From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 01:05:48 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 408A1D03; Tue, 19 Feb 2013 01:05:48 +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 1FAAA11E; Tue, 19 Feb 2013 01:05:48 +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 r1J15Zi2094056; Mon, 18 Feb 2013 18:05:41 -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 r1J15COM049014; Mon, 18 Feb 2013 18:05:12 -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> Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Feb 2013 18:05:12 -0700 Message-ID: <1361235912.1164.55.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 01:05:48 -0000 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. > > What FDT is: > > FDT is a way for the kernel to find out what hardware it's > running on; there is a DTS (source) file you can edit > that gets compiled into a DTB (binary) file that is actually > used to drive the kernel driver setup. FDT was > standardized as part of OpenFirmware on PowerPC; it allows > the system to boot very quickly and allows people who are > changing hardware configurations to quickly adjust the system > to match new hardware. > > How FreeBSD uses FDT: > > For a while, we've mostly been compiling the FDT into the kernel, > but we're trying to move to a better design where the FDT is > provided by the boot loader. > > This will eventually allow us to use a single kernel on multiple > systems (the fabled "GENERIC ARM kernel") and make it > much easier to configure boards (for example, if you connect > a new peripheral via GPIO, you'll be able to "just" edit the > DTS, compile a new DTB, and reboot to use that peripheral). > > How FreeBSD-on-RPi handles FDT: > > The RPi is closer to this boot process than other platforms > (I'm working right now to move BeagleBone in this direction) > but it's still evolving. Here's how the RPi handles the FDT > when booting FreeBSD: > > * The RPi boot blocks load the DTB into memory. > > * The RPi boot blocks edit the DTB with information about graphics setup > > * U-Boot runs and discovers some additional system information > (but doesn't deal with the FDT) > > * FreeBSD ubldr runs, finds the DTB in memory [0] and edits it > to contain memory configuration and some other related > data that it queries from U-Boot. [1] > > * ubldr tells the FreeBSD kernel how to access the FDT. > > Tim > > [0] This is the key part that's still not quite right on RPi; > ubldr should request the FDT from U-Boot whereas right now it > has special knowledge of how the RPi boot blocks store the FDT > in memory. I'm trying right now to teach ubldr how to get > an FDT from U-Boot. (U-Boot can get the FDT from the RPi > blocks, but we are not using that capability today.) > > [1] A less-serious weakness of the current process: Either U-Boot or > the RPi boot blocks should be doing this editing, instead > of ubldr getting the information from U-Boot using a different > mechanism. 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. If that's not possible, I'd settle for the ability to pass args to ubldr. Or even a value in the environment would work I guess, can ubldr see the u-boot env? 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. -- Ian