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

[Stephen Warren]

Simon Glass wrote at Monday, November 07, 2011 12:47 PM:
> On Mon, Nov 7, 2011 at 9:09 AM, Stephen Warren <swarren at 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 at 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.

-- 
nvpublic