Hi Marek, On Sat, Nov 5, 2011 at 1:41 PM, Marek Vasut <marek.va...@gmail.com> wrote: >> Hi Marek, >> >> On Sat, Nov 5, 2011 at 12:39 PM, Marek Vasut <marek.va...@gmail.com> wrote: >> >> Hi, >> >> >> >> On Sat, Nov 5, 2011 at 11:41 AM, Marek Vasut <marek.va...@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 <swar...@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 > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
