Date: Tue, 05 Mar 2013 20:58:06 -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: <1362542286.1291.94.camel@revolution.hippie.lan> In-Reply-To: <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> References: <DF7B73D4-BE50-4E75-8D5B-FE19A4764F31@freebsd.org> <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2013-03-04 at 21:30 -0700, Warner Losh wrote: > On Mar 4, 2013, at 6:09 PM, Ian Lepore wrote: > > On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote: > >> > >> ** 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. > > > > 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. > > > > 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. > > 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? > > Warner > 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. 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. 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=pa for those drivers to work. I don't know that there's any way to get the needed info for that from u-boot. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362542286.1291.94.camel>