From owner-freebsd-arm@FreeBSD.ORG Thu Feb 28 17:44:53 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4D696180; Thu, 28 Feb 2013 17:44:53 +0000 (UTC) (envelope-from tim@kientzle.com) 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 2CB8469E; Thu, 28 Feb 2013 17:44:52 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1SHiqFQ045344; Thu, 28 Feb 2013 17:44:52 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id zvw5avkge3s3wicwgpzqdimp56; Thu, 28 Feb 2013 17:44:52 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1251 From: Tim Kientzle In-Reply-To: <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> Date: Thu, 28 Feb 2013 09:44:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org, Ian Lepore 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 17:44:53 -0000 On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: >=20 > 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. A-ha! I think I just figured something out. How would the following work: * Rename PHYSADDR to KERNPHYSADDR_BASE * in the top of locore.s, we have a single conditional: #ifdef KERNPHYSADDR_BASE _kpa_base =3D KERNPHYSADDR_BASE; #else _kpa_base =3D pc & 0xF0000000; #endif I think this would DTRT on all of the configurations we currently have in SVN. * We redefine KERNPHYSADDR to be an *offset* against _kpa_base. Then we could negotiate a single offset (64k?) that works well on many platforms and use that for the GENERIC kernel. Boot loaders would be responsible for loading the kernel at an address that preserves the KPA_OFFSET. The KPA_OFFSET would be used in the ELF headers. Then there are routine code transformations to use _kpa_base instead of the compile-time symbol and to use _kpa_base + KERNPHYSADDR instead of KERNPHYSADDR. Does this sound reasonable as a starting point? It doesn't solve the trampoline problem, but I'm willing to defer that. Tim