In summer of 2013 while looking for the next work challenge, I grabbed the opportunity to use my 'spare' time to further my knowledge, buy some more test equipment and the new Beaglebone Black I'd been dreaming about, and joined an open-source Google Summer of Code project PRU/JTAG to help out.
The things I liked about the project were:
- it involved the Beaglebone Black (BBB) which has 1 GHz TI Sitara AM335X ARM Cortex A8 SoC (System on Chip) processor, SD card, Ethernet, USB host and slave interfaces, HDMI, programmable I/O pins - the works - for $45!
- it involved developing a useful and inexpensive device (BBB-based high-speed JTAG debugger) that could be really helpful to others developing their projects
- it would use the PRUSS (Programmable Real-time Unit Subsystem) which is two 200 MHz independent co-processors included on the Sitara chip, to provide real-time signalling capability on external pins
- it involved an external plug-in board ('cape') with a CPLD (Complex Programming Logic Device) that would provide *really* high-speed signalling capability (MHz)
- learning more about JTAG (I'd used JTAG debuggers and emulators in the past - a godsend to improving software development productivity - but had no real idea how the signalling worked)
- the latest version of Linux, including possible work on the kernel itself
- the opportunity to get a crash skills upgrade course - learning from experts who have long been involved in the open-source Linux community
- the opportunity to help mentor students who are getting involved
It's been only a couple of weeks, and my expectations have already been wildly exceeded!
Project Members
Besides the student, there were already two project mentors who I'll refer to by their nicknames on the #beagle-gsoc IRC channel. KA6SOX is experienced with FPGA and CPLD devices and is the designer of the cape board. PANTO is very experienced in the Linux kernel and embedded development and, critically for this project, had just finished developing a driver model for Linux that communicated with code running in the PRU processors. KA6SOX imagined a JTAG debugger running at 5 MHz or higher, given all the hardware assist devices involved.
I came onto the project very shortly after it began. The engineering student (JJ2BAILE) was already familiar with JTAG standards and had developed a PRU program in assembly language, configured the Device Tree (a new hardware pin-configuration utility built into Linux 3.8 for ARM devices), and the PRU program toggled some pins on the BBB header to emulate the JTAG signals (TCK, TMS, TDI, TDO).
I wanted to get more hands-on with board-level work, possibly to make a board myself in the future. And I wanted to learn about CPLD and PRU, to control hardware at very high speeds - to learn how to program them.
But the last decade of working years has been primarily in the Microsoft Windows world developing .NET and C# applications, and some firmware development - I wanted to do more of that. I've worked with Arduino's, Microchip PIC, and ARM7 devices - a little FPGA with Verilog. I had never used the BBB before, and only knew vaguely what the PRU was all about.
On the plus side - I had used Unix extensively in the past, Ubuntu Linux, OpenWRT Linux for wireless routers, and written and debugged firmware in C for various targets and with various tools. I was familiar with command-line development (gcc compiler) and IDE (Eclipse), cross-development toolchains such as gcc, TI Code Composer Studio, Freescale Code Warrior, and Microchip MPLAB. And oscilloscopes, logic analyzers, microcontroller emulators, software-level debuggers, etc.
So I had no doubt I could make a positive contribution, but could I do it fast enough to make a difference to the project?
What Needed to be Done?
- Linux familiarity
- development tools
- research
From experience I knew it was critical to get familiar with running Linux on the BBB, and compiling software on it or for it. You can't develop software without the right computing environment and a toolchain (or several of them) in place.
But beyond that ... the project was about the communication between gdb and a JTAG target, and the details of EVERYTHING in the middle (OpenOCD, Angstrom Linux, PRU, CPLD, JTAG signalling) were new to me. A lot more unknowns were, at that point, unknown to me - although (like Donald Rumsfeld) I assumed they were there!
So I made an initial list of what to research first:
- OpenOCD, plug-ins, configuration and gdb server interface
- similar open-source projects
- JTAG
- PRU
- vrings
Research Phase 1
OpenOCD: Looking at the OpenOCD source code, I found the 'hooks' needed to communicate with various JTAG debugging devices - some used serial communication, others bit-bashing of I/O pins. Many JTAG debuggers supported by OpenOCD use the popular FTDI USB serial device interface for the communication connection. None use an ARM PRU for the communication channel. OpenOCD implements a gdb server (which can be TCP/IP socket based) which is how gdb communicates with it.
BlackMagic: The open-source BlackMagic project provides a small on-target debugger that implements a gdb server, and illustrates most of what OpenOCD is doing without the complexity of the OpenOCD 'Jim' scripts - which are a major part of configuring OpenOCD. It helped to clarify by presenting simpler picture of the concepts required.
OpenJTAG: The OpenJTAG project, not only provided an extension to OpenOCD (thus an example of how to do it), but also - like this project - used an intermediate CPLD as part of the communication link to the JTAG pins. Interestingly, OpenJTAG makes use of command bytes rather than bitstreams, and the CPLD converted each command into appropriate JTAG pin-signalling sequences. That approach seemed to have great potential to speed up communication for our project - critical, because to achieve MHz-scale speeds would require as little communication overhead as possible.
goJTAG: JTAG also is about Boundary Scan, not just debugging - scanning a JTAG-equipped board to see what JTAG-compliant devices are on it, and then sending them JTAG commands to check pin input and output states - it is for board testing. Some boards have multiple JTAG connectors. Asking the team, I found they did plan to perform Boundary Scans as part of their testing. OpenOCD did not seem to perform Boundary Scan (although it can be done using scripts) - but I found the goJTAG project that did.
Each of these open-source projects provided a slightly different view, on how to potentially implement a JTAG solution.
JTAG: Joint Test Action Group, also standing for IEEE 1149.1 Standard Test Access Port and Boundary-Scan Architecture. A very hardware-level view - impenetrable to me at this point. Fortunately the open-source projects would help in the understanding of the pin signalling needed, and how a JTAG-equipped board would respond. Besides talking to devices to control / monitor pin states, JTAG is also used for debugging (breakpoints, single-step), downloading firmware to a target board (the faster, the better), and logging execution sequences of the target for timing analysis.
PRU: Information on the TI websites and others describing what it is. How to program it (in assembler), how to load programs into the PRUs on the BBB, how to communicate between the PRUs and ARM processes? JJ2BAILE had a working demo including Device Tree overlays - a means of mapping hardware resources (pins) to SoC chip functions (registers). I had to learn a bit about DTs and how to use them on the BBB properly.
vrings: KA6SOX and PANTO talked about 'vrings' (virtual I/O) for the communication - I could find very little about that online, except in connection with Virtual Machines and that didn't quite fit how they were talking about vrings. It soon became clear that vrings were an in-memory FIFO list of memory buffers, written by one program and read by another - obviously it would be very fast to exchange information between processes that way. To communication bi-directionally would need two vrings. On the Sitara, each of the PRU processors had their own data and instruction memory, some memory shared between the two of them, and they could access the DRAM memory used by the ARM processor. So one end of the vring would be written by ARM Linux-side code, the other end read by PRU code.
I imagined two serial channels, one in each direction (ARM->PRU, PRU->ARM) and the need to have some kind of structure - rules for communicating, also known as a protocol - for the communications on them. The first to come to mind was a raw bitstream - a succession of bytes corresponding directly to JTAG pin settings. Each byte (presumably originated from OpenOCD) would be ultimately copied to the JTAG pins as it arrived. Any responses received from the target as a result of the pins changing state could be similar transferred (also as a bitstream) back to OpenOCD. There are lots of problems with this approach, topmost among them how to control timing - almost always a critical factor when communication with electronic devices. Another - how to identify (on the incoming bitstream) which responses corresponded with which of the commands on the output bitstream)?
So I'd learned something about OpenOCD, and had to figure out how to write software that would interact with 'vrings'. Were they Linux devices, or what? How to use them?
The answers would have to wait until getting the Linux and development tools going on the BBB, when I knew more to ask intelligent questions.
Linux and the BeagleBone Black
I set up a spare computer with the latest Ubuntu as a host development system, and used it and a Windows computer and the tutorials on the BeagleBone Black website to:
- boot the saved Angstrom Linux on the BBB
- on Windows - learned how to connect to BBB terminal windows using serial USB (with putty) and the RNDIS network connection (with putty ssh), it was trivially easy as the USB device drivers were automatically installed when the BBB starts, and power to the BBB came from the USB connection itself
- on Linux - well, hard to find out how to do what - on Windows - was trivially easy. That would come later
- no SD card came with my BBB and I knew if the saved image got corrupted - the BBB would be dead to me! So I got a few 8 Gb micro-SD memory cards and, using Windows, learned how to use the Image Writer utility to format an SD card properly and copy an Angstrom distribution onto it.
- now I could boot from two Linux devices on the BBB - the eMMC (Flash Memory) device, and the SD card.
- I tried using bonescript and the gpiodemo suggested on the tutorials, and did get some pins toggling as a binary counter - and could see them on my new OpenBench Logic Sniffer and Windows OpenBench Logic Sniffer software - success!
I would have to monitor the boot process with a serial terminal - but the putty connection to the USB serial device to the BBB showed nothing because it didn't start working until the boot was complete. Unless booting from the eMMC flash memory, but that was no help to debug the other problem.
So I ordered an FTDI USB serial 3.3v cable from Digikey (768-1015-ND, it took a few days to arrive) and connected it to the J1 header on the BBB. Now I had a reliable way to monitor the real serial console, to see the u-boot output and everything. And, it became easier to use Linux to interact with the BBB.
So what had happened? I think, nothing. It was just that, somehow with the SD card as boot device, Windows XP, the BBB drivers, and BBB were - unreliable. Out of 10 times booting the BBB, the RNDIS driver appeared in Hardware Manager only a few times. Booting from the eMMC boot device always worked.
I had learned what I could on Windows, now it was mandatory to switch to Linux development on Ubuntu - because I had learned from KA6SOX and PANTO that a special Linux kernel would have to be built from source code.
COMING SOON
Next article: Notes on tackling an Open Source Beaglebone Black Project, Part 2
Links
BeagleBone Black
TI PRUSS - Programmable Realtime Unit Subsystem
TI AM33XX PRUSSv2
TI Programmable Real-time Unit - Extending Functionality of Existing SoCs
CPLD - Complex programmable logic device
JTAG IEEE 1149.1 Standard Test Access Port and Boundary-Scan Architecture
OpenOCD Project
BlackMagic JTAG Probe Project
OpenJTAG Project
goJTAG
TI Stellaris Launchpad EK-LM4F120XL
Arduino Open-Source Hardware Platform
