PHYSADDR

[Ian Lepore]

On Thu, 2013-02-28 at 23:05 -0800, Tim Kientzle wrote:
> On Feb 28, 2013, at 5:10 PM, Ian Lepore wrote:
> 
> > On Thu, 2013-02-28 at 08:58 -0800, Tim Kientzle wrote:
> >> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote:
> >> 
> >>> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote:
> >>>> Starting to look at what is needed for a Generic ARM kernel.
> >>>> There's a lot here; I sincerely hope I'm not the only one… ;-)
> >>>> 
> >>>> First up:  Can we get rid of PHYSADDR?
> >>>> 
> >>> 
> >>> If you mean, can we get rid of it within the runtime kernel, I'd say
> >>> yes, because we can use a global variable instead which is easily
> >>> settable in the entry code.
> >> 
> >> It doesn't seem to be used in the runtime kernel.  As far as
> >> I can see, it's purely a bootstrap concept.
> >> 
> >>> On the other hand, I've been working
> >>> towards getting that value set correctly in the kernel elf headers at
> >>> link time.
> >> 
> >> My question really boils down to whether PIC techniques
> >> are sufficient for the early bootstrap stage to determine
> >> where the kernel is currently executing and use that to
> >> drive the initial MMU bring up.  I've just started, but
> >> the PHYSADDR uses I've examined can be replaced
> >> with PIC techniques.  But this part of the code is
> >> pretty involved and riddled with conditional compilations,
> >> so it will be slow going.
> >> 
> >> I was impressed to find that ubldr seems to be PIC.
> >> I've run the same binary at different load addresses
> >> and so far it "just works."  (I didn't think it would work,
> >> so I was surprised by this.  I haven't dug through to
> >> figure out why it works yet.)
> >> 
> > 
> > I was suprised by this paragraph, and I've just done some testing and I
> > wonder if it's really running at different addresses, because I can't
> > make it do so without relinking it at that address.  To test, I saved
> > the entry PC in uboot/start.S and printed it in main (patch below).  No
> > matter where I tell u-boot to load ubldr, it seems to ignore the command
> > line and honor the elf headers:
> 
> I'm testing on Raspberry Pi, whose initial memory map is
> from 0x000000000 - 0x20000000 and BeagleBone, whose
> initial memory map is 0x80000000 - 0x90000000, so there's
> no way that ubldr can be getting copied to the same address
> on both platforms.
> 
> I'll have to go back and repeat my tests, because something
> is clearly not making sense here.

Yeah, something's not right.  I've never gotten ubldr to work on my BB
at all, I just directly load the kernel from u-boot.  Getting ubldr
going was on my to-do list, so I just played with it now.

u-boot says it loads ubldr to 0x82000000, then when I 'bootelf' it just
hangs.  If I re-link ubldr for an address in the 0x80000000+ range it
loads and launches just fine (but then fails to load the kernel via the
network, but that's just an unrelated problem I think).

What does a "readelf -l" show for your ubldr?  Is there any difference
in what it shows between the ones built for rpi and bb in your setup?
(I don't use your build scripts.)

-- Ian