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

Home Messages Hashtags Subgroups

Date Date 21 - 29 of 29

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

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
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
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
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
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
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
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
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
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

21 - 29 of 29

1
2

Previous Topic Next Topic

Home Hashtags Subgroups Terms