Embedded Guru

The tmp directory is important folder to look when something is not working as expected in your build. The most important folders in tmp are: deploy: Contains the build output such as images, licenses, SDK's etc sysroots: Contains shared libraries, headers and utilities that are used in the process of building recipes work: Contains the recipe's Source code Configuration Execution Logs Contents of the generated packages

1. Generate dependency tree information in the dot syntax bitbake -g core-image-minimal The above command generates a dependency graph. Bitbake creates pn-buildlist, recipe-depends.dot and task-depends.dot files pn-buildlist: Simple list of packages which are going to be build recipe-depends.dot: Show dependencies between recipes task-depends.dot: Shows dependencies between tasks. 2. Displays environmental variables bitbake -e <recipe/target name> E.g: bitbake -e core-image-minimal | grep ^SDKMACHINE 3. Enable verbose output of shell tasks bitbake -v <recipe/target name> E.g. bitbake -v core-image-minimal 4.Continue bitbake even after error. This will be useful when you started a build and went for lunch and don't want the bitbake to stop if it is unable to fetch a file over Internet bitbake -k <target> E.g. bitbake -k core-image-minimal 5. Force the target to run even if there is ssta

The build directory is created when you run source oe-init-build-env script.   Its main directories are: conf : Configuration files which control poky and Bitbake. build/conf/local.conf and build/conf/bblayers.conf are present in it downloads: yocto stores all the downloaded packages (Source files), including those downloaded over SVN or git or similar sstate-cache: snapshost of an unaltered Yocto recipe deployed as a set of packaged data generating a cache. Bitbake checks SSTATE to see if a recipe does not need to be rebuilt, thereby saving time. tmp:   temporary   build directory. We will see a lot more about tmp directory in the upcoming posts.

oe-depends-dot utility analyses recipe-depends.dot file generated by bitbake -g command and provide you with options to Find out why a particular recipe is built means who is including this recipe Find out the dependencies of the particular recipe To use oe-depends-dot utility you need to first generate recipe-depends.dot file E.g. bitbake -g core-image-minimal generates .dot files To find out the dependencies of a particular recipe: E.g. oe-depends-dot -d -k <recipename> recipe-depends.dot $ oe-depends-dot -d -k sed recipe-depends.dot Depends: ncurses db libffi diffutils pseudo-native ptest-runner dwarfsrcfiles-native gawk openssl gettext-native gcc-runtime binutils-cross-x86_64 autoconf-native opkg-utils-native python3 libtool-cross quilt-native zlib base-files sqlite3 m4 bzip2 flex bc rpm-native automake-native cryptodev-linux libtool-native opkg-utils gdbm glibc-locale gnu-config-native make readline xz glibc perl gcc-cross-x86_64 libg

PN : Represents the name of the recipe. The name is usually extracted from the recipe file name. PR:  Represents the revision of the recipe. Default value for this revision is "r0". Subsequent revisions of the recipe conventionally will have "r1", "r2" and so on. PV:  Represents the version of the recipe. Normally extracted from the recipe file name. For example: ffmpeg_3.4.2.bb recipe. ${PN} : ffmpeg ${PV} : 3.4.2

1. Create "recipes-support" folder in your own custom layer 2. Inside the "recipes-support" folder, create a folder for example "test" 3. Inside "test" folder, create "test" recipe, $touch test_0.1.bb 4. Open test_0.1.bb and update it with the following: SUMMARY = "Test Application" LICENSE = "CLOSED" inherit update-rc.d SRC_URI = "file://test.c \        " do_compile () {     ${CC} ${CFLAGS} ${LDFLAGS} ${WORKDIR}/test.c  -o ${WORKDIR}/test } do_install () {     install -d ${D}${sysconfdir}/init.d     install -m 0755 ${WORKDIR}/test_service ${D}${sysconfdir}/init.d/test_service     install -d ${D}${sbindir}     install -m 0755 ${WORKDIR}/test ${D}${sbindir}/ } INITSCRIPT_NAME = "test_service" INITSCRIPT_PARAMS = "start 99 1 2 3 4 5 . stop 20 0 1 6 ." RDEPENDS_${PN} = "initscripts" CONFFILES_${PN} += "${sysconfdir}/init.d/test_service"

