On Fri, Jul 07, 2023 at 08:05:48PM +0800, 葛士建 wrote: > Hi Sunil, > > From Sunil: > IMO, if the question is generic like "Is UEFI mandatory for RISC-V?", > the answer will be solid "no" because we can use DT without UEFI. But if > you ask whether UEFI is mandatory for ACPI support on RISC-V, then the > answer will be "yes". > ---- Why UEFI is mandatory for ACPI support on RISC-V? As we know, on X86, > ACPI works well without UEFI. Is there any limitation on RISC-V > architecture? Yes, the limitation is RISC-V can not use IA-PC BIOS. Please see section 5.2.5 and 15 in ACPI spec. I don't have much to add to Ard's reasons. https://lore.kernel.org/linux-riscv/CAMj1kXFZren0Q19DimwQaETCLz64D4bZQC5B2N=i3SAWHygkTQ@xxxxxxxxxxxxxx/ > BTW, I don't think ACPI was from UEFI, and ACPI works well with coreboot on > Chromebook as Ron said. > > + Dong Wei for ARM ISA.. > > Thanks, > -Nill > > > On Fri, Jul 7, 2023 at 6:43 PM Sunil V L <sunilvl@xxxxxxxxxxxxxxxx> wrote: > > > On Fri, Jul 07, 2023 at 09:38:30AM +0100, Conor Dooley wrote: > > > Hey, > > > > > > I've tried to reformat this a bit, probably gone wrong in the process > > > somewhere. > > > > > > On Thu, Jul 06, 2023 at 02:39:13PM -0700, ron minnich wrote: > > > > On Thu, Jul 6, 2023 at 8:32 AM Palmer Dabbelt <palmer@xxxxxxxxxxx > > <mailto:palmer@xxxxxxxxxxx>> wrote: > > > > > On Thu, 06 Jul 2023 01:53:47 PDT (-0700), Ard Biesheuvel wrote: > > > > > > On Thu, 6 Jul 2023 at 04:04, 运辉崔 <cuiyunhui@xxxxxxxxxxxxx<mailto: > > cuiyunhui@xxxxxxxxxxxxx>> wrote: > > > > > >> On Wed, Jul 5, 2023 at 10:17 PM Palmer Dabbelt < > > palmer@xxxxxxxxxxx<mailto:palmer@xxxxxxxxxxx>> wrote: > > > > > >> > On Wed, 05 Jul 2023 04:42:47 PDT (-0700), > > cuiyunhui@xxxxxxxxxxxxx<mailto:cuiyunhui@xxxxxxxxxxxxx> wrote: > > > > > >> > > Here's version 3 of patch series. > > > > > >> > > > > > > > >> > > V1: The FFI (FDT FIRMWARE INTERFACE) scheme has reached a > > > > > >> > > consensus with the Maintainers. > > > > > >> > > Please refer to: > > > > > >> > > > > https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyunhui@xxxxxxxxxxxxx/ > > > > > >> > > > > > > >> > From looking at that thread it seems that the consensus is this > > is a bad > > > > > >> > idea? Sorry if I'm just missing something... > > > > > >> > > > > > > >> > > > > > >> First of all, Coreboot does not support EFI, Ron has expressed, > > as follows: > > > > > >> "I am wondering if we can focus on risc-v here, and not drag in > > ARM, > > > > > >> b/c the ARM ACPI+UEFI ship has sailed. I had that discussion in > > 2013 > > > > > >> ;-) and it's clear we don't want to redo it. > > > > > >> In general, in my world, because of the many problems that come > > with > > > > > >> UEFI (security, code quality, performance), we'd like to avoid > > > > > >> requiring a dependency on UEFI just to get ACPI on RISC-V. It also > > > > > >> seems, from other discussions I'm having, that there is some > > belief > > > > > >> that ACPI will be wanted on RISC-V. It would be nice to separate > > those > > > > > >> pieces on RISC-V; certainly they were separate for a very long > > time in > > > > > >> the x86 world (we had ACPI+SMM on coreboot laptops without UEFI > > for > > > > > >> example)." > > > > > >> > > > > > > > > > > > > There appears to be a bit of cargo cult going on here. > > > > > > > > > > > > I agree that the traditional BIOS vendors did a terrible job > > pivoting > > > > > > to (U)EFI when it became a requirement for booting Windows on x86 > > PCs, > > > > > > and coreboot did an excellent job providing a retrofit alternative > > > > > > that was more secure and robust. > > > > > > > > > > > > However, it makes sense to distinguish between > > > > > > a) the UEFI specification > > > > > > b) the UEFI reference implementation (edk2) > > > > > > c) commercial implementations created by BIOS vendors for x86 PC > > OEMs > > > > > > that do not perform any testing beyond booting Windows. > > > > > > > > > > > > coreboot decided not to implement EFI at all, which on x86 means > > > > > > booting in a mode that is similar to BIOS boot. Given how the ACPI > > and > > > > > > DMTF (for SMBIOS) specifications were already under development > > when > > > > > > UEFI was being rolled out on x86, those specs contain provisions > > > > > > defining how to obtain the ACPI and SMBIOS tables by scanning > > regions > > > > > > of memory and looking for magic strings. But this is only defined > > for > > > > > > > > > > In theory we have that in RISC-V as well: on boot we don't actually > > have > > > > > a DT pointer, but instead a "config string" pointer. That's a bit > > of a > > > > > retcon from when we were planning on adding our own firmware probing > > > > > interface, but in order to appear to have never made a mistake we > > just > > > > > said that config strings can be anything and have magic numbers to > > > > > differentiate between the flavors. > > > > > > > > > > IIUC we don't take advantage of that in Linux, though, so maybe let's > > > > > just pretend it doesn't exist? > > > > > > > > > > > x86, and only works on x86 because all x86 machines are essentially > > > > > > PCs with a highly uniform system topology. > > > > > > > > > > > > The ARM case is very different, and while I am no expect on RISC-V, > > > > > > the following probably applies to it as well: > > > > > > - there is no need to work around buggy proprietary firmware that > > can > > > > > > boot Windows but not Linux > > > > > > - there is no 'prior art' when it comes to pre-EFI boot interfaces > > > > > > except for embedded style bare metal boot where all initialization > > is > > > > > > done by the kernel (e.g., PCI enumeration and resource assignment > > > > > > etc), and this is fundamentally arch specific > > > > > > - ACPI is a rich firmware interface, and the ACPI specification > > layers > > > > > > it on top of UEFI so the OS can make certain assumptions about the > > > > > > extent to which the platform has been initialized by the time it > > hands > > > > > > over. > > > > > > > > > > > > This is why the maintainers of the arm64 and RISC-V ports appear to > > > > > > agree that ACPI will only be supported when booting from firmware > > that > > > > > > > > > > Yes, we're basically in the same spot as arm64 is here -- or at least > > > > > we're aiming to be, we've yet to even release a kernel that boots > > with > > > > > ACPI so we have no legacy compatibility yet. > > > > > > > > > > > implements the EFI specification. Note that this does not impose > > any > > > > > > requirement at all regarding which EFI implementation is going to > > be > > > > > > used: suggestions have been made on the thread to use a) a coreboot > > > > > > specific minimal EFI shim that describes the firmware tables and > > the > > > > > > EFI memory map, b) the UPL payload for coreboot, and c) U-Boot's > > EFI > > > > > > implementation. > > > > > > > > > > > > I will also note that booting according to the EFI spec is not > > > > > > fundamentally more secure or faster: I have done some experiments > > on > > > > > > arm64 comparing bare metal boot with EFI boot using a minimal > > > > > > implementation in Rust, for booting virtual machines under KVM. > > Due to > > > > > > cache maintenance overhead and execution with the MMU disabled, > > bare > > > > > > metal boot is actually slightly slower. And due to the fact that > > the > > > > > > minimal EFI firmware enables the MMU and caches straight out of > > reset, > > > > > > it is also arguably more secure, given that all memory permission > > > > > > based protections and other page table based hardening measures > > (e.g., > > > > > > BTI) are always enabled. > > > > > > > > > > > > In summary, I think it may be time to stop extrapolating from bad > > > > > > experiences with buggy proprietary x86 PC firmware created by > > > > > > traditional BIOS vendors for booting Windows (and nothing else) 15+ > > > > > > years ago. The situation is very different for non-x86 Linux > > > > > > architectures, where we are trying hard to beat some sense into the > > > > > > fragmented embedded ecosystem, where every SoC vendor used to have > > its > > > > > > own fork of u-boot that booted in a slightly different manner, > > > > > > requiring a lot of effort on the part of the distros to track all > > > > > > those moving targets. > > > > > > > > > > That's roughly where we're trying to go in RISC-V land, at least for > > > > > most software people. Everyone gets their own ISA, which obviously > > > > > causes a ton of fragmentation, but not really anything we can do > > about > > > > > that. At least we can avoid adding additional sources of > > fragmentation > > > > > from the software side of things, though. > > > > > > > > > > >> Then, a consensus was reached with Ard, that FFI can be applied > > to RISC-V. > > > > > >> > > > > > > > > > > > > For the record, I would not characterize this as consensus. What I > > said was > > > > > > - SMBIOS has very little significance to the kernel itself or > > impact > > > > > > on its internal operation, and so it can be exposed via DT in a > > > > > > generic manner; > > > > > > - ACPI without UEFI on non-x86 is a) a bad idea, and b) > > fundamentally > > > > > > broken on arm64. So b) is out of the question, but it is not up to > > me > > > > > > to decide whether or not the RISC-V maintainers should entertain > > bad > > > > > > ideas. > > > > > > > > > > IMO we have enough bad ideas in RISC-V already and thus should avoid > > > > > adding more. > > > > > > > ACPI was not originally part of UEFI. ACPI works just fine on > > > > Chromebooks, and has for 12 years, and on coreboot since 2006, > > > > without UEFI. I've integrated support for ACPI into several > > > > code bases, including Plan 9 on non-UEFI systems. > > > > > > > > As per the section 5.2.5 of ACPI spec [1], there are only two ways > > defined to locate the RSDP. IA-PC is not applicable to RISC-V and only > > other method defined is via UEFI. > > > > [1] - > > https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#root-system-description-pointer-rsdp > > > > > > I am unable to understand the claim that ACPI on non-UEFI > > > > RISC-V is a bad idea. Clearly, I am not alone. > > > > > > > > But, all that said, I get the impression that the gatekeepers > > > > are absolutely immovable on this question? > > > > > > > Perhaps the right way > > > > to move forward is to find a way to extract what we need from ACPI > > > > and move forward on systems that can function without UEFI AND ACPI? > > > > Would that be preferable? > > > > > > Isn't this exactly the type of thing that has been proposed by this > > > series, that everyone seems to be against? Or are you suggesting that we > > > would, on a DT system, read some ACPI information, and then revert to > > > being DT based? > > > > > > > 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 > > > > > > Jess, Sunil or Ard on the EBBR front perhaps, please correct me here if I > > > have got anything wrong. > > > > > IMO, if the question is generic like "Is UEFI mandatory for RISC-V?", > > the answer will be solid "no" because we can use DT without UEFI. But if > > you ask whether UEFI is mandatory for ACPI support on RISC-V, then the > > answer will be "yes". > > > > Thanks, > > Sunil > >
