video call, week of Jan 23
Tim Newsome
Tim Newsome
Tim Newsome
Tim Newsome
Megan Wachs
Notes from Debug WG Call Jan 25
New People: Po Wei. Student at University in Computer Architecture. Mostly for security, using RISC-V as their platform. Individual Member
Benjamin — Proteus Technologies in Bangkok. Interested in Chisel, developing CPUs, the RISC-V environment in general. (Actually joined in the past)
Timeline — now let’s get a spec together that we think works.
Poll results — going to make a spec with both options. We can discuss later once we know the details of the two approaches whether both need to be required.
Latest spec is on github. Tim has started adding an abstract interface. Please read it, look at it, comment, etc. The idea is to have a common thing to work on, vs a bunch of slides, PDFs, emails that make it hard to track what we are working on.
Doing work under SiFive’s github isn’t ideal, are there better options? No better suggestions for now.
Debug Bus — Tim would like the debug bus to be a always 32-bits wide. In the past it may have been assumed that i was XLEN bits wide.
Megan — a read-and-write bus would make sense with JTAG.
Tim — But most buses don’t have read and write.
Krste — that can be folded into the Debug Transport Module— it can decide to do a read and write at once given that it knows what is hooked up to.
Rex — clarify why does it need to be 32-bits wide? Is it an OpenOCD requirement?
Tim — No, there is transfer of data between debug module and debugger. Say a 64-bit wide register, is it 2 32-bit wide registers or one 64-bit wide register?
Rex — it would be nice if the Debug Module is generic.
Cyril — what if we have 32 and 64-bit cores in an SoC.
Tim — exactly, don’t want to have to redo the debug bus or debug module when we add new cores. But Rex’s point is can we get away not specifying it?
Rex — is it a programming model requirement? Why do we have to specify this?
Tim — we have to specify how wide registers are in the debug module. If you want to ignore the bus width, you still have to say how wide is the register that you’re reading from the debug module. Maybe a different way of saying is that every Debug Module register is 32-bits wide, regardless of XLEN.
Krste — I think you’re really specifying that atomic operations are 32-bit reads and writes. Not so much the bus width.
Vyacheslav — specify a debug module “DLEN”, which may or may not be XLEN. But all our specification could be expressed in terms of DLEN.
Tim — good point, I thought about doing something like that, but I think it’s going to make more work on the debugger to be aware of these options, and I don’t see the benefit.
Tim — so in conclusion, instead of specifying the bus, the registers are all 32-bits wide?
Krste — the transport module could do some optimizations if you want.
Larry — I agree standardizing on 32 bits is fine, as Stefan said too.
Tim — OK, can conclude this on the mailing list.
Rex — quick question… the DPC and the DSCRATCH are XLEN. So is it going to be possible to read those? Or just DSTATUS which is 32-bits.
Tim — in general a hart will have many XLEN registers. If you want to read the value of a CSR, you would end up reading several 32-bit registers from the Debug Module.
Rex — are they dynamic? Are they going to change as we’re reading them?
Tim — that depends on your implementation. Wait, no. There is an operation that transfers the contents to a register in a Debug Module. So when you’re reading them from the Debug Module they would be static.
Megan — clarification, this applies for both the Abstract and Instruction Fetch interface
Tim — yes.
Rex — this is really the transaction width as received by the Debug Module from the Transport Layer block.
Tim — yes SDBUS is nominally 32 bits.
Rex — this will make OpenOCD simpler and more standard…? What’s the advantage.
Tim — yes. And it makes it easier to build reusable parts. If you always know SDBUS is 32-bits, then the DTM only needs to work with that interface. System Debug Module doesn’t need to be variable width on that side. The software also gets simpler.
Rex — shouldn’t it be XLEN?
Tim — what if I have disparate cores?
Rex — oh, I see it’s one debug module for the system.
Vyacheslav — I think we should rename “Core Debug Unit” to “Hart Debug Unit.”
Tim - OK
Rex — will think about it more, but let’s move on.
Krste — if you design the debug module to have some action performed on a write, you want to enable a bus that is only 32 bits wide to do the right thing. So if you have two halves, we need to define when the side effects occur. You could support the interface being 32 bits with a 64-bit XLEN. That’s why we are specifying it really.
Rex — can the debug module debug multiple harts simultaneously?
Tim — yes, well, timeshared
Rex — but I know the XLEN of each hart. So what is the benefit?
Krste — you can hide that. But we want to support this being a standard bus that is only 32 bit accesses. The transport can hide it and support 64bit accesses if you know what’s you need. But the SDBUS only *needs* to be 32 bit units of transfer. You can abstract it away.
Tim — its important that it works at 32 bit bus. We shouldn’t require a 64-bit bus for SDBUS.
Rex will respond to mailing list after talking to some coworkers.
Instruction Supply —
When we want the core to execute instructions, they should be fetching them from somewhere.
The confusion is it from RAM or from the Debug Module?
Tim — in my mind, the core can’t tell the difference. There are reasons why I like having instructions in the Debug Module: It’s definitely going to be there (don’t have to worry about program code messing it up).
Two reasons that arbitrary RAM location will run the user into trouble.
- how to get this RAM configured right? Could fall apart.
- If user put part of the program in the same region that the debugger is using.
Ok let’s establish the important properties of Debug RAM, wherever it is:
- Krste — Not accessible to regular program
- Rex — agree not accessible to the regular program
- Yunsup — you can share the same SRAM macro, but have access controls on different regions
- It exists
- It is accessible “right out of reset” (later clarified to mean before hart fetches first instruction out of reset)
- Hart has to be able to fetch instructions from it (“System Bus Slave” is just an example implementation)
Cyril — important question. Is that RAM always at the same address? That the hart is always going to fetch the instruction from?
Krste — we wanted it at low addresses because it is lower overhead for save and restore. If we allow it to be anywhere, the debugger has to execute more instructions
Tim — Two considerations. 1) where are the instructions? It doesn’t matter too much. 2) How does data get from the Hart into Debug Module. Being able to do a store relative to x0 is more efficient than generic address. You could make it a magic CSR that writes to the appropriate address. But it would be cleaner that it’s always this address that is relative to x0.
Proposal from mailing list — Instruction can jump to anywhere. Like the other interrupt vector registers?
Tim — don’t see why the address should be writable.
Krste — wherever the RAM is, It should not be accessible normally by the program. The whole point of debugger is that the stuff you’re debugging is broken.
Cyril — those RAMs should only be writable from the system debug bus interface, not the system.
Krste — at 0x800 you can spread the Harts about and they each have their own address in that range.
Megan — OpenOCD/similar should assume that it can’t change the debug vector. If an implementer decides to make it writable, there is no reason they can’t except they can shoot themselves in the foot with that.
No one knows a good reason we’d want to change the debug vector at runtime.
Vyacheslav — Want to say something in support of “direct” supply (vs fetching). Don’t forget about MMU and memory address translation. This sort of stuff as far as instruction supplying is used for hart architectural state. It could be annoying part of every such state to tune the access of instruction fetching.
Tim — right now, the spec says in debug mode address translation is turned off (for the reasons that you mentioned). Everyone on the mailing list said they didn’t want direct instructions because its invasive to the CPU, hard to verify, etc. Do you really want to put instructions directly into the hart that isn’t fetched from somewhere?
Vyacheslav — some register or small memory is a source of instruction fetching directly to hart, bypassing all memory hierarchy.
Statements about debug state should be discussed further… ?
Tim — Right, debug mode is not officially in any RISC-V documents. Yes, we need to clarify exactly what is “debug mode”.
Krste — Address translation happens in the core and it can be turned off, and caching wouldn’t play a role when fetching from the debug RAM. In most systems it would be uncached ifetch from the debug module. No translation, no caching going on. Core is just fetching uncached.
Rex — agree. You want to depend on the least amount of hardware and software while debugging. It’s also our expectation.
Cyril — clarification for Krste — we do instruction fetching. Do we expect the memory translation will not be active while in debug mode? Whatever instruction is executing on the hart will be happening without memory translation?
Krste — yes
Rex — ok clarification. The translation happens within the core?
Tim — it’s what I said but I’m not an expert
Krste — there are just machine physical addresses to access the debug RAM.
Yunsup — on Tim's diagram, why is Trigger connected to the system bus?
Tim — maybe for cross-triggering. Future specification.
Discussion about the diagram.
Rex — I don’t like the name "System Bus" because it feels very specific to the design we’ve implemented. System Bus feels like something that makes sense on some small SoC. In other designs, one of those components could be a large number of cores.
Tim — does it make sense to have one of your components be one of these things (as shown in the diagram)? A debug module for one of the components and all the cores.
Rex — if we share the debug module across all the different cores, you have to have some kind of communication bus, otherwise we can’t share the debug module. That is very much an implementation detail.
Tim — I keep saying “system bus” because people understand it. If I say “hart debug bus” people don’t get it.
Krste — it should be something the hart can fetch instructions from. It doesn’t have to be a global system bus, or whatever, but it has to be something the hart can fetch from.
Megan — Question about instruction fetching. Debugger supplies some instructions, but what things are assumed to happen “magically” (e.g. what used to happen in Debug ROM).
Rex — can we just put in the RAM what was already in the ROM? Why does it matter?
Tim — the difference is what happens when you halt. Megan & Tim to discuss after the call.
Rex — I can use bus master while the core is halted, right?
Tim — yes.
Rex — Our expectation is that we can just have RAM where we had ROM specified before. But that seems like an implementation detail?
Tim — it might be an implementation detail. I’ve been moving away from the ROM a bit because people hate it.
Rex — I agree.
Rex — one more clarification… "RAM is accessible out of reset”. What does that mean
Tim — you want to halt the processor before the processor’s reset is deserted. So yes there is a more precise definition: The RAM has to to be ready to go before reset is deserted when debug is asserted.
Cyril — did we discuss reset control?
Tim — It’s in the spec but no one has talked about it except Megan who says it’s too confusing. Cyril will read the current spec to see if it makes sense to him.
We all agree that it’s important to debug out of reset.
Conclusions —
System Debug Bus: Mostly OK but finish discussion on the mailing list.
Instruction supply — clarified a bunch of things.
AIs
- pick next week’s meeting date.
Rex — can we just pick a regular day for the rest of our lives?
Tim — wednesday?
Wednesday crew agrees on Wednesday!
- Continue discussion on mailing list
- read/ comment on spec on GitHub
--
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/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAGDihe%3DMKoLGmp_Lu4VGqz-NZsa8VWY1%3DKnFozMV4ZqXh6CfLw%40mail.gmail.com.
Alex Bradbury
> Notes from Debug WG Call Jan 25
meeting so they are especially useful for me this time round!
> New People: Po Wei. Student at University in Computer Architecture. Mostly
> for security, using RISC-V as their platform. Individual Member
>
> Benjamin — Proteus Technologies in Bangkok. Interested in Chisel, developing
> CPUs, the RISC-V environment in general. (Actually joined in the past)
>
> Timeline — now let’s get a spec together that we think works.
>
> Poll results — going to make a spec with both options. We can discuss later
> once we know the details of the two approaches whether both need to be
> required.
>
> Latest spec is on github. Tim has started adding an abstract interface.
> Please read it, look at it, comment, etc. The idea is to have a common thing
> to work on, vs a bunch of slides, PDFs, emails that make it hard to track
> what we are working on.
>
> Doing work under SiFive’s github isn’t ideal, are there better options? No
> better suggestions for now.
GitHub in general, then I don't have good suggestions. If the question
was about which repository specification development should take
place, I'll note we can easily get Andrew or one of the Berkeley folks
to create a new repository in the riscv GitHub organisation. In fact,
the debug taskgroup already has one - you might remember that before
Christmas I created a publicly available listing of proposed
specifications and meeting minutes etc
(https://riscv.github.io/debug-taskgroup/). So we could have something
like github.com/riscv/debug-draft-spec or else just make use of the
existing https://github.com/riscv/debug-taskgroup repo.
Best,
Alex
Tim Newsome
On 25 January 2017 at 19:01, Megan Wachs <me...@sifive.com> wrote:
> Notes from Debug WG Call Jan 25
Megan - thank you as always for the notes. I couldn't make today's
meeting so they are especially useful for me this time round!
> Latest spec is on github. Tim has started adding an abstract interface.
> Please read it, look at it, comment, etc. The idea is to have a common thing
> to work on, vs a bunch of slides, PDFs, emails that make it hard to track
> what we are working on.
>
> Doing work under SiFive’s github isn’t ideal, are there better options? No
> better suggestions for now.
Obviously I wasn't there so missed the issue with GitHub. If it's
GitHub in general, then I don't have good suggestions. If the question
was about which repository specification development should take
place, I'll note we can easily get Andrew or one of the Berkeley folks
to create a new repository in the riscv GitHub organisation. In fact,
the debug taskgroup already has one - you might remember that before
Christmas I created a publicly available listing of proposed
specifications and meeting minutes etc
(https://riscv.github.io/debug-taskgroup/). So we could have something
like github.com/riscv/debug-draft-spec or else just make use of the
existing https://github.com/riscv/debug-taskgroup repo.
Sober Liu
Currently in our implementable, instructions for debug are passed to decoder unit directly from debug module.
Debug module need to understand cmd from debugger, so it not hard to map 1-2 insn for feeding.
--
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+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/CAGDihemg_b2HG7RbKtz4GdqE17CW4%3DxkZC%3DjNSgjGwVRzfX1uA%40mail.gmail.com.
Tim Newsome
Currently in our implementable, instructions for debug are passed to decoder unit directly from debug module.
Debug module need to understand cmd from debugger, so it not hard to map 1-2 insn for feeding.
Stefan Wallentowitz
On 25.01.2017 20:01, Megan Wachs wrote:
> Krste — wherever the RAM is, It should not be accessible normally by the
> program. The whole point of debugger is that the stuff you’re debugging
> is broken.
>
> Cyril — those RAMs should only be writable from the system debug bus
> interface, not the system.
would people implement a physical protection?
Don't get me wrong, I just think we should have a discussion about
protection to reduce "debug accidents" and also as a security measure
(like good old privilege escalation via DMA). It can on the other hand
be seen as burden to simple micrcontrollers with M-mode only, I could
imagine.
Cheers,
Stefan
kr...@berkeley.edu
>>>>> On Fri, 27 Jan 2017 11:22:24 +0100, Stefan Wallentowitz <ste...@wallentowitz.de> said:
| Hi all,
| On 25.01.2017 20:01, Megan Wachs wrote:
|| Krste — wherever the RAM is, It should not be accessible normally by the
|| program. The whole point of debugger is that the stuff you’re debugging
|| is broken.
||
|| Cyril — those RAMs should only be writable from the system debug bus
|| interface, not the system.
| Is there a consensus on that? How would that align with the spec?
| How would people implement a physical protection?
least ignore writes to the space.
| Don't get me wrong, I just think we should have a discussion about
| protection to reduce "debug accidents" and also as a security measure
| (like good old privilege escalation via DMA).
| It can on the other hand
| be seen as burden to simple micrcontrollers with M-mode only, I could
| imagine.
debug at all, and let embedded software developers blink LEDs to
debug, or require they use emulators.
If you place the debug RAM in address space appropriately, it only
costs a few gates, or a small %age of what the rest of the debug
circuitry will cost you.
In other words, if you're prepared to implement debug harwdare,
protecting some portion of address space from stray application writes
is not an expensive addition.
Krste
| Cheers,
| Stefan
| --
| You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
| Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
Stefan Wallentowitz
> | Don't get me wrong, I just think we should have a discussion about
> | protection to reduce "debug accidents" and also as a security measure
> | (like good old privilege escalation via DMA).
>
> | It can on the other hand
> | be seen as burden to simple micrcontrollers with M-mode only, I could
> | imagine.
>
> If you're really worried about marginal cost, you don't implement
> debug at all, and let embedded software developers blink LEDs to
> debug, or require they use emulators.
> If you place the debug RAM in address space appropriately, it only
> costs a few gates, or a small %age of what the rest of the debug
> circuitry will cost you.
>
> In other words, if you're prepared to implement debug harwdare,
> protecting some portion of address space from stray application writes
> is not an expensive addition.
necessary and if any particular implementation should be mandated. I am
pro both.
Cheers,
Stefan
kr...@berkeley.edu
>>>>> On Fri, 27 Jan 2017 17:26:08 +0100, Stefan Wallentowitz <ste...@wallentowitz.de> said:
| On 27.01.2017 17:07, kr...@berkeley.edu wrote:
|| | Don't get me wrong, I just think we should have a discussion about
|| | protection to reduce "debug accidents" and also as a security measure
|| | (like good old privilege escalation via DMA).
||
|| | It can on the other hand
|| | be seen as burden to simple micrcontrollers with M-mode only, I could
|| | imagine.
||
|| If you're really worried about marginal cost, you don't implement
|| debug at all, and let embedded software developers blink LEDs to
|| debug, or require they use emulators.
| I personally am not worried at all, just asking.
|| If you place the debug RAM in address space appropriately, it only
|| costs a few gates, or a small %age of what the rest of the debug
|| circuitry will cost you.
||
|| In other words, if you're prepared to implement debug harwdare,
|| protecting some portion of address space from stray application writes
|| is not an expensive addition.
| I am not questioning the cost, more if the requirement is really
| necessary and if any particular implementation should be mandated. I am
| pro both.
security. Much easier than having debugger be defensive against user
code attacks on debugger.
Krste
| Cheers,
| Stefan
| --
| 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+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/.
Richard Herveille
Richard
Sent from my iPad
Michael Clark
0 Instruction address misaligned1 Instruction access fault2 Illegal instruction3 Breakpoint4 Load address misaligned5 Load access fault6 Store/AMO address7 Store/AMO access fault
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/7FBE9BFA-683C-49A6-A8E8-AA986D24F449%40roalogic.com.
Tim Newsome
Would debug mode be able to store into the instruction buffer? or would it would only be allowed via the Debug Bus?
| 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/.
| To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/7123762e-da7c-0e2c-45ed-6cff63ea6ddb%40wallentowitz.de.
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
--
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/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/22667.28728.553132.736540%40dhcp-10-240-112-178.cp.wireless.private.cam.ac.uk.
--
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/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/7FBE9BFA-683C-49A6-A8E8-AA986D24F449%40roalogic.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/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/3B33B019-770F-466B-B754-F5B921B56460%40mac.com.
Michael Clark
On 28 Jan 2017, at 2:02 PM, Tim Newsome <t...@sifive.com> wrote:On Fri, Jan 27, 2017 at 4:46 PM, Michael Clark <michae...@mac.com> wrote:Would debug mode be able to store into the instruction buffer? or would it would only be allowed via the Debug Bus?In the 0.11 spec (which SiFive implemented) that is how data would be transferred between hart and Debug Module.For the latest spec I'm thinking it'll be simpler to require the abstract modify-GPR commands, which half the people want to require anyway. That removes any need for the debugger to know what address the instruction buffer resides at.
Tim Newsome
Tim
| 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/7123762e-da7c-0e2c-45ed-6cff63ea6ddb%40wallentowitz.de.
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
--
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+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/22667.28728.553132.736540%40dhcp-10-240-112-178.cp.wireless.private.cam.ac.uk.
--
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+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/7FBE9BFA-683C-49A6-A8E8-AA986D24F449%40roalogic.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+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/.
Michael Clark
On 28 Jan 2017, at 3:02 PM, Michael Clark <michae...@mac.com> wrote:
On 28 Jan 2017, at 2:02 PM, Tim Newsome <t...@sifive.com> wrote:On Fri, Jan 27, 2017 at 4:46 PM, Michael Clark <michae...@mac.com> wrote:Would debug mode be able to store into the instruction buffer? or would it would only be allowed via the Debug Bus?In the 0.11 spec (which SiFive implemented) that is how data would be transferred between hart and Debug Module.For the latest spec I'm thinking it'll be simpler to require the abstract modify-GPR commands, which half the people want to require anyway. That removes any need for the debugger to know what address the instruction buffer resides at.
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/B58E26B0-BCC1-4E0C-AC8B-80020D00B743%40mac.com.
Tim Newsome
On 28 Jan 2017, at 3:02 PM, Michael Clark <michae...@mac.com> wrote:
On 28 Jan 2017, at 2:02 PM, Tim Newsome <t...@sifive.com> wrote:On Fri, Jan 27, 2017 at 4:46 PM, Michael Clark <michae...@mac.com> wrote:Would debug mode be able to store into the instruction buffer? or would it would only be allowed via the Debug Bus?In the 0.11 spec (which SiFive implemented) that is how data would be transferred between hart and Debug Module.For the latest spec I'm thinking it'll be simpler to require the abstract modify-GPR commands, which half the people want to require anyway. That removes any need for the debugger to know what address the instruction buffer resides at.Oh. This is making more sense now. The host doesn’t need to know the physical address of the debug instruction buffer which could be anywhere in the target address space, as the buffer is exposed as 0-7 or 0-15 (or however many 32-bit words are available in the debug instruction buffer) in the address space over JTAG.
I guess instruction_buffer_size 0 indicates the target only implements the abstract interface, however I had thought that there would be two different code paths in OpenOCD in the bottom half of the host side of the transport, but an upper half exposing the same target description format to the debugger i.e. envisaging the abstract unified interface being unified on the host side in OpenOCD with two bottom halves, one that sends instructions, one that sends commands.
This would be an interpretation of “unified abstract interface” that would support the existing SiFive implementation. i.e. implementing the unified interface on the host-side.
I hope I’m not confusing anyone :-|
Tim
| 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/7123762e-da7c-0e2c-45ed-6cff63ea6ddb%40wallentowitz.de.
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]
--
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+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/22667.28728.553132.736540%40dhcp-10-240-112-178.cp.wireless.private.cam.ac.uk.
--
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+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/7FBE9BFA-683C-49A6-A8E8-AA986D24F449%40roalogic.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+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/3B33B019-770F-466B-B754-F5B921B56460%40mac.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/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/B58E26B0-BCC1-4E0C-AC8B-80020D00B743%40mac.com.
Tim Newsome
I'm working on updating the spec (at https://github.com/sifive/riscv-debug-spec) to incorporate what I've been hearing this week. I should have something to send out on a day or two, that should make it clear what is in the spec and where.