JP2004070952A - システム記述補助テーブルを検索するマルチプラットフォーム用ファームウェア - Google Patents

Abstract

【課題】ＩＡ−６４命令セットプロセッサ用のＡＣＰＩファームウェアを提供すること。
【解決手段】ＩＡ−６４命令セットのファームウェア・インタフェース・テーブル（ＦＩＴ）は、ＳＳＤＴデータを用いたハードウェア・コンポーネント名前空間を格納することに使用される。ＳＳＤＴデータは、システム内のコンポーネントを記述する。ブートアップ時に、すべてのハードウェア・コンポーネントが分かる。システムファームウェアにおけるＡＣＰＩサブシステムは、データ設定を消費し、ＦＩＴからＳＳＤＴをロードし、アクティブシステムコンポーネントのために名前空間を作成する。ＳＳＤＴエントリを指し示す一つのＦＩＴタイプがあり、サブタイプは、ＦＩＴバージョンフィールドを使用して指し示される。
【選択図】図１

Description

　本発明は、ＩＡ−６４命令セットプロセッサ用のＡＣＰＩファームウェアに関する。

　本発明は同時に出願された、Ali Qureshi他に対する、「System And Method For Using A Firmware Interface Table To Dymamica11y Load An ACPI SSDT」という表題の米国特許出願第１０／２１２，７２１号に関連する。

　Ａｄｖａｎｃｅｄ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ａｎｄ　Ｐｏｗｅｒ　Ｉｎｔｅｒｆａｃｅ（ＡＣＰＩ）は、ハードウェアのステータス情報を、ラップトップ、デスクトップ、サーバーなどのコンピュータのオペレーティングシステムが利用できるようにするための仕様である。ＡＣＰＩについては、Compaq Computer Corporation、Intel Corporation、Microsoft Corporation、Phoenix Technologies Ltd.、Toshiba Corporationが共同で策定した５００ページの「Advanced Configuration and Power Interface Specification」，Revision 2.Oa, March 31, 2002にさらに詳細に記述されている。ＡＣＰＩ仕様は、オペレーティングシステム（ＯＳ）指向の堅牢なマザーボードデバイスの構成とデバイスおよびシステム全体の電源管理を可能にするための業界共通のインタフェースを確立するために開発された。ＡＣＰＩは、オペレーティングシステム指向の構成と電源管理（ＯＳＰＭ）の重要な要素である。

　ＡＣＰＩは、Microsoft（商標） Corporationから提供されるWindows（商標）、さまざまな製造元からオープンソースとして利用できるLinux、Hewlett-Packard Companyから提供されるHP/UXなどの様々なオペレーティングシステムを実行するパーソナルコンピュータ（ＰＣ）で使用される。ＡＣＰＩにより、ハードウェアリソースを取り扱うことも可能になる。たとえば、ＡＣＰＩは、コンピュータシステムの周辺機器の電源をオンおよびオフにすることができるようにし、それにより電源管理を改善することで、電源管理を支援する。また、ＡＣＰＩは、外部機器によりコンピュータシステムをオンにしたりオフにしたりすることができるようにする。たとえば、マウスに触れたり、キーを押すことでＡＣＰＩを使用してコンピュータシステムのスリープ状態を解除することができる。

　従来、ＡＣＰＩは様々な理由で使用するのが困難であった。第１に、ＡＣＰＩが記述される言語は、どのコンピュータシステムのプラットフォームにも固有のアセンブリ言語ではない。その代わりＡＣＰＩは、独自のソース言語と機械語、つまり、それぞれＡＣＰＩソース言語（ＡＳＬ）とＡＣＰＩ機械語（ＡＭＬ）で記述されている。ＡＳＬはこのように使用方法が非常に特殊なために、ＡＳＬをプログラムできる者は比較的少数である。さらに、ＡＳＬは、用途が限定されているため、コンストラクト（construct）が比較的少ない。そのうえ、ＡＣＰＩコードは、従来から融通がきかない構造を持つ。その結果、ＡＣＰＩコードを他のプラットフォームや、同一のプラットフォームの別の構成にさえ移行するのが困難である。そのため、新規に設計されたプラットフォームで動作するようにするには、新規のＡＳＬコードを書くことが必要になる。ＡＳＬプログラマの数が限られていることで、新しいコードを書くことは、いよいよ困難で費用がかかることになる。

　ＡＣＰＩは、静的なテーブルと、インタープリタにより実行可能なテーブルの両方からなる。ブートアップ時、システムファームウェア（典型的にはＢＩＯＳ、つまり基本入出力システム）は静的テーブルを作成し、オペレーティングシステムがそのテーブルを使用する。インタープリタ実行可能テーブルはＡＭＬで作成され、コンパイルされてからシステムファームウェアにマージされる。オペレーティングシステムはＡＭＬをインタープリタ実行可能テーブルから読み取り、構築されたインタフェースを、ＡＣＰＩインタプリタを使用して実行する。このようにして、オペレーティングシステムはハードウェアリソースを取り扱う。インタープリタ実行可能テーブルはシステムファームウェアにマージされるので、この従来の方法は、柔軟性と拡張性に欠け、プログラムし直してさまざまなシステム構成に対応するのに相当な時間が必要になる。

　たとえば、従来から、ＡＳＬの開発者はＡＣＰＩコードを書くことでプラットフォームやその派生プラットフォームの特定の構成を指定している。しかし残念ながら、ハードウェアがわずかでも変更されると、コードの設計を修正しなければならない。その場合、新規のＡＭＬコードを書いて、新規のテーブルをシステムファームウェアにマージしなければならない。したがって、従来の設計は移植性や再利用性がなかった。

　そのうえ、ＡＣＰＩは、従来からプラットフォームに派生がある場合や、相互に排他的なＡＣＰＩ要件を持つ複数のＡＣＰＩ対応のＯＳシステムをサポートする場合には、異なるシステムファームウェアＲＯＭ（読み取り専用メモリ）やＢＩＯＳを使用する必要があった。同一のシステムが複数のオペレーティングシステムをサポートする場合にも、異なるシステムファームウェアＲＯＭを使用しなければならなかった。たとえば、パーソナルコンピュータの現在の技術では、ＩＡ−３２命令セットを使用している。ＡＣＰＩは当初Microsoft（商標）ファミリーのオペレーティングシステム、特にＩＡ−３２命令セットを持つシステムで使用されていた。

　ＡＣＰＩは、さまざまなオペレーティングシステムで標準のインタフェースとして受け入れられてきた。新しい命令セットアーキテクチャであるＩＡ−６４が開発中であるが、従来のＡＣＰＩコードや方法ではその利点を十分に利用することはできない。Intel（商標） Corporationから提供される新しいItanium（商標）プロセッサファミリーは、ＩＡ−６４命令セットを使用する。現在の手法を使用する場合、このファミリーのプロセッサを元にした新規の各プラットフォームやシステム構成のためのＡＳＬは、独自に書き直す必要がある。

　ＡＣＰＩ名前空間は、名前の付けられたオブジェクトを含むＯＳ制御メモリ内の階層ツリー構造である。これらのオブジェクトはデータオブジェクト、制御方法オブジェクト、バス／デバイスパッケージオブジェクトなどである。ＯＳはＡＣＰＩ　ＢＩＯＳ内に存在するＡＣＰＩテーブルの定義ブロックをロードおよび／またはロード解除することで実行時に名前空間の内容を動的に変更する。ＡＣＰＩ名前空間内のすべての情報は、差分定義ブロックを含む差分システム記述子テーブル（ＤＳＤＴ）と、１つ以上のその他の定義ブロックから得られる。現在の技術では、ＯＥＭ（相手先商標製品製造業者）は、基本システムについての実装と構成の情報を提供するＤＳＤＴをＡＣＰＩ準拠ＯＳに対して提供しなければならない。ＯＳは常にシステムブート時にＤＳＤＴ情報をＡＣＰＩ名前空間内に挿入し、それを除去することは決してない。

　別のＡＣＰＩコンストラクトは、システム記述補助テーブル（ＳＳＤＴ）である。ＳＳＤＴは、ＤＳＤＴの延長部分である。複数のＳＳＤＴをプラットフォーム記述の一部として使用することができる。ＤＳＤＴがＡＣＰＩ名前空間にロードされた後、一意のＯＥＭテーブルＩＤを持つ各システム記述補助テーブルがロードされる。これにより、ＯＥＭは基本的な支援を１つのテーブルで提供し、他のテーブルでより小規模のシステムオプションを追加することができる。追加されたテーブルは、データを追加することだけが可能で、それ以前のテーブルのデータを上書きすることはできない。

