From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 21:56:54 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 465A29D8 for ; Wed, 6 Mar 2013 21:56:54 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5E6AC7 for ; Wed, 6 Mar 2013 21:56:53 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UDJ8d-0008rh-7h; Wed, 06 Mar 2013 18:32:27 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r26IWOvZ003334; Wed, 6 Mar 2013 11:32:24 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18VrC1G1My8FKfSBUJeLec6 Subject: Re: GENERIC kernel issues From: Ian Lepore To: Warner Losh In-Reply-To: <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Mar 2013 11:32:24 -0700 Message-ID: <1362594744.1291.132.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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: Wed, 06 Mar 2013 21:56:54 -0000 On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote: > On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: [...] > > We essentially pull off the same mapping trick with the kernel, except > > that very early in locore.s the code is carefully crafted to work right > > whether on physical or virtual addressing, just long enough to get the > > MMU turned off. Then it sets up page tables to map the physical pages > > the kernel has been loaded into to match the virtual addresses it was > > linked for. All of that only works if the low-order bits of the virtual > > address it was linked for match the physical address it was loaded at. > > That is, if linked for 0xC0001000 it must be loaded at 0xNNNN1000 > > physical, where the N bits can be anything. > > Right, but can't we get that from the virtual address. Not always. You can always figure out the right virtual address if you have the physical (you just OR-in 0xC0000000), but you can't always go the other way. If all you know is 0xC0010000 you have no idea whether the underlying physical address might be 0x00010000 or 0x80010000. Our current code that assumes you can do phys=pc&0xf0000000 is wrong for the same reason (but has been working okay by accident). That's part of why I've been working towards getting our arm ldscript to put proper physical addresses in the elf headers instead of virtual, in the fields that are supposed to have phsyical addresses in them (entry and program-header paddr fields). With this scheme SoC-specific kernels will be linked with PHYSADDR= the real physical address and can be loaded by any standard elf loader because the headers are correct. A generic kernel will be linked with PHYSADDR=offset where offset is just the low-order part of the address and ubldr can load the kernel into whatever physical memory is available as long as the offset part stays the same. -- Ian