>Number:         31912
>Category:       port-evbmips
>Synopsis:       Au1500 OHCI doesn't work when CPU is little endian...
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-evbmips-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 25 01:33:01 +0000 2005
>Originator:     Garrett D'Amore
>Release:        
>Organization:
Tadpole Computer, Inc.
>Environment:
NetBSD cabernet 3.99.10 NetBSD 3.99.10 (PB1000) #17: Mon Oct 24 14:32:47 PDT 2005  garrett@zippy:/home/garrett/work/meteor/netbsd/src/sys/arch/evbmips/compile/obj/PB1000 evbmips
cabernet# 

>Description:
If OHCI is configured in the kernel, and you have built little endian, the system panics fairly early in the boot strap with error messages claiming scheduling overruns (lots and lots of them (see ohci.c line 1168), and then a fatal panic on ohci.c line 1290:

		panic("ohci_softintr: addr 0x%08lx not found", (u_long)done);

I don't have the console output handy right now, but the addresses seem different each time.

Notably, the big endian build on the same machine works fine.  (Yes, obviously I use different root filesystems depending on the CPU endiannes, and I am using the appropriate jumper on the Au1500 board to select the endianness to match my kernel image.)

I've looked at this for a bit, but I'm not seeing the root cause.  Note that I've also tried setting the UE_BE bit in the USB_HENABLE register, and it doesn't seem to change the behavior, regardless of whether or not it is set.

Perhaps we need to perform an endian swap that isn't getting done in the au_cpureg_mem?  (The Au1550 spec seems to suggest that peripheral and system busses are separated, and may have separate endian swapping considerations.)

I will test this and if I find that this is the case, I will submit diffs.

>How-To-Repeat:
./build.sh -T ${TOOLS_DIR} -m evbmips-eb kernel=PB1000

Boot the resulting kernel on an Au1500 board.  (Note that after changes are made to the code to adjust for memory locations, the same problem happens on an Au1550 board.)
>Fix: