Linux のためのオープン BIOS

最近のシステムはレガシーのブート・プロセスにしがみつく必要はありません

多くのシステムでは、ブート時間の大部分を MS-DOS に対するレガシー・サポートに費やされています。LinuxBIOS や Open Firmware など様々なプロジェクトでは、特定のシステム専用に作られた BIOS システムを、Linux® カーネルをロードし、実行するために必要なことのみを行う、整理されたコードで置き換えようとしています。この記事では、こうした分野の概要を説明します。

Peter Seebach (dwlinux@plethora.net), Writer, 自由职业者

Author photoPeter Seebachは、たしかこの辺にFileメニューがあったはずだと思っています。Peterはコンピューターを使い始めてすぐに、プログラミングを始めましたが、いまだにGUIを目新しく感じています。



2006年 8月 31日

ビープ音

電源をオンすると、PC のハードウェアは当然のようにビープ音を鳴らしますが、このビープ音を鳴らすためには少しばかりコードが必要です。このコード片がブート・ファームウェアであり、大部分の PC では、BIOS と呼ばれます (BIOS は basic input/output system の頭文字を取ったものです)。BIOS は、初期の x86 オペレーティング・システムがディスクやモニター、その他あらゆるものにアクセスするために使っていた、基礎となるハードウェア・サポートを提供します。

BIOS が最初にすることの中には、電源オン時の様々なテストがあります。つまり、利用可能なメモリーを認識し (場合によってはテストし)、クロック・スピードを判断し、等々を行います。テストが成功すると、マシンはビープ音を 1 度鳴らします。 このプロセスは、パワーオン・セルフ・テスト、あるいは POST と呼ばれます。コンピューター「おたく」であれば、POST を動詞に使って、「あのマシンは POST もしない。メモリーを交換しよう」などという言い方をします。

一般的な自己診断には、ビープ・コード (ベンダーによって異なります) や、特定の生アドレスに書き出される診断コードなどが含まれます。一部のプラグイン・カードでは、こうしたコードに手軽にアクセスできるようになっています。標準的なソリューションとして、診断コードはポート 80 に書き込まれます。一部のメーカーは、ポート 80 にどんなバイトが書き込まれても、最後に書き込まれたバイトを 16 進で表示するプラグイン・カードを販売しています。本格的なデバッグをする場合には、こうしたものが必要になるでしょう。あるいはもっと汎用の小道具、例えば、最後に書き込まれたいくつか (256) の POST コードを読み取れるように記録してくれる、PC Weasel などが必要になります。( PC Weasel について詳しくは、下記の「参考文献」のセクションを見てください。) 当然ですが、こうしたコードの具体的な意味は BIOS 毎に異なり、それらにを文書化しているベンダーは一部にすぎません。幸いなことに、オープンソースのベンダーは、こうしたものの文書化には非常に優れています。

BIOS は今まで私達に何をしてくれたのか

MS-DOS のようなオペレーティング・システムは、CD-ROM ドライバーなど、追加のデバイス・ドライバーをロードすることができますが、すべてのハードウェア・ドライバーは、起動時に既にロードされている必要があります。こうしたドライバーに提供される標準インターフェースは、BIOS によって処理されます。そのため BIOS は、デバイスを検出し、識別し、場合によっては使える状態に初期化する必要があります。

同様に BIOS は、メモリーの初期化にも責任を持ちます。すべてのオペレーティング・システムでメモリーの初期化が要求されるわけではありませんが、初期の DOS システムでは要求された場合が多く、今日でさえ、ほとんどの BIOS では、恐らく互換性を保つという理由から初期化を行っています。このプロセスのみでも時間が長くかかるため、最近のほとんどのシステムでは、この初期化を完全に、あるいは部分的に無効にできるようになっています。また BIOS は同時に、どのくらいの量のメモリーが利用可能かも認識しようとします。その他、ブート時に行われる可能性のある動作としては、プロセッサーのキャッシュの初期化や有効化、デュアル CPU の設定、プロセッサーに関する情報の表の作成、システムに付加された PCI デバイスのリストの作成、さらには、こうしたデバイスが提供するブート ROM の実行まであります (ブート ROM を実行すると、さらに追加してドライバーがロードされるかもしれません)。

