ASUSのZ390マザーボードと9900Kの組み合わせでmacOSを動かしているマシンのブートローダーを、CloverからOpenCoreに移行しました。OpenCoreのconfig.plistはCloverに比べて複雑ですが、親切なページと便利なツールがあったので円滑に移行できました。
Table of Contents
OpenCoreのガイドとツール
Youtubeのビデオ
OpenCoreを使ってみた、という程度の記事を書きました。OpenCoreの基礎知識に関してはこちらをご覧ください。
この当時は、OpenCoreは、Cloverに比べてconfig.plistがややこしくて面倒という印象でした。設定項目が多いだけでなく、kextやSSDTやefiドライバーの一つ一つをconfig.plistで記述する必要がありました。ところが最近、YoutubeでOpenCoreの設定ビデオを見ていたら、ProperTreeという便利なツールと、手順を解説した親切なサイトが紹介されていました。ハードウェア構成も、手元のメインマシンに近いので、このビデオを参考に、OpenCoreへの移行を試すことにしました。
OpenCore設定解説ページ
こちらのページがとても親切です。デスクトップPCを対象にした解説ページです。
config.plistのそれぞれの設定項目を、詳細に網羅的に説明してくれているので、Cloverよりもわかりやすいかもしれません。歴史の長いCloverは、すでに使われない設定項目なども多く、説明を探して読んでも無意味だったりすることもあります。OpenCoreの設定は、Cloverに比べて簡単ではありませんが、最新の設定方法情報がCPU別に整理されているのは助かります。
ProperTree
このページでconfig.plist編集に使われているツールがProperTreeです。ProperTreeはPythonで書かれたクロスプラットフォームのプロパティ編集ソフトで、macOSやhackintoshを前提としたツールではありません。それに、RedditのHackintoshサブレディットで活躍されているcorpnewtさんが手を入れて、OpenCoreのための機能を追加されたようです。
今まで、config.plistはテキストエディタで編集する、というストイックな対応をしてきましたが、OpenCoreのconfig.plistは長くて複雑です。なので今後はこのツールを使っていきます。
ProperTreeを使うためには、上記のサイトからファイル一式をダウンロードします。ダウンロードしたファイルの中のProperTree.commandがメインのPythonプログラムです。ファインダーからこれを開くか、またはTerminalから起動します。ファインダーから開く場合は、Terminalのウィンドウが一つ開いて、GUIウィンドウが現れます。Autometor.appなどを使えばもっとアプリケーションっぽく見せられるとは思いますが、こういう形式も無骨で良いと思います。これでconfig.plistなどを開くと、XcodeのPlistエディタのように項目を開いたり閉じたりして閲覧し、内容を変更・追加・削除できます。
OpenCore Sanity Checker
OpenCoreのconfig.plistの正常性をチェックしてくれるページです。CPUとOpenCoreのバージョンを指定して、config.plistファイルをドラッグ&ドロップすると検査結果を表示します。この記事の最後で、作成したconfig.plistのチェックを行いました。
ハードウェア構成
この記事の対象としたマシンは、以下で紹介したZ390マザーボード＋9900Kです。
ハードウェアの構成を再掲すると、
- マザーボード：ASUS ROG MAXIMUS HERO WIFI (値上がりしてますね)
- CPU：Intel(R) Core(TM) i9-9900K CPU @ 4.00GHz
- グラフィックス：Radeon RX580, ブランドはSapphire
- WiFi/Bluetooth：Fenvi T919 (中身はBCM94360CD)
です。最新のmacOS, Clover, kext類の構成で、全く問題なく稼働しています。以下では、これをOpenCoreに移行します。
ファイルを入手してESPに置く
OpenCoreのダウンロード
以前の記事で紹介したように、Kext Updater.appを使いました。ダウンロードした中身には、Docs, EFI, Utilitiesの3個のディレクトリがありました。DocsとUtilitiesの中身は、そのうち少しずつ調べていきたいと思います。メインなのはEFIです。
OpenCoreの初期EFIをコピーする
ダウンロードしたOpenCoreファイルの中にあったEFIフォルダは、そのままESPにコピーして使います。またDocsの中にあるSample.plistを、config.plistと改名して使います。そのために、現在のマシンのESPをマウントします。そして現行のEFIを、例えばEFI_Cloverという名前に改名します。いきなり稼働中ドライブのESPを変更するのは危険かもしれませんので、他のドライブのESPやUSBメモリのESPで試しても良いかもしれません。起動に失敗したらUEFIシェルで名前を戻せば良いと思ったので、今回はメインドライブを直接変更してしまいます。
% sudo diskutil mount disk0s1 Password: Volume EFI on disk0s1 mounted % cd /Volumes/EFI % ls EFI % mv EFI EFI_Clover % ls EFI_Clover
ここに、ダウンロードしたOpenCoreのEFIをコピーします。また、Docsに入っていたSample.plistをconfig.plistに改名してEFIに入れます。
% cp -R ~/Desktop/Kext-Updates/OpenCore/EFI . % cp ~/Desktop/Kext-Updates/OpenCore/Docs/Sample.plist EFI/OC/config.plist % ls EFI EFI_Clover % ls EFI/OC ACPI Drivers OpenCore.efi Tools Bootstrap Kexts Resources config.plist
ここではTerminalでシェルコマンドを使って操作していますが、ファインダーでドラッグ&ドロップで行っても全く問題ありません。（ドラッグ&ドロップ中のスクリーンショットを撮るのが面倒だったのです、すみません）。結果としてこんな状態になりました。
ACPIの中身を用意する
EFI/OCの中をこれから設定していきます。まずはACPIフォルダの中です。EFI/OCに移動して、ACPIフォルダの中を見ると、空っぽです。
% cd EFI/OC % ls ACPI %
上記の解説ページのCoffee Lakeの説明によると、Coffee Lakeマシンに必要なSSDTは、以下の4個です。
- SSDT-PLUG Haswell以降のネイティブなCPU電力制御を担当。
- SSDT-EC-USBX 組み込まれたコントローラーを隠して、macOS用のフェイクなコントローラーを作ります。Catalinaユーザには必須で、他のバージョンでも使うことを推奨します。
- SSDT-AWAC 300シリーズチップセット用のRTCパッチ。ほとんどのB360, B365, H310, H370, Z390といくつかのZ370マザーボードでこれがないとブートしない。
- SSDT-PMC 本当の300シリーズマザーボード(つまりZ370は除く)はファームウェアでMMIOを宣言していないので、問題を起こします。そのようなマザーボードがNVRAMをサポートするために必要です。
上記のサイトにはコンパイルされたバージョンもありますし、ソースコードが掲載されたGitHubへのリンクもあります。なのでダウンロードすればokです。もしくは、ソースコードからコンパイルしても良いでしょう。その場合、GitHubのページに行き、Rawボタンをクリックして、全選択して、MacASL.appでコンパイルします。MaciASLについては、こちらをご覧ください。
例えば、SSDT-PLUGをコンパイルする場合は、ガイドに書かれているGitHubのページに行き、Rawボタンを押します。これで現れるテキストを全部コピーします。
次にMaciASL.appを起動し、新規ウィンドウを開いておき、ここにペーストします。
次に、MaciASL.appのFile, Save As…メニューを選び、出てくるダイアログでFile Format:をACPI Machine Language Binaryに設定し、SSDT-PLUG.amlという名前で保存します。こうして得られた4個のSSDTをACPIディレクトリに入れます。
あともう一つ。USBの15個制限対応のために、SSDTを作ってありました。このSSDT-UIAC.amlも、ACPIディレクトリに入れておきました。なので使用するSSDTは全部で5個になりました。
Driversの中身を整理する
Driversディレクトリは、初期状態では以下のようになっています。
解説によると、必要なDriverは以下の2個だけのようです。
- HfsPlus.efi
- OpenRuntime.efi
HfsPlus.efiはCloverでも使われている、HFS+ファイルシステムを読み込むドライバーです。HFS+から起動する場合に必要です。OpenRuntime.efiは、CloverでのAptioMemoryFix.efiに相当するドライバーのようです。Catalinaの時代なのでHFS+で起動することはもう無いと思いました。配布物にもHfsPlus.efi (もしくはVBoxHfs.efi) が含まれていません。そこでOpenRuntime.efiだけを使うことにします。
使用しないドライバーを消してしまうと、後で必要になるかもしれないので、ファイルは残しておきたいと思いました。おそらく、ファイル自体はこのディレクトリに残しておいて、config.plistの方で無効にするのがOpenCore流儀なのではと思います。でも不要なファイルは所定のディレクトリから外すというClover方式に慣れているので、offにするディレクトリを作って、使わないファイルをそちらに移すことにしました。以下の例では、Drivers_offというディレクトリを作って、OpenRuntime.efi以外はそちらに移動しました。
Kextsの中身を用意する
Kextsディレクトリも初期状態では空っぽです。現在、Cloverで使っている以下のkextをそのまま入れておくことにします。
- AppleALC.kext
- IntelMausi.kext
- Lilu.kext
- USBInjectAll.kext
- VirtualSMC.kext
- WhateverGreen.kext
Toolsの中身を整理する
これもDriversディレクトリと同様に、多数のファイルが初期状態で入っています。
デバッグするときに使用するツールらしいです。上記のガイドによると全部不要らしいです。でもUEFI Shellは絶対に欲しいと思いました。なのでそれだけを残して、他はTools_offというディレクトリを作って、そちらに移動しておきました。
以上で必要なファイルが、必要な場所に保存されました。あとはconfig.plistを設定するだけです。
Config.plistを設定する
コメントを消す
config.plistの全ての設定にはProperTreeを使います。config.plistが複雑すぎるので、テキストエディタを使うことは諦めました。ProperTreeを起動して先ほどSample.plistをコピーして作ったconfig.plistを開きます。
最初の5項目の#WARNINGとあるのはSample.plistの警告のコメントです。不要なので削除します。行の上でコンテクストメニューを開くと、メニュー項目にRemove …があります。これを選びます。
OC Clean Snapshotを使う
ProperTreeにはOC Clean Snapshotというメニュー項目があります。この機能が凄いです。これがあることを知ったことで、OpenCoreに移行する気になりました。OpenCoreのconfig.plistで一番面倒だと思っている点は、使用するSSDT, kext, efiドライバー, efiツールなどを全部config.plistに記載しておく必要があることです。名前を書いておくだけでなく、いろいろな設定も書いておく必要があります。ディレクトリに放り込んでおくだけでokだったCloverに比べて、面倒でした。kextを起動する順番を、config.plistの記述順で指定できるので、必要な機能なのかも意しれませんが。
このようなconfig.plistへの記述を自動化してくれるのがOC Clean Snapshotです。ProperTreeのメニューを開くと、OC SnapshotとOC Clean Snapshotの二つのメニューが現れます。
おすすめはOC Clean Snapshotの方です。これを選択すると、ACPI, Drivers, Kexts, Toolsディレクトリに入っているファイルを検出して、必要なconfig.plist設定を自動的に作ってくれます。例としてkextファイルの自動検出を示します。まずは初期状態のconfig.plistです。7個のkextが登録されていますが、先ほど保存したkextとは一致していません。Legacy_USB3.kextとAppleMCEReporterDisabler.kextの2個はKextsディレクトリに入っていません。その一方でKextsディレクトリに入れたUSBInjectAll.kextの項目がありません。従来ならば手作業で修正する必要がありました。
ここでProperTreeのOC Clean Snapshotを動かします。すると、ファイルを検出するOCディレクトリの場所を聞いてきます。そこで作業中のOCディレクトリを指定します。
すると、Kextsディレクトリに入っているkextのリストに自動的に置き換えてくれます。
このkextリストは、この順番に読み込まれるので、基本的なkextを先に読み込む必要があります。例えばLilu.kextは一番上に、次がVirtualSMC.kextなどの順番で記述する必要があります。ProperTreeのOC Clear Snapshot機能は、その順番も正しく判断してくれます。Kexts以外に、ACPIとDriversとToolsの中身も検索して、自動的に該当する箇所の記述を更新してくれます。
ACPIとKextsとToolsディレクトリのファイルに関しては、config.plistの記述の中でEnabledキーをTrueまたはFalseにすることで、個別にon/offすることが可能です。OC Clear Snapshot機能は、全てTrueにしてくれます。一方、OC Snapshot機能は、全てFalseにします。手動で必要なものを選ぶことになります。ACPIとKextsとToolsディレクトリ内にあるSSDT, kext, efiツールを有効にしたいという目的からしたら、OC Clear Snapshotの方が理にかなっていますし、こちらを使うのが便利だと思います。
ACPI項目
ではガイドのページと、ProperTreeのウィンドウを見比べながら細かい設定をしていきます。まずはACPI項目です。OC Clear Snapshot機能によりAddの内容は自動設定されています。これ以外の項目は全てデフォルト（Sample.plistの記述）のままで良いようです。
Booter項目
Quirksの項目のいくつかをデフォルトから変更します。辞書によるとquirksは、予想外の曲がり、ひねり、とか気まぐれのような意味だそうです。fuchsiaさんからコメントで教えていただいたUbuntu wikiの記載によると、ハードウェアのバグを回避するためのソフトウェア手法というような意味だそうです。ソースコードを読む時に、「なんでこんなことやっているんだろう」と不思議に思うだろうことから、予想外に曲折した状態というニュアンスで使われているのではと思いました。Sample.plistの設定から変更するQuirksは以下です。
- DevirtualiseMmio: True、slideオプションの拡張。Z390のメモリ確保に有効。
- RebuildAppleMemoryMap: True、macOS互換のメモリーマップを作る。
- SyncRuntimePermissions: True、Skylake以降でMATテーブルの問題を解決。
- SetupVirtualMap: False、仮想アドレスの問題を解決。Skylake以降では不要。
DeviceProperties項目
この項目の設定方法はCloverと該当項目と同様です。Sample.configの初期値ではPciRoot(0x0)/Pci(0x1b,0x0)のオーディオに関する情報しか書いてありません。
mifjpnさんからコメントで指摘いただいたのですが、オーディオのdevice pathが違っていました。多分、マザーボードの配線によるのだと思いますが、使用したマザーボードでは、PciRoot(0x0)/Pci(0x1b,0x0)ではなくて、PciRoot(0x0)/Pci(0x1f,0x3)でした。Hackintool.appでも確認できますし、ioregコマンドでも確認できました。
% ioreg | grep AppleHDAController
| | | +-o AppleHDAController@1F,3 <class AppleHDAController, id 0x10000055a, registered, matched, active, busy 0 (976 ms), retain 34>
なのでPciRoot(0x0)/Pci(0x1b,0x0)をPciRoot(0x0)/Pci(0x1f,0x3)に書き換えます。内容の方の、Layout IDはCloverの時も、Sample.configの通り1でしたのでこれはそのままです。
Audioに加えて、DevicePropertiesには、iGPUの情報をWhateverGreen.kextに伝える目的で、PciRoot(0x0)/Pci(0x2,0x0)の項目を追加します。Addの項目でコンテクストメニューを開き、New child under …のメニュー項目を選択します。すると新規な項目が現れるので、内容をPciRoot(0x0)/Pci(0x2,0x0)にしてtypeをDictionaryにします。さらにここにchildを作り、名前をAAPL,ig-platform-idにし、typeをDataにします。今回は、iGPUをヘッドレスとして使うので、値は、0300923Eにします。結果として、以下のようになります。
Kernel項目
Addの項目に記述するkextファイルの情報は、OC Clear Snapshot機能により自動設定されています。Quirksの項目のいくつかをデフォルトから変更します。デフォルトから変更する箇所は以下です。
- AppleCpuPmCfgLock: True、BIOSでCFG lockが解除できるなら不要です。ASUSのZ390マザボは解除できるのでFalseでも良いです。CloverのAppleIntelCPUPMに相当します。
- AppleXcpmCfgLock: Ture、BIOSでCFG lockが解除できるなら不要です。ASUSのZ390マザボは解除できるのでFalseでも良いです。CloverのKernelPMに相当します。
- DisableIoMapper: True、BIOSでVT-Dを無効にできるなら不要です。ASUSのZ390マザボは無効にできるのでFalseでも良いです。dart=0より良い選択肢です。
- PanicNoKextDump: True、カーネルパニックの情報が読めるようになります。
- PowerTimeoutKernelPanic: True、パワー変化によるカーネルパニックを防ぎます。デジタルオーディオに関係します。
Misc項目
DebugとSecurityのいくつかの項目をデフォルトから変更します。
- AppleDebug: True
- DisableWatchDog: True watch dog timeを無効にします。
- Target: 67、この値が0以外の場合、EFIディレクトリにopencore-2020-05-15-xxxxxx.txtというような名前のログファイルが書き込まれます。Sample.plistでは3になっています。67にするともっと多くのデバッグ情報がログファイルに書き出されます。ログファイルが不要なら0にします。
- AllowNvramReset: True
- AllowSetDefault: True
- ScanPolicy: 0、0にしないとUSBメモリーから起動しないらしいです。
- Vault: Optional、デフォルトのSecureのままでは起動しないです。Optionalは大文字で開始します。
NVRAM項目
本物のMacならばNVRAMに記録されるべき項目の設定です。Addでは、
- boot-argsのデフォルトにdebug=0x100 alcid=1を追加しますとあります。どちらも追加しなくても良いように思います。debug不要ならその指定は不要だと思います。DevicePropertiesのところで1に設定してあるので、alcid=1も不要です。
- prev-lang:kbdを手持ちのキーボードに合わせて設定します。デフォルトはロシア語になっています。USキーボードの場合は656e2d55533a30にします。
を変更します。またWriteFlashはNVRAMに設定値を書き込む設定で、Trueにしますと書いてありますが、どちらでも良いように思います。
Platform項目
CloverのSMBIOSに相当する項目ですね。機種IDは、Mojave以降はiMac19,1, High Sierra以前はiMac18,3が良いようです。その時代に未発売なMacの機種IDは使うなということですね。現在使用中のCloverのconfig.plistからSerialNumber, BoardSerialNumber, SmUUIDをコピーして、それぞれを、
- SystemSerialNumber
- MLB
- SystemUUID
にコピーしました。またROMの項目には、NICのMACアドレスを書いておけば良いようです。システム環境設定のネットワークから取得したEthernetのMACアドレスを書いておきました。
UEFI項目
Driversの項目に記述するefiドライバーの名前は、OC Clear Snapshot機能により自動設定されています。Quirksの項目のRequestBootVarFallbackをTrueに変更します。と書いてありますが、説明読んでもあまり違いはない気がしました。
以上でconfig.plistの設定が終了しました。それぞれの項目の説明がそれなりに書いてあるので、Cloverよりも明朗な感じです。説明資料が整っている印象があります。この状態で再起動すればOpenCoreから起動するはずです。起動しなければ、UEFI shellからEFIディレクトリの名前を書き換えて、Cloverに戻せば良いと思います。と考えて再起動を試したところ、なんと1回で成功しました。完成したconfig.plistを以下に置いておきます。SystemSerialNumber、SystemUUID、MLB、ROMの値は、これを使用せず、みなさんで必ず置換えてください。
Sanity Checkerで検証
ここで作ったconfig.plistを、OpenCore Sanity Checkerで検証しました。
赤い❌マークで警告を受けたのはUEFI, Driversの箇所で、VBoxHfs.efiもしくはHFSPlus.efiが無いという項目1点だけでした。上でも説明しましたが、Catalinaより古いmacOSを使う予定がなかったので、入れてませんでした。無しのままにしておきます。
青い❗️マークが1点、Misc, Toolsで出ていました。「You can remove the tool EFIs here」と表示されています。Toolsには、OpenShell.efiだけを入れてあります。UEFI Shellは、File Vault起動のセキュリティを回避できてしまうので、デバッグが終わったら外しておくようにという意味かと思いました。Toolsの記述を消すと、このマークは出なくなります。ただ、File Vault起動は使っていないですし、いざというときにUEFI Shellは欲しいので、これも無視しておきます。
黄色の❓マークが、以下の3カ所で表示されていました。
- SetupVirtualMapがNoだけど通常はYesです。
- DisableIoMapperがNoだけど通常はYesです。
- PointerSupportModeがASUSだけど通常は空白です。
上記で説明したように、SetupVirtualMapは仮想アドレスの問題を解決する機能ですが、Skylake以降では不要とのことでNoにしました。DisableIoMapperは、VT-Dを無効にする機能ですが、BIOSで無効にできているのでNoにしました。PointerSupportModeは、大もとのSample.plistでASUSとなっていました。OpenCoreのマニュアルを調べたところ、マウスポインター操作をサポートする設定らしいのですが、ASUSのZ87, Z97マザーボードだけがサポートされているらしいです。このパラメータは指摘どおりに空白にしておきました。
その他の設定
コメントでいただいた情報と、その後の記事で設定した項目を以下にまとめておきます。いろいろ情報をいただいた本当にありがとうございます。
起動ボリュームの指定
初期設定のままだと、リストの最初のドライブから起動します。起動ドライブを指定するには、macOSのシステム環境設定の起動ディスクを使います。ここで、起動させたいボリュームを選ぶと、その後、それで起動するようになります。Cloverでは起動ドライブの名前などをconfig.plistに書いていましたが、OpenCoreではよりmacOSに近い方法が可能になりました。
Kext Updaterを使う
Sample.plistの設定でKext Updater.appを起動すると、「Misc, Security, ExposeSensitiveDataの1, 2ビットをonにする」ように指示が出ます。デフォルトでは6だったので7にしました。コメントで教えていただきました。
rtc-blacklistが見つからない警告
起動時に出るかもしれない警告、
Warn:oc:setting nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:rtc-blacklist – not found oc
は、NVRAMの4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102のrtc-blacklistを消すと出なくなります。 コメントで教えていただきました。
Windowsが起動しない
Misc, Boot, BlessOverrideに, \EFI\Microsoft\Boot\bootmgfw.efi などと追加します。コメントで教えていただきました。
続きの記事
この記事に続く以下の記事でもOpenCoreの設定を行なっています。
まとめ
Z390マザーボードのマシンをCloverからOpenCoreに移行しました。それなりに時間はかかりましたが、すんなりと運びました。今回はCoffee Lake CPUマシンの移行でしたが、他のCPUについても同様に詳しい手順が説明されているので、問題なく移行可能と思います。説明資料やチュートリアルが充実していて、ツールも揃っているので、そろそろOpenCoreに移行しても大丈夫な時期になったかと感じました。細かい設定などを調べつつ、他のマシンも、順次切り替えていきたいと思います。
bootmacosさま
お世話になります。
記事を参考にOpenCoreを導入してみました。
簡潔なガイドのおかげですんなりと起動しました。
AsRockのZ390+9900k環境です。
SSDTのコンパイルの部分は知識とスキル不足でコンパイル済みのファイルを探してきて入れた状態ですが。。。
いくつか疑問がありまして、投稿させていただきました。
■OSのデュアルブート時のkext設定
CLOVERではOSのバージョン毎にフォルダがあって環境毎にkextを読み込んでくれていましたが、同様の設定はOpenCoreでも可能なものでしょうか？
具体的にはCatalinaとMojaveでBrcmpatchramの違うバージョンを読み込ませたいのですがうまくいかず。
両方突っ込んだりしてみましたがCatalinaの起動時に止まってしまう状況です。
■Driverについて
CLOVERで使用していたDriver類は不要と考えていいのでしょうか？実際動いているので問題ないのだと思いますが。。。
■ESPフォルダ内のログ
起動時のログが毎回保存されるようですが、どういった役割なのでしょうか？
■起動画面について
CLOVERに比べて無骨な印象ですがカスタマイズなどできるのでしょうかね？
質問ばかりですみませんです。。。
ブートローダーの変更後は以前より挙動が安定している気がします。MBのコイル鳴きが治まった（気のせい？）のと、ログイン後の起動が早くなった気がします。CLOVER時の設定が不完全だったのかもしれませんが。
分かりやすいガイド、ありがとうございました。
報告ありがとうございます。
macOSのバージョン毎にkextを切り分ける機能は無いようですね。Cloverでもkexts/Otherしか使って無い人が多かった気もして、あまり需要がないとされたのでしょうか。config.plistでkextの読み込みに動作カーネルのバージョン指定ができるので、それで行ってくださいということかな。ただ、その機能を使うと、そういう設定をしないで済むようにしたいというProperTreeのSnapshot機能が使えなくなってしまいますね。
Driverについては、ガイドで言及されている以外の、Cloverで使っていたドライバーは不要なようです。
ご指摘いただいて、ログファイルができていることに気付きました。ちゃんと動いている場合には、邪魔ですね。試してみたら、MiscのDebugのTarget値を0にすればログは書き出されないようです。本文に追記しておきました。
たしかに起動画面はシンプルすぎますね。
bootmacosさま
ご返信ありがとうございます。
>config.plistでkextの読み込みに動作カーネルのバージョン指定
こちらの方法を教えていただくことはできますでしょうか？
お手間おかけしてすみません。。。
試したことはないのでなんともいえないのですが。OpenCoreのパッケージに付属しているConfiguration.pdfの21ページあたりにAddプロパティの説明があります。この中に、MaxKernelとMinKernelキーの説明があり、これを使えば適用するバージョンを制限できるのではないかと思います。macOSのバージョンとカーネルバージョンの対応が面倒な感じはしますが。これで、例えば、Catalina用のBrcmpatchram_C.kextとMojave用のBrcmpatchram_M.kextを用意しておいて、BundlePathやExcutablePathで指定して、Max/MinKernelで指定しておけば、もしかしてお望みのことが出来るかもしれないです。
bootmacosさま
ありがとうございます！
挑戦してみます。
bootmacosさま
こちらのサイトでconfig.plistのチェックを行いました。
■OpenCore Sanity Checker
https://opencore.slowgeek.com
VBoxHfs.efiが必要との指摘と他にもいくつか設定の変更を指摘されました。
どこまで正確なのかは分かりませんが安心感はありますね。
指摘ありがとうございます。Sanity Checkerはやっておこうと思いつつ、忘れていました。チェックした結果を本文に反映しておきました。
お疲れ様です。
boot-argsのalcid=1と
DevicePropertiesのPciRoot(0x0)/Pci(0x1b,0x0)のlayout-id関係ですが、
alcのlayout-idのDeviceをPciRoot(0x0)/Pci(0x1f,0x3)とするとboot-argの方はいらなくなると思います。
こちらでは、うまく動いています。
ありがとうございました。PciRoot(0x0)/Pci(0x1f,0x3)でうまく動きました。Sample.configのお手本が違っていたのかなと思います。
いつも情報をありがとうございます
記事を参考にして試した所、無事起動しました
動作環境
マザーボード gigabyte Z390 AORUS ELITE
CPU CORE i5 9400F
VIDEO CARD Radeon RX580
iGPUを内蔵していないので
DevicePropertiesの設定は行っていません
あとは説明どおりに設定しました
NVRAMやスリープも動作しますが
一つだけ問題があります
ウインドウズとのデュアルブートで使用していますが
BIOSでマックの起動ディスクを優先にして
config.plistも
BOOT
DefaultVolume MacHDD
に設定しましたが
ウインドウズが自動的に立ち上がります
OPEN CORE BOOT MENUが
*1Windows
2MacHDD
になります
起動画面でスペースキーを押してから
2のMaｃHDDを選択すればMacOSが起動します
ウインドウズよりMacOSを先に起動する設定があるのでしょうか
デュアルブートにしていないのでよくわからないのですが。実は、こちらでも、記事の作業をした後、OpenCoreのデフォルトの起動メニューは1番になってました。どこで指定するのだろうかと思って、試しにmacOSのシステム環境設定の起動ディスクで、起動させたいボリュームを選んだら、その後、それで（多分OCメニューの3番）で起動するようになりました。OCは起動ディスク設定が効くようになったと、どこかで読んだことがあります。
bootmacos 様
MacOSのシステム環境設定の起動ディスクでMacHDDを指定したところ
MacOSが自動で起動するようになりました
情報 ありがとうございました
OpenCoreに移行して以来、sleep時にシステムのファン等が止まらない現象が発生しています。
メニューやショートカットキーからsleepさせた場合は止まるのですが、その際も接続しているiPadを外したりすると画面は復帰せずハードディスクやファン等が動き出すようです。
BIOSやpmset等いじってみたのですが状況変わらずでどうしたものかと。。。
Cloverの時はdarkwake等の設定でスリープ問題は落ち着いたのですがOpenCoreでもそのような設定は必要なのでしょうか？
お知恵をお借りできると幸いです。
こちらでも実はスリープ直後は画面への信号は止まって暗くなるものの、本体のファンがしばらく止まりません。ドライブアクセスランプが点滅して色々仕事をしているようです。でも1時間くらいそのまま放置すると、ファンは止まり、正しくスリープしています。Apple Watchでの画面解除も効きます。Cloverの時はすぐにファンが停止した気がするので、スリープの設定が変わったのかもしれないですし、Power Napが動いているのかもしれないです。
sleep問題は毎度鬼門ですね。。。
すぐに困るということでもないので気長に付き合っていこうと思います。
参考に早速移行させていただきました。
ブートGUIも0.5.8から対応になっているようで設定してみたらうまく動きました。
https://dortania.github.io/OpenCore-Desktop-Guide/extras/gui.html
GUIを試してみます。情報ありがとうございます。
GPUやデジタル音源からは出せませんが、今まで同様 AudioDxe でスタートアップチャイムも鳴らせますよ。最初手抜きして以前Cloverで使っていたAudioDxeをコピペして使ってみたのですが音が出せずで、上記サイトからダウンロード出来るAudioDxeに差し替えたら無事に音が出ました。
GUI試しました。見た目だけのことなのですけど、格段に良いですね。
OC 0.5.8でのGUIサポート、私も試してみました。
CloverbootでのMimimumist２のGUIには及びませんが、なかなかの出来上がりで惚れ込みました。
皆様方のコメントを拝読し背中を押されて、ようやく我がHacintoshで稼働を実現できました。ありがとうございました。
以下の背景・理由から、今晩から Bootloaderは Cloverbootではなく、この「GUIサポート付きOpenCore 0.5.8」に乗り換えることを決断いたしました。
1. OpenCore Bootloaderのコードが 苦難の道筋にもめげず、しっかりと成長していること。さらに、先人の方々からの熱い支援が広がっているのが、頼もしい。
2. OC NDF Forkにも少しかじってテストしてみましたが、全く歯が立たず途中でGive-up。
OpenCoreに移行してからUSBのポート指定の設定をしていないのですが、みなさんどうされていますか？
以前と同じように使えているので不自由はしないのですが、sleepへの影響もあるようで。。。
海外のサイト等回って、マッピングをした方がいいとか色々と見るのですが、いかんせん知識と技術が追いつかずです。
Cloverの時と同様にUSBInjectAll.kextを入れて、Cloverの時に作ったSSDT-UIAC.amlをそのまま入れています。何も考えないで引き継いだのですが、とりあえず問題なく動いているように見えます。
すみません！勘違いしていました。Kernel, QuirksのXhciPortLimitが、Sample.plistでtrueになっていて、そのまま使っていました。これが15個制限を解除しているようでした。マニュアルにはXhciPortLimitでの制限解除は、できれば使うなと書いてあり、推奨されていないようです。試しに、falseにしてみたら、若い番号から機械的に15個しか見えなくなりました。USBInjectAll + SSDT-UIAC.amlは効いていないようです。もう少し調べてみます。
追記：ACPI, AddでSSDT-UIAC.amlを指定することを忘れていただけでした。USBInjectAll + SSDT-UIAC.amlで15個を選択できました。
https://bootmacos.com/archives/2059
こちらの記事を参考にSSDTを作成して無事15個選択できました。
(sleepの挙動は変化なしです）
CLOVERの時はconfiguratorで指定できていたのでOpenCoreの方が全体にスキルが必要な感じですね。勝手が違うので戸惑うことも多いですが、これからいろいろなツールも出てくることを期待しています。
お疲れさまです。
うまくいきました。ありがとうございます。
こちらでは、まだNVMeのSSDを使っていないので、
Kernel
Quirks
ThirdPartyDrives: True でTrimをオンしないとけませんでした。
また、
Misc
Security
ExposeSensitiveData: は１，２ビットがONでないとKext UpdaterのWarningがでました。
起動時に
Warn:oc:setting nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:rtc-blacklist – not found oc
とでますが、
NVRAM
4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102のrtc-blacklistを消すと出なくなりました。
Windowsが立ち上がりませんでした。
Misc
Boot
BlessOverrideに
\EFI\Microsoft\Boot\bootmgfw.efi
の項目を追加で治りました。
報告までですが・・・失礼しました。
情報ありがとうございます。こちらでも、Kext Updaterで同様の警告が出たのでデフォルトが6だったところを、ビット1を立てて、7にしました。trimは、マニュアル見たらtrimforceコマンドの方がmacOS専用でおすすめな様子の説明があったのでtrimforceを使いました。以前は動かなかったのですが、nvramがちゃんと使えるようになったおかげか有効になりました。
今、OpenCore の勉強をしているところです。
“quirk” の意味は、漠然と”互換”と思っていましたが、調べてみると。
Ubuntu Wiki: X/Quirks に書かれている “Sometimes there are bugs in the hardware itself. Quirks are software ways to work around these bugs.” が、本来の意味に一番近いんじゃないでしょうか。
なるほどです。software waysを字面通り解釈すると、ハードウェアにバグを生じさせる箇所があるので、それを回避するために、ソフトウェアでプログラムの流れをグニュっとひん曲げて回避するというようなニュアンスなのかな。
記事への追加、ありがとうございます。
ここを読めば、OpenCore の全体を把握できるようになっていくと思います。
Quirks の項目の説明を読むと、こっちは悪くないという感じのところもあるし、デフォルトのままにしておけと書いてあったりもするので、このニュアンスでいいんじゃないかと思います。
全く関係ない話ですが、ThinkPad X240 と X250 やっとブートしました。
fuchsiaさん、boot macOSさん、ども。。。
＞“quirk” の意味は、漠然と”互換”と思っていましたが、
アダム、アダムスじゃないですけど。。。w
このQuirk、Quirksちゅうのもなんだか、？な英語ですよねぇ。。
私なんかは初体験はCloverでOcQuirks.efiを使い出したんで、すっかりAptio関連だと勝手に脳に刷り込んでましたぁ！
＞Ubuntu Wiki: X/Quirks に書かれている
あぁ〜。。。にゃるほど！そうですねぇ、ここのUbuntu Wikiに書かれてあることみて、明らかに私が勘違いしてるというのが判明しました。
このコメントは大変助かりました。 Thanks! ありがとうございます。
Aptio関連だと思い込んでて、ふと、オープンコォーのconfig.plstにはQuirksがACPIやら、BooterやらKernelやらUEFIに分散して存在してるのを観測！あれ？！なんだこりゃって思って、なんか理解してたことがおかしいなって思っていろいろ調べててこのコメント見つけてショック！理解が根本的に足らず間違ってたぁ！
そんなこんなで、この不思議な英語Quirkを調査してたら、オプーコォーの死海文書ことConfiguration.pdfの2.3 Configuration Structureの節に、ショートフレーズな説明を発見！
＞Quirks provides support for specific hacks.
これで一撃ですね！
英英辞典にある以下のとこが目に止まったので貼っておきます。
https://www.ldoceonline.com/jp/dictionary/quirk
a strange habit or feature of someone’s character, or a strange feature of something
feature of UFEI（include VBIOS?) Firmware character with Hacksだとシックリくる気がしてきています。。。
Vitさんとacidantheraさんのコンビが？ごりごりUEFIやVbiosなどをリーバスエンジニアリング して、Hardwareに直接関係性があるUEFIとVbiosにある部分をmac対応にするためにhackして設定項目化して、複数集まった物（Quirks）と呼んでconfig.plstでそれを操れるようにしてるってことなんじゃなかろうかって気がしますねぇ
もともとLinux界隈のビデオ（X?）とかUFEIの対応とかの実装で使われてた言葉のかな？？？
勝手な憶測ですけど、暗喩？Metaphor？？？的にQuirkとHackは発音も微妙ににてるし、ただ単にPatchの項目とかOptionsとかの分けて使えるし、英語圏の人にはある意味分かりやすいのかもですね？
Quirkはそうゆう和訳できない英単語なんで、カタカナのクォークとかできないし、Hackintosh英和辞典に載せるのに良い単語なのかも？
OpenCoreに移行後に発生しているsleep問題ですが、色々と試しているものの解決できていません。
指定時間にディスプレイsleep→ファン等は回り続けている状態。
pmsetコマンドで見えているsleepの阻害原因は
sleep prevented by UserEventAgent, UserEventAgent, UserEventAgent
という状況で、USBデバイスの抜き差し、BluetoothのOFFなど試しているのですが、状況は変わらずで。。。
構成は9900k、radeon Ⅶ、AsRock Phantom gaming itx、BCM94352z（各種kext)、Catalina 10.15.4、USBの15個制限は指定済みです。
どなたかお知恵を拝借できると幸いです。
手元のマシンでも同様の状態で、画面が消えてファンが回ったままでした。ドライブへのアクセスランプが時々点滅していました。でも、1時間くらい放置しておくと、知らないうちに正しくスリープしていました。これはこれで正しい挙動なのかと思い、そのまま使い続けていました。
今、確認したら、今現在はすぐにスリープするようになってます。特に変わった対策はしていません。強いていうなら、BIOSを更新して、OpenCoreのメニューでnvramをクリアしたことくらいかなと思います。画面が消えてもファンが回っていた時は、おそらくは、内部で仕事をするデーモンが動いていて、スリープするまでに時間がかかっていただけではと思います。そのデーモンの仕事が終わったので、すぐにスリープするようになったのだと思ってます。そのまましばらく使い続けられてはどうでしょうか？
＞sleep prevented by UserEventAgent
過去のトピでもUSB関連がお邪魔してるような話の流れがあるようですし。。。
デベロッパーツールのIORegistryExplorerで、BCM94352ZにくっついてるBluetoothについて、XHCのいづれかのHSxxにぶら下がってはずなので、そのBluetooth Host ControllerのUsbConnectorのタイプがほんまに0xffになってる確認してないならチェックしておいた方がよいかもですね。。。もしも0x3とかで0xffじゃないなら、うまくスリープできない原因の可能性がありますから。。。
IORegistryExplorer 3.0.2
https://mac.softpedia.com/dyn-postdownload.php/c041ba478595147787a6a35c2dbd4165/5ec9ddbb/21c3c/4/1
私んとこのHS11にぶら下がってる例。。。
https://imgur.com/a/Lc4PzUK
03ってのはUSB 3.0のコネクタで、255は内部コネクタだという設定ですよね。その設定もスリープに影響するのですね。
まっくぷろさん
ご返信ありがとうございます。
BluetoothのポートはUSBのポート指定でinternalに設定していて、
確認したところ0×ffになっていました。
Bluetooth周りのkext 類も見直して、
BrcmBluetoothInjector.kext
FakePCIID_Broadcom_WiFi.kext
のみにしました。
（OpenCoreだとBrcmPatchRAM3.kext等はなくても94352zは動くようです）
手動でもsleepだとファンは止まるので、そこらへんの挙動が謎です。。。
＞BluetoothのポートはUSBのポート指定でinternalに設定していて、
＞確認したところ0×ffになっていました。
そうですか。。。んじゃBluetoothは無罪放免ですねぇ。。。
＞OpenCoreだとBrcmPatchRAM3.kext等はなくても94352zは動くようです
逆にBrcmPatchRAM3.kexで動くようにすべきかも？？？って気もしますけど。w
https://www.tonymacx86.com/threads/dw1560-bluetooth-on-catalina-10-15-1.286412/
あと、FakePCIID_Broadcom_WiFi.kextって、もしかしてRehabManさんのですよね？
モダン志向？なOpenCoreだとLilu.kextとAirportBrcmFixup.kextあたりで動く可能性もある気もしますけど、もしも動くならならこの組み合わせでお使いになった方がよろしくないですか？たぶんOpenCoreで動くから大丈夫ですよっていうテストの対象外な気もしますんで、時代背景から彼ら的にFakePCIID_Broadcom_WiFi.kextはもはや動いてもしらんっよっていう扱いになるんじゃないかって。。。
全体的にRehabmanの全盛期？のkext類は、Lilluの仲間になるようRebornしたというか引き継がれてる？acidantheraさんのとかUSBinjextAllのsinkiさんのとかに変えないと、いろいろ具合が悪くなってる気がしなくもないですね。。。
ということで。。。次はFakePCIID_Broadcom_WiFi.kextを疑ってかかる案はどうでしょ？。。。
まっくぷろさん
ありがとうございます！
AirportBrcmFixup.kextのみでもwifiは正常に動きました。
Bluetoothに関してはイマイチ理解し切れていないのですが、
BrcmBluetoothInjector.kext単体→動く
BrcmBluetoothInjector.kext
Brcmfirmwaredata.kext
Brcmpatchram3.kext 3つ→動く
という感じでして。素人考えですが、１つで動くならその方がシンプルでいいような気もするのですが、どうなんでしょうか。。。ちなみにBrcmBluetoothInjector.kextを外すと動きません。
sleepの方は相変わらずです。。。
＞１つで動くならその方がシンプルでいいような気もするのですが、
＞どうなんでしょうか。。。
BrcmFirmwareData.kexとBrcmPatchRAM？.kext
は、たしか？本当に仕事してる時って、システムプロファイラでApple Bluetoothソフトウェアの表示のバージョンに変化が見られた気がします。
https://imgur.com/a/rTPRUFD
BrcmBluetoothInjector.kextは、FirmwareをUploadする前にBTを生かすインジェクトさせるために必要なので必須、残りの2つはBTのFirmware関連に付随する問題解決が必要なシチュエーションに使うようになってると思ってます。表面上具体的に問題が起こってなくともBTのFirmwareがkextを使う前より上になってるようならBrcmFirmwareData.kexもしくはBrcmFirmwareRepo.kextとBrcmpatchram(2 or 3).kext入れとくと安心なのかもですよ。。。
この手のごにょごにょが終わったら、kextのキャッシュのアップデートとNVRAMクリアをしたてお呪いかけといた方がよいかもです。さらにBoot Argsに-xを追加してSafemodeでも大丈夫だというとこまで確認したりするのも気持ち的に安心かもです。
あとはACPI＞Patchedに何らかのCustomSSDTをこしらえる必要があるのかもしれないですね。同じマザボ使ってGitHubで公開してる方がいれば、なんか見慣れないSSDT使ってたりすることが観測できたらそれを真似する必要があるかもです。
そうゆうCustomSSDTが必要なら-vオプションで、バラバラ流れてる文字に、不思議なエラーが出てたりするので、ErrorとかFailedとかの文字は要注意かも。。。
まっくぷろさん
kextを入れ替えて試してみましたが、ソフトウェアのバージョンはどちらも7.0.4f6でした。
とは言え、ご指摘の内容からすると入れておいた方が良さそうなので3つ入れて運用してみます。
kextのキャッシュのアップデートなど試してみつつ、boot時に止まることもあるのでCustomSSDTに関しても調べてみようと思います。
色々とありがとうございます。
なんだか本筋から外れてしまっている気もするのでForumsの方にスレッド立てますね。
すみません。。。
すみません。訂正させてください。
上に
BrcmBluetoothInjector.kext単体→動く
と書き込んだのですが、kextの入れ替え直後は動くものの、時間が経つと動かなくなりました。
なんらかのキャッシュみたいなものが働いているのか、kextの入れ替え検証には注意が必要かもですね（再現性は不明ですが）。
OpenCoreでBroadcom94352z使用時ですが、
AirportBrcmFixup.kext→wifi
BrcmBluetoothInjector.kext
Brcmfirmwaredata.kext
Brcmpatchram3.kext →Bluetooth
という組み合わせがいいようです。
同様の検証時にブート途中で止まる現象が頻発しました。NVRAMのクリアやBIOSに一旦入ってなどやっていると復旧して、それ以降は普通に立ち上がるのですがconfig.plistやそれに付随するドライバ、kextを更新した際に整理に時間がかかるのかもしれません。
上記のsleep問題に関しては解決いたしました。Forumsに投稿しましたが、USBのポート指定のミスでした。
一連の検証中に、ブート時に途中で止まる現象が頻発して、ログを見ていたらどうやらwifiカードの部分でエラーが出ているようでした。
ごにょごにょやっていたのですが、FakePCIID関連のkextを外したことが原因だったようで、戻したところブートに失敗することはなくなりました。wifiカード周りの必要なkextはCLOVERと変わらないようですね。。。
bootmacosさん、まっくぷろさん、ご助言ありがとうございました！
何度もすみません。
ブート途中で止まる現象が再発しました。fakePCIID関連ではなかったようです。。。
https://dortania.github.io/OpenCore-Desktop-Guide/troubleshooting/troubleshooting.html#stuck-on-eblogexitbsstart
こちらの部分で止まるので、書いてある対処法を試してみましたが治りません。
移行当初は出ていなかった症状なので不思議です。。。
ブートに失敗する症状が出たり出なかったりする様子だと、乱数がらみで不具合が出るKASLRの問題のような気もするのですが、いかがでしょう。
https://bootmacos.com/archives/6108
＞03ってのはUSB 3.0のコネクタで、
とりあえず目についた3を例にだしちゃいましたけど、そういえば3って何だっけていうはなしですよね？私も0, 2, 255は記憶してたけど3ってあらためて考えると初めて見た数値であることに気づきました。。。
こちらの中国の方のご説明によると、9とか10ちゅうのもある時代になってることにRealizeしちゃいました。。。『使用するUSBポートを15個指定する (OPENCORE編)』へ追記する必要があるかもですね。。。
https://translate.google.com/translate?hl=ja&sl=zh-CN&tl=en&u=https%3A%2F%2Fwww.imacpc.net%2F%3Fp%3D645&prev=search
We should change the UsbConnector value to match the port type. The default value is not always correct (USBInjectAll cannot know what the correct value is).
Note: Do not change the port address assignment. All port addresses in SSDT-UIAC-ALL.dsl are correct. Changing them will only destroy things.
The common port connector type is USB2 = 0, USB3 = 3, internal = 255. USB
The Type C port can be 9 or 10, depending on how the hardware handles the two possible directions of the USB Type C device / cable.
If USB-C uses the same SSxx in both directions, it has an internal switch (UsbConnector = 9).
If USB-C uses a different SSxx in each direction, it has no switch (UsbConnector = 10).
The HSxx port connected to the USB3 port should be labeled UsbConnector = 3, not UsbConnector = 0.
＞その設定もスリープに影響するのですね。
bcm94360CDの故障時のバックアップ用に購入したbcm943602cs となんだか不明なPCIeカードに載せて使おうとして、Cloverでスリープの挙動が変になったんで、いろいろ調査してたら、UsbConnectorのタイプがほんまに0xffじゃないとSleep拒絶反応が出ることが判明しました。しかも、このなんだかわからないPCIeカードはbcm94360CDからのUSBケーブルをHSxxのコネクタタイプ＝0xffにNZXT INTERNAL USB HUBをぶら下げて経由接続しても問題なくSleepできるけど、bcm943602csとなんだかわからないPCIeだとNZXTのHub経由したらSleepがこれまたNGで マザボのF_USBであるinternal headerに直結じゃないとSleepしない問題が発覚したので、bcm系のBluetoothはUSBConnectorTypeは0xff決め打ちじゃないかと理解してます。。。
スリープの情報ありがとうございます。また、コネクタ番号は、HackintoolのGitHubのソース（ヘッダファイル）を見たら、0x00から0x0Aまで（と0xff）の12種類あるみたいです。実際に使うのは0, 3, 9, A, FFくらいのようですが。今後の記事で言及しておきます。
bootmacosさま
ご返信ありがとうございます。
画面sleep後も本体は動き続けている感じで、一晩放置しても本体はsleepしない状況です。
OpenCoreに移行するにあたって、OSのクリーンインストール、BIOS更新等を一気にやったのですが、内部で色々と整理しているのですかね。。。
ご指摘の通りもう少し様子を見てみようと思います。
一晩その状態ですか。HDD/SSDのアクセスランプは点滅しますか？手元のマシンだとずっと点滅していたので、いかにも裏で仕事している感じでした。
HDD、SSDのアクセスランプがケースについていないので画面sleep中の状況がわからないのです、、、
特段音はしないのですが、SSDなのでなんとも言えず。
https://www.dssw.co.uk/powermanager/
こちらのアプリで強制的にsleepさせていますが、挙動が安定しないのとサブスクリプションなので費用がかかるのがネックです。
マザボのアクセスランプのピンにLED挿しておくとアクセスの様子はすぐにわかるかも。専用のパーツ買っても300円くらいらしいので一つ持っていても良いかもです。 https://www.amazon.co.jp/dp/B0798SDTS1/
あとはネットからリクエスト受けて仕事しているかもしれないですね。LANケーブル外して、WiFi offにするとどうでしょうか。
ネット関係も違うようでした。
アクセスランプ、購入してみます！
いつも参考になる記事、ありがとうございます。
私も先日OpnecoreにてRyzen9 , RadeonIVを構築しました。ほとんどのソフトが無事起動できているのですが、Lightroomだけは起動しません。
もし、何か情報をお持ちでしたら教えていただけないでしょうか。
RyzenもLightroomも使っていないのですが、検索してみると難しいようですね。WindowsでもAMD CPUでAdobe製品が使えないという話を時々目にしますので、Mac版でもIntel依存のコードがあるのかもです。でもWindows版製品と違って、macOSでAMDに対応してくれるとは思えないので、Intel CPUに変えるしかないのかもです。
返信ありがとうございます。
もうちょっとググってみます。
OpenCoreの名前とロゴをパクった悪評高いこちらの会社でも、AMD CPUでLightroomは動かないって書いてありますね。
https://opencore.computer
edit: サイトを閉じたようですね。
ここら辺を情報源にするしかないと思います。
https://gist.github.com/XLNCs/86d7a391e46f85a04d28db171656b458
ありがとうございました。
私もちょうど見つけて実施しましたら動きました。
これで主要なソフトは起動でき、細かな不具合はありますが十分使えるようになりました。
LightroomがAMD CPUで動いたということでしょうか？無理らしいという情報もあったので素晴らしいです。
詳細な原因はわかりませんが、lightroomCCは問題なく動きました。ただしlightroomは起動しません。
ただ、これでPhotoshop、Final cut、DaVinc、LRtimelapsと必要なシフトが今のところ問題なく動いています。
＞OpenCore Sanity Checker
Andrey1970氏曰く、0.6.0以降では？OpenCore Sanity Checkerじゃなくって？OC utilitiesフォルダに配備されている ocvalidateをつかえや！ゴらぁ！という流れになるらしいです。。。
2020-08-01のDev Buildには確かにそんなの入っているようです。
It is possible to perform basic validation of the configuration by using ocvalidate utility. Please note, that ocvalidate must match the used OpenCore release and may not be able to detect all configuration flaws present in the file.
https://www.insanelymac.com/forum/topic/338516-opencore-discussion/?do=findComment&comment=2732776
＞After you have removed BlacklistAppleUpdate, then go to https://opencore.slowgeek.com/ and
＞validate your config.plist, it can help you to find misstakes in your config.
No! Use OC utility ocvalidate.
そういえばOpenCoreの設定するツールも使うなって書いてあった気もします。OpenCoreを作っている人たちから見ると、他の人が作ったツールはいろいろアラが見えるのかな。