Petit topic pour les gens intéressés...

J'ai donc acheté sur ebay un board de développement FriendlyARM mini2440 avec écran 3.5". Acheté le 19/12, reçu le 14/01, coût total 60€ frais de port inclus.

Premier boot: windowsCE5.net préinstallé, en chinois, avec un touch screen pas calibré. Je branche une souris USB qui est reconnue et me permet d'essayer à tâtons les différentes icônes jusqu'à tomber par hazard sur l'utilitaire de calibration. Je cherche aussi s'il n'est pas possible de changer la langue du système, mais non. Branché au réseau, je peux configurer le DHCP, et même l'IPv6 de mon réseau fonctionne out of the box. Un carte SD insérée est reconnue, et si je le branche comme USB device à mon PC, il est vu comme un serial iPaq.

Un peu plus sérieux: installer le linux livré sur CD. Le CD est aussi essentiellement en chinois, même le manuel, mais hereusement, tout se trouve sur le net en anglais.
Je connecte mon PC au port série du mini2440 avec un câble null-modem (retrouvé dans mes caisses avant de réaliser qu'il y en a un livré dans la boîte) et un convertisseur USB-série (mon PC étant, à l'instar de tous les PC modernes, dépourvu de port série).
Un petit interrupteur permet de sélectionner le boot sur la NOR, qui contient un bootloader (supervivi) permettant de partitionner la NAND et charger le kernel et l'image root par USB.
Deux versions sont fournies, suivant la taille de la flash du système. J'ai l'agréable surprise de voir qu'on m'a livré la version la plus récente avec 64MB de RAM et 128MB de flash, contrairement à ce que disait l'annonce (probablement pas mise à jour).
Je charge donc le kernel et l'image rootfs fournis, et redémarre, pour voir apparaître un beau pingouin sur l'écran, les traces du kernel sur ma console, et puis une procédure de calibration sur l'écran, puis quelques questions pour localiser l'environnement qtopia (pays, heure, langue...) Je me retrouve alors avec en petit palmtop et toutes ses application utiles.
La console permet d'avoir accès au shell, et un telnet est ouvert, ainsi qu'un serveur web. Mais pour ces deux derniers il faut configurer le réseau qui est en adresse statique (un dhcp client est présent mais le kernel par défaut ne le supporte pas...), et forcément pas la bonne. Cela fait, me voici enfin avec un système hacker-friendly...

