DXR165の備忘録

自分用の備忘録です。

実機でIntel Processor Graphicsメモリ検証  

実機でIntel Processor Graphicsメモリ検証


Intel Processor Graphics 調査メモ  はこちらから
Intel グラフィックス製品の歴史についてはこちら



Intel Pentium(R) CPU G4560 内臓GPUであるIntel HD Graphics 610 のGraphicsメモリがどのように実装されているかを調べてみます。


検証環境その1
★MeltdownとSpectre対策パッチ済
■CPU Intel Pentium G4560 3.50 GHz (Kaby Lake-S)
■GPU ntel HD Graphics 610
■マザーボード ASUS H270-PLUS BIOS Ver 1006
    Graphics Output Protocol (GOP) Version: 9.0.1052
■メモリー DDR4-2133 4G x 2 Dual-Channel Mode
■SSD システムドライブ:Samsung SSD 960 EVO 250GB
■OS Microsoft Windows 10 Home 64bit Ver.1709 OSビルド 16299
    WDDM 2.3
    Intel Graphics Driver Version: 23.20.16.4973
    Display HDMI Resolution: 1920 x 1080 32 bit


まず、UMA確保分をみてみます。これはBIOSとWindows OS用IGDドライバで使用するメモリになります。
では、Windows が立ち上がる前のPre-Boot環境で調査します。UEFI SHELL for x64にてPCIコマンドを使い各 config register のDump値を見ます。UEFI SHELLの詳細はこちら


BIOS / DVMT Pre-Allocated = 64MB

TOLUD = C800_0000
BDSM  = C400_0000
BGSM  = C380_0000

UMA確保分は
GFX Stolen Size = TOLUD - BDSM = 64MB
GFX GTT Stolen Size = BDSM - BGSM = 8MB
となりました。

BIOS / DVMT Pre-Allocated = 1024MB

TOLUD = C800_0000
BDSM  = 8800_0000
BGSM  = 8780_0000

UMA確保分は
GFX Stolen Size = TOLUD - BDSM = 1024MB
GFX GTT Stolen Size = BDSM - BGSM = 8MB
となりました。

GFX GTT Stolen Sizeはどのマザーボードでも8MBで固定のようです。GFX Stolen Sizeは自作PCのマザーボードBIOSでは「DVMT Pre-Allocated 」の項目として設定できるようです。

PCI Aperture Size
MSACのダンプを見てみますと1bとなっており、Apeetureのサイズは256MBと判明しました。最近のBIOSでは256MB固定のようです。

MSAC = 00001b
PCIe graphics memory aperture size = 256MB



検証環境その2
★MeltdownとSpectre対策パッチ済
■CPU Intel Pentium G4560 3.50 GHz (Kaby Lake-S)
■GPU ntel HD Graphics 610
■マザーボード GIGABYTE GA-B250M-D3H BIOS Ver. F9d
    Graphics Output Protocol (GOP) Version: 9.0.1056
■メモリー DDR4-2133 4G x 2 Dual-Channel Mode
■SSD システムドライブ:Samsung SSD 960 EVO 250GB
■OS Microsoft Windows 10 Home 64bit Ver.1709 OSビルド 16299
    Intel Graphics Driver Version: 23.20.16.4973
    Current Resolution: 1920 x 1080

TOLUD = D000_0000
BDSM  = CC00_0000
BGSM  = CB80_0000

UMA確保分は
GFX Stolen Size = TOLUD - BDSM = 64MB
GFX GTT Stolen Size = BDSM - BGSM = 8MB
となりました。

PCIe graphics memory aperture size = 256MB



検証環境その3
Intel Core i3-7100U 内臓 Intel HD Graphics 620 

TOLUD = 9000_0000
BDSM  = 8C00_0000
BGSM  = 8B80_0000

GFX Stolen = 64MB
GFX GTT Stolen = 8MB
PCIe graphics memory aperture size = 256MB


この調査でDVMTもおおよそ概要がつかめました。
IGD にてVRAM をメインメモリに確保する手段ためのIntel独自名称。次の2つの方法をとります。
1.UMA
2.PCIe GART→IGD GARTロジック(ハード実装)+OS+Graphics Driverで構成
UMA確保分はDVMT Pre allocate をさすようです。

DVMTについてはこちら





category: PC-HW

tb: 0   cm: 0

UEFI BIOSではGOP driverが必須に!  

UEFI BIOSではGOP driverが必須に!

Intel Processor Graphics 調査メモ  はこちら
VGA互換関連についてはこちら



OSが起動するまでの間に、画面表示を担うのはBIOSです。レガシーBIOSではVGA互換が必須でした。しかし、UEFI BIOSでは、ビデオ機能としてGOP driverが必須になりました。
さて、2017年現在ではレガシBIOSを搭載したPCが徐々に減少し始め、OSの起動もUEFIブートが当たり前になり、もはやPCでDOSを動かすことは今後ないと思われます。そろそろ、レガシなグラフィック環境とはおさらばしたいものです。もうVGAやら、VBEやら0xA0000-0xBFFFFがどうの、I/Oポートアドレスがどうの等を深く理解する必要もないし、そうしたくないです。よって、PCのグラフィイクッス機能を理解する上で、ここからは調査の筋をグラフィイクッス機能の最小要素であるUEFI GOP (Graphic Output Protocol)に当てたいと思います。

UEFI BIOSの詳細はこちらの記事をご覧ください。

このUEFI GOPは当然BIOS上でのDriverであり、OSが立ち上がれば、基本使われません。UEFI BIOS時代になっても、PC/AT互換機では引き続きBIOSで使用するビデオ機能はビデオデバイス(ビデオカードやCPU内臓GPU)内のOption ROMに各デバイス供給元が作製し格納します。
Intel CPU内臓グラフィックの場合BIOSはシステムBIOS(マザーボード側のROMに入っている)に統合されています。



UEFI GOP (Graphic Output Protocol)
EFI初期にはグラフィイクッス機能としてUGAが定められていたようですが、2017年現在ではUEFI BIOS仕様PCにはGOP仕様のVideo BIOS(Option ROM , PCI Expansion ROM)を搭載したグラフィイクッス・ビデオカードが必要とされています。こちらの記事(グラフィックボード・ビデオカードのビデオBIOSとGOPドライバについて)もご覧ください。

引用始まり
Windows 8 が市場に出るタイミングは、すべての新しいクライアント システムが従来の BIOS から Unified Extensible Firmware Interface (UEFI) へと移行する時期でもあります。従来の BIOS インターフェイスも引き続きサポートされますが、UEFI インターフェイスを利用するマシンでは非常に豊富な機能を実現することができます。たとえば UEFI システムでは、Graphics Output Protocol (GOP) ドライバーを使って、ネイティブの解像度でリッチなグラフィックを使ったエクスペリエンスをレンダリングすることが可能です。UEFI の採用により、OS はようやくブート ファームウェアと標準化された方法でやり取りすることができるようになります。これは UEFI および TCG (Trusted Computing Group) の標準化への取り組みによって強力にサポートされています。これによって実現する機能として、たとえば OS とファームウェアが協力して安全なハンドオフ メカニズムを構築するセキュア ブートがあります。また、電源ボタンを押した時点からシームレスなビジュアル エクスペリエンスの提供が可能になります。2 つの別個のコンポーネントが 1 つのエクスペリエンスを共有するのです。
これまでにブート エクスペリエンスが完全に刷新されたことは、実のところ一度もありません。OS やハードウェアが対数的な進歩を続けてきた中で、BIOS メニューは 30 年近く時間が止まったような状態です。過去のいくつかの Windows リリースでは、OS 起動前の環境で使用する機能を数多く導入してきましたが、それぞれ実現できる機能や制約の違いに合わせた設計が必要でした。
引用終わり
出典
Microsoft Building Windows 8
Windows エンジニアリング チームによるブログ
Billie Sue 2011
https://blogs.msdn.microsoft.com/b8_ja/2011/09/22/windows-2/



UEFI仕様によると、グラフィイクッス機能ではConsole Supportとして、Simple Text Output ProtocolとGraphics Output Protocolを定めています。二つのプロトコルともグラフィイクッス機能のファンクションコールのみを定めていて、VGA互換のそれのようにハードウェアの仕様までは定めていないようです。

引用始まり
11.9 Graphics Output Protocol
The goal of this section is to replace the functionality that currently exists with VGA hardware and its corresponding video BIOSThe Graphics Output Protocol is a software abstraction and its goal is to support any foreseeable graphics hardware and not require VGA hardware, while at the same time also lending itself to implementation on the current generation of VGA hardware.

Simple Text Output Protocol
The minimum supported text mode of such devices is at least 80 x 25 characters.

Graphics Output Protocol
The EFI_GRAPHICS_OUTPUT_PROTOCOL supports three member functions to support the limited graphics needs of the pre-boot environment. These member functions allow the caller to draw to a virtualized frame buffer, retrieve the supported video modes, and to set a video mode. These simple primitives are sufficient to support the general needs of pre-OS firmware code.
The EFI_GRAPHICS_OUTPUT_PROTOCOL also exports enough information about the current mode for operating system startup software to access the linear frame buffer directly.
The interface structure for the Graphics Output protocol is defined in this section. A unique Graphics Output protocol must represent each video frame buffer in the system that is driven out to one or more video output devices.

11.9.1 Blt Buffer
The basic graphics operation in the EFI_GRAPHICS_OUTPUT_PROTOCOL is the Block Transfer or Blt. The Blt operation allows data to be read or written to the video adapter’s video memory. The Blt operation abstracts the video adapters hardware implementation by introducing the concept of a software Blt buffer.
The frame buffer abstracts the video display as an array of pixels. Each pixels location on the video display is defined by its X and Y coordinates. The X coordinate represents a scan line. A scan line is a horizontal line of pixels on the display. The Y coordinate represents a vertical line on the display. The upper left hand corner of the video display is defined as (0, 0) where the notation (X, Y) represents the X and Y coordinate of the pixel. The lower right corner of the video display is represented by (Width –1, Height -1).
The software Blt buffer is structured as an array of pixels. Pixel (0, 0) is the first element of the software Blt buffer. The Blt buffer can be thought of as a set of scan lines. It is possible to convert a pixel location on the video display to the Blt buffer using the following algorithm: Blt buffer array index = Y * Width + X.
Each software Blt buffer entry represents a pixel that is comprised of a 32-bit quantity. Byte zero of the Blt buffer entry represents the Red component of the pixel. Byte one of the Blt buffer entry represents the Green component of the pixel. Byte two of the Blt buffer entry represents the Blue component of the pixel. Byte three of the Blt buffer entry is reserved and must be zero. The byte values for the red, green, and blue components represent the color intensity. This color intensity value range from a minimum intensity of 0 to maximum intensity of 255.
引用終わり

解像度の最小値は定められず、色深度 32bitのようです。


EFI_GRAPHICS_OUTPUT_PROTOCOL
Summary
Provides a basic abstraction to set video modes and copy pixels to and from the graphics controller’s frame buffer. The linear address of the hardware frame buffer is also exposed so software can write directly to the video hardware.
GUID
#define EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID \
 {0x9042a9de,0x23dc,0x4a38,\
 {0x96,0xfb,0x7a,0xde,0xd0,0x80,0x51,0x6a}}
Protocol Interface Structure
typedef struct EFI_GRAPHICS_OUTPUT_PROTCOL {
 EFI_GRAPHICS_OUTPUT_PROTOCOL_QUERY_MODE QueryMode;
 EFI_GRAPHICS_OUTPUT_PROTOCOL_SET_MODE SetMode;
 EFI_GRAPHICS_OUTPUT_PROTOCOL_BLT Blt;
 EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE *Mode;
} EFI_GRAPHICS_OUTPUT_PROTOCOL;
Parameters
QueryMode Returns information for an available graphics mode that the graphics device and the set of active video output devices supports.
SetMode Set the video device into the specified mode and clears the visible portions of the output display to black.
Blt Software abstraction to draw on the video device’s frame buffer.
Mode Pointer to EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE data.Type EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE is defined in “Related Definitions” below. 
Related Definitions
EFI_PIXEL_BITMASK
EFI_GRAPHICS_PIXEL_FORMAT
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION
EFI_GRAPHICS_OUTPUT_PROTOCOL_MODE
Description
The EFI_GRAPHICS_OUTPUT_PROTOCOL provides a software abstraction to allow pixels to be drawn directly to the frame buffer. The EFI_GRAPHICS_OUTPUT_PROTOCOL is designed to be lightweight and to support the basic needs of graphics output prior to Operating System boot.



EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt()
Summary
Blt a rectangle of pixels on the graphics screen. Blt stands for BLock Transfer.

ということで、Blt とはBLock Transferの略とあります。これが2Dグラフィイクッスの主要機能のようです。

出典
Unified Extensible Firmware Interface Specification Version 2.4 June, 2013
11 Protocols — Console Support
11.4 Simple Text Output Protocol
11.9 Graphics Output Protocol



category: PC-HW

tb: 0   cm: 0

PC/AT互換機 の構成技術・規格の変遷  

最終更新日:2018/05/13

申し訳ございません。ただいま工事中!!


1984年 米IBMが16bitパーソナルコンピュータを発表。これがその起源です。

CPU  Intel 80286(16bit Protect Mode, 8086 Real Mode compati)

OS    DOS

バス規格 ATバス(16bit) 

ビデオ機能   MDA(モノクロ)またはCGA(320x200/4色)

ディスプレイI/F  ?

OSブート  BIOS

ドライブ系  FDD,HDD

オーディオ  ? 

電源管理  ?

H/W管理  ?

汎用I/F  シリアルポート、パラレルポート

出典
Diary on wind
IBM PC/ATの概要とハードウェア構成 [PC/AT +0]
http://lsair.html.xdomain.jp/a/e/g13_148_ibm_pcat_pcat_0.html


連載
IT管理者のためのPCエンサイクロペディア
-基礎から学ぶPCアーキテクチャ入門-

第3回 本家IBM PCの歴史(1)~IBM PC誕生
1. オープン・アーキテクチャのIBM PC誕生
元麻布春男
2002/06/14
http://www.atmarkit.co.jp/fsys/pcencyclopedia/003pc_history01/pc_hist01.html


category: PC-HW

tb: 0   cm: 0

SuperO C7H270-CG-ML BIOS 調査メモ  

最終更新日:2018/04/28
ただいま工事中!

BIOS 復旧方法


UEFI BIOSフラッシュチップは、2つのブートブロックとメインBIOSブロック(メインBIOSイメージ)で構成されるリカバリBIOSブロックで構成されています。
ブートブロックには、元のメインBIOSイメージが破損した場合に新しいBIOSイメージをフラッシュするメモリ検出およびリカバリコードを含むクリティカルなBIOSコードが含まれています。
  システム電源がオンになると、ブートブロックコードが最初に実行されます。
  これが完了すると、メインのBIOSコードはシステムの初期化とブートアップを続行します。
注:BIOSのメインブートがクラッシュした場合は、BIOSリカバリーの手順に従ってください。 ただし、BIOSブートブロックがクラッシュした場合は、付録Dの手順に従う必要があります。


category: PC-HW

tb: 0   cm: 0

AMI BIOS NVRAM BLOCK 調査メモ  

最終更新日:2018/04/15


まずはこのへんから情報がありそうな…
Flash BIOS User Guide
http://en.inspur.com/eportal/fileDir/en_active_download/userBook/Inspur%20Yingxin%20NF5180M4/Inspur%20BIOS%20Flash%20User%20Guide.pdf 

category: PC-HW

tb: 0   cm: 0

PCテクノロジー ストレージ基礎 調査メモ  

最終更新日:2018/04/21
ただいま工事中!!

Non-Volatile Memory Express(NVMe)とは



