Yocto - how to stop overwriting the same image - yocto

I am new to Yocto and following starter tutorials : https://tutorialadda.com/yocto
When I do source oe-init-build-env , this creates a build directory and moves me into it. Then when I do bitbake core-image-minimal , this builds the minimal image for me. All good.
Now I have added my own layer and recipe and run bitbake core-image-minimal again and it works.
However, how do I stop overwriting the same image in tmp/deploy/images every time I make a change (adding recipes or changing code etc.). How do I tell it to create a new image alongside the older one /s ?
Sorry if this question is primitive, but I can't seem to find a clear answer. Thanks.

Related

Bitbake do_fetch fails on incorrect hash

I am trying to build a system (Yocto based project) using bitbake and one of the steps is that it needs to retrieve an archive.zip file with a hex file in it from a Jenkins instance somewhere and install that somewhere within the kernel.
The problem now is that I have get a bitbake error on the do_fetch step of this precise recipe.
File: '/cache/downloads/firmware-17.zip' has sha256 checksum 6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9 when 6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9 was expected If this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe: SRC_URI[sha256sum] = "6b565bbe776e3eabd883af7d1660db6ac2c13f13f16fbb1dbf6b9af42e31e9c9"
As you can see the expected checksum is identical between what bitbake reads and expects so I don't really understand what to do at the moment.
What I have already tried is:
Ensure that bitbake does a full clean build.
Bump the repository where archive.zip originates from so that the hash isn't the problem.
What I haven't tried yet is:
Manually download the firmware and place it in the /downloads folder of bitbake and mark the recipe as 'fetched' but since it is running in docker that is not a viable solution really.
Has anybody come across something like this?
I suspect there is a stray space in the value set in your recipe. The message hints at that with "9c9 was" showing a double space.

In BitBake (Yocto), how to find what layer is using a dependency?

While building a Yocto image, BitBake fetches the files specified in layer recipes. When running bitbake, the process identifies missing files and tries to find them from mirrors.
Aside from searching the whole project for the missing file, is there a bitbake tool to identify a layer or recipe, given a broken package/file link?
One current example is:
expat-native-2.2.8-r0
tried, invalid: https://downloads.sourceforge.net/expat/expat-2.2.8.tar.bz2
use: https://github.com/libexpat/libexpat/releases/download/R_2_2_8/expat-2.2.8.tar.bz2
This question may be similar, but is out of date.
How do I find which layer is using the expat-native package?

How can I add or delete the recipe in Yocto image by toaster

I use Yocto image to development some product.
And I need to add or delete recipe in my Yocto image.
I try to using toaster and success to analysis my Yocto image.
But I can't delete already including recipes.
This image is customized and already using in developing.
When starting the toaster, it doesn't have any UI for delete package or recipe.
Only can analysis build image.
Someone has any ideas??
Open toaster and find the bitbake variable at bottom side. then you will find the Add variable.
To remove recipe use IMAGE_INSTALL_remove
To add recipe use IMAGE_INSTALL_append

In yocto (poky) why is the layers config in the build/ folder?

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.

Building poky-tiny for the i.MX6 Ultra Lite Evaluation Kit

I'm currently trying to build poky-tiny for imx6ulevk (using the BSP Yocto Project Environment provided by NXP).
I first followed the Quick Start Guide, tested and everything worked just fine. I then went to the usual local.conf file (/build/conf/local.conf) and changed the DISTRO variable to poky-tiny.
In poky-tiny distro file (/sources/poky/meta-yocto/conf/distro/poky-tiny.conf), I changed the virtual/kernel in the variable PREFERRED_PROVIDER_virtual/kernel to linux-imx and the PREFERRED_VERSION_linux-imx to 3.14.38 which is compatible (I think).
I finally added to the local.conf the variable IMAGE_FSTYPES with the value tar.bz2 ext3 sdcard.
At this point I tried to build using:
bitbake core-image-minimal
this runs without any problems. But it doesn't generate sdcard image or any u-boot images as is expected. The only files generated are:
core-image-minimal-imx6ulevk-20160517152114.rootfs.cpio.gz
core-image-minimal-imx6ulevk-20160517152114.rootfs.manifest
core-image-minimal-imx6ulevk.cpio.gz
core-image-minimal-imx6ulevk.manifest
modules-imx6ulevk.tgz
zImage
zImage--3.14.38-r0-imx6ul-14x14-evk-20160517152114.dtb
zImage--3.14.38-r0-imx6ul-14x14-evk-csi-20160517152114.dtb
zImage--3.14.38-r0-imx6ulevk-20160517152114.bin
zImage-imx6ul-14x14-evk-csi.dtb
zImage-imx6ul-14x14-evk.dtb
zImage-imx6ulevk.bin
And I got stuck without knowing how to deploy to the imx6ulevk. What did I do wrong? Why is yocto not generating the usual sdcard image?
If anyone gets this what worked for me was the following:
Turns out poky-tiny for imx6ulevk does not create sdcard images normally. So what you need to do, once you build it with a proper kernel, is to manually create a bootable sdcard. This can be done by using gparted cleaning everything in it and adding 2 partitions, then proceed as follow:
1 - First you use gunzip in the file core-image-minimal-imx6ulevk-...-rootfs.cpio.gz.
2 - Call cpio on the generated file: cpio -i -vd < core-image-minimal...-.cpio
3 - You just generated the root file system copy everything into one of the partitions.
4 - the zImage...* files are the generated kernel for the poky-tiny distro. Copy all but the symbolic links to the second partition. You might need to rename the files (I had to) if you're not sure what to rename to, first build regular poky using sdcard image and check out the proper names.
That's pretty much it, you should be able to boot imx6ulevk using the provided files.