Dear Nicolas,
In message alpine.LFD.2.02.1111071633330.3307@xanadu.home you wrote:
So yes, this is a simplistic solution, but it is damn good, and it solves the u-Boot restrictions we've been complaining about for at least two years now.
Could you please explain which of these restrictions cannot be solved by using the IH_TYPE_*_REL approach?
I just explained (see http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/115774/focus=115881) why I consider this a better approch than Stephen's new patches.
There are other reasons why we do want to have support for uImage format. Just one example: the length information in the image header comes in very handy when you go for very fast booting systems - here the U-Boot SPL code can load and start Linux directly, bypassing all the normale U-Boot loading and initialization. And you can boot the very same image normally as well. With zImage, you would again have to provide additional information, probably be defining yet another header format. OK, such super-fast booting systems are only a tiny fraction of the systems in the field, but...
Therefore, can this patch be merged now? I've provided my ACK for it already.
And I NAKed it already. Twice, actually.
I am still willing to reconsider this NAK, but I am asking for really convincing arguments why the IH_TYPE_*_REL approach would be less useful.
Thanks.
Wolfgang Denk