JP2001520416A

JP2001520416A - 仮想メモリサブシステムから物理メモリのコンテンツにアクセスして実行する方法及び装置

Info

Publication number: JP2001520416A
Application number: JP2000516281A
Authority: JP
Inventors: マシューイー．ジルマー; クァンファン
Original assignee: フィーニックステクノロジーズリミテッド
Priority date: 1997-10-09
Filing date: 1998-10-09
Publication date: 2001-10-30
Also published as: GB0008472D0; AU9792998A; WO1999019796A1; GB2345996A; TW425529B; GB2345996B

Abstract

(57)【要約】本発明は、プロセッサベースシステムの仮想メモリから物理メモリの命令シーケンスにアクセスして実行する装置及び方法である。装置は、プロセッサベースシステムが処理される命令シーケンスを格納するためのメモリを有し、メモリは、物理メモリと仮想メモリとを含む。装置は、格納された命令シーケンスを実行するプロセッサも有する。格納された命令シーケンスは、プロセッサに以下の動作を生じさせるプロセスステップを含む。すなわち、物理メモリから仮想メモリへの複数の所定命令シーケンスのマップと、仮想メモリにて前記複数の所定命令シーケンスの１つに対するオフセットの判別と、複数の所定命令シーケンスの１つを実行する命令の受け入れと、複数の所定命令シーケンスのうちの１つへの制御の転送と、仮想メモリから複数の所定命令シーケンスの１つの処理とである。

Description

【発明の詳細な説明】

【０００１】

【発明の背景】

【０００２】

【技術分野】

本発明は、プロセッサベースシステムのメモリに関し、特に仮想記憶サブシス
テムから物理メモリのコンテンツにアクセスして実行するための装置および方法
に関する。

【０００３】

【関連技術の説明】

仮想記憶サブシステムにおいて、仮想記憶アドレス指定は、ソフトウェアプロ
グラムにおいて使用されるメモリアドレスが、物理メモリの位置に間接的にマッ
プされる場合に使用される。物理アドレスへの変換は、大抵はプロセッサによっ
てなしとげられる。そして、かかる物理アドレスは、ユーザモードソフトウェア
および基本入出力システム（ＢＩＯＳ）にアクセス不能である。

【０００４】かかる仮想記憶サブシステムの一例は、ＷｉｎｄｏｗｓＮＴにより使用されるものである。尚、ＷｉｎｄｏｗｓＮＴは、マイクロソフトによって製造されて販売されている。特に、ＷｉｎｄｏｗｓＮＴは、デマンドページ仮想メモリサブシステムを取り入れる。ＷｉｎｄｏｗｓＮＴオペレーティングシステムで動作しているプログラムに提供されるメモリアドレス空間は、他のプログラムが
他のユーザモードプログラムから保護されているように、他のユーザモードプロ
グラムから保護されている。これは、ユーザモードサービスおよびアプリケーシ
ョンが、お互いのメモリに書き込んだり、またはお互いの指示を実行しないこと
を保証するものである。カーネルモードサービスおよびアプリケーションは、同
様の方法で保護されている。プログラムの割当られた仮想空間の外側のメモリに
アクセスしようとする場合、プログラムが終了されるとともに、ユーザに通知さ
れる。

【０００５】仮想記憶サブシステムも、物理メモリアドレスや、コンピュータシステムの一
部である入出力装置へのユーザモードソフトウェアによる直接アクセスを防ぐ。仮想記憶サブシステムを使用しているオペレーティングシステムを実行できる
コンピュータシステムの入出力装置の使用に対する傾向が増加している。かかる
システムでは、ＢＩＯＳファンクション等のプログラムの仮想記憶空間の外側で
メモリにアクセスするための手段が無い。この課題に対する１の方法は、装置用
の命令を含むファイルを読み込むデバイスドライバをインストールすることであ
る。ドライバは、ファイルを読み込んで、これらの命令を装置のメモリに書き込
む（またはダウンロードする）。しかし、このタイプのデバイスドライバは、メ
モリに対する限られたアドレス指定能力及び入出力動作のみを許容する。更に、
それは、物理メモリ空間でのシステムのプロセッサ命令の実行を許可しない。

【０００６】したがって、仮想記憶サブシステムから物理メモリのコンテンツをアクセスし
て実行するための装置および方法に対する技術に需要が存在する。そして、これ
は、メモリ用の増大したアドレス指定能力および入出力動作を容易にするととも
に、物理メモリから直接にプロセッサ命令の実行を許容する。

【０００７】

【発明の簡単な概要】

本発明は、プロセッサベースシステムの仮想メモリから物理メモリの命令シー
ケンスにアクセスして実行する装置および方法である。この装置は、プロセッサ
ベースシステムが処理される命令シーケンスを格納するためのメモリを有し、メ
モリは、物理メモリと仮想メモリとを含む。装置は、格納された命令シーケンス
を実行するためのプロセッサも有する。格納された命令シーケンスは、プロセッ
サに以下の動作を生じさせるプロセスステップを含む。すなわち、物理メモリか
ら仮想メモリへの複数の所定命令シーケンスのマップと、仮想メモリの複数の所
定命令シーケンスのうちの１つに対するオフセットの判別と、複数の所定命令シ
ーケンスのうちの１つを実行する命令の受け入れと、複数の所定命令シーケンス
のうちの１つへの制御の転送と、仮想メモリから複数の所定命令シーケンスのう
ちの１つの処理とである。

【０００８】

【好ましい発明の詳細な説明】

本実施例を、プロセッサシステム１０に関して記載する。図１は、本発明の処
理を実行する典型的なプロセッサシステム１０を示す。プロセッサシステム１０
は、ＣＰＵ１２とメモリモジュール１４とを含む。メモリモジュール１４は、ラ
ンダムアクセスメモリ（ＲＡＭ）１６と、リードオンリーメモリ（ＲＯＭ）１８
とを含む。一実施例において、メモリモジュール１４は、メインメモリ、すなわ
ちダイナミックランダムアクセスメモリ（ＤＲＡＭ）を含む。ＣＰＵ１２および
メモリモジュール１４は、システムバス２０に接続されている。プロセッサシス
テム１０は、さまざまなＩ／Ｏおよび周囲モジュールを（ＭＩＳＣ，Ｉ／Ｏ＃１，＃２．．．＃Ｎ)も含むことがある。これらのさまざまなＩ／Ｏおよび周囲モジュールは、システムバス２０に接続されているＩ／Ｏバスに沿って接続さ
れている。周囲モジュールは、一例として、コンソール、プリンタ、マウスから
なる。

【０００９】本発明は、処理システム１０にインストールされるオペレーティングシステム
に関しても記載する。図２は、本発明の装置および方法を使用している処理シス
テム１０の構造を示している全体のファンクションブロック図である。処理シス
テム１０は、アプリケーションプログラム３２及びサービス３４をサポートする
オペレーティングシステム３０と、基本入出力システム（ＢＩＯＳ）３６と、シ
ステムハードウェア３８とからなる。ＢＩＯＳ３６は、例えばコンソール（キー
ボードおよびディスプレイ）等のハードウェア装置、一般的なプリンタ、補助装
置（シリアルポート）、コンピュータの時計、ブートディスク装置に対する、ド
ライバやソフトウェアインタフェース等の集合である。ＢＩＯＳ３６は、大抵、
プログラマブルなリードオンリーメモリ（ＰＲＯＭ）に埋め込まれている。しば
しば、ＢＩＯＳファンクションそれ自身が、ＲＡＭ１６のより高速のアクセスタ
イムを利用することによって、ＰＲＯＭからＲＡＭ１６に実際にコピーされる。
これは、ＢＩＯＳ３６の「シャドウイング」として公知である。何となれば、Ｂ
ＩＯＳ３６の２個のコピーが、結果として、ＰＲＯＭのもの（これはもはや使用
されない）と、ＲＡＭ１６のものとをとを生じるからである。ＢＩＯＳ３６を格
納するＲＡＭ１６の一部は、ＢＩＯＳシャドウ空間として公知である。Ｗｉｎｄ
ｏｗｓＮＴ等のオペレーティングシステムは、オペレーティングシステムが起動して動作したあとは、ＢＩＯＳ３６を使用しない。ＷｉｎｄｏｗｓＮＴオペレーティングシステムのカーネルレベルドライバは、直接システムハードウェア
とインターフェースする。本発明は、システムハードウェア３８とオペレーティ
ングシステム３２との間のインタフェースとして、ＢＩＯＳ３６の使用を容易に
する。

【００１０】オペレーティングシステム３０は、アプリケーションプログラム３２とサービ
ス３４とにインタフェースするクラスドライバ４０と、Ｉ／Ｏマネージャー４２
とを含む。Ｉ／Ｏマネージャー４２は、適切に順番付けられた呼出しへとクラス
ドライバ４０を介して作成されるアプリケーションプログラム３２およびサービ
ス３４からのＩ／Ｏ要求を、カーネル４４に位置するさまざまなドライバルーチ
ンに変換する。特に、Ｉ／Ｏマネージャー４２にＩ／Ｏ要求が入力されるときに
、それは、カーネル４４に位置するドライバの複数のディスパッチルーチンのう
ちの１つを呼出す要求のファンクションコードを使用する。カーネル４４は、ハ
ードウェアから独立したファンクションを提供する。これは、システムファンク
ションと呼ばれ、ソフトウェア割り込みによってアクセスされる。カーネル４４
により提供されるファンクションは、とりわけ、ファイルおよびディレクトリ管
理、メモリ管理、文字装置入出力、時間および日付サポートを含む。一実施例に
おいて、オペレーティングシステムは、ＷｉｎｄｏｗｓＮＴオペレーティングシステムである。他の実施例において、オペレーティングシステム３０は、ソラ
リス(Ｓｏｌａｒｉｓ)、すなわちＡＩＸオペレーティングシステム、またはデマ
ンドページ仮想記憶サブシステムに基づいた他のオペレーティングシステムを含
む。

【００１１】本発明は、カーネル４４内に配置されたアクセスドライバ４６を提供する。ア
クセスドライバ４６は、ＢＩＯＳ３６に位置するＢＩＯＳデータにアクセスした
り、ＢＩＯＳ３６を介してシステムハードウェア３８のデータにアクセスするこ
とに、責任を負うものである。アクセスドライバ４６は、関係するＢＩＯＳファ
ンクションの実行と同様に、ＢＩＯＳファンクションアドレスの位置にアクセス
することに対しても責任を負うものである。好ましい一実施例において、アクセ
スドライバ４４は、Ｃ言語にて書かれるソースコードから成る。なお、他のアセ
ンブリ言語を、アクセスドライバ４４のファンクションを実行する際に使用して
も良い。ＢＩＯＳデータおよびアドレスは、大抵物理メモリ５０（多くの場合Ｒ
ＡＭ１４ａ、図１参照）に配置され、アクセスドライバ４６によってＢＩＯＳイ
ンタフェース４８を介してアクセスされる。一実施例において、アクセスドライ
バ４６は、ＢＩＯＳシャドウ空間にて、多くの場合物理アドレス0ｘ000E0000−0
ｘ000FFFFFで、コードを実行する。

【００１２】例えば、アクセスドライバ４６は、アドレス0ｘ00000000の物理メモリにて位置するＢＩＯＳファンクションにアクセスする必要がある。それは、物理アドレ
ス0ｘ00000000から0ｘ00000FFFまでのメモリ空間を仮想記憶空間にマップするこ
とをそれに要求しながら、Ｉ／Ｏマネージャ４２に呼出しを作る。次に、Ｉ／Ｏ
マネージャ４２は、アクセスドライバ４６の仮想記憶空間、例えば0ｘfd268000 へのポインタを戻す。アクセスドライバは、0ｘfd268000を有するその仮想アドレスを基数としたり(basing)または参照することによって、物理アドレス0ｘ000
00000のアドレス空間を参照する。このように、物理アドレス0ｘ400に位置するアクセスファンクションは、使用される仮想アドレスは、0xfd268400である。

【００１３】好ましい実施例において、一組のエントリポイント、またはファンクション呼
出しは、アプリケーションプログラム３０、サービス３２、または、アクセスド
ライバ４６を使用するクラスドライバ４０に利用可能である。アクセスドライバ
４６は、オープンしたり、クローズしたりして、エントリポイントを介して入力
・出力（¨Ｉ/Ｏ¨）制御コード(”ＩＯＣＴＬｓ”)を取り込むことができる。表
１は、アクセスドライバ４６用の構造、エントリポイント、アプリケーションを
示す。

【００１４】図３は、本発明の原理に従って設けられるようなアクセスドライバ４６の初期
化処理を示しているブロック図である。一般に、アクセスドライバ４６が最初に
ロードされるとき、そのＤｒｉｖｅｒＥｎｔｒｙファンクション（表１を参照の
こと）が実行される。多数の他の初期化がこのファンクションで起こるが（例え
ばさまざまなリソースの割当てや、アクセスドライバ４６の通常動作のための目
的）、２つの特別に基本(essential)初期化が起きる。すなわち、(a)物理メモリ
５０に位置するＢＩＯＳシャドウ領域６０（これはＢＩＯＳサービスディレクト
リ６２を含む）と、（ｂ）物理メモリ５０に位置するＢＩＯＳデータ領域６４と
が、アクセスドライバ４６の仮想メモリ(ＢＩＯＳシャドウ領域７０（これはＢＩＯＳサービスディレクトリ７２を含む）及びＢＩＯＳデータ領域７４として図
３に示す)へと両方ともマップされる。その結果、アプリケーションプログラム３２やサービス３４は、クラスドライバ４０によって、仮想アドレス指定を使用
して、ＢＩＯＳファンクションにアクセスしこれを実行する。なお、ＢＩＯＳフ
ァンクションの実行は、アクセスドライバ４６から起こらなければならない。何
となれば、ＢＩＯＳ３６の物理アドレス空間がアクセスドライバ４６だけにマッ
プされるからである。更に、アクセスドライバ４６は、付録Ａに詳細に説明する
ように、３２ビットのＢＩＯＳパワーマネジメントサービスインタフェースの実
施を介して使用される。当業者には、ＢＩＯＳパワーマネジメントサービスイン
タフェースも、６４ビット、１２８ビット、２５６ビット構成に対して実行され
ることは明らかである。アクセスドライバ４６も、６４ビット、１２８ビット、
２５６ビット構成にて動作できる。

【００１５】特に、アクセスドライバ４６は、初期化の間、物理メモリ５０に位置するＢＩ
ＯＳシャドウ領域６０及びＢＩＯＳデータ領域６４を探索する。ＢＩＯＳシャド
ウ領域６０およびＢＩＯＳデータ領域６４は、アクセスドライバ４６の仮想アド
レス空間にマップされる。次に、アクセスドライバ４６は、ＢＩＯＳサービスデ
ィレクトリ７２のヘッダの検索を実行する。アクセスドライバ４６は、ＢＩＯＳ
サービスディレクトリ７２を見つけて確認すると、即座に、ＢＩＯＳサービスデ
ィレクトリ７２のヘッダの仮想アドレスを得る。そして、それは、ＢＩＯＳシャ
ドウ領域７０のベース仮想アドレスから、ＢＩＯＳサービスディレクトリ７２の
ヘッダの仮想アドレスのオフセットを提供する。

