Antonio, Oleh, Tarek there's a patch series in my outgoing queue for quite a while that contain fixes for aarch64 and reset-halt. Maybe you want to check if any of these are still applicable. They're quite old, not easy to rebase, I'm afraid. Unfortunately I have no access to ARMv8 targets at the moment and little time to work on openocd. But maybe there's something there that could still be helpful.
The patches are all tagged with "reset". BR, Matthias On Freitag, 21. Januar 2022 15:48:10 CET Antonio Borneo wrote: > 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? > > > > -- > > Best regards, > > Oleh Kravchenko
