运辉崔 <cuiyunhui@xxxxxxxxxxxxx> writes: > 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. It clear that Coreboot doesn't support UEFI today. We're "arguing" that it's less work/verification adding the neccesary minimal UEFI plumbing for Coreboot, than jumping through hoops in the kernel to work around it. I'm getting some UEFI FUD vibes here. I also think that parts of UEFI is kind of ugly, but it's, as Jess says, *the* spec and honestly, a bit what's expected (Hi CXL). UEFI is a specification, and implementing the minimal requirements for UEFI is not that of a big deal. Look at Alex Graf's (et al) work on u-boot UEFI. U-boot is small/lean/open *and* manage to support enough UEFI for ACPI. The whole "Oh, UEFI is so bad, bloated, and closed" hand-wavery is a bit tiring. :-( ...these last four sections is more of a beer discussion. I'll take my "my FW is better than yours" rants elsewhere. ;-) Björn
