and that is fine if other firmware code base use the same0xA000000 + opensbi_imp_id however the extension is incompatible each other, because the firmware code base SBI is very firmware code base

Anup wrote: But EDK2 can and will register extensions with OpenSBI, meaning that even identical OpenSBI versions might behave differently with regards to such extension. So far I think you are right

As-per my understanding, U-Boot and Coreboot don’t need this SBI firmware code base extension. Other SBI extensions are sufficient for these bootloaders. In my opinion, use of SBI firmware code

We would like to have firmware code base SBI based on OpenSBI implementation ID, because edk2 is not one of the implementations of SBI. I saw the patches of overriding SBI implementation ID was also

For riscv-sbi-doc, we have not finalized mailing list based review OR Github PR based review so most of usl are sending riscv-sbi-doc changes as patches to mailing list and Github PR.

Kindly send the proposal to the mailing list. We have enough topics now that we can schedule a meeting to finalize things. -- Regards, Atish

Thanks Anup and Atish, Just wondering the way to submit the changes for adding firmware code base SBI extension space to riscv-sbi-doc. I already had a PR on Github, we can discuss this in the

This patch adds SBI v0.2 compliant system reset extension. It defines the sbi_system_reset function which does different things based on reset_type parameter: 1. shutdown - Power-off the entire

The SBI HFENCE VVMA calls use current VMID (in HGATP CSR) of calling HART for flushing TLB enteries. This fact is not clearly evident in current documentatation of HFENCE VVMA calls hence this patch

Hi all, The SBI spec defines a standard set of error codes, which SBI functions can return in case of failure (or success). Each function defined in the SBI spec also defines which error codes it

I'd argue that standard functions should only be allowed to return the error codes specifically listed in their descriptions (or SBI_ERR_INVALID_PARAM for invalid hart masks). It makes it way easier

Yes, my thinking, too. I created a PR with my proposed additions to the spec: https://github.com/riscv/riscv-sbi-doc/pull/51 Inline here also: Every function defined in the specification has a set

Is it really necessary to include "Cases unaccounted for by the specification should use `SBI_ERR_FAILED` and be added in the next version of the SBI specification." ? This empowers an implementation

Hi Abner and Jonathan, you're right. I included that sentence to give the implementor a way out, if the spec doesn't cover a particular case. Now I understand that this would

I'd be in favor of making sure our use of 'must', 'should', etc. are consistent with that RFC. I also noticed that there's some parts that probably belong in a non-normative conventions chapter. Stuff

wrote: Yeah. That would be useful. Patches are welcome!! As discussed in the OpenSBI mailing list, this might not be possible always. Supervisor software should decide whether it wants to hang

From: Daniel Schaefer <git@...> Hi, I had opened a PR to SBI for adding a README: https://github.com/riscv/riscv-sbi-doc/pull/50 And now I'm also posting it here for people who might

Signed-off-by: Daniel Schaefer <daniel.schaefer@...> --- README.adoc | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 README.adoc diff --git a/README.adoc

<daniel.schaefer@...> wrote: Reviewed-by: Bin Meng <bin.meng@...>