Date: Fri, 17 Jul 2009 12:23:57 +0200 From: Rafal Jaworowski <raj@semihalf.com> To: Hans Petter Selasky <hselasky@c2i.net>, cognet@freebsd.org Cc: thompsa@freebsd.org, freebsd-arm@freebsd.org, Marcel Moolenaar <marcel@freebsd.org>, =?ISO-8859-2?Q?Piotr_Zi=EAcik?= <kosmo@semihalf.com>, freebsd-usb@freebsd.org Subject: Re: CPU Cache and busdma usage in USB Message-ID: <F04328A2-99F7-4F00-B03B-9EFEC51B28C4@semihalf.com> In-Reply-To: <200907162156.06598.hselasky@c2i.net> References: <200906231035.43096.kosmo@semihalf.com> <E4BEDDE0-2872-4934-9A53-4121E33390B5@mac.com> <B8FCBB1F-F294-4252-82AE-1466631E548F@semihalf.com> <200907162156.06598.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
> 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?
> 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).
Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F04328A2-99F7-4F00-B03B-9EFEC51B28C4>