　システム抽象層（ＳＡＬ）によって定義されるＡＣＰＩアーキテクチャ内のコンストラクトはファームウェア・インタフェース・テーブル（ＦＩＴ）である。これはＩＡ−６４命令セットコンストラクトである。ＦＩＴには保護されたブートブロック外にあるファームウェアコンポーネントの開始アドレスとサイズが含まれる。ＦＩＴエントリの仕様の適切な概要は、http://WWW.inte1.com/design/itanium/down1oads/24535905.pdfから取得可能な“ITANIUM（商標） Processor Family System Abstraction Layer Specification”, document No. 245359-005, (Intel July 2002)に記述されている。
米国特許出願第１０／２１２，７２１号

　本発明の目的は、ＩＡ−６４命令セットプロセッサ用のＡＣＰＩファームウェアを提供することである。

　ＩＡ−６４命令セットのファームウェア・インタフェース・テーブル（ＦＩＴ）は、差分システム記述子テーブル（ＤＳＤＴ）データとシステム記述補助テーブル（ＳＳＤＴ）データを使用してハードウェアコンポーネント名前空間の内容を作成する（populate）ことであり、ＤＳＤＴデータとＳＳＤＴデータはシステム内のコンポーネントを記述する。ブートアップ時にすべてのハードウェアコンポーネントが検出される。システムファームウェア内のＡＣＰＩ（Advanced Condiguration and Power Interface）サブシステムは、データ設定を使用してＦＩＴからＳＳＤＴをロードしてアクティブなシステムコンポーネントのための名前空間を作成する。

　ファームウェア・インタフェース・テーブル（ＦＩＴ）には、アドレスフィールド、サイズフィールド、タイプフィールドを有するエントリが含まれる。ＦＩＴエントリのアドレスフィールドは、そのエントリのタイプについてのデータに対応する記憶域を指す。ＦＩＴ内の少なくとも１つのＦＩＴエントリは、ＳＳＤＴを識別する。ＳＳＤＴは、一意のＦＩＴタイプとサブタイプにより識別され、サブタイプはＦＩＴバージョンフィールドを使用して表される。ＳＳＤＴを指定するＦＩＴエントリは、ブートアップ時中に検索され、ＤＳＤＴと共にアクティブなシステムコンポーネントの名前空間を記述する。

　詳細な説明においては、以下の図を参照するが、同一の数字は同一の要素を示す。

　ＡＣＰＩはＩＡ−３２命令セットの概念であり、新しいＩＡ−６４命令セットでも引き続き使用されている。ＡＣＰＩは、ハードウェアの取り扱いと構成データを抽象化してオペレーティングシステム（ＯＳ）とファームウェアとのやりとりのためにハードウェア構成を定義する方法である。ＡＣＰＩは、業界標準の仕様である。現在、主要な３つの商用パーソナルコンピュータ（ＰＣ）オペレーティングシステム、つまり、Linux、HP/UX、Windows（商標）は、ＩＡ−３２空間でＡＣＰＩを使用していて、新しいＩＡ−６４空間でもＡＣＰＩを使用して実行されることになる。システムブート時、ファームウェアに電源が投入され、ファームウェアがシステム構成を確定する。システムは、必要な場合初期化されてから、動作がＯＳに渡される、つまりＯＳがブートアップされる。システムがブートアップされるときに、システムは様々なプラットフォーム構成の知識を持っていなければならない。ＡＣＰＩは、さまざまなプラットフォーム構成を定義するためにインタフェースオブジェクトと名前空間を有するハードウェア構成の仕様である。

　新しいプラットフォーム用のＡＣＰＩコードの作成は、より構造化されかつプラットフォームに依存しないようにすることが望ましい。これは、ＡＣＰＩコードに対してモジュラー設計による構築化されたアプローチを使用して達成することができる。この方法によるＡＣＰＩ設計は現在使用されておらず、事実、開発者から難色を示されている。

　従来のＡＣＰＩ設計についての別の問題は、ＡＣＰＩ開発者はＡＳＬを使用してあらゆる所定のプラットフォームの派生を完全に記述しなければならないことである。このような設計では、ブートアップ時にハードウェアコンポーネントが存在しない場合も含め、ハードウェアがわずかに変更された場合でさえ移植性や再利用性がなかった。さらに、所定のプラットフォームのタイプから派生したタイプや、同一のシステムが複数のオペレーティングシステムを支援している場合に同一のＲＯＭを使用することができなかった。

