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

Bonjour à tous,

Bon voilà la dernière idée que j'ai eu

Le principal problème que je rencontre lorsque je développe avec la gpette, c'est que lorsque je passe du PC perso au PC boulot, ou lorsque je réinstalle le système par exemple, je suis obligé de refaire ma chaine de compilation gp2x.

Ainsi j'ai eu l'idée de faire un système virtuel à l'aide de Qemu, entièrement dédié au développement GP2X, avec les bonnes librairies et toolchains installées et utilisables clé en main. Pour le moment j'ai réalisé un tel système en prenant une debian sarge installée à l'aide de debootstrap sur une image Qemu de 700Mo (non compressée). Mais je me rends vite compte qu'une install debian n'est pas encore assez optimisée. Donc je pense refaire ça avec une Gentoo (plus adaptée au dev).

Sachant qu'une Gentoo prend vite de la place au niveau de portage (gestionnaire de paquets), mais ce problème peut êtrre vite résolu à l'aide d'une seconde image qemu montée sur /usr/portage.

Les avantages de ce système sont:

-Une image contenant tout un système facilement copiable sur une clé usb et transportable n'importe où.
-Un système accessible via Qemu sur tous les PCs (windows ou Linux).
-Une image qu'on peut monter dans un dossier et dans laquelle on peut chrooter (pratique sous Linux).
-Un serveur X complètement indépendant et permettant de tester ses applications SDL.
-Voire même pas de serveur X dutout, les applis SDL étant testées à l'aide du framebuffer...
-Un système très léger et modifiable à souhait, clé en main et toujours prêt à l'usage, même pour les débutants

Aujourd'hui je vais essayer de voir pour installer une gentoo, et voir le niveau d'optimisation que je peux atteindre avec ça

Que pensez-vous de ce concept ?

tres bonne idée pour ceux qui veulent un truc portatif, c'est un pêut comme du virtual machine?

Superbe idée !

J'ai déjà virtualisé Windows XP au boulot, sous Qemu (avec le module d'optimisation i386 kqemu), mais ça reste lent, est-ce qu'un Linux tourne mieux ?
Autre choses:
- J'imagine que l'image de ton système n'est pas bootable par un vrai PC, mais seulement émulable par Qemu ?
- Je sais que VirtualBox (Licence GPL !) est plus performant pour la virtualisation d'OS que Qemu, mais je ne sais pas si les images virtualBox sont compatibles avec Qemu...?

