I completely agree with you. Wait, are we looking at the same document? The version I have says: "All SBI functions share a single binary encoding, which facilitates the mixingof SBI extensions. This

It is nice that XLEN is defined elsewhere. But, please, do not expect the reader of the SBI specification to know where that definition is. Either we have to repeat the definition here or we have to

I think there's some confusion here. SBI is a binary interface, so the C functions are just shorthand for describing the input and output meanings of each register. The two sides of the interface

The width of int, long, etc., depend on the ABI. Perhaps we don't see issues right now when considering the "standard" ABIs currently defined in the psABI. However, new ABIs, like ilp32 for rv64,

The meaning of 'XLEN' and of 'unsigned int' are defined in the main RISC-V spec and the relevant ABI documents (someone should correct me if that link is the wrong one for the ABI specification). I do

The length of int, long, unsigned long is compiler specific. We do not wan= t to require the SBI and the operating system to use the same compiler. Instead the SBI standard shall define a binary

For what its worth, The Risc-V Privileged Architecture Spec Table 3.1 defines XLEN pretty clearly: MXL XLEN 1 32 2 64 3 128 Table 3.1: Encoding of MXL

The SBI specification uses a constant XLEN multiple times in the text without defining it. I assume XLEN is the bitness of the RISC-V implementation (32, 64, or 128). Furthermore reference is made

Overall looks good to me. Merging it via github PR. -- Regards, Atish

LGTM. Reviewed-by: Atish Patra <atish.patra@...> -- Regards, Atish

Adding EDK-II support for platforms usually takes more effort than U- Boot. I think we should keep U-Boot/EDK-II for the base and may choose only EDK-II for server extension. That is still the

Hi Heinrich, Sorry for the "up" post. Agree with your comments and there is no need to create new profiles. The intent for RISC-V Linux platforms is the following Base spec will have a UEFI

Hello Kumar, OpenSBI can collaborate both with both EDK II and U-Boot. For the Linux platform this should not make a difference as long as the UEFI firmware implementation and the SBI implementation

Up to now the SBI specification does not define how unsupported EIDs and FIDs shall be handled. Require returning error code SBI_ERR_NOT_SUPPORTED. Signed-off-by: Heinrich Schuchardt

Hi All, As we spoke during the meeting today, below are the chapters that we need owners for. We are looking for volunteers to own and write each of these chapters. Please review and provide feedback

Hi, The next platform meeting is scheduled on 8th march 7AM PST. Here are the details: Agenda and minutes kept on the github wiki: https://github.com/riscv/riscv-platform-specs/wiki Here are the

Hi All, The AIA SIG meeting has been added to the RISC-V tech groups calendar https://sites.google.com/a/riscv.org/risc-v-staff/home/tech-groups-cal Our first AIA SIG meeting will be on 11th

I think you might be confusing the "reserved for software" (RSW) bits in the PTE with the "Reserved" bits. The former are bits 8 and 9 in a PTE, while the latter are bits 54-63 in Sv39/Sv48 and don't

should an OS person weigh in on this? I asked previously about COW and was told a reserved bit could be used. ---------- Forwarded message --------- From: Greg Favor <gfavor@...> Date: Fri, Feb 26,

Reviewed-by: Atish Patra <atish.patra@...> -- Regards, Atish