There's been some fun stuff lately in the maker community around Raspberry Pi and RAM upgrades. Specifically, a recentish (~ 2025) boot firmware upgrade locks the RAM size to what it shipped with. There's been some write-ups about it - https://www.jeffgeerling.com/blog/2026/raspberry-pi-ram-lockdown/ and https://hackaday.com/2026/09/22/raspberry-pi-ram-restrictions-no-big-deal-frankly/ come to mind - but they don't REALLY go into all the gory details behind the scenes.
So let's do a quick dive into RAM and how it's changed from the past until now.
First off - a lot of tinkering in retro computing exposes people to static and dynamic RAM chips, first dating back to the late 70s. After a few attempts at stuff, manufacturers soon ended up kind of iterating towards a few standard pinouts and specification timings - likely so new upstart RAM makers could sell their chips as "drop in replacements" for existing RAM.
This led manufacturers towards defining an actual standard for this stuff - JEDEC (https://en.wikipedia.org/wiki/JEDEC_memory_standards) - which defines what and how various types of RAM need to behave. This is needed so you didn't end up with RAM chips needing to be paired with very specific controllers / CPUs. Some vendors kept the market on their toes with very not compatible stuff (think the RDRAM from Rambus - https://en.wikipedia.org/wiki/RDRAM) but in general one of the big reasons we had affordable RAM until recently (and will again, I'm sure) is because there's basically no vendor lock-in and a lot of interoperability.
However, that interoperability comes at a cost. Silicon isn't just some magical thing you can stamp out and get a million chips that all behave exactly the same. There's always going to be subtle behavioural differences across them. For CPUs this can actually show up as different maximum clock frequency versus heat dissipation - some CPUs will run at the maximum clock frequency at a lower temperature versus others - and yes when you graph them you'll likely get a normal or bi-modal distribution. For desktop CPUs with active cooling this may result in the same CPU being sold at a higher price with a higher maximum clock frequency, and then a "slightly cheaper" CPU being sold with a lower maximum clock frequency. If it's going into something like a cellphone or a piece of wearable technology where there's no active cooling, you either have to choose whether to lower EVERYONES maximum device performance, allow SOME devices to operate at a maximum higher performance, or you reject a percentage of the CPUs from the product and use them elsewhere.
(Yes, this is what they call "binning".)
For RAM, stable frequency, timing and bus characteristics are critical. Remember these parts aren't operating at 1 or 10MHz anymore - these chips operate their busses on both sides of the clock cycle at over 1GHz. At that point you're well into the "this behaves like RF" domain. As part of this, the PCB layout design, the connector design, the individual track lengths (think phase delays) + lengths inside the memory controller all have to line up exactly correctly - and then you still have weird RF style behaviour going on. Remember how I said every chip behaves differently? They're going to have slightly different timing and slightly different RF characteristics. So you can't just whack a single set of parameters down and hope they work - you need to go through calibration, validation and bulk testing before you know you've got something that works.
First up - the DDR4 power-up sequence is not just "apply power, add RAS/CAS timings and go." There's a whole calibration sequence that has to happen to calibrate the memory controller PHY (physical interface). For an example of this, take a look at the AMD Soft core (FPGA) DDR4 SDRAM controller calibration / setup documentation at https://docs.amd.com/r/en-US/pg353-versal-acap-soft-ddr4-mem-ip/Memory-Initialization-and-Calibration-Sequence . It has to be able to run this sequence to completion, every time, or you won't have reliably working RAM.
What parameters are required to make this work?
Well, we get cheap, mostly interoperable DIMMs because the JEDEC standard defines what parameters to put into the DIMM EEPROM module that is read by the memory controller during power on. Yes, it's also documented online - https://en.wikipedia.org/wiki/Serial_presence_detect has all the fun details. Note that there's many, many more parameters here than just RAS/CAS timings! There's all kinds of timings to do with voltage calibration management, nanosecond accurate wait and hold times for various parts of the RAS/CAS signaling, data line skew, and other fun behavioural things.
Now here comes the fun part.
A DIMM manufacturer is going to make some test DIMMs and test them on a whole variety of motherboards to make sure that the parameters they program in reliably result in the above PHY calibration/setup succeeding 100% of the time on all the hardware they care about. They're then going to choose (hopefully conservatively) suitable values to write into the SPD to allow this to, yes, calibrate/setup 100% of the time. They may even slow down the RAM to meet timing if needed. But typically they're going to hope that the manufacturer binning of the SDRAM parts into specific part numbers and performance/behavioural bands will result in being able to make a DIMM that consistently operates at a specific performance tier without them having to further bin things when they're on the DIMM. Noone wants to throw away manufactured things, so the manufacturer has the option to just write slower parameters into SPD and sell the DIMM as a slower DIMM.
But an embedded board developer doesn't have some EEPROM attached to each group of RAM modules they've put on the board. They will have likely characterised one, two or three RAM module suppliers (either for different sizes, or the same size but multiple manufacturers so they can play off pricing against each other when making different batches of boards) and put those parameters into a fixed lookup table on said embedded board as a starting point. If you're fancy (and I don't know if RPI is being fancy or not) you'll actually run the calibration on your manufacturing line and write the SDRAM parameters for your chosen RAM into the EEPROM as the "active" configuration.
And here you see the dilemma.
See, the configuration parameters are either conservative ones for a handful of tested RAM chips from specific manufacturers, or they're very specifically for the RAM you've had installed on your embedded board. They've done a whole lot of characterization of the RAM across first one, then three, then a dozen or two, then hundreds, and finally the whole run as they're making them, to minimise the chances that during actual bulk manufacturing that a board fails RAM calibration/setup.
So when you just switch the SDRAM chip over to some other manufacturer part? You're basically hoping that given the initial RAM configuration parameters stored in EEPROM/flash somewhere on your board, the RAM calibration/setup will always succeed and then normal operation is stable. And you may get lucky! You may not! But you absolutely aren't guaranteed anything at this point.
And this is why the Raspberry Pi Foundation is doing the right thing here. Sorry y'all, but at this point you're actually likely not qualified to do all of the above work.
... and why not? Why can't you calibrate/test the RAM and write the parameters back?
A great question! The short answer is this.
It's typically vendor provided tooling that is not open source and is very proprietary, and they don't want you to know how to do it or what their memory controller is doing.
And THAT is a discussion for another time.
So now you know. It's not as simple as "RPI foundation is good" or "RPI foundation is bad". It's an intersection of how modern hardware works, how much effort goes into making sure it's bullet proof (or as bullet proof as they can get it) and what vendors / manufacturing lines are willing to release versus what they're requiring to keep as closed / NDAed stuff.
(Don't hate the player, hate the game, etc)