D'autre part, virtualBox permet de sauvegarder l'état de sa session (pour n'importe quel OS) comme on le fait déjà avec un vrai OS sur un vrai PC en mode "suspend to disk" (RAM et état CPU sauvés sur le disque, ça redémarre en 5 secondes !), ça pourrait être un plus par rapport à Qemu: pour reprendre le développement où on en était, c'est extrêmement intéressant !

Alors quelques news

Suite à mes tests il en ressort que:

-Pour le moment Debian est beaucoup plus adapté que Gentoo (niveau poids sur disque et rapidité de configuration).
-Je suis en train de bosser sur le framebuffer ainsi que sur l'optimisation du système (boot plus rapide, économies de RAM)
-Faire quelques script automatisant certaines choses au boot
-Essayer de faire la liste des élémente gp2x (libs) à inclure d'office...

Si j'ai choisi Qemu au lieu de VirtualBox, c'est tout simplement parce-que qemu n'a pas besoin d'installation et qu'il est "mettable" sur clé USB facilement. Parcontre la fonction d'hibernation de Debian peut peut-être être activée... Et vu le peu de matériel, ça ne doit pas être très compliqué à mettre en place.

Quant aux performances, le système étant minimaliste, elles sont tout à fait honorables, et le système répond très bien aux commandes qu'on lui envoit. Le boot se fait en 30-40 secondes pour le moment, et les ressources consommées par Qemu sont assez faibles.

Après je précise que l'émulation n'est indispensable que pour les windowsiens, et l'image que j'utilise est convertible en un format que VirtualBox sait gérer... Donc aucun souci à se faire.

Parcontre une chose que je cherche toujours c'est comment redirger une appli X depuis un chroot sur le X du système hôte...

Bon petites news vite fait sur l'avancement du projet


J'ai installé la plupart des libs sur la debian virtuelle et il en ressort quelques choses assez gênantes, dont les libs SDL qui installent des libs X (dépendances inutiles...).

Mon choix s'est porté sur un système léger, en mode console avec un éditeur de style VI ou nano, et juste ce qu'il faut pour compiler.

Possibilité d'importer/exporter des fichiers depuis windows via le réseau ou un dossier partagé.

Pour le moment je règle quelques problèmes dont un avec le framebuffer et SDL. J'ai chargé le module vga16fb et quand je lance une appli SDL, celle-ci tente de changer la résolution, et je me prends un "Error creating surface: no video mode large enough for 320x240". Je reste donc sur les roses...

Dès résolution de ce problème de framebuffer, je me penche sur une LFS, seul système léger et où on peut gérer les dépendances à souhait...

Ca va être long et pénible, mais le jeu en vaut la chandelle... Qemu reste en + extrèmement rapide sur des petite systèmes compilés de la sorte Alors les sceptiques pourront toujours convertir leur image en vmdk pour la faire tourner sous VirtualBox mais perso vu la légèreté du truc je n'en vois pas l'utilité En + je compte compiler un noyau avec juste ce qu'il faut pour gérer le matos émulé par Qemu. Et j'espère également faire fonctionner un jour l'émulation USB1 comme si y'avait un port sur la GP2X

NicoLarve (./3) :

- J'imagine que l'image de ton système n'est pas bootable par un vrai PC, mais seulement émulable par Qemu ?

Alors pour répondre à ta question, j'utilise Qemu principalement pour installer rapidement un système d'exploitation (de type Linux) sur des vraies machines peu puissantes. Il y a peu voici comment je m'y suis pris pour mettre win95 sur un portable 486:

-Branchement du disque dur sur ton PC avec un adaptateur USB.
-Boot sur un ISO de win95 avec pour disque dur virtuel le device de ton vrai disque.
-Installation normale de win95 sur le disque comme sur un vrai PC et copie du CD de win95 dans un dossier du disque dur virtuel.
-Boot du disque dur dans le vrai PC (et là faut savoir que win95 redétecte tout ce qui a changé, c'est à dire le matos du nouveau PC).

C'est hyper simple, rapide et efficace et ça marche avec beaucoup de choses...

Doncsi tu veux mettre ce système sur un vrai PC, tu fais ceci:

-Branchement de ton disque en USB.
-Boot d'un liveCD Linux avec le vrai disque dur en maitre et l'image virtuelle que j'ai créé en esclave.
-Montage des deux disques et copie des fichiers de l'esclave au maître.
-Chroot dans le disque maitre et exécution de grub-install pour mettre le boot loader sur le vrai disque.
-Démontage et arrêt propre de Qemu.

Et voilà après ça marche tout seul

OK, merci pour tes explications.
Tiens pendant que j'y pense, si tu veux quand même offrir la possibilité d'utiliser un gestionnaire de fenêtre (ou si ça peut résoudre les soucis daffichage), il existe WindowMaker, très light (basé sur Xorg).
Il est notamment utilisé dans les live CD Linux "RescueCD".
L'ISO de RescueCD fait 120Mo (version 0.3.7) et d'autres versions sont plus petites encore (ce n'est qu'une suggestion a cas où hein !).

Bon courage !

Re

Après un bon week-end de repos, j'ai repris l'optimisation de la Debian et je commence les tests de compilation

Pour commencer, j'ai tenté de compiler beat2x, en mode PC ça fonctionne mais je n'arrive pas à le lancer (problème avec le framebuffer à la résolution demandée). J'ai également essayé de le compiler avec la tolchain Open2x, en static. Je suis pour cela parti du Makefile.linux que j'ai modifié en conséquences. Je me suis fait une frayeur avec un "Out of memory" quand j'essayais de le compiler en static. J'avais alloué seulement 64Mo de RAM "virtuelle" à la machine, j'en ai alloué 128 et ça fonctionne beaucoup mieux, screenshot à l'appui !



La compilation se fait assez rapidement et les ressources prises par Qemu sont vraiment très faibles lors du développement, ce qui fait qu'on a un système assez réactif !

Je garde Debian pour cette application car elle a l'avantage d'être rapide, légère, et surtout le gestionnaire de paquets (apt) est génial.

Je ne compte pas mettre de serveur X pour la bonne et simple raison que ça ne sert pas à grand chose ici. Je pense que le mieux est de bosser en framebuffer comme le fait la GP2X

L'image compressée du système fait 200 et quelques Mo, et décompressée elle en fait 700.

Que pensez-vous de tout ça ?

Et aussi, quelques questions à vous poser:

1) Est-il utile d'ajouter gdb (débugger Linux) ?
2) Est-il utile d'ajouter un programme FTP (pour ulploader quelquechose sur la gp2x via usb net) ?
3) Comment est-il possible d'alléger au max une Debian sans tout casser ? (suppression des locales inutiles, ...) ?
4) Pensez-vous qu'un serveur X soit utile ?
5) Que pensez-vous du poids de l'image du système ?

