> Hi Marek, > > On Sat, Nov 5, 2011 at 12:39 PM, Marek Vasut <[email protected]> wrote: > >> Hi, > >> > >> On Sat, Nov 5, 2011 at 11:41 AM, Marek Vasut <[email protected]> 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 <[email protected]> > >> > > >> > 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 _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
