1.2. Building the SDK¶
This page provides the steps to build the Processor SDK and individual components from source. The Processor SDK build is based on the Arago Project which provides a set of layers for OpenEmbedded and the Yocto Project targeting TI platforms.
This page will provide the basic steps required to recreate the Processor SDK along with a reference of Processor SDK specific configurations, build targets, and target devices. Also, tips and suggestions are provided along with links for more in-depth information.
1.2.2. Quick Start¶
126.96.36.199. Prerequisites (One-time setup)¶
Host Setup - Ubuntu (Recommended)
The recommended Linux distribution is Ubuntu 18.04.
The following build host packages are required for Ubuntu. The following command will install the required tools on the Ubuntu Linux distribution.
For Ubuntu 18.04, please run the following:
$ sudo apt-get install build-essential autoconf \ automake bison \ flex libssl-dev bc u-boot-tools \ python diffstat \ texinfo gawk chrpath dos2unix \ wget unzip socat doxygen libc6:i386 \ libncurses5:i386 libstdc++6:i386 \ libz1:i386 g++-multilib \ git python3-distutils python3-apt
By default Ubuntu uses “dash” as the default shell for /bin/sh. You must reconfigure to use bash by running the following command:
sudo dpkg-reconfigure dash
Be sure to select “No” when you are asked to use dash as the default system shell.
Large Swap File
Building large packages, especially several at a time, requires a lot of working memory for a computer. For computers with 32 GB or RAM or more, this should not be a problem. For computers with less RAM, a swap file of ~16GB may be needed to build large packages. Creating a large swap file, or resizing a small swap file to be larger will help avoid build errors for large packages.
If working behind a proxy, please see Working Behind a Network Proxy.
Run the following commands to install the ARM Toolchains. 64-bit products like AM64x need both. 32-bit products like AM335x and AM437x only need the 32-bit toolchain (arm-none-linux-).
$ wget https://developer.arm.com/-/media/Files/downloads/gnu-a/9.2-2019.12/binrel/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf.tar.xz $ tar -Jxvf gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf.tar.xz -C $HOME $ wget https://developer.arm.com/-/media/Files/downloads/gnu-a/9.2-2019.12/binrel/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu.tar.xz $ tar -Jxvf gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu.tar.xz -C $HOME
188.8.131.52. Build Steps¶
Please refer to here for the layer configuration for a particular release of Processor SDK Linux. The MACHINE can be set to am64xx-evm, for example.
The final command below will build the tisdk-default-image, which is the Processor SDK image with arago filesystem. See Build Options for a list of additional targets.
$ git clone https://git.ti.com/git/arago-project/oe-layersetup.git tisdk $ cd tisdk $ ./oe-layertool-setup.sh -f configs/processor-sdk/processor-sdk-08.06.00-config.txt $ cd build $ . conf/setenv $ export TOOLCHAIN_PATH_ARMV7=$HOME/gcc-arm-9.2-2019.12-x86_64-arm-none-linux-gnueabihf $ export TOOLCHAIN_PATH_ARMV8=$HOME/gcc-arm-9.2-2019.12-x86_64-aarch64-none-linux-gnu $ git clone https://git.ti.com/git/security-development-tools/core-secdev-k3.git -b master $ export TI_SECURE_DEV_PKG_K3=`pwd`/core-secdev-k3 $ MACHINE=<machine> bitbake -k tisdk-default-image
Your tisdk-default-image wic image will be generated in arago-tmp-[toolchain]/deploy directory. Use Processor_SDK_Linux_create_SD_card to flash this image on the SD-Card.
1.2.3. Processor SDK Build Reference¶
The following sections provide information for configuration, build options, and supported platforms of the Processor SDK.
184.108.40.206. Layer Configuration¶
Please refer to here for the layer configuration for a particular release of Processor SDK Linux.
220.127.116.11. Build Options¶
In addition to individual components packages, the following table provides a list of build targets supported. These are the <target> used in the command:
MACHINE=<machine> bitbake <target>
The “Build Output” is given relative to the arago-tmp-[toolchain]/deploy directory.
|tisdk-base-image||images/<machine>/tisdk-base-image-<machine>.tar.xz||Minimal Target Filesytem|
The following platforms are supported in Processor SDK. These are the <machine> in the command:
MACHINE=<machine> bitbake <target>
|am64xx-evm||AM64x GP EVM, AM64x Starter Kit (SK)|
|am64xx-hs-evm||AM64x HS EVM|
Processor SDK Linux supports RT Linux Kernel for the following machines/EVMs. Use the command below to make the RT builds:
MACHINE=<machine> ARAGO_RT_ENABLE=1 bitbake <target>
|am64xx-evm | AM64x GP EVM, AM64x Starter Kit (SK)|
One or more recipes can be specified for the <target> for greater granularity of recipe development and debug. Specifying a recipe name, minus the version (if the version is appended to the name), will build the recipe and all its dependencies.
For example, the command below builds only the opencl recipe and all the dependencies it defines.
MACHINE=<machine> bitbake opencl
After the bitbake command above is successfully done, arago-tmp-[toolchain]/work/<machine>-linux-gnueabi/opencl directory will be available including the original source code under the git folder, independent shared objects (.so files) under packages-split folder, and IPKs under deploy-ipks folder.
Please note that the output of a recipe can be in another folder under “arago-tmp-[toolchain]/work” directory, depending on the defines of the recipe.
When needed, source code under the work directory (e.g.,
be modified. After the modification is done, run the following commands
to force recompilation with the new code and rebuilding of the recipe,
MACHINE=<machine> bitbake opencl --force -c compile
MACHINE=<machine> bitbake opencl
To install a modified and rebuilt package, copy the new IPKs from the deploy-ipks folder (e.g., arago-tmp-[toolchain]/work/<machine>-linux-gnueabi/opencl/[version]/deploy-ipks) to the target system and then run the following command to install the IPKs:
opkg install [package_ipk].ipk
Cleaning a Built Recipe
A built recipe can be cleaned using:
MACHINE=<machine> bitbake <target> -c cleansstate
The cleansstate task will clean recipe’s work directory and remove the recipe’s output from the dependency tree used by other recipe’s during compilation.
1.2.4. Common Variations¶
Rebuilding without SGX
In Processor SDK delivered today the graphics hardware acceleration is enabled by default for device families with SGX (e.g. AM335x, AM437x, AM57xx). As a result, some of the applications with graphics dependencies will not run properly on device variants in those families that do not contain the SGX accelerator (e.g. AM3352, AM4372, etc.). The Processor SDK has been enhanced to provide the same OOB experience with software rendering provided by QT5/Weston. The non-SGX software rendering build will be enabled by adding the following to the bottom of conf/local.conf immediately before invoking bitbake.
Rebuilding without Wayland
If a full Window system is not needed, i.e. if you simply want apps to run full screen using EGLFS then you can remove Wayland by adding the following to the bottom of conf/local.conf immediately before invoking bitbake:
DISTRO_FEATURES_remove = "wayland"
X11 Build instructions
X11 has been validated as a build option, on top of Processor SDK 4.1 release. In order to build with X11 instead of Wayland, please use the configuration processor-sdk-04.01.00.06-x11-config.txt for oe-layer-setup. One of the key differences between this configuration file and the processor-sdk-04.01.00.06 config file is the branch from meta-processor-sdk. For X11 build, morty-x11-experimental branch is used, where the DISTRO_CONFIG is set to X11 instead of wayland.
All the X11 related components are provided by the IMG DDK X11 package and located under /usr/local/XSGX directory instead of /usr/include and /usr/lib directories. The following applications and demos are built and verified with X11:
- SGX unitest programs: xgles1tests, xgles2test1, and etc.
- PVR SDK 3D demo programs: ChameleonMan, ExampleUI, and etc.
- QT5 Examples and demo programs over eglfs.x11 including matrix-gui-browser
In the X11 build, the xorg (Xserver) is running and owns the DSS resources by default. To support switching between X11 applications and non-X11 applications such as DRM modetest and gstreamer pipelines, the following shell file is provided to stop and start the Xserver.
1.2.5. See also¶
General information on Yocto, OpenEmbedded and Arago projects can be found at: