I am currently working on Yocto, want to integrate xvisor hypervisor into Yocto.
I wrote a recipe for xvisor, but how can I tell to the system like I am doing for
linux and uboot using PREFERRED_PROVIDER_virtual/kernel and PREFERRED_PROVIDER_u-boot
I tried with PREFERRED_PROVIDER_virtual/xvisor, but it is not taking.
How to compile the code, i.e do_compile()
According to Yocto Documentations PREFERRED_PROVIDER's usage is as below.
If multiple recipes provide an item, this variable determines which recipe should be given preference.You should always suffix the variable with the name of the provided item, and you should set it to the PN of the recipe to which you want to give precedence.
You simply cannot use PREFERRED_PROVIDERS_virtual/xvisor unless meta-virtualization layer is added.
If you want to add hypervisor support, you have to use meta-virtualization layer in your yoctobuild.
Reference to start with
Related
in yocto imagebuildscripts there is a config variable named "IMAGE_FEATURES" i want to create a custom Imagefeature.
I searched my yocto installation which runs poky for existing imagefeatures but i wasn't able to find it.
IMAGE_FEATURES is a bit special, as its basically being hardcoded into image.bbclass.
Generally you are way better off creating custom DISTRO_FEATURES, and triggering on them whereever needed. See packagegroup-core-boot as an example of a recipe changing behaviour based on DISTRO_FEATURE in various places.
Usage wise there is little difference, the only thing you can't do is set DISTRO_FEATURES in the image recipe. If that is your actual need, then you probably should pour the new functionality in a custom image class the includes and extends image.bbclassm and call it myimage.bbclass (or similar).
EDIT:
Initially, I referred to the dropbear recipe as an example that triggers behaviour based on systemd being set as DISTRO_FEATURE. This is technically correct (and it was the first recipe that came to my mind), but probably confusing as there is a dropbear spedific IMAGE_FEATURE too.
I'm trying to build my own yocto_meta-layer based on the imx6ulevk and in ./meta-fsl-bsp-release/imx/meta-sdk/conf/distro/include/fsl-imx-preferred-env.inc I found something weird:
PREFERRED_PROVIDER_virtual/kernel_mx6ul = "linux-imx"
PREFERRED_PROVIDER_virtual/kernel_mx6sll = "linux-imx"
PREFERRED_PROVIDER_virtual/kernel_mx7 = "linux-imx"
So i was wondering what does the last *_word (i.e. PREFERRED_PROVIDER_virtual/kernel_*) means?
a) Does it is a way to set a virtual/kernel parser depending on the machine?
b) If [a] is yes, how do i know which name to put? or what part of the machine_name.conf i need to choose?
PREFERRED_PROVIDER_<recipe-name>_<machine-name> means this variable applies to mentioned recipe AND the respective MACHINE only. This is a common sighting in distro layers. In this particular case, the freescale layer is telling bitbake which Linux kernel recipe to choose depending on the MACHINE you either set in local.conf or pass via command line. More info here.
So the answer to a) is yes.
The answer to b) is that you should not bother with changing the PREFERRED_PROVIDER for the Linux kernel unless you really know what you're doing (i.e, writing a kernel recipe from scratch). Even if you have a custom board you're unlikely to change the virtual/kernel provider. You'd likely want to follow the BSP maintainer's recommendation. What you need to do is set a proper MACHINE, and the bitbake will take care of the rest.
For example if your MACHINE is mx6ul, invoking bitbake virtual/kernel is the same as bitbake linux-imx. The former is best practice, as you call that in Yocto regardless of the machine.
I'm afraid reading the docs is the best way to fully grasp Yocto. The good thing is that it's documented really well. You'd probably want to start from the development manual and the bitbake link above, before diving into the mega manual.
The suffix underscore '_' followed by a string means that the variable, PREFERRED_PROVIDER_virtual/kernel in this case is "overridden". bitbake will use this assignment when the OVERRIDES variable contains that particular string, such as "imx6ul".
Many times, if not all, the SoC architecture is set in the MACHINEOVERRIDES variable in the machine.conf, to define what the SoC is on the board. That consequently gets assigned to OVERRIDES in some yocto/bitbake recipe elsewhere.
The Conditional Syntax (Overrides) section in the bitbake manual [1] specifically talks about how this affects the variable expansion.
a.) If we were being strict with the terminology used by Yocto, it would be no. The "machine" per-se correlates to a board, such as "imx6ulevk". The overrides you have there more generally pertain to an SoC architecture (a chip). You may have many boards running the imx6ul for example. In this case it would pertain to all "machines" running that particular SoC (as defined by your machine in MACHINEOVERRIDES).
b.) Anything appearing in the colon delimited OVERRIDES variable is fair game. You can use the machine name because Yocto does in fact append the MACHINE name to it as well. But it doesn't really make sense to do that because you have a dedication machine.conf file for you to make a hard definition such as PREFERRED_PROVIDER_virtual/kernel = "something" if you really want a machine/board specific kernel selection. NXP did this in their distro layer to apply to many machines (aka boards) all at once.
Hint: to see what these variables expand out to, run bitbake -e virtual/kernel
These overrides are one of the most powerful features of bitbake. For example if you want to override the source revision of you linux-imx kernel build you can put something like SRCREV_pn-linux-imx = "something" in your local.conf. See if you can grep the recipe sources to find out how this works!
References:
[1] https://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#conditional-syntax-overrides
I have a custom layer in project. This gets shared with colleagues.
My distro (poky) it uses a older version of alsa. This gets downloaded on initial setup of the build area. I would like to 'replace' that version of alsa with a later version and do this within my custom layer, so that they don't have to edit/replace recipes in poky.
What's the best way to do this? If I just download the newer recipe and include it in my layer (matching the file system names) will it automatically use the later version or is there something else I need to do?
The way you proceeded is the right way, you should add new recipes/bbappend files on your own layer(s), you shouldn't modify Yocto's base layers nor third-party layers by default. Nevertheless, since you want to add a newer version of an existing recipe, you should keep in mind that:
You have to check the priority of your own layer and the priority of the layer that contains the original recipe. Yocto will pick the recipe of the higher priority layer, no matter if it is a newer version or not (ignoring PV). For further information, search for BBFILE_PRIORITY in the Yocto Project Reference Manual. (You can also see a list of all configured layers along with their priorities with the command bitbake-layers show-layers)
In the case of both layers having the same priority, Yocto will build the recipe with the highest PV (you can check/set this value inside your recipe or in its filename recipename_pv.bb). Alternatively, if you wish to select another version rather than the one that is being currently built, you can just set the variable PREFERRED_VERSION_recipename = desiredPV in your distro.conf or local.conf file.
I have a working Yocto build system based on the rocko branch that is generating images for an ARM-based target board. One of the chips on this board is a small ARM-based micro-controller that is separate to the main CPU. It needs to be loaded with a firmware image that I have to build.
It would be easy to make a recipe to build this microcontroller firmware. It requires an ARM cross compiler and then some special compiler options to control the code generation (for cortex-m4 + thumb etc). The trouble is, if I setup a normal recipe, it will assume that I'm building something for the target ARM architecture, which is a different type of ARM needing different code generation options. I can of course have the firmware Makefile override the cross-compile environment that is provided for the target system and have the Makefile just produce the binary firmware image.
But this will result in a package that is nominally for the target ARM architecture, but which contains a binary blob intended to be flashed onto a chip on the target board.
So my question is, how should I make a recipe for firmware that will execute on a totally different architecture to the MACHINE that the yocto build is ultimately for?
It seems like I need to create a recipe that builds specially for the micro-controller and is therefore different in some way to normal target recipes.
Multiconfig may help you. One of the use case is that you want to build image for board which consists of FPGA and ARM core, this is somehow similar to your use case.
Quoting release notes of morty (2.2), it was introduced there:
Basic support for multi-configuration builds. For example, this enables building for more than one MACHINE at a time, which may be useful if you have a board with two separate SoCs on it, each with their own OS, but you want to target both in the same build.
I didn't try it yet, but the documentation for rocko is here: https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#platdev-building-targets-with-multiple-configurations
You basically define two machine configuration files, define them in BBMULTICONFIG variable and run bitbake with multiconfig:<configuration>: prefix for target when needed.
You need to create a bbclass, that will change the necessary variables for you, and inherit it in your recipe. Let's take as an example nativesdk.bbclass. Your newarch.bbclass file will look something like:
CLASSOVERRIDE = "class-newarch"
PACKAGE_ARCH = "newarch"
PACKAGE_ARCHS += "newarch"
TARGET_ARCH = "newarch"
TARGET_CC_ARCH = "newarch"
TARGET_LD_ARCH = "newarch"
TARGET_AS_ARCH = "newarch"
TARGET_CPPFLAGS = "..."
TARGET_CFLAGS = "..."
TARGET_CXXFLAGS = "..."
TARGET_LDFLAGS = "..."
CPPFLAGS = "..."
CFLAGS = "..."
CXXFLAGS = "..."
LDFLAGS = "..."
I have some images that are only relevant on a particular platform (let's say some are only for intel core and others are only for sabrelite).
Is it possible that the image automatically sets the MACHINE variable for the build, independently of the local.conf ?
If not, can I at least make the image refuse to build for other machines ?
I tried to do some googling but of course "yocto image selects machine" or similar requests only return generic Yocto tutorials.
Thanks.
No, an image can't influence which machine you're building for.
Background: In OpenEmbedded the concepts of a machine, an image, and a distro iare supposed to be orthogonal to each other. I.e. any image should be buildable for any combination of distro and machine. (Of course, that might not always be true in practice though).
You can make the image refuse to build by setting
COMPATIBLE_MACHINE = "macha"
in your image recipe.
Another idea, if the images are pretty similar, would be to only install the machine specific packages if the image is being built for the correct machine. This can easily be done by:
IMAGE_INSTALL_append_macha = " package1 package2"
Note the leading space in the string. (_append doesn't prepend your string with a space).
This latter part, is what is normally done. Restricting an image to a particular machine is something that's rarely done, at least in public layers.
Note: macha is the imagined name of the machine.
To add packages depending on machine, you could use the python function base_contains or base-conditional. E.G. bitbake-how-to-add-package-depending-on-machine
There is COMPATIBLE_MACHINE = " " for input in the recipe to check for compatible machine.
building-yocto-image-for-dragonboard-410c-how-to-build-chromium