Upgrading the Raspberry Pi 4 to 16 GB of RAM

[geerlingguy]

Today I saw this video from MadEDoctor on YouTube: https://www.youtube.com/watch?v=vtym0TAWNto

He was able to secure a 16 GB Micron RAM chip (don't know the exact part number, it was partially obscured in the video), and replaced the chip on a Pi 4 model B. When he plugged it in, the bootloader screen identified "16 GB" (see timestamp 3:35 in the video).

But when he tried booting Pi OS, it would get to the rainbow screen, then wouldn't boot any further.

I'm wondering if, since there was never a production 16 GB Pi, it might be something on the firmware level that needs to be tweaked, or if it might just be a dtb or some other setting that might be holding back boot.

Obviously, as this is not a production issue, there is no warranty or support for this type of modification—but it would be cool to see it work! It's highly impractical from a cost perspective as 8 GB is already beyond the limit of what probably 90% of Pi use cases need.

[timg236]

The hardware (specifically the memory controller) doesn't support 16GB.

[geerlingguy]

The hardware (specifically the memory controller) doesn't support 16GB.

Aww, shucks! I was fearful it could be something like that

[MadEDoctor_YT]

I don't think that there is hardware issue...
https://developer.arm.com/documentation ... MU?lang=en
As said in the datasheet of the Cortex A72 the MMU supports up to 44bit RAM addresses thats around 2.2TB of RAM

[timg236]

I don't think that there is hardware issue...
https://developer.arm.com/documentation ... MU?lang=en
As said in the datasheet of the Cortex A72 the MMU supports up to 44bit RAM addresses thats around 2.2TB of RAM

The A72 may well support that, but the internal address bus is smaller and the memory controller (which is not part of the ARM core) has other restrictions on the LPDDR4 configurations which effectively limits SDRAM size to 8GB.

[MadEDoctor_YT]

Ok, then why there is 16GB SDRAM address space listed in the Raspberry Pi BCM2711 document under 1.2.4 section?
https://datasheets.raspberrypi.com/bcm2 ... herals.pdf

[timg236]

Because 16GB is the size of the SDRAM window on the physical address bus. You would need to find a 16GB part supported by the SDRAM controller to fill that space, the part you have is not suitable and AFAIK there are no LPDDR4 16GB chips that are suitable.

[cleverca22]

He was able to secure a 16 GB Micron RAM chip

AFAIK there are no LPDDR4 16GB chips that are suitable.

what chips are suitable? what are the specs it supports?, how would you know if a given chip is compatible?

[MadEDoctor_YT]

There is only one chip ever made that is compatible.
That is the Micron D8CBG / MT53E4G32D8CY-046 WT:C which has x32 organization same as the
8GB OEM one that is Micron D9ZCL / MT53E2G32D4NQ-046 WT:A

Both have the exact same specs and pin layouts in their datasheet.
The only difference is that the 16GB chip has double the dies inside and double the addresses.
8GB chip datasheet - https://www.farnell.com/datasheets/3681594.pdf
16GB chip datasheet - Forum MOD - removed link to datasheet marked as Micron Confidential

[cleverca22]

have you tried the uart logs during boot? there are at least 2 different ones you can enable

BOOT_UART=1 in the eeprom config file, will enable stage1 debug, including dram init messages

uart_2ndstage=1 in config.txt will enable start4.elf debug logs

enable_uart=1 and dtoverlay=disable-bt in config.txt plus console=serial0 in cmdline.txt, will enable linux logs during boot

combine all 3, and you should have a better idea of what is hanging during boot
i'm also interested in how they differ from normal, can you post those logs if you can get them?

Both have the exact same specs and pin layouts in their datasheet.
The only difference is that the 16GB chip has double the dies inside and double the addresses.

that sounds exactly like how the 1gig pi3 works, there are no 1gig lpddr2 dies
but by wiring a 512mb die to the lower 16bits of the data bus, and a second to the upper 16bits, they can fake a 1gig die

so instead of running a 512mb die, in 32bit mode, they are running 2 x 512mb dies, in 16bit mode, but then tell the dram controller its still in 32bit mode

[timg236]

You think we aren't aware of this or don't have access to SDRAM samples?

[MadEDoctor_YT]

I am well aware that you have access to whatever you want (hardware and software) and also I am aware that you (as a company) either planned long ago or now you are planning to release a 16GB version sooner or later. And with all my respect it is obvious that you just don't want to help for one reason or another

There was a ton of bull**** throughout the years on Reddit and in this forum about how it is impossible to just swap the RAM chip on your Raspberry Pi 4 let's say, upgrade from 1GB to 8GB of memory, but I made it about two months ago. And before you say that it is way different to upgrade from 1 to 8GB than from 4 to 16GB, we all know that... The question is to find a way to make it work, instead of finding endless reasons to say how it's never going to work.

[MadEDoctor_YT]

have you tried the uart logs during boot? there are at least 2 different ones you can enable

BOOT_UART=1 in the eeprom config file, will enable stage1 debug, including dram init messages

uart_2ndstage=1 in config.txt will enable start4.elf debug logs

enable_uart=1 and dtoverlay=disable-bt in config.txt plus console=serial0 in cmdline.txt, will enable linux logs during boot

combine all 3, and you should have a better idea of what is hanging during boot
i'm also interested in how they differ from normal, can you post those logs if you can get them?

Both have the exact same specs and pin layouts in their datasheet.
The only difference is that the 16GB chip has double the dies inside and double the addresses.

that sounds exactly like how the 1gig pi3 works, there are no 1gig lpddr2 dies
but by wiring a 512mb die to the lower 16bits of the data bus, and a second to the upper 16bits, they can fake a 1gig die

so instead of running a 512mb die, in 32bit mode, they are running 2 x 512mb dies, in 16bit mode, but then tell the dram controller its still in 32bit mode

I haven't tried this yet, but I hope I will have some free time in a few days to try it out.

[timg236]

Well, that would require taping out another chip that supports a larger number of row-bits in the die addressing which is fairly obvious if you diff the two datasheets.

[PhilE]

Well, that would require taping out another chip that supports a larger number of row-bits in the die addressing which is fairly obvious if you diff the two datasheets.

That sounds like an excuse to me - fake news.

[HermannSW]

Well, that would require taping out another chip that supports a larger number of row-bits in the die addressing which is fairly obvious if you diff the two datasheets.

That sounds like an excuse to me - fake news.

Irony, or different opinions of two Raspberry Pi engineers?

[PhilE]

Where's the fun in answering that?

[bjtheone]

I am well aware that you have access to whatever you want (hardware and software) and also I am aware that you (as a company) either planned long ago or now you are planning to release a 16GB version sooner or later. And with all my respect it is obvious that you just don't want to help for one reason or another

There was a ton of bull**** throughout the years on Reddit and in this forum about how it is impossible to just swap the RAM chip on your Raspberry Pi 4 let's say, upgrade from 1GB to 8GB of memory, but I made it about two months ago. And before you say that it is way different to upgrade from 1 to 8GB than from 4 to 16GB, we all know that... The question is to find a way to make it work, instead of finding endless reasons to say how it's never going to work.

Given that many (most) people struggle with basic soldering, desoldering the memory and replacing with a larger chip is well beyond the skill of almost all folks, even if a supply was readily available.

Just because some very limited group of folks with the right training, equipment, and access to stuff can do something does not mean it is unreasonable to say that it is impossible for the general audience. And that does not even touch on if the frankenPi would be reliable, stable, and work with all the software.

There was a pretty small uptake on the 8GB models, and the additional cost was fairly minor. I don't see them doing a 16GB model for a while yet.

[geerlingguy]

There was a pretty small uptake on the 8GB models, and the additional cost was fairly minor. I don't see them doing a 16GB model for a while yet.

The 8 GB has been the hardest to get since shortly after its introduction, so either it's been supply constrained or it's extremely popular...?

That said, the BCM2711 really doesn't have the horsepower to do as many jobs that would consume more than 4 GB of RAM and be more efficient than something more powerful, so I'd bet the majority of 8 GB Pis running in the wild are using nowhere near that capacity of RAM for anything but a cache.

That said, there's a big difference between calling something 'impossible' and saying "it's very difficult and should not be attempted".

In the former case, it's a case-closed 'this cannot be done,' and it discourages the tinkerers who otherwise do crazy and wild things to advance the platform in ways nobody thought would happen. In the latter it protects the product from people bashing it for not supporting a certain feature, but leaves the room for those strange ones to play

I am always careful to say whether some thing is "impossible" or just "very dumb." The latter leaves the door open to—if nothing else—entertaining shenanigans.

[cleverca22]

i'm still surprised it even got to the rainbow screen

that means it got past the dram init code, which must understand how to deal with 16gig at least partially

BOOT_UART=1 will reveal if it actually understands that it has 16gig of ram

[redvli]

A serial dump would also interest me. A cheap cable and some copy and paste of text. No SD-card needed. I stopped more or less clicking on Youtube links.

[Dygear]

The 8 GB has been the hardest to get since shortly after its introduction, so either it's been supply constrained or it's extremely popular...?

I have 2 running as a web server, one in Boston and another in New York. They make pretty great backup servers as in the FLIRC case no moving parts are needed and it doesn't have any parts that could ware out. These are both failover services should my main server (and AMD Eypc) have a panic attack (It's running Rust programs) and fall over.

