Note: This entry originally appeared March 16, 2021 on my old blog platform.
I’m writing this to help others who may be in the same predicament as me. I wrote this a while back when I ran Windows 10 on my personal laptop (gotta have those games) but I also enjoyed working with projects and developing in a Linux environment. WSL2 has been a savior; it gets me a working, performant Linux environment with ease. But, as I’ve been playing more lately with developing Rust applications in OpenBMC, one big thing has been holding me back: the ability to run the QEMU image for the OpenBMC device itself. Let me describe my workflow:
I’m writing this to help others who may be in the same predicament as me. I wrote this a while back when I ran Windows 10 on my personal laptop (gotta have those games) but I also enjoyed working with projects and developing in a Linux environment. WSL2 has been a savior; it gets me a working, performant Linux environment with ease. But, as I’ve been playing more lately with developing Rust applications in OpenBMC, one big thing has been holding me back: the ability to run the QEMU image for the OpenBMC device itself. Let me describe my workflow:
- I have WSL setup with rust, cargo and cross. This allows me to build binaries for ARMv5.
- I use VSCode loaded into the WSL2 environment using the remote development extensions.
- Once I build my binary using cross, I SCP it to a running OpenBMC instance running via QEMU on a remote Linux box.
Now, this workflow has been working alright, but I hate to have a dependency on some second Linux box that is dedicated just to running this tiny ARM image. So I started doing some research.
I found that QEMU supports the same virtualization extensions in Windows 10 that WSL2 leverages to run as a lightweight VM without requiring a full Hyper-V installation. Using this, I don’t have to install and configure Hyper-V along with a separate Linux VM that would suck resources and have to be maintained just emulate some basic software.
Here is the procedure for getting this up and running:
- Make sure you have the Windows “Virtualization Platform” feature enabled. If you are running WSL2 already, this should be on. If it’s not, do a search for “Windows Features” and enable it.
- Download a build of QEMU for Windows. You can find links here to the installers: https://qemu.weilnetz.de/
- After running the install, add the binaries to the path variable for your Windows installation.
- Download the latest OpenBMC development image, found on the Development Environment setup documentation https://github.com/openbmc/docs/blob/master/development/dev-environment.md).
- Reboot or logout/login to reset your environment variables.
- Open up a Windows Terminal (which is also awesome!) and navigate to where the emulated image is.
- Run the following command to start the image:
qemu-system-arm.exe -m 256 -M romulus-bmc -nographic -drive file=obmc-phosphor-image-romulus.static.mtd,format=raw,if=mtd -net nic -net user,hostfwd=:127.0.0.1:2223-:22,hostfwd=:127.0.0.1:2443-:443,hostname=qemu
- Default login is “root” and password “0penBmc” (that’s a zero). End the session with ctrl+a, ctrl+x.
- You can also ssh via the forwarded port 2223.
Using this process, I have been able to remove the dependency on my secondary box and continue developing using only my Windows box.