これは大量の作業です。実際、あまりにも大量の作業なので、私の持っている一部のシステムでは、POST と、それに続くドライバー初期化動作を完了するまでに、丸々 1 分間、あるいはもっと時間がかかります。BIOS は、ブート可能なデバイスを探して様々なハードウェア・スキャンを行うことがあり、一部のシステムでは、イーサネットを介してネットワーク・ブートを実行しようとする場合さえあります。私が持っている 1 台のシステムでは、たとえネットワーク・ブートが無効になっていても、ネットワーク・ブート・パラメーターの初期化に 5 秒間近くもかけるのです。実にやっかいです。

最後に重要な点として、BIOS はかなりの量の初期化動作を行います。これらのすべてが有用なわけではありませんが、一部の動作は、どんなものをブートする場合でも有用です。例えば、デバイスに対して IRQ (interrupt request) を割り当てることは、実際に便利なサービスかもしれません。OS はこれによって、単にデバイス・リストを見るだけで、デバイスをプログラムしなくても実行を開始できるからです。多くのデバイスはコンフィギュレーション・レジスターを持っており、BIOS はシステムの書き込み可能メモリーの中に置かれている設定に基づいて、このレジスターに、妥当な、あるいは正確な値を書き込みます。(一般的に、このメモリーは CMOS と呼ばれますが、必ずしも CMOS 技術を使って実装されていることが絶対に必要なわけではありません。)

これらがすべて終了したら、BIOS は何をするのでしょう。BIOS は、どこか (通常はディスク上) にあるコードの塊を見つけて実行し、一般的にはそれによってオペレーティング・システムがロードされます。オペレーティング・システムが DOS、あるいはDOS に似たシステムの場合には、こうした一連のセットアップ動作によって、間もなくコマンド・プロンプトが表示される状態になります。


重複する作業

しかし、Linux や BSD、Windows® などでは、オペレーティング・システムが独自のドライバーを持っています。そのため、オペレーティング・システムは、付加された PCI ドライバーのリストを読み取り、こうしたドライバーをロードし始めます。そのため、BIOS が行った作業の大部分は無視されます。つまりオペレーティング・システムは SCSI ドライバーをロードすると、SCSI バスに対して独自のスキャンを行います。BIOS は情報を提供するのみであり、しかも提供する情報の大部分は使われることすらありません。BIOS が本来すべきだったのは、最初のひとかたまりのコード (ブートストラップ・ローダー、あるいはブートローダー) をロードし、マシンを実行させることだけだったのです。

つまり重装備されたマシンの場合には、すべてのデバイスが検出されるのを 2 度待たなければなりません。多くの場合、SCSI コントローラー用のブート ROM によるデバイスの検出は、かなりの時間がかかります。さらに悪いことに、そのブート ROM の実行中は、他のものが何も実行できません。対照的に最近のオペレーティング・システムでは、とにかく SCSI ドライバーをロードし、バス・リセットをかけてから他のドライバーのロードを続け、他の作業を行ってからデバイスのチェックに戻ります。つまり、オペレーティング・システムによるスキャンは、BIOS スキャンよりも速いのです。

実際のスピードの違いは、オペレーティング・システムによります。しかし私達は、Linux のブート時のスキャンが非常に速いことを知っています。つまり BIOS は、パワー・アップから最後のカーネル・ドライバーのロードまでの時間のうち単純に半分を使っているのではなく、おそらくもっと多くの時間を使っているのです。この事実は、あまり重要ではないカーネル・モジュール (サウンド・ドライバーなど) のロードなど、ブート・プロセスのかなり遅い時点、場合によると、より重要なもの (Web サーバーなど) がロードされてオンラインになった後で行われるロードでは、一層顕著になります。

私達が望んでいるのは、BIOS が大量の設定を行うのを待たずにカーネルをロードする方法、つまり、後からカーネルが行う設定を BIOS に行わせず、より速く、より的確に、そしてより信頼性高く行える方法です。


カーネルをフラッシュに入れる

当然ながら、すべてのデバイス・ドライバーを BIOS から削除してしまうことには懸念があります。もし BIOS がデバイス・ドライバーを全部ロードしないとしたら、BIOS はどのようにしてカーネルを読み込むのでしょう。単純なソリューションは、デバイス・ドライバーを削除することで解放されるすべての空間を使って、最小限のカーネルを保持することです。このカーネルの中にロードが必要なのは、他のロード可能モジュールが保持されているディスクに対するデバイス・ドライバーのみです。これがロードされれば、カーネルが起動した後で、それらのモジュールを動的にロードすることができます。

