Ttc Program Usage Guide
- 1 Overview
- 2 Downloading 'ttc'
- 3 Installing 'ttc'
- 4 Configuring 'ttc'
- 5 Using 'ttc'
- 6 Commands
- 6.1 Command overview
- 6.2 Use cases
- 6.3 Commands
- 7 Configuration files and environment variables
- 8 Automated use of 'ttc'
- 9 Appendix A: Configuration file specification
- 10 Appendix B: Configuration tips and tricks
- 10.1 Helper Programs included with ttc
- 10.2 Using inheritance
- 10.3 Tips for setting up a board reservation system
- 10.4 Using an all-networked deployment system
- 10.5 Using ttc with SDcard-based systems
- 10.6 Using ttc with Android systems
- 10.7 Using ttc with a distribution produced with the Yocto Project
This document describes the program
ttc, which is a tool for developing Linux for embedded systems.
ttc 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
ttc program is run
on the host system in order to build software and interact with
target machines in a common way.
ttc program can be run interactively, or as part of an automated
session. The purpose of
ttc 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
ttc 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
ttc 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").
ttc 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
In order to use
ttc 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
ttc 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
ttc 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
ttc configuration file must be written to take into account
the specific settings for each target connected to the host.
Download the tarball from one of the following links and follow the instructions in the README (and in this document).
|current||Public release as of March 4, 2016||https://github.com/tbird20d/ttc|
|1.3.0||Public release as of January 13, 2014||Ttc-1.3.0.tgz|
|1.2.3||Public release as of Dec 12, 2012||Ttc-1.2.3.tgz|
/usr/local/bin. 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.
/usr/local/bin would be a good
place to copy them to.
In order to use 'ttc', you first need to set up the
/etc/ttc.conf 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.
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.)
Here is the list of sub-commands available for user with the
|console||Run a program to access the target console.||.|
|cp||Copy files to or from the target.||.|
|fsbuild||File system build||.|
|fsinstall||File system install||.|
|get_config||Install kernel config for target in the $KBUILD_OUTPUT directory||assumes the current directory is top kernel source dir.|
|get_kernel||Install kernel sources for target in the $KERNEL_SRC directory||.|
|help||Show this online help.||.|
|info||Show information about a target.||.|
|kbuild||Build kernel from source.||assumes the current directory is the top kernel source dir.|
|kinstall||Install kernel for use on target.||assumes the current directory is the top kernel source dir.|
|list||Show a list of available targets.||.|
|login||Run a program to perform a network login on the target.||.|
|off||Turn target off||.|
|on||Turn target on||.|
|pos||Show power status of target||.|
|reboot||Reboot (power on and off) target board.||.|
|release||Release a reservation of a target.||.|
|reserve||Reserve a target for use.||.|
|reset||Reset target board.||.|
|rm||Remove files from the target.||.|
|run||Run a command on the target, collecting it's output||.|
|set_config||Set an individual config option||assumes the current directory is top kernel source dir|
|setenv||Starts shell with environment for performing build and other operations||.|
|status||Show status of target, including reservations.||not implemented yet (currently only shows reservation, but not board status)|
|vars||Show information about environment vars used by 'ttc'||.|
|version||Show version information and exit.||.|
|wait_for||Wait for a condition to be true.||command is executed on host (not on the target)|
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
ttc 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
ttc commands one would use to accomplish this:
- get a list of targets connected to this host
$ ttc list Targets on this host: ebony innovator nut osk test
- 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
- (optionally) apply patches to the kernel sources
$ patch -p1 <../printk-times.patch
- get a default kernel configuration for this target
$ ttc get_config
- set specific configuration options
$ ttc set_config CONFIG_PRINTK_TIME==y
- build the kernel, and install it
$ ttc kbuild $ ttc kinstall
- reboot the target with the new kernel
(either one of: On the target board, type "reboot":
or from the host, use:
$ ttc reset
- (optionally) put additional files on the target
$ ttc cp foo bar target:/tmp $ ttc cp test.sh target_bin:
- login to the console and do some work
$ ttc console <do interactive work on the target>
Runs a program to access the target console.
Usage: ttc [<target>] 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
minicom, 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.
Copy files to or from the target.
Usage: ttc [<target>] cp <src1> [<src2> ...] <dest>
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:
Install kernel config for target in the $KBUILD_OUTPUT directory
Usage: ttc [<target>] get_config [-o <otherdir>]
Use -o to specify an alternate KBUILD_OUTPUT directory (default is '.') Assumes the current directory is the top kernel source dir.
Install kernel sources for target in the $KERNEL_SRC directory
Usage: ttc [<target>] get_kernel [-o <outputdir>]
Use -o to specify a specific output kernel source directory. The default output directory, if none is specified, is 'linux'.
Show the online help.
Usage: ttc help [<command>]
If a command is specified, show help Release a reservation of a target.and usage information for that command.
Show information about a target.
Usage ttc [<target>] info [-v] [-n <attr>]
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, <attr>.
Install kernel for use on target.
Usage: ttc [<target>] kinstall
Assumes the current directory is the top kernel source directory.
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.
Run a program to perform a network login on the target.
Usage: ttc [<target>] login
Turn on the power to the target
Usage: ttc [<target>] on
Turn off the power to the target
Usage: ttc [<target>] off
Show the power status of the target
Usage: ttc [<target>] pos
Reboot the target board.
Usage: ttc [<target>] 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 the target board.
Usage: ttc [<target>] 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.
Remove files from the target.
Usage: ttc [<target>] rm <file1> [<file2>...]
Run a command on the target, and return it's output.
Usage: ttc [<target>] run "command <args>"
Set one or more individual config options
Usage: ttc [<target>] set_config [-o <outputdir>] <option-def> ...
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 <option-defs> may be specified with one command. Each <option-def> has the syntax: <option-name><operation><value>.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.
- 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.
Prepare environment for building for the target
Usage: ttc [<target>] 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
Show status of target, including reservations.
Usage: ttc [<target>] 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.
Show information about variables and config files used by ttc
Usage: ttc [<target>] vars
Show version information and exit.
Usage: ttc version
Wait for a condition to be true.
Usage: ttc [<target>] wait_for [-i <interval>] [-t <timeout>] <command> 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:
- read the global config file (/etc/ttc.conf)
- read a local config file (if specified by TTC_CONF)
- read environment variables
Automated use of 'ttc'
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
ttc is named
is located in the
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:
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=<name>". 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
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:
|Attribute Name||Meaning of value||Notes|
|target||Short (one-word) name of the target||Names starting with '.' are hidden from 'ttc list'|
|real_board||"Real" name for the target board||This is used if the multiple target configurations are used with a single physical (real) target board.|
|inherit_from||Target to inherit attributes from.||Used to reference a common block of attributes.|
|description||A description of the target board. Usually multi-line||This field is used for humans to let them know the attributes of the board.|
|TOOL_PATH||Path where toolchain tools are located.||This appended to the PATH env. variable.|
|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 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 the top directory of the kernel source.|
|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||Should reference $src and $dest|
|copy_from_cmd||Command(s) to copy files from target to host||Should reference $src and $dest|
|rm_cmd||Command(s) to remove files from target||This command should reference $dest as the location on the target of the file(s) to be removed.|
|ipaddr||Target IP address||.|
|reboot_cmd||Command(s) to reboot the target, from the host||This should power-cycle of the board, producing a cold boot of the hardware.|
|reset_cmd||Command(s) to reset the target, from the host||This is intended to be a soft reset of the hardware.|
|console_cmd||Command(s) to start an interactive console for the target.||This is usually something like minicom or screen.|
|login_cmd||Command(s) to start an interactive login session with the target||This is usually telnet, ssh or 'adb shell'. Usually, multiple login commands can be started at one time to a single target.|
|target_bin||Directory on target where binary files are located||This can be used with 'ttc cp' to put executable files in a place on the target where they can be found using the target's PATH variable.|
|fsbuild_cmd||Command(s) to build a new filesystem image for the target||.|
|fsinstall_cmd||Command(s) to install a new filesystem imgae for the target||.|
|run_cmd||Command to execute a command on the target||This command should reference $COMMAND as the string for the command to execute|
|reset_delay||Time in seconds to wait after reseting or rebooting the target||Only used if '-w' is used with 'ttc reboot' or 'ttc reset'|
Configuration attribute details
This section lists each configuration attribute, and what its value should be.
- 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.
- 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.
- 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.
- 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.
- 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.
- Architecture specifier for the kernel build (eg. arm, ppc, i386)
- Toolchain prefix used with kernel builds (eg. arm-sony-linux- )
- Place where the kernel is installed
- Default name to use for kernel source directory
- Default directory for kernel build output
- Name of the kernel image file (eg. bzImage, uImage)
- Command(s) to install the kernel image. (Assumes that the current working dir is $KERNEL_SRC)
- Command(s) to put a default kernel configuration file (.config) in $KBUILD_OUTPUT
- Command(s) to put the kernel source code in $KERNEL_SRC.
- 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).
- 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).
- Command(s) to remove files from target. This command should reference $dest as the location on the target for the removed file(s).
- Target IP address
- Command(s) to reset the target, from the host
- Command(s) to start an interactive console for the target (usually minicom)
- Command(s) to start an interactive login session with the target (usually telnet)
- Directory on target where binary files are located
- Command(s) to build a root filesystem for the target
- Command(s) to install a root filesystem to the target
- Command(s) to reserve a board (like switching the root filesystem, in case of different users having different root filesystems)
- 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 <board-name> -o 3 -d <some-delay>", 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.
- 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'
- 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.
Here is a sample:
# Some notes on syntax and conventions # Attributes that end in "_cmd" are assumed to be shell # commands, which will be executed in shell context # Each line of a multi-line _cmd will be executed # in its own sub-shell. (i.e. don't count on # exports or cd's being persistent from one line to # the next) # # The get_kernel_cmd should output the kernel source # to the directory specified by $KERNEL_SRC #====================================================== 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""" 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
- 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