tech-unixplatformspec@lists.riscv.org | [PATCH v2] Base boot and runtime requirements

Home Messages Hashtags Subgroups

Date Date 1 - 20 of 29

[PATCH v2] Base boot and runtime requirements - initial commit

Abner Chang #870 Heinrich Schuchardt <xypron.glpk@...> 於 2021年5月5日週三下午8:13寫道： On 05.05.21 12:57, Rahul Pathak wrote: > > > On Wed, May 5, 2021 at 4:09 PM Abner Chang <renba.chang@... > <mailto:renba.chang@...>> wrote: > > > > Heinrich Schuchardt <xypron.glpk@... <mailto:xypron.glpk@...>> > 於 2021年5月5日週三下午5:47寫道： > > On 05.05.21 10:31, Abner Chang wrote: > > > > > > Heinrich Schuchardt <xypron.glpk@... > <mailto:xypron.glpk@...> <mailto:xypron.glpk@... > <mailto:xypron.glpk@...>>> 於 > > 2021年5月4日週二下午2:11寫道： > > > > On 5/4/21 7:14 AM, Abner Chang wrote: > > > Hi Rahul, my responses in below. > > > > > > Rahul Pathak <rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>> > > > <mailto:rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>>> 於 2021年5月3日週一下午 > 9:55寫道： > > > > > > Hi Abner, > > > > > > I read the UEFI PI Vol2 section. Need to understand > if EBBR > > > requirements on the format are not sufficient to > achieve the > > > minimum requirements for compliance. > > > Also what those UEFI Protocols must be if the format > is compliant > > > with Section 2 of UEFI PI. > > > > > > EBBR is defined for the embedded platform with the minimum > > requirements > > > > We are using the term "embedded platform" for RTOS > systems. These don't > > use UEFI at all. Do you mean "Linux Platform"? > > > > I mean the EBBR itself is defined for the embedded platform > > as mentioned in the Introduction. > > > > > > > of UEFI to boot to UEFI OS, the majority of firmware > implementation > > > would be uboot. Furthermore, EBBR defines nothing of > UEFI/PI spec. I > > > don't know if the current uboot support PI FW format (I > don't > > think so), > > > > U-Boot only implements the EBBR subset of the UEFI spec. > > > > U-Boot does not target the UEFI Platform Initialization > Specification. > > > > EBBR does not require implementing the PI spec. > > > > right. > > > > > > > if not, then it would be the effort to support PI > firmware image > > format > > > and I have no idea if EBBR would like to accommodate PI > FW image > > format > > > for the embedded system. But yes, obviously, the > current EBBR > > > requirements on FW image format doesn't support PI spec. > Also, I don't > > > think uboot needs to support FV format because the file > format is > > > defined for EFI drivers. > > > > > > I list the protocols currently support in EDK2 for > UEFI/PI FW > > image format, > > > EFI_PEI_FIRMWARE_VOLUME_INFO_PPI > > > EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI > > > EFI_PEI_FIRMWARE_VOLUMN_PPI > > > EFI_FIRMWARE_VOLUME2_PROTOCOL > > > EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL > > > EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL > > > Almost the entire section3 in PI spec Vol3 is covered. > > > > > > That is hard to say which Protocols or PPIs are > necessary for the > > PI FW > > > format because the above are two different sets for EFI > PEI phase and > > > DXE phase. Firmware other than edk2 doesn't have those > phases, > > non-edk2 > > > firmware such as uboot just need the code to parse > firmware storage > > > format if uboot would like to read the drivers from > firmware volume. > > > > EDK II complies with the PI spec. But I see no need to > refer to this > > spec in the base boot requirements. > > > > The reason is if EDK2 is the firmware for Linux2022, is the > firmware > > must be stored in the GPT? Can't firmware store in SPI and > compliant > > with PI Firmware device format? > > Up to now this spec does not require EDK II but the provision of > APIs. > We should keep it this way. > > EDK II can live on either SPI or on MMC or on an SD card. For > developement it is preferable to have it on an SD card and not > in SPI flash. > > Hi Heinrich, > I was saying the SPI use case. Linux2022 is the base requirements > that Server extension is based on, is my understanding correct? For > the server platform, the most use case is FW image on SPI. > > > Why should we care about the PI spec at all? It is irrelevant for > booting an operating system. > > > It says below in this patch, > +- Firmware must implement the support for GPT Partitioning and meet the > +requirements as per the > +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> Firmware Storage]. Both has nothing to do with the PI spec. > The link says where and how the firmware image is stored in firmware > storage, but what is the firmware storage for edk2 if it stored in > SPI? PI is needed, right? Up to now we have not required that EDK II must be the firmware used. Why would you disallow other firmware? Heinrich, I think I didn't say that. I just say to have the equivalent stuff to EBBR firmware stroage, for the implementation we use to have on the server platform. Why should we care about the storage format of the firmware as long as the boot ROM knows how to read and launch it? Yes, boot ROM knows how to read it. But I thought we were saying how to store the firmware. I was not saying to mention the detailed firmware storage image format, that is no need. However, PI vol3 sections [2.1], [2.1.1], [2.1.1.1], and [2.1.2] are very similar to EBBR Firmware storage section, they all talk about the storage for firmware just in the different terminologies. PI Firmware volume in firmware device is equivalent to the LU mentioned in EBBR section 4.[2], but we don't put OS in the firmware storage on the server platform. PI vol3 [2.1.3] also similar to EBBR 4.2 which talks about the firmware file system. My concern for the server platform is what if the BBL is not loaded by FSBL from GUID partition on MMC/SD? Boot firmware could be just mapped to the memory space, and the processor just jumps to the reset address then executes it? The reference to EBBR section 4 does not quite match to what the server implementation we have nowadays, it would look better and flexible to me for the server platform if we put another firmware storage format in Linux2022 platform. Otherwise, I would suggest having this in server extensions to override the base requirement or as an additional extension to the base requirements for the server platform. Best regards Heinrich > Maybe the link leads to the confusion as Sunil mentioend. > > I am going to change the heading as "Firmware Storage and Partitioning" > omitting "format" from it which is causing the confusion. > > > > For firmware update we should not care about the firmware > storage format > but about the UpdateCapsule() service. > > > > > > > > > > > For the RISC-V LinuxBoot 2022 spec, we can simply say > something like > > > below to avoid the EBBR effort, > > > > On many systems U-Boot is stored between the master boot > record and the > > first partition. EBBR chapter 4 requires that this area is not > > overwritten. Further it favors GPT over MBR partitioning. > > > > > If the firmware image is stored in the Block Device > Partition format, > > > > What defines the "Block Device Partition format"? > > > > It is from EBBR spec as I can tell. > > The term "Block Device Partition" does not exist in the EBBR. > > Is that 2.2.4 in https://arm-software.github.io/ebbr/ > <https://arm-software.github.io/ebbr/>? > > Abner > > > > > > > > Do you mean "if the firmware is stored as raw data on a > block device"? > > > > I think so. > > Then we should write it in clear terms. > > > > > > > > firmware must implement the support for GPT Partitioning > and meet the > > > requirements as per the > > > > link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> > > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>>> Firmware > > > Storage]. > > > > On some legacy U-Boot platforms we have the problem that > the boot ROM > > tries to read the next boot stage from one of the first 34 > sectors. This > > conflicts with GPT partitioning. > > > > We should require that if boot ROMs read from the next > boot stage from a > > block device, the storage location must be in LBA 34 or > higher. > > > > If the firmware is read from a file system (see Raspberry > Pi), the > > firmware should be required to support GPT partitioning > (the Raspberry > > Pi requires MBR partitioning). > > > > > If the platform chooses UEFI/PI firmware storage as the > format for the > > > firmware images, firmware must have the implementation > which supports > > > the firmware storage format defined in UEFI/PI > specification Vol3 > > > section 3 [Link to PI sepc]. > > > > What is the benefit of requiring: if you store information > as X, you > > should be able to read X? I suggest to keep the storage > format of > > firmware outside of the scope for the Linux platform. > > > > If we say " firmware must implement the support for GPT > Partitioning" > > then we should also mention PI firmware storage format for the > case of > > using edk2 as FW for Linux platform. > > No why? > > GPT partitioning and protective partitions to safeguard the > firmware are > completely independent of the binary format of the firmware. > > We should not care about implementation details of the firmware. > It is > enough to prescribe what functionality the firmware must expose. > > > Otherwise, I am also fine with not mentioning anything of > storage format. > > We still should mention that the firmware must support GPT and > that the > firmware must not be stored in the first 34 LBAs of a block device. Mention this in Linux2022 platform as the base requirement? Should the server platform follow this requirement? This sounds to me a specific implementation. Abner > > > Best regards > > Heinrich > > > > > Abner > > > > > > For the server platform there might be an interest to run > PCIe ROMs. So > > their storage format may have to be supported. But as long > as these do > > not exist as native RISC-V code this will require > emulating x86 code. > > > > Best regards > > > > Heinrich > > > > > > > > The above is enough IMO. > > > Regards, > > > Abner > > > > > > Thanks > > > Rahul > > > > > > On Wed, Apr 21, 2021 at 12:08 PM Abner Chang > > <renba.chang@... <mailto:renba.chang@...> > <mailto:renba.chang@... <mailto:renba.chang@...>> > > > <mailto:renba.chang@... > <mailto:renba.chang@...> <mailto:renba.chang@... > <mailto:renba.chang@...>>>> > > wrote: > > > > > > > > > My reviews are inline below which is apart from the > > > below recommendations if you don't think that is > better. > > > > > > > > > We have Linux2022 as the base feature set for > all kinds of > > > platform, however, there are many external > references to > > EBBR in > > > this section and EBBR is in the reduced UEFI > scope and the > > base > > > requirement is mainly for the embedded platform > We also have > > > Embedded2022 section specifically to > embedded system and there > > > is a Base sub-section for it. The above confuses me. > > > Could we just have a simple and generic > description in > > Linux2022 > > > that replaces all of EBBR references, then point to > > > Embede2022 in Linux2022 for the detailed > implementation of the > > > embedded platform? Also, have the references to > EBBR in > > > Embede2022. Is this clear than the current > layout of spec? > > > > > > For example, > > > +===== Firmware > > > .... > > > .... > > > +- For compliance with base specification > platform must > > implement > > > > > > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR>> > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR>>> > > > - UEFI Required Elements], > > > Below would be implemented for UEFI firmware > system for the > > > compliance with base specification, just some > implementations > > > may be omitted based on the requirements of > different RISC-V > > > platforms > > > - EFI_SYSTEM_TABLE > > > - EFI_BOOT_SERVICES > > > - EFI_ RUNTIME_SERVICES > > > - Required EFI protocols for the base specification. > > > - Required EFI protocols for the platform. > > > Refer to Embedded2022 for the detailed > implementations of the > > > above requirements. > > > Refer to Server2022 for the detailed > implementations of the > > > above requirements. > > > > > > In Embedded2022 section, put links to refer to EBBR. > > > In Server section, we can just refer to UEFI > spec if the > > > requirement needs full UEFI scope support. > > > > > > This reduces the confusion and increases > the readability > > to the > > > audience. Otherwise, it would be hard to read > for the Server > > > platform because Server2022 would base on > Linux2022 plus the > > > extensions. And some of the requirements that > refer to EBBR > > > would be overridden because of the deviations > for the server > > > platform. > > > > > > > > > Rahul Pathak <rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>> > > > <mailto:rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>>> 於 2021年4月20日週二下午 > > > 8:23寫道： > > > > > > Initial changes for the Base Boot & Runtime > requirements. > > > The sections which are currently in-progress are > > marked as TBD. > > > These changes can serve as the starting > point and more > > > details/changes > > > can be done tailored for RISC-V. > > > This is the main patch, there are minor > changes in the > > > contributors file > > > and the changelog which are not relevant for > now so I > > am not > > > sending those. > > > > > > Signed-off-by: Rahul Pathak > <rpathak@... <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>> > > > <mailto:rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>>> > > > --- > > > riscv-platform-spec.adoc \| 125 > > > ++++++++++++++++++++++++++++++++++++--- > > > 1 file changed, 118 insertions(+), 7 > deletions(-) > > > > > > diff --git a/riscv-platform-spec.adoc > > b/riscv-platform-spec.adoc > > > index 5d3b9c3..601fb61 100644 > > > --- a/riscv-platform-spec.adoc > > > +++ b/riscv-platform-spec.adoc > > > @@ -32,6 +32,36 @@ include::profiles.adoc[] > > > // Linux-2022 Platform > > > == Linux-2022 Platform > > > > > > +=== Terminology > > > +[cols="1,2", width=80%, align="left", > options="header"] > > > +\|=== > > > +\|TERM \| DESCRIPTION > > > +\|SBI \| Supervisor Binary Interface > > > +\|UEFI \| Unified Extensible Firmware > Interface > > > +\|ACPI \| Advanced Configuration and > Power Interface > > > +\|SMBIOS \| System Management Basic I/O System > > > +\|DTS \| Devicetree source file > > > +\|DTB \| Devicetree binary > > > +\|RVA22 \| RISC-V Application 2022 > > > +\|RV32GC \| RISC-V 32-bit general purpose ISA > > described as > > > RV32IMAFDC. > > > +\|RV64GC \| RISC-V 64-bit general purpose ISA > > described as > > > RV64IMAFDC. > > > +\|=== > > > + > > > + > > > +=== Specifications > > > +[cols="1,2", width=80%, align="left", > options="header"] > > > +\|=== > > > +\|SPECIFICATION \| VERSION > > > > > > +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > > > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI>> > > > > > > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > > > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI>>> > > > Specification] \| v2.9 > > > > > > +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > > > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree>> > > > > > > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > > > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree>>> > > > Specification] \| v0.3 > > > > > > +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > > > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI>> > > > > > > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > > > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI>>> > > > Specification] \| v0.3-rc0 > > > +\|link:[RVA22 Specification] > > > > \| TBD > > > > +\|link:https://arm-software.github.io/ebbr/[EBBR > <https://arm-software.github.io/ebbr/%5BEBBR> > > <https://arm-software.github.io/ebbr/%5BEBBR > <https://arm-software.github.io/ebbr/%5BEBBR>> > > > <https://arm-software.github.io/ebbr/%5BEBBR > <https://arm-software.github.io/ebbr/%5BEBBR> > > <https://arm-software.github.io/ebbr/%5BEBBR > <https://arm-software.github.io/ebbr/%5BEBBR>>> > > > Specification] > > > \| v2.0.0-pre1 > > > > > > +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > > > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI>> > > > > > > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > > > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI>>> > > > Specification] \| v6.4 > > > > > > +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > > > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS>> > > > > > > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > > > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS>>> > > > Specification] \| v3.4.0 > > > +\|link:[Platform Policy] > > > > \| TBD > > > +\|=== > > > + > > > // Base feature set for Linux-2022 Platform > > > === Base > > > ==== Architecture > > > @@ -57,14 +87,95 @@ include::profiles.adoc[] > > > * Timers > > > * Watchdog Timers > > > > > > -==== Boot Process > > > -* Firmware > > > -* Boot-Loader > > > -* Discovery Mechanisms > > > +==== Boot and Runtime Requirements > > > +- The base specification defines the interface > > between the > > > firmware and the > > > +operating system suitable for the RISC-V > platforms with > > > rich operating > > > +systems. > > > +- These requirements specifies the required > boot and > > > runtime services, device > > > +discovery mechanism, etc. > > > +- The requirements are operating system > agnostic, > > specific > > > firmware/bootloader > > > +implementation agnostic. > > > +- The base boot specification depends on > the RVA22 > > profile > > > and all requirements > > > +from the RVA22 profile must be implemented. > > > +- The base runtime specification depends on the > > RISC-V SBI > > > specification and > > > +all requirements from the SBI spec must be > implemented. > > > +- Any RV32GC or RV64GC system with Machine, > > Supervisor and > > > User Mode can comply > > > +with the base specification. Hypervisor > Extension is > > optional. > > > +_Will be defined in this spec if the > RVA22 spec > > does not > > > mention it._ > > > +- For the generic mandatory requirements > this base > > > specification will refer to > > > +the EBBR Specification. Any deviation from > the EBBR > > will be > > > explicitly > > > +mentioned in the requirements. > > > > > > +- Specifications followed are mentioned in the > > > +<<Specifications,Specification Section>> > > > +- For more on scope of MANDATORY, DEPRECATED, > > COMPATIBILITY > > > refer Platform > > > +Policy Specification. > > > + > > > + > > > +===== Firmware > > > +- UEFI Platform must meet RISC-V Platform > requirements on > > > calling conventions, > > > +ABI support specific to RISC-V. Refer > Chapter - 2.3.7 > > > RISC-V Platforms of UEFI > > > +specification. > > > +- For compliance with base specification > platform must > > > implement > > > > > > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR>> > > > > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR>>> - > > > UEFI Required Elements], > > > > > > > > > > > > +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR>> > > > > > > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR>>> > > > - UEFI Platform Specific Elements] > > > +and support the following > > > > > > > > > > > > +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> > > > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR>> > > > > > > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR>>> > > > - Global Variables]. > > > + > > > +====== Block Device Partition Format > > > > > > Better to name it as "Firmware Block Device > Partition Format" > > > becasue the link to EBBR is specifically talks > about how to > > > store firmware image. > > > > > > +- Firmware must implement the support for GPT > > Partitioning > > > and meet the > > > +requirements as per the > > > > > > +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> > > > > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>>> > > > Firmware Storage]. > > > > > > This is what I said it may confuse audiences > becasue UEFI PI > > > spec volume3 also defines the format of firmware > image > > which is > > > used by edk2 and which is very different than > the one > > defined in > > > EBBR. > > > Can we add the below sentence, > > > Firmware must implement the require EFI > protocols if the > > > firmware image is stored in the format which > complaint with > > > section 2 "Firmware Storage Design Discussion" > in UEFI PI > > > specification volume3. > > > > > > + > > > +===== Boot Services > > > +- Base specification compliant firmware must > > implement all > > > UEFI functions > > > +marked as EFI_BOOT_SERVICES. > > > + > > > +====== Startup Protocol > > > +- UEFI firmware could be executed in either > Machine > > mode or > > > Supervisor mode > > > +during the entire POST, according to the > hart capability > > > and the platform > > > +design. For firmware privilege mode > requirements, mode > > > switch and the handover > > > +of control to S-Mode refer UEFI chapter > 2.3.7 RISC-V > > Platforms. > > > +- Before yielding control to S-Mode stage, > firmware must > > > configure the M-Mode > > > +state. Refer the RISC-V SBI specification > for details. > > > +- If the Hypervisor Extension is > implemented. TBD. > > > + > > > + > > > +====== Memory Map > > > +- UEFI environment must provide a system > memory map and > > > meet the requirements > > > +for > > > > > link:https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR> > > <https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR>> > > > > <https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR> > > <https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR>>> - > > > Memory Map]. > > > > > > + > > > +===== Boot-Loader > > > +TBD > > > + > > > +===== Discovery Mechanisms > > > +- The base specification mandates the use of > > Devicetree for > > > system description. > > > +- System must meet > > > > > link:https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR> > > <https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR>> > > > > <https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR> > > <https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR>>> - > > > Devicetree requirements] > > > +to comply with this base specification. > Also refer > > > Devicetree tables section > > > +in chapter - 4.6 EFI Configuration Table & > Properties > > Table > > > of UEFI > > > +specification. > > > > > > Could we add something regarding to SMBIOS? > > > "If platform requires SMBIOS on UEFI system, the > SMBIOS table > > > must be installed to EFI Configuration Table > according to 4.6 > > > EFI Configuration Table & Properties Table of UEFI > > > specification." > > > > > > Abner > > > > > > > > > -==== Runtime services > > > -* SBI > > > -* UEFI > > > +===== Runtime Services > > > +====== SBI > > > +- Firmware must implement the runtime > services/extensions > > > specified by the > > > +RISC-V SBI Specification. > > > +- Wherever applicable firmware must > implement UEFI > > > interfaces over similar > > > +interfaces and services present in the SBI > specification. > > > For example, UEFI > > > +runtime services must implement > ResetSystem() via SBI > > Reset > > > extension. > > > +- Legacy Extensions from the SBI > Specification are > > > deprecated and must not be > > > +implemented. > > > + > > > +====== UEFI > > > +- Firmware must conform to the > > > > > > +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > > > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR>> > > > > > > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > > > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR>>> > > > - UEFI EFI_RUNTIME_SERVICES requirements]. > > > +- Firmware must meet the requirements for > > > > > > +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > > > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR>> > > > > > > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > > > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR>>> > > > - Runtime Device Mappings] > > > +to avoid conflict between the firmware and > OS when > > > accessing the mapped > > > +devices. > > > +- Compliant UEFI runtime environment must > meet the > > > requirements for the > > > > > > +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > > > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR>> > > > > > > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > > > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR>>> > > > - Runtime Variable Access]. > > > +- Compliant implementation must meet the > Realtime Clock > > > requirements > > > > > > +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > > > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR>> > > > > > > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > > > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR>>> > > > - UEFI RTC interface] > > > +if RTC is present in the system. > > > > > > // Server extension for Linux-2022 Platform > > > === Server Extension > > > -- > > > 2.25.1 > > > > > > > > > > > > > > >
More All Messages By This Member
Heinrich Schuchardt #865 On 05.05.21 12:57, Rahul Pathak wrote: On Wed, May 5, 2021 at 4:09 PM Abner Chang <renba.chang@... <mailto:renba.chang@...>> wrote: Heinrich Schuchardt <xypron.glpk@... <mailto:xypron.glpk@...>> 於 2021年5月5日週三下午5:47寫道： On 05.05.21 10:31, Abner Chang wrote: > > > Heinrich Schuchardt <xypron.glpk@... <mailto:xypron.glpk@...> <mailto:xypron.glpk@... <mailto:xypron.glpk@...>>> 於 > 2021年5月4日週二下午2:11寫道： > > On 5/4/21 7:14 AM, Abner Chang wrote: > > Hi Rahul, my responses in below. > > > > Rahul Pathak <rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>> > > <mailto:rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>>>> 於 2021年5月3日週一下午 9:55寫道： > > > > Hi Abner, > > > > I read the UEFI PI Vol2 section. Need to understand if EBBR > > requirements on the format are not sufficient to achieve the > > minimum requirements for compliance. > > Also what those UEFI Protocols must be if the format is compliant > > with Section 2 of UEFI PI. > > > > EBBR is defined for the embedded platform with the minimum > requirements > > We are using the term "embedded platform" for RTOS systems. These don't > use UEFI at all. Do you mean "Linux Platform"? > > I mean the EBBR itself is defined for the embedded platform > as mentioned in the Introduction. > > > > of UEFI to boot to UEFI OS, the majority of firmware implementation > > would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I > > don't know if the current uboot support PI FW format (I don't > think so), > > U-Boot only implements the EBBR subset of the UEFI spec. > > U-Boot does not target the UEFI Platform Initialization Specification. > > EBBR does not require implementing the PI spec. > > right. > > > > if not, then it would be the effort to support PI firmware image > format > > and I have no idea if EBBR would like to accommodate PI FW image > format > > for the embedded system. But yes, obviously, the current EBBR > > requirements on FW image format doesn't support PI spec. Also, I don't > > think uboot needs to support FV format because the file format is > > defined for EFI drivers. > > > > I list the protocols currently support in EDK2 for UEFI/PI FW > image format, > > EFI_PEI_FIRMWARE_VOLUME_INFO_PPI > > EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI > > EFI_PEI_FIRMWARE_VOLUMN_PPI > > EFI_FIRMWARE_VOLUME2_PROTOCOL > > EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL > > EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL > > Almost the entire section3 in PI spec Vol3 is covered. > > > > That is hard to say which Protocols or PPIs are necessary for the > PI FW > > format because the above are two different sets for EFI PEI phase and > > DXE phase. Firmware other than edk2 doesn't have those phases, > non-edk2 > > firmware such as uboot just need the code to parse firmware storage > > format if uboot would like to read the drivers from firmware volume. > > EDK II complies with the PI spec. But I see no need to refer to this > spec in the base boot requirements. > > The reason is if EDK2 is the firmware for Linux2022, is the firmware > must be stored in the GPT? Can't firmware store in SPI and compliant > with PI Firmware device format? Up to now this spec does not require EDK II but the provision of APIs. We should keep it this way. EDK II can live on either SPI or on MMC or on an SD card. For developement it is preferable to have it on an SD card and not in SPI flash. Hi Heinrich, I was saying the SPI use case. Linux2022 is the base requirements that Server extension is based on, is my understanding correct? For the server platform, the most use case is FW image on SPI. Why should we care about the PI spec at all? It is irrelevant for booting an operating system. It says below in this patch, +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> Firmware Storage]. Both has nothing to do with the PI spec. The link says where and how the firmware image is stored in firmware storage, but what is the firmware storage for edk2 if it stored in SPI? PI is needed, right? Up to now we have not required that EDK II must be the firmware used. Why would you disallow other firmware? Why should we care about the storage format of the firmware as long as the boot ROM knows how to read and launch it? Best regards Heinrich Maybe the link leads to the confusion as Sunil mentioend. I am going to change the heading as "Firmware Storage and Partitioning" omitting "format" from it which is causing the confusion. For firmware update we should not care about the firmware storage format but about the UpdateCapsule() service. > > > > > > For the RISC-V LinuxBoot 2022 spec, we can simply say something like > > below to avoid the EBBR effort, > > On many systems U-Boot is stored between the master boot record and the > first partition. EBBR chapter 4 requires that this area is not > overwritten. Further it favors GPT over MBR partitioning. > > > If the firmware image is stored in the Block Device Partition format, > > What defines the "Block Device Partition format"? > > It is from EBBR spec as I can tell. The term "Block Device Partition" does not exist in the EBBR. Is that 2.2.4 in https://arm-software.github.io/ebbr/ <https://arm-software.github.io/ebbr/>? Abner > > > Do you mean "if the firmware is stored as raw data on a block device"? > > I think so. Then we should write it in clear terms. > > > > firmware must implement the support for GPT Partitioning and meet the > > requirements as per the > > link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>>> Firmware > > Storage]. > > On some legacy U-Boot platforms we have the problem that the boot ROM > tries to read the next boot stage from one of the first 34 sectors. This > conflicts with GPT partitioning. > > We should require that if boot ROMs read from the next boot stage from a > block device, the storage location must be in LBA 34 or higher. > > If the firmware is read from a file system (see Raspberry Pi), the > firmware should be required to support GPT partitioning (the Raspberry > Pi requires MBR partitioning). > > > If the platform chooses UEFI/PI firmware storage as the format for the > > firmware images, firmware must have the implementation which supports > > the firmware storage format defined in UEFI/PI specification Vol3 > > section 3 [Link to PI sepc]. > > What is the benefit of requiring: if you store information as X, you > should be able to read X? I suggest to keep the storage format of > firmware outside of the scope for the Linux platform. > > If we say " firmware must implement the support for GPT Partitioning" > then we should also mention PI firmware storage format for the case of > using edk2 as FW for Linux platform. No why? GPT partitioning and protective partitions to safeguard the firmware are completely independent of the binary format of the firmware. We should not care about implementation details of the firmware. It is enough to prescribe what functionality the firmware must expose. > Otherwise, I am also fine with not mentioning anything of storage format. We still should mention that the firmware must support GPT and that the firmware must not be stored in the first 34 LBAs of a block device. Best regards Heinrich > > Abner > > > For the server platform there might be an interest to run PCIe ROMs. So > their storage format may have to be supported. But as long as these do > not exist as native RISC-V code this will require emulating x86 code. > > Best regards > > Heinrich > > > > > The above is enough IMO. > > Regards, > > Abner > > > > Thanks > > Rahul > > > > On Wed, Apr 21, 2021 at 12:08 PM Abner Chang > <renba.chang@... <mailto:renba.chang@...> <mailto:renba.chang@... <mailto:renba.chang@...>> > > <mailto:renba.chang@... <mailto:renba.chang@...> <mailto:renba.chang@... <mailto:renba.chang@...>>>> > wrote: > > > > > > My reviews are inline below which is apart from the > > below recommendations if you don't think that is better. > > > > > > We have Linux2022 as the base feature set for all kinds of > > platform, however, there are many external references to > EBBR in > > this section and EBBR is in the reduced UEFI scope and the > base > > requirement is mainly for the embedded platform We also have > > Embedded2022 section specifically to embedded system and there > > is a Base sub-section for it. The above confuses me. > > Could we just have a simple and generic description in > Linux2022 > > that replaces all of EBBR references, then point to > > Embede2022 in Linux2022 for the detailed implementation of the > > embedded platform? Also, have the references to EBBR in > > Embede2022. Is this clear than the current layout of spec? > > > > For example, > > +===== Firmware > > .... > > .... > > +- For compliance with base specification platform must > implement > > > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR>> > <https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR>>> > > - UEFI Required Elements], > > Below would be implemented for UEFI firmware system for the > > compliance with base specification, just some implementations > > may be omitted based on the requirements of different RISC-V > > platforms > > - EFI_SYSTEM_TABLE > > - EFI_BOOT_SERVICES > > - EFI_ RUNTIME_SERVICES > > - Required EFI protocols for the base specification. > > - Required EFI protocols for the platform. > > Refer to Embedded2022 for the detailed implementations of the > > above requirements. > > Refer to Server2022 for the detailed implementations of the > > above requirements. > > > > In Embedded2022 section, put links to refer to EBBR. > > In Server section, we can just refer to UEFI spec if the > > requirement needs full UEFI scope support. > > > > This reduces the confusion and increases the readability > to the > > audience. Otherwise, it would be hard to read for the Server > > platform because Server2022 would base on Linux2022 plus the > > extensions. And some of the requirements that refer to EBBR > > would be overridden because of the deviations for the server > > platform. > > > > > > Rahul Pathak <rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>> > > <mailto:rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>>>> 於 2021年4月20日週二下午 > > 8:23寫道： > > > > Initial changes for the Base Boot & Runtime requirements. > > The sections which are currently in-progress are > marked as TBD. > > These changes can serve as the starting point and more > > details/changes > > can be done tailored for RISC-V. > > This is the main patch, there are minor changes in the > > contributors file > > and the changelog which are not relevant for now so I > am not > > sending those. > > > > Signed-off-by: Rahul Pathak <rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>> > > <mailto:rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>>>> > > --- > > riscv-platform-spec.adoc \| 125 > > ++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 118 insertions(+), 7 deletions(-) > > > > diff --git a/riscv-platform-spec.adoc > b/riscv-platform-spec.adoc > > index 5d3b9c3..601fb61 100644 > > --- a/riscv-platform-spec.adoc > > +++ b/riscv-platform-spec.adoc > > @@ -32,6 +32,36 @@ include::profiles.adoc[] > > // Linux-2022 Platform > > == Linux-2022 Platform > > > > +=== Terminology > > +[cols="1,2", width=80%, align="left", options="header"] > > +\|=== > > +\|TERM \| DESCRIPTION > > +\|SBI \| Supervisor Binary Interface > > +\|UEFI \| Unified Extensible Firmware Interface > > +\|ACPI \| Advanced Configuration and Power Interface > > +\|SMBIOS \| System Management Basic I/O System > > +\|DTS \| Devicetree source file > > +\|DTB \| Devicetree binary > > +\|RVA22 \| RISC-V Application 2022 > > +\|RV32GC \| RISC-V 32-bit general purpose ISA > described as > > RV32IMAFDC. > > +\|RV64GC \| RISC-V 64-bit general purpose ISA > described as > > RV64IMAFDC. > > +\|=== > > + > > + > > +=== Specifications > > +[cols="1,2", width=80%, align="left", options="header"] > > +\|=== > > +\|SPECIFICATION \| VERSION > > > +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI>> > > > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI>>> > > Specification] \| v2.9 > > > +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree>> > > > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree>>> > > Specification] \| v0.3 > > > +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI>> > > > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI>>> > > Specification] \| v0.3-rc0 > > +\|link:[RVA22 Specification] > > \| TBD > > +\|link:https://arm-software.github.io/ebbr/[EBBR <https://arm-software.github.io/ebbr/%5BEBBR> > <https://arm-software.github.io/ebbr/%5BEBBR <https://arm-software.github.io/ebbr/%5BEBBR>> > > <https://arm-software.github.io/ebbr/%5BEBBR <https://arm-software.github.io/ebbr/%5BEBBR> > <https://arm-software.github.io/ebbr/%5BEBBR <https://arm-software.github.io/ebbr/%5BEBBR>>> > > Specification] > > \| v2.0.0-pre1 > > > +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI>> > > > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI>>> > > Specification] \| v6.4 > > > +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS>> > > > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS>>> > > Specification] \| v3.4.0 > > +\|link:[Platform Policy] > > \| TBD > > +\|=== > > + > > // Base feature set for Linux-2022 Platform > > === Base > > ==== Architecture > > @@ -57,14 +87,95 @@ include::profiles.adoc[] > > * Timers > > * Watchdog Timers > > > > -==== Boot Process > > -* Firmware > > -* Boot-Loader > > -* Discovery Mechanisms > > +==== Boot and Runtime Requirements > > +- The base specification defines the interface > between the > > firmware and the > > +operating system suitable for the RISC-V platforms with > > rich operating > > +systems. > > +- These requirements specifies the required boot and > > runtime services, device > > +discovery mechanism, etc. > > +- The requirements are operating system agnostic, > specific > > firmware/bootloader > > +implementation agnostic. > > +- The base boot specification depends on the RVA22 > profile > > and all requirements > > +from the RVA22 profile must be implemented. > > +- The base runtime specification depends on the > RISC-V SBI > > specification and > > +all requirements from the SBI spec must be implemented. > > +- Any RV32GC or RV64GC system with Machine, > Supervisor and > > User Mode can comply > > +with the base specification. Hypervisor Extension is > optional. > > +_Will be defined in this spec if the RVA22 spec > does not > > mention it._ > > +- For the generic mandatory requirements this base > > specification will refer to > > +the EBBR Specification. Any deviation from the EBBR > will be > > explicitly > > +mentioned in the requirements. > > > > +- Specifications followed are mentioned in the > > +<<Specifications,Specification Section>> > > +- For more on scope of MANDATORY, DEPRECATED, > COMPATIBILITY > > refer Platform > > +Policy Specification. > > + > > + > > +===== Firmware > > +- UEFI Platform must meet RISC-V Platform requirements on > > calling conventions, > > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 > > RISC-V Platforms of UEFI > > +specification. > > +- For compliance with base specification platform must > > implement > > > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR>> > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR>>> - > > UEFI Required Elements], > > > > > > > +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR>> > > > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR>>> > > - UEFI Platform Specific Elements] > > +and support the following > > > > > > > +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR>> > > > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> <https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR>>> > > - Global Variables]. > > + > > +====== Block Device Partition Format > > > > Better to name it as "Firmware Block Device Partition Format" > > becasue the link to EBBR is specifically talks about how to > > store firmware image. > > > > +- Firmware must implement the support for GPT > Partitioning > > and meet the > > +requirements as per the > > > +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>>> > > Firmware Storage]. > > > > This is what I said it may confuse audiences becasue UEFI PI > > spec volume3 also defines the format of firmware image > which is > > used by edk2 and which is very different than the one > defined in > > EBBR. > > Can we add the below sentence, > > Firmware must implement the require EFI protocols if the > > firmware image is stored in the format which complaint with > > section 2 "Firmware Storage Design Discussion" in UEFI PI > > specification volume3. > > > > + > > +===== Boot Services > > +- Base specification compliant firmware must > implement all > > UEFI functions > > +marked as EFI_BOOT_SERVICES. > > + > > +====== Startup Protocol > > +- UEFI firmware could be executed in either Machine > mode or > > Supervisor mode > > +during the entire POST, according to the hart capability > > and the platform > > +design. For firmware privilege mode requirements, mode > > switch and the handover > > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V > Platforms. > > +- Before yielding control to S-Mode stage, firmware must > > configure the M-Mode > > +state. Refer the RISC-V SBI specification for details. > > +- If the Hypervisor Extension is implemented. TBD. > > + > > + > > +====== Memory Map > > +- UEFI environment must provide a system memory map and > > meet the requirements > > +for > > > link:https://arm-software.github.io/ebbr/#memory-map[EBBR <https://arm-software.github.io/ebbr/#memory-map[EBBR> > <https://arm-software.github.io/ebbr/#memory-map[EBBR <https://arm-software.github.io/ebbr/#memory-map[EBBR>> > > <https://arm-software.github.io/ebbr/#memory-map[EBBR <https://arm-software.github.io/ebbr/#memory-map[EBBR> > <https://arm-software.github.io/ebbr/#memory-map[EBBR <https://arm-software.github.io/ebbr/#memory-map[EBBR>>> - > > Memory Map]. > > > > + > > +===== Boot-Loader > > +TBD > > + > > +===== Discovery Mechanisms > > +- The base specification mandates the use of > Devicetree for > > system description. > > +- System must meet > > > link:https://arm-software.github.io/ebbr/#devicetree[EBBR <https://arm-software.github.io/ebbr/#devicetree[EBBR> > <https://arm-software.github.io/ebbr/#devicetree[EBBR <https://arm-software.github.io/ebbr/#devicetree[EBBR>> > > <https://arm-software.github.io/ebbr/#devicetree[EBBR <https://arm-software.github.io/ebbr/#devicetree[EBBR> > <https://arm-software.github.io/ebbr/#devicetree[EBBR <https://arm-software.github.io/ebbr/#devicetree[EBBR>>> - > > Devicetree requirements] > > +to comply with this base specification. Also refer > > Devicetree tables section > > +in chapter - 4.6 EFI Configuration Table & Properties > Table > > of UEFI > > +specification. > > > > Could we add something regarding to SMBIOS? > > "If platform requires SMBIOS on UEFI system, the SMBIOS table > > must be installed to EFI Configuration Table according to 4.6 > > EFI Configuration Table & Properties Table of UEFI > > specification." > > > > Abner > > > > > > -==== Runtime services > > -* SBI > > -* UEFI > > +===== Runtime Services > > +====== SBI > > +- Firmware must implement the runtime services/extensions > > specified by the > > +RISC-V SBI Specification. > > +- Wherever applicable firmware must implement UEFI > > interfaces over similar > > +interfaces and services present in the SBI specification. > > For example, UEFI > > +runtime services must implement ResetSystem() via SBI > Reset > > extension. > > +- Legacy Extensions from the SBI Specification are > > deprecated and must not be > > +implemented. > > + > > +====== UEFI > > +- Firmware must conform to the > > > +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR>> > > > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR>>> > > - UEFI EFI_RUNTIME_SERVICES requirements]. > > +- Firmware must meet the requirements for > > > +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR>> > > > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR>>> > > - Runtime Device Mappings] > > +to avoid conflict between the firmware and OS when > > accessing the mapped > > +devices. > > +- Compliant UEFI runtime environment must meet the > > requirements for the > > > +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR>> > > > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR>>> > > - Runtime Variable Access]. > > +- Compliant implementation must meet the Realtime Clock > > requirements > > > +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR>> > > > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR>>> > > - UEFI RTC interface] > > +if RTC is present in the system. > > > > // Server extension for Linux-2022 Platform > > === Server Extension > > -- > > 2.25.1 > > > > > > > > >
More All Messages By This Member
Rahul Pathak #864 On Wed, May 5, 2021 at 4:09 PM Abner Chang <renba.chang@...> wrote: Heinrich Schuchardt <xypron.glpk@...> 於 2021年5月5日週三下午5:47寫道： On 05.05.21 10:31, Abner Chang wrote: > > > Heinrich Schuchardt <xypron.glpk@... <mailto:xypron.glpk@...>> 於 > 2021年5月4日週二下午2:11寫道： > > On 5/4/21 7:14 AM, Abner Chang wrote: > > Hi Rahul, my responses in below. > > > > Rahul Pathak <rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>> 於 2021年5月3日週一下午9:55寫道： > > > > Hi Abner, > > > > I read the UEFI PI Vol2 section. Need to understand if EBBR > > requirements on the format are not sufficient to achieve the > > minimum requirements for compliance. > > Also what those UEFI Protocols must be if the format is compliant > > with Section 2 of UEFI PI. > > > > EBBR is defined for the embedded platform with the minimum > requirements > > We are using the term "embedded platform" for RTOS systems. These don't > use UEFI at all. Do you mean "Linux Platform"? > > I mean the EBBR itself is defined for the embedded platform > as mentioned in the Introduction. > > > > of UEFI to boot to UEFI OS, the majority of firmware implementation > > would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I > > don't know if the current uboot support PI FW format (I don't > think so), > > U-Boot only implements the EBBR subset of the UEFI spec. > > U-Boot does not target the UEFI Platform Initialization Specification. > > EBBR does not require implementing the PI spec. > > right. > > > > if not, then it would be the effort to support PI firmware image > format > > and I have no idea if EBBR would like to accommodate PI FW image > format > > for the embedded system. But yes, obviously, the current EBBR > > requirements on FW image format doesn't support PI spec. Also, I don't > > think uboot needs to support FV format because the file format is > > defined for EFI drivers. > > > > I list the protocols currently support in EDK2 for UEFI/PI FW > image format, > > EFI_PEI_FIRMWARE_VOLUME_INFO_PPI > > EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI > > EFI_PEI_FIRMWARE_VOLUMN_PPI > > EFI_FIRMWARE_VOLUME2_PROTOCOL > > EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL > > EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL > > Almost the entire section3 in PI spec Vol3 is covered. > > > > That is hard to say which Protocols or PPIs are necessary for the > PI FW > > format because the above are two different sets for EFI PEI phase and > > DXE phase. Firmware other than edk2 doesn't have those phases, > non-edk2 > > firmware such as uboot just need the code to parse firmware storage > > format if uboot would like to read the drivers from firmware volume. > > EDK II complies with the PI spec. But I see no need to refer to this > spec in the base boot requirements. > > The reason is if EDK2 is the firmware for Linux2022, is the firmware > must be stored in the GPT? Can't firmware store in SPI and compliant > with PI Firmware device format? Up to now this spec does not require EDK II but the provision of APIs. We should keep it this way. EDK II can live on either SPI or on MMC or on an SD card. For developement it is preferable to have it on an SD card and not in SPI flash. Hi Heinrich, I was saying the SPI use case. Linux2022 is the base requirements that Server extension is based on, is my understanding correct? For the server platform, the most use case is FW image on SPI. Why should we care about the PI spec at all? It is irrelevant for booting an operating system. It says below in this patch, +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage]. The link says where and how the firmware image is stored in firmware storage, but what is the firmware storage for edk2 if it stored in SPI? PI is needed, right? Maybe the link leads to the confusion as Sunil mentioend. I am going to change the heading as "Firmware Storage and Partitioning" omitting "format" from it which is causing the confusion. For firmware update we should not care about the firmware storage format but about the UpdateCapsule() service. > > > > > > For the RISC-V LinuxBoot 2022 spec, we can simply say something like > > below to avoid the EBBR effort, > > On many systems U-Boot is stored between the master boot record and the > first partition. EBBR chapter 4 requires that this area is not > overwritten. Further it favors GPT over MBR partitioning. > > > If the firmware image is stored in the Block Device Partition format, > > What defines the "Block Device Partition format"? > > It is from EBBR spec as I can tell. The term "Block Device Partition" does not exist in the EBBR. Is that 2.2.4 in https://arm-software.github.io/ebbr/? Abner > > > Do you mean "if the firmware is stored as raw data on a block device"? > > I think so. Then we should write it in clear terms. > > > > firmware must implement the support for GPT Partitioning and meet the > > requirements as per the > > link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> Firmware > > Storage]. > > On some legacy U-Boot platforms we have the problem that the boot ROM > tries to read the next boot stage from one of the first 34 sectors. This > conflicts with GPT partitioning. > > We should require that if boot ROMs read from the next boot stage from a > block device, the storage location must be in LBA 34 or higher. > > If the firmware is read from a file system (see Raspberry Pi), the > firmware should be required to support GPT partitioning (the Raspberry > Pi requires MBR partitioning). > > > If the platform chooses UEFI/PI firmware storage as the format for the > > firmware images, firmware must have the implementation which supports > > the firmware storage format defined in UEFI/PI specification Vol3 > > section 3 [Link to PI sepc]. > > What is the benefit of requiring: if you store information as X, you > should be able to read X? I suggest to keep the storage format of > firmware outside of the scope for the Linux platform. > > If we say " firmware must implement the support for GPT Partitioning" > then we should also mention PI firmware storage format for the case of > using edk2 as FW for Linux platform. No why? GPT partitioning and protective partitions to safeguard the firmware are completely independent of the binary format of the firmware. We should not care about implementation details of the firmware. It is enough to prescribe what functionality the firmware must expose. > Otherwise, I am also fine with not mentioning anything of storage format. We still should mention that the firmware must support GPT and that the firmware must not be stored in the first 34 LBAs of a block device. Best regards Heinrich > > Abner > > > For the server platform there might be an interest to run PCIe ROMs. So > their storage format may have to be supported. But as long as these do > not exist as native RISC-V code this will require emulating x86 code. > > Best regards > > Heinrich > > > > > The above is enough IMO. > > Regards, > > Abner > > > > Thanks > > Rahul > > > > On Wed, Apr 21, 2021 at 12:08 PM Abner Chang > <renba.chang@... <mailto:renba.chang@...> > > <mailto:renba.chang@... <mailto:renba.chang@...>>> > wrote: > > > > > > My reviews are inline below which is apart from the > > below recommendations if you don't think that is better. > > > > > > We have Linux2022 as the base feature set for all kinds of > > platform, however, there are many external references to > EBBR in > > this section and EBBR is in the reduced UEFI scope and the > base > > requirement is mainly for the embedded platform We also have > > Embedded2022 section specifically to embedded system and there > > is a Base sub-section for it. The above confuses me. > > Could we just have a simple and generic description in > Linux2022 > > that replaces all of EBBR references, then point to > > Embede2022 in Linux2022 for the detailed implementation of the > > embedded platform? Also, have the references to EBBR in > > Embede2022. Is this clear than the current layout of spec? > > > > For example, > > +===== Firmware > > .... > > .... > > +- For compliance with base specification platform must > implement > > > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR>> > > - UEFI Required Elements], > > Below would be implemented for UEFI firmware system for the > > compliance with base specification, just some implementations > > may be omitted based on the requirements of different RISC-V > > platforms > > - EFI_SYSTEM_TABLE > > - EFI_BOOT_SERVICES > > - EFI_ RUNTIME_SERVICES > > - Required EFI protocols for the base specification. > > - Required EFI protocols for the platform. > > Refer to Embedded2022 for the detailed implementations of the > > above requirements. > > Refer to Server2022 for the detailed implementations of the > > above requirements. > > > > In Embedded2022 section, put links to refer to EBBR. > > In Server section, we can just refer to UEFI spec if the > > requirement needs full UEFI scope support. > > > > This reduces the confusion and increases the readability > to the > > audience. Otherwise, it would be hard to read for the Server > > platform because Server2022 would base on Linux2022 plus the > > extensions. And some of the requirements that refer to EBBR > > would be overridden because of the deviations for the server > > platform. > > > > > > Rahul Pathak <rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>> 於 2021年4月20日週二下午 > > 8:23寫道： > > > > Initial changes for the Base Boot & Runtime requirements. > > The sections which are currently in-progress are > marked as TBD. > > These changes can serve as the starting point and more > > details/changes > > can be done tailored for RISC-V. > > This is the main patch, there are minor changes in the > > contributors file > > and the changelog which are not relevant for now so I > am not > > sending those. > > > > Signed-off-by: Rahul Pathak <rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>> > > --- > > riscv-platform-spec.adoc \| 125 > > ++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 118 insertions(+), 7 deletions(-) > > > > diff --git a/riscv-platform-spec.adoc > b/riscv-platform-spec.adoc > > index 5d3b9c3..601fb61 100644 > > --- a/riscv-platform-spec.adoc > > +++ b/riscv-platform-spec.adoc > > @@ -32,6 +32,36 @@ include::profiles.adoc[] > > // Linux-2022 Platform > > == Linux-2022 Platform > > > > +=== Terminology > > +[cols="1,2", width=80%, align="left", options="header"] > > +\|=== > > +\|TERM \| DESCRIPTION > > +\|SBI \| Supervisor Binary Interface > > +\|UEFI \| Unified Extensible Firmware Interface > > +\|ACPI \| Advanced Configuration and Power Interface > > +\|SMBIOS \| System Management Basic I/O System > > +\|DTS \| Devicetree source file > > +\|DTB \| Devicetree binary > > +\|RVA22 \| RISC-V Application 2022 > > +\|RV32GC \| RISC-V 32-bit general purpose ISA > described as > > RV32IMAFDC. > > +\|RV64GC \| RISC-V 64-bit general purpose ISA > described as > > RV64IMAFDC. > > +\|=== > > + > > + > > +=== Specifications > > +[cols="1,2", width=80%, align="left", options="header"] > > +\|=== > > +\|SPECIFICATION \| VERSION > > > +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > > > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI>> > > Specification] \| v2.9 > > > +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > > > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree>> > > Specification] \| v0.3 > > > +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > > > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI>> > > Specification] \| v0.3-rc0 > > +\|link:[RVA22 Specification] > > \| TBD > > +\|link:https://arm-software.github.io/ebbr/[EBBR > <https://arm-software.github.io/ebbr/%5BEBBR> > > <https://arm-software.github.io/ebbr/%5BEBBR > <https://arm-software.github.io/ebbr/%5BEBBR>> > > Specification] > > \| v2.0.0-pre1 > > > +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > > > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI>> > > Specification] \| v6.4 > > > +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > > > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS>> > > Specification] \| v3.4.0 > > +\|link:[Platform Policy] > > \| TBD > > +\|=== > > + > > // Base feature set for Linux-2022 Platform > > === Base > > ==== Architecture > > @@ -57,14 +87,95 @@ include::profiles.adoc[] > > * Timers > > * Watchdog Timers > > > > -==== Boot Process > > -* Firmware > > -* Boot-Loader > > -* Discovery Mechanisms > > +==== Boot and Runtime Requirements > > +- The base specification defines the interface > between the > > firmware and the > > +operating system suitable for the RISC-V platforms with > > rich operating > > +systems. > > +- These requirements specifies the required boot and > > runtime services, device > > +discovery mechanism, etc. > > +- The requirements are operating system agnostic, > specific > > firmware/bootloader > > +implementation agnostic. > > +- The base boot specification depends on the RVA22 > profile > > and all requirements > > +from the RVA22 profile must be implemented. > > +- The base runtime specification depends on the > RISC-V SBI > > specification and > > +all requirements from the SBI spec must be implemented. > > +- Any RV32GC or RV64GC system with Machine, > Supervisor and > > User Mode can comply > > +with the base specification. Hypervisor Extension is > optional. > > +_Will be defined in this spec if the RVA22 spec > does not > > mention it._ > > +- For the generic mandatory requirements this base > > specification will refer to > > +the EBBR Specification. Any deviation from the EBBR > will be > > explicitly > > +mentioned in the requirements. > > > > +- Specifications followed are mentioned in the > > +<<Specifications,Specification Section>> > > +- For more on scope of MANDATORY, DEPRECATED, > COMPATIBILITY > > refer Platform > > +Policy Specification. > > + > > + > > +===== Firmware > > +- UEFI Platform must meet RISC-V Platform requirements on > > calling conventions, > > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 > > RISC-V Platforms of UEFI > > +specification. > > +- For compliance with base specification platform must > > implement > > > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR>> - > > UEFI Required Elements], > > > > > > > +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR>> > > - UEFI Platform Specific Elements] > > +and support the following > > > > > > > +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> > > > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR>> > > - Global Variables]. > > + > > +====== Block Device Partition Format > > > > Better to name it as "Firmware Block Device Partition Format" > > becasue the link to EBBR is specifically talks about how to > > store firmware image. > > > > +- Firmware must implement the support for GPT > Partitioning > > and meet the > > +requirements as per the > > > +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> > > Firmware Storage]. > > > > This is what I said it may confuse audiences becasue UEFI PI > > spec volume3 also defines the format of firmware image > which is > > used by edk2 and which is very different than the one > defined in > > EBBR. > > Can we add the below sentence, > > Firmware must implement the require EFI protocols if the > > firmware image is stored in the format which complaint with > > section 2 "Firmware Storage Design Discussion" in UEFI PI > > specification volume3. > > > > + > > +===== Boot Services > > +- Base specification compliant firmware must > implement all > > UEFI functions > > +marked as EFI_BOOT_SERVICES. > > + > > +====== Startup Protocol > > +- UEFI firmware could be executed in either Machine > mode or > > Supervisor mode > > +during the entire POST, according to the hart capability > > and the platform > > +design. For firmware privilege mode requirements, mode > > switch and the handover > > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V > Platforms. > > +- Before yielding control to S-Mode stage, firmware must > > configure the M-Mode > > +state. Refer the RISC-V SBI specification for details. > > +- If the Hypervisor Extension is implemented. TBD. > > + > > + > > +====== Memory Map > > +- UEFI environment must provide a system memory map and > > meet the requirements > > +for > > > link:https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR> > > <https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR>> - > > Memory Map]. > > > > + > > +===== Boot-Loader > > +TBD > > + > > +===== Discovery Mechanisms > > +- The base specification mandates the use of > Devicetree for > > system description. > > +- System must meet > > > link:https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR> > > <https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR>> - > > Devicetree requirements] > > +to comply with this base specification. Also refer > > Devicetree tables section > > +in chapter - 4.6 EFI Configuration Table & Properties > Table > > of UEFI > > +specification. > > > > Could we add something regarding to SMBIOS? > > "If platform requires SMBIOS on UEFI system, the SMBIOS table > > must be installed to EFI Configuration Table according to 4.6 > > EFI Configuration Table & Properties Table of UEFI > > specification." > > > > Abner > > > > > > -==== Runtime services > > -* SBI > > -* UEFI > > +===== Runtime Services > > +====== SBI > > +- Firmware must implement the runtime services/extensions > > specified by the > > +RISC-V SBI Specification. > > +- Wherever applicable firmware must implement UEFI > > interfaces over similar > > +interfaces and services present in the SBI specification. > > For example, UEFI > > +runtime services must implement ResetSystem() via SBI > Reset > > extension. > > +- Legacy Extensions from the SBI Specification are > > deprecated and must not be > > +implemented. > > + > > +====== UEFI > > +- Firmware must conform to the > > > +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > > > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR>> > > - UEFI EFI_RUNTIME_SERVICES requirements]. > > +- Firmware must meet the requirements for > > > +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > > > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR>> > > - Runtime Device Mappings] > > +to avoid conflict between the firmware and OS when > > accessing the mapped > > +devices. > > +- Compliant UEFI runtime environment must meet the > > requirements for the > > > +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > > > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR>> > > - Runtime Variable Access]. > > +- Compliant implementation must meet the Realtime Clock > > requirements > > > +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > > > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR>> > > - UEFI RTC interface] > > +if RTC is present in the system. > > > > // Server extension for Linux-2022 Platform > > === Server Extension > > -- > > 2.25.1 > > > > > > > > >
More All Messages By This Member
Abner Chang #863 Heinrich Schuchardt <xypron.glpk@...> 於 2021年5月5日週三下午5:47寫道： On 05.05.21 10:31, Abner Chang wrote: > > > Heinrich Schuchardt <xypron.glpk@... <mailto:xypron.glpk@...>> 於 > 2021年5月4日週二下午2:11寫道： > > On 5/4/21 7:14 AM, Abner Chang wrote: > > Hi Rahul, my responses in below. > > > > Rahul Pathak <rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>> 於 2021年5月3日週一下午9:55寫道： > > > > Hi Abner, > > > > I read the UEFI PI Vol2 section. Need to understand if EBBR > > requirements on the format are not sufficient to achieve the > > minimum requirements for compliance. > > Also what those UEFI Protocols must be if the format is compliant > > with Section 2 of UEFI PI. > > > > EBBR is defined for the embedded platform with the minimum > requirements > > We are using the term "embedded platform" for RTOS systems. These don't > use UEFI at all. Do you mean "Linux Platform"? > > I mean the EBBR itself is defined for the embedded platform > as mentioned in the Introduction. > > > > of UEFI to boot to UEFI OS, the majority of firmware implementation > > would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I > > don't know if the current uboot support PI FW format (I don't > think so), > > U-Boot only implements the EBBR subset of the UEFI spec. > > U-Boot does not target the UEFI Platform Initialization Specification. > > EBBR does not require implementing the PI spec. > > right. > > > > if not, then it would be the effort to support PI firmware image > format > > and I have no idea if EBBR would like to accommodate PI FW image > format > > for the embedded system. But yes, obviously, the current EBBR > > requirements on FW image format doesn't support PI spec. Also, I don't > > think uboot needs to support FV format because the file format is > > defined for EFI drivers. > > > > I list the protocols currently support in EDK2 for UEFI/PI FW > image format, > > EFI_PEI_FIRMWARE_VOLUME_INFO_PPI > > EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI > > EFI_PEI_FIRMWARE_VOLUMN_PPI > > EFI_FIRMWARE_VOLUME2_PROTOCOL > > EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL > > EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL > > Almost the entire section3 in PI spec Vol3 is covered. > > > > That is hard to say which Protocols or PPIs are necessary for the > PI FW > > format because the above are two different sets for EFI PEI phase and > > DXE phase. Firmware other than edk2 doesn't have those phases, > non-edk2 > > firmware such as uboot just need the code to parse firmware storage > > format if uboot would like to read the drivers from firmware volume. > > EDK II complies with the PI spec. But I see no need to refer to this > spec in the base boot requirements. > > The reason is if EDK2 is the firmware for Linux2022, is the firmware > must be stored in the GPT? Can't firmware store in SPI and compliant > with PI Firmware device format? Up to now this spec does not require EDK II but the provision of APIs. We should keep it this way. EDK II can live on either SPI or on MMC or on an SD card. For developement it is preferable to have it on an SD card and not in SPI flash. Hi Heinrich, I was saying the SPI use case. Linux2022 is the base requirements that Server extension is based on, is my understanding correct? For the server platform, the most use case is FW image on SPI. Why should we care about the PI spec at all? It is irrelevant for booting an operating system. It says below in this patch, +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage]. The link says where and how the firmware image is stored in firmware storage, but what is the firmware storage for edk2 if it stored in SPI? PI is needed, right? Maybe the link leads to the confusion as Sunil mentioend. For firmware update we should not care about the firmware storage format but about the UpdateCapsule() service. > > > > > > For the RISC-V LinuxBoot 2022 spec, we can simply say something like > > below to avoid the EBBR effort, > > On many systems U-Boot is stored between the master boot record and the > first partition. EBBR chapter 4 requires that this area is not > overwritten. Further it favors GPT over MBR partitioning. > > > If the firmware image is stored in the Block Device Partition format, > > What defines the "Block Device Partition format"? > > It is from EBBR spec as I can tell. The term "Block Device Partition" does not exist in the EBBR. Is that 2.2.4 in https://arm-software.github.io/ebbr/? Abner > > > Do you mean "if the firmware is stored as raw data on a block device"? > > I think so. Then we should write it in clear terms. > > > > firmware must implement the support for GPT Partitioning and meet the > > requirements as per the > > link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> Firmware > > Storage]. > > On some legacy U-Boot platforms we have the problem that the boot ROM > tries to read the next boot stage from one of the first 34 sectors. This > conflicts with GPT partitioning. > > We should require that if boot ROMs read from the next boot stage from a > block device, the storage location must be in LBA 34 or higher. > > If the firmware is read from a file system (see Raspberry Pi), the > firmware should be required to support GPT partitioning (the Raspberry > Pi requires MBR partitioning). > > > If the platform chooses UEFI/PI firmware storage as the format for the > > firmware images, firmware must have the implementation which supports > > the firmware storage format defined in UEFI/PI specification Vol3 > > section 3 [Link to PI sepc]. > > What is the benefit of requiring: if you store information as X, you > should be able to read X? I suggest to keep the storage format of > firmware outside of the scope for the Linux platform. > > If we say " firmware must implement the support for GPT Partitioning" > then we should also mention PI firmware storage format for the case of > using edk2 as FW for Linux platform. No why? GPT partitioning and protective partitions to safeguard the firmware are completely independent of the binary format of the firmware. We should not care about implementation details of the firmware. It is enough to prescribe what functionality the firmware must expose. > Otherwise, I am also fine with not mentioning anything of storage format. We still should mention that the firmware must support GPT and that the firmware must not be stored in the first 34 LBAs of a block device. Best regards Heinrich > > Abner > > > For the server platform there might be an interest to run PCIe ROMs. So > their storage format may have to be supported. But as long as these do > not exist as native RISC-V code this will require emulating x86 code. > > Best regards > > Heinrich > > > > > The above is enough IMO. > > Regards, > > Abner > > > > Thanks > > Rahul > > > > On Wed, Apr 21, 2021 at 12:08 PM Abner Chang > <renba.chang@... <mailto:renba.chang@...> > > <mailto:renba.chang@... <mailto:renba.chang@...>>> > wrote: > > > > > > My reviews are inline below which is apart from the > > below recommendations if you don't think that is better. > > > > > > We have Linux2022 as the base feature set for all kinds of > > platform, however, there are many external references to > EBBR in > > this section and EBBR is in the reduced UEFI scope and the > base > > requirement is mainly for the embedded platform We also have > > Embedded2022 section specifically to embedded system and there > > is a Base sub-section for it. The above confuses me. > > Could we just have a simple and generic description in > Linux2022 > > that replaces all of EBBR references, then point to > > Embede2022 in Linux2022 for the detailed implementation of the > > embedded platform? Also, have the references to EBBR in > > Embede2022. Is this clear than the current layout of spec? > > > > For example, > > +===== Firmware > > .... > > .... > > +- For compliance with base specification platform must > implement > > > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR>> > > - UEFI Required Elements], > > Below would be implemented for UEFI firmware system for the > > compliance with base specification, just some implementations > > may be omitted based on the requirements of different RISC-V > > platforms > > - EFI_SYSTEM_TABLE > > - EFI_BOOT_SERVICES > > - EFI_ RUNTIME_SERVICES > > - Required EFI protocols for the base specification. > > - Required EFI protocols for the platform. > > Refer to Embedded2022 for the detailed implementations of the > > above requirements. > > Refer to Server2022 for the detailed implementations of the > > above requirements. > > > > In Embedded2022 section, put links to refer to EBBR. > > In Server section, we can just refer to UEFI spec if the > > requirement needs full UEFI scope support. > > > > This reduces the confusion and increases the readability > to the > > audience. Otherwise, it would be hard to read for the Server > > platform because Server2022 would base on Linux2022 plus the > > extensions. And some of the requirements that refer to EBBR > > would be overridden because of the deviations for the server > > platform. > > > > > > Rahul Pathak <rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>> 於 2021年4月20日週二下午 > > 8:23寫道： > > > > Initial changes for the Base Boot & Runtime requirements. > > The sections which are currently in-progress are > marked as TBD. > > These changes can serve as the starting point and more > > details/changes > > can be done tailored for RISC-V. > > This is the main patch, there are minor changes in the > > contributors file > > and the changelog which are not relevant for now so I > am not > > sending those. > > > > Signed-off-by: Rahul Pathak <rpathak@... > <mailto:rpathak@...> > > <mailto:rpathak@... > <mailto:rpathak@...>>> > > --- > > riscv-platform-spec.adoc \| 125 > > ++++++++++++++++++++++++++++++++++++--- > > 1 file changed, 118 insertions(+), 7 deletions(-) > > > > diff --git a/riscv-platform-spec.adoc > b/riscv-platform-spec.adoc > > index 5d3b9c3..601fb61 100644 > > --- a/riscv-platform-spec.adoc > > +++ b/riscv-platform-spec.adoc > > @@ -32,6 +32,36 @@ include::profiles.adoc[] > > // Linux-2022 Platform > > == Linux-2022 Platform > > > > +=== Terminology > > +[cols="1,2", width=80%, align="left", options="header"] > > +\|=== > > +\|TERM \| DESCRIPTION > > +\|SBI \| Supervisor Binary Interface > > +\|UEFI \| Unified Extensible Firmware Interface > > +\|ACPI \| Advanced Configuration and Power Interface > > +\|SMBIOS \| System Management Basic I/O System > > +\|DTS \| Devicetree source file > > +\|DTB \| Devicetree binary > > +\|RVA22 \| RISC-V Application 2022 > > +\|RV32GC \| RISC-V 32-bit general purpose ISA > described as > > RV32IMAFDC. > > +\|RV64GC \| RISC-V 64-bit general purpose ISA > described as > > RV64IMAFDC. > > +\|=== > > + > > + > > +=== Specifications > > +[cols="1,2", width=80%, align="left", options="header"] > > +\|=== > > +\|SPECIFICATION \| VERSION > > > +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > > > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI>> > > Specification] \| v2.9 > > > +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > > > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree>> > > Specification] \| v0.3 > > > +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > > > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI>> > > Specification] \| v0.3-rc0 > > +\|link:[RVA22 Specification] > > \| TBD > > +\|link:https://arm-software.github.io/ebbr/[EBBR > <https://arm-software.github.io/ebbr/%5BEBBR> > > <https://arm-software.github.io/ebbr/%5BEBBR > <https://arm-software.github.io/ebbr/%5BEBBR>> > > Specification] > > \| v2.0.0-pre1 > > > +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > > > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI>> > > Specification] \| v6.4 > > > +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > > > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS>> > > Specification] \| v3.4.0 > > +\|link:[Platform Policy] > > \| TBD > > +\|=== > > + > > // Base feature set for Linux-2022 Platform > > === Base > > ==== Architecture > > @@ -57,14 +87,95 @@ include::profiles.adoc[] > > * Timers > > * Watchdog Timers > > > > -==== Boot Process > > -* Firmware > > -* Boot-Loader > > -* Discovery Mechanisms > > +==== Boot and Runtime Requirements > > +- The base specification defines the interface > between the > > firmware and the > > +operating system suitable for the RISC-V platforms with > > rich operating > > +systems. > > +- These requirements specifies the required boot and > > runtime services, device > > +discovery mechanism, etc. > > +- The requirements are operating system agnostic, > specific > > firmware/bootloader > > +implementation agnostic. > > +- The base boot specification depends on the RVA22 > profile > > and all requirements > > +from the RVA22 profile must be implemented. > > +- The base runtime specification depends on the > RISC-V SBI > > specification and > > +all requirements from the SBI spec must be implemented. > > +- Any RV32GC or RV64GC system with Machine, > Supervisor and > > User Mode can comply > > +with the base specification. Hypervisor Extension is > optional. > > +_Will be defined in this spec if the RVA22 spec > does not > > mention it._ > > +- For the generic mandatory requirements this base > > specification will refer to > > +the EBBR Specification. Any deviation from the EBBR > will be > > explicitly > > +mentioned in the requirements. > > > > +- Specifications followed are mentioned in the > > +<<Specifications,Specification Section>> > > +- For more on scope of MANDATORY, DEPRECATED, > COMPATIBILITY > > refer Platform > > +Policy Specification. > > + > > + > > +===== Firmware > > +- UEFI Platform must meet RISC-V Platform requirements on > > calling conventions, > > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 > > RISC-V Platforms of UEFI > > +specification. > > +- For compliance with base specification platform must > > implement > > > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR>> - > > UEFI Required Elements], > > > > > > > +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > > > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR>> > > - UEFI Platform Specific Elements] > > +and support the following > > > > > > > +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> > > > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR>> > > - Global Variables]. > > + > > +====== Block Device Partition Format > > > > Better to name it as "Firmware Block Device Partition Format" > > becasue the link to EBBR is specifically talks about how to > > store firmware image. > > > > +- Firmware must implement the support for GPT > Partitioning > > and meet the > > +requirements as per the > > > +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > > > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> > > Firmware Storage]. > > > > This is what I said it may confuse audiences becasue UEFI PI > > spec volume3 also defines the format of firmware image > which is > > used by edk2 and which is very different than the one > defined in > > EBBR. > > Can we add the below sentence, > > Firmware must implement the require EFI protocols if the > > firmware image is stored in the format which complaint with > > section 2 "Firmware Storage Design Discussion" in UEFI PI > > specification volume3. > > > > + > > +===== Boot Services > > +- Base specification compliant firmware must > implement all > > UEFI functions > > +marked as EFI_BOOT_SERVICES. > > + > > +====== Startup Protocol > > +- UEFI firmware could be executed in either Machine > mode or > > Supervisor mode > > +during the entire POST, according to the hart capability > > and the platform > > +design. For firmware privilege mode requirements, mode > > switch and the handover > > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V > Platforms. > > +- Before yielding control to S-Mode stage, firmware must > > configure the M-Mode > > +state. Refer the RISC-V SBI specification for details. > > +- If the Hypervisor Extension is implemented. TBD. > > + > > + > > +====== Memory Map > > +- UEFI environment must provide a system memory map and > > meet the requirements > > +for > > > link:https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR> > > <https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR>> - > > Memory Map]. > > > > + > > +===== Boot-Loader > > +TBD > > + > > +===== Discovery Mechanisms > > +- The base specification mandates the use of > Devicetree for > > system description. > > +- System must meet > > > link:https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR> > > <https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR>> - > > Devicetree requirements] > > +to comply with this base specification. Also refer > > Devicetree tables section > > +in chapter - 4.6 EFI Configuration Table & Properties > Table > > of UEFI > > +specification. > > > > Could we add something regarding to SMBIOS? > > "If platform requires SMBIOS on UEFI system, the SMBIOS table > > must be installed to EFI Configuration Table according to 4.6 > > EFI Configuration Table & Properties Table of UEFI > > specification." > > > > Abner > > > > > > -==== Runtime services > > -* SBI > > -* UEFI > > +===== Runtime Services > > +====== SBI > > +- Firmware must implement the runtime services/extensions > > specified by the > > +RISC-V SBI Specification. > > +- Wherever applicable firmware must implement UEFI > > interfaces over similar > > +interfaces and services present in the SBI specification. > > For example, UEFI > > +runtime services must implement ResetSystem() via SBI > Reset > > extension. > > +- Legacy Extensions from the SBI Specification are > > deprecated and must not be > > +implemented. > > + > > +====== UEFI > > +- Firmware must conform to the > > > +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > > > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR>> > > - UEFI EFI_RUNTIME_SERVICES requirements]. > > +- Firmware must meet the requirements for > > > +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > > > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR>> > > - Runtime Device Mappings] > > +to avoid conflict between the firmware and OS when > > accessing the mapped > > +devices. > > +- Compliant UEFI runtime environment must meet the > > requirements for the > > > +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > > > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR>> > > - Runtime Variable Access]. > > +- Compliant implementation must meet the Realtime Clock > > requirements > > > +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > > > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR>> > > - UEFI RTC interface] > > +if RTC is present in the system. > > > > // Server extension for Linux-2022 Platform > > === Server Extension > > -- > > 2.25.1 > > > > > > > > >
More All Messages By This Member
Heinrich Schuchardt #860 On 05.05.21 10:31, Abner Chang wrote: Heinrich Schuchardt <xypron.glpk@... <mailto:xypron.glpk@...>> 於 2021年5月4日週二下午2:11寫道： On 5/4/21 7:14 AM, Abner Chang wrote: > Hi Rahul, my responses in below. > > Rahul Pathak <rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>>> 於 2021年5月3日週一下午9:55寫道： > > Hi Abner, > > I read the UEFI PI Vol2 section. Need to understand if EBBR > requirements on the format are not sufficient to achieve the > minimum requirements for compliance. > Also what those UEFI Protocols must be if the format is compliant > with Section 2 of UEFI PI. > > EBBR is defined for the embedded platform with the minimum requirements We are using the term "embedded platform" for RTOS systems. These don't use UEFI at all. Do you mean "Linux Platform"? I mean the EBBR itself is defined for the embedded platform as mentioned in the Introduction. > of UEFI to boot to UEFI OS, the majority of firmware implementation > would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I > don't know if the current uboot support PI FW format (I don't think so), U-Boot only implements the EBBR subset of the UEFI spec. U-Boot does not target the UEFI Platform Initialization Specification. EBBR does not require implementing the PI spec. right. > if not, then it would be the effort to support PI firmware image format > and I have no idea if EBBR would like to accommodate PI FW image format > for the embedded system. But yes, obviously, the current EBBR > requirements on FW image format doesn't support PI spec. Also, I don't > think uboot needs to support FV format because the file format is > defined for EFI drivers. > > I list the protocols currently support in EDK2 for UEFI/PI FW image format, > EFI_PEI_FIRMWARE_VOLUME_INFO_PPI > EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI > EFI_PEI_FIRMWARE_VOLUMN_PPI > EFI_FIRMWARE_VOLUME2_PROTOCOL > EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL > EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL > Almost the entire section3 in PI spec Vol3 is covered. > > That is hard to say which Protocols or PPIs are necessary for the PI FW > format because the above are two different sets for EFI PEI phase and > DXE phase. Firmware other than edk2 doesn't have those phases, non-edk2 > firmware such as uboot just need the code to parse firmware storage > format if uboot would like to read the drivers from firmware volume. EDK II complies with the PI spec. But I see no need to refer to this spec in the base boot requirements. The reason is if EDK2 is the firmware for Linux2022, is the firmware must be stored in the GPT? Can't firmware store in SPI and compliant with PI Firmware device format? Up to now this spec does not require EDK II but the provision of APIs. We should keep it this way. EDK II can live on either SPI or on MMC or on an SD card. For developement it is preferable to have it on an SD card and not in SPI flash. Why should we care about the PI spec at all? It is irrelevant for booting an operating system. For firmware update we should not care about the firmware storage format but about the UpdateCapsule() service. > > For the RISC-V LinuxBoot 2022 spec, we can simply say something like > below to avoid the EBBR effort, On many systems U-Boot is stored between the master boot record and the first partition. EBBR chapter 4 requires that this area is not overwritten. Further it favors GPT over MBR partitioning. > If the firmware image is stored in the Block Device Partition format, What defines the "Block Device Partition format"? It is from EBBR spec as I can tell. The term "Block Device Partition" does not exist in the EBBR. Do you mean "if the firmware is stored as raw data on a block device"? I think so. Then we should write it in clear terms. > firmware must implement the support for GPT Partitioning and meet the > requirements as per the > link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> Firmware > Storage]. On some legacy U-Boot platforms we have the problem that the boot ROM tries to read the next boot stage from one of the first 34 sectors. This conflicts with GPT partitioning. We should require that if boot ROMs read from the next boot stage from a block device, the storage location must be in LBA 34 or higher. If the firmware is read from a file system (see Raspberry Pi), the firmware should be required to support GPT partitioning (the Raspberry Pi requires MBR partitioning). > If the platform chooses UEFI/PI firmware storage as the format for the > firmware images, firmware must have the implementation which supports > the firmware storage format defined in UEFI/PI specification Vol3 > section 3 [Link to PI sepc]. What is the benefit of requiring: if you store information as X, you should be able to read X? I suggest to keep the storage format of firmware outside of the scope for the Linux platform. If we say " firmware must implement the support for GPT Partitioning" then we should also mention PI firmware storage format for the case of using edk2 as FW for Linux platform. No why? GPT partitioning and protective partitions to safeguard the firmware are completely independent of the binary format of the firmware. We should not care about implementation details of the firmware. It is enough to prescribe what functionality the firmware must expose. Otherwise, I am also fine with not mentioning anything of storage format. We still should mention that the firmware must support GPT and that the firmware must not be stored in the first 34 LBAs of a block device. Best regards Heinrich Abner For the server platform there might be an interest to run PCIe ROMs. So their storage format may have to be supported. But as long as these do not exist as native RISC-V code this will require emulating x86 code. Best regards Heinrich > > The above is enough IMO. > Regards, > Abner > > Thanks > Rahul > > On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@... <mailto:renba.chang@...> > <mailto:renba.chang@... <mailto:renba.chang@...>>> wrote: > > > My reviews are inline below which is apart from the > below recommendations if you don't think that is better. > > > We have Linux2022 as the base feature set for all kinds of > platform, however, there are many external references to EBBR in > this section and EBBR is in the reduced UEFI scope and the base > requirement is mainly for the embedded platform We also have > Embedded2022 section specifically to embedded system and there > is a Base sub-section for it. The above confuses me. > Could we just have a simple and generic description in Linux2022 > that replaces all of EBBR references, then point to > Embede2022 in Linux2022 for the detailed implementation of the > embedded platform? Also, have the references to EBBR in > Embede2022. Is this clear than the current layout of spec? > > For example, > +===== Firmware > .... > .... > +- For compliance with base specification platform must implement > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> <https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR>> > - UEFI Required Elements], > Below would be implemented for UEFI firmware system for the > compliance with base specification, just some implementations > may be omitted based on the requirements of different RISC-V > platforms > - EFI_SYSTEM_TABLE > - EFI_BOOT_SERVICES > - EFI_ RUNTIME_SERVICES > - Required EFI protocols for the base specification. > - Required EFI protocols for the platform. > Refer to Embedded2022 for the detailed implementations of the > above requirements. > Refer to Server2022 for the detailed implementations of the > above requirements. > > In Embedded2022 section, put links to refer to EBBR. > In Server section, we can just refer to UEFI spec if the > requirement needs full UEFI scope support. > > This reduces the confusion and increases the readability to the > audience. Otherwise, it would be hard to read for the Server > platform because Server2022 would base on Linux2022 plus the > extensions. And some of the requirements that refer to EBBR > would be overridden because of the deviations for the server > platform. > > > Rahul Pathak <rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>>> 於 2021年4月20日週二下午 > 8:23寫道： > > Initial changes for the Base Boot & Runtime requirements. > The sections which are currently in-progress are marked as TBD. > These changes can serve as the starting point and more > details/changes > can be done tailored for RISC-V. > This is the main patch, there are minor changes in the > contributors file > and the changelog which are not relevant for now so I am not > sending those. > > Signed-off-by: Rahul Pathak <rpathak@... <mailto:rpathak@...> > <mailto:rpathak@... <mailto:rpathak@...>>> > --- > riscv-platform-spec.adoc \| 125 > ++++++++++++++++++++++++++++++++++++--- > 1 file changed, 118 insertions(+), 7 deletions(-) > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc > index 5d3b9c3..601fb61 100644 > --- a/riscv-platform-spec.adoc > +++ b/riscv-platform-spec.adoc > @@ -32,6 +32,36 @@ include::profiles.adoc[] > // Linux-2022 Platform > == Linux-2022 Platform > > +=== Terminology > +[cols="1,2", width=80%, align="left", options="header"] > +\|=== > +\|TERM \| DESCRIPTION > +\|SBI \| Supervisor Binary Interface > +\|UEFI \| Unified Extensible Firmware Interface > +\|ACPI \| Advanced Configuration and Power Interface > +\|SMBIOS \| System Management Basic I/O System > +\|DTS \| Devicetree source file > +\|DTB \| Devicetree binary > +\|RVA22 \| RISC-V Application 2022 > +\|RV32GC \| RISC-V 32-bit general purpose ISA described as > RV32IMAFDC. > +\|RV64GC \| RISC-V 64-bit general purpose ISA described as > RV64IMAFDC. > +\|=== > + > + > +=== Specifications > +[cols="1,2", width=80%, align="left", options="header"] > +\|=== > +\|SPECIFICATION \| VERSION > +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI>> > Specification] \| v2.9 > +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree>> > Specification] \| v0.3 > +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI>> > Specification] \| v0.3-rc0 > +\|link:[RVA22 Specification] > \| TBD > +\|link:https://arm-software.github.io/ebbr/[EBBR <https://arm-software.github.io/ebbr/%5BEBBR> > <https://arm-software.github.io/ebbr/%5BEBBR <https://arm-software.github.io/ebbr/%5BEBBR>> > Specification] > \| v2.0.0-pre1 > +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI>> > Specification] \| v6.4 > +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS>> > Specification] \| v3.4.0 > +\|link:[Platform Policy] > \| TBD > +\|=== > + > // Base feature set for Linux-2022 Platform > === Base > ==== Architecture > @@ -57,14 +87,95 @@ include::profiles.adoc[] > * Timers > * Watchdog Timers > > -==== Boot Process > -* Firmware > -* Boot-Loader > -* Discovery Mechanisms > +==== Boot and Runtime Requirements > +- The base specification defines the interface between the > firmware and the > +operating system suitable for the RISC-V platforms with > rich operating > +systems. > +- These requirements specifies the required boot and > runtime services, device > +discovery mechanism, etc. > +- The requirements are operating system agnostic, specific > firmware/bootloader > +implementation agnostic. > +- The base boot specification depends on the RVA22 profile > and all requirements > +from the RVA22 profile must be implemented. > +- The base runtime specification depends on the RISC-V SBI > specification and > +all requirements from the SBI spec must be implemented. > +- Any RV32GC or RV64GC system with Machine, Supervisor and > User Mode can comply > +with the base specification. Hypervisor Extension is optional. > +_Will be defined in this spec if the RVA22 spec does not > mention it._ > +- For the generic mandatory requirements this base > specification will refer to > +the EBBR Specification. Any deviation from the EBBR will be > explicitly > +mentioned in the requirements. > > +- Specifications followed are mentioned in the > +<<Specifications,Specification Section>> > +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY > refer Platform > +Policy Specification. > + > + > +===== Firmware > +- UEFI Platform must meet RISC-V Platform requirements on > calling conventions, > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 > RISC-V Platforms of UEFI > +specification. > +- For compliance with base specification platform must > implement > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR>> - > UEFI Required Elements], > > > +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR>> > - UEFI Platform Specific Elements] > +and support the following > > > +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR>> > - Global Variables]. > + > +====== Block Device Partition Format > > Better to name it as "Firmware Block Device Partition Format" > becasue the link to EBBR is specifically talks about how to > store firmware image. > > +- Firmware must implement the support for GPT Partitioning > and meet the > +requirements as per the > +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR>> > Firmware Storage]. > > This is what I said it may confuse audiences becasue UEFI PI > spec volume3 also defines the format of firmware image which is > used by edk2 and which is very different than the one defined in > EBBR. > Can we add the below sentence, > Firmware must implement the require EFI protocols if the > firmware image is stored in the format which complaint with > section 2 "Firmware Storage Design Discussion" in UEFI PI > specification volume3. > > + > +===== Boot Services > +- Base specification compliant firmware must implement all > UEFI functions > +marked as EFI_BOOT_SERVICES. > + > +====== Startup Protocol > +- UEFI firmware could be executed in either Machine mode or > Supervisor mode > +during the entire POST, according to the hart capability > and the platform > +design. For firmware privilege mode requirements, mode > switch and the handover > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. > +- Before yielding control to S-Mode stage, firmware must > configure the M-Mode > +state. Refer the RISC-V SBI specification for details. > +- If the Hypervisor Extension is implemented. TBD. > + > + > +====== Memory Map > +- UEFI environment must provide a system memory map and > meet the requirements > +for > link:https://arm-software.github.io/ebbr/#memory-map[EBBR <https://arm-software.github.io/ebbr/#memory-map[EBBR> > <https://arm-software.github.io/ebbr/#memory-map[EBBR <https://arm-software.github.io/ebbr/#memory-map[EBBR>> - > Memory Map]. > > + > +===== Boot-Loader > +TBD > + > +===== Discovery Mechanisms > +- The base specification mandates the use of Devicetree for > system description. > +- System must meet > link:https://arm-software.github.io/ebbr/#devicetree[EBBR <https://arm-software.github.io/ebbr/#devicetree[EBBR> > <https://arm-software.github.io/ebbr/#devicetree[EBBR <https://arm-software.github.io/ebbr/#devicetree[EBBR>> - > Devicetree requirements] > +to comply with this base specification. Also refer > Devicetree tables section > +in chapter - 4.6 EFI Configuration Table & Properties Table > of UEFI > +specification. > > Could we add something regarding to SMBIOS? > "If platform requires SMBIOS on UEFI system, the SMBIOS table > must be installed to EFI Configuration Table according to 4.6 > EFI Configuration Table & Properties Table of UEFI > specification." > > Abner > > > -==== Runtime services > -* SBI > -* UEFI > +===== Runtime Services > +====== SBI > +- Firmware must implement the runtime services/extensions > specified by the > +RISC-V SBI Specification. > +- Wherever applicable firmware must implement UEFI > interfaces over similar > +interfaces and services present in the SBI specification. > For example, UEFI > +runtime services must implement ResetSystem() via SBI Reset > extension. > +- Legacy Extensions from the SBI Specification are > deprecated and must not be > +implemented. > + > +====== UEFI > +- Firmware must conform to the > +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR>> > - UEFI EFI_RUNTIME_SERVICES requirements]. > +- Firmware must meet the requirements for > +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR>> > - Runtime Device Mappings] > +to avoid conflict between the firmware and OS when > accessing the mapped > +devices. > +- Compliant UEFI runtime environment must meet the > requirements for the > +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR>> > - Runtime Variable Access]. > +- Compliant implementation must meet the Realtime Clock > requirements > +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR>> > - UEFI RTC interface] > +if RTC is present in the system. > > // Server extension for Linux-2022 Platform > === Server Extension > -- > 2.25.1 > > > >
More All Messages By This Member
Sunil V L #859 On Wed, May 05, 2021 at 04:31:46PM +0800, Abner Chang wrote: Heinrich Schuchardt <xypron.glpk@...> 於 2021年5月4日週二下午2:11寫道： On 5/4/21 7:14 AM, Abner Chang wrote: Hi Rahul, my responses in below. Rahul Pathak <rpathak@... <mailto:rpathak@...>> 於 2021年5月3日週一下午9:55寫道： Hi Abner, I read the UEFI PI Vol2 section. Need to understand if EBBR requirements on the format are not sufficient to achieve the minimum requirements for compliance. Also what those UEFI Protocols must be if the format is compliant with Section 2 of UEFI PI. EBBR is defined for the embedded platform with the minimum requirements We are using the term "embedded platform" for RTOS systems. These don't use UEFI at all. Do you mean "Linux Platform"? I mean the EBBR itself is defined for the embedded platform as mentioned in the Introduction. of UEFI to boot to UEFI OS, the majority of firmware implementation would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I don't know if the current uboot support PI FW format (I don't think so), U-Boot only implements the EBBR subset of the UEFI spec. U-Boot does not target the UEFI Platform Initialization Specification. EBBR does not require implementing the PI spec. right. if not, then it would be the effort to support PI firmware image format and I have no idea if EBBR would like to accommodate PI FW image format for the embedded system. But yes, obviously, the current EBBR requirements on FW image format doesn't support PI spec. Also, I don't think uboot needs to support FV format because the file format is defined for EFI drivers. I list the protocols currently support in EDK2 for UEFI/PI FW image format, EFI_PEI_FIRMWARE_VOLUME_INFO_PPI EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI EFI_PEI_FIRMWARE_VOLUMN_PPI EFI_FIRMWARE_VOLUME2_PROTOCOL EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL Almost the entire section3 in PI spec Vol3 is covered. That is hard to say which Protocols or PPIs are necessary for the PI FW format because the above are two different sets for EFI PEI phase and DXE phase. Firmware other than edk2 doesn't have those phases, non-edk2 firmware such as uboot just need the code to parse firmware storage format if uboot would like to read the drivers from firmware volume. EDK II complies with the PI spec. But I see no need to refer to this spec in the base boot requirements. The reason is if EDK2 is the firmware for Linux2022, is the firmware must be stored in the GPT? Can't firmware store in SPI and compliant with PI Firmware device format? For the RISC-V LinuxBoot 2022 spec, we can simply say something like below to avoid the EBBR effort, On many systems U-Boot is stored between the master boot record and the first partition. EBBR chapter 4 requires that this area is not overwritten. Further it favors GPT over MBR partitioning. If the firmware image is stored in the Block Device Partition format, What defines the "Block Device Partition format"? It is from EBBR spec as I can tell. Do you mean "if the firmware is stored as raw data on a block device"? I think so. I think Block device partition format (GPT) section here is for the storage device where OS is stored to rule out any legacy MBR style partitioning. It is not for the storage where firmware is stored. I think link here to EBBR section of "Firmware Storage" is incorrect which caused this confusion. In general, I think we should not specify any file format for the firmware. Our goal here is to define the environment as expected by the Client applications" i.e OS distros. It doesn't matter what format is used by the firmware implementation as long as it can provide boot and run time environment to the OS. Regards Sunil firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> Firmware Storage]. On some legacy U-Boot platforms we have the problem that the boot ROM tries to read the next boot stage from one of the first 34 sectors. This conflicts with GPT partitioning. We should require that if boot ROMs read from the next boot stage from a block device, the storage location must be in LBA 34 or higher. If the firmware is read from a file system (see Raspberry Pi), the firmware should be required to support GPT partitioning (the Raspberry Pi requires MBR partitioning). If the platform chooses UEFI/PI firmware storage as the format for the firmware images, firmware must have the implementation which supports the firmware storage format defined in UEFI/PI specification Vol3 section 3 [Link to PI sepc]. What is the benefit of requiring: if you store information as X, you should be able to read X? I suggest to keep the storage format of firmware outside of the scope for the Linux platform. If we say " firmware must implement the support for GPT Partitioning" then we should also mention PI firmware storage format for the case of using edk2 as FW for Linux platform. Otherwise, I am also fine with not mentioning anything of storage format. Abner For the server platform there might be an interest to run PCIe ROMs. So their storage format may have to be supported. But as long as these do not exist as native RISC-V code this will require emulating x86 code. Best regards Heinrich The above is enough IMO. Regards, Abner Thanks Rahul On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@... <mailto:renba.chang@...>> wrote: My reviews are inline below which is apart from the below recommendations if you don't think that is better. We have Linux2022 as the base feature set for all kinds of platform, however, there are many external references to EBBR in this section and EBBR is in the reduced UEFI scope and the base requirement is mainly for the embedded platform We also have Embedded2022 section specifically to embedded system and there is a Base sub-section for it. The above confuses me. Could we just have a simple and generic description in Linux2022 that replaces all of EBBR references, then point to Embede2022 in Linux2022 for the detailed implementation of the embedded platform? Also, have the references to EBBR in Embede2022. Is this clear than the current layout of spec? For example, +===== Firmware .... .... +- For compliance with base specification platform must implement +link: https://arm-software.github.io/ebbr/#required-elements[EBBR < https://arm-software.github.io/ebbr/#required-elements[EBBR> - UEFI Required Elements], Below would be implemented for UEFI firmware system for the compliance with base specification, just some implementations may be omitted based on the requirements of different RISC-V platforms - EFI_SYSTEM_TABLE - EFI_BOOT_SERVICES - EFI_ RUNTIME_SERVICES - Required EFI protocols for the base specification. - Required EFI protocols for the platform. Refer to Embedded2022 for the detailed implementations of the above requirements. Refer to Server2022 for the detailed implementations of the above requirements. In Embedded2022 section, put links to refer to EBBR. In Server section, we can just refer to UEFI spec if the requirement needs full UEFI scope support. This reduces the confusion and increases the readability to the audience. Otherwise, it would be hard to read for the Server platform because Server2022 would base on Linux2022 plus the extensions. And some of the requirements that refer to EBBR would be overridden because of the deviations for the server platform. Rahul Pathak <rpathak@... <mailto:rpathak@...>> 於 2021年4月20日週二下午 8:23寫道： Initial changes for the Base Boot & Runtime requirements. The sections which are currently in-progress are marked as TBD. These changes can serve as the starting point and more details/changes can be done tailored for RISC-V. This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those. Signed-off-by: Rahul Pathak <rpathak@... <mailto:rpathak@...>> --- riscv-platform-spec.adoc \| 125 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 118 insertions(+), 7 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 5d3b9c3..601fb61 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform == Linux-2022 Platform +=== Terminology +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|TERM \| DESCRIPTION +\|SBI \| Supervisor Binary Interface +\|UEFI \| Unified Extensible Firmware Interface +\|ACPI \| Advanced Configuration and Power Interface +\|SMBIOS \| System Management Basic I/O System +\|DTS \| Devicetree source file +\|DTB \| Devicetree binary +\|RVA22 \| RISC-V Application 2022 +\|RV32GC \| RISC-V 32-bit general purpose ISA described as RV32IMAFDC. +\|RV64GC \| RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +\|=== + + +=== Specifications +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|SPECIFICATION \| VERSION +\|link: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI < https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI Specification] \| v2.9 +\|link: https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree < https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree Specification] \| v0.3 +\|link: https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI < https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> Specification] \| v0.3-rc0 +\|link:[RVA22 Specification] \| TBD +\|link:https://arm-software.github.io/ebbr/[EBBR <https://arm-software.github.io/ebbr/%5BEBBR> Specification] \| v2.0.0-pre1 +\|link: https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI < https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI Specification] \| v6.4 +\|link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS < https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS Specification] \| v3.4.0 +\|link:[Platform Policy] \| TBD +\|=== + // Base feature set for Linux-2022 Platform === Base ==== Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] Timers * Watchdog Timers -==== Boot Process -* Firmware -* Boot-Loader -* Discovery Mechanisms +==== Boot and Runtime Requirements +- The base specification defines the interface between the firmware and the +operating system suitable for the RISC-V platforms with rich operating +systems. +- These requirements specifies the required boot and runtime services, device +discovery mechanism, etc. +- The requirements are operating system agnostic, specific firmware/bootloader +implementation agnostic. +- The base boot specification depends on the RVA22 profile and all requirements +from the RVA22 profile must be implemented. +- The base runtime specification depends on the RISC-V SBI specification and +all requirements from the SBI spec must be implemented. +- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode can comply +with the base specification. Hypervisor Extension is optional. +_Will be defined in this spec if the RVA22 spec does not mention it._ +- For the generic mandatory requirements this base specification will refer to +the EBBR Specification. Any deviation from the EBBR will be explicitly +mentioned in the requirements. +- Specifications followed are mentioned in the +<<Specifications,Specification Section>> +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform +Policy Specification. + + +===== Firmware +- UEFI Platform must meet RISC-V Platform requirements on calling conventions, +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI +specification. +- For compliance with base specification platform must implement +link: https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> - UEFI Required Elements], +link: https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR < https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] +and support the following +link: https://arm-software.github.io/ebbr/#required-global-variables[EBBR < https://arm-software.github.io/ebbr/#required-global-variables[EBBR> - Global Variables]. + +====== Block Device Partition Format Better to name it as "Firmware Block Device Partition Format" becasue the link to EBBR is specifically talks about how to store firmware image. +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link: https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> Firmware Storage]. This is what I said it may confuse audiences becasue UEFI PI spec volume3 also defines the format of firmware image which is used by edk2 and which is very different than the one defined in EBBR. Can we add the below sentence, Firmware must implement the require EFI protocols if the firmware image is stored in the format which complaint with section 2 "Firmware Storage Design Discussion" in UEFI PI specification volume3. + +===== Boot Services +- Base specification compliant firmware must implement all UEFI functions +marked as EFI_BOOT_SERVICES. + +====== Startup Protocol +- UEFI firmware could be executed in either Machine mode or Supervisor mode +during the entire POST, according to the hart capability and the platform +design. For firmware privilege mode requirements, mode switch and the handover +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. +- Before yielding control to S-Mode stage, firmware must configure the M-Mode +state. Refer the RISC-V SBI specification for details. +- If the Hypervisor Extension is implemented. TBD. + + +====== Memory Map +- UEFI environment must provide a system memory map and meet the requirements +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR <https://arm-software.github.io/ebbr/#memory-map[EBBR> - Memory Map]. + +===== Boot-Loader +TBD + +===== Discovery Mechanisms +- The base specification mandates the use of Devicetree for system description. +- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR <https://arm-software.github.io/ebbr/#devicetree[EBBR> - Devicetree requirements] +to comply with this base specification. Also refer Devicetree tables section +in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI +specification. Could we add something regarding to SMBIOS? "If platform requires SMBIOS on UEFI system, the SMBIOS table must be installed to EFI Configuration Table according to 4.6 EFI Configuration Table & Properties Table of UEFI specification." Abner -==== Runtime services -* SBI -* UEFI +===== Runtime Services +====== SBI +- Firmware must implement the runtime services/extensions specified by the +RISC-V SBI Specification. +- Wherever applicable firmware must implement UEFI interfaces over similar +interfaces and services present in the SBI specification. For example, UEFI +runtime services must implement ResetSystem() via SBI Reset extension. +- Legacy Extensions from the SBI Specification are deprecated and must not be +implemented. + +====== UEFI +- Firmware must conform to the +link: https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR < https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> - UEFI EFI_RUNTIME_SERVICES requirements]. +- Firmware must meet the requirements for +link: https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR < https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> - Runtime Device Mappings] +to avoid conflict between the firmware and OS when accessing the mapped +devices. +- Compliant UEFI runtime environment must meet the requirements for the +link: https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR < https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> - Runtime Variable Access]. +- Compliant implementation must meet the Realtime Clock requirements +link: https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR < https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> - UEFI RTC interface] +if RTC is present in the system. // Server extension for Linux-2022 Platform === Server Extension -- 2.25.1
More All Messages By This Member
Abner Chang #858 Heinrich Schuchardt <xypron.glpk@...> 於 2021年5月4日週二下午2:11寫道： On 5/4/21 7:14 AM, Abner Chang wrote: > Hi Rahul, my responses in below. > > Rahul Pathak <rpathak@... > <mailto:rpathak@...>> 於 2021年5月3日週一下午9:55寫道： > > Hi Abner, > > I read the UEFI PI Vol2 section. Need to understand if EBBR > requirements on the format are not sufficient to achieve the > minimum requirements for compliance. > Also what those UEFI Protocols must be if the format is compliant > with Section 2 of UEFI PI. > > EBBR is defined for the embedded platform with the minimum requirements We are using the term "embedded platform" for RTOS systems. These don't use UEFI at all. Do you mean "Linux Platform"? I mean the EBBR itself is defined for the embedded platform as mentioned in the Introduction. > of UEFI to boot to UEFI OS, the majority of firmware implementation > would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I > don't know if the current uboot support PI FW format (I don't think so), U-Boot only implements the EBBR subset of the UEFI spec. U-Boot does not target the UEFI Platform Initialization Specification. EBBR does not require implementing the PI spec. right. > if not, then it would be the effort to support PI firmware image format > and I have no idea if EBBR would like to accommodate PI FW image format > for the embedded system. But yes, obviously, the current EBBR > requirements on FW image format doesn't support PI spec. Also, I don't > think uboot needs to support FV format because the file format is > defined for EFI drivers. > > I list the protocols currently support in EDK2 for UEFI/PI FW image format, > EFI_PEI_FIRMWARE_VOLUME_INFO_PPI > EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI > EFI_PEI_FIRMWARE_VOLUMN_PPI > EFI_FIRMWARE_VOLUME2_PROTOCOL > EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL > EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL > Almost the entire section3 in PI spec Vol3 is covered. > > That is hard to say which Protocols or PPIs are necessary for the PI FW > format because the above are two different sets for EFI PEI phase and > DXE phase. Firmware other than edk2 doesn't have those phases, non-edk2 > firmware such as uboot just need the code to parse firmware storage > format if uboot would like to read the drivers from firmware volume. EDK II complies with the PI spec. But I see no need to refer to this spec in the base boot requirements. The reason is if EDK2 is the firmware for Linux2022, is the firmware must be stored in the GPT? Can't firmware store in SPI and compliant with PI Firmware device format? > > For the RISC-V LinuxBoot 2022 spec, we can simply say something like > below to avoid the EBBR effort, On many systems U-Boot is stored between the master boot record and the first partition. EBBR chapter 4 requires that this area is not overwritten. Further it favors GPT over MBR partitioning. > If the firmware image is stored in the Block Device Partition format, What defines the "Block Device Partition format"? It is from EBBR spec as I can tell. Do you mean "if the firmware is stored as raw data on a block device"? I think so. > firmware must implement the support for GPT Partitioning and meet the > requirements as per the > link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> Firmware > Storage]. On some legacy U-Boot platforms we have the problem that the boot ROM tries to read the next boot stage from one of the first 34 sectors. This conflicts with GPT partitioning. We should require that if boot ROMs read from the next boot stage from a block device, the storage location must be in LBA 34 or higher. If the firmware is read from a file system (see Raspberry Pi), the firmware should be required to support GPT partitioning (the Raspberry Pi requires MBR partitioning). > If the platform chooses UEFI/PI firmware storage as the format for the > firmware images, firmware must have the implementation which supports > the firmware storage format defined in UEFI/PI specification Vol3 > section 3 [Link to PI sepc]. What is the benefit of requiring: if you store information as X, you should be able to read X? I suggest to keep the storage format of firmware outside of the scope for the Linux platform. If we say " firmware must implement the support for GPT Partitioning" then we should also mention PI firmware storage format for the case of using edk2 as FW for Linux platform. Otherwise, I am also fine with not mentioning anything of storage format. Abner For the server platform there might be an interest to run PCIe ROMs. So their storage format may have to be supported. But as long as these do not exist as native RISC-V code this will require emulating x86 code. Best regards Heinrich > > The above is enough IMO. > Regards, > Abner > > Thanks > Rahul > > On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@... > <mailto:renba.chang@...>> wrote: > > > My reviews are inline below which is apart from the > below recommendations if you don't think that is better. > > > We have Linux2022 as the base feature set for all kinds of > platform, however, there are many external references to EBBR in > this section and EBBR is in the reduced UEFI scope and the base > requirement is mainly for the embedded platform We also have > Embedded2022 section specifically to embedded system and there > is a Base sub-section for it. The above confuses me. > Could we just have a simple and generic description in Linux2022 > that replaces all of EBBR references, then point to > Embede2022 in Linux2022 for the detailed implementation of the > embedded platform? Also, have the references to EBBR in > Embede2022. Is this clear than the current layout of spec? > > For example, > +===== Firmware > .... > .... > +- For compliance with base specification platform must implement > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> > - UEFI Required Elements], > Below would be implemented for UEFI firmware system for the > compliance with base specification, just some implementations > may be omitted based on the requirements of different RISC-V > platforms > - EFI_SYSTEM_TABLE > - EFI_BOOT_SERVICES > - EFI_ RUNTIME_SERVICES > - Required EFI protocols for the base specification. > - Required EFI protocols for the platform. > Refer to Embedded2022 for the detailed implementations of the > above requirements. > Refer to Server2022 for the detailed implementations of the > above requirements. > > In Embedded2022 section, put links to refer to EBBR. > In Server section, we can just refer to UEFI spec if the > requirement needs full UEFI scope support. > > This reduces the confusion and increases the readability to the > audience. Otherwise, it would be hard to read for the Server > platform because Server2022 would base on Linux2022 plus the > extensions. And some of the requirements that refer to EBBR > would be overridden because of the deviations for the server > platform. > > > Rahul Pathak <rpathak@... > <mailto:rpathak@...>> 於 2021年4月20日週二下午 > 8:23寫道： > > Initial changes for the Base Boot & Runtime requirements. > The sections which are currently in-progress are marked as TBD. > These changes can serve as the starting point and more > details/changes > can be done tailored for RISC-V. > This is the main patch, there are minor changes in the > contributors file > and the changelog which are not relevant for now so I am not > sending those. > > Signed-off-by: Rahul Pathak <rpathak@... > <mailto:rpathak@...>> > --- > riscv-platform-spec.adoc \| 125 > ++++++++++++++++++++++++++++++++++++--- > 1 file changed, 118 insertions(+), 7 deletions(-) > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc > index 5d3b9c3..601fb61 100644 > --- a/riscv-platform-spec.adoc > +++ b/riscv-platform-spec.adoc > @@ -32,6 +32,36 @@ include::profiles.adoc[] > // Linux-2022 Platform > == Linux-2022 Platform > > +=== Terminology > +[cols="1,2", width=80%, align="left", options="header"] > +\|=== > +\|TERM \| DESCRIPTION > +\|SBI \| Supervisor Binary Interface > +\|UEFI \| Unified Extensible Firmware Interface > +\|ACPI \| Advanced Configuration and Power Interface > +\|SMBIOS \| System Management Basic I/O System > +\|DTS \| Devicetree source file > +\|DTB \| Devicetree binary > +\|RVA22 \| RISC-V Application 2022 > +\|RV32GC \| RISC-V 32-bit general purpose ISA described as > RV32IMAFDC. > +\|RV64GC \| RISC-V 64-bit general purpose ISA described as > RV64IMAFDC. > +\|=== > + > + > +=== Specifications > +[cols="1,2", width=80%, align="left", options="header"] > +\|=== > +\|SPECIFICATION \| VERSION > +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > Specification] \| v2.9 > +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > Specification] \| v0.3 > +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > Specification] \| v0.3-rc0 > +\|link:[RVA22 Specification] > \| TBD > +\|link:https://arm-software.github.io/ebbr/[EBBR > <https://arm-software.github.io/ebbr/%5BEBBR> > Specification] > \| v2.0.0-pre1 > +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > Specification] \| v6.4 > +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > Specification] \| v3.4.0 > +\|link:[Platform Policy] > \| TBD > +\|=== > + > // Base feature set for Linux-2022 Platform > === Base > ==== Architecture > @@ -57,14 +87,95 @@ include::profiles.adoc[] > * Timers > * Watchdog Timers > > -==== Boot Process > -* Firmware > -* Boot-Loader > -* Discovery Mechanisms > +==== Boot and Runtime Requirements > +- The base specification defines the interface between the > firmware and the > +operating system suitable for the RISC-V platforms with > rich operating > +systems. > +- These requirements specifies the required boot and > runtime services, device > +discovery mechanism, etc. > +- The requirements are operating system agnostic, specific > firmware/bootloader > +implementation agnostic. > +- The base boot specification depends on the RVA22 profile > and all requirements > +from the RVA22 profile must be implemented. > +- The base runtime specification depends on the RISC-V SBI > specification and > +all requirements from the SBI spec must be implemented. > +- Any RV32GC or RV64GC system with Machine, Supervisor and > User Mode can comply > +with the base specification. Hypervisor Extension is optional. > +_Will be defined in this spec if the RVA22 spec does not > mention it._ > +- For the generic mandatory requirements this base > specification will refer to > +the EBBR Specification. Any deviation from the EBBR will be > explicitly > +mentioned in the requirements. > > +- Specifications followed are mentioned in the > +<<Specifications,Specification Section>> > +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY > refer Platform > +Policy Specification. > + > + > +===== Firmware > +- UEFI Platform must meet RISC-V Platform requirements on > calling conventions, > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 > RISC-V Platforms of UEFI > +specification. > +- For compliance with base specification platform must > implement > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> - > UEFI Required Elements], > > > +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > - UEFI Platform Specific Elements] > +and support the following > > > +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> > - Global Variables]. > + > +====== Block Device Partition Format > > Better to name it as "Firmware Block Device Partition Format" > becasue the link to EBBR is specifically talks about how to > store firmware image. > > +- Firmware must implement the support for GPT Partitioning > and meet the > +requirements as per the > +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > Firmware Storage]. > > This is what I said it may confuse audiences becasue UEFI PI > spec volume3 also defines the format of firmware image which is > used by edk2 and which is very different than the one defined in > EBBR. > Can we add the below sentence, > Firmware must implement the require EFI protocols if the > firmware image is stored in the format which complaint with > section 2 "Firmware Storage Design Discussion" in UEFI PI > specification volume3. > > + > +===== Boot Services > +- Base specification compliant firmware must implement all > UEFI functions > +marked as EFI_BOOT_SERVICES. > + > +====== Startup Protocol > +- UEFI firmware could be executed in either Machine mode or > Supervisor mode > +during the entire POST, according to the hart capability > and the platform > +design. For firmware privilege mode requirements, mode > switch and the handover > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. > +- Before yielding control to S-Mode stage, firmware must > configure the M-Mode > +state. Refer the RISC-V SBI specification for details. > +- If the Hypervisor Extension is implemented. TBD. > + > + > +====== Memory Map > +- UEFI environment must provide a system memory map and > meet the requirements > +for > link:https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR> - > Memory Map]. > > + > +===== Boot-Loader > +TBD > + > +===== Discovery Mechanisms > +- The base specification mandates the use of Devicetree for > system description. > +- System must meet > link:https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR> - > Devicetree requirements] > +to comply with this base specification. Also refer > Devicetree tables section > +in chapter - 4.6 EFI Configuration Table & Properties Table > of UEFI > +specification. > > Could we add something regarding to SMBIOS? > "If platform requires SMBIOS on UEFI system, the SMBIOS table > must be installed to EFI Configuration Table according to 4.6 > EFI Configuration Table & Properties Table of UEFI > specification." > > Abner > > > -==== Runtime services > -* SBI > -* UEFI > +===== Runtime Services > +====== SBI > +- Firmware must implement the runtime services/extensions > specified by the > +RISC-V SBI Specification. > +- Wherever applicable firmware must implement UEFI > interfaces over similar > +interfaces and services present in the SBI specification. > For example, UEFI > +runtime services must implement ResetSystem() via SBI Reset > extension. > +- Legacy Extensions from the SBI Specification are > deprecated and must not be > +implemented. > + > +====== UEFI > +- Firmware must conform to the > +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > - UEFI EFI_RUNTIME_SERVICES requirements]. > +- Firmware must meet the requirements for > +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > - Runtime Device Mappings] > +to avoid conflict between the firmware and OS when > accessing the mapped > +devices. > +- Compliant UEFI runtime environment must meet the > requirements for the > +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > - Runtime Variable Access]. > +- Compliant implementation must meet the Realtime Clock > requirements > +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > - UEFI RTC interface] > +if RTC is present in the system. > > // Server extension for Linux-2022 Platform > === Server Extension > -- > 2.25.1 > > > >
More All Messages By This Member
Rahul Pathak #852 On Tue, May 4, 2021 at 11:41 AM Heinrich Schuchardt <xypron.glpk@...> wrote: On 5/4/21 7:14 AM, Abner Chang wrote: > Hi Rahul, my responses in below. > > Rahul Pathak <rpathak@... > <mailto:rpathak@...>> 於 2021年5月3日週一下午9:55寫道： > > Hi Abner, > > I read the UEFI PI Vol2 section. Need to understand if EBBR > requirements on the format are not sufficient to achieve the > minimum requirements for compliance. > Also what those UEFI Protocols must be if the format is compliant > with Section 2 of UEFI PI. > > EBBR is defined for the embedded platform with the minimum requirements We are using the term "embedded platform" for RTOS systems. These don't use UEFI at all. Do you mean "Linux Platform"? > of UEFI to boot to UEFI OS, the majority of firmware implementation > would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I > don't know if the current uboot support PI FW format (I don't think so), U-Boot only implements the EBBR subset of the UEFI spec. U-Boot does not target the UEFI Platform Initialization Specification. EBBR does not require implementing the PI spec. > if not, then it would be the effort to support PI firmware image format > and I have no idea if EBBR would like to accommodate PI FW image format > for the embedded system. But yes, obviously, the current EBBR > requirements on FW image format doesn't support PI spec. Also, I don't > think uboot needs to support FV format because the file format is > defined for EFI drivers. > > I list the protocols currently support in EDK2 for UEFI/PI FW image format, > EFI_PEI_FIRMWARE_VOLUME_INFO_PPI > EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI > EFI_PEI_FIRMWARE_VOLUMN_PPI > EFI_FIRMWARE_VOLUME2_PROTOCOL > EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL > EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL > Almost the entire section3 in PI spec Vol3 is covered. > > That is hard to say which Protocols or PPIs are necessary for the PI FW > format because the above are two different sets for EFI PEI phase and > DXE phase. Firmware other than edk2 doesn't have those phases, non-edk2 > firmware such as uboot just need the code to parse firmware storage > format if uboot would like to read the drivers from firmware volume. EDK II complies with the PI spec. But I see no need to refer to this spec in the base boot requirements. > > For the RISC-V LinuxBoot 2022 spec, we can simply say something like > below to avoid the EBBR effort, On many systems U-Boot is stored between the master boot record and the first partition. EBBR chapter 4 requires that this area is not overwritten. Further it favors GPT over MBR partitioning. > If the firmware image is stored in the Block Device Partition format, What defines the "Block Device Partition format"? Do you mean "if the firmware is stored as raw data on a block device"? > firmware must implement the support for GPT Partitioning and meet the > requirements as per the > link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> Firmware > Storage]. On some legacy U-Boot platforms we have the problem that the boot ROM tries to read the next boot stage from one of the first 34 sectors. This conflicts with GPT partitioning. We should require that if boot ROMs read from the next boot stage from a block device, the storage location must be in LBA 34 or higher. If the firmware is read from a file system (see Raspberry Pi), the firmware should be required to support GPT partitioning (the Raspberry Pi requires MBR partitioning). > If the platform chooses UEFI/PI firmware storage as the format for the > firmware images, firmware must have the implementation which supports > the firmware storage format defined in UEFI/PI specification Vol3 > section 3 [Link to PI sepc]. What is the benefit of requiring: if you store information as X, you should be able to read X? I suggest to keep the storage format of firmware outside of the scope for the Linux platform. For the base spec, requirements need to be agnostic of particular implementation. Since EBBR does not talks about PI and if any new implementation complies with EBBR it may or may not have PI requirement fulfilled. We should not diverge from EBBR. So, I suggest to leave this upto implementation and not make it mandatory for compliance. If there is any confusion with the current block storage/format requirement then let me know if wording needs to be changed. Hope this is okay? For the server platform there might be an interest to run PCIe ROMs. So their storage format may have to be supported. But as long as these do not exist as native RISC-V code this will require emulating x86 code. Best regards Heinrich > > The above is enough IMO. > Regards, > Abner > > Thanks > Rahul > > On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@... > <mailto:renba.chang@...>> wrote: > > > My reviews are inline below which is apart from the > below recommendations if you don't think that is better. > > > We have Linux2022 as the base feature set for all kinds of > platform, however, there are many external references to EBBR in > this section and EBBR is in the reduced UEFI scope and the base > requirement is mainly for the embedded platform We also have > Embedded2022 section specifically to embedded system and there > is a Base sub-section for it. The above confuses me. > Could we just have a simple and generic description in Linux2022 > that replaces all of EBBR references, then point to > Embede2022 in Linux2022 for the detailed implementation of the > embedded platform? Also, have the references to EBBR in > Embede2022. Is this clear than the current layout of spec? > > For example, > +===== Firmware > .... > .... > +- For compliance with base specification platform must implement > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> > - UEFI Required Elements], > Below would be implemented for UEFI firmware system for the > compliance with base specification, just some implementations > may be omitted based on the requirements of different RISC-V > platforms > - EFI_SYSTEM_TABLE > - EFI_BOOT_SERVICES > - EFI_ RUNTIME_SERVICES > - Required EFI protocols for the base specification. > - Required EFI protocols for the platform. > Refer to Embedded2022 for the detailed implementations of the > above requirements. > Refer to Server2022 for the detailed implementations of the > above requirements. > > In Embedded2022 section, put links to refer to EBBR. > In Server section, we can just refer to UEFI spec if the > requirement needs full UEFI scope support. > > This reduces the confusion and increases the readability to the > audience. Otherwise, it would be hard to read for the Server > platform because Server2022 would base on Linux2022 plus the > extensions. And some of the requirements that refer to EBBR > would be overridden because of the deviations for the server > platform. > > > Rahul Pathak <rpathak@... > <mailto:rpathak@...>> 於 2021年4月20日週二下午 > 8:23寫道： > > Initial changes for the Base Boot & Runtime requirements. > The sections which are currently in-progress are marked as TBD. > These changes can serve as the starting point and more > details/changes > can be done tailored for RISC-V. > This is the main patch, there are minor changes in the > contributors file > and the changelog which are not relevant for now so I am not > sending those. > > Signed-off-by: Rahul Pathak <rpathak@... > <mailto:rpathak@...>> > --- > riscv-platform-spec.adoc \| 125 > ++++++++++++++++++++++++++++++++++++--- > 1 file changed, 118 insertions(+), 7 deletions(-) > > diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc > index 5d3b9c3..601fb61 100644 > --- a/riscv-platform-spec.adoc > +++ b/riscv-platform-spec.adoc > @@ -32,6 +32,36 @@ include::profiles.adoc[] > // Linux-2022 Platform > == Linux-2022 Platform > > +=== Terminology > +[cols="1,2", width=80%, align="left", options="header"] > +\|=== > +\|TERM \| DESCRIPTION > +\|SBI \| Supervisor Binary Interface > +\|UEFI \| Unified Extensible Firmware Interface > +\|ACPI \| Advanced Configuration and Power Interface > +\|SMBIOS \| System Management Basic I/O System > +\|DTS \| Devicetree source file > +\|DTB \| Devicetree binary > +\|RVA22 \| RISC-V Application 2022 > +\|RV32GC \| RISC-V 32-bit general purpose ISA described as > RV32IMAFDC. > +\|RV64GC \| RISC-V 64-bit general purpose ISA described as > RV64IMAFDC. > +\|=== > + > + > +=== Specifications > +[cols="1,2", width=80%, align="left", options="header"] > +\|=== > +\|SPECIFICATION \| VERSION > +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI > <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> > Specification] \| v2.9 > +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree > <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> > Specification] \| v0.3 > +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> > Specification] \| v0.3-rc0 > +\|link:[RVA22 Specification] > \| TBD > +\|link:https://arm-software.github.io/ebbr/[EBBR > <https://arm-software.github.io/ebbr/%5BEBBR> > Specification] > \| v2.0.0-pre1 > +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI > <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> > Specification] \| v6.4 > +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS > <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> > Specification] \| v3.4.0 > +\|link:[Platform Policy] > \| TBD > +\|=== > + > // Base feature set for Linux-2022 Platform > === Base > ==== Architecture > @@ -57,14 +87,95 @@ include::profiles.adoc[] > * Timers > * Watchdog Timers > > -==== Boot Process > -* Firmware > -* Boot-Loader > -* Discovery Mechanisms > +==== Boot and Runtime Requirements > +- The base specification defines the interface between the > firmware and the > +operating system suitable for the RISC-V platforms with > rich operating > +systems. > +- These requirements specifies the required boot and > runtime services, device > +discovery mechanism, etc. > +- The requirements are operating system agnostic, specific > firmware/bootloader > +implementation agnostic. > +- The base boot specification depends on the RVA22 profile > and all requirements > +from the RVA22 profile must be implemented. > +- The base runtime specification depends on the RISC-V SBI > specification and > +all requirements from the SBI spec must be implemented. > +- Any RV32GC or RV64GC system with Machine, Supervisor and > User Mode can comply > +with the base specification. Hypervisor Extension is optional. > +_Will be defined in this spec if the RVA22 spec does not > mention it._ > +- For the generic mandatory requirements this base > specification will refer to > +the EBBR Specification. Any deviation from the EBBR will be > explicitly > +mentioned in the requirements. > > +- Specifications followed are mentioned in the > +<<Specifications,Specification Section>> > +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY > refer Platform > +Policy Specification. > + > + > +===== Firmware > +- UEFI Platform must meet RISC-V Platform requirements on > calling conventions, > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 > RISC-V Platforms of UEFI > +specification. > +- For compliance with base specification platform must > implement > +link:https://arm-software.github.io/ebbr/#required-elements[EBBR > <https://arm-software.github.io/ebbr/#required-elements[EBBR> - > UEFI Required Elements], > > > +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR > <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> > - UEFI Platform Specific Elements] > +and support the following > > > +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR > <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> > - Global Variables]. > + > +====== Block Device Partition Format > > Better to name it as "Firmware Block Device Partition Format" > becasue the link to EBBR is specifically talks about how to > store firmware image. > > +- Firmware must implement the support for GPT Partitioning > and meet the > +requirements as per the > +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR > <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> > Firmware Storage]. > > This is what I said it may confuse audiences becasue UEFI PI > spec volume3 also defines the format of firmware image which is > used by edk2 and which is very different than the one defined in > EBBR. > Can we add the below sentence, > Firmware must implement the require EFI protocols if the > firmware image is stored in the format which complaint with > section 2 "Firmware Storage Design Discussion" in UEFI PI > specification volume3. > > + > +===== Boot Services > +- Base specification compliant firmware must implement all > UEFI functions > +marked as EFI_BOOT_SERVICES. > + > +====== Startup Protocol > +- UEFI firmware could be executed in either Machine mode or > Supervisor mode > +during the entire POST, according to the hart capability > and the platform > +design. For firmware privilege mode requirements, mode > switch and the handover > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. > +- Before yielding control to S-Mode stage, firmware must > configure the M-Mode > +state. Refer the RISC-V SBI specification for details. > +- If the Hypervisor Extension is implemented. TBD. > + > + > +====== Memory Map > +- UEFI environment must provide a system memory map and > meet the requirements > +for > link:https://arm-software.github.io/ebbr/#memory-map[EBBR > <https://arm-software.github.io/ebbr/#memory-map[EBBR> - > Memory Map]. > > + > +===== Boot-Loader > +TBD > + > +===== Discovery Mechanisms > +- The base specification mandates the use of Devicetree for > system description. > +- System must meet > link:https://arm-software.github.io/ebbr/#devicetree[EBBR > <https://arm-software.github.io/ebbr/#devicetree[EBBR> - > Devicetree requirements] > +to comply with this base specification. Also refer > Devicetree tables section > +in chapter - 4.6 EFI Configuration Table & Properties Table > of UEFI > +specification. > > Could we add something regarding to SMBIOS? > "If platform requires SMBIOS on UEFI system, the SMBIOS table > must be installed to EFI Configuration Table according to 4.6 > EFI Configuration Table & Properties Table of UEFI > specification." > > Abner > > > -==== Runtime services > -* SBI > -* UEFI > +===== Runtime Services > +====== SBI > +- Firmware must implement the runtime services/extensions > specified by the > +RISC-V SBI Specification. > +- Wherever applicable firmware must implement UEFI > interfaces over similar > +interfaces and services present in the SBI specification. > For example, UEFI > +runtime services must implement ResetSystem() via SBI Reset > extension. > +- Legacy Extensions from the SBI Specification are > deprecated and must not be > +implemented. > + > +====== UEFI > +- Firmware must conform to the > +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR > <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> > - UEFI EFI_RUNTIME_SERVICES requirements]. > +- Firmware must meet the requirements for > +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> > - Runtime Device Mappings] > +to avoid conflict between the firmware and OS when > accessing the mapped > +devices. > +- Compliant UEFI runtime environment must meet the > requirements for the > +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> > - Runtime Variable Access]. > +- Compliant implementation must meet the Realtime Clock > requirements > +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> > - UEFI RTC interface] > +if RTC is present in the system. > > // Server extension for Linux-2022 Platform > === Server Extension > -- > 2.25.1 > > > >
More All Messages By This Member
Heinrich Schuchardt #844 On 5/4/21 7:14 AM, Abner Chang wrote: Hi Rahul, my responses in below. Rahul Pathak <rpathak@... <mailto:rpathak@...>> 於 2021年5月3日週一下午9:55寫道： Hi Abner, I read the UEFI PI Vol2 section. Need to understand if EBBR requirements on the format are not sufficient to achieve the minimum requirements for compliance. Also what those UEFI Protocols must be if the format is compliant with Section 2 of UEFI PI. EBBR is defined for the embedded platform with the minimum requirements We are using the term "embedded platform" for RTOS systems. These don't use UEFI at all. Do you mean "Linux Platform"? of UEFI to boot to UEFI OS, the majority of firmware implementation would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I don't know if the current uboot support PI FW format (I don't think so), U-Boot only implements the EBBR subset of the UEFI spec. U-Boot does not target the UEFI Platform Initialization Specification. EBBR does not require implementing the PI spec. if not, then it would be the effort to support PI firmware image format and I have no idea if EBBR would like to accommodate PI FW image format for the embedded system. But yes, obviously, the current EBBR requirements on FW image format doesn't support PI spec. Also, I don't think uboot needs to support FV format because the file format is defined for EFI drivers. I list the protocols currently support in EDK2 for UEFI/PI FW image format, EFI_PEI_FIRMWARE_VOLUME_INFO_PPI EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI EFI_PEI_FIRMWARE_VOLUMN_PPI EFI_FIRMWARE_VOLUME2_PROTOCOL EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL Almost the entire section3 in PI spec Vol3 is covered. That is hard to say which Protocols or PPIs are necessary for the PI FW format because the above are two different sets for EFI PEI phase and DXE phase. Firmware other than edk2 doesn't have those phases, non-edk2 firmware such as uboot just need the code to parse firmware storage format if uboot would like to read the drivers from firmware volume. EDK II complies with the PI spec. But I see no need to refer to this spec in the base boot requirements. For the RISC-V LinuxBoot 2022 spec, we can simply say something like below to avoid the EBBR effort, On many systems U-Boot is stored between the master boot record and the first partition. EBBR chapter 4 requires that this area is not overwritten. Further it favors GPT over MBR partitioning. If the firmware image is stored in the Block Device Partition format, What defines the "Block Device Partition format"? Do you mean "if the firmware is stored as raw data on a block device"? firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> Firmware Storage]. On some legacy U-Boot platforms we have the problem that the boot ROM tries to read the next boot stage from one of the first 34 sectors. This conflicts with GPT partitioning. We should require that if boot ROMs read from the next boot stage from a block device, the storage location must be in LBA 34 or higher. If the firmware is read from a file system (see Raspberry Pi), the firmware should be required to support GPT partitioning (the Raspberry Pi requires MBR partitioning). If the platform chooses UEFI/PI firmware storage as the format for the firmware images, firmware must have the implementation which supports the firmware storage format defined in UEFI/PI specification Vol3 section 3 [Link to PI sepc]. What is the benefit of requiring: if you store information as X, you should be able to read X? I suggest to keep the storage format of firmware outside of the scope for the Linux platform. For the server platform there might be an interest to run PCIe ROMs. So their storage format may have to be supported. But as long as these do not exist as native RISC-V code this will require emulating x86 code. Best regards Heinrich The above is enough IMO. Regards, Abner Thanks Rahul On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@... <mailto:renba.chang@...>> wrote: My reviews are inline below which is apart from the below recommendations if you don't think that is better. We have Linux2022 as the base feature set for all kinds of platform, however, there are many external references to EBBR in this section and EBBR is in the reduced UEFI scope and the base requirement is mainly for the embedded platform We also have Embedded2022 section specifically to embedded system and there is a Base sub-section for it. The above confuses me. Could we just have a simple and generic description in Linux2022 that replaces all of EBBR references, then point to Embede2022 in Linux2022 for the detailed implementation of the embedded platform? Also, have the references to EBBR in Embede2022. Is this clear than the current layout of spec? For example, +===== Firmware .... .... +- For compliance with base specification platform must implement +link:https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> - UEFI Required Elements], Below would be implemented for UEFI firmware system for the compliance with base specification, just some implementations may be omitted based on the requirements of different RISC-V platforms - EFI_SYSTEM_TABLE - EFI_BOOT_SERVICES - EFI_ RUNTIME_SERVICES - Required EFI protocols for the base specification. - Required EFI protocols for the platform. Refer to Embedded2022 for the detailed implementations of the above requirements. Refer to Server2022 for the detailed implementations of the above requirements. In Embedded2022 section, put links to refer to EBBR. In Server section, we can just refer to UEFI spec if the requirement needs full UEFI scope support. This reduces the confusion and increases the readability to the audience. Otherwise, it would be hard to read for the Server platform because Server2022 would base on Linux2022 plus the extensions. And some of the requirements that refer to EBBR would be overridden because of the deviations for the server platform. Rahul Pathak <rpathak@... <mailto:rpathak@...>> 於 2021年4月20日週二下午 8:23寫道： Initial changes for the Base Boot & Runtime requirements. The sections which are currently in-progress are marked as TBD. These changes can serve as the starting point and more details/changes can be done tailored for RISC-V. This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those. Signed-off-by: Rahul Pathak <rpathak@... <mailto:rpathak@...>> --- riscv-platform-spec.adoc \| 125 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 118 insertions(+), 7 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 5d3b9c3..601fb61 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform == Linux-2022 Platform +=== Terminology +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|TERM \| DESCRIPTION +\|SBI \| Supervisor Binary Interface +\|UEFI \| Unified Extensible Firmware Interface +\|ACPI \| Advanced Configuration and Power Interface +\|SMBIOS \| System Management Basic I/O System +\|DTS \| Devicetree source file +\|DTB \| Devicetree binary +\|RVA22 \| RISC-V Application 2022 +\|RV32GC \| RISC-V 32-bit general purpose ISA described as RV32IMAFDC. +\|RV64GC \| RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +\|=== + + +=== Specifications +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|SPECIFICATION \| VERSION +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf%5BUEFI> Specification] \| v2.9 +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree <https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3%5BDevicetree> Specification] \| v0.3 +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI <https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc%5BSBI> Specification] \| v0.3-rc0 +\|link:[RVA22 Specification] \| TBD +\|link:https://arm-software.github.io/ebbr/[EBBR <https://arm-software.github.io/ebbr/%5BEBBR> Specification] \| v2.0.0-pre1 +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI <https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf%5BACPI> Specification] \| v6.4 +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS <https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf%5BSMBIOS> Specification] \| v3.4.0 +\|link:[Platform Policy] \| TBD +\|=== + // Base feature set for Linux-2022 Platform === Base ==== Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] * Timers * Watchdog Timers -==== Boot Process -* Firmware -* Boot-Loader -* Discovery Mechanisms +==== Boot and Runtime Requirements +- The base specification defines the interface between the firmware and the +operating system suitable for the RISC-V platforms with rich operating +systems. +- These requirements specifies the required boot and runtime services, device +discovery mechanism, etc. +- The requirements are operating system agnostic, specific firmware/bootloader +implementation agnostic. +- The base boot specification depends on the RVA22 profile and all requirements +from the RVA22 profile must be implemented. +- The base runtime specification depends on the RISC-V SBI specification and +all requirements from the SBI spec must be implemented. +- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode can comply +with the base specification. Hypervisor Extension is optional. +_Will be defined in this spec if the RVA22 spec does not mention it._ +- For the generic mandatory requirements this base specification will refer to +the EBBR Specification. Any deviation from the EBBR will be explicitly +mentioned in the requirements. +- Specifications followed are mentioned in the +<<Specifications,Specification Section>> +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform +Policy Specification. + + +===== Firmware +- UEFI Platform must meet RISC-V Platform requirements on calling conventions, +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI +specification. +- For compliance with base specification platform must implement +link:https://arm-software.github.io/ebbr/#required-elements[EBBR <https://arm-software.github.io/ebbr/#required-elements[EBBR> - UEFI Required Elements], +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR <https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR> - UEFI Platform Specific Elements] +and support the following +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR <https://arm-software.github.io/ebbr/#required-global-variables[EBBR> - Global Variables]. + +====== Block Device Partition Format Better to name it as "Firmware Block Device Partition Format" becasue the link to EBBR is specifically talks about how to store firmware image. +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR <https://arm-software.github.io/ebbr/#firmware-storage[EBBR> Firmware Storage]. This is what I said it may confuse audiences becasue UEFI PI spec volume3 also defines the format of firmware image which is used by edk2 and which is very different than the one defined in EBBR. Can we add the below sentence, Firmware must implement the require EFI protocols if the firmware image is stored in the format which complaint with section 2 "Firmware Storage Design Discussion" in UEFI PI specification volume3. + +===== Boot Services +- Base specification compliant firmware must implement all UEFI functions +marked as EFI_BOOT_SERVICES. + +====== Startup Protocol +- UEFI firmware could be executed in either Machine mode or Supervisor mode +during the entire POST, according to the hart capability and the platform +design. For firmware privilege mode requirements, mode switch and the handover +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. +- Before yielding control to S-Mode stage, firmware must configure the M-Mode +state. Refer the RISC-V SBI specification for details. +- If the Hypervisor Extension is implemented. TBD. + + +====== Memory Map +- UEFI environment must provide a system memory map and meet the requirements +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR <https://arm-software.github.io/ebbr/#memory-map[EBBR> - Memory Map]. + +===== Boot-Loader +TBD + +===== Discovery Mechanisms +- The base specification mandates the use of Devicetree for system description. +- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR <https://arm-software.github.io/ebbr/#devicetree[EBBR> - Devicetree requirements] +to comply with this base specification. Also refer Devicetree tables section +in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI +specification. Could we add something regarding to SMBIOS? "If platform requires SMBIOS on UEFI system, the SMBIOS table must be installed to EFI Configuration Table according to 4.6 EFI Configuration Table & Properties Table of UEFI specification." Abner -==== Runtime services -* SBI -* UEFI +===== Runtime Services +====== SBI +- Firmware must implement the runtime services/extensions specified by the +RISC-V SBI Specification. +- Wherever applicable firmware must implement UEFI interfaces over similar +interfaces and services present in the SBI specification. For example, UEFI +runtime services must implement ResetSystem() via SBI Reset extension. +- Legacy Extensions from the SBI Specification are deprecated and must not be +implemented. + +====== UEFI +- Firmware must conform to the +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR <https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR> - UEFI EFI_RUNTIME_SERVICES requirements]. +- Firmware must meet the requirements for +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR <https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR> - Runtime Device Mappings] +to avoid conflict between the firmware and OS when accessing the mapped +devices. +- Compliant UEFI runtime environment must meet the requirements for the +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR <https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR> - Runtime Variable Access]. +- Compliant implementation must meet the Realtime Clock requirements +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR <https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR> - UEFI RTC interface] +if RTC is present in the system. // Server extension for Linux-2022 Platform === Server Extension -- 2.25.1
More All Messages By This Member
Abner Chang #843 Hi Rahul, my responses in below. Rahul Pathak <rpathak@...> 於 2021年5月3日週一下午9:55寫道： Hi Abner, I read the UEFI PI Vol2 section. Need to understand if EBBR requirements on the format are not sufficient to achieve the minimum requirements for compliance. Also what those UEFI Protocols must be if the format is compliant with Section 2 of UEFI PI. EBBR is defined for the embedded platform with the minimum requirements of UEFI to boot to UEFI OS, the majority of firmware implementation would be uboot. Furthermore, EBBR defines nothing of UEFI/PI spec. I don't know if the current uboot support PI FW format (I don't think so), if not, then it would be the effort to support PI firmware image format and I have no idea if EBBR would like to accommodate PI FW image format for the embedded system. But yes, obviously, the current EBBR requirements on FW image format doesn't support PI spec. Also, I don't think uboot needs to support FV format because the file format is defined for EFI drivers. I list the protocols currently support in EDK2 for UEFI/PI FW image format, EFI_PEI_FIRMWARE_VOLUME_INFO_PPI EFI_PEI_FIRMWARE_VOLUME2_INFO_PPI EFI_PEI_FIRMWARE_VOLUMN_PPI EFI_FIRMWARE_VOLUME2_PROTOCOL EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL Almost the entire section3 in PI spec Vol3 is covered. That is hard to say which Protocols or PPIs are necessary for the PI FW format because the above are two different sets for EFI PEI phase and DXE phase. Firmware other than edk2 doesn't have those phases, non-edk2 firmware such as uboot just need the code to parse firmware storage format if uboot would like to read the drivers from firmware volume. For the RISC-V LinuxBoot 2022 spec, we can simply say something like below to avoid the EBBR effort, If the firmware image is stored in the Block Device Partition format, firmware must implement the support for GPT Partitioning and meet the requirements as per the link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage]. If the platform chooses UEFI/PI firmware storage as the format for the firmware images, firmware must have the implementation which supports the firmware storage format defined in UEFI/PI specification Vol3 section 3 [Link to PI sepc]. The above is enough IMO. Regards, Abner Thanks Rahul On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@...> wrote: My reviews are inline below which is apart from the below recommendations if you don't think that is better. We have Linux2022 as the base feature set for all kinds of platform, however, there are many external references to EBBR in this section and EBBR is in the reduced UEFI scope and the base requirement is mainly for the embedded platform We also have Embedded2022 section specifically to embedded system and there is a Base sub-section for it. The above confuses me. Could we just have a simple and generic description in Linux2022 that replaces all of EBBR references, then point to Embede2022 in Linux2022 for the detailed implementation of the embedded platform? Also, have the references to EBBR in Embede2022. Is this clear than the current layout of spec? For example, +===== Firmware .... .... +- For compliance with base specification platform must implement +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], Below would be implemented for UEFI firmware system for the compliance with base specification, just some implementations may be omitted based on the requirements of different RISC-V platforms - EFI_SYSTEM_TABLE - EFI_BOOT_SERVICES - EFI_ RUNTIME_SERVICES - Required EFI protocols for the base specification. - Required EFI protocols for the platform. Refer to Embedded2022 for the detailed implementations of the above requirements. Refer to Server2022 for the detailed implementations of the above requirements. In Embedded2022 section, put links to refer to EBBR. In Server section, we can just refer to UEFI spec if the requirement needs full UEFI scope support. This reduces the confusion and increases the readability to the audience. Otherwise, it would be hard to read for the Server platform because Server2022 would base on Linux2022 plus the extensions. And some of the requirements that refer to EBBR would be overridden because of the deviations for the server platform. Rahul Pathak <rpathak@...> 於 2021年4月20日週二下午8:23寫道： Initial changes for the Base Boot & Runtime requirements. The sections which are currently in-progress are marked as TBD. These changes can serve as the starting point and more details/changes can be done tailored for RISC-V. This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those. Signed-off-by: Rahul Pathak <rpathak@...> --- riscv-platform-spec.adoc \| 125 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 118 insertions(+), 7 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 5d3b9c3..601fb61 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform == Linux-2022 Platform +=== Terminology +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|TERM \| DESCRIPTION +\|SBI \| Supervisor Binary Interface +\|UEFI \| Unified Extensible Firmware Interface +\|ACPI \| Advanced Configuration and Power Interface +\|SMBIOS \| System Management Basic I/O System +\|DTS \| Devicetree source file +\|DTB \| Devicetree binary +\|RVA22 \| RISC-V Application 2022 +\|RV32GC \| RISC-V 32-bit general purpose ISA described as RV32IMAFDC. +\|RV64GC \| RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +\|=== + + +=== Specifications +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|SPECIFICATION \| VERSION +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] \| v2.9 +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] \| v0.3 +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] \| v0.3-rc0 +\|link:[RVA22 Specification] \| TBD +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] \| v2.0.0-pre1 +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] \| v6.4 +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] \| v3.4.0 +\|link:[Platform Policy] \| TBD +\|=== + // Base feature set for Linux-2022 Platform === Base ==== Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] * Timers * Watchdog Timers -==== Boot Process -* Firmware -* Boot-Loader -* Discovery Mechanisms +==== Boot and Runtime Requirements +- The base specification defines the interface between the firmware and the +operating system suitable for the RISC-V platforms with rich operating +systems. +- These requirements specifies the required boot and runtime services, device +discovery mechanism, etc. +- The requirements are operating system agnostic, specific firmware/bootloader +implementation agnostic. +- The base boot specification depends on the RVA22 profile and all requirements +from the RVA22 profile must be implemented. +- The base runtime specification depends on the RISC-V SBI specification and +all requirements from the SBI spec must be implemented. +- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode can comply +with the base specification. Hypervisor Extension is optional. +_Will be defined in this spec if the RVA22 spec does not mention it._ +- For the generic mandatory requirements this base specification will refer to +the EBBR Specification. Any deviation from the EBBR will be explicitly +mentioned in the requirements. +- Specifications followed are mentioned in the +<<Specifications,Specification Section>> +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform +Policy Specification. + + +===== Firmware +- UEFI Platform must meet RISC-V Platform requirements on calling conventions, +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI +specification. +- For compliance with base specification platform must implement +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] +and support the following +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables]. + +====== Block Device Partition Format Better to name it as "Firmware Block Device Partition Format" becasue the link to EBBR is specifically talks about how to store firmware image. +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage]. This is what I said it may confuse audiences becasue UEFI PI spec volume3 also defines the format of firmware image which is used by edk2 and which is very different than the one defined in EBBR. Can we add the below sentence, Firmware must implement the require EFI protocols if the firmware image is stored in the format which complaint with section 2 "Firmware Storage Design Discussion" in UEFI PI specification volume3. + +===== Boot Services +- Base specification compliant firmware must implement all UEFI functions +marked as EFI_BOOT_SERVICES. + +====== Startup Protocol +- UEFI firmware could be executed in either Machine mode or Supervisor mode +during the entire POST, according to the hart capability and the platform +design. For firmware privilege mode requirements, mode switch and the handover +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. +- Before yielding control to S-Mode stage, firmware must configure the M-Mode +state. Refer the RISC-V SBI specification for details. +- If the Hypervisor Extension is implemented. TBD. + + +====== Memory Map +- UEFI environment must provide a system memory map and meet the requirements +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map]. + +===== Boot-Loader +TBD + +===== Discovery Mechanisms +- The base specification mandates the use of Devicetree for system description. +- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] +to comply with this base specification. Also refer Devicetree tables section +in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI +specification. Could we add something regarding to SMBIOS? "If platform requires SMBIOS on UEFI system, the SMBIOS table must be installed to EFI Configuration Table according to 4.6 EFI Configuration Table & Properties Table of UEFI specification." Abner -==== Runtime services -* SBI -* UEFI +===== Runtime Services +====== SBI +- Firmware must implement the runtime services/extensions specified by the +RISC-V SBI Specification. +- Wherever applicable firmware must implement UEFI interfaces over similar +interfaces and services present in the SBI specification. For example, UEFI +runtime services must implement ResetSystem() via SBI Reset extension. +- Legacy Extensions from the SBI Specification are deprecated and must not be +implemented. + +====== UEFI +- Firmware must conform to the +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements]. +- Firmware must meet the requirements for +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] +to avoid conflict between the firmware and OS when accessing the mapped +devices. +- Compliant UEFI runtime environment must meet the requirements for the +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access]. +- Compliant implementation must meet the Realtime Clock requirements +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] +if RTC is present in the system. // Server extension for Linux-2022 Platform === Server Extension -- 2.25.1
More All Messages By This Member
Rahul Pathak #842 Hi Abner, I read the UEFI PI Vol2 section. Need to understand if EBBR requirements on the format are not sufficient to achieve the minimum requirements for compliance. Also what those UEFI Protocols must be if the format is compliant with Section 2 of UEFI PI. Thanks Rahul toggle quoted message Show quoted text On Wed, Apr 21, 2021 at 12:08 PM Abner Chang <renba.chang@...> wrote: My reviews are inline below which is apart from the below recommendations if you don't think that is better. We have Linux2022 as the base feature set for all kinds of platform, however, there are many external references to EBBR in this section and EBBR is in the reduced UEFI scope and the base requirement is mainly for the embedded platform We also have Embedded2022 section specifically to embedded system and there is a Base sub-section for it. The above confuses me. Could we just have a simple and generic description in Linux2022 that replaces all of EBBR references, then point to Embede2022 in Linux2022 for the detailed implementation of the embedded platform? Also, have the references to EBBR in Embede2022. Is this clear than the current layout of spec? For example, +===== Firmware .... .... +- For compliance with base specification platform must implement +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], Below would be implemented for UEFI firmware system for the compliance with base specification, just some implementations may be omitted based on the requirements of different RISC-V platforms - EFI_SYSTEM_TABLE - EFI_BOOT_SERVICES - EFI_ RUNTIME_SERVICES - Required EFI protocols for the base specification. - Required EFI protocols for the platform. Refer to Embedded2022 for the detailed implementations of the above requirements. Refer to Server2022 for the detailed implementations of the above requirements. In Embedded2022 section, put links to refer to EBBR. In Server section, we can just refer to UEFI spec if the requirement needs full UEFI scope support. This reduces the confusion and increases the readability to the audience. Otherwise, it would be hard to read for the Server platform because Server2022 would base on Linux2022 plus the extensions. And some of the requirements that refer to EBBR would be overridden because of the deviations for the server platform. Rahul Pathak <rpathak@...> 於 2021年4月20日週二下午8:23寫道： Initial changes for the Base Boot & Runtime requirements. The sections which are currently in-progress are marked as TBD. These changes can serve as the starting point and more details/changes can be done tailored for RISC-V. This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those. Signed-off-by: Rahul Pathak <rpathak@...> --- riscv-platform-spec.adoc \| 125 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 118 insertions(+), 7 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 5d3b9c3..601fb61 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform == Linux-2022 Platform +=== Terminology +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|TERM \| DESCRIPTION +\|SBI \| Supervisor Binary Interface +\|UEFI \| Unified Extensible Firmware Interface +\|ACPI \| Advanced Configuration and Power Interface +\|SMBIOS \| System Management Basic I/O System +\|DTS \| Devicetree source file +\|DTB \| Devicetree binary +\|RVA22 \| RISC-V Application 2022 +\|RV32GC \| RISC-V 32-bit general purpose ISA described as RV32IMAFDC. +\|RV64GC \| RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +\|=== + + +=== Specifications +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|SPECIFICATION \| VERSION +\|link:https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] \| v2.9 +\|link:https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] \| v0.3 +\|link:https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] \| v0.3-rc0 +\|link:[RVA22 Specification] \| TBD +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] \| v2.0.0-pre1 +\|link:https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] \| v6.4 +\|link:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] \| v3.4.0 +\|link:[Platform Policy] \| TBD +\|=== + // Base feature set for Linux-2022 Platform === Base ==== Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] * Timers * Watchdog Timers -==== Boot Process -* Firmware -* Boot-Loader -* Discovery Mechanisms +==== Boot and Runtime Requirements +- The base specification defines the interface between the firmware and the +operating system suitable for the RISC-V platforms with rich operating +systems. +- These requirements specifies the required boot and runtime services, device +discovery mechanism, etc. +- The requirements are operating system agnostic, specific firmware/bootloader +implementation agnostic. +- The base boot specification depends on the RVA22 profile and all requirements +from the RVA22 profile must be implemented. +- The base runtime specification depends on the RISC-V SBI specification and +all requirements from the SBI spec must be implemented. +- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode can comply +with the base specification. Hypervisor Extension is optional. +_Will be defined in this spec if the RVA22 spec does not mention it._ +- For the generic mandatory requirements this base specification will refer to +the EBBR Specification. Any deviation from the EBBR will be explicitly +mentioned in the requirements. +- Specifications followed are mentioned in the +<<Specifications,Specification Section>> +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform +Policy Specification. + + +===== Firmware +- UEFI Platform must meet RISC-V Platform requirements on calling conventions, +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI +specification. +- For compliance with base specification platform must implement +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], +link:https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] +and support the following +link:https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables]. + +====== Block Device Partition Format Better to name it as "Firmware Block Device Partition Format" becasue the link to EBBR is specifically talks about how to store firmware image. +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firmware Storage]. This is what I said it may confuse audiences becasue UEFI PI spec volume3 also defines the format of firmware image which is used by edk2 and which is very different than the one defined in EBBR. Can we add the below sentence, Firmware must implement the require EFI protocols if the firmware image is stored in the format which complaint with section 2 "Firmware Storage Design Discussion" in UEFI PI specification volume3. + +===== Boot Services +- Base specification compliant firmware must implement all UEFI functions +marked as EFI_BOOT_SERVICES. + +====== Startup Protocol +- UEFI firmware could be executed in either Machine mode or Supervisor mode +during the entire POST, according to the hart capability and the platform +design. For firmware privilege mode requirements, mode switch and the handover +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. +- Before yielding control to S-Mode stage, firmware must configure the M-Mode +state. Refer the RISC-V SBI specification for details. +- If the Hypervisor Extension is implemented. TBD. + + +====== Memory Map +- UEFI environment must provide a system memory map and meet the requirements +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map]. + +===== Boot-Loader +TBD + +===== Discovery Mechanisms +- The base specification mandates the use of Devicetree for system description. +- System must meet link:https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] +to comply with this base specification. Also refer Devicetree tables section +in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI +specification. Could we add something regarding to SMBIOS? "If platform requires SMBIOS on UEFI system, the SMBIOS table must be installed to EFI Configuration Table according to 4.6 EFI Configuration Table & Properties Table of UEFI specification." Abner -==== Runtime services -* SBI -* UEFI +===== Runtime Services +====== SBI +- Firmware must implement the runtime services/extensions specified by the +RISC-V SBI Specification. +- Wherever applicable firmware must implement UEFI interfaces over similar +interfaces and services present in the SBI specification. For example, UEFI +runtime services must implement ResetSystem() via SBI Reset extension. +- Legacy Extensions from the SBI Specification are deprecated and must not be +implemented. + +====== UEFI +- Firmware must conform to the +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements]. +- Firmware must meet the requirements for +link:https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] +to avoid conflict between the firmware and OS when accessing the mapped +devices. +- Compliant UEFI runtime environment must meet the requirements for the +link:https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access]. +- Compliant implementation must meet the Realtime Clock requirements +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] +if RTC is present in the system. // Server extension for Linux-2022 Platform === Server Extension -- 2.25.1
More All Messages By This Member
Kumar Sankaran #800 OK, agree. We are mandating PCI-E only for the server extension, which makes IMSIC mandatory only for the server extension. For the Linux-2022 base platform, we can make AIA mandatory with an information app/note that IMSIC within AIA is not mandatory. We can go ahead with having PLIC + CLINT as deprecated. Good? Regards Kumar toggle quoted message Show quoted text From: Anup Patel <Anup.Patel@...> Sent: Tuesday, April 27, 2021 9:33 PM To: Anup Patel <Anup.Patel@...>; Kumar Sankaran <ksankaran@...>; Atish Patra <Atish.Patra@...> Cc: rpathak@...; tech-unixplatformspec@... Subject: RE: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit Correction: “SBI IPI and RFENCE are optional only when AIA IMSIC is available.” Regards, Anup From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Anup Patel Sent: 28 April 2021 10:02 To: Kumar Sankaran <ksankaran@...>; Atish Patra <Atish.Patra@...> Cc: rpathak@...; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit The AIA specification is modular. It is not mandatory to implement all parts of AIA. For example, low-end embedded Linux systems having only MMIO devices will want to skip AIA IMSIC (MSI controller). We have to clearly state that SBI IPI and RFENCE are optional only when AIA IMSIC is not available. Regards, Anup From: Kumar Sankaran <ksankaran@...> Sent: 28 April 2021 09:54 To: Atish Patra <Atish.Patra@...> Cc: rpathak@...; Anup Patel <Anup.Patel@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit On Tue, Apr 27, 2021 at 5:23 PM Atish Patra <atish.patra@...> wrote: On Sat, 2021-04-24 at 04:30 +0000, Anup Patel wrote: > > > > -----Original Message----- > > From: tech-unixplatformspec@... <tech- > > unixplatformspec@...> On Behalf Of Rahul Pathak > > Sent: 24 April 2021 07:41 > > To: Atish Patra <Atish.Patra@...> > > Cc: tech-unixplatformspec@... > > Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot > > and > > runtime requirements - initial commit > > > > On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> > > wrote: > > > > > > On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote: > > > > Initial changes for the Base Boot & Runtime requirements. > > > > The sections which are currently in-progress are marked as TBD. > > > > These changes can serve as the starting point and more > > > > details/changes can be done tailored for RISC-V. > > > > This is the main patch, there are minor changes in the > > > > contributors > > > > file and the changelog which are not relevant for now so I am > > > > not > > > > sending those. > > > > > > > > Signed-off-by: Rahul Pathak <rpathak@...> > > > > --- > > > > riscv-platform-spec.adoc \| 125 > > > > ++++++++++++++++++++++++++++++++++++- > > > > -- > > > > 1 file changed, 118 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/riscv-platform-spec.adoc b/riscv-platform- > > > > spec.adoc > > > > index 5d3b9c3..601fb61 100644 > > > > --- a/riscv-platform-spec.adoc > > > > +++ b/riscv-platform-spec.adoc > > > > @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 > > > > Platform > > > > == Linux-2022 Platform > > > > > > > > +=== Terminology > > > > +[cols="1,2", width=80%, align="left", options="header"] > > > > +\|=== > > > > +\|TERM \| DESCRIPTION > > > > +\|SBI \| Supervisor Binary Interface > > > > +\|UEFI \| Unified Extensible Firmware Interface > > > > +\|ACPI \| Advanced Configuration and Power Interface > > > > +\|SMBIOS \| System Management Basic I/O System > > > > +\|DTS \| Devicetree source file > > > > +\|DTB \| Devicetree binary > > > > +\|RVA22 \| RISC-V Application 2022 > > > > +\|RV32GC \| RISC-V 32-bit general purpose ISA described as > > > > RV32IMAFDC. > > > > +\|RV64GC \| RISC-V 64-bit general purpose ISA described as > > > > RV64IMAFDC. > > > > +\|=== > > > > + > > > > + > > > > +=== Specifications > > > > +[cols="1,2", width=80%, align="left", options="header"] > > > > +\|=== > > > > +\|SPECIFICATION \| VERSION > > > > +\|link: > > > > > > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.p > > df[UEFI > > > > Specification] \| v2.9 > > > > +\|link: > > > > https://github.com/devicetree-org/devicetree-specification/releases/ > > > > tag/v0.3[Devicetree > > > > Specification] \| v0.3 > > > > +\|link: > > > > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > > > > Specification] \| v0.3-rc0 > > > > +\|link:[RVA22 > > > > Specification] > > > > \| TBD > > > > +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] > > > > \| v2.0.0-pre1 > > > > +\|link: > > > > > > https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[AC > > PI > > > > Specification] \| v6.4 > > > > +\|link: > > > > > > https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3 > > .4.0.pdf[SMBIOS > > > > Specification] \| v3.4.0 > > > > +\|link:[Platform > > > > Policy] > > > > \| TBD > > > > +\|=== > > > > + > > > > // Base feature set for Linux-2022 Platform === Base ==== > > > > Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] > > > > * Timers > > > > * Watchdog Timers > > > > > > > > -==== Boot Process > > > > -* Firmware > > > > -* Boot-Loader > > > > -* Discovery Mechanisms > > > > +==== Boot and Runtime Requirements > > > > +- The base specification defines the interface between the > > > > firmware > > > > and the > > > > +operating system suitable for the RISC-V platforms with rich > > > > operating > > > > +systems. > > > > +- These requirements specifies the required boot and runtime > > > > services, device > > > > +discovery mechanism, etc. > > > > +- The requirements are operating system agnostic, specific > > > > firmware/bootloader > > > > +implementation agnostic. > > > > +- The base boot specification depends on the RVA22 profile and > > > > all > > > > requirements > > > > +from the RVA22 profile must be implemented. > > > > +- The base runtime specification depends on the RISC-V SBI > > > > specification and > > > > +all requirements from the SBI spec must be implemented. > > > > > > This statement is bit ambiguous given that individual SBI section > > > says > > > legacy ones must not be implemented. > > > > Ok, What I thought while mentioning this that, if SBI spec mentions > > that > > Legacy interfaces should not be implemented" then this statement is > > also a > > requirement just "to not implement". > > But I think lets change the wording to this - "SBI Specification > > compliance is > > must for conformation with the Base Specification" > > BTW I have explicitly mentioned to not implement Legacy Extension > > from SBI > > in the Runtime Section below > > > > > > > > > > > > +- Any RV32GC or RV64GC system with Machine, Supervisor and > > > > User > > > > +Mode > > > > can comply > > > > +with the base specification. > > > > > > Should we reword something like this, > > > > > > Any platform seeking compliance with the base specification, must > > > implement all three privilege modes i.e. M/S/U mode. > > > > Should we not mandate the minimum ISA required to support the rich > > os. > > The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. > > > > > > > Hypervisor Extension is optional. > > > > > > Do we need to state this explicitly? I am just trying see if we > > > can > > > avoid any statements with optional word as per previous > > > discussions. > > > > > > Any platform implementing M/S/U complies with base. If they > > > implement > > > H extension on top of that but not aimed for server extension > > > compliance, they are still compliant with base specification. > > > > Agree > > > > > > > > > +_Will be defined in this spec if the RVA22 spec does not > > > > mention > > > > it._ > > > > +- For the generic mandatory requirements this base > > > > specification > > > > will refer to > > > > +the EBBR Specification. Any deviation from the EBBR will be > > > > explicitly > > > > +mentioned in the requirements. > > > > > > Just for clarification, RISC-V specific content in EBBR is not > > > merged > > > yet. The last version of the patch can be found here. > > > > > > > > > https://www.mail-archive.com/boot-architecture@.../msg015 > > > 45.html > > > > > > I will try to revise/rebase it on the latest EBBR specification. > > > > Sure, actually for the above argument on H extension, we should > > mention > > what would be the privilege level if H extension is implemented > > because. > > If this patch gets into the EBBR, we can just point to that then. > > I will connect with you to change this before sending the next > > version of the > > patch. > > It does not matter whether H-extension is implemented or not. > > The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or > VS-mode). > > The VS-mode is same as S-mode whereas HS-mode is S-mode with > additional hypervisor capabilities. > Pasting the relevant snippet from the the EBBR patch "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." > > > > > > > > > +- Specifications followed are mentioned in the > > > > +<<Specifications,Specification Section>> > > > > +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY > > refer > > > > Platform > > > > +Policy Specification. > > > > + > > > > + > > > > +===== Firmware > > > > +- UEFI Platform must meet RISC-V Platform requirements on > > > > calling > > > > conventions, > > > > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V > > > > Platforms of UEFI > > > > +specification. > > > > +- For compliance with base specification platform must > > > > implement > > > > +link: > > > > https://arm-software.github.io/ebbr/#required-elements[EBBR - > > > > UEFI Required Elements], > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#required-platform-specific-elem > > > > ents[EBBR > > > > - UEFI Platform Specific Elements] > > > > +and support the following > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#required-global-variables[EBBR > > > > - Global Variables]. > > > > + > > > > +====== Block Device Partition Format > > > > +- Firmware must implement the support for GPT Partitioning and > > > > meet > > > > the > > > > +requirements as per the > > > > +link: > > > > https://arm-software.github.io/ebbr/#firmware-storage[EBBR > > > > +Firm > > > > ware Storage]. > > > > + > > > > +===== Boot Services > > > > +- Base specification compliant firmware must implement all > > > > UEFI > > > > functions > > > > +marked as EFI_BOOT_SERVICES. > > > > + > > > > > > Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can > > > reworded similar to what EBBR has done. > > > > > > All functions defined as boot services must exist. Methods for > > > unsupported or unimplemented behavior must return an appropriate > > > error > > > code. > > > > Agree > > > > > > > > > > > > +====== Startup Protocol > > > > +- UEFI firmware could be executed in either Machine mode or > > > > Supervisor mode > > > > +during the entire POST, according to the hart capability and > > > > the > > > > platform > > > > +design. For firmware privilege mode requirements, mode switch > > > > and > > > > the handover > > > > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V > > > > Platforms. > > > > +- Before yielding control to S-Mode stage, firmware must > > > > configure > > > > the M-Mode > > > > +state. Refer the RISC-V SBI specification for details. > > > > > > Are we talking about only CSR configuration or all other > > > implmentation > > > expectations from M-mode such as interrupt/exception delegation, > > > misaligned/missing CSR emulation, PMP configuration ? > > > > All which an SEE should do, Do we need to really define what it has > > to do? > > Is that what you are asking > > Yes. Depending on the content of the profile RVA22, we may need to specify the minimum required actions of SEE. We need to discuss this in details. > > > > > > > +- If the Hypervisor Extension is implemented. TBD. > > > > + > > > > + > > > > +====== Memory Map > > > > +- UEFI environment must provide a system memory map and meet > > > > the > > > > requirements > > > > +for > > > > link:https://arm-software.github.io/ebbr/#memory-map[EBBR - > > > > Memory Map]. > > > > + > > > > > > In addition to this, should we standardize a start address (i.e. > > > 0x80000000) > > > > We should discuss this > > > > > Yep. > > > > > > > +===== Boot-Loader > > > > +TBD > > > > + > > > > +===== Discovery Mechanisms > > > > +- The base specification mandates the use of Devicetree for > > > > system > > > > description. > > > > +- System must meet link: > > > > https://arm-software.github.io/ebbr/#devicetree[EBBR - > > > > Devicetree > > > > requirements] > > > > +to comply with this base specification. Also refer Devicetree > > > > +tables > > > > section > > > > +in chapter - 4.6 EFI Configuration Table & Properties Table of > > > > UEFI > > > > +specification. > > > > > > > > -==== Runtime services > > > > -* SBI > > > > -* UEFI > > > > +===== Runtime Services > > > > +====== SBI > > > > +- Firmware must implement the runtime services/extensions > > > > specified > > > > by the > > > > +RISC-V SBI Specification. > > > > > > I think we can just mandate SBI v0.3. The base specification may > > > not > > > have to implement all the SBI extensions in future. > > > > But then shall we not revise the base spec and mention what not to > > implement from SBI spec here, Just like EBBR makes some things > > deprecated > > and optional from UEFI and other specs? > > We cannot have just one blindly point to SBI specification. All SBI > extensions > are defined as optional but certain SBI extensions become mandatory > if hardware > lacks capabilities. > > Here are few examples, > > 1) If "stimecmp" CSRs are available then SBI TIME extension is > optional > otherwise SBI TIME extension is mandatory > 2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not > have > AIA IMSIC then SBI IPI extension and SBI RFENCE extension is > mandatory I am still not convinced if platform spec should allow APLIC + CLINT combination. Why doses a platform want to implement only a part of AIA and leave out IMSIC ? Agree, we should make AIA mandatory. Would the following work? AIA: Mandatory (Required) PLIC + CLINT: Deprecated > 3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI > RFENCE > extension is mandatory > > The BASE profile should "stimecmp" CSR and AIA iMSIC is optional > whereas > these HW features will be mandatory for SERVER profile. > > List of BASE profile SBI extensions: > 1) SBI spec version should be at least 0.3 > 2) SBI TIME extension is mandatory if "stimecmp" CSR not available > 3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC + > CLINT > 4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC > + CLINT > 5) SBI HSM extension is mandatory > 6) SBI SRST extension is mandatory > 7) SBI PMU extension is mandatory > > The above list gets simplified for SERVER profile assuming "stimecmp" > and > AIA IMSIC are mandatory for SERVER profile. Here's the list: > 1) SBI spec version should be at least 0.3 > 2) SBI HSM extension is mandatory > 3) SBI SRST extension is mandatory > 4) SBI PMU extension is mandatory > > Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER > profile for older kernels (and other OSes or hypervisors) > > To summarize, the mandatory set of SBI extensions is decided by the > underlying HW features. > Agreed. > > > > > > > > > +- Wherever applicable firmware must implement UEFI interfaces > > > > over > > > > similar > > > > +interfaces and services present in the SBI specification. For > > > > example, UEFI > > > > +runtime services must implement ResetSystem() via SBI Reset > > > > extension. > > > > +- Legacy Extensions from the SBI Specification are deprecated > > > > and > > > > must not be > > > > +implemented. > > > > + > > > > +====== UEFI > > > > +- Firmware must conform to the > > > > +link: > > > > https://arm-software.github.io/ebbr/#uefi-runtime-services[EBB > > > > +R > > > > - UEFI EFI_RUNTIME_SERVICES requirements]. > > > > +- Firmware must meet the requirements for > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > > > > - > > > > Runtime Device Mappings] > > > > +to avoid conflict between the firmware and OS when accessing > > > > the > > > > mapped > > > > +devices. > > > > +- Compliant UEFI runtime environment must meet the > > > > requirements for > > > > the > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > > > > - > > > > Runtime Variable Access]. > > > > +- Compliant implementation must meet the Realtime Clock > > > > +requirements > > > > +link: > > > > https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > > > > +- > > > > UEFI RTC interface] > > > > +if RTC is present in the system. > > > > > > > > // Server extension for Linux-2022 Platform === Server > > > > Extension > > > > > > -- > > > Regards, > > > Atish > > > > > > > > > > Regards, > Anup > -- Regards, Atish -- Regards Kumar
More All Messages By This Member
Anup Patel #799 toggle quoted message Show quoted text -----Original Message----- From: Atish Patra <Atish.Patra@...> Sent: 28 April 2021 05:53 To: rpathak@...; Anup Patel <Anup.Patel@...> Cc: tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit On Sat, 2021-04-24 at 04:30 +0000, Anup Patel wrote: -----Original Message----- From: tech-unixplatformspec@... <tech- unixplatformspec@...> On Behalf Of Rahul Pathak Sent: 24 April 2021 07:41 To: Atish Patra <Atish.Patra@...> Cc: tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> wrote: On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote: Initial changes for the Base Boot & Runtime requirements. The sections which are currently in-progress are marked as TBD. These changes can serve as the starting point and more details/changes can be done tailored for RISC-V. This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those. Signed-off-by: Rahul Pathak <rpathak@...> --- riscv-platform-spec.adoc \| 125 ++++++++++++++++++++++++++++++++++++- -- 1 file changed, 118 insertions(+), 7 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform- spec.adoc index 5d3b9c3..601fb61 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform == Linux-2022 Platform +=== Terminology +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|TERM \| DESCRIPTION +\|SBI \| Supervisor Binary Interface UEFI \| Unified +\|Extensible Firmware Interface ACPI \| Advanced +\|Configuration and Power Interface SMBIOS \| System +\|Management Basic I/O System DTS \| Devicetree source file +\|DTB \| Devicetree binary +\|RVA22 \| RISC-V Application 2022 RV32GC \| RISC-V 32-bit +\|general purpose ISA described as RV32IMAFDC. +\|RV64GC \| RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +\|=== + + +=== Specifications +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|SPECIFICATION \| VERSION +\|link: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03 _18.p df[UEFI Specification] \| v2.9 +\|link: https://github.com/devicetree-org/devicetree-specification/relea ses/ tag/v0.3[Devicetree Specification] \| v0.3 +\|link: https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.ado c[SBI Specification] \| v0.3-rc0 +\|link:[RVA22 Specification] \| TBD +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] \| v2.0.0-pre1 +\|link: https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.p df[AC PI Specification] \| v6.4 +\|link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134 _3 .4.0.pdf[SMBIOS Specification] \| v3.4.0 +\|link:[Platform Policy] \| TBD +\|=== + // Base feature set for Linux-2022 Platform === Base ==== Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] * Timers * Watchdog Timers -==== Boot Process -* Firmware -* Boot-Loader -* Discovery Mechanisms +==== Boot and Runtime Requirements +- The base specification defines the interface between the firmware and the +operating system suitable for the RISC-V platforms with rich operating +systems. +- These requirements specifies the required boot and runtime services, device +discovery mechanism, etc. +- The requirements are operating system agnostic, specific firmware/bootloader +implementation agnostic. +- The base boot specification depends on the RVA22 profile and all requirements +from the RVA22 profile must be implemented. +- The base runtime specification depends on the RISC-V SBI specification and +all requirements from the SBI spec must be implemented. This statement is bit ambiguous given that individual SBI section says legacy ones must not be implemented. Ok, What I thought while mentioning this that, if SBI spec mentions that Legacy interfaces should not be implemented" then this statement is also a requirement just "to not implement". But I think lets change the wording to this - "SBI Specification compliance is must for conformation with the Base Specification" BTW I have explicitly mentioned to not implement Legacy Extension from SBI in the Runtime Section below +- Any RV32GC or RV64GC system with Machine, Supervisor and User +Mode can comply +with the base specification. Should we reword something like this, Any platform seeking compliance with the base specification, must implement all three privilege modes i.e. M/S/U mode. Should we not mandate the minimum ISA required to support the rich os. The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. Hypervisor Extension is optional. Do we need to state this explicitly? I am just trying see if we can avoid any statements with optional word as per previous discussions. Any platform implementing M/S/U complies with base. If they implement H extension on top of that but not aimed for server extension compliance, they are still compliant with base specification. Agree +_Will be defined in this spec if the RVA22 spec does not mention it._ +- For the generic mandatory requirements this base specification will refer to +the EBBR Specification. Any deviation from the EBBR will be explicitly +mentioned in the requirements. Just for clarification, RISC-V specific content in EBBR is not merged yet. The last version of the patch can be found here. https://www.mail-archive.com/boot-architecture@lists.linaro.org/ms g015 45.html I will try to revise/rebase it on the latest EBBR specification. Sure, actually for the above argument on H extension, we should mention what would be the privilege level if H extension is implemented because. If this patch gets into the EBBR, we can just point to that then. I will connect with you to change this before sending the next version of the patch. It does not matter whether H-extension is implemented or not. The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or VS-mode). The VS-mode is same as S-mode whereas HS-mode is S-mode with additional hypervisor capabilities. Pasting the relevant snippet from the the EBBR patch "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." +- Specifications followed are mentioned in the +<<Specifications,Specification Section>> +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform +Policy Specification. + + +===== Firmware +- UEFI Platform must meet RISC-V Platform requirements on calling conventions, +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI +specification. +- For compliance with base specification platform must implement +link: https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], +link: https://arm-software.github.io/ebbr/#required-platform-specific- elem ents[EBBR - UEFI Platform Specific Elements] +and support the following +link: https://arm-software.github.io/ebbr/#required-global-variables[E BBR - Global Variables]. + +====== Block Device Partition Format +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link: https://arm-software.github.io/ebbr/#firmware-storage[EBBR +Firm ware Storage]. + +===== Boot Services +- Base specification compliant firmware must implement all UEFI functions +marked as EFI_BOOT_SERVICES. + Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can reworded similar to what EBBR has done. All functions defined as boot services must exist. Methods for unsupported or unimplemented behavior must return an appropriate error code. Agree +====== Startup Protocol +- UEFI firmware could be executed in either Machine mode or Supervisor mode +during the entire POST, according to the hart capability and the platform +design. For firmware privilege mode requirements, mode switch and the handover +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. +- Before yielding control to S-Mode stage, firmware must configure the M-Mode +state. Refer the RISC-V SBI specification for details. Are we talking about only CSR configuration or all other implmentation expectations from M-mode such as interrupt/exception delegation, misaligned/missing CSR emulation, PMP configuration ? All which an SEE should do, Do we need to really define what it has to do? Is that what you are asking Yes. Depending on the content of the profile RVA22, we may need to specify the minimum required actions of SEE. We need to discuss this in details. +- If the Hypervisor Extension is implemented. TBD. + + +====== Memory Map +- UEFI environment must provide a system memory map and meet the requirements +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map]. + In addition to this, should we standardize a start address (i.e. 0x80000000) We should discuss this Yep. +===== Boot-Loader +TBD + +===== Discovery Mechanisms +- The base specification mandates the use of Devicetree for system description. +- System must meet link: https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] +to comply with this base specification. Also refer Devicetree +tables section +in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI +specification. -==== Runtime services -* SBI -* UEFI +===== Runtime Services +====== SBI +- Firmware must implement the runtime services/extensions specified by the +RISC-V SBI Specification. I think we can just mandate SBI v0.3. The base specification may not have to implement all the SBI extensions in future. But then shall we not revise the base spec and mention what not to implement from SBI spec here, Just like EBBR makes some things deprecated and optional from UEFI and other specs? We cannot have just one blindly point to SBI specification. All SBI extensions are defined as optional but certain SBI extensions become mandatory if hardware lacks capabilities. Here are few examples, 1) If "stimecmp" CSRs are available then SBI TIME extension is optional otherwise SBI TIME extension is mandatory 2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not have AIA IMSIC then SBI IPI extension and SBI RFENCE extension is mandatory I am still not convinced if platform spec should allow APLIC + CLINT combination. In absence of AIA IMSIC, the platforms will have to fallback to something like CLINT for IPIs. Instead of APLIC + CLINT it is better to mention "APLIC + Platform specific M-mode IPI mechanism" Why doses a platform want to implement only a part of AIA and leave out IMSIC ? AIA IMSIC can't be mandated for low-end systems where only MMIO devices are available. 3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI RFENCE extension is mandatory The BASE profile should "stimecmp" CSR and AIA iMSIC is optional whereas these HW features will be mandatory for SERVER profile. List of BASE profile SBI extensions: 1) SBI spec version should be at least 0.3 2) SBI TIME extension is mandatory if "stimecmp" CSR not available 3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC + CLINT 4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC + CLINT 5) SBI HSM extension is mandatory 6) SBI SRST extension is mandatory 7) SBI PMU extension is mandatory The above list gets simplified for SERVER profile assuming "stimecmp" and AIA IMSIC are mandatory for SERVER profile. Here's the list: 1) SBI spec version should be at least 0.3 2) SBI HSM extension is mandatory 3) SBI SRST extension is mandatory 4) SBI PMU extension is mandatory Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER profile for older kernels (and other OSes or hypervisors) To summarize, the mandatory set of SBI extensions is decided by the underlying HW features. Agreed. +- Wherever applicable firmware must implement UEFI interfaces over similar +interfaces and services present in the SBI specification. For example, UEFI +runtime services must implement ResetSystem() via SBI Reset extension. +- Legacy Extensions from the SBI Specification are deprecated and must not be +implemented. + +====== UEFI +- Firmware must conform to the +link: https://arm-software.github.io/ebbr/#uefi-runtime-services[EBB +R - UEFI EFI_RUNTIME_SERVICES requirements]. +- Firmware must meet the requirements for +link: https://arm-software.github.io/ebbr/#runtime-device-mappings[EBB R - Runtime Device Mappings] +to avoid conflict between the firmware and OS when accessing the mapped +devices. +- Compliant UEFI runtime environment must meet the requirements for the +link: https://arm-software.github.io/ebbr/#runtime-variable-access[EBB R - Runtime Variable Access]. +- Compliant implementation must meet the Realtime Clock +requirements +link: https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR +- UEFI RTC interface] +if RTC is present in the system. // Server extension for Linux-2022 Platform === Server Extension -- Regards, Atish Regards, Anup -- Regards, Atish Regards, Anup
More All Messages By This Member
Anup Patel #798 Correction: “SBI IPI and RFENCE are optional only when AIA IMSIC is available.” Regards, Anup toggle quoted message Show quoted text From: tech-unixplatformspec@... <tech-unixplatformspec@...> On Behalf Of Anup Patel Sent: 28 April 2021 10:02 To: Kumar Sankaran <ksankaran@...>; Atish Patra <Atish.Patra@...> Cc: rpathak@...; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit The AIA specification is modular. It is not mandatory to implement all parts of AIA. For example, low-end embedded Linux systems having only MMIO devices will want to skip AIA IMSIC (MSI controller). We have to clearly state that SBI IPI and RFENCE are optional only when AIA IMSIC is not available. Regards, Anup From: Kumar Sankaran <ksankaran@...> Sent: 28 April 2021 09:54 To: Atish Patra <Atish.Patra@...> Cc: rpathak@...; Anup Patel <Anup.Patel@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit On Tue, Apr 27, 2021 at 5:23 PM Atish Patra <atish.patra@...> wrote: On Sat, 2021-04-24 at 04:30 +0000, Anup Patel wrote: > > > > -----Original Message----- > > From: tech-unixplatformspec@... <tech- > > unixplatformspec@...> On Behalf Of Rahul Pathak > > Sent: 24 April 2021 07:41 > > To: Atish Patra <Atish.Patra@...> > > Cc: tech-unixplatformspec@... > > Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot > > and > > runtime requirements - initial commit > > > > On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> > > wrote: > > > > > > On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote: > > > > Initial changes for the Base Boot & Runtime requirements. > > > > The sections which are currently in-progress are marked as TBD. > > > > These changes can serve as the starting point and more > > > > details/changes can be done tailored for RISC-V. > > > > This is the main patch, there are minor changes in the > > > > contributors > > > > file and the changelog which are not relevant for now so I am > > > > not > > > > sending those. > > > > > > > > Signed-off-by: Rahul Pathak <rpathak@...> > > > > --- > > > > riscv-platform-spec.adoc \| 125 > > > > ++++++++++++++++++++++++++++++++++++- > > > > -- > > > > 1 file changed, 118 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/riscv-platform-spec.adoc b/riscv-platform- > > > > spec.adoc > > > > index 5d3b9c3..601fb61 100644 > > > > --- a/riscv-platform-spec.adoc > > > > +++ b/riscv-platform-spec.adoc > > > > @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 > > > > Platform > > > > == Linux-2022 Platform > > > > > > > > +=== Terminology > > > > +[cols="1,2", width=80%, align="left", options="header"] > > > > +\|=== > > > > +\|TERM \| DESCRIPTION > > > > +\|SBI \| Supervisor Binary Interface > > > > +\|UEFI \| Unified Extensible Firmware Interface > > > > +\|ACPI \| Advanced Configuration and Power Interface > > > > +\|SMBIOS \| System Management Basic I/O System > > > > +\|DTS \| Devicetree source file > > > > +\|DTB \| Devicetree binary > > > > +\|RVA22 \| RISC-V Application 2022 > > > > +\|RV32GC \| RISC-V 32-bit general purpose ISA described as > > > > RV32IMAFDC. > > > > +\|RV64GC \| RISC-V 64-bit general purpose ISA described as > > > > RV64IMAFDC. > > > > +\|=== > > > > + > > > > + > > > > +=== Specifications > > > > +[cols="1,2", width=80%, align="left", options="header"] > > > > +\|=== > > > > +\|SPECIFICATION \| VERSION > > > > +\|link: > > > > > > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.p > > df[UEFI > > > > Specification] \| v2.9 > > > > +\|link: > > > > https://github.com/devicetree-org/devicetree-specification/releases/ > > > > tag/v0.3[Devicetree > > > > Specification] \| v0.3 > > > > +\|link: > > > > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > > > > Specification] \| v0.3-rc0 > > > > +\|link:[RVA22 > > > > Specification] > > > > \| TBD > > > > +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] > > > > \| v2.0.0-pre1 > > > > +\|link: > > > > > > https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[AC > > PI > > > > Specification] \| v6.4 > > > > +\|link: > > > > > > https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3 > > .4.0.pdf[SMBIOS > > > > Specification] \| v3.4.0 > > > > +\|link:[Platform > > > > Policy] > > > > \| TBD > > > > +\|=== > > > > + > > > > // Base feature set for Linux-2022 Platform === Base ==== > > > > Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] > > > > * Timers > > > > * Watchdog Timers > > > > > > > > -==== Boot Process > > > > -* Firmware > > > > -* Boot-Loader > > > > -* Discovery Mechanisms > > > > +==== Boot and Runtime Requirements > > > > +- The base specification defines the interface between the > > > > firmware > > > > and the > > > > +operating system suitable for the RISC-V platforms with rich > > > > operating > > > > +systems. > > > > +- These requirements specifies the required boot and runtime > > > > services, device > > > > +discovery mechanism, etc. > > > > +- The requirements are operating system agnostic, specific > > > > firmware/bootloader > > > > +implementation agnostic. > > > > +- The base boot specification depends on the RVA22 profile and > > > > all > > > > requirements > > > > +from the RVA22 profile must be implemented. > > > > +- The base runtime specification depends on the RISC-V SBI > > > > specification and > > > > +all requirements from the SBI spec must be implemented. > > > > > > This statement is bit ambiguous given that individual SBI section > > > says > > > legacy ones must not be implemented. > > > > Ok, What I thought while mentioning this that, if SBI spec mentions > > that > > Legacy interfaces should not be implemented" then this statement is > > also a > > requirement just "to not implement". > > But I think lets change the wording to this - "SBI Specification > > compliance is > > must for conformation with the Base Specification" > > BTW I have explicitly mentioned to not implement Legacy Extension > > from SBI > > in the Runtime Section below > > > > > > > > > > > > +- Any RV32GC or RV64GC system with Machine, Supervisor and > > > > User > > > > +Mode > > > > can comply > > > > +with the base specification. > > > > > > Should we reword something like this, > > > > > > Any platform seeking compliance with the base specification, must > > > implement all three privilege modes i.e. M/S/U mode. > > > > Should we not mandate the minimum ISA required to support the rich > > os. > > The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. > > > > > > > Hypervisor Extension is optional. > > > > > > Do we need to state this explicitly? I am just trying see if we > > > can > > > avoid any statements with optional word as per previous > > > discussions. > > > > > > Any platform implementing M/S/U complies with base. If they > > > implement > > > H extension on top of that but not aimed for server extension > > > compliance, they are still compliant with base specification. > > > > Agree > > > > > > > > > +_Will be defined in this spec if the RVA22 spec does not > > > > mention > > > > it._ > > > > +- For the generic mandatory requirements this base > > > > specification > > > > will refer to > > > > +the EBBR Specification. Any deviation from the EBBR will be > > > > explicitly > > > > +mentioned in the requirements. > > > > > > Just for clarification, RISC-V specific content in EBBR is not > > > merged > > > yet. The last version of the patch can be found here. > > > > > > > > > https://www.mail-archive.com/boot-architecture@.../msg015 > > > 45.html > > > > > > I will try to revise/rebase it on the latest EBBR specification. > > > > Sure, actually for the above argument on H extension, we should > > mention > > what would be the privilege level if H extension is implemented > > because. > > If this patch gets into the EBBR, we can just point to that then. > > I will connect with you to change this before sending the next > > version of the > > patch. > > It does not matter whether H-extension is implemented or not. > > The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or > VS-mode). > > The VS-mode is same as S-mode whereas HS-mode is S-mode with > additional hypervisor capabilities. > Pasting the relevant snippet from the the EBBR patch "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." > > > > > > > > > +- Specifications followed are mentioned in the > > > > +<<Specifications,Specification Section>> > > > > +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY > > refer > > > > Platform > > > > +Policy Specification. > > > > + > > > > + > > > > +===== Firmware > > > > +- UEFI Platform must meet RISC-V Platform requirements on > > > > calling > > > > conventions, > > > > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V > > > > Platforms of UEFI > > > > +specification. > > > > +- For compliance with base specification platform must > > > > implement > > > > +link: > > > > https://arm-software.github.io/ebbr/#required-elements[EBBR - > > > > UEFI Required Elements], > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#required-platform-specific-elem > > > > ents[EBBR > > > > - UEFI Platform Specific Elements] > > > > +and support the following > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#required-global-variables[EBBR > > > > - Global Variables]. > > > > + > > > > +====== Block Device Partition Format > > > > +- Firmware must implement the support for GPT Partitioning and > > > > meet > > > > the > > > > +requirements as per the > > > > +link: > > > > https://arm-software.github.io/ebbr/#firmware-storage[EBBR > > > > +Firm > > > > ware Storage]. > > > > + > > > > +===== Boot Services > > > > +- Base specification compliant firmware must implement all > > > > UEFI > > > > functions > > > > +marked as EFI_BOOT_SERVICES. > > > > + > > > > > > Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can > > > reworded similar to what EBBR has done. > > > > > > All functions defined as boot services must exist. Methods for > > > unsupported or unimplemented behavior must return an appropriate > > > error > > > code. > > > > Agree > > > > > > > > > > > > +====== Startup Protocol > > > > +- UEFI firmware could be executed in either Machine mode or > > > > Supervisor mode > > > > +during the entire POST, according to the hart capability and > > > > the > > > > platform > > > > +design. For firmware privilege mode requirements, mode switch > > > > and > > > > the handover > > > > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V > > > > Platforms. > > > > +- Before yielding control to S-Mode stage, firmware must > > > > configure > > > > the M-Mode > > > > +state. Refer the RISC-V SBI specification for details. > > > > > > Are we talking about only CSR configuration or all other > > > implmentation > > > expectations from M-mode such as interrupt/exception delegation, > > > misaligned/missing CSR emulation, PMP configuration ? > > > > All which an SEE should do, Do we need to really define what it has > > to do? > > Is that what you are asking > > Yes. Depending on the content of the profile RVA22, we may need to specify the minimum required actions of SEE. We need to discuss this in details. > > > > > > > +- If the Hypervisor Extension is implemented. TBD. > > > > + > > > > + > > > > +====== Memory Map > > > > +- UEFI environment must provide a system memory map and meet > > > > the > > > > requirements > > > > +for > > > > link:https://arm-software.github.io/ebbr/#memory-map[EBBR - > > > > Memory Map]. > > > > + > > > > > > In addition to this, should we standardize a start address (i.e. > > > 0x80000000) > > > > We should discuss this > > > > > Yep. > > > > > > > +===== Boot-Loader > > > > +TBD > > > > + > > > > +===== Discovery Mechanisms > > > > +- The base specification mandates the use of Devicetree for > > > > system > > > > description. > > > > +- System must meet link: > > > > https://arm-software.github.io/ebbr/#devicetree[EBBR - > > > > Devicetree > > > > requirements] > > > > +to comply with this base specification. Also refer Devicetree > > > > +tables > > > > section > > > > +in chapter - 4.6 EFI Configuration Table & Properties Table of > > > > UEFI > > > > +specification. > > > > > > > > -==== Runtime services > > > > -* SBI > > > > -* UEFI > > > > +===== Runtime Services > > > > +====== SBI > > > > +- Firmware must implement the runtime services/extensions > > > > specified > > > > by the > > > > +RISC-V SBI Specification. > > > > > > I think we can just mandate SBI v0.3. The base specification may > > > not > > > have to implement all the SBI extensions in future. > > > > But then shall we not revise the base spec and mention what not to > > implement from SBI spec here, Just like EBBR makes some things > > deprecated > > and optional from UEFI and other specs? > > We cannot have just one blindly point to SBI specification. All SBI > extensions > are defined as optional but certain SBI extensions become mandatory > if hardware > lacks capabilities. > > Here are few examples, > > 1) If "stimecmp" CSRs are available then SBI TIME extension is > optional > otherwise SBI TIME extension is mandatory > 2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not > have > AIA IMSIC then SBI IPI extension and SBI RFENCE extension is > mandatory I am still not convinced if platform spec should allow APLIC + CLINT combination. Why doses a platform want to implement only a part of AIA and leave out IMSIC ? Agree, we should make AIA mandatory. Would the following work? AIA: Mandatory (Required) PLIC + CLINT: Deprecated > 3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI > RFENCE > extension is mandatory > > The BASE profile should "stimecmp" CSR and AIA iMSIC is optional > whereas > these HW features will be mandatory for SERVER profile. > > List of BASE profile SBI extensions: > 1) SBI spec version should be at least 0.3 > 2) SBI TIME extension is mandatory if "stimecmp" CSR not available > 3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC + > CLINT > 4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC > + CLINT > 5) SBI HSM extension is mandatory > 6) SBI SRST extension is mandatory > 7) SBI PMU extension is mandatory > > The above list gets simplified for SERVER profile assuming "stimecmp" > and > AIA IMSIC are mandatory for SERVER profile. Here's the list: > 1) SBI spec version should be at least 0.3 > 2) SBI HSM extension is mandatory > 3) SBI SRST extension is mandatory > 4) SBI PMU extension is mandatory > > Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER > profile for older kernels (and other OSes or hypervisors) > > To summarize, the mandatory set of SBI extensions is decided by the > underlying HW features. > Agreed. > > > > > > > > > +- Wherever applicable firmware must implement UEFI interfaces > > > > over > > > > similar > > > > +interfaces and services present in the SBI specification. For > > > > example, UEFI > > > > +runtime services must implement ResetSystem() via SBI Reset > > > > extension. > > > > +- Legacy Extensions from the SBI Specification are deprecated > > > > and > > > > must not be > > > > +implemented. > > > > + > > > > +====== UEFI > > > > +- Firmware must conform to the > > > > +link: > > > > https://arm-software.github.io/ebbr/#uefi-runtime-services[EBB > > > > +R > > > > - UEFI EFI_RUNTIME_SERVICES requirements]. > > > > +- Firmware must meet the requirements for > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > > > > - > > > > Runtime Device Mappings] > > > > +to avoid conflict between the firmware and OS when accessing > > > > the > > > > mapped > > > > +devices. > > > > +- Compliant UEFI runtime environment must meet the > > > > requirements for > > > > the > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > > > > - > > > > Runtime Variable Access]. > > > > +- Compliant implementation must meet the Realtime Clock > > > > +requirements > > > > +link: > > > > https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > > > > +- > > > > UEFI RTC interface] > > > > +if RTC is present in the system. > > > > > > > > // Server extension for Linux-2022 Platform === Server > > > > Extension > > > > > > -- > > > Regards, > > > Atish > > > > > > > > > > Regards, > Anup > -- Regards, Atish -- Regards Kumar
More All Messages By This Member
Anup Patel #797 The AIA specification is modular. It is not mandatory to implement all parts of AIA. For example, low-end embedded Linux systems having only MMIO devices will want to skip AIA IMSIC (MSI controller). We have to clearly state that SBI IPI and RFENCE are optional only when AIA IMSIC is not available. Regards, Anup toggle quoted message Show quoted text From: Kumar Sankaran <ksankaran@...> Sent: 28 April 2021 09:54 To: Atish Patra <Atish.Patra@...> Cc: rpathak@...; Anup Patel <Anup.Patel@...>; tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit On Tue, Apr 27, 2021 at 5:23 PM Atish Patra <atish.patra@...> wrote: On Sat, 2021-04-24 at 04:30 +0000, Anup Patel wrote: > > > > -----Original Message----- > > From: tech-unixplatformspec@... <tech- > > unixplatformspec@...> On Behalf Of Rahul Pathak > > Sent: 24 April 2021 07:41 > > To: Atish Patra <Atish.Patra@...> > > Cc: tech-unixplatformspec@... > > Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot > > and > > runtime requirements - initial commit > > > > On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> > > wrote: > > > > > > On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote: > > > > Initial changes for the Base Boot & Runtime requirements. > > > > The sections which are currently in-progress are marked as TBD. > > > > These changes can serve as the starting point and more > > > > details/changes can be done tailored for RISC-V. > > > > This is the main patch, there are minor changes in the > > > > contributors > > > > file and the changelog which are not relevant for now so I am > > > > not > > > > sending those. > > > > > > > > Signed-off-by: Rahul Pathak <rpathak@...> > > > > --- > > > > riscv-platform-spec.adoc \| 125 > > > > ++++++++++++++++++++++++++++++++++++- > > > > -- > > > > 1 file changed, 118 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/riscv-platform-spec.adoc b/riscv-platform- > > > > spec.adoc > > > > index 5d3b9c3..601fb61 100644 > > > > --- a/riscv-platform-spec.adoc > > > > +++ b/riscv-platform-spec.adoc > > > > @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 > > > > Platform > > > > == Linux-2022 Platform > > > > > > > > +=== Terminology > > > > +[cols="1,2", width=80%, align="left", options="header"] > > > > +\|=== > > > > +\|TERM \| DESCRIPTION > > > > +\|SBI \| Supervisor Binary Interface > > > > +\|UEFI \| Unified Extensible Firmware Interface > > > > +\|ACPI \| Advanced Configuration and Power Interface > > > > +\|SMBIOS \| System Management Basic I/O System > > > > +\|DTS \| Devicetree source file > > > > +\|DTB \| Devicetree binary > > > > +\|RVA22 \| RISC-V Application 2022 > > > > +\|RV32GC \| RISC-V 32-bit general purpose ISA described as > > > > RV32IMAFDC. > > > > +\|RV64GC \| RISC-V 64-bit general purpose ISA described as > > > > RV64IMAFDC. > > > > +\|=== > > > > + > > > > + > > > > +=== Specifications > > > > +[cols="1,2", width=80%, align="left", options="header"] > > > > +\|=== > > > > +\|SPECIFICATION \| VERSION > > > > +\|link: > > > > > > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.p > > df[UEFI > > > > Specification] \| v2.9 > > > > +\|link: > > > > https://github.com/devicetree-org/devicetree-specification/releases/ > > > > tag/v0.3[Devicetree > > > > Specification] \| v0.3 > > > > +\|link: > > > > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > > > > Specification] \| v0.3-rc0 > > > > +\|link:[RVA22 > > > > Specification] > > > > \| TBD > > > > +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] > > > > \| v2.0.0-pre1 > > > > +\|link: > > > > > > https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[AC > > PI > > > > Specification] \| v6.4 > > > > +\|link: > > > > > > https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3 > > .4.0.pdf[SMBIOS > > > > Specification] \| v3.4.0 > > > > +\|link:[Platform > > > > Policy] > > > > \| TBD > > > > +\|=== > > > > + > > > > // Base feature set for Linux-2022 Platform === Base ==== > > > > Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] > > > > * Timers > > > > * Watchdog Timers > > > > > > > > -==== Boot Process > > > > -* Firmware > > > > -* Boot-Loader > > > > -* Discovery Mechanisms > > > > +==== Boot and Runtime Requirements > > > > +- The base specification defines the interface between the > > > > firmware > > > > and the > > > > +operating system suitable for the RISC-V platforms with rich > > > > operating > > > > +systems. > > > > +- These requirements specifies the required boot and runtime > > > > services, device > > > > +discovery mechanism, etc. > > > > +- The requirements are operating system agnostic, specific > > > > firmware/bootloader > > > > +implementation agnostic. > > > > +- The base boot specification depends on the RVA22 profile and > > > > all > > > > requirements > > > > +from the RVA22 profile must be implemented. > > > > +- The base runtime specification depends on the RISC-V SBI > > > > specification and > > > > +all requirements from the SBI spec must be implemented. > > > > > > This statement is bit ambiguous given that individual SBI section > > > says > > > legacy ones must not be implemented. > > > > Ok, What I thought while mentioning this that, if SBI spec mentions > > that > > Legacy interfaces should not be implemented" then this statement is > > also a > > requirement just "to not implement". > > But I think lets change the wording to this - "SBI Specification > > compliance is > > must for conformation with the Base Specification" > > BTW I have explicitly mentioned to not implement Legacy Extension > > from SBI > > in the Runtime Section below > > > > > > > > > > > > +- Any RV32GC or RV64GC system with Machine, Supervisor and > > > > User > > > > +Mode > > > > can comply > > > > +with the base specification. > > > > > > Should we reword something like this, > > > > > > Any platform seeking compliance with the base specification, must > > > implement all three privilege modes i.e. M/S/U mode. > > > > Should we not mandate the minimum ISA required to support the rich > > os. > > The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. > > > > > > > Hypervisor Extension is optional. > > > > > > Do we need to state this explicitly? I am just trying see if we > > > can > > > avoid any statements with optional word as per previous > > > discussions. > > > > > > Any platform implementing M/S/U complies with base. If they > > > implement > > > H extension on top of that but not aimed for server extension > > > compliance, they are still compliant with base specification. > > > > Agree > > > > > > > > > +_Will be defined in this spec if the RVA22 spec does not > > > > mention > > > > it._ > > > > +- For the generic mandatory requirements this base > > > > specification > > > > will refer to > > > > +the EBBR Specification. Any deviation from the EBBR will be > > > > explicitly > > > > +mentioned in the requirements. > > > > > > Just for clarification, RISC-V specific content in EBBR is not > > > merged > > > yet. The last version of the patch can be found here. > > > > > > > > > https://www.mail-archive.com/boot-architecture@.../msg015 > > > 45.html > > > > > > I will try to revise/rebase it on the latest EBBR specification. > > > > Sure, actually for the above argument on H extension, we should > > mention > > what would be the privilege level if H extension is implemented > > because. > > If this patch gets into the EBBR, we can just point to that then. > > I will connect with you to change this before sending the next > > version of the > > patch. > > It does not matter whether H-extension is implemented or not. > > The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or > VS-mode). > > The VS-mode is same as S-mode whereas HS-mode is S-mode with > additional hypervisor capabilities. > Pasting the relevant snippet from the the EBBR patch "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." > > > > > > > > > +- Specifications followed are mentioned in the > > > > +<<Specifications,Specification Section>> > > > > +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY > > refer > > > > Platform > > > > +Policy Specification. > > > > + > > > > + > > > > +===== Firmware > > > > +- UEFI Platform must meet RISC-V Platform requirements on > > > > calling > > > > conventions, > > > > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V > > > > Platforms of UEFI > > > > +specification. > > > > +- For compliance with base specification platform must > > > > implement > > > > +link: > > > > https://arm-software.github.io/ebbr/#required-elements[EBBR - > > > > UEFI Required Elements], > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#required-platform-specific-elem > > > > ents[EBBR > > > > - UEFI Platform Specific Elements] > > > > +and support the following > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#required-global-variables[EBBR > > > > - Global Variables]. > > > > + > > > > +====== Block Device Partition Format > > > > +- Firmware must implement the support for GPT Partitioning and > > > > meet > > > > the > > > > +requirements as per the > > > > +link: > > > > https://arm-software.github.io/ebbr/#firmware-storage[EBBR > > > > +Firm > > > > ware Storage]. > > > > + > > > > +===== Boot Services > > > > +- Base specification compliant firmware must implement all > > > > UEFI > > > > functions > > > > +marked as EFI_BOOT_SERVICES. > > > > + > > > > > > Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can > > > reworded similar to what EBBR has done. > > > > > > All functions defined as boot services must exist. Methods for > > > unsupported or unimplemented behavior must return an appropriate > > > error > > > code. > > > > Agree > > > > > > > > > > > > +====== Startup Protocol > > > > +- UEFI firmware could be executed in either Machine mode or > > > > Supervisor mode > > > > +during the entire POST, according to the hart capability and > > > > the > > > > platform > > > > +design. For firmware privilege mode requirements, mode switch > > > > and > > > > the handover > > > > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V > > > > Platforms. > > > > +- Before yielding control to S-Mode stage, firmware must > > > > configure > > > > the M-Mode > > > > +state. Refer the RISC-V SBI specification for details. > > > > > > Are we talking about only CSR configuration or all other > > > implmentation > > > expectations from M-mode such as interrupt/exception delegation, > > > misaligned/missing CSR emulation, PMP configuration ? > > > > All which an SEE should do, Do we need to really define what it has > > to do? > > Is that what you are asking > > Yes. Depending on the content of the profile RVA22, we may need to specify the minimum required actions of SEE. We need to discuss this in details. > > > > > > > +- If the Hypervisor Extension is implemented. TBD. > > > > + > > > > + > > > > +====== Memory Map > > > > +- UEFI environment must provide a system memory map and meet > > > > the > > > > requirements > > > > +for > > > > link:https://arm-software.github.io/ebbr/#memory-map[EBBR - > > > > Memory Map]. > > > > + > > > > > > In addition to this, should we standardize a start address (i.e. > > > 0x80000000) > > > > We should discuss this > > > > > Yep. > > > > > > > +===== Boot-Loader > > > > +TBD > > > > + > > > > +===== Discovery Mechanisms > > > > +- The base specification mandates the use of Devicetree for > > > > system > > > > description. > > > > +- System must meet link: > > > > https://arm-software.github.io/ebbr/#devicetree[EBBR - > > > > Devicetree > > > > requirements] > > > > +to comply with this base specification. Also refer Devicetree > > > > +tables > > > > section > > > > +in chapter - 4.6 EFI Configuration Table & Properties Table of > > > > UEFI > > > > +specification. > > > > > > > > -==== Runtime services > > > > -* SBI > > > > -* UEFI > > > > +===== Runtime Services > > > > +====== SBI > > > > +- Firmware must implement the runtime services/extensions > > > > specified > > > > by the > > > > +RISC-V SBI Specification. > > > > > > I think we can just mandate SBI v0.3. The base specification may > > > not > > > have to implement all the SBI extensions in future. > > > > But then shall we not revise the base spec and mention what not to > > implement from SBI spec here, Just like EBBR makes some things > > deprecated > > and optional from UEFI and other specs? > > We cannot have just one blindly point to SBI specification. All SBI > extensions > are defined as optional but certain SBI extensions become mandatory > if hardware > lacks capabilities. > > Here are few examples, > > 1) If "stimecmp" CSRs are available then SBI TIME extension is > optional > otherwise SBI TIME extension is mandatory > 2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not > have > AIA IMSIC then SBI IPI extension and SBI RFENCE extension is > mandatory I am still not convinced if platform spec should allow APLIC + CLINT combination. Why doses a platform want to implement only a part of AIA and leave out IMSIC ? Agree, we should make AIA mandatory. Would the following work? AIA: Mandatory (Required) PLIC + CLINT: Deprecated > 3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI > RFENCE > extension is mandatory > > The BASE profile should "stimecmp" CSR and AIA iMSIC is optional > whereas > these HW features will be mandatory for SERVER profile. > > List of BASE profile SBI extensions: > 1) SBI spec version should be at least 0.3 > 2) SBI TIME extension is mandatory if "stimecmp" CSR not available > 3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC + > CLINT > 4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC > + CLINT > 5) SBI HSM extension is mandatory > 6) SBI SRST extension is mandatory > 7) SBI PMU extension is mandatory > > The above list gets simplified for SERVER profile assuming "stimecmp" > and > AIA IMSIC are mandatory for SERVER profile. Here's the list: > 1) SBI spec version should be at least 0.3 > 2) SBI HSM extension is mandatory > 3) SBI SRST extension is mandatory > 4) SBI PMU extension is mandatory > > Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER > profile for older kernels (and other OSes or hypervisors) > > To summarize, the mandatory set of SBI extensions is decided by the > underlying HW features. > Agreed. > > > > > > > > > +- Wherever applicable firmware must implement UEFI interfaces > > > > over > > > > similar > > > > +interfaces and services present in the SBI specification. For > > > > example, UEFI > > > > +runtime services must implement ResetSystem() via SBI Reset > > > > extension. > > > > +- Legacy Extensions from the SBI Specification are deprecated > > > > and > > > > must not be > > > > +implemented. > > > > + > > > > +====== UEFI > > > > +- Firmware must conform to the > > > > +link: > > > > https://arm-software.github.io/ebbr/#uefi-runtime-services[EBB > > > > +R > > > > - UEFI EFI_RUNTIME_SERVICES requirements]. > > > > +- Firmware must meet the requirements for > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > > > > - > > > > Runtime Device Mappings] > > > > +to avoid conflict between the firmware and OS when accessing > > > > the > > > > mapped > > > > +devices. > > > > +- Compliant UEFI runtime environment must meet the > > > > requirements for > > > > the > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > > > > - > > > > Runtime Variable Access]. > > > > +- Compliant implementation must meet the Realtime Clock > > > > +requirements > > > > +link: > > > > https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > > > > +- > > > > UEFI RTC interface] > > > > +if RTC is present in the system. > > > > > > > > // Server extension for Linux-2022 Platform === Server > > > > Extension > > > > > > -- > > > Regards, > > > Atish > > > > > > > > > > Regards, > Anup > -- Regards, Atish -- Regards Kumar
More All Messages By This Member
Kumar Sankaran #796 On Tue, Apr 27, 2021 at 5:23 PM Atish Patra <atish.patra@...> wrote: On Sat, 2021-04-24 at 04:30 +0000, Anup Patel wrote: > > > > -----Original Message----- > > From: tech-unixplatformspec@... <tech- > > unixplatformspec@...> On Behalf Of Rahul Pathak > > Sent: 24 April 2021 07:41 > > To: Atish Patra <Atish.Patra@...> > > Cc: tech-unixplatformspec@... > > Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot > > and > > runtime requirements - initial commit > > > > On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> > > wrote: > > > > > > On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote: > > > > Initial changes for the Base Boot & Runtime requirements. > > > > The sections which are currently in-progress are marked as TBD. > > > > These changes can serve as the starting point and more > > > > details/changes can be done tailored for RISC-V. > > > > This is the main patch, there are minor changes in the > > > > contributors > > > > file and the changelog which are not relevant for now so I am > > > > not > > > > sending those. > > > > > > > > Signed-off-by: Rahul Pathak <rpathak@...> > > > > --- > > > > riscv-platform-spec.adoc \| 125 > > > > ++++++++++++++++++++++++++++++++++++- > > > > -- > > > > 1 file changed, 118 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/riscv-platform-spec.adoc b/riscv-platform- > > > > spec.adoc > > > > index 5d3b9c3..601fb61 100644 > > > > --- a/riscv-platform-spec.adoc > > > > +++ b/riscv-platform-spec.adoc > > > > @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 > > > > Platform > > > > == Linux-2022 Platform > > > > > > > > +=== Terminology > > > > +[cols="1,2", width=80%, align="left", options="header"] > > > > +\|=== > > > > +\|TERM \| DESCRIPTION > > > > +\|SBI \| Supervisor Binary Interface > > > > +\|UEFI \| Unified Extensible Firmware Interface > > > > +\|ACPI \| Advanced Configuration and Power Interface > > > > +\|SMBIOS \| System Management Basic I/O System > > > > +\|DTS \| Devicetree source file > > > > +\|DTB \| Devicetree binary > > > > +\|RVA22 \| RISC-V Application 2022 > > > > +\|RV32GC \| RISC-V 32-bit general purpose ISA described as > > > > RV32IMAFDC. > > > > +\|RV64GC \| RISC-V 64-bit general purpose ISA described as > > > > RV64IMAFDC. > > > > +\|=== > > > > + > > > > + > > > > +=== Specifications > > > > +[cols="1,2", width=80%, align="left", options="header"] > > > > +\|=== > > > > +\|SPECIFICATION \| VERSION > > > > +\|link: > > > > > > https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.p > > df[UEFI > > > > Specification] \| v2.9 > > > > +\|link: > > > > https://github.com/devicetree-org/devicetree-specification/releases/ > > > > tag/v0.3[Devicetree > > > > Specification] \| v0.3 > > > > +\|link: > > > > https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI > > > > Specification] \| v0.3-rc0 > > > > +\|link:[RVA22 > > > > Specification] > > > > \| TBD > > > > +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] > > > > \| v2.0.0-pre1 > > > > +\|link: > > > > > > https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[AC > > PI > > > > Specification] \| v6.4 > > > > +\|link: > > > > > > https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3 > > .4.0.pdf[SMBIOS > > > > Specification] \| v3.4.0 > > > > +\|link:[Platform > > > > Policy] > > > > \| TBD > > > > +\|=== > > > > + > > > > // Base feature set for Linux-2022 Platform === Base ==== > > > > Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] > > > > * Timers > > > > * Watchdog Timers > > > > > > > > -==== Boot Process > > > > -* Firmware > > > > -* Boot-Loader > > > > -* Discovery Mechanisms > > > > +==== Boot and Runtime Requirements > > > > +- The base specification defines the interface between the > > > > firmware > > > > and the > > > > +operating system suitable for the RISC-V platforms with rich > > > > operating > > > > +systems. > > > > +- These requirements specifies the required boot and runtime > > > > services, device > > > > +discovery mechanism, etc. > > > > +- The requirements are operating system agnostic, specific > > > > firmware/bootloader > > > > +implementation agnostic. > > > > +- The base boot specification depends on the RVA22 profile and > > > > all > > > > requirements > > > > +from the RVA22 profile must be implemented. > > > > +- The base runtime specification depends on the RISC-V SBI > > > > specification and > > > > +all requirements from the SBI spec must be implemented. > > > > > > This statement is bit ambiguous given that individual SBI section > > > says > > > legacy ones must not be implemented. > > > > Ok, What I thought while mentioning this that, if SBI spec mentions > > that > > Legacy interfaces should not be implemented" then this statement is > > also a > > requirement just "to not implement". > > But I think lets change the wording to this - "SBI Specification > > compliance is > > must for conformation with the Base Specification" > > BTW I have explicitly mentioned to not implement Legacy Extension > > from SBI > > in the Runtime Section below > > > > > > > > > > > > +- Any RV32GC or RV64GC system with Machine, Supervisor and > > > > User > > > > +Mode > > > > can comply > > > > +with the base specification. > > > > > > Should we reword something like this, > > > > > > Any platform seeking compliance with the base specification, must > > > implement all three privilege modes i.e. M/S/U mode. > > > > Should we not mandate the minimum ISA required to support the rich > > os. > > The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. > > > > > > > Hypervisor Extension is optional. > > > > > > Do we need to state this explicitly? I am just trying see if we > > > can > > > avoid any statements with optional word as per previous > > > discussions. > > > > > > Any platform implementing M/S/U complies with base. If they > > > implement > > > H extension on top of that but not aimed for server extension > > > compliance, they are still compliant with base specification. > > > > Agree > > > > > > > > > +_Will be defined in this spec if the RVA22 spec does not > > > > mention > > > > it._ > > > > +- For the generic mandatory requirements this base > > > > specification > > > > will refer to > > > > +the EBBR Specification. Any deviation from the EBBR will be > > > > explicitly > > > > +mentioned in the requirements. > > > > > > Just for clarification, RISC-V specific content in EBBR is not > > > merged > > > yet. The last version of the patch can be found here. > > > > > > > > > https://www.mail-archive.com/boot-architecture@.../msg015 > > > 45.html > > > > > > I will try to revise/rebase it on the latest EBBR specification. > > > > Sure, actually for the above argument on H extension, we should > > mention > > what would be the privilege level if H extension is implemented > > because. > > If this patch gets into the EBBR, we can just point to that then. > > I will connect with you to change this before sending the next > > version of the > > patch. > > It does not matter whether H-extension is implemented or not. > > The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or > VS-mode). > > The VS-mode is same as S-mode whereas HS-mode is S-mode with > additional hypervisor capabilities. > Pasting the relevant snippet from the the EBBR patch "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." > > > > > > > > > +- Specifications followed are mentioned in the > > > > +<<Specifications,Specification Section>> > > > > +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY > > refer > > > > Platform > > > > +Policy Specification. > > > > + > > > > + > > > > +===== Firmware > > > > +- UEFI Platform must meet RISC-V Platform requirements on > > > > calling > > > > conventions, > > > > +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V > > > > Platforms of UEFI > > > > +specification. > > > > +- For compliance with base specification platform must > > > > implement > > > > +link: > > > > https://arm-software.github.io/ebbr/#required-elements[EBBR - > > > > UEFI Required Elements], > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#required-platform-specific-elem > > > > ents[EBBR > > > > - UEFI Platform Specific Elements] > > > > +and support the following > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#required-global-variables[EBBR > > > > - Global Variables]. > > > > + > > > > +====== Block Device Partition Format > > > > +- Firmware must implement the support for GPT Partitioning and > > > > meet > > > > the > > > > +requirements as per the > > > > +link: > > > > https://arm-software.github.io/ebbr/#firmware-storage[EBBR > > > > +Firm > > > > ware Storage]. > > > > + > > > > +===== Boot Services > > > > +- Base specification compliant firmware must implement all > > > > UEFI > > > > functions > > > > +marked as EFI_BOOT_SERVICES. > > > > + > > > > > > Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can > > > reworded similar to what EBBR has done. > > > > > > All functions defined as boot services must exist. Methods for > > > unsupported or unimplemented behavior must return an appropriate > > > error > > > code. > > > > Agree > > > > > > > > > > > > +====== Startup Protocol > > > > +- UEFI firmware could be executed in either Machine mode or > > > > Supervisor mode > > > > +during the entire POST, according to the hart capability and > > > > the > > > > platform > > > > +design. For firmware privilege mode requirements, mode switch > > > > and > > > > the handover > > > > +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V > > > > Platforms. > > > > +- Before yielding control to S-Mode stage, firmware must > > > > configure > > > > the M-Mode > > > > +state. Refer the RISC-V SBI specification for details. > > > > > > Are we talking about only CSR configuration or all other > > > implmentation > > > expectations from M-mode such as interrupt/exception delegation, > > > misaligned/missing CSR emulation, PMP configuration ? > > > > All which an SEE should do, Do we need to really define what it has > > to do? > > Is that what you are asking > > Yes. Depending on the content of the profile RVA22, we may need to specify the minimum required actions of SEE. We need to discuss this in details. > > > > > > > +- If the Hypervisor Extension is implemented. TBD. > > > > + > > > > + > > > > +====== Memory Map > > > > +- UEFI environment must provide a system memory map and meet > > > > the > > > > requirements > > > > +for > > > > link:https://arm-software.github.io/ebbr/#memory-map[EBBR - > > > > Memory Map]. > > > > + > > > > > > In addition to this, should we standardize a start address (i.e. > > > 0x80000000) > > > > We should discuss this > > > > > Yep. > > > > > > > +===== Boot-Loader > > > > +TBD > > > > + > > > > +===== Discovery Mechanisms > > > > +- The base specification mandates the use of Devicetree for > > > > system > > > > description. > > > > +- System must meet link: > > > > https://arm-software.github.io/ebbr/#devicetree[EBBR - > > > > Devicetree > > > > requirements] > > > > +to comply with this base specification. Also refer Devicetree > > > > +tables > > > > section > > > > +in chapter - 4.6 EFI Configuration Table & Properties Table of > > > > UEFI > > > > +specification. > > > > > > > > -==== Runtime services > > > > -* SBI > > > > -* UEFI > > > > +===== Runtime Services > > > > +====== SBI > > > > +- Firmware must implement the runtime services/extensions > > > > specified > > > > by the > > > > +RISC-V SBI Specification. > > > > > > I think we can just mandate SBI v0.3. The base specification may > > > not > > > have to implement all the SBI extensions in future. > > > > But then shall we not revise the base spec and mention what not to > > implement from SBI spec here, Just like EBBR makes some things > > deprecated > > and optional from UEFI and other specs? > > We cannot have just one blindly point to SBI specification. All SBI > extensions > are defined as optional but certain SBI extensions become mandatory > if hardware > lacks capabilities. > > Here are few examples, > > 1) If "stimecmp" CSRs are available then SBI TIME extension is > optional > otherwise SBI TIME extension is mandatory > 2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not > have > AIA IMSIC then SBI IPI extension and SBI RFENCE extension is > mandatory I am still not convinced if platform spec should allow APLIC + CLINT combination. Why doses a platform want to implement only a part of AIA and leave out IMSIC ? Agree, we should make AIA mandatory. Would the following work? AIA: Mandatory (Required) PLIC + CLINT: Deprecated > 3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI > RFENCE > extension is mandatory > > The BASE profile should "stimecmp" CSR and AIA iMSIC is optional > whereas > these HW features will be mandatory for SERVER profile. > > List of BASE profile SBI extensions: > 1) SBI spec version should be at least 0.3 > 2) SBI TIME extension is mandatory if "stimecmp" CSR not available > 3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC + > CLINT > 4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC > + CLINT > 5) SBI HSM extension is mandatory > 6) SBI SRST extension is mandatory > 7) SBI PMU extension is mandatory > > The above list gets simplified for SERVER profile assuming "stimecmp" > and > AIA IMSIC are mandatory for SERVER profile. Here's the list: > 1) SBI spec version should be at least 0.3 > 2) SBI HSM extension is mandatory > 3) SBI SRST extension is mandatory > 4) SBI PMU extension is mandatory > > Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER > profile for older kernels (and other OSes or hypervisors) > > To summarize, the mandatory set of SBI extensions is decided by the > underlying HW features. > Agreed. > > > > > > > > > +- Wherever applicable firmware must implement UEFI interfaces > > > > over > > > > similar > > > > +interfaces and services present in the SBI specification. For > > > > example, UEFI > > > > +runtime services must implement ResetSystem() via SBI Reset > > > > extension. > > > > +- Legacy Extensions from the SBI Specification are deprecated > > > > and > > > > must not be > > > > +implemented. > > > > + > > > > +====== UEFI > > > > +- Firmware must conform to the > > > > +link: > > > > https://arm-software.github.io/ebbr/#uefi-runtime-services[EBB > > > > +R > > > > - UEFI EFI_RUNTIME_SERVICES requirements]. > > > > +- Firmware must meet the requirements for > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR > > > > - > > > > Runtime Device Mappings] > > > > +to avoid conflict between the firmware and OS when accessing > > > > the > > > > mapped > > > > +devices. > > > > +- Compliant UEFI runtime environment must meet the > > > > requirements for > > > > the > > > > +link: > > > > > > > > https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR > > > > - > > > > Runtime Variable Access]. > > > > +- Compliant implementation must meet the Realtime Clock > > > > +requirements > > > > +link: > > > > https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR > > > > +- > > > > UEFI RTC interface] > > > > +if RTC is present in the system. > > > > > > > > // Server extension for Linux-2022 Platform === Server > > > > Extension > > > > > > -- > > > Regards, > > > Atish > > > > > > > > > > Regards, > Anup > -- Regards, Atish -- Regards Kumar
More All Messages By This Member
Greg Favor #790 On Tue, Apr 27, 2021 at 5:23 PM Atish Patra <atish.patra@...> wrote: The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. This is exactly the intent of the RVA22 profile. Tbd but the required extensions in the profile spec may be sufficient for both the Linux Base and Server platform specs. Worst case one or both may specify that a few optional items in the profile spec are required in the platform spec. Although there is one ready example - the H extension - which will be optional in the profile spec, and presumably optional in the Base platform spec and required in the Server platform spec. Greg
More All Messages By This Member
atishp@... #789 On Sat, 2021-04-24 at 04:30 +0000, Anup Patel wrote: -----Original Message----- From: tech-unixplatformspec@... <tech- unixplatformspec@...> On Behalf Of Rahul Pathak Sent: 24 April 2021 07:41 To: Atish Patra <Atish.Patra@...> Cc: tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> wrote: On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote: Initial changes for the Base Boot & Runtime requirements. The sections which are currently in-progress are marked as TBD. These changes can serve as the starting point and more details/changes can be done tailored for RISC-V. This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those. Signed-off-by: Rahul Pathak <rpathak@...> --- riscv-platform-spec.adoc \| 125 ++++++++++++++++++++++++++++++++++++- -- 1 file changed, 118 insertions(+), 7 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform- spec.adoc index 5d3b9c3..601fb61 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform == Linux-2022 Platform +=== Terminology +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|TERM \| DESCRIPTION +\|SBI \| Supervisor Binary Interface +\|UEFI \| Unified Extensible Firmware Interface +\|ACPI \| Advanced Configuration and Power Interface +\|SMBIOS \| System Management Basic I/O System +\|DTS \| Devicetree source file +\|DTB \| Devicetree binary +\|RVA22 \| RISC-V Application 2022 +\|RV32GC \| RISC-V 32-bit general purpose ISA described as RV32IMAFDC. +\|RV64GC \| RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +\|=== + + +=== Specifications +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|SPECIFICATION \| VERSION +\|link: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.p df[UEFI Specification] \| v2.9 +\|link: https://github.com/devicetree-org/devicetree-specification/releases/ tag/v0.3[Devicetree Specification] \| v0.3 +\|link: https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] \| v0.3-rc0 +\|link:[RVA22 Specification] \| TBD +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] \| v2.0.0-pre1 +\|link: https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[AC PI Specification] \| v6.4 +\|link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3 .4.0.pdf[SMBIOS Specification] \| v3.4.0 +\|link:[Platform Policy] \| TBD +\|=== + // Base feature set for Linux-2022 Platform === Base ==== Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] * Timers * Watchdog Timers -==== Boot Process -* Firmware -* Boot-Loader -* Discovery Mechanisms +==== Boot and Runtime Requirements +- The base specification defines the interface between the firmware and the +operating system suitable for the RISC-V platforms with rich operating +systems. +- These requirements specifies the required boot and runtime services, device +discovery mechanism, etc. +- The requirements are operating system agnostic, specific firmware/bootloader +implementation agnostic. +- The base boot specification depends on the RVA22 profile and all requirements +from the RVA22 profile must be implemented. +- The base runtime specification depends on the RISC-V SBI specification and +all requirements from the SBI spec must be implemented. This statement is bit ambiguous given that individual SBI section says legacy ones must not be implemented. Ok, What I thought while mentioning this that, if SBI spec mentions that Legacy interfaces should not be implemented" then this statement is also a requirement just "to not implement". But I think lets change the wording to this - "SBI Specification compliance is must for conformation with the Base Specification" BTW I have explicitly mentioned to not implement Legacy Extension from SBI in the Runtime Section below +- Any RV32GC or RV64GC system with Machine, Supervisor and User +Mode can comply +with the base specification. Should we reword something like this, Any platform seeking compliance with the base specification, must implement all three privilege modes i.e. M/S/U mode. Should we not mandate the minimum ISA required to support the rich os. The minimum ISA required is specified by RVA22 profile. I think platform spec should only specify any ISA requirements if any required ISA extensions are not specified by the profile. Hypervisor Extension is optional. Do we need to state this explicitly? I am just trying see if we can avoid any statements with optional word as per previous discussions. Any platform implementing M/S/U complies with base. If they implement H extension on top of that but not aimed for server extension compliance, they are still compliant with base specification. Agree +_Will be defined in this spec if the RVA22 spec does not mention it._ +- For the generic mandatory requirements this base specification will refer to +the EBBR Specification. Any deviation from the EBBR will be explicitly +mentioned in the requirements. Just for clarification, RISC-V specific content in EBBR is not merged yet. The last version of the patch can be found here. https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg015 45.html I will try to revise/rebase it on the latest EBBR specification. Sure, actually for the above argument on H extension, we should mention what would be the privilege level if H extension is implemented because. If this patch gets into the EBBR, we can just point to that then. I will connect with you to change this before sending the next version of the patch. It does not matter whether H-extension is implemented or not. The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or VS-mode). The VS-mode is same as S-mode whereas HS-mode is S-mode with additional hypervisor capabilities. Pasting the relevant snippet from the the EBBR patch "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." +- Specifications followed are mentioned in the +<<Specifications,Specification Section>> +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform +Policy Specification. + + +===== Firmware +- UEFI Platform must meet RISC-V Platform requirements on calling conventions, +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI +specification. +- For compliance with base specification platform must implement +link: https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], +link: https://arm-software.github.io/ebbr/#required-platform-specific-elem ents[EBBR - UEFI Platform Specific Elements] +and support the following +link: https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables]. + +====== Block Device Partition Format +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link: https://arm-software.github.io/ebbr/#firmware-storage[EBBR +Firm ware Storage]. + +===== Boot Services +- Base specification compliant firmware must implement all UEFI functions +marked as EFI_BOOT_SERVICES. + Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can reworded similar to what EBBR has done. All functions defined as boot services must exist. Methods for unsupported or unimplemented behavior must return an appropriate error code. Agree +====== Startup Protocol +- UEFI firmware could be executed in either Machine mode or Supervisor mode +during the entire POST, according to the hart capability and the platform +design. For firmware privilege mode requirements, mode switch and the handover +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. +- Before yielding control to S-Mode stage, firmware must configure the M-Mode +state. Refer the RISC-V SBI specification for details. Are we talking about only CSR configuration or all other implmentation expectations from M-mode such as interrupt/exception delegation, misaligned/missing CSR emulation, PMP configuration ? All which an SEE should do, Do we need to really define what it has to do? Is that what you are asking Yes. Depending on the content of the profile RVA22, we may need to specify the minimum required actions of SEE. We need to discuss this in details. +- If the Hypervisor Extension is implemented. TBD. + + +====== Memory Map +- UEFI environment must provide a system memory map and meet the requirements +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map]. + In addition to this, should we standardize a start address (i.e. 0x80000000) We should discuss this Yep. +===== Boot-Loader +TBD + +===== Discovery Mechanisms +- The base specification mandates the use of Devicetree for system description. +- System must meet link: https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] +to comply with this base specification. Also refer Devicetree +tables section +in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI +specification. -==== Runtime services -* SBI -* UEFI +===== Runtime Services +====== SBI +- Firmware must implement the runtime services/extensions specified by the +RISC-V SBI Specification. I think we can just mandate SBI v0.3. The base specification may not have to implement all the SBI extensions in future. But then shall we not revise the base spec and mention what not to implement from SBI spec here, Just like EBBR makes some things deprecated and optional from UEFI and other specs? We cannot have just one blindly point to SBI specification. All SBI extensions are defined as optional but certain SBI extensions become mandatory if hardware lacks capabilities. Here are few examples, 1) If "stimecmp" CSRs are available then SBI TIME extension is optional otherwise SBI TIME extension is mandatory 2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not have AIA IMSIC then SBI IPI extension and SBI RFENCE extension is mandatory I am still not convinced if platform spec should allow APLIC + CLINT combination. Why doses a platform want to implement only a part of AIA and leave out IMSIC ? 3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI RFENCE extension is mandatory The BASE profile should "stimecmp" CSR and AIA iMSIC is optional whereas these HW features will be mandatory for SERVER profile. List of BASE profile SBI extensions: 1) SBI spec version should be at least 0.3 2) SBI TIME extension is mandatory if "stimecmp" CSR not available 3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC + CLINT 4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC + CLINT 5) SBI HSM extension is mandatory 6) SBI SRST extension is mandatory 7) SBI PMU extension is mandatory The above list gets simplified for SERVER profile assuming "stimecmp" and AIA IMSIC are mandatory for SERVER profile. Here's the list: 1) SBI spec version should be at least 0.3 2) SBI HSM extension is mandatory 3) SBI SRST extension is mandatory 4) SBI PMU extension is mandatory Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER profile for older kernels (and other OSes or hypervisors) To summarize, the mandatory set of SBI extensions is decided by the underlying HW features. Agreed. +- Wherever applicable firmware must implement UEFI interfaces over similar +interfaces and services present in the SBI specification. For example, UEFI +runtime services must implement ResetSystem() via SBI Reset extension. +- Legacy Extensions from the SBI Specification are deprecated and must not be +implemented. + +====== UEFI +- Firmware must conform to the +link: https://arm-software.github.io/ebbr/#uefi-runtime-services[EBB +R - UEFI EFI_RUNTIME_SERVICES requirements]. +- Firmware must meet the requirements for +link: https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] +to avoid conflict between the firmware and OS when accessing the mapped +devices. +- Compliant UEFI runtime environment must meet the requirements for the +link: https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access]. +- Compliant implementation must meet the Realtime Clock +requirements +link: https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR +- UEFI RTC interface] +if RTC is present in the system. // Server extension for Linux-2022 Platform === Server Extension -- Regards, Atish Regards, Anup -- Regards, Atish
More All Messages By This Member
Anup Patel #776 toggle quoted message Show quoted text -----Original Message----- From: tech-unixplatformspec@... <tech- unixplatformspec@...> On Behalf Of Rahul Pathak Sent: 24 April 2021 07:41 To: Atish Patra <Atish.Patra@...> Cc: tech-unixplatformspec@... Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH v2] Base boot and runtime requirements - initial commit On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> wrote: On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote: Initial changes for the Base Boot & Runtime requirements. The sections which are currently in-progress are marked as TBD. These changes can serve as the starting point and more details/changes can be done tailored for RISC-V. This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those. Signed-off-by: Rahul Pathak <rpathak@...> --- riscv-platform-spec.adoc \| 125 ++++++++++++++++++++++++++++++++++++- -- 1 file changed, 118 insertions(+), 7 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 5d3b9c3..601fb61 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform == Linux-2022 Platform +=== Terminology +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|TERM \| DESCRIPTION +\|SBI \| Supervisor Binary Interface +\|UEFI \| Unified Extensible Firmware Interface +\|ACPI \| Advanced Configuration and Power Interface +\|SMBIOS \| System Management Basic I/O System +\|DTS \| Devicetree source file +\|DTB \| Devicetree binary +\|RVA22 \| RISC-V Application 2022 +\|RV32GC \| RISC-V 32-bit general purpose ISA described as RV32IMAFDC. +\|RV64GC \| RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +\|=== + + +=== Specifications +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|SPECIFICATION \| VERSION +\|link: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.p df[UEFI Specification] \| v2.9 +\|link: https://github.com/devicetree-org/devicetree-specification/releases/ tag/v0.3[Devicetree Specification] \| v0.3 +\|link: https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] \| v0.3-rc0 +\|link:[RVA22 Specification] \| TBD +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] \| v2.0.0-pre1 +\|link: https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[AC PI Specification] \| v6.4 +\|link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3 .4.0.pdf[SMBIOS Specification] \| v3.4.0 +\|link:[Platform Policy] \| TBD +\|=== + // Base feature set for Linux-2022 Platform === Base ==== Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] * Timers * Watchdog Timers -==== Boot Process -* Firmware -* Boot-Loader -* Discovery Mechanisms +==== Boot and Runtime Requirements +- The base specification defines the interface between the firmware and the +operating system suitable for the RISC-V platforms with rich operating +systems. +- These requirements specifies the required boot and runtime services, device +discovery mechanism, etc. +- The requirements are operating system agnostic, specific firmware/bootloader +implementation agnostic. +- The base boot specification depends on the RVA22 profile and all requirements +from the RVA22 profile must be implemented. +- The base runtime specification depends on the RISC-V SBI specification and +all requirements from the SBI spec must be implemented. This statement is bit ambiguous given that individual SBI section says legacy ones must not be implemented. Ok, What I thought while mentioning this that, if SBI spec mentions that Legacy interfaces should not be implemented" then this statement is also a requirement just "to not implement". But I think lets change the wording to this - "SBI Specification compliance is must for conformation with the Base Specification" BTW I have explicitly mentioned to not implement Legacy Extension from SBI in the Runtime Section below +- Any RV32GC or RV64GC system with Machine, Supervisor and User +Mode can comply +with the base specification. Should we reword something like this, Any platform seeking compliance with the base specification, must implement all three privilege modes i.e. M/S/U mode. Should we not mandate the minimum ISA required to support the rich os. Hypervisor Extension is optional. Do we need to state this explicitly? I am just trying see if we can avoid any statements with optional word as per previous discussions. Any platform implementing M/S/U complies with base. If they implement H extension on top of that but not aimed for server extension compliance, they are still compliant with base specification. Agree +_Will be defined in this spec if the RVA22 spec does not mention it._ +- For the generic mandatory requirements this base specification will refer to +the EBBR Specification. Any deviation from the EBBR will be explicitly +mentioned in the requirements. Just for clarification, RISC-V specific content in EBBR is not merged yet. The last version of the patch can be found here. https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg015 45.html I will try to revise/rebase it on the latest EBBR specification. Sure, actually for the above argument on H extension, we should mention what would be the privilege level if H extension is implemented because. If this patch gets into the EBBR, we can just point to that then. I will connect with you to change this before sending the next version of the patch. It does not matter whether H-extension is implemented or not. The EBBR (and UEFI firmware) always runs in S-mode (i.e. HS-mode or VS-mode). The VS-mode is same as S-mode whereas HS-mode is S-mode with additional hypervisor capabilities. +- Specifications followed are mentioned in the +<<Specifications,Specification Section>> +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform +Policy Specification. + + +===== Firmware +- UEFI Platform must meet RISC-V Platform requirements on calling conventions, +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI +specification. +- For compliance with base specification platform must implement +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], +link: https://arm-software.github.io/ebbr/#required-platform-specific-elem ents[EBBR - UEFI Platform Specific Elements] +and support the following +link: https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables]. + +====== Block Device Partition Format +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR +Firm ware Storage]. + +===== Boot Services +- Base specification compliant firmware must implement all UEFI functions +marked as EFI_BOOT_SERVICES. + Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can reworded similar to what EBBR has done. All functions defined as boot services must exist. Methods for unsupported or unimplemented behavior must return an appropriate error code. Agree +====== Startup Protocol +- UEFI firmware could be executed in either Machine mode or Supervisor mode +during the entire POST, according to the hart capability and the platform +design. For firmware privilege mode requirements, mode switch and the handover +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. +- Before yielding control to S-Mode stage, firmware must configure the M-Mode +state. Refer the RISC-V SBI specification for details. Are we talking about only CSR configuration or all other implmentation expectations from M-mode such as interrupt/exception delegation, misaligned/missing CSR emulation, PMP configuration ? All which an SEE should do, Do we need to really define what it has to do? Is that what you are asking +- If the Hypervisor Extension is implemented. TBD. + + +====== Memory Map +- UEFI environment must provide a system memory map and meet the requirements +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map]. + In addition to this, should we standardize a start address (i.e. 0x80000000) We should discuss this +===== Boot-Loader +TBD + +===== Discovery Mechanisms +- The base specification mandates the use of Devicetree for system description. +- System must meet link: https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] +to comply with this base specification. Also refer Devicetree +tables section +in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI +specification. -==== Runtime services -* SBI -* UEFI +===== Runtime Services +====== SBI +- Firmware must implement the runtime services/extensions specified by the +RISC-V SBI Specification. I think we can just mandate SBI v0.3. The base specification may not have to implement all the SBI extensions in future. But then shall we not revise the base spec and mention what not to implement from SBI spec here, Just like EBBR makes some things deprecated and optional from UEFI and other specs? We cannot have just one blindly point to SBI specification. All SBI extensions are defined as optional but certain SBI extensions become mandatory if hardware lacks capabilities. Here are few examples, 1) If "stimecmp" CSRs are available then SBI TIME extension is optional otherwise SBI TIME extension is mandatory 2) If underlying HW has PLIC + CLINT or APLIC + CLINT and does not have AIA IMSIC then SBI IPI extension and SBI RFENCE extension is mandatory 3) If underlying HW has AIA IMSIC then SBI IPI extension and SBI RFENCE extension is mandatory The BASE profile should "stimecmp" CSR and AIA iMSIC is optional whereas these HW features will be mandatory for SERVER profile. List of BASE profile SBI extensions: 1) SBI spec version should be at least 0.3 2) SBI TIME extension is mandatory if "stimecmp" CSR not available 3) SBI IPI extension is mandatory if HW has PLIC + CLINT or APLIC + CLINT 4) SBI RFENCE extension is mandatory if HW has PLIC + CLINT or APLIC + CLINT 5) SBI HSM extension is mandatory 6) SBI SRST extension is mandatory 7) SBI PMU extension is mandatory The above list gets simplified for SERVER profile assuming "stimecmp" and AIA IMSIC are mandatory for SERVER profile. Here's the list: 1) SBI spec version should be at least 0.3 2) SBI HSM extension is mandatory 3) SBI SRST extension is mandatory 4) SBI PMU extension is mandatory Note: OpenSBI might still support SBI TIME, IPI and RFENCE for SERVER profile for older kernels (and other OSes or hypervisors) To summarize, the mandatory set of SBI extensions is decided by the underlying HW features. +- Wherever applicable firmware must implement UEFI interfaces over similar +interfaces and services present in the SBI specification. For example, UEFI +runtime services must implement ResetSystem() via SBI Reset extension. +- Legacy Extensions from the SBI Specification are deprecated and must not be +implemented. + +====== UEFI +- Firmware must conform to the +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBB +R - UEFI EFI_RUNTIME_SERVICES requirements]. +- Firmware must meet the requirements for +link: https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] +to avoid conflict between the firmware and OS when accessing the mapped +devices. +- Compliant UEFI runtime environment must meet the requirements for the +link: https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access]. +- Compliant implementation must meet the Realtime Clock +requirements +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR +- UEFI RTC interface] +if RTC is present in the system. // Server extension for Linux-2022 Platform === Server Extension -- Regards, Atish Regards, Anup
More All Messages By This Member
Rahul Pathak #775 On Fri, Apr 23, 2021 at 5:04 AM Atish Patra <Atish.Patra@...> wrote: On Tue, 2021-04-20 at 17:51 +0530, Rahul Pathak wrote: Initial changes for the Base Boot & Runtime requirements. The sections which are currently in-progress are marked as TBD. These changes can serve as the starting point and more details/changes can be done tailored for RISC-V. This is the main patch, there are minor changes in the contributors file and the changelog which are not relevant for now so I am not sending those. Signed-off-by: Rahul Pathak <rpathak@...> --- riscv-platform-spec.adoc \| 125 ++++++++++++++++++++++++++++++++++++- -- 1 file changed, 118 insertions(+), 7 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc index 5d3b9c3..601fb61 100644 --- a/riscv-platform-spec.adoc +++ b/riscv-platform-spec.adoc @@ -32,6 +32,36 @@ include::profiles.adoc[] // Linux-2022 Platform == Linux-2022 Platform +=== Terminology +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|TERM \| DESCRIPTION +\|SBI \| Supervisor Binary Interface +\|UEFI \| Unified Extensible Firmware Interface +\|ACPI \| Advanced Configuration and Power Interface +\|SMBIOS \| System Management Basic I/O System +\|DTS \| Devicetree source file +\|DTB \| Devicetree binary +\|RVA22 \| RISC-V Application 2022 +\|RV32GC \| RISC-V 32-bit general purpose ISA described as RV32IMAFDC. +\|RV64GC \| RISC-V 64-bit general purpose ISA described as RV64IMAFDC. +\|=== + + +=== Specifications +[cols="1,2", width=80%, align="left", options="header"] +\|=== +\|SPECIFICATION \| VERSION +\|link: https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf[UEFI Specification] \| v2.9 +\|link: https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3[Devicetree Specification] \| v0.3 +\|link: https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc[SBI Specification] \| v0.3-rc0 +\|link:[RVA22 Specification] \| TBD +\|link:https://arm-software.github.io/ebbr/[EBBR Specification] \| v2.0.0-pre1 +\|link: https://uefi.org/sites/default/files/resources/ACPI_Spec_6_4_Jan22.pdf[ACPI Specification] \| v6.4 +\|link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.4.0.pdf[SMBIOS Specification] \| v3.4.0 +\|link:[Platform Policy] \| TBD +\|=== + // Base feature set for Linux-2022 Platform === Base ==== Architecture @@ -57,14 +87,95 @@ include::profiles.adoc[] * Timers * Watchdog Timers -==== Boot Process -* Firmware -* Boot-Loader -* Discovery Mechanisms +==== Boot and Runtime Requirements +- The base specification defines the interface between the firmware and the +operating system suitable for the RISC-V platforms with rich operating +systems. +- These requirements specifies the required boot and runtime services, device +discovery mechanism, etc. +- The requirements are operating system agnostic, specific firmware/bootloader +implementation agnostic. +- The base boot specification depends on the RVA22 profile and all requirements +from the RVA22 profile must be implemented. +- The base runtime specification depends on the RISC-V SBI specification and +all requirements from the SBI spec must be implemented. This statement is bit ambiguous given that individual SBI section says legacy ones must not be implemented. Ok, What I thought while mentioning this that, if SBI spec mentions that Legacy interfaces should not be implemented" then this statement is also a requirement just "to not implement". But I think lets change the wording to this - "SBI Specification compliance is must for conformation with the Base Specification" BTW I have explicitly mentioned to not implement Legacy Extension from SBI in the Runtime Section below +- Any RV32GC or RV64GC system with Machine, Supervisor and User Mode can comply +with the base specification. Should we reword something like this, Any platform seeking compliance with the base specification, must implement all three privilege modes i.e. M/S/U mode. Should we not mandate the minimum ISA required to support the rich os. Hypervisor Extension is optional. Do we need to state this explicitly? I am just trying see if we can avoid any statements with optional word as per previous discussions. Any platform implementing M/S/U complies with base. If they implement H extension on top of that but not aimed for server extension compliance, they are still compliant with base specification. Agree +_Will be defined in this spec if the RVA22 spec does not mention it._ +- For the generic mandatory requirements this base specification will refer to +the EBBR Specification. Any deviation from the EBBR will be explicitly +mentioned in the requirements. Just for clarification, RISC-V specific content in EBBR is not merged yet. The last version of the patch can be found here. https://www.mail-archive.com/boot-architecture@lists.linaro.org/msg01545.html I will try to revise/rebase it on the latest EBBR specification. Sure, actually for the above argument on H extension, we should mention what would be the privilege level if H extension is implemented because. If this patch gets into the EBBR, we can just point to that then. I will connect with you to change this before sending the next version of the patch. +- Specifications followed are mentioned in the +<<Specifications,Specification Section>> +- For more on scope of MANDATORY, DEPRECATED, COMPATIBILITY refer Platform +Policy Specification. + + +===== Firmware +- UEFI Platform must meet RISC-V Platform requirements on calling conventions, +ABI support specific to RISC-V. Refer Chapter - 2.3.7 RISC-V Platforms of UEFI +specification. +- For compliance with base specification platform must implement +link:https://arm-software.github.io/ebbr/#required-elements[EBBR - UEFI Required Elements], +link: https://arm-software.github.io/ebbr/#required-platform-specific-elements[EBBR - UEFI Platform Specific Elements] +and support the following +link: https://arm-software.github.io/ebbr/#required-global-variables[EBBR - Global Variables]. + +====== Block Device Partition Format +- Firmware must implement the support for GPT Partitioning and meet the +requirements as per the +link:https://arm-software.github.io/ebbr/#firmware-storage[EBBR Firm ware Storage]. + +===== Boot Services +- Base specification compliant firmware must implement all UEFI functions +marked as EFI_BOOT_SERVICES. + Implementing all EFI_BOOT_SERVICES shouldn't be mandatory. It can reworded similar to what EBBR has done. All functions defined as boot services must exist. Methods for unsupported or unimplemented behavior must return an appropriate error code. Agree +====== Startup Protocol +- UEFI firmware could be executed in either Machine mode or Supervisor mode +during the entire POST, according to the hart capability and the platform +design. For firmware privilege mode requirements, mode switch and the handover +of control to S-Mode refer UEFI chapter 2.3.7 RISC-V Platforms. +- Before yielding control to S-Mode stage, firmware must configure the M-Mode +state. Refer the RISC-V SBI specification for details. Are we talking about only CSR configuration or all other implmentation expectations from M-mode such as interrupt/exception delegation, misaligned/missing CSR emulation, PMP configuration ? All which an SEE should do, Do we need to really define what it has to do? Is that what you are asking +- If the Hypervisor Extension is implemented. TBD. + + +====== Memory Map +- UEFI environment must provide a system memory map and meet the requirements +for link:https://arm-software.github.io/ebbr/#memory-map[EBBR - Memory Map]. + In addition to this, should we standardize a start address (i.e. 0x80000000) We should discuss this +===== Boot-Loader +TBD + +===== Discovery Mechanisms +- The base specification mandates the use of Devicetree for system description. +- System must meet link: https://arm-software.github.io/ebbr/#devicetree[EBBR - Devicetree requirements] +to comply with this base specification. Also refer Devicetree tables section +in chapter - 4.6 EFI Configuration Table & Properties Table of UEFI +specification. -==== Runtime services -* SBI -* UEFI +===== Runtime Services +====== SBI +- Firmware must implement the runtime services/extensions specified by the +RISC-V SBI Specification. I think we can just mandate SBI v0.3. The base specification may not have to implement all the SBI extensions in future. But then shall we not revise the base spec and mention what not to implement from SBI spec here, Just like EBBR makes some things deprecated and optional from UEFI and other specs? +- Wherever applicable firmware must implement UEFI interfaces over similar +interfaces and services present in the SBI specification. For example, UEFI +runtime services must implement ResetSystem() via SBI Reset extension. +- Legacy Extensions from the SBI Specification are deprecated and must not be +implemented. + +====== UEFI +- Firmware must conform to the +link:https://arm-software.github.io/ebbr/#uefi-runtime-services[EBBR - UEFI EFI_RUNTIME_SERVICES requirements]. +- Firmware must meet the requirements for +link: https://arm-software.github.io/ebbr/#runtime-device-mappings[EBBR - Runtime Device Mappings] +to avoid conflict between the firmware and OS when accessing the mapped +devices. +- Compliant UEFI runtime environment must meet the requirements for the +link: https://arm-software.github.io/ebbr/#runtime-variable-access[EBBR - Runtime Variable Access]. +- Compliant implementation must meet the Realtime Clock requirements +link:https://arm-software.github.io/ebbr/#real-time-clock-rtc[EBBR - UEFI RTC interface] +if RTC is present in the system. // Server extension for Linux-2022 Platform === Server Extension -- Regards, Atish
More All Messages By This Member

1 - 20 of 29

Previous Topic Next Topic

Home Hashtags Subgroups Terms