When the Bootloader Says No: Raspberry Pi, DIY RAM, and a Fight Over Who Owns the Board

Raspberry Pi built its reputation on a simple promise: buy a board, open it, break it, fix it, and learn something. That is why classrooms, labs, and weekend workbenches still reach for a Pi.

So it landed hard when the community found that a Raspberry Pi 5 and Compute Module 5 firmware change from September 2024 can reject a soldered LPDDR package if it does not match the factory information stored on the board. A skilled rework job that might have been a repair or an upgrade can now stop at BOOT ERROR: code 9 - 'SDRAM mismatch'.

Raspberry Pi's firmware tracker and official forums document the behavior. The fight is over why the check exists, and what it does to repair and experimentation.

What actually changed

The Raspberry Pi 5 bootloader dated 2024-09-23 added SDRAM performance tuning and manufacturing-test updates. The release notes did not call this a RAM lock. Users who replaced or modified RAM found out the hard way.

At boot, the bootloader can compare the installed SDRAM against factory data burned into the SoC's one-time programmable memory. Capacity is only part of that record. Raspberry Pi engineers have said the factory image also stores other SDRAM details, including density, organization, and timing. A same-capacity chip from another board may still fail the check.

A published failure looks like this:

Expected configuration 8 Gbit (0x07)
Actual configuration 32 Gbit (0x05)
BOOT ERROR: code 9 - 'SDRAM mismatch'

Those hex values are configuration codes, not capacities written in hexadecimal. What matters is the expected configuration versus the one the bootloader found. Code 9 covers SDRAM mismatches in general, so the same message can show up for other SDRAM init failures too.

That September 2024 change sat in the field for almost two years before the community started talking about it again in September 2026. The original notes talked about manufacturing and SDRAM. They did not warn that component-level RAM work could stop the board from booting.

None of this means you can no longer desolder a BGA package. You can. Raspberry Pi engineer Tim Grovers has said a failed package can be replaced with an identical part-code device if the work is done correctly. That is not the same as fitting a different RAM device, even one with the same capacity.

Engineer PhilE has said RAM swaps between boards with different configurations are not expected to work. A capacity change is not supported by the current check.

One workaround is to stay on an older bootloader such as 2024-09-10-2712 and block later EEPROM updates. Some modified boards still boot that way. It is a compatibility hack, not an official upgrade path, and it means you miss later bootloader fixes and hardware support.

Raspberry Pi's case: resold boards, untested parts, and the support queue

Raspberry Pi points to two problems. First, modified boards sold as higher-capacity factory models. Second, support tickets for hardware combinations Raspberry Pi never tested.

On the official forums, PhilE described a familiar scam pattern: buy a cheaper low-capacity board, solder on a higher-capacity chip of unknown origin, and sell it as the official higher-capacity SKU. When that board misbehaves, the complaint often lands on Raspberry Pi, not the seller who did the swap.

If labour is cheap enough then there may be a minor financial gain in buying a part with say a 2GB part, swapping it for an 8GB part of dubious origin, and reselling it as an 8GB device. However, this brings an element of risk to the user. The board hasn't been tested by us, and is a potential support burden for us, with customers complaining of unreliable devices. We therefore remove the commercial incentive by locking devices to their original RAM size. [...]

I don't see RAM being swapped between authorised devices of different sizes as a likely use case, but don't waste your time trying. It won't work.

PhilE, Raspberry Pi engineer, official Raspberry Pi forums (excerpted)

This is not theoretical. Forum reports describe boards where Linux shows more RAM than the factory OTP says the board shipped with. Geekworm published a buyer guide on how to check a Pi 5's factory RAM configuration for that reason.

Linux's current RAM total is not proof of the original factory SKU. The revision code and OTP still describe what the board was built as.

There is also a real electrical problem. Modern LPDDR is picky. Different devices need different timings. A swap can look fine on the bench and then fall over under load if the part was never characterized for that board.

That is not an argument that every replacement chip is junk. It is why Raspberry Pi does not want to support every mix of third-party memory, solder work, and board revision. Their answer was to lock the factory configuration in firmware.

Later EEPROM releases and product-change notices in 2025 and 2026 added timings and newly qualified factory RAM parts. Those updates widen the official parts list. They do not mean the factory-configuration check has been dropped or loosened.

The other side: repair, ownership, and the culture that made Pi matter

The right-to-repair objection is simple. The same check that makes fake upgrades harder also gets in the way of honest component-level repair.

