Date: Wed, 6 Mar 2013 09:36:19 -0800 From: Tim Kientzle <kientzle@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@FreeBSD.org, Ian Lepore <ian@FreeBSD.org> Subject: Re: GENERIC kernel issues Message-ID: <A2C41315-A4C3-4BF1-8F7D-31A3D791C05A@FreeBSD.org> 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
>>>>=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. >=20 > 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. >=20 >> 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. >=20 > Right, but can't we get that from the virtual address. >=20 >> 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. >=20 > 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. >=20 > I guess I'm being dense this morning.. I'm not sure I understand what = the big deal is=85 Ian is NOT talking about the kernel here. He's talking about UBLDR, which is an ELF image loaded by U-Boot. The techniques used for the kernel (which we all agree on and which Ian has partly implemented already) don't seem to be applicable here. (I don't want to change U-Boot's ELF loader, nor should UBLDR be messing with the MMU.) So we're stuck for now with linking UBLDR separately for each memory address at which UBLDR gets run. The obvious answer is to have UBLDR be a static PIC binary and not ELF. If you see another approach, I'm interested. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A2C41315-A4C3-4BF1-8F7D-31A3D791C05A>