Jessica Clarke <jrtc27@xxxxxxxxxx> writes: > On 3 Jul 2023, at 19:58, Emil Renner Berthing <emil.renner.berthing@xxxxxxxxx> wrote: >> >> On Mon, 3 Jul 2023 at 15:33, 运辉崔 <cuiyunhui@xxxxxxxxxxxxx> wrote: >>> >>> Hi drew, >>> >>> On Mon, Jul 3, 2023 at 9:01 PM Andrew Jones <ajones@xxxxxxxxxxxxxxxx> wrote: >>>> >>>> >>>> (This is a reply to a non-existent cover letter.) >>> >>> This has been discussed many times with Ard, Please refer to : >>> https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyunhui@xxxxxxxxxxxxx/ >> >> Hi Yunhui, >> >> From that discussion it was mentioned that that arm supports 3 methods >> of booting: >> direct + devicetree >> EFI + devicetree >> EFI + ACPI >> ..but not >> direct + ACPI >> >> To me it isn't obvious from that or this thread, and since arm seems >> to be doing fine without the 4th option I'm curious why that's >> necessary on riscv? > > If anything we should be removing option 1, because that’s not a > cross-OS standard (though RISC-V’s SBI direct booting is at least not > tied to the OS). Any application-class platform spec is going to > mandate EFI, because, whatever your thoughts of EFI are, that is *the* > standard. And if you’re willing to pick up all the complexity of ACPI, > what’s a bit of EFI (especially if you only go for a minimal one a la > U-Boot)? Well said! Yunhui, why not simply add a minimal UEFI stub to Coreboot (like Jess points out above)? IMO what U-boot (or https://github.com/cloud-hypervisor/rust-hypervisor-firmware if you're into Rust ;-)) is doing, and just having a small UEFI shim is the way to go.
