On 11/08/2011 02:17 PM, Wolfgang Denk wrote:
Dear Stephen,
In message 20111108194433.7C9A013BE0C5@gemini.denx.de I wrote:
Are you willing to entertain extending bootm to recognize a third image format if this makes the patches less invasive, and/or leads to more maintainable code?
I have to admit that I don't like the idea, but I will not argue over hard facts. But please keep in mind that bootz support shall be a configuration option, that can be selected or omittet at build time. My feeling is that this would require quite a number of new #ifdef's if you try to add it into the existing code.
Thinking about this again I wonder if this is really what is needed. Why do we need a third image format?
What would happen if we just create a new image type IH_TYPE_ZIMAGE?
That would cover the kernel uImage case. We'd also need a new image type for "use in place" FDTs, since that also gets relocated to the image load address before use. I think initrds don't for some reason.
The advantage of using a -1 load address was that it avoided a proliferation of new IH_TYPE_* values, and an associated requirement for everyone to update their mkimage tool.
Another advantage of directly recognizing non-uImage-wrapper zImage, initrd, and FDT (in either bootm or bootz), is that distros wouldn't have to run mkimage ever; they could just dump the kernel in e.g. /boot/zImage (plus say /boot/initrd.img and /boot/fdt.bin), and expect U-Boot to pick it up and use it without any further processing. This would isolate more of the distro kernel install scripts from U-Boot, and keep them generic.
...
For the sake of consistency, such images should be built with IH_COMP_NONE, then.
Certainly.