[Open SoC Debug] Queries Regarding GSoC and Open SoC

Anant Sharma anant16129 at iiitd.ac.in
Wed Feb 28 16:29:01 CET 2018

Done some changes around the same and getting a different error which is
attached in the log file below. Would be great if someone could help out!

Anant Sharma,
BTech - ECE,
IIIT Delhi,

Ph: 9718827023

On Mon, Feb 26, 2018 at 1:33 AM, Philipp Wagner <philipp.wagner at tum.de>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180228/ea7fd495/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: verilator.err.log
Type: text/x-log
Size: 6220 bytes
Desc: not available
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180228/ea7fd495/attachment-0001.bin>

More information about the OpenSoCDebug mailing list