【００１６】他の実施例において、アクセスドライバは、初期化の間、物理メモリ５０に位
置するＢＩＯＳシャドウ領域６０と、ＢＩＯＳデータ領域６４と、ＢＩＯＳＲＯＭ領域とを検索する。ＢＩＯＳシャドウ領域６０と、ＢＩＯＳデータ領域６４
と、ＢＩＯＳＲＯＭ領域とは、アクセスドライバ４６の仮想アドレス空間にマップされる。次に、アクセスドライバ４６は、ＢＩＯＳサービスディレクトリ７
２のヘッダの検索を実行する。アクセスドライバ４６は、ＢＩＯＳサービスディ
レクトリ７２を見つけて確認すると、即座に、ＢＩＯＳサービスディレクトリ７
２のヘッダの仮想アドレスを得る。この他の実施例において、アクセスドライバ
４６の仮想メモリ空間のＢＩＯＳＲＯＭ領域の有効性によって、アクセスドライバ４６は、フラッシュＲＯＭのデータを読んだりまたはデータを書いたりする
ことができる。その結果、ＢＩＯＳＲＯＭは、リフラッシュしたり、書き直すことができる。更に、ハードウェアとインタフェースできる外部アプリケーショ
ンプログラムは、付録Ｂにおいて提供されるフェニックスフラッシュ(ＰｈｏｅｎｉｘＰｈｌａｓｈ）ＮＴ仕様書に記載されているような、ソフトウェア機構に
よってＢＩＯＳＲＯＭ領域にアクセスする。

【００１７】後で、アクセスドライバ４６の実行ファンクションに対する呼出しは、ＢＩＯ
Ｓシャドウ領域７０およびオフセットのベース仮想アドレスを使用して、ＢＩＯ
Ｓの要求されたエントリポイントを呼び出す。尚、アプリケーションプログラム
３２やサービス３４によって、ＢＩＯＳの仮想アドレス空間に適宜存在するＢＩ
ＯＳファンクションは、ＢＩＯＳサービスディレクトリ７２を介してのみだけで
はなく、実行することができる。

【００１８】一実施例において、ＢＩＯＳの要求されたエントリポイントを呼び出すために
呼ばれる実行ファンクションは、ＩＯＣＴＬ＿ＢＩＯＳ＿ＥＸＥＣファンクショ
ンであり、それは表１に記載されている。ＩＯＣＴＬ＿ＢＩＯＳ＿ＥＸＥＣファ
ンクションは、メインメモリやＤＲＡＭに位置するバッファ（それは、呼び出し
ているアプリケーションプログラム３２やサービス３４により指定される）にレ
ジスタスタックをつくる。スタックのコンテンツは、ＢＩＯＳファンクションが
呼び出される時の所望のレジスタ値である。アクセスドライバ４６は、呼び出し
ているアプリケーションプログラム３２やサービス３４からレジスタスタックを
パスする。プロシージャ呼出しそのものは、ＢＩＯＳサービスディレクトリ７２
にて指定されるファンクションへのポインタを使用して実行される。一実施例に
おいて、ＩＯＣＴＬ＿ＢＩＯＳ＿ＥＸＥＣによって呼ばれるＢＩＯＳファンクシ
ョンは、４バイトのシグネチャを引数として受け取って、シグネチャと関連する
ＢＩＯＳを探す。呼び出しているアプリケーションプログラム３２またはサービ
ス３４にパスされる値は、ＢＩＯＳファンクションのベース仮想アドレスと、サ
ービスのエントリポイントのベースアドレスからのオフセットとを含む。

【００１９】アクセスドライバ４６用の構造と、エントリファンクションと、アプリケーシ
ョンとの一般的な議論を行う。

【００２０】

【表１】

【００２１】

【表２】

【００２２】Ａ．アクセスドライバ４６ファンクションの詳細な説明１. 「ＤｒｉｖｅｒＥｎｔｒｙ」ファンクションこのエントリポイントによって、ドライバはその変数を初期化し、ＢＩＯＳシ
ャドウおよびデータ領域にマップし、リソースをその通常の動作に割り当てる。
各々のリソースまたはオブジェクトが割り当てられるように、それは、可変の「
ｐｈＲｅｓＡｎｄＦｌａｇｓ」に表にされ、これによって、ドライバに対してい
かなる理由がアンロードされようとも、ドライバにより使用されるリソースをフ
リーにする単一のファンクション（「ｆｒｅｅＲｅｓｏｕｒｃｅｓ」）が可能に
なる。割り当てられたりまたは接続されるリソースは、次の通りである。ａ．装置オブジェクトの作成−システムによって装置オブジェクトおよび名前の
決定。ｂ．エラーログの初期化−イベントログサービスへのリンクの作成。ｃ．主たるファンクションエントリポイントのセットアップ。ｄ．シンボリックリンクの作成−サービスまたはアプリケーションレイヤによる
使用に対して。ｅ．ＢＩＯＳシャドウのマップ−仮想メモリにアクセス可能なこのメモリ空間を
ドライバに作成。ｆ．ＢＩＯＳＲＯＭのマップ−仮想メモリアドレス空間にアクセスできるＲＯＭ領域を作成。ｇ．ＢＩＯＳデータのマップ−仮想メモリにアクセス可能なこのメモリ空間をド
ライバに作成。ｈ．このドライバによって使用されるＢＩＯＳ３２-ビットエントリポイントの
検索。

【００２３】一実施例において、装置オブジェクト名前は、「ラップトップ」であり、それ
は、マイクロソフトＯＥＭ適合キット（ＯＡＫ）によって要求されるネクサス(n
exus)ファンクションをサービスするために必要になる。対応するシンボリックリンク名前は、「ＰｈｏｅｎｉｘＡＤ」である。２．ＡｃｃｅｓｓＤｒｉｖｅｒＣｒｅａｔｅＣｌｏｓｅこのファンクションは、アプリケーションプログラム３２またはサービス３４
が、装置ハンドル用のシステムに要求を作るとき、または、すでに得られたハン
ドルを閉じるときに、ドライバ４６に知らせるために使用される。アクセスドラ
イバ４６は、うまく要求を終了するがドライバ４６の状態変数が全く変化しない
ことによって、このディスパッチエントリポイントに反応する。 3. ＡｃｃｅｓｓＤｒｉｖｅｒＵｎｌｏａｄこのディスパッチエントリポイントは、システムからドライバを除去するのに
必要なとき（装置が（ＳＣＭ）から閉じる)に、サービス制御マネージャ（ＳＣＭ）やほかのアプリケーションに代わってカーネルによって呼ばれる。このファ
ンクション呼出しの結果は、「ｐｈＲｅｓＡｎｄＦｌａｇｓ」に表にされたリソ
ースの全てが、システムに対してフリーにされ、要求がうまく完了されることで
ある。 4. ＡｃｃｅｓｓＤｒｉｖｅｒＲｅｇアクセスドライバ４６のドライバは、ＯＥＭ適合キット（ＯＡＫ）の一部とし
て提供されるパワーマネジメントモデルのための「ネクサス処理」を実行するフ
ァンクションを有する。このファンクションは、ＯＡＫ制御法を使用する要求及
び知識を有するＯＥＭ及び標準装置のパワーマネジメントのエミュレーションに
集積されている。ＡｃｃｅｓｓＤｒｉｖｅｒＲｅｇファンクションは、装置をリ
ンクされたリストに記録する。それは、要求に関して選択的に「記録解除する(d
eregisters)」装置である。典型的なＯＡＫ準拠デバイスドライバは、そのＤｒｉｖｅｒＥｎｔｒｙファンクションが実行されるときに（最初にロードされると
きに）、登録用に呼出しを行う。そして、ＤｒｉｖｅｒＵｎｌｏａｄファンクシ
ョンの一部として、各登録済み装置は、呼出しを行って、パワーマネジメントサ
ービスを必要としている装置のアクセスドライバ４６のリンクリストから、それ
自体を除去する。 5. ＩＯＣＴＬファンクションサービスやアプリケーションレイヤとＢＩＯＳとの間のあらゆるインタフェー
スは、アクセスドライバ４６のドライバのＩＯＣＴＬファンクションによって処
理される。各ＩＯＣＴＬ転送がバッファ付きモードで実行され、その結果、ドラ
イバへの入力データとその出力データとは、共通のシステムバッファにより転送
される。このバッファ空間へのポインタは、Ｉｒｐ＞ＡｓｓｏｃｉａｔｅｄＩｒ
ｐ．ＳｙｓｔｅｍＢｕｆｆｅｒとして入出力（Ｉ／Ｏ）要求パケットにおいて与
えられる。与えられた制御であると、即座に、ＩＯＣＴＬ（ドライバ内）は、シ
ステムバッファアドレスを得て、そのコンテンツを使用して要求を実行する。Ｉ
ＯＣＴＬファンクション実行の結果は、入力用に使用されたように、同じシステ
ムバッファに置かれる。

【００２４】アクセスドライバ４６のドライバにて実行される各々のＩＯＣＴＬは、ＩＯＣ
ＴＬ入力データ用の、そして、その出力データ用の固有データフォーマットを有
する。ファンクションが後述されるので、それらのデータバッファフォーマット
および各フィールドの説明が与えられる。バッファオフセットは、バイトで与え
られる。各ファンクションに対して与えられる最小バッファサイズは、アプリケ
ーションプログラムのユーザバッファに対して使用する推薦されるマロック(mal
loc())サイズである。システムバッファサイズは、ユーザバッファから自動的に
導かれる。 6. ＩＯＣＴＬ＿ＬｏｃａｔｅＩＯＣＴＬ＿Ｌｏｃａｔｅファンクションは、ドライバ４６が初期化した後、
アプリケーションプログラム３２またはサービス３４によって呼ばれる第１のデ
ィスパッチエントリポイントである。ファンクションは、フラットモデル仮想ア
ドレスフォーマット（３２ビットアドレス）にて、ＢＩＯＳ32サービスインタフ
ェースのアドレス、ＢＩＯＳシャドウ領域のベースアドレス、ＢＩＯＳデータ領
域のベースアドレスを戻す。尚、ＢＩＯＳ32サービスインタフェースは、ドライ
バレベルやカーネルスレッド（付録Ａを参照のこと）から実行されるＢＩＯＳフ
ァンクションの全てに対するシングルエントリポイントである。ＢＩＯＳ32サー
ビスインタフェースは、ドライバレベルまたはカーネルスレッド（付録Ａを参照
のこと）から実行されるＢＩＯＳファンクションの全てに対するシングルエント
リポイントである。これらのアドレス空間は、アクセスドライバ４６のドライバ
がロードされている期間に(のみ)、このドライバにアクセス可能と保証されてい
る。

【００２５】

【外１】

【００２６】 7. ＩＯＣＴＬＢＩＯＳ＿ＲｅａｄＩＯＣＴＬＢＩＯＳ＿Ｒｅａｄファンクションは、ＢＩＯＳＲＯＭ、シャ
ドウ領域、またはデータ領域のうちのいずれかの多目的リーダ(reader)である。

【００２７】

【外２】

【００２８】注：ＢＩＯＳ領域へのオフセットが、マップされたＢＩＯＳメモリの端部ととも
にオーバラップを指定したので「ｓｈｏｒｔｒｅａｄ」が生じる場合は、戻さ
れる誤差はない。その代わりに、「ａｃｔｕａｌｄａｔａｒｅａｄ」フィー
ルドは、正確に、どれだけのデータがシステムバッファにて有効であるかを示し
ている。８. ＩＯＣＴＬ＿ＢＩＯＳ＿ＷｒｉｔｅＩＯＣＴＬ＿ＢＩＯＳ＿Ｗｒｉｔｅファンクションは、ＢＩＯＳＲＯＭ、シャドウ、またはデータ領域のうちのいずれかの多目的ライター(writer)である。

【００２９】

【外３】

【００３０】注：ショート書込は、データ汚染の可能性のために許可されない。 9. ＩＯＣＴＬ＿ＢＩＯＳ＿ＥｘｅｃＩＯＣＴＬ＿ＢＩＯＳ＿Ｅｘｅｃファンクションは、ＢＩＯＳ32サービスイン
タフェースによってＢＩＯＳファンクションを実行するために使用される。起動
記録は、システムバッファの値によってパスされる。ＡＲは、ＢＩＯＳへのエン
トリポイントの起動時に、ベース構造レジスタコンテンツを判別する。首尾良く
終了したときに、ＡＲは、ＢＩＯＳ呼び出し側に通常戻されるベース構造コンテ
キストを含む。

【００３１】

【外４】

【００３２】１０. ＩＯＣＴＬ＿ＲＴＣ＿ＲｅａｄＩＯＣＴＬ＿ＲＴＣ＿Ｒｅａｄファンクションは、ＣＭＯＳＲＡＭのＲＴＣレジスタのコンテンツを読むために使用される。この原子読取り(atomic read) からのデータは、ＳＹＳＴＥＭＴＩＭＥ構造と同様にフォーマットされて、シス
テムバッファのユーザに戻される。

【００３３】

【外５】

