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. 

--
Regards, Alexander