> Dear Stephen Warren, > > In message <74cdbe0f657a3d45afbb94109fb122ff173f9a5...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
