From owner-freebsd-arm@FreeBSD.ORG Fri Mar 1 15:47:35 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99B4236D; Fri, 1 Mar 2013 15:47:35 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 5ECED66B; Fri, 1 Mar 2013 15:47:34 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UBSBK-000O1w-5c; Fri, 01 Mar 2013 15:47:34 +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 r21FlVEm086995; Fri, 1 Mar 2013 08:47:31 -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: U2FsdGVkX1+72menvMZLYT7uz3wq0Q37 Subject: Re: PHYSADDR From: Ian Lepore To: Tim Kientzle In-Reply-To: <6B8ECEA1-AC69-4B42-B866-266B8B5208DF@FreeBSD.org> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <1362100213.1195.88.camel@revolution.hippie.lan> <6B8ECEA1-AC69-4B42-B866-266B8B5208DF@FreeBSD.org> Content-Type: text/plain; charset="windows-1251" Date: Fri, 01 Mar 2013 08:47:31 -0700 Message-ID: <1362152851.1195.102.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by damnhippie.dyndns.org id r21FlVEm086995 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: Fri, 01 Mar 2013 15:47:35 -0000 On Thu, 2013-02-28 at 23:05 -0800, Tim Kientzle wrote: > On Feb 28, 2013, at 5:10 PM, Ian Lepore wrote: >=20 > > On Thu, 2013-02-28 at 08:58 -0800, Tim Kientzle wrote: > >> On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > >>=20 > >>> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > >>>> Starting to look at what is needed for a Generic ARM kernel. > >>>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) > >>>>=20 > >>>> First up: Can we get rid of PHYSADDR? > >>>>=20 > >>>=20 > >>> If you mean, can we get rid of it within the runtime kernel, I'd sa= y > >>> yes, because we can use a global variable instead which is easily > >>> settable in the entry code. > >>=20 > >> It doesn't seem to be used in the runtime kernel. As far as > >> I can see, it's purely a bootstrap concept. > >>=20 > >>> On the other hand, I've been working > >>> towards getting that value set correctly in the kernel elf headers = at > >>> link time. > >>=20 > >> My question really boils down to whether PIC techniques > >> are sufficient for the early bootstrap stage to determine > >> where the kernel is currently executing and use that to > >> drive the initial MMU bring up. I've just started, but > >> the PHYSADDR uses I've examined can be replaced > >> with PIC techniques. But this part of the code is > >> pretty involved and riddled with conditional compilations, > >> so it will be slow going. > >>=20 > >> I was impressed to find that ubldr seems to be PIC. > >> I've run the same binary at different load addresses > >> and so far it "just works." (I didn't think it would work, > >> so I was surprised by this. I haven't dug through to > >> figure out why it works yet.) > >>=20 > >=20 > > I was suprised by this paragraph, and I've just done some testing and= I > > wonder if it's really running at different addresses, because I can't > > make it do so without relinking it at that address. To test, I saved > > the entry PC in uboot/start.S and printed it in main (patch below). = No > > matter where I tell u-boot to load ubldr, it seems to ignore the comm= and > > line and honor the elf headers: >=20 > I'm testing on Raspberry Pi, whose initial memory map is > from 0x000000000 - 0x20000000 and BeagleBone, whose > initial memory map is 0x80000000 - 0x90000000, so there's > no way that ubldr can be getting copied to the same address > on both platforms. >=20 > I'll have to go back and repeat my tests, because something > is clearly not making sense here. Yeah, something's not right. I've never gotten ubldr to work on my BB at all, I just directly load the kernel from u-boot. Getting ubldr going was on my to-do list, so I just played with it now. u-boot says it loads ubldr to 0x82000000, then when I 'bootelf' it just hangs. If I re-link ubldr for an address in the 0x80000000+ range it loads and launches just fine (but then fails to load the kernel via the network, but that's just an unrelated problem I think). What does a "readelf -l" show for your ubldr? Is there any difference in what it shows between the ones built for rpi and bb in your setup? (I don't use your build scripts.) -- Ian