How to connect riscv core device with adv_dbg_if.

[AdmsLCW]

We made the pulpino chip, but we had no way to test it. Because pulpino uses the debugging interface of adv_dbg_if, and the core is riscv. When I use openocd to connect, I select or1k in the configuration file to connect, but I can't enter the command, which makes me very distressed. Can I modify the underlying function so that it can also use the du_select and tap_select commands when selecting the riscv core?

[TommyMurphyTM1234]

I didn't think that Pulpino supported OpenOCD for debugging out of the box (or maybe at all)?

• https://github.com/pulp-platform/pulpino?tab=readme-ov-file#interactive-debug
• https://github.com/pulp-platform/debug_bridge/blob/master/README.md
• https://groups.google.com/a/groups.riscv.org/g/debug/c/vx-S6p2x4tY
• https://github.com/riscv/riscv-openocd/issues/312

You probably need to ask about this issue over on the Pulpino project to see if there's any way to use OpenOCD or if that's even appropriate in the first place.

In any case, you haven't provided any real info about what exactly you tried here - e.g. OpenOCD command line, verbose openocd -d3 log etc.

[AdmsLCW]

Thank you very much for your comment. I have also raised the question on the pulpino official website. Below are some screenshots of my information. pupino.cfg run with openocd with -d3

[JanMatCodasip]

Hi @AdmsLCW,

OpenOCD supports the standard RISC-V JTAG DTM interface (debug transport over JTAG, as specified in the section 6.1 of the RISC-V debug specification).

I am sorry but no other interface is currently supported.

[AdmsLCW]

OK, I see

[TommyMurphyTM1234]

run with openocd

There's no error there or in any of the other screenshots so I'm not really sure what your issue is.

BTW logs are generally better than screenshots as not everybody can read the latter easily and they don't facilitate searching etc.

Link to issue posted on Pulpino GitHub for completeness:

• https://github.com/pulp-platform/pulpino/issues/405

[TommyMurphyTM1234]

When I use openocd to connect, I select or1k in the configuration file to connect, but I can't enter the command

What command? When you run OpenOCD interactively as above then there is no facility to enter commands via the console in which OpenOCD was launched. All you get there are log messages from OpenOCD.

If you want to interact with a target via OpenOCD then you need to use something like the OpenOCD telnet interface (for simple, low level debug operations) or run GDB and connect it to the OpenOCD GDB Remote Serial Protocol server (for a more fully featured source level debugging experience). There's also a Tcl interface that can be used to interact with the target using OpenOCD (Jim)Tcl commands/scripts. The OpenOCD documentation explains how to use these options.

• https://openocd.org/doc/html/General-Commands.html
• https://openocd.org/doc/html/GDB-and-OpenOCD.html#GDB-and-OpenOCD

[AdmsLCW]

When I use openocd to connect, I select or1k in the configuration file to connect, but I can't enter the command

What command? When you run OpenOCD interactively as above then there is no facility to enter commands via the console in which OpenOCD was launched. All you get there are log messages from OpenOCD.

If you want to interact with a target via OpenOCD then you need to use something like the OpenOCD telnet interface (for simple, low level debug operations) or run GDB and connect it to the OpenOCD GDB Remote Serial Protocol server (for a more fully featured source level debugging experience). There's also a Tcl interface that can be used to interact with the target using OpenOCD (Jim)Tcl commands/scripts. The OpenOCD documentation explains how to use these options.

• https://openocd.org/doc/html/General-Commands.html
• https://openocd.org/doc/html/GDB-and-OpenOCD.html#GDB-and-OpenOCD

Sorry for replying to your message so late. I used telnet to connect remotely, but I couldn't send the halt command. I used gdb to monitor again, but the log showed that my architecture was different and the connection was rejected. Because I don't know what the architecture of gdbserver and gdb is, and I don't know how to change it, so I can't solve this problem. Regarding the halt command response timeout problem, I suspect that it is caused by the configuration file of or1k that I used. The halt command cannot be interpreted by riscy. Below are some of my logs. I don’t know if there is something wrong with my operation. I plan to use adv_jtag_brige next to see if I can connect to pulpino. I am very much looking forward to your reply.

openocd.log gdb.log telnet.log

[TommyMurphyTM1234]

I used telnet to connect remotely, but I couldn't send the halt command.

What do you mean you couldn't send the halt command? I presume that you could send it but it failed given that this appears in the logs:

# telnet.log
Open On-Chip Debugger                                                                                                  
halt                                                                                                                  
Halt timed out, wake up GDB.                                                                                            

