The new Raspberry Pi 4

The new Raspberry Pi 4 B is here: Yihaaa!

Just one simple question: will my favorite Pi OS run it? (that’s ofcourse DietPie :smiley: )

I would also like to know if DietPi will support the new Raspberry Pi 4. As I understand the CPU is ARMv8 instead of v7. would that pose a problem?

According to Debian it should work.

2.1.2. Three different ARM ports
The ARM architecture has evolved over time and modern ARM processors provide features which are not available in older models. Debian therefore provides three ARM ports to give the best support for a very wide range of different machines:

Debian/armel targets older 32-bit ARM processors without support for a hardware floating point unit (FPU),

Debian/armhf works only on newer 32-bit ARM processors which implement at least the ARMv7 architecture with version 3 of the ARM vector floating point specification (VFPv3). It makes use of the extended features and performance enhancements available on these models.

Debian/arm64 works on 64-bit ARM processors which implement at least the ARMv8 architecture.

Also it looks like Dietpi added support for ARMv8 back in 2017

DietPi-Software | Gitea: Install updated to 1.3.1 (for new installations only). Added support for ARMv8. Now installed to
/mnt/dietpi_userdata/gitea, runs as dietpi user: … 9863#p9863

locutusweb lasy Edward
To clean things a bid up:

  • Jep RPi4 has an ARMv8 capable CPU, but this was already the case for RPi3 and even the later RPi2 models:
  • To assure compatibility of their software across all RPi models, Raspbian calls all RPi models as armhf, the RPi1+Zero as ARMv6 (with special hard-float capability) and all other models as ARMv7.
  • So theoretically Debian ARMv8 works already for quite a long time on RPi, but we stick with Raspbian as DietPi basis, as it assures full compatibility, a wide user/support space and the benefit of ARMv8 is marginal, when loosing some special compilation settings + performance-related packages from Raspbian, possibly even negative.
  • RPi4 requires a new kernel tree (v7.1+) and bootloader files. So our current image does not work. Also, due to not further mentioned compatibility reasons, Raspbian for RPi4 is only offered as Buster version. Luckly we started early to make DietPi Buster compatible :wink:.
  • Fourdee create a first DietPi image based on the new Raspbian:
  • Note that this is still experimental. On the one hand, Raspbian Buster itself still lacks some features and requires some fine tuning, on the other hand DietPi “dev” code is present on this image, which is currently in Beta, so still might need some fine tuning as well :wink:.

I’ll be playing with the Ri4, when it arrives in the next few days, as a replacement to my Xu4 which runs bittorrent/Plex.
My current plan is to install the Buster version of Raspbian then use the DietPi Prep_System script to convert. Would this be the best way yo go for now?

Jep, the new Raspbian Buster is anyway required for RPi4 support. We also created a first testing image that way:
Note that you must use the “dev” branch version of DietPi-PREP and select it there as well, until v6.25 is released, expected soon:

Received my Pi 4, Raspbian-buster is out, Debian 10 Buster is officially released.

Any updates on the DietPi version that is ready to support this - full release?

can I add a question?

how to move from stretch PI3 to buster PI4?

update on PI3 to buster and than use it on PI4?

I have the Raspberry Pi 4 Model B, 4GB version. If I install the experimental image, will I be kept on the experimental branch? What is the recommended way to install for me?

I own a Pi 4 and ysterday I flashed the experimental image based on Buster (DietPi version 6.25.3) and I have no issues! :sunglasses:

I know that in Buster NFtables replaces iptables, does the Fail2Ban dietpi-software work with this new firewall? :thinking:

bump (because i am getting a Pi4)

It’s working great. I’ve tested it and currently running it on Pi4 with Buster (DP 6.25.3). In fact, it’s working so well I locked my self out for 10 minutes this morning. I had forgotten I had changed the password! :rofl:

No, you will be converted to stable branch. You can verify this by typing;

grep 'DEV_GITBRANCH' /DietPi/dietpi.txt

