Date: Wed, 26 Dec 2012 12:12:34 -0700 From: Ian Lepore <freebsd@damnhippie.dyndns.org> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi questions Message-ID: <1356549154.1144.57.camel@revolution.hippie.lan> In-Reply-To: <B46B53E3-F555-4AE9-A5B4-FE2C33756C62@kientzle.com> References: <1356466883.1144.8.camel@revolution.hippie.lan> <08125E73-C46A-4DDF-BFD8-59D5B86136B8@bluezbox.com> <1356476778.1144.20.camel@revolution.hippie.lan> <0F630E03-7A0C-4D56-A580-C7A9ABD2CB0C@bluezbox.com> <1356479705.1144.23.camel@revolution.hippie.lan> <B46B53E3-F555-4AE9-A5B4-FE2C33756C62@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2012-12-25 at 21:57 -0800, Tim Kientzle wrote: > On Dec 25, 2012, at 3:55 PM, Ian Lepore wrote: > >>> > >>> This is so close to working. > > I know what you mean…. > > I've almost got my scripts building bootable RPi images now using > the new boot sequence that Oleksandr's been working on. > > There's clearly been a huge amount of progress: memory config > now works, the HDMI video console works. > > But I am still having a few inexplicable issues: > > 1) Building U-Boot. > > I'm trying to build U-Boot from the sources at > github.com/gonzoua/u-boot-pi.git > They build but the result won't boot. Can anyone > point me to the U-Boot sources that do work? For > now, I'm using the binary blob that Oleksandr built. > > 2) Random failure to mount root. > > This is weird. If I insert the SD card into my Mac and open > the MSDOS partition, then eject, the card will boot (sort of, > see below). Otherwise, the kernel can't mount root. I'm > entirely baffled. > I did some debugging on this today. For me, the failure is always associated with trying to run the card at 50mhz. Look for this line when it fails to boot and see if that's also the case for you. mmcsd0: 477MB <SD 5 1.0 SN 7842 MFG 09/2007 by 111 0x0000> at mmc0 50.0MHz/4bit/65535-block I've tracked down the underlying cause to some data corruption. The mmc layer sends the inquiry command to ask the card if it can do high-speed mode, and sometimes there's bogus data in the response buffer. It should always be 64 bytes of zeroes, except that one bit would be set if the card is SDHC. I see lots of non-zero data in the first part of the response buffer in the failure cases: ugen0.1: <DWCOTG> at usbus0 uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0 00648001800180018001800180030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 mmc0: switch_res[13] 0x03 The proper response would either be all zeroes or the 0x03 byte would be 0x02 for an SDHC card. I wonder if that non-zero data is in any way related to a dma transfer related to initializing the usb root hub that's happening at about the same time? -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1356549154.1144.57.camel>