　名前空間は、コンピュータシステムの階層を論理的な方法で記述する。たとえばＯＳが名前空間を使用するとき、ＯＳは下位のハードウェアの状態を取得する。したがって、ＯＳがある所定のハードウェアのためのリソースを取得することが必要な場合、あるいはコンポーネントにアクセスする方法を知る必要がある場合、ＯＳは名前空間を調べる。たとえば、ＯＳがマシンをスリープ状態にする必要がある場合、デバイスをスリープ状態にする方法を特定するオブジェクトが存在する。ＯＳは名前空間で定義されたインタフェースまたはオブジェクトを使用してハードウェアを取り扱う。これがＡＣＰＩの機能である。

　本システムと本方法の利点は、様々なプラットフォームとそれらのプラットフォームの複数の構成が共通のまたは汎用にプログラムされたファームウェアを使用して動作できるようにしていることである。現在のファームウェアが現状では克服していない問題は、ファームウェアが１つのプラットフォームの１つの構成でしか使用できないことである。本システムと本方法によれば、３つの主要なＯＳすべてで同時に動作するシステムファームウェアが可能になる。そのため、構成やＯＳが変更されるたびにファームウェアをアップグレードしたり修正する必要がない。そのためには、ＯＳは、特に、ブート時にプラットフォーム上でどのオペレーティングシステムが実行中なのかについて知る必要がある。

　ＩＡ−６４命令セットは、システムファームウェアがシステムハードウェアのＲＯＭコンポーネントにどのように配置されるのかを記述する。システムでは、ＡＣＰＩ　ＡＭＬテーブル、ＡＣＰＩ静的テーブル、純粋なファームウェアであるＳＡＬ（システム抽象化層）など様々なファームウェアコンポーネントがマージされる。ファームウェア・インタフェース・テーブル（ＦＩＴ）はファームウェア内に存在し、必要なＡＣＰＩテーブルと他の情報がメモリのどこに存在するかを記述する。ＦＩＴは、特定の数のフィールドを有し、各フィールドにはタイプがある。フィールドタイプは、コンポーネントのタイプを特定する。そのため、コンポーネントのタイプは、構造化されている。たとえば、タイプ０ｘＥ（Ｅは１６進値）は、ＰＡＬ（プロセッサ抽象化層）を具体的に示すことにすることができる。製造元ＯＥＭ（相手先商標製品）フィールドであるタイプの範囲も存在する。

　図面を参照すると、図１は特にＩＡ−６４命令セットに関連付けられたファームウェア用のシステムＲＯＭ　１００の例を示している。ＲＯＭ　１００は、ＳＡＬ　１０１、ＰＡＬ　１０３、ＳＳＤＴ領域１０５、ＡＣＰＩテーブル１０７、ＦＩＴ　１０９などのいくつかのコンポーネント領域を有する。ＦＩＴは、たとえばアドレス１１１、サイズ１１３、チェックサム１１５、タイプ１１７、バージョン１１９など多くのフィールドを有する。この例では、ＦＩＴアドレス１１１は、ＳＡＬ　１０１の先頭を指す。サイズ１１３は、必要な場合に正しいバイト数が検索できるようにＳＡＬ領域の長さを示す。ＲＯＭ内のデータの完全性を保証するためにチェックサム１１５が存在することもある。

　ＡＣＰＩテーブル１０７は、指定テーブルにより静的か動的（つまりインタープリタにより実行可能）であるかのいずれかである。システムの名前空間を作成するために、ＤＳＤＴ（差分システム記述子テーブル）がＦＩＴに保存されている。ＩＡ−６４ではＤＳＤＴが存在していることが必要である。ＤＳＤＴは、実行可能なＡＭＬの部分を定義する。ＤＳＤＴはルートシステムのハードウェアコンポーネントを定義する。ＡＣＰＩは、ＳＳＤＴ（システム記述補助テーブル）１０５を持つことも可能である。ＡＣＰＩインタープリタが実行されるとき、インタープリタはＤＳＤＴとすべてのＳＳＤＴを検索して結合された名前空間を作成する。

