[Open SoC Debug] Queries Regarding GSoC and Open SoC

Philipp Wagner philipp.wagner at tum.de
Sun Feb 25 21:03:24 CET 2018


Hi Anant,

great to hear that you were successful!

Am 25.02.2018 um 19:00 schrieb Anant Sharma:
> I have set up my environment and ready to go. I faced a little problem
> because my system couldn't find or1k-elf-gcc, but I kind of fixed it. (I
> don't think there's anything wrong with the python script). 

Did you source the setup_prebuilt.sh script which comes as part of the
prebuilts?

> Also, went
> through the examples of the Verilator. I am all set. What can I do next?

Great. By trying out OpTiMSoC you saw the hardware in which the
run-control debug/GDB support should be integrated.

Now is a good time to look at the other side: how GDB actually talks to
a processor. That part is in fact easier than one might guess: the
processor core simply provides an interface with special-purpose
registers. By reading and writing these registers the CPU can be
stopped, breakpoints can be set, etc. The documentation for this
functionality is part of the OR1k architecture specification
(https://github.com/openrisc/doc/blob/master/openrisc-arch-1.2-rev0.pdf,
Chapter 11).

To access the registers mentioned in the or1k specification the mor1kx
CPU core has dedicated ports. You can find them here:
https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx.v#L139
(starting with "du_").

What we're skipping for now is the question how the GDB software can
talk to the hardware. That part differs between simulation and real
hardware, and also different in traditional debug systems (which make
use of JTAG) and the one we're trying to build.

So back to the debug interface of the processor. To see that interface
in action, you could try your first hardware modification.

- Take the simplest example in OpTiMSoC, the compute_tile_dm with a
single core running in Verilator. You have already built that design
when working through the tutorial. However, now you need to re-build it
frequently. To do so make use of fusesoc directly as it is documented
here: https://www.optimsoc.org/docs/master/user_guide/develop.html

- Enable the debug unit in the CPU by adding
FEATURE_DEBUGUNIT("ENABLED") to the mor1kx_module file.

- You can now try to add Verilog code to stimulate the debug port. Since
we're just experimenting, you can add the code for example into the
mor1kx_module file. You could try to do the following: After the reset
of the CPU, configure it through the debug port to have a breakpoint set
when entering the main function. You do this by using the du_* signals
as outlined in the or1k specification.

Breakpoints are always set to a given program counter, so to break at
the main function you need to know the program counter at this point.
You can find it by taking a look at the disassembly of the program
you're running on the mor1kx core. If you use the hello.elf file for
example (as in the tutorial), you can determine the program counter as
follows:

~/src/baremetal-apps/hello $ grep '<main>:' hello.dis
00002540 <main>:

In my case the program counter when entering the main function would be
0x2540. This could differ on your machine though, so make sure to check
yourself.

- Once you have made the necessary modifications in the Verilog code,
you can re-run the simulation. Run it with waveforms enabled and have a
look at them in Gtkwave. Does the CPU stop indeed when the breakpoint is
hit?



I know it's a lot to wrap your head around. Good luck and persistence!
If you have questions, please let us know.

Best,

Philipp


More information about the OpenSoCDebug mailing list