Note: the UEFI/ACPI stage and the FreeBSD loader.efi activity (that uses UEFI I/O services) have no problems finding and using the media. It is the FreeBSD kernel that has the problem below. Context: Windows Dev Kit 2003 is the known example. Context: main [so: 14] on/after Apr-18's 21d56b796634 The loader.efi based on such must be used. The earlier Jan-18's 896f556205c8 (kernel) is needed. Also: Need use of hw.pac.enable=0 in loader.conf . Context: USB3.2 media examples were Samsung PSSD T7 Touch's (2 GiByte and 1 GiByte) with cables for both USB-A and USB-C use. USB3.0 media examples were OWC Envoy Pro mini's (256 MiByte) USB-A connector. Context: It is not clear if this is aarch64 specific or not. I've no other test context for it. In testing the 2 types of USB3.* media that I've access to, The USB3.2 media are not detected by the FreeBSD kernel when connected to the USB-C ports (but are detected when connected to the USB-A ports): USB3.2 in USB-C port (no "umass0" or no "umass1" or . . .) USB3.2 in USB-A port (works) USB3.0 in USB-A port (works) Unfortunately, I do not have a way to form a USB3.0/USB-C combination. The fact that UEFI handles all the combinations leads to USB3.2 in USB-C as root media ending up with the kernel unable to mount the root file system, for example. But, if the boot does not need the media, it is just as if it had not been plugged in, no boot -v messages about the media at all. (May be the Windows Dev Kit 2003 makes for a good context to use in the effort to modernize the USB support in FreeBSD?) Side note: https://learn.microsoft.com/en-us/windows/arm/dev-kit/ reports: QUOTE When connecting an external keyboard or mouse, use the USB-A ports, not USB-C. Using USB-C to connect a keyboard or mouse will only work intermittently. END QUOTE That is not what this report is about. (Also: It is unclear if that note is about UEFI vs. Windows vs. it being more general.)
(In reply to Mark Millard from comment #0) The media here is a USB3.0 SSD, making a somewhat different case than the USB3.2 device reported previously. (I.e,, t\The 4th combination is now tested to some extent.) Interestingly, using an adaptor to USB-C for plugging in media after booting FreeBSD, I get different results on different systems (the only FreeBSD USB-C contexts that I've access to): ThreadRipper 1950X: media is detected. Windows Dev Kit 2023: same media is not detected. The ThreadRipper is a USB 3.1 context for the USB-C connector, not a USB 3.2 context, in case that matters. The WDK23 has its note about avoiding keyboards and mice via its USB-C connectors, which may indicate something relevant. Being plugged in already for booting also leads to lack of detection on the WDK23. It appears that FreeBSD just does not handle detection on the USB-C ports on the Windows Dev Kit 2023.