Hey All,
I’ve just tried to move my BeagleBone from the TI provided BSP (Argo Linux 3.2 Release 04.06.00.11) to one of the newer community kernels from https://github.com/beagleboard/kernel.
I’m not using any distro, just a busybox based rootfs.
My motivations for moving to the later kernels are to gain Device Tree and a bunch of other drivers for some I2C devices as well as the TPS PMIC backlight (ultimately this will be used on a Beaglebone based custom design). I figured it would be easier to move forward that to reverse engineer these drivers into the old 3.2 kernel.
Everything seems to work, except for one of the USB use cases I’m interested in. I’m able to mount a USB stick and copy a couple of gigs of data between the two without any issues. However, when I try to communicate with a CP2102 USB UART I very quickly seem to hang the driver. This worked fine in the old 3.2 kernel.
It seems to send a bunch of data (but It doesn’t seem to arrive on the other end of the UART) and then the TX buffer fills and causes my sending test app (https://gist.github.com/anonymous/55ab3051827aeb698f95) to hang. When I pull the USB cable, I get a kernel panic somewhere in the DMA driver waiting to clear the FIFO. I’ve tried this on 3.8, 3.12 and 3.13 all with similar results (3.13 panic = https://gist.github.com/anonymous/12ef2a1223f7a953f293)
I’m using the stock am335x-bone.dts for each of the kernels.
I’ve also removed the USB support from u-boot (2014.01) to make sure no contamination got through.
I’ve also tried to disabling the USB DMA support in the kernel .config.
I’ve found that I get the exact same symptoms if I use a different USB UART ftdio_sio, so I think the problem is somewhere under the hood within the musb core/platform bindings.
I figured I’d see if anyone else has run into any problems like this, and was wondering if someone could answer a couple of questions I have:
Cheers for any help
Chris
Hey,
I’ve done a bit more digging at the problem seems to be that for some reason the TXPKTRDY bit in the HOST_CSR register never get’s cleared by the MUSB controller.
This is causing cppi41_dma_callback() to schedule work due to musb_is_tx_fifo_empty() stating there is still data in the outgoing FIFO.
Consequently the callback schedules cppi_trans_done_work() which also uses musb_is_tx_fifo_empty() which then reschedules itself if there is still data.
Thus the cppi41_trans_done() → musb_interrupt() → musb_host_tx() are never called so the USB controller never gets released.
You can see this through the dmesg.
Working:
[ 11.042601] cp210x ttyUSB0: usb_serial_generic_write_start - length = 132, data = 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 20 54 45 53 54 49 4e 47 20 54 45 53 54 49 4e 47 24
[ 11.042636] musb-hdrc musb-hdrc.0.auto: … next ep10 TX urb cc9cef00
[ 11.042658] musb-hdrc musb-hdrc.0.auto: qh ce3d6900 urb cc9cef00 dev2 ep1out-bulk, hw_ep 10, ce394b00/176
[ 11.042679] musb-hdrc musb-hdrc.0.auto: → hw10 urb cc9cef00 spd2 dev2 ep1out h_addr00 h_port00 bytes 176
[ 11.042701] musb-hdrc musb-hdrc.0.auto: configure ep10/a4 packet_sz=256, mode=0, dma_addr=0x8e394b00, len=176 is_tx=1
[ 11.042718] musb-hdrc musb-hdrc.0.auto: Start TX10 dma
[ 11.042808] musb-hdrc musb-hdrc.0.auto: DMA transfer done on hw_ep=10 bytes=176/176
[ 11.043165] musb-hdrc musb-hdrc.0.auto: OUT/TX10 end, csr 3500, dma
[ 11.043210] musb-hdrc musb-hdrc.0.auto: complete cc9cef00 usb_serial_generic_write_bulk_callback+0x0/0xd4 [usbserial] (0), dev2 ep1out, 176/176
Failing:
[ 11.043239] cp210x ttyUSB0: usb_serial_generic_write_start - length = 256, data = 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 2a 20 54 45 53 54 49 4e 47 20 54 45 53 54 49 4e 47 24
[ 11.043279] musb-hdrc musb-hdrc.0.auto: … next ep10 TX urb cc9ced00
[ 11.043301] musb-hdrc musb-hdrc.0.auto: qh ce3d6900 urb cc9ced00 dev2 ep1out-bulk, hw_ep 10, ce394a00/132
[ 11.043322] musb-hdrc musb-hdrc.0.auto: → hw10 urb cc9ced00 spd2 dev2 ep1out h_addr00 h_port00 bytes 132
[ 11.043344] musb-hdrc musb-hdrc.0.auto: configure ep10/a4 packet_sz=256, mode=0, dma_addr=0x8e394a00, len=132 is_tx=1
[ 11.043361] musb-hdrc musb-hdrc.0.auto: Start TX10 dma
[ 11.043389] musb-hdrc musb-hdrc.0.auto: DMA transfer done on hw_ep=10 bytes=132/132
FYI I’ve been using http://www.ti.com/lit/ug/sprufy9/sprufy9.pdf for the register descriptions as they’re all missing from the am335x docs (as suggested here: http://e2e.ti.com/support/arm/sitara_arm/f/791/t/211653.aspx)
Is this a known problem?
Chris