最近の BIOS フラッシュ・チップのサイズのおかげで、こうした代替手段は驚くほど現実的なものとなっています。多くのシステムでは、BIOS 用に 1 メガバイトか 2 メガバイトのフラッシュ・メモリーが利用可能です。場合によると、BIOS が実際にその程度の大きさのこともあります。また、とにかくチップは非常に安価です。余分なものを極力排除して圧縮されたカーネルは、そうした空間に容易に収まる上、Linux のブート・ローダーは、圧縮されたカーネルを非常に小さな解凍プログラムで解凍することができます。

このソリューションは、本格的なカーネル開発を行う人にとっては、おそらく適切ではないでしょう。しかし、とにかくできるだけ速くブートするシステムが必要な場合には、適切な選択肢かもしれません。LinuxBIOS プロジェクト (「参考文献」を参照) はこうしたソリューションに向けて作業を行っており、その対象としては、サーバーや組み込みシステムのユーザーが最適に思われます。


Open Firmware

MS-DOS 用に設計されたものではないブート・ファームウェアの主なソースとして、Open Firmware があります。この、ブート・ファームウェアのオープンスタンダードは、主に Sun と Apple で使われていますが、DOS スタイルのシステムよりも、オリジナルの Mac OS や Mac OS X、または Solaris など、自分でドライバー処理を行うシステムに焦点を当てて設計されています。Open Firmware の大きな利点は、「一度書けば、どこででも実行できる」ことです。Open Firmware 用のブート ROM を持つデバイスは、そのデバイスをプラグインできるバスを持つ Open Firmware システムであれば、どんなシステムでも問題なく実行します。ただし問題は、x86 PC 用に作られたデバイスで Open Firmware 用のブート ROM を持つものが、ほとんど無いことです。しかし、そうしたブート ROM を持つデバイスが見つかれば、そのデバイスは適切な選択肢かもしれません。もちろんそのためには、ハードウェア・プラットフォームを規定できること、特定のコンポーネントに標準化できることが必要です。

Open Firmware は世の中にあるものの中で、おそらく最もハッカーに使いやすい BIOS スタイルのウィジェットでしょう。Open Firmware は LinuxBIOS プロジェクトのような高速ブートは重視していませんが、一般的に言って従来の PC BIOS よりもずっと速く、自分のマシンを設定できる手段を求めるユーザーにとっては特に使いやすく作られています。

x86 のベンダーがデフォルトで Open Firmware を使うようになれば、世の中はもっと住みやすくなるはずです。


フリー BIOS を実現するための他の方法

従来の BIOS の基本的な機能を単純に再現しようとする BIOS であっても、多くの場合は従来のものよりも高速でオープンなものになります。例えば、デバイスを検出しようとして BIOS が遅くなる問題は、検出に 5 秒から 10 秒もかかるようなデバイスをそのシステムが持っていないことがわかれば、調整が可能です。

フリー BIOS で実現できる重要な側面として、ブート・ローダーを柔軟に構築できることがあげられます。例えば、OpenBIOS プロジェクトは LinuxBIOS と組み合わせて使われています。LinuxBIOS の下位レベル・コードと、そのペイロードに OpenBIOS Forth カーネルを使い、システムを Open Firmware にブートストラップするのです。x86 システムに関する作業で最も難しい部分は、実際のブート・ローダーをロードする、ごく小さなコード・ブロックを作ることです。柔軟な BIOS では、そうした作業を柔軟に行えるため、その問題を解消することができます。

LinuxBIOS は主に Linux を対象にしていますが、他のもののブートにも使われていることに注意してください。例えば、2002 年の末、LinuxBIOS のチームは、LinuxBIOS から Windows 2000 をブートすることに成功しました。互換性やサポートを広げるための全般的な作業は続けられていますが、システムをブートするために独自ソフトウェアに依存することは避けようとする考え方は、相変わらず重要な基本となっています。

非常に特化された、しかしフリーではない BIOS プログラムも世の中にはいくつかあります。例えば、Soekris Engineering 社のマシンは、comBIOS という BIOS を実行します。これは従来の BIOS よりもずっと単純で小さく、しかもずっと速くブートします。


見る目の数は多くても、資料がない

コンピューターの問題と格闘する際の最も一般的な助言として、BIOS の更新があげられます。なぜでしょうか。理論的には、いったんシステムがロードされてしまえば BIOS は使われません。しかし実際には、BIOS によって行われる初期化は致命的な重要性を持っている可能性があります。例えば、私が使っていた組み込みの x86 システムでは、カードバス (CardBus) コントローラーが使えませんでした。このコントローラーに対して IRQ をプログラムする必要があったのです。この問題は、BIOS を更新することで解決できました。理論的には、オペレーティング・システムが、このカードバス・コントローラーの正確なモデルを認識して IRQ をプログラムする特別なコードを作れたのかもしれません。しかし、この特定のボードに専用のコードを書き、コントローラーを正しくプログラムすることに関しては、ボードのベンダーの方が有利だったのです。

