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

[Wolfgang Denk]

Dear Stephen Warren,

In message <4EB85BF3.8030306 at nvidia.com> you wrote:
>
> 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.

This is you r interpretation. One could also argue that there are
people out there who know only zImage format and don't bother to ask
why other people might want to use different formats.

And it's not just that they don't care - actually they actively block
any such different approaches.


> 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.

But this is actually a non-issue.  See the 
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/115774/focus=115881

If you wrap a zImage, there is a _guarantee_ that such a single
working address exists, but it is not an absolute address, it is
relative to the start of system RAM.  If we chose an offset of 32 KiB
this will work on all systems.

> 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.

I'm missing an explanation why you think a "SDRAM-relative address in
the uImage header doesn't work".   Please elucidate.


> 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

You mean you don't put U-Boot at the end of physical RAM?  Well, I
guess you must have your reasons for deviating from what is considered
standard in mainline.

> 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?

I can understand that you don't have such knowledge.  But I don't see
how this is in any way related with the topic we're discussing here?

> 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.

It appears ARM is the only architecture to ever have such a problem.
For everybody else this has been working without any problems for
over a decade.

> 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

So what?  See above - we've been doing this for many, many years
already.  This has never been a problem anywhere.  Execpt on ARM.

> 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.

We are discussing to introduce a new feature here.  No matter what the
outcome is, the then new interface between U-Boot and Linux should be
properly documented.  As far as I understand (see above) we can even
have some kind of common standard (at least for all the cases that are
willing to accept the limitations of the zImage approach; and even for
those preferring to wrap raw images there would be a semi-standard on
all except of 3 pretty much irrelevant processors).  A distro vendor
would be well advised to just follow that standard, then.  And users
would be able know that there is auch a standard.

Umm... what exactly was your problem?

> 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

I don't understand you.  Above you complain that people might "changed
their scripts" in ways incompatible with the given uImages (and note
that a simple "iminfo" command will actually display the image
properties), and here you cite it as an advantage that they can
"write[s]/hack[s] the U-Boot scripts".

If somebody does that, he needs an understanding of the memory map of
the system, of the images (kernel, initrd, DTB) they are loading, and
(in the case of zImage) about the exact behaviour of the kernel
wrapper when unpacking / relocating the kernel code.

Do you really claim that people with that understanding are not
capable of dealing with relative uImages?  If yes, why would that be
the case?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Given a choice between two theories, take the one which is funnier.