Debug: Spike tests generate distracting/unnecessary IDCODE warnings/errors

[TommyMurphyTM1234]

When testing against Spike, these OpenOCD scripts are used:

• https://github.com/riscv-software-src/riscv-tests/blob/8f9c68e6d87fa5e058c44bbdb18b129443f3119a/debug/targets/RISC-V/spike-1.cfg#L8
• https://github.com/riscv-software-src/riscv-tests/blob/8f9c68e6d87fa5e058c44bbdb18b129443f3119a/debug/targets/RISC-V/spike-2-hwthread.cfg#L9
• https://github.com/riscv-software-src/riscv-tests/blob/8f9c68e6d87fa5e058c44bbdb18b129443f3119a/debug/targets/RISC-V/spike-2.cfg#L9
• https://github.com/riscv-software-src/riscv-tests/blob/8f9c68e6d87fa5e058c44bbdb18b129443f3119a/debug/targets/RISC-V/spike-multi.cfg#L8-L9

-expected-id 0x10e31913 specifies the IDCODE of the SiFive HiFive1's FE310:

• https://github.com/riscv-software-src/riscv-tests/blob/8f9c68e6d87fa5e058c44bbdb18b129443f3119a/debug/targets/SiFive/HiFive1.cfg#L13

However Spike uses the IDCODE 0xdeadbeef:

• https://github.com/riscv-software-src/riscv-isa-sim/blob/00dfa28cd71326a9b553052bf0160cb76f0e7e07/riscv/jtag_dtm.h#L29

So, the mismatch between the expected and actual IDCODE leads to these distracting warning/error messages:

Info : 79 5 core.c:1133 jtag_examine_chain_display(): JTAG tap: riscv.cpu tap/device found: 0xdeadbeef (mfg: 0x777 (Fabric of Truth Inc), part: 0xeadb, ver: 0xd)
Warn : 80 5 core.c:1133 jtag_examine_chain_display(): JTAG tap: riscv.cpu       UNEXPECTED: 0xdeadbeef (mfg: 0x777 (Fabric of Truth Inc), part: 0xeadb, ver: 0xd)
Error: 81 5 core.c:1133 jtag_examine_chain_display(): JTAG tap: riscv.cpu  expected 1 of 1: 0x10e31913 (mfg: 0x489 (SiFive Inc), part: 0x0e31, ver: 0x1)
Error: 82 5 core.c:1554 jtag_init_inner(): Trying to use configured scan chain anyway...
Debug: 83 5 core.c:1364 jtag_validate_ircapture(): IR capture validation scan
Debug: 84 5 core.c:1421 jtag_validate_ircapture(): riscv.cpu: IR capture 0x01
Warn : 85 5 core.c:1577 jtag_init_inner(): Bypassing JTAG setup events due to errors

I propose chainging the Spike OpenOCD scripts to use -expected-id 0xdeadbeef to match the actual expected IDCODE of this target. Or maybe even -expected-id 0 to skip IDCODE checking altogether in case the Spike IDCODE ever changes?

• https://openocd.org/doc/html/TAP-Declaration.html#:~:text=Disabling%20TAPs.-,%2Dexpected%2Did%20NUMBER,-A%20non%2Dzero

However I suspect that checking for the actual expected IDCODE is better than not checking at all?

Does anybody see any problem with this? If not then I'll prepare a PR.

[aap-sc]

no objections (at least not from me). Another way to tackle the problem would be to introduce a command-line option to spike to set IDCODE for the respected TAP - this may be an overkill though, so I guess changing openocd configuration to mirror spike IDCODE is reasonble

[TommyMurphyTM1234]

no objections (at least not from me).

Thanks @aap-sc.

Another way to tackle the problem would be to introduce a command-line option to spike to set IDCODE for the respected TAP - this may be an overkill though, so I guess changing openocd configuration to mirror spike IDCODE is reasonble

Yes, I was wondering about that too but I guess that such an enhancement to Spike should only be implemented if/when there is a compelling case for it - for general Spike use and/or if it serves some purpose for testing purposes.

[TommyMurphyTM1234]

Addressed by this PR:

• https://github.com/riscv-software-src/riscv-tests/pull/565