i.MX Yocto Project: ltib versus bitbake

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Yocto Project: ltib versus bitbake

i.MX Yocto Project: ltib versus bitbake

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 packageltib -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-circuitltib -m scbuild -p <package>bitbake <package> -c compileWith bitbake running compile also runs a lower task: configure.
rpmbuild -bi --short-circuitltib -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 rootfsltib -m scdeploy -p <package>bitbake <package> -c buildWith 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 packagesltib -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 everythingltib -m distcleanNAWith 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 licensesltib -m listpkgseulaNAWith 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 formatltib -m listpkgstwNA
list packages in a format for import into spreadsheetltib -m listpkgscsvNA
make a binary release iso imageltib -m releaseNA
make a non-distributable test iso releaseltib -m treleaseNA
configure selected platform (no build)ltib -m configNA

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 selectypeNAThe 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 shellbitbake <package name> -c devshell
import srpms into ltib (semi-automatic)ltib -m addsrpms

ltib options versus bitbake

Option Description
ltib commandbitbake commandComments
Root context number (0 is the primary and implicit)ltib --rootn | ltib -R
operate on this package onlyltib --pkg | ltib -pbitbake <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 buildltib --configure  | ltib -cNASee the mode -m config for more info
run the sub-platform configuration and buildltib --selectypeNASee the mode -m selectype for more info
configuration file to build from (defaults to .config)ltib --preconfigbitbake <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 fileltib --rcfile <f> | ltib - r <f>
batch mode, assume yes to all questionsltib --batch | ltib -b
force rebuilds even if they are up to dateltib --force | ltib -fbitbake --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 -ebitbake <package name> -c install -f
remove (erase) rpmltib --erase | ltib -E
turn off install/uninstall dependency checksltib --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 conflictsltib --conflicts | ltib -k
keep the srpms after the build (deleted by default)ltib --keepsrpms | ltib -s
more outputltib --verbose | ltib -vbitbake --verbose | bitbake -vOn 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 -dbitbake --dry-run | bitbake -n
try to continue on package build errors (autobuilds)ltib --continue | ltib -Cbitbake --continue | bitbake -k
print the application version and quitltib --version | ltib -Vbitbake --version
do not redirect any outputltib --noredir | ltib -N
run the deploy scripts even if build is up to dateltib --deploy | ltib -Dbitbake <image name> -f
disabled deployment (even with -p <pkg>)ltib --no-deploy
just download the packages onlyltib --dlonlybitbake -c fetchall <image name>E.g. bitbake -c fetchall core-image-minimal
test that the BSP's packages are availableltib --dltest
check against external staging repositoriesltib --external
leave the sources unpacked (only valid for pkg mode)ltib --leavesrc | ltib -lNA

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
Labels (1)
Comments

Leo, that´s why I like to work with you! You are so nice =D

My points:

* You table is SUPER and I think it MUST be used (period)

* We can introduce the table with your sentence:

"both engines are completely different and doing a one-to-one comparison is not actually right, but see the table below"

What do you think?

or say "fair" instead of "right" :smileysilly:

Sure Daiane, I agree with you, that phrase must be placed at the top of the doc.

ow. I just remembered one thing.

Adrian said me some time ago that the correct is use "Yoctoproject"

https://www.yoctoproject.org/sites/yoctoproject.org/files/11611_yocto_project_style_guide_070912_1.p...

I´ve been making this mistake all my life O.O

As your document is not published so far, try to keep the right standard :smileygrin:

yeah! i like leo too. his post fix some confusions of mine!

No ratings
Version history
Last update:
‎05-27-2013 02:01 PM
Updated by: