Pcduino OTG - PROBLEM SOLVED

[Solarbytes]

Hi Johan, I am battling to get my PCduino alive. Your Bullseye image from a few years back worked perfectly since that time, but bookworm or trixie images don't make OTG work. Can you please advise how to get your images from bulleseye? What could be the problem? here is what I see: the dwc2 driver gets loaded but the usb mass storage doesn't work. sometimes I get the drive in windows explorer, but it always crashes file explore and window explorer. I can navigate the folders, but I cannot create a file. Any help would be much appreciated.

[Solarbytes]

pcduino 3 nano to be more precise

[Solarbytes]

also, rsync is problematic on your images: it looks for an outdated libcrypto.ko file, so each time I have to download and compile the latest rsync version to make it work. If you can do anything about it, that would be much appreciated. curl, sudo and fdisk would also be [nice essential tool to add to your images if you can...

[Solarbytes]

diving a little deeper, I found two things in the device tree and bootup messages:

1. the DTS file has the following entry defining the OTG port, but nothing in dmesg related to usb@13000 or 1c13400, while there are entries for 1c14000 and 1c14400 which I assume would be the USB A ports - is the absence of references to 1c13000 a problem?
   usb@1c13000 {
   compatible = "allwinner,sun4i-a10-musb";
   reg = <0x1c13000 0x400>;
   clocks = <0x02 0x1a>;
   interrupts = <0x00 0x26 0x04>;
   interrupt-names = "mc";
   phys = <0x1a 0x00>;
   phy-names = "usb";
   extcon = <0x1a 0x00>;
   allwinner,sram = <0x1b 0x01>;
   dr_mode = "otg";
   status = "okay";
   phandle = <0x50>;

2. a little after detecting 1c14000, there is a line that suggests that the vbus is not properly defined:

[ 4.153418] usb_phy_generic usb_phy_generic.0.auto: dummy supplies not allowed for exclusive requests (id=vbus)

google search suggests that the kernel is trying to gain exclusive control the voltage of the port but cannot do it since it is using a dummy regulator

a bit later, (and earlier too), there are some error messages and an attempt to power cycle the port (which based on the previous point, it seems it cannot do with a dummy regulator):

[ 4.212344] usb usb2-port1: attempt power cycle
[ 4.408248] usb 2-1: new high-speed USB device number 4 using ehci-platform
[ 4.828214] usb 2-1: device not accepting address 4, error -71
[ 4.948144] usb 2-1: new high-speed USB device number 5 using ehci-platform
[ 5.364125] usb 2-1: device not accepting address 5, error -71
[ 5.364277] usb usb2-port1: unable to enumerate USB device
[ 5.740111] usb 4-1: new full-speed USB device number 2 using ohci-platform
[ 5.928104] usb 4-1: device descriptor read/64, error -62
[ 6.252690] usb 4-1: device descriptor read/64, error -62
[ 6.536265] usb 4-1: new full-speed USB device number 3 using ohci-platform
[ 6.724159] usb 4-1: device descriptor read/64, error -62
[ 7.016233] usb 4-1: device descriptor read/64, error -62
[ 7.120299] usb usb4-port1: attempt power cycle

After some more time, this following entry suggests that the gadget is activated, however, it doesn't work: Windows will produce a chime to signal that a device has been connected, then it gets disconnected, then reconnected again, but the mass-storage content is still not visible immediately, After several minutes (maybe 15 mins), the folders will appear in File Explorer, but if I try to copy a file, it will crash both File explorer and Windows Explorer.

[ 22.783776] systemd[1]: Reached target usb-gadget.target - Hardware activated USB gadget.

Any thoughts on how to resolve this would be appreciated.

Cheers,
Gaetano.

[Solarbytes]

this may also be worth looking at. The following lines in the DTS file suggest that there are 3 voltage regulators, but there is only one regulator on the PC duino for both USB host ports. Should those 3 lines all point to the only vbus regulator that is enabled, i.e. usb1-vbus?:

reg_usb0_vbus = "/usb0-vbus";
reg_usb1_vbus = "/usb1-vbus";
reg_usb2_vbus = "/usb2-vbus";

/* A single regulator (U24) powers both USB host ports. */
&reg_usb1_vbus {
	pinctrl-0 = <&usb1_vbus_pin_pcduino3_nano>;
	gpio = <&pio 3 2 GPIO_ACTIVE_HIGH>; /* PD2 */
	status = "okay";

source:
https://gitlabhost.argos-navy.ru/rockchip/rongpin/rk3588_android12/-/blob/master/u-boot/arch/arm/dts/sun7i-a20-pcduino3-nano.dts?ref_type=heads

[Solarbytes]

The problem is the kernel: I downgraded from 6.1 to 5.10.218 and OTG works fine with the usual entries in /boot/config.txt, /boot/cmdline.txt and /etc/modules.

I used your bookworm image for pcduino3-nano with password gu7eiz as the basis for the install, and from there downloaded the kernel and headers taken from https://archive.debian.org/debian/pool/main/l/linux/. I installed them with apt locally, and updated+recompiled boot.cmd accordingly.

If possible, add a note to the pcduino3 nano downloads stating that OTG may only work with kernels up to 5.10. I am sure that an expert will be able to make it work with more recent kernels, but that is beyond my skills. It may save someone else the headaches.

Thank you for your patience and advice Johan.

[Solarbytes]

Maybe this is the key to supporting OTG in kernel 6:

In the deviec tree:

&usbotg_hs {
compatible = "st,stm32mp15-hsotg", "snps,dwc2";
dr_mode = "otg";
usb-role-switch; <------ this is the major change between kernel 5 and 6 wrt OTG
/* Other DWC2 specific properties and PHY configuration */
...
};

Then on the user side, setting up the gadget requires the following:

To switch to device mode

echo "device" > /sys/class/usb_role/*.dwc2-role-switch/role

To switch to host mode

echo "host" > /sys/class/usb_role/*.dwc2-role-switch/role