Hacker News Reader

Comment by publicmail | Hacker News Reader

Maybe a dumb question but how do non x86 boards normally boot Linux images in a generic way? When I was in the embedded space, our boards all relied on very specific device tree blobs. Is the same strategy used for these or does it use ACPI or something?

View on HN

All RISC-V consumer boards running Linux also use DT. RISC-V is also working on getting ACPI but primarily for the sake of servers, just like with ARM where ACPI is primarily used for servers (ARM SBBR / ServerReady).

ARM Windows laptops only use ACPI because Windows has no interest in DTs, but under Linux these devices are still booted using DT. I don't know for sure, but the usual reason is that these ACPI implementations are hacked up by the manufacturer to be good enough to work with Windows, so supporting them on Linux requires more effort than just writing up the DT.

> so supporting them on Linux requires more effort than just writing up the DT.

More effort then producing unique images for every board?

Yes. See https://github.com/aarch64-laptops/edk2/tree/dtbloader-app?t... for example.

It's a shame the DT approach encourages land fill of boards when the manufacturer stops providing updates.

Not necessarily. DT can be loaded separately from u-boot tree / kernel tree / dtoverlay file.

The DT should really be put in the firmware (e.g u-boot), same as ACPI on x86 is in the firmware (the bios/efi).

Then you wouldn't need a unique kernel/OS image. For devices that have u-boot in ROM the DT is usually there (fdt).

It's what the RISC-V Server TG is trying to standardize: https://lists.riscv.org/g/tech-server-platform https://lists.riscv.org/g/tech-announce/topic/public_review_...

The x86 platform uses a plethora of platforms services under different names like UEFI/ACPI/PCI/(ISA plug-n-play back in the day)/APIC (programmable interrupt controller and evolved variants thereof)/etc. that allows the generic kernel to discover what's available when it boots and load the correct drivers.

ARM servers do the same with SBSA (a spec that mandates things like UEFI, ACPI etc. support) etc. I think there's some effort in RISC-V land to do the same, also using UEFI and ACPI.

Maybe I'm wrong but isn't it what SBI[0] is for?

[0] Supervisor Binary Interface

They basically don't at the moment. RISC-V is working on ACPI and "universal discovery" as a solution but it doesn't exist yet.

I think windows ARM laptops use UEFI?

They do, Windows Phone even use UEFI (not sure was completely compliant) back in the day.

publicmail was asking about ACPI vs DT, not UEFI. Using UEFI and ACPI/DT are orthogonal; DT-using devices can also boot from UEFI if the firmware provides it. See https://github.com/TravMurav/dtbloader for example.

This is explicitly what we're doing in RHEL with the P550.

We use u-boot and it's EFI capabilities to init grub (instead of another instance of u-boot)

Why not use systemd-boot?

looks like they still require a custom device tree to boot Linux

Reply on news.ycombinator.com