　システム内に存在するコンポーネントタイプの構成ごとに個別のＳＳＤＴエントリが作成される。たとえば、システムがローカルバスアダプタについて２つの派生を持つことが可能な場合、２つのＳＳＤＴが生成され、それらのローカルバスアダプタコンポーネントを定義するが、その場合、たとえばＳＳＤＴはプラットフォーム構成の派生ごとにそれぞれ定義される。各ＳＳＤＴには各自のタイプ１１７がある。たとえば、タイプ５５から８０は、様々なＳＳＤＴタイプに専用に使用されるようにしてもよい。この方法は、構成の派生がほとんどない単一プラットフォームには適している。しかし、システムに多くの構成と使用可能なオペレーティングシステムがある場合、ＳＳＤＴタイプの範囲が許容される範囲を超えることがある。そのため、ＦＩＴエントリ内で、１つのタイプをＳＳＤＴを表すのに使用して、別のフィールドを使用してコンポーネントタイプと特定の構成を示すことが望ましい。バージョンフィールド１１９はこのタイプのＦＩＴエントリには使用されていないため、他のＦＩＴ操作に悪影響をまったく与えることなく有利に使用できる。ファームウェアの仕様を守り、ファームウェアがＦＩＴエントリをデコードできる限り、その他の使用されないフィールドが使用可能であることや、フィールドをその他の用途に割り当て直さなければならないことは同業者には明らかであろう。

　図２にＤＳＤＴ名前空間２００の例を示す。システムボード内のルートシステムバス（ＳＢ）は＿ＳＢ　２０１で、システムバスアダプタ（ＳＢＡ）＿ＳＢＡ０　２０３を持つ。ＳＢＡ　＿ＳＢＡ０は、ＰＣＩ (Peripheral Component Interconnect/Interface)コンポーネント、ＰＣＩ−１　２０５を有する。＿ＳＢＡ０とＰＣＩ−１とは、それらに関連付けられた＿ＣＲＳ　２０９と＿ＣＲＳ　２０７をそれぞれ有する。ＤＳＤＴはシステム全体を記述しなくてもよい。たとえば、ＤＳＤＴは、正常にブートされたときに動作することが必要なコンピュータシステムの一部を記述してもよい。図３はＳＳＤＴの例を示していて、このＳＳＤＴはブート時にＤＳＤＴと結合され、システム全体を記述する。

　図３では、ＳＳＤＴ　３００はルート＿ＳＢ．＿ＳＢＡ０　３０１を有する。この名前は、この名前空間内で下位の子は、ＤＳＤＴ　２００のルート＿ＳＢ　２０１の子＿ＳＢＡ０　２０３に関連付けられることを示している。＿ＳＢ．＿ＳＢＡ０という表記は、オブジェクト指向の性質を持つ。子ノードは一般的に親のコンポーネントである。コンポーネント＿ＳＢ．＿ＳＢＡ０　３０１はＰＣＩコンポーネント、ＰＣＩ−５　３０３を有し、ＰＣＩ−５　３０３は、自身に関連付けられた状態＿ＳＴＡ　３０５を有する。システムのブート時、ＤＳＤＴとＳＳＤＴは組み合わされて図４に示すようにシステム名前空間４００が作成される。

　次に図４を参照すると、システムバス＿ＳＢ　４０１の組み合わされた名前空間４００が示されている。システムバスは、ＤＳＤＴ　２００とＳＳＤＴ　３００の名前空間で定義されたように、自身に関連付けられた子を有するＰＣＩコンポーネントＰＣＩ−１　２０５とＰＣＩ−５　３０３を有するようになった子ＳＢＡ＿ＳＢＡ０　４０３を有する。

　完全な名前空間を動的に構築する利点は、異なる構成に同一の基本ファームウェアで対応できることである。構成の差分は、１つまたは複数のＳＳＤＴ領域で定義することができる。図１をもう一度参照すると、ＦＩＴ　１０９のＳＳＤＴエントリは、そのタイプ１１７とバージョン１１９により識別される。ＦＩＴ　１０９は、１つまたは複数のＳＳＤＴ１０５を指し、ブート時に読み込まれる。ＳＳＤＴのアドレスは、システム内のＲＯＭやその他の任意のメモリ領域を指すことができることは、当業者には明らかであろう。

