For this part, one question is paramount, will flattened device tree or ACPI be used? or will Linux on Apple Silicon Macs use Apple device trees?
This question is not devoid of consequences. Traditionally, Linux on PowerPC Macs directly parsed Apple device trees instead of a standardised format.
For the Apple Silicon Macs, everyone currently follows the FDT path, but being able to use an Apple Device Tree comes with a lot of advantages, especially once the number of devices starts to multiply.
Such an approach when combined with an EFI stub-like Mach-O wrapper (which is possible) would allow directly doing:
kmutil configure-boot -v /Volumes/macOS -c arch/arm64/boot/Image
nvram boot-args="root=/dev/sda1 ro quiet"
rebootfrom within macOS Recovery to get a kernel booting, without requiring third-party boot loaders.
This would also make Linux on the platform much more of a proper Mac citizen.
Edit: Jacques Fortier from Apple clarified in a tweet that the Apple Device Tree format comes with no guarantees of stability across OS releases. Changes are infrequent but Apple reserves the possibility of doing them at any time.
Based on what you’ve seen done so far by Corellium and Hector Martin, what do you think of their approaches to this? What are the pros and cons of each approach?
So far Hector Martin didn’t reach the heavyweight device tree generation part yet.
In pongoOS, there’s a minimal FDT generator, that converts from Apple Device Tree.
However, that’s very hard to programatically do for a bigger set of devices.
What Corellium does as part of Project Sandcastle is shipping their own FDTs tailored
for a specific phone model. In the long term, that’s not the nicest option.
While Linux FDTs and ADTs share a common structure and origin, and are shared on PowerPC platforms, there has been >15 years of divergent evolution in ARM. Nowadays, macOS and Linux use very different conventions for a number of subsystems, as well as completely different interfaces for many devices which are already supported on both platforms. Additionally, as you have noted, Apple makes no stability guarantees.
I had a somewhat heated argument with Alex Graf on the stream last Thursday about this, but the upshot is that I do not believe it is even remotely practical to do fully automated conversion in the bootloader, nor to massage Linux into accepting Apple DT conventions; he believes maintaining our own set of FDTs manually is too much work. And so we’ve decided to meet in the middle – we will be shipping our own FDTs, but we will build automated, offline tooling so we can quickly analyze, diff, and convert ADTs most of the way to quickly respond to new boards and devices.
The bootloader will still parse ADTs and transfer specific properties that are unique per device or otherwise make sense to programmatically convert at boot time, of course, and this is what Thursday’s dev stream was all about.