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

Can't we commit both of Stephen's patches? It seems to me that they
solve different problems.

Regards,
Simon

>>
>> Regards,
>> Simon
>