mkinitramfs.sh, mkimage.sh and run.sh all read $OUT, and ui-drive.sh left
it at the shared default, so two concurrent runs built and booted the same
qemu/out/disk.img and wrote their userdata into it: a VM seeded with
role=1 read back client because the unseeded run next to it had rebuilt
the image (#20). Each run now builds and boots its own image under
$TMPDIR (real disk; /tmp is a tmpfs on the dev box and the run refuses to
start with under 1 GB free there), keeps the pinned busybox shared and
read-only through BUSYBOX, and removes the image on exit.
Verified: a seeded router-mode flow, the unseeded client-mode flow and a
third flow booted at once, 25/25, 25/25 and 10/10, each reading its own
role.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N3G6m9Aw5RyVY4ZowtKzEj
The control bridge sent a command, slept 0.3 s and read /tmp/warden-ui.dbg,
so a page that took longer to build handed the host the previous command's
reply as if it were this one (flare-edge #152). It now removes the old
reply before sending and waits, up to 5 s, for warden-ui to rename the new
one into place, the same recipe tools/warden-ctl and flow-run-hw.sh use.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013aHKWzT5EF86RFKRMtAv9n
Stage-2 init started only warden-flared and warden-modbus from the
payload, so every daemon-backed screen (Automation, MikroTik, Mining,
RS485, Starlink, Services) sat in its "not running" state on the rig
while the bench panel showed the daemons up with nothing attached. It now
starts every warden-* daemon it finds in the panel's own S-number order
(ai, automation, modbus, mikrotik, asic, starlink, stratum, flared), each
with no arguments as start-stop-daemon runs them on the panel. flare-edge
tools/rig-pull-daemons.sh copies a panel's static binaries in.
Doing that exposed a latent alias: init pointed warden-modbus's /dev/ttyS4
at /dev/ttyS0 whenever ttyS0 existed, and with --ctl that port IS the
control channel, so Modbus polls arrived inside the wake reply and the
bridge hung. run.sh now always attaches an RS485 pci-serial (a null
chardev without --rs485), and init aliases ttyS4 to ttyS1 when warden.ctl
is on the cmdline, ttyS0 otherwise.
Verified on a boot with all eight daemons: status json reports
automation.engine, mikrotik.backend, mining.available and rs485.available
true with the Modbus scan sweeping the empty UART; six daemon-backed pages
matched screenshots of the bench panel structurally (0/256 cells differ).
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013aHKWzT5EF86RFKRMtAv9n
- tests/qmp.py: `wake` is a judged verb (the reply must be the channel's
own ack) and `assert_stat` knows `idle` (0 awake, 1 dimmed, 2 asleep).
warden-ui's sleep.c swallows the touch that wakes a dimmed or blanked
panel, so every compiled flow script now opens with wake (flare-edge
#148); tests cover both.
- run.sh: vt.global_cursor_default=0. fbcon shares the virtio-gpu
framebuffer with warden-ui and its cursor blinked an 8x2 block onto the
top-left corner in some boots and not others, which made a structural
pixel reference fail by one cell (#18). The panel has no fbcon on its
display, so this only makes the rig match it.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013aHKWzT5EF86RFKRMtAv9n
- rootfs/sbin/init: the control bridge answers `@cat PATH` locally so the
driver can read /tmp/warden-web-status.json out of the guest. That file
has no trailing newline; the bridge adds one so the sentinel stays on
its own line and the line-based reader never blocks.
- tests/qmp.py: wait_json/assert_json (dotted paths, eq/ne/contains/
len_eq/len_ge/gt/lt), assert_stat off the FIFO's stats reply,
capture_region, assert_region NAME [TOLERANCE] and assert_ocr. A
tolerance other than the captured one, a reference box that does not
fit the screendump, a missing reference or a missing tesseract is FATAL
for that step and the run continues (flare-edge #147).
- tests/imgtools.py: P6 reader, crop, perceptual and structural hashes,
compare, with a self-test.
- tests/test_qmp_drive.py: drive() with QMP and the control channel
faked, pinning the per-step ok/fail/fatal contract.
- mkimage.sh SEED_DIR and ui-drive.sh --seed/--refs: settings fixtures
staged into userdata before warden-ui starts, and a reference store
handed to the driver.
- ci: the driver tests and the imgtools self-test run in qemu-tools.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013aHKWzT5EF86RFKRMtAv9n
The rig could drive the UI and detect one outcome: the process died. Nothing
could ask the UI what page it was on or what a tap would land on, because
that channel is a FIFO inside the guest and the initramfs is busybox-only
with no sshd. Scenarios therefore asserted nothing and screenshots went
unread.
run.sh --ctl exposes a second pci-serial port as a unix socket, the same
device the RS485 bridge already rides, listed first so it is always ttyS0.
It also puts warden.ctl on the kernel command line, and init bridges only
when that marker is present: a VM launched with --rs485 alone has a ttyS0
too, and that one is the Modbus wire. The bridge relays one command line in
and the FIFO's reply out, then a sentinel so the reader needs no timeout.
qmp.py gains the channel verbs (nav, page, stats, hit, assert_page,
assert_hit), records every step to results.jsonl as ok/fail/fatal, continues
past an assertion mismatch so one run reports every broken expectation, and
checks the console after EVERY step for the stage-2 init's EXITED line so a
crash is pinned to the step that caused it. assert_hit matches the widget's
bounding box: an icon has no usable caption and two list rows share a class,
but the geometry the UI itself resolved is exact.
The vocabulary is what tools/warden-ctl already speaks over SSH to a real
panel, so a script that runs here runs there. Verified end to end on the rig
(11/11 verbs round-tripped) and against the bench panel, where the same
commands returned byte-identical results.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013aHKWzT5EF86RFKRMtAv9n
U-Boot draws the boot splash from resource.img by name, and now draws a second
image by name when the splash is tapped: the same logo with its bottom-right
mark reading VERBOSE instead of GRAPHIC. Without --logo-verbose that image is
absent from the FIT and a tap changes nothing on screen, even though the boot
itself would still go verbose.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013aHKWzT5EF86RFKRMtAv9n
The probe piped the candidate binary into grep to look for -B support.
mkimage with no arguments prints usage and exits non-zero, and this script
runs under `set -euo pipefail`, so the pipeline reported failure even when
grep matched. Every candidate was rejected and the script failed closed with
"no mkimage on PATH supports -B" while a capable mkimage 2025.01 sat first
on PATH, making it impossible to build a boot.img at all.
Neutralise the probed command's exit status before the pipe. Sentinel
comments now bracket the probe so the new regression test extracts and
exercises the shipping code rather than a copy of it.
Closes#17
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
054790d claimed the vendor aligns FIT sub-images to 0x800 and made that a build
gate. Both were wrong, and the reasoning was thin: two payloads from one build,
generalised into an invariant.
What U-Boot actually requires. IMAGE_ALIGN_SIZE is 512 (include/image.h:955-958)
and the read is blk_off = (FIT_ALIGN(fdt_totalsize) + offset) / blksz
(arch/arm/mach-rockchip/fit.c:331), a truncating divide by the 512-byte eMMC
block. So the metadata size must be a multiple of 512 -- otherwise FIT_ALIGN
rounds it up and EVERY payload is read late, including ones whose own position
is perfectly aligned -- and each data-position must be a multiple of 512.
Nothing in the FIT or RESC path references 2048.
Why the 2048 gate was actively harmful: of the eight boot.img files on this
machine, four are 512-aligned but sit at data-position % 2048 = 1536, including
vendor RELEASE_TEST builds that boot. The gate would have rejected images the
vendor shipped. 0x800 is the vendor's -p value -- the file position of the FIRST
payload -- not an alignment; 054790d moved it into the -B slot.
And it broke the build inside the SDK. mk-bootimg.sh resolves mkimage with a
bare `command -v`, project/build.sh:64 prepends the SDK tool directory to PATH,
and the SDK vendors mkimage 2017.09, which has no -B and exits 255 with
"invalid option -- 'B'" under set -euo pipefail. The 6.18 image built only
because it was made from a normal shell that found host mkimage 2025.01. The
flag is now feature-detected; the vendor packer 512-aligns natively, so omitting
it there is correct rather than a fallback.
9387cff's -B 0x200 was right, and better derived than 054790d credited: the
proven image's resource sits at 8748544, a multiple of 512 but not of 1024 or
2048, which pins the alignment at exactly 512 rather than bounding it.
The gate now asserts what U-Boot enforces -- metadata % 512 and every
data-position % 512 -- and the embedded-data guard drops from 65536 to >= 4096
to match FIT_FDT_MAX_SIZE (SZ_4K, fit.c:24). At 65536 a 5000-byte header passed
the build and returned "No fit blob" on a panel.
The already-flashed 6.18 boot.img is unaffected: 2048 is a multiple of 512, so
it satisfies the real requirement, which is why it booted.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
mkimage -p only places the FIRST payload. The rest are packed contiguously, and
U-Boot reads each by dividing its data-position by the 512-byte block size with a
truncating divide -- so a payload that is not block-aligned is read from the
wrong offset. Measured: without -B this script emitted the kernel at 0x9A94,
data-position % 512 = 148, which is exactly the failing shape.
That failure is on record. flare-edge 9387cff (2026-09-01) hit it on a boot_b
FIT: "unaligned sub-images fail the RESC loader's sha256 and the logo silently
falls back to 'No resource file'". It landed on -B 0x200, inferred from noticing
the proven image was "512-aligned" without checking for a larger factor.
The proven images are aligned to 0x800, not merely to 512. Measured on the pair
that boots this board today: boot.img fdt/kernel/resource at 0x800 / 0x12800 /
0x3A7800, recovery.img at 0x800 / 0x12800 / 0x3F8800 -- every one a multiple of
2048. So 0x800 satisfies everything 0x200 does, since every 0x800 multiple is a
0x200 multiple, and additionally reproduces the vendor layout exactly. The cost
is at most 2 KiB of padding. Where a remembered rule and a booting image
disagree, match the image.
The alignment is now also asserted at build time rather than trusted. It runs on
every build because the failure it catches is silent -- a wrong offset does not
fail the build, it fails on a panel, and only sometimes visibly.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
The firmware builds against sysdrv/source/buildroot/buildroot-2025.02.8 in the
vendor SDK. That tree is not in the vendor checkout -- the SDK ships 2023.02.6 --
it was not in this manifest, and nothing anywhere recorded its origin. A clean
rebuild on another machine silently fell back to the vendor's older buildroot
and produced a different userspace, which is flare-edge#135.
fetch-buildroot-tarball.sh follows fetch-kernel-tarball.sh exactly: pinned URL,
pinned sha256, fails closed on a missing pin. Buildroot signs releases with GPG
rather than publishing a .sha256, so the pin was computed from the tarball and
is what the script verifies against.
The manifest now says out loud that two of the inputs are tarballs rather than
git trees, so "which buildroot" has an answer in the same place as "which LVGL".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
The VM builds warden_defconfig plus virt.fragment, so it has CONFIG_BRIDGE; the
vendor 5.10 kernel most panels still run does not. A Client-mode access point is
bridged to the wired uplink and needs that, so the Wi-Fi page offers it here and
declines on a 5.10 panel.
Both answers are correct for the kernel underneath, which is exactly why it is
worth writing down: a screenshot from the VM is not evidence about that page on
a 5.10 panel until the fleet has moved to the 6.18 build.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
The vendor 5.10 kernel is built without CONFIG_BRIDGE, and that absence has
shaped the firmware: the panel's access point has to be its own subnet with its
own DHCP pool instead of joining the LAN, and warden_router_set_zone() treats a
second LAN port as impossible. Both carry a code comment saying "this kernel has
no bridge".
Turning it on is what lets a Client-mode panel run an access point the way an
ordinary ceiling AP does -- wlan0 and the wired uplink in one broadcast domain,
addresses handed out by whatever router is already upstream.
Verified on the bench panel: before, `ip link add type bridge` returned
"Operation not supported"; on this kernel the bridge is created and eth0
enslaves into it (/sys/class/net/br0/brif/eth0). WireGuard, iptables and VLAN
still work.
Also fixes a warden-modbus path in architecture.md left stale by the apps/ move.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
The series was built, packaged with mk-bootimg.sh, and booted on the bench
panel: display, backlight, Goodix touch, RGA, eth0 and the usb0 gadget all
work, with no kernel faults. M4/M5/M6 in this file are stale.
The same test is what proved the three missing subsystems were real rather than
a reading of the config: wireguard, iptables and VLAN each failed on the panel
before the defconfig fix and each works after it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
LVGL and the vendor RV1106 SDK are what this platform is built against, and
nothing in this repo said WHICH ones. The two live outside every worktree as
shared checkouts, so "the version we build against" was whatever happened to be
on the machine.
They are pinned here now, by exact commit, with one script that obtains and
verifies them. Not copied: between them they are ~21 GB, the vendor SDK bakes
absolute paths into its host tools so it has to sit at one stable path anyway,
and a 21 GB git repo would be unusable while still not making anything
reproducible. What makes a build reproducible is knowing exactly which tree was
used, which is a commit id -- the same reasoning build/fetch-kernel-tarball.sh
already applies to the kernel, where a sha256 pin stands in for vendoring the
tarball.
Two behaviours worth stating, because both were wrong in the first draft:
- A checkout is detected by `.git` EXISTING, not by it being a directory. LVGL
is checked out as a worktree here, where `.git` is a file.
- Local modifications are reported and are NOT a failure. The vendor SDK is
supposed to carry them -- tools/build-firmware.sh applies our sdk-patches
series into that tree on every build -- so a pristine checkout is the
unusual state. Only a MISSING or DRIFTED tree fails.
Nothing is ever reset automatically: a tree off its pin is reported, because a
local change to a vendor tree is usually someone mid-debug, not something to
throw away on their behalf.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
Two gaps between "this SDK builds a kernel" and "this SDK can replace the
vendor SDK for the device".
BOOT IMAGE. build-kernel.sh emitted a zImage and a dtb and stopped, so
producing something the board's U-Boot would actually boot still meant going
through the vendor tree. mk-bootimg.sh packages the pair the way M2 bring-up
established (kernel/docs/m2-boot-on-c8a3.md): an EXTERNAL-DATA FIT
(mkimage -E -p 0x800), a mandatory `resource` multi sub-image carrying
rk-kernel.dtb plus any logos, and the sysmem sentinel load addresses. Each of
those was learned from a specific failure -- an embedded-data FIT is "No fit
blob", a missing resource image is "Failed to load DTB, ret=-19", real load
addresses collide -- so the script also ASSERTS the metadata stayed small,
because an embedded-data FIT looks perfectly fine until a panel will not come
back.
NETWORKING. Diffing this defconfig's expansion against the kernel actually
shipping on the panel found three whole subsystems missing, none of which fail
at build time and none of which are visible until the unit is in the field:
- WIREGUARD + NET_UDP_TUNNEL: flared's mesh to FLARE. Without it wg0 never
comes up.
- VLAN_8021Q: the MikroTik app configures tagged ports the panel terminates.
- NETFILTER and legacy iptables: every rule in S35iptables, and NAT for
router mode.
The netfilter half carried a trap worth naming. 6.18 split the legacy tables
out behind NETFILTER_XTABLES_LEGACY and IP_NF_IPTABLES_LEGACY, symbols that do
not exist in 5.10 -- so copying the vendor kernel's symbol list verbatim gives
a kernel where IP_NF_FILTER and IP_NF_NAT silently stay off and `iptables` has
no filter or nat table at all. Our userspace drives legacy iptables, not nft.
The result now shows ZERO regressions against the shipping 5.10 kernel across
mesh, gadget, firewall, VLAN, storage, net core, display/input, RGA/NPU,
wifi/BT and watchdog.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
A scenario driving the VM from outside can only see the console, and the UI's
own log was going to a file inside the guest -- reachable only after the
process exited. That made a whole class of question unanswerable while the UI
was still running: what the UI thought it was doing at the moment a screenshot
looked wrong.
It paid for itself immediately: a dashboard fullscreen that kept reverting was
a full UI rebuild firing 553 ms after the tap, which the console showed
outright (flare-edge: the applier's first-tick rebuild).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
ui-shot.sh proves touch reaches the UI in one tap. Verifying a UI change needs
a SEQUENCE -- swipe through the app rows, open a submenu, tap a tab, bring up
the keyboard -- and booting per step costs about a minute under TCG, so:
- qmp.py gains a `drive` mode: one connection, one boot, a script of
tap/swipe/fling/shot/sleep steps in PANEL PIXELS rather than the raw
0..32767 tablet axis. Swipes interpolate their motion, because LVGL decides
a gesture from the movement between indev polls and a press-then-release
with nothing in between is a click, not a scroll.
- ui-drive.sh runs such a script against a booted VM and collects the
screenshots.
It also FAILS on a UI that died mid-script. warden-ui crashing leaves its last
frame in the framebuffer, so screendumps keep returning a plausible picture of
a program that no longer exists; stage-2 init now announces the exit and its
status on the console, and ui-drive.sh greps for that after the run. This is
what caught the SIGSEGV behind flare-edge#125.
Stage-2 init also mounts devpts. The UI's Terminal page opens a PTY, so
without it that page could only ever report "no PTY available" -- it rendered,
which made a screenshot scenario look fine while the one thing the page does
was untestable.
tests/scripts/nav-stress.txt is the first committed drive script: the
navigation sequence that reproduces flare-edge#125.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T2D2KtdgwbhbF6Mo64eUrn
