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