USB-MSD non-functional after merging v5.1 to v6.x (seems to be internal USB stack issue?)

[VintagePC]

Hello!

Sending to the list because I was directed here after asking on IRC. 

Background: I've forked QEMU for a project and am in the process of implementing a more complete STM32F4xx stack as a secondary task.

To resolve recent GCC11 build errors, I attempted to merge with upstream QEMU v6 (coming from a late 2020 v5.x.x) and to my surprise, USB mass storage is no longer functional. A few packets are exchanged but at some point I 

At first I suspected the issue was my own code (fair, my implementations are in varying states of completeness. The STM32F4 USB controller has many similarities to (but is not quite the same as) the DWC2 USB stack). 

I decided to bisect the merge in order to identify the commit that causes the issue - and much to my surprise, it is this particular commit:

https://github.com/qemu/qemu/commit/bbd8323d3196c9979385cba1b8b38859836e63c3

Given this doesn't seem to be anything more than a relocation of declarations (and I don't even use any of these types directly in my code), this would seem to suggest an internal issue in linking or memory initialization. I'm happy to assist in debugging this where I can but I'm hoping someone more knowledgeable about the QEMU USB innards might be able to point me to an area to start digging since the change seems entirely orthogonal to the actual problem and could be just about anywhere. 

The command line I'm using is as follows:

./qemu-system-buddy -machine prusa-mini -kernel firmware.bin -device usb-storage,drive=usbst -drive id=usbst,file=SDcard.bin

where SDCard.bin is a bog-standard image of a FAT32 partition. (using VFAT folder emulation is similarly non-functional). Unfortunately the device does not support anything other than MSD so I cannot check  functionality with other USB devices.

I've been told this problem is not unique to my own development setup, and a cursory investigation reveals one of the symptoms is a divergence in the size of the incoming USB packets. (I'm hoping to set up a more detailed packet capture when I have more spare time this weekend). For example, the working version I will see some initial setup packets be exchanged, then a few packets of size 1, 36, 13, 13, 14, etc as the ARM firmware talks to the device. (Back when I implemented the USB stack I spent a lot of time debugging and comparing wireshark captures so I'm reasonably confident the USB handling code is correct since the firmware being run is doing full on FAT filesystem support). After merging the offending commit, I see the initial setup and then a series of packets of size 1, 36, 16, 512, and then nothing further. (Internally on the firmware the USB bus gets stuck because this last packet of size 512 is obviously junk and a symptom of the issue.).  --enable-sanitizers revealed only a minor bug elsewhere that was unrelated to the issue (and did not resolve it when fixed)

The project itself is here: https://github.com/vintagepc/MINI404 with all of my custom implementations temporarily residing in hw/arm/prusa/stm32f407 (see footnote/P.S.)

Thanks in advance for any assistance!

VintagePC.

P.S. - Yes, I recognize it's not organized and formatted entirely in the same style as the rest of QEMU and probably violates a few style guide items. As this is a spare time project (and because I am also leveraging prior work from non-upstream sources) I need to be as efficient as possible in making changes and being able to debug things. Longer term... yes, I am absolutely supportive of getting STM32F4 support upstream because I know there is significant value here. But as it is right now the parts are not functional/polished enough that I feel comfortable doing so - and I just don't have the bandwidth to spend time on that in addition to the project itself. In the long term once the SOC implementation is more complete, I definitely hope to be able to shift focus to refactoring and making what I believe to be sufficiently functional implementations ready for upstream submissions. (And if someone reading this is keen and willing to help, feel free to contact me off-list! to collaborate and/or discuss what needs to happen to make it submittable!)