# Raspberry Pi EEPROM updates will soon have an A/B feature **URL:** \ **Category:** Pi News\ **Created:** [February 17, 2026, 9:15pm UTC](https://community.info-beamer.com/t/raspberry-pi-eeprom-updates-will-soon-have-an-a-b-feature/1383 "2026-02-17T21:15:19Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![infobeamer-fw](https://community.info-beamer.com/user_avatar/community.info-beamer.com/infobeamer-fw/32/3_2.png) [@infobeamer-fw](https://community.info-beamer.com/u/infobeamer-fw)\ **Post date:** [February 17, 2026, 9:15pm UTC](https://community.info-beamer.com/t/raspberry-pi-eeprom-updates-will-soon-have-an-a-b-feature/1383/1 "2026-02-17T21:15:19Z")
Quick technical post because it doesn’t happen that often that I’m that excited for a new feature available in the Pis firmware code (last time was the HTTP boot method 🙂 ). It will soon be possible to update the firmware, stored in an EEPROM chip on a Pi5, in a fail-safe way. Announcement post [can be found here](https://forums.raspberrypi.com/viewtopic.php?p=2364222). Previously those updates could be a bit risky as a sudden power loss might render a device unbootable. This can be repaired quite easily but required manual work on the device itself. The Pi5 EEPROM has 2MB of on-device storage (up from 512KB on the Pi4). This is now split into three relevant parts: A 64KB readonly section storing the (I assume) static code that switches between version. Followed by two 988KB sized sections logically named A or B. The code in the readonly section decides which of those it should boot. Assuming the device booted using version A, the section B is unused. Using a [new rpi-eeprom-ab tool](https://github.com/raspberrypi/utils/tree/master/rpieepromab) that communicates with the Pi’s firmware over mailbox calls, a new version of the EEPROM can be flashed to B. Once that’s done, a [reboot with the tryboot flag](https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#fail-safe-os-updates-tryboot), should, from what I understand, cause the EEPROM to use the new code in section B. Importantly: Should this reboot fail for any reason, a watchdog can automatically reboot the Pi after a set duration. Such a reboot will clear the tryboot flag and the previously used version in A will be active again. Effectively such a failure will roll back the system to a previously known working state. Assuming the reboot worked properly, the running operating system can again use rpi-eeprom-ab to commit the now known good version in B. Any followup reboot will now automatically use B and the next update can repeat the same process with A/B reversed. The layout in the EEPROM’s binary files (those [available here](https://github.com/raspberrypi/rpi-eeprom/tree/ab/firmware-2712/latest)) has slightly changed as certain offsets within that file now carry special meaning. But I’ve already updated the eeprom.py tool info-beamer OS uses and it should support reading and modifying EEPROM images. You can find the updated source at [GitHub - info-beamer/rpi-eeprom-tools: Tools for working with the Pi4/Pi5 EEPROM firmware files](https://github.com/info-beamer/rpi-eeprom-tools). Once this feature is officially released, the EEPROM update process in info-beamer will very likely use those features. It’s still unclear (although I feel unlikely) if this method will also be available for the Pi4.