Hi Oleh,
Thanks for reporting the issue.
The old code, before commit 6c0151623cb09da6a80655cedf568db927ae2d93,
was simply sending the reset pulse, then halting the target.
But actually halting it randomly, somewhere during the target's boot
process. No guarantee to halt it at the very first instruction after
reset vector. I would even say _never_ halting it at the reset vector.
In your first dump it's reported
soc.cpu0: ran after reset and before halt ...
because openocd finds the target running, even if the "reset halt"
command is used.
Most aarch64 targets (and many cortex_a targets too) implement some secure
boot. This prevents halting the target at the reset vector, so "reset halt"
is not supposed to have the desired effect.
Plus, some boards further enforces, in HW, the secure boot by causing
a power cycle to the SoC when a reset is detected.
The power cycle guarantees that the SoC restarts, after a reset, as it
was just powered up.
For me this is what causes the message in your first dump
Debug regions are unpowered, an unexpected reset might have happened
JTAG-DP STICKY ERROR
OpenOCD finds the whole DAP resetted and needs to restart a few things.
But as you report after the commit
6c0151623cb09da6a80655cedf568db927ae2d93 there is something weird.
First of all, please try with the additional parameter
"srst_gates_jtag" to command "reset_config".
It should be the default, but I don't know if your board config file
sets "srst_nogate" that will not work for you.
If the above does not help, try to swap in aarch64_deassert_reset() the
lines a) retval = aarch64_poll(target);
b) retval = aarch64_init_debug_access(target);
Before the "bad" commit the order was a) then b), which is illogical
because we cannot poll the target if the debug port is not
initialized.
After the commit the order is b) then a).
I suspect that running b) as first is not able to fully initialize the
debug port after a power cycle. The old illogical code probably causes
a) to fail, forcing b) to well initialize the debug port.
Antonio
On Thu, Jan 20, 2022 at 1:48 PM Oleh Kravchenko <o...@kaa.org.ua> wrote:
Hello Christian,
I've found that this commit 6c0151623cb09da6a80655cedf568db927ae2d93
breaks `reset halt` for my aarch64.>
Here is there log before this patch:
Open On-Chip Debugger
reset halt
JTAG tap: soc.cpu tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd),
part: 0xba00, ver: 0x5) Debug regions are unpowered, an unexpected
reset might have happened JTAG-DP STICKY ERROR
soc.cpu0: ran after reset and before halt ...
soc.cpu0 cluster 0 core 0 multi core
soc.cpu0 halted in AArch64 state due to debug-request, current mode:
EL3H
cpsr: 0x0000024d pc: 0xffff005c
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Here is there log after this patch:
Open On-Chip Debugger
reset halt
JTAG tap: h32ax76.cpu tap/device found: 0x5ba00477 (mfg: 0x23b (ARM
Ltd), part: 0xba00, ver: 0x5) Debug regions are unpowered, an
unexpected reset might have happened JTAG-DP STICKY ERROR
Debug regions are unpowered, an unexpected reset might have happened
JTAG-DP STICKY ERROR
Currently my openocd source tree looks like:
On top of ae6de2f93d960c7d35e8d4c86d9c17dda17c561e I've revert commit of
6c0151623cb09da6a80655cedf568db927ae2d93.
Can I help with fix that?
