Date: Wed, 06 Mar 2013 11:32:24 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: GENERIC kernel issues Message-ID: <1362594744.1291.132.camel@revolution.hippie.lan> In-Reply-To: <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> References: <DF7B73D4-BE50-4E75-8D5B-FE19A4764F31@freebsd.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362594744.1291.132.camel>