tech-unixplatformspec@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

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

By atishp@... · #57 ·

Re: SBI Error codes

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

By Jonathan Behrens <behrensj@...> · #56 ·

Re: SBI Error codes

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

By Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...> · #55 ·

Re: SBI Error codes

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

By Jonathan Behrens <behrensj@...> · #54 ·

Re: SBI Error codes

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

By Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...> · #53 ·

Re: SBI Error codes

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

By Jonathan Behrens <behrensj@...> · #52 ·

SBI Error codes

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

By Schaefer, Daniel Helmut (DualStudy) <daniel.schaefer@...> · #51 ·

[PATCH] Clarify VMID consideration for SBI HFENCE VVMA calls

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

By Anup Patel · #50 ·

[PATCH v4] Add system reset extension

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

By Anup Patel · #49 ·

Re: [PATCH v3] Add system reboot extension

By Anup Patel · #48 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By Abner Chang <abner.chang@...> · #47 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By atishp@... · #46 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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.

By Anup Patel · #45 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By Abner Chang <abner.chang@...> · #44 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By Anup Patel · #43 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By Jonathan Behrens <behrensj@...> · #42 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By Abner Chang <abner.chang@...> · #41 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By Anup Patel · #40 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By Jonathan Behrens <behrensj@...> · #39 ·

Re: [RISC-V] [software] Add SBI extension space for firmware code base implementation

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

By Abner Chang <abner.chang@...> · #38 ·

1801 - 1820 of 1857

Home Hashtags Subgroups Terms