[Open SoC Debug] CDM-OR1K implementation

Stafford Horne shorne at gmail.com
Thu May 24 23:52:25 CEST 2018

On Thu, May 24, 2018 at 06:37:21PM +0200, Philipp Wagner wrote:
> Hi,
> this thread got rather long and the introduction of OpenOCD into the picture
> confuses me. So I'm taking the chance to summarize the my current
> understanding.

Sorry, I am not saying we want to use OpenOCD in the OSD architecture.  But
OpenOCD is the current adv_debug_sys to GDB bridge.  It should server as a
example of how to do the OSD-GDB bridge.
> To make it easier to follow, I created a modified figure here:
> http://pasteall.org/pic/show.php?id=91948fcf0633eef6e4aa0b0d9c0a58d3 (it's
> not pretty, but hopefully illustrative).
> What important components do we have in the system?
> 1) The Core Debug Module (CDM). This module connects to a single CPU and has
> two tasks:
>   a) Forward the accesses to SPRs from GDB to the core. The data can be
> forwarded unchanged, but the address needs to be translated.
>   b) Inform GDB about a status change to the CPU. The only status change
> we're interested in is a change between stalled and unstalled.
> 2) The MAM. This (already existing) module can read and write arbitrary
> memory addresses.
> 3) The OSD-GDB Server Bridge. This software module speaks the gdbserver
> protocol and forwards the GDB requests to the MAM and CDM modules.
> Notably absent in this picture are adv_dbg_system and OpenOCD. I don't see
> how these two pieces fit into the picture (expect for taking inspiration
> from their implementation).

Yes, I agree.

> Now let's have a closer look at the CDM module.
> - Every OSD module has registers which can be accessed from the host. I'm
> calling them "OSD registers" for now.
> - OSD Register addresses are 16 bit wide, values can (according to the spec)
> be 16, 32, 64 or 128 bit wide. (http://opensocdebug.readthedocs.io/en/latest/02_spec/03_dataformats.html#register-access-type-reg)
> - OSD register addresses between 0x0000 and 0x01FF are always used by OSD
> itself and have fixed meaning. All other register addresses can be used for
> any purpose by the debug module, i.e. by the CDM module in this case.
> - To enable GDB to access any SPR of the core, we want to use this
> functionality to "forward" register accesses from GDB through the OSD system
> to the core.
> - Side note: GPRs can be also be accesses through a SPR address, so there's
> no need have dedicated support for GPRs.
> - or1k SPR addresses in or1k are 16 bit wide.
> - As we don't have 16 bit available for a OSD register address, given the
> fixed registers between 0..0x200, we need to perform a address mapping. The
> address mapping I'm proposing is outlined below.
> - Register accesses require polling from the host. To notify the host about
> something interesting OSD provides a concept of "event packets". These
> packets can be sent by the CDM like an interrupt at any time and the host
> can then react on it. We can use this functionality to inform the host about
> a change in processor state: the core is stalled, or not stalled any more.
> SPR to CDM register address mapping
> - Map SPRs to CDM address 0x8000 to 0xFFFF (msb set). This gives 15 bit of
> address space.
> - Have a separate register called CORE_REG_UPPER which contains the msb of
> the address.
> - The SPR register address is then calculated as
>   spr_reg_addr = CORE_REG_UPPER << 15 | cdm_reg_addr - 0x8000
> - As long as the msb of a SPR register address (spr_reg_addr[15]) does not
> change the CORE_REG_UPPER register does not need to be modified, nicely
> generating one (1) OSD operation for a one (1) SPR register access.

Yes, this is the kind of mapping I had in mind too.  Not a 1-to-1 mapping for
each register, but address tranlation only.

> Finally, let's look at the OSD-GDB Server bridge.
> - In OSD-speak, this component is a "host module". It connects to the "host
> controller" over (most of the time) TCP and has functionality to read and
> write OSD registers from any other module, and to receive and send OSD event
> packets, just like a debug module on the chip. An example for such a host
> module can be found here: https://github.com/opensocdebug/osd-sw/blob/master/src/libosd/systracelogger.c
> In our case, the OSD-GDB server bridge will need to communicate with the CDM
> and the MAM modules.
> - The OSD-GDB Server bridge also needs to be able to talk to a GDB instance.
> For this purpose it implements the gdbserver protocol. GDB instances can
> then connect to this gdbserver over TCP and communicate with the target.
> - Most "intelligence" is within gdb itself. gdb knows which SPRs to read and
> write at what time, it knows how to to translate a "set breakpoint" request
> from the user into a memory write inserting a l.trap, etc.


> - Looking at the OpenOCD implementation I'm not fully sure what additional
> functionality, beyond transferring register and memory accesses between GDB
> and the core/memory we need to perform within the OSD-GDB Server bridge.

Yes, OpenOCD was just and example of what the OSD-GDB bridge needs to do to help
Shivam understand the details needed.

> Stafford and Shivam, is this matching your understanding as well? If there
> are significant differences in understanding maybe we should schedule a
> video call to get this sorted out quickly.

Yes, this matches 100%.  I think this is basically what we need in the spec.


More information about the OpenSoCDebug mailing list