Ttc Program Usage Guide

Overview
This document describes the program, which is a tool for developing Linux for embedded systems.

is intended to be used in a host/target development configuration, where one machine is the development host where software is configured and built, and one or more machines are targets where software is executed. This is the most common configuration for embedded systems programming. The  program is run on the host system in order to build software and interact with target machines in a common way.

The  program can be run interactively, or as part of an automated session. The purpose of  is to make it so that the same commands can be used to build software and manipulate different target machines, independent of differences in the configuration and setup of the machines. Certain details of operation are hidden from the user by the command. This makes it possible to perform the same operations on different target boards, using the same set of  commands.

When the  program runs, it reads the configuration file " ". Usually, it looks up the target to act upon (which is specified either on the command line or in the environment), then sets up the environment for the desired sub-command. (The set of supported sub-commands is listed below in the section "Commands".) Finally, using the attributes specified in the configuration file, executes the specified sub-command.

The different operations (or sub-commands) of  are intended to support the following major development activities related to a target:
 * retrieving kernel source
 * patching the kernel
 * configuring the kernel for the target, including both:
 * getting a default configuration for the target
 * modifying individual configuration options


 * building the kernel
 * installing the kernel on the target
 * rebooting the target machine
 * accessing the console for the target
 * copying files to and from the target

Note that there is NOT a one-to-one correspondence between the sub-commands and the activities listed above. This is because once the environment is set up it is possible to perform some of these activities in a target-independent way using normal Linux commands (like "make" or "patch").

In reality,  is a rather thin wrapper program which sets up the environment and performs some common operations. The bulk of the "intelligence" (how to do the actual operations) is contained in the configuration file in the form of Unix shell commands.

In order to use  on your system, you need to install the software and edit the configuration file to match your host/target setup. You may also need to install various helper scripts, referenced in your ttc.conf file, in your PATH.

Theory of operation
The most important aspect of  is that it hides certain operational details from the user, so that common commands can be used to perform operations related to an embedded development board.

The things that  hides, include things such as:
 * the location and name of the cross-compiler (and other toolchain programs)
 * the version and location of the Linux kernel source code
 * the menu location of kernel configuration options
 * the method of installing the kernel on the target board
 * the method of rebooting the target board
 * the method of installing files to the file system of the target

These things must be set up on the host machine, and then the configuration file must be written to take into account the specific settings for each target connected to the host.

Downloading 'ttc'
Download the tarball from one of the following links and follow the instructions in the README (and in this document).

Installing 'ttc'
Copy  to. If you want to use any of the provided helper scripts on your system (ssh_exec, telnet_exec, powerswitch-cycle), you should put them somewhere on your search PATH. would be a good place to copy them to.

Configuring 'ttc'
In order to use 'ttc', you first need to set up the  configuration file for the targets attached to your host machine. This is usually a relatively easy thing to do, but may require special hardware or software to provide the services that 'ttc' needs to access the board.

The syntax of the configuration file, and a description of the required contents, is in Appendix A. Also, a sample configuration file is provided, with definitions for several targets.

See the section "Configuration files and environment variables" for additional notes on where to place configuration information.

Note that not all variables need to be defined for a target, in order for a target configuration to be useful. For example, if you never re-build the distribution for a target, you don't need to configure the fsbuild or fsinstall commands. In general, you should start with a minimal configuration which meets your needs, and then expand to configuring additional features as you use those features on the board.

Using 'ttc'
You can use 'ttc' interactively from the Linux command line, or you can use it by running an automated test (which invokes target to perform various parts of the test.)

Command overview
Here is the list of sub-commands available for user with the  command.

Example 1: build and install a kernel, and logon to the target to use it
A normal sequence of operations for an interactive user of  would be:


 * get a list of targets connected to this host
 * select a target to work on, and set up the environment for it
 * get the kernel sources for a build
 * (optionally) apply patches to the kernel sources
 * get a (default) kernel configuration for this target
 * set specific configuration options
 * build the kernel, and install it
 * reboot the target with the new kernel
 * (optionally) put additional files on the target
 * access the target console and do work

-- Here are the  commands one would use to accomplish this:

