[Open SoC Debug] CDM-OR1K implementation
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:
> On Thu, May 24, 2018 at 10:07 PM, Philipp Wagner <philipp.wagner at tum.de>
> > 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) 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/
> 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
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:
> This is the base register map that GCC needs.
> For openOCD there are more provided which we can see here:
> 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.
More information about the OpenSoCDebug