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

[Stephen Warren]

On 11/07/2011 03:11 PM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <74CDBE0F657A3D45AFBB94109FB122FF173F9A51AC at HQMAIL01.nvidia.com> you wrote:
>>
>> "Stuck with" isn't really a good description.
> 
> It is, IMO.
> 
>> 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
> 
> Well, and uImage is the way of booting any OS on any architecture in
> U-Boot.  It's certainly a valid and popular mechanism.

I agree (well, /a/ way, not /the/ way).

I think the difference here is that I get the impression that people
within the U-Boot community would like to do away with zImage in general
and replace it with uImage, which simply isn't plausible, whereas I'm
perfectly happy for uImage to continue to exist, sometimes as a
container for zImage, potentially a container for something else
entirely, simply depending on what people want to put in there.

> I think a discussion on such a base is not exactly constructive.

But yes, use of zImage in the first place is tangential. People
definitely need/want to use zImage, and I think they should be allowed
to, and I'm just trying to eliminate some pain points when embedding an
ARM zImage within a uImage.

> What exactly is wrong with the use of relative (offset) addresses?
> 
> And what made you change your mind?

I mentioned this before.

The fundamental problem with uImage having an absolute load address is
that there may be no single absolute address that is usable as SDRAM
across all ARM SoCs which may be supported by a single ARM Linux kernel.
This is the basic problem I tried to solve with both my patch sets.

The reason that placing an SDRAM-relative address in the uImage header
doesn't work is fundamentally the same reason, just driven by SW rather
than HW memory maps.

People build U-Boot to load/run at all kinds of different addresses;
even within NVIDIA we're currently using 0x00e08000 for mainline U-Boot,
but would rather use 0x00108000 to fit better with our flashing tools. I
have no idea what random addresses U-Boot is typically built for on
OMAP, MSM, Exynos, or any other SoC. And this is just U-Boot; what about
all the default (or end-user-custom) scripts that U-Boot executes; how
do I know what ${loadaddr} is on every single U-boot installation, for
each of kernel, initrd, FDT?

Given this, I'm no longer totally convinced that it's possible to pick
some location in SDRAM (even specified relative rather absolute) where I
can guarantee the kernel can reside.

Note that this location is something a distro vendor would have to pick
when creating their distro kernel uImage, but end-users would expect
that uImage to work irrespective of how they've hacked their U-Boot
scripts - maybe they've changed their scripts to load the initrd or FDT
to the place location the distro vendor assumed was free for the kernel.
Maybe it isn't reasonable for users to expect this, but avoiding the
need to pick such a location will reduce distro's support costs.

Instead, with a "-1" load address meaning "don't copy the kernel" as in
my most recent patches, all we care about is that the U-Boot scripts
load the kernel somewhere that doesn't overlap with where the initrd or
FDT were loaded (or where U-Boot's code is). The decision point for this
address is whoever writes/hacks the U-Boot scripts for the board. this
is much more decentralized; the distro vendor doesn't have to make this
decision, but rather it'd deferred to whatever the end-user or board
maintainer picks in their U-Boot scripts. Much more flexible, much less
risk of conflict, and any problems should be visible to the person who
caused the problem, not the distro vendor.

-- 
nvpublic