Simon Glass wrote at Monday, November 07, 2011 12:47 PM:
On Mon, Nov 7, 2011 at 9:09 AM, Stephen Warren swarren@nvidia.com wrote:
On 11/07/2011 09:56 AM, Stephen Warren wrote:
[Resending in an attempt to avoid base64 encoding]
On 11/05/2011 04:20 PM, Wolfgang Denk wrote:
Dear Stephen Warren,
In message 1320164902-24190-3-git-send-email-swarren@nvidia.com you wrote:
The legacy uImage format includes an absolute load and entry- point address. When presented with a uImage in memory that isn't loaded at the address in the image's load address, U-Boot will relocate the image to its address in the header.
Some payloads can actually be loaded and used at any arbitrary address. An example is an ARM Linux kernel zImage file. This is useful when sharing a single zImage across multiple boards with different memory layouts, or U-Boot builds with different ${load_addr} since sharing a single absolute load address may not be possible.
With this config option enabled, an image header may contain a load address of -1/0xffffffff. This indicates the image can operate at any load address, and U-Boot will avoid automtically copying it anywhere. In this case, the entry-point field is specified relative to the start of the image payload.
Please don't invent a new solution. This has been discussed before, and the agreement was to introduce a new image format where the load and entry point addresses are not absolute, but interpreted as offsets relative to the respectice start of system RAM address.
Your own IH_TYPE_*_REL patches are queued and will be merged soon.
Oh. I kept pushing and pushing on these and kept meeting resistance. I had absolutely no idea at all that there was agreement over those patches; the reviews just stopped happening after you refused to look at them unless I provided U-Boot size information with every possible combination of ifdef locations present/removed.
Anyway, I have withdrawn my support for those patches; please don't apply them. In my opinion, this new solution is far superior because:
a) There's no need to revise mkimage to support this new scheme. Hence, it can be rolled out with just target-size changes, not host-side tool changes (well, a host-side script change is needed, but that's probably far easier than rolling out new mkimage binaries)
b) The implementation of this new scheme is far simpler, and less invasive to the U-Boot code-base, and hence probably far more maintainable.
c) I've validated that the new scheme handles kernel, initrd, and FDT. I never got around to testing a separate FDT image with the old patches
Sorry, and I forgot:
d) This new solution is much more flexible. With IH_TYPE_*_REL, you have to pick some SDRAM-relative address for the uImage load address that's valid across all SoCs the image will be used on. This is easy enough for Tegra20 and Tegra30, but I have no idea what the memory layout is for U-Boot on OMAP, MSM, Exynos, ... I foresee potential difficulty here. With the new scheme, all you say is "this image works /anywhere/; don't copy it." Given the way Linux zImage works, I know this works fine on all those SoCs, and even if it didn't, the U-Boot scripts for those SoCs could arrange for the uImage to be loaded to a SoC-specific address that the zImage /would/ work at.
Fair enough so far as it goes.
But doesn't that mean that we are stuck with zImage and cannot have U-Boot do the decompression?
"Stuck with" isn't really a good description.
zImage is a way of booting ARM Linux. There may be others(?), but zImage is certainly a valid and popular mechanism. I don't see any reason to push against using it; the only real alternative to my patches is a straight-up bootz command rather than anything else, and that also uses zImage.