[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 Marek,
> 
> On Sat, Nov 5, 2011 at 12:39 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >> 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.
> 
> Stephen's patch set should fix that by allowing an unspecified load address
> .
> 
> So this means that we are fine if we use a zImage, but what about a
> uImage? Are we giving up on that altogether? Stephen's original patch
> on this subject seemed to me to solve the problem with uImage (the one
> he had all the code size grief with).

I'd be more open to adding some kind of a flag to uImage, rather than using 
address 0xffffffff. For this is quite fragile and seems a lot like a hack.
> 
> Can't we commit both of Stephen's patches? It seems to me that they
> solve different problems.

Yes, 1/3 and 2/3 look good.
> 
> Regards,
> Simon
> 
> >> Regards,
> >> Simon