> On the other hand, the rest of the 64-bit ARM world has largely converged on two competing standards: UEFI + ACPI (largely used by servers running Windows or Linux),
The new ARM64 laptops follow BBR so they have UEFI+ACPI, which means they can run standard Windows or Linux distributions from Red Hat / Canonical. By using device tree instead, it means other operating systems won't be able to run out-of-the-box without some modification. I can totally understand and respect the decision not to touch ACPI, I just think it might not be a great long term decision.
I spent about five minutes wandering through the doc you linked trying to figure out how they define "embedded" and gave up.
In any case I've done plenty of hairy "embedded" development stuff (kernels, uboot, weird hardware drivers, etc) but I draw the line at device trees. I may have some kind of PTSD or something but I just refuse to deal with them in any way. Of course passing a path to a compiled binary device tree is fine but I refuse to do anything else.
I've met plenty of people that have no problem with them, make a living working with them, etc but other than the niche that is device tree expertise (and income) they may be experiencing some kind of Stockholm Syndrome.
I truly hate them and while they'll likely always have a place in the (hopefully) deep deep deep "embedded" world the sooner UEFI + ACPI generally takes over in the ARM ecosystem the better.
It's not really a question of firmware support; the standards need amending to support all of this, and then OSes need to implement core support. Basically, there will never be a way to run Windows natively on Apple Silicon without someone pushing to have a pile of new Apple-specific stuff added to ACPI, and then getting Microsoft to implement support for it. The only way to run Windows on Apple Silicon without all of that happening will be inside a VM that emulates a more traditional platform.
The latter might happen at some point; m1n1 is already going to become a minimal hypervisor for experimentation, and that could easily grow a GIC-to-AIC mapper and an HVC-based PSCI implementation some day. At that point, sure, throw some ACPI tables on top and Windows will boot, with decently near-native performance (assuming someone writes all the actual peripheral drivers, of course). Just not really natively. Incidentally, we're making all of our bespoke driver code dual-licensed (MIT/GPL), so people are free to take it and port it to BSD, Windows, or what have you.
Of course, Windows already works in QEMU today under M1 macOS (with emulation of the rest of the hardware as variants that Windows supports), and it should just work on Linux/KVM modulo a silly patch that's still missing related to a smaller than typical physical address space on M1. So full-fat VMs are not a problem, but obviously that has nothing to do with the bare metal boot chain.
As a community project, we can't exactly throw stuff at the UEFI Forum to get them to go down that road and specify representations for all this Apple-specific hardware in ACPI. However, Apple is a member of the Forum, so perhaps they should be the ones to do this :-)
Mainstream Linux distributions should work fine once support trickles upstream, as we will provide UEFI via U-Boot, and any reasonably generic ARM64 kernel should support devicetree and our devices (if they don't, someone should file a bug with RH/Canonical, as it would be completely silly if they don't turn on those config options in their kernels). OpenBSD also supports DT, and is already booting on m1n1.
Edit: I've just been reminded that RH/CentOS deliberately build their kernels without devicetree support, to force vendors to implement ACPI. This is, unfortunately, also mooted by the fact that they build their kernels configured for 64K page sizes, which the M1 does not support. Those kernels will never work on M1 machines, not even in a VM; effectively they target a stricter platform subset / standard than general ARMv8-A. Presumably they do this for performance on large systems, at the cost of less efficient memory usage. Maybe if Linux ever gains multi-page-size support on ARM64...
Incidentally, there is one other platform in the same boat, that deviates from the ACPI standards (no GIC): the Raspberry Pi 2 and 3. Microsoft are using proprietary ACPI extensions and patches to core Windows code to make that work. So we'd need at least another nonstandard ACPI extension and explicit Windows kernel support added by MS to make that happen on M1.
If Broadcom of all companies switched to the GIC, I wonder if there's any chance Apple would do the same in a later chip – in a less rushed dev cycle that's not just "quickly desktopify the iDevice SoC". (Also SMMU along with the GIC…)
Of course the unfortunate reality is that there is just no motivation for them to do this. Goddamn vertical integration! But.. maybe Boot Camp could motivate this? Though so far it seems they're just pushing virtualization instead.
> build their kernels configured for 64K page sizes [...] Presumably they do this for performance on large systems, at the cost of less efficient memory usage.
My guess is that they do that to enable a larger amount of memory (very relevant on servers, which are RedHat's main target market). AFAIK, both the LPA (large physical address) and LVA (large virtual address) extensions, which allow using 52 bits instead of 48 bits for the memory address, require using the 64K page size.
On ARM it does, as I mentioned in the article (though it isn't directly useful to us, as it's too different from Linux ones).
But yeah, assuming there will be no Intel machines in Apple's line-up at some point in the future, I wouldn't be surprised if they drop out of the Forum.
They even use device tree on x86 too (in addition to ACPI/EFI). The plaintext password and user guid is passed in chosen fields for instance when boot.efi unlocks an FDE disk.
It's not supposed to be just for servers, the Arm Base Boot Requirements (BBR) require it for any non-embedded use https://developer.arm.com/documentation/den0044/latest
The new ARM64 laptops follow BBR so they have UEFI+ACPI, which means they can run standard Windows or Linux distributions from Red Hat / Canonical. By using device tree instead, it means other operating systems won't be able to run out-of-the-box without some modification. I can totally understand and respect the decision not to touch ACPI, I just think it might not be a great long term decision.