現行の300シリーズチップセットマザーボードでは、macOSがNVRAMにアクセスできない問題があります。NVRAMが使えないと設定が保存されないだけでなく、シャットダウンやスリープの動作にも支障が出ます。そのためにEmuVariableUefi.efiを使って、NVRAMをソフトウェアエミュレーションする必要がありました。NVRAM問題を、エミュレーションを使わずに、根本的に解決するSSDTがRedditで紹介されていました。
このSSDT-PMC.amlをEFI/CLOVER/ACPI/patchedに入れてみました。その結果、ASUS ROG MAXIMUS XI HERO (Z390)マザーボードのNVRAMが使えるようになりました。MSI B360M Mortar Titaniumでも試しましたが、同じ方法でNVRAMが使えるようになりました。
EmuVariableUefi.efiのエミュレーションは優秀で、ちゃんと動作して何の問題もありませんでした。でも、本来のNVRAMが使えると気分が良いです。たとえば、SSDT-PMC.amlを使った結果、以下のnvramコマンド
% sudo nvram hoge=test
で試験的に設定したパラメータが、システム終了・再起動後に確認すると、
% nvram -p | grep hoge hoge test
のように、電源を切っても保存されていた様子が確認できました。EmuVariableUefi.efiを使って動かしていた時には、保存されませんでした。これができなくてもmacOSの動作には関係ない様子ですが、何らかの機能で互換性が上がったかもしれないです。
追記:コメントで教えてもらいましたが、NVRAMが動くようになると、config.plistのBootのセクションで起動ドライブを設定するときの、LastBootedVolumeの設定が動くようになります。
以下はReddit投稿の抄訳です。
OpenCoreパッケージの最新更新では、SSDT-PMC.dslという新しいSSDTが追加されました。このSSDTは、B360、B365、H310、H370、Z390用のNVRAMを復活させてくれます。
そもそもなぜ、300シリーズマザーボードのNVRAMは壊れているのでしょうか?とても簡単です。ACPIの中で、MMIOとしてファームウェアチップを宣言することを、Intelが「忘れた」のです。そのため、XNUはUEFIメモリマップで宣言されたMMIO領域を無視します。そしてマップされていないページアクセスによってNVRAM SMMページフォルトが発生してしまうのです。
このSSDTの使い方
使い方は簡単で、設定不要で入れるだけです。OpenCoreに縛られていないため、Cloverユーザーも使うことができます。ごのDSDTにはLPCBが必要ですが、Z390ではこれが非常に一般的であることに注意してください。PCI0.LPCBを検索すれば確認できます。(訳注:この意味がよく理解できないのですが、おそらくDSDTのDevice (PCI0)の項目の中に、Device (LPCB)の定義がされていることが必要という意味だと思います。MaciASLを起動するとデフォルトのDSDTが開くので確認できます。)
(訳注:このあと、macOS, Windows, Linuxでdslのコンパイル方法が説明されています。MaciASLの使い方についてはこちらをご覧ください。)
ファイルがコンパイルされると、SSDT-PMC.amlが得られます。コンパイルされたバージョンであるため、拡張子は重要です。dslは単なるソースコードです。SSDTを作成したら、これをEFI/CLOVER/ACPI/patchedまたはEFI/OC/ACPI (OpenCoreを実行している場合は、忘れずに設定に追加してください。) に入れます。コンパイルが面倒と思う人のために、ここにコンパイル済みのSSDT-PMC.amlを配布しておきます。
NVRAMエミュレーションを削除する方法
以下を削除します。CloverでRCスクリプトをインストールしている場合は色々削除します。(訳注:デフォルトではRCスクリプトをインストールしない設定なので、EmuVariableUefiの削除だけで良いと思います)SIPをオフにしてR/Wでマウントする必要があるかもしれません。
- /Volumes/EFI/EFI/CLOVER/drivers/UEFI/EmuVariableUefi-64.efi
- /Volumes/EFI/nvram.plist
- /etc/rc.clover.lib
- /etc/rc.boot.d/10.save_and_rotate_boot_log.local
- /etc/rc.boot.d/20.mount_ESP.local
- /etc/rc.boot.d/70.disable_sleep_proxy_client.local.disabled
- /etc/rc.shutdown.d/80.save_nvram_plist.local
OpenCoreユーザーの場合は、設定で次の項目を無効にするだけです。
- Booter->DisableVariableWrite->False
- NVRAM->LegacyEnable->False
そしてEFIのルートにあるnvram.plistを削除するのを忘れないでください。
NVRAMの動作をテストする方法
ターミナルを開き、一度に1行ずつペーストします。(訳注:sudo nvram -cは実行しなくても良いと思いました。適当なエントリーに値を設定するだけなら、SIPを無効にする必要はありませんでした。)
sudo -s sudo nvram -c sudo nvram myvar=test exit
再起動して次のコマンドを実行します。
nvram -p | grep -i myvar
何も返されない場合は、NVRAMが動作していません。myvar testを含む行が返された場合、NVRAMは動作しています。
Note: nvram-cを使用するにはSIPがオフになっている必要があります。もしくはブートメニューでNVRAMを消去します。Cloverの場合は、F11キーを押します。OpenCoreの場合は、 CleanNvramを選択します。Misc->Security->AllowNvramReset->YESに設定する必要もあります。
Z390,B365どちらも動きました。LastBootedVolumeがちゃんと使えるというだけでとても助かります。
LastBootedVolumeが動かないのもNVRAMの関係だったんですか。諦めていました。情報ありがとうございます。NVRAMが動くと色々ありがたいですね。
Z390マザーのマシンで数日使ってますが、EmuVariableUefi.efi使ってた時はスリープしようとすると再起動してしまうことが時々あったのが、NVRAMを使うようになってからは再起動することがなくなりました。これも効果の一つでしょうね。
BootMacOSさん、
ども、EmuVariableUefi.efを使ってたときは、実用上あんまりその問題に苦労させられるとまではいかなかったんでそのままEmuVariableUefi.efのお世話になっていたんですが、Z390ではZ370系と違って定義そのものが抜けていたんですね。。。
https://khronokernel-2.gitbook.io/opencore-vanilla-desktop-guide/intel-config.plist/coffee-lake
So true 300 series motherboards(non-Z370) don’t declare the FW chip as MMIO in ACPI and so XNU ignores the MMIO region declared by the UEFI memory map.
ただ、SSDT-PMC.amlを入れてみて、それなりに動いてるんですけど、CFG lock (MSR 0xe2)のロックを外すのも同時にしておいた方が、よろしいっぽいことを言ってる方がいるようなので、わたしはGigabyteのZ390マザーボード使ってますが、Asusと違ってBiosに設定がないので、手作業でCFG lockを外して運用してみます。CFG Lockを外さなければいけない理由は、ちょっと調べたけどいまいちよくわかりませんでした・・・
https://www.imacpc.net/wp-content/uploads/2019/12/CFG-Lock.jpg
そのCFG Lockの状態はHackintoolで確認できるようです。
お疲れ様です。
ASUS PRIME H370-A/CSM x2 で、HighSierra,Mojave,Catalina(うちMojave,CatalinaはOC併用起動も含む)、及びそれぞれのインストーラUSBメモリで、うまく行きました。
H370では、Emu時にも問題はなかったんですが、スッキリしましたね。
こんにちは
bootmacos様
以前はお世話になりました。
動作報告です。
私の環境ではWindows10とのデュアルブートにしておりますが、
直接NVRAMを使用すると、Mac,Windows共に起動が不安定になります。
例えば
1:BIOSでmacOSドライブを優先起動に設定しておりますが、一度でもWindowsを起動させると
次回起動時又は再起動時にどちらのOSが起動するかランダムになってしまいます。
2:そのうちMacもWindowsもエラーで起動できなくなってしまいます。
BIOSをクリアーしてしまえば元に戻ります。
起動してしまえば両OSとも動作は安定しております。
もう少し様子を見てみます。
ども、皆さん
私の環境でもNative NVRAMが動き出して、10.13.5の新規インルトールしたり、アップデートの再起動後の挙動が変わりました。
EFIのboot entryに以下の2個が残ってたりするんで、これは本物のNVRAMが動いてることの副作用?と思ってます。これは良いことなんでしょうけど。。。
○追加されてた1個目:Firmwareのアップデート関連のブートエントリー
Description:Mac OS X
GPT partition GUID:{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
Partition number:1
Partition starting sector:xx
Partition ending sector:xxxxxx
File path:\EFI\APPLE\UPDATERS\MULTIUPDATER\MultiUpdater.efi
○追加されてた2個目 :APFSのコンテナ全部を示すGUIDでMacOSの正規のブートエントリー
Description:Mac OS X
GPT partition GUID:{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
Partition number:5
Partition starting sector:xxxxxxxxxx
Partition ending sector:xxxxxxxxxx
File path:\D3F19C3A-C4EF-4611-AA30-8F164E45526D\System\Library\CoreServices\boot.efi
ウィンドウズのツールならEasyUEFI.Enterprise.3.0とかBOOTICEとか使うと、Boot entry見れますんで、なんか不明なブートエントリがないかとかちゃんと期待している優先順位になってるかどうか確かめないと、追加された2個は共にApple製のMacじゃないと正常に起動しないエントリーですから注意しないとだめですね。
Tutorial install dual window with BOOTICE_v1.3.3.2
https://www.youtube.com/watch?v=3_UeKgDw4Pc
EasyUEFI Enterprise 3 8 Release 1
https://www.youtube.com/watch?v=ilZD6q6vxk8
ちなみに、EFI>Apple>UPDATERS>DpUtil.efiとか残ってるはずです。。。
今後はNative NVRAMが正常に動き出した副作用で、アップデート時などで不要な純正のブートエントリーの削除もしくは起動の優先順位調整などを毎回チェックして修正しないといけなくなるという感じですね。。。
お疲れさまです。
なるほど、アップデート時の再起動の挙動が変わったのは、NVRAMの影響だったんですね、今項目をF3を押して点検してみましたがPrebootとRecoveryとBootなので、かけてるところはないようでした。
Cloverの設定は、Windowsを10秒後に自動ブートなので、アップデート等が終わったときには、きちんと戻っていました。
問題はないようです。
こんにちは
はじめまして
Hackintoshについて調べていたらこのサイトにいきつきました。
この記事とは関係の無い質問なのですが
HackintoshはBTOでも可能でしょうか?
やはり完全に自作が確実でしょうか?
お忙しいと思いますが宜しくお願い致します
BTOでもHackintosh可能だと思います。ただ、互換性のあるグラフィックスカード(AMD Radeonの一部)を選択できる必要があります。Nvidiaが人気なので、AMD選べるところは少ないです。また、Hackintoshした情報がネット上にあるマザーボードを選べると安心です。マザーボードを選べるBTOは少ないので、これも難しいかもしれません。パーツショップによっては、自由にパーツを選んで、手数料を払うと組み立て動作チェックしてくれるところもあります。そういうサービスを選んでも良いかと思います。
はじめました。色々読ませていただいて勉強しております。
下記環境で構築したのですが、本記事の通り、SSDT-PMC.amlをお借りして EFI/CLOVER/ACPI/patched に入れ、EmuVariableUefi も削除済みなんですが、nvram -p | grep -i myvar テストしてみても何も返されません。。
GIGABYTE Z390 + 9900KF
> このDSDTにはLPCBが必要ですが、Z390ではこれが非常に一般的であることに注意してください。PCI0.LPCBを検索すれば確認できます。
こちらの内容が分からなかったのですが、Z390は PCI0.LPCB というものを何かしなければならないのでしょうか?
お分かりの方がいらしたらよろしくお願い致します。
記事に追記しましたが、おそらくDSDTのDevice (PCI0)の項目の中に、Device (LPCB)の定義がされていることが必要という意味だと思います。MaciASLを起動するとデフォルトのDSDTが開くので、PCI0やLPCBで検索すると確認できます。このSSDT-PMC.amlがPCI0.LPCBを上書きしているので、元々それがない場合は機能しないという意味かなと思います。
ども、boot MacOSさん、
このHachintosh史上でエポックメイキングなNVRAMが発掘されて以来?NVRAMさまさまで、メリットを享受させていた日々なんですけど。。。
OpenCoreの実証検証を本格的にやりだしたら、NVRAMの副作用の衝撃波?が来てまして、やたらOpenCoreはNVRAMになんかごにょごにょしてるらしく(Macでは普通なんでしょうけどね?)、X230 mod BiosではC-MOSチェックサムエラー出まクリングで、RestNVRAM.efiをポチると、なんと!OpenCoreだけしか選べない専用モードに勝手に突入で、Boot設定がいじれなくなるなど、驚嘆の仕打ちをくらいました!ちょっと、あんた!NVRAMってBios Flashに書き込んでるやろ!やめてけれという感情が込み上げてきてます。w
で、昔はPCの世界観だとC-MOS RAMって、いわゆるRTCのメモリじゃねぇの?という先入観がある私なんですけど、結局のところNVRAMってBIOSのFlash EEPROMやろって思っても、それを説得する記事があんまり見つからなかったのが、この方がゴリ押しで調べてたので、ここに貼っておきます。。。今晩から私もぐっすり寝れそうです。。。w
「PCのUEFI BIOS NVRAM(設定情報)は一体どこに保存されているのか」についての調査メモ
http://dxr165.blog.fc2.com/blog-entry-405.html
”それでは、BIOS領域を見てみましょう!ありました。とうとう見つけましたNVRAM変数の一つである。Boot000がありました。これは、Windows Boot Managerです。 とうとうやりました。これで、今晩からぐっすり寝れます。”
お疲れ様です。
私も、マザーボードが5万円したころから、RTC領域(そのころはRTC自体がPCHなどに組み込まれてなくて、単独のICでした)は知っていたのですが、いわゆるBIOSの設定用の軽い容量だと思ってましたが、そういえばNV-RAMはバイト単位でなく容量を食うなあと思い、不思議でした。
リンク先を見て納得です!!
よく考えると、FlushRomがある中、電池で動かすべきは時計だけなんですよね。ハッキングでは、毎度お世話になりますC-MOSResetってもっと楽にならんのかしらねぇ^^;
おっと、匿名になりました、Mifjpnでした。(失礼しました)
OpenCoreのNVRAMへの影響はいろいろですね。Z390+OpenCoreのマシンではそれほどおかしな挙動はないのですが、Z490+OpenCoreの方では以下のような症状がよく出ます。Z490マザボは、まだ試行中で、設定を試行錯誤している状態なので、発生しやすいのだけかもしれません。が、OpenCoreがNVRAMのmacOS関連以外の部分を書き換えてしまっている気がしています。
(1) BIOSで何かの設定を変更する。再起動する。
(2) 起動しなくてBIOS設定画面に自動的に戻る(起動ドライブが見つからない様子)
(3) BIOS設定のBOOTドライブの項目を見ると全てdisabledになっている。
(4) このBIOS設定でOpenCoreの入っているドライブを起動用に指定しなおす。
(5) OpenCoreが起動してmacOSも起動するけど、ResetNVRAM.efiを起動しておかないと次の再起動で再び(2)に戻ってしまう。