6 ms·
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 spe
by publicmail 1y ago
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?
- beeflet 1y agoI think windows ARM laptops use UEFI?
- pantalaimon 1y agolooks like they still require a custom device tree to boot Linux
- ChocolateGod 1y agoThey do, Windows Phone even use UEFI (not sure was completely compliant) back in the day.
- Arnavion 1y agopublicmail 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 https://github.com/TravMurav/dtbloader for example.
- thebeardisred 1y agoThis 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)
- ChocolateGod 1y agoWhy not use systemd-boot?
- Arnavion 1y agoAll 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.
- ChocolateGod 1y ago> so supporting them on Linux requires more effort than just writing up the DT. More effort then producing unique images for every board?
- Arnavion 1y agoYes. See https://github.com/aarch64-laptops/edk2/tree/dtbloader-app?tab=readme-ov-file#why-not-acpi https://github.com/aarch64-laptops/edk2/tree/dtbloader-app?t... for example.
- ChocolateGod 1y agoIt's a shame the DT approach encourages land fill of boards when the manufacturer stops providing updates.
- Arnavion 1y agoNot necessarily. DT can be loaded separately from u-boot tree / kernel tree / dtoverlay file.
- mappu 1y agoThe 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).
- jabl 1y agoThe 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.
- skywal_l 1y agoMaybe I'm wrong but isn't it what SBI[0] is for? [0] Supervisor Binary Interface
- rwmj 1y agoIt'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-server-platform https://lists.riscv.org/g/tech-announce/topic/public_review_of_the_risc_v/109027611 https://lists.riscv.org/g/tech-announce/topic/public_review_...
- IshKebab 1y agoThey basically don't at the moment. RISC-V is working on ACPI and "universal discovery" as a solution but it doesn't exist yet.