Abner Chang
Hi Sunil, Below is my feedback to this patch after the discussion in another thread,
Linux2022 Platform is defined as the baseline requirements for RISC-V platforms, and with "Server Extension" to define the additional features of the server platform. My thought is,
Change "Server Extensions" under Linux2022 platform to just "Extension". - Those extensions could be chosen for Embeded2022, Server2022, and maybe others in the future such as the desktop or notebook. - Have a separate section "Server2022" same as Embedded2022, this makes the spec looks consistent from the platform viewpoint. The current layout seems weird that Server Extension is in the scope of
Linux2022 platform.
Choice the extensions from "Extension" for Server2020. With this, we can have another category in the future for the server that may choose the different extension set. (e.g. RV128 for large-scale server).
We can list all extensions other than baseline features in "Extension". Then in Server2022, we can have the mandatory features chosen from "Extension".
How do you think?
Thanks Abner
Hi Abner,
Sorry I missed to respond to this email.
On 16/04/21 6:30 am, Abner Chang wrote:
>
>
> Sunil V L <sunilvl@... <mailto:sunilvl@...>> 於 2021年4月15日 週四 下午11:23寫道：
>
> On Thu, Apr 15, 2021 at 05:04:47PM +0200, Heinrich Schuchardt wrote:
> > Am 15. April 2021 16:56:02 MESZ schrieb Sunil V L <sunilvl@... <mailto:sunilvl@...>>:
> > >Hi Abner,
> > >
> > >On Thu, Apr 15, 2021 at 09:44:00PM +0800, Abner Chang wrote:
> > >> Heinrich Schuchardt <xypron.glpk@... <mailto:xypron.glpk@...>> 於 2021年4月14日 週三 下午9:19寫道：
> > >>
> > >> > On 14.04.21 10:19, Abner Chang wrote:
> > >> > > Hi Sunil,
> > >> > > Thanks for initial this.
> > >> > > I would like to suggest limiting the scope of Server Extension
> > >spec for
> > >> > > RISC-V server platform and only list the items which are RISC-V
> > >related.
> > >> > > I think the RISC-V platform spec is aimed at what should be
> > >implemented
> > >> > > on RISC-V platform and also follow the industrial standards. That
> > >says
> > >> > > only define the necessary spec for RISC-V platform-specific H/W
> > >features
> > >> > > is sufficient. Forgive me if I am wrong.
> > >> > >
> > >> > > My comments in below,
> > >> > >
> > >> > > Sunil V L <sunilvl@... <mailto:sunilvl@...>
> > ><mailto:sunilvl@... <mailto:sunilvl@...>>>
> > >> > > 於 2021年4月12日 週一 下午6:40寫道：
> > >> > >
> > >> > > This specifies mandatory requirements for server class
> > >platforms in
> > >> > > addition to the requirements in base specification.
> > >> > >
> > >> > > Signed-off-by: Sunil V L <sunilvl@... <mailto:sunilvl@...>
> > >> > > <mailto:sunilvl@... <mailto:sunilvl@...>>>
> > >> > >
> > >> > > Changes in V2:
> > >> > > - Aligned to 80 characters.
> > >> > > - Removed protocols related to graphics support.
> > >> > > - Referred to SMBIOS conformance guidelines.
> > >> > > ---
> > >> > > changelog.adoc | 4 +
> > >> > > licensing.adoc | 1 +
> > >> > > riscv-platform-spec.adoc | 187
> > >> > +++++++++++++++++++++++++++++++++++++--
> > >> > > 3 files changed, 183 insertions(+), 9 deletions(-)
> > >> > >
> > >> > > diff --git a/changelog.adoc b/changelog.adoc
> > >> > > index 466b2ef..b7577be 100644
> > >> > > --- a/changelog.adoc
> > >> > > +++ b/changelog.adoc
> > >> > > @@ -7,6 +7,10 @@
> > >> > > [preface]
> > >> > > ## Change Log
> > >> > >
> > >> > > +### version 0.3-rc0
> > >> > > +* 2021-04-08:
> > >> > > +** Initial commit of server firmware requirements
> > >> > > +
> > >> > > ### version 0.2-rc0
> > >> > > * 2021-03-16:
> > >> > > ** Added 2022 platforms
> > >> > > diff --git a/licensing.adoc b/licensing.adoc
> > >> > > index 6a9cdd6..89bd6ee 100644
> > >> > > --- a/licensing.adoc
> > >> > > +++ b/licensing.adoc
> > >> > > @@ -15,6 +15,7 @@ This RISC-V Profile and Platform
> > >Specification
> > >> > > (P2S) is
> > >> > > (C) 2017 Andrew Waterman <andrew@... <mailto:andrew@...> <mailto:
> > >> > andrew@... <mailto:andrew@...>>>
> > >> > > (C) 2020 Al Stone <ahs3@... <mailto:ahs3@...> <mailto:ahs3@... <mailto:ahs3@...>>>
> > >> > > (C) 2021 Kumar Sankaran <ksankaran@... <mailto:ksankaran@...>
> > >> > > <mailto:ksankaran@... <mailto:ksankaran@...>>>
> > >> > > +(C) 2021 Sunil V L <sunilvl@... <mailto:sunilvl@...>
> > >> > > <mailto:sunilvl@... <mailto:sunilvl@...>>>
> > >> > >
> > >> > > The P2S is licensed under the Creative Commons Attribution
> > >4.0
> > >> > > International
> > >> > > License (CC-BY 4.0). The full license text is available at
> > >> > > diff --git a/riscv-platform-spec.adoc
> > >b/riscv-platform-spec.adoc
> > >> > > index 9d860f8..62009fb 100644
> > >> > > --- a/riscv-platform-spec.adoc
> > >> > > +++ b/riscv-platform-spec.adoc
> > >> > > @@ -8,11 +8,13 @@
> > >> > > = RISC-V Platform Specification
> > >> > > :author: RISC-V Platform Specification Task Group
> > >> > > :email: tech-unixplatformspec@... <mailto:tech-unixplatformspec@...>
> > >> > > <mailto:tech-unixplatformspec@... <mailto:tech-unixplatformspec@...>>
> > >> > > -:revnumber: 0.2-rc0
> > >> > > -:revdate: Mar 2021
> > >> > > +:revnumber: 0.3-rc0
> > >> > > +:revdate: Apr 2021
> > >> > > :doctype: book
> > >> > > :sectnums:
> > >> > > +:sectnumlevels: 5
> > >> > > :toc: macro
> > >> > > +:toclevels: 5
> > >> > >
> > >> > > // table of contents
> > >> > > toc::[]
> > >> > > @@ -68,14 +70,181 @@ include::profiles.adoc[]
> > >> > >
> > >> > > // Server extension for Linux-2022 Platform
> > >> > > === Server Extension
> > >> > > -==== Boot Process
> > >> > > -* Firmware
> > >> > > -* Boot-Loader
> > >> > > -* Discovery Mechanisms
> > >> > > +The server extension specifies additional requirements
> > >apart from
> > >> > base
> > >> > > +requirements for RV64I based server class platforms. Support
> > >for
> > >> > RV128I
> > >> > > +based platforms will be in future when available.
> > >> > >
> > >> > > -==== Runtime services
> > >> > > -* SBI
> > >> > > -* UEFI
> > >> > > +The platforms which conform to server extension must
> > >implement
> > >> > > +
> > >> > > +- Advanced Platform-Level Interrupt Controller (APLIC).
> > >> > [*Dependency:
> > >> > > + AIA spec should be ratified*]
> > >> > > +- Incoming MSI Controller (IMSIC) [*Dependency: AIA spec
> > >should be
> > >> > > +ratified*]
> > >> > > +- PCIe.
> > >> > >
> > >> > > +
> > >> > > +- RISC-V Hypervisor-level Instruction-Set Extensions.
> > >[*Dependency:
> > >> > > +Spec should be ratified*]
> > >> > >
> > >> > > Is this the extension only for the server platform? Could be an
> > >> > > extension for all platforms, right?
> > >> > >
> > >> > > +- Incoming MSI Controller (IMSIC) with at least 1 guest
> > >interrupt
> > >> > > +file for each HART ?? (*TBD*)
> > >> > > +- IOMMU with support for memory resident interrupt files ??
> > >(*TBD*)
> > >> > >
> > >> > > +
> > >> > > +==== Boot and Runtime Requirements
> > >> > > +===== Firmware
> > >> > > +The boot and system firmware for the RV64I server platforms
> > >must be
> > >> > > +based on UEFI as per the base specification with some
> > >additional
> > >> > >
> > >> > > "must be" seems to me a little bit strong. The system firmware
> > >could be
> > >> > > LinuxBoot, uboot, or other solutions which do not have or only
> > >support
> > >> > > the minimum requirements of UEFI protocols
> > >> > > and I think it would be better to change this section from "
> > >Firmware"
> > >> > > to "UEFI Based System Firmware" under Server Extension section.
> > >> >
> > >> > If you look at the ARM landscape there you have:
> > >> >
> > >> > EBBR: sub-set of UEFI required, fulfilled by U-Boot
> > >> > SBBR: more UEFI required, fulfilled by EDK II
> > >> > LBBR: LinuxBoot required
> > >> >
> > >> > The RISC-V Linux platform requirements matches EBBR.
> > >> > My understanding was that this chapter is meant to match SBBR.
> > >> > Maybe we need an extra chapter on LinuxBoot requirements.
> > >> >
> > >> Exactly. If use Linuxboot as the firmware solution (this has been
> > >> discussing and investigating for a while although it is not mature
> > >yet) for
> > >> the server platform and launched after EDK2 PEI phase, then who cares
> > >about
> > >> UEFI?
> > >> I suggest we have two sections, one for UEFI based system another is
> > >not.
> > >>
> > >It is correct that server extension chapter is similar to SBBR.
> > >
> > >We are not specifying any implementations here. U-Boot/EDK2/Linuxboot
> > >all are
> > >different types of firmware implementations in my opinion. All we are
> > >mandating here is the set of requirements server class platforms should
> > >have. Why do we need to have separate chapter for Linuxboot?
> >
> > LinuxBoot is really special. It is not UEFI compliant but uses kexec which cannot boot non-Linux OSes.
> >
> One criteria for server spec is to support different OSs including
> windows. As per
> https://www.phoronix.com/scan.php?page=news_item&px=LinuxBoot-Can-Boot-Windows <https://www.phoronix.com/scan.php?page=news_item&px=LinuxBoot-Can-Boot-Windows>
> Linuxboot booted windows supporting UEFI boot and runtime services
> (may be not a perfect implementation yet).
>
> From server platform perspective, any new firmware implementation need
> to satisfy the requirements from the OS. I really can't see how
> Linuxboot can be so different and introduce whole set of new requirements
> on multiple OSs. As per my understanding it is mainly trying to replace
> EDK2 DXE phase with well tested Linux drivers. But the environment what
> OS like windows will see should be kept intact.
>
> I agree with you at this point.
> But the benefit of using Linuxboot is to reduce firmware developer effort (maybe we don't need firmware developers in the future :-) ) and leverage the Linux driver as the boot firmware driver. I don't see the advantage if LinuxBoot requires the effort to implement UEFI stuff for booting system and handoff to OS. Maybe I am wrong.
> Again, my point is just the UEFI could be not the only firmware solution for server platforms.
Agreed. I understand the advantage of linuxboot. But the generic server platform need to support different OSs like windows, linux and BSD etc. These OSs put major restriction on firmware implementations. In fact the ACPI requirement is also driven by the OS especially Microsoft since it doesn't support DT. So, any solution like Linuxboot which doesn't support different OS without modification can not be considered for generic server platform.
The current generic server extension is similar to SBBR (simplified with single level). Even EBBR/SBBR mandates the UEFI firmware. For Linuxboot, ARM has separate LBBR which we can also add in future for risc-v.
Thanks
Sunil
>
> Thanks
> Abenr
>
>
> > >
> > >> >
> > >> > >
> > >> > > +requirements as mentioned below.
> > >> > >
> > >> > > +
> > >> > > +====== PCIe support
> > >> > > +PCIe is mandatory for server compliance. Hence,
> > >> > > +*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* ,
> > >> > > +*EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION* and
> > >> > > *EFI_PCI_IO_PROTOCOL*
> > >> > > +must be implemented.
> > >> > >
> > >> > > Not sure why we have to mention PCIe here for the server
> > >platform. This
> > >> > > seems to me regardless of RISC-V platform. Other buses such as
> > >CXL or
> > >> > > Gen-Z could be supported as well. This is more like the part of
> > >the
> > >> > > system firmware spec.
> > >> > > If we want to mention this, I would say *if* PCIe devices are
> > >supported
> > >> > > on the platform. Then *EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL* must be
> > >> > > installed for the UEFI firmware solution.
> > >> > >
> > >> > > We don't have to mention protocol function
> > >> > > EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_CONFIGURATION and
> > >EFI_PCI_IO_PROTOCOL,
> > >> > > those should be handled by UEFI implementation, such as the
> > >UEFI/EDK2
> > >> > > PCI BUS driver
> > >> > >
> > >> > > +
> > >> > > +====== UEFI configuration tables
> > >> > > +The platform which is complaint with server extension must
> > >provide
> > >> > > following
> > >> > > +tables.
> > >> > > +
> > >> > > +* *EFI_ACPI_20_TABLE_GUID* ACPI configuration table which is
> > >at
> > >> > > version 6.4+ or
> > >> > > +newer with HW-Reduced ACPI model.
> > >> > >
> > >> > > ACPI table is general for all ACPI-aware OS. This seems not
> > >necessary
> > >> > > to be in the scope of RISC-V platform spec,
> > >> > >
> > >> > > +* *SMBIOS3_TABLE_GUID* SMBIOS table which conforms to
> > >version 3.4
> > >> > > or later.
> > >> > >
> > >> > > uboot doesn't have SMBIOS at least for the RISC-V platform.
> > >Devicetree
> > >> > > table UEFI configuration table is needed as well for the
> > >> > > non-SMBIOS-aware OS.
> > >> >
> > >> > U-Boot creates an SMBIOS table with some information for ARM. This
> > >could
> > >> > easily be extended to RISC-V.
> > >> >
> > >> > > So we can rephrase this to * *SMBIOS3_TABLE_GUID* SMBIOS table
> > >which
> > >> > > conforms to version 3.4 or later if the platform support
> > >SMBIOS-aware
> > >> > > pre-OS applications and OS.
> > >> > > Also add another similar section for the device tree use case,
> > >which
> > >> > > is EFI_DTB_TABLE_GUID for the platform which supports DT-aware
> > >pre-OS
> > >> > > application or OS.
> > >> >
> > >> > The device-tree use case is described in the EBBR which is
> > >referenced in
> > >> > the Linux platform chapter. Why should this be repeated here?
> > >> >
> > >> We would like to have a link here to point to ARM EBBR? I don't think
> > >that
> > >> is a good idea for RISC-V platform spec.
> > >> As I know EFI_DTB_GUID which defined in EBBR will be removed because
> > >> EFI_DTB_TABLE_GUID is standardized and pushed to UEFI 2.9 for any
> > >> architectures which require DT. SBBR will just use EFI_DTB_TABLE_GUID
> > >as
> > >> well because this GUID is proposed by SBBR people. RISC-V should also
> > >use
> > >> EFI_DTB_TABLE_GUID instead of using FDT_TABLE_GUID.
> > >>
> > >I assume EBBR also will get updated in that case. Isn't it?
> > >
> > >>
> > >> > > And the reason to have these configuration tables is either
> > >SMBIOS or DT
> > >> > > carries the information of RISC-V HW features.
> > >> >
> > >> > The information in SMBIOS and DT is independent.
> > >>
> > >> Yes, those two are independent.
> > >>
> > >>
> > >> > SMBIOS will carry
> > >> > information that does not exist in the device-tree.
> > >> >
> > >> SMBIOS will also carry the information even that exists in DT for the
> > >> non-DT-aware OS such as Windows-based system.
> > >> The server is able to boot to either Windows or Linux-based OS, these
> > >two
> > >> data structures should be mentioned separately.
> > >>
> > >> Regards,
> > >> Abner
> > >>
> > >>
> > >> > Best regards
> > >> >
> > >> > Heinrich
> > >> >
> > >> > >
> > >> > >
> > >> > > +
> > >> > > +====== UEFI Protocol support
> > >> > > +The UEFI protocols listed below must be implemented in
> > >addition to
> > >> > > the base
> > >> > > +spec requirements.
> > >> > > +
> > >> > > +.Mandatory UEFI Protocols
> > >> > > +[cols="3,1,1", width=95%, align="center", options="header"]
> > >> > > +|===
> > >> > > +|Protocol | UEFI 2.9 $ | Note
> > >> > > +|EFI_LOAD_FILE2_PROTOCOL | 13.2 |
> > >> > > +|EFI_DECOMPRESS_PROTOCOL | 19.5 |
> > >> > > +|===
> > >> > > +
> > >> > >
> > >> > > What UEFI protocols must be implemented is platform design
> > >specific. We
> > >> > > may have a long list of UEFI protocols for the large system (for
> > >example
> > >> > > if it supports any kind of boot methods). Therefore I don't think
> > >we
> > >> > > need this section.
> > >> > >
> > >> > > +===== Boot-Loader
> > >> > > +*TBD*
> > >> > > +
> > >> > > +===== Discovery Mechanisms (ACPI)
> > >> > >
> > >> > > First of all, I don't quite understand what exactly the
> > >Discovery
> > >> > > Mechanisms mean? for the hardware feature discovery?
> > >> > >
> > >> > > If so, SMBIOS and DeviceTree is also part of this section, not
> > >only ACPI
> > >> > >
> > >> > > +For RV64I server platforms, it is mandatory to have ACPI
> > >tables
> > >> > > passed via UEFI
> > >> > > +to the operating system for the purpose of discovery and the
> > >> > > configuration of
> > >> > > +the hardware. This section defines mandatory ACPI tables and
> > >> > > objects. All other
> > >> > > +ACPI tables for RISC-V can be implemented as required
> > >adhering to
> > >> > > the ACPI spec
> > >> > > +version 6.4+(RISC-V support when added).
> > >> > >
> > >> > >
> > >> > >
> > >> > > +
> > >> > > +====== ACPI System Description Tables
> > >> > > +
> > >> > > +
> > >> > > +.Mandatory ACPI tables
> > >> > > +[cols="3,1,2", width=95%, align="center", options="header"]
> > >> > > +|===
> > >> > > +|ACPI Table |ACPI 6.4+
> > >$|Note
> > >> > > +|Root System Description Pointer (RSDP) |5.2.5 |
> > >> > > +|Extended System Description Table (XSDT) |5.2.8 |
> > >> > > +|Fixed ACPI Description Table (FADT) |5.2.9 |
> > >> > > +|Differentiated System Description Table (DSDT)|5.2.11.1 |
> > >> > > +|Multiple APIC Description Table (MADT) |5.2.12
> > >|*TBD*:
> > >> > > Need ECR
> > >> > > +
> > >to add
> > >> > > +
> > >APLIC &
> > >> > > IMSIC
> > >> > > +
> > >(AIA)
> > >> > > to MADT
> > >> > > +|RISC-V Timer Description Table |New
> > >|*TBD*:
> > >> > > _DSD to
> > >> > > +
> > >> > communicate
> > >> > > +
> > >> > > timebase-frequency?
> > >> > > +|Processor Properties Topology Table (PPTT) |5.2.29
> > >> > > |CPU/Cache topology
> > >> > > +
> > >> > information
> > >> > > +|Memory-mapped ConFiGuration space (MCFG) |PCI-SIG
> > >> > > |Required for PCIe
> > >> > > +
> > >support
> > >> > > +|Debug Port Table 2 (DBG2) |Microsoft
> > >|*TBD*:
> > >> > > 16550D?
> > >> > > +|Serial Port Console Redirection (SPCR) |Microsoft
> > >|*TBD*:
> > >> > > 16550D?
> > >> > > +|System Resource Affinity Table (SRAT) |5.2.16
> > >> > > |Required if the
> > >> > > +
> > >> > > platform supports NUMA
> > >> > > +|System Locality Information Table (SLIT) |5.2.17
> > >> > > |Required if the
> > >> > > +
> > >> > > platform supports NUMA
> > >> > > +|IOMMU Information Table |
> > >|*TBD*:
> > >> > > New IOMMU
> > >> > > +
> > >table
> > >> > > need to be
> > >> > > +
> > >defined
> > >> > > (like IVRS)
> > >> > > +|Software Delegated Exception Interface (SDEI) |SDEI
> > >|*TBD*:
> > >> > > New table
> > >> > > +
> > >and SBI
> > >> > > extension
> > >> > > +
> > >also
> > >> > > may be required
> > >> > > +|PMU event mapping table? |New
> > >|*TBD*:
> > >> > > New table
> > >> > > +
> > >required
> > >> > > +|===
> > >> > > +
> > >> > >
> > >> > > Most of the above tables are generic and not RISC-V specific for
> > >the
> > >> > > server platform. Perhaps only keep MADT, SDEI, and others which
> > >are
> > >> > > marked as "New". However, I don't know if those "New" tables have
> > >been
> > >> > > discussing in UEFI ASWG or those are just the proposal.
> > >> > >
> > >> > >
> > >> > > +====== ACPI Namespace
> > >> > > +
> > >> > > +- Processors must be defined under the System Bus (\_SB)
> > >name space.
> > >> > > +- Below list of Device Objects and Methods must be
> > >implemented for
> > >> > > each device
> > >> > > + definition in the DSDT.
> > >> > > +
> > >> > > +.Mandatory Device Objects and Methods
> > >> > > +[cols="1,2,3", width=95%, align="center", options="header"]
> > >> > > +|===
> > >> > > +|Object/Method | ACPI 6.4+ $ | Note
> > >> > > +|_AEI | 5.6.5.2 | Required for GPIO-signalled
> > >events.
> > >> > > +|_EVT | 5.6.5.3 | Required for
> > >interrupt-signalled
> > >> > events.
> > >> > > +|_ADR | 6.1.1 | Required for PCI
> > >> > > +|_HID | 6.1.5 |
> > >> > > +|_UID | 6.1.12 |
> > >> > > +|_CRS | 6.2.2 |
> > >> > > +|_CCA | 6.2.17 | Required for DMA capable
> > >devices
> > >> > > +|_STA | 6.3.7/7.2.4 | Device status
> > >> > > +|===
> > >> > >
> > >> > > Also, this seems to me not specific to RISC-V platform.
> > >> > >
> > >> > > +
> > >> > > +===== Runtime services
> > >> > > +====== SBI
> > >> > > +*TBD*
> > >> > > +
> > >> > > +====== UEFI
> > >> > > +It is mandatory to implement the UEFI run time services
> > >listed
> > >> > below.
> > >> > > +
> > >> > > +.Mandatory UEFI Runtime Services
> > >> > > +[cols="3,1,3", width=95%, align="center", options="header"]
> > >> > > +|===
> > >> > > +|Service | UEFI 2.9 $ | Note
> > >> > > +|GetVariable | 8.2 |
> > >> > > +|GetNextVariableName | 8.2 |
> > >> > > +|SetVariable | 8.2 | A dedicated
> > >storage for
> > >> > > firmware
> > >> > > + should be
> > >available so
> > >> > > that there
> > >> > > + is no conflict in
> > >access
> > >> > > by both
> > >> > > + firmware and the
> > >OS.
> > >> > > +|QueryVariableInfo | 8.2 |
> > >> > > +|GetTime | 8.3 | RTC Access by the
> > >OS
> > >> > > +|SetTime | 8.3 | If it is not
> > >possible to
> > >> > > set the RTC,
> > >> > > + the SetTime() can
> > >return
> > >> > > an error.
> > >> > > +|GetWakeupTime | 8.3 | Interface must be
> > >> > > implemented but it
> > >> > > + can return
> > >> > EFI_UNSUPPORTED.
> > >> > > +|SetWakeupTime | 8.3 | Interface must be
> > >> > > implemented but it
> > >> > > + can return
> > >> > EFI_UNSUPPORTED.
> > >> > > +|SetVirtualAddressMap | 8.4 |
> > >> > > +|ConvertPointer | 8.4 |
> > >> > > +|GetNextHighMonotonicCount | 8.5 |
> > >> > > +|ResetSystem | 8.5 | If SBI SRST
> > >> > > implementation is also
> > >> > > + available, the OS
> > >should
> > >> > > not use the
> > >> > > + SBI interface
> > >directly
> > >> > > but use this
> > >> > > + UEFI interface.
> > >> > > +|UpdateCapsule | 8.5 | Interface must be
> > >> > > implemented but it
> > >> > > + can return
> > >> > EFI_UNSUPPORTED.
> > >> > > +|QueryCapsuleCapabilities | 8.5 | Interface must be
> > >> > > implemented but it
> > >> > > + can return
> > >> > EFI_UNSUPPORTED.
> > >> > > +|===
> > >> > >
> > >> > > Not sure if we really need above section.
> > >> > >
> > >> > > +
> > >> > > +====== SMBIOS
> > >> > > +The System Management BIOS (SMBIOS) table is mandatory for
> > >the
> > >> > platform
> > >> > > +complaint to server extension. The SMBIOS table is
> > >identified using
> > >> > > +*SMBIOS3_TABLE_GUID* in UEFI configuration table.
> > >> > > EfiRuntimeServicesData must
> > >> > > +be the memory type used for the SMBIOS table.
> > >> > > +
> > >> > > +In addition to the conformance guidelines as mentioned in
> > >ANNEX A /
> > >> > > 6.2 of the
> > >> > > +SMBIOS specification 3.4.0, below additional structures are
> > >> > mandatory.
> > >> > > +
> > >> > > +.Mandatory SMBIOS structures
> > >> > > +[cols="4,1,2", width=95%, align="center", options="header"]
> > >> > > +|===
> > >> > > +|Structure Type | SMBIOS
> > >3.4.0 $ |
> > >> > Note
> > >> > > +|Management Controller Host Interface (Type 42) | 7.43
> > > |
> > >> > > *TBD*:
> > >> > > +
> > >> > > Redfish
> > >> > > +
> > >> > > support
> > >> > > +
> > >> > > mandatory?
> > >> > >
> > >> > > Not mandatory if no remote management for the system firmware
> > >platform
> > >> > > configurations.
> > >> > >
> > >> > > Abner
> > >> > >
> > >> > > +|Processor Additional Information (Type 44) | 7.45
> > > |
> > >> > > +|===
> > >> > >
> > >> > > ==== System Peripherals
> > >> > > * PCI-E
> > >> > > --
> > >> > > 2.25.1
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >
> > >
> > >
> >
>
|
