The Raspberry Pi 5’s bootloader checks the memory it finds against the memory it expects, and stops if the two disagree. On a board that fails the check nothing on the card or the SSD can help, because the halt happens before an operating system is loaded.
What it looks like
Issue #861 in the rpi-eeprom tracker has the whole thing. A Pi 5 on board revision b04171, booting fine on EEPROM 2024-09-10. Update it to 2026-05-11 and the board stops booting: the UART output reads “BOOT ERROR: code 9 - SDRAM mismatch”, expected configuration 16 Gbit against actual configuration 32 Gbit, and the ACT LED reports the failure. It fails the same way with the NVMe drive removed, and before Home Assistant starts.
Flashing 2024-09-10 back with the official EEPROM recovery image brings the board up every time. The reporter has recovered it several times, so it reproduces on demand.
The tracker’s answer
The report was closed as a duplicate of #750, titled “Pi 5 Bootloader shows Raspberry Pi 5 - 2GB on an 8 GB board (rev b04170)”. Same board revisions and the same memory detection, with a less deadly symptom: the bootloader misreads the RAM and boots anyway.
The reply on #750 was to carry on using the board if it works, and to contact the seller for a refund if the hardware turns out to be unreliable. It was closed as can’t reproduce. A comment in July asks for a config option to bypass the RAM size check, so that people who upgrade the memory chips can take the risk themselves. No such option exists.
The version that breaks is still the current one. v2026.05.11-2712 is the newest Pi 5 release in the repository. The later 2026.05.17 build carries the 2711 tag, which is the bootloader for the Pi 4 and Zero 2 W.
Why the check is there
The refusal is deliberate, and the reason is a resale problem. Boards built as 1 GB or 2 GB models have been reworked with cheap 8 GB memory and sold as new 8 GB Pi 5s. Issue #761 is one of those arriving in someone’s hands: it booted on 2024-09-10, then stopped with eight flashes of the ACT LED on 2024-09-23 and later. The board’s OTP dump is what settled it, and the reply was that whoever sold the board could have modified it, that it was not going to work, and that they should refund it. Raspberry Pi’s argument is that reworked memory never went through the official test process, can fail intermittently, and cannot cope with changes to firmware or provisioning.
Jeff Geerling wrote the same story up today, and he agrees with the reason rather than the method. He would rather see a one-time warranty bit, like the flag older Pis set when you overclocked past the limits, than have owners locked out of hardware they own.
My read
If the memory chips have been swapped for larger ones, the firmware treats that as a fault and refuses to start, and the only way back is a recovery image and a downgrade. Anyone with a modified Pi 5 should pin the EEPROM version before updating, and should not assume the next release fixes it. Anyone whose board failed this way without being knowingly modified should treat it as a counterfeit and go back to the seller.
Sources: issues #861 and #761 in the rpi-eeprom tracker, and Jeff Geerling on the Pi 5’s RAM lockdown