On Mon, Jan 6, 2020 at 9:06 PM Tim Newsome <[email protected]> wrote:
>
> I have a RISC-V target with 2 TAP controllers chained together. The first 
> controller connects to a core that's always accessible. The second controller 
> connects to a core that's only accessible after the first core has done some 
> setup, which (at least initially) requires the debugger.
>
> If I just configure both of those and connect then OpenOCD errors out because 
> examine() fails on the core behind the second controller because it's not 
> powered up yet. How can I change the code to make this case work? Is there an 
> example for some other target?
>
> Tim

Hi Tim,

I did something similar in the past for a Cortex-A plus Cortex-M in
the same SoC.
The core that is not accessible at reset or at debugger connection is
created in the tcl script as:
target create TARGETNAME ... -defer-examine
Then somewhere in the tcl code, for example in one event handler, you
can trigger the examination of the core with:
TARGETNAME arp_examine

I do not have right now an example to share, but there is nothing
special on top of what I already explained.
Then, where to "arp_examine" the target is really SoC dependant.

Another example I run in the past was a multi Cortex-A in SMP.
The number of cores was depending on chip sub-version, and I want to
detect it at runtime.
So I created the maximum number of cores, all but one having "-defer-examine".
In the event examine-end of the only always-active core and in the
event reset-end I go to read the chip ID and then arp_examine the
other available cores.

Unfortunately there is no hook in OpenOCD to "dynamically" disable one
core, e.g. to handle special power modes.

Antonio


_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to