Linux システムを直接起動できない場合、ブートストラップはどのように作成しますか?

Question

最初のブートストラップはどうやって作られたのでしょうか?

ブートストラッププログラムの構築 (作成とクロスコンパイル) は、あなたが示唆しているほど難しいことではありません。

私が実際に話しているのは ARM デバイスについてであることを指摘しておく必要があります。一般的なマシンで BIOS 経由でロードする基本は理解していますが、カスタムデバイスについて話しているとしたらどうでしょうか?

あなたが言及している BIOS は、本質的には PC の慣例です。(CP/M にも BIOS がありましたが、必ずしも不揮発性メモリ内にあるわけではありませんでした。) ARM CPU には通常、BIOS はなく、使用もされません。

現在使用されている典型的なARMプロセッサは、周辺機器と統合された単一のICであり、ソニック、システムオンチップ。メインメモリ (DRAM など) と不揮発性ストレージ (NAND フラッシュなど) は、設計の柔軟性を最大限に高めるために、通常は SoC の外部にあります。ただし、通常は、ブートストラップ操作を開始するために最小限のシステムコンポーネントを初期化するための小さな (おそらく 128 KB) 組み込み ROM (読み取り専用メモリ) があります。プロセッサをリセットすると、常にこのブート ROM が実行されます。(この ROM は完全に読み取り専用であり、変更できません。コードは、チップの製造中にシリコンにマスクされます。)

各 SoC ベンダーには、OS をロードして実行するための独自のブートストラップメソッドがあります。GPIO ピンを介してハードウェアストラッピング読み取りを使用して、ブートストラップシーケンスの次のステージのソースを決定するベンダーもあります。別のベンダーは、メモリとデバイスの順序付きリストを使用してブートストラッププログラムを探します。別の手法は、直接実行できる NOR フラッシュのファームウェアに分岐することです (つまり、XIP、インプレース実行)。

メインメモリに DRAM を使用するシステムのブートストラップの問題の 1 つは、ハードウェアの初期化です。コードを DRAM にロードして実行する前に、DRAM メモリコントローラを初期化する必要があります。では、この初期化コードはメインメモリには置けないので、どこに保存すればよいのでしょうか。
各ベンダーには独自のソリューションがあります。ブート ROM がアクセスできるように、メモリ構成データを不揮発性メモリに保存する必要があるものもあります。一部の SoC には、小さなブートストラッププログラムを実行するために、SRAM (DRAM のように初期化を必要としない) が統合されています。一部の SoC は、XIP ブートストラッププログラムを保持するために NOR フラッシュを使用します。

ブートストラッププログラムが DRAM を初期化したら、メインメモリを使用して次のブート段階をロードできます。これは、U-Boot などの高度なブートユーティリティ、または (ブートストラッププログラムが対応している場合) Linux カーネルである可能性があります。プロセッサのリセットから OS の実行までの間に、複数のブートストラッププログラムまたは段階が実行される場合があることに注意してください。

Linux ARM カーネルを起動するための要件は、次のドキュメントに記載されています。http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
Linux ARM の古いバージョンでは、ATAG リストを使用して基本的な構成情報をカーネルに渡していました。最新バージョンでは、デバイスツリーのコンパイル済みバイナリを使用して完全なボード構成を提供します。

明らかに、「ブートストラップはどのように作成しますか?」という質問には、何らかの条件なしには答えられません。

PC BIOS と同様に、SoC のブート ROM は独自のものであり、公開されていません (NDA に署名しない限り)。ただし、他のほとんどのブートコードは GPL または同様のライセンスの下で公開されており、簡単に入手できます。

付録

Zynq 7000（Xilinx SoCを使用）を使用しているとのことですが、Xilinxにはビデオチュートリアルがあります。Linuxブートイメージの構築方法そのビデオは
、私がすでに書いたことを裏付けています。1
. Xilinx SoC には、組み込みブート ROM (技術的には第 1 ステージですが、無視されるか、ステージ 0 として説明されることが多い) があります。2
. 次のステージのブートストラッププログラムのソースを指定するための「モードピン」があります。3
. ブート ROM は、組み込み SRAM に FSBL と呼ばれるブートストラッププログラム (技術的には第 2 ステージですが、多くの場合「第 1」ステージとして説明されます) をロードします。このプログラムは DRAM を初期化し、次のステージである U-Boot をロードします。4
. U-Boot は DRAM から実行され、Linux カーネルをロードします。

このビデオでは、FSBLソースコードをXilinxサイトからダウンロードし、数ステップでクロスコンパイルできることを説明しています。"騙す"あなたが主張するとおりです。ビルドは単純な構成とクロスコンパイルであり、一般的なアプリケーションパッケージよりもシンプルで簡単だと思います。

おそらく、あなたの混乱はブートメディアの曖昧さ、つまりブートイメージのソースが指定されていないことによるものでしょう。ビデオでは、NAND フラッシュと SD カードがブートデバイスとして考えられます。
ブート ROM は、モードピンによって設定されたソースメディアから FSBL イメージを読み取るように指示されます。

FSBL (私が使用した他のブートストラップと同様) は、構成されたソースメディアから U-Boot を読み取るように構築されています。ランタイムの代替手段はありません。

U-Boot はその名前 (「ユニバーサル」) にふさわしい機能を実現しようとしており、さまざまなデバイスからイメージ (およびスクリプト) をロードするように (環境変数を使用して) 設定できます。対話型オプションもあります。

Xilinx wikiもご覧くださいZynq Linuxは、「Zynqの起動に関する完全な情報は、技術リファレンスマニュアル「」。

Answer 1