IMXLXYOCTOUG
i.MX Yocto プロジェクト ユーザーガイド
Rev. LF6.6.3_1.0.0 — 29 年 2024 月 XNUMX 日
NXPセミコンダクターズ
ユーザーガイド
IMXLXYOCTOUG i.MX Yocto プロジェクト
文書情報
| 情報 | コンテンツ |
| キーワード | i.MX、Linux、LF6.6.3_1.0.0 |
| 抽象的な | このドキュメントでは、Yocto Project ビルド環境を使用して i.MX ボードのイメージをビルドする方法について説明します。 i.MX リリース層と i.MX 固有の使用法について説明します。 |
以上view
このドキュメントでは、Yocto Project ビルド環境を使用して i.MX ボードのイメージをビルドする方法について説明します。 i.MX リリース層と i.MX 固有の使用法について説明します。
Yocto プロジェクトは、組み込み Linux OS 開発に重点を置いたオープンソース コラボレーションです。Yocto プロジェクトの詳細については、Yocto プロジェクト ページを参照してください。 www.yoctoproject.org/Yocto Projectのホームページには、システムの使い方を詳しく説明したドキュメントがいくつかあります。i.MXリリースレイヤーなしで基本的なYocto Projectを使用するには、次の場所にあるYocto Projectクイックスタートの指示に従ってください。 https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html.
FSL YoctoプロジェクトコミュニティBSP（ FSL コミュニティ BSP (freescale.github.io)）は、NXP以外の開発コミュニティであり、Yocto Project環境でi.MXボードのサポートを提供しています。i.MXはYocto Projectコミュニティに参加し、Yocto Projectフレームワークに基づくリリースを提供しています。FSLコミュニティBSPの使用に関する特定の情報は、コミュニティで入手できます。 web ページ。このドキュメントは、コミュニティ BSP ドキュメントの拡張版です。
Fileイメージの構築に使用される はレイヤーに保存されます。レイヤーにはさまざまなタイプのカスタマイズが含まれており、さまざまなソースから取得されます。いくつかの fileレイヤー内の はレシピと呼ばれます。 Yocto Project のレシピには、ソース コードを取得し、コンポーネントをビルドしてパッケージ化するメカニズムが含まれています。次のリストは、このリリースで使用されるレイヤーを示しています。
i.MX リリース層
- メタimx
– meta-bsp: meta-freescale、poky、および meta-openembedded レイヤーの更新
– meta-sdk: meta-freescale-distros のアップデート
– meta-ml: 機械学習レシピ
– meta-v2x: i.MX 2DXL のみで使用される V8X レシピ
– meta-cockpit: i.MX 8QuadMax のコックピットレシピ
Yocto プロジェクトのコミュニティ レイヤー
- meta-freescale: ベースおよび i.MX Arm リファレンス ボードのサポートを提供します。
- meta-freescale-3rdparty: サードパーティおよびパートナーのボードのサポートを提供します。
- meta-freescale-distro: 開発とボード機能の練習に役立つ追加アイテム。
- fsl-community-bsp-base: 多くの場合、base に名前が変更されます。FSL コミュニティ BSP の基本構成を提供します。
- meta-openembedded: OEコアユニバースのレイヤーのコレクション。 レイヤー.openembedded.org/.
- poky: Poky の基本的な Yocto プロジェクト項目。詳細については、Poky README を参照してください。
- meta-browser: 複数のブラウザを提供します。
- meta-qt6: Qt 6 を提供します。
- meta-timesys: BSP の脆弱性 (CVE) を監視および通知するための Vigiles ツールを提供します。
このドキュメントでのコミュニティ レイヤーへの参照は、meta-imx を除く Yocto プロジェクトのすべてのレイヤーを対象としています。 i.MX ボードは、meta-imx 層と meta-freescale 層で構成されます。これには、U-Boot、Linux カーネル、リファレンス ボード固有の詳細が含まれます。
i.MX は、新しい i.MX リリースを FSL Yocto Project Community BSP と統合するための、i.MX BSP リリースと呼ばれる追加のレイヤー (meta-imx という名前) を提供します。meta-imx レイヤーは、Yocto Project の既存の meta-freescale および meta-freescale-distro レイヤーではまだ利用できない、新しいリリース用の更新された新しい Yocto Project レシピとマシン構成をリリースすることを目的としています。i.MX BSP の内容
リリース層はレシピとマシン構成です。多くのテストケースでは、他の層がレシピを実装したり、 files および i.MX リリース レイヤーは、現在のレシピに追加するか、コンポーネントを含めてパッチやソースの場所を更新することによって、レシピの更新を提供します。ほとんどの i.MX リリース レイヤー レシピは、コミュニティが提供したものを使用し、他のレイヤーでは利用できない新しいパッケージ バージョンごとに必要なものを更新するため、非常に小さいです。
i.MX BSP リリース レイヤーは、システム イメージの起動に必要なすべてのコンポーネントを含むイメージ レシピも提供するため、ユーザーにとっては簡単です。コンポーネントは個別にビルドすることも、イメージに必要なすべてのコンポーネントを 1 つのビルド プロセスに取り込むイメージ レシピを通じてビルドすることもできます。
i.MX カーネルおよび U-Boot リリースには、i.MX パブリック Git サーバーを通じてアクセスします。ただし、いくつかのコンポーネントは i.MX ミラー上のパッケージとしてリリースされます。パッケージベースのレシピプル fileGit の場所ではなく i.MX ミラーから取得し、必要なパッケージを生成します。
バイナリとしてリリースされるすべてのパッケージは、各マシン構成で定義された DEFAULTTUNE の指定に従ってハードウェア浮動小数点を有効にしてビルドされます。 file。ソフトウェア浮動小数点パッケージは、jethro リリース以降は提供されません。
Yocto Project 6.6.3 (Nanbield) 用にリリース LF1.0.0_4.3 がリリースされました。 Yocto Project 4.3 の同じレシピがアップストリームされ、Yocto Project リリースの次のリリースで利用できるようになります。 Yocto プロジェクトのリリース サイクルは約 XNUMX か月です。
meta-imx のレシピとパッチはコミュニティ層にアップストリームされます。特定のコンポーネントに対してそれが完了すると、 filemeta-imx の は必要なくなり、FSL Yocto プロジェクト コミュニティ BSP がサポートを提供します。コミュニティは、i.MX リファレンス ボード、コミュニティ ボード、およびサードパーティ ボードをサポートしています。
1.1 エンドユーザー使用許諾契約
NXP Yocto プロジェクト BSP のセットアップ環境プロセス中に、NXP エンド ユーザー ライセンス契約 (EULA) が表示されます。 i.MX プロプライエタリ ソフトウェアを引き続き使用するには、ユーザーはこのライセンスの条件に同意する必要があります。条件への同意により、Yocto プロジェクト ビルドが i.MX ミラーからパッケージを解凍できるようになります。
注記：
セットアップ プロセス中にこのライセンス契約を注意深くお読みください。一度同意すると、i.MX Yocto プロジェクト環境での以降のすべての作業は、この同意した契約に結び付けられます。
1.2 参考文献
i.MX にはソフトウェアでサポートされる複数のファミリーがあります。以下にリストされているファミリとファミリごとの SoC を示します。 i.MX Linux リリース ノートには、現在のリリースでサポートされている SoC が記載されています。以前にリリースされた一部の SoC は、現在のリリースでビルド可能であっても、以前の検証済みレベルにある場合は検証されない場合があります。
- i.MX 6 ファミリー: 6QuadPlus、6Quad、6DualLite、6SoloX、6SLL、6UltraLite、6ULL、6ULZ
- i.MX 7 ファミリー: 7Dual、7ULP
- i.MX 8 ファミリー: 8QuadMax、8QuadPlus、8ULP
- i.MX 8M ファミリー: 8M Plus、8M Quad、8M Mini、8M Nano
- i.MX 8X ファミリー: 8QuadXPlus、8DXL
- i.MX 9 ファミリー: i.MX 93、i.MX 95
このリリースには、次の参考資料と追加情報が含まれています。
- i.MX Linux リリース ノート (IMXLXRN) – リリース情報を提供します。
- i.MX Linux ユーザーズ ガイド (IMXLUG) – U-Boot と Linux OS のインストール、および i.MX 固有の機能の使用に関する情報を提供します。
- i.MX Yocto Project ユーザーズ ガイド (IMXLXYOCTOUG) – Yocto Project を使用してホストをセットアップし、ツール チェーンをインストールし、ソース コードをビルドしてイメージを作成する NXP 開発システムのボード サポート パッケージについて説明します。
- i.MX 機械学習ユーザーズ ガイド (IMXMLUG) – 機械学習に関する情報を提供します。
- i.MX Linux リファレンス マニュアル (IMXLXRM) – i.MX 用の Linux ドライバーに関する情報を提供します。
- i.MX グラフィックス ユーザーズ ガイド (IMXGRAPHICUG) – グラフィックス機能について説明します。
- i.MX 移植ガイド (IMXXBSPPG) – BSP を新しいボードに移植する手順を説明します。
- i.MX VPU アプリケーション プログラミング インターフェイス Linux リファレンス マニュアル (IMXVPUAPI) – i.MX 6 VPU 上の VPU API に関するリファレンス情報を提供します。
- Harpoon ユーザーズ ガイド (IMXHPUG) – i.MX 8M デバイス ファミリ向けの Harpoon リリースを紹介します。
- i.MX 8QuadMax 向け i.MX デジタル コックピット ハードウェア パーティショニング イネーブルメント (IMXDCHPE) – i.MX 8QuadMax 向けの i.MX デジタル コックピット ハードウェア ソリューションを提供します。
- i.MX DSP ユーザーズ ガイド (IMXDSPUG) – i.MX 8 の DSP に関する情報を提供します。
- i.MX 8M Plus カメラおよびディスプレイ ガイド (IMX8MPCDUG) – i.MX 8M Plus の ISP 独立センサー インターフェイス API に関する情報を提供します。
- EdgeLock Enclave ハードウェア セキュリティ モジュール API (RM00284) – このドキュメントは、EdgeLock Enclave (ELE) プラットフォーム用の i.MX 8ULP、i.MX 93、および i.MX 95 ハードウェア セキュリティ モジュール (HSM) ソリューションによって提供される API のソフトウェア リファレンス記述です。
クイック スタート ガイドには、ボードとそのセットアップに関する基本情報が含まれています。彼らはNXPにいます webサイト。
- SABRE プラットフォーム クイック スタート ガイド (IMX6QSDPQSG)
- i.MX 6UltraLite EVK クイック スタート ガイド (IMX6ULTRALITEQSG)
- i.MX 6ULL EVK クイック スタート ガイド (IMX6ULLQSG)
- i.MX 7Dual SABRE-SD クイック スタート ガイド (SABRESDBIMX7DUALQSG)
- i.MX 8M Quad 評価キット クイック スタート ガイド (IMX8MQUADEVKQSG)
- i.MX 8M Mini 評価キット クイック スタート ガイド (8MMINIEVKQSG)
- i.MX 8M Nano 評価キット クイック スタート ガイド (8MNANOEVKQSG)
- i.MX 8QuadXPlus マルチセンサー有効化キット クイック スタート ガイド (IMX8QUADXPLUSQSG)
- i.MX 8QuadMax マルチセンサー有効化キット クイック スタート ガイド (IMX8QUADMAXQSG)
- i.MX 8M Plus 評価キット クイック スタート ガイド (IMX8MPLUSQSG)
- i.MX 8ULP EVK クイック スタート ガイド (IMX8ULPQSG)
- i.MX 8ULP EVK9 クイック スタート ガイド (IMX8ULPEVK9QSG)
- i.MX 93 EVK クイック スタート ガイド (IMX93EVKQSG)
- i.MX 93 9×9 QSB クイック スタート ガイド (93QSBQSG)
ドキュメントはオンラインで入手できます。 nxp.com.
- i.MX 6の情報はこちら nxp.com/iMX6シリーズ.
- i.MX SABREの情報はこちら 詳しくはこちら.
- i.MX 6UltraLiteの情報はこちら 詳しくはこちら.
- i.MX 6ULLの情報はこちら 詳しくはこちら.
- i.MX 7Dualの情報はこちら 詳しくはこちら.
- i.MX 7ULPの情報はこちら 詳しくはこちら.
- i.MX 8の情報はこちら 詳しくはこちら.
- i.MX 6ULZの情報はこちら 詳しくはこちら.
- i.MX 93の情報はこちら 詳しくはこちら.
- i.MX 95の情報はこちら 詳しくはこちら.
特徴
i.MX Yocto プロジェクト リリース レイヤーには次の機能があります。
- Linuxカーネルレシピ
– カーネル レシピは recipes-kernel フォルダーにあり、i.MX Git サーバーからダウンロードしたソースから i.MX カーネルを統合します。これは、プロジェクト内のレシピによって自動的に実行されます。
– LF6.6.3_1.0.0 は、Yocto プロジェクト向けにリリースされた Linux カーネルです。 - U-Bootのレシピ
– U-Boot レシピは recipes-bsp フォルダーにあり、i.MX Git サーバーからダウンロードしたソースから i.MX uboot-imx.git を統合します。
– i.MX 6.6.3、i.MX 1.0.0、i.MX 6、i.MX 7、i.MX 8 デバイス用の i.MX リリース LF93_95 では、更新された v2023.04 i.MX U-Boot バージョンが使用されます。このバージョンは、すべての i.MX ハードウェアに対して更新されていません。
– i.MX Yocto プロジェクト コミュニティ BSP はメインラインの u-boot-fslc を使用しますが、これは U-Boot コミュニティでのみサポートされており、L6.6.3 カーネルではサポートされていません。
– i.MX Yocto プロジェクト コミュニティ BSP は U-Boot バージョンを頻繁に更新するため、新しい U-Boot バージョンがメタフリースケール レイヤーに統合され、i.MX uboot-imx リリースからの更新がメインラインに統合されると、上記の情報が変更される可能性があります。 - グラフィックレシピ
– グラフィック レシピは recipes-graphics フォルダーに保存されます。
– グラフィックス レシピは、i.MX グラフィックス パッケージ リリースを統合します。GPU を備えた i.MX ボードの場合、imx-gpu-viv レシピは、各 DISTRO のグラフィック コンポーネント (フレーム バッファー (FB)、XWayland、Wayland バックエンド、Weston コンポジター (Weston)) をパッケージ化します。フレーム バッファーをサポートするのは、i.MX 6 と i.MX 7 のみです。
– Xorg ドライバーは xserver-xorg を統合します。 - i.MX パッケージ レシピ、firmware-imx、imx-sc-fimrware、およびその他のパッケージは recipes-bsp に存在し、i.MX ミラーからプルされてビルドされ、イメージ レシピにパッケージ化されます。
- マルチメディアレシピ
– マルチメディア レシピは recipes-multimedia にあります。
– imx-codec や imx-parser などの独自パッケージには、i.MX ミラーから取得されたレシピがあり、それをビルドしてイメージ レシピにパッケージ化します。
– オープンソース パッケージには、GitHub のパブリック Git リポジトリから取得されるレシピが含まれています。
– 制限されているコーデック用のレシピがいくつか提供されています。これらのパッケージは i.MX ミラーにはありません。
これらのパッケージは個別に入手できます。入手するには、i.MX マーケティング担当者にお問い合わせください。 - コアレシピ
udev などの一部のルール レシピは、システムに展開される更新された i.MX ルールを提供します。これらのレシピは通常、ポリシーの更新であり、カスタマイズにのみ使用されます。リリースは、必要な場合にのみ更新を提供します。 - デモレシピ
デモ レシピは meta-sdk ディレクトリにあります。このレイヤーには、イメージ レシピ、タッチ キャリブレーションなどのカスタマイズ レシピ、デモ アプリケーション レシピが含まれています。 - 機械学習レシピ
機械学習レシピは meta-ml ディレクトリにあります。このレイヤーには、tensorflow-lite、onnx などのパッケージの機械学習レシピが含まれています。 - コックピットレシピ
コックピット レシピは meta-cockpit に存在し、imx-8qmcockpit-mek マシン構成を使用する i.MX 8QuadMax でサポートされます。
meta-nxp-demo-experience レイヤーには、さらに多くのデモンストレーションとツール レシピが含まれています。このレイヤーは、リリースされたすべてのフル イメージに含まれています。
ホストの設定
Linux ホスト マシンで Yocto プロジェクトの期待どおりの動作を実現するには、以下で説明するパッケージとユーティリティをインストールする必要があります。重要な考慮事項は、ホスト マシンに必要なハードディスク容量です。元の場合ampたとえば、Ubuntu を実行しているマシン上でビルドする場合、必要な最小ハード ディスク容量は約 50 GB です。すべてのバックエンドを一緒にコンパイルするには十分な、少なくとも 120 GB を用意することをお勧めします。機械学習コンポーネントを構築するには、少なくとも 250 GB が推奨されます。
推奨される最小の Ubuntu バージョンは 20.04 以降です。最新リリースは Chromium v91 をサポートしていますが、これには ulimit (オープン数) を増やす必要があります。 files) から 4098。
3.1 港湾労働者
i.MXは現在、dockerセットアップスクリプトをリリースしています。 GitHub – nxp-imx/imx-docker: i.MX Dockerdocker を使用してホスト ビルド マシンをセットアップするには、readme の指示に従ってください。
さらに、i.MX 8 のみにメタ仮想化レイヤーを含めることで、標準マニフェストで Docker on Board が有効になります。これにより、外部 Docker ハブから Docker コンテナをインストールするためのヘッドレス システムが作成されます。
3.2 ホストパッケージ
Yocto Projectビルドでは、Yocto Projectで文書化されているビルド用の特定のパッケージをインストールする必要があります。 Yocto プロジェクトのクイック スタート ビルド マシンにインストールする必要があるパッケージを確認します。
Yocto プロジェクトの必須ホスト パッケージは次のとおりです。
$ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential \chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils \iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \python3-subunit mesa-common-dev zstd liblz4-tool file ロケール -y
$ sudo ロケール生成 en_US.UTF-8
構成ツールは、ビルド マシン上にある grep のデフォルト バージョンを使用します。パスに異なるバージョンの grep があると、ビルドが失敗する可能性があります。回避策の 1 つは、特別バージョンの名前を「grep」を含まない名前に変更することです。
3.3 Repo ユーティリティのセットアップ
Repo は、Git 上に構築されたツールで、複数のリポジトリを含むプロジェクトの管理を容易にします。これらのリポジトリは同じサーバー上に存在する必要はありません。 Repo は、Yocto プロジェクトの階層化された性質を非常によく補完し、ユーザーが独自のレイヤーを BSP に簡単に追加できるようにします。
「repo」ユーティリティをインストールするには、次の手順を実行します。
- ホームディレクトリにbinフォルダを作成します。
$ mkdir ~/bin (binフォルダがすでに存在する場合、この手順は必要ない場合があります)
$curl https://storage.googleapis.com/git-repo-downloads/repo>~/bin/repo
$ chmod a + x〜/ bin / repo - .bashrcに次の行を追加します。 file ~/bin フォルダが PATH 変数に含まれていることを確認します。
エクスポート PATH=~/bin:$PATH
Yocto プロジェクトのセットアップ
まず、以下のコマンドを使用して、Git が正しく設定されていることを確認します。
$ git config –global user.name “あなたの名前”
$ git config –global user.email “あなたのメールアドレス”
$ git config –リスト
i.MX Yocto プロジェクト BSP リリース ディレクトリには、1 つ以上のビルド ディレクトリの構築に使用されるレシピと、環境のセットアップに使用されるスクリプトのセットが含まれるソース ディレクトリが含まれています。
プロジェクトの構築に使用されるレシピは、コミュニティと i.MX の両方から提供されます。 Yocto プロジェクトのレイヤーがソース ディレクトリにダウンロードされます。これにより、プロジェクトのビルドに使用されるレシピが設定されます。
次の例ampこのファイルは、i.MX Yocto プロジェクト コミュニティ BSP レシピ レイヤーをダウンロードする方法を示しています。この元彼にとってはampファイルを作成すると、プロジェクト用に imx-yocto-bsp というディレクトリが作成されます。これの代わりに任意の名前を使用できます。
$ mkdir imx-yocto-bsp
$ cd imx-yocto-bsp
$ リポジトリ初期化 -u https://github.com/nxp-imx/imx-manifest
-b imx-linux-nanbield -m imx-6.6.3-1.0.0.xml
$リポジトリ同期
注記：
https://github.com/nxp-imx/imx-manifest/tree/imx-linux-nanbield すべてのマニフェストのリストがあります fileこのリリースではサポートされています。
このプロセスが完了すると、ソース コードがディレクトリ imx-yocto-bsp/sources にチェックアウトされます。
repo sync コマンドを使用してリポジトリ同期を定期的に実行し、最新のコードに更新できます。
Repo の初期化中にエラーが発生した場合は、.repo ディレクトリを削除して、Repo 初期化コマンドを再度実行してみてください。
リポジトリの init は、ラインの最新のパッチ用に構成されています。インデックスの指示に従ってください。 imx-マニフェスト.git 元の GA を取得します。それ以外の場合は、GA とパッチがデフォルトで取得されます。zeus ベースから以前のリリースを取得するには、Repo 初期化行の最後に -m (リリース マニフェスト名) を追加すると、以前のリリースが取得されます。例:ampファイルは README に記載されています file 上記のリンクにあります。
イメージビルド
このセクションでは、イメージを構築するプロセスとともに詳細情報を提供します。
5.1 ビルド構成
i.MX は、i.MX マシンのセットアップを簡素化するスクリプト imx-setup-release.sh を提供します。このスクリプトを使用するには、ビルド対象の特定のマシンの名前と、必要なグラフィカル バックエンドを指定する必要があります。
スクリプトはディレクトリと設定を設定します file指定されたマシンとバックエンド用。
meta-imx レイヤーでは、i.MX は、metafreescale マシン構成をオーバーレイする新規または更新されたマシン構成を提供します。これら fileこれらは、imx-setup-release.sh スクリプトによって、meta-freescale/conf/machine ディレクトリにコピーされます。以下は i.MX マシンの構成です。 fileを選択できます。最新の追加情報については、リリース ノートまたはマシン ディレクトリを確認してください。
| i.MX6 | i.MX7 | i.MX8 | i.MX9 |
| • imx6qpsabresd • imx6ulevk • imx6ulz-14x14evk • imx6ull14x14evk • imx6ull9x9evk • imx6dlsabresd • imx6qsabresd • imx6solosabresd • imx6sxsabresd • imx6sllevk |
• imx7dsabresd • imx7ulpevk |
• imx8qmmek • imx8qxpc0mek • imx8mqevk • imx8mm-lpddr4-evk • imx8mm-ddr4-evk • imx8mn-lpddr4-evk • imx8mn-ddr4-evk • imx8mp-lpddr4-evk • imx8mp-ddr4-evk • imx8dxla1-lpddr4-evk • imx8dxlb0-lpddr4-evk • imx8dxlb0-ddr3l-evk • imx8mnddr3levk • imx8ulp-lpddr4-evk • imx8ulp-9×9-lpddr4evk |
• s93evk さん • imx93-11x11lpddr4x-evk • imx93-9×9-lpddr4qsb • imx93-14x14lpddr4x-evk |
各ビルド フォルダーは、1 つのディストリビューションのみを使用するように構成する必要があります。変数 DISTRO_FEATURES が変更されるたびに、クリーンなビルド フォルダーが必要になります。各グラフィカル バックエンド Frame Buffer、Wayland、および XWayland にはそれぞれディストリビューション構成があります。ディストリビューションがない場合 file を指定すると、XWayland ディストリビューションがデフォルトとして設定されます。ディストリビューション構成は local.conf に保存されます file DISTRO 設定で、bitbake の実行中に表示されます。過去のリリースでは、poky ディストリビューションを使用し、layer.conf でバージョンとプロバイダーをカスタマイズしていましたが、カスタム ディストリビューションの方が優れたソリューションです。デフォルトの poky ディストリビューションを使用すると、デフォルトのコミュニティ構成が使用されます。i.MX リリースとして、NXP がサポートし、テストしている構成セットを用意することを優先します。
DISTRO 構成のリストは次のとおりです。 fsl-imx-fb は i.MX 8 ではサポートされておらず、fsl-imxx11 はサポートされていないことに注意してください。
- fsl-imx-wayland: 純粋な Wayland グラフィックス。
- fsl-imx-xwayland: Wayland グラフィックスおよび X11。EGL を使用する X11 アプリケーションはサポートされていません。
- fsl-imx-fb: フレーム バッファー グラフィックス – X11 または Wayland なし。フレーム バッファーは i.MX 8 および i.MX 9 ではサポートされていません。
ユーザーは独自のディストリビューションを作成することを歓迎します file これらのいずれかに基づいて、local.conf を更新して優先バージョンとプロバイダーを設定することなく、環境をカスタマイズできます。
imx-setup-release.sh スクリプトの構文を以下に示します。
$ ディストリビューション =マシン=ソースimx-setup-release.sh -b
ディストリビューション=ビルド環境を構成するディストリビューションであり、meta-imx/meta-sdk/conf/distro に保存されます。
マシン=構成を指すマシン名です file meta-freescale および meta-imx の conf/machine 内。
-b imx-setup-release.sh スクリプトによって作成されるビルド ディレクトリの名前を指定します。
スクリプトを実行すると、ユーザーに EULA に同意するよう求められます。 EULA が承諾されると、承諾は各ビルド フォルダー内の local.conf に保存され、そのビルド フォルダーに対して EULA 承諾クエリは表示されなくなります。
スクリプトの実行後、作業ディレクトリは、スクリプトによって作成されたばかりのディレクトリであり、-b オプションで指定されます。 conf フォルダーが作成され、次の内容が含まれます。 file■ bblayers.conf および local.conf。
の/conf/bblayers.conf file i.MX Yocto プロジェクト リリースで使用されるすべてのメタレイヤーが含まれています。
local.conf file マシンとディストリビューションの仕様が含まれています。
マシン ??= 'imx7ulpevk'
ディストリビューション ?= 'fsl-imx-xwayland'
ACCEPT_FSL_EULA = “1”
これを編集することで MACHINE 設定を変更できます。 file必要に応じて。
local.conf の ACCEPT_FSL_EULA file EULA の条件に同意したことを示します。
meta-imx レイヤーでは、i.MX 6 および i.MX 6 マシン用に統合されたマシン構成 (imx7qpdlsolox.conf および imx6ul7d.conf) が提供されています。i.MX はこれらを使用して、テスト用に XNUMX つのイメージにすべてのデバイス ツリーを含む共通イメージを構築します。これらのマシンはテスト以外の目的で使用しないでください。
5.2 i.MX Yocto プロジェクト イメージの選択
Yocto プロジェクトは、さまざまなレイヤーで使用できるいくつかの画像を提供します。 Poky はいくつかのイメージを提供し、meta-freescale と meta-freescale-distro はその他のイメージを提供し、追加のイメージ レシピは meta-imx レイヤーで提供されます。次の表に、さまざまなキー イメージ、そのコンテンツ、およびイメージ レシピを提供するレイヤーを示します。
表1. i.MX Yocto プロジェクトイメージ
| 画像名 | ターゲット | レイヤーごとに提供 |
| コアイメージ最小限 | デバイスの起動のみを許可する小さなイメージ。 | ポケ |
| コアイメージベース | ターゲット デバイスのハードウェアを完全にサポートするコンソール専用のイメージ。 | ポケ |
| コアイメージ佐藤 | 佐藤のイメージ、モバイル環境とモバイルデバイスのビジュアルスタイル。このイメージはSatoテーマをサポートしており、Pimlicoアプリケーションを使用しています。これには、ターミナル、エディター、および file マネージャー。 | ポケ |
| imx-イメージコア | Wayland バックエンドに使用される i.MX テスト アプリケーションを含む i.MX イメージ。このイメージは、毎日のコア テストで使用されます。 | メタimx/メタSDK |
| fsl-イメージマシンテスト | コンソール環境を備えた FSL コミュニティ i.MX コア イメージ (GUI インターフェイスなし)。 | メタフリースケールディストリビューション |
| imx-イメージ-マルチメディア | Qt コンテンツなしで GUI 付きの i.MX イメージを構築します。 | メタimx/メタSDK |
| imx-イメージ-フル | 機械学習機能を備えたオープンソースの Qt 6 イメージを構築します。これらのイメージは、ハードウェア グラフィックスを備えた i.MX SoC でのみサポートされます。i.MX 6UltraLite、i.MX 6UltraLiteLite、i.MX 6SLL、[MX 7Dual、i.MX 8MNanoLite、または i.MX 8DXL ではサポートされません。 | メタimx/メタSDK |
5.3 イメージの構築
Yocto プロジェクトのビルドでは bitbake コマンドを使用します。元の場合ampル、ビットベイク指定されたコンポーネントを構築します。各コンポーネントのビルドには、フェッチ、構成、コンパイル、パッケージ化、ターゲット rootfs へのデプロイなどの複数のタスクがあります。 bitbake イメージ ビルドは、イメージに必要なすべてのコンポーネントを収集し、タスクごとの依存関係の順序でビルドします。最初のビルドは、コンポーネントのビルドに必要なツールを備えたツールチェーンです。
次のコマンドは元のコマンドですampイメージの構築方法については、次のファイルを参照してください。
$ bitbake imx-image-multimedia
5.4 ビットベイクのオプション
イメージを構築するために使用するbitbakeコマンドはbitbakeです. 以下に説明する特定のアクティビティには、追加のパラメータを使用できます。Bitbake は、単一のコンポーネントを開発するためのさまざまな便利なオプションを提供します。BitBake パラメータを使用して実行するには、コマンドは次のようになります: bitbake必要なビルド パッケージです。
次の表に、BitBake のオプションをいくつか示します。
表2. BitBakeオプション
| BitBakeパラメータ | 説明 |
| -c フェッチ | ダウンロード状態が完了としてマークされていない場合に取得します。 |
| -c クリーンオール | コンポーネントのビルド ディレクトリ全体をクリーンアップします。ビルド ディレクトリ内の変更はすべて失われます。 rootfs とコンポーネントの状態もクリアされます。コンポーネントはダウンロード ディレクトリからも削除されます。 |
| -c デプロイ | イメージまたはコンポーネントを rootfs にデプロイします。 |
| -k | ビルド中断が発生した場合でも、コンポーネントのビルドを続行します。 |
| -c コンパイル -f | 一時ディレクトリ下のソース コードを直接変更することはお勧めできませんが、変更した場合、このオプションを使用しない限り、Yocto プロジェクトがコードを再構築しない可能性があります。イメージの展開後に再コンパイルを強制するには、このオプションを使用します。 |
| -g | イメージまたはコンポーネントの依存関係ツリーをリストします。 |
| -DDD | 3 レベルの深さのデバッグをオンにします。 D ごとに、別のレベルのデバッグが追加されます。 |
| -s、--show-versions | すべてのレシピの現在のバージョンと優先バージョンを表示します。 |
5.5 U-Boot 構成
U-Boot 構成はメイン マシン構成で定義されます file。構成は、UBOOT_CONFIG 設定を使用して指定されます。これには、local.conf で UBOOT_CONFIG を設定する必要があります。それ以外の場合、U-Boot ビルドはデフォルトで SD ブートを使用します。
これらは、次のコマンドを使用して個別にビルドできます (MACHINE を正しいターゲットに変更します)。
U-Boot 構成の間にスペースを入れることで、1 つのコマンドで複数の U-Boot 構成を構築できます。
各ボードの U-Boot 構成は次のとおりです。 i.MX 6 および i.MX 7 ボードは、OPTEE なしおよび OP-TEE ありの SD をサポートします。
- uboot_config_imx93evk=”sd fspi”
- uboot_config_imx8mpevk=”SD FSPI ECC”
- uboot_config_imx8mnevk=”sd fspi”
- uboot_config_imx8mmevk=”sd fspi”
- uboot_config_imx8mqevk=”sd”
- uboot_config_imx8dxlevk=”sd fspi”
- uboot_conifg_imx8dxmek=”sd fspi”
- uboot_config_imx8qxpc0mek=”sd fspi”
- uboot_config_imx8qxpmek=”sd fspi”
- uboot_config_imx8qmmek=”sd fspi”
- uboot_config_imx8ulpevk=”sd fspi”
- uboot_config_imx8ulp-9×9-lpddr4-evk=”sd fspi”
- uboot_config_imx6qsabresd=”SD SATA SD-OPTEE”
- uboot_config_imx6qsabreauto=”SD SATA メモリ ドライブ スピンドル NAND SD-OPTEE”
- uboot_config_imx6dlsabresd=”sd epdc sd-optee”
- uboot_config_imx6dlsabreauto=”sd イメージ スピン nand sd-optee”
- uboot_config_imx6solosabresd=”sd sd-optee”
- uboot_config_imx6solosabreauto=”sd イメージ スピン nand sd-optee”
- uboot_config_imx6sxsabresd=”sd emmc qspi2 m4fastup sd-optee”
- uboot_config_imx6sxsabreauto=”sd qspi1 nand sd-optee”
- uboot_config_imx6qpsabreauto=”SD SATA メモリ ドライブ スピンドル NAND SD-OPTEE”
- uboot_config_imx6qpsabresd=”SD SATA SD-OPTEE”
- uboot_config_imx6sllevk=”sd epdc sd-optee”
- uboot_config_imx6ulevk=”SD emmc qspi1 sd-optee”
- uboot_config_imx6ul9x9evk=”sd qspi1 sd-optee”
- uboot_config_imx6ull14x14evk=”SD emmc qspi1 nand sd-optee”
- uboot_config_imx6ull9x9evk=”sd qspi1 sd-optee”
- uboot_config_imx6ulz14x14evk=”SD emmc qspi1 nand sd-optee”
- uboot_config_imx7dsabresd=”SD EPDC QSPI1 NAND SD-OPTEE”
- uboot_config_imx7ulpevk=”SD emmc sd-optee”
任意の U-Boot 構成でビルドするには、次の手順を実行します。
1 つの U-Boot 構成のみの場合:
$ echo “UBOOT_CONFIG = \”eimnor\”” >> conf/local.conf
複数の U-Boot 構成の場合:
$ echo “UBOOT_CONFIG = \”sd eimnor\”” >> conf/local.conf
$マシン= bitbake -c デプロイ u-boot-imx
注記： i.MX 8 は、U-Boot を導入する imx-boot を使用します。
5.6 シナリオの構築
以下は、さまざまな構成のビルド セットアップ シナリオです。
マニフェストを設定し、次のコマンドを使用して Yocto Project レイヤー ソースを設定します。
$ mkdir imx-yocto-bsp
$ cd imx-yocto-bsp
$ リポジトリ初期化 -u https://github.com/nxp-imx/imx-manifest
-b imx-linux-nanbield -m imx-6.6.3-1.0.0.xml
$リポジトリ同期
次のセクションでは、具体的な例をいくつか示します。ampレス。コマンドをカスタマイズするために指定されたマシン名とバックエンドを置き換えます。
5.6.1 i.MX 6QuadPlus SABRE-AI のフレーム バッファー イメージ
$ DISTRO=fsl-imx-fb マシン=imx6qpsabreauto ソース imx-setup-release.sh –b ビルド-fb
$ bitbake imx-image-multimedia
これにより、フレーム バッファー バックエンドを使用してマルチメディア イメージが構築されます。
5.6.2 i.MX 8QuadXPlus MEK 上の XWayland イメージ
$ DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek ソース imx-setup-release.sh -b build-xwayland
$ bitbake imx-image-full
これにより、Qt 6 と機械学習機能を備えた XWayland イメージが構築されます。 Qt 6 と機械学習を使用せずにビルドするには、代わりに imx-image-multimedia を使用してください。
5.6.3 i.MX 8M Quad EVK 上の Wayland イメージ
$ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk ソース imx-setup-release.sh -b buildwayland
$ bitbake imx-image-multimedia
これにより、Qt 6 を使用せずにマルチメディアを使用して Weston Wayland イメージが構築されます。
5.6.4 ビルド環境の再起動
ビルド ディレクトリの設定後に新しいターミナル ウィンドウを開いたり、マシンを再起動したりした場合は、セットアップ環境スクリプトを使用して環境変数を設定し、再度ビルドを実行する必要があります。完全な imxsetup-release.sh は必要ありません。
$ ソースのセットアップ環境
5.6.5 XWayland および Wayland の Chromium ブラウザ
Yocto Project コミュニティには、GPU ハードウェアを備えた i.MX SoC 用の Wayland バージョン Chromium Browser 用の Chromium レシピがあります。 NXP は、コミュニティからのパッチのサポートやテストを行っていません。このセクションでは、Chromium を rootfs に統合し、ハードウェア アクセラレーションによるレンダリングを有効にする方法について説明します。 WebGL. Chromium ブラウザには、imx-release-setup.sh スクリプトに自動的に追加されるメタブラウザなどの追加レイヤーが必要です。
XWayland または Wayland の local.conf で、イメージに Chromium を追加します。 X11はサポートされていません。
CORE_IMAGE_EXTRA_INSTALL += “クロム-オゾン-ウェイランド”
5.6.6 Qt 6 と QtWebエンジンブラウザ
Qt 6 には商用ライセンスとオープンソース ライセンスの両方があります。 Yocto Project でビルドする場合、オープンソース ライセンスがデフォルトになります。これらのライセンスの違いを理解して、適切に選択してください。オープンソース ライセンスでカスタム Qt 6 の開発が開始された後は、商用ライセンスでは使用できません。法定代理人と協力して、これらのライセンスの違いを理解してください。
注記：
Qtの構築Webエンジンは、リリースで使用されるメタクロム レイヤーと互換性がありません。
NXP ビルド セットアップを使用している場合は、bblayers.conf から meta-chromium を削除します。
# qtとの互換性がないためコメントアウトしましたwebエンジン
#BBLAYERS += “${BSPDIR}/sources/meta-browser/meta-chromium”
利用可能な Qt 6 ブラウザは XNUMX つあります。 QtWebエンジン ブラウザは次の場所にあります。
- /usr/share/qt6/examples /webエンジンウィジェット/スタイルシートブラウザ
- /usr/share/qt6/examples /webエンジンウィジェット/シンプルブラウザ
- /usr/share/qt6/examples /webエンジンウィジェット/Cookieブラウザ
- /usr/share/qt6/examples /webエンジン/クイックナノブラウザ
上記のディレクトリに移動し、そこにある実行可能ファイルを実行すると、3 つのブラウザすべてを実行できます。
実行ファイルにパラメータ -plugin evdevtouch:/dev/input/event0 を追加することで、タッチスクリーンを有効にすることができます。
./quicknanobrowser -plugin evdevtouch:/dev/input/event0
QtWebエンジンは、i.MX 6、i.MX 7、i.MX 8、i.MX 9 の GPU グラフィックス ハードウェアを搭載した SoC でのみ動作します。
Qtを含めるにはwebエンジンをイメージに追加するには、次の内容を local.conf またはイメージ レシピに記述します。
IMAGE_INSTALL:append = ” パッケージグループ-qt6-webエンジン"
5.6.7 NXP eIQ機械学習
meta-ml レイヤーは、以前は個別の meta-imx-machinelearning レイヤーとしてリリースされ、現在は標準の BSP イメージ (imx-image-full) に統合されている NXP eIQ 機械学習の統合です。
多くの機能には Qt 6 が必要です。imx-image-full 以外の構成を使用する場合は、local.conf に次の内容を入力します。
IMAGE_INSTALL:append = ” packagegroup-imx-ml”
NXP eIQ パッケージを SDK にインストールするには、local.conf に次の内容を記述します。
TOOLCHAIN_TARGET_TASK:append = ” tensorflow-lite-dev onnxruntime-dev”
注記：
TOOLCHAIN_TARGET_TASK_append 変数は、パッケージをイメージではなく SDK にのみインストールします。
OpenCV DNN デモのモデル構成と入力データを追加するには、local.conf に次の内容を追加します。
PACKAGECONFIG:append:pn-opencv_mx8 = ” テスト test-imx”
5.6.8 システム
Systemd はデフォルトの初期化マネージャーとして有効になっています。 systemd をデフォルトとして無効にするには、fsl-imxpreferred-env.inc に移動し、systemd セクションをコメントアウトします。
5.6.9 マルチライブラリの有効化
i.MX 8 では、multilib 構成を使用して 32 ビット OS 上での 64 ビット アプリケーションの構築をサポートできます。 Multilib は、さまざまなターゲット最適化またはアーキテクチャ形式でライブラリを構築し、これらを XNUMX つのシステム イメージに結合する機能を提供します。 Multilib は、MULTLIB、DEFAULTTUNE、IMAGE_INSTALL 宣言を local.conf に追加することで有効になります。 file。 Multilib は、debian パッケージ管理ではサポートされていません。 RPM システムが必要です。 local.conf 内の 2 つのパッケージ管理行をコメントアウトして、デフォルトの RPM に移動します。
MULTILIBS宣言は通常lib32またはlib64であり、
MULTILIB_GLOBAL_VARIANTS 変数は次のようになります。
MULTILIBS = “multilib:lib32”
DEFAULTTUNE は、次のように、この代替ライブラリ タイプの AVAILTUNES 値の 1 つである必要があります。
DEFAULTTUNE:virtclass-multilib-lib32 = “armv7athf-neon”
IMAGE_INSTALL は、次のように特定のアプリケーションに必要な 32 ビット ライブラリのイメージに追加されます。
IMAGE_INSTALL:append = ” lib32-bash”
i.MX 8 の場合、32 ビット アプリケーション サポートを構築するには、local.conf に次のステートメントが必要になります。この構成では、メイン マシン タイプとして 64 ビット マシンを指定し、multilib:lib32 を追加します。これらのライブラリは armv7athf-neon チューンでコンパイルされ、すべてのイメージに lib32 パッケージが含まれます。
マシン = imx8mqevk
# マルチライブラリターゲットを定義する
conf/multilib.conf が必要です
MULTILIBS = “multilib:lib32”
DEFAULTTUNE:virtclass-multilib-lib32 = “armv7athf-neon”
# イメージにマルチライブラリパッケージを追加する
IMAGE_INSTALL:append = ” lib32-glibc lib32-libgcc lib32-libstdc++”
処理エラーを避けるために、deb パッケージ化を無効にします。 local.conf を確認し、次のものがあればコメントします。
パッケージクラス = “package_deb”
EXTRA_IMAGE_FEATURES += “パッケージ管理”
5.6.10 OP-TEE の有効化
OP-TEE には、OP-TEE OS、OP-TEE クライアント、OP-TEE テストの 3 つのコンポーネントが必要です。さらに、カーネルと U-Boot には構成があります。 OP-TEE OS はブートローダーに常駐し、OP-TEE クライアントとテストは rootfs に常駐します。
このリリースでは、OP-TEEはデフォルトで有効になっています。OP-TEEを無効にするには、meta-imx/meta-bsp/conf/layer.confに移動します。 file OP-TEE の DISTRO_FEATURES_append をコメント アウトし、削除された行のコメントを解除します。
5.6.11 刑務所の建設
Jailhouse は、Linux OS をベースとした静的パーティショニング ハイパーバイザーです。これは、i.MX 8M Plus、i.MX 8M Nano、i.MX 8M Quad EVK、および i.MX 8M Mini EVK ボードでサポートされています。
Jailhouse ビルドを有効にするには、次の行を local.conf に追加します。
DISTRO_FEATURES:append = ”刑務所”
U-Boot で、run jh_netboot または jh_mmcboot を実行します。 Jailhouse 用に専用の DTB をロードします。 i.MX 8M Quadを元に戻すampLinux OS の起動後、ファイル:
#insmod jailhouse.ko
#./jailhouse imx8mq.cell を有効にする
i.MX 8 の Jailhouse の詳細については、i.MX Linux ユーザー ガイド (IMXLUG) を参照してください。
5.6.12 パッケージ管理
Yocto Project のデフォルトのパッケージ管理は rpm です。i.MX ディストリビューションでは、パッケージ管理として debian が有効になりました。local.conf で package_rpm に ACKAGE_CLASSES セットを追加するか、debian パッケージ フィード PACKAGE_CLASSES = “package_deb” なしでカスタム ディストリビューションを作成することで、これを簡単に無効にできます。
debian パッケージ フィードの追加により、debian のパッケージ フィードにリンクする /etc/apt に、sources.list を追加できるようになりました。これにより、ユーザーはイメージに提供されていないパッケージを Yocto イメージに追加することなくインストールできます。このパッケージ フィードは i.MX Yocto ビルド プロセスによって生成されるものではないため、各パッケージが適切な依存関係で動作するという保証はありませんが、よりシンプルなツールを提供できます。
複雑で特定のバージョンへの依存度が高いソフトウェアでは、外部パッケージ フィードに問題が発生する可能性があります。
イメージの展開
完了 fileシステムイメージが展開されるのは、 /tmp/デプロイ/イメージ。イメージの大部分は、環境設定で設定されたマシンに固有です。各イメージ ビルドでは、マシン構成で定義された IMAGE_FSTYPES に基づいて、U-Boot、カーネル、およびイメージ タイプを作成します。 file。ほとんどのマシン構成では、SD カード イメージ (.wic) と rootfs イメージ (.tar) が提供されます。 SD カード イメージには、対応するハードウェアの起動に適したパーティション化されたイメージ (U-Boot、カーネル、rootfs などを含む) が含まれています。
6.1 SDカードイメージのフラッシュ
SDカードイメージ file .wic には、対応するハードウェアの起動に適したパーティション化されたイメージ (U-Boot、カーネル、rootfs など) が含まれています。 SD カード イメージをフラッシュするには、次のコマンドを実行します。
zstdcat .wic.zst | sudo dd of=/dev/sd bs=1M 変換=fsync
フラッシュの詳細については、『i.MX Linux ユーザー ガイド (IMXLUG)』の「SD/MMC カードのブートの準備」セクションを参照してください。 NXP eIQ 機械学習アプリケーションの場合は、追加の空きディスク容量 (約 1 GB) が必要です。これは、IMAGE_ROOTFS_EXTRA_SPACE 変数を local.conf に追加することで定義されます。 file Yocto構築プロセスの前に。 Yocto Project メガマニュアル.
カスタマイズ
i.MX Linux OS 上で構築およびカスタマイズするシナリオは 3 つあります。
- i.MX Yocto Project BSP を構築し、i.MX リファレンス ボードで検証します。このドキュメントの手順では、この方法について詳細に説明します。
- カーネルをカスタマイズし、カーネルと U-Boot を使用してカスタム ボードとデバイス ツリーを作成します。SDK をビルドし、Yocto Project ビルド環境の外部でのみカーネルと U-Boot をビルドするためのホスト マシンを設定する方法の詳細については、i.MX ユーザー ガイド (IMXLUG) の「スタンドアロン環境で U-Boot とカーネルをビルドする方法」の章を参照してください。
- i.MX Linuxリリース用に提供されているBSPからパッケージを追加または削除して、ディストリビューションをカスタマイズします。カスタムYoctoプロジェクトレイヤーを作成します。i.MXは複数のデモ例を提供します。ampファイルを使用して、i.MX BSP リリースの上にカスタム レイヤーを表示します。このドキュメントの残りのセクションでは、カスタム DISTRO およびボード構成を作成する手順について説明します。
7.1 カスタムディストリビューションの作成
カスタム ディストリビューションはカスタム ビルド環境を構成できます。ディストリビューション fileリリースされたfsl-imx-wayland、fslimx-xwayland、fsl-imx-fbはすべて、特定のグラフィカルバックエンドの設定を示しています。ディストリビューションは、カーネル、U-Boot、GStreamerなどの他のパラメータを設定するためにも使用できます。i.MXディストリビューション fileは、i.MX Linux OS BSP リリースのテストに必要なカスタム ビルド環境を作成するように設定されています。
各顧客が独自のディストリビューションを作成することをお勧めします file そして、それをビルド環境のプロバイダー、バージョン、カスタム構成の設定に使用します。ディストリビューションは既存のディストリビューションをコピーして作成されます file、または poky.conf のようなものを含めて追加の変更を追加するか、i.MX ディストリビューションの 1 つを含めてそれを開始点として使用します。
7.2 カスタムボード構成の作成
リファレンス ボードを開発しているベンダーは、そのボードを FSL コミュニティ BSP に追加することが必要になる場合があります。
新しいマシンが FSL コミュニティ BSP でサポートされているため、ソース コードをコミュニティと共有しやすくなり、コミュニティからのフィードバックも得られます。
Yocto プロジェクトを使用すると、新しい i.MX ベースのボード用の BSP を簡単に作成して共有できます。アップストリーム プロセスは、Linux OS カーネルとブートローダーが動作し、そのマシンに対してテストされたときに開始する必要があります。安定した Linux カーネルとブートローダー (たとえば、ampファイル、U-Boot) をマシン構成でポイントする file、そのマシンで使用されるデフォルトのものになります。
もう 1 つの重要なステップは、新しいマシンの保守担当者を決定することです。メンテナは、そのボードで動作するメイン パッケージのセットを維持する責任を負います。マシンの保守者は、カーネルとブートローダーを常に最新の状態に保ち、ユーザー空間パッケージをそのマシン用にテストする必要があります。
必要な手順を以下に示します。
- カーネル構成をカスタマイズする file必要に応じて。カーネル構成 file arch/arm/configs 内の場所であり、ベンダー カーネル レシピはカーネル レシピを通じてロードされるバージョンをカスタマイズする必要があります。
- 必要に応じて U-Boot をカスタマイズします。詳細については、i.MX BSP 移植ガイド (IMXBSPPG) を参照してください。
- ボードのメンテナーを任命します。このメンテナーは、 fileは必要に応じて更新されるため、ビルドは常に機能します。
- 以下に示すように、Yocto Project コミュニティの手順に従って Yocto Project ビルドを設定します。
コミュニティ マスター ブランチを使用します。
a. ホストのLinux OSディストリビューションに応じて、必要なホストパッケージを以下からダウンロードします。 Yocto プロジェクトのクイック スタート.
b. 次のコマンドでリポジトリをダウンロードします。
$curl https://storage.googleapis.com/git-repo-downloads/repo>~/bin/repo
c.すべてを保存するディレクトリを作成します。任意のディレクトリ名を使用できます。このドキュメントでは imxcommunity-bsp を使用します。
$ mkdir imx-community-bsp
d. 次のコマンドを実行します。
$ cd imx-コミュニティ-bsp
e. リポジトリのマスター ブランチを使用してリポジトリを初期化します。
$ リポジトリ初期化 -u https://github.com/Freescale/fsl-community-bsp-platform -b マスター
f. 構築に使用するレシピを取得します。
$リポジトリ同期
g. 次のコマンドで環境を設定します。
$ ソース セットアップ環境ビルド - 類似のマシンを選択 file fsl-community-bsp/sources/meta-freescale-3rdparty/conf/machineで、ボードを示す名前を使用してコピーします。新しいボードを編集します。 file ボードに関する情報とともに。少なくとも名前と説明を変更してください。 MACHINE_FEATURE を追加します。
- 最新のコミュニティ マスター ブランチで変更をテストし、すべてが正常に動作することを確認します。少なくとも core-image-minimal を使用してください。
$ bitbake コアイメージ最小 - パッチを準備します。レシピ スタイル ガイドと、git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/ tree/README の「Contributing」セクションに従ってください。
- アップストリームはmeta-freescale-3rdpartyへ。アップストリームにはパッチを メタフリースケール.
7.3 BSP のセキュリティ脆弱性の監視
Common Vulnerability and Exposures (CVE) の監視は、Timesys の NXP 対応 Vigiles ツールで実行できます。Vigiles は、ターゲット イメージのビルド時の Yocto CVE 分析を提供する脆弱性監視および管理ツールです。これは、Yocto Project BSP で使用されるソフトウェアに関するメタデータを収集し、NIST、Ubuntu などさまざまなソースからの CVE 情報を統合する CVE データベースと比較することで行われます。
ハイレベルなオーバーview 検出された脆弱性が返され、影響する CVE、その重大度、利用可能な修正に関する情報を含む詳細な分析が可能になります。 viewオンラインで編集。
レポートをオンラインでアクセスするには、次のリンクから NXP Vigiles アカウントに登録してください。
https://www.timesys.com/register-nxp-vigiles/
Vigiles の設定と実行に関する追加情報は、こちらをご覧ください。
https://github.com/TimesysGit/meta-timesys
https://www.nxp.com/vigiles
7.3.1 構成
BSP ビルドの conf/bblayers.conf に meta-timesys を追加します。
の形式に従ってください file そして、meta-timesysを追加します。
BBLAYERS += “${BSPDIR}/sources/meta-timesys”
conf/local.conf の INHERIT 変数に vigiles を追加します。
INHERIT +=「警戒」
7.3.2 実行
meta-timesys がビルドに追加されると、Vigiles は Linux BSP が Yocto でビルドされるたびにセキュリティ脆弱性スキャンを実行します。追加のコマンドは必要ありません。ビルドが完了するたびに、脆弱性スキャン情報が imx-yocto-bsp/ ディレクトリに保存されます。 /警戒中。
あなたはできる view セキュリティスキャンの詳細:
- コマンドライン（概要）
- オンライン（詳細）
単に file 名前付き-report.txt、詳細なオンライン レポートへのリンクが含まれています。
よくある質問
8.1 クイックスタート
このセクションでは、Linux マシン上で Yocto プロジェクトをセットアップし、イメージを構築する方法についてまとめています。これが何を意味するかについては、上記のセクションで詳しく説明しています。
「repo」ユーティリティのインストール
BSP を取得するには、「repo」をインストールする必要があります。これは 1 回だけ実行する必要があります。
$: mkdir ~/bin
$: 円url https://storage.googleapis.com/git-repo-downloads/repo>~/bin/repo
$: chmod a+x ~/bin/repo
$: PATH=${PATH}:~/bin
BSP Yocto プロジェクト環境をダウンロードしています。
repo init の -b オプションで、希望するリリースの正しい名前を使用します。これはリリースごとに 1 回実行する必要があり、最初の手順で作成されたディレクトリのディストリビューションを設定します。repo sync を実行すると、ソースの下のレシピを最新のものに更新できます。
$: mkdir imx-yocto-bsp
$: cd imx-yocto-bsp
$: リポジトリ初期化 -u https://github.com/nxp-imx/imx-manifest -b imx-linux-nanbield m imx-6.6.3-1.0.0.xml
: リポジトリ同期
注記：
https://github.com/nxp-imx/imx-manifest/tree/imx-linux-nanbield すべてのマニフェストのリストがあります fileこのリリースではサポートされています。
特定のバックエンドの設定
i.MX 8 および i.MX 9 フレームバッファはサポートされていません。これらは i.MX 6 および i.MX 7 SoC でのみ使用してください。
フレームバッファのセットアップ:
$: DISTRO=fsl-imx-fb MACHINE=ソース imx-setup-release.sh -b build-fb
Wayland のセットアップ:
$: DISTRO=fsl-imx-wayland MACHINE=ソース imx-setup-release.sh -b build-wayland
XWayland のセットアップ:
$: DISTRO=fsl-imx-xwayland MACHINE=ソース imx-setup-release.sh -b build-xwayland
すべてのバックエンド向けに構築
Qtなしでビルドする
$: bitbake imx-image-multimedia
Qt 6 と機械学習機能を使用して構築する
$: bitbake imx-image-full
8.2 ローカル構成のチューニング
Yocto Project のビルドは、特に複数のビルド ディレクトリでビルドする場合、時間とディスク使用量の両方でかなりのビルド リソースを消費する可能性があります。これを最適化する方法があります。たとえば、ampファイルでは、共有 sstate キャッシュ (ビルドの状態をキャッシュ) とダウンロード ディレクトリ (ダウンロードされたパッケージを保持) を使用します。これらは、local.conf 内の任意の場所に設定できます。 file 次のようなステートメントを追加します。
DL_DIR=”/opt/imx/yocto/imx/download”
SSTATE_DIR=”/opt/imx/yocto/imx/sstate-cache”
ディレクトリはすでに存在しており、適切な権限を持っている必要があります。共有 sstate は、複数のビルド ディレクトリが設定されており、それぞれが共有キャッシュを使用してビルド時間を最小限に抑える場合に役立ちます。共有ダウンロード ディレクトリにより、取得時間が最小限に抑えられます。これらの設定がない場合、Yocto Project はデフォルトで sstate キャッシュとダウンロードのビルド ディレクトリを使用します。
DL_DIR ディレクトリにダウンロードされたすべてのパッケージには、 。終わり。ネットワークでパッケージの取得に問題が発生した場合は、パッケージのバックアップ バージョンを手動で DL_DIR ディレクトリにコピーし、 。終わり file touch コマンドを使用します。次に、bitbake コマンドを実行します。
ビットベイク。
詳細については、 Yocto Project リファレンス マニュアル — Yocto Project ® 5.0.1 ドキュメント.
8.3 レシピ
各コンポーネントはレシピを使用して構築されます。新しいコンポーネントの場合、ソース (SRC_URI) を指し、該当する場合はパッチを指定するレシピを作成する必要があります。 Yocto プロジェクト環境は make から構築されますfile レシピ内の SRC_URI で指定された場所にあります。ビルドが autotools から確立される場合、レシピは autotools と pkgconfig を継承する必要があります。作るfileYocto Project でビルドされたパッケージを取得するには、クロス コンパイル ツールによって CC をオーバーライドできるようにする必要があります。
一部のコンポーネントにはレシピがありますが、追加のパッチやアップデートが必要です。これは bbappend レシピを使用して実行できます。これは、更新されたソースに関する詳細を既存のレシピに追加します。元の場合ampファイル、新しいパッチを含める bbappend レシピには次の内容が含まれている必要があります。
FILESEXTRAPATHS:先頭に := “${THISDIR}/${PN}:”
SRC_URI += file:// 。パッチ
FILESEXTRAPATHS_prepend は、Yocto Project に、リストされているディレクトリを調べて、SRC_URI にリストされているパッチを見つけるように指示します。
注記：
bbappendレシピが取得されない場合、 view フェッチログ file 作業フォルダ配下の(log.do_fetch)を参照し、関連するパッチが含まれているか確認してください。 bbappend 内のバージョンの代わりに、Git バージョンのレシピが使用される場合があります。 files.
8.4 追加パッケージの選択方法
パッケージにレシピが提供されている場合は、画像にパッケージを追加できます。コミュニティが提供するレシピの検索可能なリストは、次の場所にあります。 レイヤー.openembedded.org/アプリケーションに既に Yocto Project レシピがあるかどうかを検索して、どこからダウンロードできるかを確認できます。
8.4.1 画像の更新
イメージは、パッケージと環境構成のセットです。
画像 file (imx-image-multimedia.bb など) 内に含まれるパッケージを定義します。 file システム。
根 file システム、カーネル、モジュール、U-Bootバイナリはbuild/tmp/deploy/images/で利用可能です。 。
注記：
パッケージをイメージに含めずにビルドすることはできますが、パッケージを rootfs に自動的にインストールしたい場合は、イメージを再構築する必要があります。
8.4.2 パッケージグループ
パッケージ グループは、任意のイメージに含めることができるパッケージのセットです。
パッケージグループにはパッケージのセットを含めることができます。例:ampたとえば、マルチメディア タスクは、マシンに応じて VPU パッケージがビルドされているかどうかを判断できるため、BSP でサポートされているすべてのボードに対してマルチメディア パッケージの選択を自動化でき、イメージにはマルチメディア パッケージのみが含まれます。
追加のパッケージは、次の行を追加することでインストールできます。 /local.conf を参照してください。
CORE_IMAGE_EXTRA_INSTALL:追加 = ” 」
多くのパッケージグループがあります。これらは、packagegroup または packagegroups という名前のサブディレクトリにあります。
8.4.3 推奨バージョン
優先バージョンは、特定のコンポーネントに使用するレシピの優先バージョンを指定するために使用されます。コンポーネントは異なるレイヤーに複数のレシピを持つことができ、優先バージョンは使用する特定のバージョンを指します。
meta-imx レイヤーのlayer.conf では、運用環境に静的システムを提供するために、すべてのレシピに対して優先バージョンが設定されています。これらの優先バージョン設定は、正式な i.MX リリースに使用されますが、将来の開発には必須ではありません。
優先バージョンは、以前のバージョンではどのレシピを使用すべきか混乱が生じる可能性がある場合にも役立ちます。
例えばampファイル、imx-test および imx-lib の以前のレシピでは年月バージョン管理が使用されていましたが、これは次のように変更されました。バージョン管理。優先バージョンがない場合、古いバージョンが選択される可能性があります。優先バージョンが設定されていない限り、_git バージョンを持つレシピは通常、他のレシピよりも優先して選択されます。優先バージョンを設定するには、local.conf に次の内容を記述します。
優先_バージョン_ : =「 」
優先バージョンの使用の詳細については、Yocto Project マニュアルを参照してください。
8.4.4 優先プロバイダー
優先プロバイダーは、特定のコンポーネントの優先プロバイダーを指定するために使用されます。コンポーネントには複数のプロバイダーを含めることができます。元の場合ampたとえば、Linux カーネルは i.MX または kernel.org によって提供でき、優先プロバイダーには使用するプロバイダーが示されます。
例えばampつまり、U-Boot は、denx.de と i.MX を通じてコミュニティの両方から提供されます。コミュニティ プロバイダーは u-boot-fslc によって指定されます。 i.MX プロバイダーは u-boot-imx によって指定されます。優先プロバイダーを指定するには、local.conf に次の内容を記述します。
推奨プロバイダ: = “ ”
PREFERRED_PROVIDER_u-boot_mx6 = “u-boot-imx”
8.4.5 SoC ファミリ
SoC ファミリは、特定のシステム チップのセットに適用される変更のクラスを文書化します。各マシン構成で file、マシンは特定の SoC ファミリとともにリストされます。元の場合ampファイルでは、i.MX 6DualLite Sabre-SD は、i.MX 6 および i.MX 6DualLite SoC ファミリにリストされています。 i.MX 6Solo Sabre-auto は、i.MX 6 および i.MX 6Solo SoC ファミリにリストされています。一部の変更は、local.conf 内の特定の SoC ファミリを対象にして、マシン構成の変更をオーバーライドできます。 file。以下は元ですampmx6dlsabresd カーネル設定の変更ファイル。
KERNEL_DEVICETREE:mx6dl = “imx6dl-sabresd.dts”
SoC ファミリは、ハードウェアのクラスにのみ固有の変更を加える場合に役立ちます。元の場合ampi.MX 28 EVK にはビデオ処理ユニット (VPU) がないため、VPU のすべての設定は、正しいクラスのチップに固有となるように i.MX 5 または i.MX 6 を使用する必要があります。
8.4.6 BitBake ログ
BitBakeはビルドとパッケージのプロセスをtmp/work/の一時ディレクトリに記録します。 / /一時。
コンポーネントがパッケージの取得に失敗した場合、エラーを示すログが file log.do_fetch。
コンポーネントがコンパイルに失敗した場合、エラーを示すログが次の場所に記録されます。 file log.do_compile。
コンポーネントが期待どおりにデプロイされない場合があります。ビルド コンポーネント ディレクトリ (tmp/work/) 下のディレクトリを確認します。 / ）。各レシピの package、packages-split、および sysroot* ディレクトリをチェックして、 fileはそこに配置されます（ある場所）tagデプロイ ディレクトリにコピーされる前に編集されます)。
8.4.7 CVE の監視と通知のメカニズムを追加する方法
CVE 追跡メカニズムは GitHub から取得できます。ディレクトリ imx-yocto-bsp/sources に移動します。
次のコマンドを実行します。
git クローン https://github.com/TimesysGit/meta-timesys.git -b カークストーン
このコマンドは、NXP および Timesys が提供する Vigiles 製品の一部として、セキュリティの監視と通知に使用されるイメージ マニフェスト生成用のスクリプトを提供する追加のメタレイヤーをダウンロードします。ソリューションの使用方法については、セクション 7.3 に従ってください。
完全な CVE レポートにアクセスするには、LinuxLink ライセンス キーが必要です。開発環境にキーがなければ、Vigiles はデモ モードで実行を続け、概要レポートのみを生成します。
LinuxLink で Vigiles アカウントにログインします (アカウントがない場合は作成します)。 https://www.timesys.com/registernxp-vigiles/)。設定にアクセスして新しい
キー。キーをダウンロード file 開発環境に。キーの場所を指定する file Yocto の conf/local.conf 内 file 次の声明文を添えて:
VIGILES_KEY_FILE = “/tools/timesys/linuxlink_key”
参考文献
- ブート スイッチの詳細については、i.MX Linux ユーザーズ ガイド (IMXLUG) の「i.MX ボードのブート方法」セクションを参照してください。
- U-Boot を使用してイメージをダウンロードする方法については、i.MX Linux ユーザーズ ガイド (IMXLUG) の「U-Boot を使用したイメージのダウンロード」セクションを参照してください。
- SD/MMC カードの設定方法については、i.MX Linux ユーザーズ ガイド (IMXLUG) の「SD/MMC カードの起動準備」セクションを参照してください。
ドキュメント内のソースコードに関する注意
Exampこのドキュメントに示されているファイル コードには、次の著作権と BSD-3 条項ライセンスがあります。
Copyright 2024 NXP 以下の条件が満たされる場合、修正の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用が許可されます。
- ソース コードを再配布する場合は、上記の著作権表示、この条件リスト、および以下の免責事項を保持する必要があります。
- バイナリ形式で再配布する場合は、上記の著作権表示、この条件リスト、および以下の免責事項を、配布時に提供されるドキュメントおよび/またはその他の資料に再現する必要があります。
- 著作権所有者の名前もその貢献者の名前も、書面による事前の特別な許可なしに、このソフトウェアから派生した製品を推奨または宣伝するために使用することはできません。
このソフトウェアは、著作権者および貢献者によって「現状のまま」提供され、商品性および特定目的への適合性に関する黙示の保証を含むがこれに限定されない、明示または黙示のいかなる保証も否認されます。いかなる場合においても、著作権者または貢献者は、契約、厳格責任、不法行為（過失またはその他を含む）を問わず、本ソフトウェアの使用によって生じたいかなる直接的、間接的、偶発的、特別、懲罰的、または結果的な損害（代替品またはサービスの調達、使用、データ、または利益の喪失、または事業の中断を含むがこれらに限定されない）についても、たとえそのような損害の可能性について知らされていたとしても、一切の責任を負わないものとします。
改訂履歴
この表は改訂履歴を示しています。
改訂履歴
| 文書ID | 日付 | 実質的な変更 |
| IMXLXYOCTOUG v.LF6.6.3_1.0.0 | 29年2024月XNUMX日 | カーネルを 6.6.3 にアップグレードし、i.MX 91P を削除し、i.MX 95 をアルファ品質として追加しました。 |
| IMXLXYOCTOUG v.LF6.1.55_2.2.0 | 12/2023 | 6.1.55 カーネルにアップグレードされました。 |
| IMXLXYOCTOUG v.LF6.1.36_2.1.0 | 09/2023 | カーネルを 6.1.36 にアップグレードし、I.MX 91P を追加しました。 |
| IMXLXYOCTOUG v.LF6.1.22_2.0.0 | 06/2023 | 6.1.22 カーネルにアップグレードされました。 |
| IMXLXYOCTOUG v.LF6.1.1_1.0.0 | 04/2023 | セクション 3.2 のコマンドラインの誤りを修正。 |
| IMXLXYOCTOUG v.LF6.1.1_1.0.0 | 03/2023 | 6.1.1 カーネルにアップグレードされました。 |
| IMXLXYOCTOUG v.LF5.15.71_2.2.0 | 12/2022 | 5.15.71 カーネルにアップグレードされました。 |
| IMXLXYOCTOUG v.LF5.15.52_2.1.0 | 09/2022 | カーネル 5.15.52 にアップグレードされ、i.MX 93 が追加されました。 |
| IMXLXVOCTOUG v.LF5.15.32_2.0.0 | 06/2022 | 5.15.32 カーネル、U-Boot 2022.04、および Kirkstone Yocto にアップグレードされました。 |
| IMXLXYOCTOUG v.LF5.15.5_1.0.0 | 03/2022 | 5.15.5 カーネル、Honister Yocto、および Qt6 にアップグレードされました。 |
| IMXLXYOCTOUG v.LF5.10.72_2.2.0 | 12/2021 | カーネルを 5.10.72 にアップグレードし、BSP を更新しました。 |
| IMXLXYOCTOUG v.LF5.10.52_2.1.0 | 09/2021 | i.MX GULP Alpha 用に更新され、カーネルが 5.10.52 にアップグレードされました。 |
| IMXLXYOCTOUG v.LF5.10.35_2.0.0 | 06/2021 | 5.10.35 カーネルにアップグレードされました。 |
| IMXLXYOCTOUG v.LF5.10.9_1.0.0 | 04/2021 | セクション 3.1「ホスト パッケージ」のコマンド ラインのタイプミスを修正しました。 |
| IMXLXYOCTOUG v.LF5.10.9_1.0.0 | 03/2021 | 5.10.9 カーネルにアップグレードされました。 |
| IMXLXYOCTOUG v.L5.4.70_2.3.0 | 01/2021 | 「Arm Cortex-M4 イメージの実行」セクションのコマンド ラインを更新しました。 |
| IMXLXYOCTOUG v.L5.4.70_2.3.0 | 12/2020 | i.MX 5.4 リリース i.MX ボードの統合 GA (i.MX 8 を含む) MX 8M プラスと i.MX XNUMXDXL。 |
| IMXLXYOCTOUG v.L5.4.47_2.2.0 | 09/2020 | i.MX 5.4M Plus 用の I.MX 2 Beta8 リリース、8DXL 用の Beta、およびリリースされた I.MX ボードの統合 GA。 |
| IMXLXYOCTOUG v.L5.4.24_2.1.0 | 06/2020 | i.MX 5.4M Plus 用の i.MX 8 ベータ リリース、2DXL 用の Aipha8、およびリリースされた i.MX ボードの統合 GA。 |
| IMXLXYOCTOUG v.L5.4.3_2.0.0 | 04/2020 | i.MX 5.4M Plus および 8DXL EVK ボード用の i.MX 8 アルファ リリース。 |
| IMXLXYOCTOUG v.LF5A.3_1.0.0 | 03/2020 | I.MX 5.4 カーネルと Yocto プロジェクトのアップグレード。 |
| IMXLXYOCTOUG v.L4.19.35_1.1.0 | 10/2019 | I.MX 4.19 カーネルと Yocto プロジェクトのアップグレード。 |
| IMXLXYOCTOUG v.L4.19.35_1.0.0 | 07/2019 | I.MX 4.19 ベータ カーネルと Yocto プロジェクトのアップグレード。 |
| IMXLXYOCTOUG v.L4.14.98_2.0.0_ga | 04/2019 | i.MX 4.14 カーネルのアップグレードとボードのアップデート。 |
| IMXLXYOCTOUG v.L4.14.78_1.0.0_ga | 01/2019 | I.MX 6、i.MX 7、i.MX 8 ファミリーの GA リリース。 |
| IMXLXYOCTOUG v14.14.62_1.0.0_ベータ | 11/2018 | i.MX 4.14 カーネル アップグレード、Yocto Project Sumo アップグレード。 |
| IMXLXYOCTOUG v14.9.123_2.3.0_ 8mm | 09/2018 | i.MX 8M Mini GA リリース。 |
| IMXLXYOCTOUG v14.9.88_2.2.0_ 8qxp-beta2 | 07/2018 | i.MX 8QuadXPlus Beta2 リリース。 |
| IMXLXYOCTOUG v14.9.88_2.1.0_ 8mmアルファ | 06/2018 | i.MX 8M Mini Alpha リリース。 |
| IMXLXYOCTOUG v14.9.88_2.0.0-ga | 05/2018 | i.MX 7ULP および i.MX 8M Quad GA リリース。 |
| IMXLXYOCTOUG v14.9.51_imx8mq- ga | 03/2018 | i.MX 8M Quad GAを追加しました。 |
| IMXLXYOCTOUG v14.9.51_8qm- beta2/8qxp-beta | 02/2018 | i.MX 8QuadMax Beta2 および i.MX 8QuadXPlus Beta を追加しました。 |
| IMXLXYOCTOUG v.L4.9.51_imx8mq- ベータ | 12/2017 | i.MX 8M Quadを追加しました。 |
| IMXLXYOCTOUG v14.9.51_imx8qm- ベータ 1 | 12/2017 | i.MX 8QuadMaxを追加しました。 |
| IMXLXYOCTOUG v14.9.51_imx8qxp-アルファ | 11/2017 | 初回リリース。 |
法的情報
定義
下書き — ドキュメントの下書きステータスは、コンテンツがまだ内部検討中であることを示します。view 正式な承認が必要であり、変更や追加が行われる可能性があります。NXP Semiconductors は、文書のドラフト版に含まれる情報の正確性または完全性についていかなる表明または保証も行わず、そのような情報の使用の結果について一切の責任を負いません。
免責事項
限定保証および責任 — このドキュメントの情報は、正確で信頼できるものであると信じられています。 ただし、NXP セミコンダクターズは、そのような情報の正確性または完全性に関して、明示または黙示を問わず、いかなる表明または保証も行わず、そのような情報の使用の結果について責任を負わないものとします。 NXP セミコンダクターズ以外の情報源から提供された場合、NXP セミコンダクターズは本書の内容について一切の責任を負いません。
NXP セミコンダクターズは、間接的、偶発的、懲罰的、特別または必然的な損害 (利益の損失、節約の損失、事業の中断、製品の撤去または交換に関連する費用、または手直し費用を含むがこれらに限定されない) について、いかなる場合にも責任を負わないものとします。そのような損害は、不法行為 (過失を含む)、保証、契約違反、またはその他の法的理論に基づくものではありません。
いかなる理由であっても、お客様が被る可能性のある損害にかかわらず、本書に記載されている製品に関してお客様に対して NXP Semiconductors が負う総計および累積的な責任は、NXP Semiconductors の商用販売の条件に従って制限されるものとします。変更する権利 - NXP Semiconductors は、仕様や製品の説明など、本書で公開されている情報をいつでも予告なしに変更する権利を留保します。本書は、本書の公開前に提供されたすべての情報に優先し、それらを置き換えます。
使用適合性 — NXP セミコンダクターズ製品は、生命維持、生命にかかわるまたは安全上重要なシステムまたは機器、または NXP セミコンダクターズ製品の故障または誤動作が合理的に予想されるアプリケーションでの使用に適しているように設計、承認、または保証されていません。人身傷害、死亡または重大な物的損害または環境損害。 NXP セミコンダクターズおよびそのサプライヤーは、NXP セミコンダクターズ製品をそのような機器またはアプリケーションに含めたり使用したりすることについて一切の責任を負いません。
アプリケーション — これらの製品のいずれかについてここに記載されているアプリケーションは、説明のみを目的としています。 NXP セミコンダクターズは、そのようなアプリケーションがさらなるテストや変更なしに指定された用途に適していることを表明または保証しません。
お客様は、NXPセミコンダクターズ製品を使用したアプリケーションおよび製品の設計と運用に責任を負い、NXPセミコンダクターズは、アプリケーションまたはお客様の製品設計に関するいかなる支援についても責任を負いません。 NXPセミコンダクターズの製品が、お客様のアプリケーションと計画された製品、および計画されたアプリケーションとお客様のサードパーティのお客様の使用に適しているかどうかを判断するのは、お客様の単独の責任です。 お客様は、アプリケーションと製品に関連するリスクを最小限に抑えるために、適切な設計と運用のセーフガードを提供する必要があります。
NXPセミコンダクターズは、お客様のアプリケーションまたは製品、あるいはお客様のサードパーティのお客様によるアプリケーションまたは使用の弱点またはデフォルトに基づくデフォルト、損傷、コスト、または問題に関連する責任を負いません。 お客様は、NXPセミコンダクターズ製品を使用して、お客様のアプリケーションおよび製品に必要なすべてのテストを行い、アプリケーションおよび製品、またはお客様のサードパーティのお客様によるアプリケーションまたは使用のデフォルトを回避する責任があります。 NXPはこの点に関して一切の責任を負いません。
商用販売の条件 — NXP セミコンダクターズの製品は、次の Web サイトで公開されている商用販売の一般条件に従って販売されます。 https://www.nxp.com/profile/terms、有効な書面による個別契約で別段の合意がない限り。 個別の契約が締結された場合、それぞれの契約の条件のみが適用されるものとします。 NXPセミコンダクターズは、お客様によるNXPセミコンダクターズ製品の購入に関するお客様の一般条件の適用に明示的に反対します。
輸出管理 — この文書およびここに記載されている項目は、輸出管理規制の対象となる場合があります。 輸出には、所轄官庁からの事前承認が必要になる場合があります。
非自動車認定製品での使用への適合性 — この文書に、この特定の NXP Semiconductors 製品が自動車に適合していると明示的に記載されていない限り、この製品は自動車での使用には適していません。この製品は、自動車のテストまたはアプリケーションの要件に従って適合もテストもされていません。NXP Semiconductors は、自動車の機器またはアプリケーションに非自動車適合製品を組み込んだり使用したりすることに関して一切の責任を負いません。
お客様が自動車の仕様および規格に対する自動車用途でのデザインインおよび使用のために製品を使用する場合、お客様は (a) そのような自動車用途、用途および仕様に対する製品の NXP セミコンダクターズの保証なしで製品を使用するものとし、および ( b) お客様が NXP Semiconductors の仕様を超えて自動車用途に製品を使用する場合は、そのような使用はお客様自身の責任のみで行うものとし、(c) お客様は、お客様の設計および使用に起因する責任、損害、または製品の故障に関する請求について、NXP Semiconductors を完全に補償するものとします。 NXP セミコンダクターズの標準保証および NXP セミコンダクターズの製品仕様を超える車載アプリケーション向けの製品。
翻訳 — ドキュメントの法的情報を含む、英語以外の (翻訳された) バージョンのドキュメントは、参照のみを目的としています。 翻訳版と英語版の間に相違がある場合は、英語版が優先されるものとします。
安全 — お客様は、すべての NXP 製品が未確認の脆弱性にさらされている可能性があること、または確立されたセキュリティ基準または既知の制限付きの仕様をサポートしている可能性があることを理解しています。 お客様は、お客様のアプリケーションおよび製品に対するこれらの脆弱性の影響を軽減するために、アプリケーションおよび製品のライフサイクル全体の設計と運用に責任を負います。 お客様の責任は、NXP 製品がお客様のアプリケーションで使用するためにサポートするその他のオープンおよび/または独自技術にも及びます。 NXP は、いかなる脆弱性についても責任を負いません。 お客様は、NXP からのセキュリティ アップデートを定期的に確認し、適切にフォローアップする必要があります。
お客様は、目的のアプリケーションの規則、規制、および標準に最も適合するセキュリティ機能を備えた製品を選択し、その製品に関する最終的な設計上の決定を行うものとし、製品に関するすべての法律、規制、およびセキュリティ関連の要件を遵守する責任を単独で負うものとします。 NXP が提供する可能性のある情報またはサポートについて。
NXP には製品セキュリティ インシデント対応チーム (PSIRT) があります ( PSIRT@nxp.com) は、NXP 製品のセキュリティ脆弱性に関する調査、報告、およびソリューションのリリースを管理する組織です。
NXP BV — NXP BV は事業会社ではなく、製品の流通や販売は行いません。
商標
注意: 参照されているすべてのブランド、製品名、サービス名、および商標は、それぞれの所有者の財産です。
NXP — ワードマークとロゴはNXP BVの商標です
AMBA、Arm、Arm7、Arm7TDMI、Arm9、Arm11、Artisan、big.LITTLE、Cordio、CoreLink、CoreSight、Cortex、DesignStart、DynamIQ、Jazelle、Keil、Mali、Mbed、Mbed Enabled、NEON、POP、RealView、SecurCore、Socrates、Thumb、TrustZone、ULINK、ULINK2、ULINK-ME、ULINKPLUS、ULINKpro、μVision、Versatile — は、米国および/またはその他の国における Arm Limited (またはその子会社または関連会社) の商標および/または登録商標です。 関連技術は、特許、著作権、意匠、企業秘密の一部またはすべてによって保護されている場合があります。 全著作権所有。
エッジロック — NXP BV の商標です。
電子知能指数 — NXP BV の商標です。
MX の — NXP BV の商標です。
IMXLXYOCTOUG
All information providこの文書に記載されている内容は、法的な免責事項の対象となります。
© 2024 NXP BV 無断複写・転載を禁じます。
Rev. LF6.6.3_1.0.0 — 29 年 2024 月 XNUMX 日
ドキュメント / リソース
 |
NXP IMXLXYOCTOUG i.MX Yocto プロジェクト [pdf] ユーザーガイド IMXLXYOCTOUG i.MX Yocto プロジェクト、i.MX Yocto プロジェクト、Yocto プロジェクト、プロジェクト |
