Upstream, and this fork¶
Every number here was measured on a running board or read from a live server, on 2026-09-08. Where a claim could not be checked, it says so.
The two upstreams disagree with each other¶
Turing Pi publishes firmware by two routes, and they do not agree:
| route | newest | checksums |
|---|---|---|
| GitHub releases | v2.1.0 | — |
| firmware.turingpi.com | v2.0.5 | none published |
The mirror is what the stock web interface follows. On a board running anything newer, following it walks the board backwards.
No checksums at all
SHA256SUMS, sha256sum.txt, sha256 and checksums.txt all return 404
on the mirror. An image from there is trusted on TLS and nothing else —
which is why this fork labels such a source TLS only rather than
pretending it was verified.
Both routes ship as sources in this fork, precisely so the disagreement is visible on one page rather than discovered later.
Platform¶
| upstream | fork | |
|---|---|---|
| Kernel | 6.8 — not a longterm release | 6.12.109 LTS |
| Buildroot | 2024.05.1 (EOL) | 2025.02.17 LTS |
| Rust | 1.85.0 | 1.98.1 |
| Image size | — | 38.1 MB, 81 % of the UBI slot; build fails at 90 % |
Updating¶
| upstream | fork | |
|---|---|---|
| Bad image | power cut, hard-cutting four modules | reboots back by itself |
| Modules during a flash | power-cycled | untouched |
| What is staged | not reported | version, checksum, source |
| Newer release available? | mirror that stops at v2.0.5 | from any configured source |
| Install a chosen version | — | from the web interface |
The gate has promoted cleanly fifteen consecutive times, over the air, with all four modules running. Each time the modules' uptimes advanced by exactly the wall-clock duration of the flash — the evidence that nothing was reset.
What the gate cannot see
It checks that the daemon answers and that the switch ports exist. An image whose new feature is broken passes both. This fork's own metrics endpoint could have shipped completely broken and been promoted happily — which is why release verification is explicit and written down, not left to the gate.
Hardware the board could not see¶
| upstream | fork | |
|---|---|---|
| SoC temperature | none — no thermal node in any device tree | reads through thermal_zone0 |
| Fan | fixed persisted speed | kernel-driven from that sensor |
| Switch port state | not exposed | per-port link, speed, counters |
| Module power-on time | one shared bit, correct only for node 1 | per node, as a duration |
The temperature sensor is the clearest example. The driver was compiled in and never probed, because mainline describes no thermal node for this SoC — so the fan ran flat out with nothing to regulate against. Adding the node to the board device tree is what made both work.
Monitoring¶
31 Prometheus metric families, none of which existed upstream. The credential
is the part worth noting: /metrics takes a token that returns 401 against
/api/bmc, so a scrape config cannot power-cycle a module or flash the board.
Upstream has no metrics endpoint, so it has no equivalent question.
What is still missing¶
Honest gaps, not roadmap:
- A hardware watchdog. The gate cannot save an image that hangs before it runs. That still needs physical access.
- An EC certificate. The daemon mints an RSA-4096 self-signed certificate
at every boot, so every browser calls it insecure and there is no path to
install a real one but
scp. - USB flashing of a module is built and has never been exercised on this kernel.
- VLAN filtering and STP on the switch:
br0bridges all six ports flat.