From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 17:30:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8FEC95A for ; Wed, 29 Oct 2014 17:30:19 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5017CA4A for ; Wed, 29 Oct 2014 17:30:18 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s9THTjRt086941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Oct 2014 18:29:46 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s9THTc60036358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 18:29:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s9THTcDv060817; Wed, 29 Oct 2014 18:29:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s9THTbCi060816; Wed, 29 Oct 2014 18:29:37 +0100 (CET) (envelope-from ticso) Date: Wed, 29 Oct 2014 18:29:37 +0100 From: Bernd Walter To: Luiz Otavio O Souza Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices Message-ID: <20141029172937.GB59614@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140825163528.d2e696cc3d03ad9bebcd239c@schwarzes.net> <20140826074951.4cf5a8fc@X220.alogt.com> <53FD1646.2010103@ceetonetechnology.com> <20140827021349.1273f703c6756d07fad72a16@schwarzes.net> <20141014032743.GK38905@cicely7.cicely.de> <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141023022244.GB16490@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Andreas Schwarz , George Rosamond , "freebsd-arm@freebsd.org" , ticso@cicely.de, Tim Kientzle X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:30:19 -0000 On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: > On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: > > On 22 October 2014 18:44, Bernd Walter wrote: > > > On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: > > >> On 14 October 2014 01:13, Bernd Walter wrote: > > >> > > > >> > Ok - that card problem seems random or contact related. > > >> > Whatever, it is 6 am - time to sleep ;-) > > >> > > >> I've found a missing silicon bug workaround on our driver. > > >> > > >> It's pretty recent and i'm still building new images to test with more > > >> cards, but it did fix all the instability i was seeing on the > > >> identification of one of my cards. > > >> > > >> Together with the new firmware (yes, there is another SD fix there) my > > >> RPi B rev 2 (with this same card) has gone from unusable to rock > > >> stable (i've done 80 cold boots without any damage/corruption to the > > >> card). > > >> > > >> Please, give it a try and let me know if it helps. > > > > > > Tested. > > > All I can say so far is that it is random, but your patch didn't help. > > > > Without my patch you should see the speed and the bus width changing > > over the boots and with my patch it should always be the same > > (41.6MHz/4bit): > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > > > Furthermore this problem now happens on each boot try. > > > It still may be possible that it can boot, but I've tried many more > > > times than needed before. > > > > > > Timecounters tick every 10.000 msec > > > usbus0: 480Mbps High Speed USB v2.0 > > > ugen0.1: at usbus0 > > > uhub0: on usbus0 > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > mmcsd0: Error indicated: 1 Timeout > > > mmcsd0: Error indicated: 1 Timeout > > > fb0: 656x416(0x0@0,0) 16bpp > > > fb0: pitch 1312, base 0x5e006000, screen_size 545792 > > > fbd0 on fb0 > > > VT: initialize with new VT driver "fb". > > > > Ok. Can you try add the following to /boot/loader.conf ? > > > > echo hw.bcm2835.sdhci.hs=0 >> /boot/loader.conf > > > > RPi _is_ picky about the SD card, the patch won't make that go away > > but should help in a few cases. > > I know - that's the reason why I bought the B+ boards in bundle with > cards directly from Farnell. > Hoped they wouldn't make any problems under FreeBSD. > The cards unfortunately are unlabeled, just the included SD adapter > has a raspi logo. > > > There is a possibility that your card won't work in HS mode and now > > that the card identification always works, it will always go with the > > highest supported speed. The tunable should help if that is the case. > > This makes sense. > I don't remember this card/board combination, but about a year ago, when > I used other cards in other boards the speed and width wasn't always the > same. > > And you are absolutely right, with that loader.conf entry it works. > ... > mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block > ... This is another card from the same order (and hopefully same batch) in a Beaglebone Black: mmcsd0: 8GB at mmc0 48.0MHz/4bit/65535-block Interesting that the Raspberry is so picky about them, since the card clearly is capable to do such frequency. But I miss something on the Raspberry board. The B boards clearly have series resistors in the signal lines. The B+ has not. However the MMC/SD should have some pull up resistors, usually around 100k Ohms. Following the signals is hard to impossible, but there are no such resistors in a reasonable location on neither B nor B+. They might be interal in the broadcom SoC, but this is very unusual. I consider modding the SD signals on the B+ impossible, but it can be done on the B. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.