Hi All, The next platform HSC meeting is scheduled on Mon Apr 4th 2022 at 8AM PST. Here are the details: Agenda and minutes kept on the github

UEFI uses to talk of configuration tables not of firmware tables. Add missing 'the', 'and'. Enhance readability of sentence concerning ExitBootServices(). Signed-off-by: Heinrich Schuchardt

(Resending for RISC-V ISA-DEV and RISC-V SW-DEV because previous email was not received on these lists.)

This is to announce the start of the public review period for the RISC-V UEFI Protocol specification. This specification is considered as frozen now as per the RISC-V International policies. The

Hi All, Due to lack of a full agenda, I am canceling the next platform HSC meeting on Monday Mar 21st 2022. This way, people can use this time to attend other RISC-V meetings. In terms of the

Hi All, I wanted to point out that we have GitHub repositories and a mailing list for OS-A SEE (Supervisor Execution Environment) TG. Please join if you are interested. GitHub Admin:

Hi All, The next platform HSC meeting is scheduled on Mon Mar 7th 2022 at 8AM PST. Here are the details: Agenda and minutes kept on the github

That's a bit looser a definition than I'd expect, but that explains your comments, certainly. Thx.

Since the suitable response to a first or second stage timeout is rather system-specific, ARM didn't try to ordain exactly where the timeout signals go and what happens as a result. In SBSA they just

Don't they even define whether restartability is required or not?

Even ARM SBSA allowed a lot of flexibility as to where the first-stage and second-stage timeout "signals" went (which ultimately then placed the handling in the hands of software somewhere). In other

Now we're starting to drill down appropriately. There is a wide range. This is me thinking out loud and trying desperately to avoid the real work I should be doing: - A watchdog time event can cause

From a platform standpoint, the intent was to have a single platform level watchdog that is shared across the entire platform. This platform watchdog could be the 2-level watchdog as described below

One comment - for when any concrete discussion about having a system-level watchdog occurs: One can have a one-stage or a two-stage watchdog. The former yanks the emergency cord on the system upon

Yes. Greg articulated what I was getting at better than I did. I apologize for muddying the waters. From a platform standpoint one system-level watchdog should suffice as it's typically the last

A core-level watchdog can mean quite different things to different people and their core designs. In some cases this "watchdog" would be a micro-architectural thing that, for example, recognizes that

Hi Aaron, Thanks for the response. Would you be able to give any more details on how a core level watchdog would differ from a platform level one? James

If one is operating the machine with 16 harts without any sharding or partitioning, I don't see why one would need a watchdog per hart. System watchdogs, or TCO timers from other architecture's

Hi Greg, Thanks for your response. I'm not sure if I'm missing something about there being a connection between having a supervisor level watchdog timer and having a timer per hart, but I wasn't

For now (this year) RVI is focusing on standardizing an initial OS-A SEE (Supervisor Execution Environment) and an OS-A Platform standardizing Supervisor and User level functionality, i.e. not