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!)

Reply via email to