BSPとデバイスドライバー
それぞれを理解している（または理解していない）間、私は2つの間の実際的な違いを理解するのには程遠いようです。
私の理解では、BSPはドライバーと構成設定のパッケージであり、カーネルイメージがボードを起動できるようにします（その一部です）。個々のデバイスドライバーは、特定のコンポーネント（HW）で動作し、一方の側でコアカーネルとインターフェイスし、もう一方の側でデバイス自体とインターフェイスします。
Linuxカーネルを見ると、BSPの役割がどこで始まり、デバイスドライバーの役割がどこで終わるのかがわかりません。具体的には、イメージごとにボードごとに1つのBSPを表示するのに慣れていますが、汎用Linuxカーネルは同じイメージを持つ任意のアーキテクチャファミリーにロードできます（異なるファミリーには異なるイメージがあることは明らかです：x86、AMD64、arm、 etc ...）、必要に応じて特定のボードおよび周辺機器ドライバーがinitrdからロードされます。
一般的なLinuxカーネルディストリビューション用のBSPはありますか？または、BSPは特別なケースのボードにのみ関連していますか？
この動作は他のカーネルでも似ていますか？ VxWorks？
最後の1つは、さまざまなボードに適合する単一のイメージを生成するために、さまざまなBSPをマージすることは一般的ですか？
BSPとデバイスドライバーの関係は "has-a"と表示されます。ボードサポートパッケージには、デバイスドライバーが含まれています。
BSPとカーネルの違いは簡単に区別できません。カーネルは命令をハードウェアに変換します。カーネルは 特定のハードウェアファミリ に書き込まれることが多いため、見た目ほど移植性や汎用性はありません。これは、アーキテクチャファミリごとに異なるコードの順列に相当します。
BSPは、その逆のようなものとして機能します。BSPは、そのボードの特定のハードウェアセットで動作するツールと手順を提供します。特定の制御された状況では、カーネルがこの作業を行うことができます。しかし、BSPは 設定手順 に従って、互換性のあるカーネル/ OS /アプリケーションスタックがそのボードを使用できるようにします。
CPUサイクルとメモリ、おそらくいくつかのプロトコル（USB、イーサネット、いくつかのビデオタイプ）にアクセスする必要があるだけの場合、幅広いアーキテクチャをサポートするカーネルは素晴らしいものであり、そのハードウェアアブストラクションの幅が最後から2番目に評価される時期がありました。 。しかし今、ボードには センサーのスイート （加速度計、磁力計、ジャイロスコープ、光、近接、大気圧など）、テレフォニー、複数のCPU、複数のGPUなどがある可能性があることを考慮してくださいオン。カーネルは、VGA/DVI/HDMI/DisplayPortと、CPU/GPUの組み合わせのいくつかの組み合わせを提供するように作成できます（特定のハードウェアパッケージを使用する場合/その場合）が、理論上のすべてのコンテキストのサポートを作成することは、特定のボード用に構築されたBSP。それでも、それは1つのカーネルに当てはまります。ボードはLinux、Windows、Android、Symbianなどをサポートできます。
そのため、カーネルとハードウェアをさらに分離するために Yocto のような取り組みが存在します。 BSPはハードウェアセットをkernel/os/appスタックを超えて拡張可能にし、カーネルは特定のos/appスタックを複数のHWアーキテクチャ上で移植可能にします。
私の経験に基づくと、BSPははるかに大きな範囲です。これには、ブートローダー、rootfs、カーネル、ドライバーなどが含まれます。つまり、BSPを使用すると、ボードを起動できます。ドライバーはデバイスを機能させ、BSPの一部にすぎません。
ドライバーはBSPとは異なります。
今日、再利用性を高めるためにモジュール化されています。組み込みシステムのソフトウェア開発は、通常3つの層に分かれています。
- カーネル（タスク処理、スケジューリング、メモリ管理を含む）
- スタック（デバイスドライバーの上位層であり、I2C、SPI、イーサネット、SDIO、シリアル、ファイルシステム、ネットワークなどのプロトコル実装を提供します）
- BSP =デバイスドライバー（I2C、SDIO、SPI、Ethernet_MAC、UART（シリアル）、割り込み処理（ISR）のレジスターのようなハードウェア上のコントローラーのレジスターへのアクセスを提供します。
ボードサポートパッケージ（デバイスドライバー）は、他の2つのソフトウェアレイヤーを変更せずにボードごとに変更するソフトウェアレイヤーです。
ボードサポートパッケージには、アプリケーションでボードを使用するために必要なものがすべて含まれています。これには、ボード上のデバイス用のデバイスドライバーや、アプリケーションプログラマー用のユーティリティソフトウェアが含まれます。ウィンドウ環境もマルチメディアボードで利用できます。システムエンジニアは、ボードに拡張機能をさらに追加できます。一部のアプリケーションでは、機能強化のためにbspの一部を再実装する必要があります。ここで、bspは、リファレンス実装またはそのような要件の開始点の役割を果たします。
混乱はビジネスモデルにあります。リファレンスボードまたは開発ボードは、モバイルデバイスのようなエンド/コンシューマー製品ではありません。 iPhoneやSamsung Galaxyのような製品を設計、開発することは重要な役割を果たします。
ジェネリックbspはほとんどの場合最適化を欠いているため、初心者モデルのジェネリックbsp、または最適化が残されている場所でのみ期待できます。安価なボードの場合、BSPは非常に一般的です。プロデューサーが投資する投資額が少ないためです。
利用可能なマイクロカーネルもあるので、カーネルとユーザースペースの面であまり強調しないでください。ここで、ドライバーはユーザー空間の一部です！カーネルのないコードが1つしかない低電力ボードをもう一度考えてみてください。つまり、それは、そのボードの機能をサポートするソフトウェアに要約されます。
ドライバーは、デバイスの動作のようにカーネルに伝えるプログラムです...デバイスは、USBデバイス、カメラ、またはBluetoothの場合もあれば、何でもかまいません。操作のサイズに基づいて、3つの文字、ブロック、ネットワークに分類します。しかし、それは各デバイスへのアクセスのみを提供します...それはデバイスのみを構成し、メモリ、CPU速度は構成しません。そのプロセッサまたはコントローラに指示を与えることはありません。それはそのプロセッサーまたはコントローラーでの作業です。誰が機能を定義するマイクロコントローラーを有効にするか、誰がマイクロコントローラーの開始点を与えるか...誰が指示を与えるか。 BSPのような答えが出てきます.................... Bspは、ブートローダーを有効にするボードサポートパッケージです。システムの動作を示します。 2つのシナリオを考えてみます。1つは、USBコネクタオプションを持つPCにPCがあり、これは最初のシナリオです。2つ目は、PCを持っています。私がやります...
この場合、OSを搭載したPCを使用しているため、システムの動作を考慮する必要はありません。システムOSを搭載したデバイスの動作を有効にするだけです。
この場合、ボードとは、すべての周辺機器を備えたプロセッサを意味します。この場合、OSがないため、デバイスを作成するか、そのデバイスの動作を有効にする必要があります。
デバイスドライバー/カーネルモジュールがハードウェアアブストラクションを実行し、ボードサポートパッケージがデバイスドライバーへのインターフェイスを提供する、またはハードウェアアブストラクションレイヤー自体であるという意味で、ボードサポートパッケージとHAL（ハードウェアアブストラクションレイヤー）の間に概念的なリンクがあります。 。
したがって、基本的にBSPには、DOS時代のBIOSと同様の機能があります：
さらに、BSPは次の操作を実行することになっています。
- プロセッサーを初期化する
- バスを初期化する
- 割り込みコントローラーを初期化する
- 時計を初期化する
- RAM設定を初期化します
- セグメントを構成する
- フラッシュからブートローダーをロードして実行する
から： https://en.wikipedia.org/wiki/Board_support_package
最近のPCのBIOSは、システムハードウェアコンポーネントを初期化してテストし、大容量メモリデバイスからブートローダーをロードして、オペレーティングシステムを初期化します。 DOSの時代、BIOSは、キーボード、ディスプレイ、およびその他の入出力（I/O）デバイス[デバイスドライバー]にハードウェアアブストラクションレイヤーを提供し、アプリケーションプログラムへのインターフェイスを標準化しました最新のオペレーティングシステムは、ロード後にBIOSを使用せず、代わりにハードウェアコンポーネントに直接アクセスします。
ソース： https://en.wikipedia.org/wiki/BIOS
別の側面は、BSPでのデバイスツリーの使用です。デバイスツリーは、マシンのハードウェアを説明する統一または標準化の概念です。
U-bootブートローダーと出荷の準備
Doug Abbott、Linux for Embedded and Real-Time Applications（Fourth Edition）、2018
デバイスツリー
Linuxなどのオペレーティングシステムを新しいプラットフォームに移植する際の最大の問題の1つは、ハードウェアの説明です。 これは、ハードウェアの説明がおそらく数十程度のデバイスドライバー、カーネル、ブートローダーに散らばっているからです（ほんの数例を挙げます）。最終的な結果として、これらのさまざまなソフトウェアはプラットフォームごとに固有になり、構成オプションの数が増え、すべてのボードに固有のカーネルイメージが必要になります。
この問題に対処するためのアプローチはいくつかあります。 「ボードサポートパッケージ」またはBSPの概念は、ハードウェアに依存するすべてのコードを1か所のいくつかのファイルに収集しようとします。 Linuxカーネルソースツリーの
Arch/サブツリー全体が巨大なボードサポートパッケージであると主張できます。カーネルの
Arch/arm/サブツリーを見てください。そこには、mach-*とplat-*という形式の多数のディレクトリがあり、それぞれ「machine」と「platform」の略です。これらのディレクトリ内のほとんどのファイルは、ARMアーキテクチャの特定の実装の構成情報を提供します。もちろん、各実装はその構成を異なる方法で記述します。コンピュータシステムのハードウェアを明確に説明するために使用できる単一の言語があればいいのではないでしょうか。それがデバイスツリーの前提であり、約束でもあります。
システムの周辺機器は、さまざまな次元で特徴付けることができます。たとえば、キャラクターデバイスとブロックデバイスがあります。メモリマップデバイスと、I2CやUSBなどの外部バスを介して接続するデバイスがあります。次に、プラットフォームデバイスと検出可能なデバイスがあります。
検出可能なデバイスとは、PCIやUSBなどの外部バス上に存在するデバイスで、システムの種類と構成方法をシステムに通知できます。つまり、カーネルによって「発見」される可能性があります。デバイスを識別したら、対応するドライバーをロードするのはかなり簡単なことです。ドライバーはデバイスに問い合わせて、正確な構成を決定します。
一方、プラットフォームデバイスは、自身を識別するメカニズムがありません。 Sitaraなどのシステムオンチップ（SoC）の実装には、システムクロック、割り込みコントローラー、GPIO、シリアルポートなど、これらのプラットフォームデバイスが多数あります。デバイスツリーメカニズムは、プラットフォームデバイスの管理に特に役立ちます。
デバイスツリーの概念は、カーネルのPowerPCブランチで発展し、そこで最も使用されているようです。実際、すべてのPowerPCプラットフォームが起動時にデバイスツリーをカーネルに渡すことが要件となっています。デバイスツリーのテキスト表現は、拡張子が.dtsのファイルです。これらの.dtsファイルは通常、カーネルソースツリーの
Arch/$Arch/boot/dtsにあります。デバイスツリーは、コンピューターシステムのデバイスと相互接続バスのコレクションを記述する階層データ構造です。ルートファイルシステムと同様に、「
/」で表されるルートから始まるノードとして編成されます。すべてのノードには名前があり、名前と値のペアである「プロパティ」で構成されています。 「子」ノードが含まれる場合もあります。リスト15.1は、devicetree.org Webサイトから取得したサンプルデバイスツリーです。構造を説明する以外に何もしません。ここには、node1とnode2という名前の2つのノードがあります。 node1には2つの子ノードがあり、node2には1つの子ノードがあります。プロパティは、name = valueで表されます。値は、文字列、文字列のリスト、角括弧で囲まれた1つ以上の数値、または山括弧で囲まれた1つ以上の「セル」です。プロパティがその存在または不在によってブール値を伝える場合は、値を空にすることもできます。
ソース： https://www.sciencedirect.com/topics/computer-science/board-support-package
デバイスツリーオーバーレイ経由でカーネルモジュールを起動時にロードできます。つまり、RPiでdtoverlay=lirc-rpiに/boot/config.txtを追加すると、lirc-piカーネルモジュール/デバイスドライバーがロードされます。
今後のデフォルトのconfig.txtには、次のようなセクションが含まれる可能性があります。
# Uncomment some or all of these to enable the optional hardware interfaces #dtparam=i2c_arm=on #dtparam=i2s=on #dtparam=spi=on一部のパラメータを定義するオーバーレイがある場合、次のように後続の行で指定できます。
dtoverlay=lirc-rpi dtparam=gpio_out_pin=16 dtparam=gpio_in_pin=17 dtparam=gpio_in_pull=down
ソース： https://www.raspberrypi.org/documentation/configuration/device-tree.md
Yoctoを使用してBSPを構築すると、デバイスドライバー、カーネル、ブートローダーなどに散在するすべてのハードウェア情報が収集されます。これは、Yoctoでこれを行う方法を開発者向けガイドで示したものですhttps://www.yoctoproject.org/docs/2.5/bsp-guide/bsp-guide.html
[Yoctoのドキュメント] ... BSPは「…ハードウェア固有のコンポーネントのみに関係している」と述べています。最終配布ポイントで、ビルドシステムと他のツールを組み合わせたBSPを出荷できます。ただし、これらは特定の最終製品で偶然に組み合わされる別個のコンポーネントであることを区別することが重要です。」
ソース： https://www.microcontrollertips.com/board-support-package/