$ ttc list Targets on this host: ebony innovator nut osk test
 * get a list of targets connected to this host


 * select a target to work on, and set up environment for it

$ ttc ebony setenv


 * get the kernel sources for a build

$ ttc get_kernel -o linux-test $ cd linux-test

$ patch -p1 <../printk-times.patch
 * (optionally) apply patches to the kernel sources

$ ttc get_config
 * get a default kernel configuration for this target


 * set specific configuration options

$ ttc set_config CONFIG_PRINTK_TIME==y


 * build the kernel, and install it

$ ttc kbuild $ ttc kinstall

(either one of: On the target board, type "reboot":
 * reboot the target with the new kernel

$ reboot or from the host, use:

$ ttc reset

$ ttc cp foo bar target:/tmp $ ttc cp test.sh target_bin:
 * (optionally) put additional files on the target


 * login to the console and do some work

$ ttc console 

console
Runs a program to access the target console.

Usage: ttc [ ] console

A program is run to provide interactive access to the target console. It is not possible to predict what program will be used. Often it is, talking to a serial console on the target. But the access program could be something else, so no assumptions should be made. This command is not intended to support automated access to the target console. Use 'ttc run' for that.

cp
Copy files to or from the target.

Usage: ttc [ ] cp [ ...]

The last path specified determines the direction of the copy. Use the prefix "target:" to specify a filepath on the target. "target_bin:" can be used to put a file on the target in a directory on the PATH.


 * Ex: ttc cp test_data test_data2 target:/tmp
 * Ex: ttc cp test.sh target_bin:

get_config
Install kernel config for target in the $KBUILD_OUTPUT directory

Usage: ttc [ ] get_config [-o ]

Use -o to specify an alternate KBUILD_OUTPUT directory (default is '.') Assumes the current directory is the top kernel source dir.

get_kernel
Install kernel sources for target in the $KERNEL_SRC directory

Usage: ttc [ ] get_kernel [-o ]

Use -o to specify a specific output kernel source directory. The default output directory, if none is specified, is 'linux'.

help
Show the online help.

Usage: ttc help [ ]

If a command is specified, show help Release a reservation of a target.and usage information for that command.

info
Show information about a target.

Usage ttc [ ] info [-v] [-n ]

Show information about a target. The '-v' (verbose) option will show all the attributes for the target (from the configuration file). Use the '-n' option to display the value of a single attribute,.

kinstall
Install kernel for use on target.

Usage: ttc [ ] kinstall

Assumes the current directory is the top kernel source directory.

list
Show a list of available targets.

Usage: ttc list [-q]

Use -q for "quiet" mode. This suppresses extraneous output. The resulting list can be parsed more easily by other programs.

login
Run a program to perform a network login on the target.

Usage: ttc [ ] login

on
Turn on the power to the target

Usage: ttc [ ] on

off
Turn off the power to the target

Usage: ttc [ ] off

pos
Show the power status of the target

Usage: ttc [ ] pos

reboot
Reboot the target board.

Usage: ttc [ ] reboot [-w]

This performs a reboot (power cycle) of the target board. Use the '-w' option to have ttc wait a period of time before returning, to allow the board to reset. The length of the wait is determined by the 'reset_delay' specified for the board.

reset
Reset the target board.

Usage: ttc [ ] reset [-w]

This performs a soft reset of the target board, if available. Note that if the hardware configuration does not support a soft reset, a reboot may be performed instead. Use the '-w' option to have ttc wait a period of time before returning, to allow the board to reset. The length of the wait is determined by the 'reset_delay' specified for the board.

rm
Remove files from the target.

Usage: ttc [ ] rm [ ...]

run
Run a command on the target, and return it's output.

Usage: ttc [ ] run "command "

set_config
Set one or more individual config options

Usage: ttc [ ] set_config [-o ]  ...

Use -o to specify a non-default KBUILD_OUTPUT directory. (The default is '.' if none is specified in the environment or the target.conf file.)

Multiple  may be specified with one command. Each  has the syntax:  .i Operations are: '=' for assignment, and '+=' for a string append. Boolean or tristate values should be one of "y", "n", and "n". String values must be enclosed in quotes, which usually requires shell escaping of the quote characters (see below).

A backup is made of the .config file.

Examples:
 * ttc set_config CONFIG_FOO=y
 * ttc set_config CONFIG_BAR=n CONFIG_BAZ=1234
 * ttc set_config "CONFIG_STR=\"foo bar\""
 * ttc set_config "CONFIG_STR+=\" quiet\""

Assumes the current directory is the top kernel source dir.

setenv
Prepare environment for building for the target

Usage: ttc [ ] setenv [-o >file]

This command starts a new shell, with an environment that is prepared for building for the target. That is, things like KBUILD_OUTPUT, CROSS_COMPILE, and ARCH are set in the environment, and PATH has been adjusted to include the appropriate toolchain directory.

When -o is used, no new sub-shell is started. Rather, -o causes target to output the required environment variables as a series of shell export statements. These can be 'sourced' into the current shell rather than starting a new sub-shell.


 * Ex: ttc ebony setenv -o >foo ; source foo

status
Show status of target, including reservations.

Usage: ttc [ ] status

This command shows the the status of the indicated target. The full command for showing status is not implemented yet. Currently, this command shows the reservation status of the target, but not any online/network/booted status for the target board.

vars
Show information about variables and config files used by ttc

Usage: ttc [ ] vars

version
Show version information and exit.

Usage: ttc version

wait_for
Wait for a condition to be true.

Usage: ttc [ ] wait_for [-i ] [-t ] The command is run periodically until it returns 0. By default, the interval between executing the command is 5 seconds. Use -i to specify a different interval, and -t to specify a maximum time to wait. Both are expressed in seconds.


 * Ex: ttc wait_for -i 2 -t 100 "test -f /target/ebony/tmp/outfile"

This will check every two seconds to see if /target/ebony/tmp/outfile exists, waiting no longer than 100 seconds total. The exit code from of 'ttc' is the exit code of the last invocation of the command (0 on success).

Note that this command operates on the host. The above example would be most useful for an 'ebony' target with an NFS-mounted root filesystem that had "/tmp" on the target mapped to "/target/ebony/tmp" on the host. If you need to run a command on the target, you can use 'ttc run' for that. Some similar to the above, but running a command on the target to check for the presence of a file would be:


 * Ex: ttc wait_for -i 2 -t 100 "ttc run \"test -f /tmp/outfile\""

Configuration files and environment variables
Configuring ttc consists of creating the definitions for ttc attributes and sub-commands for a target. Note that more than one ttc entry can be created for a single physical board. This is useful when you are working with different code-bases, different toolchains, or some other difference in configuration, for a board. For example, maybe you have a board which can run both Android and Angstrom. You could have two different ttc configurations for these different setups.

The global config file
The global config file for ttc is at /etc/ttc.conf. If you do not have root access to your machine (to put or edit stuff in /etc), then you should use a local config file instead.

Using a local config file
You can use a local ttc configuration file by creating the file, and specifying it's path in the shell environment variable TTC_CONF. For example you could do the following to use a local configuration file in your home directory:


 * create ~/ttc.conf with your target definitions
 * $ export TTC_CONF=~/ttc.conf
 * $ ttc list

You can use a combination of both global and local configs, but in general it can get confusing if you have the same targets in both config files. Additionally, values are read from the environment, and take precedence over any values set in the global and local config files. For example, one variable set and used by ttc is ARCH. If this is in your environment before you run ttc, then the value from your environment is used instead of any values defined from your ttc configuration.

The order of reading configuration values is:
 * 1) read the global config file (/etc/ttc.conf)
 * 2) read a local config file (if specified by TTC_CONF)
 * 3) read environment variables

