Recently I’ve bought myself a Seeed Studio XIAO ESP32C3, and I eventually want to program it using Rust. I thought it would be nice to also be able to test the code with the usual CI runners so for that purpose I would like to emulate the ESP32C3 chip. Espressif maintains a fork of qemu that allows that: GitHub - espressif/qemu: Fork of QEMU with Espressif patches. See Wiki for details. so I wanted to package that version for use in my devShell (and later the automated tests).
The build system uses Meson, which I’m not familiar with, but I managed to work around some subproject that Meson would try to download during the build by ‘manually’ prefetching the subproject repos. Is there are more idomatic nixpkgs way to do this?
If I build my expression I get a qemu that seems to work (starts, doesn’t just crash immedately), but I have not been able to build a working image to run on it. I’m not sure if this means that the derivation is broken after all, or if my images are wrong. Any tips would be appreciated.
I don’t really have anything fit for public consumption yet, but as a first step I’m reproducing https://n8henrie.com/2023/09/compiling-rust-for-the-esp32-with-nix/ and trying to update it to current versions. I then would like to be able to put a simple ‘blink’ type program into qemu as a proof-of-concept.
It looks like we’re trying to achieve something similar, but I’m still confused. Thanks for the tip.
（which I was try to run qemu for raspberry4B in nixos though qemu-patch-raspberry4, which I thought is quite hard to understand what exactly this repo has done）
Cross compile C/C++/Rust code from x86_64-linux (and ideally aarch64-linux) to a riscv variant that works on an esp32c3 chip. This I can do for a physical chip using particular pinned versions of rust/nixpkgs but I’m not able to use current nixpkgs for example. That relates to the issue I linked.
Emulate said esp32c3 using qemu on x86_64-linux (and ideally aarch64-linux). That is what my PR is for. If this is not accepted into nixpkgs, I’ll create a flake repo for it.
Create a binary payload from step 1 (using e.g. espflash) to use in the emulator. I haven’t managed to find the correct incantation for that yet. The best result so far is getting qemu stuck in a boot loop.
If qemu-patch-raspberry4 is another qemu fork you will probably be able to use my PR as inspiration at least.
For those still interested in this: I’ve found a less invasive way of working around the linker error that I encountered and the example code no longer patches nixpkgs, but just injects an additional cargoBuildFlag for the example package. So, we no longer need to rebuild the whole Rust stack, which is a big improvement imo.
Yesterday I’ve updated my nix-qemu-espressif flake to
esp-develop-9.0.0-20240606, and I’ve cleaned and updated the Rust on ESP32C3 example. Hope it’s useful for someone (other than myself).