CPU Cache and busdma usage in USB

[Hans Petter Selasky]

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