(57)【要約】【課題】　ファームウェアインタフェーステーブルを用いてＡＣＰＩのＳＳＤＴを動的にロードするシステムおよび方法を提供する。【解決手段】　システムブート時に１つまたは２つ以上の２次システム記述テーブル（ＳＳＤＴ）を、ＩＡ−６４命令セットのファームウェアインタフェーステーブル（ＦＩＴ）にロードすることができように、ＦＩＴデータタイプは、それぞれのＳＳＤＴタイプに対して定義される。差別化システム記述テーブル（ＤＳＤＴ）データも、ＦＩＴに配置され、１つまたは２つ以上のＳＳＤＴと結合されて、システムのすべてのアクティブなコンポーネントについての結合された名前空間が作成される。【選択図】図５
2004070945.tif 000002
【特許請求の範囲】
【請求項１】
　ＩＡ−６４命令セットプロセッサ用のマルチプラットフォーム・マルチオペレーティングシステムのファームウェアであって、
　コンピュータシステムをブートアップするシステムファームウェアであって、ブートアップ命令によりコード化される第１の記憶ブロックを有し、かつデータ（１００）を記憶する第２の記憶ブロックを有する、システムファームウェアと、
　システムのブートアップ中にアクセス可能であり、前記コンピュータシステムのコンポーネント（５０１、５０３、…、５１５）に対応する情報で占められる前記第２の記憶ブロックと、
　前記第２の記憶ブロックに存在するファームウェアインタフェーステーブル（firmware interface table）（ＦＩＴ）であって、該ＦＩＴは、（１０９）アドレス（１１１）、サイズ（１１３）、およびタイプ（１１７）を有するエントリを含み、かつＦＩＴエントリのそれぞれのアドレス（１１１）が、前記エントリのタイプのデータに対応するそれぞれの記憶域を指し示す、ＦＩＴと、
　２次システム記述テーブル（secondary system description table）（ＳＳＤＴ）（１０５、３００）を特定する少なくとも１つのＦＩＴエントリ（１０９）であって、前記ＳＳＤＴは、少なくとも１つのシステムコンポーネント（５０１，５０３、…、５１５）を記述する情報を含み、前記ＦＩＴ（１０９）において特定されるそれぞれのＳＳＤＴは、ブートアップ中に検索され、アクティブなシステムコンポーネントの名前空間（４００）を記述する、少なくとも１つのＦＩＴエントリと
　を備えるファームウェア。
【請求項２】
　前記ＦＩＴエントリは、チェックサム情報（１１５）およびバージョン情報（１１９）をさらに含む
　請求項１に記載のファームウェア。
【請求項３】
　前記ＳＳＤＴ情報（３００）は、差別化システム記述子テーブル（differentiated system descriptor table）（ＤＳＤＴ）（２００）からの情報と結合され、前記ＤＳＤＴ情報は、前記第２の記憶ブロックのメモリーに存在する
　請求項１に記載のファームウェア。
【請求項４】
　前記ＳＳＤＴ情報（３００）は、第３の記憶ブロックに存在し、該第３の記憶ブロックは、前記ファームウェアの外部に存在する
　請求項３に記載のファームウェア。
【請求項５】
　前記ＳＳＤＴ情報（３００）は、差別化システム記述テーブル（differentiated system descriptor table）（ＤＳＤＴ）（２００）からの情報と結合され、前記ＤＳＤＴ情報および前記ＳＳＤＴ情報は、第３の記憶ブロックに存在し、該第３の記憶ブロックは、前記ファームウェアの外部に存在する
　請求項１に記載のファームウェア。
【請求項６】
　システムのブートアップ中にＦＩＴ（１０９）からＳＳＤＴデータ（１０５、３００）を検索し、アクティブなシステムコンポーネント（５０１、５０３、…、５１５）の名前空間（４００）を生成する方法であって、
　コンピュータシステムのそれぞれのシステムコンポーネントについて、それぞれのシステムコンポーネントの情報を、２次システム記述テーブル（ＳＳＤＴ）用のそれぞれの記憶域に、システムのブートアップ前に記憶すること（７０１）と、
　前記コンピュータシステムのアクティブなシステムコンポーネントのシステム構成を、システムのブートアップ時に決定すること（７０３）と、
　それぞれが対応するＳＳＤＴ情報を記憶するそれぞれの記憶域を指し示す、ファームウェアインタフェーステーブル（ＦＩＴ）にＳＳＤＴエントリをロードすること（７０５）であって、ロードされる前記エントリはそれぞれのシステムコンポーネントに対応する、ロードすることと、
　前記システムコンポーネントの名前空間を、前記アクティブなシステムコンポーネントの決定されたシステム構成により初期化すること（７０７）と
　を含む方法。
【請求項７】
　前記システムファームウェアから、選択されたオペレーティングシステムに制御を渡すこと（７０９）をさらに備え、前記オペレーティングシステムは、前記システムコンポーネントの名前空間を消費して（consume）、システムコンポーネントの対話を定義する
　請求項６に記載の方法。
【請求項８】
　前記ファームウェアインタフェーステーブル（ＦＩＴ）は、第１の記憶ブロックに存在し、前記ＦＩＴは、アドレス（１１１）、サイズ（１１３）、およびタイプ（１１７）を有するエントリを備え、ＦＩＴエントリの前記アドレスは、該エントリのタイプのデータに対応する記憶域を指し示す
　請求項６に記載の方法。
【請求項９】
　ＦＩＴエントリは、前記第１の記憶ブロックの外部の記憶域を指し示す
　請求項８に記載の方法。
【請求項１０】
　前記システムコンポーネントの名前空間（４００）を初期化することは、ＳＳＤＴ情報（３００）を、差別化システム記述テーブル（differentiated system descriptor table）（ＤＳＤＴ）（２００）からの情報と結合することをさらに備える
　請求項６に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、ＩＡ−６４命令セットプロセッサ用のファームウェアに関する。
【０００２】
（関連出願の相互参照）
　この出願は、Shiraz Ali Qureshi等によって同時に出願された「System And Method For Using A Firmware Interface Table To Dynamically Load Multiple ACPI SSDT Tables」という発明の名称の米国特許出願第１０／２１２，７１９号に関連する。
【背景技術】
【０００３】
　電力制御インタフェース（ＡＣＰＩ）（Advanced Configuration and Power Interface）は、ラップトップ、デスクトップ、サーバ等を含むコンピュータのオペレーティングシステムに利用可能なハードウェア状態情報を作成する仕様である。
　ＡＣＰＩに関するより多くの情報は、Compaq Computer Corporation、Intel Corporation、Microsoft Corporation、Phoenix Technologies Ltd.、およびToshiba Corporationによって共同で規定された５００ページにわたる非特許文献１に見出すことができる。
【０００４】
　ＡＣＰＩ仕様は、強固なオペレーティングシステム（ＯＳ）向けマザーボードのデバイス構成ならびにデバイスおよびシステム全体の双方の電力管理を可能にする業界共通インタフェースを確立するために開発された。
　ＡＣＰＩは、オペレーティングシステム向け構成および電力管理（ＯＳＰＭ（operating system-directed configuration and power management））の重要な要素である。
【０００５】
　ＡＣＰＩは、Ｍｉｃｒｏｓｏｆｔ（登録商標）Corporationから市販されているＷｉｎｄｏｗｓ（登録商標）、さまざまなベンダからオープンソースとして市販されているＬｉｎｕｘ、およびHewlett-Packard Companyから市販されているＨＰ−ＵＸといったさまざまなオペレーティングシステムを実行するパーソナルコンピュータ（ＰＣ）において使用される。
　また、ＡＣＰＩは、ハードウェア資源の操作をも可能にする。
【０００６】
　例えば、ＡＣＰＩは、コンピュータシステムの周辺機器の電源投入および電源切断を可能にすることにより電力管理を援助し、電力管理を改善する。
　また、ＡＣＰＩは、外部デバイスがコンピュータシステムの電源投入および電源切断を行うことも可能にする。
　例えば、マウスのタッチまたはキーの押下によって、コンピュータシステムを、ＡＣＰＩを用いて起動させることができる。
【０００７】
　もともと、ＡＣＰＩは、さまざまな理由により取り扱いが困難であった。
　まず、ＡＣＰＩは、どのコンピュータシステムプラットフォームのネイティブアセンブリ言語によっても記述されていない。
　その代わり、ＡＣＰＩは、それ自身のソース言語、すなわちＡＣＰＩソース言語（ACPI Source Language）（ＡＳＬ）、およびそれ自身のマシン言語、すなわちＡＣＰＩマシン言語（ACPI Machine Language）（ＡＭＬ）をそれぞれ持っている。
　その高度に専門化された用途のため、比較的少ないＡＳＬプログラマしか存在しない。
【０００８】
　さらに、ＡＳＬは、その限定された用途のため、比較的少ないコンストラクトしか持たない。
　またさらに、ＡＣＰＩコードは、その設計において従来型の一体構造である。
　その結果、これは、他のプラットフォームに、または同じプラットフォームの異なる構成にさえもＡＣＰＩコードを移植することを難しくする。
　したがって、新しいＡＳＬコードは、新しく設計されたプラットフォームと連携するために書き換える必要がある。
　ＡＳＬプログラマの数が限られていることは、新しいコードの記述をますます問題化し、費用のかかるものとしている。
【０００９】
　ＡＣＰＩは、静的テーブルおよび解釈可能テーブル（interpretable table）の双方からなる。
　ブートアップ時に、システムファームウェア（通常ＢＩＯＳ、すなわち基本入出力システム（Basic Input/Output System））が、静的テーブルを構築する。
　静的テーブルは、オペレーティングシステムによって消費される。
【００１０】
　解釈可能テーブルは、ＡＭＬからなる。
　ＡＭＬは、コンパイルされ、その後システムファームウェアにマージされる。
　オペレーティングシステムは、ＡＣＰＩインタプリタを用いて、解釈可能テーブルからＡＭＬを読み出し、設計されたインタフェースを実行する。
【００１１】
　このような方法で、オペレーティングシステムは、ハードウェア資源を操作する。
　解釈可能テーブルが、システムファームウェアにマージされるので、この従来の方法は、柔軟性、および拡張性を欠き、異なるシステム構成を収容するためにプログラムを作り直すには、かなりの時間を必要とする。
【００１２】
　例えば、従来、ＡＳＬ開発者は、ある特定の構成のプラットフォームまたはプラットフォームの差異を特定するＡＣＰＩコードを記述する。
　残念なことに、ハードウェアの変更がわずかに行われた場合でも、その設計は変更されなければならない。
【００１３】
　これにより、新しいＡＭＬコードを記述し、かつ新しいテーブルをシステムファームウェアにマージすることが必要になる。
　したがって、従来の設計は、移植性のあるものでないか、または再利用できるものではない。
【００１４】
　さらに、従来、プラットフォームの差異が存在する場合、またはプラットフォームが２つ以上のＡＣＰＩ起動（ACPI-aware）ＯＳシステムをサポートし、これらＯＳシステムが相互に相容れないＡＣＰＩ要件を有する場合に、ＡＣＰＩは、異なるシステムファームウェアＲＯＭ（読み出し専用メモリ）またはＢＩＯＳを使用することを必要としていた。
　同じシステムが複数のオペレーティングシステムをサポートする場合にも、異なるシステムファームウェアＲＯＭを使用しなければならなかった。
【００１５】
　例えば、パーソナルコンピュータの現在の技術は、ＩＡ−３２命令セットを使用する。
　Ｍｉｃｒｏｓｏｆｔ（登録商標）ファミリーのオペレーティングシステムは、特にＩＡ−３２命令セットを有するシステムでは、主にＡＣＰＩを使用する。
【００１６】
　ＡＣＰＩは、さまざまなオペレーティングシステムに、標準インタフェースとして受け入れられてきた。
　新しい命令セットのアーキテクチャであるＩＡ−６４が開発中であるが、その利点をレガシーＡＣＰＩコードまたは方法と共に十分に利用することはできない。
【００１７】
　Ｉｎｔｅｌ（登録商標）Corporationから市販される新しいＩｔａｎｉｕｍ（登録商標）Processor Familyは、ＩＡ−６４命令セットを使用する。
　このファミリーのプロセッサに基づくそれぞれの新しいプラットフォームまたはシステム構成用のＡＳＬは、現在の慣行が利用されるならば、独自に書き換える必要があるであろう。
【００１８】
　ＡＣＰＩの名前空間は、名前を付けられたオブジェクトを含むＯＳ制御メモリ内の階層的なツリー構造である。
　これらのオブジェクトは、データオブジェクトであってもよいし、制御メソッドオブジェクト、バス／デバイスパッケージオブジェクトなどのオブジェクトであってもよい。
　ＯＳは、ＡＣＰＩ　ＢＩＯＳに存在するＡＣＰＩテーブルから定義ブロックをロードおよび／またはアンロードすることにより、実行時に名前空間の内容を動的に変更する。
【００１９】
　ＡＣＰＩの名前空間のすべての情報は、差別化システム記述テーブル（ＤＳＤＴ（differentiated system description table））から生じる。
　ＤＳＤＴは、差別化された定義ブロックおよび１つまたは２つ以上の他の定義ブロックを含む。
【００２０】
　現在の技術では、ＯＥＭ（相手先ブランド製造者（original equipment manufacturer））が、ＡＣＰＩ互換ＯＳにＤＳＤＴを供給しなければならず、ＡＣＰＩ互換ＯＳは、ベースシステムについての実施情報および構成情報を供給する。
　このＯＳは、システムブート時には常に、ＤＳＤＴ情報をＡＣＰＩ名前空間に挿入し、それを決して消去しない。
【００２１】
　別のＡＣＰＩコンストラクトは、２次システム記述テーブル（secondary system description table）（ＳＳＤＴ）である。
　ＳＳＤＴは、ＤＳＤＴの延長である。
　複数のＳＳＤＴをプラットフォームの記述の一部として使用することができる。
【００２２】
　ＤＳＤＴがＡＣＰＩ名前空間にロードされた後、一意のＯＥＭテーブルＩＤを備えたそれぞれの２次記述テーブル（secondary description table）がロードされる。
　これにより、ＯＥＭは、別のテーブルのより小さなシステムオプションを追加している間に、あるテーブルの基本サポートを提供することが可能になる。
　追加テーブルは、データの追加のみを行うことができる。
　それらのテーブルは、前のテーブルからのデータを上書きすることはできない。
【００２３】
　システム抽象レイヤ（system abstract layer）（ＳＡＬ）によって定義されるＡＣＰＩアーキテクチャのコンストラクトは、ファームウェアインタフェーステーブル（firmware interface table）（ＦＩＴ）である。
　これは、ＩＡ−６４命令セットのコンストラクトである。
【００２４】
　ＦＩＴは、保護されたブートブロックの外部にあるファームウェアコンポーネントの開始アドレスおよびサイズを含む。
　ＦＩＴエントリ仕様の優れた概要は、http://www.intel.com/design/itanium/downloads/24535905.pdfにおいて入手できる非特許文献２に見ることができる。
【非特許文献１】「Advanced Configuration and Power Interface Specification」Revision 2.0a, March 31, 2002
【非特許文献２】「ＩＴＡＮＩＵＭ（登録商標） Processor Family System Abstraction Layer Specification」Document No. 245359-005, (Intel July 2002)
【発明の開示】
【発明が解決しようとする課題】
【００２５】
　本発明の目的は、ファームウェアインタフェーステーブルを用いてＡＣＰＩのＳＳＤＴを動的にロードするシステムおよび方法を提供することである。
【課題を解決するための手段】
【００２６】
　ＩＡ−６４命令セットのファームウェアインタフェーステーブル（ＦＩＴ）は、２次システム記述テーブル（ＳＳＤＴ）データを用いてハードウェアコンポーネントの名前空間を占めるために使用される。
　ＳＳＤＴデータは、当該システムのコンポーネントを記述する。
　ブートアップ時に、すべてのハードウェアコンポーネントが検出される。
　システムファームウェア内のＡＣＰＩサブシステムは、データ設定を使用し、ＳＳＤＴをＦＩＴからロードして、アクティブなシステムコンポーネントの名前空間を作成する。
【００２７】
　システムブート時に１つまたは２つ以上のＳＳＤＴをＦＩＴにロードすることができように、ＦＩＴデータタイプは、それぞれのＳＳＤＴタイプに対して定義される。
　差別化システム記述テーブル（ＤＳＤＴ）データも、ＦＩＴに配置され、１つまたは２つ以上のＳＳＤＴと結合されて、システムのすべてのアクティブなコンポーネントについての結合された名前空間が作成される。
【００２８】
　より詳細な説明は、以下の図面を参照して行われる。
　図面において、同様の符号は、同様の要素を参照している。
【発明の効果】
【００２９】
　本発明によれば、ファームウェアインタフェーステーブルを用いてＡＣＰＩのＳＳＤＴを動的にロードするシステムおよび方法を提供することができる。
【発明を実施するための最良の形態】
【００３０】
　ＡＣＰＩは、新しいＩＡ−６４命令セットにも使用されるＩＡ−３２命令セットのコンセプトである。
　ＡＣＰＩは、ハードウェア操作および構成データを抽象化し、オペレーティングシステム（ＯＳ）およびファームウェアの対話のためのハードウェアの構成を定義する手段である。
　ＡＣＰＩは、業界標準仕様である。
【００３１】
　現在、主な３つの市販のパーソナルコンピュータ（ＰＣ）オペレーティングシステム、すなわちＬｉｎｕｘ、ＨＰ／ＵＸおよびＷｉｎｄｏｗｓ（登録商標）は、ＩＡ−３２空間でＡＣＰＩを使用し、新しいＩＡ−６４空間でＡＣＰＩを使用して作動するであろう。
　システムブート時、ファームウェアが作動され、システム構成を決定する。
【００３２】
　システムは、初期化の必要があれば初期化され、その後、操作は、ＯＳに引き渡される。
　すなわち、操作は、ＯＳをブートアップする。
　システムがブートアップされると、種々のプラットフォーム構成の知識を持たなければならない。
　ＡＣＰＩは、異なるプラットフォーム構成を定義するために、インタフェースオブジェクトおよび名前空間を有するハードウェア構成用の仕様である。
【００３３】
　新しいプラットフォーム用のＡＣＰＩコードの生成を、さらに構造化し、かつプラットフォームから独立させることが望まれている。
　これは、ＡＣＰＩコードのモジュール設計を備えた設計化アプローチ（architected approach）を使用して達成することができる。
　ＡＣＰＩ設計のこの方法は、現在使用されておらず、実際に、開発者は、この方法に対して難色を示している。
【００３４】
　これまでのＡＣＰＩ設計に関連する別の問題は、ＡＣＰＩ開発者が、いかなる所定のプラットフォームの差異もＡＳＬを使用して詳細に記述しなければならなかったことである。
　ハードウェアの変更がわずかに行われたとしても、設計には、移植性または再利用可能性が考慮されていなかった。
【００３５】
　この考慮していないことは、ブートアップ中にハードウェアコンポーネントを見失うことを含んでいた。
　さらに、その所定のプラットフォームのタイプの差により、またはその同じシステムが複数のオペレーティングシステムをサポートしていると、同じＲＯＭを使用することができなかった。
【００３６】
　名前空間は、コンピュータシステムの階層を論理的方法で記述する。
　例えば、ＯＳが名前空間を消費すると、ＯＳは、ハードウェアが下層でどのようなものかのイメージを得る。
　したがって、ＯＳが、所定のハードウェアコンポーネント用の資源を得る必要があるか、またはコンポーネントへのアクセス方法を知る必要がある場合、ＯＳは、名前空間を頼りにする。
【００３７】
　例えば、ＯＳが、マシンをスリープ状態にする必要がある場合、デバイスをスリープ状態にする方法を特定するオブジェクトが存在する。
　ＯＳは、名前空間で定義されたインタフェースまたはオブジェクトを用いて、ハードウェアを操作する。
　これが、ＡＣＰＩの機能である。
【００３８】
　本システムおよび方法の利点は、本システムおよび方法により、さまざまなプラットフォームおよびそれらプラットフォームの複数の構成が、共通のファームウェアまたは汎用的にプログラミングされたファームウェアを用いて実行可能になるということである。
　現在存在するファームウェアの現時点で満たされていない要望は、当該ファームウェアが１つのプラットフォームの１つの構成でしか使用できないことである。
　本システムおよび方法は、３つの主なＯＳのすべてで同時に動作するシステムファームウェアを可能にする。
　したがって、このファームウェアは、構成またはＯＳが変更されるごとに、アップグレード／変更される必要がないことになる。
　これを行うには、ＯＳは、特に、どのオペレーティングシステムがブート時にプラットフォーム上で実行されているかを知っている必要がある。
【００３９】
　ＩＡ−６４命令セットは、システムファームウェアが、システムハードウェアのＲＯＭコンポーネントにどのように配置されるかを記述する。
　システムにマージされるさまざまなファームウェアコンポーネントが存在し、これらファームウェアコンポーネントには、ＡＣＰＩ　ＡＭＬテーブル、ＡＣＰＩ静的テーブル、および純粋にファームウェアであるＳＡＬ（システム抽象レイヤ（system abstraction layer））が含まれる。
【００４０】
　ファームウェアインタフェーステーブル（ＦＩＴ）は、ＲＯＭに存在し、ＲＯＭのレイアウトおよびそれぞれのタイプのファームウェアコンポーネントが存在する場所を記述する。
　ＦＩＴは、所定の個数のフィールドを有し、それぞれのフィールドは、タイプを有する。
【００４１】
　フィールドのタイプは、コンポーネントのタイプを特定する。
　このようにして、コンポーネントのタイプは、構造化されている。
　例えば、タイプ０ｘＥ（１６進数のＥ）は、ＰＡＬ（processor abstraction layer）を指定するタイプを示すであろう。
　ベンダＯＥＭフィールドであるタイプの範囲も存在する。
【００４２】
　次に図面、特に図１を参照して、図１には、ＩＡ−６４命令セットに関連したファームウェア用の例示的なシステムＲＯＭ１００が示されている。
　ＲＯＭ１００は、いくつかのコンポーネント領域、例えば、ＳＡＬ領域１０１、ＰＡＬ領域１０３、ＳＳＤＴ領域１０５、ＡＣＰＩテーブル１０７、およびＦＩＴ１０９を有する。
　ＦＩＴは、多数のフィールド、例えば、アドレス１１１、サイズ１１３、チェックサム１１５、タイプ１１７、バージョン１１９等を有する。
【００４３】
　この例では、ＦＩＴアドレス１１１は、ＳＡＬ１０１の開始アドレスを指し示している。
　サイズ１１３は、ＳＡＬ領域の長さを示し、これにより、要求があった時、正確なバイト数が検索される。
　ＲＯＭ内のデータの完全性を保証するためにチェックサム１１５を設けることができる。
【００４４】
　ＡＣＰＩテーブル１０７は、特定のテーブルに依存して、静的かまたは動的（すなわち解釈可能（interpretable））であってよい。
　システムの名前空間を作成するために、ＤＳＤＴ（差別化システム記述テーブル（differentiated system descriptor table））が、ＲＯＭに記憶され、ＦＩＴを用いて検索可能になっている。
　ＡＣＰＩに準拠したＯＳは、ＤＳＤＴが存在することを必要とする。
【００４５】
　ＤＳＤＴは、実行可能なＡＭＬ部分を定義する。
　ＤＳＤＴは、ルートシステムのハードウェアコンポーネントを定義する。
　ＡＣＰＩは、ＳＳＤＴ（２次システム記述テーブル（secondary system description table））１１５も用意する。
　ＡＣＰＩインタプリタが実行されると、ＡＣＰＩインタプリタは、ＤＳＤＴおよびすべてのＳＳＤＴを検索し、結合されたシステム名前空間を作成する。
【００４６】
　個々のＳＳＤＴエントリは、システムに存在するコンポーネントタイプのそれぞれの構成に対して作成される。
　例えば、システムが、ローカルバスアダプタに関して２つの差異を持つことができる場合、ローカルバスアダプタコンポーネントを定義するために生成された２つのＳＳＤＴが存在することとなる。
【００４７】
　例えば、それぞれのプラットフォーム構成の差異に対して１つずつのＳＳＤＴが存在することとなる。
　それぞれのＳＳＤＴは、それ自身のタイプ１１７を有する。
　例えば、タイプ５５から８０が、さまざまなＳＳＤＴのタイプ専用に確保されている。
　この方法は、少ない構成の差異しか持たない単一のプラットフォームに対して適切に機能する。
【００４８】
　図２を参照して、例示的なＤＳＤＴ名前空間２００が示されている。
　システムボードのルートシステムバス（ＳＢ）は、システムバスアダプタ（ＳＢＡ）＿ＳＢＡ０　２０３を有する＿ＳＢ　２０１である。
　ＳＢＡ　＿ＳＢＡ０は、ＰＣＩ（peripheral component interconnect/interface）コンポーネントＰＣＩ−１　２０５を有する。
【００４９】
　ＳＢＡ　＿Ｓ０Ａ０およびＰＣＩ−１は、それぞれそれらに関連する＿ＣＲＳ　２０９および２０７を有する。
　ＤＳＤＴは、システム全体を記述していなくてもよい。
　例えば、ＤＳＤＴは、ブートを成功させるために稼動中にあることが要求されるコンピュータシステムの一部を記述していてもよい。
　図３は、例示的なＳＳＤＴを示している。
　このＳＳＤＴは、ブート時に、ＤＳＤＴと結合されて、システム全体を記述する。
【００５０】
　次に、図３を参照して、ＳＳＤＴ３００は、ルートの＿ＳＢ．＿ＳＢＡ０　３０１を有する。
　この名前は、この名前空間においてそれに続く子が、ＤＳＤＴ２００のルート＿ＳＢ　２０１のＳＢＡ０子２０３と関連していることを示している。
　＿ＳＢ．＿ＳＢＡ０という表記は、本質的にオブジェクト指向型の表記である。
【００５１】
　子ノードは、一般にその親のコンポーネントである。
　コンポーネント＿ＳＢ．＿ＳＢＡ０　３０１は、ＰＣＩコンポーネントＰＣＩ−５　３０３を有し、ＰＣＩ−５　３０３は、それに関連する状態＿ＳＴＡ　３０５を有する。
　システムブート時に、ＤＳＤＴおよびＳＳＤＴは結合され、図４に示すようなシステム名前空間４００が作成される。
【００５２】
　次に、図４を参照して、システムバス＿ＳＢ　４０１用の結合された名前空間４００が示されている。
　ＤＳＤＴ２００およびＳＳＤＴ３００の名前空間で定義されたように、このシステムバスは、子ＳＢＡ　＿ＳＢＡ０　４０３を有し、子ＳＢＡ　＿ＳＢＡ０　４０３は、ＰＣＩコンポーネントＰＣＩ−１　２０５およびＰＣＩ−５　３０３を含み、ＰＣＩコンポーネントＰＣＩ−１　２０５およびＰＣＩ−５　３０３は、それらに関連する子を有する。
【００５３】
　完全な名前空間を動的に設計する利点は、同じ土台のファームウェアを異なる構成に供給できることである。
　構成の相違は、１つまたは２つ以上のＳＳＤＴ領域で定義することができる。
　図１を再び参照して、ＦＩＴ１０９のＳＳＤＴエントリは、そのタイプ１１７によって特定される。
【００５４】
　ＦＩＴ１０９は、１つまたは２つ以上のＳＳＤＴ１０５を指し示し、ブート時に読み込まれる。
　ＳＳＤＴ用のアドレスが、ＲＯＭまたはシステムの他の任意のメモリ領域を指し示すことができることは、当業者には明らかであろう。
【００５５】
　動的な名前空間の別の利点は、ブート中に機能しなくなるコンポーネントが存在し得ることである。
　ブートを成功させるために、システムのすべてのデバイスが存在する必要がないこともあり得るし、あるいは、機能する必要がないこともあり得る。
　従来技術のシステムでは、あるデバイスがブート中に機能しなくなると、ブート全体が機能しなくなることが多い。
【００５６】
　Ｗｉｎｄｏｗｓ（登録商標）にとって、これは、結果として、「死のブルースクリーン（the blue screen of death）」として知られている状態、すなわちシステム障害となり得る。
　動的なＳＳＤＴを用いてオプションのデバイスを定義すると、システムは、それらオプションのデバイスが存在し、かつブート時に機能しているかどうかを判断することができる。
　もし存在し、かつ機能していない場合、それらデバイスは、名前空間にロードされない。
　したがって、ＯＳは、ブート時にそれらデバイスを探索しないであろう。
【００５７】
　図５（Ａ）および図５（Ｂ）は、システム−１およびシステム−２の例示的なハードウェア構成を示している。
　ここで、両システムは、本方法を利用して同じファームウェアを使用することができる。
　図５（Ａ）を参照して、２つのローカルバスアダプタ（ＬＢＡ）ＬＢＡ１　５０３およびＬＢＡ２　５０５を有するシステムバスアダプタ（ＳＢＡ）５０１が示されている。
【００５８】
　ＬＢＡ１は、４つのスロットＳ１、Ｓ２、Ｓ３およびＳ４（５０７、５０９、５１１および５１３）を有する。
　ＬＢＡ２は、１つのスロットＳ１　５１５のみを有する。
【００５９】
　図５（Ｂ）を参照して、３つのＬＢＡ、すなわちＬＢＡ１、ＬＢＡ２およびＬＢＡ４（５２３、５２５および５２７）を有するＳＢＡ５２１が示されている。
　ＬＢＡ１は、２つのスロットＳ１およびＳ２（５２９および５３１）を有する。
　ＬＢＡ２は、１つのスロットＳ１　５３３を有する。ＬＢＡ４は、３つのスロットＳ１　５３５、Ｓ２　５３７、およびＳ３　５３９を有する。
【００６０】
　これらのシステムの名前空間を表すのに使用される簡易化したＤＳＤＴは、図６（Ａ）のようになる。
　システム−１の残りのコンポーネントを記述するために使用されるＳＳＤＴは、図６（Ｂ）のようになる。
　システム−２の残りのコンポーネントを記述するために使用されるＳＳＤＴは、図６（Ｃ）のようになる。
【００６１】
　両システムが、２つのローカルバスアダプタを備えたＳＢＡを有し、第１のＬＢＡが少なくとも２つのスロットを有し、第２のＬＢＡが１つのスロットを有することは、当業者に明らかであろう。
　この構成が、この例での基本システムであり、ＤＳＤＴは、これらのコンポーネントのみを定義する必要がある。
　他のすべてのコンポーネントは、ＳＳＤＴに記述される。
【００６２】
　例えば、システム−１について、ＬＢＡ１の２つの追加スロットは、基本構成上に定義されなければならない。
　システム２について、追加ＬＢＡであるＬＢＡ４は、３つのスロットＳ１、Ｓ２およびＳ３により定義されなければならない。
　したがって、同じファームウェアにとって、システム−１およびシステム−２を収容するには、ロードされるＳＳＤＴのみが変更されなければならない。
【００６３】
　次に、図７を参照して、ＤＳＤＴおよび少なくとも１つのＳＳＤＴ　ＦＩＴエントリを用いて、システムコンポーネントの名前空間を生成する例示的な方法を示すフローチャートが示されている。
　ステップ７０１において、システムコンポーネントが特定され、システムコンポーネントの対応する情報、すなわち定義が、１つまたは２つ以上のＳＳＤＴ領域に記憶される。
　この情報は、ＲＯＭまたはシステムファームウェアにアクセス可能な他の任意のメモリに記憶することができる。
【００６４】
　ステップ７０３において、システムのブートアップ中、ブートに成功したコンポーネントが特定される。
　これについて、これらコンポーネントは「アクティブな」コンポーネントとして知られている。
　すべての可能なＳＳＤＴがＲＯＭにロードされ、ＦＩＴによって記述される。
　ステップ７０５において、ＳＡＬによるＡＣＰＩ静的テーブルの生成時に、ＳＡＬは、アクティブなコンポーネント用にどのＳＳＤＴをロードするかを決定し、その情報をＡＣＰＩ静的テーブルに置く。
【００６５】
　システムコンポーネント情報が検索されて、システム名前空間が生成されると、アクティブでない、すなわち機能していないコンポーネントは、記述されない。
　これにより、不可欠でない１つまたは２つ以上のコンポーネントがない状態で、システムをブートアップすることが可能となる。
　また、ステップ７０７において、システムのブートアップ中、ＡＣＰＩインタプリタは、静的テーブルおよび動的テーブルを消費して、静的テーブルおよび動的テーブル（ＤＳＤＴおよびＳＳＤＴ）を結合することにより、有効なＡＣＰＩ名前空間を作成する。
【００６６】
　名前空間が、ＡＣＰＩインタプリタによって完成されると、ステップ７０９において、制御はＯＳに渡され、システムは立ち上げられ、そして稼動状態になる。
　その後、ＯＳは、生成された名前空間を用いて、システムコンポーネントと対話を行う。
　ファームウェアインタフェーステーブルを用いてＡＣＰＩ　ＳＳＤＴをロードする新規な方法の好ましい実施形態（例示することを意図し、限定することを意図していない）を説明してきたが、当業者は、上記教示に照らして変更および変形を行い得ることに留意されたい。
　したがって、併記特許請求項によって定義されるような本発明の範囲および精神の範囲内にある変更を、開示された本発明の具体的な実施形態において行い得ることが理解されよう。
【産業上の利用可能性】
【００６７】
　本発明は、プロセッサ用のファームウェアに利用可能である。
【図面の簡単な説明】
【００６８】
【図１】ファームウェアインターフェーステーブルを有する例示的なファームウェアＲＯＭのブロック図である。
【図２】ＤＳＤＴの例示的な名前空間を示す図である。。
【図３】ＳＳＤＴの例示的な名前空間を示す図である。
【図４】図２のＤＳＤＴおよび図４のＳＳＤＴからのコンポーネントを結合した名前空間を示す図である。
【図５】（Ａ），（Ｂ）は、システムバスアダプタならびに少なくとも１つのローカルバスアダプタおよび対応するスロットを有する例示的なシステムのブロック図である。
【図６】（Ａ）は、図５（Ａ）および図５（Ｂ）に共通に示すハードウェアコンポーネントに対応するＤＳＤＴ名前空間の例を示す図である。　（Ｂ）は、図６（Ａ）のＤＳＤＴ名前空間に含まれない、図５（Ａ）に示すハードウェアコンポーネントに対応するＳＳＤＴ名前空間の例を示す図である。　（Ｃ）は、図６（Ａ）のＤＳＤＴ名前空間に含まれない、図５（Ｂ）に示すハードウェアコンポーネントに対応するＳＳＤＴ名前空間の例を示す図である。
【図７】ＤＳＤＴおよび少なくとも１つのＳＳＤＴ　ＦＩＴエントリを用いてシステムコンポーネント名前空間を生成する例示的な方法を示すフローチャートである。
【符号の説明】
【００６９】
１０１・・・ＳＡＬ領域、
１０３・・・ＰＡＬ領域１０３、
１０５・・・ＳＳＤＴ領域１０５、
１０７・・・ＡＣＰＩテーブル、
１０９・・・ＦＩＴ１０９、
１１１・・・アドレス１１１、
１１３・・・サイズ、
１１５・・・チェックサム、
１１７・・・タイプ、
１１９・・・バージョン、
２００・・・ＤＳＤＴ名前空間、
２０５・・・コンポーネントＰＣＩ−１
３００・・・ＳＳＤＴ、
４００・・・システム名前空間、
５０１・・・システムバスアダプタ（ＳＢＡ）、
５０３，５０５，５２３〜５２７・・・ローカルバスアダプタ（ＬＢＡ）、
５０７〜５１５，５３７〜５３９・・・スロット、
【図１】
2004070945.tif 000003
【図２】
2004070945.tif 000004
【図３】
2004070945.tif 000005
【図４】
2004070945.tif 000006
【図５】
2004070945.tif 000007
【図６】
2004070945.tif 000008
【図７】
2004070945.tif 000009