Date: Wed, 29 Oct 2014 14:59:13 -0600 From: Warner Losh <imp@bsdimp.com> To: Ian Lepore <ian@FreeBSD.org> Cc: Andreas Schwarz <Andreas.Schwarz@schwarzes.net>, George Rosamond <george@ceetonetechnology.com>, "freebsd-arm@freebsd.org" <freebsd-arm@FreeBSD.org>, ticso@cicely.de, Tim Kientzle <tim@kientzle.com> Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices Message-ID: <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> In-Reply-To: <1414613786.17308.124.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> <20141029200403.GC59614@cicely7.cicely.de> <1414613786.17308.124.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_AB56FC0D-97C9-4AD5-A351-732A2C752617 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 29, 2014, at 2:16 PM, Ian Lepore <ian@FreeBSD.org> wrote: > On Wed, 2014-10-29 at 21:04 +0100, Bernd Walter wrote: >> 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: >>>>>>>>>=20 >>>>>>>>> Ok - that card problem seems random or contact related. >>>>>>>>> Whatever, it is 6 am - time to sleep ;-) >>>>>>>>=20 >>>>>>>> I've found a missing silicon bug workaround on our driver. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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). >>>>>>>>=20 >>>>>>>> Please, give it a try and let me know if it helps. >>>>>>>=20 >>>>>>> Tested. >>>>>>> All I can say so far is that it is random, but your patch didn't = help. >>>>>>=20 >>>>>> 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 >>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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". >>>>>>=20 >>>>>> Ok. Can you try add the following to /boot/loader.conf ? >>>>>>=20 >>>>>> echo hw.bcm2835.sdhci.hs=3D0 >> /boot/loader.conf >>>>>>=20 >>>>>> RPi _is_ picky about the SD card, the patch won't make that go = away >>>>>> but should help in a few cases. >>>>>=20 >>>>> 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. >>>>>=20 >>>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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 >>>>> ... >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> --=20 >>>=20 >>> 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. >>=20 >> 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. High speed on the RM9200 boards was always a bit dodgy anyway. :( Sorry = for the hassle. >>> 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. >>=20 >> 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. >>=20 >=20 > U-boot and linux both run the card at full speed... 400khz during > identification, then 50mhz for cards which support it (which is > virtually every card these days, certainly every card larger than = 2gb). > I verified the clock rates with a 'scope back when I was debugging = hard > on this problem, thinking that we were somehow setting the wrong rates > in the driver. The signals looked right, so I think the problem must = be > in the timing or sequence of commands we send to the host controller. There have bugs in the past where we transition to the new speed at the wrong time, which caused issues. That might be a fruitful avenue of = inquiry. Warner --Apple-Mail=_AB56FC0D-97C9-4AD5-A351-732A2C752617 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUUVUhAAoJEGwc0Sh9sBEA+uAQAKucpdVfyJk1NcAxGUmQLkcS zRSSjTsDYcBxb0h6mdxNgsY61RzP6kCvCSRA0ryOVv9h9yst6SZNKjStxXgh5yc+ Oge+/f/9BwKpQpzNrJ6aM4YIu4SDogklFDmH8Lwe2+zpE/NV1Bt2uxWLnqUawDHf cudQy8SuWnVYCiZQD7P+8MN66uOpnsYTrW1d/AvsD2fQ/iAEnbJ+txa2idaEAzDV y9m3RZyxUFcFhx1kWA9+Ktl+1W4i7Hf4+7qGgJ8MRpef0RPSTG0fFX6AwaJaOizr Acc1cVcX2RxAt6Hl23pvNGYohgFSj+mn5BZKk8QqSSnFTIFMjAJElmIgNc8eQGdM aUKzhfLixe79Xva6mZOPQeFZ07/q6Izu3A4a5uN766KH5B8l62Y+l+L1O1i5O32U xZv219VCVXFYkHXo8+oHfgAB7vInxbXikq6cTh+R8Juyrm3O6WwJZ9ziowYSSfUE IvHPUHgZEi+xmg1M4yH3+J3C05CgjHh+RnQbFa2NzjyJjTAZcADgNL3UF+9s7Lks 0/os6CwiXhfg3KoQJKChpwZxrDKRmqzzLSacmOp2NYMZvbiqmLXbPXCdtwINiCkv CR6rDwIHYDiJMKTvLoBRH7cN2JWVbsxHhUZX3X/gopnTu8twvhbuoi2MkcKG41qg 6wDACJbLpEqXcqW2O4GU =OlDb -----END PGP SIGNATURE----- --Apple-Mail=_AB56FC0D-97C9-4AD5-A351-732A2C752617--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD>