Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Oct 2014 03:18:57 +0100
From:      Bernd Walter <ticso@cicely7.cicely.de>
To:        Warner Losh <imp@bsdimp.com>
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>, ticso@cicely.de
Subject:   Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices
Message-ID:  <20141030021857.GD59614@cicely7.cicely.de>
In-Reply-To: <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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 <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?20141030021857.GD59614>