From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 13:56:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 231CE368 for ; Thu, 30 Oct 2014 13:56:45 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE821DD7 for ; Thu, 30 Oct 2014 13:56:44 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjqDO-000Ajv-68; Thu, 30 Oct 2014 13:56:38 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9UDuZVe083124; Thu, 30 Oct 2014 07:56:35 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19nO0hRaxD49dT4zrJY5+tS X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices From: Ian Lepore To: Luiz Otavio O Souza In-Reply-To: References: <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <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> Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Oct 2014 07:56:35 -0600 Message-ID: <1414677395.17308.155.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Andreas Schwarz , George Rosamond , Tim Kientzle , "freebsd-arm@freebsd.org" , ticso@cicely.de 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: Thu, 30 Oct 2014 13:56:45 -0000 On Thu, 2014-10-30 at 10:54 -0200, Luiz Otavio O Souza wrote: > 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 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. > Is your probe set for 10x mode? When I first looked at the clock and data signals on the rpi sdcard they looked horrible, the waveforms were anything but square. I thought I was on to something at first, maybe the board was just too underpowered. But eventually I realized I had the probe set to 1x mode and it was pulling too much current off the lines. When I switched it to 10x everything looked good. (Maybe all of this is a no-brainer to a hardware person. I'm a software person with just enough hardware knowledge to confuse himself.) -- Ian > 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