The CPU of the Raspberry Pi 4 is the only 64-bit ARM chip I've ever seen that doesn't include native AES instructions. As a result, it's much lower performance for network or disk encryption use cases.
Up until the RPi 4 I thought AES instructions were a part of AArch64, but I was wrong. Such a weird omission to make on (I expect) Broadcom's side. All other 64-bit ARM SBCs just have it, even the low cost ones.
They are a recommended extension.
I expect that the crypto instructions are not present on the RPi3/4 because of legal reasons, to allow it to be exported to Iran and such...
One of the main benefits you get to running a proper aarch64 userspace is ability to run a modern functional firefox install. The 32-bit builds usually don't support anything newer than a very old LTS release. It's been hell trying to build and/or run that target (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1452128 )
This is especially important if considering use as a low-end desktop as Chromium will eat through 4GB of ram like it's nobody's business.
Where can I get it? I didn't think Mozilla offered a precompiled version for aarch64 Linux. I've been using an the Debian ESR release (68.0.5) from the Armbian repository on my NanoPi M4.
One of the things that I find great about Raspbian is that the boot files are stored on a FAT32 partition which is readable from any OS, and there are some nice considerations for headless setups: drop in a wpa_supplicant.conf to configure Wi-Fi, `touch ssh` to get OpenSSH enabled at next boot. Do any of the alternative OSes, like Ubuntu, offer this?
I recently installed Arch Linux on my Pi Zero, it also uses FAT32 for the boot partition. I did the initial setup the way you described. Check out https://archlinuxarm.org/ , it's pretty great.
So that's how they came up with that. As someone who normally installs "normal" Linux systems I find it quite irritating that you have to put a file somewhere, especially the boot record, to "enable" ssh of all things. Up until now I considered it a weird decision. (and I still think it is not optimal) I deploy my RPi's in the field and don't put a monitor on them so I would expect ssh running as default. First time I found out about it was when reading the unit file when I was building a custom image based on raspbian, so I wouldn't consider it obvious :) When working on a Linux Device I just mount the main partition and do my customizations.
One downside: you will probably need a bit more memory to do the same work. An unmentioned benefit: better ASLR, for what that's worth.
> A 64 bit system means that RAM can be accessed in 8 byte read/writes per instruction.
I mean...kind of but that's probably not really what's happening in this benchmark. Firstly, in that test `memset()` is surely using NEON instructions internally on both ARMv7 and AArch64, which can load/store up to 32 bytes in a single instruction. Further that test is really just showing the bandwidth of the memory controller. I'm not sure why AArch64 would matter there. It's possible that `memset` / `memcmp` are using smarter prefetching instructions in AArch64.
Noob question: What kind of optimizations are even responsible for those kinds of performance improvements?
32 bits is enough to utilize all 4 GB of the Raspberry Pi4, so I figured the only benefit of using a 64 bit OS would be to support 64 bit software. Why would a 64 bit build perform better than a 32 bit build on the same hardware?
Slightly off topic, but kind of on theme at least: does anyone know where to get an SBC (single board computer) with 6GB of RAM... or even 4.5GB (that doesn't cost like $~300)? The raspberry PI is almost perfect, I just need slightly more ram per unit.
There are a few more. You could also build your own.
All you need is a micro ITX motherboard + ram and a processor and something to power. Get them used and it will be way more powerful.
I've also customised the image by adding users, public keys and such. Removing some of the cloud cruft.
These instructions make it very, very easy and you can do this on an x86 machine. Just make sure to use /usr/bin/qemu-aarch64-static (64 bits) instead of qemu-arm-static (32 bits).
The flipside is-- if you have a 1GB pi, you're going to be wasting a whole lot of RAM on wider pointers, and you may be more constrained by RAM than CPU throughput.
(Also, 64 bit Pi is not nearly as well supported as 32 bit currently. Does hardware GL work yet? What about if you're going to do MIPI, etc?) IMO it's worth waiting for a little more maturity.
I realize I'm a little late to the party as this post is almost a day old, however as a Pi enthusiast I feel obligated to mention RackN's edgelab [1] project which leverages Pi4's PXE boot to rapidly build a 64-bit mini Pi lab and then a k3s cluster on top.
Full disclosure: I don't work for RankN but am a customer; my use case is zero-touch ESXi cluster and Linux builds but I like the tool and have way too many Pis.
I’ve been running Ubuntu on most of mine for a while now, but I go back to Raspbian now and then for the hardware support (graphics, in particular, are a bit of a pain, but I’ve also had issues with the built-in Wi-Fi). My “lab” Pi 4 is on Raspbian also because I like noodling in Mathematica (which I don’t think you can get in ARM64 at all for any distro).
It would be awesome to have a decent ARM64 SBC with a good GPU (able to drive 2 4K monitors and run Firefox/VS Code). Any recommendations from the non-Pi crowd?
Has anyone gotten the aarch64 Raspberry Pi image of Alpine to work on the Pi 4? It seems like a good fit for a RAM constrained system but I could never get it past the colorful boot screen.
It's fairly easy to trim down what runs on Raspbian. so if your only concern is background tasks eating RAM, you don't need something like Alpine to fix that issue. We use Pis at my work for running slideshows, and while performing their duty they use about 123MB of RAM for all running software (mostly our software + monitoring tools).
As far as I'm aware, ilp32 support for aarch64 has been proposed and implemented, but the patches weren't accepted upstream in the kernel because nobody was able to make a sufficiently convincing case that there was enough benefit to justify adding a whole new ABI to the kernel (there are a few benchmarks where it's noticeable but mostly it just doesn't make enough difference to be worthwhile, AIUI). Possibly the situation has changed since I last heard about it.
> I think the main issue keeping the pi with a 32b userspace is the lack of availability of 64bit GPU firmware
Uh, no. It's there because of the design goals and priorities of the Foundation. They want to be able to distribute a distribution that runs on any raspberry pi generation. Performance is of secondary concern to them. So Raspbian remains at 32-bit.
The fully open source driver stack can't some soon enough. (yes I know firmware files still exist, but they don't prevent you from running a 64 bit kernel and userspace)
[+] [-] DCKing|6 years ago|reply
Up until the RPi 4 I thought AES instructions were a part of AArch64, but I was wrong. Such a weird omission to make on (I expect) Broadcom's side. All other 64-bit ARM SBCs just have it, even the low cost ones.
[+] [-] fulafel|6 years ago|reply
A Pentium II 200 MHz could saturate 100 Mbps with AES-128[1], RPi4 has 4 x 1400 MHz cores (with 64-bit ALU & NEON available).
[1] https://www.di.ens.fr/~granboul/recherche/AES/timings.html
edit: There are RPi4 AES and other benchmarks here in this "openssl speed" paste: https://gist.github.com/HimaJyun/f05d3017dfb05a4ccb0def010bb... - indicates 50-80 MB/s = 400-640 Mbps per core.
[+] [-] my123|6 years ago|reply
[+] [-] MikusR|6 years ago|reply
[+] [-] joecool1029|6 years ago|reply
This is especially important if considering use as a low-end desktop as Chromium will eat through 4GB of ram like it's nobody's business.
[+] [-] drmpeg|6 years ago|reply
$ dpkg -l | grep firefox
ii firefox
73.0.1+build1-0ubuntu0.18.04.1 armhf
Safe and easy web browser from Mozilla
[+] [-] watchdogtimer|6 years ago|reply
[+] [-] rgovostes|6 years ago|reply
[+] [-] koralewski|6 years ago|reply
[+] [-] 4d617832|6 years ago|reply
[+] [-] thrwaway69|6 years ago|reply
[+] [-] ratiolat|6 years ago|reply
[+] [-] tssva|6 years ago|reply
[+] [-] m463|6 years ago|reply
The requirement of multiple partitions, with different filesystem types causes a lot of needless complication in the configuration and boot process.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] gok|6 years ago|reply
> A 64 bit system means that RAM can be accessed in 8 byte read/writes per instruction.
I mean...kind of but that's probably not really what's happening in this benchmark. Firstly, in that test `memset()` is surely using NEON instructions internally on both ARMv7 and AArch64, which can load/store up to 32 bytes in a single instruction. Further that test is really just showing the bandwidth of the memory controller. I'm not sure why AArch64 would matter there. It's possible that `memset` / `memcmp` are using smarter prefetching instructions in AArch64.
[+] [-] m4rtink|6 years ago|reply
[+] [-] CivBase|6 years ago|reply
32 bits is enough to utilize all 4 GB of the Raspberry Pi4, so I figured the only benefit of using a 64 bit OS would be to support 64 bit software. Why would a 64 bit build perform better than a 32 bit build on the same hardware?
[+] [-] yalok|6 years ago|reply
[+] [-] cesarb|6 years ago|reply
For 4 GB of memory, 32 bits of address space are not good enough, as discussed a couple of days ago (https://lwn.net/Articles/813201/ discussed here at https://news.ycombinator.com/item?id=22440733).
[+] [-] threatofrain|6 years ago|reply
→ https://www.raspberrypi.org/downloads/
[+] [-] rubyn00bie|6 years ago|reply
ARM or X86 I really don't care...
[+] [-] thrwaway69|6 years ago|reply
Udoo - https://shop.udoo.org/udoo-x86-ii-ultra.html
LattePanda - https://www.lattepanda.com/products/lattepanda-alpha-864s.ht...
There are a few more. You could also build your own. All you need is a micro ITX motherboard + ram and a processor and something to power. Get them used and it will be way more powerful.
[+] [-] coleifer|6 years ago|reply
[+] [-] camccar|6 years ago|reply
[+] [-] 0xcoffee|6 years ago|reply
Then `sudo rpi-update`
[+] [-] echlebek|6 years ago|reply
[+] [-] louwrentius|6 years ago|reply
https://ubuntu.com/download/raspberry-pi
I've also customised the image by adding users, public keys and such. Removing some of the cloud cruft.
These instructions make it very, very easy and you can do this on an x86 machine. Just make sure to use /usr/bin/qemu-aarch64-static (64 bits) instead of qemu-arm-static (32 bits).
https://powersj.io/post/raspbian-edit-image/
[+] [-] mlyle|6 years ago|reply
(Also, 64 bit Pi is not nearly as well supported as 32 bit currently. Does hardware GL work yet? What about if you're going to do MIPI, etc?) IMO it's worth waiting for a little more maturity.
[+] [-] monocasa|6 years ago|reply
[+] [-] technofiend|6 years ago|reply
Full disclosure: I don't work for RankN but am a customer; my use case is zero-touch ESXi cluster and Linux builds but I like the tool and have way too many Pis.
[1] https://github.com/digitalrebar/edgelab
[+] [-] rcarmo|6 years ago|reply
It would be awesome to have a decent ARM64 SBC with a good GPU (able to drive 2 4K monitors and run Firefox/VS Code). Any recommendations from the non-Pi crowd?
[+] [-] kevinastone|6 years ago|reply
[0]: https://developer.nvidia.com/embedded/jetson-nano-developer-...
[+] [-] Legogris|6 years ago|reply
Then there's also Khadas VIM3.
[+] [-] zamadatix|6 years ago|reply
[+] [-] nightfly|6 years ago|reply
[+] [-] thrwaway69|6 years ago|reply
[+] [-] dsm9000|6 years ago|reply
[+] [-] lasermike026|6 years ago|reply
[+] [-] alexellisuk|6 years ago|reply
[+] [-] muth02446|6 years ago|reply
[+] [-] pm215|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] moonbug|6 years ago|reply
[+] [-] joecool1029|6 years ago|reply
Uh, no. It's there because of the design goals and priorities of the Foundation. They want to be able to distribute a distribution that runs on any raspberry pi generation. Performance is of secondary concern to them. So Raspbian remains at 32-bit.
[+] [-] Teknoman117|6 years ago|reply