How to change the config of u-boot in Yocto

Question

Building linux for an iMX6 dev board using the Yocto Project, and I want to change the .config used to build u-boot-imx (u-boot for the iMX dev board) - e.g. change the auto boot delay to 1 second as an example.

I can edit the config (e.g. find the build directory and run make menuconfig), but when I run bitbake to rebuild the image, it overwrites the .config with the default again. There are many xxx_defconfig files and I don't know which it is using.

I followed this guide for kernel configuration with the Yocto project. I made a change to the .config file, and copied it to my layer and renamed to "defconfig". I created a new layer with a u-boot-imx_2017.03.bbappend to extend u-boot-imx_2017.03.bb (the recipe for u-boot-imx).

Here's my u-boot-imx_2017.03.bbappend

FILESEXTRAPATHS_prepend := "${THISDIR}:"

SRC_URI += "file://defconfig"

I also added it to the "BBFILES" in my layer.conf

I rebuild u-boot as follows:

bitbake -f -D u-boot-imx -c compile

When I do this, the .config file in the build directory reverts to the default config (not my altered version) and the resulting u-boot binary doesn't have the change (boot delay still 3 sec).

I think my layer is getting processed because I see this in the output:

DEBUG: Appending .bbappend file /home/bob/yocto/morty/sources/meta-mylayer/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bbappend to /home/bob/yocto/morty/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bb

I can't see any debug output saying there was an error (e.g. couldn't find my defconfig file).

How do I make this kind of change to the u-boot config with Yocto?

===== EDIT =====

I followed the instructions from LetoThe2nd 's answer below. Here's what I found:

bitbake-layers show-appends

Useful! Among the layers I see:

u-boot-imx_2017.03.bb:
  /home/bob/yocto/morty/sources/meta-mylayer/imx/meta-bsp/recipes-bsp/u-boot/u-boot-imx_2017.03.bbappend

So it looks like it found the layer.

bitbake -e -c clean u-boot-imx | tee build.log

Grepping in build.log for "SRC_URI", I found this:

# $SRC_URI [6 operations]
...
# pre-expansion value:
#   "${UBOOT_SRC};branch=${SRCBRANCH} file://defconfig"
SRC_URI="git://git.freescale.com/imx/uboot-imx.git;protocol=git;branch=imx_v2017.03_4.9.11_1.0.0_ga file://defconfig"

The file://defconfig comes from my bbappend.

Grepping for UBOOT_MACHINE, I found:

# $UBOOT_MACHINE [2 operations]
...
UBOOT_MACHINE=" mx6ull_14x14_evk_config"

This looks correct!

I checked the .config in the u-boot-imx build directory; it's still incorrect.

(I compared the value of CONFIG_BOOTDELAY in defconfig from my layer with the value in .config in the build directory for u-boot-imx).

===== EDIT 2 =====

I followed suggestion 1 in the ADDENDUM to LetoThe2nd 's answer below. I.e.:

• Create a patch for the xxx_defconfig file used when building u-boot-imx for my evk board (in this case, [SOURCE DIR]/configs/mx6ull_14x14_evk_defconfig)

• Place the patch in my layer dir with the .bbappend

• Changed .bbappend to look line this:

_

FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += " file://mx6ull_14x14_evk_defconfig.patch;patchdir=${S}/configs "

• Note use of patchdir=${S}/configs - so bitbake knows where to apply the patch, i.e. [SOURCE DIR]/configs. See this question

This worked! (i.e. the adjusted auto-boot delay I put in the patch was used in u-boot-imx).

I have not tried suggestion 2 as the first method sounded better.

Godbey

Glad you worked it out! On a side note, the patchdir setting should only be necessary if your patch was created somewhere down the source tree of the package to patch. If you do the diff one directory level up in your case, the setting shouldn't be needed anymore. I would call that a best practise, but of course in this particular case and situation its only secondary. – Swinney

@Godbey when you say ".config"... What to you actually mean? Which file? – Rosalie

Answer 1

Technically the process you described sounds correct to me. But there's a couple of obstacles to watch out for, respectively things to check:

