[Open SoC Debug] CDM-OR1K implementation
shorne at gmail.com
Sun May 20 00:24:32 CEST 2018
On Sat, May 19, 2018 at 09:53:45PM +0530, SHIVAM AGGARWAL wrote:
> Thanks for the clarification.
> On Sat, May 19, 2018 at 8:22 PM, Philipp Wagner <philipp.wagner at tum.de>
> > Hi,
> > Am 19.05.2018 um 16:20 schrieb SHIVAM AGGARWAL:
> > > *Register Access*
> > > How do we access the core's general purpose registers and (on
> > > openrisc) SPRs. I just see mappings for the debug registers. Is
> > it
> > > in some other debug module? I thought it should be here.
> > >
> > >
> > > As per my understanding, we will use CDM module to access only the debug
> > > unit using signals defined in the System Interface. All the other
> > > registers can be accessed through MAM (Memory Access Module).
> > No CPU register can be accessed through the MAM module, only the memory
> > (and in fact main memory, not the L1 cache. If the L1 is not
> > write-through more modifications, such as a cache flush, might be
> > needed.) If the currently mapped registers are not able to access the
> > GPRs (and possibly other registers needed by GDB) you need to add those.
> > Shivam, please try to acquire a clear understanding how a debugging
> > process through GDB works to make sure you don't miss significant
> > portions when writing the OSD CDM spec.
> > I read about the debugging process through GDB. I will surely go through
> more resources. I even discussed this with Stafford a while ago.
> OR1K debug unit is used for reading/writing breakpoint/watchpoint addresses
> or data.
> I thought that we can use MAM to access other registers. Sorry for the
> misinterpretation. I probably misunderstood the following statement from
> the description
We discussed this on #timvideos here:
I will repeat what I said.
The debug unit (CDM) and the du_* signals are used for:
1. Read/Write registers (this includes debug unit registers which gives
sofware controlling the CDM access to setup breakpoints/watchpoitns.)
2. Stalling/Starting the CPU (i.e. ctrl-C in gdb or continue)
3. Signalling to the debugger that a cpu has stalled. (breakpoint/watchpoint)
For or1k gdb and OpenOCD we dont have hardware breakpoints and watchpoints
implemented as far as I know we have something like this:
GDB <-> OpenOCD <-jtag-> [adv_debug_sys] <--> [mor1kx]
For OSD we would have
MaM - to handle reading writing to ram, i.e. set the l.trap
CDM - handle stall/resume and register access
As per my understanding.
Breakpoints are setup by writing an l.trap. instruction into memory. This
causes the CPU to stall when it hit a certain instruction. GDB will swap in/out
the real instruction upon resume.
Watchpoints are handled by setting up l.trap on every instruction and then
comparing old and new memory values after each stall. Ideally we will support
hardware watchpoints, but after we setup more watchpoints then is supported
by hardware gdb falls back to the l.trap on every instruction.
Again, I think we should be using adv_dbg_if as a base. But with some
- Support for the OSD debug interface
- No need for memory bus interface (its provided by MAM)
- Just need to support a single core (multicore is handled by OSD
> "Typical use cases include the initialization of a memory with a program,
> or the inspection of memory post-mortem or during run-control debugging."
> I understand the need of accessing other registers in the module. But, now
> we need to expand the register map as well as the system interface. For
> commands like "info spr", we need to map each and every other register
> (SPRs and GPRs) in the CDM module. There are 32 groups (only first 10 are
> important) of SPRs with each group having different register addressing
> scheme. Groups 0, 1 and 2 have 1535 registers each. I am not sure how
> mapping each and every register will work out in this case.
> Also, can the existing system interface signals (du* ports) be used to
> read/write any memory location?
> Do we need some interface similar to MAM module:
I think the interface should be similar. Registers are just memory locations in
Do you have a blog to report your gsoc status? Perhaps you can summarize this
More information about the OpenSoCDebug