search

enjoy-digital / litex

Build your hardware, easily!
Other
2.89k stars 555 forks source link

Debugging LiteX / VexRiscv with Verilator / OpenOCD / GDB #676

Closed lindemer closed 3 years ago

lindemer commented 3 years ago

Is it possible to load a binary onto an emulated LiteX / VexRiscv SoC in Verilator and debug it with GDB? If so, is there a tutorial on how to do this? I'm new to the LiteX ecosystem, and I see that lxsim has a --sim-debug flag, but I can't find any documentation on it. (I would like to do a cycle-accurate simulation of Zephyr RTOS with a custom VexRiscv plugin.)

Dolu1990 commented 3 years ago

I don't know if there is a TCP to JTAG bridge in litex, but in case of, there is how it can be done in SpinalSim : https://github.com/SpinalHDL/SpinalHDL/blob/cd04d9c3b06f82d18c28db9f82f7925276f41745/lib/src/main/scala/spinal/lib/com/jtag/sim/JtagTcp.scala#L10

You just need to open a TCP socket, apply each byte to the JTAG pin directly, and eventualy send back the TDO value as a byte

mithro commented 3 years ago

@tcal-x You had this question to right?

tcal-x commented 3 years ago

@mithro I haven't yet had a need to dive into Verilator simulation, but it is useful to know that it exists. I'd more likely use Verilator for collecting waveforms, but instead use Renode + custom instructions for functional debugging if the new instructions can be handled by the extension capability.

tcal-x commented 3 years ago

@mithro I haven't yet had a need to dive into Verilator simulation, but it is useful to know that it exists. I'd more likely use Verilator for collecting waveforms, but instead use Renode + custom instructions for functional debugging if the new instructions can be handled by the extension capability.

...although if I can't find the problem using Renode, then I'd need to get down to this level of detail -- debugging on the actual Verilog implementation using Verilator and the debug bridge with GDB.

lindemer commented 3 years ago

@enjoy-digital Is there any documentation on this available? The only information I can find is here https://github.com/timvideos/litex-buildenv/wiki/Debugging but I couldn't get this to work on my Arty board. After the load command in GDB, the connection appears to break (i.e., I can't read memory or run continue).

tcal-x commented 3 years ago

Hi @lindemer , I replied to you on VexRiscv Gitter, but I have one more comment. I see the instructions that you pointed to don't use wishbone-tool. Wishbone-tool is useful for wrapping the openOCD command and making it simpler to use.

From my notes, here is the set of things that I ran, using etherbone:

I don't (yet) have any experience debugging with a Verilator simulation.

lindemer commented 3 years ago

@tcal-x This is exactly what I'm looking for - had no idea wishbone-tool existed. Won't be able to test this until I'm back from the holidays, but thanks a lot for the tutorial.

tcal-x commented 3 years ago

I should have added these earlier:

Also, there is a section in the Fomu workshop that describes using wishbone-tool's gdb bridge:

lindemer commented 3 years ago

@tcal-x wishbone-tool throws this error when I follow your instructions:

Error: "invalid configuration: invalid ethernet address: io error invalid socket address"

I also tried running lxsim --cpu-type=vexriscv --cpu-variant=secure+debug --with-etherbone instead of using the FPGA but I get the same result, even though lxsim has automatically generated a new network interface with address 192.168.1.100/24. Have you encountered this problem?

tcal-x commented 3 years ago

@lindemer try doing ip addr to make sure the network interface is set up correctly.

I don't recall seeing that error.

Are you building your own wishbone-tool?

lindemer commented 3 years ago

@tcal-x I'm using a USB-Ethernet dongle and as far as I can tell everything's configured as it should be. I installed the latest Rust compiler and built wishbone-tool from source.

$ ip addr

3: enx00249b284adc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:24:9b:28:4a:dc brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 scope global enx00249b284adc
       valid_lft forever preferred_lft forever

$ ip route

default via 10.0.2.2 dev enp0s3 proto dhcp metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
169.254.0.0/16 dev enp0s3 scope link metric 1000
192.168.1.0/24 dev enx00249b284adc proto kernel scope link src 192.168.1.100
lindemer commented 3 years ago

@kgugala I'm still getting the same error message from wishbone-tool described above after pulling your fix for this in https://github.com/enjoy-digital/litex/pull/774. Any ideas?

tcal-x commented 3 years ago

Hi @lindemer , I just tried running it again, on Arty, using an soc built with --use-etherbone, and cpu_variant="full+debug". It works, although a bit flakey, but I don't see the error you mention. So let me dump what I did, and we can see if we missed anything.

sudo ip link set dev enx9cebe8612341 down
sudo ip addr add 192.168.1.100/24 dev enx9cebe8612341
sudo ip link set dev enx9cebe8612341 up

Note: I noticed my wireless interface was already using 192.168.1.x, so I switched to a different network in my home.

$ ip addr
6: enx9cebe8612341: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 9c:eb:e8:61:23:41 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 scope global enx9cebe8612341
       valid_lft forever preferred_lft forever

$ ip route 
192.168.1.0/24 dev enx9cebe8612341 proto kernel scope link src 192.168.1.100

Wow, almost identical to yours.

Then I run wishbone tool and see the expected response:

$ ~/bin/wishbone-tool --ethernet-host 192.168.1.50 -s gdb
INFO [wishbone_tool::server] accepting gdb connections on 127.0.0.1:3333

I'm using a top Python script for LiteX that's custom, but I don't know how that would allow it to work for me and not you. I'll see if I can generate a "pure" LiteX SoC and get it to work, time allowing.

tcal-x commented 3 years ago

EDIT: The previous version of the comment said that wishbone-tool wasn't working with a pure LiteX build, but it was my mistake: I had forgotten to kill the wishbone-tool connection from my "working" build, so when I tried to build with pure LiteX and connect, the old wishbone-tool connection was blocking my new attempt at connecting with wishbone-tool.

After killing the old wishbone-tool connection, the new connection with -s gdb did work as above, giving the accepting gdb connections message.

I had build using pure LiteX (with litex_setup.py), after updating all of the repos: ./arty.py --cpu-type=vexriscv --cpu-variant=full+debug --with-etherbone --build --load.

lindemer commented 3 years ago

@tcal-x Really appreciate all your help on this. So I've updated LiteX and run the commands you suggested, and I can now at least ping the board at 192.168.1.50, which is an improvement. I'm still getting the same invalid socket error from wishbone-tool, though.

I built the tool from source with the latest Rust/Cargo... any chance you're using an older version of it?

tcal-x commented 3 years ago

@lindemer , I'm using a locally-built wishbone-tool; I'm at this commit:

commit 8d1e09b807a7a79ebc1fc2dee8d40a208c788a5b (HEAD -> master, origin/master, origin/HEAD)
Merge: f00e82a b9531c0
Author: Sean Cross <sean@xobs.io>
Date:   Wed Nov 25 10:46:43 2020 +0800

    Merge pull request #34 from betrusted-io/master

    change the csr.csv register for the CPU reboot after USB update

Hmm, have you checked your firewall settings?

enjoy-digital commented 3 years ago

Closing since has been answered. This has been labelled as add-answer-to-wiki and answer will be added to Wiki.