Remotely Controlling(远程控制) an Octeon through PCI, PCIe, or EJTAG

 

 

1. Introduction
In development, and production, it may be useful to access and control Octeon from a remote host or other communication path. For example, a PC may need to boot Octeon through PCI/PCIe. At other times you may want to read registers through EJTAG. In order to support these conditions, Cavium Networks has developed a remote protocol library and a number of special purpose command line utilities. These utilities allow common operations like register dumps, read and write of CSRs, and profiling to be done outside of Octeon.
This document provides detailed information on the following aspects of controlling Octeon remotely:


1. Introduction
2. Supported Remote Protocols
3. Backwards Compatibility with Previous Utilities
4. Booting over PCI or EJTAG (oct-remote-boot)
5. Remote Bootloader Commands (oct-remote-bootcmd)
6. Remote Console (oct-remote-console)
7. Read CPU Core State (oct-remote-core)
8. CSR Access (oct-remote-csr)
9. Quickly Test Memory (oct-remote-ddr)
10. Loading Files into Memory (oct-remote-load)
11. Read / Write a 64 bit Memory Location (oct-remote-memory)
12. Displaying Octeon POW state (oct-remote-pow)
13. Profiling (oct-profile, oct-remote-profile)
14. Resetting Octeon (oct-remote-reset)
15. Saving Memory to a file (oct-remote-save)
16. Tracing using the Octeon Trace Buffer (oct-remote-tra)
17. Determining proper DDR configuration parameters (oct-remote-ddr-tune)
18. Debugging using GDB
2. Supported Remote Protocols
The Octeon remote library supports a number of possible protocols for connecting to Octeon. The choice of which protocol to use is controlled by the environment variableOCTEON_REMOTE_PROTOCOL. If this environment variable isn't set, the utilities will display a message showing the possible supported protocols. Here is a list of some of the support protocols:
OCTEON_REMOTE_PROTOCOL = PCI[:device]
Use PCI/PCIe to access Octeon from the host or root complex. If multiple Octeon's are present, the optional "device" number specifies which one to use. The first device is number 0.
OCTEON_REMOTE_PROTOCOL = PCIHOST
Use PCI/PCIe to connect to the host Octeon from a target. This is normally only used during development for profiling and register dumps. This allows an Octeon PCI/PCIe target to access the host's (or root complex's) registers.
OCTEON_REMOTE_PROTOCOL = MACRAIGOR:name,tcp_port
Use a Macraigor mpDemon to access Octeon through EJTAG. "name" is either the host name or IP address of the mpDemon probe. "tcp_port" is the TCP port of the probe (normally 1000).
OCTEON_REMOTE_PROTOCOL = GDB:name,tcp_port
Use the GDB remote protocol to access Octeon. Many brands of EJTAG probes supply GDB remote stubs for debugging. The remote utilities can use this protocol directly. Abatron, Mentor Graphics, and Macraigor are all known to work with this protocol. "name" is either the host name or IP address of the GDB stub. "tcp_port" is the TCP port of the first core. Each additional core increments the TCP port by one. The README.txt files in the sdk/ejtag directory have more information about specific probes.
OCTEON_REMOTE_PROTOCOL = LINUX
Assume the utility is running under Linux userspace native on the Octeon. mmap() and debug exception handlers are used to access the local Octeon without modifying the kernel.
In the event of problems, the environment variable OCTEON_REMOTE_DEBUG can be used to enable detailed diagnostic information. Increasing numbers, show more detail:


OCTEON_REMOTE_DEBUG = 0
Disables all diagnostic output.
OCTEON_REMOTE_DEBUG = 1
Enables a small amount of informational data.
OCTEON_REMOTE_DEBUG = 2
More diagnostic data is generated.
OCTEON_REMOTE_DEBUG = 3
Call traces of octeon-remote are generated.
OCTEON_REMOTE_DEBUG = ...
OCTEON_REMOTE_DEBUG = 9
All possible output is enabled.
Normally debug output from the remote library is color coded based on the diagnostic level. If you wish to turn the color off, add 256 to the debug level.


3. Backwards Compatibility with Previous Utilities
The Octeon SDK contains a number of trivial shell scripts to allow the oct-remote-* utilities to act as a drop in replacement for the oct-pci-* and oct-linux-* utilities provided in previous SDKs. The functionality of the older utilities is implemented in the remote utilities when the OCTEON_REMOTE_PROTOCOL is set appropriately.
The scripts for oct-pci-* set OCTEON_REMOTE_PROTOCOL=pci.
The scripts for oct-linux-* set OCTEON_REMOTE_PROTOCOL=linux.
4. Booting over PCI or EJTAG (oct-remote-boot)
Octeon can be booted from a remote host without the need for a boot flash on the Octeon board. For PCI targets, the Octeon board must be configured for PCI boot mode. This keeps all cores in reset after the chip is taken out of reset. For EJTAG boot, the board must _not_ be configured for PCI boot mode, as core 0 must be running for the EJTAG probe to use. The oct-remote-boot program configures the memory controller, copies the bootloader to DRAM, and then boots the bootloader. By default the provided bootloader (target/bin/u-boot-pci.bin) for the detected board is used. A different bootloader image can be specified on the command line. oct-remote-boot also supports a 'generic' board type and bootloader that should support most Octeon boards. In order to use the generic board mode, certain board configuration parameters must be passed on the command line so that oct-remote-boot can configure the memory controller properly. (The SPD addresses for the DIMMS are required in all cases.)