Build Linux Using Yocto
Build Linux Using Yocto
Embedded Artists AB
Rundelsgatan 14
SE-211 36 Malmö
Sweden
http://www.EmbeddedArtists.com
Disclaimer
Embedded Artists AB makes no representation or warranties with respect to the contents hereof and
specifically disclaim any implied warranties or merchantability or fitness for any particular purpose.
Information in this publication is subject to change without notice and does not represent a
commitment on the part of Embedded Artists AB.
Feedback
We appreciate any feedback you may have for improvements on this document. Send your comments
by using the contact form: www.embeddedartists.com/contact.
Trademarks
All brand and product names mentioned herein are trademarks, services marks, registered
trademarks, or registered service marks of their respective owners and should be treated as such.
Table of Contents
1 Document Revision History ................................. 6
2 Introduction ........................................................... 8
2.1 Conventions.................................................................................... 8
8 Yocto Images....................................................... 41
8.1 meta-toolchain .............................................................................. 41
9 Customization ..................................................... 42
9.1 Create a layer ................................................................................ 42
9.2 Create a recipe.............................................................................. 43
9.3 Add content or change behavior of existing recipe .................. 45
10 Miscellaneous ................................................... 46
10.1 Root file system on SD card ...................................................... 46
10.2 Build Linux kernel from source code ....................................... 47
10.3 Build u-boot from source code ................................................. 48
10.3.1 Extra steps for iMX8 .................................................................. 49
10.4 Use devtool to build Linux / u-boot........................................... 50
10.5 State and download cache in Yocto ......................................... 51
2 Introduction
This document provides you with step-by-step instructions to setup the Yocto build system, build boot
loaders, Linux kernel and file system for the Embedded Artists i.MX6, i.MX7, and i.MX8 based COM
boards.
Additional documentation you might need is.
• NXP Yocto Project User’s Guide – The document is available in the Linux bundle found at the
software and tools section on NXP’s website.
• The Getting Started document for the board you are using.
• Yocto project overview - https://www.yoctoproject.org/software-overview/
• Yocto Project Quick Start
• Yocto Project Reference Manual
• Yocto Training – Instructions for using Yocto at the NXP community site
• Bitbake Cheat Sheet: https://elinux.org/Bitbake_Cheat_Sheet
2.1 Conventions
A number of conventions have been used throughout to help the reader better understand the content
of the document.
Constant width text – is used for file system paths and command, utility and tool names.
$ mkdir ~/bin
$ curl http://commondatastorage.googleapis.com/git-repo-
downloads/repo > ~/bin/repo
4. Add the directory to the PATH variable. The line below could be added to your .bashrc file so
the path is available in each started shell/terminal
$ export PATH=~/bin:$PATH
1. Create a directory for the downloaded files (ea-bsp in the example below)
$ mkdir ea-bsp
$ cd ea-bsp
2. Configure Git if you haven’t already done so. Change “Your name” to your actual name and
“Your e-mail” to your e-mail address.
3. Initialize repo. The file containing all needed repositories is downloaded in this step. Change
<selected branch> to a branch name according to Table 1.
$ repo sync
All files have now been downloaded into the ea-bsp directory. Most of the files will actually be
available in the sub-directory called sources.
4 Building Images
Yocto is using the BitBake tool to generate complete Linux images/distributions, that is, all needed to
boot and run a Linux system. This is typically boot loader(s), Linux kernel, and root file system with
selected utilities and applications.
4.1 Available Images
The recipes that have been downloaded contain many different images. The table below describe only
a few of the images that are available.
Image name Description
Only available on branch ea-4.14.78 and later. Based on
core-image-base and added packages for peripheral testing
ea-image-base and verification. This is Embedded Artists default image and
the one included in the pre-build packages on
imx.embeddedartsits.com.
core-image-minimal A small image allowing a device to boot
core-image-base A console only image that fully supports the target device
Build an image with GUI support, but without Qt content.
fsl-image-gui Works with X11, DirectFB, frame buffer and Wayland
backends.
Build a Qt5 image. Works with X11, Frame buffer, and
fsl-image-qt5
Wayland backends.
Build u-boot, kernel and file system that can be used by
fsl-image-mfgtool-initramfs
NXP’s Manufacturing tool.
meta-toolchain Builds an installable toolchain (cross-complier)
Builds toolchain/SDK for Qt5. Can be used when developing
meta-toolchain-qt5
Qt5 applications.
Usually, the name of the file that defines an image contains the string “image”. You can search for
such files using the find command. Please note that not all images follow this naming convention.
The toolchain images are images that doesn’t contain “image” in the name.
$ cd ~/ea-bsp/sources
$ find -name *image*.bb
environment script. If you don’t run the setup-environment script you won’t have access
to needed tools and utilities, such as bitbake.
$ bitbake ea-image-base
When the build has finished the images will be available in the directory specified below. Please note
that this directory will be different if you are using another build directory or machine configuration.
~/ea-bsp/build_dir/tmp/deploy/images/imx6sxea-com.
Go to chapter 5 for instructions of how to deploy images to the target hardware.
4.5 Bitbake Options
This section contains a few examples of how to use bitbake. This is by no means a complete list of all
available bitbake options, but instead a list of examples that you might find useful.
4.5.1 Clean Build for a Specific Image/Recipe
The “-c” option executes a specific task for an image or recipe. In the example below a previous build
of the u-boot boot loader is cleaned.
To build u-boot after it has been cleaned just specify the image name u-boot-ea.
$ bitbake u-boot-ea
$ bitbake-layers show-appends
5 Deploying Images
NXP's Manufacturing Tool currently exists in two versions. MFGTool is the old version and UUU is the
new version.
MFGTool UUU
MFGTool version V2 V3
Actively developed No Yes
OS Support Windows only Windows + Linux
Source Code Available No Yes, GitHub
As of May 2019, Embedded Artists plan to keep MFGTool support for old kernel releases (i.e. prior to
Linux 4.14.78). For Linux 4.14.78 there will be a transition time where both MFGTool and UUU zip files
will be available but at some point, only the UUU zip file will be updated. For all releases after Linux
4.14.78, only UUU will be supported.
1 2 3 4 5 6 7 8
1. Set the boot jumpers in OTG boot mode as shown in Figure 4. First jumper in the up position
and the second jumper in down position. Please note that the orientation of the DIP switch
component can be different on different COM boards. Make sure you are changing the correct
jumper by looking at the number by the jumper.
2. Make sure a USB cable is connected between the board (micro-B connector on carrier board)
and your PC
3. Reset the board
Note: When you want to boot the software from eMMC you have to reverse the setting, that
is, first jumper in down position and second jumper in up position.
5.1.5 Configurations
Several configurations of the tool have been prepared in order to help you download specific images.
Shortcuts to these configurations are available as vbs files in the root of the MFGTool directory. All you
need to do is to double-click on one of these files and the manufacturing tool will start.
- ea-com-emmc_bootloaders.vbs – will install only the bootloaders. This should
only be used if you want to restore the bootloaders or download your own bootloaders to the
board.
- ea-com-emmc_kernel.vbs – will install kernel and dtb files. This should only be
used if you want to update the kernel or dtb file.
- ea-com-emmc_full_tar.vbs – will install bootloaders, Linux kernel and root file
system. The root file system will be installed from a tar.bz2 file.
- ea-com-emmc_update_rootfs.vbs – will only download the root file system (the
ext3 file) to the board.
Click the Start button to start the download of files. If all operations are successful the progress bars
will turn green, see Figure 6. Click the Stop button and then Exit to close the manufacturing tool. If an
operation fails the progress bars will turn red. In this case it can be helpful to have a look at the log
MfgTool.log which is found in the same directory as the manufacturing tool.
5.2 UUU
UUU (Universal Update Utility) is version 3 of MFGTool but it has been rewritten, is publicly available
on GitHub (https://github.com/NXPmicro/mfgtools) and it can be run on both Windows and Linux while
the older versions of MFGTool were limited to Windows only.
UUU can be used to write images to the board. This tool is sending files and instructions over USB and
the board must be set in OTG boot mode for it to work.
Starting with Linux 4.14.78, a uuu-zip file will be made available in addition to the mfgtool zip files on
http://imx.embeddedartists.com/ for the board you are using. Note that iMX8M Quad COM, iMX8M Mini
uCOM, iMX8M Nano, and iMX7ULP uCOM boards will not have an mfgtool zip file.
Prerequisites:
• Ubuntu 16.04 or above, 64-bit
• Windows 10, 64-bit
• Windows 7, 64-bit - note that there might be problems with drivers and that it might not even
work with the driver fixes applied even if the documentation says it does. The Windows 7
specific instructions can be found here: https://github.com/NXPmicro/mfgtools/wiki/WIN7-
User-Guide
Useful links:
• UUU on GitHub: https://github.com/NXPmicro/mfgtools
• UUU release page: https://github.com/NXPmicro/mfgtools/releases
5.2.1 Download the Tool
Download the zip file for the board you are using from http://imx.embeddedartists.com/
Unpack this zip file somewhere on your computer. Below is a description of some of the content in the
zip file.
- uuu (root): Contains a README file.
- uuu/*.uuu: The different download configurations.
- uuu/files/: Contains pre-compiled versions of images. The tool will look in this directory
when selecting images to download to the board.
5.2.2 Prepare hardware
The instructions here are identical to the ones for MFGTool available in 5.1.2
5.2.5 Configurations
Several configurations (*.uuu files) for the tool have been prepared in order to help you download
specific images.
- bootloader.uuu – will install only the bootloaders. This should only be used if you want
to restore the bootloaders or download your own bootloaders to the board.
$ cd ~/uuu_imx8mq_com_4.14.78
$ chmod +x ./uuu
$ sudo ./uuu full_tar.uuu
The terminal will show a progress bar like this while it is running:
If a problem occurs then the program will terminate and print an error message like this
C:\> cd c:\temp\uuu_imx8mq_com_4.14.78
C:\temp\uuu_imx8mq_com_4.14.78> uuu.exe full_tar.uuu
The terminal will show a progress bar like this while it is running:
If a problem occurs then the program will terminate and print an error message like this
5.2.9 Troubleshoot
Some common problems and solutions:
• The first time you run uuu on your computer it fails.
This is likely because of USB driver installation. Let the driver install, reset the hardware and
then run the uuu command again. In Windows it is three different drivers that are needed so
this procedure might have to be repeated three times - each time the procedure gets a little bit
further.
• UUU appears to hang with a "Wait for Known USB Device Appear..." message like this:
This means that the hardware is either not connected to the computer with the USB cable or it
is not in the OTG boot mode. Check 5.1.2 to 5.1.4 again and then run the uuu command
again.
• Windows 7 fail to flash with an error like this:
This happens if the uuu program is not executed with the correct rights. Either use "sudo uuu"
or setup udev rules so that sudo rights are not needed. The instructions for how to create the
udev rules are built into the tool so run "uuu -udev" and then follow the steps:
2. Find attached storage devices. In the example below only one device is attached and will
therefore get device index zero (‘0’). You need to know this index when accessing the device
in later steps.
3. List the content on the USB device to see that your files are available on the device. The zero
in the instructions below is the device index.
Important: Files are loaded into RAM memory which means that they must be smaller than
the memory on the board.
1. Load the ext3 image into memory. In the example below USB device 0 is accessed and the
file rootfs.ext3 is loaded to address 0x83000000. The size of the loaded file is
79691776 bytes. This information is important and needed in step 3. The size may be
different in your case.
2. Find the offset to the file system partition. If you are using the default setup from Embedded
Artists the root file system will be in partition 2 which as shown in the example below is
available at offset 24576 (0x6000). Partition 1 contains the Linux kernel and device tree (dtb)
files.
3. Write the file to eMMC. The eMMC memory is available on mmc device 1 and as found in the
previous step partition 2 starts at offset 0x6000. The amount of data to write to the mmc
device must be given in number of blocks where each block is 512 bytes. The value must be
written as a hexadecimal value. 79691776 / 512 = 155648 ➔ 0x26000.
4. A new root file system has now been written to the device and the board can be rebooted.
5.4 From within Linux
It is also possible to do updates to the system from within Linux.
5.4.1 Kernel image and dtb files
Kernel images and dtb (device tree) files are available on a partition of eMMC that is normally not
mounted. The instructions below show how to update the kernel image and dtb file (or add new dtb
files) from a USB memory stick to the eMMC partition.
1. Copy the files to a USB memory stick
2. Boot into Linux and then insert this into the USB Host Connector on the Carrier Board, see
Figure 7. You will see output in the console as below.
3. Mount the USB memory stick and eMMC partition. The USB memory stick has in this
example the device name sda1 as can be seen in the output in step 2 above. The partition
on the eMMC is in this example available at /dev/mmcblk2p1, but this could be different on
different COM boards.
# mkdir /mnt/usb
# mount /dev/sda1 /mnt/usb
# mkdir /mnt/mmcboot
# mount /dev/mmcblk2p1 /mnt/mmcboot
4. Copy the bin file and / or dtb file from the USB memory stick to the boot partition.
# cp /mnt/usb/zImage /mnt/mmcboot
# cp /mnt/usb/imx6sxea-com-kit.dtb /mnt/mmcboot
5. Un-mount devices
# umount /mnt/usb
# umount /mnt/mmcboot
In the example below e2fsprogs (file system utilities) and parted (manipulates partition tables)
has been added to the variable. Please note that IMAGE_INSTALL_append must start with a
space character as in the example below.
NOTE. These instructions have been tested with Lubuntu 14.04 and 16.04, but they should
work on newer versions.
The default disc capacity is 20GB which is much too low. It is recommended to have at least 120GB to
be able to build. If you plan to build Android then at least 200GB is needed.
The virtual machine requires at least 3GB of memory but more is better if the host machine (the
machine running the VMware Player application) can spare it.
If the host machine has a processor with multiple cores then it is possible to assign more than one of
those to the virtual machine which will decrease build times.
The new virtual machine is now ready to be started. Press the Play button to boot the machine for the
first time.
Select to install Lubuntu and then follow the on-screen configuration guide.
The first important page is the installation type page where it is a good idea to click the “Use LVM”
option as it will make it easier to expand the disc space in the future. It is
optional.
The installation will complete and at the end a restart is required. When rebooting there will be a
message stating to remove the installation media:
To remove the media, right click on the CD icon at the top right of the window and select Settings.
Make sure that the “Connect at power on” option is not selected. This is the same as ejecting a CD.
After removing the CD and the booting has completed the virtual machine should boot into the
desktop (possibly asking for login information depending on the options selected during installation).
Figure 22 – Desktop
It is recommended to run the Software Updater to get all the fixes that have been made. Click the icon
on the bottom of the screen and follow the instructions.
The last thing to do is to install VMware Tools. This is optional but it adds a couple of useful features
including
• Move the mouse pointer out of the VMware Player window without having to press Ctrl+Alt
• Copy text between the virtual machine and the host machine
Start the LXTerminal and run the following commands in the terminal window that appear:
$ cd /tmp/
$ tar -xf /media/user/VMware\ Tools/VMwareTools*.tar.gz
$ cd vmware-tools-distrib
$ sudo ./wmware-install.pl
Note that the path above assumes that the login name that you have is “user”. Replace that part with
the name used to login to the virtual machine.
The wmware-intall.pl script will ask a lot of questions but always select the default answer (shown as
e.g. [yes]) unless you are sure you know what you are doing.
After the last question is answered the VMware tools will be installed. Reboot when the installation
program completes.
8 Yocto Images
8.1 meta-toolchain
To be able to build your own application or, for example, u-boot and the Linux kernel outside of Yocto
you need a toolchain. The toolchain consists of cross-compiler, linker, and necessary libraries. As
mentioned in section 4.1 there is an image named meta-toolchain that will create the necessary
toolchain.
1. Build the image
$ bitbake meta-toolchain
2. The build will result in a file located at <build dir>/tmp/deploy/sdk. The exact
name of the file depends on several factors, but in our example, it is called:
fsl-imx-fb-glibc-x86_64-meta-toolchain-cortexa9hf-neon-
toolchain-4.14.78-sumo.sh
3. Install the toolchain
$ cd <build dir>/tmp/deploy/sdk
$ sudo ./fsl-imx-fb-glibc-x86_64-meta-toolchain-cortexa9hf-neon-
toolchain-4.14.78-sumo.sh
4. If you select the default settings the toolchain will in this example be installed in /opt/fsl-
imx-fb/4.14-sumo/
5. Before building an application run the command below to setup environment variables
$ source /opt/fsl-imx-fb/4.14-sumo/environment-setup-cortexa9hf-
neon-poky-linux-gnueabi
6. If you are compiling for an iMX8 target then run the following command to avoid linker error(s)
$ unset LDFLAGS
7. You can verify that the environment variables has been correctly setup by running the
command below that will show the version of the GCC compiler used.
$ $CC –-version
arm-poky-linux-gnueabi-gcc (GCC) 7.3.0
...
NOTE 1: Setting up environment variables in step 5 may overwrite other variables you
already have in your environment. It is, for example, not recommended to do this in the same
terminal where you run bitbake to build Yocto images.
9 Customization
9.1 Create a layer
In Yocto a layer can be seen as a collection of related recipes (instructions) that tell the build system
what to do. As an example, Embedded Artists created the layer meta-ea to contain all recipes
needed to build an image for one of our COM boards.
For these instructions you should first have built an image as described in chapter 4 We are using the
name meta-example in these examples. Change this to the name you want to use for your layer.
Create the layer
The instruction is run from the build directory and the layer will be created in the sources directory.
The meta-example layer will be created with a number of files including an example recipe. The
directory structure will look like below.
meta-example
| -- conf
| | -- layer.conf
| -- COPYING.MIT
| -- README
| -- recipes-example
| | -- example
| | | -- example_0.1.bb
The disadvantage of running bitbake-layers is that it will add the layer with an absolute path and
not a relative path as the other layers in bblayers.conf. Below is an example of
bblayers.conf were meta-example has been added using bitbake-layers.
...
BBLAYERS += " ${BSPDIR}/sources/m eta-qt5 "
#Embedded A rtists Yocto layer
BBLAYERS += " ${BSPDIR}/sources/m eta-ea "
BBLAYERS += " ${BSPDIR}/sources/m eta-murata-wireless "
BBLAYERS += "/home/user/builds/bu ild-dir/sources/meta-e xample"
Version control
It is recommended that you add your new layer to a version-controlled repository such as GitHub. It is
out of the scope of this document to describe how you do this, but there are many guides online such
as the link below that describes how to create a new repository on GitHub.
https://help.github.com/en/github/getting-started-with-github/create-a-repo
By adding the layer to a repository, you can also add it to a repo manifest that will keep track of all
repositories needed to do a full Yocto image. Embedded Artists has created the repository ea-
yocto-base that contains a repo manifest. See an example by following the link below.
https://github.com/embeddedartists/ea-yocto-base/blob/ea-4.14.98/default.xml#L34
9.2 Create a recipe
It is the recipe that contains the settings and tasks needed to build a package. The recipe contains the
information about where the source code can be found, which version to use and if any patches should
be applied. It can also specify dependencies to other recipes.
When a new layer was created in section 9.1 an example recipe was also created. This example only
contains one .bb file which will print a message during the build.
example_0.1.bb
A better example is to create a recipe that will build and install a hello world application. The
instructions below are based on the example described in Yocto’s official documentation.
https://www.yoctoproject.org/docs/2.5.3/mega-manual/mega-manual.html#new-recipe-single-c-file-
package-hello-world
Create recipe directory
Within the meta-example layer create the directories needed for the new recipe. The first directory,
recipes-example, is a container directory where you can put several recipes (using the same
directory as was created when creating the layer). The directory hello-world is the actual recipe
directory for this example. The sub-directory files will contain the source code, helloworld.c in
this example.
$ cd ../sources/meta-example
$ mkdir -p recipes-example/hello-world/files
S = "${WORK DIR}"
do_compile( ) {
${CC} hel loworld.c -o helloworl d
}
do_install( ) {
install - d ${D}${bindir}
install - m 0755 helloworld ${D} ${bindir}
}
The recipe file begins with short description of the recipe and also specifies which license that will
apply.
The file continues with specifying the path to the source code (SRC_URI). It only lists the name of the
file, but Yocto will know to look for this file in the sub-directory files.
Then comes the compile and install steps. In do_compile the file will be compiled into an
executable program and in do_install the program will be installed into the file system at the
location defined by ${bindir} (typically /usr/bin).
The last line (INSANE_SKIP_${PN}) was added to skip ldflags. Without this line, QA errors were
generated (like below).
ERROR: hello-world-1.0-r0 do_package_qa: QA Issue: No GNU_HASH in
the elf binary:
Create helloworld.c
Within hello-world/files create the file helloworld.c and add the content below to that file.
int main() {
printf(" Hello world\n");
return 0 ;
}
$ cd ../../<build-dir>
$ bitbake hello-world
To make sure the hello world application is included in the image you are building add the following to
conf/local.conf.
Then build the image (in this example we are using ea-image-base, but you can change to the
image you are using).
$ bitbake ea-image-base
# Change the default configuration from 44100Hz to 48000Hz for iMX6 UltraLite
do_install_append_mx6ul () {
if [ -e ${D}/${sysconfdir}/asound.conf ]; then
sed -e "s:playback\.pcm.*:playback.pcm \"dmix_48000\":g" \
-e "s:capture\.pcm.*:capture.pcm \"dsnoop_48000\":g" \
-i ${D}/${sysconfdir}/asound.conf
fi
}
What this file do is to append to the do_install task. When this task is run it will look for the
asound.conf file and modify it to use 48000 Hz instead of 44100 Hz using the sed command.
Please note that this change will only be applied for the mx6ul target (i.e., iMX6 UltraLite). The
reason to limit the change to the iMX6 UltraLite is because for this target it wasn’t possible to generate
a 44100 Hz clock given the way the audio related clocks are setup for the processor.
The original file can be found on GitHub.
https://github.com/embeddedartists/meta-ea/blob/ea-4.14.98/recipes-bsp/alsa-state/alsa-
state.bbappend
More information in the Yocto documentation:
https://www.yoctoproject.org/docs/2.5.3/mega-manual/mega-manual.html#using-bbappend-files
10 Miscellaneous
10.1 Root file system on SD card
By default, u-boot, kernel, and root file system are stored on the onboard eMMC flash. The instructions
in this section show how to put the root file system on an external SD card. The u-boot, kernel and dtb
files are still stored on the eMMC.
Detect which device file the SD card is available on
1. Boot into Linux without having an SD card inserted in the SD card slot
2. Insert the SD card and you will see output similar to below in the terminal. In this example the
device file to use will be /dev/mmcblk1p1.
4. Now you can run uuu with full.tar to update the target. See chapter 5 for more information
about deploying images.
NOTE: In this section we are modifying an existing configuration file. An alternative is to copy
the configuration file and renaming it instead of modifying it.
# setenv mmcautodetect no
# saveenv
5. When you reset/boot the board it will use the root file system stored on the SD card.
10.2 Build Linux kernel from source code
You can build the Linux kernel outside of Yocto by following the instructions in this section. Please note
that it is recommended that the kernel is built by Yocto when you are generating your final distribution
images since there can be dependencies between the root file system and the kernel.
The instructions in this section assume that you have built and installed the toolchain as described in
section 8.1 above.
Setup the environment variables for the toolchain. We are using the same installation path as
described in section 8.1 above. If you have installed the toolchain in a different path use that path in
the instructions below.
$ source /opt/fsl-imx-fb/4.14-sumo/environment-setup-cortexa9hf-
neon-poky-linux-gnueabi
If you are compiling Linux for an iMX8 based board then run the following command to avoid linker
error(s):
$ unset LDFLAGS
Get the source code from the Embedded Artists GitHub repository. In this example we are checking
out branch ea_4.14.78.
Use Embedded Artists kernel configurations (use ea_imx8_defconfig instead if compiling for
an iMX8M target).
$ make ea_imx_defconfig
(Optional) If you want to change kernel configurations you can at this point run the menuconfig tool.
$ make menuconfig
$ make
When the build process has finished the kernel will be available here: arch/arm/boot/zImage.
Device tree files are available in the following directory: arch/arm/boot/dts. A compiled device
tree file has the file extension dtb.
Updating the system
You have several options to update the system with the new kernel. The first option is to use the
manufacturing tool as described in section 5.1 above. The other option is to update the boot partition
from within Linux as described in section 5.4.1 .
10.3 Build u-boot from source code
You can build u-boot outside of Yocto by following the instructions in this section.
The instructions in this section assume that you have built and installed the toolchain as described in
section 8.1 above.
Setup the environment variables for the toolchain. We are using the same installation path as
described in section 8.1 above. If you have installed the toolchain in a different path use that path in
the instructions below.
$ source /opt/fsl-imx-fb/4.14-sumo/environment-setup-cortexa9hf-
neon-poky-linux-gnueabi
If you are compiling the u-boot for an iMX8 based board then run the following command to avoid
linker error(s):
$ unset LDFLAGS
Get the source code from the Embedded Artists GitHub repository. In this example we are checking
out branch ea_v2018.03.
Use the Embedded Artists configuration for the COM board you are using. In the example below the
configuration for the iMX6 SoloX COM board is used.
$ make mx6sxea-com_config
$ make
When the build process has finished the u-boot image will be available directly in the uboot-imx
directory.
Updating the system
Use the manufacturing tool as described in section 5.1 to update the system with the new u-boot
image.
Note: Instead of running these commands manually you can use devtool as described in
section 10.4
For the iMX8 it is not enough to compile the u-boot - it must also be packaged together with these
components to get something that can be flashed:
• U-boot (including SPL)
• ARM Trusted Firmware
• DDR Firmware
• HDMI Firmware
This is normally handled in yocto automatically but if you want to do it outside of yocto these are the
steps:
1. Build the u-boot as explained above. These steps will assume that the folder
~/work/uboot-imx/ was used - otherwise change accordingly below
2. Download and build the ARM Trusted Firmware
$ cd ~/work/
$ git clone https://source.codeaurora.org/external/imx/imx-atf
$ cd imx-atf
$ git checkout imx_4.14.78_1.0.0_ga
$ source /opt/fsl-imx-wayland/4.14-sumo/environment-setup-aarch64-
poky-linux
$ unset LDFLAGS
3. Download and extract the DDR/HDMI Firmware and answer yes to the end user license
agreement
$ cd ~/work/
$ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-
8.0.bin
$ chmod +x firmware-imx-8.0.bin
$ ./firmware-imx-8.0.bin
$ cd ~/work/
$ git clone https://source.codeaurora.org/external/imx/imx-mkimage
$ cd imx-mkimage
$ git checkout imx_4.14.78_1.0.0_ga
$ cp ../firmware-imx-8.0/firmware/ddr/synopsys/lpddr4_pmu_* iMX8M/
$ cp ../firmware-imx-8.0/firmware/hdmi/cadence/signed_* iMX8M/
$ cp ../uboot-imx/u-boot.bin iMX8M/
$ cp ../uboot-imx/u-boot-nodtb.bin iMX8M/
$ cp ../uboot-imx/spl/u-boot-spl.bin iMX8M/
$ cp ../uboot-imx/tools/mkimage iMX8M/mkimage_uboot
$ cp ../imx-atf/build/imx8mm/release/bl31.bin iMX8M/
$ cp ../uboot-imx/arch/arm/dts/fsl-imx8mm-ea-ucom-kit_v2.dtb
iMX8M/fsl-imx8mm-evk.dtb
$ cp ../imx-atf/build/imx8mq/release/bl31.bin iMX8M/
$ cp ../uboot-imx/arch/arm/dts/fsl-imx8mq-ea-com-kit_v2.dtb
iMX8M/fsl-imx8mq-evk.dtb
7. Build to get iMX8M/flash.bin and then rename it to match the file name used in UUU.
8. Use the UUU tool as described in section 5.2 to update the system with the bootloader
10.4 Use devtool to build Linux / u-boot
Section 10.2 and section 10.3 describe how to build Linux and u-boot from source code outside of
Yocto. This is in general a fast way to work with Linux / u-boot development compared to re-building
inside of Yocto. There is however another alternative that will let you build within Yocto, but with your
own Linux / u-boot repositories. This can be suitable when you for example want to test modifications,
but make sure to keep the kernel in sync with the root file system. For u-boot and especially u-boot for
iMX8 the benefits of using devtool is that you don’t have to manually re-create the boot image as
described in section 10.3.1 .
Run the commands below within your Yocto build directory.
For Linux kernel:
For u-boot:
Once you have modified the repository you can build a new Yocto image, for example, ea-image-base.
$ bitbake ea-image-base
If you want to switch back to using the default repositories you can use devtool reset as shown
below.
SSTATE_DIR = "/opt/yocto-cache/shared-sstate-cache"
DL_DIR = "/opt/yocto-cache/downloads"
SSTATE_MIRRORS = " file://.* file:///opt/yocto-cache/shared-sstate-
cachePATH "
Here we can see that the recipe is called alsa-state. You can now search in the sources
directory for this recipe.
If you would like to modify this file you could then create a bbappend file an put that in your own layer
as described in section 9.3 .
11.5 How do I add my own files to the file system?
If you want to install your own files to the file system you could either add your own recipe that installs
the files (see section 9.2 for a description of how to add a recipe) or you can use the Embedded Artists
recipe called ea-files.
Below you can see an example where we use ea-files to add two files to the file system. The first
part (EA_FILES_DIRS) lists the directories where the files need to be installed. The second part
installs the file crank_8mm_mn.tar.gz to /home/root and crank_8mm_mn.sh to
/etc/profile.d.
These files will be given the permissions 644 (read for all, write only for user).
EA_FILES_DI RS = "\
/home/root \
/etc/profi le.d \
"
EA_FILES_64 4 = "\
crank_8mm_ mn.tar.gz:/home/root/c rank_8mm_mn.tar.gz \
crank_8mm_ mn.sh:/etc/profile.d/c rank_8mm_mn.sh \
"
ea-yocto-base
NXP packages
meta-ea
linux-imx (linux-ea)
uboot-imx (u-boot-ea)
11.7.1 meta-ea
Section 3.4 describes how to download the repositories included in the Yocto build. In that section you
can see that a tool called repo is used together with a link to a repository called ea-yocto-base.
This repository contains a manifest (default.xml) that tells repo which repositories to download,
where they are located, and exactly which revision to use. Follow the link below to see how the
manifest looks like for the ea-4.14.98 distribution.
https://github.com/embeddedartists/ea-yocto-base/blob/ea-4.14.98/default.xml
Below is an excerpt from the manifest file. Here you can see that the Embedded Artists repositories
are located on GitGub and you can also see which revision of the layer meta-ea that will be
downloaded.
...
<remote fet ch="git://github.com/e mbeddedartists" name=" EA"/>
...
...
SRC_URI = "git://github.com/embeddedartists/linux-
imx.git;protocol=git;branch=${SRCBRANCH}"
...
LOCALVERSION = "-2.2.0"
SRCBRANCH = "ea_4.14.98"
SRCREV = "b095f5fb8a8de39e77f578dcd351783fdcdf1984"
...
SRCBRANCH = "ea_v2018.03"
SRC_URI = " git://github.com/embed dedartists/uboot-
imx.git;bra nch=${SRCBRANCH} \
"
SRCREV = "f 70b292988ec7bcee7f4b41 2e62cdd9cd05e6dba"
...