Currently this function is just a nop(). It is not needed in this revision of the extension. The function might be called repeatedly by different threads with different values. How do you want to

Am Donnerstag, 2. Juni 2022, 10:47:58 CEST schrieb Anup Patel: ok, sounds like a plan as well :-)

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

<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

There are variety of ways in which supervisor software can use tarea_offset: 1) Use lock to serialize access to shared memory and always use fixed offset (maybe zero) from all HARTs 2) No lock to

Hi Anup, Am Mittwoch, 1. Juni 2022, 18:17:32 CEST schrieb Anup Patel: typo in the "div_by_2" (not 4 like below and in the function itself) ? This will vastly reduce the number of needed ecalls when

Thanks for starting to close this gap. I miss a discussion of the conflicts that can arise if the configuration of the serial console is changed by the caller. Do we need an ecall that closes the

Thanks, it will be nice to drop putchar. What is the motivation for `area_offset`? Will the supervisor use different offsets for different harts? What are the advantages and disadvantages of the

Hi All, Below is the draft proposal for SBI Debug Console Extension. Please review it and provide feedback. Thanks, Anup Debug Console Extension (EID #0x4442434E

Hi All, My apologies for the long email up front. I hope people find this useful as well as a starting point for a broader discussion in how all these pieces fit together within RISC-V. There are

All, As per the policy governing chairs and vice chairs, we are holding a call for candidates for the positions of CHAIR and VICE-CHAIR for the OS-A SEE TG. To nominate yourself or another member of

Hi All, I am pleased to inform that 45 days of public review period has ended for the RISC-V UEFI Protocol Spec. Feedbacks during review period are addressed. We will go through the remaining

Hi All, I'm cross posting to tech-unixplatformspec@ and tech-os-a-see@ lists because there wasn't sufficient overlap in membership to get the proper visibility. I had proposed a charter that can be

I wouldn't say there was true convergence on a near-final hardware WDT spec. To start with there have also been arguments to abstract any hardware away from what S/HS-mode sees and to instead have an

Several modifications to the WDT spec were proposed, and seemingly agreed in this discussion thread. Is there any plan to actually update the spec? Should I try to learn enough git-foo to generate a

Both of those sound reasonable to me. I didn't modify the charter yet as I'd like to hear from others on this list w/ their opinion. I can make the change as required subsequently. I adjusted the

I haven't been following the H extension closely, and was not aware the HBI/HEE terms have suffered the same fate. This is one of those things that makes it hard to convince people to take RISC-V

Add requirement for preserving the PCIe ID routing as described in issue: https://github.com/riscv/riscv-platform-specs/issues/81 Signed-off-by: Mayuresh Chitale <mchitale@...> ---

Currently the SBI specification defines how to hand device-trees from the SEE to the S-mode firmware. In the context of Trusted Firmware A a document has been developed describing what a more generic