Raspberry Pi 5 EEPROM Update Blocks Manual RAM Upgrades: Error Code 9 Sparks Controversy

The Incident: A Firmware Update That Triggers 'SDRAM Mismatch'

A Raspberry Pi 5 user recently posted a warning on Reddit: since the pieeprom-2024-09-23.bin EEPROM firmware update, the Raspberry Pi 5 now enforces a RAM capacity check at boot time. If the detected memory capacity doesn't match the factory configuration, the system will flat-out refuse to start.

The boot log shared in the post makes this check crystal clear:

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'

In simple terms: the Raspberry Pi 5's SoC contains an OTP (One-Time Programmable) memory region that permanently stores the board's factory memory configuration at the time of manufacture. When the EEPROM bootloader detects that the actual memory capacity (32 Gbit in this case) doesn't match the OTP-recorded factory spec (8 Gbit), it throws Error Code 9 and halts the boot process.

OTP (One-Time Programmable) memory is a type of non-volatile storage inside a chip that can only be written once and becomes permanently read-only thereafter. During factory testing, the Broadcom BCM2712 SoC used in the Raspberry Pi 5 has key parameters — such as the board's memory specification and chip serial number — burned into the OTP region. Because the physical nature of OTP makes this data impossible to overwrite or modify, OTP verification results carry extremely high trustworthiness, making them a natural "hard baseline" for firmware to assess hardware legitimacy. EEPROM, by contrast, is a different type of erasable non-volatile storage used to hold the updatable bootloader. The trigger for this incident is a new piece of logic added to the EEPROM bootloader: early in the boot sequence, it now reads the factory memory spec from OTP, compares it against the detected memory capacity, and aborts if they don't match.

Why This Has Infuriated Hardware Enthusiasts

The core grievance of the original poster is this: upgrading the RAM in a Raspberry Pi 5 is an extraordinarily high-barrier operation to begin with.

The Raspberry Pi 5 uses BGA-packaged, soldered-on RAM — not a slot-based memory module you can swap out like in a desktop PC. Removing the factory-soldered memory chip and replacing it with a higher-capacity one requires professional rework equipment (such as a BGA rework station and hot air gun) and serious soldering expertise. Anyone capable of pulling this off is, by definition, a hardcore hardware enthusiast.

The poster's argument: precisely because some capable users want to cut costs by repurposing spare memory chips or self-upgrading in a market where memory prices remain high, the official firmware has now erected a deliberate software-level barrier that shuts these hard-won hardware modifications out.

He drew an apt analogy — "imagine buying a desktop PC and not being able to replace the RAM or SSD." This is exactly the kind of product design logic that Right to Repair advocates find most objectionable.

BGA (Ball Grid Array) packaging is a surface-mount technology where solder balls are arranged in a grid on the underside of the chip, widely used in applications demanding tight space constraints and high electrical performance — such as mobile SoCs, GPU VRAM, and server memory. Unlike traditional leaded packages, all solder joints on a BGA device are hidden directly beneath the chip and invisible to the naked eye; X-ray equipment is required to verify solder quality. Replacing a BGA chip requires a professional infrared or hot-air rework station to heat the board along a precise temperature curve until the solder balls reflow, then use a vacuum tool to lift the old chip, clean the pads, apply flux, and reflow the new chip using the same temperature-controlled process. Any temperature deviation or misalignment at any step can cause bridging between adjacent joints or cold solder joints — and a single mistake can destroy the motherboard. This is why anyone capable of such work is considered a "hardcore" enthusiast.

Official Silence and Deleted Forum Posts

What further inflamed the controversy was another detail the poster mentioned: his attempts to discuss or post about this issue on the official Raspberry Pi forums were reportedly deleted almost immediately.

This lack of open communication amplified community speculation about the company's motives. The poster even half-jokingly worried: "At this rate, are they going to start checking for serialized power adapters at boot to block third-party chargers?"

It should be noted that all of the above represents the statements and personal views of a single Reddit user. The company has not yet issued any public statement on the technical rationale behind this update.

Technical Justification vs. Commercial Motivation

At the heart of the debate is a fundamental question: is hardcoding a memory capacity check a decision driven by technical and stability considerations, or is it purely a business strategy?

Possible arguments for technical justification:

• Memory timing, voltage, and capacity parameters must be tightly matched with firmware configuration. A capacity mismatch could cause random crashes or data corruption during operation that are extremely difficult to diagnose.
• From a product support perspective, the company may simply be unwilling to provide technical support for unverifiable, non-standard hardware configurations. Enforcing the check prevents a flood of "my modded board is unstable" support tickets.

Arguments questioning commercial motivation:

• The poster bluntly characterizes it as an "artificial software wall" designed to push consumers toward purchasing higher-margin, premium-priced high-memory models.
• If stability were the only concern, an "advanced user proceeds at own risk" unlock option would theoretically suffice — a hard boot refusal is not the only possible response.
• The deletion of forum discussions makes the "purely technical" explanation harder to accept at face value.

Memory Timing refers to the precise time-interval parameters that DRAM must satisfy between signals during read and write operations. Common metrics include CAS Latency (CL), RAS-to-CAS Delay (tRCD), and Row Precharge Time (tRP). Memory chips of different capacities and die densities often have different optimal timing parameters. The memory initialization code in firmware (commonly known as the "memory training" process) loads the corresponding timing tables based on the preset capacity and die specifications. If the actual chip doesn't match these presets, performance may degrade at best — and at worst, random memory read/write errors can occur, manifesting at the OS level as intermittent crashes or silent data corruption. This is the core argument for the technical-justification side: non-standard memory configurations can introduce system stability issues that are nearly impossible to reproduce and diagnose, and these problems ultimately tend to bounce back to the manufacturer as support complaints.

The Bigger Picture

Setting aside the Raspberry Pi specifically, this incident reflects an increasingly common trend in embedded devices and consumer electronics: manufacturers layering software-level "locks" on top of hardware through firmware, OTP, and serialized verification mechanisms.

For ordinary users, these locks are usually irrelevant. But for an ecosystem like Raspberry Pi — long celebrated for being open, hackable, and education-friendly — there is an inherent tension between that positioning and hardcoded restrictions. The Raspberry Pi has always attracted precisely the kind of users who love to DIY and push hardware boundaries, and a boot-refusing validation check hits that core user base right where it hurts.

The topic continues to ferment in the community. Whether the company will issue a formal technical explanation, or offer some kind of unlock mechanism, remains to be seen. Regardless of whether the final verdict leans toward "technical necessity" or "commercial motivation," this incident adds yet another vivid case study to the ongoing debate around the right to repair and hardware freedom.