config.plistに「XHCIをXHCに変更」とか「SAT0をSATAに変更」などのパッチを書いている方も多いと思います。これは一体何なのか考えてみました。
Table of Contents
DSDTのPatches
USBを設定するスクリプトであるUSBMapを試していたところ(そのうち紹介できれば良いと思い試行錯誤しています)、次のようなメッセージが出ました。
「あなたのマシンにはEC0ってのがあるけどこれはECに変えた方が良いと思う。だからESPにあるconfig.plistを書き換えてあげましょうか?」
よくわからないのでとりあえず辞退させていただきました。これは、config.plistのDSDTの中にPachesというkeyを作って、そのarrayとして下のようなdictを追加してあげようかという提案です。
<key>Patches</key> <array> <dict> <key>Comment</key> <string>change EC0 to EC</string> <key>Disabled</key> <false/> <key>Find</key> <data> RUMwXw== </data> <key>Replace</key> <data> RUNfXw== </data> </dict> </array>
config.plistのサンプルには、このようなPatchesが書かれていることがあります。書かれているBase64の内容は、base64コマンドで確認できます。
echo RUMwXw== | base64 -D EC0_ echo RUNfXw== | base64 -D EC__
それぞれの結果はEC0_とEC__になります。コメント通り、EC0をECに変更しようとするパッチです。
この他にconfig.plist設定例でしばしば紹介される典型的な名称変更パッチには以下のようなものがあります。(変更前の名前)—>(変更後の名前)の形式で記載しました。
- EC0 —> EC
- XHCI —> XHC
- XHC1 —> XHC
- EHC1 —> EH01
- EHC2 —> EH02
- SAT0 —> SATA
Clover Configurator.appでもパッチを簡単に選べる機能があります。ACPI > DSDTを選択すると、パッチを選ぶメニューが出てきます。ここにはなぜかXHCに関するメニュー項目はありませんが、他にも多数のパッチ候補が表示されています。
この中からいくつかのパッチをよくわからずとりあえずconfig.plistに書いている方も多いと思います。私もよくわかっていませんでした。
パッチの目的
RehabManさんの解説などを読んで私なりに理解した理由は次のようなものです。間違っているかもしれません。私の理解が正しいのかどうか、皆さんにお聞きしたと思い、この記事を書きました。詳しい方がいらしたら、ぜひコメントでお知らせいただけるとありがたいです。適宜修正していきます。
DSDTの項目名変更
これらのパッチは、config.plistのコメントから類推できるように、DSDTの項目名を変更する目的で使用されています。
DSDTは電源管理のための情報で、マザーボードに搭載されているハードウェアの状況が記載されています。例えばどういう名前のUSBやSATAが何本あってどう接続されているかなどが書いてあるようです。マザーボードのBIOS(ファームウェア)がこの情報を持っていて、OSに提供します。WindowsやLinuxなどのOSはこの情報を参考にしてハードウェアにアクセスします。ファームウェアが提供するDSDT情報と、これを利用するOSの関係は、同じようにEFIに基づいて設計されているMacでも同様です。Macのファームウェアがハードウェア構成をDSDTを通して提供し、macOSはそれに従ってハードウェアを制御します。
DSDTが提供する名称は、マザーボードによって違います。それがMacと同じ名前であることもありますし、違う名前のこともあります。例えば、iMac19,2のUSBコントローラはXHCIという名前ですが(最近のMac製品ならほぼ同じでXHCIです)、手元のZ390マザーボードはXHCです。
自作で使うマザーボードでの名前を、本物のMacで採用されている名前に合わせたり、あえて名前を変えたりしているのがconfig.plistで使われるパッチの役割です。上で紹介した例で、Macで採用されている名前を太字体にした対応表が以下です。
- EC0 —> EC
- XHCI —> XHC
- XHC1 —> XHC
- EHC1 —> EH01
- EHC2 —> EH02
- SAT0 —> SATA
EC0とSAT0に対するパッチは、Macで使われる名前に合わせるためのパッチで、残りのXHCI, XHC1, EHC1, EHC2へのパッチは、これとは逆にMacで使われている名前と違う名前にするためのパッチです。同じ改名パッチではありますが、動作が全く逆ですので、そのパッチを当てる動機も違います。
実機のMacに名前を合わせるパッチ
上記の例ですと以下の2つのパッチは、ATXマザーボードが提供するDSDTの項目名をMacで使われる名前に変更するパッチです。本物のMacにより近い設定にしたいという意図は理解できると思います。
- EC0 —> EC
- SAT0 —> SATA
どうやら10.11以前の古いmacOSは、DSDTの情報をあまり活用していなかったようです。どんなハードウェアが使われるか予想できないWindowsと違って、自社のハードウェアでしか動かさないOSなので、ハードウェア仕様をDSDTから得る必要がなかったのかもしれません。機種IDさえわかればハードウェアの詳細情報はわかってしまいますから。なのでこのようなパッチが必要だったようです。しかし、現在のmacOSではDSDT情報をちゃんと利用するようになったためか、この種類のパッチを当てなくても、大抵の場合、問題は発生しないようです。
例えば、手元のASUS Z390マザーボードでIORegistryExplorer.appを起動して検索したところ、SAT0という項目がありました。その一方でSATAという項目はありませんでした。
Clover Configurator.appのメニューには、SAT0 —> SATAというパッチ候補があります。これを選ぶと以下のパッチがconfig.plistに書き込まれるようです。
<key>Patches</key> <array> <dict> <key>Comment</key> <string>change SAT0 to SATA</string> <key>Disabled</key> <false/> <key>Find</key> <data> U0FUMA== </data> <key>Replace</key> <data> U0FUQQ== </data> </dict> </array>
これも動かしてみたところ、SAT0からSATAに正しく名称変更されました。でもSATA関連は変更前でも変更後でも全く問題なく稼働しています。
冒頭ではEC0をECに変えるようにと指示された話を紹介しました。Hackinotosh用のツールでは、実機の名前になっていることを前提にして動いていることもあるのかもしれません。でも,問題が発生しなければ当てなくても良いパッチだと思います。
実機のMacの名前を避けるパッチ
以下のパッチはどれも、実機で使われるUSBコントローラの名前と違う名前に設定するためのパッチです。
- XHCI —> XHC
- XHC1 —> XHC
- EHC1 —> EH01
- EHC2 —> EH02
ATXマザーボードと実機の名前が一致しているのに、わざわざ別名にするパッチなので、なぜ必要なのか理解に苦しむと思います。その経緯は以下のようです。
上で、macOSも10.11からDSDTに書かれた情報を利用するようになったらしいと書きました。ところが一部のMacハードウェアは、あろうことかUSBに関する正しいDSDT情報を持っていなかったようです。DSDT情報をOSで利用する予定がなかったのでいい加減に記述してあったのかもしれません。本来なら正しいDSDTを提供するようにファームウェアアップデートするべきですが、それは大変なのでOS側で対応したそうです。つまり、DSDTのUSB情報が間違っているMacに対しては、macOSで用意したUSB構成情報を使用することになりました。全てのMac機種のDSDT情報を無視しているわけではなく、DSDT情報が怪しいとわかっているMac機種に関してはOSで用意した値を使っているようです。
なのでATXマザーボードが持っているUSBコントローラに、たまたまMac実機と同じ名前がついていると、DSDTが提供する情報を使わずに、macOSが用意したMac実機の情報を使ってしまう可能性があります。それを避けるために、Mac実機と違う名前に改名するのがこれらのパッチです。
このパッチも、いろいろな理由で不要な場合が多いです。
まずは、もともとDSDTのUSBコントローラ名がMacの実機と違う名前だったら名称変更は不要です。例えば手元のASUS Z390マザーボード(機種IDはiMac19,1)でIORegistryExplorer.appを起動して、XHCを検索してみたところ、名称変更パッチを当てなくても、XHCという名前で存在していました。名称変更パッチの変更対象名として使われるXHCIとかXHC1という名前の項目はそもそも存在していませんでした。このような場合は、名称変更パッチは不要と考えて良いと思います。
次に、macOSがDSDTを信用してくれる機種IDなら名称変更は不要と考えられます。例えばこちらはNUCで作ったHackintoshの例です。機種IDはMacBookAir5,1です。IORegistryExplorer.appを起動して確認すると、名称変更対象に上がっているEHC1とEHC2があるようです。その一方でEH01やEH02は見つかりません。でもmacOSは、この機種のDSDTは正しいと認識しているようで、このままでも全く問題なくUSBが認識されています。NUCはUSBの数が少ないので15個制限も問題無いようです。
ちなみに、このNUCで、
- EHC1 —> EH01
- EHC2 —> EH02
の名称変更パッチを当ててみるとちゃんと変更されることが確認できました。config.plistに追加したパッチは、以下のものです。
<key>Patches</key> <array> <dict> <key>Comment</key> <string>change EHC1 to EH01</string> <key>Disabled</key> <false/> <key>Find</key> <data> RUhDMQ== </data> <key>Replace</key> <data> RUgwMQ== </data> </dict> <dict> <key>Comment</key> <string>change EHC2 to EH02</string> <key>Disabled</key> <false/> <key>Find</key> <data> RUhDMg== </data> <key>Replace</key> <data> RUgwMg== </data> </dict> </array>
この結果EH01とEH02がIORegistryExplorer.appのウィンドウに現れました。その一方で、EHC1とEHC2は無くなりました。名称変更のパッチが効いているようです。でもどちらの場合でも、USBは問題なく機能しました。
以上のように、Mac実機のDSDT項目名を避けるパッチを当てることで、DSDTのUSB情報がありのままにmacOSに伝わり、Hackintoshの動作が安定する可能性があります。ただし最近の機種IDを設定していれば、DSDTの情報がそのまま正しくmacOSで使われるのでパッチは不要な気がします。古い機種IDであっても、MojaveのAPFS起動に対応した時にファームウェアアップデートされたので、信用できるDSDTに置き換わっている可能性もあります。なのでmacOSがDSDTを無視する必要性が少なくなったはずです。そのような状況を考えると、実機の名前を避けるパッチも、もはやそれほど必要でない気もしています。
まとめ
ということで、config.plistのDSDT Patchesの機能を考察しました。半分推測なので、間違っているかもしれません。詳しい方いらしたら、コメントで教えていただければ助かります。
まとめると、DSDT Patchesは、DSDTの項目名を変更するパッチでした。改名結果はIORegistryExplorer.appで確認できました。改名するとDSDT情報が正しくmacOSに伝わり、Hackintoshの動作が安定する可能性があります。ただし最近では、パッチの必要性が下がっている気がします。使用しているマザーボードのDSDT項目が、パッチ対象の名前かどうかを調べておいて、パッチ対象の名称であった場合は、何か問題があった時に名称変更のパッチを試すのが良いと思います。
記事内容とは関係ないですが・・・。
NativeDisplayBrightnessを使用すると、Hackintoshでもディスプレイの明るさをF1, F2キーで変更することが出来ますが、これはpatchやkextで対応できるものなのでしょうか?
NativeDisplayBrightnessはDDC/CI対応ディスプレイのみ対応(現在発売中のディスプレイは、ほぼ対応しています)ということですが、みなさんどうしてるのかな、と思いつつ・・・。
日本語のサイトで、Hackintoshと関連付けて紹介しているサイトがなかったため、一応共有させていただきます。
https://github.com/Bensge/NativeDisplayBrightness
なるほどこんなものがあるのですね知りませんでした。
早速入れてみたところ、i5 9400F+Z390+Vega64 MacOS 10.14.6/iMac 19.2で全く問題なく動きました。
PatchやKext類は特に意識しておりませんが、人によって環境によって動かないってこともあるのでしょうね。
ちなみにディスプレイはEIZO FS2333 HDMI接続です。
NativeDisplayBrightnessはログイン時に起動するタイプ(ログイン項目)のようですので、ACPIパッチやkextで対応する仕事より上位レベルの仕事をしているような気がします。
NativeDisplayBrightnessはネイティブのキーイベントをオーバーライドできないため、明るさ調整のみStandard Function KeyとHardware (Special Features) Keyの設定とは逆になってしまいますね。
自分でコメントしておきながらなんですが、ネイティブのキーイベントが利用できるMonitorControlのほうが良さそうです。
https://github.com/the0neyouseek/MonitorControl
XHC,SATAのパッチを外してみましたが、確かに問題なく起動しますね。
XHCはGIGABYTEマザーでも元々の名前が合っていました。SAT0は出てきますが特に問題にはならないのでしょうかね。
これでまたConfig.plistがかなりシンプルになりそうですね。
現行のマザーボードは大体XHCでSAT0のようですね。
お疲れさまです。以下のことがあったので納得です。
Mojave環境を作っているときに、こんな事がありました。
TECH HOWDYだったと思いますが、以前Mojave(おそらくベータ)のUSB用のEFI一式のダウンロードがあって動いたので、使ってみてたことがあります。plistを見たのですがDSDTのパッチがまったくないのでした。
リンクは探したらありました。
https://techhowdy.com/process-to-install-hackintosh-macos-mojave/
(実はここで、OsxAptioFix2Drv-64.efiのみが、EmuVariableUefi-64.efiを使わないで電源周りがうまくいくとうことで、ちょっと悩んだんです。)
その他のサイトのMojave用EFIのconfig.plistは、DSDTパッチ周りがかなりゴテゴテしてるのが多いように思います。色々なチップセット(またはメーカー)対応のためなんでしょうか。ちょっと不思議に思います。
以前こちらでも紹介されたー
corpnewtさんのバニラガイド~Coffee Lake用config.plist
https://bootmacos.com/entry/2019/01/13/005222
でも、「CloverのACPIデフォルト設定は、多すぎで、やりすぎなところがあります。そのために問題を引き起こす可能性があります。そこで、できるだけ単純に書き直します。」とあり、
XHC1とSAT0とXHCIのみになっていたことも、納得がいきました。
ありがとうございます。