【００３４】注：ＲＴＣのイヤーフィールドは、８ビット長である。ＲＴＣのイヤーフィ
ールドのコンテンツは、今年、西暦(ＡＤ）の全体の値を含むＳＹＳＴＥＭＴＩＭＥ．ＹＥＡＲ１６ビットフィールドに再計算される。例えば、ＲＴＣ＝00、Ｙ
ｅａｒ＝1980；ＲＴＣ＝23，Ｙｅａｒ＝２００３。また、レガシー(legacy)ＲＴ
Ｃ装置がそれらのレジスタのミリセカンドフィールドを提供しないことに注意す
る。これのため、このファンクションのための出力データの現在のミリセカンド
フィールドは、常にゼロに設定される。１１. ＩＯＣＴＬ＿ＶｅｒｓｉｏｎＩＯＣＴＬ＿Ｖｅｒｓｉｏｎファンクションは、呼び出し側のメジャー、アク
セスドライバ４６のドライバのマイナーバージョンに戻る。更に、ドライバのこ
のバージョンにより実行されるファンクションは、ビットマップに列挙される。
ビットマップの目的は、サービスや高レベルのドライバが、ドライバのこのバー
ジョンをそれらの目的のために使用することができるか否かを（多くはインスト
ール時に）評価することである。

【００３５】

【外６】

【００３６】１2. ＩＯＣＴＬ＿ＰＭ＿ＳｕｓｐｅｎｄＩＯＣＴＬ＿ＰＭ＿Ｓｕｓｐｅｎｄファンクションによって、ＩＲＰ＿ＭＪ＿
ＰＮＰ＿ＰＯＷＥＲとＩＲＰ＿ＭＮ＿ＬＴ＿ＳＵＳＰＥＮＤＩＲＰ’ｓとが、
アクセスドライバＤｒｉｖｅｒＲｅｇエントリポイントを使用してそれ自体を登
録した装置の各々に送られる。

【００３７】

【外７】

【００３８】１3. ＩＯＣＴＬ＿ＰＭＲｅｓｕｍｅＩＯＣＴＬ＿ＰＭ＿Ｒｅｓｕｍｅファンクションによって、ＩＲＰ＿ＭＪ＿Ｐ
ＮＰ＿ＰＯＷＥＲ、ＩＲＰ＿ＭＮ＿ＬＴ＿ＲＥＳＵＭＥＩＲＰ’ｓが、アクセ
スドライバＤｒｉｖｅｒＲｅｇのエントリポイントを使用してそれ自体を登録し
た装置の各々に送られる。

【００３９】

【外８】

【００４０】Ｂ．アクセスドライバ４６によって戻されるエラーコード以下の表は、ＲＰの終了が失敗したりまたは部分的に終了されるときに戻され
るエラー状況を定義する。ファンクションの終了の条件が、同様に与えられる。
この表は、必要である。何となれば、オペレーティングシステムによって公知の
ＮＴＳＴＡＴＵＳ値と、アクセスドライバ４６のデバイスドライバにより使用さ
れるものとの間に、１対１の対応が必ずしも必要でないからである。アプリケー
ションライターやエンドユーザによって使用できるストリングへとコードを逆に
変換するために、ＮＴＳＴＡＴＵＳエラーコードのみが使用されることが必須で
ある。

【００４１】

【表３】

【００４２】Ｃ．ＢＩＯＳ３２ビットエントリポイント仕様ＢＩＯＳ用のエントリポイントを見つけるＩＯＣＴＬ＿Ｌｏｃａｔｅのために
、ＢＩＯＳ３２-ビットサービスディレクトリが使用される。ＢＩＯＳ３２-
ビットサービスディレクトリの説明を、付録Ｃに記載する。ＢＩＯＳファンクシ
ョンを検索したり実行するときにアクセスドライバ４６が使用するシグネチャは
、「３２」とするものである。

【００４３】ＷｉｎｎｔＥｎｔｒｙ（ＢＩＯＳ32サービスディレクトリ）構造が上記の状態
を受けていることが見いだされなければ、アクセスドライバ４６のドライバは、
ロード時間で失敗し、そして、ＤｒｉｖｅｒＥｎｔｒｙは、表２に示すように、
初期化ができなかったことを示す。Ｄ．リアルタイムクロックハードウェアアクセスＩＯＣＴＬ＿ＲＴＣ＿Ｒｅａｄファンクションを実行するために、ＲＴＣのレ
ジスタとアクセスの方法とを定義することが必要である。ＲＴＣレジスタは、Ｃ
ＭＯＳＲＡＭのＩ／Ｏアドレス空間に位置する。ＲＴＣレジスタのみを、表３に示す。レジスタは、ＣＭＯＳＲＡＭアドレスをポート0ｘ70に出力して、次にポート0ｘ71で主体の８ビットレジスタを読み込むことによって、アクセスされる。すべてのＲＴＣが読まれたあと、ＣＭＯＳＲＡＭアドレスは0ｘ0Ｄを指
すように設定される。

【００４４】

【表４】

【００４５】図４Aは、本発明の初期化処理の一実施例を示しているフローチャートである。スタート状態から始まり、プロセスＳ100は、プロセスステップＳ110に進み、
呼び出しプログラム（すなわちＩ／Ｏマネージャ４２）の変数が初期化される。
初期化ステップＳ110の詳細を、図４Bおよび添付のテキストに提供する。プロセ
スS100は、次にプロセスステップＳ120へ進み、そこで、アクセスドライバ４６をロードする。アクセスドライバの変数の初期化が、次に起きる。初期化ステッ
プの間、２の特に不可欠な初期化が起きる。すなわち、(a) 物理メモリ５０に位
置するＢＩＯＳシャドウ領域６０（これはＢＩＯＳサービスディレクトリ６２を
含む）と、（ｂ）物理メモリ５０に位置するＢＩＯＳデータ領域６４とが、両方
ともアクセスドライバ４６のアクセスドライバ４６の仮想メモリ（仮想メモリは
、図３に示すようにＢＩＯＳシャドウ領域７０（これはＢＩＯＳサービスディレ
クトリ７２を含む）とＢＩＯＳデータ領域７４として示される）にマップされる
。

【００４６】プロセスＳ100は、次にプロセスステップＳ130へ進み、そこにおいて、ポイン
タの初期化が起きる。プロセスステップＳ130の詳細を、図４Cおよび添付のテキ
ストに提供する。プロセスＳ100は、次にプロセスステップＳ140へ進み、そこに
おいて、初期化が終了する。プロセスＳ100は、次に終わる。図４Bは、プロセスステップＳ110の詳細を示しているフローチャートである。
プロセスＳ110は、スタート状態から始まると、プロセスステップＳ112に進み、
そこにおいて、Ｉ／Ｏマネージャ４２からの呼び出しプログラムは、システムバ
ッファの指定されたメモリ構造に対してメモリを割り当てる。プロセスＳ110は、次にプロセスステップＳ114へ進み、そこにおいて、Ｉ／Ｏマネージャ４２からの呼び出しプログラムは、多数のＢＩＯＳファンクションの位置、それらの対
応するエントリポイント、長さ、オフセットを判別する。一実施例において、こ
れは、ＢＩＯＳファンクションの仮想アドレスを有する対応するＢＩＯＳファン
クションのために指定されたメモリ構造のアドレスフィールドに入ることによっ
て、そして、各々のＢＩＯＳファンクションを識別する４バイトのＡＳＣＩＩス
トリングを提供することによって、なしとげられる。次に、呼び出しプログラム
の初期化が終わる。

【００４７】図４Cは、図４AのプロセスステップＳ130の詳細を示しているフローチャートである。プロセスステップＳ132に示すように、呼び出しアプリケーションプログラム３２またはサービス３４は、スタート状態から始まり、クラスドライバに
よって、ＩＯＣＴＬ＿Ｌｏｃａｔｅに呼出しを行う。応えて、プロセスステップ
Ｓ134に示すように、アクセスドライバ４６は、ＢＩＯＳサービスディレクトリ７２のヘッダの検索を実行する。ＢＩＯＳサービスディレクトリ７２を見つけて
確認すると、即座に、アクセスドライバ４６は、ＢＩＯＳサービスディレクトリ
７２のヘッダの仮想アドレスを得る。そして、これは、ＢＩＯＳシャドウ領域７
０のベース仮想アドレスから、ＢＩＯＳサービスディレクトリ７２のヘッダ仮想
アドレスのオフセットを提供する。次に、プロセスＳ130は、呼び出しアプリケーションプログラム３２またはサービス３４に制御を戻す。

【００４８】図５Aは、本発明の呼び出し実行プロセスを示しているフローチャートである。スタート状態から開始して、プロセスＳ200は、プロセスステップＳ210に進み
、そこにおいて、呼び出しプログラムが、アクセスドライバ４６に、それが実行
を開始したいＢＩＯＳファンクションのアドレスを与えることによって、ＢＩＯ
Ｓファンクションを呼び出す。プロセスＳ200は、次にプロセスステップＳ220へ
進み、そこにおいて、アクセスドライバ４６は、Ｉ／Ｏマネージャ４２から、Ｉ
ＯＣＴＬ命令を介してＢＩＯＳファンクションにディスパッチ呼出しを受け取る
（図２を参照のこと）。プロセスＳ200は、次にプロセスステップＳ230へ進み、
そこにおいて、アクセスドライバ４６は、エントリポイントアドレスの範囲チェ
ックを行う。特に、アクセスドライバ４６は、エントリポイントアドレスが、サ
ービスディレクトリヘッダを除く、ＢＩＯＳシャドウ領域にマップされたアドレ
スの範囲内にあるか否かを判別する。そうでない場合には、アクセスドライバ４
６は、開始仮想アドレスが、物理メモリから仮想メモリまでマップされたアドレ
スの範囲内にないことを示す。これは、フラグの使用によって示される。範囲チ
ェックがうまくいっている場合、プロセスＳ200はプロセスステップＳ240へ進み
、そこにおいて、アクセスドライバ４６は、呼ばれたＢＩＯＳファンクションを
実行する。次に、プロセスＳ200は終わる。

【００４９】図５Bは、図５AのプロセスステップＳ240の詳細を示しているフローチャートである。スタート状態から始まり、プロセスＳ240は、プロセスステップＳ242に
進み、そこにおいて、アクセスドライバ４６は、Ｉ／Ｏマネージャ４２からのプ
ログラムによって以前に指定されたシステムバッファにレジスタスタックをつく
る。プロセスＳ330は、次にプロセスステップＳ244へ進み、そこにおいて、アク
セスドライバ４６は、実行されるＢＩＯＳファンクションのアドレスを保持する
レジスタスタックにポインタを提供する。プロセスＳ240は、次にプロセスステップＳ246へ進み、そこにおいて、Ｉ／Ｏマネージャ４２からの呼出しプログラムは、仮想メモリにマップされるような物理アドレスを使用して、開始アドレス
がポインタにより示されているファンクションを呼び出して実行する。そして、
プロセスＳ240は終わる。

【００５０】アクセスドライバ４６のＩＯＣＴＬ＿ＢＩＯＳ＿ＥＸＥＣファンクションのユ
ーティライゼーションの一例を提供する。まず最初に、アプリケーションプログ
ラム３２またはサービス３４は、命令ＩＯＣＴＬ＿Ｌｏｃａｔｅを使用してアク
セスドライバ４６に呼出しを行う。アクセスドライバ４６により戻されるデータ
は、ＢＩＯＳシャドウ領域ベース仮想アドレス、ＢＩＯＳシャドウ領域ベース仮
想アドレスからのＢＩＯＳサービスディレクトリオフセット、ＢＩＯＳデータ領
域ベース仮想アドレスを含む。

【００５１】次に、以下のステップは、ＢＩＯＳサービス、そのエントリポイント、長さ、
アドレスオフセットの存在を判別するために使用される。Ｉ／Ｏマネージャ４２
からの呼び出しプログラムは、最初にＩＯＣ＿ＥＸＥＣ１などのレジスタ構造に
対してメモリを割り当て、次に、ＩＯＣＴＬ＿Ｌｏｃａｔｅファンクションによ
って与えられる仮想アドレスを有する構造のｂｉｏｓＦｕｎｃｔｉｏｎフィール
ドに充填する。他のレジスタ値が、次のように満たされる。ＢＩＯＳサービスを
識別している４バイトのＡＳＣＩＩストリングは、ｅａｘレジスタへとロードさ
れ、ゼロはｅｂｘレジスタへとロードされる。

【００５２】次に、呼び出し側は、ＩＯＣＴＬ呼出しのためのシステムバッファにコピーさ
れたＩＯＣ＿ＥＸＥＣ１構造のコンテンツを有するアクセスドライバ４６のＩＯ
ＣＴＬ＿ＢＩＯＳ＿Ｅｘｅｃファンクションを呼び出す。次に、ＢＩＯＳファン
クションが実行される。アクセスドライバ４６のＩＯＣＴＬ＿ＢＩＯＳ＿Ｅｘｅ
ｃファンクションは、戻り、ｅａｘ、ｅｂｘ、ｅｃｘ、ｅｄｘ用のレジスタ値は
、それぞれサービスディレクトリからの反応を含む。次に、Ｉ／Ｏマネージャ４
２の呼び出しプログラムは、サービスディレクトリから戻る情報を取り、システ
ムバッファのｂｉｏｓＦｕｎｃｔｉｏｎエントリポイントと構造とを作成する。
次に、それは、アクセスドライバ４６のＩＯＣＴＬ＿ＢＩＯＳ＿Ｅｘｅｃファン
クションを使用して、ＢＩＯＳファンクションを呼び出す。戻されたデータは、
同じＩＯＣ＿ＥＸＥＣ１構造においてパスされる。

【００５３】図４Ａ、図4Ｂ、図５Ａ、図5Ｂに示すプロセスの例を付録Ｄ1―Ｄ3に示す。特
に、付録Ｄ1は、クラスドライバ４６を介してＢＩＯＳファンクションを呼ぶ際に使用される、アプリケーションプログラム３２、サービス３４、またはクラス
ドライバ４０用の典型的なソースコードを示す。付録Ｄ2およびＤ3は、アクセス
ドライバ４６用の典型的なソースコードを示す。付録Ｄ2は、シャドウ領域のＢＩＯＳファンクションを実行するための典型的なソースコードを示す。その一方
で、付録Ｄ3は、レジスタスタックを作成するとともに、ＢＩＯＳファンクションを実行するためのエントリポイントを呼ぶための典型的なソースコードを示す
。

【００５４】本発明を使用すると、仮想メモリサブシステム物理メモリのコンテンツにアク
セスして実行する装置及び方法が提供される。この装置及び方法は、メモリおよ
び入出力動作のための増加したアドレス指定機能を容易にし、更に、物理メモリ
空間のプロセッサ命令の実行を許可する。本発明は、特定の好ましい実施例に関して記載したが、当業者に明らかな他の
実施例も、本発明の範囲内である。したがって、本発明の範囲は、以下に続く請
求項のみによって定義されるものである。

【図面の簡単な説明】

【図１】図１は、本発明の装置および方法が使用される典型的なプロセッサシステムの
システムブロック図である。

【図２】図２は、本発明の装置および方法を使用するオペレーティングシステムの構造
を示している全体的な機能ブロック図である。

【図３】図３は、本発明の原理に従って提供されるようなアクセスドライバ４６の初期
化プロセスを示しているブロック図である。

【図４Ａ】図４Ａは、本発明の初期化プロセスの一実施例を示しているフローチャートで
ある。

【図４Ｂ】図４Ｂは、図４ＡのプロセスステップＳ１１０の詳細を示しているフローチャ
ートである。

【図４Ｃ】図４Ｃは、図４ＡのプロセスステップＳ１３０の詳細を示しているフローチャ
ートである。

【図５Ａ】図５Ａは、本発明の実行プロセスを示しているフローチャートである。

【図５Ｂ】図５Ｂは、図５ＡのプロセスステップＳ２４０の詳細を示しているフローチャ
ートである。

【付録Ａ】

付録ＡＷｉｎｄｏｗｓＮｔ４．０用ＢＩＯＳパワー管理サービスはしがき４関連文書４用語４アーキテクチャの概要５ＢＩＯＳ３２サービス・ディレクトリの変更５ＢＩＯＳ３２サービス・ディレクトリ・ヘッダ５ＢＩＯＳサービス・ディレクトリ６３２−ビットＢＩＯＳパワー管理サービス・インターフェース７コーリング・パラメータ７３２−ビットＡＰＭとの相違８ソフトウエア要件９開発ソフトウエア要件９ソフトウエア要件９はしがきこの文書は、３２ビットＢＩＯＳパワー管理サービス・インターフェース（Ｂ
ＰＭＳＩ）用インターフェースを提供する。このインターフェースは、ＡＰＭを
認識するアプリケーションに対してパワー管理サービスを提供する、Ｗｉｎｄｏ
ｗｓＮＴパワー管理カーネル・ドライバによって使用される。用語ＡＭＰＢＩＯＳＡＰＭ仕様（現在改訂レベル１．２）に準拠するパワー管理機能を備えるシス
テムＢＩＯＳ。カーネル・モードＮＴシステム・コードが走る特権プロセッサ・モード。カーネル・モード・ス
レッドは、全てのＩ／Ｏおよびシステム・メモリにアクセスすることができる。パワー管理カーネル・ドライバ（ＰＭドライバ）サービスのために、ＢＩＯＳＲＯＭ、ＢＩＯＳデータ・エリア、および３２
ビット・サービスへのアクセスを与える。パワー管理サービス（ＰＭサービス）アプリケーションおよびその他のドライバにパワー管理サービスを提供する。
パワー管理カーネル・ドライバ（ＰＭドライバ）が提供するインターフェースを
用いて、それらの要求をＢＩＯＳパワー管理サービス・インターフェースへのク
エリに変換する。ＰｏｗｅｒＰＡＬシステムおよびデバイス・パワー管理機構に対するシステム・レベルのアクセ
スを与えるＰｈｏｅｎｉｘのＡＰＭＢＩＯＳ拡張版。システム・アイドルＰＭサービスがアプリケーション・レベルにおいて最少処理を検出した状態。
この状態では、アイドル優先度で走るスレッドのみが実行され、上位優先度クラ
スで走るいずれかのスレッドによって先取りされる。ユーザ・モードアプリケーション・コードが走る非特権プロセッサ・モード。ユーザ・モード
・スレッドはＩ／Ｏおよびシステム・メモリにアクセスすることはできない。アーキテクチャの概要ＷｉｎｄｏｗｓＮＴパワー管理に対応するＢＩＯＳの拡張は次の２つの部分
から成る。（ａ）ＢＩＯＳ３２サービス・ディレクトリの変更。ＰＭドライバがＢＩＯＳパ
ワー管理サービス・インターフェースに対するエントリを発見することを可能に
するエントリを追加した。（ｂ）ＡＰＭ３２ビット・インターフェースを模した新たな３２ビットＢＩＯＳ
パワー管理サービス。多少の相違があり、それを以下に記す。新たなインターフ
ェースは、安全度を増しＷｉｎｄｏｗｓＮＴに一層適した０：３２コーリング
方法を提供する。ＰＭカーネルがＢＩＯＳサービスを使用する場合、以下のステップを実行しな
ければならない。１．ＢＩＯＳ３２サービス・ディレクトリ・ヘッダを見つける。２．ＢＩＯＳ３２サービス・ディレクトリ・コーリング・インターフェースをコ
ールし、３２ビットＢＩＯＳパワー管理サービス・インターフェース・エントリ
・ポイントを指定する。３．３２ビットＢＩＯＳパワー管理サービス・インターフェース・エントリ・ポ
イントをコールし、ＡＰＭ接続を求める。ＢＩＯＳ３２サービス・ディレクトリの変更３２ビットＢＩＯＳサービス・ディレクトリは、ＰｈｅｎｉｘＢＩＯＳ内に
ある既存構造であり、３２ビット保護モード・アプリケーションまたはオペレー
ティング・システムが、特定の３２ビット・サービスに対するエントリ・ポイン
トを見つけることを可能にする。この仕様は、新たな標準的な３２ビットＢＩＯ
Ｓサービスを定義する。ＢＩＯＳ３２サービス・ディレクトリは、ＰＭドライバが検出可能な固定構造
、および特定のサービスに対するアドレスを返す１つの関数から成る。ＢＩＯＳ３２サービス・ディレクトリ・ヘッダＢＩＯＳ３２サービス・ディレクトリを実現するＢＩＯＳは、物理アドレス範
囲０Ｅ００００ｈ−０ＦＦＦＦＦｈ内のどこかに、特定の隣接１６バイト・パタ
ーンを埋め込まなければならない。このパターンは、パラグラフで位置合わせさ
れていなければならない（即ち、１６バイトの境界で始まらなければならない）
。このパターンは、ＢＩＯＳ３２サービス・ディレクトリ・ヘッダとして知られ
ている。ヘッダは６つの個別フィールドで構成されている。以下の表に各フィールドに
ついて説明する。

【表５】ＢＩＯＳ３２サービス・ディレクトリのクライアントは、最初にヘッダを突き
止めてその存在を判定しなければならない。これは、パラグラフずつ進めながら
０Ｅ００００ｈないし０ＦＦＦＦ０ｈを走査し、各パラグラフの最初の４バイト
においてサインの一致（”＿３２＿”）を探す。サインが検出されたなら、クラ
イアントはヘッダ内の全バイトのチェックサムを求める。（パラグラフ内のヘッ
ダ長は、オフセット９ｈで分かる）。ヘッダ内の全バイトを互いに加算し、その
結果が０ｈにならなければならない。チェックサムが有効な場合、３２ビット・
エントリ・ポイント・フィールドは、ＢＩＯＳ３２サービス・ディレクトリ・コ
ーリング・インターフェースのアドレスとして使用することができる。ヘッダが
見つからない場合、ＢＩＯＳ３２サービス・ディレクトリはそのプラットフォー
ム上には存在しないことになる。ＢＩＯＳ３２サービス・ディレクトリ・エントリ・ポイント、ならびにそれに
関連するコードおよびデータは、４Ｇｂ物理アドレス空間内のどこに位置しても
よい。しかしながら、物理的に隣接しており（即ち、ＲＯＭまたはＦＬＡＳＨ空
間に送出される）、２ページ内に納まる（即ち、３ページには跨がらない）こと
を保証する。ＢＩＯＳサービス・ディレクトリＢＩＯＳ３２ビット・パワー管理サービス・インターフェースへのエントリ・
ポイントを得るためには、ＰＭドライバは、以下のパラメータを用いてＢＩＯＳ
サービス・ディレクトリをコールしなければならない。ＩＮ：ＥＡＸ ”ＮＴＰＭ”または0x4E54504D ＥＢＸ０ｘ００００００００ＯＵＴ：ＡＬエラー・コード：0x00＝なし、0x81＝サービス存在せずＥＢＸ３２ビットパワー管理サービス・コードの基底アドレス。ＥＣＸ３２ビットパワー管理サービス・コードの長さ(ＥＢＸより) ＥＤＸ３２ビット・パワー管理サービス・コード・エントリ・ポイントのオフセット（ＥＢＸより）３２ビット・パワー管理サービス・コード・エントリ・ポイントのエントリ・
ポイントはＦＡＲ（即ち、セグメントおよびオフセット双方をスタック上にプッ
シュする必要がある）である。ＣＳ：基底アドレスは、エントリ・ポイントを含むページの（４ＫＢ）ページ・
アドレス以下でなければならない。例えば、エントリ・ポイントが０ＦＦＦ８１
２３４ｈであるとすると、基底アドレスは０ＦＦＦ８１０００ｈ以下でなければ
ならない。このリミットは、基底アドレスにこのリミットを加算すると、エント
リ・ポイントを含むページに続く（４ＫＢ）ページ上の最後のアドレスに等しく
なるようにしなければならない。例えば、エントリ・ポイントが０ＦＦＦ８１２
３４Ｈであるとすると、基底アドレスにリミットを加算した結果は０ＦＦＦ８２
ＦＦＦｈ以上でなければならない。単純に言えば、基底アドレスおよびリミット
は、エントリ・ポイントを含むページおよび次のページ双方に「跨がらなければ
」ならない。セグメント・コードは、１００ｂ（コード、実行のみ）または１０１ｂ（コー
ド、実行／リード）でなければならない。しかしながら、サービス・ディレクト
リのインプリメンタは、ＣＳコード・セグメントへのリード・アドレスを引き受
けることができない。システム・バイトは、１（非システム・セグメント）でな
ければならない。記述子特権レベル（ＤＰＬ）を０とすることを推奨する（ＣＳ
記述子ＤＰＬは、現特権レベル即ちＣＰＬとなる）。ＣＰＬが０でない場合、Ｏ
Ｓは、リング０特権命令に対して、トラップおよび仮想化サービスを提供しなけ
ればならない。また、このフィールドのＥＦＬＡＧＳ（章０を参照）内のＩＯＰ
Ｌフィールドに対する依存性にも注意すること。デフォルト・サイズ・ビットは１（３２ビット）でなければならない。ＤＳ：基底アドレスはＣＳ基底アドレスに等しくなければならない。リミット
はＣＳリミット以上でなければならない。セグメント・コードは、０００ｂ（データ、リードのみ）または００１ｂ（デ
ータ、リード／ライト）でなければならない。しかしながら、サービス・ディレ
クトリのインプリメンタは、ＤＳコード・セグメントへのライト・アドレスを引
き受けることができない。システム・バイトは、１（非システム・セグメント）
でなければならない。記述子特権レベル（ＤＰＬ）は、ＣＰＬ（章０のＤＰＬフ
ィールドを参照）以上でなければならない。ＳＳ：セグメント・コードは、０１１ｂ（データ、リード／ライト、下方展開）
または００１ｂ（データ、リード／ライト、上方展開）でなければならない。シ
ステム・バイトは、１（非システム・セグメント）でなければならない。記述子
特権レベル（ＤＰＬ）は、ＣＰＬ（章０のＤＰＬフィールドを参照）以上でなけ
ればならない。デフォルト・サイズ・ビットは１（３２ビット）でなければなら
ない。粒度ビットは１（４Ｋｂ）でなければならない。前述の設定値は、少なくとも４ｋｂのスタック・サイズを確保することに注意
すること。少なくとも１ｋｂの使用可能な未使用スタックがあることを確保する
のは、コール側の責任である。ページング：ページングは、イネーブルしてもしなくてもよい。ページングをイ
ネーブルする場合、ＣＳおよびＤＣセレクタによって記述されるアドレス空間は
、線形的に隣接していなければならない。即ち、ＲＯＭまたはＦＬＡＳＨ内で見
出されるコーリング・インターフェースの元々の物理的隣接性を保存しなければ
ならない（コーリング・インターフェース・コードおよびデータは、場所に依存
せず、ＥＩＰに関係するように書かれる）。ＩＯＰＬ：コーリング・インターフェースがＩ／Ｏ命令を実行するためには、Ｅ
ＦＬＡＧＳ内のＩ／Ｏ特権レベル（ＩＯＰＬ）フィールドは、ＣＰＬ（章０のＤ
ＰＬフィールドを参照）以上でなければならない。その他：ＢＩＯＳデータ・エリア、拡張ＢＩＯＳデータ・エリア、および固定位
置ＲＯＭデータ・テーブルは、ページングのために、実行コードの使用に供する
と仮定することはできない。ＢＤＡにアクセスするには、コール元が与えるポイ
ンタを用いればよい。３２ビットＢＩＯＳパワー管理サービス・インターフェース一般に、３２ビットＢＩＯＳ管理インターフェースは、３２ビットＡＰＭエン
トリ・ポイントと同じ機能性を与える。コーリング・パラメータを受け渡す方法
、およびあるＡＰＭ接続機能に対応する方法という２つの領域に相違がある。コーリング・パラメータＡＰＭ３２ビットインターフェースはＣＰＵレジスタ内の全てのパラメータを
受け渡す。ＢＩＯＳパワー管理サービス・インターフェースは、スタック上のパ
ラメータを受け渡す。同等のＣ−型の宣言では、以下のようになる。

【外９】実際のＡＰＭ関数およびそのビヘービャは、対応するレジスタ・フィールドに
書き込まれた値によって決定される。ｐＢＤＡフィールドは、カーネル・ドライ
バがＢＩＯＳデータ・エリアをマップした仮想アドレスへのポインタであるので
、サービス・エントランスによってこれにアクセスすることができる。エラーが発生した場合、ｒｅｇＦｌａｇｓのビット０は１となり、エラー・コ
ードがｒｅｇＥＡＸのビット８−１５に入る。それ以外の場合、ｒｅｇＦｌａｇ
ｓのビット０は０であり、ｒｅｇＥＡＸのビット８−１５も０である。エラー・
コードは、ＡＰＭ１．２仕様において見られるものと同一である。ソフトウエア要件開発ソフトウエア要件ＰＭサービスを構築するには、以下のソフトウエア開発ツールが必要となる。・ＭｉｃｒｏｓｏｆｔのＭＡＳＭ６．１１ｃアセンブラ・コードをデバッグするためのＰｈｅｎｉｘＰｈＤｅｂｕｇソフトウエア要件ＰＭサービスは、以下の環境で実行する必要がある。・ＷｉｎｄｏｗｓＮＴ４．０・ＰｏｗｅｒＰＡＬに対するＮＴＢＩＯＳインターフェースに対応するＰ
ｈｅｎｉｘＮｏｔｅＢＩＯＳを備えたシステム。・システムにインストールされたＰＭドライバ移植に関する変更次の章では、Ｃｏｒｅ、Ｍｉｓｅｒおよびチップセット・コードにおいて修正
されたファイルについて説明する。また、通常のＢＩＯＳを移植しＮＴ対応を含
ませるために必要な変更についても説明する。

【付録Ｂ】

付録ＢＰｈｏｅｎｉｘＰｈｌａｓｈＮＴウインドウズＮＴ用フラッシュＲＯＭプログ
ラミングユーティリティー付録Ｂに言及されているフェニックスＡＤドライバは、アクセスドライバ４６
である。 1.0 概要 5 ハードウェアにアクセスするためＣドライバを用いる。 5 2.0 オペレーションモード 7 2.1 Ｗｉｎ32コンソール 7 2.3 完了コード 11 2.4 デバイス依存モジュール 12 2.4.1. 自動検出 13 2.4.2 ゼロ 13 2.4.3 消去 13 2.4.4 プログラム 13 2.5 サポートされるデバイス 13 3.0 PLATFORM．ＤＤＬの詳細 15 3.1 ファイル書式 15 3.2 ファイルヘッダ書式 15 3.3 ブロックテーブル書式 17 3.3.3 多重フラッシュブロック 18 3.3.4 ブートブロック及びESCD記憶の処理 18 3.3.5 ブロックテーブルの例 19 3.4 PLATFORM．ＤＤＬ関数 19 3.4.1 関数EnableFlash（） 20 3.4.2 関数DisableFlash（） 20 3.4.3 関数BeginFlash（DWORD Block_Index） 21 3.4.4 関数EndFlash（DWORD Block_Index） 21 3.4.5 関数GetBlock（DWORD Index, DWORD Buffer_Address） 21 3.4.6 関数CmdLine（char far *szOptions） 22 3.4.7 関数AutoSense（） 22 3.4.8 関数IsFlashable（char far*szErrorMsg） 23 3.4.9 関数Reboot（） 23 3.4.10 関数CheckSum（） 23 3.4.11 関数GetBIOSFileSize（） 23 3.4.12 関数GetManufactID（） 24 3.4.13 関数GetPartlD（） 24 3.4.14 関数GetFlags（） 24 3.4.15 関数GetlmageBuf（） 24 3.4.16 関数GetMfglDAddr（） 24 3.4.17 関数GetPartlDAddr（） 25 3.4.18 関数GetRetryCount（） 25 3.4.19 関数GetblockTableSize（） 25 3.4.20 関数GetpartTypesSize（） 25 3.4.21 関数GetBlockTable（） 25 3.4.22 関数GetpartTypes（） 26 3.4.23 関数GetDLLVersion（） 26 3.4.24 関数GetROMFileName（） 26 3.4.25 関数GetDDLFuncDefine（） 26 4.0 BIOS．ROMの詳細 27 5.0 一般的実装の指針 28 付録B1 − 将来の強化 29 キーボードLEDを伴う完了コード 29 付録B2 − PHLASHNT.H 完了及びエラーコード 30 付録B3 − PLATFORM.DDLサンプルソースコード 31 PLATFORM.CPP 311.0 概要 PhoenixPhlashフラッシュユーティリティーは、AT互換性システム内で、フラッシュROM中にBIOS画像をプログラムするために使用されるものである。ユーティリティーは以下のファイルで構成されることになる： PHLASHNT.EXE − フラッシュROMをプログラムするために使用される PLATFORM.DLL − プラットフォーム依存機能を実行するために使用される BIOS.ROM − フラッシュROM中にプログラムされるべき現在のBIOS画像本付属書は、PHLASHNT.EXEプログラムに関する機能性の詳細な説明を提供する
ものである。PLATFORM.DLL及びBIOS.ROMはプラットフォームに特定的なものであ
ることから、本書中では、これら2つのファイルの一般的な書式のみが網羅されている。 PhoenixPhlashは、Win32のコンソールアプリケーションとして実行されるもの
である。この設計プロジェクトについては、柔軟性、適合性及びサポート性に高い優先
度が与えられている。PHLASHNT.EXEを修正することなく数多くの異なるプラット
フォーム及び環境設定をサポートすることができるようにPLATFORM.DLLファイル
には可能な限り多くのカスタム化能力が組み込まれる予定であることから、Phoe
nixpPhlashは、単一のフラッシュROM部分を伴う複数のプラットフォーム、並びに多数のフラッシュROMを伴うプラットフォームをサポートすることになる。ブートブロックデバイス及び任意の多重フラッシュ可能領域構成を伴うデバイスを
含め、１Mビットから４Mビットあるいはそれ以上のフラッシュROMが収容される。サポートされている各部分について、特定のフラッシュROM部分に特定的なすべてのコード（例えば、Intel28Fxxxx）が、PHLASHNT.EXEモジュールの一部とな
る。プラットフォームに特定的なすべてのコードおよびパラメーター（例えば、
フラッシュイネーブルコード及びフラッシュROMアドレスレンジ）が、PLATFORM.
DLLモジュールの一部となる。 PheonixPhlashユーティリティーの主モジュール、PHLASHNT.EXEは、プラットフォームとは独立したすべてのコードを包含することになる。これは、ユーザー
インターフェースコード、PLATFORM.DLLファイルをロードし確認するためのコー
ド、フラッシュデバイスをプログラムするためのコードのプラットフォーム独立
部分を含むことになる。 PHLASHNT.EXEは、MicrosoftC++V4.2またはそれ以降のもの使用して生成された
、Win32で実行可能なファイルである。ハードウエアにアクセスするためのCドライバの使用 PHLASHNT.EXEは、I/Oポートにアクセスするため；BIOSデータ及びコード部域にアクセスするため；及びBIOS32サービスを実行するためにウインドウズNTユー
ザーモードアプリケーションをイネーブルするべくPhoenixADドライバと組み合わさって作動するCドライバC++クラスを用いる。Cドライバクラスは、アプリケーションプログラムとPhoenixADドライバとの間に単純かつ柔軟性のあるインターフェースを提供する。 Cドライバは、ユーザーモードアプリケーションプログラムに対して下記の機能を提供するためにPhoenixADドライバと組み合わさって作動する。 I/Oポートにアクセスする。 BIOS32サービスを実行する。 BIOS画像にアクセスする。 BIOSデータ部域にアクセスする。システムのReal Time Clockを読取る。 Cドライバクラスは、ウインドウズNTアプリケーションとPhoenixAdドライバの
間の薄いラッパーインターフェースとしての役割を果たす。これはドライバへの
インターフェースをカプセル封じし、アプリケーション及びカーネルドライバ設
計の両方に柔軟性を提供する。将来の互換性を確保するために、PHLASHNT.EXEは、PhoenixADドライバを直接呼び出さず、その代わりに、Cドライバクラスの中の方法を呼び出す。2.0 オペーレーションモード 2.1 Win32コンソール PHLASHNT.EXEは、ウインドウズNTのウインドウからスタートし、この後に（も
しあれば）オプションのコマンドラインフラグが続くことになる。コマンドラインフラグには以下のものが含まれる予定である（大文字及び小文
字の両方が許容可能）：／Ａ AUTODETECT OFF− 部品からIDを読取らない。デフォルトによって、プログラムは、メーカーID及び部品IDからから読取られたIDが、PLATFORM.DLLファイル内で規定されたIDと整合することを確認し、2つのIDが異なる場合は部品から読取られたIDが使用される。これによって、いくつかの異なる部品について２つのファイルのいずれかを修正することなく同じPLATFORM.DLL及びBIOS.ROMを使用することが可能になる。このフラグが未設定の場合、IDは部品から「読取り可能」であると仮定される。このフラグが設定済みの場合、部品からのIDは使用されず、その代わりに、PLATFORM.DLL内に規定されている値が使用される。／Ｂ＝filename BINARY FILE− デフォルトプラットフォームにに特定的なバイナリーファイルをオ−バーライドする。このオプションは、フルパス仕様が必要とされる場合、及び／又はバイナリーファイルがPLATFORM.DLL以外の名前を有している場合に必要とされる。／ＢＵ＝filename BACKUP− 消去前に、BIOS画像の先行バージョンをfilenameファイル内にセーブする。Filenameはオプションである。即ち、特定されない場合は、先行画像がBIOS.BAK中に記憶される。数多くのBIOSのバージョンが、シャドーメモリーや圧縮解除といったプラットフォーム依存機能を使用することから、ファイル内に書き込まれないうちにBIOS画像を検索するのにPLATFORM.DLL 内でプラットフォーム依存コードを使うことが往々にして必要である。／Ｃ COMS UPDATE− Flashが更新された後にCMOSチェックサムをクリアする。AUTO_UPDATE機能が新しいBIOS画像中に導入された場合、BIOSは自動的にすべてのCMOSフィールドを次のブートでそのデフォルト値にセットする。AU TO_UPDATE機能がロードされない場合、BIOSは次のブートでCMOSチェックサムエラーメッセージを表示し、ユーザーに対してSetupを実行して手動で機械を再構成するべくF2ボタンを押すようプロンプトする。／ＣＳ CHECKSUM BIOS ROM− BIOS ROM画像上でチェックサムを計算する。チェックサムがゼロでない場合、あるいはオプションのPLATFORM.DLL関数CheckSum が機能しない場合、プログラムはエラーメッセージで終了する。／Ｈ USAGE− プログラム名、バージョン、著作権及びヘルプスクリーンを表示する。このオプションのためには／？も同様に使用することができる。／Ｉ IMAGE SIZE VERIFICATION− ＲＯＭ画像ファイルサイズがフラッシュ部分のサイズと同じ場合にのみ行なわれる。／ＭＯＤＥ＝ｎ OPERATION− PHLASHNTのためのオペレーティングモードを選択する。現在は、下記のオペレーティングモードがサポートされている。０ BIOS画像のみ更新する（正規オペレーティングモード）。このモードでは、PHLASHNTは現行のBIOS画像を新しい画像と置換する。BIOSシステム内のDMI情報は維持される。これはデフォルトモードであり、／MODEコマンドラインフラグが存在しない場合又はオペレーティングモードが特定されいてない場合に選択される。１ DMI情報のみを更新する。このモードでは、PHLASHNTは、Flashに対するDMIコマンドラインフラグを経由して特定されたストリングの書き込みを行う。新しいDMIストリングがコマンドライン上で特定されない限り、 BIOSシステム内のDMI情報は維持される。２ BIOS及びDMI情報の両方を更新する（システムDMIストリングを保存する）。このモードでは、PHLASHNTは、現行のBIOS画像の置換及びFlashに対するDMIコマンドラインフラグを経由して特定されたストリングの書き込みの両方を行う。新しいDMIストリングがコマンドライン上で特定されない限り、BIOSシステム内のDMI情報は維持される。３ BIOS及びDMI情報の両方を更新する（システムDMIストリングをリセットする）。このモードでは、PHLASHNTは、現行のBIOS画像の置換及びFlas hに対するDMIコマンドラインフラグを経由して特定されたストリングの書き込みの両方を行う。BIOSシステム内のDMI情報は、新しいBIOS ROMからのDMIストリング及び／又はコマンドライン上で特定された新DMIストリングで置換される。これらのオプションは、機密保護上の理由からヘルプ（／Ｈ）オプションでは
表示されない。／N NEW（異なるもの）− BIOS ROMの異なるバージョンについてのみ行なわれる。BIOSバージョン及び構築データと時間を含むBCPSYSでのデータ構造が、BIOS.ROMファイル内の対応する構造と同一である場合には、プログラムはフラッシングなく終了する。／Ｏ OVERRIDE PLATFORM.DLL OPTIONS− PLATFORM.DLL内のすべてのフラグ設定をディスエーブルする。このスイッチがない場合、PLATFORM.DLL内で設定されたオプションは、コマンドライン上で特定されたオプションと組合される。このスイッチが使用される場合は、コマンドラインオプションのみが使用される。／Ｐ PRODUCTION− フラッシングのスピードを最大にする。すべてのユーザーフィードバックは、最小限に削減される（音なし、又は画面更新）。これが生産環境内の部分のフラッシュに必要な時間を短縮するために使用される。最終的な成功／失敗のみが報告される。／ＰＮ BIOS PART NUMBER CHECK− BIOS.ROM内のBIOS部品番号が現行BIOS内の部品番号と同一の場合にのみ行なわれる。／ＰＦ＝“list of options” プラットフォーム依存モジュールPLATFORM.DLLに移行させられるべきコマンドラインオプション。一部のプラットフォームでは、コマンドラインオプションをプラットフォーム依存手続に移行させることが望ましい場合がある。これは関数CmdLine（）を経由して行われる。CmdLine（）アドレスが非ゼロであり、かつこのコマンドラインオプションが存在する場合、等号の直後のストリングはPLATFORM.DLLに移行させられることになる（ストリングがスペースを含む場合は、ストリングを2重引用符でくくる）。／Ｒｎ RETRY− １つのブロックのフラッシングに失敗した場合、アボートせずにｎ回再試行する。PLATFORM.CPP内でPsiRetryCountを望まれる再試行計数でセットすることによって危機モードで/Rnオプションを使用することができる。／Ｓ SILENT− オーディオフィードバックのない消音オペレーション／Ｖ VERIFY− 各ブロックがプログラミングされた後、フラッシュ部分アドレススペース内のデータは、BIOS.ROMファイル内のデータと比較される。不一致があればそれが報告され、（プロンプトに対する応答に応じて）プログラムが同一ブロックのプログラミングを再試行するかあるいはシステムが停止するかのいずれかが起きる。フラッシュメモリーが消去された後にチェックが行われるために、システムは非常に不安定になり、ユーザーに適正に通知して回復することが不可能になることがある。／Ｚ ZERO BLOCKS− 消去前のゼロフラッシュブロック filename BIOS ROM画像ファイル名。先行バックスラッシュのないいずれかのコマンドラインオプションはすべて、BIOS ROM画像ファイル用のファイル名として解釈されることになる。ROM BIOS画像用のフルパスを特定するのに必要な場合及び／又はROM BIOS画像ファイルがBIOS.ROMと異なっている場合にのみファイル名が要求される。＠filename 応答ファイル。上述のコマンドラインオプションのうちの任意のものを、応答ファイル内に置くことができる。PHLASHNTはファイルを読取り、あたかもコマンドライン上に入力されたかのようにオプションを処理する。オプションは、単一のライン上又は個別のライン上に置くことができる。各ラインは、最高で1024文字の長さをもつことができる。下記のコマンドラインフラグは、Phoenixデスクトップマネージメントインターフェース（DMI）を通じて後日検索する目的でFlashに対して情報を書き込むた
めに使用される。標的BIOS画像がDMIインターフェースをサポートしていない（D
MI BCP構造を導入させていない）場合又はPHLASHNTオペレーションモードがBIOS
のみの場合（上記を参照）DMIコマンドラインフラグは無視される。すべてのフラグは、書式／DxxStringを有しており、ここでxxは特定のDMIスト
リングを識別する１つ又は２つの文字である（下記を参照）。DMIコマンドラインフラグはオプションである。即ち、一定のあたえられたDMIコマンドラインフラグが特定されない場合、PLATFORM.DLL内でデフォルトストリングが特定されな
い限り対応するDMIストリングバッファーの先行するコンテンツは修正されない。この場合、PHLASHNTは常にデフォルトストリングを対応するDMIストリングバッファーに書き込む。DMIコマンドフラグがStringフィールドなしで特定される場合、対応するDMIストリングバッファーはクリア（空ストリングにセット）される。Stringは印刷可能なASCII文字のみを含むことができる。Stringがスペースを含む場合は、このStringを引用符でくくらなければらない。各DMIストリングの最大な長さは、プラットフォームに特定的なものである。移行させられたス
トリングが対応する標的バッファーよりも長い場合、PHLASHNTはエラーを戻す。
現在サポートされているのは下記のDMIファイルである。これらのオプションは、機密保護上の理由からヘルプ（/H）オプションにより表示されない。 /DSS・String システムの通し番号ストリングを特定する。 /DMS・String システムメーカー名ストリングを特定する。 /DPS・String システム製品（モデル）識別ストリングを特定する。 /DVS・String システムバージョンストリングを特定する。 /DSM・String マザーボード通し番号ストリングを特定する。 /DMM・String マザーボードメーカー名ストリングを特定する。 /DPM・String マザーボード製品（モデル）識別ストリングを特定する。 /DVM・String マザーボードバージョンストリングを特定する。 /DSC・String シャーシ通し番号ストリングを特定する。 /DMC・String シャーシメーカー名ストリングを特定する。 /DPC・String シャーシ製品（モデル）識別ストリングを特定する。 /DVC・String シャーシバージョンストリングを特定する。 /DO1・String OEMストリング１を特定する。 /DOｎ・String OEMストリングｎを特定する。システム及びシャーシスイッチは、DMIバージョン2.0でのみ入手可能である。下記に示されているコマンドラインスイッチのより古い形式は、元来DMI1.2用
であったもので、互換性目的のために維持されている。これらはそれぞれ/DSM、
/DMM、/DPM及び/DVMと等価である。 /DS・String マザーボード通し番号ストリングを特定する。 /DM・String マザーボードメーカー名ストリングを特定する。 /DP・String マザーボード製品（モデル）識別ストリングを特定する。 /DV・String マザーボードバージョンストリングを特定する。次に、フラッシュプログラムがPLATFORM.DLLをロードし、フラッシングのため
プラットフォームを準備するべくPLATFORM.DLL内のプラットフォーム依存関数En
ableFlash（）を呼び出す。PLATFORM.DLLは、BIOS ROM画像がメモリー内でロードされるべきメモリー領域を表示し、フラッシュデバイス用としてどのメモリー
領域を使用すべきかを表示することになる。メモリー領域は従来のメモリー内で
もあるいは拡張メモリー内でもよい。ROM画像がメモリー領域内にロードされた後に、デバイスプログラミングが開始する。プログラムすべきフラッシュROMの各ブロックについて、 1) PLATFORM.DLL内でBeginFlash（）が呼び出される。 2) PHLASHNT.EXE内の適正なフラッシュアルゴリズムが実行される。 3) PLATFORM.DLL内でEndFlash（）が呼び出される。このプロセスは、PLATFORM.DLL内で特定された各フラッシュブロックについて
反復される。こうして、単一プラットフォーム上の複数のデバイス、1つのデバイス内の複数のブロック及び各ブロックについてのブロック依存初期化／終了コ
ードが可能になる。これはまた、ブートブロックといったメモリ領域の自動セー
ブ及び回復も可能とする。フラッシングの間、進捗情報がユーザーに提示される。 1) 生産モードが選択されない場合、適正なメッセージウインドウがスクリーン上に表示され、これには時刻、ガスメータ型式の進捗インジケータ及びステータスラインメッセージが含まれる。 2) およそ毎秒1回ずつ、短いブザー音が鳴る。 3) 各ステップの開始及び完了時に適切なコードがデバッグポートに送られる
。ビデオは毎秒1回以上更新されることになる。サウンドは、およそ毎秒1回生成
される。製作環境内で進捗更新がデイスエーブルされる可能性があることに留意
されたい。フラッシングが完了した後、DisableFlash（）がPLATFORM.DLLファイルから実
行される。2つの異なるサウンドの内の一方がフラッシュプロセスの成功又は失敗を表示する目的で生成されることになる。ビデオが利用可能な場合、適切なメ
ッセージウインドウが表示される。短時間の休止の後にシステムは、再ブートさ
れる。 2.3 完了コードプログラムは数多くのステップを通して進行し、ユーザに対して各ステップで
の状態を報告する能力をもつことになるが、３つの主要段階のみが、サウンド及
びキーボードLEDコードにより識別される。これらの3つの主要段階とは以下のも
のである。 1) PLATFORM.DLLファイルを読み込みかつ点検する。 2) プラットフォームに特定的な初期化を実施する。 3) 部分をプログラミングする。プログラムが、フラッシングプロセスの主な３つの段階のいずれかを完了でき
なかった場合、プログラムは、プログラムがどの段階で不首尾であったかをユー
ザーに通知するべく異なるサウンドシーケンス及びキーボードLEDを使用する。プログラムのスタート時点で、キーボード上のCAPS_LOCK,NUM_LOCK及びSCROLL_L
OCKのLEDが点灯する。3つの段階の各々における不首尾は以下のとおり表示される。

