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