Système de développement virtuel pour GP2X - Page 2

pareil cette taille me semble raisonnable !
QUand on voit la taille des démos de jeux récents.. tu es largement dans la gamme enfin largement en dessous

Parcontre il ne faut pas perdre de vue que l'image décompressée pèse 2Go, pourquoi cette taille ? Ben tout simplement j'ai laissé de l'espace libre afin de pouvoir rajouter des programmes et/ou enregistrer des fichiers de développement perso. A savoir également que j'ai viré toutes les docs dans /usr/share/doc et /usr/share/man afin de gagner encore un peu de place...

C'est sûr que de toutes manières, on n'est plus à 1 ou 2go près de nos jours, et le plus important est bien d'avoir un environnement de travail fiable (car séparé du système hôte) et simple à utiliser car tout préconfiguré !

Alors, on le teste quand ton système ? ;-)

Salut,

Bah une archive contenant l'image + émulateurs est déjà disponible sur le net à cette adresse:

http://dl.free.fr/iA9Ts5THG/Gp2xDev.tar.gz

Si y'a des intéressés, je pourrai voir à l'insérer sur le réseau Freenet...

Au fait j'ai oublié de dire, une fois le bureau chargé, le menu de fluxbox est accessible par clic droit sur le bureau

Alors que donnent les tests ? Ca marche ?

De mon côté, ce matin j'étais en train de voir si je pouvais pas booter le kernel de la gp2x avec Qemu-arm, mais bon ça me semble mitigé, enfin je lâche pas et j'essayerai d'un compiler un qui boot, ça serait cool ça

Sinon aussi j'ai regardé le système OpenMoko, et plus particulièrement le zip contenant qemu-arm et l'image d'OpenMoko, permettant de le démarrer sur un PC...

Parcontre c'est très très lent, j'espère que j'aurai de meilleurs résultats avec le boot du noyau gp2x quand j'y arriverai. Ca permetterait de tester directement les programmes et en prime, ça rendrait possible à des gens n'ayant pas de gp2x de contribuer au développement des projets en cours.

Qu'en pensez-vous ?

Alors ca y est j'ai enfin DL ton image et je l'ai enfin lancé
Donc le boot se passe sans problème, mais j'arrive au login ( en version texte, pas graphique ) mais je ne trouve pas le login et le mot de passe pour me loguer...
J'ai loupé un chapitre , parce que j'ai relu tout le post et j'ai cherché une documentation dans l'archive , mais j'ai rien trouvé ...

Merci d'avance

Il me semblait l'avoir laissé quelquepart, mais tfaçon pour te logger:

login: root
Pass: gpette

Mot de passe que tu peux biensûr changer, la création de nouveaux users doit être possible aussi, mais je ne l'ai pas fait pour laisser la liberté de personnaliser le système à chacun.

D'ailleurs, je sais pas si j'ai bien fait de laisser le prompt de login

ouaip je pense que tu devrais le virer et faire un autologin
Comme ca hop on boot direct sur l'environnement de travail comme on démarre un logiciel pour taper du code
Et j'ai pas testé mais est ce que tu enregistre les fenêtre ouvertes ou pas ? (réouverture de la session dans le même état qu'a la fermeture)

Nop je le fais pas encore, pour ça faudrait que j'implémente une sorte d'hibernation (ce qui doit être faisable normalement...).

En contre partie j'ai réussi à démarrer l'image à l'aide de vmware player, en la convertissant au bon format:

qemu-img convert gpdev.img -O vmdk gpdev.vmdk

après suffit de créer le fichier vmx correspondant à l'aide des tutos sur le net et hop c'est parti.
L'avantage de vmware player c'est que ça supporte l'émulation USB du coup, donc possibilité de bosser sur du vrai hard (bluetooth, webcam, etc etc).

A noter que l'image vmdk générée ici est aussi compatible avec VirtualBox.

Pour l'histoire de "mise en veille" faudrait essayer de créer un fichier de swap et d'installer swsup2. Il n'y a pas de raison que ça ne fonctionne pas

Parcontre je n'ai pas constaté d'accélération notable de la vitesse d'émulation avec vmware player... Donc Qemu est pas si mal en fin de compte

après c'est ptète ma machine qui n'est pas assez puissante pour aller plus vite mais ça m'étonnerait...

Bon, j'arrive à faire fonctionner à peu près la mise en veille prolongée, MAIS je rencontre un problème de freeze du serveur Xvesa lors du retour de veille. Néanmoins, les fenêtres sont bien restaurées à leur état normal et je vais tenter autre chose

Bon pour ajouter le support de l'émulation, il suffit de faire ceci:

apt-get update
apt-get install hibernate

Normalement il doit installer uswsusp

Ensuite quand il pose des questions appuyez simplement sur [enter].

Quand tout est installé, il suffit alors de bien remplir le fichier de config /etc/uswsusp.conf

resume device = /dev/hda2
compress = y
early writeout = y
image size = 0
RSA key file = /etc/uswsusp.key
shutdown method = platform
max loglevel = 7