Swapping a BGA memory package is specialist work. Repair techs, labs, and experienced hobbyists are the people who can do it. They may be pulling a good chip off a dead board or keeping hardware out of the scrap bin.

You still own the PCB. You can still change the parts. The bootloader now decides whether that new configuration is allowed to start. That is a different deal from a warning that the modification is unsupported.

Jeff Geerling has said Raspberry Pi can do this and still called it a loss for hardware tinkering. Those are separate points. Whether the policy is lawful depends on the jurisdiction. The community argument is whether a boot-time lock belongs on a platform sold for experimentation.

The official CM5 RAM-upgrade thread was locked after Raspberry Pi engineers explained the policy. A locked thread does not prove motive. It does leave the engineers' own words in the archive.

The Consumer Rights Wiki and other repair advocates put it this way: a board marketed for experimentation can still refuse some component-level changes. That is a policy choice.

A possible middle path already existed

Older Raspberry Pi boards handled some overclock and overvoltage settings with an OTP warranty bit. The board still booted. Raspberry Pi reserved the right to refuse warranty service. The documentation still describes that bit and when it can be set. It also says the warranty bit is never set on Raspberry Pi 4.

That older approach suggests a less blunt option for RAM work:

• Let a repaired or modified board boot.
• Record that the factory configuration changed.
• Make that flag visible in software and to support staff.
• Refuse warranty coverage for failures caused by unsupported hardware changes.
• Keep publishing factory revision data so buyers can check the original SKU.

Raspberry Pi would have to decide whether that is enough to stop fraudulent resellers. A visible mod flag would help buyers and support teams tell factory boards from reworked ones. It would not automatically solve the reliability problem Raspberry Pi is worried about.

What this means if you buy or build with Pi

Buy the factory RAM size you need. Do not plan a 2GB-to-8GB rework to save money. Raspberry Pi engineers have said a different RAM configuration may not pass the current bootloader.

Buy from a legitimate reseller. That lowers the odds of getting a board someone already modified. If you buy from a marketplace or another second-hand source, check the factory configuration yourself.

Check the board you have. Raspberry Pi revision codes encode factory RAM capacity. Published Pi 5 codes cover 1GB, 2GB, 4GB, 8GB, and 16GB. OTP data is another record of the original build.

On a running Raspberry Pi:

cat /proc/cpuinfo | grep Revision

To inspect OTP:

vcgencmd otp_dump

Current firmware also reports physical SDRAM size, in gigabits, here:

cat /proc/device-tree/chosen/rpi-sdram-size-gbit

That node is the size the firmware sees on the package. It is not the factory SKU in the revision code. On a stock board the two usually match. On a modified board that still boots, they can disagree. Revision and OTP still describe the factory build. The device-tree value can follow the chip that is actually fitted.

Linux's current RAM total can disagree with the factory record for the same reason.

Treat old firmware as a last resort. Tracker reports describe modified boards that boot on 2024-09-10 firmware and fail after later updates because of the SDRAM check. Raspberry Pi OS updates the EEPROM by default. If you pin an old bootloader on purpose, you also have to stop automatic updates. Raspberry Pi documents the update service and how to freeze the bootloader version.

A same-part-code repair is not a RAM upgrade. Tim Grovers has said an identical part-code replacement can work. A different device with the same capacity is still subject to the firmware check. Do not sell or treat that board as an untouched factory SKU.

Both problems are real.

Raspberry Pi's worry is grounded. Untested RAM can be unstable. A reworked board sold as a higher-capacity factory model confuses buyers and support. The company has kept adding official SDRAM parts as Pi 5 and CM5 have grown.

The repair complaint is grounded too. A skilled owner can still replace the package. Current firmware may still refuse to boot if the new part does not match the factory record. That closes off a class of repair that the hardware itself still allows.

The argument is about the line Raspberry Pi drew. They chose a boot-time lock instead of labels, seller checks, warranty exclusions, or a visible modification flag.

For most buyers the practical answer is dull and useful. Buy the RAM size you need. Check the factory revision on used or oddly cheap boards. If you are replacing a dead package, an identical part code is a different job from a capacity upgrade. If you freeze an old bootloader to keep a modification alive, you are also skipping later EEPROM updates.

Pi still invites experimentation. The boards can still be reworked. The current firmware decides whether some of those reworks are allowed to start.

---

ameriDroid carries official Raspberry Pi 5 configurations.