Saturday 28 April 2018

FSL Community BSP Release Notes 2.4 documentation

Link:

To get the BSP you need to have repo installed and use it as:
Install the repo utility:
$: mkdir ~/bin
$: curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
$: chmod a+x ~/bin/repo
Download the BSP source:
$: PATH=${PATH}:~/bin
$: mkdir fsl-community-bsp
$: cd fsl-community-bsp
$: repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b rocko
$: repo sync
At the end of the commands you have every metadata you need to start work with.
To start a simple image build:
$: MACHINE=imx28evk DISTRO=fslc-framebuffer source ./setup-environment build-imx28 
$: cd build;
$: bitbake -g core-image-minimal / bitbake -g u-boot-mkimage
$: bitbake core-image-minimal / bitbake u-boot-mkimage

You can use any directory to host your build.
The source code is checked out at fsl-community-bsp/sources.

Adding Qt5 into Image

Link:
http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard
 
$: git clone -b rocko https://github.com/meta-qt5/meta-qt5.git

 

1. Edit yocto/build/conf/bblayers.conf to add the meta-qt5 layer at the end:
 ${BSPDIR}/sources/meta-qt5 \
 ${BSPDIR}/sources/meta-openembedded/meta-ruby \
 ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
2. Edit yocto/build/conf/local.conf and add:
EXTRA_IMAGE_FEATURES = "debug-tweaks ssh-server-openssh "

IMAGE_INSTALL_append = " gcc g++ binutils libgcc libgcc-dev libstdc++ libstdc++-dev libstdc++-staticdev \
autoconf automake ccache chkconfig glib-networking glibmm \
packagegroup-core-buildessential pkgconfig  \
boost cmake zlib glib-2.0 packagegroup-fsl-tools-testapps  \
    ruby \
    cpufrequtils \
    nano \
    gdb \
    gstreamer \
    gst-meta-video \
    gst-fsl-plugin \
    gst-plugins-base-app \
    gst-plugins-base \
    gst-plugins-good \
    gst-plugins-good-rtsp \
    gst-plugins-good-udp \
    gst-plugins-good-rtpmanager \
    gst-plugins-good-rtp \
    gst-plugins-good-video4linux2 \
    openssh-sftp-server \
    packagegroup-fsl-gstreamer \
    packagegroup-fsl-tools-testapps \
    packagegroup-fsl-tools-benchmark \
    imx-vpu \
    imx-test \     
    qtbase-fonts \
    qtbase-plugins \
    qtbase-tools \
    qtbase-examples \
    qtdeclarative \
    qtdeclarative-plugins \
    qtdeclarative-tools \
    qtdeclarative-examples \
    qtdeclarative-qmlplugins \
    qtmultimedia \
    qtmultimedia-plugins \
    qtmultimedia-examples \
    qtmultimedia-qmlplugins \
    qtsvg \
    qtsvg-plugins \
    qtsensors \
    qtimageformats-plugins \
    qtsystems \
    qtsystems-tools \
    qtsystems-examples \
    qtsystems-qmlplugins \
    qtscript \
    qt3d \
    qt3d-examples \
    qt3d-qmlplugins \
    qt3d-tools \
    qtwebkit \
    qtwebkit-examples-examples \
    qtwebkit-qmlplugins \
    qtgraphicaleffects-qmlplugins \
    qtconnectivity-qmlplugins \
    qtlocation-plugins \
    qtlocation-qmlplugins \
    cinematicexperience \
    cairo pango fontconfig freetype pulseaudio dbus \
    alsa-lib alsa-tools alsa-state alsa-utils-alsaconf fsl-alsa-plugins \
    i2c-tools \ 
    "

We include ssh-server-openssh in EXTRA_IMAGE_FEATURES and the openssh-sftp-server in IMAGE_INSTALL_append for rapid deploying using QtCreator
  • Note: qtquickcontrols-qmlplugins fails in master branch
If you plan on using the 'core-image-minimal' image, then you must add 'dbus' to the IMAGE_INSTALL_append list.
If you plan to use Qt5 eglfs plugin for accelerated graphics using the framebuffer, you need to discard X11 and wayland so the proper graphics drivers get included:
DISTRO_FEATURES_remove = "x11 wayland"
  • The Wandboard Linux Kernel 3.10.17 comes configured with 24 bit depth for HDMI and LCD displays in the device tree. If you experience problems running Qt5 applications with the eglfs platform, change the bit depth to 32 bits in your own kernel fork or use the fbset (fbset [w] [h] [w] [h] 32) BEFORE running any egl application.
Bitbake an image like core-image-minimal (you need to be in your yocto/build directory):
 $ bitbake fsl-image-multimedia-full
Note: If bitbake fails with an error regarding cmake or drm recipes, locate their directories, delete them and try again.

Cross compile Qt5 for QtCreator

