PHYSADDR

[Ian Lepore]

On Sat, 2013-03-02 at 10:10 -0800, Tim Kientzle wrote:
> On Mar 2, 2013, at 9:50 AM, Ian Lepore wrote:
> 
[...]
> 
> > We may not have control over anything before ubldr.  Not everything is
> > an eval board that you can easily build a custom u-boot for.  
> 
> Yep.  Full agreement here.
> 
> 
> > I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the
> > beginning of the kernel; it's true now but need not be so.  But that's
> > no big deal, we can tweak the linker script to give us the offset of the
> > _start symbol so it'll work no matter what.
> 
> Patches?  ;-)
> 

Forthcoming, if I could stop talking on irc and email long enough to
finish them. :) I started playing with it yesterday enough to be sure it
was doable.

> > The more I ponder the fixed offset concept for a generic kernel the more
> > it seems that it might be viable, providing that we require the use of
> > ubldr.  Then we can make sure that ubldr is always linked at an offset
> > that doesn't overlap the kernel load offset.  An offset number like 1mb
> > or 4mb might work well for the kernel; it leaves lots of space for ubldr
> > to be loaded down low in memory.  I think putting the loader at a lower
> > address than the kernel is required, because there's no upper bound on
> > the kernel size (I did a 27MB kernel last month -- it contains a huge
> > embedded md filesystem image).
> 
> Thanks for pointing this out.  I've been consistently putting ubldr
> in high memory but hadn't realized kernels varied that much in
> size.  I'll rethink that.
> 
> > This just pushes the real problem into ubldr, though, and that becomes
> > the non-generic component that has to be linked at a different physical
> > address for each SoC.  A kernel could still be loaded without ubldr, but
> > it may need to be built in a non-generic way for some platforms.
> 
> Among the many things I'd like to try:  see if there's a way to build
> ubldr as a PIC raw binary (instead of an ELF image).  That might
> help in a lot of case.
> 

I think the only way this works is to write a relocation-fixup
trampoline for ubldr.  I'm 15 years outdated on toolchain stuff, but I
think the two ways this could go would be something like a small custom
runtime loader and the bulk of ubldr is a .so file that it loads (they
could be bound together in a multi-segment elf file I think), or we
continue with the current -static link but do a partial link or prelink
that leaves relocation info in the image so that some trampoline code
could walk the reloc list patching up offsets into absolute addresses.

-- Ian