What is Bitbake and Poky? - yocto

Can someone please briefly explain what is Bitbake, Poky, Recipes in simple words? I just want a basic understanding of what these are. Thanks.

Let's create a simple relationship of Bitbake, poky and recipes.
Poky is the Yocto Project reference system and is composed of collection of tools and metadata. Poky is platform-independent and performs cross-compiling, using Bitbake Tool, OpenEmbedded Core, and a default set of metadata. The main objective of Poky is to provide all the features an embedded developer needs.
Bitbake is a task scheduler that parses Python and Shell script mixed code, which we called Recipes. The code parsed generates and runs tasks. They are a set of steps orders according to the code's dependencies.
Metadata is where all the Recipes are located. Metadata is composed of a mix of Python and Shell Script text files. Poky uses this to extend OpenEmbeddded Core, meta-yocto, and meta-yocto-bsp
Sources: Embedded Linux Development with Yocto Project by Otavio Salvador and Daiane Angolini

Bitbake is a generic task execution engine that allows shell and Python tasks to be run efficiently and in parallel while working within complex inter-task dependency constraints. More details: what is bitbake
Poky provides an open source, full-platform build tool based on Linux, X11, Matchbox, GTK+, Pimlico, Clutter, and other GNOME Mobile technologies. Poky is primarily a platform builder that generates filesystem images based on open source software. More details: what is poky
Recipes (.bb files) are fundamental components in the Yocto Project environment. Each software component built by the OpenEmbedded build system requires a recipe to define the component. More details: how to create a recipe

Related

Yocto deploy Debug or Release prebuild?

I am writing a bitbake recipe to deploy a third party pre-built tool, similar to this wiki page: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
However, I have a Release and Debug pre-build versions of the tool available as *.so files. How do I distinguish inside the recipe which one of both build types I shall deploy?
Thanks and regards,
Martin
You can have two different virtual recipes each with their own .so file. This then warrants a selection in a configuration file (with PREFERRED_PROVIDER_virtual/my-recipe), so either in a machine or distro configuration file. This is probably preferred if you consider having release and debug distros.
A second option is to install the libraries in two different paths, in two different PACKAGES (use FILES_my-package for that) and make them RCONFLICTS_my-package each other to be sure they can't both be in the rootfs. After that, you could write a pkg_postinst_my-package() task specific to each package that actually move the library from the "different" path to the intended one. This will be run both at build time when creating the rootfs and at runtime on first boot, so you need to make sure to exclude one or the other (it's usually done by checking if ${D} exists, which does at build time but not runtime).
c.f.: http://docs.yoctoproject.org/dev-manual/dev-manual-common-tasks.html#post-installation-scripts
If you can manage to have both libraries installed in your rootfs and select the one you want with the LIBRARY_PATH environment variable, a simple recipe, with two packages with each library in a different location, will be sufficient.

recipe also produces -native output that needs packaging

