RISC-V Platform Spec Review - Canonical - Meeting Minutes 9/15/2021
Comments after review with Canonical in RED
Regards
Kumar
-----Original Message-----
From: Heinrich Schuchardt <heinrich.schuchardt@...>
Sent: Wednesday, September 8, 2021 1:41 AM
To: Kumar Sankaran <ksankaran@...>
Cc: Atish Patra <Atish.Patra@...>; Philipp Tomsich <ptomsich@...>; tech-unixplatformspec@...
Subject: Re: RISC-V Platform Spec Review - Canonical
On 9/8/21 6:21 AM, Kumar Sankaran wrote:
> Hi Heinrich,
>
> As you know, we have been working on the RISC-V platform spec. At this
> point, the DRAFT version of the spec is ready for review and is
> available here
> https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc
> <https://github.com/riscv/riscv-platform-specs/blob/main/riscv-platform-spec.adoc>
Dear Kumar,
please, see my comments below.
>
> I wanted to request you to do a review of the spec and provide us with
> all your comments from a Canonical/Ubuntu perspective. Would you be
> available next week Wed Sep 15^th 9AM PST to go thru a final walk-thru
> and go over your comments as well?
Yes the time is fine.
>
> Let us know and I will send out a meeting invite. Please let me know who
> else from Canonical should be involved in the review and do forward this
> email and the link to the spec to them as well.
I will forward the mail internally.
>
> Thanking you for your help.
>
> Regards
>
> Kumar
>
Overall the platform specification requires that the reader is quite
familiar at least with the ISA specifications. Maybe in a later stage we
need a paper that is more accessible for a newcomer.
Add commentary on how to read the document with the ISA specs.
Terminology:
Please, add EBBR [15]
Will make this change
2.1.4.2.1. Legacy wired IRQs - DEPRECATED
Please, provide a definition of deprecated in the terminology or the
introduction as the usage of this word is RISCV.org specific.
Copy the key definitions of DEPRECATED, MANDATORY etc. again to the platform spec, so its clear to understand this from the platform spec
2.1.6. Boot Process
Please, add a reference [15] for EBBR.
Will make this change
2.2.6.1. UEFI
We already require that SBI implements the system reset extension. So
"If SBI SRST implementation is also available, the OS should not use the
SBI interface directly but use this UEFI interface."
can be changed to
"The OS shall not use the SBI interface directly but use this UEFI service."
(The UEFI specification uses the word "runtime service".)
Use the existing text in the spec since it covers the right use cases.
2.2. Server Extension
Should we require the implementation of the EFI_TCG2_PROTOCOL
which is the basis for measured boot? Both EDK II and U-Boot support the
protocol if a TPM implementation is available.
The RISC-V security requirements for platform are currently under discussion and being owned by the security/TEE group within RISC-V. This requirement will be addressed along with the security requirements. Should track this within the platform security requirements.
UART 2.1.5.1
The UART text will be reworded as the following. The platform spec will mandate the UART support only for hardware and firmware. Support for this UART in software layers running on top of the firmware like boot-loaders, kernel etc. is NOT mandatory.
In order to facilitate the bring-up and debug of the low level initial platform, hardware is required to implement a UART port which confirms to the following requirements and firmware must support the console using this UART:
- The UART register addresses are required to be aligned to 4 byte boundaries. If the implemented register width is less than 4 bytes then the implemented bytes are required to be mapped starting at the smallest address.
- The UART port implementation is required to be register-compatible with one of the following:
- UART 16550 - REQUIRED
- UART 8250 - DEPRECATED
Otherwise the specification looks fine to me.
Best regards
Heinrich