✧✦Catherine✦✧
in the upcoming #GlasgowInterfaceExplorer ARM7TDMI debugger, here is how you can read system memory using just a few lines of Python
this avoids the need for any existing interface like GDB server as it lets you easily manipulate CPU state in every feasible way
✧✦Catherine✦✧
the advantage of the implementation strategy I picked is that the entire read is done in one long burst without requiring more than a single USB roundtrip; as a result, it occurs at the maximum speed the JTAG interface can provide
(nobody cares about ARM7TDMI, but the technique generalizes to CoreSight, and will be even faster there)
✧✦Catherine✦✧
@azonenberg @abrasive technically this is 1149.1 noncompliant but it definitely works
(oooor you could be like me and implement your own debug probe, not beholden to inefficiencies of FTDI :3)
Andrew Zonenberg
@abrasive @whitequark Especially for reading data - you'd have to poll a status register to find out data was ready, then read the data itself after round tripping, etc.
So my next version of the debug interface completely sidestepped all of that and did unholy things with JTAG instead.
Andrew Zonenberg
@abrasive @whitequark I loaded USER1 into IR (this was a Spartan-6 FPGA) and then entered SHIFT-DR state.
And free-ran TCK.
The debug bridge would constantly shift in idle words if you had no data to send, and check the response data from the DUT for a preamble. As soon as it saw a 55 55 55 D5 it knew the DUT was sending traffic and would parse it appropriately.
So you effectively had two independent unidirectional streams of 32-bit words sent bit serial, each synchronous to TCK but with no tight coupling to each other. This let me use large bulk transfers over the MPSSE and completely eliminated polling, which was far more efficient.
Andrew Zonenberg
@abrasive @whitequark So the high level concept is that the debug interface was bridging datagrams in the on-chip interconnect out to a TCP socket on the client PC.
Essentially each client (unit test, logic analyzer, etc) connected to the debug server would get a virtual device ID that it could use to send and receive packets to on-chip devices as if it were a very slow on-chip IP.
The bus words were all 32 bits wide so the natural implementation over JTAG would be a single 32-bit scan register that you'd hit over and over to send multiple words.
The problem is, this is slooow especially if you're using FTDI things that run over USB 2.0 with large bulk transfers etc.
Andrew Zonenberg
@whitequark Nice.
Have we ever talked about the horrible perversion of JTAG I implemented for debugging my thesis system? This kinda reminds me of it
abrasive
@azonenberg @whitequark I'm all ears for stories of perverted debug interfaces if you feel like sharing
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.