【外１０】段階１− PLATFORM.DLLの位置決め以前に不首尾が発生。一番考えられる原因
は、PLATFORM.DLLファイル書式内のエラーである。システムは安定モードにあり
、BIOSにはいかなる変更も行われなかった、再ブートは必要とされない。段階2− プラットフォーム依存初期化の間の不首尾。システムは不安定であり、再ブートが必要とされる。BIOSにはいかなる変更も行われなかった。段階３− フラッシュメモリープログラミングの間の不首尾。システムは不安
定で、BIOSフラッシュメモリーは汚染されている。危機管理ディスケットでシス
テムを再スタートさせなければならない。プログラムは同様に、各ステップにおいてエラー検知も実行することになる。
PRODUCTIONオプションによって明らかにディスエーブルされたのでないかぎり、
プログラムの進捗につれて、これは、現在進行中のステップのステップ番号ある
いはエラーコードのうちの１つのいずれかをスクリーン及びデバッグポート上で
報告する。エラー及びプログラムステップについてのコード番号は、付属書のB2
においてさらに定義されている。フラッシュメモリー部分に何らかの変更が行われる前にエラーが検知された場
合、プログラムはユーザーに対する通知を試み、その後に適正なエラーメッセー
ジと共にPHLASHNTを退出することになる。フラッシュメモリーが一旦修正されて
しまった場合、エラーはプログラムの停止を発生させることになる。 2.4 デバイス依存モジュールサポートされているフラッシュメモリーの各タイプについて、以下のことを実
行する部品に特定的なモジュールが存在することになる。 1) 部品を識別してメーカーID及び部品IDを戻す。 2) フラッシュメモリーの１レンジをゼロにする（すべてのビットをゼロにセ
ットする）。 3) フラッシュメモリーの１レンジを消去する（すべてのビットを１にセット
する）。 4) フラッシュメモリーの1レンジをプログラミングする。 2.4.1 自動検出このモジュール中には、フラッシュメモリー部分からメーカーID及び部品IDを
読み取るのに必要なコードが存在することになる。IDを決定することができない
場合は、ゼロ復帰させられる。PLATFORM_DLLファイル内に関数AutoSense（）が備えられている場合は、内蔵式自動検知モジュールは使用されず、その代わりに
、備えられている関数AutoSense（）が使用されることになる。 2.4.2 ゼロプログラミング可能となる前にフラッシュメモリーをゼロにセットすることを
必要とする部品タイプがいくつか存在する。このモジュールには、メモリーレン
ジをゼロにセットするために必要なコードが存在することになる。 2.4.3 消去大半のフラッシュメモリー部分は、その部分をプログラミングできるようにな
る前にフラッシュメモリーをオール１にセットすることを必要とする。これらの
部分は往々にして、単一の書込みオペレーションでフラッシュメモリー全ブロッ
クの消去を可能にする。このモジュール内には、メモリーレンジを１にセットす
るために必要なコードが存在することになる。 PLATFORM.DLLファイル内でブロックディスクリプタが定義される場合、ディス
クリプタは、フラッシュメモリ中の各「消去可能」ブロックについて少なくとも
1つのディスクリプタが存在するような形でセットアップされなければならない。例えば、Intel28F004フラッシュメモリー中には、16kバイトのBOOTブロックが
１つ、８ｋバイトのPARAMETERブロックが２つ、96kバイトのMAINブロックが１つ
と128kバイトのEXTENDEDブロックが３つ存在する。7つのブロック各々が単一の書込みで消去可能であり、7つのブロック各々について少なくとも1つのデスクリ
プタが存在しなければならない。 2.4.4 プログラムこのモジュール中には、BIOS ROM画像からデータバイトを読取るため及びそれ
らをフラッシュ部分中にプログラミングするために必要なコードが存在すること
になる。 2.5サポートされるデバイス PHLASHNT．EXEによってサポートされるフラッシュメモリデバイスの初期セットは、以下の表に列記されている部品を含むことになる。各部品のタイプについて
、メーカと部品のID及び部品の説明が列記される。新しい部品が入手可能になる
ため、フラッシュアルゴリズムの新しいタイプが与えられるように（新規のAuto
Detect（）、Zero（）、Erase（）、及びProgram（）の機能）、PHLASHNT．EXE にさらなるモジュールを追加することが必要であろう。新しい部品のために、存
在するアルゴリズムの１つを使用することが可能であり、メーカID及び部品IDの
みを変更することが可能である場合、PLARTFORM．DLL fileにそれを示すことが
でき、PHLASHNT．EXEの変更は不要である（さらなる詳細についてはPartTypesの
項を参照のこと）

