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.
使用Yocto项目为iMX6开发板构建linux,我想更改用于构建u-boot-imx的.config(用于iMX开发板的u-boot) - 例如例如,将自动启动延迟更改为1秒。
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.
我可以编辑配置(例如,找到构建目录并运行make menuconfig),但是当我运行bitbake重建图像时,它会再次使用默认值覆盖.config。有许多xxx_defconfig文件,我不知道它使用的是什么。
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).
我在Yocto项目中遵循本指南进行内核配置。我对.config文件进行了更改,并将其复制到我的图层并重命名为“defconfig”。我创建了一个带有u-boot-imx_2017.03.bbappend的新层来扩展u-boot-imx_2017.03.bb(u-boot-imx的配方)。
Here's my u-boot-imx_2017.03.bbappend
这是我的u-boot-imx_2017.03.bbappend
FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += "file://defconfig"
I also added it to the "BBFILES" in my layer.conf
我还将它添加到我的layer.conf中的“BBFILES”中
I rebuild u-boot as follows:
我按如下方式重建u-boot:
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).
当我这样做时,构建目录中的.config文件将恢复为默认配置(而不是我的更改版本),并且生成的u-boot二进制文件没有更改(启动延迟仍为3秒)。
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).
我看不到任何调试输出说有错误(例如找不到我的defconfig文件)。
How do I make this kind of change to the u-boot config with Yocto?
如何使用Yocto对u-boot配置进行此类更改?
===== EDIT =====
=====编辑=====
I followed the instructions from LetoThe2nd 's answer below. Here's what I found:
我按照下面LetoThe2nd的回答说明。这是我发现的:
bitbake-layers show-appends
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
bitbake -e -c clean u-boot-imx | tee build.log
Grepping in build.log for "SRC_URI", I found this:
在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"
The file://defconfig comes from my bbappend.
file:// defconfig来自我的bbappend。
Grepping for UBOOT_MACHINE, I found:
为UBOOT_MACHINE打算,我发现:
# $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.
我检查了u-boot-imx构建目录中的.config;它仍然是不正确的。
(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).
(我将defconfig中CONFIG_BOOTDELAY的值与我的图层的值进行比较,将u-boot-imx的构建目录中的.config中的值进行比较)。
===== EDIT 2 =====
=====编辑2 =====
I followed suggestion 1 in the ADDENDUM to LetoThe2nd 's answer below. I.e.:
我按照下面的LetoThe2nd的回答中的建议1。即:
-
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)
为我的evk板构建u-boot-imx时使用的xxx_defconfig文件创建补丁(在本例中为[SOURCE DIR] / configs / mx6ull_14x14_evk_defconfig)
-
Place the patch in my layer dir with the .bbappend
使用.bbappend将补丁放在我的图层目录中
-
Changed .bbappend to look line this:
将.bbappend更改为以下行:
_
_
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
- 注意使用patchdir = $ {S} / configs - 所以bitbake知道应用补丁的位置,即[SOURCE DIR] / configs。看到这个问题
This worked! (i.e. the adjusted auto-boot delay I put in the patch was used in u-boot-imx).
这有效! (即我在补丁中放入的调整后的自动启动延迟用于u-boot-imx)。
I have not tried suggestion 2 as the first method sounded better.
我没有尝试过建议2,因为第一种方法听起来更好。
2 个解决方案
#1
3
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?
- 是你的.bbappend实际处理?
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?
- .bbappend实际上是否具有所需的效果?
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.
看看究竟发生了什么。这最好与管道组合成较少(或您选择的寻呼机),然后搜索修改后的值,如SRC_URI。
- Find out what your u-boot machine is.
- 找出你的u-boot机器是什么。
Given the information from 2., this is rather trivial: check for the variable called
鉴于来自2.的信息,这是相当微不足道的:检查所调用的变量
UBOOT_MACHINE
as this is what u-boot really should see.
因为这是u-boot真正应该看到的。
- Try to not tell bitbake what to do it too much detail.
- 尽量不要告诉bitbake要做太多细节。
Especially combining the -f and -c switches might have unexpected results, as you basically tinker with the task dependencies. In my experience, something along
特别是组合-f和-c开关可能会产生意想不到的结果,因为您基本上修改了任务依赖性。根据我的经验,还有一些东西
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
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.
我已经检查过OE开发人员,主要问题是defconfig机制是(linux-)内核特定的,这也是为什么在kernel-dev手册中对它进行了解释。
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.
准备u-boot源的补丁。在您的情况下,这可能只是对已经使用的defconfig文件的一个小修改。以规范格式提供补丁并将其添加到SRC_URI,然后它应该自动被拾取并执行操作。
- The hackish (and untested, therefore only half) way:
- hackish(和未经测试,因此只有一半)的方式:
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:
以完整格式准备配置(而不是defconfig精简版)。然后将其添加到SRC_URI并通过.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.
这应该在编译开始之前直接注入新配置。它可能需要一点修补,但你肯定会有这个想法。另一种方法是将defconfig注入原始文件。
Having said that, I strongly recommend the first way.
话虽如此,我强烈推荐第一种方式。
#2
0
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:
没有必要将整个私有.config文件复制到u-boot build文件夹中,如果需要更改defconfig中的一些设置,sed在do_compile_prepend方法中也能正常工作。例:
`
`
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.
在搜索和替换模式中,空间完全正常。 $ {BOARD_DEVICE_TREE}可以在其中一个Yocto配置文件中定义。此方法也适用于已使用基于配方的修补程序列表修补的源/头文件。
#1
3
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?
- 是你的.bbappend实际处理?
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?
- .bbappend实际上是否具有所需的效果?
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.
看看究竟发生了什么。这最好与管道组合成较少(或您选择的寻呼机),然后搜索修改后的值,如SRC_URI。
- Find out what your u-boot machine is.
- 找出你的u-boot机器是什么。
Given the information from 2., this is rather trivial: check for the variable called
鉴于来自2.的信息,这是相当微不足道的:检查所调用的变量
UBOOT_MACHINE
as this is what u-boot really should see.
因为这是u-boot真正应该看到的。
- Try to not tell bitbake what to do it too much detail.
- 尽量不要告诉bitbake要做太多细节。
Especially combining the -f and -c switches might have unexpected results, as you basically tinker with the task dependencies. In my experience, something along
特别是组合-f和-c开关可能会产生意想不到的结果,因为您基本上修改了任务依赖性。根据我的经验,还有一些东西
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
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.
我已经检查过OE开发人员,主要问题是defconfig机制是(linux-)内核特定的,这也是为什么在kernel-dev手册中对它进行了解释。
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.
准备u-boot源的补丁。在您的情况下,这可能只是对已经使用的defconfig文件的一个小修改。以规范格式提供补丁并将其添加到SRC_URI,然后它应该自动被拾取并执行操作。
- The hackish (and untested, therefore only half) way:
- hackish(和未经测试,因此只有一半)的方式:
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:
以完整格式准备配置(而不是defconfig精简版)。然后将其添加到SRC_URI并通过.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.
这应该在编译开始之前直接注入新配置。它可能需要一点修补,但你肯定会有这个想法。另一种方法是将defconfig注入原始文件。
Having said that, I strongly recommend the first way.
话虽如此,我强烈推荐第一种方式。
#2
0
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:
没有必要将整个私有.config文件复制到u-boot build文件夹中,如果需要更改defconfig中的一些设置,sed在do_compile_prepend方法中也能正常工作。例:
`
`
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.
在搜索和替换模式中,空间完全正常。 $ {BOARD_DEVICE_TREE}可以在其中一个Yocto配置文件中定义。此方法也适用于已使用基于配方的修补程序列表修补的源/头文件。