interactive vs. automated use
Some tricks for automated use:

Use the -o option with "ttc setenv" to output the environment variables to a file, then source that file in the current environment This solves the problem of setting environment variables in the current shell, rather than in a sub-shell started via "ttc". Here's a line which does this:

ttc foo setenv -o >tmp ; source tmp ; rm tmp ; make $kimage

Appendix A: Configuration file specification
The configuration file for  is named , and is located in the  directory.

This file contains a list of the targets attached to this host, and their attributes. An attribute can be a static data value, such as the name of the target, its description, or its IP address. Or an attribute can be a list of one or more commands that perform an operation related to the target.

The file contains a list of name-value pairs. It supports single-line and multi-line values. A single-line name-value pair has the syntax: name=value

A multi-line name-value pair has the syntax: name="""first line second line etc."""

In other words, three double-quotes are used to denote the start and end of a multi-line value.

Lines starting with a '#' are comments.

The file is divided into sections, one for each target described. Each section begins with a target declaration, of the form: "target= ". This line specifies the end of the previous section (if any) and the start of a new section. The attributes that follow this line in the file are associated with the indicated target, up to the next target declaration line.

Some values are sequences of shell script commands, which are used to implement a single  sub-command. By convention, the names of an attribute which implement a command ends with "_cmd".

