09:50 <Deneb> could anyone advise on what this means and how to go about fixing it please?

09:50 <Deneb> Error: JTAG-DP STICKY ERROR

09:50 <Deneb> Warn : target bcm2837.cpu0 examination failed

10:30 <PaulFertser> Deneb: it likely means the target CPU is not in a suitable state so can't be talked to properlyy.

10:35 <Deneb> Hmm, the Pi is booting the standard Pi linux OS with a desktop. I removed the SD Card and powered up the Pi without an OS and it nowe tells me that the idcode is wrong (0xfffffffe) which it is. Rer-inserting the card yeildfs the previous error. Clearly it needs to be booted. Would I need a minimal OS installation for this or some specific configuration?

10:54 <PaulFertser> Deneb: I've read that some Cortex-A targets require kernel arguments to prevent CPU from entering idle states. Probably some other tricks are needed with this broadcom soc too.

11:41 <Deneb> PaulFertser: I think I have figured it out. It seems that this Pi has a BCM2836. This device seems to have the same IDCODE as the BCM2837.

11:41 <PaulFertser> Deneb: idcode is only checked during jtag scan interrogation, it doesn't affect examination.

11:42 <Deneb> I copied rpi3.cfg and created an rpi2.cfg and changed the reference to the BCM2837 to BCM2836. I had already tried BCM2835 which did not work due to the different IDCODE.

11:43 <Deneb> using the .cfg file, openocd connects without error.

11:44 <Deneb> I then dug out a Pi3 and used the original rpi3.cfg file and that worked as well. Both sessions read the same IDCODE.

11:44 <Deneb> it would appear the the BCM2836 and BCM2837 have the same IDCODE....

11:45 <Deneb> anyway, it would appear that I can now move on to experimenting with gdb...

11:51 <Deneb> is there such a thing as an IDCODE to part reference? I couldn't find anything on Google but maybe not using the right search terms

12:13 <PaulFertser> Deneb: those JTAG ID codes for ARM targets are usually just indicating the core type (so you can tell apart cortex-m3 from cortex-m4 but not much more).

12:14 <Deneb> ah, that would explain it. They both have the same core. Thanks.

12:15 <Deneb> I can now connect with gdb, but it drops out shortly after target remote :3333. I am just Googling the next error: Error: Invalid ACK (7) in DAP response

12:46 <maribu[m]> I am starting to clean up the qn908x nor flash driver patch. Regarding style, https://openocd.org/doc/doxygen/html/stylec.html is the ultimate source? E.g. if common use, uncrustify and the doc are contradicting each other, I should stay with what the doc says, right?

12:47 <PaulFertser> maribu[m]: it should pass checkpatch.pl first of all. And I'd say common use is more essential.

12:52 <maribu[m]> So in case of switch the doc says cases should have the same indent as the switch statements. (E.g. no double-indent, as the Linux kernel code style says, see https://www.kernel.org/doc/html/v6.1/process/coding-style.html#indentation). But uncrustify wants double indent and a quick grep -R shows double indent. I would go for double indent, right?

12:52 <PaulFertser> OK, 0.12.0-rc3 is done and out, please report if anything's missing or incorrect. borneoa_

12:53 <maribu[m]> And regarding the whitespace between `#define FOO_BAR` and `<SOME-NUMBER>`: The patch currently uses spaces there, while common use seems to be tabs. I should convert to tabs, right?

12:54 <PaulFertser> maribu[m]: uncrustify config haven't been updated in ages. I suggest you just follow the existing recent code and that should be it.

12:55 <maribu[m]> OK, will do :)

12:57 <shibboleth> any progress re openocd-spi?

12:57 <borneoa_> PaulFertser: it's perfect! Thanks

12:59 <PaulFertser> Gerrit feels responsive enough atm, even though the build is ongoing, so looks like those measures helped.

13:20 <borneoa_> PaulFertser: good. I don't have other patch to merge, but I will push a series in next days. I will check how it behaves.

13:38 <Deneb> looks like my gdb installation on this Linux machine supported only the Intel architecture. I needed to install the gdb-multiarch pakage to get support for arm. Running gdb-multiarch now allows me to debug the Pi.

13:38 <Deneb> thanks for your help along the way with this.

16:13 <PaulFertser> karlp: I've set web_sessions maxAge to 1w , so should be good for one week now, you can check it in the cookie.

20:44 <karlp> cool, thanks.

21:38 <maribu[m]> Looks like I messed up cleaning up https://review.openocd.org/c/openocd/+/5584 :-/

21:38 <maribu[m]> First, it created a new review ID: https://review.openocd.org/c/openocd/+/7406

21:39 <maribu[m]> Second, I see lots and lots of merge conflicts. But I double checked that the branch is rebased on top of upstream's master. I have no idea what went wrong there :/

21:42 <maribu[m]> Anyway, I call it a day for now... At least the patch check is passing now.