There’s probably a limit to the number of devices you can operate at the same time. There is code in the HCD (host controller driver) to reuse the fixed resources, but it has not been extensively tested. MCCI has a test tree of 30+ hubs and 90+ mass storage devices that we use for enumeration testing; once we have clear instructions that I can give our test lab so we can set up Win10 here on a Pi, we can at least run tests and record problems.
Even if multiple devices work, it is certain that performance will decrease if you have more than a few devices active. Only 8 transfers can be active on the USB bus at one time. We attempt to rotate the operations through the hardware, but for use cases like video conferencing while recording to a USB SSD (think of Zoom, for example), things may get quirky. (Video conferencing while recording needs high-bandwidth isoch in for the webcam, usually; audio is 2 channels for IN and OUT, mass storage has a channel for the data transfer… it seems possible, but there are also channels for hubs, HID class, controls on audio, etc.)
webcams may have issues.
audio works but again has not been really stress tested (looking for pops, etc.) Making audio work is “hard real-time” – we have to service the hardware and schedule new stuff every 125 us.
although I wrote Windows portion of the code very defensively, it’s possible that there are BSODs lurking, especially because of the inevitable differences between the MCCI implementation and the Microsoft implementation. (Our core code is portable and OS agnostic; all the WIndows-isms are at the edge. Microsoft wrote to their APIs. This results in much different synchronization patterns and callback patterns to the client drivers.)
Most of the above can probably be fixed. But it probably requires my time, because I did all the low-level Windows work, and I have severe constraints.
Feel free to report issues here (or go to the MCCI support portal to get an official ticket number.)
Start=3 in HKLM\ControlSet001\Services is set by default for both the HCD and HUB driver, Start=0 is needed for USB Boot. (INACCESSIBLE_BOOT_DEVICE BSoD when Start=3)
with Start=0, the USB driver loads and Windows can read its boot files normally off a USB HDD, but 0xc000021a BSoD follows afterwards. Needs further testing though.
Environment:
Raspberry Pi 3B
Andrei’s UEFI Build Jan 16 2019
Seagate HDD on a JMicron JMS578 based USB Harddrive cage.
Since NtSetSystemPowerState is in the backtrace, it seems possible that the root cause is the USB driver’s response to a previous power-management IRP. I’d try displaying more of the string at ffffb28ce29a5230 – they only displayed invalid session process or… and there might be more info near that string.
There is a log of power management actions available via one of the ! commands. Or we’d have to run the checked drivers and get the debug log.
An alternative is that there’s something wrong in the hard disk image (possibly because of a previous boot attempt that clobbered the registry?).
For those of you looking to boot from USB (if we get to that point) - I’d recommend taking a look at the Geekworm X850 setup. I have one. The case is great and allows for three heatsinks to be installed. The board has it’s own power input for the hard drive which is an MSATA. For anyone looking to use a standard 2.5 HDD or SSD, I’d look at the X820. Either way, here’s a link to the X850.