linux - 組み込みデバイスにブートローダーが必要なのはなぜですか?

Question

ARM cortex-A8 で ELinux カーネルを使用しています。

ブートローダーがどのように機能し、どのような仕事をしているのかを知っています。しかし、質問があります。なぜブートローダーが必要なのですか?なぜブートローダーが生まれたのですか?

ブートローダなしでカーネルをフラッシュメモリから RAM に直接ロードできないのはなぜですか? ロードするとどうなりますか？実際、プロセッサはそれをサポートしていませんが、なぜ手順に従っているのでしょうか?

Answer 1

Linux のコンテキストでは、ブート ローダーはいくつかの事前定義されたタスクを担当します。この質問にはアームタグが付けられているので、 ARM ブートは役立つリソースになると思います。ATAG具体的には、ブート ローダーは、RAM の量、カーネル コマンド ライン、およびその他のパラメーターを記述するリストの設定を担当していました/現在も担当しています。最も重要なパラメータの 1 つはマシン タイプです。デバイス ツリーでは、ボードの完全な説明が渡されます。これにより、ストック ARM Linux は、説明されているようにパラメーターを設定するためのコードがないと起動できなくなります。

パラメータにより、1 つの汎用Linux で複数のデバイスをサポートできます。たとえば、ARM Debian カーネルは何百もの異なるボード タイプをサポートできます。 Ubootまたはその他のブート ローダーは、この情報を動的に決定するか、ボード用にハード コードすることができます。

また、こちらのスタック オーバーフローのブートローダー情報ページもご覧ください。

ATAGS基本的なシステムでは、NOR フラッシュをセットアップして SRAM にコピーできる場合があります。ただし、通常はこれよりも少し複雑です。Linux では RAM のセットアップが必要なため、SDRAM コントローラーを初期化する必要がある場合があります。NAND フラッシュを使用する場合、不良ブロックを処理する必要があり、コピーは よりも少し複雑になる可能性がありますmemcpy()。

Linux には、ドライバがクロックが初期化されていると想定する潜在的なドライバ バグが存在することがよくあります。たとえば、Ubootが特定のマシンのイーサネット クロックを常に初期化する場合、Linux イーサネット ドライバーはこのクロックの設定を怠っている可能性があります。これは、特にクロック ツリーに当てはまります。

一部のシステムでは、Linux でサポートされていないブート イメージ形式が必要です。たとえば、ハードウェアをすぐに初期化できる特別なヘッダー。devicesから初期コードを読み取るように構成するのと同じです。さらに、多くの場合、すぐに構成する必要があるハードウェアがあります。ブートローダーはこれをすばやく実行できますが、Linux の通常の構造ではこれが大幅に遅れて I/O 競合などが発生する可能性があります。

実用的な観点からは、ブートローダーを使用する方が簡単です。ただし、Linux のソースをそこから直接起動するように変更することを妨げるものは何もありません。ブートローダのコードを Linux の先頭に直接貼り付けるようなものかもしれませんが。

関連項目: Coreboot、Uboot、およびウィキペディアの比較。Bareboxはあまり知られていませんが、適切に構造化された最新の ARM 用ブート ローダーです。 RedBootは一部の ARM システムでも使用されています。RedBoot パーティションは、カーネル ツリーでサポートされています。

Answer 2

ブートローダーは、セルフテストの完了後にコンピューターのメインオペレーティングシステムまたはランタイム環境をロードするコンピュータープログラムです。

^_{ウィキペディアの記事から}

つまり、基本的にブートローダーは、フラッシュからオペレーティングメモリにデータをコピーするというあなたが望むことを実行しています。とても簡単です。

OSのブートストラップについて詳しく知りたい場合は、リンク先の記事を読むことを強くお勧めします。ブートフェーズは、テストとは別に、周辺機器やその他のチェックも含みます。それらをスキップすることは、非常に単純な組み込みデバイスでのみ意味があります。そのため、ブートローダーはさらに単純です。

一部の組み込みシステムは、機能を開始するために目立った起動シーケンスを必要とせず、オンにすると、ROMに格納されている操作プログラムを実行するだけの場合があります。

