From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 17:59:00 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 7345DD0B; Tue, 19 Feb 2013 17:59:00 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1C7C69F9; Tue, 19 Feb 2013 17:58:59 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.6/8.14.6) with ESMTP id r1JHwxRo007031; Tue, 19 Feb 2013 10:58:59 -0700 (MST) (envelope-from ian@FreeBSD.org) 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 r1JHwuMY050113; Tue, 19 Feb 2013 10:58:56 -0700 (MST) (envelope-from ian@FreeBSD.org) Subject: Re: RPi hangs in bootloader From: Ian Lepore To: Tim Kientzle In-Reply-To: References: <51227033.3070304@thieprojects.ch> <1361235912.1164.55.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Feb 2013 10:58:56 -0700 Message-ID: <1361296736.1164.75.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: Tue, 19 Feb 2013 17:59:00 -0000 On Tue, 2013-02-19 at 09:35 -0800, Tim Kientzle wrote: > On Feb 18, 2013, at 5:05 PM, Ian Lepore wrote: > > On Mon, 2013-02-18 at 11:47 -0800, Tim Kientzle wrote: > >>> I do not understand the FDT_ERR_BADMAGIC, the page http://www.denx.de/wiki/DULG/UBootCmdFDT has a lot of those errors listed in an example session but does not explain what the message conveys? > >> > >> To help me clarify my own understanding, I wrote a brief > >> explanation of where we are with FDT handling that > >> digs into how RPi boot handles FDT today and points > >> out some of the work that still remains. > >> > > > > While you're digging around in that area of the code... is there any way > > ubldr can find out from u-boot how it was loaded? I would love it if > > ubldr could automatically set currdev=net0: if it was loaded via dhcp or > > tftp, and automatically use net0:/boot/loader.rc in that case as well. > > I believe this is possible, but it would require some C-level > work on ubldr. (And I'm not using netbooting in my current > dev environment, so I don't have a good way to test this > right now.) > > The U-Boot API does provide a way to access the U-Boot > environment variables. My work on ubldr right now is > using this to get the FDT information from U-Boot. > > If I stumble across the specific hooks needed for this, > I'll let you know. > > > The general thing I'm up to today is learning enough about ubldr to use > > it effectively, and ultimately to see if it can be used to load a > > (semi-)generic kernel plus a set of modules you configure in loader.rc. > > I've just managed to do that by hand, now to see if loader.rc will > > cooperate. > > Modulo bugs, this should all work. ubldr is just loader(8) with > U-Boot API grafted underneath instead of a PC BIOS. > So module loading and all the boot-time configuration > hooks that people are used to on x86 should Just Work. > > A couple of folks have talked about turning on FICL > in ubldr, that would open even more automation > possibilities. That's what I'm testing at this very moment. So far it seems to be working fine, except that I notice "fdt addr 0x0100" has to be in the loader.rc file, it doesn't work if it's in the loader.conf file. So I'm off to see what's up with that... -- Ian