Openocd config about connecting two CPUs through a daisy chain

[lz-bro]

Assuming the connection method of the daisy chain is tdi ->cpu0->cpu1->tdo
my config is:

adapter driver jlink
transport select jtag
adapter speed  2000

bindto 0.0.0.0
gdb_port  1024

set _CHIPNAME_0 cpu1
set _CHIPNAME_1 cpu0

jtag newtap $_CHIPNAME_0 cpu -irlen 5 -expected-id 0x10000E21
jtag newtap $_CHIPNAME_1 cpu -irlen 5 -expected-id 0x10000E21

set _TARGETNAME_0 $_CHIPNAME_1.cpu
set _TARGETNAME_1 $_CHIPNAME_0.cpu
target create $_TARGETNAME_0 riscv -chain-position $_TARGETNAME_0 -coreid 0
target create $_TARGETNAME_1 riscv -chain-position $_TARGETNAME_1 -coreid 1

$_TARGETNAME_0 configure -event examine-end {
    # write register, enable cpu1
    #mww 0x418080220 0x1
    mww 0x418082200 0x0
    mww 0x418082200 0x1
    mww 0x418082220 0x0
    mww 0x418082220 0x1
}

foreach t [target names] {
     targets $t
     riscv set_mem_access progbuf
}

Error log show:

Info : 1614 63 riscv-013.c:2139 examine(): [cpu0.cpu] Examined RISC-V core; found 1 harts
Info : 1615 63 riscv-013.c:2141 examine(): [cpu0.cpu]  XLEN=64, misa=0x800000000094112f
User : 1616 63 target.c:724 target_examine_one(): [cpu0.cpu] Target successfully examined.
Debug: 1617 63 target.c:1815 target_call_event_callbacks(): target event 21 (examine-end) for core cpu0.cpu
Debug: 1618 63 target.c:5049 target_handle_event(): target(0): cpu0.cpu (riscv) event: 21 (examine-end) action: 
    # write register, enable cpu1
    mww 0x418080220 0x1
    mww 0x418082200 0x0
    mww 0x418082200 0x1
    mww 0x418082220 0x0
    mww 0x418082220 0x1

....

Debug: 3397 109 riscv.c:1717 riscv_examine(): [cpu1.cpu] Starting examination
Debug: 3407 109 riscv.c:406 dtmcontrol_scan(): DTMCONTROL: 0x0 -> 0x7101
Debug: 3408 109 riscv.c:1731 riscv_examine(): [cpu1.cpu] dtmcontrol=0x7101
Debug: 3409 109 riscv.c:1733 riscv_examine(): [cpu1.cpu] version=0x1
Debug: 3410 109 riscv-013.c:2757 init_target(): [cpu1.cpu] Init.
Debug: 3411 109 riscv-013.c:1866 examine(): [cpu1.cpu] dbgbase=0x0
Debug: 3421 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x0 -> 0x7101
Debug: 3422 109 riscv-013.c:1874 examine(): [cpu1.cpu] dtmcontrol=0x7101
Debug: 3423 109 riscv-013.c:1875 examine(): [cpu1.cpu] dtmcs=0x7101 {version=1_0 idle=7 errinfo=not_implemented abits=0x10}
Debug: 3424 109 riscv-013.c:758 check_dbgbase_exists(): [cpu1.cpu] Searching for DM with DMI base address (dbgbase) = 0x0
Debug: 3425 109 riscv-013.c:254 get_dm(): [cpu1.cpu] Coreid [1] Allocating new DM
Debug: 3426 109 riscv-013.c:497 dmi_scan(): [cpu1.cpu] reset_delays_wait done
Debug: 3436 109 riscv-013.c:397 dump_field(): 50b w 00000000 @10 -> + 00000000 @00; 0i
Debug: 3437 109 riscv-013.c:405 dump_field(): write: dmcontrol=0 {}
Debug: 3447 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 0i
Debug: 3448 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=1, ac_busy_delay=0
Debug: 3458 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3468 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 1i
Debug: 3469 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=2, ac_busy_delay=0
Debug: 3479 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3489 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 2i
Debug: 3490 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=3, ac_busy_delay=0
Debug: 3500 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3510 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 3i
Debug: 3511 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=4, ac_busy_delay=0
Debug: 3521 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3531 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 4i
Debug: 3532 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=5, ac_busy_delay=0
Debug: 3542 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3552 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 5i
Debug: 3553 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=6, ac_busy_delay=0
Debug: 3563 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3573 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 6i
Debug: 3574 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=7, ac_busy_delay=0
Debug: 3584 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3594 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 7i
Debug: 3595 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=8, ac_busy_delay=0
Debug: 3605 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3615 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 8i
Debug: 3616 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=9, ac_busy_delay=0
Debug: 3626 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01
Debug: 3636 109 riscv-013.c:397 dump_field(): 50b - 00000000 @10 -> b 00000000 @10; 9i
Debug: 3637 109 riscv-013.c:466 increase_dmi_busy_delay(): [x100.cpu] dtmcs_idle=7, dmi_busy_delay=10, ac_busy_delay=0

I would like to know if my config is written correctly, thank you!

[TommyMurphyTM1234]

