Symptom is: keep some USB devices busy, for about 1 minute the USB core is dead and all USB devices cease to work, even after re-plugging. Only way to restore is reboot.
Hi @numbqq I am using a 38W PD power supply, should be plenty for the load (CPU under 30% and about 500mA of USB current).
To reproduce, connect a hub (any kind of USB hub is fine) and plug 3 USB 2.0 devices to the hub (for me it’s 3 ESP32 Serial JTAG, I believe you can use any serial to usb converter) and read from them simultaneously. After a while the USB disconnects with the message shown above, and the USB controller is dead.
I suspect a quirk issue because of:
which is very similar.
I will need some time for testing here as I am very busy for a deadline, but I can test maybe tomorrow morning.
which indicates some interference between USB and Wi-Fi. However that does not explain why the XHCI controller just dies and the port disabled until reboot.
Please try to use our official image to check this issue, and also suggest you to use our official PD adaptor. As we can’t reproduce this issue on our side, so we need to keep the same hardware and software situation.
I think I found the reason of this issue. The (immediate) cause of this problem is a bad USB cable causing USB hub to disable and re-enumerate the USB devices: [ 1669.467200] usb 1-1.2-port3: disabled by hub (EMI?), re-enabling...
Note the USB Hub is working perfectly fine and the cable to the VIM4 has no problem. So there is still something wrong about the VIM4’s xHCI.
I will try to find a way to reproduce without a bad USB cable in the following days.
So another easy way to reproduce is frequently wiggle USB devices under a hub that make them have high error count and get disabled by hub. Anyways, the conclusion for now is that the USB on VIM4 is very experimental and will probably never get mainline support, due to the fact that the USB IP is probably from Corigine not the usual (and battle-tested) dwc3 people used to.
Unless Amlogic decides to do upstreaming effort we will be stuck at the vendor kernel.
Technically you are correct.
However in “real life testing” that is an issue that occurs and needs to be addressed. Its much better to have issues in the lab.
As @foxsquirrel said, you are technically correct. But it makes me nervous about using the VIM4 in production, as the xHCI would not come up again. I tested a few other platforms including one RPi4 and one Intel laptop. When exposed to same conditions they would just disconnect the misbehaving USB device and all other USB devices still work. On the VIM4 the xHCI dies and all USB ports will cease to work until reset.
This is very nice to hear! I really hope upstreaming would help improving the VIM4.
apparently Amlogic is licensing VS’s NPU core, but is not distributing the SDK as open source but a closed source blob. However the official VS SDK looks much much better so why can’t we just get support using the official SDK?