OpenOCD assumes hartid and hart index are the same

[timsifive]

No description provided.

[mwachs5]

How does OpenOCD use hartid? I mean, how does this issue come up?

[timsifive]

Currently upon startup OpenOCD will eg. display:

Info : Examined RISC-V core; found 2 harts
Info :  hart 0: XLEN=64, misa=0x8000000000141129
Info :  hart 1: XLEN=64, misa=0x8000000000141129

That's really the hart index, though. And the source uses hartid everywhere, and that should be clarified.

This is not high-priority, but I think it's worth tracking.

[aap-sc]

@en-sc is it still the case?

[TommyMurphyTM1234]

@en-sc is it still the case?

I don't think that this format of output occurs anymore.

Currently upon startup OpenOCD will eg. display:

Info : Examined RISC-V core; found 2 harts
Info :  hart 0: XLEN=64, misa=0x8000000000141129
Info :  hart 1: XLEN=64, misa=0x8000000000141129

I can't see that the per-hart info is logged at all other than the number of detected harts:

cd src/target/riscv

grep "LOG.*hart" *
riscv-013.c:			LOG_TARGET_ERROR(target, "Couldn't place hart in halt group 0. "
riscv-013.c:			LOG_TARGET_ERROR(target, "Couldn't place hart back in halt group %d. "
riscv-013.c:		LOG_TARGET_DEBUG(target, "Detected %d harts.", dm->hart_count);
riscv-013.c:		LOG_TARGET_ERROR(target, "No harts found!");
riscv-013.c:	LOG_TARGET_DEBUG(target, "Waiting for hart to come out of reset.");
riscv-013.c:		LOG_TARGET_ERROR(target, "No harts were prepped!");
riscv-013.c:	LOG_TARGET_DEBUG(target, "halting hart");
riscv.c:	LOG_TARGET_DEBUG(target, "prep hart, debug_reason=%d", target->debug_reason);
riscv.c:	LOG_TARGET_DEBUG(target, "halting all harts");
riscv.c:	LOG_TARGET_DEBUG(target, "Polling all harts.");
riscv.c:		LOG_TARGET_WARNING(target, "%d harts should remain halted, and %d should resume.",
riscv.c:	LOG_TARGET_DEBUG(target, "stepping hart");
riscv.c:		LOG_TARGET_ERROR(target, "Unable to step rtos hart.");
riscv.c:	LOG_TARGET_DEBUG(target, "Resuming hart, state=%d.", target->state);
riscv.c:		LOG_TARGET_ERROR(target, "Can't save register %s on a hart that is not halted.",

grep "LOG.*Exam" *
riscv-011.c:	LOG_INFO("Examined RISCV core; XLEN=%d, misa=0x%" PRIx64,
riscv-013.c:	LOG_TARGET_INFO(target, "Examined RISC-V core");

[en-sc]

@aap-sc, I'm not sure what Tim meant by 'hart index' and 'hartid'.

We have 4 similar concepts:

1. Target index in target list (i.e. the one that can be used instead of target's name in targets TCL command).
   • specified by the order in which targets are created.
   • starts from zero
   • contiguous
2. Target's coreid configuration parameter.
   • user specified, defaults to zero.
   • no restrictions :)
3. Hart index on the DM (as described in [3.3. Selecting Harts]) (i.e. what to write to 'hartsel' to select that hart).
   • starts from zero
   • contiguous
4. Value of mhartid CSR
   • at least one is zero (not necessarily on this DM though)
   • unique, but not necessarily contiguous.

First of all, (3) and (4) are not related in any way. In fact, AFAIK, (4) is not used by OpenOCD in any meaningful way.

User-specified (2) is used as (3). I think this is what Tim meant and it still holds true.

riscv-openocd/src/target/riscv/riscv-013.c

Line 2174 in 40cda81

info->index = target->coreid;

This makes the relations between the first three a bit complicated :).

• (a) One DM per TAP, one hart per DM:
  • coreid (2) on all targets should be zero.
  • Though for now if a user specifies coreid to some other value, it is silently ignored due to WARL nature of 'hartsel' :).
• (b) One DM per TAP, multiple harts per DM.
  • coreids should start from zero and be contiguous for each TAP.
  • If a user mistakes and two harts on one DM get the same coreid... Well, let's not think about it.
• (c) Multiple DMs per TAP.
  • Now coreid enumerates targets (starts from zero, contiguous) on the same TAP with the same dbgbase.
  • If there are two targets on the same TAP with same dbgbase and same coreid...

The cherry on top is, the whole coreid and dbgbase configuration is not necessary.
Usecase where none of them is specified can be supported with just filling-up DMs on each TAP as requested (with target index (1) determining where each hart goes). IMHO, this is a nice and easy-to-use default.

TLDR:

IMHO, while the issue is not clearly described, it is valid and should be left open.

[TommyMurphyTM1234]

@aap-sc, I'm not sure what Tim meant by 'hart index' and 'hartid'.

I'm pretty sure that by "index" he meant the index of the array/list that OpenOCD uses (or maybe used in the past?) internally to store hart info whereas the "hartid" is the actual Hart identifier and the two may not be the same number. For example the spec says that one hart must have the ID 0 but otherwise hart IDs just have to be unique and are not necessarily contiguous or monotonically incrementing:

Volume II: RISC-V Privileged Architectures V20211203 - 3.1.5 Hart ID Register mhartid

Hart IDs might not necessarily be numbered contiguously in a multiprocessor system, but at least one hart must
have a hart ID of zero. Hart IDs must be unique within the execution environment.

Actually "at least" doesn't look correct if exactly one hart must have an ID of zero?

• mhartid wording re. hart ID zero confusing/incorrect? riscv/riscv-isa-manual#1446