Freescale Yocto Project for i.MX6 platform
Category : Blog Post
The Yocto Project is an open-source collaboration focused on embedded Linux® OS development. For more information regarding Yocto Project, see the Yocto Project page www.yoctoproject.org/. There are several documents on the Yocto Project homepage that describe in detail how to use the system. The basic Yocto Project, without the latest Freescale release layer, can be used by following instructions in the Yocto Project Quick Start found at http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html.
Freescale i.MX joined the Yocto Project community to provide a release based on the Yocto Project framework. Information specific to FSL community BSP can be found on the community webpage.
Freescale Yocto Project Release layers have the following features:
- Linux kernel recipe
- The kernel recipe resides in the recipes-kernel folder and integrates a Freescale kernel from the source downloaded from the Freescale git server. This is done automatically by the recipes in the project.
- 10.53_1.1.0 is a Linux kernel that Freescale has released only for the Yocto Project. Previous BSP releases based on Linux version 3.0.35 are released with ltib and are provided only from FSL Community BSP in the Yocto Project environment.
- Freescale L3.10.53_1.1.0 supports using device trees. Device tree settings are found in the i.MX 6 machine configuration files.
- U-Boot recipe
- The U-Boot recipe resides in the recipes-bsp folder and integrates a Freescale uboot-imx.git from the source downloaded from the Freescale git server.
- Certain i.MX boards use different U-Boot versions.
- Freescale release L3.10.53_1.1.0 for the i.MX 6 devices uses an updated v2014.04 Freescale version. This version has not been updated for other i.MX Freescale hardware.
- Releases based on Linux version 2.6.35 for imx5qsb uses v2009.08 from meta-fsl-arm.
- The Freescale Yocto Project Community BSP uses u-boot-fslc v2013.10 from the mainline but this is only supported by the community 3.0.35 kernel and will probably not work for the L3.10.53 kernel.
- Freescale release L3.10.53_1.1.0 requires the Freescale v2014.04 U-Boot release.
- The Freescale Yocto Project Community BSP updates U-Boot versions frequently, so the information above might change as new U-Boot versions are integrated to meta-fsl-arm layers and updates from Freescale u-boot-imx releases are integrated into the mainline.
- Graphics recipes
- Graphics recipes reside in recipes-graphics.
- Graphics recipes integrate the Freescale graphics package release. For the i.MX 6 boards, the gpu-viv-bin-mx6q recipes package the graphic components for each backend – X11, frame buffer (fb), Direct Frame Buffer (directfb), Wayland backend and Weston compositor (weston).
- Xorg-driver integrates our xserver-xorg.
- For i.MX 5, the amd-gpu-bin provides packages for X11 and frame buffer backends.
- MX package recipes
- imx-lib, imx-test, and firmware-imx reside in recipes-bsp and pull from the Freescale mirror to build and package into image recipes.
- Multimedia recipes
- Multimedia recipes reside in recipes-multimedia.
- Recipes include libfslcodec, libfslparser, libvpuwrap, and gstreamer that pull from the Freescale mirror to build and package into image recipes.
- Some recipes are provided for codecs that are restricted. Packages for these are not on the Freescale mirror. These packages are available separately. Contact your Freescale Marketing representative to acquire these.
- Core recipes
- Some recipes for rules, such as udev, provide updated i.MX rules to be deployed in the system. These recipes are usually updates of policy recipes and are used for customization only. Releases only provide updates if needed.
To get the Yocto Project expected behaviour in a Linux Host Machine, the packages and utilities described below must be installed. An important consideration is the hard disk space required in the host machine. For example, when building on a machine running Ubuntu, the minimum hard disk space required is about 50 GB for the X11 backend. It is recommended that at least 120 GB be provided, which is enough to compile any backend.
The recommended minimum Ubuntu version is 12.04 or later. Earlier versions may cause the Yocto Project build setup to fail, because it requires python versions only available starting with Ubuntu 12.04. See The Yocto Project reference manual for more information.
Essential Yocto Project host packages:
$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib \
build-essential chrpath socat
i.MX layers host packages for a Ubuntu 12.04 or 14.04 host setup:
$ sudo apt-get install libsdl1.2-dev xterm sed cvs subversion coreutils texi2html \
docbook-utils python-pysqlite2 help2man make gcc g++ desktop-file-utils \
libgl1-mesa-dev libglu1-mesa-dev mercurial autoconf automake groff curl lzop asciidoc
i.MX layers host packages for a Ubuntu 12.04 host setup only:
$ sudo apt-get install uboot-mkimage
i.MX layers host packages for a Ubuntu 14.04 host setup only:
$ sudo apt-get install u-boot-tools
Setting Up the Repo Utility
Create a bin folder in the home directory.
$ mkdir ~/bin (this step may not be needed if the bin folder already exists)
$ curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable.
Yocto Project Setup
Getting Source from GIT:
$ mkdir fsl-release-bsp
$ cd fsl-release-bsp
$ git config –global user.name “Your Name”
$ git config –global user.email “Your Email”
$ git config –list
$ repo init -u git://git.freescale.com/imx/fsl-arm-yocto-bsp.git -b imx-3.10.53-1.1.0_ga
$ repo sync
Choosing a Freescale Yocto Project Image
|core-image-minimal||A small image that only allows a device to boot.|
|core-image-base||A console-only image that fully supports the target device hardware.|
|core-image-sato||An image with Sato, a mobile environment and visual style for mobile devices. The image supports X11 with a Sato theme, Pimlico applications. It contains a terminal, an editor and a file manager.|
|fsl-image-machine-test||An FSL Community i.MX core image with console environment – no GUI interface|
|fsl-image-gui||Builds a Freescale image with a GUI without any QT content. This image recipe works on all backends for X11, DirectFB, Frame Buffer and Wayland|
|fsl-image-qt5||Builds a QT5 image for X11, Frame Buffer and Wayland Backends|
In the meta-fsl-bsp-release layer, Freescale provides new or updated machine configurations that overlay the meta-fsl-arm machine configurations. These files are copied into the meta-fsl-arm/conf/machine directory by the fsl-setup-release.sh script.
The following are all the Freescale machine configuration files that can be selected:
bitbake <parameter> <component>
<component> is a desired build package.
|-c fetch||Fetches if the downloads state is not marked as done.|
|-c cleanall||Cleans the entire component build directory. All the changes in the build directory will be lost. The rootfs and state of the component are also cleared. The component is also removed from the download directory.|
|-c deploy||Deploys an image or component to the rootfs.|
|-k||Continues building components even if a build break occurs.|
|-c compile -f||It is not recommended that the source code under the tmp directory is changed directly, but if it is, the Yocto Project might not rebuild it unless this option is used. Use this option to force a recompile after the image is deployed.|
|-g||Lists a dependency tree for an image or component.|
|-DDD||Turns on debug 3 levels deep. Each D adds another level of debug.|
|U-Boot type||Build setup||Build command|
|U-Boot EIM-NOR||$ echo “UBOOT_CONFIG = \”eimnor\”” >> conf/local.conf||$ MACHINE=imx6dlsabreauto bitbake -c deploy u-boot-imx|
|U-Boot SPI-NOR||$ echo “UBOOT_CONFIG = \”spinor\”” >> conf/local.conf||$ MACHINE=imx6qsabreauto bitbake -c deploy u-boot-imx|
|U-Boot NAND||$ echo “UBOOT_CONFIG = \”nand\”” >> conf/local.conf||$ MACHINE=imx6solosabreauto bitbake -c deploy u-boot-imx|
|U-Boot SATA||$ echo “UBOOT_CONFIG = \”sata\”” >> conf/local.conf||$ MACHINE=imx6qsabresd bitbake -c deploy u-boot-imx|
|U-Boot M4||$ echo “UBOOT_CONFIG = \”m4fastup\”” >> conf/local.conf||$ MACHINE=imx6sxsabresd bitbake -c deploy u-boot-imx|
|U-Boot QSPI1||$ echo “UBOOT_CONFIG = \”qspi1\”” >> conf/local.conf||$ MACHINE=imx6sxsabreauto bitbake -c deploy u-boot-imx|
|U-Boot QSPI2||$ echo “UBOOT_CONFIG = \”qspi2\”” >> conf/local.conf||$ MACHINE=imx6sxsabresd bitbake -c deploy u-boot-imx|
|U-Boot EMMC||$ echo “UBOOT_CONFIG = \”emmc\”” >> conf/local.conf||$ MACHINE=imx6sxsabresd bitbake -c deploy u-boot-imx|
|U-Boot m4fastup||$ echo “UBOOT_CONFIG = \”m4fastup\”” >> conf/local.conf||$ MACHINE=imx6sxsabresd bitbake -c deploy u-boot-imx|
Building an Image
The Yocto Project build uses the bitbake command. For example, bitbake <component> builds the named component. Each component build has multiple tasks, such as fetching, configuration, compilation, packaging, and deploying to the target rootfs. The bitbake image build gathers all the components required by the image and build in order of the dependency per task. The first build is the toolchain along with the tools required for the components to build.
The following command is an example on how to build an image:
$ bitbake fsl-image-gui
X-11 Image on i.MX 6Quad Sabre-SD
$ MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-x11 -e x11
$ bitbake fsl-image-gui
This builds an X11 image without QT5. To build with QT5, build fsl-image-qt5.
FB Image on i.MX 6Quad Sabre-AI
$ MACHINE=imx6qsabreauto source fsl-setup-release.sh –b build-fb –e fb
$ bitbake fsl-image-qt5
This builds QT5 on a frame buffer backend. To build without QT5, use image recipe fsl-image-gui.
DFB Image on i.MX 6SoloX Sabre-SD
$ MACHINE=imx6sxsabresd source fsl-setup-release.sh –b build-dfb –e dfb
$ bitbake fsl-image-gui
The fsl-image-gui image works on all backends and, if DirectFB is setup correctly in the build environment, it will enable the
DirectFB components. DirectFB does not support QT5 so only fsl-image-gui can be used with it.
Wayland Image on i.MX 6SoloX Sabre-SD
$ MACHINE=imx6sxsabresd source fsl-setup-release.sh -b build-wayland -e wayland
$ bitbake fsl-image-qt5
This builds a QT5 Weston Wayland image. To build without QT5, build fsl-image-gui.
Chromium Browser on X11 and Wayland
The Yocto Project community has chromium-imx recipes in the dizzy branch for X11 and Wayland. Note that the VPU patches used have problems but GPU patches work. This section describes how to integrate Chromium into your rootfs and enable hardware accelerated rendering of WebGL. The Chromium browser requires additional layers added in the fsl-release-setup.sh script.In local.conf, you can perform the following operations:
- Add Chromium into your image.
CORE_IMAGE_EXTRA_INSTALL += “chromium”
- Add the commercial white list into local.conf.
This allows proprietary code to be built into your image. Additional license obligations will need to be met for these additions. Make sure you know what they are and are in compliance.
Qt5 and WebKit Browser
Qt5 has both a commercial and an open source license. When building in Yocto Project the open source license is the default. Make sure to understand the differences between these licenses and choose appropriately. Once custom Qt5 development has started on the open source license it can’t be used with the commercial license. Work with a legal representative to understand the differences between these licenses. There are two Qt5 browsers available. Qt5WebKit can be found in /usr/share/qt5/examples/webkitwidgets/browser and WebKit2 can be found in /usr/share/qt5/examples/webkitqml/flickrview.
To run these, after booting up Linux on your device, tell Qt5 which graphics to use but setting the environment variable below. See Section “Qt5” in the i.MX Linux User’s Guide for the information on the graphics for different graphical backends.
Both browsers can be run by going to the directory above and running the executable found there. Touchscreen can be enabled by adding the parameters -plugin evdevtouch:/dev/input/event0 to the executable. So the command line would look like one of these:
./browser -plugin evdevtouch:/dev/input/event0
.flickrview -plugin evdevtouch:/dev/input/event0
Flashing an SD Card Image
An SD card image provides the full system to boot with U-Boot and kernel. To flash an SD card image, run the following command:
$ sudo dd if=<image name>.sdcard of=/dev/sd<partition> bs=1M && sync
For more information on flashing, see Section “Preparing an SD/MMC Card to Boot” in the i.MX Linux User’s Guide (IMXLUG).
The Manufacturing Tool, MFGTool
One way to place an image on a device is to use the Manufacturing Tool, MFGTool. The recipes used to build a manufacturing tool image are linux-imx-mfgtool and u-boot-mfgtool. To build a manufacturing image do the following –
$ bitbake fsl-image-mfgtool-initramfs
A manufacturing tool kernel is built using the imx_v7_mfg_defconfig while the default kernel is built by using the imx_v7_defconfig. This is handled automatically by the MFGTool recipes listed above.