Blogs
| Whew! USB-OTG on ppc405EX |
| Written by Hunter Cobbs |
| Thursday, 21 May 2009 12:19 |
|
I realize it's been a while since my last post because I've been doing my patented "bang my head against a problem untill something breaks", and I've finally fixed the problem. I'm doing some early prototying of a AMCC PPC405EX based board. Here's just a few of my actions so far to let you know how much frustration this one little problem has casued me:
Then comes the next problem. After finally porting in the dwc_otg USB driver to the OpenWRT patched kernel, I went about hooking up some usb-serial devices that we planned to use. They detected properly and registered. The I open up a minicom connection and WAM! 99-100% IRQ usage. Completely bogged down the system. Turns out, the device is running in an IRQ(Slave) mode and triggering interrupts that need to be serviced at an insane rate (had a back log of 89k interrupts at some points). After two weeks of focusing on this problem, I finally noticed something odd in my kernel build. I kept getting warnings during the compilation of dwc_otg about a right shift and left shift that exceeded the bounds of the variable they were operating on. Needless to say, this captured my interest after slogging through IRQs and data sheets for the last week and a half. Digging into the driver, I find that the only places shifts occur is wrapped in a #define that can only be triggered if your DMA controller is 64bit. Which is not good as the DMA Controller on PPC405 series processors are only 32bit in width. So feeling good about myself, I fixed the ppc4xx_dma.h header where this mis-alignment occurred, recompiled the kernel, and kicked it off. It failed horribly. Still in IRQ mode on boot. Nothing I do can change it. I even delved into some rather deep kernel discussion archives and found how to specify module parameters at boot to built-in kernels. NOTHING was working, and the driver would always fail to load when I attempted to force it into DMA mode. Even hard-coding the dma mode in the root driver parameters structure would fail. Finally, I hit upon a brainstorm that its not enabling DMA that's the problem; Something must be forcing us to never even consider DMA. And since the DMA support was trying to access in 64bit instead of 32bit mode, the original developers must have been having a hell of a time themselves, and forced the DMA not to be built. So, I had to go spelunking. After trudging through the dwc_otg driver code, I stumbled upon a #if defined (xxx) that forced the device into Slave(non-DMA) mode. Getting that feeling every engineer knows when he's about to make a break-through, I did a kernel-wide search for that #define. And guess where I found it? It was a compile-time option for the 405EX/r in the dwc_otg Makefile. Amazingly once I fixed the DMA alignment issue and took out the forced Slave mode, I have a DMA-accessible USB-OTG device! I am going to be submitting a patch back upstream to DENX that enables the DMA access to the USB-OTG as well as general DMA access on the PPC4xx platform as the dwc_otg driver is not in the main kernel. Who knows, I may get brave and try to port these fixes into a newer kernel (currently I'm running 2.6.25 that is patched to hell and back). I'm posting this from my iPhone, so I'll fill in more detail later. Guess I might even post my patches here fir the fun of it.
Edit: 22-MAY-2009 OK, I'm currently getting the latest stable DENX 2.6 git release. They are the only trees I'm aware of that has this particular driver in their source tree, but the generic DMA header file definitely needs to be update if this driver ever wants to make it into the standard tree, so... if nothing else, I'll have my fingerprints on it. When I finally get the patches done, I'll add them here and post them in the linux-ppc dev mailing list.
Patches are IN! Lest see if I can set these up right. dwc_otg Driver Patches: |