puis refaire un spkg-reconfigure uswsusp, là il devrait régénérer le initrd. Note: aux questions qu'il va poser, laisser les valeurs par défaut, normalement il reprend celles du fichier de config.

Pour suspendre taper simplement: s2disk

Lors du prochain reboot il va faire le resume automatiquement.

PARCONTRE, avant de faire ça éditer /etc/profile et commenter la dernière ligne (celle contenant startx), rajouter un # devant pour la commenter, et ensuite taper reboot pour relancer la machine virtuelle.

Cela aura pour effet de ne pas lancer Xvesa au prochain boot, donc de rester en mode console. Une fois en mode console, vous pouvez taper s2disk et ainsi tester l'hibernation.

Pourquoi tout ceci ? bah tout simplement parce-qu'il y a un conflit entre le framebuffer utilisé par Xvesa et l'hibernation.

Si quelqu'un trouve la solution au problème

NOTE: l'hibernation est très rapide, le retour prend un peu plus de temps à cause du boot du noyau, mais reste néanmoins beaucoup plus rapide qu'un boot.

bah au pire virtualbox a une fonction d'hibernation..

MERCI BEAUCOUP

Je vais de ce pas tester tout ça ....

Mille merci

oeildefeu (./44) :
bah au pire virtualbox a une fonction d'hibernation..

Pour vmplayer aussi ça fonctionne bien ... je viens de faire le test

OK ben si vous arrivez à vous démerder sans l'hibernation de linux

La version GPL de VirtualBox fonctionne au poil, mais dommage que faille convertir l'image avec qemu-img à chaque fois...

Vous aurez sans doute remarqué que les outils de dev sont dans /opt/open2x

et les sources de noyau sont dans /usr/gp2x

Maintenant pour ce qui est du path, il est automatiquement défini au démarrage via le script /etc/profile.

Un autologin doit être possible, je vois ça de ce pas

Bon alors voici les résultats de mes tests:

Un autologin est parfaitement faisable !!! Voici la procédure pour le mettre en place simplement:

créer un script /bin/autologin, pour cela taper:

nano /bin/autologin

Puis dans ce fichier mettre ceci:

#!/bin/sh /bin/login -f root

Ensuite enregistrez le fichier, fermez-le et faites:

chmod +x /bin/autologin

Puis, éditez votre /etc/inittab de cette façon:

nano /etc/inittab

Trouvez les lignes:

1:2345:respawn:/sbin/getty 38400 tty1 #2:23:respawn:/sbin/getty 38400 tty2

Et modifiez-les de cette façon:

1:2345:respawn:/sbin/getty -n -l /bin/autologin 38400 tty1 linux 2:23:respawn:/sbin/getty 38400 tty2

Enfin enregistrez le fichier (ctrl+o depuis nano).
Le fait d'enlever le # de la seconde ligne la décommente, elle servira au cas où vous aillez fait une fausse manip quelquepart, il suffira alors de faire alt+F2 et de vous logger normalement sur cette nouvelle console. Si vous souhaitez plus de consoles virtuelles vous pouvez décommenter les autres lignes mais c'est pas très utile si vous bosser sous Xvesa, et cela consommera de la RAM pour pas grand chose...

Allez encore une dernière étape à faire, néanmoins importante si vous ne voulez pas que le mot de passe root vous soit demandé à chaque boot:

nano /etc/passwd