What's the issue?
There's no error in the log.
You probably need to capture and attach (ideally don't just copy and paste it) the full verbose log.

[lz-bro]

What's the issue? There's no error in the log. You probably need to capture and attach (ideally don't just copy and paste it) the full verbose log.

debug.log

[en-sc]

The only issue I see with the config:

target create $_TARGETNAME_1 riscv -chain-position $_TARGETNAME_1 -coreid 1

-coreid is interpreted as hartid (index on the DM) on RISC-V targets, so it really should be zero if you have two harts on separate DMs.

However, this does not explain why the behavior is what it is.

What I see from the log:

1. The first hart is accessible.
2. The sequence of memory writes intended to enable the second hart is executed successfully.
3. OpenOCD is able to communicate with the second TAP (dtmcs is readable).
4. However, the attempt to enable the second hart fails (writing dmcontrol with zero to reset is results in dmi.busy being stuck).

So my best guesses for what is wrong are:

1. The sequence of memory writes is incorrect and does not enable the second core.
2. Maybe you should add a delay after running the sequence?

[TommyMurphyTM1234]

Maybe not significant but the numbering of items seems a bit confusing:

set _CHIPNAME_0 cpu1
set _CHIPNAME_1 cpu0

set _TARGETNAME_0 $_CHIPNAME_1.cpu
set _TARGETNAME_1 $_CHIPNAME_0.cpu

Should this actually be:

set _CHIPNAME_0 cpu0
set _CHIPNAME_1 cpu1

set _TARGETNAME_0 $_CHIPNAME_0.cpu
set _TARGETNAME_1 $_CHIPNAME_1.cpu

What is the nature of/context for the following?

$_TARGETNAME_0 configure -event examine-end {
    # write register, enable cpu1
    #mww 0x418080220 0x1
    mww 0x418082200 0x0
    mww 0x418082200 0x1
    mww 0x418082220 0x0
    mww 0x418082220 0x1
}

What is the nature of your RISC-V target? E.g. simulated HDL implementation? FPGA implementation? ASIC/actual silicon implementation? Etc.?

[TommyMurphyTM1234]

These lines in the log seem odd to me:

Line   19: Debug: 24 0 command.c:152 script_debug(): command - jtag newtap cpu1 cpu -irlen 5 -expected-id 0cpu100E21
Line   22: Debug: 27 0 command.c:152 script_debug(): command - jtag newtap cpu0 cpu -irlen 5 -expected-id 0cpu100E21
Line  152: Info : 238 31 core.c:1133 jtag_examine_chain_display(): JTAG tap: cpu1.cpu tap/device found: 0cpu100e21 (mfg: 0x710 (SpacemiT (Hangzhou)Technology Co Ltd), part: 0x0000, ver: 0x1)
Line  153: Info : 239 31 core.c:1133 jtag_examine_chain_display(): JTAG tap: cpu0.cpu tap/device found: 0cpu100e21 (mfg: 0x710 (SpacemiT (Hangzhou)Technology Co Ltd), part: 0x0000, ver: 0x1)

0cpu100e21 doesn't look like a valid 32-bit IDCODE to me.

[en-sc]

0cpu100e21 doesn't look like a valid 32-bit IDCODE to me.

AFAIU, this is the result of search & replace x100->cpu1.

Can also be observed by comparing the lines in description and in the log:

Debug: 3458 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01

Became

Debug: 3458 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0cpu100 -> 0x7d01

[TommyMurphyTM1234]

0cpu100e21 doesn't look like a valid 32-bit IDCODE to me.

AFAIU, this is the result of search & replace x100->cpu1.

Can also be observed by comparing the lines in description and in the log:

Debug: 3458 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0x10000 -> 0x7d01

Became

Debug: 3458 109 riscv-013.c:455 dtmcontrol_scan(): DTMCS: 0cpu100 -> 0x7d01

Maybe so - but it would be clearer if the original/unmodified log was provided to avoid confusion.

[lz-bro]

yes ，I made two replace and it caused some misunderstanding

[lz-bro]

Maybe not significant but the numbering of items seems a bit confusing:

set _CHIPNAME_0 cpu1
set _CHIPNAME_1 cpu0

set _TARGETNAME_0 $_CHIPNAME_1.cpu
set _TARGETNAME_1 $_CHIPNAME_0.cpu

Should this actually be:

set _CHIPNAME_0 cpu0
set _CHIPNAME_1 cpu1

set _TARGETNAME_0 $_CHIPNAME_0.cpu
set _TARGETNAME_1 $_CHIPNAME_1.cpu

What is the nature of/context for the following?

$_TARGETNAME_0 configure -event examine-end {
    # write register, enable cpu1
    #mww 0x418080220 0x1
    mww 0x418082200 0x0
    mww 0x418082200 0x1
    mww 0x418082220 0x0
    mww 0x418082220 0x1
}

What is the nature of your RISC-V target? E.g. simulated HDL implementation? FPGA implementation? ASIC/actual silicon implementation? Etc.?

FPGA implementation

[TommyMurphyTM1234]

You didn't address all of the questions that I asked in an attempt to clarify matters.

Apropos of what @en-sc said previously it may be that the operations intended to enable the second CPU are not implemented appropriately and this may be why you get the timeout.

However without more detailed information about your target (e.g. the exact memchanism that enables the second CPU etc.) it's difficult for anybody else here to give informed advice.