(Sigh, resending again to avoid rejected MIME encoding) On 11/07/2011 01:26 PM, Wolfgang Denk wrote: > 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.
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. (Well, there is a restriction that the image must be somewhere within the first 128M of RAM for PATCH_PHYS_VIRT(?) to operate correctly, but I'd still count that as been almost arbitrarily relocatable) > 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? Note that the only thing that made my IH_TYPE_*_REL work was this exact same runs-at-any-location feature of ARM zImages; there was never anything in the kernel that allowed it to solely run at "some specific offset from the base of SDRAM"; that was just the first way I thought of modifying U-Boot to enable this current feature. -- nvpublic _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
