Yoctoを使用した組み込みLinuxシステムの構築

序文
1.Yoctoソフトウェアのソースコードを入手する
2. Yocto ビルドディレクトリを初期化します。
3. 組み込み Linux システムを構築する
4. カスタマイズされた組み込み Linux システム
5、uboot移植
6. 穀粒移植
7. ルートファイルシステムを構築する
要約する

序文

一般に、完全な組み込み Linux システムには、主に U-Boot、Linux カーネル、およびルートファイルシステムが含まれています。組み込み Linux システムの構築とは、実際には、使用するハードウェアプラットフォームに U-Boot、Linux カーネル、およびルートファイルシステムを移植することであり、実際のプロジェクトのニーズに応じて、構築された組み込みシステムにサードパーティが提供するソフトウェアを追加することも含まれます。これにより、アプリケーションプログラムは製品要件を迅速、便利、かつ確実に実現できます。組み込み Linux システムを構築するには多くの方法とツールがありますが、この記事では Yocto を使用して、NXP の imx8mm プラットフォーム上で実行される組み込み Linux システムを構築します。Yocto プロジェクトは、その柔軟性と使いやすさで組み込み Linux の世界ではよく知られています。Yocto プロジェクトの目的は、組み込みハードウェアおよびソフトウェアメーカー向けの Linux ディストリビューションを作成することであり、多くのコアボードメーカーが Yocto を使用して、対応する組み込み Linux ディストリビューションを構築しています。この共有は、Yocto の基本的な紹介として機能し、Yocto に基づいて組み込み Linux システムを構築する基本的なプロセスと方法を理解するのに役立ちます。

1.Yoctoソフトウェアのソースコードを入手する

Yocto 作業パス /opt/work/yocto-kirkstone に切り替えて、次のリポジトリコマンドを使用して Yocto プロジェクトを取得します (NXP 公式 imx-manifest.git プロジェクトの imx-linux-kirkstone ブランチを複製します)。

repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-kirkstone -m imx-5.15.32-2.0.0.xml

注: 上記の手順を実行する前に、ubuntu 環境に Python3 をインストールする必要があります。

クローン作成が完了すると、/opt/work/yocto-kirkstoneディレクトリにファイルが作成されます/.repo/manifests/imx-5.15.32-2.0.0.xml。これらのファイルは、imx-linux-kirkstone ブランチで使用される Git ライブラリを定義します。最後に、/opt/work/yocto-kirkstoneディレクトリでrepo syncコマンドを実行して Yocto プロジェクトを取得します。

Yocto プロジェクトのソースコードを正常に取得すると、 Yocto 作業パスの下に、、およびその他のファイル/opt/work/yocto-kirkstone/が取得されます。の：imx-setup-release.shsetup-environmentsources
ここに画像の説明を挿入

imx-setup-release.sh: このスクリプトは、Yocto を初期化して組み込み Linux システムの作業環境を構築するために使用されます。
setup-environment: このスクリプトは、imx-setup-release.shスクリプトの実行時に入力されたパラメータに従ってYocto 作業環境をセットアップしますMACHINE。DISTRO-b <build_dir>
ソースフォルダー: このフォルダーには、組み込み Linux システムの構築に使用されるソースコードやコンパイルツールなど、多くのファイルが保存されます。
Base: このフォルダーには主に、Yocto の作業環境を構築するときに使用される bblayers.conf と setup-environment が格納されます。
meta-advantech : プロジェクト開発はこのレイヤーを使用します。
meta-clang: C 言語ファミリーのフロントエンドと LLVM コンパイラのバックエンド。
meta-browser : gnome、mozilla などのいくつかのブラウザを提供します。
meta-freescale : Freescale ARM 公式リファレンスボードに基づいたいくつかの基本的なサポートソフトウェアを提供します。
メタimx：
- meta-bspuboot とカーネルの構成情報を含むディレクトリは、
  sources/meta-imx/meta-bsp/recipes-bsp/u-bootsources
  /meta-imx/meta-bsp/recipes-kernelです。
- meta-sdkGoogle Chrome の bbappend ファイルなど、いくつかの更新されたソフトウェアが含まれるディレクトリは、
  sources/meta-imx/meta-sdk/dynamic-layers/chromium-browser-layer/recipes-browser/chromium です。
- meta-ml：機械学習関連のソフトウェア。
meta-freescalse-distro: いくつかの公式組み込み Linux ディストリビューション。
meta-freescalse-3rdparty: サードパーティのボードサポートソフトウェア。
meta-nxp-demo- experience: 一部のデモは NXP NXP によって公式に提供されます。
meta-openembedded: Yocto の構築に使用されるツールソフトウェアを定義する OE カーネルのコレクション。
meta-qt6: QT6 関連のソフトウェア。
poky: Yocto の基本ディストリビューションは、このバージョンに基づいて、独自の組み込み Linux ディストリビューションを構築します。

i.MXボードの構成は、カーネルといくつかのボードレベルのハードウェア構成情報を含め、主にmeta-imxとでmeta-freescale定義されることに注意してください。LinuxU-Boot

2. Yocto ビルドディレクトリを初期化します。

リポジトリを通じて Yocto プロジェクトのソースコードを取得した後、Yocto ビルドディレクトリを初期化する必要もあります。これは、Yocto が組み込み Linux システムの作業環境を構築するために使用します (実際には、いくつかのフォルダーを作成し、いくつかの変数値を初期化し、構成ファイルを取得します)。特定の組み込み Linux ディストリビューションを構築するため)。リポジトリによって取得された Yocto プロジェクトのソースパス (/opt/work/yocto-kirkstone/) の下で、Freescales は imx-setup-release.sh スクリプトを提供します。

2.1.imx-setup-release.sh スクリプトの実行

imx-setup-release.sh が存在するパスに次のコマンドを入力して、imx-setup-release.sh スクリプトを実行します。

MACHINE=imx8mmeamb9918a1 DISTRO=fsl-imx-xwayland source  imx-setup-release.sh -b eamb9918a1

imx-setup-release.shスクリプトを実行すると、最初にいくつかの EULA ライセンスが読み取られ、読み取りが完了すると、Yocto ビルドディレクトリの初期化が完了します。
スクリプトの実行終了後、eamb9918a1自動的にフォルダが生成され、eamb9918a1そのパスに切り替わり、このフォルダ配下で以降のシステム構築処理が完了します。同時に、eamb9918a1 フォルダーの下に conf フォルダーが生成されます。conf
ここに画像の説明を挿入
フォルダーには 2 つの重要なファイルbblayers.confとlocal.conf2 つの構成ファイルがあります。

eamb9918a1/conf/bblayer.conf: この構成ファイルは、組み込み Linux システムディストリビューションを構築するために必要なメタレイヤーを定義します。
eamb9918a1/conf/local.conf: この設定ファイルはMACHINEおよびDISTROの設定項目を定義します。

2.2.imx-setup-release.sh脚本解析

