From owner-freebsd-arm@FreeBSD.ORG Sun May 13 07:24:46 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 B5B0B1065670; Sun, 13 May 2012 07:24:46 +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 6F81B8FC08; Sun, 13 May 2012 07:24:45 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4D7HLRv079525; Sun, 13 May 2012 07:17:21 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id af4meg9v63azpsdbvu9kdk27tn; Sun, 13 May 2012 07:17:21 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: Date: Sun, 13 May 2012 00:17:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> To: Tim Kientzle X-Mailer: Apple Mail (2.1257) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 07:24:46 -0000 On May 12, 2012, at 4:36 PM, Tim Kientzle wrote: >=20 > On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote: >=20 >> On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>>=20 >>> On the AM3358, the DRAM starts at 0x8000 0000 >>> on boot, so I'm trying to find a clean way to convince >>> the loader's ELF code to put the kernel there. >>=20 >> Look at what I did for ia64. All that frobbing should be done >> in the machine specific implementation of arch_copyin, arch_copyout >> and arch_readin. It's a kluge to do it in elf_loadimage. >=20 > That sounds like a reasonable approach. I've started > working down that path=85 but it looks like I'll have to fix > a lot of the FDT code along the way. I'm getting close. In particular, I've reworked the FDT code so that it correctly uses copyout() to parse data in the kernel. Of course, in order to use libfdt to actually manipulate the device tree, I have to copyout() the entire blob into a malloc'ed buffer. So now I need to understand how to copyin() the blob back into the kernel address space. Should I overwrite the FDT in the kernel with the edited FDT? That doesn't feel quite right, but it's essentially what the FDT code here was trying to do before. I could also implement something similar to file_loadraw() that would allow me to create a new module from an in-memory buffer. I think that might be a little cleaner. Is there already something like this? Tim From owner-freebsd-arm@FreeBSD.ORG Mon May 14 08:50:01 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 97C001065672; Mon, 14 May 2012 08:50:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6497E8FC08; Mon, 14 May 2012 08:50:01 +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 q4E8nstk053648; Mon, 14 May 2012 04:49:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4E8nscn053644; Mon, 14 May 2012 08:49:54 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 14 May 2012 08:49:54 GMT Message-Id: <201205140849.q4E8nscn053644@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 08:50:01 -0000 TB --- 2012-05-14 08:10:01 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-14 08:10:01 - 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-05-14 08:10:01 - starting HEAD tinderbox run for arm/arm TB --- 2012-05-14 08:10:01 - cleaning the object tree TB --- 2012-05-14 08:10:01 - cvsupping the source tree TB --- 2012-05-14 08:10:01 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-05-14 08:12:13 - building world TB --- 2012-05-14 08:12:13 - CROSS_BUILD_TESTING=YES TB --- 2012-05-14 08:12:13 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-14 08:12:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-14 08:12:13 - SRCCONF=/dev/null TB --- 2012-05-14 08:12:13 - TARGET=arm TB --- 2012-05-14 08:12:13 - TARGET_ARCH=arm TB --- 2012-05-14 08:12:13 - TZ=UTC TB --- 2012-05-14 08:12:13 - __MAKE_CONF=/dev/null TB --- 2012-05-14 08:12:13 - cd /src TB --- 2012-05-14 08:12:13 - /usr/bin/make -B buildworld >>> World build started on Mon May 14 08:12:13 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 [...] if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3pcap ]; then F=pcap_is_swapped.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_is_swapped.3 ]; then F=pcap_is_swapped.3; else F=pcap_is_swapped.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_is_swapped.3 gzip -cn pcap_is_swapped.3 > pcap_is_swapped.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3pcap ]; then F=pcap_lib_version.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_lib_version.3 ]; then F=pcap_lib_version.3; else F=pcap_lib_version.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_lib_version.3 gzip -cn pcap_lib_version.3 > pcap_lib_version.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3pcap ]; then F=pcap_list_datalinks.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_datalinks.3 ]; then F=pcap_list_datalinks.3; else F=pcap_list_datalinks.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_datalinks.3 gzip -cn pcap_list_datalinks.3 > pcap_list_datalinks.3.gz if [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3pcap ]; then F=pcap_list_tstamp_types.3pcap; elif [ -f /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3 ]; then F=pcap_list_tstamp_types.3; else F=pcap_list_tstamp_types.3; fi; sed -e 's/3PCAP/3/g' /src/lib/libpcap/../../contrib/libpcap/$F > pcap_list_tstamp_types.3 sed: /src/lib/libpcap/../../contrib/libpcap/pcap_list_tstamp_types.3: No such file or directory *** Error code 1 Stop in /src/lib/libpcap. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-14 08:49:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-14 08:49:54 - ERROR: failed to build world TB --- 2012-05-14 08:49:54 - 1430.11 user 379.14 system 2393.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon May 14 11:07: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 BA0AB1065798 for ; Mon, 14 May 2012 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A34E38FC16 for ; Mon, 14 May 2012 11:07:07 +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 q4EB77X6053199 for ; Mon, 14 May 2012 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4EB77fU053197 for freebsd-arm@FreeBSD.org; Mon, 14 May 2012 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 May 2012 11:07:07 GMT Message-Id: <201205141107.q4EB77fU053197@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 11:07:07 -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/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/160431 arm [busdma] [patch] Disable interrupts during busdma cach o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156496 arm [patch] Minor bugfixes and enhancements to mmc and mmc o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o 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/154189 arm lang/perl5.12 doesn't build on arm o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 17 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon May 14 19:23: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 931C0106566B for ; Mon, 14 May 2012 19:23:18 +0000 (UTC) (envelope-from fredrik.siken@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 529B08FC0A for ; Mon, 14 May 2012 19:23:18 +0000 (UTC) Received: by yenl8 with SMTP id l8so5908707yen.13 for ; Mon, 14 May 2012 12:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ugUrn12NOshwjIisw/wfCh6OTXCptmm12PN1R/gLsr4=; b=APL/eSeT9vdRHpbZkcIv+WI47GtrM7Wdeu+VGTa1IMzKhkXS+R7hisbg4IJ4HOQOf1 ryNpd9PspLQ2Qyi5DopTe5kXaZ1Mkli4CK7tnarRuv2eQqUEcGZOrXwq8A/O2TL1Kj7q fjiNUTkvE6rCB9u21SVB69CYGUHAnJlq/9NJo9z0iwSGplm1mNTZZlpX1N/5oHce0zS1 TibnVlyyxQPrtqAR2jbFcQNFiet/pOK6CXoyaoKeaRoJtKqVJfjG7rtmuymfnYNB0+P8 DVwNBWihSzVNyVmcVo9F/b49nvp5YiVpEf71Hm5s0t4JgPzz8dqaFmrW+MMIfzk39G3x fv3g== MIME-Version: 1.0 Received: by 10.50.17.169 with SMTP id p9mr168990igd.60.1337023391783; Mon, 14 May 2012 12:23:11 -0700 (PDT) Received: by 10.50.91.131 with HTTP; Mon, 14 May 2012 12:23:11 -0700 (PDT) Date: Mon, 14 May 2012 21:23:11 +0200 Message-ID: From: =?ISO-8859-1?Q?Fredrik_Sik=E9n?= To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: 13x longer execution times before remount X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:23:18 -0000 Hi, I've an 8.2-Release running on an ARM with poor execution performance before a remount is performed. The scenario is as follows 0) I mount an UFS SSD disk # mount -o noclusterr -o noclusterw /dev/ad0s1 /mnt/ 1) I copy an executable to an UFS mounted SSD disk and measure its time of execution from start to stop 2) I remount the system (umount/mount) 3) I perform the same steps as in 1) but now with a performance increase of 13x Other tests performed: - Tested on a UFS USB stick with the same behaviour - Tested to write to an NFS mounted disk and this gives the expected behaviour - the same time before and after a remount. - Running the same version on a x86 gives the expected behaviour - the same time before and after a remount. Results after file is copied but before a remount # time ./test 10000 1000000 size = 10000, no = 1000000 133.000u 0.000s 2:13.53 99.8% 3282+18575k 0+0io 0pf+0w Results after a remount # time ./test 10000 1000000 size = 10000, no = 1000000 7.000u 0.000s 0:07.82 99.8% 3286+18595k 0+0io 0pf+0w The test application source looks like this #include #include #include int main(int argc, char **argv) { int size = atoi(argv[1]); int no = atoi(argv[2]); printf("size = %d, no = %d\n", size, no); { int i; for(i = 0 ; i Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E4281065744 for ; Mon, 14 May 2012 19:37:47 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 7104C8FC1A for ; Mon, 14 May 2012 19:37:47 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 9vZt1j0091GXsucA1vdnGs; Mon, 14 May 2012 19:37:47 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta07.emeryville.ca.mail.comcast.net with comcast id 9vdm1j00D4NgCEG8Uvdmpc; Mon, 14 May 2012 19:37:47 +0000 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 q4EJbioD094467; Mon, 14 May 2012 13:37:44 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Fredrik =?ISO-8859-1?Q?Sik=E9n?= In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" Date: Mon, 14 May 2012 13:37:44 -0600 Message-ID: <1337024264.1503.73.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-arm@freebsd.org Subject: Re: 13x longer execution times before remount X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:37:47 -0000 On Mon, 2012-05-14 at 21:23 +0200, Fredrik Sikn wrote: > Hi, > > I've an 8.2-Release running on an ARM with poor execution performance > before a remount is performed. > > The scenario is as follows > > 0) I mount an UFS SSD disk > # mount -o noclusterr -o noclusterw /dev/ad0s1 /mnt/ > > 1) I copy an executable to an UFS mounted SSD disk and measure its > time of execution from start to stop > > 2) I remount the system (umount/mount) > > 3) I perform the same steps as in 1) but now with a performance increase of 13x > > Other tests performed: > - Tested on a UFS USB stick with the same behaviour > - Tested to write to an NFS mounted disk and this gives the expected > behaviour - the same time before and after a remount. > - Running the same version on a x86 gives the expected behaviour - the > same time before and after a remount. > > Results after file is copied but before a remount > # time ./test 10000 1000000 > size = 10000, no = 1000000 > 133.000u 0.000s 2:13.53 99.8% 3282+18575k 0+0io 0pf+0w > > Results after a remount > # time ./test 10000 1000000 > size = 10000, no = 1000000 > 7.000u 0.000s 0:07.82 99.8% 3286+18595k 0+0io 0pf+0w > > The test application source looks like this > #include > #include > #include > > int main(int argc, char **argv) { > > int size = atoi(argv[1]); > int no = atoi(argv[2]); > printf("size = %d, no = %d\n", size, no); > > { > int i; > > for(i = 0 ; i char *p = malloc(size); > memset(p, 0, size); > free(p); > } > } > } > > Thanks, > Fredrik More info on this problem and a potential workaround (not ideal, but we've been living with it) can be found here: http://lists.freebsd.org/pipermail/freebsd-arm/2012-January/003288.html http://lists.freebsd.org/pipermail/freebsd-arm/2012-February/003296.html - Ian From owner-freebsd-arm@FreeBSD.ORG Tue May 15 08:09:52 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 50657106566B; Tue, 15 May 2012 08:09:52 +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 1838F8FC0A; Tue, 15 May 2012 08:09:51 +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 q4F89ouW055276; Tue, 15 May 2012 04:09:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id q4F89o3s055275; Tue, 15 May 2012 08:09:50 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 15 May 2012 08:09:50 GMT Message-Id: <201205150809.q4F89o3s055275@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 08:09:52 -0000 TB --- 2012-05-15 07:00:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-15 07:00: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-05-15 07:00:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-05-15 07:00:00 - cleaning the object tree TB --- 2012-05-15 07:00:00 - cvsupping the source tree TB --- 2012-05-15 07:00:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-05-15 07:02:23 - building world TB --- 2012-05-15 07:02:23 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 07:02:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 07:02:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 07:02:23 - SRCCONF=/dev/null TB --- 2012-05-15 07:02:23 - TARGET=arm TB --- 2012-05-15 07:02:23 - TARGET_ARCH=arm TB --- 2012-05-15 07:02:23 - TZ=UTC TB --- 2012-05-15 07:02:23 - __MAKE_CONF=/dev/null TB --- 2012-05-15 07:02:23 - cd /src TB --- 2012-05-15 07:02:23 - /usr/bin/make -B buildworld >>> World build started on Tue May 15 07:02:24 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 May 15 08:08:08 UTC 2012 TB --- 2012-05-15 08:08:08 - cd /src/sys/arm/conf TB --- 2012-05-15 08:08:08 - /usr/sbin/config -m AVILA TB --- 2012-05-15 08:08:08 - building AVILA kernel TB --- 2012-05-15 08:08:08 - CROSS_BUILD_TESTING=YES TB --- 2012-05-15 08:08:08 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-15 08:08:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-15 08:08:08 - SRCCONF=/dev/null TB --- 2012-05-15 08:08:08 - TARGET=arm TB --- 2012-05-15 08:08:08 - TARGET_ARCH=arm TB --- 2012-05-15 08:08:08 - TZ=UTC TB --- 2012-05-15 08:08:08 - __MAKE_CONF=/dev/null TB --- 2012-05-15 08:08:08 - cd /src TB --- 2012-05-15 08:08:08 - /usr/bin/make -B buildkernel KERNCONF=AVILA >>> Kernel build for AVILA started on Tue May 15 08:08:08 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 [...] /src/sys/kern/sched_4bsd.c: In function 'sched_add': /src/sys/kern/sched_4bsd.c:1350: warning: implicit declaration of function 'STD_PROBE4' /src/sys/kern/sched_4bsd.c:1350: warning: nested extern declaration of 'STD_PROBE4' [-Wnested-externs] /src/sys/kern/sched_4bsd.c:1350: error: 'sched' undeclared (first use in this function) /src/sys/kern/sched_4bsd.c:1350: error: (Each undeclared identifier is reported only once /src/sys/kern/sched_4bsd.c:1350: error: for each function it appears in.) /src/sys/kern/sched_4bsd.c:1350: error: expected expression before ',' token /src/sys/kern/sched_4bsd.c:1350: error: 'enqueue' undeclared (first use in this function) *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-05-15 08:09:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-05-15 08:09:50 - ERROR: failed to build AVILA kernel TB --- 2012-05-15 08:09:50 - 2505.58 user 570.33 system 4190.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue May 15 11:53:31 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E351E1065673 for ; Tue, 15 May 2012 11:53:31 +0000 (UTC) (envelope-from thomas.fabien@gmail.com) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id A693E8FC08 for ; Tue, 15 May 2012 11:53:30 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id 72D1C27042CB for ; Tue, 15 May 2012 13:55:06 +0200 (CEST) From: Fabien Thomas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 15 May 2012 13:53:28 +0200 Message-Id: <7D3480C9-BFD0-416C-8A65-C31BFE5E093A@gmail.com> To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: RFC: hwpmc soft arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Fabien Thomas List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 11:53:32 -0000 Hi, This patch add sampling support for arm using soft PMC. At this time only with one level (no backtrace), i'm planning to add it with ddb code as a base but if some arm guru can give me some pointer it = will help. The patch is tested on 8.3 but should works on head. patch: http://freebsd.org/~fabient/patch-hwpmc_arm_rev1 add to your kernel conf: options HWPMC_HOOKS device hwpmc # can be added as a module options DEVICE_POLLING sample capture during buildworld: kldload hwpmc # if build as a module pmcstat -Sclock.hard -T -w4 http://freebsd.org/~fabient/pmc_arm.png Fabien= From owner-freebsd-arm@FreeBSD.ORG Tue May 15 12:38: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 53695106564A; Tue, 15 May 2012 12:38:08 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) by mx1.freebsd.org (Postfix) with ESMTP id DEBC98FC0A; Tue, 15 May 2012 12:38:07 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id q4FCbiIj047855; Tue, 15 May 2012 14:37:44 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id q4FCbinj047854; Tue, 15 May 2012 14:37:44 +0200 (CEST) (envelope-from mlfbsd) Date: Tue, 15 May 2012 14:37:44 +0200 From: mlfbsd To: Fabien Thomas Message-ID: <20120515123743.GA47838@ci0.org> References: <7D3480C9-BFD0-416C-8A65-C31BFE5E093A@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D3480C9-BFD0-416C-8A65-C31BFE5E093A@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-arm@freebsd.org Subject: Re: RFC: hwpmc soft arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 12:38:08 -0000 On Tue, May 15, 2012 at 01:53:28PM +0200, Fabien Thomas wrote: > Hi, > > This patch add sampling support for arm using soft PMC. > At this time only with one level (no backtrace), i'm planning to add it > with ddb code as a base but if some arm guru can give me some pointer it will help. > > The patch is tested on 8.3 but should works on head. > > patch: > http://freebsd.org/~fabient/patch-hwpmc_arm_rev1 > Hi Fabien, It seems fine, I see nothing wrong in this patch. Backtrace support should be easy to add. Thanks a lot for working on this ! Regards, Olivier From owner-freebsd-arm@FreeBSD.ORG Tue May 15 16:38:52 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E13221065674; Tue, 15 May 2012 16:38:51 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 5AA068FC17; Tue, 15 May 2012 16:38:51 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 9984FC4B2C; Tue, 15 May 2012 18:38:40 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id TkaZKmfC+lE9; Tue, 15 May 2012 18:38:39 +0200 (CEST) Received: from [10.0.0.22] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id BE14AC4B12; Tue, 15 May 2012 18:38:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Rafal Jaworowski In-Reply-To: <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> Date: Tue, 15 May 2012 18:38:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1084) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 16:38:52 -0000 On 2012-05-13, at 09:17, Tim Kientzle wrote: > On May 12, 2012, at 4:36 PM, Tim Kientzle wrote: >>=20 >> On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote: >>=20 >>> On May 8, 2012, at 1:32 AM, Tim Kientzle wrote: >>>>=20 >>>> On the AM3358, the DRAM starts at 0x8000 0000 >>>> on boot, so I'm trying to find a clean way to convince >>>> the loader's ELF code to put the kernel there. >>>=20 >>> Look at what I did for ia64. All that frobbing should be done >>> in the machine specific implementation of arch_copyin, arch_copyout >>> and arch_readin. It's a kluge to do it in elf_loadimage. >>=20 >> That sounds like a reasonable approach. I've started >> working down that path=85 but it looks like I'll have to fix >> a lot of the FDT code along the way. >=20 > I'm getting close. In particular, I've reworked the FDT code > so that it correctly uses copyout() to parse data in the > kernel. Of course, in order to use libfdt to actually > manipulate the device tree, I have to copyout() the > entire blob into a malloc'ed buffer. >=20 > So now I need to understand how to copyin() the > blob back into the kernel address space. >=20 > Should I overwrite the FDT in the kernel with the > edited FDT? That doesn't feel quite right, but it's > essentially what the FDT code here was trying to > do before. >=20 > I could also implement something similar to file_loadraw() > that would allow me to create a new module from an > in-memory buffer. I think that might be a little cleaner. >=20 > Is there already something like this? A given DTB (loaded dynamically or statically embedded in the kernel) = has some small amount of free space inside it so it is possible to = perform in-place modifications, adding properties / nodes until you run = our of this space (libfdt code will handle cases when exceeding this and = would fail gracefully). The fixup mechanism currently implemented does = minor modifications of the device tree in this fashion. My understanding is that if you'd like to modify the blob in a major way = you need to relocate it into a new location with more padding (there's = facility for relocation in libfdt already) and then modify it = accordingly. This won't be possible however with the statically embedded = DTB in the kernel as you cannot grow this space easily. The way to go = here would be to create a DTB metadatum (as if the DTB was loaded = dynamically from standalone blob file) with sufficient space, relocate = the statically embedded original content into this metadatum, do = modifications there and pass this new copy (as part of regular loader(8) = metadata) to the kernel for processing. The building blocks are there = (DTB loaded as metadata) and should work. Rafal From owner-freebsd-arm@FreeBSD.ORG Wed May 16 04:55:43 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 AECFC1065673; Wed, 16 May 2012 04:55: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 696CC8FC0C; Wed, 16 May 2012 04:55:43 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q4G4ta7i097766; Wed, 16 May 2012 04:55:36 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.143] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id cjwceifix7u97pzjty2ewj4y5s; Wed, 16 May 2012 04:55:36 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> Date: Tue, 15 May 2012 21:55:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B2A320B-3ADE-4F48-B94E-4F0886178251@freebsd.org> <201205070957.03842.jhb@freebsd.org> <8B01DF29-747A-449C-A762-E852F57C6380@freebsd.org> <1CCD6DAD-5B3F-431C-8A5C-A9951408AC82@kientzle.com> <1A2C0F4D-E03E-4FC1-9ED7-07DE1D056D3E@semihalf.com> To: Rafal Jaworowski X-Mailer: Apple Mail (2.1257) Cc: arm@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How does loader(8) decide where to load the kernel? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 04:55:43 -0000 On May 15, 2012, at 9:38 AM, Rafal Jaworowski wrote: >>=20 >> Should I overwrite the FDT in the kernel with the >> edited FDT? That doesn't feel quite right, but it's >> essentially what the FDT code here was trying to >> do before. >=20 > A given DTB (loaded dynamically or statically embedded in the kernel) = has some small amount of free space inside it so it is possible to = perform in-place modifications, adding properties / nodes until you run = our of this space (libfdt code will handle cases when exceeding this and = would fail gracefully). The fixup mechanism currently implemented does = minor modifications of the device tree in this fashion. I've fixed the code in sys/boot/fdt/ to do all access through = copyout/copyin. I'm waiting for a "make universe" to make sure I didn't break something inadvertently, and will probably commit it tomorrow. Right now, this just copies the DTB to a malloc-ed area, modifies the copy and then writes it back to the same place (either in the kernel or in a separately-loaded blob). It seems to work correctly even when copyout/copyin are doing address translations. > ... if you'd like to modify the blob in a major way you need to = relocate it into a new location with more padding =85. create a DTB = metadatum (as if the DTB was loaded dynamically from standalone blob = file) with sufficient space, =85. and pass this new copy (as part of = regular loader(8) metadata) to the kernel for processing. The building = blocks are there (DTB loaded as metadata) and should work. Yes, I see how that would work. Is there a real use for this? I could take a look at it once I'm finished with the current ubldr work I'm doing. Tim From owner-freebsd-arm@FreeBSD.ORG Thu May 17 10:12:04 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40A01106568D; Thu, 17 May 2012 10:12:04 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id CC5E28FC0A; Thu, 17 May 2012 10:12:00 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 360EDC4B2C; Thu, 17 May 2012 12:11:50 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id wk-bRt3RI39U; Thu, 17 May 2012 12:11:49 +0200 (CEST) Received: from [10.0.0.93] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 8C034C4B2A; Thu, 17 May 2012 12:11:49 +0200 (CEST) Message-ID: <4FB4EABA.702@semihalf.com> Date: Thu, 17 May 2012 14:10:34 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120127 Thunderbird/3.1.16 MIME-Version: 1.0 To: freebsd-fs@freebsd.org, freebsd-embedded@FreeBSD.org, freebsd-arm@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: NAND Framework in HEAD. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 10:12:04 -0000 Hello, I would like to annouce merging of the project/nand branch into HEAD. The purpose of this project was to create a complete environment supportng NAND Flash devices in FreeBSD. The NAND Flash environment consists of a driver framework for NAND controllers and memory chips, a NAND device simulator and a fault tolerant, log-structured file system (NANDFS), tailored to meet the unique challenges of NAND flash storage. The package includes all the tools, utilities and documentation needed to deploy this technology in custom applications. The NAND Flash environment consists of several distinct components: - NAND framework (drivers harness for NAND controllers and NAND chips) - NAND simulator (NANDsim) - NAND file system (NAND FS) - Companion tools and utilities - Documentation (manual pages) NAND FS adopts log-structured approach and some parts of its internal design are derived from the new implementation of the log-structured file system (NILFS), with some concepts rooting in the original (now legacy) BSD log-structured file system (LFS). The NAND FS has the following major features: - Hard links - Symbolic links - Case-sensitive, case-preserving - Snapshots No limit on the number of snapshots (only volume-limited) Mountable as read-only file systems Simultaneously mountable (there can be a writable mount concurrently mixed with a number of read-only snapshots) - Redundant super block - Metadata POSIX file permissions Creation timestamps Last content modification timestamps Last metadata change timestamps Checksum / ECC Additional documentation related to project can be found at: http://wiki.semihalf.com/moin.cgi/FreeBSD/NAND The NAND Flash Framework was developed by Semihalf. Juniper Networks and the FreeBSD Foundation kindly sponsored releasing the code to the FreeBSD community. regards, grzesiek From owner-freebsd-arm@FreeBSD.ORG Thu May 17 10:56:33 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D20481065673; Thu, 17 May 2012 10:56:33 +0000 (UTC) (envelope-from ray@dlink.ua) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 894ED8FC15; Thu, 17 May 2012 10:56:33 +0000 (UTC) Received: from terran.dlink.ua (unknown [192.168.10.90]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id 47569C495B; Thu, 17 May 2012 13:56:27 +0300 (EEST) Date: Thu, 17 May 2012 13:56:30 +0300 From: Aleksandr Rybalko To: Grzegorz Bernacki Message-Id: <20120517135630.6ec31920.ray@dlink.ua> In-Reply-To: <4FB4EABA.702@semihalf.com> References: <4FB4EABA.702@semihalf.com> Organization: D-Link X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, freebsd-embedded@FreeBSD.org Subject: Re: NAND Framework in HEAD. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 10:56:33 -0000 On Thu, 17 May 2012 14:10:34 +0200 Grzegorz Bernacki wrote: >> Hello, >> >> I would like to annouce merging of the project/nand branch into >> HEAD. The purpose of this project was to create a complete >> environment supportng NAND Flash devices in FreeBSD. >> >> The NAND Flash environment consists of a driver framework for NAND >> controllers and memory chips, a NAND device simulator and a fault >> tolerant, log-structured file system (NANDFS), tailored to meet the >> unique challenges of NAND flash storage. The package includes all >> the tools, utilities and documentation needed to deploy this >> technology in custom applications. >> >> The NAND Flash environment consists of several distinct components: >> - NAND framework (drivers harness for NAND controllers and NAND >> chips) >> - NAND simulator (NANDsim) >> - NAND file system (NAND FS) >> - Companion tools and utilities >> - Documentation (manual pages) >> >> NAND FS adopts log-structured approach and some parts of its >> internal design are derived from the new implementation of the >> log-structured file system (NILFS), with some concepts rooting in >> the original (now legacy) BSD log-structured file system (LFS). >> >> The NAND FS has the following major features: >> - Hard links >> - Symbolic links >> - Case-sensitive, case-preserving >> - Snapshots >> – No limit on the number of snapshots (only volume-limited) >> – Mountable as read-only file systems >> – Simultaneously mountable (there can be a writable mount >> concurrently mixed with a number of read-only snapshots) >> - Redundant super block >> - Metadata >> – POSIX file permissions >> – Creation timestamps >> – Last content modification timestamps >> – Last metadata change timestamps >> – Checksum / ECC >> >> Additional documentation related to project can be found at: >> http://wiki.semihalf.com/moin.cgi/FreeBSD/NAND >> >> The NAND Flash Framework was developed by Semihalf. Juniper Networks >> and the FreeBSD Foundation kindly sponsored releasing the code to >> the FreeBSD community. >> >> regards, >> grzesiek >> _______________________________________________ >> freebsd-embedded@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >> To unsubscribe, send any mail to >> "freebsd-embedded-unsubscribe@freebsd.org" Cool! Many thanks for that! to you Grzegorz and to whole Semihalf!!! WBW -- Alexandr Rybalko aka Alex RAY From owner-freebsd-arm@FreeBSD.ORG Thu May 17 12:15:49 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C6081065674; Thu, 17 May 2012 12:15:49 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id C8C088FC18; Thu, 17 May 2012 12:15:48 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id F31FFC4B2C; Thu, 17 May 2012 14:15:37 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id TvEkhdLj2Twi; Thu, 17 May 2012 14:15:37 +0200 (CEST) Received: from [10.0.0.22] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id EBF19C4B2A; Thu, 17 May 2012 14:15:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Rafal Jaworowski In-Reply-To: <20120517135630.6ec31920.ray@dlink.ua> Date: Thu, 17 May 2012 14:15:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FB4EABA.702@semihalf.com> <20120517135630.6ec31920.ray@dlink.ua> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, freebsd-embedded@FreeBSD.org Subject: Re: NAND Framework in HEAD. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 12:15:49 -0000 On 2012-05-17, at 12:56, Aleksandr Rybalko wrote: > On Thu, 17 May 2012 14:10:34 +0200 > Grzegorz Bernacki wrote: >=20 >>> Hello, >>>=20 >>> I would like to annouce merging of the project/nand branch into >>> HEAD. The purpose of this project was to create a complete >>> environment supportng NAND Flash devices in FreeBSD. >>>=20 >>> The NAND Flash environment consists of a driver framework for NAND=20= >>> controllers and memory chips, a NAND device simulator and a fault=20 >>> tolerant, log-structured file system (NANDFS), tailored to meet the=20= >>> unique challenges of NAND flash storage. The package includes all >>> the tools, utilities and documentation needed to deploy this >>> technology in custom applications. >>>=20 >>> The NAND Flash environment consists of several distinct components: >>> - NAND framework (drivers harness for NAND controllers and NAND >>> chips) >>> - NAND simulator (NANDsim) >>> - NAND file system (NAND FS) >>> - Companion tools and utilities >>> - Documentation (manual pages) >>>=20 >>> NAND FS adopts log-structured approach and some parts of its >>> internal design are derived from the new implementation of the >>> log-structured file system (NILFS), with some concepts rooting in >>> the original (now legacy) BSD log-structured file system (LFS). >>>=20 >>> The NAND FS has the following major features: >>> - Hard links >>> - Symbolic links >>> - Case-sensitive, case-preserving >>> - Snapshots >>> =E2=80=93 No limit on the number of snapshots (only = volume-limited) >>> =E2=80=93 Mountable as read-only file systems >>> =E2=80=93 Simultaneously mountable (there can be a writable = mount >>> concurrently mixed with a number of read-only snapshots) >>> - Redundant super block >>> - Metadata >>> =E2=80=93 POSIX file permissions >>> =E2=80=93 Creation timestamps >>> =E2=80=93 Last content modification timestamps >>> =E2=80=93 Last metadata change timestamps >>> =E2=80=93 Checksum / ECC >>>=20 >>> Additional documentation related to project can be found at: >>> http://wiki.semihalf.com/moin.cgi/FreeBSD/NAND >>>=20 >>> The NAND Flash Framework was developed by Semihalf. Juniper Networks >>> and the FreeBSD Foundation kindly sponsored releasing the code to >>> the FreeBSD community. >>>=20 >>> regards, >>> grzesiek >>> _______________________________________________ >>> freebsd-embedded@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >>> To unsubscribe, send any mail to >>> "freebsd-embedded-unsubscribe@freebsd.org" >=20 > Cool! Many thanks for that! to you Grzegorz and to whole Semihalf!!! This project was developed by Grzegorz Bernacki, Mateusz Guzik, =C5=81ukas= z P=C5=82achno, Jan Si=C4=99ka, =C5=81ukasz W=C3=B3jcik, with some help = from Jakub Klama and yours truly. We would like to thank Marcel = Moolenaar, Larkland Morley and Craig Rodrigues for testing, problem = reports and integration at Juniper side. Rafal From owner-freebsd-arm@FreeBSD.ORG Thu May 17 12:25:26 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 68913106564A; Thu, 17 May 2012 12:25:26 +0000 (UTC) (envelope-from rafael@lk6.com.br) Received: from mx2.lk6.com.br (mailx.lk6.com.br [189.30.46.209]) by mx1.freebsd.org (Postfix) with ESMTP id B78A18FC16; Thu, 17 May 2012 12:25:25 +0000 (UTC) Received: from mx.lk6.com.br (unknown [189.114.74.27]) by mx2.lk6.com.br (Postfix) with ESMTP id D74721CD31; Thu, 17 May 2012 09:19:13 -0300 (BRT) Received: from helix.lk6.com.br (unknown [192.168.2.11]) by mx.lk6.com.br (Postfix) with ESMTP id AA92DE4D019; Thu, 17 May 2012 09:19:11 -0300 (BRT) Received: from helix.lk6.com.br (localhost.helix.lk6.com.br [192.168.2.11]) by helix.lk6.com.br (Postfix) with ESMTP id 25A82544BC56; Thu, 17 May 2012 09:19:11 -0300 (BRT) Date: Thu, 17 May 2012 09:19:11 -0300 (BRT) From: Rafael Aquino To: Rafal Jaworowski Message-ID: <6ca0ac8e-937e-4525-ad65-f134a49b8615@helix.lk6.com.br> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Originating-IP: [192.168.2.9] X-Mailer: Zimbra 7.1.1_GA_3205 (ZimbraWebClient - FF3.0 (Win)/7.1.1_GA_3205) Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, freebsd-embedded@FreeBSD.org Subject: Re: NAND Framework in HEAD. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 12:25:26 -0000 ----- Mensagem original ----- > De: "Rafal Jaworowski" > Para: "Aleksandr Rybalko" > Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, freebsd-embedded@Fre= eBSD.org > Enviadas: Quinta-feira, 17 de Maio de 2012 9:15:46 > Assunto: Re: NAND Framework in HEAD. > > > On 2012-05-17, at 12:56, Aleksandr Rybalko wrote: > > > On Thu, 17 May 2012 14:10:34 +0200 > > Grzegorz Bernacki wrote: > > > >>> Hello, > >>> > >>> I would like to annouce merging of the project/nand branch into > >>> HEAD. The purpose of this project was to create a complete > >>> environment supportng NAND Flash devices in FreeBSD. > >>> > >>> The NAND Flash environment consists of a driver framework for > >>> NAND > >>> controllers and memory chips, a NAND device simulator and a fault > >>> tolerant, log-structured file system (NANDFS), tailored to meet > >>> the > >>> unique challenges of NAND flash storage. The package includes all > >>> the tools, utilities and documentation needed to deploy this > >>> technology in custom applications. > >>> > >>> The NAND Flash environment consists of several distinct > >>> components: > >>> - NAND framework (drivers harness for NAND controllers and NAND > >>> chips) > >>> - NAND simulator (NANDsim) > >>> - NAND file system (NAND FS) > >>> - Companion tools and utilities > >>> - Documentation (manual pages) > >>> > >>> NAND FS adopts log-structured approach and some parts of its > >>> internal design are derived from the new implementation of the > >>> log-structured file system (NILFS), with some concepts rooting in > >>> the original (now legacy) BSD log-structured file system (LFS). > >>> > >>> The NAND FS has the following major features: > >>> - Hard links > >>> - Symbolic links > >>> - Case-sensitive, case-preserving > >>> - Snapshots > >>> =E2=80=93 No limit on the number of snapshots (only volume-limite= d) > >>> =E2=80=93 Mountable as read-only file systems > >>> =E2=80=93 Simultaneously mountable (there can be a writable mount= > >>> concurrently mixed with a number of read-only snapshots) > >>> - Redundant super block > >>> - Metadata > >>> =E2=80=93 POSIX file permissions > >>> =E2=80=93 Creation timestamps > >>> =E2=80=93 Last content modification timestamps > >>> =E2=80=93 Last metadata change timestamps > >>> =E2=80=93 Checksum / ECC > >>> > >>> Additional documentation related to project can be found at: > >>> http://wiki.semihalf.com/moin.cgi/FreeBSD/NAND > >>> > >>> The NAND Flash Framework was developed by Semihalf. Juniper > >>> Networks > >>> and the FreeBSD Foundation kindly sponsored releasing the code to > >>> the FreeBSD community. > >>> > >>> regards, > >>> grzesiek > >>> _______________________________________________ > >>> freebsd-embedded@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded > >>> To unsubscribe, send any mail to > >>> "freebsd-embedded-unsubscribe@freebsd.org" > > > > Cool! Many thanks for that! to you Grzegorz and to whole > > Semihalf!!! > > This project was developed by Grzegorz Bernacki, Mateusz Guzik, > =C5=81ukasz P=C5=82achno, Jan Si=C4=99ka, =C5=81ukasz W=C3=B3jcik, with s= ome help from Jakub > Klama and yours truly. We would like to thank Marcel Moolenaar, > Larkland Morley and Craig Rodrigues for testing, problem reports and > integration at Juniper side. > > Rafal > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to > "freebsd-arm-unsubscribe@freebsd.org" > Hey, everybody! I bought a Sheevaplug 2 years ago and still not using it, waiting for NAND = support. Congratulations for the great work. I'm a big fan!!! Best regards! Rafael Mentz Aquino LK6 Solu=C3=A7=C3=B5es em TI Rua Domingos de Almeida, 135 sala 1102 Centro - Novo Hamburgo - RS - BRAZIL (51) 3035-6997 - 9999-7030 www.lk6.com.br From owner-freebsd-arm@FreeBSD.ORG Thu May 17 12:26:22 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 B66E51065675; Thu, 17 May 2012 12:26:22 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 28B1E8FC18; Thu, 17 May 2012 12:26:21 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 9BFF6C4B3C; Thu, 17 May 2012 14:26:05 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id ps4WStHYEzuE; Thu, 17 May 2012 14:26:04 +0200 (CEST) Received: from [10.0.0.22] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id A5454C4B2C; Thu, 17 May 2012 14:26:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Rafal Jaworowski In-Reply-To: <6ca0ac8e-937e-4525-ad65-f134a49b8615@helix.lk6.com.br> Date: Thu, 17 May 2012 14:26:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8450E177-A668-4336-AC16-3260C0683226@semihalf.com> References: <6ca0ac8e-937e-4525-ad65-f134a49b8615@helix.lk6.com.br> To: Rafael Aquino X-Mailer: Apple Mail (2.1084) Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, freebsd-embedded@FreeBSD.org Subject: Re: NAND Framework in HEAD. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 12:26:22 -0000 On 2012-05-17, at 14:19, Rafael Aquino wrote: >=20 > ----- Mensagem original ----- >> De: "Rafal Jaworowski" >> Para: "Aleksandr Rybalko" >> Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, = freebsd-embedded@FreeBSD.org >> Enviadas: Quinta-feira, 17 de Maio de 2012 9:15:46 >> Assunto: Re: NAND Framework in HEAD. >>=20 >>=20 >> On 2012-05-17, at 12:56, Aleksandr Rybalko wrote: >>=20 >>> On Thu, 17 May 2012 14:10:34 +0200 >>> Grzegorz Bernacki wrote: >>>=20 >>>>> Hello, >>>>>=20 >>>>> I would like to annouce merging of the project/nand branch into >>>>> HEAD. The purpose of this project was to create a complete >>>>> environment supportng NAND Flash devices in FreeBSD. >>>>>=20 >>>>> The NAND Flash environment consists of a driver framework for >>>>> NAND >>>>> controllers and memory chips, a NAND device simulator and a fault >>>>> tolerant, log-structured file system (NANDFS), tailored to meet >>>>> the >>>>> unique challenges of NAND flash storage. The package includes all >>>>> the tools, utilities and documentation needed to deploy this >>>>> technology in custom applications. >>>>>=20 >>>>> The NAND Flash environment consists of several distinct >>>>> components: >>>>> - NAND framework (drivers harness for NAND controllers and NAND >>>>> chips) >>>>> - NAND simulator (NANDsim) >>>>> - NAND file system (NAND FS) >>>>> - Companion tools and utilities >>>>> - Documentation (manual pages) >>>>>=20 >>>>> NAND FS adopts log-structured approach and some parts of its >>>>> internal design are derived from the new implementation of the >>>>> log-structured file system (NILFS), with some concepts rooting in >>>>> the original (now legacy) BSD log-structured file system (LFS). >>>>>=20 >>>>> The NAND FS has the following major features: >>>>> - Hard links >>>>> - Symbolic links >>>>> - Case-sensitive, case-preserving >>>>> - Snapshots >>>>> =E2=80=93 No limit on the number of snapshots (only = volume-limited) >>>>> =E2=80=93 Mountable as read-only file systems >>>>> =E2=80=93 Simultaneously mountable (there can be a writable = mount >>>>> concurrently mixed with a number of read-only snapshots) >>>>> - Redundant super block >>>>> - Metadata >>>>> =E2=80=93 POSIX file permissions >>>>> =E2=80=93 Creation timestamps >>>>> =E2=80=93 Last content modification timestamps >>>>> =E2=80=93 Last metadata change timestamps >>>>> =E2=80=93 Checksum / ECC >>>>>=20 >>>>> Additional documentation related to project can be found at: >>>>> http://wiki.semihalf.com/moin.cgi/FreeBSD/NAND >>>>>=20 >>>>> The NAND Flash Framework was developed by Semihalf. Juniper >>>>> Networks >>>>> and the FreeBSD Foundation kindly sponsored releasing the code to >>>>> the FreeBSD community. >>>>>=20 >>>>> regards, >>>>> grzesiek >>>>> _______________________________________________ >>>>> freebsd-embedded@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >>>>> To unsubscribe, send any mail to >>>>> "freebsd-embedded-unsubscribe@freebsd.org" >>>=20 >>> Cool! Many thanks for that! to you Grzegorz and to whole >>> Semihalf!!! >>=20 >> This project was developed by Grzegorz Bernacki, Mateusz Guzik, >> =C5=81ukasz P=C5=82achno, Jan Si=C4=99ka, =C5=81ukasz W=C3=B3jcik, = with some help from Jakub >> Klama and yours truly. We would like to thank Marcel Moolenaar, >> Larkland Morley and Craig Rodrigues for testing, problem reports and >> integration at Juniper side. >>=20 >> Rafal >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to >> "freebsd-arm-unsubscribe@freebsd.org" >>=20 >=20 > Hey, everybody! >=20 > I bought a Sheevaplug 2 years ago and still not using it, waiting for = NAND support. > Congratulations for the great work. I'm a big fan!!! Sheevaplug (and the 88F6281 chip in general) is actually the reference, = demo implementation of the NAND controller driver in this framework. Rafal From owner-freebsd-arm@FreeBSD.ORG Thu May 17 14:08:47 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 943BC1065674; Thu, 17 May 2012 14:08:47 +0000 (UTC) (envelope-from gber@freebsd.org) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 217258FC0C; Thu, 17 May 2012 14:08:47 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 05C74C4E1F; Thu, 17 May 2012 16:08:36 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id Fugf3jlTcvWo; Thu, 17 May 2012 16:08:35 +0200 (CEST) Received: from [10.0.0.93] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 05D52C5183; Thu, 17 May 2012 16:08:35 +0200 (CEST) Message-ID: <4FB52238.6080000@freebsd.org> Date: Thu, 17 May 2012 18:07:20 +0200 From: Grzegorz Bernacki User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120127 Thunderbird/3.1.16 MIME-Version: 1.0 To: Rafal Jaworowski References: <6ca0ac8e-937e-4525-ad65-f134a49b8615@helix.lk6.com.br> <8450E177-A668-4336-AC16-3260C0683226@semihalf.com> In-Reply-To: <8450E177-A668-4336-AC16-3260C0683226@semihalf.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, freebsd-embedded@FreeBSD.org Subject: Re: NAND Framework in HEAD. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 14:08:47 -0000 On 05/17/12 14:26, Rafal Jaworowski wrote: > > On 2012-05-17, at 14:19, Rafael Aquino wrote: > >> >> ----- Mensagem original ----- >>> De: "Rafal Jaworowski" >>> Para: "Aleksandr Rybalko" >>> Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, freebsd-embedded@FreeBSD.org >>> Enviadas: Quinta-feira, 17 de Maio de 2012 9:15:46 >>> Assunto: Re: NAND Framework in HEAD. >>> >>> >>> On 2012-05-17, at 12:56, Aleksandr Rybalko wrote: >>> >>>> On Thu, 17 May 2012 14:10:34 +0200 >>>> Grzegorz Bernacki wrote: >>>> >>>>>> Hello, >>>>>> >>>>>> I would like to annouce merging of the project/nand branch into >>>>>> HEAD. The purpose of this project was to create a complete >>>>>> environment supportng NAND Flash devices in FreeBSD. >>>>>> >>>>>> The NAND Flash environment consists of a driver framework for >>>>>> NAND >>>>>> controllers and memory chips, a NAND device simulator and a fault >>>>>> tolerant, log-structured file system (NANDFS), tailored to meet >>>>>> the >>>>>> unique challenges of NAND flash storage. The package includes all >>>>>> the tools, utilities and documentation needed to deploy this >>>>>> technology in custom applications. >>>>>> >>>>>> The NAND Flash environment consists of several distinct >>>>>> components: >>>>>> - NAND framework (drivers harness for NAND controllers and NAND >>>>>> chips) >>>>>> - NAND simulator (NANDsim) >>>>>> - NAND file system (NAND FS) >>>>>> - Companion tools and utilities >>>>>> - Documentation (manual pages) >>>>>> >>>>>> NAND FS adopts log-structured approach and some parts of its >>>>>> internal design are derived from the new implementation of the >>>>>> log-structured file system (NILFS), with some concepts rooting in >>>>>> the original (now legacy) BSD log-structured file system (LFS). >>>>>> >>>>>> The NAND FS has the following major features: >>>>>> - Hard links >>>>>> - Symbolic links >>>>>> - Case-sensitive, case-preserving >>>>>> - Snapshots >>>>>> – No limit on the number of snapshots (only volume-limited) >>>>>> – Mountable as read-only file systems >>>>>> – Simultaneously mountable (there can be a writable mount >>>>>> concurrently mixed with a number of read-only snapshots) >>>>>> - Redundant super block >>>>>> - Metadata >>>>>> – POSIX file permissions >>>>>> – Creation timestamps >>>>>> – Last content modification timestamps >>>>>> – Last metadata change timestamps >>>>>> – Checksum / ECC >>>>>> >>>>>> Additional documentation related to project can be found at: >>>>>> http://wiki.semihalf.com/moin.cgi/FreeBSD/NAND >>>>>> >>>>>> The NAND Flash Framework was developed by Semihalf. Juniper >>>>>> Networks >>>>>> and the FreeBSD Foundation kindly sponsored releasing the code to >>>>>> the FreeBSD community. >>>>>> >>>>>> regards, >>>>>> grzesiek >>>>>> _______________________________________________ >>>>>> freebsd-embedded@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-embedded >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-embedded-unsubscribe@freebsd.org" >>>> >>>> Cool! Many thanks for that! to you Grzegorz and to whole >>>> Semihalf!!! >>> >>> This project was developed by Grzegorz Bernacki, Mateusz Guzik, >>> Łukasz Płachno, Jan Sięka, Łukasz Wójcik, with some help from Jakub >>> Klama and yours truly. We would like to thank Marcel Moolenaar, >>> Larkland Morley and Craig Rodrigues for testing, problem reports and >>> integration at Juniper side. >>> >>> Rafal >>> >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to >>> "freebsd-arm-unsubscribe@freebsd.org" >>> >> >> Hey, everybody! >> >> I bought a Sheevaplug 2 years ago and still not using it, waiting for NAND support. >> Congratulations for the great work. I'm a big fan!!! > > Sheevaplug (and the 88F6281 chip in general) is actually the reference, demo implementation of the NAND controller driver in this framework. > Hi, In the first step only platform independent code has been integrated. Platform code related to 88F6281 (like dts files, kernel configuration, localbus driver, etc) will be committed soon. Thanks for showing your interest, regards, grzesiek From owner-freebsd-arm@FreeBSD.ORG Thu May 17 20:08:37 2012 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48A7F106564A for ; Thu, 17 May 2012 20:08:37 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7D08FC19 for ; Thu, 17 May 2012 20:08:37 +0000 (UTC) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta03.emeryville.ca.mail.comcast.net with comcast id B40b1j00A1zF43QA387XSw; Thu, 17 May 2012 20:07:31 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta24.emeryville.ca.mail.comcast.net with comcast id B87W1j00Z4NgCEG8k87XJd; Thu, 17 May 2012 20:07:31 +0000 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 q4HK7TBr097698; Thu, 17 May 2012 14:07:29 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: Svatopluk Kraus In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 May 2012 14:07:28 -0600 Message-ID: <1337285248.1503.308.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, hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 20:08:37 -0000 On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: > Hi, > > I'm working on DMA bus implementation for ARM11mpcore platform. I've > looked at implementation in ARM tree, but IMHO it only works with some > assumptions. There is a problem with DMA on memory block which is not > aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. > > Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. > Then first cache line associated with the buffer can be divided into > two parts, A and B, where A is a memory we know nothing about it and B > is buffer memory. The same stands for last cache line associatted with > the buffer. We have no problem if a memory is coherent. Otherwise it > depends on memory attributes. > > 1. [no cache] attribute > No problem as memory is coherent. > > 2. [write throught] attribute > The part A can be invalidated without loss of any data. It's not problem too. > > 3. [write back] attribute > In general, there is no way how to keep both parts consistent. At the > start of DMA transaction, the cache line is written back and > invalidated. However, as we know nothing about memory associated with > part A of the cache line, the cache line can be filled again at any > time and messing up DMA transaction if flushed. Even if the cache line > is only filled but not flushed during DMA transaction, we must make it > coherent with memory after that. There is a trick with saving part A > of the line into temporary buffer, invalidating the line, and > restoring part A in current ARM (MIPS) implementation. However, if > somebody is writting to memory associated with part A of the line > during this trick, the part A will be messed up. Moreover, the part A > can be part of another DMA transaction. > > To safely use DMA with no coherent memory, a memory with [no cache] or > [write throught] attributes can be used without problem. A memory with > [write back] attribute must be aligned on CACHE_LINE_SIZE. > > However, for example mbuf, a buffer for DMA can be part of a structure > which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We > can know that nobody will write to the structure during DMA > transaction, so it's safe to use the buffer event if it's not aligned > on CACHE_LINE_SIZE. > > So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and > we want to avoid bounce pages overhead, we must support additional > information to DMA transaction. It should be easy to support the > information about drivers data buffers. However, what about OS data > buffers like mentioned mbufs? > > The question is following. Is or can be guaranteed for all or at least > well-known OS data buffers which can be part of DMA access that the > not CACHE_LINE_SIZE aligned buffers are surrounded by data which > belongs to the same object as the buffer and the data is not written > by OS when given to a driver? > > Any answer is appreciated. However, 'bounce pages' is not an answer. > > Thanks, Svata I'm adding freebsd-arm@ to the CC list; that's where this has been discussed before. Your analysis is correct... to the degree that it works at all right now, it's working by accident. At work we've been making the good accident a bit more likely by setting the minimum allocation size to arm_dcache_align in kern_malloc.c. This makes it somewhat less likely that unrelated objects in the kernel are sharing a cache line, but it also reduces the effectiveness of the cache somewhat. Another factor, not mentioned in your analysis, is the size of the IO operation. Even if the beginning of the DMA buffer is cache-aligned, if the size isn't exactly a multiple of the cache line size you still have the partial flush situation and all of its problems. It's not guaranteed that data surrounding a DMA buffer will be untouched during the DMA, even when that surrounding data is part of the same conceptual object as the IO buffer. It's most often true, but certainly not guaranteed. In addition, as Mark pointed out in a prior reply, sometimes the DMA buffer is on the stack, and even returning from the function that starts the IO operation affects the cacheline associated with the DMA buffer. Consider something like this: void do_io() { int buffer; start_read(&buffer); // maybe do other stuff here wait_for_read_done(); } start_read() gets some IO going, so before it returns a call has been made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets done on the cacheline containing the variable 'buffer'. The act of returning from the start_read() function causes that cacheline to get reloaded, so now the stale pre-DMA value of the variable 'buffer' is in cache again. Right after that, the DMA completes so that ram has a newer value that belongs in the buffer variable and the copy in the cacheline is stale. Before control gets into the wait_for_read_done() routine that will attempt to handle the POSTREAD partial cacheline flush, another thread gets control and begins setting up a new DMA for another device, different buffer. This time it's a read using a 64K buffer for disk IO. The busdma sync code calls cpu_dcache_inv_range() for that buffer but because the range is so large, it gets turned into a cpu_dcache_wbinv_all() because that's cheaper than looping through an arbitrarily large range invalidating a line at a time. Except, ooops, that means we write back to ram the cacheline holding the stale value of the 'buffer' variable, wiping out the data brought in by DMA before the partial cachline flush code could do its dance to preserve it. There are several variations of the above scenario; it doesn't require a stack-allocated buffer to trigger a writeback of a stale value. Any cacheline that gets dirtied after a PREREAD invalidate can end up overwriting fresh DMA data in ram with stale data from the cacheline at any time, because any call to cpu_dcache_inv_range() or cpu_dcache_wbinv_range() can get turned into a cpu_dcache_wbinv_all(). That means any DMA operation and also a context switch which calls cpu_dcache_wbinv_all(). If you rule out bounce buffers as a solution, then I think that may leave us with just one option: make the pages uncacheable for the duration of the DMA. Essentially force a DMA_COHERENT buffer if the driver didn't already do so. I think doing so blindly may have performance implications every bit as bad as using bounce buffers. (For example, turning off cache on a stack page could really hurt.) The code to do the remapping already exists in pmap.c as part of handling multiple mappings for VIVT caches. From the busdma code you could accomplish the remapping by making a temporary writable kernel mapping for the buffer pages in the PRE handling and undo that mapping in the POST handling. It may be that a hybrid approach would work. For an unaligned buffer, if it isn't already DMA_COHERENT, then if it is below a certain size bounce it, otherwise remap the buffer's pages. When I was knee-deep in this problem last summer one of the things I noticed in our systems was that large DMA operations (1 KByte or larger buffers) tend to be DMA_COHERENT buffers, and when not they're already cache aligned and a power of two in size. For us the partial cacheline flush situations are almost always caused by tiny IO of 1 to 128 bytes length, usually serial-comms or usb related. I think pre-allocating a few pages for bouncing small unaligned IO would be a big win compared to remapping the pages as uncacheable. The remapping has to take locks and search lists of pages and so on; it should be way faster to do a small memcpy() instead. Buffers bigger than some (perhaps tunable) limit would get remapped instead of bounced. It also might be nice to have a knob to enable logging when bouncing or remapping is used to avoid partial cacheline operations, to make it easy to find drivers that could be tweaked for better performance. If you're bouncing 2 or 3 operations per second with a 4-byte buffer that's no big deal. If every network packet is resulting in bouncing/remapping you'd want to know about that. -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri May 18 12:07:41 2012 Return-Path: Delivered-To: freebsd-arm@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8B26106568B; Fri, 18 May 2012 12:07:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7A3CE8FC0C; Fri, 18 May 2012 12:07:41 +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 q4IC7f83044731; Fri, 18 May 2012 12:07:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q4IC7fs8044727; Fri, 18 May 2012 12:07:41 GMT (envelope-from linimon) Date: Fri, 18 May 2012 12:07:41 GMT Message-Id: <201205181207.q4IC7fs8044727@freefall.freebsd.org> To: kvedulv@kvedulv.de, linimon@FreeBSD.org, freebsd-arm@FreeBSD.org, linimon@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: arm/154189: lang/perl5.12 doesn't build on arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 12:07:41 -0000 Synopsis: lang/perl5.12 doesn't build on arm State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Fri May 18 12:06:37 UTC 2012 State-Changed-Why: Did the compiler fix committed in arm/161128 fix this problem? Responsible-Changed-From-To: freebsd-arm->linimon Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 18 12:06:37 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=154189 From owner-freebsd-arm@FreeBSD.ORG Fri May 18 12:13:20 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D23AA106564A; Fri, 18 May 2012 12:13:20 +0000 (UTC) (envelope-from mmoll@darkthrone.kvedulv.de) Received: from darkthrone.kvedulv.de (darkthrone.kvedulv.de [IPv6:2001:1578:400:101::2]) by mx1.freebsd.org (Postfix) with ESMTP id 952A18FC15; Fri, 18 May 2012 12:13:20 +0000 (UTC) Received: by darkthrone.kvedulv.de (Postfix, from userid 666) id B35A71EE8; Fri, 18 May 2012 14:13:18 +0200 (CEST) Date: Fri, 18 May 2012 14:13:18 +0200 From: Michael Moll To: bug-followup@FreeBSD.org Message-ID: <20120518121318.GA91772@darkthrone.kvedulv.de> References: <201205181207.q4IC7fs8044727@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201205181207.q4IC7fs8044727@freefall.freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org, linimon@freebsd.org Subject: Re: arm/154189: lang/perl5.12 doesn't build on arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 12:13:20 -0000 Hi, On Fri, May 18, 2012 at 12:07:41PM +0000, linimon@FreeBSD.org wrote: > Did the compiler fix committed in arm/161128 fix this problem? My ARM-hardware went out of order, so I can't test it. However, someone on freebsd-arm could maybe? Best Regards -- Michael Moll e-mail : kvedulv@kvedulv.de WWW : http://www.kvedulv.de/ From owner-freebsd-arm@FreeBSD.ORG Fri May 18 12:16: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 941C2106566B; Fri, 18 May 2012 12:16:37 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (pancho.soaustin.net [76.74.250.40]) by mx1.freebsd.org (Postfix) with ESMTP id 71F4C8FC12; Fri, 18 May 2012 12:16:37 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id 03FA756252; Fri, 18 May 2012 07:16:37 -0500 (CDT) Date: Fri, 18 May 2012 07:16:37 -0500 From: Mark Linimon To: Michael Moll Message-ID: <20120518121636.GE1462@lonesome.com> References: <201205181207.q4IC7fs8044727@freefall.freebsd.org> <20120518121318.GA91772@darkthrone.kvedulv.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120518121318.GA91772@darkthrone.kvedulv.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-arm@FreeBSD.org, linimon@freebsd.org, bug-followup@FreeBSD.org Subject: Re: arm/154189: lang/perl5.12 doesn't build on arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 12:16:37 -0000 On Fri, May 18, 2012 at 02:13:18PM +0200, Michael Moll wrote: > My ARM-hardware went out of order, so I can't test it. However, someone > on freebsd-arm could maybe? Responses to this PR gets automatically copied over to freebsd-arm, so let's see if there are any responses. mcl From owner-freebsd-arm@FreeBSD.ORG Fri May 18 14:13:44 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 2B245106566C; Fri, 18 May 2012 14:13:44 +0000 (UTC) (envelope-from onwahe@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC718FC0C; Fri, 18 May 2012 14:13:43 +0000 (UTC) Received: by laai10 with SMTP id i10so2956261laa.13 for ; Fri, 18 May 2012 07:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Uqzy/MF3GEKb4ELQoTPrC7ndv18u7EXDo3wTOpWQVlQ=; b=DYbMMoKTyxXfRZxWBU+HhFji+zH13xLbrgI03eCYjuAJegPCi9R5lmgcaJ57BPAo1Q b5N7bAUAxsxNDyvllLB9CiY33Cmr+I/XLXw9T0ntkBfA7WhfhHW/4th5k0Wt2Pye/Wjf 3x2vD6wkBzUP01NnD9h0WToXXZwvZf3ValUb1GZKfmvol97pGz/CCEefIzRe8/stiHIj 4mgCsZ3mvzbHnE/UBYGtdo70nPixyg70zDi8T9lvDR7Sl295/tkkL8IikyjNfEd7L+Av FN9NAkLPtI4m7nONEYumuvLgTf0Bql3hThKByUajqsagZk8rQWmIWRA+dGjmm8tYiop7 jbcA== MIME-Version: 1.0 Received: by 10.152.48.6 with SMTP id h6mr11237327lan.30.1337350421929; Fri, 18 May 2012 07:13:41 -0700 (PDT) Received: by 10.112.60.65 with HTTP; Fri, 18 May 2012 07:13:41 -0700 (PDT) In-Reply-To: <1337285248.1503.308.camel@revolution.hippie.lan> References: <1337285248.1503.308.camel@revolution.hippie.lan> Date: Fri, 18 May 2012 16:13:41 +0200 Message-ID: From: Svatopluk Kraus To: Ian Lepore , Mark Tinguely , Richard Hodges Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, hackers@freebsd.org Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:13:44 -0000 On Thu, May 17, 2012 at 10:07 PM, Ian Lepore wrote: > On Thu, 2012-05-17 at 15:20 +0200, Svatopluk Kraus wrote: >> Hi, >> >> I'm working on DMA bus implementation for ARM11mpcore platform. I've >> looked at implementation in ARM tree, but IMHO it only works with some >> assumptions. There is a problem with DMA on memory block which is not >> aligned on CACHE_LINE_SIZE (start and end) if memory is not coherent. >> >> Let's have a buffer for DMA which is no aligned on CACHE_LINE_SIZE. >> Then first cache line associated with the buffer can be divided into >> two parts, A and B, where A is a memory we know nothing about it and B >> is buffer memory. The same stands for last cache line associatted with >> the buffer. We have no problem if a memory is coherent. Otherwise it >> depends on memory attributes. >> >> 1. [no cache] attribute >> No problem as memory is coherent. >> >> 2. [write throught] attribute >> The part A can be invalidated without loss of any data. It's not problem= too. >> >> 3. [write back] attribute >> In general, there is no way how to keep both parts consistent. At the >> start of DMA transaction, the cache line is written back and >> invalidated. However, as we know nothing about memory associated with >> part A of the cache line, the cache line can be filled again at any >> time and messing up DMA transaction if flushed. Even if the cache line >> is only filled but not flushed during DMA transaction, we must make it >> coherent with memory after that. There is a trick with saving part A >> of the line into temporary buffer, invalidating the line, and >> restoring part A in current ARM (MIPS) implementation. However, if >> somebody is writting to memory associated with part A of the line >> during this trick, the part A will be messed up. Moreover, the part A >> can be part of another DMA transaction. >> >> To safely use DMA with no coherent memory, a memory with [no cache] or >> [write throught] attributes can be used without problem. A memory with >> [write back] attribute must be aligned on CACHE_LINE_SIZE. >> >> However, for example mbuf, a buffer for DMA can be part of a structure >> which can be aligned on CACHE_LINE_SIZE, but not the buffer itself. We >> can know that nobody will write to the structure during DMA >> transaction, so it's safe to use the buffer event if it's not aligned >> on CACHE_LINE_SIZE. >> >> So, in practice, if DMA buffer is not aligned on CACHE_LINE_SIZE and >> we want to avoid bounce pages overhead, we must support additional >> information to DMA transaction. It should be easy to support the >> information about drivers data buffers. However, what about OS data >> buffers like mentioned mbufs? >> >> The question is following. Is or can be guaranteed for all or at least >> well-known OS data buffers which can be part of DMA access that the >> not CACHE_LINE_SIZE aligned buffers are surrounded by data which >> belongs to the same object as the buffer and the data is not written >> by OS when given to a driver? >> >> Any answer is appreciated. However, 'bounce pages' is not an answer. >> >> Thanks, Svata > > I'm adding freebsd-arm@ to the CC list; that's where this has been > discussed before. > > Your analysis is correct... to the degree that it works at all right > now, it's working by accident. =A0At work we've been making the good > accident a bit more likely by setting the minimum allocation size to > arm_dcache_align in kern_malloc.c. =A0This makes it somewhat less likely > that unrelated objects in the kernel are sharing a cache line, but it > also reduces the effectiveness of the cache somewhat. > > Another factor, not mentioned in your analysis, is the size of the IO > operation. =A0Even if the beginning of the DMA buffer is cache-aligned, i= f > the size isn't exactly a multiple of the cache line size you still have > the partial flush situation and all of its problems. > > It's not guaranteed that data surrounding a DMA buffer will be untouched > during the DMA, even when that surrounding data is part of the same > conceptual object as the IO buffer. =A0It's most often true, but certainl= y > not guaranteed. =A0In addition, as Mark pointed out in a prior reply, > sometimes the DMA buffer is on the stack, and even returning from the > function that starts the IO operation affects the cacheline associated > with the DMA buffer. =A0Consider something like this: > > =A0 =A0void do_io() > =A0 =A0{ > =A0 =A0 =A0 =A0int buffer; > =A0 =A0 =A0 =A0start_read(&buffer); > =A0 =A0 =A0 =A0// maybe do other stuff here > =A0 =A0 =A0 =A0wait_for_read_done(); > =A0 =A0} > > start_read() gets some IO going, so before it returns a call has been > made to bus_dmamap_sync(..., BUS_DMASYNC_PREREAD) and an invalidate gets > done on the cacheline containing the variable 'buffer'. =A0The act of > returning from the start_read() function causes that cacheline to get > reloaded, so now the stale pre-DMA value of the variable 'buffer' is in > cache again. =A0Right after that, the DMA completes so that ram has a > newer value that belongs in the buffer variable and the copy in the > cacheline is stale. > > Before control gets into the wait_for_read_done() routine that will > attempt to handle the POSTREAD partial cacheline flush, another thread > gets control and begins setting up a new DMA for another device, > different buffer. =A0This time it's a read using a 64K buffer for disk IO= . > The busdma sync code calls cpu_dcache_inv_range() for that buffer but > because the range is so large, it gets turned into a > cpu_dcache_wbinv_all() because that's cheaper than looping through an > arbitrarily large range invalidating a line at a time. > > Except, ooops, that means we write back to ram the cacheline holding the > stale value of the 'buffer' variable, wiping out the data brought in by > DMA before the partial cachline flush code could do its dance to > preserve it. > > There are several variations of the above scenario; it doesn't require a > stack-allocated buffer to trigger a writeback of a stale value. =A0Any > cacheline that gets dirtied after a PREREAD invalidate can end up > overwriting fresh DMA data in ram with stale data from the cacheline at > any time, because any call to cpu_dcache_inv_range() or > cpu_dcache_wbinv_range() can get turned into a cpu_dcache_wbinv_all(). > That means any DMA operation and also a context switch which calls > cpu_dcache_wbinv_all(). > > If you rule out bounce buffers as a solution, then I think that may > leave us with just one option: =A0make the pages uncacheable for the > duration of the DMA. =A0Essentially force a DMA_COHERENT buffer if the > driver didn't already do so. =A0I think doing so blindly may have > performance implications every bit as bad as using bounce buffers. =A0(Fo= r > example, turning off cache on a stack page could really hurt.) =A0The cod= e > to do the remapping already exists in pmap.c as part of handling > multiple mappings for VIVT caches. =A0From the busdma code you could > accomplish the remapping by making a temporary writable kernel mapping > for the buffer pages in the PRE handling and undo that mapping in the > POST handling. > > It may be that a hybrid approach would work. =A0For an unaligned buffer, > if it isn't already DMA_COHERENT, then if it is below a certain size > bounce it, otherwise remap the buffer's pages. =A0When I was knee-deep in > this problem last summer one of the things I noticed in our systems was > that large DMA operations (1 KByte or larger buffers) tend to be > DMA_COHERENT buffers, and when not they're already cache aligned and a > power of two in size. =A0For us the partial cacheline flush situations ar= e > almost always caused by tiny IO of 1 to 128 bytes length, usually > serial-comms or usb related. Good to know. > > I think pre-allocating a few pages for bouncing small unaligned IO would > be a big win compared to remapping the pages as uncacheable. =A0The > remapping has to take locks and search lists of pages and so on; it > should be way faster to do a small memcpy() instead. =A0Buffers bigger > than some (perhaps tunable) limit would get remapped instead of > bounced. > > It also might be nice to have a knob to enable logging when bouncing or > remapping is used to avoid partial cacheline operations, to make it easy > to find drivers that could be tweaked for better performance. =A0If you'r= e > bouncing 2 or 3 operations per second with a 4-byte buffer that's no big > deal. =A0If every network packet is resulting in bouncing/remapping you'd > want to know about that. It sounds resonable for me. > > -- Ian Thanks for replies. So, we have to check DMA buffers if they are aligned and if not, we have two possibilies in general. 1. To not assume anything about surrounding data around unaligned DMA buffer at all. This always leads to bouncing or memory attributes changing in no coherent case. 2. To add new flag (something like BUS_DMA_UNALIGNED_SAFE) and set it in dmamap load functions in cases that we know it's safe to use an unaligned buffer. This way we can avoid bouncing in some cases. I didn't know about drivers that are using DMA buffers on stack. However, to patch such a driver is something I can do on my own. I.e., I always can decide that a driver buffer is safe for DMA even unaligned. Moreover, for example, DMA descriptors rings are defined as an array in some net drivers and a descriptor size could be smaller than CACHE_LINE_SIZE. The drivers must be modified anyway to made descriptors coherent or aligned. What I can do in a driver it's not so simple in case of OS buffers like mbufs. I can check how mbufs are used in current implementation and say, yes, it's safe to use them unaligned. However, it can be changed in next release if anybody won't take care of it. It would be nice to have a maintained list of OS buffers which are DMA safe in respect of CACHE_LINE_SIZE. Is the flag and the list interesting for somebody else? Some more notes. SMP makes things worse and ARM11mpcore is about SMP too. For example, another thread could be open about that how to flush caches (exclusive L1 cache) in SMP case. I'm not sure how to correctly change memory attributes on page which is in use. Making new temporary mapping with different attributes is wrong and does not help at all. It's question how to do TLB and cache flushes on two and more processors and be sure that everything is OK. It could be slow and maybe, changing memory attributes on the fly is not a good idea at all. Svata From owner-freebsd-arm@FreeBSD.ORG Fri May 18 14:20:50 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1284C106566B; Fri, 18 May 2012 14:20:50 +0000 (UTC) (envelope-from kp@sigsegv.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:51:216:3eff:feb7:3147]) by mx1.freebsd.org (Postfix) with ESMTP id 927DC8FC1B; Fri, 18 May 2012 14:20:49 +0000 (UTC) Received: from adrastea.jupiter.sigsegv.be (adrastea.jupiter.sigsegv.be [IPv6:2001:6f8:1498:1::3]) by mercury.codepro.be (Postfix) with ESMTP id 3317052F; Fri, 18 May 2012 16:20:48 +0200 (CEST) Received: from thebe.jupiter.sigsegv.be (thebe.jupiter.sigsegv.be [172.16.1.5]) by adrastea.jupiter.sigsegv.be (Postfix) with ESMTP id A286FD097; Fri, 18 May 2012 16:20:17 +0200 (CEST) Received: by thebe.jupiter.sigsegv.be (Postfix, from userid 1000) id 8B3AB1B79F; Fri, 18 May 2012 16:20:17 +0200 (CEST) Date: Fri, 18 May 2012 16:20:17 +0200 From: Kristof Provost To: Michael Moll Message-ID: <20120518142017.GV31195@thebe.jupiter.sigsegv.be> References: <201205181207.q4IC7fs8044727@freefall.freebsd.org> <20120518121318.GA91772@darkthrone.kvedulv.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120518121318.GA91772@darkthrone.kvedulv.de> X-PGP-Fingerprint: E114 D9EA 909E D469 8F57 17A5 7D15 91C6 9EFA F286 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm@FreeBSD.org, linimon@freebsd.org, bug-followup@FreeBSD.org Subject: Re: arm/154189: lang/perl5.12 doesn't build on arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:20:50 -0000 On 2012-05-18 14:13:18 (+0200), Michael Moll wrote: > On Fri, May 18, 2012 at 12:07:41PM +0000, linimon@FreeBSD.org wrote: > > Did the compiler fix committed in arm/161128 fix this problem? > > My ARM-hardware went out of order, so I can't test it. However, someone > on freebsd-arm could maybe? > lang/perl5.12 builds and runs on my OpenRD. Regards, Kristof From owner-freebsd-arm@FreeBSD.ORG Sat May 19 15:54:16 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 3C95A106566C; Sat, 19 May 2012 15:54:16 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id F3CBB8FC12; Sat, 19 May 2012 15:54:15 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:889:fc08:3271:d956]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id ED7A74AC2D; Sat, 19 May 2012 19:54:14 +0400 (MSK) Date: Sat, 19 May 2012 19:54:08 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <15910458724.20120519195408@serebryakov.spb.ru> To: freebsd-embedded@FreeBSD.org, freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Does -CURRENT support *Plug "computers? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 15:54:16 -0000 Hello, Freebsd-embedded. Does -CURRENT support SheevaPlug/GuruPlug/DreamPlug computers, based on Marvell ARM CPUs? -- // Black Lion AKA Lev Serebryakov From owner-freebsd-arm@FreeBSD.ORG Sat May 19 16:16:16 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 88BD5106566C; Sat, 19 May 2012 16:16:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 2BF5B8FC1B; Sat, 19 May 2012 16:16:16 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4JGBeTp005659 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 19 May 2012 10:11:40 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh X-Priority: 3 (Normal) In-Reply-To: <15910458724.20120519195408@serebryakov.spb.ru> Date: Sat, 19 May 2012 10:11:40 -0600 Content-Transfer-Encoding: 7bit Message-Id: <0B759071-D141-4AEA-B91C-A2923C8D7D5C@bsdimp.com> References: <15910458724.20120519195408@serebryakov.spb.ru> To: lev@FreeBSD.org X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sat, 19 May 2012 10:11:40 -0600 (MDT) Cc: freebsd-arm@FreeBSD.org, freebsd-embedded@FreeBSD.org Subject: Re: Does -CURRENT support *Plug "computers? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 16:16:16 -0000 On May 19, 2012, at 9:54 AM, Lev Serebryakov wrote: > Does -CURRENT support SheevaPlug/GuruPlug/DreamPlug computers, based > on Marvell ARM CPUs? Yes. Warner