From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 19:29:35 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F97B106566C for ; Tue, 20 Jan 2009 19:29:35 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id D65F88FC0C for ; Tue, 20 Jan 2009 19:29:34 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 232099502; Tue, 20 Jan 2009 21:29:33 +0200 Message-ID: <49762621.70104@FreeBSD.org> Date: Tue, 20 Jan 2009 21:29:37 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: "M. Warner Losh" References: <49760E8E.1000609@FreeBSD.org> <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> In-Reply-To: <20090120.122312.1543793985.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jan 2009 19:29:35 -0000 M. Warner Losh wrote: > In message: <4976215B.40302@FreeBSD.org> > Alexander Motin writes: > : M. Warner Losh wrote: > : > In message: <49760E8E.1000609@FreeBSD.org> > : > Alexander Motin writes: > : > : Krassimir Slavchev wrote: > : > : > -----BEGIN PGP SIGNED MESSAGE----- > : > : > Hash: SHA1 > : > : > > : > : > M. Warner Losh wrote: > : > : > ... > : > : >> mmcsd0: 1983MB at mmc0 30MHz/1bit > : > : >> Trying to mount root from ufs:/dev/mmcsd0s1 > : > : >> > : > : >> Manual root filesystem specification: > : > : >> : Mount using filesystem > : > : >> eg. ufs:/dev/da0a > : > : >> ? List valid disk boot devices > : > : >> 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