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

[Simon Glass]

Hi Marek,

On Sat, Nov 5, 2011 at 1:41 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
>> Hi Marek,
>>
>> On Sat, Nov 5, 2011 at 12:39 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
>> >> Hi,
>> >>
>> >> On Sat, Nov 5, 2011 at 11:41 AM, Marek Vasut <marek.vasut at 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 at 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.

Possibly, but at least it makes it very clear that the load address
should not be used.

>>
>> 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.

Actually I meant both series, sorry. The previous series enhanced
uImage to understand an image that can go anywhere, and I think that
is useful also. In both series, a load address of -1 means 'ignore
it'.

Regards,
Simon


>>
>> Regards,
>> Simon
>>
>> >> Regards,
>> >> Simon
>