Raspberry Pi 5 的 RAM 改裝自 2024-09-23 起遭韌體限制，這代表甚麼

Raspberry Pi enthusiasts have been quietly upgrading the RAM on Pi 5 boards for a while now. The process involved swapping out the LPDDR4X memory package, and for the technically adventurous, it worked. It stopped working two years ago. The restriction is not new: Pi 5 bootloader EEPROM releases dated 2024-09-23 and later refuse to bring up memory that does not match what the board was provisioned with at the factory, and a board with a swapped chip fails SDRAM initialisation and does not boot. What is new is that the behaviour has finally been documented in public. One naming note: this is Raspberry Pi Ltd, the trading company, not the Raspberry Pi Foundation.

Jeff Geerling wrote it up on 21 September 2026, which is why it is being discussed now. His own summary of the timing: "The firmware update that disabled RAM swaps was actually from late 2024, two years ago." Let's break down what the firmware checks, what the changelog does and does not say about it, and what your options actually look like.

💡 Why This Matters

Raspberry Pi lists the Pi 5 in 1 GB, 2 GB, 4 GB, 8 GB and 16 GB variants, all LPDDR4X-4267. For users who wanted more RAM than their board shipped with, unofficial chip swaps were an appealing path. It kept older boards in service and gave power users more headroom for workloads like running local AI models, containers, or memory-intensive self-hosted apps. It was also, according to Raspberry Pi, being abused at the other end of the market: the company's position is that resellers were buying cheap low-RAM boards, soldering larger chips of unknown provenance onto them, and selling them as factory 8 GB units.

Firmware-level lockdowns change that calculus entirely. When the bootloader refuses to initialise memory that does not match the board's factory provisioning, the board does not boot at all. The reported symptom is the green ACT LED flashing eight times in a repeating pattern, which is the SDRAM failure code. This is not a soft restriction you can work around with a config file tweak.

🔧 What the Firmware Actually Does

Modern SBCs rely on their firmware to train and initialize RAM at boot. The firmware contains timing parameters, voltage settings, and compatibility tables specific to the memory chips the manufacturer has validated. When Raspberry Pi updates that firmware to check against an approved list of memory configurations, any chip not on that list can fail initialization entirely or be flagged and rejected.

The practical result is that a board that previously booted fine after a RAM swap stops booting. The restriction lives below the OS, so there is no Linux-side fix. One important caveat on sourcing: the rpi-eeprom changelog entry for 2024-09-23 says only "SDRAM performance tuning", "Allow BANKLOW to be configured by SDRAM_BANKLOW parameter" and "Manufacturing test updates". It never mentions a memory check, so the changelog will not tell you this happened. The clearest primary evidence is rpi-eeprom issue 761, filed 15 October 2025 by a user whose Pi 5, sold as 8 GB, failed to boot on every EEPROM release from 2024-09-23 onward and booted fine on 2024-09-10. Raspberry Pi engineers asked for vcgencmd otp_dump, concluded from the OTP provisioning that the board had been modified after manufacture, and said such a board "won't cope with any changes in firmware / otp provisioning and is stuck on a pre-2712D0 firmware release with old/test SDRAM code." A Raspberry Pi engineer has also stated the policy directly on the company forums, in this thread.

🤔 Why Would Raspberry Pi Do This?

There are a few plausible reasons, and they are not mutually exclusive.

Stability and support: Unofficial RAM swaps can cause hard-to-diagnose instability. Restricting unsupported configurations reduces support burden.
Supply chain and binning: Memory chips are binned and validated for specific performance envelopes. A chip that works in one context may not meet the timing tolerances Raspberry Pi has tested against.
Revenue protection: Selling higher-RAM SKUs is a meaningful part of the business model. Unofficial upgrades cut into that, particularly now that the Pi 5 is widely available.
Per-part memory tuning: The rpi-eeprom changelog is full of entries adding timings for specific memory configurations, including "Improved SDRAM refresh timings for Pi5 16GB" and a Broadcom SDRAM firmware bump "to support additional memory variants." The bootloader has to know which part is actually fitted. That also explains the part people find hardest to accept: a same-capacity chip pulled from another Pi 5 can still be rejected, because the check is not only about size. This has nothing to do with RP1, the Pi 5's I/O controller, which does not sit on the memory interface at all.

