Debug Video Call March 15 : NOTE US TIME CHANGE
64 views
Skip to first unread message
Megan Wachs
Mar 15, 2017, 8:38:51 AM3/15/17
to RISC-V Debug Group
Here are slides for today's call at 8am PST. Note that in the US we've moved our clocks forward one hour, so depending on your location the call may be an hour earlier.
--
https://docs.google.com/presentation/d/1VsKJoSRIClrip-7HonvrBY9N0h2yoTFthKMrZiGbi0E/edit?usp=sharing
Megan
Megan A. Wachs
Engineer | SiFive, Inc
300 Brannan St, Suite 403
San Francisco, CA 94107
Alex Bradbury
Mar 15, 2017, 8:47:16 AM3/15/17
to Megan Wachs, RISC-V Debug Group
On 15 March 2017 at 12:38, Megan Wachs <me...@sifive.com> wrote:
> Here are slides for today's call at 8am PST. Note that in the US we've moved
> our clocks forward one hour, so depending on your location the call may be
> an hour earlier.
Do you mean 8am PDT? For the sake of avoiding confusion, the call will
> Here are slides for today's call at 8am PST. Note that in the US we've moved
> our clocks forward one hour, so depending on your location the call may be
> an hour earlier.
start in how many hours time? :)
Best,
Alex
Megan Wachs
Mar 15, 2017, 10:01:47 AM3/15/17
to Alex Bradbury, RISC-V Debug Group
Sorry. In 1 hour from now.
Megan
Megan Wachs
Mar 15, 2017, 10:54:20 AM3/15/17
to Alex Bradbury, RISC-V Debug Group
And here is the link to the call that starts in 5 minutes:
Alex Bradbury
Mar 15, 2017, 1:58:34 PM3/15/17
to Megan Wachs, RISC-V Debug Group
Notes from the call:
## General
* Remember to check the Git repo for changes, make pull requests for changes
etc
## Enumeration and probing
* Enumeration and probing
* See google doc
<https://docs.google.com/document/d/1HwfJcQj1V1OeB2ECA16rNtEp3Hg3ZfDTuzpcCfZTnxM/edit?usp=sharing>
* Megan has resolved a number of things there since last week (e.g. config
string)
* Do we need to account for the fact the dpc might be clobbered when
running. Can we just make it so dpc won't be clobbered when executing
program buffers?
* See discussion on the mailing list about config string, Megan
talks through an example from current Rocket
* Does the example solve the problem Alex raised on the mailing
list? (hartid <-> hart array mapping). It
does for rocket, might need something more general
* Does the config string list the hartid? Need to check
## Implementation disucssion
* Palmer on spike/openocd: currently trying to finish off Tim's work on
spike and openocd, get it matching the hardware implementation. Finds the
spec is hard to read, and many things are optional making it unclear what
parts are available to you. It's also not easy to determine what needs to be
implemented for debuggers to work with your hardware
* Suggest adding an appendix to describe one particular implementation
approach
* Are there other implementations that aren't based on Rocket? Sober posting
on the mailing list posted about their's
* Gaj: it's painful for tools vendors if there are too many options for
implementers.
* Want to make it clear in the spec what needs to be implemented to be
'compatible'
* May be worth reaching out to Richard, Pulpino team
* For Rocket, Megan implemented base GPR abstract commands, with everything
else handled with the program buffer
* Pre-exec bit added a lot of complexity, suggest removing it due to the
implementation complexity
* Currently have data registers and program registers, but can't really
share them. If you just had one set of registers, it is cheaper. Like the
idea where you could have zero data registers and just have program buffer
registers
* Alex: if we make this change, we should be very explicit about the
changed interpretation and rather than having this as yet another option
* Alex: these are debug module-level registers rather than per-hart right?
Answer: Yes
* Gaj: can you get a case where you're in program mode would would want to
use the data registers?
* Megan: 32-bit command register seems a high overhead (very few commands
will be supported on a given implementation).
* Alex: isn't this a premature optimisation?
* Palmer: OpenOCD has been focusing on the program buffer style of
implementation. GPR access is currently handled using abstract commands,
but was unsure if these are always there according to the spec.
* Thought it was meant to be that GPR access is always there, program
buffer may or may not be, may or may not be able to access CSRs via
abstract commands
* Megan: Instruction buffer is the hard thing, if you have abstract
commands then doing the things you can do with them is easy. But you're
limited in what you can do with them.
* Alex: can we remove some other things that are currently optional? e.g.
whether data registers are in CSR vs memory mapped
* Palmer: our openocd port has to support the older version of the debug
spec as well.
* Gaj: many tools that are not your classic debugger, e.g. profiler will
be using the baseline GPR access
* Gaj: want to use abstract commands to acess state without halting the
hart, and will want openocd support for that.
* Megan: anyone who is willing should write up the minimum things out of the
options they would expect to either implement in hardware, or see from a
debugger
## MIPI
* See notes from Megan in slides
<https://docs.google.com/presentation/d/1VsKJoSRIClrip-7HonvrBY9N0h2yoTFthKMrZiGbi0E/edit?usp=sharing>
## General
* Remember to check the Git repo for changes, make pull requests for changes
etc
## Enumeration and probing
* Enumeration and probing
* See google doc
<https://docs.google.com/document/d/1HwfJcQj1V1OeB2ECA16rNtEp3Hg3ZfDTuzpcCfZTnxM/edit?usp=sharing>
* Megan has resolved a number of things there since last week (e.g. config
string)
* Do we need to account for the fact the dpc might be clobbered when
running. Can we just make it so dpc won't be clobbered when executing
program buffers?
* See discussion on the mailing list about config string, Megan
talks through an example from current Rocket
* Does the example solve the problem Alex raised on the mailing
list? (hartid <-> hart array mapping). It
does for rocket, might need something more general
* Does the config string list the hartid? Need to check
## Implementation disucssion
* Palmer on spike/openocd: currently trying to finish off Tim's work on
spike and openocd, get it matching the hardware implementation. Finds the
spec is hard to read, and many things are optional making it unclear what
parts are available to you. It's also not easy to determine what needs to be
implemented for debuggers to work with your hardware
* Suggest adding an appendix to describe one particular implementation
approach
* Are there other implementations that aren't based on Rocket? Sober posting
on the mailing list posted about their's
* Gaj: it's painful for tools vendors if there are too many options for
implementers.
* Want to make it clear in the spec what needs to be implemented to be
'compatible'
* May be worth reaching out to Richard, Pulpino team
* For Rocket, Megan implemented base GPR abstract commands, with everything
else handled with the program buffer
* Pre-exec bit added a lot of complexity, suggest removing it due to the
implementation complexity
* Currently have data registers and program registers, but can't really
share them. If you just had one set of registers, it is cheaper. Like the
idea where you could have zero data registers and just have program buffer
registers
* Alex: if we make this change, we should be very explicit about the
changed interpretation and rather than having this as yet another option
* Alex: these are debug module-level registers rather than per-hart right?
Answer: Yes
* Gaj: can you get a case where you're in program mode would would want to
use the data registers?
* Megan: 32-bit command register seems a high overhead (very few commands
will be supported on a given implementation).
* Alex: isn't this a premature optimisation?
* Palmer: OpenOCD has been focusing on the program buffer style of
implementation. GPR access is currently handled using abstract commands,
but was unsure if these are always there according to the spec.
* Thought it was meant to be that GPR access is always there, program
buffer may or may not be, may or may not be able to access CSRs via
abstract commands
* Megan: Instruction buffer is the hard thing, if you have abstract
commands then doing the things you can do with them is easy. But you're
limited in what you can do with them.
* Alex: can we remove some other things that are currently optional? e.g.
whether data registers are in CSR vs memory mapped
* Palmer: our openocd port has to support the older version of the debug
spec as well.
* Gaj: many tools that are not your classic debugger, e.g. profiler will
be using the baseline GPR access
* Gaj: want to use abstract commands to acess state without halting the
hart, and will want openocd support for that.
* Megan: anyone who is willing should write up the minimum things out of the
options they would expect to either implement in hardware, or see from a
debugger
## MIPI
* See notes from Megan in slides
<https://docs.google.com/presentation/d/1VsKJoSRIClrip-7HonvrBY9N0h2yoTFthKMrZiGbi0E/edit?usp=sharing>
Don A. Bailey
Mar 15, 2017, 2:11:59 PM3/15/17
to Alex Bradbury, Megan Wachs, RISC-V Debug Group
Quick update on the security side: sorry I couldn't make today's call; client requested a last minute meeting. But! Good news abounds.
- Spoke with the OpenOCD lead; the serial model for debug auth is OK
- They suggested two models that are being added to OpenOCD: RTT and another
- I had a serial model pinned up, but took a step back to review the suggested models
- Don't think the suggested models fit, but learned a bit about what OpenOCD "needs" from an abstraction perspective
Updated spec coming shortly as a result. I'm in meetings for the rest of today, so by Friday afternoon is realistic.
Best,
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CA%2BwH2949XKYomWeTU-VJ30YJqJ5FqG6GEMOL%2BfSaubrfx0q6Wg%40mail.gmail.com.--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
Megan Wachs
Mar 17, 2017, 11:47:48 AM3/17/17
to Alex Bradbury, RISC-V Debug Group
Thanks Alex!
Megan Wachs
Mar 17, 2017, 11:49:06 AM3/17/17
to Don A. Bailey, Alex Bradbury, RISC-V Debug Group
Thanks for talking to the OpenOCD folks Don. What exactly is RTT? Can you send a link?
Thanks!
Megan
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CA%2BwH2949XKYomWeTU-VJ30YJqJ5FqG6GEMOL%2BfSaubrfx0q6Wg%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages