Replacing the network profile with g_mass_storage, we’re seeing connection direct to laptop working reliably. When connected to DUT it will rarely will enumerate. I’m thinking the PHY tuning needs adjustment, likely drive strength.
Is there a PHY tuning register for the USB-C port in peripheral mode?
The snps,dwc3 ip is pretty configurable: snps,dwc3.yaml « usb « bindings « devicetree « Documentation - kernel/git/torvalds/linux.git - Linux kernel source tree and ti,am62-usb ti,am62-usb.yaml « usb « bindings « devicetree « Documentation - kernel/git/torvalds/linux.git - Linux kernel source tree
But which of the usb-gadget drivers are you trying to use to share to the DUT device?
For reference, we dive into configfs in the default image to share the virtual USB devices: bb-usb-gadgets/suite/bookworm/debian/bb-start-acm-ncm-rndis-old-gadget · main · BeagleBoard.org / repos-arm64 · GitLab
Regards,
using kernel module g_mass_storage. So emulating mass storage to the DUT from test harness (LAVA).
g_mass_storage really doesn’t have any options. Are you seeing any USB probing errors on either side? How are you loading the module? Forcing it from the cmdline option?
Side note, looking at our Beagle boot scripts, we have not used discrete gadget drivers since pre v4.4.x era (v3.14.x/v3.8.x timeline)… Starting with v4.4.x we moved to configfs (libcomposite) usb gadget configuration. So we aren’t sadly the best for validating g_mass_storage.
Regards,
Yes I’m aware libcomposite is the preferred approach, we will move to that soon. For now I think the focus is the electrical network, which can be seen as a constant (same interconnects, same cabling, same legnth), so figuring PHY tuning/drive strength was the knob to twiddle.
With a microSD card, formatted to FAT32, plug it to the Beagleplay, then expose it in the g_mass_storage command. This is after stopping code server and network peripheral services.
sudo modprobe g_mass_storage file=/dev/disk/by-uuid/CC9A-DBE1 stall=0 speed=1
Laptop will enumerate BeaglePlay as a mass storage device, one can read/write files on the microSD card. Same connection with DUT will not reliably enumerate, if at all. Which is likely due to PHY tuning.
Do you have to access it thru Linux? BeaglePlay’s u-boot should have DFU support from mainline now too, or just use u-boot’s ums driver to share the microSD over usb… DFU/ums in u-boot seems to get more testing today…
Regards,
We are using the BeaglePlay as a Linaro LAVA type B worker for distributed board farm testing.
https://validation.linaro.org/
The mass storage use case is required for updating the DUT firmware. The DUT should be using UEFI capsule support for updates, but I digress. So accessing from Linux is a requirement.
The LAVA dispatcher on the BeaglePlay runs in a docker container, which executes a test that performs the DUT device update. A Mikrobus Relay Click is used for power control, and secondary USB mux selection.
It’s a much more cost effective approach, than something like this:
https://shop.linux-automation.com/index.php?route=product/product&product_id=61
Hi @RobertCNelson
Thanks for your suggestion. I have tried BeaglePlay’s ums with a DUT. It can flash one binary file to the DUT at a time. But after each file is flashed, the BeaglePlay exits ums mode, so I have to issue the ums command for each file. i.e. ums 0 mmc 1 . Does it sound normal to you?
Also, for our use case, we want to use BeaglePlay to flash a DUT automatically with a microSD card. Is there a way for BeaglePlay to enter and exit ums mode automatically?