Upgrading from stock firmware

What changes on your board, what it costs, and how to go back.

Every timing and every screenshot on this page came from doing it once, on a board that shipped with stock firmware, on 2026-09-10. Where something was not measured, it says so.

Read Installing on your own board first for the warnings. This page is the transition itself.

What you have, and what you get

Stock

Six tabs. bmcd 2.3.2, BMC UI 3.3.3, Buildroot 2024.05.1, kernel 6.8.12, built 2024-09-03.

This fork

Seven tabs — a console, a network tab and a settings tab that stock does not have. This capture is firmware v2.20.0: bmcd 2.29.0, BMC UI 3.19.0, Buildroot 2025.02.17, kernel 6.12.109 LTS. The daemon and the interface have moved on since — the changelog is the live answer — but the tabs and the kernel are what this page is about. Since BMC-UI 4.0.0 the tabs are a sidebar and the pages have new names; the capture shows the interface as it was then.

The full stock interface, tab by tab, is its own page, captured before this board was upgraded.

Doing it

Download the .tpu and its checksum from the releases page. Verify it before it goes near the board:

$ sha256sum -c tp2-bmc-firmware-ota-v2.24.0.tpu.sha256

Then either route below. Both stage the image and neither applies it until the board reboots.

Through the interface

Stock's Firmware Upgrade tab takes the file and, optionally, the checksum. Put the checksum in. It is the only integrity check stock offers, and the field is optional in a place where it should not be.

From the command line

Stock has no tpi-selfupdate — that ships with this fork — but it does have tpi firmware:

$ scp tp2-bmc-firmware-ota-v2.24.0.tpu root@BMC:/mnt/sdcard/
$ ssh root@BMC 'tpi firmware --file /mnt/sdcard/tp2-bmc-firmware-ota-v2.24.0.tpu \
    --sha256 008beb0006b2179e2184043f0a8db86c26638bfacf75d65953f5fdecbdcf9717'
started transfer of 36.12 MiB..
Done

Done does not mean upgraded

It means staged. The board keeps running the old firmware, its uptime does not reset, and nothing appears in dmesg. It looks exactly like a failed upgrade, and on the first run here it was mistaken for one for ten minutes.

What actually happened is visible in the flash layout: a new UBI volume rootfs_new appears beside rootfs, and u-boot's boot target begins with nextboot. The image is written and armed.

$ ssh root@BMC reboot

What it costs

Measured on the run described above:

Transfer of 36.12 MiB	26.6 s
Install from a source on the Firmware page, until it says staged	26 s
Reboot, until the board answers again	48 s
Compute modules disturbed	none

The install row is the daemon downloading the image from the source, checking its sum, writing it to the spare slot and arming the next boot, all inside one request; from v2.38.0 the page shows that count while it runs, the way it shows the reboot's. Nothing is armed until it says staged, so refreshing the page mid-install changes nothing.

That last row deserves a caveat rather than a promise. The board's network switch is driven by the BMC, so a BMC reboot is expected to interrupt the modules' links. On this run the reboot was quick enough that four modules — running Kubernetes, one of them a control-plane node — were never marked unhealthy, and a public service in front of them answered every probe throughout. A slower board, or a busier cluster, may not be so lucky. Do not plan on zero disruption; plan on a minute of it and be pleased.

Going back

After the upgrade the flash holds rootfs and rootfs_prev, and rootfs_prev is the stock image your board shipped with. Returning to stock is a boot away, not a re-flash.

That is true for exactly one upgrade

The next upgrade overwrites rootfs_prev with the version you are leaving. After it, the rollback slot holds this fork's previous release, and getting back to stock means flashing a stock .tpu again.

For the longer route, stock's own releases are already a configured source in this fork's Firmware Upgrade page, listed under show older or unrelated versions. How Turing Pi publishes those, and why neither of their two routes carries a checksum, is its own page.

What the upgrade does not change

Your root password and your authorised keys survive: they live on the overlay volume, which the upgrade does not touch. The hostname survives for the same reason.

With one consequence worth knowing about. If your board is still on the password it shipped with — root / turing — that survives too, and this firmware will not run on it until you change it: the interface shows one page asking for a new password, and the API refuses everything else. It is the published password on every board ever sold, so a board keeping it is a board anyone who can reach it can administer. Twelve characters, once, and the rest of the interface opens.

If you changed it at any point, you will not be asked. Node power states are read from the hardware on start rather than re-applied from a stale file, so modules are not power-cycled to suit the daemon's memory of them.