The msd payload used to expose the SD card over USB on the Pi Zero W is firmware. I wanted to modify its behaviour to be able to reboot the gadget without physically replugging the Pi.
So I built a Linux-based replacement for that payload for the Raspberry Pi Zero W v1.1. The Pi boots a small cross-compiled kernel plus an initramfs containing a freestanding init (C, no libc). It waits for the SD card, exposes /dev/mmcblk0 as a USB mass-storage device via configfs, and reboots on eject (and also reboots if no card appears within 20s). The whole thing builds reproducibly with a Nix flake into an rpiboot boot directory, deployed with rpiboot -d result.
Tested end-to-end on real hardware.
Sharing in case it's useful to others hitting the same limitation, and I'd welcome thoughts on whether a Linux-based MSD payload like this fits anywhere in the usbboot ecosystem (perhaps merging 32 and 64 bit directories at some point).
Repo: https://github.com/FraFrieFa/rpi-zero-usb-gadget
The
msdpayload used to expose the SD card over USB on the Pi Zero W is firmware. I wanted to modify its behaviour to be able to reboot the gadget without physically replugging the Pi.So I built a Linux-based replacement for that payload for the Raspberry Pi Zero W v1.1. The Pi boots a small cross-compiled kernel plus an initramfs containing a freestanding
init(C, no libc). It waits for the SD card, exposes/dev/mmcblk0as a USB mass-storage device via configfs, and reboots on eject (and also reboots if no card appears within 20s). The whole thing builds reproducibly with a Nix flake into an rpiboot boot directory, deployed withrpiboot -d result.Tested end-to-end on real hardware.
Sharing in case it's useful to others hitting the same limitation, and I'd welcome thoughts on whether a Linux-based MSD payload like this fits anywhere in the usbboot ecosystem (perhaps merging 32 and 64 bit directories at some point).
Repo: https://github.com/FraFrieFa/rpi-zero-usb-gadget