On the Compute Module 4, the USB_OTG_ID pin was directly wired to a USB mux that would decide between either two USB-A ports on the CM4 IO board which could be enabled by adding “dtoverlay=dwc2,dr_mode=host” or a separate mini-USB port that could allow the CM4 to act as a gadget/device instead of a host by changing that to “dr_mode=peripheral”. There was a third option to set “dr_mode=otg” and by adding or removing the USB_OTG jumper on the CM4 IO board you could switch between the two functionalities as needed rather than having to reboot to switch functionality.Ok.. Currently when I want to flash to the eMMC, I set a jumper on the "Fit jumper to disable eMMC Boot" and then run usbboot, which loads the image as you said and then its available as a Mass storage device.Oh - I've not noticed that jumper before! I suspect it emulates the special OTG cables with a built-in resistor(?), for situations where you want the USB interface to auto-detect which role to be in. Whether it's configured manually or automatically, you still need to enable that USB controller on that connector, which is what the "dwc2" overlay does. However, in order to activate mass storage gadget mode properly you also need to persuade the kernel not to access the medium (SD Card, EMMC), which is why you need something like the mass-storage-gadget image provided as part of the usbboot suite.
I wanted to know when I attach a jumper to the pins marked with "USB_OTG", what does it do. I was assuming it was setting the device as Mass storage making the eMMC available, which I guess I am wrong about it.
Since the USB3 ports on the CM5 IO board are completely separate and the USB2 ports are no longer present, there is no USB mux or need to decide between host or gadget/device mode. Using the USB-C port in peripheral mode is very useful, but it seems as though a recent firmware update may have changed functionality a bit. I used to be able to use a USB-C to USB-C cord with my Pi 5, but now to get gadget mode functionality I need to have a USB-C to A adapter back to C adapter when using two USB-C ports. Strangely, I don’t have this issue at all when using the same CM5 on CM4 boards.
The USB_OTG_ID feature on the chip itself is key to maintaining functionality when using CM5 SOC’s on CM4 boards, outside of that I don’t think there is much useful purpose in most applications.
Statistics: Posted by ChipChop — Thu Jan 30, 2025 4:08 am