I am using BSP layer meta-ti in yocto build system with poky as distro. When i set the MACHINE variable as "beaglebone", the PREFERRED_PROVIDER_virtual/kernel is "linux-ti-staging" i.e the kernel source will be downloaded from SRC_URI present in recipe linux-ti-staging-version.bb.
I have written my own kernel recipe(my-custom-kernel-version.bb) where i have specified the SRC_URI pointing to different github path to defconfig for the custom kernel source. This recipe is present in meta-mylayer/recipes-kernel/linux/
I do want to do any kernel modification in yocto using bitbake -c menuconfig virtual/kernel.
How can i make bitbake to pickup up my-custom-kernel-version.bb
rather than the linux-ti-staging-version.bb to fetch the kernel source.
Inside your distribution file. You can simply add:
PREFERRED_PROVIDER_virtual/kernel = "my-custom-kernel-version"
Make sure that you have PROVIDES += "virtual/kernel" in your kernel recipe.
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 build a yocto OS image, the image is done, but I can't find the kernel source.
I want to modify some files in the kernel source.
I see no any kernel source file in build/
i built for Yocto dunfell , core-image-minimal image for qemuarm machine
You can find kernel source in
build/tmp/work-shared/qemuarm/kernel-source
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
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'.
Bitbake by default generates .rpm files,
But unfortunately .rpm files do not work on debian or ubuntu systems.
How to make bitbake to generate .deb files directly?
First, you can't assume that you'll be able to use your bitbake:ed deb-packages in your regular Debian or Ubuntu system anyway.
Now, the Poky reference distribution (of the Yocto Project), which is what I assume you're using (due to your yocto tag), do default to rpm.
Set PACKAGE_CLASSES in conf/local.conf or preferably, in your own distro config to:
PACKAGE_CLASSES = "package_deb"
This will configure your build to use deb-packages. (The other options are package_ipk or package_rpm.