Raspberry Pi locks Pi 5 RAM in firmware to stop fraudulent resellers
On 21 September 2026, Jeff Geerling documented a firmware lock, introduced in late 2024, that prevents swapping the RAM chips on a Raspberry Pi 5. The move targets resellers who modify entry-level boards, but it also removes the right to repair and upgrade your hardware.
21 September 2026. Jeff Geerling publishes his analysis of the Pi 5 RAM lockdown. Late 2024. Raspberry Pi quietly shipped a firmware mechanism that blocks swapping RAM chips — sometimes even chips of the same capacity. 22 September 2026. Hackaday picks up the story and the Hacker News thread confirms the community has not forgotten the board’s founding promise. Why it matters: the move targets resellers who modify entry-level Pi 5 boards, but it also shuts the door on repairing or upgrading your hardware — with no way out except downgrading to 2024 firmware.
The scam the measure aims to kill
The mechanism Geerling describes is easy to follow. Vendors buy cheap 1 or 2 GB Pi 5 boards, desolder the original chips, solder in cheap — sometimes unreliable — 8 GB chips, and sell the result as brand-new 8 GB Pi 5s.
The incentive is financial. In the current AI bubble, RAM is expensive, and the price gap between a 2 GB and an 8 GB Pi 5 makes the operation profitable. Geerling does not dispute the legitimacy of the problem: dubious RAM and unscrupulous resellers produce boards with unpredictable failures, which Raspberry Pi ends up supporting anyway. The vendor finds itself handling customers of shops it never chose.
A silent lock, shipped two years ago
The detail that stings is the timing. The firmware update that disabled RAM swaps dates from late 2024 — two years before Geerling’s reveal. You cannot pin it on the recent RAM price spike or an urgency born of the AI bubble: the lock was in place long before.
The issue, Geerling stresses, is not legality. Raspberry Pi is within its rights to lock down its hardware however it likes. The issue is that there is no simple workaround, other than running ancient firmware — 2024-09-10-2712 or older — on the board. That is an absurd entry cost for anyone who simply wants to repair a board whose chip failed, or take a Pi 5 to more memory.
# The EEPROM bootloader version currently flashed
sudo rpi-eeprom-update
# Memory actually detected by the kernel
grep MemTotal /proc/meminfoThe technical point Raspberry Pi has
Geerling is candid: on the merits, Raspberry Pi has a case. Memory timings for modern LPDDR chips are tricky to get right. A bad solder joint, or a cheap chip that only barely passed validation, produces erratic failure modes — crashes neither the user nor support can diagnose. Heat and overclocking make it far worse when the configuration has not been tested and tuned at the factory.
So it is worth separating two things the community’s anger tends to conflate. The first is the technical argument, which Geerling finds reasonable, probably even on legal grounds. The second is the platform’s ethos. The Pi was built on the idea that you could tinker with it — and not being able to tinker down to the chip level is, in his words, “a big miss”. Very few people actually desolder a RAM chip; what matters is the idea that you could if you wanted to. For a homelab running the same board 24/7, the loss cuts deeper still, because it hits the repairability of hardware that is supposed to last for years.
The only way out, and what it costs
The current situation has no satisfying exit. Downgrading to 2024 firmware means giving up two years of fixes — security included — to recover a freedom to tinker. And there is no physical way to identify, at a glance, a Pi 5 whose RAM has been swapped, which makes life harder for second-hand buyers.
For self-hosters specifically, the two-year firmware freeze is the real cost. A Pi 5 that runs a NAS, a Home Assistant install or a media server sits on a network and needs every security fix it can get; pinning it to a 2024 bootloader to recover the right to swap chips is a trade very few people will actually make. The lock is therefore not a neutral limitation — it is, in practice, a ban for anyone who is not prepared to run unsupported firmware.
There is, however, a software path, which Geerling recalls by citing a Geekworm post: Raspberry Pi publishes the model codes for its boards, so you can verify how much RAM a given model is supposed to have. Someone on Hacker News even suggested that Raspberry Pi drill a hole for the factory-set RAM size instead of locking the firmware — harder to industrialise, but a route that would not shut users out.
What Geerling proposes: the warranty bit
Geerling puts forward an alternative that Raspberry Pi has used before. Up to the Pi 3 B, the board had a “warranty bit”: a firmware flag flipped from 0 to 1 if you deliberately bypassed the safety limits — for example, overclocking past what the vendor judged safe.
He suggests applying the same logic to RAM: instead of banning the swap, set a one-time firmware flag that says “I give up warranty support”, then let the user solder whatever chip they choose and own the consequences. That is exactly the compromise the right-to-repair community has defended for years: the freedom to open, against responsibility for what you do inside — not an outright ban. The proposal is not a fringe demand; it is a mechanism Raspberry Pi itself shipped for years, which makes the current hard lock feel like a step backwards rather than a necessary safeguard.
Verdict
If you buy a second-hand Pi 5, check the RAM expected for the model against the codes Raspberry Pi publishes, and be wary of deals that look too good on 8 GB models — that is where the scam thrives. If you were planning to repair or upgrade a Pi 5 by swapping chips, know the official path has been closed since late 2024 and the only way out — old firmware — costs you two years of fixes. If hardware tinkering is part of why you self-host, keep following this story: the warranty-bit proposal is the most promising ground, and it is user pressure that might eventually push Raspberry Pi to soften its stance. The lock is not a technical inevitability — it is a governance choice, and governance choices can be reversed. For everyone else, it is a reminder that the hardware you own can still be governed by firmware you do not control.