RVI Virtual Ethernet
Ethernet and serial ports are essential to the successful development of a new board. Unfortunately they tend to be the first items discarded when space and cost is tight. One solution is to break out the connectors of these ports using a separate debug board such as Bluewaters Squid development board. When this is not a viable option there is one more alternative, to use the RealView ICE to create "virtual" ethernet and serial ports through the JTAG connection to the board.
Debug Communications Channel (DCC)
The Debug Communictaions Channel (DCC) is a component of EmbeddedICE(R) logic in ARM cores. It allows communication between the host and target without stopping the program flow or entering the debug state. It is accessed on the target through coprocessor 14 using the MCR and MRC instructions and by the host over the JTAG connector. These registers can be polled by the target or processed via interrupt (if the processor can be configured to route the Embedded ICE COMMRX and COMMTX interrupts to the interrupt controller).
To transfer data to the host from the target, the following instruction is used (data to be transmitted in Rn);
MCR p14, 0, Rn, c1, c0
To read data from the host, the following instruction is used (data received in Rd);
MRC p14, 0, Rd, c1, c0
To retrieve the status of the communications channel, the following instruction is used (status retrieved into Rd);
MRC p14, 0, Rd, c0, c0
The status indicates if there is new data to be received from the host (bit 0) and if the host is ready to receive data (bit 1).
The DCC channel on the RealView ICE can be configured in several different modes:
- Mode 0: The channel is not used.
- Mode 1: The ICE will make the raw DCC data available through TCP ports 5000.
- Mode 2: The ICE will process the DCC messages and provide a virtual ethernet and TTY to the target.
Virtual Debug Ports
When the Realview ICE is configured in Mode 2, it can be used to provide a virtual ethernet and virtual TTY device to the target. The target can use these virtual devices in the same way that it would have used a real device. ARM has provided generic source code for the target side device drivers that can be ported to any operating system or embedded application. ARM has also provided drivers that have already been ported to Linux and U-boot (ARM Linux and U-Boot patch download).
The ICE shares its ethernet port with the target using ethernet bridging. By checking the IP address of received packets the ICE can determine which packets are destined for the host, and which packets are for the ICE itself. The ICE can be manually configured with the IP address of the host, or it can automatically detect the host's IP address by snooping DHCP responses sent to the host. On the host the virtual serial port can be accessed by telneting to the ICE, or from the prompt if command line tools are used to load the software on to the device.
Bluewater Systems Experience
On small form factor devices it is not practical to use up valuable space with Ethernet and serial port components. Yet Ethernet and serial is essential to board bring-up and software development. On these occasions Bluewater Systems has used the virtual Ethernet and serial port provided by the ICE. By mounting the root file system of the device over NFS, development time can be slashed due to the ease of updating the file system on the host PC without having to reboot the device. Modules and applications can be easily modified on the development PC and quickly tested on the device.
We have updated the original patches from ARM to make them suitable for the latest Linux kernel supported by Bluewaters Snapper modules. We have also used the RealView LVDS Probe which allows us to run the JTAG interface over 30MHz providing much improved Ethernet performance.