Very unfortunate that their in-house developed and promoted OS ("Raspbian") only supports armv7, thus leaving the vast majority that doesn't know about the existence of (or how to use) archlinux ARM an the likes with a 32 bit os. Am I the only one that doesn't get the sense out of this here? Debian supports Aarch64 out of the box I think.
The other day, there was a person who had a "reddit gold" bounty for the first person who can help them get the Pi 0 online. The person basically couldn't get the Pi Zero on the wireless network. They had no USB-OTG adapter or mini HDMI adapter they could use to debug the Pi Zero. I was thinking something along the line of making the Pi USB port a USB-serial gadget, but it was still cumbersome. The "accepted solution" was to pull out the SD card for the Zero, put it into a Pi3B they had, get the 3B online, and put it back to the Zero. I think that was such a brilliant idea.
Making it easy for users to achieve such tasks is often overlooked by us who "know too much" to not care about the efficiency of the new hardware. I don't think it was an accident that the Pi is so ubiquitous in education: They made a lot of right decisions to make their product easy to use.
I have yet to find it - you can get them cheap, but no where near what the RPi Foundation advertised them at when they first were announced/launched.
Several online places have them for $5, but shipping 'kills the deal' as they say.
They also sell the normal RPi3 for $29.99 instead of $35.
[1] https://www.vilros.com/shop/raspberry-pi/raspberry-pi-zero-w...
You can very easily† pop in an ArchLinux ARM AArch64[0] in there and notice that you only get a very basic framebuffer, sound is just not working at all, and the bootloader is quite incomplete. So ARMv7 it is for me, even with ArchLinux ARM and in spite of my wish for better FOSS support from Broadcom or in Linux mainline.
† I find alarm much much better as a distro than raspbian as it's incredibly straightforward to install, maintain, and use, while vanilla debian is downright painful.
[0]: https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-...
Most x86 boxen tend to run tons of proprietary firmware but at least that isn't pinning me down on ancient hacked-up kernel trees.
Doesn't the firmware run on VideoCore anyways, so why would its bitness matter?
Closed ARM-side libraries are of course a different beast.
You get 3D accelerated Wayland or Xorg with the open source VC4 driver!
People who actually have a use for 64bit on their pis will generally know what to do, and I'm guessing most of of them won't have a whole lot of use for the streamlined UX that is Raspbian's raison d'etre, anyway.
Don't most ARMv7 CPUs (like A7, A15, etc.) have 1 TB address space? On LPAE ARM, 64-bit arch will only get you larger virtual address space, but you get same 40-bit address space in both cases.
> reduction in memory consumption that comes with pointers that are half as big
Nothing prevents you from running 32-bit binaries on 64-bit OS, as long as you have 4kB page size.
I can see having a bit of headroom for virtual memory, but I wouldn't want to actually use it. The non-volatile storage on this computer is an SD card, so paging will be particularly expensive. Are you really going to have more than 3GB of swap? That's a pretty big appetite for thrashing.
Regarding running 32-bit binaries on 64-bit OS, sure, and the code that lives in those binaries will run faster. But you'll still be needlessly taking a hit on the 64-bit kernel and userland.
Looks like I should have communicated it more clearly.
AArch64 does have some perks, but mostly for out-of-order cores, which RPI3's Cortex A53 is not.
That said, even A53 can benefit from 31 registers in 64-bit mode. Large virtual address space is nice not only for memory mapping files, but to do lazy initialization while keeping high performance direct pointer access characteristics. That way you can have the MMU doing the check and indirection for you instead of slow explicit conditional check in code.
You can mitigate pointer size by ensuring memory accesses are PC-relative. Perhaps there could be support for something similar to x32 ABI [0] as well.
AArch64 codegen does need to generate more conditional jumps or CSELs (like cmove) though. Also function entry & exit code is larger due to lack of LDM & STM (load/store multiple). But on the other hand, stack spills are rarer, thanks to 31 general purpose registers instead of 14 on 32-bit ARM.
Where AArch64 truly shines is when you have a real out-of-order CPU core, for example Cortex A72. There are significantly more opportunities for instruction level parallelism due to dropping instruction predicates and other changes.
https://libre.computer/2017/12/03/performance-and-power-cons...