[U-Boot] [PATCH v2 1/3] image: Make image_get_fdt work like image_get_{ram_disk, kernel}

[Marek Vasut <marek.vasut@gmail.com>]

> Hi,
> 
> On Sat, Nov 5, 2011 at 11:41 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> image_get_ram_disk() and image_get_kernel() perform operations in a
> >> consistent order. Modify image_get_fdt() to do things the same way.
> >> This allows a later change to insert some image header manipulations
> >> into these three functions in a consistent fashion.
> >> 
> >> v2: New patch
> >> 
> >> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> > 
> > Hi Stephen,
> > 
> > this patchset is good and all, but can we not also introduce cmd_zload to
> > load zImages? Wolfgang, today's ARM hardware will really benefit from
> > that, uImage holds us back a lot these days. Other option is to extend
> > cmd_bootm() to load zImages.
> > 
> > Cheers
> 
> Just a quick Q. What is the ultimate intent here? Should we be aiming
> to have U-Boot copy and decompress the data into RAM ready for Linux?

Nope, not at all. We have a problem with booting linux images which support 
multiple different SoCs (because the RAM might be elsewhere for different SoCs).

> In theory this should be slightly faster since U-Boot already has the
> data in its cache. I think zImage now supports having an FDT inside
> but what is the advantage of zImage over a uImage with compressed
> portions?

That's not the point. We need to load FDT, load zImage, setup the regs and boot 
it from where we load the zImage. The uImage envelope contains fixed address to 
where the kernel image is loaded, which interferes with kernel's runtime 
patching of the kernel base address (zreladdr).

Basically kernel can be loaded to address A1 on one SoC, address A2 on different 
SoC, but in the old times, the kernel had to be linked to a predefined address. 
That's not true anymore. Now if kernel is loaded to address A1, it adjusts 
itself and runs from A1, so for A2 etc.

uImage blocks this because it forces u-boot to copy zImage to fixed address.
> 
> Regards,
> Simon