It is now very easy to build an environment for cross compilation using QtCreator. Version 1.7 in paths refers to Yocto Dizzy branch, if you are using different branch please use corresponding paths.
bitbake a meta-toolchain-qt5
Bitbake a poky toolchain (you need to be in your yocto/build directory):
 $ bitbake meta-toolchain-qt5
Install your new toolchain
Run the new installer that has been generated in yocto/build/tmp/deploy/sdk
$ sh poky-eglibc-x86_64-meta-toolchain-qt5-cortexa9hf-vfp-neon-toolchain-1.7.sh
This will install a cross compiler and its needed environment including the Qt5 arm libraries.
Configure Qt creator
Run qtcreator from the terminal after running the setup environment script located in /opt/poky/1.7
In QtCreator go to Tools > Options > Devices and add your Wandboard as a generic linux device.
go to Tools > Options > Build & Run and:
  1. Add a new compiler. Select your poky compiler: /opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-cpp
  2. Add your new cross compiled Qt version by selecting the qmake located in /opt/poky/1.7/sysroots/x86_64-pokysdk-linux/usr/bin/qt5
  3. Add a new kit selecting your new Qt5 version and compiler and setting the sysroot to /opt/poky/1.7/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi and leave the Qt mkspec empty. Finally select your wandboard for the device.

Boot Sequence and Optimization Techniques



Before starting to work on the boot time optimization of any Linux platform, it is important to understand the boot sequence of the device. Here is the general boot sequence of the Linux platform.

  • ROM Code from Processor
  • Uboot (Bootloader)
    • DDR and Non-Volatile Memory Initialization
    • Initializing and configuring all the peripherals
    • Reading Kernel and Rootfs images from Non Volatile Memory
  • Loading Kernel
    • Initializing the platform hardware
    • Loading Built-in Driver Modules
  • Loading the Rootfs
    • Mounting File System
    • Loading driver modules from File System

One has to note here that the boot sequence would vary among the various platforms due to the following factors.

  • Processor's SRAM size - As the ROM code is loaded into processor's SRAM, if the size of the SRAM is not enough to hold the entire uboot, there may be another loader called x-loader (also called as MLO) which will be small in size. For example, OMAP3 processors will have x-loader to load the uboot.
  • Boot Device (MMC, NAND Flash, etc.)


 
1 Optimizing Bootloader
The following techniques would help to optimize the boot time of bootloader.
  • Removing or disabling the features that are unnecessary for the bootloader is the primary task in optimizing the bootloader.
  • It is better to keep the bootloader as minimal as possible. Bootloader should only initialize the RAM and Non-Volatile memory and then read kernel and rootfs images from non-volatile memory and load the kernel to RAM.
  • Using just the bootstrap instead of full uboot would also reduce the boot time. Have a separate full-fledged uboot for testing and use smaller bootstrap to load the kernel in production.
  • Remove the boot delay that's usually there in uboot before loading the kernel.
  • Make sure bootloader is reading the exact size of kernel and rootfs. Many loaders read up to the default maximum size irrespective of size of kernel and rootfs images.
  • Choosing the correct compression for the kernel images is a crucial while optimizing the boot time. Choosing the right compression techniques depends upon the balance between the storage reading speed and the CPU performance to decompress the kernel. Based on this, one should analyse with the various compression techniques before coming up with the correct compression method which gives good trade-off between read and decompress times.


2 Optimizing Kernel
Using the following techniques would help to optimize the kernel boot time.
  • As in the boot loader optimization, always start with disabling the features that are unnecessary for the product. Disabling unnecessary features not only helps in the reducing the kernel load time but also reducing the size of the kernel image which in turn reduces the time taken to read the kernel/rootfs images from the Non-Volatile memory.
  • Compile all the drivers that are not needed during boot time as modules so that these modules can be loaded once the critical application is launched.
  • Debug output on console may also take lot of time. So remove all the debug messages and keep only error messages.
  • Reorder the loading of the driver modules in such a way that modules that are required to run the critical application are loaded at first and then the remaining modules can be loaded in the background after the critical application is launched.

3 Optimizing Root File system and RAM File system Usage

3.1 Choosing the right File System
Optimizing the file system is generally one of the most important things to be worked on in boot time optimization as different file systems can take different times for initialization and mount times. The type of file system directly impacts the boot time. The different mount time is due to the different read, write and access performance of the various file systems. One should have the complete understanding of all the file system types and purpose of the file system in the final product. Choosing the right file system is again depends on the trade-off between the performance of the file system and purpose of the file system in the final product.


3.2 Using Temporary RAM File System
One important step in improving the boot time is to use the RAMFS file system temporarily till loading the critical application and load the root file system in background. In one of our product developments we used this technique where we were able to achieve 1 second boot time!

Reading Linux Kernel images into RAM from u-boot:

Reading images into RAM: