USB host controller using the Motorola PowerPC MPX8xx CPU Brad Parker brad@heeltoe.com 02/03/04 Overview: The MPC850 & 823 "PowerPC" CPU's have some USB functionality integrated into the their Communications Processor Module (CPM) functionality. The USB functionality can be used to create a USB host controller which will support the Linux USB stack. There are, however, some caveats and requirements. It is also possible to create a function or "client" device with the CPM USB functionality. This generally works out of the box without any special hardware support (other than the USB drivers) so we won't discuss that here. The m8xxhic.c driver was originally written to work with the Embedded Planet RPX Lite board. It has since been extended to work with the Brightstar ipEngine. RPX Lite caveats: Rev "CW" boards need an external wire added for the 1Khz signal. Rev "DW" board have internal circuitry to route this signal. The CW & DW boards have pullups which are appropriate only for "function" or client/slave mode. To run as a USB host (i.e. with the m8xxhci driver), you need to remove R74 & R75. Once removed add two 15k "pulldown" resistors from the signal pads of R74 & R75 (i.e. D+ & D-) to ground. Embedded Planet 749 Miner Rd., Highland Heights, OH 44143 Phone: 440-646-0077 Fax: 440-646-4329 http://www.embeddedplanet.com Bright Star ipEngine caveats: The 1khz signal needs to be generated by the FPGA. The simplest thing to do it to route the CLK2 output to the DREQ0 input via the FPGA. A slightly more complex design creates a programmer timer in the FPGA which generates the DREQ0 and an interrupt. I can provide AHDL samplesof both options. 15k pulldown resistors are required on D+ & D- for proper host controller operation. Bright Star Engineering Inc. 19 Enfield Drive Andover MA 01810 978-470-8738 978-470-8878 (FAX) http://www.brightstareng.com Issues: - To be a valid host controller you need to generate SOF packets every 1ms. The tolerance is +/- 500ns. This is way beyond what a normal linux kernal can do. It's not uncommon for interrupts to be delayed 3-5ms in a 2.2 or 2.4 kernel. Trust me on this one. It might be possible to get 1ms accurate interrupts using RTLinux but a stock kernel can't do it. If the SOF's don't get generated accurately your devices will go to sleep and stop responding. - High vs. low speed devices. All mice and keyboards are low speed devices. If you want to support them you must have an 8xx with the right microcode. Cameras, speakers, disks, etc.. are always high speed devices. Hubs are also always high speed devices. It is very common that a keyboard is actually a high speed hub with a low speed keyboard and several ports attached to it. Specifics: Not all MPC8XX processors will support a USB host controller driver. Specifically: MPC823A - wont work as microcode does not support low speed devices (might work on high speed only, but I've never tried) MPC823B - works fun. the prefered device. MPC850 - early revs are high speed only. Later revs have fixed microcode. MPC860 - I don't think it supports USB. There is specific information on mask levels in the driver source code. Hardware: In order to get the CPM to generate an SOF packet every 1ms, you need to do two things. 1. install a microcode patch 2. apply a 1Khz signal to PC15 The patch is small and basically generates the SOF packet. Care is taken in the driver not to "crash into" the generation of this packet. It seems that if the driver tries to send a frame at the same time the patch is active the CPM locks up. It's tricky to know when the SOF is going to be sent, however. The MOT documentation for the patch claims that an SOF interrupt will be generated. This is hog wash. The patch doesn't generate any interrupt. What they are really saying (I checked) is that if you use a USB trasceiver (like the one made by Philips, used on the ADS board) the recieve side is not turned off during transmit and the CPM will "hear" it's own SOF being sent and generate an interrupt. A total hack, but it works. The trouble is if you use a tranceiver like the one made by Sipex, the receive side is disabled during transmit and the CPM will not hear the SOF. In the driver the code syncs up an internal timer interrupt to the SOF and uses the internal timer to keep track of when SOF's will occur... Here's a quote from the MOT patch docs: "The trigger for the transmission of SOF is a 1Khz signal that should be applied to the DREQ1 pin (PC[15], pin R16). This signal can be generated by a CPM timer or BRG, dividing the system clock. There should be external connection between the timer/BRG output and the DREQ1 input. The falling edge of the 1 Khz signal will trigger the transmission of the SOF packet. The s/w is responsible to prepare the SOF packet payload (frame number and CRC5) ahead of time. The s/w is also responsible to guaranty that the transmitter is free (i.e. there are no ongoing transactions) for the SOF transmission. In case that the transmitter is not free, the SOF packet will not be sent. At the completion of the SOF transmission, a maskable SOF interrupt (USBER register bit 12) is generated to notify the s/w that it may start the frame s transactions, and prepare the SOF payload (frame number and CRC5) for the next frame." Software: drivers/usb/m8xxhci.c drivers/usb/m8xxhci.h Host controller driver for MPC850 & 823B. arch/ppc/8xx_io/microcode.c USB SOF microcode patch fro MPC850 & MPC823