riscv-collab / riscv-openocd

Fork of OpenOCD that has RISC-V support
Other
452 stars 328 forks source link

Infinite loop (busy datacount) and problems installing riscv-openocd #561

Closed LPLATU closed 9 months ago

LPLATU commented 3 years ago

Hello,

unfortunately I couldn't find a solution to the two problems I am facing right now.

The first problem is as follows: I am working with the PULPissimo Platform and have successfully ported it to FPGA (ZedBoard) by following the guide they provide with just minor adjustments. This was fine and I was able to use OpenOCD and gdb to load an ELF file and run (and debug) the program. I have used Open On-Chip Debugger 0.8.0 (2014-04-29-12:22) as well as Open On-Chip Debugger 0.10.0+dev-00615-g5ead86ea9 (2020-08-24-15:25).

We then went on and tried using a different core (everything else is pretty much the same, just the core has been replaced). The core is a RI5CY look-alike core which implements the interrupt system as specified in the RISC-V Instruction Set Manual. We did quite some simulation on RTL and also synthesis and everything has worked fine so far. I have then created the bitstream and flashed it to the FPGA, pretty much following the guide like last time. When I am trying to launch OpenOCD with my configuration file, it takes a long time and will result in the following:

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

When I connect gdb it will result in the following:

(gdb) target remote localhost:3333 Remote debugging using localhost:3333 warning: Target-supplied registers are not supported by the current architecture Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Remote 'g' packet reply is of odd length: E0E

This of course means that I am unable to load anything to the board.

(gdb) load You can't do that when your target is `exec'

Unfortunately I haven't had any problems like this before (sounds weird to say...) so I'm not very knowledgeable in debugging OpenOCD as it has just worked before without any major problems. What I did was run it with the -d3 option and compared it with the vanilla PULPissimo that I have used before. This showed me (or rather confirmed) that (the core?) seems to be busy for some reason:

Debug: 11677 922 target.c:1609 target_call_event_callbacks(): target event 18 (examine-end) for core 992 Debug: 11678 922 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_flash init Debug: 11679 922 command.c:143 script_debug(): command - ocd_flash ocd_flash init Debug: 11680 922 riscv.c:1550 riscv_openocd_poll(): polling all harts Debug: 11681 922 riscv.c:2385 riscv_set_current_hartid(): setting hartid to 992, was 992 Debug: 11682 922 riscv.c:1504 riscv_poll_hart(): polling hart 992, target->state=0 Debug: 11683 922 riscv-013.c:393 scan(): 41b 3i r 00000000 @11 -> + 00000000 @10 Debug: 11684 922 riscv-013.c:393 scan(): 41b 3i - 00000000 @11 -> + 00030382 @11 Debug: 11685 922 riscv-013.c:404 scan(): -> allresumeack anyresumeack allhalted anyhalted authenticated version=2 Debug: 11686 922 riscv.c:1510 riscv_poll_hart(): triggered a halt Debug: 11687 922 riscv.c:1641 riscv_openocd_poll(): hart 992 halted Debug: 11688 922 riscv.c:2385 riscv_set_current_hartid(): setting hartid to 992, was 992 Debug: 11689 922 riscv-013.c:393 scan(): 41b 3i r 00000000 @11 -> + 00000000 @11 Debug: 11690 922 riscv-013.c:393 scan(): 41b 3i - 00000000 @11 -> + 00030382 @11 Debug: 11691 922 riscv-013.c:404 scan(): -> allresumeack anyresumeack allhalted anyhalted authenticated version=2 Debug: 11692 922 riscv-013.c:793 execute_abstract_command(): command=0x2207b0; access register, size=32, postexec=0, transfer=1, write=0, regno=0x7b0 Debug: 11693 922 riscv-013.c:393 scan(): 41b 3i w 002207b0 @17 -> + 00000000 @11 Debug: 11694 923 riscv-013.c:393 scan(): 41b 3i - 00000000 @17 -> + 002207b0 @17 Debug: 11695 923 riscv-013.c:393 scan(): 41b 3i r 00000000 @16 -> + 00000000 @17 Debug: 11696 923 riscv-013.c:393 scan(): 41b 3i - 00000000 @16 -> + 08001002 @16 Debug: 11697 923 riscv-013.c:404 scan(): -> progbufsize=8 busy datacount=2 Debug: 11698 923 riscv-013.c:393 scan(): 41b 3i r 00000000 @16 -> + 00000000 @16 Debug: 11699 923 riscv-013.c:393 scan(): 41b 3i - 00000000 @16 -> + 08001002 @16 Debug: 11700 923 riscv-013.c:404 scan(): -> progbufsize=8 busy datacount=2 Debug: 11701 923 riscv-013.c:393 scan(): 41b 3i r 00000000 @16 -> + 00000000 @16 Debug: 11702 923 riscv-013.c:393 scan(): 41b 3i - 00000000 @16 -> + 08001002 @16 Debug: 11703 923 riscv-013.c:404 scan(): -> progbufsize=8 busy datacount=2 Debug: 11704 924 riscv-013.c:393 scan(): 41b 3i r 00000000 @16 -> + 00000000 @16 Debug: 11705 924 riscv-013.c:393 scan(): 41b 3i - 00000000 @16 -> + 08001002 @16 Debug: 11706 924 riscv-013.c:404 scan(): -> progbufsize=8 busy datacount=2 Debug: 11707 924 riscv-013.c:393 scan(): 41b 3i r 00000000 @16 -> + 00000000 @16 Debug: 11708 924 riscv-013.c:393 scan(): 41b 3i - 00000000 @16 -> + 08001002 @16 Debug: 11709 924 riscv-013.c:404 scan(): -> progbufsize=8 busy datacount=2 ... (this will loop) ...

