It is common that the metalayer providing a Linux Kernel recipe includes a default configuration file for the Linux Kernel source code (the defconfig
file).
There are several approaches to customize the Linux Kernel source code and defconfig
file. This article presents the option to patch the defconfig from the Linux Kernel source code and is a good approach to be used with meta-fsl-bsp-release
or meta-imx
.
The list of requirements:
meta-imx:imx-5.4.3-2.0.0
)For example, take BSP release imx-5.4.3-2.0.0
for meta-imx
$ mkdir <BSP_DIR>
$ cd <BSP_DIR>
$ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.3-2.0.0.xml
$ repo sync
$ MACHINE=imx8mnevk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland
Use the very same Linux Kernel source code from the metalayer. In this example, open the file sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb
to get the git repository, and git commit.
$ cd ~
$ git clone git://source.codeaurora.org/external/imx/linux-imx.git
$ cd linux-imx
$ git checkout fd263a3edd95dfe812397fabf1059b5f99bba2ab -b change_defconfig
Using the default defconfig
as a base, configure the Linux Kernel, and then use make menuconfig
to change the configuration as desired.
After the customization, generate a new defconfig
file and replace the default one.
The step by step with all the commands can be see in next snippet:
$ export ARCH=arm64
$ export CROSS_COMPILE=aarch64-linux-gnu-
$ make defconfig
$ make menuconfig
$ make savedefconfig
$ cp defconfig arch/arm64/configs/defconfig
The customization can be highlighted by git, in this example the result is show in next log:
$ git status
On branch change_defconfig
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: arch/arm64/configs/defconfig
Untracked files:
(use "git add <file>..." to include in what will be committed)
defconfig
no changes added to commit (use "git add" and/or "git commit -a")
Review the change and create a commit, with that commit, create a patch.
TIP: The defconfig
file can also be directly changed. The make menuconfig
can be skipped in that case.
$ git add arch/arm64/configs/defconfig
$ git commit -s -m "defconfig: Customize defconfig"
$ git format-patch -1
0001-defconfig-Customize-defconfig.patch
Now that the Linux Kernel configuration is customized, and a patch to the kernel is created, copy over that patch to the metalayer, and install it to the Linux Kernel recipe file.
$ mkdir <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx/
$ cp 0001-defconfig-Customize-defconfig.patch <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx/
The Linux Kernel recipe for this example is linux-imx_5.4.bb
. Edit the file to install the patch.
$ gedit <BSP_DIR>/sources/meta-imx/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb
Add the following line:
SRC_URI += "file://0001-defconfig-Customize-defconfig.patch "
The resultant change is show above:
$ cd <BSP_DIR>/sources/meta-imx/
$ git diff
diff --git a/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb b/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb
index 214647abb..3f926314c 100644
--- a/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb
+++ b/meta-bsp/recipes-kernel/linux/linux-imx_5.4.bb
@@ -16,6 +16,7 @@ KERNEL_BRANCH ?= "imx_5.4.3_2.0.0"
LOCALVERSION = "-2.0.0"
KERNEL_SRC ?= "git://source.codeaurora.org/external/imx/linux-imx.git;protocol=https"
SRC_URI = "${KERNEL_SRC};branch=${KERNEL_BRANCH}"
+SRC_URI += "file://0001-defconfig-Customize-defconfig.patch "
SRCREV = "fd263a3edd95dfe812397fabf1059b5f99bba2ab"
Remember to change the current directory to the metalayer.
Build the image again. The new image binary reflects the changes in Linux Kernel, and in case the change removes some kernel module, the rootfs also reflects the change.
$ cd <BSP_DIR>/bld-xwayland
$ bitbake <image-name>
Hi Daiane,
We are using the i.MX8M Mini, and would prefer not to modify the various meta layers that are provided as part of the BSP. The BSP we are using is from Variscite, and apparently builds on NXP's own BSP for Yocto Warrior and Zeus.
We would like to have our changes in a custom layer, e.g. meta-xxx, and then have Yocto apply a custom device tree (.dts) and defconfig to our image. We are currently building fsl-image-qt5.
How can I instruct Yocto to use our own defconfig and .dts from within a custom layer, which avoids having to modify the normal open-source layers provided? I believe that it might involve adding a .bbappend file to something like meta-xxx/recipes-kernel/linux, but I am not at all sure what to put into it.
At the moment I have to run bitbake -c menuconfig virtual/kernel, then bitbake fsl-image-qt5 again to make kernel configuration change "stick".
Thanks for your help,
Scott
There is one working example of bbappend that applies a patch to a code:
The first 5 lines would be an example for what you want to accomplish.
So the patches would include the changes for adding a new dtb, and the changes for the defconfig file
maybe you would need to think about adding a new board eventually
and if you add a new dts, probably you want to install it to the final image:
imx8mmevk.conf « machine « conf - meta-freescale - Layer containing NXP hardware support metadata
Thanks for the examples, Daiane. This is one area that seems frustrating to many Yocto users. I've seen so many postings about Yocto not applying someone's defconfig or dts as expected, and debugging why seems to be a challenge. I guess that this is one of the tradeoffs with Yocto. It does some very complex things quite easily (i.e. bitbake my_image), but seemingly simple customizations require a deep dive into layers, where to put recipes, creating .bbappend files, figuring out what Yocto variables need to be modified in those .bbappend files, etc.
I think there are many of us trying to use Yocto and vendor-provided BSPs that don't want to change the provided source code, but need to make minor tweaks to the kernel configuration and the device tree for our custom hardware. It would be nice if Yocto provided a simple, straightforward way to accomplish those two things in a user-defined custom layer, but maybe this will come with time.
Thanks for your tutorial writeups. I have found them to be very helpful and informative. Thanks again for your efforts!
Yocto does
But there are a lot of forced configurations on NXP BSP metalayers in order to make sure we use exactly what we provide (in a more controlled way). That's why it's sometimes difficult to "customize" the kernel, it's because the BSP is concepted in a way to not be customized.
For example, the meta-freescale metalayer has a completely differente approach on how to handle the defconfig file.
Thanks for your feedback, I really appreciate to know that my tutorials make someone else's live easier somehow.