RISC-V UEFI systems need to support new RISCV_BOOT_PROTOCOL. This protocol is required to communicate the boot hart ID from firmware to the bootloader/kernel. This protocol specification is

There was no need for any extension specific return value yet. I doubt if we will need one in the future. To reduce ambiguity, how about this change: "Returns 0 if the given SBI extension ID (EID)

Why should the value be implementation specific and not extension specific? I would prefer if the specification would provide extension specific unique return values instead of introducing ambiguity

Sounds good to me as well. I will make the change.

Hi All, I submitted a pull request to the platform spec repo: https://github.com/riscv/riscv-platform-specs/pull/75 This is definitely a WIP, but I wanted to start the conversation. Much of the

Are we or will we be using any benchmarks here? I worry that this is based on experience. Workloads have evolved. Things like traversing workloads (hadoop, cpu encrypt, cpu compress, ...) and sparse

Hi all, A few comments to add on here: - The expectation in the CMO group was that there *could* be different cache block sizes for different operations. As Aaron points out, one may have one block

Hi All, During the Platform HSC the topic of specifying an expected cache granule size for a platform was brought up. Below are some thoughts/observations on the topic. The purpose of this email is to

The RVA22S64 ISA profile will provide all that detail. An 2022 OS-A platform spec will simply mandate the RVA22S64 profile. Greg

Hi Greg, Just my two cents - wouldn’t it be much clearer to distill the paragraph into a table that clearly outlines which feature, ISA-subset is required in each

That comment was referring to the fact that one can view a platform as only specifying/standardizing S/VS-mode functionality, but it actually is also indirectly specifying/standardizing U/VU-mode ISA

Could you explain in what way you think it is wrong? I disagree; I think the parenthetical comment is unnecessary in the normative text. The first portion is explicit in the privileged

All, Recently a PR was sent out to remove U and VU mode standardization from the platform spec scope. Which is sort of right and sort of wrong. I brought this issue up with Krste and Andrew

Hi All, The next platform HSC meeting is scheduled on Mon Jan 24th 2022 at 8AM PST. Here are the details: Agenda and minutes kept on the github

Thank you for your reply

That won't be required as the specification clearly states that "SBI extensions as whole are optional but they shall not be partially implemented. If sbi_probe_extension() signals that an extension

3.4. Function: Probe SBI extension (FID #3) struct sbiret sbi_probe_extension(long extension_id); Returns 0 if the given SBI extension ID (EID) is not available, or an extension-specific

Hi Paul, Can you send a PR please? Regards Kumar

Indeed. I'm sure we'll cross that bridge eventually (at which point ratification should be very smooth).

Hi Andrew, I mostly agree with your suggestion considering the fact that we have very few (or none) RV32 Linux (or RichOS) capable systems. I would also like to correct my previous comment about the