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