From owner-freebsd-arm@FreeBSD.ORG Wed Jan 30 22:51:44 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 19CD6ED5 for ; Wed, 30 Jan 2013 22:51:44 +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 B3813B53 for ; Wed, 30 Jan 2013 22:51:43 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1U0gVB-0009E9-3s; Wed, 30 Jan 2013 14:51:35 -0800 Message-ID: <5109A3F2.7010508@bluezbox.com> Date: Wed, 30 Jan 2013 14:51:30 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: hiren panchasara Subject: Re: Raspberry Pi No Login References: <09931DEF-C90A-4E72-B5EE-02BB0C6A8588@kobudo.homeunix.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 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 [...] 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: Wed, 30 Jan 2013 22:51:44 -0000 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. Linux developers assume that the problem i "lazy" CRC module and their fix is to retry these operation several times until they succeed. Daisuke's patch uses same approach. I am reluctant to commit special quirk handler for one controller, moreover I believe that it just masks symptoms and does not address root cause. Unfortunately I do not have access to Arasan's hardware specs or errata so can't confirm my assumptions. I'll try to spend some time identifying the actual source of the problem and if it yields nothing - we'll try to come up with least intrusive workaround.