From owner-freebsd-arm@FreeBSD.ORG Fri Jul 17 11:10:14 2009 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 3AFBB1065670; Fri, 17 Jul 2009 11:10:14 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD978FC12; Fri, 17 Jul 2009 11:10:12 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hrwt8fWgTlIA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=6I5d2MoRAAAA:8 a=Wfte-A8PZ4CvN3Pqc4oA:9 a=K1papP_sE1_jh7A71HkA:7 a=D3J5flF0k_qGl-iQSlEjpUw5UdoA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1110142483; Fri, 17 Jul 2009 13:10:09 +0200 From: Hans Petter Selasky To: Rafal Jaworowski Date: Fri, 17 Jul 2009 13:09:50 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200906231035.43096.kosmo@semihalf.com> <200907162156.06598.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907171309.52316.hselasky@c2i.net> Cc: Marcel Moolenaar , freebsd-usb@freebsd.org, freebsd-arm@freebsd.org, thompsa@freebsd.org, cognet@freebsd.org, Piotr =?utf-8?q?Zi=C4=99cik?= Subject: Re: CPU Cache and busdma usage in USB 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, 17 Jul 2009 11:10:14 -0000 On Friday 17 July 2009 12:23:57 Rafal Jaworowski wrote: > On 2009-07-16, at 21:56, Hans Petter Selasky wrote: > > On Tuesday 14 July 2009 19:20:22 Rafal Jaworowski wrote: > >>>> Please note these problems should be considered as a showstopper > >>>> for the release since USB is currently broken on at least three ARM > >>>> platforms in the tree (Marvell). > > > > Hi, > > > > First of all I'm not able to boot into userland on my ARM board. > > Maybe I > > missed something. I'm using a custom built userland image. > > > > Trying to mount root from ufs:/dev/md0 > > warning: no time-of-day clock registered, system time will not be set > > accurately > > Jul 16 18:53:22 init: login_getclass: unknown class 'daemon' > > Fatal kernel mode data abort: 'Alignment Fault 3' > > trapframe: 0xc622cc60 > > FSR=00000003, FAR=6e75203a, spsr=600000d3 > > r0 =60000093, r1 =c10594a0, r2 =c10594a0, r3 =00000002 > > r4 =c10acbd0, r5 =00000000, r6 =6e75203a, r7 =c10594a0 > > r8 =c622cd74, r9 =00000000, r10=c0ab081c, r11=c622cccc > > r12=c622ccac, ssp=c622ccac, slr=c020a144, pc =c00c02c8 > > > > [thread pid 4 tid 100008 ] > > Stopped at _thread_lock_flags+0x24: ldr r4, [r6] > > db> > > Just making sure: your kernel and world are in sync, correct? Yes, I made a clean toolchain, a clean buildworld and a clean buildkernel. > > > With the following patch in arm/cpufunc.c my UMASS device gets > > detected at > > boot time (KB9202B ARM board). Else I get a USB request timeout > > followed by a > > panic. But data transfers of more than 16KByte are likely to be > > broken. > > > > struct cpu_functions arm9_cpufuncs = { > > ... > > - /*XXX*/ arm9_dcache_wbinv_range, /* dcache_inv_range */ > > + /*XXX*/ arm9_dcache_inv_range, /* dcache_inv_range */ > > > > }; > > Hm, this looks indeed strange, but I have no idea why both methods > point to _wbinv_range; it seems like it was there from the beginning. > I also looked at NetBSD code (from which FreeBSD/arm originates) and > they still have it this way too... > > Olivier, any thoughts why this was done this way? > > (FYI: the cpu we work with fall under ARM9E/ARM10, but the situation > with dcache_inv_range() is similar as for ARM9 case above). > > > Piotr and Rafal: How does ARM work? Are there two caches? One read > > cache and > > one write cache. Or are they the same. What happens if you read a > > value from > > RAM into cache, then writeback+invalidate it. Does it get written > > back to RAM > > or does it get discarded? Sorry, I have some holes in my ARM > > knowledge which > > you need to fill in. > > I don't know what separate read/write CPU caches would be; some > implementations allow for locking [parts of] cache contents, so it can > mimic read-only, but it's probably not what you're asking for. Usually > there's cache at various levels, dedicated for data/instructions, or > unified, depending on implementation with different characteristics > (associativity etc.). It seems you need to read about cache basics, as > there are many aspects, and one of the foremost is we have VIVT > approach (virtual indexed, virtual tagged) in this context, as opposed > to physical approach. > > > Reference: > > > > ENTRY(arm9_dcache_inv_range) > > ldr ip, .Larm9_line_size > > cmp r1, #0x4000 > > bcs .Larm9_dcache_wbinv_all > > > > Anything unclear? > > Sorry, but what is the question? I was just pointing out in the assembly code, the fact that the invalidate range call can in some cases do a writeback invalidate. > > > Are there any pending patches which I should have put into the code > > before > > building? > > There are pmap fixes pending, which will be commited shortly > http://people.freebsd.org/~raj/patches/arm/pmap-fixes.diff although > according to stas@ they had no visible effect on AT91 (but they fix real > issues in pmap, possibly just not [yet] observed on AT91). Ok. --HPS