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.