Mount root from SD card?

[Alexander Motin]

M. Warner Losh wrote:
> In message: <49760E8E.1000609 at FreeBSD.org>
>             Alexander Motin <mav at 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.

> : 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.

-- 
Alexander Motin