[Open SoC Debug] CDM-OR1K implementation

SHIVAM AGGARWAL shivam16195 at iiitd.ac.in
Sun May 20 13:41:55 CEST 2018


Thanks for the response.
On Sun, May 20, 2018 at 3:54 AM, Stafford Horne <shorne at gmail.com> wrote:

> 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>
> > wrote:
> >
> > > 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.
> >
> https://github.com/openrisc/tutorials/blob/master/docs/Debugging.md#gdb-basics
> >
> > 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
> > <
> https://opensocdebug.readthedocs.io/en/latest/02_spec/07_modules/mam/index.html
> >
> > :
>
> We discussed this on #timvideos here:
>
> https://botbot.me/freenode/timvideos/2018-05-11/?msg=99956125&page=1
>
> 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)
>

Yes. That's pretty much what I covered in the specification.

>
> 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]
>                                       \           |
>                                        \------> [ram]
>
> 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.
>
>   See: https://sourceware.org/gdb/wiki/Internals/Breakpoint%20Handling
>
> 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.
>
>   See: https://sourceware.org/gdb/wiki/Internals%20Watchpoint
> <https://sourceware.org/gdb/wiki/Internals%20Watchpoints>
>
Again, I think we should be using adv_dbg_if as a base. But with some
> differences:
>
>   - 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
>     architecture)
>
> > "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
> the CPU.
>
>
I went through all the resources again. As per my understanding, CDM works
by storing breakpoint addresses in the debug registers. If a  PC ever
matches a value in breakpoint registers, CPU raises an exception and
reports it to GDB. This is basically a hardware breakpoint.
As you mentioned above, by writing an l.trap instruction into memory we can
implement software breakpoint. For this part, we need access to memory.
(MAM)

Things to do now:
1. To expand memory map to access a the other registers.
2. To see how the existing system interface can be used to read/write
memory.
3. To support software breakpoints, we need access to memory. This can be
achieved either by using MAM or extending CDM module.


Do you have a blog to report your gsoc status?  Perhaps you can summarize
> this
> there?
>

I do have a blog: https://gsoc2018timvideos.wordpress.com/
I post daily snippets on the blogs and will also post weekly status updates
every Monday.

I have also posted a week wise schedule for CDM-OR1K.
https://gsoc2018timvideos.wordpress.com/2018/05/18/week-wise-schedule-for-cdm-or1k/

Please check and provide your valuable feedback.


> -Stafford
>

- Shivam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180520/75bc74ab/attachment.html>


More information about the OpenSoCDebug mailing list