Hi, Genode crowd!
I've been porting the MUSB OTG driver for the OMAP4 platform to the Genode Framework.
I have implemented the following: * some linux routines for platform devices (to manage resources) * added code for some stubs in dde kit (strings, mutexes, spin locks) * the I2C driver class for Genode and ported the OMAP4 I2C driver * the TWL controller routines to read/write registers * misc omap4 phy init (clocks and other registers)
This has allowed me to compile and run the musb driver and the gadget drivers (zero, ethernet) from the linux kernel. However, I've been desperately trying to figure out why it is not working.
I have enabled all the levels of debugging in the usb drivers and have dumped the MUSB FIFO in both linux and genode. The good thing is that the data is not all zeroes or all ones, but correct usb requests starting with 0x80. I think this indicates memory IO is working.
The bad thing is that under linux I get the correct usb requests (80 06, that is, GET_DESCRIPTOR). Under genode I either get SET_DESCRIPTOR or SET_ADDRESS all the time and the host (desktop) says "device descriptor read/64, error -32".
Does anyone have any idea what may have gone wrong? IO and register access seems to work so I'm lost here.
I have pushed the code to my github if you may want to try it out yourself git://github.com/astarasikov/genode.git The branch is omap4-otg-dirty. I have also pushed the 'contrib' directory because I was lazy to prepare the patches and fight Makefiles until the driver is working. My run script is called "panda_otg.run" (in my personal directory, astarasikov/run).
I have also made the kernel message dumps in linux and genode so that it's possible to compare how usb behaves. I have also disabled L2 cache in uboot since it caused a lot of trouble with framebuffer previously.
http://pastebin.ca/2239708 http://pastebin.ca/2239709
Note that I have the commented out the setting up interrupts part for the omap4 twl. Actually, zero is returned as the default irq number which is timer. I have tested with both the correct irq number and the zero interrupt, it does not affect anything - in both cases the device does detect when the cable is plugged, but fails to set up the connection.