It's not the bare minimum, though. They designed an entire boot policy framework that allows you to multi-boot different OSes in different security contexts, so you can have your fully secure and DRM-enabled macOS next to your own Linux install (and even then their design maintains basic evil maid attack security, even for Linux or other custom kernels). That's more than pretty much any other general purpose platform.
Yeah, I know, and I agree that that is kinda cool. But in terms of everything else, especially in terms of standard vs custom stuff it is a very small change from iOS devices. If there was any business reason to adopt standards (say Boot Camp would've been deemed important) – they would've at least used UEFI.
UEFI by itself is not useful; we're going to support UEFI+DeviceTree in our boot chain, but it's not going to run Windows.
What you want is ACPI support if you want the platform to be compatible with higher-level ARM boot standards. Unfortunately, ACPI support assumes stuff like GIC and other hardware details. You probably want EL3 for PSCI too. But that would be a massive change to their silicon design.
So, effectively, there is no reason for them to support UEFI or any other firmware-level stuff if their chips are not compatible with Windows, which they aren't, and re-engineering their silicon to be something that could run Windows (without one-off patches from Microsoft, like they did for the Raspberry Pi which is in the same boat) would've obviously been a huge cost to them and not something they decided made business sense at this point.
Obviously Microsoft could choose to add support for these chips to Windows like we're doing with Linux, but that's on them; it requires core kernel changes that are not something you can do in drivers (last I checked Windows doesn't even support IRQ controller drivers as modules).
Well, going straight to seeing Linux output on the EFI framebuffer instead of having to develop things like m1n1 first would've been useful. Not very useful but still.
Yeah, not using the GIC is what I hate the most. If the SoC was less… custom, we could've even written our own ACPI tables (possibly useful ones depending on e.g. which particular Designware crap they used – the better DW PCIe controllers do support ECAM, etc.) and avoided having to redo all the work in every kernel anyone wanted to run…
