Hi,
> At some point during implementation of the STM USB stack must have run
> into the same problem with the communications choking during MSD init.
> And at the time (which involved a LOT of wireshark comparisons with a
> real USB drive on the host and on the DCW2 Rpi2 stack) I'd added the
>
Well... the plot thickens. I have found the smoking gun.
At some point during implementation of the STM USB stack must have run into the
same problem with the communications choking during MSD init. And at the time
(which involved a LOT of wireshark comparisons with a real USB drive on the
Hi Gerd,
Thanks for the reply!
> Is this reproducable on master branch somehow?
Interesting thought... I initially hadn't considered it very much because I've
got a bit of tunnel vision with my fork - but perhaps having a go with the
RPi2 which uses the DWC2 subsystem may manifest something
Hi,
> 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
Hmm, that is rather strange indeed.
> Given this doesn't seem to
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
