On 11/08/2011 02:17 PM, Wolfgang Denk wrote: > Dear Stephen, > > In message <20111108194433.7c9a013be...@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. -- nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
