Re: 'aarch64: add support for "reset halt"' actually breaks reset halt

[Antonio B. <bor...@gm...>]

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 <ol...@ka...> 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?
>
> --
> Best regards,
> Oleh Kravchenko