I hope we can get true AArch64 support as well, for many different reasons. One is that Dolphin-emu has an AArch64 JIT but not a 32 bit ARM one. While it’s probably not terribly hard to get the Pi4 booting to 64 bit, which is actually probably good enough if you’re just interested in virtualization, I have no idea how to get the VideoCore 6 drivers in 64 bit and if I had to guess, I’d guess shit out of luck for now.

(I am not sure Dolphin-emu would run with considerable performance, but damn if I’m not curious.)

VC4 works great in 64-bit, I've had WebGL running on some browser under Weston on ArchLinuxARM on a Pi3. I would expect V3D (VideoCore 5/6) to work out of the box on 64-bit too. Mesa very rarely introduces any unportable code – e.g. RadeonSI pretty much just works on FreeBSD/aarch64 :)

Wait - is the VC4/V3D driver open source? I feel like I missed that bit.

So basically, I should just cross compile RPi Linux and Mesa and it should work?

To be honest, I have been confused about the VideoCore driver situation from day 1, but I thought it was a blob.

VC4 and V3D are open source Mesa drivers for VideoCore 4 and VideoCore 5/6 respectively. I don't remember what the proprietary driver is called.

> ...AArch64 support for the Raspberry Pi soon, especially since they have launched the models with larger amounts of RAM...

1 TB RAM supported by 32-bit ARM is not enough? I don't think increasing process virtual address size is the most pressing need at this point. Although it would help with things like WebAssembly, and anything else that benefits from mapping a lot of stuff in the address space.

The myth that you need to have 64-bit to access more than 4 GB RAM seems to still be very strong, despite not being true for a long time on modern x86 (since Pentium Pro in 1995) and ARM platforms (since LPAE designs, like 2013 Cortex A7/A15, etc.).

Of course I'd also like to get AArch64 on RPi4, but for entirely different reasons. To support double precision NEON SIMD and to get more registers to help Cortex A72 core out-of-order engine to keep the execution units busy. More registers helps to reduce dependencies, giving OoO more freedom to rearrange instructions for optimal execution.

I'm no Linus Torvalds fan, but his rant (and follow-up) on PAE explains why this is actually a terrible idea:

1) https://www.realworldtech.com/forum/?threadid=76912&curposti... 2) https://www.realworldtech.com/forum/?threadid=76912&curposti...

So cute. The times before Meltdown.

Anyways, Linus is being... Linus. He is of course right in some ways, from kernel point of view it does suck, when you can't map all of the caches and buffers simultaneously. But PAE is pretty good for a bunch of large processes.

actually, the host OS for this post is a ubuntu 18.04.2 server image.

root@pi:~# cat /etc/issue.net

Ubuntu 18.04.2 LTS

root@pi:~# uname -a

Linux pi 4.19.57-v8+ #2 SMP PREEMPT Tue Jul 9 20:31:37 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

root@pi:~# file /bin/ls

/bin/ls: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-, for GNU/Linux 3.7.0, BuildID[sha1]=de05fcef79d88af9cf9a71ed38e73af0b179bfb2, stripped

Wait - what did it take to get 18.04.2 server running?

Is there an SD image that works?

baking one right now -- it is based on http://cdimage.ubuntu.com/ubuntu/releases/18.04.2/release/ub... but slightly modified (no root password, KVM setup, docker installed etc.)

will provide a link once I manage to upload it somewhere

there you go: https://cloudkernels.net/rpi4-64-bit-kvm-docker.img.xz sha1sum: 1b96a6be5256182eaceb5894fb993c8ffce8c2a2

it's quite beefy, 2.5GB -- apologies for that. We should be able to craft a much smaller image based on the ubuntu server release. Apparently, something was off about mounting the root partition on the first boot, so we went with our original image.

Ok, so I must be a bit thicker than the rest, but what's the login? I tried ubuntu with no password, as well as root with no password, as well as root/root, and root/admin, and the default pi/raspberry, but to no avail.

What am I missing here?

hmm I'm pretty sure its root with no password... you can edit /etc/shadow and remove the 2nd field on root and ubuntu and try again just in case

I just tried root with no password, didn't work for me. I am getting bounced. Rewriting the SD card one more time...

Ok, so I am deeply confused. DOwnloaded the image, the SHA1sum is correct. Unpacked the image, wrote it on an 32GB SD card from Samsung. I am booting from an RPI4 with 4GB of RAM. Are the 4GBs the issue? I can ssh to it, it will send me its public key, and I can give the login and the password, but providing "root" as login and hitting enter upon the password gives me this:

C:\Windows\System32>ssh -l root 192.168.178.184 [email protected]'s password: Permission denied, please try again. [email protected]'s password: Permission denied, please try again. [email protected]'s password: [email protected]: Permission denied (publickey,password).

root w/o password won't work for me. How is anyone else connecting? I am using SSH.

password-less SSH is not supposed to work, use a console cable or just inject your SSH key to /root/.ssh/authorized_keys and it should work.

built a stock ubuntu (cloud-init ready) image: https://cloudkernels.net/ubuntu-18.04.2-preinstalled-server-... sha1sum: 0b1d8b72ea5410fb7928925fd76dd0218b4f7a94

The behaviour should be identical to installing on a RPi3 (user/pass ubuntu/ubuntu, ethernet networking setup correctly etc.)

Ubuntu Mate has an image that works on the Pi3.

That's what the article is about. Also openSUSE (and SLES) run in 64 bit mode on a RPi 3 by default without issues, using a mainline kernel and FOSS userspace (no proprietary /opt/vc stuff).

Shortly after the Pi 4 was released I looked into it and found that, for the Pi 3 at least, the foundation weren't really interested. It essentially adds another distro for them to maintain. It's a shame.

It's not like anyone is forced to use their distro. It's newbie-oriented and extremely annoying for Unix geeks anyway (Debian base with its always-outdated packages, etc)

You don't even have to run Linux at all. FreeBSD/aarch64 works great on a Pi3 (as a headless server at least, VC4 is not ported)

How is Debian annoying for Unix geeks? If outdated packages are an issue, you can always install stable backports, or stuff from testing/unstable.

True but the newbies will slowly drift away from all the projects that don't want to split focus from aarch64.