　動的名前空間の別の利点は、ブートアップ中に何らかのコンポーネントに障害が発生する場合に対応できることである。首尾よいブートのために、システムのすべてのデバイスが存在したり動作状態にある必要はない。従来技術のシステムでは、ブート中にデバイスに障害が発生するときに、ブート全体が失敗することが多かった。Windows（商標）では、この失敗は、いわゆる「青い画面」つまりシステム障害という結果を引き起こし得る。動的ＳＳＤＴを使用してオプションのデバイスを定義する場合、システムはこれらのオプションのデバイスが存在していてブート時に機能するかどうかを確定することができる。デバイスが存在しなかったり機能しないときには、デバイスは名前空間にロードされない。そのため、ＯＳはブート時にそれらのデバイスを検索することはない。

　図５Ａと図５Ｂは、システム−１とシステム−２のハードウェア構成の例を示しており、両方のシステムは本方法を利用する同一のファームウェアを使用できる。図５Ａを参照すると、２つのローカルバスアダプタ（ＬＢＡ）、ＬＢＡ１　５０３とＬＢＡ２　５０５、を有するシステムバスアダプタ（ＳＢＡ）５０１が示されている。ＬＢＡ１は４つのスロット、Ｓ１、Ｓ２、Ｓ３、Ｓ４（５０７、５０９、５１１、５１３）を有する。ＬＢＡ２はスロットＳ１　５１５を１つだけ有する。図５Ｂを参照すると、３つのＬＢＡ、ＬＢＡ１、ＬＢＡ２、ＬＢＡ４（５２３、５２５、５２７）を有するＳＢＡ　５２１が示されている。ＬＢＡ１は２つのスロット、Ｓ１とＳ２（５２９と５３１）を有し、ＬＢＡ２は１つのスロットＳ１　５３３を有し、ＬＢＡ４は３つのスロット、Ｓ１　５３５、Ｓ２　５３７、Ｓ３　５３９を有する。

　これらのシステムの名前空間を表すのに使用される簡略化したＤＳＤＴは図６Ａのようになる。システム−１の残りのコンポーネントを記述するのに使用されるＳＳＤＴは図６Ｂのようになる。システム−２の残りのコンポーネントを記述するのに使用されるＳＳＤＴは図６Ｃのようになる。両方のシステムが、２つのローカルバスアダプタを備えるＳＢＡを有し、第１のＬＢＡは少なくとも２つのスロットを有し、第２のＬＢＡは１つのスロットを有することが当業者には明らかであろう。この例では、この構成が基本システムのため、ＤＳＤＴは３つのコンポーネントを定義するだけでよい。他のすべてのコンポーネントはＳＳＤＴで記述される。

　たとえば、システム−１については、ＬＢＡ１の２つの追加スロットは基本構成に追加して定義されなければならない。システム−２については、追加のＬＢＡであるＬＢＡ４は３つのスロットＳ１、Ｓ２、Ｓ３を有するように定義されなければならない。したがって、同一のファームウェアについて、ロードされるＳＳＤＴだけを変更すれば、システム−１とシステム−２に対応できる。

　多くの構成を持つ多くのプラットフォームで使用するためにファームウェアとそれに関連するＡＳＬが開発される場合、多くのコンポーネント構成が可能なことは明らかであろう。３つのスロットを各々が持つ４つのＬＢＡを有するプラットフォームもあれば、１つから４つのＰＣＩスロットを各々が持つ５つのＬＢＡを有するプラットフォームもある。したがって、バージョンフィールドは、個々の構成を区別するのに使用される。ＦＩＴについて１つのＳＳＤＴタイプが定義され、ＤＳＤＴを複数のＳＳＤＴと組み合わせるときに、エントリのバージョンが構成を区別するのに使用される。たとえば、バージョンフィールドが１６ビット長とする。例示的な一実施形態では、１６ビットが８ビットごとの２つのバイトに分割される。一方の１バイト［８ビット］はアダプタを特定し、他方の１バイトはアダプタのスロット数を特定する。表１は、４つのスロットを持つＬＢＡ　１について、現在の構成を示すためにバージョンフィールドがどのように設定され得るかを示している。テーブルは２進表記を使用している。したがって、コンポーネント番号は２進表記で０００００００１になり、スロット数は０００００１００になる。他のビット割り当て方法も使用できることは当業者にとっては明らかであろう。たとえば、より多くのスロットが必要な場合、コンポーネント番号に３ビットを使用して、スロット数を確定するのに５ビットを使用することができる。