Si vous avez des questions je reste à votre disposition

Bon voilà, j'ai passé l'image à 2Go. Sachant que la taille compressée sera juste fonction de la taille des fichiers mis dedans.

Pourquoi ce changement de taille ? Ben tout simplement parce-que j'inclus les sources du noyau de la dernière version du firmware de la F100 ainsi que la toolchain de GPH pour pouvoir compiler ce noyau et tous les modules à utiliser dessus

Ca avance lentement mais sûrement !!!

Bon encore quelques nouvelles

-La compilation de modules noyau fonctionne bien ainsi que le menuconfig, donc tout est OK de ce côté !
-J'ai résolu un ptit problème avec un partage de dossier. Dorénanvant un dossier "partage" est créé dans le dossier Qemu, il permet d'émuler une partition "hdb1" qui pointe dans ce dossier en lecture/écriture.
-La machine virtuelle a un accès à Internet complètement transparent pour l'utilisateur

Il me reste donc deux problèmes principaux à résoudre:

-L'installation du module ALSA nécessaire au son avec SDL
-Un système d'affichage (tinyX ?) pour tester les applis SDL de façon complètement transparents et indépendante du système hôte.

Que pensez-vous de tout ça ?

Tout ça est pas mal, il faudra juste que tu arrives à bien montrer les avantages de ton système si tu veux qu'un dev l'utilise
Mais c'est clair que ca présente de bons avantages !

Ton développement m'interesse au plus haut point ... Ca m'a tout l'air génial

1) Est-il utile d'ajouter gdb (débugger Linux) ?
Pourquoi pas , ça ne mange pas de pain

2) Est-il utile d'ajouter un programme FTP (pour ulploader quelquechose sur la gp2x via usb net) ?
ou plutot un client SSH ?

3) Comment est-il possible d'alléger au max une Debian sans tout casser ? (suppression des locales inutiles, ...) ?
Je connais pas assez les Debian ...

4) Pensez-vous qu'un serveur X soit utile ?
Pas vraiment , du moment qu'on puisse tester nos applis graphique . Peut être un bon petit menu avec certaines fonctions et une bonne plateforme de fichier d'aide ?

5) Que pensez-vous du poids de l'image du système ?
Maintenant avec les machines actuelles , 2 Go c'est tout petit

Serait il possible d'avoir aussi le support de la F200 avec les sources du noyau du firmware F200 ?

Merci d'avance.

OK j'ai pris en compte les demandes, et vais de ce pas récupérer les sources du noyal. j'espère que c'est la même toolchain qui est utilisée. Mais ça va encore alourdir le système. Enfin c'est pour la bonne cause !!!

Il faut aussi que je fasse le bilan des libs à ajouter... D'ailleurs les libs SDL de la toolchain Open2x sont-elles bien ou y'en a-t'il des plus optimisées ?

Pour le moment le fichier ZIP compressé du système + Qemu win fait 354,5Mo, ce qui est plutôt raisonnable

Pensez-vous qu'un tel upload passerait sur gp2x file archive ???

les SDL open2x sont les plus optimisé sur GP2x

Bon bah voilà, je teste la compilation des modules du firmware 4.0.0 et visiblement ça marche:



Donc voilà ça avance Par défaut je compresserai les sources noyau, et chacun décompressera celles dont il aura besoin, dans un souci d'économie d'espace disque

cool

Merci beaucoup

Bon alors là j'ai pas beaucoup avancé. Mais je cherche à régler quelques petits problèmes.

Comme je le disais hier, j'ai inclus les sources du noyau firmware 4.0.0, et j'ai installé unzip et gdb.

j'obtiens des erreurs maintenant quand je lance une appli SDL:

Can't set video mode: No video mode large enough for 320x240

J'espère que j'arriverai à résoudre ce problème bien chiant

Sinon je vais aussi essayer de charger le bon module ALSA pour le son

Finalement j'ai mis un petit serveur X, nommé Xvesa, et qui permet de faire tourner fluxbox

Mon occupation est donc maintenant de configurer fluxbox pour faire une jolie interface toute propre... J'essaye également de faire tourner Eterm

La je dis ca devient nickel !

Bon ben ça avance bien là

J'ai configuré TinyX + fluxbox avec un chtit fond d'écran provisoire, le tout en 800x600. Les applications SDL se lancent correctement maintenant

Tout ça va bientôt être prêt pour être propulsé sur le net en préversion test

Allez un petit screenshot pour mettre en appétit:

C'est joli non ? J'ai pas encore touché grand chose et je vais essayer d'alléger tout ça un max. Sachant que je n'ai pas réussi à faire fonctionner Eterm à cause de problèmes de polices....

