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