function_safe_cmd >> function_check_capability >> Benchmark.lmbench2 >> function_kill_procs >> function_is_empty 

Fuego 1.2 wiki

Login

Adding a board in split format

NOTE: under construction
{{TableOfContents}}''NOTE: under construction''

Overview [edit section]

= Overview =To add your own board to Fuego, there are three main steps: * 1. create a test directory on the target * 2. create a board file (on the host) * 3. add your board as a node in the Jenkins interface

Create test directory on target [edit section]

== Create test directory on target ==First, log in to your target board, and create a directory wheretests can be run.  Usually, you do this as root, and a commonlyused directory for this is "/home/a".  To do this, do the following:
For target with network connectivity : {{{#!YellowBox $ ssh root@your_target <target>$ mkdir /home/a <target>$ exit}}}
For target with network connectivity : {{{#!YellowBox $ ssh root@your_target <target>$ mkdir /home/a <target>$ exit}}}
For target with Serial connectivity :
For target with Serial connectivity : 
Use minicom or any other serial terminal tool.Login to the target by giving username and password.Create the directory 'a' as below: {{{#!YellowBox <target>$ mkdir /home/a}}}
Use minicom or any other serial terminal tool.Login to the target by giving username and password.Create the directory 'a' as below: {{{#!YellowBox <target>$ mkdir /home/a}}}

Create board file [edit section]

== Create board file ==Now, create your board file.The board files reside in <fuego-source-dir>/fuego-ro/boards, andeach file has a filename with the name of the board, with the extension ".board".
The easiest way to create a board file is to copy an existing one,and edit the variables to match those of your board. The followinginstructions are for a board called 'myboard', that has networkingaccess, an ssh daemon running on target, and the ARM architecture.
The easiest way to create a board file is to copy an existing one,and edit the variables to match those of your board.  The followinginstructions are for a board called 'myboard', that has networkingaccess, an ssh daemon running on target, and the ARM architecture.
Do the following:{{{#!YellowBox $ cd fuego-ro/boards $ cp template-dev.board myboard.board $ vi myboard.board}}}
Do the following:{{{#!YellowBox $ cd fuego-ro/boards $ cp template-dev.board myboard.board $ vi myboard.board}}}

Note: you can use your own editor in place of 'vi'

''Note: you can use your own editor in place of 'vi' ''

Set board parameters [edit section]

=== Set board parameters ===A board file has parameters which define how Fuego interacts with yourboard.  There are lots of different parameters, but the most importantto get started quickly (and the most commonly edited) are:

TRANSPORT parameters [edit section]

==== TRANSPORT parameters ====Each board needs to specify how Fuego will communicate with it.This is done by specifying a TRANSPORT, and a few variables associatedwith that transport type.
  • TRANSPORT - this specifies the transport to use with the target * there are three transport types currently supported: 'ssh', 'serial', 'ttc' * Most boards will use the 'ssh' or 'serial' transport type * ex: TRANSPORT="ssh"
 * TRANSPORT - this specifies the transport to use with the target   * there are three transport types currently supported: 'ssh', 'serial', 'ttc'   * Most boards will use the 'ssh' or 'serial' transport type   * ex: TRANSPORT="ssh" 
Most targets require the following: * LOGIN - specifies the user account to use for Fuego operations * PASSWORD - specifies the password for that account (if any)
Most targets require the following: * LOGIN - specifies the user account to use for Fuego operations * PASSWORD - specifies the password for that account (if any)
There are some parameters that are specific to individual transports.
There are some parameters that are specific to individual transports.
For targets using ssh: * IPADDR * SSH_PORT
For targets using ssh: * IPADDR * SSH_PORT
IPADDR is the network address of your board. SSH_PORT is the port wherethe ssh daemon is listening for connections. By default this is 22, butyou should set this to whatever your target board uses.
IPADDR is the network address of your board.  SSH_PORT is the port wherethe ssh daemon is listening for connections.  By default this is 22, butyou should set this to whatever your target board uses.
For targets using serial: * SERIAL * BAUD * IO_TIME_SERIAL
For targets using serial: * SERIAL * BAUD * IO_TIME_SERIAL
SERIAL is serial port name used to access the target from the host. Thisis the name of the serial device node on the host (or in the container).this is specified without the /dev/ prefix. Some examples are: * ttyACM0 * ttyACM1 * ttyUSB0
SERIAL is serial port name used to access the target from the host.  Thisis the name of the serial device node on the host (or in the container).this is specified without the /dev/ prefix.  Some examples are: * ttyACM0 * ttyACM1 * ttyUSB0
BAUD is the baud-rate used for the serial communication, for eg. "115200".
BAUD is the baud-rate used for the serial communication, for eg. "115200".  
IO_TIME_SERIAL is the time required to catch the command's response from the target. This is specified as a decimal fraction of a second, and is usuallyvery short. A time that usually works is "0.1" seconds. * ex: IO_TIME_SERIAL="0.1"
IO_TIME_SERIAL is the time required to catch the command's response from the target. This is specified as a decimal fraction of a second, and is usuallyvery short.  A time that usually works is "0.1" seconds. * ex: IO_TIME_SERIAL="0.1"
This value directly impacts the speed of operations over the serial port, soit should be adjusted with caution. However, if you find that some operationsare not working over the serial port, try increasing this value (in small increments - 0.15, 0.2, etc.)
This value directly impacts the speed of operations over the serial port, soit should be adjusted with caution.  However, if you find that some operationsare not working over the serial port, try increasing this value (in small increments - 0.15, 0.2, etc.)

Note: In the case of TRANSPORT="serial", Please make sure that docker container and Fuego have sufficient permissions to access the specified serial port. You may need to modify docker-create-usb-privileged-container.sh prior to making your docker image, in order to make sure the container can access the ports. Also, if check that the host filesystem permissions on the device node (e.g /dev/ttyACM0 allows access. From inside the containeryou can try using the sersh or sercp commands directly, to test access tothe target.

''Note: In the case of TRANSPORT="serial", Please make sure that docker container and Fuego have sufficient permissions to access the specified serial port. You may need to modify docker-create-usb-privileged-container.sh prior to making your docker image, in order to make sure the container can access the ports.  Also, if check that the host filesystem permissions on the device node (e.g /dev/ttyACM0 allows access. From inside the containeryou can try using the sersh or sercp commands directly, to test access tothe target.''
For targets using ttc: * TTC_TARGET
For targets using ttc: * TTC_TARGET
TTC_TARGET is the name of the target used with the 'ttc' command.
TTC_TARGET is the name of the target used with the 'ttc' command.

Other parameters [edit section]

==== Other parameters ==== * BOARD_TESTDIR * ARCHITECTURE * PLATFORM * DISTRIB
The BOARD_TESTDIR directory is an absolute path in the filesystem on thetarget board where the Fuego tests are run.Normally this is set to something like "/home/a", but you can set it toanything. The user you specify for LOGIN should have access rights tothis directory.
The BOARD_TESTDIR directory is an absolute path in the filesystem on thetarget board where the Fuego tests are run.Normally this is set to something like "/home/a", but you can set it toanything.  The user you specify for LOGIN should have access rights tothis directory.
The ARCHITECTURE is a string describing the architecture used by toolchains to build the tests for the target.
The ARCHITECTURE is a string describing the architecture used by toolchains to build the tests for the target.
The PLATFORM variable indicates the toolchain to use to build the testsfor the target. If you are using an ARM target, set this to "qemu-armv7hf".This is a default ARM toolchain installed in the docker container, and shouldwork for most ARM boards.
The PLATFORM variable indicates the toolchain to use to build the testsfor the target.  If you are using an ARM target, set this to "qemu-armv7hf".This is a default ARM toolchain installed in the docker container, and shouldwork for most ARM boards.
If you are not using ARM, or for some reason the pre-installed arm toolchainsdon't work for the Linux distribution installed on your board, then you will need to install your own SDK or toolchain. In this case, followthe steps in Adding a toolchain, then come back to this step and setthe PLATFORM variable to the name you used for that operation.
If you are not using ARM, or for some reason the pre-installed arm toolchainsdon't work for the Linux distribution installed on your board, then you will need to install your own SDK or toolchain.  In this case, followthe steps in [[Adding a toolchain]], then come back to this step and setthe PLATFORM variable to the name you used for that operation.
For other variables in the board file, see the section below.
For other variables in the board file, see the section below.
The DISTRIB variable specifies attributes of the Linux distributionrunning on the board, that are used by Fuego. Currently, this is mainly used to tell Fuego what kind of system logger the operating system onthe board has. Here are some options that are available: * base.dist - a "standard" distribution that implements syslogd-style system logging. It should have the commands: logread, logger, and /var/log/messages * nologread.dist - a distribution that has no 'logread' command, but does have /var/log/messages * nosyslogd.dist - a distribution that does not have syslogd-style system logging.
The DISTRIB variable specifies attributes of the Linux distributionrunning on the board, that are used by Fuego.  Currently, this is mainly used to tell Fuego what kind of system logger the operating system onthe board has.  Here are some options that are available: * base.dist - a "standard" distribution that implements syslogd-style system logging.  It should have the commands: logread, logger, and /var/log/messages * nologread.dist - a distribution that has no 'logread' command, but does have /var/log/messages * nosyslogd.dist - a distribution that does not have syslogd-style system logging.
If DISTRIB is not specified, Fuego will default to using "nosyslogd.dist".
If DISTRIB is not specified, Fuego will default to using "nosyslogd.dist".

Add node to Jenkins interface [edit section]

== Add node to Jenkins interface ==Finally, add the board in the Jenkins interface.
In the Jenkins interface, boards are referred to as "Nodes".
In the Jenkins interface, boards are referred to as "Nodes".
You can see a list of the boards that Fuego knows about using: * $ ftc list-boardsWhen you run this command, you should see the name of the board you justcreated.
You can see a list of the boards that Fuego knows about using: * $ ftc list-boardsWhen you run this command, you should see the name of the board you justcreated.
You can see the nodes that have already been installed in Jenkins with: * $ ftc list-nodes
You can see the nodes that have already been installed in Jenkins with: * $ ftc list-nodes
To actually add the board as a node in jenkins, inside the docker container, run the following command at a shell prompt: * $ ftc add-nodes <board_name>
To actually add the board as a node in jenkins, inside the docker container, run the following command at a shell prompt: * $ ftc add-nodes <board_name>

Board-specific test variables [edit section]

= Board-specific test variables =The following other variables can also be defined in the board file: * MAX_REBOOT_RETRIES * FUEGO_TARGET_TMP
See Variables for the definition and usage of these variables.
See [[Variables]] for the definition and usage of these variables.

General Variables [edit section]

== General Variables ==== File System test variables (SATA, USB, MMC) ==If running filesystem tests, you will want to declare the Linux device nameand mountpoint path, for the filesystems to be tested.  There are threedifferent device/mountpoint options available depending on the testplan youselect (SATA, USB, or MMC).  Your board may have all of these types ofstorage available, or only one.
To prepare to run a test on a filesystem on a sata device, define theSATA device and mountpoint variables for your board.
To prepare to run a test on a filesystem on a sata device, define theSATA device and mountpoint variables for your board.
For example, if you had a SATA device with a mountable filesystem accessibleon device /dev/sdb1, and you have a directory on your target of /mnt/satathat can be used to mount this device at, you could declare the followingvariables in your board file. * SATA_DEV="/dev/sdb1" * SATA_MP="/mnt/sata"
For example, if you had a SATA device with a mountable filesystem accessibleon device /dev/sdb1, and you have a directory on your target of /mnt/satathat can be used to mount this device at, you could declare the followingvariables in your board file. * SATA_DEV="/dev/sdb1" * SATA_MP="/mnt/sata"
You can define variables with similar names (USB_DEV and USB_MP, or MMC_DEV and MMC_MP) for USB-based filesystems or MMC-based filesystems.
You can define variables with similar names (USB_DEV and USB_MP, or MMC_DEV and MMC_MP) for USB-based filesystems or MMC-based filesystems.

LTP test variables [edit section]

== LTP test variables ==LTP (the Linux Test Project) has a large number of tests, not all of whichmay be expected to work correctly on your board.  Some of the LTP testsdepend on the kernel configuration or on aspects of your Linux distributionor your configuration.
You can control whether the LTP posix test succeeds by indicating thenumber of positive and negative results you expect for your board.These numbers are indicated in test variables in the board file: * LTP_OPEN_POSIX_SUBTEST_COUNT_POS * LTP_OPEN_POSIX_SUBTEST_COUNT_NEG
You can control whether the LTP posix test succeeds by indicating thenumber of positive and negative results you expect for your board.These numbers are indicated in test variables in the board file: * LTP_OPEN_POSIX_SUBTEST_COUNT_POS * LTP_OPEN_POSIX_SUBTEST_COUNT_NEG
You should run the LTP test yourself once, to see what your baseline valuesshould be, then set these to the correct values for your board (configurationand setup).
You should run the LTP test yourself once, to see what your baseline valuesshould be, then set these to the correct values for your board (configurationand setup).
Then, Fuego will report any deviation from your accepted numbers, for LTP tests on your board.
Then, Fuego will report any deviation from your accepted numbers, for LTP tests on your board.
TBWiki engine 1.9.3 by Tim Bird