C++でNVMeと(*´Д`)ハァハァ 戯れていたら一年経ってた。
https://www.slideshare.net/hiyohiyo/cnvme


デハイス側の対応
AHCI(SATA)はキュー数は 1 コマンド キューで 32 コマンド / キュー
NVMe は キュー数は65536 コマンド キューで 65536 コマンド / キュー

毎秒2.7GBで神速!NVMe対応超高速SSD『Intel SSD750シリーズ』がヤバすぎる
http://weekly.ascii.jp/elem/000/000/321/321921/


キュー(queue)とは?:コンピュータでも「待ち行列」は重要|データ分析用語を解説
https://www.graffe.jp/blog/885/


●コマンドキューイング●
コマンドが終了する前に次のコマンドを受け取っておく機能です。
コマンドを先行して受け取っておき、効率がよいと思われる順番にならびかえて実行します。
HDD上に点在するデータのシーク動作が効率的に行われるため、大幅に処理が速くなります。
RATOC Systems
Q.SCSIコンフィグレーションユーティリティの機能がよくわからないのですが?
http://www.ratocsystems.com/products/subpage/scsi/products.html#command

NCQ

HDDをAHCIモードで使うメリットとしては、キャッシュ内でコマンドを並び換えることでHDDのヘッド移動のロスを最小限にするNCQ(ネイティブコマンドキューイング)が使えることが大きいが、ヘッド動作がないSSDでは性能面の効果はどうなのだろうか。NCQ対応の有無は製品情報にも記載されることがあまりないが、CrystalDiskInfoを使えば対応状況を確認できる。ここでは、NCQに対応しているIntelのX-25M

2009年10月号 DOS/V POWER REPORT |  Impress
 その他の特集 > SSD完全攻略マニュアル
SSD Q&A
Q IDE互換モードとAHCIモードはどっちが速い?
http://www.dosv.jp/other/0910/07.htm


ATA, SATA, USB, IEEE1394, ファイバチャネルと言ったものはあくまでデータの通り道であり、全てSCSIのプロトコルがベースになっています。
続:なんてこったい。
SCSIって。。 
https://blogs.yahoo.co.jp/kawajun_island/59154040.html


 Native Command Queuingは、SCSIが持つTagged Command Queuingの考え方を継承して設計された機能であり、Race-free Status Return Mechanism、Interrupt Aggregation、First Party DMA(FPDMA)という3つの機能によって支えられている。
SCSIユーザも注目!? の
シリアルATA Native Command Queuing
(2003年12月8日)
[Text by 伊勢雅英]
https://pc.watch.impress.co.jp/docs/2003/1208/it012.htm

NCQ can deal with up to 32 commands at a time, while TCQ can deal with up to 216 commands (TCQ hard disk drives, however, can usually support a queue of “only” 64 commands).
Hardware Secrets
NCQ (Native Command Queuing) and TCQ (Tagged Command Queuing) Explained
By Gabriel Torres -  April 16, 2006 
http://www.hardwaresecrets.com/ncq-native-command-queuing-and-tcq-tagged-command-queuing-explained/




CrystalDiskMark
CrystalDiskMark 4/5/6 はベンチマーク部に Microsoft DiskSpd (The MIT License) を使用しております。そのためベンチマーク結果は CrystalDiskMark 3 と互換性がありません。

QはQueue Depthの略で命令を対象デバイスに一度に発行する数でありQueueの数ではない。


Ver. 6
4K Q8T8が新登場。これの意味合いはマルチスレッド数が8個になったところと、Queue Depthが8と浅くなったところはサーバーなどのSSD向けの項目のためか?

ソフトウェアCrystalDiskMark
https://crystalmark.info/ja/software/crystaldiskmark/

SSD S.M.A.R.T.
CrystalDiskMark (Version 5)  Edit
Random Read 4KiB diskspd.exe -b4K -d5 -o1 -t1 -W0 -r -S -w0 TestFilePath
http://ssdsmart.wicurio.com/index.php?%E3%83%99%E3%83%B3%E3%83%81%E3%83%9E%E3%83%BC%E3%82%AF%E3%82%BD%E3%83%95%E3%83%88


IOmater使い方
puti se note
ベンチマーク:Iometerの設定方法・使用方法、ストレージパフォーマンステスト(ディスク負荷テスト)
http://www.putise.com/stress-test/iometer






category: PC-HW

tb: 0   cm: 0

Intel グラフィックス製品の歴史  

最終更新日:2018/05/19
Intel グラフィックス製品の歴史


Intel Processor Graphics 調査メモ  はこちらから


PC Graphics の歴史は

PC技術興亡史
グラフィックス編
第1回:最初のグラフィックスは、単純なフレームバッファー 
第2回:サードパーティーが推進した、IBM PCグラフィックスのカラー化 
第3回:VGAからXGAへ、IBMがグラフィックス規格を引っ張る 
第4回:グラフィックス拡張機能の乱立から、VESAによる標準化へ 
第5回:Windows時代に入り、グラフィックスアクセラレーター登場 
第6回:Windowsでもゲームを!DirectXが登場 
第7回:グラフィクスは単純な描画機構から、プログラマブルに進化 
第8回:グラフィックスは差別化が困難に、そしてモバイルに新たな競争が 
大原 雄介=フリーランス テクニカルライター 2015/03/18
http://tech.nikkeibp.co.jp/にて記事検索「PC技術興亡史」して下さい。

をご覧ください。


Intel グラフィックス製品の歴史をたどっていくときのポイントでまず抑えるのはバスの世代の変化にります。
バスの世代の変化 PCI-> AGP -> PCIe
大きな転換点はPCIeの登場です。


次は、内臓グラフィックの統合レベルです。
MCH内臓 -> CPUダイ統合
CPUダイ統合でLLCがCPUと共有できる点は非常に大きな意味を持つのではないでしょうか?


その次はOSです。
Windows 2000/xp(32bit)-> Vista(32bit)  -> 7(64bit) -> 10(64bit)
大きな転換点は2つ。
・Vista でWDDMが登場し、OS、デバイスドライバの関係等、その他様々な点が変わった。
・64bit Windows 7 の普及でメインメモリの容量の壁がなくなった。


最後にPCファームウエアの変遷です。
BIOS(VGA互換機能) -> UEFI BIOS(GOP Driver)
意外と忘れがちなのですが、OSが起動するまで画面描画を担うのはファームウエアです。メーカーのロゴやらCPUやメモリを認識したメッセージをディスプレイで見ることができるのもファームウエアのお陰です。PC/AT互換機のファームウエアといえば、永らくBIOSが使われてきました。そのBIOSで必要とされるビデオ機能はソフトウェア(API)とハードウェア(I/O Port Address,IRQ)の両方に及んでいました。いわゆるVGA互換と呼ばれるものです。従来、PC/AT互換機で使用するすべてのビデオカードや内臓グラフィイクッスにはこのVGA互換機能が埋め込まれてきました。レガシーをずーと引きずってきた訳です。しかし、そのレガシーをようやく捨て去れる時期がやってこようとしています。それは、レガシーBIOSに代わる新しいBIOS、そう、UEFI BIOSの登場です。2012年ごろよりWindows 8の登場と伴にPCのファームウエアにUEFI BIOSが普及し始めました。そして、2018年現在、コンシュマー用PCではUEFI BIOSの普及率はかなり高くなってきていると思われます。そして、ついにインテルはこのレガシーを2020年までにUEFI BIOSから削除する構想を明らかにしました。

Intel is removing legacy BIOS support from
client & data center platforms by 2020
• Platforms will be strictly UEFI Class 3
No 16-bit OpROM (VGA, LAN, Storage)
This will break any customer process that
depends on “disabling UEFI” (“CSM ON”)

"Last Mile" Barriers to
Removing Legacy BIOS
Fall 2017 UEFI Plugfest
October 30 – November 3, 2017
Presented by Brian Richardson (Intel Corporation)
http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf

このインテルの構想に賛同するハードウェアベンダーがどれだけいるかはわかりませんが、少なくとも、2018年現在でDOSを使う人はもういないし、Linux OSもUEFI BIOS対応が終わっているようですし、もうレガシーをきれいさっぱり捨て去るのがよいと思います。そうしないと、なにより、PCの勉強をする若い人がいつまでも、レガシーな知識を身につけなければならない、それは、”将来への重荷”になっていると思います。


UEFI BIOSについてはこちらの記事をご覧ください。




その歴史概要

AGPインターフェイス
1997年 Intel 初のAGPインターフェイス搭載チップセット 440LXが登場した。
ディスクリートビデオカード
1998年 Intel 740 発表。Intel唯一のディスクリートビデオカード。初のAGP対応ビデオチップ。
IGT (Intel Graphics Technology) コア
1999年 チップセット Intel 810 インテル社初のグラフィック(Direct AGP)統合チップセット DVMT対応
Intel Extreme Graphics
2001年~ チップセット Intel 830 に統合。
2004年~ Intel Graphics Media Accelerator(GMA)
チップセット Intel 915G(PCIe)以降に統合
2010年~ Intel HD Graphics 
CPUダイに統合(Sandy Bridge以降、Arrandale,Clarkdaleはパッケージ統合)


出典
Tom's Hardware Graphics Slideshow
Evolution Of Intel Graphics: i740 To Iris Pro
 by Michael Justin Allen Sexton  2017
http://www.tomshardware.com/picturestory/693-intel-graphics-evolution.html#s1


ASCII PCI登場から440BXまで Intelチップセットの歴史 その1 2009年 大原雄介
http://ascii.jp/elem/000/000/475/475852/index-3.html


AKIBA PC Hotline! HotHot REVIEW!
統合型チップセットの大本命登場
  ~ Intel810搭載マザーボード ~
1999年6月 [Text by 笠原一輝@ユービック・コンピューティング]
http://pc.watch.impress.co.jp/docs/article/990611/hotrev14.htm


@IT > System Insider > 解説 > 今後の10年を占う新Pentium 4プラットフォームを考察する
1.PCI Expressをサポートした初のチップセット
2.新チップセットで強化された機能
元麻布春男 2004年

List of Intel graphics processing units
From Wikipedia, the free encyclopedia
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units



チップセット 440LXについて


初のAGPインターフェイスを搭載チップセットで正式には
INTEL 440LX AGPSET: 82443LX PCI
A.G.P. CONTROLLER (PAC)
となるようです。

AGPはIntelが考案した規格で、Pentium II用チップセットのIntel 440LXで初めて実装された。PCIバスのプロトコルなどをベースとしながら、8bit幅のアドレスバスを別途用意するほか、DME(Direct Memory Execute)と呼ばれる機能を実装。テクスチャをメインメモリ上に直接置くことで、ビデオカード側に実装するビデオメモリ量を削減し、ひいてはビデオカードの低価格化を実現させるものであった。

やじうまPC Watch
【懐パーツ】3Dグラフィックス界の風雲児、「Intel 740」搭載ビデオカード
劉 尭2016年11月15日 06:00
https://pc.watch.impress.co.jp/docs/news/yajiuma/1029873.html


で、この440LXチップセットのデータシートを見てみますと、Aperture SizeやらAperture Translation Table Base Registerなどのレジスタがありました。



PCI Configuration Space—Device 0 (Host-to-PCI Bridge)
B4h APSIZE Aperture Size Control Register
B8–BBh ATTBASE Aperture Translation Table Base Register

出典
INTEL 440LX AGPSET: 82443LX PCI
A.G.P. CONTROLLER (PAC)
Datasheet.
REVISION HISTORY
July, 1997 -001 first release.
January, 1998 -002.




Intel 810では専用のビデオメモリを持たず、メインメモリと共有するUMA (Unified Memory Architecture) を採用。





AGP(Accelerated Graphics Port)
引用始まり
 Intel社が'96年に発表した、グラフィックスアクセラレータとシステムメモリを結ぶ高速な専用バス(最大転送速度は現行のPCIバスが132MB/秒であるのに対し、533MB/秒)の規格で、主として3Dグラフィックスやフルモーションビデオに有用な以下の2つのメリットを提供する。

「高速な専用バスの確保」  様々なデバイスが使用するPCIバスとは独立した形で、グラフィックスアクセラレータ専用の高速バスを用意することによって、グラフィックスシステムのパフォーマンスを向上させる。
「メインメモリの共有」  テクスチャマッピング(立体の表面にグラフィックスを貼ること)を直接メインメモリから実行できるようになるので、そのための大量のメモリをビデオカード上に搭載しておく必要が無くなる(2D用の2~4MBといった少ないメモリだけでも、高品位な3Dアクセラレーションが期待できる)。
引用終わり
PC Watch 鈴木直美の「PC Watch先週のキーワード」
第3回【'97/10/13~10/17】
SGRAM RAMDAC AGP SDK DirectX OpenGL
http://pc.watch.impress.co.jp/docs/article/971021/key3.htm


引用始まり
もっとも、このAGPはご存知のとおり、3Dグラフィックスカードで「テクスチャーデータをメインメモリーからビデオメモリーへと高速に転送する」という目的で作られたもの。バスの構造もこれにあわせて最適化されているし、ソフトウェアの面でも「GART」(Graphics Address Remapping Table) Driverを使うことが前提となっている
引用終わり
ASCII バスの歴史を振り返る PCIからAGP、PCI-X編 2011年 大原雄介
PCIを超える2つの規格 AGPとPCI-X
http://ascii.jp/elem/000/000/618/618492/index-3.html


Direct Memory Execute(DIME)

Executeモード
AGPの実行モードの1つ。Direct Memory Execute(DIME)とも呼ばれる。OSがメインメモリーの一部をAGPメモリーとして獲得し、グラフィックスチップが直接アクセス可能なようにする。このとき、AGPメモリーはUC(Uncache)に属性が変更される。当然、アプリケーションからはこのメモリー領域は使えなくなり、メインメモリーがAGPメモリー分だけ少なくなったように見える。
出典
ASCII.jpデジタル用語辞典
http://yougo.ascii.jp/caltar/Execute%E3%83%A2%E3%83%BC%E3%83%89



引用始まり
Taking advantage of AGP's DIME (Direct Memory Execute , see "AGP - A New Interface for Graphic Accelerators" ) however is somewhat more difficult. DIME needs to allocate some system RAM via the OS to access large textures via AGP outside the local graphic memory of the card. The OS has to know what it's doing and hence definitely needs an extension that enables this procedure. Unfortunately there isn't any such extension available for Windows NT 4 yet, but if you realize, that NT is currently anyhow not the right platform for playing 3D games (no Direct3D support, only DirectDraw and others with SP3) you will understand why NT users will have to wait for a decent AGP implementation until NT 5 is released. For the majority of users however which are using Windows 95 (especially for games) there are three things necessary:
引用終わり
出典
Tom's Hardware   AGP - The Practice by Thomas Pabst 1997 
http://www.tomshardware.com/reviews/agp,35.html



GART(Graphics Address Remapping Table) 
Consistent with that emphasis,this interface specification requires a physical-to-physical address remapping mechanism which insures the graphics accelerator (an A.G.P. master) will have a contiguous view of graphics data structures dynamically allocated in system memory.
Remapping is accomplished via a memory-based table called the Graphics Address Remapping Table (GART) and used (“walked”) by the corelogic to perform the remapping. In order to avoid compatibility issues and allow future implementation flexibility, this mechanism is specified at a software (API) level. In other words, the actual GART table format is not specified; rather it is abstracted to the API by a HAL or miniport driver that must be provided with the corelogic. While this API does not constrain the future partitioning of remapping hardware, the remapping function will initially be implemented in the chipset or corelogic
引用元
Accelerated Graphics Port
Interface Specification
Revision 2.0
Intel Corporation
May 4, 1998
Intel
2. Architectural Context and Scope
2.1 Two Usage Models: “Execute” and “DMA”



Intel 810 Chipset(初のグラフィイクッス機能搭載チップセット)
Product Features
Integrated Graphics Memory Controller
Intel D.V.M. Technology
AGP External Port Not Support

/Host-Hub Interface Bridge/DRAM Controller(Device 0) Registers
|SMRAM -> System Management RAM Control Register
||Graphics Mode Select (GMS). 
This field is used to enable/disable the internal graphics device and select the amount of system memory that is used to support the internal graphics device.
00 = Graphics Device Disabled, No memory used (Device 1 is not accessible in this case)
01 = Reserved
10 = Graphics Device Enabled, 512 KB of memory used
11 = Graphics Device Enabled 1 MB of memory used
The 512 KB and 1 MB space selected by this field is used by video BIOS for handling support of VGA when no GMCH graphics driver is present (e.g., a DOS boot).
|MISCC -> Miscellaneous Control Register
||Graphics Display Cache Window Size Select.
0 = 64 MB (default)
1 = 32 MB. See GMADR Register (Device 1).
/IGD(Device 1) MMIO Base Address Registers(BARs)
|GMADR -> Graphics Memory Range Address Register
|MMADR -> Memory Mapped Range Address Register

出典
Intel 810 Chipset: Intel 82810/82810-DC100 Graphics and Memory Controller Hub (GMCH) Datasheet June 1999


引用始まり
 810チップセットは、「Whitney」のコードネームで呼ばれていた低価格PC向けのチップセット。ノースブリッジにAGP対応の2D/3Dビデオ機能が統合されているのが特徴。最上位の「810DC100」と、標準の「810」、廉価版の「810-L」の3製品が用意される。量産開始はすべて6月からで、1万個受注時の価格は、それぞれ3,910円/3,600円/3,120円となっている。

 3製品の構成は、I/Oコントローラの性能によって区分されている。最上位の「810DC100」は4MBのディスプレイキャッシュ(オプション)を追加できる。その他は「810」と共通で、ATA/66に対応するほか最大6スロットのPCIバスをサポートする。廉価版の「810-L」のみ、ATA/66に対応せず、PCIバスも最大4スロットとなる。

 ビデオ機能は、ソフトウェアDVD-Video再生をアクセラレートするモーションコンペンセーション(動き補償)に対応するほか、コントローラを統合する「ダイレクトAGP」などの技術により、AGP 2X相当の性能を実現したという。AC '97 signaling link対応のコントローラも搭載し、ソフトウェアによるオーディオ/モデム機能の提供が可能。また、スリープ状態からの復帰が従来より高速になる「Instantly Available PC技術」の対応機能が追加されている。標準構成ではISAバスをサポートしないが、オプションで対応する。
引用終わり
出典
PC Watch インテル、Celeron 466MHzと810チップセットを正式発表 ('99年4月26日)
http://pc.watch.impress.co.jp/docs/article/990426/intel.htm



引用始まり
Intelの説明によると、この統合チップセットでは、現在チップセットとビデオチップに入っているAGPのコントローラ回路とAGPのピンが不要になり、またメモリコントローラを統合、フレームバッファを削減できるためコストが削減できるという。フレームバッファには、システムメモリの一部を割り当てる。また、AGPではシステムメモリをテクスチャバッファなどに割り当てるが、この新しいアーキテクチャでは、もともとフレームメモリもシステムメモリを使っているため、テキスチャメモリなどにもダイナミックにシステムメモリの一部をアロケートできる。つまり、“AGPライク”なフィーチャを実現できると言う。AGPと異なり、ビデオチップが外部のチップセットにアクセスするロスもないため、AGPのレイテンシなどの問題も解決されるかも知れない。

 しかし、3~4年ほど前に共有メモリ構成(UMA)が騒がれた時は、システムメモリを共有した場合は、システム全体のパフォーマンスが落ちることが指摘された。それに対して、Intelは、当時と比べると、メモリ容量が大きくなりメモリ帯域も広くなったことで、システムパフォーマンスに与える影響はずっと小さくなったと主張する。ただし、このチップセットでは、サポートメモリはIntelが次世代高速DRAMとして押している広帯域のDirect RDRAMではなくSDRAMとなる見込みだ。これは、ローコストシステムでは、当初はコスト高が見込まれるDirect RDRAMが受け入れられないためと見られる。また、同社では、現在チップセットを製造している0.35ミクロンプロセスよりも高集積化が可能な、0.25ミクロンプロセス技術への移行が、チップセット統合の背景にあることを説明した。
引用終わり
出典
PC Watch 後藤弘茂のWeekly海外ニュース ('98年9月18日)
IDF速報:レガシーフリー化と低コスト
-Intelが次世代チップセットやマザーボードの戦略を明らかに-
ビデオ統合チップセットを投入
http://pc.watch.impress.co.jp/docs/article/980918/kaigai01.htm


引用始まり
GMCHに内蔵されているグラフィックスコアは、「Portola(ポルトラ)」のコードネームで呼ばれていた新グラフィックスチップ「Intel 752」だ。グラフィックスコアとメモリコントローラの間は、AGP 2x相当の帯域で結ばれているという。利点は、AGPの問題点だったレイテンシが、メモリコントローラとグラフィックスコアの一体化でかなり解消されたことだ。グラフィックスコアは、システムメモリの一部をグラフィックス用領域として使うUMA構成を取る。
引用終わり
出典
PC Watch 後藤弘茂のWeekly海外ニュース ('99年4月28日)
Intel 810登場、Intel版MediaGXはいつ?
https://pc.watch.impress.co.jp/docs/article/990428/kaigai01.htm


引用始まり
The Intel 810 chipset takes two major leaps forward from today’s shared memory solutions – complex integration of memory controller and graphics capability (Direct AGP) and advanced dynamic memory utilization (Dynamic Video Memory Technology – D.V.M.T.).

3.2 Direct AGP
Direct AGP provides the integrated graphics function the capability to make direct memory set-up calls (similar to those associated with standard AGP protocol) to system memory resulting in life-like video quality. 
引用終わり
出典
Intel 810 Chipset Great Performance for Value PCs Revision 2.1 May 30, 2000
3. Intel Graphics Technology for the Value PC Segment


Intel 815 Chipset
/Host-Hub Interface Bridge/DRAM Controller(Device 0) Registers
|SMRAM -> System Management RAM Control Register
||Graphics Mode Select (GMS). This field is used to enable/disable the Internal Graphics device and select the amount of main memory that is “Stolen” to support the internal graphics device in VGA (nonlinear) mode only. These 2 bits only have meaning if we are not in AGP mode.
00 = Internal graphics device Disabled, No memory “Stolen”
01 = Internal graphics device Enabled, No memory “Stolen”
10 = Internal graphics device Enabled, 512 KB of memory “Stolen” for frame buffer.
11 = Internal graphics device Enabled, 1 MB of memory “Stolen” for frame buffer.
|MISCC -> Miscellaneous Control Register
||Graphics Translation Window Size Select—R/W. In GFX mode this would be the size of the GTT (Graphics Translation Table). Not a valid bit in AGP mode.
0 = 64 MB (default)
1 = 32 MB.
/IGD MMIO Base Address Registers(BARs)
|GMADR -> Graphics Memory Range Address Register
|MMADR -> Memory Mapped Range Address Register

出典
Intel 815 Chipset Family: 82815 Graphics and Memory Controller Hub (GMCH) Datasheet June 2000



Intel 830 Chipset
/SDRAM Controller/Host-hub Interface Device Registers -Device #0
|GCC1-–GMCH Control Register #1
||Graphics Mode Select (GMS). This field is used to select the amount of Main Memory that is preallocated to support the Internal Graphics device in VGA (non-linear) and Native (linear) modes. These 3 bits are valid only when Internal graphics is enabled.
000 = No memory pre-allocated (Graphics memory Disabled) [RESERVED]
001 = No memory pre-allocated (Graphics memory Enabled) [RESERVED]
010 = DVMT (UMA) mode, 512K of memory pre-allocated for frame buffer
011 = DVMT (UMA) mode, 1M of memory pre-allocated for frame buffer
100 = DVMT (UMA) mode, 8M of memory pre-allocated for frame buffer)
||Device 2: Graphics Memory Aperture Size (Controls GMADR register in Device#2)
0 = 128 MB(default)
1 = 64 MB
/IGD MMIO Base Address Registers(BARs)
|GMADR -> Graphics Memory Range Address Register
|MMADR -> Memory Mapped Range Address Register

出典
Intel® 830 Chipset Family: 82830 Graphics and Memory Controller Hub (GMCH-M) Datasheet January 2002



Intel 915 Chipset 


インテルも「10年に一度の抜本的な変革をもたらす」と新しいチップセットを評価しているそうです。
PCIeを初めて実装 915Gは初PCIe GART?
内蔵GPUは「GMA900」の搭載
Linux のIntel ドライバもこのチップセットを基本としているようです。i915 .

/Host Bridge/DRAM Controller PCI Register Details (D0:F0)
|GGC—GMCH Graphics Control Register
||Graphics Mode Select (GMS): This field is used to select the amount of main memory that is pre-allocated to support the Internal Graphics device in VGA (non-linear) and Native (linear) modes. The BIOS ensures that memory is preallocated only when Internal graphics is enabled. Device 2 (IGD) does not claim VGA cycles (memory and I/O), and the Sub-Class Code field within Device 2,Function 0 Class Code register is 80h.
000 = No memory pre-allocated
001 = DVMT (UMA) mode, 1 MB of memory pre-allocated for frame buffer.
010 = Reserved.
011 = DVMT (UMA) mode, 8 MB of memory pre-allocated for frame buffer.
100–111 = Reserved.
/Integrated Graphics Device PCI Register Details (D2:F0)
|GMADR -> Graphics Memory Range Address Register
|GTTADRGraphics Translation Table Range Address
This register requests allocation for Graphics Translation Table Range. The allocation is for 256 KB.
|BSM—Base of Stolen Memory
Graphics Stolen Memory and TSEG are within DRAM space defined under TOLUD. From the top of low used DRAM, GMCH claims 1 to 64 MBs of DRAM for internal graphics, if enabled.
|MSAC—Multi Size Aperture Control
This register determines the size of the graphics memory aperture in function 0 and in the trusted space. By default, the aperture size is 256 MB (bit 27 read only). If bit 1 is set to a 1, then the aperture size is limited to 128 MB.
※この時点ではGTT Stolen Memory(GSM)専用RangeはなくBSM内に確保している模様です。
2018/05/09追記
GTT Stolen Memory(GSM)の物理アドレスがDevice 2: Function 0のPGTBL_CTL register (MMIO 2020)にあるようです。

11 System Address Map 
The Address Map includes a number of programmable ranges: 
• Device 2: Function 0 (82915G/82915GV/82915GL/82910GL GMCH only)
⎯ MMADR – IGD registers and internal graphics instruction port. (512-KB window)
⎯ IOBAR – I/O access window for the GMCH internal graphics. Through this window
address/data register pair, using I/O semantics, the IGD and internal graphics instruction
port registers can be accessed. Note, this allows accessing the same registers as
MMADR. In addition, the IOBAR can be used to issue writes to the GTTADR table.
⎯ GMADR – Internal graphics translation window. (256-MB window)
⎯ GTTADR – Internal graphics translation table location. (256-KB window). Note that the
PGTBL_CTL register (MMIO 2020) indicates the physical address base which is 4 KB
aligned. 



機能


インテル®SDVOポートは、対応するGMCHからの第2世代のデジタルビデオ出力です。



データへの高帯域幅アクセスは、グラフィックスおよびシステムメモリポートを介して提供されます。 GMCHは、4.2 GB /秒〜8.5 GB /秒(メモリ構成に応じて)のシステムメモリにあるグラフィックスデータにアクセスできます。

GMCHはIntelのダイレクトメモリ実行モデルを使用してシステムメモリからテクスチャをフェッチします。 GMCHには、最近使用されたテクスチャデータの頻繁なメモリフェッチを避けるためのキャッシュコントローラが含まれています。

GMCHは、統合型DAC、および/またはADD2カードを駆動できる2つのSDVOポート(PCI Expressで多重化)を駆動することができます。外部SDVOデバイスは、最大2048x1536 @ 75 Hzの解像度で標準プログレッシブスキャンアナログモニタを駆動することができます。 SDVOポートは、さまざまなTV-Out、TMDS、およびLVDSトランスミッタを駆動することができます。


GMCHの内部グラフィックスデバイス(IGD)には、いくつかのタイプのコンポーネントが含まれています。 IGDの主なコンポーネントはエンジン、プレーン、パイプ、ポートです。
GMCHには、3Dおよび2Dエンジンを制御する3D / 2D命令処理ユニットがあります。 IGDの3Dおよび2Dエンジンには、メモリコントローラを介してデータが供給されます。エンジンの出力は、メモリに送られたサーフェスで、GMCHプレーンによって取得され、処理されます。

GMCHには、さまざまなプレーン(ディスプレイ、オーバーレイ、カーソル、VGAなど)が含まれています。平面は、ソース、サイズ、位置、方法、フォーマットなどの特性を持つ長方形のイメージから構成されます。これらの面は、似たような特性を持つ矩形のメモリサーフェスであるソースサーフェスにアタッチされます。それらは特定の宛先パイプにも関連付けられています。

パイプは、組み合わされたプレーンとタイミングジェネレータのセットで構成されています。 GMCHには2つの独立した表示パイプがあり、2つの独立した表示ストリームのサポートが可能です。 ポートは、パイプの結果の宛先です。 GMCHには3つのディスプレイポート、1つのアナログ(DAC)と2つのデジタル(SDVOポートBおよびC)が含まれています。 

12 Functional Description
12.5 Intel® Serial Digital Video Output (SDVO)
12.6 Integrated Graphics Device
より抜粋しGoogle 翻訳した。



出典
Intel® 915G/915GV/915GL/915P/915PL/910GL Express Chipset Datasheet For the Intel® 82915G/82915GV/82915GL/82910GL Graphics and Memory Controller Hub (GMCH) and the Intel® 82915P/82915PL Memory Controller Hub (MCH) February 2005



現在のAGPは、PCIバスをベースに開発されたものだが、PCIバスより高いデータ転送速度を確保するための物理的、電気的な変更だけでなく、ソフトウェア的にも異なるものとなっている。こうしたソフトウェア的な変更が、ある意味でAGPをグラフィックス専用にしているわけだが、PCI Expressのx16スロットをそのまま利用する将来のグラフィックス・スロットは、ソフトウェア的にも汎用のPCI Expressスロットと変わらない。例えばAGPの特徴的な機能の1つとしてはGART*4のサポートが挙げられるが、PCI ExpressではGARTのサポートは行われない。これはPentium III以降のプロセッサ自体がGARTに相当する「Page Attribute Table」をサポートしているため、不要と判断されたことによる。
*4 Graphics Address Remapping Table:メイン・メモリの一部をAGPメモリとして確保し、グラフィックス・コントローラが直接そのアドレスをアクセスすることを可能にする機能。

解説
PCI-X 2.0とPCI Expressのインパクト(後編)
――新しい拡張インターフェイスの実体とその影響を探る――
3. 次世代のI/O規格「PCI Express」は何が変わるのか?
元麻布春男
2002/10/11
http://www.atmarkit.co.jp/fsys/kaisetsu/009pci_innovation/pci_innov03.html



Intel 2th-7th Core Processor
/PCI Device 0, Function 0 Configuration Registers
|GGC—GMCH Graphics Control Register
|-|GTT Graphics Memory Size (GGMS)
This field is used to select the amount of Main Memory that is preallocated to support the Internal Graphics Translation Table. 
1h = 1 MB of pre-allocated memory
2h = 2 MB of pre-allocated memory
0h = No pre-allocated memory
||Graphics Mode Select (GMS)
This field is used to select the amount of main memory that is preallocated to support the Internal Graphics device in VGA (nonlinear) and Native (linear) modes. 
0h = 0 MB - 512 MB
|BDSM—Base Data of Stolen Memory Register
The base address of stolen DRAM memory
|BGSM—Base of GTT stolen Memory Register
The base address of stolen DRAM memory for the GTT
/Processor Graphics Registers
|GMADR -> Graphics Memory Range Address Register
|GTTMMADR—Graphics Translation Table ,Memory Mapped Range Address
|MSAC—Multi Size Aperture Control
7th Core MAX 4096 MB.

出典
2nd Generation Intel Core Processor Family Desktop,
Intel Pentium Processor Family Desktop, and
Intel Celeron Processor Family Desktop
Datasheet, Volume 2 September 2011



Intel 7th Core Processor
/Host Bridge/DRAM Registers
GMCH Graphics Control Register (GGC)
Base Data of Stolen Memory (BDSM)
Base of GTT stolen Memory (BGSM)
/Processor Graphics Registers
Graphics Translation Table, Memory Mapped Range Address (GTTMMADR)*
Graphics Memory Range Address (GMADR)*
I/O Base Address (IOBAR)*→I/O portアドレスです。レガシー用?
Base Data of Stolen Memory (BDSM)
Multi Size Aperture Control (MSAC)
*は標準BAR


出典
7th Generation Intel® Processor
Families for S Platforms and Intel®
CoreTM X-Series Processor Family
Datasheet, Volume 2 of 2
May 2017



Intel® Open Source HD Graphics
Programmer's Reference Manual
For the 2016 Intel Atom™ Processors, Celeron™ Processors, and
Pentium™ Processors based on the "Apollo Lake" Platform
(Broxton Graphics)
Volume 2b: Command Reference: Registers
 May 2017, Revision 1.0
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-bxt-vol02b-commandreference-registers.pdf
※ATOM内臓のHD Graphics のドキュメントですが、その世代はKaby Lakeと同じ第9世代ですので問題ないと思われます。

によりますと

GMCH Graphics Control Register(GGC) / Graphics Mode Select(GMS):
このフィールドは、VGA(非線形)モードおよびNative(リニア)モードで内部グラフィックスデバイスをサポートするために事前に割り当てられたメインメモリの量を選択するために使用されます。 BIOSは、内部グラフィックスが有効な場合にのみメモリが事前に割り当てられるようにします。 IGDが無効/有効になっているため、ハードウェアはこれらのビットを自動的にクリアまたは設定しません。
BIOS要件:IVD(このレジスタのビット1)が0の場合、BIOSはこのフィールドを0hに設定してはなりません。
BIOS要件:新しいサイズでは8MBまでの割り当てが可能であるため、BIOSはWOPCMと基本的なGFX Stolen 機能のための十分なスペースがあることを保証する必要があります。

00h:0MB
01h:32MB
02h:64MB
03h:96MB
etc..

GMCH Graphics Control Register(GGC) / GTT Graphics Memory Size(GGMS):
このフィールドは、内部グラフィックス変換テーブルをサポートするためにあらかじめ割り当てられているメインメモリの量を選択するために使用されます。BIOSは、内部グラフィックスが有効な場合にのみメモリが事前に割り当てられるようにします。GSMはDSMとの連続した物理的なDRAM空間であると想定され、BIOSは連続したメモリチャンクを割り当てる必要があります。
ハードウェアは、レジスタにプログラムされたGSMサイズのみを使用してDSMからGSMのベースを導出します。この値を予約済みにプログラミングする場合のハードウェア機能は保証されていません。

0x0:No Preallocated Memory
0x1:2MB of Preallocated Memory
0x2:4MB of Preallocated Memory
0x3:8MB of Preallocated Memory

となっています。



GTTMMADR(PCI BAR)は16MBが必要。
GMADR(PCI BAR) は  Multi Size Aperture Control (MSAC)で決まる。
GMADRはMMIO内でのPCIe GARTのApertureの開始アドレスになります。この値はOSが設定します。また、このApertureのサイズはBIOSがMulti Size Aperture Control (MSAC)の値を設定することで決定します。

GTTMMADR
このレジスタは、統合されたグラフィックス変換テーブル変更範囲とメモリマップ範囲の割り当てを要求します。この範囲には、MMIOおよびグローバルGTTアパーチャに合わせて16 MBが必要です.MMIOで使用される2 MBとGTTで8 MBが使用されます。

GTTADRは(GTTMMADR + 8 MB)から始まり、MMIOのベースアドレスはGTTMMADRと同じです。(GTTMMADR + 2MB) - (GTTMMADR + 8MB)の間の領域は予約されています。

  グローバルGTTの場合、この範囲はグラフィックスデバイスの設定領域のメモリBARとして定義されます。これは、ページテーブルエントリ値(PTE)を書き込むためにソフトウェアが必要とされる別名です。ソフトウェアは、グローバルグラフィックス変換テーブル(GTT)からPTE値を読み取ることができる。PTEはグローバルGTTメモリ領域に直接書き込むことはできません。  デバイスは、オンチップで実装されたさまざまなTLB内のキャッシュされた変換を無効にするために、この領域への書き込みをスヌープします。

割り当ては16MBで、ベースアドレスはビット[38:24]で定義され、OSが割り当てる。


          8MB   ->  Global GTT Table Aperture
GTTADR  --------------------------
          6MB   -> Reserved 
          -----------------
          2MB   -> MMIO
GTTMMADR ------------------------------------------------------

Multi Size Aperture Control (MSAC)
APSZ4: This field is used in conjunction with other APSZ* fields to determine the size
of Aperture (GMADR) and affects certain bits of GMADR register. The description below
is for all APSZ* fields 4:0 -

00000 = 128MB => GMADR.B[26:4] is hardwired to 0
00001 = 256MB => GMADR.B[27] = 0, R0
00010 = illegal (hardware will treat this as 00011)
00011 = 512MB => GMADR.B[28:27] = 0, R0
0100—00110 = illegal (hardware will treat this as 00111)
00111: 1024MB => GMADR.B[29:27] = 0, RO
000-01110 = illegal (hardware will treat this as 01111)
01111= 2048MB => GMADR.B[30:27] = 0, R0
10000-11110 = illegal (hardware will treat this as 11111)
11111 = 4096MB => GMADR.B[31:27] = 0, RO







category: PC-HW

tb: 0   cm: 0

インテルプロセッサグラフィックのvBIOSをROMPERSERする。  

インテルプロセッサグラフィックのvBIOSをROMPERSERしてみました。


ROMライターで吸い上げた、マザーボード ASUS PRIME H270-PLUS のBIOSをROMPERSERしたところ、


15225592961810.jpg 


のような結果となりました。
IGDなのでビデオ機能関連コードは本体BIOSに統合されています。CSMのためにVGA互換のコードを残しているようです。しかし、ナント!デバイスIDはHASWELL IGDになっています。最近はこれに手を入れていないのでしょう。




category: PC-HW

tb: 0   cm: 0

DMA(Direct Memory Access)関連調査メモ  

DMA

下の表にしたような、高速通信を行う必要がある周辺I/Oデバイスコントローラは、DMAマスタ機能を内蔵しているものがあるよ。

周辺I/Oデバイス 主な接続バス 備考
ハードディスク SCSI、IDE/ATA、Serial ATA
グラフィックス AGP、PCI Express
USBホスト PCI(USB2.0)、PCI Express(USB3.0) UHCI、OHCI、EHCI、xHCI
ネットワーク PCI Ethernet

これらのコントローラは、自分専用のDMACを内蔵していて、DMAマスタになって能動的にDMA転送を起動することができるんだ。USBホストやEthernetコントローラは、一般にPCI系のバスに接続されていることが多い。

PCIバスの規格では、接続したデバイスがDMAマスタになる機能がサポートされているため、DMA転送とは非常に相性がいいんだ。

このようなDMAマスタデバイスを「バスマスタ型デバイス」と言うこともある。最近のPCでは、USBやネットワークは必須機能になっているから、最初からマザーボードやチップセットに内蔵されている。

例えば、Intelチップセットでは、ICH(I/O Controller Hub)というコンパニオンチップにまとめられているんだ。こういう場合も、CPUとはPCIと互換性のあるバスで接続されているので、ソフトウェア(デバイスドライバ)の視点からはPCIの場合と同じように扱うことができるんだよ。

出典
学校では教えてくれないこと
DMA対応と言われたら(1)
https://www.uquest.co.jp/embedded/learning/lecture15-1.html





DMAの仕様としてISAで規定されていて、

DMAコントローラとして主に使用されていた代表的なICとして8237Aがあります

( 8237Aのデータシート がダウンロードできますので興味の有る方はダウンロードしてみてください)

DMAコントローラ8237Aが導入されたのはIBM PCからとなります。

DMAコントローラ8237Aは4つのチャンネルがありますので、4つのデバイスのデータ転送が可能となります

ATXマザーボードでは1つのDMAコントローラのみでしたが、現在のPCでは2つのICで合計8のデバイスの

データ転送が可能となっています。 割り込みその2で見てきたPICと同じように2つのICが連結されています

2つのDMAコントローラは4MHzのクロックで動作しています。



現在のパソコンでは、ISAのDMAでは8つのデバイスしか転送できない、また64kBまでのメモリまでしか

アクセスできない(理由は後述します)、転送速度が遅いためHDDなどの大容量デバイスかつ高速な

デバイスはUDMA(Ultra Direct Memory Access)が使用されています。

しかし、フロッピーディスクなどの昔からあるデバイスをサポートするためにISAのDMAは

現在でも残っていますので、ISA仕様のDMAは現在のパソコンでも残っています。

このサイトではISA仕様のDMAをISA DMAと表記します
出典
ISA(Industry Standard Architecture)とDMA
http://softwaretechnique.jp/OS_Development/kernel_development13.html












category: PC-HW

tb: 0   cm: 0

VGA(Video Graphics Array)関連調査メモ  

最終更新日:2018/05/15

申し訳ございません。ただいま工事中!!


Intel Processor Graphics 調査メモ  はこちら



グラフィック・ビデオ機能を掘り下げるにはやはり「VGA互換」周りの情報をこれまた掘り下げる必要がありそうです。



VGA(Video Graphics Array)
一般に「VGA」「XGA」で解像度を意味することが多いが、元々はIBMのグラフィックスアダプターの名称を指していた。
出典
日経テクノロジーオンライン HOME > エレクトロニクス > 電子デバイス > 
PC技術興亡史  グラフィックス編 第1回~第4回
大原 雄介=フリーランス テクニカルライター 2015/03/04
http://techon.nikkeibp.co.jp/article/FEATURE/20150106/397325/



●VGA(Video Graphics Array)
 IBM社が'87年に、同社のPS/2シリーズ用に開発したグラフィックスアダプタ(ビデオカード)の規格。

 一部の専用アクセラレータを除くと、現在は全てのグラフィックスアダプタが備えている標準的なビデオサブシステムで、システムのインストール時やセイフティモード、DOSモードなどで、このVGAの画面モードが使われている。特に640×480ドットは、VGAの代表的な画面サイズであるため、しばしばこのサイズだけを指して「VGA」といわれることもあるが、実際には表のように、MDA(Monochrome Display Adapter)やCGA(Color Graphics Adapter)、EGA(Enhanced Graphics Adapter)といった旧来のアダプタが備えていた多彩なモードも網羅しており(※1)、80×25文字のテキストモード(解像度的には720×400ドットで、EGAに比べ縦方向が50ドット増えている)や、320×200ドット 256色のグラフィックスモードも備えている。
出典
PC Watch ■鈴木直美の「PC Watch先週のキーワード」 ■
第67回【'99/2/22~ 2/26】
http://pc.watch.impress.co.jp/docs/article/990304/key67.htm




PC/AT互換機においてUEFI BIOSより昔のレガシーBIOS環境ではVideo BIOSがVGA/VBE互換機能を必要とする。
引用始まり
ディスクインターフェイスカードおよびグラフィックカードは別途搭載する必要がありました。
ディスクインターフェイスについては今回扱う話ではないので詳細は割愛しますが、これら2種のインターフェイスはそれぞれマザーボード本体に搭載されているBIOS ROMを拡張するためのディスクBIOSおよびビデオBIOSを搭載していて、当時提供されていたPC-DOS(MS-DOS)をはじめとする対応OSではその拡張BIOSの機能を呼び出して利用していました。また、それゆえにそれらの拡張BIOSではOSとのデータのやりとりに用いるI/Oポートやメモリアドレス、それにレジスタの扱いなどが厳密に定義されていました。
つまり、IBM PCに搭載されたグラフィックカードは本来、いずれもハードウェア(グラフィックコントローラおよびその使用リソース)とソフトウェア(ビデオBIOS)が不可分の規格なのです。
引用終わり
出典
連載:IT因縁話「VGA≠画面解像度(1)~はじまりはMDA・CGAから~」
by tsuchitani [2014年3月31日]
http://app-review.jp/news/177312




フレームバッファ (Frame Buffer)
 画面に表示するための文字やイメージを記録しておくためのメモリ。ビデオバッファ、あるいはビデオメモリ、ビデオRAM(VRAM)とも。ただし、ビデオメモリやVRAMといった場合、フレームバッファを含む(一般的なビデオカードではフレームバッファが大半を占める)ビデオ回路用のメモリ全体を指すのに対し、フレームバッファは、純粋な画面表示領域のことをいう。

 フレームバッファは、通常はメインメモリの一部として割り付けられており、直接、あるいはグラフィックス回路の描画機能等を使って、ここに画面イメージが書き込まれる。書き込まれたイメージは、DAC(Digital to Analog Converter)によって、ディスプレイのタイミングに合せたビデオ信号に変換され画面に表示される。

 グラフィックスモードにおけるフレームバッファの持ち方には、大きく分けると「プレーナ(Planar)方式」と「パックドピクセル(Packed Pixel)方式」とがある。

プレーナ方式は、VGA(Video Graphics Array)の16色モード等で用いられているタイプで、複数のプレーン(Plane~面)を使って1枚のフレームバッファを構成している。
 例えばVGAの場合には、「赤/緑/青/輝度」の要素に対応する、640bit×480bit相当のプレーンが4枚用意されており、これら各プレーンのビットが組みになって(すなわち4bitで)画面上の1ピクセルの情報を表している(*1)。ちなみにVGAの場合には、各プレーンは同一アドレス上にマッピングされているが、98シリーズのように、別のアドレスに置かれる場合もある。

 一方の「パックドピクセル(Packed Pixel)方式」は、VGAの256色モードをはじめとする、Windowsの一般的な高解像度モードで用いられている方式で、1つのフレームバッファは、ひとつのメモリ上にフラットに割り付けられる(言い替えれば1フレーム1プレーン)。例えば256色の場合には、1ピクセルは8bit――すなわち1バイトなの で、1ピクセルに対応したバイト列が、メモリ上にシーケンシャルに並ぶことになる。現行のビデオカードでは、1ピクセルは、8、16、24、32bitのいずれかの値をとり、8bitの場合は、色情報そのものではなく256種類の色情報がセットされたカラーパレット(カラールックアップテーブル)を指すポインタが、16bit以上ではそのままRGBのカラー情報がここに書き込まれる(*2)。


(*1) VGAでは、プレーンの要素が実際の色を表わすのではなく色情報がセットされたカラーパレットを指すポインタになっている。
(*2) 32bitは、メモリを4バイト単位に扱うだけで、ピクセル情報はこのうちの24bit分だけが使用される。ベンダーによっては、この隙間のない24bitのモードのことを特別に「パックドピクセル」と呼ぶことがある。

■鈴木直美の「PC Watch先週のキーワード」 ■
第20回:2月23日~2月27日
https://pc.watch.impress.co.jp/docs/article/980303/key20.htm#FrameBuffer




VESA BIOS Extension(VBE)
VESA(Video Electronics Standards Association) が制定した VGA 以上の高解像度表示を行う BIOS の仕様です。

VBE の歴史
VGA 規格は IBM が開発し、長年その仕様が守られつづけています。それが故にどのような Video board でも VGA BIOS より定義された API を使用することで、Video board の区別無く、Video memory を制御出来るのです。

その後 Video board は、Windows の影響もあり VGA より更に高画質を実装することになります。が当時、各社独自の方法で進化してしまった関係上、統一した Video 制御が出来ませんでした。Windows の場合は、各社独自に Driver を開発することで高画質を実現することが出来ましたが、それ以外の OS では長らくサポートすることが出来ませんでした。

このような状況で VBE の開発が行われることになります。

VBE ではフレームバッファを操作する統一的な API を定義しました。Vidoe board 各社、VBE をサポートすることにより、独自の Driver を作成することなく Video 制御が可能になります。

#なるはずでしたと言った方が良いかも知れません ;-(。

Mc.N Homepage SDK
[M.D.L] VESA BIOS Extension(VBE) について
http://mcn.oops.jp/lab/etc/vbe.htm






引用始まり
Windows XPの標準のディスプレイ・ドライバ
 こうした問題が生じていた直接の理由は、セーフモードで利用されるグラフィックス・ドライバが、「VGAドライバ」であったことだ。640×480ドット、16色というのは、標準VGAがサポートする最大の解像度であるこのVGAドライバは、Windowsが標準でサポートしていないグラフィックス・チップの場合でも使われる。そもそもVGAは、1987年にリリースされたIBM PS/2の上位モデルに採用されたグラフィックス技術だ。「標準」という点では、この15年近く前の技術が進歩せずに、現在まで使われてきたわけだ。Windows XPでは、この部分が大きく変わる。標準で用いられるディスプレイ・ドライバが、VGA対応からSVGA(SuperVGA)対応に変わるのである。

(一部省略)

VBE 3.0対応で実現したセーフモードの高解像度サポート
 以上のような高解像度モードのサポートは、「標準ディスプレイ・ドライバ」がVESAのVBE 3.0(VESA BIOS Extension 3.0)をサポートすることにより実現されているVBEとは、もともとのVGA BIOS(ビデオBIOS)の仕様をベースに拡張を施した、PCのグラフィックス・サブシステムのためのファームウェア・インターフェイス規格である。ディスプレイ関連規格をとりまとめているVESA(Video Electronics Standards Association)が策定している。最新版であるVBE 3.0には、いわゆるVGA BIOSの拡張だけでなく、プロテクト・モードから拡張機能(VGAに対する)を呼び出すエントリ・ポイントが用意されており、Windows XPの標準ドライバは、このプロテクト・モード・インターフェイスを用いている。したがって、専用ディスプレイ・ドライバを用いずに高解像度を利用するには、グラフィックス・カードがVBE 3.0をサポートしていることが不可欠となるので注意していただきたい(VBE 3.0に対応していなくても、専用ドライバがあれば高解像度表示は可能)

 もちろん、標準ドライバがVBE 3.0に対応したからといって、専用ディスプレイ・ドライバが不要になるわけではない。確かに標準ドライバだけでも高解像度表示は可能だが、ハードウェアが持つアクセラレーション機能が利用できないため、画面表示がかなり遅くなる。当然のことだが、3Dグラフィックス機能や動画表示関連の機能を用いることもできない。あくまでも、専用ドライバが利用できないような非常事態向けの機能といえるかもしれないが、セットアップ時、あるいはセーフモード時も高解像度が利用可能になるメリットは大きい。少なくともセーフモードでのメンテナンス中に、ダイアログ・ボックスの表示が画面からはみ出す、といったトラブルからは解放されるハズだ。

VBE 3.0対応はUGAサポートへの第一歩
 標準ドライバが高解像度表示に対応することで、Windows XPのディスプレイ機能は、確実に一歩前進する。が、進歩はここで止まるわけではない。Windows XPのさらに次のバージョン「Blackcomb(開発コード名:ブラッコム)」以降のOSでは、UGA(Universal Graphics Adapter)と呼ばれるディスプレイ標準の採用が検討されている。

 VGAまでの標準ディスプレイ技術(CGA、MDA、EGAなど)は、標準化されたBIOSインターフェイスを備えると同時に、I/Oアドレスやレジスタといったハードウェア・インターフェイスの標準が定義されていた。それにより、ハードウェアに直接アクセスするDOSアプリケーション・レベルでの互換性を保証していた。しかし、時代は移り変わり、アプリケーションがハードウェアに直接アクセスすることは事実上なくなった。WindowsなどGUIに対応したアクセラレータ(というより、現在市販されているすべてのグラフィックス・チップ)は、VGAを超えた部分でのハードウェア・レベルの互換性は持たないが、それぞれのOSに対応したデバイス・ドライバを用意することで、ハードウェア・レベルの互換性を不要にしている。

 UGAでは、こうした考えに基づき、ハードウェア・インターフェイスの標準を定めない。定められるのは、VGA BIOSに代わるUGAファームウェアのインターフェイスであり、このインターフェイスに準拠していれば、特にハードウェアをどう設計しなければならない、ということはなくなる。逆に求められるのは、VGA互換のハードウェア・インターフェイスを用いないことだ。

 UGAの狙いは、VGA BIOSに代わるUGAファームウェアのインターフェイス(ソフトウェア・インターフェイス)を定義することで、VGAという旧式のデバイス(レガシー・デバイス)を除去することにある、と考えられる。上記のとおりVGAは、特定のI/Oアドレス、特定のメモリ・アドレスなど、ハードウェア依存のリソースを用いる。こうしたリソースの存在は、システムの自由度を低くするだけでなく、使い勝手の低下を招く。

(一部省略)

 UGAに準拠したグラフィックス・チップ(を用いたグラフィックス・カード)は、完全なプラグ&プレイが保証されると同時に、複数枚のカードを同時に利用することが容易になる。システムの起動と、OSのセットアップやセーフモードの画面表示は、UGAファームウェアと、これに対応したディスプレイ・ドライバで実現されるが、3Dグラフィックスなど高度な機能にはやはりグラフィックス・チップごとに対応した専用のディスプレイ・ドライバが必要になると考えられる。現時点では詳細は明らかにされていないが、UGAファームウェアの機能は、VBE 3.0の機能を強化したものになる、と考えるのが常識的だろう。サーバなど、グラフィックス機能を必要としないプラットフォームでは、OS標準のUGAドライバを用いるものも出てくるかもしれない。
引用終わり
出典
ITmedia Windows XPの正体 セーフモードが高解像度対応になるWindows XP
元麻布春男 2001/07/12

元麻布氏が上記の記事で触れていたUGAは後に策定されたEFI仕様のグラフィックス表示プロトコルとして定義されているUGA (Universal Graphic Adapters) となった模様です。しかし、UEFI BIOS
が普及した2017年では、グラフィックス表示プロトコルはGOP (Graphic Output Protocol) が主流のようです。



VGA Hardware
Port I/O: The VGA needs 8-bit read/writes, and 16-bit writes.
MMIO: The VGA uses uncached byte accesses to 0xA0000-0xBFFFF. 

VGA Registers
Note that PCI boards do *not* report the VGA addresses in their configuration space, and that the addresses can not be remapped. It is therefore not possible to properly operate two cards in VGA mode at the same time.

Video Memory Layout
The video memory consists of four 'planes' (individual units) of memory, each with a size of 64KB, giving the VGA 256k of video memory.
出典
OSDev.org Hardware Video VGA Resources and VGA Hardware documentation
http://wiki.osdev.org/Main_Page

I/Oポートアドレスマップの例
0x3B0-0x3BF VGA/モノクロビデオ
0x3C0-0x3CF VGA/EGAビデオ
0x3D0-0x3DF VGA/CGAビデオ


VGA/VBE BIOSとWindows 3.x のビデオカード・デバイスドライバの関係

DOSしかなかった頃は、DOSはVGA/VBE BIOSを利用し、アプリケーションにビデオ機能を提供していた。一部のDOSアプリケーションはビデオカード・デバイスドライバを自前で実装していた。しかし、Windows 3.xの登場でマルチタスクになり、VGA/VBE BIOSは使えなくなった。そのため、専用のビデオカード・デバイスドライバを各ビデオカードメーカーは用意するようになった。ここから、BIOSとデバイスドライバの2重ビデオ機能構造が始まったようです。そして、Windows OSが全盛なった以降、VGA/VBE BIOSはOSブート前の一瞬かセーフモードの時しか使われなくなってしまったようです。


それにしても、PCのビデオ機能は歴史的に紆余曲折があり、容易に理解しがたいものですね!





UEFI BIOS CSM
2018年現在はUEFI BIOSが主流となりましたが、まだ、CSMとしてレガシーな要素が生き残っています。特にビデオ機能は残っているケースが多いようです。以下のの記事もご覧ください。



category: PC-HW

tb: 0   cm: 0

Intel ME 調査メモ  

最終更新日: 2017/11/27 07:39

調査したメモを随時更新中!



最近、下記記事にあるように話題になり、その脆弱性を指摘された UEFIとIntel ME ですが、諸悪の根源はIntel ME であり、UEFIはあくまでも、PCのファームウエアの仕様でしかないと思います。そこで、この謎のブラックボックスであるIntel MEを調査し、メモします。

PC Watch ニュース / Google、ユーザーの知らないところで動くUEFIの脆弱性に警鐘
https://pc.watch.impress.co.jp/docs/news/1090501.html


Intelでは、現在のプラットフォームがこの脆弱性を抱えているかどうかを検出するためのツール「Intel-SA-00086 Detection Tool」を提供し、ユーザーが判別できるようにしている

Intel Management Engineなどに8個の脆弱性が発見
~第6世代Core以降が影響、ThinkPadなどがすでに対策開始
劉 尭2017年11月22日 16:33
https://pc.watch.impress.co.jp/docs/news/1093023.html



ASUSのホームページでは早速、改良したMEのファームウエアが公開された。


MEUpdateTool
Intel has identified security issue that could potentially place impacted platform at risk. 
Use ME Update tool to update your ME.
*We suggest you update ME Driver to the latest Version 11.7.0.1040 simultaneously. 

2017/11/22
BIOS & FIRMWARE
https://www.asus.com/jp/Motherboards/PRIME-H270-PLUS/HelpDesk_BIOS/



インテルMEの秘密 - チップセットに隠されたコードと、それが一体何をするかを見出す方法 - by イゴール・スコチンスキー - Igor Skochinsky
https://www.slideshare.net/codeblue_jp/me-32214055

上記記事によりますと、PCHにはマイコンが搭載されており、CPUが動いいていなくとも、そのPCのリソースを使い様々のことができてしまうそうです。最近のPCHにはARCというマイコンが搭載されているそうです。

DesignWare ARCプロセッサ・コア 
https://www.synopsys.com/jp2/ip/processorip/arcprocessors/pages/default.aspx



Intel MEは常にPCのブート・コンフィグレーションに深くかかわっているようで、単に法人ユーザなどがPCの管理コストを下げるツール機能だけではないようです。



category: PC-HW

tb: 0   cm: 0

SPIの前は何が使われていた? 調査メモ  

最終更新日: 2018/04/14 10:35

Sorry. This article is now writing!
SPIの前は何が使われていた?



■Firmware Hub(FWH)
 FWHはBIOSやPOSTなどのプログラムを格納するフラッシュメモリとしての役割を持っている。こうしたフラッシュメモリはこれまではISAバス(Xバス)経由で接続されることが多かったが、FWHはICHに直結されており、ISAバスを必要としない。2種類あるFWH(82802ABと82802AC)の違いは、このフラッシュメモリの容量であり、82802ABが512Mbytes、82802ACが1Mbytesである。  FWHはフラッシュメモリ以外にRandom Number Generator(RNG)というハードウェアによる乱数発生回路を内蔵しており、暗号化などセキュリティの強化に利用できる。

@IT > @IT総合検索 > Insider's Computer Dictionary > [Intel 810] 最終更新日: 2002/05/29
http://www.atmarkit.co.jp/icd/root/17/7885617.html









【CeBIT 2004】Intelが次世代チップセットIntel 925X/915シリーズを公開

Intel® 5 Series Chipset and
Intel® 3400 Series Chipset
Datasheet
January 2012


5.24 Serial Peripheral Interface (SPI)

5.24.1.2 Descriptor Mode
Descriptor Mode is required for all SKUs of the PCH. It enables many new features of
the chipset:
• Integrated Gigabit Ethernet and Host processor for Gigabit Ethernet Software
• Intel® Active Management Technology
• Intel® Quiet System Technology
• Intel® Management Engine Firmware
• PCI Express* root port configuration
• Supports up to two SPI components using two separate chip select pins
• Hardware enforced security restricting master accesses to different regions
• Chipset Soft Strap regions provides the ability to use Flash NVM as an alternative to
hardware pull-up/pull-down resistors for the PCH and Processor
• Supports the SPI Fast Read instruction and frequencies of up to 33 MHz
Uses standardized Flash Instruction Set



5.24.1.2.1 SPI Flash Regions
In Descriptor Mode the Flash is divided into five separate regions:

Region Content
0 Flash Descriptor
1 BIOS
2 Management Engine
3 Gigabit Ethernet
4 Platform Data

Only three masters can access the four regions: Host processor running BIOS code,
Integrated Gigabit Ethernet and Host processor running Gigabit Ethernet Software, and
Management Engine. The only required region is Region 0, the Flash Descriptor. Region
0 must be located in the first sector of device 0 (offset 0). 


Flash Region Sizes
SPI flash space requirements differ by platform and configuration. The Flash Descriptor
requires one 4 KB or larger block.

5.24.2 Flash Descriptor
The maximum size of the Flash Descriptor is 4 KB. If the block/sector size of the SPI
flash device is greater than 4 KB, the flash descriptor will only use the first 4 KB of the
first block. The flash descriptor requires its own block at the bottom of memory (00h).
The information stored in the Flash Descriptor can only be written during the
manufacturing process as its read/write permissions must be set to Read only when the
computer leaves the manufacturing floor.

The Flash Descriptor is made up of eleven sections (see Figure 5-13). 

1. The Flash signature selects Descriptor Mode as well as verifies if the flash is
programmed and functioning. The data at the bottom of the flash (offset 0) must be
0FF0A55Ah to be in Descriptor mode. 

2. The Descriptor map has pointers to the other five descriptor sections as well as the
size of each.


4. The Region section points to the three other regions as well as the size of each
region. 

5. The master region contains the security settings for the flash, granting read/write
permissions for each region and identifying each master by a requestor ID. See
Section 5.24.2.1 for more information.

6 & 7. The Processor and PCH chipset soft strap sections contain Processor and PCH
configurable parameters. 








category: PC-HW

tb: 0   cm: 0

Intel Kaby Lake-S Datasheet の調査メモ  

最終更新日 2017/11/12 15:34

Intel Kaby Lake-S Datasheet でBIOS ROMやSPIを調査したメモです。


7th Generation Intel® Processor
Families for S Platforms and Intel®
CoreT X-Series Processor Family
Datasheet, Volume 2 of 2

Supporting 7th Generation Intel® CoreTM Processor Families, Intel®
Pentium® Processor Family, and Intel® Celeron® Processor Family for
S Platforms and Intel® Core""' X-Series Processor Platforms

May 2017


2 Processor Configuration Register Definitions and Address Ranges
|--2.6 PCI Memory Address Range (TOLUD - 4 GB)
     |--2.6.4 High BIOS Area

セキュリティ上の理由から、プロセッサはこの範囲を確実にDMIにデコードします。
このポジティブデコードは、重なり合う範囲が無視されることを保証する。
これにより、ブートベクタとBIOSがPCHを実行するようになります。
PCIメモリアドレス範囲の上位2 MB(FFE0_0000h〜FFFF_FFFFh)は、
システムBIOS(High BIOS)、PCIデバイス用の拡張BIOS、およびシステムBIOSのA20エイリアスに予約されています。
プロセッサはリセット後にHigh BIOSから実行を開始します。 この領域は積極的にDMIにデコードされます。 BIOSに必要な実際のアドレス空間は2 MB未満です。
ただし、この領域の最小プロセッサMTRR範囲は2 MBです。 したがって、完全な2
MBを考慮する必要があります。




Intel® 200 (including X299) and
Intel® Z370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 1 of 2

October 2017
Revision 003


4 Memory Mapping
|--4.3 Memory Map
     |--4.3.1 Boot Block Update Scheme

The PCH supports a “Top-Block Swap” mode that has the PCH swap the top block in the
FWH or SPI flash (the boot block) with another location. This allows for safe update of
the Boot Block (even if a power failure occurs). When the “top-swap” enable bit is set,
the PCH will invert A16 for cycles going to the upper two 64—KB blocks in the FWH or
appropriate address lines as selected in Boot Block Size (BOOT_BLOCK_SIZE) soft
strap for SPI.

For FHW when top swap is enabled, accesses to FFFF_0000h-FFFF_FFFFh are directed
to FFFE_0000h-FFFE_FFFFh and vice versa. When the Top Swap Enable bit is 0, the PCH
will not invert A16.

For SPI when top swap is enabled, the behavior is as described below. When the Top
Swap Enable bit is O, the PCH will not invert any address bit.



9 Pin Straps
The following signals are used for static configuration. They are sampled at the rising
edge of RSMRST# or PCH_PWROK to select configuration and then revert later to their
normal usage. To invoke the associated mode, the signal should be driven at least four
PCI clocks prior to the time it is sampled.

The PCH implements soft straps, which are used to configure specific functions within
the PCH and processor very early in the boot process before BIOS or software
intervention. The PCH will read soft strap data out of the SPI device prior to the de-
assertion of reset to both the Intel Management Engine and the Host system.

静的構成には以下の信号が使用されます。
RSMRST#またはPCH_PWROKの立ち上がりエッジでサンプリングされ、コンフィギュレーションを選択した後、通常の使用状態に戻します。
関連モードを起動するには、サンプリングされる前に少なくとも4つのPCIクロックで信号を駆動する必要があります。

PCHはソフトストラップを実装しています。ソフトストラップは、BIOSやソフトウェアの介入前に起動プロセスの早い段階で、PCHとプロセッサ内の特定の機能を設定するために使用されます。
PCHは、インテルマネジメントエンジンとホストシステムの両方にリセットを解除する前に、ソフトウェアのストラップデータをSPIデバイスから読み込みます




32 Serial Peripheral Interface for FIash/TPM (SPI0)

|--32.3 概要
PCHは、システムフラッシュおよびTPMデバイスをサポートするための1つのシリアル周辺インターフェイス(SPI0)を提供します。
インターフェイスは3つのチップセレクト信号(CS#)を実装し、最大2つのフラッシュデバイスと1つのTPMデバイスをPCHに接続できます。
CS0#とCS1#はフラッシュデバイスに使用され、CS2#はTPM専用です。
SPIインタフェースは、1.8Vまたは3.3Vのいずれかをサポートします。

注:この章で説明するSPIインタフェースは、フラッシュとTPMのサポートのみを対象としています。
このインタフェースは、汎用SPI(GSPI)など、このドキュメントで説明されている他のSPIとは異なります。

|--32.7 Functional Description


32.7.1.2.2 SPI Flash Regions
In Descriptor Mode the Flash is divided into five separate regions.

Table 32-1. SPI Flash Regions

Region Content
0 Flash Descriptor
1 BIOS
2 Intel Management Engine
3 Gigabit Ethernet
4 Platform Data
8 EC

リージョンにアクセスできるマスターは4つだけです。
BIOSコードを実行するホストプロセッサ、ギガビットイーサネットソフトウェアを実行する内蔵ギガビットイーサネットおよびホストプロセッサ、Intel Management Engine、およびEC。
フラッシュディスクリプタとインテル®MEリージョンは、唯一の必須リージョンです。
フラッシュディスクリプタは領域0になければならず、領域0はデバイス0(オフセット0)の最初のセクタに配置する必要があります。 その他の地域は、任意の順序で編成することができます。
リージョンは複数のコンポーネントにわたって拡張できますが、連続している必要があります。


32.7.1.3 Flashディスクリプタ
フラッシュコンポーネント0のボトムセクタにはフラッシュディスクリプタが含まれています。
Flash Descriptorの最大サイズは4 KBです。
SPIフラッシュデバイスのブロック/セクタサイズが4 KBより大きい場合、フラッシュディスクリプタは最初のブロックの最初の4 KBのみを使用します。
フラッシュディスクリプタは、メモリの最下部(00h)に独自のブロックを必要とします。
フラッシュディスクリプタに格納されている情報は、製造プロセス中にのみ書き込むことができます。その理由は、コンピュータが製造現場を離れるときに読み込み/書き込み許可を読み取り専用に設定する必要があるからです。
フラッシュディスクリプタは、図32-1に示すように11つのセクションで構成されています。

フラッシュシグネチャは、ディスクリプタモードを選択するとともに、フラッシュがプログラムされ、機能しているかどうかを確認します。 ディスクリプタモードにするには、フラッシュの最下部(オフセット10h)のデータが0FF0A55Ahでなければなりません。

Descriptorマップには、他の5つのディスクリプタセクションへのポインタと、それぞれのディスクリプタセクションのポインタがあります。

コンポーネントセクションには、システム内のSPIフラッシュに関する情報が含まれています。
(チップ消去のような)無効な命令、及び読み出し、高速読み出し及び書き込み/消去命令のための周波数のうちの少なくとも1つを含むことができる。

Regionセクションは、3つの他のリージョンと各リージョンのサイズを指します。

マスターリージョンには、フラッシュのセキュリティ設定が含まれており、各リージョンの読み取り/書き込みパーミッションを付与し、各マスターをリクエスタIDで識別します。

プロセッサおよびPCHソフトストラップセクションには、プロセッサおよびPCHの設定可能なパラメータが含まれています。

32.7.1.3.1ディスクリプタ・マスター領域
マスタ領域は、SPIデバイスの各領域の読み出しおよび書き込みアクセス設定を定義します。 マスター領域は、BIOS、ギガビットイーサネット、管理エンジン、およびECの4つのマスターを認識します。 各マスタは、プライマリ領域の直接読み取りのみを許可されています。


32.7.1.4 Flash Access
There are two types of accesses: Direct Access and Program Register Accesses.
32.7.1.4.1 Direct Access
Masters are allowed to do direct read only of their primary region
— Gigabit Ethernet region can only be directly accessed by the Gigabit Ethernet
controller. Gigabit Ethernet software must use Program Registers to access the
Gigabit Ethernet region.

Master's Host or Management Engine virtual read address is converted into the SPI
Flash Linear Address (FLA) using the Flash Descriptor Region Base/Limit registers

32.7.1.4.2 Program Register Access
Program Register Accesses are not allowed to cross a 4-KB boundary and can not
issue a command that might extend across two components

Software programs the FLA corresponding to the region desired
— Software must read the devices Primary Region Base/Limit address to create a
FLA.




Intel® 200 (including X299) and
Intel® Z370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 2 of 2

October 2017
Revision 005







8 SP1 Interface (D31:F5)
8.1 SP1 Configuration Registers Summary

8.1.8 BIOS Control (BIOS_SPI_BC)—Offset DCh

OS Function Hide (OSFH): This bit controls read access to SPI‘s
Device ID, Vendor ID PCI Config register. This bit does not affect
access to any other PCI Config registers. This bit is locked with
BILD. Trusted BIOS must set this bit prior to starting the OS.

0 : DeviceID, VendorID can be read

1 : reads to Device ID, Vendor ID return invalid data



BIOS Interface Lock-Down (BILD): When set, prevents TS and
BBS from being changed. This bit can only be written from O to 1
once.







category: PC-HW

tb: 0   cm: 0

UEFI Platform Initialization (PI) Specification の調査メモです。  

最終更新日 2018/04/01 16:15

Sorry! Now Writing!



UEFI and EDK II Learning and Development
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-EDKII-Learning-Dev


Lesson_1_PEI_and_Course_Intro

セキュリティ(SEC)はプラットフォーム初期化の第1段階であり、プラットフォームのリセットまたは電源投入後に実行され、ファームウェアの整合性が損なわれないようにします。 SECは、プラットフォームおよびプロセッサのアーキテクチャにも依存します。

SECフェーズでは、コードは最小限に抑えられ、特定のプロセッサアーキテクチャ用のアセンブリ言語になる可能性が最も高くなります。

flashからも実行されるので、コードは圧縮されません。

また、ハードウェアデバッガを使用する場合は、リセットベクタで実行を開始します。

PEl resides in boot firmware volumes (BFVs)






月刊インターフェイス 2011/11月号
UEFI BIOS 起動フロー

SEC
アーキテクチャ依存。 マイクロコード、キャッシュをRAM 32ビットプロテクト・モード切替

PEI
スタック利用可能。C言語。ROM上のコードを直接実行。ROM上に格納されたシリコン・ドライバを実行

DXE
メインメモリ使用可能。各バス初期化。PnP


BDS







Platform Initialization (PI) Specification
Volume 3:
Shared Architectural Elements
Version 1.6 
May 2017


2 Firmware Storage Design Discussion

2.1.1.1 Flash
Flash devices are the most common non-volatile repository for firmware volumes. Flash devices are often divided into sectors (or blocks) of possibly differing sizes, each with different run-time characteristics. Flash devices have several unique qualities that are reflected in the design of the firmware file system:
• Flash devices can be erased on a sector-by-sector basis. After an erasure, all bits within a sector return to their erase value, either all 0 or all 1. 
• Flash devices can be written on a bit-by-bit basis if the change is from its erase value to the non￾erase value. For example, if the erase value is 1, then a bit with the value 1 can be changed to 0.
• Flash devices can only change from a non-erase value to an erase value by performing an erase operation on an entire flash sector.
• Some flash devices can enable or disable reads and writes to the entire flash device or to individual flash sectors.
• Some flash devices can lock the current enable or disable state of reads and writes until the next reset. 
• Flash writes and erases are often longer operations than reads.
• Flash devices often place restrictions on the operations that can be performed while a write or erase is occurring.




category: PC-HW

tb: 0   cm: 0

PCI コンフィグレーション・メカニズム1をUEFI Shell for x64で体験してみる  

UEFI Shell for x64のmm -ioコマンドでI/Oポートを叩けるようなので、これを使い、PCI コンフィグレーション・メカニズム1の動作を体感します。

調査環境
■CPU Kaby Lake-S  Intel Pentium G4560 3.50 GHz
■マザーボード ASUS PRIME H270-PLUS
■メモリー DDR4-2133 4G x 2 Dual-Channel Mode
■SSD システムドライブ:Samsung NVMe SSD 960 EVO 250GB
■OS Microsoft Windows 10 Home 64bit Ver.1709
■Chipset H270 Stepping A0
■Intel Chipset Driver Ver. 10.1.1.44
■BIOS AMI BIOS Ver. 0808 UEFI Comp Ver 2.60
■Onboard PCI Devices  なし

■UEFI Interactive Shell for x64 v2.2 by EDK 2 


それでは、PCIバスのB:0 D:0 F:0にあるホストブリッジのコンフィグレーションレジスタの内、ベンダーIDとデバイスIDを読んでみます。


CONFIG_ADDRESSレジスタ(32bit)  CF8h CF9h CFAh CFBh
Enable           バス番号        デバイス・機能番号  レジスタアドレス
1000 0000     0000 0000     0000 0000            0000 0000
8000_0000hを書き込む
CONFIG_DATAレジスタ(32bit)  CFCh CFDh CFEh CFFh
ダブルワードでレジスタ値が帰る。
CFCh がCONFIG_ADDRESSレジスタで指定したレジスタアドレスの1バイト目の値が読める。
以下、CFDh -> 2バイト目  CFEh -> 3バイト目  CFFh -> 4バイト目  となります。


UEFI Shell mmコマンド実行画面
IMG_20171028_062227.jpg 


上記のようにコンフィグレーションレジスタのベンダーID は 8086 、デバイスID は 590Fとなりました。よって、ホストブリッジのコンフィグレーションレジスタにアクセスしていることが確認できました。mmコマンドの最後でmm cf8 00000000 -w 4 -io としているのはcfch-cffhのI/O空間をCONFIG_DATAレジスタから切り離すためです。


主な参考文献/URL

PCI Express 設計の基礎と応用
畑山 仁 / 編著 CQ出版 2010年5月15日発行


Interface 増刊  改訂新版 PCIバス&PCI-Xバスの徹底研究
Interface編集部 (編集) CQ出版 2004年7月1日発行


7th Generation Intel® Processor
Families for S Platforms and Intel®
CoreTM X-Series Processor Family
Datasheet, Volume 2 of 2

Supporting 7th Generation Intel® Core Processor Families, Intel®
Pentium® Processor Family, and Intel® Celeron® Processor Family for
S Platforms and Intel® Core X-Series Processor Platforms

May 2017

2 Processor Configuration Register Definitions and Address Ranges
2.2 PCI Devices and Functions


category: PC-HW

tb: 0   cm: 0

Intel CPU の Host Bridge/DRAM Registers 内にある PCIEXBAR 調査メモ  

7th Gen Intel Processor の Host Bridge/DRAM Registers 内にあるPCIEXBAR ( PCI Express Register Range Base Address ) を下記の環境で実際に調べてみました。

目的
Intel x86 プラットフォームではCPU/チップセットがアドレス・デコード機能を実装することによりPCIeコンフィグレーションレジスタをメインメモリにマッピングしている。PCIEXBARがわかれば、PCIeコンフィグレーションレジスタがメインメモリにマップされているアドレスがわかり、そのレジスタのすべてにアクセスが可能となる。今回はそれを実際のマシンで確認する。


調査環境
■CPU Kaby Lake-S  Intel Pentium G4560 3.50 GHz
■マザーボード ASUS PRIME H270-PLUS
■メモリー DDR4-2133 4G x 2 Dual-Channel Mode
■SSD システムドライブ:Samsung NVMe SSD 960 EVO 250GB
■OS Microsoft Windows 10 Home 64bit Ver.1709
■Chipset H270 Stepping A0
■Intel Chipset Driver Ver. 10.1.1.44
■BIOS AMI BIOS Ver. 0808 UEFI Comp Ver 2.60
■Onboard PCI Devices  なし


調査方法
プリブート環境にてUEFI Interactive Shell for x64 v2.2 by EDK 2 のpci -i コマンドと dmemコマンドを実行し調査する。

調査手順
1. Pentium G4560はPCIeルートコンプレックスをCPUに内臓している。CPUの仕様書でHost Bridgeのバス、デバイス、機能の各番号を調べる。それによるとB0:D0:F0となっている。pci -i コマンドでpci -i コマンドのPCIコンフィグレーションレジスタのダンプを取る。仕様書によるとPCIEXBARレジスタは60h番地の64ビット幅。PCIEXBARは38:28ビット範囲にあり、最大39ビットのアドレスが指定できる。

pci -i コマンドのpci -i コマンド実行結果(x86はリトルエンディアン)
  PCI Segment 00 Bus 00 Device 00 Func 00 [EFI 0000000000]
  00000000: 86 80 0F 59 06 00 90 20-05 00 00 06 00 00 00 00  *...Y... ........*
  00000010: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  00000020: 00 00 00 00 00 00 00 00-00 00 00 00 43 10 94 86  *............C...*
  00000030: 00 00 00 00 E0 00 00 00-00 00 00 00 00 00 00 00  *................*
  00000040: 01 90 D1 FE 00 00 00 00-01 00 D1 FE 00 00 00 00  *................*
  00000050: C1 02 00 00 31 00 00 00-47 00 B0 C4 01 00 00 C0  *....1...G.......*
  00000060: 05 00 00 F8 00 00 00 00-01 80 D1 FE 00 00 00 00  *................*
  00000070: 00 00 00 FF 01 00 00 00-00 0C 00 FF 7F 00 00 00  *................*
  00000080: 10 00 00 00 00 11 11 00-1A 00 00 00 00 00 00 00  *................*
  00000090: 01 00 00 FF 01 00 00 00-01 00 30 3A 02 00 00 00  *..........0:....*
  000000A0: 01 00 00 00 02 00 00 00-01 00 40 3A 02 00 00 00  *..........@:....*
  000000B0: 01 00 C0 C0 01 00 40 C0-01 00 00 C0 01 00 C0 C4  *......@.........*
  000000C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  000000D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  000000E0: 09 00 10 01 51 20 01 62-C8 00 04 94 00 00 04 00  *....Q .b........*
  000000F0: 00 00 00 00 C8 0F 09 00-00 00 00 00 00 00 00 00  *................*

上記の結果から、この環境ではPCIEXBARは0_F800_0000hから始まり64MBの範囲であると判明した。バス番号は0-63まで。

2. メインメモリのアドレス0_F800_0000hからHost Bridge (B0:D0:F0)のレジスタ長に当たる4KBのダンプをdmemコマンドでとり、ベンダIDとデバイスIDがそれぞれ8086h 、590Fhとなるかを確認する。

各コンフィグレーションレジスタの区割りは4KBアライメントになり下の計算式で割り出す。
PCI Express Base Address + Bus Number * 1MB + Device Number * 32KB + Function
Number * 4KB
注意)各ナンバーは10進表現


Host Bridge dmemコマンドの実行結果(x86はリトルエンディアン)

Memory Address 00000000F8000000 1000 Bytes
  F8000000: 86 80 0F 59 06 00 90 20-05 00 00 06 00 00 00 00  *...Y... ........*
  F8000010: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  F8000020: 00 00 00 00 00 00 00 00-00 00 00 00 43 10 94 86  *............C...*
  F8000030: 00 00 00 00 E0 00 00 00-00 00 00 00 00 00 00 00  *................*
  F8000040: 01 90 D1 FE 00 00 00 00-01 00 D1 FE 00 00 00 00  *................*
  F8000050: C1 02 00 00 31 00 00 00-47 00 B0 C4 01 00 00 C0  *....1...G.......*
  F8000060: 05 00 00 F8 00 00 00 00-01 80 D1 FE 00 00 00 00  *................*
  F8000070: 00 00 00 FF 01 00 00 00-00 0C 00 FF 7F 00 00 00  *................*
  F8000080: 10 00 00 00 00 11 11 00-1A 00 00 00 00 00 00 00  *................*
  F8000090: 01 00 00 FF 01 00 00 00-01 00 30 3A 02 00 00 00  *..........0:....*
  F80000A0: 01 00 00 00 02 00 00 00-01 00 40 3A 02 00 00 00  *..........@:....*
  F80000B0: 01 00 C0 C0 01 00 40 C0-01 00 00 C0 01 00 C0 C4  *......@.........*
  F80000C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  F80000D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  F80000E0: 09 00 10 01 51 20 01 62-C8 00 04 94 00 00 04 00  *....Q .b........*
  F80000F0: 00 00 00 00 C8 0F 09 00-00 00 00 00 00 00 00 00  *................*
  F8000100: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF  *................*

     |
  F8000FF0: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF  *................*

   は後述するTOLUDレジスタ(32bit)でTOLUDは0_C4C0_0000hとなる。




次にUSB 3.0 xHCI Controller (B0:D20:F0) のコンフィグレーションレジスタも見てみる。


オフセットは32×20 (KB) = 640 × 1024 = A0000h になる。

xHCI Controller dmemコマンドの実行結果(x86はリトルエンディアン)
Memory Address 00000000F80A0000 1000 Bytes
  F80A0000: 86 80 AF A2 06 00 90 02-00 30 03 0C 00 00 80 00  *.........0......*
  F80A0010: 04 00 21 F7 00 00 00 00-00 00 00 00 00 00 00 00  *..!.............*
  F80A0020: 00 00 00 00 00 00 00 00-00 00 00 00 43 10 94 86  *............C...*
  F80A0030: 00 00 00 00 70 00 00 00-00 00 00 00 FF 01 00 00  *....p...........*
  F80A0040: FD 01 34 80 88 C6 0F 80-00 00 00 00 00 00 00 00  *..4.............*
  F80A0050: 5B 6E CE 0F 00 00 00 00-00 00 00 00 00 00 00 00  *[n..............*
  F80A0060: 30 60 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *0`..............*
  F80A0070: 01 80 C2 C1 08 00 00 00-00 00 00 00 00 00 00 00  *................*
  F80A0080: 05 00 86 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  以下省略

しかし、DRAMの価格が安くなったとはいえ、メインメモリのうち、この64MBが無駄になるとは少し悲しい気分ですぅ。
訂正
最近(2017年時点)のIntel CPU(MCH)はMemory Reclaim機能があるのを忘れていました。この機能を有効な場合、TOLUDから4Gまのメモリ範囲は4Gよりも上にリマップされメインメモリとして利用することが可能になります。したがって、上記の実例ではPCIeコンフィグレーションレジスタのマップ範囲はTOLUDより上にあるため、メモリホールとなりません。お詫びして訂正します。

Memory Reclaim機能については下記記事も参考にして下さい。
ASUS マザーボード BIOS設定項目のメモ 


category: PC-HW

tb: 0   cm: 0

Intel 100/200 PCH Primary to Sideband Bridge について  

最終更新日:2017/10/27 06:47

SkyLakeと共に登場したIntel 100 PCH より少しレジスタ構造が変わったようです。具体的には以下のようになります。

8/9シリーズチップセットPCH にあったRCBA (Root Complex Base Address)がなくなり

10 Chipset Configuration Registers
This section describes all registers and base functionality that is related to chipset
configuration and not a specific interface (such as LPC, USB, or PCI Express*). It
contains the root complex register block that describes the behavior of the upstream
internal link.
This block is mapped into memory space, using the Root Complex Base Address (RCBA)
register of the PCI-to-LPC bridge. Accesses in this space must be limited to 32-bit (DW)
quantities. Burst accesses are not allowed.

10.1 Chipset Configuration Registers (Memory Space)

0400h–0403   RPC Root Port Configuration
3400h–3403h RC   RTC Configuration
など

12 LPC Interface Bridge Registers (D31:F0)
12.1 PCI Configuration Registers (LPC I/F—D31:F0)
F0h–F3h RCBA Root Complex Base Address

出典
Intel® 8 Series/C220 Series Chipset
Family Platform Controller Hub
(PCH)
Datasheet
May 2014






P2SB(Primary to Sideband Bridge)のSideband Register Access BAR (SBREG_BAR)が登場した。

38 Primary to Sideband Bridge
(P2SB)

The PCH incorporates a wide variety of devices and functions. The registers within
these devices are mainly accessed through the primary interface, such as PCI
configuration space and IO/MMIO space. Some devices also have registers that are
distributed within the PCH Private Configuration Space at individual endpoints (Target
Port IDs) which are only accessible through the PCH Sideband Interface.

These PCH Private Configuration Space Registers can be addressed via SBREG_BAR or
through SBI Index Data pair programming.

出典
Intel® 200 (including X299) and
Intel® 2370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 1 of 2

October 2017
Revision 003


4 P2SB Bridge (D31:F1)
4.1 P2SB Configuration Registers Summary

Sideband Register Access BAR (SBREG_BAR)—Offset 10h
P2SB Control (P2SBC)—0ffset E0h
Hide Device (HIDE): When this bit is set, the P2SB will return 1s
on any PCI Configuration Read on IOSF-P. All other transactions
including PCI Configuration Writes are unaffected by this. This
does not affect reads performed on the IOSF-SB interface.

出典
Intel® 200 (including X299) and
Intel® 2370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 2 of 2

October 2017
Revision 005


略語
PCR -> PCH Private Configuration Space Registers?
IOSF -> Intel On-die Switch Fabric
IOSFはIntel SoCの標準内部バスで、PCIエミュレーションをプロトコルとしてサポートすることで、レガシードライバとの互換性を維持している。また、IOSFとは異なるサブファブリックをサポートできるサイドバンドチャネルを備えており、他社IPの取り込みもできる。

出典
後藤弘茂のWeekly海外ニュース
スモールコアCPU「Avoton」で明らかになったIntelのローパワーCPU戦略
(2013/9/9 00:00)
https://pc.watch.impress.co.jp/docs/column/kaigai/614543.html


category: PC-HW

tb: 0   cm: 0

PCのUEFI BIOS NVRAM(設定情報) 調査メモ  

最終更新日 2018/04/20 22:35


「PCのUEFI BIOS NVRAM(設定情報)は一体どこに保存されているのか」についての調査メモです。下記の実機で調べてみました。

調査環境
■CPU Kaby Lake-S  Intel Pentium G4560 3.50 GHz
■マザーボード ASUS PRIME H270-PLUS
■メモリー DDR4-2133 4G x 2 Dual-Channel Mode
■SSD システムドライブ:Samsung NVMe SSD 960 EVO 250GB
■OS Microsoft Windows 10 Home 64bit Ver.1709
■Chipset H270 Stepping A0
■Intel Chipset Driver Ver. 10.1.1.44
■BIOS AMI BIOS Ver. 0808 UEFI Comp Ver 2.60
■BIOS 128Mb Flash ROM
■Onboard PCI Devices  なし

調査環境の様子
IMG_20171028_115432.jpg 



そもそもPC/AT 互換機では…
BIOSの設定値はRTC RAM ( RTC CMOS RAM )に保管される。
詳しくは下記サイトに書かれている。
[PCAT]: RTC+CMOS RAM 関連
http://mcn.oops.jp/dev/pcat/rtc.htm


RTC RAM は現在ではRTCと共にPCHに統合されている。

Intel 200 PCHのデータシートを見てみる。

Intel® 200 (including X299) and
Intel® Z370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 1 of 2

October 2017
Revision 003


28 Real Time Clock (RTC)

28.3 Overview
The PCH contains a Motorola MC146818B-compatible real-time clock with 256 bytes of
battery-backed RAM. The real-time clock performs two key functions—keeping track of
the time of clay and storing system data, even when the system is powered down. The
RTC operates on a 32.768-KHz crystal and a 3V battery.

28.7 Functional Description
The Real Time Clock (RTC) module provides a battery backed-up date and time keeping
device with two banks of static RAM with 128 bytes each, although the first bank has
114 bytes for general purpose usage.

28.7.5 Clearing Battery-Backed RTC RAM
Clearing CMOS RAM in a PCH-based platform can be done by using a jumper on
RTCRST# or GPI. Implementations should not attempt to clear CMOS by using a
jumper to pull VccRTC low.


Intel® 200 (including X299) and
Intel® Z370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 2 of 2

October 2017
Revision 005

30 Real TIme Clock (RTC)
30.1 RTC Indexed Registers Summary

The RTC contains two sets of indexed registers that are accessed using the two
separate Index and Target registers (70h/71h or 72h/73h), as shown in the following

table:
RTC (Standard) RAM Bank
Index Name
00h Seconds
01h Seconds Alarm
02h Minutes
03h Minutes Alarm
04h Hours
05h Hours Alarm
06h Day of Week
07h Day of Month
08h Month
09h Year
0Ah Register A
0Bh Register B
0Ch Register D
0Dh Register D
0Bh-7Fh 114 Bytes of User RAM
データシートではこう書いてるが、正しくは次にようになる。
0Ah Register A
0Bh Register B
0Ch Register C
0Dh Register D
0Eh-7Fh 114 Bytes of User RAM




I / Oロケーション70hおよび71hは、リアルタイムクロックの標準的なレガシーロケーションである。このバンクのマップを表12-7に示します。ロケーション72hおよび73hは、拡張RAMにアクセスするためのものです。
拡張RAMバンクは、索引スキームを使用してアクセスされます。
 アドレスポインタとしてI / Oアドレス72hが使用され、データレジスタとしてI / Oアドレス73hが使用される。 127hを超えるインデックスアドレスは無効です。
拡張RAMが不要な場合は、無効にすることができます。

ソフトウェアは、I / Oアドレス70hでビット7の値を保持しなければなりません。
このアドレスに書き込む場合、ソフトウェアは最初に値を読み取ってから、順次アドレス書き込み中にビット7に同じ値を書き込む必要があります。
ポート70hは直接読み取ることができません。
このレジスタを読み取る唯一の方法は、Alt Accessモードです。
RTCインデックスビット6:0はポート74hから読み出し可能ですが、ビット7は常に0を返します。
ノーマル動作中にNMI#イネーブルが変更されない場合、ソフトウェアはこのビットを1回読み取ってから、その後のポート70hへのすべての書き込みの値を保持することができます。



30.2 RTC PCR Registers Summary
These registers are within the PCH Private Configuration Space which is accessible
through the PCH Sideband Interface. They can be accessed via (SBREG_BAR + PortID
+ Register Offset).

30.2.1 RTC Configuration (RC)—Offset 3400h

Upper 128 Byte Lock (UL): When set, bytes 38h-3Fh in the
upper 128 byte bank of RTC RAM are locked and cannot be
accessed. Writes will be dropped and reads will not return any
guaranteed data. Bit reset on system reset.

Lower 128 Byte Lock (LL): When set, bytes 38h-3Fh in the
lower 128 byte bank of RTC RAM are locked and cannot be
accessed. Writes will be dropped and reads will not return any
guaranteed data. Bit reset on system reset.

Upper 128 Byte Enable (UE): When set, the upper 128 byte
bank of RTC RAM can be accessed.



と書いてあります。では、RCレジスタを見てみる。

SBREG_BAR=FD000000だったので
PortID = 0xC3 (RTC)

RCの1バイト目にUL,LL,UEがある。

Memory Address 00000000FDC33400 100 Bytes
  FDC33400: 1C 00 00 00 FF FF FF FF-FF FF FF FF FF FF FF FF  *................*
  FDC33410: FF FF FF FF 00 00 00 00-03 00 00 00 FF FF FF FF  *................*
  FDC33420: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF  *................*
  FDC33430: FF FF FF FF FF FF FF FF-FF FF FF FF FF FF FF FF  *................*

なので、1C =0001 1100 -> UL=1,LL=1,UE=1でした。このPCHはBIOSにより拡張バンクのRAMが有効になっていることがわかりました。と、いうことで、このPCHのRTC RAMはわづか114+128=242バイトしか記憶できません。

それでは、調査実機のRTC RAM の中身を見てみます。
調査方法
プリブート環境にてUEFI Interactive Shell for x64 v2.2 by EDK 2 のmm -ioコマンドを実行し調査する。

RTC はI/Oポート70h/71h と 72h/73h でアクセスする。このI/Oポート70h or 72hにRAMを読み取る際のオフセット値を書き込み71h or 73hから値を読み取る。しかし、厄介なことが1つある。70hの最上位のビット7はNMI割り込みの制御に使われている。なんで、このような仕様になっているのか?それは、たぶん、IBMかIntelのおじさん達がそう決めたからに他ならない。さらに、またまた厄介なことがある。このI/Oポート70hの値はPCHをAlternate Access Modeにしないと読めない。その方法は

29.2 Interrupt PCR Registers Summary
29.2.14 General Interrupt Control (GIC)—Offset 31FCh
ビット17 ->  Alternate Access Mode Enable (AME): When set, read only registers can be written, and write only registers can be read.

なので、
SBREG_BAR=FD000000
PortID = 0xC4 (Processor Interface, 8254 Timer, HPET, APIC )

で、調査実機では下図のようにAlternate Access Modeにビットはたっていない。ので、ここにビットを立てればよい。

Memory Address 00000000FDC43100 200 Bytes
  FDC43100: 0B 0A 0B 0B 0B 0B 0B 0B-00 00 00 00 00 00 00 00  *................*
  FDC43110: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43120: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43130: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43140: 10 32 10 32 10 32 10 32-10 32 10 32 10 32 10 32  *.2.2.2.2.2.2.2.2*
  FDC43150: 10 32 10 32 10 32 10 32-10 32 00 00 00 00 00 00  *.2.2.2.2.2......*
  FDC43160: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43170: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43180: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43190: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC431A0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC431B0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC431C0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC431D0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC431E0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC431F0: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43200: 00 40 FF 00 01 00 00 00-00 00 00 00 00 00 00 00  *.@..............*
  FDC43210: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43220: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*
  FDC43230: 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  *................*

そうしましたら、レジスタアドレス FDC431FE を02にすればよい。

実行結果
IMG_20171028_113940.jpg 
1コマンド目:ポート70hをリードするが0が帰る
2コマンド目:Alternate Access ModeをEnable
3コマンド目:ポート70hのリード成功。C6が帰る
8コマンド目:ポート70hのリード成功。46が帰る
BIOSで絶えずNMIの有効・無効を切り替えているようです。しかし、OS起動前の段階ですので、RTCインデックスレジスタを書き込む際にMNIのビットが変わっても、後で再起動すれば元に戻るので問題ないでしょう。気にせず、RTC RAMの内容を見てみます。


RTC RAMの内容 実行結果
IMG_20171028_124852.jpg 
ついでに、RTCの日と月の値も見てみました。
1アドレス目:標準バンク IDX:07 (日) = 28   (by BCD )
2アドレス目:標準バンク IDX:08 (月) = 10   (by BCD )
3アドレス目:標準バンク IDX:0E  = 0A
4アドレス目:標準バンク IDX:0F  = 00
5アドレス目:標準バンク IDX:46  = F0
6アドレス目:標準バンク IDX:70  = 00
7アドレス目:拡張バンク IDX:00  = 00   
8アドレス目:拡張バンク IDX:01  = 00   
9アドレス目:拡張バンク IDX:02  = 00   

ということで、このPCHのRTC RAMは標準バンクのユーザ領域は何らかしらBIOSメーカ仕様で使われいるが、拡張バンクはなにも使われていない模様です。このあたりの仕様は公開されていないので詳しいことはこれ以上わかりそうにありません。いずれにせよ、UEFI GLOBAL VARIABLES などの標準変数はこのRTC RAMの114バイトに収まらないことは確実です。したがって、TRC RAMで使用している部分は互換性維持のために残し、収まりきらない情報はBIOSが格納されているフラッシュROMに保存されていると思われます。また、PnPで必要となるESCD領域もフラッシュROM側にあるのでないかと思われます。今後、さらに、このあたりの詳しいことを調べてみたいと思います。




2017/11/04 追記

さて、さて
PCのUEFI BIOS NVRAM がRTC RAM にはないとなると、他に保存でそうな場所としてはBIOSが格納されているフラッシュROMしかありません。しかし、そもそもこのフラッシュROMはCPUがリセット直後に実行するBIOSコードが書き込まれており、それがメモリ空間にマップされています。Kaby Lake-S CPUではメモリ空間のFFE0_0000h〜FFFF_FFFFhの2MB領域にBIOS フラッシュROMがマッピングされています。そして、CPUはリセットベクタアドレスであるFFFF_FFF0hから命令を実行します(x64 CPUならたぶんこれに同じと思います)。つまり、ROMとして機能しているわけです。この状態ですと、フラッシュROMにイレーズやライトなどは難しそうです。

Intel のPCH データシートの仕様を見てみるとそれらしい記述がありました。

Intel® 200 (including X299) and
Intel® Z370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 1 of 2

October 2017
Revision 003

32 Serial Peripheral Interface for FIash/TPM (SPI0)

32.3 概要
PCHは、システムフラッシュおよびTPMデバイスをサポートするための1つのシリアル周辺インターフェイス(SPI0)を提供します。
インターフェイスは3つのチップセレクト信号(CS#)を実装し、最大2つのフラッシュデバイスと1つのTPMデバイスをPCHに接続できます。
CS0#とCS1#はフラッシュデバイスに使用され、CS2#はTPM専用です。

32.7 Functional Description
32.7.1.2.2 SPI Flash Regions
In Descriptor Mode the Flash is divided into five separate regions.

Table 32-1. SPI Flash Regions
Region Content
0 Flash Descriptor
1 BIOS
2 Intel Management Engine
3 Gigabit Ethernet
4 Platform Data
8 EC



CPUはBIOSコードを順次実行し、システムの状態がDXEフェーズまで来ると、BIOS実行コードはPCIデバイスも使えるので、このPCI to SPIインターフェイスを使い、フラッシュROMのBIOS領域の一部にリード・ライトアクセスをするようです。

ということで、
この実機のマザーボードに実装されているROMはBIOSのコードを実行するROMの機能と初期化後に可用となるSPIフラッシュとしてのデータストレージ的機能を持ち合わせていると思われます。


実機のマザーボードではこのBIOSフラッシュROMにはSPI接続のNOR Flash (winbond製 W25Q128FVSQ)が使われていますが、わずか8本の配線で大きさも1cm角もないぐらいの大きさです。この小さなチップの領域にUEFI BIOSのNVRAMが納めれているようです。マザーボードをよく見ないと見落としてしまいそうな小さな部品にBIOSコードが植え込まれ、設定情報などが読み書きされているとは驚き桃ノ木です。マザーボードのマニュアルでは128Mbitとなっており、16MBの容量となり、RTC RAMよりもはるかに大容量です。


IMG_20171104_184516 (1) 
調査実機のフラッシュROMの様子

Winbond製 W25Q128FVのデータシートを見ると、レジスタなどを持ち、ブロック毎の書き込み禁止属性など設定できるようです。



その後、いろいろ雑誌等を調べていると、次のような記述がありました。

月刊インターフェイス 2011年11月号 CQ出版社 
技術解説
第2特集 IBM PC/AT誕生から30年のしがらみを捨て去る
従来のPC/AT用BIOSを置き換えるUEFI仕様の概要
藤原 尚伸,高橋 泰博 pp.100-106
3.UEFIの導入のメリット
・BIOSの設定領域の拡大
UEFIでは設定情報などをEFI Variableとして、通常BIOSが格納されているフラッシュROMの一部の領域を確保し使用しています。

著者はBIOSメーカであるフェニックス・テクノロジーズの方です。


結論

UEFI BIOSでは設定情報などの変数はフラッシュROMの一部の領域に保存されており、RTC RAMは互換確保のために部分的に使用されている。

しかし、次の疑問が残る。

マザーボードのCMOSクリアでは、そのフラッシュROMに保存された設定情報などはクリアされないのではないか???

今回はここで力尽きました。




2017/11/12 追記

ご注意
これ以降で紹介する内容を実施することにより、状況によってはマザーボードを破壊する可能性があります。また、この行為はメーカー・代理店の製品保証や修理対応の免責事項に該当するようです。ご自身で実施される場合は自己責任でお願いします。


UEFI BIOSの設定情報はRTC RAMとBIOSフラッシュROMに存在していることがわかりました。そうなりましたら、やはり、それを実際に自分の目で確かめずにはおられません。そこで、上記と同じ実機環境で「本当にそうなっているのか?」調べてみました。


調査方法

PCHのデータシートに書いてあるPCI to SPI インターフェイスを使いレジスタアクセスでSPIフラッシュROMを読む方法はやり方がネットには見当たりませんし、難しそうです。UEFI Shellにそれをアクセスできるコマンドもありません。まあ、アーキテクチャ依存な部分ですのないんでしょう。このマザーボードのBIOSに実装されているSPIフラッシュROMにアクセスするドライバのAPIもわかりそうにありません。そこで、より直接的な方法として、ネットでも情報が豊富なROMライターを用いた方法で調べることにします。今回はROMライターをROMからデータを丸ごと吸い上げるツールとして使用します。BIOSの書き換え・書き込み目的ではありません。


用意するもの
IMG_20171111_052206.jpg 

1.ROMライターそのもの
    今回選んだのはROMライター EZP2010です。選定理由はネットに実践事例が多くあるためと価格が安価2000円台なこと。


2.ROMライターを動かすアプリケーション(for Windows )
    ROMライター EZP2010に同梱


3.ROMライター用のデバイスドライバ(for x64 windows )
    ROMライター EZP2010に同梱


4.ROMライターをUSB接続で動かすWindows PC
  NEC LAVIE (Intel Core i3-7100U x64-Windows 10 Pro)を用意


5.ROMライターからSPIフラッシュROMにつなぐコネクタや電線や諸々
    USBケーブルはROMライター EZP2010に同梱で他は自作



ROMライター EZP2010のセットアップは下記サイトを参考にさせて頂きました。
参考サイト
ふらっと 気の向くままに
LGA1151 ASUSマザーボードBIOS復旧 1/2 ROM焼き
http://datyotosanpo.blog.fc2.com/blog-entry-103.html?id=CHOICE_SPI_PROGRAMMER#CHOICE_SPI_PROGRAMMER


ROMライター EZP2010とSPIフラッシュROMの接続は下記サイトを参考にさせて頂きました。
参考サイト
価格コム クチコミ掲示板
SpringbokさんのASUS SPIピンヘッダーによるUEFI(BIOS)更新方法
http://bbs.kakaku.com/bbs/K0000932620/SortID=20768616/#tab



ROMライター EZP2010とSPIフラッシュROMの接続で悪戦苦闘

実機のASUS H270-PLUSに装着されているSPI Flash chipは上記サイトで解説されている通り、SPIピンヘッダでメンテナンスするタイプです。しかし、このピンヘッダが曲者で、マザーボードのPower onやResetなどのシステムピンで広く使われている2.54mmタイプではなく、2mmタイプなのです(下記備考を参照)。ですので、コネクタ付きケーブルの入手性が低く、今回はコンタクトピンとケーブルのみ購入し後は、とりあえず通電すればよい程度に自作となりました。電子工作は小学生にやった時以来です。
ピンヘッダとSPI Flash chipのアサインはやはり、上記サイトのSpringbokさんのASUS ROG STRIX Z270F GAMINGと同じでした。コンタクトピンとケーブルは1本毎、ラジオペンチで挟みました。その後、ピン同士の絶縁のために、ピンにセロテープを巻きました。ピンヘッダにピンを挿すのも間隔が狭いのでライトで照らし、虫眼鏡で拡大しての作業となりました。そして、なんとか、下の写真のように接続が終わりました。ふぅーっっ。
マザーボードについてるものは念のためすべて外してください。RTC用のコイン電池も忘れずに。と言いながら、ナント!CPU、メモリ、SSDを外していませんでした(後で気づく(笑))。



セットアップ完了
 IMG_20171111_052223.jpg 



それでは、緊張のチップリード開始です。EZP2010アプリケーションのリードを実行します。いざ、吸い上げ実行。おーっと。順調に読んでいます。無事読み込み割りました。成功じゃー。やりましたー。この時点、すでにすごく達成感があります。このチップの容量は128Mb(16MB)ですが読み込み時間は1分ぐらいでした。


spiflashrom.png 
このアプリケーションでフラッシュから読み込んだ中身を見てみます。フラッシュのアドレス最下部からオフセット10hにシグネチャである0FF0A55Ahがありました。データシート(詳細はこちらの記事で、Intel Kaby Lake-S Datasheet の調査メモ)通りです。このフラッシュはディスクリプタモードであることがわかります。それでは、BIOS領域を見てみましょう!ありました。とうとう見つけましたNVRAM変数の一つである。Boot000がありました。これは、Windows Boot Managerです。 とうとうやりました。これで、今晩からぐっすり寝れます。


と、いうことでUEFI BIOSの設定情報はASUS H270-PLUSの場合はBIOS ROMチップ(SPI Flash Chip)に書き込まれていると確認できました。


また、これまで疑問だった「マザーボードのCMOSクリアとBIOS ROMチップ設定情報のクリアの関係」はおそらく、RTC CMOS RAMのクリアをBIOSで判断し、それに合わせBIOS ROMチップの設定情報でクリアすべき情報は削除していると思われます。


2017/11/15 追記

今更ですが、Windows 10のハードウェア要求仕様にUEFI NVRANに関するものがありました。

Hardware Compatibility Specification for Systems for Windows 10, version 1703
System.Fundamentals.Firmware.UEFISecureBoot

All client systems must support UEFI Secure boot.
Description
Note: These requirements are "If Implemented" for Server systems and apply only if a Server system supports UEFI Secure Boot.
1. Secure Boot must ship enabled with minimum of UEFI 2.3.1 Errata C.
|
|
30. Reserved Memory for Windows Secure Boot UEFI Variables. A total of at least 64 KB (Recommended 128 KB) of non-volatile NVRAM storage memory must be reserved for NV UEFI variables (authenticated and unauthenticated, BS and RT) used by UEFI Secure Boot and Windows, and the maximum supported variable size must be at least 32 KB (Recommended 64 KB). There is no maximum NVRAM storage limit.

ということで、Windows PC ではUEFI NVRAM 記憶容量は最低64KBは必要とのことです。




備考


ROM(Read Only Memory)だげと書き換え可能???
フラッシュ・メモリでも書き換えできるのではないですか?

 フラッシュ・メモリは書き換え可能です。しかし、消去するときはブロック単位で一括消去しなければならないので、1 バイトずつ自由に書き換えることができません。さらに、消去や書き込みにはとても時間がかかるので、プログラムの実行速度が大幅に低下してしまいます。加えて、書き換え回数の上限があるので、プログラム実行時に自由に書き換えるような使い方をするのは困難です。フラッシュ・メモリを ROM の仲間に分類しているのは、そういう理由からです。
2015 年 6 月 30 日 EDN マイクロサイト掲載の記事広告を転載。記事中の情報はすべて掲載時点のものです

TI ホーム > 技術解説ライブラリ > Q&A でよく分かるマイコン基礎の基礎 > 第 10 回 マイコンのメモリ容量って何? 大きいほどいいの?
http://www.tij.co.jp/lsds/ti_ja/general/mcu_qa/qa10_memory_capacity.page




Flash (ROM) にはプログラムコード格納用に適した小容量のNOR Flash とデータストレージ用に使われているNAND Flash の2種類がある。NOR Flashにはパラレル・タイプととシリアル・タイプがあります。2017年現在はシリアル・タイプ(SPI Flash Chip)が主流のようです。



NOR型シリアル・フラッシュ・メモリはピン数が少ないため,基板実装のコストが節約できます.接続されるCPUのピン数も少なくなるので,CPU上のI/Oの数も節約できます.これによりCPUのパッケージ・コストやチップ面積を削減できる可能性があります.
出典
フラッシュ・メモリの高速化技術と最新の不揮発性メモリの動向 ―― フラッシュの次を担うのは、フラッシュかそれとも...
柴田茂則,太田豊
技術解説 2008年7月31日
http://www.kumikomi.net/archives/2008/07/16flash.php?page=2

SPI Flashの使い方 / LogiClover開発ブログ
http://logiclover.hatenablog.jp/entry/2017/04/02/024351


NOR Flash
NAND型フラッシュメモリとは異なり、データの読み出しにおいて、RAMと同様にアドレス指定によるアクセスができ、コードをRAMにコピーすることなく直接実行すること(execute in place)が可能。データの書き込みについては、一度ブロック単位で消去した後、書き込むという手順を踏む。

NOR型フラッシュメモリ
https://ja.wikipedia.org/wiki/NOR%E5%9E%8B%E3%83%95%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%83%A1%E3%83%A2%E3%83%AA



ソフテックだより 第91号(2009年6月3日発行)
技術レポート
「マイコンによるNOR型フラッシュメモリ制御」
3. NOR型フラッシュメモリ制御
3-1. 特徴
メモリからの読み出しはSRAMなどと同様に1バイト単位のアクセスが可能
メモリの消去(イレーズ)、書き込み(プログラム)は、基本的にコマンド入力によるブロック単位での操作が必要
イレーズ、プログラム等のコマンドにはメーカーにより、若干の違いがある
書き込み動作が低速である(メーカーによっては独自の高速書き込み方式をサポートしている)
リードアクセスについては、SRAMインタフェースを搭載しているマイコンであれば、ソフト的には何も意識することなくアクセスが可能です。しかし、フラッシュへの書き込み(プログラム)に関しては、コマンド入力が必要となるため、ドライバソフトが必要となります。また、プログラム時には0→1のデータ書き込みを行うことができないため、必ず書き込み対象のセクタをイレーズ(対象領域のデータがすべて0xFFFFとなる)してからプログラムする必要があります。
http://www.softech.co.jp/mm_090603_firm.htm



Flashの種類
Flashには二種類あってCFI(Common Flash Interface)というメモリのようにピンの多いタイプとSPI(Serial Peripheral Interface)というピンの少ないタイプがあります。CFIの方が原始的で通常のメモリのように読めますが、SPIはドライバが無いと読めません。
Qiita Flashのこと yamori813 2017年10月06日に更新
https://qiita.com/yamori813/items/89562bade8460ad654c5


2007/01/17
WinPC Labs
大容量かつ高速化で普及が進む、
「フラッシュメモリー」の原理を探る
豊後基彦=バッファロー
http://tech.nikkeibp.co.jp/it/pc/article/NPC/20061129/255245/



ノンマスカラブル割り込みというのは、とにかく無条件に実行される割り込みのことです
http://www7a.biglobe.ne.jp/~thor/pcnyumon/nyu050.htm
本当に初心者の人に捧げるコンピューター入門 
もう少し突っ込んだハードウェアの話


【TIPS】QI(キューアイ)ケーブル/コネクタ
「2550(コネクタ)」との呼称も用いられ、ソケット部はコンタクトピンを圧着したリード線1本1本をハウジングに挿して使用します。ハウジングは1列×n、2列×nのピン数、ピン間(ピッチ)は2mmタイプと2.54mmタイプがあり、逆挿し防止機構や引き抜き防止(ロック)機構は備えていませんが、その分省スペース性に優れています。
電子工作や自作パソコン(マザーボード、各種拡張ボード)で幅広く使用されていますが、逆挿し防止機構を持たないため特に電源を取り扱う場合は注意が必要です。
なお、ソケットに嵌合するプラグ部の指定品種は特になく、一般的に「ヘッダーピン(2mmピッチ/2.54mmピッチ)」と呼ばれるものが使用されています。
共立電子 エレショップ
http://eleshop.jp/shop/c/c11301115_p2/




参考図書

AT互換機 アーキテクチャハンドブック―
DOS/Vプログラミングのためのテクニカルデータを網羅 単行本 – 1995/3
川村 浩也  (著), 吉田 雅秋  (著)
ナツメ社




参考データシート

Intel® 200 (including X299) and
Intel® 2370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 1 of 2

October 2017
Revision 003


Intel® 200 (including X299) and
Intel® 2370 Series Chipset Families
Platform Controller Hub (PCH)
Datasheet - Volume 2 of 2

October 2017
Revision 005


Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Volume 3 (3A, 3B, 3C & 3D):
System Programming Guide

September 2016

CHAPTER 9
PROCESSOR MANAGEMENT AND INITIALIZATION
9.1 INITIALIZATION OVERVIEW
9.1.4 First Instruction Executed



winbond spiflash Datasheet
3V 128M-BIT
SERIAL FLASH MEMORY WITH
DUAL/QUAD SPI & QPI May 13, 2016
http://www.winbond.com/hq/product/code-storage-flash-memory/serial-nor-flash/?__locale=en&partNo=W25Q128FV


参考サイト

Intel Security Advanced Threat Research
System Firmware and UEFI Security
http://www.intelsecurity.com/advanced-threat-research/content/system-firmware.html

Attacking and Defending BIOS in 2015 | 2015-06-20 

Attacking and Defending
BIOS in 2015
Oleksandr Bazhaniuk, Yuriy Bulygin (presenting), Andrew Furtak,
Mikhail Gorobets, John Loucaides, Alex Matrosov, Mickey Shkatov
Advanced Threat Research

PDF Documents
P39,40
Where does firmware store its settings?


category: PC-HW

tb: 0   cm: 0

UEFI BIOS Boot Mechanisms  

最終更新日 2017/10/08 16:26

2017/10/04現在、主流と思われるUEFI Specification Version 2.5 / Advanced Configuration and Power Interface Specification Version 6.2よりブートに関係する部分をGoogle翻訳により和訳しメモしておきます。

出典
Unified Extensible Firmware Interface Forum
http://www.uefi.org/specifications


Unified Extensible Firmware Interface Specification 
Version 2.5 Errata A
January, 2016




1 Introduction
このUnified Extensible Firmware Interface(以下、UEFI)仕様では、オペレーティングシステム(OS)とプラットフォームファームウェア間のインタフェースについて説明しています。 UEFIの前には、Extensible Firmware Interface Specification 1.10(EFI)がありました。その結果、一部のコードと特定のプロトコル名でEFIの指定が保持されます。特に指定のない限り、この仕様のEFI指定はUEFIの一部であると見なすことができます。
このインタフェースは、プラットフォーム関連の情報と、OSローダおよびOSで使用可能なブートおよびランタイムサービスコールを含むデータテーブルの形式です。これらは一緒になって、OSを起動するための標準的な環境を提供します。この仕様は、純粋なインタフェース仕様として設計されています。したがって、この仕様では、プラットフォームファームウェアが実装する必要があるインターフェイスと構造のセットを定義しています。同様に、仕様では、OSが起動時に使用するインタフェースと構造のセットが定義されています。ファームウェア開発者が必要な要素を実装する方法を選択するか、またはOSの開発者がこれらのインタフェースと構造を利用する方法を選択するかは、開発者にとって残された実装の決定です。
この仕様の目的は、OSとプラットフォームファームウェアがOSブートプロセスをサポートするために必要な情報のみを通信する方法を定義することです。これは、プラットフォームおよびファームウェアによってOSに提示される、ソフトウェアで表示可能なインターフェイスの正式で完全な抽象的な仕様によって実現されます。
この正式な定義を使用すると、サポートされているプロセッサ仕様と互換性のあるプラットフォーム上で動作するように意図されたシュリンクラップOSは、プラットフォームやOSのカスタマイズを行うことなく、さまざまなシステム設計で起動することができます。また、プラットフォームの革新により、OSのブートシーケンスに新しいコードを記述することなく、プラットフォーム機能を強化する新しい機能を導入することもできます。
さらに、抽象的な仕様は、レガシーデバイスとファームウェアコードを時間の経過とともに置き換えるルートを開きます。新しいデバイスタイプおよび関連するコードは、OSブートサポートコードに影響を与えずに、同じ定義された抽象インターフェースを介して同等の機能を提供することができます。
この仕様は、モバイルシステムからサーバーまでのあらゆるハードウェアプラットフォームに適用されます。この仕様では、プロトコルインタフェースの選択とともに、一連のコアサービスが提供されています。プロトコルインタフェースの選択は、様々なプラットフォーム市場セグメントに合わせて時間をかけて進化していくことができます。同時に、この仕様では、OEMが差別化を可能にするための最大限の拡張性とカスタマイズ能力が認められています。この中で、UEFIの目的は、従来の「PC-AT」スタイルのブート・ワールドから従来のAPIを使用しない環境への進化の道筋を定義することです。

1.1 UEFIドライバモデル拡張
起動デバイスへのアクセスは、一連のプロトコルインターフェイスを通じて提供されます。 UEFIドライバーモデルの1つの目的は、「PC-AT」スタイルのオプションROMの代わりを提供することです。 UEFIドライバーモデルに書き込まれたドライバーは、ブート前環境のブートデバイスにアクセスするように設計されていることを指摘することが重要です。高性能でOS固有のドライバに代わるものではありません。
UEFIドライバモデルは、起動前環境で実行されるモジュール式のコード(ドライバとも呼ばれます)の実行をサポートするように設計されています。これらのドライバは、プラットフォーム上のハードウェアバスおよびデバイスを管理または制御することができ、またはソフトウェア由来のプラットフォーム固有のサービスを提供することができる。
UEFIドライバモデルには、プラットフォームがUEFI準拠のOSをブートするために必要なバスドライバとデバイスドライバの組み合わせを設計および実装するために、UEFIドライバライタに必要な情報も含まれています。
UEFIドライバーモデルは汎用的に設計されており、あらゆるタイプのバスまたはデバイスに適合させることができます。 UEFI仕様では、PCIバスドライバ、PCIデバイスドライバ、USBバスドライバ、USBデバイスドライバ、およびSCSIドライバの書き方について説明しています。従来のオプションROMイメージとの互換性を維持しながら、PCIオプションROMにUEFIドライバを格納できるようにする追加の詳細情報が提供されています。
UEFI仕様の設計目標の1つは、ドライバイメージをできるだけ小さく保つことです。ただし、ドライバが複数のプロセッサアーキテクチャをサポートする必要がある場合、サポートされている各プロセッサアーキテクチャ用にドライバオブジェクトファイルも出荷する必要があります。このスペースの問題に対処するために、この仕様ではEFIバイトコード仮想マシンも定義しています。 UEFIドライバは、単一のEFIバイトコードオブジェクトファイルにコンパイルできます。 UEFI仕様準拠のファームウェアには、EFIバイトコードインタープリタが含まれている必要があります。これにより、複数のプロセッサアーキテクチャをサポートする単一のEFIバイトコードオブジェクトファイルを出荷することができます。もう一つの省スペース技術は、圧縮の使用です。この仕様では、UEFIドライバのサイズを縮小し、UEFIドライバがROMデバイスに格納されるときのオーバーヘッドを削減するために使用される圧縮アルゴリズムと圧縮解除アルゴリズムを定義しています。
UEFI仕様に含まれる情報は、OSV、IHV、OEM、およびファームウェアベンダーが、この仕様に準拠するファームウェアを設計および実装するために使用できます。標準プロトコルインターフェイスを生成するドライバ、およびUEFI準拠のブートに使用できるオペレーティングシステムローダオペレーティングシステム。


3 Boot Manager
UEFIブートマネージャは、アーキテクチャ上定義されたグローバルNVRAM変数を変更して設定できるファームウェアポリシーエンジンです。ブートマネージャーは、UEFIドライバーとUEFIアプリケーション(UEFI OSブートローダーを含む)をグローバルNVRAM変数で定義された順序でロードしようとします。プラットフォームのファームウェアは、通常のブートではグローバルNVRAM変数で指定されたブート順序を使用する必要があります。プラットフォームファームウェアは、余分なブートオプションを追加したり、ブート順序リストから無効なブートオプションを削除する可能性があります。
プラットフォームファームウェアは、ファームウェアブートプロセスで例外条件が検出された場合に、ブートマネージャに付加価値機能を実装することもできます。付加価値機能の1つの例は、ドライバが初めてロードされたときに起動が失敗した場合、UEFIドライバをロードしないことです。別の例では、ブートプロセスで重大なエラーが検出された場合、OEM定義の診断環境で起動します。
UEFIのブートシーケンスは、次のもので構成されています。
•ブート順序リストは、グローバルに定義されたNVRAM変数から読み込まれます。この変数への変更は、次のプラットフォームのリセット後に有効になることが保証されています。ブート順序リストは、ブート対象の情報を含むNVRAM変数のリストを定義します。各NVRAM変数は、ユーザーに表示できるブートオプションの名前を定義します。
•変数には、ハードウェアデバイスへのポインタと、ロードするUEFIイメージを含むハードウェアデバイス上のファイルも含まれます。
•変数には、OSのパーティションとディレクトリへのパスと、他の設定固有のディレクトリも含まれる場合があります。
NVRAMには、UEFIイメージに直接渡されるロードオプションも含まれます。プラットフォーム・ファームウェアは、ロード・オプションに含まれている内容を認識していません。ロードオプションは、プラットフォームのファームウェアブートポリシーを設定するためにグローバルNVRAM変数に書き込むときに、上位ソフトウェアによって設定されます。この情報は、UEFI OSローダーの場所と異なる場合は、OSカーネルの場所を定義するために使用できます。


3.5 Boot Mechanisms
EFIは、EFI_SIMPLE_FILE_SYSTEM_PROTOCOLまたはEFI_LOAD_FILE_PROTOCOLを使用してデバイスから起動できます。

EFI_SIMPLE_FILE_SYSTEM_PROTOCOLをサポートするデバイスは、そのデバイスを起動可能にするためにファイルシステムプロトコルを具体化する必要があります。

デバイスが完全なファイルシステムをサポートしない場合、EFI_LOAD_FILE_PROTOCOLが生成され、イメージを直接マテリアライズすることができます。

ブートマネージャは、最初にEFI_SIMPLE_FILE_SYSTEM_PROTOCOLを使用してブートを試みます。 それが失敗した場合、EFI_LOAD_FILE_PROTOCOLが使用されます。



3.5.1 Boot via the Simple File Protocol
EFI_SIMPLE_FILE_SYSTEM_PROTOCOLを使用して起動すると、FilePathは、そのデバイスを「話す」デバイスを指すデバイスパスから開始します
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL。

FilePathの次の部分は、起動可能なイメージを含むサブディレクトリを含むファイル名を指します。

ファイル名がヌルのデバイスパスである場合、あいまいなファイル名を持つリムーバブルメディアデバイスに対して定義されたルールを使用して、メディア上でファイル名を検出する必要があります(下の3.5.1.1項を参照)。


指定されたファイルシステムのフォーマットは12.3節に含まれています。

ファームウェアは、UEFIファイルシステムを理解するEFI_SIMPLE_FILE_SYSTEM_PROTOCOLを生成する必要がありますが、EFI_SIMPLE_FILE_SYSTEM_PROTOCOLインタフェースを使用してファイルシステムを抽象化することができます。


3.5.1.1 Removable Media Boot Behavior
リムーバブルメディアデバイスでは、FilePathにサブディレクトリを含むファイル名を含めることはできません。

FilePathList [0]は、プラットフォーム内の不揮発性メモリに格納され、いつでも変更できるメディアと同期して保持することはできません。

リムーバブルメディアデバイスのFilePathList [0]は、EFI_SIMPLE_FILE_SYSTEM_PROTOCOLまたはEFI_BLOCK_IO_PROTOCOLをサポートするデバイスを指します。

FilePathList [0]には、ファイル名またはサブディレクトリは含まれません。

FilePathList [0]がEFI_SIMPLE_FILE_SYSTEM_PROTOCOLをサポートするデバイスを指している場合、システムファームウェアは、デフォルトのファイル名を\ EFI \ BOOT \ BOOTx64.EFI形式(x64マシンの場合)で追加して、リムーバブルメディアFilePathList [0]から起動しようとします。

machine type short-nameはPE32 +イメージフォーマットアーキテクチャを定義します。

各ファイルにはUEFIイメージタイプが1つのみ含まれています。システムは1つ以上のイメージタイプからの起動をサポートしています。 表12に、UEFIイメージ・タイプを示します。

3.5.2 Boot via LOAD_FILE PROTOCOL


7 Services — Runtime Services
7.2 Variable Services
変数は、情報と属性(キー)と任意のデータ(値)の識別で構成されるキーと値のペアとして定義されます。 変数は、プラットフォームに実装されたEFI環境と、EFI環境で実行されるEFI OSローダーおよびその他のアプリケーション間で渡されるデータを格納する手段として使用することを目的としています。
変数の実装はこの仕様では定義されていませんが、変数はほとんどの場合永続的でなければなりません。 これは、プラットフォーム上のEFI実装は、少なくとも明示的に削除または上書きされるまで、システムがブートするたびに、格納用に渡された変数が保持され、使用可能になるように配列を配置する必要があることを意味します。 この種の不揮発性ストレージの提供は、一部のプラットフォームでは非常に制限される可能性があるため、他の情報伝達手段を使用できない場合は、変数を控えめに使用する必要があります。

Table 33 lists the variable services functions described in this section:
Table 33. Variable Services Functions
Name Type Description
GetVariable Runtime Returns the value of a variable.
GetNextVariableName Runtime Enumerates the current variable names. 
SetVariable Runtime Sets the value of a variable.
QueryVariableInfo() Runtime Returns information about the EFI variables


9 Protocols — Device Path Protocol
9.1 Device Path Overview
デバイスパスは、デバイスへのプログラムパスを定義するために使用されます。

デバイスパスの主な目的は、OSローダなどのアプリケーションが、インタフェースが抽象化している物理デバイスを特定できるようにすることです。

デバイスパスの集合は、通常、名前空間と呼ばれます。

たとえば、ACPIは、ASL(ACPI Source Language)で書かれた名前空間の周りにあります。

可能な限りEFIがACPIを置き換えずにACPIに代わってしまうことを考えると、EFIのACPIネームスペースを利用することは理にかなっているようです。

ただし、ACPIネームスペースは、オペレーティングシステムのランタイムで使用するように設計されており、プラットフォームのファームウェアやOSローダーには適していません。

このため、EFIはデバイスパスと呼ばれる独自の名前空間を定義します。

デバイスパスは、ACPIネームスペースを最大限活用するように設計されています。

デバイスパスの主要な構造の1つは、ACPIネームスペースへのリンケージを定義します。

デバイスパスは、ACPIが標準の列挙アルゴリズムでバスに接続するギャップを埋めるためにも使用されます。

デバイスパスは、バス上で使用されているデバイスに関する情報を、標準の列挙メカニズムと関連付けることができます。

デバイスパスは、ファイルが存在すべき場所、またはファイルがロードされた場所のメディア上の場所を定義するためにも使用されます。

デバイスパスの特殊なケースは、レガシーメディアからのレガシーオペレーティングシステムのオプションのブートをサポートするためにも使用できます。

デバイスパスは、OSローダとオペレーティングシステムが、プラットフォームファームウェアがどのデバイスをブートデバイスとして使用しているかを知ることができるように設計されています。

これにより、オペレーティングシステムは、プラットフォームファームウェアと一致するシステムのビューを維持することができます。

これの一例は、ブートデバイスおよびコンソールとしてネットワーク接続を使用している「ヘッドレス」システムです。

このような場合、ファームウェアは、オペレーティングシステムに、ネットワークアダプタおよびネットワークプロトコル情報をコンソールとして使用し、これらのデバイスのデバイスパス内のブートデバイスとして使用します。


9.2 EFI Device Path Protocol

Protocol Interface Structure
//*******************************************************
// EFI_DEVICE_PATH_PROTOCOL
//*******************************************************
typedef struct _EFI_DEVICE_PATH_PROTOCOL {
UINT8 Type;
UINT8 SubType;
UINT8 Length[2];
} EFI_DEVICE_PATH_PROTOCOL;



9.3 Device Path Nodes
Device Pathノードには主に6つのタイプがあります。

Hardware Device Path.
このデバイスパスは、システムのリソースドメインにデバイスがどのように接続されるかを定義します。リソースドメインは、システムの共有メモリ、メモリマップI / O、およびI / Oスペースです。

ACPI Device Path.
このデバイスパスは、列挙が業界標準の方法で記述されていないデバイスを記述するために使用されます。これらのデバイスは、ACPI名前空間でACPI AMLを使用して記述する必要があります; このデバイスパスは、ACPIネームスペースへのリンケージです。

Messaging Device Path.
このデバイスパスは、システムのリソースドメイン外のデバイスの接続を記述するために使用されます。このデバイスパスは、SCSI IDなどの物理的なメッセージング情報、またはネットワークプロトコルIPアドレスなどの抽象的な情報を記述できます。

Media Device Path.
このデバイスパスは、ブートサービスによって抽象化されているメディアの部分を記述するために使用されます。たとえば、メディアデバイスパスは、ハードドライブ上のどのパーティションが使用されているかを定義できます。

BIOS Boot Specification Device Path.
このデバイスパスは、レガシーオペレーティングシステムの起動を指示するために使用されます。 BIOSブート仕様バージョン1.01に基づいています。 この仕様を取得するための詳細については付録Qを参照してください。

End of Hardware Device Path.
サブタイプに応じて、このデバイスパスノードは、デバイスパスインスタンスまたはデバイスパス構造の終わりを示すために使用されます。


9.3.1 Generic Device Path Structures
Type
Type 0 1 Type 0x01 – Hardware Device Path
Type 0x02 – ACPI Device Path
Type 0x03 – Messaging Device Path
Type 0x04 – Media Device Path
Type 0x05 – BIOS Boot Specification Device Path
Type 0x7F – End of Hardware Device Path

Sub-Type 
Varies by Type. 

Length
Length of this structure in bytes. Length is 4 + n bytes.

Specific Device Path Data
Type and Sub-Type define type of data. Size of data is included in Length.


9.3.2 Hardware Device Path

9.3.2.1 PCI Device Path
Type 1 – Hardware Device Path
Sub-Type 1 – PCI
Length 6 bytes
Function (4,1)
PCI Function Number
Device (5,1)
PCI Device Number

9.3.5 Messaging Device Path

9.3.5.5 USB Device Paths
Type 3 – Messaging Device Path
Sub-Type 5 – USB
Length 6 bytes.
USB Parent Port Number (4,1)
USB Parent Port Number
Interface (5,1)
USB Interface Number



9.3.3 ACPI Device Path
このデバイスパスには、デバイスのプラグアンドプレイハードウェアIDと対応する一意の永続IDを表すACPIデバイスIDが含まれています。

 ACPI IDは、デバイスに関連付けられたACPI _HID、_CID、_UIDのデバイス識別オブジェクトに格納されます。

ACPIデバイスパスには、プラットフォームファームウェアからオペレーティングシステムに提供されるACPIネームスペースと正確に一致する必要がある値が含まれています。

_HID、_CID、_UIDのデバイス識別オブジェクトの詳細については、ACPI仕様を参照してください。

_HIDと_CIDの値は、ACPI名前空間に表示されるオプションのデバイス識別オブジェクトです。

_HIDのみが存在する場合は、_HIDを使用して、ACPIドライバによって列挙されるすべてのデバイスを記述する必要があります。

_CIDは、存在する場合、OSが接続するために重要な情報を含んでいます
汎用ドライバ(例えばPCIバスドライバ)であり、_HIDにはOS固有の情報が含まれ、デバイス固有のドライバを接続する。

ACPIバスドライバは、デバイス用の標準バス列挙子が存在しない場合にのみ、デバイスを列挙します。

_UIDオブジェクトは、再起動後も変更されないデバイスのシリアル番号スタイルのIDをOSに提供します。

オブジェクトはオプションですが、同じ_HIDを報告する2つのデバイスがシステムに含まれている場合に必要です。

_UIDは、同じ_HID値を持つすべてのデバイスオブジェクト間で一意である必要があります。

_HIDのAPCI名前空間に_UIDが存在しない場合は、ACPIデバイスパスの_UIDフィールドにゼロの値を格納する必要があります。

ACPIデバイスパスは、ハードウェアデバイスパスで定義されていないデバイスの記述にのみ使用されます。

PCI仕様ではPCIルートブリッジのプログラミングモデルが定義されていないため、_HID(存在する場合は_CIDとともに)がPCIルートブリッジを表すために必要です。

ACPIデバイスパスには、_HIDフィールドと_UIDフィールドのみを含む単純なサブタイプと_HID、_CID、および_UIDフィールドを含む拡張サブタイプの2つのサブタイプがあります。

ACPIデバイスパスノードは、_HIDおよび_UID値の数値32ビット値のみをサポートします。

拡張ACPIデバイスパスノードは、_HID、_UID、および_CIDの値の数値と文字列の両方の値をサポートします。

その結果、ACPI Device Pathノードは小さくなり、可能であれば不揮発性ストレージに格納される可能性のあるデバイスパスのサイズを縮小するために使用する必要があります。

_HIDフィールドに文字列値が必要な場合、または_UIDフィールドに文字列値が必要な場合、または_CIDフィールドが必要な場合は、展開されたACPIデバイスパスノードを使用する必要があります。

拡張ACPIデバイスパスノードの文字列フィールドが存在する場合、対応する数値フィールドは無視されます。

ACPIデバイスパスノードと拡張ACPIデバイスパスノードの_HIDフィールドと_CIDフィールドは、32ビットの圧縮EISAタイプのIDとして格納されます。

次のマクロは、プラグアンドプレイハードウェアIDからこれらのEISAタイプのIDを計算するために使用できます。

EFIデバイスパスノードの_HIDフィールドと_CIDフィールドを計算するために使用されるプラグアンドプレイハードウェアIDは、ACPIテーブルに一致するエントリを作成するために使用されるプラグアンドプレイハードウェアIDと一致する必要があります。

このマクロによって生成された圧縮EISAタイプのIDは、ACPIテーブルに格納されている圧縮されたEISAタイプのIDとは異なります。

その結果、ACPIデバイスパスノードからの圧縮されたEISAタイプのIDは、ACPIテーブルの圧縮されたEISAタイプのIDと直接比較できません。


Type 2 – ACPI Device Path.
Sub-Type 1 ACPI Device Path.
Length 12 bytes.
_HID (4,4)
Device’s PnP hardware ID stored in a numeric 32-bit compressed EISA-type ID. This value must match the corresponding _HID in the ACPI name space.
_UID (8,4)
Unique ID that is required by ACPI if two devices have the same _HID. This value must also match the corresponding _UID/_HID pair in the ACPI name space. Only the 32-bit numeric value type of _UID is supported; thus strings must not be used for the _UID in the ACPI name space.



9.3.6 Media Device Path
This Device Path is used to describe the portion of the medium that is being abstracted by a boot
service. An example of Media Device Path would be defining which partition on a hard drive was
being used.

9.3.6.1 Hard Drive
ハードドライブメディアデバイスパスは、ハードドライブ上のパーティションを表すために使用されます。

各パーティションには少なくともハードドライブデバイスパスノードがあり、それぞれがパーティションテーブルのエントリを記述します。

EFIは、MBRおよびGPTパーティショニング形式をサポートしています。

 パーティションは、それぞれのパーティションテーブルのエントリに応じて1から始まる番号に従って番号が付けられます。

パーティションは、LBAゼロで始まるEFIで処理されます。

パーティション番号0は、生のハードドライブまたは生の拡張パーティションを表すために使用できます。

新しいパーティションフォーマットが将来サポートされるように、パーティションフォーマットはデバイスパスに保存されます。

ハードドライブデバイスパスには、ディスクシグネチャとディスクシグネチャタイプも含まれています。

ディスク署名はOSによって維持され、Device Pathノードを分割するためにEFIによってのみ使用されます。

ディスク署名は、OSが物理的にシステム内を移動した後でもディスクを検出できるようにします。

セクション3.1.2は、ハードドライブメディアデバイスパスを処理するための特別なルールを定義しています。

これらの特別なルールにより、ディスクの場所が変更され、ディスクからのシステム起動が可能になります。

Type 4 – Media Device Path
Sub-Type 1 – Hard Drive
Length 42 bytes.
Partition Number 4 4
Describes the entry in a partition table, starting with entry 1.
Partition number zero represents the entire device. Valid
partition numbers for a MBR partition are [1, 4]. Valid partition
numbers for a GPT partition are [1,
NumberOfPartitionEntries].
Partition Start 8 8
Starting LBA of the partition on the hard drive
Partition Size 16 8
Size of the partition in units of Logical Blocks
Partition Signature 24 16 
Signature unique to this partition:
• If SignatureType is 0, this field has to be initialized with 16
zeroes.
• If SignatureType is 1, the MBR signature is stored in the
first 4 bytes of this field. The other 12 bytes are initialized
with zeroes.
• If SignatureType is 2, this field contains a 16 byte
signature.
Partition Format 40 1
Partition Format: (Unused values reserved)
0x01 – PC-AT compatible legacy MBR (see Section 5.2.1).
Partition Start and Partition Size come from
PartitionStartingLBA and PartitionSizeInLBA for
the partition.
0x02 – GUID Partition Table (see Section 5.3.2).
Signature Type 41 1
Type of Disk Signature: (Unused values reserved)
0x00 – No Disk Signature.
0x01 – 32-bit signature from address 0x1b8 of the type
0x01 MBR.
0x02 – GUID signature.



9.4 Device Path Generation Rules
9.4.2 Rules with ACPI _HID and _UID
ACPI仕様で説明したように、ACPIは_HID、_CID、_UIDなど、いくつかの異なる種類のデバイス識別オブジェクトをサポートしています。

_UIDデバイス識別オブジェクトはACPIではオプションであり、同じIDを持つ複数の_HIDが存在する場合にのみ必要です。

ACPI名前空間が_UIDを実装していない場合、ACPIデバイスパス構造には_UIDフィールドにゼロが含まれている必要があります。

_UIDフィールドは、再起動後も保持される一意のシリアル番号です。

ACPI名前空間内のデバイスが_HIDを持ち、_CRS(Current Resource Setting)で記述されている場合は、ACPIデバイスパス構造で記述する必要があります。

_CRSは、デバイスが他の標準によってマッピングされていないことを意味します。

_CRSは、非標準デバイスをプラグアンドプレイデバイスにするためにACPIによって使用されます。

ACPIネームスペースの設定方法により、ACPIドライバは標準的な方法でデバイスを設定できます。

_CIDが存在すると、ACPI Device PathノードまたはExpanded ACPI Device Pathノードを使用する必要があるかどうかが決まります。

Table 93. ACPI _CRS to EFI Device Path Mapping
---------------------------------------------------------------------------
PCI Root Bus -> ACPI Device Path: _HID PNP0A03, _UID
---------------------------------------------------------------------------

ルートPCIブリッジのサポートには、EFIデバイスパスに特別なルールが必要です。

ルートPCIブリッジは、通常、独自のバスを消費し、PCIバスを生成するチップセットに含まれるPCIデバイスです。

典型的なデスクトップおよびモバイルシステムでは、ルートPCIブリッジは1つだけです。

大規模なサーバーシステムには、通常複数のルートPCIブリッジがあります。

ルートPCIブリッジの動作は、現在のPCI仕様では定義されていません。

ルートPCIブリッジは、PCIバスを消費して生成するPCI対PCIブリッジと混同しないでください。

PCI-PCIブリッジの動作と構成は、現在のPCI仕様で完全に規定されています。

ルートPCIブリッジは、PNP0A03のプラグアンドプレイIDを使用します。これは、ACPIデバイスパス_HIDフィールドまたは拡張ACPIデバイスパス_CIDフィールドに格納され、ACPIネームスペースと一致します。

ACPIデバイスパス構造の_UIDは、ACPI名前空間の_UIDと一致する必要があります。




9.6 EFI Device Path Display Format Overview
このセクションでは、EFIデバイスパスプロトコルとテキストの間の推奨される変換について説明します。 また、これらを実装するための標準プロトコルについても説明します。 目標は次のとおりです。
•標準化された表示形式。 これにより、ドキュメントおよびテストツールは、複数のベンダーが提供するドライバからの出力を理解することができます。
•読みやすさを向上させる。 デバイスのパスは人が読む必要があるため、フォーマットは解読できる形式で、業界標準のデータ提示手段を可能な限り維持する必要があります。 この場合、表示専用フォームと解析可能フォームの2つのフォームがあります。
•必要に応じて、テキストからバイナリ形式への往復変換、およびテキストの損失なし。
•コマンドラインの解析が簡単です。 デバイスパスは、シェルから実行されるUEFIアプリケーションのコマンドラインに表示される可能性があるため、アプリケーションまたはシェルによって基本コマンドライン処理を禁止してはいけません。

9.6.1 Design Discussion


9.6.1.6 Text Device Node Reference
Parameter Types
Table 95. EFI Device Path Option Parameter Values

EISAID 
ACPI仕様で使用される形式の7文字のテキスト識別子。 最初の3文字は大文字または小文字のアルファベットでなければなりません。 2番目の4文字は、数字、大文字または小文字の16進数です。 オプションで、番号0にすることもできます。



Table 96. Device Node Table


Type: 2 (ACPI Device Path)
SubType: 1 (ACPI Device Path)
HID=PNP0A03
PciRoot(UID)
The UID parameter is an integer. It is optional but required for display.
The default value is zero.





Type: 4 (Media Device Path)
SubType: 1 (Hard Drive)
HD(Partition,Type,Signature,Start, Size)
HD(Partition,Type,Signature) (Display Only)
The Partition is an integer representing the partition number. It is
optional and the default is 0. If Partition is 0, then Start and Size are
prohibited.
The Type is an integer between 0-255 or else the keyword MBR (1) or
GPT (2). The type is optional and the default is 2.
The Signature is an integer if Type is 1 or else GUID if Type is 2. The
signature is required.
The Start is a 64-bit unsigned integer. It is prohibited if Partition is 0.
Otherwise it is required.
The Size is a 64-bit unsigned integer. It is prohibited if Partition is 0.
Otherwise it is required.


12 Protocols - Media Access
12.1 Load File Protocol
This section defines the Load File protocol. This protocol is designed to allow code running in the
boot services environment to find and load other modules of code.

12.4 Simple File System Protocol
This section defines the Simple File System protocol. This protocol allows code running in the EFI
boot services environment to obtain file based access to a device.
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL is used to open a device volume and return an
EFI_FILE_PROTOCOL that provides interfaces to access files on a device volume.


13 Protocols - PCI Bus Support
13.2.1 PCI Root Bridge Device Paths
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLは、ドライバがサービスを利用できるようにハンドルにインストールする必要があります。 EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLに加えて、
EFI_DEVICE_PATH_PROTOCOLも同じハンドルにインストールする必要があります。 EFI_DEVICE_PATH_PROTOCOLの詳細については、第9章を参照してください。
通常、ACPIデバイスパスノードは、PCIルートブリッジを記述するために使用されます。システム内のバス階層に応じて、追加のデバイスパスノードがこのACPIデバイスパスノードに先行する場合があります。デスクトップシステムには通常、PCIルートブリッジが1つしか含まれていないため、EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLとEFI_DEVICE_PATH_PROTOCOLのハンドルが1つあります。サーバーシステムには複数のPCIルートブリッジが含まれている可能性があるため、それぞれのPCIルートブリッジのハンドルこれらのハンドルのうち、
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOLおよびEFI_DEVICE_PATH_PROTOCOLが含まれます。どの場合も、PCIルートブリッジのACPIデバイスパスノードの内容は、そのシステムのACPIテーブルにある情報と一致する必要があります。
表112に、デスクトップシステムのPCIルートブリッジのデバイスパスの例を示します。 現在、デスクトップシステムには通常、1つのPCIルートブリッジが含まれています。 このデバイスパスは、ACPIデバイスパスノードとデバイスパスエンド構造で構成されています。 _HIDおよび_UIDは、PCIルートブリッジのACPIテーブル記述と一致していなければなりません。 PCIルートブリッジが1つしかないシステムの場合、_UID値は通常0x0000です。 このデバイスパスの簡略表記は、ACPI(PNP0A03,0)です。

Table 112. PCI Root Bridge Device Path for a Desktop System
Type 0x02 – ACPI Device Path.
Sub Type 0x01 - ACPI Device Path.
Length 0x0C - 12bytes.
_HID (4,4) 0x41D0, 0x0A03  
PNP0A03 – 0x41D0 represents the compressed string ‘PNP’ and is  encoded in the low order bytes.  The compression method is described in the ACPI Specification.
_UID (8,4) 0x0000


16 Protocols — USB Support
16.1 USB2 Host Controller Protocol
セクション16.1とセクション16.1.1は、USB2ホストコントローラプロトコルについて説明します。 このプロトコルは、USB2ホストコントローラのI / O抽象化を提供します。 USB2ホストコントローラは、ユニバーサルシリアルバス(USB)にインタフェースするハードウェアコンポーネントです。 データ構造を処理し、USB上でトランザクションを生成することにより、システムメモリとUSB上のデバイス間でデータを移動します。 このプロトコルは、ユニバーサルシリアルバスを介してすべてのデータトランザクションを実行するためにUSBバスドライバによって使用されます。 また、USBホストコントローラに統合されたUSBルートハブを管理するためのサービスも提供します。 USBデバイスドライバはこのプロトコルを直接使用しません。 代わりに、USBバスドライバによって生成されたI / O抽象化を使用します。 このプロトコルは、USBバスに直接アクセスする必要のあるドライバのみが使用する必要があります。

16.1.1 USB Host Controller Protocol Overview
USBホストコントローラプロトコルは、EFIブートサービス環境で動作するコード(通常はUSBバスドライバ)によって使用され、USBバスを介してデータトランザクションを実行します。さらに、USBバスのルートハブの抽象化も提供します。
EFI_USB2_HC_PROTOCOLで提供されるインタフェースは、USBバス上のデータトランザクションを管理するために使用されます。また、USBルートハブの制御方法も提供します。 EFI_USB2_HC_PROTOCOLは、USB 1.1およびUSB 2.0準拠のホストコントローラの両方をサポートするように設計されています。
EFI_USB2_HC_PROTOCOLは、EHCI、UHCIおよびOHCI標準で動作するように設計された基本機能を抽象化しています。このプロトコルを使用することで、基盤となるUSBホストコントローラがXHCI、EHCI、OHCI、またはUHCI規格に準拠しているかどうかを知ることなく、単一のUSBバスドライバを実装できます。
EFI_USB2_HC_PROTOCOLの各インスタンスは、プラットフォーム内のUSBホストコントローラに対応しています。プロトコルは、USBホストコントローラの親バスタイプのデバイスドライバによって作成されたUSBホストコントローラのデバイスハンドルに接続されています。たとえば、PCIデバイスとして実装されているUSBホストコントローラには、PCIデバイスドライバがEFI_USB2_HC_PROTOCOLのインスタンスを生成する必要があります。





Advanced Configuration and Power Interface Specification
Version 6.2
May 2017

Overview
What is ACPI?
ACPIは、まず、ホストOS内にサブシステムを形成する、アーキテクチャに依存しない電源管理および構成フレームワークとして理解できます。 このフレームワークは、電源状態(スリープ、休止状態、起床など)を定義するハードウェアレジスタセットを確立します。 ハードウェアレジスタセットは、専用ハードウェアおよび汎用ハードウェアでの操作に対応できます。
標準のACPIフレームワークとハードウェアレジスタセットの主な目的は、OSからファームウェアをネイティブに直接呼び出さずに電源管理とシステム構成を可能にすることです。 ACPIは、図0-1および図0-2に示すように、システムファームウェア(BIOS)とOSの間のインターフェイスレイヤーとして機能し、一定の制限とルールを備えています。

Operating System
↑           ↓
ACPI subsystem
System firmware
Figure 0-1. ACPI overview

基本的に、ACPIは、システムファームウェアとOSの間で共有されるデータテーブルと定義ブロックの2種類のデータ構造を定義します。 これらのデータ構造は、ファームウェアとOSとの間の主要な通信メカニズムです。 データテーブルは生データを格納し、デバイスドライバによって消費されます。 定義ブロックは、インタプリタによって実行可能なバイトコードで構成されます。

DATA Tables           
                                   OS
                                   ↓
Definition blocks →   AML interpliter ⇔ ACPI namespace ( Objects )
                                   ↓ 
                               System hardware
Figure 0-2. ACPI structure

この定義ブロックのバイトコードは、ACPIソース言語(ASL)コードからコンパイルされます。 ASLは、ACPIオブジェクトの定義と制御メソッドの記述に使用される言語です。 ASLコンパイラは、ASLをACPIマシン言語(AML)バイトコードに変換します。 AMLは、図0-3に示すように、AMLインタプリタによって処理される言語です。

ASL code
   ↓
ASL compiler
   ↓
[Definition blocks ( AML byte bode )]]
   ↓
AML interpliter
Figure 0-3. ASL and AML

AMLインタプリタはバイトコードを実行し、定義ブロック内のオブジェクトを評価して、バイトコードがループ構成、条件付き評価、アクセス定義済みアドレス空間を実行し、アプリケーションが必要とするその他の操作を実行できるようにします。 AMLインタプリタは、システムメモリ、I / O、PCI構成など、定義されたアドレス空間への読み取り/書き込みアクセス権を持ちます。オブジェクトと呼ばれるエントリポイントを定義することによって、これらのアドレス空間にアクセスします。オブジェクトは直接定義された値を持つことができます。そうでなければ、AMLインタプリタによって評価され、解釈されなければなりません。
列挙可能なオブジェクトのこのコレクションは、ACPI名前空間と呼ばれるOS構成です。名前空間は、システム上のACPIデバイスの階層表現です。システムバスは、これらのACPIデバイスの列挙のルートです。 PCIまたはUSBデバイスのような他のバスで列挙可能なデバイスは、通常、ネームスペースに列挙されません。代わりに、独自のバスがデバイスを列挙し、ドライバをロードします。ただし、すべての列挙可能なバスには、ACPIが通常これらのデバイスのドライバを読み込まないにもかかわらず、ACPIでデバイスのバス固有のアドレスをエンコードできるようにするエンコード技術があります。
一般に_HIDオブジェクト(ハードウェア識別オブジェクト)を持つデバイスは列挙され、そのドライバはACPIによってロードされます。 _ADRオブジェクト(物理アドレスオブジェクト)を持つデバイスは、通常、ACPIによって列挙されず、一般にACPIによってドライバがロードされません。 _ADRデバイスは通常、ACPIを必要とせずにすべての必要な機能を実行できますが、デバイスドライバが機能を実行できない場合、またはドライバがシステムファームウェアと通信する必要がある場合、ACPIはオブジェクトを評価して必要な機能を実行できます。
一例として、PCIはネイティブのホットプラグをサポートしていません。しかし、PCIはACPIを使用してオブジェクトを評価し、PCI上でホットプラグを実行するために必要な機能をACPIが満たすようにするメソッドを定義することができます。
ACPIの追加の側面は、システム操作中に発生するACPI割り込みイベントを処理する実行時モデルです。 ACPIは、これらのイベントを処理するために必要なオブジェクトを評価し続けます。この割り込みベースのランタイムモデルについては、以下のランタイムモデルのセクションで詳しく説明します。

ACPI Initialization
ACPIがどのように動作するかを理解する最良の方法は、時系列です。ユーザがシステムの電源を入れると、システムファームウェアはセットアップ、初期化、および自己テストを完了します。
その後、システムファームウェアは、ブートストラップローダに制御を渡す前に、ファームウェアの初期化中に得られた情報を使用して、必要に応じて様々なプラットフォーム構成および電源インタフェースデータでACPIテーブルを更新する。拡張ルートシステム記述テーブル(XSDT)は、ACPIサブシステムによって使用される最初のテーブルであり、システム上の他のACPIテーブルの大部分のアドレスを含みます。 XSDTは、固定ACPI記述テーブル(FADT)と、初期化時にOSが処理する他の主要テーブルを指します。 OSが初期化されると、FADTはACPIサブシステムを、定義ブロックを含む最初のテーブルであるため、ネームスペースの始まりである差別化システム記述テーブル(DSDT)に指示します。
次に、ACPIサブシステムはDSDTを処理し、ACPI定義ブロックから名前空間を構築し始める。また、XSDTはセカンダリシステム記述テーブル(SSDT)を指し、名前空間に追加します。 ACPIデータテーブルは、システムハードウェアに関するOS rawデータを提供します。
OSがACPIテーブルからネームスペースを構築した後、OSはネームスペース内で遭遇するすべての_HIDデバイスのネームスペースとローディングデバイスドライバをトラバースし始めます。

System firmware
XSDT
[FADT /  SSDTs  /  Major ACPI tabels]

XSDT → DSDT

[DSDT  /  SSDTs] → ACPI namespace
Figure 0-4. ACPI initialization

1 Introduction
ACPI(Advanced Configuration and Power Interface)仕様は、堅牢なオペレーティングシステム(OS)指向のマザーボードデバイス構成と、デバイスとシステム全体の電源管理を可能にする業界共通インタフェースを確立するために開発されました。 ACPIは、オペレーティングシステムが指向する構成と電源管理(OSPM)の重要な要素です。
ACPIは、Power Management BIOSコード、Advanced Power Management(APM)アプリケーションプログラミングインターフェイス(API、PNPBIOS API、マルチプロセッサ仕様(MPS)テーブルなど)の既存のACPI前コレクションを、明確な電力管理および構成インターフェイス仕様に展開しました。 ACPIは、既存の(レガシー)ハードウェアからACPIハードウェアへの秩序ある移行手段を提供し、ACPIとレガシーの両方のメカニズムを単一のマシンに存在させ、必要に応じて使用することができます。
さらに、元のACPI仕様の開始時に構築されたシステム・アーキテクチャーは、歴史的な「プラグ・アンド・プレイ」インターフェースの限界を広げました。 ACPIは、より堅牢で潜在的により効率的な方法で高度なアーキテクチャをサポートするために、既存のマザーボード構成インタフェースを進化させました。
この仕様書で定義されているインタフェースとOSPMの概念は、デスクトップ、モバイル、ワークステーション、およびサーバマシンを含むすべてのコンピュータクラスに適しています。電源管理の観点から、OSPM / ACPIは、システム全体を低電力状態(スリープ状態)にするなど、未使用のデバイスを低電力状態に移行することによって、システムがエネルギーを節約するというコンセプトを推進します。
このドキュメントでは、ACPIハードウェアインターフェイス、ACPIソフトウェアインターフェイス、およびACPIデータ構造について説明します。このインターフェイスは、実装すると、堅牢なOS指向の構成と電源管理(OSPM)をサポートします。


2 Definition of Terms
2.1 General ACPI Terminology
Operating System-directed Power Management (OSPM)
A model of power (and system) management in which the OS plays a central role and uses global information to optimize system behavior for the task at hand.


3 ACPI Concepts
3.7 Configuration and “Plug and Play”
電源管理に加えて、ACPIインターフェイスは、OSPMがマザーボードデバイスの必要なリソースを動的に挿入および削除できるように設定するためのコントロールと情報を提供します。 差別化システム記述テーブル(DSDT)および二次システム記述テーブル(SSDT)を含むACPI定義ブロックは、ACPI名前空間と呼ばれる階層形式のマザーボードデバイスを記述する。 OSは、ハードウェアIDを持つデバイスを探してACPI名前空間を読み込むだけで、マザーボードデバイスを列挙します。
ACPIによって列挙される各デバイスには、デバイスが占有する可能性があるハードウェアリソース、デバイスで現在使用されているリソースを報告するオブジェクト、およびそれらのリソースを構成するオブジェクトを報告するACPI名前空間のACPI定義オブジェクトが含まれます。 この情報は、デバイスを構成するためにプラグアンドプレイOS(OSPM)によって使用されます。


4 ACPI Hardware Specification
ACPIは、ACPI互換のOSがACPI互換のハードウェアプラットフォームを制御および通信できる標準的なインターフェイスメカニズムを定義しています。ただし、ACPIハードウェア仕様が実装されている場合、プラットフォームはこのセクションの要件を満たしている必要があります(「ハードウェア削減ACPI」を参照)。
このセクションでは、ACPIのハードウェアの側面について説明します。
ACPIは、プログラミングモデルとその動作として「ハードウェア」を定義します。 ACPIは既存のレガシープログラミングモデルの多くを同じように保つよう努めています。しかし、特定の機能目標を達成するために、指定された機能は、特定のアドレッシングおよびプログラミングスキームに準拠しています。このカテゴリに属する​​ハードウェアを「固定」と呼びます。
ACPIはこれらの変更を最小限に抑えるよう努めていますが、ハードウェアエンジニアは、このセクションを注意深く読んで、レガシー専用ハードウェアモデルをACPI /レガシーハードウェアモデルまたはACPI専用ハードウェアモデルに変換するために必要な変更を理解する必要があります。
ACPIは、ハードウェアを固定または汎用の2つのカテゴリに分類します。固定カテゴリに収まるハードウェアは、ACPIのプログラミングおよび動作仕様を満たしています。一般的なカテゴリに入るハードウェアは、その実装において広範な柔軟性を有する。


5 ACPI Software Programming Model
ACPIは、第4項「ACPIハードウェア仕様」で説明しているように、ACPI互換OSがマシンのコア電源管理機能を制御するために使用するハードウェアレジスタインタフェースを定義します。ACPIは、ACPIシステムの電源管理と構成を制御するための抽象的なインタフェースも提供します。最後に、ACPIは、ACPI互換OSとプラットフォームランタイムファームウェアとの間のインターフェースを定義する。
ハードウェアベンダーが実装を柔軟に選択できるように、ACPIは表を使用してシステム情報、機能、およびそれらの機能を制御する方法を記述します。これらの表には、システムボード上のデバイス、または他のハードウェア標準を使用して検出または電源管理できないデバイスと、第3章「概要」で説明した機能が一覧表示されています。システムで使用可能な電源プレーンとクロックソース、バッテリ、システムインジケータライトなどの説明。これにより、OSPMはシステムコントロールの実装方法を知らなくてもシステムデバイスを制御できます。
このセクションで扱うトピックは次のとおりです。
•ACPIシステム記述テーブルのアーキテクチャが定義され、そのアーキテクチャでOEMが提供する定義ブロックの役割について説明します。
•ACPI名前空間の概念について説明します。

5.3 ACPI Namespace


6 Device Configuration
6.1 Device Identification Objects
6.1.5 _HID (Hardware ID)
This object is used to supply OSPM with the device’s PNP ID or ACPI ID.1
When describing a platform, use of any _HID objects is optional. However, a _HID object must be used to describe any device that will be enumerated by OSPM. OSPM only enumerates a device when no bus enumerator can detect the device ID. For example, devices on an ISA bus are enumerated by OSPM. Use the _ADR object to describe devices enumerated by bus enumerators other than OSPM.
Arguments:
None
Return Value:
An Integer or String containing the HID
A _HID object evaluates to either a numeric 32-bit compressed EISA type ID or a string. If a string, the format must be an alphanumeric PNP or ACPI ID with no asterisk or other leading characters.
A valid PNP ID must be of the form "AAA####" where A is an uppercase letter and # is a hex digit. A valid ACPI ID must be of the form "NNNN####" where N is an uppercase letter or a digit ('0'-'9') and # is a hex digit. This specification reserves the string "ACPI" for use only with devices defined herein. It further reserves all strings representing 4 HEX digits for exclusive use with PCI-assigned Vendor IDs.
Example ASL:
Name (_HID, EISAID ("PNP0C0C")) // Control-Method Power Button
Name (_HID, EISAID ("INT0800")) // Firmware Hub
Name (_HID, "ACPI0003") // AC adapter device
Name (_HID, "MSFT0003") // Vendor-defined device
Name (_HID, "80860003") // PCI-assigned device identifier



参考情報
Unified Extensible Firmware Interface Forum
Home » Developers » Registries
PNP ID AND ACPI ID REGISTRY
http://www.uefi.org/PNP_ACPI_Registry

COMPANY       PNP ID     Approved on Date
MICROSOFT    PNP         03/05/2004
INTEL CORP    ICO         08/10/2000

Vendor IDs are subject to uniqueness requirements and some ID requests may not be available. For instance, Microsoft has reserved the PNP ID’s Vendor ID "PNP" to identify various devices that do not have an existing EISA ID, as well as defining compatibility devices. These IDs are defined in the file(↓).

WINDOWS GENERIC DEVICE IDs
DEVICE ID RANGES

ID range Category
--------  -------------
PNP0xxx System devices
PNP8xxx Network adapters 
PNPAxxx SCSI, proprietary CD adapters 
PNPBxxx Sound, video capture, multimedia
PNPCxxx - Dxxx Modems
--Peripheral Buses--
PNP0A00         ISA Bus
PNP0A01         EISA Bus
PNP0A02         MCA Bus
PNP0A03         PCI Bus
PNP0A04         VESA/VL Bus

ACPI for Developers  // Bumblebee-Project/Bumblebee
https://github.com/Bumblebee-Project/Bumblebee/wiki/ACPI-for-Developers


Compaq Computer Corporation
Phoenix Technologies Ltd.
Intel Corporation
Plug and Play BIOS Specification
Version 1.0A
May 5, 1994

4.0 Configuration Support
4.7 Extended Configuration Services



Compaq Computer Corporation
Phoenix Technologies Ltd.
Intel Corporation
BIOS Boot Specification 
Version 1.01
January 11, 1996

1.0  Introduction
1.2  Related Documents
Plug and Play BIOS Specification 1.0A Compaq/Phoenix/Intel


1.3  Purpose
この仕様の目的は、BIOSがシステム内のすべてのIPL(初期プログラムロード)デバイスを識別し、ユーザーが選択した順序で優先順位を付け、次に各デバイスを順番に調べてブートを試みる方法を説明することです。 プラグアンドプレイBIOS仕様では、ブートプロセス中にBIOSに追加の要件が課せられ、CD-ROM、ネットワークリモートブート、PCMCIAなどのように起動可能なデバイスが増えているため、BIOSの起動がよりインテリジェントになります。 この仕様では、実質的に既存のIPLデバイスからのブートを可能にし、将来のIPLデバイスの定義についても十分に汎用的で柔軟性のあるブートスキームを定義することが重要です。


category: PC-HW

tb: 0   cm: 0

Intel Platform System Address Map 調査メモ  

Sorry Now Writing!

調査範囲 7th GEN Intel Processor Families for S Platform

情報源
■本家本元のデータシートです。
7th Generation Intel Core Processor Families for S Platform
Datasheet – Volume 2 of 2
January 2017
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/7th-gen-core-family-desktop-s-processor-lines-datasheet-vol-2.pdf


BIOS環境下でのメモリーマップについて記述されています。
White Paper A Tour beyond BIOS Memory Map
Design in UEFI BIOS
Jiewen Yao Intel Corporation
Vincent J. Zimmer Intel Corporation
February 2015
https://firmware.intel.com/content/tour-beyond-bios-memory-map-design-uefi-bios


HP UEFI シェルユーザーガイド
https://h50146.www5.hpe.com/lib/products/servers/proliant/manuals/744994-191a_ja.pdf



Haswellのシステムメモリマップについて書かれています。
InfoSec Institute / System Address Map Initialization in x86/x64 Architecture
Part 2: PCI Express-Based Systems by Darmawan Salihun on JANUARY 9, 2014
http://resources.infosecinstitute.com/system-address-map-initialization-x86x64-architecture-part-2-pci-express-based-systems/


メモリーリマッピング
http://www.geocities.jp/hpt_user99/MemoryReclaiming.html
の記事にあるとおり、このMemory Remapはメモリアドレスの4GB以下のアドレスにあるメモリホール(メモリマップドI/Oなど)が原因でCPU(OS)がアクセスできない領域の物理メモリアドレスを搭載メモリ量より上のアドレスにRemappingすることで、メモリホール分の物理メモリ領域を取り戻す機能のようです。これをIntel はMemory Reclaimと呼んでいるようです。このMemory Remapの機能を活かすには当然、64bitOSが必要になります。


こちらのサイトに本家本元Intelがメモリーホール問題の対応について記述したドキュメントがありました。
Polywell Computers / Support / FAQ
Not All Memory is Available after Installing 4GB or More of System Memory
... Full White Paper available HERE
http://www.polywell.com/us/support/faq/4gb_rev1.pdf
Intel Chipset 4 GB System Memory Support White Paper
February 2005

テックウィンド HOME>ASUS>メモリーに関するトラブルシューティング
http://www.tekwind.co.jp/faq/ASU/entry_29.php

category: PC-HW

tb: 0   cm: 0

Intel Processor Graphics 調査メモ  

最終更新日 2018/05/23

Sorry. This article is now writing!

Intel Processor Graphics の調査メモです。
最近のIntel CPUにはもれなくグラフィック機能がついています。世の中に出回っているグラフィックでは一番が数が多いのではないでしょうか?
また、グラフィックはPCのデバイスの中で、一番身近で目にするもので、しかも、その性能の良し悪しがわかりやすいデバイスではないでしょうか。
今回はそのPCグラフィックデバイスの内、身近に数多くあるIntel Processor Graphicsを調査してみます。


調査対象はGPUの世代が7.5世代(Haswell)以降のIntel IGDとします。




Intel グラフィックス製品の歴史についてはこちら


Terminology
IGD -> Internal Graphics Device or Integrated Graphics Device.









そもそもグラフィック・ビデオ機能とは?







まずは下記サイトで基礎を学びます。しかし、最近のPC雑誌ではこのような基礎的な技術を解説する記事が非常に少なくなったような気がする。

コンピュータの基礎の基礎 出典:日経パソコン 2002年2月4日号,2002年2月18日号,2002年3月4日号
http://itpro.nikkeibp.co.jp/article/lecture/20070419/268970/

Part1 メモリー空間とは何か 
Part2 RAMの物理的な内部構造は 
Part3 ハードディスクの基本構造 
Part4 ハードディスク性能を決める要素とは 
Part5 グラフィックスチップとメモリー 
Part6 グラフィックスチップの描画機能 



初期では、グラフィックス機能は「メモリ(フレームバッファ)をデータで埋める」のが主な仕事。
出典
PC Watch 骨まで理解するPCアーキテクチャ(GPU編) 第1回
~固定機能からシェーダへの移り変わり 2014/4/4 大原 雄介
http://pc.watch.impress.co.jp/docs/column/1month-kouza/642769.html




フレームバッファ (Frame Buffer)
 画面に表示するための文字やイメージを記録しておくためのメモリ。ビデオバッファ、あるいはビデオメモリ、ビデオRAM(VRAM)とも。ただし、ビデオメモリやVRAMといった場合、フレームバッファを含む(一般的なビデオカードではフレームバッファが大半を占める)ビデオ回路用のメモリ全体を指すのに対し、フレームバッファは、純粋な画面表示領域のことをいう。

 フレームバッファは、通常はメインメモリの一部として割り付けられており、直接、あるいはグラフィックス回路の描画機能等を使って、ここに画面イメージが書き込まれる。書き込まれたイメージは、DAC(Digital to Analog Converter)によって、ディスプレイのタイミングに合せたビデオ信号に変換され画面に表示される。

 グラフィックスモードにおけるフレームバッファの持ち方には、大きく分けると「プレーナ(Planar)方式」と「パックドピクセル(Packed Pixel)方式」とがある。

プレーナ方式は、VGA(Video Graphics Array)の16色モード等で用いられているタイプで、複数のプレーン(Plane~面)を使って1枚のフレームバッファを構成している。
 例えばVGAの場合には、「赤/緑/青/輝度」の要素に対応する、640bit×480bit相当のプレーンが4枚用意されており、これら各プレーンのビットが組みになって(すなわち4bitで)画面上の1ピクセルの情報を表している(*1)。ちなみにVGAの場合には、各プレーンは同一アドレス上にマッピングされているが、98シリーズのように、別のアドレスに置かれる場合もある。

 一方の「パックドピクセル(Packed Pixel)方式」は、VGAの256色モードをはじめとする、Windowsの一般的な高解像度モードで用いられている方式で、1つのフレームバッファは、ひとつのメモリ上にフラットに割り付けられる(言い替えれば1フレーム1プレーン)。例えば256色の場合には、1ピクセルは8bit――すなわち1バイトなの で、1ピクセルに対応したバイト列が、メモリ上にシーケンシャルに並ぶことになる。現行のビデオカードでは、1ピクセルは、8、16、24、32bitのいずれかの値をとり、8bitの場合は、色情報そのものではなく256種類の色情報がセットされたカラーパレット(カラールックアップテーブル)を指すポインタが、16bit以上ではそのままRGBのカラー情報がここに書き込まれる(*2)。


(*1) VGAでは、プレーンの要素が実際の色を表わすのではなく色情報がセットされたカラーパレットを指すポインタになっている。
(*2) 32bitは、メモリを4バイト単位に扱うだけで、ピクセル情報はこのうちの24bit分だけが使用される。ベンダーによっては、この隙間のない24bitのモードのことを特別に「パックドピクセル」と呼ぶことがある。

■鈴木直美の「PC Watch先週のキーワード」 ■
第20回:2月23日~2月27日
https://pc.watch.impress.co.jp/docs/article/980303/key20.htm#FrameBuffer





GPUが単に2Dグラフィック出力を行なうデバイスだった時代では、GPUは出力専用デバイスだったので、CPU側は単に描画コマンドをGPU側に投げるだけで良く、CPUが受け取るのは最終的に描画コマンドの完了通知だけであった。
出典
PC Watch 骨まで理解するPCアーキテクチャ(GPU編) 第4回
~GPGPU性能引き上げのカギとなるCPUとGPUの連携 2014/4/25 大原 雄介
http://pc.watch.impress.co.jp/docs/column/1month-kouza/646073.html


コンピュータのグラフィック機能の歴史についてまとめてあります。↓
ぐうたら感謝の日  / グラフィック機能の歴史
http://www.geocities.co.jp/SiliconValley-Cupertino/6138/computer/graphic/more/history.html





ということで、グラフィックの根本的な機能としては
「メモリにフレームバッファがあって、そこにデータを書き込めば、後はそのチップがそのデータを信号に変換して、ディスプレイに文字や画像なり、また、長方形や円が指定したカラーで表示される」
ことのようです。ここを押さえれば、わかったような気になります。

このディスプレイに表示の部分では
解像度
リフレッシュレート
の要素がある。これはビデオカードの性能で決まります。また、これに対応したディスプレイ装置も必要になります。


フレームバッファの実装
その実装にはフルバッファ方式とタイリング(Tiling)方式がある。










Processor Graphics 概要



Intel Processor Graphics製品系列(Sandy Bridge later and Desktop Product only)

Gen6 -> Sandy Bridge 2011
CPUコアとグラフィックスコア,ノースブリッジ機能がシングルダイに統合

ASCII 見えてきたSandy Bridgeの詳細 4つの特徴を解説
2010年 塩田紳二
http://ascii.jp/elem/000/000/555/555215/


Sandy BridgeのGPUコア「HD Graphics 3000&2000」には,どこまで期待していいのか
http://www.4gamer.net/games/098/G009883/20110112028/


インテル,Sandy Bridgeのアーキテクチャを日本語で詳しく解説 米田 聡
http://www.4gamer.net/games/098/G009883/20100928067/

ASCII / 詳細解説 これがSandy Bridgeのアーキテクチャーだ 2011年 大原雄介
高速化された内蔵GPU Intel HD Graphics 2000/3000
http://ascii.jp/elem/000/000/579/579517/index-5.html
→初のProcessor Graphics のが概要が解説されている。

一番愛好しているのが言うまでもなくインテルで、Sandy Bridge以降のすべてのCPUで、CPUコア同士の接続にこのRing Busを使っている
ロードマップでわかる!当世プロセッサー事情 ― 第449回
いまさら聞けないIT用語集 データ転送経路のRing Bus
2018年03月12日 12時00分更新 大原雄介
http://ascii.jp/elem/000/001/645/1645785/index-2.html


Gen7 -> Ivy Bridge 2012

Gen7.5 -> Haswell 2013 

Gen8 -> Broadwell 2015 

Gen9 -> Skylake 2015 

PC Watch半導体/周辺機器CPUIntel
後藤弘茂のWeekly海外ニュース 2015/11/5
GPUコンピューティング機能を強化したSkylakeのGPU
http://pc.watch.impress.co.jp/docs/column/kaigai/729060.html

Intel HD Graphics
https://ja.wikipedia.org/wiki/Intel_HD_Graphics









Intel Processor Graphics ハードウエア概要

Intel Processor Graphics Updated December 17, 2015
Developer Documents for Intel Processor Graphics
https://software.intel.com/en-us/articles/intel-graphics-developers-guides
--> IGD世代別にハードウエア概要が解説されている。







INTEL® OPEN SOURCE HD GRAPHICS AND INTEL IRIS™ PLUS GRAPHICS PROGRAMMER'S REFERENCE MANUAL (PRM) FOR THE 2016 - 2017 INTEL CORE™ PROCESSORS, CELERON™ PROCESSORS, AND PENTIUM™ PROCESSORS BASED ON THE "KABY LAKE" PLATFORM

Volume 3: GPU Overview
Volume 5: Memory Views
Volume 11: Blitter
Volume 12: Display

https://01.org/linuxgraphics/hardware-specification-prms/2016-intelr-processors-based-kaby-lake-platform


linux用の技術ドキュメントです。この中から2Dに関係するものを抜粋します。
まずは概観から見てみましょう!





Volume 3: GPU Overview
グラフィックス処理ユニットは、メモリマップされたIOレジスタの直接インタフェースを介してCPUによって制御され、CPUがメモリに配置したコマンドを構文解析することによって間接的に制御される。ディスプレイインターフェイスとBlitter(ブロックイメージ転送ツール)は主に直接CPUレジスタアドレスによって制御され、3Dおよびメディアパイプラインとパラレルビデオコーデックエンジン(VCE)は主にメモリ内の命令リストによって制御されます。


Block Diagram of the GPU

                       CPU Register Interface                
                               ↓↑                          ↓↑  
                               ↓↑              Blitter (block image transferrer
                               ↓↑                          ↓↑  
Display Device <-- Display/Overlay   <--  Memory Interface 


 

Volume 5: Memory Views
Graphics Memory Address Spaces 

GMADR
Processor Graphics translation window の開始アドレス。サイズはMSACで決まる。
プロセッサおよび他のピア(DMI)デバイスは、このアドレス空間を使用して、メインメモリにあるグラフィックスデータを読み書きします。このアドレスは内部的にGM_Addressに変換されます。

GTTADR
Global GTT Table Apertureの開始アドレス。
グローバルGTTの場合、この範囲はグラフィックスデバイスの設定領域のメモリBARとして定義されます。これは、ページテーブルエントリ値PTEを書き込むためにソフトウェアが必要とされるエイリアスです。 ソフトウェアは、グローバルグラフィックス変換テーブルGTTからPTE値を読み取ることができる。

GSM
これは、GFXドライバの使用に固有のページ変換用のグローバルGTTエントリを格納するために、物理メモリから取り出した8 MB(最大)の領域です。GTTMMADRを介してCPUパスからアクセスできますが、GPU / DEは同じ領域に直接アクセスできます。

DSM
メインメモリにiGFX用に確保した領域でOSからは見えない。GMADRを経由して、CPUより、また、GPU/DEから直接アクセスできます。

補足
          8MB   ->  Global GTT Table Aperture
GTTADR  --------------------------
          6MB   -> Reserved 
          -----------------
          2MB   -> MMIO
GTTMMADR ------------------------------------------------------

Multi Size Aperture Control (MSAC)
APSZ4: This field is used in conjunction with other APSZ* fields to determine the size
of Aperture (GMADR) and affects certain bits of GMADR register. The description below
is for all APSZ* fields 4:0 -

00000 = 128MB => GMADR.B[26:4] is hardwired to 0
00001 = 256MB => GMADR.B[27] = 0, R0
00010 = illegal (hardware will treat this as 00011)
00011 = 512MB => GMADR.B[28:27] = 0, R0
0100—00110 = illegal (hardware will treat this as 00111)
00111: 1024MB => GMADR.B[29:27] = 0, RO
000-01110 = illegal (hardware will treat this as 01111)
01111= 2048MB => GMADR.B[30:27] = 0, R0
10000-11110 = illegal (hardware will treat this as 11111)
11111 = 4096MB => GMADR.B[31:27] = 0, RO

Main Memory 
統合グラフィックスデバイスは、グラフィック機能用に4KBの物理メイン(システム)メモリを使用することができます。 このメインメモリのいくつかは、初期化中(例えば、VGAバッファ用)にシステムメモリの上から「盗まれる」可能性がある。 しかし、ほとんどのグラフィックスオペランドは、アプリケーション要求を満たすために動的に割り当てられます。 この目的のために、グラフィックスドライバは、ロックダウンされた(すなわち、非スワップ可能な)物理システムメモリページ(通常、キャッシュ可能な非ページプールから)を頻繁に割り当てる必要がある。 大きなサーフェスをバックするために必要なロックされたページは、通常は連続していません。 したがって、不連続な物理ページに裏打ちされた「論理的に連続した」サーフェスをサポートする手段が必要です。 前のセクションで説明したグラフィックス変換テーブル(GTT)は、その手段を提供します。


Volume 11: Blitter
 
これは、2Dグラフィック機能ですね!


Volume 12: Display

North Display Engine Registers 
北の方がメイン機能を司っているようです。メモリのフレームバッファの情報をディスプレイに表示するために電気信号に変換します。

South Display Engine Registers
The South Display Engine supports Hot Plug Detection, GPIO, GMBUS, Panel Power Sequencing, and Backlight Modulation.


BitBlt(Bit Block Transfer)



 当初のアクセラレーター機能はごく単純で、直線や長方形、だ円の描画、囲まれた領域の塗りつぶし、BitBlt程度の機能しかなかった。BitBltとはBit Block Transferの略で、グラフィックスメモリー(以下VRAM)中のある領域を別の場所にコピー/移動する機能だ。そして、拡大、縮小、変形やAND/OR/NOTなど、論理演算を実行する機能などが次第に追加されていった。


PC技術興亡史
Windows時代に入り、グラフィックスアクセラレーター登場
グラフィックス編 第5回
大原 雄介=フリーランス テクニカルライター 2015/04/01
日経テクノロジーオンライン
http://tech.nikkeibp.co.jp/dm/article/FEATURE/20150106/397330/


Intel Processor Graphics コア数


Intel HD Graphicsではコアのことを「EU」と呼ぶ


Kaby Lake (Gen 9 iCPU)
HD Graphics 610 12コア(EU) GT1

PC de GAME
- BTOとゲーミングPCのお話
CPU内蔵GPU
http://pcdegame.zashiki.com/igpu.html



Intel Processor Graphics のBIOSビデオ機能についてはこちら






Graphics メモリ






Intel グラフィイクッスはPCIデバイス側にメモリを実装せず、CPUが使うメインメモリよりその領域を拝借して使用している。そのため、その実装がややこしい模様です。

Intel Processor Graphics
ー>専用メモリを持たず、システムメモリの一部をビデオメモリとして利用。このシステムメモリの一部は一般的にUMA(Unified Memory Architecture)と呼ばれ、BIOSもしくはビデオドライバによってシステムメモリの一部がビデオメモリ専用として確保。

出典
PC Watch / Windows Vistaの仕組みを学ぶ【共有ビデオメモリ編】
(2007年6月14日) [Reported by wakasugi@impress.co.jp]
http://pc.watch.impress.co.jp/docs/2007/0615/vistamech2.htm
Windows Vistaでは、WDDM「Windows Display Driver Model」という名の新しいディスプレイドライバモデルが採用された。これにより、GPUの共有ビデオメモリの取り扱い方法が大きく変更された。


フレームバッファはIGDの場合はメインメモリに置かれる。Intel用語ではフェンス(Fence )と呼ぶようです。そのフレームバッファを含めIGD専用メモリ領域としてUMA方式でメインメモリにその領域を確保する。その専用領域の大きさやアドレスはBIOSで設定される。





OSが立ち上がるまでは

DSM と GSMでVRAMをメインメモリに確保する。UMA(Unified Memory Architecture)

OS起動後
Intel Processor GraphicsはGARTロジックを実装しているので、Windows 10 (WDDM)では上記のDSMに加えPCIe GARTも使用可能になる。

PCIe GARTとは
定義上、AGPはグラフィックスアドレス再配置テーブル(GART)を備えたチップセットを必要とし、非線形システムメモリの線図をグラフィックスデバイスに提供します。しかしながら、PCIeは、メモリリニアライゼーションハードウェアがチップセットではなく、グラフィックス装置自体に存在することを要求する。したがって、AGPスタイルの別個のGARTミニポートドライバではなく、PCIeでのメモリリニアライゼーションのドライバサポートがビデオドライバに存在する必要があります。

Windows XPドライバモデル(XPDM)ドライバで非ローカルビデオメモリを使用するグラフィックハードウェアベンダは、メモリリニアライゼーションハードウェアと対応するソフトウェアの両方を実装する必要があります。

  WDDMと互換性のあるすべてのPCIeグラフィックスアダプタは、ハードウェアとソフトウェアのメモリリニアライゼーションをサポートする必要があります。

IGDまたは外部PCIeグラフィックスカードのグラフィックスメモリが不足している場合に、追加のグラフィックメモリ空間として使用される連続したアドレス空間として使用されます。
グラフィックスアパーチャを提供するために割り当てられたシステムメモリのメモリ管理は、従来のAGPアパーチャと同様にグラフィックス変換テーブルを使用します。
グラフィックアパーチャのメモリ管理を行うのはOSの責任です。具体的にはグラフィックデバイスドライバになります。

出典
InfoSec Institute / System Address Map Initialization in x86/x64 Architecture
Part 2: PCI Express-Based Systems by Darmawan Salihun on JANUARY 9, 2014
http://resources.infosecinstitute.com/system-address-map-initialization-x86x64-architecture-part-2-pci-express-based-systems/

Microsoft PCI Express FAQ for Graphics
https://docs.microsoft.com/ja-jp/windows-hardware/drivers/pci/pci-express-faq-for-graphics



Intel 7th Core Processor
/Host Bridge/DRAM Registers
GMCH Graphics Control Register (GGC)
Base Data of Stolen Memory (BDSM)
Base of GTT stolen Memory (BGSM)
/Processor Graphics Registers
Graphics Translation Table, Memory Mapped Range Address (GTTMMADR)*
Graphics Memory Range Address (GMADR)*
I/O Base Address (IOBAR)*→I/O portアドレスです。
Base Data of Stolen Memory (BDSM)
Multi Size Aperture Control (MSAC)
*は標準PCI BAR


When running in Processor Graphics mode, processor initiated TileX/TileY/linear reads/
writes to GMADR range are supported. Write accesses to GMADR linear regions are
supported from both DMI and PEG. GMADR write accesses to TileX and TiIeY regions
(defined using fence registers) are not supported from the DMI or the PEG port.
GMADR read accesses are not supported from either DMI or PEG.



出典
7th Generation Intel® Processor
Families for S Platforms and Intel®
CoreTM X-Series Processor Family
Datasheet, Volume 2 of 2
May 2017



実機でIntel Processor Graphicsメモリ検証はこちら






 デバイスドライバ





Windows デバイスドライバ

まずは、Windows Vista で登場したWDDMから見てみましょう。


WDDM(The Windows Display Driver Model)


Windows Vistaでは,これまでカーネルモードでのみ動作していたデバイスドライバが,「カーネルモードドライバ」(Kernel Mode Driver)と「ユーザーモードドライバ」(User Mode Driver)に分けられた。

Windows Vista上で,それこそWebブラウザなど,GDIベースのアプリケーションを実行したとしよう。そのとき,GDIベースの描画は,メインメモリの中に作られた仮想的な画面「オフスクリーンバッファ」(Off Screen Buffer)に対して行われる。そして,オフスクリーンバッファに描画された内容を,DirectXを利用して,デスクトップの3D画面「グラフィックスサーフェス」(Graphics Surface)に重ね合わせるという手法が採られているのだ。
このマネージメントを行っているのが「DWM」(Desktop Window Manager)だ。DWMは,GDIとの互換性を提供しつつ,オフスクリーンバッファにアプリケーションソフトの描画を行い,その内容をDirectXのサーフェスに重ねて表示させるという仕事をしている。
Windows Vista(のAeroデスクトップ)では一般のアプリケーションの画面描画方法が大きく変わった。GDI互換は維持されているものの,従来は一般的にGDIから画面に直接描画されていたのに対し,「GDI→DWM→DirectX」という流れで画面が描画されているのだ。

Windows Vistaでは,一般のアプリケーションがDWMを通じてDirectXを利用する。そしてもちろん,ゲームからもDirectXを利用しなければならないわけで,従来のDirectXのように複数のアプリケーションからの同時利用が難しい仕様では困ってしまう。
 したがって,WDDMでは複数のアプリケーションから3Dアクセラレーションなどの機能が利用できるよう,DirectXに大幅な変更が加えられている。
出典
4Gamer.net / Vistaを買うのはまだ早い グラフィックス編 米田 聡 
http://www.4gamer.net/specials/tooearlytogetvista/001/tooearlytogetvista_001.shtml
Windowsのグラフィイクッス周りの基本的な事柄がよくわかる。


WDDM
Windows Display Driver Model (WDDM) Design Guide
https://docs.microsoft.com/ja-jp/windows-hardware/drivers/display/windows-vista-display-driver-model-design-guide

Graphics Memory Reporting through WDDM January 9, 2006
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/graphicsmemory.doc



DirectX 10/SM4.0はWindows Vista専用。厳密なバージョンコントロールで亜流バージョンはなし

DirectXによって提供されてきたグラフィックサブシステムのDirect3Dは、複数のアプリケーションから同時利用されることを想定していなかった。Windows Vistaでは、そのGUIがDirect3D 9(Ex)によって実現されており、これとは別にDirect3D 10も実装されている。同時に複数の3Dアプリケーションを動作させたり、GPGPU用途への対応までを視野に入れると、古いシングルタスク前提の設計では都合が悪かったのだ。そこでWindows Vistaという大きな変革に乗じてリリースされるDirectX 10/SM4.0では、マルチスレッドに対応し、さらに動作安定度も向上させた新しいGPUドライバソフトウェアのアーキテクチャを採用した。それが「WDDM : Windows (Vista) Display Driver Model」だ。

WDDMではドライバソフトウェアがユーザーモードとカーネルモードに分かれ、アプリケーションからの不当なドライバ制御などでシステムクラッシュが起こりにくい設計としている。また、GPUのハードウェア的なマルチスレッド対応度に応じてWDDM 1.0/2.0/2.1というバージョン分けがなされ、WDDM 1.0はDirectX 9世代以前の旧設計のGPUをWDDM実装したもの、そしてあらかじめDirectX 10をターゲットにして開発されたGPUはWDDM 2.0以降の実装で提供される。1.0と2.0/2.1の違いは実質的にはマルチスレッドの対応レベルの違いを表しており、1.0はノンプリエンプティブ(*1)なマルチスレッドに対応し、2.0/2.1はプリエンプティブなマルチスレッド(*2)に対応する。2.0と2.1の違いは主にマルチスレッド粒度の違いにあり、2.1の方がより細かいターゲット単位でスレッド切り替えが行える。

Windows Vistaのグラフィックサブシステム

                         Application
                                ↓
User-Mode DriverDirect3D
                                ↓
      DXGKrnl(GPU scheduler Video Memory Manager)
                                ↓
                  Kernel-Mode Driver
                                ↓
                 Graphics Hardware 


GPUとシェーダ技術の基礎知識(6)
2008/02/29 13:30:00 トライゼット西川善司
https://news.mynavi.jp/article/graphics-6/



ビデオメモリの容量表示
注意!!
Windows 10 ドライバにおいては、Intel IGDのアダプタプロパティで表示される「専用ビデオメモリ」の容量は一部のゲームアプリケーションがVRAMなしと判断しないように、決め打ちで128MBに設定されているそうです。あーややこしい!


出典
Intel Support Home  Intel Graphics Drivers 
Frequently Asked Questions for Intel Graphics Memory on Windows 10
https://www.intel.com/content/www/us/en/support/graphics-drivers/000020962.html

抜粋始まり
How much graphics memory does my computer have?
Display adapter properties
Note The reported Shared System Memory is not an ongoing reservation of system memory. It's simply the limit of how much system memory the OS will allow graphics to use at a given time, on the given platform.

Note By default, the Intel graphics driver will report 128 MB of fictitious Dedicated Video Memory for compatibility with applications that don’t correctly comprehend a fully unified memory architecture. See Dedicated Memory Reporting for more information.
抜粋終わり


ビデオメモリ表示ツール
GpuMemTest
http://www.programming4beginners.com/gpumemtest




Linux Graphics ドライバ


Linux Graphics関連情報はこちらが参考になります。

Martin Peres Publication Archive 2012 NOV 25
A deeper look into GPUs and the Linux Graphics Stack
Slides
https://publications.mupuf.org/files/toulibre2012_deeper_look.pdf

そのによりますと、

The GPU needs the host for:
Setting the screen mode/resolution (mode setting);
Configuring the engines and communication busses;
Handling power management;
Thermal management (fan, react to overheating/power);
      Change the GPU’s frequencies/voltage to save power;
Processing data:
      Allocate processing contexts (GPU VM + context ID);
      Upload textures or scientific data;
      Send commands to be executed in a context.


Overview of the components of a graphics stack
A GPU with its screen;
One or several input devices (mouse, keyboard);
A windowing system (such as the X-Server and Wayland);
Accelerated-rendering protocols (such as OpenGL);
Graphical applications (such as Firefox or a 3D game).

Components of the Linux Graphics stack
Direct Rendering Manager (DRM) : exports GPU primitives;
X-Server/Wayland : provide a windowing system;
Mesa : provides advanced acceleration APIs;

だそうです。




Intel Processor Graphicsのデバイスドライバ関連情報源として以下、ドキュメントがありますが、解読するにはかなり難易度が高いです。

Intel Open Source 01.ORG
Home / Intel Graphics for Linux / Intel Graphics for Linux - Documentation
Hardware Specification - PRMs (PROGRAMMER'S REFERENCE MANUAL)
https://01.org/linuxgraphics/documentation
--> IGD世代別のドライバ関連情報が記載されている。

Intel Open Source Graphics Programmer Reference Manual (PRM)
https://github.com/Igalia/intel-osrc-gfx-prm


Linux DRM(Direct Rendering Manager) driver


2016年12月12日 Linux 4.9が正式公開,2200万行を超える史上最大のビッグリリースに
2016年12月12日
階戸アキラ

Linus Torvaldsは12月11日(米国時間)⁠,Linuxカーネルの最新版である「Linux 4.9」を正式公開した。「⁠これまででもっとも大きなリリースだと確信している」とLinusが明言しているとおり,総コード行数は約2234万行,5万6000を超えるファイルで構成されており,過去最大サイズのカーネルとなっている。

Intel DRMに関してもいくつかのフィックスが実施されており,Skylakeサポートの改善や,DMA-BUF(DMAバッファ)におけるインプリシットフェンシングのフルサポートなどが含まれている。また4.9からIntel Integrated Sensor Hub(ISH)もサポートされた。

http://gihyo.jp/admin/clip/01/linux_dt/201612/12









ディスプレイインターフェイス Display Interface



映像データインターフェイス基礎

ホーム > EIZOライブラリー > 掲載記事 > 第2回 DisplayPortからD-Subまで――液晶ディスプレイの「映像入力インタフェース」を網羅する
http://www.eizo.co.jp/eizolibrary/other/itmedia02_02/



Processor GraphicsからはDigital Display Interface (DDI)で出力され、CPU外のマザーボード上の実装で、HDMI、DisplayPort、D-Subなどに変換される。








Intel Processor Graphics(Kaby Lake) 4K-60p対応

HDMI
マザーボードにコンバータチップを載せて、4K-60pを実現しているようです。

DisplayPort
ネイティブに対応しているようです。しかし、まだ、ケーブルのお値段がお高いでしょうか?


出典
マルチディスプレイのまとめスタイル修正
http://multidisplay2.blogspot.jp/2013/01/intel-igpu.html











参考文献 URL




GPUを支える技術
――超並列ハードウェアの快進撃[技術基礎]
著者 Hisa Ando 
技術評論社 (2017/6/30)








FreeBSD graphics support for Intel
https://www.slideshare.net/YuichiroNaito/intel-graphics


マルチディスプレイのまとめ
http://multidisplay2.blogspot.jp/2013/01/intel-igpu.html
--> 映像出力インターフェイスに詳しい

Mapping Virtual Addresses to a Memory Segment
https://docs.microsoft.com/ja-jp/windows-hardware/drivers/display/mapping-virtual-addresses-to-a-memory-segment


Drupalサイト構築&動画作成
メモリーエラー
https://phoenixknight.jp/blog/%E3%83%A1%E3%83%A2%E3%83%AA%E3%83%BC%E3%82%A8%E3%83%A9%E3%83%BC




category: PC-HW

tb: 0   cm: 0

Desktop 4-7th Generation Intel Core Processor Configuration Register Overview  

Now writing


Principal Registers

1. Host Bridge/DRAM Registers
General
TOM—Top of Memory : This Register contains the size of physical memory.
TOUUD—Top of Upper Usable DRAM
TOLUD—Top of Low Usable DRAM
REMAPBASE—Remap Base Address Register
REMAPLIMIT—Remap Limit Address Register

Memory
MCHBAR—Host Memory Mapped Register Range Base

PCIe
PXPEPBAR—PCI Express Egress Port Base Address
DMIBAR—Root Complex Register Range Base Address
PCIEXBAR—PCI Express Register Range Base Address

IGD
GGC—GMCH Graphics Control Register
BDSM—Base Data of Stolen Memory
BGSM—Base of GTT stolen Memory

Intel ME SMM
TSEGMB—TSEG Memory Base

2. Integrated Graphics Device Registers
GTTMMADR(PCI10h)—Graphics Translation Table, Memory Mapped
Range Address
GMADR(PCI18h)—Graphics Memory Range Address
IOBAR(PCI20h)—I/O Base Address



category: PC-HW

tb: 0   cm: 0

Intel PCH I/Oポートフレキシビリティ機能について  

第4世代Coreプロセッサ/8シリーズチップセットのリリースとともに、PCHにI/Oポートフレキシビリティ機能が取り入れられた。この機能は、PCHのSATA,PCIe,USB,の接続数を上限の範囲で、ソフトトラップにより変更を可能とする。

PCIe Root Port のFunction Noはこのソフトトラップの設定により可変となる。
PCIの規定によりマルチファンクションデバイスはFunction No 0の機能を持たなければならない。
I/Oポートフレキシビリティ機能により、PCH PCIe Controller のRoot PortでFunction No がデフォルトで0であって、このRoot Portが無効化された場合は、PCIの上記規定によりこのデバイスの他のRoot PortをFunction No 0にする必要がある。

8/9シリーズチップセットPCH では上記のソフトトラップはPCI Express Root Ports register (RCBA+404h)で設定する。

LPC Interface Bridge Registers (D31:F0) / RCBA (Root Complex Base Address)

出典 
Intel 8 Series/C220/9 Series Chipset Family Platform Controller Hub (PCH) Datasheet
5.3 PCI Express Root Ports


2017/05/15 追記
PCHのI/Oポートフレキシビリティ機能を実現するソフトトラップはIntel 100/200  Series Chipsetより次のように仕様が変更された模様です。

P2SB Bridge (Primay to Sideband Bridge) (D31:F1) / Sideband Register Access BAR (SBREG_BAR)

出典 
Intel 100/200 Series Chipset Family Platform Controller Hub (PCH) Datasheet Vol 1
39 Primay to Sideband Bridge (P2SB)

Intel 100/200 Series Chipset Family Platform Controller Hub (PCH) Datasheet Vol 2
3 P2SB Bridge (D31:F1)


category: PC-HW

tb: 0   cm: 0

PCI/PCI Express バスについて調べてわかったことなど  

最終更新日:2017/11/05

はじめに
PCI/PCI Express(以降PCIe) バスは現在のPCになくてはならない技術です。便利なUSB機器を陰で支えるUSBコントローラもCPUとはPCI Expressバスでつながっています。PCを人間にたとえるなら、CPUが頭脳、各デバイスが手足・目・声、そしてPCI/PCIeバスは神経伝達系と言えるかもしれません。そんなことで興味深々となり、PCI/PCIeバスについてちょっと調べてみました。随時わかったことをこの記事で更新していきます!(いつぅ?完成しますのん)

まずはPCIから
PCI Express を調べるその前に、まず、PCIを知っておかないといけないようです。なぜなら、PCI Express も互換性維持のためにPCIの仕様に準じている部分があるためです。PCI(Peripheral Component Interconnect)はIntelによって開発されたデバイスを接続するバス仕様です。バスとはCPUとデバイスとの間でデータをやり取りするための信号線などの物理的規格やそのソフトウエア仕様です。PCIはPCI Expressが登場する前に主流となっていたバス仕様です。


歴史
1992年

PCI Local Bus Specification Revision 1.0が策定される。


2002年
PCI Express Base Specification Revision 1.0がリリースされる。

2004年
PCI Local Bus Specification Revision 3.0(PCIの最終版)が登場。
PCI Express (Gen1)ネイティブグラフィックスカード登場

Intel 925X / 915P / 915Gチップセット登場 
 ■注目ポイント(PCIeを初めて実装)
(MCH  -> PCIe Gen1 x16 
(DMI PCIe Gen1 x4
(IOH -> PCIe Gen1 x1 が4port PCI が6port
(HD Audioをサポート



2005年

PCI Firmware Specification 3.0もリリース

PCI ExpressがGPU用インターフェースの主流となる


2006年

PCI Express Base Specification Revision 2.0リリース

Gigabit EthernetコントローラーやRAIDコントローラー、SATAコントローラーなど、対応する製品も増加


2008年

Intel P45 チップセット

(MCHが内蔵するPCI ExpressコントローラーがGen2対応になった

MCH  -> PCIe Gen2 x16 

DMI PCIe Gen1 x4   (2.5GT/s x4)

IOH -> PCIe Gen1 x1 が6port


2009年

Lynnfield / 1th Core

CPU--> PCIe Gen2 x16 (これ以降、PCIEコントローラ(Root Complex)をCPUに内蔵、従来はMCH)
DMI 1.0 (PCIe Gen1 x 4)
PCH(P55)--> PCIe Gen1*注1が6本
このRoot Complexは、サイズがほとんどCPUのダイひとつ分以上ある
※注1 PCH側はスペック表記上、PCIe Gen2となっているが実態はGen1の転送速度になります。


2010年

PCI Express Base Specification Revision 3.0リリース

Clarkdale / 1th Core
CPU--> PCIe Gen2 x16 ■注目ポイント(パッケージレベルでのGPUコアの統合
DMI 1.0 (PCIe Gen1 x 4)
PCH(H57/H55)--> PCIe Gen1*注1が6本
※注1 PCH側はスペック表記上、PCIe Gen2となっているが実態はGen1の転送速度になります。


2011年


Sandy Bridge / 2th Core
CPU--> PCIe Gen2 x16■注目ポイント(ダイレベルでのGPUコアの統合
DMI 2.0 (PCIe Gen2 x 4)  ■注目ポイント(DMI が2.0になる
PCH(Z67 P67)--> PCIe Gen2が8本  ■注目ポイント(PCHのPCIe がGEN2になる


2012年

Ivy Bridge / 3th Core
CPU--> PCIe Gen3 x16  ■注目ポイント(CPUのPCIe がGEN3になる
DMI 2.0 (PCIe Gen2 x 4)
PCH(Z77) --> PCIe Gen2が8本 (これ以降、USB 3.0コントローラをPCHに内蔵)


2013年

Haswell / 4th Core
CPU--> PCIe Gen3 x16
DMI 2.0 (PCIe Gen2 x 4)
PCH(Z87) --> PCIe Gen2が8本(これ以降、I/Oポート・フレキシビリティー機能をPCHに内蔵)


2014年

Haswell Refresh / 4th Core
CPU--> PCIe Gen3 x16
DMI 2.0 (PCIe Gen2 x 4)
PCH(Z97) --> PCIe Gen2が8本


2015年


Skylake / 6th Core
CPU--> PCIe Gen3 x16
DMI 3.0 (PCIe Gen3 x 4)  ■注目ポイント(DMI が3.0になる
PCH(Z170)  --> PCIe Gen3が20本  ■注目ポイント(PCHのPCIe がGEN3になりレーン数も増加


2017年


Kaby Lake / 7th Core
CPU--> PCIe Gen3 x16
DMI 3.0 (PCIe Gen3 x 4)  
PCH(Z270)  --> PCIe Gen3が24本  ■注目ポイント(PCHのレーン数が増加、しかし、DMI帯域は変わらず





PCI Expressとは

PCIでは複数のデバイスが同時に通信できない。
転送速度も理論値で133MB/秒程度。

そこで、PCI Expressの登場となる。


主な特徴
Point to Pointで全二重通信
大本のコントローラー(Root Complex)と各デバイスが、すべて独立した配線で接続
これでも不足する場合はスイッチ(ブリッジ)を介してデバイスを接続


レーン
受信と送信をまとめた1組をを1レーン(x1)と呼ぶ。
1レーン(x1)、4レーン(x4)、8レーン(x8)、16レーン(x16)などがある。


PCIeスロット(拡張カードがささる側コネクタ)


拡張カード(スロットにさす方)


グラフィックス用の16レーンスロットは、グラフィックスカード専用というわけではなく、汎用の広帯域スロットとして利用することが可能。スロットよりレーン数の少ない拡張カードを挿入することができる。



スピード

リビジョンで転送スピードが異なる。PCI Express Base Specification Revision 3.0を略してPCIe Gen3とする。

実効データ転送速度(1レーン・片方向)

Gen1 250MB/s
Gen2 500MB/s
Gen3 1GB/s (物理層帯域 8Gbps)

Gen3デバイスは、8GT/秒対応の物理層と2.5、5GT/秒対応の物理層の両方を内蔵し、実際の通信に応じて切り替えている。


セグメントとは
言うなればひとつのバスの管理単位である。

PCI-Xに限らず、PCIやAGPですらも、セグメントを使って大規模システムを構築できる。

出典

ロードマップでわかる!当世プロセッサー事情 ― 第109回

バスの歴史を振り返る PCIからAGP、PCI-X編

2011年07月11日 12時00分更新 大原雄介

http://ascii.jp/elem/000/000/618/618492/index-4.html#eid618499




PCI/PCI Express ソフトウェア
ソフトウエアとしては、PCIもPCIeも同じ。しかし、PCIeの拡張機能を使う場合は拡張コンフィグレーションレジスタを操作する。
Windows Vista 以降でネイティブにPCIeをサポートしている。

Transaction Layerより上→ソフトウェア(PCI互換のインタフェース)
Datalink Layerより下→ハードウェア(PCI互換なし)


PCI/PCIe コンフィギュレーション
デバイス側がコンフィギュレーションレジスタを実装する。ソフトウェアはこれにアクセスし、デバイスを操作する。そのレジスタ内のBAR(Base Address Register)にアドレスを設定することで、そのデバイス固有のメモリアドレスやI/Oアドレスが決まる。そのコンフィギュレーションレジスタを読み書きするためにコンフィグレーション・トランザクションを使う。

コンフィギュレーションレジスタには以下の要素を含む。デバイスがPCI-to PCI Bridge(TYPE 1)か通常デバイス(TYPE 0)で要素が異なる部分もある。PCI/PCIe共通のレジスタは000h - 0FEhまで、PCIe拡張は0FFf - FFFhまで。
Vender ID / Device ID
コマンド/ステータス
デバイスが使用するメモリマップドI/OやI/Oのアドレスを設定・保持する(BAR)
割り込み設定
デバイス固有
など

BAR(Base Address Register):必要バイト数はリードオンリーの0のビットを植える。最低値は16バイト 0x0000 


PC/AT互換機PCでPCI/PCIe コンフィギュレーションを担うのはBIOSです。その流れをIntel Haswellプラットフォームで簡単に説明します。
まず、BIOSがチップセット(ホストブリッジ)を初期化し、バス内を検索しバス番号等が決まる。バス番号はアルゴリスムで決まる。デバイス番号はブリッジへの配線で決まる。機能番号はデバイスの設計で決まる。CPU I/Oポートの0xCF8(固定)と0xCFC(固定)を使ってPCIデバイスのコンフィギュレーション空間にアクセスし、PCI互換レジスタを設定する(この方法はチップセット実装に依存する)。チップセット(ホストブリッジ)のPCIEXBARレジスタにコンフィグレーションレジスタをマッピングするメモリアドレス等を設定する。これにより、次のメモリ・マップト・コンフィグレーション・アクセスが可能になる。PCIeではコンフィギュレーションレジスタにアクセスするためにメモリ・マップト・コンフィグレーション・アクセス、英語表記ではMemory Mapped Configuration Access (MMCFG,MMCONFIG)を使う。チップセット、BIOS、OSが連携して実現。チップセットに該当機能の実装が必要。そのデバイスのバス番号、デバイス番号、機能番号でマッピングされたメモリアドレスにアクセスすると、コンフィグレーションレジスタを読み書きできる。
マッピングは以下の法則でなされる。
バス番号255-デバイス番号31ー機能番号7-レジスタ(0h~FFFh)
バス番号0-デバイス番号0ー機能番号0-レジスタ(0h~FFFh)
ベースアドレスーーー
このように256MBの領域を要しますが実際のIntel Z87チップセットでは64MBの実装でした。しかし、この分が実質メモリーホールになるようです。

PCIEXBARレジスタに設定されたメモリアドレス等をOS等に引き継ぐために、ACPIテーブル:MCFGにそれらを書き込む。

ACPI _OSCメソッド機能も使用。
システムやチップセットの機能に依存する可能性がある。
PCIEXBARレジスタもコンフィグレーションレジスタの1つであるが、PCI標準で定められていないデバイス独自実装レジスタである。また、そのオフセット・アドレスもチップセット毎で異なるようです。
詳細は
PCI-to-PCI Bridge Architecture Specification Revision 1.2 ,
PCI Firmware Specification 3.0



PCI Expasion ROM(Option ROM)
PCI/PCI ExpressデバイスはPCI Expasion ROM(Option ROM)をもつことができる。UEFI BIOSが主流になってきた2017年でもグラフィックボードにはこのPCI Expasion ROM(Option ROM)が必須となっています。その理由はこちらの記事~グラフィックボード・ビデオカードのビデオBIOSとGOPドライバについてを参照ください。また、PCI Expasion ROM(Option ROM)の記事についてはこちらhttp://dxr165.blog.fc2.com/blog-entry-369.htmlを参照ください。



バスマスタ(bus master)


下記サイトでDMAの基礎を予習しました。
マイナビ パソコン
コラム セカンド・オピニオン
54 バスのアーキテクチャ - 過去から未来へ(15) ○シェアードバスのアーキテクチャ(3)から(5)
大原雄介 [2003/11/27]
http://news.mynavi.jp/column/sopinion/054/






引用始まり
 バスの制御を行なうデバイス。広義では、CPUやマザーボード上のDMAC(Direct Memory Access Controller)も制御権を持つデバイスになるが、一般には、DMACに相当する機能を持ち、CPUを介さずに直接データ転送が行なえるタイプのI/Oデバイスを指す。

 もっともオーソドックスなデータの入出力方法は、CPUが直接デバイスのリード/ライトを行なうスタイルで、これをPIO(Programmed Input/Output)転送という。ISAバスには、CPUとは無関係に、デバイス~メモリ間で直接データ転送が行なえるDMAという仕組みが用意されており、これを使うスタイルをDMA転送と呼んでいる。DMA転送は、CPUを転送処理から開放し負荷を軽減する機構なのだが、システムの設計が古く転送速度が大幅に低下してしまうため、高速性を要求するISAデバイスの多くはPIOか、マザーボード上のDMACに代って、拡張カード上のコントローラが処理するスタイルのバスマスタ方式を採用している(※1)。

 PCIバスの場合には、共通のDMACを使うという概念は無く、アービタ(arbiter)がバスの使用権を調停し(arbitration)、各マスタデバイスに使用権を与えるスタイルになっており、入出力はPIOかバスマスタ転送になる。

(※1) ISA(Industry Standard Architecture)バスにはアービトレーション機能が無いため、DMA転送に見せかけた変則的なスタイルのバスマスタ転送だが、MCA(Micro Channel Architecture)、EISA(Extended Industry Standard Architecture)、VL-Bus(VESA Local-Bus)、PCI(Peripheral Component Interconnect)などはみな、アービトレーション機能が備わっている。
引用終わり
出典
PC Watch ■鈴木直美の「PC Watch先週のキーワード」 ■
第58回【'98/11/30~12/11】
http://pc.watch.impress.co.jp/docs/article/981217/key58.htm


引用始まり
 Windows XPでは、IDEデバイスのDMA転送を極力有効にするために、ハードウェア側の問題によりDMA転送に失敗する可能性がある場合、または実際に転送に失敗した場合の対策が追加されている。逆に問題がなければ、自動的にDMA転送が有効の状態でセットアップされる。
引用終わり
 ITmedia Windows XPの正体 大幅に改善されたWindows XPのIDEサポート 澤谷琢磨 2001/09/22
http://www.atmarkit.co.jp/fpc/xp_feature/idesupport/idesupport.html







備考
UEFI BIOSはPCI/PCIe デバイスに対しINTx ,MSI,MSI-X割り込みを使用せず、ポーリングで対応している。

SerDesはSERializer/DESerializerの略です。

ACPI SMBIOS Table Viewer
FirmwareTablesView v1.01 
http://www.nirsoft.net/utils/firmware_tables_view.html



Intel  PCI Express Enhanced Configuration Mechanism

Intel 945G/945GZ/945GC/945P/945PL Express Chipset Family Datasheet June 2008 (2005年発売のデスクトップ向けMCHです。DDR2 ,PCIe Support)

3 Register Description
3.3 Configuration Mechanisms 
3.3.1 Standard PCI Configuration Mechanism より抜粋

The PCI specification defines two bus cycles to access the PCI configuration space: 
Configuration Read and Configuration Write. Memory and I/O spaces are supported directly by the processor.
Configuration space is supported by a mapping mechanism implemented within the (G)MCH.
The configuration access mechanism uses the CONFIG_ADDRESS register (at I/O address 0CF8h though 0CFBh) and CONFIG_DATA register (at I/O address 0CFCh though 0CFFh)
To reference a configuration register, a DWord I/O write cycle is used to place a value into CONFIG_ADDRESS that specifies the PCI bus, the device on that bus, the function within the device, and a specific configuration register of the device function being accessed.
CONFIG_ADDRESS[31] must be 1 to enable a configuration cycle. 
CONFIG_DATA then becomes a window into the four bytes of configuration space specified by the contents of CONFIG_ADDRESS. 
Any read or write to CONFIG_DATA will result in the (G)MCH translating the CONFIG_ADDRESS into the appropriate configuration cycle.


3.3.2 PCI Express* Enhanced Configuration Mechanism (Intel®82945G/82945GC/82945P/82945PL (G)MCH Only) より抜粋

As with PCI devices, each PCI Express device is selected based on decoded address information that is provided as a part of the address portion of configuration request packets. A PCI Express device will decode all address information fields (bus, device, function, and extended address numbers) to provide access to the correct register.To access this space (steps 1, 2, and 3 are completed only once by BIOS):

1. use the PCI compatible configuration mechanism to enable the PCI Express enhanced configuration mechanism by writing 1 to bit 0 of the PCIEXBAR register.

2. use the PCI compatible configuration mechanism to write an appropriate PCI Express base address into the PCIEXBAR register .

3. calculate the host address of the register you wish to set using (PCI Express base + (bus number * 1 MB) + (device number * 32 KB) + (function number * 4 KB) + (1 B * offset within the function) = host address).

4. use a memory write or memory read cycle to the calculated host address to write or read that register. 




主な参考文献/URL

PCI Express 設計の基礎と応用
畑山 仁 / 編著 CQ出版 2010年5月15日発行


Interface 増刊  改訂新版 PCIバス&PCI-Xバスの徹底研究
Interface編集部 (編集) CQ出版 2004年7月1日発行


PCI Expressの概要 (Slide) Lattice Semiconductor 2007
http://teledynelecroy.com/japan/pdf/semi/pci-seminar2007-02.pdf


National Instruments / PCI Express - PCI Express 規格の概要 発行日: 1 07, 2008 
http://www.ni.com/white-paper/3767/ja/#toc1


Raphine Project / PCI Express
https://raphine.wordpress.com/kernel/code_reading/driver/pcie/


osdev-jp/osdev-jp.github.io/Wiki/PCI Memo
https://github.com/osdev-jp/osdev-jp.github.io/wiki/PCI-Memo


松谷健史のページ / PCI expressメモ
http://web.sfc.wide.ad.jp/~macchan/wiki/index.php?PCI%20express%E3%83%A1%E3%83%A2


InfoSec Institute / System Address Map Initialization in x86/x64 Architecture
Part 1: PCI-Based Systems by Darmawan Salihun on SEPTEMBER 16, 2013
http://resources.infosecinstitute.com/system-address-map-initialization-in-x86x64-architecture-part-1-pci-based-systems/
BIOSレベルでのPCIコンフィグレーションについて詳細に記述されています。


InfoSec Institute / System Address Map Initialization in x86/x64 Architecture
Part 2: PCI Express-Based Systems by Darmawan Salihun on JANUARY 9, 2014
http://resources.infosecinstitute.com/system-address-map-initialization-x86x64-architecture-part-2-pci-express-based-systems/
BIOSレベルでのPCI Expressコンフィグレーションについて詳細に記述されています。


White Paper A Tour beyond BIOS Memory Map
Design in UEFI BIOS
Jiewen Yao Intel Corporation
Vincent J. Zimmer Intel Corporation
February 2015
https://firmware.intel.com/content/tour-beyond-bios-memory-map-design-uefi-bios
UEFI BIOS環境下でのメモリーマップについて記述されています。


Wikipedia / IOMMU
IOMMU (Input/Output Memory Management Unit、IOMMU) とはDMA可能なI/Oバスと主記憶装置を接続するメモリ管理ユニット (MMU) である。
https://ja.wikipedia.org/wiki/IOMMU


Intel Developer Zone / Development/Tools/Resources
The-Compute-Architecture-of-Intel-Processor-Graphics-Gen9-v1d0.pdf
https://software.intel.com/en-us/file/the-compute-architecture-of-intel-processor-graphics-gen9-v1d0pdf


大原雄介公式サイト/バス・インターフェース関連記事
http://www.yusuke-ohara.com/

マイナビ / パソコン / セカンド・オピニオン
40 バスのアーキテクチャ - 過去から未来へ(1) 
大原雄介 [2003/08/07]
http://news.mynavi.jp/column/sopinion/040/

マイナビ / パソコン / セカンド・オピニオン
97 バスのアーキテクチャ - 過去から未来へ(58) プロトコル(その23):PCI Express(その1)
大原雄介 [2004/12/14]
http://news.mynavi.jp/column/sopinion/097/

PC Watch 短期集中連載】大原雄介の最新インターフェイス動向 ~PCI Express 3.0編その1
(2009年3月10日)  [Reported by 大原雄介]
http://pc.watch.impress.co.jp/docs/2009/0310/interface01.htm



元麻布春男の週刊PCホットライン/ギガビットEthernet専用チャネル「CSA」はPCI Expressの妨げとなるか? 2003年2月20日 元麻布春男
http://pc.watch.impress.co.jp/docs/2003/0220/hot246.htm


@IT > System Insider >[解説] 今後の10年を占う新Pentium 4プラットフォームを考察する
 1.PCI Expressをサポートした初のチップセット
 2.新チップセットで強化された機能
2004/07/29  元麻布春男
http://www.atmarkit.co.jp/fsys/kaisetsu/042pciexpress/pciexpress01.html
http://www.atmarkit.co.jp/fsys/kaisetsu/042pciexpress/pciexpress02.html


Microsoft Hardware Dev Center 
Docs / Windows Hardware / Windows Drivers / Device and Driver Technologies / PCI
PCI driver programming guide
https://docs.microsoft.com/ja-jp/windows-hardware/drivers/pci/


WinHEC 2006 Presentations / System Fundamentals - Core Platform Architecture and Security
PCI Express in Depth for Windows Vista and Beyond [PowerPoint ; 324 KB]
https://www.microsoft.com/whdc/winhec/pres06.mspx


OS Wiki/hardwares/PCI
http://oswiki.osask.jp/?PCI


パソコン初心者講座 / 自作パソコン入門 / チップセット
http://www.pc-master.jp/jisaku/chipset.html


X-Bus
Support
Logic
 82371AB PCI-TO-ISA / IDE
XCELERATOR (PIIX4) 
https://www.intel.com/Assets/PDF/datasheet/290562.pdf



In the PC/XT four different address buses can be distinguished:
X-address bus
Part 3
Personal Computer Architectures and
Bus Systems
http://www.fi.tartu.ee/loengumaterjalid/stud/arvutikomponendid/ISA.pdf


category: PC-HW

tb: 0   cm: 3

PCI/PCIeデバイスドライバ  


PCI/PCIeデバイスドライバ
デバイス操作に特化した命令セットの集合


以下、メモ置きです。

実装方法や上層のソフトウエアとのインターフェイスを仕様として規定されている。


スタック レイヤー構造




BIOS(UEFI BIOS)はマザーボードにオンボードのPCIeデバイスは既知なので、起動に必要なUSBやSATA,のコード(ドライバ)をシステムBIOSに持っている。
OSはベンダーIDとデバイスIDでドライバを特定する。USB,ATAはインボックスドライバが適用される。


category: PC-HW

tb: 0   cm: 0

PCI Expasion ROM(Option ROM)  

PCI Expasion ROM(Option ROM)

PCI/PCI ExpressデバイスはPCI Expasion ROM(Option ROM)をもつことができる。


以下、メモ置きです。

PCI Local Bus Specification 2.2 1998 (For Legacy BIOS)
6.3. PCI Expansion ROMs
6.3.3. PC-compatible Expansion ROMs

entry point INIT function

6.3.3.1.1. POST Code Extensions

C0000h-DFFFFh

VGA device C0000h

6.3.3.1.2. INIT Function Extensions


PCI Firmware Specification 3.0(For Legacy BIOS & EFI)
3. EFI PCI SERVICES
3.2. PCI-X Mode 2 and PCI Express

The PCI-X Mode 2 and PCI Express provide a software programming model that is software compatible with the Conventional PCI.
EFI PCI I/O Protocol supports up to 4 GB of configuration space; therefore, it covers the PCI-X Mode 2 and PCI Express Extended Configuration space of 4 KB in size.
EFI uses a single timer interrupt in pre-boot, EFI device drivers are polled so INTx, MSI, or MSI-X is not used by EFI.
To identify a function (e.g., Conventional PCI, PCI-X vs. PCI Express), the EFI driver uses Device ID, Vendor ID, and Capability Pointer in the compatibility configuration space.


5. PCI Expation ROMs

PCI Expansion ROM Header Format
Offset Length Description
0x00 1 0x55 ROM Signature, byte 1
0x01 1 0xAA ROM Signature, byte 2
0x02 16h XX Reserved (Processor architecture unique data)
0x18 2 XX Pointer to PCI Data Structure

PCI Data Structure Format
Offset Length Description
0x00 4 "PCIR"
0x04 2 Vender ID
0x06 2 Device ID
0x08 2 Device List Pointer
0x0A 2 PCI Data Structure Length
0x0C 1 PCI Data Structure Revision
0x0D 3 Class Code
0x10 2 Image Length
0x12 2 Revision Level of the Vender's ROM
0x14 1 Code Type
0x15 1 Last Image Indicator
0x16 2 Maximum Run-time Image Length
0x18 2 Pointer to Configuration Utility Code Header
0x1A 2 Pointer to DMTF CLP Entry Point

PCI Data Structure Revision
0x03 PCI Firmware Specification 3.0

Code Type Description
0x00 IA-32, PC-AT compatible
0x01 Open Firmware standard for PCI
0x02 Hewlett-Packard PA RISC
0x03 EFI Image
0x04-0xFF Reserved


UEFI Platform Initialization Specification Version 1.4 VOLUME 5   Standards
11 PCI Platform
11.6.1 PCI Platform Protocol
EFI_PCI_PLATFORM_PROTOCOL.GetPciRom()

Description
The GetPciRom() function gets the PCI device's option ROM from a platform-specific location.The option ROM will be loaded into memory. This member function is used to return an image that is packaged as a PCI 2.2 option ROM. The image may contain both legacy and UEFI option ROMs. See the UEFI 2.1 Specification for details. 


UEFI Specification 2.4 13 Protocols - PCI Bus Support
13.4 EFI PCI I/O Protocol
13.4.2 PCI Option ROMs

EFI takes advantage of both the PCI Firmware Specification and the PE/COFF Specification 
to store EFI images in a PCI Option ROM. 

Rules
• A PCI Option ROM may contain one or more images.
• Each image must being on a 512-byte boundary.
• Legacy Option ROM images begin with a Standard PCI Expansion ROM Header (Table 114).
• EFI Option ROM images begin with an EFI PCI Expansion ROM Header (Table 118).
• Each image must contain a PCIR data structure in the first 64 KiB of the image.
• The image data for an EFI Option ROM image must be a PE/COFF image or a compressed PE/COFF image following the UEFI Compression Algorithm.
• The PCIR data structure must begin on a 4-byte boundary.
• If the PCI Option ROM contains a Legacy Option ROM image, it must be the first image.
• The images are placed in the PCI Option ROM in order from highest to lowest priority. This priority is used to build the ordered list of Driver Image Handles that are produced by the Bus Specific Driver Override Protocol for a PCI Controller.

Table 116. EFI PCI Expansion ROM Header
Offset Byte Length Value Description
0x00 1 0x55 ROM Signature, byte 1
0x01 1 0xAA ROM Signature, byte 2
0x02 2 XXXX Initialization Size – size of this image in units of 512 bytes. 
0x04 4 0x0EF1 Signature from EFI image header
0x08 2 XX Subsystem value for EFI image header
0x0a 2 XX Machine type from EFI image header
0x0c 2 XX Compression type 0x0001 - The image is compressed.
0x0e 8 0x00 Reserved
0x16 2 XX Offset to EFI Image
0x18 2 XX Offset to PCIR Data Structure

以上、メモ置きです。


category: PC-HW

tb: 0   cm: 0

メモリーマップドI/O  

メモリーマップドI/Oとは、メモリー空間の一部にI/Oデバイスにアクセスするための領域を割り当てる方式。MOVE命令。

 x86アーキテクチャーではI/Oアドレス空間マッピング方式もある。この場合はI/O命令を使う。I/O命令では高速なデータ転送ができないため、メモリーマップドI/Oが多く使われるようです。



category: PC-HW

tb: 0   cm: 0

チップセットのLPCとは  

チップセットでのISAバス廃止にともにない策定された。
LPCは7本(+オプション6本)で、機能や帯域はほぼISAと同等のものを提供、Super I/Oチップがつながる。

Super I/O
かつてISAバス接続の拡張カードとして提供されてきたシリアルポート(RS232C)、パラレルポート(プリンタポート)、PS/2ポート、FDなどの機能を統合。




category: PC-HW

tb: 0   cm: 0

Windows API GetFirmwareEnvironmentVariableでUEFI BootOrder変数にアクセス  

UEFI BootOrder変数はUEFI Shell コマンドのDmpstore やBCFGで参照・メンテが可能ですが、ブートしなおして、USBメモリ挿して等操作が少々面倒です。Windows からアクセスする方法は以下があります。

BCDEdit 
標準コマンドですが、BCDがからんで使いずらい。また、その情報も抽象化され不十分。

EASYUEFI
GUIツールです。機能限定でフリーで使えますが、仕様が不明。

そこで、ネットを探索していると以下の記事がありました。
powershellからNVRAMよむやつ
yomi322.hateblo.jp/entry/2016/05/01/205936

Windows API(GetFirmwareEnvironmentVariable)とPowerShellでアクセスできるようです。

実際にやってみました。
実証環境 
ASUS H270-PLUS BIOS Ver 0311 UEFI Spec Ver 2.50
Intel Celeron G3900 
Win 10 Home 64bit Ver 1607(Redstone 1)


手順
・まず、PowerShell ISEを管理者権限で使えるようにする。
Win 7以降では標準で入ってる。

・コマンドが実行できるように以下を実行
Set-ExecutionPolicy RemoteSigned(実行ポリシーの変更?→はい)

・スクリプトをコピペし、ファイルに保存し実行する。


すると

実行結果↓
PS C:\windows\system32> C:\Users\XXX\Documents\bootorder.ps1
00 00 01 00 
BootOrderのダンプが吐き出さられる。

UEFIの仕様ではBootOrdeは2バイト整数の配列となっています。
また、バイトオーダーはx64マシンなのでリトルエンディアンになります。
なので、2番目の01 00は00 01の並びになります。
解析すると
BootOrder Priority
1番目はBoot0000
2番目はBoot0001
となります。


コード解説
AdjustPrivileges()関数は
アクセス権等をチェックしている模様。管理者権限であれば通過する。

BootOrder()関数は
これが肝心の本体です。ここをいじくればよいようです。
GetFirmwareEnvironmentVariableでBootOrderを読み込みバッファにためます。バッファサイズは0x100で決め打ち。
GUIDはUEFI Global VariableのGUIDをセット


応用ーBootOption####を読んでみる!


BootOption####を読むには、すでに####が判明しているので簡単です。BootOption####はEFI_LOAD_OPTION descriptorを含みます。読めますが、しかし、その構造はちょっと難しい作りです。

EFI_LOAD_OPTION descriptor
typedef struct _EFI_LOAD_OPTION {
UINT32 Attributes ;
UINT16 FilePathListLength;
CHAR16 Description[];
EFI_DEVICE_PATH_PROTOCOL FilePathList[];
UINT8 OptionalData[];
} EFI_LOAD_OPTION;
(出典:UEFI Specification 2.5 / 3 Boot Manager 3.1.3 Load Options)

FilePathList[]のバイト長がFilePathListLengthにセットされています。

今日はここまでで力尽きました。続きはのちほど。

2017/02/17 やっと更新できます。

それでは、WIndows 10を起動するBootOption0000を実際に読んでみます。
上記の構造の解説ですが、まず基本のところから。
DescriptionはこのBootOptionの名前です。 Windows Boot Managerがセットされていました。
FilePathListは不定繰返し配列のようです。そのパスの表現はEFI_DEVICE_PATH_PROTOCOLで定められています。そのバイト長はFilePathListLengthに格納されています。
OptionalDataにセットされたデータは起動するアプリケーション(例 Windows Boot Manager)に渡されるようです。このOptionalDataについては詳細はよくわかりません。
Attributesは基本的にLOAD_OPTION_ACTIVE 0x00000001がセットされているようです。


EFI_DEVICE_PATH_PROTOCOL
いろいろ細かい仕様があるようですが、ブートローダー起動用Pathは以下の3つでよいようです。

1.Hard Drive Media Device Path
Type 4 – Media Device Path 0x04
Sub-Type 1 – Hard Drive 0x01
Length  0x2A 0x00 (LE)固定
Partition Number 
Partition Start
Partition Size 
Partition Signature ここに該当パーティションのUniquePartitionGUIDがはいっています。
Partition Format  – GUID Partition Table 0x02
Signature Type  – GUID signature 0x02
(出典:UEFI 2.5 / 9 Protocols - Device Path Protocol 9.3.6 Media Device Path)

ポイント! このUniquePartitionGUIDにより複数のパーティションがある場合でも、該当デバイスを特定できる。

UniquePartitionGUIDとは
GUID Partition Table (GPT) DiskのPartition TableはGPT HeaderとGPT Partition Entry Arrayで構成される。
GPT Partition Entry Arrayは
PartitionTypeGUID ESPはxxxといった決まりがある。
UniquePartitionGUID パーティションを作成したときにUEFI GUIDを生成し格納
StartingLBA
EndingLBA
Attributes
PartitionName
で構成される。
(出典:UEFI 2.5 / 5 GUID Partition Table (GPT) Disk Layout 5.3.3 GPT Partition Entry Array)

UEFIのGUID(Globally Unique Identifiers)はRFC 4122のタイムスタンプとMACアドレスを使うタイプの仕様を使うようです。 注意{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}緑の部分のバイトオーダーはリトルエンディアンです。
(出典:UEFI 2.5 / Appendix A GUID and Time Formats)


2.File Path Media Device Path
Type 4 – Media Device Path 0x04
Sub-Type 4 – File Path 0x04
Length 
Path Name ここに起動するブートローダーのパスが入る。
今回は\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI が入っていました。
(出典:UEFI 2.5 / 9 Protocols - Device Path Protocol 9.3.6 Media Device Path)


3.Device Path End Structure
Type 0x7F –  End of Hardware Device Path
Sub-Type 0xFF – End Entire Device Path
Length 
(出典:UEFI 2.5 / 9 Protocols - Device Path Protocol 9.3.1 Generic Device Path Structures)

以上、BootOptionの保持する情報をおぼろげながら知ることができました。GPTパーティションの効用はシステムドライブに2Tバイト以上のディスクを使えること以上に、OSブート時にシステムドライブをUniquePartitionGUIDにより簡易に識別できることにあるようです。これを知ることができたの今回の収穫です。


参考URL
日経Linux Linuxキーワード UUID
http://itpro.nikkeibp.co.jp/article/Keyword/20090206/324330/
GUIDの簡単な仕組みとディスクの識別にUUIDを使うメリットなどが解説されている。


category: PC-HW

tb: 0   cm: 0

Boot Option(NVRAMブート変数)とBCD内エントリーの不整合  

Windows 8-10 、または、Windows 8-10 とLinuxのマルチブートを使用している場合、Boot Option に重複してWindows Boot Managerエントリーが登録されたり、Linux系のブートエントリー(例 Ubuntu )の残骸なのどが残るなど、Boot Option(NVRAMブート変数)とBCD内エントリーの不整合が生じることがります。その理由についてはこちらをご覧ください。
さて、その解消策ですが、マイクロソフトの下記URLに記載されています。
https://technet.microsoft.com/ja-jp/library/cc749510(v=ws.10).aspx
しかし、少しとっつきにくいようです。

そこで、自分なりに手順をまとめてみました。

・Bcdedit /export savebcd
BCDのバックアップをとる。
バックアップBCDファイルがカレントディレクトリに作成される。

・Copy savebcd newbcd
修正用BCDをシステムBCD(現在使用中の)からコピーし作成する。

・Bcdedit /store newbcd /delete ID
修正用BCDのファームウエアエントリーの重複するもの、不要なものを削除する。これで、まず、BCD内のエントリーをきれいにする。
削除対象のファームウエアエントリーIDはあらかじめ調べておく。

・Bcdedit /import newbcd /clean
修正用BCDをシステムBCD(元のBCD)に戻し、すべてのBoot Option(NVRAMブート変数)を削除する。

・BCDedit /enum /firmware
BCDのファームウエアエントリーよりBoot Option(NVRAMブート変数)がゼロから生成され、同期がとれる。

もしものときは、バックアップsavebcdからインポートすればいよい。




category: PC-HW

tb: 0   cm: 0

BIOSについて  

PCにUEFI BIOSが搭載されるようになり今年、2017年で5年経とうとしています。UEFI BIOSもかなり一般的になってきました。現役PCのBIOSも従来のBIOS(Legacy BIOS)は少なくなったように思います。今後は、BIOSといえばUEFI仕様であることが普通になり、その呼称もBIOSに戻るような気がします。また、その方が、話が通じやすく、いいように思います。


category: PC-HW

tb: 0   cm: 0

ASUS マザーボード BIOS設定項目のメモ  

PRIME H270-PLUS BIOS Ver 0609 
> Advanced > SA Configuration > Memory Configuration > Memory Remap [Enabled/Disabled]
チップセットにメモリ4GB以上をアクセスさせるか否かを設定するようです。現状Win 10 64bit OS & 物理メモリ4GB以上当たり前のご時世ではEnabeledの設定でOKです。この設定は、上位機種の場合省略されている。

2017/05/21追記
メモリーリマッピング
http://www.geocities.jp/hpt_user99/MemoryReclaiming.html
の記事にあるとおり、このMemory Remapはメモリアドレスの4GB以下のアドレスにあるメモリホール(メモリマップドI/Oなど)が原因でCPU(OS)がアクセスできない領域の物理メモリアドレスを搭載メモリ量より上のアドレスにRemappingすることで、メモリホール分の物理メモリ領域を取り戻す機能のようです。これをIntel はMemory Reclaimと呼んでいるようです。このMemory Remapの機能を活かすには当然、64bitOSが必要になります。

2017/05/27追記
こちらのサイトに本家本元Intelがメモリーホール問題の対応について記述したドキュメントがありました。
Polywell Computers / Support / FAQ
Not All Memory is Available after Installing 4GB or More of System Memory
... Full White Paper available HERE
http://www.polywell.com/us/support/faq/4gb_rev1.pdf
Intel Chipset 4 GB System Memory Support White Paper
February 2005



参考URL
テックウィンド HOME>ASUS>メモリーに関するトラブルシューティング
http://www.tekwind.co.jp/faq/ASU/entry_29.php



> Advanced > SA Configuration > Above 4G Decoding [Enabled/Disabled]
システムが64bitに対応しているとき、この設定を有効にすると、BIOSはPCI/PCIデバイスで使用するメモリ空間を4GB以上の実メモリアドレスの上にマッピングするようです。なぜか、この設定はZ系チップセットのBIOSではBootメニューに表示されています。例:PRIME Z270-A > Boot > Above 4G Decoding [Enabled/Disabled]

出典
PRIME_Z270-A_AR_BIOS Manual(English)



Intel AMTとは

「vPro」 向けの技術の1つ。
AMTはActive Management Technologyの略。
主に企業向けの機能。
CPUが動いてなくても、他PCからリモート操作や電源操作などが可能。
CPUとは別の組み込みプロセッサ(ME: Management Engine)が必要。


category: PC-HW

tb: 0   cm: 0

PCIe 理論上の最大帯域幅  

PCIe 片方向1レーン理論上の最大帯域幅(2016/10/30現在)

PCI  ->  133MB/s  (参考)

Gen1 -> 250MB/s  /物理層 2.5 GT/s エンコード 8b/10b

Gen2 -> 500MB/s  /物理層 5.0 GT/s エンコード 8b/10b

Gen3 -> 1GB/s      /物理層 8.0 GT/s エンコード 128b/130b


category: PC-HW

tb: 0   cm: 0

グラフィックボード・ビデオカードのビデオBIOSとGOPドライバについて  

マザーボードのBIOSがUEFI BIOSに切り替わって以降、UEFI BIOS搭載マザーボードにグラフィックボード・ビデオカード(以降グラフィックボード)を取り付け、システムをレガシBIOS互換機能を使用せずUEFI仕様でブートする際には、グラフィックボードのPCI Option ROMに従来のビデオBIOSに加え、さらに、UEFI仕様のビデオドライバが搭載されていることが必要となりました。そのビデオドライバはGOP(Graphic Output Protocol)ドライバと呼ばれているようです。CPU内臓GPUも上記の仕様に従います。

マザーボード上にあるシステムBIOS(レガシ、UEFIともに)は、ビデオに関するコード(命令セット)を持っていません。通常マザーボードにビデオ機能は実装されておらず当たり前といえば当たり前ですが…。システムBIOSはシステム初期化時にグラフィックボードのPCI Option ROM からそのコードをメモリに吸い上げたのちにCPUで実行し、ビデオ機能を得ることができます。これにより、マザーボードにどんなグラフィックボードが装着されていても、私たちはOSが起動する前にPOST情報やメーカのロゴマークなどをディスプレイから見ることができるのです。

グラフィックボードはソフトウエアから見ればPCI互換デバイスです。PCIデバイスはPCI Option ROMを追加することでソフトウエアを実装することができます。これはPCI の仕様により定義されています。このPCI Option ROMにそれぞれのグラフィックボードに対応したコード(命令セット)をグラフィックスカードベンダーが格納します。


マザーボードがレガシBIOSの場合はPCI Option ROMよりビデオBIOS(このビデオBIOSによりソフトウエアは共通のBIOS システムコールを提供してもらえる)が使われます。

マザーボードがUEFI BIOSの場合はPCI Option ROMよりGOPドライバ(UEFI Graphic Output Protocolを提供する。これにより、ソフトウエアはグラフィックスカードの種別によらず共通のUEFI仕様のビデオ関数を使いビデオ機能を得る)が使われます。グラフィックスカードの製品仕様にWin 8 or 10 対応と表記があれば、その製品はGOP対応ドライバをPCI Option ROMに搭載しているようです。また、GPU-ZなどのフリーソフトでそのグラフィックスカードがUEFI対応かどうか確認することができます。



NVDIA GT710のPCI Option ROMを検証してみました。

GPU-ZでPCI Option ROMを吸出し、ROM-PARSERで解析
解析結果
Valid ROM signature found @600h, PCIR offset 190h
PCIR: type 0 (x86 PC-AT), vendor: 10de, device: 128b, class: 030000
PCIR: revision 0, vendor revision: 1

Valid ROM signature found @fc00h, PCIR offset 1ch
PCIR: type 3 (EFI), vendor: 10de, device: 128b, class: 030000
PCIR: revision 3, vendor revision: 0
EFI: Signature Valid, Subsystem: Boot, Machine: X64
Last image

NVDIA GT710はx86 PC-AT (ビデオBIOS)とEFI(GOPドライバ)をの両方を持っていることがわかりました。

参考情報
ツクモ福岡店ブログ/そうだ、グラフィックボードを増設しよう! でも、その前に..
https://blog.tsukumo.co.jp/fukuoka/2015/08/post_116.html



category: PC-HW

tb: 0   cm: 0

Intel HD530 (CPU内臓グラフィック)のVRAMはどこにある?  

Intel HD530 などのCPU内蔵GPUは、VRAMに相当する部分をメインメモリより使用している。


category: PC-HW

tb: 0   cm: 0

PC基礎 メモリー空間  

最終更新日:2018/04/08

メモリー空間は1区画は8ビット(1バイト)毎に番号が振られ、この番号を「メモリアドレス」呼びます。


メモリアドレスは16進数で表す。
最初の1区画のアドレスは0から始まる。
メモリダンプは1区画8ビットなので1区画を16進数2桁で表現します。


例 容量が4バイト(4区画)のメモリがあったとすると......

1区画目のメモリアドレスは0000_0000hとなる。
2区画目のメモリアドレスは0000_0001hとなる。
3区画目のメモリアドレスは0000_0002hとなる。
4区画目のメモリアドレスは0000_0003hとなる。
最終メモリアドレスはメモリ容量(バイト)-1となります。


16進数に慣れる
A→10
B→11
C→12
D→13
E→14
F→15

FF->255

16進数のFは10進数での9と思うとわかりやすい。Fの意味合いは「あと1を足すと桁が繰り上がる」と捉える。バーゲンセールでは¥9,999円とよく9の数字が並びますが、コンピュータの世界ではこのFが至るところで出没します。




64bit アドレッシングの場合は
16進数(4bit)表現で16桁(64÷4=16)となる。
例 FFFF_FFFF_FFFF_FFFF メチャ桁数が多くなるよね~!


備考
1 KByte = 1024 Byte
1 MByte = 1024 KByte  = 1048576 Byte
1 GByte = 1024 MByte = 1073741824 Byte


0000_00FF = 256Byte目の位置を指す

0000_0FFF = 4KB目の位置
0000_FFFF = 64KB目の位置
000F_FFFF = 1MBの位置(bitでは20桁)
00FF_FFFF = 16M Bの位置
0FFF_FFFF = 256MBの位置
3FFF_FFFF = 1GBの位置
7FFF_FFFF = 2GBの位置
BFFF_FFFF = 3GBの位置
FFFF_FFFF = 4GBの位置



n bit CPU addresssable space 

8 bit -> 256 B. 0x FF.
16 bit -> 64 KB. 0xFFFF.
x86 Real Mode -> 1 MB.  0xFFFFF.
32 bit -> 4 GB. 0xFFFF_FFFF.


メモリの幅(割り当て単位)
4KB(4096 Byte)  単位で割り当てることが多い。
4KB が 256個で1MBになる。




参考文献・URL
Cプログラミング入門以前  – 2006/6/1 村山 公保  (著) 毎日コミュニケーションズ



日経BPnet / ITpro / コンピュータの基礎の基礎 Part1 メモリー空間とは何か
http://itpro.nikkeibp.co.jp/article/lecture/20070824/280260/?rt=nocnt


category: PC-HW

tb: 0   cm: 0

x86 CPU基礎知識  

Intel 80386(i386)には32bit幅の汎用レジスタが8個ある。


category: PC-HW

tb: 0   cm: 0

x86 Intel CPU 系図  

代表的なCPUのみ

1978年 8086  → x86アーキテクチャーでの最初のCPUで16bit

1985年 80386(i386)  →x86アーキテクチャー 最初の32ビットCPU(IA-32)

2004年 第3世代Pentium4 →x86アーキテクチャー 最初の64ビットCPU(EM64T)



IA-32 : Intel Architecture 32bit
EM64T : Extended Memory 64 Technology

X64(x86-64)とは
AMD64,EMT64Tの互換64bit命令セットアーキテクチャーをさす。




    

category: PC-HW

tb: 0   cm: 0

BIOS  

BIOSとはPCのファームウエアです。PC/AT互換機PCで使われています。

主な役割は
1.ハードウェアのチェック・初期化
2.OSの起動
3.OSへのシステムコール提供
などです。

3のシステムコールはWindows 7-10 のOSでは使われていません。かつて、MS-DOSで使われていました。

現在(2016年7月)ではUEFI仕様のBIOSが主流になりつつあります。BIOSはPC/AT互換機の仕様のようですが、このUEFI仕様はPC/AT互換機だけでなく、Itaniumなど他の種類のCPUにも採用されているようです。


従来のBIOSとUEFI仕様のBIOSとの違い
従来
8086(16 bit) リアルモードで動作する。→使用可能なアドレス空間は1MB
OS起動→MBR
パーティション管理→MBR(最大容量は約2.2TBまで)

UEFI仕様
32ビット以上のプロセッサ
OS起動→UEFIアプリケーション
パーティション管理→GPT最大容量は約8.5ZBまで)


SMBIOSとは
UEFI仕様策定より前に、PCを管理する目的で策定された。そのPCの製造元やハードウエア構成などの情報を共通の手法で取得できるよう定めたもの。SMBIOSはUEFI環境PCでも使用されており、ハードウエア初期化後に、その情報がUEFIにより生成される模様。


category: PC-HW

tb: 0   cm: 0

PCの基礎知識  

Windows PCは従来PC/AT互換機(日本ではDOS/V)と呼ばれていました。今では、わざわざ、「PC/AT互換機」と言わずともそれが当たり前になっているようです。そのPC/AT互換機は主につぎの規格でできています。

CPU  INTEL x86アーキテクチャー

バス規格 PCI , PCI Express ( PCIe ) 

OSブート  BIOS, UEFI BIOS 

ドライブ系  IDE/ATA/ATAPI,  SATA , NVMe

ディスプレイI/F  D-Sub  DVI , HDMI, 

オーディオ  AC97 ,  HD Audio 

電源管理  APM  -> ACPI 

H/W管理  (PnP)Plug and Play -> ACPI

汎用I/F  シリアルポート、パラレルポート, USB , USB 2.0 , USB 3.0 , USB 3.1 



category: PC-HW

tb: 0   cm: 0

さらば!レガシー!(自分勝手判断で早く無くなってほしいものPC編)  

レガシーBIOS(UEFIでない) -> DOS時代には大変お世話になりました。

MBR -> よく頑張っていただきました。

HDD -> 起動ドライブとしてはもう使えません。

光学ドライブ -> もうブンブン回さなくていいんですよ。




category: PC-HW

tb: 0   cm: 0

ブルーレイディスクでやっちまった  

ノートパソコンのリカバリーディスクの作成のためブルーレイディスクを買いに行き、ドライブにいれたところ、形式が違うなどのエラーが出ました。そうです、やっちまいました。録画用のBD-Rを買ってしまったのです。BD-Rの録画用はデータ用には使えないそうです。あー、ややこし。これだから、光学ドライブは前から相性が悪く、好きになれない?

category: PC-HW

tb: 0   cm: 0

Windows XP / Office 2003  

Windows XP / Office 2003のサポートが打ち切られ、2か月ほど経ちました。その後、Windows XP / Office 2003を使っていて、ウイルス被害に遭ったというニュースは今のところ、特にないようです。

category: PC-HW

tb: 0   cm: 0

Intel Platform & PCI Express 動向  

2014/8/27加筆修正
2015/2/15加筆修正
2016/10/23加筆修正
2016/11/12加筆修正

2017/02/27 この記事は
PCI/PCI Express バスについて調べてわかったことなど  
へ移動しました。


category: PC-HW

tb: 0   cm: 0

パソコンのディスプレイ解像度  

最近のパソコンはディスプレイ解像度が高い製品が多くなりました。一昔前は「800 × 600 は SVGA だからそこそこなものだ」などとと自分の頭の中のモノサシで評価できたました。しかし、今はディスプレイ解像度が高いもでは3200×1800 や2560×1440が登場し、さっぱり見当がつきません。そこで、現在のスタンダードなディスプレイ解像度をメモっておきます。


バリューノートパソコン 1366 × 768 ( HD )

高級ノートパソコン 1920×1080 ( Full HD )

category: PC-HW

tb: 0   cm: 0

広がるWi-Fi対応機器  

とうとうデジカメにもWi-Fi対応が広がってきた。すでにWi-Fi対応した機器は

プリンター
ポータブルHDD
ゲーム機
スマートフォン
ダブレット
テレビ
レコーダー

今後、どう広がっていくのでしょうか?

category: PC-HW

tb: 0   cm: 0

無線LANのセキュリティー  

昨今、無線LAN(Wi-Fi)が急速に広まりつつあります。そんな中、無線LANのセキュリティーについてきちんとした知識を持っておく必要があります。

無線LANのセキュリティには認証と暗号化がある。
規格認証暗号化 備考
  なしWEP 危険 
WPAWPA-PSKTKIP 
AES 
WPA2WPA2-PSKTKIP 
AES 現在、この組み合わせがベスト


category: PC-HW

tb: 0   cm: 0

Wi-Fi  

無線LANが標準規格に合っていて、相互につながることを示すブランド。

現在の規格はIEEE 802.11a, b , g , n(5GHz) , n(2.4GHz)です。

現在市販の普及価格帯ノートPCに標準搭載されている規格はIEEE 802.11b , g , n(2.4GHz)でしょうか。

IEEE 802.11nが登場してから、無線LANで2.4GHzか5GHzのどの周波数を使うかの話をよく聞くようになりました。

「11ac (Draft)」従来規格の11nと比べ、約11.5倍(規格最大値)の高速  使用する周波数は5GHzです。

IEEE 802.11周波数帯理論最大速度 普及度
a5GHZ54Mbps        
b2.4Ghz11Mbps 
g2.4Ghz54Mbps現在の主流
n5GHZ300Mbps 
n2.4Ghz300Mbps普及しつつある。
ac5GHZ まだDraft 一部製品化

category: PC-HW

tb: 0   cm: 0

PC 高精細モニターの時代到来?  

最近の液晶モニターは高精細なものが増えてきました。Sony VAIO Duo 11では190DPI近くになっています。Windows のUI標準とされている96DPIよりかなり大きくなってきているようです。ですので、文字などは高精細なモニターほど小さく表示されてしまいます。Windows 8などでは高精細モニターへの対応もされているそうです。アプリケーションも高精細モニターに対応したものが登場してくると思われます。

category: PC-HW

tb: 0   cm: 0

My PC spec data  

NEC LaVie S LS550/E
型番 PC-LS550ES4KS (PC-LS550ES6Gがベース)

Win7 Home Premium SP1 64ビット
CPU Intel Core i5 2410M 2.30GH
チップセット HM65 Express
Memory 4GB
無線LAN IEEE 802.11b/g/n

PRINTER
Canon iP2600, iP2700

Aterm WM3300R 無線LAN IEEE 802.11b/g

category: PC-HW

tb: 0   cm: 0

プロフィール

最新コメント

カウンター(2012/3/10以降)