13:59 <jjulian> PaulFertser: Just wanted to say hi and thanks again. We managed to get the JTAG going. Apart from the r32/38 JTAG switch, there is a so called JTAG hub, which is encoding JTAG transfers within DR scans. Essentially every transferred TDO/TDI bit is expanded to a nibble, in which the other bits are used to encode TMS plus an enable bit. After

13:59 <jjulian> re-implementing this we can now talk to the vexriscv core :)

14:01 <jjulian> Our implementation is quite ugly, though. We have hacked it into the ftdi interface driver. I'm not sure if there is any more appropriate place for this. We couldn't easily spot one, where we had enough control on the data flow.

14:03 <PaulFertser> jjulian: hi! Great news, happy to hear you made it working!

14:04 <PaulFertser> jjulian: oh, how did you manage to find out that weird jtag hub encoding?

14:06 <PaulFertser> Just by observing the JTAG LA capture and comparing it to what riscv target code was sending?

14:06 <PaulFertser> "just" :D

14:07 <PaulFertser> I understand how implementing this in a cross-adapter way seems to be impossible given the current architecture.

14:07 <PaulFertser> Even though it's possible to support it with all major adapters: ftdi, jlink, cmsis-dap.

14:15 <jjulian> It's actually part of the openocd cableserver interface, which is included in their patch. The implementation is just a bit hard to read. :)

14:16 <PaulFertser> Haha, yes, I noticed, their patch is messy.

14:19 <PaulFertser> jjulian: probably to implement this cleaner one is supposed to run two OpenOCD instances, the first handling riscv target code and communicating with the second via TCP socket (e.g. using remote_bitbang protocol or even cmsis-dap over TCP or something like that) and the second instance getting the commands from the socket and encoding them in those DR scans.

14:21 <PaulFertser> Here's an example of cmsis-dap over TCP https://review.openocd.org/c/openocd/+/8973

14:22 <PaulFertser> But for first try it's probably much easier to implement remote_bitbang server inside openocd.

14:58 <jjulian> PaulFertser: Sounds interesting. I'll take a look

15:03 <PaulFertser> jjulian: I'm not saying it's the best architecture but I can't think about anything more elegant and straightforward to implement yet.

15:04 <PaulFertser> Because you kind of want to have a special adapter for that hub, but also need to call into the real adapter eventually. And you need to register all the commands of the real adapter etc.

15:06 <PaulFertser> Hm, alterantively the trickery might go into target code itself. And there already is some, /* On BSCAN TAP: Select IR=USER4, issue tunneled IR scan via BSCAN TAP's DR */

15:07 <PaulFertser> jjulian: this tunneled via BSCAN sounds kind of like what you're doing there.

20:18 <gamiee> kinda surprising that CH347 can be updated

20:35 <karlp> what do you mean?

20:35 <karlp> it's litereally just a usb-hs mcu that often comes with pre-baked firwmare.

20:36 <karlp> calling the dongle ch347 is actually a bit unhelpful, as nominally the api could be used by ~anything

20:44 <karlp> huh, nvm, they do actaully brand it as "firmware included" even though it's "obviously" just a mcu really.