Raspberry Pi Now Boots Only Factory RAM, and the Release Note Did Not Mention It

By Indie Kings | September 26, 2026

Updated September 26, 2026: Raspberry Pi boards now refuse to boot when the installed memory does not match what the factory recorded, and the check is enforced from the bootloader against one-time programmable memory in the SoC. The lock arrived in the 2024-09-23 firmware build, under a release note that described it only as minor updates to align with manufacture test. That is roughly two years before the current memory price surge, so this is not a response to RAM being expensive. It is a response to resellers fitting higher capacity chips of dubious origin and selling the boards as factory units.

Verification note: The engineering detail and the boot error quoted below come from Its FOSS's account by Sourav Rudra, published September 22, 2026, which cites the Raspberry Pi forum directly. Raspberry Pi's stated position and the fraud rationale come from TechPowerUp's report by DrUsmanSaleem, also September 22, 2026, citing the forums via Tom's Hardware. Two Raspberry Pi engineers are quoted by name in that material: PhilE and Tim Grovers. Two timing points matter and we have kept them straight. The firmware build that introduced the behaviour is dated 2024-09-23, which is a community identification rather than an official admission. And the forum thread that produced the current coverage is from late June 2026, so the news is the disclosure and the reporting, not a recent change.

Raspberry Pi single board computer with memory chips visible on the board

Image: Raspberry Pi board. Credit: TechPowerUp.

What actually changed

The behaviour is narrower and more absolute than most coverage of this has described, so it is worth being precise about the mechanism.

When a Raspberry Pi 5 boots on firmware at or beyond the 2024-09-23 build, the bootloader reads the installed memory and compares it against a configuration stored in the SoC's one-time programmable memory. That is a field that can be written once at manufacture and cannot be rewritten afterwards, which is what makes the stored value trustworthy as a factory record.

If the comparison fails, the board stops. The user facing error is boot code 9, listed as an SDRAM mismatch, and the console output looks like this:

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'

Two features of that check matter more than the capacity comparison itself, and both are easy to miss.

It is not a capacity check. Even memory of the same size taken from another Raspberry Pi 5 board can trigger the error, because the firmware compares additional device attributes recorded in OTP, not just the gigabit figure. So a donor board's memory is not a workaround.

It is enforced at every boot, by the bootloader. This is not a setting in an operating system that can be changed, and it is not a check in a vendor tool. It sits below the operating system, and there is no configuration file that disables it.

And it arrived quietly. The release note attached to the 2024-09-23 build described the change as minor updates to align with manufacture test, with no mention of locking out unapproved memory. That is the detail that turned a sensible anti fraud measure into a grievance, because nobody reading release notes would have signed up for this.

Why: a fraud pattern with a paper trail

The stated justification is specific, and it is not a vague anti-tampering story.

The pattern Raspberry Pi describes is that a reseller buys boards with cheaper, lower capacity memory, fits higher capacity chips sourced from a third party, and resells the result as a factory unit of the larger size. The chips are described in the company account as being of dubious origin. Critically, those boards were never tested by Raspberry Pi, so when a buyer's machine started misbehaving, the support request landed on Raspberry Pi rather than on the party that sold the modified hardware.

There is a documented case, and it is the strongest evidence in the whole thread. A user bought a board sold to them as a legitimate 8GB Raspberry Pi 5. It worked normally at first, then stopped booting after a routine firmware update. Memory testing on the older firmware reported no errors at all, which pointed to the board having been altered before it reached the buyer. One of the Raspberry Pi engineers, Tim Grovers, reviewed the OTP memory dump the reporter had shared and confirmed the board had been modified by the seller.

That case is worth sitting with, because it cuts both ways in a way the coverage has not always made clear. The user was a victim of fraud. The firmware update that stopped their board working was the same firmware update that made the tampering detectable. Detection and breakage arrived as the same event.

The part that is not about fraud at all

Here is where a reasonable anti fraud measure stops being one.

