Linuxは、Linus Torvaldsが寮の部屋で作業していたときに予想していたよりも、はるかに幅広いデバイスに展開されています。サポートされているチップアーキテクチャの多様性は驚くべきものであり、大小さまざまなデバイスでLinuxを生み出しています。巨大なIBMメインフレームから、接続ポートとその間のすべてのものよりも大きくない小さなデバイスまで。大企業のデータセンター、インターネットインフラストラクチャデバイス、および個人開発システムで使用されます。また、家電製品、携帯電話、および多くのモノのインターネットデバイスにも電力を供給します。
デスクトップおよびエンタープライズクラスのデバイス用のLinuxソフトウェアを構築する場合、開発者は通常、ビルドマシンでUbuntuなどのデスクトップディストリビューションを使用して、ソフトウェアが展開される環境にできるだけ近い環境を構築します。 VirtualBoxやDockerなどのツールを使用すると、開発、テスト、本番環境をさらに適切に調整できます。
組み込みシステムとは何ですか？
ウィキペディアでは、組み込みシステムを次のように定義しています。「より大規模な機械的または電気的システム内に専用の機能を備えたコンピューターシステムで、多くの場合、リアルタイムのコンピューティングの制約があります。」
組み込みシステムは、ほとんどの人がコンピューターとは考えていないコンピューターだと言っても過言ではありません。その主な役割は、ある種のアプライアンスとして機能することであり、汎用コンピューティングプラットフォームとは見なされません。
その他のLinuxリソース
- Linuxコマンドのチートシート
- 高度なLinuxコマンドのチートシート
- 無料のオンラインコース：RHELの技術概要
- Linuxネットワーキングのチートシート
- SELinuxチートシート
- Linuxの一般的なコマンドのチートシート
- Linuxコンテナとは何ですか？
- 最新のLinux記事
組み込みシステムプログラミングの開発環境は、通常、テスト環境や本番環境とは大きく異なります。さまざまなチップアーキテクチャ、ソフトウェアスタック、さらにはオペレーティングシステムを使用する場合もあります。開発ワークフローは、組み込み開発者とデスクトップおよびWeb開発者では大きく異なります。通常、ビルド出力は、カーネル、デバイスドライバー、ライブラリ、アプリケーションソフトウェア（場合によってはブートローダー）を含む、ターゲットデバイスのソフトウェアイメージ全体で構成されます。
この記事では、組み込みLinuxシステムを構築するために一般的に利用可能な4つのオプションの調査を紹介します。それぞれを操作するのがどのようなものかを説明し、読者がデザインに使用するツールを決定するのに役立つ十分な情報を提供します。それらの使い方は教えません。選択肢を絞り込んだら、詳細なオンライン学習リソースがたくさんあります。すべてのユースケースに適したオプションはありません。決定を下すのに十分な詳細を提示したいと思います。
Yoctoプロジェクトは、「ハードウェアアーキテクチャに関係なく、組み込み製品用のカスタムLinuxベースのシステムを作成するのに役立つテンプレート、ツール、およびメソッドを提供するオープンソースコラボレーションプロジェクト」として定義されています。これは、特定のニーズに合わせたカスタムLinuxランタイムイメージを作成するために使用されるレシピ、構成値、および依存関係のコレクションです。
完全な開示：組み込みLinuxでの私の仕事のほとんどは、Yoctoプロジェクトに焦点を当てており、このシステムに対する私の知識と偏見はおそらく明らかです。
YoctoはビルドシステムとしてOpenembeddedを使用しています。技術的には、この2つは別々のプロジェクトです。ただし、実際には、ユーザーはその違いを理解する必要はなく、プロジェクト名は頻繁に同じ意味で使用されます。
Yoctoプロジェクトビルドの出力は、大きく3つのコンポーネントで構成されています。
- ターゲットランタイムバイナリ： これらには、ブートローダー、カーネル、カーネルモジュール、ルートファイルシステムイメージが含まれます。 Linuxをターゲットプラットフォームにデプロイするために必要なその他の補助ファイル。
- パッケージフィード： これは、ターゲットにインストールできるソフトウェアパッケージのコレクションです。必要に応じて、パッケージ形式（deb、rpm、ipkなど）を選択できます。それらの一部はターゲットランタイムバイナリにプレインストールされている場合がありますが、デプロイされたシステムにインストールするためのパッケージをビルドすることは可能です。
- ターゲットSDK： これらは、ターゲットにインストールされているソフトウェアを表すライブラリとヘッダーファイルのコレクションです。これらは、アプリケーション開発者がコードを構築するときに使用され、適切なライブラリにリンクされていることを確認します
Yoctoプロジェクトは業界で広く使用されており、多くの影響力のある企業からの支援を受けています。さらに、大規模で活気のある開発者コミュニティとエコシステムが貢献しています。オープンソース愛好家と企業スポンサーの組み合わせは、Yoctoプロジェクトの推進に役立ちます。
Yoctoでサポートを受けるための多くのオプションがあります。自分でやりたい場合は、本やその他のトレーニング資料があります。専門知識を採用したい場合は、Yoctoの経験を持つ多くのエンジニアが利用できます。また、多くの営利団体は、ターンキーのYoctoベースの製品またはサービスベースの実装とカスタマイズを設計に提供しています。
Yoctoプロジェクトは、レイヤーを介して簡単に拡張できます。レイヤーは、独立して公開して機能を追加したり、プロジェクトリリースで使用できないターゲットプラットフォームに追加したり、システムに固有のカスタマイズを保存したりできます。レイヤーを構成に追加して、ストックリリースに特に含まれていない独自の機能を追加できます。たとえば、「メタブラウザ」レイヤーには、システム用に簡単に構築できるWebブラウザのレシピが含まれています。それらは独立して維持されるため、レイヤーは標準のYoctoリリースとは異なるリリーススケジュール（レイヤーの開発速度に合わせて調整）にすることができます。
Yoctoは、間違いなく、この記事で説明したオプションの中で最も幅広いデバイスをサポートしています。多くの半導体およびボードメーカーからのサポートにより、Yoctoは選択した任意のターゲットプラットフォームをサポートする可能性があります。 Yoctoの直接リリースでは、（適切なテストとリリースサイクルを可能にするために）少数のボードしかサポートされていませんが、標準の作業モデルでは、外部のボードサポートレイヤーを使用します。
最後に、Yoctoは非常に柔軟でカスタマイズ可能です。特定のアプリケーションのカスタマイズは、カプセル化と分離のためにレイヤーに保存できます。フィーチャレイヤーに固有のカスタマイズは、通常、レイヤー自体の一部として保存されます。これにより、同じ設定を複数のシステム構成に同時に適用できます。 Yoctoは、明確に定義されたレイヤーの優先度とオーバーライド機能も提供します。これにより、レイヤーが適用されてメタデータが検索される順序を定義できます。また、優先度の高いレイヤーの設定を上書きすることもできます。たとえば、既存のレシピに対する多くのカスタマイズがプライベートレイヤーに追加され、優先順位によって順序が正確に制御されます。
Yoctoプロジェクトの最大の欠点は、学習曲線です。システムを学び、真に理解するには、かなりの時間と労力がかかります。ニーズによっては、これは、アプリケーションの中心ではないテクノロジーと能力への投資が多すぎる場合があります。このような場合、商用ベンダーの1つと協力することは良い選択肢かもしれません。
Yoctoプロジェクトのビルドでは、開発のビルド時間とリソースがかなり長くなります。ツールチェーン、カーネル、およびすべてのターゲットランタイムコンポーネントを含む、ビルドする必要のあるパッケージの数は重要です。 Yocto開発者向けの開発ワークステーションは、大規模なシステムになる傾向があります。コンパクトなノートブックの使用はお勧めしません。これは、多くのプロバイダーから入手可能なクラウドベースのビルドサーバーを使用することで軽減できます。さらに、Yoctoには、特定のパッケージをビルドするためのパラメーターが変更されていないと判断した場合に、以前にビルドされたコンポーネントを再利用できるキャッシュメカニズムが組み込まれています。
次の組み込みLinux設計にYoctoプロジェクトを使用することは強力な選択です。ここに示されているオプションの中で、ターゲットのユースケースに関係なく最も広く適用できます。幅広い業界サポート、活発なコミュニティ、および幅広いプラットフォームサポートにより、これはマストデザイナーにとって良い選択です。
Buildrootプロジェクトは、「クロスコンパイルによって組み込みLinuxシステムを生成するためのシンプルで効率的で使いやすいツール」として定義されています。 Yoctoプロジェクトと同じ目的の多くを共有していますが、シンプルさとミニマリズムに焦点を当てています。一般に、Buildrootは、すべてのパッケージのすべてのオプションのコンパイル時設定を無効にし（いくつかの注目すべき例外を除く）、システムを可能な限り最小にします。特定のデバイスに適切な設定を有効にするのは、システム設計者の責任です。
Buildrootは、すべてのコンポーネントをソースからビルドしますが、オンターゲットパッケージ管理をサポートしていません。そのため、イメージはビルド時に大部分が修正されるため、ファームウェアジェネレーターと呼ばれることもあります。アプリケーションはターゲットファイルシステムを更新できますが、実行中のシステムに新しいパッケージをインストールするメカニズムはありません。
Buildrootの出力は、大きく3つのコンポーネントで構成されています。
- Linuxをターゲットプラットフォームにデプロイするために必要なルートファイルシステムイメージとその他の補助ファイル
- ターゲットハードウェアに適したカーネル、ブートローダー、およびカーネルモジュール
- すべてのターゲットバイナリを構築するために使用されるツールチェーン。
Buildrootがシンプルさを重視しているということは、一般的に、Yoctoよりも習得が容易であることを意味します。コアビルドシステムはMakeで記述されており、開発者がシステム全体を理解できるように十分に短く、組み込みLinux開発者のニーズを満たすために十分に拡張可能です。 Buildrootコアは通常、一般的なユースケースのみを処理しますが、スクリプトを介して拡張できます。
Buildrootシステムは、構成に通常のMakefileとKconfig言語を使用します。 KconfigはLinuxカーネルコミュニティによって開発され、オープンソースプロジェクトで広く使用されているため、多くの開発者に馴染みがあります。
オプションのビルド時設定をすべて無効にするという設計目標のため、Buildrootは通常、すぐに使用できる構成を使用して可能な限り最小のイメージを生成します。同様に、ビルド時間とビルドホストリソースは、一般的にYoctoプロジェクトよりも短くなります。
シンプルさと最小限の有効なビルドオプションに重点を置くことは、アプリケーションのBuildrootビルドを構成するために大幅なカスタマイズが必要になる可能性があることを意味します。さらに、すべての構成オプションは1つのファイルに保存されます。つまり、複数のハードウェアプラットフォームがある場合は、プラットフォームごとにカスタマイズを変更する必要があります。
システム構成ファイルを変更するには、すべてのパッケージを完全に再構築する必要があります。これは、Yoctoと比較して最小のイメージサイズとビルド時間によっていくらか軽減されますが、構成を微調整している間、ビルドが長くなる可能性があります。
中間パッケージ状態のキャッシュはデフォルトでは有効になっておらず、Yoctoの実装ほど完全ではありません。つまり、最初のビルドは同等のYoctoビルドよりも短い場合がありますが、後続のビルドでは多くのコンポーネントの再構築が必要になる場合があります。
次の組み込みLinux設計にBuildrootを使用することは、ほとんどのアプリケーションにとって良い選択です。設計で複数のハードウェアタイプやその他の違いが必要な場合は、複数の構成の同期が複雑であるため、再検討する必要がありますが、単一のセットアップで構成されるシステムの場合、Buildrootが適切に機能する可能性があります。
OpenWRT / LEDE
OpenWRTプロジェクトは、コンシューマールーター用のカスタムファームウェアを開発するために開始されました。最寄りの小売店で入手できる低コストのルーターの多くは、Linuxシステムを実行できますが、すぐに使用できるわけではありません。これらのルーターのメーカーは、新しい脅威に対処するための頻繁な更新を提供していない可能性があります。提供している場合でも、更新されたイメージをインストールするメカニズムは難しく、エラーが発生しやすくなっています。 OpenWRTプロジェクトは、メーカーによって放棄された多くのデバイスの更新されたファームウェアイメージを生成し、これらのデバイスに新しいリースを提供します。
OpenWRTプロジェクトの主な成果物は、多数の商用デバイス用のバイナリイメージです。デバイスのエンドユーザーがシステムに新しいソフトウェアを追加できるようにする、ネットワークにアクセス可能なパッケージリポジトリがあります。 OpenWRTビルドシステムは汎用ビルドシステムであり、開発者は独自の要件を満たすカスタムバージョンを作成し、新しいパッケージを追加できますが、その主な焦点はターゲットバイナリです。
商用デバイスの交換用ファームウェアを探している場合は、OpenWRTがオプションのリストに含まれているはずです。それはよく維持されており、メーカーのファームウェアでは不可能な問題からあなたを守るかもしれません。機能を追加して、デバイスをより便利にすることもできます。
組み込み設計がネットワークに重点を置いている場合は、OpenWRTが適しています。ネットワークアプリケーションはOpenWRTの主な使用例であり、それらのソフトウェアパッケージの多くがOpenWRTで利用できる可能性があります。
OpenWRTは、設計に重要なポリシー決定を課します（YoctoおよびBuildrootと比較して）。これらの決定が設計目標を満たさない場合は、重要な変更を行う必要がある場合があります。
展開されたデバイスのフリートでパッケージベースの更新を許可することは、管理が困難です。これは、定義上、QAチームがテストしたものとは異なるソフトウェア負荷になります。さらに、ほとんどのパッケージマネージャーでアトミックインストールを保証することは困難であり、電源を入れ直すタイミングが悪いと、デバイスが予測できない状態になる可能性があります。
OpenWRTは、趣味のプロジェクトや商用ハードウェアの再利用に適しています。また、ネットワーキングアプリケーションにも適しています。デフォルト設定から大幅なカスタマイズが必要な場合は、BuildrootまたはYoctoをお勧めします。
組み込みLinuxシステムを設計するための一般的なアプローチは、DebianやRed Hatなどのデスクトップディストリビューションから始めて、インストールされたイメージがターゲットデバイスのフットプリントに収まるまで不要なコンポーネントを削除することです。これは、RaspberryPiプラットフォームで人気のあるRaspbianディストリビューションで採用されているアプローチです。
このアプローチの主な利点は、親しみやすさです。多くの場合、組み込みLinux開発者はデスクトップLinuxユーザーでもあり、選択したディストリビューションに精通しています。ターゲットで同様の環境を使用すると、開発者はより迅速に開始できる場合があります。選択したディストリビューションに応じて、aptやyumなどの標準のパッケージツールを使用して多くの追加ツールをインストールできます。
ディスプレイとキーボードをターゲットデバイスに接続して、すべての開発をそこで直接行うことができる場合があります。組み込みスペースを初めて使用する開発者にとって、これはより馴染みのある環境である可能性が高く、トリッキーなクロス開発セットアップを構成して使用する必要がなくなります。
ほとんどのデスクトップディストリビューションで利用できるパッケージの数は、一般に、前述の組み込み固有のビルダーで利用できるパッケージの数よりも多くなります。ユーザーベースが大きく、ユースケースの種類が多いため、アプリケーションに必要なすべてのランタイムパッケージが既に構築されており、すぐに使用できる場合があります。
ターゲットをプライマリ開発環境として使用すると、時間がかかる可能性があります。コンパイラツールの実行はリソースを大量に消費する操作であり、構築するコードの量によっては、パフォーマンスが低下する可能性があります。
一部の例外を除いて、デスクトップディストリビューションはリソースの少ないシステムに対応するように設計されておらず、ターゲットイメージを適切にトリミングすることが難しい場合があります。同様に、デスクトップ環境で期待されるワークフローは、ほとんどの埋め込みデザインには理想的ではありません。この方法で再現可能な環境を取得することは困難です。パッケージを手動で追加および削除すると、エラーが発生しやすくなります。これは、Debianベースのシステムのdebootstrapなどのディストリビューション固有のツールを使用してスクリプト化できます。再現性をさらに向上させるために、CFEngineなどの構成管理ツールを使用できます（完全な開示は、私の雇用主であるMender.ioによって行われます）。ただし、あなたはまだ配布プロバイダーに翻弄されています。配布プロバイダーは、あなたのニーズではなく、ニーズに合わせてパッケージを更新します。
市場に出す予定の製品については、このアプローチに注意してください。これは、趣味のアプリケーションに最適なモデルです。ただし、サポートが必要な製品の場合、このアプローチは問題になる可能性があります。より早くスタートできるかもしれませんが、長期的には時間と労力がかかる可能性があります。
この説明では、ビルドシステムの機能に焦点を当てていますが、通常、決定に影響を与える可能性のある非機能要件があります。システムオンチップ（SoC）またはボードをすでに選択している場合、選択はベンダーによって決定される可能性があります。ベンダーが特定のシステムにボードサポートパッケージ（BSP）を提供している場合、それを使用すると通常はかなりの時間を節約できますが、開発サイクルの後半で問題が発生しないように、BSPの品質を調査してください。
予算が許せば、ターゲットOSに商用ベンダーを使用することを検討することをお勧めします。ここで説明するオプションの多くの検証済みでサポートされている構成を提供する企業があります。組み込みLinuxビルドシステムの専門知識がない限り、これは適切な選択であり、コアコンピテンシーに集中できます。
>別の方法として、開発スタッフ向けの商用トレーニングを検討することもできます。これは、商用OSプロバイダーよりも安価である可能性が高く、自給自足が可能になります。これは、選択したビルドシステムの基本の学習曲線をすばやく乗り越える方法です。
最後に、1つ以上のシステムの経験を持つ開発者がすでにいる場合があります。好みのあるエンジニアがいる場合は、それを考慮して決定する価値があります。
概要
組み込みLinuxシステムの構築には多くの選択肢があり、それぞれに長所と短所があります。プロセスの後半でシステムを切り替えるには非常にコストがかかるため、設計のこの部分に優先順位を付けることが重要です。これらのオプションに加えて、新しいシステムが常に開発されています。うまくいけば、この議論が新しいシステム（およびここで言及されているシステム）をレビューするためのコンテキストを提供し、次のプロジェクトの確実な決定を下すのに役立つでしょう。