Building Embedded Linux images for VEST Development Platforms using Yocto

Building Embedded Linux images for VEST Development Platforms using Yocto VEST-VKGEN-QSG-001 Provides basic build instructions on how to get started with building Yocto images for VEST development platforms www.apc-vest.com Copyright 2016 Advanced Products Corporation Pte Ltd. All rights reserved. No part of this document may be photocopied, reproduced, or translated to another language without the prior written permission of Advanced Products Corporation Pte Ltd. When printed or downloaded from APC managed server/web site this document is considered uncontrolled. Page 1 APC Proprietary Information June 9, 2017

TABLE OF CONTENTS 1. Overview...6 1.1 List Of Acronyms/Terms... 6 1.2 Reference Documents... 7 2. Preparing your computer...8 2.1 Install Ubuntu... 8 2.1.1 Preparing the partition or Virtual disk image... 8 2.1.2 Shared folders and other considerations... 8 2.1.3 Installing Ubuntu... 8 2.2 Adding specific software to Ubuntu... 8 2.3 Setting up Bitbucket... 9 2.3.1 Private repositories and enabling SSH access to Bitbucket... 9 3. Downloading Freescale Community BSP Platform... 12 3.1 Installing repo utility... 12 3.2 Downloading Layers used in Yocto... 12 3.2.1 Building a different version of Yocto... 13 4. Meta-layers for VEST Development platforms... 14 4.1 Downloading VEST support layers for Yocto... 14 4.2 Always a Work In Progress... 14 5. Building Embedded Linux Images... 15 5.1 Setup a build directory/environment... 15 5.2 Make modifications to the build environment... 15 5.3 Selecting an image to build... 17 5.4 Building the first Yocto image for VEST development platform... 18 5.4.1 Fetch the sources before starting the compilation process... 18 5.5 Building MFGTool runtime images... 18 5.6 Updating VEST layers and rebuilding the image... 19 6. Deploying embedded Linux Images... 20 6.1 Yocto generated files used in deployment... 20 6.2 Flashing to on-board flash memory or SD Card... 21 6.2.1 Copying files for MFGTool... 22 6.2.2 emmc/sd Card Layout... 23 6.2.3 Programming the emmc with new images... 24 6.3 Powering up the board with the new image... 26 7. Developing & Deploying Your Own Applications... 29 7.1 Customising the Kernel and U-Boot for your custom board/application... 29 7.1.1 U-Boot... 29 7.1.2 Modifying the logo being displayed at start-up... 29 7.1.3 Modifying the logo being displayed when Linux starts... 30 7.2 Generating the compiler to build applications outside Yocto... 30 7.2.1 Including more user-space libraries and header files... 31 8. Revision History... 33 Page 2 APC Proprietary Information June 9, 2017

9. Legal Notices... 34 Page 3 APC Proprietary Information June 9, 2017

LIST OF TABLES Table 1-1: List of Acronyms/Terms... 7 Table 1-2: List of Reference documents... 7 Table 2-1: VEST Git repository names & URLs... 9 Table 6-1: Essential output files from Yocto build... 20 Table 6-2: Files to be updated in MFGTool package... 23 Table 6-3: emmc layout map... 24 Table 6-4: Serial debug console settings... 24 Page 4 APC Proprietary Information June 9, 2017

LIST OF FIGURES/DIAGRAMS Figure 2-1: Command to install required software on top of Ubuntu 14.04 LTS... 8 Figure 2-2: Installing meld utility... 9 Figure 2-3: Common dependencies... 9 Figure 2-4: SSH access to Bitbucket... 11 Figure 3-1: Installing repo utility... 12 Figure 3-2: Downloading Yocto layers... 12 Figure 4-1: Download VEST meta layers... 14 Figure 5-1: Setting up the environment... 15 Figure 5-2: Steps to copy the sample bblayers.conf and local.conf files to build directory... 16 Figure 5-3: Contents of bblayers.conf.sample... 16 Figure 5-4: Contents of local.conf.sample... 17 Figure 5-5: Listing all buildable images... 17 Figure 5-6: Build the image... 18 Figure 5-7: Fetch all source files needed... 18 Figure 5-8: Building MFGTool firmware... 19 Figure 5-9: Updating layers and building image... 19 Figure 6-1: MFGTool package directory structure... 21 Figure 6-2: Files (mfgtool agent) under ' Profiles/Linux_VS5100/firmware/vest-vk5100'... 22 Figure 6-3: Files under 'files/logos' & files/vest-vk5100 folders which are flashed into emmc/sd Card... 22 Figure 6-4: emmc partition layout data... 23 Figure 6-5: MFGTool initial window... 25 Figure 6-6: MFGTool reporting success... 25 Figure 6-7: Example of serial debug console log when MFGTool starts executing... 26 Figure 6-8: SPL & U-Boot flow... 28 Figure 7-1: Settings used to create compatible logo image for U-Boot... 30 Figure 7-2: Building cross-compiler for external application development... 31 Figure 7-3: Building SDK with toolchain, user-space libraries and header files for application development 31 Page 5 APC Proprietary Information June 9, 2017

