From owner-freebsd-arm@FreeBSD.ORG Sun Dec 16 00:08:56 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADD9BAD0 for ; Sun, 16 Dec 2012 00:08:56 +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 315BF8FC1A for ; Sun, 16 Dec 2012 00:08:55 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id qBG08hbw098735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 16 Dec 2012 01:08:44 +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.5/8.14.4) with ESMTP id qBG08eHl071675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Dec 2012 01:08:40 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id qBG08eAW038482; Sun, 16 Dec 2012 01:08:40 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id qBG08drB038481; Sun, 16 Dec 2012 01:08:39 +0100 (CET) (envelope-from ticso) Date: Sun, 16 Dec 2012 01:08:39 +0100 From: Bernd Walter To: Ian Lepore Subject: SAM9G45 (was: sheevaplug boot from nandfs hangs) Message-ID: <20121216000839.GS16564@cicely7.cicely.de> References: <1355364418.87661.489.camel@revolution.hippie.lan> <1355595537.1198.72.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355595537.1198.72.camel@revolution.hippie.lan> 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, Ronald Klop X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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: Sun, 16 Dec 2012 00:08:56 -0000 On Sat, Dec 15, 2012 at 11:18:57AM -0700, Ian Lepore wrote: > Wow, this is all very familiar. I had this exact situation a couple > months ago as I was trying to get freebsd running on my pico-sam9g45 You have a SAM9G45 running? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Sun Dec 16 01:04:37 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8613F4ED for ; Sun, 16 Dec 2012 01:04:37 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8BE2D8FC14 for ; Sun, 16 Dec 2012 01:04:36 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBG14ZRQ067089 for ; Sat, 15 Dec 2012 18:04:35 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBG14CrC060819; Sat, 15 Dec 2012 18:04:12 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: SAM9G45 (was: sheevaplug boot from nandfs hangs) From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20121216000839.GS16564@cicely7.cicely.de> References: <1355364418.87661.489.camel@revolution.hippie.lan> <1355595537.1198.72.camel@revolution.hippie.lan> <20121216000839.GS16564@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Dec 2012 18:04:12 -0700 Message-ID: <1355619852.1198.98.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 01:04:37 -0000 On Sun, 2012-12-16 at 01:08 +0100, Bernd Walter wrote: > On Sat, Dec 15, 2012 at 11:18:57AM -0700, Ian Lepore wrote: > > Wow, this is all very familiar. I had this exact situation a couple > > months ago as I was trying to get freebsd running on my pico-sam9g45 > > You have a SAM9G45 running? > Yeah, this board: http://www.mini-box.com/pico-SAM9G45-X The mci driver is stuck in "1 sector at a time" mode (slow) because all the workarounds for the rm9200 errata seem to interfere with the new less-buggy mci hardware. I think I just need to write a new driver from scratch for the new hardware rev. I've also got ehci working for it. I did some pretty ugly stuff in the at91 directory to get it going. I was just hacking to get it working, then I was going to work with Warner to clean up what I had done and get it committed, but both his and my lives got busy and nothing much has happened for 2 months now. But it does sit here on my desk running just fine (and notably not ever crashing or anything). Pretty much I've been using it when I need to see a freebsd 10 manpage, but not much else. :) I heard a rumor that the hardware guys at work are taking a look at using a G45 for an upcoming project. If that happens, that'll ensure a better mci driver gets written. If you need a patchset and are willing to deal with the ugly half-baked nature of what I've got, just let me know. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Dec 16 01:27:19 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7BF0B58 for ; Sun, 16 Dec 2012 01:27:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B0568FC0C for ; Sun, 16 Dec 2012 01:27:19 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2872692pbc.13 for ; Sat, 15 Dec 2012 17:27:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=tGm+fmvscEudr7PY6dnNsjXQsWN9+Y09jLSi00LD7nE=; b=d3RHv7QmhO9xkd4uzwb8mMaLTH8FUTykayIwkZxkhCzpISlWMKsq2LpohkVhV5t2Eh E+jZz/zlwWv9qo2hcBGFKdcgzl864ni1NDKiCj7/ZzhN9e0w5pF6y4ADvmFt+mIh3RbD IUKV+JtYamOS6taWcFp8168DeU6na6nztIuAZfvzAGADPl7E4PaoBa2u1zjCS+DnoHL6 W/WfKKV7QTejYskWurItCz43Lo8Gla68j2kiZRQTljKqIKzy0As49ZoPkowQ76MsMPUM V9mHVwVtN9qYn8QUWhfRH9Is5Rc1D+e51aLqQJbLSsMic3mYTCSaSF68+cY71aiq82j6 hcMg== Received: by 10.66.77.105 with SMTP id r9mr28843192paw.76.1355621238986; Sat, 15 Dec 2012 17:27:18 -0800 (PST) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id gu5sm5526085pbc.10.2012.12.15.17.27.16 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Dec 2012 17:27:17 -0800 (PST) Sender: Warner Losh Subject: Re: SAM9G45 (was: sheevaplug boot from nandfs hangs) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1355619852.1198.98.camel@revolution.hippie.lan> Date: Sat, 15 Dec 2012 18:27:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1355364418.87661.489.camel@revolution.hippie.lan> <1355595537.1198.72.camel@revolution.hippie.lan> <20121216000839.GS16564@cicely7.cicely.de> <1355619852.1198.98.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmxsfvgaWN2N891kX8FYkvn/gI3KOjkXg9BclWpXu8MPGed4n7+FQfQYmGqhmkWC72y/yTY Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 01:27:19 -0000 On Dec 15, 2012, at 6:04 PM, Ian Lepore wrote: > On Sun, 2012-12-16 at 01:08 +0100, Bernd Walter wrote: >> On Sat, Dec 15, 2012 at 11:18:57AM -0700, Ian Lepore wrote: >>> Wow, this is all very familiar. I had this exact situation a couple >>> months ago as I was trying to get freebsd running on my pico-sam9g45 >>=20 >> You have a SAM9G45 running? >>=20 >=20 > Yeah, this board: http://www.mini-box.com/pico-SAM9G45-X >=20 > The mci driver is stuck in "1 sector at a time" mode (slow) because = all > the workarounds for the rm9200 errata seem to interfere with the new > less-buggy mci hardware. I think I just need to write a new driver = from > scratch for the new hardware rev. I've also got ehci working for it. The G45 also has newer MCI control (with different DMA) than the old = RM9200 or the SAM9260 boards. > I did some pretty ugly stuff in the at91 directory to get it going. I > was just hacking to get it working, then I was going to work with = Warner > to clean up what I had done and get it committed, but both his and my > lives got busy and nothing much has happened for 2 months now. But it > does sit here on my desk running just fine (and notably not ever > crashing or anything). Pretty much I've been using it when I need to > see a freebsd 10 manpage, but not much else. :) I've wanted to do more, and had planned on using my G45 for my sprinkler = control panel (which would include LCD support), but $WORK has been = kinda busy, and life has been over-full... > I heard a rumor that the hardware guys at work are taking a look at > using a G45 for an upcoming project. If that happens, that'll ensure = a > better mci driver gets written. Yea, if I don't beat you to it... > If you need a patchset and are willing to deal with the ugly = half-baked > nature of what I've got, just let me know. Has it changed? Warner= From owner-freebsd-arm@FreeBSD.ORG Sun Dec 16 01:32:43 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E573BDE; Sun, 16 Dec 2012 01:32:43 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 20CBD8FC0C; Sun, 16 Dec 2012 01:32:42 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBG1WPwO094820; Sun, 16 Dec 2012 01:32:25 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 68pkw6tind7vwzvhiyiiwk2ajn; Sun, 16 Dec 2012 01:32:25 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: arm/174461: [patch] Fix off-by-one in arm9/arm10 cache maintenance routines Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <1355603099.1198.87.camel@revolution.hippie.lan> Date: Sat, 15 Dec 2012 17:32:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201212151957.qBFJvdUo044496@revolution.hippie.lan> <1355603099.1198.87.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1283) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 01:32:43 -0000 On Dec 15, 2012, at 12:24 PM, Ian Lepore wrote: > On Sat, 2012-12-15 at 12:08 -0800, Adrian Chadd wrote: >> Wow, cool. What family CPU is in the pandaboard and r-pi? >>=20 >> Would you be able to review the earlier ARM support and see if = similar >> issues exist there? >>=20 >> Thanks! >>=20 >>=20 >>=20 >> Adrian >>=20 >>=20 >> On 15 December 2012 11:57, Ian Lepore = wrote: >>>=20 >>>> Number: 174461 >=20 > This *is* the earlier ARM support. The pandaboard and r-pi are arm = v7. Slight correction: Pandaboard is armv7 (Cortex-A9) RaspberryPi is armv6 (arm11) Tim= From owner-freebsd-arm@FreeBSD.ORG Sun Dec 16 01:33:31 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C35C13 for ; Sun, 16 Dec 2012 01:33:31 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id E655F8FC0A for ; Sun, 16 Dec 2012 01:33:18 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBG1XImI067827 for ; Sat, 15 Dec 2012 18:33:18 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBG1Wtxo060834; Sat, 15 Dec 2012 18:32:55 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: SAM9G45 (was: sheevaplug boot from nandfs hangs) From: Ian Lepore To: Warner Losh In-Reply-To: References: <1355364418.87661.489.camel@revolution.hippie.lan> <1355595537.1198.72.camel@revolution.hippie.lan> <20121216000839.GS16564@cicely7.cicely.de> <1355619852.1198.98.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Sat, 15 Dec 2012 18:32:55 -0700 Message-ID: <1355621575.1198.100.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 01:33:31 -0000 On Sat, 2012-12-15 at 18:27 -0700, Warner Losh wrote: > On Dec 15, 2012, at 6:04 PM, Ian Lepore wrote: > > > On Sun, 2012-12-16 at 01:08 +0100, Bernd Walter wrote: > >> On Sat, Dec 15, 2012 at 11:18:57AM -0700, Ian Lepore wrote: > >>> Wow, this is all very familiar. I had this exact situation a couple > >>> months ago as I was trying to get freebsd running on my pico-sam9g45 > >> > >> You have a SAM9G45 running? > >> > > > > Yeah, this board: http://www.mini-box.com/pico-SAM9G45-X > > > > The mci driver is stuck in "1 sector at a time" mode (slow) because all > > the workarounds for the rm9200 errata seem to interfere with the new > > less-buggy mci hardware. I think I just need to write a new driver from > > scratch for the new hardware rev. I've also got ehci working for it. > > The G45 also has newer MCI control (with different DMA) than the old RM9200 or the SAM9260 boards. > > > I did some pretty ugly stuff in the at91 directory to get it going. I > > was just hacking to get it working, then I was going to work with Warner > > to clean up what I had done and get it committed, but both his and my > > lives got busy and nothing much has happened for 2 months now. But it > > does sit here on my desk running just fine (and notably not ever > > crashing or anything). Pretty much I've been using it when I need to > > see a freebsd 10 manpage, but not much else. :) > > I've wanted to do more, and had planned on using my G45 for my sprinkler control panel (which would include LCD support), but $WORK has been kinda busy, and life has been over-full... > > > I heard a rumor that the hardware guys at work are taking a look at > > using a G45 for an upcoming project. If that happens, that'll ensure a > > better mci driver gets written. > > Yea, if I don't beat you to it... > > > If you need a patchset and are willing to deal with the ugly half-baked > > nature of what I've got, just let me know. > > Has it changed? I have no idea what I last sent you, but I notice that in my pico sandbox I've got some changes checked in to mercurial and a bunch of uncommitted changes too, so you've probably not seen the latest. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Dec 16 05:03:07 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 371867FC for ; Sun, 16 Dec 2012 05:03:07 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id 9CFBB8FC0A for ; Sun, 16 Dec 2012 05:03:06 +0000 (UTC) Received: from [136.186.229.44] (garmitage3.caia.swin.edu.au [136.186.229.44]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id qBG52bZ7017557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Dec 2012 16:02:52 +1100 Message-ID: <50CD55ED.8020000@swin.edu.au> Date: Sun, 16 Dec 2012 16:02:37 +1100 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111003 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: FreeBSD/armv6 for QEMU References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 05:03:07 -0000 On 12/06/2012 18:52, Oleksandr Tymoshenko wrote: > Hello, > > I've just finished first version of VersatilePB support for FreeBSD/armv6. > QEMU uses this machine as a base for armv6 emulation. > > Full patch: http://people.freebsd.org/~gonzo/arm/qemu/versatilepb.diff > Build/run info: http://kernelnomicon.org/?p=229 [..] Just wanted to publicly say Thanks! I recently started dabbling with emulating embedded devices (for possible educational use), and your patches worked nicely. I managed to boot and run my own build of your patched -CURRENT kernel under qemu 1.1.1 (qemu-devel on a FreeBSD 8 host) with modest reliability (I can establish network connectivity, ssh in to the guest, run basic executables, but while trying to build a simple Port the guest OS stopped responding to anything but ping). I know your blog says I shouldn't try qemu 1.1.1, but I couldn't resist ;) Under qemu 1.3.0 (on a WinXP Host) the VersatilePB guest successfully built a number of small-ish ports (tmux, ushare, gmake, ..) without freezing or crashing. cheers, gja From owner-freebsd-arm@FreeBSD.ORG Sun Dec 16 21:16:26 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D0B98C95; Sun, 16 Dec 2012 21:16:26 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 464568FC19; Sun, 16 Dec 2012 21:16:26 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.5/8.14.5/ALCHEMY.FRANKEN.DE) with ESMTP id qBGLGNN0049914; Sun, 16 Dec 2012 22:16:24 +0100 (CET) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.5/8.14.5/Submit) id qBGLGNXu049913; Sun, 16 Dec 2012 22:16:23 +0100 (CET) (envelope-from marius) Date: Sun, 16 Dec 2012 22:16:23 +0100 From: Marius Strobl To: Jeff Roberson Subject: Re: Call for testing and review, busdma changes Message-ID: <20121216211623.GA49699@alchemy.franken.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Sun, 16 Dec 2012 23:03:45 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Dec 2012 21:16:26 -0000 On Sat, Dec 08, 2012 at 08:51:12AM -1000, Jeff Roberson wrote: > Hello, > > http://people.freebsd.org/~jeff/physbio.diff > > I have a relative large patch that reforms the busdma API so that new > types may be added without modifying every architecture's > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > routines so that they may be called from MI code. The MD busdma is then > given a chance to do any final processing in the complete() callback. > This patch also contains cam changes to unify the bus_dmamap_load* > handling in cam drivers. > > The arm and mips implementations saw the largest changes since they have > to track virtual addresses for sync(). Previously this was done in a type > specific way. Now it is done in a generic way by recording the list of > virtuals in the map. > > I have verified that this patch passes make universe which includes > several kernel builds from each architecture. I suspect that if I broke > anything your machine simply won't boot or will throw I/O errors. There > is little subtlety, it is mostly refactoring. > > The next step is to allow for dma loading of physical addresses. This > will permit unmapped I/O. Which is a significant performance optimization > targeted for 10.0. > > Many thanks for your assistance. Any review feedback is also appreciated. > Survives a buildworld on sparc64; tested with mpt(4) and sym(4). Marius From owner-freebsd-arm@FreeBSD.ORG Mon Dec 17 11:06:40 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E878C97D for ; Mon, 17 Dec 2012 11:06:40 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B1CB28FC1D for ; Mon, 17 Dec 2012 11:06:40 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qBHB6eVt023379 for ; Mon, 17 Dec 2012 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qBHB6eKL023377 for freebsd-arm@FreeBSD.org; Mon, 17 Dec 2012 11:06:40 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Dec 2012 11:06:40 GMT Message-Id: <201212171106.qBHB6eKL023377@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 Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Dec 2012 11:06:41 -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/174461 arm [patch] Fix off-by-one in arm9/arm10 cache maintenance o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic 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 16 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Dec 17 13:03:06 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB205F2 for ; Mon, 17 Dec 2012 13:03:06 +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 5BE108FC0A for ; Mon, 17 Dec 2012 13:03:05 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id qBHD2rqY035839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Dec 2012 14:02:53 +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.5/8.14.4) with ESMTP id qBHD2beF021565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 14:02:37 +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 qBHD2bbq049017; Mon, 17 Dec 2012 14:02:37 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id qBHD2aLO049016; Mon, 17 Dec 2012 14:02:36 +0100 (CET) (envelope-from ticso) Date: Mon, 17 Dec 2012 14:02:36 +0100 From: Bernd Walter To: Warner Losh Subject: Re: SAM9G45 (was: sheevaplug boot from nandfs hangs) Message-ID: <20121217130236.GB46193@cicely7.cicely.de> References: <1355364418.87661.489.camel@revolution.hippie.lan> <1355595537.1198.72.camel@revolution.hippie.lan> <20121216000839.GS16564@cicely7.cicely.de> <1355619852.1198.98.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 17 Dec 2012 13:03:06 -0000 On Sat, Dec 15, 2012 at 06:27:12PM -0700, Warner Losh wrote: > > On Dec 15, 2012, at 6:04 PM, Ian Lepore wrote: > > > On Sun, 2012-12-16 at 01:08 +0100, Bernd Walter wrote: > >> On Sat, Dec 15, 2012 at 11:18:57AM -0700, Ian Lepore wrote: > >>> Wow, this is all very familiar. I had this exact situation a couple > >>> months ago as I was trying to get freebsd running on my pico-sam9g45 > >> > >> You have a SAM9G45 running? > >> > > > > Yeah, this board: http://www.mini-box.com/pico-SAM9G45-X > > > > The mci driver is stuck in "1 sector at a time" mode (slow) because all > > the workarounds for the rm9200 errata seem to interfere with the new > > less-buggy mci hardware. I think I just need to write a new driver from > > scratch for the new hardware rev. I've also got ehci working for it. > > The G45 also has newer MCI control (with different DMA) than the old RM9200 or the SAM9260 boards. > > > I did some pretty ugly stuff in the at91 directory to get it going. I > > was just hacking to get it working, then I was going to work with Warner > > to clean up what I had done and get it committed, but both his and my > > lives got busy and nothing much has happened for 2 months now. But it > > does sit here on my desk running just fine (and notably not ever > > crashing or anything). Pretty much I've been using it when I need to > > see a freebsd 10 manpage, but not much else. :) > > I've wanted to do more, and had planned on using my G45 for my sprinkler control panel (which would include LCD support), but $WORK has been kinda busy, and life has been over-full... Unfortunately I'm also low on time, but I have two g45 boards: http://shop.in-circuit.de/products/Home/ICnova-CPU-Module/6/ICnova-SAM9G45-OEM Have them together with different devboards - one with display. > > I heard a rumor that the hardware guys at work are taking a look at > > using a G45 for an upcoming project. If that happens, that'll ensure a > > better mci driver gets written. > > Yea, if I don't beat you to it... > > > If you need a patchset and are willing to deal with the ugly half-baked > > nature of what I've got, just let me know. > > Has it changed? -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Tue Dec 18 00:09:19 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1DF2069D; Tue, 18 Dec 2012 00:09:19 +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 D246B8FC0C; Tue, 18 Dec 2012 00:09:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBI09BvE097689; Mon, 17 Dec 2012 19:09:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBI09BDV097676; Tue, 18 Dec 2012 00:09:11 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 00:09:11 GMT Message-Id: <201212180009.qBI09BDV097676@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 00:09:19 -0000 TB --- 2012-12-17 22:40:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-17 22:40:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-17 22:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-17 22:40:00 - cleaning the object tree TB --- 2012-12-17 22:40:00 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-17 22:40:00 - cd /tinderbox/HEAD/arm/arm TB --- 2012-12-17 22:40:00 - /usr/local/bin/svn cleanup /src TB --- 2012-12-17 22:44:18 - /usr/local/bin/svn update /src TB --- 2012-12-17 22:44:28 - At svn revision 244368 TB --- 2012-12-17 22:44:29 - building world TB --- 2012-12-17 22:44:29 - CROSS_BUILD_TESTING=YES TB --- 2012-12-17 22:44:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-17 22:44:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-17 22:44:29 - SRCCONF=/dev/null TB --- 2012-12-17 22:44:29 - TARGET=arm TB --- 2012-12-17 22:44:29 - TARGET_ARCH=arm TB --- 2012-12-17 22:44:29 - TZ=UTC TB --- 2012-12-17 22:44:29 - __MAKE_CONF=/dev/null TB --- 2012-12-17 22:44:29 - cd /src TB --- 2012-12-17 22:44:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Dec 17 22:44:39 UTC 2012 >>> 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 >>> World build completed on Mon Dec 17 23:43:03 UTC 2012 TB --- 2012-12-17 23:43:03 - generating LINT kernel config TB --- 2012-12-17 23:43:03 - cd /src/sys/arm/conf TB --- 2012-12-17 23:43:03 - /usr/bin/make -B LINT TB --- 2012-12-17 23:43:03 - cd /src/sys/arm/conf TB --- 2012-12-17 23:43:03 - /usr/sbin/config -m LINT TB --- 2012-12-17 23:43:03 - building LINT kernel TB --- 2012-12-17 23:43:03 - CROSS_BUILD_TESTING=YES TB --- 2012-12-17 23:43:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-17 23:43:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-17 23:43:03 - SRCCONF=/dev/null TB --- 2012-12-17 23:43:03 - TARGET=arm TB --- 2012-12-17 23:43:03 - TARGET_ARCH=arm TB --- 2012-12-17 23:43:03 - TZ=UTC TB --- 2012-12-17 23:43:03 - __MAKE_CONF=/dev/null TB --- 2012-12-17 23:43:03 - cd /src TB --- 2012-12-17 23:43:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Dec 17 23:43:03 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Dec 18 00:03:19 UTC 2012 TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m AC100 TB --- 2012-12-18 00:03:19 - skipping AC100 kernel TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m ARMADAXP TB --- 2012-12-18 00:03:19 - skipping ARMADAXP kernel TB --- 2012-12-18 00:03:19 - cd /src/sys/arm/conf TB --- 2012-12-18 00:03:19 - /usr/sbin/config -m ATMEL TB --- 2012-12-18 00:03:19 - building ATMEL kernel TB --- 2012-12-18 00:03:19 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 00:03:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 00:03:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 00:03:19 - SRCCONF=/dev/null TB --- 2012-12-18 00:03:19 - TARGET=arm TB --- 2012-12-18 00:03:19 - TARGET_ARCH=arm TB --- 2012-12-18 00:03:19 - TZ=UTC TB --- 2012-12-18 00:03:19 - __MAKE_CONF=/dev/null TB --- 2012-12-18 00:03:19 - cd /src TB --- 2012-12-18 00:03:19 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Tue Dec 18 00:03:19 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Tue Dec 18 00:07:13 UTC 2012 TB --- 2012-12-18 00:07:13 - cd /src/sys/arm/conf TB --- 2012-12-18 00:07:13 - /usr/sbin/config -m AVILA TB --- 2012-12-18 00:07:13 - skipping AVILA kernel TB --- 2012-12-18 00:07:13 - cd /src/sys/arm/conf TB --- 2012-12-18 00:07:13 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-12-18 00:07:14 - skipping BEAGLEBONE kernel TB --- 2012-12-18 00:07:14 - cd /src/sys/arm/conf TB --- 2012-12-18 00:07:14 - /usr/sbin/config -m BWCT TB --- 2012-12-18 00:07:14 - building BWCT kernel TB --- 2012-12-18 00:07:14 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 00:07:14 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 00:07:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 00:07:14 - SRCCONF=/dev/null TB --- 2012-12-18 00:07:14 - TARGET=arm TB --- 2012-12-18 00:07:14 - TARGET_ARCH=arm TB --- 2012-12-18 00:07:14 - TZ=UTC TB --- 2012-12-18 00:07:14 - __MAKE_CONF=/dev/null TB --- 2012-12-18 00:07:14 - cd /src TB --- 2012-12-18 00:07:14 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Tue Dec 18 00:07:14 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/cc/cc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/cc/cc_newreno.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/tcp_hostcache.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c: In function 'tcp_input': /src/sys/netinet/tcp_input.c:783: error: 'isipv6' undeclared (first use in this function) /src/sys/netinet/tcp_input.c:783: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_input.c:783: error: for each function it appears in.) *** [tcp_input.o] Error code 1 Stop in /obj/arm.arm/src/sys/BWCT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 00:09:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 00:09:11 - ERROR: failed to build BWCT kernel TB --- 2012-12-18 00:09:11 - 3742.32 user 790.08 system 5351.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Dec 18 09:09:22 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E884890; Tue, 18 Dec 2012 09:09:22 +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 601528FC12; Tue, 18 Dec 2012 09:09:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id qBI99LQw082656; Tue, 18 Dec 2012 04:09:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id qBI99LtU082649; Tue, 18 Dec 2012 09:09:21 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 18 Dec 2012 09:09:21 GMT Message-Id: <201212180909.qBI99LtU082649@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 , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 09:09:22 -0000 TB --- 2012-12-18 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 07:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 07:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-18 07:30:00 - cleaning the object tree TB --- 2012-12-18 07:36:16 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 07:36:16 - cd /tinderbox/HEAD/arm/arm TB --- 2012-12-18 07:36:16 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 07:37:46 - /usr/local/bin/svn update /src TB --- 2012-12-18 07:38:04 - At svn revision 244385 TB --- 2012-12-18 07:38:05 - building world TB --- 2012-12-18 07:38:05 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 07:38:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 07:38:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 07:38:05 - SRCCONF=/dev/null TB --- 2012-12-18 07:38:05 - TARGET=arm TB --- 2012-12-18 07:38:05 - TARGET_ARCH=arm TB --- 2012-12-18 07:38:05 - TZ=UTC TB --- 2012-12-18 07:38:05 - __MAKE_CONF=/dev/null TB --- 2012-12-18 07:38:05 - cd /src TB --- 2012-12-18 07:38:05 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Tue Dec 18 07:38:11 UTC 2012 >>> 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 >>> World build completed on Tue Dec 18 08:41:58 UTC 2012 TB --- 2012-12-18 08:41:58 - generating LINT kernel config TB --- 2012-12-18 08:41:58 - cd /src/sys/arm/conf TB --- 2012-12-18 08:41:58 - /usr/bin/make -B LINT TB --- 2012-12-18 08:41:58 - cd /src/sys/arm/conf TB --- 2012-12-18 08:41:58 - /usr/sbin/config -m LINT TB --- 2012-12-18 08:41:58 - building LINT kernel TB --- 2012-12-18 08:41:58 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 08:41:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 08:41:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 08:41:58 - SRCCONF=/dev/null TB --- 2012-12-18 08:41:58 - TARGET=arm TB --- 2012-12-18 08:41:58 - TARGET_ARCH=arm TB --- 2012-12-18 08:41:58 - TZ=UTC TB --- 2012-12-18 08:41:58 - __MAKE_CONF=/dev/null TB --- 2012-12-18 08:41:58 - cd /src TB --- 2012-12-18 08:41:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Dec 18 08:41:58 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Dec 18 09:03:17 UTC 2012 TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m AC100 TB --- 2012-12-18 09:03:17 - skipping AC100 kernel TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m ARMADAXP TB --- 2012-12-18 09:03:17 - skipping ARMADAXP kernel TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m ATMEL TB --- 2012-12-18 09:03:17 - building ATMEL kernel TB --- 2012-12-18 09:03:17 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 09:03:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 09:03:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 09:03:17 - SRCCONF=/dev/null TB --- 2012-12-18 09:03:17 - TARGET=arm TB --- 2012-12-18 09:03:17 - TARGET_ARCH=arm TB --- 2012-12-18 09:03:17 - TZ=UTC TB --- 2012-12-18 09:03:17 - __MAKE_CONF=/dev/null TB --- 2012-12-18 09:03:17 - cd /src TB --- 2012-12-18 09:03:17 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Tue Dec 18 09:03:18 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Tue Dec 18 09:07:33 UTC 2012 TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m AVILA TB --- 2012-12-18 09:07:33 - skipping AVILA kernel TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-12-18 09:07:33 - skipping BEAGLEBONE kernel TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m BWCT TB --- 2012-12-18 09:07:33 - building BWCT kernel TB --- 2012-12-18 09:07:33 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 09:07:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 09:07:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 09:07:33 - SRCCONF=/dev/null TB --- 2012-12-18 09:07:33 - TARGET=arm TB --- 2012-12-18 09:07:33 - TARGET_ARCH=arm TB --- 2012-12-18 09:07:33 - TZ=UTC TB --- 2012-12-18 09:07:33 - __MAKE_CONF=/dev/null TB --- 2012-12-18 09:07:33 - cd /src TB --- 2012-12-18 09:07:33 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Tue Dec 18 09:07:33 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/cc/cc.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/cc/cc_newreno.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/tcp_hostcache.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -Werror /src/sys/netinet/tcp_input.c /src/sys/netinet/tcp_input.c: In function 'tcp_input': /src/sys/netinet/tcp_input.c:783: error: 'isipv6' undeclared (first use in this function) /src/sys/netinet/tcp_input.c:783: error: (Each undeclared identifier is reported only once /src/sys/netinet/tcp_input.c:783: error: for each function it appears in.) *** [tcp_input.o] Error code 1 Stop in /obj/arm.arm/src/sys/BWCT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-12-18 09:09:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-12-18 09:09:21 - ERROR: failed to build BWCT kernel TB --- 2012-12-18 09:09:21 - 3774.85 user 812.13 system 5960.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Wed Dec 19 23:03:36 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F1A244E; Wed, 19 Dec 2012 23:03:36 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 97ABF8FC16; Wed, 19 Dec 2012 23:03:29 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBJN3Smn050166; Wed, 19 Dec 2012 16:03:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBJN3NsO065767; Wed, 19 Dec 2012 16:03:23 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Jeff Roberson In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Dec 2012 16:03:23 -0700 Message-ID: <1355958203.1198.235.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 19 Dec 2012 23:34:56 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:03:36 -0000 On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: > Hello, > > http://people.freebsd.org/~jeff/physbio.diff > > I have a relative large patch that reforms the busdma API so that new > types may be added without modifying every architecture's > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > routines so that they may be called from MI code. The MD busdma is then > given a chance to do any final processing in the complete() callback. > This patch also contains cam changes to unify the bus_dmamap_load* > handling in cam drivers. > > The arm and mips implementations saw the largest changes since they have > to track virtual addresses for sync(). Previously this was done in a type > specific way. Now it is done in a generic way by recording the list of > virtuals in the map. > > I have verified that this patch passes make universe which includes > several kernel builds from each architecture. I suspect that if I broke > anything your machine simply won't boot or will throw I/O errors. There > is little subtlety, it is mostly refactoring. > > The next step is to allow for dma loading of physical addresses. This > will permit unmapped I/O. Which is a significant performance optimization > targeted for 10.0. > > Many thanks for your assistance. Any review feedback is also appreciated. > > Jeff More test results... Today I updated to r244435 and then applied your patches (and my little fix, but not my big set of busdma changes) over that, and built everything fresh for my DreamPlug. I plugged an SSD drive into the eSata port for some testing and right away noticed extreme slowness; 'camcontrol identify' shows the drive running in PIO mode with the patches, but it's fine without them (output below). I'm no ata or cam wizard, but I can easily toggle back and forth between kernels with/without the patches; let me know if I can do anything to generate useful info to track this down. -- Ian -------------------------------- With unpatched -current @ r244435 ada0 at mvsch0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) root@dpcur:/root # camcontrol identify ada0 pass0: ATA-9 SATA 2.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 2.x device model M4-CT128M4SSD2 firmware revision 000F serial number 0000000012290910F745 WWN 500a07510910f745 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 250069680 sectors LBA48 supported 250069680 sectors PIO supported PIO4 DMA supported WDMA2 UDMA5 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify yes no 0/0x0 unload yes yes free-fall no no data set management (TRIM) yes -------------------------------- With physbio patches applied to r244435... ada0 at mvsch0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) root@dpcur:/root # camcontrol identify ada0 pass0: < > ATA-0 device pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) protocol ATA/ATAPI-0 device model firmware revision serial number cylinders 0 heads 0 sectors/track 0 sector size logical 512, physical 512, offset 0 LBA not supported LBA48 not supported PIO supported PIO0 w/o IORDY DMA not supported Feature Support Enabled Value Vendor read ahead no no write cache no no flush cache no no overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) no SMART no no microcode download no no security no no power management no no advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload no no free-fall no no data set management (TRIM) no -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Dec 20 00:41:36 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 044F07D for ; Thu, 20 Dec 2012 00:41:36 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id BDB268FC13 for ; Thu, 20 Dec 2012 00:41:35 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBK0fSQf057028 for ; Wed, 19 Dec 2012 17:41:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBK0fPo7065942 for ; Wed, 19 Dec 2012 17:41:25 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: nand performance From: Ian Lepore To: freebsd-arm@freebsd.org Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Dec 2012 17:41:25 -0700 Message-ID: <1355964085.1198.255.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Dec 2012 00:41:36 -0000 I've been working to get nandfs going on a low-end Atmel arm system. Performance is horrible. Last weekend I got my nand-based DreamPlug unbricked and got nandfs working on it too. Performance is horrible. By that I'm referring not to the slow nature of the nand chips themselves, but to the fact that accessing them locks out userland processes, sometimes for many seconds at a time. The problem is real easy to see, just format and populate a nandfs filesystem, then do something like this mount -r -t nandfs /dev/gnand0s.root /mnt nice +20 find /mnt -type f | xargs -J% cat % > /dev/null and then try to type in another terminal -- sometimes what you're typing doesn't get echoed for 10+ seconds a time. The problem is that the "I/O" on a nand chip is really just the cpu copying from one memory interface to another, a byte at a time, and it must also use busy-wait loops to wait for chip-ready and status info. This is being done by high-priority kernel threads, so everything else is locked out. It seems to me that this is about the same situation as classic ATA PIO mode, but PIO doesn't make a system that unresponsive. I'm curious what techniques are used to migitate performance problems for ATA PIO modes, and whether we can do something similar for nand. I poked around a bit in dev/ata but the PIO code I saw (which surely wasn't the whole picture) just used a bus_space_read_multi(). Can someone clue me in as to how ATA manages to do PIO without usurping the whole system? -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Dec 20 18:55:14 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B087960B for ; Thu, 20 Dec 2012 18:55:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id 42E198FC14 for ; Thu, 20 Dec 2012 18:55:13 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 359431501 for freebsd-arm@freebsd.org; Thu, 20 Dec 2012 19:55:11 +0100 From: Hans Petter Selasky To: freebsd-arm@freebsd.org Subject: Fwd: Re: EHCI on armv6 with Write-Back caches Date: Thu, 20 Dec 2012 19:56:47 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212201956.47884.hselasky@c2i.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Dec 2012 18:55:14 -0000 FYI - please test! ---------- Forwarded Message ---------- Subject: Re: EHCI on armv6 with Write-Back caches Date: Thursday 20 December 2012, 19:46:34 From: Hans Petter Selasky To: Warner Losh CC: Andrew Turner , Oleksandr Tymoshenko , freebsd-usb@freebsd.org, alfred@freebsd.org, freebsd- wireless@freebsd.org Hi, I've run some basic tests over here (x86) which passed after some patch modifications. Please test and verify for your ARM targets: http://svnweb.freebsd.org/changeset/base/244500 http://svnweb.freebsd.org/changeset/base/244503 Please also verify that upgt and uwrt and uath still works like expected. --HPS ----------------------------------------- From owner-freebsd-arm@FreeBSD.ORG Thu Dec 20 19:49:24 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 99CEC60B for ; Thu, 20 Dec 2012 19:49:24 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id C04D38FC13 for ; Thu, 20 Dec 2012 19:49:23 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBKJnMvx016715 for ; Thu, 20 Dec 2012 12:49:22 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBKJnKqX066776; Thu, 20 Dec 2012 12:49:20 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <201212201956.47884.hselasky@c2i.net> References: <201212201956.47884.hselasky@c2i.net> Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Dec 2012 12:49:20 -0700 Message-ID: <1356032960.1198.313.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Dec 2012 19:49:24 -0000 On Thu, 2012-12-20 at 19:56 +0100, Hans Petter Selasky wrote: > FYI - please test! > > ---------- Forwarded Message ---------- > > Subject: Re: EHCI on armv6 with Write-Back caches > Date: Thursday 20 December 2012, 19:46:34 > From: Hans Petter Selasky > To: Warner Losh > CC: Andrew Turner , Oleksandr Tymoshenko > , freebsd-usb@freebsd.org, alfred@freebsd.org, freebsd- > wireless@freebsd.org > > Hi, > > I've run some basic tests over here (x86) which passed after some patch > modifications. Please test and verify for your ARM targets: > > http://svnweb.freebsd.org/changeset/base/244500 > http://svnweb.freebsd.org/changeset/base/244503 > > Please also verify that upgt and uwrt and uath still works like expected. > > --HPS FYI, I've done some testing (it was weeks ago) of EHCI on armv4 and had no problems at all. I didn't exactly beat it to death, but I know I tested umass in particular with some file copying and tar/untar and that sort of thing. I'll make a point of updating and re-testing that soon. If there have been problems on armv6, especially with the memory shared between the cpu and hci (the descriptor lists), there's a chance it's fallout from the change in busdma_machdep-armv6.c in August to stop honoring BUS_DMAMEM_COHERENT (r239597). While the docs don't require that flag to be honored, the practical reality is that drivers are relying on the fact that the ARM and MIPS implementations treat that flag as if it were BUS_DMAMEM_NOCACHE. As of r244469 (yesterday) the COHERENT flag will hand out uncached memory again, so if the shared descriptor lists were any part of the problem, that should be fixed now. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Dec 20 20:07:39 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6B50BA95 for ; Thu, 20 Dec 2012 20:07:39 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0598FC0C for ; Thu, 20 Dec 2012 20:07:38 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id qBKK7TG7081746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2012 12:07:29 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id qBKK7S0p081745; Thu, 20 Dec 2012 12:07:28 -0800 (PST) (envelope-from jmg) Date: Thu, 20 Dec 2012 12:07:28 -0800 From: John-Mark Gurney To: Ian Lepore Subject: Re: nand performance Message-ID: <20121220200728.GK1563@funkthat.com> Mail-Followup-To: Ian Lepore , freebsd-arm@freebsd.org References: <1355964085.1198.255.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1355964085.1198.255.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 20 Dec 2012 12:07:29 -0800 (PST) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Dec 2012 20:07:39 -0000 Ian Lepore wrote this message on Wed, Dec 19, 2012 at 17:41 -0700: > I've been working to get nandfs going on a low-end Atmel arm system. > Performance is horrible. Last weekend I got my nand-based DreamPlug > unbricked and got nandfs working on it too. Performance is horrible. > > By that I'm referring not to the slow nature of the nand chips > themselves, but to the fact that accessing them locks out userland > processes, sometimes for many seconds at a time. The problem is real > easy to see, just format and populate a nandfs filesystem, then do > something like this > > mount -r -t nandfs /dev/gnand0s.root /mnt > nice +20 find /mnt -type f | xargs -J% cat % > /dev/null > > and then try to type in another terminal -- sometimes what you're typing > doesn't get echoed for 10+ seconds a time. > > The problem is that the "I/O" on a nand chip is really just the cpu > copying from one memory interface to another, a byte at a time, and it > must also use busy-wait loops to wait for chip-ready and status info. > This is being done by high-priority kernel threads, so everything else > is locked out. > > It seems to me that this is about the same situation as classic ATA PIO > mode, but PIO doesn't make a system that unresponsive. > > I'm curious what techniques are used to migitate performance problems > for ATA PIO modes, and whether we can do something similar for nand. I > poked around a bit in dev/ata but the PIO code I saw (which surely > wasn't the whole picture) just used a bus_space_read_multi(). Can > someone clue me in as to how ATA manages to do PIO without usurping the > whole system? Looks like the problem is all the DELAY calls in dev/nand/nand_generic.c.. DELAY is a busy wait not letting the cpu do anything else... The bad one is probably generic_erase_block as it looks like the default is 3ms, plenty of time to let other code run... If it could be interrupt driven, that'd be best... I can't find the interface that would allow sub-hz sleeping, but there is tsleep that could be used for some of the larger sleeps... But switching to interrupts + wakeup would be best... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Fri Dec 21 00:19:04 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D807FE89 for ; Fri, 21 Dec 2012 00:19:04 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 775888FC0A for ; Fri, 21 Dec 2012 00:19:04 +0000 (UTC) Received: from [88.198.91.248] (helo=[IPv6:::1]) by id.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TlqKI-000GDG-EG; Thu, 20 Dec 2012 16:19:03 -0800 Message-ID: <50D3AAF1.80609@bluezbox.com> Date: Thu, 20 Dec 2012 16:18:57 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Hans Petter Selasky Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches References: <201212201956.47884.hselasky@c2i.net> In-Reply-To: <201212201956.47884.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > FYI - please test! > > Forwarded Message > > Subject: Re: EHCI on armv6 with Write-Back caches > Date: Thursday 20 December 2012, 19:46:34 > From: Hans Petter Selasky > To: Warner Losh > CC: Andrew Turner , Oleksandr Tymoshenko > , freebsd-usb@freebsd.org, alfred@freebsd.org, freebsd- > wireless@freebsd.org > > Hi, > > I've run some basic tests over here (x86) which passed after some patch > modifications. Please test and verify for your ARM targets: > > http://svnweb.freebsd.org/changeset/base/244500 > http://svnweb.freebsd.org/changeset/base/244503 > > Please also verify that upgt and uwrt and uath still works like expected. > > --HPS > [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:19:04 -0000 On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > FYI - please test! > > ---------- Forwarded Message ---------- > > Subject: Re: EHCI on armv6 with Write-Back caches > Date: Thursday 20 December 2012, 19:46:34 > From: Hans Petter Selasky > To: Warner Losh > CC: Andrew Turner , Oleksandr Tymoshenko > , freebsd-usb@freebsd.org, alfred@freebsd.org, freebsd- > wireless@freebsd.org > > Hi, > > I've run some basic tests over here (x86) which passed after some patch > modifications. Please test and verify for your ARM targets: > > http://svnweb.freebsd.org/changeset/base/244500 > http://svnweb.freebsd.org/changeset/base/244503 > > Please also verify that upgt and uwrt and uath still works like expected. > > --HPS > if_smsc fails with following diagnostics: smsc0: error: allocating USB transfers failed The problem is that Bulk-In transfer buffer is 5 pages long but tag's boundary limitation is a page and it's impossible to allocate 5 pages without crossing page boundary From owner-freebsd-arm@FreeBSD.ORG Fri Dec 21 00:50:55 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 890B4409 for ; Fri, 21 Dec 2012 00:50:55 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 1FFE08FC14 for ; Fri, 21 Dec 2012 00:50:54 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBL0olCP020624 for ; Thu, 20 Dec 2012 17:50:48 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBL0oj3H066949; Thu, 20 Dec 2012 17:50:45 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: nand performance From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20121220200728.GK1563@funkthat.com> References: <1355964085.1198.255.camel@revolution.hippie.lan> <20121220200728.GK1563@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Dec 2012 17:50:45 -0700 Message-ID: <1356051045.1198.329.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 00:50:55 -0000 On Thu, 2012-12-20 at 12:07 -0800, John-Mark Gurney wrote: > Ian Lepore wrote this message on Wed, Dec 19, 2012 at 17:41 -0700: > > I've been working to get nandfs going on a low-end Atmel arm system. > > Performance is horrible. Last weekend I got my nand-based DreamPlug > > unbricked and got nandfs working on it too. Performance is horrible. > > > > By that I'm referring not to the slow nature of the nand chips > > themselves, but to the fact that accessing them locks out userland > > processes, sometimes for many seconds at a time. The problem is real > > easy to see, just format and populate a nandfs filesystem, then do > > something like this > > > > mount -r -t nandfs /dev/gnand0s.root /mnt > > nice +20 find /mnt -type f | xargs -J% cat % > /dev/null > > > > and then try to type in another terminal -- sometimes what you're typing > > doesn't get echoed for 10+ seconds a time. > > > > The problem is that the "I/O" on a nand chip is really just the cpu > > copying from one memory interface to another, a byte at a time, and it > > must also use busy-wait loops to wait for chip-ready and status info. > > This is being done by high-priority kernel threads, so everything else > > is locked out. > > > > It seems to me that this is about the same situation as classic ATA PIO > > mode, but PIO doesn't make a system that unresponsive. > > > > I'm curious what techniques are used to migitate performance problems > > for ATA PIO modes, and whether we can do something similar for nand. I > > poked around a bit in dev/ata but the PIO code I saw (which surely > > wasn't the whole picture) just used a bus_space_read_multi(). Can > > someone clue me in as to how ATA manages to do PIO without usurping the > > whole system? > > Looks like the problem is all the DELAY calls in dev/nand/nand_generic.c.. > DELAY is a busy wait not letting the cpu do anything else... The bad one > is probably generic_erase_block as it looks like the default is 3ms, > plenty of time to let other code run... If it could be interrupt driven, > that'd be best... > > I can't find the interface that would allow sub-hz sleeping, but there is > tsleep that could be used for some of the larger sleeps... But switching > to interrupts + wakeup would be best... > Yeah, the DELAY() calls were actually not working for me (I think I'm the first to test this stuff with an ONFI type chip), and I've replaced them all with loops that poll for ready status, which at least minimizes the wait time, but it's still a busy-loop. Real-world times for the chips I'm working with are 30uS to open a page for read, ~270uS to write a page, and ~750uS to erase a block. But whether busy-looping for status or busy-looping polling a clock for DELAY, or transferring a byte at a time for the actual IO, it's all the same... it's cpu and memory bus cycles that are happening in a high-priority kernel thread. The interface between the low-level controller and the nand layer doesn't allow for interrupt handling right now. Not all hardware designs would allow for using interrupts, but mine does, so reworking things to allow its use would help some. Well, it would help for writes and erases. The 180mhz ARM I'm working with doesn't get much done in 30uS, so reads wouldn't get any better. Reads are all I really care about, since the product in the field will have a read-only filesystem, and firmware updates are infrequent and it's okay if they're a bit slow. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Dec 21 03:02:18 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D311B79E for ; Fri, 21 Dec 2012 03:02:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ia0-f169.google.com (mail-ia0-f169.google.com [209.85.210.169]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4768FC17 for ; Fri, 21 Dec 2012 03:02:18 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id r4so3601695iaj.0 for ; Thu, 20 Dec 2012 19:02:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=NI9c28MRLU8hvCe1IOddCmkiEQ4uRkCQzn3b9fk4eMg=; b=cgmupi/ECK1+45kHWY4nYeKQhpSppS9nwHXz8c+DxdzOjPaMKcV4nMn3MFbBA4higf u3WW/9rRigaCFK89UyUkPhHdIgyFA8BJWZaxfu76f2fvVoQa3RBCxccG91oRrlXButB2 O8I8aHvpLlYbKnBkAf8Q2PiTveDqVgfc5beYPfEYt44VgAR7Mcaiojr9Z0EPnr6JsUsb oKznoXKv75lmJBAC/TR7WUI8uDPG+2bEBrcGcFpqyv9Z6Fp1z7OcN89E8F1KjM+kJ7Xb KKU1g2hPPAAnBwge4k8lnHt1U9v0uP28a0+Lpzm7O7fMAtVgBrkp+83ZsZOtb91Y5mUP rEBA== X-Received: by 10.50.91.230 with SMTP id ch6mr7534163igb.92.1356058931925; Thu, 20 Dec 2012 19:02:11 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id ez8sm8483198igb.17.2012.12.20.19.02.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 19:02:10 -0800 (PST) Sender: Warner Losh Subject: Re: nand performance Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1356051045.1198.329.camel@revolution.hippie.lan> Date: Thu, 20 Dec 2012 20:02:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1355964085.1198.255.camel@revolution.hippie.lan> <20121220200728.GK1563@funkthat.com> <1356051045.1198.329.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlkouuiOBxX30fGmLIgSP+d43CSA+xkSH1sbWXm+WBdyvITsr79oTce5igrIvvsZLjqhsVk Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 03:02:18 -0000 On Dec 20, 2012, at 5:50 PM, Ian Lepore wrote: > On Thu, 2012-12-20 at 12:07 -0800, John-Mark Gurney wrote: >> Ian Lepore wrote this message on Wed, Dec 19, 2012 at 17:41 -0700: >>> I've been working to get nandfs going on a low-end Atmel arm system. >>> Performance is horrible. Last weekend I got my nand-based DreamPlug >>> unbricked and got nandfs working on it too. Performance is = horrible. >>>=20 >>> By that I'm referring not to the slow nature of the nand chips >>> themselves, but to the fact that accessing them locks out userland >>> processes, sometimes for many seconds at a time. The problem is = real >>> easy to see, just format and populate a nandfs filesystem, then do >>> something like this >>>=20 >>> mount -r -t nandfs /dev/gnand0s.root /mnt >>> nice +20 find /mnt -type f | xargs -J% cat % > /dev/null >>>=20 >>> and then try to type in another terminal -- sometimes what you're = typing >>> doesn't get echoed for 10+ seconds a time. >>>=20 >>> The problem is that the "I/O" on a nand chip is really just the cpu >>> copying from one memory interface to another, a byte at a time, and = it >>> must also use busy-wait loops to wait for chip-ready and status = info. >>> This is being done by high-priority kernel threads, so everything = else >>> is locked out. >>>=20 >>> It seems to me that this is about the same situation as classic ATA = PIO >>> mode, but PIO doesn't make a system that unresponsive. =20 >>>=20 >>> I'm curious what techniques are used to migitate performance = problems >>> for ATA PIO modes, and whether we can do something similar for nand. = I >>> poked around a bit in dev/ata but the PIO code I saw (which surely >>> wasn't the whole picture) just used a bus_space_read_multi(). Can >>> someone clue me in as to how ATA manages to do PIO without usurping = the >>> whole system? >>=20 >> Looks like the problem is all the DELAY calls in = dev/nand/nand_generic.c.. >> DELAY is a busy wait not letting the cpu do anything else... The bad = one >> is probably generic_erase_block as it looks like the default is 3ms, >> plenty of time to let other code run... If it could be interrupt = driven, >> that'd be best... >>=20 >> I can't find the interface that would allow sub-hz sleeping, but = there is >> tsleep that could be used for some of the larger sleeps... But = switching >> to interrupts + wakeup would be best... >>=20 >=20 > Yeah, the DELAY() calls were actually not working for me (I think I'm > the first to test this stuff with an ONFI type chip), and I've = replaced > them all with loops that poll for ready status, which at least = minimizes > the wait time, but it's still a busy-loop. Real-world times for the > chips I'm working with are 30uS to open a page for read, ~270uS to = write > a page, and ~750uS to erase a block. You're the first one to use it with Intel or Micron NAND? I find that = kinda hard to believe given their ubiquity... But those times look about right for 3xnm parts... With newer parts, = according to published specifications, those times get longer. Expect = them to double over the next year (meaning through Intel/Micron's 20nm = parts now rolling out). Other NAND vendors have similar published specs, = or there's much public information about this. > But whether busy-looping for status or busy-looping polling a clock = for > DELAY, or transferring a byte at a time for the actual IO, it's all = the > same... it's cpu and memory bus cycles that are happening in a > high-priority kernel thread. =20 But usually the transfer goes quickly (a few microseconds with dedicated = hardware) compared to the waiting (tens or hundreds of microseconds). = The RM9200 doesn't have a dedicated NAND hardware, so byte-banging the = data to the device is the only choice... It looks like you'll also have to coordinate it with a number of GPIO = pins, which is good... That means you'll be able to have an interrupt = service the state change of the GPIO pins (well, you may need to augment = the current lame on AT91 gpio support that I wrote to allow for this). = But the NAND subsystem looks like it needs some support to do that... > The interface between the low-level controller and the nand layer > doesn't allow for interrupt handling right now. Not all hardware > designs would allow for using interrupts, but mine does, so reworking > things to allow its use would help some. Well, it would help for = writes > and erases. The 180mhz ARM I'm working with doesn't get much done in > 30uS, so reads wouldn't get any better. Reads are all I really care > about, since the product in the field will have a read-only = filesystem, > and firmware updates are infrequent and it's okay if they're a bit = slow. Any idea what the interrupt and scheduling delay runs these days on the = RM9200? It has been forever since I tried to measure it. You may be = able to signal a waiting process rather than using DELAY to busy wait = for things. But that likely means a thread of some sort to defer the = work once the chip returns done. Read might get better, from a system = load point of view, but maybe not from a performance point of view. = While 30us isn't a lot, you may find that your console performance goes = to hell with that long a block... Warner= From owner-freebsd-arm@FreeBSD.ORG Fri Dec 21 07:42:00 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76F4CEE2 for ; Fri, 21 Dec 2012 07:42:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id F2EDF8FC0A for ; Fri, 21 Dec 2012 07:41:59 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 356411420; Fri, 21 Dec 2012 08:41:57 +0100 From: Hans Petter Selasky To: Oleksandr Tymoshenko Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches Date: Fri, 21 Dec 2012 08:43:33 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201212201956.47884.hselasky@c2i.net> <50D3AAF1.80609@bluezbox.com> In-Reply-To: <50D3AAF1.80609@bluezbox.com> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212210843.33147.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 07:42:00 -0000 On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: > On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > > FYI - please test! > > > > ---------- Forwarded Message ---------- > > > > Subject: Re: EHCI on armv6 with Write-Back caches > > Date: Thursday 20 December 2012, 19:46:34 > > From: Hans Petter Selasky > > To: Warner Losh > > CC: Andrew Turner , Oleksandr Tymoshenko > > , freebsd-usb@freebsd.org, alfred@freebsd.org, > > freebsd- wireless@freebsd.org > > > > Hi, > > > > I've run some basic tests over here (x86) which passed after some patch > > modifications. Please test and verify for your ARM targets: > > > > http://svnweb.freebsd.org/changeset/base/244500 > > http://svnweb.freebsd.org/changeset/base/244503 > > > > Please also verify that upgt and uwrt and uath still works like expected. > > > > --HPS > > if_smsc fails with following diagnostics: > smsc0: error: allocating USB transfers failed > > The problem is that Bulk-In transfer buffer is 5 pages long but tag's > boundary limitation is > a page and it's impossible to allocate 5 pages without crossing page > boundary Hi, In the tag "nsegments" is 2 + size/PAGE_SIZE, so this is a bug in busdma! The boundary only tells where the segments should be split. --HPS From owner-freebsd-arm@FreeBSD.ORG Fri Dec 21 08:00:08 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97F40219 for ; Fri, 21 Dec 2012 08:00:08 +0000 (UTC) (envelope-from alie@affle.com) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx1.freebsd.org (Postfix) with ESMTP id 456A18FC17 for ; Fri, 21 Dec 2012 08:00:07 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id fw7so4778055vcb.17 for ; Fri, 21 Dec 2012 00:00:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=8eKxrAWwbcXuOs1V5gY29iAG3nTWWLLZNzbXeCGFA90=; b=Aa0bYe0tsXoLuWZu6Nf+eEzstJVyboIeMHlR5HEMwHUgaEaEQ/iBZ5+zFZVg7mGhbd oYAvAEzh6y5YkGRl0UDeNzLSDNkExGgc7qF3bdSdMsEhwic6F0Ni43rwssHZZVnDGMtZ 0CLKHnMawkIJxqJJnQtiBzaFtzwTDDJzwk3xswQlUZhzkhYf0EjX0RnNYBtUSabMDa5+ 6yHDPlSgAGAzLjevbSfE8vmglYqLhPL9i6F/PXEIWzr3NCrfN6iU6LPKYKNjbu990aHg whKnyYCZa10oPWMtfFQz6/hn1JxylFYsCLnr6+qs7x6NqipUGIcKxKZpKIXADMsjFDoZ vnPw== MIME-Version: 1.0 Received: by 10.52.21.107 with SMTP id u11mr16136342vde.101.1356076805651; Fri, 21 Dec 2012 00:00:05 -0800 (PST) Received: by 10.58.152.7 with HTTP; Fri, 21 Dec 2012 00:00:05 -0800 (PST) Date: Fri, 21 Dec 2012 16:00:05 +0800 Message-ID: Subject: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any port From: Alie Tan To: "freebsd-arm@freebsd.org" X-Gm-Message-State: ALoCoQnzpwSU/JnDl72B7j+7HLw5kgHeriFlXpJcFOtLm/+gwHtNCkfOajYS2014aP1oh149dBui Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 08:00:08 -0000 Hi, Anyone having hang issue while compiling any big port or portsnap fetch extract? Once hung, I cant SSH or press any key on keyboard anymore. Regards, Alie T From owner-freebsd-arm@FreeBSD.ORG Fri Dec 21 14:19:20 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69FAAD5C for ; Fri, 21 Dec 2012 14:19:20 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe03.c2i.net [212.247.154.66]) by mx1.freebsd.org (Postfix) with ESMTP id E8A158FC12 for ; Fri, 21 Dec 2012 14:19:19 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe03.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 193772516; Fri, 21 Dec 2012 15:19:11 +0100 From: Hans Petter Selasky To: Oleksandr Tymoshenko Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches Date: Fri, 21 Dec 2012 15:20:46 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201212201956.47884.hselasky@c2i.net> <50D3AAF1.80609@bluezbox.com> In-Reply-To: <50D3AAF1.80609@bluezbox.com> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201212211520.46822.hselasky@c2i.net> Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 14:19:20 -0000 On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: > On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > > FYI - please test! > > > > ---------- Forwarded Message ---------- > > > > Subject: Re: EHCI on armv6 with Write-Back caches > > Date: Thursday 20 December 2012, 19:46:34 > > From: Hans Petter Selasky > > To: Warner Losh > > CC: Andrew Turner , Oleksandr Tymoshenko > > , freebsd-usb@freebsd.org, alfred@freebsd.org, > > freebsd- wireless@freebsd.org > > > > Hi, > > > > I've run some basic tests over here (x86) which passed after some patch > > modifications. Please test and verify for your ARM targets: > > > > http://svnweb.freebsd.org/changeset/base/244500 > > http://svnweb.freebsd.org/changeset/base/244503 > > > > Please also verify that upgt and uwrt and uath still works like expected. > > > > --HPS > > if_smsc fails with following diagnostics: > smsc0: error: allocating USB transfers failed > > The problem is that Bulk-In transfer buffer is 5 pages long but tag's > boundary limitation is > a page and it's impossible to allocate 5 pages without crossing page > boundary Can you try again using this patch: http://svnweb.freebsd.org/changeset/base/244535 --HPS From owner-freebsd-arm@FreeBSD.ORG Sat Dec 22 00:06:04 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E94975A for ; Sat, 22 Dec 2012 00:06:04 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id D65AC8FC0A for ; Sat, 22 Dec 2012 00:06:03 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBM062J3039023 for ; Fri, 21 Dec 2012 17:06:02 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBM05xIl068099; Fri, 21 Dec 2012 17:06:00 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: nand performance From: Ian Lepore To: Warner Losh In-Reply-To: References: <1355964085.1198.255.camel@revolution.hippie.lan> <20121220200728.GK1563@funkthat.com> <1356051045.1198.329.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Dec 2012 17:05:59 -0700 Message-ID: <1356134759.1198.436.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 00:06:04 -0000 On Thu, 2012-12-20 at 20:02 -0700, Warner Losh wrote: > On Dec 20, 2012, at 5:50 PM, Ian Lepore wrote: > > > On Thu, 2012-12-20 at 12:07 -0800, John-Mark Gurney wrote: > >> Ian Lepore wrote this message on Wed, Dec 19, 2012 at 17:41 -0700: > >>> I've been working to get nandfs going on a low-end Atmel arm system. > >>> Performance is horrible. Last weekend I got my nand-based DreamPlug > >>> unbricked and got nandfs working on it too. Performance is horrible. > >>> > >>> By that I'm referring not to the slow nature of the nand chips > >>> themselves, but to the fact that accessing them locks out userland > >>> processes, sometimes for many seconds at a time. The problem is real > >>> easy to see, just format and populate a nandfs filesystem, then do > >>> something like this > >>> > >>> mount -r -t nandfs /dev/gnand0s.root /mnt > >>> nice +20 find /mnt -type f | xargs -J% cat % > /dev/null > >>> > >>> and then try to type in another terminal -- sometimes what you're typing > >>> doesn't get echoed for 10+ seconds a time. > >>> > >>> The problem is that the "I/O" on a nand chip is really just the cpu > >>> copying from one memory interface to another, a byte at a time, and it > >>> must also use busy-wait loops to wait for chip-ready and status info. > >>> This is being done by high-priority kernel threads, so everything else > >>> is locked out. > >>> > >>> It seems to me that this is about the same situation as classic ATA PIO > >>> mode, but PIO doesn't make a system that unresponsive. > >>> > >>> I'm curious what techniques are used to migitate performance problems > >>> for ATA PIO modes, and whether we can do something similar for nand. I > >>> poked around a bit in dev/ata but the PIO code I saw (which surely > >>> wasn't the whole picture) just used a bus_space_read_multi(). Can > >>> someone clue me in as to how ATA manages to do PIO without usurping the > >>> whole system? > >> > >> Looks like the problem is all the DELAY calls in dev/nand/nand_generic.c.. > >> DELAY is a busy wait not letting the cpu do anything else... The bad one > >> is probably generic_erase_block as it looks like the default is 3ms, > >> plenty of time to let other code run... If it could be interrupt driven, > >> that'd be best... > >> > >> I can't find the interface that would allow sub-hz sleeping, but there is > >> tsleep that could be used for some of the larger sleeps... But switching > >> to interrupts + wakeup would be best... > >> > > > > Yeah, the DELAY() calls were actually not working for me (I think I'm > > the first to test this stuff with an ONFI type chip), and I've replaced > > them all with loops that poll for ready status, which at least minimizes > > the wait time, but it's still a busy-loop. Real-world times for the > > chips I'm working with are 30uS to open a page for read, ~270uS to write > > a page, and ~750uS to erase a block. > > You're the first one to use it with Intel or Micron NAND? I find that kinda hard to believe given their ubiquity... > Yep, I'm certain of it. The code to detect an onfi part is wrong (it looks for "onfi" rather than "ONFI"), and the code to read and parse the onfi data doesn't deal with endianess, packing, and alignment. I have patches, but I need to review all my XXXes and tidy things up. > But those times look about right for 3xnm parts... With newer parts, according to published specifications, those times get longer. Expect them to double over the next year (meaning through Intel/Micron's 20nm parts now rolling out). Other NAND vendors have similar published specs, or there's much public information about this. > > > But whether busy-looping for status or busy-looping polling a clock for > > DELAY, or transferring a byte at a time for the actual IO, it's all the > > same... it's cpu and memory bus cycles that are happening in a > > high-priority kernel thread. > > But usually the transfer goes quickly (a few microseconds with dedicated hardware) compared to the waiting (tens or hundreds of microseconds). The RM9200 doesn't have a dedicated NAND hardware, so byte-banging the data to the device is the only choice... > It's more than a few microseconds. The base speed on the Micron parts we're using is a 10mhz bus, so that's ~400uS to transfer a page. The part can be told to run as fast as 40mhz (and oddly, I find that I can just set the wait states to run almost that fast without telling the chip I intend to do so, and it works just fine), but even so the page xfer is ~100uS. The Marvell chips also require the cpu to do all the data movement, so the only two types of hardware I have to test with have the same responsiveness problems. Given how easy it is to implement nand access in a SoC by sharing the regular memory data bus lines and using a couple address lines for ALE/CLE, there are probably plenty of others that'll work the same. > It looks like you'll also have to coordinate it with a number of GPIO pins, which is good... That means you'll be able to have an interrupt service the state change of the GPIO pins (well, you may need to augment the current lame on AT91 gpio support that I wrote to allow for this). But the NAND subsystem looks like it needs some support to do that... > Yeah, that's what I was alluding to earlier. There's an unused function now to read the RB# line but that doesn't really buy much (which is probably why the middle layer doesn't ever call it). It would be better if there were a function that could wait for a change in RB#, but it would have to be optional to implement, because it isn't really required to make the hardware work and you could envision systems where getting an interrupt on RB# change just isn't possible. > > The interface between the low-level controller and the nand layer > > doesn't allow for interrupt handling right now. Not all hardware > > designs would allow for using interrupts, but mine does, so reworking > > things to allow its use would help some. Well, it would help for writes > > and erases. The 180mhz ARM I'm working with doesn't get much done in > > 30uS, so reads wouldn't get any better. Reads are all I really care > > about, since the product in the field will have a read-only filesystem, > > and firmware updates are infrequent and it's okay if they're a bit slow. > > Any idea what the interrupt and scheduling delay runs these days on the RM9200? It has been forever since I tried to measure it. You may be able to signal a waiting process rather than using DELAY to busy wait for things. But that likely means a thread of some sort to defer the work once the chip returns done. Read might get better, from a system load point of view, but maybe not from a performance point of view. While 30us isn't a lot, you may find that your console performance goes to hell with that long a block... > > Warner I also haven't measured interrupt latency for quite a while. In fact, since the freebsd 6.2 days. One thing I have measured recently is syscall performance... calling getpid() on an rm9200 takes 7 to 9 microseconds. IMO, that's crazy-long, but that's a problem for another day. But that's the kind of thing that makes me a bit skeptical that trying to buy back 30uS while waiting for a read page-open is going to restore a lot of responsiveness to userland apps. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Dec 22 00:58:24 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9651188 for ; Sat, 22 Dec 2012 00:58:24 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id EC4EA8FC0C for ; Sat, 22 Dec 2012 00:58:23 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBM0wGYx039608 for ; Fri, 21 Dec 2012 17:58:16 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBM0wElg068125; Fri, 21 Dec 2012 17:58:14 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches From: Ian Lepore To: Hans Petter Selasky In-Reply-To: <201212210843.33147.hselasky@c2i.net> References: <201212201956.47884.hselasky@c2i.net> <50D3AAF1.80609@bluezbox.com> <201212210843.33147.hselasky@c2i.net> Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Dec 2012 17:58:14 -0700 Message-ID: <1356137894.1198.454.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 00:58:25 -0000 On Fri, 2012-12-21 at 08:43 +0100, Hans Petter Selasky wrote: > On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: > > On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > > > FYI - please test! > > > > > > ---------- Forwarded Message ---------- > > > > > > Subject: Re: EHCI on armv6 with Write-Back caches > > > Date: Thursday 20 December 2012, 19:46:34 > > > From: Hans Petter Selasky > > > To: Warner Losh > > > CC: Andrew Turner , Oleksandr Tymoshenko > > > , freebsd-usb@freebsd.org, alfred@freebsd.org, > > > freebsd- wireless@freebsd.org > > > > > > Hi, > > > > > > I've run some basic tests over here (x86) which passed after some patch > > > modifications. Please test and verify for your ARM targets: > > > > > > http://svnweb.freebsd.org/changeset/base/244500 > > > http://svnweb.freebsd.org/changeset/base/244503 > > > > > > Please also verify that upgt and uwrt and uath still works like expected. > > > > > > --HPS > > > > if_smsc fails with following diagnostics: > > smsc0: error: allocating USB transfers failed > > > > The problem is that Bulk-In transfer buffer is 5 pages long but tag's > > boundary limitation is > > a page and it's impossible to allocate 5 pages without crossing page > > boundary > > Hi, > > In the tag "nsegments" is 2 + size/PAGE_SIZE, so this is a bug in busdma! > > The boundary only tells where the segments should be split. I think you're right. It looks like the arm busdma implemenation would try (and fail) to allocate multiple pages that don't cross a page boundary instead of allocating what I think your tags ask for if I'm reading the usb code correctly: a collection of segments that are each a maximum of one page long and don't cross a page boundary. When I reworked the arm allocation logic I closely modeled it after what jhb@ recently did to the x86 busdma; it looks like it would behave the same. The powerpc and mips implementations look more like the historic arm code, and look like they would get it wrong using different logic. The manpage says that the tag passed to bus_dmamem_alloc() contains the mapping (not the allocation) constraints. It also says that all allocations are done as a single segment -- a statement I've always considered to be just out of date, not as establishing part of the usage contract for the function. The question now is whether the code can always do the right thing with every possible combination of memattr, alignment, exclusion window, numsegs, maxsegsize, and boundary. Maybe that's why the manpage doesn't explicitly nail down the requirement to honor the tag for allocation. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sat Dec 22 08:23:48 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 299E6B11 for ; Sat, 22 Dec 2012 08:23:48 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id D9D378FC13 for ; Sat, 22 Dec 2012 08:23:47 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id qBM8Ndi0045478; Sat, 22 Dec 2012 08:23:39 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 4bm963j7bw9azvsckf2nysx3us; Sat, 22 Dec 2012 08:23:39 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: FreeBSD10-CURRENT r244480 hang while compiling lighttpd or any port Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Sat, 22 Dec 2012 00:23:39 -0800 Content-Transfer-Encoding: 7bit Message-Id: <6FC3E540-DEBD-4763-BB46-13F3422508E9@kientzle.com> References: To: Alie Tan X-Mailer: Apple Mail (2.1283) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 08:23:48 -0000 On Dec 21, 2012, at 12:00 AM, Alie Tan wrote: > > Anyone having hang issue while compiling any big port or portsnap fetch > extract? On what system? Tim From owner-freebsd-arm@FreeBSD.ORG Sat Dec 22 14:22:45 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90748EB9; Sat, 22 Dec 2012 14:22:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 287A28FC0A; Sat, 22 Dec 2012 14:22:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBMEMUNE073377; Sat, 22 Dec 2012 16:22:30 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBMEMUNE073377 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBMEMUZ7073376; Sat, 22 Dec 2012 16:22:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 22 Dec 2012 16:22:30 +0200 From: Konstantin Belousov To: Jeff Roberson Subject: Re: Call for testing and review, busdma changes Message-ID: <20121222142230.GU53644@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pzbqGaOtRNiVr7w4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home X-Mailman-Approved-At: Sat, 22 Dec 2012 14:46:04 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 14:22:45 -0000 --pzbqGaOtRNiVr7w4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 08, 2012 at 08:51:12AM -1000, Jeff Roberson wrote: > Hello, >=20 > http://people.freebsd.org/~jeff/physbio.diff >=20 > I have a relative large patch that reforms the busdma API so that new=20 > types may be added without modifying every architecture's=20 > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer()= =20 > routines so that they may be called from MI code. The MD busdma is then= =20 > given a chance to do any final processing in the complete() callback.=20 > This patch also contains cam changes to unify the bus_dmamap_load*=20 > handling in cam drivers. >=20 > The arm and mips implementations saw the largest changes since they have= =20 > to track virtual addresses for sync(). Previously this was done in a typ= e=20 > specific way. Now it is done in a generic way by recording the list of= =20 > virtuals in the map. >=20 > I have verified that this patch passes make universe which includes=20 > several kernel builds from each architecture. I suspect that if I broke= =20 > anything your machine simply won't boot or will throw I/O errors. There= =20 > is little subtlety, it is mostly refactoring. >=20 > The next step is to allow for dma loading of physical addresses. This=20 > will permit unmapped I/O. Which is a significant performance optimizatio= n=20 > targeted for 10.0. >=20 > Many thanks for your assistance. Any review feedback is also appreciated. I re-read the patch with the scars from the unmapped buffers work somewhat healed up, and I noted something I do not quite understand. As an example, please look at the sys/cam/ata/ata_da.c:adastart(). The code there takes bp and converts in into ccb with ataio union member used. Should this code path be converted, together with e.g. ahci_begin_transaction(), to operate on ccb instead of loading from the buffer ? The same question for ata. Was the change missed, or do you have some other plans for the drivers ? --pzbqGaOtRNiVr7w4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ1cIlAAoJEJDCuSvBvK1BFQAP/iuogDJUm1Ic80g20ZLhSz3M 9Pmb6NXMB0pFCRXy+gWMnMy/Rccf1fJlVtC8cxRxQZLJxOyur/RdrN4PTzdr4HtA gEBk2wnKtyXLTLHgKZcGhMoI62lwxgTJMXz8yK4S3DpmmA2URsLRrqgmWRw1MMdK +fKrhthaedPDFgvcJU0BwJjNoyiMod7LabqmuJr32PC2wtvAQH/sXBILk9qp1lXl xNgAhduvUF7n6d61qRELx1DVQkU3xWjVf8NiA3VqTDbCRrSrFBGdwJZKMSIyqDy/ Q2gUYegpd7QkEKzHt4u8O3sn2Um1XpC86/YfBMNMI28wDZjtijsOgx+RiykJHEiM tvTcQCS7dXo696nXEEKkw9607GU0KAKamtyIGSMz3qUE9PKTFcfR3BVoj7ikrJDq LFiODjF+wCpJ9MtIWJPjWfpVOicl7mkedu6U2HZ7ABIUltusqHZTYW2yEtJSle/e QjDPcfgGdPKtjaKSfd4bCfNqe0mLHtAThJmV/dX1Nx+43aGBmCJ8qWjDkmBJG5Uw su+KSsQ/q+T0QEvUSwDrVUaTJ7PSRctc6MnLMJcUt5VRwHJ8NArIxe6YapMNOlS6 D0MIMcsIt1B0qgvXyGYiTiF564lM0bgqAzRWcragvxYOd6cixWqNBV7qmjkdySch Ysf8ToRRocS2b92/i/8N =GTYI -----END PGP SIGNATURE----- --pzbqGaOtRNiVr7w4-- From owner-freebsd-arm@FreeBSD.ORG Sat Dec 22 23:06:17 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 81BB8BB0 for ; Sat, 22 Dec 2012 23:06:17 +0000 (UTC) (envelope-from iz-rpi03@hs-karlsruhe.de) Received: from smtp.hs-karlsruhe.de (smtp.HS-Karlsruhe.DE [193.196.64.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3E06D8FC0A for ; Sat, 22 Dec 2012 23:06:17 +0000 (UTC) Received: from iz-wera01.hs-karlsruhe.de ([193.196.65.46]) by smtp.hs-karlsruhe.de with esmtp (Exim 4.80.1) (envelope-from ) id 1TmY92-0066I4-A8; Sun, 23 Dec 2012 00:06:16 +0100 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 From: Ralf Wenk To: Hans Petter Selasky Subject: Re: Fwd: Re: EHCI on armv6 with Write-Back caches In-reply-to: <201212211520.46822.hselasky@c2i.net> References: <201212201956.47884.hselasky@c2i.net> <50D3AAF1.80609@bluezbox.com> <201212211520.46822.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Dec 2012 00:06:04 +0100 Message-Id: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Dec 2012 23:06:17 -0000 > On Friday 21 December 2012 01:18:57 Oleksandr Tymoshenko wrote: > > On 12/20/2012 10:56 AM, Hans Petter Selasky wrote: > > > FYI - please test! > > > > > > ---------- Forwarded Message ---------- > > > > > > Subject: Re: EHCI on armv6 with Write-Back caches > > > Date: Thursday 20 December 2012, 19:46:34 > > > From: Hans Petter Selasky > > > To: Warner Losh > > > CC: Andrew Turner , Oleksandr Tymoshenko > > > , freebsd-usb@freebsd.org, alfred@freebsd.org, > > > freebsd- wireless@freebsd.org > > > > > > Hi, > > > > > > I've run some basic tests over here (x86) which passed after some patch > > > modifications. Please test and verify for your ARM targets: > > > > > > http://svnweb.freebsd.org/changeset/base/244500 > > > http://svnweb.freebsd.org/changeset/base/244503 > > > > > > Please also verify that upgt and uwrt and uath still works like expected. > > > > > > --HPS > > > > if_smsc fails with following diagnostics: > > smsc0: error: allocating USB transfers failed > > > > The problem is that Bulk-In transfer buffer is 5 pages long but tag's > > boundary limitation is > > a page and it's impossible to allocate 5 pages without crossing page > > boundary > > Can you try again using this patch: > > http://svnweb.freebsd.org/changeset/base/244535 Since revision 244503 I get an error after inserting an USB-stick in about 50% of the cases. The problem is still there with revision 244535. My latest test was with revision 244582. The kernel messages are: root@raspberry-pi:~ # ugen0.4: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 umass0:0:0:-1: Attached to scbus0 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted ugen0.4: at usbus0 (disconnected) umass0: at uhub1, port 3, addr 4 (disconnected) When things go well they are: root@raspberry-pi:~ # ugen0.4: at usbus0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x4101 umass0:0:0:-1: Attached to scbus0 root@raspberry-pi:~ # da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3817MB (7818240 512 byte sectors: 255H 63S/T 486C) But even then there is something wrong now: root@raspberry-pi:~ # gpart show da0 => 34 7818173 da0 GPT (3.7G) 34 2097152 1 freebsd-ufs (1.0G) 2097186 5721021 - free - (2.7G) root@raspberry-pi:~ # mount /dev/da0p1 /mnt g_vfs_done():da0p1[READ(offset=65536, length=8192)]error = 6 mount: /dev/da0p1: Device not configured I am using a RPI-B kernel configuration with serial boot console and added options MSDOSFS and GEOM_PART_GPT. With older revisions they worked. The USB-stick is OK. I verified that with my PC. Ralf