From owner-freebsd-arm@FreeBSD.ORG Tue Feb 19 17:35:26 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 DDAF4D2F; Tue, 19 Feb 2013 17:35:26 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 9F2F6863; Tue, 19 Feb 2013 17:35:26 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1JHZQfq074768; Tue, 19 Feb 2013 17:35:26 GMT (envelope-from kientzle@FreeBSD.org) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id xfxprprjeb9vkjhz33ta9j4nzn; Tue, 19 Feb 2013 17:35:26 +0000 (UTC) (envelope-from kientzle@FreeBSD.org) Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1361235912.1164.55.camel@revolution.hippie.lan> Date: Tue, 19 Feb 2013 09:35:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51227033.3070304@thieprojects.ch> <1361235912.1164.55.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) 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:35:26 -0000 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? >>=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 >=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 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. Tim