@RadxaYuntian Guys i really appreciate your sense of humor, but why do you think that there’s a problem with the USB controller on the PC, if the speed in OTG mode is Superspeed and in the exact same port the speed is Highspeed in peripheral mode? So how about putting aside the theory that there’s any problem with the USB controller on the PC side, and instead trying to focus on the SBC side and doing the same test like i do? Moreover i’m a developer so your initial general hints you gave me as some random noskill user was amusing but now it’s getting annoying-boring. This is the 4th different board that i bought from you, and so far all were just pure waste of money. This OTG and Peripheral mode with the Mass Storage Gadget Driver is totally fucked up everywhere, so i think it would be high time fixing it. Luring potential customers with non working features is not ethical
CM5 USB and touchscreen issues
As you can see from my recording I could not reproduce your issue, and thus I have no clue how to fix it.
Just to show how gentleman i am, i give you a more simple test case which doesn’t involve any 3rd party stuff, other PC, whatsoever.
Connect the USB-C port to the USB3-A port with the USB3 OTG cable. So there aren’t any additional computers/devices involved in the party, just pure CM5.
I enabled radxa-ncm otg service in rsetup just like you did in your video.
This picture shows the situation when the peripheral overlay is disabled:
While the following picture shows the situation when the peripheral overlay is enabled:
The small arrows show that the port is in OTG mode in the first picture, and in the second picture it’s in peripheral mode.
The big arrows show that the speed is 5000M in the first case in OTG mode so it’s Superspeed, while it’s just 480M in the second case in peripheral mode
which is Highspeed only.
I can’t wait for your explanation about this phenomenon…
Hi @Rockpi_fan,
We have a new discovery, when using Type-C to Type-A cable, only one Type-C side is available for USB3, and can’t hot-swap to switch the flip side, can only re-power on to switch the flip side, otherwise it can only be recognized to USB2
OTG mode in first picture. How did you modify it?
It’s exactly the case that you said. I noticed this thing 1 year ago when i was experimenting the 5B model, but that time i didn’t create a topic about this problem because that SBC wasn’t suitable for our project. In my opinion the problem is not with the cable, because you can notice the same behaviour with a type-c -> type-c cable as well, give it a try if you haven’t done so. So it does matter which side of the cable is used to connect to the CM5’s type-c port, but at the same time it doesn’t matter which side is used of the cable to connect to the host side. Thus this led me to the conclusion that there is a hardware related problem with the USB in EVERY Radxa product…
Guys did you have a chance to experiment the problem a bit further?
Could you confirm if this a SOM or IO board related problem?
Probably the overlay need to configure FUSB302 as well. We would come back to this later.
@RadxaYuntian This is a key thing from our perspective because if this can’t be fixed in the foreseeable future, that means we can’t build our product on this SBC, so i would appreciate if your team could provide an answer/solution to this issue as soon as possible.
Is there a way to block users so one don’t have to read all this self centered nonsense?
Sure, i tell you a universal solution: don’t open/read those topics that you are not interested in. Is there a way to not feel sudden urge to comment everything, especially those topics that you have no idea about? I would really appreciate if you didn’t spam the topic with BS, so once we have a solution and others encounter the same problem they could quickly find what they need to do instead of reading 1000 nonsense replies from such geniuses like you.
Dear @RadxaYuntian! I am also affected by this problem, I would like to know if there is any progress in this matter?
He is currently working on another customer’s issue.
In this case, could I possibly get some guidance on where to look in the source code regarding this issue?
Until you are able to address it in more detail, I would like to investigate this strange matter on my own.
Probably the port configuration in device tree, FUSB302 driver, tcpm state machine, and Rockchip USB controller as a starting point. We don’t know the root cause at this point.
We spent a lot of time checking this and eventually escalated to Rockchip support. They have confirmed that when dr_mode is configured as peripheral, some driver dependency chain is broken, causing FUSB302 not being probed properly.
No proposed fix or ETA is available at this time.
@RadxaYuntian That’s a bad news for us, but i’d like to say thank you for putting the time and effort to investigate the issue and notify the vendor about it. Hopefully they will fix it rather sooner than later. 