If you are on stable branch it will show:


What exactly are you asking?

Sorry, no Question. I just wanted this topic to “go” to my Quick links.(your posts) :slight_smile:

I just made the experimental image the new default download. The second version of it seems to work pretty stable, no major issues reported, neither on RPi4 nor on earlier versions.
Note that there are not yet all RPi4 features supported by dietpi-config, e.g. dual HDMI or enabling 4k, but of course it can be done manually, using /DietPi/config.txt:

If you guys find time, it would be great if you could run dietpi-config > Tools > Benchmarks.
Especially the RAM speed is what I am interested in. The current uploads show even slower speed than RPi3, but LPDDR4 should be faster of course:
If you also/still find it being around 300 MiB/s write and 600 MiB/s read, then we need to check configs where this might come from.
E.g. by default we do not set sdram_freq in /DietPi/config.txt. Default value should be 3200 on RPi4 but it could be tested if this is really the case: vcgencmd get_config int or vcgencmd get_config sdram_freq
Otherwise perhaps setting it explicitly might be required for some reason:
G_CONFIG_INJECT ‘sdram_freq=’ ‘sdram_freq=3200’ /DietPi/config.txt

I just did. One problem to have in mind though is that because I also have my DNS-software (AdGuardHome, better alternative to Pihole, which I added to the dietpi-services list), before the benchmark test, Dietpi kills it so it cannot query the dns of dietpi-survey after the benchmark is complete. This means the survey result won’t be uploaded. I excluded AdGuardHome from services so it isn’t stopped before benchmark so the survey results could be uploaded afterwards. I imagine the Pi-hole users have the same problem. You would definitely get more survey data if survey was uploaded to ssh.IP instead of ssh.DNS

Anyway, results were uploaded and I’ll also post them here. It does seem like the memory speeds are a bit off.

│ Benchmarks completed: │
│ - CPU Performance : Duration = 7.54 seconds (lower is │
│ faster) │
│ - CPU Temp : Idle = 44’c | Full load = 56’c │
│ - RootFS : Write = 7 MiB/s | Read = 41 MiB/s │
│ - RAM : Write = 421 MiB/s | Read = 778 MiB/s

I tred setting sdram to 3200 like you suggested

vcgencmd get_config sdram_freq

RAM benchmark shows:

  • CPU Performance : Duration = 7.61 seconds (lower is
  • CPU Temp : Idle = 46’c | Full load = 56’c
  • RootFS : Write = 3 MB/s | Read = 41 MB/s
  • RAM : Write = 413 MB/s | Read = 778 MB/s

So no difference.

Benchmarks completed:
│ - CPU Performance : Duration = 8.64 seconds (lower is faster)
│ - CPU Temp : Idle = 48’c | Full load = 57’c
│ - RootFS : Write = 15 MiB/s | Read = 40 MiB/s
│ - RAM : Write = 357 MiB/s | Read = 667 MiB/s

with sdram_freq=3200
Benchmarks completed:
│ - CPU Performance : Duration = 8.53 seconds (lower is faster)
│ - CPU Temp : Idle = 46’c | Full load = 55’c
│ - RootFS : Write = 17 MiB/s | Read = 40 MiB/s
│ - RAM : Write = 362 MiB/s | Read = 682 MiB/s

RAM seems much lower than @aftensleuk`s test

vcgencmd get_config int


by the way… there is a Kodi 18.3 Version that I installed and it works very good
(except MPEG-2 Videos that crashes Kodi immediately I have no other problems)

I dont know if this is needed for dependencies …
but Rascas from made 18.3 for buster PI3 that I tried before (didn`t work for PI4)…

for this I added to /etc/apt/sources.list

“deb /”

with this apt key in command line: “wget -O - | sudo apt-key add -”

only for the meantime till an official version will be released…

Your rootFS speeds are great. What SD-card are you using? Because I assume that’s a benchmark measuring SD-speeds.

Samsung EVO Plus microSDHC 128 GB