【表６】 3.0 プラットフォーム.DLL詳細このモジュールは、特別なプラットフォーム上のフラッシュデバイスをプログ
ラムするに必要なコードとパラメタに依存する全てのプラットフォームを含む。 3.1 ファイルフォーマット PLATFORM.DLLは、PLATFORM.CPP（マイクロソフトビジュアルC++4.2以降）を編
集することによって作られるウィンドウズDLLである。それは特定のプラットフォームデータと実行可能なコードを含む。PLATFORM.CPPファイルのサンプルソー
スコードはアペンディクスＢ３に含まれている。 PLATFORM.DLLのファイルバージョンはバージョン“NT 1.00”で始まる。バージョンはPLATFORM.DLLに含まれるszVersion変数の中に指定されている。 3.2 ファイルヘッダフォーマット PLATFORM.DLLファイルは以下に記されているフォーマットを有する。

【表７】 dwFileSize バイオスロムファイル中のバイト数 bManufactID 製造者ID bPartID パートID dwFlags オプションフラッグ。以下の値のコンビネーションでなければならない： FLAG_AUTOSENSEOFF パートからIDを読まない FLAG_BACKUP バックアップシステムバイオスロム FLAG_NEWBIOSONLY 64KがF000:0で同一ならフラッシュせず FLAG_PRODUCTION 最大速度（サウンドビデオオフ） FLAG_SILENT 音を発生させず FLAG_VERIFY フラッシュの後各ブロックをベリファイ FLAG_PLATFORMCMD プラットフォームオプションstrプレゼント FLAG_BIOSPARTNUM 同じバイオスパートナンバーの時のみフラッシュ FLAG_CHECKSUM バイオスロムチェックサム FLAG_CMOS CMOSチェックサムクリヤ FLAG_IMAGESIZE フラッシュパートにマッチするイメージサイズをベリファイ dwImageBuf 拡張メモリ中のバイオスロムイメジのアドレス。このフィールドはイメジが読み込まれるバッファのリニアアドレスを決定する。このエリアは又、SAVEオプションが指定されるときに使われる。セーブさ
れるどんなブロックもアドレスdwImageBuffer+dwFileSizeから始まるアドレス範
囲を使う。 dwMfgIDAddr dwPartIDAddr これら２つのオプションフィールドはフラッシュメモリIDバイトのリニアアドレスを含む。これらのフィールドがゼロの時、E0000hとE0001hのデ
フォルトアドレスが使われる。 bRetryCount フラッシングが失敗の場合のリトライ回数 szVersion PLATFORM.DLLのバージョン szROMFileName リザーブされたものは"BIOS.ROM"ストリングでなければな
らない。このフィールドはPLATFORM.DLLファイルのフォーマットを認識しベリフ
ァイするのに使用される。 dwDLLRFuncDefine PLATFORM.DLLにおいてプラットフォーム指定のどの機能が
定義されるかを示す。 hbBlockTable ブロックテーブルで描かれるブロック数 dwBlockTable フラッシュパートは一度に１つの隣接するブロックがプログラムされる。プログラムされる各ブロックは対応するブロックディスクリプタを有し
なければならない。 bpartTypesSize 追加するフラッシュパート数 dwPartTypes サポートされるフラッシュパートのオプションテーブル。各テーブルのエントリは以下のフォーマットを有する。

【表８】デバイステーブルはゼロにセットされたwFlashType、cMfgID及びcPartID を有するディスクリプタによってターミネイトされる。多数のプラットフォームは同一BIOS.ROMイメジをいくつかの異なるフラッ
シュパートで使用可能にする。このテーブルは新しいパートが入手される時に使
用され、該パート現在PHLASHNT.EXEでサポートされているパートの中にはなく、
該パートはサポートされたパートの１つとして同一のフラッシングアルゴリズム
を使用する。 procEnable フラッシングprocをエネーブルにする procDisable フラッシングprocをディセーブルにする procBegin フラッシングprocを開始する procEnd フラッシングprocを終了する procGetBlock バックアップprocのために次のBIOSブロックを得る procCmdLine プロセスカスタムコマンドラインオプションproc procSense カスタム自動検知proc procIsFlashable 前進okの場合カスタムOEMprocを決定 procReboot カスタムリブートproc procCheckSum BIOS ROMイメジチェックサムがゼロの場合カスタムチェックサムp
rocが使用される PLATFORM.DLLファイルのサンプルソースコードはAPPENDIX B3に示される。 3.3 ブロックテーブルフォーマットブロックテーブルはブロックディスクリプタリストを含む。ブロックテーブル
中の各ブロックディスクリプタは以下のストラクチャで定義される。

