12:03 <jjulian> PaulFertser: Thanks, we've made some progress on this. We extracted the actual sequence for the JTAG hub channel selection out of that patch and tried to replicate it using a openocd config. Our current state looks like this: https://pastebin.com/MmeprWeE

12:03 <jjulian> This leads to the following behaviour: https://pastebin.com/2Xi1gntg

12:03 <jjulian> To me it looks a bit as if we would have to trigger a TAP scan somehow after switching the hub channel. Does that make any sense?

12:20 <jjulian> The lattice implementation actually seems to send the instructions for the hub switch before openocd itself starts to do any JTAG setup. So when openocd scans for the TAPs it already sees the CPU.

12:25 <Haohmaru> this was a "virtual" RISC-V core that is actually emulated on an FPGA thing, right?

12:26 <jjulian> Haohmaru: Yes, it's VexRISC-V. I'm trying to use this openocd fork https://github.com/SpinalHDL/openocd_riscv for it.

12:27 <Haohmaru> i wonder, if this wasn't FPGA but "real", would you be able to debug it normally with the normal openocd?

12:28 <jjulian> No, I don't think so. The VexRISC-V does implement a non-standard debug interface, so the stock riscv implementation in openocd won't work with it.

12:29 <jjulian> It's a Lattice FPGA and the Lattice original tooling uses the same, but instead of using the FT2232H interface directly, they have a thing that they call the "cableserver", which talks to the FT2232H. And then they have a patch for openocd, which adds a custom interface that talks to their cableserver.

12:29 <jjulian> The JTAG hub channel select, which I'm trying to resemble is done as part of the interface initialization.

12:30 <Haohmaru> huh wait, so openocd never directly talks to the debugger (FT223whatever) but instead to another program?

12:30 <Haohmaru> how sneaky

12:31 <jjulian> yes

12:31 <jjulian> See here: https://github.com/LatticePropel/propel-sdk/blob/master/openocd_riscv/openocd_riscv.patch#L625

12:32 <Haohmaru> and the cableserver app is... TopSecret, right?

12:33 <Haohmaru> The Precious is hidden in it

12:34 <Haohmaru> i wonder if this app was made intentionally to hide some sh*t or is it maybe because the way to program this virtual core on their FPGA is too awkward to implement into openocd directly?

12:35 <Haohmaru> ...and they didn't bother so they made the changes to openocd "minimal" and moved the sketchy things to the app

12:36 <jjulian> Of course it closed. But actually if you look at that function I linked, you see that it really just does 3 IR Scans and one DR Scan. Using a logic analyzer we can also see that this is what actually happens on the wire.

12:37 <Haohmaru> well i don't understand the code, nor the JTAG nor FPGA stuff

12:58 <PaulFertser> jjulian: hey

13:00 <PaulFertser> jjulian: the problem with OpenOCD is that taps can't be dynamically added or removed after configuration stage ends (and runtime starts). The reasonable workaround is to define all the possible taps in config, and then enable/disable them dynamically. For testing of course one can just restart OpenOCD with different config.

13:00 <PaulFertser> jjulian: so basically what you're already doing.

13:02 <PaulFertser> jjulian: what I'd do there is I would define only the FPGA tap, then I would execute that magic irscan/drscan sequence. Then I'd shutdown OpenOCD and would restart it with just adapter defined to see the results of tap autodetection.

13:03 <PaulFertser> jjulian: also if you start OpenOCD with -d3 you'll see what exactly is giving you that weird "Error while reading from socket"

13:10 <PaulFertser> jjulian: in the case I was familiar with the magic sequence was basically replacing one tap with another, see tcl/target/bcm47xx.cfg . But in your case it might be actually adding it to the chain. So do the sequence, then try restarting OpenOCD without taps defined.

13:19 <jjulian> PaulFertser: That config looks very similar to what we are trying :)

13:19 <jjulian> Running openocd with just the fpga tap, then the 4 scan commands and then running it again without any tap configured leads to the fpga being autodetected again, though.

