Re: Watchdog timer per hart?
toggle quoted messageShow quoted text
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 an interrupt (as opposed to a HW reset)
-- maskable or non-maskable?
-- Using xTVEC to vector or a platform defined vector.? (e.g. the reset vector)
-- A new cause type or reuse an existing one? (e.g.using the reset cause)
-- restartable or non-restartable or both? (both implies - to me at least- the 2 stage watchdog concept, "pulling the emergency cord")
If the watchdog timer is restartable, either it must
--- be maskable, or
--- implement something like the restartable-NMI spec to be able to save state.
-- what does "pulling the emergency cord" do? e.g.
--- some kind of HW reset (we had a light reset at Intel that cleared as little as possible so that a post-mortem dump could identify what was going on)
--- just vector to a SW handler (obviously this should depend on why the watchdog timer was activated, e.g. waiting for a HW event or SW event)
On Wed, Mar 2, 2022 at 12:41 PM Kumar Sankaran <ksankaran@...> wrote:
From a platform standpoint, the intent was to have a single platform