J'ai ajouté Dillo dans un but de documentation au format html qui pourra être inclue plus tard

Salut,
Ça avance vite ton projet, cool !

Je pensais à un truc, trouverais-tu pertinent d'installer subversion dans ton image de manière à récupérer les divers dépôts (Open2x, GPH, etc.) et surtout pour pouvoir mettre à jour très facilement les diverses sources ?
Ça pourrait même inciter des développeurs à faire systématiquement un dépôt subversion pour leurs développements, accessibles pour toute la communauté GP2x !

Au niveau de la réduction de taille de la Debian il doit y avoir pas mal de trucs inutiles pour ton projet.
Le mieux serait de poster la liste des paquets installés, on pourra tous faire le tri comme ça !

Ok pour subversion, c'est ajouté

Ce qu'il y a de bien c'est qu'un petit coup d'apt et hop c'est installé.

Enlever les paquets en trop c'est une très bonne idée, mais sur Debian je ne sais pas comment faire sans casser les dépendances

Actuellement j'en suis à:

-Une image non compressée de 2Go
-Un espace libre utlisable de 500Mo environ

Le système utilise 1,4 Go d'espace sur les 2Go

Il y a également 47 Mo de SWAP.

La liste des paquets arrive bientôt, juste le temps de trouver comment la faire.

Si y'en a qui sont bons en graphisme je suis à la recherche d'un bon papier peint pour fluxbox, car celui que j'ai là je ne sais pas si il est librement utilisable...

Ok j'ai la liste,

Les paquets marqués "deinstall" sont virés.

Le problème c'est qu'il faut virer des services au boot.

J'ai également ajouté un client ssh. J'ai installé idesk mais sans encore m'en servir, c'est juste au cas où...

Je vais aussi, quand j'aurai du temps, faire le tri des modules à virer pour gagner encore un peu de place...


Fichier joint : liste.txt

Bon, je me suis un chtit peu amusé là

J'ai transféré le système sur un disque dur véritable pour le faire booter sur un vieux PC IBM 380Z.
Malgré quelques bugs acpi ou autres, ça marche !!!

Le PC ne possède que 32Mo de RAM et le disque dur fait 6Go.

Quand tout vient de booter, interface graphique compris, il reste au moins 2Mo de RAM dispo, et la swap n'est pas utilisée

Allez un petit lien vers une photo (attention lourd !) juste pour le fun

http://www.no-lobbies.info/gp2x/p233.jpg

lol t'es un vrai geek toi !

Bonjour à tous,

je vous annonce la mise en ligne de la version bêta de test, à vous de juger, elle intègre tout ce qu'il faut, qemu version linux et qemu version win.

les variables PATH sont pré-configurées afin que les copilateurs soient immédiatement utilisables...

Voici l'adresse où vous pourrez télécharger cette release: http://dl.free.fr/iA9Ts5THG/Gp2xDev.tar.gz

Attention, ça pèse 551Mo.

Voici la somme MD5 afin que vous puissiez contrôler la bonne intégrité du package: b06d62a3177f4356824abed2746331f2 Gp2xDev.tar.gz

Bon dl

Cool

Merci beaucoup ... je lance le DL et je teste

sebtx (./23) :
Ok j'ai la liste,

Les paquets marqués "deinstall" sont virés.

Le problème c'est qu'il faut virer des services au boot.

J'ai également ajouté un client ssh. J'ai installé idesk mais sans encore m'en servir, c'est juste au cas où...

Je vais aussi, quand j'aurai du temps, faire le tri des modules à virer pour gagner encore un peu de place...


Fichier joint : liste.txt

Désolé de ne pas avoir répondu plus tôt, mon gestionnaire de fil RSS m'a induit en erreur...
Je vais regarder ta liste pour voir un peu.
On doit pouvoir enlever 500Mo, sais-tu combien d'espace prennent tous les outils relatifs à la GP2x ?

NicoLarve (./28) :
On doit pouvoir enlever 500Mo, sais-tu combien d'espace prennent tous les outils relatifs à la GP2x ?

Je retire ce que j'ai dit: ta liste me parait déjà bien courte...
C'est vraiment la liste de tous les paquets installés ?

Ouaip, mais faut savoir que les outils de compilation prennent beaucoup de place déjà... Sachant que leur taille décompressée est énorme par rapport à leur taille compressée. De plus, j'ai laissé apt installer les dépendances selon ses choix. Je suis parti d'un système minimal à l'aide de debootstrap...

A vous de voir, 500 Mo pour un tel système ça me semble raisonnable et avec les connexions du moment, ça ne doit plus poser beaucoup de problèmes...