13:20 <PaulFertser> jjulian: is there a way to do the silly magic with vendor tool and then without resetting the target trying to connect to it with regular OpenOCD to compare the tap id that's detected?

13:21 <jjulian> Should be possible when running the regular openocd on Windows. The linux variant of the vendor tooling is of course broken.

13:21 <PaulFertser> jjulian: my point is that there might be some minor detail missing about the irscan/drscan sequence as you implemented and so it's not doing the thing.

13:22 <jjulian> PaulFertser: I just did a full capture of the JTAG when using the vendor tooling. Up to the point where OpenOCD prints "JTAG tap: fpga_spinal.bridge tap/device found: 0x10001fff".

13:22 <jjulian> See here: https://pastebin.com/qAwLqkmK

13:23 <PaulFertser> jjulian: like probably it expects irscan to not switch to the default state before executing the next command or similar

13:23 <jjulian> Can you make any sense of the 0x5555555 DR scans? Also I can't see where any scan would show the 0x10001fff

13:27 <PaulFertser> jjulian: OK, so the trace starts with the usual way to do Test Logic Reset by guaranteed transition to reset/idle, this is supposed to pre-load IDCODE instruction in IR and so it goes right away to DR scan to shift out tap ids.

13:29 <PaulFertser> Then it shifts 0x32 in IR and 0x05 (IDCODE for this target?) gets shifted out.

13:30 <jjulian> Right. And there it sees the 010FB043, which

13:30 <PaulFertser> Then it goes via idle state and shifts 0x040006 in DR, gets 0x000006 out. But in this trace how do I see how many bits were actually shifted?

13:31 <jjulian> Hm, good point. Let me see, if we can change the export format

13:32 <jjulian> meanwhile here is the capture from openocd with our config: https://pastebin.com/WMdRUc5g

13:32 <jjulian> there definitely is still a bunch of differences

13:36 <jjulian> PaulFertser: Here the logs with bit counts included:

13:36 <jjulian> - lattice: https://pastebin.com/BupNtUwi

13:36 <jjulian> - openocd: https://pastebin.com/Wm06MKKS

13:41 <PaulFertser> jjulian: since shift-IR count doesn't change it means that it's not that a tap is added into a chain but rather replaced.

13:42 <PaulFertser> It looks like this 0x5555555 (28) is part of the switching required, probably it's mentioned in that patch elsewhere.

13:45 <PaulFertser> jjulian: no good idea yet, but it feels like you're really close and you have everything required to make this work eventually.

13:52 <jjulian> Yes, we just added the 0x5555555 as well as the following 0x1155... and 0x3333.... instructions. That makes a good difference. OpenOCD seems to be able to talk to the CPU now.

13:52 <jjulian> It says: [lifclu.cpu] Target successfully examined.

13:52 <jjulian> Now, I can connect with gdb, but then I get: Error: timed out while waiting for target halted

13:52 <jjulian> Not sure why that would be

13:52 <PaulFertser> Awesome progress!

13:53 <PaulFertser> jjulian: by default it tries to halt the target upon gdb connection so that fails for some reason.

13:53 <PaulFertser> I'd compare -d3 output of upstream OpenOCD to see how exactly the examination process was different if at all.

13:54 <PaulFertser> Probably it's not exactly right yet.

13:54 <PaulFertser> jjulian: might be that after switching the IR length would still be 8 instead of 4 or something like that.

13:55 <PaulFertser> Looks like that cable server itself inserted those fives and other "strange" commands?

13:57 <jjulian> seems so. I couldn't find them in the patch

14:15 <jjulian> good thing is: "info registers" works, and using "set" I can actually even change those registers. So the connection to the CPU is basically working, I'd say. Just halting the target is not yet working

14:45 <PaulFertser> jjulian: probably they have also some changes to riscv target code there.

14:46 <PaulFertser> jjulian: hm, another state in which the target can not be halted is when its reset is pulled constantly

15:13 <jjulian> It shouldn't be held in reset. There are no TRST and SRST lines attached in the design