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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
