本身從事BIOS相關工作已經六年了;今年由於生涯規劃,決定暫時(?)離開BIOS而轉做其他工作;即使如此,對於 BIOS仍是有著極大的興趣以及期待. 從小就是喜歡做整理以及分享的人,所以最近有個衝動是:何不將自己所知道的整理一下,並將之POST出來,讓更多對BIOS有興趣的人可以有點深入的瞭解BIOS? 也讓版上的諸多前輩可以提出指教及批評,進而糾正我的一些觀念 ? 基於這樣的想法,我選擇了這裡來作為我這個念頭付諸實現的地方,請大家多多挹注,多多指教,多多批評 ! 歡迎任何的建議 ^_^
首先要說明的是,我覺得BIOS在台灣可以分成三類的人:(自己的分法,僅供參考)
1. 撰寫BIOS kernel的人
2. 撰寫chipset code的人
3. 撰寫 OEM code的人
我是屬於第二類的人,所以我的觀點(view point)也是從chipset出發 ! 對於第一及第三類,我的接觸不多 !
要先這樣說明的原因是:有些問題我無法回答或 comment,因此,就有賴版上諸位的幫忙了(if available)
還有,我本身是撰寫某一家BIOS(A, P, or M)的,所以會幾乎以該家的所教給我的 flow/information 來敘述事情;當然,我會盡量抽離這種成分來敘述,讓大家瞭解 "事情的本質即可 "...若有偏頗之處仍須請大家包涵...
最後,我所撰寫的幾乎是親身經歷的 information,因此,不會有天馬行空的想像(不過,做BIOS仍是需要想像力的...^_^...) 若有錯誤,那應該是我的經驗不足,或是我的經驗有誤,還是要請大家指正囉 !
就這樣...
liaoo
~轉載自程式俱樂部討論區~
星期三, 9月 26, 2007
星期一, 10月 08, 2007
[我知道的BIOS]->[系統資源] 6
在此,想先提一下所謂的系統資源(system resources). 在電腦的世界裡,所謂的系統資源約可分為四大類,亦即: DMA, Memory, IO, and Interrupts. (大家若是仔細檢視一下 [我的電腦]->[內容]->[硬體]->[裝置管理員]->[檢視]->[資源(依類型)],便可以發現我想表達的)
* DMA:
=> CPU可以說是系統的大腦;在沒有DMA時,CPU幾乎得參與所有的事情;但是有了DMA後,可以讓 DMA controller或是bus-mastering devices自己來執行data transfer from and to memory,CPU只在開始及結束時參與;如此CPU可以做其他事情. 典型的電腦系統有八個 DMA channels. 檢視 "資源(依類型)"中DMA的部分可以知道哪一個 channel被哪一個 device使用.
* Interrupt:
=> 周邊devices請求 cpu 服務的方式. 一般的電腦系統中有 16IRQs(IRQ0~15). 由兩個 cascade的8259所提供. 當有device透過 IRQx發 interrupt時, CPU會被告知;然後,CPU最後會得到對應於該IRQx的 service routine的 entry point,之後便跳到該處去執行ISR(interrupt service routine). 現在的電腦系統有發展出APIC mode(有別於原有的8259 mode),其目的在於提供更多的 interrupt inputs以及專有的interrupt機制.
在檢視 "資源(依類型)"中的interrupt可發現: IRQ 0/1/4/6/8/12/13/14/15其實是dedicated to specific devices使用的;而剩下的IRQs則是分給PCI devices共同/單獨使用. 若是APIC mode,則可以看到超過15的IRQ !
* Memory:
=>在此所謂的memory,並非指記憶體模組那種memory,而是: CPU memory addressing space ! 亦即,以32-bit CPU而言,可以定址到的 memory space is 2^32 = 4GB. 這麼大的空間就是一種資源 !因為,在此範圍內,CPU可以完全存取,而且,也是有限的 !那,要如何利用這麼大的資源呢 ? 方法就是所謂的 "Mapping(映射)".
舉FM為例,在收音機上一定有旋鈕可以調,亦即, FM的波段是有範圍的. 只有在此範圍,才能收到訊號(<-這也是資源). 然後,在此範圍內,要發射訊號的人,會先提出申請,看要使用那個頻率,經過認可後便可以使用該頻率波段了. 所以在此範圍內便可以聽到警廣,中廣,空中英語教室...等的廣播. (記住: "每個人" 都可以使用該資源中的"一部份",只要"被核准"...)
Memory space 也是一樣 ! 在廣大的 0~4G space中,也有很多人可以使用. Ex. 記憶體模組可以使用某一塊,BIOS ROM也可以使用某一塊, PCI devices也可以使用某一塊,APIC也可以使用某一塊,...etc. 常見的字眼 "Memory map" 就是闡述這樣的觀念 !
*I/O
=> 同理, IO 指的也是 CPU I/O addressing space. 也是一種資源. 現在 I/O addressing space 是 0000h~FFFFh,共64KB的範圍.
[Summary] 資源是有限的,要斟酌使用 ^_^
[補充memory部分]
假設系統插有1G記憶體,使用外部的顯示卡,且使用512KB BIOS ROM,則:
[Part1]
-memory space 0~(1G-1)被此1G記憶體所佔用;或說此1G記憶體被映射到memory space 0~(1G-1);只要CPU存取這個範圍,就會存取到此1G記憶體.
Ex. 在BIOS中寫:(前提: in big-real mode)
xor ax,ax
mov es,ax
mov esi, 00000000h
mov al, BYTE PTR es:[esi] ; access 此1G記憶體中 位置0處的資料 !
[Part2]
-memory space 1G~4G 則是由"其他人"所佔用,例如:(below are examples ONLY)
1.memory space 0xD4100000~D410FFFF是由 Ethernet card的 operational registers 所佔用
2.memory space 0xD4204000~D4204FFF是由 USB 1.1 host的 operational registers 所佔用
3.memory space 0xD4206000~D4206FFF是由 USB 2.0 host的 operational registers 所佔用
4.memory space 0xD4200000~D4203FFF是由 High Definition Audio的 Operational registers 所佔用
5.memory space 0xFEC00000~FECFFFFF是被 IO APIC 所佔用
6.memory space 0xFFF80000~FFFFFFFF是被 512KB BIOS ROM 所佔用
.....
只要CPU存取這範圍,則會access到 "對應" 的device registers.
Ex. 假設要access USB 1.1 HOST's operational register offset 0,則BIOS只要寫:
(前提: big-real mode)
xor ax,ax
mov es,ax
mov esi, 0D4204000h
add esi, 0 ; 0 means offset 0
mov al, DWORD PTR es:[esi] ; access
[Q] 那問題來了:CPU發了一個memory cycle,誰來決定/如何決定要給誰(記憶體 or USB 1.1 HOST OP registers)呢?
=>chipset一定知道系統插了1G記憶體,也會將此資訊,1G( = 40000000h ),記錄在內部register中.當cpu要存取記憶體而發 address: 00000000h 的cycle時,chipset會將 address與 1G比較;因為小於1G,則 "知道" 要發給記憶體 !
當cpu要存取USB OP而發 address: 0D4204000h 的cycle時,chipset會將 address與 1G比較;因為大於1G,則 "知道" 要發給PCI devices, Ex. USB host !
* 1G這個 information 的有一個名詞代表它: Top Memory ! 代表可用的記憶體的上限.
[結論]: 4G memory space 充斥著各式各樣的 "H/W registers"(假如把記憶體也視為 registers,ROM chip也視為registers.....)
Q:問個問題一下古時候, VGA 的memory 是被mapping 到0xA000 的一個64KB 的area，如果你的VGA card 有1MB 的memory 就無法全部mapping, 需要banking 的動作.在big-real mode 中, 如果還是1MB 的memory 會是多大 ,它會比mapping 從哪到哪?
A:就我所知,以前的VGA display會使用到 installed memory A0000h~BFFFFh間的範圍;這是屬於UMA(upper memory area)的一部份;其中A0000h~AFFFFh(64k) for VGA graphics mode memory;B0000h~B7FFFh for VGA mono text mode memory;B8000H~BFFFFh for VGA color text mode memory.
*上述的 三塊 memory 都是 video memory(or called frame buffer),用來儲存要顯示的image的記憶體
* 還記得組語練習中有 output color text to screen,其中所用到的 segment = B800h !!!
( for color text )
當program存取到這塊時,VGA card便會 read it and 負責將之顯示到 monitor !
現在的 VGA cards則是含有 built-in video memory;雖然不是使用系統記憶體,仍是被 mapped to A0000h~BFFFFh.(此時,很重要的一點是:系統記憶體的 A0000h~BFFFFh不再被VGA display用了....這點之後會提到,將被用來放 SMI code...)
你所說的1M memory,因為無法全部 mapped,所以有 bank switch來解決;那麼我的感覺是:還是一樣用 bank switch來解決 !!! 沒有變...
因為,我所知道的 memory map中在1M以下只有 A0000h~BFFFFh for Video card用的(你從 資源(依類型)中去看,也可以發現這範圍是給 display用的...) 而且,in big-real mode 也不會讓 1M memory可以完全 mapped,這是沒關係的 !
這個其實跟系統chipset無關, 跟VGA chip比較有關. 如果VGA chip不支援 linear frame buffer, 我想你只有用banking的方法做. 如果有支援, 正確方式是要透過VBIOS. VBE 2.0以後有定義linear frame buffer的地址位置.你可以呼叫 return VBE mode infomation 這個 function call 來取得位址.
* DMA:
=> CPU可以說是系統的大腦;在沒有DMA時,CPU幾乎得參與所有的事情;但是有了DMA後,可以讓 DMA controller或是bus-mastering devices自己來執行data transfer from and to memory,CPU只在開始及結束時參與;如此CPU可以做其他事情. 典型的電腦系統有八個 DMA channels. 檢視 "資源(依類型)"中DMA的部分可以知道哪一個 channel被哪一個 device使用.
* Interrupt:
=> 周邊devices請求 cpu 服務的方式. 一般的電腦系統中有 16IRQs(IRQ0~15). 由兩個 cascade的8259所提供. 當有device透過 IRQx發 interrupt時, CPU會被告知;然後,CPU最後會得到對應於該IRQx的 service routine的 entry point,之後便跳到該處去執行ISR(interrupt service routine). 現在的電腦系統有發展出APIC mode(有別於原有的8259 mode),其目的在於提供更多的 interrupt inputs以及專有的interrupt機制.
在檢視 "資源(依類型)"中的interrupt可發現: IRQ 0/1/4/6/8/12/13/14/15其實是dedicated to specific devices使用的;而剩下的IRQs則是分給PCI devices共同/單獨使用. 若是APIC mode,則可以看到超過15的IRQ !
* Memory:
=>在此所謂的memory,並非指記憶體模組那種memory,而是: CPU memory addressing space ! 亦即,以32-bit CPU而言,可以定址到的 memory space is 2^32 = 4GB. 這麼大的空間就是一種資源 !因為,在此範圍內,CPU可以完全存取,而且,也是有限的 !那,要如何利用這麼大的資源呢 ? 方法就是所謂的 "Mapping(映射)".
舉FM為例,在收音機上一定有旋鈕可以調,亦即, FM的波段是有範圍的. 只有在此範圍,才能收到訊號(<-這也是資源). 然後,在此範圍內,要發射訊號的人,會先提出申請,看要使用那個頻率,經過認可後便可以使用該頻率波段了. 所以在此範圍內便可以聽到警廣,中廣,空中英語教室...等的廣播. (記住: "每個人" 都可以使用該資源中的"一部份",只要"被核准"...)
Memory space 也是一樣 ! 在廣大的 0~4G space中,也有很多人可以使用. Ex. 記憶體模組可以使用某一塊,BIOS ROM也可以使用某一塊, PCI devices也可以使用某一塊,APIC也可以使用某一塊,...etc. 常見的字眼 "Memory map" 就是闡述這樣的觀念 !
*I/O
=> 同理, IO 指的也是 CPU I/O addressing space. 也是一種資源. 現在 I/O addressing space 是 0000h~FFFFh,共64KB的範圍.
[Summary] 資源是有限的,要斟酌使用 ^_^
[補充memory部分]
假設系統插有1G記憶體,使用外部的顯示卡,且使用512KB BIOS ROM,則:
[Part1]
-memory space 0~(1G-1)被此1G記憶體所佔用;或說此1G記憶體被映射到memory space 0~(1G-1);只要CPU存取這個範圍,就會存取到此1G記憶體.
Ex. 在BIOS中寫:(前提: in big-real mode)
xor ax,ax
mov es,ax
mov esi, 00000000h
mov al, BYTE PTR es:[esi] ; access 此1G記憶體中 位置0處的資料 !
[Part2]
-memory space 1G~4G 則是由"其他人"所佔用,例如:(below are examples ONLY)
1.memory space 0xD4100000~D410FFFF是由 Ethernet card的 operational registers 所佔用
2.memory space 0xD4204000~D4204FFF是由 USB 1.1 host的 operational registers 所佔用
3.memory space 0xD4206000~D4206FFF是由 USB 2.0 host的 operational registers 所佔用
4.memory space 0xD4200000~D4203FFF是由 High Definition Audio的 Operational registers 所佔用
5.memory space 0xFEC00000~FECFFFFF是被 IO APIC 所佔用
6.memory space 0xFFF80000~FFFFFFFF是被 512KB BIOS ROM 所佔用
.....
只要CPU存取這範圍,則會access到 "對應" 的device registers.
Ex. 假設要access USB 1.1 HOST's operational register offset 0,則BIOS只要寫:
(前提: big-real mode)
xor ax,ax
mov es,ax
mov esi, 0D4204000h
add esi, 0 ; 0 means offset 0
mov al, DWORD PTR es:[esi] ; access
[Q] 那問題來了:CPU發了一個memory cycle,誰來決定/如何決定要給誰(記憶體 or USB 1.1 HOST OP registers)呢?
=>chipset一定知道系統插了1G記憶體,也會將此資訊,1G( = 40000000h ),記錄在內部register中.當cpu要存取記憶體而發 address: 00000000h 的cycle時,chipset會將 address與 1G比較;因為小於1G,則 "知道" 要發給記憶體 !
當cpu要存取USB OP而發 address: 0D4204000h 的cycle時,chipset會將 address與 1G比較;因為大於1G,則 "知道" 要發給PCI devices, Ex. USB host !
* 1G這個 information 的有一個名詞代表它: Top Memory ! 代表可用的記憶體的上限.
[結論]: 4G memory space 充斥著各式各樣的 "H/W registers"(假如把記憶體也視為 registers,ROM chip也視為registers.....)
Q:問個問題一下古時候, VGA 的memory 是被mapping 到0xA000 的一個64KB 的area，如果你的VGA card 有1MB 的memory 就無法全部mapping, 需要banking 的動作.在big-real mode 中, 如果還是1MB 的memory 會是多大 ,它會比mapping 從哪到哪?
A:就我所知,以前的VGA display會使用到 installed memory A0000h~BFFFFh間的範圍;這是屬於UMA(upper memory area)的一部份;其中A0000h~AFFFFh(64k) for VGA graphics mode memory;B0000h~B7FFFh for VGA mono text mode memory;B8000H~BFFFFh for VGA color text mode memory.
*上述的 三塊 memory 都是 video memory(or called frame buffer),用來儲存要顯示的image的記憶體
* 還記得組語練習中有 output color text to screen,其中所用到的 segment = B800h !!!
( for color text )
當program存取到這塊時,VGA card便會 read it and 負責將之顯示到 monitor !
現在的 VGA cards則是含有 built-in video memory;雖然不是使用系統記憶體,仍是被 mapped to A0000h~BFFFFh.(此時,很重要的一點是:系統記憶體的 A0000h~BFFFFh不再被VGA display用了....這點之後會提到,將被用來放 SMI code...)
你所說的1M memory,因為無法全部 mapped,所以有 bank switch來解決;那麼我的感覺是:還是一樣用 bank switch來解決 !!! 沒有變...
因為,我所知道的 memory map中在1M以下只有 A0000h~BFFFFh for Video card用的(你從 資源(依類型)中去看,也可以發現這範圍是給 display用的...) 而且,in big-real mode 也不會讓 1M memory可以完全 mapped,這是沒關係的 !
這個其實跟系統chipset無關, 跟VGA chip比較有關. 如果VGA chip不支援 linear frame buffer, 我想你只有用banking的方法做. 如果有支援, 正確方式是要透過VBIOS. VBE 2.0以後有定義linear frame buffer的地址位置.你可以呼叫 return VBE mode infomation 這個 function call 來取得位址.
星期三, 9月 26, 2007
[我所知道的BIOS]->[PowerOn Sequence & BIOS Entry] 3
在此將以DeskTop platform來說明(Notebook platform 的 power-on sequence 牽涉到 EC,可參考討論區中 "power on sequence" 文章);還有,所敘為rough flow,詳細的時序圖依據design會有些許不同.
[Power-On sequence]
- AUX power ok
- Main power ok
- PCI reset
- SB state-machine runs...
- NB state-machine runs...
- CPU power-Good ok
- CPU reset
- 1st code-read by CPU ( <- BIOS entry point,即 CPU 會抓取 FFFFFFF0h 處的 BIOS code 來執行)
* 當然CPU一次抓取的BIOS data不僅僅是幾個Byte ! 而是一堆的data(Ex. 64 bytes);之後會從中 extract 出 FFFFFFF0h處的 data,然後來執行.
補充: 為什麼CPU 發的第一個位置不會只有FFFFFFF0h? 而是多抓很多個? 範例中為什麼是64 bytes?
原因在於 cache的支援. cache不是細分為單一byte 的, 而是以block(many bytes)為單位. 這個block的大小的名詞就是 cache line size. 也就是要填入cache一次要寫入的bytes量. 例如 cache line size 為 16 bytes. 那麼一次就要讀16 bytes到cache去.
CPU 一但發生cache miss(第一次開機一定是cache miss)的狀況時.就會通過host bus 對外取得資料. 這時就會產生burst read cycle來達成fill cache line的需求. 所以由CPU 的 cache line size的大小就可以知道CPU一次會抓多少的 bytes. P4以後CPU 的cache line size 為 64 bytes, 所以CPU 就會產生一個 burst length 為8 的 memory read cycle. 所以CPU 發出的位置就需往下減.然後在讀取的資料中可以包含到 FFFFFFF0h以後的資料.
自此,CPU便循著 CPU->NB->SB->ROM 的 path,循序地至BIOS ROM中抓code,執行 fetch->decode->calculate->store...自此開始便是BIOS POST stage starts...
[有可能遇到的問題是] debug code = "00" or "FF" (意即BIOS常用的 Port80 card所顯示出的 "code" ) !!!
* 此時,強烈建議:請在BIOS entry point 處 丟Port 80(value可自行定義),因為,即使BIOS有跑到,但因為距離 1st 丟 Port80 的 code仍有一小段程式碼;若系統 hang在此其間,Port80仍是沒有 code,因此,在BIOS一開始進來便先 out Port80 將有助於判定: system hang before BIOS entry point or NOT !!! )
# Assume system hang 'before' BIOS entry point, 可能的原因有:
- incorrect power sequence: 此 sequence 有 spec,規範訊號間的相對關係與 assert/deassert的時間,violate spec有可能導致 system hang;此時需要 H/W or board designer來量測
- incorrect power-on frequency:有發生過因為 Power-On CPU frequency錯誤而不開機者.請用 scope量測
- incorrect chipset behavior: 意即上述的 power-on sequence中有關於 NB/SB的 state-machine部分,有可能這部分的行為不正常,因此需要 H/W designer來 clarify
* 曾聽說,某家chipset需要BIOS image 中 include 幾個 bytes 來 config NB/SB的 registers;這些 settings也會影響 power-on時 chipset的 behavior;因此,這幾個 byte 若是錯的,也有可能 system hang
補充:很多chipset都(or 曾經)有這個功能, SiS, NV, VIA, Intel. 以前有個詞叫ROMSIP就是指這玩意兒... 即使在現今的intel platform也有預留這東東.
#Assume system hang 'after' BIOS entry point
=> 這就是BIOS engineer的時間了,就 debug吧...(儘管,有些 issue 是 board or H/W造成的...)
* 此時的 debug方式,若有 輔助工具的(Ex. P debug card) 就用,沒有的就用Port80 card囉 !
[Summary]: 沒進入到 BIOS entry point前....不要找我....真的沒辦法 >_<
* 關於 BIOS entry point,請參考 討論區中 "追蹤BIOS code 的進入點" 文章 !!!
[Power Button開始的動作]
一般Power Btn 都是EC 控制(或稱PCU)，如果你說要知道Power Btn之後的動作就是問EC 工程師就對啦。
我印象中好像是Power btn按下後-->EC 偵測到動作(應該是KBC 發Event給EC BIOS或是EC BIOS自己每隔一段時間去檢查有沒有Event..沒K過EC Spec,純猜測...)-->EC 檢查目前系統狀態(不同時間點按下Power Btn , EC可能會做一些動作，因此要判斷)，檢查的時候主要會去檢查南橋ICH接到EC的訊號線，判斷Sx state-->如果是正常開機，則開始供電--->系統上電後，CPU會從起始位址開始讀取BIOS第一條指令(至於CPU何時收到重置訊號可能要看一下其他Spec...)。
另外印象中EC BIOS有分成兩種形式，因為EC Controller可能裡面的記體器容量會不足，或是說節省成本故意做成那樣，所以 EC BIOS 會是包在SBIOS或是放在EC Controller裡面兩種格式。
如果真的要K流程，應該是去看EC Spec跟ICH Spec吧...
當EC 收到power event (指power button的動作後...), 會根據目前系統的狀態來決定是否要開某些電源...For example, 當系統處於s3(suspend)的狀態時, 當user按下power button後, EC 會發一個訊號給南橋, 然後EC 會wait for SUSB and SUSC 的訊號assert. 然後開 main power的電(我指的是非suspend的power)...但是詳細的動作應該各家都不太一樣才對. 而且這些spec都是各公司的knowhow
[Power-On sequence]
- AUX power ok
- Main power ok
- PCI reset
- SB state-machine runs...
- NB state-machine runs...
- CPU power-Good ok
- CPU reset
- 1st code-read by CPU ( <- BIOS entry point,即 CPU 會抓取 FFFFFFF0h 處的 BIOS code 來執行)
* 當然CPU一次抓取的BIOS data不僅僅是幾個Byte ! 而是一堆的data(Ex. 64 bytes);之後會從中 extract 出 FFFFFFF0h處的 data,然後來執行.
補充: 為什麼CPU 發的第一個位置不會只有FFFFFFF0h? 而是多抓很多個? 範例中為什麼是64 bytes?
原因在於 cache的支援. cache不是細分為單一byte 的, 而是以block(many bytes)為單位. 這個block的大小的名詞就是 cache line size. 也就是要填入cache一次要寫入的bytes量. 例如 cache line size 為 16 bytes. 那麼一次就要讀16 bytes到cache去.
CPU 一但發生cache miss(第一次開機一定是cache miss)的狀況時.就會通過host bus 對外取得資料. 這時就會產生burst read cycle來達成fill cache line的需求. 所以由CPU 的 cache line size的大小就可以知道CPU一次會抓多少的 bytes. P4以後CPU 的cache line size 為 64 bytes, 所以CPU 就會產生一個 burst length 為8 的 memory read cycle. 所以CPU 發出的位置就需往下減.然後在讀取的資料中可以包含到 FFFFFFF0h以後的資料.
自此,CPU便循著 CPU->NB->SB->ROM 的 path,循序地至BIOS ROM中抓code,執行 fetch->decode->calculate->store...自此開始便是BIOS POST stage starts...
[有可能遇到的問題是] debug code = "00" or "FF" (意即BIOS常用的 Port80 card所顯示出的 "code" ) !!!
* 此時,強烈建議:請在BIOS entry point 處 丟Port 80(value可自行定義),因為,即使BIOS有跑到,但因為距離 1st 丟 Port80 的 code仍有一小段程式碼;若系統 hang在此其間,Port80仍是沒有 code,因此,在BIOS一開始進來便先 out Port80 將有助於判定: system hang before BIOS entry point or NOT !!! )
# Assume system hang 'before' BIOS entry point, 可能的原因有:
- incorrect power sequence: 此 sequence 有 spec,規範訊號間的相對關係與 assert/deassert的時間,violate spec有可能導致 system hang;此時需要 H/W or board designer來量測
- incorrect power-on frequency:有發生過因為 Power-On CPU frequency錯誤而不開機者.請用 scope量測
- incorrect chipset behavior: 意即上述的 power-on sequence中有關於 NB/SB的 state-machine部分,有可能這部分的行為不正常,因此需要 H/W designer來 clarify
* 曾聽說,某家chipset需要BIOS image 中 include 幾個 bytes 來 config NB/SB的 registers;這些 settings也會影響 power-on時 chipset的 behavior;因此,這幾個 byte 若是錯的,也有可能 system hang
補充:很多chipset都(or 曾經)有這個功能, SiS, NV, VIA, Intel. 以前有個詞叫ROMSIP就是指這玩意兒... 即使在現今的intel platform也有預留這東東.
#Assume system hang 'after' BIOS entry point
=> 這就是BIOS engineer的時間了,就 debug吧...(儘管,有些 issue 是 board or H/W造成的...)
* 此時的 debug方式,若有 輔助工具的(Ex. P debug card) 就用,沒有的就用Port80 card囉 !
[Summary]: 沒進入到 BIOS entry point前....不要找我....真的沒辦法 >_<
* 關於 BIOS entry point,請參考 討論區中 "追蹤BIOS code 的進入點" 文章 !!!
[Power Button開始的動作]
一般Power Btn 都是EC 控制(或稱PCU)，如果你說要知道Power Btn之後的動作就是問EC 工程師就對啦。
我印象中好像是Power btn按下後-->EC 偵測到動作(應該是KBC 發Event給EC BIOS或是EC BIOS自己每隔一段時間去檢查有沒有Event..沒K過EC Spec,純猜測...)-->EC 檢查目前系統狀態(不同時間點按下Power Btn , EC可能會做一些動作，因此要判斷)，檢查的時候主要會去檢查南橋ICH接到EC的訊號線，判斷Sx state-->如果是正常開機，則開始供電--->系統上電後，CPU會從起始位址開始讀取BIOS第一條指令(至於CPU何時收到重置訊號可能要看一下其他Spec...)。
另外印象中EC BIOS有分成兩種形式，因為EC Controller可能裡面的記體器容量會不足，或是說節省成本故意做成那樣，所以 EC BIOS 會是包在SBIOS或是放在EC Controller裡面兩種格式。
如果真的要K流程，應該是去看EC Spec跟ICH Spec吧...
當EC 收到power event (指power button的動作後...), 會根據目前系統的狀態來決定是否要開某些電源...For example, 當系統處於s3(suspend)的狀態時, 當user按下power button後, EC 會發一個訊號給南橋, 然後EC 會wait for SUSB and SUSC 的訊號assert. 然後開 main power的電(我指的是非suspend的power)...但是詳細的動作應該各家都不太一樣才對. 而且這些spec都是各公司的knowhow
星期三, 10月 10, 2007
[我所知道的BIOS]->[PCI SCAN] 9
這次要提的是: PCI !
[About PCI device]
1. 每一個PCI device都有其 unique PFA(PCI Function Address). PFA由 bus number,device number & function number所組成.
Ex. USB device PFA is (0,6,0) <- USB is a PCI device and its bus/dev/function is 0/6/0
2. 有了PFA,就可以存取其 PCI configuration registers.
Ex. write USB PCI register 43h bit1 = 1
=>
mov eax, 80003040h
mov dx, 0cf8h
out dx, eax
mov dx, 0cffh
in al, dx
or al, 00000010b
out dx, al
* IO port 0cf8/0cfc 為 PCI config address port & data port,意即:將 address(80003040h)送到config port(0cf8h),然後從 data port(0cfch + 3)來存取 data(al)
* 注意: 32-bit address(80003040h) 中 bit[1:0] = 00b(固定的),所以雖然存取的是 43h,但還是寫成40h ! 而要存取到 43h,則從 0cfch+3來達成 (因為: 0cfch<-> 40h,0cfdh<->41h,0cfeh<->42h, 0cffh<->43h)
3. 基本的PCI device的 config registers可分成 2 parts:
A. header region(offset 00h~3Fh)
B. device specific region(40h~FFh)
在BIOS's PCI_SCAN stage中,會touch到 part A. Ex. command byte, BARs, Interrupt line, latency timer,...etc. 而Part B是製作 or design這個device的廠商所附加的 function/feature.
4. 每個PCI device都可以 request 之前所提的 4 resources:
A. memory resource:透過 Base Address Register(BAR)
B. IO resource:透過 Base Address Register(BAR)
C. Interrupt: 透過 interrupt pin
D. DMA: 這需要 device本身即具有 bus master function(status byte會indicate)
[Why need PCI SCAN]
現在的computer system泰半由許多PCI devices所組成,因此,BIOS POST中另一個重要的 task is : PCI_SCAN !!!
它代表的是: BIOS會掃瞄 whole system,找出所有的PCI devices; initial them and build a linked list of PCI devices.在此list中的每一個node都代表一個PCI device,且含有其 characteristics !
Ex. Vendor ID,Device ID, PFA,Option ROM exist or NOT,...etc.
一旦建好此表,以後的 tasks 隨時都可以參考 !!!
所以, after PCI_SCAN,有兩件事完成了:
1. PCI device initialization;device config registers(Part A) are correctly set ...
2. One data structure is built to describe the PCI devices in whole system(建在memory中)
這也是屬於kernel code part ^_^ ( system 一般很少 hang at this stage...)
符合PCI spec的device即稱為........PCI device ^_^
[補充] PCIe device
PCIe device => 符合PCIe spec的device(...廢話...)
對軟體而言,它仍是PCI device. 因此,基本的 header region and device specific region也有. 不過,PCIe新定義了 extended config space,即 offset 100h(含)以上,直到 FFFh( 所以, 最大可以至 4096 bytes )
存取 PCI config space的方式,用原來 0cf8/0cfc的方式依然可行,但只能 access offset 00h~FFh. 要 access 100h(含)以上的 extended config space,則必須用 memory transaction的方式 !
Ex. mov ax, [50400000h] <- read device (4,0,0)'s register 0;2 bytes
here 50000000h: PCIe extended base address. 可以從 chipset register得知
bit[27:20]: Bus information
[19:15]: Device information
[14:12]: Function information
[11: 8]: Extended Register
[7:2]: DW number
[1:0]: Byte enable
因此,只要知道 PCIe extended base address,就可以像以前一樣,可以任意存取 PCIe config registers, even > 0FFh !
除此之外, PCIe device可以由其 Capability pointer(points to a linked list of capabilities)辨認出來. 因為,在眾多的 capabilities中,會有一個 PCIe capability;其 ID value = 10h.
Note: PCIe extended base address 要 reserve and report to OS. Size is 256MByte. 這是BIOS需要做的. (當然,BIOS也要將此 base address寫入 chipset register,讓 chipset 知道:有這樣的 cycle時,是給PCIe device的 ! )
[補充] For P2P bridge
P2P bridge = PCI-to-PCI bridge. 其存在可以 introduce 另一 new PCI bus,可以容納更多的 PCI device.
P2P bridge亦有其 PCI config space,但是 lauout 與 PCI device有點不同,大家可以參閱P2P spec並與PCI device's config space比較一下.
在 P2P config space中,我常遇到的 issue是和下列 register有關的:
- Primary bus register: offset 18h
- Secondary bus register: offset 19h
- Subordinate bus register: offset 1Ah
----------------------------------------
Notes:
這三個 registers是BIOS在 PCI_SCAN時會決定的;所代表的意義是:這個 P2P bridge的上面 PCI bus number is ? 下面的PCI bus number is ? 及包含此 P2P bridge的 "branch" 最深的 PCI bus number is ?
Ex. 18/19/1Ah of one P2P bridge is 0/2/3
=> 此 P2P bridge 是 "bridge" PCI bus 0 and 2的(橋接在 PCI bus 0 and 2之間);而包含此P2P bridge的 PCI branch(想像成 tree structure) 最大(深)的PCI bus number is 3
----------------------------------------
- memory base/limit
- IO base/limit
----------------------------------------
Notes:
這兩個是 BIOS 在 PCI_SCAN時所 assign的. 所代表的是: resource "window" for devices behind this bridge.意即:若P2P bridge下面(就上例言:是 Bus 2上)有 PCI devices,則他們的 BARs 必須被包含在此 window 之內 !!!
----------------------------------------
[Practice]
[Q]假設有一個 P2P bridge ,下面有一PCI device;現在必須要去 accessPCI device's Device ID/Vendor ID(that is, PCI config read). 但是,問題是:做這事的"點"要在 PCI_SCAN之"前"....那要如何做到呢 ^_^ ?
Ans:假如要在很早前(Ex. PCI SCAN之前)去 access P2P bridge後面的 device,照理是做不到的,因為: P2P bridge沒有被正確的 configed...
在此例中,P2P bridge的 primary/secondary/subordinate bus要被 set,後面的device才能被 accessed到 !
所以,假如要在 PCI SCAN前就 access,則BIOS必須手動去 set 此 3 bytes;然後,PCI config access才能被 forward to 其後的 PCI devices...
[Q] 如何 disable memory or IO resource window ?
Ans: 只要將 base設成比 limit "大" 即可 !!!
---------------
- 相關討論 Part1 -
---------------
前輩已經提到P2P Bridge我就直接問我的問題了
[Q1] Bridge 是用來擴充PCI Bus，在PCI Bus Spec與PCI-PCI Bridge Spec中定義，PCI Device是透過IDSEL來決定他的身分，其中PCI Bus Spec定義AD[31:11]，而PCI Bridge Spec定義AD[31:16] 當做IDSEL，這中間差異為何? 為什麼一個要從Bit 11開始當作是Dev 0 ，而另一個由Bit 16 才當作是 Dev 0 ?
Ans: 1. IDSEL對PCI device而言是 input,是用來當作 device's "chip-select"訊號. 而且,IDSEL "如何連接" 是 H/W決定的,BIOS無法決定.
假如將板子上某個device's IDSEL "割斷",則此 device將無法接受 PCI configuration read/write(以 ru.exe來說,就是按F6後,是看不到它的...)
那要如何決定 device's IDSEL ? 一般而言, board designer會將 "unused AD lines"拿來做 IDSEL,以連接至 PCI device.
在 configuration access時,所下的 Ex. "o cf8 80001020"(看起來是 I/O transaction)會被 host bridge轉成 configuration transaction;此時, host bridge即可判斷此 transaction 要 access的 device是否在該 PCI bus上;if YES 轉成 Type 0 transaction;If NO 轉成 Type 1 transaction,並往下發送...(host bridge只要 check latched "bus information"即可完成此判斷 !)
以 Type 0言,AD bus上的 format as follows:
bit[1:0] = 00 ( indicates "Type 0" )
bit[7:2] indicates register number
bit[10:8] indicates function number
那 Bus number ? Device number ?
=> Bus number不必知道 ! 因為:Type 0產生即代表 bus number = 現在的 bus #
=> Device number呢 ? 因為,此時(Config transaction && address phase) AD bus bit[31:11]沒人用 !!! 因此, board designer會把此 21 bits拿來做 IDSEL用 !
因此, AD bus bit11 <-> device 0
12 <-> device 1
.......
當然,不可能 21 bits都拿來接 PCI devices;因為電路上的現實考量...
.................以上為:我所知為何從 bit11開始來當作 IDSEL................
以 Type 1言,PCI-PCI bridge收到後,會將其 bus information與自己的 secondary bus number比較;若是 addressed device是在 secondary bus上,則將 Type 1 -> Type 0;若否,繼續包成Type 1往下一層送...
在P2P spec v1.1 page 22 有一張表,說明 IDSEL generation(from primary address -> secondary address),其中有提到: if primary address bit[15:11] =0,則 secondary address AD [31:16] = 0000 0000 0000 0001;以此類推.
所以,我覺得為什麼 for P2P bridge 其 IDSEL可由 bit[31:16] 來決定的原因在此 !!!(表的關係...)
.................以上為:我推論為何從 bit16開始來當作 IDSEL................
[補充]
PCI config index register裡面的資料其實和硬體解出configuration cycle是相關的.
一.轉換出來是type 0 cycle的話. 硬體只要做以下兩件事.
1. mask 掉bus number(bit 16 ~ 31)以上的部份.
2.解碼 device number的部份即可到對應的 AD bit. 所以其最低可以使用的就是AD11.也就是說一個bus上最多只能有 21個 devices(只是由於推動力問題, 往往是做不到的).
Note:其實也可以設計成其他大於AD 11開始, 這要看chip設計者決定了.
二. 轉換出來是type 1 cycle的話. 只要做
1. mask 掉reserved以上的部份(bit 24 ~31)
2. bit 0 = 1
由於P2P跟其他device不同的地方就是, 除了type 0 clcye以外, 還必須處理 type 1 cycle. 這也是分成兩部份
一. type 1 -> type 0. 當 bus number 等於 secondary bus number 時候出現.
1. 解碼 device number 到對應的 AD. spec中有提到轉換的表. dev 0 = AD16....etc
2. 把 bit 0 由1 變成 0
二. type 1-> type 1. 當 bus number 介於 secondary bus number和 subordinate bus number
1. 直接往下一層送即可.交給其他的P2P 處理.
[Q2] 在IA32下，CONFIG_ADDRESS 會被轉成Configuration Cycles，當Bus Number <>0 時，NB會轉成Type 1 然後往 DMI送到SB，當P2P Bridge收到後，然後定址到Slot上面的PCI Device，這樣說法對嗎?
Ans: 總而言之, 是自己local bus上的,就會轉成 Type 0,然後打在AD bus上,等待認領;若否就轉成 Type 1,往下一個bridge送,繼續尋找...對的人...for each bridge,都是一樣...
[補充]
對 PCI spec是, 如果以Intel PCI express架構來說. 那個已經被封裝成 pci express的 package了.沒有所謂的 type 0, type 1 cycle了.
[Q3]PCI Device透過IDSEL來決定身分，那PCIE Device呢? 我查過資料，好像PCIE不需要IDSEL那他是如何決定Device Number ?
Ans: 我所遇的 PCIe device也是由 AD bit[31:11]中找線拉至 device's IDSEL決定的.不知其他家 chipset是如何 implement.
[補充]
PCI express 是internal routing. PCI express是個跟PCI 完全不同的架構. 只是為了軟體相容性的關係, 把software架構做的跟PCI bus一樣. PCI express是point-to-point架構, 一個link 只會連接一個device. 跟PCI 這種可以多個device在同一bus上是不一樣的. 所以 device number對PCI express是完全不重要的.
Note. AMD的Hyper transport 也是基於一樣的心態來設計軟體架構的.
※ PCIe 的device是 internal routing. 以規格來看,下一層的 device number都是為0.
------------------
- 相關討論 Part 2 -
------------------
DMI指的是 Intel 南北橋中間的通道 ! 之前也是不知P2P bridge部份關於IDSEL的配置,查了表才知道原來有這樣的 mapping(primary address<->secondary address). 其實,可以說 "unused AD bus 會被拿來當 IDSEL用"就是了吧 ^_^
[補充]
是的, 只要軟體能夠知道routing 關係.怎麼接都可以. 只要bus controller控好實際的IDSEL即可. P2P之所以會有嚴格規定(兩項, 1. IDSEL&device number表, 2. secondary bus IRQ routing)是因為P2P 不一定是在板子上. 包含卡都可以有P2P bridge. 在板子上的P2P 可以靠BIOS來建立正確的 routing, 但是插卡不行. 所以必須把這些定義好. 這樣 PnP software(BIOS or OS)才能正確的完成IRQ 分配.讓卡正常工作. 所以如果觀察某些板廠. 就算是真的p2p 沒有存在在板子上, 很多PCI slot的IRQ routing都是依據p2p spec裡面的規定做(因為SB的PCI bus還是落在P2P之後).
在 PCI scan時,BIOS會掃描整個系統的PCI architecture(包含 device & bridge);其掃描方式由BIOS's PCI kernel來決定 !
[補充]
其實了解PCI spec. 要寫PCI scan其實可以效率好又正確. 常見的新進工程師寫法大概就是 3個 loop來處理. bus:0~255, device:0~31, function:0~7. 掃個 256*32*8次, 反正都是程式做, 結果往往也看來正確.這種寫法其實是不對的. (其實,若是多了解硬體的架構,就可以寫出有效率的code了 ! 這也是F/W工程師的價值...)
Ex. Assume 系統架構是這樣的: NB,P2Px3, PCIe bridge x2;其中:
A. 3 P2Ps的配置 is: P2P0下面接P2P1;P2P下面接P2P2
B. PCIe x 2 & P2P0都在 bus 0;其PFA為
NB(0,0,0)
P2P0(0,1,0)
PCIE0(0,4,0)
PCIE1(0,5,0)
=> 最後的 PCI achitecture is:
Bus 0----------------------
NB(0,0,0),P2P0(0,1,0),PCIE0(0,5,0),PCIE1(0,6,0)
*下面 Bus 1/2/3由 P2P0/1/2所 introduce:
Bus 1----------------------
P2P1(1,0,0)
Bus 2----------------------
P2P2(2,0,0)
Bus 3----------------------
*下面 Bus 4由 PCIE0所 introduce:
Bus 4----------------------
*下面 Bus 5由 PCIE1所 introduce:
Bus 5----------------------
所以,Bus number 是由BIOS's scanning "algorithm"所決定的;假如採用 depth-first,則會產生上述的結果 ! 決定後的值會填到 bridge的 Primary/secondary/subordinate bus number registers !
[Q]順便問個問題好了. 其實function number不應該是永遠需要scan的, 為什麼?什麼時候才需要scan function number?
Ans: 我想,對於 function number的問題,應該是: PCI header region offset 0Eh bit7代表: milti-function or NOT ! 因此,可以先 check此bit,再決定要不要往下掃了...這樣又少做了許多虛工...^_^
Ex. PFA (0,3,0) 有回應(that is, Vendor ID/Device ID != 0xFFFFFFFF),則先check (0,3,0)'s PCI Reg0Eh bit7; if "1" then 此device為 multi-function device,還要再往下找 Ex. (0,3,1~7) 有無回應;if "0" then try next device number...!
[補充，加快速的的方式]
檢查multi function bit是正確的, 但是不只是因為效率問題. 而是PCI 規格中, single function裝置可以不解碼 config cycle type 0 bit[8~10], 也就是說 一個 single function裝置, 會對 所有的function number回應, 也就是會出現 8 個相同的device.
順便說一下我的scan加速法. 其實我不是使用 vandor ID & device ID來判斷裝置存在與否. 我是用 class/subclass/interfae ID來作判斷. default 只scan bus 0, 遇到 P2P bridge才會把taget bus number+1, 如果遇到multi host(host bridge 數量> 1)的板子才會完整掃描 255個 bus. ^_^
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
~轉貼自艾克索夫實驗室~
Rootkit in PCI Option ROM
「Rootkit」一字來自 UNIX 界；但目前通常用於描述 Windows 木馬程式作者所運用的隱形技術。
起初，Rootkit指的是一組程式，可讓駭客躲過偵測。 為達成此目的，可執行的系統檔案 (如 login、ps、ls、netstat 等) 或系統程式庫 (libproc.a) 會遭到更換，或安裝核心模組。 這兩種動作只有一個相同目的；防止使用者收到正確資訊，知道電腦上發生了什麼事。
首先介紹PCI的基本常識, PCI Bus是在約1990年由Intel發展出來, 用來連接主機板上的各項裝置的匯流排標準, 後來成為業界的標準之一, Spec可以在PCI-SIG註冊會員之後下載, 架構上簡單的說, 就是一個Host bridge, 在一般的PC上通常指的就是North Brdige, 這個brdige後面就是bus#0(當然也有Multi Host-Bridge的狀況, 這邊舉例的是最單純的情況), 然後接到South Bridge, South Bridge之後可能接的是ISA Bus, IDE Controller, USB, IDE, DMA Controller等等, 如果bus#0上還有別的PCI Bridge, 這個Bridge後面就是bus#1, 如果有多個Bridge存在(PCI最多可以有256個bus), bus#就不一定是固定的了, 一個PCI Bus上可以有32個device, 每個device可以有8個function, 每個function都有屬於自己的256個register. 在PCI的規範裡, 256個register中的前0×40個是公定的功能, 從0×40到0xff則由各家廠商自行實作, 存取這些register的方法, 一般的PC上是透過IO port 0xCF8~0xCFF, 如果是新的PCI-Express則是直接透過Memory Mapped IO, 以存取記憶體的方式直接進行存取, 例如我們想要讀取一個在bus#0 dev#1 func#0的register#40~43, 透過IO的方式如下:
mov eax, (0x01 << 31 ) // Type-1 PCI Configuration
+ (0x00 << 16 ) // Bus#0
+ (0x01 << 11 ) // Device#1
+ (0x00 << 8 ) // Function#0
+ 0x40 // Register#40
mov dx, 0xCF8 // Index Port 0xCF8 ~ 0xCFB
out dx, eax
mov dx, 0xCFC // Data Port 0xCFC ~ 0xCFF
in eax, dx // Get Data in EAX
如果是透過MMIO的方式則簡單多了:
mov esi, (MMIO_BASE) + (0x00 << 20) + (0x01 << 15) + (0x00 << 12) + 0x40
mov eax, [esi]
今天我們比較有興趣的是位在0×30~0×33的register, 在PCI Spec定義中, 這裡的值存放的就是expansion rom在physical memory中被decode到IO的位址, 比如說這個位址是0xFE000000, 如果你在0×30把bit0設為0×1(io->mem decode), Command Register(0×04~0×05)的Memory Space Bit打開, 在0xFE000000的地方你就可以找到這個rom, 開頭是0×55AA(這當然也是規範之一, 用來辨視是否為一個PCI rom), BIOS在POST過程中, 會逐一掃描位於主機板上所有的PCI Device, 假如device上有rom, 就會把它給拷貝到memory中, 然後用jmp指令跳到ROM開頭offset 0×02(別忘了開頭offset 0×00是0×55AA)的地方開始執行PCI ROM, 執行完後ROM會再把控制權交回到BIOS手上, 一般而言, 在傳統記體空間中, 0xC0000~0xCFFFF是給VGA ROM用的, 0xD0000~0xEFFFF則是留給一般的PCI ROM使用, 當然各種情況下還是會有些許差異, 例如有些BIOS會保留0xE0000~0xFFFFF給自己使用, 像是BIOS的interrupt service, DMI data….等等雜七雜八的東西, 執行完的ROM仍然會保留在記憶體中, 因為有些ROM會修改IVT(Interrupt Vector Table), 將某些interrupt service導向自己的code, 像是VGA ROM可能就會hook int 0×10, 這是很合理的, 因為int 0×10是BIOS所提供用來控制螢幕的service, 聰明的你看到這裡應該就知道前面所提的那篇文章想說什麼了, 如果有個”惡意”的程式被埋在PCI ROM裡面, 只要一開機就會自動被執行, 它的運作並不是一時的, 它可以hook某個OS一定會用到的BIOS Interrupt Service, 然後在這個interrupt service被呼叫的時候動作就可以了, 而且麻煩的是即使你format你的HDD也沒用, 除非你把有問題的PCI Device從你的主機板上移除, 嗯….聽起來蠻炫的, 但是, 有可能嗎?
要回答這個問題之前, 需要知道一些基本的常識, 在保護模式下, 因為IO動作受到限制的關係, 要存取IO並不像在DOS那樣容易, 但如果想嘗試Re-flash一顆PCI ROM, 勢必得進行IO動作, 所幸在Windows下這並不是不可能的事, 有些人可能知道利用SeTcbPrivilege和使用ProcessUserModeIOPL structure呼叫undocumented Native API NtSetInformationProcess()就可以達成目的. 一旦攻擊者有辦法修改PCI ROM, 他就可以利用文章中所提到的例子: int 0×10(Windows在開機過程中會透過Ke386CallBios()呼叫int x010), 作他想作的任何事了.
可惜不論哪種攻擊方式, 最終都是要對OS kernel動手腳, 利用各種偵測工具(如: Archon Scanner), 一定可以找到有問題的地方, 如果最後的箭頭指向PCI ROM, 我們可以透過上文所述, 將存在PCI Device和memory中的ROM給dump出來, 需要dump兩邊的rom, 是因為PCI Spec規範中允許實際上所需要配置的記憶體不一定要等於原本rom的大小, 藉以節省保貴的記憶體(別忘了PCI ROM只能被配置到幾個64KB的segment裡而已), 然後向PCI Device的製造商索取正常版本的rom進行比對, 藉以得知是否為被修改的版本. 假如發現有不一樣的地方, 接下來可以朝幾個方向繼續分析是否為有問題的ROM, 我們可以檢查一下它是否修改了不必要的IVT, 像PXE ROM就不太可能hook int 0×10, 或是有保護模式相關的程式碼, 因為一般的ROM應該都是在real mode下執行, 所以應該不會切到protected mode, 如果有相關的程式碼那就非常可疑, 還有rom裡面是否有可疑的字串, 或是位在Windows Kernel位址空間裡的32-bit address, 另外ROM裡面也不太可能出現編碼過的code, 如果rom裡的code很難被disassemble, 或是充滿了一堆obfuscated code, 那也是很有問題.
除了軟體的方式, 最近興起的新技術TPM也能克制這種攻擊手法
[About PCI device]
1. 每一個PCI device都有其 unique PFA(PCI Function Address). PFA由 bus number,device number & function number所組成.
Ex. USB device PFA is (0,6,0) <- USB is a PCI device and its bus/dev/function is 0/6/0
2. 有了PFA,就可以存取其 PCI configuration registers.
Ex. write USB PCI register 43h bit1 = 1
=>
mov eax, 80003040h
mov dx, 0cf8h
out dx, eax
mov dx, 0cffh
in al, dx
or al, 00000010b
out dx, al
* IO port 0cf8/0cfc 為 PCI config address port & data port,意即:將 address(80003040h)送到config port(0cf8h),然後從 data port(0cfch + 3)來存取 data(al)
* 注意: 32-bit address(80003040h) 中 bit[1:0] = 00b(固定的),所以雖然存取的是 43h,但還是寫成40h ! 而要存取到 43h,則從 0cfch+3來達成 (因為: 0cfch<-> 40h,0cfdh<->41h,0cfeh<->42h, 0cffh<->43h)
3. 基本的PCI device的 config registers可分成 2 parts:
A. header region(offset 00h~3Fh)
B. device specific region(40h~FFh)
在BIOS's PCI_SCAN stage中,會touch到 part A. Ex. command byte, BARs, Interrupt line, latency timer,...etc. 而Part B是製作 or design這個device的廠商所附加的 function/feature.
4. 每個PCI device都可以 request 之前所提的 4 resources:
A. memory resource:透過 Base Address Register(BAR)
B. IO resource:透過 Base Address Register(BAR)
C. Interrupt: 透過 interrupt pin
D. DMA: 這需要 device本身即具有 bus master function(status byte會indicate)
[Why need PCI SCAN]
現在的computer system泰半由許多PCI devices所組成,因此,BIOS POST中另一個重要的 task is : PCI_SCAN !!!
它代表的是: BIOS會掃瞄 whole system,找出所有的PCI devices; initial them and build a linked list of PCI devices.在此list中的每一個node都代表一個PCI device,且含有其 characteristics !
Ex. Vendor ID,Device ID, PFA,Option ROM exist or NOT,...etc.
一旦建好此表,以後的 tasks 隨時都可以參考 !!!
所以, after PCI_SCAN,有兩件事完成了:
1. PCI device initialization;device config registers(Part A) are correctly set ...
2. One data structure is built to describe the PCI devices in whole system(建在memory中)
這也是屬於kernel code part ^_^ ( system 一般很少 hang at this stage...)
[補充] PCIe device
PCIe device => 符合PCIe spec的device(...廢話...)
對軟體而言,它仍是PCI device. 因此,基本的 header region and device specific region也有. 不過,PCIe新定義了 extended config space,即 offset 100h(含)以上,直到 FFFh( 所以, 最大可以至 4096 bytes )
存取 PCI config space的方式,用原來 0cf8/0cfc的方式依然可行,但只能 access offset 00h~FFh. 要 access 100h(含)以上的 extended config space,則必須用 memory transaction的方式 !
Ex. mov ax, [50400000h] <- read device (4,0,0)'s register 0;2 bytes
here 50000000h: PCIe extended base address. 可以從 chipset register得知
bit[27:20]: Bus information
[19:15]: Device information
[14:12]: Function information
[11: 8]: Extended Register
[7:2]: DW number
[1:0]: Byte enable
因此,只要知道 PCIe extended base address,就可以像以前一樣,可以任意存取 PCIe config registers, even > 0FFh !
除此之外, PCIe device可以由其 Capability pointer(points to a linked list of capabilities)辨認出來. 因為,在眾多的 capabilities中,會有一個 PCIe capability;其 ID value = 10h.
Note: PCIe extended base address 要 reserve and report to OS. Size is 256MByte. 這是BIOS需要做的. (當然,BIOS也要將此 base address寫入 chipset register,讓 chipset 知道:有這樣的 cycle時,是給PCIe device的 ! )
[補充] For P2P bridge
P2P bridge = PCI-to-PCI bridge. 其存在可以 introduce 另一 new PCI bus,可以容納更多的 PCI device.
P2P bridge亦有其 PCI config space,但是 lauout 與 PCI device有點不同,大家可以參閱P2P spec並與PCI device's config space比較一下.
在 P2P config space中,我常遇到的 issue是和下列 register有關的:
- Primary bus register: offset 18h
- Secondary bus register: offset 19h
- Subordinate bus register: offset 1Ah
----------------------------------------
Notes:
這三個 registers是BIOS在 PCI_SCAN時會決定的;所代表的意義是:這個 P2P bridge的上面 PCI bus number is ? 下面的PCI bus number is ? 及包含此 P2P bridge的 "branch" 最深的 PCI bus number is ?
Ex. 18/19/1Ah of one P2P bridge is 0/2/3
=> 此 P2P bridge 是 "bridge" PCI bus 0 and 2的(橋接在 PCI bus 0 and 2之間);而包含此P2P bridge的 PCI branch(想像成 tree structure) 最大(深)的PCI bus number is 3
----------------------------------------
- memory base/limit
- IO base/limit
----------------------------------------
Notes:
這兩個是 BIOS 在 PCI_SCAN時所 assign的. 所代表的是: resource "window" for devices behind this bridge.意即:若P2P bridge下面(就上例言:是 Bus 2上)有 PCI devices,則他們的 BARs 必須被包含在此 window 之內 !!!
----------------------------------------
[Practice]
[Q]假設有一個 P2P bridge ,下面有一PCI device;現在必須要去 accessPCI device's Device ID/Vendor ID(that is, PCI config read). 但是,問題是:做這事的"點"要在 PCI_SCAN之"前"....那要如何做到呢 ^_^ ?
Ans:假如要在很早前(Ex. PCI SCAN之前)去 access P2P bridge後面的 device,照理是做不到的,因為: P2P bridge沒有被正確的 configed...
在此例中,P2P bridge的 primary/secondary/subordinate bus要被 set,後面的device才能被 accessed到 !
所以,假如要在 PCI SCAN前就 access,則BIOS必須手動去 set 此 3 bytes;然後,PCI config access才能被 forward to 其後的 PCI devices...
[Q] 如何 disable memory or IO resource window ?
Ans: 只要將 base設成比 limit "大" 即可 !!!
---------------
- 相關討論 Part1 -
---------------
前輩已經提到P2P Bridge我就直接問我的問題了
[Q1] Bridge 是用來擴充PCI Bus，在PCI Bus Spec與PCI-PCI Bridge Spec中定義，PCI Device是透過IDSEL來決定他的身分，其中PCI Bus Spec定義AD[31:11]，而PCI Bridge Spec定義AD[31:16] 當做IDSEL，這中間差異為何? 為什麼一個要從Bit 11開始當作是Dev 0 ，而另一個由Bit 16 才當作是 Dev 0 ?
Ans: 1. IDSEL對PCI device而言是 input,是用來當作 device's "chip-select"訊號. 而且,IDSEL "如何連接" 是 H/W決定的,BIOS無法決定.
假如將板子上某個device's IDSEL "割斷",則此 device將無法接受 PCI configuration read/write(以 ru.exe來說,就是按F6後,是看不到它的...)
那要如何決定 device's IDSEL ? 一般而言, board designer會將 "unused AD lines"拿來做 IDSEL,以連接至 PCI device.
在 configuration access時,所下的 Ex. "o cf8 80001020"(看起來是 I/O transaction)會被 host bridge轉成 configuration transaction;此時, host bridge即可判斷此 transaction 要 access的 device是否在該 PCI bus上;if YES 轉成 Type 0 transaction;If NO 轉成 Type 1 transaction,並往下發送...(host bridge只要 check latched "bus information"即可完成此判斷 !)
以 Type 0言,AD bus上的 format as follows:
bit[1:0] = 00 ( indicates "Type 0" )
bit[7:2] indicates register number
bit[10:8] indicates function number
那 Bus number ? Device number ?
=> Bus number不必知道 ! 因為:Type 0產生即代表 bus number = 現在的 bus #
=> Device number呢 ? 因為,此時(Config transaction && address phase) AD bus bit[31:11]沒人用 !!! 因此, board designer會把此 21 bits拿來做 IDSEL用 !
因此, AD bus bit11 <-> device 0
12 <-> device 1
.......
當然,不可能 21 bits都拿來接 PCI devices;因為電路上的現實考量...
.................以上為:我所知為何從 bit11開始來當作 IDSEL................
以 Type 1言,PCI-PCI bridge收到後,會將其 bus information與自己的 secondary bus number比較;若是 addressed device是在 secondary bus上,則將 Type 1 -> Type 0;若否,繼續包成Type 1往下一層送...
在P2P spec v1.1 page 22 有一張表,說明 IDSEL generation(from primary address -> secondary address),其中有提到: if primary address bit[15:11] =0,則 secondary address AD [31:16] = 0000 0000 0000 0001;以此類推.
所以,我覺得為什麼 for P2P bridge 其 IDSEL可由 bit[31:16] 來決定的原因在此 !!!(表的關係...)
.................以上為:我推論為何從 bit16開始來當作 IDSEL................
[補充]
PCI config index register裡面的資料其實和硬體解出configuration cycle是相關的.
一.轉換出來是type 0 cycle的話. 硬體只要做以下兩件事.
1. mask 掉bus number(bit 16 ~ 31)以上的部份.
2.解碼 device number的部份即可到對應的 AD bit. 所以其最低可以使用的就是AD11.也就是說一個bus上最多只能有 21個 devices(只是由於推動力問題, 往往是做不到的).
Note:其實也可以設計成其他大於AD 11開始, 這要看chip設計者決定了.
二. 轉換出來是type 1 cycle的話. 只要做
1. mask 掉reserved以上的部份(bit 24 ~31)
2. bit 0 = 1
由於P2P跟其他device不同的地方就是, 除了type 0 clcye以外, 還必須處理 type 1 cycle. 這也是分成兩部份
一. type 1 -> type 0. 當 bus number 等於 secondary bus number 時候出現.
1. 解碼 device number 到對應的 AD. spec中有提到轉換的表. dev 0 = AD16....etc
2. 把 bit 0 由1 變成 0
二. type 1-> type 1. 當 bus number 介於 secondary bus number和 subordinate bus number
1. 直接往下一層送即可.交給其他的P2P 處理.
[Q2] 在IA32下，CONFIG_ADDRESS 會被轉成Configuration Cycles，當Bus Number <>0 時，NB會轉成Type 1 然後往 DMI送到SB，當P2P Bridge收到後，然後定址到Slot上面的PCI Device，這樣說法對嗎?
Ans: 總而言之, 是自己local bus上的,就會轉成 Type 0,然後打在AD bus上,等待認領;若否就轉成 Type 1,往下一個bridge送,繼續尋找...對的人...for each bridge,都是一樣...
[補充]
對 PCI spec是, 如果以Intel PCI express架構來說. 那個已經被封裝成 pci express的 package了.沒有所謂的 type 0, type 1 cycle了.
[Q3]PCI Device透過IDSEL來決定身分，那PCIE Device呢? 我查過資料，好像PCIE不需要IDSEL那他是如何決定Device Number ?
Ans: 我所遇的 PCIe device也是由 AD bit[31:11]中找線拉至 device's IDSEL決定的.不知其他家 chipset是如何 implement.
[補充]
PCI express 是internal routing. PCI express是個跟PCI 完全不同的架構. 只是為了軟體相容性的關係, 把software架構做的跟PCI bus一樣. PCI express是point-to-point架構, 一個link 只會連接一個device. 跟PCI 這種可以多個device在同一bus上是不一樣的. 所以 device number對PCI express是完全不重要的.
Note. AMD的Hyper transport 也是基於一樣的心態來設計軟體架構的.
※ PCIe 的device是 internal routing. 以規格來看,下一層的 device number都是為0.
------------------
- 相關討論 Part 2 -
------------------
DMI指的是 Intel 南北橋中間的通道 ! 之前也是不知P2P bridge部份關於IDSEL的配置,查了表才知道原來有這樣的 mapping(primary address<->secondary address). 其實,可以說 "unused AD bus 會被拿來當 IDSEL用"就是了吧 ^_^
[補充]
是的, 只要軟體能夠知道routing 關係.怎麼接都可以. 只要bus controller控好實際的IDSEL即可. P2P之所以會有嚴格規定(兩項, 1. IDSEL&device number表, 2. secondary bus IRQ routing)是因為P2P 不一定是在板子上. 包含卡都可以有P2P bridge. 在板子上的P2P 可以靠BIOS來建立正確的 routing, 但是插卡不行. 所以必須把這些定義好. 這樣 PnP software(BIOS or OS)才能正確的完成IRQ 分配.讓卡正常工作. 所以如果觀察某些板廠. 就算是真的p2p 沒有存在在板子上, 很多PCI slot的IRQ routing都是依據p2p spec裡面的規定做(因為SB的PCI bus還是落在P2P之後).
在 PCI scan時,BIOS會掃描整個系統的PCI architecture(包含 device & bridge);其掃描方式由BIOS's PCI kernel來決定 !
[補充]
其實了解PCI spec. 要寫PCI scan其實可以效率好又正確. 常見的新進工程師寫法大概就是 3個 loop來處理. bus:0~255, device:0~31, function:0~7. 掃個 256*32*8次, 反正都是程式做, 結果往往也看來正確.這種寫法其實是不對的. (其實,若是多了解硬體的架構,就可以寫出有效率的code了 ! 這也是F/W工程師的價值...)
Ex. Assume 系統架構是這樣的: NB,P2Px3, PCIe bridge x2;其中:
A. 3 P2Ps的配置 is: P2P0下面接P2P1;P2P下面接P2P2
B. PCIe x 2 & P2P0都在 bus 0;其PFA為
NB(0,0,0)
P2P0(0,1,0)
PCIE0(0,4,0)
PCIE1(0,5,0)
=> 最後的 PCI achitecture is:
Bus 0----------------------
NB(0,0,0),P2P0(0,1,0),PCIE0(0,5,0),PCIE1(0,6,0)
*下面 Bus 1/2/3由 P2P0/1/2所 introduce:
Bus 1----------------------
P2P1(1,0,0)
Bus 2----------------------
P2P2(2,0,0)
Bus 3----------------------
*下面 Bus 4由 PCIE0所 introduce:
Bus 4----------------------
*下面 Bus 5由 PCIE1所 introduce:
Bus 5----------------------
所以,Bus number 是由BIOS's scanning "algorithm"所決定的;假如採用 depth-first,則會產生上述的結果 ! 決定後的值會填到 bridge的 Primary/secondary/subordinate bus number registers !
[Q]順便問個問題好了. 其實function number不應該是永遠需要scan的, 為什麼?什麼時候才需要scan function number?
Ans: 我想,對於 function number的問題,應該是: PCI header region offset 0Eh bit7代表: milti-function or NOT ! 因此,可以先 check此bit,再決定要不要往下掃了...這樣又少做了許多虛工...^_^
Ex. PFA (0,3,0) 有回應(that is, Vendor ID/Device ID != 0xFFFFFFFF),則先check (0,3,0)'s PCI Reg0Eh bit7; if "1" then 此device為 multi-function device,還要再往下找 Ex. (0,3,1~7) 有無回應;if "0" then try next device number...!
[補充，加快速的的方式]
檢查multi function bit是正確的, 但是不只是因為效率問題. 而是PCI 規格中, single function裝置可以不解碼 config cycle type 0 bit[8~10], 也就是說 一個 single function裝置, 會對 所有的function number回應, 也就是會出現 8 個相同的device.
順便說一下我的scan加速法. 其實我不是使用 vandor ID & device ID來判斷裝置存在與否. 我是用 class/subclass/interfae ID來作判斷. default 只scan bus 0, 遇到 P2P bridge才會把taget bus number+1, 如果遇到multi host(host bridge 數量> 1)的板子才會完整掃描 255個 bus. ^_^
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
~轉貼自艾克索夫實驗室~
Rootkit in PCI Option ROM
「Rootkit」一字來自 UNIX 界；但目前通常用於描述 Windows 木馬程式作者所運用的隱形技術。
起初，Rootkit指的是一組程式，可讓駭客躲過偵測。 為達成此目的，可執行的系統檔案 (如 login、ps、ls、netstat 等) 或系統程式庫 (libproc.a) 會遭到更換，或安裝核心模組。 這兩種動作只有一個相同目的；防止使用者收到正確資訊，知道電腦上發生了什麼事。
首先介紹PCI的基本常識, PCI Bus是在約1990年由Intel發展出來, 用來連接主機板上的各項裝置的匯流排標準, 後來成為業界的標準之一, Spec可以在PCI-SIG註冊會員之後下載, 架構上簡單的說, 就是一個Host bridge, 在一般的PC上通常指的就是North Brdige, 這個brdige後面就是bus#0(當然也有Multi Host-Bridge的狀況, 這邊舉例的是最單純的情況), 然後接到South Bridge, South Bridge之後可能接的是ISA Bus, IDE Controller, USB, IDE, DMA Controller等等, 如果bus#0上還有別的PCI Bridge, 這個Bridge後面就是bus#1, 如果有多個Bridge存在(PCI最多可以有256個bus), bus#就不一定是固定的了, 一個PCI Bus上可以有32個device, 每個device可以有8個function, 每個function都有屬於自己的256個register. 在PCI的規範裡, 256個register中的前0×40個是公定的功能, 從0×40到0xff則由各家廠商自行實作, 存取這些register的方法, 一般的PC上是透過IO port 0xCF8~0xCFF, 如果是新的PCI-Express則是直接透過Memory Mapped IO, 以存取記憶體的方式直接進行存取, 例如我們想要讀取一個在bus#0 dev#1 func#0的register#40~43, 透過IO的方式如下:
mov eax, (0x01 << 31 ) // Type-1 PCI Configuration
+ (0x00 << 16 ) // Bus#0
+ (0x01 << 11 ) // Device#1
+ (0x00 << 8 ) // Function#0
+ 0x40 // Register#40
mov dx, 0xCF8 // Index Port 0xCF8 ~ 0xCFB
out dx, eax
mov dx, 0xCFC // Data Port 0xCFC ~ 0xCFF
in eax, dx // Get Data in EAX
如果是透過MMIO的方式則簡單多了:
mov esi, (MMIO_BASE) + (0x00 << 20) + (0x01 << 15) + (0x00 << 12) + 0x40
mov eax, [esi]
今天我們比較有興趣的是位在0×30~0×33的register, 在PCI Spec定義中, 這裡的值存放的就是expansion rom在physical memory中被decode到IO的位址, 比如說這個位址是0xFE000000, 如果你在0×30把bit0設為0×1(io->mem decode), Command Register(0×04~0×05)的Memory Space Bit打開, 在0xFE000000的地方你就可以找到這個rom, 開頭是0×55AA(這當然也是規範之一, 用來辨視是否為一個PCI rom), BIOS在POST過程中, 會逐一掃描位於主機板上所有的PCI Device, 假如device上有rom, 就會把它給拷貝到memory中, 然後用jmp指令跳到ROM開頭offset 0×02(別忘了開頭offset 0×00是0×55AA)的地方開始執行PCI ROM, 執行完後ROM會再把控制權交回到BIOS手上, 一般而言, 在傳統記體空間中, 0xC0000~0xCFFFF是給VGA ROM用的, 0xD0000~0xEFFFF則是留給一般的PCI ROM使用, 當然各種情況下還是會有些許差異, 例如有些BIOS會保留0xE0000~0xFFFFF給自己使用, 像是BIOS的interrupt service, DMI data….等等雜七雜八的東西, 執行完的ROM仍然會保留在記憶體中, 因為有些ROM會修改IVT(Interrupt Vector Table), 將某些interrupt service導向自己的code, 像是VGA ROM可能就會hook int 0×10, 這是很合理的, 因為int 0×10是BIOS所提供用來控制螢幕的service, 聰明的你看到這裡應該就知道前面所提的那篇文章想說什麼了, 如果有個”惡意”的程式被埋在PCI ROM裡面, 只要一開機就會自動被執行, 它的運作並不是一時的, 它可以hook某個OS一定會用到的BIOS Interrupt Service, 然後在這個interrupt service被呼叫的時候動作就可以了, 而且麻煩的是即使你format你的HDD也沒用, 除非你把有問題的PCI Device從你的主機板上移除, 嗯….聽起來蠻炫的, 但是, 有可能嗎?
要回答這個問題之前, 需要知道一些基本的常識, 在保護模式下, 因為IO動作受到限制的關係, 要存取IO並不像在DOS那樣容易, 但如果想嘗試Re-flash一顆PCI ROM, 勢必得進行IO動作, 所幸在Windows下這並不是不可能的事, 有些人可能知道利用SeTcbPrivilege和使用ProcessUserModeIOPL structure呼叫undocumented Native API NtSetInformationProcess()就可以達成目的. 一旦攻擊者有辦法修改PCI ROM, 他就可以利用文章中所提到的例子: int 0×10(Windows在開機過程中會透過Ke386CallBios()呼叫int x010), 作他想作的任何事了.
可惜不論哪種攻擊方式, 最終都是要對OS kernel動手腳, 利用各種偵測工具(如: Archon Scanner), 一定可以找到有問題的地方, 如果最後的箭頭指向PCI ROM, 我們可以透過上文所述, 將存在PCI Device和memory中的ROM給dump出來, 需要dump兩邊的rom, 是因為PCI Spec規範中允許實際上所需要配置的記憶體不一定要等於原本rom的大小, 藉以節省保貴的記憶體(別忘了PCI ROM只能被配置到幾個64KB的segment裡而已), 然後向PCI Device的製造商索取正常版本的rom進行比對, 藉以得知是否為被修改的版本. 假如發現有不一樣的地方, 接下來可以朝幾個方向繼續分析是否為有問題的ROM, 我們可以檢查一下它是否修改了不必要的IVT, 像PXE ROM就不太可能hook int 0×10, 或是有保護模式相關的程式碼, 因為一般的ROM應該都是在real mode下執行, 所以應該不會切到protected mode, 如果有相關的程式碼那就非常可疑, 還有rom裡面是否有可疑的字串, 或是位在Windows Kernel位址空間裡的32-bit address, 另外ROM裡面也不太可能出現編碼過的code, 如果rom裡的code很難被disassemble, 或是充滿了一堆obfuscated code, 那也是很有問題.
除了軟體的方式, 最近興起的新技術TPM也能克制這種攻擊手法
星期四, 9月 27, 2007
[我所知道的BIOS]->[Jumpless] 4
上一篇所提到的是:BIOS entry point. 它是第一個被 CPU 所抓取並執行指令之處.每家BIOS都有其相應的 file,要牢記.
在本文中,要提及: Jumpless ! 在此要先說明Jumpless的意義.它代表:"用 s/w方式來 config clockgen generator,使之產生正確的 頻率s 來供應系統運作". 重要性在於:假如某個 frequency錯了,則將導致 system abnormal or malfunction...
有哪些 frequencies由 clockgen 提供?
- CPU clock (在此指的是 : host clock, Ex. FSB800 CPU 需被 supply 200MHz clock)
- DRAM clock( depends on chipset design; Ex. DDR 533要被 supply 266MHz clock)
更正 : DRAM clock現在都是由NB產生 . 外部的最多是 buffer而已. 並非 clock generator. 原因是為了保持較良好的 host clock & DRAM clock的同步.
補充:我舉的例子是以前的chipset design. 現在我做過的 chipset 其 DRAM clock的確由北橋來推. 北橋中有一會 register定義: CPU-DRAM ratio.
Ex. CPU clock = 100MHz. Ratio = 3:5,則可得 DRAM clock = 166MHz
- AGP clock: 標準 is 66.6MHz (= 1/2 PCI clock)
- PCI clock: 33.3MHz
- SATA clock: 100MHz(see SATA spec,似乎還要更精確...)
- Link clock: 即假如NB/SB中間有 link,亦由clockgen提供
- USB 1.1 clock: 12MHz
更正: USB 的 clock 是 48MHz
補充:我們 chipset的 design是: 由 clockgen提供 12MHz clock(或由 external crystal提供),被 PLL吃進去後,會產生 48MHz給 USB 1.1(你說的應該是這部分). 至於 USB 2.0,則是 supplied other freuencies !
- SIO clock...etc
Clock Generator的架構
=> ClockGen基本組成為 PLL(Phase Looked Loop) + Div. PLL 的輸入為 14.318MHz, 利用 迴授方式產生出 frequency F;之後 經過 Div 除頻,便得到 desired frequency,見下列圖示:
14.318MHz -> PLL -> F -> Div -> f
Ex. F = 400MHz, 為 PLL振出來的;若 Div = 4,則 f = 100MHz
ClockGen的 spec中,會列出許多 registers,好比是 Function 的 "contact window",透過這些 registers可以設定此clockgen !
更正:其實PLL 不是單純一個的 div. 鎖相迴路的參數是兩的divider 組成 M(VCO divider)/N(REF divider)
補充:觀念上來說是 PLL所振出的頻率經 div後可得到 desired frequency. 但在 clockgen中:
1. 有 2 bytes(即所謂的M,N)來決定 VCO
2. 有幾個 bits來決定 div;一些主要的 frequency都有相對應的div
3. VCO / div = frequency
How to access ClockGen
=>現今存取 clockgen的方式,都是透過 SMBUS來達成. SMBUS 有分 1.1 and 2.0,不過大同小異. SMBUS是 2-wire protocol;由 SMBUS master(即內建在南橋內部的 SMBUS controller )來下 command 給 SMBUS device(Ex. Clockgen);Command中常用的有 Block Read/Write & Byte Read/Write
不同家 chipset 的 SMBUS controller implement方式不同,自然下command的方式亦不同;主要的步驟是:
- pre-init( clear status or ...)
- put slave address(要 access 的對象)
- decide Read or Write
- put command(Protocol type, Ex. Block or Byte access)
- put offset(要存取 自 clockgen中的哪一個 Byte開始...)
- put data if (Write device)
- start transaction !!!
(... processing ...)
- get "Complete" status to check if transaction is done successfully
(...wait for system reset...)
* 當 start transaction後, SMBUS controller便會將 programmer所 prepare的資訊將之轉成 SMBUS command打給 device;完成後應該在 controller端有 status register可以檢查,看看是否 transaction ok or failed,或是有其他 error conditions.
透過這樣的方法,programmer便可以 config clockgen使之產生正確的 frequencies.
[2 Programming ways for clockgen]
=> 現今的 ClockGen有提供兩種方式 for S/W config. 一為 table mode,一為linear mode. Table mode指的是: ClockGen spec 中會有一個 table,裡面說明: 要產生 ? frequency 要填 ? 值.因此,這種方式只需program 1 byte to Clockgen就行了. 若是 linear mode,則是坊間所說的無段變頻,即可以微調frequency. Ex. table mode只提供 100/133/166/200MHz,但 linear mode則可以提供類似 102.6/136.3/168.7..等的頻率. 此時,要program的 byte數就很多了.....除此之外, linear mode也可以config 所謂的 spread spectrum(%),板廠測EMI時會用到
【Notes】
1. For NB platform power-on CPU frequency 由 2 pins來決定;DT platform會由 Jumper決定.不管如何,之後做Jumpless都可以 override掉原 clock settings
更正: 不是只有NB如此.不管DT 或server. CPU FSB 也是 pin(由於FSB頻率比NB多.所以是 3 pins )來決定的.不是jumper. 即使要做超頻設計會對這三pin做手腳, 也不會使用jumper
2. 有些 clockgen所提供的 SS 都是 center spread. 若需要 Down spread則可以由 center spread搭配 改變後的 frequency(類似直流準位)來達成
給我正確的頻率,其餘免談 ...^_^...
=====================================================================
Q&A
=====================================================================
>前輩我有幾個問題要發問!
>1. 你這邊說的Table方式頻率是指供應給CPU頻率嗎? Intel網站的CPU說明，他說是固定的不可調的? 所以這不是HW固定住(Latch)設定值了嗎?
>
>2. 可以解釋一下Down Spread/Center Spread /...所代表的意思嗎? 還有用途?
>
>3. 我目前也在嘗試Program ClcokGen(新手上路)，很多專有名詞還沒搞懂，另外目前ClockGen不是可以
>輸出不同頻率嗎? 為什麼Table方式只需要Program 1 byte就好 ???還是說各家廠商設定方式不同，有些廠
>商只要利用1 Byte 就已經選擇好所有的頻率了(33MHZ/48MHz/DOT96MHZ/LCD27MHZ...)?
[For #1]
=> 我所謂的 "Table"方式指的是: 為了方便設定,clockgen designer會專門提供一個byte register(8-bit);此 byte的某些 bit fields(Ex. bit[4:0])可以讓programmer填一組值,例如 01001b. 此值 write 至 clockgen成功後, CPU/DRAM/AGP/PCI/...etc 都會是固定的頻率. Ex. 100/133/66/33/...etc. 所以才說只填 1 byte only !
此值一旦填至 clockgen, clockgen便依據該 byte(可參考 spec前幾頁,會有一張表說明: bit[4:0] <-> frequency combinations)來產生出 frequencies.
不管用哪一種方式(table or linear mode),都會 supply CPU frequency !!!不過,此時的 CPU frequency is CPU的外頻 ( CPU 總頻率(core) = (外頻)*(倍頻 <-multiplier) )
Ex. 外頻 200MHz(Merom CPU, FSB 800),倍頻 = 12 -> core freq = 2.4GHz
還有,BIOS可以調整 外頻 & 倍頻 ! 沒問題 ! 不過,若遇到鎖頻的CPU(Ex. 量產版的CPU),倍頻可能無法調整.但外頻還是可以靠 config clockgen來達到 !!!
For #2
=> 假設要達到 100MHz 且 SS = 0.5% center spread.則:
(...想像以前學的直流與交流的訊號...)
100MHz 相當於 直流的部分,其值不隨時間而變; 0.5% center spread好比弦波訊號(振幅是 100M * 0.005 * (1/2);所以,兩者的合成便是: 以 100MHz為中心,其值隨時間而變,振幅 is 100M * 0.005 * (1/2) 的訊號 !!!
我 '猜' 要這樣測試的原因是:所產生的 clock一定不會是 perfect的 100MHz,有可能因為元件或是外部干擾而被 "改變".為了模擬這樣的情況,我們會將 clock的 spread spectrum enable,產生 "隨時間而改變"的頻率,來測試系統的穩定度...等
Down spread 0.5% 指的是:距離 水平 100MHz, 最低的值是 100M-100M*0.005,最高值則是 100M本身( 等同於: 水平值 99.5 + center spread 0.5%, right ? )
For #3
=> 前面提過,只設 1 byte 就可以產生所有頻率是因為: clockgen公司已經把設定各頻率的功能"濃縮"在一個 byte裡面 ; programmer只要 config this byte 就可以了...
* 關於 EMI 測試部分,有錯請指正. ( ...我有用到 "猜" 字眼...^_^ )
[[EMI 測試的知識]]
由於 對clock信號來說. 鋒(peak)值是能量最強的地方. 所以peak的能量就會不斷累積, 發射出來. 因此在頻譜上就會出現能量很強的頻率. EMI 工程師的工作就是要想辦法屏閉這些電磁波的干擾.
為什麼需要 spread spectrum? 由於PLL 十分精準. 也就是說 100MHz的clock, 其 peak & peak之間的距離一致(波長固定). 所以能量十分驚人. 使用展頻可以使 peak 的距離改變(由於頻率不斷的在一個範圍內改變, 這個可以用示波器累積clock信號來看) 所以累積的能量會比較低. 這樣EMI 可以比較好處理.
至於為什麼會有要求BIOS一開始就把展頻開著, 以確保板子的穩定? 很簡單.不開展頻clock很穩定.自然比較不會有問題. 展頻一開. 由於頻率是浮動的. 很多設計欠佳的板子就會不穩定. 及早發現才能及早修改.
[[補充資料~~運作原理]]
CPU本身有預設值的BSEL[2:0]值，這個值是與Clockgen所產生的BCLK是對應的，CPU本身Spec會有一個Table定義這個值，然後CPU透過BSEL[2:0](輸出pin) 連接到Clockgen與NB(這兩個都是輸入pin)，所以當Power on的時候，Clcokgen會依照CPU預設的BSEL[2:0]去產生BCLK給CPU，而FSB 頻率也是經由CPU接到NB的BSEL[2:0] 來同步(一般都是1/4 CLK 提取一次資料，所以假設BCLK=200MHZ ，而Clockgen輸出到NB的Host Clk=200MHz，一般都會同步，所以 FSB=Host clk*4 = 800MHZ)
※ Clockgen 分別透過BCLK與HostClk pins輸出頻率給CPU與NB
然後CPU開始執行BIOS Code，當執行到Program Clockgen時，BIOS可以透過Clockgen內的暫存器的某個Byte 內的FSC/FSB/FSA 這3個bit 來改變BCLK輸出頻率(應該可看作override BSEL[2:0]設定)，當CPU接收到新的BCLK頻率後可能的反應有:
1. CPU本身不支援這個BCLK所以系統當機或是Shutdown
2. CPU 可工作在這個BCLK頻率，依照這個頻率對照Table，然後改變BSEL[2:0]的設定
另外CPU 是否能工作在266Mhz or 200Mhz or both，這部份依照每顆CPU不同而有所不同，有些CPU只能工作在266Mhz，所以當BLCK=200Mhz時，CPU就不會工作。
假設CPU可工作在266Mhz與200Mhz，則當BCLK從200MHZ-->266Mhz時，CPU一樣可以工作。
還有CPU內部的調整ratio的MSR暫存器可分成測試版的CPU跟出貨版CPU的不同：
a)測試版CPU的Ratio可調，如何調要看Spec
b)出貨版CPU不可調，也就是鎖倍頻
---------------------------------------------------------------
1. Clockgen 會送兩組 differential-pair clocks給 CPU & NB. 目前這兩組 clocks是相同的頻率.
2. CPU有兩 pins 稱 BCLK[1:0]. Input.
NB HostClk[1:0]. Input
* bit[1:0] 是代表: differential-pair clock都會有 2 clocks,分別是 true clock and complementary clock
3. 開機時的 behavior 是:
1) CPU內部自己會產生一組 default BSEL[2:0] 給 Clockgen的 FSC/B/A (依據經驗,這組 default 值 可以由 CPU MSR 得到 ; 也等於這顆CPU所能支援的最大外頻,BCLK)
2) Clockgen據此 FSC/B/A會產生對應的頻率,送給 CPU 的 pins BCLK[1:0]
Ex. 266MHz
3) 之後,若有需要, BIOS可以透過 config FSC/B/A 或是 M/N programming(透過clockgen內部的暫存器)來 "override"掉原來的 clock setting以達到改變 BCLK的目的.
------------------------------------------------------------------
CPU 工作頻率=外頻 (BCLK)* 倍頻(MSR調整)
FSB 頻寬= CPU Spec說由 BSEL[2:0] "同步決定"，但是看Clockgen電路有分成，BCLK與HostClk(兩者應該輸出同樣頻率) 所以應該是北橋拿HostClk當參考，每1/4 Clk提取一次Data，所以應該是HostClk * 4
以前FSB頻寬=FSB工作頻率，所以有人把CPU工作頻率計算方式看作 " FSB頻率 * 倍頻 "，但是由於FSB頻寬目前已經不等於FSB 工作頻率，且Clockgen 分別拉了兩組pins(BCLK與HostClk)給CPU以及北橋，所以計算CPU工作頻率的方式才會變成目前的 "BCLK * 倍頻"
加註:
1. FSB1066指的是: bandwidth ! 不是頻率. 一般不會說 FSB266,而會說 host clock = 266MHz !
2. *4 應該是因為 ( clock的上下緣都可以觸發 ) + ( differential-pair) 的關係
我先解釋一下這三pin,就我印象中除了之前 NV chip + K7 和 SiS的chipset以外.
CPU 的FS0, FS1, FS2會接到clockgen (FSA,B,C)和NB (BSEL0,1,2)的對應pin.
CPU 是負責產生準位, clockgen & NB 會在自己的powerok ready的時候把資料latch進去.
clockgen 除了利用這三pin來產生對應頻率的CPU clock外, 另外也會根據這個頻率來產生合適的PCI-E, PCI clock..., 而北橋則是利用來產生正確的 DRAM clock(host/dram ratio),對intel來說也有PCI-E的同步關係.
至於超頻跟這三pin 的關係, 我稍微解說一下.一般而言要超頻的話, MB 必須把到NB & clockgen的路徑斷開, 由另外設計的線路來取代CPU的FS0,1,2.也就是說NB & clockgen 一開機必須收到一個由這個控制線路決定的FSB. 這樣才能作所謂的 133-> 200 or 200 -> 266的大幅度超頻.因為此時NB 和 clockgen 才會正確的分配. 別忘了NB, SB, PCI-E, PCI, DRAM是沒有CPU這麼強的超頻力. 直接利用軟體改變clockgen會造成很多不該變化的頻率跟著變.
Note:此超頻線路, default是一個所有CPU都能開的安全值, 一但BIOS完成設定, 就會latch住資料
此外還必須配合watchdog 來處理過度超頻不能開機的問題. linear mode只用來處理小超頻的部份
以前遇到的 clockgen 是 CPU & DRAM clocks 由同一個 PLL決定,其餘 clocks由另一個PLL決定. 當時有寫一個OS下的小程式,可以微調 CPU頻率(以1MHz為單位). 不過,微調CPU的同時也會微調到DRAM clock(<-同一個PLL),只是微調值不同(depends on divider).
現在遇到的 clockgen + chipset design 是: CPU由一PLL供給,而DRAM clock由北橋推.同樣的,微調CPU clock一樣牽動DRAM clock.
至於其它 frequencies是否會跟著變, depends on Clockgen design;現在的clockgen幾乎都有 2以上的PLLs;所以類似PCI/AGP/SATA clocks都會有專門的 PLL控制. 而CPU則由另一個PLL控制.
有興趣及時間的人可以試試看 M/N programming(小微調). 看著 (Ex. FSB800 CPU)由200MHz 操到 210MHz,也是一種快樂 ^_^
Q: 這邊剛好有提到watchdog...想請問一下前輩這個東西在PC系統上是何時開始使用? 用途為何或是應用為何? 以前學校沒看到過這個東西，不過我在嵌入式系統常看到一些應用，另外在南橋Spec有看到過，而BIOS端需要如何去應用以及設定它? 另外使用 watchdog 來處理過度超頻不能開機是怎樣的一個方式? 頻率不對，CPU已經無法work，連BIOS code都不能執行了? 所以他是靠HW去處理嗎?
A:我曾用過關於watchdog timer 的經驗是 => 在 config clockgen完後, 需要 system發 PCI reset ! 此時會需要 watchdog timer...
因為, write clockgen完後,有可能系統當掉 !!! (<-frequency settings被改變了...)因此,我知道的作法是: 在 write clockgen之前,先 enable watchdog timer ! (當然,一定會指明要"多少時間後"才發 PCI reset ! ) 一 enable完,便匆匆去 write clockgen(當然,這段時間要夠長,以免 write clockgen沒完成,PCI reset就出來了 >_< ).
一旦 write clockgen完畢,code會寫 "jmp $"...然後等 watchdog timer 時間到,然後PCI reset出來 reset system...
你所說當機時的 watchdog timer,我沒做過 ! 不過,watchdog timer 不一定是要在 SB內啊!(或是即使做在 SB內,也是"獨立的"...)做成外部的電路就不怕 chipset hang時 timer會失效了...^_^
一般我知道的 watchdog timer control 大概有:
- enable/disable ( => 開始記時...)
- time to bomb (=>多少時間後爆炸 ?)
- event routing ( => 時間到要幹嘛 ?)
[[WatchDog]]
watchdog是個硬體機制.
watchdog 在嵌入式應用中主要就是用來做系統自動回復用的.通常用在機器處理很critical 的任務, 不能當機超過一定時間的事務. 一般的用法是, 系統的軟體要固定時間去重設timer. 例如: watchdog timer 設定10秒以後會重置系統, 那麼系統軟體可以每5秒有一個task 去重設timer. 萬一系統當機了. 由於軟體無法重設timer. timer 數完了以後就會發出reset , 讓系統重新恢復狀態. 在MB 中superI/O 有watchdog, clockgen 也有支援watchdog. 以超頻來說, 往往設定完clock generator的瞬間, 系統可能會當機. 這時有兩種狀況. 1. 因為clock 變化造成, 這種狀況只要一個PCI reset. 系統就可以繼續執行. 這時BIOS 可以借用 watchdog來發PCI reset. 只要在定clock之前先設好watchdog timer, 然後在一段時間後關掉watchdog timer. 這樣就可以解決這個問題. 一種是 clock 增加太多造成chip 死當. 這種就需要依靠 clock gen 裡面的watch dog來讓clock 回復成default value(Note:要視clock gen的設計, 有些只是發reset而已).
另外一種我知道的應用是雙 BIOS的主板. 利用watchdog來切換BIOS.
在本文中,要提及: Jumpless ! 在此要先說明Jumpless的意義.它代表:"用 s/w方式來 config clockgen generator,使之產生正確的 頻率s 來供應系統運作". 重要性在於:假如某個 frequency錯了,則將導致 system abnormal or malfunction...
有哪些 frequencies由 clockgen 提供?
- CPU clock (在此指的是 : host clock, Ex. FSB800 CPU 需被 supply 200MHz clock)
- DRAM clock( depends on chipset design; Ex. DDR 533要被 supply 266MHz clock)
更正 : DRAM clock現在都是由NB產生 . 外部的最多是 buffer而已. 並非 clock generator. 原因是為了保持較良好的 host clock & DRAM clock的同步.
補充:我舉的例子是以前的chipset design. 現在我做過的 chipset 其 DRAM clock的確由北橋來推. 北橋中有一會 register定義: CPU-DRAM ratio.
Ex. CPU clock = 100MHz. Ratio = 3:5,則可得 DRAM clock = 166MHz
- AGP clock: 標準 is 66.6MHz (= 1/2 PCI clock)
- PCI clock: 33.3MHz
- SATA clock: 100MHz(see SATA spec,似乎還要更精確...)
- Link clock: 即假如NB/SB中間有 link,亦由clockgen提供
- USB 1.1 clock: 12MHz
更正: USB 的 clock 是 48MHz
補充:我們 chipset的 design是: 由 clockgen提供 12MHz clock(或由 external crystal提供),被 PLL吃進去後,會產生 48MHz給 USB 1.1(你說的應該是這部分). 至於 USB 2.0,則是 supplied other freuencies !
- SIO clock...etc
Clock Generator的架構
=> ClockGen基本組成為 PLL(Phase Looked Loop) + Div. PLL 的輸入為 14.318MHz, 利用 迴授方式產生出 frequency F;之後 經過 Div 除頻,便得到 desired frequency,見下列圖示:
14.318MHz -> PLL -> F -> Div -> f
Ex. F = 400MHz, 為 PLL振出來的;若 Div = 4,則 f = 100MHz
ClockGen的 spec中,會列出許多 registers,好比是 Function 的 "contact window",透過這些 registers可以設定此clockgen !
更正:其實PLL 不是單純一個的 div. 鎖相迴路的參數是兩的divider 組成 M(VCO divider)/N(REF divider)
補充:觀念上來說是 PLL所振出的頻率經 div後可得到 desired frequency. 但在 clockgen中:
1. 有 2 bytes(即所謂的M,N)來決定 VCO
2. 有幾個 bits來決定 div;一些主要的 frequency都有相對應的div
3. VCO / div = frequency
How to access ClockGen
=>現今存取 clockgen的方式,都是透過 SMBUS來達成. SMBUS 有分 1.1 and 2.0,不過大同小異. SMBUS是 2-wire protocol;由 SMBUS master(即內建在南橋內部的 SMBUS controller )來下 command 給 SMBUS device(Ex. Clockgen);Command中常用的有 Block Read/Write & Byte Read/Write
不同家 chipset 的 SMBUS controller implement方式不同,自然下command的方式亦不同;主要的步驟是:
- pre-init( clear status or ...)
- put slave address(要 access 的對象)
- decide Read or Write
- put command(Protocol type, Ex. Block or Byte access)
- put offset(要存取 自 clockgen中的哪一個 Byte開始...)
- put data if (Write device)
- start transaction !!!
(... processing ...)
- get "Complete" status to check if transaction is done successfully
(...wait for system reset...)
* 當 start transaction後, SMBUS controller便會將 programmer所 prepare的資訊將之轉成 SMBUS command打給 device;完成後應該在 controller端有 status register可以檢查,看看是否 transaction ok or failed,或是有其他 error conditions.
透過這樣的方法,programmer便可以 config clockgen使之產生正確的 frequencies.
[2 Programming ways for clockgen]
=> 現今的 ClockGen有提供兩種方式 for S/W config. 一為 table mode,一為linear mode. Table mode指的是: ClockGen spec 中會有一個 table,裡面說明: 要產生 ? frequency 要填 ? 值.因此,這種方式只需program 1 byte to Clockgen就行了. 若是 linear mode,則是坊間所說的無段變頻,即可以微調frequency. Ex. table mode只提供 100/133/166/200MHz,但 linear mode則可以提供類似 102.6/136.3/168.7..等的頻率. 此時,要program的 byte數就很多了.....除此之外, linear mode也可以config 所謂的 spread spectrum(%),板廠測EMI時會用到
【Notes】
1. For NB platform power-on CPU frequency 由 2 pins來決定;DT platform會由 Jumper決定.不管如何,之後做Jumpless都可以 override掉原 clock settings
更正: 不是只有NB如此.不管DT 或server. CPU FSB 也是 pin(由於FSB頻率比NB多.所以是 3 pins )來決定的.不是jumper. 即使要做超頻設計會對這三pin做手腳, 也不會使用jumper
2. 有些 clockgen所提供的 SS 都是 center spread. 若需要 Down spread則可以由 center spread搭配 改變後的 frequency(類似直流準位)來達成
=====================================================================
Q&A
=====================================================================
>前輩我有幾個問題要發問!
>1. 你這邊說的Table方式頻率是指供應給CPU頻率嗎? Intel網站的CPU說明，他說是固定的不可調的? 所以這不是HW固定住(Latch)設定值了嗎?
>
>2. 可以解釋一下Down Spread/Center Spread /...所代表的意思嗎? 還有用途?
>
>3. 我目前也在嘗試Program ClcokGen(新手上路)，很多專有名詞還沒搞懂，另外目前ClockGen不是可以
>輸出不同頻率嗎? 為什麼Table方式只需要Program 1 byte就好 ???還是說各家廠商設定方式不同，有些廠
>商只要利用1 Byte 就已經選擇好所有的頻率了(33MHZ/48MHz/DOT96MHZ/LCD27MHZ...)?
[For #1]
=> 我所謂的 "Table"方式指的是: 為了方便設定,clockgen designer會專門提供一個byte register(8-bit);此 byte的某些 bit fields(Ex. bit[4:0])可以讓programmer填一組值,例如 01001b. 此值 write 至 clockgen成功後, CPU/DRAM/AGP/PCI/...etc 都會是固定的頻率. Ex. 100/133/66/33/...etc. 所以才說只填 1 byte only !
此值一旦填至 clockgen, clockgen便依據該 byte(可參考 spec前幾頁,會有一張表說明: bit[4:0] <-> frequency combinations)來產生出 frequencies.
不管用哪一種方式(table or linear mode),都會 supply CPU frequency !!!不過,此時的 CPU frequency is CPU的外頻 ( CPU 總頻率(core) = (外頻)*(倍頻 <-multiplier) )
Ex. 外頻 200MHz(Merom CPU, FSB 800),倍頻 = 12 -> core freq = 2.4GHz
還有,BIOS可以調整 外頻 & 倍頻 ! 沒問題 ! 不過,若遇到鎖頻的CPU(Ex. 量產版的CPU),倍頻可能無法調整.但外頻還是可以靠 config clockgen來達到 !!!
For #2
=> 假設要達到 100MHz 且 SS = 0.5% center spread.則:
(...想像以前學的直流與交流的訊號...)
100MHz 相當於 直流的部分,其值不隨時間而變; 0.5% center spread好比弦波訊號(振幅是 100M * 0.005 * (1/2);所以,兩者的合成便是: 以 100MHz為中心,其值隨時間而變,振幅 is 100M * 0.005 * (1/2) 的訊號 !!!
我 '猜' 要這樣測試的原因是:所產生的 clock一定不會是 perfect的 100MHz,有可能因為元件或是外部干擾而被 "改變".為了模擬這樣的情況,我們會將 clock的 spread spectrum enable,產生 "隨時間而改變"的頻率,來測試系統的穩定度...等
Down spread 0.5% 指的是:距離 水平 100MHz, 最低的值是 100M-100M*0.005,最高值則是 100M本身( 等同於: 水平值 99.5 + center spread 0.5%, right ? )
For #3
=> 前面提過,只設 1 byte 就可以產生所有頻率是因為: clockgen公司已經把設定各頻率的功能"濃縮"在一個 byte裡面 ; programmer只要 config this byte 就可以了...
* 關於 EMI 測試部分,有錯請指正. ( ...我有用到 "猜" 字眼...^_^ )
[[EMI 測試的知識]]
由於 對clock信號來說. 鋒(peak)值是能量最強的地方. 所以peak的能量就會不斷累積, 發射出來. 因此在頻譜上就會出現能量很強的頻率. EMI 工程師的工作就是要想辦法屏閉這些電磁波的干擾.
為什麼需要 spread spectrum? 由於PLL 十分精準. 也就是說 100MHz的clock, 其 peak & peak之間的距離一致(波長固定). 所以能量十分驚人. 使用展頻可以使 peak 的距離改變(由於頻率不斷的在一個範圍內改變, 這個可以用示波器累積clock信號來看) 所以累積的能量會比較低. 這樣EMI 可以比較好處理.
至於為什麼會有要求BIOS一開始就把展頻開著, 以確保板子的穩定? 很簡單.不開展頻clock很穩定.自然比較不會有問題. 展頻一開. 由於頻率是浮動的. 很多設計欠佳的板子就會不穩定. 及早發現才能及早修改.
[[補充資料~~運作原理]]
CPU本身有預設值的BSEL[2:0]值，這個值是與Clockgen所產生的BCLK是對應的，CPU本身Spec會有一個Table定義這個值，然後CPU透過BSEL[2:0](輸出pin) 連接到Clockgen與NB(這兩個都是輸入pin)，所以當Power on的時候，Clcokgen會依照CPU預設的BSEL[2:0]去產生BCLK給CPU，而FSB 頻率也是經由CPU接到NB的BSEL[2:0] 來同步(一般都是1/4 CLK 提取一次資料，所以假設BCLK=200MHZ ，而Clockgen輸出到NB的Host Clk=200MHz，一般都會同步，所以 FSB=Host clk*4 = 800MHZ)
※ Clockgen 分別透過BCLK與HostClk pins輸出頻率給CPU與NB
然後CPU開始執行BIOS Code，當執行到Program Clockgen時，BIOS可以透過Clockgen內的暫存器的某個Byte 內的FSC/FSB/FSA 這3個bit 來改變BCLK輸出頻率(應該可看作override BSEL[2:0]設定)，當CPU接收到新的BCLK頻率後可能的反應有:
1. CPU本身不支援這個BCLK所以系統當機或是Shutdown
2. CPU 可工作在這個BCLK頻率，依照這個頻率對照Table，然後改變BSEL[2:0]的設定
另外CPU 是否能工作在266Mhz or 200Mhz or both，這部份依照每顆CPU不同而有所不同，有些CPU只能工作在266Mhz，所以當BLCK=200Mhz時，CPU就不會工作。
假設CPU可工作在266Mhz與200Mhz，則當BCLK從200MHZ-->266Mhz時，CPU一樣可以工作。
還有CPU內部的調整ratio的MSR暫存器可分成測試版的CPU跟出貨版CPU的不同：
a)測試版CPU的Ratio可調，如何調要看Spec
b)出貨版CPU不可調，也就是鎖倍頻
---------------------------------------------------------------
1. Clockgen 會送兩組 differential-pair clocks給 CPU & NB. 目前這兩組 clocks是相同的頻率.
2. CPU有兩 pins 稱 BCLK[1:0]. Input.
NB HostClk[1:0]. Input
* bit[1:0] 是代表: differential-pair clock都會有 2 clocks,分別是 true clock and complementary clock
3. 開機時的 behavior 是:
1) CPU內部自己會產生一組 default BSEL[2:0] 給 Clockgen的 FSC/B/A (依據經驗,這組 default 值 可以由 CPU MSR 得到 ; 也等於這顆CPU所能支援的最大外頻,BCLK)
2) Clockgen據此 FSC/B/A會產生對應的頻率,送給 CPU 的 pins BCLK[1:0]
Ex. 266MHz
3) 之後,若有需要, BIOS可以透過 config FSC/B/A 或是 M/N programming(透過clockgen內部的暫存器)來 "override"掉原來的 clock setting以達到改變 BCLK的目的.
------------------------------------------------------------------
CPU 工作頻率=外頻 (BCLK)* 倍頻(MSR調整)
FSB 頻寬= CPU Spec說由 BSEL[2:0] "同步決定"，但是看Clockgen電路有分成，BCLK與HostClk(兩者應該輸出同樣頻率) 所以應該是北橋拿HostClk當參考，每1/4 Clk提取一次Data，所以應該是HostClk * 4
以前FSB頻寬=FSB工作頻率，所以有人把CPU工作頻率計算方式看作 " FSB頻率 * 倍頻 "，但是由於FSB頻寬目前已經不等於FSB 工作頻率，且Clockgen 分別拉了兩組pins(BCLK與HostClk)給CPU以及北橋，所以計算CPU工作頻率的方式才會變成目前的 "BCLK * 倍頻"
加註:
1. FSB1066指的是: bandwidth ! 不是頻率. 一般不會說 FSB266,而會說 host clock = 266MHz !
2. *4 應該是因為 ( clock的上下緣都可以觸發 ) + ( differential-pair) 的關係
我先解釋一下這三pin,就我印象中除了之前 NV chip + K7 和 SiS的chipset以外.
CPU 的FS0, FS1, FS2會接到clockgen (FSA,B,C)和NB (BSEL0,1,2)的對應pin.
CPU 是負責產生準位, clockgen & NB 會在自己的powerok ready的時候把資料latch進去.
clockgen 除了利用這三pin來產生對應頻率的CPU clock外, 另外也會根據這個頻率來產生合適的PCI-E, PCI clock..., 而北橋則是利用來產生正確的 DRAM clock(host/dram ratio),對intel來說也有PCI-E的同步關係.
至於超頻跟這三pin 的關係, 我稍微解說一下.一般而言要超頻的話, MB 必須把到NB & clockgen的路徑斷開, 由另外設計的線路來取代CPU的FS0,1,2.也就是說NB & clockgen 一開機必須收到一個由這個控制線路決定的FSB. 這樣才能作所謂的 133-> 200 or 200 -> 266的大幅度超頻.因為此時NB 和 clockgen 才會正確的分配. 別忘了NB, SB, PCI-E, PCI, DRAM是沒有CPU這麼強的超頻力. 直接利用軟體改變clockgen會造成很多不該變化的頻率跟著變.
Note:此超頻線路, default是一個所有CPU都能開的安全值, 一但BIOS完成設定, 就會latch住資料
此外還必須配合watchdog 來處理過度超頻不能開機的問題. linear mode只用來處理小超頻的部份
以前遇到的 clockgen 是 CPU & DRAM clocks 由同一個 PLL決定,其餘 clocks由另一個PLL決定. 當時有寫一個OS下的小程式,可以微調 CPU頻率(以1MHz為單位). 不過,微調CPU的同時也會微調到DRAM clock(<-同一個PLL),只是微調值不同(depends on divider).
現在遇到的 clockgen + chipset design 是: CPU由一PLL供給,而DRAM clock由北橋推.同樣的,微調CPU clock一樣牽動DRAM clock.
至於其它 frequencies是否會跟著變, depends on Clockgen design;現在的clockgen幾乎都有 2以上的PLLs;所以類似PCI/AGP/SATA clocks都會有專門的 PLL控制. 而CPU則由另一個PLL控制.
有興趣及時間的人可以試試看 M/N programming(小微調). 看著 (Ex. FSB800 CPU)由200MHz 操到 210MHz,也是一種快樂 ^_^
Q: 這邊剛好有提到watchdog...想請問一下前輩這個東西在PC系統上是何時開始使用? 用途為何或是應用為何? 以前學校沒看到過這個東西，不過我在嵌入式系統常看到一些應用，另外在南橋Spec有看到過，而BIOS端需要如何去應用以及設定它? 另外使用 watchdog 來處理過度超頻不能開機是怎樣的一個方式? 頻率不對，CPU已經無法work，連BIOS code都不能執行了? 所以他是靠HW去處理嗎?
A:我曾用過關於watchdog timer 的經驗是 => 在 config clockgen完後, 需要 system發 PCI reset ! 此時會需要 watchdog timer...
因為, write clockgen完後,有可能系統當掉 !!! (<-frequency settings被改變了...)因此,我知道的作法是: 在 write clockgen之前,先 enable watchdog timer ! (當然,一定會指明要"多少時間後"才發 PCI reset ! ) 一 enable完,便匆匆去 write clockgen(當然,這段時間要夠長,以免 write clockgen沒完成,PCI reset就出來了 >_< ).
一旦 write clockgen完畢,code會寫 "jmp $"...然後等 watchdog timer 時間到,然後PCI reset出來 reset system...
你所說當機時的 watchdog timer,我沒做過 ! 不過,watchdog timer 不一定是要在 SB內啊!(或是即使做在 SB內,也是"獨立的"...)做成外部的電路就不怕 chipset hang時 timer會失效了...^_^
一般我知道的 watchdog timer control 大概有:
- enable/disable ( => 開始記時...)
- time to bomb (=>多少時間後爆炸 ?)
- event routing ( => 時間到要幹嘛 ?)
[[WatchDog]]
watchdog是個硬體機制.
watchdog 在嵌入式應用中主要就是用來做系統自動回復用的.通常用在機器處理很critical 的任務, 不能當機超過一定時間的事務. 一般的用法是, 系統的軟體要固定時間去重設timer. 例如: watchdog timer 設定10秒以後會重置系統, 那麼系統軟體可以每5秒有一個task 去重設timer. 萬一系統當機了. 由於軟體無法重設timer. timer 數完了以後就會發出reset , 讓系統重新恢復狀態. 在MB 中superI/O 有watchdog, clockgen 也有支援watchdog. 以超頻來說, 往往設定完clock generator的瞬間, 系統可能會當機. 這時有兩種狀況. 1. 因為clock 變化造成, 這種狀況只要一個PCI reset. 系統就可以繼續執行. 這時BIOS 可以借用 watchdog來發PCI reset. 只要在定clock之前先設好watchdog timer, 然後在一段時間後關掉watchdog timer. 這樣就可以解決這個問題. 一種是 clock 增加太多造成chip 死當. 這種就需要依靠 clock gen 裡面的watch dog來讓clock 回復成default value(Note:要視clock gen的設計, 有些只是發reset而已).
另外一種我知道的應用是雙 BIOS的主板. 利用watchdog來切換BIOS.
星期二, 10月 16, 2007
[我所知道的BIOS]->[VGA init] 10
一般而言,BIOS會在POST時 locate 3 devices:
- Input device(Ex. Keyboard)
- Output device(Ex. Display device)
- IPL(Initial Program Load, Ex. HDD)
這次要提到的是 Display device,即 VGA !
在PCI_SCAN之後,BIOS會在記憶體中建立一個data structure,代表整個系統的 PCI architecture.
Ex. Ponter-> NB->P2P->SB->IDE->AUDIO->LAN->USB 2.0->USB 1.1->...->VGA->...->End
在VGA_init的階段,BIOS會去 go-through this list,一個個的問:"有沒有人需要shadow Option ROM的 ?"
-------------------------------
*1 在此,先break,並說明一些觀念:
1. Option ROM是 for H/W的 firmware;像BIOS一樣是 for MB.有可能直接在硬體上 ,or 包在BIOS image中
2. 有Option ROM的 H/W可能有: VGA card,Lan card, RAID card,...etc
3. VGA's Option ROM 也就是 VBIOS ! 專門處理 screen I/O operation(主要是int10h)
4. VGA "shadow" 即代表: 將 VBIOS copy 到 shadow RAM, Ex. C0000h~C7FFFh處(32K)
5. VGA init這個階段只 consider "VGA device" ! for 其他 device,之後再考慮其 shadow的事宜
-------------------------------
(承接前面的 flow):此時,VGA device會舉手說:"我要" !此時,BIOS會去尋找VGA device's Option ROM(即VBIOS)在哪裡;此時,VBIOS有可能在card上 or "當初" 被包在 BIOS image中(*2)
一但找到,則會先 作一些 checks:Ex.
- Option ROM signature is 0xAA55 ?
- 比較 Option ROM內的 Vendor ID/Device ID = H/W's IDs ?
- class code and sub-class code correct ?
- length = 0 ?
...etc...
若都符合,則視它為 VGA Option ROM(VBIOS) ! 之後,利用 memory2memory copy將之 copy到 shadow memory,從 C0000h處開始存放...
複製完後,再 check "checksum"是否正確;if yes then jump to "entry of initialization code",控制權自此轉移至 VGA Option ROM,由它去做 initialize VGA的工作 ! ( 若是CRT螢幕,user會聽到ㄉ一ㄤ的一聲 ! 即代表 initialize VGA成功 !!! )
<- 此為 VGA_init的工作 !!!
*2 說"當初"的原因是: VGA BIOS若包在BIOS image中,在 BIOS shadow時,也會被一併 copy到記憶體的某處放著;當然,會記住存放處 !
[Note] 一般遇到 VGA init fail的issue時,可以先 check:是否 VGA BIOS已被 copy 至 C0000h處;若有,則check是否已經 jump to VBIOS or NOT;若否,則可以往前 check是否前面所列的一些 "關卡"沒過 (Ex. ID不 match, or checksum 不相等...etc )
VGA 若 ok,電腦就是彩色的 ^_^
---------------------------
- 相關討論 -----------------
---------------------------
通常都是板子一來就會去開始Debug VGA...
VBIOS 若壞，螢幕是黑ㄟ
VBIOS若好，螢幕是彩色ㄟ
沒螢幕的情況下要繼續Porting BIOS就比較麻煩一點
[Q]Option ROM是 for H/W的 firmware;像BIOS一樣是 for MB.有可能直接在硬體上 ,or 包在BIOS image中。前者我叫它SW ROM,後者叫legacy ROM，您已經提到sw rom的load方式，那麽legacy rom load方式是否應該有所不同呢？一但找到OpROM,則BIOS 會先作一些 checks:
Ex.
- Option ROM signature is 0xAA55 ?
- 比較 Option ROM內的 Vendor ID/Device ID = H/W's IDs ?
- class code and sub-class code correct ?
- length = 0 ?
...etc...
兩种rom都是通過這種方式嗎？
Ans: 我所說的都是 rough flow，而這兩種ROM的"處理方式"不同,但"檢查的機制"大同小異...建議去trace BIOS code比較清楚
[補充1]
1.可以查看PCI ROM Spec... 裡面有詳細說明如何Load OpROM 的方式，而檢查項目就各家BIOS不同...
2.可以用HEX編輯器直接開啟ROM File，例如VBIOS.bin or OpROM.dat ...etc 來查看內容(Binary file)，例如某VBIOS.DAT 的內容如下:
00000 55 AA 80 E9 4B ....
00010 30 30 00 22 E9 19 21 5F 40 00
.......................................
00040 50 43 49 52 86 80 42 2A ..............
其中:
a)55AA是這個ROM的Signature <--代表他是符合規範的ROM
b)80 這個ROM的Code size <--需查閱Spec確定一下
c) 接著是EntryPoint Address <--實際上會執行的程式碼進入點的位址，所以一般都是講
Jmp OpRomBaseAddr+3 <-- 你如果trace BIOS 程式碼，這就是 +3 的由來
d) 000018h=40 代表另一個PCI Header在Offset 00040h的地方
所以 50 43 49 52 是Signature，如果用ACSII 來看就是"PCIR"
其他更多資訊可以查看PCI ROM Spec說明.....
e) "PCIR"後面緊跟著這個OpRom的VID與DID ...即8086 2A42 <--Intel=8086
3.如果想要改OpRom裡面的Code，可以使用反組譯工具去修改或是用Debug去修改
如果比較簡單的OpROM要做實驗的話我都用Debug.com 把OpROM 載入到Mem，接著利用T /P 指令單步執行去追蹤與修改，修改好之後再查看機器碼，再利用Hex編輯器 or 反組譯工具寫回去OpROM (找Bug時可以嘗試這樣寫啦，不過違反智慧財產權，最好還是叫Vendor幫你改，而且光看懂OpROm的流程就需要一點時間了 ^^!)
如果要用組合語言寫一個Dummy OpRom的做法就像下面範例去模擬一個OpROM...
至於你BIOS端可不可以run 就要看你的檢查機制嚴謹程度或是你自己修改你的BIOS code來達到模擬的目的 :
.586p
.code
YourCodeStart:
ORG 0
db 55h, 0AAh
TotalCodeSize db (offset YourCodeEnd) - (offset YourCodeStart)
ORG 3
jmp entrypoint
entrypoint:
........
YourCodeEnd:
END
組譯完之後可以利用微軟工具EXE2BIN.EXE 把他轉成xxx.bin (binary file)然後你就可以包進去BIOS測試。
[補充2]
當VGA init時,那時VGA BIOS的放置處可能有:
case 1: 在 memory中(當初在 shadow stage時被 copy 到 memory)
case 2: 在 card上(Ex. 一般的 external VGA card上都有一顆小rom)
因此,這兩種case的處理方式便不同.
Ex. In case 2 若VGA card在 bridge後面,則還需要 config 該 bridge's resource window使Option(in card)可以被正確的 accessed...<- 所以處理方式有所不同 !
至於檢查機制;因為Option ROM不管放哪裡,其 content都是一樣 ! 因此檢查機制大同小異...還有,不同家BIOS的 "checks" 也未必完全相同 !!!
- Input device(Ex. Keyboard)
- Output device(Ex. Display device)
- IPL(Initial Program Load, Ex. HDD)
這次要提到的是 Display device,即 VGA !
在PCI_SCAN之後,BIOS會在記憶體中建立一個data structure,代表整個系統的 PCI architecture.
Ex. Ponter-> NB->P2P->SB->IDE->AUDIO->LAN->USB 2.0->USB 1.1->...->VGA->...->End
在VGA_init的階段,BIOS會去 go-through this list,一個個的問:"有沒有人需要shadow Option ROM的 ?"
-------------------------------
*1 在此,先break,並說明一些觀念:
1. Option ROM是 for H/W的 firmware;像BIOS一樣是 for MB.有可能直接在硬體上 ,or 包在BIOS image中
2. 有Option ROM的 H/W可能有: VGA card,Lan card, RAID card,...etc
3. VGA's Option ROM 也就是 VBIOS ! 專門處理 screen I/O operation(主要是int10h)
4. VGA "shadow" 即代表: 將 VBIOS copy 到 shadow RAM, Ex. C0000h~C7FFFh處(32K)
5. VGA init這個階段只 consider "VGA device" ! for 其他 device,之後再考慮其 shadow的事宜
-------------------------------
(承接前面的 flow):此時,VGA device會舉手說:"我要" !此時,BIOS會去尋找VGA device's Option ROM(即VBIOS)在哪裡;此時,VBIOS有可能在card上 or "當初" 被包在 BIOS image中(*2)
一但找到,則會先 作一些 checks:Ex.
- Option ROM signature is 0xAA55 ?
- 比較 Option ROM內的 Vendor ID/Device ID = H/W's IDs ?
- class code and sub-class code correct ?
- length = 0 ?
...etc...
若都符合,則視它為 VGA Option ROM(VBIOS) ! 之後,利用 memory2memory copy將之 copy到 shadow memory,從 C0000h處開始存放...
複製完後,再 check "checksum"是否正確;if yes then jump to "entry of initialization code",控制權自此轉移至 VGA Option ROM,由它去做 initialize VGA的工作 ! ( 若是CRT螢幕,user會聽到ㄉ一ㄤ的一聲 ! 即代表 initialize VGA成功 !!! )
<- 此為 VGA_init的工作 !!!
*2 說"當初"的原因是: VGA BIOS若包在BIOS image中,在 BIOS shadow時,也會被一併 copy到記憶體的某處放著;當然,會記住存放處 !
[Note] 一般遇到 VGA init fail的issue時,可以先 check:是否 VGA BIOS已被 copy 至 C0000h處;若有,則check是否已經 jump to VBIOS or NOT;若否,則可以往前 check是否前面所列的一些 "關卡"沒過 (Ex. ID不 match, or checksum 不相等...etc )
---------------------------
- 相關討論 -----------------
---------------------------
通常都是板子一來就會去開始Debug VGA...
VBIOS 若壞，螢幕是黑ㄟ
VBIOS若好，螢幕是彩色ㄟ
沒螢幕的情況下要繼續Porting BIOS就比較麻煩一點
[Q]Option ROM是 for H/W的 firmware;像BIOS一樣是 for MB.有可能直接在硬體上 ,or 包在BIOS image中。前者我叫它SW ROM,後者叫legacy ROM，您已經提到sw rom的load方式，那麽legacy rom load方式是否應該有所不同呢？一但找到OpROM,則BIOS 會先作一些 checks:
Ex.
- Option ROM signature is 0xAA55 ?
- 比較 Option ROM內的 Vendor ID/Device ID = H/W's IDs ?
- class code and sub-class code correct ?
- length = 0 ?
...etc...
兩种rom都是通過這種方式嗎？
Ans: 我所說的都是 rough flow，而這兩種ROM的"處理方式"不同,但"檢查的機制"大同小異...建議去trace BIOS code比較清楚
[補充1]
1.可以查看PCI ROM Spec... 裡面有詳細說明如何Load OpROM 的方式，而檢查項目就各家BIOS不同...
2.可以用HEX編輯器直接開啟ROM File，例如VBIOS.bin or OpROM.dat ...etc 來查看內容(Binary file)，例如某VBIOS.DAT 的內容如下:
00000 55 AA 80 E9 4B ....
00010 30 30 00 22 E9 19 21 5F 40 00
.......................................
00040 50 43 49 52 86 80 42 2A ..............
其中:
a)55AA是這個ROM的Signature <--代表他是符合規範的ROM
b)80 這個ROM的Code size <--需查閱Spec確定一下
c) 接著是EntryPoint Address <--實際上會執行的程式碼進入點的位址，所以一般都是講
Jmp OpRomBaseAddr+3 <-- 你如果trace BIOS 程式碼，這就是 +3 的由來
d) 000018h=40 代表另一個PCI Header在Offset 00040h的地方
所以 50 43 49 52 是Signature，如果用ACSII 來看就是"PCIR"
其他更多資訊可以查看PCI ROM Spec說明.....
e) "PCIR"後面緊跟著這個OpRom的VID與DID ...即8086 2A42 <--Intel=8086
3.如果想要改OpRom裡面的Code，可以使用反組譯工具去修改或是用Debug去修改
如果比較簡單的OpROM要做實驗的話我都用Debug.com 把OpROM 載入到Mem，接著利用T /P 指令單步執行去追蹤與修改，修改好之後再查看機器碼，再利用Hex編輯器 or 反組譯工具寫回去OpROM (找Bug時可以嘗試這樣寫啦，不過違反智慧財產權，最好還是叫Vendor幫你改，而且光看懂OpROm的流程就需要一點時間了 ^^!)
如果要用組合語言寫一個Dummy OpRom的做法就像下面範例去模擬一個OpROM...
至於你BIOS端可不可以run 就要看你的檢查機制嚴謹程度或是你自己修改你的BIOS code來達到模擬的目的 :
.586p
.code
YourCodeStart:
ORG 0
db 55h, 0AAh
TotalCodeSize db (offset YourCodeEnd) - (offset YourCodeStart)
ORG 3
jmp entrypoint
entrypoint:
........
YourCodeEnd:
END
組譯完之後可以利用微軟工具EXE2BIN.EXE 把他轉成xxx.bin (binary file)然後你就可以包進去BIOS測試。
[補充2]
當VGA init時,那時VGA BIOS的放置處可能有:
case 1: 在 memory中(當初在 shadow stage時被 copy 到 memory)
case 2: 在 card上(Ex. 一般的 external VGA card上都有一顆小rom)
因此,這兩種case的處理方式便不同.
Ex. In case 2 若VGA card在 bridge後面,則還需要 config 該 bridge's resource window使Option(in card)可以被正確的 accessed...<- 所以處理方式有所不同 !
至於檢查機制;因為Option ROM不管放哪裡,其 content都是一樣 ! 因此檢查機制大同小異...還有,不同家BIOS的 "checks" 也未必完全相同 !!!
星期三, 10月 10, 2007
[我所知道的BIOS]->[Shadowing] 8
[Why shadow BIOS ?]
在此之前所提的BIOS tasks,都是循著 CPU->NB->SB->SIO->ROM的路徑來達成的;意即: CPU是去BIOS ROM裡面抓code來執行 ! 明顯的一件事是: ROM access time > DRAM access time ! 且RAM access width is 32bits,而 ROM access width 通常為 16 bits. 因此,便有了所謂" BIOS Shadowing"的觀念產生 ! <- "performance consideration" !!!
[What is shadowing]
意即: 將部分BIOS CODE(in ROM)拷貝至DRAM中 ! (此後, CPU將從DRAM中抓code來執行...)這樣的動作便稱做 "Shadowing" ! 而該處的DRAM即稱為 shadow memory.
Shadowing 在BIOS 中是極為複雜的 kernel code part ! 想深入瞭解的人最好有 source code可 trace.
[When to shadow BIOS]
=> 當然是等記憶體穩定了,可以使用後,才做 ^_^
*因此,假如 DRAM sizing 有問題, BIOS shadowing必定有問題 !!!
以下是之前在其他文章中發表關於 shadow 的文章,再次節錄以供參考 !
[System Behavior before & after shadow]
說的更白話一點就是 : 當 Power On後, 跑完 system power-on sequence後, CPU會被 reset ( reset 指的是 CPU 的 內容會回到 "初始值" ); 而 CPU內部的 EIP (32-bit )的初值是 FFFFFFF0h, 所以, CPU的 第一個 code read 就是到 FFFFFFF0h fetch code...
這個 memory cycle 從 CPU發出, 先會經過 North bridge ; 此時, north bridge會說 "這不是我的"...然後,往 south bridge 丟 ; south bridge 會說, "這是我的",收下後丟給 ROM ! 所以, FFFFFFF0h 會被 ROM 接走 !!! ( 所以 前人才說 "硬體初始值要把0xFFFFFFF0 和 0x000FFFF0 要mapping到同一個地方", 這個地方就是.....ROM !!! )
之後, CPU所發的 cycle 都會照上述的方式一路抵達 ROM...由 CPU循著 fetch, decode, execute, store的順序作事情...
但到某一個階段前, BIOS的 code 會指示 " 要將 BIOS data 從 ROM 搬到 DRAM" ! 而在此階段之後, BIOS會設定 north bridge 暫存器, 告訴 north bridge "之後 CPU所發的 cycle 不可以不收而傳到 south bridge"....
自此之後, CPU 所發的 cycle 全部轉到 DRAM 中,由 CPU循著 fetch, decode, execute, store的順序作事情...
[Summary] 總而言之, BIOS 一開始是CPU讀取 ROM content來執行,之後是CPU 讀取 DRAM content 執行 ^_^
[補充][以提問的方式^_^]
[Q]: shadow memory到底是那一塊 ?
[A]: 以現在的電腦系統而言, shadow memory 是在UMA(upper memory area;傳統記憶體 640K以上至1M之間) "裡面"(part of it) ;在此UMA內可以分為 6 segments(64kB/each), total 384KB.
其中 C0000h~DFFFFh: for VGA BIOS and other devices' Option ROMs
E0000h~FFFFFh: BIOS ROM code
這兩個 blocks 本質是 memory;之後會被載以ROM content;因此,便稱為 shadow memory(好像: ROM在上面, memory在下面,是ROM的 "shadow"...)
[Q]: shadow memory 的內容 完全 "=" ROM content ?
[A]: of course NOT ! 除了 UMA不大以外,BIOS ROM因為必須support more and more functions/features,size已經越長越大;除此之外,BIOS ROM中也有部分module是經過壓縮的.(UMA不夠放...)
當BIOS shadow時,只會 copy necessary code(Ex. run-time要用的...etc)至 shadow memory ! 另外,已經執行過後的code也不會被載入. 因此,不是 1-1的copy...
[Q]: what Shadow enabled/disable mean in chipset ?
[A]: 前面提過, CPU要 fetch的code由 shadow memory 提供 or ROM提供,其根本關鍵在於 chipset's behavior ! 意即,NB必須做此決定 ! 所以,這機制一般是由NB來實現的.
NB內有所謂的 shadow registers. 當 shadow register enable時, memory cycle由 shadow memory 來回應;若 shadow disable,則由ROM回應.
意即:
000E0000h~000FFFFFh由 shadow memory replies if (shadow enabled)
000E0000h~000FFFFFh由 ROM chip replies if (shadow disabled)
若FFFE000h~FFFFFFFFh呢 ? 必定由ROM chip來回應(不然一開機怎麼辦?). 與 shadow disable/enable無關 !!!
*若使用 ru.exe 並檢視 memory space,可發現上述的情況.
[Q]: shadow有何好處 ?
[A]: 因為 slower ROM v.s faster RAM,所以放在RAM可以增加 system performance.
*各位可以發現,同樣的code放在 rom & dram中執行速度將大不相同 !
[Q]: shadow memory的 issue ?
[A]: 被 shadowed 的 memory area都會被設成 write-protected ! 因此,這塊area是不能 write 的.所以,若有程式會 "write"這塊,則會有問題 !!!
其實, BIOS shadow這段code大家不太會碰觸到...瞭解基本information即可.
有錯誤請指正 !!!
[附註]
[Q1] "BIOS的所有動作都必須先從ROM COPY至DRAM之後CPU才有辦法去執行"
Ans : 講簡單一點就是對CPU來說，他只負責提取指令，解碼指令，執行指令。至於是讀取到哪邊的指令他就不管了(IA32 架構)。例如CPU要讀取F0000h的指令來執行，那F0000h有可能是ROM也有能是DRAM。
[Q2] "那BIOS一開始的0E05BH是ROM的位置？還是DRAM的位置呢？"
==>0~4G 是指位址線的位址(因為Address bus = 32 bits=2^32)，至於位址線上面是分配給DRAM還是ROM使用還是Others...就要看實際的硬體架構，例如IA32 架構就有其分配的方式。
==>所以某個位址線的位址可以被分配給ROM使用也可以分配給DRAM使用，還可以重疊一起使用，例如 F segment (000F_0000h)就是重疊使用，所謂的重疊就是就像是CPU 對F0000h存取的時候，他是存取到DRAM的資料還是ROM的資料 ? 答案就是看北橋....如果北橋在此時把這個位址是映對到ROM，那麼CPU讀取到的F0000h資料是ROM裡面的，如果北橋是映對到DRAM那麼CPU一樣是讀取F0000h但是會讀取到DRAM內的資料。
==> 所以0E05Bh 是位址線的位址。
==> 另外BIOS一開始的位址是在FFFF_FFF0 不是在0E05Bh...
==> BIOS的程式碼會去改變北橋設定，讓在不同階段的執行期間去存取到DRAM/ROM的資料，我們稱為shadow....例如從F0000h的 ROM讀資料，寫到F0000h 的DRAM中
==> 這邊說的都是IA32，其他架構要看Spec 說明。
在此之前所提的BIOS tasks,都是循著 CPU->NB->SB->SIO->ROM的路徑來達成的;意即: CPU是去BIOS ROM裡面抓code來執行 ! 明顯的一件事是: ROM access time > DRAM access time ! 且RAM access width is 32bits,而 ROM access width 通常為 16 bits. 因此,便有了所謂" BIOS Shadowing"的觀念產生 ! <- "performance consideration" !!!
[What is shadowing]
意即: 將部分BIOS CODE(in ROM)拷貝至DRAM中 ! (此後, CPU將從DRAM中抓code來執行...)這樣的動作便稱做 "Shadowing" ! 而該處的DRAM即稱為 shadow memory.
Shadowing 在BIOS 中是極為複雜的 kernel code part ! 想深入瞭解的人最好有 source code可 trace.
[When to shadow BIOS]
=> 當然是等記憶體穩定了,可以使用後,才做 ^_^
*因此,假如 DRAM sizing 有問題, BIOS shadowing必定有問題 !!!
以下是之前在其他文章中發表關於 shadow 的文章,再次節錄以供參考 !
[System Behavior before & after shadow]
說的更白話一點就是 : 當 Power On後, 跑完 system power-on sequence後, CPU會被 reset ( reset 指的是 CPU 的 內容會回到 "初始值" ); 而 CPU內部的 EIP (32-bit )的初值是 FFFFFFF0h, 所以, CPU的 第一個 code read 就是到 FFFFFFF0h fetch code...
這個 memory cycle 從 CPU發出, 先會經過 North bridge ; 此時, north bridge會說 "這不是我的"...然後,往 south bridge 丟 ; south bridge 會說, "這是我的",收下後丟給 ROM ! 所以, FFFFFFF0h 會被 ROM 接走 !!! ( 所以 前人才說 "硬體初始值要把0xFFFFFFF0 和 0x000FFFF0 要mapping到同一個地方", 這個地方就是.....ROM !!! )
之後, CPU所發的 cycle 都會照上述的方式一路抵達 ROM...由 CPU循著 fetch, decode, execute, store的順序作事情...
但到某一個階段前, BIOS的 code 會指示 " 要將 BIOS data 從 ROM 搬到 DRAM" ! 而在此階段之後, BIOS會設定 north bridge 暫存器, 告訴 north bridge "之後 CPU所發的 cycle 不可以不收而傳到 south bridge"....
自此之後, CPU 所發的 cycle 全部轉到 DRAM 中,由 CPU循著 fetch, decode, execute, store的順序作事情...
[Summary] 總而言之, BIOS 一開始是CPU讀取 ROM content來執行,之後是CPU 讀取 DRAM content 執行 ^_^
[補充][以提問的方式^_^]
[Q]: shadow memory到底是那一塊 ?
[A]: 以現在的電腦系統而言, shadow memory 是在UMA(upper memory area;傳統記憶體 640K以上至1M之間) "裡面"(part of it) ;在此UMA內可以分為 6 segments(64kB/each), total 384KB.
其中 C0000h~DFFFFh: for VGA BIOS and other devices' Option ROMs
E0000h~FFFFFh: BIOS ROM code
這兩個 blocks 本質是 memory;之後會被載以ROM content;因此,便稱為 shadow memory(好像: ROM在上面, memory在下面,是ROM的 "shadow"...)
[Q]: shadow memory 的內容 完全 "=" ROM content ?
[A]: of course NOT ! 除了 UMA不大以外,BIOS ROM因為必須support more and more functions/features,size已經越長越大;除此之外,BIOS ROM中也有部分module是經過壓縮的.(UMA不夠放...)
當BIOS shadow時,只會 copy necessary code(Ex. run-time要用的...etc)至 shadow memory ! 另外,已經執行過後的code也不會被載入. 因此,不是 1-1的copy...
[Q]: what Shadow enabled/disable mean in chipset ?
[A]: 前面提過, CPU要 fetch的code由 shadow memory 提供 or ROM提供,其根本關鍵在於 chipset's behavior ! 意即,NB必須做此決定 ! 所以,這機制一般是由NB來實現的.
NB內有所謂的 shadow registers. 當 shadow register enable時, memory cycle由 shadow memory 來回應;若 shadow disable,則由ROM回應.
意即:
000E0000h~000FFFFFh由 shadow memory replies if (shadow enabled)
000E0000h~000FFFFFh由 ROM chip replies if (shadow disabled)
若FFFE000h~FFFFFFFFh呢 ? 必定由ROM chip來回應(不然一開機怎麼辦?). 與 shadow disable/enable無關 !!!
*若使用 ru.exe 並檢視 memory space,可發現上述的情況.
[Q]: shadow有何好處 ?
[A]: 因為 slower ROM v.s faster RAM,所以放在RAM可以增加 system performance.
*各位可以發現,同樣的code放在 rom & dram中執行速度將大不相同 !
[Q]: shadow memory的 issue ?
[A]: 被 shadowed 的 memory area都會被設成 write-protected ! 因此,這塊area是不能 write 的.所以,若有程式會 "write"這塊,則會有問題 !!!
其實, BIOS shadow這段code大家不太會碰觸到...瞭解基本information即可.
有錯誤請指正 !!!
[附註]
[Q1] "BIOS的所有動作都必須先從ROM COPY至DRAM之後CPU才有辦法去執行"
Ans : 講簡單一點就是對CPU來說，他只負責提取指令，解碼指令，執行指令。至於是讀取到哪邊的指令他就不管了(IA32 架構)。例如CPU要讀取F0000h的指令來執行，那F0000h有可能是ROM也有能是DRAM。
[Q2] "那BIOS一開始的0E05BH是ROM的位置？還是DRAM的位置呢？"
==>0~4G 是指位址線的位址(因為Address bus = 32 bits=2^32)，至於位址線上面是分配給DRAM還是ROM使用還是Others...就要看實際的硬體架構，例如IA32 架構就有其分配的方式。
==>所以某個位址線的位址可以被分配給ROM使用也可以分配給DRAM使用，還可以重疊一起使用，例如 F segment (000F_0000h)就是重疊使用，所謂的重疊就是就像是CPU 對F0000h存取的時候，他是存取到DRAM的資料還是ROM的資料 ? 答案就是看北橋....如果北橋在此時把這個位址是映對到ROM，那麼CPU讀取到的F0000h資料是ROM裡面的，如果北橋是映對到DRAM那麼CPU一樣是讀取F0000h但是會讀取到DRAM內的資料。
==> 所以0E05Bh 是位址線的位址。
==> 另外BIOS一開始的位址是在FFFF_FFF0 不是在0E05Bh...
==> BIOS的程式碼會去改變北橋設定，讓在不同階段的執行期間去存取到DRAM/ROM的資料，我們稱為shadow....例如從F0000h的 ROM讀資料，寫到F0000h 的DRAM中
==> 這邊說的都是IA32，其他架構要看Spec 說明。
星期三, 11月 28, 2007
純手工打造你自己的x86 BIOS(3)
在前面兩篇文章中的描述中其實大家就應該可以知道我的實驗環境由幾個部份所組成，所以我這邊假設 "如果我是ㄧ個BIOS Vendor"，我將會如何描述我前面所說的那些部分。
在我的實驗中，整個BIOS Build Environment 我們可以得知如同下圖的架構，我在後面將分別對這些部份做ㄧ個簡單的說明。
1.Source code : 這就是我的MyBios.asm，只有一個檔案，ㄧ般我會放在某個目錄內，大家可以想一下如果擴充成7000多個檔案的時候，你會放同一個目錄嗎? 如果分類你要如何分? 如果修改,你要直接改嗎? 還是採用什麼方式去覆蓋?
2. Build Settings : 我使用的是MASM，而他在我的C:\MASM，假如你是利用makefile產生結果，那麼你就會需要設定一些工具的路徑，組譯或是編譯的程式是哪ㄧ個，參數為何...等。
3.Build Tools : 像我提到的Build.exe就是我自己寫的，用來輔助建立BIOS Image時所使用，所以當你的環境越來越大的時候，所使用的Tools可能就不只一個。
4.Build : 當上面的部分都結合在一起後，就可以產生出結果，ㄧ般我們可以利用makefile 方式把上面步驟都結合在一起，然後就可以方便的產生出結果。
5.BIOS Image : 在我的實驗中，產生的結果就是MyBIOS.ROM。
結論：
實驗中大家可以發現，其實BIOS vendor所提供的環境基本的本質很簡單，只是當你在實做的時候你會遇到一些問題，而你在解決這些問題的時候不知不覺整個架構就會越來越複雜，因此當我們接觸到一個成熟的BIOS Build environment時，就會需要了解更多的東西以便我們更能夠駕馭BIOS vendor所提供的環境。
前面這幾篇文章大致上描述出BIOS Build Environment的基本架構，所以當你想要寫一個BIOS然後提供給別人一個環境去撰寫BIOS時，其基本本質大概就是這樣，後面的文章中我會繼續介紹實際上MyBIOS.asm 中我們該撰寫什麼後我們才能夠在Port 80h 的7段顯示器上顯示99h。
在我的實驗中，整個BIOS Build Environment 我們可以得知如同下圖的架構，我在後面將分別對這些部份做ㄧ個簡單的說明。
1.Source code : 這就是我的MyBios.asm，只有一個檔案，ㄧ般我會放在某個目錄內，大家可以想一下如果擴充成7000多個檔案的時候，你會放同一個目錄嗎? 如果分類你要如何分? 如果修改,你要直接改嗎? 還是採用什麼方式去覆蓋?
2. Build Settings : 我使用的是MASM，而他在我的C:\MASM，假如你是利用makefile產生結果，那麼你就會需要設定一些工具的路徑，組譯或是編譯的程式是哪ㄧ個，參數為何...等。
3.Build Tools : 像我提到的Build.exe就是我自己寫的，用來輔助建立BIOS Image時所使用，所以當你的環境越來越大的時候，所使用的Tools可能就不只一個。
4.Build : 當上面的部分都結合在一起後，就可以產生出結果，ㄧ般我們可以利用makefile 方式把上面步驟都結合在一起，然後就可以方便的產生出結果。
5.BIOS Image : 在我的實驗中，產生的結果就是MyBIOS.ROM。
結論：
實驗中大家可以發現，其實BIOS vendor所提供的環境基本的本質很簡單，只是當你在實做的時候你會遇到一些問題，而你在解決這些問題的時候不知不覺整個架構就會越來越複雜，因此當我們接觸到一個成熟的BIOS Build environment時，就會需要了解更多的東西以便我們更能夠駕馭BIOS vendor所提供的環境。
前面這幾篇文章大致上描述出BIOS Build Environment的基本架構，所以當你想要寫一個BIOS然後提供給別人一個環境去撰寫BIOS時，其基本本質大概就是這樣，後面的文章中我會繼續介紹實際上MyBIOS.asm 中我們該撰寫什麼後我們才能夠在Port 80h 的7段顯示器上顯示99h。
星期四, 11月 15, 2007
EFI Framework 概述
如果有下載Intel EFI Spec的人就知道每次提到EFI的時候就會有一個很大的綠色的H，這個就是EFI 的framework。
什麼是Framework呢? 這邊就簡單說一下整個EFI framework架構。
我個人猜想，當初Intel 開發EFI其實只是為了要擴充BIOS的功能，因為在Legacy BIOS的年代，很多的東西都沒有模組化，因此當硬體或是Platform有比較大的變動的時候，對於整個BIOS開發的時間就會延長，那種感覺就好像是你每次都要對一個新的硬體重新寫一次你的BIOS程式碼，很沒有效率。
另外在Legacy BIOS年代，所有的BIOS程式碼的開發幾乎都是不同的BIOS vendor與Chipset 廠商ㄧ同合作，因此不同家的BIOS Vendor對於相同Chipset 廠商所寫出來的程式碼的穩定度就會不同，這對於 Intel 來說就等於要多花好幾倍的時間去跟不同BIOS Vendor 來討論以及處理問題。
因此，假如Intel 能夠把底層的BIOS程式碼變成模組化容易抽換，那麼BIOS在開發的過程中就會快速以及方便許多，而這種概念就像是Windows裡面的HAL 層的概念，簡單說在Windows系統中實際存取硬體是透過ㄧ個叫做HAL介面的處理，所以當Windows想要在不同的硬體上執行的時候，他只要把HAL的介面換成新的硬體的處理方式就可以了，而在Windows可以不用再重新改寫，例如你把Windows拿到Apple上面去執行，對於微軟的工程師來說，只要把HAL從新改寫就可以了。
而EFI的Framework 就像是HAL，Intel 本身提供了一些Protocol以及一些Lib來存取他們的硬體，而這一層就叫做Framework。對於Intel來說，不管你是哪一家的BIOS Vendor就不會再出現A廠商存取Intel Chipset有問題而B廠商不會，因為最底層都是Intel 自己負責。
而建構在Framework 上的一些功能就是各家BIOS Vendor自己去負責，感覺就像我之前說的，Inetl 留下一些地方給BIOS Vendor填寫他們的程式碼，然後BIOS Vendor在留下一些地方給OEM/ODM BIOS填寫ㄧ些程式碼，彼此關係就是一層一層環環相扣。
這邊還要提到EFI Framework 除了前面說的那些之外，他還提供了一些Boot Flow的控制，這就像是說從Power On--->POST--->Boot to OS的一些流程的控制也是由這個Framework 提供，感覺就像是你寫了一個main{}，而裡面的FunA()/FunB()/FunC() 的先後順序的執行你也都寫好了，之後FunA() 內要填什麼樣的子程式碼就屬於BIOS Vendor跟OEM/ODM BIOS自己決定了。
//--------------------------------------------------
// EFI Framework 的概念與C語言對應的示意圖
//--------------------------------------------------
#include <--Intel提供的函數
main() <--Intel 提供的Boot Flow
{
Dispatch FunA(); <--SEC
Dispatch FunB(); <--PEI
Dispatch FunC(); <--DXE
Dispatch FunD(); <--BDS
...
}
EFI Framework還有另一個優點就是移植性高，例如Intel 可以把整個EFI Framework概念移到嵌入式系統上去實做BIOS，這樣子他們能夠開發的市場就會越來越大。
前面提到這些都是Intel提供的EFI Framework，那麼AMD/其他廠商怎麼辦? 對，我也在想這個問題，由上面的說法可以看出Intel 的野心，他想把原本BIOS Vendor做的事情自己拿來做，為了不讓人家知道太多Chipset內的秘密，他自己寫Chipset的函數並做成Framework給BIOS vendor使用，所以我個人在思考幾個問題：
a) 假設不同 BIOS Vendor 都使用相同的函數的情況下，彼此的優缺點是不是只剩下誰提供的OEM/ODM Features比較多 ?
b) 假設不同 BIOS Vendor 都使用相同的Framework下，當底層換成AMD或是其他廠商後，彼此的優缺點是不是只剩下誰對不同廠商的支援度比較高，市場佔有率就比較高?
c)假設OEM/ODM BIOS 都使用相同的Framework後，開發時間縮短相對的被取代的性質是否也相對提高?
d) Others..
以上大致上就是個人對於EFI Framework 的一些理解跟想法，如有誤請先進不吝指正，謝謝!
什麼是Framework呢? 這邊就簡單說一下整個EFI framework架構。
我個人猜想，當初Intel 開發EFI其實只是為了要擴充BIOS的功能，因為在Legacy BIOS的年代，很多的東西都沒有模組化，因此當硬體或是Platform有比較大的變動的時候，對於整個BIOS開發的時間就會延長，那種感覺就好像是你每次都要對一個新的硬體重新寫一次你的BIOS程式碼，很沒有效率。
另外在Legacy BIOS年代，所有的BIOS程式碼的開發幾乎都是不同的BIOS vendor與Chipset 廠商ㄧ同合作，因此不同家的BIOS Vendor對於相同Chipset 廠商所寫出來的程式碼的穩定度就會不同，這對於 Intel 來說就等於要多花好幾倍的時間去跟不同BIOS Vendor 來討論以及處理問題。
因此，假如Intel 能夠把底層的BIOS程式碼變成模組化容易抽換，那麼BIOS在開發的過程中就會快速以及方便許多，而這種概念就像是Windows裡面的HAL 層的概念，簡單說在Windows系統中實際存取硬體是透過ㄧ個叫做HAL介面的處理，所以當Windows想要在不同的硬體上執行的時候，他只要把HAL的介面換成新的硬體的處理方式就可以了，而在Windows可以不用再重新改寫，例如你把Windows拿到Apple上面去執行，對於微軟的工程師來說，只要把HAL從新改寫就可以了。
而EFI的Framework 就像是HAL，Intel 本身提供了一些Protocol以及一些Lib來存取他們的硬體，而這一層就叫做Framework。對於Intel來說，不管你是哪一家的BIOS Vendor就不會再出現A廠商存取Intel Chipset有問題而B廠商不會，因為最底層都是Intel 自己負責。
而建構在Framework 上的一些功能就是各家BIOS Vendor自己去負責，感覺就像我之前說的，Inetl 留下一些地方給BIOS Vendor填寫他們的程式碼，然後BIOS Vendor在留下一些地方給OEM/ODM BIOS填寫ㄧ些程式碼，彼此關係就是一層一層環環相扣。
這邊還要提到EFI Framework 除了前面說的那些之外，他還提供了一些Boot Flow的控制，這就像是說從Power On--->POST--->Boot to OS的一些流程的控制也是由這個Framework 提供，感覺就像是你寫了一個main{}，而裡面的FunA()/FunB()/FunC() 的先後順序的執行你也都寫好了，之後FunA() 內要填什麼樣的子程式碼就屬於BIOS Vendor跟OEM/ODM BIOS自己決定了。
//--------------------------------------------------
// EFI Framework 的概念與C語言對應的示意圖
//--------------------------------------------------
#include
main() <--Intel 提供的Boot Flow
{
Dispatch FunA(); <--SEC
Dispatch FunB(); <--PEI
Dispatch FunC(); <--DXE
Dispatch FunD(); <--BDS
...
}
EFI Framework還有另一個優點就是移植性高，例如Intel 可以把整個EFI Framework概念移到嵌入式系統上去實做BIOS，這樣子他們能夠開發的市場就會越來越大。
前面提到這些都是Intel提供的EFI Framework，那麼AMD/其他廠商怎麼辦? 對，我也在想這個問題，由上面的說法可以看出Intel 的野心，他想把原本BIOS Vendor做的事情自己拿來做，為了不讓人家知道太多Chipset內的秘密，他自己寫Chipset的函數並做成Framework給BIOS vendor使用，所以我個人在思考幾個問題：
a) 假設不同 BIOS Vendor 都使用相同的函數的情況下，彼此的優缺點是不是只剩下誰提供的OEM/ODM Features比較多 ?
b) 假設不同 BIOS Vendor 都使用相同的Framework下，當底層換成AMD或是其他廠商後，彼此的優缺點是不是只剩下誰對不同廠商的支援度比較高，市場佔有率就比較高?
c)假設OEM/ODM BIOS 都使用相同的Framework後，開發時間縮短相對的被取代的性質是否也相對提高?
d) Others..
以上大致上就是個人對於EFI Framework 的一些理解跟想法，如有誤請先進不吝指正，謝謝!
星期三, 9月 26, 2007
PCI IRQ Routing Table Specification
~~~轉載請註明出處~~~by 小華的部落格
在x86歷史的演進中，有很多的BIOS工程師對於PCI IRQ Routing Table還是搞不清楚，我剛入行的時候也是一樣，對於這個東西一點概念都沒有，只知道是因為IRQ#不夠用，所以才需要去繞線(Routing)。
[為何要繞? 背景是什麼?]
依照我自己研究出來的歷史，我發現可能的原因是因為PCI設備越來越多，然後當時的中斷控制器是串聯的8259A，所以只有IRQ0~IRQ15可以用，且IRQ2已經連接 "僕8259" (第二顆中斷控制器)，所以剩下來15支IRQ#可以用，但是又因為x86系統在早期的設計中，有些IRQ#已經分配給固定的設備使用，所以剩下來沒幾支可以用，可是設備又那麼多，所以如何去分配剩下來的IRQ就是大家討論的話題。
[IRQ繞線的歷史發展]
依照我查到的資料，早期的作業系統Windows 95年代左右，PCI設備要使用哪一支IRQ中斷線是靠PCI卡上面的"跳線"去控制，所以有可能會因為兩個PCI設備跳同一支"IRQ#"而造成衝突導致當機或是藍底白字。
後來改用BIOS Setup Menu內去控制，也就是可以進去BIOS設定畫面去設定IRQ分配。
因此為了解決PCI設備越來越多，但是IRQ不夠用的情況，所以微軟找上的晶片廠商也就是Intel合作開發PIRQ Route Controller，簡單說就是微軟想在他的作業系統上面支援"共享IRQ中斷架構"的驅動程式，但是需要硬體配合，因此定義了PCI IRQ Routing Table來規範硬體線路要怎樣繞線，且需要BIOS支援哪些資訊。
[為什麼是PCI設備而不是ISA設備?]
因為當時PCI Bus取代了傳統的周邊匯流排，所以PCI設備橫行，且設備需要服務就是透過中斷請求線IRQ#請求服務，對於OS端來說，這個服務就是驅動程式，至於CPU如何把控制權交給OS，則是靠IDT (interrupt Description Table)，相關詳細資料請看Windows核心說明。
[跟DOS有關嗎?]
應該是無關，除非你在DOS下替你的PCI設備寫了一個驅動程式，或是你的PCI設備在DOS模式下要工作，不過應該也是沒啥機會這樣做吧，所以PIRQ Routing都是針對Windows作業系統而言，因為與設備驅動程式管理有關。
[Windows 作業系統的改變]
對於微軟自己定義的規範中，他最希望的就是能夠共享IRQ，所以在作業系統的改變就是要能分辨是哪個PCI Device透過IRQ發出請求，這是因為可能有好幾個PCI 設備都用同一支IRQ#中斷請求，所以OS 必須要能夠讓正確的驅動程式去服務發出中斷的設備，因此在撰寫OS 端的 Driver 時有了新的規範(針對共享IRQ的驅動程式有其規範)。
[Chipset的改變]
起先為了微軟的規範，Inetl 在南橋ICH上面多了幾支接腳(PIRQA~PIRQD)，這幾支接腳又有對應的暫存器可以組態他們，例如下面範例：
PIRQA Register 60h bit3:0 <--PIRQA那隻接腳的設定暫存器在LPC Reg60h，其中bit3:0定義如下
=================================================================================
IRQ Routing — R/W. (ISA compatible.)
Value IRQ
0000b Reserved
0001b Reserved
0010b Reserved
0011b IRQ3
0100b IRQ4
0101b IRQ5
0110b IRQ6
0111b IRQ7
...
由上面範例可以看出每支PIRQ接腳都可以用"軟體"設定的方式橋接到IRQ#的任何一支。
也由於上面範例我們可以知道，OS 必須"先知道哪些IRQ可以被使用" 還有"哪些IRQ已經被使用"，因為OS本身有自己配置IRQ#的演算方式，因此必須要先知道這些資訊，才有辦法去對PIRQ#繞線。
[BIOS的支援]
所以BIOS要提供"PIRQ Routing Table"給作業系統，然後OS就可以得到這些資訊，但是又因為OS版本不同(Win95/Win95/Win2000/WinXp or Acpi OS/non-ACPI OS..等分類)，所以透過的傳遞管道也不同。
[後來的演變]
隨著PCI設備越來越多PIRQ只有4支接腳已經不夠用，所以後來擴充到8支，分別是PIRQA~PIRQH。
至今2007，OS 與 Intel 在這部份的演變也越來越複雜，因為後來的Intel 提出了新一代的中斷控制器APIC，所以在南橋ICH內就分成了兩種中斷控制器PIC與I/O APIC兩種，又因為OS演變成ACPI OS，所以原先PCI IRQ Routing Table Spec內所描述的方式就變成了ACPI Spec內的方式，簡單說就是BIOS傳遞PIRQ Routing方式也從Legacy OS方式演變成ACPI Mode方式(原本Table放在記憶體，現在改放在ASL Code)。
另外由於南橋ICH有兩種PIC，所以進入ACPI OS時是採用Legacy PIC mode 還是APIC mode 也會影響BIOS提供PIRQ Routing Table的方式，所以在ACPI Mode 底下又分成APIC Mode方式或是Non-APIC Mode(PIC Mode)方式。
~~~轉載請註明出處~~~by 小華的部落格
[結論]
PIRQ#是南橋上面的接腳，連接到PCI 的INTA#~INTD#，原本INTA#~INTD#應該直接接到PIC上面的IRQ#接腳，但是因為IRQ#不夠用，所以微軟才與Intel合作，多做了幾支接腳出來，然後用軟體方式去配置這些多出來的接腳PIRQ#要繞線到哪個IRQ#，且作業系統的驅動程式可支援共享IRQ中斷，所以在Chipset 端把這種機制稱之為PIRQ Route Controller (具有PIRQ繞線功能的控制器，也就是某某一代的南橋開始把這個功能整合進去南橋晶片內)。
而BIOS所扮演的角色就是提供PIRQ Routing Table，這個Table的結構如同微軟的PCI IRQ Routing Table的規範，而當系統演變到ACPI 後，BIOS也改變了提供Table的方式，也就是改遵循ACPI Spec內的規範去提供這些資訊。
上述這些資訊只是我整理的筆記的一部分概要，詳細內容可以參考相關資料說明，畢竟我也是花了一個多星期的時間才整理出整個PIRQ的歷史，是對是錯我也不清楚，畢竟過去的架構我來不及參與，只能就我收集到的資料作一個描述，如有誤請先進指教。 ~~~轉載請註明出處~~~by 小華的部落格
[後記]
1)當ACPI OS 系統處在APIC Mode的時候，PIRQA~PIRQH會直接對應在APIC 的IRQ16~IRQ23而不需要繞線。
2)APIC 目前可提供的中斷請求線有 IRQ0~IRQ255 ，目前只使用IRQ0~IRQ23
3)APIC 前面的IRQ0#~IRQ15對應到PIC的IRQ0~IRQ15
4)PIRQ Routing 是指: IRQ不夠用才需要透過PIRQ Routing Controller繞線，所以只針對PIC，而APIC模式則不需要繞線。
4)APIC Mode只需要描述哪些PCI Device共用了哪些PIRQ線。
5)non-APIC mode則需要描述哪些PIC的IRQ#可以被使用，描述的內容如同PCI IRQ Routing Table，差別在於用ASL Code描述
6)APIC有分成Local APIC與I/O APIC，這邊所提到的都是指I/O APIC。
[Reference]
http://www.microsoft.com/whdc/archive/pciirq.mspx
http://www.microsoft.com/taiwan/whdc/system/CEC/ACPI-MP.mspx
http://www.google.com
[補充資料]
VGA IRQ的配置
早期VGA卡還在ISA時代的時候, 透過BIOS啟動系統時, 會得到interrupt 第一順位, 而且有固定存取區域在UMB(Upper Memory Black)裡頭與系統相對印; 在PnP時代, BIOS系統直接在啟動系統時給予IRQ#編號, 無論你是AGP or PCI都變成由BIOS指定位置, 而不再像ISA時代需要跟其他人搶系統控制權.
順便一提的是, MS系統推出雙螢幕(Dual VGA)的概念的時候, 一些VGA-BIOS沒規劃好的顯示卡就出現問題. 因為在BIOS啟動系統的時候, 會依照設定順序尋找開機起始用的顯示卡(預設是PCI), 結果因為有兩張PCI顯示卡(或者主機板的晶片採用SIS55xx系列, VIA早期586時代晶片都有這種現象), 反而推選不出一個可以啟動的System VGA, 變成必須在佈線的時候強制規定哪邊是佔用較高優先權的現象...
到了AGP時代, 變成系統直接佔用, 不再有IRQ衝突的事情.....對廠商對BIOS規劃人員也變得比較簡單點了....
display card在古老時代是不需要IRQ的,當時diplay card本身不過是被動式的介面,顯示記憶體都是由CPU來控制寫入或讀出與搬移(如HOYO兄所說),所以那時就是單純的使用 Linear address mapping 來處理,而遇到較大而複雜的畫面記憶體處理時,就用視訊記憶體頁切換來應付,然而隨著顯示的需求越來越複雜,VGA card和CPU間的溝通需求也越來越多,VGA本身也搭載了功能強大的GPU,可算是一個小的專門處理影像的CPU了.這時候 VGA Card不再是一個只會聽CPU命令的單元了,它開始會對CPU提出要求,以進行一些需要取用北橋資源的動作,此時就需要IRQ來做"舉手發言".
目前市面上仍然有一些VGA是不需要IRQ的,但並不代表它們不是高階顯示卡,而是視廠商所使用的技術而定.
一般的 VGA IRQ 預設大都在IRQ 11，除非有佔用系統會自動轉到別的IRQ...
PIRQ配置演算法(4 支PIRQ的時候)
PCI SLOT 中斷共有四個
INT a/b/c/d
一般的接法是
Slot1 a/b/c/d 接到南橋 a/b/c/d
Slot2 a/b/c/d 接到南橋 b/c/d/a
Slot3 a/b/c/d 接到南橋 c/d/a/b
Slot4 a/b/c/d 接到南橋 d/a/b/c
而卡上 通常是從 int a 接起
所以兩片使用一個中斷的PCI 卡會變成個別接到 int a / int b, 而不會通通都接到int a 了
PCI 要求裝置的中斷要共享，唯一缺點就是 "共享的部分" 要多消耗一些程式碼去確定中斷是給誰的
另有一些ON BOARD 的裝置已經固定接到其中的一些中斷訊號線上了，看看主機板說明書上有沒有寫
這樣你就可以知道INT a/b/c/d 哪些是完全可以獨立運作的。
中斷經過IRQ Routing table 去轉成我們常說的中斷號碼 IRQ# 這個在BIOS中可以設定，也可以自動配置。如果有獨立中斷的SLOT 就可以拿來用在IDE Card/SCSI Card這種講究效能的裝置上。
另外就是給一些卡使用，因為這些卡的驅動程式不肯跟別人分享中斷，如果分享就不肯工作。
還有一種卡和別人分享就容易當機。
有一些ISA 規格的裝置一定會佔用固定的中斷，如果不用可以DISABLE，不過 PCI 還是只有四個給你的SLOT用空再多也沒用要分享的依舊要分享
irq-0 Timer
irq-1 Keyboard
irq-2 Cascade
irq-3 Com2
irq-4 Com1
irq-7 LPT1
irq-8 RTC
irq-12 PS/2
irq-13 FPU
irq-14 IDE1
irq-15 IDE2
大部分的VGA 都沒有配中斷，另外 Win2k ACPI 會把IRQ routing table 通通都設成同一個中斷號碼 沒辦法改 效能會降低 因為每個PCI卡的驅動程式都會檢查一遍 看看是不是自己的中斷，每次也只會有一個說是他的中斷這在高速裝置是很糟糕的。
在x86歷史的演進中，有很多的BIOS工程師對於PCI IRQ Routing Table還是搞不清楚，我剛入行的時候也是一樣，對於這個東西一點概念都沒有，只知道是因為IRQ#不夠用，所以才需要去繞線(Routing)。
[為何要繞? 背景是什麼?]
依照我自己研究出來的歷史，我發現可能的原因是因為PCI設備越來越多，然後當時的中斷控制器是串聯的8259A，所以只有IRQ0~IRQ15可以用，且IRQ2已經連接 "僕8259" (第二顆中斷控制器)，所以剩下來15支IRQ#可以用，但是又因為x86系統在早期的設計中，有些IRQ#已經分配給固定的設備使用，所以剩下來沒幾支可以用，可是設備又那麼多，所以如何去分配剩下來的IRQ就是大家討論的話題。
[IRQ繞線的歷史發展]
依照我查到的資料，早期的作業系統Windows 95年代左右，PCI設備要使用哪一支IRQ中斷線是靠PCI卡上面的"跳線"去控制，所以有可能會因為兩個PCI設備跳同一支"IRQ#"而造成衝突導致當機或是藍底白字。
後來改用BIOS Setup Menu內去控制，也就是可以進去BIOS設定畫面去設定IRQ分配。
因此為了解決PCI設備越來越多，但是IRQ不夠用的情況，所以微軟找上的晶片廠商也就是Intel合作開發PIRQ Route Controller，簡單說就是微軟想在他的作業系統上面支援"共享IRQ中斷架構"的驅動程式，但是需要硬體配合，因此定義了PCI IRQ Routing Table來規範硬體線路要怎樣繞線，且需要BIOS支援哪些資訊。
[為什麼是PCI設備而不是ISA設備?]
因為當時PCI Bus取代了傳統的周邊匯流排，所以PCI設備橫行，且設備需要服務就是透過中斷請求線IRQ#請求服務，對於OS端來說，這個服務就是驅動程式，至於CPU如何把控制權交給OS，則是靠IDT (interrupt Description Table)，相關詳細資料請看Windows核心說明。
[跟DOS有關嗎?]
應該是無關，除非你在DOS下替你的PCI設備寫了一個驅動程式，或是你的PCI設備在DOS模式下要工作，不過應該也是沒啥機會這樣做吧，所以PIRQ Routing都是針對Windows作業系統而言，因為與設備驅動程式管理有關。
[Windows 作業系統的改變]
對於微軟自己定義的規範中，他最希望的就是能夠共享IRQ，所以在作業系統的改變就是要能分辨是哪個PCI Device透過IRQ發出請求，這是因為可能有好幾個PCI 設備都用同一支IRQ#中斷請求，所以OS 必須要能夠讓正確的驅動程式去服務發出中斷的設備，因此在撰寫OS 端的 Driver 時有了新的規範(針對共享IRQ的驅動程式有其規範)。
[Chipset的改變]
起先為了微軟的規範，Inetl 在南橋ICH上面多了幾支接腳(PIRQA~PIRQD)，這幾支接腳又有對應的暫存器可以組態他們，例如下面範例：
PIRQA Register 60h bit3:0 <--PIRQA那隻接腳的設定暫存器在LPC Reg60h，其中bit3:0定義如下
=================================================================================
IRQ Routing — R/W. (ISA compatible.)
Value IRQ
0000b Reserved
0001b Reserved
0010b Reserved
0011b IRQ3
0100b IRQ4
0101b IRQ5
0110b IRQ6
0111b IRQ7
...
由上面範例可以看出每支PIRQ接腳都可以用"軟體"設定的方式橋接到IRQ#的任何一支。
也由於上面範例我們可以知道，OS 必須"先知道哪些IRQ可以被使用" 還有"哪些IRQ已經被使用"，因為OS本身有自己配置IRQ#的演算方式，因此必須要先知道這些資訊，才有辦法去對PIRQ#繞線。
[BIOS的支援]
所以BIOS要提供"PIRQ Routing Table"給作業系統，然後OS就可以得到這些資訊，但是又因為OS版本不同(Win95/Win95/Win2000/WinXp or Acpi OS/non-ACPI OS..等分類)，所以透過的傳遞管道也不同。
[後來的演變]
隨著PCI設備越來越多PIRQ只有4支接腳已經不夠用，所以後來擴充到8支，分別是PIRQA~PIRQH。
至今2007，OS 與 Intel 在這部份的演變也越來越複雜，因為後來的Intel 提出了新一代的中斷控制器APIC，所以在南橋ICH內就分成了兩種中斷控制器PIC與I/O APIC兩種，又因為OS演變成ACPI OS，所以原先PCI IRQ Routing Table Spec內所描述的方式就變成了ACPI Spec內的方式，簡單說就是BIOS傳遞PIRQ Routing方式也從Legacy OS方式演變成ACPI Mode方式(原本Table放在記憶體，現在改放在ASL Code)。
另外由於南橋ICH有兩種PIC，所以進入ACPI OS時是採用Legacy PIC mode 還是APIC mode 也會影響BIOS提供PIRQ Routing Table的方式，所以在ACPI Mode 底下又分成APIC Mode方式或是Non-APIC Mode(PIC Mode)方式。
~~~轉載請註明出處~~~by 小華的部落格
[結論]
PIRQ#是南橋上面的接腳，連接到PCI 的INTA#~INTD#，原本INTA#~INTD#應該直接接到PIC上面的IRQ#接腳，但是因為IRQ#不夠用，所以微軟才與Intel合作，多做了幾支接腳出來，然後用軟體方式去配置這些多出來的接腳PIRQ#要繞線到哪個IRQ#，且作業系統的驅動程式可支援共享IRQ中斷，所以在Chipset 端把這種機制稱之為PIRQ Route Controller (具有PIRQ繞線功能的控制器，也就是某某一代的南橋開始把這個功能整合進去南橋晶片內)。
而BIOS所扮演的角色就是提供PIRQ Routing Table，這個Table的結構如同微軟的PCI IRQ Routing Table的規範，而當系統演變到ACPI 後，BIOS也改變了提供Table的方式，也就是改遵循ACPI Spec內的規範去提供這些資訊。
上述這些資訊只是我整理的筆記的一部分概要，詳細內容可以參考相關資料說明，畢竟我也是花了一個多星期的時間才整理出整個PIRQ的歷史，是對是錯我也不清楚，畢竟過去的架構我來不及參與，只能就我收集到的資料作一個描述，如有誤請先進指教。 ~~~轉載請註明出處~~~by 小華的部落格
[後記]
1)當ACPI OS 系統處在APIC Mode的時候，PIRQA~PIRQH會直接對應在APIC 的IRQ16~IRQ23而不需要繞線。
2)APIC 目前可提供的中斷請求線有 IRQ0~IRQ255 ，目前只使用IRQ0~IRQ23
3)APIC 前面的IRQ0#~IRQ15對應到PIC的IRQ0~IRQ15
4)PIRQ Routing 是指: IRQ不夠用才需要透過PIRQ Routing Controller繞線，所以只針對PIC，而APIC模式則不需要繞線。
4)APIC Mode只需要描述哪些PCI Device共用了哪些PIRQ線。
5)non-APIC mode則需要描述哪些PIC的IRQ#可以被使用，描述的內容如同PCI IRQ Routing Table，差別在於用ASL Code描述
6)APIC有分成Local APIC與I/O APIC，這邊所提到的都是指I/O APIC。
[Reference]
http://www.microsoft.com/whdc/archive/pciirq.mspx
http://www.microsoft.com/taiwan/whdc/system/CEC/ACPI-MP.mspx
http://www.google.com
[補充資料]
VGA IRQ的配置
早期VGA卡還在ISA時代的時候, 透過BIOS啟動系統時, 會得到interrupt 第一順位, 而且有固定存取區域在UMB(Upper Memory Black)裡頭與系統相對印; 在PnP時代, BIOS系統直接在啟動系統時給予IRQ#編號, 無論你是AGP or PCI都變成由BIOS指定位置, 而不再像ISA時代需要跟其他人搶系統控制權.
順便一提的是, MS系統推出雙螢幕(Dual VGA)的概念的時候, 一些VGA-BIOS沒規劃好的顯示卡就出現問題. 因為在BIOS啟動系統的時候, 會依照設定順序尋找開機起始用的顯示卡(預設是PCI), 結果因為有兩張PCI顯示卡(或者主機板的晶片採用SIS55xx系列, VIA早期586時代晶片都有這種現象), 反而推選不出一個可以啟動的System VGA, 變成必須在佈線的時候強制規定哪邊是佔用較高優先權的現象...
到了AGP時代, 變成系統直接佔用, 不再有IRQ衝突的事情.....對廠商對BIOS規劃人員也變得比較簡單點了....
display card在古老時代是不需要IRQ的,當時diplay card本身不過是被動式的介面,顯示記憶體都是由CPU來控制寫入或讀出與搬移(如HOYO兄所說),所以那時就是單純的使用 Linear address mapping 來處理,而遇到較大而複雜的畫面記憶體處理時,就用視訊記憶體頁切換來應付,然而隨著顯示的需求越來越複雜,VGA card和CPU間的溝通需求也越來越多,VGA本身也搭載了功能強大的GPU,可算是一個小的專門處理影像的CPU了.這時候 VGA Card不再是一個只會聽CPU命令的單元了,它開始會對CPU提出要求,以進行一些需要取用北橋資源的動作,此時就需要IRQ來做"舉手發言".
目前市面上仍然有一些VGA是不需要IRQ的,但並不代表它們不是高階顯示卡,而是視廠商所使用的技術而定.
一般的 VGA IRQ 預設大都在IRQ 11，除非有佔用系統會自動轉到別的IRQ...
PIRQ配置演算法(4 支PIRQ的時候)
PCI SLOT 中斷共有四個
INT a/b/c/d
一般的接法是
Slot1 a/b/c/d 接到南橋 a/b/c/d
Slot2 a/b/c/d 接到南橋 b/c/d/a
Slot3 a/b/c/d 接到南橋 c/d/a/b
Slot4 a/b/c/d 接到南橋 d/a/b/c
而卡上 通常是從 int a 接起
所以兩片使用一個中斷的PCI 卡會變成個別接到 int a / int b, 而不會通通都接到int a 了
PCI 要求裝置的中斷要共享，唯一缺點就是 "共享的部分" 要多消耗一些程式碼去確定中斷是給誰的
另有一些ON BOARD 的裝置已經固定接到其中的一些中斷訊號線上了，看看主機板說明書上有沒有寫
這樣你就可以知道INT a/b/c/d 哪些是完全可以獨立運作的。
中斷經過IRQ Routing table 去轉成我們常說的中斷號碼 IRQ# 這個在BIOS中可以設定，也可以自動配置。如果有獨立中斷的SLOT 就可以拿來用在IDE Card/SCSI Card這種講究效能的裝置上。
另外就是給一些卡使用，因為這些卡的驅動程式不肯跟別人分享中斷，如果分享就不肯工作。
還有一種卡和別人分享就容易當機。
有一些ISA 規格的裝置一定會佔用固定的中斷，如果不用可以DISABLE，不過 PCI 還是只有四個給你的SLOT用空再多也沒用要分享的依舊要分享
irq-0 Timer
irq-1 Keyboard
irq-2 Cascade
irq-3 Com2
irq-4 Com1
irq-7 LPT1
irq-8 RTC
irq-12 PS/2
irq-13 FPU
irq-14 IDE1
irq-15 IDE2
大部分的VGA 都沒有配中斷，另外 Win2k ACPI 會把IRQ routing table 通通都設成同一個中斷號碼 沒辦法改 效能會降低 因為每個PCI卡的驅動程式都會檢查一遍 看看是不是自己的中斷，每次也只會有一個說是他的中斷這在高速裝置是很糟糕的。
[我所知道的BIOS]->[系統架構] 2
任何 firmware 都有相對應的硬體;也唯有深入瞭解硬體,才能寫出好的 firmware ! (當然,對 programming language 很熟,有技巧的的人可以寫出好的 firmware,但是,另一個層面是:對硬體很瞭解,所以所寫的firmware 與 H/W 搭配良好,這也是另一種值得追求的地步)
BIOS 就是 "主機板的 F/W". 所以,它的對象就是主機板上的所有 devices. (為了後續的解說,我只列出一些,其他的坊間書上都可找到)
- [CPU]
=> central process unit. 依架構不同有分 Intel or AMD cpu. 其工作之一是: fetch code->decode it->fetch operands->calculate->store result.
- [North bridge]
=> 即俗稱的北橋. 常見的 Intel 945/P/G,965 等是其北橋晶片代號. 它可以約略區分成四個 blocks(H/W view)
1. Host interface: 即 與 CPU interface 的部分.
2. DRAM interface: 即與 DRAM interface的部分
3. Display interface: 即與 AGP/PCIe VGA interface的部分
4. Link interface: 即與 South bridge(南橋) interface的部分
簡單說,North bridge的功能是: Host block 承接 CPU 所 issue 的 cycle, 辨認(identify),並且將之 forward至 "正確的接收者" ( Ex. DRAM block, display block, or Link block )
所以,它像交通警察一樣,接收中央的命令,將來自四面八方的車流引導至正確的地方,讓整個城市的各部分各角落可以相互交流無虞.
-[South bridge]
=> 及俗稱的南橋. 常見的 Intel ICH7/8為其南橋晶片代號. 它"可能"包含以下的 blocks:
1. Link interface: 即呼應北橋的部分.
2. PCI block: 處理 PCI request部分(即 implement PCI spec H/W part)
3. ACPI block: implement ACPI H/W part
4. USB
5. Audio
6. SATA(AHCI)
7. ...
所以, 南橋裡面包含許多我們常見的名詞, USB/1394/SATA/HDA/TPM/PCIE...等
-[BIOS ROM]
=> 儲存 BIOS image的device. 常見的有 ISA ROM/LPC ROM/SPI ROM. 編譯出來的 BIOS binary file透過燒錄器或是 flash tool 燒錄到此 ROM中. 內容是0101...的 binary code
所以,總結來說: BIOS code被CPU fetch, 經過 decode後, 會轉發給NB.NB接到後也會自行decode 此 request;若是 與 DRAM有關的,則 forward to DRAM block;若與 display有關,則forward to display block;若是與 PCI有關的,則將之轉發給 SB(透過兩者中間的Link),請SB再找適合的人 Ex. USB, SATA, or 1394 controller ! ( 別忘了 PCI H/W是在SB裡...)
以上依序所講到的 CPU->NB->SB->ROM,將在後面的敘述中用來說明一些觀念及flow.
Summary:
1. BIOS可以說是 chipset's driver !!!
2. CPU所 issue 的 cycle會先抵達NB,由NB判定是給誰的;若不是 for DRAM or display,則會再轉發給SB,由它判定是要給誰的
BIOS 就是 "主機板的 F/W". 所以,它的對象就是主機板上的所有 devices. (為了後續的解說,我只列出一些,其他的坊間書上都可找到)
- [CPU]
=> central process unit. 依架構不同有分 Intel or AMD cpu. 其工作之一是: fetch code->decode it->fetch operands->calculate->store result.
- [North bridge]
=> 即俗稱的北橋. 常見的 Intel 945/P/G,965 等是其北橋晶片代號. 它可以約略區分成四個 blocks(H/W view)
1. Host interface: 即 與 CPU interface 的部分.
2. DRAM interface: 即與 DRAM interface的部分
3. Display interface: 即與 AGP/PCIe VGA interface的部分
4. Link interface: 即與 South bridge(南橋) interface的部分
簡單說,North bridge的功能是: Host block 承接 CPU 所 issue 的 cycle, 辨認(identify),並且將之 forward至 "正確的接收者" ( Ex. DRAM block, display block, or Link block )
所以,它像交通警察一樣,接收中央的命令,將來自四面八方的車流引導至正確的地方,讓整個城市的各部分各角落可以相互交流無虞.
-[South bridge]
=> 及俗稱的南橋. 常見的 Intel ICH7/8為其南橋晶片代號. 它"可能"包含以下的 blocks:
1. Link interface: 即呼應北橋的部分.
2. PCI block: 處理 PCI request部分(即 implement PCI spec H/W part)
3. ACPI block: implement ACPI H/W part
4. USB
5. Audio
6. SATA(AHCI)
7. ...
所以, 南橋裡面包含許多我們常見的名詞, USB/1394/SATA/HDA/TPM/PCIE...等
-[BIOS ROM]
=> 儲存 BIOS image的device. 常見的有 ISA ROM/LPC ROM/SPI ROM. 編譯出來的 BIOS binary file透過燒錄器或是 flash tool 燒錄到此 ROM中. 內容是0101...的 binary code
所以,總結來說: BIOS code被CPU fetch, 經過 decode後, 會轉發給NB.NB接到後也會自行decode 此 request;若是 與 DRAM有關的,則 forward to DRAM block;若與 display有關,則forward to display block;若是與 PCI有關的,則將之轉發給 SB(透過兩者中間的Link),請SB再找適合的人 Ex. USB, SATA, or 1394 controller ! ( 別忘了 PCI H/W是在SB裡...)
以上依序所講到的 CPU->NB->SB->ROM,將在後面的敘述中用來說明一些觀念及flow.
Summary:
1. BIOS可以說是 chipset's driver !!!
2. CPU所 issue 的 cycle會先抵達NB,由NB判定是給誰的;若不是 for DRAM or display,則會再轉發給SB,由它判定是要給誰的
星期三, 11月 14, 2007
BIOS 開發環境
這篇文章主要是概述 BIOS 開發環境下的一些基礎知識，有助於了解如何自己去撰寫一個屬於你自己的 BIOS。
大家都知道Legacy BIOS是使用Assembly 所撰寫，目前的UEFI則是使用C語言，但是不論是哪一種BIOS，其開發環境下的基礎知識都還是相同。
ㄧ般BIOS工程師開始學習BIOS Vendor所提供的BIOS Code時，最主要會學習下列幾個項目：
1.Build process : BIOS ROM是如何產生，這部份要去了解的是整個流程為何?
例如: (ㄧ堆Source code) --> 經過哪些Build process --> (產生BIOS.ROM)
2.Directory : BIOS Code的目錄架構為何? 哪些是屬於Framework/Kernel/Oem ?
3.Build Config : BIOS 相關參數的設定，每家Vendor設定方式都不同!
4.Build Tools : BIOS 建立時使用了哪些工具，ㄧ般都是MASM+VisualStudio+DDK+Bios Vendor自己開發的一些Tools。
5.Build your BIOS ROM : 如何建立你的第一個BIOS ROM，ㄧ般都是使用nmake/直接在IDE(整合開發環境下)下設定好，就可以直接去Buildㄧ個完整的BIOS ROM。
有了上述的整理分類，其實不難發現，實際上我們撰寫的BIOS code只是一個BIOS Vendor做出來的環境下(或稱為框架下)去"填寫"一些屬於我們的程式碼，就像是C語言的開發環境下你只需要知道在main(){.....} 的括號內去撰寫程式碼就好了，後面的事情BIOS Vendor都幫你做好了。
所以OEM/ODM端的BIOS能夠處理的東西都是比較偏向客戶端的需求而去撰寫一些程式碼，我們稱這些程式碼為"Features"。而這些部份就像你買Asus /Acer/...etc 不同家的電腦，裡面所能提供的功能會不同。
雖然好像看起來只是"填入"ㄧ些程式碼，但是這部分又與整個硬體運作以及BIOS Vendor所提供的程式碼的"穩定度"有很大的關係，所以如果只是單純修改這些程式碼約1年可以上手，但是如果要能處理bug，那麼可能就需要多年的經驗累積了。因此在這種OEM/ODM BIOS與BIOS Vendor分工合作的情況之下，OEM/ODM端的BIOS有自己負責解決問題的地方，而BIOS Vendor也有自己負責要處理的地方，大家相互合作。
說了這麼多，對於BIOS開發環境應該有所了解，但是最近案子開始在忙了，所以會寫Blog時間會比較少了，等過陣子等案子不忙的時候，我再告訴大家如何如果要實做一個類似BIOS vendor開發環境，你需要哪些工具，還有怎樣子做。
大家都知道Legacy BIOS是使用Assembly 所撰寫，目前的UEFI則是使用C語言，但是不論是哪一種BIOS，其開發環境下的基礎知識都還是相同。
ㄧ般BIOS工程師開始學習BIOS Vendor所提供的BIOS Code時，最主要會學習下列幾個項目：
1.Build process : BIOS ROM是如何產生，這部份要去了解的是整個流程為何?
例如: (ㄧ堆Source code) --> 經過哪些Build process --> (產生BIOS.ROM)
2.Directory : BIOS Code的目錄架構為何? 哪些是屬於Framework/Kernel/Oem ?
3.Build Config : BIOS 相關參數的設定，每家Vendor設定方式都不同!
4.Build Tools : BIOS 建立時使用了哪些工具，ㄧ般都是MASM+VisualStudio+DDK+Bios Vendor自己開發的一些Tools。
5.Build your BIOS ROM : 如何建立你的第一個BIOS ROM，ㄧ般都是使用nmake/直接在IDE(整合開發環境下)下設定好，就可以直接去Buildㄧ個完整的BIOS ROM。
有了上述的整理分類，其實不難發現，實際上我們撰寫的BIOS code只是一個BIOS Vendor做出來的環境下(或稱為框架下)去"填寫"一些屬於我們的程式碼，就像是C語言的開發環境下你只需要知道在main(){.....} 的括號內去撰寫程式碼就好了，後面的事情BIOS Vendor都幫你做好了。
所以OEM/ODM端的BIOS能夠處理的東西都是比較偏向客戶端的需求而去撰寫一些程式碼，我們稱這些程式碼為"Features"。而這些部份就像你買Asus /Acer/...etc 不同家的電腦，裡面所能提供的功能會不同。
雖然好像看起來只是"填入"ㄧ些程式碼，但是這部分又與整個硬體運作以及BIOS Vendor所提供的程式碼的"穩定度"有很大的關係，所以如果只是單純修改這些程式碼約1年可以上手，但是如果要能處理bug，那麼可能就需要多年的經驗累積了。因此在這種OEM/ODM BIOS與BIOS Vendor分工合作的情況之下，OEM/ODM端的BIOS有自己負責解決問題的地方，而BIOS Vendor也有自己負責要處理的地方，大家相互合作。
說了這麼多，對於BIOS開發環境應該有所了解，但是最近案子開始在忙了，所以會寫Blog時間會比較少了，等過陣子等案子不忙的時候，我再告訴大家如何如果要實做一個類似BIOS vendor開發環境，你需要哪些工具，還有怎樣子做。
星期日, 11月 04, 2007
BIOS's 神秘面紗
對於一般使用者來說，BIOS的存在與否有可能連系統從買進、使用、壞損後都還不知道有他的存在，但是對於進階的使用者來(DIY 玩家)，BIOS 的校調確可以增加對於系統的操控以及效能的調整。如圖所示，這是一般BIOS設定畫面，依照這家BIOS廠商的不同，所提供的設定畫面與功能也有所不同。
因此一般多數人的印象還是停留在對於BIOS 要如何設定與校調，因此對於一般想進入這個行業的新手們的入門資料也是非常的少。
目前市面上的書籍中對於BIOS比較有深入探討的是 旗標出版社 "BIOS Inside，BIOS研發技術剖析"，ㄧ共是兩版本，但書籍中比較著墨在 AMI BIOS 的程式碼撰寫方式以及工具的使用，對於系統平台部分著墨較少，但是卻也涵蓋了大部分的資訊，所以比較像AMI BIOS 新進員工訓練手冊。因此，對於想進入這個行業的人，我建議可以參考這本書中的指引，對於了解BIOS 工作性質會有許多的幫助。
至於有些人認為要不要 "很懂" 組合語言? 這部分我個人覺得不是那麼重要，因為了解系統架構會比你撰寫程式碼來的重要，畢竟程式語言只是一個工具，你只要懂工具的用法就可以了，懂得系統架構的人才能對於這些語言有更深入的體會，就像是有些人會寫組合語言，但是連邏輯位址/線性位址/實體位址都搞不清楚，還會把虛擬位址搞在ㄧ起。而實際上真正懂組合語言的人真的不多，像是我本身對於組合語言就還是懵懵懂懂的，這是因為我對於硬體架構還不是那麼了解，所以對於組合語言的精神我還無法掌握，但是對於工具的應用(用組合語言撰寫程式或是修改BIOS程式碼)卻也還可以符合工作上的需求。
我對於ㄧ般有興趣的人的建議是多去看一下IA32硬體架構的書籍(PC 硬體介面研究)，多了解組合語言用法，其他的就是多撰寫ㄧ些與BIOS/系統有關的程式，像是如何存取CMOS，如何呼叫BIOS提供的中斷，如何呼叫OS提供的中斷，如何存取硬碟資訊，如何列舉PCI設備...等，進階的部份就是如何切換CPU工作模式，中斷的管理...等，進階的部分一般Windows 程式書籍中會有提到。希望藉由這些資訊能夠幫助大家更了解如果要踏入 BIOS 行業你需要哪些知識。
OEM/ODM BIOS工程師的行情價: 嗯看公司...目前3x000NT(大學畢，不含公司分紅)...
如果換算其他公司算法(沒股票的那種)，約5x000~6x000NT*14 個月
星期四, 6月 19, 2008
NVRAM list v.s NVStore
最近接了一個新的案子,雖然還沒開始Run但是事前的準備也不能少，也因此遇到了新問題,所以在部落格留下紀錄以後好方便查詢!
在跟客戶接觸的過程中,他們要求我提供CMOS NVRAM List ,用過P公司的BIOS的人都知道, P公司會產生這個List ,而這個List其實就是對應我們在Setup Menu中的選項設定值(例如某個item內有Enable/Disable選項而選擇後的值會存放進去CMOS當中) ,有了這份List ,客戶就可以開發自己的工廠測試程式去修改CMOS內的設定值來達到他們的需求(不考慮Checksum問題時可以這樣做)。最常見的就是修改Boot Order (修改開機順序)，當然這些工具還是需要BIOS端的支援啦!
而我的問題在於EFI架構中為了一些安全性的考量,已經建議這些設定值的存放地方改至NVStore，即直接寫入至BIOS ROM中的某個規劃出來的區塊,因此我沒辦法直接修改CMOS來達到修改某個item的設定值,除非你在POST的BIOS code中去讀取你自己定義的CMOS位置然後在去改變他,這部分我們學長已經是這樣子的方式來修改BootOrder!
方式一:
AP修改CMOS --> POST過程中BIOS去讀取CMOS值 -->BIOS修改至相關Variable位置
有關於NVStore部分,在不同的bios廠商中做法也是不見得會完全依照當初的建議去做,像是P公司現階段的BIOS code就比較尷尬...因為他不是完全的EFI 架構,所以有一部分還是存放在NVRAM 中 ,一部分是存放在NVStore ，所以在過度期中他還是有提供NVRAM list,只可惜這次的案子不是使用p公司的BIOS =.=!
路不通就自己通, 因此在EFI 架構下我自己寫了一個介面給AP端使用(修改cmos在由POST 開機時讀取出來修改的方式我學長已經實做成功,所以我才試試看改寫另一種方式),方式是透過SW SMI Driver來註冊一個SMI Routine ，然後在這個Routne中去得到AP端傳進來的RAM Buffer,而這塊RAM Buffer中說明了我要去修改/讀取哪一個NV Variable 以及要寫入/回傳的資料 ,因此在DOS或是Windows下就可以很方便的透過這個介面去修改設定值。
而ap端我是採用TC++ 3.0 先去配置一塊記憶體,然後把參數寫進去這塊記憶體,然後用ESI指向這塊記憶體,接著發送SW SMI ，如下面所示
type struct {
DWORD Protocol; (Byte/word/dword)
DWORD VarIndex;
DWORD VarData;
}OEM_BUFFER
STATUS OEM_SMI_Trigger(OEM_BUFFER *inputbuf,OEM_BUFFER *outputbuf)
{
AH=Select Fun (Read/Write)
AL=SW SMI function number
ESI=input buffer
EDI=output buffer
EBX = Signature '$OEM'
DX=B2h
}
方式二:
AP端將參數寫至RAM --> AP端設定好暫存器,指向存放參數的RAM --> AP端觸發SMI --> BIOS透過暫存器得到參數 --> BIOS SMM code設定相關Variable.
結論:
透過方式一的方式簡單又方便,但是缺點在於傳遞的資料量有限,且如果變數過多時會很麻煩!
透過方式二的方式複雜但是可以傳遞較大的資料量,應用也比較廣,變數過多也無所謂,因為BIOS端會把這些item都集中然後放在某個Structure中,所以只要指定好Index就可以了(以前叫做Token),其他應用可以類似寫一個燒BIOS ROM的介面,透過BIOS本身的Code去燒...目前某家EFI BIOS公司就是這樣子去開發Flash utility...
在跟客戶接觸的過程中,他們要求我提供CMOS NVRAM List ,用過P公司的BIOS的人都知道, P公司會產生這個List ,而這個List其實就是對應我們在Setup Menu中的選項設定值(例如某個item內有Enable/Disable選項而選擇後的值會存放進去CMOS當中) ,有了這份List ,客戶就可以開發自己的工廠測試程式去修改CMOS內的設定值來達到他們的需求(不考慮Checksum問題時可以這樣做)。最常見的就是修改Boot Order (修改開機順序)，當然這些工具還是需要BIOS端的支援啦!
而我的問題在於EFI架構中為了一些安全性的考量,已經建議這些設定值的存放地方改至NVStore，即直接寫入至BIOS ROM中的某個規劃出來的區塊,因此我沒辦法直接修改CMOS來達到修改某個item的設定值,除非你在POST的BIOS code中去讀取你自己定義的CMOS位置然後在去改變他,這部分我們學長已經是這樣子的方式來修改BootOrder!
方式一:
AP修改CMOS --> POST過程中BIOS去讀取CMOS值 -->BIOS修改至相關Variable位置
有關於NVStore部分,在不同的bios廠商中做法也是不見得會完全依照當初的建議去做,像是P公司現階段的BIOS code就比較尷尬...因為他不是完全的EFI 架構,所以有一部分還是存放在NVRAM 中 ,一部分是存放在NVStore ，所以在過度期中他還是有提供NVRAM list,只可惜這次的案子不是使用p公司的BIOS =.=!
路不通就自己通, 因此在EFI 架構下我自己寫了一個介面給AP端使用(修改cmos在由POST 開機時讀取出來修改的方式我學長已經實做成功,所以我才試試看改寫另一種方式),方式是透過SW SMI Driver來註冊一個SMI Routine ，然後在這個Routne中去得到AP端傳進來的RAM Buffer,而這塊RAM Buffer中說明了我要去修改/讀取哪一個NV Variable 以及要寫入/回傳的資料 ,因此在DOS或是Windows下就可以很方便的透過這個介面去修改設定值。
而ap端我是採用TC++ 3.0 先去配置一塊記憶體,然後把參數寫進去這塊記憶體,然後用ESI指向這塊記憶體,接著發送SW SMI ，如下面所示
type struct {
DWORD Protocol; (Byte/word/dword)
DWORD VarIndex;
DWORD VarData;
}OEM_BUFFER
STATUS OEM_SMI_Trigger(OEM_BUFFER *inputbuf,OEM_BUFFER *outputbuf)
{
AH=Select Fun (Read/Write)
AL=SW SMI function number
ESI=input buffer
EDI=output buffer
EBX = Signature '$OEM'
DX=B2h
}
方式二:
AP端將參數寫至RAM --> AP端設定好暫存器,指向存放參數的RAM --> AP端觸發SMI --> BIOS透過暫存器得到參數 --> BIOS SMM code設定相關Variable.
結論:
透過方式一的方式簡單又方便,但是缺點在於傳遞的資料量有限,且如果變數過多時會很麻煩!
透過方式二的方式複雜但是可以傳遞較大的資料量,應用也比較廣,變數過多也無所謂,因為BIOS端會把這些item都集中然後放在某個Structure中,所以只要指定好Index就可以了(以前叫做Token),其他應用可以類似寫一個燒BIOS ROM的介面,透過BIOS本身的Code去燒...目前某家EFI BIOS公司就是這樣子去開發Flash utility...
星期一, 10月 08, 2007
[我所知道的BIOS]->[DRAM Sizing] (1) 7
現在要提到的是BIOS POST中一個重要的 task : DRAM sizing !
它主要的工作是:讓我們所插的記憶體可以正常且穩定的運作 !
[Q] 為什麼穩定的記憶體這麼重要 ?
=> 因為,有太多東西需要存放其上了,例如: BIOS code(之後在 shadow部分會提到), 開機之後所需要的 device drivers and OS,etc...假如記憶體不穩,在存取 memory時無法得到需要的資料,或是根本連 read or write都不行,那麼便會發現: 不是 system hang(maybe randomly) during POST ,或是進OS後 blue screen...
所以,"BIOS DRAM sizing不好" 是系統不穩的原因之一. (地基都不穩了,怎能奢求其上的房子可以堅固 ^_^ )
在介紹 DRAM sizing之前,先稍微簡單說明 DRAM 的相關知識.(若有不足或錯誤之處,請不吝指正...)
1. DRAM chip 可看做是 square array;基本的單位 is cell. 每一個 cell 是由數個電晶體組成(depends on cell width;記得是: 1 bit 由一個電晶體組成,可以記錄 0 and 1的資訊; 1 cell 可能含 n bits;讀取DRAM cell屬於破壞性的讀取,因此讀取的同時常伴隨著 "refresh" <- 與 SRAM不同)
2. 要存取 DRAM chip 中的資料,必須提供 row and column address;這兩個 address是有先後順序的;意即: row address先送,然後再送 column address to chip.
(呼應前面所言: square array,類似 x,y 定址) 最後 指到的 data 將被放到 data bus上,CPU會讀走
*若有空可以上網查: 為什麼DRAM chip所需的 pins 是減半(half)的 ^_^
3. DRAM controller 現在一般都做在 chipset 中,Ex. NB內(AMD K8 CPU則是將 memory controller做在CPU內 ,for better performance);其工作便是 interfacing DRAM chip;充作其他 devices(Ex. CPU,DMA controller...etc) 與 DRAM chip 之間的橋樑 !
Ex. In BIOS ,寫下列的 code 欲 "read", "記憶體", "位置8處"的資料:
xor ax, ax
mov es, ax
mov edi, 00000008h
mov al, BYTE PTR es:[edi]
[00000008h] 是 programmer所"知"的 linear address,但DRAM chip 只認得 MA0~MAx,BA0~BA1..etc訊號,如何溝通 ? => 靠 DRAM controller 來轉換 !!!
4. DRAM access time => 從 DRAM chip 接到 address signals 直到 valid data 出現在 data bus上的時間(assume "read" memory),稱之;也是DRAM chip的特性之一.
5. 現今常見的 DRAM is DDR/DDR2 SDRAM. 所謂的 "S"DRAM 指的是 Synchronous DRAM,即 DRAM operation 都是參考一個 clock執行的;即與它同步(synchronous). DDR 指得是 Double Data Rate,亦即在 clock 的 rising and falling edge都可以傳資料. 而DDR2指的是: DDR的 "第二代" ! (別想成 DDR2 = DDR x 2 !!! 雖然剛好有些數值是兩倍的關係...)
Ex. DDR2 533(or called PC2 4200) =>
1. "2" means DDR2
2. 533 is transfer rate( 每一秒可做 533筆資料 transfer )
3. 4200 means: 533筆資料/s * 每筆 8 bytes( => 64 bit width) ~= 4200MB/s
下一章將介紹 DRAM sizing 的 flow/information !
它主要的工作是:讓我們所插的記憶體可以正常且穩定的運作 !
[Q] 為什麼穩定的記憶體這麼重要 ?
=> 因為,有太多東西需要存放其上了,例如: BIOS code(之後在 shadow部分會提到), 開機之後所需要的 device drivers and OS,etc...假如記憶體不穩,在存取 memory時無法得到需要的資料,或是根本連 read or write都不行,那麼便會發現: 不是 system hang(maybe randomly) during POST ,或是進OS後 blue screen...
所以,"BIOS DRAM sizing不好" 是系統不穩的原因之一. (地基都不穩了,怎能奢求其上的房子可以堅固 ^_^ )
在介紹 DRAM sizing之前,先稍微簡單說明 DRAM 的相關知識.(若有不足或錯誤之處,請不吝指正...)
1. DRAM chip 可看做是 square array;基本的單位 is cell. 每一個 cell 是由數個電晶體組成(depends on cell width;記得是: 1 bit 由一個電晶體組成,可以記錄 0 and 1的資訊; 1 cell 可能含 n bits;讀取DRAM cell屬於破壞性的讀取,因此讀取的同時常伴隨著 "refresh" <- 與 SRAM不同)
2. 要存取 DRAM chip 中的資料,必須提供 row and column address;這兩個 address是有先後順序的;意即: row address先送,然後再送 column address to chip.
(呼應前面所言: square array,類似 x,y 定址) 最後 指到的 data 將被放到 data bus上,CPU會讀走
*若有空可以上網查: 為什麼DRAM chip所需的 pins 是減半(half)的 ^_^
3. DRAM controller 現在一般都做在 chipset 中,Ex. NB內(AMD K8 CPU則是將 memory controller做在CPU內 ,for better performance);其工作便是 interfacing DRAM chip;充作其他 devices(Ex. CPU,DMA controller...etc) 與 DRAM chip 之間的橋樑 !
Ex. In BIOS ,寫下列的 code 欲 "read", "記憶體", "位置8處"的資料:
xor ax, ax
mov es, ax
mov edi, 00000008h
mov al, BYTE PTR es:[edi]
[00000008h] 是 programmer所"知"的 linear address,但DRAM chip 只認得 MA0~MAx,BA0~BA1..etc訊號,如何溝通 ? => 靠 DRAM controller 來轉換 !!!
4. DRAM access time => 從 DRAM chip 接到 address signals 直到 valid data 出現在 data bus上的時間(assume "read" memory),稱之;也是DRAM chip的特性之一.
5. 現今常見的 DRAM is DDR/DDR2 SDRAM. 所謂的 "S"DRAM 指的是 Synchronous DRAM,即 DRAM operation 都是參考一個 clock執行的;即與它同步(synchronous). DDR 指得是 Double Data Rate,亦即在 clock 的 rising and falling edge都可以傳資料. 而DDR2指的是: DDR的 "第二代" ! (別想成 DDR2 = DDR x 2 !!! 雖然剛好有些數值是兩倍的關係...)
Ex. DDR2 533(or called PC2 4200) =>
1. "2" means DDR2
2. 533 is transfer rate( 每一秒可做 533筆資料 transfer )
3. 4200 means: 533筆資料/s * 每筆 8 bytes( => 64 bit width) ~= 4200MB/s
下一章將介紹 DRAM sizing 的 flow/information !
星期四, 9月 27, 2007
[我所知道的BIOS]->[Chipset Config] 5
一旦正確的頻率供給給system後, BIOS便依據既定的POST table(類似行程表)來做事. 首先,與chipset最為相關的便是 [chipset config stage]. 意即,在此階段BIOS必須對 chipset registers填入正確的值,俾使其正常運作. 一般而言,要config下列的 devices:
- NB(還記得前面有提過北橋內部約可分 4 blocks; "有些" blocks 需要 在此 program...)
- SB(即 PCI-ISA bridge)
- ACPI registers
- USB registers
- SATA registers
- PATA registers
...
* 在此所謂的 registers指的是: PCI config registers(除了ACPI registers以外). PCI spec所定義的 PCI config registers 00~3Fh 為 PCI header part,這個範圍的registers並不是此階段的主要工作(當然還是會touch,只是不多),而是稍後BIOS PCI kernel的事情.此階段將 focus on :offset 40h以後的 registers,因為,這些是 device specific的部分,是 chipset自己加function/feature之處 !!!
* ACPI registers通常透過 IO 來存取
Ex. // assume ACPI Base is 800h,要 access ACPI Reg55h
mov dx, 855h
in al, dx ; <- al = ACPI Reg55h's value
* 上述所列的 devices多為 PCI device,也都有唯一的PFA(PCI Function Address,即 bus#,device#,func#),也因此,只要對 device 下 PCI configuration read/write便可以 config device registers.
Ex. 假設: set SATA register offset 52h bit3 = 1;SATA controller PFA is (0,4,3)
=> 簡單的 assembly can be:
mov eax, 80002750h
mov dx, 0cf8h
out dx, eax
mov dx, 0cfeh
in al, dx
or al, 00001000b
out dx, al
事實上每家BIOS都 maintain many "tables" 來說明: 哪一個 device 中的哪些 registers要填?值.相關的 access routine都已經寫好. Programmer只需更改表裡面的值即可 ^_^
*當有人要求改 register setting時,我們必須知道三件事:
1. why (為什麼要改?)
2. what(改成何值?)
3. when(什麼點改?)
*對於 BIOS kernel與 OEM coding的人言,這部分會是較少碰觸的,因為,這些code會由 chipset porting的人負責撰寫及維護.
- NB(還記得前面有提過北橋內部約可分 4 blocks; "有些" blocks 需要 在此 program...)
- SB(即 PCI-ISA bridge)
- ACPI registers
- USB registers
- SATA registers
- PATA registers
...
* 在此所謂的 registers指的是: PCI config registers(除了ACPI registers以外). PCI spec所定義的 PCI config registers 00~3Fh 為 PCI header part,這個範圍的registers並不是此階段的主要工作(當然還是會touch,只是不多),而是稍後BIOS PCI kernel的事情.此階段將 focus on :offset 40h以後的 registers,因為,這些是 device specific的部分,是 chipset自己加function/feature之處 !!!
* ACPI registers通常透過 IO 來存取
Ex. // assume ACPI Base is 800h,要 access ACPI Reg55h
mov dx, 855h
in al, dx ; <- al = ACPI Reg55h's value
* 上述所列的 devices多為 PCI device,也都有唯一的PFA(PCI Function Address,即 bus#,device#,func#),也因此,只要對 device 下 PCI configuration read/write便可以 config device registers.
Ex. 假設: set SATA register offset 52h bit3 = 1;SATA controller PFA is (0,4,3)
=> 簡單的 assembly can be:
mov eax, 80002750h
mov dx, 0cf8h
out dx, eax
mov dx, 0cfeh
in al, dx
or al, 00001000b
out dx, al
事實上每家BIOS都 maintain many "tables" 來說明: 哪一個 device 中的哪些 registers要填?值.相關的 access routine都已經寫好. Programmer只需更改表裡面的值即可 ^_^
*當有人要求改 register setting時,我們必須知道三件事:
1. why (為什麼要改?)
2. what(改成何值?)
3. when(什麼點改?)
*對於 BIOS kernel與 OEM coding的人言,這部分會是較少碰觸的,因為,這些code會由 chipset porting的人負責撰寫及維護.
星期二, 9月 04, 2012
快快樂樂學EFI (1)
快快樂樂學EFI
Harrison Hsieh 2010/07/19
Chap 1 EFI How to
1.1 概論
有感於當初學習EFI的時候是直接經由BIOS vendor: "I公司"的網路上的訓練課程以及他們派了一組人來幫我們上了一星期Bring up之後，就直接在客戶的案子上邊做邊學，所以很多EFI基本的基礎都沒有學好!因此，最近想化整為零把EFI 重頭學習一遍! 那EFI 入門該學些甚麼呢?! 個人覺得，工欲善其事必先利其器! 所以先去抓一套可以編譯工具以及一套EDK或是 EFI Tool kits 來學習是最簡單的方式! 所以我們的學習目標就是了解甚麼是EFI/UEFI ，然後再告訴你如何去找到你需要的資料以及建構出一個可以撰寫EFI code的環境。
1.2 EFI 歷史回顧
Extensible Firmware Interface (EFI，可擴充韌體介面) 是一個規範，他規範了一個介面，界於作業系統(例如: Windows)與平台韌體(Platform firmware)之間的一個橋樑。 EFI 的改進是被用來取代傳統BIOS的介面(這個傳統的介面被稱之為IBM PC compatible PC 的BIOS或稱之為Legacy BIOS). 最初EFI是由Intel 所主導發展，Intel 已於2005年此規範交給目前UEFI論壇(Unified EFI Forum) 的會員一起共同維護與推廣，這便是眾所皆知的UEFI (Unified EFI，統一的EFI).
最初EFI發展動機是為了在1990年中的Intel-HP Itanium 系統，當時的PC BIOS有一個限制(支援16 bit 的處理器模式，1MB 位址空間與AT 硬體架構)，而這個限制使的他無法支援大型伺服器平台的系統Intel-HP Itanium。 最初的時候Intel 只是為了解決這些BIOS啟動時的限制，後來就乾脆改變它的名稱，且稱之為EFI。
Intel Platform Innovation Framework for EFI
Intel 在其平台上為了EFI去建立了一個新框架(Framework)，而這個框架的最初代號叫做Tiano，這個框架非常的完整，它包含了EFI對原本傳統韌體的所有支援，他也可以透過所謂的compatibility support module(CSM)來支援傳統的PC BIOS，簡單說就是傳統BIOS能做的EFI也能做，但是不是完整支援就要看CSM支援的程度。
特別是，這個框架包含了在Power- On後，所有必要的初始化步驟去初始化一個平台(Platform);但是這些步驟的運作並沒有被定義在EFI specification內，而是被定義在 Platform Initialization Specification(簡稱PI Spec)內的章節。 Intel 並沒有將這個架構完整的開放給一般的End-User知道，他只有開放這些資訊給一些獨立的BIOS 廠商(稱之為IBV)，像是安邁 (American Megatrends ，AMI) 或是系微(Insyde Software)、鳳凰科技(Phoenix) …等的BIOS韌體供應商。
而在TianoCore project(也就是所謂的EFI Developer Kit ，EDK)的Open source之中，會提到如何去開發這個Framework。這個開發工具中含括了EFI的一些硬體初始化的程式碼(只針對一些硬體，但並不包含韌體本身) ，至於這些程式碼的授權包含BSD license 和 Eclipse Public License…等。
而Tiano是為了取代BIOS的一種框架，所以透過EFI可以讓PC的設備自己撰寫一個驅動程式來管理這個設備。而對於開放原始碼來說，這也代表大家可以從TianoCore.org 下載這個專案，然後以BSD（Berkley Software Distribution）的授權方式來生產你的產品。BSD的授權，你自己去修改它的軟體並且發展出屬於你自己的產品，但BSD並不會去要求你把修改的地方公開出來，而這種方法會有助於你去保護你的智慧財產權。
歷史故事簡略介紹完了，廢話不多說我們就馬上進入EFI 世界中，告訴你一個EFI的環境需要哪些工具來編譯、去哪裡下載EFI 工具包、如何建構你的編譯環境。
1.3 Compiler 工具
為了能夠編譯一套EDK或是EFI Tool kits ，你會需要使用到 WinDDK或是VisualStudio，這是為了提供一些Compiler 工具像是C的Compiler : CL.EXE或是像Lib工具: LIB.EXE 以及連結工具Link.exe...etc
另外你可能還需要使用到MASM 來組譯一些少部分的組合語言程式碼，因此軟體需求如下:
(1) WinDDK version 3790.11830(EFI Tool kits預設)/ VisualStudio 2003(EDK預設)/VisualStudio 2005/VisualStudio 2008
(2) EFI Tools Kit /EDK source code.
(2) EFI Tools Kit /EDK source code.
(3) MASM
(4) TortoiseSVN
(4) TortoiseSVN
1.4 EFI Resource
在茫茫網海中，如何蒐尋EFI 相關資源?! 小弟我不是幫Google 打廣告，是因為我常使用他去找資料! 那我們要輸入哪些關鍵字可以找到我們要的資料呢?
首先進入Google搜尋引擎，輸入關鍵字 "EFI EDK"，你就會看到下面的連結: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK
目前EFI 相關資訊比較完整的地方就是這個網站，裡面你可以下載到你需要的EFI Tool kit/EDK ，並且有一些相關的文件可以幫助你開始你的EFI之旅。
1.5 EFI Tool Kits
接下來我們就開始看看這些不同的專案有哪些是可以幫助我們入門，首先要介紹的是 EFI 工具組(EFI Tool Kits)，他是一個可以支援快速開發EFI 應用程式的一個環境，讓你可以快速的開發32 bit/64bit 的EFI應用程式。
接下來我們就開始看看這些不同的專案有哪些是可以幫助我們入門，首先要介紹的是 EFI 工具組(EFI Tool Kits)，他是一個可以支援快速開發EFI 應用程式的一個環境，讓你可以快速的開發32 bit/64bit 的EFI應用程式。
這些應用程式包含 : EFI based applications, protocols, device drivers, EFI shells 以及不同平台的 OS loaders (IA-32, IA-64(IPF) and Intel 64(EM64T or X64) platforms)，你可以透過他的Source Repository下載。
在下載之後，如何得知你下載的EFI Tool kit 版本 : 例如 D:\efitoolkit\doc\RELNOTE.pdf 文件內會有版本，如下圖所示:
1.6 EFI Dev Kit (EDK) : http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK
EDK指的是Open-source的一個EFI “Framwork”元件，英特爾依照EFI規範所實做出來的一套Code，當時的開發的代號為“Tiano”。
EDK的基本上是一個範例元件，裡面有為框架的基礎程式碼(Framework's Foundation code)和驅動程序範例(Sample Driver)。
EDK也是一個開發工具包，可以用來Debugging/Testing EFI 的Framework's driver。
你可以透過下面的連結去取得一些相關的資訊以及說明:
(1) EDK如何開始 : EDK Getting Started Guide 或是 http://ncu.dl.sourceforge.net/project/efidevkit/Edk%20Getting%20Started%20Guide%5B1%5D.0.41.pdf
從下圖中的紅色框框的地方就是SVN下載的連結:
1.7 Download EDK/EFI Tool kits
首先，你必須先安裝 TortoiseSVN，這是一個版本控制的軟體，可以幫助你去Server端把code抓下來! 如果你沒有使用過的人就請先研究看看這個東西要如何使用，這邊就不多說明!
http://tortoisesvn.tigris.org/
http://tortoisesvn.tigris.org/
接著，透過這個TortoiseSVN去抓一套最新版的EDK /EFI Tool kits 下來! 方法很簡單，就是透過TortoiseSVN的Export功能，在他的URL地方輸入你要抓的Code的位置(也就是前面提到的Source Repository)，然後輸入好Export directory(例如存放到 D:\EfiToolKit )，然後就等他下載好就可以了，例如下面的圖示與步驟: https://efi-toolkit.svn.sourceforge.net/svnroot/efi-toolkit/trunk/efi-toolkit (下載EFI Tool Kits)
1.8 Reference
UEFI spec : http://www.uefi.org/specs
How to get WinDDK : http://www.microsoft.com/whdc/DevTools/WDK/WDKpkg.mspx
UEFI Programming : http://x86asm.net/articles/uefi-programming-first-steps/index.html
Wiki : http://zh.wikipedia.org/zh-tw/%E7%BB%9F%E4%B8%80%E5%8F%AF%E6%89%A9%E5%B1%95%E5%9B%BA%E4%BB%B6%E6%8E%A5%E5%8F%A3
UEFI Programming : http://x86asm.net/articles/uefi-programming-first-steps/index.html
Wiki : http://zh.wikipedia.org/zh-tw/%E7%BB%9F%E4%B8%80%E5%8F%AF%E6%89%A9%E5%B1%95%E5%9B%BA%E4%BB%B6%E6%8E%A5%E5%8F%A3
訂閱：
文章 (Atom)