If an attribute name is all upper-case, this denotes a value that is placed in the environment. (There are, however, some environment variable values which are NOT denoted by an upper-case attribute name).

Most attributes are put into the shell environment prior to execution of any '_cmd' scripts. These attributes can be referenced by the scripts using shell variable syntax. For example $KERNEL_SRC. Attributes are also available internally for macro expansion using a python string interpolation variable, like so: %(real_board)s. The name of the attribute goes inside the parens, as in %(attr_name)s. Make sure to include the trailing 's' in the reference, or python will throw an exception and things will not work as you expect. Note that string interpolation happens before a command is used for external command execution. (That is, before there is the shell substitutes environment variables.)

Configuration attributes summary
Supported attributes are:

Configuration attribute details
This section lists each configuration attribute, and what its value should be.


 * target: Short (one-word) name of the target. If the target name starts with a '.', it is not displayed in the list from the command 'ttc list'. This is similar to Linux directory listings, and is useful for having hidden targets, which other targets use as a base for inheritance.
 * real_board: Name of the real board for a target. This is a convention that allows multiple target configurations to be defined for a single board.  For example, you could have a real board "omap", and define different target configurations for working with the board using android, or directly with embedded linux (e.g. with target configurations for "omap-android" and "omap-linux".  The 'real_board' value is used for reserving the board and checking it's status.  It is often used in variable form in blocks that are inherited by other target configurations.
 * inherit_from: Name of target configuration to inherit attributes from. Any attributes listed in the current target override attributes in the inherited-from target configuration. A block that is inherited from may use %-style variable references to customize the commands in the block to the inheriting block.  For example, a inherited from block may specify kbuild_cmd as "kbuild_cmd=make %(kimage)s", and different inheriting targets could specify their own values for 'kimage' respectively.
 * description: A description of the target board. Usually this is a multi-line value, and is intended to provide information about the target in human-readable form.
 * TOOL_PATH: Path where toolchain tools are located. This appended to the PATH env. variable when a 'setenv' environment is constructed, and before any sub-commands are executed.
 * ARCH: Architecture specifier for the kernel build (eg. arm, ppc, i386)
 * CROSS_COMPILE: Toolchain prefix used with kernel builds (eg. arm-sony-linux- )
 * INSTALL_PATH: Place where the kernel is installed
 * KERNEL_SRC: Default name to use for kernel source directory
 * KBUILD_OUTPUT: Default directory for kernel build output
 * kimage: Name of the kernel image file (eg. bzImage, uImage)
 * kinstall_cmd: Command(s) to install the kernel image. (Assumes that the current working dir is $KERNEL_SRC)
 * get_config_cmd: Command(s) to put a default kernel configuration file (.config) in $KBUILD_OUTPUT
 * get_kernel_cmd: Command(s) to put the kernel source code in $KERNEL_SRC.
 * copy_to_cmd: Command(s) to copy files from host to target. This command should reference $src as the location of the file(s) on the host, and $dest as the location on the target for the copied file(s).
 * copy_from_cmd: Command(s) to copy files from target to host. This command should reference $src as the location on the target to copy from, and $dest as the location on the host for the copied file(s).
 * rm_cmd: Command(s) to remove files from target. This command should reference $dest as the location on the target for the removed file(s).
 * ipaddr: Target IP address
 * reset_cmd: Command(s) to reset the target, from the host
 * console_cmd: Command(s) to start an interactive console for the target (usually minicom)
 * login_cmd: Command(s) to start an interactive login session with the target (usually telnet)
 * target_bin: Directory on target where binary files are located
 * fsbuild_cmd: Command(s) to build a root filesystem for the target
 * fsinstall_cmd: Command(s) to install a root filesystem to the target
 * reserve_cmd: Command(s) to reserve a board (like switching the root filesystem, in case of different users having different root filesystems)
 * reboot_cmd: Command(s) to reboot the board. This is intended to be a power-cycle of the board, producing a cold boot of the hardware.  Usually this is something like "powerswitch-cycle -n  -o 3 -d ", but it depends on completely on how you have the board wired up for power and what the host needs to do to reboot it.  A helper command of powerswitch-cycle is provided for targets attached to web power switches from digital loggers. See http://www.digital-loggers.com/lpc.html.
 * reset_cmd: Command(s) to reset the target, from the host. This is intended to be a soft reset of the hardware. If you have automated control of a software reset pin or button on the board, then configure this command to activate it.  Otherwise, you could use something like: 'reset_cmd=ttc run reboot'
 * run_cmd: Command to execute a command on the target. This cmd should use $COMMAND as the string for the command to execute on target.  Some helper programs are provided to perform this execution using ssh or telnet (in case authentication or other handshaking is required to accomplish the execution.)  These are called ssh_exec and telnet_exec, respectively.

Configuration Example
Here is a sample:

target=.telnet_defaults description="""default commands and attributes for boards with telnet daemon, root filesystem at /target/%(real_board)s (NFS-mounted), and accessible via network at hostname %(real_board)s"""
 * 1) Some notes on syntax and conventions
 * 2) Attributes that end in "_cmd" are assumed to be shell
 * 3) commands, which will be executed in shell context
 * 4) Each line of a multi-line _cmd will be executed
 * 5) in its own sub-shell.  (i.e. don't count on
 * 6) exports or cd's being persistent from one line to
 * 7) the next)
 * 8) The get_kernel_cmd should output the kernel source
 * 9) to the directory specified by $KERNEL_SRC
 * 1) to the directory specified by $KERNEL_SRC

