sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
bohdan-tymkiv has joined #openocd
v0|d has joined #openocd
bohdan-tymkiv has quit [Ping timeout: 256 seconds]
HelloShitty has quit [Ping timeout: 240 seconds]
bohdan-tymkiv has joined #openocd
HelloShitty has joined #openocd
Bertl_zZ is now known as Bertl
emeb has joined #openocd
jybz has quit [Ping timeout: 260 seconds]
jybz has joined #openocd
Hawk777 has joined #openocd
Guest30 has joined #openocd
<Guest30>
Hello guys! Starting from this commit 6c0151623cb09da6a80655cedf568db927ae2d93 I'm not able to use OpenOCD with AArch64. Any ideas? Or better to make contact with author of this commit?
<PaulFertser>
Guest30: hi
<PaulFertser>
Guest30: what exactly stopped working?
<Guest30>
reset halt :)
<Guest30>
Debug regions are unpowered, an unexpected reset might have happened JTAG-DP STICKY ERROR TARGET: cpu0 - Not halted
<PaulFertser>
Guest30: but probably it wasn't really working before either? And you should get the same as before with "reset; halt".
<Guest30>
it worked: cpu0: ran after reset and before halt ...; cpu0 halted in AArch64 state due to debug-request, current mode: EL3H
<PaulFertser>
Guest30: if you saw that "ran after reset and before halt" it means the CPU wasn't really stopped at reset vector so you can't really say it was working ;)
<Guest30>
Well, I was able to load u-boot over JTAG. Now I can't :-/
<PaulFertser>
Guest30: what happens if you do "reset; halt"?
<Guest30>
One sec
<Guest30>
Target not examined yet
<PaulFertser>
Guest30: btw, what reset_config are you using?
<Guest30>
reset_config trst_and_srst
<PaulFertser>
Guest30: what leads to target not examined: reset or halt?
<Guest30>
reset
<Guest30>
after 'halt' I see: JTAG-DP STICKY ERROR
<PaulFertser>
Guest30: when you just start OpenOCD is it able to examine the target?
<Guest30>
it prints: hardware has 6 breakpoints, 4 watchpoints
<PaulFertser>
Guest30: and then are you able to "halt"?
<Guest30>
yes, I'm able :)
<PaulFertser>
Without errors I mean
<PaulFertser>
And if you do "reset" afterwards do you get that target not examined?
<Guest30>
without errors.
<Guest30>
then I do reset and get error
<PaulFertser>
Guest30: so I would guess "reset" (aka "reset run") before that commit wasn't working either.
<Guest30>
It works
<Guest30>
I mean it worked before 6c0151623cb09da6a80655cedf568db927ae2d93
<PaulFertser>
Guest30: you said "reset halt" kind of worked there, but did "reset run" work?
<Guest30>
yes, it works before 6c0151623cb09da6a80655cedf568db927ae2d93.
bohdan-tymkiv has quit [Ping timeout: 256 seconds]
<PaulFertser>
Guest30: reading that commit, do you see anything that might have any effect on non-halt case?
<Guest30>
Let's summarize - After 6c0151623cb09da6a80655cedf568db927ae2d93 `reset halt` and `reset run` doesn't work.
<Guest30>
I'm not experienced with JTAG and AArch64 development to say something useful about this commit.
<PaulFertser>
Guest30: and my question is: did "reset run" work on 6c0151623cb09da6a80655cedf568db927ae2d93^ ?
nerozero has joined #openocd
bohdan-tymkiv has joined #openocd
<Guest30>
Yes, it work
nerozero has quit [Ping timeout: 268 seconds]
<PaulFertser>
Guest30: I suggest you create a ticket for this issue. Make sure you include -d3 logs both for the working and not-working versions while attempting to do what you need.
bohdan-tymkiv has quit [Remote host closed the connection]
<PaulFertser>
Guest30: I guess. Probably your target doesn't support "reset halt" at all so that can't work. What's that SoC?
<Guest30>
Ambarella
<PaulFertser>
Heh. I heard they violate GPL
<PaulFertser>
Guest30: are you hacking some IP cams?
<PaulFertser>
Guest30: in any case I wouldn't be surprised if some Cortex-A devices can't and never will support "reset halt".
<Guest30>
Hehe :) No, porting U-boot to it
<Guest30>
Could you please give more details about never will support? Why?
<PaulFertser>
Guest30: reset halt means that the SoC must be fully reset but at the same time the debug circuity in CPU should remain its state so that the "vector catch" would work to halt the target at reset vector.
<PaulFertser>
Guest30: some vendors do not implement that because they want to run secret ROM bootloader on reset
<PaulFertser>
Guest30: some just hardwire reset in a silly way so that it resets everything
<Guest30>
Can I use OpenOCD to workaround this?
<Guest30>
I mean, reset is really works. Maybe it resets everything, that okay for me. Can I prepare some gdbinit script to simplify development?
<PaulFertser>
Guest30: if you can load and run u-boot after that "halt" you showed then it's enough of a workaround.
<PaulFertser>
Guest30: I also suggest to retry "reset; halt"
<Guest30>
This works! reset; cpu0 arp_examine; halt
<PaulFertser>
Probably it's as good as it gets with this target.
<Guest30>
Can I use some target -event to automate this?
<PaulFertser>
Guest30: it's probably easier to use "monitor reset; cpu0 arp_examine; halt" in your GDB script
<Guest30>
`adapter srst delay 10` have some impact on this too
<PaulFertser>
It might of course
<PaulFertser>
If your target takes some time to come up after reset you might want higher delay.
<PaulFertser>
But if it resets all debug then it needs to be reexamined anyway.
<Guest30>
Hm, with the latest master branch OpenOCD works much better. Previous sometimes with gdb was failed generate valid backtrace and read local/global variables.
<PaulFertser>
Some devs are working hard on improving it :)
<Guest30>
:D I will donate
<PaulFertser>
You can also help by sending and reviewing patches on Gerrit.
<Guest30>
Sure, I will send and it will be done :)