Introduction to yocto


Published on

An introductiont to version 1.2.1 of the Yocto Linuxdistribution build system.

Published in: Technology, Education

Introduction to yocto

  1. 1. Introduction to Yocto Version 1.2.1 August 2012 Alex González Digi International
  2. 2. AgendaYocto Overview ● Yocto 1.2.1 release System developers ● Yocto components ● Installing the Yocto build tree ● Yocto build system ● Using Yocto for system development ● Yocto Layers ● Yocto build system ● Bitbake recipes ● Yocto configuration ● System development workflow ○ OverviewApplication developers ○ Image generation process ● Application Development Kit Overview ○ Image creation ● Yocto standalone toolchain installation ○ Package repository ● Using the toolchain outside of Yocto ○ Yocto Features ● Yocto ADT installer ○ Command line build ● Application development workflow ■ Bitbake commands ● Command line workflow ■ Build times ● Eclipse plug-in for application developers ○ Using Hob ○ Installation ○ Fixing existing applications ○ Configuration ○ Yoctos Kernel Tree ○ Running a Yocto project application ■ Kernel customization ○ Debugging a Yocto project application ■ Kernel patching ○ Bitbake commander ○ Freescales Yocto kernel ■ The meta-fsl-arm layer ■ Kernel configuration
  3. 3. Yocto Overview● Open source, collaborative, umbrella project.● (98 projects)● Stable releases every 6 months.● Suitable both for: ○ System developers ○ Application developers● Supported by Freescale, Intel, LSI, Wind River, Montavista, Mentor Graphics, Texas Instruments, Huawei and others.
  4. 4. Yocto 1.2.1 releaseThe release is available at comprises poky denzil 7.0.1, eclipse plugin, toolchains, package sources, packaged package sources (rpm,ipk), abuild appliance, an ADT installer and a set of supported BSP layers.The structure of poky once untarred:The most up to date development can be fetched by: git clone git://
  5. 5. Yocto components● Poky (Build system) ○ OE-core ○ bitbake ○ Reference BSP metadata (one per arch) ○ meta-yocto ○ Documentation● ADT eclipse plugin● Embedded kernel tools● Pseudo (fakeroot replacement)● Swabber (Host system access detection)● Hob (Bitbake GUI)● Build Appliance (Virtual host image)● eglibc● autobuilder (QA and test plans)
  6. 6. Yocto build system
  7. 7. Yocto Layers Overview Collection of recipes that contain extensions and customizations to base systems.They are directories to look for recipes and added to BBLAYERS in build/conf/bblayers.conf
  8. 8. Yocto layers Management bitbake-layers <command> [arguments]Layer structure Where command can be:meta-<bsp_name>/meta-<bsp_name>/<bsp_license_file> helpmeta-<bsp_name>/README show-layers: Show current configured layers.meta-<bsp_name>/README.sources show-recipes: List available recipes and its layer parents.meta-<bsp_name>/binary/<bootable_images> show-overlayed: Show overlayed recipes (duplicated name onmeta-<bsp_name>/conf/layer.conf a higher priority layer)meta-<bsp_name>/conf/machine/*.conf show-appends: List .bbappend files and their recipe files.meta-<bsp_name>/recipes-bsp/* flatten: Flattens the layer configuration into a different folder.meta-<bsp_name>/recipes-core/* This are all layers with overlayed recipes removed and .meta-<bsp_name>/recipes-graphics/* bbappend files added to their corresponding recipes.meta-<bsp_name>/recipes-kernel/linux/linux-yocto_<kernel_rev>.bbappend Creating your own layers manuallyOpenEmbedded layers can be used with Yocto. ● Copy meta-skeleton ● Modify conf/layer.conf. ● Optionally add conf/machine/ and conf/distro/ ● Optionally, add new recipes to the recipes-* sub directories. Use .bbappend to override parts of other recipes better than pasting recipe code. ● Enable your layer by adding it to conf/bblayers.conf Or use the yocto-bsp command line tool: yocto-bsp help yocto-bsp help create
  9. 9. Bitbake recipesEach application has one or more bitbake recipe in the different layers. To add a new package to Yocto you need to providea .bb recipe for it. You can use any OpenEmbedded recipe as template.meta/recipes-core/expat/expat_2.1.0.bbrequire expat.incLIC_FILES_CHKSUM = "file://COPYING;md5=1b71f681713d1256e1c23b0890920874"PR = "r0"SRC_URI[md5sum] = "dd7dab7a5fea97d2a6a43f511449b7cd"SRC_URI[sha256sum] = "823705472f816df21c8f6aa026dd162b280806838bb55b3432b0fb1fcca7eb86"meta/recipes-core/expat/expat.incSUMMARY = "A stream-oriented XML parser library."DESCRIPTION = "Expat is an XML parser library written in C. It is a stream-oriented parser in which an application registers handlersfor things the parser might find in the XML document (like start tags)"HOMEPAGE = ""SECTION = "libs"LICENSE = "MIT"SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.gz file://autotools.patch"inherit autotools lib_package gzipnative# This package uses an archive format known to have issue with some versions of gzipdo_unpack[depends] += "gzip-native:do_populate_sysroot"do_configure_prepend () { rm -f ${S}/conftools/libtool.m4}
  10. 10. Bitbake classesBitbake classes (.bbclass) provide encapsulation and inheritance logic. They abstract common functionality and shareit amongst several recipes.Class files are placed in a classes directory under the meta or build directory, and are searched for in the BBPATH as.conf files.To enable its features it is usually enough to inherit the class. Every .bb recipe inherits the base.bbclass automatically.It contains definitions of basic tasks as fetching, unpacking, configuring, compiling, installing and packaging. These areusually overridden by other classes as autotool.bbclass or package.bbclass.Some important classes are:autotools.bbclass distutils.bbclassupdate-alternatives.bbclass devshell.bbclassupdate-rc.d.bbclass package*.bbclassbinconfig.class kernel.bbclaspkgconfig.bbclass image.bbclasssrc_distribute.bbclass rootfs*.bbclasssrc_distribute_local.bbclass sanity.bbclasscpan.bbclass insane.bbclass
  11. 11. Bitbake recipes Multiple providersIf a target has multiple providers, like different kernel or application versions, bitbake defaults to thehigher version. But this selection can be qualified by adding the following to a recipe: PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" COMPATIBLE_MACHINE Stops parsing unless machine listed here. DEFAULT_PREFERENCE Relative priority among like-named recipes. Overridden by PREFERRED_VERSION_* PREFERRED_VERSION_virtual/kernel = "3.2"
  12. 12. Bitbake recipes License trackingLIC_FILES_CHKSUM variable contains checksums of the license text in the source code for the recipe. Its mandatoryfor all recipes, unless the LICENSE variable is set to "CLOSED". LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx file://licfile1.txt;beginline=5;endline=29;md5=yyyy file://licfile2.txt;endline=50;md5=zzzz Commercial licensesRecipes which contain: LICENSE_FLAGS = "commercial" LICENSE_FLAGS = "license_${PN}_${PV}"Need to have a matching entry in the LICENSE_FLAGS_WHITELIST in local.conf, as: LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly" LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
  13. 13. Introduction to Yocto Application developers
  14. 14. Application developing contents Application developing ● Application Development Kit Overview ● Yocto standalone toolchain installation ● Using the toolchain outside of Yocto ● Yocto ADT installer ● Application development workflow ● Command line workflow ● Eclipse plug-in for application developers ○ Installation ○ Configuration ○ Running a Yocto project application ○ Debugging a Yocto project application ○ Bitbake commander
  15. 15. Application Development Kit OverviewThe application developer can: ● Install standalone Yocto toolchains. ● Use the ADT installer to install per architecture cross toolchains, environment setup scripts (/opt/poky/1.2.1), a sysroot (configured location f.e ${HOME}/yocto), and QEMU images: ● Or can use the toolchain and sysroot from a Yocto release tarball, what we will call Yocto Project Build Tree (YPBT).
  16. 16. Yocto standalone toolchain installation ● Download a precompiled tarball. ● Built in the YPBT for deployment: source oe-init-build-env [optional folder name] bitbake meta-toolchain-gmae (sato) bitbake meta-toolchain Compiles the tarball in tmp/deploy/sdk.In both cases the tarball is uncompressed in /opt/poky/x.y, the recommended toolchain location. ● Built in the YPBT for internal usage: 1. source oe-init-build-env 2. Edit conf/local.conf for your machine type: 3. bitbake meta-ide-support 4. Repeat the last two steps for several machine types.The toolchain will be built in the tmp directory.The sysroot and QEMU images would need to be installed separately.
  17. 17. Using the toolchain outside of YoctoThe toolchain in /opt/poky can be used outside of the Yocto project to build autotools or Makefilebased source, just by sourcing the architecture specific environment setup script before building./opt/poky/1.2/environment-setup-${ARCH}-poky-linuxAutotools configure --host=armv5te-poky-linux-gnueabi --with-libtool- sysroot=<sysroot-dir>Makefile CC=arm-poky-linux-gnueabi-gcc LD=arm-poky-linux-gnueabi-ld CFLAGS=”${CFLAGS} --sysroot=<sysroot-dir>” CXXFLAGS=”${CXXFLAGS} --sysroot=<sysroot-dir>”
  18. 18. Yocto ADT installer ● Download a precompiled release ● Build one from the Yocto Project build tree: source oe-init-build-env bitbake adt-installerExtract anywhere: tar -xjf adt_installer.tar.bz2 cd adt-installer/ vim adt-installer.conf ./adt_installerInstalls into /opt/poky/x.y the toolchain, sysroot (at the configured location) and QEMU kernel images(in the adt-installer/download_image/zImage-qemuarm.bin)
  19. 19. Application development workflow The Eclipse plug in allows you to: ● Custom BSP ○ Copy an existing one ○ Make configuration changes ○ Make recipe changes ● Compile ● Deploy ● Run ● Debug
  20. 20. Command line workflowBuild the ipk packagebitbake <pkgname>bitbake package-indexDeploy the package to targets root filesystemCopy them to a web server and modify the base-feeds.conf file in the target:/etc/opkg/base-feeds.confsrc/gz all the package to the sysrootopkg-cl –f <conf_file> -o <sysroot_dir> updateopkg-cl –f <cconf_file> -o <sysroot_dir> --force-overwrite install <pkgname>opkg-cl –f <cconf_file> -o <sysroot_dir> --force-overwrite install <pkgname>-dbgopkg-cl –f <conf_file> -o <sysroot_dir> --force-overwrite install <pkgname>-dev
  21. 21. Eclipse plug-in for application developers Installation1) Install the Indigo Eclipse classic (does not work in Juno)2) Update with: Programming Languages -> Autotools Support for CDT Programming Languages -> C/C++ Development Tools Linux Tools -> LTTng - Linux Tracing Toolkit TM and RSE Main Features TM and RSE Optional Add-ons -> Every item except "RSE Unit Tests and RSE WinCE Services" CDT Main Features CDT Optional Features -> C/C++ Remote Launch and Target Communication Framework. Development tools and SDKs for Yocto Linux
  22. 22. Eclipse plug-in for application developers ConfigurationWindows -> Preferences -> Yocto ADT (also per project configuration)Selecting the Toolchain Type:Standalone Pre-built Toolchain: Toolchain and sysroot installed separately, without the Yocto Project build tree.Build System Derived Toolchain: Toolchain built as part of the Yocto Project build tree.Toolchain: For standalone prebuilt toolchain use /opt/poky/x.y , otherwise, point to the Yoctos project build/tmpdirectorySysroot: Point to the place where the rootfs for the target is created by the ADT installer. Used by QEMU, the NFSboot process and the x-toolchain. Otherwise, the YBPT installs it in build/tmp.Target architecture: Chose from the dropdown box.QEMU: For a build system derived toolchain, the kernel will be in tmp/deploy/images. Otherwise, its in the directoryspecified to he ADT installer to download the image, by default adt_installer/download_image/zImage-qemuarm.bin.Project -> "Change Yocto Project Settings" can change the toolchain configuration per project.
  23. 23. Eclipse plug-in for application developers Running a Yocto project applicationCreating a projectFile -> New -> C/C++ project -> Yocto ADT projectCan be based in both autotools or Makefiles. We will use a"Hello World ANSI C Autotools" sample project.Running an example applicationCompile and test in QEMU, Run -> Externals tools ->qemu_armv5te-poky-linux-gnueabiOpen a terminal and run ifconfig to get its IP address.In Run Configurations create a new C/C++ remoteapplication with a TCF (Target Communication Framework)connection to QEMUs IP address. The run the configuration:root@qemuarm:/# /bin/HelloWorld;exitHello Worldlogout
  24. 24. Eclipse plug-in for application developers Debugging a Yocto project application ● Place a breakpoint in main(). ● Debug Configuration->C/C++ Remote applications, click Debug. The debug perspective appears with the application executed in QEMU.For this to work the target image needs to contain a TCF agent service, which is added to an image as part of the tools.debug feature.
  25. 25. Eclipse plug-in for application developers Bitbake CommanderAllows you to add and modify the projects layers. Once the metadata project is created, we can modify it as follows:As general rules: 1. File -> New -> Yocto BitBaker Commander -> Bitbake ● You never change the metadata from upstream recipe (unless you are submitting a bug report upstream) 2. Point SRC_URI to the package source. ● You always use additional layers to make your own 3. Click populate to auto complete some fields, and complete changes. "Description" and "License" fields.When creating a new Yocto Project, you can point it to an 4. Project -> Launch Hobexisting YPBT, or you can instruct it to clone one from the 5. Choose the build directory to place the final images. (Notupstream Yocto project in a new location (not the Eclipse the YPBT, just an output folder)workspace). 6. Use Hob to customize and build your own images.YoctoProjectTools -> yocto-bsp allows to create a newlayer.
  26. 26. Introduction to Yocto System developers
  27. 27. System developing contents System developers ● Installing the Yocto build tree ● Using Yocto for system development ● Yocto build system ● Yocto configuration ● System development workflow ○ Overview ○ Image generation process ○ Image creation ○ Package repository ○ Yocto Features ○ Command line build ■ Bitbake commands ■ Build times ○ Using Hob ○ Fixing existing applications ○ Yoctos Kernel Tree ■ Kernel customization ■ Kernel patching ○ Freescales Yocto kernel ■ The meta-fsl-arm layer ■ Kernel configuration
  28. 28. Installing the Yocto build tree1. Development host machine setup2. Yocto installation:● Download Yocto release as tarball (for supported platforms)● Clone from git repositories ○ Clone the Yocto project build tree (YPBT) git clone git:// Initialized empty Git repository in ${USER}/poky/.git/ ● Clone the Yocto Linux kernel A bare (allow pushes) local repository: git clone --bare git:// linux-yocto-3.2.git A local working copy: git clone linux-yocto-3.2.git my-linux-yocto-3.2-work The Yocto project metadata needed to modify and build kernel images. git clone git:// poky-extras Initialized empty Git repository in ${USER}/poky/poky-extras/.git/ ● Clone the BSP layer: git clone git:// Initialized empty Git repository in ${USER}/poky/meta-fsl-arm/.git/
  29. 29. Using Yocto for system development ● The Yocto Project build tree is f.e located at /usr/local/yocto-1.2 ● We initialize an environment for our project: source oe-init-build-env $HOME/ccwmx53 ● The initial project contents are: ~/ccwmx53$ find ./conf/bblayers.conf ./conf/local.conf ● We would edit local.conf and add layers to bblayers.conf ● Run bitbake to build: bitbake <target>, f.e bitbake core-image-minimal ● Find the build output in deploy/imagesUsing local source mirrorsDownloading all sources is time consuming so you probably only what to do it once. To use a local mirror, after acomplete build move the sources and edit your local.conf file to include: SOURCE_MIRROR_URL ?= "file://path_to_local_mirror" INHERIT += "own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1"To make sure you can build without network access you can add: BB_NO_NETWORK = "1"
  30. 30. Yocto build system
  31. 31. Yocto configuration ● Local user defined: build/conf/local.conf MACHINE BB_NUMBER_THREADS PARALLEL_MAKE DL_DIR ● Policy meta-yocto/conf/distro/poky.conf ● Machine specific meta-bsp/conf/machine/imx51evk.conf
  32. 32. System development workflow Overview● Image creation ○ Adding existing packages to image ■ Adding a Yocto feature ○ Creating a custom image ○ Adding new packages to Yocto ○ Fixing existing applications workflow● Kernel development ○ Source modifications ○ Configuration changesNote that Yocto does not seem to support bootloader development.
  33. 33. System development workflow Image generation process Recipes do: ● fetch package sources ● patch ● configure ● compile ● package.Shared state caching (Or using checksum information during the build)Bitbake uses a per-task state caching system and not per recipe. It checksums the tasks inputs and rerun thetask if they have changed. This is called the basehash. A master checksum add the basehash and thehashes of the tasks dependencies.The shared state code looks in SSTATE_DIR (local) and SSTATE_MIRRORS (network) for shared statefiles. The state validity is detected looking at its name as the task checksum is there. If its valid, it downloadsit and uses it to accelerate the task.
  34. 34. System development workflow Image creation DESCRIPTION = "My Custom Tasks" PACKAGES = "Images can be customized in the build/local.conf file: task-custom-apps task-custom-apps-dbg Adding packages to the image: task-custom-apps-dev task-custom-tools IMAGE_INSTALL = "task-core-x11-base package1 package2" task-custom-tools-dbg inherit core-image task-custom-tools-dev IMAGE_INSTALL_append = " sysfsutils" [note the leading space] " RDEPENDS_task-custom-apps = "Or by adding a new task (see right box), using meta/recipes-core/tasks/task- dropbear as an example. portmap psplash"And then adding it to the image : RDEPENDS_task-custom-tools = " oprofile IMAGE_INSTALL_append " task-custom-apps task-custom-tools" oprofileui-server lttng-control lttng-viewer" RRECOMMENDS_task-custom-tools = " kernel-module-oprofile"
  35. 35. System development workflow Package repository Images are generated from the packages for: ● Target rootfs images ● QEMU rootfs images ● Sysroots for application development Newer packages can be generated to update both sysroots and target root filesystems.
  36. 36. Yocto FeaturesYocto introduces features as a mechanism to group recipes by logical function. Features can beselected by the distribution or at image creation time. ● Distribution can select which features they want to support via:DISTRO_FEATURESMACHINE_FEATURESSome distribution feature example are alsa, bluetooth, ext2, usbgadget, usbhost, wifi, nfs, ipv6 ,toucshcreen etc ● Images can be configured with:IMAGE_FEATURESEXTRA_IMAGE_FEATURESSome image feature example are x11-base, x11-sato, nfs-server,package-management, tools-debugetc
  37. 37. Command line build Build DebuggingPrepare for build source oe-init-build-env [build_dir] Enable debug output: bitbake -DDD -v targetnamewhere typically build_dir represents a target. Log file for shell tasks: ${WORKDIR}/temp/log.do_taskname.pidLaunch build Corresponding to the bitbake tasks in bitbake <target> [-k]The -k or --continue option instructs bitbake to go Adding logging to recipes (meta/classes/logging.bbclass)ahead and build all dependencies even if there arefailures. Python: bb.fatal, bb.error, bb.warn, bb.note, bb.plain, and bb.Common targets can be found in: debug Bash: bbfatal, bberror, bbwarn, bbnote, bbplain, and bbdebug. ○ meta/recipes-core/images ○ meta/recipes-sato/images No dependency buildAnd also in: ● meta/recipes-extended/images bitbake -b <somepath/> ● meta/recipes-qt/images ● meta/recipes-graphics/images Show environment information ● meta/recipes-rt/images Shows current and preferred version of packages. bitbake --show-versionsExplained in the Yocto project documentation. Shows global or per-package environment bitbake --environmentBuild results in tmp/deploy/images bitbake --environment <package name> bitbake --environment -b <recipename>
  38. 38. Bitbake commandsSome usual commands:bitbake <pkgname> -c listtasksTasks available for a package/recipebitbake <pkgname> -c rebuild -f Clean and build again a packagebitbake <pkgname> -c fetch -f Download again the source programbitbake <pkgname> -c devshell Expand a gnome xterm ready to raise commandsbitbake <pkgname> -c clean/compile Clean or compile package.bitbake <pkgname> Build package (including creating package)bitbake package-index Make package index files for feedsbitbake <target_image> Build image contains task-base packages.bitbake <target_image> -c buildall -f Build pending packages for target_imagebitbake <target_image> -c rootfs -f Populate rootfs again for target_imagebitbake -e <pkgname> | grep ^S= Finds the source code.bitbake -e <target> | grep ^WORKDIR= Finds bitbakess working directory.bitbake -e <image-target> | grep ^IMAGE_FSTYPES=Finds the image types being build.bitbake -g -u depexp<target_image> Dependency explorer UIMore details on the bitbake manual.
  39. 39. Build timesOn an Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00 ● First build (all sources local)GHz Total time: 1h 6minsBuild configuration ● Build, no clean Total time: 1min 30secsbuild/local.conf BB_NUMBER_THREADS = "4" ● Clean, then rebuild PARALLEL_MAKE = "-j 4" ○ Remove build directory MACHINE ??= "qemuarm" Same as first build above. ○ Remove only build output /tmp (keeps ● Download source first downloaded sources and state) bitbake -c fetchall core-image- Total time: 8 mins. minimal ● Then build bitbake core-image-minimal
  40. 40. Using HobHob is a GUI for bitbake.It allows to build for different machine typesas well as: ● Adding layers ● Choose image type ● Add/remove individual recipes and tasks ● Select output image types, packaging format, etc
  41. 41. System development workflow Fixing existing applications● Find the path to the temporary source code for your ● Generate the patch package. git format-patch HEAD~1 bitbake -e <target> | grep ^S= ● Copy the patch to a "files" folder in the same directory● Change to that path and create a local git repo as the recipe. git init ● Add it to Yocto: git add * SRC_URI += "file://my_changes.patch" git commit ● Increment the Package revision number (PR) ● Clean:● Edit files● Test your changes bitbake -c clean -f <pkgname> bitbake -c compile -f <pkg_name> bitbake -c cleanall -f <pkgname>● Commit your changes git status git add file1.c file2.c file3.c git commit
  42. 42. Yoctos Kernel TreeThe Yocto kernel team has its own set of processes and tools. The Yoctokernel tree is structured as follows: ● Once the Yocto kernel branches from, BSPs and custom features are all in branches. ● Once its released, new features are backported on a process named "upward revision" (uprev). ● The kernel build system compiles a list of KERNEL_FEATURES, producing a series of meta directories to apply to the base tree. ● The released Yocto kernel tree is a combination of all supported boards and configurations.
  43. 43. Yoctos kernel treeKernel customization ● Create a new layer copying an existing layer or using the yocto- bsp command line tool. yocto-bsp create custom arm ● Add it to bblayers.conf ● The template left by yocto-bsp leaves a set of .cfg files to add configuration variables. ● It also leaves .scc files to add kernel features to. ● The meta-fsl-arm kernel does not yet use the same .cfg and .scc files, and does not use the Yocto kernel project tool.
  44. 44. Yoctos kernel tree Kernel patching● Kernel patches can be manually added/removed.● Or we can use the yocto-kernel command line tool. yocto-kernel patch add custom ~/test.patch Added patches: test.patch yocto-kernel patch list custom The current set of machine-specific patches for myarm is: 1) test.patch● It also works for configuration fragments: yocto-kernel config add custom CONFIG_MISC_DEVICES=y Added items: CONFIG_MISC_DEVICES=y yocto-kernel config list custom The current set of machine-specific kernel config items for myarm is: 1) CONFIG_MISC_DEVICES=y
  45. 45. Yoctos kernel tree Bitbake tasksdo_fetch ● Listed by:do_unpackdo_kernel_checkout bitbake -c listtasks virtual/kerneldo_validate_branches ● Re-ran by:do_patchdo_kernel_configme bitbake virtual/kernel -c taskdo_populate_llicdo_configure ● To streamline the kernel configuration, run iteratively:do_kernel_configcheckdo_compile bitbake virtual/kernel -c configmedo_compile_kernelmodules bitbake virtual/kernel -c kernel_configcheckdo_sizecheckdo_uboot_mkimagedo_kernel_link_vmlinuxdo_compile_perfdo_installdo_install_perfdo_packagedo_deploy
  46. 46. Freescales Yocto kernel The meta-fsl-arm layer ● Browsable at ● Contains recipes to build all the components of the FSL BSP, including kernel, U-Boot and multimedia components. ● imx53qsb.conf ○ includes machine/ ○ includes distro/ Defines the preferred providers: PREFERRED_PROVIDER_virtual/xserver = "xserver-xorg- lite" PREFERRED_PROVIDER_virtual/kernel ?= "linux-imx" PREFERRED_PROVIDER_linux-libc-headers ?= "linux-libc- headers-imx" PREFERRED_PROVIDER_u-boot ?= "u-boot" So bitbake will look for the most recent "linux-imx" recipe from: ● ● ● Taking into account the DEFAULT_PREFERENCE and COMPATIBLE_MACHINE variables as with all recipes. So is chosen in this case.
  47. 47. Freescales Yocto kernel Kernel configuration ● The kernel recipe selected contains a defconfig file ● The do_configure task in: meta/classes/kernel.bbclass copies it to .config and runs make oldconfig. ● Kernel patches are kept on the linux-imx- folder and are listed on the SRC_URI of the recipe. ● Configuration fragments can also be kept in the same folder and appended also to SRC_URI. SRC_URI += "file://i2c.cfg" ● The kernel can be configured with: source oe-init-build-env bitbake virtual/kernel -c menuconfig
  48. 48. Q&AThanks for watching!
  49. 49. This presentation is shared with an Attribution-NonCommercial-ShareAlike 3.0 Unported license.