# openocd.log                                                                                                                          
Debug: 1231 10797 command.c:152 script_debug(): command - halt
Debug: 1232 10797 target.c:3268 handle_halt_command(): -
Debug: 1233 10797 or1k.c:570 or1k_halt(): target->state: running
Debug: 1243 10798 or1k_du_adv.c:285 adbg_ctrl_write(): Write control register 0: 0x000000cd
Debug: 1262 10798 target.c:3249 target_wait_state(): waiting for target halted...
Info : 121269 15799 target.c:539 target_poll(): Halt timed out, wake up GDB.
Debug: 121270 15799 target.c:1815 target_call_event_callbacks(): target event 0 (gdb-halt) for core pulpino.cpu
Error: 121271 15799 target.c:3257 target_wait_state(): timed out while waiting for target halted
Debug: 121272 15799 command.c:541 run_command(): Command 'halt' failed with error code -4

Does it make any difference if you increase the timeout?

• https://openocd.org/doc/html/Architecture-and-Core-Commands.html#index-riscv-set_005fcommand_005ftimeout_005fsec

For example:

# While connected to the OpenOCD telnet interface:
riscv set_command_timeout_sec 20
halt

but the log showed that my architecture was different and the connection was rejected

I presume that you're referring to this?

# gdb.log

Admin@LogicComputingWeapon MINGW64 ~
# gdb
GNU gdb (GDB) 13.2
Copyright (C) 2023 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 "x86_64-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
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".
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
warning: Architecture rejected target-supplied description
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
Could not read registers; remote failure reply 'E0E'
(gdb)

As the log states you're running the wrong GDB - the native x86_64 one rather than the RISC-V one.

This GDB was configured as "x86_64-w64-mingw32".

You need to run the correct one - e.g. riscv64-unknown-elf-gdb or similar.

[AdmsLCW]

@TommyMurphyTM1234 I cannot use the riscv command because I created an or1k target. I checked the manual of openocd and only by creating an or1k target can I link to adv_dbg_if. In the openocd manual, I have only seen that riscv has commands to adjust the timeout. My core question is whether I can use the or1k configuration file to link to riscv. If not, how can I link to adv_dbg_if and create a riscv target at the same time. Very much looking forward to your advice.

Open On-Chip Debugger
riscv set_command_timeout_sec 10
invalid command name "riscv"

Before using gdb monitoring with riscv-related architecture, I think I should first solve the configuration problem of openocd. However, JanMatCodasip replied that openocd only supports linking riscv with dtm.（T﹏T）

[TommyMurphyTM1234]

I cannot use the riscv command because I created an or1k target.

Ah - my mistake.

I checked the manual of openocd and only by creating an or1k target can I link to adv_dbg_if. In the openocd manual, I have only seen that riscv has commands to adjust the timeout. My core question is whether I can use the or1k configuration file to link to riscv.

Well, self-evidently you can because you have posted logs that show that you have accessed your RISC-V target this way. Albeit with the halt command seemingly timing out for some reason. You need to investigate and figure out why this happens. Is it, by any chance, a simulated target (e.g. using ModelSim, Verilator etc.)? These are notoriously slow especially for debugging and may need special handling in order to work well - e.g. increasing timeouts where applicable or, where that's not possible, maybe even hacking OpenOCD if necessary.

I still think that the Pulpino community would be better placed to advise on you this as it's more of a Pulpino issue than an OpenOCD issue as far as I can see.

If not, how can I link to adv_dbg_if and create a riscv target at the same time.

You can only do this if the JTAG chain in the target has both sorts of devices. It sounds like the Pulpino does not.

Before using gdb monitoring with riscv-related architecture, I think I should first solve the configuration problem of openocd.

I think you should first try to figure out why halt seems to be timing out.

[AdmsLCW]

I have no good way to find out why the timeout occurs, because the chip may have failed to tape out and the halt gives too little information. I can only build the debugging environment as well as possible. Furthermore, I'm not sure that changing openocd's underlying functions is a correct and efficient way to do it. And it was too hard for me. I will try to find the debugging method from the pulp official website, thank you for your suggestion.

I cannot use the riscv command because I created an or1k target.

Ah - my mistake.

I checked the manual of openocd and only by creating an or1k target can I link to adv_dbg_if. In the openocd manual, I have only seen that riscv has commands to adjust the timeout. My core question is whether I can use the or1k configuration file to link to riscv.

Well, self-evidently you can because you have posted logs that show that you have accessed your RISC-V target this way. Albeit with the halt command seemingly timing out for some reason. You need to investigate and figure out why this happens. Is it, by any chance, a simulated target (e.g. using ModelSim, Verilator etc.)? These are notoriously slow especially for debugging and may need special handling in order to work well - e.g. increasing timeouts where applicable or, where that's not possible, maybe even hacking OpenOCD if necessary.

