// SPDX-License-Identifier: CC-BY-4.0 // // introduction.adoc: provide an introduction to the document // // Provide a basic introduction to the overall document, defining some // key terms and

Hm, I don't know. OpenSBI doesn't seem to provide this info to its payloads (presumably whatever sets up fw_dynamic ensures that the payload is intended for U-mode). Perhaps change to and then have

How should the SBI user detect whether it is in supervisor mode or user mode? Will this be indicated in the device tree? I believe current implementations all set/require that at initialization

This extension is an attempt to make it easier for supervisor mode software to identify which harts are valid, and which are part of the execution environment. This is helpful for hotplug,

The initial state of software running in the SBI was not specified. Particularly egregious was the omission of the requirement that a0 contain the hartid of the hart. That behavior was used to justify

This is perhaps obvious, but should be stated explicitly. In particular, this specification extends the instruction set by specifying particular behavior for the `ebreak` instruction. If

Terms like should et. al. are commonly understood to introduce a requirement, but it is sometimes unclear exactly what they mean. Link to the RFC specifying particular meanings for those terms. This

This allows it to be cross-referenced easily. Signed-off-by: Sean Anderson <seanga2@...> --- riscv-sbi.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/riscv-sbi.adoc

This clarifies some previously-unspecified terminology. It also specifies the initial state. This should make it easier to define something sane for rebooting in #39 [1] without needing to require

Most of the sentences end with only one space and period. Change the outliers to conform. Also fix sbi_hart_stop to match the style of other functions with no arguments. Signed-off-by: Sean Anderson

# Profiles and Platform Spec Technical Subcommittee (P2TS) Agenda: 26 Oct 2020 ## Meeting Info: weekly on Mondays (09:00 PST, 16:00 UTC) Details:

Yeah, what Atish says. Sorry about that, Drew. I probably updated the calendar in exactly the most confusing manner possible. But, we are to be every Monday from here on out. --

The meeting is switched to Monday 9AM every week to avoid conflict. The calendar is updated as well. The next "Profiles and Platform Spec TS" meeting is scheduled on Mon, October 26, 9am –

Hi, I am a little confused. I had the meeting starting now, but I don't see it on https://sites.google.com/a/riscv.org/risc-v-staff/home/tech-groups-cal thanks, drew

Looks good to me. I don't see a reviewed-by tag as this is not actual patch. I have approved the PR in github. https://github.com/riscv/riscv-sbi-doc/pull/61 For future reference, it is preferred

# Profiles and Platform Spec Technical Subcommittee (P2TS) Agenda: 19 Oct 2020 ## Meeting Info: weekly on Mondays (09:00 PST, 16:00 UTC) Details:

Hi Paul, Please see my response below inline …. Regards, Anup

Folks, I unfortunately won't be able to attend this Monday's call due to a conflict - but should be able to attend on the 26th. So in the event someone wants to discuss the PSCI gateway

Hi folks, Here's the rough sketch of the Linux kernel portion of a PSCI gateway through SBI, as we've been discussing in our calls:

Hello All, As we very glad to acknowledge, RISC-V's SBI standard now have a list of implementations, such as BBL, OpenSBI, Xvisitor and KVM. To expand the list in the Specification, we are now to