tech-unixplatformspec@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

It works fine, but it's not as nice as the system itself slowing down to your debugging speed. (Although slowing the system down will generally be imperfect in any case, because systems have other

By Tim Newsome · #1617 ·

Re: OS-A platform stoptime requirement

Are there downsides to the debugger inhibiting the timer interrupt by setting STIE to 0? This seems like would provide similar benefit even for a multi-hart system... regards ved

By Ved Shanbhogue · #1616 ·

Re: OS-A platform stoptime requirement

stoptime is nice on single-hart systems, but not really practical in multi-hart systems where one hart can be running while another is halted. The main benefit is that it allows you to single step

By Tim Newsome · #1615 ·

Re: Platform specification questions

Hi Ved, Are we ready to finalize the changes after all the comments and discussions on the list of questions you had on this thread? If yes, can you send a PR for these changes please? I see the PCIe

By Kumar Sankaran · #1614 ·

Re: SBI: We can fast handle some SBI functions for extreme performance in assembly code implementation if SBI extension‘s FID equals to zero

This is platform specific address and it will break for platforms having MTIME register at some other address. Such optimizations, increasingly make a SBI implementation platform specific. This is

By Anup Patel · #1613 ·

SBI: We can fast handle some SBI functions for extreme performance in assembly code implementation if SBI extension‘s FID equals to zero

RISC-V SBI provides platform agnostic functions for kernels. The nomal handling procedure in an SBI implementation would include context switch and call higher language code, e.g. Rust or C code.

By 洛佳 Luo Jia · #1612 · Edited

Re: OS-A platform stoptime requirement

I agree that the stoptime=1 requirement should be removed. I can think of a case where stoptime might be useful but it would be a contrived example that's not useful in the real world. I should have

By Paul Donahue · #1611 ·

Re: OS-A platform stoptime requirement

Btw, that would be a DRET to exit Debug mode (not an MRET). Greg

By Greg Favor · #1610 ·

Re: OS-A platform stoptime requirement

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

By Greg Favor · #1609 ·

Re: OS-A platform stoptime requirement

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

By Greg Favor · #1608 ·

Re: OS-A platform stoptime requirement

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

By Ved Shanbhogue · #1607 ·

Re: OS-A platform stoptime requirement

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

By Greg Favor · #1606 ·

Re: OS-A platform stoptime requirement

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

By Ved Shanbhogue · #1605 ·

Re: OS-A platform stoptime requirement

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

By Greg Favor · #1604 ·

Re: OS-A platform stoptime requirement

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

By Allen Baum · #1603 ·

Re: [PATCH 1/1] Platform Spec Content Reorganization into separate sections

<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

By atishp@... · #1602 ·

Re: OS-A platform stoptime requirement

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.

By Greg Favor · #1601 ·

Re: OS-A platform stoptime requirement

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

By Beeman Strong · #1600 ·

Re: OS-A platform stoptime requirement

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.

By andrew@... · #1599 ·

Re: OS-A platform stoptime requirement

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,

By Greg Favor · #1598 ·

241 - 260 of 1857

Home Hashtags Subgroups Terms