Not exactly true. ARM server chips do have ACPI. The trick is buying a CPU that is SBSA[1] and SBBR[2] compliant. Then most things work as expected.
[1] https://static.docs.arm.com/den0029/a/Server_Base_System_Arc...
[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0044d/Se...
It's not hard to acquire something with an ARM CPU on it, but at prices an ordinary person can afford, they're all in the category of toy computers. Try to find an affordable ARM system with a M.2 2280 NVME SSD slot on it like you can find on a $100 desktop x86-64 motherboard. Or multiple PCI-Express 3.0 x8/x16 slots.
I've previously spent many years working for a hardware manufacturer. Personal theory is that this is a real example of a chicken or egg problem related to economies of scale. Nobody wants to spend dozens of millions of dollars tooling up to produce ARM socketed CPUs and motherboards and stuff, which may or may not be price/performance competitive with current-gen Intel and AMD stuff by the time it's ready for release. And there's a huge risk in manufacturing something like that and then discovering that the sales volumes are really low.
Look at the sheer massive quantities that the top-ten Taiwanese motherboard manufacturers churn out every year.
> You can wipe pretty much any Android device (not just phones, but also HDMI "streaming boxes", which are a convenient form-factor for basing a workstation on) and install Linux on them
No you really can't, and phones aren't servers. Take any modern $600 smartphone and try installing something very close to a stock debian or centos on it. Being able to maybe boot a Linux kernel on something doesn't mean that there's anything like the market demand for that particular hardware platform target for a whole distribution.
Because ARM is a design licensed to companies that want to make their own chips for their own purposes. Those purposes involve optimizing cost by choosing, per product, whether to integrate various cores onto the SoC, or to leave them as external devices on the board, or to maybe put them into a secondary chipset microcontroller and route some IO pins to connect the two.
In ARM designs, the licensee determines the required pin-out, because the licensee determines what the CPU does vs. what the board does. You can't really have a generic "ARM board", because no two "ARM CPUs" would have the same expectations for what are on that board.
A particular ARM licensee could standardize the socket between their own designs—but in doing so, they'd lose a lot of the advantage of licensing vs. buying an off-the-shelf chip in the first place.
https://www.youtube.com/explainingcomputers is a good YouTube channel for reviewing these types of single board computers.
There's Qseven [1] and SMARC [2].
1 https://en.m.wikipedia.org/wiki/Qseven
2 https://en.m.wikipedia.org/wiki/Smart_Mobility_Architecture
We have reached the point where shipping 1.2B Smartphone per year is called massive, comparing to 200M PC market where 150M of those are laptop ( Soldered and non Socketed ).
You cant buy a self made ARM PC. But there will be Qualcomm ARM Laptop. And the AWS ARM CPU are based on ARM N1 Design, it is only a matter of time somebody make the same CPU, or System integrator selling CPU made from other ARM CPU vendor such as Fujisu, Ampere, Huawei, Marvell, or possibly Nvidia and others.
I dont see much of a problem in getting ARM access as consumers.
Google, which has previously collaborated (OP1) with Rockchip on Chrome OS.
The ARM equivalent to ACPI is ACPI.
ACPI is not "between the board and CPU", it's "between the OS and the computer". Which is actually much more important. Writing drivers for bespoke PCIe, USB and SATA controllers is not fun. ACPI standardizes configuration of these things.
Eh, kinda-sorta. ACPI (through the availability of a DSDT in BIOS flash) provides whatever's running on application processors (like CPUs, but also independent coprocessors like mobile baseband processors and server baseboard management controllers) the ability to 1. query "the board" for what's effectively a listing of the available busses, and the devices on those busses; and 2. to initialize those devices with wired address-space regions on those busses, such that nothing conflicts.
Now, certainly, ARM boards that have standardized "network-like" peripheral busses like PCIe, USB, or (maybe) SATA, have an ACPI controller on the SoC, to schedule those devices' address-space regions onto those busses.
But not all ARM devices have those busses. Some are entirely embedded, with the ARM core serving more of the function of a microcontroller than a true application processor. (There are ARM cores in keyboards and mice!) And some—especially cheap—consumer ARM "platforms" only have busses like SPI and I²C. (You know, like an Arduino!) Even older fully-featured ARM "computers", like smartphones and portable game consoles, didn't support ACPI until very recently, either (which is much of why devices like the 3DS and PSVita didn't support Bluetooth or USB OTG HNP.)
In either case, these devices more-often-than-not don't have ACPI controllers, instead "hard-wiring" each peripheral device on the board to a certain address-space range on a certain bus available to the CPU, just like PCs used to do before there were even IRQ jumpers. (One clear example: every Nintendo portable since the GBA was an ARM SoC, but none of them until the Switch have had ACPI. They just had a static IO memory map, that you could program against.)
And even those ARM devices that do have an ACPI controller on-board, almost universally don't use it the way that x86 does, where even chipset-specific devices like Platform Controller Hubs get probed and configured by ACPI rather than just sitting statically on a special bus.
I'm not sure what you're calling "an ACPI controller". (You seem to be thinking of MMUs and PICs??)
ACPI is a software interface. The tables are the ACPI. It's possible to implement ACPI on a system that originally shipped with U-Boot and Flattened Device Trees. Say, for the Raspberry Pi: https://github.com/tianocore/edk2-platforms/tree/8b72f720d53...
But most ARM devices aren't using it - their closest equivalent is the device tree.
Nope, the PostmarketOS project is actively trying to make this feasible. It's quite non-trivial and heavily device-specific.
Our current approach is using the Allwinner A20 processor. Investing quite a bit of work in a free driver for the h264 encoding block on there (cedrus vpu).
It was an honest question if we had overlooked something obvious...
That page is a bit out of date, I think the support has improved since then.
https://uefi.org/sites/default/files/resources/ACPI_2.0_Supp...
The difference between ARM and x86 is that there's no standardized ARM interface between the motherboard and the CPU—no ARM equivalent to ACPI. Every integration of an ARM CPU into a board is bespoke. So you have to buy "a board with an ARM CPU on it", not just an ARM CPU and board separately.
But, if you relax that restriction, it's not like it's hard to acquire "a board with an ARM CPU on it." 80% of single-board computers (e.g. the Raspberry Pi) are "a board with an ARM CPU on it." You can wipe pretty much any Android device (not just phones, but also HDMI "streaming boxes", which are a convenient form-factor for basing a workstation on) and install Linux on them. There are also some higher-end development/SDK boards for ARM embedded systems, like the Nvidia Jetson. What more do you need?