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

[Wolfgang Denk]

Dear Stephen Warren,

In message <4EB87122.3050602 at nvidia.com> you wrote:
>
> The uncompressed image needs to end up at 32K-from-start-of-SDRAM (or
> whatever SoC-specific value the kernel defines). If U-Boot puts the
> zImage at that same location, the first thing the U-Boot decompressor
> must do is copy the compressed image somewhere else in SDRAM, so that
> when the decompressed kernel is written to 32K (or wherever), it doesn't
> overwrite the compressed image it's decompressing.

Good.

You confirm my understanding that only the zImages are relocatable,
while the raw images are not.

> > 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.
> 
> I keep forgetting that U-Boot typically relocates itself to high memory,
> so the location it runs from initially isn't always relevant.
> 
> Still, this is an optional feature, so I don't think it's good practice
> to rely on it absolutely.

No, this is not an optinal feature. That's how it is supposed to
work, and how it actually works on all ARM systems in mainline
U-Boot.

> As background, this feature is enabled for Tegra20 in the mainline
> U-Boot repository, but not in our internal Tegra30 repositories for
> example. I believe we eventually intend to enable this option for
> Tegra30 too, but there's some bug that causes the relocation to fail at
> the moment.

I cannot and will not comment on out-of-tree code.

> It's the central point of the discussion!
> 
> The issue is: When a distro vendor creates a uImage, can they pick an
> address (be it absolute, relative, or whatever) where the bootm command
> can copy the zImage to, and be 100% guaranteed that address won't
> conflict with U-Boot code, wherever the U-Boot environment loaded the
> initrd, or wherever the U-Boot environment loaded the FDT, or ...?

The chaos results from two systems working against each other: U-Boot
is capable of loading linux kernel images in place and start them, but
instead of letting it do what it can, you load a zImage, which
includes it's own wrapper, copy code, gzip code and all that stuff.

Agreed, that may be useful on simple boot loaders. but in U-Boot it is
not only not useful, it creates all the problems you are complaining
about.

If you just wrap a raw kernel image instead into a uImage (like we for
example do on Power), then you have everythign you want: you can load
the uImage at semi-random addresses in RAM, or you can even directly
boot ir from NOR flash.


> (I honestly feel like I've repeated myself on this point many times. I'm
> not sure how to restate it any differently.)

Repeating the stuff does not make it more convincing to me.

> > So what?  See above - we've been doing this for many, many years
> > already.  This has never been a problem anywhere.  Execpt on ARM.
> 
> It's quite possible that there's more standardization on other
> architectures. I'm not familiar enough with e.g. PPC to know why there
> aren't issues there.

On PPC we simple do not use the image wrapper when building uImages.

It's only ARM that insists it must always only zImages, and everthing
else is inherently bad.  Patches to wrap raw kernel images instead
have been submitted a number of times before (I think starting with
2.4.17 or something like that) but have always been rejected.

Drop the wrapper in uImages, and the problem goes away.

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
I am an atheist, thank God!