Date: Mon, 11 Feb 2013 10:19:00 -0800 From: Oleksandr Tymoshenko <gonzo@bluezbox.com> To: Ian Lepore <ian@FreeBSD.org> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm@FreeBSD.org Subject: Re: Raspberry Pi No Login Message-ID: <62DF1CE7-6F3E-4233-9657-244B73D5EBE5@bluezbox.com> In-Reply-To: <1360597905.4545.89.camel@revolution.hippie.lan> References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> <F9B0FF68-05F7-40FA-9150-CD0D602ADF9B@kientzle.com> <CALCpEUFNCojMLx2_90iKDyCoezdt3TgFYQ-EXafNhVCevN9OsQ@mail.gmail.com> <5109A3F2.7010508@bluezbox.com> <5116F226.7010204@bluezbox.com> <1360597905.4545.89.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2013-02-11, at 7:51 AM, Ian Lepore <ian@FreeBSD.org> wrote: > On Sat, 2013-02-09 at 17:04 -0800, Oleksandr Tymoshenko wrote: >> On 1/30/2013 2:51 PM, Oleksandr Tymoshenko wrote: >>> On 1/30/2013 2:25 PM, hiren panchasara wrote: >>>> On Wed, Jan 30, 2013 at 9:15 AM, Tim Kientzle <tim@kientzle.com> wrote: >>>>> On Jan 30, 2013, at 7:42 AM, Neal Nelson wrote: >>>>> >>>>>> HI. >>>>>> >>>>>> I'm able to build a bootable FreeBSD image using the beaglebone >>>>>> scripts, which I understand is the accepted way at the moment. >>>>>> >>>>>> The problem I have is that everything seems to be going nicely, but >>>>>> I never get a login prompt. The last thing I see, after the ssh key >>>>>> generation stuff, is a line showing the date, then nothing. This is >>>>>> true using Current as of today (2012-01-30). >>>>>> >>>>>> I've had this problem for some time now as every image I build >>>>>> using this process has the same problem. If anyone has an idea as >>>>>> to what I'm doing wrong, I'd be very grateful. >>>>> Look at the kernel boot messages for the SD card >>>>> check. >>>>> >>>>> Is it probing at 25MHz or 50MHz? >>>>> >>>>> I haven't tried RPi in a little while, but last time I did >>>>> there was an erratic bug which caused the SD card >>>>> to sometimes get probed at 50MHz and be non-functional. >>>>> >>>>> I believe some people worked around this by trying >>>>> different cards or maybe it's been fixed in the >>>>> SD driver by now? >>>> Not sure if its fixed in the driver now but I got around the frequency >>>> problem by the patch available at: >>>> http://www.peach.ne.jp/archives/rpi/patch/ >>>> >>>> Basically its setting freq to 25MHz instead of default 50MHz in >>>> bcm2835_sdhci.c >>> >>> The patch works around the issue although it does address several >>> issues with FreeBSD's >>> generic mmc driver. Namely: driver does not check for return value for >>> functions that read >>> card's CSD, SCR or the result of switch command. CSD and SCR register >>> contain card-specific >>> information drivers uses to tune its operations. So when register read >>> command silently >>> fails driver uses partially valid data and hence its behavior might or >>> might not manifest >>> problems. >>> >>> Now the interesting part is why these commands fail. SDHCI controller >>> returns Data CRC >>> errors when executing them. It happens fairly early in initialization >>> sequence so at that point >>> card operates at 400KHz and should not have problem like this. >> >> Today I went all scientific on this issue and plugged logic analyzer >> to SD card using SparkFun's SD Sniffer[1]. What I found was that on >> power up SDHCI controller starts operating at frequency of 190KHz but >> shortly after it, before any data is read via DATA line, it switches to >> 8MHz. So I capped minimum frequency for SDHCI driver at 8MHz and got >> RPi into endless reboot cycle. Lo and behold: it's been almost two >> hours and so far no Data CRC Error interrupts. >> >> Patch: http://people.freebsd.org/~gonzo/arm/patches/rpi-sdhci.diff >> >> Description: >> - Do not silently ignore failure of "Read CSD" and "Read SCR" >> commands since data returned by them is essential for further >> initialization >> - Properly calculate minimum frequency for SDHCI 3.00 and higher >> - Add new method to SDHCI interface for setting driver-specific >> minimum frequency. Provide default implementation. >> - Cap minimum frequency at 8MHz for Raspberry Pi's SDHC >> >> I'd appreciate reviews and testing. There is one debug printf that >> will be removed from final version. >> >> [1] https://www.sparkfun.com/products/11468 >> > > I may not be understanding what you mean about the 8mhz clock, but if > that refers to the speed on the sd/mmc bus itself, that sounds like a > violation of the protocol. The bus is supposed to be run at no more > than 400khz until the card identification procedure is completed. (I > suspect most modern card can run the ID sequence at full speed.) > > I wonder if the real problem is a violation of a rule about switching > speed after the ID sequence... I vaguely remember there are some rules > about that, like after sending commands that change the bus config you > have to wait a certain number of cycles for the card to adjust. Yes, I was talking about SD/MMC bus speed. I understand that it's violation of ID sequence but Data CRC errors at low frequencies looks like silicon quirk. I failed to find any errata for chip so it's guesswork but I do not think it's our SDHCI/MMC driver bug. The Linux driver struggles from the same issues. Our options here are: - Increase retry attempts number in generic SDHCI and MMC drivers. for Read CSD and Read SCR commands. It will only increase chances but will not guarantee success. - Cap minimum frequency which seems to help but leaves out older MMC cards.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62DF1CE7-6F3E-4233-9657-244B73D5EBE5>