Hi Conor, On Sat, Jul 8, 2023 at 12:53 AM 葛士建 <geshijian@xxxxxxxxxxxxx> wrote: > > > > > On Sat, Jul 8, 2023 at 12:16 AM Conor Dooley <conor@xxxxxxxxxx> wrote: >> >> Hey, >> >> On Wed, Jul 05, 2023 at 07:42:51PM +0800, Yunhui Cui wrote: >> > Add the description for ffitbl subnode. >> > >> > Signed-off-by: Yunhui Cui <cuiyunhui@xxxxxxxxxxxxx> >> > --- >> > .../devicetree/bindings/firmware/ffitbl.txt | 27 +++++++++++++++++++ >> > MAINTAINERS | 1 + >> > 2 files changed, 28 insertions(+) >> > create mode 100644 Documentation/devicetree/bindings/firmware/ffitbl.txt >> > >> > diff --git a/Documentation/devicetree/bindings/firmware/ffitbl.txt b/Documentation/devicetree/bindings/firmware/ffitbl.txt >> > new file mode 100644 >> > index 000000000000..c42368626199 >> > --- /dev/null >> > +++ b/Documentation/devicetree/bindings/firmware/ffitbl.txt >> > @@ -0,0 +1,27 @@ >> > +FFI(FDT FIRMWARE INTERFACE) driver >> > + >> > +Required properties: >> > + - entry : acpi or smbios root pointer, u64 >> > + - reg : acpi or smbios version, u32 >> > + >> > +Some bootloaders, such as Coreboot do not support EFI, >> > +only devicetree and some arches do not have a reserved >> > +address segment. Add "ffitbl" subnode to obtain ACPI RSDP >> > +and SMBIOS entry. >> >> Since the conversation on this stuff all seems to be going absolutely >> nowhere, the ACPI portion of this is intended for use on RISC-V in >> violation of the RISC-V ACPI specs. It also goes against the >> requirements of the platform spec. Quoting from [1]: >> >> | > Just so we're all on the same page, I just now asked Mark Himelstein >> | > of RISC-V International if there is anything in RISC-V standards that >> | > requires UEFI, and the answer is a solid "no." >> | >> | Huh? Firstly, running off to invoke RVI is not productive - they don't >> | maintain the various operating system kernels etc. >> | Secondly, that does not seem to be true. The platform spec mandates UEFI >> | for the OS-A server platform, alongside ACPI: >> | https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#32-boot-process >> | and the OS-A embedded platform needs to comply with EBBR & use DT: >> | https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc#32-boot-process >> | >> | EBBR does say that systems must not provide both ACPI and DT to the OS >> | loader, but I am far from an expert on these kind of things & am not >> | sure where something like this where the DT "contains" ACPI would stand. >> | >> | The RISC-V ACPI spec also says "UEFI firmware is mandatory to support >> | ACPI": >> | https://github.com/riscv-non-isa/riscv-acpi/blob/master/riscv-acpi-guidance.adoc > > UEFI firmware is mandatory to support ACPI and coreboot is an option to support ACPI as well. i think it works well for both, I don't think UEFI and ACPI need to be binding together, each UEFI and ACPI also works well with other solutions. Thanks for shijian(Nill)'s suggestions. Hi Conor, Thank you very much for your valuable comments on this set of patch codes, which are very helpful. Judging from the current specifications, maybe yes, you can NACK, but it's better not to rush to conclusions. The so-called specifications represent the ideas of FFI opponents. What we have to do is to discuss with them and get an effective consensus, so as to achieve the purpose of updating the specification. >> >> >> >> NAKed-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> >> >> Cheers, >> Conor. >> >> [1] - https://lore.kernel.org/linux-riscv/20230707-attach-conjuror-306d967347ce@wendy/ Thanks, Yunhui
