From owner-freebsd-arm@FreeBSD.ORG Mon Feb 11 18:19:33 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 0F3D1FE6; Mon, 11 Feb 2013 18:19:33 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 86D1A2EA; Mon, 11 Feb 2013 18:19:32 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.2.132]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U4xyJ-000LES-KA; Mon, 11 Feb 2013 10:19:25 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Raspberry Pi No Login From: Oleksandr Tymoshenko In-Reply-To: <1360597905.4545.89.camel@revolution.hippie.lan> Date: Mon, 11 Feb 2013 10:19:00 -0800 Content-Transfer-Encoding: 7bit Message-Id: <62DF1CE7-6F3E-4233-9657-244B73D5EBE5@bluezbox.com> References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> <5109A3F2.7010508@bluezbox.com> <5116F226.7010204@bluezbox.com> <1360597905.4545.89.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2013-02-11, at 7:51 AM, Ian Lepore 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 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 [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Tim Kientzle , 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, 11 Feb 2013 18:19:33 -0000 On 2013-02-11, at 7:51 AM, Ian Lepore 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 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.