From owner-freebsd-arm@FreeBSD.ORG Mon Jan 19 15:54:27 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 C74281065674 for ; Mon, 19 Jan 2009 15:54:27 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 152BF8FC1D for ; Mon, 19 Jan 2009 15:54:27 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 93E39C3A8 for ; Mon, 19 Jan 2009 17:31:48 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75864-02 for ; Mon, 19 Jan 2009 17:31:47 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 56EFFC295 for ; Mon, 19 Jan 2009 17:31:47 +0200 (EET) Message-ID: <49749CE2.2000405@bulinfo.net> Date: Mon, 19 Jan 2009 17:31:46 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: freebsd-arm@freebsd.org X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Subject: 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: Mon, 19 Jan 2009 15:54:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am trying to test the latest CURRENT on my 91rm9200 board but can not mount root from SD card anymore. Any ideas? Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #1 r187432M: Mon Jan 19 16:39:23 EET 2009 root@krassi:/usr/obj/arm/usr/src-current/sys/CENTIPAD CPU: ARM920T rev 0 (ARM9TDMI core) DC enabled IC enabled WB enabled LABT 16KB/32B 64-way Instruction cache 16KB/32B 64-way write-back-locking-A Data cache real memory = 67108864 (64 MB) avail memory = 62226432 (59 MB) atmelarm0: on motherboard at91_st0: mem 0xdffffd00-0xdffffdff irq 1 on atmelarm0 at91_st0: watchdog registered, timeout intervall max. 64 sec at91_pio0: mem 0xdffff400-0xdffff5ff irq 1 on atmelarm0 at91_pio0: ABSR: 0x1000060 OSR: 0 PSR:0x380010 ODSR: 0 at91_pio0: [FILTER] at91_pio1: mem 0xdffff600-0xdffff7ff irq 1 on atmelarm0 at91_pio1: ABSR: 0xff338 OSR: 0 PSR:0x3fc00cc7 ODSR: 0 at91_pio1: [FILTER] at91_pio2: mem 0xdffff800-0xdffff9ff irq 1 on atmelarm0 at91_pio2: ABSR: 0 OSR: 0 PSR:0xc07f ODSR: 0x4000 at91_pio2: [FILTER] at91_pio3: mem 0xdffffa00-0xdffffbff irq 1 on atmelarm0 at91_pio3: ABSR: 0 OSR: 0 PSR:0xfffffff ODSR: 0 at91_pio3: [FILTER] at91_pmc0: mem 0xdffffc00-0xdffffcff irq 1 on atmelarm0 at91_pmc0: Primary: 10000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 60 MHz at91_mci0: mem 0xdffb4000-0xdffb7fff irq 10 on atmelarm0 at91_mci0: [ITHREAD] mmc0: on at91_mci0 at91_twi0: mem 0xdffb8000-0xdffbbfff irq 12 on atmelarm0 at91_twi0: [ITHREAD] iicbus0: on at91_twi0 setting cwgr to 0x1a4a4 iic0: on iicbus0 icee0: at addr 0xa7 on iicbus0 ate0: mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0 miibus0: on ate0 rlphy0: PHY 16 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ate0: Ethernet address: 43:00:00:01:ff:00 ate0: [ITHREAD] uart0: mem 0xdffff200-0xdffff3ff irq 1 on atmelarm0 uart0: [FILTER]uart0: console (115200,n,8,1) uart1: mem 0xdffc0000-0xdffc3fff irq 6 on atmelarm0 uart1: [FILTER] uart2: mem 0xdffc4000-0xdffc7fff irq 7 on atmelarm0 uart2: [FILTER] uart3: mem 0xdffc8000-0xdffcbfff irq 8 on atmelarm0 uart3: [FILTER] uart4: mem 0xdffcc000-0xdffcffff irq 9 on atmelarm0 uart4: [FILTER] at91_ssc0: mem 0xdffd0000-0xdffd3fff irq 14 on atmelarm0 at91_ssc0: [ITHREAD] at91_ssc1: mem 0xdffd4000-0xdffd7fff irq 15 on atmelarm0 at91_ssc1: [ITHREAD] at91_ssc2: mem 0xdffd8000-0xdffdbfff irq 16 on atmelarm0 at91_ssc2: [ITHREAD] at91_spi0: mem 0xdffe0000-0xdffe3fff irq 13 on atmelarm0 at91_spi0: [ITHREAD] spibus0: on at91_spi0 spibus0: at cs 0 ohci0: mem 0xdfe00000-0xdfefffff irq 23 on atmelarm0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0 usb0 on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhub0: device problem (IOERROR), disabling port 2 Cannot get 100 Hz clock; using 100Hz at91_st0: [FILTER] Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000 Timecounters tick every 10.000 msec 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 With last known working kernel: ... FreeBSD 8.0-CURRENT #32: Thu Nov 8 17:22:00 EET 2007 ... SD CARD: 2079326208 bytes mmcsd0: on mmc0 mmc0: setting transfer rate to 30.000MHz Trying to mount root from ufs:/dev/mmcsd0s1 warning: Low voltage. The time may be corrupted! Dec 4 06:42:27 init: getting pseudoterminals resource limit: Invalid argument pid 25 (sh), uid 0: exited on signal 11 ... Best regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdJzixJBWvpalMpkRAp8WAJ9TkaSuQEi+601eEr6gDgYLiDsIkwCfXqA0 fp2SXoYe1rH/1119MAVCtdA= =hgL9 -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Mon Jan 19 18:10:13 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 720B4106579A for ; Mon, 19 Jan 2009 18:10:13 +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 9065A8FC24 for ; Mon, 19 Jan 2009 18:10:06 +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 n0JI7ro8077294; Mon, 19 Jan 2009 11:07:53 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 19 Jan 2009 11:08:27 -0700 (MST) Message-Id: <20090119.110827.2140505733.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <49749CE2.2000405@bulinfo.net> References: <49749CE2.2000405@bulinfo.net> 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: Mon, 19 Jan 2009 18:10:14 -0000 In message: <49749CE2.2000405@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : Hi, : : I am trying to test the latest CURRENT on my 91rm9200 board but can not : mount root from SD card anymore. : : Any ideas? : : Copyright (c) 1992-2009 The FreeBSD Project. : Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 : The Regents of the University of California. All rights reserved. : FreeBSD is a registered trademark of The FreeBSD Foundation. : FreeBSD 8.0-CURRENT #1 r187432M: Mon Jan 19 16:39:23 EET 2009 : root@krassi:/usr/obj/arm/usr/src-current/sys/CENTIPAD : CPU: ARM920T rev 0 (ARM9TDMI core) : DC enabled IC enabled WB enabled LABT : 16KB/32B 64-way Instruction cache : 16KB/32B 64-way write-back-locking-A Data cache : real memory = 67108864 (64 MB) : avail memory = 62226432 (59 MB) : atmelarm0: on motherboard : at91_st0: mem 0xdffffd00-0xdffffdff irq 1 on atmelarm0 : at91_st0: watchdog registered, timeout intervall max. 64 sec : at91_pio0: mem 0xdffff400-0xdffff5ff irq 1 on atmelarm0 : at91_pio0: ABSR: 0x1000060 OSR: 0 PSR:0x380010 ODSR: 0 : at91_pio0: [FILTER] : at91_pio1: mem 0xdffff600-0xdffff7ff irq 1 on atmelarm0 : at91_pio1: ABSR: 0xff338 OSR: 0 PSR:0x3fc00cc7 ODSR: 0 : at91_pio1: [FILTER] : at91_pio2: mem 0xdffff800-0xdffff9ff irq 1 on atmelarm0 : at91_pio2: ABSR: 0 OSR: 0 PSR:0xc07f ODSR: 0x4000 : at91_pio2: [FILTER] : at91_pio3: mem 0xdffffa00-0xdffffbff irq 1 on atmelarm0 : at91_pio3: ABSR: 0 OSR: 0 PSR:0xfffffff ODSR: 0 : at91_pio3: [FILTER] : at91_pmc0: mem 0xdffffc00-0xdffffcff irq 1 on atmelarm0 : at91_pmc0: Primary: 10000000 Hz PLLA: 180 MHz CPU: 180 MHz MCK: 60 MHz : at91_mci0: mem 0xdffb4000-0xdffb7fff irq 10 on : atmelarm0 : at91_mci0: [ITHREAD] : mmc0: on at91_mci0 : at91_twi0: mem 0xdffb8000-0xdffbbfff irq 12 on atmelarm0 : at91_twi0: [ITHREAD] : iicbus0: on at91_twi0 : setting cwgr to 0x1a4a4 : iic0: on iicbus0 : icee0: at addr 0xa7 on iicbus0 : ate0: mem 0xdffbc000-0xdffbffff irq 24 on atmelarm0 : miibus0: on ate0 : rlphy0: PHY 16 on miibus0 : rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto : ate0: Ethernet address: 43:00:00:01:ff:00 : ate0: [ITHREAD] : uart0: mem 0xdffff200-0xdffff3ff irq 1 on atmelarm0 : uart0: [FILTER]uart0: console (115200,n,8,1) : uart1: mem 0xdffc0000-0xdffc3fff irq 6 on atmelarm0 : uart1: [FILTER] : uart2: mem 0xdffc4000-0xdffc7fff irq 7 on atmelarm0 : uart2: [FILTER] : uart3: mem 0xdffc8000-0xdffcbfff irq 8 on atmelarm0 : uart3: [FILTER] : uart4: mem 0xdffcc000-0xdffcffff irq 9 on atmelarm0 : uart4: [FILTER] : at91_ssc0: mem 0xdffd0000-0xdffd3fff irq 14 on atmelarm0 : at91_ssc0: [ITHREAD] : at91_ssc1: mem 0xdffd4000-0xdffd7fff irq 15 on atmelarm0 : at91_ssc1: [ITHREAD] : at91_ssc2: mem 0xdffd8000-0xdffdbfff irq 16 on atmelarm0 : at91_ssc2: [ITHREAD] : at91_spi0: mem 0xdffe0000-0xdffe3fff irq 13 on atmelarm0 : at91_spi0: [ITHREAD] : spibus0: on at91_spi0 : spibus0: at cs 0 : ohci0: mem 0xdfe00000-0xdfefffff irq : 23 on atmelarm0 : ohci0: [GIANT-LOCKED] : ohci0: [ITHREAD] : usb0: OHCI version 1.0 : usb0 on ohci0 : usb0: USB revision 1.0 : uhub0: on usb0 : uhub0: 2 ports with 2 removable, self powered : uhub0: device problem (IOERROR), disabling port 2 : Cannot get 100 Hz clock; using 100Hz : at91_st0: [FILTER] : Timecounter "AT91RM9200 timer" frequency 32768 Hz quality 1000 : Timecounters tick every 10.000 msec : 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? Warner : With last known working kernel: : ... : FreeBSD 8.0-CURRENT #32: Thu Nov 8 17:22:00 EET 2007 : ... : SD CARD: 2079326208 bytes : mmcsd0: on mmc0 : mmc0: setting transfer rate to 30.000MHz : Trying to mount root from ufs:/dev/mmcsd0s1 : warning: Low voltage. The time may be corrupted! : Dec 4 06:42:27 init: getting pseudoterminals resource limit: Invalid : argument : pid 25 (sh), uid 0: exited on signal 11 : ... : : : Best regards : : : -----BEGIN PGP SIGNATURE----- : Version: GnuPG v1.4.7 (FreeBSD) : : iD8DBQFJdJzixJBWvpalMpkRAp8WAJ9TkaSuQEi+601eEr6gDgYLiDsIkwCfXqA0 : fp2SXoYe1rH/1119MAVCtdA= : =hgL9 : -----END PGP SIGNATURE----- : _______________________________________________ : freebsd-arm@freebsd.org mailing list : http://lists.freebsd.org/mailman/listinfo/freebsd-arm : To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" : : From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 07:59:29 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 A6CFA106564A for ; Tue, 20 Jan 2009 07:59:29 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF4F8FC08 for ; Tue, 20 Jan 2009 07:59:29 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id D73C3C49B; Tue, 20 Jan 2009 09:59:27 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03792-07; Tue, 20 Jan 2009 09:59:26 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id C3FF0C195; Tue, 20 Jan 2009 09:59:26 +0200 (EET) Message-ID: <4975845E.6020502@bulinfo.net> Date: Tue, 20 Jan 2009 09:59:26 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: "M. Warner Losh" References: <49749CE2.2000405@bulinfo.net> <20090119.110827.2140505733.imp@bsdimp.com> In-Reply-To: <20090119.110827.2140505733.imp@bsdimp.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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 07:59:29 -0000 -----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). Best regards > >> Warner > > With last known working kernel: > ... > FreeBSD 8.0-CURRENT #32: Thu Nov 8 17:22:00 EET 2007 > ... > SD CARD: 2079326208 bytes > mmcsd0: on mmc0 > mmc0: setting transfer rate to 30.000MHz > Trying to mount root from ufs:/dev/mmcsd0s1 > warning: Low voltage. The time may be corrupted! > Dec 4 06:42:27 init: getting pseudoterminals resource limit: Invalid > argument > pid 25 (sh), uid 0: exited on signal 11 > ... > > > Best regards > > _______________________________________________ freebsd-arm@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdYRexJBWvpalMpkRAupbAKCU5m28vw6OOhqo9MfMTbVGAFi7OwCfYDQ7 ctPYlDa089mbI+bKUYAf4ys= =6cNg -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 18:09:28 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 8484B106564A for ; Tue, 20 Jan 2009 18:09:28 +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 0BED68FC0A for ; Tue, 20 Jan 2009 18:09:27 +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 232094630; Tue, 20 Jan 2009 20:09:26 +0200 Message-ID: <4976135A.3070109@FreeBSD.org> Date: Tue, 20 Jan 2009 20:09:30 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Krassimir Slavchev References: <1232392983.00063248.1232380802@10.7.7.3> <1232400185.00063286.1232389201@10.7.7.3> <1232450582.00063538.1232438401@10.7.7.3> <49760E8E.1000609@FreeBSD.org> In-Reply-To: <49760E8E.1000609@FreeBSD.org> 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 18:09:28 -0000 Alexander Motin wrote: > 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. > > 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. As I can see from specification, if sc->wire4 is set to 0 by default, bus will not ever switched into 4bit mode. Try to just comment out " && sc->wire4" part of at91_mci.c. If this variable expected to report real bus width, then it probably should be done in different way, by reporting correct host capabilities. > PS: For MMC cards bus width testing routine implemented. May be we could > do something alike for SD cards. It is not part of SD specification, but > may be we could just issue some other command, transferring data, to > check effective bus width. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 18:41:59 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 CF7E61065697; Tue, 20 Jan 2009 18:41:59 +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 6C8DD8FC16; Tue, 20 Jan 2009 18:41: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 n0KIeF6r001605; Tue, 20 Jan 2009 11:40:15 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 11:40:51 -0700 (MST) Message-Id: <20090120.114051.-854291995.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <49760E8E.1000609@FreeBSD.org> References: <1232400185.00063286.1232389201@10.7.7.3> <1232450582.00063538.1232438401@10.7.7.3> <49760E8E.1000609@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 18:42:02 -0000 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. : 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. : PS: For MMC cards bus width testing routine implemented. May be we could : do something alike for SD cards. It is not part of SD specification, but : may be we could just issue some other command, transferring data, to : check effective bus width. That would be cool. Warner From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 18:49: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 7955310656BF for ; Tue, 20 Jan 2009 18:49:00 +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 EC8518FC1B for ; Tue, 20 Jan 2009 18:48:59 +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 232093696; Tue, 20 Jan 2009 19:48:58 +0200 Message-ID: <49760E8E.1000609@FreeBSD.org> Date: Tue, 20 Jan 2009 19:49:02 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Krassimir Slavchev References: <1232392983.00063248.1232380802@10.7.7.3> <1232400185.00063286.1232389201@10.7.7.3> <1232450582.00063538.1232438401@10.7.7.3> In-Reply-To: <1232450582.00063538.1232438401@10.7.7.3> 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 18:49:01 -0000 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. 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. PS: For MMC cards bus width testing routine implemented. May be we could do something alike for SD cards. It is not part of SD specification, but may be we could just issue some other command, transferring data, to check effective bus width. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 18:50:39 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 C2D1B10656C3; Tue, 20 Jan 2009 18:50:39 +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 59D658FC12; Tue, 20 Jan 2009 18:50:39 +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 n0KIntkW001713; Tue, 20 Jan 2009 11:49:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 11:50:31 -0700 (MST) Message-Id: <20090120.115031.2008400028.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4976135A.3070109@FreeBSD.org> References: <1232450582.00063538.1232438401@10.7.7.3> <49760E8E.1000609@FreeBSD.org> <4976135A.3070109@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 18:50:43 -0000 In message: <4976135A.3070109@FreeBSD.org> Alexander Motin writes: : Alexander Motin wrote: : > 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. : > : > 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. : : As I can see from specification, if sc->wire4 is set to 0 by default, : bus will not ever switched into 4bit mode. Try to just comment out " && : sc->wire4" part of at91_mci.c. If this variable expected to report real : bus width, then it probably should be done in different way, by : reporting correct host capabilities. sc is initialized to 0 by the bus layer, so I don't think this will have an effect. You are correct that this should be generic in the board-level specific meta-data for each at91 board. That stuff just isn't there yet. The problem is, I think, that something broke in the series of commits and now reads don't work at all anymore. After the first couple in the series, I didn't test the follow on commits due to time. Warner : > PS: For MMC cards bus width testing routine implemented. May be we could : > do something alike for SD cards. It is not part of SD specification, but : > may be we could just issue some other command, transferring data, to : > check effective bus width. : : -- : Alexander Motin : : From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 19:09:12 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 D47871065674 for ; Tue, 20 Jan 2009 19:09:12 +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 581328FC1E for ; Tue, 20 Jan 2009 19:09:12 +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 232097861; Tue, 20 Jan 2009 21:09:11 +0200 Message-ID: <4976215B.40302@FreeBSD.org> Date: Tue, 20 Jan 2009 21:09:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: "M. Warner Losh" References: <1232400185.00063286.1232389201@10.7.7.3> <1232450582.00063538.1232438401@10.7.7.3> <49760E8E.1000609@FreeBSD.org> <20090120.114051.-854291995.imp@bsdimp.com> In-Reply-To: <20090120.114051.-854291995.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:09:13 -0000 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. > : 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 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 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 From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 19:33:15 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 EB17A106564A; Tue, 20 Jan 2009 19:33:15 +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 A18728FC17; Tue, 20 Jan 2009 19:33:15 +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 n0KJVs5V002207; Tue, 20 Jan 2009 12:31:54 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 12:32:30 -0700 (MST) Message-Id: <20090120.123230.-272218744.imp@bsdimp.com> To: mav@freebsd.org From: "M. Warner Losh" In-Reply-To: <20090120.122312.1543793985.imp@bsdimp.com> References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> 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:33:16 -0000 In message: <20090120.122312.1543793985.imp@bsdimp.com> "M. Warner Losh" writes: : : 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. I've got the following patch, untested, that I think does what I think needs to be done. Not sure about the return value from update_ios... Index: at91_mci.c =================================================================== --- at91_mci.c (revision 187479) +++ at91_mci.c (working copy) @@ -201,7 +201,10 @@ sc->host.f_min = 375000; sc->host.f_max = 30000000; sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; - sc->host.caps = MMC_CAP_4_BIT_DATA; + if (sc->wire4) + sc->host.caps = MMC_CAP_4_BIT_DATA; + else + sc->host.caps = 0; child = device_add_child(dev, "mmc", 0); device_set_ivars(dev, &sc->host); err = bus_generic_attach(dev); @@ -295,6 +298,8 @@ clkdiv = (at91_master_clock / ios->clock) / 2; } if (ios->bus_width == bus_width_4 && sc->wire4) + return EINVAL; + if (ios->bus_width == bus_width_4) WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); else WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); Warner 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 From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 19:58:37 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 79FF31065672 for ; Tue, 20 Jan 2009 19:58:37 +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 F29F88FC1A for ; Tue, 20 Jan 2009 19:58:36 +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 232101379; Tue, 20 Jan 2009 21:58:35 +0200 Message-ID: <49762CEF.1000405@FreeBSD.org> Date: Tue, 20 Jan 2009 21:58:39 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> In-Reply-To: <20090120.123230.-272218744.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:58:37 -0000 M. Warner Losh wrote: > In message: <20090120.122312.1543793985.imp@bsdimp.com> > "M. Warner Losh" writes: > : : 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. > > I've got the following patch, untested, that I think does what I think > needs to be done. Not sure about the return value from update_ios... > > Index: at91_mci.c > =================================================================== > --- at91_mci.c (revision 187479) > +++ at91_mci.c (working copy) > @@ -201,7 +201,10 @@ > sc->host.f_min = 375000; > sc->host.f_max = 30000000; > sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; > - sc->host.caps = MMC_CAP_4_BIT_DATA; > + if (sc->wire4) > + sc->host.caps = MMC_CAP_4_BIT_DATA; > + else > + sc->host.caps = 0; > child = device_add_child(dev, "mmc", 0); > device_set_ivars(dev, &sc->host); > err = bus_generic_attach(dev); Ok. I agree with this part. If for some reason you really need this wire4 variable, this is the right way to use it. > @@ -295,6 +298,8 @@ > clkdiv = (at91_master_clock / ios->clock) / 2; > } > if (ios->bus_width == bus_width_4 && sc->wire4) > + return EINVAL; > + if (ios->bus_width == bus_width_4) > WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); > else > WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); > This part is correct, but useless. If the first part have not set MMC_CAP_4_BIT_DATA, then mmc layer will never request bus_width_4. That's why I have proposed to remove " && sc->wire4" check from here. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Tue Jan 20 20:06:31 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 964DB1065670 for ; Tue, 20 Jan 2009 20:06:31 +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 1A32F8FC17 for ; Tue, 20 Jan 2009 20:06:30 +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 232102061; Tue, 20 Jan 2009 22:06:30 +0200 Message-ID: <49762EC9.1010006@FreeBSD.org> Date: Tue, 20 Jan 2009 22:06:33 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> In-Reply-To: <49762CEF.1000405@FreeBSD.org> 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 20:06:32 -0000 Alexander Motin wrote: > M. Warner Losh wrote: >> In message: <20090120.122312.1543793985.imp@bsdimp.com> >> "M. Warner Losh" writes: >> : : 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. >> >> I've got the following patch, untested, that I think does what I think >> needs to be done. Not sure about the return value from update_ios... >> >> Index: at91_mci.c >> =================================================================== >> --- at91_mci.c (revision 187479) >> +++ at91_mci.c (working copy) >> @@ -201,7 +201,10 @@ >> sc->host.f_min = 375000; >> sc->host.f_max = 30000000; >> sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; >> - sc->host.caps = MMC_CAP_4_BIT_DATA; >> + if (sc->wire4) >> + sc->host.caps = MMC_CAP_4_BIT_DATA; >> + else >> + sc->host.caps = 0; >> child = device_add_child(dev, "mmc", 0); >> device_set_ivars(dev, &sc->host); >> err = bus_generic_attach(dev); > > Ok. I agree with this part. If for some reason you really need this > wire4 variable, this is the right way to use it. > >> @@ -295,6 +298,8 @@ >> clkdiv = (at91_master_clock / ios->clock) / 2; >> } >> if (ios->bus_width == bus_width_4 && sc->wire4) >> + return EINVAL; >> + if (ios->bus_width == bus_width_4) >> WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); >> else >> WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); >> > > This part is correct, but useless. If the first part have not set > MMC_CAP_4_BIT_DATA, then mmc layer will never request bus_width_4. > That's why I have proposed to remove " && sc->wire4" check from here. No, stop, this part is incorrect. Correct but useless would be: if (ios->bus_width == bus_width_4 && !sc->wire4) return EINVAL; -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 08:54:28 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 82F4A1065670 for ; Wed, 21 Jan 2009 08:54:28 +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 045788FC12 for ; Wed, 21 Jan 2009 08:54:27 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 232144662; Wed, 21 Jan 2009 10:54:27 +0200 Message-ID: <4976E2C2.4090002@FreeBSD.org> Date: Wed, 21 Jan 2009 10:54:26 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> In-Reply-To: <49762EC9.1010006@FreeBSD.org> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------030507030601000405000609" 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: Wed, 21 Jan 2009 08:54:28 -0000 This is a multi-part message in MIME format. --------------030507030601000405000609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Alexander Motin wrote: > Alexander Motin wrote: >> M. Warner Losh wrote: >>> In message: <20090120.122312.1543793985.imp@bsdimp.com> >>> "M. Warner Losh" writes: >>> : : 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. >>> >>> I've got the following patch, untested, that I think does what I think >>> needs to be done. Not sure about the return value from update_ios... I would prefer attached variant. It will also disable 4-bit support by default, but will make it properly. How do you plan to control that wire4 variable? With device.hints? -- Alexander Motin --------------030507030601000405000609 Content-Type: text/plain; name="at91_mci.c.wire4.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="at91_mci.c.wire4.patch" --- at91_mci.c.prev 2009-01-20 19:36:58.000000000 +0200 +++ at91_mci.c 2009-01-21 10:46:00.000000000 +0200 @@ -201,7 +201,10 @@ at91_mci_attach(device_t dev) sc->host.f_min = 375000; sc->host.f_max = 30000000; sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; - sc->host.caps = MMC_CAP_4_BIT_DATA; + if (sc->wire4) + sc->host.caps = MMC_CAP_4_BIT_DATA; + else + sc->host.caps = 0; child = device_add_child(dev, "mmc", 0); device_set_ivars(dev, &sc->host); err = bus_generic_attach(dev); @@ -294,7 +297,7 @@ at91_mci_update_ios(device_t brdev, devi else clkdiv = (at91_master_clock / ios->clock) / 2; } - if (ios->bus_width == bus_width_4 && sc->wire4) + if (ios->bus_width == bus_width_4) WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) | MCI_SDCR_SDCBUS); else WR4(sc, MCI_SDCR, RD4(sc, MCI_SDCR) & ~MCI_SDCR_SDCBUS); --------------030507030601000405000609-- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 09:24:49 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 199DB1065674; Wed, 21 Jan 2009 09:24:49 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id C04868FC2B; Wed, 21 Jan 2009 09:24:48 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 3D163C9C9; Wed, 21 Jan 2009 11:24:46 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68939-08; Wed, 21 Jan 2009 11:24:45 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 6CBADC501; Wed, 21 Jan 2009 11:24:45 +0200 (EET) Message-ID: <4976E9DB.3000803@bulinfo.net> Date: Wed, 21 Jan 2009 11:24:43 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Alexander Motin References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> In-Reply-To: <4976E2C2.4090002@FreeBSD.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Wed, 21 Jan 2009 09:24:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've tried the attached patch but the problem still exist. I see another strange things which may be related: On 7.1-STABLE: #fdisk -BI mmcsd0 ******* Working on device /dev/mmcsd0 ******* fdisk: Geom not found: "mmcsd0" #geom disk list Geom name: ad4 Providers: 1. Name: ad4 Mediasize: 250059350016 (233G) Sectorsize: 512 Mode: r5w5e6 fwsectors: 63 fwheads: 16 Geom name: mmcsd0 Providers: 1. Name: mmcsd0 Mediasize: 2012217344 (1.9G) Sectorsize: 512 Mode: r0w0e0 fwsectors: 0 fwheads: 0 Also sysinstall crashes when trying to create a new slice. May be because: Disk name: mmcsd0 FDISK Partition Editor DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) Alexander Motin wrote: > Alexander Motin wrote: >> Alexander Motin wrote: >>> M. Warner Losh wrote: >>>> In message: <20090120.122312.1543793985.imp@bsdimp.com> >>>> "M. Warner Losh" writes: >>>> : : 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. >>>> >>>> I've got the following patch, untested, that I think does what I think >>>> needs to be done. Not sure about the return value from update_ios... > > I would prefer attached variant. It will also disable 4-bit support by > default, but will make it properly. How do you plan to control that > wire4 variable? With device.hints? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdunaxJBWvpalMpkRAjzPAJ9LA9ZhZjPjIQiod3T5kR/JtIFW9ACgqddT ZiXkmV7ByTiAXn4PIG7LFl4= =vyt3 -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 09:50:39 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 785281065670 for ; Wed, 21 Jan 2009 09:50:39 +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 EFC918FC08 for ; Wed, 21 Jan 2009 09:50:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 232151477; Wed, 21 Jan 2009 11:50:38 +0200 Message-ID: <4976EFED.4010706@FreeBSD.org> Date: Wed, 21 Jan 2009 11:50:37 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Krassimir Slavchev References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> In-Reply-To: <4976E9DB.3000803@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------020403090708080602000605" 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: Wed, 21 Jan 2009 09:50:39 -0000 This is a multi-part message in MIME format. --------------020403090708080602000605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Krassimir Slavchev wrote: > I've tried the attached patch but the problem still exist. Then it is something different. It would be easier if I have some arm hardware to play with, but I have no. Try to apply this debugging patch. It should tell us what's going on there. > I see another strange things which may be related: > On 7.1-STABLE: > > #fdisk -BI mmcsd0 > > ******* Working on device /dev/mmcsd0 ******* > fdisk: Geom not found: "mmcsd0" > > #geom disk list > Geom name: ad4 > Providers: > 1. Name: ad4 > Mediasize: 250059350016 (233G) > Sectorsize: 512 > Mode: r5w5e6 > fwsectors: 63 > fwheads: 16 > > Geom name: mmcsd0 > Providers: > 1. Name: mmcsd0 > Mediasize: 2012217344 (1.9G) > Sectorsize: 512 > Mode: r0w0e0 > fwsectors: 0 > fwheads: 0 > > Also sysinstall crashes when trying to create a new slice. > May be because: > Disk name: mmcsd0 FDISK > Partition Editor > DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) I don't think it is related. There is no such thing as disk geometry on flash card, that's why driver does not announce it. The only places where it may be important is when fdisk is trying to align partitions with track boundaries for compatibility with legacy BIOS'es. There is no problem to report some fake values, but from one side they should better match BIOS assumptions on geometry and from other, they should as much as possible to match flash erase sector size. I just have no any system which supports SD booting to report something reasonable there. Reporting maximal 63 sectors per track as for HDD may result in ineffective filesystem alignment and reduced performance. -- Alexander Motin --------------020403090708080602000605 Content-Type: text/plain; name="mmc.c.debug.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mmc.c.debug.patch" --- mmc.c.prev 2008-12-25 11:50:18.000000000 +0200 +++ mmc.c 2009-01-21 11:39:31.000000000 +0200 @@ -315,11 +315,14 @@ mmc_wait_for_req(struct mmc_softc *sc, s req->done = mmc_wakeup; req->done_data = sc; + printf("CMD: %x ARG %x len %d\n", req->cmd->opcode, req->cmd->arg, + (int)(req->cmd->data)?req->cmd->data->len:0); MMCBR_REQUEST(device_get_parent(sc->dev), sc->dev, req); MMC_LOCK(sc); while ((req->flags & MMC_REQ_DONE) == 0) msleep(req, &sc->sc_mtx, 0, "mmcreq", 0); MMC_UNLOCK(sc); + printf("RES: %d\n", req->cmd->error); return (0); } --------------020403090708080602000605-- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 10:40:16 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 169B01065688; Wed, 21 Jan 2009 10:40:16 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 17BCE8FC0C; Wed, 21 Jan 2009 10:40:14 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id A720ACA24; Wed, 21 Jan 2009 12:40:12 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73765-09; Wed, 21 Jan 2009 12:40:11 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id DE48ACA01; Wed, 21 Jan 2009 12:40:11 +0200 (EET) Message-ID: <4976FB8C.5050209@bulinfo.net> Date: Wed, 21 Jan 2009 12:40:12 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Alexander Motin References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> In-Reply-To: <4976EFED.4010706@FreeBSD.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Wed, 21 Jan 2009 10:40:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is the output: CMD: 0 ARG 0 len 0 RES: 0 CMD: 8 ARG 1aa len 0 RES: 1 CMD: 37 ARG 0 len 0 RES: 0 CMD: 29 ARG 0 len 0 RES: 0 CMD: 0 ARG 0 len 0 RES: 0 CMD: 8 ARG 1aa len 0 RES: 1 CMD: 37 ARG 0 len 0 RES: 0 CMD: 29 ARG ff8000 len 0 RES: 0 CMD: 37 ARG 0 len 0 RES: 0 CMD: 29 ARG ff8000 len 0 RES: 0 CMD: 2 ARG 0 len 0 RES: 0 CMD: 3 ARG 0 len 0 RES: 0 CMD: 9 ARG 10000 len 0 RES: 0 CMD: 7 ARG 10000 len 0 RES: 0 CMD: 37 ARG 10000 len 0 RES: 0 CMD: 33 ARG 0 len 8 RES: 0 CMD: 6 ARG ffffff len 64 RES: 0 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 RES: 0 CMD: 7 ARG 0 len 0 RES: 0 CMD: 7 ARG 10000 len 0 RES: 0 CMD: 7 ARG 0 len 0 RES: 0 CMD: 7 ARG 10000 len 0 RES: 2 CMD: 6 ARG 80fffff0 len 64 RES: 0 CMD: 7 ARG 0 len 0 RES: 0 mmcsd0: 1983MB at mmc0 30MHz/1bit CMD: 7 ARG 10000 len 0 RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: 6 ARG 0 len 0 RES: 0 CMD: 11 ARG 0 len 512 RES: 0 CMD: 11 ARG 0 len 512 RES: 0 CMD: 11 ARG 200 len 512 RES: 0 Trying to mount root from ufs:/dev/mmcsd0s1 >> >> Also sysinstall crashes when trying to create a new slice. >> May be because: >> Disk name: mmcsd0 FDISK >> Partition Editor >> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) > > I don't think it is related. There is no such thing as disk geometry on > flash card, that's why driver does not announce it. The only places > where it may be important is when fdisk is trying to align partitions > with track boundaries for compatibility with legacy BIOS'es. > > There is no problem to report some fake values, but from one side they > should better match BIOS assumptions on geometry and from other, they > should as much as possible to match flash erase sector size. I just have > no any system which supports SD booting to report something reasonable > there. Reporting maximal 63 sectors per track as for HDD may result in > ineffective filesystem alignment and reduced performance. > > At least sysinstall should be fixed. Should I fill a PR for this? Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdvuMxJBWvpalMpkRAryjAJ9v4cj1FCZHFUx/csHsa3SDrjodHwCeNMSi wgWK6W4prQzbjJqzitiqcnw= =F7xk -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 13:01:29 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 36427106582B for ; Wed, 21 Jan 2009 13:01:29 +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 8AF218FC19 for ; Wed, 21 Jan 2009 13:01:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 232173098; Wed, 21 Jan 2009 15:01:27 +0200 Message-ID: <49771CA6.7080106@FreeBSD.org> Date: Wed, 21 Jan 2009 15:01:26 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Krassimir Slavchev References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> In-Reply-To: <4976FB8C.5050209@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 21 Jan 2009 13:01:30 -0000 Krassimir Slavchev wrote: > This is the output: > > CMD: 0 ARG 0 len 0 > RES: 0 > CMD: 8 ARG 1aa len 0 > RES: 1 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG 0 len 0 > RES: 0 > CMD: 0 ARG 0 len 0 > RES: 0 > CMD: 8 ARG 1aa len 0 > RES: 1 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG ff8000 len 0 > RES: 0 > CMD: 37 ARG 0 len 0 > RES: 0 > CMD: 29 ARG ff8000 len 0 > RES: 0 > CMD: 2 ARG 0 len 0 > RES: 0 > CMD: 3 ARG 0 len 0 > RES: 0 > CMD: 9 ARG 10000 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 0 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: 33 ARG 0 len 8 > RES: 0 > CMD: 6 ARG ffffff len 64 > RES: 0 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: d ARG 0 len 64 > RES: 2 > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: d ARG 0 len 64 > RES: 0 This part looks fine. Just normal SD detection and initialization. Somewhere here bus frequency and high-speed timings negotiated: > CMD: 7 ARG 0 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 0 > CMD: 7 ARG 0 len 0 > RES: 0 > CMD: 7 ARG 10000 len 0 > RES: 2 > CMD: 6 ARG 80fffff0 len 64 > RES: 0 > CMD: 7 ARG 0 len 0 > RES: 0 > mmcsd0: 1983MB at mmc0 30MHz/1bit Then regular card activity beging: - select the card - error > CMD: 7 ARG 10000 len 0 > RES: 2 - select bus width - normal ?? > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: 6 ARG 0 len 0 > RES: 0 - read some sectors - normal ?? > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 200 len 512 > RES: 0 > Trying to mount root from ufs:/dev/mmcsd0s1 It's a bis strange to me that this card selection request failed, while previous ones during initialization managed fine. May be card or controller unable to handle such speed, or may be bus just hasn't managed to settle new parameters until that command. Also interesting what are the reading command returned after card select command failed. Boot with verbose messages enabled should show when exactly frequency has changed. Do it please. >>> Also sysinstall crashes when trying to create a new slice. >>> May be because: >>> Disk name: mmcsd0 FDISK >>> Partition Editor >>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) >> I don't think it is related. There is no such thing as disk geometry on >> flash card, that's why driver does not announce it. The only places >> where it may be important is when fdisk is trying to align partitions >> with track boundaries for compatibility with legacy BIOS'es. > >> There is no problem to report some fake values, but from one side they >> should better match BIOS assumptions on geometry and from other, they >> should as much as possible to match flash erase sector size. I just have >> no any system which supports SD booting to report something reasonable >> there. Reporting maximal 63 sectors per track as for HDD may result in >> ineffective filesystem alignment and reduced performance. > > At least sysinstall should be fixed. Should I fill a PR for this? Probably yes. I haven't looked into sysinstall. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 13:30:27 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 7ADBE106564A; Wed, 21 Jan 2009 13:30:27 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id ED9A98FC16; Wed, 21 Jan 2009 13:30:26 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 56C44CA39; Wed, 21 Jan 2009 15:30:24 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85092-10; Wed, 21 Jan 2009 15:30:23 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 5004FC319; Wed, 21 Jan 2009 15:30:23 +0200 (EET) Message-ID: <4977236E.2020409@bulinfo.net> Date: Wed, 21 Jan 2009 15:30:22 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Alexander Motin References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> In-Reply-To: <49771CA6.7080106@FreeBSD.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Wed, 21 Jan 2009 13:30:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Boot with verbose messages is here: http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose Alexander Motin wrote: > Krassimir Slavchev wrote: >> This is the output: >> >> CMD: 0 ARG 0 len 0 >> RES: 0 >> CMD: 8 ARG 1aa len 0 >> RES: 1 >> CMD: 37 ARG 0 len 0 >> RES: 0 >> CMD: 29 ARG 0 len 0 >> RES: 0 >> CMD: 0 ARG 0 len 0 >> RES: 0 >> CMD: 8 ARG 1aa len 0 >> RES: 1 >> CMD: 37 ARG 0 len 0 >> RES: 0 >> CMD: 29 ARG ff8000 len 0 >> RES: 0 >> CMD: 37 ARG 0 len 0 >> RES: 0 >> CMD: 29 ARG ff8000 len 0 >> RES: 0 >> CMD: 2 ARG 0 len 0 >> RES: 0 >> CMD: 3 ARG 0 len 0 >> RES: 0 >> CMD: 9 ARG 10000 len 0 >> RES: 0 >> CMD: 7 ARG 10000 len 0 >> RES: 0 >> CMD: 37 ARG 10000 len 0 >> RES: 0 >> CMD: 33 ARG 0 len 8 >> RES: 0 >> CMD: 6 ARG ffffff len 64 >> RES: 0 >> CMD: 37 ARG 10000 len 0 >> RES: 0 >> CMD: d ARG 0 len 64 >> RES: 2 >> CMD: 37 ARG 10000 len 0 >> RES: 0 >> CMD: d ARG 0 len 64 >> RES: 0 > > This part looks fine. Just normal SD detection and initialization. > > Somewhere here bus frequency and high-speed timings negotiated: > >> CMD: 7 ARG 0 len 0 >> RES: 0 >> CMD: 7 ARG 10000 len 0 >> RES: 0 >> CMD: 7 ARG 0 len 0 >> RES: 0 >> CMD: 7 ARG 10000 len 0 >> RES: 2 >> CMD: 6 ARG 80fffff0 len 64 >> RES: 0 >> CMD: 7 ARG 0 len 0 >> RES: 0 >> mmcsd0: 1983MB at mmc0 30MHz/1bit > > Then regular card activity beging: > > - select the card - error >> CMD: 7 ARG 10000 len 0 >> RES: 2 > > - select bus width - normal ?? >> CMD: 37 ARG 10000 len 0 >> RES: 0 >> CMD: 6 ARG 0 len 0 >> RES: 0 > > - read some sectors - normal ?? >> CMD: 11 ARG 0 len 512 >> RES: 0 >> CMD: 11 ARG 0 len 512 >> RES: 0 >> CMD: 11 ARG 200 len 512 >> RES: 0 >> Trying to mount root from ufs:/dev/mmcsd0s1 > > It's a bis strange to me that this card selection request failed, while > previous ones during initialization managed fine. May be card or > controller unable to handle such speed, or may be bus just hasn't > managed to settle new parameters until that command. > Also interesting what are the reading command returned after card select > command failed. > > Boot with verbose messages enabled should show when exactly frequency > has changed. Do it please. > >>>> Also sysinstall crashes when trying to create a new slice. >>>> May be because: >>>> Disk name: mmcsd0 FDISK >>>> Partition Editor >>>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) >>> I don't think it is related. There is no such thing as disk geometry on >>> flash card, that's why driver does not announce it. The only places >>> where it may be important is when fdisk is trying to align partitions >>> with track boundaries for compatibility with legacy BIOS'es. >>> There is no problem to report some fake values, but from one side they >>> should better match BIOS assumptions on geometry and from other, they >>> should as much as possible to match flash erase sector size. I just have >>> no any system which supports SD booting to report something reasonable >>> there. Reporting maximal 63 sectors per track as for HDD may result in >>> ineffective filesystem alignment and reduced performance. >> At least sysinstall should be fixed. Should I fill a PR for this? > > Probably yes. I haven't looked into sysinstall. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdyNuxJBWvpalMpkRAljVAJ976HFJu0zPWWmgqSGM9NUkBFXltQCeO5am UNVeNhRajDLjuwMgqstKL1I= =V/UU -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 13:45:29 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 DE4961065CA3; Wed, 21 Jan 2009 13:45:29 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 725B08FC08; Wed, 21 Jan 2009 13:45:29 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id C5410CA31; Wed, 21 Jan 2009 15:45:26 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86581-10; Wed, 21 Jan 2009 15:45:25 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id C21BBC319; Wed, 21 Jan 2009 15:45:25 +0200 (EET) Message-ID: <497726F5.5080000@bulinfo.net> Date: Wed, 21 Jan 2009 15:45:25 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Alexander Motin References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> In-Reply-To: <4977236E.2020409@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Wed, 21 Jan 2009 13:45:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Oops, sorry this output was without SD card inserted! I've changed the file. Best Regards Krassimir Slavchev wrote: > Boot with verbose messages is here: > > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose > > > Alexander Motin wrote: >> Krassimir Slavchev wrote: >>> This is the output: >>> >>> CMD: 0 ARG 0 len 0 >>> RES: 0 >>> CMD: 8 ARG 1aa len 0 >>> RES: 1 >>> CMD: 37 ARG 0 len 0 >>> RES: 0 >>> CMD: 29 ARG 0 len 0 >>> RES: 0 >>> CMD: 0 ARG 0 len 0 >>> RES: 0 >>> CMD: 8 ARG 1aa len 0 >>> RES: 1 >>> CMD: 37 ARG 0 len 0 >>> RES: 0 >>> CMD: 29 ARG ff8000 len 0 >>> RES: 0 >>> CMD: 37 ARG 0 len 0 >>> RES: 0 >>> CMD: 29 ARG ff8000 len 0 >>> RES: 0 >>> CMD: 2 ARG 0 len 0 >>> RES: 0 >>> CMD: 3 ARG 0 len 0 >>> RES: 0 >>> CMD: 9 ARG 10000 len 0 >>> RES: 0 >>> CMD: 7 ARG 10000 len 0 >>> RES: 0 >>> CMD: 37 ARG 10000 len 0 >>> RES: 0 >>> CMD: 33 ARG 0 len 8 >>> RES: 0 >>> CMD: 6 ARG ffffff len 64 >>> RES: 0 >>> CMD: 37 ARG 10000 len 0 >>> RES: 0 >>> CMD: d ARG 0 len 64 >>> RES: 2 >>> CMD: 37 ARG 10000 len 0 >>> RES: 0 >>> CMD: d ARG 0 len 64 >>> RES: 0 >> This part looks fine. Just normal SD detection and initialization. > >> Somewhere here bus frequency and high-speed timings negotiated: > >>> CMD: 7 ARG 0 len 0 >>> RES: 0 >>> CMD: 7 ARG 10000 len 0 >>> RES: 0 >>> CMD: 7 ARG 0 len 0 >>> RES: 0 >>> CMD: 7 ARG 10000 len 0 >>> RES: 2 >>> CMD: 6 ARG 80fffff0 len 64 >>> RES: 0 >>> CMD: 7 ARG 0 len 0 >>> RES: 0 >>> mmcsd0: 1983MB at mmc0 30MHz/1bit >> Then regular card activity beging: > >> - select the card - error >>> CMD: 7 ARG 10000 len 0 >>> RES: 2 >> - select bus width - normal ?? >>> CMD: 37 ARG 10000 len 0 >>> RES: 0 >>> CMD: 6 ARG 0 len 0 >>> RES: 0 >> - read some sectors - normal ?? >>> CMD: 11 ARG 0 len 512 >>> RES: 0 >>> CMD: 11 ARG 0 len 512 >>> RES: 0 >>> CMD: 11 ARG 200 len 512 >>> RES: 0 >>> Trying to mount root from ufs:/dev/mmcsd0s1 >> It's a bis strange to me that this card selection request failed, while >> previous ones during initialization managed fine. May be card or >> controller unable to handle such speed, or may be bus just hasn't >> managed to settle new parameters until that command. >> Also interesting what are the reading command returned after card select >> command failed. > >> Boot with verbose messages enabled should show when exactly frequency >> has changed. Do it please. > >>>>> Also sysinstall crashes when trying to create a new slice. >>>>> May be because: >>>>> Disk name: mmcsd0 FDISK >>>>> Partition Editor >>>>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) >>>> I don't think it is related. There is no such thing as disk geometry on >>>> flash card, that's why driver does not announce it. The only places >>>> where it may be important is when fdisk is trying to align partitions >>>> with track boundaries for compatibility with legacy BIOS'es. >>>> There is no problem to report some fake values, but from one side they >>>> should better match BIOS assumptions on geometry and from other, they >>>> should as much as possible to match flash erase sector size. I just have >>>> no any system which supports SD booting to report something reasonable >>>> there. Reporting maximal 63 sectors per track as for HDD may result in >>>> ineffective filesystem alignment and reduced performance. >>> At least sysinstall should be fixed. Should I fill a PR for this? >> Probably yes. I haven't looked into sysinstall. > > _______________________________________________ freebsd-arm@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdyb0xJBWvpalMpkRAp6fAJ4/nwjwzvJ2gJuH8pGSpjKKhSZFBQCggIhs 1kc1rDx4i88ulndFuCLIW1Q= =lwV7 -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 13:59:10 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 213E110656C9 for ; Wed, 21 Jan 2009 13:59:10 +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 9977D8FC24 for ; Wed, 21 Jan 2009 13:59:09 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 232180690; Wed, 21 Jan 2009 15:59:08 +0200 Message-ID: <49772A2C.7090903@FreeBSD.org> Date: Wed, 21 Jan 2009 15:59:08 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Krassimir Slavchev References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> In-Reply-To: <497726F5.5080000@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 21 Jan 2009 13:59:11 -0000 Krassimir Slavchev wrote: > Oops, sorry this output was without SD card inserted! > I've changed the file. That's some different debugging. I have meant that one, which happens when boot_verbose="YES" added to loader.conf, or respective Fx button pressed during boot on PC. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 14:09:20 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 CC2EF10656E1; Wed, 21 Jan 2009 14:09:20 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5D58FC2B; Wed, 21 Jan 2009 14:09:20 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id C6140CA4B; Wed, 21 Jan 2009 16:09:17 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88650-08; Wed, 21 Jan 2009 16:09:15 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 131F1C195; Wed, 21 Jan 2009 16:09:15 +0200 (EET) Message-ID: <49772C8A.5020402@bulinfo.net> Date: Wed, 21 Jan 2009 16:09:14 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Alexander Motin References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> In-Reply-To: <49772A2C.7090903@FreeBSD.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Wed, 21 Jan 2009 14:09:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Motin wrote: > Krassimir Slavchev wrote: >> Oops, sorry this output was without SD card inserted! >> I've changed the file. > > That's some different debugging. I have meant that one, which happens > when boot_verbose="YES" added to loader.conf, or respective Fx button > pressed during boot on PC. > Yes this is with kernel VERBOSE_SYSINIT option because I cannot set boot_verbose from arm boot loader. Verbose messages from which modules you want to see? I will set bootverbose manually. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdyyKxJBWvpalMpkRAsBbAKCLUOVoOsBScAqSOkSbSPuedqQi/gCZAcU5 PzlVXZfnW4xDrs5lwrISpd4= =wWIY -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 14:19:39 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 3E1181065D62 for ; Wed, 21 Jan 2009 14:19:39 +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 D32368FC1D for ; Wed, 21 Jan 2009 14:19:35 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 232182817; Wed, 21 Jan 2009 16:19:34 +0200 Message-ID: <49772EF1.1060207@FreeBSD.org> Date: Wed, 21 Jan 2009 16:19:29 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Krassimir Slavchev References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> In-Reply-To: <49772C8A.5020402@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: multipart/mixed; boundary="------------090900070404000504090305" 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: Wed, 21 Jan 2009 14:19:50 -0000 This is a multi-part message in MIME format. --------------090900070404000504090305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Krassimir Slavchev wrote: > Alexander Motin wrote: >> Krassimir Slavchev wrote: >>> Oops, sorry this output was without SD card inserted! >>> I've changed the file. >> That's some different debugging. I have meant that one, which happens >> when boot_verbose="YES" added to loader.conf, or respective Fx button >> pressed during boot on PC. > > Yes this is with kernel VERBOSE_SYSINIT option because I cannot set > boot_verbose from arm boot loader. > Verbose messages from which modules you want to see? I will set > bootverbose manually. mmc. And while being there, apply this one please. -- Alexander Motin --------------090900070404000504090305 Content-Type: text/plain; name="mmc.c.debug2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mmc.c.debug2.patch" --- mmc.c1 2008-12-25 11:50:18.000000000 +0200 +++ mmc.c 2009-01-21 16:15:27.000000000 +0200 @@ -1322,11 +1322,12 @@ mmc_calculate_clock(struct mmc_softc *sc panic("can't get children"); for (i = 0; i < nkid; i++) { ivar = device_get_ivars(kids[i]); +printf("timing %d, rate %d, hsrate %d\n", ivar->timing, ivar->tran_speed, ivar->hs_tran_speed); if (ivar->timing < max_timing) max_timing = ivar->timing; if (ivar->tran_speed < max_dtr) max_dtr = ivar->tran_speed; - if (ivar->hs_tran_speed < max_dtr) + if (ivar->hs_tran_speed < max_hs_dtr) max_hs_dtr = ivar->hs_tran_speed; } for (i = 0; i < nkid; i++) { --------------090900070404000504090305-- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 14:26:43 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 D7370106568F; Wed, 21 Jan 2009 14:26:43 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 875A78FC13; Wed, 21 Jan 2009 14:26:43 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id CD652CA41; Wed, 21 Jan 2009 16:26:40 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89374-08; Wed, 21 Jan 2009 16:26:40 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 193E9C195; Wed, 21 Jan 2009 16:26:40 +0200 (EET) Message-ID: <4977309F.2020402@bulinfo.net> Date: Wed, 21 Jan 2009 16:26:39 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Alexander Motin References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> <49772EF1.1060207@FreeBSD.org> In-Reply-To: <49772EF1.1060207@FreeBSD.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Wed, 21 Jan 2009 14:26:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... CMD: 7 ARG 0 len 0 RES: 0 timing 1, rate 30000000, hsrate 50000000 CMD: 7 ARG 10000 len 0 RES: 2 CMD: 6 ARG 80fffff0 len 64 RES: 0 CMD: 7 ARG 0 len 0 RES: 0 mmc0: setting transfer rate to 30.000MHz mmcsd0: 1983MB at mmc0 30MHz/1bit CMD: 7 ARG 10000 len 0 RES: 2 mmc0: setting bus width to 1 bits CMD: 37 ARG 10000 len 0 RES: 0 CMD: 6 ARG 0 len 0 RES: 0 CMD: 11 ARG 0 len 512 RES: 0 CMD: 11 ARG 0 len 512 RES: 0 CMD: 11 ARG 200 len 512 RES: 0 Trying to mount root from ufs:/dev/mmcsd0s1 Alexander Motin wrote: > Krassimir Slavchev wrote: >> Alexander Motin wrote: >>> Krassimir Slavchev wrote: >>>> Oops, sorry this output was without SD card inserted! >>>> I've changed the file. >>> That's some different debugging. I have meant that one, which happens >>> when boot_verbose="YES" added to loader.conf, or respective Fx button >>> pressed during boot on PC. >> Yes this is with kernel VERBOSE_SYSINIT option because I cannot set >> boot_verbose from arm boot loader. >> Verbose messages from which modules you want to see? I will set >> bootverbose manually. > > mmc. And while being there, apply this one please. > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJdzCfxJBWvpalMpkRAm1AAKCwNkuBrI6uBwfC4ZlrkpLgTqXc/wCeIM0j AGdwpQCQvBceK1HzyCF7xEM= =TLd2 -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 15:35:47 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 05D581065672; Wed, 21 Jan 2009 15:35:47 +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 BA19D8FC12; Wed, 21 Jan 2009 15:35:46 +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 n0LFY0rP024798; Wed, 21 Jan 2009 08:34:00 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 08:34:38 -0700 (MST) Message-Id: <20090121.083438.1081366624.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <4976E2C2.4090002@FreeBSD.org> References: <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@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: Wed, 21 Jan 2009 15:35:47 -0000 In message: <4976E2C2.4090002@FreeBSD.org> Alexander Motin writes: : Alexander Motin wrote: : > Alexander Motin wrote: : >> M. Warner Losh wrote: : >>> In message: <20090120.122312.1543793985.imp@bsdimp.com> : >>> "M. Warner Losh" writes: : >>> : : 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. : >>> : >>> I've got the following patch, untested, that I think does what I think : >>> needs to be done. Not sure about the return value from update_ios... : : I would prefer attached variant. It will also disable 4-bit support by : default, but will make it properly. How do you plan to control that : wire4 variable? With device.hints? It is part of the board-variant work that I have in flight. I'm not 100% sure the exact mechanism, but the meta-data about how the device is wired will be provided by "the parent device" in some way. I'm still working out the details. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 15:42:55 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 603BB106584D; Wed, 21 Jan 2009 15:42:55 +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 045318FC1B; Wed, 21 Jan 2009 15:42:54 +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 n0LFf4XO024847; Wed, 21 Jan 2009 08:41:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 08:41:41 -0700 (MST) Message-Id: <20090121.084141.-1119405090.imp@bsdimp.com> To: mav@freebsd.org From: "M. Warner Losh" In-Reply-To: <49772A2C.7090903@FreeBSD.org> References: <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@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: Wed, 21 Jan 2009 15:42:57 -0000 In message: <49772A2C.7090903@FreeBSD.org> Alexander Motin writes: : Krassimir Slavchev wrote: : > Oops, sorry this output was without SD card inserted! : > I've changed the file. : : That's some different debugging. I have meant that one, which happens : when boot_verbose="YES" added to loader.conf, or respective Fx button : pressed during boot on PC. You can't do either of those on the ARM platform. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 15:42:57 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 06B5C1065863; Wed, 21 Jan 2009 15:42:57 +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 B66FC8FC1E; Wed, 21 Jan 2009 15:42:56 +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 n0LFfOe1024849; Wed, 21 Jan 2009 08:41:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 08:42:02 -0700 (MST) Message-Id: <20090121.084202.96341656.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <49772C8A.5020402@bulinfo.net> References: <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> 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: mav@freebsd.org, 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: Wed, 21 Jan 2009 15:42:59 -0000 In message: <49772C8A.5020402@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : Alexander Motin wrote: : > Krassimir Slavchev wrote: : >> Oops, sorry this output was without SD card inserted! : >> I've changed the file. : > : > That's some different debugging. I have meant that one, which happens : > when boot_verbose="YES" added to loader.conf, or respective Fx button : > pressed during boot on PC. : > : : Yes this is with kernel VERBOSE_SYSINIT option because I cannot set : boot_verbose from arm boot loader. : Verbose messages from which modules you want to see? I will set : bootverbose manually. Which boot loader are you using? Warner From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 15:42:59 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 60E26106567E; Wed, 21 Jan 2009 15:42:59 +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 0DE598FC12; Wed, 21 Jan 2009 15:42:58 +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 n0LFdkTD024838; Wed, 21 Jan 2009 08:39:46 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 08:40:23 -0700 (MST) Message-Id: <20090121.084023.188100520.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <4977236E.2020409@bulinfo.net> References: <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> 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: mav@freebsd.org, 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: Wed, 21 Jan 2009 15:43:00 -0000 In message: <4977236E.2020409@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : Boot with verbose messages is here: : : http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose This looks very similar to the data corruption I saw when I had enabled multiblock read. To track this down, we're going to have to print the actual data returned for each sector... Warner : Alexander Motin wrote: : > Krassimir Slavchev wrote: : >> This is the output: : >> : >> CMD: 0 ARG 0 len 0 : >> RES: 0 : >> CMD: 8 ARG 1aa len 0 : >> RES: 1 : >> CMD: 37 ARG 0 len 0 : >> RES: 0 : >> CMD: 29 ARG 0 len 0 : >> RES: 0 : >> CMD: 0 ARG 0 len 0 : >> RES: 0 : >> CMD: 8 ARG 1aa len 0 : >> RES: 1 : >> CMD: 37 ARG 0 len 0 : >> RES: 0 : >> CMD: 29 ARG ff8000 len 0 : >> RES: 0 : >> CMD: 37 ARG 0 len 0 : >> RES: 0 : >> CMD: 29 ARG ff8000 len 0 : >> RES: 0 : >> CMD: 2 ARG 0 len 0 : >> RES: 0 : >> CMD: 3 ARG 0 len 0 : >> RES: 0 : >> CMD: 9 ARG 10000 len 0 : >> RES: 0 : >> CMD: 7 ARG 10000 len 0 : >> RES: 0 : >> CMD: 37 ARG 10000 len 0 : >> RES: 0 : >> CMD: 33 ARG 0 len 8 : >> RES: 0 : >> CMD: 6 ARG ffffff len 64 : >> RES: 0 : >> CMD: 37 ARG 10000 len 0 : >> RES: 0 : >> CMD: d ARG 0 len 64 : >> RES: 2 : >> CMD: 37 ARG 10000 len 0 : >> RES: 0 : >> CMD: d ARG 0 len 64 : >> RES: 0 : > : > This part looks fine. Just normal SD detection and initialization. : > : > Somewhere here bus frequency and high-speed timings negotiated: : > : >> CMD: 7 ARG 0 len 0 : >> RES: 0 : >> CMD: 7 ARG 10000 len 0 : >> RES: 0 : >> CMD: 7 ARG 0 len 0 : >> RES: 0 : >> CMD: 7 ARG 10000 len 0 : >> RES: 2 : >> CMD: 6 ARG 80fffff0 len 64 : >> RES: 0 : >> CMD: 7 ARG 0 len 0 : >> RES: 0 : >> mmcsd0: 1983MB at mmc0 30MHz/1bit : > : > Then regular card activity beging: : > : > - select the card - error : >> CMD: 7 ARG 10000 len 0 : >> RES: 2 : > : > - select bus width - normal ?? : >> CMD: 37 ARG 10000 len 0 : >> RES: 0 : >> CMD: 6 ARG 0 len 0 : >> RES: 0 : > : > - read some sectors - normal ?? : >> CMD: 11 ARG 0 len 512 : >> RES: 0 : >> CMD: 11 ARG 0 len 512 : >> RES: 0 : >> CMD: 11 ARG 200 len 512 : >> RES: 0 : >> Trying to mount root from ufs:/dev/mmcsd0s1 : > : > It's a bis strange to me that this card selection request failed, while : > previous ones during initialization managed fine. May be card or : > controller unable to handle such speed, or may be bus just hasn't : > managed to settle new parameters until that command. : > Also interesting what are the reading command returned after card select : > command failed. : > : > Boot with verbose messages enabled should show when exactly frequency : > has changed. Do it please. : > : >>>> Also sysinstall crashes when trying to create a new slice. : >>>> May be because: : >>>> Disk name: mmcsd0 FDISK : >>>> Partition Editor : >>>> DISK Geometry: 0 cyls/0 heads/0 sectors = 0 sectors (0MB) : >>> I don't think it is related. There is no such thing as disk geometry on : >>> flash card, that's why driver does not announce it. The only places : >>> where it may be important is when fdisk is trying to align partitions : >>> with track boundaries for compatibility with legacy BIOS'es. : >>> There is no problem to report some fake values, but from one side they : >>> should better match BIOS assumptions on geometry and from other, they : >>> should as much as possible to match flash erase sector size. I just have : >>> no any system which supports SD booting to report something reasonable : >>> there. Reporting maximal 63 sectors per track as for HDD may result in : >>> ineffective filesystem alignment and reduced performance. : >> At least sysinstall should be fixed. Should I fill a PR for this? : > : > Probably yes. I haven't looked into sysinstall. : > : : -----BEGIN PGP SIGNATURE----- : Version: GnuPG v1.4.7 (FreeBSD) : : iD8DBQFJdyNuxJBWvpalMpkRAljVAJ976HFJu0zPWWmgqSGM9NUkBFXltQCeO5am : UNVeNhRajDLjuwMgqstKL1I= : =V/UU : -----END PGP SIGNATURE----- : : From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 15:50:57 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 A286E106564A; Wed, 21 Jan 2009 15:50:57 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 580FC8FC18; Wed, 21 Jan 2009 15:50:57 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 31DDECA34; Wed, 21 Jan 2009 17:50:54 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95715-03; Wed, 21 Jan 2009 17:50:53 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 43E35C501; Wed, 21 Jan 2009 17:50:53 +0200 (EET) Message-ID: <4977445C.1090504@bulinfo.net> Date: Wed, 21 Jan 2009 17:50:52 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: "M. Warner Losh" References: <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> <20090121.084202.96341656.imp@bsdimp.com> In-Reply-To: <20090121.084202.96341656.imp@bsdimp.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: mav@freebsd.org, 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: Wed, 21 Jan 2009 15:50:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <49772C8A.5020402@bulinfo.net> > Krassimir Slavchev writes: > : -----BEGIN PGP SIGNED MESSAGE----- > : Hash: SHA1 > : > : Alexander Motin wrote: > : > Krassimir Slavchev wrote: > : >> Oops, sorry this output was without SD card inserted! > : >> I've changed the file. > : > > : > That's some different debugging. I have meant that one, which happens > : > when boot_verbose="YES" added to loader.conf, or respective Fx button > : > pressed during boot on PC. > : > > : > : Yes this is with kernel VERBOSE_SYSINIT option because I cannot set > : boot_verbose from arm boot loader. > : Verbose messages from which modules you want to see? I will set > : bootverbose manually. > > Which boot loader are you using? > > Warner > I am using bootspi to boot from TFTP server. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJd0RcxJBWvpalMpkRAo1VAJ4noAvXXowkr6StHIp5gJR5RdvA5gCdF/OM XBYxIDm3WK8iOFMpH529IHE= =Qbu+ -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 16:03:08 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 AD1AE106566C; Wed, 21 Jan 2009 16:03:08 +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 676F88FC08; Wed, 21 Jan 2009 16:03:08 +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 n0LG0HHT025104; Wed, 21 Jan 2009 09:00:17 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 09:00:54 -0700 (MST) Message-Id: <20090121.090054.107772597.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <4977445C.1090504@bulinfo.net> References: <49772C8A.5020402@bulinfo.net> <20090121.084202.96341656.imp@bsdimp.com> <4977445C.1090504@bulinfo.net> 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: mav@FreeBSD.org, 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: Wed, 21 Jan 2009 16:03:09 -0000 In message: <4977445C.1090504@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : M. Warner Losh wrote: : > In message: <49772C8A.5020402@bulinfo.net> : > Krassimir Slavchev writes: : > : -----BEGIN PGP SIGNED MESSAGE----- : > : Hash: SHA1 : > : : > : Alexander Motin wrote: : > : > Krassimir Slavchev wrote: : > : >> Oops, sorry this output was without SD card inserted! : > : >> I've changed the file. : > : > : > : > That's some different debugging. I have meant that one, which happens : > : > when boot_verbose="YES" added to loader.conf, or respective Fx button : > : > pressed during boot on PC. : > : > : > : : > : Yes this is with kernel VERBOSE_SYSINIT option because I cannot set : > : boot_verbose from arm boot loader. : > : Verbose messages from which modules you want to see? I will set : > : bootverbose manually. : > : > Which boot loader are you using? : > : > Warner : > : : I am using bootspi to boot from TFTP server. Hmmmm.... That makes it harder to add a -v flag to get bootverbose... Warner From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 16:10:04 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 4534B106564A for ; Wed, 21 Jan 2009 16:10:04 +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 B88E18FC29 for ; Wed, 21 Jan 2009 16:10:03 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 232197017; Wed, 21 Jan 2009 18:10:02 +0200 Message-ID: <497748D9.2040607@FreeBSD.org> Date: Wed, 21 Jan 2009 18:10:01 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Krassimir Slavchev References: <20090120.114051.-854291995.imp@bsdimp.com> <4976215B.40302@FreeBSD.org> <20090120.122312.1543793985.imp@bsdimp.com> <20090120.123230.-272218744.imp@bsdimp.com> <49762CEF.1000405@FreeBSD.org> <49762EC9.1010006@FreeBSD.org> <4976E2C2.4090002@FreeBSD.org> <4976E9DB.3000803@bulinfo.net> <4976EFED.4010706@FreeBSD.org> <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <49772C8A.5020402@bulinfo.net> <49772EF1.1060207@FreeBSD.org> <4977309F.2020402@bulinfo.net> In-Reply-To: <4977309F.2020402@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 21 Jan 2009 16:10:04 -0000 Krassimir Slavchev wrote: > ... > CMD: 7 ARG 0 len 0 > RES: 0 Before this point mmc_rescan_cards() have successfully selected all the cards. Then at this point mmcbr_set_bus_mode(dev, pushpull); mmcbr_update_ios(dev); were called. And after that same request inside mmc_calculate_clock() has failed. That's strange. > timing 1, rate 30000000, hsrate 50000000 > CMD: 7 ARG 10000 len 0 > RES: 2 Open drain bus mode control is not implemented by sdhci driver, so I haven't looked at it close. Quick look around shows that push-pull mode was set there even without that last call. May be I am wrong, but first line looks useless. mmcbr_update_ios(dev) writes to the controller bus control registers, may be it affects something, or bus require some time to settle after it? > CMD: 6 ARG 80fffff0 len 64 > RES: 0 > CMD: 7 ARG 0 len 0 > RES: 0 > mmc0: setting transfer rate to 30.000MHz > mmcsd0: 1983MB at mmc0 30MHz/1bit Bus frequency changed here. SD specification allows frequencies up to 25MHz without high speed timings used, but cards like this one ofter declare a bit higher frequencies in legacy mode. May be we should just to try to limit it to some safe value? You may just try to set max_dtr = 5000000; in mmc_calculate_clock(), before "if (bootverbose) {". > CMD: 7 ARG 10000 len 0 > RES: 2 > mmc0: setting bus width to 1 bits > CMD: 37 ARG 10000 len 0 > RES: 0 > CMD: 6 ARG 0 len 0 > RES: 0 > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 0 len 512 > RES: 0 > CMD: 11 ARG 200 len 512 > RES: 0 > Trying to mount root from ufs:/dev/mmcsd0s1 > > Alexander Motin wrote: >> Krassimir Slavchev wrote: >>> Alexander Motin wrote: >>>> Krassimir Slavchev wrote: >>>>> Oops, sorry this output was without SD card inserted! >>>>> I've changed the file. >>>> That's some different debugging. I have meant that one, which happens >>>> when boot_verbose="YES" added to loader.conf, or respective Fx button >>>> pressed during boot on PC. >>> Yes this is with kernel VERBOSE_SYSINIT option because I cannot set >>> boot_verbose from arm boot loader. >>> Verbose messages from which modules you want to see? I will set >>> bootverbose manually. >> mmc. And while being there, apply this one please. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 16:40:46 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 E1EED106568A; Wed, 21 Jan 2009 16:40:46 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 970BD8FC08; Wed, 21 Jan 2009 16:40:46 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id C2ED3CA37; Wed, 21 Jan 2009 18:40:43 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97735-04; Wed, 21 Jan 2009 18:40:41 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id EB5DCCA29; Wed, 21 Jan 2009 18:40:40 +0200 (EET) Message-ID: <4977500A.7060902@bulinfo.net> Date: Wed, 21 Jan 2009 18:40:42 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: "M. Warner Losh" References: <4976FB8C.5050209@bulinfo.net> <49771CA6.7080106@FreeBSD.org> <4977236E.2020409@bulinfo.net> <20090121.084023.188100520.imp@bsdimp.com> In-Reply-To: <20090121.084023.188100520.imp@bsdimp.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: mav@freebsd.org, 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: Wed, 21 Jan 2009 16:40:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <4977236E.2020409@bulinfo.net> > Krassimir Slavchev writes: > Boot with verbose messages is here: > > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose > >> This looks very similar to the data corruption I saw when I had >> enabled multiblock read. To track this down, we're going to have to >> print the actual data returned for each sector... > >> Warner Here is a dump of data right after the byte swapping in at91_mci_read_done(): http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump and here is the first 1M of the SD card: http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJd1AJxJBWvpalMpkRAqWtAKC3EUilDCO0xao7N5xalFL2D9iMSACfVlwa 4UK5WYmLGlb22iHjFiDgFh0= =zi6J -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 16:48:29 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 B2D1C106566B; Wed, 21 Jan 2009 16:48:29 +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 2E7918FC16; Wed, 21 Jan 2009 16:48:29 +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 n0LGjdjQ025658; Wed, 21 Jan 2009 09:45:39 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 09:46:16 -0700 (MST) Message-Id: <20090121.094616.639845519.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <497748D9.2040607@FreeBSD.org> References: <49772EF1.1060207@FreeBSD.org> <4977309F.2020402@bulinfo.net> <497748D9.2040607@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: Wed, 21 Jan 2009 16:48:30 -0000 In message: <497748D9.2040607@FreeBSD.org> Alexander Motin writes: : Krassimir Slavchev wrote: : > ... : > CMD: 7 ARG 0 len 0 : > RES: 0 : : Before this point mmc_rescan_cards() have successfully selected all the : cards. Then at this point : mmcbr_set_bus_mode(dev, pushpull); : : mmcbr_update_ios(dev); : were called. And after that same request inside mmc_calculate_clock() : has failed. That's strange. : : > timing 1, rate 30000000, hsrate 50000000 : > CMD: 7 ARG 10000 len 0 : > RES: 2 : : Open drain bus mode control is not implemented by sdhci driver, so I : haven't looked at it close. Quick look around shows that push-pull mode : was set there even without that last call. May be I am wrong, but first : line looks useless. mmcbr_update_ios(dev) writes to the controller bus : control registers, may be it affects something, or bus require some time : to settle after it? Without open drain bus mode, I don't think that you can properly do MMC cards. At least I couldn't with the AT91 when I was developing it. The open drain mode is what allows us to select the one mmc card we're talking to. : > CMD: 6 ARG 80fffff0 len 64 : > RES: 0 : > CMD: 7 ARG 0 len 0 : > RES: 0 : > mmc0: setting transfer rate to 30.000MHz : > mmcsd0: 1983MB at mmc0 30MHz/1bit : : Bus frequency changed here. SD specification allows frequencies up to : 25MHz without high speed timings used, but cards like this one ofter : declare a bit higher frequencies in legacy mode. May be we should just : to try to limit it to some safe value? You may just try to set : max_dtr = 5000000; : in mmc_calculate_clock(), before "if (bootverbose) {". The AT91 stuff works well in high speed mode, but the internal clocks of the AT91 may limit it to a number less than 50MHz. The 30MHz limit actually should be at91_master_clock / 2, so that's a bit of a bug in the driver (which I've fixed in my tree). I've made 30MHz work on the prior version of the code, so there's not a hardware limitation. BTW, at91_master_clock is 60,000,000 by default, so we can't go higher than 30MHz on those boards. Warner : > CMD: 7 ARG 10000 len 0 : > RES: 2 : > mmc0: setting bus width to 1 bits : > CMD: 37 ARG 10000 len 0 : > RES: 0 : > CMD: 6 ARG 0 len 0 : > RES: 0 : > CMD: 11 ARG 0 len 512 : > RES: 0 : > CMD: 11 ARG 0 len 512 : > RES: 0 : > CMD: 11 ARG 200 len 512 : > RES: 0 : > Trying to mount root from ufs:/dev/mmcsd0s1 : > : > Alexander Motin wrote: : >> Krassimir Slavchev wrote: : >>> Alexander Motin wrote: : >>>> Krassimir Slavchev wrote: : >>>>> Oops, sorry this output was without SD card inserted! : >>>>> I've changed the file. : >>>> That's some different debugging. I have meant that one, which happens : >>>> when boot_verbose="YES" added to loader.conf, or respective Fx button : >>>> pressed during boot on PC. : >>> Yes this is with kernel VERBOSE_SYSINIT option because I cannot set : >>> boot_verbose from arm boot loader. : >>> Verbose messages from which modules you want to see? I will set : >>> bootverbose manually. : >> mmc. And while being there, apply this one please. : : -- : Alexander Motin : : From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 17:06:34 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 0F2BB1065672; Wed, 21 Jan 2009 17:06:34 +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 C0D9E8FC12; Wed, 21 Jan 2009 17:06:33 +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 n0LH4un7025872; Wed, 21 Jan 2009 10:04:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 10:05:33 -0700 (MST) Message-Id: <20090121.100533.-1955669401.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <4977500A.7060902@bulinfo.net> References: <4977236E.2020409@bulinfo.net> <20090121.084023.188100520.imp@bsdimp.com> <4977500A.7060902@bulinfo.net> 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: mav@FreeBSD.org, 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: Wed, 21 Jan 2009 17:06:34 -0000 In message: <4977500A.7060902@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : M. Warner Losh wrote: : > In message: <4977236E.2020409@bulinfo.net> : > Krassimir Slavchev writes: : > Boot with verbose messages is here: : > : > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose : > : >> This looks very similar to the data corruption I saw when I had : >> enabled multiblock read. To track this down, we're going to have to : >> print the actual data returned for each sector... : > : >> Warner : : : Here is a dump of data right after the byte swapping in : at91_mci_read_done(): : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump : : and here is the first 1M of the SD card: : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin Looks like we're getting some data corruption: CMD: 11 ARG 0 len 512 ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 ... and then: CMD: 11 ARG 0 len 512 00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 ... So it looks like the first 4 bytes are corrupted on the read. If you look closely at the data on the device, you'll see that 'fc 31 c0 8e' are the first 4 bytes of the reads are the 'left over' data from prior data streams. This didn't used to be the case in the prior code before the recent changes. The only way we're going to find the bad change is to do a binary search on the svn changes to find out where we go off the rails. This problem seems familiar to me, but I can't quite put my finger on what the root-cause was last time I had it. Warner From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 17:15:17 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 3900C1065672; Wed, 21 Jan 2009 17:15:17 +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 DC4508FC08; Wed, 21 Jan 2009 17:15:16 +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 n0LHEMRC026015; Wed, 21 Jan 2009 10:14:22 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 10:14:59 -0700 (MST) Message-Id: <20090121.101459.2022307528.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <20090121.100533.-1955669401.imp@bsdimp.com> References: <20090121.084023.188100520.imp@bsdimp.com> <4977500A.7060902@bulinfo.net> <20090121.100533.-1955669401.imp@bsdimp.com> 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: mav@FreeBSD.org, 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: Wed, 21 Jan 2009 17:15:17 -0000 In message: <20090121.100533.-1955669401.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <4977500A.7060902@bulinfo.net> : Krassimir Slavchev writes: : : -----BEGIN PGP SIGNED MESSAGE----- : : Hash: SHA1 : : : : M. Warner Losh wrote: : : > In message: <4977236E.2020409@bulinfo.net> : : > Krassimir Slavchev writes: : : > Boot with verbose messages is here: : : > : : > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose : : > : : >> This looks very similar to the data corruption I saw when I had : : >> enabled multiblock read. To track this down, we're going to have to : : >> print the actual data returned for each sector... : : > : : >> Warner : : : : : : Here is a dump of data right after the byte swapping in : : at91_mci_read_done(): : : : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump : : : : and here is the first 1M of the SD card: : : : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin : : Looks like we're getting some data corruption: : : CMD: 11 ARG 0 len 512 : : ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 : ... : : and then: : : CMD: 11 ARG 0 len 512 : : 00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 : ... : : So it looks like the first 4 bytes are corrupted on the read. If you : look closely at the data on the device, you'll see that 'fc 31 c0 8e' : are the first 4 bytes of the reads are the 'left over' data from prior : data streams. This didn't used to be the case in the prior code : before the recent changes. The only way we're going to find the bad : change is to do a binary search on the svn changes to find out where : we go off the rails. This problem seems familiar to me, but I can't : quite put my finger on what the root-cause was last time I had it. I should have said 'fc 31 c0 8e' are the first four bytes of the data on the device, and 'ff ff ff ff' and '00 00 55 aa' are the leftover data which is corrupting things. The latter is actually the last 4 bytes of the block, which indicates that our PMC usage has stopped too soon, or that we have left over PMC data from a previous "read" that didn't specify enough data to be transferred. I suspect that we're sending a command down and not expecting enough data. On other bridges we toss the data harmlessly. On at91, the data is still in the FIFO for the mci device, so we see it first on the next read. At least that's the theory that just popped into my head, and also the root-cause that I now recall from before when I saw similar problems... Of course, given the number of transfers that had a lot of 'ff' in them, maybe the PMC is trasnferring data that doesn't really exist yet... Warner From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 18:19:34 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 E83C7106566C for ; Wed, 21 Jan 2009 18:19:34 +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 01DF98FC1D for ; Wed, 21 Jan 2009 18:19:33 +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 232206452; Wed, 21 Jan 2009 20:19:28 +0200 Message-ID: <49776734.8030805@FreeBSD.org> Date: Wed, 21 Jan 2009 20:19:32 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090121.084023.188100520.imp@bsdimp.com> <4977500A.7060902@bulinfo.net> <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> In-Reply-To: <20090121.101459.2022307528.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: Wed, 21 Jan 2009 18:19:35 -0000 M. Warner Losh wrote: > In message: <20090121.100533.-1955669401.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <4977500A.7060902@bulinfo.net> > : Krassimir Slavchev writes: > : : -----BEGIN PGP SIGNED MESSAGE----- > : : Hash: SHA1 > : : > : : M. Warner Losh wrote: > : : > In message: <4977236E.2020409@bulinfo.net> > : : > Krassimir Slavchev writes: > : : > Boot with verbose messages is here: > : : > > : : > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose > : : > > : : >> This looks very similar to the data corruption I saw when I had > : : >> enabled multiblock read. To track this down, we're going to have to > : : >> print the actual data returned for each sector... > : : > > : : >> Warner > : : > : : > : : Here is a dump of data right after the byte swapping in > : : at91_mci_read_done(): > : : > : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump > : : > : : and here is the first 1M of the SD card: > : : > : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin > : > : Looks like we're getting some data corruption: > : > : CMD: 11 ARG 0 len 512 > : > : ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c > : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab > : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 > : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 > : ... > : > : and then: > : > : CMD: 11 ARG 0 len 512 > : > : 00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c > : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab > : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 > : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 > : ... > : > : So it looks like the first 4 bytes are corrupted on the read. If you > : look closely at the data on the device, you'll see that 'fc 31 c0 8e' > : are the first 4 bytes of the reads are the 'left over' data from prior > : data streams. This didn't used to be the case in the prior code > : before the recent changes. The only way we're going to find the bad > : change is to do a binary search on the svn changes to find out where > : we go off the rails. This problem seems familiar to me, but I can't > : quite put my finger on what the root-cause was last time I had it. > > I should have said 'fc 31 c0 8e' are the first four bytes of the data > on the device, and 'ff ff ff ff' and '00 00 55 aa' are the leftover > data which is corrupting things. The latter is actually the last 4 > bytes of the block, which indicates that our PMC usage has stopped too > soon, or that we have left over PMC data from a previous "read" that > didn't specify enough data to be transferred. I suspect that we're > sending a command down and not expecting enough data. On other > bridges we toss the data harmlessly. On at91, the data is still in > the FIFO for the mci device, so we see it first on the next read. At > least that's the theory that just popped into my head, and also the > root-cause that I now recall from before when I saw similar > problems... > > Of course, given the number of transfers that had a lot of 'ff' in > them, maybe the PMC is trasnferring data that doesn't really exist > yet... > > Warner This part looks quire strange for plain FIFO explanation. Several consequential commands give different results: CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... RES: 2 CMD: 37 ARG 10000 len 0 RES: 0 CMD: d ARG 0 len 64 ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... RES: 2 While working on sdhci driver for on ENE chip I have found that for short transfers (less then 1K) DMA engine returns set of zeroes instead of data. I haven't found better solution and just handling short transfers by PIO. Same problem exists for PIO also, but there it was masked by adding short delay before reading from port. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Wed Jan 21 19:30:19 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 244F31065675; Wed, 21 Jan 2009 19:30:19 +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 BBD098FC18; Wed, 21 Jan 2009 19:30:18 +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 n0LJS4wt027729; Wed, 21 Jan 2009 12:28:04 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 21 Jan 2009 12:28:42 -0700 (MST) Message-Id: <20090121.122842.-1582190967.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <49776734.8030805@FreeBSD.org> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@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: Wed, 21 Jan 2009 19:30:19 -0000 In message: <49776734.8030805@FreeBSD.org> Alexander Motin writes: : M. Warner Losh wrote: : > In message: <20090121.100533.-1955669401.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <4977500A.7060902@bulinfo.net> : > : Krassimir Slavchev writes: : > : : -----BEGIN PGP SIGNED MESSAGE----- : > : : Hash: SHA1 : > : : : > : : M. Warner Losh wrote: : > : : > In message: <4977236E.2020409@bulinfo.net> : > : : > Krassimir Slavchev writes: : > : : > Boot with verbose messages is here: : > : : > : > : : > http://mnemonic.bulinfo.net/~krassi/ARM/arm.verbose : > : : > : > : : >> This looks very similar to the data corruption I saw when I had : > : : >> enabled multiblock read. To track this down, we're going to have to : > : : >> print the actual data returned for each sector... : > : : > : > : : >> Warner : > : : : > : : : > : : Here is a dump of data right after the byte swapping in : > : : at91_mci_read_done(): : > : : : > : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump : > : : : > : : and here is the first 1M of the SD card: : > : : : > : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.bin : > : : > : Looks like we're getting some data corruption: : > : : > : CMD: 11 ARG 0 len 512 : > : : > : ff ff ff ff fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c : > : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab : > : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 : > : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 : > : ... : > : : > : and then: : > : : > : CMD: 11 ARG 0 len 512 : > : : > : 00 00 55 aa fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c : > : 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab : > : fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 : > : 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 : > : ... : > : : > : So it looks like the first 4 bytes are corrupted on the read. If you : > : look closely at the data on the device, you'll see that 'fc 31 c0 8e' : > : are the first 4 bytes of the reads are the 'left over' data from prior : > : data streams. This didn't used to be the case in the prior code : > : before the recent changes. The only way we're going to find the bad : > : change is to do a binary search on the svn changes to find out where : > : we go off the rails. This problem seems familiar to me, but I can't : > : quite put my finger on what the root-cause was last time I had it. : > : > I should have said 'fc 31 c0 8e' are the first four bytes of the data : > on the device, and 'ff ff ff ff' and '00 00 55 aa' are the leftover : > data which is corrupting things. The latter is actually the last 4 : > bytes of the block, which indicates that our PMC usage has stopped too : > soon, or that we have left over PMC data from a previous "read" that : > didn't specify enough data to be transferred. I suspect that we're : > sending a command down and not expecting enough data. On other : > bridges we toss the data harmlessly. On at91, the data is still in : > the FIFO for the mci device, so we see it first on the next read. At : > least that's the theory that just popped into my head, and also the : > root-cause that I now recall from before when I saw similar : > problems... : > : > Of course, given the number of transfers that had a lot of 'ff' in : > them, maybe the PMC is trasnferring data that doesn't really exist : > yet... : > : > Warner : : This part looks quire strange for plain FIFO explanation. Several : consequential commands give different results: : : CMD: 37 ARG 10000 len 0 : RES: 0 : CMD: d ARG 0 len 64 : : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : RES: 2 : CMD: 37 ARG 10000 len 0 : RES: 0 : CMD: d ARG 0 len 64 : : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : RES: 2 : CMD: 37 ARG 10000 len 0 : RES: 0 : CMD: d ARG 0 len 64 : : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : RES: 2 : CMD: 37 ARG 10000 len 0 : RES: 0 : CMD: d ARG 0 len 64 : : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : RES: 2 : : While working on sdhci driver for on ENE chip I have found that for : short transfers (less then 1K) DMA engine returns set of zeroes instead : of data. I haven't found better solution and just handling short : transfers by PIO. Same problem exists for PIO also, but there it was : masked by adding short delay before reading from port. I'll have to take a look at the code in more detail to make sure that we're doing the right thing. I noticed all the ff's, but didn't notice until now what they were shifted the same way that the data blocks were later. In this case, you'll see there's three of them. I believe that this is the first use of a CMD that generates data that isn't a full block of data... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 08:35:02 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 23FCA106573B for ; Thu, 22 Jan 2009 08:35:02 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id D25AF8FC18 for ; Thu, 22 Jan 2009 08:35:01 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id n0M8MuCQ014976; Thu, 22 Jan 2009 01:22:57 -0700 Message-ID: <49782CE0.8010607@semihalf.com> Date: Thu, 22 Jan 2009 09:22:56 +0100 From: Rafal Jaworowski Organization: Semihalf MIME-Version: 1.0 To: "M. Warner Losh" References: <4977236E.2020409@bulinfo.net> <497726F5.5080000@bulinfo.net> <49772A2C.7090903@FreeBSD.org> <20090121.084141.-1119405090.imp@bsdimp.com> In-Reply-To: <20090121.084141.-1119405090.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 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: Thu, 22 Jan 2009 08:35:02 -0000 M. Warner Losh wrote: > In message: <49772A2C.7090903@FreeBSD.org> > Alexander Motin writes: > : Krassimir Slavchev wrote: > : > Oops, sorry this output was without SD card inserted! > : > I've changed the file. > : > : That's some different debugging. I have meant that one, which happens > : when boot_verbose="YES" added to loader.conf, or respective Fx button > : pressed during boot on PC. > > You can't do either of those on the ARM platform. Just for the record: Marvell ARM platforms can boot with regular loader(8) environment; in this case using runtime variables, boot flags etc. works. Rafal From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 11:29:04 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 DABC4106566B for ; Thu, 22 Jan 2009 11:29:04 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id F037C8FC18 for ; Thu, 22 Jan 2009 11:29:03 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0MAusOZ044982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 11:56:54 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0MAupgE016778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 11:56:51 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0MAupaB051946; Thu, 22 Jan 2009 11:56:51 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0MAupu9051945; Thu, 22 Jan 2009 11:56:51 +0100 (CET) (envelope-from ticso) Date: Thu, 22 Jan 2009 11:56:50 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20090122105650.GB50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090121.122842.-1582190967.imp@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: mav@freebsd.org, 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 Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 11:29:05 -0000 On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: > In message: <49776734.8030805@FreeBSD.org> > Alexander Motin writes: > : > : This part looks quire strange for plain FIFO explanation. Several > : consequential commands give different results: > : > : CMD: 37 ARG 10000 len 0 > : RES: 0 > : CMD: d ARG 0 len 64 > : > : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... > : RES: 2 > : CMD: 37 ARG 10000 len 0 > : RES: 0 > : CMD: d ARG 0 len 64 > : > : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 > : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... > : RES: 2 > : CMD: 37 ARG 10000 len 0 > : RES: 0 > : CMD: d ARG 0 len 64 > : > : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... > : RES: 2 > : CMD: 37 ARG 10000 len 0 > : RES: 0 > : CMD: d ARG 0 len 64 > : > : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... > : RES: 2 > : > : While working on sdhci driver for on ENE chip I have found that for > : short transfers (less then 1K) DMA engine returns set of zeroes instead > : of data. I haven't found better solution and just handling short > : transfers by PIO. Same problem exists for PIO also, but there it was > : masked by adding short delay before reading from port. > > I'll have to take a look at the code in more detail to make sure that > we're doing the right thing. I noticed all the ff's, but didn't > notice until now what they were shifted the same way that the data > blocks were later. In this case, you'll see there's three of them. > > I believe that this is the first use of a CMD that generates data that > isn't a full block of data... Havn't read everything, so maybe I writing nonsense in respect to this problem. The multiblock read trouble is a problem in the MMC design. The first read always works fine, but you need to stop the transfer and an exact time, otherwise it starts reading the next block. The first bytes of the next block then stucks in the DMA fifo and the next read then starts with the stuck uint32. If you see broken reads like this then I would assume the previous command was problematic. The official workaround to get multiblock reading is to reset the MMC and clean the fifo after each multiblock command, but I would assume it is enough to just read the data register a few time before setting up the DMA for the new request. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 13:22: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 02EDB1065678 for ; Thu, 22 Jan 2009 13:22: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 3C8408FC12 for ; Thu, 22 Jan 2009 13:22:33 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [77.52.120.233] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 232281305; Thu, 22 Jan 2009 15:22:30 +0200 Message-ID: <49787314.3070004@FreeBSD.org> Date: Thu, 22 Jan 2009 15:22:28 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: ticso@cicely.de References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> In-Reply-To: <20090122105650.GB50103@cicely7.cicely.de> 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: Thu, 22 Jan 2009 13:22:35 -0000 Bernd Walter wrote: > On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: >> In message: <49776734.8030805@FreeBSD.org> >> Alexander Motin writes: >> : >> : This part looks quire strange for plain FIFO explanation. Several >> : consequential commands give different results: >> : >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 >> : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : CMD: 37 ARG 10000 len 0 >> : RES: 0 >> : CMD: d ARG 0 len 64 >> : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... >> : RES: 2 >> : >> : While working on sdhci driver for on ENE chip I have found that for >> : short transfers (less then 1K) DMA engine returns set of zeroes instead >> : of data. I haven't found better solution and just handling short >> : transfers by PIO. Same problem exists for PIO also, but there it was >> : masked by adding short delay before reading from port. >> >> I'll have to take a look at the code in more detail to make sure that >> we're doing the right thing. I noticed all the ff's, but didn't >> notice until now what they were shifted the same way that the data >> blocks were later. In this case, you'll see there's three of them. >> >> I believe that this is the first use of a CMD that generates data that >> isn't a full block of data... > > Havn't read everything, so maybe I writing nonsense in respect to > this problem. > The multiblock read trouble is a problem in the MMC design. > The first read always works fine, but you need to stop the transfer > and an exact time, otherwise it starts reading the next block. > The first bytes of the next block then stucks in the DMA fifo and > the next read then starts with the stuck uint32. > If you see broken reads like this then I would assume the previous > command was problematic. > The official workaround to get multiblock reading is to reset the MMC > and clean the fifo after each multiblock command, but I would assume > it is enough to just read the data register a few time before setting > up the DMA for the new request. Haven't look deep at that arm controller operation, but standard SD host has special counter register which terminates DMA transfer after specified amount of blocks. sdhci driver even uses it's Auth-CMD12 feature, where controller even sends STOP command to the card by itself. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 14:20:23 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 A99011065687; Thu, 22 Jan 2009 14:20:23 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 23F968FC19; Thu, 22 Jan 2009 14:20:22 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0MEKJR7050239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 15:20:19 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0MEKGfI021919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 15:20:16 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0MEKFHN052455; Thu, 22 Jan 2009 15:20:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0MEKFlN052454; Thu, 22 Jan 2009 15:20:15 +0100 (CET) (envelope-from ticso) Date: Thu, 22 Jan 2009 15:20:15 +0100 From: Bernd Walter To: Alexander Motin Message-ID: <20090122142015.GC50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49787314.3070004@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 14:20:24 -0000 On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: > Bernd Walter wrote: > >On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: > >Havn't read everything, so maybe I writing nonsense in respect to > >this problem. > >The multiblock read trouble is a problem in the MMC design. > >The first read always works fine, but you need to stop the transfer > >and an exact time, otherwise it starts reading the next block. > >The first bytes of the next block then stucks in the DMA fifo and > >the next read then starts with the stuck uint32. > >If you see broken reads like this then I would assume the previous > >command was problematic. > >The official workaround to get multiblock reading is to reset the MMC > >and clean the fifo after each multiblock command, but I would assume > >it is enough to just read the data register a few time before setting > >up the DMA for the new request. > > Haven't look deep at that arm controller operation, but standard SD host > has special counter register which terminates DMA transfer after > specified amount of blocks. sdhci driver even uses it's Auth-CMD12 > feature, where controller even sends STOP command to the card by itself. > Yes - and this is broken in the Atmel design. This is not the only nasty bug that Atmel has left int he chip. You need to issue the STOP command at the absolut right timing, which is more or less impossible. The design puts every 32bit word in a receive register, which has a small fifo. You can setup a DMA enginge to pull the words from the register into RAM. Now what happens is that if you issue the STOP too late it starts reading the next block and then stops - the card can stop at every location, so there is no problem about this, but now you have the first words in the receive fifo. The DMA doesn't work anymore, because it was setup with a limited number of words to pull, so the additional words are kept in the register. Once you start reading the next block and setup the DMA it pulls the stuck words first. It that case it looks as if the timing is one word too late therefor you get 4 additonal bytes after each transaction. It shouldn't be a problem to read the receive register without data in it, so 4 or 5 dummy reads befor DMA setup should be enough. IIRC the fifo can only hold up to 3 words. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 14:46:41 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 AF002106564A; Thu, 22 Jan 2009 14:46:41 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 437E38FC0C; Thu, 22 Jan 2009 14:46:41 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 0EC57CB1C; Thu, 22 Jan 2009 16:46:36 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46403-10; Thu, 22 Jan 2009 16:46:35 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id DF3F7CB05; Thu, 22 Jan 2009 16:46:34 +0200 (EET) Message-ID: <497886C9.3020907@bulinfo.net> Date: Thu, 22 Jan 2009 16:46:33 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: ticso@cicely.de References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> In-Reply-To: <20090122142015.GC50103@cicely7.cicely.de> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: Alexander Motin , 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: Thu, 22 Jan 2009 14:46:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have added a loop to read (256 times) the receive register (MCI_RDR) right before DMA setup for reading. Here is the result: http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump2 Best Regards Bernd Walter wrote: > On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: >> Bernd Walter wrote: >>> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: >>> Havn't read everything, so maybe I writing nonsense in respect to >>> this problem. >>> The multiblock read trouble is a problem in the MMC design. >>> The first read always works fine, but you need to stop the transfer >>> and an exact time, otherwise it starts reading the next block. >>> The first bytes of the next block then stucks in the DMA fifo and >>> the next read then starts with the stuck uint32. >>> If you see broken reads like this then I would assume the previous >>> command was problematic. >>> The official workaround to get multiblock reading is to reset the MMC >>> and clean the fifo after each multiblock command, but I would assume >>> it is enough to just read the data register a few time before setting >>> up the DMA for the new request. >> Haven't look deep at that arm controller operation, but standard SD host >> has special counter register which terminates DMA transfer after >> specified amount of blocks. sdhci driver even uses it's Auth-CMD12 >> feature, where controller even sends STOP command to the card by itself. >> > > Yes - and this is broken in the Atmel design. > This is not the only nasty bug that Atmel has left int he chip. > You need to issue the STOP command at the absolut right timing, which > is more or less impossible. > The design puts every 32bit word in a receive register, which has a small > fifo. > You can setup a DMA enginge to pull the words from the register into RAM. > Now what happens is that if you issue the STOP too late it starts reading > the next block and then stops - the card can stop at every location, so > there is no problem about this, but now you have the first words in the > receive fifo. > The DMA doesn't work anymore, because it was setup with a limited number > of words to pull, so the additional words are kept in the register. > Once you start reading the next block and setup the DMA it pulls the > stuck words first. > It that case it looks as if the timing is one word too late therefor > you get 4 additonal bytes after each transaction. > It shouldn't be a problem to read the receive register without data in > it, so 4 or 5 dummy reads befor DMA setup should be enough. > IIRC the fifo can only hold up to 3 words. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJeIbJxJBWvpalMpkRAoyiAJ498TG0ZB+aIoz66ZMQ08C3RxQ8YQCfSoL0 AA+/Up5DcZCzX7b+sz0PXk0= =pLAx -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 14:47:36 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 723B61065670 for ; Thu, 22 Jan 2009 14:47:36 +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 E83D58FC17 for ; Thu, 22 Jan 2009 14:47:35 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [77.52.115.103] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 232291892; Thu, 22 Jan 2009 16:47:32 +0200 Message-ID: <49788702.9010808@FreeBSD.org> Date: Thu, 22 Jan 2009 16:47:30 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: ticso@cicely.de References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> In-Reply-To: <20090122142015.GC50103@cicely7.cicely.de> 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: Thu, 22 Jan 2009 14:47:37 -0000 Bernd Walter wrote: > On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: >> Bernd Walter wrote: >>> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: >>> Havn't read everything, so maybe I writing nonsense in respect to >>> this problem. >>> The multiblock read trouble is a problem in the MMC design. >>> The first read always works fine, but you need to stop the transfer >>> and an exact time, otherwise it starts reading the next block. >>> The first bytes of the next block then stucks in the DMA fifo and >>> the next read then starts with the stuck uint32. >>> If you see broken reads like this then I would assume the previous >>> command was problematic. >>> The official workaround to get multiblock reading is to reset the MMC >>> and clean the fifo after each multiblock command, but I would assume >>> it is enough to just read the data register a few time before setting >>> up the DMA for the new request. >> Haven't look deep at that arm controller operation, but standard SD host >> has special counter register which terminates DMA transfer after >> specified amount of blocks. sdhci driver even uses it's Auth-CMD12 >> feature, where controller even sends STOP command to the card by itself. >> > > Yes - and this is broken in the Atmel design. > This is not the only nasty bug that Atmel has left int he chip. > You need to issue the STOP command at the absolut right timing, which > is more or less impossible. > The design puts every 32bit word in a receive register, which has a small > fifo. > You can setup a DMA enginge to pull the words from the register into RAM. > Now what happens is that if you issue the STOP too late it starts reading > the next block and then stops - the card can stop at every location, so > there is no problem about this, but now you have the first words in the > receive fifo. > The DMA doesn't work anymore, because it was setup with a limited number > of words to pull, so the additional words are kept in the register. > Once you start reading the next block and setup the DMA it pulls the > stuck words first. > It that case it looks as if the timing is one word too late therefor > you get 4 additonal bytes after each transaction. > It shouldn't be a problem to read the receive register without data in > it, so 4 or 5 dummy reads befor DMA setup should be enough. > IIRC the fifo can only hold up to 3 words. Looks realistic. Just needed somebody with hardware to investigate it. But even if current problem seems to be alike, the reasons are probably different. At this time, mmc/mmcsd layers are strictly instructed to not issue multi block operations to the at91 controller. There is something different pollutes the buffer. But may be cleaning that FIFO before starting transfer could become universal solution. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 15:13:47 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 2D1D01065675; Thu, 22 Jan 2009 15:13:47 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id B7FAB8FC17; Thu, 22 Jan 2009 15:13:46 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0MFDhMm052334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 16:13:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0MFDelo023468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 16:13:40 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0MFDedB052630; Thu, 22 Jan 2009 16:13:40 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0MFDe7u052629; Thu, 22 Jan 2009 16:13:40 +0100 (CET) (envelope-from ticso) Date: Thu, 22 Jan 2009 16:13:40 +0100 From: Bernd Walter To: Alexander Motin Message-ID: <20090122151340.GE50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49788702.9010808@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:13:47 -0000 On Thu, Jan 22, 2009 at 04:47:30PM +0200, Alexander Motin wrote: > Bernd Walter wrote: > >Yes - and this is broken in the Atmel design. > >This is not the only nasty bug that Atmel has left int he chip. > >You need to issue the STOP command at the absolut right timing, which > >is more or less impossible. > >The design puts every 32bit word in a receive register, which has a small > >fifo. > >You can setup a DMA enginge to pull the words from the register into RAM. > >Now what happens is that if you issue the STOP too late it starts reading > >the next block and then stops - the card can stop at every location, so > >there is no problem about this, but now you have the first words in the > >receive fifo. > >The DMA doesn't work anymore, because it was setup with a limited number > >of words to pull, so the additional words are kept in the register. > >Once you start reading the next block and setup the DMA it pulls the > >stuck words first. > >It that case it looks as if the timing is one word too late therefor > >you get 4 additonal bytes after each transaction. > >It shouldn't be a problem to read the receive register without data in > >it, so 4 or 5 dummy reads befor DMA setup should be enough. > >IIRC the fifo can only hold up to 3 words. > > Looks realistic. Just needed somebody with hardware to investigate it. I unfortunately don't have the time right now. > But even if current problem seems to be alike, the reasons are probably > different. At this time, mmc/mmcsd layers are strictly instructed to not > issue multi block operations to the at91 controller. There is something > different pollutes the buffer. That's the point why I was not sure if it applies here. Is there anything else issued which needs a STOP? I'm really a bit out of SD card command handling... > But may be cleaning that FIFO before starting transfer could become > universal solution. Probably - especially because multiblock operations are a massive speed factor, but it would still be good to know why it happens here. With multiblock writing we don't have this problem, because we have to supply the data and there is no reson to supply more than we need to send. The reason why we don't allow multiblock writes with this controller is just because we need a temporary buffer to reorder the bytes, which is fixed allocated to one block - the MCI in the RM9200 uses the wrong byte order - sigh... Would be good to use a larger buffer some day to speed up writing. Especially with writing multiblock would be a major enhancement. As another point: Is it possible to support SHDC with mci some day, or is there a special hardware requirement for SDHC? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 15:23:08 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 4C02B1065670; Thu, 22 Jan 2009 15:23:08 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id D0D738FC1B; Thu, 22 Jan 2009 15:23:07 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0MFMtQ2052562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 16:22:55 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0MFMoSG023740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 16:22:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0MFMorX052684; Thu, 22 Jan 2009 16:22:50 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0MFMooI052683; Thu, 22 Jan 2009 16:22:50 +0100 (CET) (envelope-from ticso) Date: Thu, 22 Jan 2009 16:22:50 +0100 From: Bernd Walter To: Krassimir Slavchev Message-ID: <20090122152250.GH50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <497886C9.3020907@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <497886C9.3020907@bulinfo.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, Alexander Motin , ticso@cicely.de Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 15:23:09 -0000 On Thu, Jan 22, 2009 at 04:46:33PM +0200, Krassimir Slavchev wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I have added a loop to read (256 times) the receive register (MCI_RDR) > right before DMA setup for reading. Here is the result: > > http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump2 Seems there is a good reason, why Atmel does a MCI reset in their workaround :( > Best Regards > > Bernd Walter wrote: > > On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: > >> Bernd Walter wrote: > >>> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: > >>> Havn't read everything, so maybe I writing nonsense in respect to > >>> this problem. > >>> The multiblock read trouble is a problem in the MMC design. > >>> The first read always works fine, but you need to stop the transfer > >>> and an exact time, otherwise it starts reading the next block. > >>> The first bytes of the next block then stucks in the DMA fifo and > >>> the next read then starts with the stuck uint32. > >>> If you see broken reads like this then I would assume the previous > >>> command was problematic. > >>> The official workaround to get multiblock reading is to reset the MMC > >>> and clean the fifo after each multiblock command, but I would assume > >>> it is enough to just read the data register a few time before setting > >>> up the DMA for the new request. > >> Haven't look deep at that arm controller operation, but standard SD host > >> has special counter register which terminates DMA transfer after > >> specified amount of blocks. sdhci driver even uses it's Auth-CMD12 > >> feature, where controller even sends STOP command to the card by itself. > >> > > > > Yes - and this is broken in the Atmel design. > > This is not the only nasty bug that Atmel has left int he chip. > > You need to issue the STOP command at the absolut right timing, which > > is more or less impossible. > > The design puts every 32bit word in a receive register, which has a small > > fifo. > > You can setup a DMA enginge to pull the words from the register into RAM. > > Now what happens is that if you issue the STOP too late it starts reading > > the next block and then stops - the card can stop at every location, so > > there is no problem about this, but now you have the first words in the > > receive fifo. > > The DMA doesn't work anymore, because it was setup with a limited number > > of words to pull, so the additional words are kept in the register. > > Once you start reading the next block and setup the DMA it pulls the > > stuck words first. > > It that case it looks as if the timing is one word too late therefor > > you get 4 additonal bytes after each transaction. > > It shouldn't be a problem to read the receive register without data in > > it, so 4 or 5 dummy reads befor DMA setup should be enough. > > IIRC the fifo can only hold up to 3 words. > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > > iD8DBQFJeIbJxJBWvpalMpkRAoyiAJ498TG0ZB+aIoz66ZMQ08C3RxQ8YQCfSoL0 > AA+/Up5DcZCzX7b+sz0PXk0= > =pLAx > -----END PGP SIGNATURE----- -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 15:55:40 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 30989106564A for ; Thu, 22 Jan 2009 15:55:40 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id CFCA98FC0C for ; Thu, 22 Jan 2009 15:55:39 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id A1AF6CB24 for ; Thu, 22 Jan 2009 17:55:37 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53218-04 for ; Thu, 22 Jan 2009 17:55:37 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id E7B2ACA91 for ; Thu, 22 Jan 2009 17:55:36 +0200 (EET) Message-ID: <497896F3.9030908@bulinfo.net> Date: Thu, 22 Jan 2009 17:55:31 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> In-Reply-To: <20090122151340.GE50103@cicely7.cicely.de> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig092BE48745BA0D0C1546363B" X-Virus-Scanned: amavisd-new at mx.bulinfo.net Subject: Re: Mount root from SD card?(solved!) 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: Thu, 22 Jan 2009 15:55:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig092BE48745BA0D0C1546363B Content-Type: multipart/mixed; boundary="------------090002080101070607040400" This is a multi-part message in MIME format. --------------090002080101070607040400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, We have to send the command before enabling the PDC for reading. I do not know why in the datasheet is opposite! See the attached patch. Thanks to All! Best Regards --------------090002080101070607040400 Content-Type: text/plain; name="at91_mci.c.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="at91_mci.c.diff" Index: at91_mci.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- at91_mci.c (revision 187590) +++ at91_mci.c (working copy) @@ -199,7 +199,7 @@ goto out; } sc->host.f_min =3D 375000; - sc->host.f_max =3D at91_master_clock / 2; /* Typically 30MHz */ + sc->host.f_max =3D AT91C_MASTER_CLOCK / 2; /* Typically 30MHz */ sc->host.host_ocr =3D MMC_OCR_320_330 | MMC_OCR_330_340; if (sc->wire4) sc->host.caps =3D MMC_CAP_4_BIT_DATA; @@ -399,8 +399,8 @@ WR4(sc, MCI_ARGR, cmd->arg); if (cmdr & MCI_CMDR_TRCMD_START) { if (cmdr & MCI_CMDR_TRDIR) { + WR4(sc, MCI_CMDR, cmdr); WR4(sc, PDC_PTCR, PDC_PTCR_RXTEN); - WR4(sc, MCI_CMDR, cmdr); } else { WR4(sc, MCI_CMDR, cmdr); WR4(sc, PDC_PTCR, PDC_PTCR_TXTEN); --------------090002080101070607040400-- --------------enig092BE48745BA0D0C1546363B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJeJb3xJBWvpalMpkRAv80AJ9cIvsG8zH0P9ClSolZNAcMmnfNDQCggFMh 94JiNAZJSRIkkQTrvzoEqzE= =aklO -----END PGP SIGNATURE----- --------------enig092BE48745BA0D0C1546363B-- From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 16:07:08 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 47D2D1065670; Thu, 22 Jan 2009 16:07:08 +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 EB66A8FC18; Thu, 22 Jan 2009 16:07:07 +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 n0MG52fB048050; Thu, 22 Jan 2009 09:05:02 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 09:05:40 -0700 (MST) Message-Id: <20090122.090540.-839781195.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <49787314.3070004@FreeBSD.org> References: <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@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, ticso@cicely.de 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: Thu, 22 Jan 2009 16:07:08 -0000 In message: <49787314.3070004@FreeBSD.org> Alexander Motin writes: : Bernd Walter wrote: : > On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: : >> In message: <49776734.8030805@FreeBSD.org> : >> Alexander Motin writes: : >> : : >> : This part looks quire strange for plain FIFO explanation. Several : >> : consequential commands give different results: : >> : : >> : CMD: 37 ARG 10000 len 0 : >> : RES: 0 : >> : CMD: d ARG 0 len 64 : >> : : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : >> : RES: 2 : >> : CMD: 37 ARG 10000 len 0 : >> : RES: 0 : >> : CMD: d ARG 0 len 64 : >> : : >> : ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 : >> : 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : >> : RES: 2 : >> : CMD: 37 ARG 10000 len 0 : >> : RES: 0 : >> : CMD: d ARG 0 len 64 : >> : : >> : ff ff ff ff 00 00 00 00 00 00 00 28 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : >> : RES: 2 : >> : CMD: 37 ARG 10000 len 0 : >> : RES: 0 : >> : CMD: d ARG 0 len 64 : >> : : >> : ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 28 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : >> : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... : >> : RES: 2 : >> : : >> : While working on sdhci driver for on ENE chip I have found that for : >> : short transfers (less then 1K) DMA engine returns set of zeroes instead : >> : of data. I haven't found better solution and just handling short : >> : transfers by PIO. Same problem exists for PIO also, but there it was : >> : masked by adding short delay before reading from port. : >> : >> I'll have to take a look at the code in more detail to make sure that : >> we're doing the right thing. I noticed all the ff's, but didn't : >> notice until now what they were shifted the same way that the data : >> blocks were later. In this case, you'll see there's three of them. : >> : >> I believe that this is the first use of a CMD that generates data that : >> isn't a full block of data... : > : > Havn't read everything, so maybe I writing nonsense in respect to : > this problem. : > The multiblock read trouble is a problem in the MMC design. : > The first read always works fine, but you need to stop the transfer : > and an exact time, otherwise it starts reading the next block. : > The first bytes of the next block then stucks in the DMA fifo and : > the next read then starts with the stuck uint32. : > If you see broken reads like this then I would assume the previous : > command was problematic. : > The official workaround to get multiblock reading is to reset the MMC : > and clean the fifo after each multiblock command, but I would assume : > it is enough to just read the data register a few time before setting : > up the DMA for the new request. : : Haven't look deep at that arm controller operation, but standard SD host : has special counter register which terminates DMA transfer after : specified amount of blocks. sdhci driver even uses it's Auth-CMD12 : feature, where controller even sends STOP command to the card by itself. The standard host adapter spec has this. The Atmel part doesn't. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 16:12:17 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 35E15106564A for ; Thu, 22 Jan 2009 16:12:17 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id DE0458FC0C for ; Thu, 22 Jan 2009 16:12:16 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 7D49FCB41 for ; Thu, 22 Jan 2009 18:12:14 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54708-03 for ; Thu, 22 Jan 2009 18:12:13 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id A5CCBCB38 for ; Thu, 22 Jan 2009 18:12:13 +0200 (EET) Message-ID: <49789ADE.4020107@bulinfo.net> Date: Thu, 22 Jan 2009 18:12:14 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> <497896F3.9030908@bulinfo.net> In-Reply-To: <497896F3.9030908@bulinfo.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Subject: Re: Mount root from SD card?(solved!) 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: Thu, 22 Jan 2009 16:12:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 And SD is corrupted! ... mmcsd0: 1983MB at mmc0 30MHz/1bit GEOM: mmcsd0s1: geometry does not match label (255h,63s != 64h,63s). GEOM: mmcsd0s2: geometry does not match label (255h,63s != 64h,63s). Trying to mount root from ufs:/dev/mmcsd0s1 warning: no time-of-day clock registered, system time will not be set accurately Loading configuration files. No suitable dump device was found. Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: adding /dev/mmcsd0s2 as swap device uhub0: device problem (IOERROR), disabling port 2 Starting file system checks: /dev/mmcsd0s1: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/mmcsd0s1: clean, 740863 free (3079 frags, 92223 blocks, 0.3% fragmentation) try does not match label (255h,63s != 64h,63s). Setting hostuuid: 5d40cced-02e7-11dc-b687-00ff01000043. Setting hostid: 0xf129ad60. Mounting local file systems:. panic: ufs_dirbad: /: bad dir ino 47116 at offset 0: mangled entry KDB: enter: panic [thread pid 80 tid 100044 ] Stopped at kdb_enter+0x44: ldrb r15, [r15, r15, ror r15]! db> Krassimir Slavchev wrote: > Hi, > > We have to send the command before enabling the PDC for reading. I do > not know why in the datasheet is opposite! > > See the attached patch. > > Thanks to All! > > Best Regards > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJeJrexJBWvpalMpkRAoCqAJ962bjsgQuUmDuuGQUH/gVjtOAelACbBDNU XczYSgeGxfA58BB5p4EsUIw= =NPrA -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 16:12:41 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 6EE911065692; Thu, 22 Jan 2009 16:12:41 +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 1E84F8FC12; Thu, 22 Jan 2009 16:12:41 +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 n0MG9IvR048152; Thu, 22 Jan 2009 09:09:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 09:09:57 -0700 (MST) Message-Id: <20090122.090957.803629112.imp@bsdimp.com> To: mav@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <49788702.9010808@FreeBSD.org> References: <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@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, ticso@cicely.de 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: Thu, 22 Jan 2009 16:12:41 -0000 In message: <49788702.9010808@FreeBSD.org> Alexander Motin writes: : Bernd Walter wrote: : > On Thu, Jan 22, 2009 at 03:22:28PM +0200, Alexander Motin wrote: : >> Bernd Walter wrote: : >>> On Wed, Jan 21, 2009 at 12:28:42PM -0700, M. Warner Losh wrote: : >>> Havn't read everything, so maybe I writing nonsense in respect to : >>> this problem. : >>> The multiblock read trouble is a problem in the MMC design. : >>> The first read always works fine, but you need to stop the transfer : >>> and an exact time, otherwise it starts reading the next block. : >>> The first bytes of the next block then stucks in the DMA fifo and : >>> the next read then starts with the stuck uint32. : >>> If you see broken reads like this then I would assume the previous : >>> command was problematic. : >>> The official workaround to get multiblock reading is to reset the MMC : >>> and clean the fifo after each multiblock command, but I would assume : >>> it is enough to just read the data register a few time before setting : >>> up the DMA for the new request. : >> Haven't look deep at that arm controller operation, but standard SD host : >> has special counter register which terminates DMA transfer after : >> specified amount of blocks. sdhci driver even uses it's Auth-CMD12 : >> feature, where controller even sends STOP command to the card by itself. : >> : > : > Yes - and this is broken in the Atmel design. : > This is not the only nasty bug that Atmel has left int he chip. : > You need to issue the STOP command at the absolut right timing, which : > is more or less impossible. : > The design puts every 32bit word in a receive register, which has a small : > fifo. : > You can setup a DMA enginge to pull the words from the register into RAM. : > Now what happens is that if you issue the STOP too late it starts reading : > the next block and then stops - the card can stop at every location, so : > there is no problem about this, but now you have the first words in the : > receive fifo. : > The DMA doesn't work anymore, because it was setup with a limited number : > of words to pull, so the additional words are kept in the register. : > Once you start reading the next block and setup the DMA it pulls the : > stuck words first. : > It that case it looks as if the timing is one word too late therefor : > you get 4 additonal bytes after each transaction. : > It shouldn't be a problem to read the receive register without data in : > it, so 4 or 5 dummy reads befor DMA setup should be enough. : > IIRC the fifo can only hold up to 3 words. : : Looks realistic. Just needed somebody with hardware to investigate it. : : But even if current problem seems to be alike, the reasons are probably : different. At this time, mmc/mmcsd layers are strictly instructed to not : issue multi block operations to the at91 controller. There is something : different pollutes the buffer. True. But the mmc layer is also now issuing commands it didn't used to issue, with different timing than before. That's the root cause of the problem. Also, there's bugs in the timing switching code that I'm working through. It does some bogus things and makes some bogus assumptions (like that if a car CAN do a hight speed transfer it MUST do it, even if the transfer speed isn't > 25MHz). : But may be cleaning that FIFO before starting transfer could become : universal solution. That's a really ugly solution. And it can't really be done reliably on this chip. At least when I was messing with it before I couldn't get it to work completely... There were too many ugly things wrong with this chip to make it viable. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 16:12:43 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 2B2C01065692; Thu, 22 Jan 2009 16:12:43 +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 D28E78FC1A; Thu, 22 Jan 2009 16:12:42 +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 n0MGBP2V048208; Thu, 22 Jan 2009 09:11:25 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 09:12:04 -0700 (MST) Message-Id: <20090122.091204.831807729.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de From: "M. Warner Losh" In-Reply-To: <20090122151340.GE50103@cicely7.cicely.de> References: <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> 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: mav@FreeBSD.org, 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: Thu, 22 Jan 2009 16:12:43 -0000 In message: <20090122151340.GE50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 04:47:30PM +0200, Alexander Motin wrote: : > Bernd Walter wrote: : > >Yes - and this is broken in the Atmel design. : > >This is not the only nasty bug that Atmel has left int he chip. : > >You need to issue the STOP command at the absolut right timing, which : > >is more or less impossible. : > >The design puts every 32bit word in a receive register, which has a small : > >fifo. : > >You can setup a DMA enginge to pull the words from the register into RAM. : > >Now what happens is that if you issue the STOP too late it starts reading : > >the next block and then stops - the card can stop at every location, so : > >there is no problem about this, but now you have the first words in the : > >receive fifo. : > >The DMA doesn't work anymore, because it was setup with a limited number : > >of words to pull, so the additional words are kept in the register. : > >Once you start reading the next block and setup the DMA it pulls the : > >stuck words first. : > >It that case it looks as if the timing is one word too late therefor : > >you get 4 additonal bytes after each transaction. : > >It shouldn't be a problem to read the receive register without data in : > >it, so 4 or 5 dummy reads befor DMA setup should be enough. : > >IIRC the fifo can only hold up to 3 words. : > : > Looks realistic. Just needed somebody with hardware to investigate it. : : I unfortunately don't have the time right now. : : > But even if current problem seems to be alike, the reasons are probably : > different. At this time, mmc/mmcsd layers are strictly instructed to not : > issue multi block operations to the at91 controller. There is something : > different pollutes the buffer. : : That's the point why I was not sure if it applies here. : Is there anything else issued which needs a STOP? : I'm really a bit out of SD card command handling... : : > But may be cleaning that FIFO before starting transfer could become : > universal solution. : : Probably - especially because multiblock operations are a massive : speed factor, but it would still be good to know why it happens here. : : With multiblock writing we don't have this problem, because we have : to supply the data and there is no reson to supply more than we need to : send. : The reason why we don't allow multiblock writes with this controller is : just because we need a temporary buffer to reorder the bytes, which is : fixed allocated to one block - the MCI in the RM9200 uses the wrong : byte order - sigh... : Would be good to use a larger buffer some day to speed up writing. : Especially with writing multiblock would be a major enhancement. Yes. We could have a larger buffer, but we still need the reset the fifo after each transfer hack. I tried to implement it long ago, but it failed to work reliably... : As another point: : Is it possible to support SHDC with mci some day, or is there a special : hardware requirement for SDHC? It should be, in theory, possible. sdio is a different matter due to timing issues, but SDHC should be possible... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 16:30:02 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 3CEE5106567C for ; Thu, 22 Jan 2009 16:30:02 +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 F204A8FC0A for ; Thu, 22 Jan 2009 16:30: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 n0MGTTNK048484; Thu, 22 Jan 2009 09:29:29 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 09:30:07 -0700 (MST) Message-Id: <20090122.093007.1785588956.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <497896F3.9030908@bulinfo.net> References: <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> <497896F3.9030908@bulinfo.net> 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?(solved!) 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: Thu, 22 Jan 2009 16:30:03 -0000 In message: <497896F3.9030908@bulinfo.net> Krassimir Slavchev writes: : Index: at91_mci.c : =================================================================== : --- at91_mci.c (revision 187590) : +++ at91_mci.c (working copy) : @@ -199,7 +199,7 @@ : goto out; : } : sc->host.f_min = 375000; : - sc->host.f_max = at91_master_clock / 2; /* Typically 30MHz */ : + sc->host.f_max = AT91C_MASTER_CLOCK / 2; /* Typically 30MHz */ : sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; : if (sc->wire4) : sc->host.caps = MMC_CAP_4_BIT_DATA; This change is wrong. : @@ -399,8 +399,8 @@ : WR4(sc, MCI_ARGR, cmd->arg); : if (cmdr & MCI_CMDR_TRCMD_START) { : if (cmdr & MCI_CMDR_TRDIR) { : + WR4(sc, MCI_CMDR, cmdr); : WR4(sc, PDC_PTCR, PDC_PTCR_RXTEN); : - WR4(sc, MCI_CMDR, cmdr); This change is also wrong. It won't work. Also, why test the direction at all if we're just going to do the same thing in both legs of the branch? When I was developing the code, I originally had the 'send a command and then enable PDC' logic. It didn't work for the read case, so now we enable the reader and then send the command. We do this based on the logic that it is OK to have the PDC enabled when there's no data transfer going, but if we send the command, then take an interrupt before we can enable the PDC, we'd lose data. And that seemed to happen a lot. There's lots of races in programming this chip :( : } else { : WR4(sc, MCI_CMDR, cmdr); : WR4(sc, PDC_PTCR, PDC_PTCR_TXTEN); Warner From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 18:02:34 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 CD3CE1065672 for ; Thu, 22 Jan 2009 18:02:34 +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 4E4828FC08 for ; Thu, 22 Jan 2009 18:02:33 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [77.52.86.222] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 232309641; Thu, 22 Jan 2009 20:02:31 +0200 Message-ID: <4978B4A6.8060408@FreeBSD.org> Date: Thu, 22 Jan 2009 20:02:14 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: ticso@cicely.de References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> In-Reply-To: <20090122151340.GE50103@cicely7.cicely.de> 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: Thu, 22 Jan 2009 18:02:35 -0000 Bernd Walter wrote: > As another point: > Is it possible to support SHDC with mci some day, or is there a special > hardware requirement for SDHC? SDHC (SD High Capacity) has just a different data addressing scheme (in 512bytes blocks instead of bytes). There is no special hardware requirements, only minor initialization differences. With present mmc/mmcsd modules SDHC should work fine on any controller. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 18:05:26 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 E7C09106566C; Thu, 22 Jan 2009 18:05:26 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 4EE6B8FC19; Thu, 22 Jan 2009 18:05:26 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0MI5MdC056679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Jan 2009 19:05:22 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0MI5JAh028006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 19:05:19 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0MI5J1L053077; Thu, 22 Jan 2009 19:05:19 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0MI5I5D053076; Thu, 22 Jan 2009 19:05:18 +0100 (CET) (envelope-from ticso) Date: Thu, 22 Jan 2009 19:05:18 +0100 From: Bernd Walter To: Alexander Motin Message-ID: <20090122180518.GK50103@cicely7.cicely.de> References: <20090121.100533.-1955669401.imp@bsdimp.com> <20090121.101459.2022307528.imp@bsdimp.com> <49776734.8030805@FreeBSD.org> <20090121.122842.-1582190967.imp@bsdimp.com> <20090122105650.GB50103@cicely7.cicely.de> <49787314.3070004@FreeBSD.org> <20090122142015.GC50103@cicely7.cicely.de> <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> <4978B4A6.8060408@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4978B4A6.8060408@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, ticso@cicely.de Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 18:05:27 -0000 On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: > Bernd Walter wrote: > >As another point: > >Is it possible to support SHDC with mci some day, or is there a special > >hardware requirement for SDHC? > > SDHC (SD High Capacity) has just a different data addressing scheme (in > 512bytes blocks instead of bytes). There is no special hardware > requirements, only minor initialization differences. With present > mmc/mmcsd modules SDHC should work fine on any controller. Good news - thank you for clearification. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 23:00:45 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 37F4B1065678; Thu, 22 Jan 2009 23:00:45 +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 E59F28FC13; Thu, 22 Jan 2009 23:00:44 +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 n0MMv18m054091; Thu, 22 Jan 2009 15:57:02 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 15:57:41 -0700 (MST) Message-Id: <20090122.155741.-470325804.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de From: "M. Warner Losh" In-Reply-To: <20090122180518.GK50103@cicely7.cicely.de> References: <20090122151340.GE50103@cicely7.cicely.de> <4978B4A6.8060408@FreeBSD.org> <20090122180518.GK50103@cicely7.cicely.de> 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: mav@FreeBSD.org, 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: Thu, 22 Jan 2009 23:00:46 -0000 In message: <20090122180518.GK50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: : > Bernd Walter wrote: : > >As another point: : > >Is it possible to support SHDC with mci some day, or is there a special : > >hardware requirement for SDHC? : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in : > 512bytes blocks instead of bytes). There is no special hardware : > requirements, only minor initialization differences. With present : > mmc/mmcsd modules SDHC should work fine on any controller. : : Good news - thank you for clearification. Now all we need to do is to enhance the boot blocks to be able to boot off the SDHC cards :) BTW, I found and fixed the bug (at least I think so). We were assuming that all transfers were 512 bytes long. The newly used 16 and 64 byte transfers broke that assumption, which is why things broke after Alexander's latest commits. There's still a small chance that there's something borked in the byte swapping code, but I kinda doubt it since I was able to mount root. svn commit r187603 is the fix. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 23:06:53 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 CF4E31065695; Thu, 22 Jan 2009 23:06:53 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 09E0F8FC0C; Thu, 22 Jan 2009 23:06:52 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0MN6nww074176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Jan 2009 00:06:49 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0MN6lHr036893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 00:06:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0MN6lLU053870; Fri, 23 Jan 2009 00:06:47 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0MN6lYr053869; Fri, 23 Jan 2009 00:06:47 +0100 (CET) (envelope-from ticso) Date: Fri, 23 Jan 2009 00:06:47 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20090122230647.GN50103@cicely7.cicely.de> References: <20090122151340.GE50103@cicely7.cicely.de> <4978B4A6.8060408@FreeBSD.org> <20090122180518.GK50103@cicely7.cicely.de> <20090122.155741.-470325804.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090122.155741.-470325804.imp@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, mav@FreeBSD.org, ticso@cicely7.cicely.de, ticso@cicely.de Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 23:06:55 -0000 On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: > In message: <20090122180518.GK50103@cicely7.cicely.de> > Bernd Walter writes: > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: > : > Bernd Walter wrote: > : > >As another point: > : > >Is it possible to support SHDC with mci some day, or is there a special > : > >hardware requirement for SDHC? > : > > : > SDHC (SD High Capacity) has just a different data addressing scheme (in > : > 512bytes blocks instead of bytes). There is no special hardware > : > requirements, only minor initialization differences. With present > : > mmc/mmcsd modules SDHC should work fine on any controller. > : > : Good news - thank you for clearification. > > Now all we need to do is to enhance the boot blocks to be able to boot > off the SDHC cards :) Yes, but since you wrote code to store the kernel inside SPI-flash there is a useable workaround available ;-) Full loader support would be more interesting than SDHC in boot code anyway. > BTW, I found and fixed the bug (at least I think so). We were > assuming that all transfers were 512 bytes long. The newly used 16 > and 64 byte transfers broke that assumption, which is why things broke > after Alexander's latest commits. There's still a small chance that > there's something borked in the byte swapping code, but I kinda doubt > it since I was able to mount root. > > svn commit r187603 is the fix. Great! -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 23:27:02 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 3E56E106566B; Thu, 22 Jan 2009 23:27:02 +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 E8ECD8FC13; Thu, 22 Jan 2009 23:27: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 n0MNPs8p054515; Thu, 22 Jan 2009 16:25:54 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 16:26:33 -0700 (MST) Message-Id: <20090122.162633.1849591410.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de From: "M. Warner Losh" In-Reply-To: <20090122230647.GN50103@cicely7.cicely.de> References: <20090122180518.GK50103@cicely7.cicely.de> <20090122.155741.-470325804.imp@bsdimp.com> <20090122230647.GN50103@cicely7.cicely.de> 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: mav@FreeBSD.org, 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: Thu, 22 Jan 2009 23:27:02 -0000 In message: <20090122230647.GN50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: : > In message: <20090122180518.GK50103@cicely7.cicely.de> : > Bernd Walter writes: : > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: : > : > Bernd Walter wrote: : > : > >As another point: : > : > >Is it possible to support SHDC with mci some day, or is there a special : > : > >hardware requirement for SDHC? : > : > : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in : > : > 512bytes blocks instead of bytes). There is no special hardware : > : > requirements, only minor initialization differences. With present : > : > mmc/mmcsd modules SDHC should work fine on any controller. : > : : > : Good news - thank you for clearification. : > : > Now all we need to do is to enhance the boot blocks to be able to boot : > off the SDHC cards :) : : Yes, but since you wrote code to store the kernel inside SPI-flash : there is a useable workaround available ;-) : Full loader support would be more interesting than SDHC in boot code : anyway. Raj@ did some interesting work in this area for the marvel port... : > BTW, I found and fixed the bug (at least I think so). We were : > assuming that all transfers were 512 bytes long. The newly used 16 : > and 64 byte transfers broke that assumption, which is why things broke : > after Alexander's latest commits. There's still a small chance that : > there's something borked in the byte swapping code, but I kinda doubt : > it since I was able to mount root. : > : > svn commit r187603 is the fix. : : Great! Well, it doesn't work in 4-bit bus mode. Of course, I'm not sure it ever worked in 4-bit bus mode... Warner From owner-freebsd-arm@FreeBSD.ORG Thu Jan 22 23:57:19 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 EEC5A10657C0; Thu, 22 Jan 2009 23:57:18 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 83A5E8FC0A; Thu, 22 Jan 2009 23:57:18 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0MNvF5L075780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Jan 2009 00:57:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0MNvCWn038226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 00:57:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0MNvCic053992; Fri, 23 Jan 2009 00:57:12 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0MNvCl2053991; Fri, 23 Jan 2009 00:57:12 +0100 (CET) (envelope-from ticso) Date: Fri, 23 Jan 2009 00:57:12 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20090122235712.GO50103@cicely7.cicely.de> References: <20090122180518.GK50103@cicely7.cicely.de> <20090122.155741.-470325804.imp@bsdimp.com> <20090122230647.GN50103@cicely7.cicely.de> <20090122.162633.1849591410.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090122.162633.1849591410.imp@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, mav@FreeBSD.org, ticso@cicely7.cicely.de, ticso@cicely.de Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2009 23:57:20 -0000 On Thu, Jan 22, 2009 at 04:26:33PM -0700, M. Warner Losh wrote: > In message: <20090122230647.GN50103@cicely7.cicely.de> > Bernd Walter writes: > : On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: > : > In message: <20090122180518.GK50103@cicely7.cicely.de> > : > Bernd Walter writes: > : > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: > : > : > Bernd Walter wrote: > : > : > >As another point: > : > : > >Is it possible to support SHDC with mci some day, or is there a special > : > : > >hardware requirement for SDHC? > : > : > > : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in > : > : > 512bytes blocks instead of bytes). There is no special hardware > : > : > requirements, only minor initialization differences. With present > : > : > mmc/mmcsd modules SDHC should work fine on any controller. > : > : > : > : Good news - thank you for clearification. > : > > : > Now all we need to do is to enhance the boot blocks to be able to boot > : > off the SDHC cards :) > : > : Yes, but since you wrote code to store the kernel inside SPI-flash > : there is a useable workaround available ;-) > : Full loader support would be more interesting than SDHC in boot code > : anyway. > > Raj@ did some interesting work in this area for the marvel port... I already noticed his work with great pleasure. > : > BTW, I found and fixed the bug (at least I think so). We were > : > assuming that all transfers were 512 bytes long. The newly used 16 > : > and 64 byte transfers broke that assumption, which is why things broke > : > after Alexander's latest commits. There's still a small chance that > : > there's something borked in the byte swapping code, but I kinda doubt > : > it since I was able to mount root. > : > > : > svn commit r187603 is the fix. > : > : Great! > > Well, it doesn't work in 4-bit bus mode. Of course, I'm not sure it > ever worked in 4-bit bus mode... It never worked - I tried it a while back and had interesting results, but it wasn't stable, which I asumed to be my bad knowledge on how this should be implemented correctly. Thanks to mav@ we have other controllers working and can test the sdmmc part unrelated from mci. Nevertheless: multiblock is the real speed issue. My speed tests were very impressive, but because of mci problems data were corrupted of course. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 23 00:15:03 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 1B50510656BB; Fri, 23 Jan 2009 00:15:03 +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 A90F98FC1D; Fri, 23 Jan 2009 00:15:02 +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 n0N0COsE055069; Thu, 22 Jan 2009 17:12:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 22 Jan 2009 17:13:04 -0700 (MST) Message-Id: <20090122.171304.-1528842637.imp@bsdimp.com> To: ticso@cicely.de, ticso@cicely7.cicely.de From: "M. Warner Losh" In-Reply-To: <20090122235712.GO50103@cicely7.cicely.de> References: <20090122230647.GN50103@cicely7.cicely.de> <20090122.162633.1849591410.imp@bsdimp.com> <20090122235712.GO50103@cicely7.cicely.de> 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: mav@freebsd.org, 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: Fri, 23 Jan 2009 00:15:03 -0000 In message: <20090122235712.GO50103@cicely7.cicely.de> Bernd Walter writes: : On Thu, Jan 22, 2009 at 04:26:33PM -0700, M. Warner Losh wrote: : > In message: <20090122230647.GN50103@cicely7.cicely.de> : > Bernd Walter writes: : > : On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: : > : > In message: <20090122180518.GK50103@cicely7.cicely.de> : > : > Bernd Walter writes: : > : > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: : > : > : > Bernd Walter wrote: : > : > : > >As another point: : > : > : > >Is it possible to support SHDC with mci some day, or is there a special : > : > : > >hardware requirement for SDHC? : > : > : > : > : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in : > : > : > 512bytes blocks instead of bytes). There is no special hardware : > : > : > requirements, only minor initialization differences. With present : > : > : > mmc/mmcsd modules SDHC should work fine on any controller. : > : > : : > : > : Good news - thank you for clearification. : > : > : > : > Now all we need to do is to enhance the boot blocks to be able to boot : > : > off the SDHC cards :) : > : : > : Yes, but since you wrote code to store the kernel inside SPI-flash : > : there is a useable workaround available ;-) : > : Full loader support would be more interesting than SDHC in boot code : > : anyway. : > : > Raj@ did some interesting work in this area for the marvel port... : : I already noticed his work with great pleasure. : : > : > BTW, I found and fixed the bug (at least I think so). We were : > : > assuming that all transfers were 512 bytes long. The newly used 16 : > : > and 64 byte transfers broke that assumption, which is why things broke : > : > after Alexander's latest commits. There's still a small chance that : > : > there's something borked in the byte swapping code, but I kinda doubt : > : > it since I was able to mount root. : > : > : > : > svn commit r187603 is the fix. : > : : > : Great! : > : > Well, it doesn't work in 4-bit bus mode. Of course, I'm not sure it : > ever worked in 4-bit bus mode... : : It never worked - I tried it a while back and had interesting results, : but it wasn't stable, which I asumed to be my bad knowledge on how this : should be implemented correctly. : Thanks to mav@ we have other controllers working and can test the : sdmmc part unrelated from mci. : Nevertheless: multiblock is the real speed issue. : My speed tests were very impressive, but because of mci problems data : were corrupted of course. I'll see if I can find an hour or two to look into the proper reset of the mci fifos after use... I'd also like to get 4-bit working too... Right now I'm only getting ~900kB/s (890-919) and we can do much better, no? Warner From owner-freebsd-arm@FreeBSD.ORG Fri Jan 23 09:17:38 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 B6D1C1065694 for ; Fri, 23 Jan 2009 09:17:38 +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 3850E8FC13 for ; Fri, 23 Jan 2009 09:17:38 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [77.52.72.118] (account mavbsd@alkar.net HELO localhost) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 232357808; Fri, 23 Jan 2009 11:17:35 +0200 Sender: mav@FreeBSD.org From: "Alexander Motin" To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely7.cicely.de MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Message-ID: <200901231117070000@1426712698> X-Mailer: FlexMail 4 Date: Fri, 23 Jan 2009 11:17:06 +0200 Content-Transfer-Encoding: 8bit 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: Fri, 23 Jan 2009 09:17:39 -0000 > Right now I'm only getting ~900kB/s (890-919) and we can do much > better, no? I have started from alike values with sdmmc driver, but with multiblock transfers and 4 bits bus I have reached top possible for my controller 15Mbytes/s. Multiblock transfers are very important to reduce number of interrupts. -- Alexander Motin From owner-freebsd-arm@FreeBSD.ORG Fri Jan 23 10:31:04 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 8AB6310656CB; Fri, 23 Jan 2009 10:31:04 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0D5B98FC1E; Fri, 23 Jan 2009 10:31:03 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n0NAV0ug094118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Jan 2009 11:31:00 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n0NAUrk2055651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 11:30:53 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n0NAUrrL055652; Fri, 23 Jan 2009 11:30:53 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n0NAUrdd055651; Fri, 23 Jan 2009 11:30:53 +0100 (CET) (envelope-from ticso) Date: Fri, 23 Jan 2009 11:30:53 +0100 From: Bernd Walter To: Alexander Motin Message-ID: <20090123103053.GR50103@cicely7.cicely.de> References: <200901231117070000@1426712698> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200901231117070000@1426712698> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.055, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-arm@FreeBSD.org, ticso@cicely7.cicely.de, ticso@cicely.de Subject: Re: Mount root from SD card? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2009 10:31:06 -0000 On Fri, Jan 23, 2009 at 11:17:06AM +0200, Alexander Motin wrote: > > Right now I'm only getting ~900kB/s (890-919) and we can do much > > better, no? > > I have started from alike values with sdmmc driver, but with multiblock transfers and 4 bits bus I have reached top possible for my controller 15Mbytes/s. Multiblock transfers are very important to reduce number of interrupts. Not only that - they are important for card internal optimization. Especially with writing a transfer can issue read-modify-write cycles on the large cell blocks and writing a 16k FS block in 32 card transactions is not very perfect. Especially many MLC cards have a large write transaction overhead. With reading it just means opening the cells for reading, but some card designs are slow with this as well. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Jan 23 16:06:25 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 0B44C1065691 for ; Fri, 23 Jan 2009 16:06:25 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id B28BE8FC25 for ; Fri, 23 Jan 2009 16:06:24 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id BBE05CC35; Fri, 23 Jan 2009 18:06:22 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14965-02; Fri, 23 Jan 2009 18:06:22 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id F01AFCC1C; Fri, 23 Jan 2009 18:06:21 +0200 (EET) Message-ID: <4979EAFE.2030407@bulinfo.net> Date: Fri, 23 Jan 2009 18:06:22 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: "M. Warner Losh" References: <49788702.9010808@FreeBSD.org> <20090122151340.GE50103@cicely7.cicely.de> <497896F3.9030908@bulinfo.net> <20090122.093007.1785588956.imp@bsdimp.com> In-Reply-To: <20090122.093007.1785588956.imp@bsdimp.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Fri, 23 Jan 2009 16:06:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <497896F3.9030908@bulinfo.net> > Krassimir Slavchev writes: > : Index: at91_mci.c > : =================================================================== > : --- at91_mci.c (revision 187590) > : +++ at91_mci.c (working copy) > : @@ -199,7 +199,7 @@ > : goto out; > : } > : sc->host.f_min = 375000; > : - sc->host.f_max = at91_master_clock / 2; /* Typically 30MHz */ > : + sc->host.f_max = AT91C_MASTER_CLOCK / 2; /* Typically 30MHz */ > : sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; > : if (sc->wire4) > : sc->host.caps = MMC_CAP_4_BIT_DATA; > > This change is wrong. Ok. I did this because at91_master_clock was not defined here. > > : @@ -399,8 +399,8 @@ > : WR4(sc, MCI_ARGR, cmd->arg); > : if (cmdr & MCI_CMDR_TRCMD_START) { > : if (cmdr & MCI_CMDR_TRDIR) { > : + WR4(sc, MCI_CMDR, cmdr); > : WR4(sc, PDC_PTCR, PDC_PTCR_RXTEN); > : - WR4(sc, MCI_CMDR, cmdr); > > This change is also wrong. It won't work. Also, why test the > direction at all if we're just going to do the same thing in both legs > of the branch? When I was developing the code, I originally had the > 'send a command and then enable PDC' logic. It didn't work for the > read case, so now we enable the reader and then send the command. We > do this based on the logic that it is OK to have the PDC enabled when > there's no data transfer going, but if we send the command, then take > an interrupt before we can enable the PDC, we'd lose data. And that > seemed to happen a lot. Ok but I was able to read correctly first blocks ... Looking at linux's driver they do the same, first sending CMD and then enable PDC for reading. Thanks for latest fixes! Best regards > > There's lots of races in programming this chip :( > > : } else { > : WR4(sc, MCI_CMDR, cmdr); > : WR4(sc, PDC_PTCR, PDC_PTCR_TXTEN); > > > Warner > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJeer9xJBWvpalMpkRAoe5AJ44dnZY2pKZY/ZphexulLPFFXzN7wCfS+T/ pV+SezanCxT/pYtWE6dsKVM= =GPct -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Fri Jan 23 16:15:58 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 18A0410658C3; Fri, 23 Jan 2009 16:15:58 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 89B738FC14; Fri, 23 Jan 2009 16:15:57 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id EACC8CC45; Fri, 23 Jan 2009 18:15:55 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13545-07; Fri, 23 Jan 2009 18:15:54 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id A7263CC32; Fri, 23 Jan 2009 18:15:54 +0200 (EET) Message-ID: <4979ED3A.2020008@bulinfo.net> Date: Fri, 23 Jan 2009 18:15:54 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090122230647.GN50103@cicely7.cicely.de> <20090122.162633.1849591410.imp@bsdimp.com> <20090122235712.GO50103@cicely7.cicely.de> <20090122.171304.-1528842637.imp@bsdimp.com> In-Reply-To: <20090122.171304.-1528842637.imp@bsdimp.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: mav@freebsd.org, ticso@cicely7.cicely.de, freebsd-arm@freebsd.org, ticso@cicely.de 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: Fri, 23 Jan 2009 16:15:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <20090122235712.GO50103@cicely7.cicely.de> > Bernd Walter writes: > : On Thu, Jan 22, 2009 at 04:26:33PM -0700, M. Warner Losh wrote: > : > In message: <20090122230647.GN50103@cicely7.cicely.de> > : > Bernd Walter writes: > : > : On Thu, Jan 22, 2009 at 03:57:41PM -0700, M. Warner Losh wrote: > : > : > In message: <20090122180518.GK50103@cicely7.cicely.de> > : > : > Bernd Walter writes: > : > : > : On Thu, Jan 22, 2009 at 08:02:14PM +0200, Alexander Motin wrote: > : > : > : > Bernd Walter wrote: > : > : > : > >As another point: > : > : > : > >Is it possible to support SHDC with mci some day, or is there a special > : > : > : > >hardware requirement for SDHC? > : > : > : > > : > : > : > SDHC (SD High Capacity) has just a different data addressing scheme (in > : > : > : > 512bytes blocks instead of bytes). There is no special hardware > : > : > : > requirements, only minor initialization differences. With present > : > : > : > mmc/mmcsd modules SDHC should work fine on any controller. > : > : > : > : > : > : Good news - thank you for clearification. > : > : > > : > : > Now all we need to do is to enhance the boot blocks to be able to boot > : > : > off the SDHC cards :) > : > : > : > : Yes, but since you wrote code to store the kernel inside SPI-flash > : > : there is a useable workaround available ;-) > : > : Full loader support would be more interesting than SDHC in boot code > : > : anyway. > : > > : > Raj@ did some interesting work in this area for the marvel port... > : > : I already noticed his work with great pleasure. > : > : > : > BTW, I found and fixed the bug (at least I think so). We were > : > : > assuming that all transfers were 512 bytes long. The newly used 16 > : > : > and 64 byte transfers broke that assumption, which is why things broke > : > : > after Alexander's latest commits. There's still a small chance that > : > : > there's something borked in the byte swapping code, but I kinda doubt > : > : > it since I was able to mount root. > : > : > > : > : > svn commit r187603 is the fix. > : > : > : > : Great! > : > > : > Well, it doesn't work in 4-bit bus mode. Of course, I'm not sure it > : > ever worked in 4-bit bus mode... > : > : It never worked - I tried it a while back and had interesting results, > : but it wasn't stable, which I asumed to be my bad knowledge on how this > : should be implemented correctly. > : Thanks to mav@ we have other controllers working and can test the > : sdmmc part unrelated from mci. > : Nevertheless: multiblock is the real speed issue. > : My speed tests were very impressive, but because of mci problems data > : were corrupted of course. > > I'll see if I can find an hour or two to look into the proper reset of > the mci fifos after use... I'd also like to get 4-bit working too... I have added some debug info with 4-bit mode enabled: http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump3 > > Right now I'm only getting ~900kB/s (890-919) and we can do much > better, no? > > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJee06xJBWvpalMpkRAgZ/AJ9FzKp7Oq00CZqWC/KIb31Ve0EPAgCdGH/l B1mZQcf8IYmdI/8x7C29iLo= =y2Rs -----END PGP SIGNATURE----- From owner-freebsd-arm@FreeBSD.ORG Fri Jan 23 16:18:43 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 37CCF1065670 for ; Fri, 23 Jan 2009 16:18:43 +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 CEF668FC14 for ; Fri, 23 Jan 2009 16:18:42 +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 n0NGEh9o071856; Fri, 23 Jan 2009 09:14:43 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 23 Jan 2009 09:15:23 -0700 (MST) Message-Id: <20090123.091523.-192571782.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <4979EAFE.2030407@bulinfo.net> References: <497896F3.9030908@bulinfo.net> <20090122.093007.1785588956.imp@bsdimp.com> <4979EAFE.2030407@bulinfo.net> 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: Fri, 23 Jan 2009 16:18:43 -0000 In message: <4979EAFE.2030407@bulinfo.net> Krassimir Slavchev writes: : -----BEGIN PGP SIGNED MESSAGE----- : Hash: SHA1 : : M. Warner Losh wrote: : > In message: <497896F3.9030908@bulinfo.net> : > Krassimir Slavchev writes: : > : Index: at91_mci.c : > : =================================================================== : > : --- at91_mci.c (revision 187590) : > : +++ at91_mci.c (working copy) : > : @@ -199,7 +199,7 @@ : > : goto out; : > : } : > : sc->host.f_min = 375000; : > : - sc->host.f_max = at91_master_clock / 2; /* Typically 30MHz */ : > : + sc->host.f_max = AT91C_MASTER_CLOCK / 2; /* Typically 30MHz */ : > : sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; : > : if (sc->wire4) : > : sc->host.caps = MMC_CAP_4_BIT_DATA; : > : > This change is wrong. : : Ok. I did this because at91_master_clock was not defined here. Yea, that's my bad, actually. I've since fixed it. : > : @@ -399,8 +399,8 @@ : > : WR4(sc, MCI_ARGR, cmd->arg); : > : if (cmdr & MCI_CMDR_TRCMD_START) { : > : if (cmdr & MCI_CMDR_TRDIR) { : > : + WR4(sc, MCI_CMDR, cmdr); : > : WR4(sc, PDC_PTCR, PDC_PTCR_RXTEN); : > : - WR4(sc, MCI_CMDR, cmdr); : > : > This change is also wrong. It won't work. Also, why test the : > direction at all if we're just going to do the same thing in both legs : > of the branch? When I was developing the code, I originally had the : > 'send a command and then enable PDC' logic. It didn't work for the : > read case, so now we enable the reader and then send the command. We : > do this based on the logic that it is OK to have the PDC enabled when : > there's no data transfer going, but if we send the command, then take : > an interrupt before we can enable the PDC, we'd lose data. And that : > seemed to happen a lot. : : Ok but I was able to read correctly first blocks ... : Looking at linux's driver they do the same, first sending CMD and then : enable PDC for reading. : : Thanks for latest fixes! Sure. The underlying problem was that we were doing 512 byte transfers for 64 byte requests. Ooops, that's bad. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Jan 23 16:45:44 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 97FD9106566B; Fri, 23 Jan 2009 16:45:44 +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 3CCE88FC08; Fri, 23 Jan 2009 16:45:44 +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 n0NGgSBi072355; Fri, 23 Jan 2009 09:42:28 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 23 Jan 2009 09:43:09 -0700 (MST) Message-Id: <20090123.094309.773732871.imp@bsdimp.com> To: krassi@bulinfo.net From: "M. Warner Losh" In-Reply-To: <4979ED3A.2020008@bulinfo.net> References: <20090122235712.GO50103@cicely7.cicely.de> <20090122.171304.-1528842637.imp@bsdimp.com> <4979ED3A.2020008@bulinfo.net> 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, mav@FreeBSD.org, ticso@cicely7.cicely.de, ticso@cicely.de 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: Fri, 23 Jan 2009 16:45:44 -0000 In message: <4979ED3A.2020008@bulinfo.net> Krassimir Slavchev writes: : I have added some debug info with 4-bit mode enabled: : : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump3 Looks like we're getting a FIFO error here. That's similar to what I'm seeing as well. I'm not sure why... I also have implemented a full reset of the device between reads, but I get a CRC error there. Time to look at the latest datasheet to see if I can find a better workaround. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Jan 23 17:02:37 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 C615A1065674 for ; Fri, 23 Jan 2009 17:02:37 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 78E1A8FC1D for ; Fri, 23 Jan 2009 17:02:37 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 581ADCC15; Fri, 23 Jan 2009 19:02:35 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14965-08; Fri, 23 Jan 2009 19:02:32 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id 92A42C44C; Fri, 23 Jan 2009 19:02:32 +0200 (EET) Message-ID: <4979F827.1010309@bulinfo.net> Date: Fri, 23 Jan 2009 19:02:31 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090122235712.GO50103@cicely7.cicely.de> <20090122.171304.-1528842637.imp@bsdimp.com> <4979ED3A.2020008@bulinfo.net> <20090123.094309.773732871.imp@bsdimp.com> In-Reply-To: <20090123.094309.773732871.imp@bsdimp.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net 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: Fri, 23 Jan 2009 17:02:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <4979ED3A.2020008@bulinfo.net> > Krassimir Slavchev writes: > : I have added some debug info with 4-bit mode enabled: > : > : http://mnemonic.bulinfo.net/~krassi/ARM/sd.dump3 > > Looks like we're getting a FIFO error here. That's similar to what > I'm seeing as well. I'm not sure why... > > I also have implemented a full reset of the device between reads, but > I get a CRC error there. Time to look at the latest datasheet to see > if I can find a better workaround. > > Warner > Let me know if you want to test something. Best Regards -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJefgnxJBWvpalMpkRApfmAKC3BkB4JpP+pAzwHhXcg3uAZ1KAsgCgn8Jv aUMFhwV7Q2BhwLRQ+OadJWo= =AUNO -----END PGP SIGNATURE-----