【表９】ブロックテーブルは、ゼロにセットされた全エントリを有するディスクリプタに
よってターミネートされている。 DWbLOCKsIZE バイトでのブロックサイズ。ブロックは隣接していなければならない。 dwFileOffset BIOS.ROMファイル中のこのブロックのオフセット dwLinerarAddress 32ビットアドレススペースでこのブロックのアドレスを始
める cMfgID 製造IDまたは自動検知にゼロ cPartID パートIDまたは自動検知にゼロ wBlockAttr このブロックのためのアクションを決定。以下のフラグのコンビネーションでなければならない。 ATTR_ZERO プログラミング前にこのブロックはゼロでなければならな
い ATTR_ERASE プログラミング前にこのブロックはゼロでなければならな
い ATTR_SAVE プログラミング前にこのブロックの内容をセーブ ATTR_PROG このブロックをプログラム ATTR_RESTORE プログラム後にこのブロック内容をレストア ATTR_SAVE、ATTR_PROG、ATTR_RESTOREの中の１のみが一度に使用可能。ア
トリビュート指定なき場合は、PHLASHNT.EXEブロックを不変にする。しかし、こ
れらの全てがオミットされても、プロシジャBeginFlash()及びEndFlash()は、２
つのブロックが異なったフラッシュデバイスにあるとき、あるいはブートブロッ
クが追加的機能をブロック書き込みのためにエネーブルしたりを要求したり次の
ブロックがプログラムされる前にそれをディセーブルする追加機能を要求すると
きに、使用可能である。BeginFlash()は又条件的ブロック処理に使用可能である
。BeginFlash()がノンゼロにもどる場合、現在のブロックは処理されない。各ATTR_SAVEブロックは、他のATTR_SAVEブロックが使用可能である以前に
ATTR_RESTOREブロックによって従われなければならない。与えられたフラッシュメモリレンジのために幾つかのブロックデスクリプ
タがあることに注目。例えば、64k消去可能フラッシュメモリブロク中の16kフラ
ッシュメモリブートブロックを保持するために、３つのブロックデスクリプタが
用いられる。第１のデスクリプタは16kブートブロックをセーブし、２番目は64k
を消去しプログラムし、そして３番目はそのブートブロックにレストアする。フラッシングのための時間を減らすために、ATTR_ZEROフラグが使われないのが推奨される、なぜなら、これはZEROステップとフラッシング時間を半分に
するのを回避する。そのパートに示唆されるわずかなより古いフラッシュメモリ
タイプのみが、再プログラムされる前にゼロ化される。大部分のパートはこの動
作を要求しない。 3.3.3 マルチプルフラッシュブロックブロックテーブルはマルチプルデバイスフラッシングと、各デバイス内にある
マルチプルブロックをサポートするために使われる。その種のプラットフォーム
のためにROMイメジファイルは、全てのプログラムされるべきフラッシュパートのイメジを含まなければならなく、そして、そのブロックテーブルは、フラッシ
ュされるべきデータの各ブロックの好適なオフセットと長さを含まなければなら
ない。各フラッシュブロックの前後のプラットフォームを好適に構成するために、フ
ァンクションPHLASHNT.EXEはBeginFlash(Block_Index)を呼び出してPLATFORM.DL
Lがどんなそのようなセットアップも実行するようにさせることができる。いかなる初期化又はターミネーションをも必要に応じてブロック間で実行することは
、BeginFlash()とEndFlash()のファンクションの役割である。 3.3.4 ブートブロック処理とESCDストーリッジフラッシュメモリでメモリレンジをプログラムするために、同一メモリレンジ
に対して幾つかの異なったブロックデスクリプタが存在する必要がある。これは
、単一“消去”メモリレンジ内のESCDストーリッジ又はブートブロックを予約す
る必要がある。多数のフラッシュパートは少数の書き込み動作、即ち各メモリブロックに対し
て１つ、によって消去される。例えばインテル28f400フラッシュメモリは７ブロ
ック（１つの16Kブートブロック、２つの8Kパラメタブロック、１つの64Kメイン
ブロック及び３つの128K拡張ブロック）を有する。このパートは７回の書き込み
動作のみで消去されうる。他のパートに対しては、消去機能は64Kのフラッシュメモリを一度に消去し、このレンジがブートとパラメタブロックに分かれているかどうかに関わらない。
そのような場合、この種の64Kメモリレンジに対して３つのブロックデスクリプタが存在することが重要である。テーブルの第１ブロックデスクリプタはブート
ブロックをセーブするために使われ、第２ブロックデスクリプタはパラメタを消
去しプログラムするために使われ、第３デスクリプタはこの範囲内にブートブロ
ックをレストアするために使われる。幾つかのパートは、追加的プラットフォーム従属アクションがブートブロック
がプログラムされる前に、取られなければならない。例えばインテルパートはVP
P電圧に加えてVHH電圧が好適に設定されることを要求する。そのような場合、ブ
ロックデスクリプタはBeginFlash()及びEndFlashu()プロシジャ（各ブロックの前後と呼ばれる）のようなファンクションを有しなければならない。 3.3.5 ブロックテーブル例以下の例のコードはPLATFORM.CPPの"blockTable”の中に置かれる。

【表１０】 3.4 PLATFORM.DLLファンクション現在サポートされているファンクションは以下の通りである。以下のファンクションはPLATFORM.DLLに含められて、PHLASHNT.EXEによっ
てアクセスされて、プラットフォーム従属機能を実行する。 EnableFlash DisableFlash BeginFlash EndFlash GetBlock CmdLine AutoSense lsFlashable Reboot CheckSum 以下のファンクションによってPHLASHNT.EXEはPLATFORM.DLLに含まれる広
域変数とデータストラクチャにアクセスすることが可能になる。 GetBIOSFileSize GetManufactID GetPartID GetFlags GetImageBuf GetMfgIDAddr GetPartDAddr GetRetryCount GetblockTableSize GetPartsSize GetBlockTable GetpartTypes GetDLLVersion GetROMFileName GetDLLFuncDefine 3.4.1 ファンクションエネーブルフラッシュ（） Entyr: なし Returns: エラーコード（即ちゼロ）このファンクションはPLATFORM.DLLにおいて存在しなければならない。それは
フラッシュメモリアクセスの全てのアテンプトの前にコールされる。このファン
クションによって一般に実行されるアクションは以下を含む。メモリへのマップフラッシュデバイスディセーブルキャッシュ、シャドイング及びパワーマネジメントフラッシュキャッシュディセーブルPCIブリッジエネーブル書き込みのROM（VPPオン）大部分のプラットフォームは、パートがフラッシングのためにエネーブルにな
る以前にジャンパは変えられることを要求する。EnableFlash()プロシジャは、このジャンパセッティングが不正確であると判定した場合、ジャンパが除去され
エラーコードに戻るようにベリファイしなければならない。エラーコードについ
ては付録Bを参照。 3.4.2 ファンクションディセーブルフラッシュ（） Entry：なし Returns: エラーコード（即ちゼロ）このオプションファンクションは、最終ブロックがプログラムされた（あるい
はエラーが検出された）後コールされる。それはPHLASHNT.EXEが存在（一般的に
はリブート前の最終コールとして）する直前に、コールされる。それは再起動（
Re-Action）をクリアに行うに必要な全てのファンクションを実行すべきであり、一般的にこのファンクションを含む；即ちディセーブルロム書き込み（VPPオフ） 3.4.3 BeginFlash(DWORD Block_Index)のファンクション Entry: プログラムされるブロック（又はテーブル不使用の場合ゼロ）のインデクス Exit: なし Returns: エラーコード（VPPオフ）このオプションファンクションはPHLASHNT.EXEによって、フラッシュブロック
が処理される直前にコールされる。それは各ブロック（ブロックテーブル中に見
いだされる）ごとに、コールされる。このファンクションによって実行されるアクションは、以下を含む：ブートブロックをそれが消去される前にセーブする１つのデバイスから他のデバイスへ（複数デバイスを伴うプラットフォー
ム上で）スイッチするブートブロックリプログラムのためにVHHをエネーブルにする現行ブロックが処理されるべきかを判断する BeginFlash()が非ゼロに戻る場合、現行ブロックは処理されない。 3.4.4 EndFlash(Dword Block_Index)ファンクション Entry: プログラムされたブロック（テーブルのゼロは不使用）の
インデクス Returns: エラーコード（即ちゼロ）このオプションファンクションはPHLASHNT.EXEによって、フラッシュブロック
が処理された直後に、コールされる。それは各ブロック（ブロックテーブル内に
見いだされる）に対してコールされる。このファンクションによって実行されるアクションは一般的に以下を含む： BeginFlash()ファンクションによってセーブされるBOOTブロックをレスト
ア２つの異なったデバイスのプログラミング間をクリーンアップブートブロックがプログラムされた場合VHHをディセーブル 3.4.5 GetBlock（DWORD Index,DWOED Buffer_Address） Entry: コピーされるブロックのインデクス及び64kバッファのリニアアド
レス Exit: バッファは存在するバイオスロムイメジの次のブロックに満たされる Returns: ネガティブエラーコード、ゼロ又はポジティブこのオプションファンクションはPHLASHNT.EXEによって、BACKUPフラグが指定
されるたびにコールされる。GetBlock()は、フラッシュメモリが変化する前にフ
ラッシュメモリ内容がセーブされるとき、補助に使われる。多くのバイオスイメ
ジがシャドウラムに解凍されて入れられているので、PHLASHNT.EXEがバイオスロ
ムイメジにプラットフォーム従属システムをセットアップせずにアクセスするこ
とは常には可能ではない。GetBlockファンクションは、現在のバイオスロムイメ
ジの従属アクセスするプラットフォームを許可するために必要である。バイオス
ロムイメジは以下のステップを使用してPHLASHNT.EXEによってセーブされる： 1)インデクスをゼロにセットされたGetBlock(Index,Buffer)及び64kバッファをコールし、パラメタバッファによって向けられ、予め定義されたパタンで
満たされる。バッファのパタンがBIOS.BAKファイル中の第１の64kブロックとしてセーブされ、その後プログラムは次のステップに進む 2)GetBlack(Index,Bufer)を、インデクスを前回のGetBlock（）のコールによって帰った値にセットして呼び出し、64kバッファをBIOS.BAKにセーブしそしてこれをGetBack（）により帰る数が負になるまで繰り返す。 3)最後のGetBack（）によって帰る値がゼロの場合、メモリをフラッシングして進む。帰った値が負のエラーコードの場合、エラーをレポートし、BIOS.B
AKをデレートし、抜け出す。 GetBack（）がプラットフォームが正常な状態でGetBack（）をしてBIOS ROM イメジをバッファ内のコピーせしめること及びプラットフォームがGetBack（）がPHLASHNT.EXE制御に戻る前にオリジナルモードに蓄えられるのを確かなものに
することは、GetBack（）実行の役割である。特に、GetBack（）は、EnableFlas
h()に対してコールがなされる前にコールされる。GetBack（）に渡されたバッフ
ァポインタは常に640k以下のリアルメモリ範囲にあり、ディスクに直接移ること
が可能である。 3.4.6 Function CmdLine(charfar*szOptions) Entry: 含むペイロードら特定コマンドラインオプションを伴うストリングへのポインタ Returns: エラーコード（即ち０）このオプションファンクションはPLATFORM.DLLが読み込まれた直後PHLASHNT.E
XEによってコールされる。それは全てのプラットフォーム特定コマンドラインパ
ラメタ（/PLATFORM=""コマンドラインにオプションを伴う等しいサインの直後に
特定される）を含むストリングアドレスを通過される。ストリングはリーディン
グとトレーリングのダブルクォートをもしあれば含む。 3.4.7 Function AutoSense() Entry: PLATRFORM.INIヘッダから検索された製造者及びデバイスID Returns: フラッシュパート（即ちゼロ）から検索されたID このファンクションはPLATFORM.DLL中のEnableFlash()ファンクションがコールされた直後PHLASHNT.EXEによってコールされる。AutoSense()機能は、”非標準”のメモリ組織がフラッシュメモリに使われたときメモリフラッシュパートの
自動判定を可能にする。例えば２つの分離パートが偶数と奇数のBIOSアドレスに
使用されるとき（その場合従来の自動検出機構はフェールする）、この機構はそ
れぞれのパートのIDを獲得しベリファイするのに使われる。 IDは１バイトの長さでDWORDのなかにパックされ、製造IDをBYTE0及びデバイス
IDをBYTE1のなかに含む。 3.4.8 Function lsFlashable（char far*szErrorMsg） Entry: 戻ったエラーメッセージを含むストリングへのポインタ Exit: エラーメッセージストリングを含むszErrorMsg Returns: エラーコード（即ちゼロ）このオプションファンクションは、EnableFlash()が進んでも良いかどうか判断する以前にコールされる。もしこの機能が非ゼロエラーコードに戻る場合、ス
トリングszErrorMsgが表示されプログラムは終了する。254バイト以上までターミネーティングNULLがszErrorMsgの中に戻される。これがどのように使用されかの例は以下の如くである：同じプラットフォーム
に対してはOEMは、プラグアンドプレー能力を持ったあるいは持たないシステムを販売している。lsFashable()機能は、現行システムがプラグアンドプレーを持
っているかどうか判定し、そしてすでに持っていないプラットフォーム上のプラ
グアンドプレーBIOSをフラッシュしない。 3.4.9 Function Reboot() Entry: なし Returns: なしこのオプションファンクションはシステムをリセットしてプログラムが終了し
たあと、コールされる。提供される場合、PHLASHNTの自身のリブートコードに代
わってコールされる。 3.4.10 FunctionCheckSum（） Entry: なし Returns: エラーコード（即ちゼロ）このオプショルファンクションは、プログラムがBIOSROMイメジがのchecksum が正しい可動か判定する前にコールされる。一般には、NuBIOSイメジのBIOSROM イメジチェックサムはゼロである。このルーティーンは、ROMイメジチェックサムがゼロでないと知られるとき、交互チェックサム検出方法を提供するために使
用される。この機能が非ゼロに戻ると、PHLASHNは終了する。 3.4.11 FunctionGetBIOSFilSize() Entry: なし Returns: BIOSイメジサイズこの機能は、PLATFORM.DLLからの広域変数dwFileSizenoの内容を戻す。 3.4.12 Function GetManufactID() Entry: なし Returns: 製造者ID この機能は、PLATFORM.DLLからの広域変数bManufactIDの内容を戻す。 3.4.13 Function GepartID() Entry: なし Returns: PrtID この機能は、PLATFORM.DLLからの広域変数PrtIDの内容を戻す。 3.4.14 Function GetFlags() Entry: なし Returns: オプションフラグこの機能は、PLATFORM.DLLからの広域変数dwFlagsの内容を戻す。 3.4.15 Function GetImageBuf() Entry: なし Returns: イメジバッファの位置この機能は、PLATFORM.DLLからの広域変数dwImageBufの内容を戻す。 3.4.16 Function GetMfgIDAddr() Entry: なし Returns: 製造者IDが位置するアドレスこの機能は、PLATFORM.DLLからの広域変数dwMfgIDAddrの内容を戻す。 3.4.17 Function GetPartIDAddr() Entry: なし Returns: パートIDが位置するアドレスこの機能は、PLATFORM.DLLからの広域変数dwPartIDAddrの内容を戻す。 3.4.18 Function GetRetryCount() Entry: なし Returns: 障害が起きた場合フラッシングをリトライする回数この機能は、PLATFORM.DLLからの広域変数bRetryCountの内容を戻す。 3.4.19 Function GetblockTableSize() Entry: なし Returns: ブロックテーブル中のブロックの個数この機能は、PLATFORM.DLLからの広域変数blockTableSizeの内容を戻す。 3.4.20 Function GetpartTypesSize() Entry: なし Returns: PLATFORM.DLLが記述する追加的フラッシュパートの数この機能は、PLATFORM.DLLからの広域変数GetpartTypesSizeの内容を戻す。 3.4.21 Function GetBlockTable() Entry: なし Returns: ブロックテーブルのアドレスこの機能は、PLATFORM.DLLからの広域変数BlockTableの内容を戻す。 3.4.22 Function GetPartTypes() Entry: なし Returns: partTypesのアドレスこの機能は、PLATFORM.DLLからの広域変数partTypesの内容を戻す。 3.4.23 Function GetDLLVersion() Entry: なし Returns: PLATFORM.DLLのバージョンこの機能は、PLATFORM.DLLからの広域変数szVersionの内容を戻す。 3.4.24 Function GetROMFileName() Entry: なし Returns: BIOSROMファイル名称この機能は、PLATFORM.DLLからの広域変数szROMBIOSFileの内容を戻す。 3.4.25 Function GetDLLFuncDefine() Entry: なし Returns: PLATFORM.DLL中のどんなプラットフォーム従属機能かを示すこの機能は、PLATFORM.DLLからの広域変数dwDLLFuncDefineの内容を戻す。 4.0 BIOS.ROM詳細 ROMイメジファイルサイズは充分に大きく、プログラムされるべきフラッシュデバイス中の全てのブロックを含む。ブートブロックスワッピングやデータ圧縮
のような必要とするBIOSイメジの事後処理は、ROMイメジファイルに予め組み込まれていなければならない。 5.0 一般検索ガイドラインプログラムはマイクロソフトビジュアルＣ＋＋バージョン4.2以降によって開発される。なぜならばこのプログラムは入手しうる最新のデバイスとして開発されること
及びコードサイズはクリティカルではないので、コーディングスタイルは実行可
能なコードのコンパクトさよりもコード読み取り可能性及び明晰さがより高い優
先度を有している。しかしながら、プログラムは又製造環境で使用されるので、パートフラッシン
グのためには可能な最短時間を取り得るように構成されなければならない。特に
、ノンクリティカルユーザインタフェースがディセーブルされるモードを有する
べきである。そして、可能なときは時間消費フラッシング機能は最小のアセンブ
リ言語で記述されるべきである。付録B1−将来の拡張キーボードLEDを有する完了コードプログラムが、フラッシングプロセスの３つの大きな段階のどこかで終了に失敗
すると、プログラムはキーボードLEDを使ってユーザにどの段階でプログラムが失敗したかを知らせる。プログラムスタートにおいてキーボード上のCAPS LOCK,
NUM_LOCK,SCROLL_LOCKのLEDは点灯される。それぞれ３つの段階の障害が以下に示される。キーボードLEDがオン記述 CAPS,NUM,SCROLL platform.dllの読み取り以前 CAPS,NUM platform initの以前 NUM platform initの以後なし成功裏に終了付録B2−PHLASHNT.H 終了とエラーコード FFh BIOS.BAKバッファのためのメモリアロケーション失敗 FEh BIOS.BAKがすでに存在（それをリネーム又はデレート） FDh BIOS.BAK上のFile Create失敗 FCh BIOS.BAK上のFile Write失敗 FBh BIOS.BAK上のFile Close失敗 FAh BIOSのバックアップがPLATFORM.DLL中にサポートされていない F9h PLATFORM.DLL上のFile Open失敗 F8h PLATFORM.DLL上のFile Read失敗 F7h PLATFORM.DLL上のFile Close失敗 F6h PLATFORM.DLL中のシグネチャバイト位置指定失敗 F5h サポートされていないPLATFORM.DLLファイルバージョン F2h PLATFORM.DLL中のデバイステーブルが多くのエントリを持ちすぎ F1h PLATFORM.DLL中のデバイステーブルがサポートされていないフラッシュタ
イプを有する F0h PLATFORM.DLLにおいて組み合わせられたSAVEやRESTOREの属性 EFh PLATFORM.DLL中のRESTOREブロックに合わないSAVEブロック ECh サポートパートのテーブルに見いだされないパートID EBh PLATFORM.DLLはコマンドパラメタライン中にエラーを発見した EAh BIOS ROMイメジへのアロケーション失敗 E9h BIOS ROMイメジファイル上にオープン失敗 E8h BIOS ROMイメジファイル上にリード失敗 E6h BIOS ROM上にファイルクローズ失敗 E4h フラッシュメモリID読み取り意図失敗 E3h PLATFORM.DLLはフラッシュメモリID戻り失敗 E2h BCPSYSブロックがBIOS ROMファイルイメジ中に発見できない E1h ファイルは同一BIOSパートナンバを含まない E0h ファイルは異なったBIOS ROMイメジバージョンを含まない DFh フラッシュに書かれるべきデータがBIOS ROMイメジに合わない DEh フラッシュメモリ書き込み失敗 DDh 失敗したフラッシュメモリブロックを消す DCh VPPは予定のレベルではない DBh 失敗したシーケンス消去 DAh 新しいDMIストリングが大きすぎ D9h BIOS ROMファイルはこのシステムでは使われていない D8h DMI OEMストリングのアロケーション失敗 D7h BIOS ROM中の指定されたDMI OEMストリングのスペースがない D6h DMI OEMストリングはサポートされていない（BCPDMI 0.1+を要求） D5h BIOS ROMファイルイメジ中のBCPDMIブロックが発見できない D3h BIOS ROMファイルが破壊された可能性（checksumはゼロでない） D2h BIOS ROMファイルサイズはフラッシュパートサイズに合わない D1h DMIシステムとシャーシストリングはBCPDMI2.1+を要求付録B3−PLATFORM.DLL サンプルソースコード

