Alors que je suis en pleine galère de portage uClinux sur ma carte (toujours la même, actuellement j'arrive à charger et lancer un kernel, mais manifestement il boucle en reboot à l'initialisation, au niveau du deflate et de _setup_mmu, ce qui est étrange pour un uClinux configuré sans support de la MMU, vous en conviendrez), je tombe sur le peu de doc disponible sur le net, et notamment sur cette présentation/conférence à propos d'un portage de Linux sur plateforme LPC de Philips. Morceaux choisis :

Preparing to program Linux
  Since our U-boot can not program, we need to create a .hex file so JTAG can program it.
  objcopy does not support changing base address of result Intel hex file.
  Wrote our own program to convert from binary to Intel hex file supporting different base address.
  Built u-boot images and converted them to Intel hex.

Programming and Running?
  Used JTAG again to program Linux and the file system
  Running, asking U-boot to run Linux
  No response from kernel...
  We have no symbolic debugging, but tried a breakpoint using JTAG debugger
  We are nowhere near a valid address...
  Seems we programmed the wrong file...
  But this was the file according to the AP...

Les galères s'enchaînent...

Running init
  Searching for help on the Internet did not help (first time in my life...)
  Contacting Philips and after a lot of effort (since they officially do not support Linux) we found a contact person in China...
  He looked at our kernel configuration and found that we did not include support for flat binaries, no one told us to do so...
  Added support for flat binaries and...
  Let there be light...

Is our work done?
  Our work is far from being done, we ran uClinux on an evaluation board only
  Hardware guys never build a similar board...
  We need to modify U-boot for our new board
  Board specific code is coded in ARM assembly so we had to learn ARM assembly.

Au final :

Returning to evaluation board
  Retrying to run on evaluation board...
  No success...
  We should minimize our changes in Linux code...
  Ok, it runs but it is unstable...
  Took us about 3 weeks to find out a minor change in Linux configuration (ARM clock).

Conclusion de l'aventure :

Summary
  This talk contains only the highlights, we had much more problems, some of them our our mistakes.
  What do we learn from this?
  Nothing is as easy as it looks.
  Try to avoid changing the Linux kernel, the kernel programmers know what they are doing.
  Do not attempt porting if you are not absolutely familiar with target architecture.

La fois où j'ai expliqué longuement à un non informaticien les particularités du métier, il a trouvé ça désespérant. C'est vrai. Mais bon, quand on a trouvé au détour d'un pdf paumé que faire un "set $sp=<load_address>" dans gdb avant de faire son load peut éviter des mésaventures quant au chargement de code envoyé via j-tag, et que effectivement on passe d'une erreur mystérieuse dont on a finit par comprendre au détour d'une ML lorsque le patch contenant le message d'erreur a été soumis qu'on est en train de jardiner dans la RAM dans des adresses fantaisistes, à un linux qui certes ne dit rien mais manifestement tourne (ok, dans le vide, mais quand même), on est presque heureux. Forcément, le type qui fait du web, à côté, il paraît bizarre...