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

Nicolas Pitre
2011-11-07T21:41:51Z

On Mon, 7 Nov 2011, Stephen Warren wrote:

> (Sigh, resending again to avoid rejected MIME encoding)
>
> On 11/07/2011 01:26 PM, Wolfgang Denk wrote:
> > Dear Stephen Warren,
> >
> > In message <74CDBE0F657A3D45AFBB94109FB122FF173F9A5035@HQMAIL01.nvidia.com> you wrote:
> >> Anyway, I have withdrawn my support for those patches; please don't apply
> >> them. In my opinion, this new solution is far superior because:
> >
> > Argh... So we are back at square one.
> >
> > The problem with this new approach is that Linux kernel images are NOT
> > freely relocatable. They do have a fix entry point, even if this is
> > not an absolute address, but a relative one.

So what? The Linux entry point is always fixed. Relative to the image
payload, it must always be 0.

> That's simply not true ARM Linux zImages /are/ relocatable - as far as
> I'm aware, they can run from anywhere in SDRAM. I've certainly tested
> loading ARM zImages at a few random locations and it works fine, and
> I've been told by senior Linux kernel people that this is intentional.

Exact.

> > The natural way to
> > handle this is exactly that: add support for images with relative
> > )offset based) load and entry point addresses.
> >
> > Your new approahc is indeed simpler - actually it is too simplistic,
> > as you cannot record load address / entry point information any more.
> > It may work when using the kernel wrapper - but what if you don't want
> > to do that?

Only the kernel zImage is relocatable. So only the kernel
zImage should be wrapped into a uImage using the -1 load address flag.
And this solution allows for zImage to be loaded wherever we want
_after_ the uImage encapsulation.

So yes, this is a simplistic solution, but it is damn good, and it
solves the u-Boot restrictions we've been complaining about for at least
two years now.

Therefore, can this patch be merged now? I've provided my ACK for it
already.

Thank you.

Nicolas