Am 14. Oktober 2020 02:13:41 MESZ schrieb Atish Patra <ati...@atishpatra.org>: >On Tue, Oct 13, 2020 at 4:33 PM Heinrich Schuchardt ><xypron.g...@gmx.de> wrote: >> >> Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra ><ati...@atishpatra.org>: >> >On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt >> ><xypron.g...@gmx.de> wrote: >> >> >> >> Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra >> ><atish.pa...@wdc.com>: >> >> >This patch adds all minimum mandatory requirements to make RISC-V >> >> >compatible >> >> >with EBBR. >> >> > >> >> >Signed-off-by: Atish Patra <atish.pa...@wdc.com> >> >> >--- >> >> > source/chapter1-about.rst | 42 >> >+++++++++++++++++++++++++++++++-- >> >> > source/chapter2-uefi.rst | 10 +++++++- >> >> > source/chapter3-secureworld.rst | 13 ++++++++++ >> >> > source/references.rst | 4 ++++ >> >> > 4 files changed, 66 insertions(+), 3 deletions(-) >> >> > >> >> >diff --git a/source/chapter1-about.rst >b/source/chapter1-about.rst >> >> >index 3db3f3280448..6927c87a125f 100644 >> >> >--- a/source/chapter1-about.rst >> >> >+++ b/source/chapter1-about.rst >> >> >@@ -152,9 +152,10 @@ operating system. >> >> >SBBR is targeted at the server ecosystem and places strict >> >requirements >> >> >on the >> >> > platform to ensure cross vendor interoperability. >> >> >EBBR on the other hand allows more flexibility to support >embedded >> >> >designs >> >> >-which do not fit within the SBBR model. >> >> >-For example, a platform that isn't SBBR compliant because the >SoC >> >is >> >> >only >> >> >+which do not fit within the SBBR model. For example, a platform >> >that >> >> >isn't SBBR compliant because the SoC is only >> >> >supported using Devicetree could be EBBR compliant, but not SBBR >> >> >compliant. >> >> >+EBBR also supports multiple architectures such as AArch64 & >RISC-V. >> >> >However, RISC-V >> >> >+is not compatible with SBBR. Thus, a EBBR compliant RISC-V >platform >> >> >would not be SBBR compliant. >> >> > >> >> >By definition, all SBBR compliant systems are also EBBR >compliant, >> >but >> >> >the >> >> > converse is not true. >> >> >@@ -228,6 +229,43 @@ This document uses the following terms and >> >> >abbreviations. >> >> > Original Equipment Manufacturer. In this document, the final >> >device >> >> > manufacturer. >> >> > >> >> >+ RISC-V >> >> >+ An open standard Instruction Set Architecture (ISA) based >on >> >> >Reduced Instruction >> >> >+ Set Architecture (RISC). >> >> >+ >> >> >+ HART >> >> >+ Hardware thread in RISC-V. This is the hardware execution >> >> >context that contains >> >> >+ all the state mandated by the ISA. >> >> >+ >> >> >+ M Mode >> >> >+ Machine mode is the most secure and privileged mode in >> >RISC-V. >> >> >+ >> >> >+ S Mode >> >> >+ Supervisor mode is the next secure mode where virtual >memory >> >is >> >> >enabled. >> >> >+ >> >> >+ HS Mode >> >> >+ Hypervisor-extended-supervisor mode which virtualizes the >> >> >supervisor mode. >> >> >+ >> >> >+ U Mode >> >> >+ User mode where userspace application is expected to run. >> >> >+ >> >> >+ HSM >> >> >+ Hart State Management (HSM) is an SBI extension that >enables >> >the >> >> >supervisor >> >> >+ mode software to implement ordered booting. >> >> >+ >> >> >+ SEE >> >> >+ Supervisor Execution Environment in RISC-V. This can be M >> >mode >> >> >or HS mode. >> >> >+ >> >> >+ SBI >> >> >+ Supervisor Binary Interface. This is an interface between >SEE >> >> >and supervisor >> >> >+ mode in RISC-V. >> >> >+ >> >> >+ RV32 >> >> >+ 32 bit execution mode in RISC-V. >> >> >+ >> >> >+ RV64 >> >> >+ 64 bit execution mode in RISC-V. >> >> >+ >> >> > SiP >> >> > Silicon Partner. In this document, the silicon >manufacturer. >> >> > >> >> >diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst >> >> >index 74ef70e29784..ad9d9543555e 100644 >> >> >--- a/source/chapter2-uefi.rst >> >> >+++ b/source/chapter2-uefi.rst >> >> >@@ -36,7 +36,7 @@ Resident UEFI firmware might target a specific >> >> >privilege level. >> >> > In contrast, UEFI Loaded Images, such as third-party drivers and >> >boot >> >> >applications, must not contain any built-in assumptions that they >> >are >> >> >to be >> >> >loaded at a given privilege level during boot time since they >can, >> >for >> >> >example, >> >> >-legitimately be loaded into either EL1 or EL2 on AArch64. >> >> >+legitimately be loaded into either EL1 or EL2 on AArch64 and HS >or >> >S >> >> >mode in RISC-V. >> >> > >> >> > AArch64 Exception Levels >> >> > ------------------------ >> >> >@@ -59,6 +59,14 @@ UEFI-compliant Operating System. >> >> > In this instance, the UEFI boot-time environment can be >provided, >> >as a >> >> >virtualized service, by the hypervisor and not as part of the >host >> >> >firmware. >> >> > >> >> >+RISC-V privilege levels >> >> >+----------------------- >> >> >+ >> >> >+UEFI shall execute in RV32/RV64 mode either in S or HS mode >> >depending >> >> >on whether >> >> >+or not virtualization is supported in hardware and available at >OS >> >> >load time. >> >> >+If the UEFI firmware is running in HS mode, the hypervisor is >> >> >responsible for >> >> >+providing the virtualized boot-time/runtime services. >> >> >+ >> >> > UEFI Boot Services >> >> > ================== >> >> > >> >> >diff --git a/source/chapter3-secureworld.rst >> >> >b/source/chapter3-secureworld.rst >> >> >index 9c51bca24f33..1551aa90c349 100644 >> >> >--- a/source/chapter3-secureworld.rst >> >> >+++ b/source/chapter3-secureworld.rst >> >> >@@ -27,3 +27,16 @@ Platforms without EL3 must implement one of: >> >> > However, the spin table protocol is strongly discouraged. >> >> >Future versions of this specification will only allow PSCI, and >PSCI >> >> >should >> >> > be implemented in all new designs. >> >> >+ >> >> >+ >> >> >+RISC-V Multiprocessor Startup protocol >> >> >+====================================== >> >> >+The firmware resident in M-mode or hypervisor running in HS mode >> >must >> >> >implement >> >> >+and conform to at least Supervisor Binary Specification [SBI]_ >v0.2 >> >> >with HART >> >> >+State Management(HSM) extension for both RV32 and RV64. In >addition >> >to >> >> >that, the >> >> >+firmware must ensure the following conditions before jumping to >the >> >> >UEFI >> >> >+application. >> >> >+ - a0 must always contain the hart id of the booting hart. >> >> >+ - a1 must always contain the memory address of the device >tree. >> >> >> >> I think this is only true for the non-EFI entry-point of Linux. >> >> >> >Sorry. I should have been more verbose here. The first two >conditions >> >should be set by the uefi application >> >before jumping to OS. In the Linux case, EFI stub should set these >> >values before jumping to real Linux. >> > >> >How about this: >> > >> >In addition to that, the firmware must ensure the following >condition >> >before jumping to the UEFI >> >application. >> > - The device tree must contain a property named **boot-hartid** >> >under */chosen* node. >> > This property must indicate the id of the booting hart. >> >The firmware application must ensure the following condition before >> >jumping to the >> >operating system. >> > - a0 must always contain the hart id of the booting hart. >> > - a1 must always contain the memory address of the device tree. >> >> The OS entry point is where the system table and the image handle are >passed. >> >> Yes, currently the Linux EFI stub calls some legacy entry point with >a0, a1 in the way you describe. But if they tomorrow pass the >information on the stack or via a fixed memory location or whatever it >is fine too. It is just a hidden implementation detail in the depth of >the application "Linux" that makes no difference to the UEFI world. >> >> I see no need to mention this Linux specific and internal stuff in >the EBBR spec. >> > >ok. Do we need to specify this under a linux specific section in that >case ? >Because the boot-hartid entry is also how EFI stub chooses to pass the >hartid to proper Linux. >Any other OS may choose to do it differently or Can we mandate that >every UEFI application (either similar to linux efistub >or any other UEFI application) must parse this device tree node to >retrieve the hartid.
It would not make any difference in the context of the EBBR if the boot hart id inside Linux were represented by an Egyptian hieroglyph in register x14 or a Maya glyph in x27. The firmware passes the boot hart id as device node. It is the only clue that the OS will get. If the information is relevant for the OS it has to parse it. Be it BSD, Haiku, Windows or Linux. The EBBR spec should avoid being OS specific. Best regards Heinrich > >> > >> >> The EFI entry point expects the system table and the image handle >as >> >only arguments. That is why you put the boot hart id into the >> >device-tree which is a configuration table pointed to by the system >> >table. >> > >> >Yes. EFI entry point arguments are defined by UEFI specification. So >> >we don't need to specify that. >> > >> >> >+ - The device tree must contain a property named >**boot-hartid** >> >> >under */chosen* node. >> >> >> >> %/under/under the/ >> >> >> >Thanks. I will fix that. >> > >> >> How is this modelled when using an ACPI table and not a device >tree? >> >> >> > >> >Currently, there is no ACPI design for RISC-V. I guess we need to >> >revisit this when we define ACPI for RISC-V. >> >> Maybe mention it as a TODO, e.g. >> >> "Passing of the boot hart id via ACPI tables has not been defined >yet." >> > >Sure. I will add that. > >> Best regards >> >> Heinrich >> >> >> >> >> >+ This property must indicate the id of the booting hart. >> >> >diff --git a/source/references.rst b/source/references.rst >> >> >index 1eb05090647e..9c96cb977c7e 100644 >> >> >--- a/source/references.rst >> >> >+++ b/source/references.rst >> >> >@@ -23,3 +23,7 @@ >> >> >.. [UEFI] `Unified Extensable Firmware Interface Specification >v2.8 >> >> >Errata A >> >> >> >>><https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_, >> >> > February 2020, `UEFI Forum <http://www.uefi.org>`_ >> >> >+ >> >> >+.. [SBI] `Supervisor Binary Interface (SBI) >> >> >+ >> >> >> >>><https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc>`_ >> >> >+ 11 October 2020, `RISC-V International ><https://riscv.org/>`_ >> >> >-- >> >> >2.28.0 >> >> > >> >> >_______________________________________________ >> >> >boot-architecture mailing list >> >> >boot-architecture@lists.linaro.org >> >> >https://lists.linaro.org/mailman/listinfo/boot-architecture >> >> >> >> _______________________________________________ >> >> boot-architecture mailing list >> >> boot-architecture@lists.linaro.org >> >> https://lists.linaro.org/mailman/listinfo/boot-architecture >> > > >-- >Regards, >Atish >_______________________________________________ >boot-architecture mailing list >boot-architecture@lists.linaro.org >https://lists.linaro.org/mailman/listinfo/boot-architecture _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
