[Open SoC Debug] CDM: Next Steps
shivam16195 at iiitd.ac.in
Fri Jun 15 13:28:51 CEST 2018
I went through a couple of resources to understand the implementation of
GDB server, RSP protocol
and how these things can be used for OSD-GDB server.
A gdbserver acts as a bridge between GDB (the GNU debugger) and a System on
It accepts commands from GDB via a network port (TCP/IP) using the RSP
then translates those commands into a format understandable by the debug
modules in the system being debugged.
The current implementation of gdb server in openOCD is generic and
The target specific details (for example, for OR1K) are listed here:
As per my understanding, the complete software side in OSD should be
something like this:
The OSD-GDB server will be responsible for communication between GDB and
server via TCP port using RSP protocol.
The major differences (as per my understanding) between the implementation
of gdbserver in
openOCD and OSD system:
1. The bridge program uses the hardware drivers to send the translated
commands to the
target system via an external JTAG cable in case of openOCD. We don’t need
JTAG or any other communication medium in the OSD-GDB server.
This part is handled by GLIP and osd-device gateway.
2. There are 2 data areas that are manipulated by GDB:
- Main memory. A uniform address space with 32-bit addressing. Provision
for separate or unified instruction and data and instruction caches.
Provision for separate or unified, 1 or 2-level data and instruction MMUs.
- This area can be accessed using MAM client class.
- Special Purpose Registers (SPRs). These registers provide all the
administrative functionality of the processor: program counter, processor
status, saved exception registers, debug interface, MMU and cache
- This area can be accessed using CDM client class.
3. An interface to connect it to the host controller (as mentioned in the
I think the general API for that part should be similar to osd_memaccess
The target description is mentioned as:
Also, something about the target description in an XML file is specified
I am looking more into this point. Please, if possible elaborate more about
this point and
how it can be executed in the OSD-GDB server.
Also, suggest if I should continue the discussion over this topic on the
mailing list or a PR with possible API would be better?
On Wed, Jun 13, 2018 at 10:49 AM, SHIVAM AGGARWAL <shivam16195 at iiitd.ac.in>
> On Wed, Jun 13, 2018 at 2:43 AM, Stafford Horne <shorne at gmail.com> wrote:
>> Hi Shivam,
>> As it was noted in Philip's mail it was suggested to work on the "CDM
>> Client" class. This will help define the software side API of the CDM
>> hardware that the gdb-osd server will interact with. In order to do
>> that you may also want to think about what API (functions) would be
>> required by the gdb server. You can look at some example
>> implementations of those.
>> I would also suggest having a non gdb, more simple, debug interface.
>> The gdb debug interface is quite complicated and makes a lot of
>> abstractions via GDB. Having a simple interface could make it easy to
>> independently verify your "CDM client" class. Is there something
>> similar already for the MAM interface?
> We have completed the implementation of CDM client class.
> Please take a look at the merged code:
> Associated tests:
> A brief description of the API documentation:
> Apart from the event part of CDM, CDM client class provides two important
> API(functions)- cl_cdm_cpureg_read() and cl_cdm_cpureg_write()
> functions for easy interface with OSD-GDB server bridge. The two functions
> provide read/write register accesses by first updating the CORE_REG_UPPER
> register with the MSB of the SPR register (only if required), followed by
> an address translation from SPR register to CDM specific register and
> finally, a concluding read/write register request.
>> For software a good reference implementation for a gdb server is the
>> one from qemu:
>> - qemu - https://git.qemu.org/?p=qemu.git;a=blob;f=gdbstub.c
>> There is also a openocd gdb server implementation:
>> - http://repo.or.cz/openocd.git/blob/HEAD:/src/server/gdb_server.c
>> Bother are self contained and not huge.
> Thanks for the referred implementation. I went through the implementation
> of openocd gdb server very briefly.
>> On Wed, Jun 13, 2018 at 1:27 AM SHIVAM AGGARWAL <shivam16195 at iiitd.ac.in>
>> > Oh sorry. It was probably a misunderstanding on my part.
>> > I will continue with the OSD-GDB server bridge. I have already opened
>> an issue: https://github.com/opensocdebug/osd-sw/issues/19
>> > I am reading about RSP protocol and looking at the source code of
>> openOCD for reference: http://repo.or.cz/openocd.git/tree/HEAD:/src
>> > Thanks a lot for your guidance and support.
>> > Shivam Aggarwal
>> > On Tue, Jun 12, 2018 at 9:35 PM, Philipp Wagner <philipp.wagner at tum.de>
>> >> On 06/12/2018 05:55 PM, SHIVAM AGGARWAL wrote:
>> >>> Okay. I will complete the hardware implementation and get back to you
>> soon. Also, I got access to Synopsys VCS through my institute's lab
>> resources. I am currently learning how to use the tool.
>> >>> So, please guide me about the testing part as well.
>> >> Let's not do too many things at once. You started with the software
>> part, and I'm proposing to continue down this path and finish it first
>> before moving on to the next thing.
>> >> Philipp
>> >> _______________________________________________
>> >> OpenSoCDebug mailing list
>> >> OpenSoCDebug at lists.librecores.org
>> >> https://lists.librecores.org/listinfo/opensocdebug
>> > _______________________________________________
>> > OpenSoCDebug mailing list
>> > OpenSoCDebug at lists.librecores.org
>> > https://lists.librecores.org/listinfo/opensocdebug
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenSoCDebug