[U-Boot-Users] RFC: New uImage format bindings

Darcy Watkins DWatkins at tranzeo.com
Wed Dec 19 15:50:37 CET 2007


Hello,

I like the idea, but I think that the FTD blob for a specific board
should normally reside on that board somewhere alongside the U-Boot
image itself.  This should be part of the board support package for the
board.  Having it in the uImage optionally helps when you want to
override what is in the board itself, but having the FDT blob normally
be part of the U-Boot board support allows one new style uImage to be
able to run on any member of a whole family of compatible boards (e.g.
different populated variants such as amount of memory, peripherals, etc
- this info per variant is entered into the FDT blob for the board's
variant).

There also needs to be provision for a "requires" type verb.  For
example, the new uImage blob with a kernel could have "requires
PPC405EP" if it has been built with chip specific optimizations
compatible only with PPC405EP.  If it is loaded onto a PPC405GP based
board, the U-Boot could detect the incompatibility and issue an error
message instead of try to boot the incompatible kernel.  This could also
be used as part of auto selection amongst multiple kernel images if each
image is so tagged and there is also an order of preference (and implied
fallback order).

The 'requires' verb could also be used for a lot of other cool stuff
(e.g. firmware image upgrade / backout schemes), but I think we should
keep it simple, first focusing on what is needed to make boot / no-boot
decisions and perhaps selection of boot arguments.

Regards,

Darcy


--snip!--
Attaches is a draft of proposed bindings for New uImage format.
It's a early RFC, please review and comment.





More information about the U-Boot mailing list