I'm cc'ing Tim Newsome and Paul Donahue (chairs of the Debug TG). Tim or Paul can comment on the debug value in sometimes being able to stop the local hart time CSR from advancing while in Debug

Just fwiw, most multi-hart RV implementations have a shared MTIME register. (CLINT, for example, reflects this.) I'll resend the original question to both chairs of the Debug TG so they can comment

Greg HI I agree architecturally there is just memory-mapped MTIME. We can leave it at that. What I meant by clock was where a each hart has its unique memory mapped MTIME and thereby is clocked by a

Architecturally there is just the memory-mapped MTIME register and the time CSRs - where time is a (delayed) copy of MTIME. How MTIME values get into the time CSRs is implementation-specific (with

So there is an assumption here that somehow time is broadcast and not the clock. For an implementation that does clock broadcast this requirement requires having a shadow time that counts while

And also re-sync'ing when coming out of deeper power management sleep states. The mechanism for software reading mtime is memory-mapped register reads; ditto for trap-and-emulate of hardware reads of

What you describe sounds very implementation dependent; I had always imagined that mtime would not be broadcast, but an mtime count enable bit would be, to keep the local copy synched. That has its

<ksankaran@...> wrote: Not sure why these are not rendered correctly in gmail. The deleted text seems to be garbage as well which indicates a rendering issue in gmail. Please make sure

I'm cc'ing Paul Donahue (vice-chair of the Debug TG). He was involved with distilling out of the enormous amount of optionality in the Debug spec, what would be suitable to require in OS-A platforms.

Thanks, I definitely misunderstood the intent. So the expectation is that, in Debug Mode, reads to mtime will see time continue to progress, but reads to the time CSR will see a frozen value. Reads

Oops, it has been a while since I've read this spec. I withdraw my comment, if it's indeed the case that shared implementations of mtime need not be affected by stoptime.

I think there's a little bit of confusion going on. The 'stoptime' bit is defined as "Don’t increment any hart-local timers while inDebug Mode." I take this to clearly not be referring to MTIME,

FWIW, although I appreciate the motivation behind this requirement, I also support removing it. For the case that mtime is centrally implemented, this requirement is quite onerous to implement. For

Hi there, In the OS-A platform spec I see the following requirement: • dcsr.stopcount and dcsr.stoptime must be supported and the reset value of each must be 1 The rationale justifies the

Greg HI - Thanks. I think this is very clear. I think the recommendation could be changed to require MSI and make supporting INTx emulation optional. I am hoping to hear from BIOS and OS experts if

As per the discussion and agreement during the Platform HSC meeting, this patch splits the content of the platform spec into 3 different sections - an OS-A Common Requirements section, OS-A Embedded

The following two items in Ved's email didn't get any response, so I offer my own below ... I think where this came from is learnings in the ARM "server" ecosystem (as then got captured in SBSA). In

Yes, fine by me. We can make the changes you have suggested above and leave the remaining content as is. -- Regards Kumar

Kumar & Greg, If the content is worthwhile, please consider putting it in an informative section. Content, such as discussed, might either become an (inline) application note—or go into a separate

So we could drop these statements: " - Main memory must be protected with SECDED-ECC. - All cache structures must be protected. - single-bit errors must be detected and corrected. - multi-bit