Date: Sat, 02 Mar 2013 11:25:29 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: PHYSADDR Message-ID: <1362248729.1195.189.camel@revolution.hippie.lan> In-Reply-To: <AC642AAD-8D8C-429E-AE3B-A34241DA2517@kientzle.com> 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> <AC642AAD-8D8C-429E-AE3B-A34241DA2517@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2013-03-02 at 10:10 -0800, Tim Kientzle wrote: > On Mar 2, 2013, at 9:50 AM, Ian Lepore wrote: > [...] > > > We may not have control over anything before ubldr. Not everything is > > an eval board that you can easily build a custom u-boot for. > > Yep. Full agreement here. > > > > 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. > > Patches? ;-) > Forthcoming, if I could stop talking on irc and email long enough to finish them. :) I started playing with it yesterday enough to be sure it was doable. > > 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). > > Thanks for pointing this out. I've been consistently putting ubldr > in high memory but hadn't realized kernels varied that much in > size. I'll rethink that. > > > 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. > > Among the many things I'd like to try: see if there's a way to build > ubldr as a PIC raw binary (instead of an ELF image). That might > help in a lot of case. > I think the only way this works is to write a relocation-fixup trampoline for ubldr. I'm 15 years outdated on toolchain stuff, but I think the two ways this could go would be something like a small custom runtime loader and the bulk of ubldr is a .so file that it loads (they could be bound together in a multi-segment elf file I think), or we continue with the current -static link but do a partial link or prelink that leaves relocation info in the image so that some trampoline code could walk the reloc list patching up offsets into absolute addresses. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362248729.1195.189.camel>