Is 4 GB the Limit for the Raspberry Pi 4? | Hacker News Reader

Is 4 GB the Limit for the Raspberry Pi 4?

hackaday.com

44 pointsipeev42 comments

I'd agree with the hackaday commenters that this seems like they considered putting eMMC (or any kind of flash) storage on the high-end board. Would have been nice considering the reliability of most microSD cards.

Relevant: https://www.raspberrypi.org/forums/viewtopic.php?p=1484362#p...

"Nope, personal experience. SD cards have wear leveling, EMMC generally doesn't, so if using them for the same thing, the EMMC will fail first. depends on the FS." - An Engineer at Rasberry Pi.

Anyone comment on that?

Its an incorrect statement - I think James on the Pi forum was confusing NAND vs eMMC.

eMMC has (with exception of some high grade SDCards) better write cycles and is considerably more durable than the average SDCard.

What about above average SD cards: the so called "industrial" SD cards?

Average users aren't running out of write cycles. SD cards usually corrupt themselves and can be reflashed multiple times before they become physically unusable. If you are willing to pay a premium then you can get a more reliable brand but there are no guarantees that the specific model you bought is reliable. Usually corruption happens in combination with sketchy micro USB cables and power adapters (micro USB compatibility isn't actually a great benefit). Smartphones have batteries so the only thing that matters is that the average power sent to the battery exceeds the discharge rate. A temporary voltage drop for a fraction of a second can ruin the stability of your SBC and corrupt the SD card in the process. eMMC is non replaceable, therefore it has to be more resistant against power loss. Corrupting eMMC can turn the entire device into a paperweight.

It 100% comes from not enough amps from a power supply. The Pi will run on less than 2000ma but at some point you are going to start getting transistor level bit flips not unlike a CPU that is overclocked too high. Things like cell phone chargers also appear to work but simply cant supply a consistent current under load because they were never designed to

What's the write speed comparison for the Pi 4 and an equivalent SBC with eMMC? I'm very tempted to buy one for general purpose compute but I'm wondering if I should get the RockPro instead (inferior software support but theoretically superior performance).

I've had Odroid devices in the past. Although they by all means work as advertised, the SW support for the raspberry pi is higher, allowing more recent kernels and with more (most) of the sources available also more tinkering.

I'd recommend to settle for the lower performance unless you really really need it.

The SD controller has been improved somewhat from the older Pi models, this article has some storage benchmarks: https://www.cnx-software.com/2019/06/24/raspberry-pi-4-bench...

Odroid has some eMMC performance numbers: https://magazine.odroid.com/article/orange-emmc-module-samsu...

Though on either board the fastest storage you'll get will likely be a USB3->SATA bridge with an SSD.

A major product challenge of eMMC in a design is the requirement to supply a means of flashing data onto the storage device when the CPU can't boot from the eMMC (or the disk is corrupted).

The SDCard solves this problem fairly well (although the solution requires a reasonable level of computer literacy due to the filesystems and raw block device access needed, however its a good fit for the Pi user demographic).

Other systems solve this chicken/egg problem by having a tool that runs on a PC that can perform the programming of attached storage, often by downloading code and data into a CPUs RAM and then having it flash to the disk. Exposing JTAG to Pi customers however is a step too far and would require more expensive external JTAG hardware to be needed per customer as well.

If I was Pi, I'd put a 10cent USB stick IC onto the board that connects in parallel to the eMMC and enable the board to be plugged into any USB host and mounted as external storage. Some programmable logic (get one of the Silego 10cent programmable logic ICs) would be needed to prevent the USB from being mounted when the system was running - I'd probably add in a button or switch that is read at power on and determines which interface gets to see the eMMC. It would need to hold either the Pi chip or the USB IC in reset depending on which function was selected.

A second option would be to put an USB eMMC protocol stack into the BootROM, but this would need LittleKernel or something similar in the BootROM and its non-trivial to get right!

They could go the "Android way" and have a fastboot of sorts to boot software like a recovery OS to reflash the main os.

I believe fast boot relies on having a stable, on PCB storage device (eMMC or NAND) to ensure that the recovery method doesn't have any opportunity to get wiped / trashed. Using an SDCard doesn't ensure this and thus something in hardware would be needed instead.

Ive been running raspberry pis on sd cards for years and really haven't had any issues. And if I did have an issue I’d just fire up a new sd card and dd the disk image back on.

It’s actually one of the great features of the PI IMO, having the ability to quickly swap disks and reboot. Reminds me of the computers and video games of yesterday.

I agree, as long as you store everything permanent on a centralized database then being able to fix a node in a cluster is just a card swap.

This! When I saw a new Pi was announced with multiple models I dearly hoped for one with optional reliable on board storage. The MicroSD card is easy to use, but just not remotely close to reliable enough as the only kind of onboard storage for many use cases.

