From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 16:58:21 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9E04C54A; Thu, 28 Feb 2013 16:58:21 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 724DC1BA; Thu, 28 Feb 2013 16:58:21 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1SGwLXE045001; Thu, 28 Feb 2013 16:58:21 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id rx2vkwj6pqjrkizzud5jivht4a; Thu, 28 Feb 2013 16:58:21 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <1362068453.1195.40.camel@revolution.hippie.lan> Date: Thu, 28 Feb 2013 08:58:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> References: <1362068453.1195.40.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 16:58:21 -0000 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