<clever>
ah but since its for dumb things, its more, that openocd has to turn it on/off, based on how smart it believes the adapter is
<Hawk777>
Yeah.
<Hawk777>
I think so.
<Hawk777>
I’m not an expert at OpenOCD’s codebase, so I’m not sure which layers do that.
<clever>
so i can see several layers i could implement things at now, the dumbest is just remote_bitbang
<clever>
the next layer up, just slightly smarter, is more like the ftdi, where you give it an array of `N*2` bits, and it will output that on 2 pins with a 3rd clock, capture `N` bits, and return them
<clever>
then the next layer up, is to have the command array clearly have 4bit IR codes, or 35bit DR codes, where it will shift thru them, but hang and repeat a command on WAIT, and finally return a 32bit result for each DR code
<clever>
and the next layer up, would be to define AP things to read/write, and do the IR/DR stuff within the adapter
<Hawk777>
AFAICT those are all valid and reasonable layers.
<Hawk777>
In the “array of IR/DR codes” you might want to also add tags for whether the retry logic should apply to a given line or not, so that you can use it with non-ARM JTAG targets.
<Hawk777>
But, if all you care about is ARM you might not need that right away.
<clever>
i mainly intend to debug rpi products, the pi0-pi4 all use jtag, the pi5 uses SWD
<clever>
the rp2040 is cortex-m0+ with swd
<clever>
and the rp2350 is more complex, cortex-m3 and hazard (risc-v) sharing a single SWD port
<clever>
but somebody i work with also wants ch32 stuff, which is an entirely different protocol, so that could start at the remote_bitbang layer, and work up its own path
<clever>
Hawk777: i also notice an odd path in the jtag graph, what would be the point of doing Select-DR-Scan, Capture-DR, Exit1-DR, Update-DR ?
<Hawk777>
I don’t really know.
<Hawk777>
I suppose in case of ARM it’s probably useless, it would execute the ACK pattern as an A[3:2]+RnW, with the data treated as an address.
<clever>
or going from Exit1-DR back to Shift-DR?
<Hawk777>
Maybe on some other devices it’s useful.
<clever>
exit2*
<Hawk777>
You mean Exit2-DR to Shift?
<clever>
yeah
<Hawk777>
I don’t know about that either.
<Hawk777>
Actually, I have an idea.
<clever>
Pause-DR i could see being semi useful, pre-load some command (cpu resume, or boundary scan bit-bashing), and then you have a defined latency (2 or 3 TCK pulses) to Update-DR, where things begin taking effect
<Hawk777>
You could do conditional chains. Execute command A, which reads something. Expect that 99% of the time, the value will be X. If the value is X, execute command B. If the value is not X, abort. You could achieve this by DRSCANning command A, then immediately DRSCANning command B while reading the result of command A. If the result you read back is not X, take the Exit2→Shift transition and replace B with a nop.
<clever>
yeah, so you can Capture, Shift out command 2B, while reading 1's reply
<clever>
then process 1's reply, change your mind, go back to Shift, and send 2C
<Hawk777>
Yep!
<Hawk777>
I don’t know if anyone does that in practice, but it looks like it would be possible.
<clever>
i could see that being useful, if the WAIT stuff didnt exist
<Hawk777>
Probably only really useful if there’s a very strong bias in command A’s result.
<Hawk777>
Yeah.
<clever>
for non-DP jtag
<clever>
and openocb probably doesnt use it, but i think boundary scan would be something like 3 registers? pin direction, mask, and data?, with 1 bit per addressable pin?
<clever>
with the mask being useful to prevent a write from impacting the pin
<Hawk777>
I’ve never looked into how bscan works actually.
<Hawk777>
It looks like it uses a handful of different IR instructions.
<clever>
my rough understanding, is that it would basically allow bit-banging any addressable pin, without the cpu having to be online, and maybe even internal nets
<Hawk777>
Yes.
<clever>
so you can then test connections between chips without having the cpu co-operate
<clever>
if the chip even has a cpu
<clever>
static int remote_bitbang_write(int tck, int tms, int tdi)
<clever>
looks like this just assumes bit0 is tdi, bit1 is tms, and bit2 is tck?
<clever>
and after OR'ing things together, it adds it to the ascii 0, to convert into a 0-7 number
<Hawk777>
Looks that way to me. I guess that’s how the remote bitbang protocol works.
<clever>
so you cant freely configure which remote gpio does what, at the openocd end
<Hawk777>
Presumably you’d do that on the bitbang adapter end.
<clever>
yeah
<Hawk777>
Which IMO makes sense; different products might have different ways of naming pins, so keep the protocol simple.
<clever>
when i hear remote bitbang, i think more, where you just tell the remote device which gpio to wiggle
<clever>
but this seems to be more jtag focused, and gives it the value of 3 jtag output signals
<clever>
at a glance, it looks like remote_bitbang doesnt even have linebreaks? its just a series of numbers, from 0-7, which just get shoved into 3 gpio as fast as the adapter desires
<clever>
and maybe just TDO gets captured? one ascii char per clock? and returned back
<clever>
seems dead-simple
nerozero has joined #openocd
Hawk777 has quit [Quit: Leaving.]
slobodan has joined #openocd
joconor has quit [Read error: Connection reset by peer]
joconor has joined #openocd
Haohmaru has joined #openocd
joconor has quit [Ping timeout: 248 seconds]
joconor has joined #openocd
renrelkha has quit [Quit: bye]
renrelkha has joined #openocd
JakeSays has joined #openocd
slobodan has quit [Ping timeout: 244 seconds]
Haohmaru has quit [Quit: saionara]
Guest7 has joined #openocd
Guest7 has quit [Quit: Client closed]
slobodan has joined #openocd
nerozero has quit [Ping timeout: 252 seconds]
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #openocd
PlasmaHH_ has joined #openocd
zjason` has joined #openocd
zjason has quit [Ping timeout: 252 seconds]
slobodan has quit [Ping timeout: 248 seconds]
<karlp1>
PlasmaHH_: what version of openocd are you running with this dual load issue? it's not in the pastebin?
<PlasmaHH_>
karlp1: git from a couple of days ago, had that problem for years now
<PlasmaHH_>
since it usually works the second attempt its not something too annoying to really debug when I need to get shit done ;)
<karlp1>
clever: another option is things like the blackmagic probe for esp32, "farbprobe" and similar, https://github.com/flipperdevices/blackmagic-esp32-s2 might be portable to your pico-w more easily than openocd itself.
<PlasmaHH_>
I think last time I saw a hint of a hardfault there, not sure
<PlasmaHH_>
so gnight
PlasmaHH_ has quit [Ping timeout: 264 seconds]
Deneb has joined #openocd
noarb has joined #openocd
Deneb has quit [Quit: Leaving]
<clever>
karlp1: as long as its based on lwip and doesnt use fancy threading stuff, then it should be easy to just swap out the gpio methods and just run it