When you run source poky/oe-init-build-env, it will create a "build" folder in that directory, and inside this build folder, it will create "conf" folder which contains two files: 1. local.conf 2. bblayers.conf 1. local.conf : Configures almost every aspect of the build system: Machine we are building for (MACHINE) Tool chain host architecture to be used for a custom cross-toolchain (SDKMACHINE) Optimize options for maximum build time reduction (BB_NUMBER_THREADS, PARALLEL_MAKE) Where to place downloads (DL_DIR) Package Management options , which type of packages to generate (PACKAGE_CLASSES) 2. bblayers.conf: bblayers.conf file tells bitbake what layers you want to be considered during the build. By default, the layers listed in this file include layers minimally needed by the build system. However, you must manually add any custom layers you have created. E.g: BBLAYERS = "\                                   /home/jamal/poky/meta \

If there is need to enable or disable some configuration from the linux recipe which your BSP provides, create a new layer in Yocto. In this layer create the following folders: sources/meta-<layer_name>/recipes-kernel/linux In this folder create the following recipe (.bbappend) : touch linux-intel_%.bbappend Add the following two lines in this file FILESEXTRAPATHS_prepend := "${THISDIR}/files:" SRC_URI += "file://config.cfg" Then create files folder in that location:  $mkdir files && cd files After this create config.cfg file. $touch config.cfg Add all your changes into this. CONFIG_R8169=y CONFIG_I2C_CHARDEV=y CONFIG_EEPROM_AT24=y # CONFIG_USB_SERIAL_CP210X is not set That's all, now this settings will override the default configuration.

Yocto build Bitbake tool parses a recipe and generates a list of tasks that it can execute to perform the build steps. The most important tasks are: do_fetch : Fetches the source code do_unpack : Unpacks the source code into a working directory do_patch: Locates patch files and applies them to the source code do_configure: Configures the source by enabling and disabling any build time and configuration options for the software being built do_compile: Compiles the source in compilation directory do_install: Copies file from the compilation directory to a holding area do_package: Analyzes the content of the holding area and splits into subsets based on available packages and files do_package_write_rpm: Creates the actual RPM package and places them in the Package Feed Area The above task list is in the correct dependency order.

