00:12 <joshua_> also not being able to know how long the IR is really sucks too.

00:14 <whitequark[cis]> the glasgow JTAG applet does the maximum possible effort in estimating IR lengths in a multi-TAP chain

00:14 <vegard_e[m]> going by the block diagram on page 529, the TAP might not implement anything more than plain boundary scan: https://www.nxp.com/docs/en/reference-manual/MPC8245UM.pdf

00:18 <whitequark[cis]> the reason the diagram looks that way is probably because they're hiding how the debug interface works

00:18 <whitequark[cis]> this is likely in a misguided attempt to impede security research

00:19 <whitequark[cis]> vendors lie about JTAG all the time

00:19 <vegard_e[m]> the BSDL mentions a TLMSEL, and a TLM is apparently a «TAP linking module»

00:19 <whitequark[cis]> oh, it has a JTAG mux. how exciting

00:20 <vegard_e[m]> docs for other freescale chips say a little bit more about it, but not much useful

00:21 <josHua[m]> 2005 is kind of from the time before security, though

00:30 <whitequark[cis]> sorta but not really? freescale took it more seriously than most

00:39 <jn> the Abatron BSI3000 debugger (which i have access to) claims to support MPC824x among other chips

00:40 <jn> semi-official statement i've read on the freescale/nxp forum: https://boopsnoot.de/@jn/112402035920777862

00:40 <jn> "This interface uses internal possibilities of processor core and this information is closed."

00:42 <whitequark[cis]> josHua: by "security" i mean "debug interfaces can often be used to bypass code protection"

00:43 <whitequark[cis]> which was never well tolerated

00:43 <josHua[m]> yeah, in the back of my mind, I sort of think of that era as having debug interfaced undocumented 1) because they couldn't be bothered to document them, and 2) because they would expose microarchitectural details that they would rather keep proprietary for no real reason

00:44 <josHua[m]> rather than 3) because there was any expectation that code protection actually worked against any attacker who was capable of looking at a block diagram

00:45 <whitequark[cis]> mmmhm

00:45 <jn> i definitely found some microarchitectural details in there. a pre-decoded instruction format, i think

00:45 <jn> the code (in another debugger's firmware) looks like they compiled a netlist to C and then to ppc asm

00:46 <whitequark[cis]> ow

00:46 <jn> the source/destination register fields in PPC instructions are a bit inconsistent. the pre-decoder seems to normalize them, swapping them in some instruction formats

01:29 <duskwuff[m]> "we built this debug port for our own engineers, its utility to outside software developers is a convenient* side effect"

05:59 <chipb> can’t charge your customers extortionate rates for debug probes and software if they can just build their own for less cost…

07:16 <jn> chipb: yeah, that might be the main reason

10:40 <q3k[cis]> <josHua[m]> "2005 is kind of from the time..." <- i mean, even the AVR JTAG docs are withheld for the same reason, this isn't anything new

10:43 <q3k[cis]> (of course someone reverse engineered this, anyway http://ftp.twaren.net/Unix/NonGNU/freeice/AVR-OCD-Documentation.html )