> On 11/07/2011 02:04 PM, Marek Vasut wrote: > ... > > >> The problem with this new approach is that Linux kernel images are NOT > >> freely relocatable. They do have a fix entry point, even if this is > >> not an absolute address, but a relative one. The natural way to > >> handle this is exactly that: add support for images with relative > >> )offset based) load and entry point addresses. > > > > You have that runtime patching stuff in linux-arm-kernel now, there > > should be no problem with that anymore actually. So basically I > > understood there was an agreement to make special uImage/fitImage which > > ... oh doh, here is where I'm getting lost. Is it that the kernel will > > still be copied to address, but a relative one to where uImage is loaded > > -- and the entrypoint will be relative to that same address? > > U-Boot scripts load uImages to some script-defined address. > > (At least for kernel images) when running the bootm command, U-Boot will > then copy the kernel image from whatever place the script loaded it to > whatever value the "load address" uImage header field contains. > > With my first set of patches, I created IH_TYPE_KERNEL_REL (as a pair to > IH_TYPE_KERNEL) where the load address in the header is not an absolute > address, but rather is interpreted as an offset from "the start of > SDRAM", whatever that is for a particular board. The idea was that while > there could not be a single absolute load address that was valid for all > ARM SoCs, perhaps there could be a single offset from SDRAM that was > valid for all ARM SoCs. With this scheme, U-Boot's bootm command would > still perform the same copy I mentioned above. This applied equally to > "legacy" uImages and FIT images. > > With the new set of patches I posted, I didn't add any new uImage > formats, but instead defined a single load address value (0xffffffff) as > meaning "no load address specified", or "load address irrelevant". In > this case, when bootm processes the kernel image, it re-writes the load > address of the image to be equal to wherever the script actually ended > up loading the image. Hence, the kernel image is already in the desired > location, and the copy of the kernel is avoided.
But the kernel ends at offset where uImage was loaded to + few bytes (sizeof(uImage header)), right? > In my opinion, the new scheme is simpler, more correct, more flexible, > more efficient (fewer copies of the kernel data)..., for the reasons I > mentioned a couple emails back. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot