Tous ces bogues et leurs correctifs que je viens d'énoncer, ont été rapportés au développeur principal de U-Boot, Wolfgang Denk, mais seul le dernier a été pris en compte. Les deux autres ont été mis à l'écart sous prétexte qu'il s'agit de bogues de XMD et de GCC... Cependant, j'ai eu des retours d'autres développeurs qui ont été ravis de mes correctifs et qui ont donc demandé à Monsieur Denk de les prendre en compte. Pourtant, à ce jour, je n'ai pas de réponse de sa part...
Le système de relocation de U-Boot rend le débogage et l'utilisation des symboles très compliqués. D'autres chargeurs utilisent un système en deux phases[15]: la première consiste en un programme minimal qui réside dans la Flash copiant l'exécutable principal du chargeur dans la mémoire vive, la seconde phase est l'exécution finale du chargeur. C'est globalement ce que fait U-Boot, mais comme il n'est composé que d'un seul exécutable, il faut remettre à jour la table des symboles à la volée. Personnellement, même si j'ai bien assimilé le principe de la relocation, j'aurais opté pour une conception en deux phases, comme la plupart des chargeurs.
Enfin, les documentations ne sont pas toutes à jour, ce qui m'a valu quelques surprises lors de mes tests. Il faut donc souvent chercher dans les sources ou dans les archives de la liste de diffusion officielle pour trouver la solution à un problème, ce qui n'est pas le plus efficace.
En conclusion, je dirais que U-Boot remplit pour le moment parfaitement son rôle, mais certains de ses défauts pourraient être gênant par la suite. Une alternative serait de choisir RedBoot qui semble être bien adapté, mais je n'ai pas pu le tester. Il faut savoir qu'eCos (le noyau sur lequel se base RedBoot) supporte un nombre plus important d'architectures, de plus il existe une version pour le Virtex-II Pro et il est compatible en partie avec l'API de Linux (il gère donc aussi le multi-process). C'est pourquoi l'emploi de RedBoot me semble plus judicieux.
