From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 14:30:09 2008 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 5E3151065679; Fri, 19 Dec 2008 14:30:09 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id B530B8FC29; Fri, 19 Dec 2008 14:30:08 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id mBJE6qrB003290; Fri, 19 Dec 2008 07:06:53 -0700 Message-ID: <494BAA90.7000801@semihalf.com> Date: Fri, 19 Dec 2008 15:07:12 +0100 From: Grzegorz Bernacki MIME-Version: 1.0 To: arm@freebsd.org, embedded@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Multiple virtual mappings considered harmful 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, 19 Dec 2008 14:30:09 -0000 Hi, I've investigated lately problem with data corruption when copying big files on ARM machine. Below are my findings. 1. High level scenario. Problem occurs during copying of big files (~300MB and more). Calculated MD5 checksums for original and copied files are different. Chunks of data which get corrupted have always 32 bytes in length i.e. cache line length. 2. Root cause. The root cause of the problem is additional virtual mapping of read/write buffers at cluster read/write (sys/kern/vfs_cluster.c, cluster_rbuild(), cluster_wbuild(). Buffers for sequential read/write operation are concatenated and sent to device as one big buffer. Concatenation of buffers uses pmap_qenter(), which puts *additional* mapping in the KVA for physical area already mapped. For each buffer we extract pages it contains and then all the pages from all the buffers are mapped into new virtual address of new buffer. So we end up with at least two virtual addresses for each page. Such scenario on systems with virtual cache (most ARMs) leads to serious problems: we can have unflushed modified data pertaining to the same physical pages cached in separate cache blocks: data written back first (associated with virtual mapping #1) is potentially overwritten by data associated with virtual mapping #2 when its cache content is written back later, or vice versa. 3. Workaround for FFS read/write problems - avoid clustered reading/writing on ARM: # mount -o noclusterr -o noclusterw /dev/da0a /mnt/ 4. More general solution. This is the second time we indentified a problem of the same nature related to multiple virtual mapping on ARM, and are wondering about some more general solution that would prevent us from such problems (very subtle and hard to nail down) in the future. We were thinking at least about an extension to DIAGNOSTIC that would detect such attempts or so. Any other suggestions or comments welcome. From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 14:57:00 2008 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 89F091065673; Fri, 19 Dec 2008 14:57:00 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from semihalf.com (semihalf.com [206.130.101.55]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7098FC1B; Fri, 19 Dec 2008 14:57:00 +0000 (UTC) (envelope-from gjb@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by semihalf.com (8.13.1/8.13.1) with ESMTP id mBJEundq021537; Fri, 19 Dec 2008 07:56:50 -0700 Message-ID: <494BB647.2060807@semihalf.com> Date: Fri, 19 Dec 2008 15:57:11 +0100 From: Grzegorz Bernacki MIME-Version: 1.0 To: Mark Tinguely References: <200812191452.mBJEqnaM040259@casselton.net> In-Reply-To: <200812191452.mBJEqnaM040259@casselton.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, embedded@freebsd.org Subject: Re: Multiple virtual mappings considered harmful 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, 19 Dec 2008 14:57:00 -0000 Mark Tinguely wrote: > > which version of FreeBSD (7 or -current). > It is -current. pozdrawiam, Grzesiek From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 15:03:42 2008 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 8E857106564A; Fri, 19 Dec 2008 15:03:42 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 38C4D8FC19; Fri, 19 Dec 2008 15:03:42 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id mBJEqnJC040260; Fri, 19 Dec 2008 08:52:49 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1229698369; bh=WOYpNTKxdoShlol/DSYPKiyETDY5u5ldNCtJPF/ WHwg=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=mbSsQ3CUlu5 sPvqJ9Vmh+iWBXunIfltRypaWrt2arD7pwlERaWNZCd+7wF9oE6yYhyFlmtzsb50kJX ZQmbikv7hdYTslcHUA4IBAYnjXGqXwII4HAR92u/zV3thH/hOvnBhWqzZYQIthxdKyT YuEAUEo10KE8QvY/GJV/6x3Mh4= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id mBJEqnaM040259; Fri, 19 Dec 2008 08:52:49 -0600 (CST) (envelope-from tinguely) Date: Fri, 19 Dec 2008 08:52:49 -0600 (CST) From: Mark Tinguely Message-Id: <200812191452.mBJEqnaM040259@casselton.net> To: arm@freebsd.org, embedded@freebsd.org, gjb@semihalf.com In-Reply-To: <494BAA90.7000801@semihalf.com> Cc: Subject: Re: Multiple virtual mappings considered harmful 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, 19 Dec 2008 15:03:42 -0000 > I've investigated lately problem with data corruption when copying big files > on ARM machine. Below are my findings. ... which version of FreeBSD (7 or -current). --Mark Tinguely. From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 16:11:28 2008 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 F1E681065674; Fri, 19 Dec 2008 16:11:28 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id B57A28FC2E; Fri, 19 Dec 2008 16:11:28 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.2/8.14.2) with ESMTP id mBJGBRuS044292; Fri, 19 Dec 2008 10:11:27 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1229703087; bh=9qbdqjuoxEdZHeTGe+3ABEz71k8pwh6T8g67Hj2 8+WA=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=KySDFpGT k/H2HRDT4l3YIVPHIaKmUWJnWpl0mBWNg+UFon9tu2yctahjpLBMeCDeAO0keY1lc5s oX6OxDau2g0QmLx4wNuT5P5BKr73xYHR8DhuVlKLfyHztu0rhplGhxtUqIfiDhiBXaq bWPYNOWpcbPyJfHDFK2iJeDQ+U8mY= Received: (from tinguely@localhost) by casselton.net (8.14.2/8.14.2/Submit) id mBJGBRna044291; Fri, 19 Dec 2008 10:11:27 -0600 (CST) (envelope-from tinguely) Date: Fri, 19 Dec 2008 10:11:27 -0600 (CST) From: Mark Tinguely Message-Id: <200812191611.mBJGBRna044291@casselton.net> To: gjb@semihalf.com, tinguely@casselton.net In-Reply-To: <494BB647.2060807@semihalf.com> Cc: arm@freebsd.org, embedded@freebsd.org Subject: Re: Multiple virtual mappings considered harmful 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, 19 Dec 2008 16:11:29 -0000 Looking at the pmap code real quick, I think the original authors assumed quick kernel entries were not shared. Since they can be, we should have to add pv_entrys and the cache vac/fix process on the pmap_kenter_internal called routines too. I am still thinking the ARM code should revolve to FreeBSD style (recursive page tables, make SMP ready, etc). --Mark. From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 16:48:47 2008 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 1CBC91065677; Fri, 19 Dec 2008 16:48:47 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D71268FC1B; Fri, 19 Dec 2008 16:48:46 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id mBJGlSnk031441; Fri, 19 Dec 2008 09:47:28 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 19 Dec 2008 09:47:32 -0700 (MST) Message-Id: <20081219.094732.461359941.imp@bsdimp.com> To: gjb@semihalf.com From: "M. Warner Losh" In-Reply-To: <494BAA90.7000801@semihalf.com> References: <494BAA90.7000801@semihalf.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@FreeBSD.org, embedded@FreeBSD.org Subject: Re: Multiple virtual mappings considered harmful 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, 19 Dec 2008 16:48:47 -0000 In message: <494BAA90.7000801@semihalf.com> Grzegorz Bernacki writes: : 2. Root cause. ... : So we end up with at least two virtual addresses for each page. ... : 4. More general solution. : This is the second time we indentified a problem of the same nature related to : multiple virtual mapping on ARM, and are wondering about some more general : solution that would prevent us from such problems (very subtle and hard to : nail down) in the future. We were thinking at least about an extension to : DIAGNOSTIC that would detect such attempts or so. Any other suggestions or : comments welcome. I think this is an excellent idea. MIPS will need this too, since it too suffers from the virtual aliasing problem. Warner From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 18:30:40 2008 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 231AD106564A; Fri, 19 Dec 2008 18:30:40 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 118498FC1E; Fri, 19 Dec 2008 18:30:40 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from mdenny-t60.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KC400I0UWMYEW90@asmtp018.mac.com>; Fri, 19 Dec 2008 09:30:34 -0800 (PST) Message-id: From: Marcel Moolenaar To: Grzegorz Bernacki In-reply-to: <494BAA90.7000801@semihalf.com> Date: Fri, 19 Dec 2008 09:30:33 -0800 References: <494BAA90.7000801@semihalf.com> X-Mailer: Apple Mail (2.930.3) Cc: arm@freebsd.org, embedded@freebsd.org Subject: Re: Multiple virtual mappings considered harmful 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, 19 Dec 2008 18:30:40 -0000 On Dec 19, 2008, at 6:07 AM, Grzegorz Bernacki wrote: > 2. Root cause. > The root cause of the problem is additional virtual mapping of read/ > write > buffers at cluster read/write (sys/kern/vfs_cluster.c, > cluster_rbuild(), > cluster_wbuild(). Buffers for sequential read/write operation are > concatenated > and sent to device as one big buffer. Concatenation of buffers uses > pmap_qenter(), which puts *additional* mapping in the KVA for > physical area > already mapped. For each buffer we extract pages it contains and > then all the > pages from all the buffers are mapped into new virtual address of > new buffer. > So we end up with at least two virtual addresses for each page. Could this also affect I-cache coherency by virtue of not flushing the D-cache properly before synchronizing the I-cache, as you mention reading? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-arm@FreeBSD.ORG Fri Dec 19 18:45:52 2008 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 6233F1065676 for ; Fri, 19 Dec 2008 18:45:52 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 4DEF38FC12 for ; Fri, 19 Dec 2008 18:45:52 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_6aRa5zsxN2/Qv99f8U55DA)" Received: from mohan-pc.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KC5008CM03OS630@asmtp011.mac.com> for arm@freebsd.org; Fri, 19 Dec 2008 10:45:25 -0800 (PST) Message-id: <4CEE2ADA-1827-463B-8174-C2204C05442D@mac.com> From: Marcel Moolenaar To: arm@freebsd.org Date: Fri, 19 Dec 2008 10:45:23 -0800 X-Mailer: Apple Mail (2.930.3) Cc: Subject: Support for FPA float on LE 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, 19 Dec 2008 18:45:52 -0000 --Boundary_(ID_6aRa5zsxN2/Qv99f8U55DA) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT All, As mentioned before, we (read: Juniper) need support for FPA floating-point. FPA is like VFP, except that it's always stored in big-endian. For ARMEB this obviously is exactly the same as VFP, but for ARMEL this needs a tweak. See attached patch. Does this make sense? -- Marcel Moolenaar xcllnt@mac.com --Boundary_(ID_6aRa5zsxN2/Qv99f8U55DA) Content-type: application/octet-stream; x-unix-mode=0644; name=fpa-fbsd.diff Content-transfer-encoding: 7bit Content-disposition: attachment; filename=fpa-fbsd.diff Index: lib/msun/src/math_private.h =================================================================== --- lib/msun/src/math_private.h (revision 186331) +++ lib/msun/src/math_private.h (working copy) @@ -38,8 +38,18 @@ * ints. */ -#if BYTE_ORDER == BIG_ENDIAN +#ifdef __arm__ +#if defined(__VFP_FP__) || defined(__ARMEB__) +#define IEEE_WORD_ORDER BYTE_ORDER +#else +#define IEEE_WORD_ORDER BIG_ENDIAN +#endif +#else /* __arm__ */ +#define IEEE_WORD_ORDER BYTE_ORDER +#endif +#if IEEE_WORD_ORDER == BIG_ENDIAN + typedef union { double value; @@ -52,7 +62,7 @@ #endif -#if BYTE_ORDER == LITTLE_ENDIAN +#if IEEE_WORD_ORDER == LITTLE_ENDIAN typedef union { Index: lib/libc/arm/_fpmath.h =================================================================== --- lib/libc/arm/_fpmath.h (revision 186331) +++ lib/libc/arm/_fpmath.h (working copy) @@ -26,15 +26,26 @@ * $FreeBSD$ */ +#if defined(__VFP_FP__) || defined(__ARMEB__) +#define _IEEE_WORD_ORDER _BYTE_ORDER +#else +#define _IEEE_WORD_ORDER _BIG_ENDIAN +#endif + union IEEEl2bits { long double e; struct { -#ifndef __ARMEB__ +#if _BYTE_ORDER == _LITTLE_ENDIAN +#if _IEEE_WORD_ORDER == _LITTLE_ENDIAN unsigned int manl :32; +#endif unsigned int manh :20; unsigned int exp :11; unsigned int sign :1; -#else +#if _IEEE_WORD_ORDER == _BIG_ENDIAN + unsigned int manl :32; +#endif +#else /* _BYTE_ORDER == _LITTLE_ENDIAN */ unsigned int sign :1; unsigned int exp :11; unsigned int manh :20; Index: lib/libc/arm/arith.h =================================================================== --- lib/libc/arm/arith.h (revision 186331) +++ lib/libc/arm/arith.h (working copy) @@ -11,7 +11,7 @@ * architecture. See contrib/gdtoa/gdtoaimp.h for details. */ -#ifndef __ARMEB__ +#if !defined(__ARMEB__) && defined(__VFP_FP__) #define IEEE_8087 #define Arith_Kind_ASL 1 #define Sudden_Underflow Index: lib/libc/include/fpmath.h =================================================================== --- lib/libc/include/fpmath.h (revision 186331) +++ lib/libc/include/fpmath.h (working copy) @@ -30,6 +30,10 @@ #include #include "_fpmath.h" +#ifndef _IEEE_WORD_ORDER +#define _IEEE_WORD_ORDER _BYTE_ORDER +#endif + union IEEEf2bits { float f; struct { @@ -52,10 +56,15 @@ double d; struct { #if _BYTE_ORDER == _LITTLE_ENDIAN +#if _IEEE_WORD_ORDER == _LITTLE_ENDIAN unsigned int manl :32; +#endif unsigned int manh :20; unsigned int exp :11; unsigned int sign :1; +#if _IEEE_WORD_ORDER == _BIG_ENDIAN + unsigned int manl :32; +#endif #else /* _BIG_ENDIAN */ unsigned int sign :1; unsigned int exp :11; Index: sys/arm/include/ieee.h =================================================================== --- sys/arm/include/ieee.h (revision 186331) +++ sys/arm/include/ieee.h (working copy) @@ -91,6 +91,12 @@ #define DBL_EXPBITS 11 #define DBL_FRACBITS 52 +#if defined(__VFP_FP__) || defined(__ARMEB__) +#define _IEEE_WORD_ORDER _BYTE_ORDER +#else +#define _IEEE_WORD_ORDER _BIG_ENDIAN +#endif + struct ieee_single { #if _BYTE_ORDER == _BIG_ENDIAN u_int sng_sign:1; @@ -110,10 +116,15 @@ u_int dbl_frach:20; u_int dbl_fracl; #else +#if _IEEE_WORD_ORDER == _LITTLE_ENDIAN u_int dbl_fracl; +#endif u_int dbl_frach:20; u_int dbl_exp:11; u_int dbl_sign:1; +#if _IEEE_WORD_ORDER == _BIG_ENDIAN + u_int dbl_fracl; +#endif #endif }; --Boundary_(ID_6aRa5zsxN2/Qv99f8U55DA) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT --Boundary_(ID_6aRa5zsxN2/Qv99f8U55DA)-- From owner-freebsd-arm@FreeBSD.ORG Sat Dec 20 04:14:41 2008 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 B8C3E1065670 for ; Sat, 20 Dec 2008 04:14:41 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7FD308FC13 for ; Sat, 20 Dec 2008 04:14:41 +0000 (UTC) (envelope-from sam@errno.com) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mBK3pqGE042131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Dec 2008 19:51:52 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <494C6BD7.3050708@errno.com> Date: Fri, 19 Dec 2008 19:51:51 -0800 From: Sam Leffler User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Subject: HEADS UP: Cambria support committed 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, 20 Dec 2008 04:14:41 -0000 I just committed support for Gateworks Cambria boards (IXP435) to HEAD. This has major changes for IXP425 users so beware. I know that ARM_USE_SMALL_ALLOC is broken by this (on IXP425 at least); it will be fixed. I think the trampoline code also needs fixups to deal with PHYSADDR changing from 0x10000000 to 0. Sam From owner-freebsd-arm@FreeBSD.ORG Sat Dec 20 15:34:05 2008 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 820EA1065674 for ; Sat, 20 Dec 2008 15:34:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from mail.icecube.wisc.edu (trout.icecube.wisc.edu [128.104.255.119]) by mx1.freebsd.org (Postfix) with ESMTP id 5871C8FC13 for ; Sat, 20 Dec 2008 15:34:05 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id C70335823C; Sat, 20 Dec 2008 09:16:06 -0600 (CST) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id 0G3G18eeywuT; Sat, 20 Dec 2008 09:16:06 -0600 (CST) Received: from wanderer.tachypleus.net (c-71-234-177-38.hsd1.ct.comcast.net [71.234.177.38]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 7A2735823A; Sat, 20 Dec 2008 09:16:06 -0600 (CST) Message-ID: <494D0C23.9050509@freebsd.org> Date: Sat, 20 Dec 2008 09:15:47 -0600 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.18 (X11/20081126) MIME-Version: 1.0 To: =?ISO-8859-2?Q?Rafa=B3_Jaworowski?= References: <20081125.104452.535842403.imp@bsdimp.com> <04BDAB4F-CF02-4CE6-90D8-E03EDC1CC8CC@semihalf.com> <492C74CE.4090808@freebsd.org> <20EB52EA-EA95-42A4-9319-7838F0128447@semihalf.com> In-Reply-To: <20EB52EA-EA95-42A4-9319-7838F0128447@semihalf.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: arm@FreeBSD.org Subject: Re: Code review request: boards on AT91 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, 20 Dec 2008 15:34:05 -0000 Rafał Jaworowski wrote: > On 2008-11-25, at 22:57, Nathan Whitehorn wrote: > >> Rafał Jaworowski wrote: >>> On 2008-11-25, at 18:44, M. Warner Losh wrote: >>> >>> >>>> If anybody wants me to write up where I'm going with this, or answer >>>> any question, please feel free to ask. Also, comments would be nice. >>> >>> I was dreaming once about all-generic initarm() that would have >>> KOBJ-based dispatcher, but am not sure this wouldn't cause some >>> chicken-and-egg issues as some parts of the infrastructure might not >>> be available at such early stages, but didn't investigate this too >>> close, any thoughts? But anyways, even a simple scheme with common >>> logic and function ptrs, which each platform variation would >>> implement their own routines (or use generic), would improve the ARM >>> init code significantly. >> I am about to commit a patch in order to provide Open Firmware >> modularization using KOBJ (coincidentally, this should make >> supporting FDTs much easier). In order to this, I had to make KOBJ >> behave itself when invoked almost at the very beginning of the boot >> process on both PowerPC and SPARC, so you shouldn't have any trouble >> putting this in very early boot on ARM either once this hits the tree. > > Oh, very interesting news, thanks a lot -- I'll definitely look at > your code. This was revision 186347 that I finally committed yesterday. -Nathan