How to change the config of u-boot in Yocto

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.

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.

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.