[U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address

[Stephen Warren <swarren@nvidia.com>]

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.

-- 
nvpublic