Integration with ttc
This page describes how to use Fuego with
ttc is a tool
used for manual and automated access to and manipulation of target
boards. It is a tool developed by Tim Bird and used at Sony for
managing their board farms, and for doing kernel development on multiple
different target boards at a time (including especially boards with
different processors and architectures.)
This page describes how
ttc and Fuego are integrated, so that the
Fuego test framework can use
ttc as it’s transport mechanism.
You can find more information about
ttc on the embedded Linux wiki
Outline of supported functionality
Here is a rough outline of the support for
ttc in Fuego:
Integration for the tool and helper utilities in the container build
When the docker container is built,
ttcis downloaded from Github and installed into the Docker image.
During this process, the path to the
ttc.conffile is changed from
ttcis a valid transport option in Fuego
You can specify
ttcas the ‘transport’ for a board, instead of
ttcadded support for
-ras an option to the
This is required since Fuego uses
-rextensively to do recursive directory copies (See Transport_notes for details)
The Fuego core scripts have been modified to avoid using wildcards on
A new test called
Functional.fuego_transporthas been added
This tests use of wildcards, multiple files and directories and directory recursion with the Fuego
It also indirectly tests the
getfunction (the other major Fuego transport function), because logs are obtained during the test.
ttc has several sub-commands. Fuego currently only uses the following
ttc run- to run a command on the target
ttc cp- to get a file from the target, and to put files to the target
Note that some other commands, such as
ttc reboot are not used, in
spite of there being similar functionality provided in fuego (see
function target reboot and function
ov rootfs reboot).
Finally, other commands, such as
ttc kbuild and
ttc kinstall are not used currently. These may be
used in the future, when Fuego is expanded to have a focus on tests
that require kernel rebuilding.
Location of ttc.conf
ttc on a host uses the default configuration file at
/etc/ttc.conf. Fuego modifies the
ttc installed inside the
Fuego docker container, so that it uses the configuration
file located at
/fuego-ro/conf/ttc.conf as its default.
During Fuego installation,
/etc/ttc.conf is copied to
/fuego-ro/conf from the host machine, if it is present (and a copy
ttc.conf is not already there).
Steps to use ttc with a target board
Here is a list of steps to set up a target board to use
These steps assume you have already added a board to fuego
following the steps described in Adding a board.
If needed, create your Docker container using
This may be needed if you are using
ttcwith board controls that require access to USB devices (such as the Sony debug board)
install.sh, as documented in Installing Fuego.
Make sure that
fuego-ro/conf/ttc.confhas the definitions required for your target board
Validate this by doing
ttc listto see that the board is present, and
ttc cpcommands, to test that these operations work with the board, from inside the container.
Edit the fuego board file (found in
TTC_TARGETvariable to the name for the target used by
See the following example, for a definition for a target named ‘bbb’ (for my Beaglebone black board):TRANSPORT=ttc TTC_TARGET=bbb
modify your copy_to_cmd
ttc.conf file, you may need to make changes to the
copy_to_cmd definitions for boards used by Fuego. Fuego allows
programs to pass a
-r argument to its internal
which in turn invokes
cp command, with the source as
target and destination as the host. In other words, it ends up
copy_from_cmd for the indicated target.
All instances of
copy_to_cmd should be modified to reference a new
$copy_args, and they should support the use
-r in the command arguments.
Basically, if a Fuego test uses
put -r at any point, this needs to
be supported by
ttc will pass any ‘-r’ seen to the
subcommand in the environment variable
$copy_args, where you can use
it as needed with whatever sub-command (
scp, or something
else) that you use to execute a
ttc.conf.sample2 for usage examples.