Raspberry Pi 4 Gets 8GB RAM, Raspbian 64-bit (Beta)

Raspberry Pi 4 with 8GB RAM

The Raspberry Pi 4 Model B was launched in June 2019 with Broadcom BCM2711 Arm Cortex-A72 processor coupled with either 1, 2, or 4GB LPDDR4 RAM.

But there were expectations that a Raspberry Pi 4 with 8GB RAM or an 8GB eMMC flash may be eventually launched, as some of the user guides read “Product name: Raspberry Pi 4 Model B 1 GB, 2 GB, 4 GB + 8 GB variants”. We now know the answer as the Raspberry Pi Foundation has just introduced Raspberry Pi 4 with 8GB RAM.

Raspberry Pi 4 8GB specifications are the same except for the RAM capacity:

    • SoC – Broadcom BCM2711 quad-core Cortex-A72 (ARMv8) @  1.5GHz with VideoCore VI GPU supporting OpenGL ES 3.0 graphics
    • System Memory – 8GB LPDDR4
    • Storage – MicroSD card slot
    • Video Output  & Display I/F
      • 2x micro HDMI ports up to 4Kp60
      • 3.5mm AV port with composite video (and stereo audio)
      • 2-lane MIPI DSI display port
    • Video
      • Decode – H.265 up to 4Kp60, H.264 up to 1080p60
      • Encode – H.264 up to 1080p30
    • Camera – 2-lane MIPI CSI camera port
    • Audio – Stereo audio via AV port, digital audio via HDMI ports
    • Connectivity
      • Gigabit Ethernet (RJ45)
      • Dual-band (2.4 GHz/5.0 GHz) 802.11b/g/n/ac WiFi 5
      • Bluetooth 5.0 BLE
    • USB – 2x USB 3.0 ports, 2x USB 2.0 ports.
    • Expansion – Standard 40-pin GPIO header fully backward-compatible with previous Raspberry Pi boards
    • Power Supply
      • 5V DC via USB-C connector (minimum 3A )
      • 5V DC via GPIO header (minimum 3A )
      • Power over Ethernet (PoE) via optional PoE HAT
    • Dimensions – 85 x 56 mm (same as other model B boards)
    • Temperature Range – 0 – 50°C

Raspberry Pi 4 8GB RAM Unboxing

I got one of the new boards just before launch courtesy of Malaysia based Cytron.

The marking on the package is a good sign, and the SBC ships with a GPIO header pinout card, a warning card, and a safety and user guide…

Click to Enlarge

But if we look at the board itself, nothing has really changed.

Click to Enlarge
Click to Enlarge

The important part is the LPDDR4 chip marked “OAA47 D9ZCL”. It’s meaningless, so we’ll need to use Micron component marking decoder to find out D9ZCL FBGA code is for MT53E2G32D4NQ-046 WT:A chip that is indeed a 64Gbit (8GB) LPDDR4 memory chip.

Raspberry Pi 4 8GB vs 1GB RAM

But that’s the only difference I can easily sport, so let’s compare an early Raspberry Pi 4 1GB RAM to the latest Raspberry Pi 4 8GB RAM board.

Click to Enlarge

The back of the board adds silkscreen for certifications, as well as existing modifications for Raspberry Pi 4 Rev 1.2 to avoid damaging the board when inserting a MicroSD card. But the top of the board has more modification around the USB-C port, USB Type-A ports, and a chip between the VLI PCIe to USB chip and AV jack is just gone. So it’s possible further USB-C issues have been fixed, and some improvements have been made to USB host ports maybe with regards to powering up external hard drives.

[Update from Eben Upton about hardware changes:

These are the regulator changes I mention in the post. The disappeared chip near the USB connector is the old regulator. The new stuff near the USB-C is the new regulator. The input clamp component has moved across to the USB area to make room.

]

What about software? Raspbian 64-bit on the way?

Getting a Raspberry Pi 4 with 8GB RAM is great, but shouldn’t we have a 64-bit OS to make use of the extra memory? We’ve already seen Debian 10 64-bit, BalenaOS, and Ubuntu for Raspberry Pi, but considering Raspbian is the officially recommended operating system we should expect a 64-bit version of Raspbian very soon. And indeed the Raspberry Pi Foundation has posted a beta version of Raspberry Pi 64-bit OS (not called Raspbian 64-bit for some reason) which I was told it is still not ready for prime time, and I’m not surprised because it’s… a beta version. I’m not able to test the board right since I’m on the road and don’t have a proper USB-C power adapter nor micro HDMI cable with me. However, I’ve been told the 32-bit version of Raspbian already shows about 8GB RAM.

