The Linux Kernel is just another recipe for Yocto, so learning to patch it you learn to patch any other package. In the other hand, Yocto **should not** be used for package development, but in those rare cases follow the below steps. It is assumed that you have already build the package you want to patch. 1. Create the patch or patches. In this example we are patching the Linux kernel for [wandboard-dual](http://www.wandboard.org/) machine; in other words, the value of MACHINE on the `build/conf/local.conf` is `MACHINE ??= 'wandboard-dual'`. In case you already have the patches, make sure these can be nicely applied with the commands `git apply --check <PATCH_NAME>`, and jump this step build $ cd tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git build $ # Edit any files you want to change build $ git add <modified file 1> <modified file 2> .. # Select the files you want to commit build $ git commit -s -m '<your commit's title>' # Create the commit build $ git format-patch -1 # Create the patch 2. Create a new layer (see document i.MX Yocto Proyect: How can I create a new Layer?) 3. On the new layer (e.g `meta-fsl-custom`) , create the corresponding subfolders and the `.bbfile` sources $ mkdir -p meta-fsl-custom/recipes-kernel/linux/linux-wandboard-3.0.35/ sources $ cat > meta-fsl-custom/recipes-kernel/linux/linux-wandboard_3.0.35.bbappend FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" SRC_URI += "file://0001-calibrate-Add-printk-example.patch" PRINC := "${@int(PRINC) + 1}" # SEE NOTE BELLOW ^d (The PRINC variable is not needed starting at Yocto 1.6 ([RFC] base.bbclass: Deprecate the PRINC logic - Patchwork)) 4. Move the patch to the new layer sources $ cp \ ../build/tmp/work/wandboard_dual-poky-linux-gnueabi/linux-wandboard/3.0.35-r0/git/0001-calibrate-Add-printk-example.patch \ meta-fsl-custom/recipes-kernel/linux/linux-wandboard-3.0.35 5. Setup the enviroment and clean previous package's build data (sstate) fsl-community-bsp $ . setup-environment build build $ bitbake -c cleansstate linux-wandboard 6. Compile and Deploy build $ bitbake -f -c compile linux-wandboard build $ bitbake -c deploy linux-wandboard 7. Insert the SD into your Host and copy the `uImage` into the first partition. Do not forget to unmount the partition before removing the card! build $ sudo cp tmp/deploy/images/uImage /media/Boot\ wandbo/ 8. Insert the SD into your board and test your change.

After bitbake meta-toolchain the script to install the toolchain package is located under $ ls tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.4.1.sh    tmp/deploy/sdk/poky-eglibc-x86_64-arm-toolchain-1.4.1.sh In order to install it: $ source poky-eglibc-x86_64-arm-toolchain-1.4.1.sh     [sudo] password for daiane:     Enter target directory for SDK (default: /opt/poky/1.4.1):     You are about to install the SDK to "/opt/poky/1.4.1". Proceed[Y/n]?y     Extracting SDK...done     Setting it up...done     SDK has been successfully set up and is ready to be used. Hello World $ source /opt/poky/1.4.1/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ cd ~/test/ $ arm-poky-linux-gnueabi-gcc helloworld.c $ ls a.out                                                 helloworld.c                           $ ./a.out -bash: ./a.out: cannot execute binary file $ file a.out a.out: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped Kernel $ source /opt/poky/1.4.1/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ cd linux-2.6-imx $ git checkout remotes/origin/imx_3.0.35 $ export ARCH=arm $ export CROSS_COMPILE=$TARGET_PREFIX $ unset LDFLAGS $ make imx6_defconfig $ make uImage Make sure to have mkimage available on bin patch (if using mkimage from u-boot export its patch) Or, download the ubuntu pachage: sudo apt-get install uboot-mkimage UPDATE You may find the following error:   OBJCOPY arch/arm/boot/zImage   Kernel: arch/arm/boot/zImage is ready multiple (or no) load addresses: This is incompatible with uImages Specify LOADADDR on the commandline to build an uImage make[1]: *** [arch/arm/boot/uImage] Error 1 make: *** [uImage] Error 2 This is regarding a missing LOADADDR for mkimage to use to generate uImage with the right offset to be placed in the right LOADADDR. The address value is dependent on your hardware! And it is different depending on imx6 variations. So please be aware regarding what is your right value. If the machine you are using is supported in yocto project/meta-fsl-arm, for example, you can find the value related with your board in the file conf/machine/include/imx-base.inc or online here meta-fsl-arm - Layer containing Freescale ARM hardware support metadata It is the same value used in variable UBOOT_ENTRYPOINT. For example as of this writing for the Freescale SABRE-SD board looking in conf/machine/include/imx-base.inc UBOOT_ENTRYPOINT_mx6  = "0x10008000" Thus the build command would be: $ make uImage LOADADDR=0x10008000 So, as a quick reference table, I point here the 3 most wanted make command lines: imx28evk: $ make LOADADDR=0x40008000 imx53qsb: $ make LOADADDR=0x70008000 imx6qsabresd: $ make LOADADDR=0x10008000 Update 2 Suggested by cmcqueen1975 Building an autotools-based package. E.g. $ source /opt/poky/1.4.1/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi $ ./configure ${CONFIGURE_FLAGS} $ make $ make install the CONFIGURE_FLAGS is the variable depending on your very-own project. Go to Yocto Training - HOME Go to Task #7 - Create the toolchain

Build the tool chain image. It generates the toolchain that will be installed on your host machine and used to build any source code: $ bitbake meta-toolchain It does take some time to build. Why to create a toolchain? Yocto is not intended to be used to package development. Yocto is a linux distribution creator. It´s intended to be a image builder, a rootfs creator. (please, see more about "what is yocto" here and here) So, yocto itself should not be used to "develop" a new package. Although, Yocto can help creating a environment for development like meta-toolchain or Eclipse ADT. Go HOME Go Task #6 - Customize the image

A tutorial on 'Freescale Yocto Project'. Source code is located here NOTE: When doing 'repo init -u .... -b <LATEST_STABLE_BRANCH_NAME>', make sure you are using the latest stable branch (dora is the latest when writing this note)

Don't forget to update your source code. How to customize the image Enter <yocto>/source and find any image available: $ find -name *image*.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-gui-sdk.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-test.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb ./meta-fsl-demos/recipes-qt/images/qt-in-use-image.bb ./meta-fsl-demos/recipes-qt/images/qte-in-use-image.bb ./meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb ./meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-image.bb ./meta-openembedded/meta-oe/recipes-support/imagemagick/imagemagick_6.7.5.bb ./meta-openembedded/meta-oe/recipes-multimedia/libsdl-image/libsdl-image_1.2.12.bb ./poky/meta-hob/recipes-core/images/hob-image.bb ./poky/meta-skeleton/recipes-multilib/images/core-image-multilib-example.bb ./poky/meta/recipes-devtools/mkelfimage/mkelfimage_svn.bb ./poky/meta/recipes-sato/images/core-image-sato-dev.bb ./poky/meta/recipes-sato/images/core-image-sato.bb ./poky/meta/recipes-sato/images/core-image-sato-sdk.bb ./poky/meta/recipes-qt/images/qt4e-demo-image.bb ./poky/meta/recipes-core/images/core-image-minimal.bb ./poky/meta/recipes-core/images/core-image-base.bb ./poky/meta/recipes-core/images/core-image-minimal-dev.bb ./poky/meta/recipes-core/images/core-image-minimal-initramfs.bb ./poky/meta/recipes-core/images/build-appliance-image.bb ./poky/meta/recipes-core/images/core-image-minimal-mtdutils.bb ./poky/meta/recipes-extended/images/core-image-lsb-sdk.bb ./poky/meta/recipes-extended/images/core-image-basic.bb ./poky/meta/recipes-extended/images/core-image-lsb-dev.bb ./poky/meta/recipes-extended/images/core-image-lsb.bb ./poky/meta/recipes-graphics/images/core-image-directfb.bb ./poky/meta/recipes-graphics/images/core-image-x11.bb ./poky/meta/recipes-graphics/images/core-image-clutter.bb ./poky/meta/recipes-graphics/xcb/xcb-util-image_0.3.9.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2012.04.01.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.03.bb ./poky/meta/recipes-rt/images/core-image-rt-sdk.bb ./poky/meta/recipes-rt/images/core-image-rt.bb The above images (and packages with 'image' in file name) may be used as a base image, where new packages may be added, or example of new images. bitbake -s  shows any *available* package locally. Grep for the name of desired package: $ bitbake -s | grep calibrat calibrateproto                      :0.0+gitAUTOINC+1da6fd1e2c7a49648245c98481fabea8b9690a8c-r2             libxcalibrate                       :0.0+gitAUTOINC+209d83af61ed38a002c8096377deac292b3e396c-r0             xinput-calibrator                   :0.7.5+gitAUTOINC+c01c5af807cb4b0157b882ab07a893df9a810111-r1 For example, the package name is xinput-calibrator, in order to include this package this would be the string needed. The dependency tree is shown with $ bitbake -g fsl-image-test For the fsl-image-test. Or any other image Include the package name on the image definition file. $ cd meta-fsl-demos/ $ vim recipes-fsl/images/fsl-image-test.bb Include the package name on IMAGE_INSTALL list: IMAGE_INSTALL += " \     packagegroup-fsl-gstreamer \     packagegroup-fsl-tools-testapps \     packagegroup-fsl-tools-benchmark \ xinput-calibrator \ " In order to include the package on any image, configure conf/local.conf file the as the following: MACHINE ??= 'imx6qsabresd' DISTRO ?= 'poky' PACKAGE_CLASSES ?= "package_rpm" EXTRA_IMAGE_FEATURES = "debug-tweaks tools-sdk" USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" CONF_VERSION = "1" BB_NUMBER_THREADS = '8' PARALLEL_MAKE = '-j 8' ACCEPT_FSL_EULA = "1" CORE_IMAGE_EXTRA_INSTALL += "xinput-calibrator" And then $ bitbake fsl-image-test In order to add debug or native builder include on conf/local.conf: EXTRA_IMAGE_FEATURES += "tools-sdk" Every image created after that will include development tools. The same may be included in any bb image file. From Poky description: 'tools-sdk" - Adds development tools such as gcc, make, pkgconfig and so forth. "dev-pkg" - Adds -dev packages for all installed packages. This is useful if you want to develop against the libraries in the image. "tools-debug" - Adds debugging tools such as gdb and strace. If you don't like command line, or you prefer a window-like interface, you can take a look on HOB. See hob documentation https://www.yoctoproject.org/documentation/hob-manual See getting started video for hob Introducing Hob - YouTube Go to Yocto Training - HOME Go to Task #5 - Kernel

You already know. Your source code is one week old now, so please, update it (or should I say 'sync' it?)! Get used to update your BSP layers. Recipe Is the name of file that determinates how a package should act. For example, the version, where it is the mainstream repo, how to build, install, link. etc. Kernel For meta-fsl-arm the kernel recipes are under meta-fsl-arm/recipes-kernel/linux (take a look here meta-fsl-arm - Layer containing Freescale ARM hardware support metadata) For meta-fsl-arm, there are 3 kernel recipes: linux-fslc_3.8.bb  --> kernel mainline (from kernel.org) linux-imx_2.6.35.3.bb  --> kernel from FSL, for imx5x and imx28 linux-imx_3.0.35.bb --> kernel from FSL for imx6 Take the linux-imx for imx6 as an example meta-fsl-arm - Layer containing Freescale ARM hardware support metadata The recipe determinates: what´s the compatible machine for this linux version (mx6) what´s the commit ID for the head of this code (SRCREV) (MX6DL and MX6SL have different source code) what´s the patches for the mx6 boards (SRC_URI). In order to see where the source code is cloned from, you need to go to .inc file meta-fsl-arm - Layer containing Freescale ARM hardware support metadata SRC_URI = "git://git.freescale.com/imx/linux-2.6-imx.git \            file://defconfig \ " it´s from git.freescale.com. In addition, there is a defconfig file added on SRC_URI. There is a defconfig file for every board, on every Linux revision. Some defconfigs are shared for more than one board (for example, every mx6 board), and some Linux version are not compatible for some boards (for example, imx53 is only compatible with 2.6.35). During a bitbake linux-imx, a temp folder will be created under build/tmp/armv7-imx6....../linux-imx, with code from git, patches and defconfig. Then bitbake takes that defconfig and configure the kernel, built it, and deploy it. So, in order to change the kernel configuration (make menuconfig) you must replace your defconfig file from meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6 How to change kernel configuration Create the new defconfig Copy it to meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6 (or the right folder for your board/kernel) $ bitbake -c cleansstate linux-imx $ bitbake linux-imx (if you want only the kernel image) $ bitbake fsl-image-gui (if you want to generate a complete image using the new kernel) How to make menuconfig with yocto $ bitbake -c menuconfig linux-imx will generate a config file on tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r33.10/git/.config The complete step by step to change the kernel configuration $ bitbake -c menuconfig linux-imx (change anything) $ cp tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r33.10/git/.config ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6/defconfig $ bitbake -c cleansstate linux-imx $ bitbake fsl-image-gui The uImage will be under tmp/deploy/image In order to replace only uImage binary into one ready sdcard: $sudo cp tmp/deploy/image/uImage-imx6-XXX.bin /media/user/Boot imx6/uImage Kernel Mainline - kernel.org In order to use kernel mainline instead of linux-imx. Please add the following code to your conf/local.conf PREFERRED_PROVIDER_virtual/kernel = "linux-fslc" Make sure the desired board is supported by kernel.org. In order to take and build kernel mainline manually, please see https://community.freescale.com/docs/DOC-95017 Final points It´s not a simple task, I know. Yocto is not the best tool for use to develop and customize kernel during development stage. It is easier to use an external toolchain (bitbake meta-toolchain). Once the kernel development, or customization, is done, the changes can be integrated in the Yocto so it is managed for production use. I like to have a copy of kernel source code cloned on my machine directly from git.freescale.com, then I can re-configure it, rebuild it, apply some patches, make changes, and build it manually - any way I want it. So, I only change kernel using yocto when I know the bug and I know how to fix it, and I have the patch. (and this is the way I like to work) Although this is how to configure (and even patch) kernel (if you want to patch kernel, follow the example in the recipes) If you face any error, please, let me know. I tested the steps and it worked, but I´m using an Ubuntu machine, not a virtual machine (and I´m not sure how -c menuconfig will act in a virtual machine). Go to Yocto Training - HOME Go to Task #4 - Deploy and test

On the build folder, type bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq where <image> is the image name (e.g. core-image-minimal). In case you want to know if a certain <package> is included on an image, just grep the output bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq | grep <package>

The edit-compile-test loop is the quickest way so can test your changes. 1. Go to the package's source code folder and edit your files. 2. Compile that particular package, e.g. bitbake linux-imx -c compile -f 3. Deploy, e.g. bitbake linux-imx -c deploy 4. Insert the SD card into your host, and copy the Linux kernel into the the first partition sudo cp tmp/deploy/images/uImage /media/Boot 5. Insert the SD card into your board, boot and test your changes 6. In case you are satisfied with the results, you need to create a patch and add into the package's recipe. Check this document to execute this step.

Update The source code is one week old now, so please, update it! $ repo sync Images - the result of a bitbake Example of a content after bitbake build_mx6/tmp/deploy/images: fsl-image-gui-imx6qsabresd-20130505174618.rootfs.ext3 fsl-image-gui-imx6qsabresd-20130505174618.rootfs.sdcard fsl-image-gui-imx6qsabresd-20130505174618.rootfs.tar.bz2 fsl-image-gui-imx6qsabresd-20130508162511.rootfs.ext3 fsl-image-gui-imx6qsabresd-20130508162511.rootfs.sdcard fsl-image-gui-imx6qsabresd-20130508162511.rootfs.tar.bz2 fsl-image-gui-imx6qsabresd.ext3 fsl-image-gui-imx6qsabresd.sdcard fsl-image-gui-imx6qsabresd.tar.bz2 modules-3.0.35-1.1.0+yocto+g0596856-r32.10-imx6qsabresd.tgz README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt u-boot.imx u-boot-imx6qsabresd.imx u-boot-imx6qsabresd-v2013.04-r3.imx* uImage uImage-3.0.35-r32.10-imx6qsabresd-20130505174618.bin uImage-imx6qsabresd.bin Get used with generated images. Understand which file is a symbolic link and which one is the image in fact. Symbolic link will always point to latest image. sdcard image Take a look how sdcard is generated here meta-fsl-arm - Layer containing Freescale ARM hardware support metadata The disk layout used is: 0-> IMAGE_ROOTFS_ALIGNMENT    reserved to bootloader (not partitioned) IMAGE_ROOTFS_ALIGNMENT -> BOOT_SPACE    kernel and other data BOOT_SPACE -> SDIMG_SIZE     rootfs Use IMAGE_OVERHEAD_FACTOR to add more space Please, go to original file in order to understand the disk layout. It´s basically some initial space for u-boot. One partition for uImage. One partition for rootfs. The total sdcard size will be calculate for every image, if you want to add more empty space inside generated sdcard, use IMAGE_OVERHEAD_FACTOR. Deploy Deploy the sdcard image: $ sudo dd if=fsl-image-gui-imx6qsabresd.sdcard of=/dev/sdX bs=1M Or, deploy the ext3 rootfs $ sudo dd if=fsl-image-gui-imx6qsabresd.ext3 of=/dev/sdX2 bs=1M Or deploy only the tar.bz rootfs $ sudo mount /dev/sdX2 /mnt/card $ sudo tar xf imagename-imx53qsb.tar.bz2 -C /mnt/card In order to deploy only kernel $ sudo cp uImage-3.0.35-r32.10-imx6qsabresd-20130505174618.bin /media/Boot In order to  deploy only u-boot $ sudo dd if=u-boot-imx6qsabresd-v2012.10-r3.imx of=/dev/sdX bs=512 seek=2 If using HDMI please, modify u-boot environment arguments: setenv mmcargs "setenv bootargs console=${console},${baudrate} root=${mmcroot} rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24" This is the how sdcards are made by meta-fsl-arm. Of course you can use your own. But double check the u-boot bootenv. Plug your sdcard and let the board boot To login: root Go to HOME Go to Task #3 - The build result Go to Task#5 - kernel

Add the above line to conf/local.conf file: PREFERRED_PROVIDER_virtual/kernel = "linux-fslc" Check this page to see what the mainline Linux kernel supports for a particular Freescale board.

You can but building times will take much longer (approximately 2 times longer for the core-image-minimal) compared to a build done on a native machine. In case you can not do the build on a native machine, make sure your virtual has enough hard-disk room (at least 50GB). For example, these are the build folders sizes after baking core-image-minimal: build$ du -h --max-depth=1 1.3G    ./sstate-cache 3.2M    ./cache 12K    ./.hob 32K    ./conf 22G    ./tmp 23G    . The tmp folder is by far the largest (containing building statistics, source code, deployed images, etc.) build/tmp$ tree -L 2 -d . ├── buildstats │   ├── cogl-imx6qsabresd │   ├── fsl-image-gui-imx6qsabresd │   ├── fsl-image-gui-sdk-imx6qsabresd │   ├── mesa-dri-imx6qsabresd │   ├── mesa-imx6qsabresd │   └── pseudo-native-imx6qsabresd ├── cache │   └── default-eglibc ├── deploy │   ├── images │   ├── licenses │   └── rpm ├── log │   ├── cleanlogs │   └── cooker ├── pkgdata │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   └── imx6qsabresd-poky-linux-gnueabi ├── sstate-control ├── stamps │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   ├── work-shared │   └── x86_64-linux ├── sysroots │   ├── imx6qsabresd │   ├── imx6qsabresd-tcbootstrap │   └── x86_64-linux ├── work │   ├── all-poky-linux │   ├── all-poky-linux-gnueabi │   ├── armv7a-vfp-neon-poky-linux-gnueabi │   ├── imx6qsabresd-poky-linux │   ├── imx6qsabresd-poky-linux-gnueabi │   └── x86_64-linux └── work-shared     └── gcc-4.7.2-r13

There are two ways: 1. BitBake. Append the package into the IMAGE_INSTALL variable. But In case you want the package in every image,  add a line to your conf/local.conf file IMAGE_INSTALL_append = " package"           Make sure to include the space BEFORE the package name. You can add other packages, just place spaces in-between. In case you want the package in a particular image, e.g. fsl-image-gui,, add it on meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb IMAGE_INSTALL += " \     ${SOC_IMAGE_INSTALL} \     cpufrequtils \     nano \     packagegroup-fsl-gstreamer \     packagegroup-fsl-tools-testapps \     packagegroup-fsl-tools-benchmark \     packagegroup-qt-in-use-demos \     qt4-plugin-phonon-backend-gstreamer \     qt4-demos \     qt4-examples \     fsl-gui-extrafiles \     package \     " 2. Hob. Due to its graphical nature, adding more packages to a base image is easier than the bitbake way. Run the hob app under the build folder, select your machine and image, then edit the later (click on the Edit image button) In case the package is not available, you need to create it. As a starting point take a look at this example. In case you consider is good enough to be present on the mainstream repos, send the patch to the meta-freescale mailing list.

There are two optionsou 1. Remove all source code after building: You can indicate bitbake to remove all source code after a build adding this line INHERIT += "rm_work" our to your conf/local.conf file. Of course, when baking another image, ALL source code has to be fetched again and it can take a lot of time, specially on machines with low connections to the Internet. The smallest image you can build is core-image-minimal, containing the minimal set of packages to board a particular machine. The largest is fsl-image-gui (in fact, there is one bigger 'fsl-image-gui-sdk' used for developing purposes inside the target). Between these two, there are a lot of images you can choose. You can even create your own image using hob. In case you do not want to build anything, there are some pre-built images on this site, just download the sdcard file and flash it to an SD card. 2. Select only those  IMAGE_FSTYPES you need. There is a variable named IMAGE_FSTYPES  which indicates the output formats you want for the resulting root file system images, by default is has this value: IMAGE_FSTYPES ?= "tar.bz2 ext3 sdcard" and it is located on /sources/meta-fsl-arm/conf/machine/include/imx-base.inc machine's header file. If you want to change it, place this variable on the build/conf/local.conf file. In case you have NFS mounting, remove the 'sdcard' (and either 'ext3' or 'tar.bz2') string, resulting in IMAGE_FSTYPES = "tar.bz2"

1. Follow all instructions from Freescale's github repo except the last bitbake command 2. Run hob under the build folder build$ hob & 3. On the GUI, select machine and image, then build 4. In case you need to flash an SD Card, hob does not produce an .sdcard image, so as a workaround, close hob and on the same console run build$ bitbake <image>     where image must be the same as the one you choose with hob 5. Flash your SD card build$ sudo dd if=tmp/deploy/images/fsl-image-gui-imx6qsabresd.sdcard of=/dev/sdX bs=4M NOTES: In case of building issues, please follow this link In case of booting issues, make sure: 1. board DIP switches are set correctly 2. you have chosen the correct machine before baking If issues persist, report it to the community

You already know. Your source code is one week old now, so please, update it! $ repo sync What was the changes? Please, read the output and determinate what file was changed. Directory tree This is what I have under fsl-community-bsp directory: $ tree -d -L 2 -A . ├── build_mx53 │   ├── conf │   ├── sstate-cache │   └── tmp ├── build_mx6 │   ├── conf │   ├── sstate-cache │   └── tmp ├── downloads │   └── git2 └── sources     ├── base     ├── meta-fsl-arm     ├── meta-fsl-arm-extra     ├── meta-fsl-demos     ├── meta-openembedded     └── poky Sstate-cache keeps the pre-build packages cache so once one package is built, and it´s not changes, no need to re-build it again. If a team shares the same build environment, the sstate-cache folder can be shared as well. I´m not personally used to configure it, so, please, follow the doc: Yocto Project Reference Manual The downloads folder is shared for any build folder. It holds every package´s source code. For example, the ssh source code (and this source code can be built for any architecture) In addition, you may want to share the download folder with your team (one download folder for the complete team), so please, go to Yocto Project Reference Manual and look for DL_DIR. Build_mx6 tree .../build_mx6$ tree -d -L 2 -A . ├── conf ├── sstate-cache └── tmp     ├── buildstats     ├── cache     ├── deploy     ├── log     ├── pkgdata     ├── sstate-control     ├── stamps     ├── sysroots     ├── work     └── work-shared Inside tmp folder you will find images and build results. Images is placed inside deploy. Build statistics like initial and final time for each package/task are under buildstats The complete log for any 'bitbake' you did is under log. Take a look, for example, on the file  log/cooker/imx6qsabresd/11111111111.log. Please, notice that 111111111 is the PID number, so every time you run bitbake you have a different one. The source code, the patches, and the logs for the last bitbake, for each package is under work. Take a look on the files under tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ for example, for the kernel. .../build_mx6$ tree -d -L 1 -A tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ ├── deploy-linux-imx ├── deploy-rpms ├── git ├── image ├── license-destdir ├── package ├── packages-split ├── pkgdata ├── pseudo ├── sysroot-destdir └── temp Go under temp, and see a lot of log.* and run.*: .../build_mx6$ ls tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/temp/ log.do_bundle_initramfs             log.do_uboot_mkimage                run.do_package_write_rpm.28992      run.perform_packagecopy.16364 log.do_bundle_initramfs.28986       log.do_uboot_mkimage.2325           run.do_patch                        run.populate_packages.16364 log.do_compile                      log.do_unpack                       run.do_patch.2556                   run.read_shlibdeps.16364 log.do_compile.3483                 log.do_unpack.1155                  run.do_populate_lic                 run.read_subpackage_metadata.28992 log.do_compile_kernelmodules        log.task_order                      run.do_populate_lic.10988           run.split_and_strip_files.16364 log.do_compile_kernelmodules.29051  run.base_do_fetch.28859             run.do_populate_sysroot             run.split_kernel_module_packages.16364 log.do_configure                    run.base_do_unpack.1155             run.do_populate_sysroot.17692       run.split_kernel_packages.16364 log.do_configure.3048               run.BUILDSPEC.28992                 run.do_qa_configure.3048            run.sstate_create_package.10988 log.do_deploy                       run.debian_package_name_hook.16364  run.do_qa_staging.17692             run.sstate_create_package.16364 log.do_deploy.617                   run.do_bundle_initramfs             run.do_sizecheck                    run.sstate_create_package.17692 log.do_fetch                        run.do_bundle_initramfs.28986       run.do_sizecheck.2323               run.sstate_create_package.2724 log.do_fetch.28859                  run.do_compile                      run.do_strip                        run.sstate_create_package.28992 log.do_install                      run.do_compile.3483                 run.do_strip.2321                   run.sstate_create_package.617 log.do_install.2327                 run.do_compile_kernelmodules        run.do_uboot_mkimage                run.sstate_task_postfunc.10988 log.do_package                      run.do_compile_kernelmodules.29051  run.do_uboot_mkimage.2325           run.sstate_task_postfunc.16364 log.do_package.16364                run.do_configure                    run.do_unpack                       run.sstate_task_postfunc.17692 log.do_packagedata                  run.do_configure.3048               run.do_unpack.1155                  run.sstate_task_postfunc.2724 log.do_packagedata.2724             run.do_deploy                       run.emit_pkgdata.16364              run.sstate_task_postfunc.28992 log.do_package_write_rpm            run.do_deploy.617                   run.fixup_perms.16364               run.sstate_task_postfunc.617 log.do_package_write_rpm.28992      run.do_fetch                        run.package_depchains.16364         run.sstate_task_prefunc.10988 log.do_patch                        run.do_fetch.28859                  run.package_do_filedeps.16364       run.sstate_task_prefunc.16364 log.do_patch.2556                   run.do_install                      run.package_do_pkgconfig.16364      run.sstate_task_prefunc.17692 log.do_populate_lic                 run.do_install.2327                 run.package_do_shlibs.16364         run.sstate_task_prefunc.2724 log.do_populate_lic.10988           run.do_package                      run.package_do_split_locales.16364  run.sstate_task_prefunc.28992 log.do_populate_sysroot             run.do_package.16364                run.package_fixsymlinks.16364       run.sstate_task_prefunc.617 log.do_populate_sysroot.17692       run.do_packagedata                  run.package_get_auto_pr.16364       run.sysroot_cleansstate.3048 log.do_sizecheck                    run.do_packagedata.2724             run.package_get_auto_pr.2327        run.sysroot_stage_all.17692 log.do_sizecheck.2323               run.do_package_qa.16364             run.package_get_auto_pr.617         run.write_specfile.28992 log.do_strip                        run.do_package_rpm.28992            run.package_name_hook.16364 log.do_strip.2321                   run.do_package_write_rpm            run.patch_do_patch.2556 For each package, you will be able to see the log for the latest task, and what was done on the latest task. For example: log.do_compile - shows the log output from latest do_compile made for kernel run.do_compile - shows the compile command line log.do_compile.111111 - shows the log output from 1111111 time of do_compile In order to know the tasks and the task sequence, take a look to log.taskorder file For the images generated, you will find something like that: .../build_mx6$ ls -la tmp/deploy/images/imx6qsabresd/ total 146260 drwxr-xr-x 2 user user     4096 Mar  6 21:21 . drwxrwxr-x 3 user user     4096 Mar  6 21:12 .. -rw-r--r-- 1 user user 67108864 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.ext3 -rw-r--r-- 1 user user 83886080 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.sdcard -rw-r--r-- 1 user user 18782361 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.tar.bz2 lrwxrwxrwx 1 user user       55 Mar  6 21:21 core-image-base-imx6qsabresd.ext3 -> core-image-base-imx6qsabresd-20140306173758.rootfs.ext3 lrwxrwxrwx 1 user user       57 Mar  6 21:21 core-image-base-imx6qsabresd.sdcard -> core-image-base-imx6qsabresd-20140306173758.rootfs.sdcard lrwxrwxrwx 1 user user       58 Mar  6 21:21 core-image-base-imx6qsabresd.tar.bz2 -> core-image-base-imx6qsabresd-20140306173758.rootfs.tar.bz2 -rw-rw-r-- 2 user user   439697 Mar  6 21:12 modules--3.0.35-r37.14-imx6qsabresd-20140306173758.tgz lrwxrwxrwx 2 user user       54 Mar  6 21:12 modules-imx6qsabresd.tgz -> modules--3.0.35-r37.14-imx6qsabresd-20140306173758.tgz -rw-rw-r-- 2 user user      294 Mar  6 21:20 README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt lrwxrwxrwx 2 user user       35 Mar  6 21:16 u-boot.imx -> u-boot-imx6qsabresd-v2013.10-r0.imx lrwxrwxrwx 2 user user       35 Mar  6 21:16 u-boot-imx6qsabresd.imx -> u-boot-imx6qsabresd-v2013.10-r0.imx -rwxr-xr-x 2 user user   297984 Mar  6 21:16 u-boot-imx6qsabresd-v2013.10-r0.imx lrwxrwxrwx 2 user user       53 Mar  6 21:12 uImage -> uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin -rw-r--r-- 2 user user  4042496 Mar  6 21:12 uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin lrwxrwxrwx 2 user user       53 Mar  6 21:12 uImage-imx6qsabresd.bin -> uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin You can access any generated image, the image name ending with the yearmothdaypid (long number) is the real image, and every time your bitbake complete, it generate a new image. The symbolic link points to the latest created image. The .ext3 file is the EXT3 image for the rootfs. (you can copy it directly to SD card using dd: $sudo dd if=core-image-base.ext3 of=/dev/sdb2 ) The .sdcard file is the complete image to be copied to sdcard. It´s u-boot+uImage+rootfs The .tar.bz2 file is the tarball for the rootfs, you can extract it on your PC. uImage is the latest kernel image u-boot is the latest u-boot image. and so on. Play around with generated files. A lot of them I don´t know. And a lot of them I don´t use. For a standard image generation you only need to know where the final images is placed. Any question, comment, issue, please let me know. Before you go, let your bitbake creates the biggest image ever: $ bitbake fsl-image-gui Note (24Feb2014): Required disk space for build image is ~44GB Start it and let it finish while you do something else. Go HOME Go to Task #2 Go to Task#4

NOTE: Please suggest bitbake commands you find it useful! bitbake command Description bitbake <image> Bake an image (add -k to continue building even errors are found in the tasks execution) bitbake <package> -c <task> Execute a particular package's task. Default Tasks names: fetch, unpack , patch , configure , compile , install , package , package_write , and build. Example: To (force) compiling a kernel and then build, type: $ bitbake  linux-imx -f -c compile $ bitbake linux-imx bitbake <image > -g -u depexp Show the package dependency for image. Example: To show all packages included on fsl-image-gui $ bitbake fsl-image-gui -g -u depexp NOTE: This command will open a UI window, so it must be execute on a console inside the host machine (either virtual or native). bitbake <package> -c  devshell Open a new shell where with neccesary system values already defined for package hob bitbake frontend/GUI. bitbake <package> -c listtasks List all tasks for package bitbake virtual/kernel -c menuconfig Interactive kernel configuration bitbake <image> -c fetchall Fetch sources for a particular image bitbake-layers show-layers Show layers bitbake-layers show-recipes "*-image-*" Show possible images to bake. Without "*-images-*", it shows ALL recipes bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq Show image's packages bitbake -g <pkg> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq Show package's dependencies bitbake –v <image> 2>&1 | tee image_build.log Print (on console) and store verbose baking bitbake -s | grep <pkg> Check if certain package is present on current Yocto Setup

NOTES: Empty cells do not mean there is no bitbake parameter for the corresponding ltib one. This is still work in progress. Both engines are completely different and doing a one-to-one comparison is not actually fair. The following tables compare the two core build tools, ltib for LTIB and bitbake for the Yocto Project (YP, hereafter). For YP, there is another important tool called HOB,  when appropriate, we add comments on the Comment's column. There are two main tables, 'ltib modes versus bitbake' 'ltib options versus bitbake'.          We split in two based how ltib splits its parameter, so the order is the same as the one shown when typing './ltib --help'. LTIB comes in every released BSP, follow the User Guide to install it. The command 'ltib' is a script located on the folder with the same name, so all ltib commands should be run with './' as prefix YP can be seen of a series of layers (folders). To download these, including the Freescale layers, follow this link. The command 'bitbake' must be installed independently, you can either use the package manager of you OS (e.g. sudo apt-get install bitbake on Ubuntu) or download the source code and do the setup manually. Both ways should place the bitbake script into a executable path. ltib modes versus bitbake Mode description ltib command bitbake command Comment Just prep the package ltib -m prep -p <package> bitbake <package> -c patch With bitbake when running the patch task, it executes two lower tasks: fetch and unpack. For example, if one wants a untouched (no yocto patches) kernel, one can try: 'bitbake linux-imx -c unpack' and code unpacked code is placed on tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/<version>/git/ rpmbuild -bc --short-circuit ltib -m scbuild -p <package> bitbake <package> -c compile With bitbake running compile also runs a lower task: configure. rpmbuild -bi --short-circuit ltib -m scinstall -p <package> bitbake <package> -c With ltib the install task executes the %Install section of the package's spec. With bitbake the same task executes all related package's recipe install functions, e.g. do_install. Note: with ltib running a higher task (like scinstall) will not execute lower tasks (like scbuild and prep); this is not the case for bitbake: it runs lower tasks automatically. does an scinstall followed by an install to the rootfs ltib -m scdeploy -p <package> bitbake <package> -c build With bitbake, build is the default task, so one can even omit the -c build parameter, e.g. 'bitbake <package>' generate and merge a patch (requires -p <pkg>) ltib -m patchmerge -p <package> NA This is a pretty nice feature from LTIB, unfortunately with bitbake the command does not exit. For example, to patch the Kernel's recipe, take a look at this procedure. In case you follow all these steps to fix a bug, do not forget to send your patch to the community. lean/uninstall target packages ltib -m clean -p <package> NA With bitbake the 'clean' counterpart does not exit. If one needs to remove a specific package from a build, you may remove it from the image configuration file (e.g. file meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb, remove item on IMAGE_INSTALL variable); if package is inside a package group (e.g. ./meta-fsl-demos/recipes-fsl/packagegroup/packagegroup-fsl.bb) you may remove it there. After this change, bitbake again and the resulting image won't have the package. With HOB, this is much simpler due to its Graphical User Interface. Just type hob on your build directory, select the machine and the base image, then click on the 'Edit Image'. On that window you can easily deselect packages. Once deselection is done, build the image. full cleanup, removes nearly everything ltib -m distclean NA With bitbake the 'distclean' command does not exit. The way to remove all the built, remove the build/tmp folder. Be careful, next time you run bitbake, all tasks for all packages will be executed, in other words, you will start from scratch. list packages (alphanumeric) ltib -m listpkgs non-GUI: bitbake -g fsl-image-gui && cat pn-depends.dot GUI: bitbake -g -u depexp fsl-image-gui A bit more complex non-GUI: bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq list package names and licenses ltib -m listpkgseula NA With HOB, you can see every package name name and its licence. Just type hob, then select the machine and image, and click on the 'Edit Image' button. On the 'All recipes' tab, you get a list of packages with their licenses. list packages in twiki format ltib -m listpkgstw NA list packages in a format for import into spreadsheet ltib -m listpkgscsv NA make a binary release iso image ltib -m release NA make a non-distributable test iso release ltib -m trelease NA configure selected platform (no build) ltib -m config NA There is no way to open a configuration menu with bitbake. Instead, you can use hob. With hob, things are much easier. Just type hob under the build folder and you can select the machine and the image. If the image you want does not fit to the ones already available, you can add packages manually and even store your new tuned image. NOTES: 1. On YP, an image is a similar concept as LTIB's package profile (usually called just profile). There are many predefined images which can be used as starting point, so type 'bitbake <image name>'. 2. In case the kernel needs to be configure, run 'bitbake linux-imx -c menuconfig'. sub-platform selection (no build) ltib -m selectype NA The selectype on LTIB opens two menus: 1. Platform and the Package Profile selection 2. Configuration menu (the same menu as the one shown with -m config). In case one needs to do execute just the first task, just run 'bitbake <image name>'. In case you need to execute both, run hob. enter ltib shell mode (sets up spoofing etc) ltib -m shell bitbake <package name> -c devshell import srpms into ltib (semi-automatic) ltib -m addsrpms ltib options versus bitbake Option Description ltib command bitbake command Comments Root context number (0 is the primary and implicit) ltib --rootn | ltib -R operate on this package only ltib --pkg | ltib -p bitbake <package> With bitbake there is no need to add a '-' parameter, just use the package name without the .bb extension run the interactive configuration and build ltib --configure  | ltib -c NA See the mode -m config for more info run the sub-platform configuration and build ltib --selectype NA See the mode -m selectype for more info configuration file to build from (defaults to .config) ltib --preconfig bitbake <predefined image> With bitbake use any of the predefined images (assuming that these have not been modified), e.g. bitbake core-image-minimal or bitbake fsl-image-gui (it happens to be the smallest and the largest image, in terms of number of packages) profile file.  This is used to select an alternate  set of userspace packages, this is saved and used on later runs of ltib (e.g config/profiles/max.config) ltib --profile use this resource file ltib --rcfile <f> | ltib - r <f> batch mode, assume yes to all questions ltib --batch | ltib -b force rebuilds even if they are up to date ltib --force | ltib -f bitbake --force | bitbake -f For example, to force recompiling the kernel: bitbake linux-imx -c compile -f re-install rpms (but don't force rebuild) ltib --reinstall | ltib -e bitbake <package name> -c install -f remove (erase) rpm ltib --erase | ltib -E turn off install/uninstall dependency checks ltib --nodeps | ltib -n bitbake -b <somepath/somefile.bb> For example, to build just the kernel (no dependencies, just kernel): bitbake -b ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.0.35.bb NOTE: ALL dependencies should be already be installed, otherwise the command will fail don't force install rpms that have file conflicts ltib --conflicts | ltib -k keep the srpms after the build (deleted by default) ltib --keepsrpms | ltib -s more output ltib --verbose | ltib -v bitbake --verbose | bitbake -v On YP, the log can be too verbose, so one way to handle the amount of log is to store it and then grep it: bitbake linux-imx | tee log; grep -i <your string to seach> < log mostly a dry run (calls to system are just echos) ltib --dry-run | ltib -d bitbake --dry-run | bitbake -n try to continue on package build errors (autobuilds) ltib --continue | ltib -C bitbake --continue | bitbake -k print the application version and quit ltib --version | ltib -V bitbake --version do not redirect any output ltib --noredir | ltib -N run the deploy scripts even if build is up to date ltib --deploy | ltib -D bitbake <image name> -f disabled deployment (even with -p <pkg>) ltib --no-deploy just download the packages only ltib --dlonly bitbake -c fetchall <image name> E.g. bitbake -c fetchall core-image-minimal test that the BSP's packages are available ltib --dltest check against external staging repositories ltib --external leave the sources unpacked (only valid for pkg mode) ltib --leavesrc | ltib -l NA This is the default mode in YP. All source code can be found on tmp/work. In case you want to remove source code after building (as in LTIB), add INHERIT += "rm_work" to your local.conf. NOTE: If your adding changes to a particular package, these will be lost. In case you want to keep source code of a specific package, include this on the RM_WORK_EXCLUDE variable (e.g. RM_WORK_EXCLUDE += "busybox eglibc"). Make the selected root number sticky --sticky Remove root stickiness --no-sticky (re)configure/build/install the host support package set --hostcf use with package listings --enable use if you really want to ignore any locks (careful!) --ignorelock used with -m release to copy additional content --fullbsp used with -m release to copy specical packages into ISO --distmap don't check sudo, work around for broken sudo (fc9) --no-sudo use git for some package's build where use-git-mode is either: internal    Use fsl internal git external   Use fsl external git --use-git-mode use external git for some package's build --external-git help on usage --help | -h --help | -h

1. Increasing the number of threads. Make sure the Parallelism variables located on conf/local.conf BB_NUMBER_THREADS: indicating how many task bitbake should run in parallel PARALLEL_MAKE: indicating how many processes make should run in parallel are not commented and with correct values. The script  setup-enviroment  automatically sets these equal to the number of CPU cores. You can double this value if you want but there is no significant speed's gain. 2. Having a local repository on the server. When baking an image, one of the first steps for each recipe is to fetch the source code (from git repos, tarballs, etc); it makes sense to reuse this data for future builds and also share it with other server's users. You can indicate bitbake to look first at a local repo (file://) on your conf/local.conf file SOURCE_MIRROR_URL ?= "file:///opt/yocto/download/" INHERIT += "own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1" # BB_NO_NETWORK = "1" Just make sure the download folder has read access for all users (chmod a+r /opt/yocto/download/)

Yes. The Yocto Project site hosts some of the MX machines here. NOTES: If the machine's folder is present but it is empty, a building error may have occurred. Check the build's status for the machine on the archives or send an email to the list. Due to limited resources, not all (Freescale) machines are (nightly) built, in case you need one of these, you need to bake it yourself. You can start building following these instructions.

1. When reusing the build directory, sometimes compilation errors are seen; to overcome these, a fast solution is to clean the Share State Cache of the particular recipe/package $ bitbake <name of the recipe> -c cleansstate 2. Re-run the recipe $ bitbake <name of the recipe> 3. Re-run the bitbake command you were running, before getting into trouble. For example: $ bitbake fsl-image-gui In case the problem persists, please send the log into the mailing list or check if this issue has been reported previously.