Enea Linux is made available as sources, this allows for of building various Enea Linux artifacts and is detailed in the following sections:

Build Enea Linux images using the following steps: Set the $MACHINE/<machine> variable to the target you need, e.g. intel-corei7-64. Clone Enea Linux sources using Repo tool. Please refer to for more details. $ mkdir enea-linux $ cd enea-linux $ repo init -u git@git.enea.com:linux/manifests/el_manifests-standard.git \ -b refs/tags/Enea_Linux_8.0 -m $MACHINE/default.xml $ repo sync Source the build environment $ cd poky $ TEMPLATECONF=meta-el-standard/conf/template.<machine> \ . ./oe-init-build-env <build_dir> Sourcing the build environment is needed everytime a new shell is used. However, sourcing using the TEMPLATECONF is only needed the first time around. After the first time, it is enough to source the build directory created before. The build directory may reside on an NFS mount, but the TMPDIR (<build_dir>/tmp) may not. Either build all on a local disk, or update TMPDIR in conf/local.conf to point to a local disk. Build Enea Linux image # You have already initiated the build environment and are in the <build_dir> $ bitbake <enea-image-name> $ cd <build_dir>/tmp/deploy/images/<target>/ # Here are the build binaries Some builds have restrictions on the length of the path name. If you get a build error indicating that the length is too long, you need to move your build to obtain a shorter path. Generated images are by default saved in <build_dir>/tmp/deploy/images/<target>, where <build_dir> by default is the current working directory. Images are created for emulation on host or for booting a physical target, according to how the build environment was set up before running bitbake. Depending on the number of processors and cores, the amount or RAM, the speed of your Internet connection and other factors, the build process can take several hours the first time you run it. Subsequent builds run much faster since parts of the build are cached. Make sure that the user running the build has access to the Git repositories on git.enea.com. The build process fetches information from git.enea.com so the user running the build shall have the ssh key properly configured. Please refer to for more details on how to get access to Enea Linux sources.

If you want to rebuild a cross-compilation toolchain to be used by in application development, use the following steps: Clone Enea Linux sources using Repo tool. Please refer to for more details on how to do this. $ mkdir enea-linux $ cd enea-linux $ repo init -u git@git.enea.com:linux/manifests/el_manifests-standard.git \ -b refs/tags/Enea_Linux_8.0 -m $MACHINE/default.xml $ repo sync Source the build environment $ cd poky $ TEMPLATECONF=meta-el-standard/conf/template.<machine> \ . ./oe-init-build-env <build_dir> Sourcing the build environment is needed everytime a new shell is used. However, sourcing using the TEMPLATECONF is only needed the first time around. Afterwards it is enough to source the build directory created before. The build directory may reside on an NFS mount, but the TMPDIR (<build_dir>/tmp) may not. Either build all on a local disk, or update TMPDIR in conf/local.conf to point to a local disk. Build Enea Linux SDK # You have already initiated the build environment and are in the <build_dir> $ bitbake <enea-image-name> -c populate_sdk_ext $ cd <build_dir>/tmp/deploy/sdk/ # Here is the SDK installer script Some builds have restrictions on the length of the path name. If you get a build error indicating that the length is too long, you need to move your build to obtain a shorter path. Generated SDK installer script is by default saved in <build_dir>/tmp/deploy/sdk, where <build_dir> by default is the current working directory. Depending on the number of processors and cores, the amount or RAM, the speed of your Internet connection and other factors, the build process can take several hours the first time you run it. Subsequent builds run much faster since parts of the build are cached. For more details on how to install and use the SDK, please refer to .

Regardless whether you decide to use the pre-built images or if you choose to build your own, the end result should be similar. Once you have the artifacts availalbe, you may proceed to booting Enea Linux on target. Enea Linux supports multiple booting methods so those will be described in the following sections.

