On Tue, Oct 13, 2020 at 5:55 PM Heinrich Schuchardt <[email protected]> wrote: > > Am 14. Oktober 2020 02:13:41 MESZ schrieb Atish Patra <[email protected]>: > >On Tue, Oct 13, 2020 at 4:33 PM Heinrich Schuchardt > ><[email protected]> wrote: > >> > >> Am 14. Oktober 2020 01:03:51 MESZ schrieb Atish Patra > ><[email protected]>: > >> >On Tue, Oct 13, 2020 at 3:21 PM Heinrich Schuchardt > >> ><[email protected]> wrote: > >> >> > >> >> Am 13. Oktober 2020 20:39:12 MESZ schrieb Atish Patra > >> ><[email protected]>: > >> >> >This patch adds all minimum mandatory requirements to make RISC-V > >> >> >compatible > >> >> >with EBBR. > >> >> > > >> >> >Signed-off-by: Atish Patra <[email protected]> > >> >> >--- > >> >> > 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. >
Fair enough. I will update the patch as per the discussion. > 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 > >> >> >[email protected] > >> >> >https://lists.linaro.org/mailman/listinfo/boot-architecture > >> >> > >> >> _______________________________________________ > >> >> boot-architecture mailing list > >> >> [email protected] > >> >> https://lists.linaro.org/mailman/listinfo/boot-architecture > >> > > > > > >-- > >Regards, > >Atish > >_______________________________________________ > >boot-architecture mailing list > >[email protected] > >https://lists.linaro.org/mailman/listinfo/boot-architecture > -- Regards, Atish _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
