On the 27th May 2025, the VirtualBox team released a beta version of VirtualBox 7.2.0, which includes support for running on Windows on Arm hosts. You can see the release announcement here. For me, the main addition in this release is the support for running VirtualBox, and more specifically the VirtualBox Extension Pack, on Windows on Arm hosts.
I tinker with embedded software development, targeting hosts like the RP2040, STM32 and other microcontrollers. Having been a Linux user for the whole of my career, I use WSL2 on my Windows host to give me access to a familiar Linux environment.
Having moved from an M1 Macbook Pro to a Qualcomm Snapdragoon Elite based Windows laptop about a year ago, I had been hopeful that the development environment on the Windows platform would be as robust as MacOS in terms of developer tool support.
Initially, all went well. WSL2 worked great out of the box, and I can easily run a remote development environment from VSCode on the Windows host. All development tools installed fine, and I could build an application using the Embassy framework that targeted the RP2040.
But this is where things started going wrong. If I waned to deploy and debug the application to the RP2040 using the probe-rs tool, the WSL2 environment needed access to the USB device that was attached to the debug probe. For a WSL2 environment, this normally happens though use of the usbipd service that proxies access from host devices to guests. While usbipd had a build available for Arm targets, it made use of the VirtualBox Extension Pack to provide USB support, and there wasn't a version available for Windows on Arm hosts.
Interestingly, I could hack something together that would just about work well enough for me to contune development. If I installed the required tool on the windows host, in this instance the probe-rs tool, and change the .cargo/config.toml configuration to use probe-rs.exe instead of probe-rs, the WSL environment would use the Windows version of the tool, and I was able fo upload images to the target and monitor the debug output. So for the embassy examples, I could use the following patch:
diff --git a/examples/rp/.cargo/config.toml b/examples/rp/.cargo/config.toml
index 3d7d61740..db3e77a06 100644
--- a/examples/rp/.cargo/config.toml
+++ b/examples/rp/.cargo/config.toml
@@ -1,5 +1,5 @@
[target.'cfg(all(target_arch = "arm", target_os = "none"))']
-runner = "probe-rs run --chip RP2040"
+runner = "probe-rs.exe run --chip RP2040"
[build]
target = "thumbv6m-none-eabi" # Cortex-M0 and Cortex-M0+
This was fine as a short term workaround, but it was not ideal as I was unable to get the full debugging experience working. What I really needed was native support for the VirtualBox Extension Pack on Windows on Arm hosts.
After installing VirtualBox and the corresponding extenion pack, then ensuring that WSL2 and usbipd were both at the latest version, it was time to give it a spin and see if I could get direct access to the debug probe from my WSL2 environment.
Microsoft have some good documentation on how to install and use usbipd to attach a USB device to a running WSL2 instance. I'm not going to rehash the details here, please follow those unstructions to get your environment set up.
As a sanity check, I first check that the debug probe is not visible to the WSL2 environment.
> lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Next, from the windows host, list the attached USB devices. I have removed all devices other than the debug probe for brevity.
> usbipd.exe list
Connected:
BUSID VID:PID DEVICE STATE
...
8-1 2e8a:000c CMSIS-DAP v2 Interface, USB Serial Device (COM4) Not shared
...
Persisted:
GUID DEVICE
Now I can bind the device to usbipd. This requires me to be running a command prompt with administrator privileges.
> usbipd.exe bind --busid 8-1
The next step is to attach the device the running WSL2 instance.
> usbipd.exe attach --wsl --busid 8-1
Now we can check in the WSL2 environment to see if the device is visible.
> lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 2e8a:000c Raspberry Pi Debug Probe (CMSIS-DAP)
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
One last check, to see if probe-rs can also see the device
> probe-rs list
The following debug probes were found:
[0]: Debug Probe (CMSIS-DAP) -- 2e8a:000c:E6614103E7723E2F (CMSIS-DAP)
For now, it looks like it is all working! This is a great step forward for me to make my Windows on Arm laptop a more complete development platform. Next step will be to get the debugging environment up and running, but thats for a different post.
I would like to extend my thanks to Oracle and all the VirtualBox team for their hard work getting this release out, it is an invaluable tool, and its great to see it back in my development toolbox.