Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Oct 2014 21:04:03 +0100
From:      Bernd Walter <ticso@cicely7.cicely.de>
To:        Ian Lepore <ian@FreeBSD.org>
Cc:        Andreas Schwarz <Andreas.Schwarz@schwarzes.net>, George Rosamond <george@ceetonetechnology.com>, Tim Kientzle <tim@kientzle.com>, "freebsd-arm@freebsd.org" <freebsd-arm@FreeBSD.org>, ticso@cicely.de
Subject:   Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices
Message-ID:  <20141029200403.GC59614@cicely7.cicely.de>
In-Reply-To: <1414605501.17308.97.camel@revolution.hippie.lan>
References:  <53FD1646.2010103@ceetonetechnology.com> <20140827021349.1273f703c6756d07fad72a16@schwarzes.net> <20141014032743.GK38905@cicely7.cicely.de> <20141014041305.GM38905@cicely7.cicely.de> <CAB=2f8wiBLRYBVHUw-PptzQE-QP3%2B1EmHFMMMipZWi_dUG9m8w@mail.gmail.com> <20141022204454.GA12231@cicely7.cicely.de> <CAB=2f8xHEeF8DtP1eCkpp3Y0rZu3w0Phi_gzMSByGJ74xaFchg@mail.gmail.com> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 29, 2014 at 11:58:21AM -0600, Ian Lepore wrote:
> On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote:
> > 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 <SDHC 00000 1.0 SN 62A50A6C MFG 11/2013 by 27 SM> 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: <DWCOTG> at usbus0
> > > > > uhub0: <DWCOTG OTG Root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
> > > > > mmcsd0: 8GB <SDHC 00000 1.0 SN 62A50A6C MFG 11/2013 by 27 SM> 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 <SDHC 00000 1.0 SN 62A50A6C MFG 11/2013 by 27 SM> 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 <SDHC 00000 1.0 SN A2050A45 MFG 11/2013 by 27 SM> 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.
> > 
> > -- 
> 
> Pullups on sd signal lines is a recent thing.  It's in the sd 4.x
> physical spec, in the form of requiring the standard sd data lines be
> pulled high or low when using the new UHS-II signals.  Other than that
> pullups are not required on any of the lines for sd cards.  At work we
> don't put pullups on any of them, and use a 22 ohm series on just the
> clock line, and that only on designs where we have to fly across a
> ribbon cable to get to the card socket.

Can't say since when it is in the SD spec, saw it in the MMC, but don't
know how long it is there either.
Anyway - I remember them well, because I had to hand wire them on my
RM9200 prototype boards.
It never had been a problem until Warner added higher speed support, but
I don't have series resistors on my boards.

> The thing to keep in mind about the rpi sdcard woes is that it all works
> in u-boot and in linux.  The same cards that fail on freebsd get as far
> as loading freebsd... i.e., they worked fine in u-boot and didn't fail
> until our driver came along and touched the hardware.  If you boot that
> same card into linux it'll work fine.

Do they run the cards with high clock rates?
At least with u-boot there wouldn't be a real problem for them to just
don't do high speed probing.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141029200403.GC59614>