login_cmd=telnet %(real_board)s copy_to_cmd=cp $src /target/%(real_board)s/$dest copy_from_cmd=cp /target/%(real_board)s/$src $dest rm_cmd=rm /target/%(real_board)s/$dest run_cmd=telnet_exec -t %(real_board)s -u root -c "$COMMAND"

target=innovator real_board=inno-1 inherit_from=.telnet_defaults description="""TI OMAP Innovator board, with: OMAP1510 processor (ARM925T core and a C55x DSP) The ARM core runs at 168 MHZ. The board has 32 meg. of flash (in 2 16M banks) and 32 meg. of SDRAM."""

ipaddr=192.168.1.61 console_cm==minicom inno

TOOL_PATH=/usr/local/arm-sony-linux/devel/bin ARCH=arm CROSS_COMPILE=arm-sony-linux- kimage=uImage kinstall_cmd=cp -v arch/arm/boot/uImage /target/inno-1/boot reset_cmd=omap-reset get_kernel_cmd=export CVSRSH=/usr/bin/ssh ; cvs -d :ext:oak.sm.sony.co.jp:/var/cvsroot co -r branch_ALP_LINUX -d $KERNEL_SRC linux-2.6 get_config_cmd="""export CVSRSH=/usr/bin/ssh ; cvs -d :ext:oak.sm.sony.co.jp:/var/cvsroot co local-dev/team/configs       cp local-dev/team/configs/config-innovator-baseline $KERNEL_SRC/.config"""

target_bin=/devel/usr/bin



target=osk inherit_from=.telnet_defaults real_board=osk2

description="""TI OMAP Starter Kit (OSK): OMAP5912 processor (ARM926EJ-S core and a C55x DSP) The ARM core runs at 192 MHZ. The board has 32 meg. of flash and 32 meg. Mobile DDR SDRAM, 10 Mbit Ethernet interface, USB Host interface and a AIC23 stereo codec."""

ipaddr=192.168.1.72 console_cmd=echo "console is on timdesk" ; false