In June 2026, a tinkerer attempted an upgrade on a Compute Module 5, taking it from 2GB to 4GB, and posted the problems they hit on the official Raspberry Pi forum. After back and forth with two engineers from the company, the position that came back was that swaps between different memory capacities are intentionally blocked.

That is the intended behaviour and it is not disputed. What is disputed is the collateral. The check also blocks the cases nobody was trying to commit fraud in.

Repair with an identical part. Grovers noted that swapping an identical part-code chip is still possible for someone sufficiently skilled, which is a genuinely narrow escape route. It requires sourcing the exact same part number.
But the SKU count is growing. The same comment notes that the number of memory SKUs Raspberry Pi now supports means timing and configuration parameters vary per device. As the range widens, the population of boards where an identical part-code replacement is realistic keeps shrinking.

So the repair path exists, it is technical rather than practical, and it narrows over time as product variety increases. That is the trade the company has made, stated plainly by the people who made it.

The timing, which is the part people misread

This is the point most coverage has attached in the wrong direction, and getting it right changes how the story reads.

The firmware build is dated 2024-09-23. The current memory price surge is a 2026 phenomenon, and the arithmetic on desktop DDR5 over the past twelve months is in the region of a 500 percent climb. The lock predates the surge by roughly two years.

So the lock was not a response to RAM becoming expensive, and it was not a response to the supply crunch that has since driven laptop prices up and made memory modules unaffordable in their own right. It was a response to a fraud pattern that existed independently of any of that, and the company says so.

That distinction is worth holding, because it removes the most cynical reading of the decision. Raspberry Pi did not lock the RAM of the most repairable mainstream board to extract margin from a price spike. It locked the RAM to stop sellers passing off modified hardware as factory products, and it did so before there was a price spike to respond to.

It also means the current memory economics are not an excuse available to the company, which cuts the other way. The mechanism chosen was not adjusted once the surge arrived, and two years on it remains the enforcement.

Using software to close hardware

The critique, stated fairly, is about mechanism rather than motive, and Its FOSS puts it plainly: a bootloader that cross-references OTP at every boot to enforce a factory set RAM configuration is a software mechanism being used to close the hardware.

The context that makes it land is how unusual Raspberry Pi's position is. It is not an open hardware project in the strict sense, the way a Pine64 or a Framework board with published schematics is. But it built a great deal of community goodwill on the idea that the board belonged to whoever was holding it. People ran custom operating systems, stripped the hardware down, pushed it past its documented limits, and occasionally pulled it apart to the silicon level. That culture of ownership is a real part of why the platform is where it is.

Against that, the fraud problem is real, the company's frustration is understandable, and untested boards reaching customers and then generating support load is a genuine problem with a genuine cost. None of that is in dispute here.

What is in dispute is whether a per boot OTP comparison was the right instrument. A bootloader check is cheap to add and impossible for a buyer to work around, which is exactly why it is effective against the fraud it targets, and exactly why it is felt as a door closing by the people who did nothing wrong. Defending the right to reject modified hardware while staying open enough for tinkerers to experiment are two goals that this mechanism satisfies only one of.

The reaction in the thread is largely what you would expect, and it is worth not softening it. The recurring complaint is that the premise of the platform was that it was hackable, and the recurring follow-up question is what gets locked next.

What it means if you are buying one now

Two practical consequences, neither of which needs an opinion on the ethics.

Verify the seller before you buy, not after. A board with substituted memory is now detectable by the firmware itself, and the detection looks identical to a genuine hardware fault. The documented 8GB case ran memory tests clean on the old firmware and still turned out to be modified, which means consumer level testing will not find this. Buy from a source you would trust with the rest of your hardware, and treat an SDRAM mismatch on a board that worked yesterday as a signal to check provenance rather than to start re-soldering.

If you repair rather than resell, check the firmware date first. A board that was fine before an update and dead after one may not be broken at all. It may be a board whose memory was changed at some point in its life, and the update is the first thing that noticed.

