Date: Thu, 28 Feb 2013 08:58:20 -0800 From: Tim Kientzle <kientzle@FreeBSD.org> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: PHYSADDR Message-ID: <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> In-Reply-To: <1362068453.1195.40.camel@revolution.hippie.lan> References: <E886046B-1612-425B-902B-72D4B0E93618@freebsd.org> <1362068453.1195.40.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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=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. 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.) > Where to physically load the kernel has to be specified somewhere. Yes, in the loader. Once the kernel is running, it can look at the PC and see where it was loaded. I'm doubtless oversimplifying, though. ;-) > So how would something like ubldr decide on a physical load address = for > a generic kernel that had, say, zeroes in the paddr and e_entry = fields? I'm not sure yet. > The trampoline code replicates the "loader has empirical knowledge" > problem, because it is in effect another loader. The address at which > the external loader loads the kernel.gz.tramp has nothing to do with = the > address at which the trampoline places the decompressed kernel. Right > now it's another case of the loader (trampoline) bit-twiddling the > virtual addresses from the kernel's elf headers. I'm focusing on the non-trampoline case first. I agree that the trampoline is trickier. > I'm not sure we can completely wish away the trampoline, but I think = we > can define some conventions that ensure its existance is not a barrier > to having a generic kernel, pretty much just by saying so. For = example, > we could require that a kernel have valid physical addresses in the = elf > headers for the trampoline to operate on, and simply state that = generic > kernels designed to be loaded anywhere can't use the trampoline. I would be happy with this if we can't do any better. > I had to put some effort recently into figuring out some of the = perverse > details of how an at91 SoC gets from first-electrons to a running > kernel, and I took notes at the time. I started formatting the notes > into a wiki page, but only got the first half of them cleaned up. > Still, there may be some useful info even if the formatting is rough: >=20 > https://wiki.freebsd.org/FreeBSD/arm/BootProcess Thanks, I'll take a careful look at this. I have a lot of notes about the BeagleBone and RPi boot processes as well. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?674A08B3-6600-4B77-8511-9EF54E4B9B1F>