How to change the config of u-boot in Yocto

Jeremy picture Jeremy · Nov 1, 2017 · Viewed 16.9k times · Source

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.

Answer

LetoThe2nd picture LetoThe2nd · Nov 1, 2017

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.

  1. 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.

  1. 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.

  1. 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.

  1. 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.