La suite logique: recompiler un kernel et l'installer. Les sources patchées d'un linux 2.6.29.4 sont fournies, avec les configs pour les différents modèles. Je modifie la config pour ajouter le support DHCP, et l'IPv6 en module. Je change le logo de boot en passant et recompile avec le toolchain arm-linux-gcc fourni également. Tout se passe presque trop facilement, et je recharge le nouveau kernel avec supervivi. Reboot, et tout va toujours bien, à part que le DHCP ne marche toujours pas. Je copie les modules via NFS ou carte SD, mais l'IPv6 ne marche pas non plus.
Recompil avec IPv6 inclus dans le kernel, reflash, et... Le kernel est trop grand, car la partition réservée par défaut au kernel est de 2MB. J'ai donc repartitionné ma NAND pour laisser plus de place au kernel, j'ai dû modifier aussi la config de partitionnement hard-codée dans le kernel (j'ai eu du mal à trouver où, alors voici pour la postérité: arch/arm/plat-s3c24xx/common-friendly-arm.c)
Là mon kernel passe dans la partition, démarre depuis le bootloader (mais sans la console série ...?), et le DHCP ne fonctionne toujours pas Et si je rechange le switch pour booter directement depuis la NAND, le NAND bootloader cherche le kernel au mauvais endroit et ça ne marche évidemment pas.

J'en suis là, en config un peu manuelle mais je commence à bien comprendre l'architecture du bazar et je suis confiant. J'ai fait des essais avec u-boot, je vais aussi jouer avec la feature UBIFS du kernel pour gérer la NAND.

Voilà, suite au prochain numéro, vous pouvez reprendre une activité normale...

Ca devient passionnant ! la suite la suite ...

waw c'est pour en faire quoi ?

Salut,

je suppose que tu les a achete chez hifikanon. J'en ai pris 2 pour en faire un prototype de domotique (remplacer les interrupteurs par des touch screen et tout le tralala). Idem chez moi pour l'OS et le touch screen non calibré. Pour l'instant le temps me manque un peu donc je n'ai pas encore essayé d'y mettre un nouveau OS.

J'ai hate de lire la suite de tes aventures

NUTZ> en principe, une régulation de mon chauffage central... En pratique, il faudra alors que j'en achète un deuxième parce que c'est trop fun ...

La suite:
J'ai installé u-boot comme bootloader sur la NAND. Ainsi j'ai la latitude de partitionner la NAND comme je l'entends et installer un kernel plus gros.
Inconvénients:
- il faut convertir son zImage linux en un format uImage avec un utilitaire propre à u-boot.
- u-boot est patché pour pouvoir flasher une image yaffs2 (au lieu de jffs2), mais ça n'a jamais marché pour moi. Alors j'ai du flasher le kernel avec u-boot et l'image root avec le supervivi de la NOR... Ça a finalement marché mais c'est pas très pratique.
Solutions possibles:
- un initrd avec les tools de formatage yaffs
- initialiser yaffs avec un NFS root
- passer à jffs2, plus standard, mais beaucoup moins adapté aux spécificités la flash NAND

J'ai trouvé pourquoi le dhcp ne marchait pas: il faut enabler l'option packet socket dans le networking du kernel. Je ne comprends pas pourquoi l'option support DHCP n'a pas une dépendance envers cette autre option...

J'ai donc à présent un kernel compilé maison qui supporte l'IPv6 et le DHCP.

Voilaaa...

SMaton> hifikanon en effet...
Et je vois qu'il a mis à jour sa page de description.

De fait, impressionnant, c'est beau le savoir

Ca se lit comme un roman

Bon, Phil, avec un topic aussi bien léché, tu pourras pas dire que tu ne l'as pas cherché: je viens de commander le miens....

Tu voudras bien me faire un gros tarbz2 avec toute la doc en Anglish!

Après analyse de la question, je resterai avec YAFFS2 (le plus compact, le plus performant, etc.)
En bootant avec un root fs en NFS, je n'ai plus besoin de supervivi pour flasher ma partition YAFFS. Y'a qu'à effacer, faire le mount (pas de mkfs) et copier. Et pour développer, c'est tellement plus facile avec NFS.

Maintenant, je ressors openembedded pour me compiler tout ce dont j'ai besoin.

C'est énorme la façon dont s'est raconté, on mange le texte afin de savoir ce qui va se passer! Besoin de la suite go prendre quelques jours de congés afin d'avancer sur le sujet tes fans t'attendent...

J'avais pas l'intention d'en faire un roman, mais merci

On peut avoir les images avec le texte

</modedrogueON>
Si tu cherches un preneur de son, un caméraman, une stedicam, je suis ton homme pour te suivre tel Loft Stroy des g33k de l'informatique. Le concept ça serait g33k Story présenté par Mario Bross et Luigi...
</stopladrogue>
</modedrogueOFF>

Bon, ça fait plusieurs jours que je rame pour trouver la bonne solution pour mon root filesystem.

Les options:

- openembedded: j'avais déjà ramé pas mal pour mettre en oeuvre cet environnement complet de cross-compilation pour i386/uClibc. J'ai downloadé une version "préconfigurée" pour le mini2440, qui ne marche évidemment pas out of the box. Je reviendrai peut-être plus tard à la version "normale" que je reconfigurerai moi-même, mais je voulais essayer d'abord des solutions plus rapides.

- buildroot: le crosstool de référence autour de uClibc/busybox. J'ai récupéré le git et essayé de compiler la version courante ainsi que des versions taggées comme 2009.11, et ça merde toujours quelque part. Je viens de télécharger le tar.gz de la version 2009.11 pour voir si ça marche mieux, et c'est en train de compiler à fond pour l'instant (mais ça commence toujours comme ça...)

- scratchbox: très prometteur, et semble très facile d'utilisation: on se "loggue" dans le système qui est construit autour de fakeroot, qemu, LD_PRELOAD, et c'est comme si on compilait en natif. J'ai ramé pour l'installer (problèmes liés à mon kernel 64 bits, VDSO, un menu qui fonctionne dans un xterm mais pas dans un rxvt...), et aucun des cross toolchains dans les paquets debian ne fonctionnent pour ma target: les exécutables crashent tous sur un "illegal instruction". Je retenterai de configurer dans scratchbox mon toolchain à moi si le buildroot qui compile toujours foire.

- linux from scratch: c'est ce que je voudrais éviter un utilisant un des tools plus haut...

- développement sur la target: un peu pour rire mais faisable: j'ai installé un debian ARM complet que je peux monter en NFS root au démarrage de ma target. De là, je peux installer les tools de développement et les librairies que je veux... ça prend juste un peu de temps pour compiler tout le bazar

Mais que vois-je ? Mon buildroot a fini de compiler sans erreur, je retourne y voir !

Bon, j'ai trouvé.
Les toolchains de scratchbox, comme le premier toolchain que j'ai généré avec buildroot, compilent en hardware floating point, et c'est le kernel qui doit "trapper" les illegal instructions. Il faut donc enabler le floating point emulation, ce que j'avais bien fait, mais apparemment, il reste un souci. Avec mon buildroot, j'avais l'écran de login, mais le shell crashait.
Maintenant, je compile en software floating point, et tout roule. J'ai une image qui me permet de me logguer en ssh et de lancer python...
Je pourrai réessayer ce toolchain avec scratchbox, ou retenter l'aventure openembedded, qui apporte quand même l'avantage de générer des packages ipkg installables individuellement plutôt qu'une image complète qu'il faut synchroniser avec ce qui est déjà installé.

Mais ce sera pour plus tard, ce soir je regarde un film avec madame...

quel film?

donc, en très résumé, tu as fait table rase de l'image chinoise pré-loadée et tu as mtn ton propre image avec ton propre kernel et ton propre FS et ton propre shell qui tournent dedans?

Cela signifie que tu es (très?) loin de pouvoir jouir du côté graphique/touch-screen/widgets/Xorg/applications/browser ?

Et du côté network? tout ok (kernel-ready) ?

Tout juste.



Le framebuffer est fonctionnel (pingouin au boot sur l'écran). Le kernel supporte d'ailleurs très bien l'image FS standard avec qtopia.
J'ai un xorg kdrive (anciennement TinyX) compilé qui se plaint de la config, que je pourrais patcher.
J'ai aussi tenté la compil de xorg sur framebuffer dans buildroot, sans succès, je pourrais le compiler à la main.
J'ai eu le même ecueil avec Qt-embedded dans buildroot. Je pourrais aussi le compiler tout seul comme un grand.
J'ai pour l'instant un faible pour une solution à la pyvm, où j'attaquerais directement le framebuffer, sans passer par X ni même Qt embedded.

Avant d'opter pour une de ces solutions, je voudrais surtout me fixer sur un système de cross-compilation, et je crois que j'opterai pour scratchbox, parce que la solution est élégante, et qu'elle est également utilsée par le SDK de Maemo, avec lequel je m'attends à jouer pas mal dès que j'aurai pu mettre la main sur ce qui sera mon prochain GSM.

Mais dans l'immédiat, je fais du hardware, car j'ai reçu mes capteurs de température I2C, en boitiers SOT23 (c'est tout tout tout petit...)




Yep. Pas utilisé le wireless, mais j'ai IPv4, IPv6, multicast, ...

Ma carte vient d'arriver aussi, pas de problème de douanes non plus..

Super, je te la racheterai quand tu en auras marre ...

rfr> excellent deal...
je sens que je risque d'abandonner déjà tous mes mini projets PIC du coup.. didix tu rachètes aussi?