From owner-freebsd-arm@FreeBSD.ORG Sun Feb 27 21:27:44 2011 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 19DC2106566B for ; Sun, 27 Feb 2011 21:27:44 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:50:40:63ff:feea:93a]) by mx1.freebsd.org (Postfix) with ESMTP id A5E148FC0C for ; Sun, 27 Feb 2011 21:27:43 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.2/8.14.3) with ESMTP id p1RLTCRs084818; Sun, 27 Feb 2011 22:29:12 +0100 (CET) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.2/8.14.3/Submit) id p1RLTCpp084817; Sun, 27 Feb 2011 22:29:12 +0100 (CET) (envelope-from mlfbsd) Date: Sun, 27 Feb 2011 22:29:11 +0100 From: Olivier Houchard To: Krassimir Slavchev Message-ID: <20110227212911.GA84773@ci0.org> References: <4D6645A5.7060106@bulinfo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6645A5.7060106@bulinfo.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on Toshiba AC100? 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: Sun, 27 Feb 2011 21:27:44 -0000 Hi Krassimir, On Thu, Feb 24, 2011 at 01:48:53PM +0200, Krassimir Slavchev wrote: > Hello All, > > Some information about this notebook: > > http://uk.computers.toshiba-europe.com/innovation/generic/home-ac100/ > > AC100 has a 1GHz NVIDIA Tegra 250 mobile processor (built on a dual-core > ARM Cortex-A9 MPCore processor); it has 512 MB of DDR2 RAM and up to a > 32 GB solid state drive for storing and sharing of files, video, photos > and music. Its wireless connectivity includes 802.11 B/G/N WLAN, > optional 3G Mobile Broadband and Bluetooth 2.1 + EDR. A single HDMI > connection is also provided for those who want to output video from the > smartbook. It also has a 1.3 megapixel webcam with microphone which > allows video chatting. This would be a fine target for FreeBSD, unfortunately, getting docs from NVidia about the Tegra 2 CPU is more complicated than expected, so there's just no support yet. Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Mon Feb 28 11:06:55 2011 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 20C9F106564A for ; Mon, 28 Feb 2011 11:06:55 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0EE618FC1F for ; Mon, 28 Feb 2011 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p1SB6sm9011914 for ; Mon, 28 Feb 2011 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p1SB6s4J011912 for freebsd-arm@FreeBSD.org; Mon, 28 Feb 2011 11:06:54 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Feb 2011 11:06:54 GMT Message-Id: <201102281106.p1SB6s4J011912@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org 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, 28 Feb 2011 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/154306 arm named crashes with signal 11 o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/154189 arm lang/perl5.12 doesn't build on arm o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 8 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Feb 28 16:23:42 2011 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE601106566C; Mon, 28 Feb 2011 16:23:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 68A088FC0C; Mon, 28 Feb 2011 16:23:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p1SGNf1k051107; Mon, 28 Feb 2011 11:23:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1SGNfjT051106; Mon, 28 Feb 2011 16:23:41 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 28 Feb 2011 16:23:41 GMT Message-Id: <201102281623.p1SGNfjT051106@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 16:23:42 -0000 TB --- 2011-02-28 15:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-28 15:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-02-28 15:30:00 - cleaning the object tree TB --- 2011-02-28 15:30:14 - cvsupping the source tree TB --- 2011-02-28 15:30:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-02-28 15:31:01 - building world TB --- 2011-02-28 15:31:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-28 15:31:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-28 15:31:01 - TARGET=arm TB --- 2011-02-28 15:31:01 - TARGET_ARCH=arm TB --- 2011-02-28 15:31:01 - TZ=UTC TB --- 2011-02-28 15:31:01 - __MAKE_CONF=/dev/null TB --- 2011-02-28 15:31:01 - cd /src TB --- 2011-02-28 15:31:01 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 28 15:31:01 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -o fdwrite fdwrite.o gzip -cn /src/usr.sbin/fdwrite/fdwrite.1 > fdwrite.1.gz ===> usr.sbin/fifolog (all) ===> usr.sbin/fifolog/lib (all) cc -O -pipe -I/src/usr.sbin/fifolog/lib -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/fifolog/lib/fifolog_int.c cc1: warnings being treated as errors /src/usr.sbin/fifolog/lib/fifolog_int.c: In function 'fifolog_int_open_i': /src/usr.sbin/fifolog/lib/fifolog_int.c:110: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/fifolog/lib. *** Error code 1 Stop in /src/usr.sbin/fifolog. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-02-28 16:23:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-28 16:23:40 - ERROR: failed to build world TB --- 2011-02-28 16:23:41 - 2312.49 user 633.88 system 3220.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Feb 28 21:22:56 2011 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0051106564A; Mon, 28 Feb 2011 21:22:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8A1A58FC08; Mon, 28 Feb 2011 21:22:56 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p1SLMtNW065205; Mon, 28 Feb 2011 16:22:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p1SLMtqx065204; Mon, 28 Feb 2011 21:22:55 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 28 Feb 2011 21:22:55 GMT Message-Id: <201102282122.p1SLMtqx065204@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 21:22:57 -0000 TB --- 2011-02-28 20:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-02-28 20:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-02-28 20:30:00 - cleaning the object tree TB --- 2011-02-28 20:30:08 - cvsupping the source tree TB --- 2011-02-28 20:30:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-02-28 20:30:28 - building world TB --- 2011-02-28 20:30:28 - MAKEOBJDIRPREFIX=/obj TB --- 2011-02-28 20:30:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-02-28 20:30:28 - TARGET=arm TB --- 2011-02-28 20:30:28 - TARGET_ARCH=arm TB --- 2011-02-28 20:30:28 - TZ=UTC TB --- 2011-02-28 20:30:28 - __MAKE_CONF=/dev/null TB --- 2011-02-28 20:30:28 - cd /src TB --- 2011-02-28 20:30:28 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 28 20:30:29 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/fdwrite/fdwrite.1 > fdwrite.1.gz ===> usr.sbin/fifolog (all) ===> usr.sbin/fifolog/lib (all) cc -O -pipe -I/src/usr.sbin/fifolog/lib -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/fifolog/lib/fifolog_int.c cc -O -pipe -I/src/usr.sbin/fifolog/lib -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/fifolog/lib/fifolog_create.c cc1: warnings being treated as errors /src/usr.sbin/fifolog/lib/fifolog_create.c: In function 'fifolog_create': /src/usr.sbin/fifolog/lib/fifolog_create.c:83: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/fifolog/lib. *** Error code 1 Stop in /src/usr.sbin/fifolog. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-02-28 21:22:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-02-28 21:22:55 - ERROR: failed to build world TB --- 2011-02-28 21:22:55 - 2311.34 user 633.73 system 3175.24 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Mar 1 02:23:01 2011 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53452106564A; Tue, 1 Mar 2011 02:23:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E79B18FC1E; Tue, 1 Mar 2011 02:23:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p212Mxkk079355; Mon, 28 Feb 2011 21:22:59 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p212MxZu079354; Tue, 1 Mar 2011 02:22:59 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 1 Mar 2011 02:22:59 GMT Message-Id: <201103010222.p212MxZu079354@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 02:23:01 -0000 TB --- 2011-03-01 01:30:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-03-01 01:30:01 - starting HEAD tinderbox run for arm/arm TB --- 2011-03-01 01:30:01 - cleaning the object tree TB --- 2011-03-01 01:30:12 - cvsupping the source tree TB --- 2011-03-01 01:30:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-03-01 01:30:31 - building world TB --- 2011-03-01 01:30:31 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-01 01:30:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-01 01:30:31 - TARGET=arm TB --- 2011-03-01 01:30:31 - TARGET_ARCH=arm TB --- 2011-03-01 01:30:31 - TZ=UTC TB --- 2011-03-01 01:30:31 - __MAKE_CONF=/dev/null TB --- 2011-03-01 01:30:31 - cd /src TB --- 2011-03-01 01:30:31 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 1 01:30:31 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/fdwrite/fdwrite.1 > fdwrite.1.gz ===> usr.sbin/fifolog (all) ===> usr.sbin/fifolog/lib (all) cc -O -pipe -I/src/usr.sbin/fifolog/lib -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/fifolog/lib/fifolog_int.c cc -O -pipe -I/src/usr.sbin/fifolog/lib -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/fifolog/lib/fifolog_create.c cc1: warnings being treated as errors /src/usr.sbin/fifolog/lib/fifolog_create.c: In function 'fifolog_create': /src/usr.sbin/fifolog/lib/fifolog_create.c:83: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/fifolog/lib. *** Error code 1 Stop in /src/usr.sbin/fifolog. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-01 02:22:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-01 02:22:59 - ERROR: failed to build world TB --- 2011-03-01 02:22:59 - 2311.42 user 632.96 system 3178.37 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Mar 1 07:23:10 2011 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36FAE106564A; Tue, 1 Mar 2011 07:23:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id D58738FC13; Tue, 1 Mar 2011 07:23:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.4) with ESMTP id p217N8og093525; Tue, 1 Mar 2011 02:23:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.4/Submit) id p217N823093524; Tue, 1 Mar 2011 07:23:08 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 1 Mar 2011 07:23:08 GMT Message-Id: <201103010723.p217N823093524@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 07:23:10 -0000 TB --- 2011-03-01 06:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2011-03-01 06:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-03-01 06:30:00 - cleaning the object tree TB --- 2011-03-01 06:30:11 - cvsupping the source tree TB --- 2011-03-01 06:30:11 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-03-01 06:30:32 - building world TB --- 2011-03-01 06:30:32 - MAKEOBJDIRPREFIX=/obj TB --- 2011-03-01 06:30:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-03-01 06:30:32 - TARGET=arm TB --- 2011-03-01 06:30:32 - TARGET_ARCH=arm TB --- 2011-03-01 06:30:32 - TZ=UTC TB --- 2011-03-01 06:30:32 - __MAKE_CONF=/dev/null TB --- 2011-03-01 06:30:32 - cd /src TB --- 2011-03-01 06:30:32 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 1 06:30:32 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.sbin/fdwrite/fdwrite.1 > fdwrite.1.gz ===> usr.sbin/fifolog (all) ===> usr.sbin/fifolog/lib (all) cc -O -pipe -I/src/usr.sbin/fifolog/lib -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/fifolog/lib/fifolog_int.c cc -O -pipe -I/src/usr.sbin/fifolog/lib -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.sbin/fifolog/lib/fifolog_create.c cc1: warnings being treated as errors /src/usr.sbin/fifolog/lib/fifolog_create.c: In function 'fifolog_create': /src/usr.sbin/fifolog/lib/fifolog_create.c:83: warning: comparison between signed and unsigned *** Error code 1 Stop in /src/usr.sbin/fifolog/lib. *** Error code 1 Stop in /src/usr.sbin/fifolog. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-03-01 07:23:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-03-01 07:23:08 - ERROR: failed to build world TB --- 2011-03-01 07:23:08 - 2312.94 user 632.92 system 3187.51 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Mar 2 22:10:11 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FCF8106567B for ; Wed, 2 Mar 2011 22:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 392668FC1D for ; Wed, 2 Mar 2011 22:10:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p22MABVZ078818 for ; Wed, 2 Mar 2011 22:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p22MABmL078817; Wed, 2 Mar 2011 22:10:11 GMT (envelope-from gnats) Resent-Date: Wed, 2 Mar 2011 22:10:11 GMT Resent-Message-Id: <201103022210.p22MABmL078817@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-arm@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Ian Lepore Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 980BB106566C for ; Wed, 2 Mar 2011 22:06:34 +0000 (UTC) (envelope-from ilepore@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 782CB8FC14 for ; Wed, 2 Mar 2011 22:06:34 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta03.emeryville.ca.mail.comcast.net with comcast id EMqY1g0011eYJf8A3MtQ93; Wed, 02 Mar 2011 21:53:24 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta19.emeryville.ca.mail.comcast.net with comcast id EMtL1g00R4NgCEG01MtMzK; Wed, 02 Mar 2011 21:53:22 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id p22LrILY092795 for ; Wed, 2 Mar 2011 14:53:18 -0700 (MST) (envelope-from ilepore@damnhippie.dyndns.org) Received: (from ilepore@localhost) by revolution.hippie.lan (8.14.4/8.14.4/Submit) id p22LrIhP097307; Wed, 2 Mar 2011 14:53:18 -0700 (MST) (envelope-from ilepore) Message-Id: <201103022153.p22LrIhP097307@revolution.hippie.lan> Date: Wed, 2 Mar 2011 14:53:18 -0700 (MST) From: Ian Lepore To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:10:11 -0000 >Number: 155214 >Category: arm >Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-arm >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 02 22:10:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Ian Lepore >Release: FreeBSD 8.2-RC3 arm >Organization: none >Environment: FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB arm Included patch is against -current even though the problem was first seen on 8.2-RC3 The problem was seen on AT91RM9200 hardware, but presumably also affects the SAM9 series which uses the same driver code. >Description: With the latest generation of large-capacity SD cards, write speeds as low as 20 kbytes/sec are seen. These modern cards have erase-block sizes as large as 8192K (compared to 32K typical on previous generations). The at91_mci driver does only single-sector IO; apparently this requires the SD card to internally perform an expensive read-erase-modify-write cycle for each 512 byte block written to the card. It should be noted that even with older SD cards that have smaller erase-block sizes, write throughput to the card rarely exceeds about 350 kbytes/sec; still very slow for modern hardware. With the patch provided, write throughput improves to approximately 1500 kbytes/sec. Read speeds also improve (was 640, now 2400 kbytes/sec). >How-To-Repeat: The slow IO can be demonstrated using dd to write directly to the device (bypassing buffering and caching at higher layers): dvb# dd if=/dev/zero of=/dev/mmcsd0s2a bs=64k count=100 100+0 records in 100+0 records out 6553600 bytes transferred in 266.252838 secs (24614 bytes/sec) dvb# dd if=/dev/zero of=/dev/mmcsd0s2a bs=6400k count=1 1+0 records in 1+0 records out 6553600 bytes transferred in 265.004883 secs (24730 bytes/sec) >Fix: The following patch adds support for multi-block IO to the at91_mci driver. The patch is to -current even though the problem was discovered in 8.2-RC3. The patched driver will also work in 8.2, but requires a few other items in the arm/at91 directory to be back-ported as well (to support references to things such as at91_master_clock and at91_is_rm9200)). --- patch-arm-at91_mci-for-multiblock begins here --- --- sys/arm/at91/at91_mci.c.cvs_v1.18 2011-02-28 13:43:54.000000000 -0700 +++ sys/arm/at91/at91_mci.c 2011-03-02 07:21:38.000000000 -0700 @@ -67,7 +67,13 @@ #include "opt_at91.h" -#define BBSZ 512 +#ifndef AT91_MCI_MAX_BLOCKS +#define AT91_MCI_MAX_BLOCKS 64 /* default 32k bounce buffer */ +#endif + +#define BBSIZE (AT91_MCI_MAX_BLOCKS * 512) + +static int mci_debug; struct at91_mci_softc { void *intrhand; /* Interrupt handle */ @@ -75,21 +81,24 @@ int sc_cap; #define CAP_HAS_4WIRE 1 /* Has 4 wire bus */ #define CAP_NEEDS_BYTESWAP 2 /* broken hardware needing bounce */ - int flags; int has_4wire; -#define CMD_STARTED 1 -#define STOP_STARTED 2 + int flags; +#define PENDING_CMD 0x01 +#define PENDING_STOP 0x02 +#define PENDING_ERROR 0x04 +#define CMD_MULTIREAD 0x10 +#define CMD_MULTIWRITE 0x20 struct resource *irq_res; /* IRQ resource */ struct resource *mem_res; /* Memory resource */ struct mtx sc_mtx; bus_dma_tag_t dmatag; bus_dmamap_t map; - int mapped; struct mmc_host host; int bus_busy; struct mmc_request *req; struct mmc_command *curcmd; - char bounce_buffer[BBSZ]; + char *bbuf_vaddr; /* bounce buf in KVA space */ + bus_addr_t bbuf_paddr; /* bounce buf mapped into DMA space */ }; static inline uint32_t @@ -124,6 +133,14 @@ #define AT91_MCI_ASSERT_UNLOCKED(_sc) mtx_assert(&_sc->sc_mtx, MA_NOTOWNED); static void +at91_mci_getaddr(void *arg, bus_dma_segment_t *segs, int nsegs, int error) +{ + if (error != 0) + return; + *(bus_addr_t *)arg = segs[0].ds_addr; +} + +static void at91_mci_pdc_disable(struct at91_mci_softc *sc) { WR4(sc, PDC_PTCR, PDC_PTCR_TXTDIS | PDC_PTCR_RXTDIS); @@ -137,6 +154,48 @@ WR4(sc, PDC_TNCR, 0); } +/* Reset the controller, then restore most of the current state. + * + * This is called after detecting an error. It's also called after stopping a + * multi-block write, to un-wedge the device so that it will handle the NOTBUSY + * signal correctly. See comments in at91_mci_stop_done() for more details. + */ +static void at91_mci_reset(struct at91_mci_softc *sc) +{ + uint32_t mr; + uint32_t sdcr; + uint32_t dtor; + uint32_t imr; + + at91_mci_pdc_disable(sc); + + /* save current state */ + + imr = RD4(sc, MCI_IMR); + mr = RD4(sc, MCI_MR) & 0x7fff; + sdcr = RD4(sc, MCI_SDCR); + dtor = RD4(sc, MCI_DTOR); + + /* reset the controller */ + + WR4(sc, MCI_IDR, 0xffffffff); + WR4(sc, MCI_CR, MCI_CR_MCIDIS | MCI_CR_SWRST); + + /* restore state */ + + WR4(sc, MCI_CR, MCI_CR_MCIEN); + WR4(sc, MCI_MR, mr); + WR4(sc, MCI_SDCR, sdcr); + WR4(sc, MCI_DTOR, dtor); + WR4(sc, MCI_IER, imr); + + /* Make sure sdio interrupts will fire. Not sure why reading + * SR ensures that, but this is in the linux driver. + */ + + RD4(sc, MCI_SR); +} + static void at91_mci_init(device_t dev) { @@ -145,7 +204,7 @@ WR4(sc, MCI_CR, MCI_CR_MCIEN); /* Enable controller */ WR4(sc, MCI_IDR, 0xffffffff); /* Turn off interrupts */ WR4(sc, MCI_DTOR, MCI_DTOR_DTOMUL_1M | 1); - WR4(sc, MCI_MR, 0x834a); // XXX GROSS HACK FROM LINUX + WR4(sc, MCI_MR, 0x834a); // set PDCMODE, PWSDIV=3, CLKDIV=75 #ifndef AT91_MCI_SLOT_B WR4(sc, MCI_SDCR, 0); /* SLOT A, 1 bit bus */ #else @@ -168,7 +227,6 @@ static int at91_mci_probe(device_t dev) { - device_set_desc(dev, "MCI mmc/sd host bridge"); return (0); } @@ -193,24 +251,44 @@ AT91_MCI_LOCK_INIT(sc); - /* - * Allocate DMA tags and maps + at91_mci_fini(dev); + at91_mci_init(dev); + + /* Allocate DMA tags and maps and a physically-contiguous bounce buffer. + * + * The parms in the tag_create call cause the dmamem_alloc call to + * create a single contiguous buffer of BBSIZE bytes aligned to a 4096 + * byte boundary. + * + * Allocate the bounce buffer using DMA_COHERENT which in effect means + * that the pages are mapped as non-cacheable (making all the + * bus_dmamap_sync() calls become fast no-ops) because there's no value + * in caching the data in the swap/bounce buffers (there would just be + * extra overhead in flushing the caches after the data has been + * accessed exactly once). + * + * After allocating the bounce buffer we load the map for it and leave + * it loaded as long as the driver is active. */ - err = bus_dma_tag_create(bus_get_dma_tag(dev), 1, 0, - BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, MAXPHYS, 1, - MAXPHYS, BUS_DMA_ALLOCNOW, NULL, NULL, &sc->dmatag); + + err = bus_dma_tag_create(bus_get_dma_tag(dev), 4096, 0, + BUS_SPACE_MAXADDR_32BIT, BUS_SPACE_MAXADDR, NULL, NULL, + BBSIZE, 1, MAXPHYS, 0, NULL, NULL, &sc->dmatag); if (err != 0) goto out; - err = bus_dmamap_create(sc->dmatag, 0, &sc->map); + err = bus_dmamem_alloc(sc->dmatag, (void **)&sc->bbuf_vaddr, + BUS_DMA_NOWAIT|BUS_DMA_COHERENT, &sc->map); if (err != 0) goto out; - at91_mci_fini(dev); - at91_mci_init(dev); + err = bus_dmamap_load(sc->dmatag, sc->map, sc->bbuf_vaddr, BBSIZE, + at91_mci_getaddr, &sc->bbuf_paddr, BUS_DMA_NOWAIT); + if (err != 0) + goto out; /* - * Activate the interrupt + * Set up to handle interrupts. */ err = bus_setup_intr(dev, sc->irq_res, INTR_TYPE_MISC | INTR_MPSAFE, at91_mci_intr, sc, &sc->intrhand); @@ -230,10 +308,13 @@ if (sc->has_4wire) sc->sc_cap |= CAP_HAS_4WIRE; - sc->host.f_min = at91_master_clock / 512; + /* Our real min freq is master_clock/512, but upper driver layers are + * going to set the min speed during card discovery, and the right speed + * for that is 400khz, so advertise a safe value just under that. + */ sc->host.f_min = 375000; sc->host.f_max = at91_master_clock / 2; - if (sc->host.f_max > 50000000) + if (sc->host.f_max > 50000000) sc->host.f_max = 50000000; /* Limit to 50MHz */ sc->host.host_ocr = MMC_OCR_320_330 | MMC_OCR_330_340; @@ -252,8 +333,15 @@ static int at91_mci_detach(device_t dev) { + struct at91_mci_softc *sc = device_get_softc(dev); + at91_mci_fini(dev); at91_mci_deactivate(dev); + + bus_dmamap_unload(sc->dmatag, sc->map); + bus_dmamem_free(sc->dmatag, sc->bbuf_vaddr, sc->map); + bus_dma_tag_destroy(sc->dmatag); + return (EBUSY); /* XXX */ } @@ -293,7 +381,7 @@ sc->intrhand = 0; bus_generic_detach(sc->dev); if (sc->mem_res) - bus_release_resource(dev, SYS_RES_IOPORT, + bus_release_resource(dev, SYS_RES_MEMORY, rman_get_rid(sc->mem_res), sc->mem_res); sc->mem_res = 0; if (sc->irq_res) @@ -303,14 +391,6 @@ return; } -static void -at91_mci_getaddr(void *arg, bus_dma_segment_t *segs, int nsegs, int error) -{ - if (error != 0) - return; - *(bus_addr_t *)arg = segs[0].ds_addr; -} - static int at91_mci_update_ios(device_t brdev, device_t reqdev) { @@ -322,7 +402,7 @@ sc = device_get_softc(brdev); host = &sc->host; ios = &host->ios; - // bus mode? + if (ios->clock == 0) { WR4(sc, MCI_CR, MCI_CR_MCIDIS); clkdiv = 0; @@ -346,137 +426,176 @@ static void at91_mci_start_cmd(struct at91_mci_softc *sc, struct mmc_command *cmd) { - uint32_t cmdr, ier = 0, mr; + uint32_t cmdr, mr; uint32_t *src, *dst; int i; struct mmc_data *data; - void *vaddr; - bus_addr_t paddr; sc->curcmd = cmd; data = cmd->data; - cmdr = cmd->opcode; /* XXX Upper layers don't always set this */ cmd->mrq = sc->req; + /* Begin setting up command register. */ + + cmdr = cmd->opcode; + + if (sc->host.ios.bus_mode == opendrain) + cmdr |= MCI_CMDR_OPDCMD; + + /* Set up response handling. Allow max timeout for responses. */ + if (MMC_RSP(cmd->flags) == MMC_RSP_NONE) cmdr |= MCI_CMDR_RSPTYP_NO; else { - /* Allow big timeout for responses */ cmdr |= MCI_CMDR_MAXLAT; if (cmd->flags & MMC_RSP_136) cmdr |= MCI_CMDR_RSPTYP_136; else cmdr |= MCI_CMDR_RSPTYP_48; } - if (cmd->opcode == MMC_STOP_TRANSMISSION) - cmdr |= MCI_CMDR_TRCMD_STOP; - if (sc->host.ios.bus_mode == opendrain) - cmdr |= MCI_CMDR_OPDCMD; - if (!data) { - // The no data case is fairly simple + + /* If there is no data transfer, just set up the right interrupt mask + * and start the command. + * + * The interrupt mask needs to be CMDRDY plus all non-data-transfer + * errors. It's important to leave the transfer-related errors out, to + * avoid spurious timeout or crc errors on a STOP command following a + * multiblock read. When a multiblock read is in progress, sending a + * STOP in the middle of a block occasionally triggers such errors, but + * we're totally disinterested in them because we've already gotten all + * the data we wanted without error before sending the STOP command. + */ + + if (data == NULL) { + uint32_t ier = MCI_SR_CMDRDY | + MCI_SR_RTOE | MCI_SR_RENDE | + MCI_SR_RCRCE | MCI_SR_RDIRE | MCI_SR_RINDE; + at91_mci_pdc_disable(sc); -// printf("CMDR %x ARGR %x\n", cmdr, cmd->arg); + + if (cmd->opcode == MMC_STOP_TRANSMISSION) + cmdr |= MCI_CMDR_TRCMD_STOP; + + /* Ignore response CRC on CMD2 and ACMD41, per standard. */ + + if (cmd->opcode == MMC_SEND_OP_COND || + cmd->opcode == ACMD_SD_SEND_OP_COND) + ier &= ~MCI_SR_RCRCE; + + if (mci_debug) + printf("CMDR %x (opcode %d) ARGR %x no data\n", + cmdr, cmd->opcode, cmd->arg); + WR4(sc, MCI_ARGR, cmd->arg); WR4(sc, MCI_CMDR, cmdr); - WR4(sc, MCI_IER, MCI_SR_ERROR | MCI_SR_CMDRDY); + WR4(sc, MCI_IER, ier); return; } + + /* There is data, set up the transfer-related parts of the command. */ + if (data->flags & MMC_DATA_READ) cmdr |= MCI_CMDR_TRDIR; + if (data->flags & (MMC_DATA_READ | MMC_DATA_WRITE)) cmdr |= MCI_CMDR_TRCMD_START; + if (data->flags & MMC_DATA_STREAM) cmdr |= MCI_CMDR_TRTYP_STREAM; - if (data->flags & MMC_DATA_MULTI) + else if (data->flags & MMC_DATA_MULTI) { cmdr |= MCI_CMDR_TRTYP_MULTIPLE; - // Set block size and turn on PDC mode for dma xfer and disable - // PDC until we're ready. - mr = RD4(sc, MCI_MR) & ~MCI_MR_BLKLEN; - WR4(sc, MCI_MR, mr | (data->len << 16) | MCI_MR_PDCMODE); - WR4(sc, PDC_PTCR, PDC_PTCR_RXTDIS | PDC_PTCR_TXTDIS); - if (cmdr & MCI_CMDR_TRCMD_START) { - if (cmdr & MCI_CMDR_TRDIR) - vaddr = cmd->data->data; - else { - /* Use bounce buffer even if we don't need - * byteswap, since buffer may straddle a page - * boundry, and we don't handle multi-segment - * transfers in hardware. - * (page issues seen from 'bsdlabel -w' which - * uses raw geom access to the volume). - * Greg Ansley (gja (at) ansley.com) - */ - vaddr = sc->bounce_buffer; - src = (uint32_t *)cmd->data->data; - dst = (uint32_t *)vaddr; - if (sc->sc_cap & CAP_NEEDS_BYTESWAP) { - for (i = 0; i < data->len / 4; i++) - dst[i] = bswap32(src[i]); - } else - memcpy(dst, src, data->len); - } - data->xfer_len = 0; - if (bus_dmamap_load(sc->dmatag, sc->map, vaddr, data->len, - at91_mci_getaddr, &paddr, 0) != 0) { - cmd->error = MMC_ERR_NO_MEMORY; - sc->req = NULL; - sc->curcmd = NULL; - cmd->mrq->done(cmd->mrq); - return; - } - sc->mapped++; - if (cmdr & MCI_CMDR_TRDIR) { + sc->flags |= (data->flags & MMC_DATA_READ) ? + CMD_MULTIREAD : CMD_MULTIWRITE; + } + + /* Disable PDC until we're ready. + * + * Set block size and turn on PDC mode for dma xfer. + * Note that the block size is the smaller of the amount of data to be + * transferred, or 512 bytes. The 512 size is fixed by the standard; + * smaller blocks are possible, but never larger. + */ + + WR4(sc, PDC_PTCR, PDC_PTCR_RXTDIS | PDC_PTCR_TXTDIS); + + mr = RD4(sc,MCI_MR) & ~MCI_MR_BLKLEN; + mr |= min(data->len, 512) << 16; + WR4(sc, MCI_MR, mr | MCI_MR_PDCMODE); + + /* Set up DMA. + * + * Use a bounce buffer even if we don't need to byteswap, because doing + * multi-block IO with a single large DMA buffer is way fast (compared + * to single-block IO), even after incurring the overhead of also + * copying from/to the caller's buffers (which may be in non-contiguous + * physical pages). + * + * In an ideal non-byteswap world we could create a dma tag that allows + * for discontiguous segments and do the IO directly from/to the + * caller's buffer(s), using ENDRX/ENDTX interrupts to chain the + * discontiguous buffers through the PDC. Someday. + * + * XXX what about stream transfers? + */ + + if (data->flags & (MMC_DATA_READ | MMC_DATA_WRITE)) { + if (data->flags & MMC_DATA_READ) { bus_dmamap_sync(sc->dmatag, sc->map, BUS_DMASYNC_PREREAD); - WR4(sc, PDC_RPR, paddr); + WR4(sc, PDC_RPR, sc->bbuf_paddr); WR4(sc, PDC_RCR, data->len / 4); - ier = MCI_SR_ENDRX; + WR4(sc, PDC_PTCR, PDC_PTCR_RXTEN); } else { + if (sc->sc_cap & CAP_NEEDS_BYTESWAP) { + src = (uint32_t *)data->data; + dst = (uint32_t *)sc->bbuf_vaddr; + for (i = 0; i < data->len / 4; i++) + dst[i] = bswap32(src[i]); + } else { + bcopy(data->data, sc->bbuf_vaddr, data->len); + } bus_dmamap_sync(sc->dmatag, sc->map, BUS_DMASYNC_PREWRITE); - WR4(sc, PDC_TPR, paddr); + WR4(sc, PDC_TPR, sc->bbuf_paddr); WR4(sc, PDC_TCR, data->len / 4); - ier = MCI_SR_TXBUFE; + /* do not enable PDC xfer until CMDRDY asserted */ } + data->xfer_len = 0; /* XXX what's this? appears to be unused. */ } -// printf("CMDR %x ARGR %x with data\n", cmdr, cmd->arg); + + if (mci_debug) + printf("CMDR %x (opcode %d) ARGR %x with data\n", cmdr, cmd->opcode, cmd->arg); + WR4(sc, MCI_ARGR, cmd->arg); - if (cmdr & MCI_CMDR_TRCMD_START) { - if (cmdr & MCI_CMDR_TRDIR) { - 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); - } - } - WR4(sc, MCI_IER, MCI_SR_ERROR | ier); + WR4(sc, MCI_CMDR, cmdr); + WR4(sc, MCI_IER, MCI_SR_ERROR | MCI_SR_CMDRDY); } static void -at91_mci_start(struct at91_mci_softc *sc) +at91_mci_next_operation(struct at91_mci_softc *sc) { struct mmc_request *req; req = sc->req; if (req == NULL) return; - // assert locked - if (!(sc->flags & CMD_STARTED)) { - sc->flags |= CMD_STARTED; -// printf("Starting CMD\n"); - at91_mci_start_cmd(sc, req->cmd); - return; - } - if (!(sc->flags & STOP_STARTED) && req->stop) { -// printf("Starting Stop\n"); - sc->flags |= STOP_STARTED; - at91_mci_start_cmd(sc, req->stop); - return; + + if (!(sc->flags & PENDING_ERROR)) { + if (sc->flags & PENDING_CMD) { + sc->flags &= ~PENDING_CMD; + at91_mci_start_cmd(sc, req->cmd); + return; + } else if (sc->flags & PENDING_STOP) { + sc->flags &= ~PENDING_STOP; + at91_mci_start_cmd(sc, req->stop); + return; + } } - /* We must be done -- bad idea to do this while locked? */ + + WR4(sc, MCI_IDR, 0xffffffff); sc->req = NULL; sc->curcmd = NULL; + //printf("req done\n"); req->done(req); } @@ -486,16 +605,16 @@ struct at91_mci_softc *sc = device_get_softc(brdev); AT91_MCI_LOCK(sc); - // XXX do we want to be able to queue up multiple commands? - // XXX sounds like a good idea, but all protocols are sync, so - // XXX maybe the idea is naive... if (sc->req != NULL) { AT91_MCI_UNLOCK(sc); return (EBUSY); } + //printf("new req\n"); sc->req = req; - sc->flags = 0; - at91_mci_start(sc); + sc->flags = PENDING_CMD; + if (sc->req->stop) + sc->flags |= PENDING_STOP; + at91_mci_next_operation(sc); AT91_MCI_UNLOCK(sc); return (0); } @@ -535,118 +654,299 @@ static void at91_mci_read_done(struct at91_mci_softc *sc) { - uint32_t *walker; - struct mmc_command *cmd; - int i, len; + struct mmc_command *cmd = sc->curcmd; + + /* We arrive here when the entire DMA transfer for a read is done, + * whether it's a single or multi-block read. Either way the next thing + * to do is move on to the next operation. For single-block that'll + * mean returning the now-completed request, for multi-block it will + * invoke the stop command sequence. + */ + + WR4(sc, PDC_PTCR, PDC_PTCR_RXTDIS | PDC_PTCR_TXTDIS); - cmd = sc->curcmd; bus_dmamap_sync(sc->dmatag, sc->map, BUS_DMASYNC_POSTREAD); - bus_dmamap_unload(sc->dmatag, sc->map); - sc->mapped--; + if (sc->sc_cap & CAP_NEEDS_BYTESWAP) { - walker = (uint32_t *)cmd->data->data; - len = cmd->data->len / 4; + int i; + uint32_t *src = (uint32_t *)sc->bbuf_vaddr; + uint32_t *dst = (uint32_t *)cmd->data->data; + int len = cmd->data->len / 4; for (i = 0; i < len; i++) - walker[i] = bswap32(walker[i]); + dst[i] = bswap32(src[i]); + } else { + bcopy(sc->bbuf_vaddr, cmd->data->data, cmd->data->len); } - // Finish up the sequence... - WR4(sc, MCI_IDR, MCI_SR_ENDRX); - WR4(sc, MCI_IER, MCI_SR_RXBUFF); - WR4(sc, PDC_PTCR, PDC_PTCR_RXTDIS | PDC_PTCR_TXTDIS); + + cmd->error = MMC_ERR_NONE; + at91_mci_next_operation(sc); } static void -at91_mci_xmit_done(struct at91_mci_softc *sc) +at91_mci_write_done(struct at91_mci_softc *sc, uint32_t sr) { - // Finish up the sequence... + struct mmc_command *cmd = sc->curcmd; + + /* We arrive here when the entire DMA transfer for a write is done, + * whether it's a single or multi-block write. If it's multi-block we + * have to immediately move on to the next operation which is to send + * the stop command. If it's a single-block transfer we need to wait + * for NOTBUSY, but if that's already asserted we can avoid another + * interrupt and just move on to completing the request right away. + */ + WR4(sc, PDC_PTCR, PDC_PTCR_RXTDIS | PDC_PTCR_TXTDIS); - WR4(sc, MCI_IDR, MCI_SR_TXBUFE); - WR4(sc, MCI_IER, MCI_SR_NOTBUSY); + bus_dmamap_sync(sc->dmatag, sc->map, BUS_DMASYNC_POSTWRITE); - bus_dmamap_unload(sc->dmatag, sc->map); - sc->mapped--; + + if ((cmd->data->flags & MMC_DATA_MULTI) || (sr & MCI_SR_NOTBUSY)) { + cmd->error = MMC_ERR_NONE; + at91_mci_next_operation(sc); + } else { + WR4(sc, MCI_IER, MCI_SR_ERROR | MCI_SR_NOTBUSY); + } +} + +static void +at91_mci_notbusy(struct at91_mci_softc *sc) +{ + struct mmc_command *cmd = sc->curcmd; + + /* We arrive here by either completion of a single-block write, or + * completion of the stop command that ended a multi-block write (and, I + * suppose, after a card-select or erase, but I haven't tested those). + * Anyway, we're done and it's time to move on to the next command. + */ + + cmd->error = MMC_ERR_NONE; + at91_mci_next_operation(sc); +} + +static void +at91_mci_stop_done(struct at91_mci_softc *sc, uint32_t sr) +{ + struct mmc_command *cmd = sc->curcmd; + + /* We arrive here after receiving CMDRDY for a MMC_STOP_TRANSMISSION + * command. Depending on the operation being stopped, we may have to do + * some unusual things to work around hardware bugs. + */ + + /* This is known to be true of at91rm9200 hardware; it may or may not + * apply to more recent chips: + * + * After stopping a multi-block write, the NOTBUSY bit in MCI_SR does + * not properly reflect the actual busy state of the card as signaled on + * the DAT0 line; it always claims the card is not-busy. If we believe + * that and let operations continue, following commands will fail with + * response timeouts (except of course MMC_SEND_STATUS -- it indicates + * the card is busy in the PRG state, which was the smoking gun that + * showed MCI_SR NOTBUSY was not tracking DAT0 correctly). + * + * The atmel docs are emphatic: "This flag [NOTBUSY] must be used only + * for Write Operations." I guess technically since we sent a stop it's + * not a write operation anymore. But then just what did they think it + * meant for the stop command to have "...an optional busy signal + * transmitted on the data line" according to the SD spec? + * + * I tried a variety of things to un-wedge the MCI and get the status + * register to reflect NOTBUSY correctly again, but the only thing that + * worked was a full device reset. It feels like an awfully big hammer, + * but doing a full reset after every multiblock write is still faster + * than doing single-block IO (by almost two orders of magnitude: + * 20KB/sec improves to about 1.8MB/sec best case). + * + * After doing the reset, wait for a NOTBUSY interrupt before continuing + * with the next operation. + */ + + if (sc->flags & CMD_MULTIWRITE) { + at91_mci_reset(sc); + WR4(sc, MCI_IER, MCI_SR_ERROR | MCI_SR_NOTBUSY); + return; + } + + /* This is known to be true of at91rm9200 hardware; it may or may not + * apply to more recent chips: + * + * After stopping a multi-block read, loop to read and discard any data + * that coasts in after we sent the stop command. The docs don't say + * anything about it, but empirical testing shows that 1-3 additional + * words of data get buffered up in some unmentioned internal fifo and + * if we don't read and discard them here they end up on the front of + * the next read DMA transfer we do. + */ + + if (sc->flags & CMD_MULTIREAD) { + uint32_t sr; + int count = 0; + do { + sr = RD4(sc, MCI_SR); + if (sr & MCI_SR_RXRDY) { + RD4(sc, MCI_RDR); + ++count; + } + } while (sr & MCI_SR_RXRDY); +// if (count != 0) +// printf("Had to soak up %d words after read\n", count); + } + + cmd->error = MMC_ERR_NONE; + at91_mci_next_operation(sc); + +} + +static void +at91_mci_cmdrdy(struct at91_mci_softc *sc, uint32_t sr) +{ + struct mmc_command *cmd = sc->curcmd; + int i; + + if (cmd == NULL) + return; + + /* We get here at the end of EVERY command. We retrieve the command + * response (if any) then decide what to do next based on the command. + */ + + if (cmd->flags & MMC_RSP_PRESENT) { + for (i = 0; i < ((cmd->flags & MMC_RSP_136) ? 4 : 1); i++) { + cmd->resp[i] = RD4(sc, MCI_RSPR + i * 4); + if (mci_debug) + printf("RSPR[%d] = %x sr=%x\n", i, cmd->resp[i], sr); + } + } + + /* If this was a stop command, go handle the various special + * conditions (read: bugs) that have to be dealt with following a stop. + */ + + if (cmd->opcode == MMC_STOP_TRANSMISSION) { + at91_mci_stop_done(sc, sr); + return; + } + + /* If this command can continue to assert BUSY beyond the response then + * we need to wait for NOTBUSY before the command is really done. + * + * Note that this may not work properly on the at91rm9200. It certainly + * doesn't work for the STOP command that follows a multi-block write, + * so post-stop CMDRDY is handled separately; see the special handling + * in at91_mci_stop_done(). + * + * Beside STOP, there are other R1B-type commands that use the busy + * signal after CMDRDY: CMD7 (card select), CMD28-29 (write protect), + * CMD38 (erase). I haven't tested any of them, but I rather expect + * them all to have the same sort of problem with MCI_SR not actually + * reflecting the state of the DAT0-line busy indicator. So this code + * may need to grow some sort of special handling for them too. (This + * just in: CMD7 isn't a problem right now because dev/mmc.c incorrectly + * sets the response flags to R1 rather than R1B.) + */ + + if ((cmd->flags & MMC_RSP_BUSY)) { + WR4(sc, MCI_IER, MCI_SR_ERROR | MCI_SR_NOTBUSY); + return; + } + + /* If there is a data transfer with this command, then... + * - If it's a read, we need to wait for ENDRX. + * - If it's a write, now is the time to enable the PDC and we need to + * wait for BLKE. + */ + + if (cmd->data) { + uint32_t ier; + if (cmd->data->flags & MMC_DATA_READ) { + ier = MCI_SR_ENDRX; + } else { + ier = MCI_SR_BLKE; + WR4(sc, PDC_PTCR, PDC_PTCR_TXTEN); + } + WR4(sc, MCI_IER, MCI_SR_ERROR | ier); + return; + } + + /* If we made it to here, we don't need to wait for anything more for + * the current command, move on to the next command (will complete the + * request if there is no next command). + */ + + cmd->error = MMC_ERR_NONE; + at91_mci_next_operation(sc); } static void at91_mci_intr(void *arg) { struct at91_mci_softc *sc = (struct at91_mci_softc*)arg; - uint32_t sr; - int i, done = 0; - struct mmc_command *cmd; + struct mmc_command *cmd = sc->curcmd; + uint32_t sr, isr; AT91_MCI_LOCK(sc); - sr = RD4(sc, MCI_SR) & RD4(sc, MCI_IMR); -// printf("i 0x%x\n", sr); - cmd = sc->curcmd; - if (sr & MCI_SR_ERROR) { - // Ignore CRC errors on CMD2 and ACMD47, per relevant standards - if ((sr & MCI_SR_RCRCE) && (cmd->opcode == MMC_SEND_OP_COND || - cmd->opcode == ACMD_SD_SEND_OP_COND)) - cmd->error = MMC_ERR_NONE; - else if (sr & (MCI_SR_RTOE | MCI_SR_DTOE)) + + sr = RD4(sc, MCI_SR); + isr = sr & RD4(sc, MCI_IMR); + + if (mci_debug) + printf("i 0x%x sr 0x%x\n", isr, sr); + + /* All interrupts are one-shot; disable it now. + * The next operation will re-enable whatever interrupts it wants. + */ + + WR4(sc, MCI_IDR, isr); + + if (isr & MCI_SR_ERROR) { + if (isr & (MCI_SR_RTOE | MCI_SR_DTOE)) cmd->error = MMC_ERR_TIMEOUT; - else if (sr & (MCI_SR_RCRCE | MCI_SR_DCRCE)) + else if (isr & (MCI_SR_RCRCE | MCI_SR_DCRCE)) cmd->error = MMC_ERR_BADCRC; - else if (sr & (MCI_SR_OVRE | MCI_SR_UNRE)) + else if (isr & (MCI_SR_OVRE | MCI_SR_UNRE)) cmd->error = MMC_ERR_FIFO; else cmd->error = MMC_ERR_FAILED; - done = 1; - if (sc->mapped && cmd->error) { - bus_dmamap_unload(sc->dmatag, sc->map); - sc->mapped--; - } + device_printf(sc->dev, + "IO error; status MCI_SR = 0x%x cmd opcode = %d\n", + sr, cmd->opcode); + sc->flags |= PENDING_ERROR; + at91_mci_reset(sc); + at91_mci_next_operation(sc); } else { - if (sr & MCI_SR_TXBUFE) { + if (isr & MCI_SR_TXBUFE) { // printf("TXBUFE\n"); - at91_mci_xmit_done(sc); } - if (sr & MCI_SR_RXBUFF) { + if (isr & MCI_SR_RXBUFF) { // printf("RXBUFF\n"); - WR4(sc, MCI_IDR, MCI_SR_RXBUFF); - WR4(sc, MCI_IER, MCI_SR_CMDRDY); } - if (sr & MCI_SR_ENDTX) { + if (isr & MCI_SR_ENDTX) { // printf("ENDTX\n"); } - if (sr & MCI_SR_ENDRX) { + if (isr & MCI_SR_ENDRX) { // printf("ENDRX\n"); at91_mci_read_done(sc); } - if (sr & MCI_SR_NOTBUSY) { + if (isr & MCI_SR_NOTBUSY) { // printf("NOTBUSY\n"); - WR4(sc, MCI_IDR, MCI_SR_NOTBUSY); - WR4(sc, MCI_IER, MCI_SR_CMDRDY); + at91_mci_notbusy(sc); } - if (sr & MCI_SR_DTIP) { + if (isr & MCI_SR_DTIP) { // printf("Data transfer in progress\n"); } - if (sr & MCI_SR_BLKE) { + if (isr & MCI_SR_BLKE) { // printf("Block transfer end\n"); + at91_mci_write_done(sc, sr); } - if (sr & MCI_SR_TXRDY) { + if (isr & MCI_SR_TXRDY) { // printf("Ready to transmit\n"); } - if (sr & MCI_SR_RXRDY) { + if (isr & MCI_SR_RXRDY) { // printf("Ready to receive\n"); } - if (sr & MCI_SR_CMDRDY) { + if (isr & MCI_SR_CMDRDY) { // printf("Command ready\n"); - done = 1; - cmd->error = MMC_ERR_NONE; - } - } - if (done) { - WR4(sc, MCI_IDR, 0xffffffff); - if (cmd != NULL && (cmd->flags & MMC_RSP_PRESENT)) { - for (i = 0; i < ((cmd->flags & MMC_RSP_136) ? 4 : 1); - i++) { - cmd->resp[i] = RD4(sc, MCI_RSPR + i * 4); -// printf("RSPR[%d] = %x\n", i, cmd->resp[i]); - } + at91_mci_cmdrdy(sc, sr); } - at91_mci_start(sc); } AT91_MCI_UNLOCK(sc); } @@ -703,7 +1003,7 @@ *(int *)result = sc->host.caps; break; case MMCBR_IVAR_MAX_DATA: - *(int *)result = 1; + *(int *)result = AT91_MCI_MAX_BLOCKS; break; } return (0); --- patch-arm-at91_mci-for-multiblock ends here --- >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 00:10:09 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2840F1065670 for ; Thu, 3 Mar 2011 00:10:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F05B78FC14 for ; Thu, 3 Mar 2011 00:10:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p230A8lx093350 for ; Thu, 3 Mar 2011 00:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p230A89l093346; Thu, 3 Mar 2011 00:10:08 GMT (envelope-from gnats) Date: Thu, 3 Mar 2011 00:10:08 GMT Message-Id: <201103030010.p230A89l093346@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Bernd Walter Cc: Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bernd Walter List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 00:10:09 -0000 The following reply was made to PR arm/155214; it has been noted by GNATS. From: Bernd Walter To: Ian Lepore Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards Date: Thu, 3 Mar 2011 00:52:51 +0100 On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote: > > >Number: 155214 > >Category: arm > >Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards > >Confidential: no > >Severity: serious > >Priority: medium > >Responsible: freebsd-arm > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Mar 02 22:10:10 UTC 2011 > >Closed-Date: > >Last-Modified: > >Originator: Ian Lepore > >Release: FreeBSD 8.2-RC3 arm > >Organization: > none > >Environment: > FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB arm > > Included patch is against -current even though the problem was first seen on > 8.2-RC3 > > The problem was seen on AT91RM9200 hardware, but presumably also affects the > SAM9 series which uses the same driver code. > > >Description: > With the latest generation of large-capacity SD cards, write speeds as low as > 20 kbytes/sec are seen. These modern cards have erase-block sizes as large as > 8192K (compared to 32K typical on previous generations). The at91_mci driver > does only single-sector IO; apparently this requires the SD card to internally > perform an expensive read-erase-modify-write cycle for each 512 byte block > written to the card. The complete details of this problem are completely known. However the RM9200 has many hardware problems to be worked around and so far noone actually did. Your patch is quite large, so I would like to ask you explicitly: Did you test your patch with an AT91RM9200 system? You did enable multisector support for reading and (more important) for writing? But you didn't activate 4bit mode? With 4bit mode there is no hardware bug, but when the driver was written is was just done in a lazy way because activating 4bit on SD cards require special handling - in the meantime the SD layer itself was extracted and has 4bit support, but the at91_mci driver was never updated to use that. PS: I'm very pleased to see your work since SD write speed was a major show stopper for some applications -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 00:26:23 2011 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 CD7B51065672 for ; Thu, 3 Mar 2011 00:26:23 +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 7E1768FC15 for ; Thu, 3 Mar 2011 00:26:23 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p230JuY3060262 for ; Wed, 2 Mar 2011 17:19:56 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D6EDEA5.2030200@bsdimp.com> Date: Wed, 02 Mar 2011 17:19:49 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <201103030010.p230A89l093346@freefall.freebsd.org> In-Reply-To: <201103030010.p230A89l093346@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards 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, 03 Mar 2011 00:26:24 -0000 On 03/02/2011 17:10, Bernd Walter wrote: > The following reply was made to PR arm/155214; it has been noted by GNATS. > > From: Bernd Walter > To: Ian Lepore > Cc: FreeBSD-gnats-submit@freebsd.org > Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards > Date: Thu, 3 Mar 2011 00:52:51 +0100 > > On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote: > > > > >Number: 155214 > > >Category: arm > > >Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards > > >Confidential: no > > >Severity: serious > > >Priority: medium > > >Responsible: freebsd-arm > > >State: open > > >Quarter: > > >Keywords: > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Wed Mar 02 22:10:10 UTC 2011 > > >Closed-Date: > > >Last-Modified: > > >Originator: Ian Lepore > > >Release: FreeBSD 8.2-RC3 arm > > >Organization: > > none > > >Environment: > > FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB arm > > > > Included patch is against -current even though the problem was first seen on > > 8.2-RC3 > > > > The problem was seen on AT91RM9200 hardware, but presumably also affects the > > SAM9 series which uses the same driver code. > > > > >Description: > > With the latest generation of large-capacity SD cards, write speeds as low as > > 20 kbytes/sec are seen. These modern cards have erase-block sizes as large as > > 8192K (compared to 32K typical on previous generations). The at91_mci driver > > does only single-sector IO; apparently this requires the SD card to internally > > perform an expensive read-erase-modify-write cycle for each 512 byte block > > written to the card. > > The complete details of this problem are completely known. > However the RM9200 has many hardware problems to be worked around and > so far noone actually did. > Your patch is quite large, so I would like to ask you explicitly: > Did you test your patch with an AT91RM9200 system? I believe their only playform is AT91RM9200 based... > You did enable multisector support for reading and (more important) for > writing? > But you didn't activate 4bit mode? > With 4bit mode there is no hardware bug, but when the driver was written > is was just done in a lazy way because activating 4bit on SD cards require > special handling - in the meantime the SD layer itself was extracted and > has 4bit support, but the at91_mci driver was never updated to use that. Actually, I was never able to make the 4-bit mode work because our primary hardware platfom had only 1 bit and the eval boards that I bought that had 4-bits wired up would never work completely reliably. Since I was never able to test it reliably, I never completed the partial implementation I did. > PS: I'm very pleased to see your work since SD write speed was a > major show stopper for some applications Agreed. This stuff is very cool. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 00:40:12 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE662106566B for ; Thu, 3 Mar 2011 00:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DB9678FC17 for ; Thu, 3 Mar 2011 00:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p230eBac023560 for ; Thu, 3 Mar 2011 00:40:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p230eBIt023558; Thu, 3 Mar 2011 00:40:11 GMT (envelope-from gnats) Date: Thu, 3 Mar 2011 00:40:11 GMT Message-Id: <201103030040.p230eBIt023558@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Ian Lepore Cc: Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 00:40:12 -0000 The following reply was made to PR arm/155214; it has been noted by GNATS. From: Ian Lepore To: ticso@cicely.de Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards Date: Wed, 02 Mar 2011 17:21:09 -0700 On Thu, 2011-03-03 at 00:52 +0100, Bernd Walter wrote: > On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote: > > > > >Number: 155214 > > >Category: arm > > >Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards > > >Confidential: no > > >Severity: serious > > >Priority: medium > > >Responsible: freebsd-arm > > >State: open > > >Quarter: > > >Keywords: > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Wed Mar 02 22:10:10 UTC 2011 > > >Closed-Date: > > >Last-Modified: > > >Originator: Ian Lepore > > >Release: FreeBSD 8.2-RC3 arm > > >Organization: > > none > > >Environment: > > FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB arm > > > > Included patch is against -current even though the problem was first seen on > > 8.2-RC3 > > > > The problem was seen on AT91RM9200 hardware, but presumably also affects the > > SAM9 series which uses the same driver code. > > > > >Description: > > With the latest generation of large-capacity SD cards, write speeds as low as > > 20 kbytes/sec are seen. These modern cards have erase-block sizes as large as > > 8192K (compared to 32K typical on previous generations). The at91_mci driver > > does only single-sector IO; apparently this requires the SD card to internally > > perform an expensive read-erase-modify-write cycle for each 512 byte block > > written to the card. > > The complete details of this problem are completely known. > However the RM9200 has many hardware problems to be worked around and > so far noone actually did. > Your patch is quite large, so I would like to ask you explicitly: > Did you test your patch with an AT91RM9200 system? > You did enable multisector support for reading and (more important) for > writing? > But you didn't activate 4bit mode? > With 4bit mode there is no hardware bug, but when the driver was written > is was just done in a lazy way because activating 4bit on SD cards require > special handling - in the meantime the SD layer itself was extracted and > has 4bit support, but the at91_mci driver was never updated to use that. > > PS: I'm very pleased to see your work since SD write speed was a > major show stopper for some applications > Yes, the patch is large, partly because I included comments about the hardware problems I found and how the code works around them (and also to help the next person understand the flow). My changes support multi-sector IO for both reads and writes. The company I work for uses the AT91RM9200 on custom-designed boards in 8 products, all with substantially similar board designs. So far we've tested these changes on 4 of them, with no problems found. I have not tested with 4-bit enabled; I wasn't aware (but in retrospect I probably should have assumed) that the hardware bugs are different with 4-bit enabled. I'm not even sure our hardware design carries all 4 lines to the card; I'll look at the schematics and if they're connected I'll see about testing that mode. (And if they're not I'll see about having our designers wire up all 4 lines on future designs.) I also haven't tested with the SAM9-series, because I don't have that hardware available. (I hope to convince our hardware designers to migrate us to SAM9 this year.) From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 01:24:42 2011 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 E7DED106566B for ; Thu, 3 Mar 2011 01:24:42 +0000 (UTC) (envelope-from gja@ansley.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8348FC1A for ; Thu, 3 Mar 2011 01:24:42 +0000 (UTC) Received: by ywf9 with SMTP id 9so212870ywf.13 for ; Wed, 02 Mar 2011 17:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ansley.com; s=google; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GXTF84SU1fLce0xDBwEAFErIBNsLzzpEZNdfZezp7ko=; b=jszsdFHqk4JkJjFKEgV/5xstr5qzcHapaClG/7K79uy8TYzMxOWhC+fn57W26l1vz9 2hImdOLvjz5A9T10B2NsdwzXbQxJepy9nWtoD3ARBh7vBVleXB4gmI50GQc64RbwXqRs CggM/KCzkTMVuAKxm/dj02Ip7EW/Uj9QS2xQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=ansley.com; s=google; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HP4IkPWUflvh+G9D48LgCooe+6QvllUcI0he4BNHiduLI6McCNfizCxYFBPhoM797C YVpJD0nSsVXQm6M5VXwGLwHSklsOKltU3Czhap/csQLbnr1gHxHaOboxUbDoDQJLgX2I +mRHFJvb4M732js7kIYHO9gMNQ5oWmwCejZi8= Received: by 10.236.108.178 with SMTP id q38mr599224yhg.81.1299113798854; Wed, 02 Mar 2011 16:56:38 -0800 (PST) Received: from gregmbp.internal.ansley.com (99-135-104-139.lightspeed.tukrga.sbcglobal.net [99.135.104.139]) by mx.google.com with ESMTPS id f31sm383387yhc.13.2011.03.02.16.56.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2011 16:56:38 -0800 (PST) Sender: Greg Ansley Message-ID: <4D6EE744.5050100@ansley.com> Date: Wed, 02 Mar 2011 19:56:36 -0500 From: Greg Ansley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <201103030040.p230eBIt023558@freefall.freebsd.org> In-Reply-To: <201103030040.p230eBIt023558@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards 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, 03 Mar 2011 01:24:43 -0000 On 3/2/11 7:40 PM, Ian Lepore wrote: > The following reply was made to PR arm/155214; it has been noted by GNATS. > > From: Ian Lepore > To: ticso@cicely.de > Cc: FreeBSD-gnats-submit@freebsd.org > Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern > large SD cards > Date: Wed, 02 Mar 2011 17:21:09 -0700 > > On Thu, 2011-03-03 at 00:52 +0100, Bernd Walter wrote: > > On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote: > > > > > > >Number: 155214 > > > >Category: arm > > > >Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards > > > >Confidential: no > > > >Severity: serious > > > >Priority: medium > > > >Responsible: freebsd-arm > > > >State: open > > > >Quarter: > > > >Keywords: > > > >Date-Required: > > > >Class: sw-bug > > > >Submitter-Id: current-users > > > >Arrival-Date: Wed Mar 02 22:10:10 UTC 2011 > > > >Closed-Date: > > > >Last-Modified: > > > >Originator: Ian Lepore > > > >Release: FreeBSD 8.2-RC3 arm > > > >Organization: > > > none > > > >Environment: > > > FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB arm > > > > > > Included patch is against -current even though the problem was first seen on > > > 8.2-RC3 > > > > > > The problem was seen on AT91RM9200 hardware, but presumably also affects the > > > SAM9 series which uses the same driver code. > > > > > > >Description: > > > With the latest generation of large-capacity SD cards, write speeds as low as > > > 20 kbytes/sec are seen. These modern cards have erase-block sizes as large as > > > 8192K (compared to 32K typical on previous generations). The at91_mci driver > > > does only single-sector IO; apparently this requires the SD card to internally > > > perform an expensive read-erase-modify-write cycle for each 512 byte block > > > written to the card. > > > > The complete details of this problem are completely known. > > However the RM9200 has many hardware problems to be worked around and > > so far noone actually did. > > Your patch is quite large, so I would like to ask you explicitly: > > Did you test your patch with an AT91RM9200 system? > > You did enable multisector support for reading and (more important) for > > writing? > > But you didn't activate 4bit mode? > > With 4bit mode there is no hardware bug, but when the driver was written > > is was just done in a lazy way because activating 4bit on SD cards require > > special handling - in the meantime the SD layer itself was extracted and > > has 4bit support, but the at91_mci driver was never updated to use that. > > > > PS: I'm very pleased to see your work since SD write speed was a > > major show stopper for some applications > > > > Yes, the patch is large, partly because I included comments about the > hardware problems I found and how the code works around them (and also > to help the next person understand the flow). > > My changes support multi-sector IO for both reads and writes. > > The company I work for uses the AT91RM9200 on custom-designed boards in > 8 products, all with substantially similar board designs. So far we've > tested these changes on 4 of them, with no problems found. > > I have not tested with 4-bit enabled; I wasn't aware (but in retrospect > I probably should have assumed) that the hardware bugs are different > with 4-bit enabled. I'm not even sure our hardware design carries all 4 > lines to the card; I'll look at the schematics and if they're connected > I'll see about testing that mode. (And if they're not I'll see about > having our designers wire up all 4 lines on future designs.) > > I also haven't tested with the SAM9-series, because I don't have that > hardware available. (I hope to convince our hardware designers to > migrate us to SAM9 this year.) > With the current code (prepatch) 4bit mode is known to work at least on the SAM9G20 with kernel option AT91_MCI_HAS_4WIRE. I'll be working on the SAM9G20 in the next few days and I can test the patch on both a RM9200 (1 bit only) and on a couple of SAM9G20 designs with 4bit hardware. Greg From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 03:07:29 2011 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 C2696106564A for ; Thu, 3 Mar 2011 03:07:29 +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 4E0AE8FC15 for ; Thu, 3 Mar 2011 03:07:28 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p232oZb7071079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2011 03:50:35 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p232oWYK094151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2011 03:50:32 +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 p232oVSx026439; Thu, 3 Mar 2011 03:50:31 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p232oVxr026438; Thu, 3 Mar 2011 03:50:31 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Mar 2011 03:50:31 +0100 From: Bernd Walter To: Greg Ansley Message-ID: <20110303025031.GD86812@cicely7.cicely.de> References: <201103030040.p230eBIt023558@freefall.freebsd.org> <4D6EE744.5050100@ansley.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6EE744.5050100@ansley.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards 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, 03 Mar 2011 03:07:29 -0000 On Wed, Mar 02, 2011 at 07:56:36PM -0500, Greg Ansley wrote: > On 3/2/11 7:40 PM, Ian Lepore wrote: > >The following reply was made to PR arm/155214; it has been noted by GNATS. > > > >From: Ian Lepore > >To: ticso@cicely.de > >Cc: FreeBSD-gnats-submit@freebsd.org > >Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern > > large SD cards > >Date: Wed, 02 Mar 2011 17:21:09 -0700 > > > > On Thu, 2011-03-03 at 00:52 +0100, Bernd Walter wrote: > > > On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote: > > > > > > > > >Number: 155214 > > > > >Category: arm > > > > >Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern > > large SD cards > > > > >Confidential: no > > > > >Severity: serious > > > > >Priority: medium > > > > >Responsible: freebsd-arm > > > > >State: open > > > > >Quarter: > > > > >Keywords: > > > > >Date-Required: > > > > >Class: sw-bug > > > > >Submitter-Id: current-users > > > > >Arrival-Date: Wed Mar 02 22:10:10 UTC 2011 > > > > >Closed-Date: > > > > >Last-Modified: > > > > >Originator: Ian Lepore > > > > >Release: FreeBSD 8.2-RC3 arm > > > > >Organization: > > > > none > > > > >Environment: > > > > FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC > > 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB arm > > > > > > > > Included patch is against -current even though the problem was > > first seen on > > > > 8.2-RC3 > > > > > > > > The problem was seen on AT91RM9200 hardware, but presumably also > > affects the > > > > SAM9 series which uses the same driver code. > > > > > > > > >Description: > > > > With the latest generation of large-capacity SD cards, write > > speeds as low as > > > > 20 kbytes/sec are seen. These modern cards have erase-block sizes > > as large as > > > > 8192K (compared to 32K typical on previous generations). The > > at91_mci driver > > > > does only single-sector IO; apparently this requires the SD card > > to internally > > > > perform an expensive read-erase-modify-write cycle for each 512 > > byte block > > > > written to the card. > > > > > > The complete details of this problem are completely known. > > > However the RM9200 has many hardware problems to be worked around and > > > so far noone actually did. > > > Your patch is quite large, so I would like to ask you explicitly: > > > Did you test your patch with an AT91RM9200 system? > > > You did enable multisector support for reading and (more important) > > for > > > writing? > > > But you didn't activate 4bit mode? > > > With 4bit mode there is no hardware bug, but when the driver was > > written > > > is was just done in a lazy way because activating 4bit on SD cards > > require > > > special handling - in the meantime the SD layer itself was extracted > > and > > > has 4bit support, but the at91_mci driver was never updated to use > > that. > > > > > > PS: I'm very pleased to see your work since SD write speed was a > > > major show stopper for some applications > > > > > > > Yes, the patch is large, partly because I included comments about the > > hardware problems I found and how the code works around them (and also > > to help the next person understand the flow). > > > > My changes support multi-sector IO for both reads and writes. > > > > The company I work for uses the AT91RM9200 on custom-designed boards in > > 8 products, all with substantially similar board designs. So far we've > > tested these changes on 4 of them, with no problems found. > > > > I have not tested with 4-bit enabled; I wasn't aware (but in retrospect > > I probably should have assumed) that the hardware bugs are different > > with 4-bit enabled. I'm not even sure our hardware design carries all 4 > > lines to the card; I'll look at the schematics and if they're connected > > I'll see about testing that mode. (And if they're not I'll see about > > having our designers wire up all 4 lines on future designs.) > > > > I also haven't tested with the SAM9-series, because I don't have that > > hardware available. (I hope to convince our hardware designers to > > migrate us to SAM9 this year.) > > > With the current code (prepatch) 4bit mode is known to work at least on > the SAM9G20 with kernel option AT91_MCI_HAS_4WIRE. I'll be working on > the SAM9G20 in the next few days and I can test the patch on both a > RM9200 (1 bit only) and on a couple of SAM9G20 designs with 4bit hardware. Oh - we already have such a feature - cool. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 19:55:28 2011 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 4AF8C1065679 for ; Thu, 3 Mar 2011 19:55:28 +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 0EA108FC1E for ; Thu, 3 Mar 2011 19:55:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id p23JpnCR073752 for ; Thu, 3 Mar 2011 12:51:49 -0700 (MST) (envelope-from imp@bsdimp.com) Message-ID: <4D6FF142.9020801@bsdimp.com> Date: Thu, 03 Mar 2011 12:51:30 -0700 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.13) Gecko/20101211 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <201103030040.p230eBIt023558@freefall.freebsd.org> <4D6EE744.5050100@ansley.com> In-Reply-To: <4D6EE744.5050100@ansley.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards 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, 03 Mar 2011 19:55:28 -0000 On 03/02/2011 17:56, Greg Ansley wrote: > On 3/2/11 7:40 PM, Ian Lepore wrote: >> The following reply was made to PR arm/155214; it has been noted by >> GNATS. >> >> From: Ian Lepore >> To: ticso@cicely.de >> Cc: FreeBSD-gnats-submit@freebsd.org >> Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern >> large SD cards >> Date: Wed, 02 Mar 2011 17:21:09 -0700 >> >> On Thu, 2011-03-03 at 00:52 +0100, Bernd Walter wrote: >> > On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote: >> > > >> > > >Number: 155214 >> > > >Category: arm >> > > >Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern >> large SD cards >> > > >Confidential: no >> > > >Severity: serious >> > > >Priority: medium >> > > >Responsible: freebsd-arm >> > > >State: open >> > > >Quarter: >> > > >Keywords: >> > > >Date-Required: >> > > >Class: sw-bug >> > > >Submitter-Id: current-users >> > > >Arrival-Date: Wed Mar 02 22:10:10 UTC 2011 >> > > >Closed-Date: >> > > >Last-Modified: >> > > >Originator: Ian Lepore >> > > >Release: FreeBSD 8.2-RC3 arm >> > > >Organization: >> > > none >> > > >Environment: >> > > FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC >> 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB arm >> > > >> > > Included patch is against -current even though the problem was >> first seen on >> > > 8.2-RC3 >> > > >> > > The problem was seen on AT91RM9200 hardware, but presumably also >> affects the >> > > SAM9 series which uses the same driver code. >> > > >> > > >Description: >> > > With the latest generation of large-capacity SD cards, write >> speeds as low as >> > > 20 kbytes/sec are seen. These modern cards have erase-block >> sizes as large as >> > > 8192K (compared to 32K typical on previous generations). The >> at91_mci driver >> > > does only single-sector IO; apparently this requires the SD card >> to internally >> > > perform an expensive read-erase-modify-write cycle for each 512 >> byte block >> > > written to the card. >> > >> > The complete details of this problem are completely known. >> > However the RM9200 has many hardware problems to be worked around and >> > so far noone actually did. >> > Your patch is quite large, so I would like to ask you explicitly: >> > Did you test your patch with an AT91RM9200 system? >> > You did enable multisector support for reading and (more >> important) for >> > writing? >> > But you didn't activate 4bit mode? >> > With 4bit mode there is no hardware bug, but when the driver was >> written >> > is was just done in a lazy way because activating 4bit on SD cards >> require >> > special handling - in the meantime the SD layer itself was >> extracted and >> > has 4bit support, but the at91_mci driver was never updated to use >> that. >> > >> > PS: I'm very pleased to see your work since SD write speed was a >> > major show stopper for some applications >> > >> >> Yes, the patch is large, partly because I included comments about the >> hardware problems I found and how the code works around them (and also >> to help the next person understand the flow). >> >> My changes support multi-sector IO for both reads and writes. >> >> The company I work for uses the AT91RM9200 on custom-designed >> boards in >> 8 products, all with substantially similar board designs. So far >> we've >> tested these changes on 4 of them, with no problems found. >> >> I have not tested with 4-bit enabled; I wasn't aware (but in >> retrospect >> I probably should have assumed) that the hardware bugs are different >> with 4-bit enabled. I'm not even sure our hardware design carries >> all 4 >> lines to the card; I'll look at the schematics and if they're >> connected >> I'll see about testing that mode. (And if they're not I'll see about >> having our designers wire up all 4 lines on future designs.) >> >> I also haven't tested with the SAM9-series, because I don't have that >> hardware available. (I hope to convince our hardware designers to >> migrate us to SAM9 this year.) >> > With the current code (prepatch) 4bit mode is known to work at least > on the SAM9G20 with kernel option AT91_MCI_HAS_4WIRE. I'll be working > on the SAM9G20 in the next few days and I can test the patch on both a > RM9200 (1 bit only) and on a couple of SAM9G20 designs with 4bit > hardware. For some ancient history... The Atmel Linux repo went back and forth on the 4-bit support in RM9200. When the SAM9260 was released, they added support there and specifically disabled it for the RM9200. When I asked about it, they muttered something about silicon bugs. After that, it ping ponged back and forth between supported and not for a while. I honestly don't know where it settled finally. Warner From owner-freebsd-arm@FreeBSD.ORG Thu Mar 3 22:04:44 2011 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 D3CD41065670 for ; Thu, 3 Mar 2011 22:04:44 +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 6376B8FC12 for ; Thu, 3 Mar 2011 22:04:43 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p23M4d7h005775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Mar 2011 23:04:39 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p23M4aAJ041093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2011 23:04:36 +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 p23M4aWa031403; Thu, 3 Mar 2011 23:04:36 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id p23M4ZlX031402; Thu, 3 Mar 2011 23:04:35 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Mar 2011 23:04:35 +0100 From: Bernd Walter To: Warner Losh Message-ID: <20110303220435.GP86812@cicely7.cicely.de> References: <201103030040.p230eBIt023558@freefall.freebsd.org> <4D6EE744.5050100@ansley.com> <4D6FF142.9020801@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D6FF142.9020801@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards 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, 03 Mar 2011 22:04:45 -0000 On Thu, Mar 03, 2011 at 12:51:30PM -0700, Warner Losh wrote: > On 03/02/2011 17:56, Greg Ansley wrote: > >On 3/2/11 7:40 PM, Ian Lepore wrote: > >>The following reply was made to PR arm/155214; it has been noted by > >>GNATS. > >> > >>From: Ian Lepore > >>To: ticso@cicely.de > >>Cc: FreeBSD-gnats-submit@freebsd.org > >>Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern > >> large SD cards > >>Date: Wed, 02 Mar 2011 17:21:09 -0700 > >> I have not tested with 4-bit enabled; I wasn't aware (but in > >>retrospect > >> I probably should have assumed) that the hardware bugs are different > >> with 4-bit enabled. I'm not even sure our hardware design carries > >>all 4 > >> lines to the card; I'll look at the schematics and if they're > >>connected > >> I'll see about testing that mode. (And if they're not I'll see about > >> having our designers wire up all 4 lines on future designs.) > >> > >> I also haven't tested with the SAM9-series, because I don't have that > >> hardware available. (I hope to convince our hardware designers to > >> migrate us to SAM9 this year.) > >> > >With the current code (prepatch) 4bit mode is known to work at least > >on the SAM9G20 with kernel option AT91_MCI_HAS_4WIRE. I'll be working > >on the SAM9G20 in the next few days and I can test the patch on both a > >RM9200 (1 bit only) and on a couple of SAM9G20 designs with 4bit > >hardware. > > For some ancient history... > > The Atmel Linux repo went back and forth on the 4-bit support in > RM9200. When the SAM9260 was released, they added support there and > specifically disabled it for the RM9200. When I asked about it, they > muttered something about silicon bugs. After that, it ping ponged back > and forth between supported and not for a while. I honestly don't know > where it settled finally. Interesting. I'm not aware of 4-bit silicon bugs, but of course there are boards, which are 1-bit wired only. And I'm aware that you need 100k pullup or pulldown to the data wires, although my first prototype boards worked fine without them. I don't remember the reason for them. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Mar 4 20:20:12 2011 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B6BB106566B for ; Fri, 4 Mar 2011 20:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E388F8FC1E for ; Fri, 4 Mar 2011 20:20:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p24KKBTI007849 for ; Fri, 4 Mar 2011 20:20:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p24KKBL7007848; Fri, 4 Mar 2011 20:20:11 GMT (envelope-from gnats) Date: Fri, 4 Mar 2011 20:20:11 GMT Message-Id: <201103042020.p24KKBL7007848@freefall.freebsd.org> To: freebsd-arm@FreeBSD.org From: Ian Lepore Cc: Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ian Lepore List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 20:20:12 -0000 The following reply was made to PR arm/155214; it has been noted by GNATS. From: Ian Lepore To: ticso@cicely.de Cc: FreeBSD-gnats-submit@freebsd.org Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards Date: Fri, 04 Mar 2011 13:10:12 -0700 On Thu, 2011-03-03 at 00:52 +0100, Bernd Walter wrote: > On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote: > > > > >Number: 155214 > > >Category: arm > > >Synopsis: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards > > >Confidential: no > > >Severity: serious > > >Priority: medium > > >Responsible: freebsd-arm > > >State: open > > >Quarter: > > >Keywords: > > >Date-Required: > > >Class: sw-bug > > >Submitter-Id: current-users > > >Arrival-Date: Wed Mar 02 22:10:10 UTC 2011 > > >Closed-Date: > > >Last-Modified: > > >Originator: Ian Lepore > > >Release: FreeBSD 8.2-RC3 arm > > >Organization: > > none > > >Environment: > > FreeBSD dvb 8.2-RC3 FreeBSD 8.2-RC3 #49: Tue Feb 15 22:52:14 UTC 2011 root@revolution.hippie.lan:/usr/obj/arm/usr/src/sys/DVB arm > > > > Included patch is against -current even though the problem was first seen on > > 8.2-RC3 > > > > The problem was seen on AT91RM9200 hardware, but presumably also affects the > > SAM9 series which uses the same driver code. > > > > >Description: > > With the latest generation of large-capacity SD cards, write speeds as low as > > 20 kbytes/sec are seen. These modern cards have erase-block sizes as large as > > 8192K (compared to 32K typical on previous generations). The at91_mci driver > > does only single-sector IO; apparently this requires the SD card to internally > > perform an expensive read-erase-modify-write cycle for each 512 byte block > > written to the card. > > The complete details of this problem are completely known. > However the RM9200 has many hardware problems to be worked around and > so far noone actually did. > Your patch is quite large, so I would like to ask you explicitly: > Did you test your patch with an AT91RM9200 system? > You did enable multisector support for reading and (more important) for > writing? > But you didn't activate 4bit mode? > With 4bit mode there is no hardware bug, but when the driver was written > is was just done in a lazy way because activating 4bit on SD cards require > special handling - in the meantime the SD layer itself was extracted and > has 4bit support, but the at91_mci driver was never updated to use that. > > PS: I'm very pleased to see your work since SD write speed was a > major show stopper for some applications > I made some time today to try 4-bit mode in the mci driver, using 8.2-RELEASE as a testbed. I quickly determined that just enabling 4-bit mode results in corrupted read data severe enough to virtually always cause "root mount error" at boot. Occasionally it'll manage to mount root but then lock up or panic during rc-file processing. It does this both with the original driver and with my patched driver configured for single-block or multi-block operation. After some experimenting to find the cause of the corrupted data, I realized we're violating the SD spec by running the bus at 30mhz -- the spec says 25mhz max until you use CMD6 to switch to high-speed mode if the card supports it. Our next lower available speed is 15mhz, and when I set that as the max speed, 4-bit works perfectly, both in the original driver and with my patches in single or multi-block operation. (In my patched driver I had to add a controller reset following a multi-block read stop, similar to after a multi-write, to avoid occasional spurious data crc errors in 4-bit mode. The data we want is read correctly; the crc error happens on the block that's still coming in as the stop command is being issued. I'm not sure why this only happens in 4-bit mode.) Since we've been getting away with 30mhz/1-bit for years, I surmise that any card that is capable of delivering 25mhz/4-bit is also capable of doing 30mhz/1-bit even though that's a slight violation of the spec. But 30mhz/4-bit appears to be enough of a violation that even modern cards don't keep up. (When looking at dumps of the corrupted read data, an old card had a lot of corruption, like 20% of the data was read wrong. A modern card had just a few bits wrong out of every few kbytes read.) Since 15mhz/4bit is still twice the data throughput of 30mhz/1bit I decided to do some crude benchmarking to see if it's worth the trouble of making 4-bit work correctly. The results appear below. In summary, there is definitely a benefit to using 4-bit transfers, but the improvement isn't nearly as dramatic as the change from single- to multi-block IO. Supporting 4-bit transfers properly will require some changes in dev/mmc. It doesn't currently use CMD6 to switch to high-speed mode at all. I'm assuming if we update it to do so, we'll have no problem running at 30mhz/4-bit. There'll also need to be some fixes in the routine that calculates the speed to run at, because right now it doesn't account for the 25mhz speed limit set by the spec before switching to high-speed (which is why we end up running at 30mhz). The mci driver will also need some updates to round down to the next lower supported clock speed requested by the upper layers, but it would probably be good to have a bit of a hack in there as well to allow 30mhz operation in 1-bit mode since folks have come to expect that and it seems to work ok. About the benchmarks... I tested with two different cards, noted below by their erase block sizes. The card with the 32-block erase size is a SanDisk 512mb card from several years ago. The card with the 8192-block erase size is a SanDisk 2gb card purchased recently. The older card does not claim to support high-speed mode, the newer card does (but of course we don't switch the card to hs mode). I tested each card with each combo of bus speed, bus width, and single- versus multi-block IO. All of the results below are with my patched driver. I also briefly tested the original unpatched 8.2 driver and found the results very much in line with the 1-block results from my patched driver. (The patched driver performs a little better even in single-block mode, probably because it gets the same work done with fewer interrupts.) Read and write speeds are as reported by these commands: dd if=/dev/mmcsd0s2a of=/dev/null bs=1m count=10 dd if=/dev/zero of=/dev/mmcsd0s2a bs=1m count=10 Each test was run several times immediately after rebooting; median values reported. There were no writable filesystems mounted and relatively little going on in the system in general, but I didn't get fanatical about leveling the test conditions. Erase/clock/bus/xfer size Read bytes/sec Write bytes/sec 32/30MHz/1bit/1-block 864452 333324 32/15MHz/4bit/1-block 975780 346738 8192/30MHz/1bit/1-block 647241 24211 8192/15MHz/4bit/1-block 722659 24253 32/30MHz/1bit/64-block 2192806 1775660 32/15MHz/4bit/64-block 3075302 1775302 8192/30MHz/1bit/64-block 2133880 1503959 8192/15MHz/4bit/64-block 2947133 1753540 Another crude little benchmark... right after booting I logged on as root immediately and did a vmstat -i, so this should roughly represent how many interrupts it took to get booted and launch root's shell (all read IO, there are no writeable filesystems mounted, both done at 30mhz/1-bit): vmstat -i interrupt total rate original driver (1-block) irq10: at91_mci0 42384 1284 patched driver (64-block) irq10: at91_mci0 1365 52 Based on the benchmark results, and the fact that I don't really have the time to take on the dev/mmc changes right now, I think we should adopt the multi-block patches and stick with 30mhz/1-bit for now. Maybe I can find some time later this year to get dev/mmc working better with high-speed mode (without accidentally breaking the sdhci world, which I don't know enough about right now). From owner-freebsd-arm@FreeBSD.ORG Sat Mar 5 12:49:09 2011 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 35E5D1065670 for ; Sat, 5 Mar 2011 12:49:09 +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 9CC968FC1B for ; Sat, 5 Mar 2011 12:49:08 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id p25Cn1aQ060670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 5 Mar 2011 13:49:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.4/8.14.4) with ESMTP id p25Cmo98043530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Mar 2011 13:48: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 p25CmooL043354; Sat, 5 Mar 2011 13:48: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 p25CmnBO043353; Sat, 5 Mar 2011 13:48:49 +0100 (CET) (envelope-from ticso) Date: Sat, 5 Mar 2011 13:48:49 +0100 From: Bernd Walter To: Ian Lepore Message-ID: <20110305124849.GW86812@cicely7.cicely.de> References: <201103042020.p24KKBL7007848@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103042020.p24KKBL7007848@freefall.freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern large SD cards 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: Sat, 05 Mar 2011 12:49:09 -0000 On Fri, Mar 04, 2011 at 08:20:11PM +0000, Ian Lepore wrote: > The following reply was made to PR arm/155214; it has been noted by GNATS. > > From: Ian Lepore > To: ticso@cicely.de > Cc: FreeBSD-gnats-submit@freebsd.org > Subject: Re: arm/155214: [patch] MMC/SD IO slow on Atmel ARM with modern > large SD cards > Date: Fri, 04 Mar 2011 13:10:12 -0700 > > On Thu, 2011-03-03 at 00:52 +0100, Bernd Walter wrote: > > On Wed, Mar 02, 2011 at 02:53:18PM -0700, Ian Lepore wrote: > Since 15mhz/4bit is still twice the data throughput of 30mhz/1bit I > decided to do some crude benchmarking to see if it's worth the trouble > of making 4-bit work correctly. The results appear below. In > summary, there is definitely a benefit to using 4-bit transfers, but > the improvement isn't nearly as dramatic as the change from single- to > multi-block IO. 4bit transport has a more interesting point than bandwidth. An 64k read with 15MHz/1bit will have ~35ms calculated latency just for the data transport, which I consider a pretty high value. Nevertheless I'm still exited about your multiblock support and your measured values already look fantastic. > Based on the benchmark results, and the fact that I don't really have > the time to take on the dev/mmc changes right now, I think we should > adopt the multi-block patches and stick with 30mhz/1-bit for now. I completely agree with you. The main problem was write performance and this is clearly solved to match with media capabilities - not to speak that the former single block writes also had an increased media wear. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.