[Open SoC Debug] CDM-OR1K implementation

SHIVAM AGGARWAL shivam16195 at iiitd.ac.in
Wed May 23 10:36:57 CEST 2018


Hi all,

I spend last two days reading about GDB and its architecture.

As a program that works directly with the instructions of the target CPU,
GDB needs in-depth knowledge about the details of the CPU core. GDB needs
information of all registers (SPRs and GPRs) within the target system CPU;
this allows it to read or write CPU registers by address. It also needs to
know about all the the sizes of the different kinds of data, the size and
shape of the address space, how the calling convention works, what
instruction will cause a trap exception, and so on.

To sum up, CDM-OR1K must provides access to each register in the CPU core
as a OSD specific register.

All SPRs in mor1kx are listed in this verilog code:
https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx-sprs.v


   1.

   *Register map for SPRs and GPRs in CDM-OR1K*:

We can easily map 32-bit wide 32 GPRs as two 16-bit OSD specific registers
in the module. We already have access to the debug unit for setting
watchpoints/breakpoints.

In GDB, there are commands like ‘info spr’ used to show the value of a SPR
or group of SPRs and ‘spr’ to set the value of an individual SPR. There are
about 12 groups (permitted upto 32) with some groups (1, 2 and 3) having
1000+ SPRs.

We can assign address spaces 0x0200-0xffff (about 65023 registers) as
module specific registers in CDM-OR1K. The space is enough to map each or1k
register into OSD address space.

*Alternate solution*: Can we have certain dedicated read/write registers in
the module?

i.e instead of mapping each and every register, each time GDB asks for a
specific SPR read/write, we can store its address in one of OSD register
and data in two other registers. This information can be translated over
system interface signals to the CPU core. But, for commands like ‘info
spr’, we might need to store such information for all the SPRs.

     2. *System Interface signals*

Currently, we have debug signals for the debug unit. The complete interface
should work like this:

Read operation:

   1.

   GDB commands Register read.
   2.

   OSD debug interconnect passes this request in the form of a register
   read request debug packet to the module. (
   https://opensocdebug.readthedocs.io/en/latest/02_spec/03_dataformats.html#register-read-request-type-sub-req-read-reg
   )
   3.

   CDM-OR1K acknowledges that request. du_we_i port goes low. (read
   operation)
   4.

   OR1K reads data from that address into OSD registers. (du_dat_o port)
   5.

   Now CDM-OR1K passes this information to OSD debug interconnect in the
   form of two reg read response packets. (
   https://opensocdebug.readthedocs.io/en/latest/02_spec/03_dataformats.html#register-read-response-type-sub-resp-read-reg-success
   )

Write operation will be similar.

Queries:

1. I looked in the description of mor1kx to figure out the system interface
for SPRs and GPRs. Can these signals be used for the system interface?

https://github.com/openrisc/mor1kx/blob/a9a01c009ea2b24764973560fde4a9855f4ba95d/rtl/verilog/mor1kx_cpu.v#L157

OR,
https://github.com/openrisc/mor1kx/blob/a9a01c009ea2b24764973560fde4a9855f4ba95d/rtl/verilog/mor1kx_bus_if_wb32.v#L28

2. Also since the system interface for SPRs will be different from that of
Debug unit, CDM-OR1K must also know a way to differentiate between the two,
right?


References:

http://www.aosabook.org/en/gdb.html

https://sourceware.org/gdb/wiki/Internals%20Register-Representation

https://www.embecosm.com/packages/esp3/embecosm-esp3-or32-gdb-6.8-or1k-manual-pdf-2.0.pdf

https://opencores.org/usercontent/doc/1263783054


*- Shivam Aggarwal*

On Tue, May 22, 2018 at 1:01 PM, Philipp Wagner <philipp.wagner at tum.de>
wrote:

> On 05/20/2018 04:25 PM, Stafford Horne wrote:
>
>> On Sun, May 20, 2018 at 05:11:55PM +0530, SHIVAM AGGARWAL wrote:
>>
>>> I went through all the resources again. As per my understanding, CDM
>>> works
>>> by storing breakpoint addresses in the debug registers.
>>>
>>
>> I don't think you need to think about it this way.  CDM just provides
>> access
>> to the CPU registers.  The debugger software decides what to write to
>> which
>> registers (i.e. this target driver in gdb/openocd).
>>
>> 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.
>>>
>>
>> It should be MAM (for 2 and 3). Unless anyone objects.
>>
>> To support any debugging we need read/write access to memory.
>>
>
> Just as Stafford said: the MAM enables access to the (main) memory. So
> part 2 and 3 are already there. So the main thing to do is (1).
>
> The main challenge on that one will be how to cleverly map the register
> address space of the mor1kx CPU to the limited register address space
> available through OSD. The question is essentially: can we come up with a
> core-agnostic, generic mapping, or do we need to pick certain address
> ranges out of the or1k register map and place it somewhere in the OSD
> register address space.
>
> To be able to answer this question, we first need a more detailed overview
> of the registers which are accessed through GDB.
>
> Shivam, could you provide this overview, and run it by Stafford to make
> sure you got everything covered? We can then in a second step discuss how
> to add this information to the CDM spec.
>
> Philipp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180523/9384b18d/attachment-0001.html>


More information about the OpenSoCDebug mailing list