Below you find an example of how to boot Enea Linux in a target supporting PXE. The PXE boot is handled by the target BIOS. This requires the setup of DHCP, TFTP and NFS servers on the host. The DHCP server contains a configuration for the target, found via the target MAC address, and refers to the TFTP server for the boot image and to the NFS server for the root file system. For the DHCP server, in addition to the general configuration, the DHCPD configuration should contain an entry for the target with the following information: Host name MAC hardware ethernet address (also available in the TFTP configuration) IP address, (assuming a fixed IP address is used) The TFTP server shall be defined as next-server The relative path in the TFTP server to the PXE file pxelinux.0 The NFS server IP address and the path to the rootfs on the NFS server, defined as option root-path Example of a DHCP server configuration: host intel-corei7-64_host { hardware ethernet 01:00:25:90:c8:c5:98; fixed-address 192.168.1.38; next-server 192.168.2.10; filename "intel-corei7-64_tftp/pxelinux.0"; option root-path "192.168.2.20:/export/intel-corei7-64_rootfs"; } For the TFTP server, the TFTP path to the target's pxelinux.0 file is given in the DHCP Configuration. Examples of files included in the TFTP subdirectory indicated by the DHCP configuration are: pxelinux.0 vesamenu.c32 boot/device01/bzImage (bootable image file) pxelinux.cfg/01-00-25-90-c8-c5-98 (Configuration file) One configuration file has the same name as the target's MAC address (but with hyphens instead of a colon). This configuration file contains a pointer to the bootable image and also a list of command line arguments to append when the image is started. The same NFS path to the root file system is both in the DHCP and the TFTP configuration. Example of a configuration file: default vesamenu.c32 prompt 0 timeout 100 label device01 menu label ^EneaLinuxNFS menu default kernel boot/device01/bzImage append root=/dev/nfs nfsmount=192.168.2.20:/export/intel-corei7-64_rootfs ip=dhcp console=ttyS0,115200 NFS server: The NFS server shall contain an unpacked root file system in the path indicated both in the DHCP and in the TFTP configuration. After configuring the servers, copy files from the build directory into the correctly configured paths: Ensure the target is not already running an OS, otherwise the target might attempt to change files on the root file system while it is populated with new files. Copy pxelinux.0 and vesamenu.c32 from the build directory, e.g. from <build_dir>tmp/work/corei7-64-enea-linux/syslinux/6.03-r0/image/usr/share/syslinux/. Copy bzImage from <build_dir>/tmp/deploy/images/<target>/. Populate the root file system in the NFS directory by unpacking enea-image-standard-intel-corei7-64.tar.gz found at <build_dir>/tmp/deploy/images/<target>/. Boot the target by: Use the BIOS or boot setup to select PXE boot, if not already selected. Reboot the target. The boot setup menu is usually launched by pressing F12 or ESC during BIOS power up tests. Look up the manufacturer's documentation for your board model to find the appropriate key.

Bitbake allows a modular approach of Metadata, by building images for the layers listed in the conf/bblayers.conf file from your build directory. To avoid polluting the build with unnecessary packages, before adding a new layer, it is recommended to check if the Metadata you need is already available in the enabled layers, in which case, for the intended configuration, it may require less modification. To ease further use of the layer, try to follow as many best practices as possible when creating it: Use names starting with the meta prefix (although this is not a requirement) Place your layer under poky Isolate different customizations by layer Assign the layer to a repository (to easily have access to maintenance) To enable a layer, its top path must be specified in the BBLAYERS variable, as follows: # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf # changes incompatibly POKY_BBLAYERS_CONF_VERSION = "2" BBPATH = "${TOPDIR}" BBFILES ?= "" BBLAYERS ?= " \ /path/to/poky/meta \ /path/to/poky/meta-el-common \ /path/to/poky/meta-el-standard \ /path/to/poky/meta-enea-bsp-common \ /path/to/poky/meta-enea-bsp-x86 \ /path/to/poky/meta-openembedded/meta-oe \ /path/to/poky/meta-openembedded/meta-networking \ /path/to/poky/meta-openembedded/meta-filesystems \ /path/to/poky/meta-openembedded/meta-python \ /path/to/poky/meta-poky \ /path/to/poky/meta-<layer> \ " Before adding an extra layer, please keep in mind that the order of layers is important (due to BitBake parsing conf/layer.conf as specified in BBLAYERS). To add an extra layer, you can modify the build/conf/bblayers.conf file in the source code editor you prefer, as described above, or use one of the specially designed Yocto tools. To do such, you can simply modify the build/conf/bblayers.conf file in the source code editor you prefer, as described above, or use one of the specially designed Yocto tools. For instance, in addition to the above, the Yocto Bitbake layers utility ensures a very useful checking of some basic layer requirements. Bitbake layers are available, as most of the BitBake tools, when sourcing oe-init-build-env. Therefore, to enable a custom meta layer, you should simply run the following from the build directory: bitbake-layers add-layer <meta-layer> If the specified layer doesn't contain a conf/layer.conf file, you should add one with the needed configuration. Also, to make sure the layer insertion is done in the right metadata, the utility looks for the bblayers.conf configuration file in the corresponding path, which should be satisfied if running the command from the generated build directory. For further information on this or on other utilities belonging to the same suite, run: bitbake-layers -h As a result, BBLAYERS shall be extended with the bsp-layer/s layer for your target and any other additional layer/s. For details on how to do this, see the Yocto 2.5 Dev Manual, section "Understanding and Creating Layers". If needed replace the Yocto version. Layers can be added when you initialize the build environment. The layers required for each target are specified in the build commands in the Enea Linux distribution's Release Information. Each Enea Linux customer is advised to add a custom layer for customer-specific additions and customizations, instead of modifying existing layers. The recommended way to modify a package is to edit directly in the recipe file. Utilizing the devshell, bitbake -c devshell <image_name>, when constructing or modifying recipes is really handy when experimenting, but do not forget to make the final updates directly in the recipe file. It is difficult to keep track of exactly what in the user environment is "dirty" and not in sync with current recipes. Therefore, always make sure to bitbake -c clean <image_name> after finishing up a devshell session, and adapt recipes accordingly to ensure a shareable and repeatable build environment.