imx-setup-release.sh スクリプトの実行中は、次の 3 つの主要なパラメータを入力する必要があります。

MACHINE=imx8mmeamb9918a1
DISTRO=fsl-imx-xwayland
-beam9918a1

一般に、imx-setup-release.sh スクリプトは、これら 3 つのパラメーターを通じてビルド環境を決定します。その中で、一時ファイル、ビルドログ、最終的に生成されたインストールファイルなどを保存するため-b eamb9918a1にeamb9918a1フォルダーが生成されます。同時に、Yocto はこれら 2 つのパラメータDISTROに従ってMACHINE対応する設定ファイル (.conf) を見つけます。これらの設定ファイルは、構築する組み込み Linux システムの機能とステータスを定義します。
例えば：

imx-setup-release.sh スクリプトは、DISTRO の値に応じて、ソースパスの下で DISTRO の値に対応する .conf ファイルを検索します。例: 、いくつかの変数が含まれるpath の下でファイルが検索されます。定義されている場合は、組み込み Linux ディストリビューションの構成に使用します。同時に、そのパスの下に、組み込み Linux システムの構成をサポートするハードウェアプラットフォームが定義されていることがわかります。DISTRO= fsl-imx-xwaylandsources/meta-imx/meta-sdk/conf/distrofsl-imx-xwayland.confsources/meta-imx/meta-bsp/conf/machine
imx-setup-release.sh は、 MACHINEの値に従って、ソースパスの下でMACHINE値に対応する .conf ファイルを検索します。例: 、構成用にいくつかの変数が定義されているpath の下のファイルが検索されます。組み込み Linux が実行されるハードウェアプラットフォーム。MACHINE= imx8mmeamb9918a1sources/meta-advantech/meta-adv-imx/conf/machineimx8mmeamb9918a1.conf

2.3. setup-environment スクリプトの実行

imx-setup-release.shスクリプトでは、 setup-environmentDISTRO=$FSLDISTRO MACHINE=$MACHINE . ./$PROGNAME $BUILD_DIRスクリプトが呼び出されます。

# Set up the basic yocto environment
if [ -z "$DISTRO" ]; then
   DISTRO=$FSLDISTRO MACHINE=$MACHINE . ./$PROGNAME $BUILD_DIR
else
   MACHINE=$MACHINE . ./$PROGNAME $BUILD_DIR
fi

setup-environmentスクリプトのヘルプ情報を参照してください。YoctoパスでサポートされているMACHINEがリストされ、setup-environmentスクリプトの使用方法も説明されています。

