15:50 <electricworry> I'm trying to get single-stepping to work on a Raspberry Pi 2B. Unfortunately when using `step` in openocd it just continues - doesn't halt on the next instruction and I get "timeout waiting for target halt".

15:50 <electricworry> I found something interesting. Hacking away at corex_a.c I changed stepbreakpoint in cortex_a_step() to be BKPT_HARD. If I run that once, openocd crashes (because a pointer to a buffer for orig_instr has not been set). But interestingly if I reverse that change and run openocd again, single-stepping is working.

15:51 <electricworry> ** Sorry, I meant I changed stepbreakpoint to be BKPT_SOFT which caused the crash - then back to BKPT_HARD.

15:51 <electricworry> Anyway, any ideas of why this might be correcting the issue?

15:54 <electricworry> My starting point is a spinlock which is the first thing executed in my kernel7.img, because I want to be able to step from there through my code.

16:52 <PaulFertser> Hi electricworry

16:54 <PaulFertser> This is an unusual observation and it's strange it affects just that corte-a target.

16:54 <PaulFertser> Please stay on channel, I hope some people more experienced in Cortex-A will chime in.

17:05 <electricworry> I will, thanks. I figured that one of the following is true: (a) Single-stepping RPi2B should work, in which case I've got something wrong in my configuration, and my antics has had a side-effect of fixing it.

17:06 <electricworry> (b) It's known to not work and no-one's solved it yet, in which case maybe I've stumbled upon a workaround of sorts? :)

17:15 <PaulFertser> electricworry: you haven't specified what version you're using and whether it's upstream config and what jtag or swd adapter is involved, sometimes that plays a role.

17:15 <PaulFertser> electricworry: you can also enable -d3 logging in OpenOCD and check what's happening on "step" (or "stepi" in GDB) against ARM Debug Interface document.

17:18 <PaulFertser> electricworry: in general single-stepping should work on all targets and I haven't heard about any issues in that regard on RPi or other Broadcom ARM.

17:19 <PaulFertser> There's also a chance the communication is unstable due to signal integrity issues, then the results can be randomly surprising.

17:33 <electricworry> Indeed, I've been brief so far. I'll report back once I get a repo set up with my config.

17:41 <PaulFertser> What is spinlock waiting on, how many instructions is it?

17:46 <electricworry> It's just "_start:

17:46 <electricworry> @ Wait for JTAG

17:46 <electricworry> b _start"

17:46 <electricworry> wfe

17:46 <electricworry> The idea being it'll loop there until I patch "b _start" to a nop.

18:10 <PaulFertser> electricworry: hm, but is icache is enabled or something else that might affect it?

18:11 <PaulFertser> electricworry: have you tried to "reg pc <address after b>" and then stepping?

18:15 <electricworry> I'll gather information into a repo so that it should be easier to explain. Unfortunately git.savannah.nongnu.org is down at the moment so my progress has gone to zero.

18:37 <PaulFertser> electricworry: you can wait for JTAG wth software breakpoint instruction, and probably even using semihosting to print something with it.

18:45 <electricworry> PaulFertser: I've put things in https://github.com/electricworry/openocd-raspberry-pi-2b. The makefile shows that I'm building openocd from source (it's tagged at version 0.12.0), and also the config files I'm using to run openocd.

18:46 <electricworry> And the code I'm executing on the RPi is in kernel/boot.S, extremely trivial. The README.md in the root shows what's happening.

18:47 <electricworry> In answer to your questions, I've tried "reg pc 0x8008; step" per your suggestion, but no improvement. Once I've halted, it indicates that icache is disabled.

18:47 <electricworry> I don't know if my openocd config is sane. I gathered that from various blogs that weren't demonstrating that anything actually worked well.

18:55 <PaulFertser> electricworry: you should normally use current git HEAD of OpenOCD (0.12.0 was released way too long ago) and configs that come with it, not from blogs.

18:57 <electricworry> Understood. Let me revise and try again.

19:08 <electricworry> There's no configuration for a Raspberry Pi 2 in the openocd repo.

19:26 <electricworry> Ok, so I switched over to a Raspberry Pi 3B, and used the configs from the distro. All good there. I'll work back from that and see if I can get the 2B working.

19:44 <electricworry> Thanks for your help. In summary a Raspberry Pi 3 works fine, but the problem with single-stepping always happens on a Raspberry Pi 2. I just updated the repo.

19:46 <electricworry> I'm using the configs from master for the FTDI FT2232H and I copied the rpi3.cfg to make a rpi2.cfg (just changing the target from bcm2837 to bcm2836).

21:02 <PaulFertser> Hm, that's strange indeed

22:02 <electricworry> I'm inclined to move on work with the RPi3 as I need to make some progress, but should I perhaps send a detailed question to the mailing list?

22:05 <PaulFertser> electricworry: worth a try at this point, sure, to the -devel one.

22:12 <electricworry> PaulFertser: Thanks again. Bed time.