【表１１】

【表１２】

【表１３】

【表１４】

【表１５】

【表１６】

【付録Ｃ】

付録Ｃ要約：この文書は、ＢＩＯＳ３２サービス・ディレクトリとして知られている
、新たなＢＩＯＳサービスについての提案について紹介する。この新たなサービ
スっは、３２ビット・コード・セグメントで走るコール元のために設計された、
ばイ押す内のサービスに関する情報を提供する。（ＢＩＯＳ３２サービス・ディ
レクトリ自体は、３２ビットＢＩＯＳサービスである。）このサービスのクライ
アントとして考えられるのは、３２ビット・オペレーティング・システムおよび
３２ビット・デバイス・ドライバである。このサービスの提供者として考えられ
るのは、１つ以上の３２ビットＢＩＯＳサービスを実施するＢＩＯＳベンダであ
る。１．はしがきＢＩＯＳ３２サービス・ディレクトリの提案は、周辺素子相互接続（ＰＣＩ）
規格のために３２ビット・コード・インターフェースを確定する試みの中で生ま
れた。解決すべき主要な問題は、３２ビット・コール側はどのようにして３２ビ
ットＢＩＯＳサービスの存在を判定するかということであった。機能的インター
フェース（即ち、制御を移管する先のエントリ・ポイント）の欠点は、機能性イ
ンターフェースが残っていない場合には明らかである。復元可能な方法があると
しても、機能性インターフェースが存在するという証拠として、サインの検索を
伴うと思われる。実際、最初のＢＩＯＳ３２ビット・サービスの１つであるＥＩ
ＳＡは、０Ｆ０００ｈセグメント内の固定位置に存在サインを使用する。しかし
ながら、必要とされる３２ビットＢＩＯＳサービスが増加し、存在するようにな
るに連れて、各々にサイン（およびエントリ・ポイント、セグメント要件等のよ
うなあらゆる関連情報）を設けることは、貴重なメモリ資源の浪費であることは
明白である。したがって、背後にある考えは、（訳注：文が途中で切れています
）ＢＩＯＳ３２サービス・ディレクトリは、１つのサインを用いて汎用３２ビッ
ト・サービスの存在を示し、具体的な３２ビットサービス全てに関する情報を戻
す。その場しのぎで問題を解決し続けることに対して、総合的な解決策を実現する
ことの正当性は、規格が業界に与える恩恵からも明らかである。コードの再利用
性、新たな３２ビットＢＩＯＳインターフェースのモジュール化（「プラグ・イ
ン」を可能にする）実施、コール側環境要件についての全般的な仕様等は、考え
られる利点の一部である。ＢＩＯＳ３２サービス・ディレクトリは、ヘッダおよびコーリング・インター
フェースという２つの構成要素を有する。ヘッダは、サインを含み、既知のメモ
リ範囲内に位置する固定データ構造である。有効なヘッダが存在することは、コ
ーリング・インターフェースの存在を意味し、実際には、そのエントリ・ポイン
トを記述する。コーリング・インターフェースは、コードおよびデータの本体で
あり、ヘッダおよび個々の３２ビットＢＩＯＳサービスのいずれからも離れた別
個のメモリ空間に存在する。これは、コール元が特定の３２ビットＢＩＯＳサー
ビスに関する情報を受け取る際に用いる機能性インターフェースを提供する。（
章０には、ヘッダ、コーリング・インターフェース、および「ＸＹＺ」３２ビッ
トＢＩＯＳサービスの仮説メモリ・マップについて説明がある。）コーリング・インターフェースの設計は、２つの次元で拡張可能である。第１
に、これは機能ベースのインターフェースである。今後のサービス改訂は、必要
となる毎に、新たな機構に組み込むことができる。第２に、個々の３２ビットＢ
ＩＯＳサービスは、４バイト・コンポーネントＩＤによって表わされる。これに
よって、ＯＳコール元およびＢＩＯＳ３２サービス・ディレクトリ・インプリメ
ンタ双方共、新たな３２ビットＢＩＯＳサービスが使用できるようになる毎に、
これらを容易に追加することが可能となる。ＢＩＯＳサービス・ディレクトリに対するインターフェース、および例による概
要２．ＢＩＯＳ３２サービス・ディレクトリ・ヘッダＢＩＯＳ３２サービス・ディレクトリを実現するＢＩＯＳは、物理アドレス範
囲０Ｅ００００ｈ−０ＦＦＦＦＦｈ内のどこかに、特定の隣接１６バイト・パタ
ーンを埋め込まなければならない。このパターンは、パラグラフで位置合わせさ
れていなければならない（即ち、１６バイトの境界で始まらなければならない）
。このパターンは、ＢＩＯＳ３２サービス・ディレクトリ・ヘッダとして知られ
ている。ヘッダは６つの個別フィールドで構成されている。以下の表に各フィールドに
ついて説明する。

【表１７】ＢＩＯＳ３２サービス・ディレクトリのクライアントは、最初にヘッダを突き
止めてその存在を判定しなければならない。これは、パラグラフずつ進めながら
０Ｅ００００ｈないし０ＦＦＦＦ０ｈを走査し、各パラグラフの最初の４バイト
においてサインの一致（”＿３２＿”）を探す。サインが検出されたなら、クラ
イアントはヘッダ内の全バイトのチェックサムを求める。（パラグラフ内のヘッ
ダ長は、オフセット９ｈで分かる）。ヘッダ内の全バイトを互いに加算し、その
結果が０ｈにならなければならない。チェックサムが有効な場合、３２ビット・
エントリ・ポイント・フィールドは、ＢＩＯＳ３２サービス・ディレクトリ・コ
ーリング・インターフェースのアドレスとして使用することができる。ヘッダが
見つからない場合、ＢＩＯＳ３２サービス・ディレクトリはそのプラットフォー
ム上には存在しないことになる。３．ＢＩＯＳサービス・ディレクトリ・コーリング・インターフェースＢＩＯＳ３２サービス・ディレクトリの存在がわかったならば（前述のヘッダ
検査によって）、ヘッダ内にある３２ビット物理アドレスを、コーリング・イン
ターフェースへのエントリ・ポイントとして用いることができる。クライアント
は、このアドレスにＣＡＬＬＦＡＲしなければならない。クライアントのコー
ル環境は、以下の要件を有する。３．１コード・セグメント以下の値を有するセグメント記述子を用いて、ＣＳコード・セグメント・セレ
クタを設定しなければならない。・基底アドレスは、エントリ・ポイントを含むページの（４ｋｂ）ページ・ア
ドレス以下でなければならない。例えば、エントリ・ポイントが０ＦＦＦ８１２
３４ｈであるとすると、基底アドレスは０ＦＦＦ８１０００ｈ以下でなければな
らない。・このリミットは、基底アドレスにこのリミットを加算すると、エントリ・ポ
イントを含むページに続く（４ＫＢ）ページ上の最後のアドレスに等しくなるよ
うにしなければならない。例えば、エントリ・ポイントが０ＦＦＦ８１２３４Ｈ
であるとすると、基底アドレスにリミットを加算して０ＦＦＦ８２ＦＦＦｈ以上
でなければならない。・単純に言えば、基底アドレスおよびリミットは、エントリ・ポイントを含む
ページおよび次のページ双方に「跨がらなければ」ならない。・セグメント・タイプは、１００ｂ（コード、実行のみ）または１０１ｂ（コ
ード、実行／リード）でなければならない。しかしながら、サービス・ディレク
トリのインプリメンタは、ＣＳコード・セグメントへのリード・アドレスを引き
受けることができない。・システム・バイトは、１（非システム・セグメント）でなければならない。・記述子特権レベル（ＤＰＬ）を０とすることを推奨する（ＣＳ記述子ＤＰＬ
は、現特権レベル即ちＣＰＬとなる）。ＣＰＬが０でない場合、ＯＳは、リング
０特権命令に対して、トラップおよび仮想化サービスを提供しなければならない
。また、このフィールドのＥＦＬＡＧＳ（章０を参照）内のＩＯＰＬフィールド
に対する依存性にも注意すること。・デフォルト・サイズ・ビットは１（３２ビット）でなければならない。ＢＩＯＳ３２サービス・ディレクトリ・エントリ・ポイント、ならびにそれに
関連するコードおよびデータは、４Ｇｂ物理アドレス空間内のどこに位置しても
よい。しかしながら、物理的に隣接しており（即ち、ＲＯＭまたはＦＬＡＳＨ空
間に送出される）、２ページ内に納まる（即ち、３ページには跨がらない）こと
を保証する。３．２データ・セグメント以下の値を有するセグメント記述子を用いて、ＤＳデータ・セグメント・セレ
クタを設定しなければならない。・基底アドレスはＣＳ基底アドレスに等しくなければならない。・リミットはＣＳリミット以上でなければならない。・セグメント・タイプは、０００ｂ（データ、リードのみ）または００１ｂ（
データ、リード／ライト）でなければならない。しかしながら、サービス・ディ
レクトリのインプリメンタは、ＤＳコード・セグメントへのライト・アドレスを
引き受けることができない。・システム・バイトは、１（非システム・セグメント）でなければならない。・記述子特権レベル（ＤＰＬ）は、ＣＰＬ（章０のＤＰＬフィールドを参照）
以上でなければならない。ＥＳ、ＦＳ、およびＧＳデータ・セグメント・セレクタに関する要件はない。３．３スタック・セグメント以下の値を有するセグメント記述子を用いて、ＳＳスタック・セグメント・セ
レクタを設定しなければならない。・セグメント・タイプは、０１１ｂ（データ、リード／ライト、下方展開）ま
たは００１ｂ（データ、リード／ライト、情報展開）でなければならない。・システム・バイトは、１（非システム・セグメント）でなければならない。・記述子特権レベル（ＤＰＬ）は、ＣＰＬ（章０のＤＰＬフィールドを参照）
以上でなければならない。・デフォルト・サイズ・ビットは１（３２ビット）でなければならない。・粒度ビットは１（４Ｋｂ）でなければならない。前述の設定値は、少なくとも４ｋｂのスタック・サイズを確保することに注意
すること。少なくとも１ｋｂの使用可能な未使用スタックがあることを確保する
のは、コール側の責任である。３．４ページングページングは、イネーブルしてもしなくてもよい。ページングをイネーブルす
る場合、ＣＳおよびＤＣセレクタによって記述されるアドレス空間は、線形的に
隣接していなければならない。即ち、ＲＯＭまたはＦＬＡＳＨ内で見出されるコ
ーリング・インターフェースの元々の物理的隣接性を保存しなければならない（
コーリング・インターフェース・コードおよびデータは、場所に依存せず、ＥＩ
Ｐに関係するように書かれる）。３．５ＩＯＰＬ：コーリング・インターフェースがＩ／Ｏ命令を実行するため
には、ＥＦＬＡＧＳ内のＩ／Ｏ特権レベル（ＩＯＰＬ）フィールドは、ＣＰＬ（
章０のＤＰＬフィールドを参照）以上でなければならない。ＢＩＯＳ３２サービス・ディレクトリ・コーリング・インターフェースは、関
数を基本とし、全てのパラメータはレジスタにおいて受け渡しされる。レジスタ
がある関数の出力パラメータとして指定されていない場合、これは保存されるこ
とになる。全てのフラグは保存される。関数値は、レジスタＢＬ内の入力パラメ
ータとして渡される。レジスタＡＬにリターン・ステータスが戻される。リター
ン・ステータスが００ｈの場合、関数が成功したことを示す。リターン・ステー
タスが８０ｈの場合、要求された関数（ＢＬにおける）に対応しないことを示す
。その他のＡＬリターン値は、個々の関数によって定義される。現在定義されて
いるＢＩＯＳ３２サービス・ディレクトリの関数は１つである。これを以下に詳
しく示す。３．６コンポーネント存在関数（ＢＬ＝０ｈ）コンポーネント存在関数は、特定の３２ビットＢＩＯＳサービスが存在するか
否か、そして存在する場合、それが占めるメモリ空間についての情報を返す。入力：ＢＬ，０ｈＥＡＸ，コンポーネントＩＤコンポーネントＩＤは、３２ビットＢＩＯＳサービスを一意に識別する
４バイトＡＳＣＩＩストリングである。個々のＢＩＯＳサービスについての仕様
は、それら自体のコンポーネントＩＤを定義する。（これらの仕様が、コンポー
ネントＩＤストリングは左から右にパックされるのか、あるいは右から左にパッ
クされるのかを定義することは重要である）。ＥＢＸ，予約済み、０ｈにセットされている。出力：要求された３２ビット・サービスが存在しない場合、ＡＬ＝８１ｈ要求された３２ビット・サービスが存在する場合、ＡＬ＝０ｈＥＢＸ＝３２ビットＢＩＯＳサービスの基底アドレスＥＣＸ＝２３ビットＢＩＯＳサービスの長さＥＤＸ＝３２ビットＢＩＯＳサービス・エントリ・ポイントのオフセット
（ＥＢＸより）ＥＢＸ，ＥＣＸ，およびＥＤＸレジスタの残りは、個々の３２ビットＢＩＯＳ
サービス仕様によって異なる。即ち、これらは、セグメント・セレクタ、最小「
包含」値等を設定するための正確な値を表わすことができる。３．７将来の機能将来のＢＩＯＳ３２サービス・ディレクトリの機能は、今後の本文書の改訂版
において定義されよう。機能パラメータ・インターフェースは、レジスタの受け
渡しに制約されず、スタック上の入出力パラメータを用いることができる。これ
は、スタックの静的な定義のために、実現可能である。４．まとめ本文書は、ＢＩＯＳサービス・ディレクトリについて記載したものである。こ
れは、ヘッダおよびコーリング・インターフェースという２つの別個のメモリ・
コンポーネントを識別する。ヘッダは、メモリ範囲０Ｅ００００ｈ−０ＦＦＦＦ
Ｆｈ内に位置するサイン・データのパラグラフである。コーリング・インターフ
ェースは、４Ｇｂのアドレス空間内におけるメモリの物理的隣接セクションのい
ずれかを占めるコードの本体であり、長さが２ページ（８ｋｂ）未満である。ヘ
ッダは、コーリング・インターフェース・メモリ・エリアへのポインタを含む。ＢＩＯＳ３２サービス・ディレクトリ・コーリング・インターフェースの関数
は、特定の３２ビットＢＩＯＳサービスに対してコードおよびデータを含む、追
加のメモリ・エリアを記述する。仮説的なヘッダ、コーリング・インターフェー
スおよび「ＸＹＺ」３２ビットＢＩＯＳサービスのメモリ・マップは次の通りで
ある。

