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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

Jonathan, With EDK2 + OpenSBI running in background, the S-mode software will see SBI implementation ID of OpenSBI because EDK2 uses unmodified OpenSBI as library. This means from S-mode

Anup, are you saying that EDK2's extension would be the only use of ext_id = 0xA000000 + opensbi_imp_id or that any firmware that uses OpenSBI is free to make a (potentially incompatible) extension

Hi Anup, Thanks for the clarification. I have updated PR according to this. edk2 is removed from SBI implementation ID. Thanks Anup and Jonathan. Abner