On Fri, 2011-10-14 at 21:19 +0100, Russell King - ARM Linux wrote: > On Fri, Oct 14, 2011 at 01:16:27PM -0700, Stephen Warren wrote: > > Russell King wrote at Friday, October 14, 2011 2:12 PM: > > > I don't think that's so with the various flavours of platform specific > > > uboot which float around. For instance, on the OMAP4430 SDP, the > > > following commands were used as supplied to load a uImage off the SD > > > card into RAM at a different address to which it was built for, and > > > execute it at that address: > > > > > > mmcinit 0 > > > fatload mmc 0 0x80300000 uImage > > > bootm 80300000 > > > > > > Whether the 'bootm' command then copied the image and called it there, > > > or whether it executed it at 0x80300000 I've no idea - but why then > > > load the image at a different address in the first place? > > > > Yes, U-Boot's image handling looks at the image at 80300000, extracts the > > "load address" from the image header, memcpy()'s the image to that address, > > then jumps to the "entry address" in the image header. > > Ah, so specifying that address is just a total waste of space then, > because you might as well specify an address which results in the > copy not being necessary. > > However, I'd expect that uboot is dumb enough to still do the copy > irrespective of whether its already in the right place. U-Boot doesn't do an unnecessary copy if the body of the image is already at the load address specified in the image header. Unfortunately, it also doesn't do a copy if the header of the image is at the load address, (I guess to support images constructed with an embedded header). This means that fatload mmc 0 0x80300000 uImage bootm 0x80300000 will crash as it will attempt to boot Linux by executing the image header. To successfully boot without requiring a relocation we would need: fatload mmc 0 0x80300000-sizeof(header) uImage bootm 0x80300000 -- Tixy -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