usage()
{
    
    
    echo -e "
Usage: MACHINE=<machine> DISTRO=<distro> source $PROGNAME <build-dir>
Usage:                                   source $PROGNAME <build-dir>
    <machine>    machine name
    <distro>     distro name
    <build-dir>  build directory

The first usage is for creating a new build directory. In this case, the
script creates the build directory <build-dir>, configures it for the
specified <machine> and <distro>, and prepares the calling shell for running
bitbake on the build directory.

The second usage is for using an existing build directory. In this case,
the script prepares the calling shell for running bitbake on the build
directory <build-dir>. The build directory configuration is unchanged.
"

    ls sources/meta-advantech/*/conf/machine/*.conf > /dev/null 2>&1
    ls sources/meta-freescale-distro/conf/distro/fslc-*.conf > /dev/null 2>&1
    if [ $? -eq 0 ]; then
        echo -e "
Supported machines: `echo; ls sources/meta-advantech/*/conf/machine/*.conf \
| sed s/\.conf//g | sed -r 's/^.+\///' | xargs -I% echo -e "\t%"`

Supported Freescale's distros: `echo; ls sources/meta-freescale-distro/conf/distro/fslc-*.conf \
| sed s/\.conf//g | sed -r 's/^.+\///' | xargs -I% echo -e "\t%"`

Available Poky's distros: `echo; ls sources/poky/meta-poky/conf/distro/*.conf \
| sed s/\.conf//g | sed -r 's/^.+\///' | xargs -I% echo -e "\t%"`

Examples:

- To create a new Yocto build directory:
  $ MACHINE=imx8mmeamb9918a1 DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b imx8mmeamb9918a1

- To use an existing Yocto build directory:
  $ source $PROGNAME build
"
    fi
}

imx-setup-release.sh スクリプトと setup-environment スクリプトを比較すると、imx-setup-release.sh スクリプトは主に EULA ライセンス関連の操作を完了し、レイヤー、マシン、ディストリビューション、その他の情報を構成ファイルに書き込みます。環境スクリプトを実行し、ビルドディレクトリ emab9918 の作成を完了し、DISTRO と MACHINE の 2 つのパラメーターに従って対応するパスで構成ファイルを見つけ、ビルドディレクトリで bitbake ビルドツールを実行するシェルを呼び出すための環境を準備します。

3. 組み込み Linux システムを構築する

3.1. BitBake ビルドシステムプロセスの簡単な分析

Bitbake ビルドの最初のステップは、構築される組み込み Linux システムディストリビューションの機能と特性の一部を決定するメタデータベース構成ファイルを解析することです。まず、メタデータの
概念をいくつか理解しましょう。リポジトリを通じて yocto プロジェクトを取得した後、ソースディレクトリにはいくつかのフォルダーがあり、これらのフォルダーは1 つずつメタデータです。bitbake を使用してシステムを構築する場合、どのメタデータが使用されるかはスクリプトの初期化時に決定されます。build /conf/パスの下にbblayers.conf構成ファイルが生成され、bitbake ツールはbblayers.confに基づきます。 file の定義により、使用するメタデータが決まります。Recipe : メタデータでは、source/meta-xxx フォルダーに保存されている多くのファイルがあります。:このフォルダーの下にある bbclass ファイル、bbclass ファイルは一般的な関数または変数を保存します。他のレシピでは、inheritキーワードによって参照できます。C++ のクラスの概念に少し似ています。: conf フォルダー内のlayer.conf ファイルは、メタデータで使用されるどの .bb および .bbappend ファイルが組み込み Linux システムの構築に参加するかを定義します。: このフォルダーには、組み込み Linux システムの構築に必要なソフトウェアパッケージまたはソースコードを定義する .bb または .bbappend ファイルが多数あります。主に次のものが含まれます。
imx-setup-release.sh
ここに画像の説明を挿入

classes
conf
recipes-xxx

ソフトウェアパッケージの基本情報: 作成者、ホームページ、ライセンスなど。
バージョン情報
依存ファイル
パッケージをダウンロードする場所と方法
ソフトウェアパッケージのパッチ情報: パッチが必要かどうか、パッチのダウンロードアドレスと方法など。
設定方法、ソフトウェアパッケージのコンパイル方法、インストール場所など。
例として、パッケージ u-boot の bb ファイルを取り上げます。

qing@Qing:/opt/work/yocto-kirkstone/sources/meta-imx/meta-bsp/recipes-bsp/u-boot$ cat u-boot-imx_2022.04.bb 
# Copyright (C) 2013-2016 Freescale Semiconductor
# Copyright 2018 (C) O.S. Systems Software LTDA.
# Copyright 2017-2022 NXP

require recipes-bsp/u-boot/u-boot.inc
###############################################################
########### For upstream u-boot-imx-common_2022.04.inc ########
DESCRIPTION = "i.MX U-Boot suppporting i.MX reference boards."

LICENSE = "GPL-2.0-or-later"
LIC_FILES_CHKSUM = "file://Licenses/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263"

UBOOT_SRC ?= "git://source.codeaurora.org/external/imx/uboot-imx.git;protocol=https"
SRCBRANCH = "lf_v2022.04"
SRC_URI = "${UBOOT_SRC};branch=${SRCBRANCH}"
SRCREV = "1c881f4da83cc05bee50f352fa183263d7e2622b"
LOCALVERSION = "-${SRCBRANCH}"

DEPENDS += "flex-native bison-native bc-native dtc-native gnutls-native"

S = "${WORKDIR}/git"
B = "${WORKDIR}/build"

inherit fsl-u-boot-localversion

BOOT_TOOLS = "imx-boot-tools"

###############################################################
# require recipes-bsp/u-boot/u-boot-imx-common_${
      
      PV}.inc

PROVIDES += "u-boot"

inherit uuu_bootloader_tag

UUU_BOOTLOADER            = ""
UUU_BOOTLOADER:mx6-nxp-bsp        = "${UBOOT_BINARY}"
UUU_BOOTLOADER:mx7-nxp-bsp        = "${UBOOT_BINARY}"
UUU_BOOTLOADER_TAGGED     = ""
UUU_BOOTLOADER_TAGGED:mx6-nxp-bsp = "u-boot-tagged.${UBOOT_SUFFIX}"
UUU_BOOTLOADER_TAGGED:mx7-nxp-bsp = "u-boot-tagged.${UBOOT_SUFFIX}"

do_deploy:append:mx8m-nxp-bsp() {
    
    
    # Deploy u-boot-nodtb.bin and fsl-imx8m*-XX.dtb for mkimage to generate boot binary
    if [ -n "${UBOOT_CONFIG}" ]
    then
        for config in ${
    
    UBOOT_MACHINE}; do
            i=$(expr $i + 1);
            for type in ${
    
    UBOOT_CONFIG}; do
                j=$(expr $j + 1);
                if [ $j -eq $i ]
                then
                    install -d ${
    
    DEPLOYDIR}/${
    
    BOOT_TOOLS}
                    install -m 0777 ${
    
    B}/${
    
    config}/arch/arm/dts/${
    
    UBOOT_DTB_NAME}  ${
    
    DEPLOYDIR}/${
    
    BOOT_TOOLS}
                    install -m 0777 ${
    
    B}/${
    
    config}/u-boot-nodtb.bin  ${
    
    DEPLOYDIR}/${
    
    BOOT_TOOLS}/u-boot-nodtb.bin-${
    
    MACHINE}-${
    
    type}
                fi
            done
            unset  j
        done
        unset  i
    fi
}

PACKAGE_ARCH = "${MACHINE_ARCH}"
COMPATIBLE_MACHINE = "(mx6-generic-bsp|mx7-generic-bsp|mx8-generic-bsp)"

bbappendファイル: .bbappend ファイルは、レシピファイル情報を拡張または上書きするために使用されます。各 bbappend ファイルには対応するレシピファイルがあり、2 つのファイルは同じファイル名を使用しますが、接尾辞が異なります。たとえばu-boot-imx_2022.04.bb、とu-boot-imx_2022.04.bbappend。%ワイルドカードレシピファイル名にも使用できます。たとえば、busybox_1.21.%.bbappendという名前の追加ファイルは、busybox_1.21.x.bb という名前のレシピファイルを拡張して上書きでき、ファイル名の x には、busybox_1.21.1.bb、busybox_1.21.2. bb などの任意の文字列を使用できます。通常、バージョン番号をワイルドカードとして指定するにはパーセント記号を使用します。

上記の概念を明確にした後、bitbake の構築プロセスについて話しましょう.
一般に、bitbake は build/conf/bblayers.conf レイヤー.conf で定義された有効なメタレイヤーに従って、対応するメタレイヤー/conf ディレクトリを見つけます。layer.conf では、現在のレイヤーで使用されるレシピがbbFILESとで指定されます。bbPATHつまり、bbPATH を通じて、どのパスでどの .bb および .bbappend ファイルを見つけるかを bitbake に伝え、これらのファイルを通じて、どのソフトウェアパッケージまたはソースコードが組み込み Linux ディストリビューションの構築に使用されるかを bitbake に伝えます。レシピが解析されると、「タスクリスト」が生成され、bitbake -sコマンドを使用して現在のプロジェクト内のビルド可能なタスクをすべてリストできます。次のステップでは、bitbake は「タスクリスト」に従ってシステムを構築します。実際、システムの構築プロセスでは、タスクの形式で実行されます。

3.2. BitBake ビルドシステムタスクの簡単な分析

パッケージをビルドする最も単純な方法を実行する場合bitbake <package_name>、bitbake はこのパッケージのレシピファイルを検索し、見つかった後にレシピ内の構成オプションを解析して、次のタスクを順番に実行します。

do_fetch ソースコードをダウンロード
do_unpack はソースコードを解凍します
do_patch ソースコードにパッチを適用する
do_configure 構成
do_compile コンパイル
do_install インストール、ファイルをターゲットディレクトリにコピーします
do_package はインストールパッケージを生成し
、 **-c** パラメーターを使用して個々のタスクを実行することもできます。たとえば、ソースコードのダウンロードのみでbitbake -c fetchを実行できます。

3.2.1 ソースコードを取得する

ソースコードを取得するプロセスはdo_fetchタスクによって完了します。このタスクは主にSRC_URI変数によって制御され、ソースコードの場所、ソースコードを取得するためのプロトコルなどを指定できます。ソースコードには、アップストリームプロジェクトリリース、ローカルプロジェクトファイル、およびgit/svn などのコードバージョンマネージャーの 3 つのソースがあります。
アップストリームプロジェクトリリースは、zip、tar パッケージなどのアーカイブファイルの形式で存在します。
バージョン管理マネージャーを通じてリリースされたソースコードは、通常、git/svn プロトコルを使用してダウンロードされます。たとえば、このメソッドを使用してソースコードを指定すると、bitbake がLinux システムの構築プロセスでdo_fetchタスクを実行するときに、ソースコードのクローンが作成され、で定義されたSRC_URIおよびSRCREV変数に従ってシステムの構築に参加します。レシピ。さらに、ソースコードがアーカイブファイルとして取得された場合、do_unpackタスクは ${S} 変数が指すパスにソースコードを解放します。ソースコードの圧縮パッケージがダウンロードされ、圧縮パッケージの内部構造が最上位のサブディレクトリ ${ の規則に準拠している場合、 S のデフォルト値は ${WORKDIR} / ${BPN} - ${PV} です。 BPN} - ${PV} の場合、S を設定する必要はありません。ただし、圧縮パッケージがこの規則に準拠していない場合、またはソースコードが git などのバージョン管理サーバーから複製された場合は、S を手動で設定する必要があります。たとえば、git はソースコードを ${WORKDIR}/git パスに複製するため、この値をレシピで設定する必要があります。
次の図は、ソースコードの取得とリリースの概略図です。linux
ここに画像の説明を挿入
-imx_5.15.bb ファイルと同様に、S の値を手動で設定する必要があります。

KERNEL_SRC = "git://github.com/Advantech-IIoT/linux-imx.git;protocol=https;branch=${SRCBRANCH}"
SRC_URI = "${KERNEL_SRC}"
SRCREV = "065aa1f91e58e1108720dc701a074760be878962"

S = "${WORKDIR}/git"

eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/linux-imx/5.10.72+gitAUTOINC+b8bb4918e6-r0/git最終的なソースコードがパスにダウンロードされます。

3.2.2 パッチ適用

ソフトウェアがソースコードを取得したら、パッチを適用する必要があります。SRC_URI では、patch、.diff、またはこれらの接尾辞が付いた圧縮パッケージ diff.gz はすべてパッチコードです。do_patch タスクの実行時にパッチが自動的に適用されます。通常、パッチファイルは ${BP} ${BPN} という名前のフォルダー、またはレシピファイルの隣のファイルに置きます。
このうち、パッチファイルはfilesディレクトリ配下に配置されます。

root@ning-QiTianM620-N000:sources/meta-advantech/meta-adv-imx/recipes-extended/cpio# ls
cpio_%.bbappend  files
root@ning-QiTianM620-N000:sources/meta-advantech/meta-adv-imx/recipes-extended/cpio/files$ ls
0001-Wrong-CRC-with-ASCII-CRC-for-large-files.patch

このうちパッチファイルは、ビルドパッケージのレシピ名 ${BPN} で作成されたフォルダである chromium-ozone-wayland ディレクトリ配下に配置されています。

root@ning-QiTianM620-N000:/recipes-browser/chromium/chromium-ozone-wayland# ls
0001-Add-knob-for-imx-gpu.patch

3.2.3 構成

ほとんどのソフトウェアはコンパイル前に、通常は次の 3 つの方法で構成する必要があります。

Autotools: ソースファイルにconfigure.ac ファイルがある場合、ソフトウェアは Autotools を使用してビルドされ、レシピファイルは autotools クラスを継承する必要があります (inherit autotools)。この場合、do_configure を含める必要はありません。必要な構成オプションを渡すには、EXTRA_OECONF または PACKAGE_CONFARGS を設定する必要がある場合があります。
CMake: ソースファイルに CMakeLists ファイルがある場合、ソフトウェアは CMake でビルドされ、レシピファイルは cmake クラスを継承する必要があり (inherit cmake)、do_configure タスクを含める必要はなく、いくつかの調整を行うことができます。 EXTRA_OECMAKE を設定することによって。
その他; 場合によっては、構成のレシピに do_configure タスクを指定する必要があります。

3.2.4 コンパイル

構成が成功すると、システムは自動的に do_compile タスクを呼び出してコンパイルします。

3.2.5 インストール

インストール中、システムコール do_install タスクによって生成されたファイルとディレクトリ構造は、ターゲットデバイス上のミラーの場所にコピーされます。${S} ${B} および ${WORKDIR} ディレクトリ内のファイルは ${D} ディレクトリにコピーされ、ターゲットシステム上に構造が作成されます。autotools と cmake で構築されたソフトウェアパッケージの場合、システムはインストールコマンドを呼び出してインストールタスクを実行します。それ以外の場合は、do_install タスクを変更するか手動で作成する必要があります。レシピで do_install 関数を定義し、インストール手順を追加できます。
手動でインストールする場合は、まず do_install 関数で install -d を使用して、${D} の下にディレクトリを作成する必要があります。これらのディレクトリが存在すると、install を使用してこれらのディレクトリにファイルを手動でインストールできます。
以下のことを説明するために、.bb ファイル内の do_install 関数を例として取り上げます。

do_install() {
    
    	
	install -d ${
    
    D}/usr/bin/
    install -m 755 ${
    
    S}/bin/gester ${
    
    D}/usr/bin/
}

3.2.6 梱包

cmake または Autotools を使用する場合、このステップも自動的に行われます。それ以外の場合は、do_package 関数を記述する必要があります。

4. カスタマイズされた組み込み Linux システム

Yocto システムは、ビルドシステムで使用されるソフトウェアパッケージ、ソースコード、構成情報などをメタデータの形式で整理および管理します。メタデータはある程度までレイヤーとして理解できますが、レイヤーは実際にはフォルダーです (これらのフォルダーは通常、meta-xxx の形式で名前が付けられます)。
レイヤーを使用してソースデータを管理すると、モジュラー設計手法の維持に役立ちます。レイヤーには、いくつかの特定の機能に必要なソースデータが含まれており、各レイヤーは互いに干渉しません。構築されたシステムに必要な機能が変更された場合にのみ、この機能に対応する層を変更する必要があるため、機能の独立性とモジュール設計が維持されます。

4.1. メタマイレイヤーの作成

メタレイヤーを作成するには 2 つの方法があります。1 つは手動で作成する方法、もう 1 つは bitbake-layers コマンドを使用して作成する方法です。なお、レイヤーを作成する前に、で既存のレイヤーを確認することができますhttp://layers.openembedded.org/layerindex/layers/。作成するレイヤーがすでに存在する場合は、それを直接使用できます。そうでない場合は、自分で作成する必要があります。

4.1.1 自動作成

bitbake-layers create-layer meta-mylayer

4.1.2 マニュアルの作成

1. レイヤーにデータを保存するフォルダーを作成します。通常は、meta-xxx という名前が付けられます。例: メタマイレイヤー。
2. レイヤー構成ファイルを作成します。新しく作成したレイヤーフォルダー (例：meta-mylayer) の下に conf/layer.conf ファイルを作成します。layer.conf ファイルの基本的なフレームワークは次のとおりです。

# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
   ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "mylayer"
BBFILE_PATTERN_mylayer = "^${LAYERDIR}/"
BBFILE_PRIORITY_mylayer = "5"

(1). BBPATH: 新しく追加したレイヤーのパスをグローバル変数 BBPATH に追加すると、bitbake はシステム構築時にこの変数に従って対応するレイヤーを見つけます。
(2). BBFILES: 新しく追加したレイヤーのレシピファイル (例: .bb または .bbappend ファイル) をグローバル変数 BBFILES に追加すると、bitbake はシステムの構築時にこの変数に従って対応するレシピファイルを見つけます。
(3). BBFILE_COLLECTIONS: bbFILE_COLLECTIONS 変数にレイヤー名を追加します。つまり、レイヤーフォルダー名 meta-xxx の xxx を BBFILE_COLLECTIONS に割り当てます。
(4). BBFILE_PATTERN: BBFILE_PATTERN 変数は、特定のレイヤーの BBFILES で定義されたファイルと一致するために使用される正規表現です。この変数には、特定のレイヤーの名前をプレフィックスとして付ける必要があります。
(5). BBFILE_PRIORITY: レイヤーの優先度。同じレシピが異なるレイヤで定義されている場合、BBFILE_PRIORITY に対応する高い優先度に従って、対応するレシピファイルが使用されます。
3. コンテンツを追加します。レイヤーの種類に応じて、一部のレイヤーではマシン構成とディストリビューション構成が追加されるため、そのレイヤーの下の conf/machine/ ファイルにマシン構成を追加し、このレイヤーの conf/distro/ ファイルにディストリビューション構成を追加する必要があります。

4.2. メタマイレイヤーを有効にする

新しいレイヤーを作成した後、システム構築プロセスに参加するには、そのレイヤーを有効にする必要があります。参加しているビルドシステムによって使用されるレイヤーは、eamb9918a1/config/bblayers.conf で定義されます。Freescale は、eamb9918a1/conf/bblayers.conf ファイルを変更するための imx-setup-release.sh スクリプトを公式に提供しています。Yocto ビルドディレクトリを初期化するときに、imx-setup-release.sh スクリプトを呼び出します。したがって、imx-setup-release.sh スクリプトを変更するだけです。変更方法は次のとおりです。また、meta-mylayer の相対ディレクトリを実行して、meta-mylayer を bblayers.conf ファイルに追加することも
ここに画像の説明を挿入
できます。bitbake-layers add-layer meta-mylayer

cd /opt/work/yocto-kirkstone/eamb9918a1
bitbake-layers add-layer ./sources/meta-mylayer

4.3. レシピの作成

レシピ (.bb ファイル) は、Yocto プロジェクト環境の基本コンポーネントです。新しいレシピを作成するには、比較的簡単な方法が 2 つあります。

Recipetool: Yocto が提供する、ソースファイルに基づいてレシピを自動作成するツール
既存のレシピ: 同様の機能要件を持つ既存のレシピを変更します。http://layers.openembedded.org/layerindex/branch/master/layers/には、コミュニティによって管理されている多くのレシピがあり、ニーズを満たすものを見つけて入手できます。それらを直接使用します。

recipetool create -o example/example_0.1.bb  ../../meta-mylayer/

上記の手順を実行して作成されたレシピは次のとおりです。

# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in order to be fully functional.
# (Feel free to remove these comments when editing.)

# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is
# your responsibility to verify that the values are complete and correct.
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
# No information for SRC_URI yet (only an external source tree was specified)
SRC_URI = ""

# NOTE: no Makefile found, unable to determine what needs to be done
do_configure () {
    
    
	# Specify any needed configure commands here
	:
}
do_compile () {
    
    
	# Specify compilation commands here
	:
}
do_install () {
    
    
	# Specify install commands here
	:
}

上記ファイルには、レシピの著作権ライセンス、ライセンスファイルのチェックサム、ソースコードのURIが記述され、do_configureなどのタスクの書き換えインターフェースが提供されます。

4.4. レシピのコンパイル

imx-setup-release スクリプトを使用して Yocto ビルドディレクトリを初期化した後、自動的にビルドディレクトリに入ります。このパスで次のコマンドを実行してコンパイルします。

bitbake example

その中で例となるのがレシピ名です。コンパイルプロセス中に、OpenEmbedded コンパイルシステムは、解凍されたファイルやログファイルなどを保存するレシピごとに一時フォルダーを作成します。各レシピの一時ファイルは次のように編成されています。

BASE_WORKDIR ?= "${TMPDIR}/work"
WORKDIR = "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"

例: imx8mmeamb9918a1-poky-linux はシステムアーキテクチャ、レシピファイルは rs9116nb0_git.bb、生成されるファイルパスは次のとおりです。

eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/rs9116nb0/2022.06_git-r0

さらに、次のコマンドを使用して、パッケージを構築するときに作業ディレクトリを見つけることができます。

bitbake -e linux-imx | grep ^WORKDIR=  //定位linux-imx工作目录
bitbake -e linux-imx | grep ^S=        //定位源码解压后的位置
bitbake -e linux-imx | grep ^B=        //定位源码编译目录
bitbake -e linux-imx | grep -E "^PN=|^PV=|^PR="  //定位构建包的配方名称、配方版本和构建包的配方的修订版

上記のファイルディレクトリの下には、いくつかの重要なフォルダーがあります。

image : ターゲットシステムにインストールするファイルを保存し、インストールパスに従って保存します。
deploy : インストールパッケージを rpm/deb 形式で保存します。
temp : ビルドプロセス中に実行されたすべてのタスク命令と、実行されたプロセスのログを保存します。
BitBake がタスクを実行する順序は、そのタスクスケジューラによって制御されます。${WORKDIR}/temp/ディレクトリ配下の、からrun_始まるファイルは解析後の各タスクの詳細内容を記録し、log_から始まるファイルはタスク実行時のログを記録し、から始まるlog.task_orderファイルは現在のターゲットで実行されたタスクを順に記録します。

4.5. マシンファイルの作成

一般に、カスタムハードウェアプラットフォームは、Freescale によって公式に提供されている imx8mmevk ハードウェアプラットフォーム設定を参照します。ハードウェアインターフェイスドライバーが正常に動作することを確認するには、カスタムハードウェアインターフェイス設計に基づいて imx8mmevk ハードウェアプラットフォームを変更する必要があります。sources/meta-imx/meta-bsp/conf/machineしたがって、パスの下のファイルimx8mmevk.confを、システムの構築に使用するハードウェアプラットフォームの構成ファイルとして参照する必要があります。imx8mmevk.confファイルは主に次の部分で構成されます。

include ファイルimx8mmevk.conf ファイルでは、ファイルは
require キーワードによって参照され、ファイルでは、ファイルは require キーワードによって参照されます。sources/meta-freescale/conf/machine/imx8mm-lpddr4-evk.confimx8mm-lpddr4-evk.confimx8mm-evk.inc

qing@Qing:sources$ cat meta-freescale/conf/machine/imx8mm-lpddr4-evk.conf
......
require include/imx8mm-evk.inc
......

ファイルimx8mm-evk.inc内で参照されている

require conf/machine/include/imx-base.inc
require conf/machine/include/arm/armv8a/tune-cortexa53.inc

このうち、imx8mm は coretexa53 シリーズのコアに属しているため、coretexa53.inc ファイルが参照されます。このファイルはsources/poky/meta/conf/machine/include/arm/armv8a/tune-cortexa53.incパスの下にあり、主に coretexa53 アーキテクチャコアに関連するいくつかの定義を定義します。coretexa53.inc については、変更する必要はありません。それ。さらに、imx-base.inc ファイルはsources/meta-freescale/conf/machine/include/imx-base.incパスの下にあり、主に uboot のエントリアドレス、デフォルトのカーネル定義など、imx シリーズ CPU のいくつかのデフォルトパラメータを定義します。

カーネルデバイスツリーの定義
imx8mmevk.conf ファイルでは、コンパイル中に Linux カーネルによって生成されるデバイスツリーファイルが、変数KERNEL_DEVICETREEによって定義されます。コンパイル中に Linux カーネルによって生成されたデバイスツリーファイルを変更する必要がある場合は、KERNEL_DEVICETREE変数の値を変更する必要があります。

# Include device trees for other boards for internal test
KERNEL_DEVICETREE += " \
    freescale/imx8mm-ddr4-evk.dtb \
    freescale/imx8mm-ddr4-evk-pcie-ep.dtb \
    freescale/imx8mm-ddr4-evk-rm67191.dtb \
    freescale/imx8mm-ddr4-evk-rm67191-cmd-ram.dtb \
    freescale/imx8mm-ddr4-evk-rm67199.dtb \
    freescale/imx8mm-ddr4-evk-rm67199-cmd-ram.dtb \
    freescale/imx8mm-ddr4-evk-revb.dtb \
    freescale/imx8mm-ddr4-evk-revb-rm67191.dtb \
    freescale/imx8mm-ddr4-evk-revb-rm67191-cmd-ram.dtb \
    freescale/imx8mm-ddr4-evk-revb-rm67199.dtb \
    freescale/imx8mm-ddr4-evk-revb-rm67199-cmd-ram.dtb \
"

U-Boot 構成
imx8mm-lpddr4-evk.conf ファイルでは、対応する U-Boot デフォルト構成ファイルがカスタムハードウェアプラットフォームに追加され、次に示すようにUBOOT_CONFIG変数を設定することで有効になります。

UBOOT_CONFIG ??= "sd"
UBOOT_CONFIG_BASENAME = "imx8mm_evk"
UBOOT_CONFIG[sd]      = "${UBOOT_CONFIG_BASENAME}_defconfig,sdcard"
UBOOT_CONFIG[mfgtool] = "${UBOOT_CONFIG_BASENAME}_defconfig"
UBOOT_CONFIG[fspi]    = "${UBOOT_CONFIG_BASENAME}_fspi_defconfig"

imx8mm-evk.inc ファイルでは、コンパイル時に uboot によって使用されるデバイスツリーファイルは、変数UBOOT_DTB_NAMEによって定義されます。

# Set u-boot DTB
UBOOT_DTB_NAME = "${KERNEL_DEVICETREE_BASENAME}.dtb"

DDR FIRMWARE の設定
imx8mm-lpddr4-evk.conf ファイルでは、コンパイル中に DDR によって使用される bin ファイルが変数DDR_FIRMWARE_NAMEによって定義されます。

# Set DDR FIRMWARE
DDR_FIRMWARE_NAME = " \
 lpddr4_pmu_train_1d_imem.bin \
 lpddr4_pmu_train_1d_dmem.bin \
 lpddr4_pmu_train_2d_imem.bin \
 lpddr4_pmu_train_2d_dmem.bin \
"

4.6. システムイメージのカスタマイズ

4.6.1 IMAGE_INSTALL メソッドの使用

既存のシステムイメージファイルを変更する。例:imx-image-fullシステムに基づいてシステムイメージファイルを構築したいが、追加の strace パッケージを追加する必要がある場合は、ファイルを作成し、imx-image-full.bbappend新しいファイル.bbappendに次のコードを追加することで strace パッケージを追加できます。

IMAGE_INSTALL:append = "strace"

さらに、ファイルを変更することもできますconf/local.confが、ここでの変更はグローバルであり、ビルドされたすべてのイメージファイルが有効になるため、プロジェクト管理には役立ちません。最善の方法は、変更するイメージに対応する新しい bbappend ファイルを作成し、特定のイメージファイルに特定のパッケージのみをインストールすることです。

パッケージを追加する上記の方法は、IMAGE_INSTALL変数を設定してターゲットイメージシステムにパッケージを追加または削除することです。パッケージを追加するには :append 構文を使用し、パッケージを削除するには :remove 構文を使用できます。パッケージとパッケージグループは、通常、 IMAGE_INSTALL変数設定を通じてターゲットイメージにインストールされます。パッケージグループはパッケージのコレクションであり、通常は .bb ファイルによって定義されます。

4.6.1 IMAGE_FEATURES メソッドの使用

ターゲットイメージの特性を設定するには、IMAGE_INSTALL変数を使用する以外に、 IMAGE_FEATURES変数を使用することもできます。この変数はパッケージおよびパッケージグループに限定されず、ユーザーが独自に定義できます。:append および :remove 構文を使用してIMAGE_FEATURES変数の内容を変更することもできます。プロジェクトで使用されているように:

IMAGE_FEATURES:remove = " ssh-server-dropbear"
IMAGE_FEATURES:append = " ssh-server-openssh"

上記では、IMAGE_FEATURES変数を通じて、パッケージ ssh-server-openssh がfsl-image-multimediaイメージに追加され、パッケージ ssh-server-dropbear が削除されました。また、以下のコマンドを実行すると、上記のIMAGE_FEATURES:removeやIMAGE_FEATURES:appendによる追加や削除もパッケージグループであることがわかります。

$ bitbake -e fsl-image-multimedia | grep ^FEATURE_PACKAGES
FEATURE_PACKAGES_ssh-server-dropbear="packagegroup-core-ssh-dropbear"
FEATURE_PACKAGES_ssh-server-openssh="packagegroup-core-ssh-openssh"

「定義済み」ssh-server-opensshは、上記の 2 つのパッケージグループの .bb ファイルをソースコードディレクトリ内で直接検索できることを意味します。packagegroup-core-ssh-opensshssh-server-dropbearpackagegroup-core-ssh-dropbear

$ find ./ -name "packagegroup-core-ssh-openssh*"
./poky/meta/recipes-core/packagegroups/packagegroup-core-ssh-openssh.bb

4.6.3 PACKAGE_EXCLUDEの使用

最後に、削除したいパッケージがIMAGE_INSTALLおよびIMAGE_FEATURESの定義に表示されない場合、通常はパッケージグループにカプセル化されます。このとき、PACKAGE_EXCLUDE変数を使用して設定できます。

PACKAGE_EXCLUDE = "package_name package_name package_name ..."

リストされたパッケージはいずれもターゲットイメージにインストールされません。ここに問題がある可能性があります。他のパッケージがここにリストされているパッケージ (つまり、RDEPENDS 変数にリストされている) に依存している場合、ビルド時にエラーが報告され、対応する依存関係を変更する必要があります。例として connman を削除します。

PACKAGE_EXCLUDE = "connman"

ビルド時に以下のエラーが発生します。

$ bitbake fsl-image-machine-test
...
Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 packagegroup-core-tools-testapps : Depends: connman-client but it is not going to be installed
                                    Depends: connman-tools but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
...

packagegroup-core-tools-testapps パッケージグループの connman-client と connman-tools は両方とも connman に依存しており、これは packagegroup-core-tools-testapps.bb ファイルで確認できます。

RDEPENDS_${
    
    PN} = "\
    blktool \
    ${KEXECTOOLS} \
    alsa-utils-amixer \
    alsa-utils-aplay \
    ltp \
    connman-tools \
    connman-tests \
    connman-client \
    ${@bb.utils.contains('DISTRO_FEATURES', 'x11', "${
    
    X11TOOLS}", "", d)} \
    ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', "${
    
    X11GLTOOLS}", "", d)} \
    ${@bb.utils.contains('DISTRO_FEATURES', '3g', "${
    
    3GTOOLS}", "", d)} \
    "

新しい packagegroup-core-tools-testapps.bbappend ファイルを作成し、 _remove 構文を使用して削除できます。

RDEPENDS_${
    
    PN}_remove = "connman-tools connman-tests connman-client"

5、uboot移植

5.1.u-boot ソースコードの変更

U-Boot の移植プロセス中に、対応する uboot ソースコードを変更する必要があります。Yocto が提供するレシピを直接変更するのではなく、新しく作成したメタアドバンテックレイヤーに同じ名前のレシピを持つ bbappend ファイルを作成して、U-Boot ソフトウェアのコンパイルプロセスを構成します。uboot プロバイダーは、次のように PREFERRED_PROVIDER_virtual/bootloader_imx = "u-boot-imx" 変数によって定義され
ます。

PREFERRED_PROVIDER_virtual/bootloader_imx = "u-boot-imx"

imx8mm のプロバイダーは u-boot-imx であることがわかります。実際、/sources/meta-imx/meta-bsp/recipes-bsp/u- のパスにある u-boot-imx_2022.04 に対応しています。 boot/.bb ファイル。したがって、次のパスを作成しsources/meta-advantech/meta-adv-imx/recipes-bsp/u-boot/、u-boot-imx_2022.04.bbappend ファイルを作成しました。ファイルの内容は次のとおりです。

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

UBOOT_SRC = "git://github.com/Advantech-IIoT/uboot-imx.git;protocol=https"
SRCBRANCH = "lf_v2022.04"
SRC_URI = "${UBOOT_SRC};branch=${SRCBRANCH}"
SRCREV = "642b7925a0bcfc145e5ef51214b008afe472cc6d"
LOCALVERSION = "-${SRCBRANCH}"

上記の bbappend ファイルから、SRC_URI 変数と SRCREV 変数を使用して、ビルドシステムに参加する uboot ソースコードの場所を指定します。

5.2.u-bootデバイスツリーファイル

前に machine.conf ファイルを作成したときに、コンパイル時に uboot によって使用されるデバイスツリーファイルを定義するには、変数UBOOT_DTB_NAMEを設定する必要があると述べました。uboot の他の構成の設定も machine.conf ファイルで設定されます。

5.3.u-boot ソースコードの構築

コマンドを使用して Yocto 作業環境がロードされた後MACHINE=imx8mmeamb9918a1 DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b eamb9918a1、カーネルは次の 2 つの方法でコンパイルできます。
コマンドの実行:bitbake imx-image-fullシステム全体をコンパイルする
コマンドの実行: bitbake u-boot-imxuboot のみ
をコンパイルするシステム全体をモード 1 でコンパイルするコマンドの場合、組み込み Linuxディストリビューションバージョンは一度に完了します U-Boot、Linux カーネル、デバイスツリーファイル、ルートファイルシステムのコンパイル、パッケージのインストールなどのプロセスは最終ターゲットファイルを直接生成します; 方法 2 を使用する場合、uboot のみが個別にコンパイルされます。コンパイル後、ロードフォース u-boot.bin ファイルの下に生成されますeamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/u-boot-imx/2022.04-r0/image/boot。

eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/u-boot-imx/2022.04-r0/image/boot$ ls
u-boot.bin  u-boot.bin-sd  u-boot-sd-2022.04-r0.bin  u-boot-spl.bin  u-boot-spl.bin-sd  u-boot-spl.bin-sd-2022.04-r0

6. 穀粒移植

6.1. Linux カーネルのソースコードの変更

Linux カーネルの移植プロセスでは、対応する Linux カーネルソースコードを変更する必要があります。同様に、Yocto で提供されるレシピを直接変更するのではなく、以前に作成したメタアドバンテックで新しいレシピを作成します。Linux カーネルのコンパイルを設定します。プロセス。Linux カーネルのプロバイダーは、次のようにPREFERRED_PROVIDER_virtual/kernel_imx
変数によって定義されます。

PREFERRED_PROVIDER_virtual/kernel_imx = "linux-imx"

imx8mm Linux カーネルのプロバイダーは linux-imx であることがわかります。実際、これは /sources/meta-imx/meta-bsp/recipes-kernel/linux にある linux-imx_5.15.bb ファイルに対応しています。 / 道。したがって、次のようなパスを作成しました: sources/meta-advantech/meta-adv-imx/recipes-kernel/linux/，并创建linux-imx_5.15.bbappendfile. ファイルの内容は次のとおりです。

sources/meta-advantech/meta-adv-imx/recipes-kernel/linux$ cat linux-imx_5.15.bbappend 
SRCBRANCH = "lf-5.15.y"
LOCALVERSION = "-lts-5.15.y"
KERNEL_SRC = "git://github.com/Advantech-IIoT/linux-imx.git;protocol=https;branch=${SRCBRANCH}"
SRC_URI = "${KERNEL_SRC}"
SRCREV = "065aa1f91e58e1108720dc701a074760be878962"

同様に、 SRC_URI変数とSRCREV変数を使用して、ビルドシステムに参加するカーネルソースコードの場所を指定します。

6.2 Linux カーネルデバイスツリーファイル

前に machine.conf ファイルを作成するときに、変数 KERNEL_DEVICETREE を設定する必要があると述べましたが、Linux カーネルのコンパイルプロセスで使用されるデバイスツリーファイルは、変数 KERNEL_DEVICETREE によって定義されます。

6.3. Linux カーネルの作成とパッチファイルの入手

Linux カーネルの移植プロセスでは、パッチファイルの取得または作成が必要になります。より簡単な方法は、git コマンドを使用して変更を送信し、パッチファイルを生成することです。

$ git add init/calibrate.c
$ git commit -m "calibrate.c - Added some printk statements"
$ git format-patch -1
0001-calibrate.c-Added-some-printk-statements.patch

生成されたパッチファイルを meta-mylayer/recipes-kernel/linux/linux-imx/ パスに配置し、.bbappend ファイルに追加します。

SRC_URI：append = " file://0001-calibrate.c-Added-some-printk-statements.patch"

次のコマンドを実行して、最初にカーネルコンパイルディレクトリをクリアしてから、パッチを再度適用します。

$ bitbake linux-imx -c clean
$ bitbake linux-imx -c patch

次に、パッチが適用されたソースコードをチェックし、パッチが有効になっていることを確認して、コンパイルします。

$ bitbake linux-imx

カーネル構成を変更する別の方法は、bitbake linux-imx -c menuconfig対話型インターフェースを開いてここで構成を変更することです: ここでの構成は、コンパイル・
ここに画像の説明を挿入
ディレクトリーの .config ファイルから取得されます。これが最初のコンパイルの場合、このファイルはカーネルのアーチ/アームですソースコード /conifg ディレクトリ内の defconfig ファイルのコピー。通常、レシピファイルの do_config タスクで指定されます。
menuconfig で変更した後、保存して終了します。更新された .config ファイルはコンパイルディレクトリ tmp/work/imx8mmeamb9918a1-poky-linux/linux-imx/5.15.32+gitAUTOINC+065aa1f91e-r0/build/ に生成され、元の .config の名前は .config に変更されます。。年。次に、 diffconfig オプションを呼び出して構成スニペットを生成します。

bitbake linux-imx -c diffconfig

この手順では、.config と .config.old の違いを比較し、変更内容を特定し、構成フラグメントと呼ばれるパッチファイルを生成します。生成されたファイルは、カーネルビルドディレクトリの flagment.cfg にあります。このファイルを meta-advantech/meta-adv-imx/recipes-kernel/linux/linux-imx/ ディレクトリにコピーし、linux-imx_5.10.72.bbappend ファイルに追加します。

SRC_URI += "file://fragment.cfg"

さまざまな種類の変更を追加するために複数の構成フラグメントが使用されることが多いため、fragment.cfg を意味のあるファイル名に変更することをお勧めします。コンパイル前に、kernel_configcheckカーネル構成が正しいかどうかをチェックするオプションを呼び出すことができます。

bitbake linux-imx -c kernel_configcheck

6.4. Linux カーネルのソースコードの構築

コマンドを使用して Yocto 作業環境をロードした後MACHINE=imx8mmeamb9918a1 DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b eamb9918a1、カーネルを次の 2 つの方法でコンパイルできます。
コマンドを実行:bitbake imx-image-fullシステム全体を
コンパイルするコマンドを実行: bitbake linux-imxLinux カーネルを個別に
コンパイルする方法 1 でシステム全体をコンパイルするコマンドの場合、組み込み Linux ディストリビューションバージョンは一度に完成します U-Boot、Linux カーネル、デバイスツリーファイル、ルートファイルシステムのコンパイル、パッケージのインストールなどのプロセスにより、最終的なターゲットファイルが直接生成されます。方法 2 を使用すると、Linux カーネルとデバイスのみが生成されます。コンパイル後、eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/linux-imx/5.15.32+gitAUTOINC+065aa1f91e-r0/build/arch/arm64/boot にイメージファイルが生成されます。、ファイルは道路dts強度に応じて生成されますdtb。

eamb9918a1/tmp/work/imx8mmeamb9918a1-poky-linux/linux-imx/5.15.32+gitAUTOINC+065aa1f91e-r0/build/arch/arm64/boot/dts/freescale$ ls
imx8mm-adv-eamb9918-a1.dtb  imx8mm-evk.dtb

上記の dtb ファイルは、Linux カーネルのコンパイルプロセス中に生成されるデバイスツリーファイルです。同様に、sources/meta-advantech/meta-adv-imx/conf/machine/imx8mmeamb9918a1.conf ファイルでは、定義された変数 KERNEL_DEVICETREE が、生成されたデバイスツリーファイルに対応します。
コンパイルされた Linux カーネルイメージを展開する必要がある場合は、次のコマンドを使用できます。

bitbake -c deploy -f linux-imx                    //部署内核镜像到deploy目录

このコマンドは、生成された Linux カーネルイメージファイルを /tmp/deploy/images パスにデプロイします。

7. ルートファイルシステムを構築する

組み込み Linux システムディストリビューションを構築する場合、完全な組み込み Linux システム全体が bitbake imx-image-multimedia コマンドを通じて構築されます。このうち、Freescale では対象となるイメージファイルをいくつか用意していますが、イメージファイルがサポートする機能が増えると、ルートファイルシステムが大きくなることに注意してください。ここでは imx-image-full を選択します
ここに画像の説明を挿入
。実際、bitbake imx-image-full コマンドを実行すると、bitbake は/sources/meta-imx/meta-sdk/dynamic-layers/qt6-layer/recipes-fsl/imagesパス内のファイルを検索しimx-image-full.bb、imx-image-full.bb ファイルの構成に従ってシステムを構築します。同時に、パスの下に、上の表で説明したミラーファイルに対応する他のファイルも/sources/meta-imx/meta-sdk/recipes-fsl/images表示されます。さらに、ファイルシステムを構築するときは、実際のプロジェクトのニーズに応じて、対応する bbppend ファイルを作成して、新しい機能ソフトウェアをインストールおよび構成する必要があります。最後に、 bitbake imx-image-fullコマンドを実行することで、bitbake ツールの使用を開始して組み込み Linux システムを構築できます。ファイルシステムが構築されると、 Yocto ファイルシステムに対応するパス配下にimx-image-full-xxx.xxxファイルが出力されます。同時に、このパスの下に、対応するファイルシステムにインストールされているソフトウェアパッケージを含むマニフェストファイルも出力されます。次のコマンドを実行してマニフェストファイルを表示し、構築されたルートファイルシステムにインストールされているソフトウェアパッケージに chromium ブラウザが含まれているかどうかを照会します。fsl-image-multimedia.bb
eamb9918a1/tmp/deploy/images/imx8mmeamb9918a1
ここに画像の説明を挿入

eamb9918a1/tmp/deploy/images/imx8mmeamb9918a1$ cat imx-image-full-imx8mmeamb9918a1.manifest | grep chromium
chromium-ozone-wayland armv8a-mx8mm 96.0.4664.110-r0

また、ルートファイルシステムを構築するときに、フェッチ/リクエストなどのエラーが発生することがよくありますが、一般に、これはネットワークの問題であり、対応する操作を再度実行できます。たとえば、フェッチ中にエラーが報告されたことを示すエラーメッセージが表示された場合は、do_fetch タスクを単独で実行できます。do_fetch タスクが成功した後、ファイルシステムの構築を再実行します。ルートファイルシステムの構築時に問題が繰り返し発生する場合は、ビルドフォルダーの内容を削除し、コマンドを実行してファイルシステムを再度構築してみてください。

要約する

たとえば、上記は今日お話しする内容ですが、この記事では、Yocto システムのシステム移植プロセスをすばやく簡単に理解できるように、Yocto システムの導入と使用方法について簡単に紹介します。

【Yocto移植】技術共有