TOOL_PATH=/usr/local/arm-sony-linux/devel/bin ARCH=arm CROSS_COMPILE=arm-sony-linux- kimage=uImage KERNEL_SRC==linux TMPDIR=/tmp KBUILD_OUTPUT=../build/osk kinstall_cmd=cp -v $KBUILD_OUTPUT/arch/arm/boot/uImage /target/osk2/boot reset_cmd=echo "remote reset not supported" ; false get_kernel_cmd=tla get -A alp@oak--trial-5 alp-linux--dev $KERNEL_SRC get_config_cmd="""export CVSRSH==/usr/bin/ssh ; cd $TMPDIR ; cvs -d :ext:oak.sm.sony.co.jp:/var/cvsroot co local-dev/team/configs/config-osk-baseline ; cd -       cp $TMPDIR/local-dev/team/configs/config-osk-baseline $KBUILD_OUTPUT/.config"""

target_bin=/devel/usr/bin

target=nut inherit_from=.telnet_defaults real_board=nut description=="""Nut is an x86-based desktop computer, with: Intel Celeron processor, running at 2 GHz. The machine has 128 meg. of RAM and a 40G IDE hard drive."""

reset_cmd=nut-reset console_cmd=minicom nut

ipaddr=192.168.1.14

TOOL_PATH= ARCH= CROSS_COMPILE= INSTALL_PATH=/target/nut/boot KERNEL_SRC=linux KBUILD_OUTPUT=../build/nut

kimage=bzImage kinstall_cmd=cp -v $KBUILD_OUTPUT/arch/i386/boot/bzImage /target/nut/boot/vmlinuz get_kernel_cmd="""tar -xjf /home/rbatest/base/linux-2.6.10.tar.bz2               mv linux-2.6.10 $KERNEL_SRC""" get_config_cmd=cp /home/rbatest/base/config-nut-works-2.6.11-rc4 $KBUILD_OUTPUT/.config

Appendix B: Configuration tips and tricks
Should document the following here:

Helper Programs included with ttc

 * use of helper programs:
 * telnet_exec, ssh_exec - used to execute commands on the target, communicating either with a telnet daemon or ssh daemon (and handling things like specifying the user and password).
 * powerswitch-cycle - used to reboot boards attached to a Digital Loggers web power switch
 * switch-target-fs - used to switch between root filesystems when 'ttc reserve' is used

Using inheritance

 * inheritance and multiple target configurations for a single board

Tips for setting up a board reservation system

 * reserving boards

Using an all-networked deployment system

 * using tftp for kernel and NFS rootfs for filesystem

Using ttc with SDcard-based systems

 * how to use a baseline (known working) kernel & rootfs with sdcard-based systems
 * configure SDcard with multiple partitions
 * configure uboot with timed delay
 * interrupt uboot from host by writing to serial console
 * select either known-working kernel or kernel-under-test to boot
 * for kinstall_cmd reboot to known-working kernel and use that kernel to write system under test to other partitions on SDCARD
 * for reboot_cmd, reboot to test kernel.

Using ttc with Android systems

 * how to wrap adb for android systems
 * Can use setenv_cmd to check for correct Android configuration

Here is a snippet from a target configuration for an android-based device: setenv_cmd="""if [ -z "$ANDROID_BUILD_TOP" ] ; then \       echo "ANDROID_BUILD_TOP is not set - please source build/envsetup.sh" ;  \        exit 1 ; \ fi """

TOOL_PATH=$ANDROID_BUILD_TOP/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin CROSS_COMPILE=ccache arm-eabi- ARCH=arm kimage=zImage KBUILD_OUTPUT=../out/kbuild/%(target)s INSTALL_MOD_PATH=../modules/%(target)s KERNEL_SRC=kernel TMPDIR=/tmp

kbuild_cmd=time make -j8 %(kimage)s login_cmd=adb shell copy_to_cmd=adb push $src $dest copy_from_cmd=adb pull $src $dest rm_cmd=adb shell rm $dest run_cmd=adb shell "$COMMAND"


 * specify prebuilt toolchains relative to $ANDROID_BUILD_TOP
 * use 'adb push' for copy_to_cmd, and 'adb pull' for copy_from_cmd.
 * use 'adb shell' for run_cmd

Using ttc with a distribution produced with the Yocto Project

 * integration with Yocto Project