> that doesn't mean much because they're actually running Linux forks

Many of these Arm SoCs are running linux forks because there are some terrible baked in drivers, and no spec associated with them. Still, that is a step ahead of the M1 as there are at least drivers that don't have to be decompiled and reverse engineered.

These drivers are baked, even if there are specs for them.

The thing is, that these SoCs have no PCIe or other enumerable bus. You (=your kernel) must know what hardware it is running on and which drivers to load without being able to ask the hardware, what is really present. One wrong POKE and the entire system can hang.

And that is on top of the problem, how to boot in the first place. There is not such thing as UEFI on these SoCs. Every single one is a special snowflake with its own special way to boot.

Hence, kernels built for specific systems, even if it is just Device Tree.

Things have gotten a lot better in ARM-land recently. It's possible to build a generic ARM kernel that will boot on a lot of hardware, as long as the bootloader passes the right device tree blob.

Most device vendors don't really have a need or incentive to use this, though. A generic kernel is much larger and wastes flash space, and most vendors don't care about running anything but their OS image on it, so they of course just build a kernel specific to their hardware.

But in theory it should be possible at some point to use a generic ARM Debian installer to install your own OS on a random ARM device, assuming the relevant drivers and device tree have been upstreamed.

This is a little out of date. Device tree exists explicitly to avoid needing a machine file for your board. Bootloaders like uboot will load your kernel and dtb together, and the kernel uses the dtb to enumerate the hardware on the system.

Again, the problem isn't that the mainline kernel _couldnt_ support these boards, is that no one wants to put in the work to bring their implementations up to the standards of the mainline kernel.

> Every single one is a special snowflake with its own special way to boot

Eh, the majority of embedded crap comes with U-Boot (sometimes built without EFI support but always with Linux image support, at least).

I've run into more than a few ARM SoCs that use custom U-Boot forks, too.

I don't think I have used an Arm SoC that _didnt_ use either a custom uboot, or some custom stage one loader (often a stripped down uboot).

Apple is a hardware vendor. How are the parts they use "non-standard"? What are the "standard" parts that Linux uses and further what consumer or business hardware has Linux indicated is standard?

It appears what should be being asked for is Apple to commit resources to natively support things like: Docker, Kubernetes, Virtualization and Linux drivers on their M1 Macs going forward.

Interfacets, it is mentioned in the article

> Apple designed their own interrupt controller, the Apple Interrupt Controller (AIC), not compatible with either of the major ARM GIC standards. And not only that: the timer interrupts - normally connected to a regular per-CPU interrupt on ARM - are instead routed to the FIQ, an abstruse architectural feature, seen more frequently in the old 32-bit ARM days. Naturally, Linux kernel did not support delivering any interrupts via the FIQ path, so we had to add that.

and many others

https://corellium.com/blog/linux-m1

It is on top of HN now https://news.ycombinator.com/item?id=25859907

The T2 chip is non-standard and unique to Macs. It affects the boot process and disk access in non-standard and proprietary ways. Apple's SMC is also non-standard, as is their UEFI implementation.

You can see a list of differences between Macs and standard PCs here: https://en.wikipedia.org/wiki/Apple%E2%80%93Intel_architectu...

Not many people want to run Linux on intel based mac because you can run Linux on a much cheaper intel machine.