一般的には、オープンソース・システムの方が、バグを適切に修正できるとされています。しかし、BIOS に関しては、必ずしもそうとは言えません。オリジナルのハードウェア・ベンダーは、汎用の BIOS の開発者が知り得ない追加情報を持っている可能性があります。もっと汎用の、何十種類ものボード上で実行するフリーのソフトウェア BIOS を作る必要があるのです。そうすればベンダーも、異なるハードウェア上でのコードの動作を心配する必要が無くなり、的確な想定ができるようになります。

いずれにせよ、オープンソースの手法には多くの利点があります。例えば、私が使っている古い Alpha システムに載っている BIOS は、Symbios Logic の 875 SCSI コントローラー・チップをサポートしています。しかし、この BIOS では、この BIOS がサポートする PCI ベンダーと製品 ID のペアのリストがハード・コード化されており、このリストに載っているカードでないと動作しません。動作するカードであっても、リストに載っていなければ、単純に無視されてしまいます。BIOS はクローズド・ソースであり、しかも多少意図的に複雑に作られているため、単純にテーブルにパッチを当てることはできません。おかげで私は、物理的にはまったく同等で 75 ドルで市販されているカードの代わりに、特定のベンダーの、220 ドルもする SCSI カードを買わざるを得ませんでした。

おそらく転換点となるのは、マザーボードのベンダーが、商用提供されている主要な BIOS の代わりにオープンソースの BIOS を使うことを決めるときでしょう。それが実際に起こるかどうか、いつ起こるのか、私にはわかりませんが、サポートやドキュメンテーションが充実した BIOS が登場すれば、素晴らしいことだと思います。


これらをすべて利用する

大部分のユーザーにとって、ここに書いたようなことは、まだ現実的ではありません。BIOS フラッシュ・チップへの書き込みミスは非常に危険です。そのチップを再書き込みしない限り、コンピューターは動作しません。しかも、コンピューターをブートしてチップに書き込むことができないため、特別なハードウェアが必要になります。一部のシステムでは、2 つのフラッシュ・チップを持っており、1 つをブート用に使ってから、もう 1 つをプログラムできるようになっていますが、すべてのシステムがそうなっているわけではありません。そのため、大部分の人にとっては、別の BIOS 設計を試すことは少し危険です。とはいえ、壊れても構わないような古い予備のコンピューターを皆さんが持っており、それがフリー BIOS プロジェクトのどれかでサポートされているのであれば、ちょっと試してみるのも楽しいかもしれません。特にホビーストには魅力的でしょう。

サーバー・ファームや組み込みシステムを扱っている人であれば、今日のこうした技術から得られるものはずっと多いかもしれません。もしリセットに要する時間が重要な場合には、ここで説明したものがハードウェア上で動作するように時間と手間をかけることは、大いに価値があります。それに、組み込み開発のプロジェクトでは、少なくとも 1 つ、馬鹿げたことやサポートされていないことをしなくては楽しくありません。

長期的には、この技術によってベンダーは選択肢を広げることができます。組み込みシステムのベンダーにとっては、ブート・ファームウェアに関する選択肢が広がります。そして選択肢が広がることによって、ごく一部による独自の BIOS 設計から、よりオープンで競争の激しいマーケットへの移行が起きるでしょう。

参考文献

学ぶために

製品や技術を入手するために

  • LinuxBIOS project は、Linux をサポートすることに直接の焦点を当てています。
  • The OpenBIOS project は、PowerPC® と x86 の両方のシステムで実行する、フリーの Open Firmware 実装を構築しようとしています。
  • PC Weasel は、新しい BIOS を実行する場合にも古い BIOS を実行する場合にも便利です。これを利用すると、VGA カードとキーボードを持っているという認識のマシンに対してシリアル・コンソールからアクセスでき、また POST コードにアクセスすることもできます。
  • Technologic Systems も自家製の BIOS プログラムを持っており、彼らの持つ、非常に高度な x86 組み込みシステムで使われています。
  • Soekris Engineering は自家製の BIOS プログラムを配布しており、また blinkenlight を使った素敵な装置も作っています。
  • developerWorks から直接ダウンロードできる IBM trial software を使って、皆さんの次期 Linux 開発プロジェクトを構築してください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=231221
ArticleTitle=Linux のためのオープン BIOS
publish-date=08312006