1. OVERVIEW This document describes how a user can build Yocto images for VEST development platforms. VEST development platforms usually come with SOM powered by an NXP/Freescale i.mx 6 SoC Carrier board that the SOM plugs into LCD Display with Touch interface Other add-on cards, modules and accessories If the reader already has a compatible development environment including a Bitbucket account, the reader may want to skip a few chapters of this document and read from Section 3 Downloading Freescale Community BSP Platform onwards. If the reader is only interested in flashing images that he/she might have for a particular development platform, please read Section 6.2 Flashing to on-board flash memory. 1.1 LIST OF ACRONYMS/TERMS Acronym/Term VEST APC SOM Carrier Board Yocto Freescale Community BSP LTS SSH Git Virtual Machine Machine (In Context of Yocto) Meta Layers (In Context of Yocto) Images (Context of Yocto) rootfs RAM Disk Meaning Venture Embedded Solutions Technology Advanced Products Corporation Private Limited System On Module Application specific board or the development board into which the SOM is inserted or plugged The Yocto Project (https://www.yoctoproject.org/) Project that involves Freescale/NXP and its community of third-party developers that port Linux kernels that may be partly or fully based on NXP s official release into an OpenEmbedded build system such that it is compatible with the Yocto Project. Long Term Support Secure Shell Distributed version control system used in Software development A Virtual instance of a PC Desktop running an operating system (in this case, Linux) for development A machine in Yocto is a complete description of a build configuration of specific packages and their versions that are required to add support for any particular board that is supported by a solution like VEST OpenEmbedded allows solutions like VEST to support one or more machines and further specify various recipes that are available for building for one of the supported machines. Yocto Project allows users to create a custom Linux based distribution. That custom distribution is called an image. Root File System that contains system executables, libraries, configuration scripts, kernel modules and in some cases, the application A virtual disk drive; but resides in volatile RAM Page 6 APC Proprietary Information June 9, 2017

Acronym/Term MFGTool sysroot Meaning NXP Manufacturing Tool that is used to program the emmc that is in the SOM with firmware and other contents Refers to the directory that contains the target library and when used in the context of an SDK, suitable subdirectories under the sysroot will also contain the header files Table 1-1: List of Acronyms/Terms 1.2 REFERENCE DOCUMENTS Control number or title VEST-VK5100-QSG-001 Yocto Project Development Manual 2.0 Manufacturing Tool V2 suite of documents Git Cheat Sheet Description/Source VK5100 Development Platform Quick Start Guide from http://www.apc-vest.com http://www.yoctoproject.org/docs/2.0/dev-manual/devmanual.html Please refer to the Document folder in the MFGTool package that you may request from VEST https://www.atlassian.com/dms/wac/images/landing/git/a tlassian_git_cheatsheet.pdf Table 1-2: List of Reference documents Page 7 APC Proprietary Information June 9, 2017

2. PREPARING YOUR COMPUTER Building an embedded linux distribution using Yocto requires use of a Linux machine to be used as a development host. Sections 2.1 & 2.2 provide information on installing Ubuntu. Section 2.3 provides information about setting up a Bitbucket account to access the files, from VEST, to build Embedded Linux for VEST development platforms. 2.1 INSTALL UBUNTU As of writing this document, the following steps have been known to work with Ubuntu 14.04.3 LTS. While it is believed that the steps described in this document will work with later versions of Ubuntu LTS, we do not guarantee that it would work. 2.1.1 Preparing the partition or Virtual disk image When developing for Yocto, the amount of hard disk space that will be consumed will depend upon the Yocto image being built and the packages included in the image. Whenever possible, allocate the maximum amount of memory that can be allocated to the virtual disk image (if you are using a HyperVisor/Virtual Machine like VirtualBox or VMWare) or partition. Generally, it is recommended that the developer creates at least a 128GB partition/virtual disk although it must be noted that this space is likely to run out very soon as the total space required to build one image can be anywhere from 25GB to 50GB, which includes the sources, object files and the rootfs. The process of creating a partition or a virtual disk is beyond the scope of this document. Please refer to the relevant user-guide of your virtual machine program. 2.1.2 Shared folders and other considerations Virtual machine software like Virtual Box and VMWare provide a facility of sharing the contents of a directory/folder in the host computer with an instance of the virtual machine. Please enable this when creating the virtual machine and setup a directory/folder in your host to copy files from the virtual machine to the host or vice-versa. 2.1.3 Installing Ubuntu Please refer to one of many online tutorials of how to install Ubuntu (in this case, 14.04.3 LTS) in your computer or Virtual machine. After installing Ubuntu, please install the guest additions software from your virtual machine software provider into Ubuntu. This will enable many accelerations and features to make the virtual machine run better on your host PC. Also, this is often required for features like shared folder. 2.2 ADDING SPECIFIC SOFTWARE TO UBUNTU By default, Ubuntu is not setup to develop for VEST development platforms or any i.mx 6 based development platforms. To be able to download and build the Yocto project for VEST developments platforms, please download and install additional software using the command line given below. These commands can be executed under any working directory. sudo will require the root user s password to be entered some time since the last instance that it was last entered. $ sudo apt-get install git-core gnupg flex bison gperf buildessential zip curl zlib1g-dev gcc-multilib g++-multilib libc6- dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32zdev ccache libgl1-mesa-dev libxml2-utils xsltproc unzip u-boottools subversion uuid uuid-dev zlib1g-dev libswitch-perl liblzo2- dev gawk wget diffstat unzip texinfo build-essential chrpath libsdl1.2-dev xterm curl cmake automake libtool xclip Figure 2-1: Command to install required software on top of Ubuntu 14.04 LTS Page 8 APC Proprietary Information June 9, 2017

This will install all of the additional software required for Yocto. However, to assist in development, it is recommended that the following packages are installed as well. meld is useful to make visual comparison of two files or two versions of the same file. $ sudo apt-get install meld Figure 2-2: Installing meld utility Many libraries used in embedded Linux systems require more libraries in the host system to build them. So, it is highly recommended to install additional libraries and programs mentioned in Figure 2-3. $ sudo apt-get install gawk wget diffstat unzip p7zip-full texinfo gcc-multilib gperf udisks screen python-m2crypto Figure 2-3: Common dependencies Depending upon the exact version of packages installed during the Ubuntu installation process, there may be additional packages that may have to be installed to complete the build. 2.3 SETTING UP BITBUCKET VEST provides source code for the kernel and U-Boot through git repositories. VEST hosts the source code and layers in Bitbucket (https://bitbucket.org/apc-vest). This consists of at least the following three components. Bitbucket Repository Name meta-vest-mx6 linux-vest-mx6 u-boot-vest-mx6 URLs to use in an internet browser Purpose https://bitbucket.org/apcvest/meta-vest-mx6 VEST s meta layers for Yocto https://bitbucket.org/apc-vest/linuxvest-mx6 Linux kernel & support package for VEST development boards https://bitbucket.org/apc-vest/uboot-vest-mx6 U-Boot bootloader & support package required for the VEST development boards Table 2-1: VEST Git repository names & URLs More repositories will be added over-time. Some of these repositories may be private and hence, a Bitbucket account is needed. To check if these repositories are public, please visit https://bitbucket.org/apcvest and check if the repositories mentioned in Table 2-1 are listed under the list of public repositories. If all the repositories listed above are public, then one does not need to create a Bitbucket account. If any of the repositories are private, then a Bitbucket account is required. Even if the above repositories become publicly accessible, VEST may provide additional functionality through private repositories under specific licensing terms. Please feel free to contact support@apc-vest.com if you should have any questions in this regard. First time users must request access to Bitbucket repositories through http://apc-vest.com/sourcecode-access/. 2.3.1 Private repositories and enabling SSH access to Bitbucket If the repositories are private and if you do not have a Bitbucket account for work, please create a free Bitbucket account using your corporate email address by visiting https://www.bitbucket.com. Please send a request through http://apc-vest.com/source-code-access/ or contact your VEST representative with the following information for an invitation to access the private repositories. Bitbucket Username Page 9 APC Proprietary Information June 9, 2017

Work email address associated with the Bitbucket account Company name VEST development platform or SOM that is used A project identifier for your project, if any: Company name and project identifier is used to manage teams within Bitbucket Yocto uses several scripts to automatically fetch suitable versions of the software to build an embedded Linux image. This automatic fetch process requires SSH access if private repositories are used. At the time of writing this document, all VEST repositories are private and the VEST meta layers for Yocto are designed to use SSH to access private repositories when building using Yocto. After you have setup an account with Bitbucket using your work email address, please review https://confluence.atlassian.com/bitbucket/set-up-ssh-for-git-728138079.html to know more about setting up SSH access for your git account with Bitbucket. To further assist in setting up the SSH access when there are firewall restrictions, we provide step-by-step instructions below in Figure 2-4 and in particular, step 5. In the instructions, please replace <LinuxUserName> with your Linux user name. Please note that if the user would like to access his/her Bitbucket account over SSH from multiple PCs or Virtual machines, a unique SSH key must be used on each of those machines. Page 10 APC Proprietary Information June 9, 2017

Step 1: Generate Public and Private Keys for SSH. Use /home/<linuxusername>/.ssh/id_rsa_bitbucket as the name of the identity file when asked. It is user s choice to enter a passphrase or not when asked. As suggested, it is more user-friendly if a passphrase is not used as Yocto uses scripts to access and fetch sources from Bitbucket using SSH. $ ssh-keygen Step 2: Run the ssh-agent if it is not running $ ps -e grep [s]sh-agent $ ssh-agent /bin/bash Step 3: Add the newly created keys to SSH (assuming the file name and location entered in Step 1 is the same as suggested. Otherwise, use the same file name, which was provided in Step 1, in this step and following steps) $ ssh-add /home/<linuxusername>/.ssh/id_rsa_bitbucket Step 4: The following command places the public key into the clipboard. Alternatively, copy contents of the public key file into clipboard manually. $ cat /home/<linuxusername>/.ssh/id_rsa_bitbucket.pub xclip -sel clip Step 5: Add (i.e., paste) public key copied into clipboard in Step 4 into Bitbucket. It can be done by first logging into your Bitbucket account and then clicking the Avatar of your account and navigating through to Bitbucket Settings SSH Keys Add SSH Key Step 5: The firewall in some companies might block port 22 that is used for SSH by default. To establish SSH access under those conditions, Bitbucket provides SSH support over TCP port 443 (which is used by HTTPS and hence, not typically blocked). To configure access over port 443 to git servers in Bitbucket, please create or modify ~/.ssh/config file to have the following contents. Host bitbucket.org User git Hostname altssh.bitbucket.org IdentityFile /home/<linuxusername>/.ssh/id_rsa_bitbucket IdentitiesOnly yes Port 443 Step 6: Configure your global git profile by using your work email address, which is expected to be the same email address associated with the Bitbucket account $ git config --global user.email "your@email.com" $ git config --global user.name "your name" Step 7: Verify SSH setup by looking at the logs of this command for a successful connection established. In particular, please look for the line that reads logged in as <your Bitbucket name>, which confirms that SSH access works from this machine. $ ssh -vt git@bitbucket.org Figure 2-4: SSH access to Bitbucket Page 11 APC Proprietary Information June 9, 2017

3. DOWNLOADING FREESCALE COMMUNITY BSP PLATFORM VEST-VKGEN-QSG-001, REV A Freescale Community maintains meta layers that can be used to build many images. More information on Community can be found at https://github.com/freescale/fsl-community-bsp-platform. 3.1 INSTALLING REPO UTILITY The platform involves the use of repo, which is a popular repository management utility from the Android project that helps in automating many tasks related to downloading most of the layers required to build Yocto images. Launch a new terminal window in your Ubuntu. Step 1: Create a directory in your home directory to place the repo utility $ mkdir ~/bin Step 2: Get repo utility $ curl http://commondatastorage.googleapis.com/git-repodownloads/repo > ~/bin/repo Step 3: Make that utility an executable $ chmod a+x ~/bin/repo Step 4: Add the location of the repo command to executable search path $ echo "PATH=\${PATH}:~/bin" >> ~/.bashrc Step 5: Exit the terminal window $ exit Figure 3-1: Installing repo utility 3.2 DOWNLOADING LAYERS USED IN YOCTO Use the following steps to download the layers into your hard drive. Please note that this downloads only the layers and recipes; but does not download the source code for building the recipes. Step 1: Create a folder in which you would like to download various layers and build your Yocto image $ mkdir -p ~/development/my_vest && cd ~/development/my_vest Step 2: Download layers from a particular branch on the platform (in this case, jethro branch, which corresponds to Yocto 2.0.x) $ repo init -u https://github.com/freescale/fsl-community-bspplatform -b jethro $ repo sync Figure 3-2: Downloading Yocto layers The label jethro mentioned in Figure 3-2 refers to the branch that matches the code name of the Yocto version that is supported. Page 12 APC Proprietary Information June 9, 2017

3.2.1 Building a different version of Yocto To build a different version of Yocto (say krogoth) instead of Jethro, please replace jethro in Figure 3-2 with krogoth. Generally speaking, one should be able to specify the code name of any supported Yocto version as an argument to the repo command in Figure 3-2. At the time of writing this document, only Jethro which is Yocto 2.0.x and Krogoth which is Yocto 2.1.x are supported by VEST. Page 13 APC Proprietary Information June 9, 2017

4. META-LAYERS FOR VEST DEVELOPMENT PLATFORMS 4.1 DOWNLOADING VEST SUPPORT LAYERS FOR YOCTO VEST provides layers to easily enable building of Yocto based images on VEST development platforms. These layers and components are available from VEST s git repositories in Bitbucket - https://bitbucket.org/apcvest/. Please review Section 2.3 before proceeding further with these steps. Step 1: Change to the directory created in earlier steps described in Figure 3-2 $ cd ~/development/my_vest/sources Step 2: Clone/Fetch the meta-vest-mx6 repository from Bitbucket using either https access or SSH access methods. Since the Yocto build process might access private repositories, SSH access method is preferred. Instructions provided below assume that ssh access has been enabled in the Virtual Machine or PC in which Yocto is built $ git clone ssh://git@bitbucket.org/apc-vest/meta-vest-mx6.git metavest-mx6 Figure 4-1: Download VEST meta layers 4.2 ALWAYS A WORK IN PROGRESS VEST derives its kernel for its i.mx 6 SoC based platforms from Linux kernel 3.14.52 released by NXP for i.mx 6. Either as a consequence of continuous testing or as a consequence of adding new features & functionality, there will be changes committed to the repositories in Bitbucket by VEST engineers. Customers are advised to periodically check if there are changes in VEST repositories that they are interested in or if the latest code solves an issue for them. Customers can either use git browsers or git commands to view the details of the change or can simply visit the website of the repository (for example, https://bitbucket.org/apc-vest/meta-vest-mx6/commits/all) and click on any particular commit to get detailed information about that commit before deciding whether to make use of the changes or not. Page 14 APC Proprietary Information June 9, 2017

5. BUILDING EMBEDDED LINUX IMAGES 5.1 SETUP A BUILD DIRECTORY/ENVIRONMENT One can create any number of build directories under the directory where the Community BSP platform repo has been downloaded. The illustration shows how to set one up for VEST VK5100 development platform as an illustration. The procedure for other VEST development platforms remain the same with the primary exception that the respective development platform name is used instead of VK5100 or vk5100 in the instructions below. This command sets up a build directory (the string my_vk5100 in this command can be replaced by any name of that the user prefers limited only by what Linux/Yocto allows) $ cd ~/development/my_vest $. setup-environment my_vk5100 Figure 5-1: Setting up the environment Please note that whenever a new terminal window is opened from now, please setup the environment using. setup-environment my_vk5100 to work on this build directory. This step is required to use Yocto tools on this build directory. All operations below assume that the user is in ~/development/my_vest/my_vk5100 directory after setting up the environment. 5.2 MAKE MODIFICATIONS TO THE BUILD ENVIRONMENT One can check the build directory s hierarchy by typing ls ~/development/my_vest/my_vk5100. After a fresh creation of the environment, only the conf directory exists. The conf directory consists of two important files: bblayers.conf: Contains the list of directories that contain the various layers describing the components to be built or the image to be built local.conf: The main configuration file of the build environment. This contains the main configuration including the definition of the MACHINE and customisation section of the Yocto build environment The build environment described in ~/development/my_vest/my_vk5100/conf/local.conf can be modified in a number of ways to Change the target machine for which the image is built Add or remove certain components to/from the built image Override default set of components or their versions Specify source code caching directories, etc Add/Install custom files to the target... and many more customisation that Bitbake allows that are beyond the scope of this document VEST provides sample local.conf and bblayers.conf files which can be used as a reference. They are available under ~/development/my_vest/sources/meta-vest-mx6/conf as local.conf.sample and bblayers.conf.sample. Please copy the contents of ~/development/my_vest/sources/meta-vestmx6/conf/local.conf.sample and ~/development/my_vest/sources/meta-vest-mx6/conf Page 15 APC Proprietary Information June 9, 2017

/bblayers.conf.sample over into ~/development/my_vest/my_vk5100/conf/local.conf and ~/development/my_vest/my_vk5100/conf/bblayers.conf. And make any additional changes required like adding new packages or features. Alternatively, please modify the bblayers.conf file and the local.conf directly to make some essential changes. The essential changes are highlighted in figures and respectively. $ cd ~/development/my_vest $. setup-environment my_vk5100 $ cp../sources/meta-vest-mx6/conf/bblayers.conf.sample conf/bblayers.conf $ cp../sources/meta-vest-mx6/conf/local.conf.sample conf/local.conf $ vi conf/bblayers.conf... Edit bblayers.conf if required (please see following paragraphs) $ vi conf/local.conf... Edit local.conf if required (please see following paragraphs) Figure 5-2: Steps to copy the sample bblayers.conf and local.conf files to build directory Figure 5-3 below describe the essential changes that the bblayers.conf.sample file provide. Most importantly, please ensure the meta-vest-mx6 layer is included in the bblayers.conf file as highlighted in green. Other layers like those highlighted in blue must be added if features/images are available only from those layers. LCONF_VERSION = "6" BBPATH = "${TOPDIR}" BSPDIR := "${@os.path.abspath(os.path.dirname(d.getvar('file', True)) + '/../..')}" BBFILES?= "" BBLAYERS = " \ ${BSPDIR}/sources/poky/meta \ ${BSPDIR}/sources/poky/meta-yocto \ \ ${BSPDIR}/sources/meta-openembedded/meta-oe \ ${BSPDIR}/sources/meta-openembedded/meta-multimedia \ ${BSPDIR}/sources/meta-openembedded/meta-webserver \ ${BSPDIR}/sources/meta-openembedded/meta-networking \ ${BSPDIR}/sources/meta-openembedded/meta-python \ \ ${BSPDIR}/sources/meta-fsl-arm \ ${BSPDIR}/sources/meta-fsl-arm-extra \ ${BSPDIR}/sources/meta-fsl-demos \ ${BSPDIR}/sources/meta-vest-mx6 \ " Figure 5-3: Contents of bblayers.conf.sample Figure 5-4 below describe the essential changes that the local.conf.sample file provide. Most importantly, please ensure the correct machine is defined as shown in green. Most other changes are just useful changes that would help the developer or introduce a developer to some variables used in Yocto to include extra features. The changes in blue (EXTRA_IMAGE_FEATURES and IMAGES_INSTALL_append) will work only if the corresponding changes (also in blue) in Figure 5-3 are done such that layers that provide the feature in local.conf are also included in bblayers.conf. The variable IMAGE_FSTYPES tells Yocto in which forms the final image must be built. Please refer to the Yocto Development Manual and the internet for information on how to add/remove components and customise the components. There are some examples in the VEST meta layers of how components can be customised by making use of several ways of overriding a layer or extended a layer in Yocto. Page 16 APC Proprietary Information June 9, 2017

MACHINE??= 'vest-vk5100' DISTRO?= 'poky' PACKAGE_CLASSES?= "package_rpm" EXTRA_IMAGE_FEATURES = "debug-tweaks" USER_CLASSES?= "buildstats image-mklibs" PATCHRESOLVE = "noop" BB_DISKMON_DIRS = "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ ABORT,${TMPDIR},100M,1K \ ABORT,${DL_DIR},100M,1K \ ABORT,${SSTATE_DIR},100M,1K \ ABORT,/tmp,10M,1K" PACKAGECONFIG_append_pn-qemu-native = " sdl" PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" CONF_VERSION = "1" # Download all the sources locally into this folder # and create compressed archives locally for sharing # with multiple BSP directories # DL_DIR?= "${BSPDIR}/src_cache" SOURCE_MIRROR_URL?= "file://${dl_dir}" INHERIT += "own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1" # Additionally, more than one of these values including ext2, ext4, jffs2 can be specified. # IMAGE_FSTYPES = "ext2 ext4 jffs2 tar.bz2" IMAGE_FSTYPES = "sdcard tar.bz2" EXTRA_IMAGE_FEATURES += "splash hwcodecs" IMAGE_INSTALL_append += "monkey proftpd autofs ptpd wolfssl zeroconf wpa-supplicant hostapd dnsmasq curl" ACCEPT_FSL_EULA = "1" Figure 5-4: Contents of local.conf.sample 5.3 SELECTING AN IMAGE TO BUILD NXP/Freescale and the community project define many Yocto images that we can build. To find out the list of images that can be built, please use the following commands. $ cd ~/development/my_vest/sources $ ls */meta*/recipes*/images/* meta*/recipes*/images/* Figure 5-5: Listing all buildable images To make it easier to build images for VEST development platforms, VEST has created some custom image recipes. These recipes can be found under the ~/development/my_vest/sources/meta-vestmx6/recipes-images/images directory. Please review the *.bb files under that directory to look at examples of building your own product specific distribution. For the purposes of building the first VEST image, we will use the image recipe vest-image-x11 (as defined by vest-image-x11.bb file). Page 17 APC Proprietary Information June 9, 2017

5.4 BUILDING THE FIRST YOCTO IMAGE FOR VEST DEVELOPMENT PLATFORM To build a particular image, please invoke bitbake to build the image. In this illustration, we build the vestimage-x11 image. Please note that it is important to ensure that the build environment has been setup on a terminal window at some point before starting the build as mentioned in Setup a build directory/environment. $ cd ~/development/my_vest/my_vk5100 $ bitbake vest-image-x11 Figure 5-6: Build the image Please note that the bitbake command in will not only compile and link the recipes that are include included in the definition of the vest-image-x11 image recipe; but also, the features and recipes added to EXTRA_IMAGE_FEATURES and IMAGE_INSTALL_append variables in local.conf. 5.4.1 Fetch the sources before starting the compilation process Yocto build process fetches the source of each package just before configuring the package for build, compiling and deploying the package. This means that if as much as 5000+ packages are required to build the image, then internet connection is required until the build completes at least for the first time even if local caching of sources is enabled as done in meta-vest-mx6/conf/local.conf.sample. Since building of the image takes several hours depending upon the number of packages being built and the machine on which the image is built, it may be useful and/or required to download the sources first while Internet connection is available before starting the configuration and compilation part of the process. The commands below will instruct bitbake to first download the source code for all packages included in the image first (including building of a local cache, if instructed to do so) first before starting the compilation and deployment process. $ cd ~/development/my_vest/my_vk5100 $ bitbake -c fetchall vest-image-x11 Figure 5-7: Fetch all source files needed 5.5 BUILDING MFGTOOL RUNTIME IMAGES NXP provides a utility called the Manufacturing Tool (MFGTool) to aid i.mx users to program emmc and other flash parts that are connected to i.mx SoCs. Since there are a few versions of MFGTool that NXP/Freescale has provided over the years, it is highly recommended that the customer uses MFGTool with accompanying documentation. VEST customers can request MFGTool package for their VEST development board(s) by sending an email to support@apc-vest.com. The version of MFGTool that VEST s MFGTool package is based on can be found at https://www.nxp.com/webapp/download?colcode=imx6_l3.14.52_mfg_tool. MFGTool makes use of a proprietary protocol that NXP has embedded inside the Boot ROM of the i.mx SoC. When the SoC is placed in a special MFG mode (also, called the Serial Download mode), MFGTool can be used to first download a runtime image that contains a U-Boot, Linux kernel and a RAM Disk based rootfs to help download the product binaries and program the flash connected to i.mx SoC. To make things easier and to prevent confusion, VEST has created a separate MACHINE to have maximum flexibility in creating the firmware image for manufacturing tool. We also encourage developers to create a separate build directory/environment to build the firmware images for manufacturing tool. Page 18 APC Proprietary Information June 9, 2017

Step 1: Create a new build directory $ cd ~/development/my_vest $. setup-environment my_vk5100-mfg Step 2: Copy the sample bblayers.conf.sample file into ~/development/my_vest/my_vk5100-mfg/conf/bblayers.conf and modify to include a reference to meta-vest-mx6 Step 3: Copy the sample local.conf.sample into ~/development/my_vest/my_vk5100- mfg/conf/local.conf and modify suitably. Ensure that the variable MACHINE is configured to vest-vk5100-mfgtool. Remove all EXTRA_IMAGE_FEATURES and IMAGE_INSTALL_append as mfgtool does not normally need those features Step 4: Build the fsl-image-mfgtool-initramfs image $ cd ~/development/my_vest/my_vk5100-mfg $ bitbake fsl-image-mfgtool-initramfs Figure 5-8: Building MFGTool firmware Please note that for VK8300, one should use vest-vk8300-mfgtool as the MACHINE in local.conf. 5.6 UPDATING VEST LAYERS AND REBUILDING THE IMAGE As mentioned in Section 4.2, VEST would continue to modify and improve its support for developers who want to use embedded linux and the Yocto in their projects. To get updates to VEST support, it is often sufficient to pull the latest updates for the meta-vest-mx6 layer. Latest updates to that layer has information on the exact kernel revision and U-Boot revision to be pulled from their respective VEST repositories. Please follow the following steps to update an earlier meta-vest-mx6 clone and rebuild your image. Step 1: Change to the directory where the meta-vest-mx6 layer has been cloned from VEST repository $ cd ~/development/my_vest/sources/meta-vest-mx6 Step 2: Pull latest updates available for that layer from git. This command may have to be modified depending upon branches involved. $ git pull Step 3: Rebuild the image $ cd ~/development/my_vest $. setup-environment my_vk5100 $ bitbake vest-image-x11 Figure 5-9: Updating layers and building image Page 19 APC Proprietary Information June 9, 2017

6. DEPLOYING EMBEDDED LINUX IMAGES VEST development platforms feature a flash on the SOM itself. It is recommended that developers use the on-som emmc flash memory for their development and production needs. Additionally, some VEST development platforms do provide the option of the booting from usd/sd card that can be inserted into the carrier board of the VEST development platform for the U-Boot and image to be booted from the usd/sd card. This feature can be helpful when preparing for a demo or to nondestructively test a new image on the device. Please refer to the development platform s documentation on booting from SD/uSD card. After building the image using the layers and recipes provided, the build system creates several files that are used to construct the final image that will be programmed i.e., deployed into the emmc. The following steps will help you through the process. 6.1 YOCTO GENERATED FILES USED IN DEPLOYMENT The files generated by Yocto are located in the tmp/deploy/images/<machine> directory under the build directory. Table 6-1 below lists the files used for deployment. Purpose SPL Small Program that sets up DRAM and loads the U- Boot U-Boot bootloader. The imx file contains a header making it suitable for use in MFGTool Under ~/development/my_vest/my_ vk5100/tmp/deploy/images/v est-vk5100 SPL u-boot.img Under ~/development/my_vest/my_vk51 00-mfg/tmp/deploy/images/vestvk5100-mfgtool SPL u-boot.imx Root File System Table 6-1: Essential output files from Yocto build Compressed kernel image zimage zimage-mfgtool-vest-vk5100- mfgtool.bin Device Tree Blob zimage-imx6dl-vest-vk5100- sdio.dtb (In some cases, like in VK8300, there may be multiple DTB files that are created for flashing into the target such that VK8300 s U-Boot can decide at runtime, the DTB file to be loaded) zimage-mfgtool-imx6dl-vestvk5100-sdio.dtb vest-image-x11-vestvk5100.tar.bz2 (The leading suffix follows the name of the image being built. When building the image coreimage-minimal, this file will be core-image-minimal-vestvk5100.tar.bz2) fsl-image-mfgtool-initramfs-vestvk5100-mfgtool.cpio.gz.u-boot Page 20 APC Proprietary Information June 9, 2017

6.2 FLASHING TO ON-BOARD FLASH MEMORY OR SD CARD NXP s MFGTool allows us to create a product specific programming sequence to store contents into an onboard flash memory like emmc or removable storage like SD card. The programming sequence that is used to perform the actual programming of the target is stored in an XML file named ucl2.xml in the MFGTool package and can be modified by the user to suit the needs of the product. For more information on the MFGTool and how the XML file may be modified, please refer to documentation on manufacturing tool that is available in the manufacturing tool package from VEST for VEST development platforms. This package also contains U-Boot, kernel and the programming sequence for certain common variants of the VEST development platforms. Please contact support@apc-vest.com to get the manufacturing tool package for your VEST development platform. Figure 6-1 shows the directory structure of the MFGTool package from VEST. In this illustration and in several steps below, the root directory of the package is assumed to be vest-yocto-mfgtools-rootfs- 20170331. The Embedded Linux manufacturing tool package that VEST provides may contain a different name. When following the text below, please substitute vest-yocto-mfgtools-rootfs-20170331 with the name that you find in the package that you receive. cfg.ini under the top-most directory provides values to variables that choose the profile to be used Contains the V*EST logo bitmaps (as gzipped archives) that are used by U-Boot as splash screen Contains one or more profiles for each board/som. Contains the ucl2.xml and other scripts including the emmc/sd Card/NAND Flash partitioning layout MACHINE specific files directory has the content that needs to be flashed into the on-som flash/sd card including the product firmware MACHINE specific firmware directory has the content from the mfgtool build (Section 5.5) is used to perform the flashing process. This is the agent that performs that actual programming of the flash. Figure 6-1: MFGTool package directory structure Please note that a product specific carrier board would require not just a new product firmware; but also potentially a board specific mfgtool agent/helper firmware that is used to perform the programming itself. The latter includes the output of process outlined in Section 5.5 and programming sequence (stored in a file named ucl2.xml) modified to suit the product firmware. It is very important to note that the U-Boot, built by following the steps in Section 5.5, placed under the machine specific firmware folder, is used by the MFGTool to configure the memory controller in i.mx 6 SoC for the DRAM used in the SOM. The U-Boot and the device tree blob(s) specific must have been updated to use proper carrier board defines I/Os so that they output debug messages to the correct UART port. Figure 6-2 shows the typical contents of the firmware/vest-vk5100 folder in the MFGTool package from VEST. These files will not be stored in the flash; but will be downloaded by MFGTool Page 21 APC Proprietary Information June 9, 2017

Figure 6-2: Files (mfgtool agent) under ' Profiles/Linux_VS5100/firmware/vest-vk5100' Figure 6-3 shows the typical contents of the files/logos and the files/vest-vk5100 folders in the MFGTool package that VEST provides. The programming sequence defined in OS firmware/ucl2.xml makes use of variables defined by cfg.ini to know which files must be used. The programming sequence may rename some of these files as they are flashed into emmc to suit product requirements. So, please review the ucl2.xml file, cfg.ini file and the MFGTool s documentation that is available under the Document folder shown in Figure 6-1. The programming sequence can also be customised to suit the product s needs. (a) Contents of mfgtool2/logos folder (b) Contents of the Profiles/Linux_VS5100/files/vest-vk5100 folder Figure 6-3: Files under 'files/logos' & files/vest-vk5100 folders which are flashed into emmc/sd Card 6.2.1 Copying files for MFGTool Files mentioned in Table 6-1 are built either on a Linux Virtual Machine within a Host computer or a Linux machine. However, NXP s MFGTool runs only on Microsoft Windows. While this section of the document does not aim to provide instructions on how the developer may copy the files from Linux machine to Windows machine, it provides information on what files to copy and how some of them will have to be renamed for use with MFGTool package provided by VEST. Please refer to the documentation of your Virtual machine to copy the files from Linux virtual machine to a Windows host PC. When using the development platform, the files under the firmware folder in the MFGTool package would normally not have to be modified if the memory configuration of the SOM used in the development kit matches the u-boot provided for the platform there. Otherwise, the Yocto images generated for MFGTool (as described in Section 5.5 Building MFGTool runtime images ) that are specific for the SOM & carrier board must be copied appropriately. If the names of the files are not exactly the same as what is provided by VEST, please note that the cfg.ini file directly under vest-yocto-mfgtools-rootfs- 20170331/mfgtool2 directory and/or the <Chosen Profile>/OS Firmware/ucl2.xml file in the above illustration will have to be modified appropriately. Please consult the Manufacturing Tool documentation that is available under the Document folder for more information. Page 22 APC Proprietary Information June 9, 2017

Purpose SPL Small Program that sets up DRAM and loads the U- Boot U-Boot bootloader. The imx file contains a header making it suitable for use in MFGTool From ~/development/my_vest/my_ vk5100/tmp/deploy/images/v est-vk5100 to files/vestvk5100 SPL u-boot.img VEST-VKGEN-QSG-001, REV A From ~/development/my_vest/my_vk51 00-mfg/tmp/deploy/images/vestvk5100-mfgtool to firmware/vestvk5100 SPL u-boot.imx Compressed kernel image zimage zimage-mfgtool-vest-vk5100- mfgtool.bin Device Tree Blob zimage-imx6dl-vest-vk5100- sdio.dtb (Please note that in some cases like in VK8300, there may be multiple DTB files that may have to be copied) zimage-mfgtool-imx6dl-vestvk5100-sdio.dtb (Please note that in some cases like in VK8300, there may be multiple DTB files that may have to be copied) Root File System vest-image-x11-vestvk5100.tar.bz2 is renamed as rootfs.tar.bz2 when copying into the destination folder Table 6-2: Files to be updated in MFGTool package fsl-image-mfgtool-initramfs-vestvk5100-mfgtool.cpio.gz.u-boot To flash a new image into emmc, please update the relevant files in the machine specific folder under the files directory above by following Table 6-2. Please modify the cfg.ini or ucl2.xml files suitably to use different file names, board names, logo files, add additional versioning, etc To modify the logo displayed by U-Boot and to modify the logo displayed when Linux is booting, please read Sections 7.1.2 and 7.1.3 respectively. 6.2.2 emmc/sd Card Layout Partition scripts stored under the OS Firmware directory partition the emmc. The layout of the partition can be defined by the user by changing the files like vest.4gb.yocto.layout or vest.16gb.yocto.layout. Here is a sample content of the layout file for a 4GB emmc. # partition table of /dev/sdb unit: sectors /dev/sdb1 : start= 8192, size= 65536, Id=83 /dev/sdb2 : start= 73728, size= 3345098, Id=83 /dev/sdb3 : start= 3418826, size= 1048576, Id=83 /dev/sdb4 : start= 4467402, size= 3300000, Id=83 Figure 6-4: emmc partition layout data Please ignore the device number (/dev/sdb) listed there. The device number information is not used by the partition script. Only the start, size and Id numbers are used. 1 sector is 512 bytes. Please leave the Id value as 83, even for a FAT file-system. One can read the script source file in prep_sdcard_yocto.sh to understand how this layout file is used and the partitions are formatted & labelled. Here is an interpretation of the emmc layout. Please note that these layout files are also used for SD card partitioning as well. Page 23 APC Proprietary Information June 9, 2017

Purpose emmc Start Address Max Size File-system Label Used during filesystem creation VEST-VKGEN-QSG-001, REV A Mount Point in target Master Boot 0 1KB - - - Record SPL 1KB 68KB - - - U-Boot 69KB 4MB- - - - 69KB Device Tree 4MB 32MB FAT kernel /mnt/kerneldtblogo Blob, Kernel & Logo Root Filesystem 36MB 1633MB ext4 rootfs / Application 1669MB 512MB ext4 app /mnt/app partition Data partition 2181MB 1611MB ext4 data /mnt/data Table 6-3: emmc layout map If this partition map needs to be modified, please modify the contents of the layout file suitably. One common scenario is if the rootfs needs to be much larger than the default number, then the layout file needs to be modified suitably i.e., the size of some partitions following the rootfs might have to be adjusted and the start address of all affected partitions may have to be adjusted so as to still remain within the overall size of the flash device. 6.2.3 Programming the emmc with new images The steps for running the MFGtool to program the emmc/usd/sd is the same for all development platforms and operating systems. The actual target non-volatile storage that will be flashed is selected by using an appropriate cfg.ini file. 1. Please consult your development platform s Quick Start Guide to place the development mode in Serial Download mode (also referred to as Manufacturing Mode ). 2. When MFGTool executes, its progress can be monitored from the program s screen in Windows. Additional details can be seen by connecting the development platform s serial debug port to the PC. Please consult your development platform s Quick Start Guide or schematics to know which port provides the serial debug console. Please note that the mfgtool firmware build above in section 5.5 must also match this port. Typically, the serial port needs to be configured to the following settings. Setting Value Baud Rate 115,200 bps Data 8-bit Parity None Stop 1-bit Flow Control None Table 6-4: Serial debug console settings 3. Power-up the development platform 4. Connect the USB cable from the PC to the development platforms USB OTG port, which is typically a micro-usb port. Since there might be several such ports on the development platform, please check the development platform s Quick Start Guide to identify the correct port that provides USB OTG functionality. Page 24 APC Proprietary Information June 9, 2017

5. Under the mfgtool2 directory in the received MFGTool package, copy the appropriate cfg-*.ini file into cfg.ini or modify cfg.ini file appropriately to reflect the Profile of the mfgtool (which gives the image that you would like to burn) and the development platform that you are using. The cfg.ini file also selects the non-volatile storage that will be flashed. 6. Launch the MFGTool that is located directly under mfgtool2 directory. This should result in a window like shown below. Please note that HID-compliant device must be displayed, which is an indication that the software is connected to a supported development platform. If HID-compliant device is not shown, please check the switches/jumpers in the development platform that are used to place the development platform in the Serial Download mode and check all the cable connections including the USB OTG cable connection. Figure 6-5: MFGTool initial window 7. Connecting the serial debug console cable (this might either be a special debug port cable in some development platforms like VK5100 or another micro-usb port like in VK8300) from the kit to the same PC. This is useful to monitor the progress of the flashing process in a fine-grained manner as the development platform emits logs when the mfgtool agent is being executed in it. 8. Click the Start button to start the programming process. The programming process can be monitored either on the MFGTool window or the serial debug console. An example of the log shown in the serial debug console when MFGTool starts downloading and executing the agent in the target is shown in Figure 6-7. A successful operation results in a screen with green bars like shown in Figure 6-6. A screen with red bar indicates that the process failed. If the serial debug console is connected, there may be more information on why the operation failed. Figure 6-6: MFGTool reporting success Page 25 APC Proprietary Information June 9, 2017

Figure 6-7: Example of serial debug console log when MFGTool starts executing 9. After the MFGTool completes the programming process, it is very important to press the Stop button in the window shown in Figure 6-6 if one does not wish the MFGTool program to automatically start programming the next i.mx 6 device that is connected to the PC and placed in serial download mode. To exit the program, simply close the window or click the Exit button. 6.3 POWERING UP THE BOARD WITH THE NEW IMAGE After programming the emmc with the new image, please change the boot mode of the development platform to boot from emmc and power cycle the development platform. The development platform should now boot with the newly deployed image. Please consult the development board s quick start guide to know the exact position of the boot select switches/jumper to place the SOM into boot from emmc mode. If you have programmed the image into an SD or usd card, then please consult the development boards quick start guide or user guide to know the exact position of the boot select switches/jumper to boot from SD/uSD. Also, please connect your PC to the UART port marked for serial debug in your board. For some VEST development platforms like VK5100 development platform, a special interface connector with 3-pin to DB9 conversion is required. For other VEST development platforms that have a USB-to-serial convertor built into the development platform, please use a suitable USB cable. Please consult the development board s quick start guide to know which port and connector must be used for this purpose. On a PC that is connected to the development platform s serial debug port, please use software like TeraTerm and configure the serial port with the settings mentioned in Table 6-4. Assuming that VEST provided layer.conf.sample and bblayers.conf.sample files were used as suggested above, Figure 6-8 shows the logs emitted by SPL and U-Boot leading into the execution of the kernel. Further, the Linux kernel executes through various stages and as soon as the frame buffer is ready and psplash starts executing, one should see the Yocto project logo on the display as a splash screen shown during kernel startup. The serial debug console displays all the messages emitted by the kernel and stops Page 26 APC Proprietary Information June 9, 2017

with a login prompt. But at the same time, the graphical shell already displays a terminal window for the user to connect a USB keyboard to the development platform and enter shell commands. In the serial debug console, please enter root as the user in serial debug console to get to the same state. The system will not ask for a password if the suggested files were used as mentioned above. Page 27 APC Proprietary Information June 9, 2017

U-Boot SPL 2015.10 (Jun 08 2016-22:17:29) Board Config: 3'b111 ==> 7 sdio: 1, pcie: 0, dram_part_id: 0 DRAM Part: h5tc2g63ffr checking emmc U-Boot 2015.10 (Jun 08 2016-22:17:29 +0800) CPU: Freescale i.mx6solo rev1.3 996 MHz (running at 792 MHz) CPU: Commercial temperature grade (0C to 95C) at 53C Reset cause: POR VS5100: usdhc3 is available I2C: ready DRAM: 512 MiB MMC: emmc: 0, usd_card: 1, SDIO: 2 checking emmc *** Warning - bad CRC, using default environment PCI: pcie phy link never came up auto-detected panel Hannstar-WSVGA load_logo_image_from_filesystem: logo_1024x600.bmp.gz fatload mmc 0:1 0x12000000 logo_1024x600.bmp.gz reading logo_1024x600.bmp.gz 32304 bytes read in 21 ms (1.5 MiB/s) video_interfaces changing to lvds Display: Hannstar-WSVGA (1024x600) Frame Buffer Startup Delay - 750000usecs @ board_cfb_skip:907 In: serial Out: serial Err: serial Found PFUZE200 deviceid=11,revid=21 Net: board_eth_init Phy 0 not found FEC [PRIME] Hit any key to stop autoboot: 0 checking emmc switch to partitions #0, OK mmc0(part 0) is current device checking emmc reading boot.scr ** Unable to read file boot.scr ** reading zimage 6210384 bytes read in 174 ms (34 MiB/s) Booting from mmc... reading imx6dl-vest-vk5100-sdio.dtb 36807 bytes read in 18 ms (1.9 MiB/s) Kernel image @ 0x12000000 [ 0x000000-0x5ec350 ] ## Flattened Device Tree blob at 18000000 Booting using the fdt blob at 0x18000000 Using Device Tree in place at 18000000, end 1800bfc6 Starting kernel... Booting Linux on physical CPU 0x0 Linux version 3.14.52_vest-3.14.52-1 (user@user-virtualbox) (gcc version 5.2.0 (GCC) ) #1 SMP PREEMPT Wed Jun 08 22:12:41 SGT 2016 SPL dumps SOM information. & configures memory controller. Loads U-Boot into DRAM and passes control to it. Always check the build date to see if it is the SPL you built. U-Boot starts running and dumps information about the SOM and SoC. Always check the build date to ensure that this is the U-Boot that you built. U-Boot auto-detects display by trying to sense the touch panel connected to the carrier board. It then loads a suitable logo from the boot device and puts it in a buffer for display before turning on the backlight. The V*EST logo is shown on the display here. U-Boot can be configured at compile time to wait for a predefined amount of time (in seconds) for the user to manually override the default kernel load flow and command line. U-Boot runs a (default) script that loads the kernel (zimage) & device tree from emmc into pre-determined memory locations in DRAM and passes control to zimage along with a kernel command line that can affect system behaviour. For example, U-Boot sends detected display through this command line Kernel is executing... Check the kernel build date as well Figure 6-8: SPL & U-Boot flow Page 28 APC Proprietary Information June 9, 2017

7. DEVELOPING & DEPLOYING YOUR OWN APPLICATIONS Yocto provides a standard way to create a base Linux based system with numerous libraries and applications of developer s choice. Yocto also allows for kernel customisation, kernel module development and application development using customer specific layers and assigning appropriate priorities to those layers. Alternatively, developers can use their custom build system to build their applications. 7.1 CUSTOMISING THE KERNEL AND U-BOOT FOR YOUR CUSTOM BOARD/APPLICATION There are many ways to customise the kernel. The easiest way is to duplicate meta-vest-mx6 and define new machines. meta-vest-mx6 defines machines like vest-vk5100 or vest-vk5100-mfgtool. Please choose a machine name that you would like and modify the defconfig files for your product/machine. Additionally, a new device tree may have to be created. Device tree source files are available under the directory arch/arm/boot/dts under the kernel source tree. Customers with appropriate access can download the Linux kernel source for VEST from https://bitbucket.org/apc-vest/linux-vest-mx6.git or ssh://git@bitbucket.org/apc-vest/linux-vest-mx6.git. Please ensure that the correct branch is being downloaded. At the time of writing this document, 3.14 is the active branch. Even when VEST s development board is used, there may be scenarios like adding support for a camera module or new I 2 C or SPI device where the device tree provided by VEST might have to be modified. The device tree that must be used for the machine is normally defined under conf/machine/<machine>.conf layer under the customer layer or in VEST s case, meta-vest-mx6. External kernel development model is also very common in Yocto too. Please read more about these in the internet and Yocto Project Development Manual and the internet for numerous ways of kernel development using Yocto. 7.1.1 U-Boot The U-Boot might also have to change depending upon what is changed in the board or what is desired in the application. Customers with appropriate access can download the U-Boot source for VEST from https://bitbucket.org/apc-vest/u-boot-vest-mx6.git or ssh://git@bitbucket.org/apc-vest/u-boot-vestmx6.git. Please ensure that the correct branch is being downloaded. At the time of writing this document, 2015.10 is the active branch. Board specific files/changes can be gotten by searching for vest in file/directory names. The changes are mostly under the following directories: configs include/configs board/vest 7.1.2 Modifying the logo being displayed at start-up At the time of writing this document, VEST s u-boot for Embedded Linux loads and displays a gzip compressed 24-bpp BMP file in the display that is part of the development platform. The free open-source image manipulation tool Gimp can be used to reformat the BMPs in an appropriate format. Page 29 APC Proprietary Information June 9, 2017

Figure 7-1: Settings used to create compatible logo image for U-Boot The logo that is used by U-Boot is stored in the FAT partition labelled kernel as mentioned in Table 6-3: emmc layout map. VEST uses a certain naming convention for the files so that their size is obvious and fills the entire display. For example, logo_1024x600.bmp.gz & logo_640x480.bmp.gz. U-Boot has been designed to try to identify the display being used based on implicit knowledge of the displays that VEST supports and load the logo with suitable dimensions. To modify, it suffices if new logo files are placed under logos directory and modify ucl2.xml and cfg.ini files depending upon the resolution of the display/images and the name of the file in that directory. Please refer to Section 6.2 for more information. 7.1.3 Modifying the logo being displayed when Linux starts The splash feature added to EXTRA_IMAGE_FEATURES in local.conf.sample makes use of psplash to provide the Yocto image and the progress bar when the machine boots Linux. Please search the Internet to find articles that teach how to change the image in that splash screen. Also, custom programs can also be written to show the splash screen. 7.2 GENERATING THE COMPILER TO BUILD APPLICATIONS OUTSIDE YOCTO Although Yocto can be used for application development by defining new recipes under the customer s layers, there may be a need to generate a compatible compiler if application is not compiled within Yocto build environment and its integration into the root file system is not done using Yocto. And Yocto can help to generate the cross compiler that is needed for this external application development model. Please follow the steps in Figure 7-2 to build the cross-compiler toolchain. Page 30 APC Proprietary Information June 9, 2017