08:34 <PaulFertser> karlp1: I'd say yes, as it's breaking assumptions of the flash driver and do not ensure consistent hardware state.

09:29 <manawyrm> Hey folks :)

09:29 <manawyrm> I've been working with OpenOCDs remote-bitbang driver over the last couple of days very successfully, but the hardware I'm using also has support to do JTAG natively, which would increase performance pretty significantly, I'd hope.

09:30 <manawyrm> Is there a similar TCP (or otherwise networked) protocol in OpenOCD that I could implement to get a higher layer JTAG interface?

09:30 <manawyrm> (at least higher layer than direct bitbanging)

09:31 <manawyrm> As my performance bottleneck is between the TCP receiver and the device under test, I almost thought about implementing a custom JTAG "sink" in software, parsing the bitbanging commands back into instruction/data and so on, but that sounds overly complex and fragile

09:57 <clever> manawyrm: was just asking this very question a few days ago!

09:58 <clever> manawyrm: https://libera.irclog.whitequark.org/openocd/2024-10-14#;clever

10:00 <clever> ah, the search is hiding a lot of context

10:00 <clever> https://libera.irclog.whitequark.org/openocd/2024-10-14#37147146;

10:00 <clever> skipping to a timestamp is better

10:06 <manawyrm> clever: aww :/

10:06 <manawyrm> yeah, that's pretty mch what I want and those answers look like what I already gathered from looking at the source code

10:06 <manawyrm> That's pretty sad, so I guess I'd either have to invent something myself

10:06 <manawyrm> (and upstream that)

10:06 <manawyrm> or just live with the current state

10:07 <clever> i need to dig into it more, but i think there was something about the jlink driver supporting tcp?

10:07 <manawyrm> yeah, but the jlink is a propritary device

10:07 <manawyrm> i mean -- the protocol is probably documented somewhat inside of openocd

10:07 <manawyrm> so I might be able to do that

10:07 <manawyrm> but ... well....

10:07 <clever> yeah

10:08 <clever> in my case, the goal is to have a pico-w expose jtag over wifi

10:08 <clever> so i can debug a remote target

10:08 <manawyrm> in my case, there is no real actual hardware JTAG lines, it's virtual inside of a remote machine

10:08 <clever> ahhh

10:08 <manawyrm> I have a little daemon accepting remote-bitbang connections rn

10:08 <manawyrm> and it's then writing into magic registers, etc.

10:09 <clever> i suspect that the rpi has those same magic registers internally, and it can mux the jtag to physical pins or the magic regs

10:09 <manawyrm> clever: yeah, I'm using a AST2500 (one of those server remote management chips here)

10:09 <manawyrm> but it's basically a rpi chip after all

10:10 <manawyrm> currently I'm bitbanging the GPIO registers over a UART repl/shell, you can imagine how slow that is

10:10 <clever> yeah

10:11 <clever> the magic regs in the rpi, seem to include automatic shifting

10:11 <clever> https://github.com/librerpi/rpi-open-firmware/blob/master/common/broadcom/bcm2708_chip/arm_control.h#L383-L413

10:11 <clever> manawyrm: my best guess as to how they work, is that you load some data into TDI and TMS, then you tell it to clock out 32 bits

10:12 <clever> and then a reply will appear in TDO

10:12 <clever> once BUSY clears itself

10:12 <manawyrm> clever: yeah, that seems very similar to the peripheral in my chip

10:12 <manawyrm> (altough I do have full docs, so that's nice)

10:12 <clever> on second look, i dont see an option to shift 35 bits

10:13 <clever> and i think arm is heavily based on 35bit transfers?

10:13 <clever> but there is a fishy 0 bit shift, and 34, so maybe off by one?

10:14 <clever> keep me updated if you make something tcp based, and i can try to implement your stuff in my pico-w project

10:16 <clever> i need to get off to bed

11:35 <PaulFertser> manawyrm: the jlink documentation for the lower level protocol was freely available to the public

11:37 <PaulFertser> manawyrm: but probably the USBIP way is really making sense for your usecase too?

11:51 <manawyrm> PaulFertser: the USBIP way is batshit insane, i'm sorry

11:51 <manawyrm> there's no actual hardware involved anywhere

11:51 <manawyrm> Emulating a virtual USB device on a virtual HCI to speak JTAG?

11:51 <manawyrm> That's just crazy

11:58 <PaulFertser> manawyrm: good point. As with any generic solution it's suboptimal for any specific application, agreed.

13:32 <karlp1> manawyrm: would https://review.openocd.org/c/openocd/+/6867 be helpful at all?

13:33 <karlp1> potentially better than remote bitbang, potentially just another square peg in a round hole?

14:03 <manawyrm> karlp1: yes, indeed, that already looks better :)

14:04 <manawyrm> I'll have to check the implementation of the JTAG peripheral and see if I can map this properly, but removing the multiple writes required for a single state transition should already improve speeds by orders of magnitude

23:04 <clever> manawyrm: one thought i came to, the arm jtag protocol involves sending a 35bit command to the cpu, and receiving a 35bit reply back

23:05 <clever> and within that reply, is a WAIT flag, meaning the 2nd last command is still busy, the last command you just gave it wasnt accepted, and to discard the reply you saw WAIT in

23:05 <clever> so you can just keep repeating that command until its accepted

23:05 <clever> so in theory, openocd can fire off a list of commands, saying to write something to the IR register, or to write a series of things to the special 35bit DR register

23:06 <clever> and then the remote device can walk that whole list of commands, and retry when needed, building up a list of 35bit replies

23:06 <clever> and once its done, fire the entire set of replies back off to openocd

23:31 <jn> manawyrm: oh hi :)

23:32 <clever> jn: ah, hello!

23:33 <jn> hi clever :)