FrontPage 

Fuego 1.0 wiki

Login

Adding a toolchain in split format

{{TableOfContents}}

Introduction [edit section]

= Introduction =In order to build tests for your target board, you need to install a toolchain(often in the form of an SDK) into the fuego system, and let fuego knowhow to access it.
Adding a toolchain to Fuego consists of these steps: * 1. obtain (generate or retrieve) the toolchain * 2. copy the toolchain to the container * 3. install the toolchain inside the container * 4. create a -tools.sh file for the toolchain * 5. reference the toolchain in the appropriate board file
Adding a toolchain to Fuego consists of these steps: * 1. obtain (generate or retrieve) the toolchain * 2. copy the toolchain to the container * 3. install the toolchain inside the container * 4. create a -tools.sh file for the toolchain * 5. reference the toolchain in the appropriate board file

Obtain a toolchain [edit section]

= Obtain a toolchain =First, you need to obtain a toolchain that will work with your board.
If you are using an ARM-based target, then to get started, you may use the pre-installed armv7hf toolchain. However, there is no guarantee that this willwork on your board. It is much better to install your own SDK for your boardinto the fuego system.
If you are using an ARM-based target, then to get started, you may use the pre-installed armv7hf toolchain.  However, there is no guarantee that this willwork on your board.  It is much better to install your own SDK for your boardinto the fuego system.

Building a Yocto Project SDK [edit section]

