I want to install an initramfs in the rootfs /boot (not the same as a wic boot partition).
In rootfs /boot, there are a kernel image, and a fit image installed.
I don't bundle the initramfs in the kernel, but put it in the fit image, but this fit image is the one without the initramfs.
I need to put the initramfs in /boot on the rootfs but I don't find what is installing these or if there is a legitimate way to also install other things there, or if I need to patch something?
I'm hoping for something like IMAGE_BOOT_FILES where I can specify extra files from DEPLOY_DIR_IMAGE
As an extra detail, the initramfs I wish to install isn't the one declared to the kernel recipe with INITRAMFS_IMAGE (for fit image inclusion) but an alternate initramfs which can be built separately.
But I'm having trouble specifying the dependency so this extra initramfs is built separately.
I've tried specifying the name of this initramfs recipe using:
DISTRO_EXTRA_RDEPENDS
EXTRA_IMAGEDEPENDS
PACKAGES
Edit: Part of the answer seems to be that the initramfs is an image and so anything it installs (using staging) would be in itself.
Clearly I need to follow the kernel recipe plan which is a different recipe to depend on the imitramfs, and it having produced it's artifacts to then steal them
The simple answer is to use something like this in the top level yocto-image-base.bb recipe
ROOTFS_POSTPROCESS_COMMAND_append += "install_initramfs;"
install_initramfs() {
cp ${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE}-${MACHINE}.cpio.gz ${IMAGE_ROOTFS}/boot/
ln -sf ${INITRAMFS_IMAGE}-${MACHINE}.cpio.gz ${IMAGE_ROOTFS}/boot/initramfs.gz
}
But I'd rather add back in inherit staging to the initramfs bb with something like:
addtask populate_sysroot after do_build before do_complete
to re-introduce the ability for an image recipe to contribute to a higher-level sysroot other than through ${DEPLOY_IMAGE_DIR}
It ought to be as straighforward to drop an initramfs in a parent sysroot as it is with wic into /boot
Related
I would like to see linux kernel sources that were used to build an image with bitbake in yocto. I need to verify that we are using a correct dts file, and probably to update it.
I was told that devtool can help me to see kernel sources, but I can't understand how to use devtool to get the linux kernel sources(and the dts file in special).
How do I do it?
In order to use devtool to modify the kernel, if you don't know the kernel name, you can execute in the build environment the next command:
devtool modify virtual/kernel
This will modify the recipe for virtual/linux, which underneath is an alias for the kernel you are using, for example linux-tegra, linux-imx, etc.
After you execute that command, you can see the sources that have been unpacked and patched inside your builddir folder on the following path: build/workspace/sources/<kernel recipe name>.
Devtool will create a git repo on that path, which will have the same branches as the remote SRC_URI where it is getting it from, so you can make your changes there.
It will also create a .bbappend so that bitbake knows that the actual source for the kernel is this folder and not the one on tmp. This bbappend is located in this path:
build/workspace/appends/<kernel recipe name>.bbappend
After you modify it, you can just do a bitbake virtual/kernel to build this modified kernel.
In order to find which device tree your machine is using, you can extract such information using the -e flag on bitbake and then grep:
bitbake -e virtual/kernel | grep "^KERNEL_DEVICETREE="
Then you can search for that device tree inside the kernel sources and you can modify it as well.
Hope this helps a little. If you have more doubts let me know.
I'm in the process of upgrading from Yocto Sumo to Yocto Dunfell. In this process there's quite a few packages getting added to the rootfs that wasn't there before and which I don't have use for. I would like to know why they are added? Which dependency triggers them to get added?
In previous versions of Yocto there was a pn-depends.dot file which provided this information. This has now been removed. All that is left is a task-depends.dot which I guess I should use, however it is harder to read as it lists dependencies between individual tasks and doesn't show why a certain package is added to the rootfs. The command bitbake -g <image-name> -u taskexp makes it slightly easier to read the file but it is still hard to understand as package names are not always the same as task names.
What is the preferred solution to get an answer to "why is included in my rootfs?"
I have a project that could be built with the Yocto build system to generate a full disk image. According to the existing procedure, I can get only a full disk image that should be flashed on SD card.
And this does not suit my needs because I can't flash the image on the board. In my case, I need to build a certain project (that currently has a recipe) to an executable. (This project currently is a part of the full disk that is built with Yocto)
So I am wondering, is it possible to extract this executable (and the libraries that this executable depends on) from Yocto build files, so that I could copy and install it on the board? Which possibilities do I have to do this? Do I have some quick and dirty way to do this?
P.S: I heard something about that Yocto can provide a package for a certain project, that could be installed by the corresponding package manager on the board. On the board installed dpkg package manager.
It's a solution to add tar.gz to your IMAGE_FSTYPE.
After building the image, you can extract the executable you were looking for from the created archive.
Or you add the output format you need for your target and install the full image.
I'm using Yocto project to build a linux kernel image following these steps:
https://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d27Som1EKMainPage
For some reasons I just want to reduce my Image size so I can flash it on QSPI 8 Mega octet memory. I have tried to reduce the size of my rootFS, I have removed some packages that I found in .manifest file and some Distro features. But I did not find how can I modify the kernel size which size is fixed ( 4.2 Mega octet ).
I think that when I can remove some drivers that I don't need the kernel size will be reduced.
I just want to know how can I find what drivers are built in my image and where can I find them ? and later how can I delete the ones that I don't need ?
Thank you.
if you check the .config file that was generated for your BSP, it will show what drivers (and other things) were built into your kernel (check for the 'y' on all the options).
Such file should be somewhere in:
tmp/work//linux-yocto//linux-*-build/.config
Sorry that I can't give you the exact location, but it literally depends on what BSP/MACHINE you are building for.
Also, if you want to modify such configuration, you can call:
$ bitbake -c menuconfig virtual/kernel
that will bring up the menuconfig ncurses interface, in which you can not only see what is installed but also modify what you need.
I am working on an embedded project on Zedboard. I would like (at least for now) to use Bitbake only to produce proper rootfs. I use recipe core-image-minimal, as I need only limited amount of staff there. How can I "tell" it to not compile kernel, not make u-boot, etc. and focus on rootfs only?
Here is what I've done so far:
Created my build environment
Downloaded needed layers
Modified local.conf to add needed packages to rootfs
Then after typing
bitbake core-image-minimal
I get my rootfs, and all this unnecessary staff. How can I avoid it?
I recently had the same need to only build the rootfs with yocto, skipping other things such as kernel, uboot, image creation etc. There are many legitimate reasons to do so. Anyways, this is what you have to do:
bitbake core-image-minimal -c image_cpio
in krogoth, this will populate the rootfs directory in build/tmp/work/$MACHINE/core-image-minimal/1.0-r0/ and create a rootfs.cpio file in build/tmp/deploy/images/$MACHINE/
in morty, the rootfs.cpio archives seem to be in build/tmp/work/$MACHINE/core-image-minimal/1.0-r0/deploy-core-image-minimal-image-complete/
Interesting concept. However, from what I observed, Yocto must get the defconfig in kernel and u-boot to do configuration on the image itself. Therefore, removing the process will make rootfs not bootable.
These happened for me a lot of time since I used different kernels to compile for different machines. I thought that the ARM image will be the same and will work for all machine but I was wrong.
For Debian, the image compiled need to use kernel's corresponding configuration to compile the rootfs for it to work. And Yocto is the same.
bitbake -e |grep IMAGE_FSTYPE
will give you something like:
IMAGE_FSTYPES="tar.gz cpio cpio.gz.u-boot ...."
it's a list of all the image that will be generated, to remove the undesired ones, in the local.conf file use:
IMAGE_FSTYPES_remove = " cpio cpio.gz.u-boot"
the space before the first element it's not optional.
Regards
If you don't want to build a kernel set the preferred provider of virtual/kernel to 'linux-dummy'.