Closed lz-bro closed 1 week ago
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.
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.
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:
dtmcs
is readable).dmcontrol
with zero to reset is results in dmi.busy
being stuck).So my best guesses for what is wrong are:
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.?
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.
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
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.
yes ,I made two replace and it caused some misunderstanding
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
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.
Assuming the connection method of the daisy chain is tdi ->cpu0->cpu1->tdo my config is:
Error log show:
I would like to know if my config is written correctly, thank you!