I would like to include the following recipe in a non quemu image through a bbappend file. How do I override the
SRC_URI_append_quemuall?
https://github.com/ExorEmbedded/yocto-poky/blob/exorint/meta/recipes-connectivity/connman/connman-conf.bb
Thanks in advance!
Well if you really want those two config files in your image, for a non-qemu machine, the best would be to add a bbappend in your own layer, and just copy the two SRC_URI lines there. And while copying, remove _append_qemuall.
Though, it's quite likely that you also should supply your own versions of those configuration files in that layer.
copy your recipe name and open vi meta-yogurt/recipes-images/your-image-name
add recipename recipename-dev
if you have .so , .a libs for rootfs then addd " recipename-staticdev " also
Related
I use Yocto Zeus to build an embedded Linux for my board. So far I need to replace the /etc/ssh/sshd_config with my custom one.
Unfortunately I couldn't find any useful information about that. Just found some help on the Internet.
I've created a custom layer and add an recipe as following:
sources
mylayer
mylayer-recipes
recipes-connectivity
openssh
openssh_%.bbappend
openssh
sshd_config
openssh_%.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://sshd_config"
after this I've try to rebuild the image
bitbake core-image-minimal
But nothing happens. No error and no change of the sshd_config file in the image.
What I do wrong? Actually I only want to replace the system /etc/ssh/sshd_config with the custom one, nothing else.
Ok, I've finally solved the issue. It's turned out that I haven't follow the full path to the *.bb but only the top level although the doc says "...This implies that you must have the supporting directory structure set up that will contain any files or patches you will be including from the layer." in the 5.1.5. Using .bbappend Files section. So the final folders structure looks like this:
sources
mylayer
mylayer-recipes
openssh
openssh_%.bbappend
openssh
sshd_config <----- the file that replaces the original one
poky
recipes-connectivity
openssh
openssh_8.0p1.bb
openssh
sshd_config <----- the original file
....
i.e. I just added folder openssh to mylayer-recipes folder and now that works as expected
How can i include a pre-built binary file into buildroot generated image?
I have tried to include the binary file into appropriate folder in build_dir but every time i try to do make the image is being created without the file.
You can use a root filesystem overlay.
See chapter Project-specific customization in the Buildroot manual.
Just in case someone is looking for a easy fix you can add the files to buildroot-dir/files folder. The file should match the exact directory structure. For example you want to put the file in /usr/bin in the image then keep the file in buildroot-dir/files/usr/bin and rebuild the image.
I'm new to yocto. I'm trying to learn how the packages are added, how to create new layers and so on... just poking around. Started by cloning poky and playing around.
To my understanding, the bblayers.conf file is critical to the project configuration and what you end up building (what layers and packages go into your final image).
This might be the wrong assumption, but I also have a feeling that the build/ folder is where things you build (bitbake) stay. Images, lots of things needed to build them, a big cache of stuff... You can delete it and rebuild it if you somehow broke it. Or you can just copy everything without the build/ folder and continue working on a different computer.
Apparently it's not quite the case. The build/conf/ folder has the important .conf files like the bblayers.conf.
Can someone explain why is this the case? Is there an elegant way to separate the project config and the build folder?
There are a couple layers to the Yocto Project, mainly:
-BSPDIR: TOPDIR (build),sources,setup-environment
-BSPDIR/setup-environment: initial all the variable to for bitbake;
-BSPDIR/sources: meta-data/
-TOPDIR: conf/ sstate-cache/ cache/ tmp/ downloads/
-TOPDIR/downloads: recipe fetched packages;
-TOPDIR/conf/ : stored all the configuration. Mainly bblayers.conf, local.conf, sanity_info;
-TOPDIR/conf/bblayers.conf: stored all the path to meta-data that will be loaded;
-TOPDIR/conf/local.conf: configuration to build
-TOPDIR/conf/sanity_info: path double check to make sure that all the path used in the last compile match the current compile;
-TOPDIR/tmp/: Where all the compiling and building work happen
In BSPDIR/sources/poky/meta/conf/bitbake.conf
sources/poky/meta/conf/bitbake.conf:TMPDIR ?= "${TOPDIR}/tmp"
sources/poky/meta/conf/bitbake.conf:PERSISTENT_DIR = "${TOPDIR}/cache"
sources/poky/meta/conf/bitbake.conf:DL_DIR ?= "${TOPDIR}/downloads"
sources/poky/meta/conf/bitbake.conf:SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
TOPDIR is where you initialize when run setup-environment or oe-init-build-env; All the other bitbake configuration environment variable can be changed based on your need in conf/local.conf;
e.g. modify conf/local.conf to change the downloads directory from TOPDIR/downloads;
DL_DIR ?= "/home/downloads/"
To create new layer, please watch this video: https://www.youtube.com/watch?v=3HsaoVqX7dg
You might have followed the Yocto Project Quick Start Guide.
The earliest step in yocto after installing (cloning git repositories and installing packages) is to create your OE (OpenEmbedded) environment, which is done via:
source oe-init-build-env
This automatically creates and leads you to the build folder.
Matter that you can give any directory of your system as parameter for this call (Reference Manual - Build Overview):
source oe-init-build-env [build_dir]
⤑ This is also the step, where your 'project config' is separated from the actual build folder.
⤑ As you assumed, in practice you would at most copy the layers and not the build folder. Even better is to leave sources from others in their git repositories and only copy and maintain your own layers.
it is true an issue in the modern Yocto build system.
file bblayers.conf has to be synthesized based on MACHINE and DISTRO information using all provided (usually with the help of repo manifest file) layers by: collecting data from each available layer file layer.conf as well as conf/machine, conf/distro, images.
Instead bblayers.conf is usually copied over from the base layer conf/bblayers.conf location with the help of setup-environment script.
this approach provides no "one click" buildable environment but require maintainer/developer to look into readme to identify what layers are missing to be added to the build/conf/bblayers.conf.
I like to disable and enable some pins in my RPi project.
These are GPIO 6, GPIO 5 and GPIO 26. I like to use these PINs in my own kernel driver.
For this project I connect a simple electric board via the GPIOs. The minimal system is build via yocto. I like to change the device tree file to disable/enable GPIOs.
I need to change or make my own dts file. For that I think I will need to:
find the original RPi dts
patch it or create my own dts
add it to the layer.conf
add file to the kernel recipe via append
How can I do this? or where can I find the sources?
Actually I am struggling to find the dts files for the RPi2 I am using. I was checking the "raspberrypi2-poky-linux-gnueabi" recipe results(and do not find any files).
I do not find any tutorial how to setup yocto + meta-raspberrypi + own dts. it would be great if we can figure out the necessary steps.
I'm not convinced this question has been well answered, so let me take a few minutes and document what I've done to add device tree overlays to my yocto builds.
This is a multi-problem process.
I'm going to make a few assumptions:
* You source your oe-init-build-env in a shell, and do your bitbake builds manually in a terminal (or you know how to do it with equivalent tooling)
* You know (or are already learning) the basics of device trees...
Start with your own meta layer. Mine is out on github.
You'll need to create an *-overlay.dts source file. You can start with a simple place holder, and stuff it (quite literally) anywhere on your system. We'll import it to your meta layer in the next step using bitbake to do some of the staging and what-not for us.
recipetool appendsrcfile -wm rpi /path/to/your-layer-meta virtual/kernel /path/to/your-overlay.dts 'arch/${ARCH}/boot/dts/overlays/your-overlay.dts
At this point, you should end up with a recipes-kernel/linux directory with an appropriate bbappend targeting the $MACHINE type of -wm (rpi, as above), ready to copy the device tree source file into the proper spot for bitbake to find it when it building the kernel. But it still won't be included in your kernel build.
We need to add the overlay reference to the KERNEL_DEVICETREE variable, in places that will cover the scopes of: linux, bootfiles, and the sdcard_image-rpi.bbclass from meta-raspberrypi.
In the linux bbappend created in step 3, add KERNEL_DEVICETREE += "overlays/your-overlay.dtbo" to make the linux kernel build include your dts as something to compile into a dtbo.
To make the sdcard_image-rpi.bbclass copy the file, you'll need to add KERNEL_DEVICETREE =+ "overlays/your-overlay.dtbo" to your image recipe.
To make the overlay active, you'll need to create a recipes-bsp/bootfiles/rpi-config_git.bbappend whereyou can append a do_deploy step to add the dtoverlay=your line to config.txt.
I use my layer for more than one project, so I felt OK with having the dts compile with every kernel but only copy it to images where my image recipe added it to the KERNEL_DEVICETREE. For further insurance that I don't get these things interferring in images I don't want them in, my rpi-config append has a test to see if I should add the dtoverlay line to the config.txt
Of course, this was all assuming you were going to use your own home-grown DTS without starting from a kernel-sourced one. The process would be largely the same, but you'd be able to patch the existing, or copy it, or whatever you want to do in your linux recipe.
I hope this helps! I know it's an old question.
First you need to find the kernel used on your yocto project, the recipe is linux-raspberry.bb or something like linux-*.bb. The preferred kernel is probably set in your local.conf or machine.conf: PREFERRED_PROVIDER_virtual/kernel ?= "linux-raspberry"
This is indirectly set via "meta-raspberrypi/conf/machine/include/rpi-default-providers.inc" which is included via "rpi-base.inc"
Once found, take a look at the recipe, clone the git repository of the kernel, on the right branch, and reset at the right SRCREV.
Once downloaded, the dts files are in /path/of/my/kernel/linux-raspberry/arch/arm/boot/dts/. You can find the name of the devicetree file used in the kernel recipe, local.conf or machine.conf, with the variable KERNEL_DEVICETREE = "..."
For the meta-raspberry and rpi2 selected, the dts files can be found in <path to build dir>/linux-raspberrypi2-standard-build/source/arch/arm/boot/dts/. The source dir is a linked dir to the git sources.
You can add a new dtb by creating dtsi/dts files (don't forget to add it in the Makefile).
Create a patch, add it to the kernel recipe:
SRC_URI += "file://0001-mypatch.patch"
and put the patch file like this in your meta
├── files
│ └── 0001-mypatch.patch
└── linux-raspberry.bb
Modify the KERNEL_DEVICETREE variable to add your new dtb.
Now you can bitbake your kernel/image, your new dtb will be created.
I am new to bitbake. and I have multiple questions all related to each other.
I am trying to remove all the packages that are GPLv3 from my package. i see that there are .bb files for both versions (gplv2 and gplv3 or other license types as applicable), of packages in meta/recipes-*/ folders. If I use INCOMPATIBLE_LICENSE=GPLv3 it removes all the packages that are GPLv3. But I want to include some packages that are GPLv3. where do i specify this.
I do see a BBFILES flag in the bblayers.conf in poky/build/conf dir. is this this place to add the specific recipes?
Another question i have is, If i want to use a specific .bb file out of the multiple .bb files in the recipes-/ folder how do i do that. for example
/recipes-extended/tar/tar_1.17.bb
/tar_1.27.1.bb
In this case, how do i pick tar_1.17.bb and ignore 1.27.bb. This is just one example. There is a "bitbake -b" command that takes .bb file as input but that will build only that .bb file and ignore dependencies according to the documentation. I want to build the complete package and be able to pick and ignore a specific .bb file.
So, how does bitbake pick and more pricisely which .bb file does bitbake pick when there are multiple .bb files in the recipe folder.
1 There's no way to do that. What would the purpose be? Normally, if you want to avoid GPLv3, you want a completely GPLv3 free image
There's one way to circumvent the system. You can set
INCOMPATIBLE_LICENSE_pn-<package/recipe name> = ""
That will allow you to build the package. However, don't use this for production, unless you really know what you're doing.
2/3: Normally the highest version will be built. You can use
PREFERRED_VERSION_<package name>
in local.conf or in your distro, to select another version. Another way is to add
DEFAULT_PREFERENCE = "-1"
to the recipe you don't want to build.
You should be able to set
WHITELIST_<spdx_license> += "<name of the package which you want to white list>"
Not very well documented but the code is in poky/meta/base.bbclass