如何在Yocto中更改u-boot的配置

时间:2022-09-16 23:45:32

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:

从技术上讲,你所描述的过程听起来对我来说是对但是需要注意几个障碍,分别要检查的事情:

  1. is your .bbappend actually processed?
  2. 是你的.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.

这将为您提供在当前构建情况下生效的所有附加的完整详细列表。

  1. Does the .bbappend actually have the desired effect?
  2. .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。

  1. Find out what your u-boot machine is.
  2. 找出你的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真正应该看到的。

  1. Try to not tell bitbake what to do it too much detail.
  2. 尽量不要告诉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.

因此,为了使您的配置进入实际构建,有一个半解决方案。

  1. The correct way:
  2. 正确的方法:

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,然后它应该自动被拾取并执行操作。

  1. The hackish (and untested, therefore only half) way:
  2. 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:

从技术上讲,你所描述的过程听起来对我来说是对但是需要注意几个障碍,分别要检查的事情:

  1. is your .bbappend actually processed?
  2. 是你的.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.

这将为您提供在当前构建情况下生效的所有附加的完整详细列表。

  1. Does the .bbappend actually have the desired effect?
  2. .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。

  1. Find out what your u-boot machine is.
  2. 找出你的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真正应该看到的。

  1. Try to not tell bitbake what to do it too much detail.
  2. 尽量不要告诉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.

因此,为了使您的配置进入实际构建,有一个半解决方案。

  1. The correct way:
  2. 正确的方法:

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,然后它应该自动被拾取并执行操作。

  1. The hackish (and untested, therefore only half) way:
  2. 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配置文件中定义。此方法也适用于已使用基于配方的修补程序列表修补的源/头文件。