Skip to content

Firmware for the Turing Pi 2 that undoes its own mistakes

Upstream's last release was February 2025 and the maintainer moved on. A bad flash still meant a trip to the rack, an update still power-cycled all four compute modules, and the board's own temperature sensor was not in the device tree. This fork picks it up on a kernel that is still supported.

Install it Coming from stock firmware? What changed, row by row

18 / 1promotions / rollbacks — read off the board. The rollback is the point: a firmware that has never had to undo itself has not been shown able to.

6.12 LTSkernel, on Buildroot 2025.02 LTS. Upstream ships 6.8 on an end-of-life Buildroot.

0 modulespower-cycled by a firmware update. Upstream cuts all four.

  • Firmware slots: what is running and what it falls back to

    A bad image undoes itself

    Boots the new image tentatively; keeps it only if the daemon answers and every module's port is present.

  • Every candidate version, from every configured source, with its checksum state

    Pick a version, from anywhere

    This fork, upstream's two catalogues, or the SD card — side by side, each checksum-verified or marked as not.

  • Board health: memory, NAND erase blocks, clock sources

    See what the board sees

    The temperature sensor upstream never described, which trip point set the fan, NAND wear, and what the clock is synced to.

  • A serial console in the browser showing a module's live kernel output

    A console to every module

    Four serial consoles in the browser, no header, no adapter — each opens on the module's recent output.

  • Per-module power and USB routing

    Power and USB, per module

    Power, reset, USB routing and flashing — and a flash that refuses a module it cannot positively identify.

  • The raw /metrics exposition, as a scraper sees it

    Metrics, on their own port

    Every family the board exposes, on a listener that serves nothing else — so a scraper never holds the root password.

  • Network interfaces and time

    Network and time

    Interfaces, addresses, and an NTP source you can set — and see whether it is actually synchronised.

  • Settings: hostname, configuration export

    Name it, export it

    Hostname, clock and configuration are controls, not files on a shell — and tpi reaches every one from a terminal.

Why fork it

Upstream is dormant. Its firmware mirror stops at v2.0.5, while its GitHub releases reach v2.1.0 — the same publisher, two catalogues that disagree. Following the documented update path would downgrade a board running anything newer.

That mattered because the board had real problems: a firmware update power-cycled the compute modules, there was no temperature sensor anywhere, the fan ran flat out with nothing to regulate against, and a bad image meant a trip to the rack.

What changed

upstream this fork
Kernel 6.8, not a longterm release 6.12.109 LTS
Buildroot 2024.05.1 (EOL) 2025.02.17 LTS
Bad image recovery power cut health-gated A/B promotion
Firmware update vs modules power-cycles them rails untouched
Board temperature none — no sensor in the device tree read, with its trip points
Fan fixed persisted speed kernel-driven, and it says why
Metrics none a documented catalogue
Scrape endpoint — its own port, which cannot reach /api/bmc
Published checksums none SHA256SUMS per release, verified on download
Serial console serial header on the board per module, in the browser
Firmware sources one, hard-coded configurable; GitHub, HTTP, or SD card
API description a prose page OpenAPI 3.1, served by the board itself
Command line upstream's tpi, unaware of any of this tpi reaches every endpoint above

The full comparison carries the evidence for each row, including the ones where upstream is ahead.

Start here

Read the fault list before you rely on this

The certificate on the board is expired. Anything running locally on the BMC is trusted without a credential, though since v2.14.0 it at least leaves an audit line saying so. Nothing shuts the board down if it overheats — there is no critical trip. And flashing a module on a v2.5 board now refuses rather than guessing, but the port mapping behind that has not been proven against two modules in maskrom.

All of them are written down with their tickets, along with the mDNS responder that killed this board twice in one day before v2.13.0 fixed it. A fork that lists only its improvements is advertising.