Haohmaru has quit [Read error: Connection reset by peer]
Haohmaru has joined #openocd
akaWolf has quit [Ping timeout: 248 seconds]
slobodan has joined #openocd
zmatt has quit [Ping timeout: 248 seconds]
zmatt has joined #openocd
<PlasmaHH>
I am currently in the situation that through gdb "load" on one machine it works almost fine on another it pretends to load the binary but whats in the controller aftwareds is still the old thing... anyone has an idea how to debug that? there is no error message of any sorts
<Haohmaru>
how about verification?
<Haohmaru>
the only thing that comes to my mind is perhaps if the firmware goes to the wrong place (address) perhaps
<PlasmaHH>
the output of the load command looks fine... also the "monitor program" command does the right thing... it must have to do something with the communication between gdb and openocd
<PlasmaHH>
well, I wanted to recompile gdb on that machine anyways maybe thats the difference
<Haohmaru>
hm
<PlasmaHH>
its getting annoying when you just want to write an swo plugin but things break left and right ;)
Hawk777 has joined #openocd
<PaulFertser>
PlasmaHH: compare-sections
<PaulFertser>
PlasmaHH: set debug remote 1
<PaulFertser>
And then compare what's going on there.
<PaulFertser>
Probably on another system you have memory map disabled and so GDB has no clue it's flash memory.
<PlasmaHH>
well at least I dont have it in my cfg ... assuming that might be the reason, wouldnt it be expected to see an error message?
<PaulFertser>
Depends on the target.
<PaulFertser>
Just enable that remote debug to compare what commands are actually used.
<PlasmaHH>
will do ... the target and the cfg is the same on both machines which made me wonder in the first place... have to finish the next swo feature before tying again
bvernoux has joined #openocd
Haohmaru has quit [Quit: saionara]
<PlasmaHH>
PaulFertser: good hint with the memory map... I did not noticed (because it was scrolled too far up) that gdb complained it wasnt built with xml support... possibly something went wrong in the last build ( -j xx support isnt great there )
<PlasmaHH>
now its back to the known behaviour of "load" working after a second attempt... ^^
PlasmaHH_ has joined #openocd
PlasmaHH has quit [Ping timeout: 255 seconds]
renrelkha has quit [Quit: bye]
renrelkha has joined #openocd
nerozero has quit [Ping timeout: 252 seconds]
noarb has quit [Ping timeout: 248 seconds]
<karlp1>
that's still busted though
<karlp1>
something's realllly weird in your environment.
clever has joined #openocd
<clever>
what kind of network jtag options does openocd support?
noarb has joined #openocd
<Hawk777>
I think they’re probably all listed here <https://openocd.org/doc/html/Debug-Adapter-Configuration.html#Interface-Drivers> just like all the others. There‘s a “remote_bitbang”. I’m not sure if the J-link supports some kind of network use, not sure how those work. Also Cadence Virtual Debug (vdebug) looks like it uses some kind of network connection.
<Hawk777>
Is that what you were looking for?
<zapb__>
clever, j-link supports tcp/ip
<zapb__>
clever, then there is remote_bitbang
<zapb__>
No other "network jtag" options are available
<zapb__>
clever, what do you need / what do you want to do?
<karlp1>
clever: it's actually more common to solve this (with openocd) by just using a normal usb connected debug interface and attaching it to any generic SBC/openwrt device and accessing it over the network that way.
<karlp1>
it's not what you asked, but it might be what you need?
<Hawk777>
Ah, yes, if what you want is to be able to debug things from somewhere other than where the thing is, I tend to do the networking at the GDB/Telnet level.
<Hawk777>
I think that’s what karlp1 meant.
<Hawk777>
So OpenOCD runs close to the target, while GDB runs close to me.
<Hawk777>
But you can also just SSH somewhere and then run GDB too.
<PlasmaHH_>
this is the output of two different "load" invocations in gdb ... https://pastebin.com/KU3E6kRH anyone can tell me in a few words how it does the flash process? is it one of those where it starts a small program on the controller ram?
<Hawk777>
Yes it is. Most of OpenOCD’s Flash access works that way (and you can confirm in this case “timeout waiting for algorithm” means it tried to do that). That program and the data to write are loaded into the work area and run from there.
<Hawk777>
Some of the algorithms (maybe most or all?) stream data through the work area, rather than being started and stopped for each chunk of data.
<clever>
zapb__: oops, got distracted, i want to implement jtag on a pico-w, and using an existing protocol would avoid the need to use an openocb fork
<Hawk777>
Ah. Could you run OpenOCD on the pico-w instead?
<Hawk777>
(I have no idea what a pico-w is, maybe that’s a silly idea)
<clever>
Hawk777: it only has 260kb of ram
<Hawk777>
Ah, not so much then :)
<PlasmaHH_>
so the question then is, why does it time out...
<PaulFertser>
PlasmaHH_: you can tell how the flashing actually works by looking at openocd -d3 log, not the gdb log.
<Hawk777>
clever: maybe remote_bitbang? Unless you were hoping to push more intelligence to the pico-w.
<PaulFertser>
PlasmaHH_: for stm32 yes, there's a small helper uploaded to RAM which does flashing from a circular buffer which is filled in a lockless fashion.
<PaulFertser>
clever: hm, how about daplink (cmsis-dap) packed into tcp?
<Hawk777>
Does OpenOCD speak that? I thought it only had a driver for CMSIS-DAP attached via USB?
<Hawk777>
Neat idea if it works though!
<PlasmaHH_>
hm, looks a bit like a hard fault...
<clever>
PaulFertser: that sounds good, because i want to avoid spending 1 round trip per bit, lol
<clever>
hmmm, what about serial jtag protocols?
<clever>
socat can bridge a pty and a tcp socket
<clever>
and then openocd will think its a local serial/tty
<Hawk777>
remote_bitbang was my suggestion, Paul suggested CMSIS-DAP which would be much more efficient.
<clever>
my first goal, is to jtag debug a cortex-a cpu
<clever>
but some of my targets are SWD to cortex-a or cortex-m
<PaulFertser>
clever: or jlink protocol over tcp/ip can be an option, that's supported by libjaylink already.
<PaulFertser>
But serial, hm, nothing comes to mind.
<clever>
hmmm, but is jlink currentlty usb only?
<PaulFertser>
No
<clever>
i'll have to go over the openocd source, see what the protocl is like, and try to implement things
<clever>
another option, how complex is it to parse the gdb<->openocd protocol, and then jtag a cortex-a cpu?
<clever>
could i just re-implement part of openocd and cut openocb out of the loop?
<PaulFertser>
clever: jlink is implemented in libjaylink
<PaulFertser>
clever: GDB Serial protocol is quite high level, it's about "write target register X" or "read target memory Y" level.
<clever>
yeah, thats pretty high level, which pivots things, to how hard is it to do such an action, on arm1176, cortex-A7, A53, and A72
<clever>
and also cortex-M0+, cortex-m3, and cortex-A76, over SWD
Henry_Nguyen has joined #openocd
<PaulFertser>
And it is hard
<PaulFertser>
That's what OpenOCD does.
<PaulFertser>
clever: have you considered implementing USBIP protocol?
<clever>
that could maybe work.....
<clever>
the pico-w could claim to be a remote usbip controller, but then not actually send the packets to hw, and have a virtual hub and device
<clever>
then the client with openocd, just connects over usbip, and thinks there is a standard usb adapter present
<PaulFertser>
And that project would be universally useful too for emulating all kinds of USB devices.
<clever>
yeah
<clever>
i can see how it would help to make it in ~3 pieces
<borneoa___>
clever: if I remember correctly, there is a cmsis-dap implementation as an example for zephyr OS. If you can have zephyr support on your MCU, porting the cmsis-dap example should be very easy
<clever>
first, a usbip target for the pico-w, to accept packets from a remote host
<clever>
second, a virtual usb stack, for doing everything in sw
<clever>
third, a virtual usb device, that implements some jtag protocol
<clever>
then just the first part can be re-used, shoved into the pico usb host, and be a light weight usbip target
<clever>
but doing remote_bitbang does also sound like an idea, because then it would support a wider array of things, jtag/swd/ and more, in one module, it just wont have the best performance
<clever>
jack of all trades, master of none
<Hawk777>
You could do both?
<Hawk777>
If you have time to burn!
<clever>
yeah
<PaulFertser>
clever: daplink/cmsisdap also supports bare jtag in addition to swd.
<clever>
start with remote_bitbang, and use it as a fallback for all protocols, and other use (reset pins and such)
<clever>
thats good
<PaulFertser>
You won't like performance of remote_bitbang over wifi.
<clever>
currently, i have a tcp socket rigged into a hw uart
<PaulFertser>
Because all USB protocols were designed with latency in mind and make heavy use of batching.
<clever>
if the socket is open, a gpio is allowed to float, closed pulls the gpio low
<clever>
and thats wired to a reset pin, so the device can only run when watched
<clever>
PaulFertser: yeah, and thats also why i want something like daplink/cmsisdap, because of the latency, i want the pico to do a lot of the workload
<clever>
but i dont plan to use it for major debug, just simple things like getting a backtrace and register dump
<PaulFertser>
clever: the real trick is that ARM Debug Interface protocols (both SWD and the debug protocol running on top of JTAG as a transport) were /also/ designed with batching in mind.
<PaulFertser>
So it's not like you gain that much trying to make a probe any smarter than cmsis-dap.
<clever>
yeah
<PaulFertser>
clever: basically, you give it a sequence of commands and then you get a response that tells you on which one it broke if at all (and the rest wasn't executed).
<clever>
nice and simple
<clever>
and if all succeed, you get an array of results?
<PaulFertser>
clever: it's not like you'll waste much time implementing remote_bitbang so go for it, see if it's probably enough for the usecase.
<PaulFertser>
clever: exactly
<clever>
and for that batching, the debug adapter would need to have some understanding of success vs failure
<clever>
so it can pause after each command, and test something
<PaulFertser>
clever: it doesn't need to pause it just gives the whole reply back over USB or other high latency link.
<clever>
i mean for the failure case, where it stops in the middle of a batch?
<PaulFertser>
The OpenOCD learns from the array of results/statuses where it failed.
<clever>
but if its supposed to stop on the first command that failed, it needs to know when something is a failure?
<PaulFertser>
clever: the debugee itself just ignores the rest of the commands it received after it failed executing one. So nobody needs to care to stop.
<clever>
https://www.fpga4fun.com/JTAG2.html my rough understanding of jtag, is that you can use TCK and TMS to step thru this a state machine (2nd image), and then use TDI and TDO to shift data into either the IR or DR register, and IR acts as an index, to route DR somewhere
<clever>
so IR is basically a register#, and DR then maps to the given register
<clever>
ahhh
<PaulFertser>
clever: bitbanging JTAG requires low latency, same about SWD. I'm talking about the protocols running on top of them.
<clever>
so you can basically just shove constants into IR and DR in the right sequence, and capture what TDO emits from DR, and send the whole bitstream back to openocd
<clever>
yeah, i can hw accelerate the whole jtag part, using the PIO block on the pico
<PaulFertser>
clever: you can read ADIv5 PDF if you're interested about how exactly JTAG DR maps to debug functionality.
<clever>
in the broadcom rpi SoC's, the arm jtag has 3 modes, off, gpio, and jtag bash
<clever>
gpio, routes the arm jtag signals into the gpio alt-function matrix, and can expose them on physical pins
<clever>
but that jtag bash one has caught my eye for years, i suspect its a hw block to bit-bang jtag from within the SoC (from a management cpu), without using external pins
<clever>
PaulFertser: do the bit defines on 384-410 catch your eye?
<clever>
and just the fact that it has registers called TMS, TDI, and TDO
<PaulFertser>
clever: hm no
<PaulFertser>
TMS/TDI/TDO are familiar naturally
<clever>
to me, it feels like you load some data into TMS and TMI, then hit something like the BITS12 flag, to shift TMS/TDI out to the arm core over 12 clocks
<clever>
and whatever the arm core returns, winds up in the TDO register
<clever>
(maybe swap TDI and TDO)
<PaulFertser>
Probably
<PaulFertser>
That would be a generic enough way to implement JTAG over MMIO registers.
<clever>
yeah
<clever>
and if i cross-reference to ADIv5 PDF, i should be able to poke it enough to confirm some signs of life
<PaulFertser>
Requesting IDCODE would be a start
<clever>
yeah
<clever>
and isnt that loading all 0's or all 1's into IR?
<clever>
and then reading DR
<PaulFertser>
IIRC after reset the IR is preloaded with IDCODE instruction so you can just read out DR.
<clever>
ahh
<clever>
and when in the Shift-IR state, that IDCODE instriction would also leak out of the TDO pin, as you shift in the next IR?
<PaulFertser>
Yeah
<clever>
since the hw has little way to know, if its the first in the chain or not, and what put the code into IR
<clever>
so it must act like a shift-reg
<PaulFertser>
Both IR and DR act as shift regs, yes.
<PaulFertser>
In a sane, compliant implementation.
<clever>
this is a second jtag port on the rpi SoC's, for the chip overall, and the videocore cpu
<clever>
the VPU jtag is normally always accessible (but a fuse can be burned to disable it somehow)
<clever>
the ARM jtag is only accessible if the VPU software enables it, and the jtag port goes offline during reboot, causing openocd to get upset (when ive bit-banged it in the past)
<clever>
> Figure A1-2 Structure of the DAP, showing DPv0 JTAG-DP accesses to a generic AP
<clever>
ah, found this figure, looks like the DP on arm just has 4 registers in the jtag layer? DPACC, IDCODE, ABORT, APACC, and maybe BYPASS?
<PaulFertser>
BYPASS is generic, any decent JTAG device supports that instruction and provides a single-bit BYPASS DR for that.
<clever>
i knew that, but the diagram is a bit confusingly draw, with BYPASS being a label on the output of DPACC
<clever>
maybe the effective length of the DPACC shift reg changes when in bypass mode?
<PaulFertser>
In bypass mode nothing is happening and it's doing nothing other than passing through single bit shift register.
<clever>
yeah
<clever>
they just put BYPASS in a weird place on the diagram, it feels like they are using bit0 of DPACC as the bypass register
<clever>
i think APACC then selects what you want to address? and DPACC is the data port?
<zapb__>
clever, the jlink net protocol is quite straight forward
<clever>
it looks like you load DPACC into the jtag IR, and then load 8 into ???, to then access the "AP Select (SELECT)" register
<clever>
but where does that 8 go?
bvernoux has quit [Read error: Connection reset by peer]
<PaulFertser>
Sorry, it's been long time since I last read ADI.
<clever>
from what i can see, the DP acts as a mux, to allow multiple AP's to share a single jtag port easily
<clever>
so a chip designer can take the AP from every component, and shove them all into a single jtag port
<clever>
and the AP's then provide control over a single thing, like debugging a cpu core, or accessing the system bus, or a rom that describes all of those connections
<Hawk777>
There are some chips that do exactly that in practice; STM32H7 is an example. It has three APs on one DP. AP0 is the main one that accesses the CPU core and the system bus. AP2 is a secondary path to certain debug hardware, which works when the system bus doesn’t work due to clocks being stopped. I can’t remember what AP1 is for.
<clever>
and i assume that the videocore series of chips, had something incompatible (arm was added later in its development), so they couldnt mesh their stuff into an AP
<clever>
and they instead just had 2 entirely seperate jtag ports
<clever>
ah, section B2.1.3, says that the 8 to access SELECT, needs to be in DPBANKSEL
<clever>
but that seems to be a sub-section of SELECT....
<clever>
ah wait, misread it, DPBANKSEL is "dont care" when writing to SELECT
<clever>
the 8 goes into "address" which isnt specified clearly yet
<Hawk777>
In JTAG, the DR (for DPACC and APACC) is 35 bits wide, and when you want to do a DPACC to write to SELECT, you load the DPACC instruction into IR (if not already there), and then the 35 bits you load into DR are the 32 bits of data plus three extra bits, which are bits 3 and 2 of the address (hence the 8 of select would put 10 in those bits) and the indication of whether you want to read or write.
<Hawk777>
See B3.4.3
<Hawk777>
If you’re on IHI0031D anyway, not sure what revision you’re looking at.
<Hawk777>
In SWD, it looks like A[2:3] are part of the “write packet request” or “read packet request”.
<Hawk777>
See B4.2.1/B4.2.2.
<clever>
Hawk777: the thing i'm confused about, is that the 35bit DPACC, seems to map to one of the "DP Registers", but you also write to DPACC to select which DP register?
<clever>
or, is writes just always giving addr+data, in that 35bit?
<clever>
then how does reads work?
<clever>
SELECT is write-only, so i can see how you can just throw an addr+data at the hw, as a 35bit blob, and it can do everything in one shot
<clever>
but then you have things like EVENTSTAT, where you need to set DPBANKSEL (via a write to SELECT), then somehow set the addr to 4 and read 32bits?
<Hawk777>
A DPACC DRSCAN gives both the data and also part of the address.
<clever>
Hawk777: yeah, but thats for writes, its reads that i'm confused about
<Hawk777>
A read is just the same as a write but with RnW set.
<Hawk777>
So you write to SELECT to get DPBANKSEL set same as you always would.
<clever>
so, you give it the 3 bits of addr+rw, and then the next 32 bits out of the shift register are the data?
<Hawk777>
Then you do a DRSCAN with A[2:3] set to point at EVENTSTAT, but RnW=1 so it doesn’t write.
<Hawk777>
Then the next DRSCAN you perform (to *anything*) contains the result of the read.
<clever>
ahhhh, thats what i'm missing
<Hawk777>
If you don’t want to touch any other register, you can point that next DRSCAN at RDBUFF.
<Hawk777>
And don’t forget to check ACK.
<clever>
so you write 35bits to the DR shift reg, then cycle the TMS state machine for one lap, and read 35bits back out of the DR reg
<Hawk777>
Yep. And since it’s a shift register, while you are shifting those result bits out, you are also simultaneously shifting another DPACC data+A+RnW in, which will execute after that shift.
<clever>
and yeah, you could then write something else to DR, as your answer shifts out
<Hawk777>
Except it will *not* execute if your ACK bits say WAIT.
<Hawk777>
That’s what you want, you can just shovel commands in without worrying about inter-command dependencies; if you hit a WAIT, the following command won’t run anyway even though the previous hasn’.t
<clever>
and where is the ACK and WAIT?
<Hawk777>
ACK and WAIT are in the bottom 3 bits of the DR that you receive.
<Hawk777>
Same place that A[3:2] and RnW are for data that you send.
<clever>
ah, so when you shift in, you give it 32bit of data, 2bit of addr, and 1bit of r/w
slobodan has quit [Ping timeout: 276 seconds]
<clever>
and what shifts back out, is 32bit of data, and 3bit of ack/wait flags
<Hawk777>
Yep!
<clever>
so, you can basically just have a bit old array of 4bit IR codes, and 35bit DR codes, (type+data)
<clever>
and you just shovel each thing into the jtag, one at a time, and store the 35bit replies (or just 32bit?) into the final reply back to the host
<Hawk777>
Well, you’ll get better performance if you skip IRSCANs if you’re doing the same type of access.
<Hawk777>
But yes you could.
<clever>
yeah
<Hawk777>
Maybe that’s an optimization you do on the adapter end of things.
<clever>
i would say the command generator should do that
<clever>
only if the next access is to a different IR, would it insert an IR code into the command stream
<Hawk777>
Yeah.
<Hawk777>
That makes sense.
<clever>
so openocd is responsible for not generating duplicate IR's
<Hawk777>
When talking to a dumb adapter, yes, I believe it does that.
<Hawk777>
(e.g. an FTDI)
<clever>
from what i can remember, the FTDI can basically be re-programmed as a lop-sided SPI interface
<Hawk777>
Yep.
<clever>
with 2 data out, 1 data in, and a clock
<Hawk777>
You probably want the adapter to retry when you get a WAIT, rather than going all the way back to OpenOCD over the network.
<clever>
yeah
<clever>
and i can just not record the WAIT's in the output stream
<Hawk777>
If your adapter is really dumb, you can’t really do much batching, because you could have three requests (A, B, C), and if you just batch them up, A takes a long time, B gets shifted in and discarded (and returns the WAIT reply), and then C gets shifted in and executes (because by now A is finished, and it returns the result), but maybe C shouldn’t have happened if B didn’t happen.
<Hawk777>
If the adapter handles WAITs, that batching is fine because it’ll keep retrying B until it actually executes before moving on to C.
<clever>
yeah
<clever>
ive got ~260kb of sram
<clever>
so i can easily store a huge set of commands, and wait on them before returning a batch
<Hawk777>
That seems like plenty to make something pretty smart.
<clever>
its already running a whole networking stack
<Hawk777>
But maybe you want to make it talk CMSIS-DAP, since that’s pretty much a standard? That’s a little bit higher level I think, though I’m not really familiar with it.
<clever>
i'll need to look over what that does
<clever>
but i do also want to understand the lower level stuff as well
<Hawk777>
It looks like the CMSIS-DAP command set has a command that just does a whole register read/write (so the adapter would automatically update SELECT if needed, and then do the APACC or DPACC with retries as needed to make things happen).
<clever>
and which state then causes things to execute, and the DR to be updated with the result?
<Hawk777>
Update-DR causes the operation to occur.
<Hawk777>
(well, to *start*)
<Hawk777>
And then Capture-DR causes either OK+data or WAIT to appear in DR.
<clever>
ahhh
<clever>
so Capture will atomicly copy the DR (which may have a "still busy" flag) into the shift reg
<clever>
and then Shift-DR lets you read that result out, while giving it the next command
<Hawk777>
Anyway, if you roll your own protocol, you probably want some way of identifying whether the retry logic should be applied to a particular DRSCAN or not, because you don’t want to apply ARM’s retry logic to some random other JTAG device which happens to have a 35-bit DR but doesn’t speak this protocol at all.
<Hawk777>
Yep!
<clever>
but, youll have already started giving it a new command, before you can realize the previous is in WAIT
<Hawk777>
*Literally* while giving it the next command, since one bit goes in *and* one bit comes out for each clock cyle.
<clever>
but, you can go from shift->exit->capture, to loop, without hitting update
<clever>
so the thing you just gave it, never actually executes
<Hawk777>
You can’t go from exit to capture…
<Hawk777>
That arrow points the other direction.
<clever>
ah oops, exit2 and the arrows confused me
<Hawk777>
The reason why what you said isn’t a problem is due to the sentence in B3.4.3 in the “WAIT response to a DPACC or APACC access” subsection which says “No request is generated at the Update-DR state, and the shifted-in data is discarded.”
<clever>
so, youll have given it 1 bit (r/w flag) of the new command, before you got the first bit of the out
<clever>
ahhhh
<clever>
and i assume there is no race condition, where WAIT clears itself, after capture, and during shift?
WeaselSoup has quit [Ping timeout: 255 seconds]
<Hawk777>
There shouldn’t be. That would be a buggy chip.
<Hawk777>
Because in the spec, it’s not about whether the request is *currently* in progress or not, it’s about whether the *response to the DPACC* was OK or WAIT.
<clever>
so capture is also copying the DR to some shadow registers, so it knows what WAIT was at the last capture
<Hawk777>
At least the OK/WAIT part I guess.
<clever>
and in the event of a race, it knows that the host saw WAIT, and it should ignore and wait for anothre capture
WeaselSoup has joined #openocd
<Hawk777>
Oh, also, I explained all this without mentioning the “overrun detect” flag, which changes the behaviour slightly: with that enabled, if you ever get a WAIT, then *all* subsequent APACCs stop working until you explicitly clear the indication, whether or not the operation has finished. That allows a dumb adapter to be driven with fewer turnarounds, as long as you carefully tune the timing so WAITs don’t happen in the common case.
<clever>
so that also means, when you loop and try to read WAIT again, you can just re-send the "next" command
<Hawk777>
Yes.
<clever>
until it stops saying WAIT
<clever>
ah i see what you mean, so that makes the WAIT more sticky, so if command 4 stalls for one cycle, 5 doesnt then take effect without 4
<clever>
so a dumb adapter that keeps on truckin will have everything fail
<clever>
like an ftdi just working its way thru a usb packet
<Hawk777>
Yep. If I understand correctly, the subsequent commands (after the first one that returns WAIT) actually return OK/FAULT, *not* WAIT, as they are considered to have instantly failed rather than being delayed.
<clever>
yeah
<clever>
is that a mode you can turn on/off?
<Hawk777>
But STICKYORUN is a type of failure whose behaviour is well-defined and that allows things to be retried.
<Hawk777>
Yeah, CTRL/STAT.ORUNDETECT controls it.
<clever>
so a smart adapter can turn it off, because its able to handle WAIT
<Hawk777>
Yep.
<Hawk777>
Actually it looks like it defaults to disabled.