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

[Marek Vasut <marek.vasut@gmail.com>]

> 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