在Legacy BIOS 時代, 基本上SMBIOS/ACPI 的規格書都說明在E/F Segments 用特定的Tag String 可以找到需要的Table, 甚至現在SMBIOS v3.2 的Chapter 5.2 還是建議在Non-UEFI的系統上一樣在F Segments 要能找到, 不過能台灣多數的OEM/ODM 很喜歡表現自己能力尤其某A公司喜歡把從IBV的code改到完全不相容,藉以表現自己與眾不同有技術能力,對我來說是個腦殘的事情,當然它們多數情況下只針對廣大的Windows 系統而且是一般普羅大眾,所以測起來沒問題也就這樣延續這個風格一直下去。例如它們家的SMBIOS EPS現在不會出現在F Segment裡,但是ACPI 的RSDT會,這就是很奇怪的事情。
不是所有作業系統都是UEFI based的就是會造成困擾,不過因為昨天看到放在Github上的DumpACPI 還是有人用,還幫我除錯x64版本,發了Issues,因為當初移到Github時,我只簡單在我的32bits VM上測試過就上傳了,畢竟那時我的主要工作環境都是Linux/Android 開發,直到現在換了新環境,又回到跟Windows/BIOS比較貼近的環境。
但是該Issues還提到他的Win32(x86) 版本一樣找不到ACPI RSDP, 所以個人猜測他的系統可能一樣是只針對UEFI system 的設計, 不完全相容舊有規格。那這問題有辦法解決嗎? 應該是可以透過查找整個記憶體空間得到處理的,但是如何更有效率的查找?根據UEFI 的規格書, 透過AllocatePool() & AllocatePages()所配置的記憶體會在32bits系統上一定落於4GB以下, 而且應該是在 80000000h ~ FFFFFFFFh 區間??(待確認), 所以實際上要找的空間就可以限縮再這2GB內, 按照現在電腦的讀取速度,其實這不須要花太久時間去比對要找的資料,而且這還可以延伸去找 UEFI Runtime service 才是。不過需要花點時間去做點實驗測試。
至於現在主流的64bits系統看到規格書提到可以在4GB之上,需要來確認一下EDK2的UDK實作版本到底是怎樣配置記憶體映射的。