I still think that the Pulpino community would be better placed to advise on you this as it's more of a Pulpino issue than an OpenOCD issue as far as I can see.

If not, how can I link to adv_dbg_if and create a riscv target at the same time.

You can only do this if the JTAG chain in the target has both sorts of devices. It sounds like the Pulpino does not.

Before using gdb monitoring with riscv-related architecture, I think I should first solve the configuration problem of openocd.

I think you should first try to figure out why halt seems to be timing out.

[TommyMurphyTM1234]

In your earlier log I see this - note the line number (285):

Debug: 1243 10798 or1k_du_adv.c:285 adbg_ctrl_write(): Write control register 0: 0x000000cd

That line does not tally with the latest sources in this repo:

• https://github.com/riscv/riscv-openocd/blob/b6fa69bedd52b76aa8d5115c66ba6cc8c7dd8bf9/src/target/openrisc/or1k_du_adv.c#L285
• https://github.com/riscv/riscv-openocd/blob/b6fa69bedd52b76aa8d5115c66ba6cc8c7dd8bf9/src/target/openrisc/or1k_du_adv.c#L287

Are you sure that you're using the latest OpenOCD?

[TommyMurphyTM1234]

I'm not sure that changing openocd's underlying functions is a correct and efficient way to do it

Temporarily hacking OpenOCD to add extra custom logging or other logic is a perfectly valid way to investigate such issues where there are suspicions that the target hardware may not be functioning correctly. I would consider adding code to check if this write actually took effect (assuming that the register can be read back to check this):

Debug: 1243 10798 or1k_du_adv.c:285 adbg_ctrl_write(): Write control register 0: 0x000000cd

Or - if possible - simply manually write and read back this register via the OpenOCD telnet command interface. If the write and read back shows that the write is working OK then, presumably, there may be an issue with the target actually acting on the requested operation (halt) in which case further investigation would have to be on the target side (e.g. simulation or logic analysis on the actual chip if that's even possible).

[AdmsLCW]

In your earlier log I see this - note the line number (285):

Debug: 1243 10798 or1k_du_adv.c:285 adbg_ctrl_write(): Write control register 0: 0x000000cd

That line does not tally with the latest sources in this repo:

• https://github.com/riscv/riscv-openocd/blob/b6fa69bedd52b76aa8d5115c66ba6cc8c7dd8bf9/src/target/openrisc/or1k_du_adv.c#L285
• https://github.com/riscv/riscv-openocd/blob/b6fa69bedd52b76aa8d5115c66ba6cc8c7dd8bf9/src/target/openrisc/or1k_du_adv.c#L287

Are you sure that you're using the latest OpenOCD?

I'm sure I'm using the latest version of openocd, and I checked the or1k_du_adv.c file and it's the same.

[AdmsLCW]

I'm not sure that changing openocd's underlying functions is a correct and efficient way to do it

Temporarily hacking OpenOCD to add extra custom logging or other logic is a perfectly valid way to investigate such issues where there are suspicions that the target hardware may not be functioning correctly. I would consider adding code to check if this write actually took effect (assuming that the register can be read back to check this):

Debug: 1243 10798 or1k_du_adv.c:285 adbg_ctrl_write(): Write control register 0: 0x000000cd

Or - if possible - simply manually write and read back this register via the OpenOCD telnet command interface. If the write and read back shows that the write is working OK then, presumably, there may be an issue with the target actually acting on the requested operation (halt) in which case further investigation would have to be on the target side (e.g. simulation or logic analysis on the actual chip if that's even possible).

How could I read the value of the register. OpenOCD prompts me that the CPU is not in the halt state and operations are not allowed. The command I use is read_memory. Later,I will try to modify the underlying file.

[TommyMurphyTM1234]

I'm sure I'm using the latest version of openocd, and I checked the or1k_du_adv.c file and it's the same.

I don't understand why there's a line numbering mismatch between the logging and the latest sources so.

How could I read the value of the register. OpenOCD prompts me that the CPU is not in the halt state and operations are not allowed.

That's something that you'll have to ask over at the Pulpino project.

Later,I will try to modify the underlying file.

Probably no point if the memory can't be read when the target isn't halted.

In my opinion it's probably time to revert to simulation of your target to see if/why telling it to halt doesn't work. But, again, the Pulpino community might be better placed to advise on what looks like a target specific rather than an OpenOCD issue.