How is that possible? If I remember correctly some Arm processors support LPAE 40-bit addressing which allows 32-bit systems to access over 4GB but with a limitation that a single process cannot use more than 3GB RAM. There’s already a 64-bit option in /boot/config.txt which you set if you also use a 64-bit kernel.


This should allow you to run 64-bit applications without LPAE limitation, but it’s still challenging since the Raspbian rootfs is still 32-bit only, so you’d have to build your own 64-bit libraries too. I’ll probably test Raspberry Pi OS 64-bit and/or other 64-bit OS compatible with Raspberry Pi such as Ubuntu 20.04 on the board once I’m back home.

One thing you can be for sure is that benchmark results for the 8GB RAM version are likely to be exactly the same as for 2GB and 4GB models. Raspbian 64-bit OS may eventually bring some improvements and/or regressions in benchmarks, but people who will really benefit from the extra RAM are those who ran out of memory with 4GB RAM, or experienced severe swapping on the MicroSD card.

How Much? And Where can I get One?

Raspberry Pi 4 8GB is available with an official retail price of $75 US before taxes and shipping. It can be purchased from distributors including Cytron,  Element14, Seeed Studio, and Pimonori.

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

94 Replies to “Raspberry Pi 4 Gets 8GB RAM, Raspbian 64-bit (Beta)”

  1. Now I can see a Raspberry Pi 4 with 16GB RAM would be possible, but it won’t happen because the chip they’d need does not exist…
    Eben Upton:

    The BCM2711 chip that we use on Raspberry Pi 4 can address up to 16GB of LPDDR4 SDRAM

    1. Why are you guys so resistant to sticking eMMC on your boards. That should be the standard. uSD is just an absurd way to house the OS. Now, let get a new CM4 with PHY onboard & make it smaller we dont need every single I/O pin on the connector.

      1. I’m not involved with the Raspberry Pi Foundation at all, but I think they did not add an eMMC flash because they did not want to completely redesign the board. And if you read the RPi forums some of the developers said a MicroSD is better than eMMC flash… I remember this was talked in another thread on CNX Software and mostly dismissed.

        CM4 will likely not be smaller beause they’ll also expose PCIe, and they may also want some backward compatibility.

        1. > CM4 will likely not be smaller beause they’ll also expose PCIe, and they may also want some backward compatibility.

          If they want backwards compatibility how should then RGMII, 2nd HDMI and either PCIe or the SuperSpeed data lines be present on the connector? Are there plenty of unused pins?

          1. Not quite sure, I haven’t looked into it in details, but the current SO-DIMM connector should have 200 or so pins, so that might be enough?

        2. Upton has commented, that USB to SSD is better and faster in his opinion and they have added Usb Boot.

          1. I still don’t understand why desktop PCs have PCI slots, when they could also have superspeed instead. Seems all the PC manufacturers are morons, would they just listen to eben, jamesh and jerry, the world would be so much better!

          2. He He 🙂 Yes PC comes from the family history of motherboard and configure as you wish. Over time the usb, sound, keyboard, ide, sata etc moved to the motherboard chips.

          3. And soon only usb will be left where you can hang the things oktopus-alike from RGB LED umbilicals…

          4. because usb3 is 3lanes link and little bit more latency where pcie can be only one lane link and latency under uS

          5. For most people desktop PC = notebook. Also the pcie lane is available via usb-c/thunderbolt.

        3. The random r/w performance of eMMC is obviously higher than SD card,even the poor eMMC is faster than so-called A2 SD card. I have do some tests on RPi4 (with iozone), but the current bootloader can not boot normally every time on eMMC.

    1. It’s probably the only SBC with 8GB RAM that sells for less than $150. I’m not sure that many people need the extra memory though unless maybe those who use it as a desktop replacement.

      1. Yes i hope more people get the idea that SoC capable of 8GB or more in these price brackets have desktop use for lower end stuff. Word processing, database , light photo editing etc.

        1. Yep. Lately I tried to use RPI4 4GB with manjaro + ZRAM for desktop use. If I play youtube for hours, it’ll freeze. Memory full. And the HDMI out color is worse than my latitude e6440.

        2. Intel and amd embedded already come with 32gb ddr4 for light desktop and htpc use cases such as kodi. I can imagine how python / nodejs embedded runtimes may begin to reserve space appropriately. Schools want to run whole dev stack and desktop in the edge computing nodes.

        3. That’s exactly what I’m buying mine for. It’ll be really interesting to see how it compares to the pinebook pro. 2 x 2GHz A72s vs 4 x 1.5GHz A72s but double the RAM. As much as I love the pinebook pro it’s a bit slow for heavy web usage, I suspect the proper solution is higher single core performance but I’d like to see what more cores and more RAM does to the situation plus it’s significantly cheaper than jumping to 16 cores with the Honeycomb LX2K.

          1. For web, ARM SBC lack proper GPU and VPU driver. 2x A72 is quite good, if you compare that to atom Z8350.

      2. It’s great for ltsp thin clients. 8gb enables more modern app platforms such as webkit / pwa.

  2. It’s great as this will encourage others to increase their memory as well to fill the gap. It will also really pressure RPi users to migrate to 64-bit, possibly giving up on the rare stuff that doesn’t work anymore. By the way, running a 64-bit kernel with 32-bit userland is not a bad option at all for a first start. My previous PC has run like this for many years, and as long as you don’t have a single application requiring a lot of RAM it’s a good compromise.

    1. If only it was that easy. As pointed out, the BCM2711 doesn’t have a limited memory controller, whereas a lot of the “cheap” Chinese ARM SoC has a hard upper limit of 1, 2 or 4GB. Thus it’s not possible to make a board with more RAM than the SoC supports.

      1. > whereas a lot of the “cheap” Chinese ARM SoC has a hard upper limit of 1, 2 or 4GB

        Some (Allwinner) even in a mode that you need to solder a 4GB package to the PCB but can then address only 3GB of it.

      1. Well, to be fair, “some RPi users want…”. I think there’s a solid installed base of people who want a 64-bit linux on it, judging by the community’s activity around triyng to boot the 64 bit kernel were when RPi4 was released. I think that for most users, it’s just “because surely 64 is twice as good as 32”. Another part might have wanted it just because RPF said it was pointless!

        1. There are users who need up to 64 gigabytes of RAM but NUC and ITX boards don’t have GPIO/SPI/I2C. Progress is always great. RPi increased RAM from initial 0,25 GB to 8 GB in 8 years. That’s 32x improvement. They also upgraded from 1 small to 4 big cores and from 100 to 1000 Mbit ethernet. I’d expect RPi to have 64 GB of RAM in 2028, along with 10 gigabit ethernet and 32 cores, maybe 3 or 5nm.

          1. You forgot to add to your calculations consumption increase. When for SBC is Fan necessity I put hands from it. I have enough noise coming form my laptop. And I am happy my tablet nad smartphones is fanless.

  3. Good news, along with bootable from usb. It’s more feasible to use RPi4 for desktop use. What the not-so-good news is: they still doesn’t provide RTC onboard like odroid XU4 or N2. You have to use RTC shield.

    1. If it is networked, just get the time via NTP. If it is not networked, use a RTC shield. I strongly suspect that the ratio of case 1 to case 2 is extremely high!

      1. Sadly, where I live, the electricity and internet connection is not that good. Electricity: goes off quite often, sometimes, twice/thrice a week, for ~2 hours. Internet: not available at someplace. RTC shield, is a shield. You must bought the shield. If they put onboard RTC, you just have to supply the battery. Simpler.

          1. Pricey, and not practical. It’s better to use used UPS (custom, use step down DC from battery) or powerbank.

            My dream sbc: Something like N2 + onboard battery shield, so you can plug in, say, 18650 batter{y|ies} there for emergency case (electricity goes down).

          2. Item availability, and RTC shield is pricier. Plus for that 40 GPIO, you’ve used 3 of that. And sometimes, you can’t put other shield on it if the shield must occupy same GPIO place.

            With onboard RTC, you just go to computer shop, bought 1 mobo battery, and put that to the SBC.

            If there’s 2 SBC, 1 with onboard RTC, another must use shield. It’s no brainer to pick one with onboard RTC.

            But we talk about RPi here. The foundation focus, as they said, is education (for developed world). They’re not preparing these board for developing world, where electricity and/or internet goes on and off..

          3. Olimex offers certain SBCs with built-in lipo chargers and up converters to also power usb from one cell as on a tablet or power bank.

          4. Nope I meant i.e. this: https://www.olimex.com/Products/OLinuXino/A64/A64-OLinuXino/open-source-hardware

            Or that: https://www.olimex.com/Products/OLinuXino/Home-Server/LIME2-SERVER-NO-HDD/open-source-hardware

            Or many others ready to just connect a single cell lipo to a 2pin connector and you have the same battery backup as you are used from your phone.

            Perfect for the indian power grid with daily loadshedding and occasional cyclones (ok you will need a really phat lipo for that 😉 )

          5. While my post with the direct links awaits moderation: No, I meant the Olinuxino range of SBCs many have a Lipo connector allowing to charge from and powering the board. See i.e. home server/freedom box or Olinuxino A64, the lime range, even the upcoming STM32MP1 based lime SBC etc.

          6. Yes! something like A64-OLinuXino. If only other SBC made board like that too.

          7. My next SBC might be one of theirs, being fed up with amlogic’s boot process and blobbyness

  4. Have they now fixed the issues that limited DMA to only the first GB of RAM (or to the first 3 GB in the case of PCIe)?

    1. But then we’d lose USB3, correct ? I’m still looking for a compact&cheap 4GB board with USB3/GbE/SATA to replace my annoying backup server, and if possible with 16 MB NOR or some eMMC to put the OS. To date I think the closest would be the 2GB espressobin. And no, I’m not going to waste my macchiatobin on this 🙂

      1. I’d happily loose USB3 if I can have a standard PCIe slot. This is how my VIM3Ls are set up, with a PCIe switch, a i350 and a 88se9215. CPUs, memory, PCIe. It rhymes beautifully! 😉

        1. Interesting point. I thought about using my VIM3L for this but the USB3 turns to USB2 when PCIe is in use and I’ve seen the difference between USB2 and USB3 for off-site backups that lasted 12+ hours in USB2. However it’s true that I tend to focus on SATA because my current SSD is on SATA but I could also consider buying an M2 1TB SSD to put on another board!

          1. Just add a decent USB3 card. Even sharing a single PCIe lane among a bunch of functions is better than using the terrible IPs that most vendors glue together. My setup looks a ball of wires (it is!), but it is pretty performant (yes, the cards do cost twice the price of the SBC…).

          2. > My setup looks a ball of wires (it is!)

            Can you share a picture (me being really curios now)?

          3. I tried two:
            – ASM1184e: works, but a bit flaky at times. It sits on its own PCIe card with 4 ports, so you quickly end-up with tons of cables dangling around as you need to individual cables running to the ports with their own PCIe connectors.
            – PI7C9X2G404: pretty solid, lines on the board carrying the PCIe connectors, so much more robust. This corresponds to the picture I have posted above.

      2. > But then we’d lose USB3, correct?

        Sure. Or they also put an VL805 on the CM4 and PCIe is wasted for USB3 (unfortunately Eben Upton answered the question whether there will be PCIe on the connector not directly).

        1. “Not to be left out, today we’ve released an early beta of our own 64-bit operating system image.”

          Never too late. It’s 2020 after all.

  5. It would be nice if the memory fit into a socket and could be replaced / upgraded. Not just the Raspberry Pi, but low-cost SBCs in general. It seems like it would add very little cost per-unit to the BOM. I can imagine a number of reasons why they might shy away from this though – compatibility, cost, and maybe even availability of chips that fit into a socket as opposed to a BGA style package.

    1. It can add a lot of support trouble that they don’t want to risk. Look at the situation with Atoms and DDR3. You had to try 3-4 different brands before finding one that allowed your machine to boot. I even sent one in RMA, firmly believing the board was dead due to 3 different sticks not working on it, it’s just that I needed to try yet another one :-/ I don’t know how it is today, the only atoms I have now all have their RAM soldered!

      1. > It can add a lot of support trouble that they don’t want to risk.

        And you would need to find a SoC that is equipped with a memory controller that can deal with DIMMs in the first place.

        1. The memory controller has nothing to do with the DIMM or DRAM chip, DIMM is just a form factor. RK3399 can also support DIMM, it’s a matter of ddr calibration, which can be down in u-boot SPL. One example is the laptop bunnie made, with iMX6 and SODIMM ram. DIMM make sense if the supported max ram is far beyond some user’s requirement, such as 16/32GB.

          1. It can be done on the i.mx6 because the DDR controller is documented. For rockchip etc you’re basically dependent on whatever hardcoded values are in the blob before the SPL.. and half the reason those blobs are there is because the bootroms aren’t equiped to read the SPD eeprom off of a DIMM and init the memory in a sane way before anything else loads.

          2. But how should users do ‘ddr calibration, which can be done in u-boot SPL’ when they’re pretty much clueless and just want to repurpose their old DDR3 SO-DIMMs from a laptop?

            I was referring to Hardkernel folks who explained in their forum that for dealing with DIMMs in the usual way (bootloader reading out the SPD eeprom on the DIMM containing calibration info and then setting up memory) necessary data lines were already missing in most ARM SoCs.

          3. Quite frankly they could sacrifice 2 GPIOs and bitbang them to read the tiny 24C02 on the DIMM.

    1. As Jean-Luc indicated above, many of their users are not interested and prefer SD. It’s not much surprising though. The first thing needed to boot from eMMC is to have a flexible boot option with an easy way to boot from SD/USB in recovery mode to reinstall the board. Having dealt with rockchip’s crappy tools to flash the eMMC image over USB, which couldn’t even just be a dump of the SD, or having had to deal with Marvell’s NAND flashing over the serial port, again with a small change from the other image, then with the clearfog’s inability to see SD and eMMC at the same time, making the eMMC reinstallation quite difficult, I can easily understand how many users have kept horror stories in mind.

      For me, an SBC booting off eMMC should use a simple file-based boot process (such as extlinux.conf), and be able to boot a very similar recovery image from over USB so that users don’t have extreme difficulties recovering from a non-booting machine, especially when it’s their only linux machine at home.

      1. Flashing eMMC on the Compute Module is rather simple but (not so) surprisingly you need to tell the RPi Trading Ltd. employees how it’s done: https://www.raspberrypi.org/forums/viewtopic.php?t=237321 (the jamesh guy is also in charge of censoring their forums und telling people eMMC would be way slower than SD cards and adding eMMC to the board would cost insane amounts of money).

        1. The only point against emmc besides price (SD cards also come with a price tag) is the RMA for “bricked” boards, for status quo you just blame the user of using the wrong SD, easy, problem solved.

          1. Nobody is forcing them to solder eMMC directly on the board since pluggable eMMC modules as designed by Hardkernel for example exist for a long time now. Radxa / Tom Cubie extended the ODROID module format with a 2nd row connector for more secure mounting and FriendlyELEC invented eMMC modules that do not take much space on the board since ‘floating above’ other stuff:

            https://m.media-amazon.com/images/I/51DJXRhefeL._AC_UL320_.jpg

      2. Khadas Rescue offers a very easy and full featured ‘rescue’ image for the VIM3. Even lazy people like me have no problem using it to dump images to EMMC, and even chroot and edit showstopping /etc misconfigurations with it.

  6. To supply the slightly higher peak currents required by the new memory package, James has shuffled the power supply components on the board
    So the Pi 4 board was modified a bit but they increased the overheating problem?

    1. Why exactly? Don’t you think the RPi Trading Ltd. employees do a good job trying to support their own hardware with all their ThreadX hacking, kernel support and Rasbian and now ‘Raspberry Pi OS’ builds?

      You know that Armbian for RPi would just be a modified userland (which is either Ubuntu or Debian anyway and you can get both for the RPi already) since Armbian can not deal with the RPi’s primary operating system (closed source ThreadX) and it would make absolutely no sense to deal with the RPi kernel.

      So all you would get from Armbian are some familiar userland tools and maybe with the RPi 4 some small performance tweaks (e.g. zram by default and IRQ affinity optimizations. But to be honest: nobody inside Armbian team seems to care about such low-level stuff anymore so the only difference would be the replacement of moronic ‘swap on SD card’ with zram)

      1. I don’t know whether RPI4 not using ThreadX, but I’ve read that RPi4 didn’t have ThreadX. CMIIW. And the reason I prefer armbian is how they set the ZRAM, tmpfs, etc. It really help for lazy me. For now, I’m using manjaro with kde, with systemd-swap package :).

        1. > I don’t know whether RPI4 not using ThreadX, but I’ve read that RPi4 didn’t have ThreadX

          RPi 4 relies on VideoCore VI while the older ones are VC4 SBC. Guess why stuff that worked already with the older RPi like USB or network booting is now delayed that much?

          Since ‘booting’ an RPi happens in the closed source domain called VideoCore. Talented people on RPi Trading Ltd.’s payroll waste their time dealing with the proprietary stuff called ThreadX to implement device drivers for PCIe, USB3/XHCI and RGMII/MDIO just to be able to bring up stuff that worked before when everything was behind the one single USB2 connection.

          1. > Guess why stuff that worked already with the older RPi like USB or network booting is now delayed that much?

            I suppose they’re moving from ThreadX to non ThreadX that stuff become delayed now. Look like they still using it. Sorry, my knowledge about these thing is minimal.

      2. TBH I think if you dislike ThreadX the future of ARM is not going to be to your liking.. i.e. more and more stuff being moved to closed and signed blobs below the kernel in an attempt to skirt around the GPL.

        1. Of that comes true, that’s not a good development.
          So far blobs were confined in their own uC, like i.e. WLAN firmware or as mobile basebands were running on their own uP but can mess with main memory via DMA, bad enough.

          But threadx is about as crucial to run the arm cores, as what one hears about IME on x86, so you can’t disable it, not even at the cost of reduced functionality.

          1. It’s not an *if*. It’s already true. The boot process for 64bit ARM SoCs basically always involves loading “secure world” firmware below the kernel. The ARM trusted firmware is BSD licensed so they don’t need to give you the source to their hacked up copy of it and they can easily lock you out from replacing it by implementing signing.

            I’ve already seen linux drivers that are just calls into hidden secure world code. If you think the situation with stuff like video encoders is bad now get ready for a world where all of that stuff is hidden in the secure firmware and there isn’t even awful leaked SDK code to work out how it works.

          2. Well that’s true for hacking blobbed up appliances, but if you are the manufacturer of some SBC or something based on an SOC then you have the BSD licensed ATF, so it’s open source, regardless if it’s Linux or something else.

            Even without some calls into a blob if you have a TiVo-ized Linux appliance riddled with blobs in kernel and userspace. Maybe not even the GPL dump resembles the running binary. So no need for any underlying blobs, we have already lost.

          3. >but if you are the manufacturer of some SBC or something
            >based on an SOC then you have the BSD licensed ATF,
            >so it’s open source, regardless if it’s Linux or something else.

            That’s not required by the license. It would be perfectly fine for the only source of the ATF being a binary blob in the vendor SDK. Vendors already hide how bits like DRAM init, PLL setup etc work in blobs that not even their direct customers have the code for.

          4. Sad but not really surprising.
            Thinking back to university times, those arm7 BSPs were similar type of crap. Highly patched uC Linux kernels completely cut off from any update path…

  7. The AI known as Jerry will have access to more memory and bigger registers.. someone needs to shutdown this madness before it’s too late.

    1. Give me an rk3399 with this amount of memory and the same price level and I will outperform him in trolling any time of the day 😛

      1. One user on RPI thinks Android on 8GB RPI, will be a Nvidia Shield killer. So much for RPI user education.

        1. Just bring a touchscreen and a cam into the equation and you have a flagship killer android phone…

          1. Lol

            And if you bring it on board a plane its the bestest eva avionics box.

            Had just boeing replaced mcas with an rpi, the max would fly again from months.

        2. 8GB isn’t all that much on Android. You can see from articles like this [1] that “Paired with the processor is 6GB of RAM, the A71 could keep open a bit more than 10 apps at once.”. So only 10 desktop apps. If the apps are really heavy like the browsers, Android Studio, etc., you might only be able to run 2-3 apps at a time.

          [1] https://mobilesyrup.com/2020/05/18/samsung-galaxy-a71-review/

Leave a Reply

Your email address will not be published.

Advertisement
Advertisement