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

Is it expected that there should be a watchdog timer and timeout signal per hart in the system, or is okay for there to be one timer in the system and for the timeout signal to be delivered to a

Hi All, The next platform HSC meeting is scheduled on Wed Feb 23rd 2022 at 9AM PST. This meeting is moved to Wed as Monday Feb 21st is a holiday for President's Day in the US. Here are the

Chris, The Platforms effort is being reorganized and we'll spin up a task group for RVM-CSI (a source-level abstraction framework) up in the near future. RVM-CSI is very much in focus (for the

Chris, I'm cc'ing the chairs of the Software HC and the Platforms HSC. All platform efforts are being re-organized a bit as we speak (compared to thus far one group was trying to address a number of

Hi all, I lead the CPU software / SDK team at Imagination Technologies, we are entering the RISC-V space but I'm still quite new around here. At present we are most interested in embedded applications

nits: %s/RISCV_BOOT_PROTOCOL/RISCV_EFI_BOOT_PROTOCOL/ This new protocol is needed because ACPI cannot make use of the current device-tree based approach to transfer the boot hart ID to the next boot

Hi all! I just sent this to tech-chairs, but due to the nature of your work Stephano suggested getting feedback here as well. The Configuration Structure task group has been working on how software