I migrated a few years ago to the ASU’s Up! Board - same dimensions, GPIO, general layout as a Pi but with quad core atom, 32GB onboard storage, 4gb of ram and “proper” gigabit Ethernet. No more micro SD card failures (I’m aware usb and network boot exist for the Pi but does not fit my needs).

This Pi 4 ticks all of those boxes except for the storage. So close to a truly great little home server device.

They will need to offer a 64-bit kernel then. It's unfortunate that even the newest Raspbian for the Pi 4 is still 32-bit, both kernel and userland.

Not necessarily: Physical memory and virtually addressable memory are two different things. See for example https://en.wikipedia.org/wiki/Physical_Address_Extension. Not sure how that works on the Pi though.

which causes its own problems with kernel & drivers, and your processes are still only 4gb per process aware unless you play windowing/segmenting games.

64bit is the solution, pae was a huge hack when 64bit wasn't ready yet.

ARM does support LPAE and I think the linux kernel does too for ARM: https://lwn.net/Articles/415190/

I've never seen it in use though!

The Pi 4 is an ARM64 device that they're still running in armhf mode?!

Haven't the RPi's all been ARM64 since the Pi 2?

Yes, the 2/3/4 are all 64 bit. The Zero/Zero W are the same old 32 bit ARM11 hardware as the original Pi. Raspbian is still armhf but there are several aarch64 distros available (Arch, Fedora, Debian) for the recent Pi models.

RPi2 is 32-bit ARMv7.

All RPi3 models are ARMv8 (Cortex A53).

Anything a little more upscale but similar in spirit to the Pi 4?

E.g. at around $100 or $200?

Depends what you mean by "similar in spirit", but there are a smorgasboard of single board computers and self-contained computers out there at a multitude of different price points.

If you're looking for just a small computer, the Intel NUC is a good place to start.

I really like Hardkernel's Odroid boards. They have a big catalog for many use cases and are a lot more performant than the Pi but less open hardware/driver wise and lack on board WiFi/BT. But as others have said, there are A LOT of similar boards. If you want something very small, the NanoPi boards look nice but I have never tried one of them.

Beyond the OrangePI boards at the same price point as RPi, I like the UP boards which use x86 compatible chips for that $100-200+ bracket, you get good, fast, processors with decent memory options and don't have to screw about with weird android-orientated hardware.

Slower CPU than the Rpi4, but the Jetson Nano's GPU makes for a reasonable desktop experience. $99

Also, a refurb Asus Chromebox would be around $150 if you want x86.

Software support (up to date distro, timely security parches to kernel, reasonably unbuggy drivers et ) is usually the weak point of arm boards. Even raspbian traditionally lags a bit there but most other boards are worse. You are probably better off with low end x86.

How about a used lenovo m92p

Basically every Atom board ever.

Nano Pi T4 $109 [1]

6-core, 64-bit, 4GB ram, EMMC, GbE, Wifi5 (AC), HDMI 2.0 (4k), USB3

Best software besides Rasberry I've seen is from these guys. Great build quality too.

1: https://www.friendlyarm.com/index.php?route=product/product&...

Given all the efforts to cram Visual Studio Code onto the Pi (because kids learning the basics of programming need a "modern" development environment), an 8 GiB Pi would actually make that practical.

I cross-compile to ARM all day long. The idea of editing and building on the target completely eludes me. I guess I shouldn't worry - it's job security.

Recently I tried to cross-compile a Qt application. With differences in the moc executable between host (x86 debian) and target (rpi3), I couldn't quite get things to work (with cmake as build system).

Do you have any tips?

moc is run at compile, and it runs on the host. You shouldn't need to run it on the target.

I'd get a complete toolchain from ARM's developer website, then build the entire Qt project for cross compilation on the host. Then you should be able to build the complete Qt app on x86 and deploy on ARM.

Not everybody uses the Pi for IoT. It was originally intended to be a child's primary computer and an educational tool. Being able to do useful programming work on the Pi itself is an important use case.

Then why wasn't that ready with version 1?

You're correct that it was originally an edu tool. It isn't anymore.

It still is, albeit that's not its only use. Your assumption that no one should ever need to write or compile code on the Pi is wrong on its face.

Ive always thought getting kids to write code on the prior generations of Pi was the fastest way to turn them off programming. Kids aren’t stupid, they can tell the computer is horrifically slow and not much fun to use as a desktop computer.

It’s a truly terrible development desktop machine. It’s great fun for deploying the projects you built on a even vaguely modern other computer that doesn’t lag just dragging an IDE window around, but I sure as heck wouldn’t want to actually develop the code on it.

I’m curious to see if the extra power offered by the 4 meaningfully changes this, but I don’t think it’s going to change my own habits.

I just fired up VS Code and it looks like it's using around 300MB. No doubt that's a lot, and it will go up as I actually use it, bit I'd still think you could get by with with much less than 8GB.

That'll grow fast when you also have chrome/ff, node, and rsync running right behind it. It can be done on 4GB, but its a lot more comfortable on 8.

Reply on news.ycombinator.com