rsta2
USB Mass Storage Issues with detecting USBMS Gadget in BIOS
Greetings, we are implementing a project that leverages the circle framework and I believe I have identified some issues with the dwgadget implementation within Circle.
I know this functionality works fine with the Linux based mass storage driver, so I have reason to believe this is specific to Circle.
I altered the HandleSCSI function to include additional debug logging to help identify what commands may be causing issues.
in the file lib/usb/gadget/usbmsdgadget.cpp
I uncommented the #define MLOGNOTE(From,...) logging command
and added the following line under the class definition
void CUSBMSDGadget::HandleSCSICommand()
MLOGNOTE("HandleSCSICommand","CBWCB[0]=0x%x, CBWCB[1]=0x%x, CBWCB[2]=0x%x, CBWCB[3]=0x%x", m_CBW.CBWCB[0],m_CBW.CBWCB[1],m_CBW.CBWCB[2],m_CBW.CBWCB[3]);
I also enabled the USB_GADGET_DEBUG logs.
To test this, I imaged an SDcard with the file win98qi_v0.9.6_ALL_usb.img and then copied over the required files and output of the sample kernel of test/usb-msd-gadget (specifically in my case, kernel7.img). I am testing on Raspberry Pi Zero 2 W.
Issue 1: Many computer systems will not detect the USB Mass Storage during BIOS detection.
(higher priority)
Here are the logs from 3 boot sessions after I enabled the USB_GADGET_DEBUG logs. I did have HandleSCSI additional logging enabled, but as the logs reveal the BIOS didn't get that far.
My cmdline.txt was logdev=ttyS1 loglevel=5 usbboost=true sounddev=sndi2s fast=true
I also tried with cmdline.txt as logdev=ttyS1 loglevel=5 sounddev=sndi2s and no difference was found in the logs.
logger: Circle 49.0.1 started on Raspberry Pi Zero 2 W 512MB
logger: Revision code is 902120, compiler has been GCC 14.2.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.68 sdhost: emmc1: sdhost-bcm2835 loaded
00:00:02.20 emmc: Capacity is 15193 MBytes
00:00:02.20 emmc: Found a valid version 3.0x SD card
00:00:02.90 kernel: Compile time: Jun 27 2025 11:43:11
00:00:07.24 dwgadget: IRQ (status 0x00001000)
00:00:07.24 dwgadget: USB reset
00:00:07.24 dwgadget: Set device address to 0
00:00:07.24 dwgadgetep: First in next EP sequence is 0
00:00:07.24 dwgadgetep: Dumping 0x10 bytes starting at 0x22FA8
00:00:07.24 dwgadgetep: 2FA8: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:09.92 dwgadget: IRQ (status 0x00002000)
00:00:09.92 dwgadget: Enumeration done
00:00:09.92 dwgadget: IRQ (status 0x00000800)
00:00:09.92 dwgadget: USB suspend
00:00:17.07 dwgadget: IRQ (status 0x00001000)
00:00:17.07 dwgadget: USB reset
00:00:17.07 dwgadget: Set device address to 0
00:00:17.07 dwgadgetep: First in next EP sequence is 0
00:00:17.07 dwgadgetep: Dumping 0x10 bytes starting at 0x22FA8
00:00:17.07 dwgadgetep: 2FA8: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:19.75 dwgadget: IRQ (status 0x00002000)
00:00:19.75 dwgadget: Enumeration done
00:00:19.75 dwgadget: IRQ (status 0x00000800)
00:00:19.75 dwgadget: USB suspend
00:00:25.33 dwgadget: IRQ (status 0x00001000)
00:00:25.33 dwgadget: USB reset
00:00:25.33 dwgadget: Set device address to 0
00:00:25.33 dwgadgetep: First in next EP sequence is 0
00:00:25.33 dwgadgetep: Dumping 0x10 bytes starting at 0x22FA8
00:00:25.33 dwgadgetep: 2FA8: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:28.01 dwgadget: IRQ (status 0x00002000)
00:00:28.01 dwgadget: Enumeration done
00:00:28.01 dwgadget: IRQ (status 0x00000800)
00:00:28.01 dwgadget: USB suspend
The log looks mostly as expected, but the device does not receive any request from the host and goes to suspend instead. I will try to reproduce this here with the BIOS of a PC.
I successfully tested the test/usb-msd-gadget with the BIOS of my PC Netbook. The drive is detected, but I had to remove the blinking of the Act LED, because the startup operation takes too long otherwise.
Thanks for testing, are you able to boot into an OS as well? We are seeing major issues with Seabios enabled devices such as the ITX Llama, that is what the logs are from.
We have got this to work on other systems but I think the way how the dwgadget or dwgadgetendpoint is handling bus resets and handoff between bios session and boot. This doesn't happen with the Linux MSD gadget which I why I raised the issue.
Unfortunately I do not have an OS, which I can boot on a PC from a SD card. I started the loading process and from the debug output I can see, that is loads something, but of course I will not really run.
I think the time is critical, which the RPi needs to start into the application, which provides the MSD gadget function. When the RPi is powered via the USB, which is also used for data transfers, the RPi has only a short time to start until the boot selection window appears. Sometimes the time is too short, and there is no entry for the USB drive.
On my PC (Itx llama), I'm able to use CTRL+ALT+DEL which does not restart the circle device. I know this isn't entirely a timing issue on the Llama due to that.
In my project we are using dwgadget/dwgadgetendpoint and have verified the ctrl+alt+del works in some scenarios but also doesn't get past the bios detection properly (sometimes in our project it detects in the bios but won't boot correctly due to resets).
If you have the opportunity to try win98qi usb it should boot, and used linux to boot with.
I modified the test/usb-msd-gadget so that one can copy an disk image file to the SD card and it delivers the file contents like it would be written directly to the SD card, starting at sector 0. With this and with a disk image of FreeDOS I was able to test the boot process further and I also ran into an issue.
After selecting the boot option from the boot screen, it loads some sectors successfully and then instead of continuing the host sends an USB reset. Currently unfortunately I have no idea, why this happens.
See the log file attached. My comments are preceded with ###.
Thank you for testing this, this is similar to what we are seeing in my project, however I don't get the stack dump after trying to boot from our disc.
Is this something you are able to continue investigating?
I tested now with a different PC (Thinkpad X240) and it works there without modifications to the Circle gadget source. I think you have to disable Secure Boot and enable the Compatibility System Module (CSM) so that it works. My previous PC did not support this and so it did not work. I assume there is no problem in Circle, it's just a feature (Secure Boot) of the PC.
My apologies I was wrong. There was a problem in the Circle gadget code, so that it was not able to handle Enumeration Done interrupts properly, when they occurred in states other than StateResetDone. The problem has been fixed on the develop branch. With this booting works on my Netbook too, which didn't work before.
I've applied this specific fix as a patch to my local environment, but noticed it is harder to get my BIOS to enumerate the device now. I've enabled USB_GADGET_DEBUG and the only indicators that anything is happening is when I restart my computer, that the mass storage device is logging a connection reset.
Here are my latest logs:
logger: Circle 49.0.1 started on Raspberry Pi Zero 2 W 512MB
logger: Revision code is 902120, compiler has been GCC 14.2.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.68 sdhost: emmc1: sdhost-bcm2835 loaded
00:00:02.20 emmc: Capacity is 15193 MBytes
00:00:02.20 emmc: Found a valid version 3.0x SD card
00:00:02.90 kernel: Compile time: Jul 3 2025 13:28:05
00:00:03.52 dwgadgetep: First in next EP sequence is 0
00:00:03.52 dwgadgetep: Dumping 0x10 bytes starting at 0x22F10
00:00:03.52 dwgadgetep: 2F10: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:15.57 dwgadgetep: First in next EP sequence is 0
00:00:15.57 dwgadgetep: Dumping 0x10 bytes starting at 0x22F10
00:00:15.57 dwgadgetep: 2F10: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:26.57 dwgadgetep: First in next EP sequence is 0
00:00:26.57 dwgadgetep: Dumping 0x10 bytes starting at 0x22F10
00:00:26.57 dwgadgetep: 2F10: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
First start was at around 00:00:03.52
Next restart was at around 00:00:15.57 and the third start was at 00:00:26.57
Are you sure, that you enabled USB_GADGET_DEBUG globally and rebuild everything? I'm missing at least the "dwgadget: USB reset" line, which must come before "dwgadgetep: First in next EP sequence is 0". Without the messages from "dwgadget" the log is not telling much.
Thank you so much for the latest release. We've updated it in our project but still experiencing similar issues.
My build process was to edit the include/circle/sysconfig.h file, updated the USB_GADGET_VENDOR_ID, USB_GADGET_DEVICE_ID_BASE and set USB_GADGET_DEBUG in there as well, then ran make for RASSPI=3 using the GCC as per instructions.
I have built the latest usb-msd-gadget and tried booting 3 times from my retro PC using CTRL+ALT+DEL. My retro PC maintains power to the USB port during reboot.
Outside of these logs, I am able to see a lot of debug logs when I load Windows 98SE, I haven't included them since that part seems to be working.
logger: Circle 50 started on Raspberry Pi Zero 2 W 512MB logger: Revision code is 902120, compiler has been GCC 14.3.1 00:00:00.66 timer: SpeedFactor is 1.51 00:00:00.68 sdhost: emmc1: sdhost-bcm2835 loaded 00:00:02.20 emmc: Capacity is 60906 MBytes 00:00:02.20 emmc: Found a valid version 3.0x SD card 00:00:02.90 kernel: Compile time: Aug 22 2025 11:20:30 00:00:11.86 dwgadget: IRQ (status 0x00001000) 00:00:11.86 dwgadget: USB reset 00:00:11.86 dwgadget: Set device address to 0 00:00:11.86 dwgadgetep: First in next EP sequence is 0 00:00:11.86 dwgadgetep: Dumping 0x10 bytes starting at 0x23118 00:00:11.86 dwgadgetep: 3118: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF 00:00:18.32 dwgadget: IRQ (status 0x00002000) 00:00:18.32 dwgadget: Enumeration done 00:00:18.32 dwgadget: IRQ (status 0x00000800) 00:00:18.32 dwgadget: USB suspend 00:00:19.96 dwgadget: IRQ (status 0x00000800) 00:00:19.96 dwgadget: USB suspend 00:00:30.19 dwgadget: IRQ (status 0x00001000) 00:00:30.19 dwgadget: USB reset 00:00:30.19 dwgadget: Set device address to 0 00:00:30.19 dwgadgetep: First in next EP sequence is 0 00:00:30.19 dwgadgetep: Dumping 0x10 bytes starting at 0x23118 00:00:30.19 dwgadgetep: 3118: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF 00:00:36.64 dwgadget: IRQ (status 0x00002000) 00:00:36.64 dwgadget: Enumeration done 00:00:36.65 dwgadget: IRQ (status 0x00000800) 00:00:36.65 dwgadget: USB suspend 00:00:38.29 dwgadget: IRQ (status 0x00000800) 00:00:38.29 dwgadget: USB suspend
diff --git a/include/circle/sysconfig.h b/include/circle/sysconfig.h
index 566e6eb7..1de6ba35 100644
--- a/include/circle/sysconfig.h
+++ b/include/circle/sysconfig.h
@@ -329,7 +329,7 @@
// define a new one.
#ifndef USB_GADGET_VENDOR_ID
-#define USB_GADGET_VENDOR_ID 0x0000
+#define USB_GADGET_VENDOR_ID 0x04da
#endif
// USB_GADGET_DEVICE_ID_BASE is the base value for the assignment of
@@ -340,7 +340,7 @@
// same USB Vendor ID!
#ifndef USB_GADGET_DEVICE_ID_BASE
-#define USB_GADGET_DEVICE_ID_BASE 0x8001
+#define USB_GADGET_DEVICE_ID_BASE 0xa4a5
#endif
#ifndef USB_GADGET_DEVICE_ID_MIDI
@@ -355,6 +355,10 @@
#define USB_GADGET_DEVICE_ID_MSD (USB_GADGET_DEVICE_ID_BASE+2)
#endif
+#ifndef USB_GADGET_DEBUG
+#define USB_GADGET_DEBUG
+#endif
+
Thanks for the full log. With it I can analyze this now again. It will take some time.
There is an update on the branch usb-gadget-fix. Can you please test your code with it. Thanks.
Thank you for the update. I'm using your test/usb-msd-gadget code for these tests.
I'm not sure if it's getting any further, since the mass storage device still isn't able to be detected by the bios. Here are the latest logs with debugging turned on.
logger: Circle 50 started on Raspberry Pi Zero 2 W 512MB
logger: Revision code is 902120, compiler has been GCC 14.3.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.68 sdhost: emmc1: sdhost-bcm2835 loaded
00:00:02.20 emmc: Capacity is 60906 MBytes
00:00:02.20 emmc: Found a valid version 3.0x SD card
00:00:02.90 kernel: Compile time: Aug 26 2025 08:08:45
00:00:09.04 dwgadget: IRQ (status 0x00001000, state 1)
00:00:09.04 dwgadget: USB reset
00:00:09.04 dwgadget: Set device address to 0
00:00:09.04 dwgadgetep: First in next EP sequence is 0
00:00:09.04 dwgadgetep: Dumping 0x10 bytes starting at 0x232F8
00:00:09.04 dwgadgetep: 32F8: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:15.50 dwgadget: IRQ (status 0x00002000, state 2)
00:00:15.50 dwgadget: Enumeration done
00:00:15.50 dwgadget: IRQ (status 0x00000800, state 3)
00:00:15.50 dwgadget: USB suspend
00:00:24.21 dwgadget: IRQ (status 0x00001000, state 1)
00:00:24.21 dwgadget: USB reset
00:00:24.21 dwgadget: Set device address to 0
00:00:24.21 dwgadgetep: First in next EP sequence is 0
00:00:24.21 dwgadgetep: Dumping 0x10 bytes starting at 0x232F8
00:00:24.21 dwgadgetep: 32F8: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:30.67 dwgadget: IRQ (status 0x00002000, state 2)
00:00:30.67 dwgadget: Enumeration done
00:00:30.67 dwgadget: IRQ (status 0x00000800, state 3)
00:00:30.67 dwgadget: USB suspend
00:00:32.31 dwgadget: IRQ (status 0x00000800, state 1)
00:00:32.31 dwgadget: USB suspend
The logs were first turning on the device with the system, (it takes about 5 seconds to reach the BIOS after the VGA card initialization).
I have another set of logs where I disabled the LED Blinking to reduce boot time for the usb-msd-gadget.
logger: Circle 50 started on Raspberry Pi Zero 2 W 512MB
logger: Revision code is 902120, compiler has been GCC 14.3.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.68 sdhost: emmc1: sdhost-bcm2835 loaded
00:00:02.20 emmc: Capacity is 60906 MBytes
00:00:02.20 emmc: Found a valid version 3.0x SD card
00:00:02.90 kernel: Compile time: Aug 26 2025 08:45:09
00:00:04.64 dwgadget: IRQ (status 0x00002000, state 1)
00:00:04.64 dwgadget: Enumeration done
00:00:04.64 dwgadget: USB reset
00:00:04.64 dwgadget: Set device address to 0
00:00:04.64 dwgadgetep: First in next EP sequence is 0
00:00:04.64 dwgadgetep: Dumping 0x10 bytes starting at 0x232E0
00:00:04.64 dwgadgetep: 32E0: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:04.67 dwgadget: IRQ (status 0x00000800, state 3)
00:00:04.67 dwgadget: USB suspend
00:00:06.28 dwgadget: IRQ (status 0x00000800, state 1)
00:00:06.28 dwgadget: USB suspend
00:00:17.31 dwgadget: IRQ (status 0x00001000, state 1)
00:00:17.31 dwgadget: USB reset
00:00:17.31 dwgadget: Set device address to 0
00:00:17.31 dwgadgetep: First in next EP sequence is 0
00:00:17.31 dwgadgetep: Dumping 0x10 bytes starting at 0x232E0
00:00:17.31 dwgadgetep: 32E0: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:23.77 dwgadget: IRQ (status 0x00002000, state 2)
00:00:23.77 dwgadget: Enumeration done
00:00:23.77 dwgadget: IRQ (status 0x00080800, state 3)
00:00:23.77 dwgadget: USB suspend
00:00:23.77 dwgadget: Out EP interrupt
00:00:23.77 dwgadgetep: EP0: Interrupt status is 0x00000008
00:00:23.77 dwgadgetep: 8 byte(s) transferred
00:00:23.77 dwgadgetep: Dumping 0x8 bytes starting at 0x59DB40
00:00:23.77 dwgadgetep: DB40: 40 DB 59 C0 40 DB 59 C0-55 55 55 55 55 55 55 55
00:00:23.77 dwusbgadgetendpoint0.cpp(181): stack[7] is 0xB020
00:00:23.77 dwusbgadgetendpoint0.cpp(181): stack[13] is 0xA78C
00:00:23.77 dwusbgadgetendpoint0.cpp(181): stack[31] is 0x94D0
00:00:23.77 dwusbgadgetendpoint0.cpp(181): stack[34] is 0x10000
00:00:23.77 dwusbgadgetendpoint0.cpp(181): stack[41] is 0x9AA8
00:00:23.77 dwusbgadgetendpoint0.cpp(181): stack[53] is 0x13F1C
00:00:23.77 dwusbgadgetendpoint0.cpp(181): assertion failed: pSetupData->wLength <= sizeof m_OutBuffer
This one has only two boots, the initial boot (where dwgadget gets initialized around 4 seconds) and a single reboot, where we end up in a crashed state.
These are all of the logs I have been able to gather.
Thanks again, I hope we are able to resolve the issue with booting.
There is a new commit on the usb-gadget-fix branch, which should fix the failed assertion above. It's probably generally a good idea to disable the Act LED blink at startup to speed it up.
Thanks again for the updates, however I tested it and didn't see any changes.
logger: Circle 50 started on Raspberry Pi Zero 2 W 512MB
logger: Revision code is 902120, compiler has been GCC 14.3.1
00:00:00.66 timer: SpeedFactor is 1.51
00:00:00.68 sdhost: emmc1: sdhost-bcm2835 loaded
00:00:02.20 emmc: Capacity is 60906 MBytes
00:00:02.20 emmc: Found a valid version 3.0x SD card
00:00:02.90 kernel: Compile time: Aug 27 2025 07:23:26
00:00:04.63 dwgadget: IRQ (status 0x00002000, state 1)
00:00:04.63 dwgadget: Enumeration done
00:00:04.63 dwgadget: USB reset
00:00:04.63 dwgadget: Set device address to 0
00:00:04.63 dwgadgetep: First in next EP sequence is 0
00:00:04.63 dwgadgetep: Dumping 0x10 bytes starting at 0x232E0
00:00:04.63 dwgadgetep: 32E0: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:04.67 dwgadget: IRQ (status 0x00000800, state 3)
00:00:04.67 dwgadget: USB suspend
00:00:06.28 dwgadget: IRQ (status 0x00000800, state 1)
00:00:06.28 dwgadget: USB suspend
00:00:23.03 dwgadget: IRQ (status 0x00001000, state 1)
00:00:23.03 dwgadget: USB reset
00:00:23.03 dwgadget: Set device address to 0
00:00:23.03 dwgadgetep: First in next EP sequence is 0
00:00:23.03 dwgadgetep: Dumping 0x10 bytes starting at 0x232E0
00:00:23.03 dwgadgetep: 32E0: 01 00 FF FF FF FF FF FF-FF FF FF FF FF FF FF FF
00:00:29.48 dwgadget: IRQ (status 0x00002000, state 2)
00:00:29.48 dwgadget: Enumeration done
00:00:29.49 dwgadget: IRQ (status 0x00080800, state 3)
00:00:29.49 dwgadget: Out EP interrupt
00:00:29.49 dwgadgetep: EP0: Interrupt status is 0x00000008
00:00:29.49 dwgadgetep: 8 byte(s) transferred
00:00:29.49 dwgadgetep: Dumping 0x8 bytes starting at 0x59DB40
00:00:29.49 dwgadgetep: DB40: 40 DB 59 C0 40 DB 59 C0-55 55 55 55 55 55 55 55
00:00:29.49 dwusbgadgetendpoint0.cpp(181): stack[7] is 0xB020
00:00:29.49 dwusbgadgetendpoint0.cpp(181): stack[13] is 0xA78C
00:00:29.49 dwusbgadgetendpoint0.cpp(181): stack[31] is 0x94D0
00:00:29.49 dwusbgadgetendpoint0.cpp(181): stack[34] is 0x10000
00:00:29.49 dwusbgadgetendpoint0.cpp(181): stack[41] is 0x9A98
00:00:29.49 dwusbgadgetendpoint0.cpp(181): stack[53] is 0x13F1C
00:00:29.49 dwusbgadgetendpoint0.cpp(181): assertion failed: pSetupData->wLength <= sizeof m_OutBuffer
Also, the BIOS still isn't detecting the device on the first boot. The crash happens after I CTRL + ALT + DEL reboot the computer.
I'm running out of ideas at the moment. I don't understand, why the USB host goes into "suspend" instead of sending something out at 00:00:04.67. Later it sends something at 00:00:29.49, but the setup data is wrong, which triggers the assertion. And this event (status 0x00080800) comes together with another "suspend" (bit 0x800 is set). In "suspend" mode data transfers are not possible. Perhaps I get an idea later, how to handle this all.
I need to refactor my code and try again. I'll also try with the base msdgadget when I get a chance, probably this weekend.
Please use the latest version on the usb-gadget-fix branch for testing the MSD gadget. The version on the master branch does not have the latest fixes.
I don't think this is working.
When I restarted my Llama BIOS I received a crash:
logger: Circle 50 started on Raspberry Pi Zero 2 W 512MB logger: Revision code is 902120, compiler has been GCC 14.3.1 00:00:00.66 timer: SpeedFactor is 1.51 00:00:00.68 sdhost: emmc1: sdhost-bcm2835 loaded 00:00:02.20 emmc: Capacity is 60906 MBytes 00:00:02.20 emmc: Found a valid version 3.0x SD card 00:00:02.90 kernel: Compile time: Oct 23 2025 19:11:47 00:00:03.11 dwgadget: 2 Endpoint(s) activated logger: Circle 50 started on Raspberry Pi Zero 2 W 512MB logger: Revision code is 902120, compiler has been GCC 14.3.1 00:00:00.66 timer: SpeedFactor is 1.51 00:00:00.68 sdhost: emmc1: sdhost-bcm2835 loaded 00:00:02.20 emmc: Capacity is 60906 MBytes 00:00:02.20 emmc: Found a valid version 3.0x SD card 00:00:02.90 kernel: Compile time: Oct 23 2025 19:11:47 00:00:21.77 dwusbgadgetendpoint0.cpp(181): stack[7] is 0xAF28 00:00:21.77 dwusbgadgetendpoint0.cpp(181): stack[13] is 0xA6D8 00:00:21.77 dwusbgadgetendpoint0.cpp(181): stack[29] is 0x9814 00:00:21.77 dwusbgadgetendpoint0.cpp(181): stack[33] is 0x10000 00:00:21.77 dwusbgadgetendpoint0.cpp(181): stack[39] is 0x963C 00:00:21.77 dwusbgadgetendpoint0.cpp(181): stack[45] is 0x9974 00:00:21.77 dwusbgadgetendpoint0.cpp(181): stack[55] is 0x13E24 00:00:21.77 dwusbgadgetendpoint0.cpp(181): assertion failed: pSetupData->wLength <= sizeof m_OutBuffer
The ITX Llama still isn't able to detect the storage device during BIOS startup either.
Would looking at the way how the gadget subsystem in Linux help? As mentioned earlier, I never had the issue with that implementation.
This log does not contain the messages from USB_GADGET_DEBUG,, so it's difficult to understand, what happened, as it is anyway. Be sure, I already have looked into the Linux code (there is no other reference).
When I enabled debug logging, it was unable to complete a usb mass storage connection to my macintosh I waited about 20 seconds longer than usual
I can try it again with the debug logs, are there specific ones I should enable to target what we're looking for?
There is a new version on the usb-gadget-fix branch, which sends a STALL now on receiving an invalid length value in a SETUP packet, instead of failing an assertion.
If you want to test it and it does not work, please enable USB_GADGET_DEBUG globally as a system option (with configure -d in Circle or configure -o in circle-stdlib) and rebuild everything. Perhaps it makes sense to out-comment the dump of transferred data here to speed up operation.
I haven't had the chance to run this just yet, but I did create a small patch to limit the amount of data that is being logged but still allows for normal USB handshakes.
Is this acceptable for testing?