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

Marek Vasut
2011-11-07T21:04:41Z

> Dear Stephen Warren,
>
> In message <74CDBE0F657A3D45AFBB94109FB122FF173F9A5035@HQMAIL01.nvidia.com>
you wrote:
> > > 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
>
> There was no resistance ever. There were just the normal review
> comments.
>
> > 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
>
> If there are no further complaints that usually menas the stuff is
> sitting in the queue waiting to be processed. Sorry, but my bandwidth
> _is_ limited.
>
> > 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. The natural way to
> handle this is exactly that: add support for images with relative
> )offset based) load and entry point addresses.

You have that runtime patching stuff in linux-arm-kernel now, there should be no
problem with that anymore actually. So basically I understood there was an
agreement to make special uImage/fitImage which ... oh doh, here is where I'm
getting lost. Is it that the kernel will still be copied to address, but a
relative one to where uImage is loaded -- and the entrypoint will be relative to
that same address?

>
> 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?
>
> > > I do not see the need for yet another implementation for the very same
> > > thing, so NAK.
>
> The NAK remains. The new code will not go in.
>
> Best regards,
>
> Wolfgang Denk

Cheers