shibboleth has quit [Remote host closed the connection]
shibboleth has joined #openocd
shibboleth has quit [Remote host closed the connection]
shibboleth has joined #openocd
shibboleth has quit [Quit: shibboleth]
Hawk777 has joined #openocd
nerozero has joined #openocd
Hawk777 has quit [Quit: Leaving.]
slobodan has joined #openocd
d_olex has quit [Ping timeout: 248 seconds]
slobodan_ has joined #openocd
slobodan has quit [Ping timeout: 260 seconds]
slobodan_ is now known as slobodan
d_olex has joined #openocd
<gamiee>
I sent the patch right now because it's very very similar to BL702 one. It's because both were developed at same time simultaneously, so they share a lot. So I was thinking maybe it would be good to have one common config (like bl602_common.cfg) which those two includes, same as STM32s.
<gamiee>
Hi borneoa___ . I pushed to gerrit TCL script for BL602 chip, with link to BL602 flash driver as well. (So can be merged only after the flash driver is merged too).
<gamiee>
(Also I am aware that rebasing will be required when BL702 proper reset patch is merged due merge conflict, will take care of that when it will happen).
<gamiee>
(also, sorry for multiple revisions, I have weird brainfog today, so even when I proof-readed the commits, I always missed that.)
<gamiee>
Although, I was not sure about it, so I did it just as it is. I will appreciate any feedback, mainly if common config is right thing to do or not.
nerozero has quit [Ping timeout: 260 seconds]
clever has joined #openocd
<clever>
starting work on the jtag code now, i can wiggle TDI/TMS/TCK, and TDO will sometimes respond, only stumbling block is that TRST was low at first
<clever>
but the value i'm reading out of IR doesnt look right, and its not clear if i should be using 4bit or 8bit IR codes
<PaulFertser>
clever: you can try probing IR length if you know it's just one tap. Push like 32 ones there, then start pushing zeros and see what the delay is.
<clever>
PaulFertser: with this code, it should shift 0b1110 into IR, and then try to read 64bits from DR (specs say its only 32bits long), but i only get a 0 out of IDCODE
<clever>
according to the arm docs, 0b1110 should be IDCODE
<clever>
and the DR is only 32bits long, so the shifts would put the result into the upper 32bits of my uint64
<PaulFertser>
clever: also IDCODE should be the instruction autoloaded in IR after JTAG state machine reset (by TRST or test-logic-reset sequence).
<clever>
should i expect IDCODE to also come out of TDO when i shift-ir?
<clever>
on that first command?
<PaulFertser>
clever: I'm not exactly sure, the arm docs say about "debug logic reset".
<clever>
TDO: 0xdc400ba400000000
<clever>
if i dont write to IR at all, and just immediately reset and shift-dr, i get this
<clever>
and i'm on a cortex-a53 currently...
<PaulFertser>
Cortex-M has 0x4BA00477 IDCODE
<PaulFertser>
Cortex-A7 0x6ba00477
<PaulFertser>
It's been too many years since I worked with JTAG on bit level, sorry...
<clever>
if i flip the bits around in JS, i get 25d0023b
<clever>
oh, i can see 1 minor problem with my code, vs `figure 2` in your link
<clever>
`figure 2` has TMS and TDI high on the same clock
<clever>
so i might be inserting an extra bit at the end of my shift-ir's
<clever>
> The thing is that going through the Capture-IR state, the TAP controller loads into the shift register a value of 0b0001 for CoreSight JTAG-DP TAP
<clever>
> So, over the next 9 clock cycles (including this one) we will get a TDO sequence of 0b100010000
<clever>
PaulFertser: so it looks like its LSB first, and my bit-shifts are backwards
<clever>
TDO: 0x25d0023b
<clever>
now it outputs the same as when JS flipped it around...
<clever>
> (0x25d0023b << 1).toString(16)
<clever>
'4ba00476'
<clever>
PaulFertser: aha, bingo!, i'm off by 1 bit!
<clever>
TDO: 0x4ba00477
<clever>
the problem, is that upon entering shift-dr, TDO already has bit0 of the DR
<clever>
and i then ignored that, and pulse TCK once
<PaulFertser>
clever: aha, nice, so it matches finally!
<clever>
yep
<clever>
now that i see these 2 problems, let me fix the shift-ir code...
<clever>
still buggy, it claims IR had 0x2, but shifting 0b1110 into IR did still produce the expected IDCODE
<PaulFertser>
I'm not so sure about that idcode command preloaded thing.
<PaulFertser>
There's also the way to auto-detect all taps on the chain and right after test logic reset they should have those markers at the end to allow length autodetection, not idcode probably.
<PaulFertser>
I can't now remember how exactly to get idcode loaded.
<clever>
updated the gist with the new logs and code
<clever>
added some newlines and comments to the logs, but i think i'm mis-aligned on tck
<clever>
TDO hist: 0x4ba00477e1ff8000
<clever>
PaulFertser: this variable, is a shift-register, that gets updated (bit 63 set to TDO), after each TCK pulse
<clever>
its a 64bit field, so when doing a 32bit shift-dr, only the upper 32bits should be used
<clever>
and the lower 32bits, are part of the shift-ir output, and the value of tdo while doing the TMS dance
slobodan_ has joined #openocd
slobodan has quit [Ping timeout: 252 seconds]
<clever>
aha!
<clever>
> At the Capture-IR state, the binary value 0b0001 for 4-bit instructions, or 0b00000001 for 8-bit instructions, is loaded into this shift section.
<clever>
PaulFertser: so for arm chips with a 4bit IR, capture-ir always loads 0001 into the shift-register, and not the previous IR value!
<clever>
which is exactly what i see in my logs
<clever>
page 93 of the ADI also says that IDCODE is put into the IR, when in test-logic-reset
<clever>
so the problem, is that i assumed i could read the 0b1110 out of IR, to confirm it was in IDCODE mode
<PaulFertser>
clever: so it's there but gets overwritten as soon as you get into Capture-IR?
<clever>
PaulFertser: yep
<clever>
going ingo reset, sets IR to IDCODE
<clever>
going into capture-ir puts a constant that reveals the IR length into the shift-reg
<clever>
going into update-ir, moves the shift-reg into the IR register
<clever>
but if you have even 1 clock in shift-ir, then things will be shifted, and a mix of the constant and the TDI pin
<clever>
but the state machine does have a way to skip shift-ir
<clever>
and the constant it loads, is the boundary scan SAMPLE code
slobodan_ is now known as slobodan
JakeSays_ has joined #openocd
JakeSays has quit [Ping timeout: 264 seconds]
JakeSays_ is now known as JakeSays
<clever>
PaulFertser: so my next task, is finding a usb protocol to implement, and getting 2 usb interfaces at once
mwette has quit [Ping timeout: 260 seconds]
<PaulFertser>
clever: or you can quickly prototype with remotebitbang for starters
<PaulFertser>
And to have something simple for reference.
<clever>
PaulFertser: does remote bitbang support usb as well?
<PaulFertser>
clever: ah, no, it's just TCP.
<clever>
but there is also the other problem, where i need ~3 streams to a single usb device
<clever>
thats what i thought
<clever>
the 1st stream is the serial port on the pi
<clever>
the 2nd stream is jtag
<clever>
and the 3rd stream is control of other signals, like the hw reset, or later on, re-flashing the boot media
<PaulFertser>
USB allows for that with "composite device" thing.
<clever>
yep
<clever>
ive done those before with the pi-zero
<clever>
i just need to convince the pico to do the same thing
<clever>
PaulFertser: and with this, i can shove arbitrary values into IR and DR, of arbitrary length
<clever>
and a large chunk of the jtag api has been abstracted away
<clever>
and in theory, this part should work on anything using jtag, not just arm (just change the IR codes)
<clever>
PaulFertser: oh!!, as i discovered earlier, the clock that moves from capture to shift, updates TDO, and is presenting bit0 of the shift-reg, upon entering shift mode
<clever>
and bit0 is the WAIT flag!
<clever>
(when using DPACC or APACC)
<clever>
so you only have to spent a single clock in shift-dr, to detect if you need to wait or not