From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 19:36:00 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 1AA28106564A; Tue, 20 Jan 2009 19:36:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id B665E8FC0A; Tue, 20 Jan 2009 19:35:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0KJWv96002226; Tue, 20 Jan 2009 12:32:57 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 12:33:33 -0700 (MST) Message-Id: <20090120.123333.-2135184451.imp@bsdimp.com> To: mav@freebsd.org From: "M. Warner Losh" In-Reply-To: <49762621.70104@FreeBSD.org> References: <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <49762621.70104@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii 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:36:00 -0000 In message: <49762621.70104@FreeBSD.org> Alexander Motin writes: : 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? Yes. You don't understand the history here. Keep it. I've sent my preferred patch. There's clearly a bug here, but wire4 is absolutely required to my future plans. Warner