[Open SoC Debug] Queries Regarding GSoC and Open SoC

Anant Sharma anant16129 at iiitd.ac.in
Fri Mar 9 15:03:12 CET 2018


On Mon, Feb 26, 2018 at 1:33 AM, Philipp Wagner <philipp.wagner at tum.de>
wrote:
>
> 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_").

When I want to edit the stuff that is going into mor1kx i.e. all the ports
which
start with "du_", from the mor1kx_module.sv file, I will actually be
dealing with
the following ports.

input         dbg_stall_i, // External Stall Input
input         dbg_ewt_i, // External Watchpoint Trigger Input
output [3:0]  dbg_lss_o, // External Load/Store Unit Status
output [1:0]  dbg_is_o, // External Insn Fetch Status
output [10:0] dbg_wp_o, // Watchpoints Outputs
output        dbg_bp_o, // Breakpoint Output
input         dbg_stb_i, // External Address/Data Strobe
input         dbg_we_i, // External Write Enable
input [31:0]  dbg_adr_i, // External Address Input
input [31:0]  dbg_dat_i, // External Data Input
output [31:0] dbg_dat_o, // External Data Output
output        dbg_ack_o, // External Data Acknowledge (not WB compatible)

These ports are linked to the instantiated ports of mor1kx which start with
"du_"

Now I have 2 problems when I try to do the above.

1. I can't figure out what values should I put into what ports to get the
result that
i am looking for. Is there anywhere where the procedure is documented? The
pdf
of or1kx architecture specification just talks about the registers but
nothing about
these ports.

2. If I do figure out the data I have to put in the ports, I will have to
create registers
which will be given values from inside an 'always' block which will in turn
be triggered
when the CPU resets. The gtkwave can visualize the dbg_bp_o for me but it
cannot
visualize registers inside mor1kx_module.sv


>
>
> 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.
>


Thank You,
Anant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180309/acddd3b4/attachment.html>


More information about the OpenSoCDebug mailing list