Neither of those is a workaround. Both are the consequence of the check being exactly as effective as advertised.

FAQ

What exactly is locked on the Raspberry Pi 5?
The installed memory is compared at boot against a configuration stored in the SoC's one-time programmable memory. A mismatch raises boot code 9, an SDRAM mismatch, and the board refuses to continue. The check is enforced by the bootloader on every boot, not by the operating system, and it cannot be disabled by configuration.

Can I still upgrade the RAM myself?
Not to a different capacity. The company's stated position, given on the official forum after a Compute Module 5 owner tried going from 2GB to 4GB in June 2026, is that swaps between different capacities are intentionally blocked. The narrow exception is replacing a chip with an identical part code, which engineer Tim Grovers described as possible for someone sufficiently skilled.

Does a same size stick from another board work?
Not reliably. The firmware compares additional device attributes recorded in OTP beyond the capacity figure, so an identically sized module from another board can still trigger the error. As Raspberry Pi supports more memory SKUs, timing and configuration parameters vary per device, which makes an exact part-code match progressively harder to arrange.

Why did Raspberry Pi do this?
To address a fraud pattern where resellers fitted higher capacity chips of dubious origin to lower capacity boards and sold them as factory units. Because those boards were never tested by Raspberry Pi, failures generated support requests that landed on the company. One engineer confirmed a reported 8GB board had been modified by the seller after reviewing the OTP memory dump the buyer shared.

Is this a reaction to RAM prices going up?
No. The community identifies the firmware build that introduced the check as 2024-09-23, which is roughly two years before the current memory price surge. The lock responds to reseller fraud, a problem that existed independently of memory pricing, and the company does not present it as a pricing measure.

Was the change announced?
Effectively no. The release note for the 2024-09-23 build described the change as minor updates to align with manufacture test, without mentioning that unapproved memory would stop working. The current coverage stems from a forum thread in late June 2026, so what is new is the disclosure and the discussion rather than the behaviour itself.

Bottom Line

This is a small piece of firmware doing something quite large, and it is worth understanding precisely rather than as a story about either greed or principle. The mechanism is a per boot comparison against one-time programmable memory in the SoC, which raises boot code 9 and stops the board dead. It is not a capacity check, so an identically sized module from a donor board will not rescue it, and it sits in the bootloader rather than the operating system, so there is nothing to configure. The fraud it targets is real and documented: a buyer who thought they had an 8GB board was sold one with substituted memory, memory tests came back clean on the older firmware, and a Raspberry Pi engineer confirmed the modification from the OTP dump. The detail that reframes the whole story is the date. The build is identified as 2024-09-23, about two years before the memory price surge, and the release note described it only as minor updates to align with manufacture test. So this is not a company closing its most repairable board to profit from a price spike. It is a company that identified a resale fraud, responded to it, and did so years before the shortage that would have given everyone an obvious motive. That removes the cynical reading and it also removes the excuse, because the mechanism was never revisited once the surge arrived. What remains is the honest disagreement its own engineer articulated: swapping an identical part code is still possible for someone sufficiently skilled, but the number of memory SKUs the company supports is growing, so timing and configuration parameters now vary per device and that repair route narrows over time. A bootloader check against OTP is a software mechanism being used to close hardware, on a platform whose goodwill was built on the idea that the board belonged to whoever held it, and it is exactly as effective against the tinkerer repairing a dead board as it is against the reseller passing off a modified one. Neither side of that is unreasonable. The fraud was a real cost carried by the wrong party, and the fix is a door closing in both directions at once.

Sources: Its FOSS, Raspberry Pi disallows RAM upgrades to fight fraud, does it make sense? by Sourav Rudra, September 22, 2026 | TechPowerUp, Raspberry Pi confirms boards are locked to factory RAM size via firmware by DrUsmanSaleem, September 22, 2026, citing Raspberry Pi forums via Tom's Hardware