使用Yocto项目为iMX6开发板构建linux,我想更改用于构建u-boot-imx的.config(用于iMX开发板的u-boot) – 例如例如,将自动启动延迟更改为1秒.
我可以编辑配置(例如,找到构建目录并运行make menuconfig),但是当我运行bitbake重建图像时,它会再次使用默认值覆盖.config.有许多xxx_defconfig文件,我不知道它使用的是什么.
我跟随this guide进行了Yocto项目的内核配置.我对.config文件进行了更改,并将其复制到我的图层并重命名为“defconfig”.我创建了一个带有u-boot-imx_2017.03.bbappend的新层来扩展u-boot-imx_2017.03.bb(u-boot-imx的配方).
这是我的u-boot-imx_2017.03.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += "file://defconfig"
我还将它添加到我的layer.conf中的“BBFILES”中
我按如下方式重建u-boot：
bitbake -f -D u-boot-imx -c compile
当我这样做时,构建目录中的.config文件将恢复为默认配置(而不是我的更改版本),并且生成的u-boot二进制文件没有更改(启动延迟仍为3秒).
我认为我的图层正在处理,因为我在输出中看到了这一点：
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
我看不到任何调试输出说有错误(例如找不到我的defconfig文件).
如何使用Yocto对u-boot配置进行此类更改？
=====编辑=====
我按照下面LetoThe2nd的回答说明.这是我发现的：
bitbake-layers show-appends
有用！在我看到的层中：
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
所以看起来它找到了这个层.
bitbake -e -c clean u-boot-imx | tee build.log
在build.log中获取“SRC_URI”,我发现了这个：
# $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"
file：// defconfig来自我的bbappend.
为UBOOT_MACHINE打算,我发现：
# $UBOOT_MACHINE [2 operations]
...
UBOOT_MACHINE=" mx6ull_14x14_evk_config"
这看起来正确！
我检查了u-boot-imx构建目录中的.config;它仍然是不正确的.
(我将defconfig中CONFIG_BOOTDELAY的值与我的图层的值进行比较,将u-boot-imx的构建目录中的.config中的值进行比较).
=====编辑2 =====
我按照下面的LetoThe2nd的答案在ADDENDUM中提出了建议1.
即：
>为我的evk板构建u-boot-imx时使用的xxx_defconfig文件补丁(在本例中为[SOURCE DIR] / configs / mx6ull_14x14_evk_defconfig)
>使用.bbappend将补丁放在我的图层目录中
>更改.bbappend看起来这样：
_
FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += " file://mx6ull_14x14_evk_defconfig.patch;patchdir=${S}/configs "
>注意使用patchdir = ${S} / configs – 所以bitbake知道在哪里应用补丁,即[SOURCE DIR] / configs.见this question
这有效！ (即我在补丁中放入的调整后的自动启动延迟用于u-boot-imx).
我没有尝试过建议2,因为第一种方法听起来更好.
解决方法:
从技术上讲,你所描述的过程听起来对我来说是对但是需要注意几个障碍,分别要检查的事项：
>你的.bbappend是否实际处理过？
虽然这似乎是你的情况(你通过调试输出找到),这通常更容易检查：
bitbake-layers show-appends
这将为您提供在当前构建情况下生效的所有附加的完整详细列表.
> .bbappend实际上是否具有所需的效果？
如果涉及多个配方,事情可能会很复杂,并相互覆盖.检查
bitbake -e u-boot-imx
看看究竟发生了什么.这最好与管道组合成较少(或您选择的寻呼机),然后搜索修改后的值,如SRC_URI.
>找出你的u-boot机器是什么.
鉴于来自2.的信息,这是相当简单的：检查所调用的变量
UBOOT_MACHINE
因为这是u-boot真正应该看到的.
>尽量不要告诉bitbake要做太多细节.
特别是组合-f和-c开关可能会产生意想不到的结果,因为您基本上修改了任务依赖性.根据我的经验,还有一些东西
bitbake -c clean u-boot-imx && bitbake u-boot-imx
应该更好地工作,因为它贯穿整个构建依赖,包括配置,修补等.
EDIT / ADDENDUM
我已经检查过OE开发人员,主要问题是defconfig机制是(linux-)内核特定的,这也是为什么在kernel-dev手册中对它进行了解释.
因此,为了使您的配置进入实际构建,有一个半解决方案.
>正确的方法：
准备u-boot源的补丁.在您的情况下,这可能只是对已经使用的defconfig文件的一个小修改.拥有规范格式的补丁并将其添加到SRC_URI,然后它应该自动被拾取并执行操作.
> hackish(和未经测试,因此只有一半)的方式：
以完整格式准备配置(而不是defconfig精简版).然后将其添加到SRC_URI并通过.bbappend中的其他任务使用它：
do_compile_prepend() {
cp YOURFILENAME ${S}/.config
}
这应该在编译开始之前直接注入新配置.它可能需要一点点修改,但你肯定会得到这个想法.另一种方法是将defconfig注入原始文件.
话虽如此,我强烈推荐第一种方式.