From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 19:24:01 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 6E702106567B; Tue, 20 Jan 2009 19:24:01 +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 1B1AB8FC19; Tue, 20 Jan 2009 19:24:01 +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 n0KJMbfk002102; Tue, 20 Jan 2009 12:22:37 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 12:23:12 -0700 (MST) Message-Id: <20090120.122312.1543793985.imp@bsdimp.com> To: mav@freebsd.org From: "M. Warner Losh" In-Reply-To: <4976215B.40302@FreeBSD.org> References: <49760E8E.1000609@FreeBSD.org> <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@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:24:01 -0000 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. Warner