None of these reasons are inherently sinister, but the combined effect is a more closed platform than many in the community expected from Raspberry Pi.

🛡️ What This Means for Your Homelab

If you are running a Pi 5 with an unofficial RAM upgrade and it is working today, the immediate risk is a firmware update breaking your setup. Here is how to think about it.

If your swapped board works today, you are already running old firmware. The only bootloader releases that tolerate a swapped chip are 2024-09-10 and earlier, so a board still running a RAM mod is two years behind on bootloader fixes. There is no release channel that keeps you both current and modded. The real choice is old firmware or a factory memory configuration, and it is worth knowing which one you have picked.

To check your current EEPROM version and what update is staged:

sudo rpi-eeprom-update

The release channel is not set with rpi-eeprom-config. That command edits the bootloader's own configuration, things like BOOT_ORDER. The channel is the FIRMWARE_RELEASE_STATUS variable in /etc/default/rpi-eeprom-update:

sudo nano /etc/default/rpi-eeprom-update

In the current rpi-eeprom package that variable defaults to default, and latest is the other channel; the older critical, stable and beta names are historical and no longer what the tooling uses. The same file also holds RPI_EEPROM_ALLOW_DOWNGRADE and STRICT_MIN_VER_CHECK, which matter if you ever need to go backwards. Checked against the rpi-eeprom repository on 29 September 2026.

Going backwards is getting harder. The 2026-09-23 bootloader release added a manufacture-version check: "If the MFG version of the image to update is less than MFG version in OTP then recovery.bin and self update will both fail to write the eeprom update", with bootloader_allow_mfg_downgrade=1 in config.txt as the documented bypass. On newer boards whose minimum version is burned into OTP, rolling all the way back to a 2024 bootloader is no longer a simple reflash. That change landed six days before this post went up, so treat it as current rather than settled.

Consider your upgrade path instead. If you need more RAM for your workload, the official 16 GB Pi 5 is a real option. It costs more than a DIY swap, but it comes with full firmware support and no risk of a future update refusing to initialise your memory.

🧰 Alternatives If You Need More Headroom

If the Pi 5 RAM ceiling is genuinely limiting your homelab, here are paths that do not depend on unofficial hardware modifications.

Raspberry Pi 5 16 GB: The official high-RAM option. Full firmware support, no risk from future updates.
Swap space on fast storage: Not a substitute for real RAM, but an NVMe-backed swap partition on a Pi 5 with an M.2 HAT can extend effective memory for workloads that tolerate it. Add a swap file on your NVMe mount point rather than the SD card.
Move the workload: For memory-intensive tasks like running local LLMs, a small x86 mini PC or a used workstation server often makes more sense than pushing a Pi to its limits.
Orange Pi, Rock Pi, or other SBCs: The broader ARM SBC ecosystem has boards with more RAM and less restrictive firmware policies. They come with their own trade-offs around community support and software compatibility.

🔍 The Bigger Picture

This situation highlights a tension that has been building in the SBC space. As these boards become more capable and more commercially successful, the platforms inevitably become more controlled. The original Pi was almost impossibly open at the hardware level. The Pi 5 is a far more sophisticated piece of hardware, and sophistication tends to come with tighter firmware control.

That does not make the Pi 5 a bad board. It is still one of the most capable and well-supported SBCs you can buy. But it does mean that the "buy a cheap board and hack it into something bigger" model has real limits now. Plan your Pi 5 deployments around the official RAM tiers, and treat any unofficial hardware modification as something that may stop working after a firmware update.

✅ Wrap Up

Raspberry Pi's firmware-level RAM lockdown on the Pi 5 closed the door on a useful, if unofficial, upgrade path, and it did so in September 2024. If you have a working unofficial RAM swap today, you are on a two-year-old bootloader and any update will end that. If you are planning a new Pi 5 build that needs more than 8 GB, buy the 16 GB model and skip the uncertainty entirely.

Jeff Geerling's 21 September 2026 post is the place to start on the community side. For the primary material, rpi-eeprom issue 761 is where Raspberry Pi engineers describe the check themselves, and the Pi 5 bootloader release notes are worth watching for future changes, with the caveat that this particular behaviour never appeared in them.

Related from the lab

Originally published at codewithromi.com.