Date: Fri, 01 Mar 2013 08:47:31 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Tim Kientzle <kientzle@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: PHYSADDR Message-ID: <1362152851.1195.102.camel@revolution.hippie.lan> In-Reply-To: <6B8ECEA1-AC69-4B42-B866-266B8B5208DF@FreeBSD.org> References: <E886046B-1612-425B-902B-72D4B0E93618@freebsd.org> <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <1362100213.1195.88.camel@revolution.hippie.lan> <6B8ECEA1-AC69-4B42-B866-266B8B5208DF@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2013-02-28 at 23:05 -0800, Tim Kientzle wrote: > On Feb 28, 2013, at 5:10 PM, Ian Lepore wrote: >=20 > > On Thu, 2013-02-28 at 08:58 -0800, Tim Kientzle wrote: > >> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > >>=20 > >>> 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=85 ;-) > >>>>=20 > >>>> First up: Can we get rid of PHYSADDR? > >>>>=20 > >>>=20 > >>> If you mean, can we get rid of it within the runtime kernel, I'd sa= y > >>> yes, because we can use a global variable instead which is easily > >>> settable in the entry code. > >>=20 > >> It doesn't seem to be used in the runtime kernel. As far as > >> I can see, it's purely a bootstrap concept. > >>=20 > >>> On the other hand, I've been working > >>> towards getting that value set correctly in the kernel elf headers = at > >>> link time. > >>=20 > >> 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. > >>=20 > >> 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.) > >>=20 > >=20 > > 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 comm= and > > line and honor the elf headers: >=20 > 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. >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362152851.1195.102.camel>