Hi Björn, On Wed, Jul 5, 2023 at 10:43 PM Björn Töpel <bjorn@xxxxxxxxxx> wrote: > > 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)? In fact, in the v1 email, Coreboot's maintainer Ron has made it clear that Coreboot does not support EFI, and it is necessary to transmit firmware information through DTS on RISC-V. @Ron, can you help explain it to them? > 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. Thanks, Yunhui
