whitequark[cis] changed the topic of #glasgow to: https://glasgow-embedded.org · digital interface explorer · https://www.crowdsupply.com/1bitsquared/glasgow · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.irclog.whitequark.org/glasgow · matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
cr1901_ has joined #glasgow
cr1901 has quit [Read error: Connection reset by peer]
mats1 has quit [Ping timeout: 248 seconds]
mats1 has joined #glasgow
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
andymandias has quit [Read error: Connection reset by peer]
andymandias has joined #glasgow
Stary has quit [Quit: ZNC - http://znc.in]
Fridtjof has quit [Quit: ZNC - http://znc.in]
Stary has joined #glasgow
Fridtjof has joined #glasgow
<mcc111[m]> It is! And once again UPS's online communications are simply misleading.
jstein has joined #glasgow
galibert[m] has quit [Quit: Idle timeout reached: 172800s]
Nekron[m] has joined #glasgow
<Nekron[m]> I've got also shipment notification for FedEx (delivery to Germany)... so very excited!
zerobytesecurity has joined #glasgow
<zerobytesecurity> mine shippped to now what to do first?
<zerobytesecurity> s/shippped/shipped/, s/to/too/
<jn> hmm, i'm probing a JTAG port, and the result is TAP #0: IR[8] BYPASS. any idea how to make it show up with an IDCODE?
<whitequark[cis]> you can't
<whitequark[cis]> if it shows BYPASS there is no IDCODE in the silicon
<whitequark[cis]> IDCODE/BYPASS are basically prefix coded. you reset the device and if DR starts with 1 it's IDCODE followed by 31 identification bits, with 0 it's BYPASS (i may have swapped 0/1)
<whitequark[cis]> s/device/TAP/
<whitequark[cis]> it's somewhat upsetting that (a) IDCODE presence is not mandated and (b) the IR pattern for IDCODE is not fixed by the spec
<jn> but it might still work for debugging if i find a bypass?
meklort has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
meklort has joined #glasgow
<whitequark[cis]> <jn> "but it might still work for..." <- can you explain what you're doing in more detail?
<jn> i have a cisco switch from circa 2002, with a powerpc SoC (MPC8245) on it. i found the connector that is likely connected to the processor jtag. glasgow's jtag-pinout found a pinout, then jtag-probe found the bypass mentioned above
<jn> my plan is to attach another debug adapter that supports this SoC, and trace the communication, to reverse-engineer the jtag-based debug protocol
vegard_e[m] has joined #glasgow
<vegard_e[m]> the BSDL file for MPC8245 agrees that there's no IDCODE: https://bsdl.info/view.htm?sid=bc9aa80bd2e4ae5f88ca59b002289d77
<jn> vegard_e[m]: that's a very useful website, thanks!
<whitequark[cis]> <jn> "but it might still work for..." <- oh. so the only difference between IDCODE and BYPASS is that you don't get the IDCODE
<whitequark[cis]> there's no functional difference
<whitequark[cis]> (the JTAG applet assumes expert-level knowledge of JTAG)
<jn> got it, thanks
<vegard_e[m]> the thing about JTAG is also that it only standardizes boundary scan, not debug
<vegard_e[m]> any debug interface over JTAG is an extension and there's a lot of different ones
<whitequark[cis]> yep
<whitequark[cis]> also some things are blatantly not JTAG compliant
<whitequark[cis]> the worst offender is likely MSP430
<jn> vegard_e[m]: yep :/ (hence my plan to RE this particular JTAG-based debug interface)