== Building a Yocto Project SDK ==When you build an image in the Yocto Project, you can also build an SDKto go with that image using the '-c do_populate_sdk' build step with bitbake.
To build the SDK in Yocto Project, inside your yocto build directory do: * bitbake <image-name> -c do_populate_sdk
To build the SDK in Yocto Project, inside your yocto build directory do: * bitbake <image-name> -c do_populate_sdk
This will build an SDK archive (containing the toolchain, header files andlibraries needed for creating software on your target, and put it intothe directory <build-root>/tmp/deploy/sdk/
This will build an SDK archive (containing the toolchain, header files andlibraries needed for creating software on your target, and put it intothe directory <build-root>/tmp/deploy/sdk/
For example, if you are building the 'core-image-minimal' image, you wouldexecute:{{{#!YellowBox $ bitbake core-image-minimal -c do_populate_sdk}}}At this step look in tmp/deploy/sdk and note the name of the sdk installpackage (the file ending with .sh).
For example, if you are building the 'core-image-minimal' image, you wouldexecute:{{{#!YellowBox $ bitbake core-image-minimal -c do_populate_sdk}}}At this step look in tmp/deploy/sdk and note the name of the sdk installpackage (the file ending with .sh).

Install the SDK in the docker container [edit section]

= Install the SDK in the docker container =To allow fuego to use the SDK, you need to install it into the fuegodocker container.  First, transfer the SDK into the container usingdocker cp.
With the container running, on the host machine do: * docker ps (note the container id) * docker cp tmp/deploy/sdk/<sdk-install-package> <container-id>:/tmp
With the container running, on the host machine do: * docker ps (note the container id) * docker cp tmp/deploy/sdk/<sdk-install-package> <container-id>:/tmp
This last command will place the SDK install package into the /tmpdirectory in the container.
This last command will place the SDK install package into the /tmpdirectory in the container.
Now, install the SDK into the container, into /userdata/toolchains.
Now, install the SDK into the container, into /userdata/toolchains.
At the shell inside the container, run the SDK install script(which is a self-extracting archive): * /tmp/poky-....sh * during the installation, specify an installation path under /userdata/toolchains, like: /userdata/toolchains/poky/2.0.1
At the shell inside the container, run the SDK install script(which is a self-extracting archive):  * /tmp/poky-....sh    * during the installation, specify an installation path under /userdata/toolchains, like: /userdata/toolchains/poky/2.0.1
These instructions are for an SDK built by the Yocto Project. Similarinstructions would apply for installing a different toolchain or SDK.That is, get the SDK into the container, then install it into /userdata/toolchains.Note that it is not strictly required that the SDK be installed there - it can be installedanywhere you need to (say, under /opt), but the convention is to placetoolchains under userdata for consistency, and to make them visible to both thecontainer and the host.
These instructions are for an SDK built by the Yocto Project.  Similarinstructions would apply for installing a different toolchain or SDK.That is, get the SDK into the container, then install it into /userdata/toolchains.Note that it is not strictly required that the SDK be installed there - it can be installedanywhere you need to (say, under /opt), but the convention is to placetoolchains under userdata for consistency, and to make them visible to both thecontainer and the host.

Create a -tools.sh file for the toolchain [edit section]

= Create a -tools.sh file for the toolchain =Now, fuego needs to be told how to interact with the toolchain.During test execution, the fuego system determines what toolchain to usebased on the value of the PLATFORM variable in the board file for the targetunder test.  The PLATFORM variable is a string that is used to selectthe appropriate 'tools.sh' file in /userdata/toolchains.
You need to determine a name for this PLATFORM, and then create a filewith that name, called $PLATFORM-tools.sh. So, for example if you createdan SDK with poky for the qemuarm image, you might call the PLATFORM "poky-qemuarm". You would create a file called "poky-qemuarm-tools.sh"
You need to determine a name for this PLATFORM, and then create a filewith that name, called $PLATFORM-tools.sh.  So, for example if you createdan SDK with poky for the qemuarm image, you might call the PLATFORM "poky-qemuarm".  You would create a file called "poky-qemuarm-tools.sh"
The -tools.sh file is used by Fuego to define the environment variables neededto interact with the SDK. This includes things like CC, AR, and LD. The completelist of variables that this script neeeds to provide are described on the pagetools.sh
The -tools.sh file is used by Fuego to define the environment variables neededto interact with the SDK.  This includes things like CC, AR, and LD.  The completelist of variables that this script neeeds to provide are described on the page[[tools.sh]]
Inside the -tools.sh file, you execute instructions that will set theenvironment variables needed to build software with that SDK. For an SDK built by the Yocto Project, this involves setting a fewvariables, and calling the environment-setup... script that comes with the SDK.For SDKs from other sources, you can define the needed variables by directlyexporting them.
Inside the -tools.sh file, you execute instructions that will set theenvironment variables needed to build software with that SDK.  For an SDK built by the Yocto Project, this involves setting a fewvariables, and calling the environment-setup... script that comes with the SDK.For SDKs from other sources, you can define the needed variables by directlyexporting them.
Here is an example of the tools.sh script for poky-qemuarm. This isin the sample file /userdata/toolchains/poky-qemuarm-tools.sh:
Here is an example of the tools.sh script for poky-qemuarm.  This isin the sample file /userdata/toolchains/poky-qemuarm-tools.sh:
{{{#!YellowBox# fuego toolchain script# this sets up the environment needed for fuego to use a toolchain# this includes the following variables:# CC, CXX, CPP, CXXCPP, CONFIGURE_FLAGS, AS, LD, ARCH# CROSS_COMPILE, PREFIX, HOST, SDKROOT# CFLAGS and LDFLAGS are optional# # this script is sourced by /userdata/conf/tools.sh
POKY_SDK_ROOT=/userdata/toolchains/poky/2.0.1export SDKROOT=${POKY_SDK_ROOT}/sysroots/armv5e-poky-linux-gnueabi
POKY_SDK_ROOT=/userdata/toolchains/poky/2.0.1export SDKROOT=${POKY_SDK_ROOT}/sysroots/armv5e-poky-linux-gnueabi
# the Yocto project environment setup script changes PATH so that python uses# libs from sysroot, which is not what we want, so save the original path# and use it laterORIG_PATH=$PATH
# the Yocto project environment setup script changes PATH so that python uses# libs from sysroot, which is not what we want, so save the original path# and use it laterORIG_PATH=$PATH
PREFIX=arm-poky-linux-gnueabisource ${POKY_SDK_ROOT}/environment-setup-armv5e-poky-linux-gnueabi
PREFIX=arm-poky-linux-gnueabisource ${POKY_SDK_ROOT}/environment-setup-armv5e-poky-linux-gnueabi
HOST=arm-poky-linux-gnueabi
HOST=arm-poky-linux-gnueabi
# don't use PYTHONHOME from environment setup scriptunset PYTHONHOMEenv -u PYTHONHOME}}}
# don't use PYTHONHOME from environment setup scriptunset PYTHONHOMEenv -u PYTHONHOME}}}

Reference the platform in a board file [edit section]

= Reference the platform in a board file =Now, to use that SDK for building test software for a particular target board,set the value of the PLATFORM variable in the board file for that target.
Edit the board file: * vi /userdata/conf/boards/foo.board
Edit the board file: * vi /userdata/conf/boards/foo.board
And add (or edit) the line: * PLATFORM="poky-qemuarm"
And add (or edit) the line: * PLATFORM="poky-qemuarm"

Notes [edit section]

run_python internally to execute the container'sdefault python interpreter, instead of the interpreter that was builtby the Yocto Project.
= Notes === Python execution ==You may notice that some of the example scripts set the environmentvariable ORIG_PATH.  This is used by the function [[function_run_python|run_python]] internally to execute the container'sdefault python interpreter, instead of the interpreter that was builtby the Yocto Project.

Previous versions of Fuego/JTA [edit section]

== Previous versions of Fuego/JTA ==In previous versions of Fuego and JTA (before September, 2016), you added support for a platform by editing the file /userdata/conf/tools.sh.This method of adding support for a new toolchain is deprecated, in favor ofthe current system of adding a separate file for each toolchain installedin the system.
TBWiki engine 1.9.3 by Tim Bird