1. Command to check the list of available images. Run the following command in your source directory: $ ls meta*/recipes*/images/*.bb 2. Command to run the generated image in QEMU $runqemu <machine> <zImage> <filesystem> e.g. runqemu qemux86 core-image-minimal 3. Command to list the machines available $ ls meta*/conf/machine/*.conf 4. Command to generate SDK for a particular image $ bitbake <imagename> -c populate_sdk E.g. bitbake core-image-full-cmdline -c populate_sdk 5. Order in which all tasks executed are stored in <build directory>/tmp/work/<machine toolchain>/<package name>/<package version>/temp/log.task_order E.g. :   build/tmp/work/corei7-64-poky-linux/grep/3.1-r0/temp/log.task_order

Step1: Download the Poky Source code $ git clone git://git.yoctoproject.org/poky --branch sumo Step 2: Prepare the build environment. Inside the poky directory, there is a script named oe_init_build_env, which should be used to setup the build environment $ source poky/oe_init_build_env [ build_directory ] Here build_directory is an optional argument for the name of the directory where the environment is set; in case it is not given , it defaults to "build" Step 3: The above script will move you in a build folder and create two files ( local.conf, bblayers.conf ) inside conf folder. Now you can run any commands Step 4: Building Target Image bitbake <recipeName> bitbake core_image_full_cmdline

Non technically speaking, metadata is a set of data that describes and gives information about other data. Yocto: Metadata refers to the build instructions  data used to control what things get built and to affect how they are build Metadata also includes: Commands and data used to indicate what version of software are used Where they are obtained from Changes or additions to the software itself (Patches) which are used to fix bugs or customize the software to use in a particular solution Metadata in Yocto is a collection of  Configuration files (.conf) : Specifies machine architecture, file path, distribution selection Recipes(.bb and .bbappend) : Containing set of instructions , where to fetch the code, build etc Classes(.bbclass) : Abstract common functionality and for other recipes to just use the functionality Includes(.inc) : Similar to header files, this to avoid duplication when there is a recipe of multiple versions, common instructions are placed i

Kernel module is a piece of kernel code which can be added to the running kernel when loaded and can be removed from the kernel when the functionality is removed. When we do insmod on a module, it performs a series of steps: It calls init_module() to intimate the kernel that a module is attempted to be loaded and transfers the control to the kernel In kernel, sys_init_module() is run. It does a sequence of operations as follows: Verifies if the user who attempts to load the module has the permission to do so or not After verification, load_module function is called. The load_module function assigns temporary memory and copies the elf module from user space to kernel memory using copy_from_user It then checks the sanity of the ELF file ( Verification if it is a proper ELF file ) Then based on the ELF file interpretation, it generates offset in the temporary memory space allocated. This is called the conveni

Yocto Build System can take a lot of disk space during build. But bitbake provides options to preserve disk space You can tell bitbake to delete all the source code, build files after building a particular recipe by adding the following line in local.conf file INHERIT += "rm_work" Disadvantage: Difficult to debug while build fails of any recipe. For example, if you want to exclude bitbake deleting source code of a particular package, you can add it in RM_WORK_EXCLUDE += "recipe-name" E.g: RM_WORK_EXCLUDE += "core-image-minimal"

Sometimes, we may have a requirement to build Yocto Offline, this can happen due to various reasons: 1. No Internet Connection 2. Poor Download Speed 3. Firewall issues in Companies The process is to get all the required packages for a particular image passing "fetchall" to bitbake for a particular image you are going to build bitbake -c fetchall core-image-minimal Once all the packages have been downloaded, you can disable the network access by updating the local.conf file with the following: BB_NO_NETWORK = "1"

If you want to test your hddimg generated by bitbake on Virtual Box. Step 1: Convert the hddimg into VMDK using the VBoxManage utility VBoxManage convertfromraw D:\Yocto\Testing\core-image-sato-20181108045541.hddimg D:\Yocto\Testing\core-image-sato.vmdk --format VMDK   Another option is to add IMAGE_FSTYPES += vmdk in your local.conf file I then followed the below link to start the VMDK image https://github.com/gmacario/gmacario.github.io/blob/master/_posts/2015-11-14-running-yocto-image-inside-virtualbox.md Step2: Create a new Virtual Machine by clicking on New Step 3: Type the name of the Virtual Machine , Type: Linux, Version: Other Linux(64-bit) Step4: Set the Memory size to "1024" Step 5: Hard Disk: Do not add a virtual hard disk , Select "Create" and then "Continue" Step 6: Click on "Settings" and Under Storage: Add New Storage Controller -> Add SATA Controller Step 7: Select: Choose Exi

oe-pkgdata-util is helpful in determining why a file is included in the root file system. E.g: On the development machine: oe-pkgdata-util find-path /etc/inittab sysvinit-inittab: /etc/inittab $ oe-pkgdata-util find-path */libncurses.so* ncurses-libncurses: /lib64/libncurses.so.5 ncurses-libncurses: /lib64/libncurses.so.5.9 ncurses-dbg: /lib64/.debug/libncurses.so.5.9 lib32-ncurses-dbg: /lib/.debug/libncurses.so.5.9 ncurses-dev: /usr/lib64/libncurses.so lib32-ncurses-dev: /usr/lib/libncurses.so lib32-ncurses-libncurses: /lib/libncurses.so.5.9 lib32-ncurses-libncurses: /lib/libncurses.so.5 The other way is given a recipe and find out what files are generated by that recipe oe-pkgdata-util list-pkg-files -p lib32-ncurses To list the individual packages a recipe provide: oe-pkgdata-util list-pkgs -p lib32-ncurses lib32-ncurses-libtinfo lib32-ncurses-libncursesw lib32-ncurses-libncurses lib32-ncurses-libticw lib32-ncurses-libti

My learnings in Yocto 1. To open the linux kernel menuconfig ( Here I am using meta-intel layer ), run the following commands bitbake -c menuconfig linux-intel If you are using yocto kernel it will be bitbake -c menuconfig linux-yocto 2. To check whether your bbappend recipe is parsed by bitbake, run the following command bitbake-layers show-appends 3. To add a particular package in your root file system Open your local.conf file and add the recipe name below IMAGE_INSTALL += "recipe-name" E.g. IMAGE_INSTALL += "libusb" or IMAGE_INSTALL_append = "libusb" If you want this package to be included only in a particular image then, IMAGE_INSTALL_append_pn-<image-name> = "recipe-name" E.g. IMAGE_INSTALL_append_pn-core-image-sato = "libusb" 4. To include a kernel module in your root file system MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "kernel-module-cp210x" 5. To automatically load the module on bo