On the discussion for ARM64 servers using ACPI or DT, I think it's important to look at the bigger picture beyond just stating that things need to be done one way or the other. The way I see the server market (somewhat simplified), we have four main markets at the moment:

1) Microserver: $100-$1000, 5W-50W power consumption, highly integrated single-socket or SoC, usually ARM or x86, sometimes still MIPS or PowerPC, usually Linux with custom distros and marketed as NAS or networking appliances.  Dreams of hyperscale computing to replace PCs.

2) PC-Server: $1000-$10000, 50W-500W, one or two sockets, Intel Xeon territory with a few Opterons left, running Windows or any Linux distro, commodity off-the-shelf products with no vendor value-add.  Internally very similar to the average laptop computer with extra CPU cores for performance and ECC memory added in for reliability but few of the interesting "enterprise" features. Huge revenues but all the hardware profits go to Intel.

3) Enterprise server: $10000-$100000, 500W-50KW, 4 or more sockets, running RHEL, SLES, AIX, Solaris, HP-UX or Windows. Typically using Itanium (HP, Huawei, previously Supermicro, SGI, NEC, Bull and others), Power7 (IBM, Bull), SPARC (Oracle, Fujitsu), Xeon E7 (all of the above plus Cisco, Dell and few more) and very few remaining Opteron 6xxx (Dell, HP, Supermicro).

4) Mainframes and supercomputers (ignoring PC clusters): $100000+, 10KW+, Running SLES, z/OS, or custom OSs, great margins (at least on mainframes) but produced in tiny amounts by only a handful of companies.

The argument that is normally made in favor of ACPI is that everybody is used to category 2 COTS servers which all use ACPI. However, there is no way for ARM to actually enter that market, since by definition it's not the same kind of commodity: you cannot swap out a Dell server with an ARM based machine and keep the same software installation the way you could when replacing it with a Lenovo server.

Instead, what needs to happen is that a) ARM SoC based micro servers get better with the migration to 64 bit and start eating the PC server market from below or b) we see real ARM64 enterprise servers stir up the (shrinking) Unix/Itanium/RISC market by being cheaper with the same features and having a story for moving people off of their current installed base. My impression is that a number of companies are trying one or the other, sometimes both at once with different product lines.

When you are coming from the SoC angle, that debate has been resolved years ago: Basically all SoCs from the past few years that we support in Linux have some degree of DT support (the other ones are using board files), across ten CPU architectures.  The only serious attempt to use ACPI on an SoC that I'm aware of so far was the Minnowboard support from +Darren Hart. While that shows that it can be done in principle, the patch set also shows where infrastructure is missing in practice and this is still a rather PC-like system. Doing the same for an SoC that shares its device drivers with another ARM32, PowerPC or MIPS SoC (or an embedded ARM64 product) that has existing DT support would be a rather pointless waste of time and probably get rejected by a number of subsystem maintainers.

For the enterprise systems, things look a bit different, as the market is split in two factions: PowerPC and SPARC use an IEEE compliant Open Firmware, so they pass a device tree, while Xeon and Itanium are tied to the Intel/Microsoft world and use ACPI. The natural thing to do for faster time to market is to keep using whatever platform you are coming from. If you take an existing Itanium design and replace the CPU with an ARM64 chip, you probably want to keep ACPI to allow reusing your device drivers, while replacing the SPARC CPU a different server with an ARM64 chip would make an Open Firmware DT the natural choice. For completely new designs, it should not make much of a difference as long as the system is reasonably PC-like and not an SoC, but I'd suggest using an open firmware DT for consistency with the low-end world.
Shared publiclyView activity