From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 02:19:53 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 A2A5E258; Thu, 30 Oct 2014 02:19:53 +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 2B5C0C35; Thu, 30 Oct 2014 02:19:52 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s9U2J6sa003279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2014 03:19:06 +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 s9U2Iw2V045853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 03:18:58 +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 s9U2IwWP063529; Thu, 30 Oct 2014 03:18:58 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s9U2IvnW063528; Thu, 30 Oct 2014 03:18:57 +0100 (CET) (envelope-from ticso) Date: Thu, 30 Oct 2014 03:18:57 +0100 From: Bernd Walter To: Warner Losh Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices Message-ID: <20141030021857.GD59614@cicely7.cicely.de> Reply-To: ticso@cicely.de 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> 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 , Ian Lepore , 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 02:19:53 -0000 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. 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. > 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 :-( -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.