
What is wrong with all those AArch64 desktops? - djsumdog
https://marcin.juszkiewicz.com.pl/2019/10/23/what-is-wrong-with-all-those-aarch64-desktops/
======
ohazi
We don't have AArch64 desktops because it's not possible to build an AArch64
motherboard. There are no standard sockets -- and every ARM vendor starts
their system using a proprietary, inscrutable Rube Goldberg machine. On the
Raspberry Pi, the _GPU_ starts the processor for crying out loud.

~~~
incompatible
I'm not sure that the standard socket is so important. I don't remember ever
changing the CPU on a motherboard: by the time significantly better CPUs are
available, they need a different socket.

An AArch64 desktop could be built in the same way that the Raspberry Pi was
built, just with a higher spec CPU and more connectors.

~~~
ohazi
You're right about the socket, but the problem is that every chip/board
basically needs a custom bootloader - you can't just plug in a USB stick with
a Debian AArch64 installer and go to town, you need a custom packaged blob
from the vendor, which usually comes with their own blessed Linux distribution
(e.g. Raspbian), and you're out of luck if that doesn't meet your needs.

If this model works for you, then yeah, a Raspberry Pi or a similar board
could work. I've been hearing pretty great things about the new Pinebook Pro
laptop.

~~~
incompatible
Anything that requires binary blobs just to boot seems fishy. You'd think one
driver per chipset would be sufficient, and it should be open source.

I suppose in the AMD/Intel world, all these binary blobs are built into UEFI.

~~~
shawnz
Doesn't UEFI also support aarch64? Why can't vendors use that?

~~~
gsnedders
Windows 10 requires UEFI support, so any ARM device that supports Windows 10
uses UEFI.

~~~
solarkraft
Hey, that's wonderful. What I had read before pointed to every device having
some weird undocumented mess.

But: Is the bootloader even unlockable to install alternative software?

~~~
gsnedders
> But: Is the bootloader even unlockable to install alternative software?

IIRC, MS require the device to support Secure Boot, but whether or not you can
disable it or whether you can add other signing keys is undefined (and I have
no idea what vendors do). (Originally the requirement was it must be always
enabled and only the OEM could add keys, but that has since changed.)

~~~
timthorn
There's a port of Ubuntu available. It isn't yet complete but it does boot on
Windows on Arm devices.

