Raspberry Pi No Login

[Oleksandr Tymoshenko]

On 2013-02-11, at 7:51 AM, Ian Lepore <ian at 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 at 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.