From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 18:25:33 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96A81937 for ; Sat, 2 Mar 2013 18:25:33 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by mx1.freebsd.org (Postfix) with ESMTP id 49C93B6B for ; Sat, 2 Mar 2013 18:25:32 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBr7k-000DUR-Ef; Sat, 02 Mar 2013 18:25:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r22IPTX1088808; Sat, 2 Mar 2013 11:25:29 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19kyyBcgRSnWP3WXJmPCqke Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <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> Content-Type: text/plain; charset="us-ascii" Date: Sat, 02 Mar 2013 11:25:29 -0700 Message-ID: <1362248729.1195.189.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 18:25:33 -0000 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