ARM cortex-A8でELinuxカーネルを使用しています。
ブートローダーがどのように機能し、どのような仕事をしているのかはわかっています。しかし、私は質問を持っています-なぜブートローダーが必要なのですかなぜブートローダーが生まれたのですか?
ブートローダーを使わずに、フラッシュメモリからRAMにカーネルを直接ロードできないのはなぜですか?それをロードするとどうなりますか?実際、プロセッサはそれをサポートしませんが、なぜ手順に従うのですか? ?
ブートローダーは、セルフテストの完了後にコンピューターのメインオペレーティングシステムまたはランタイム環境をロードするコンピュータープログラムです。
^ Wikipedia Article から
つまり、基本的にブートローダーは、フラッシュからオペレーティングメモリにデータをコピーするという、望みどおりのことをしています。とても簡単です。
OSのブーストラッピングについて詳しく知りたい場合は、リンク先の記事を読むことを強くお勧めします。ブートフェーズは、テストとは別に、周辺機器やその他のチェックも行います。それらをスキップすることは、非常に単純な組み込みデバイスでのみ意味があり、それがブートローダーがさらに単純な理由です。
一部の組み込みシステムは、機能を開始するのに目立った起動シーケンスを必要とせず、電源を入れると、ROMに格納されている運用プログラムを実行するだけです。
同じソース
Linuxのコンテキストでは、ブートローダーはいくつかの事前定義されたタスクを担当します。この質問には arm タグが付いているので、- ARM booting は有用なリソースになると思います。具体的には、ブートローダーは、RAMの量、カーネルコマンドライン、およびその他のパラメーターを説明するATAG
リストの設定を担当していました。最も重要なパラメータの1つは、マシンタイプです。 device treesを使用すると、ボードの説明全体が渡されます。これにより、在庫ARM Linuxは、説明されているようにパラメータをセットアップするためのコードなしで起動することが不可能になります。
パラメータを使用すると、1つのgenericLinuxで複数のデバイスをサポートできます。たとえば、ARM Debianカーネルは数百の異なるボードタイプをサポートできます。Ubootまたは他のブートローダーは動的に決定できますこの情報またはそれはボードのためにハードコーディングすることができます。
bootloader info ページのスタックオーバーフローを確認することもできます。
基本的なシステムではATAGS
をセットアップしてNOR flash to SRAMにコピーできます。ただし、通常はこれよりも少し複雑です。LinuxにはRAMセットアップなので、SDRAMコントローラを初期化する必要がある場合があります。NANDフラッシュを使用する場合は、不良ブロックとコピーを処理する必要がありますはmemcpy()
よりも少し複雑かもしれません。
Linuxには、ドライバーがクロックが初期化されていると想定するドライバーの潜在的なバグがしばしば存在します。たとえば、Ubootが常に特定のマシンのイーサネットクロックを初期化する場合、Linuxイーサネットドライバーはこのクロックのセットアップを怠っていた可能性があります。これは、クロックツリーで特に当てはまります。
一部のシステムでは、Linuxでサポートされていないブートイメージ形式が必要です。たとえば、ハードウェアをすぐに初期化できる特別なヘッダー。初期コードを読み取るためのdevices
の構成と同様です。さらに、多くの場合、すぐに構成する必要のあるハードウェアがあります。 ブートローダーはこれをすばやく実行できますが、Linuxの通常の構造はこれを大幅に遅延させ、I/O競合などを引き起こす可能性があります。
実用的な観点からは、ブートローダーを使用する方が簡単です。ただし、Linuxのソースを変更して、そこから直接ブートすることを妨げるものは何もありません。 ブートローダーコードを直接Linuxの先頭に貼り付けるようなものかもしれませんが。
関連項目: Coreboot 、 boot 、および Wikipediaの比較 。 ベアボックス はあまり知られていませんが、ARM用のよく構造化された最新のブートローダーです。 RedBoot は一部のARMシステムでも使用されます。RedBootパーティションはカーネルツリーでサポートされています。
プライマリブートローダーは通常シリコンに組み込まれており、システムで実行される最初のUSERコードのロードを実行します。
ブートローダーはチップに依存するため、最初のコードをロードするための標準化されたプロトコルがないために存在します。コードは、シリアルポート、フラッシュメモリ、またはハードドライブを介してロードできる場合があります。それを見つけるためのブートローダー機能です。
ユーザーコードが読み込まれて実行されると、ブートローダーは使用されなくなり、システム実行の正確さはユーザーの責任になります。
組み込みLinuxチェーンでは、プライマリブートローダーがUbootをセットアップして実行します。次に、UbootはLinuxカーネルを見つけてロードします。
ブートローダーを使わずに、フラッシュメモリからRAMにカーネルを直接ロードできないのはなぜですか?ロードするとどうなりますか?実際、プロセッサはそれをサポートしませんが、なぜ手順に従うのですか? ?
Bartek、Artless、およびFelipeはすべて、画像の一部を提供します。
すべての組み込みプロセッサタイプ(EG 386EX、Coretex-A53、EM5200)は、リセットまたは電源投入時に自動的に(somethingを実行します。 somethingは、電源を入れ直すか、デバイスをリセットするかによって異なる場合があります。一部の組み込みプロセッサでは、デバイスの電源投入時またはリセット時にさまざまなピンに印加される電圧に基づいてsomethingを変更できます。
いずれにせよ、プロセッサー上の物理スペースが必要であるため、プロセッサーが実行できるsomethingには制限があります。 somethingを定義します。それがオンチップFLASH、命令マイクロコード、またはその他のメカニズムであるかどうか。
この制限は、somethingが
したがって、リセットまたはパワーサイクルに応じてプロセッサが実行する処理は変更できず、あまり実行できません。また、存在しないか初期化されていない可能性がある数百メガバイトまたはギガバイトをメモリに自動的にコピーしたくない場合、そして、それは非常に時間がかかる可能性があります。
そう....
使用するすべてのデバイスで許可される最小サイズよりも小さい小さなプログラムを設定します。そのプログラムはsomethingが必要な場所に保存されます。
小さなプログラムがU-Bootの場合もあります。場合によっては、U-Bootでも初期ロードには大きすぎることがあるので、小さなプログラムがU-Bootをロードします。
重要なのは、somethingによってロードされるものはすべてであることです。 modifiable特定のシステムの必要に応じて。それがU-Bootである場合は、メインのオペレーティングシステムをロードする場所またはU-Boot(または他のブートローダー)をロードする場所を認識しています。
U-Boot(一般的にブートローダーと言えば)は、デバイス、メモリ、チップ設定などの最小限のセットを構成して、メインOSをロードして起動できるようにします。メインOS initは、追加の構成や初期化を処理します。
したがって、シーケンスは次のとおりです。
カーネルでは、作業しているハードウェアが特定の状態である必要があります。使用したすべてのハードウェアの状態を確認し、その後の操作のために初期化する必要があります。これは、カーネル(カーネルイメージをRAMにロードするための使用とは別に、組み込み(またはその他の環境)でブートローダーを使用する主な理由の1つです。
システムをオンにすると、RAMもカーネルをロードするために完全に初期化された)有用な状態ではありません。したがって、カーネルに直接(質問に答えるため)、したがって、カーネルを初期化するための構成が必要になります。
他のすべての回答で述べられていることとは別に、これは正しいです。場合によっては、システムがさまざまな実行モードを経由する必要がある場合は、例としてTrustZoneを安全に使用するARMチップです。それでもHWの初期化の一種と見なしますが、1つのバイナリですべてを実行すること、つまりブートローダーの複数の段階を実行することは不可能ではないにしても非現実的であるという追加の制限(例:使用可能なメモリ)があるという事実があります。利用可能です。
さらに、セキュリティ上の理由から、それぞれが署名されており、セキュリティ要件を満たしている場合にのみジョブを実行できます。