Thank you for your answers!
If I understood correctly the intended behavior is for all harts to resume at the specified address. However, maybe you could clarify on the second part of my original question:
What should be done if some targets have already been resumed (e.g., selected hart has been stopped because of a software breakpoint, but others in the SMP group continue to run)? Should an error be reported, or should non-halted hart be 'resumed' at the specified address?
Example (core0.cpu and core1.cpu are in SMP group):
Example (core0.cpu and core1.cpu are in SMP group):
reset halt
targets core0.cpu
targets core0.cpu
bp <some address>
resume
//core0.cpu hits software breakpoint and halts, so core0.cpu is halted, but core1.cpu is still running
resume <some other address>
//Any idea what should happen here?
29.03.2023, 01:19, "Tommy Murphy" <tommy_mur...@hotmail.com>:
> As for address, I don't see that it would ever make sense for all cores to resume at the same address.There are cases where it could make sense. E.g. common startup code executed by all cores (aka RISC-V harts). In fact, a lot of multi-hart RISC-V implementions do exactly that at startup - have all harts execute some common/shared code until such time as initialisation gets them executing different code from different memory regions.,> So if the resume address is specified in a multi-core configuration, then either:
> 1) only that core should resume, or
What do you mean by "that core"?
Aren't all cores treated as a single entity when part of an SMP group, in particular when it comes to halt and resume? The OpenOCD resume command has no way of identifying an individual SMP core and I don't know of any "out of band" mechanism for doing so either?
If an (optional) address is specified to the resume command then, as things stand, it seems correct to me from an OpenOCD perspective for all cores to be resumed at that address. Whether or not that makes sense is the responsibility of the debugger user. :-)
