Hi All, Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ... The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing the

Hi, There are two major issues in passing virtual address of string: 1) A rogue supervisor software can pass a virtual address mapped to a physical address not accessible to it. 2) To access a string

For SBI spec, we have avoided separate function signatures for RV32 and RV64 so better to prefer other options. If we want to combine "addr_lo" and "addr_hi" into one parameter then uint64_t is better

<heinrich.schuchardt@...> wrote: Okay, I will update the text. Yes, the accessibility check on physical address parameters is very important for SBI implementation (M-mode firmware, Hypervis

Hi All, Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ... The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing the

Hi All, To support native debugging in S-mode and VS-mode, we need a SBI Debug Trigger extension which complements the Sdtrig extension. Below is the draft proposal of the SBI Debug Trigger Extension.

Hi Aaron, Few comments below ... Rather than gating these ACPI ECR efforts on AIA spec being frozen. We should start sending out incremental ECRs for the things that are already ratified. Each ECR wil

The term "domain" is not used in the proposal since it is OpenSBI specific. My comment was mainly for Heinrich since he is already aware of OpenSBI domains. In general, other M-mode firmwares might al

The term "supervisor-mode" over here means: * HS-mode or VS-mode on systems with H-extension * S-mode on systems without H-extension (Please see the introduction chapter of SBI specification) In fact,

Hi All, Based on feedback, below is the updated draft proposal of the SBI Debug Console Extension ... The motivations behind this proposal is as follows: 1) There is no new SBI extension replacing the

Hi Stefano, <stefano.stabellini@...> wrote: We have legacy SBI v0.1 calls where most of them are replaced by newer SBI v0.2 (or higher) calls. Only the SBI v0.1 putchar() does not have a replac

We have a requirement in the OS-A platform spec to mandate a particular type of UART for early prints but there were objections on selecting one type of UART over another. This SBI debug console exten

My understanding is that different TGs or SIGs will propose their own SBI extensions. Once a set of changes for next SBI spec release are finalized, the SBI TG can collect all new SBI extensions and p

The legacy SBI v0.1 putchar() and getchar() are byte-level send/receive calls. This is very slow for virtualized world particularly KVM RISC-V because each SBI v0.1 putchar() or getchar() will trap to

<heinrich.schuchardt@...> wrote: The shared memory area in case of this SBI extension will be shared across all HARTs so the SBI implementation will ensure atomicity in setting/reading share

The memory type should be 0 (i.e. PMA) for the shared memory between SBI implementation and supervisor software. Before MMU setup, the memory type is by default 0 (i.e. PMA) so we don't have to mandat

Clearly, if we have a separate SBI extension to manage shared memory then we will end-up with such memory management calls. Memory allocators are generally hard to get it right and this also adds lot

Heinrich has a similar suggestion so please see my response to his comment. Regards, Anup

You can easily create multiple pre-populated strings using ".asciiz" in assembly sources. Just set the base address of pre-populated strings once on boot hart and print from anywhere using usual 4-5 i

<heinrich.schuchardt@...> wrote: Usually, the serial port related code in M-mode firmware only uses status and data registers so for most serial ports support the M-mode firmware will adapt