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
Related
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.
I want to create am minimal Linux system. I have compiled the kernel myself, but I want to use Yocto to build my rootfs. How can I build the smallest possible rootfs to startup and system and open a shell without building the kernel? Also, how can I choose the type of rootfs? I'd like it to be initramfs so I can then embed it in my kernel image.
Without more details both questions would require very long answers. Luckily the Development Manual covers the issues: See Building a tiny system and Building an initramfs image. I would suggest starting with those and asking more specific questions if needed.
I have a custom board with imx6dl chip and peripherals. I have compiled u-boot, zImage and rootfs from examples provided by manufacturer. But when i try to build yocto from git repo with latests releases, it fails to run (some drivers not working, board is loading and display interface, but touchscreen is not working for ex.),
Is there any way to include precompiled binaries zImage, u-boot and device table to bitbake recipes? I'm very new to yocto project, and only need to get bootable image with working drivers and qt5.
If you have a working boot chain (e.g. u-boot, kernel and device tree) that you have built out-of-yocto, then you might try building a rootfs only. This requires two main settings, to be made in your local.conf to get started. Please don't firget that this is just a starting point, and it is highly advised to get the kernel/bootloader build sorted out really soon.
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy to have no kernel being built, and something like MACHINE="qemuarm" to set up an armv7 build on poky later than version 3.0. The core-image-minimal target should at least be enough to drop you in a shell for starters, and then you can proceed from there.
Additionally, it might be qorth asking the board vendor or the yocto community (#yocto on the freenode server) if they know about a proper BSP layer. FSL things are quite nicely supported these days, and if your board is closely related to one of the well-known ones, you've got a high chance that meta-freescale just does the trick nicely.
Addition:
#Martin pointed out the mention of Qemu is misleading. This is just the easiest way to make Yocto build a userland for the armv7-architecture which the imx6dl is based on. The resulting root filesystem should be sufficiently compatible to get started, before moving on to more tuned MACHINE configuration.
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.
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