[https://github.com/aarch64-laptops/linux](https://github.com/aarch64-laptops/linux)

------
cesarb
The author's description of what is a "desktop system" sounded a lot like a
"no true Scotsman" to me. I've had several desktop systems that didn't meet
all of the author's criteria - in fact, I've had desktop systems that met
_none_ of these criteria. And these systems did meet what most people would
consider to be "desktop systems": box shaped, designed to be put over or under
the desk, tethered (no built-in battery other than the RTC battery),
internally expansible (not all-in-ones or NUCs), with a x86-32 or x86-64
processor, and booting with traditional BIOS and/or UEFI.

~~~
wolrah
I disagree, the author's description matches the majority of x86 motherboards
in production, and if you were to wander in to a random computer store and ask
for a standard desktop PC you'd be led to an array of machines that met all of
those requirements. If it's not "small form factor" it almost certainly checks
all the boxes.

I agree with the author, what AArch64 (or any alternative architecture) really
needs to be taken seriously for more than "toy" or "appliance" type use cases
is a real desktop board that an interested party could swap in place of the
motherboard of one of their old PCs without having to invest in a pile of
adapters.

To me, that means the following:

* Standard ATX or MicroATX formfactor * Standard ATX power input * At least two standard DIMM or SODIMM slots, preferably four * At least 32 lanes of PCIe 3.0 or greater, exposed as at least one x16 and one x4 slot plus one x4 M.2, leaving eight lanes for onboard accessories or more slots as desired * At least two SATA channels, preferably four * At least one copper gigabit ethernet interface * At least six USB 3.0 ports, preferably more and faster. * Onboard audio sufficient for watching Youtube or participating in a VoIP/videoconference call.

Since I'm pretty sure that providing video from power on rather than after the
OS loads requires support in the video card itself, onboard video of some sort
is probably also a requirement for now as well. Specifics don't matter, but it
should be able to handle an accelerated desktop and video decoding.

~~~
timthorn
So something like this?
[https://e.huawei.com/en/products/servers/kunpeng/kunpeng-
des...](https://e.huawei.com/en/products/servers/kunpeng/kunpeng-desktop-
board)

~~~
wolrah
Yes, that does seem to be pretty much exactly what I'd want out of an ARM
desktop platform. It would be nice if they'd offer more cores in the desktop
variant of the board, and anything that has a "contact us for pricing" link
annoys the crap out of me, but it does meet the specs.

------
TD-Linux
If you want a non-x86 desktop, but not AArch64 in particular, I'd recommend
looking at the Talos POWER9 systems instead. I have a Talos II Lite, and my
only two complaints (less pcie slots with only a single socket, and no built
in sata) were solved with their new Blackbird motherboard. It's gotten closer
to the desktop experience than any AArch64 computer I've tried, and in some
ways it's even better (petitboot is awesome).

~~~
Koshkin
But in all fairness, why would anyone just "want a non-x86 desktop" (as in:
"anything but x86"). Doesn't make sense to me...

~~~
Symmetry
It can be useful to test code that's supposed to be portable on a system with
a weaker than x86 memory model.

And a self-synchronizing instruction stream can be a security advantage and a
fixed instruction width means Power and AArch64 are trivially self-
synchronizing. And really just not having the dominant ISA is a pretty big
security advantage in some cases.

I'm pretty sure that neither of those is a huge deal for most people but I can
see wanting it.

~~~
AnimalMuppet
ELI5: How, specifically, does AArch64 have a "weaker than x86" memory model?

~~~
asveikau
When multiple cores access the same memory location, it is expensive for one
core to invalidate the cache of another or ensure operations don't get re-
ordered in either core. These days most architectures when reading or writing
shared data require memory barrier instructions to guarantee your core to sees
writes from another, or other cores to see your writes, in a timely sequential
fashion like we expect when writing code that accesses variables.

Historically there were architectures that would reorder these accesses in a
"lax" way, making very few guarantees about what you will see from another
core, on the theory that it will cost less to keep things synchronized between
cores (most data is not shared anyway, so why waste work trying to create a
unified view across cores? The CPU can also reorder work for better
efficiency.). Intel is historically one of the most conservative, strict-
ordering architectures, requiring fewer barrier instructions and creating the
illusion that reads and writes more or less occur on a single timeline.

See also:

[https://en.wikipedia.org/wiki/Memory_ordering](https://en.wikipedia.org/wiki/Memory_ordering)

------
zamadatix
I think the Jetson AGX Xavier is probably a better match out of the box to the
requirements than anything listed on that page. The only thing it doesn't meet
is the plus on 16+ GB of RAM. For the same price you could get a much better
x86 desktop though.

\- 8 core CPU

\- 16 GB LPDDR4x

\- Volta based GPU

\- Gig ethernet (native)

\- PCIe x8 (x16 physical slot)

\- m.2 E key (PCIe wireless or LTE)

\- m.2 M key (PCIe NVMe SSD)

\- 2 USB 3.1

\- HD audio header

\- eSATAp through PCie bridge (allows native 2.5" SATA drives)

But really there isn't really much reason to use ARM on a desktop outside of
needs relating to specifically needing to have ARM.

------
joecool1029
I'm trialing using AArch64 for desktop use. I bought a Raspberry Pi 4 4GB
desktop kit awhile back and it sucked in the beginning. So I did what most
people do with their pi; that is to leave it unused and unplugged like a
Nintendo Wii.

Finally after the firmware fixes came about to improve cooling a few months
ago and it was advised to just run the thing set up on its side, I decided to
revisit running a 'desktop' on it.

Raspbian, as most people know, is 32-bit and the idea is you can plug the
microsd card it into any model of pi ever made and it'll run. This sucks for
performance and you can't run a version of firefox made the past few years.
Chromium isn't an option on a 4GB ram system, it's just not.

I eventually settled on using sakaki's gentoo pi64 build and it was fairly
painless to get running. Unfortunately, she hasn't kept the build up to date
and there's a lot of weird customization she performed to get things running
in the early days.

Anyways aside from having it run some compiles overnight and finding a new
binhost to pull prebuilt stuff from, it runs pretty well. Actually better than
my Intel Atom powered GPD Pocket (as it does not throttle ever). All the
hardware works, and I've had no video issues since switching to the 5.4
kernel. It checks most of the boxes that OP asked for aside from the RAM being
limited to 4GB. Unlike more powerful options on the market, it's got a wide
release and a low price point so developers will be working on it.

So yeah, there's your AArch64 desktop you can buy today that everything works
on for around $50. If you want to improve performance a bit more for IO,
there's SSD/nvme adapters for it, and while I'm unsure about hooking into
pci-e, the device has it...

Oh, and the audio thing is dumb as hell to complain about. Just output the
audio through HDMI to your receiver and call it a day. What's the big friggin
deal that the desktop lacks a 7.1 analog output. If you want high quality
headphone audio, USB audio is practically plug and play on any OS these days.
I don't get it.

~~~
zamadatix
Ubuntu is probably the way to go on the Pi if you're looking for
compatibility. The 32 bit version is ARMv7 instead of ARMv6 with HF packages
as Raspbian is. The 64 bit version is ARMv8. It's an official version from
Canonical so you don't have to worry about some person abandoning their build
or compiling your own packages all the time. With the newer CPU in the Pi 4
it's possible for them to support >4G models in the future but they aren't
really interested in targeting $100+ use cases so it'll never make a "great"
desktop. Useful as a fanless device that can run standard code though.

If you hack into PCIe you'd lose the USB. It's only a single x1 connection. I
suppose you could hack a PCIe switch on top of that but even so it's x1 so it
was already oversubscribed just hosting the USB 3 interfaces.

~~~
HeWhoLurksLate
IIRC, If you hack into PCIe, you only lose USB 3.0, because the USB 2.0 ports
are directly connected to the SoC.

------
selimnairb
Just wait until Apple releases a Mac mini powered by an A-series CPU. If I had
to bet, I’d say this will be the first Arm Mac they will release. This way
developers can easily buy one for porting their apps before A-series-based
MacBooks are released.

~~~
AndrewStephens
I am going to go out on a very short limb and predict that Apple does no such
thing in the foreseeable future, say 3 or 4 years. In the past, Apple has only
transitioned to a new architecture once it was so powerful that it could
easily emulate older hardware. Apple doesn't care about backwards
compatibility as much as Microsoft on desktops but even they cannot release a
new desktop/laptop that doesn't run existing software.

Although ARM processors are fast in certain benchmarks, they cannot compete
with x86 for performance and certainly cannot emulate the instruction set at a
speed users would find acceptable.

ARM makes great sense for low power devices and _maybe_ servers. Apple already
makes tons of the former and seems uninterested in the later.

~~~
fmajid
My iPad Pro is as fast on single-thread as all my Intel desktop machines, and
2/3 on multicore. In a non-thermally throttled enclosure, I would expect it to
outperform.

[https://browser.geekbench.com/user/122632](https://browser.geekbench.com/user/122632)

~~~
Macha
Right, but 1-2x perf is not nearly enough to naively emulate a system.

~~~
ridiculous_fish
Rosetta was not a naive emulator. It was a dynamic, optimizing re-compiler.

There's two reasons to think that an ARM transition would be easier:

1\. The endianness is the same. The PPC/Intel transition required processes to
share memory while disagreeing on byte order.

2\. Apple controls their ARM CPU designs. They can add whatever they like.

~~~
andrekandre
right, and

3\. rosetta only emulated the actual app binary; eventually it called in to
native libs, so performance for the most part held up really well iirc (for
apps, not sure about games)

------
ChuckMcM
Sigh, no definition of what a "desktop" would be. That would be a start. Does
it have to have "on board audio" ? All my early desktops up through the
Pentium 3 used an add in card (typically a Soundblaster) to provide audio. So
why make it the "requirement" for a desktop? Graphics? All graphics were "plug
in" in early desktops until transistors got so cheap you could throw one into
the southbridge for "free." The list goes on.

It would a much better exercise to create a systems design document for what
an AArch64 desktop should have, required, extras, and nice to have. Start
there and work forward, not at a full fledged PC desktop with 30 years of
evolution behind it and start there.

~~~
haerwu
Extra PCIe x1 slot on mainboard would be fine instead of on-board audio.

------
tyoma
Desktop and workstations will be the _last_ place to find non-x86 chips. Power
use doesn’t matter, and critical consumer applications and raw performance are
a must.

Its much more exciting to see what will happen with laptops and (in cloud)
servers.

------
Jonnax
I had some representatives from ARM and NXP come and give a demo of some ARM
boxes.

Now these were in the context of white box customer premises networking
equipment, but what I found quite interesting was that these machines all
supported UEFI.

There's certainly an effect to have some standardisation for ARM machines.

But who knows when it'll get to the desktop.

~~~
cameron_b
Yea I think the model here (especially since the article seems to really be
conflating "desktop" with "High end desktop" especially in terms of the Arm
ecosystem ), will be that we do see these features developed from the server
side first, and then given the "content creator" treatment. I don't think that
this is bad as the article implies. Rocking the top of the HEDT market is good
for magazine covers, but it isn't exactly where the profits are. Filling
datacenters will fund the work that we're interested in -- namely the robust,
expandable, systems that have the muscle and the mainstream features that make
for a cushy desktop experience.

But also, Aren't we still complaining about linux on the desktop?

~~~
blattimwind
> and then given the "content creator" treatment

Content creation is done almost exclusively through proprietary software
that's heavily optimized for a given platform, so this would be one of the
worst markets to tackle first with an _architecture change_.

------
sam_lowry_
On a related note, I just got my Pine64 Pinebook Pro, and it's much better
than my beloved Samsung xe303c12 in all apects. Lightweight, FHD screen
resolution. No need to fiddle with the OS.

~~~
fmajid
I'm still waiting for mine, it seems like the most viable option for someone
who wants to develop for armv8 Linux. I had the original PineBook and found it
disappointing, how would the PineBook compare to, say, a MacBook Air?

~~~
sam_lowry_
Screen bleeding is an issue. Otherwise, a great small laptop.

------
anfilt
Honestly, would like to see more RISC-V offerings instead of 64bit arm.
Although the ISA is still relatively new. Also some the extensions like bit
manip are not finalized. However, the base instructions are.

~~~
solarkraft
I'd love to have a RISC-V tablet one day, but think ARM will be an
intermediate step, which will, through gained experience and already built
infrastructure, ease the second switch of ISA.

~~~
anfilt
Like on the open source side things, it's already possible to run a RISC-V
desktop. Problem is no cheap hardware outside some expensive dev boards.

[https://abopen.com/news/building-a-risc-v-
pc/](https://abopen.com/news/building-a-risc-v-pc/)

Also that thing does not have up-gradable RAM, but you do have PCI-E.

------
magicalhippo
His list of requirements for a "desktop system" is ok for a developer desktop
PC, but for most people it's complete overkill.

The RPi4 running Raspbian is just a tad short of being perfectly acceptable
for users like my GF. It's just a tad sluggish, so either a bit more
streamlining of the platform, or a bit beefier CPU and GPU and it would be
just fine for her.

~~~
zamadatix
The lack of quality storage interfaces is a killer too. Pi 4's still eat SD
cards and even when they don't it's not exactly speedy. USB to mSATA/m.2 SATA
adapters provide a step up but it's still quirky and you still need a
functioning SD card to boot to it with the current firmware.

~~~
yjftsjthsd-h
Needing an SD card to boot is especially annoying because the pi 3 did have
the ability to boot from USB and I _think_ network with no SD card present.

EDIT: To be clear, non-SD boot on the pi 4 "will be added in the future via
optional bootloader updates"[0], so hopefully this is a temporary complaint.

[0]
[https://www.raspberrypi.org/documentation/hardware/raspberry...](https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md)

~~~
T3OU-736
Not for everyone's setup, but network booting the Pi's is an option [1].
Probably not wireless, but it may be something.

Bonus points for the instructions using a Pi as a server for this setup.

[1]
[https://www.raspberrypi.org/documentation/hardware/raspberry...](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md)

~~~
yjftsjthsd-h
That's for pi 3; I don't think it works on 4 (yet)

~~~
zamadatix
Network boot is in the beta firmware now. USB boot is still a ways off.

------
Koshkin
Looks like Odroid N2 is as close as it gets to an AArch64 desktop. (Still not
a true Scotsman though.)

~~~
reggieband
I've recently been recommended YouTube videos by ExplainingComputers and that
channel introduced me to the new breed of SBC (single-board computers)
including the Odroid. One of the more recent videos is for the Khadas VIM3 [1]
which was a very interesting ARM based SBC.

I am blown away these days by the power of these cheap and small boards. I
just don't have any use for them right now and I know I would tinker with them
for a few days then they would end up in a drawer collecting dust.

[https://www.youtube.com/watch?v=ryTykjUbJIs](https://www.youtube.com/watch?v=ryTykjUbJIs)

------
qwerty456127
> 4U rack/tower case sounds clearly like “we know it is server but will try to
> sell it as a desktop”. No m.2, no audio, no mention about USB ports, no 1GbE
> network.

Isn't every server meant to have a 1GbE port nowadays? Dont most of the
servers have m.2?

And for PCIe slots - aren't those extensible with raisers?

> That system was kind of Frankenstein’s monster. Audio over some USB stereo-
> only dongle, all USB devices plugged into hubs due to only two ports on
> mainboard I/O panel.

Perhaps one could just put a USB hub and the audio dongle inside the actual
case?

~~~
toast0
Maybe some of these have SFP+? 10G only interfaces that need a transceiver.
That would be a pain in a home setup.

~~~
qwerty456127
Perhaps. But I haven't actually seen servers with SFP+ 10G on-board. All the
servers we buy have a classic 1GbE RJ-45 built-in and we extend them with SFP+
10G PCIe adapters when needed.

~~~
haerwu
AArch64 servers tend to have 10G (or faster) SFP+ ports rather than 1GbE.

------
timthorn
Don't be afraid to get in touch with Avantek to ask what you need to know.
They're very friendly, in my experience.

------
tomc1985
Every time I've tried to run AArch64 like a desktop (mostly via ODROIDs), it's
been an exercise in misery. Endless tweaking, and almost always an important
service, like 3D graphics or audio, doesn't work. Last I checked the driver
situation there is just lacking

~~~
watchdogtimer
Support for the Rockchip RK3399-based boards seems pretty good. Audio and
wireless on my NanoPi M4 have worked flawlessly for me. No problem playing
YouTube videos, either, even at 1.5x speed. Editing 3D CAD files using Freecad
in Debian 10 has also worked great.

The only things I miss are being able to run the latest versions of some
software, which are often compiled only for x86 or MacOS. For instance, I'm
currently stuck on Debian's Firefox ESR (currently Firefox 68.4) because
Firefox doesn't offer precompiled binaries for AArch64 on Linux.

------
zmix
Why would one want an ARM desktop system (except if (s)he is an ARM
developer)?

For my desktop I want as much power as money permits. And the most important
thing is ergonomy, since I rather invest into my eyes and wrists than into the
silicon.

~~~
watchdogtimer
I use a pedal-powered computer. For me, every watt counts.

My desktop system is a NanoPi M4 and a 16" Sceptre monitor. The combined
system draws a total of about 6.5 W. Granted, there are some laptops that come
near that level of power consumption. I simply like the form factor of a
desktop PC.

~~~
danbolt
That sounds really interesting. Would you have more information on such a
setup?

------
qubex
I really wish somebody would produce a single-board system with a Qualcomm 865
or 8cx processor, NVM support, and PCIe.

------
LargoLasskhyfv
No OpenFirmware? No good!

------
bhouston
Raspberry PI 4 runs with 1 4k monitor pretty well and has audio and you can
attach peripherals.

It is desktop like.

Arm desktops are just single board computers. Why? Because that is all you
need.

If you want to assemble overprice parts yourself to get marginal benefits
stick with x86.

The truth is the market for desktops even in the x86 market has shrunk
considerably because there are few benefits except if you are rendering and
even then you should be using cloud compute in that case.

~~~
Jonnax
If I'm rendering, I should use cloud computing?

Like an artist is supposed to use a remote desktop to do 3D modelling? Or an
engineer doing CAD? Or a video editor creating 4k video?

There are a lot of professionals that need powerful computers. Not everyone
just needs a text editor to write their SaaS application.

~~~
jdietrich
_> If I'm rendering, I should use cloud computing?

Like an artist is supposed to use a remote desktop to do 3D modelling? Or an
engineer doing CAD? Or a video editor creating 4k video?_

Yes. High-end workstations are effectively obsolete for professionals rather
than prosumers, it's just taking some IT departments a while to catch on. All
those workloads are highly bursty and involve substantial collaboration, which
makes virtualization a natural fit. I haven't tested and wouldn't necessarily
recommend a Raspberry Pi as a client terminal, but it just doesn't make sense
any more to put a really powerful machine under everyone's desk rather than
having a rackload of servers as a pooled resource.

[https://www.nvidia.com/en-us/design-visualization/quadro-
vdw...](https://www.nvidia.com/en-us/design-visualization/quadro-vdws/)

------
pcwalton
Without mention of Apple's plans for MacBooks, I don't buy this doom-and-gloom
prediction. Remember that everyone thought AArch64 was DOA right up until
Apple released an iPhone using it, and then all the other manufacturers
instantly followed suit. I wouldn't be surprised if Apple is the first to
release a mainstream AArch64 desktop/laptop, and then everyone else follows
them.

~~~
loeg
It's vaporware until it exists. Sure, Apple seems to have the strongest ARM
CPU at this time. It remains to be seen if they can single-handedly create an
entire arm64 PC ecosystem.

~~~
fmajid
I suspect they'd start with their server farms, just as Amazon is doing with
its own ARM AWS instances based on the Graviton SOC it bought when it acquired
Annapurna. Amazon is on record saying they are going to migrate their internal
services like ELB over to ARM.

