No device descriptors reported to host on RK3588 boards

[wchill]

Seeing something similar to #28 on two RK3588(S) boards - Orange Pi 5 and NanoPC T6. It might just be caused by the Rockchip kernel being garbage, but would like some help debugging this as configfs seems to work properly.

This is some minimal code I'm using to test functionfs (also works on a Raspberry Pi 4): https://gist.github.com/wchill/b905e8b776ccce1d8cf77a8ce2baa307

Running sudo /usr/bin/usbdevice start in the included Linux images for these two boards works properly. That script uses configfs to expose ADB to the host machine.

dmesg output:

# this is with functionfs
[  817.544711] read descriptors
[  817.544997] read strings
[  817.752523] dwc3 fc000000.usb: device reset
[  823.339517] dwc3 fc000000.usb: device reset
[  828.992008] dwc3 fc000000.usb: device reset
[  834.643483] dwc3 fc000000.usb: device reset
[  866.455147] ffs_data_put(): freeing

# this is with configfs
[  871.610680] read descriptors
[  871.610752] read strings
[  871.891945] dwc3 fc000000.usb: device reset
[  871.990169] android_work: sent uevent USB_STATE=CONNECTED

[vpelletier]

At a glance I cannot see any obvious cause for this issue.

A first debugging idea would be to strace the python process on both platforms, and check what happens once USB stuff starts happening. Of special interest are operations related to the eventfd and AIO.

A second debugging idea would be to look into the device's kernel logs, possibly increasing verbosity. dyndbg, if available, could help get some more details from the kernel.

Another debugging direction would be to use usbmon to capture usb traffic to see what transfers the host is seeing. I have not used it in a while, so I forgot if the gadget side gets its traffic reported to usbmon as well - if it does it would be most useful. The "raw text" (/sys/kernel/debug/usb/usbmon/*u files) output should be enough, the amount of data should be low and it is more the presence/absence of some packets which could be interesting here. You will want to minimise the USB traffic on the monitored bus (unplugging non-essential devices) during the capture to make the output easier to filter, and you will likely want to do a first pass of trimming before posting, as it could contain traffic to and from unexpected devices - traffic which should be mostly harmless, but could be sensitive (pin code sent to a USB smartcard reader, password typed on a USB keyboard...).

If neither show anything interesting, the next direction will likely be to look deeper into the kernel. Testing both the RK and Pi on the same kernel version could help reduce the amount of differences. It looks like the Pi4 has a dwc2 (brcm,bcm2835-usb) so this would be the next difference.

[wchill]

Unfortunately, it's not possible to run the two boards with the same kernel version, as the RK3588 doesn't have mainline support at the moment (I'm forced to use Rockchip's vendor supplied kernel).

The USB C port that allows dual role on the RK3588 is internally wired up to the USB 3 controller, so it's using the dwc3 driver.

Will investigate a bit more later, as I'm currently blocked anyway from deploying on the RK3588 due to a different unrelated driver issue (waiting on the Armbian folks to put together the correct kernel patches).

[vpelletier]

Quick heads-up: #28 is progressing and 36bd59f15bd90bf2fddbdec369d2aa6e376ed082 could be the fix needed for this issue.

[vpelletier]

I believe this issue can be closed now that #28 is resolved. Feel free to reopen if this issue still happens.