00:33 <Guest11> Hi. I can find no references to it being discussed, but MounRiver/WCH (China...) is distributing a modified OpenOCD without the license and without the source. MounRiver_Studio_Community_Linux_x64_V110 contains COPYING, et. al for GCC, GDB, etc. but it's not clear they modified it. They absolutely modified OpenOCD to support their SWD thing for

00:33 <Guest11> their CH32V307 and CH32V103 parts. toolchain/OpenOCD/bin/wch-riscv.cfg shows they've added an 'adapter driver wlink' and support for their flash, but that source isn't offered. Support@ http://mounriver.com/ has refused to offer source.  They're supposed to offer source for GCC, Expat, libz and everything else that's GPLed, but it's not clear they

00:33 <Guest11> modified them materially. Without source to their OpenOCD devs, we can't recompile OpenOCD for Pi or Chromebook to load code for their parts. Think the story is the same with thier WCH549 WCH-LINK debugging boards, but there may be RISC-V sauce needed, too. Can you please give them a legal bump to include (and comply with...) COPYING for OpenOCD

00:33 <Guest11> and provide working source?

06:59 <PaulFertser> Guest11: hi

07:00 <PaulFertser> Guest11: how nasty of them :/

07:00 <PaulFertser> Guest11: have you tried contacting them for the source? Unfortunately, I didn't see it published anywhere yet.

07:01 <PaulFertser> Guest11: it's not like OpenOCD devs can give anybody a legal bump :(

08:17 <Haohmaru> so, anything like with "mon xyz" or "monitor xyz" tells gdb to send the "xyz" to the other end (gdb-server (openocd))

08:17 <Haohmaru> right?

08:17 <PaulFertser> Right

08:22 <Haohmaru> "reset halt" uses the chip's RESET pin to externally reset the chip and then tries to prevent it from running its program?

08:31 <PaulFertser> Only if reset_config includes srst.

08:31 <Haohmaru> what's that?

08:31 <PaulFertser> It's a command described in the manual.

08:31 <Haohmaru> i'm basically trying to figure out and document those commands i'm copy/pasting around

08:32 <Haohmaru> i saw the manual, but i'm trying to explain the commands in a way more dumber language ;P~

09:25 <karlp> Guest11: I've already been poking patrick at WCH for sources, and asking him again on their discord.

09:25 <karlp> he's currently not replied,

09:26 <karlp> we've been getting _some_ information regarding the bootloader protocol though, so I have some hopes that this _will_ get resolved, but yes, kinda sucky right now.

09:26 <karlp> bright side, it mostly works? :|

09:26 <Haohmaru> so i just ran gdb --tui .. it's not bad so far

09:26 <Haohmaru> way better than bare CLI

09:26 <Haohmaru> it even syntax highlights the code

09:27 <karlp> oh, nice, there goes cgbd's reason for life ;)

09:30 <rkta> the tui also has different layouts, try 'layout next' or 'la n'

09:32 <Haohmaru> this is the kind of thing where you probably wanna put the terminal in a bigger window

09:32 <Haohmaru> kewl

09:33 <Haohmaru> je suis <optimized out>

16:00 <xloem[m]> Hi #openocd … I’ve been using the flashrom serprog tools to flash plcc32/lpc bios chips to work with coreboot, and I’m running into issues. Is this a problem I could solve with openocd?

16:16 <PaulFertser> xloem[m]: unlikely, flashrom is the tool to flash memory chips

16:16 <PaulFertser> xloem[m]: OpenOCD is handy when you have some FPGA or CPU to control using a debug protocol over JTAG or SWD.

16:18 <xloem[m]> ok thanks

17:37 <djgl> Hi, on my (SWD-only) RK3568 board the SRST line also resets the debug logic. Can I tell OpenOCD somehow that it has to reconnect? When I execute "halt" after "reset" all it does is print the DPIDR register. I need to restart OpenOCD to be able to halt the target. reset_config srst_gates_jtag and srst_pulls_trst don't help.

17:58 <PaulFertser> djgl: hi

17:58 <djgl> hi

17:59 <PaulFertser> djgl: usually if it has issues with talking to the target it re-examines it automatically.

18:00 <PaulFertser> djgl: you can force it manually with $TARGETNAME arp_examine

18:01 <PaulFertser> djgl: you can add that to configure -event reset-deassert-post { ... }

18:01 <PaulFertser> djgl: and if you prepare a config which works with rockchip reliably it would be nice to see it upstreamed.

18:04 <djgl> PaulFertser, arp_examine doesn't help. I see that openocd defers executing arp_examine on the sleeping cores after reset, so I guess it already executes it on the running core.

18:05 <PaulFertser> djgl: you can see the current target and the list of all targets with "targets" command.

18:05 <PaulFertser> And you should be able to force arp_examine on any of them.

18:09 <djgl> PaulFertser, on the other other three cores arp_examine works and prints the number of breakpoints and watchpoints, but I am still unable to halt the cores.

18:10 <PaulFertser> djgl: do you select them with "targets" command prior to trying to halt?

18:11 <djgl> I use them in an smp configuration. halt tries to halt them all and it works before I execute reset

18:13 <PaulFertser> djgl: probably you need to arp_examine all of them after reset before trying another halt.

18:13 <djgl> PaulFertser, if I don't use smp, I can halt the other cores after arp_examine

18:15 <djgl> Maybe I need more "adapter srst delay"?

18:16 <djgl> no...

18:17 <djgl> ok, then maybe also -defer-examine the first core...

18:20 <PaulFertser> fwiw you can try running OpenOCD with -d3 and see what it does differently on startup compared to manual arp_examine calls you do later.

18:20 <PaulFertser> In this case there's also cross-trigger interface involved, probably it's that one that needs some additional examination.

18:22 <PaulFertser> djgl: in aarch64_examine you might want to patch out condition after " don't re-probe hardware after each reset "

18:23 <PaulFertser> djgl: have you tried instead of using SRST triggering a watchdog reset, does it also reset debug logic?

18:23 <djgl> PaulFertser, I'll look into it

18:24 <djgl> PaulFertser, new problem: when I -defer-examine the first core and then do arp_examine after reset, I get "Could not find APB-AP for debug access". It works before reset.

18:31 <djgl> PaulFertser, thank you for your help. I guess I will spend more time on this this weekend.

18:31 <PaulFertser> djgl: my other two ideas might provide more food for thought.

18:31 <PaulFertser> djgl: it's clear from the code that first startup is special, so you can easily make it not special.

18:32 <PaulFertser> And in case watchdog reset doesn't reset debug then it'd be the best option I guess. And you can trigger watchdog by suitable mdw command or two.

18:37 <djgl> PaulFertser, before I connected the SRST line I tried to perform a reset like U-Boot does (write 0xfdb9 to 0xfdd200d4), but it had a similar effect. Also I wanted a way to reset the board that works even when the Cortex-A55 cores no longer respond and Rockchip didn't add a MEM-AP with access to the normal address space.

18:40 <djgl> Rockchip also missed the opportunity to use a JTAG-AP to debug the RISC-V on that chip through SWD, but that's another story.

18:40 <PaulFertser> djgl: I see. So probably that's another case where OpenOCD needs some special tweak. Good luck with your debugging btw.

18:40 <PaulFertser> OpenOCD doesn't support JTAG-AP anyway.