Date: Fri, 17 Jul 2009 13:09:50 +0200 From: Hans Petter Selasky <hselasky@c2i.net> To: Rafal Jaworowski <raj@semihalf.com> Cc: Marcel Moolenaar <marcel@freebsd.org>, freebsd-usb@freebsd.org, freebsd-arm@freebsd.org, thompsa@freebsd.org, cognet@freebsd.org, Piotr =?utf-8?q?Zi=C4=99cik?= <kosmo@semihalf.com> Subject: Re: CPU Cache and busdma usage in USB Message-ID: <200907171309.52316.hselasky@c2i.net> In-Reply-To: <F04328A2-99F7-4F00-B03B-9EFEC51B28C4@semihalf.com> References: <200906231035.43096.kosmo@semihalf.com> <200907162156.06598.hselasky@c2i.net> <F04328A2-99F7-4F00-B03B-9EFEC51B28C4@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200907171309.52316.hselasky>