The factory firmware¶
What a stock Turing Pi 2 looks like before any of this fork touches it.
Every value and every screenshot on this page came off a second board — board B, still sealed on its shipped firmware — on 2026-09-10. Nothing here is quoted from upstream's documentation; it is what the board itself reported.
The point of recording it is that it stops being observable the moment the board is upgraded. A comparison against a baseline nobody kept is not a comparison.
What it reports about itself¶
| value | |
|---|---|
| Board model | Turing Pi 2 (v2.5.1) — stock's answer, and it is wrong; see below |
Daemon (bmcd) |
2.3.2 |
| BMC UI | 3.3.3 |
| API | 1.1 |
| Buildroot | 2024.05.1 |
| Kernel | 6.8.12 |
tpi |
1.0.6 |
| Built | 2024-09-03, two years before this capture |
| Hostname | turingpi |
Build version v2024.05.1 is not a firmware version
The About tab reports Build version v2024.05.1, which is Buildroot's release, not the firmware's. The install guide mentions this leak; the screenshot above is the board doing it.
Stock names the wrong board revision
The screenshot says v2.5.1. The board is a v2.5.2.
This was only visible because the same board was read twice. Stock
firmware reported v2.5.1; after the upgrade, on the same hardware
minutes later, this fork reported v2.5.2. Hardware settles it: a
v2.5.1 has no PCF8563 real-time clock, and this board's answers a
register read on /dev/rtc1. The chip is fitted, so the board is not a
v2.5.1.
The likely cause is ordinary and worth knowing: stock bmcd 2.3.2 was
built on 2024-09-03, and it appears to report the newest revision it has
heard of rather than admitting an unknown one. A board newer than the
firmware gets silently aged down.
It matters because board revision is what a person checks before believing a compatibility note. If your stock board says v2.5.1, that is a claim about your firmware's vintage as much as your hardware.
The interface, tab by tab¶
Stock firmware serves six tabs. This fork adds a console, a network tab and a settings tab on top of them, so the six below are the common ground.
Login¶
A local username and password, and nothing else. There is no second factor and no identity provider.
Info¶
Storage, one fan slider, the bridge address, and buttons to reboot the BMC or reload the daemon. The MAC on this page has been replaced with the IANA documentation address; everything else is untouched.
Nodes¶
Four power toggles and four restart buttons. All four modules were powered on when this was taken, which is what the toggle position means here.
USB¶
One USB bus, routed to one node at a time. The mode is Host, Device or Flash, with a separate compatibility toggle for node 1's USB-A port. The capture shows Flash mode pointed at node 2, left over from writing that module minutes earlier — the board keeps the last route, it does not return to a default.
Flash Node¶
Write an operating system image to one module's eMMC: a node, a local or remote file, and an optional SHA-256. A Skip CRC checkbox sits beside the install button, so the one integrity check on offer can be turned off at the point of use.
Firmware Upgrade¶
A .tpu file, an optional SHA-256, and an Upgrade button. This is the screen
that installs this fork, and the optional checksum field is the only integrity
check stock firmware offers.
The API underneath¶
Authentication is a POST of a username and password to
/api/bmc/authenticate, which returns a 64-character token used as a bearer
token on every later call. Off-board calls without one are refused with 401.
On the board itself, there is no authentication at all
A request to https://127.0.0.1/api/bmc from the BMC's own shell answers
in full without any credential. Anything that can run code on the
board — or reach that socket — holds the whole API, including node power
and flashing.
This fork inherits the bypass. Since v2.14.0 it at least records one — an unauthenticated call writes an audit line saying so — which makes it findable afterwards, not prevented. What is and isn't fixed carries the detail and the plan to remove it.
Flash layout¶
The NAND is one megabyte of boot plus a 255 MB UBI, divided in three:
| volume | size | holds |
|---|---|---|
uboot-env |
124 KiB | the bootloader environment |
rootfs |
38.1 MiB | the read-only root |
overlay |
151.3 MiB | everything that survives a reboot |
The root is mounted as an overlay: a read-only lower layer with the overlay volume written on top. That is why a file edited on a running board — an authorised key, a password — persists, while the image underneath stays whatever was flashed.
Going back¶
Rolling back to stock means flashing an official image through the same Firmware Upgrade tab pictured above. Turing Pi publishes those by two routes that do not agree with each other; which one to trust, and why neither carries a checksum, is its own page.