From owner-freebsd-arm@FreeBSD.ORG Mon Feb 18 19:46:07 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 4CE46E9B for ; Mon, 18 Feb 2013 19:46:07 +0000 (UTC) (envelope-from tim@kientzle.com) 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 21B541FF for ; Mon, 18 Feb 2013 19:46:06 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r1IJjx1h064761; Mon, 18 Feb 2013 19:45:59 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cmyqw9xxb69xsv533dsz6azs6s; Mon, 18 Feb 2013 19:45:59 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: RPi hangs in bootloader Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <51227033.3070304@thieprojects.ch> Date: Mon, 18 Feb 2013 11:45:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51227033.3070304@thieprojects.ch> To: Werner Thie 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: Mon, 18 Feb 2013 19:46:07 -0000 On Feb 18, 2013, at 10:17 AM, Werner Thie wrote: > Hi all >=20 > just built a fresh image (latest sources) with Tim Kientzle's script = for the RPi after getting my serial cable and see the following on the = console >=20 > > cu -l /dev/cuaU0 -s 115200 Context: You connected after the RPi boot blocks have already run. U-Boot's boot delay has just expired (the digit zero below) and U-Boot is reading its configuration: > Connected > 0 > reading uEnv.txt > 170 bytes read in 9448 ms (0 Bytes/s) > Importing environment from mmc ... > reading ubldr > 242830 bytes read in 62811 ms (2.9 KiB/s) > ## Starting application at 0x02000054 =85 Context: At this point, ubldr has started. ("ubldr" is "the U-Boot compatible version of loader(8)"). It first probes U-Boot for some general system info before it prints it's own version information: > Consoles: U-Boot console > Compatible API signature found @db662a8 > Number of U-Boot devices: 1 >=20 > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (root@xtools, Mon Feb 18 08:36:09 CET 2013) > DRAM: 224MB >=20 > Device: disk > error validating blob: FDT_ERR_BADMAGIC Context: ubldr has just run the loader.rc command that should find the FDT at a particular location in memory. Apparently, the block of memory it's looking at does not in fact contain a valid FDT. This could be a problem earlier in the boot process (there isn't an FDT where it should be) or could be a problem with ubldr (it's not actually looking where it was told to look) or with loader.rc (it may not have the correct command). (Note: I happen to be tinkering with that exact part of ubldr at the moment, but I just realized out that I haven't actually committed any of my changes yet, so I don't think this is my fault. ;-) You're pretty much toast at this point, since without an FDT, the kernel won't be able to boot. However, ubldr is going to load and execute the kernel anyway: > | > /boot/kernel/kernel data=3D0x3939b8+0x4294c = syms=3D[0x4+0x7f530+0x4+0x61597] > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > fdt_start: 0x00466F50 > Kernel entry at 0x100100... > Kernel args: (null) The last three messages are printed by ubldr just before it transfers control to the kernel. "Kernel args: (null)" is quite typical here. >=20 > After that the RPi hangs forever. Any hints what to try? When was the last time you built an image? There are two reasonable explanations: * RPi boot blocks aren't loading the proper FDT into memory. Look at the RPi boot configuration file config.txt which should refer to devtree.dat. Make sure devtree.dat matches an earlier build. * ubldr isn't correctly finding the FDT. There's been a steady amount of work on boot stuff recently, though I don't see anything in the last few weeks that seems directly relevant. Do you know what SVN revision you're using right now? Do you have an SVN revision of a recent good build? Tim