[Open SoC Debug] CDM-OR1K implementation

Stafford Horne shorne at gmail.com
Fri May 25 00:00:55 CEST 2018


On Fri, May 25, 2018 at 12:20:08AM +0530, SHIVAM AGGARWAL wrote:
> Hi,
> 
> On Thu, May 24, 2018 at 10:07 PM, Philipp Wagner <philipp.wagner at tum.de>
> wrote:
...
> > 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.
> >
> 
> This is a very neat way of mapping.
> 
> 1. The final mapping will be something like this: https://docs.google.com/
> document/d/1qlmbhIvUt8XnSjvwAyiwyRDp6zeeJtN1Lz6WafBWn2o/edit?usp=sharing
> 
> 2. Since, we are mapping each SPR into exactly one OSD register, we need to
> change the width of the OSD register from 16 bits to 32 bits, right?
> 
> 3. We need to map only first 10 groups in the module. This implies that MSB
> for each group will always be 0. So, we can even omit the CORE_REG_UPPER
> part.

I would go with Philipp's method.  We should use the SPR bus for all register
access.  16 bit should be enough using the 2 register method philipp described.

> >
> > 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/opensocdebu
> > g/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.
> >
> >
> > 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.
> >
> 
> I think the only significant difference lies in the approach of
> implementing CDM module. Stafford mentioned that we can include the
> information for OR1K register map on the software side.

When I say map I mean "name" to "address" map.  The OSD-CDM module and CDM-CPU
module will need to map the GDB address to the CDM address then back to SPR bus
address address using the formula Phil described.

> "GDB Only really needs information about the GPRs:
>        See:
>     https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=
> blob;f=gdb/features/or1k-core.xml;h=6fe9765150575464bf11a975
> 2e3c3276ff4ab8fa;hb=HEAD
>
>     This is the base register map that GCC needs.
> 
>     For openOCD there are more provided which we can see here:
>     http://repo.or.cz/openocd.git/blob/HEAD:/src/target/openrisc/or1k.c#l53
> 
>     The register maps are transferred from the debug server to GDB via an
> XML file."
> 
> This will help in making CDM core independent. But, I think there are a
> couple of issues with this implementation.
> 
> First, we need to have specialized read/write registers in the CDM module
> instead of the register map. It will be inefficient as there will be
> multiple transactions for a single read/write access.
> Secondly, I am not sure if we can include OR1K register details in the
> software side as mentioned above in the OSD framework.
> 
> So, I believe it is best to map OR1K registers in the module.

I don't agree.  The 2,3 specialized translation registers is going to make it
much more simple.

-Stafford



More information about the OpenSoCDebug mailing list