<pie___>
like i bet this is super easy for someone who has a damn clue :/
mrpackthead has quit [Read error: Connection reset by peer]
<shapr>
meh, we all have different clues
rohitksingh has joined ##openfpga
Dolu has joined ##openfpga
genii has joined ##openfpga
pie___ has quit [Ping timeout: 245 seconds]
eplum has quit [Quit: Connection closed for inactivity]
Bob_Dole has quit [Ping timeout: 250 seconds]
Bob_Dole has joined ##openfpga
Miyu has joined ##openfpga
<whitequark>
azonenberg_work: btw i'm going to try plugging glasgow jtag into jtaghal
<whitequark>
so going to refactor it a bit
<azonenberg_work>
refactor glasgow?
<azonenberg_work>
or jtaghal :)
<whitequark>
jtaghal duh
<whitequark>
glasgow is already perfect
<whitequark>
:P
<azonenberg_work>
Lol
<azonenberg_work>
what did you want to change?
<whitequark>
azonenberg_work: factor out libusb stuff for glasgow
<whitequark>
since that part is identical for jtag and swd
<azonenberg_work>
ah, ok
<azonenberg_work>
Makes sense
<azonenberg_work>
I did that with FTDI recently if you look
<azonenberg_work>
FTDIDriver is now used by both FTDIJtagInterface and FTDISWDInterface
<q3k>
mwk: didn't you also want to refactor something in jtaghal? ^
<sorear>
so if I wanted to understand JTAG software and JTAG dongles with a focus on tethered debug (all of the parts of the stack "above" 1149.1 and "below" gdb), anyone have recommendations on where to start looking
<azonenberg_work>
sorear: tethered debug of what
<azonenberg_work>
The protocols are completely different for each vendor/cpu family :p
<whitequark>
sorear: start with 1149.1?
<azonenberg_work>
1149.1 then, if you're interested in ARM stuff, the ARM Debug Interface specification
<azonenberg_work>
i forget the doc number but you can find it on google easily
<sorear>
azonenberg_work: i'm probably going to invent a debug interface for this project b/c the draft riscv debug interface would be more than half of my LUT budget
<sorear>
but I'd still like to talk to gdb with a "maximally normal" intermediate stack
<azonenberg_work>
well ADI is specific to the arm architecture and theres probably a patent minefield if you use it for anything else
<azonenberg_work>
If you want a minimalistic debug architecture i'd suggest you go with what MIPS has
<sorear>
i believe the usual flow is gdb -> openocd -> ??? dongle drivers -> ??? dongles -> DUT
<azonenberg_work>
Basically, you have a certain region of physical address space memory mapped
<gruetzkopf>
sorear: how about mmodeless riscv?
<azonenberg_work>
And a jtag register to read the address/data it wants to access and respond with data
<sorear>
gruetzkopf: the debug protocol still has >100 bits of state
<azonenberg_work>
sorear: you're worried about 100 dffs?
<azonenberg_work>
how big is your whole soc
jevinskie has joined ##openfpga
* azonenberg_work
looks over at designs using tens of kdffs
<azonenberg_work>
gruetzkopf: anyway to load a debugger stub, you use a command/signal somewhere to make the cpu jump to that debug memory area
<azonenberg_work>
you start feeding it instructions
<azonenberg_work>
then it can memcpy data to/from that region
<azonenberg_work>
etc
<azonenberg_work>
so the hardware support is pretty minimal
<azonenberg_work>
but you still need a few hundred bits of state just for jtag registers
<sorear>
azonenberg_work: this project is "what is the absolute minimum if you don't care about CPI", which is currently looking like 200-400 LUT4+FF
<sorear>
75% a learning exercise for myself, but I'm going to publish it anyway in case somebody ever has a use for it
<sorear>
since it's not a design point anyone else has really been pushing
<azonenberg_work>
in that case the debug interface would be a single IRQ signal that makes it jump to a hard wired debug interrupt address
<azonenberg_work>
And then you add your own system-dependent logic to the memory bus to do the rest
<azonenberg_work>
i would avoid having a jtag TAP in the cpu core itself since a real soc will normally have more things to debug than just the cpu
<sorear>
wouldn't that normally be handled by jtag chaining?
<azonenberg_work>
Well, if you have 30 taps in a single chip it gets awkward :p
<azonenberg_work>
in particular, the more taps you have the less efficient jtag is
<azonenberg_work>
2-3 is fine but 10-20 starts to add significant overhead
<azonenberg_work>
since you need a padding bit for every tap
<azonenberg_work>
extreme example, if you have 33 taps
<azonenberg_work>
scanning a 32-bit register has 50% overhead vs a single tap
<azonenberg_work>
scanning a 1-bit status register has 3200% overhead
<sorear>
I take it that IR shifts are much less common than DR shifts, b/c nobody seems to talk about the much larger overhead of IR shifts
<azonenberg_work>
Yeah they are a lot less common in performance critical code
<sorear>
(why is there no mechanism to get the instruction register length during IDCODE probing?)
<azonenberg_work>
Anyway the ARM debug protocol gets around this by having the jtag block give access to your memory bus
<azonenberg_work>
then everything else is memory mapped
<azonenberg_work>
So typicall an arm soc of any size will have two taps
<azonenberg_work>
one for boundary scan and maybe some custom top-level commands (since the arm debug tap is an ARM IP you cant usually change)
<azonenberg_work>
and one for debug of all cpus and peripherals
<azonenberg_work>
sorear: and thats a good question, i wish i had an answer
<azonenberg_work>
jtaghal does include logic to infer IR length in some cases
<azonenberg_work>
in particular, for a jtag chain of any size
<azonenberg_work>
if you have exactly one unknown device IDCODE you can calculate the IR length
<azonenberg_work>
Since you can calculate the total IR length, and you can subtract the known IRs from that
<azonenberg_work>
But for multiple unknown devices all you can tell is the sum of their IR lengths
<azonenberg_work>
and not where in the chain the bits are allocated
<azonenberg_work>
In jtaghal, i try to figure out based on full or partial IDCODE the IR length of as many chips as i can and then create a "filler" device if i find an unknown idcode
<sorear>
anyway my question was more "what does jtaghal do, who are its consumers, what does it talk to, what alternatives to it exist"
<sorear>
not "help me design a debug protocol"
<azonenberg_work>
sorear: jtaghal is an API to jtag and (WIP) SWD
<azonenberg_work>
at pretty much all levels of the stack, although not complete at the higher levels
<azonenberg_work>
At the adapter level I support Glasgow via libusb, FTDI dongles via the blob API (and eventually the open library, have to review the PR for that)
<azonenberg_work>
Digilent dongles via the blob API (maybe eventually some of them via libusb thanks to diamondman)
<azonenberg_work>
and finally, arbitrary dongles (either a custom implementation with a LAN interface, or a socket server to one of the above devices) using my protobuf-based TCP socket protocol
<azonenberg_work>
starshipraider will speak that protocol natively
<azonenberg_work>
you could also, with some effort, write a bridge that speaks to a xilinx virtual cable, openocd device, etc
<azonenberg_work>
none exist yet
<azonenberg_work>
sorear: anyway, then I have a C++ API to a range of devices at higher levels
<azonenberg_work>
i have full support for the 32-bit ARM debug interface, decent support for the 32-bit MIPS debug interface
<azonenberg_work>
then as far as CPU debug vs just ram access
<azonenberg_work>
i can halt-resume and inspect registers for Cortex-M CPUs
<azonenberg_work>
There is no gdbserver yet but it wouldnt be hard to add
Laksen has quit [Quit: Leaving]
<azonenberg_work>
There is no register modify support but it wouldnt be hard to add
<azonenberg_work>
Cortex-A support is lagging because that is a lot more complex
<azonenberg_work>
I have pretty solid support for programming and talking to xilinx FPGAs of various types
<azonenberg_work>
Zero boundary-scan support, that was never a priority (I have a ticket for it but never went anywhere)
<sorear>
what do you use jtaghal for if there's no gdbserver?
<azonenberg_work>
mostly? FPGAs
<sorear>
are there differences of kind between cortex-a and cortex-m debugging, or is it just "more registers"? (which does cortex-r more resemble?)
<azonenberg_work>
The ARM support was added pretty recently
<azonenberg_work>
My understanidng is cortex-R is mostly Cortex-A but with a simpler MMU
<azonenberg_work>
I have a custom shell similar to the openocd CLI that lets you do raw memory read-write transactions on an arm device
<azonenberg_work>
And i have scripted commands for things like dumping flash
<azonenberg_work>
checking if a stm32 is read-locked
<azonenberg_work>
etc
<azonenberg_work>
STM32 support is pretty decent - I can dump flash, bulk-erase, set/clear protection. and flash a raw binary memory image (no ELF support yet, that's next on the list)
<azonenberg_work>
it's only tested on... i think the F411
<azonenberg_work>
But should in theory support most of the other parts
<azonenberg_work>
if you add the idcode to the database
<azonenberg_work>
sorear: Cortex-A and Cortex-M debug are completely different at the top level of the stack, below there it's the same
<sorear>
does it use BSDL in any way?
<azonenberg_work>
basically, the arm debug interface gives you access to a memory bus that talks to debug registers on each CPU
<azonenberg_work>
and a ROM or hierarchy of ROM tables that stores metadata about what CPUs or other debuggable IP blocks are at what address ranges
<azonenberg_work>
it's all self-describing
<azonenberg_work>
But the SFR set for a Cortex-M vs a Cortex-A is completely different
<azonenberg_work>
once you're on the debug bus there is nothing in common
<azonenberg_work>
jtaghal does not use BSDL whatsoever, BSDL is actually of very limited use outside PCB self-test
<azonenberg_work>
it assigns names to hex instructions and tells you the instruction length
<azonenberg_work>
and the idcode
<azonenberg_work>
thats it
<sorear>
do fossi people just squat random idcodes?
<azonenberg_work>
The only full jtag tap i made was a command-compatible clone of a xilinx part
<azonenberg_work>
So i used their idcode
<sorear>
32-bits is kinda not large enough to reliably avoid collisions
<azonenberg_work>
Yeah
<azonenberg_work>
The proper option would be to go to jedec and register a vendor code
<azonenberg_work>
aaanyway, jtaghal does not use bsdl because there isnt much of a point
<azonenberg_work>
i have a hard coded database of device IDs that instantiate different C++ classes with different protocol support code
<azonenberg_work>
If someone writes a f/oss bsdl parser (no good non-GPL ones exist to my knowledge)
<azonenberg_work>
I will gladly add code that creates "dummy" devices if it finds a matching BSDL
<azonenberg_work>
But you still wont be able to do anything other than seeing the chip ID
<azonenberg_work>
and, if i add support, boundary scan of the IO pins
<sorear>
so in the final jtaghal world it'll be gdb -> jtaghal -> libusb and/or libftdi -> [OS USB stack] -> [glasgow or ftdi] -> 1394.1 bus
<sorear>
and jtaghal's scope *mostly* overlaps with openocd
<sorear>
in that openocd implements a gdbserver and uses various libraries to talk to usb devices
<sorear>
and they have that cute jtag over tcp thing
<azonenberg_work>
sorear: it would be gdb -> jtaghal_gdbserver
<azonenberg_work>
probably then talking to jtagd
<sorear>
i have an openocd checkout here but I haven't managed to make much sense of it
<sorear>
is jtagd a thing which already exists?
<azonenberg_work>
jtaghal itself is a library, so you'd have to write a gdbserver that either calls into the library itself, or talks to jtagd (which bridges jtag out to a TCP socket using google protobufs)
<azonenberg_work>
jtagd is roughly equivlanet to openocd's tcp server, or the xilinx xvcd
<azonenberg_work>
but at a higher level (chain manipulation commands instead of raw TDI/TDO/TMS bits)
<sorear>
how many tcp servers does openocd have? i only know about the hella low level 'remote bitbang' one
<azonenberg_work>
So you have commands to do things like "set IR of device 3 in the chain to 0x41414141" and the padding bits are added server-side
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined ##openfpga
<sorear>
TIL about ?ts
pie__ has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
<sorear>
azonenberg_work: is jtaghal_gdbserver a thing which is (a) ready to be done (b) could be done by someone with limited experience in the system
<azonenberg_work>
sorear: a) yes, b) not sure
<azonenberg_work>
however
<azonenberg_work>
there is some refactoring that will probably be needed in the DebuggableDevice class for it to be really clean
<azonenberg_work>
And some features, like modifying CPU registers, arent implemented yet
<azonenberg_work>
I'd rather hold it off a little bit still
<sorear>
once that exists, what would still be an appropriate reason to use openocd?
pie__ has quit [Ping timeout: 276 seconds]
<azonenberg_work>
well, openocd has a much larger set of devices supported on the CPU side of things
<azonenberg_work>
jtaghal started as an FPGA tool and gained CPU support recently
<azonenberg_work>
But jtaghal is also IMO a cleaner API and is non-GPL if you care about such things
<sorear>
are there other stacks I should look into besides openocd/jtaghal? do they look similar from 10000ft to openocd/jtaghal?
<azonenberg_work>
None that i know of
<azonenberg_work>
openocd is lke the de facto standard now and i made jtaghal to avoid working with it :p
<sorear>
I'm guessing that at least a few of the silicon vendors used to have their own stacks, like how ARMCC used to be a thing
pie__ has joined ##openfpga
Bike_ has joined ##openfpga
Bike has quit [Disconnected by services]
Bike_ is now known as Bike
Miyu has quit [Ping timeout: 244 seconds]
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has quit [Ping timeout: 250 seconds]