　図７は、ＤＳＤＴと少なくとも１つのＳＳＤＴ用のＦＩＴエントリを使用してシステムコンポーネント名前空間を生成する例示的な一方法を示す流れ図である。ステップ７０１で、システムコンポーネントが識別され、それらのシステムコンポーネントに対応する情報または定義が１つまたは複数のＳＳＤＴ領域に保存される。この情報は、システムファームウェアからアクセス可能なＲＯＭや任意のその他のメモリに保存することができる。ステップ７０３でシステムブートアップ中に、正常にブートアップされたコンポーネントが識別される。ここでは説明の便宜上、これらのコンポーネントは「アクティブな」コンポーネントとして認識されているとする。すべてのロード可能なＳＳＤＴがＲＯＭにロードされ、ＦＩＴにより記述される。ステップ７０５で、ＳＡＬによるＡＣＰＩ静的テーブルの生成時に、ＳＡＬはアクティブなコンポーネントに対してどのＳＳＤＴがロードされるかを決定し、その情報をＡＣＰＩ静的テーブルに配置する。

　システムコンポーネント情報が検索されシステム名前空間が生成されるときに、アクティブではないコンポーネントや障害のあるコンポーネントは記述されない。これにより、１つまたは複数の不可欠ではないコンポーネントがない場合でもシステムがブートアップ可能になる。また、ステップ７０７で、システムのブートアップ中に、ＡＣＰＩインタープリタは、静的テーブルと動的テーブル（ＤＳＤＴとＳＳＤＴ）を組み合わせることで、静的テーブルと動的テーブルを使用して有効なＡＣＰＩ名前空間を作成する。ステップ７０９で、ＡＣＰＩインタープリタにより名前空間が完全に生成されると、制御はＯＳに移行し、システムが起動し動作する。それから、ＯＳは生成された名前空間を使用してシステムコンポーネントとのやりとりを行う。

　ファームウェア・インタフェース・テーブルを使用してＡＣＰＩ　ＳＳＤＴをロードするための新規の方法の好ましい実施形態について説明したが（説明は限定することを意図したものではなく例示することを意図している）、当業者は、前述の教示をふまえて変更や変形が可能であることに留意しなければならない。したがって、併記の特許請求の範囲によって定義されるように本発明の範囲と精神内で、開示した本発明の特定の実施形態に対して変更が可能なことは明らかである。

ファームウェア・インタフェース・テーブルを有する例示的なファームウェアＲＯＭを示すブロック図。 ＤＳＤＴの例示的な名前空間を示す図。 ＳＳＤＴの例示的な名前空間を示す図。 図２のＤＳＤＴと図３のＳＳＤＴのコンポーネントを組み合わせた名前空間を示す図。 システムバスアダプタ、少なくとも１つのローカルバスアダプタ、対応するスロットを有する例示的なシステムのブロックダイヤグラム。 システムバスアダプタ、少なくとも１つのローカルバスアダプタ、対応するスロットを有する例示的なシステムのブロックダイヤグラム。 図５Ａと図５Ｂに共通に示されるハードウェアコンポーネントに対応する例示的なＤＳＤＴ名前空間。 図５Ａに示され図６ＡのＤＳＤＴ名前空間には含まれないハードウェアコンポーネントに対応する例示的なＳＳＤＴ名前空間。 図５Ｂに示され図６ＡのＤＳＤＴ名前空間には含まれないハードウェアコンポーネントに対応する例示的なＳＳＤＴ名前空間を示す図。 ＤＳＤＴと少なくとも１つのＳＳＤＴ用のＦＩＴエントリを使用してシステムコンポーネント名前空間を生成する例示的な方法を示す流れ図。

Claims (10)

