Cannot view memory address contents through OpenOCD GDB debugging (FPGA emulation)

[hasanalshaikh]

Hi, I am new to OpenOCD and debugging through FPGA emulation. So, pardon if any of the following seem trivial.

I am using the Digilent 2 board for emulation purposes. I built my openocd from riscv-openocd fork. I have a working Linux OS installed on my target. I followed the instructions provided on readme to open a terminal for OpenOCD using: openocd -f ariane.cfg This seems to be working fine with the output log being:

`Open On-Chip Debugger 0.11.0+dev-02217-g52ca5d198 (2022-01-31-13:19)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
none separate

DEPRECATED! use 'adapter speed' not 'adapter_khz'
DEPRECATED! use 'adapter driver' not 'interface'
Warn : Interface already configured, ignoring
DEPRECATED! use 'ftdi vid_pid' not 'ftdi_vid_pid'
DEPRECATED! use 'ftdi channel' not 'ftdi_channel'
DEPRECATED! use 'ftdi layout_init' not 'ftdi_layout_init'
DEPRECATED! use 'ftdi layout_signal' not 'ftdi_layout_signal'
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Warn : `riscv set_prefer_sba` is deprecated. Please use `riscv set_mem_access` instead.
Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x00000001 (mfg: 0x000 (<invalid>), part: 0x0000, ver: 0x0)
Info : [riscv.cpu] datacount=2 progbufsize=8
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=64, misa=0x800000000014112d
[riscv.cpu] Target successfully examined.
Info : starting gdb server for riscv.cpu on 3333
Info : Listening on port 3333 for gdb connections
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections`

Then I opened a second terminal to open gdb. I generated the .elf file of a simple Hello World program by compiling with the the riscv64-unknonw-elf-gcc. Then I established connection with the remote host. This is probably where the problem starts as I can see there's some packet error encountered although I am not sure why.

Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-linux-gnu --target=riscv64-unknown-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://github.com/sifive/freedom-tools/issues>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/hasan/Desktop/hello.elf...
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0xffffffe0006930e4 in ?? ()
Ignoring packet error, continuing...

Next, I load the program using load. However, I see that the program is starting loading into the address 0x100b0 which I believe should not be the case (it should start at 0x800000). But it still loads the program successfully:

(gdb) load
Loading section .text, size 0x260c lma 0x100b0
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Loading section .rodata, size 0x18 lma 0x126c0
Ignoring packet error, continuing...
Loading section .eh_frame, size 0x4 lma 0x136d8
Ignoring packet error, continuing...
Loading section .init_array, size 0x10 lma 0x136e0
Ignoring packet error, continuing...
Loading section .fini_array, size 0x8 lma 0x136f0
Ignoring packet error, continuing...
Loading section .data, size 0xf58 lma 0x136f8
Ignoring packet error, continuing...
Loading section .sdata, size 0x40 lma 0x14650
Ignoring packet error, continuing...
Start address 0x100c6, load size 13784
Ignoring packet error, continuing...
Transfer rate: 286 bytes/sec, 1969 bytes/write.

Meanwhile, I get this error message on the first terminal:

Error: Timed out after 120s waiting for busy to go low (abstractcs=0x8001002). Increase the timeout with riscv set_command_timeout_sec.
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 120s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Error: Unsupported register (enum gdb_regno)(8)
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 120s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Error: Unsupported register (enum gdb_regno)(8)

I have tried to set the timeout from telnet using riscv set_command_timeout_sec 300. This time I did not get the unsupported register or timeout errors on the OpenOCD terminal (it still shows packet error on gdb terminal though).

After the program is loaded, when I try to single step through the program using si it gets stuck at "Ignoring packet error, continuing" and nothing shows up. I also tried to read memory addresses using

(gdb) x/i 0x100b0
   0x100b0 <register_fini>:	Ignoring packet error, continuing...
Reply contains invalid hex digit 116

This same error message (Reply contains invalid hex digit) shows up for other memory addresses as well.

What am I doing wrong? To the best of my understanding, the problem lies with the elf file loading since it's loading at address 0x100b0 instead of 0x80000. Is there a different process for generating the elf file in FPGA emulation other than the process I followed? Also, why do I get these other errors? How do I get rid of them? Any help is much appreciated, thanks.

[niwis]

Hi, a few comments:

1. It looks like you are in kernel space when connecting gdb (i.e. Linux is booted). I understand that you would like to run a bare-metal program, correct? In that case, loading directly after connecting will not work because address translation is still enabled. In gdb, after target remote localhost:3333, issue a monitor reset halt to reset the core and start in M-mode.
2. gdb extracts the section addresses from the elf file. Double-check your linker script to make sure that the program is mapped to the correct addresses (you can double-check the resulting elf file with an objdump

The default timeout should suffice. When the busy flag is not cleared within 120s, usually something went very wrong (in your case, likely a store page fault when attempting to load the program into unmapped memory). It is not easy to recover from these; you need to reset the core. Packet errors should also not occur and indicate that something went wrong.

Best, Nils

[MikeOpenHWGroup]

Thanks for your help on this @niwis.

Hi @hasanalshaikh, this Issue has not been updated in one year so I can assuming your question was answered and will close it. If you still have a question, feel free to re-open this one or create a new one.