【表１８】本文書は、３２ビットＢＩＯＳにアクセスする標準的な方法を提示するもので
ある。ＢＩＯＳ３２サービス・ディレクトリ・コーリング・インターフェースの
拡張可能性を用いれば、新たな３２ビットＢＩＯＳサービスが認識され実施され
る毎に、標準的な方法を容易に発展させていくことができる。

【付録Ｄ１】

【付録Ｄ２】

【付録Ｄ３】

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者ファンクァンアメリカ合衆国カリフォルニア州 92782タスティンサラトガドライブ 13281 Ｆターム(参考） 5B005 JJ01 MM31 5B076 BA01

Claims

【特許請求の範囲】

【請求項１】物理メモリ内の命令シーケンスを、プロセッサベースシステム内
の仮想メモリからアクセス及び実行する装置であって、プロセッサベースシステムの処理がなされる命令シーケンスを記憶し且つ物理
メモリ及び仮想メモリを含むメモリと、前記記憶済命令シーケンスを実行するプロセッサと、前記記憶済命令シーケンスは、（ａ）前記物理メモリから前記仮想メモリ内に
複数の所定の命令シーケンスをマップさせるステップと、（ｂ）前記仮想メモリ
内の前記複数の所定の命令シーケンスの１つに対してオフセットを決定させるス
テップと、（ｃ）前記複数の所定の命令シーケンスの１つを実行するためにイン
ストラクションを受けせしめるステップと、（ｄ）前記複数の所定の命令シーケ
ンスの１つに制御を移動せしめるステップと、（ｅ）前記仮想メモリからの前記
複数の所定の命令シーケンスの１つを処理せしめるステップとを前記プロセッサ
に処理せしめる処理方法を含むことを特徴とする装置。
【請求項２】前記ステップ(c)において、前記インストラクションはアプリケーションプログラムにより作成されることを特徴とする請求項１に記載の装置。
【請求項３】前記ステップ(c)において、前記インストラクションはクラスドライバにより作成されることを特徴とする請求項１に記載の装置。
【請求項４】前記ステップ(a)は、（ａ．１）ＢＩＯＳサービスディレクトリを含む複数のＢＩＯＳ命令シーケンス
を物理メモリから仮想メモリにマップするステップと、（ａ．２）物理メモリから仮想メモリにＢＩＯＳデータをマップするステップと
を含むことを特徴とする請求項１に記載の装置。
【請求項５】前記ステップ(b)は、（ｂ．１）ＢＩＯＳサービスディレクトリの開始仮想アドレスを決定するステッ
プと、（ｂ．２）ＢＩＯＳサービスディレクトリを参照する複数のＢＩＯＳ命令シーケ
ンスのうちの１つの開始仮想アドレスを決定するステップとを含むことを特徴と
する請求項４に記載の装置。
【請求項６】前記ステップ（d）は、（ｄ．１）記憶場所内にレジスタスタックを作成するステップと、（ｄ．２）前記レジスタスタック内の複数のＢＩＯＳ命令シーケンスのうちの１
つの開始仮想アドレス位置を識別するステップと、（ｄ．３）複数のＢＩＯＳ命令シーケンスのうちの１つに対して制御を移動する
ステップを含むことを特徴とする請求項５に記載の装置。
【請求項７】前記ステップ（ｄ．１）において、前記記憶場所は、ダイナミック
ランダムアクセスメモリ（DRAM）内のバッファに在ることを特徴とする請求項６
に記載の装置。
【請求項８】前記ステップ（ｄ．１）において、前記記憶場所は、主記憶装置内
のバッファに在ることを特徴とする請求項６に記載の装置。
【請求項９】前記ステップ(e)は、（ｅ．１）物理メモリから仮想メモリにマップされたアドレスの範囲内に開始仮
想アドレスが含まれているか否かを決定するステップと、（ｅ．２）前記アドレスの範囲内に含まれている場合には仮想メモリから複数の
ＢＩＯＳ命令シーケンスの１つを実行し、含まれていない場合には物理メモリか
ら仮想メモリにマップされるアドレスの範囲内に開始仮想アドレスがないことを
指し示すステップとを含むことを特徴とする請求項６に記載の装置。
【請求項１０】物理メモリ内の命令シーケンスを、プロセッサベースシステム
内の仮想メモリからアクセス及び実行する方法であって、（ａ）物理メモリから仮想メモリに複数の所定の命令シーケンスをマップするス
テップと、（ｂ）仮想メモリ内の前記複数の所定の命令シーケンスのうちの１つに対してオ
フセットを決定するステップと、（ｃ）前記複数の所定の命令シーケンスのうちの１つを実行するためにインスト
ラクションを受け取るステップと、（ｄ）前記複数の所定の命令シーケンスのうちの１つに対して制御を移動するス
テップと、（ｅ）前記仮想メモリからの前記複数の所定の命令シーケンスのうちの１つを処
理せしめるステップと、を含むことを特徴とする方法。
【請求項１１】前記ステップ(c)において、前記インストラクションはアプリケーションプログラムにより作成されることを特徴とする請求項１０に記載の方
法。
【請求項１２】前記ステップ(c)において、前記インストラクションはクラスドライバにより作成されることを特徴とする請求項１０に記載の方法。
【請求項１３】前記ステップ(a)は、（ａ．１）ＢＩＯＳサービスディレクトリを含む複数のＢＩＯＳ命令シーケンス
を物理メモリから仮想メモリにマップするステップと、（ａ．２）物理メモリから仮想メモリにＢＩＯＳデータをマップするステップと
を含むことを特徴とする請求項１０に記載の方法。
【請求項１４】前記ステップ(b)は、（ｂ．１）ＢＩＯＳサービスディレクトリの開始仮想アドレスを決定するステッ
プと、（ｂ．２）ＢＩＯＳサービスディレクトリを参照する複数のＢＩＯＳ命令シーケ
ンスのうちの１つの開始仮想アドレスを決定するステップとを含むことを特徴と
する請求項１３に記載の方法。
【請求項１５】前記ステップ（d）は、（ｄ．１）記憶場所内にレジスタスタックを作成するステップと、（ｄ．２）前記レジスタスタック内の複数のＢＩＯＳ命令シーケンスのうちの１
つの開始仮想アドレス位置を識別するステップと、（ｄ．３）複数のＢＩＯＳ命令シーケンスのうちの１つに対して制御を移動する
ステップとを含む請求項１４に記載の方法。
【請求項１６】前記ステップ（ｄ．１）において、前記記憶場所は、ダイナミッ
クランダムアクセスメモリ（DRAM）内のバッファに在ることを特徴とする請求項
１５に記載の方法。
【請求項１７】前記ステップ（ｄ．１）において、前記記憶場所は、主記憶装置
内のバッファに在ることを特徴とする請求項１５に記載の方法。
【請求項１８】前記ステップ(e)は、（ｅ．１）物理メモリから仮想メモリにマップされたアドレスの範囲内に開始仮
想アドレスが含まれているか否かを決定するステップと、（ｅ．２）含まれている場合には仮想メモリから複数のＢＩＯＳ命令シーケンス
の１つを実行し、含まれていない場合には、物理メモリから仮想メモリにマップ
されるアドレスの範囲内に開始仮想アドレスがないことを指し示すステップとを
含むことを特徴とする請求項１５に記載の方法。
【請求項１９】物理メモリ内の命令シーケンスを、プロセッサベースシステム内
の仮想メモリからアクセス及び実行するコンピュータに実行可能な処理方法であ
って、（ａ）物理メモリから仮想メモリに複数の所定の命令シーケンスをマップするス
テップと、（ｂ）仮想メモリ内の前記複数の所定の命令シーケンスのうちの１つに対してオ
フセットを決定するステップと、（ｃ）前記複数の所定の命令シーケンスのうちの１つを実行するためにインスト
ラクションを受け取るステップと、（ｄ）前記複数の所定の命令シーケンスのうちの１つに対して制御を移動するス
テップと、（ｅ）前記仮想メモリからの前記複数の所定の命令シーケンスのうちの１つを処
理せしめるステップとを含むことを特徴とする方法。
【請求項２０】前記ステップ(c)において、前記インストラクションはアプリケーションプログラムにより作成されることを特徴とする請求項１９に記載のコ
ンピュータに実行可能な処理方法。
【請求項２１】前記ステップ(a)は、（ａ．１）ＢＩＯＳサービスディレクトリを含む複数のＢＩＯＳ命令シーケンス
を物理メモリから仮想メモリにマップするステップと、（ａ．２）物理メモリから仮想メモリにＢＩＯＳデータをマップするステップと
を含むことを特徴とする請求項１９に記載のコンピュータに実行可能な処理方法
。
【請求項２２】前記ステップ(b)は、（ｂ．１）ＢＩＯＳサービスディレクトリの開始仮想アドレスを決定するステッ
プと、（ｂ．２）ＢＩＯＳサービスディレクトリを参照する複数のＢＩＯＳ命令シーケ
ンスのうちの１つの開始仮想アドレスを決定するステップとを含むことを特徴と
する請求項２１に記載のコンピュータに実行可能な処理方法。
【請求項２３】前記ステップ（ｄ）は、（ｄ．１）記憶場所内にレジスタスタックを作成するステップと、（ｄ．２）前記レジスタスタック内の複数のＢＩＯＳ命令シーケンスのうちの１
つの開始仮想アドレス位置を識別するステップと、（ｄ．３）複数のＢＩＯＳ命令シーケンスのうちの１つに対して制御を移動する
ステップとを含む請求項２２に記載のコンピュータに実行可能な処理方法。
【請求項２４】前記ステップ（ｄ．１）において、前記記憶場所は、ダイナミッ
クランダムアクセスメモリ（DRAM）内のバッファに在ることを特徴とする請求項
２３に記載のコンピュータに実行可能な処理方法。
【請求項２５】前記ステップ（ｄ．１）において、前記記憶場所は、主記憶装置
内のバッファに在ることを特徴とする請求項２３に記載のコンピュータに実行可
能な処理方法。
【請求項２６】前記ステップ（ｅ）は、（ｅ．１）物理メモリから仮想メモリにマップされたアドレスの範囲内に開始仮
想アドレスが含まれているか否かを決定するステップと、（ｅ．２）前記アドレスの範囲内に含まれている場合には仮想メモリから複数の
ＢＩＯＳ命令シーケンスの１つを実行し、含まれていない場合には物理メモリか
ら仮想メモリにマップされるアドレスの範囲内に開始仮想アドレスがないことを
指し示すステップとを含むことを特徴とする請求項２３に記載のコンピュータに
実行可能な処理方法。
【請求項２７】プロセッサベースシステムの仮想メモリからのアクセス及び物
理メモリ内の命令シーケンスを実行する装置であって、プロセッサベースシステムの処理がなされる命令シーケンスを記憶し且つ物理
的なメモリ及び仮想メモリを含むメモリと、前記記憶済命令シーケンスを実行するプロセッサと、を有し、前記記憶済命令シーケンスは、（ａ）前記物理メモリから前記仮想メモ
リ内に複数の所定の命令シーケンスをマップさせるステップと、（ｂ）前記仮想
メモリ内の前記複数の所定の命令シーケンスの１つに対してオフセットを決定さ
せるステップと、（ｃ）前記複数の所定の命令シーケンスの１つを実行するため
にインストラクションを受けせしめるステップと、（ｄ）前記複数の所定の命令
シーケンスの１つに制御を移動せしめるステップと、（ｅ）前記仮想メモリから
の前記複数の所定の命令シーケンスの１つを処理せしめるステップとを前記プロ
セッサに生じせしめる処理方法を含むことを特徴とする装置。
【請求項２８】前記ステップ（ａ）は、（ａ．１）複数のＢＩＯＳ読み取り専用(ROM)命令シーケンス及びＢＩＯＳサー
ビスディレクトリを含む、複数のＢＩＯＳ命令シーケンスを物理メモリから仮想
メモリにマップするステップと、（ａ．２）物理メモリから仮想メモリにＢＩＯＳデータをマップするステップと
を含むことを特徴とする請求項２７に記載の装置。
【請求項２９】前記ステップ(b)は、（ｂ．１）ＢＩＯＳサービスディレクトリの開始仮想アドレスを決定するステッ
プと、（ｂ．２）ＢＩＯＳサービスディレクトリを参照する複数のＢＩＯＳ命令シーケ
ンスのうちの１つの開始仮想アドレスを決定するステップとを含むことを特徴と
する請求項２８に記載の装置。
【請求項３０】前記ステップ（ｄ）は、（ｄ．１）記憶場所内にレジスタスタックを作成するステップと、（ｄ．２）前記レジスタスタック内の複数のＢＩＯＳ命令シーケンスのうちの１
つの開始仮想アドレス位置を識別するステップとを含むことを特徴とする請求項
２９に記載の装置。
【請求項３１】前記ステップ（ｅ）は、（ｅ．１）物理メモリから仮想メモリにマップされたアドレスの範囲内に開始仮
想アドレスが含まれているか否かを決定するステップと、（ｅ．２）含まれている場合には仮想メモリから複数のＢＩＯＳ命令シーケンス
の１つを実行し、含まれていない場合には、物理メモリから仮想メモリにマップ
されるアドレスの範囲内に開始仮想アドレスがないことを指し示すステップとを
含むことを特徴とする請求項３０に記載の装置。
【請求項３２】物理メモリ内の命令シーケンスを、プロセッサベースシステム
内の仮想メモリからアクセスする方法であって、（ａ）物理メモリから仮想メモリに複数の所定の命令シーケンスをマップするス
テップと、（ｂ）仮想メモリ内の前記複数の所定の命令シーケンスのうちの１つに対してオ
フセットを決定するステップと、（ｃ）前記複数の所定の命令シーケンスのうちの１つを実行するためにインスト
ラクションを受け取るステップと、（ｄ）前記複数の所定の命令シーケンスのうちの１つに対して制御を移動するス
テップと、（ｅ）前記仮想メモリからの前記複数の所定の命令シーケンスのうちの１つを処
理せしめるステップとを含むことを特徴とする方法。
【請求項３３】前記ステップ（ａ）は、（ａ．１）複数のＢＩＯＳ読み取り専用(ROM)命令シーケンス及びＢＩＯＳサー
ビスディレクトリを含む、複数のＢＩＯＳ命令シーケンスを物理メモリから仮想
メモリにマップするステップと、（ａ．２）物理メモリから仮想メモリにＢＩＯＳデータをマップするステップと
を含むことを特徴とする請求項３２に記載の方法。
【請求項３４】前記ステップ（ｂ）は、（ｂ．１）ＢＩＯＳサービスディレクトリの開始仮想アドレスを決定するステッ
プと、（ｂ．２）ＢＩＯＳサービスディレクトリを参照する複数のＢＩＯＳ命令シーケ
ンスのうちの１つの開始仮想アドレスを決定するステップとを含むことを特徴と
する請求項３３に記載の方法。
【請求項３５】前記ステップ（ｄ）は、（ｄ．１）記憶場所内にレジスタスタックを作成するステップと、（ｄ．２）前記レジスタスタック内の複数のＢＩＯＳ命令シーケンスのうちの１
つの開始仮想アドレス位置を識別するステップとを含むことを特徴とする請求項
３４に記載の方法。
【請求項３６】前記ステップ（ｅ）は、（ｅ．１）物理メモリから仮想メモリにマップされたアドレスの範囲内に開始仮
想アドレスが含まれているか否かを決定するステップと、（ｅ．２）前記アドレスの範囲内に含まれている場合には仮想メモリから複数の
ＢＩＯＳ命令シーケンスの１つを実行し、含まれていない場合には物理メモリか
ら仮想メモリにマップされるアドレスの範囲内に開始仮想アドレスがないことを
指し示すステップとを含むことを特徴とする請求項３５に記載の方法。