_{同じソース}

Answer 3

プライマリ ブートローダは通常、シリコンに組み込まれており、システムで実行される最初の USER コードのロードを実行します。

チップに依存するため、最初のコードをロードするための標準化されたプロトコルがないため、ブートローダーが存在します。場合によっては、シリアル ポート、フラッシュ メモリ、またはハード ドライブを介してコードを読み込むこともできます。それを見つけるのがブートローダー機能です。

ユーザー コードが読み込まれて実行されると、ブートローダーは使用されなくなり、システム実行の正確性はユーザーの責任になります。

組み込み Linux チェーンでは、プライマリ ブートローダーが Uboot をセットアップして実行します。次に、Uboot は Linux カーネルを見つけてロードします。

Answer 4

ブートローダなしでカーネルをフラッシュメモリから RAM に直接ロードできないのはなぜですか? ロードするとどうなりますか？実際、プロセッサはそれをサポートしていませんが、なぜ手順に従っているのでしょうか?

Bartek、Artless、および Felipe はすべて、全体像の一部を示しています。

すべての組み込みプロセッサ タイプ (EG 386EX、Coretex-A53、EM5200) は、リセットまたは電源投入時に自動的に何らかの処理を行います。電源を入れ直すか、デバイスをリセットするかによって、何かが異なる場合があります。一部の組み込みプロセッサでは、デバイスの電源投入時またはリセット時にさまざまなピンに印加される電圧に基づいて何かを変更できます。

とにかく、オンチップフラッシュ、命令マイクロコード、またはその他のメカニズムであるかどうかにかかわらず、何かを定義するために必要なプロセッサ上の物理スペースのため、プロセッサが実行できることには制限があります。

この制限は、何かが

• 固定された目的で、1 つのことをできるだけ迅速に実行します。
• 通常、コードの小さなブロック (多くの場合、数キロバイト以下) を固定メモリ位置にロードし、ロードされたコードの先頭から実行します。
• 変更不可。

そのため、リセットまたは電源の再投入に応じてプロセッサが行うことは変更できず、あまり行うこともできません。数百メガバイトまたはギガバイトを、存在しないか初期化されていない可能性のあるメモリに自動的にコピーすることは望ましくありません。そして、これには長い時間がかかる可能性があります。

そう....

使用するすべてのデバイスで許可されている最小サイズよりも小さい小さなプログラムをセットアップします。そのプログラムは、何かが必要な場所に保存されます。

小さなプログラムが U-Boot の場合もあります。U-Boot でさえ最初の読み込みには大きすぎる場合があるため、小さなプログラムが次に U-Boot を読み込みます。

ポイントは、 somethingによって読み込まれるものはすべて、特定のシステムの必要に応じて変更できるということです。U-Boot の場合は素晴らしいですが、そうでない場合は、メインのオペレーティング システムをロードする場所または U-Boot (または他のブートローダー) をロードする場所を認識しています。

次に、U-Boot (一般的にブートローダーについて言えば) は、最小限のデバイス、メモリ、チップ設定などを構成して、メイン OS をロードして起動できるようにします。メイン OS init は、追加の構成または初期化を処理します。

したがって、シーケンスは次のとおりです。

• プロセッサの電源投入またはリセット
• 何かが初期ブート コード (または U-Boot スタイルの組み込みブートローダー) をロードします。
• 初期ブート コード (不要な場合があります)
• U-Boot (またはその他の一般的な組み込みブートローダー)
• Linux 初期化

Answer 5

カーネルは、作業中のハードウェアが特定の状態にあることを必要とします。使用したすべてのハードウェアは、その状態をチェックし、その後の操作のために初期化する必要があります。これは、カーネル イメージを RAM にロードするために使用する以外に、組み込み環境 (またはその他の環境) でブート ローダーを使用する主な理由の 1 つです。
システムの電源を入れると、RAM もカーネルをロードするのに役立つ状態 (使用するために完全に初期化された状態) ではありません。したがって、(質問に答えるために) カーネルを直接ロードすることはできないため、カーネルを初期化するための構造が必要になります。