Date: Thu, 30 Oct 2014 10:54:08 -0200 From: Luiz Otavio O Souza <lists.br@gmail.com> To: ticso@cicely.de Cc: Andreas Schwarz <Andreas.Schwarz@schwarzes.net>, George Rosamond <george@ceetonetechnology.com>, Ian Lepore <ian@freebsd.org>, Tim Kientzle <tim@kientzle.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices Message-ID: <CAB=2f8zamdWrSv15h4Zq0%2BdD-nc_QSUdT3NKJ%2BpbrvY81w0MLQ@mail.gmail.com> In-Reply-To: <20141030021857.GD59614@cicely7.cicely.de> References: <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> <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> <20141030021857.GD59614@cicely7.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 October 2014 00:18, Bernd Walter wrote: > On Wed, Oct 29, 2014 at 02:59:13PM -0600, Warner Losh wrote: >> >> 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: >> >>> >> >>> 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. >> >> High speed on the RM9200 boards was always a bit dodgy anyway. :( Sorry for the hassle. > > Sorry? > No - you had been just in time to catch this hardware problem as prototype. > >> >>> 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. >> >> >> > >> > 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. > > Well... > If you scope checked the frequency, it works with other software and > with another controller, then it must be some strange kind of controller > software handling problem. > The Raspi is not a board with high speed expectations anyway. > Probably we should default the highspeed sysctl to false instead of true > until there is a fallback or fix. I tried to check the SD clock frequency with the scope and just by connecting the probe on the SD clock line the card that was previously working flawless, start to exhibit some i/o errors, so i guess it is pretty sensible to capacitance load on that line (that may explain why they removed the series resistor). This lead me into another issue, where i get reading errors from card (because of the scope probe) and even when errors do not affect the filesystem neither the system (as in dd if=/dev/mmcsd0 of=/dev/zero bs=1m), the controller cannot recover from the first error and you need to reboot. If this is a real error (I cannot reproduce it reliably yet), it would explain a lot. I'll take care of change the high speed default setting for now. > > Btw I have a hardkernel board with this broadcom chip - it looks like > it has pull ups... > Never powered it up so far - it is said to be software compatible with > the raspberry. > It has a micro SD slot and a connector for an eMMC board, not sure if > there is a second controller or you can't use both at the same time. > Will give it a try during the next days. I have asked about the pull-ups before, but from nxp's AN10911, I infer that they are used for interface conditioning (ESD and EMI): http://www.nxp.com/documents/application_note/AN10911.pdf > >> 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. > > I hate such bugs :-( So do i :) Luiz
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAB=2f8zamdWrSv15h4Zq0%2BdD-nc_QSUdT3NKJ%2BpbrvY81w0MLQ>