1. 　ＩＡ−６４命令セットプロセッサ用のマルチプラットフォームのマルチオペレーティングシステム用ファームウェアであって、
   　コンピュータシステムをブートアップするシステムファームウェアであって、該システムファームウェアは、ブートアップ命令がプログラムされている第１の命令ブロックと、データを保存するための第２のメモリブロックとを有し、
   　前記第２のメモリブロックは、システムブートアップ中にアクセス可能であって、前記コンピュータシステムのコンポーネントに対応した情報を格納しており、
   　前記第２のメモリブロック内に設けられたファームウェア・インタフェース・テーブルであって、アドレスフィールド、サイズフィールド、およびタイプフィールドのエントリを含み、ファームウェア・インタフェース・テーブルのエントリの前記アドレスフィールドのエントリが該エントリのタイプについてのデータに対応する記憶域を指すファームウェア・インタフェース・テーブルと、
   　システム記述補助テーブルを識別する前記ファームウェア・インタフェース・テーブル内の少なくとも１つのファームウェア・インタフェース・テーブルのエントリであって、前記システム記述補助テーブルは少なくとも１つの前記コンピュータシステムのコンポーネントを記述する情報を備え、前記システム記述補助テーブルは一意のファームウェア・インタフェース・テーブルのタイプおよびファームウェア・インタフェース・テーブルのバージョンフィールドを使用したサブタイプにより識別され、前記ファームウェア・インタフェース・テーブルのエントリはアクティブなシステムコンポーネントの名前空間を記述するためにブートアップ中に検索される、少なくとも１つのファームウェア・インタフェース・テーブルのエントリと、
   を備えるファームウェア。
2. 　前記ファームウェア・インタフェース・テーブルのエントリはチェックサムおよびバージョンの情報をさらに含む請求項１に記載のファームウェア。
3. 　前記システム記述補助テーブルの情報は差分システム記述子テーブルの情報と組み合わされ、前記差分システム記述子テーブルの情報は前記第２のメモリブロック内に存在する請求項１に記載のファームウェア。
4. 　前記システム記述補助テーブルの情報は、第３のメモリブロック内に存在し、該第３のメモリブロックは前記ファームウェア外に存在する請求項３に記載のファームウェア。
5. 　前記システム記述補助テーブルの情報は差分システム記述子テーブルの情報と組み合わされ、前記差分システム記述子テーブルの情報および前記システム記述補助テーブルの情報は第３のメモリブロック内に存在し、該第３のメモリブロックは前記ファームウェア外に存在する請求項１に記載のファームウェア。
6. 　システムブートアップ中にシステム記述補助テーブルのデータをファームウェア・インタフェース・テーブルから検索してアクティブなシステムコンポーネントの名前空間を生成する方法であって、
   　各システムコンポーネントについて、対応するシステムコンポーネント情報を、前記システム記述補助テーブルを保存する記憶域に保存するステップと、
   　システムブートアップ時に、コンピュータシステムにおけるアクティブなコンポーネントのシステム構成を決定するステップと、
   　システム記述補助テーブルのエントリを有するファームウェア・インタフェース・テーブルをロードするステップであって、各システム記述補助テーブルは、対応する前記システム記述補助テーブルの情報を保存する記憶域を指し、ロードされる前記エントリはシステムコンポーネントに対応し、ファームウェア・インタフェース・テーブルのエントリはタイプフィールドによりシステム記述補助テーブルのエントリとして識別され、前記システム記述補助テーブルのエントリはファームウェア・インタフェース・テーブルのエントリのバージョンフィールドで識別されるサブタイプを有し、
   　決定された前記システム構成を持つ前記システムコンポーネントの名前空間をアクティブなシステムコンポーネントについて初期化するステップと、
   を含む方法。
7. 　制御を前記システムファームウェアから選択されたオペレーティングシステムに移行するステップをさらに含み、前記オペレーティングシステムは、前記システムコンポーネントの名前空間を使用してシステムコンポーネントとの対話を定義する請求項６に記載の方法。
8. 　前記ファームウェア・インタフェース・テーブルは第１のメモリブロック内に存在し、前記ファームウェア・インタフェース・テーブルはアドレス、サイズ、およびタイプを有するエントリを含み、ファームウェア・インタフェース・テーブルのエントリの前記アドレスは前記エントリのタイプについてのデータに対応する記憶域を指す請求項６に記載の方法。
9. 　ファームウェア・インタフェース・テーブルのエントリは、前記第１のメモリブロック外の記憶域を指す請求項８に記載の方法。
10. 　前記システムコンポーネントの名前空間をアクティブなシステムコンポーネントについて初期化するステップは、システム記述補助テーブルの情報を差分システム記述子テーブルの情報と組み合わせるステップをさらに含む請求項６に記載の方法。
    

Images