如果系統有一個以上的 FS# 存在，以往會透過Shell Script 的方式，來尋找執行 startup.nsh 的 FS 位置，但近期的察看shell的source code，其實shell內部已經有考慮到此情境，因此會根據starup.nsh被執行的位置，自動建立一個variable "homefilesystem"
但 shell spec 似乎沒特別標記此環境變數的定義與用途 ?!?
相關 shell source code 位置與函式:
ShellPkg\Application\Shell\Shell.c
LocateStartupScript ( … )
可以於 startup.nsh 內，使用此變數來鎖定
startup.nsh 的 FS# 位置，可方便進行 script file 的操作。
因為之前有在網路上看到有人寫了可以於 UEFI Shell 下發送命令的程式，因此自己也試試是否可以寫出類似功能的程式，如同 Linux 上的 ipmicmd 依樣，但主要可以在 UEFI Shell 下進行，可以方便開發人員快速的送出命令，便於測試。
功能 :
計畫 :
因最近有同事在處理 ReSizable Bar 的需求，而訪間也有很多可以辨識是否有支援的軟體，但好奇的是，是否有機會可以用較快的方式辨識ReSizable 的支援狀況以及是否被開啟 ?
雖然新版 shell 的 pci 指令可以辨識 ReSizable bar 的支援狀態，但第一時間不好解析 ~
因此依據 PCIE Spec 來解析 ~ 並寫成一APP ~ 或許可以較方便使用，可以提供另一種辨識的方式 !!
*Re-Sizable Bar 的規範在 pcie spec v2.1 就已經制定了，如同 above 4GB 功能，必須要 PCIE 裝置有支援，才會被開啟，因此就算 BIOS 開啟此功能，如果設備本身沒有支援，也不會對其造成影響。
BIOS 的
re-Sizable Bar 功能關閉 !!
BIOS 的Re-sizable
Bar 功能開啟。此時 PCIE Bar 的屬性值會被重設 !!
在職場上，如果自己的腳色定位安排出現尷尬的時候，或許就是給自己的一個警訊，不能倚老賣老。沒有人是無法取代的，更何況做出多次的承諾後，也都還是能夠無預警的取消，代表者自己的角色也就如此了。其實，可以的話，一開始不要做出承諾的話，反而比較好。
剩下的或許只是情懷的枷鎖，要認清自己的身份與立場，還是有做事的態度 !!
這陣子剛好要驗證 PCH 出來的 I2C Controller 的功能，但如果只是要單純確認功能，要弄個Ubuntu 似乎又有點麻煩，所以想說來寫一個 UEFI App，可以進行類似 Linux 的 i2c detect 功能，主要就是提供一個快速又點簡單的方式來判斷 i2c 功能是否正常，且框架都模仿 i2c detect XD。
另外也順便練習一下擷取 ACPI Table，所以多此一舉的透過 MCFG 來取得 PCIE 的基底位置，並使用此方式來取暫存器資料 XD`.
功能 :
1. 支援 PCH LPSS 與 SMBus。*
2. 支援 64 Bit 定址。
3. 使用 MCFG 定址 PCIEX。
4. 可使用 7bit 或 8bit 方式呈現 i2c slave devices。**
5. 支援顯示 i2c 裝置。
*目前只驗證過 TGL-H/UP3 , 但理論上 CML 與其他平台應該要有機會可以使用
** 8bit 模式，只會顯示偶數位置 (預設 BIT 0 為 0)
20230920 更新
1. 修正 shell 2.0 無法正常執行問題。
2. 調整顯示 smbus/i2c devices 的方式。
3. 修正在 DDR5 平台上，掃描 slave addr 位置超過 0x7E 會出錯。
Thanks
最近有機會碰到使用 DDR5 記憶體的案子，因為是很新的技術，所以順便了解一下SPD讀取的方式，進一步了解才發現讀取的方式與以往DDR3,DDR4 有些差異。
先簡單列一下 DDR5 上的特點 :
1. 支援 SPD HUB , 以 Jedec 規範分為 SPD5118 與 SPD5108。
2. SPD5118 , 51 是指 SPD HUB 的 ID，18 是指有 Temp Sensor，08 是指沒有 Temp Sensor。
3. SPD HUB 內的 NVM 總容量為 1024 Byte。
4. SPD HUB 內的 NVM 分為 8 Pages，每個 Page 有 128 Byte。
5. 對應記憶體用的 SPD 會落在 NVM 區域內。
讀取步驟 :
1. 使用 SMBUS Read Byte，讀取 Slave Addr (SA)，偏移位置為 0x00 (MR0)，確認讀取到的值是否為 0x51。
2. 確定有 SPD HUB 的存在後，開始進行 SPD 的讀取。
3. 先進行切換 Page 的動作，偏移位置為 0xB (MR11) 的 BIT [2:0]，3b000 - 3b111。
4. 讀取 NVM 的動作，填上偏移位置，且須將偏移位置的 BIT7 設定為 1 ( MemReg [BIT7] )，切換為內部 NVM 區域。
5. 讀完 128 Byte 後，再切換Page，共八次。
Thanks
WinDDK v7600.16385.1 與 EWDK v1834 是目前編譯 UEFI Image 最常使用到的兩款由微軟提供的開發工具，基本上直接到微軟的官方網站下載，並直接安裝就可以直接使用了，環境變數會在安裝過程中建立好，頂多需要再 IDE 內指定一下路徑即可 !!
但這兩個開發工具，如果全部安裝的話，可能會需要佔掉硬碟約莫 8 GB 左右的容量，當然，如果沒有空間上的顧忌，其實直接安裝是最保險且簡單的 ~
因為個人比較喜歡簡易地設定，加上希望編譯環境能夠單純化，所以嘗試將兩套開發工具的內容簡化，過濾出編譯必要的檔案就好，讓空間需求降低。
而簡化後的 WDK 與 EWDK 所占用的空間，初估約莫 1.3 GB 左右，或許能有效的放出更多的調度空間。
使用附件的 WDK 與 EWDK，可搭配下面環境變數設定 :
由於個人較常使用命令列編譯 (Command Line Compile )，所以環境變數都是透過個別的 batch 檔案宣告，編譯環境會比較單純。
EWDK 與 WDK 為微軟版權所有 !!
Offical WDK Link v7600.16385.1
Offical EWDK (ver 1834) (Build 1703) Link
這邊提供 EWDK 的檔案過濾說明，WDK的部分礙於授權，有機會再提供。
參考看看 !
如果系統有一個以上的 FS# 存在，以往會透過Shell Script 的方式，來尋找執行 startup.nsh 的 FS 位置，但近期的察看shell的source code，其實shell內部已經有考慮到此情境，因此會根據starup.nsh被執行的位置，自動建立一個v...
