07:54 <jjulian> Hey, I'm trying to setup openocd to access a RISC-V soft CPU running on a Lattice LIFCLU FPGA. The original Lattice tooling seems to use a patched openocd, using a vexriscv target. I am trying to use stock openocd with RISC-V instead. The CPU has a "JTAG channel" set to 14, which in the Lattice config is set using a "set channel 14" command in

07:54 <jjulian> openocd. Is that a standard command? I can't find it documented.

07:54 <jjulian> Right now, I am in a state where the scan sees the FPGA itself, but I can't get down to the CPU. If I do not set the channel in the lattice openocd variant, I get the same behavior. So I somewhat suspect that channel thing might be the issue?

07:57 <jjulian> the interface is a FTDI FT2232H

08:10 <zapb> jjulian, "set channel 14" is no OpenOCD command

08:11 <Haohmaru> forked and modified openocd again

08:11 <zapb> jjulian, where did you get the patched OpenOCD version from? The corresponding source code must be available somewhere

08:12 <zapb> If the target is a normal riscv target, you should be able to use the "riscv" target

08:12 <zapb> There is also a riscv-openocd fork which you can give a try

08:14 <jjulian> It's shipped as part of the Lattice Radiant tooling... I wouldn't be surprised if they violated license terms.

08:14 <zapb> jjulian, did you try vanilla openocd (Git master) with riscv target?

08:15 <jjulian> I just realized that the set channel command might be for their interface implementation. They have a dedicated process the "cableserver", which talks to the FTDI interface and are not using the stock ftdi support of openocd. I would obviously rather use the latter.

08:15 <jjulian> zapb: That's what I'm trying right now, but I can't get the JTAG scan to actuall see the CPU

08:15 <zapb> jjulian, show your config and output (pastebin)

08:16 <zapb> Would not be the first time some company violates GPL :D

08:17 <Haohmaru> "If you want to violate the GPL - press one" 11111111111111

08:19 <jjulian> zapb: This is the config that lattice uses: https://pastebin.com/LRKjvJc4. I've added the openocd call with all arguments in the bottom. My config currently looks like this: https://pastebin.com/f6n9kd7Q

08:19 <jjulian> And this is the output I get:

08:19 <jjulian> https://pastebin.com/y87iZ8EN

08:19 <jjulian> so true about the GPL...

08:20 <jjulian> and this is the output of the lattice openocd: https://pastebin.com/YZD1juj3

08:22 <Haohmaru> QCoreApplication::applicationDirPath <- dafuq, have they added some crap from the cue-tea lib to openocd?

08:23 <Haohmaru> and it looks like they aren't even using it properly

08:23 <zapb> jjulian, seems "heavily" modified. Maybe a look into the RISCV_SMALL_YAML file give some insights. Could be that they perform some configuration to enable debug access (?)

08:23 <zapb> jjulian, do you use the same adapter in both setups?

08:36 <zapb> jjulian, maybe this solves your problem https://tomverbeure.github.io/2021/07/18/VexRiscv-OpenOCD-and-Traps.html

08:37 <zapb> (not read entirely)

08:38 <zapb> The most important part here is: "The VexRiscv debug infrastructure is not compatible with the standard RISC-V Debug Specification."

08:47 <jjulian> Sorry, was pulled into a call. Back now.

08:49 <jjulian> That post looks very much like it's what I need. Thanks. I'll check in detail

08:49 <zapb> jjulian, you're welcome

09:26 <jjulian> unfortunately that article leaves out the details on the JTAGG primitive cell support, which seems to be used to hook the VexRISC-V's JTAG behind that FPGA's JTAG. Couldn't really figure out how to configure that, yet.

09:26 <jjulian> I suppose this relates to the magic "set channel 14" in the lattice tooling.

09:32 <zapb> Is this a lattice specific thing?

09:32 <zapb> jjulian, feel free to ask/request the source code from Lattice (e.g. via forum)

09:33 <zapb> jjulian, you could also check if the "set channel" command is included in the openocd fork mentioned in the article

09:43 <Haohmaru> you should do that early because they probably won't respond very urgently ;P~

09:46 <jjulian> It seems lattice specific. This is the lattice-cable.cfg, which is used by their tooling: https://pastebin.com/kJ5XAwHf

09:46 <jjulian> If a channel is set, they relay that to the "lattice_jtaghub_channel_select" command

09:46 <jjulian> which is not supported by the spinalhdl riscv-openocd fork either

10:05 <zapb> jjulian, is it not possible to route the jtag signals directly to I/Os?

10:07 <zapb> They did not even change the comments in the config file ("Olimex ARM-JTAG-EW") :D

11:30 <jjulian> zapb: there are not many spare I/Os on the board, so it's not really feasible to routed the CPU's JTAG to dedicated pins

11:31 <zapb> Okay, I see

11:53 <jjulian> I fear it wouldn't be even helpful if lattice published the source code of their openocd variant, as the actual magic for selecting the JTAG target probably appears within their cableserver, through which openocd only communicates via a tcp socket.

12:37 <jjulian> Maybe my best bet is to actually sniff the JTAG with a logic analyzer when using the lattice tooling to figure out which opcodes it send to select the CPU's JTAG port.

13:03 <PaulFertser> jjulian: is that thing you want going via JTAGG? And is it somehow that you do not see VHDL source for how the soft core integrates with it?

13:06 <PaulFertser> But that's weird, doesn't look like it provides an easy way to connect arbitrary JTAG TAP to it judging by https://github.com/tomverbeure/ecp5_jtag/blob/main/README.md

13:32 <jjulian> PaulFertser: To be honest I am not completely sure, whether JTAGG is what I need. I'm running on a LIFCL-33U FPGA, which is based on the Lattice Nexus platform. I couldn't find documentation specifically on that one for the JTAG routing feature. On the ECP5 FPGAs it apparently is done via JTAGG, though.

14:41 <PaulFertser> jjulian: quick look at that JTAGG description didn't tell me how one can switch between the states of the JTAG machine connected to it, that's odd.

15:01 <jjulian> PaulFertser: Did you look at [this](http://www.latticesemi.com/view_document?document_id=52656) or something else? The JTAGF seems to basically be a mux, which has two TDO output lines?

15:02 <PaulFertser> jjulian: I looked only at https://github.com/tomverbeure/ecp5_jtag/blob/main/README.md . Well, TDO output I can understand but for JTAG also you need TMS to guide state machine transitions.

15:06 <jjulian> Hm, I also can't really bring this together with the JTAG channel selection, where you can select 14, 15 or 16 for the RISC-V CPU in the lattice tooling.

15:06 <jjulian> The JTAGG really looks like a 1:2 mux at most, right?

15:09 <PaulFertser> Kinda but not sure how that combines with actual JTAG connections. Normally you have some amount of taps chained with TMS and TCK going in parallel, then you load "instructions" to each of them in parallel by going through the relevant states, then you go to Shift-DR state and you can load/read DRs of each of them in parallel.

15:10 <PaulFertser> Big SoCs also often feature some "JTAG routers" or "switches" which allow to connect additional taps in the chain but it's still the same idea after the connection is completed.

15:21 <jjulian> Hm, yes, I saw a mention of "JTAG Hub" in some Lattice document. That sounds somewhat like a router/switch. And maybe that one is in use. But documentation doesn't really seem to exist.