Date: Tue, 20 Jan 2009 21:29:37 +0200 From: Alexander Motin <mav@FreeBSD.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arm@freebsd.org Subject: Re: Mount root from SD card? Message-ID: <49762621.70104@FreeBSD.org> In-Reply-To: <20090120.122312.1543793985.imp@bsdimp.com> References: <49760E8E.1000609@FreeBSD.org> <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <4976215B.40302@FreeBSD.org> > Alexander Motin <mav@FreeBSD.org> writes: > : M. Warner Losh wrote: > : > In message: <49760E8E.1000609@FreeBSD.org> > : > Alexander Motin <mav@FreeBSD.org> writes: > : > : Krassimir Slavchev wrote: > : > : > -----BEGIN PGP SIGNED MESSAGE----- > : > : > Hash: SHA1 > : > : > > : > : > M. Warner Losh wrote: > : > : > ... > : > : >> mmcsd0: 1983MB <SD Memory Card> at mmc0 30MHz/1bit > : > : >> Trying to mount root from ufs:/dev/mmcsd0s1 > : > : >> > : > : >> Manual root filesystem specification: > : > : >> <fstype>:<device> Mount <device> using filesystem <fstype> > : > : >> eg. ufs:/dev/da0a > : > : >> ? List valid disk boot devices > : > : >> <empty line> Abort manual input > : > : >> > : > : >> mountroot> ? > : > : >> > : > : >> List of GEOM managed disk devices: > : > : >> mmcsd0 > : > : >> > : > : >>> Looks like that should be working. > : > : >>> mav@ has done a lot of hacking on the mmc code... > : > : >>> Do you have 1 wire or 4 wires for your mmc bus on your board? > : > : > > : > : > On the board all 4 bus wires are connected (MCD A0-A3) but I've never > : > : > seen working 4-bit mode on AT91RM9200 (See PR128987 too). > : > : > : > : I have just committed MMCBR_IVAR_CAPS implementation into CURRENT. > : > : Without having it implemented, results can be unpredictable. For > : > : example, mmc layer could enable high-speed timings to reach 30MHz, but > : > : this mode is not implemented for this controller. Booting with verbose > : > : messages enabled could give a bit more information. > : > > : > This controller's driver should do the right thing when given a too > : > high bus speed: clamp it to the maximum... > : > > : > However, maybe the clamps are right. The above symptom was what I'd > : > see when the data read in was corrupted. It is the whole reason I > : > never enabled the multi-block read for this controller. I could never > : > make it work well enough to even make mountroot happy. > : > : High-speed timings does not mean just a high frequency. It is some > : different signaling scheme required for higher frequencies, which should > : be explicitly enabled on both card and controller. If one of them is not > : enabled - there will be problems. > > Ah, true. That does need to be a capability then. > > : > : What's about 4-bit mode, I see some sc->wire4 variable checked by the > : > : driver, which is never initialized. I don't very understand how this > : > : thing expected to work. > : > > : > It is initialized to zero. It is expected that there will be a > : > different mechanism in the future to set it generically on a per-board > : > basis. > : > : IMHO it is incorrect to disable 4bit mode on that stage, it is too late > : there. It should be done at controller capabilities announcement stage. > : If you are not objecting, I would remove that wire4 variable. > > I am objecting. The code is there so that the rest of the driver does > the right thing when doing 4-bit. It needs to be a capability too. > > However, before we go monkeying with this, we need to find the > underlying bug. Bug of not working 4-bit mode? I have told why it is not working: because zeroed wire4 variable permanently disables it by clearing respective bit in controller SDCR register. I can't imagine any possible usage for this variable in present state. Can you? -- Alexander Motin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49762621.70104>