Hacker News Reader

Comment by ohazi | Hacker News Reader

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.

View on HN

I made this same complaint about Android/ARM a while back[1]. ARM is just random shit soldered to random pins. I wish Microsoft would open source all the drivers to their dead phone line, since at least that had ARM+UEFI. I suppose there's DeviceTree but .. honestly that's just laughable and I've seen very few boards even release a correctly configured/working device tree.

[1]: https://battlepenguin.com/tech/android-fragmentation/

ARM defines SBSA and SBBR as the standard boot environment for servers, so you can take a Windows ARM ISO or a RHEL ARM ISO and boot either on the same server hardware. Desktop ARM - were there to be any demand for it - could support the same standard.

All the Avantek desktops do.

Those workstations use server motherboards.

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.

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.

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.

Totally agree! You'd think that vendors would agree too, since it makes it strictly easier for engineers to use their chips and design them into higher value products.

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

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

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?

> 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.)

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

All ARM Servers need to be SBBR compliant. Which means UEFI+ACPI so each Linux distro just boots and works.

SBC market is completely different thing. But that blog post was not about them.

In addition to the custom bootloader mentioned above, this would require significantly more SKUs. Many combinations of motherboard and CPU in use at the moment would probably not even make it to market.

> We don't have AArch64 desktops because it's not possible to build an AArch64 motherboard.

For the most part, this doesn't matter. Most SoCs have all the features you want. Though, the article is specifically bemoaning lots of missing I/O. I think most vendors think that the USB connectivity is a big wildcard. But, I agree - NVMe would be nicer than mmc/SD, that's for sure.

> every ARM vendor starts their system using a proprietary, inscrutable Rube Goldberg machine.

This does matter, a lot. It matters so much that we didn't change how x86 booted for ~3 decades after the AT. ARM is trying to change things for their server products, at least [1]. I'm curious just how complicated/expensive the minimal product that satisfied this platform is. Could you still do it with SoCs in the same tier as the Raspi/ODROID/etc? Server-in-name-only?

[1] https://developer.arm.com/architectures/platform-design/serv...

Every Intel vendor starts their system using a proprietary, inscrutable Rube Goldberg machine as well. This isn't the problem here.

In the x86 case, it's proprietary to Intel, and the blob for each generation is universal across products using that generation of CPU. That blob then loads up a standard higher-level firmware that presents a uniform environment to operating system bootloaders. ARM boards don't boot with a blob from ARM, but with a blob from the particular SoC vendor, and everything after that point is unpredictable and unstandardized.

Oh, there's a few more levels of proprietary nonsense you didn't even mention. There's the chipset initialization, which is proprietary to either Intel or AMD (depending on which vendor you're using). But that doesn't even come straight from the CPU manufacturer; it's baked into the firmware provided by your motherboard vendor, which typically includes a bunch of middleware from a third party BIOS manufacturer like AMI. And all of it is all completely proprietary, and highly specific to the particular motherboard you're using, even though most of the hardware is all identical across boards and manufacturers.

It's not quite as bad as you make it out to be. The early init stuff comes from the CPU manufacturer and is merely included verbatim into the firmware packages distributed by the motherboard vendor.

The UEFI environment is a mashup of modules from the CPU/chipset manufacturer, a BIOS vendor like AMI, and sometimes stuff from TianoCore/EDK. The end result is specific to each board model, but most of the modules going into the UEFI implementation are either universal/hardware-agnostic, or uniquely determined by the choice of components on the motherboard (primarily the chipset and superIO). The only stuff here that's excessively messy and error-prone is the ACPI tables.

The configuration UI is particular to the board vendor. The UI necessarily has some tweaks for each particular model, but vendors share most of the code and visual design across the entire product line. Occasionally, it's possible to skip the silly UI and fall back to the default old-fashioned text mode standard configuration UI provided by AMI or whoever.

It is actually, but it requires AMD or Intel to care. AMD could easily make an AArch64 CPU that is x570 compatible, it would require a BIOS update for sure but they could do it. There is nothing Physically stopping them from making a CPU with all the interconnect bits needed and a ton of AArch64 cores... other than there is really no fiscal incentive to do it.

AMD did (briefly) sell ARM64 chips, the Optero A1100, aka "AMD Seattle" CPU

- 4 or 8 Cortex-A57 cores at 1.7 or 2Ghz

- support for up to 128 gig of either DDR3 or DDR4 memory

- 14 SATA 3 ports

- 2 10GbE ethernet ports

- 8x PCI-E 3.0

(EDIT: Fixed formatting, sorry!)

I regret not getting one of these when SoftIron was selling theirs

Wouldn't it be better to start from the server side? IIRC they at least have UEFI over there.

> On the Raspberry Pi, the GPU starts the processor for crying out loud

What does this mean? Where can I read more about this?

On Raspberry "GPU" (VideoCore processor) is the main processor. ARM CPU is secondary in some sense.

Here's a good overview:

https://thekandyancode.wordpress.com/2013/09/21/how-the-rasp...

https://raspberrypi.stackexchange.com/a/10595

Total noob, but. Could someone come up with a standard socket and build adapters?

Cost. Standardizing is expensive.

Linaro has gone a step out from a "socket" to define board spec and mezzanine connectors.

Arm has a lot more variation than general purpose computing in the processor / SOC / SOM implementation, that is indeed the main appeal on the small end of the scale

Reply on news.ycombinator.com