[Open SoC Debug] CDM-OR1K implementation

SHIVAM AGGARWAL shivam16195 at iiitd.ac.in
Sat May 19 18:23:45 CEST 2018

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

"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:


>     *Stall Packet (CDM->debugger)*
> >     In the stall packet I see we encode the "reason", I don't think we
> >     need it. This would require that the CDM core know how to figure that
> >     out.  i.e. it would have to read the DRR to detect it was a trap,
> then
> >     it would need to check DMR2[WBS] to determine what caused the trap.
> >     I think the stall packet should specify "stall" only and core id if
> >     needed.   Note there are multiple things that might cause a stall
> >     (Timers, Debug Traps, Bus Error, Reset) we might want to capture all
> >     of those some day)
> >
> >
> > Yes. This part of specification is still pretty experimental.
> > I kept the description very minimal for this part for now. I believe for
> > a start, just a stall signal should be sufficient.
> You kept the description of the 'reason' field minimal, but in fact the
> minimal solution would be to just leave out the 'reason' field. You
> might want to go ahead and do that.
> >     *Stall Packet (debugger->CDM) - missing?*
> >     I think we also need a packet to stall and restart the core.  I
> >     don't see this.
> >
> >
> > I think you are right. We need some means to allow debugger to stop the
> > CPU core. Subnet Control Module already provides this functionality.
> > https://opensocdebug.readthedocs.io/en/latest/02_spec/07_modules/scm/
> dbgregisters.html
> > For this part, we can have one more register in the control register
> > map. Setting this register high should be enough to stall and restart
> > the core.
> - I would expect a stall to be done using a OSD register write, not
> using an event packet. Event packets are there utilized for unsolicited
> events, i.e. things which cannot be anticipated by the host CPU when
> they happen.
> - The STM module can only stall *all* CPUs in the system, it is not
> designed to stall individual modules. If none of the registers described
> in the current CDM spec provide this functionality you need to add it
> there.
> Philipp

- Shivam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180519/3e771af1/attachment-0001.html>

More information about the OpenSoCDebug mailing list