Date: Sat, 2 Mar 2013 16:15:08 -0700 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm@FreeBSD.org Subject: Re: PHYSADDR Message-ID: <07E4A3AF-DC56-4BD6-B564-3370C9716329@bsdimp.com> In-Reply-To: <1362246634.1195.178.camel@revolution.hippie.lan> References: <E886046B-1612-425B-902B-72D4B0E93618@freebsd.org> <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 2, 2013, at 10:50 AM, Ian Lepore wrote: > I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the > beginning of the kernel; it's true now but need not be so. But that's > no big deal, we can tweak the linker script to give us the offset of = the > _start symbol so it'll work no matter what. We have total control over this, since we control the linker script that = puts locore.S at the front. > The more I ponder the fixed offset concept for a generic kernel the = more > it seems that it might be viable, providing that we require the use of > ubldr. Then we can make sure that ubldr is always linked at an offset > that doesn't overlap the kernel load offset. An offset number like = 1mb > or 4mb might work well for the kernel; it leaves lots of space for = ubldr > to be loaded down low in memory. I think putting the loader at a = lower > address than the kernel is required, because there's no upper bound on > the kernel size (I did a 27MB kernel last month -- it contains a huge > embedded md filesystem image). >=20 > This just pushes the real problem into ubldr, though, and that becomes > the non-generic component that has to be linked at a different = physical > address for each SoC. A kernel could still be loaded without ubldr, = but > it may need to be built in a non-generic way for some platforms. Why not compile ubldr -pic? Then it wouldn't matter where we get loaded, = we'll work... > So if we declare that this scheme is for generic kernels loaded by a > loader (ubldr or other) that is aware of the generic kernel scheme, > there's no need for the physical address fields in the elf headers to = be > interpretted as a real physical address that would work for a standard > elf loader. You can build kernels that work with a standard elf = loader, > but the generic kernel is not such a thing. =20 Correct. BTW, what do latter-day universal-boot linux kernels do? > In that case, the physical address and entry address fields in the > headers are all offsets. If physical ram on a given chip starts at > zero, then the headers would accidentally be right for a standard elf > loader. Otherwise the generic-aware loader is responsible for filling > in some high-order bits when interpretting the headers. >=20 > The PHYSADDR symbol (and its several name variations) at build time = now > becomes zero for a generic kernel or non-zero to generate a = SoC-specific > kernel that can be loaded by a standard elf loader. The symbol = doesn't > exist at all in the compilation, it's used only by the build system = and > is passed as a parameter to the linker. >=20 > There's another problem constant we haven't talked about yet: > STARTUP_PAGETABLE_ADDR, used by locore to build the early page tables. > It's the absolute physical address of an area of memory that doesn't > have any other important data in it, and won't get overwritten by > something before initarm() builds the real page tables. I think most > SoCs now put it way up high in memory "safely out of the way", but = that > won't work generically. We need 16K aligned to a 16K boundary, and > maybe it would work to use the area immediately preceeding the start = of > the kernel. We could require the kernel to be linked on a 16k = boundary > so that we can just blindly subtract 16K from the starting physaddr we > calculate; nice and easy. Maybe have ubldr responsible for this? And if you aren't booting with = ubldr using a custom loader, you're already into the land of unique = kernel build anyway, and can wire it there... Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?07E4A3AF-DC56-4BD6-B564-3370C9716329>