對全台灣的人來說，因 COVID-19 的疫情影響，社區群聚突然爆發，從 5/19 全國升級三級警戒以來，這段日子真的不太好過，短短一個月內從天堂掉到地獄，一切都是亂糟糟的，上網看新聞始終充斥各種帶風向、多方陣營互相攻訐、口水噴不停，但疫情始終沒有趨緩的跡象。就像一場棒球賽打到九局全無失分，幾次險局都化險為夷，精彩可期，萬萬沒想到卻在最後半局，被自己的失誤而遭逆轉，賽事不僅輸了卻還沒打完，目前還在失分中看不見止血的跡象...
不發牢騷了，回歸正題。這篇文章要講的是，上次提到黑蘋果三號機還有些後續補完項目，經歷這一個多月來亂糟糟的生活之後，如今總算是有了成果。以下的內容，主要針對黑蘋果三號機使用的 Z490 VISION G 主機板，補完四個項目：Intel iGPU 純內顯輸出、Intel HDMI Audio （Intel 內顯 HDMI 音效），Intel I225-V 主機板 2.5G 有線網路，以及在 macOS 環境下，啟用 Z490 VISION G 內建的 RGB 色彩功能，（2024.04.15）最後再補充一段在不移除不支援 NVMe SSD 的情況下，停用該 SSD 裝置的做法。
一、Intel i7-10700K + 技嘉 Gigabyte Z490 VISION G 純內顯輸出方案
這個項目搞了好幾天，終於搞定了，自己的黑蘋果調教功能也有些許提升。只要在 EFI/OC/config.plist 內，加入以下內容
<key>DeviceProperties</key> <dict> <key>Add</key> <dict> <key>PciRoot(0x0)/Pci(0x2,0x0)</key> <dict> <key>AAPL,ig-platform-id</key> <data>BwCbPg==</data> <key>device-id</key> <data>mz4AAA==</data> <key>framebuffer-fbmem</key> <data>AACQAA==</data> <key>framebuffer-patch-enable</key> <data>AQAAAA==</data> <key>framebuffer-stolenmem</key> <data>AAAwAQ==</data> <key>framebuffer-con0-busid</key> <data>BQAAAA==</data> <key>framebuffer-con0-enable</key> <data>AQAAAA==</data> <key>framebuffer-con0-flags</key> <data>xwMAAA==</data> <key>framebuffer-con0-index</key> <data>AQAAAA==</data> <key>framebuffer-con0-pipe</key> <data>CQAAAA==</data> <key>framebuffer-con0-type</key> <data>AAQAAA==</data> <key>framebuffer-con1-busid</key> <data>BAAAAA==</data> <key>framebuffer-con1-enable</key> <data>AQAAAA==</data> <key>framebuffer-con1-flags</key> <data>xwMAAA==</data> <key>framebuffer-con1-index</key> <data>AwAAAA==</data> <key>framebuffer-con1-pipe</key> <data>CAAAAA==</data> <key>framebuffer-con1-type</key> <data>AAgAAA==</data> <key>framebuffer-con2-busid</key> <data>AQAAAA==</data> <key>framebuffer-con2-enable</key> <data>AQAAAA==</data> <key>framebuffer-con2-flags</key> <data>xwMAAA==</data> <key>framebuffer-con2-index</key> <data>AgAAAA==</data> <key>framebuffer-con2-pipe</key> <data>CgAAAA==</data> <key>framebuffer-con2-type</key> <data>AAQAAA==</data> </dict> </dict> </dict>
也就是 DeviceProperties -> Add -> PciRoot(0x0)/Pci(0x2,0x0) 底下，加上 FameBuffer 的修正參數。把它整理成表格，看起來會比較清楚，如下：
| Key | Type | Value |
| AAPL,ig-platform-id | Data | 07009B3E |
| device-id | Data | 9B3E0000 |
| framebuffer-fbmem | Data | 00009000 |
| framebuffer-patch-enable | Data | 01000000 |
| framebuffer-stolenmem | Data | 00003001 |
| framebuffer-con0-busid | Data | 05000000 |
| framebuffer-con0-enable | Data | 01000000 |
| framebuffer-con0-flags | Data | C7030000 |
| framebuffer-con0-index | Data | 01000000 |
| framebuffer-con0-pipe | Data | 09000000 |
| framebuffer-con0-type | Data | 00040000 |
| framebuffer-con1-busid | Data | 04000000 |
| framebuffer-con1-enable | Data | 01000000 |
| framebuffer-con1-flags | Data | C7030000 |
| framebuffer-con1-index | Data | 03000000 |
| framebuffer-con1-pipe | Data | 08000000 |
| framebuffer-con1-type | Data | 00080000 |
| framebuffer-con2-busid | Data | 01000000 |
| framebuffer-con2-enable | Data | 01000000 |
| framebuffer-con2-flags | Data | C7030000 |
| framebuffer-con2-index | Data | 02000000 |
| framebuffer-con2-pipe | Data | 0A000000 |
| framebuffer-con2-type | Data | 00040000 |
以上參數，理論上應該適用於所有的 Z490 主板 + i7-10700K with Intel UHD 630 內顯輸出。
補充：HEVC (H.265) 無法編碼
附帶補充，倘若發生 H.264 編碼正常，但 HEVC (H.265) 無法編碼的情況，請檢查一下上述原來的設定中有無「AAPL,slot-name」，如果有，則必須刪除。（可用 VideoProc 檢查）。
相對的，如果要使用獨立顯卡進行 HEVC 編碼，則是在 DeviceProperties 底下的獨顯路徑下（可用 PCI List 查看），加入 AAPL,slot-name 字串值為 Slot-1 即可。
二、Intel i7-10700K + 技嘉 Gigabyte Z490 VISION G 啟用 Intel HDMI Audio 音效
2022.06.10 更新：純內顯啟用 Intel HDMI Audio 至今已經有解決方案。不再需要依賴 FakePCIID.kext、FakePCIID_Intel_HDMI_Audio.kext 等偽裝 ID 手段、或是加入 AAPL00,override-no-connect 等亂七八糟又不完美的方法。
根據 AppleALC 的 Release v1.7.2 版（2022.06.06）資訊：
- Update controller patch for 400 series 0x06C8 to fix HDMI audio by @Core-i99
意即把 AppleALC.kext 更新到 v1.7.2+，Intel 400 系列主板就可支援 Intel HDMI Audio 輸出。OC/config.plist 搭配 DeviceProperties -> Add -> PciRoot(0x0)/Pci(0x1F,0x3) 加入以下的 Realtek 1220-VB 板載音效設定即可。
| Key | Type | Value |
| model | String | Realtek 1220-VB |
| device_type | String | Audio device |
| layout-id | Data | 11000000 |
| hda-gfx | String | onboard-2 |
從 AppleALC v1.6.1 開始，layout-id = 0x11 （十進位 17）是專為技嘉 Z490 VISION G 訂製。若一切順利時，用 Hackintool 查看 Sound 頁籤，顯示內容如下：
經歷一年多的時間，Intel i7-10700K + 技嘉 Gigabyte Z490 VISION G 的版載音效、Intel HDMI Audio 音效等問題，皆完善解決。
三、Gigabyte Z490 VISION G 的板載網路 Intel I225-V 驅動
（2022.04.28 重新編輯整理）這個項目有點複雜，需分成兩個部分來說明：
- macOS 11(.4) Big Sur 以前
- macOS 12 Monterey
雖然分成兩個部分，不過兩者設定的方式大多沒有互相衝突，也就是說兩者都照著設定時，Intel I225-V 支援的作業系統可從 10.15 到目前最新的 macOS 12。
3.1 macOS 11(.4) Big Sur 以前
技嘉 Z490 VISION G 主機板內建 Intel I225-V 2.5GbE 乙太網路。這款網路產品直到 macOS 11.4 以後才被原生支援，在此之前都是以偽裝 Intel I210 裝置的方式，由 macOS 系統內的 AppleIntelI210Ethernet.kext（com.apple.driver.AppleIntelI210Ethernet） 驅動。驅動方式如下：
EFI/OC/config.plist 內的設定值：
<dict> <key>DeviceProperties</key> <dict> <key>Add</key> <dict> <key>PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0)</key> <dict> <key>device-id</key> <data>8hUAAA==</data> <key>device_type</key> <string>Ethernet Controller</string> <key>model</key> <string>Intel Ethernet-Controller I225-V</string> </dict> </dict> </dict> <key>Kernel</key> <dict> <key>Patch</key> <array> <dict> <key>Arch</key> <string>Any</string> <key>Base</key> <string>__Z18e1000_set_mac_typeP8e1000_hw</string> <key>Comment</key> <string>Enables Intel Ethernet-Controller I225-V natively.</string> <key>Count</key> <integer>1</integer> <key>Enabled</key> <true/> <key>Find</key> <data>8hUAAA==</data> <key>Identifier</key> <string>com.apple.driver.AppleIntelI210Ethernet</string> <key>Limit</key> <integer>0</integer> <key>Mask</key> <data></data> <key>MaxKernel</key> <string>20.4.0</string> <key>MinKernel</key> <string>19.0.0</string> <key>Replace</key> <data>8xUAAA==</data> <key>ReplaceMask</key> <data></data> <key>Skip</key> <integer>0</integer> </dict> </array> </dict> <key>NVRAM</key> <dict> <key>Add</key> <dict> <key>7C436110-AB2A-4BBB-A880-FE41995C9F82</key> <dict> <key>boot-args</key> <string>dk.e1000=0</string> </dict> </dict> </dict> </dict>
整理成表格看得比較清楚，主要是分成三個地方：
DeviceProperties -> Add -> PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0)
| Key | Type | Value |
| device-id | Data | F2150000 |
| device_type | String | Ethernet Controller |
| model | String | Intel Ethernet-Controller I225-V |
Kernel -> Patch 新增一筆資料：
| Key | Type | Value |
| Arch | String | Any |
| Base | String | __Z18e1000_set_mac_typeP8e1000_hw |
| Comment | String | Enables Intel Ethernet-Controller I225-V natively. |
| Count | Number | 1 |
| Enabled | Boolean | True |
| Find | Data | F2150000 |
| Identifier | String | com.apple.driver.AppleIntelI210Ethernet |
| Limit | Number | 0 |
| Mask | Data | |
| MaxKernel | String | 20.4.0 |
| MinKernel | String | 19.0.0 |
| Replace | Data | F3150000 |
| ReplaceMask | Data | |
| Skip | Number | 0 |
NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> boot-args 加入 dk.e1000=0
| Key | Type | Value |
| boot-args | String | dk.e1000=0 |
如下圖：
以上設定的用意為：
- 「PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0)」加入 device-id = 0x15F2 與 Kernel Patch 修正 AppleIntelI210Ethernet.kext 加入置換為 0x15F3 ，這兩項設定的用意是欺騙 macOS 的 I225LM 驅動程序，來驅動 Intel I225-V 網絡控制器。
- MaxKernel = 20.4.0 與 MinKernel = 19.0.0 是限制在 macOS 15(.x) ~ macOS 11.3(.x) 之間才有作用。而 macOS 11.4 以後 AppleIntelI210Ethernet.kext（com.apple.driver.AppleIntelI210Ethernet） 原生支援 0x15F3，不需 Kernel Patch。
- boot-args 加入參數 dk.e1000=0 （Monterey 12.3 以後需改為 e1000=0），這個參數只對 11.4 以上有效，避免 macOS 11.4 用新的方法（com.apple.DriverKit-AppleEthernetE1000.dext）驅動 Intel 2.5GbE 的網卡，因為新方法在搭載 Intel I225-V 的技嘉主機板會發生崩潰當機的現象。
以上設定方式對 macOS 10.15 ~ 11.x 實測全都有效，包含 11.4 與 11.5。附帶一提的是，倘若系統為 macOS 11.4+，可以只保留 dk.e1000=0 的參數（其他全數刪除）。
3.2 macOS 12 Monterey
在 macOS 12 Monterey Beta 版發表之後， Z490 Vision G 板載 Intel I225-V 網卡開始出現異常。雖然 Beta 版 7~8 一度恢復正常，但是 Beta9 開始乃至正式版上市之後，Intel I225-V 始終無法正常運作，症狀是系統有成功識別裝置、驅動也有載入，但是系統偏好設定 > 網路 > 乙太網路卻始終顯示沒有連線的狀態，等於是系統升級到 macOS 12 Monterey 之後，發生 Intel I225-V 有線網卡無法使用的問題，感覺上像是 macOS 的鍋，因為舊版 macOS 可以正常運作。
大約在 2022 年 4 月初時，德國有位神人 badbrain 發表技嘉主機板載 Intel I225-V 問題的解決方案（德文原文），此方法經 5T33Z0 的驗證確實有效（英文原文）。問題的原因說起來有點複雜，不過這個問題在技嘉的主機板上特別明顯。根據神人發表的證據顯示，技嘉採用 Intel I225-V v1/v2 版本的主機板，在網卡的 EEPROM 內的韌體資訊大多存在某些描述錯誤，而 macOS12 Monterey 在驅動上更深層綁定硬體描述時，最終導致問題的發生。
以下綠色的部分是神人 badbrain 參考多家主機板商的 EEPROM 之後，歸納出來後修改過的資訊。
我個人採用 5T33Z0 發表的方法，實測之後也是有效，這個延宕將近一年的大坑，終於是補上了。5T33Z0 的解決方案寫得非常詳細，圖文並茂，建議參考 5T33Z0 原文即可，以下僅重點翻譯。
3.2.1 寫入經過修正的 Intel I225-V 韌體
1. 先確認 OpenCore 啟用 UEFI Shell 功能。config.plist 設定如下：
2. 下載 I225-Vmod.zip（下載網址：#1 樓附欓），解壓縮後得到 I225MOD （修正後的 I225-V EEPROM 韌體）與 eeupdate64e.efi （EEPROM 更新工具）。這兩個檔案複製到 FAT32 的隨身碟上，或是複製到 EFI 卷冊的根目錄中。
3. 重開機，進入 OpenCore 介面選單，選擇 OpenChell 進入 UEFI Shell 環境。這個環境很像 DOS 或 Linux 的命令模式
4. 進入包含 I225MOD 與 eeupdate64e.efi 檔案的卷冊，指令為 fs[數字]: Enter，例如 fs0: Enter 或 fs1: Enter....。進入之後用 dir 或是 ls 查看是否包含 I225MOD 與 eeupdate64e.efi 這兩個檔案。如果沒有的話，更改 fs[數字]: 直到找到有包含兩個檔案為止。
5.執行 eeupdate64e.efi /gui 按 Enter 執行韌體更新作業，會出現 Intel .... 介面視窗，警告你現在操作的軟體 eeupdate64e.efi 是受機密性保護，不可隨意發布（也就是說，通常只有 Intel 的協力生產廠商才能取得 eeupdate64e.efi ），按 Enter 下一步。
6. 箭頭鍵選擇「Intel(R) Ethernet Controler I225-V」並 Enter
7. 選擇「Raw EEPROM - Extended」並 Enter
8. 在以下的畫面中，先執行備份（F3-Dump To file）後，再載入（F4-Load From File）修正過的 EEPROM 韌體。
9. 按 F3 備份原始 EEPROM 韌體以防萬一。輸入備份檔名按 Enter 後，不會有任何提示（後續可以找到這個備份檔案）
10. 按 F4 載入 EEPROM 韌體，輸入 I225MOD，按 Enter 開始載入。
11. 隨後會問你要不要保留 MAC Address，一定要選擇回答 Yes（選擇 No 則網卡的 MacAddress 會被蓋掉，以後會延伸其他問題）
12. 按 Esc 離開，詢問是否確認儲存變更，回答是。
13. 接下來再按 Esc 離開
14. 選擇 Exit 離開
15. 重開機。
若一切順利的話，從去年秋天 macOS 12 Monterey 上市後就罷工已久的 Intel I225-V ，應該就會恢復連線運作了。
而神人 badbrain 這兩天又發表了一個工具，可以在 Windows 環境中更新 Intel I225-V EEPROM 韌體的工具（#23 樓，下載 GIGABYTE_Intel-i225-firmware-tool.zip 這個檔案 ）。看起來是使用技嘉官網的 1.45 版韌體更新工具，把裡面的 1.45 改為較新的 1.68 版韌體檔案。據說也有相同的效果，不過我沒測試就是了。
3.2.2 使用新版驅動（com.apple.DriverKit-AppleEthernetE1000.dext）：啟用 AppleVTD
從 macOS 11.4 開始，系統預設載入新的網卡驅動（com.apple.DriverKit-AppleEthernetE1000.dext），這導致本來的 Z490 VISION G 用戶使用 11.3 以前的 OpenCode config.plist 設定且不更改的話，會發生當機重啟的現象，所以需在 boot-args 加入參數 dk.e1000=0 （masOS 12.3 以後改為 e1000=0 ）強迫載入舊版 AppleIntelI210Ethernet.kext（com.apple.driver.AppleIntelI210Ethernet）驅動來避免系統崩潰，後來也就一直這麼使用舊驅動。直到近日得知並解決 Intel I225-V 網卡於 Monterey 系統的問題後，才大概知道新版驅動造成系統崩潰的原因。
正面對決黑蘋果的死穴：VT-d
新版網卡驅動依賴 Intel VT-d 功能（IO 虛擬化直接存取技術），而 Intel VT-d 卻是長期以來黑蘋果的死穴，開啟 VT-d 之後輕則各種周邊出現異常，重則各種卡機死當四國宣言，印象中我都是遇到當機重啟的問題。以往黑蘋果解決 VT-d 衝突的方式不外乎兩種：(1) 到 BIOS 設定關閉 VT-d 功能 (2) 若設備未提供 VT-d 關閉選項且功能預設為開啟，或是 BIOS 將 Intel VT-d 設定啟用時，則必需在 OpenCore config 設定的 Kernel > Quirks 底下，將 DisableIoMapper 設定 True 來繞過 VT-d 機制。這兩種方法都會讓 macOS 停用 VT-d ，算是逃避問題的手段。
所以了，如果黑蘋果要使用新版 Intel 網卡驅動（DriverKit），便意味著無法規避 VT-d 機制，得正面對決處理這個死穴。而 VT-d 使用 DMA Remapping 的技術，必需有一組 DMA Rempping Table 數據（名稱為 DMAR）儲存在 BIOS 的 ACPI 表內。因此國外網友 @yosoyoco 研究出解決方案，只需適當修正 DMAR 的內容，刪除該表中 Reserved Memory Region，就能解除這個死穴，看來這又是 Apple 一貫「軟硬體深度綁定」的套路。
以技嘉 Z490 VISION G 來說，操作的方法如下：
(一）取得修正後的 DMAR 數據表
DMAR 數據表跟 USB Port Map 一樣，不同主板就會有不同的內容。Z490 VISION G 的用戶可以從 5T33Z0 提供的檔案 EFI.Z490.VisionG.OC.0.8.1.v2.0.zip 下載解壓縮，裡面的 EFI/OC/ACPI/DMAR.aml 可以直接拿來用，或者是自行從自己的主板提取，操作方式如下（參考來源）：
1. 首先確認 BIOS 的 VT-d 有打開，以及 Intel 內顯也有驅動，OpenCore config 設定的 Kernel > Quirks > DisableIoMapper 為 True 。（也就是 BIOS 內 VT-d 有啟用，但是 OpenCore 遮蔽 VT-d 機制的狀態）
2. 執行 MaciASL 工具，File > New from ACPI > DMAR
則會開啟系統內的 DMAR 表。由於內容有點長，所以以下分成「上半部」、「下半部」兩張圖說明：
在上半部先注意到黃框內兩個值：
- Signature : "DMAR"
- Oem Table ID : "EDK2 " （注意右邊有四個空格）
下半部是重點：
- 反白部分（即兩個 [Reserved Memory Region] 區段）要刪除
- 最下方 Raw Table Data 的部分，跟右邊綠色的部分對照得到：
- "DMAR" 的 HEX 值為 44 4D 41 52
- "EDK2 " 的 HEX 值為 45 44 4B 32 20 20 20 20
也就是說，針對 DMAR 的部分，要做兩件事：
- 刪除兩個 [Reserved Memory Region] 區段
- 記下以下資訊：
- Signature : "DMAR"，HEX 值為 44 4D 41 52
- Oem Table ID : "EDK2 " HEX 值為 45 44 4B 32 20 20 20 20
刪除完兩個區段後如下圖，龜毛一點的話可依照下圖黃色標示空兩行。
3. 修改後的 DMAR 存擋到 EFI/OC/ACPI/ 底下，檔名不限，可取名為 DMAR.aml。
其實說穿了，修正的 DMAR 也只是刪掉 [Reserved Memory Region] 內容罷了。
(二）主板 BIOS 與 OpenCore config.plist 的設定
- BIOS：VT-d 如果尚未啟用，則將它啟用。保存並重新啟動到 macOS 12 Monterey。
- 系統偏好設定 - 網路，將乙太網 > IPv4 設置為DHCP，和進階 > 硬體 > 配置為 Automatic。
- OpenCore 的 config.plist 設定如下：
- ACPI > Add > [n] >
- Comment <string>: DMAR Table
- Enabled <boolean> : True
- Path <string> : DMAR.aml (即上個步驟產生的檔案)
- ACPI > Delete >[n] 加入以下內容：（TableSignature 填入 DMAR 的 HEX，OemTableId 填入 EDK2 的HEX）
- All <boolean>: False
- Comment <string> : Drop OEM DMAR Table
- Enabled <boolean>：True
- OemTableId <data>：45444B3220202020
- TableLength <integer>：0
- TableSignature <data>：444D4152
- DeviceProperties > PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0) : 拿掉或加上 # 做為備註
- Kernel > Quirks > DisableIoMapper 調整為 False
- NVRAM > Add > 7C436110-AB2A-4BBB-A880-FE41995C9F82 > boot-args : 禁用/刪除引導參數 dk.e1000=0
- 將 config.plist 存擋
- ACPI > Add > [n] >
config.plist 的設定會依照 ACPI > Delete 的描述，刪除主機板載的 OEM DMAR Table 資料，並載入自訂修正後的 DMAR.aml 資料。
修改項目的 config.plist 如下：
(三) 重開機。若 Intel VT-d 啟用且 I225-V 有線網卡新版驅動成功載入的話，網卡的部分一樣亮綠燈，且乙太網卡驅動也是新版。
開啟 VT-d、修改 DMAR，費了那麼多功夫載入新版驅動，到底有什麼好處？坦白說，就網卡這部分功能來說似乎沒什麼好處，但是考慮到將哪天新版 macOS 把舊版驅動拿掉，到時候還是得面對，所以趁現在學起來也好。
成功啟用了 VT-d 之後 ，有個蘋果獨家技術 AppleVTD 也會被成功開啟。
AppleVTD 是啥玩意？上網 G 了一下，貌似 Mac 連接某些 Thunderbolt 裝置需要這個東西。我個人的經驗是，macOS 版 Canon EOS Utility 3 使用 USB 與相機連線傳檔時，也會使用到 AppleVTD 這玩意，否則從相機傳檔時有極高機率會發生錯誤。這個問題已在二號機、三號機等黑蘋果設備上皆得到證實和解決（延伸閱讀：Ivy Bridge 攻頂最後一哩：i7-3770K）。
未啟用 AppleVTD 時 ，EOS Utility 3 很容易遇到傳圖失敗的錯誤（下圖）。
感覺上 AppleVTD 似乎與資料傳輸有關，如果沒有 AppleVTD 相關的需求，也許不用這麼搞剛把 Vt-d 徹底搞定。
3.3 技嘉 Z490 VISION G 的 Intel I225-V 有線網卡項目修正總結
以上將所有細節寫出來之後又臭又長，在此快速總結一下：
- 技嘉某些搭載 Intel I225-V v1 及少部分 v2 的主機板，「可能需要」刷入修改過的韌體來解決 macOS 12 Monterey 工作異常的問題。
- macOS 10.15 ~ 11.3 需使用 Kernel Patch 的方式。
- macOS 11.4+ 可透過 boot-args 加入參數 dk.e1000=0 (macOS < 12.3) 或 e1000=0 (macOS >=12.3) 選擇使用新（DriverKit）/舊（AppleIntelI210Ethernet.kext）驅動。macOS 11.4+ 無參數為預設新版，有參數為使用舊版。
- macOS 11.4+ 若想要使用新版驅動，則必須啟用 VT-d 功能（啟用 AppleVTD ）。啟用 VT-d 功能必須伴隨 DMAR 修正，否則會發生系統崩潰當機。
- macOS 13+ 系統已移除舊版驅動 AppleIntelI210Ethernet.kext，若想使用此舊版，除了 boot-args 加入 e1000=0 ，仍需自行下載舊版驅動，並於 config.plist 設定驅動。
四、修正 macOS Ventura 13.3+ 的 Wifi 工作異常（2023.06.10 新增）
這個問題是日前在黑蘋果三號機測試安裝 macOS 14 Beta Sonoma 時，很偶然的情況下發現的。症狀是 macOS Ventura 13.0 ~ 13.2.1 時 Wifi 一切正常，但不論全新安裝或升級到 Ventura 13.3+ 之後，Wifi 有正常驅動卻搜尋不到任何 SSID，也無法連線。但神奇的是黑蘋果二號機（i7-3770 + Z77）升級至 Ventura 13.3+ 卻沒遇到這問題。經由各種測試、重灌升級、排列組合等方法，卡關了將近兩天，終於找到答案（來源）。
如果黑蘋果設備同時滿足以下條件，那可能會觸發 Wifi 無線網路（例如 BCM94360）異常不工作：
- macOS 13.3+ 版本
- 系統成功啟用 AppleVTD（本文 3.2.2 所有操作步驟）
- 系統成功驅動 iGPU 內顯
- 主記憶體超過 16GB（不含 16GB）
- 主板為某些廠牌的 Z370、Z390、Z490，Z590 其中一種（特徵是系統原生 DMAR 表中包含 Reserved Memory Region 區段的主機板）
程序大神 CaseySJ 將驅動程式 IOPCIFamily 經由反組譯後，得知 13.3+ 出現了以往未曾見過兩個新函式：AppleVTD::addMemoryRange 與 AppleVTD::reserveRanges 。這兩個函式一旦遇到有 Reserved Memory Region 的 DMAR 表，就會出現程式錯誤的 BUG，導致驅動發生問題，即使修改過的 DMAR 表（拿掉 Reserved Memory Region 區段）也一樣，只有在原生 DMAR 表中沒有 Reserved Memory Region 的主板則才不會發生錯誤。（來源1、來源2）
所幸這個問題已經有解，方法很簡單，擇一即可：
4.1 解法（一）：
改變上述的觸發條件之一即可，例如關閉 iGPU 內顯、或不使用 AppleVTD，或系統記憶體不超過 16GB，甚至不要升級到 Ventura 13.3+。如果這些條件都必須滿足且無法避開，則只能採取 4.2 解法（二）。
4.2 解法（二）：
其原理是遮蔽 AppleVTD::addMemoryRange 發生的錯誤，讓 IOPCIFamily 得以持續運作，已經整合在 OpenCore 0.9.2+ 內。作法如下：
- OpenCore 升級到 0.9.2+ 以上
- Kernel -> Quirks -> DisableIoMapperMapping 設定為 True。（其他設定維持本文 3.2.2 啟用 AppleVTD 的全部作法）
解法就這麼簡單。遇到這問題時 TNND 足足卡了近兩天的時間，總算是解決了。
五、macOS 環境下的 RGB 燈光效果
Z490 VISION G 主機板支援時下最中二....阿不是，時下最流行的 RGB 燈光效果。為了配合實現主機板的 RGB 效果，以及其它的因素，所以又花了好幾天的時間，逐一物色新的電腦機殼，開出的條件限制如下：
- ATX，支援主板 RGB 燈光控制
- 具備對外 5.25 吋（光碟機） 與 3.5 吋裝置（多功能讀卡機）
- 背板可藏線、主板背板開洞：用於方便更換主機板和 CPU 散熱器。
- 預留水冷排安裝空間
所有的電腦配件中，機殼是品牌及種類最多，也是最難選的一環。然而找遍所有 DIY 電腦賣場電商，竟沒有任何一款符合要求，原因是較新的電腦機殼才有支援主板 RGB 控制，並且大多已取消 5.25 和 3.5 對外槽位。只好退而求其次，刪除 3.5 吋的限制。
支援 5.25 光碟，又有 RGB 燈控、預留水冷排位置的機殼，找遍各大賣場，只剩寥寥幾款：
- 旋剛：光影者 RGB（1,690 元）、夜鯊 Night Shark RGB（2,490 元）
- 安鈦克：DP502 FLUX（2,390 元）
最後反覆評估之後，我選擇安鈦克 DP502 FLUX，原因是外型比較優雅 不帶中二感，內建的集線 HUB 不僅支援 RGB ，還將風扇電源集中管理，所以機殼上的 RGB 燈條 + 四顆風扇，只需一組 SATA電源+ 1 個主板風扇插座 + 1 個 ARGB 3pin 插座，這個 HUB 的集線設計比旋剛略為勝出。
DP502 機殼內建三十多種燈光效果，當主機板不支援 RGB 時也可透過機殼的按鈕切換燈號效果，並且可以透過一條 3 pin 與支援的主板進行燈光連動。至於 Z490 VISION G 主機板 IO 埠旁邊的馬甲有一組 RGB 燈光，以及主板內建兩組標準 5050 RGB LED 燈條插座（12V 4pin），和兩組 5050 可編程 LED 燈條插座（5V 3pin）。在官網的產品頁上可以模擬控制燈號的效果。
但問題是，主機板的 RGB 設定工具 RGB Fusion 理所當然只支援 Windows 平台（畢竟 Mac 電腦並沒有 RGB 配備），究竟～要怎麼在 macOS 環境下控制主板 RGB 呢？讓我們繼續看下去...
跨平台 RGB 燈控工具：liquidctl
有一套名為 liquidctl 的工具，用 Python 寫的，可以跨平台運行。雖然和技嘉原廠的 RGB Fusion 相比少了很多種花樣，不過沒魚蝦也好，至少提供一個 macOS 環境控制 RGB 燈號的機會。
依照 liquidctl 官網說明，在安裝完 Python3 之後，透過 pip3 指令安裝 liquidctl 即可：（按：macOS 安裝 Python3 的方式，可參考「使用 PyQt 開發樹莓派的 UI 介面程式」內文下方，「macOS 開發 PyQt5」項目中安裝 Python3 的說明）
$ pip3 install liquidctl
然後，執行
$ liquidctl list
若一切都很順利的話，會出現「Device #0: Gigabyte RGB Fusion 2.0 5702 Controller」。
不過，macOS 的用戶通常並不會這麼順利。執行 liquidctl list 之後，會先遇到以下兩種結果之一：
- 出現「usb.core.NoBackendError: No backend available 」錯誤
- 什麼都沒有
解決的方式如下：
1. 出現「usb.core.NoBackendError: No backend available 」：
從這個訊息可以推測，主板 RGB 燈號使用的是 USB 介面進行溝通。而 Python 讀寫 USB 資料時需要 libusb 套件。這個錯誤訊息通常表示 macOS 系統內少了 libusb 套件。
一般來說，安裝 python3 套件也是用 pip3 指令。不過，BUT，巴特，macOS 環境下 pip3 安裝 libusb 並不能解決這個問題，依然會出現錯誤。這問題又卡了我好一段時間，直到看到這篇文章，才知道我又踩到坑了。透過 pip3 安裝的 libusb ，在 macOS 平台竟然是空殼檔案（windows / linux 正常），得改用 brew 安裝才行：
$ brew install libusb libusb-compat
這坑踩得真 TM 冤枉...
（註：若出現「brew: command not found 」，則 macOS 電腦內必須事先安裝 Homebrew）。
2. 什麼都沒有
在 macOS 執行 liquidctl list 如果發現什麼都沒有的話，通常就兩種可能：
- 主板本身硬體不支援
- 因 USB Port limit 限制，未把 RGB 燈控的 USB 納入。
第一種就放棄了。如果是第二種，可以用 Hackintool 工具查看，燈控的 USB 埠是否有無出現，以技嘉的主機板來說，通常會顯示「ITE Device」。
若確定主板有支援 RGB 燈控、但 USB Ports 沒有出現相關項目，八九不離十就是被 macOS 的 USB Ports Limit 規範限制了，只好重做一次 USB Ports Mapping （本站教學），把這個 USB 埠放進來。
使用 liquidctl 控制主板燈號
這邊就很簡單了。參考 liquidctl 官網對 Gigabyte RGB Fusion 2.0 的網頁說明，指令如下
$ liquidctl set <channel> color <mode> <color> <--speed xxxx>
- channel：共有 9 個，分別是 led1~led8 共 8 個，以及 sync 讓這 8 個 led 一起同步運作的 channel。
- mode ：顯示模式。有 off, fixed, pulse，flash，double-flash，color-cycle 這幾種。
- color：顏色，長度為 6 的字串，即 rrggbb ，每個顏色為長度2的 16 進位值，例如 ff0000 即全紅色，ffffff 即全白色，198964 為近期很熱門的「土銀綠」。當 mode 為 off 跟 color-cycle 時，不需要帶入顏色參數。
- --speed xxxx：速度，有 slowest, slower, normal (預設值), faster, fastest 或 ludicrous 這幾種。空白則為預設。要注意的是只適用於顏色會變換的 mode。
範例：
$ liquidctl set sync color off
$ liquidctl set led1 color fixed 350017
$ liquidctl set led2 color pulse ff2608
$ liquidctl set led3 color flash 350017
$ liquidctl set led4 color double-flash 350017
$ liquidctl set led5 color color-cycle --speed slower
channel 的說明：
led1: the LED next to the IO panel（主機板後端 IO 埠馬甲區）
led2: one of two 12V RGB headers（主機板第一個 12V RGB 端口）
led3: the LED on the PCH chip ("Designare" on Vision D)（主機板南僑 PCH 馬甲區。 Z490 VISION G 閹割而不具備）
led4: an array of LEDs behind the PCI slots on back side of motherboard;（主機板 PCI 插槽，Z490 VISION G 閹割而不具備）
led5: second 12V RGB header（主機板第二個 12V RGB 端口）
led6: one of two 5V addressable RGB headers（主機板第一個 5V ARGB 端口）
led7: second 5V addressable RGB header（主機板第二個 5V ARGB 端口）
led8: not in use（沒用到）
不過 Z490 VISION G 已經被閹割幾個，只剩下 led1、led2、led5、led6、led7。從 DP502 的 3pin ARGB 接線可接在 led6 （即 Z490 VISON G 主機板 D_LED1 插座 ）或 led7（即 Z490 VISION G 主機板 D_LED2 插座。）
而 liquidctl 也支援 python3 程式引用呼叫， Z490 VISION G 能運作的程式格式如下：
from liquidctl import find_liquidctl_devices
first = True
# find all connected and supported devices
devices = find_liquidctl_devices()
for dev in devices:
# connect to the device (here a context manager is used, but the
# connection can also be manually managed)
with dev.connect():
print(f'{dev.description} at {dev.bus}:{dev.address}:')
# devices should be initialized after every boot (here we assume
# this has not been done before)
init_status = dev.initialize()
# print all data returned by initialize()
if init_status:
for key, value, unit in init_status:
print(f'{key}: {value} {unit}')
# get regular status information from the device
status = dev.get_status()
# print all data returned by get_status()
for key, value, unit in status:
print(f'{key}: {value} {unit}')
# for a particular device, set the pump LEDs to red
if 'RGB Fusion' in dev.description:
print('setting pump to radical red')
radical_red = [0xff, 0x35, 0x5e]
dev.set_color(channel='sync', mode='off', colors=[radical_red])
# the context manager took care of automatically calling disconnect();
# when manually managing the connection, disconnect() must be called at
# some point even if an exception is raised
if first:
first = False
print() # add a blank line between each device
換句話說，可以用 python 語言自行撰寫控制主版燈號的程式，這麼一來可玩的花樣就很多了，例如可以用手機遙控，或是使用 Hey Siri 來控制黑蘋果的 RGB 燈號....等等等等。
六、停用黑蘋果不支援的 NVMe SSD (2024.04.15 補充)
幾個月前在網路上用便宜的價格買了兩張 2230 SSD，分別是 KIOXIA（鎧俠）BG5 和 Sk hynix BC711 都是 256GB，其中 BG5 改裝成 CFexpress 卡給 Canon R5 使用，而 BC711 改成 CFexpress 仍不被 Canon R5 支援（亮紅燈不開機，需特定 C20 韌體）所以就閒置了。後來接觸 AIGC 繪圖需要大空間存放 Stable Diffusion 模型，就把 BC711 裝到二號機主板的 M.2 SSD 插槽 ，就這樣用了一段時間。某次要切換到 macOS 做事，才發現 macOS 開機出現 panic 無法進入系統，錯誤訊息顯示 nvme command timeout 和 com.apple.iokit.IONVMeFamily 錯誤，上網查了一下，才想起 macOS 僅支援有限款式 NVMe SSD ，這篇文章也明確指出 BC711 並不在 macOS 支援之列，不過文章中提供的解法對二號機無效（原因是文章內提到的 SSDT-NVME-DISABLE.aml 連結到不同檔案導致失效），然而二號機主板 UEFI BIOS 也沒提供關閉指定 NVMe SSD 的功能，這意味著如果要來回交互使用 Windows 和 macOS ，就得反覆拆裝 BC711 NVMe SSD。
後來覺得這樣拆裝下去也不是辦法，只好再求助網路大神，最後終於成功解決這個問題。原理是透過修改 ACPI 表實現停用特定裝置。由於裝了BC711 之後 macOS 是不可開機的情況，所以接下來的操作大都是在 Windows 環境下。理論上這個問題會出現在任何一台黑蘋果，不過既然是黑蘋果二號機上發生的，所以把解法寫在這篇如下：
1. 進 BIOS 找出不支援 NVMe SSD 的位置資訊。
BC711 安裝在主機板的 M2A_SB 插槽位置（離 CPU 較遠的第二個 M.2 插槽），在 BIOS 內看到的是匯流排 8 號的位置，Vendor ID 為 0x1C5C，Device ID 為 0x174A。
2. Windows 環境下找出該裝置對應的 ACPI 路徑。
根據 BIOS 顯示的內容，於 Windows 的裝置管理員中查找「標準 NVM Express 控制器」。二號機裝了 2 張 NVMe SSD，所以有兩個控制器，需查閱裝置內容才能判斷 BC711 是掛在哪個控制器上。
裝置主頁會顯示匯流排編號，詳細資料 - 相容性識別碼顯示裝置的 Vendor ID 與 Device ID。比對驗明正身之後，確認是第二個 「標準 NVM Express 控制器」無誤。
3. 驗明正身之後，紀錄 ACPI 資訊。有兩筆要記錄下來
(1) 屬性至「BIOS 裝置名稱」，紀錄反斜線之後的字串。
(2) 切換到屬性「位置路徑」，依照下圖的指示，記下擷取之後的字串值。
以二號機為例，意即 BIOS 裝置名稱取得「_SB.PCI0.RP09.PXSX」 ，位置路徑取得「_SB_.PCI0.RP09.PXSX」，兩者僅差了 SB 右邊一個底線字元「_」。
4. 使用筆記本或是 Xiasl 工具（下載），新增 .dsl 文件（假設名稱為 SSDT-NVME-DISABLE.dsl），將以下內容貼上後，依照上面提到的字串值修改藍底白字內容 ：
DefinitionBlock ("", "SSDT", 2, "hack", "spoof", 0x00000000)
{
External (_SB_.PCI0.RP09.PXSX, DeviceObj) //位置路徑
Method (_SB.PCI0.RP09.PXSX._DSM, 4, NotSerialized) // BIOS 裝置名稱加上 ._DSM
{
If ((!Arg2 || (_OSI ("Darwin") == Zero)))
{
Return (Buffer (One)
{
0x03 // .
})
}
Return (Package (0x0A)
{
"name",
Buffer (0x09)
{
"#bc711"
},
"IOName",
"#bc711",
"class-code",
Buffer (0x04)
{
0xFF, 0xFF, 0xFF, 0xFF // ....
},
"vendor-id",
Buffer (0x04)
{
0x5C, 0x1C, 0x00, 0x00 // BC711 Vendor ID
},
"device-id",
Buffer (0x04)
{
0x4A, 0x17, 0x00, 0x00 // BC711 Device ID
}
})
}
}
要注意的是 Method 右邊藍底白字填入 BIOS 裝置名稱取得的字串值，一定要加上「._DSM」。上面綠底白字的部分，一律填入 0xFF 即可，不過像我一樣龜毛的也可以填入 NVMe 裝置的 Vendor ID 與 Device ID。填入時要順序要反過來，例如 0x1C5C 填入時是 0x5C, 0x1C。
填完之後，使用 Xiasl 開啟 .dsl 文件並編譯，會在 .dsl 同一個目錄下自動產生相同檔名的 .aml 檔案（例如 SSDT-NVME-DISABLE.aml）。
最後，把 .aml 檔案放到 EFI/OC/ACPI/patched/ 底下，並且在 EFI/OC/config.plist 內加入啟用即可。
成功的話，macOS 就可以在未移除不支援 NVMe SSD 的情況下開機，再也不用為了切換使用 Windows / macOS 而拆裝 NVMe SSD。若是在 .aml 填入正確的 Vendor ID 和 Device ID 時，macOS 環境下 PCI 裝置樹也能識別出來，只是沒有作用罷了。
留言列表
{{ article.title }}
IoT 物聯網 (2)