Study the Hello World recipe in the Yocto Project Development Manual. If needed replace the example version (2.5) with the Yocto version in your Enea Linux distribution.

The default configuration produces a standard Linux installation, but it is often desirable to configure specific packages in more detail. Different packages implement their configuration in different ways, and there is no single method that is valid for all packages. As always, in a collaborative development environment, the developer should make sure that the recipes in the custom layer are upgraded accordingly when a reconfiguration of a specific package is done. In subsequent sections you find examples on how to configure some common packages.

The Linux kernel provides a vast array of configuration options, managed using its own configuration system. The kernel package can be supplied from different providers, and this example uses the virtual/kernel package name to refer to the kernel used in the build: $ bitbake -c menuconfig virtual/kernel menuconfig requires Ncurses. If the terminal that pops up immediately closes instead of showing the menuconfig interface, check that the Ncurses development library is installed. First build the kernel: $ bitbake -f -c compile -c install -c deploy virtual/kernel Then build the whole distribution: $ bitbake enea-image-<name>

Busybox uses the same configuration system as the Linux kernel and is therefore invoked similarly. In contrast to the kernel, there is generally only one variant of busybox in a distribution and we can therefore refer to it by the package name alone: $ bitbake -c menuconfig busybox

Adding commercial-licensed packages might pose distribution problems due to license agreements or patents. Commercial-licensed packages are not provided with Enea Linux. Depending on your use case, you might need to extend the initial image with more packages by adding recipes and updating the image definition, always in accordance with the license conditions. To succeed with building the customized image, you might need to solve dependencies by adding even more packages. Below is an example with steps on how to add a package with a commercial license. The configuration is updated in two places and the recipes are selected for the packages and any dependencies. This is only an illustrating example, the exact configuration may differ between different packages. Some packages could require other defines added to local.conf and some packages might need an added DEPENDS in the *.inc file, or other particular changes. Append the package name to the IMAGE_INSTALL definition, used in the recipe corresponding to the image you will build, as in one of the examples below: If you need the package in a set of images, to avoid defining it in each recipe, add the following line to IMAGE_INSTALL in meta-el-common/images/enea-image-common.inc package_name \ If you have specific images in which you need the package, add the following line in the corresponding recipes in meta-el-<profile>/images/enea-image-<profile>.bb IMAGE_INSTALL += " \ package_name \ " Add the required license to the LICENSE_FLAGS_WHITELIST definition. This can be done by adding script lines in the corresponding scripts/conf_setup.sh file, which appends LICENSE_FLAGS_WHITELIST += "<suitable-license> to conf/local.conf. To mitigate the build errors caused by packages with commercial licenses, you might also need to append the generic license LICENSE_FLAGS_WHITELIST += "commercial" in the same way as above. Select the needed recipes for the packages and add these to the build configuration. Select the needed recipes to resolve dependencies for the new packages and add these to the build configuration. More information about recipes can be found here: http://git.openembedded.org/ https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe

