qemu: device-sim bringup — boot smoke, A/B disk harness, virt kernel variant

The third simulator (deliberately not named "sim"): a QEMU -M virt VM that
boots the real 6.18.46 kernel and enters at -kernel zImage — everything below
(BootROM/idblock/U-Boot/real BCB A/B selection) is closed blobs + mask ROM
and is explicitly out of scope.

- qemu/mkinitramfs.sh: pinned static busybox (sha256 fail-closed) + rootfs/
- qemu/mkimage.sh: unprivileged sparse disk image with the device's canonical
  12-partition blkdevparts A/B layout (vda == mmcblk0 mapping)
- qemu/rootfs/: stage-1 init (by-name symlinks from PARTNAME uevents,
  whole-token warden.slot= parse, switch_root) + stage-2 init (userdata/oem
  mounts, slirp networking, payload daemon start)
- qemu/run.sh: runner with --slot/--rtc/--watchdog/--rs485/--qmp/--display
- qemu/configs/virt.fragment + WARDEN_KCONFIG_FRAGMENT hook in
  build/build-kernel.sh (canonical RV1106 build untouched when unset):
  adds PCI, pci-serial, i6300esb watchdog, WireGuard, virtio-gpu/input
- qemu/tests/boot-smoke.sh: sentinel-asserting boot test

Verified on QEMU 10.0.11: canonical zImage boots -M virt unmodified (the
feared DEBUG_UNCOMPRESS decompressor hang does not exist in 6.18); full
stack boots both slots; 12 by-name symlinks; userdata persists across
reboot; -rtc base=2021-01-01 reproduces the no-RTC wrong-clock class.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018HUayid7W5w7jBdb9Rrj1K
This commit is contained in:
BFE Engineering
2026-08-29 18:53:16 -06:00
co-authored by Claude Fable 5
parent 44cdf2bf38
commit bf3c93cf85
16 changed files with 680 additions and 0 deletions
+10
View File
@@ -0,0 +1,10 @@
# The device's canonical 12-partition A/B layout, expressed for the VM's
# virtio disk (vda). On hardware the same string names mmcblk0 and is baked
# into the U-Boot env — source: flare-edge docs/decisions/0003-partition-layout.md.
# There is no MBR/GPT anywhere: U-Boot and Linux both parse this string, which
# is why handing it to the VM kernel on the cmdline reproduces the exact
# partition map (vda9 = rootfs_a = hardware mmcblk0p9).
#
# Sourced by qemu/mkimage.sh (computes byte offsets from it) and qemu/run.sh
# (passes it verbatim in -append). Single source of truth — edit only here.
WARDEN_BLKDEVPARTS='vda:32K(env),512K@32K(idblock),512K(uboot),512K(misc),32M(boot_a),32M(boot_b),128M(oem_a),128M(oem_b),1G(rootfs_a),1G(rootfs_b),32M(recovery),1G(userdata)'