Re: [External] [PATCH v2 1/3] riscv: obtain ACPI RSDP from FFI.

[Björn Töpel]

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.