<div dir="ltr"><div><div>On Mon, Feb 26, 2018 at 1:33 AM, Philipp Wagner <<a href="mailto:philipp.wagner@tum.de">philipp.wagner@tum.de</a>> wrote:<br>><br>> Hi Anant,<br>><br>> great to hear that you were successful!<br>><br>> Am 25.02.2018 um 19:00 schrieb Anant Sharma:<br>> > I have set up my environment and ready to go. I faced a little problem<br>> > because my system couldn't find or1k-elf-gcc, but I kind of fixed it. (I<br>> > don't think there's anything wrong with the python script).<br>><br>> Did you source the setup_prebuilt.sh script which comes as part of the<br>> prebuilts?<br>><br>> > Also, went<br>> > through the examples of the Verilator. I am all set. What can I do next?<br>><br>> Great. By trying out OpTiMSoC you saw the hardware in which the<br>> run-control debug/GDB support should be integrated.<br>><br>> Now is a good time to look at the other side: how GDB actually talks to<br>> a processor. That part is in fact easier than one might guess: the<br>> processor core simply provides an interface with special-purpose<br>> registers. By reading and writing these registers the CPU can be<br>> stopped, breakpoints can be set, etc. The documentation for this<br>> functionality is part of the OR1k architecture specification<br>> (<a href="https://github.com/openrisc/doc/blob/master/openrisc-arch-1.2-rev0.pdf">https://github.com/openrisc/doc/blob/master/openrisc-arch-1.2-rev0.pdf</a>,<br>> Chapter 11).<br>><br>> To access the registers mentioned in the or1k specification the mor1kx<br>> CPU core has dedicated ports. You can find them here:<br>> <a href="https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx.v#L139">https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx.v#L139</a><br>> (starting with "du_").<br><br>When I want to edit the stuff that is going into mor1kx i.e. all the ports which<br>start with "du_", from the <a href="http://mor1kx_module.sv">mor1kx_module.sv</a> file, I will actually be dealing with<br>the following ports.<br><br>input         dbg_stall_i, // External Stall Input<br>input         dbg_ewt_i, // External Watchpoint Trigger Input<br>output [3:0]  dbg_lss_o, // External Load/Store Unit Status<br>output [1:0]  dbg_is_o, // External Insn Fetch Status<br>output [10:0] dbg_wp_o, // Watchpoints Outputs<br>output        dbg_bp_o, // Breakpoint Output<br>input         dbg_stb_i, // External Address/Data Strobe<br>input         dbg_we_i, // External Write Enable<br>input [31:0]  dbg_adr_i, // External Address Input<br>input [31:0]  dbg_dat_i, // External Data Input<br>output [31:0] dbg_dat_o, // External Data Output<br>output        dbg_ack_o, // External Data Acknowledge (not WB compatible)<br><br>These ports are linked to the instantiated ports of mor1kx which start with "du_"<br><br>Now I have 2 problems when I try to do the above.<br><br>1. I can't figure out what values should I put into what ports to get the result that<br>i am looking for. Is there anywhere where the procedure is documented? The pdf<br>of or1kx architecture specification just talks about the registers but nothing about<br>these ports.<br><br>2. If I do figure out the data I have to put in the ports, I will have to create registers<br>which will be given values from inside an 'always' block which will in turn be triggered<br>when the CPU resets. The gtkwave can visualize the dbg_bp_o for me but it cannot<br>visualize registers inside <a href="http://mor1kx_module.sv">mor1kx_module.sv</a> <br><br> <br>><br>><br>> What we're skipping for now is the question how the GDB software can<br>> talk to the hardware. That part differs between simulation and real<br>> hardware, and also different in traditional debug systems (which make<br>> use of JTAG) and the one we're trying to build.<br>><br><br><br></div>Thank You,<br></div>Anant<br></div>