1. is your .bbappend actually processed?

While this seems to be the case for you (you found out through the debug output) this is usually easier checked with:

bitbake-layers show-appends

This will give you a complete and detailed list of all appends that are in effect in your current build situation.

2. Does the .bbappend actually have the desired effect?

If more than one recipe is involved, things can be complicated, and overwrite each other. Check with

bitbake -e u-boot-imx

to see what actually happens. This is best combined with piping into less (or the pager of your choice) and then searching for the modified values, like SRC_URI.

3. Find out what your u-boot machine is.

Given the information from 2., this is rather trivial: check for the variable called

UBOOT_MACHINE

as this is what u-boot really should see.

4. Try to not tell bitbake what to do it too much detail.

Especially combining the -f and -c switches might have unexpected results, as you basically tinker with the task dependencies. In my experience, something along

bitbake -c clean u-boot-imx && bitbake u-boot-imx

should work better, as it goes through the whole build dependency, including configuration, patching, and so on.

EDIT / ADDENDUM

I've checked with the OE devs, and the main problem is that the defconfig mechanism is (linux-)kernel specific, thats also why it is explained in the kernel-dev manual.

So to get your config into the actual build, there are one and a half solutions.

1. The correct way:

Prepare a patch to the u-boot sources. In your case, thats probably just a minor modification to the defconfig file that already is in use. Have the patch in the canonical format and add it to SRC_URI, then it should automatically be picked up and do the trick.

2. The hackish (and untested, therefore only half) way:

Prepare your config in full format (not the defconfig stripped down version). Then add it to SRC_URI and use it through an additional task in your .bbappend:

do_compile_prepend() {
  cp YOURFILENAME ${S}/.config
}

This should inject the new configuration directly before compilation starts. It might need a little tinkering, but you certainly get the idea. Another approach would be to inject your defconfig over the original file.

Having said that, I strongly recommend the first way.

Swinney

Method 1 in your addendum worked nicely! I have added notes to the question (EDIT 2) about how I applied it. – Godbey

Just to add to LetoThe2nd's response. The second method of applying config file support does work and more information on it can be found here: community.nxp.com/thread/376369 Basically what happens you have your own defconfig/.config file that you include as a SRC_URI inclusion in your Yocto recipe. You then do a string comparison on the master defconfig/.config for your configuration addition, and apply it on top appropriately. This is to ensure that there are no duplicates of the same configuration setting. I have used this method before and can post a solution if required. – Matronize

Answer 2

It is possible to add defconfig as regular file, as an example I'm pasting some working bbappend:

PR = "r7"
BRANCH = "ti-u-boot-2020.01"
SRCREV = "ae8ceb7b6e3acb4bc90f730e33dafc7b65066591"
FILESEXTRAPATHS_prepend := "${THISDIR}:" 

SRC_URI +=  "file://0001-Add-am335x-cmpc30-target.patch \
         file://am335x-cmpc30.dts;subdir=git/arch/arm/dts \
         file://am335x_cmpc30_defconfig;subdir=git/configs/ \
        "

So "file://am335x_cmpc30_defconfig;subdir=git/configs/" line actually put whole defconfig to u-boot source code.

Lorou

Thanks! This is very useful, because patches take really a lot of time to create while this takes a fraction of that time! A much better solution if you want to create new files. For changing the existing files I will have to still stick with patches... – Rosalie

Answer 3

not necessary to copy whole private .config file into u-boot build folder, if it is necessary to alter some settings inside defconfig, sed is working perfectly well inside the do_compile_prepend method too. example:

`

do_configure_prepend() {
        sed -i -e 's,CONFIG_DEFAULT_DEVICE_TREE=,CONFIG_DEFAULT_DEVICE_TREE= ${BOARD_DEVICE_TREE},g'  ${S}configs/mx7ulp_evk_defconfig
}

`

spaces are perfectly OK inside the search and replace patterns. ${BOARD_DEVICE_TREE} could be defined in one of the Yocto config files. this method also works well for the source/header files being already patched with recipe based patch list.

Coachwhip