We should have a table with dependencies for SBI extensions. E.g. SBI Time only required if sstc is not present SBI IPI/RFENCE is only required if IMSIC or SSWI is not present I will send a patch afte

Agreed. However, the additional verbose explanation doesn't hurt. So I am inclined to keep it unless somebody is strongly opposed to it.

Fixed. Thanks.

My bad. Fixed it.

Hi, The RISC-V international has recently established a ratification policy[1] for non-ISA specification as well. All of the non-ISA specifications (e.g SBI, psABI, ACLINT) will have to go through the

Some of the ISA requirement sections do not belong to a platform specification and can move to the profile specification. The fence.i recommendation belong to software section as it talks about a requ

The platform spec provides various choices for interrupt controller to be implemented in the platform. As M-mode is not a mandatory requirement any more and VS-mode is only required for platforms with

Last level cache and NUMA node cache events are not specific to per hart. Do not make them mandatory for per hart performance monitor events. Signed-off-by: Atish Patra <atishp@...> --- riscv

Signed-off-by: Atish Patra <atishp@...> --- riscv-platform-spec.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.ado

This version of the platform specification doesn't mandate M-mode requirements. However, it should specify M-mode access protection from lower privilege modes for platforms that do implement M-mode. O

As per the discussion in the mailing list, M-mode requirements should not be included in this version of the platform specification to allow platform vendors more flexibility in implementing privilege

Sure. I will update the patch. I was talking about the CMO (cache management operations) CSRs. Here are the details. https://github.com/riscv/riscv-CMOs/blob/master/specifications/cmobase-v0.6.pdf ok.

Table 1 merely states the information rather than requirement. For example: If category 3 (MSIs and Wired IRQs) is used, MSIs at M-mode can be provided using IMSIC while wired interrupts at M-mode can

This version of the platform specification doesn't mandate M-mode requirements. However, it should specify M-mode access protection from lower privilege modes for platforms that do implement M-mode. O

As per the discussion in the mailing list, M-mode requirements should not be included in this version of the platform specification to allow platform vendors more flexibility in implementing privilege

Signed-off-by: Atish Patra <atish.patra@...> --- riscv-platform-spec.adoc | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.ado

That may lead to a lot of fragmentation in terms of implementation in hardware and software customization. Isn't it ? Another issue with just specifying the intent is that how do we verify if a platfo

Sure. We will try to improve the text. Any suggestions are welcome. Thanks again for your feedback.

Just to add to Heinrich's point, LoadFile2 is the preferred method for loading initrd in RISC-V UEFI implementation as well.

ACLINT is a modular spec. It allows flexibility in implementing all three (MSWI/SSWI/MTIMER) devices. That's why, a platform can implement only MTIMER. In fact, server extension mandates only the last