On Mon, 7 Nov 2011, Stephen Warren wrote: > (Sigh, resending again to avoid rejected MIME encoding) > > On 11/07/2011 01:26 PM, Wolfgang Denk wrote: > > Dear Stephen Warren, > > > > In message <[email protected]> > > you wrote: > >> 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.
So what? The Linux entry point is always fixed. Relative to the image payload, it must always be 0. > 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. Exact. > > 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? Only the kernel zImage is relocatable. So only the kernel zImage should be wrapped into a uImage using the -1 load address flag. And this solution allows for zImage to be loaded wherever we want _after_ the uImage encapsulation. So yes, this is a simplistic solution, but it is damn good, and it solves the u-Boot restrictions we've been complaining about for at least two years now. Therefore, can this patch be merged now? I've provided my ACK for it already. Thank you. Nicolas _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
