Something that flew under the radar a while back is getting attention again. A post on the r/selfhosted subreddit reminds us that the Raspberry Pi 5 will refuse to boot if it detects RAM that doesn’t match the memory configuration recorded at the factory.
The behavior traces to a firmware update that many in the community have identified as the 2024-09-23 build, which went out with a very dry release note that said:
Interesting changes since the last release:-
Minor updates for to align with manufacture test.
You can see the lack of a point about locking out unapproved memory here.
What it does, and why
2.41 Expected configuration 8 Gbit (0x07)
2.44 Actual configuration 32 Gbit (0x05)
2.48 USB-OTG disconnect
2.51 BOOT ERROR: code 9 - 'SDRAM mismatch'The error faced by Glad-Independence893.
When a Pi 5 boots with the firmware at or beyond the threshold (basically 2024-09-23 or later), it checks the installed RAM against a configuration stored in the SoC’s OTP memory.
A mismatch throws “code 9,” listed as an “SDRAM mismatch,” and the board refuses to go further. It isn’t just a capacity check either. Even RAM of the same size from another Pi 5 board can trigger the error if it doesn’t match other device attributes recorded in OTP.
A few months ago in June, another tinkerer had done something similar, trying to upgrade the RAM on their CM5 from 2GB to 4GB, posting the issues he faced on the official Raspberry Pi forum.
After some back and forth that included the issue poster and two engineers from the Raspberry Pi team, the company’s stand was that swaps between different RAM capacities are intentionally blocked.
Same-size swaps from another board aren’t guaranteed to work either, since the firmware records additional device attributes beyond just the capacity figure.
One of the engineers, Tim Grovers (timg236), noted that swapping an identical part-code chip for repair is still possible for someone sufficiently skilled, but the growing number of RAM SKUs the Raspberry Pi now supports means timing and configuration parameters will vary per device.
Who it’s meant to catch
Simply speaking, this is meant to tackle hardware-associated fraud scenarios where a low-capacity board gets cheap, untested RAM from a third-party source soldered in, then gets resold as a higher-capacity model.
This has been a long-standing problem; you can see for yourself in an issue from last year when a user purchased what was sold as a legitimate 8GB Pi 5. It worked fine initially but stopped booting after a routine firmware update.
Running memtest on the older firmware showed no errors, which led to the suspicion that the board had been modified before sale. Back then, Tim had reviewed the OTP dump shared by the reporter and confirmed that the board was modified by the seller.
Does it make sense?
The fraud problem is real, and Raspberry Pi’s frustration is understandable. Boards with unvalidated RAM making their way to customers and then leading to support requests is a serious problem.
But the mechanism chosen to tackle this affects more than the fraudsters.
Raspberry Pi has long occupied an unusual position in the hardware world. It isn’t an open hardware project in the strictest sense, but it built much of its community goodwill on the idea that the board belonged to whoever was holding it.
People ran custom operating systems, stripped it down, pushed it past its limits, and occasionally pulled it apart down to the silicon. That culture of ownership was part of what made the platform what it is today.
A bootloader that cross-references OTP at every boot to enforce factory-set RAM configuration is a software mechanism being used to close the hardware. I understand that Raspberry Pi is well within its rights to make this call.
But defending those rights while still being open enough for tinkerers to experiment is something they could have stood behind. People looking to buy a new Pi should also shoulder some responsibility here; you should always verify the seller and storefront before buying.
If you’re affected by this, the workaround is to stay on a firmware version older than the 2024-09-23 build, then disable the automatic EEPROM update service so the board doesn’t pull a newer version on its own.