I have a recipe which successfully invokes a legacy build command to cross-compile a target.
As a side effect it produces some custom native tools that are used in the build.
I want to reap those tools into a -tools-native package to allow other recipes to depend the main package to access the artifacts, and use the -tools-native package to further process those artifacts.
I can build such a native package as simply as adding:
PROVIDES = "${PN} ${PN}-tools-native"
SYSROOT_DIRS += "/"
PACKAGES += "${PN}-tools-native"
FILES_${PN}-tools-native += "/native-bin/*"
and having the install section install the native tools to /native-bin/
but yet it somehow isn't a real native package, and when DEPENDS'd by an additional recipe the native-bin artifacts are installed inrecipe-sysrootinstead ofrecipe-sysroot-native`
I also have to install the tools 0644 or bitbake tries to strip them (and fails, as they are native build).
Because the native tools are already generated by the legacy build commands, I don't need to actually invoke as a -native recipe variant.
It's a long process, I don't want to run it twice, either.
Currently I work around it by having the other recipes DEPEND on recipe-native-tools and fixup the permissions and PATH
But what's the proper way to do this?
This is generally handled by separate recipes. There is no mechanism to share native binaries from target recipes as their task hashes have the wrong kinds of information in them (they change depending on the target architecture).
Target recipes don't install their bindir/sbindir into the sysroot since we can't run them and as you mention, they're the wrong architecture so they confuse strip and so on.
You could try having a native recipe which depended upon this target recipe and which installs the binaries saved by the target recipe somewhere into its ${D} at do_install. That may well give some warnings since in general native recipes shouldn't depend on target recipes but is probably your best option if you can't build twice.

How to use a different compiler for single recipe?

I am building a yocto image for a multicore MCU (A7 + M4). The U-Boot and Linux run on A7. M4 is used for some real time operations.
Currently I am building the M4 part (cmake project) first and bitbake only adds the binary file to the image. What I want to do is to integrate the M4 build into the yocto build process. For this I need to specify a different compiler for the M4 recipe but I can't find any way to do it.
After reading yocto manual I think that writing custom do_compile method should work. But I guess there should be some way to use the existing cmake builder.
I think the multiconfig feature is the one you want, as long as both variants have their own MACHINE definition:
https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#dev-building-images-for-multiple-targets-using-multiple-configurations

Library built but not part of rootfs

I have built images using yocto(core-image-minimal). I need "libtinfo" library to run my application, but it is not part of rootfs.
I could see the library was built and available under "cortexa7hf-neon-poky-linux-gnueabi" folder, but it is not available in rootfs. I have added using IMAGE_INSTALL_append.
My doubt here is, if the library is not required for rootfs(core-image-minimal) then it should not built.
Why the yocto built that library? similar behavior was observed with libudev library also.
Before answering your question, if you have an application which depends on "libtinfo" and your application is also build using yocto (say sample_app.bb), then you should use
DEPENDS += "libtinfo"
RDEPENDS_${PN} += "libtinfo"
This will instruct yocto to include the library in rootfs as your application needs it for runtime.
My doubt here is, if the library is not required for
rootfs(core-image-minimal) then it should not built.
Assume you have source for a package which produces binary and also library i.e for example source for kmod produces libkmod and also modprobe, insmod, rmmod. In such cases recipes are written in such a way to produce two different package (based on configuration you can see *.rpm or *.ipk) files i.e kmod_*.ipk/rpm and libkmod2_*.ipk/rpm.
Based on your real requirement of application you can either use kmod or libkmod in RDEPENDS.
In your case, libtinfo is build inside ncurses package which may not be required in rootfs by any package.
Why the yocto built that library? similar behavior was observed with
libudev library also.
By default the recipe for the source component ncurses or systemd includes the configuration (do_configure) for libtinfo and libudev respectively. But it is not included in rootfs, as none of the software needs it during runtime.
You can always check the dependency graph using
bitbake -g <recipe name>
as mentioned here.

Building modules with linux kernel for custom flavor

I followed the instructions given in the link: http://blog.avirtualhome.com/how-to-compile-a-new-ubuntu-11-04-natty-kernel/ for building a custom kernel and booting it. Everything works fine, except that when building it, I used the option skipmodule=true (as given in this link), so I guess the modules are not built for this kernel. So I have two questions:
How do I build only the modules for my flavor, now that I have the rest of the kernel built? 'make modules' will build it for generic flavor only, if I'm not wrong.
Also does it require me to build the entire kernel source, 'fakeroot debian/rules binary-i5' (i5 is my custom falvor), each time I make a change to one of my modules?
Thanks.
1) To build a linux kernel module for a specific kernel from the module source directory do:
make -C {path-to-kernel-source} M=`pwd` modules
The -C option tells is used to point to the kernel source tree where it finds the kernel's top-level Makefile. The M=`pwd` option points it to the module source directory, where it builds the 'modules' target.
2) Nope, its not necessary to build the source kernel. Either having the kernel source tree or the kernel headers suffice.