Open Boot の階層的な名前付けの構造は、さまざま なバス構造をもつシステムをサポートしている。これは、 比較的単純なバス構造をもつ SPARCstation1 (Open Boot を最初に採用した言 t 算機 ) から、マルチプロセッサ や多重バス、階層的なバスをもつシステムまで対応できる ように拡張されている。 物理白冓造を厳密に反映した Open Boot の命名規則 は、 Solaris 2.0 カーネルの内部の命名方法に影響を与え た。 Sun の Device File System(devfs) は、 Open Boot の命名規則をもとにしている。 Sun の 2 段階目のディスク・プートプログラムは、 Open Boot のもとで動作するように Forth で書き直 された。これによって機能が向上し、サイズが小さくな り、 CPU に依存しないようになった。そのほかの Sun の、、スタンドアローン " プログラムは、 Open Boot に低 レベルのテンヾイスアクセスとメモリ管理を任せられるよう になり、以前より計算機 , 、の依存生が大幅に減少した。 Forth 言語の使用は長期的には有効であったが、初期の 段階ではいくっかの問題が発生した。 ROM 環境では、メ モリ容量に厳しい制限がある。 Forth でメモリを有効に利 用し、 Open Boot の各要素か伺じランタイム・システム を利用できなければ、機能を削らすに Open Boot を実現 することはできなかったであろう。 Forth を使用する際の最初の問題は、 C 言語のように よく知られていないので、うさんくさくみられることであ る。この結果、多くの政治的問題が発生し、プロジェク トの初期段階では多くの時間がその角夬に費やささら に、 F 。 rth プログラマーは、 C プログラマーよりみつける のか難しいという間題があった。この問題の 1 つの解決方 法は実地訓練である。 Sun の Open Boot 開発チームのメ ンバーの 1 人は、 Forth を使った経験がなかったが、使え るように訓練するのはそれはど難しくはなかった。 Open Boot か成功して Forth か業界で受け入れられるようにな るなら、これらの問題の一墻 ; は角夬されるかもしれない。 OS の開発者やハードウェア開発者のうち、 Open Boot の機能を自分たちのハードウェアやソフトウェアのデバッ グに使いたいと考える人は、 30 分はどで、 Forth の機能 の必要な部分を学べるだろう。 F 。 rth プログラムをイ甘軍発性メモリのなかに置けるセル フパッチ機能は、たいへん便利である。この機能によって、 UNIX MAGAZINE 1992.8 Open Bo 高価で混乱を招く ROM のバージョンアップを避けるこ とかできる。 Open Boot のデバック饑能は、よく使われるように なった。いくつかの OS の開発者は Sun の kadb カーネ ルテンヾッガを使うのをやめ、 Open Boot に組み込まれて いる機能を利用するようになった。あるハードウェア・エ ンジニアは、現在、自分で Forth を使って立ち上げると きの診断プログラムを書いている。そして、診断工ンジニ アカ発したプログラムは使わないようになった。言斤プ ログラムの FCode ドライバへの変換は、はんのわすかな 手間でできることもある。 FCode ドライバのための組込みデバッグ機能により、 デバック環境を用意する必要がなくなった。この常駐の ファームウェア・デバック環境により、標準ではない構 成やサポートされていないデバイスによって発生するユー サーの問題は、だいたい電話て解決できるようになった。 FCode 、ドライバは対言乱勺に逆コンパイルでき、順番に実 行およひ検証ができ、パッチが当てられるからである。 失敗 現在の Open Boot アーキテクチャは第 2 版 2 で、第 1 版の多くの間違いを訂正できた。 第 1 版の間題は、時間不足、我々自身の無知、、、誰で も最初は間違う " 症羊などが原因である。第 1 版の問題 には、次のようなものがあった。 ・糸寸アドレス 第 1 版では、テンヾイスのアドレスとして、 CPU の物理 アドレス空間でのアドレスを返していた。こは、親の デバイス中アドレス空間を使用すべきであった。 ・プートドライバの未サポート 取イ寸け可能なディスプレイ・デバイスのドライバはサ ポートしていた。プートドライバもサポートしようとし たが、正しく動作しなかった ( 設引・の難しさとバグのた め ) 。これは、第 2 版でサポートされるようになった。 ・、。スな互換羅 2 UNIX カーネルとさまざまな中間プートプログラムの 移植を容易にするために、第 1 版では、 Sun の Open Open Boot 第 2 版 (Open Boot 2. X ) は、 SPARCstation2 、 IPX などて利用できる。 OS か起動する前の ROM モニターの状態で、 本文中で述べた絖態を、あれこれ試すことカきるだろう。 115
図 1 Open Boot プロック・ダイヤグラム Forth lJser P 「田 m ROMvec lnterface Fo 曲 Virtual Machine Device Tree FCode 日 - 旧 Devices 技術的な詳細 UNIX MAGAZINE 1992.8 を提供している。 リーの参照やほかの Open Boot の機能を利用する手続き を介して利用する。このインターフェイスは、デバイスッ Open Boot のサービスを ROMvec インターフェイス Open Boot がロードする OS などのプログラムは、 に対言乱勺な Forth インタープリタでも使用されている。 ランタイム・システムによって実行される。これは、同時 ルにコンパイルされて組み込ま Forth のイ廨課言 t 算機の トコードで記述されている。 FCode は、インクリメンタ ライバのための機構は、 FCode と呼ばれる Forth のバイ ンタープリタである。取付け可能デバイスの認識とそのド る。ューザー・インターフェイスは、対言乱勺な Forth イ 前述のように、 Open Boot は Forth をもとにしてい する名前空間を提供する。 している。テンヾイスツリーは、それぞれのデバイスを識別 ある。これは、計算機のハードウェア構成の階層構造を表 Open Boot のデータ構造の中心は、デパイスツリーで 次に、基利勺な考え方について述べる。 : 参具の。 アの標準 IEEE P1275 の草案にある ( 「標準」の節を Open Boot の完全な言当は、プート・ファームウェ Open Boot デパイスツリー Open Boot では、デバイスツリーは命名や、ハ ウェア・デバイスと Open Boot のソフトウェア・パッ ケージの認識に使用される。 構造とアドレス付け テンヾイスは、相互に接続されたバスを通じてシステムに 組み込まれる。 Open Boot は、バスとそれに組み込まれ たテンヾイスをノードのツリーとして表す。そして、ツリー のルートか言算機全体を表す。 それぞれのデパイスノードには、プロバティ ( ノードと これに里するデバイスを言己するデータ構造 ) と、メソ ッド ( テンヾイスのアクセスに使用されるソフトウェア手続 き ) 、そして子どものノード ( そのノードに取り付けられ ているはかのデバイスのノード。デバイスツリーでは、そ のノードの茁妾下にある ) がある。子どものノードをもつ テンヾイスノードを階層ノード (hierarchical nodes) 、子 どものノードがないデバイスノードをリーフノード、ある ノードの茁た E にあるノードを親ノードと呼ぶ。 多くの階層的なノードは、バスとそれに取り付けられ ているコントローラを表す。それぞれの階層ノードでは、 接続されているデバイスを互いに識別する物理アドレス空 間が定義されている。階層テンヾイスに接続されているテンヾ イスには、そのアドレス空間内の物理アドレスを割り当て る。物理アドレスの形式は 1 組の 32bit の数値で、この 2 つの直の使用は、階層デバイスドライバに特有である。 ーヨ殳に、この 2 つの新直はそのデバイスに特有な物理井寺 徴、たとえば、バスのアドレスやデバイスか取り付けられ ノード名 用いたノード名によって識別する。 テンヾイスツリーのなかの各ノードは、次のような言己去を 命名規則 スを変更する必要はない。 のデバイスが取り付けられたときでも、テンヾイスのアドレ ているスロット番号にもとづいている。これにより、ほか をゼ - れ 07 れ e@社れを t - add ess : device-arguments 109 れた文字列である。これは、 1 ~ 31 文字までの文字と数 人間か理解できるデバイスに付けら d ロ眦ルれ ame は、
FCode プログラムのテンヾッグには、 Open Boot 自体 イスドライバ ( ディスクやある種のテーフ用のドライバな のデバッグに使うものと同じツールか利用できる。 FCode ど ) は、このパッケージを利用している。これにより、上 プログラムはコンパイルされ、 F 。 rth プログラムと同し実 位のソフトウェアに対しては一貫してバイトストリームで 行形式になる。そして、逆コンパイラを使えば、ソースコ のインターフェイスか提供できる。このようにして、特 ードに戻せる。新しい FCode ドライバを開発するときに 別なことをしなくても、プートプログラムをさまざまなプ は、プログラムを FCode の形式に変換する必要はない。 ロックサイズのデバイスで動くようにできる。 コードは F 。 rth のソースコードの形式でテストでき、動 端末工ミュレータバッケージはディスプレイ・デバイス くようになれば、 FCode に変換して ROM のなかに置け で使用される。このパッケージは文字を表示するディスフ ばよい。 レイ・デバイスの : 頁に置かれ、 ANSI 端末をエミュレー トし、特定の ANSI ェスケープ・シーケンスを処理する。 不揮発性メモリ ル 1 および 8 パッケージは、ビットマップで文字を表 Open Boot では、いくつかのシステムの成疋用のノヾラ 示するルーチンである。これは、ダム・フレームバッファ メータは、イ寸軍発生メモリのなかに置かれる。どのような をもつデバイスのドライバで使われる。 パラメータがあるかはシステム依存だが、そのなかには、 TFTP ノヾッケージは Trivial File Transfer ProtocoI ューサーか設定・尺できるものが含まれているだろう。 を実装し、ネットワークからの起動のために使用される。 たとえば、起動するデバイスやコンソール・テンヾイスの名 前、入力デバイスのシリアル通信速度などである。ューザ ーやプログラムがこれらのオプションにアクセスする場合 には、人間か読むことができる名前を使う。これらのオフ Open Boot は、 Sun か現在出荷しているすべてのコ ションのイ寸軍発生メモリのなかのオ昜所やエンコード形 ンピュータで使用されており、・変も使用される予定であ 式は、それぞれの Open Boot のみが知っている。これ る。 Force Computer は、 Open Boot ファームウェア により、製品の改良とシステム要求の変化にともなう、新 を、いくっかのプロセッサとバスを使用した新しい製品に しいオプションの追加や旧いオプションの削除が容易に 採用した。 IEEE P1275 Open Boot ワーキンググルー なる。 プは、 Open Boot をもとにしたファームウェア標準につ いて需義をおこなっている。 イ甘軍発性メモリの一碚には、 Forth のソースコードである スクリプト・ファイル NVRAMRC のために使用され 成功 る。 NVRAMRC はユーサーの作成した Forth コマンド を置いたり、拡張、バグフィックス・パッチ、カスタマイ Open Boot では、プロバティのリストを使って計算 機の情報を報告するため、同し OS のカーネルで、多数の ズに使える。 Open Boot は、 NVRAMRC の内容を起 重加に自重加勺に実行する。 ードウェア・プラットホームをサポートできる。 Emacs ふうの行編集機能を使って、 NVRAMRC の 従来は、 Sun の UNIX カーネル自体がサホートしてい る計算機とその緻を判断していた。現在は、 Open Boot 内容を変更できる。 のプロバティリストから、それぞれのキ致 ( キャッシュサ サホート・パッケージ イズなど ) を得ている。新しいハードウェアでも、同しフ Open Boot には、いくつかの系囚みのパッケージがあ ァミリーに属していれは、カーネルを変更する必要はない。 る。これにより、ドライバが実行するいくつかの竹業を助 FCode は言 t 算機に依存しないので、 SBus を計算機か けることができる。 ら独立させることができる。したがって、同し SBus カー deblocker パッケージは、バイトストリームを利用 ドを異なる CPU をもつハードウェアでも使用できる。も した読み書きと、プロック単位での読み書きを変換する。 ちろん、、取り付けられた " デバイスを認識したり、同じ 本質的にプロック単位でアクセスしなければならないデバ プートドライバを使用することもできる。 114 UNIX MAGAZINE 1992.8
Mitch BradIey Chair, P1275 Open Boot Working Group 2732 Katrina Way Mountain View, CA 94040 USA Fax : 十 1 ( 415 ) 962 ー 0927 email:Mitch.BradIey@Eng.Sun. COM そのはかにも、 IEEE での各種の標準化が Open Boot に関連している。たとえば、 IEEE Futurebus 十標準に は、 FCode を使用したデバイス認識の規約が含まれてい る。 IEEE VME-D 標準 ( 草案 ) にも同しような規約が ある。 SBus の仕様は、初めからデバイス認識のために FCode を使用している。 入手方法 Sun Microsystems は、 IEEE プート・ファームウェ アの P1275 標準の一部とするために、 Open Boot の仕 様を IEEE に提出した。そのため、このイ」は自由に入 手できる。また、仕様とそのインターフェイスの使用と実 現も自由である。上記の叫各先に問い合わせれば、 P1275 草案の入手ガ去が分かるだろう。標準が制定されれば、仕 様は IEEE から入手できるようになる。 Sun は、 Open Boot の実装を、 SPARC 上て利用で きるソースコードでライセンスしている。 SPARC 以外 の計算機用のものはない。コードの 10 % 未満の部分が、 SPARC 依存である。著者に問い合わせれば、最新の情 幸ゞ入手できる。ライセンスは、実現に対してのみ適用さ 仕様には適用されない。仕様は自由である。 Sun の Open Boot のもとになった Forth 言語インタ ープリタは、現在、さまざまな計算機 (SPARC 、 680X0 、 386 / 486 など ) て利用できる。これについては、一ド記に問 い合わせてはしい。 BradIey Forthware P. O. Box 4444 Mountain View, CA 94040 USA これ以外に、さらに多くの計算機で利用できる Forth インタープリタがある。詳細は、参考文献欄にある Forth lnterest Group 宛に問い合わせてはしい。 [ 参考文献 ] [ 1 ] IEEE P1275 Standard for Boot Firmware (working draft ) Open Boot のイ土様の最万版。 UNIX MAGAZINE 1992.8 0 〃 e Boot [ 2 ] Forth-83 Standard. Forth Standards Team この標準と、そのほかの Forth に関する文献は次のところか ら入手できる。 Forth lnterest Group, P. O. Box 8231 , San Jose, CA 95155 USA [ 3 ] dpANS-2 ANSI に提案されている Forth プログラミングシステムの 標ま次のところから入手できる。 GlobaI Engineering Documents. lnc. 2805 McGaw Ave. lrvine, CA 92714 USA Order number X3.215-199X. [ 4 ] Devfs テパイス・ファイルシステム。ドキュメントは、これを書い ている時点では入手できない。詳しい情報は著者に間い合わ せてはしい。 [ 5 ] lntroduction to Open B00t2.0 , Sun Microsystems part number 800-5647-10 [ 6 ] Open Boot 2.0 Command Reference , S un Microsys- tems part number 800-6076-10 [ 7 ] Open Boot 2.0 Command Summary(card), Sun Mi- crosystems part number 800-5675 ー 10 [ 8 ] Writing FCode Programs for SBus Cards, Sun Mi- crosystems part number 800 ー 5673 ー 10 ・ Mitch BradIey Sun Microsystems のシニア工ンジニア。 Sun 1 開発当初からのメン バーで、ハードウェアの言 t (SCSI-2 と Multibus 用の Ethernet ポード ) をおこない、デバイスドライバを書き、 UNIX をハックし、は とんどの Sun の CPU ポードの製作に携わった。約 4 年前から Open Boot の言 t と開発に着手しその普及に務めている。 VanderbiIt 大学と Stanford : た学で学位を取得、 Cambridge 大学で ChurchilI 奨学生として学ぶ。 ROLM でアナロク河路の言 1 者、 HP の研究所でフ。ログラマー、ベル研究 所でアナログおよびデジタル回路の言者、プログラマーを経 0 1980 年代より Forth に興未をもち、ハードウェアの診断プログラムを Forth で書き、 C よりはるかに速く見できることを知る。各不臨 1 算機・、、の Forth の実装を専門とする Bradley Forthware クを営者でもある。 ( ◎ 1992 , Sun Microsystems Computer Corp. 117
表 3 メソッド」 名前 erase—screen poll-packet xmit-packet read-blocks write read close open selftest デパイスタイプ 任意 任意 任意 任意 任意 ディスク ネットワーク ネットワーク ディスプレイ draw-character ディスプレイ 機能 テンヾイスのハードウェアテスト デバイスの使用開始 デバイスの使用終了 テンヾイスからの読出し デバイスへの書出し ディスクからのプロックの読出し ネットワー久ンヾケットを送信 バケットの受信 画面のクリア スクリーン上に文字を表示 ている。この拡張には、新しいデバイスノードの追加やプ ロバティの生成や読出しなどが含まれている。 プロービング プロービング (probing) とは、取付け可能なデバイス のために、新たにデバイスツリーを生成する手続きであ る。取付け可能なデバイスは、ユーサーがシステムに、拡 貶ヾスなどを使って取り付けるテンヾイスのことである。 SBus を例にとってみる。 SBus の仕様では、それぞれ の SBus カードには、カードのアドレス空間での 0 バイ ト目から始まる FCode ROM がある。起動川学のプロー プで、それぞれの SBus スロットを検査し、そのスロッ トにある FC 。 de プログラムを実行する。これにより、そ のデバイスに対応する新たなデバイスツリーのノードを生 成し、また、そのデバイスを言己するプロバティを作りだ す。さらにメソッドをコンパイルすることもある。このメ ソッドは、のちにそのデバイスから起動したり、そのテンヾ イスに表示するために使われる。メソッドをコンパイルし た結果は、システムの RAM に置かれ、 FCode の ROM はもはや必要なくなる。 スロットにアドレスか割り付けられていないようなバス (Multibus など ) では、 FCode ROM が置かれているア ドレスのリストを不揮発性メモリのなかに手苻早している。 また、そのなかには FCode ROM 用の場戸励ゞない古いデ バイスのための、 FCode ドライバのメソッドが入ってい ることもある。 プログラム・インターフェイス Open Boot でプートされるプログラムは、 ROMvec インターフェイスを通して Open Boot のサービスか利用 112 できる。 ROMvec は、 C やアセンプラ・プログラムから 呼び出せる手続きを用意している。これらの手続きを使っ て、プートしたプログラムから、テンヾイスツリーをたどる、 プロバティの内容をみる、テンヾイスメソッドの実行、メモ リの割当て、利用可能なメモリサイズを調べることなど、 さまざまな便利な機能が使える。ある ROMvec の手続き を使えは、任意の Forth ソースコードを Open Boot に 送り込んで実行できる。 ROMvec インターフェイスを使えは、 2 段階目のプー トプログラム 1 で Ope Ⅱ Boot のドライバカリ用できる。 Open Boot ドライバは、プート時の使用を想定しており、 OS からの使用は考えられていない。そのため、単純でサ イズが小さくなるように最適化されており、マルチタスク 竟で優れた性能か得られるようにはなっていない。メイ ンの OS に言 t 算機の制御が移り、自由に仮想メモリと物 理メモリを割り当てることができるようになれば、 Open Boot のドライバは不要になる。 ユーサー・インターフェイス Open Boot のユーサー・インターフェイスも、 Forth をもとにしている。すべてのインターフェイスのコマンド は、 Forth の、、ワード " ( 手続き ) である。 Forth は、ス タックを使うプログラミング言語で、後置記法 (postfix syntax) を採用している。 Forth のワードは、その名前を入力すれば実行できる。 ワードの前後には、空白文字 ( スペースやタブ、改行記号 など ) によるデリミタが必要である。 F 。 rth のワードは左 から右に順に実行される。構文は単純 ( 空白文字だけがデ 1 ( 調主 ) Sun の OS のプートは多段階になっている。まず、 ROM が ハードディスクなどに入っているプートコードを読み出し、そのプート コードが /boot を読み出し /boot が /vmunix を読み出す。 UNIX MAGAZINE 1992.8
について日己したプロバティは任意にカ長することがで き、あらゆる不頁のデバイスと、そのすべての情報に適 応できる。デバイスツリーのなかのすべてのノードは、 一意なパス名を使って指定でき、異なる種類のバスが 相互に接続された複雑な階層をもつシステムにも対応で きる。 ・プログラム可能なユーザー・インターフェイス Open Boot のユーサー・インターフェイスは、標準 的な対話的プログラミング言語にもとづいているため、 ューザーが入力するコマンド列も完全なプログラムであ る。これは、ハードウェアとソフトウェアのデバッグ に有効である。たとえば、 Open Boot は最初に新しい ハードウェアとソフトウェアを立ち上げるときに、きわ めて有効である。また、 Open Boot のプログラミング 機能は、多種多様なシステムのバグ修正のために使用さ ・ FCode のテンヾッグ ューザー・インターフェイス言語 (Forth) と FCode 言 語は同じインタープリタで動く。そのため、 FCode プ ログラムは、 Open Boot の内蔵ツールによって開発、 デバッグできる。 ・ OS のデバッグ Open Boot には、 OS のコードをデバッグするシンポ リック逆アセンプラとプレークポイント、そしてカーネ ルのデータ構造をバする手続きがある。この機能によ り、はとんどの場合にカーネルデバッガを使う必要がな くなった。つまり、この機能は Open Boot に内蔵さ れているため、カーネルデバッガを使うときのようにあ らかじめ準備しなくても、クラッシュしたカーネルをデ の基本 バッグできるのである。 108 倣している。テンヾイスツリーの末端ではないノードはバ ードウェアの柤に接続されているバスの階層構造を模 割り当てている。テンヾイスツリーのすべての構造は、ハ れたデバイスを一意に認識できるようにアドレス空間を のレベルでは、それぞれの物理的なバスが、取り付けら ードウェア デバイスツリーの構造とその命名規則は、 ・ Parent-relative な物理アドレス 言 t にあたっては、以下のような基本方針を採用した。 スを表し、その子どものノードは、そのバスに接続され ているデバイス ( はかのバスを含む場合もある ) を表し ている。あるノードとその兄弟のノードとの区別は、親 のノードか表すバスのなかでの、そのデバイスに割り当 てられている物理アドレスによって可能である。 ・プロノヾティリスト テンヾイスについての情報は、任意に拡張できるプロバテ ィリストのなかに置かれている。プロバティの値を表す 唯一の基本的なデータ型は、バイト列のみである。その 情報は、計算機に独立なエンコード / デコードの手続き によって、バイト列に変換される。プロバティは名前に よって参照する。ある名前のプロバティの有無は、値の 有無とは独立である。 手続き型インターフェイス Open Boot の外部インターフェイスは、共有のデータ 構造を参照することよりも、手続きを参照することを基 本に、ファームウェアがそのデータ構造を選んだり、変 更できるようにする。また、ファームウェアと OS と のあいだでのデータの共有 (include-file-coupling) を 減らす。これにより、 OS とファームウェアの開発者の あいだでの調整を減らし、それぞれを独立のスケジュー ルでリリースできるようになる。 ・ Forth の全面的な採用 Forth はシステム言 t の中心となっている。 Forth は、ユーザー・インターフェイス、 FCode ドライ バのインタープリタ、プロバティリストの機構、デバイ スツリーの操作、パッチのためのツール ( 新しい ROM をリリースせすにファームウェアのバグを修正するため に使われる ) 、そしてハードウェアとソフトウェアのデ バッガに用いられる。同しツールと同し去がシステム のすべての構成要素で硬われており、すべての機能はつ ねに利用できるようになっている ( いくつかの、、セキュ リティ・モード " を除いて、システムには本質的にモー ドがない ) 。 ・名前空間の分昔婦司停 Open Boot では、、マジックナンノヾー " をう己するた めの集中的な管理は必要ない。たとえば、デバイスの記 述は文字列になっており、デバイス名はデバイスメー カーの名前から始まるようになっている。 UNIX MAGAZINE 1992.8
ードウェアの一部とみなせるので、 OS の自動コンフィ ギュレーション ()S をハードウェアの違いに合わせる こと ) 作業は簡略化できる。つまり、ファームウェアが、 ードウェアの違いを隠したり、その不頁を OS に伝え ることにより、 OS がハードウェアを認識しなくてもよい ようにするのである。 ファームウェアはエンドユーザーにとってはます関係 がないので、アーキテクチャや言 t に注意か払われること はあまりない。たいていは、、、後回し " にされたり、、、必 ノ、 従来の解決方法 要悪 " とみなされる。 UNIX MAGAZINE 1992.8 機械語で書かれたドライバが入れられている。 く、ほとんどの NuBus カードには依然として 68000 の めたのである。あいにく、これはとりあげられることがな という名前の、 CPU に依存しないバイトコード言語を定 ト用ドライノヾのための Diagnostic Engine Language ある NuBus の規格ではこの問題の解決を試みた。プー バスカ吏われる場合には明らかに間題である。 合には有効だが、複数のべンダーがあり、多様な CPU や メーカーの特定プロセッサの特定のバスしか存しない場 する CPU でしか使用できないのである。これは、特定 れているので、その命令セットを実行またはエミュレート するという問題がある。これらのドライバは機械語で書か しかし、こうした解決策には、ドライノヾか言 t 算機に依存 いるものがある。 PC / AT バス用のカードには、 BIOS のドライバが付いて は、 PDP-II の機械語で書かれたドライバが付いている。 ドライバが付属している。また、一部の QBus カードに 一部の NuBus カードには 68000 の機械語で書かれた ついての間題を解決しようとした。たとえは、 AppIe の そこで、いくっかのメーカーがプート用のドライバに る以前の OS の状況に似ている。 複数のべンダーに採用されて標準になった UNIX か現れ 整合生はほとんどない。現在のファームウェアの状況は、 ぞれのメーカーカ甘是供するファームウェアのあいだには、 らシステム本の調析や制御にまでおよぶ。しかし、それ た。ファームウェアの機能は、単純な ROM モニターか 各メーカーが自社の言 t 算機に固有なものとして開発してき 歴史的には、ファームウェアは専有的な性格のもので、 0 〃 e れお 00 を Open Boot OpenB 。。 t のファームウェア・アーキテクチャは、 れらの問題を解決し、さらに、ハードウェアとソフトウェ アのテンヾッグのために、すべてをプログラムで制蹤卩できる 計算機独立 られる。 Open Boot のおもな特徴として、次のような点か挙げ 特徴 竟を提供する。 ト (property list) によって言当されている。デバイス ツリーのなかのそれぞれのデバイスは、プロバティリス テムのハードウェア構成を知ることができる。デバイス て記述される。 OS はデバイスツリーを調べそのシス イスツリーと呼ばれる Open Boot のデータ構造によっ 取り外せないデバイスも、取り外せるデバイスも、デバ デバイスツリー している。 語 Forth にもとづいた FCode インタープリタを内蔵 ぞれの Open Boot システム ROM は、プログラム言 計算機でも同しデバイスとドライバが使用できる。それ る。言 t 算機に依存しないため、異なる命令セットをもつ に依存しないインタープリタ言語によって言己されてい 取付け可能なドライバは、 FCode と呼ばれる計算機 ・ FCOde の能力を高めることかできるのである。 テム ROM の変更やバージョンアップなしにシステム イバか載っている。このような I / O デバイスは、シス これらのデバイスの ROM 上には、取付け可能なドラ そのテンヾイスにメッセージを表示したりできる。通常、 新しいテンヾイスを付け加えて、そこからプートしたり、 メインの Open Boot システム ROM を変更せすに 取付け可能なデバイスドライバ (PIug-in Device Dri- イスには含まれていない。 機に固有の細かな情報は、 Open Boot のインターフェ で開発されたが、その言 t は CPU に依存しない。計算 当初、 Open Boot は SPARC CPU をもつ言 t. 算機 . 上 107
Boot の前身のファームウェアと互換匪を保とうと試み た。これは新しい言 t 算機への移行で間題を惹き起こし、 とくに、第 1 版のメモリの割当てガ去は悲惨なもので あった。第 2 版では、物理メモリおよび仮想メモリの どちらでも、完全に重加勺な割当てができる。 ・テキスト表示の性能 なぜ Forth なのか いくつかの Open Boot の実装では、テキスト表示の 効率がたいへん悪かった。原因の大部分は、プログラム Open Boot の実現に、 C ではなく Forth を利用した のバグのせいである。基本的なテキスト表示サプルーチ のは次のような理由による。 ンは、キャッシュメモリから実行されるようになってい ます、 Forth か完全な対話型の環境だからである。 c は たが、バグのため、そのページに対するキャッシュを有 本質的には対話型ではない。 C のインタープリタは存在す 効にできなかった。当然のことながら、それらのルーチ るが、ふつうは F 。 rth インタープリタよりかなり大きく、 ンは ROM から実行されるが、これはキャッシュより ROM 工竟のプログラム空間は貴重なためである。 Forth 約 50 倍も遅い。 の構文は単純なので、各種のノ、一ドウェアのテンヾッグに便 ・資源の限界 利であり、基冓造を変えてコマンド言語に刻長するのも 第 1 版では、さまざまな資源一一プロバティリスト 簡単である。次に、 Forth ソースの FCode へのエンコー のサイズや、ノード・ディスクリプタ、イ瓦想メモリ、プ ドは、便利で計算機に依存しない、、中間言語 " だからであ ログラムのための空間などに固定の制限があった。これ る。それは小さく、生成しやすく、高速に実行でき、デ らのうちのいくつかは、過去のものとの互換性のためで バッガの操作も簡単である。最後に、 Forth コードのコン あったが、先見の明のなさときつい作業スケジュール、 パイル効率がとてもよいからである。 SPARC プロセッサ たんなる手落ちによるものもある。第 2 版では、メモリ 上では、同し機能をもつ C コードの半分の大きさになる。 の割当ては一ヨ殳化さより動的になっており、また、 Forth を使用した結果、ファームウェア環境において 固定の制限についても、いくつかは残っているが ( すく きわめて多くの機能が融合された。システムの構成要素 なくと麒点では ) かなり大きくしてある。 のほとんどは、二重三重の機能を備えている。たとえば、 第 2 版はかなりよくできていると思う。現在、 IEEE の Forth の基本コマンドは、ユーサー・インターフェイス Open Boot ワーキンググループがおもに取り組んでいる のコマンドである。同時に、 FCode ドライバの関数やハ のは、次のようなことである。 ードウェア・デバッグッールの機能を兼ね、テンヾイスッ リーを実現する彳難リを担っている。その結果、きわめて多 ・国ヒ くの機能を小さなスペースに入れることかでき、同しユー Open Boot は、 ISO Latin-I の文字セットと多くの サー・インターフェイスのコマンドを、多くの異なる作業 国のキーポードをサポートしている。場伏ではアジアの て利用できるようになった。 文字セットのための準備はされていない。また、コマン ドとエラーメッセージは英語のみである。 仮想メモリの仮定 ファームウェアカイ吏えるイ廨課メモリの範囲については、 OS カーネルとの暗黙の合意がある。これは、違った OS を同レ、一ドウェアで使用するために必要なのて修 正しなければならない。 ・物理アドレス幅 物理アドレスの幅は、現在のところ 64bit で、その形 116 式はバス依存である。新しい 64bit の VMEbus ( 実 質上 70 のアドレスピット幅をもつ ) には、不十分であ る。試案としては、アドレス幅はバス依存とし、依存す る部分については、それぞれのバスのノードに対するド ライバに閉し込めてしまうことが考えられている。 示 IEEE では、 P1275 Open Boot ワーキング・グルー プが、 Open Boot を基礎としたプート・ファームウェア のための標準を需義中である。そのための聳義は、各地で 月に 1 回開かれている。さらに情報が必要な場合には下記 へ連絡してほしい。 UNIX MAGAZINE 1992.8
リミタ ) で、去も簡単佐から右に実行 ) なので、 Forth のインタープリタはごく小さい。 Forth の題直引数は、スタックを使って受け渡される。 引数は、ワードの実行前にスタックに置かその結果は、 実行後にスタックに置かれる。新直は、数そのものを入力 するか、必要とする新直を返すワードを実行すればスタッ クに置くことかできる。 Forth には、ワードを入力順に実行する、、会話状態 " の コンパイル状態 " もある。この状態では、ワー はかに、 ドはインクリメンタルにコンパイルされてメモリのなかに 置かれる。コンパイル状態に入るには、特別な Forth の ワード、 : ( コロン ) を実行すればよい。この状態では、新 しい Forth のワードの生成や名前付けをおこなう。これ に続く Forth のワードは、新しい Forth のワードの一に 分として、コンパイルされて組み込まれる。そして、ワー ド、 ; ( セミコロン ) を入力すれは、新しいワードのコンパ イルは終了し、会話状態に戻る。新しく定義されたワード は、既存のワードとまったく同様に使える。 Open Boot のユーザー・インターフェイス用のコマン ドは、そのはかの Forth 命令と組み合わせて完全なプロ グラムにできる。たとえば、テストループなどである。 ツールキット あらかじめ用意された Open Boot のユーザー・イン ターフェイスのコマンドには、次のようなものがある。 デバイスツリーを詩ヾる ・ほかのプログラム ( たとえば (S) を起重丿ける ・メモリやレジスタの内容を調べる ・診断テストをおこなう ・面寅算およひ論理寅算をおこなう 不揮発生メモリにあるコンフィギュレーションのオプ ションの値を設定する オンラインヘルプにより、利用可能なユーザー・イン ターフェイス・コマンドや Forth の基本的な使い方が分 かる。コマンド行からの入力と編集は、 Emacs ふうのラ インデイタでおこなえる。また、対言乱勺なヒストリとコマ ンド名の補完機能がある。 UNIX MAGAZINE 1992.8 0 〃 e B00 ー テ / ヾッカ ノ、一ドウェア、システム・ソフトウェア、ファームウェ アおよび FCode プログラムのテンヾッグのために、 Forth のワードカ甘是供されている。 Forth 自体の機能と組み合わ せれば、さまざまな診断スクリプトやテストシーケンスが 作成できる。 ハードウェアのデバッグッールには、デバイスごとの 自己診断用のメソッド、たとえば、テンヾイスレジスタのマ ッピングや参照をする低レベルのプリミテイプが含まれて いる。初期化や、画面への表示の整形、監視などの手続き は、これらのプリミテイプと標ま勺な Forth の制徊犠造 やループなどを組み合わせて定義できる。 Open Boot で は、計算機の一・ -- 都分か動作しない場合も対言乱勺で使いやす いデバック環竟カリ用できるので、新しい計算機のハード ウェアを立ち上げるためには有効である。 システム・ソフトウェアのテンヾッグッールには、シン ポリック逆アセンプラと、機戒語プログラムの実行を制御 したり、言算機の状態を表示する Forth のワードがある。 シンポリック逆アセンプラの機能は、特定のシンポルテー プルの形式には依存しない。実行の制御には、ステップ実 行とプレークポイントの設定がある。状態を表示するワー ドを使えば、レジスタの値やメモリ情報、手続き呼出しの ためのフレームなどの参照、設定ができる。実行の制徊坤 状態表示のコマンドは Forth のワードなので、さらに複 雑なデバッグ・スクリプト たとえば、条件付きのプ レークポイントやカーネルデータ構造の表示コマンドなど が定義できる。 多くの ROM べースプログラムは、 ICE やロジック・ アナライザ、あるいは 1 本のシリアル回線でつながって いるようなホスト / ターゲット環竟でテンヾッグしなければ ならないが、 Open Boot は自分自身でテンヾッグできる。 Open Boot で使われている Forth には逆コンパイラが含 まれているので、システムのすべての Forth のワードを ソースコードの形式に戻せる。 Forth のプログラムは、そ れを構成しているワードを対話的に実行することにより、 1 っすっ詩・ヾていくことができる。その結果は、 Forth の 表示コマンドで調べることができる。 Open Boot ファー ムウェアをメモリのなかにコピーすれば、ソースレベルの パッチを当てることができる。 113
Open Boot ファームウェア ファームウェア ファームウェアのおもな仕事は、ハードウェアの検査 とハードディスクあるいはネットワークから OS を起 動する ( 読み込んで実行する ) ことである。通常、ファ ームウェアは、 ROM(Read Only Memory) または PROM(Programmable Read Only Memory) 中にあ り、電源投入後ただちに起動する。 OS は、そのはかのサーピスをファームウェアに要求す ることもある。多くの場合、ファームウェアは、ハ ウェアとソフトウェアの対話的なデバッグをサポートす る必がある。 OS に加えて、中間のプートプログラムや 斤プログラムなどでも、ファームウェアカ甘是供するサー ピスを利用している。 ファームウェアの問題点 オープンシステム環境ではユーザーが自由に I/O テンヾ イスをインストールできるので、 OS のロードは複雑な作 業になっている。 OS をロードする I / O デバイスがあら かじめすべて分かっているならは、ファームウェアに 106 Open Boot は、 OS が起動する前の状態のコンヒ。ュータを 制御するファームウェアの ( ソフトウェア ) アーキテクチャ である。 Open Boot ファームウェアは、計算機に依存しない 対話的プログラム言語 Forth をもとに言十されている。 Open B00t には、次のような特徴がある。起動のためのド ライバがあらかじめ組み込まれているデバイスの認識、ディ スクやテープ、ネットワークからの起動、ハードウェア構成 の報告、ハードウェアやソフトウェア、ファームウェアのた めのデバッグッールの提供である。 Open B00t は、 SBus に接続されているデバイスの認識や、 そのデバイスからの起動などの基本機能を提供する。 IEEE で は、 Open B00t をもとにした起動のためのファームウェアの 標準化作業か進められている。 Futurebus 十と VME-D バスの 標準には Open Boot が含まれている。 0 Mitch Bradley れらのためのデバイスドライバを組み込んでおけばよい。 しかし、新たなプートデバイスが追加された場合は、ファ ームウェアにそのデバイスのドライバを組み込まなくては ならない。また、新しいデバイスをすべて含む完全なファ ームウェアを実現しようとすれば、、、デバイス数 x システ ム数 " の組合を考える必要があり、実質的には不可能で ある。 ノ、一ドウェアの検査とプート中の状況を表示するデバイ スについても、同様なことがいえる。ファームウェアは、 これらを表示するために、それぞれの表示用デバイスのド ライノヾを備えなくてはならない。解決方法の 1 つは、す べての表示デバイスで、基本となるデバイスをエミュレー トすることである。この方法はたしかに動くには動くが、 ハードウェア・コストの増加を招き、新しい技術の導入の 妨げになる。 ー殳に、 1 つの、、 Generic" な OS か 1 司じファミリーを 形成するいくつかの計算機で動作す川ま、ハードウェアは 急速に進歩する。これは、異なる言 fr 機がソフトウェアか らまったく同一にみえるのならそれほど困難ではないが、 実際には OS からもまったく同しにみえるようにするの はきわめて難しい。しかし、あを御未でファームウェアは UNIX MAGAZINE 1992.8