Trouver cette ligne (c'est la 1ère ligne du fichier normalement):

root:x:0:0:root:/root:/bin/bash

La remplacer par:

root::0:0:root:/root:/bin/bash

Si vous ne voyez pas la modif, il suffit simplement d'enlever le x qui est présent au début de la 1ère ligne

Enregistrez maintenant votre fichier et voilà, normalement votre autologin doit être pleinement fonctionnel.

Je vais pousser mémé mais sur mon pc portable (P-IV 2ghz) c un peu mou.. kqemu ?
J'essaye de tester kqemu aujourd'hui on verra..

Right click on `kqemu.inf' in Explorer and choose Install.

In order to start kqemu, you must do:
net start kqemu

Bon j'ai fait ça je sais pas si cela suffit ... j'ai l'impression que c'est moins mou..

Au fait conseillé ou pas apt-get upgrade ?

Tant qu'à utiliser Kqemu, tu as mieux à faire crois-moi

Si tu es sous linux, tu as une solution viable

Sous win parcontre émulateur oblige

depuis le système virtuel, aller dans un xterm, puis:

nano /etc/profile

Aller chercher la dernière ligne, puis commenter:

/usr/bin/startx

comme ceci:

#/usr/bin/startx

Enregistrer le fichier, puis arrêter normalement le système virtuel.

Sur votre système hôte (votre linux), à l'aide d'un terminal, aller jusque dans le dossier de votre dossier "image" de gpdev.

Vous devez normalement voir un fichier nommé gpdev.img

On va maintenant monter cette image comme ceci:

mkdir gpdev mount -o loop,offset=32256,rw,user,umask=0 gpdev.img gpdev/

Ensuite on va chrooter à l'aide du script que j'ai placé dedans:

cd gpdev ./changeroot

Normalement vous devez voir des lignes s'afficher et enfin un nouveau prompt.
Quand vous êtes dans votre système, afin de retrouver votre environnement (PATH des outils, etc etc) faites ceci:

source /etc/profile

Puis vous pouvez naviguer et bosser dans votre système comme si vous étiez dans votre machine virtuelle.

Pour pouvoir lancer et tester vos applis avec le Xorg hôte, il suffit d'ouvrir un autre terminal et de naviguer dans le dossier "gpdev" où vous avez monter l'image, et de lancer tout simplement le programme...

quand vous avez fini de bosser, pour sortir du chroot, faites simplement

exit

Cela va démonter /proc et /dev dans votre chroot automatiquement.

Pour démonter l'image proprement, déjà assurez-vous que plus aucun programme ni terminal n'est ouvert dans le dossier gpdev, puis faites:

cd .. umount gpdev.img

Voilà, vous savez maintenant vous passer de machine virtuelle quand vous bossez déjà sur un PC Linux

apt-get upgrade possible, mais pas indispensable étant donné que c'est une machine virtuelle.

Parcontre la version de debian utilisée étant pas encore en stable, il y aura probablement pas mal de MAJ.

A la fin des updates, toujours effacer les fichiers dans /var/cache/apt/archives, dans /usr/share/man et dans /usr/share doc, afin de gagner de la place

C'est bourrin mais ça marche.

j'suis sous windows.. mais manip interessante !

plop je viens de tester l'autologin et ca roule impec !
Par contre c'est vrai que s2disk sans fermer Xvesa ca merdouille..

Première utilisation de l'image de sebtx aujourd'hui:
J'ai décompressé les sources du firmware 4.0.0, vérifié si une maj était dispo (svn update), configuré quelques bricoles du kernel (make menuconfig, ajout de qques modules supplémentaires) et lancé la compilation (make).
Pour le moment, tout se passe très bien, sublime !

Je pensais à un truc: tu pourrais presque maintenir ton image à l'aide de subversion (versionner /etc/, et autres répertoires "non user"): on pourrait alors intégrer tes modifications dans nos images avec un simple 'svn update /' ... est-ce abusé...? ...un peu, mais tellement pratique !
Avantages:
* chaque modif que tu fais est récupérable en tapant seulement 12 caractères !
* pas besoin de télécharger l'image à chaque modif (très gênant si on a déjà personnalisé un minimum son environnement user, gain de temps énorme)
* si les utilisateurs de l'image sont "sages" et pas trop bidouilleurs, cette approche doit donner des environnements de développement pour les non connaisseurs très robuste

Inconvénients:
* toute modif d'un fichier versionné de l'image faite en local par un utilisateur va générer un conflit avec subversion lors d'un 'svn update',
* lourdeur de gestion/mise en place...? quel fichier doit être versionné, etc.?

En tous cas, merci pour ton travail !!
Tu nous fais gagner à tous un temps fou en éventuelles galères de configuration !

Ok, donc pour s2disk si vous n'en n'avez pas besoin puis-je le retirer pour re-gagner de la place ?

Suversion serait utile pour quand je fais une modif de config. Sachant que pour l'update du système y'a l'outil apt.

Parcontre rien ne m'empêche de publier un script qui effectue chacune de mes modifs à chaque update. ça serait à mon avis plus adapté

Sinon, une solution bien à laquelle j'avais pensé était de faire une debian virtuelle avec les mêmes versions de gcc/glibc mais tout ça en architecture ARM. Avantage ? plus besoin de cross-compiler, ça fait un peu comme une gp2x virtuelle, mais sur son PC, douée de possibilités intéressantes

Inconvénient; obligé de recompiler les librairies (sdl & co) optimisées pour mettre sur le système virtuel...

Qu'en pensez-vous ?

Si tu es motivé pour écrire des scripts, alors ça pourait être sympa !

Sinon, comment ferais-tu tourner une machine virtuelle ARM sur PC (quel ému ?)
En fait, si on peut faire ça, ça veut dire qu'on pourrait même booter le kernel de la GP2x ?
Pour développer, y'aurai pas mieux !

C'est justement ce que j'étais en train de dire. Sans vouloir booter exactement le même kernel, on peut booter la même version mais utiliser un disque dur virtuel au lieu de flash.

Sinon faire comme le projet openmoko, qui ont bidouillé un peu qemu pour le faire coller au hard du neo1973, pouvant booter le firmware d'origine. c'est forcément faisable, mais cela suggère d'en connaitre un rayon sur le mapping mémoire et les ressources de la gp2x...

Ré-upload de l'image à lancer avec Qemu, root / gpette

http://www.megaupload.com/?d=LPNAVYUC

Licence libre of course