Date: Thu, 28 Feb 2013 23:05:44 -0800 From: Tim Kientzle <kientzle@FreeBSD.org> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: PHYSADDR Message-ID: <6B8ECEA1-AC69-4B42-B866-266B8B5208DF@FreeBSD.org> In-Reply-To: <1362100213.1195.88.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=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 say >>> 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 = 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. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6B8ECEA1-AC69-4B42-B866-266B8B5208DF>