Yocto Projectを使用してiMX6開発ボード用のLinuxを構築しています。u-boot-imx(iMX開発ボード用のu-boot)の構築に使用する.configを変更したいと思います。例として、自動起動遅延を1秒に変更します。
構成を編集できます(たとえば、ビルドディレクトリを見つけてmake menuconfigを実行します)が、bitbakeを実行してイメージを再構築すると、.configがデフォルトで上書きされます。多くのxxx_defconfigファイルがあり、どのファイルを使用しているかはわかりません。
私は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
「SRC_URI」のbuild.logを確認して、私はこれを見つけました:
# $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の回答の補遺の提案1に従いました。つまり:
Evkボード用のu-boot-imxをビルドするときに使用するxxx_defconfigファイルのパッチを作成します(この場合は[SOURCE DIR]/configs/mx6ull_14x14_evk_defconfig) )
.bbappendを使用して、パッチをレイヤーdirに配置します。
.bbappendを次のように変更しました:
_
FILESEXTRAPATHS_prepend := "${THISDIR}:"
SRC_URI += " file://mx6ull_14x14_evk_defconfig.patch;patchdir=${S}/configs "
これはうまくいきました! (つまり、パッチに入れた調整済みの自動ブート遅延は、u-boot-imxで使用されました)。
最初の方法の方が良さそうだったので、提案2は試していません。
技術的には、あなたが説明したプロセスは私には正しいように聞こえます。ただし、注意すべき障害がいくつかあり、それぞれ確認する必要があります。
これはあなたに当てはまるようですが(デバッグ出力から判明しました)、これは通常、次のように簡単に確認できます。
bitbake-layers show-appends
これにより、現在のビルド状況で有効なすべての追加の完全かつ詳細なリストが表示されます。
複数のレシピが関係している場合、事態は複雑になり、お互いを上書きする可能性があります。確認する
bitbake -e u-boot-imx
実際に何が起こるかを確認します。これは、less(または選択したページャー)にパイプして、変更された値(SRC_URIなど)を検索することと組み合わせるのが最適です。
2.からの情報があれば、これはかなり簡単です。呼び出された変数を確認します
UBOOT_MACHINE
これは、u-bootが実際に表示するものです。
特に-fスイッチと-cスイッチを組み合わせると、基本的にタスクの依存関係をいじるので、予期しない結果になる可能性があります。私の経験では、何か
bitbake -c clean u-boot-imx && bitbake u-boot-imx
構成、パッチ適用など、ビルドの依存関係全体を通過するため、より適切に機能するはずです。
編集/補遺
私はOE開発者に確認しましたが、主な問題は、defconfigメカニズムが(linux-)カーネル固有であることであり、それがkernel-devマニュアルで説明されている理由でもあります。
したがって、構成を実際のビルドに組み込むには、1.5のソリューションがあります。
U-bootソースへのパッチを準備します。あなたの場合、それはおそらくすでに使用されているdefconfigファイルへのほんの小さな変更です。パッチを正規の形式にしてSRC_URIに追加すると、自動的にピックアップされてトリックが実行されます。
完全な形式で構成を準備します(defconfigを削除したバージョンではありません)。次に、それをSRC_URIに追加し、.bbappendの追加タスクで使用します。
do_compile_prepend() {
cp YOURFILENAME ${S}/.config
}
これにより、コンパイルが始まる前に新しい構成が直接挿入されます。少し工夫する必要があるかもしれませんが、あなたは確かにアイデアを得ます。別のアプローチは、元のファイルにdefconfigを挿入することです。
そうは言っても、私は最初の方法を強くお勧めします。
プライベート.config
ファイル全体をu-bootビルドフォルダーにコピーする必要はありません。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
}
`
スペースは、検索および置換パターン内で完全に問題ありません。 ${BOARD_DEVICE_TREE}
は、Yocto構成ファイルの1つで定義できます。この方法は、レシピベースのパッチリストですでにパッチが適用されているソース/ヘッダーファイルにも適しています。