Is it expected that there should be a watchdog timer and timeout signal per hart in the system, or is okay for there to be one timer in the system and for the timeout signal to be delivered to a

Hi All, The next platform HSC meeting is scheduled on Wed Feb 23rd 2022 at 9AM PST. This meeting is moved to Wed as Monday Feb 21st is a holiday for President's Day in the US. Here are the

Chris, The Platforms effort is being reorganized and we'll spin up a task group for RVM-CSI (a source-level abstraction framework) up in the near future. RVM-CSI is very much in focus (for the

Chris, I'm cc'ing the chairs of the Software HC and the Platforms HSC. All platform efforts are being re-organized a bit as we speak (compared to thus far one group was trying to address a number of

Hi all, I lead the CPU software / SDK team at Imagination Technologies, we are entering the RISC-V space but I'm still quite new around here. At present we are most interested in embedded applications

nits: %s/RISCV_BOOT_PROTOCOL/RISCV_EFI_BOOT_PROTOCOL/ This new protocol is needed because ACPI cannot make use of the current device-tree based approach to transfer the boot hart ID to the next boot

Hi all! I just sent this to tech-chairs, but due to the nature of your work Stephano suggested getting feedback here as well. The Configuration Structure task group has been working on how software

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 profile? Michael 😄 Michael

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