[U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address

[Stephen Warren <swarren@nvidia.com>]

[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

> I do not see the need for yet another implementation for the very same
> thing, so NAK.

-- 
nvpublic