Search code examples
kerneldriveryocto

Change kernel config but defconfig already there

My yocto repo already has a kernel config file:

defconfig

Right now, I want to do more modification on kernel config, can I still use

bitbake -c menuconfig virtual/kernel

or I need to directly edit on 'defconfig'

Solution

  • My way of changing kernel .config parameters in Yocto

    I change the linux kernel configuration in Yocto this way:

    Step 1: Add a .bbappend file that extends the kernel buid

    A .bbappend file in Yocto adds build commands to an existing build step. Here we extend the build step for the kernel compilation. We create a .bbappend file in one of our bitbake layers (I assume you will have added at least one layer for your own stuff).

    cd [any-of-my-own-layers]/recipes-kernel/linux/
mkdir files
nano linux-mainline_%.bbappend

    In this file we add the following code.

    #
# Modify Linux kernel configuration
#

SUMMARY = "Changes to the Linux kernel configuration."
SECTION = "MySection"

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://kerneldebug.cfg"

    We save the file with ctrl+x and y.

    Step 2

    Step 1 needs to be done only once. Step 2 needs to be done everytime we change the kernel config.

    bitbake -c menuconfig virtual/kernel
#Change by the GUI of menuconfig, save, exit
bitbake -c diffconfig virtual/kernel
#In the terminal output of this command you can see the [diff-file] location
less [diff-file]           (Check if this is what you'd expect)
cp [diff-file] [any-of-my-own-layers]/recipes-kernel/linux/files/[speaking-name].cfg
bitbake -fc patch virtual/kernel
bitbake -fc compile virtual/kernel
bitbake [my-image-name]

    Now we can boot and test the new setting. The setting will be permanent.

    IF YOU'RE STILL BUSY WITH YOUR VERY FIRST KERNEL PATCH YOU CAN STOP READING HERE.

    Appendix A: Working over time, making more than one change

    Aboves paragraph shows you how to make your very first kernel config change. If you need to make more and more changes over a period of time, here's my best practices:

    Be careful not to overwrite you past work

    Note: Above's procedure always creates a new file with only the latest changes you made in menuconfig. So be careful not to overwrite the settings from the last run of bitbake diffconfig. E.g. when you made last wheek a file my-driver.cfg and then execute bitbake diffconfig and cp [diff-file] ... again with the same name my-driver.cfg, the edits you made last wheek will be overwritten. So allways use a new name for the .cfg file. You can add several .cfg files to the .bbappend file (several SRC_URI += "xyz.cfg" lines) and reference the new file there. This gives the single config fragments a structure. Or you can merge todays file manually into last wheek's file and then delete today's file and leave the bbappend untouched.

    Manually extending the .cfg file

    When I have to make more edits, sometimes I fire up menuconfig (bitbake -c menuconfig virtual/kernel), find out the setting there, note its name, leave menuconfig without saving. Then I edit the .cfg file ([any-of-my-own-layers]/recipes-kernel/linux/files/[speaking-name].cfg) directly. No need to call diffconfig. Here's an example of a .cfg file, as you can see you can easily drop in new lines:

    EXAMPLE OF AN AUTO-GENERATED .CFG FILE, NO NEED TO CREATE THIS YOURSELF, JUST FYI:

    less /yocto/meta-layers/meta-mynux/recipes-kernel/linux/files/kgdb.cfg

# CONFIG_SERIAL_KGDB_NMI is not set
CONFIG_CONSOLE_POLL=y
# CONFIG_DEBUG_INFO is not set
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
# CONFIG_KGDB_KDB is not set

    Appendix B: Workflow for testing (optional)

    Above's text shows how to change the kernel configuration in yocto, once you know which settings you need. If you know your settings you can stop reading here. If, however, you want to test the settings first, or play around with different settings, there is a "rapid prototyping" way as follows:

    For testing you can use

    bitbake -c menuconfig virtual/kernel
bitbake -c compile virtual/kernel
bitbake [my-image-name]
then boot as you like.

    Now you can test the new config. After the next "bitbake -c patch virtual/kernel" or after the next full rebuild all kernel menuconfig settings will be gone. So the workflow is first testing with this menuconfig/compile/boot procedure, and once you're satisfied use diffconfig and store the config fragement to a file to make it permanent (like shown all above in this post).

    Appendix C: Troubleshooting

    I encountered two caveats. No need to read this section if everything goes well

    bitbake menuconfig does not work

    If you're building in a docker environment, you might to install additional packages with (e.g.) apt for using menuconfig. In local.conf you can configure the kind of menucconfig (there are several GUIs).

    The kernel does not pick up the changes

    If the kernel picks up your changes can be tested with adding a kernel name suffix in kenel config and then call "uname -r" on the target. If your changes don't show up the filename of .bbappend might maybe not match your kernel .bb recipe name. I found the correct name to use for the .bbappend file the following way, just in case you need a different name:

    cd /yocto/meta-layers
find -name "linux-*.bbappend"

    The result was: …/meta-layers/poky/../meta-phytec/recipes-kernel/lan743x/linux-mainline_4.14.134-phy2.bb.do_patch. From there I could guess the right name and replaced the kernel version 4.14.134 by % for convenience.