JTAG in WRT54GS
There is always a JTAG automate (JTAG logic) integrated into your SoC or CPU and usually this is connected to a JTAG header on the PCB. You can test and program the IC by issuing JTAG commands to it through the JTAG.
To do that, you need to connect the parallel port of your PC with the JTAG header on the PCB via a bought or a homemade “JTAG cable”. You then run a special JTAG software on your PC, which allows you to comfortably control the JTAG automate and make it perform commands like reads and writes at arbitrary locations.
As already stated the primary intention of the JTAG automate is to test the IC itself. But of course it can additionally be utilized to recover a device if you erased the bootloader resident on the flash. Because, through the JTAG automate in the SoC, you can also write to the Flash Chip.
A JTAG port can be used without any software running on the IC itself, but the IC still has to be powered by a separate power supply. This means, you can solder a lonely SoC to a PCB, no Flash-Chip, no RAM; then connect to it via JTAG and interact with the SoC. Of course, on the PC itself, you should have some sort of software, to make this interaction with the hardware on the lowest level possible a bit more comfortable.
Of course, if there is a flash chips soldered onto the PCB, you could access this chip by programming the SoC via JTAG. It’s one of those amazingly useful things that allows you to recover from pretty much anything that doesn’t involve a hardware failure.
The JTAG Automate is not a standardized system. Different SoCs/CPUs/ISAs have different JTAG automate behavior and reset sequence, most likely you will find ARM and MIPS CPUs, both having their standard to allow controlling the CPU behavior using JTAG.
Finding JTAG connector on a PCB can be a little easier than finding the UART since most vendors leave those headers unpopulated after production. JTAG connectors are usually 12, 14, or 20-pins headers with one side of the connector having some signals at 3.3V and the other side being connected to GND.
It’s one of those amazingly useful things that allows you to recover from pretty much anything that doesn’t involve a hardware failure. While the JTAG can technically be used to watch every instruction and register as the system boots, the recovery software only uses it for DMA access to the flash chip, making it somewhat a blind recovery mechanism.
The biggest mistake people seem to make with JTAG is the “wipe everything and reflash bootloader” (CFE for broadcom devices) approach; they either can’t find the correct CFE version after wiping the device, or they reflash with a CFE which is incompatible with their device. You should always try to use the CFE version that came with the device rather than attempting to replace it with some random CFE you found on the internet.
Second mistake – embedded within CFE is a set of NVRAM defaults to be used if the NVRAM partition is missing. This means that in most cases you can just wipe everything but CFE and it’ll happily boot, recreate NVRAM and start waiting for a firmware via TFTP. In some cases however, the defaults embedded defaults (in the CFE shipped with the device) don’t match the actual hardware and CFE will fail to boot. This is why we have the warnings not to wipe NVRAM. To recover from this situation you need either the original NVRAM contents, or a version of CFE with the correct defaults.
Identifying JTAG connector Headers
There are two major JTAG header arrangements used in SOHO routers based on MIPS CPUs. One uses 12 pins and the other uses 14 pins.
12 Pin Header
Found in Linksys routers such as the WRT54G and WRT54GS, the 12-pin header has the following arrangement of JTAG signals and pins:
Perhaps, this header is a truncated version of the full EJTAG header.
JTAG allows device programmer hardware to transfer data into internal non-volatile device memory (e.g. CPLDs). Some device programmers serve a double purpose for programming as well as debugging the device. In the case of FPGAs, volatile memory devices can also be programmed via the JTAG port, normally during development work. In addition, internal monitoring capabilities (temperature, voltage and current) may be accessible via the JTAG port.
JTAG programmers are also used to write software and data into flash memory. This is usually done using data bus access like the CPU would use, and is sometimes actually handled by a CPU, but in other cases memory chips have JTAG interfaces themselves. Some modern debug architectures provide internal and external bus master access without needing to halt and take over a CPU. In the worst case, it is usually possible to drive external bus signals using the boundary scan facility.
As a practical matter, when developing an embedded system, emulating the instruction store is the fastest way to implement the “debug cycle” (edit, compile, download, test, and debug). This is because the in-circuit emulator simulating an instruction store can be updated very quickly from the development host via, say, USB. Using a serial UART port and bootloader to upload firmware to Flash makes this debug cycle quite slow and possibly expensive in terms of tools; installing firmware into Flash (or SRAM instead of Flash) via JTAG is an intermediate solution between these extremes.
A JTAG interface is a special interface added to a chip. Depending on the version of JTAG, two, four, or five pins are added. The four and five pin interfaces are designed so that multiple chips on a board can have their JTAG lines daisy-chained together if specific conditions are met.The two pin interface is designed so that multiple chips can be connected in a star topology. In either case a test probe need only connect to a single “JTAG port” to have access to all chips on a circuit board.
Daisy-chained JTAG (IEEE 1149.1)
The connector pins are
- TDI(Test Data In)
- TDO(Test Data Out)
- TCK(Test Clock)
- TMS(Test Mode Select)
- TRST(Test Reset) optional.
Test reset signal is not shown in the next image:
The TRST pin is an optional active-low reset to the test logic – usually asynchronous, but sometimes synchronous, depending on the chip. If the pin is not available, the test logic can be reset by switching to the reset state synchronously, using TCK and TMS. Note that resetting test logic doesn’t necessarily imply resetting anything else. There are generally some processor-specific JTAG operations which can reset all or part of the chip being debugged.
Since only one data line is available, the protocol is serial. The clock input is at the TCK pin. One bit of data is transferred in from TDI, and out to TDO per TCK rising clock edge. Different instructions can be loaded. Instructions for typical ICs might read the chip ID, sample input pins, drive (or float) output pins, manipulate chip functions, or bypass (pipe TDI to TDO to logically shorten chains of multiple chips).
As with any clocked signal, data presented to TDI must be valid for some chip-specific Setup time before and Hold time after the relevant (here, rising) clock edge. TDO data is valid for some chip-specific time after the falling edge of TCK.
The maximum operating frequency of TCK varies depending on all chips in the chain (the lowest speed must be used), but it is typically 10-100 MHz (100-10 ns per bit). Also TCK frequencies depend on board layout and JTAG adapter capabilities and state. One chip might have a 40 MHz JTAG clock, but only if it is using a 200 MHz clock for non-JTAG operations; and it might need to use a much slower clock when it is in a low power mode. Accordingly, some JTAG adapters haveadaptive clocking using an RTCK (Return TCK) signal. Faster TCK frequencies are most useful when JTAG is used to transfer lots of data, such as when storing a program executable into flash memory.
Clocking changes on TMS steps through a standardized JTAG state machine. The JTAG state machine can reset, access an instruction register, or access data selected by the instruction register.
JTAG platforms often add signals to the handful defined by the IEEE 1149.1 specification. A System Reset (SRST) signal is quite common, letting debuggers reset the whole system, not just the parts with JTAG support. Sometimes there are event signals used to trigger activity by the host or by the device being monitored through JTAG; or, perhaps, additional control lines.
Even though few consumer products provide an explicit JTAG port connector, the connections are often available on the printed circuit board as a remnant from development prototyping and/or production. When exploited, these connections often provide the most viable means for reverse engineering.