Date: Wed, 6 Mar 2013 10:51:45 -0700 From: Warner Losh <imp@bsdimp.com> To: Tim Kientzle <kientzle@FreeBSD.org> Cc: freebsd-arm@FreeBSD.org, Ian Lepore <ian@FreeBSD.org> Subject: Re: GENERIC kernel issues Message-ID: <E41D383B-6A8B-4C82-8FF6-C0753CD142DD@bsdimp.com> In-Reply-To: <A2C41315-A4C3-4BF1-8F7D-31A3D791C05A@FreeBSD.org> 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> <A2C41315-A4C3-4BF1-8F7D-31A3D791C05A@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 6, 2013, at 10:36 AM, Tim Kientzle wrote: >>>>>=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 >=20 > Ian is NOT talking about the kernel here. >=20 > He's talking about UBLDR, which is an ELF image > loaded by U-Boot. >=20 > 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.) >=20 > 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. OK. I'm back with you now, and I agree. ubldr does run in PA, and what = I've said don't apply... Unless we make ubldr PIC, so I think we're on = the same page here... We could create our own mapping, but we'd have to totally trash that = just before jumping to the kernel, which I'm at best luke warm to since = that kind of code has to be in assembler... I think that static PIC = binary would be easier... Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E41D383B-6A8B-4C82-8FF6-C0753CD142DD>