Hi Stephen,
On Mon, Nov 7, 2011 at 9:09 AM, Stephen Warren <swar...@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-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.
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?
Regards,
Simon
>
> --
> nvpublic
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
