
Hi,
I am trying to get the PCI OHCI driver (drivers/usb_ohci.c in the u- boot-usb.git archive) to work on a MIPS 4KEc system, but facing a couple of problems:
Endianess poses a problem in that the 4KEc runs in little endian mode and #defining LITTLEENDIAN still introduces some swaps that should not be done. My guess is that USB has only been used on big endian CPUs. For the time being I have removed all the swaps, just to get the driver going. Once the driver is working I will put the swaps back in.
A more nasty problem has to do with address spaces: MIPSen always use virtual memory, even when the MMU is off. For example: kernel code (and thus U-Boot too) runs in host memory from 0x80000000 to 0x9FFFFFFF (cached) or 0xA0000000 to 0xBFFFFFFF (uncached). Both these memory spaces are mapped to physical memory 0x00000000 to 0x1FFFFFFF.
As far as I can see the PCI OHCI driver does not do address translations when moving addresses (pointers) to and from the host controller. For example the HcHCCA register is programmed with a virtual address, not the physical address as it should be. Likewise for the HcControlHeadED register and the other memory pointers used by the controller. This leads to PCI bus errors (e.g. Received Master Abort errors) when the driver initialises the root hub.
The instances where these registers are written are easy enough to find and fix, but the code manipulating the endpoint descriptors is much more difficult. It is hard to figure out when a particular pointer is handed off to the controller and when it is actually used by the CPU.
The original Linux driver (from a 2.4 release if I am not mistaken) does cater for the translation between kernel virtual memory addresses and device physical addresses. To fix the address translations my idea is to take the Linux OHCI driver from which the U-Boot driver was derived and do a careful comparison of the two, moving the address translations back into the U-Boot driver.
Therefore two questions: From which Linux kernel version is the U-Boot PCI OCHI driver derived? Is the above approach viable or is there a better strategy?
Thanks in advance.
With kind regards, Hans Zuidam -- Hans Zuidam De Koppele 136, 5632 LD Eindhoven, The Netherlands Tel. +31 40 2481546, Mob. +31 6 42345456 h.zuidam@computer.org