Date: Wed, 6 Mar 2013 10:03:24 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org Subject: Re: GENERIC kernel issues Message-ID: <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> In-Reply-To: <1362542286.1291.94.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: > On Mon, 2013-03-04 at 21:30 -0700, Warner Losh wrote:=20 >> On Mar 4, 2013, at 6:09 PM, Ian Lepore wrote: >>> On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote: >>>>=20 >>>> ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a >>>> lot of progress and I'm working on some related changes to >>>> address this. I think we understand how to eliminate these >>>> constants and replace them with run-time detection of the >>>> load address. I'm still not sure what changes might be needed >>>> to the loader to make this work.=20 >>>=20 >>> I don't think anything more needs to be done to the loader to be = able to >>> load a kernel built with the ldscript changes, beyond the change I = did a >>> week or two ago to make it work right with elf headers that contain >>> physical addresses. >>>=20 >>> On the other hand, I haven't got anything to offer on the problem of = the >>> loader needing to be linked differently for each board or SoC, since >>> they all have physical memory in differing address ranges. >>=20 >> Well, the Phyiscal memory load address is just a hint after all. Any = way to leave it blank and have ubldr cope by putting it in the first = available phyiscal memory slot from the FDT? >>=20 >> Warner >>=20 >=20 > It's not just a hint, the executable is linked to run at that address > and no other. There is no relocation info in the file at all. That's > true of both the kernel and ubldr. It's also true of any old > static-linked executable, but in that case the object is just mapped = at > the virtual address it's linked for by the kern/imgact_elf.c code. It is just a hint, since we can load it at any physical address. Well, = almost any. But we can get the almost from the virtual part. > 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. > Unfortunately, I don't think we can pull the same kind of trick with > ubldr. In locore.s for the kernel we build simple page tables which = are > just enough to get us to the code in initarm() that builds them for > real. No SoC-specific stuff has to happen along the way (or if it = does, > SoC-specific code is invoked via various hooks to board support > routines). In ubldr we mess with the hardware (via the u-boot = drivers), > so if we turn on the MMU to map the memory ubldr is running from, we > also have to map the hardware va=3Dpa for those drivers to work. I = don't > know that there's any way to get the needed info for that from u-boot. So long as the code is PIC up until the time we turn on the MMU, then = we're fine. We can and should still do this in locore.S. I guess I'm being dense this morning.. I'm not sure I understand what = the big deal is... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F>