Hacker News Reader

Comment by vetinari | Hacker News Reader

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.

View on HN

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).

Reply on news.ycombinator.com