Before cross-compiling applications for your target, you need to install the Software Development Kit (SDK) - which contains the cross-compilation toolchain - and set up the cross-compilation environment on your host. The toolchain for each supported target contains a 64-bit library for gcc. The toolchain and the environment-setup script are wrapped together inside a toolchain installer in the form of a shell script. The cross-compilation toolchain is packaged as follows: The <target> toolchain contains the lib64 (64-bit) library. The <target> installer has an environment-setup script which will select the lib64 to be used by gcc. This way, a 64-bit application can be cross-compiled. Do as in the example below to install the SDK and set up the cross-compilation environment: The fastest alternative is to use a precompiled cross-compilation toolchain installer for your host and target. Please refer to the Release Information document, in section 1.1 Provided Contents, for more details on where to find the pre-compiled SDK installer. Run the installer to unpack the cross-compilation toolchain and the environment-setup script: $ chmod 770 enea-*-toolchain-<version>.sh $ ./enea-*-toolchain-<version>.sh When prompted, select to install the SDK in the desired directory, referred to as <sdkdir>. The default path where the SDK will be installed, will be shown in the prompt. The installer unpacks the environment setup script in <sdkdir> and the toolchain under <sdkdir>/sysroots. Choose a unique directory for each toolchain. Installing a second toolchain of any type (buildtools toolchain or cross-compilation toolchain) in the same directory as a previously installed one will break the $PATH variable of the first one. Setup the toolchain environment for your target by sourcing the environment-setup script: $ . <sdkdir>/environment-setup-<arch>-enea-linux Example: $ . /opt/enea/environment-setup-corei7-64-enea-linux Once the cross-compilation toolchain is in place and the environment set up, you can proceed with Cross-Compiling Applications from Command Line (4.1) or, if Eclipse is installed, Cross-Compiling from Eclipse (5.4.1).

Build an Enea Linux image from the SDK to run on QEMU x86: $ cd <sdkdir>/workspace $ devtool build-image enea-image-standard $ devtool runqemu kvm enea-image-standard nographic slirp

A Package Management System (PMS) can be used to customize your image in a consistent way, e.g. to install, upgrade, or delete packages considering the dependencies. The package management systems supported by Enea Linux are described in this section. More information about PMS can be found in the Yocto 2.5 document Yocto Project Mega Manual. If needed replace the Yocto version in the link.

Enea Linux provides DEB packages on linux.enea.com site, in directory <release>/<target>/deb/. The application for performing runtime package management of DEB packages on the target is called apt-get. Use the apt-get command to install, upgrade, or remove packages. Before using any apt-get options that require network access, please check that the network is configured and working properly. The apt-get command is by default included in Enea Linux images.

APT relies on the concept of repositories in order to find packages and resolve dependencies. Any number of additional repositories can be added to APT's configuration files (.list extension) located in sources.list.d directory (e.g: /etc/apt/sources.list.d/repos.list) and then be queried by APT. # touch /etc/apt/sources.list.d/repos.list # echo "deb [trusted=yes] http://server-address/path/to/the/package/directory ./" | \ tee -a /etc/apt/sources.list.d/repos.list Run apt-get update to fetch information from the new repository: # apt-get update

DEB packages typically have file names like foo-1.0.1-r0.0_arm64.deb The file name includes the package name (foo), version (1.0.1), revison (r0.0), and architecture (arm64). To install a package, log in as root and type the following command at a shell prompt: # apt-get install foo The apt-get install command will install one or more packages in the system.

The apt-get upgrade command will upgrade one or more packages which are currently installed in the system. If no packages are given, all installed packages will be checked. # apt-get upgrade foo

The apt-get remove command will remove one or more packages which are currently installed in the system. Example: # apt-get remove ptest-runner Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: libc6-dbg libc6-dev libc6-extra-nss libc6-thread-db libcidn1 linux-libc-headers-dev Use 'apt autoremove' to remove them. The following packages will be REMOVED: ptest-runner 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] y (Reading database ... 5766 files and directories currently installed.) Removing ptest-runner (2.0.2+git0+6d2872116c-r0.0) ...

The apt-cache search allows searching for the given expressions in the name, summary and description of known packages. Example: # apt-cache search ptest-runner ptest-runner - A C program to run all installed ptests ptest-runner-dbg - A C program to run all installed ptests - Debugging files ptest-runner-dev - A C program to run all installed ptests - Development files