Servo

Introduction

Servo is a debug board used for Chromium OS test and development. It connects to most Chrome devices through a debug header on the mainboard. The debug header is used primarily during development and is often removed before a device is released to consumers. If you have a production device the debug header might need reworking before servo can be connected.

Connecting Servo

In a typical debug setup, you connect servo to the debug header on a Chrome device, and to a host machine through the HOST_IN USB port. See the annotated FAFT setup image for details.

Most newer Chrome OS mainboards attach to servo with a 50-pin flex cable. The schematic and layout for this cable is also available. The standard DUT-side debug header is an AXK750347G from Panasonic, though shorter variants are sometimes used.

The basic steps to connect servo are:

Check the direction printed on the flex cable.

Connect the DUT end to the debug header on the Chrome device, metal side down.

Connect the Servo end to the header on the servo board, metal side up. Make sure to engage the black bottom clip of the header on the servo board by pushing it inwards after inserting the ribbon cable. This will hold the ribbon cable in place and press the contacts.

Use a USB cable to connect the servo board to your Linux workstation.

You should be able to use the power button on servo to power the Chrome device on and off.

Using Servo

To use servo, on your Linux workstation you need to build Chromium OS and create a chroot environment.

The hdctools (Chrome OS Hardware Debug & Control Tools) package contains several tools needed to work with servo. Make sure the latest version is installed in your chroot:

sudo emerge hdctools

On your workstation, servod must also be running to communicate with servo:

sudo servod -b $BOARD &

With servod running, dut-control commands can be used to probe and change various controls. For a list of commands, run dut-control with no parameters:

dut-control

You can toggle GPIOs by specifying the control and the state. For example, to perform a DUT cold reset:

dut-control cold_reset:on

sleep 1

dut-control cold_reset:off

Higher-level controls may set several sub-controls in sequence. For example, to transition a DUT to recovery mode:

dut-control power_state:rec

To access the CPU or EC UARTs, first check the port mapping with dut-control, then attach a terminal emulator program to the port:

To set up servo to run automated tests, connect the servo board and the test device to the network via Ethernet, and load a Chromium OS image onto USB memory stick. The networking and build image steps are not described here; see FAFT for details on configuring servo to run automated tests. For information on writing tests, see the servo library code in the Chromium OS autotest repo.

Single-Step Debugging with Servo, GDB, and OpenOCD

Using the Servo along with GDB and OpenOCD, you can single-step debug via JTAG on TI EC targets. For example, here's how you would get setup for samus.

1. Start up servod for the target which you will attach to and enable JTAG access.

sudo servod -b samus &

dut-control jtag_buf_on_flex_en:on jtag_buf_en:on

2. Now that servod is up and running, we need to launch OpenOCD. There are some configuration files present and we need to instruct OpenOCD to use the configuration file for the Servo V2. The arguments to openocd here are for samus.

Once you see a line indicating the number of breakpoints, you should be ready to attach with gdb. When OpenOCD launches, it starts up a gdbserver listening on port 3333 by default. This can be overridden by setting the gdb_port option in the configuration file. For more information, consult the OpenOCD User's guide.

3. Now that OpenOCD is up and running, we can launch GDB and load the symbols from our EC ELF file. Make sure to use the correct gdb binary from the toolchain.