From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 01:25:56 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 79624B6 for ; Tue, 19 Feb 2013 01:25:56 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x22e.google.com (ie-in-x022e.1e100.net [IPv6:2607:f8b0:4001:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1F61CD for ; Tue, 19 Feb 2013 01:25:56 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id k10so7927019iea.33 for ; Mon, 18 Feb 2013 17:25:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=9/KLkkA0GxMKNzdT0zcht53BO24BV+JMRL6NLGOw1lY=; b=Oco8T9KZSHEgjjibaoc3pSAfEsyb587O7NUseWVg6UjZo+YRj2OwCCmw+xS/A9ZkwG t6vCenFUuO3IS+o0skVZNKUat9oeyf7KajprKvBO+ZHqsK4hUOwyVeC3kmH8+oV3+jc5 gD3UJB8dF9GdSy6X/aAq0xL8LtoXP2HGRfOWFSs8X3PukfC4S8U/ZIjhOCKPpGfBucZv mPhuQ9GCU+Nns4I8C24u11IF9B1TS7N4w6D3rfeG8Z5DPohyaZ47qjixBW/gakJJGbS9 wsC1TD3lFZKXLacli9vHEhIAPyo5EEFcOQV8UYZqJgFlMNLW+hnxEZiKsQlYjo9w/ZV1 icsg== X-Received: by 10.50.194.129 with SMTP id hw1mr8252074igc.8.1361237155804; Mon, 18 Feb 2013 17:25:55 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id uy13sm11788858igb.7.2013.02.18.17.25.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 17:25:54 -0800 (PST) Sender: Warner Losh Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1361235912.1164.55.camel@revolution.hippie.lan> Date: Mon, 18 Feb 2013 18:25:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C578B82-E8F9-4020-B52C-5F1091576E75@bsdimp.com> References: <51227033.3070304@thieprojects.ch> <1361235912.1164.55.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnR0LxeKaeNCGjGRa1F2NEEL2CMrSSeM0DIufGxru7nSJdpGMifslLRdDksdSf84wAYz7+N 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:25:56 -0000 On Feb 18, 2013, at 6: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? >>=20 >> 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. >>=20 >> What FDT is: >>=20 >> 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. >>=20 >> How FreeBSD uses FDT: >>=20 >> 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. >>=20 >> 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). >>=20 >> How FreeBSD-on-RPi handles FDT: >>=20 >> 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: >>=20 >> * The RPi boot blocks load the DTB into memory. >>=20 >> * The RPi boot blocks edit the DTB with information about graphics = setup >>=20 >> * U-Boot runs and discovers some additional system information >> (but doesn't deal with the FDT) >>=20 >> * 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] >>=20 >> * ubldr tells the FreeBSD kernel how to access the FDT. >>=20 >> Tim >>=20 >> [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.) >>=20 >> [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. >=20 > 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=3Dnet0: if it was loaded via = dhcp or > tftp, and automatically use net0:/boot/loader.rc in that case as well. I don't think it can but... > 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? ... you can pass this in on the command line. I think the way we're = booting means we'd have to dig this information out of the environment, = in which case we can always grab the command line... > 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. Let us know how that works out. Warner