The fact that everything works with the core provided on the PULPissimo platform makes me guess that there is a problem with the new core that we use and not with OpenOCD itself but I am not 100% certain. Maybe someone can confirm/deny?

My second problem is with getting this here OpenOCD to install.

System:

Operating System: Scientific Linux 7.6 (Nitrogen) CPE OS Name: cpe:/o:scientificlinux:scientificlinux:7.6:GA Kernel: Linux 3.10.0-1062.4.3.el7.x86_64 Architecture: x86-64

I have started by cloning

git clone git://git.code.sf.net/p/openocd/code openocd

after that I switched to the directory and pulled

git pull

everything is up-to-date, so I continued with

./bootstrap

which results in some errors

+ aclocal --warnings=all + libtoolize --automake --copy + autoconf --warnings=all + autoheader --warnings=all + automake --warnings=all --gnu --add-missing --copy configure.ac:29: installing './compile' configure.ac:38: installing './config.guess' configure.ac:38: installing './config.sub' configure.ac:17: installing './install-sh' configure.ac:17: installing './missing' src/Makefile.am:4: error: bad characters in variable name '%C%_openocd_SOURCES' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:7: error: bad characters in variable name '%C%_libopenocd_la_SOURCES' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:11: error: bad characters in variable name '%C%_openocd_LDADD' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:13: error: bad characters in variable name '%C%_openocd_LDADD' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:16: error: bad characters in variable name '%C%_openocd_LDADD' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:18: error: bad characters in variable name '%C%_openocd_LDADD' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:21: error: bad characters in variable name '%C%_libopenocd_la_CPPFLAGS' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:26: error: bad characters in variable name '%C%_libopenocd_la_CPPFLAGS' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:27: error: bad characters in variable name '%C%_libopenocd_la_CPPFLAGS' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:29: error: bad characters in variable name '%C%_libopenocd_la_CPPFLAGS' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:30: error: bad characters in variable name '%C%_libopenocd_la_CPPFLAGS' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:31: error: bad characters in variable name '%C%_libopenocd_la_CPPFLAGS' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:35: error: bad characters in variable name '%C%_libopenocd_la_CPPFLAGS' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:38: error: bad characters in variable name '%C%_libopenocd_la_LDFLAGS' Makefile.am:143: 'src/Makefile.am' included from here src/Makefile.am:46: error: bad characters in variable name '%C%_libopenocd_la_LIBADD' Makefile.am:143: 'src/Makefile.am' included from here doc/Makefile.am:2: error: bad characters in variable name '%C%_openocd_TEXINFOS' Makefile.am:144: 'doc/Makefile.am' included from here Makefile.am:46: warning: wildcard $(srcdir: non-POSIX variable name Makefile.am:46: (probably a GNU make extension) Makefile.am: installing './INSTALL' Makefile.am: installing './depcomp' automake: error: cannot open < ./%D%/openocd.texi: No such file or directory

I then tried to run

./configure

which results in the following error

configure: error: jimtcl not found, run git submodule init and git submodule update.

so I did both

git submodule init git submodule update

no errors here, so I tried to configure again

./configure

this results in the following error

config.status: error: cannot find input file: `Makefile.in'

which is where I am right now. I don't know if I have to give any arguments to the configure but from what I read you don't have to (but I could be wrong about that). I also don't know if this here OpenOCD is even necessary for me or (as mentioned above) if the problem is rather with the core itself.

Unfortunately up to this point I never had any major issues with the FPGA port or OpenOCD or gdb (it really does sound weird to say this) so I'm kind of lost right now. I hope this is the right place to ask and that someone might give me some hints as to what exactly the problem is and where I should start to fix it.

Thank you for your time, LPLATU

JanMatCodasip commented 3 years ago
src/Makefile.am:4: error: bad characters in variable name '%C%_openocd_SOURCES'
Makefile.am:143: 'src/Makefile.am' included from here
...
...

If I recall correctly, these errors appear if automake version is insufficient. Can you please check your automake version? Automake 1.14 or newer is required:

automake --version
LPLATU commented 3 years ago
src/Makefile.am:4: error: bad characters in variable name '%C%_openocd_SOURCES'
Makefile.am:143: 'src/Makefile.am' included from here
...
...

If I recall correctly, these errors appear if automake version is insufficient. Can you please check your automake version? Automake 1.14 or newer is required:

automake --version

Indeed my automake is version is automake (GNU automake) 1.13.4 I'm going to manually update it as yum tells me I already have the latest version.

Edit: So I updated to automake 1.16.3 and tried again.

git clone git://git.code.sf.net/p/openocd/code openocd

then

cd openocd/ git pull

also I did

git submodule init git submodule update

then I did

./bootstrap

which resulted in

/+ aclocal --warnings=all /+ libtoolize --automake --copy /+ autoconf --warnings=all configure.ac:13: error: possibly undefined macro: AC_MSG_WARN If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:37: error: possibly undefined macro: AC_DISABLE_SHARED configure.ac:207: error: possibly undefined macro: AC_DEFINE configure.ac:646: error: possibly undefined macro: AC_MSG_NOTICE

after that I tried

./configure

to see what would happen. This resulted in

configure: error: cannot find install-sh, install.sh, or shtool in . "."/.

JanMatCodasip commented 3 years ago

I haven't personally run into this specific issue, so I am guessing: The autoconf errors seem to be the trouble. Could this be due to missing pkg-config?

BTW, when running ./configure, you may use the following arguments (which enable the most frequently used JTAG drivers):

./configure --enable-jtag_vpi \ 
    --enable-remote-bitbang \ 
    --enable-ftdi \
    --prefix=<path/where/to/install>
TommyMurphyTM1234 commented 3 years ago

Hopefully I won't get flamed for it here like I did on the openocd mailing list recently :-) but I find using @ilg-ul's xPack Project openocd docker based build scripts much more predictable and easy to use than trying to build openocd manually/natively. Less No messing around trying to find the magic combination of packages to install to make things work and the resulting binaries are much more portable over a wide range of Linux distros/versions (as well as Windows and MacOS).

https://xpack.github.io/openocd/ https://xpack.github.io/openocd/#build-details https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md

You can edit this file to build from the SiFive RISC-V openocd fork repo:

https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L41

Hope this helps.

timsifive commented 3 years ago

Looks like you're getting some good help here.

git clone git://git.code.sf.net/p/openocd/code openocd

That is starting with upstream OpenOCD. This github is for the RISC-V fork of OpenOCD, which generally has a little bit better RISC-V support, but not all the latest OpenOCD features. The long-term goal is to make them both identical, but we're not there yet.

en-sc commented 9 months ago

@LPLATU, seems like the issue is resolved. I would like to close it.