這是篇轉載來的文章，如果作者看到覺得有侵害到您的權益，請再告訴 Heresy。 XP Pro 的遠端桌面只允許一個人連線，當其他使用者使用遠端桌面連線到 XP Pro 時，本機使用者會被強制登出。 只要完成下列步驟，就可以解除這個限制，經實測確實可行（測試機器為 XP Pro SP2 Vol 版本，本機主控台一個工作階段加上兩部電腦遠端登入）。 注意： 問答集： 此外： 有人把步驟寫成批次檔，install 一下就好了 http://concurrentremotesessions.netfirms.com/Concurrent_Remote_sessions_SP2.zipXP 的終端機也能多人同時登入！
答：據聞取自 XP SP2 RC1，termsrv.dll 版號 5.1.2600.2055。
答：不清楚，個人並不使用 [自動更新]。照理說如果這個檔案沒有被發現有弱點，MS 應該不會釋出更新。
答：不清楚，個人沒有 Home 版本，只有在 XP Pro 版本測試過可行。或許您可以試試然後告訴大家結果。
答：不清楚，請自行負擔所有風險。
裡面的批次檔寫死成 c:\windows, 若 windows xp 不是裝在 c:, 需自行修改其實用 %windir% 就好了
2008年12月29日 星期一
轉貼：XP 的終端機多人同時登入
2008年10月31日 星期五
[轉載]如何成為一位傑出的工程師
如何成為一位傑出的工程師
How to be a Star Engineer
Robert E. Kelley, Carnegie Mellon University
(Robert E. Kelley, "How to be a star engineer," IEEE Spectrum, pp. 51-58, Oct. 1999.)
翻譯：馬仕毅
在1985 年，我被問了一些問題,從那時起,我就開始找尋真正的答案。提出問題的是貝爾實驗室(那是仍然是AT&T的一部分，現在屬於 Lucent Technologies Inc.)。貝爾實驗室由全世界最好的大學中聘用了最優秀，最聰明的畢業生,然而, 最後只有少數的人真正發揮他們的潛力而成為卓越的工程師。大部分的新進人員發展成可以穩定地完成任務的執行者，生產力並沒有特別突出，無法幫助貝爾實驗室 在提昇AT&T的市場競爭力方面，做出顯著的貢獻。
貝爾實驗室想要知道的是：傑出的工程師和普通的工程師到底有什麼不同？傑出與否是由天份來決定？還是可以經由學習得來？可不可以設計一套提昇生產力的計畫來幫助表現平平的員工成為傑出的人才？
不 只有公司才會尋求這些問題的答案。由1985年開始，幾乎所有我遇到的工程師都希望能夠增加自己的生產力。他們覺得自己也可以出類拔萃，他們不喜 歡被同事的光芒所掩蓋。因此他們不斷地努力求進步。在現今的職場中，資源越來越少,工作的要求卻越來越多。全球化的競爭，購併風氣,企業裁員使得每位員工 所承擔的責任越來越重大，而可利用的資源卻比以前少。環顧你的四周，和五年前比較，那位不是比以前工作更努力，工時更長？誰不是待完成的工作一堆，好多的 電話和電子郵件還沒回？大家都在暗自擔心，如果不能再提高生產力，下一個被裁員的會不會是自己？誰不希望能夠重新掌握自己的生活-在工作和個人生活中取得 一個更好的平衡點？每個人都聽過：更聰明地工作(work smarter)，只是似乎沒人知道那是什麼意思。
我 和我的同事從那時起就開始研究公司和個人生產力的問題。來自貝爾實驗室，3M，及惠普公司總計超過一千位工程師在這個研究的過程中，同時扮演了研 究夥伴及受試者的角色。為了瞭解傑出工程師的秘密，我們使用了問卷調查，直接觀察，工作日記，焦點團隊(focus groups)，以及面試等方法來收集資料。並在適當的時候使用統計分析，內容分析(content analysis)，及反覆的模型建立(iterative model building)等方法。
許多其他的公司也都參與了這個過 程，包含了以電機工程師為重心的Analog Devices, Fore Systems, Air Touch，以及一些包含其他領域工程師的公司如Shell Oil, Kimberly Clark等。這些公司採用了我們的生產力提昇計畫。有效地將表現普通的員工轉換成傑出的工程師，而在這個過程中，也讓我們對於產生傑出表現的關鍵因素有 了更多的了解。
通往傑出之路
Lai及Henry在進入貝爾實驗室時，兩人的背景近 似。都是由頂尖的大學畢業，平均成績3.8(GPA)。都曾經在電腦公司做過暑期工讀，而且都 獲得教授的全力推薦。然而，在剛進公司的前六個月，兩人採取了截然不同的態度來面對公司指派的工作。上午的時間，他們需要上有關電話技術以及貝爾實驗室工 作流程的課。下午的時間則參與一些暖身計畫(break-in projects)，這是一些需要完成的次要工作，即使是做得很差也不至於對重要的計畫造成影響。
Henry像在寫畢業論文或是準備考試似的將自己關在辦公室中。他收集了許多的技術文件以深入了解最新的技術進展，只有在上廁所或是參加必要的會議時才會離開辦公室。他記得當時的想法是『最重要的事情是：我是否可以證明給我的同事看，在技術上我真的很行』
Lai 每個下午安排的三個小時的時間來完成指派的工作以及增進技術上的技能。一有多出來的時間，她會向其他的同事自我介紹，同時了解一下他們正在進 行的計畫。如果有同事需要幫忙或是時程的壓力很大，她會自告奮勇要幫忙。雖然她對新的工作環境文化不熟，她的同事們還是覺得很窩心。特別是這些本來不是她 的問題。
有一天下午，有一位同事正在和一個困難的程式奮戰，而整個軟體計畫的時程只剩一週了。Lai以前在修一門高等課程時學過一個新的 程式工具，她覺得應 該可以應付這個程式，所以她主動提出要幫忙寫這個程式，這樣她的同事就可以專心應付更大的計畫。另一次，有一些複雜的軟體工具需要安裝在每個人的PC上。 依照以前的作法，是由每個人自己在電腦上安裝，有問題自己解決。Lai在以前暑期工讀的時候也曾遇過類似的狀況，她覺得由一個人來安裝這個軟體到所有的電 腦上比較合理。因此她主動建議由她來做。但是這個安裝的動作比想像中要困難，總共需要兩週的時間。比她原先估計的四天要多出很多。她原本可以放棄這個建 議，但是她仍然將這個工作實行完成。雖然她有好幾天必須提早到公司並且加班到很晚，才不會影響到白天的上課及計畫的進度。
六個月之後，Henry和Lai都完成了他們的技術課程以及第一個任務。他們的計畫執行成效都被評估為良好而且具有技術上的競爭力。實際上，Henry的計畫成果在技術上可能要比Lai來的高明一些。
然而在同事之間的認同度方面，Henry顯然比較不足。雖然大家都覺得他還好相處，同事們還是認為他比較像獨行俠。對於技術的部份相當熟練，但是未必能將他的技能和其他的同事分享。他的行事態度還是和在學校時一樣，只在乎個別的表現。
在另一方面，Lai給別人的印象就比較主動積極。她肯主動發掘並解決問題，即使那並不在她的責任範圍內。同事們都覺得她好像進入實驗室不只六個月了。當然，經理們也注意到了Lai具有成為傑出工程師的特質。已經開始考慮要讓她參與更重要的計畫了。
大 部分的人(如Henry)都對於傑出工作能力的成因有自己的理論，然而，大多數都錯得很離譜。過去14年來，我們對於傑出工程師的成因，有許多令 人吃驚的發現，也打破了許多很普遍的迷思。我們的第一個發現是：老闆們和同事們眼中的傑出人才往往差異很大。我們首先請經理人列出他們心目中的傑出人選， 然後再建議他們篩選這些人選，請他們想一想如果他們有很重要的計畫要執行，或是重大計畫有什麼緊急狀況，需要特種部隊來解決問題，或是自己要出來創業，需 要聘請一些高手時，誰是最佳人選。當我們將這張表拿給表現傑出的工程師們看時，他們往往對老闆們的選擇嗤之以鼻。『Joe怎麼可能會入選？他已經好幾年沒 做什麼事了。還有，Maria 怎麼沒在上面？每個人有問題卡住了或是需要新點子時都會去找她。』
這個反應的差異讓我們停下來重新思索。我們往後退了一個步驟，重新要求經理人以及工程師中的高手分別列出那些人的績效比其他的同事高出許多。特別是做事方式讓其他人佩服的。我們想要排除那些不擇手段獲取績效的人，往往他們對組織造成的傷害大到可以抵銷他們所有的貢獻。
這個步驟的結果是：兩方所提出來的人選當中，只有大約百分之五十的人是重複的。優秀的工程師和經理人對於誰的表現比較好，大約有一半的機會是看法不一致的。
在 我們最早在貝爾實驗室的研究中，我們對受試者做進一步的挑選。只有在經理人及同事們眼中都表現傑出的工程師才會成為我們的研究對象。(在之後研究 3M公司時，我們把客戶的看法也考慮進去)。我們同時也考慮了他們所獲得的獎項，榮譽，及考績獎金的數目等。另外，專利及發表文章的數量也會列入考慮。這 些條件都滿足的傑出工程師就構成我們研究的對象，由其中分析傑出表現的成因。
為了要分出表現平平的表現優異的員工的主要差異，我們請教了高階主管，中階主管，工程師，以及其他研究者的看法。由這些結果中，我們累積了45個主管們及工程師們都覺得會影響傑出表現的主要因素。大致上可以分為四大類：
· 一、認知類的因素：比較高的智商，邏輯推理能力，及創意。
· 二、個性因素：自信，野心，勇氣，以及是否相信可以控制自己的命運。
· 三、社交因素：人際關係，領導能力。
· 四、工作及組織因素：與主管的關係，工作成就感，對於薪資及獎金的態度。
接下來，要找出這45個因素中那些是影響傑出表現的重要因素。我們對數百位表現傑出及表現普通的工程師做了為期兩天的測試。我們同時也做了資料的蒐集及分析，建立詳細的個案歷史資料，和員工及僱用他們的主管面談。同時也請他們提供自傳及個人的檔案資料。
令 人困惑的是，經過兩年的研究，我們的資料顯示不論是認知因素，個性因素，社交因素，或是工作及組織因素都無法作為分辨出傑出表現的有效因素。對於 上面列的所有傳統因素，無論是單獨或是合併分析，答案都是一樣：無法藉以分辨出普通工程師和傑出工程師。我們用了十幾種比較資料的方式，將電腦分析應用到 極限，然而，每次的執行結果都讓我們當時覺得：我們的分析方法一定是有什麼嚴重的錯誤。我們找不到任何一個可以分辨一個人是否會有傑出表現的因素。
難道是另有一些關鍵因素我們還沒有發現？難道我們原先以為的主要因素：認知因素，個性因素，社交因素，工作及組織因素完全與傑出表現無關？
我 們研究結果的長期效應是打破了一般人對於傑出表現的迷思。而事實上，在我們之後的研究發現：其他的因素也其影響力。只是大部分的工程師在進入職場 時，早已具有足夠的潛力可以表現得卓越非凡，然而最後卻成就普通。成就傑出表現的原因並不在他們擁有什麼，而在於他們如何應用他們所擁有的特質。傑出表現 之謎其實在於如何將他們的天分轉換成生產力：就好像將位能轉換成動能一樣。我們的結論是：傑出的表現是努力得來的，與天份無關。(Stars are made, not born.)
九個工作策略
好 了，如果你是一個希望能夠提高生產力，增加自己智慧資產的工程師。你該如何做才能讓別人覺得你表現傑出呢？在我們這個研究之前，這個答案並不存 在。無論是在學校或是在職場中，沒有任何地方在教培養傑出表現的工作策略。大多數的人藉由試誤法來驗證自己的想法。然而，許多計術上極有競爭力的工程師因 為在這個過程中犯了太多錯誤，使得他們的整體表現僅僅比平均稍高一些而已。例如，他們可能沒有採取主動積極的態度，或者是他們在對整個組織重要性不高的方 面主動積極。
我們發現，改變你做事的方法以及和別人共事的方法是有必要的。表現傑出的人事實上做事的方法和其他的人有相當的差異。他們將他們的工作策略融合到每天的表現中，產生一個前後一致的行為準則。任何一位具有足夠聰明和動機的工程師都可以獲得卓越表現的能力。
盡管如此，這種生產力的發揮並不是像大爆炸一樣的釋放出來。也沒有魔法藥丸或是神奇子彈可以讓你瞬間出類拔萃。而是藉由九個互相結合在一起的工作策略為基礎發展起來的。以下依照重要性排列，分別介紹這九種工作策略。
1. 閃亮的軌跡(Blazing trails)
你對於之前提到的Lai和Henry的看法是什麼？你是否覺得Henry被低估了因為他只強調技術上的競爭力並不公平？或者Lai受賞識只因她會閒聊？
一 般的員工，如Henry，腦海中的主動積極是：想出一些新的想法可以讓他們的工作做得更好，或是在公司主動幫忙一些額外的事情，例如規劃年度野餐 或是號召同仁去捐血。實際上，Henry覺得他自己很主動，『我收集了最新的技術文件並學習了最新的軟體工具，因而我可以將我的指派工作做得極好。沒有人 叫我做這些。』Henry這樣告訴我。
Lai很清楚而Henry並不了解的一個關鍵是：只有特定的行為才能讓別人覺得你主動積極。主動積極的真正意涵是：
· 主動追求超過自己職權範圍的更大責任(例如Lai主動幫忙安裝新的軟體工具)。同時仍然能夠完成自己的主要任務。
· 能夠額外付出心力來幫助其他同事或是團隊，就像Lai主動幫助她的同事應付難纏的程式。
· 當有重要的任務出現在每個人職權中間的灰色地帶時，能夠主動承擔起責任，並且將任務完美達成。
對於認定的目標或是計畫，不屈不撓地堅持直到成功地執行完畢。就像Lai在幫忙安裝軟體時以加班的方式完成原先的構想。
在一般人的印象中，唯一值得主動去做的事是發明一個商業上成功的新產品，比如說發明物件導向的Java語言。如果你花了許多心力，卻無法在華爾街日報頭版上刊登一篇讚美重大貢獻的文章，那你主動的努力就白費了。
然 而，在我們的研究中，傑出的工程師都堅信：雖然他們非常期望夠主動積極地做出巨大的貢獻，日常中的小貢獻，日復一日地累積起來，也可能造成同樣的 影響力。不只這樣，他們發現通常一個重大的發現是在一連串較小的努力之後，慢慢形成的。如果你自己的工作態度是不注重在小地方採取主動的態度，則你所累積 的貢獻會逐漸乾涸，而重大的突破永遠都沒有機會發生。例如，Lai主動幫助同事處理一個繁瑣的程式，可能可以讓她的同事獲得一個喘息的空間，而這正是在工 作上要產生有意義的突破所需要的條件。
傑出的工程師同時也相信，你可以主動做出貢獻的程度會和你的經驗直接相關。Lai在還是新進人員 時，大家並不期望她承擔太大的責任，但是她主動對周 遭的人做出一些小貢獻為她的同事帶來一些意外的驚喜。同時也很快地讓其他人認同她是一位有生產力的工程師。當她越來越有經驗之後，大家才會開始期望她能夠 主動地承擔更高難度，風險更高的任務。
我們對Lai, Henry及其他數百位其他工程師的觀察發現，對於任何一個有競爭力的專業工作者團隊，新進人員必須展現主動積極的精神。這樣的態度不只會讓主管感到滿 意，更重要的是，你的同事和客戶也會因此而欣賞你的表現。同事們期望中的工作夥伴不會將自己侷限在職務說明書中所列舉的任務中。他們希望他們的同事可以像 Lai一樣願意做超過自己職權範圍以外的任務。因為他們知道，如果一個新進的人員的工作份量比自己少，自己就要承擔更多的責任。他們需要能夠延伸自己責任 範圍的工作夥伴，無論是和同事更能搭配，提供客戶更好的服務，或是更能應付市場的迅速改變。
不只是主管和同事，客戶們也會期望他們所接觸的員工具有這些特質。如果一個新進人員沒有辦法滿足這些期望，他們可能會和Henry一樣，被歸類為有能力但是生產力不足的員工，無法對整個團隊做出正面的貢獻。
2. 知道該問誰(Knowing who knows)
一般的員工對於建立人際關係網路的想法僅止於有管道可以得知最新的辦公室八卦，或者是和自己領域中的人及獵人頭公司的主管保持聯絡，以便於日後可以轉換更好的工作。
傑 出的工程師除了上述的管道之外，另外維持了一種更重要的人際關係網路。因為他們了解，目前社會資訊過載的程度已經使得很少人具備完成工作所需的所 有資訊。他們可能具備50-80%的知識，但是除非有辦法能夠將剩下的部份補起來，否則他們的工作就無法順利完成。有效的人際聯繫正是他們補足資訊不足的 方法。
善於利用這個聯繫的人很清楚必須事先和各領域的專家建立可靠的雙向聯絡管道。這個聯繫網路中的專家們可以藉由彼此的幫助完成手邊的重要任務。建立這個網路的主要的目的，是希望盡可能地降低本身的知識不足以勝任新工作的機會。
有效的人際網路和一般人的人際關係有兩個最大的不同點：一是有效的人際網路包含了對的人，二是獲得回應的速度快。
他們所認識的專家可以第一時間就提供正確的答案。一般人則比較常得到錯誤的資訊，通常是因為問錯人，或是知道答案的專家並不在他的人際關係網路中。他們可能因而被誤導，或是繼續盲目摸索。
反應迅速的的人際網路可以使得優秀的工程師迅速的獲得自己所缺乏的資訊，而能夠比其他的人更早繼續進行工作。假設他們花了半天的時間來來問到他們所要得答案，其他的人大概要花一兩天的時間，而且通常得到的還是錯誤的資訊。長時間下來，累積的差異相當可觀。
優秀的工程師因為建立了更有效而且更迅速的網路，生產力得以進一步的提昇而能夠超越普通的工程師。即使是具有相同的天份，光靠自己總是有所不足。
Andersen Consulting, 一家國際性的顧問公司，指派公司的一位資訊技術顧問 Claudio 來撰寫一份時限很緊的合約提案。這是一份五十萬美元的合約，內容是提供生物技術公司所使用生物化驗程序的資訊技術支援。
Claudio記得他有一個大學同學現在在生物技術領域中最有名的公司Genentech Inc.上班，因此與她聯絡，而她則介紹了一位專攻生物化驗程序的同事給Claudio。僅僅用了兩通電話，他就獲得了完成他的合約提案所需要的資訊。
發 生在Claudio的另一位同事，Newt身上的狀況就不同了。和Claudio一樣，Newt也需要相同的資訊。但是Newt並沒有運用自己的 人際網路，而採用了公司的建議，將他的問題貼在公司內部的電子留言板上。第二天，他發現電腦內有40個回應等著他去處理。這些回應的答案有許多是彼此互相 牴觸的，但是由於他並不認識這些提供回應的人，無法判斷其中回答的品質。他只好一個一個的去了解和確認這40個回應的內容。
因此，當Newt還在為他獲得過多的資訊而傷腦筋時，Claudio已經利用他有效率的人際網路將兩人的差距越拉越大。
針對資訊獲得的問題，目前高級主管們普遍的作法是以改進公司內部電腦網路作為解決方案。主管們花了數百萬美元的經費在新增電腦硬體及軟體上面，相信像Newt這樣的員工可以用email解決他們的困境。
但是成功的人際聯繫通常建立在一對一的直接溝通上，比較不人性的電腦網路廣播往往效果不佳。傑出的工程師會花許多精神在建立，維繫，及運用由一群專家們彼此互通有無所組成的高效率人際關係網路。和其中有沒有使用高科技沒有直接的關係。
3. 主動的自我管理(Proactive self-management)
一般人相信自我管理的意義在於對於時間及計畫的控制。如果他們的工作可以在原訂的時程，預算，及規格之內完成，則他們的自我管理一定沒有問題。
傑 出的工程師們知道主動自我管理的真正內涵決不只是時程及計畫管理。這兩項是每個員工都應該做到，而且是公司付錢請他們完成的。傑出的工程師的工作 策略在於主動地創造機會，影響工作上的決策，在工作上表現得極端優異，並且開創自己事業發展的方向。這樣的態度可以使他們加速累積工作經驗和才能，使得他 們在公司中的價值增加。
Elena在一家提供汽車工業先進陶瓷材料的公司從事研發的工作。她向公司提出出差申請，希望能夠去參加一個生產 力及品質的研討會。由於這個研討會 的內容和她的工作沒有直接相關，而且出差預算已經快用完，她的上司並不同意。Elena並沒有因為這個決定而打消念頭，因為她相信參加這個研討會會使得她 在公司中更有價值。她用了自己的假期去參加這個研討會，並且自付旅費。
在會中，她發現歐洲正在發展一個新的品質標準ISO 9000。這個標準建立了一些投標要求，目的在確保原料，產品，及生產程序的更高品質，使得歐洲的公司在全球市場中更具競爭力。如果像她公司這類提供原料的公司無法滿足這些要求，將無法參與歐洲的標案。
回來之後，她變得更活躍。她利用自己的時間研究ISO 9000的要求，並且利用午餐會議的時間向她的工作團隊解釋。很快的，她的同事們也開始重視這個議題，並且試著說服他們的上司提早準備歐洲的ISO 9000投標要求對於公司將有很大的幫助。
高 階的主管們比較難接受他們的觀點。他們懷疑歐洲會形成制定標準的共識，更別說是強制執行新的標準了。然而，Elena不斷嘗試讓主管們了解，她會 寄一些文章或是她寫的備忘錄給他們，提醒他們第一家符合這個標準的好處。最後，最高主管們看到了一些實質的好處，因此決定採納這個想法。現在，歐洲已經是 他們公司的最大客戶，同時，品質的提昇也對他們的美國市場有幫助。
Elena的自我管理使得公司經營得更成功。即使她的主管並不支持，她 仍主動積極地提昇自己的價值。同時，她也看到了提昇公司價值的機會。最 後，Elena的作法強調了各個工作策略是互相結合的。她的自我管理同時包含了主動積極-有意願做超過她的職務範圍，甚至超過她的上司，而達成一個所有人 都受惠的目標。而能完成這些的關鍵在於：她不輕易放棄。
4. 掌握全局(Getting the big picture)
一般人都有目光短淺的問題。他們只由自己的角度看世界，並且將自己侷限在相同的觀點。
傑出工程師反而時常跳脫自己的角度而以許多不同的觀點來看事情。『我的客戶會怎麼想？我的競爭對手的想法是什麼？我的同事呢？我的上司和公司的股東又在想什麼？』由於他們可以用不同的視野來衡量事情的重要性，因此他們能對產品做出改良，或是對問題發展出更完善的解決方案。
傑 出工程師的觀點是由累積足夠的經驗而發展出來的判斷模式。Sarah在她獲得電腦科學的碩士學位之後在矽谷找了一個軟體開發的工作。在求學以及工 作的期間，她用一本筆記本來紀錄她對時常發生的問題及解決方式的觀察。每天晚上，她會仔細閱讀她的筆記本，像偵探一樣尋找問題的模式及其中的線索。
依Sarah 的實務和經驗，她和其他的新進人員一樣表現不錯。然而，她和其他人最大的不同在於她對於軟體以及電腦邏輯內部的了解。同事們很快就發現 了她的洞察力，當有重大的障礙無法突破時會來尋求她的幫助。而這也提供Sarah一個很好的機會可以接觸到一些她原本工作不會碰到的問題。
在 任職滿一年時，Sarah做了一件同事們覺得非常不可思議的事。她請求調到軟體測試部門。測試工作時常被誤認為是次一等而且前途發展有限的。軟體 測試人員的工作主要是檢查其他人的成果，確認軟體的執行和預期中的相同。和其他的研發工作相比，測試工作少了一些開發新產品所帶來的個人成就感。由於他們 總是帶來壞消息，例如軟體的臭蟲或是品質的問題，軟體開發工程師即使知道是必要的，通常也是很不情願，甚至略帶敵意地容忍測試人員的存在。
但是Sarah將測試工作視為一個新的機會，可以從完全不同的角度來了解她自己的工作。她將會廣泛地了解造成軟體錯誤的原因。可以在一兩年之內累積大量的經驗。同時，可以和最重要的客戶合作，一起開發客戶眼中合理的測試程式。
在這個過程中，Sarah可以學到在將來的軟體開發時，如何避免本質上及觀點上所會犯的錯誤。同時，測試工作也使得她有機會了解她同事們的觀點。她由同事們開發軟體的問題及排除的過程中學習到相當紮實的技巧。
兩年後，當Sarah重新回到軟體開發的工作時，她在測試部門的訓練開始展現在工作上。她的同事們很快就認定她是軟體大師。Sarah成為他們公司的軟體專家，帶領著公司在矽谷中力爭上游。
像Sarah這樣的傑出工程師，可以分辨不同觀點中的細微差異。這並不是因為有天份。而是因為他們主動追尋，並且將這個特質轉換成實質的幫助。
5. 正確地追隨(The right kind of followership)
一般的工程師相信，擔任追隨者角色的重點在於嚴守分際，毫不遲疑地接受命令，同時不對主管造成威脅。
然 而，傑出的工程師很早就了解到，副手還可以有更正面的貢獻，一個傑出的第二號人物的真義在於專心做出幫助。他們主動而且積極地投入對組織（及主 管）的成功有幫助的事，同時，對於該做什麼及如何做，他們可以做出獨立而決定性的判斷。一個好的追隨者可以和主管充分配合來達成整個組織的目標，即時他和 主管之間的個性及工作文化並不相同。
這點可能會另許多人感到驚訝，因為一般人認為傑出的人應該都是主管或是焦點人物。通常，傑出的副手對主管所做的幫助在於對於可能有困難的地方事先提出警告，做一個心思縝密的共振板，或是質疑主管決定的正確性。
在 許多的科技公司中，公司相信客戶真正的需求和知識員工所認為最好的必須做出區別。我常常聽到老闆們和我抱怨當客戶需要的只是一部道奇車，而他的員 工們卻造了一部勞斯萊斯。技術員工往往對於製造出最好的相當執著，他們希望能把最先進的技術都用在產品中，即時這樣會造成時程延誤及增加預算。
但是有時對錯不一定是絕對的，一位貝爾實驗室的優秀工程師在主管質疑他做了額外的功能時據理力爭。他的主管希望能夠在電話交換機中採用簡化的轉接功能來提前完成產品提供給客戶。
她說：『先別管這些額外的功能，這個客戶寧可現在就有一個基本的機器可以用，而不希望因為一個更強的功能多等一個月。』
她的工程師回答：『未必是這樣』。並且和她坐下來討論這個產品對這個客戶及其他客戶的的短期和長期目標。
『沒 錯，短期內對這個客戶來說，這樣做可能有好處。』她的屬下說。『但是這樣做也有風險，他們可能會把我們歸類成較低階的產品線。同時，如果我們現 在將這個額外的功能加進去，我們已經在進行中的下個客戶的產品開發會省很多時間。不過，我們還是再和客戶確認一次他們的想法。』
這位優秀的追隨者了解他的主管最關心的問題。同時，他也試著將她的觀點轉移到他們共同的整體目標。在可能的狀況下，傑出的追隨者可以稍微修正他們的方向使得他們的努力和公司的目標吻合。不行的話，他們只好另外找一個更適合的公司。
6. 團隊合作(Teamwork as joint ownership of a project)
一般的員工所了解的團隊合作是在計畫進行中或是解決問題時和他人合作，並且做好自己的部份。
傑出的工程師對團隊合作有更高一層的看法。他們將之視為一連串複雜的技巧，包含了參與設定共有的計畫目標，團隊承諾，工作紀律，時程，及分享團隊成就。同時，這也包含了主動促進團隊的互動–讓每個人都覺得是團體的一分子，處理衝突，並幫助其他成員解決問題。
有一個醫療器材供應商由於醫院對於他們最新型的加護監視器失效十分不滿，因此成立了一個危機處理小組來處理這件事。這個儀器會不定時的發出錯誤緊急的警告，使得病患和醫療人員都很困擾，醫療人員時常匆忙趕來處理緊急的狀況，才發現完全沒有問題。
這個處理小組包含了五個部門的專業人員，包含了生產，研發，及客戶服務的人員。在這個小組的7位成員中，只 Aiden最為優秀，他原本是一個工程師，為了多了解客戶服務相關的事務而調到客服部門。
在 小組第一次會議進行到了第 3 個小時的時候，成員們對於該立即採取的行動起了激烈的爭執。Ewing，一位53歲，在公司已經服務25年的生產工程師，希望說服其他人繼續派遣修護人員 到醫院維修。而 Julie，一位研究部門的新進人員，則希望能夠比照嬌生公司處理 Tyleno l事件的先例，全面回收產品。
隨著討 論的進行，Ewing 和 Julie 的爭論越來越白熱化，同時也越不文明。Aiden發現他自己以及其他人開始感到沮喪及煩躁。為了不讓這種狀況持續發展至不可收拾，Aiden 將他的感覺提出來，並且建議休會10分鐘，讓大家休息一下來想想有沒有轉圜的方式。
當會議繼續進行的時候，Aiden 請 Julie 來代言 Ewing 的意見，同時請 Ewing 替 Julie 的看法辯護，試著利用這種方法來打破僵局。雖然 Julie 和 Ewing 有點不太情願，這個策略有效地削減了逐漸升高的緊張及憤怒。這時，其他的小組成員開始腦力激盪，提出可能的想法。一位很有經驗但是害羞的設計師 Eloise，坐在角落的位置而且整天都還沒有發言。她用很溫和的聲音提出她的看法：『由於並不是每一家醫院都有相同的抱怨，我們是不是該先找出為什麼這 幾台機器會持續發生問題？或許這些機器本身一開始就有故障，也可能是這些機器安裝的醫院有一些特殊的地方。與其全面回收所有的產品，不如只將有問題的機器 收回來，同時檢查所有的設定資訊來查出到底問題出在那裡，說不定是磁場太高之類
的現象造成的。』
她講完時，並沒有其他的成員回應她的想法。討論繼續進行了幾分鐘之後，Aiden 加入討論並提醒大家：『我不確定是不是每個人都聽到剛剛 Eloise 的建議，我想她的方法應該可以幫我們解決這個事件，現在是不是可以請妳再說一次給大家聽？』
Eloise 再一次地提出她的想法，Aiden 注意到這個建議不但展現了對客戶的問題認真回應，同時也比全面回收成本低。其他的小組成員開始支持 Eloise 的方法來化解僵局，然後開始討論後續的議題。
如果不是 Aiden 出面干涉，Ewing 和 Julie 可能還在爭吵，Eloise 的意見可能永遠不會被注意到，整個小組不知道還要掙扎多久。雖然 Aiden 在小組中的角色是客戶服務部門的代表，他做了超越他職責的努力而增進了團隊的效能。
7. 小領導者的領導風格(Small-l leadership)
一般人很著迷於大領導者的領導風格 (Big-L Leadership): 大願景，大魅力，大成功。對他們而言，領導能力是與生俱來的天份。擁有這種天份的人能透過掌權來炫耀自我，對最重要的事情有決定權，同時對於向下授權之類的事並不感興趣。
傑 出的員工則將領導能力視為一種工作策略，運用於自己的專業能力及影響力來說服一群人團結起來，一起完成重要的工作。這項工作包含了許多方面的努 力：幫助團隊創造一個清楚的願景，建立信任並獲得承諾來努力完成任務。爭取足夠的資源以順利達成目標。同時指導整個計畫的進行直到順利執行完畢。
我 們都知道有些人非常聰明，卻沒辦法領導最小的計畫。除了智力之外，還要具備其他的能力才能展現小領導者的領導風格(Small-l leadership)。小領導者了解人與人之間微妙的關係，而大領導者則專注在自己的想法，自己的工作風格，與自己的目標。小領導者知道他們必須考慮所 有團隊成員的需求，技能，渴望，及權力。
這種將注意力放在自己以外的領導風格在職場現實上是比較有生產力的。小領導者通常對於他所領導的 團體沒有正式的職權。同事們只有在確定團隊中的領導 者對於自己和其他人的利益一樣重視時才願意參與。因此，要將團隊組合起來需要和所有的成員互動，溝通，這對於大領導者而言，是浪費寶貴的領導時間。然而， 一個願意和所有團隊成員同甘共苦的小領導者，往往比最有魅力的大領導者主管更能獲得成員的忠誠及信任。
傑出領導者的最大秘訣，也是和大領導者及表現普通的領導者最大的差異，在於他們不會假設他們對於其他人的一切事情都能完全掌握。大多數的大領導者相信自己是無所不能的，他們知道什麼是對成員及狀況最好的處置。
傑 出的小領導者總是會先詢問成員的意見，即使他們覺得他們已經知道結果。Anithia, 一位德商公司在美國的軟體設計師，在開始計畫之前一定會先驗證她對同事們想法的假設是否正確。當她被指派去帶領一個開發網路軟體的計畫時，她在第一次的會 議就先詢問成員們對於工作角色和任務的意見。
『John, 在上次和你一起執行計畫時，你曾提到你希望能有更多的硬體經驗，目前還是這樣嗎？因為這個計畫硬體的部份非常重要。』
Anithia 像一個認知心理學家一樣暫停自己的假設，提出一些開放性的問題，讓成員們可以表達他們目前具備的技能以及他們對於計畫的期望及需求。 因此，她可以將任務的分配和成員的能力及興趣做更好的配合。她希望能夠避免將她的同事定型，不要像好萊塢製作人一樣製造演員的刻板印象。
當 然，身為員工不可能總是獲得所有想要任務與福利。但是，沒有正式職權的小領導者可以藉由真誠的聆聽及試著滿足部份的需求來贏得認同。同時這個努力 溝通的過程也可以為計畫打下互信的基礎，幫助度過計畫遇到困難時無可避免的壓力。在某一個技術領域展現優越的實力可能可以幫助一個傑出的工程師被指派為團 隊的領導者。但是小領導者知道階層的力量並不能延伸到人際關係這一方面。他們會試著創造出一種氣氛，讓成員們感受到『我們是在同一艘船上』。
Anithia 所領導的計畫後來客戶的反應非常好。在年終慶功的晚宴上，北美部門的總裁對Anithia大加讚賞，邀請她一起到台上來表揚這個計畫 及她以前所領導計畫的成功。他說：『如果我們公司有500個像Anithia這樣的人，控制整個北美市場是遲早的事。』然後，他請Anithia講幾句 話。
就像許多演員獲得奧斯卡獎時一樣，Anithia可以很快的講一些感謝上司及成員的話。而她卻不是這樣做。她邀請了所有的團隊成員一 起到台上來，請 其中的一位將所有的人介紹給大家，然後她說：『這個計畫是我們共同努力的成果，沒有每一個人的貢獻，不可能有今天的成功，我們對於這個計畫感到很驕傲，非 常高興你們也這樣想。』然後他們一起對大家鞠了一個躬。
8. 精明(Street smarts)
一般人多半太專注在討人喜歡，以為這樣是在職場中快速升遷的方法。他們要不就是對於辦公室內的政治問題太過關心，要不就是故意裝作完全不在乎。
傑 出的員工了解任何的組織中都有許多正當而互相競爭的利益。藉由他們對組織運作的理解力，可以幫助他們在這些互相牴觸的競爭中，促成合作，凸顯衝突 的部份，並且讓任務順利完成。這個動作包含了具備處理個人及團隊動態的傑出運作能力，知道何時該避免衝突，何時該正面對決，同時知道如何將可能的敵人轉化 為盟友。
記得Sarah嗎？在第4項工作策略中提到的傑出軟體開發工程師。雖然她的同事都覺得她瘋了，她仍然自願請調到測試部門。這個動 作不但讓她對她的工 作有不同的觀點，她同時也知道那些人會和她日後的工作相關，並開始建立良好合作的關係。這種組織上的聯繫不但可以提高她的地位，還可以讓日後工作上的互動 更加順利。
在第3項工作策略中提到的Elena，運用了大量的組織運作機智來影響她的公司，將營運的焦點轉移到ISO 9000及歐洲市場的機會。首先，她利用午餐會議的機會將她在研討會中學到的傳授給她的同事。在她對這個議題更加了解之後，她舉辦了更詳細的訓練課程。同 時，她向她的上司仔細解釋這個特殊標準對公司的好處，並且藉由寄送關於業務及營收潛力的相關文件及備忘錄慢慢遊說管理階層。當然，在和更上層的管理者接觸 之前她一定會先得到她上司的准許。接著她開始訓練她的其他同事如何贏得歐洲客戶的標案。由此可看出，在她試著推銷她的想法的同時，她將這個想法和公司的重
要目標結合在一起。同時也很注重組織運作的禮儀。
9. 呈現(Show and tell)
一般員工認為呈現就是利用炫目的簡報，長篇的備忘錄，或是公開展示自己的成果來吸引管理階層的注意。他們的重心擺在自己的形象以及自己所要傳達的訊息，而不是擺在聽眾。
傑出的工程師則會仔細篩選所要表達的資訊，以最有效，最友善的格式來傳遞訊息並說服特定的聽眾。就最高層次而言，呈現的意義在於對於特定的聽眾選擇適當的訊息，或是對特定的訊息選擇適當的聽眾。
呈 現的重要性是無法迴避的。一位專業人員如果無法有效地以簡報的方式傳達自己的想法給其他的人，在現今的職場中要生存是相當艱苦的。對於大多數的知 識工作者而言，這裡討論的重點並不是大型的演說，像比爾蓋茲在超大型的會議中心以最先進的多媒體設備及電腦特效所做的展示。而是針對在公司內部的小型會議 室中，對5至20位聽眾所做的簡報。簡報的聽眾多半是同事，上司，或是客戶。而內容多半是技術性的或是與產品相關的議題。
對傑出的專業人員而言，簡報準備的過程比較複雜。我們的研究觀察到呈現的表達方式會逐漸修正，由單純的傳達資訊轉變為對訊息的塑造。傑出的工程師通常精通將訊息傳達給特定的對象，說服聽眾接受所要表達內容，及事先對可能產生的批評做出準備的能力。
一般人最常見的錯誤會發生在由單純的資訊傳達，提升到試圖運用這個訊息發揮影響力時。在這個過程中，他們聽眾的組成已經大不相同了。然而，他們呈現的風格及的結構卻維持和原來一樣。
一位財星500大企業的勞工關係經理在和公司的工會協商新的合約時，面臨了必須降低醫療照顧成本的問題，他以極佳的呈現方式來解決這個問題。在這個協商的過程中，他所擬定的計畫必須同時被公司的最高主管及工會接受。
他 的主要處理方式是將相同的資訊塑造成完全不同的表現方式。首先他針對一群較低階的工會職員進行為期一週溝通，每天簡報一小部份的資訊。他發給他們 清晰而容易閱讀的講義，讓他們可以複製給所有的工會成員。講義的內容淺顯得讓人可以快速理解。這個呈現的主軸在於傳達一個訊息，如果工會同意改變醫療照顧 的計畫。公司承諾將所省下來的資金用來更新老舊的工廠設備，使得工廠更具競爭力。同時降低關場及失業的風險。
而他稍早對公司的執行長及副 總裁所做的簡報基本上含有相同的資訊，但是卻用完全不同的方式來包裝。首先，和對工會簡報相比最大的不同是互動的時間少 了很多。因此，大部分的資訊包含在一份詳細的報告中。他以其中有一個很具有說服力的章節來建議接受新的計畫。此外，他有一個小時的時間可以對公司的執行長 及董事長進行簡報來加強他的論點。
他在簡報中強調，如果管理階層執意改變醫療照顧計畫而沒有任何有創意的補償計畫，工會將不會同意而使協商幾乎不可能進行。他提醒公司目前才剛進入一個快速成長期，股東們可能無法忍受員工罷工。
雖然雙方陣營都對他的計畫有一些批評，然而，這位優秀的協商者已經將這個計畫的基礎打得很穩固了。到了最後，管理階層及工會都接受了他的建議案，只做了小部份的更動。
在這個案例中有許多值得學習的呈現技巧。但是其中最重要的，也是一般人和高手最大的不同點在於：了解你的聽眾，並且藉此塑造所要傳達的訊息。
Meara 的工作是設計影像傳輸軟體，可以透過電話線路在醫院的急診室之間傳遞X光片，心電圖指數，及即時的電視畫面。她用了一個電視短片作為簡報 的開頭，來對急診室醫師及醫院主管介紹她的團隊所設計的最新軟體。短片以汽車的緊急煞車聲和救護車的警報聲開始，一個小孩被緊急送入急診室，一位醫師開啟 她們公司的儀器並且說他只有幾分鐘的時間可以來挽救一條年輕的生命。
她說：『我們目前的進展可能可以挽救這個孩子，或是你的孩子的生命。在我們計畫進行中，我們不斷的觀看這個短片來提醒自己，盡量將產品做到最好有多重要。現在，請和我們分享我們的成果。』
為 了展現新的軟體和之前版本的差異，Meara使用了電子計時器搭配心跳聲做示範。首先，她使用舊版的軟體，在所有的聽眾還在等待螢幕上慢慢傳來的 畫面時，計時器已經跑完了，心跳聲停止了，手術室的警告燈也熄滅了。而當使用新的軟體展示時，畫面傳輸的速度變快，在計時器停止之前已經完成影像的傳輸。
然後Meara向她的聽眾解釋在產品開發的過程中為了縮短傳輸時間所做的努力。包含了那些嘗試是有幫助的，那些則沒有用，以及其中的原因。她將技術上的論點和醫療專業人員挽救性命的過程戲劇化地編織在一起。
Meara藉著讓她的聽眾們感受到自己的孩子被送進急診室的恐懼，吸引聽眾們的注意力到公司的產品。然後戲劇性地展示了新產品的價值。
成為閃亮的明星
我 們對於我們的生產力提昇計畫做了長期的成效評估。觀察工程師們在學習了這些工作策略之前和之後生產力的差異。在過去的7年之中，有超過 1000 位美國及歐洲的專業工作者受過這個訓練。這個訓練課程曾經授權給專業的訓練機構，同時也有大學將這套計畫用於課堂上以及職員的成長計畫。
為了提供評估的基準，我們訪問了主管，傑出的工程師，及一般的員工，請他們列出明顯顯示出生產力提昇的衡量標準。在經過許多次的反覆實驗之後，我們確認了滿足這些衡量標準的員工，在生產力上確實有明顯的提昇。
然後我們訪問了 300 位參加者及 300 位沒有參加人員的直接主管，根據這些衡量標準來評分，第一次評分是在參與計畫之前，第二次則是在完成計畫之後 8 個月。
在這個主管評分的分析中，參與計畫的人員在生產力上都有顯著的提昇。參加過這個訓練的工程師不但解決問題的速度變快，工作產出的品質也提昇了，同時不斷地讓他們的客戶感到驚喜。
這個傑出工作策略的計畫並不是用來矯正生產力低落的員工。參與計畫的人員中，有30%是本來表現就已經很優秀了。然而，他們生產力的提昇仍然是相當顯著。
生產力提昇最顯著的是女性及少數民族的工程師。根據他們上司的說法，參與計畫前後的生產力差異平均值可以達到400%。
這個訓練計畫的成功驗證了我們研究的主要發現。要大幅提昇生產力並不需要魔法。當一個工程師表現平平時，通常不是因為他的能力不足。而是因為他從來沒有學過可以提高他生產力的工作策略。一旦他了解了這些策略，他就開始邁向傑出之路。
[轉載]Android配合Eclipse環境建置
1. 建立目錄 D:\Android
2. 下載 Google Adnroid SDK
http://code.google.com/android/download.html
解壓後改名"android_sdk_windows_m3-rc20a" -> "android_sdk"
放到D:\Android\android_sdk
3. 下載 eclipse(ex:Eclipse Classic 3.3.1.1)
http://www.eclipse.org/downloads/
解壓後放在D:\softwate\eclipse
4. 下載並安裝JDK (ex:Java SE Development Kit 6 Update 4)
網址：http://java.sun.com/javase/downloads/index.jsp
設定系統PATH：我的電腦右鍵->內容->進階->環境變數->PATH->編輯->加上你的JRE安裝路徑(比如：C:\Program Files\Java\jre1.6.0_04\bin)
5. 安裝 Android Eclipse Plugin
5.1 Eclipse->Help->Software Update->Find and Install->Search for new features to install
5.2 按下New Remote Site
Name:Android
URL:https://dl-ssl.google.com/android/eclipse/
(如果之前已經安裝過，先到Eclipse Help->Software Update->Manage Configure找到Andriod Development Tools，右鍵，Uninstall)
6. 指定Android SDK的位置
Eclipse-> Window -> Preferences -> Android -> SDK Location -> "D:\Android\android_sdk"
7. 建立第一個程式：HelloAndroid
Eclipse -> File -> New -> Project -> Android Project
Project Name:HelloAndroid
Package Name:com.google.android.hello
Activity Name:HelloAndroid
Application:Hello, Android
在HelloAndroid.java貼上程式碼：
package com.google.android.hello;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;
public class Hello extends Activity {
/** Called when the activity is first created. */
@Override
public void onCreate(Bundle icicle) {
super.onCreate(icicle);
TextView tv = new TextView(this);
tv.setText("Hello, Android");
this.setContentView(tv);
}
}
在專案上，右鍵，Run as，Android Application
接著就會出現模擬器，往左邊選擇Applications
選擇Hello, Android
出現執行畫面了！
2008年10月23日 星期四
XP 多人遠端登入
本篇為轉載文章 問答集：
來源不詳，若有知道作者為誰，歡迎告知，小弟會再修改放上，謝謝
緣 由 : XP Pro 的遠端桌面只允許一個人連線，當其他使用者使用遠端桌面連線到 XP Pro 時，
本機使用者會被強制登出。只要完成下列步驟，
就可以解除這個限制，經實測確實可行
(測試機器為 XP Pro SP2 Vol 版本，本機主控台一個工作階段加上兩部電腦遠端登入)。
1. 將 Windows 啟動在安全模式。
2. 按一下 [控制台] 中的 [系統]，取消選取 [遠端] 索引標籤中的
[允許使用者遠端連線 到這部電腦]，然後按一下 [確定]。
3. 開啟 [控制台][系統管理工具][服務]，將 Terminal Services 服務停用，
然後按一下[確定]。
4. 瀏覽到 C:\windows\system32\dllcache 目錄，將termsrv.dll 檔案改成
別的名稱 (例如 termsrv.original)。
5. 從 http://www.orbitfiles.com/download/id20947665 下載無連線數目限制
的 termsrv.dll，然後將它複製到C:\windows\system32\dllcache 目錄。
6. 瀏覽到 C:\windows\system32 目錄，重複步驟 4 與步驟 5
(將 termserv.dll 改成其他名稱，然後將剛下載的檔案複製到此目錄。
7. 開啟 [登錄編輯程式]，找到
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\
Terminal Server\Licensing Core 機碼。新增一個名為
EnableConcurrentSessions 的 DWORD 項目，將其值設定為 1，
然後關閉 [登錄編輯程式]。
8. 按一下 [ 開始][執行]，輸入 gpedit.msc，然後按一下ENTER。
開啟 [電腦設定][系統管理範本][Windows 元件][終端機服務]，
按兩下 [限制連線數目]，選擇 [已啟用]，然後在
[可允許的 TS 最大連線數目] 中設定想要的最大連線數目。
9. 重新啟動 Windows 在正常模式。
10. 按一下 [控制台] 中的 [系統]，選取 [遠端] 索引標籤中的
[允許使用者允端連線到這部電腦]，然後按一下 [確定]。
11. 開啟 [控制台][系統管理工具][服務]，將 Terminal Services 服務啟動，
然後按一下 [確定]。
12. 重新啟動 Windows。
注意：
1. 您必須為使用者建立帳戶並將他加入 Remote Desktop User群組，
該使用者才能連線。
2. 您可能必須啟用「快速使用者切換」與「歡迎畫面」，按一
下 [開始][控制台][使用者帳戶][變更使用者登入或登出的方式]
以啟用上述兩個功能。
3. 此解決方案可能不適合已加入網域的電腦，因為網域群組原則可能
會覆寫本機群組原則。
答：據聞取自 XP SP2 RC1，termsrv.dll 版號 5.1.2600.2055。
答：不清楚，個人並不使用 [自動更新]。照理說如果這個檔案沒有被發現有弱點，MS 應該不會釋出更新。
答：不清楚，個人沒有 Home 版本，只有在 XP Pro 版本測試過可行。或許您可以試試然後告訴大家結果。
答：不清楚，請自行負擔所有風險。
2008年6月28日 星期六
BIOS for VGAint
(轉貼於"小華的部落格http://biosengineer.blogspot.com/")
一般而言,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" 也未必完全相同 !!!
BIOS for PCI
(轉貼於"小華的部落格http://biosengineer.blogspot.com/")
[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 <<>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也能克制這種攻擊手法
打造自己的BIOS
(轉貼於"小華的部落格http://biosengineer.blogspot.com/")
第一集：
存放BIOS的設備從早期都放在EEPROM到現在的Flash ROM，一路上的演變已經可以寫成一部BIOS歷史課本。
在早期的BIOS中，BIOS本身程式碼就是用來當成一個Boot Loader，但是由於後來的晶片功能越來越強大且BIOS除了初始化硬體設備之外還要協助OS去支援一些功能，所以整個BIOS程式碼就已經變成了一個 龐然大物，而維護整個BIOS程式碼也非一個人的能力所及。
因此後來的BIOS程式碼都是由一些BIOS供應商來負責維護，各家BIOS供應商會有自己的撰寫方式與架構。正因為如此，開發BIOS的程式碼目前也都是使用各家廠商所提供的開發環境來建構。
而這篇文章的目的在於如何在目前的PC架構下純手工打造一個屬於自己的BIOS環境以及撰寫一個簡單的BIOS程式碼可以讓系統輸出一個值到Port 80h，我同事問我為什麼不寫一個mini BIOS可以開到DOS下去，因為如同我上述所說，寫是可以寫啦，要花很多的精力跟體力，這邊只是拋磚引玉說一個大概，然後描述一下如果自己真的要撰寫一 個BIOS 要如何做? 或許有些人有興趣可以找幾個朋友一起寫BIOS，或許哪一天就可以開ㄧ家台灣BIOS供應商...(呵呵，我自己在幻想啦!)
需要用到的工具以及相關知識：
1.MASM 6.15
2.Turbo C++ 3.0
3.基本組合語言撰寫能力
4.基本C語言撰寫能力
5.IA32 Spec vol 1~3
6.EC BIOS ROM(可以請EC BIOS Eng協助)
實驗目的與方法:
1. 建立一個BIOS 開發環境
2. 建立一個1MB BIOS ROM file
3. 利用組合語言撰寫一個64kb 大小的BIOS程式碼的 binary file
4. 利用C語言撰寫一個Build Tools，並將EC與64k BIOS塞進去1MB BIOS ROM
5.利用燒入器將1MB BIOS ROM燒入到MLB中，並且上電後檢查Port 80h是否有正確的輸出我們程式碼中撰寫的值。
上面的程式撰寫部分不需要很強的能力，只要基本的C或是組合語言語法就可以了，所以算是基本入門，重點還是在我ㄧ直強調的地方 "懂架構才是重點，程式語言只是工具而已"...。
第二集：
電腦發展至今已經經過了很長的時間，許多遇到的問題也都被ㄧ些前輩解決了，因此目前學校或是市面上的書籍幾乎都是講解如何在一個"現成且成熟"的平台上發展。
例如很多書會教你寫VC/.net/Java ，但是，說到如何去寫編譯器、作業系統及開發BIOS的書就不多了，也因此大家比較專注於如何在成熟的平台上能夠快速/有效率/有系統性的開發以及提出解 決問題的辦法，而像我因為興趣而去探討BIOS的本質的人就應該比較少吧，畢竟這些問題在之前的前輩都已經遭遇過，也提出了很好的解決方式，所以才會有目 前一些實力堅強的BIOS 供應商的存在，因此也沒必要像我這樣純手工打造。
在前ㄧ篇的文章中我已經大致上描述了一下我的實驗方式，這邊就針對整個流程作ㄧ些詳細的介紹。
在純手工打造你自己的x86 BIOS(1) 中有提到，你可以學習到的東西是比較基本的概念，所以我並不會把完整的Sample code貼上來，畢竟教釣魚比給魚吃還重要，因此請大家輕鬆看待我的拙作(小弟也只入行1年多 ，還請前輩還多多指導)。
前一篇文章中所提到的核心部份在於我撰寫了64K 的BIOS程式碼 (MyBIOS.asm)，實際不到64k ，只是我利用了填00h的方式填滿到64k。
而組譯與連結是透過ML.EXE ，輸出的是一個MyBIOS.exe ，而這個是一個DOS下的執行檔，所以裡面有MZ Header ，因為被多加了這個Header 因此MyBIOS.exe約65k ，而我會再利用Build tools取出裡面的64k ，然後變成MyBios.bin，當然這只是最簡單的方法而已，但不是唯一。
[註] EXE2BIN 只能轉換小於64k 的檔案，所以這邊不能使用它，所以我才自己轉換。
當取出了MyBios.bin 之後連同EC.bin 經由Build.exe 產生一個1MB 大小的BIOS ROM Image file，然後把位置固定住。
固定位址是因為：
1. 我的範例中的Platform 上面的EC Controller是採用Share ROM方式，也就是把EC BIOS包在System BIOS中，因此我們需要固定住位址，這樣子EC Controller 才能去System BIOS中讀取EC BIOS的程式碼並且執行。
2.由於x86 CPU讀取第一條指令是在 FFFF_FFF0h，所以我們必須要把BIOS code固定在尾端往下算的64k 範圍內，如下圖所示：
圖 中可以看到整個BIOS ROM Image file是1MB ，其中64k是EC code另外64k是BIOS code，然後擺放在1MB 檔案中的位置就如上圖所示，其餘空白的地方我都是填00h/ffh (須看BIOS ROM Spec中說明空白是00h/ffh)
總結:
●MyBios.asm 負責CPU 第一條指令以及組態CPU 模式還有設定Port 80h的輸出並且輸出一個99h 到Port 80h
●EC.bin EC的BIOS Code，由EC BIOS工程師撰寫，我只是拿來用而已
●Build.exe 會先產生一個1MB 空白的BIOS ROM Image，然後把上面兩個bin file塞到先前產生的1MB 空白BIOS ROM Image，並固定其擺放位址，而擺放時並沒有考慮任何File System的架構問題，而是直接塞。
●MyBIOS.ROM 產生出的MyBIOS.ROM就是要用來燒入到BIOS part中的檔案，也就是類似一般大家在Flash BIOS時的那個檔案。
C:\> Flash.exe /all MyBIOS.ROM
上面是一般大家使用某個Flash Utiltity 時會打的一些指令，因為工具不同所以參數也不同，不過相同的是都會有一個BIOS ROM Image file(例如MyBios.ROM)
另 外這邊有點不ㄧ樣的地方在於我沒有自己寫Flash Utility(我們BIOS裝在EC Controller下，而我又懶的看EC Spec)，所以沒辦法像上面方式使用某個工具去更新 BIOS ROM，況且你們如果要實驗相同的東西，Flash Utiltiy也不能共用，所以這部份有興趣的人就自己研究一下你們公司內是怎樣撰寫這部份的工具。
而我的燒錄方式是採用EC Controller提供的燒入器，所以直接點選我的MyBios.ROM就可以燒進去BIOS Part了，而這部份也不多做說明。
由於整個實驗我才花了1.5天時間(0.5天寫Build.exe + 1天寫MyBios.asm)，所以很多地方沒考慮進去，希望各位有其他意見請告訴我，謝謝!
第三集：
在前面兩篇文章中的描述中其實大家就應該可以知道我的實驗環境由幾個部份所組成，所以我這邊假設 "如果我是ㄧ個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。
第四集：
上ㄧ篇文章我已經針對我的實驗做了敘述，這裡我就針對實際上我的程式碼撰寫的內容做一個介紹。
在程式碼的撰寫中，其實我只有使用了簡單的C語言跟組合語言語法，重點是要讓大家知道， 其實BIOS跟一般的Boot Loader寫法沒什麼不同，只是PC上面的BIOS需要考慮的事情比一般的Boot Loader還多很多，因此程式碼 size可以大 到1MB甚至是2MB (ㄧ般Boot Loader不可能這麼大)，所以我有機會玩一個這麼大的Boot Loader也真是很榮幸的啦!
廢話不多說，我就先針對我前面提到的Build.exe 內的程式碼說明；
底下是我的Build.c 內的程式碼片段，其實我就只有使用到fopen() 、fputc() ...等基本的函數去讀寫一個檔案，所以可以很容易的把我組譯好的MyBIOS.bin 跟EC.bin 塞進去同一個檔案內，做法其實很簡單，就是像我下面做法一樣，先利用fopen()開啟檔案，然後在把你要的資料寫進去檔案，只是寫的時候你要考慮 file offset 位置的問題，因為當你燒錄到BIOS part中的時候，CPU是會固定重FFFF_FFF0h的位址讀取第一條指令，因此你要像我前面說的一樣，把MyBios.bin放在固定的位址中。
//建立一個空白的MyBIOS.ROM , 裡面資料都是00h
void show_help(void)
{
printf("Build.exe v1.0.0 by Harrison Hsieh \n");
printf("===========================================\n");
printf("/C Init MyBIOS.ROM \n");
printf("/B [EC] [BIOS] Add Rom \n");
printf("Output : MyBios.ROM \n");
}
void InitBiosROM(char *argv[])
{
FILE *fo;
long i;
if ((fo = fopen (BiosRom, "wb")) == (FILE *) NULL)
{
exit(1);
}
for(i=0 ; i<= BIOSSIZE ; i++) //1MB
{
fputc(0x00,fo);
}
/* All done, close the file */
fclose (fo);
}
在說明完Build.c內的做法後，接著說明MyBIOS.bin 內的程式碼撰寫；
其實在MyBios.asm 中，我只有做4 件事情：
1. 設定好FFFF_FFF0h的第一條指令
2.開啟BigReal Mode (因為我要設定ICH9的RCRB內的暫存器，所以要開啟)
3.設定ICH9內的暫存器，把所有Port 80h的訊號轉送到LPC介面(我的Post card走LPC界面，所以要設定)
4.輸出99h 到Port 80h(所以LPC介面上面的Post card就會顯示99h)
底下是我的MyBIOS.asm 內的程式碼片段：
COLDBOOT:
CLI
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 1. Enable big real mode
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
JMPREG di,Make4GBSegmentDI
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 2. Set RCRB base address
;; 3. Config ICH9 Register
;; 4. Out 99h to Port 80h
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
....
mov dx, 0cfch
mov eax,RCRB_BaseAddr
out dx, eax
....
and BYTE PTR es:[esi], NOT (04h) ; RCRB+xxxxh bit 2=0 Output to LPC
....
fPostCode:
mov al,099h
mov dx,80h
out dx,al
jmp fPostCode ;無窮回圈ㄧ直顯示99h
...
...
wbinvd ; ...begins here on power up
PUBLIC POWER
POWER:
JMP COLDBOOT ; first jump
DB '11/14/07',00,00,00 ; My release marker
以上就是我撰寫的程式碼內容的說明，其實沒有用到什麼特別的東西，如果說比較難的部份大概就是如何把程式碼塞到正確的位址吧。
總結：
純手工打造你自己的x86 BIOS 文章(1)~(4) 在這邊就做一個結束，在這幾篇文章中的實驗我主要是要幫助剛入門的BIOS新手去了解整個BIOS vendor提供的BIOS環境架構以及實際上BIOS code撰寫的第一步，因為很多東西都是入門的第一步比較難。
還記得ㄧ年前我剛入行的時候，我們學長跟我說寫BIOS最簡單的方式就是自己把一個BIOS寫到能開機你大概就已經學會了，雖然我離能自己寫到開機還有一 段距離，不過在學習的過程中也學到了很多東西，因此當初會想自己純手工寫一個能讓x86 CPU執行一段BIOS code的環境也是希望能幫助更多BIOS入門時遇到挫折的朋友 ^^Y。
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開發環境，你需要哪些工具，還有怎樣子做。
EFI(Extensible Firmware Interface)之2
Extensible Firmware Interface ，EFI 簡介 by Harrison
(轉貼於"小華的部落格http://biosengineer.blogspot.com/")
Extensible Firmware Interface (EFI) 是一個規範，他規範了一個介面，界於作業系統(例如: Windows)與平台韌體(Platform firmware)之間的一個橋樑。 EFI的改進被用來取代傳統BIOS的介面(這個傳統的介面被稱之為IBM PC compatible PC 的BIOS或稱之為Legacy BIOS).
最初EFI是由Intel 所主導發展，目前則由UEFI論壇(Unified EFI Forum) 的會員一起共同維護，這便是眾所皆知的UEFI (Unified EFI，統一的EFI).
發展歷史 History
最初EFI發展動機是為了在1990年中的Intel-HP Itanium 系統，當時的PC BIOS有一個限制(支援16 bit 的處理器模式，1MB 位址空間與AT 硬體架構)，而這個限制使的他無法支援大型伺服器平台的系統Intel-HP Itanium。 最初的時候Intel 只是為了解決這些BIOS啟動時的限制，後來就乾脆改變它的名稱，且稱之為EFI。
EFI specification 1.02 在2000年12月的時候由Intel發行 (Version 1.01 則是Intel 最初發行的版本，但是它裡面有一些錯誤存在。)
EFI specification 1.10 在2002年12月1日發行，他包含了 EFI driver model 增強版。
到了 2005年， Intel 將這個版本貢獻給 UEFI Forum來幫助大家討論，藉以提升EFI開發環境以及提升他的功能。 所以將EFI改稱為 Unified EFI (UEFI)來代表這個改變。
而UEFI Forum 目前2007年1月7日的最新版本是UEFI specification version 2.1 。它增加了cryptography，network authentication， IPv6 support和User Interface 架構(簡稱 UEFI使用者介面，或稱HII)。
EFI specification 所定義的介面中包含platform information的Data tables還有啟動服務(Boot Services)與Runtime services (例如如何去啟動OS loader 或是啟動 ㄧ個EFI-aware OS)。
另外像是原本就存在於PC BIOS中的其他類型的增強型BIOS(像是SMBIOS或是ACPI )也都可以存在於EFI之中，因為他們並沒有使用16-bit runtime interface去服務他們。
Services
EFI 定義了啟動服務( boot services)，這些服務包含了文字與圖形支援，這些支援可以針對不同的設備(device)，匯流排(bus)，檔案服務(file services)，Block…等， 還有一些runtime services 就像是date， time 和 NVRAM services.
Device drivers
EFI針對標準設備驅動程式的增加部份，它提供了處理器-非依賴的設備驅動程式環境(Processor-independent device driver environment) 稱之為EFI Byte Code 或 EBC。依照UEFI 規範中的系統需求中提到，系統需要裝設一個翻譯器(interpreter)來提供EBC Image 的裝載(resides in)或是載入(Loaded into)進去這個環境。
因此，EBC會類似被模擬成Open Firmware的樣子。而這個Open Firmware(他是一個硬體-非依賴韌體，Hardware-independent firmware)是就像是使用在 PowerPC-架構的 Apple Macintosh 電腦或是 Sun Microsystems SPARC 電腦，或是其他也在使用Open Firmware的電腦。
一些非EBC(non-EBC architecture EFI device drivers types)架構的EFI 設備驅動程式型態則有一個介面來支援OS對他們的使用。
這些介面可以允許OS去依賴EFI所提供的一些基本設備驅動程式(像是圖形驅動程式，網路驅動程式的支援)來初始化一些設備，直到OS所需的驅動程式全被載入為止。
Boot Manager
EFI boot manager 也被使用來選擇和載入一個作業系統(Operating system)，移除則需要決定一個Boot Loader的管理機制 (Boot Loader變成EFI 應用程式的類型)，在Framework架構中是屬於Boot Device Select，BDS階段。
Disk Support
除了標準PC磁碟分割(Disk partition scheme)架構Master boot record (MBR)之外, EFI 還增加了一個新的支援 GUID Partition Table (GPT)， 而這個新的支援則不受到標準MBR的侷限。 在EFI specification 並沒有描述你要使用哪一種的file system; 而典型的EFI在實作上則內定支援使用 FAT32 的檔案系統。
The EFI Shell
EFI 社群(community)建立了一個開放式源碼(Open Source)與介殼程式環境(Shell environment)，是使用者與作業系統溝通的程式，負責解譯及執行使用者下達給作業系統的指令。
所以EFI Shell並不是直接的啟動進入到OS，因此在某些情況之下，使用者可以進入到EFI shell。而這個shell是一個EFI application，它可以直接存在於platform ROM(直接燒入在裡面)，或是在有驅動程式的ROM的設備上面(透過驅動程式來載入EFI Shell)。
像在MacBook (Apple 的Intel CPU架構的筆記型電腦)，你可以把EFI shell 應用程式放在USB隨身碟，而在開機的時候按著"Option"，然後就會看到一個選擇開機項目的畫面，選擇你的USB隨身碟，那麼就可以看到一個長的很 像DOS的畫面，而這個畫面就是EFI Shell。
而這個Shell可以被使用來執行一個EFI 的應用程式，像是 setup， OS install， diagnostic(診斷分析程式)或是Configuration utilities和System flash updates…等，他也能直接的播放CDs 或是DVDs 而不需要進入到一個完整的OS環境底下，它提供了一個適當的環境來開發EFI應用程式。另外Shell commands也可能可以用來複製，搬移檔案或是目錄(如果你的Shell 有支援)，而設備驅動程式也可以利用他去載入或是卸載，而一個完整的TCP/IP 堆疊(TCP/IP 7層架構)也可以使用EFI Shell被完整的使用。
簡單說就是EFI Shell提供了一個不需要進入OS環境也可以處理你需要的工作的一個環境。最後EFI shell支援腳本，而他的副檔名是 .nsh files，他就像是DOS下的批次檔( batch files)。
Shell Command的指令名稱繼承了DOS command interpreter 或是 Unix shell(操作起來像是混合體，有時出現DOS指令的名稱，有時是Unix的名稱) ，而EFI Shell其實就是可以看作成在BIOS裡面的一個DOS環境。
Extensions
EFI延伸功能之中所描述，EFI可以從任何虛擬的非揮發性儲存設備載入並且連接到電腦之中，例如一個original equipment manufacturer (OEM) 廠商在賣系統的時候將EFI 分割區放硬碟中，而要將這些功能載入的程式則放在主機板上的ROM之中，簡單說就是BIOS ROM裡面的程式可以去硬碟把EFI 功能載入出來執行，例如一些測試程式放在硬碟，然後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內的某個章節。
Intel 並沒有將這個架構完整的開放給一般的End-User知道，他只有開放這些資訊給一些獨立的BIOS 廠商(稱之為IBV)，像是安邁 (American Megatrends ，AMI) 或是系微(Insyde Software) …等的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並不會去要求你把修改的 地方公開出來，而這種方法會有助於你去保護你的智慧財產權。
Platforms that use EFI or the Framework
最早使用EFI 的平台式 Intel的第一個Itanium 工作站和伺服器，他們支援EFI 1.02。 接著是Hewlett-Packard的第一個 Itanium 2 系統(2002年發表)，支援EFI 1.10; 而這些系統都可以啟動 Windows, Linux, FreeBSD 和HP-UX。
不管是Itanium或是 Itanium 2 系統，他們在出貨的時候都是使用EFI compliant firmware，且須遵照DIG64 specifications。
在2003的11月, Gateway 介紹他們的Gateway 610 Media Center，第一個x86 Windows-based 的電腦系統使用了這個框架(Framework)，而韌體供應商則是 Insyde Software's InsydeH2O。而這個韌體依舊是依靠賴傳統BIOS相容介面的方式去實作出這個框架來啟動微軟系統，簡單說就是EFI 的框架去模擬成傳統BIOS，因為Windows並不認識EFI，所以利用EFI框架做出模組(Module)方式去符合目前x86 架構。
在2006年1月，Apple Computer 販售了屬於他們第一次使用 Intel-based的Macintosh電腦， 這個系統使用了EFI和新框架Framework來取代了原本他們在Power PC-Based 一直以來都在使用的 Open Firmware，而在 2006年4月5日， Apple 公佈了一個 Boot Camp 應用程式，這是一個非破壞性的分割工具(non-destructive partitioning tool)去幫助Apple的使用這去安裝Windows XP驅動程式甚至是系統到麥金塔的電腦之中。
而同時，Apple的韌體的也做了更新支援，讓傳統的BIOS支援去它的EFI實作。在此之後，所有的麥金塔系統(Intel-Based)也都是使用使 這種韌體(Firmware)出貨。 現在所有目前的Macintosh systems 也都可以啟動傳統的作業系統Windows XP，簡單說就是WindowsXP不認識EFI，而Apple機器內如果裝了Windows XP就必須使用Legacy BIOS方式去啟動Windows XP，因此Apple更新了EFI的Firmware支援，去模擬出一個傳統的BIOS介面來支援，應該也是叫做CSM。
從2005年之後，幾乎大多數的Intel 主機板都開始出貨這種支援新的框架架構的主機板的韌體(Framework-based firmware)。現在像是一些新的mobile,，desktop和 server 產品，在2006年起，也都開始使用這種框架。
自2005起，EFI也開始被實作在非PC架構的系統上，像是嵌入式系統，像是 embedded systems based 的 XScale cores。
而EDK 還包含了NT32 的目標(Target)，也就是說它允許EFI Frimware和EFI Application 去執行一個Windows 應用程式。
Security and freedom concerns
According to Ron Minnich, the lead developer for LinuxBIOS, one of the stated goals of EFI is to protect hardware vendors "intellectual property"[15]. This raises security concerns and notably makes creating a free software BIOS impossible.
EFI could be used to create a "DRM BIOS", thus letting vendors build computers which limit what the user can do.
有關於自由軟體運動v.s EFI 請參考下列網站說明：
http://taiwan.cnet.com/enterprise/technology/0,2000062852,20098242,00.htm
Reference
維基百科
CNET
EFI(Extensible Firmware Interface)之1
EFI為Extensible Firmware Interface的簡稱。
中文叫做可延伸式韌體界面...
這裡有詳細的討論文章可以參考
http://taiwan.cnet.com/enterprise/technology/0,2000062852,20098242,00.htm
Intel 搞的EFI叫Tiano，EFI只是一個SPEC名稱，
Tiano才是Intel搞出來bios source code的名稱。
EFI就是要各硬體廠商自己寫BIOS，就是所謂的
EFI driver，然後BIOS vendor只要整合combine
，甚至end user可以不改source code自己load driver
unload driver，很方便，可是對傳統的bios vendor就不妙了，
他們的角色變的可有可無啦。
现在TIANO已经Open Source了.
你可以在
http:\\www.tianocore.org
上获得它的source code.
最近又出現一種新發展標準, 叫uEFI (Unified Extensible Firmware Interface), :002: 據了解...它是建構在EFI 1.10 規格所發展出來的新標準。
目前力拱uEFI的大廠, 包括
Phoenix Technologies (http://www.phoenix.com/en/Home/default.htm)
Intel (http://www.intel.com/)
Microsoft (http://www.microsoft.com/)
AMD (http://www.amd.com/us-en/)
American Megatrends Inc. (http://www.ami.com/)
Dell (http://www.dell.com/)
Hewlett Packard (http://www.hp.com/)
IBM (http://www.ibm.com/us/)
Insyde (http://www.insydesw.com.tw/en/index.asp)
看來它將會取代EFI, 成為業界發展的主流啦:
詳細內容可以至http://www.uefi.org/index.php?pg=2獲得!!
2008年5月9日 星期五
Sound and Vision: A Technical Overview of the Emotion Engine
By Jon Stokes | Published: February 16, 2000 - 07:00AM CT
Preface
I'll spare you the obligatory opening fluff paragraph that goes something like "when Sony first announced the Emotion Engine...," and I'll cut right to the chase. The Emotion Engine is weird. It's so weird, in fact, that it took me quite a while to figure out how it works, and as a result, it's going to take me quite a while to explain it. The result of this is that I want to approach this topic in two parts.
The first part of this article will not be as technically granular as most of my previous work because I want to provide a pertinent overview and a context for understanding the Emotion Engine in detail, without addressing some of the more complex architectural issues. For the technically uninitiated, the first part will suffice in bringing you the mojo you need (and hopefully wetting your whistle for more). With the foundation laid in part I, the second part of this article will, then, delve into the depths of the Emotion Engine. This second part is probably less accessible than the first, because to understand it, you'll need to be familiar with CPU architectural concepts like pipelining, VLIW, SIMD, instruction latency, throughput, etc. If you are not familiar with these terms, I'd suggest checking out some of my previous work. [Update 10/05/00: I've since written a system-level comparison of the PS2 and the PC, which should be a bit more accessible than this article. I'd suggest reading it first.]
Also, a disclaimer before I get started. The literature on the PS2 offers conflicting numbers for the sizes of the various caches in the Emotion Engine. These numbers are usually the last to be fixed at production time, and I'm not sure of the latest ones. However, I used the numbers that I thought were most recent. Feel free to correct me if you know otherwise.
Part I: General Playstation 2 Overview
The bulk of this article will deal exclusively with design and function of the heart of Sony's Playstation 2: the Emotion Engine. However, because of the way Sony designed the PS2, it's not really possible to look only at the Emotion Engine, and ignore the rest of the system. So we'll start out by looking at the system as a whole, and then we'll narrow the discussion to the Emotion Engine.
We have to look at the Emotion Engine in the context of the overall design of the PS2 because, unlike a modern PC's CPU, the Emotion Engine is not really a general purpose computing device. The CPU of a PC is designed from the ground up to run SPEC benchmarks...er, application code as fast as possible. Since application code comes in a wide variety of forms and performs a wide variety of functions, CPU hardware must be general enough to give acceptable performance on almost anything a coder throws at it. In a PC system, this general-purpose CPU is augmented by special purpose hardware for things like video acceleration, network communications, sound processing, etc..
The PS2 is in a slightly different situation. The PS2's designers had the luxury of designing hardware whose main purpose is to run one type of application extremely well: the 3D game. Sure, the PS2 can run web browsers, mail clients, and other types of software, but that's all secondary. The main thing the PS2 does is 3D gaming, which means generating the kind of immersive sound and vision that places you in a virtual world. Nearly all of the PS2's hardware is dedicated to providing some specific portion of that audiovisual gaming experience.
So just how does the PS2 generate 3D graphics and sound? Let's take a look at the main parts of the PS2.
In the above picture, you can see that there are four main parts to the device. Let's look at the one at a time. The I/O Processor (IOP) handles all USB, FireWire, and game controller traffic. When you're playing a game on the PS2, the IOP takes your controller input and sends it to the Emotion Engine so that the Emotion Engine can update the state of the game world appropriately. The Emotion Engine is the heart of the PS2, and the part that really makes it unique. The Emotion Engine handles two primary types of calculations and one secondary type:
- Geometry calculations: transforms, translations, etc.
- Behavior/World simulation: enemy AI, calculating the friction between two objects, calculating the height of a wave on a pond, etc.
- Misc. functions: program control, housekeeping, etc.
When all is said and done, the Emotion Engine's job is to produce display lists (sequences of rendering commands) to send to the Graphics Synthesizer. The Graphics Synth is sort of a souped-up video accelerator. It does all the standard video acceleration functions, and its job is to render the display lists that the EE sends it. Finally, the Sound Processor is the "soundcard" of the PS2. It lets you do 3D digital sound using AC-3 and DTS.
The Emotion Engine is sort of a combination CPU and DSP Processor, whose main function is simulating 3D worlds. So before we discuss the Emotion Engine's architecture in detail, we should talk a bit about DSP (Digital Signal Processing) and 3D graphics.
3D rendering and DSP basics
Background: 3D rendering and DSP basics
A DSP processor, in a nutshell, takes in massive amounts of input data and performs repetitive, loop-based calculations on it to produce massive amounts of output data. Speed and bandwidth are of the essence in digital signal processing. One of the most useful and important features that modern DSPs have is the ability to do a MAC (multiply-accumulate) in a single cycle. A MAC is used in a variety of vector calculations, the most common of these being the dot product. The dot product involves summing the products of vector element pairs, and it requires a series of MACs to calculate. The Emotion Engine has a total of 10 FMACs (Floating-Point Multiply-Accumulators), each of which can do one 32-bit floating-point MAC operation per cycle. If you were wondering what's behind those outrageous polygon counts that Sony publishes for the PS2, now you know; the PS2 can do a lots of MACs, very, very quickly.
The second big requirement for a DSP processor is memory bandwidth and availability. The PS2 is full of small, strategically placed caches (the SPRAM, VU instruction and data memory, etc.) that can be accessed in a single cycle. More importantly, the SPRAM (Scratch Pad RAM--more on this in a moment) interleaves those single-cycle CPU accesses with slower memory bus DMA accesses, so the SPRAM doesn't get tied up by the slower main bus. Finally, the Emotion Engine contains a 10-channel DMA controller (DMAC) to manage up to 10 simultaneous transfers on the Emotion Engine's internal 128-bit, 64-bit, and 16-bit buses. With the DMA controller directing all that bus traffic between the various components and types of memory, the other components are free to do their thang without having to manage data transfers themselves.
The final bit of background info that's pertinent to our project involves 3D rendering. This isn't the place to discuss 3D rendering basics or anything like that (and I'm not really the guy to discuss them either), but there is one aspect of the rendering process we should cover. The Graphics Synthesizer on the PS2 takes data from the Emotion Engine in a very specific form: the display list. The display list is a sequence of drawing commands that tells the GS which primitive shapes to draw and where. A typical display list contains commands to draw vertices, shade the faces of polygons, render bitmaps, etc.--basically, the commands required to actually draw the virtual, 3D world of the game. The Graphics Interface unit (GIF) can take multiple display lists from multiple units inside the Emotion Engine and combine them to allow the Graphics Synth to produce composite images. Or, it can arbitrate between the lists to decide which ones get drawn and when.
Since the Graphics Synthesizer eats display lists, the Emotion Engine's main job is to feed those lists to it. The Emotion Engine's various subunits can operate independently of each other in order to asynchronously generate multiple display lists to send to the GS. Since the Graphics Synth's interface unit, the GIF, handles, tracks and manages all of these display lists, Emotion Engine doesn't really have to waste computational resources or internal bus bandwidth keeping track of them. Its various sub-units just concentrate on cranking them out and sending them over a dedicated, 64-bit bus to the GIF. Render 'em all, and let the GIF sort 'em out.
The Emotion Engine: Basic Architecture
As was stated above, the Emotion Engine's primary piece of output is the display list. Generating those display lists involves a number of steps besides just the obvious geometry calculations. For instance, if the software you're running is a racing game, then you've got to first calculate the virtual friction between a car's tires and the road (among other things) when the car turns a corner before you can draw the next scene. Or if the game is an FPS, you have to run the enemy AI's path-finding code so you'll know where to place them on each frame. So there's a lot of stuff that goes on behind the scenes and affects the output on the screen. All of this labor--geometry calculations, physics calculations, AI, data transfers, etc.-- is divided up among the following units:
- MIPS III CPU core
- Vector Unit (which is actually two vector units, VU0 and VU1).
- floating-point coprocessor, or FPU
- Image Processing Unit (The IPU is basically an MPEG2 decoder with some other capabilities).
- 10-channel DMA controller
- Graphics Interface unit. (GIF)
- RDRAM interface and I/O interface (for connecting to the two RDRAM banks and the I/O Processor, respectively))
All of the above components are integrated onto one die and are connected (with the exception of the FPU) via a shared 128-bit internal bus.
As was noted in the bullet list, the VU can be further divided into two independent, 128-bit SIMD/VLIW vector processing units, VU0 and VU1. These units, though they're microarchitecturally identical, are each intended to fill a specific role. Toshiba, who designed the Emotion Engine and licensed it to Sony, didn't feel that it was optimal to have three pieces of general purpose hardware (a CPU and two vector processors) that could be assigned to any task that was needed. Instead, they fixed the roles of the devices in advance, customized the devices to fit those roles, and organized them into logical units. In that respect, they're sort of like employees who've been grouped together on the basis of talent and assigned to teams. Let's look at the division of labor amongst the components:
- CPU + FPU: basic program control, housekeeping, etc.
- CPU + FPU + VU0: behavior and emotion synthesis, physics calculations, etc.
- VU1: simple geometry calculations that produce display lists which are sent directly to the Graphics Synth (via the GIF).
- IPU: image decompression.
Of the above "teams," 2 and 3 are the ones I want to talk about here.
The CPU/FPU/VU0 team
The FPU and VU0 are coprocessors for the MIPS III CPU core. This means that the CPU, the FPU, and VU0 all form a logical and functional unit (or a team, if you will) where the CPU is the primary, controlling device and the other two components extend its functionality. This CPU/FPU/VU0 team has a common set of goals: emotion synthesis, physics, behavior simulation, etc. I'll be going into much more detail on this collaboration in the second half of the article.
There are two main things that bind this team together and allow them to work very closely with each other. The first is the way they communicate with each other: VU0 and the FPU each have a dedicated, 128-bit coprocessor bus that connects them directly to the CPU. That way, they don't have to talk over the main, shared bus. The dedicated 128b bus also gives the CPU direct access to VU0's registers, and allows VU0 to fill its role as a standard, MIPS III coprocessor.
The other important component that ties the CPU core and VU0 closely together is the Scratch Pad RAM. The SPRAM is 16K of very fast RAM that lives on the CPU, but that both the CPU and VU0 can use to store data structures. The SPRAM also acts as a staging area for data, before it's sent out over the 128b internal bus. So the SPRAM is kind of like a shared workspace, where the CPU and VU0 collaborate on a piece of data before sending it out to wherever it needs to go next.
The VU1/Graphics Synth team
The other main team is composed of VU1 and the Graphics Synthesizer (which communicate via the GIF). Just as VU0 has a dedicated bus to the CPU core, VU1 has its own 128-bit dedicated path to the GIF. However, VU1 and the Graphics Synth aren't as closely tied together as are the CPU/FPU/VU0 group. VU1 and the GS are more like equal partners, and one doesn't control the other. You're probably wondering at this point just who does control VU1. This is an interesting question, and we'll discuss the answer when we talk about VU1's architecture in detail.
Putting the teams together
Though the roles of the components were fixed by the PS2's designers, the overall design is still quite flexible. You divvy up an application's work amongst the teams however you like. For instance, the CPU/FPU/VU0 group can generate display lists and do geometry processing in parallel with VU1, so both groups can send display lists to the GIF at the same time.
Or, the CPU/FPU/VU0 group can act as a sort of preprocessor for VU1. The CPU and co. process conditional branches in the rendering code and load data from main memory. They then generate world information that VU1 takes as input and and turns into a display list.
This flexibility allows a developer to customize the process of generating and rendering the 3D environment to suit the needs of the specific application you're working with.
Now that we've gone over the basics of the Emotion Engine's operation, it's time to get hardcore. For the remainder of this article, I'll go in-depth on the MIPS III CPU core, VU0, and VU1. I'll give you the straight scoop on how these components are designed, and how they're integrated with each other. If terms like instruction latency, pipelining, and SIMD make your eyes glaze over, then you might want to check out here. If, however, you're an architecture enthusiast who eats CPU internals for breakfast, then hang on, because what follows is quite fascinating.
The MIPS III CPU Core
The MIPS ISA has been a popular one for everything from game consoles to SGI workstations. Check out this page for the rundown on the various products that MIPS has shown up in. Among them are:
- Sony Playstation
- Nintendo 64
- Sony's WebTV
- Cassio's Cassiopeia PDA line.
- Sony's AIBO
- Various printers, copiers, scanners, etc.
In short, the MIPS ISA is an industry standard RISC ISA that's found in applications almost everywhere. Sony's MIPS III implementation is a 2-issue design that supports multimedia instruction set enhancements. It has 32, 128-bit GPRs (general purpose registers), and the following logical pipes:
- Two 64-bit integer ALUs
- a 128-big Load/Store Unit
- a Branch Execution Unit
- FPU Coprocessor (COP1)
- Vector Coprocessor, VU0 (COP2)
(Here's a shot of the processor block diagram.) The core can issue two 64-bit integer ops, or one integer op and one 128-bit Load/Store per cycle. For the obsessed, below is a handy chart that gives you a breakdown of all the types of instructions that can be issued concurrently:
| ALU | MAC0 | MMI | Branch | COP1 oper. | COP2 oper. | |
| ALU | X | X | X | X | X | X |
| MAC1 | X | X | X | X | X | X |
| LZC | X | X | X | X | X | X |
| Ld/St | X | X | X | X | X | X |
| SYNC | X | X | X | X | X | X |
| Branch | X | X | X | X | X | |
| ERET | X | X | X | X | X | |
| COP0 ld/mov | X | X | X | X | X | X |
| COP1 ld/mov | X | X | X | X | X | X |
| COP2 ld/mov | X | X | X | X | X | X |
The two, fully-pipelined 64b integer ALU's are interesting, because they can either be used independently of each other (like in a normal CPU), or they can be locked together to do 128-bit integer SIMD in the following configurations: sixteen, 8-bit ops/cycle; eight, 16-bit ops/cycle; four, 32-bit ops/cycle. Pretty sweet.
To take advantage of the integer and FP SIMD capabilities that COP2 (COP2 = VU0) and the iALUs provide, Toshiba used extensions to the MIPS III ISA that include a comprehensive set of 128-bit SIMD instructions. Here are the instruction types that the CPU core supports:
- MUL/DIV instructions
- 3-op MUL/MADD instructions
- Arithmetic ADD/SUB instructions
- Pack and extend instructions
- Min/Max instructions
- Absolute instructions
- Shift instructions
- Logical instructions
- Compare instructions
- Quadword Load/Store
- Miscellaneous instructions
The CPU has a 16K instruction cache and an 8K data cache, each of which are two-way set associative. It's also capable of speculative execution using a simple, two-part branch prediction mechanism (a 64-entry BTAC and a BHT). Toshiba didn't waste a lot of resources on branch prediction, because the CPU's pipeline is a short 6 stages. Unlike with Willamette's extremely deep 20-stage pipeline, the penalty for a mispredict isn't too high. Here are the pipe stages:
1. PC select
2. Instruction fetch
3. Instruction decode and register read
4. Execute
5. Cache access
6. Writeback
Pretty standard RISC stuff. As usual, the execute stage can take a couple of cycles depending on the latencies of the instructions.
I discussed the SPRAM earlier, but I didn't mention that it has it's own address space that's accessible to the CPU via standard MIPS III Load/Store instructions. These loads and stores are interleaved with the main bus accesses to keep throughput up.
The FPU coprocessor, COP1, doesn't really deserve its own section. It's pretty much a straight-up, floating-point coprocessor that's a throwback to the classic RISC days when the FPU was a separate unit from the core. It executes basic, 32-bit MIPS coprocessor instructions using one FMAC unit and one FDIV unit, each of which is the same as the FMACs and FDIVs in the vector units. I'll talk about what these units do when we get to the vector unit discussion.
As you can tell from the above, the CPU core isn't really all that exciting. The only really cool things in it are the SPRAM and the 128-bit integer SIMD capabilities. Other than that, there's not much out of the ordinary going on. This unit is mostly here to handle program control flow by processing branch commands. It also does other stuff, but it doesn't do any of the real heavy lifting--that's reserved for the vector units.
Vectors
Both VU0 and VU1 are microarchitecturally identical, but they're not functionally identical. VU1 has some extra features tacked onto the outside of it that help it do geometry processing, and VU0 has some features that it doesn't normally use (but that VU1 does). Toshiba did things this way to make the units easier to manufacture. Since VU0 is simpler, we'll start with it first. Just keep in mind that a lot of what's said about VU0 also applies to VU1.
Vector Unit 0
VU0 is a 128-bit SIMD/VLIW design. (If you're confused about the term "SIMD/VLIW," don't worry, so was I at first. We'll discuss what this term means in a special section to follow.) Since VU0 is a coprocessor for the MIPS III core, it spends most of its time operating in Coprocessor Mode. This means it looks like just another logical pipe (along with the integer ALUs) to the programmer. The instructions that make VU0 go are just 32-bit MIPS COP instructions, mixed in with integer, FPU, and branch instructions. In this respect, VU0 looks a lot like the G4's Altivec unit. Often, in the rendering process, the CPU maintains a separate thread that controls VU0. The CPU places FP data on the dedicated bus in 128b chunks (w,x,y,z), which the VIF unpacks into 4 x 32 words for processing by the FMACs.
VU0 has its own set of 32, 128-bit FPRs (floating-point registers), each of which can hold 4, 32-bit single precision floating-point numbers. It also has 16, 16-bit integer registers for integer computation.
Here are the computational units available to VU0 (and VU1):
- 4 FMACs
- 1 FDIV
- 1 LSU
- 1 ALU
- 1 random number generator.
The first 5 units here, the 4 FMACs and the 1 FDIV, are sort of the heart of both VU0 and VU1 (which are themselves the heart of the Emotion Engine, which is itself the heart of the PS2). So this is where the magic happens. Each of the FMACs can do the following instructions:
| Floating-Point Multiply-Accumulate | 1 cycle |
| Min/Max | 1 cycle |
The FDIV unit does the following instructions:
| Floating-point Divide | 7 cycles |
| Square Root | 7 cycles |
| Inverse Square Root | 13 cycles |
The bulk of the processing that the PS2 does to make a 3D game involves performing the above operations on lots and lots of data.
Now, those last three units in my list (LSU, ALU, and RNG) aren't normally shown in most charts as being part of VU0. I suspect this is because they aren't used in coprocessor mode. When VU0 is acting like a MIPS Coprocessor, it only uses the 4 FMACs. "Wait a minute," you're saying, "isn't VU0 always a MIPS coprocessor--you know, the 128-bit dedicated bus and stuff? You went to great lengths to make that point in the first half of the article." Yeah, I did kind of insist that VU0 is on the CPU's "team," and that they share the same goals, and that it's bound to the CPU, etc.. This is kind of misleading (although I would argue heuristically justifiable), but all will become clear in the final section. For now, just understand that VU0 mostly operates as a MIPS Coprocessor that handles any FP SIMD instructions that show up in the CPU's instruction stream.
Vector Unit 1
VU1 is a fully independent SIMD/VLIW processor that includes all the architectural features of VU0, plus some additional mojo. These additions relate directly to VU1's role as a geometry processor for the Graphics Synth, and they help bind it more tightly to the GS. The primary addition is an extra functional unit, the Elemntary Functional Unit (EFU). The EFU is just 1 FMAC and 1 FDIV, just like the CPU's FPU. The EFU performs some of the more basic calculations required for geometry calculation.
Another big difference between VU1 and VU0 is that VU1 has 16K of data memory and 16K of instruction memory (as opposed to VU0's 8K data/8K instruction sizes). This larger amount of data memory is needed because VU1's role as a geometry processor requires that it handle much more data than VU0.
Finally, VU1 has multiple paths it can take to get data to the GIF (and on to the GS). Like VU0, VU1 can send display lists to the GIF via the main, 128b bus. Or, VU1's VIF can send data directly to the GIF. Finally, there's a direct connection between VU1's 16K data memory and the GIF, meaning that VU1 can work on a display list in data memory, and the DMAC can transfer the results directly to the GIF.
I have to pause here and note that there's some serious confusion in Sony's literature on the direct path between VU1 and the GIF. One diagram for a slide show seems to show the path as connecting the instruction memory to the GIF, another diagram quite obviously shows the path going from the lower execution unit to the GIF, and yet another shows it with the path connecting the data memory to the GIF. This last one is the only one that makes sense to me, but I went ahead and left my diagram ambiguous.
As you'll recall from the discussion of VU0, VU0 is controlled by the CPU, and VU0 gets its instructions from whatever program the CPU is currently running. VU1, however, doesn't work that way. VU1's VIF plays a much more prominent role in VU1's life than VU0's VIF does in its. VU1's VIF takes in and parses what Sony confusingly calls a 3D display list. This 3D display list is not VU1's program. Rather, it's a data structure that contains two types of information, and some specialized commands that tell VU1 how to handle this information. The two types of info are
a. the actual VU1 program instructions, which go in VU1's instruction memory.
b. the data that said program operates on. This goes in VU1's data memory.
The VIF decodes and parses the 3D display list commands, and makes sure that VU1 program code and data find their way into the correct spots. In this manner, VU1 can operate independently of the CPU to generate display lists. Executing these VU1, "VLIW mode" programs brings into play those three units that VU0 often neglects: the LSU, the iALU, and the RNG. These three units, along with the EFU (which acts as a general FPU), all function to make VU1 a full-blown SIMD/VILW coprocessor. Hahaha...there's that term again: SIMD/VLIW. Now it's time to find out what it means.
Programming the VU
To wrap up, we're going to take a look at the VU's instruction format, and talk about its microarchitecture in a bit more detail. We'll look at VU1 first, because it always runs in "VLIW mode." Then we'll talk about VU0, and how it's different.
Both VU1 and VU0 are 2-issue, VLIW processors. The basic instruction format for VU1 is a 64-bit, VLIW instruction packet (or "bundle," or whatever VLIW term you want to use) that can be divided into two, 32-bit COP2 instructions.
These two instructions are executed in parallel by two execution units: the upper execution unit and the lower execution unit. (Refer back to the two VU block diagrams on the last page. The upper unit is blue and the lower unit is green.) These two units have the following functionality:
| Upper instructions | Lower instructions |
|
|
Now, what you should note is that the upper execution unit is a SIMD unit, while the lower isn't. Hence the term "VLIW/SIMD." So the code is "64-bit VLIW," of which 32 bits are SIMD. Cool, eh? I thought so.
To see this in action, let's look at a code example that I've adapted from one of Sony's slides.
| Upper Instruction | Lower Instruction |
MUL VF04, VF03, Q | DIV Q, 1.0, VF02.w |
MUL ACC, VF10, VF01.x | MOVE VF03, VF02 |
MADD ACC, VF11, VF01.y | ADD VI03M VI03, -1 |
MADD ACC, VF12, VF01.z | NOP |
MADD VF02, VF13, VF01.w | LQ VF01, VI01++ |
NOP | BGTZ VI03, LOOP |
NOP | SQ VF04, VI02++ |
The instructions on the left are executed by the upper execution unit, while the ones on the right are executed by the lower unit.
VU0 is a bit different from VU1 in that, instead of operating in VLIW mode all the time, it normally runs in "MIPS Coprocessor Mode." A MIPS Coprocessor instruction is a 32b instruction and not a 64-bit VLIW instruction. So this means that when it's in COP mode, VU0 can crunch 4, 32-bit FP SIMD numbers in parallel, using the 4 FMACs in the upper execution unit. (I'm assuming that in this situation, the upper opcode contains the SIMD FP instruction op and the lower opcode a NOP.)
VU0 doesn't have to stay in COP mode though. It can operate in VLIW mode by calling a micro-subroutine of VLIW code. In this case, it takes a 64-bit instruction bundle and splits it into two 32-bit MIPS COP2 instructions, and executes them in parallel, just like VU1.
As you can see, having two operating modes for VU0 is a bit complex, but it gives the unit a lot of flexibility.
Conclusion
As you can see from the above breakdown, with a total of 10 FMACs, 4 FDIVs, and all the other integer, branch, and load/store resources available, the Emotion Engine is a hoss.
Not only does the Emotion Engine have horsepower under the hood, but its aggressively new, cutting-edge design means that it's going to take a while for developers to really learn to use all that power. It'll be interesting to see if the PC has caught up with the PS2 by the time PS2 developers figure out how to exploit this hardware to its fullest potential.
Although I've stated repeatedly that the PS2's number one application is 3D gaming, neither Sony nor Toshiba (Toshiba designed the Emotion Engine, and Sony licenses it) are going to sit by and let this hardware get pigeonholed in that application space. Sony has invested big, big money (I think it's around $100 million) in developing non-game applications for the PS2. So by the time the PS2 goes stateside, we should see other types of software available for it. This device is going to be the centerpiece of Sony's assault on the world's living rooms, so you can bet they'll milk it for all they can.
Toshiba is also planning to leverage the Emotion Engine in other markets. I don't have any details, but I'd imagine that before too long we can expect to see a whole range of devices based on this chip. As far as its options in the embedded market, it's not exactly the lowest power device available. Here are some specs that should give you an idea how it stacks up, process wise, to other CPUs out there.
| Clock | 250 MHz |
| VDD | 1.8v |
| Design Rule | 0.25 um |
| Gate Length | 0.18 um |
| Power | 13 watts |
| Transistors | 10.5 million |
| Die size | 17 mm x 14.1 mm (240 mm2) |
| Package | 540-pin PBGA (Ball Grid Array) |
| Layers | 4-layer metal |
Just to put things in perspective, 10.5 million transistors is the same number of transistors that the G4 has, with the K7 weighing in at about 22 million transistors. So while the Emotion Engine isn't exactly as svelte as Crusoe, it's pretty darn lean considering all the hardware that's packed onto it.
All in all, it should be a fascinating ride in the next few months as MS and Nintendo begin to ready their own console offerings. The PS2 has really upped the ante in terms of raw gaming horsepower, so MS and Nintendo are going to have to offer something killer in response. (Was I the only one who was unimpressed by the recently-released X-Box specs? I hope nVidia packs some amazing hardware into it, because after looking at the Emotion Engine, a 600MHz Intel offering ain't turnin' me on...maybe if it's a Willamette...) All speculation aside though, one thing is definitely for certain. As of the Japanese launch of the Playstation 2 last month, the home entertainment scene just got much, much more exciting.
Bibliography (and props)
Unfortunately, none of the articles on the PS2 that I used for my research are (legally) available free of charge. I think you can get most of them via the Ask IEEE service on the web though. Speaking of docs, I want to send a big whopping thank you to all the folks who responded to my recent cry for help. I've been poring over the docs in preparation for this article, and I haven't had time to write thank-you's yet. Emails will definitely be forthcoming though, because you guys made this article possible. Now, to the bibliography:
- K. Kutaragi et al., "A Micro Processor with a 128b CPU, 10 Floating-Point MACs, 4 Floating-Point Dividers, and an MPEG2 Decoder," ISSCC (Int’l Solid-State Circuits Conf.) Digest of Tech. Papers,Feb. 1999, pp. 256-257.
- F.M. Raam et al., “A High Bandwidth Superscalar Microprocessor for Multimedia Applications,” ISSCC Digest of Technical Papers,Feb. 1999, pp. 258-259.
- A. Kunimatsu et al., 5.5 GFLOPS Vector Units for “Emotion Synthesis”, (Slide show and presentation.) System ULSI Engineering Laboratory, TOSHIBA Corp. and Sony Computer Entertainment Inc.
- Masaaki Oka Masakazu Suzuoki. Designing and Programming the Emotion Engine, Sony Computer Entertainment. IEEE Micro, pp. 20-28
- Various other slides from presentations that people mailed me. I have no idea where they came from, but if there was copyright info on them and I used a diagram from them, I included it.
- Berkeley Design Technology, Inc. DSP Processors and Cores -- the Options Multiply. Reprinted from Integrated System Design, June, 1995
- Berkeley Design Technology, Inc. Choosing a DSP Processor.
==========================================
SONY COMPUTER ENTERTAINMENT ANNOUNCES WORLD’S FASTEST 128 Bit CPU "EMOTION ENGINE" FOR THE NEXT GENERATION PLAYSTATION
TOKYO, March 2, 1999 -- Sony Computer Entertainment Inc. is pleased to announce the co-development with Toshiba Corp. of the 128 bit CPU ("EE", or "Emotion EngineÔ ") for use in the next generation of PlayStationÒ . In order to process massive multi-media information at the fastest possible speeds, data bus, cache memory as well as all registers are 128 bits; this is integrated on a single chip LSI together with the state of the art 0.18 micron process technology. The development of a full 128-bit CPU is the first of its kind in the world.
Not only will this new CPU have application for games, but it will be the core media processor for future digital entertainment applications, and has a vastly superior floating point calculation capability compared to the latest personal computers. The new CPU incorporates two 64-bit integer units (IU) with a 128-bit SIMD multi-media command unit, two independent floating point vector calculation units (VU0, VU1), an MPEG 2 decoder circuit (Image Processing Unit/IPU) and high performance DMA controllers onto one silicon chip. The massive combined performance of this CPU permits complicated physical calculation, NURBS curved surface generation and 3D geometric transformations, which are difficult to perform in real time with PC CPUs, to be performed at high speeds.
In addition, by processing the data at 128-bits on one chip, it is possible to process and transfer massive volumes of multi-media data. CPUs on conventional PCs have a basic data structure of 64 bits, with only 32 bits on recent game consoles. The main memory supporting the high speed CPU uses the Direct Rambus DRAM in two channels to achieve a 3.2GB/second bus bandwidth. This equates to four times the performance of the latest PCs that are built on the PC-100 architecture.
By incorporating the MPEG 2 decoder circuitry on one chip, it is now possible to simultaneously process high-resolution 3D graphics data at the same time as high quality DVD images. The combination of the two allows the introduction of a new approach to digital entertainment and real-time graphics and audio processing.
With a floating point calculation performance of 6.2GFLOPS/second, the overall calculation performance of this new CPU matches that of a super computer. When this is applied to the processing of geometric and perspective transformations normally used in the calculation of 3D computer graphics (3DCG), the peak calculation performance reaches 66 million polygons per second. This performance is comparable with that of high-end graphics workstations (GWS) used in motion picture production.
Rambus is a registered trademark of Rambus Inc.
Emotion Engine Features and General Specifications
CPU core 128bit RISC (MIPS IV-subset)
Clock Frequency 300MHz
Integer Unit 64bit (2-way Superscalar)
Multimedia extended instructions 107 instructions at 128bit width
Integer General Purpose Register 32 at 128 bit width
TLB 48 double entries
Instruction Cache 16KB (2-way)
Data Cache 8KB (2-way)
Scratch Pad RAM 16KB (Dual port)
=================================
Main Memory 32MB (Direct RDRAM 2ch@800MHz)
Memory bandwidth 3.2GB/sec
DMA 10 channels
Co-processor1 FPU (FMAC x 1, FDIV x 1)
Co-processor2 VU0 (FMAC x 4, FDIV x 1)
Vector Processing Unit VU1 (FMAC x 5, FDIV x 2)
Floating Point Performance 6.2GFLOPS
Geometry
+ Perspective Transformation 66Million Polygons/sec
+ Lighting 38Million Polygons/sec
+ Fog 36Million Polygons/sec
Curved Surface Generation (Bezier) 16Million Polygons/sec
Image Processing Unit MPEG2 Macroblock Layer Decoder
Image Processing Performance 150Million Pixels/sec
Gate width 0.18 micron
VDD Voltage 1.8 V
Power Consumption 15 Watts
Metal Layers 4
Total Transistors 10.5 Million
Die Size 240 mm2
Package 540pin PBGA
=================================*) 4 dimensional calculation to single precision floating point.
EE performance based on measured data. For P2 and P3, theoretical maximum values based on manufacturer’s figures and other published data.
SONY COMPUTER ENTERTAINMENT ANNOUNCES THE DEVELOPMENT OF THE WORLD’S FASTEST GRAPHICS RENDERING PROCESSOR USING EMBEDDED DRAM TECHNOLOGY
TOKYO, March 2, 1999 -- Sony Computer Entertainment has developed the Graphics Synthesizer for the next generation PlayStation® incorporating a massively parallel rendering engine that contains a 2,560 bit wide data bus that is 20 times the size of leading PC-based graphics accelerators. Very high pixel fill rates and drawing performance is achieved only through the use of embedded DRAM process technology pioneered by SCE for use in advanced graphics technology.
The current PlayStation introduced the concept of the Graphics Synthesizer via the real-time calculation and rendering of a 3D object. This new GS rendering processor is the ultimate incarnation of this concept – delivering unrivalled graphics performance and capability. The rendering function was enhanced to generate image data that supports NTSC/PAL Television, High Definition Digital TV and VESA output standards. The quality of the resulting screen image is comparable to movie-quality 3D graphics in real time.
In the design of graphics systems, the rendering capability is defined by the memory bandwidth between the pixel engine and the video memory. Conventional systems use external VRAM reached via an off-chip bus that limits the total performance of the system. However in the case of the new GS, there is a 48-Gigabyte memory access bandwidth achieved via the integration of the pixel logic and the video memory on a single high performance chip. This allows orders of magnitude greater pixel fill-rate performance compared to today’s best PC-based graphics accelerators.
When rendering small polygons, the peak drawing capacity is 75 Million polygons per second and the system can render 150 Million particles per second. With this large drawing capability, it is possible to render a movie-quality image. With Z-buffering, textures, lighting and alpha blending (transparency), a sustained rate of 20 Million polygons per second can be drawn continuously.
This new architecture can also execute recursive multi-pass rendering processing and filter operations at a very fast speed without the assistance of the main CPU or main bus access. In the past, this level of real-time performance was only achieved when using very expensive, high performance, dedicated graphics workstations. However, with the design of the new Graphics Synthesizer, this high quality image is now available for in-home computer entertainment applications. This will help accelerate the convergence of movies, music and computer technology into a new form of digital entertainment.
Graphics Synthesizer – Features and General Specifications
GS Core Parallel Rendering Processor with embedded DRAM
Clock Frequency 150 MHz
No. of Pixel Engines 16 (in Parallel)
Embedded DRAM 4 MB of multi-port DRAM (Synced at 150MHz)
Total Memory Bandwidth 48 Giga Bytes per Second
Combined Internal
Data Bus bandwidth 2560 bit
Read 1024 bit
Write 1024 bit
Texture 512 bit
Display Color Depth 32 bit (RGBA: 8 bits each)
Z Buffering 32 bit
Rendering Functions Texture Mapping, Bump Mapping
Fogging, Alpha Blending
Bi- and Tri-Linear Filtering
MIPMAP, Anti-aliasing
Multi-pass Rendering
Rendering Performance
Pixel Fill Rate 2.4 Giga Pixel per Second
(with Z buffer and Alphablend enabled)
1.2 Giga Pixel per Second
(with Z buffer, Alpha and Texture)
Particle Drawing Rate 150 Million /sec
Polygon Drawing Rate 75 Million /sec (small polygon)
50 Million /sec (48 Pixel quad with Z and A)
30 Million /sec (50 Pixel triangle with Z and A)
25 Million /sec (48 Pixel quad with Z, A and T)
Sprite Drawing Rate 18.75 Million (8 x 8 Pixels)
Display output NTSC/PAL
Digital TV (DTV)
VESA (maximum 1280 x 1024 pixels)
Silicon process technology 0.25 µ 4-level metal
Total number of transistors 43 Million
Die size 279mm2
Package Type: 384 pin BGA
===========================
SONY COMPUTER ENTERTAINMENT ANNOUNCES THE DEVELOPMENT OF AN I/O PROCESSOR FOR THE NEXT GENERATION PLAYSTATION® THAT PROVIDES 100% BACKWARDS COMPATIBILITY
TOKYO, March 2, 1999 -- Sony Computer Entertainment has developed the I/O Processor with LSI Logic Corporation for the next generation PlayStation. By embedding this processor we have achieved 100% backward compatibility with the current PlayStation. In addition, the new I/O Processor supports IEEE 1394 and Universal Serial Bus (USB) which are the new standards for digital interconnectivity.
The new I/O Processor for the next generation PlayStation is based on the current PlayStation CPU but with enhanced cache memory and a new, higher performance DMA architecture that permits a four-fold increase in data transfer rates. The serial interface is also upgraded to over 20 times the performance of the current PlayStation. In addition, the USB host controller and the IEEE 1394 link and physical layers are integrated onto this single chip LSI.
The USB interface is compatible with OHCI (Open Host Controller Interface) and can handle data transfer rates of between 1.5Mbps and 12Mbps (Mega bits per second). IEEE 1394 can handle data transfer rates of between 100 Mbps and 400 Mbps.
The use of these interfaces allows the future connectivity of the new PlayStation system to a variety of other systems and consumer products such as VCR, Set Top Box, Digital Camera, Printer, Joystick, Keyboard and Mouse amongst others.