UbootドライバーとLinuxドライバーの違い
組み込み Linux システムを学習したり移植したりするときに、Uboot ドライバーの移植や Linux ドライバーの開発に触れることがありますが、このとき、組み込み Linux 初心者は必ず次のような疑問を抱くでしょう。
Uboot には、関連するチップ プラットフォームと外部ハードウェア デバイス用のドライバーがすでに用意されていますが、なぜ Linux カーネルにドライバーを統合する必要があるのでしょうか? 以下で説明します。
Ubootドライバー
Uboot はオープン ソース ブート ローダーの 1 つです。どのような種類のブート ローダーであっても、その中心的な役割は組み込みシステム (Linux カーネルなど) を起動することであるため、Uboot は次のような不揮発性メモリからデータをロードする必要があります。 FLASH と MMC: Linux カーネルを読み出し、実行のためにカーネルを DDR や RAM などの揮発性メモリに移動します。
Uboot は Linux カーネルを不揮発性メモリから読み取って移動する必要があるため、Uboot 自体が最初に不揮発性メモリ (MMC など) とメモリ (DDR など) を駆動する必要があります。
上記はシナリオの 1 つにすぎませんが、たとえば、Uboot は、その後のプログラムのダウンロードやデバッグを容易にする USB およびネットワーク通信機能も提供します。たとえば、USB を使用したり、NFS ファイル システムや TFTP サービスを使用して、ネットワーク経由で Linux カーネル イメージをダウンロードしたりできます。
たとえば、Uboot はコマンド対話をサポートしていますが、シミュレートされた端末でコマンドを入力および出力するには、プロセッサのシリアル ポート Uart を使用してコンピュータ上の端末エミュレータと通信する必要があるため、Uboot も Uart を駆動できる必要があります。
Uboot は最終的に特定のチップ上で動作するため、上記のドライバーはこのチップの規則に従って作成する必要があります。たとえば、Uboot が Allwinner sunxi シリーズ チップで実行される場合、MMC ドライバーは Allwinner sunxi シリーズ チップのレジスタ ルールに従って作成される必要があります。たとえば、Uboot にはドライバー sunxi_mmc.c が含まれており、「allwinner sunxi プラットフォーム用の MMC ドライバー」とマークされています。
Uboot ドライバーは、Linux カーネル プログラムの起動とロードの要件のみを満たす必要があり、通常、ドライバーは比較的単純です。
Linuxドライバー
Linux はオペレーティング システム カーネルに属し、コンピューター上のさまざまなハードウェア リソースを管理したり、ハードウェア デバイスからデータを読み取る必要があるため、Linux カーネルにはハードウェアを駆動できるドライバーも必要です。たとえば、ユーザーに画面表示を提供する必要がある場合、Linux カーネルが画面を駆動できる必要があります。たとえば、ユーザーに入力を提供する必要がある場合、Linux カーネルはキーボード、マウス、マイク、カメラ、USB ディスク、その他のデバイスを駆動できる必要があります。オーディオを再生できるようにするには、スピーカーを駆動できる必要があります。
Linux カーネルのドライバーは、Linux カーネルだけで使用されるわけではありません。Linux カーネル自体を使用するだけでなく、システム内で実行されている他のアプリケーションにもドライバーを提供する必要があります。そのため、Linux カーネル ドライバーは、アプリケーション呼び出しへのインターフェイスのセット (open、read、write、close)。それだけでなく、ドライバーをより適切に分離するために、Linux カーネルにはより複雑なドライバー フレームワークも必要です。
Linux ドライバーはハードウェア リソースを管理し、アプリケーションにユーザーレベルのハードウェア操作インターフェイスを提供する必要がありますが、ドライバーは通常複雑です。
Linux カーネルにドライバーが必要なのはなぜですか?
冒頭で挙げた疑問に戻ります: Uboot には関連するチップ プラットフォームと外部ハードウェア デバイス用のドライバーがすでに用意されていますが、なぜ Linux カーネルは依然としてドライバーを統合し、ドライバーを管理するためにデバイス ツリーを使用する必要があるのでしょうか。
たとえば、Uboot は MMC を駆動していますが、Linux カーネルは依然として単独で MMC を駆動する必要があります。これはなぜでしょうか? これは、ルート ファイル システム rootfs も MMC に配置されているためで、MMC からルート ファイル システムをマウントするには、Linux カーネルが MMC にアクセスできる必要があるため、MMC ドライバーが必要です。
Linux カーネルが Uboot の MMC ドライバーを使用しないのはなぜですか? という疑問もあるかもしれません。
主な理由は次の 3 つです。
(1) Uboot の動作段階では、MMC ドライバーは Uboot ベア メタル ルールに従って実装され、純粋なベア メタル ドライバーであるため、Linux カーネルは Uboot MMC ドライバーを認識できません。
(2) Linux カーネルが Uboot ドライバーを認識できたとしても、Uboot によって Linux カーネルがメモリにロードされ、実行がトリガーされた瞬間から、Uboot の責任は終了し、Uboot に含まれるすべてのプログラムは実行されなくなります。したがって、当然ながら Uboot ドライバーは使用できず、最終的にはすべてのコンピューターのハードウェアを Linux カーネルによって制御する必要があります。
(3) Uboot のベアメタル ドライバーはプログラムにハードコーディングされているため、使用が柔軟性に欠け、ハードウェア デバイスの管理が不便で、ドライバーの個別のインストールまたはアンインストールをサポートできません。
特例：
前述したように、Uboot は DDR (ダブル データ レート メモリ) を使用する必要があるため、通常、DDR は Uboot 内で初期化されます。Linux カーネルの起動後に再度 DDR を駆動する必要はありません。代わりに、Uboot によって渡された DDR 構成情報が使用されます。 DDRの読み取りと書き込みを行います。
したがって、DDR ドライバーは特殊なケースであり、Linux の起動後、Linux カーネル自体は DDR にあるため、Linux カーネルは DDR を再初期化できません。そうしないと、Linux カーネルが失われるため、Linux カーネルは Uboot によって提供される DDR ドライバーを使用する必要があります。 。
DDR は Uboot で正常に初期化されました。カーネルの起動プロセス中に、カーネルは Uboot によって渡された DDR 構成情報を読み取り、この情報を使用してメモリ コントローラーと DDR を正しく構成します。
DDR は、アプリケーションに公開する必要がなく、柔軟性要件がないシステム レベルのハードウェア リソースであるため、Linux カーネルが Uboot によって提供される DDR 構成を直接使用しても、大きな影響はありません。
デバッグ方法の違い
Uboot はベアメタル プログラムであり、Uboot プログラムをチップにダウンロードして実行するには、STLink や SWD などのデバッグ ツールに頼るか、半導体チップ メーカーによってチップ上に固化された USB 転送プログラムを使用するしかありません。
Uboot ドライバーのサポートにより、シリアル ポート、USB、イーサネット、SD カードまたは U ディスク、さらにはワイヤレス ネットワークなどを介して、Linux カーネル プログラムをチップにダウンロードするためのより多くの方法があり、Linux カーネルは次のことを行う必要があります。 Uboot を開始する前に、Uboot によってメモリにロードされる必要があります。