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. 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. -- nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot