From owner-freebsd-arm@FreeBSD.ORG Thu Dec 27 03:52: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 52374192 for ; Thu, 27 Dec 2012 03:52:44 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) by mx1.freebsd.org (Postfix) with ESMTP id AF5278FC0C for ; Thu, 27 Dec 2012 03:52:43 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id BD34739FA3; Thu, 27 Dec 2012 12:52:41 +0900 (JST) Received: from artemis (unknown [172.18.0.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id A8CF039D5E; Thu, 27 Dec 2012 12:52:41 +0900 (JST) Message-ID: <2BA73CBF02B04DD19D08CDFC556B8750@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Oleksandr Tymoshenko" References: In-Reply-To: Subject: Re: FreeBSD/armv6z/clang on Raspberry Pi 512MB (with U-Boot + ubldr) Date: Thu, 27 Dec 2012 12:52:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2012 03:52:44 -0000 >PTE sync - related part, Im not sure it's strictly required. We use WT >caches for page tables >so we should be OK without implicit sync operations for them. I hope >somebody >more clueful can confirm/disprove this. Some digging, I notice "Invalidate Entire Instruction Cache" works without segfault. So, Invalidate D-cache is no effect :) It seems following should work for this issue: mov r0, #0 mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire Instruction Cache */ mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization Barrier */ Try this code instead of CF_ICACHE_SYNC. I don't know side effect of Invalidate I-cache, but it works. Also I don't know whether DSB is required or not. For test, using NFS or HDD/SDD is BAD idea for system stress. You must use SD(mmc) or USB memory. Serial console is recommended for interrupt test. Here is simple test from serial console: # rm -rf /var/db/portsnap /usr/ports # mkdir /var/db/portsnap # portsnap fetch # portsnap extract # cd /usr/ports/shells/bash # make BATCH=y If your kernel is really stable, it should finish without any problems with SD/mmc. ---------------------------------------------------------------------- --- sys/arm/arm/swtch.S (revision 244663) +++ sys/arm/arm/swtch.S (working copy) @@ -130,7 +130,11 @@ /* Switch to lwp0 context */ ldr r9, .Lcpufuncs -#if !defined(CPU_ARM11) && !defined(CPU_CORTEXA) && !defined(CPU_MV_PJ4B) +#if defined(CPU_ARM1176) + mov r0, #0 + mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire Instruction Cache */ + mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization Barrier */ +#elif !defined(CPU_CORTEXA) && !defined(CPU_MV_PJ4B) mov lr, pc ldr pc, [r9, #CF_IDCACHE_WBINV_ALL] #endif @@ -352,7 +356,11 @@ cmpeq r0, r5 /* Same DACR? */ beq .Lcs_context_switched /* yes! */ -#if !defined(CPU_ARM11) && !defined(CPU_CORTEXA) && !defined(CPU_MV_PJ4B) +#if defined(CPU_ARM1176) + mov r0, #0 + mcr p15, 0, r0, c7, c5, 0 /* Invalidate Entire Instruction Cache */ + mcr p15, 0, r0, c7, c10, 4 /* Data Synchronization Barrier */ +#elif !defined(CPU_CORTEXA) && !defined(CPU_MV_PJ4B) /* * Definately need to flush the cache. */ ---------------------------------------------------------------------- Thanks. -- Daisuke Aoyama