That said, the BCM2711 really doesn't have the horsepower to do as many jobs that would consume more than 4 GB of RAM and be more efficient than something more powerful, so I'd bet the majority of 8 GB Pis running in the wild are using nowhere near that capacity of RAM for anything but a cache.

I was thinking about this recently. It would be very handy to have an SQLite server in memory for reads with a backing store for writes. So writes hit both the in-memory database and the SD card database, but reads only come from the memory. That would make the Raspberry Pi fairly quick and read heavy workloads. The only problem? Most of the Databases I use are in the a ride range, and right now fit into 8GB, but they are growing fast. (See attachment).

That said, there's a big difference between calling something 'impossible' and saying "it's very difficult and should not be attempted".

In the former case, it's a case-closed 'this cannot be done,' and it discourages the tinkerers who otherwise do crazy and wild things to advance the platform in ways nobody thought would happen. In the latter it protects the product from people bashing it for not supporting a certain feature, but leaves the room for those strange ones to play

I am always careful to say whether some thing is "impossible" or just "very dumb." The latter leaves the door open to—if nothing else—entertaining shenanigans.

I think it's more like "We don't want to encourage people to possibly break their hardware." It requires a pretty experienced hand in order to desolder a RAM chip and put another one on.

[MadEDoctor_YT]

Today I got some free time available and I started testing different stuff the community suggested over the past couple of days.
I just got VMware fully working on the Raspberry Pi 4 with the 16GB of RAM

Now I will continue with testing other stuff...

[ejolson]

Today I got some free time available and I started testing different stuff the community suggested over the past couple of days.
I just got VMware fully working on the Raspberry Pi 4 with the 16GB of RAM

Now I will continue with testing other stuff...

Congratulations! Thanks for posting.

[6by9]

Fake SD cards will report a larger size than they can really support. They'll work fine until you exceed their actual size or the size that can be addressed....