OpenCore on Boot macOS

macOS Sequoia 15.6.1 に更新

Tue, 26 Aug 2025 13:37:01 +0900

macOS Sequoia 15.6.1がリリース（2025/8/20）されていたので、15.6から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.63GBです。OCLPでパッチを当てているので、フルサイズになっているようです。

OCLPを外すと、678.2MBになりました。アップデートの内容は、セキュリティ修正のようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。ビルド番号は24G90でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.6から15.6.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.6 に更新

Thu, 07 Aug 2025 21:58:53 +0900

macOS Sequoia 15.6がリリース（2025/7/29）されていたので、15.5から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.63GBです。OCLPでパッチを当てているので、フルサイズになっています。

OCLPを外すと、1.43GBになりました。アップデートの内容は、バグとか脆弱性への対応のようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24G84でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.5から15.6にアップデートしました。今まで通り、安定して動作しています。

OpenCore 1.0.4 から1.0.5に更新

Thu, 07 Aug 2025 20:13:25 +0900

OpenCoreの1.0.5が公開 (2025年7月7日) されていたので1.0.4からアップデートしました。config.plistに追加された項目はありませんでしたので、1.0.4 のconfig.plistそのままでも動きます。

1.0.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

大きな変更は無いようですが、

Fixed kext injection compatibility issues with macOS 26

という項目があるので、macOS Tahoeに少し対応したのかもしれません。

OpenCore 1.0.5とmacOS Sequoiaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sequoia 15.5
OpenCore Legacy Patcher 2.3.2 (WiFi対応のため)

今回のタイミングでAppleALC.kext, Lilu.kext, RestrictEvents.kext, VirtualSMC.kext, WhateverGreen.kext がアップデートされてましたので、これも最新にしました。

EFIのバックアップを取る

何かあって起動しなくなると大変ですから、EFIのバックアップをとっておきます。EFIフォルダをどこかにコピーしておけば良いだけの簡単な作業です。Kext Updaterには、EFI Backupというボタンがありますからこれを押すと ~/Documents/EFI-Backup/EFI_Backup_2024.12.13-19-17.zipというような名前でバックアップしてくれるので、さらに簡単です。ただ、起動しなくなった場合に、このファイルにアクセスできる手段は用意しておく必要があります。通常はAPFSなので、EFIシェルやWindowsからはアクセスできません。

起動しなくなった場合に即座に対応したいならば、FAT32でフォーマットしたUSBメモリに、EFIという名前のフォルダを作り、起動に使っているEFIファイル類をコピーしておくと良いです。BIOSからこのUSBメモリを指定すれば、アップデート前と同様に起動します。私の場合は、iCloudでDocuments以下を同期してあるので、他のMacからすぐに読み出せます。

.efiファイルを差し替える

更新するために、今までと同様に、X64/EFIフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。

config.plistを作り直す

現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作ります。

この際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。

今回追加された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。

macOS Sequoia 15.5 に更新

Mon, 26 May 2025 01:37:09 +0900

macOS Sequoia 15.5がリリース（2025/5/13）されていたので、15.4.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.62GBです。OCLPでパッチを当てているので、フルサイズになっています。

OCLPを外すと、1.53GBになりました。Apple Intelligenceが売りのようです。でも、Apple IntelligenceはIntel Macでは動かないので、Hackintoshでも使えません。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24F74でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.4.1から15.5にアップデートしました。今まで通り、安定して動作しています。

Apple Intelligenceには未対応でした。例えば、Apple Silicon搭載MacだとインストールされるImage Playground.app（AIによる画像生成を試すアプリ）は、インストールされませんでした。Apple Intelligenceを使うためには、Apple Silicon搭載Macに買い換える必要があります。

macOS Sequoia 15.4.1 に更新

Wed, 23 Apr 2025 12:15:18 +0900

macOS Sequoia 15.4.1がリリース（2025/4/16）されていたので、15.4から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.58GBです。OCLPでパッチを当てているので、フルサイズになっています。

OCLPを外すと、842.1MBになりました。脆弱性に対応したセキュリティアップデートのようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24E263でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.4から15.4.1にアップデートしました。今まで通り、安定して動作しています。

OpenCore 1.0.3 から1.0.4に更新

Sat, 12 Apr 2025 21:53:08 +0900

OpenCoreの1.0.4が公開 (2025年3月4日) されていたので1.0.3からアップデートしました。config.plistに追加された項目は1件だけですが、デフォルトで対応しました。なので1.0.3 のconfig.plistそのままでも動きます。

1.0.4をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.4とmacOS Sequoiaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sequoia 15.4
OpenCore Legacy Patcher 2.3.2 (WiFi対応のため)

今回のタイミングでAppleALC.kext, VirtualSMC.kextがアップデートされてましたので、これも最新にしました。

EFIのバックアップを取る

.efiファイルを差し替える

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。

config.plistを作り直す

今回追加された項目は、以下でした。

Booter/Quirksに、ClearTaskSwitchBit が追加されました。古いmacOSで32bitカーネルが動作する場合に必要な機能らしいです。古いmacOSは使ってないので、デフォルトのまま、falseにしておきました。

デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動すると思います。

macOS Sequoia 15.4 に更新

Tue, 01 Apr 2025 22:53:51 +0900

macOS Sequoia 15.4がリリース（2025/3/31）されていたので、15.3.2から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

OCLPを外すと、3.34GBになりました。写真でメモリー動画が作れるようになったようです。AIでメール仕分けするとか、いろいろ便利になりそうです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ログインしようとすると、今までのアップデートとは違って、「次回から自動ダウンロードします」とか、「ようこそMacへ」などの画面が出ましたが、そのあとは、普通通りログインします。

ビルド番号は24E248でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.3.2から15.4にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.3.2 に更新

Wed, 12 Mar 2025 19:27:05 +0900

macOS Sequoia 15.3.2がリリース（2025/3/11）されていたので、15.3.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.22GBです。OCLPでパッチを当てているので、フルサイズになっています。そのせいか、説明もSequoiaが公開されたメジャーアップデートの時の内容になってます。

OCLPを外すと、642.9MBになりました。アップデート内容は、セキュリティアップデートのようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D81でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.3.1から15.3.2にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.3.1 に更新

Fri, 21 Feb 2025 17:53:59 +0900

macOS Sequoia 15.3.1がリリース（2025/2/11）されていたので、15.3から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

OCLPを外すと、640MBになりました。アップデート内容は、セキュリティアップデートのようです。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D70でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.3から15.3.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.3 に更新

Wed, 05 Feb 2025 14:44:54 +0900

macOS Sequoia 15.3がリリース（2025/1/27）されていたので、15.2から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

OCLPを外すと、1.39GBになりました。説明は、前回のアップデートからの差分の内容になりました。15.3では、計算機に機能が追加されたようです。もちろん、これだけでなく、多数のアップデートがされているはずと思います。

アップデートする

「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D60でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

新機能を試す

アップデート内容に、「“計算機”で、等号をもう一度クリックすると、最後の数式の演算を繰り返すことができます」という項目がありましたので、試してみました。計算機を開いて、100×1.05=を計算します。

100×1.05=を入力

100万円を年利5%の定期預金に預けた1年後の預金額、の計算です。結果は105万円です。ここで=キーをさらに押したところ、最後のx1.05=の演算が繰り返されました。=キーを全部で10回押せば、複利計算されて、10年後の預金額、162.889万円になります。

100×1.05==========を入力

ちなみに、バージョン15.2の計算機では、=を複数回押しても、結果は変化しませんでした。

まとめ

macOS Sequoia 15.2から15.3にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.2 に更新

Fri, 13 Dec 2024 19:15:10 +0900

macOS Sequoia 15.2がリリース（2024/12/12）されていたので、15.1.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.25GBです。OCLPでパッチを当てているので、フルサイズになっています。説明もSequoiaが公開されたメジャーアップデートの時の内容になってます。

OCLPを外すと、2.17GBになりました。説明は、前回のマイナーアップデートからの差分の内容になりました。15.2では、写真とSafariなどに機能が追加されたようです。

更新する

「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24C101でした。

OCLPを復活

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

新機能を試す

天気

アップデート内容に、「メニューバーに“天気”を追加すると、現在の気象状況をMacのメニューバーで確認したり、クリックして詳しい天気予報に素早くアクセスしたりできます」という項目がありましたので、試してみました。「アップルマーク」「システム設定」「コントロールセンター・メニューバーのみ」の天気を「メニューバーに表示」にします。デフォルトは非表示でした。これで、以下のように、メニューバーから天気を確認できます。

株価

「“株価”の時間外（立会時間前）の株価で、市場が開く前にNASDAQとNYSEの銘柄を追跡できます」という機能も追加されたので確認しました。以下は、15.1.1での株価（上）と、15.2での株価（下）のスクショです。

日本時間で18時過ぎのスクショなので、NASDAQは立会時間前取引の時刻です。日本時間早朝に終了した立会時間取引の終値に加えて、立会前価格が実時間で表示されるようになりました。グラフ部分は、立会時間内の価格グラフだけで、今までと変わりません。

まとめ

macOS Sequoia 15.1.1から15.2にアップデートしました。今まで通り、安定して動作しています。

OpenCore 1.0.2 から1.0.3に更新

Fri, 13 Dec 2024 16:31:40 +0900

OpenCoreの1.0.3が公開 (2024年12月4日) されていたので1.0.2からアップデートしました。config.plistに追加された項目はありません。なので1.0.2 のconfig.plistそのままでも動きます。

1.0.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.3とmacOS Sequoiaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sequoia 15.1.1
OpenCore Legacy Patcher 2.2.0 (WiFi対応のため)

今回のタイミングでAppleALC.kext, Lilu.kext, WhateverGreen.kextがアップデートされてましたので、これも最新にしました。

EFIのバックアップを取る

起動しなくなった場合に即座に対応したいならば、FAT32でフォーマットしたUSBメモリに、EFIという名前のフォルダを作り、起動に使っているEFIファイル類をコピーしておくと良いです。BIOSからこのUSBメモリを指定すれば、アップデート前と同様に起動します。

.efiファイルを差し替える

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。

config.plistを作り直す

今回追加された項目はありませんでした。古いconfig.plistのままでも、変更なしで起動すると思います。

OpenCore 1.0.1 から1.0.2に更新

Wed, 27 Nov 2024 22:09:42 +0900

OpenCoreの1.0.2が公開 (2024年10月9日) されていたので1.0.1からアップデートしました。config.plistに追加された項目は1点だけで、デフォルトのままで問題ありません。なので1.0.1 のconfig.plistそのままでも動きます。

1.0.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.2とmacOS Sequoiaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sequoia 15.1.1
OpenCore Legacy Patcher 2.1.2 (WiFi対応のため)

今回のタイミングでAppleALC.kext, Lilu.kext, RestrictEvents.kext, VirtualSMC.kext, WhateverGreen.kextがアップデートされてましたので、これも最新にしました。

.efiファイルを差し替える

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

今回追加された項目は、以下でした。

UEFI/ReservedMemoryに、Unload が追加されました。array型の情報で、初期値は空です。すでに存在するファームウェアドライバをアンロードする項目とのことです。デフォルトのまま、空にしておきました。

大きな変更はありませんので、古いconfig.plistのままでも、変更なしで起動すると思います。

macOS Sequoia 15.1.1 に更新

Fri, 22 Nov 2024 23:51:53 +0900

macOS Sequoia 15.1.1がリリース（2024/11/19）されていたので、15.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。セキュリティアップデートとのことなので、機能は変わらないと思われます。

サイズは、macOSの本体とほぼ同じ14.53GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、651.1MBになりました。

「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24B91でした。

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.1から15.1.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.1 に更新

Tue, 29 Oct 2024 17:58:55 +0900

macOS Sequoia 15.1がリリース（2024/10/28）されていたので、15.0.1から更新しました。特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。iPhoneミラーリングでドラッグ&ドロップが可能になったようです。iPhoneミラーリングは、セキュリティチップのないHackintoshでは使えない機能ですが、実機のMacで使うととても便利です。

サイズは、macOSの本体とほぼ同じ14.53GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、1.883GBになりました。「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24B83でした。

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.0.1から15.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15.0.1 に更新

Sat, 05 Oct 2024 20:22:15 +0900

macOS Sequoia 15.0.1がリリース（2024/10/3）されていたので、15.0から更新しました。バグ修正のアップデートということもあり、特に問題なく安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。アップデート項目が多数列挙されていますが、Sequoiaになっての新機能がまだ表示されているだけのようです。今回の更新目的は、バグ修正なので機能の変更は無いものと思われます。

Software Update

サイズは、macOSの本体とほぼ同じ14.45GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、774.8MBになりました。「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。

Download

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24A348でした。

About This Mac

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、Wi-Fiが復活しました。

まとめ

macOS Sequoia 15.0から15.0.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia を自作PCにインストール

Tue, 17 Sep 2024 15:29:37 +0900

macOS 15.0 Sequoia が日本時間2024/9/17に公開されました。これを、ASRock Z690 Steel Legend、Intel 13900KF、AMD Radeon RX 6600で構成した自作PCにインストールしました。OpenCore、kext類は最新です。Sonoma 14.6.1を起動している設定と全く同じ設定で動作しました。使用できないSequoiaの機能はあるかと思いますが、基本的に問題なく動作します。

OpenCoreの設定

OpenCoreの設定は、Sonomaを動かしていた時と同様で、全く変更していません。Wi-Fiに関する設定については、こちらをご覧ください。

SonomaでBroadcom Wi-Fiを有効にする

以下の作業で使ったOpenCoreの設定 (EFIのファイル類) を、こちらに置いておきました。参考になさってください。（シリアル番号などは適当に書いてありますのでこちらを参考にしてconfig.plistを書き換えてください）

Sequoiaインストーラを入手

macOSインストーラーを入手するために、ベータ版の時と同様にsoftwareupdateコマンドを使いました。Sequoia対応のMacのターミナルで、以下のコマンドを入力すると、Sequoiaがダウンロード可能なことがわかります。ちなみに、Sonomaの方も14.7が配布されているようでした。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia, Version: 15.0, Size: 14138558KiB, Build: 24A335, Deferred: NO
* Title: macOS Sonoma, Version: 14.7, Size: 13343514KiB, Build: 23H124, Deferred: NO
（以下略）

次に、同じくsoftwareupdateコマンドで、Version 15.0のダウンロードを指定すると、Sequoiaをダウンロードできました。公開日当日で混んでいるためか、時間がかかりました。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 5.0%

Installingの数値が100%に到達すると、表示がInstall finished successfullyに変化し、終了します。すると、「アプリケーション」の中に、Install macOS インストール.appというインストーラが出来上がってました。

macOS Sequoia Installer

クリーンインストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、Intel 13900KF、AMD Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.1です。このコンピュータには、以下の２個のSSD（他にも多数接続してます）が接続されてます。

Macintosh HD (OpenCore 1.0.1 とSonoma 14.6.1)
Sequoia (Sequoia Beta 8)

現在、Macintosh HDのOpenCoreで起動して、SequoiaのSequoia Beta 8を動かしています。Sequoia Beta 8から起動した状態で、Macintosh HDをフォーマットして、クリーンインストールすることにしました。

ちなみに、ユーザー用のディレクトリは、homeと名付けた別のボリュームに入れてます。システムだけがMacintosh HDに入っているので、これだけを消去しました。EFIもユーザデータも無事なはずです。

HDD構成

次に、Sequoia Beta 8で起動している状態で、先のInstall macOS インストール.appを開きます。

macOS Sequoia Installer

続けるボタンを押して、消去したばかりのMacintosh HDボリュームをインストール先に選択しました。これでクリーンインストールができるはずです。

インストールの準備が終わると、再起動を促す表示が現れます。この先2-3回ほど再起動し、最初はmacOS Installerというボリュームから起動し、次回以降はMacintosh HDから起動しました。EFIボリュームに残したOpenCoreは正しく機能していたようです。

動作確認

この後、無事Sequoiaが起動して、通常通り使用できました。

About This Mac

ユーザディレクトリを、元のhomeボリュームに戻したので、データも全部引き継がれました。実用的に使えてますので、Sonomaから完全移行することにします。

OCLPは2.0.1になってましたので、これでBroadcomのWi-Fi設定をしました。Wi-Fiも接続可能になりました。

OCLP 2.0.1

Sequoiaの目玉機能の一つだったiPhoneミラーリングは、動作しませんでした。iPhoneとBluetoothで接続できて、コード認証の画面までは進むのですが、その後、Wi-Fiで接続する段階で動作しなくなりました。T2チップ、もしくはApple Siliconが必要らしく、今後も無理そうです。

iPhone mirroring

まとめ

macOS 15.0 Sequoiaが公開されたので、ASRock Z690 Steel Legendで自作したPCにインストールしました。Sonomaの時に使用していたのと同じOpenCore設定で動作しました。EFIファイル類は以下で公開してますので、参考になさってください。

Sequoia

T2チップを利用した一部機能は動作しませんが、実用的には問題なく使用できてます。

OpenCore Legacy PatcherがSequoiaに対応

Sun, 15 Sep 2024 13:15:05 +0900

OpenCore Legacy Patcher (OCLP)の 2.0.0がリリースされました。Sequoiaのベータ版にインストールしたところ、SequoiaでもBroadcomのWi-Fiが使えることを確認しました。

Sonoma以降で使えなくなったBroadcomのWi-Fiは、OpenCore Legacy Patcher (OCLP) を使うと復活できます。詳細は以下の記事をご覧ください。

SonomaでBroadcom Wi-Fiを有効にする

OCLPがSequoiaに対応

SonomaのWi-Fi対応のために使っているOCLPから、アップデートの案内が出てました。Ver. 2.0.0になって、Sequoiaに対応したようです。

OpenCore Legacy Patcher update

そこで早速試してみることにします。

Sequoiaベータ版にインストール

ここからは、Sequoiaベータ版を起動して進めました。ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600を以下の設定で使ってます。

macOS Sequoia 15 Beta 8をインストール

Sequoiaベータ版は、メインで使っているSSDとは別のSSDにインストールしてあります。コンピュータのUEFIの起動は、SonomaがインストールされたメインのSSDで行い、OpenCoreの起動ボリューム選択で、Sequoia SSDを起動します。なので、OpenCoreの設定やkext類はSonomaを動かしている状態のままです。

次に、OCLPリリースページから、2.0.0をダウンロードします。

https://github.com/dortania/OpenCore-Legacy-Patcher/releases

ここから、OpenCore-Patcher.pkgをダウンロードしました。pkgファイルを開くと、インストーラが起動します。

OCLPインストーラ

インストール終了すると、アプリケーションフォルダの中にOCLPアプリができているので起動します。

OCLP 2.0.0

ここで、Post-Install Root Patchを選ぶと、Wi-Fi関係のパッチを当てられます。

Post-Install Root Patch

再起動するとWi-Fiが使えるようになってました。

Wi-Fi

まとめ

OCLPがアップデートされて2.0.0になり、Sequoiaに対応しました。そこでSequoiaベータ版で、動作を確認しました。OCLPを起動してボタンを押すだけでWi-Fiが動作するようになりました。SonomaとSequoiaの差は少ないようで、同じOpenCore設定で問題なく動作してます。OCLPのおかげでWi-Fiも動くようになったので、Sequoiaリリース日には、すぐに移行しようと考えてます。

macOS Sequoia 15 Beta 8をインストール

Fri, 30 Aug 2024 14:25:42 +0900

macOS Sequoia 15のDeveloper Beta 8が2024/8/29に公開されていました。ビルドは24A5331bです。前回のDeveloper Beta 7に引き続き、このDeveloper Beta 8も自作PCにインストールしてみました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.6.1を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 8インストーラを入手

今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Betaを選ぶとBeta 6が、Developer Betaを選ぶとBeta 8がダウンロードできるようになります。

Screenshot

softwareupdateコマンドで確認すると、どちらを選んでもビルド番号は24A5331bで、同じもののようです。以下では単にBeta 8と書くことにします。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14086413KiB, Build: 24A5331b, Deferred: NO
（以下略）

softwareupdateコマンドでVersion 15.0のダウンロードを指定すると、Beta 8をダウンロードできました。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 25.0%

Installingの数値が100%になると、表示がInstall finished successfullyに変化し、終了します。すると、「アプリケーション」の中に、Install macOS Sequoia Beta.appというインストーラが出来上がってました。

Screenshot

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.1で、macOS 14.6.1で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。

Installer

この後は、通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。

このSSDには、前回インストールしたBeta版が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

インストールの準備が終わると、再起動を促す表示が現れます。

Restart Your Mac

この先3回再起動し、最初はmacOS Installerというボリュームから起動し、次回以降はインストール先に指定したボリュームから起動しました。

動作確認

この先、無事にmacOS Sequoiaが動作しました。前回同様、Radeon RX 6600のDP端子にも画像が出ました。日本語変換のインラインインタフェースも前回同様に正常動作しました。

About This Mac

これは仕方ないことですが、WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

WiFi

まとめ

macOS Sequoia Developer Beta 8を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。

macOS Sequoia 15 Beta 7をインストール

Sat, 24 Aug 2024 18:02:30 +0900

macOS Sequoia 15のDeveloper Beta 7が2024/8/21に公開されていました。ビルドは24A5327aです。前回のDeveloper Beta 6に引き続き、このDeveloper Beta 7も自作PCにインストールしてみました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.6.1を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 7インストーラを入手

今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Betaを選ぶとBeta 5が、Developer Betaを選ぶとBeta 7がダウンロードできるようになります。

Screenshot: Download Beta

softwareupdateコマンドで確認すると、どちらを選んでもビルド番号は24A5327aで、同じもののようです。以下では単にBeta 7と書くことにします。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14086413KiB, Build: 24A5327a, Deferred: NO
（以下略）

softwareupdateコマンドでVersion 15.0のダウンロードを指定すると、Beta 7をダウンロードできました。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 13.0%

Screenshot

インストールする

Installer

このSSDには、前回インストールしたBeta 6が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

インストールの準備が終わると、再起動を促す表示が現れます。

Restart Your Mac

この先、2回再起動し、いずれもmacOS Installerというボリュームから起動しました。

動作確認

DPから映像が出る

この先、無事にmacOS Sequoiaが動作しました。今回から、Radeon RX 6600のDP端子に画像が出るようになりました！今までのようにHDMI端子に切り替える必要はありませんでした。

Screenshot

インラインでの日本語変換

日本語変換のインタフェースにも進展がありました。今までは、メモアプリなどの一部のアプリでしかインラインでの変換ができませんでした。Safariで文章を入力すると、確定するまで表示されない状態でした。これが改善されて、正常に日本語入力できるようになりました。

そのほか

WiFi

まとめ

macOS Sequoia Developer Beta 7を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。ディスプレイポートからの映像出力ができるようになり、日本語入力のインタフェースも完璧になりました。使い込んでいないので、動作しない機能があるのかもしれませんが、すぐに移行しても問題ない気もします。

OpenCore 1.0.0 から1.0.1に更新

Thu, 22 Aug 2024 11:50:56 +0900

OpenCoreの1.0.1が公開されていたので1.0.0からアップデートしました。config.plistに追加された項目はありません。なので1.0.0 のconfig.plistそのままでも動きます。

1.0.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。Sequoia対応に関しても記述はありませんが、手元の環境ではSequoiaベータ版が問題なく起動できているので、大きな問題は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.1とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.6.1
OpenCore Legacy Patcher 1.5.0 (WiFi対応のため)

今回のタイミングでAppleALC.kext, Lilu.kext, RestrictEvents.kext, VirtualSMC.kext, WhateverGreen.kextがアップデートされてましたので、これも最新にしました。

.efiファイルを差し替える

BOOT/BOOTX64.efi
OC/OpenCore.efi
OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。
OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

比較した結果、新たにsample.plistに追加された項目はありませんでした。なので、今まで動作していたのであれば、古いconfig.plistのままでも、変更なしで起動します。

macOS Sequoia 15 Beta 6をインストール

Thu, 22 Aug 2024 10:49:44 +0900

macOS Sequoia 15のDeveloper Beta 6が2024/8/13に公開されていました。Public Beta 4に相当するベータ版のようです。前回のDeveloper Beta 4に引き続き、このDeveloper Beta 6も自作PCにインストールしてみました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.6.1を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 6インストーラを入手

今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Beta, Developer Beta, 15.1 Developer Betaの選択肢がありますが、どれを選んでも、この先でダウンロードされるベータ版は同じでした。

Screenshot: Download Beta

今回はPublic Betaを選んでみたところ、macOS Sequoia 15 Beta 5というアップデートが現れました。

Screenshot: Public Beta 5

Developer Betaを選ぶと、今度はmacOS Sequoia 15 Beta 7というアップデートが現れます。でもsoftwareupdateで調べたところ、どちらも同じビルド番号24A5320aでした。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14086413KiB, Build: 24A5320a, Deferred: NO
（以下略）

これはDeveloper Beta 6もしくはPublic Beta 4に相当するもののようです。Developer Beta 7 もしくはPublic Beta 5 は予告だけで、まだ用意されていないのかもしれません。以下ではDeveloper Beta 6を単にBeta 6と書くことにします。

softwareupdateコマンドでVersion 15.0を指定すると、Beta 6をダウンロードできます。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 13.0%

Installingの数値が100%になると、表示がInstall finished successfullyに変化し、終了します。すると、「アプリケーション」の中に、Install macOS Sequoia Beta.appというインストーラが出来上がってました。どういうわけかアプリ名が英語に戻ってました。

Screenshot

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.6.1で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。これも英語表示に戻りました。

Installer

このSSDには、前回インストールしたBeta 4が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

インストールの準備が終わると、再起動を促す表示（これも英語に戻りました）が現れます。

Restart Your Mac

この先、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況は今までのBeta版と同じでした。HDMI端子には映像が出ます。デフォルトの壁紙が、セコイアの森に変わってました。

About This Mac

WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

WiFi

まとめ

macOS Sequoia Developer Beta 6を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。壁紙がセコイアの森に変更されていました。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。

macOS Sonoma 14.6.1 に更新

Tue, 20 Aug 2024 21:43:36 +0900

macOS Sonoma 14.6.1がリリース（2024/8/8）されていたので、14.6から更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.64GBです。

Screenshot: software update

「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23G93でした。

Screenshot: About This Mac

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、無事Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.6から14.6.1にアップデートしました。今まで通り、安定して動作しています。

macOS Sonoma 14.6 に更新

Sat, 03 Aug 2024 23:14:28 +0900

macOS Sonoma 14.6がリリース（2024/7/29）されていたので、14.5から更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.64GBです。

Update 14.6

「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23G80でした。

About this Mac.

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、無事Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.5から14.6にアップデートしました。今まで通り、安定して動作しています。

macOS Sequoia 15 Beta 4をインストール

Mon, 29 Jul 2024 12:51:03 +0900

macOS Sequoia 15のDeveloper Beta 4が2024/07/24に公開されていました。同時に公開されたPublic Beta 2と同じもののようです。Public Beta 1という最初のパブリックベータ版も2024/7/15に公開されていたのですが、これはDeveloper Beta 3とは違うバージョンでした。そこで、前回のDeveloper Beta 3に引き続き、Developer Beta 4も自作PCにインストールしたところ、動作しました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.5を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 4インストーラを入手

今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておきます。今まではDeveloper Betaの項目しかありませんでしたが、今回はPublic Betaの項目も現れていました。どちらを選ぶと良いかわからなかったので、最初は新しく現れたPublic Betaを選んでみました。

すると、macOS Sequoia 15 Beta 2というアップデートが現れます。これはPublic Beta 2という意味のようです。

Public Beta 2

次に今までと同じDeveloper Betaを選んでみると、macOS Sequoia 15 Beta 4が現れます。これはDeveloper Beta 4という意味のようです。

Developer Beta 4

それぞれのバージョンを、softwareupdateで調べたところ、どちらも同じビルド番号24A5298hでした。Public Beta 2とDeveloper Beta 4は同じもののようです。ややこしいので、ここでは単にBeta 4として紹介します。

% softwareupdate --list-full-installers 
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14328272KiB, Build: 24A5298h, Deferred: NO
（以下略）

softwareupdateコマンドでVersion 15.0を指定すると、これをダウンロードできます。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Installing: 13.0%

Installingの数値が100%になると、表示がInstall finished successfullyに変化し、終了します。すると、「アプリケーション」の中に、macOS Sequoiaベータ版インストール.appというインストーラが出来上がってました。サイズは少し増えて14.72GBです。

インストーラー

今までは、名称がInstall macOS Sequoia Beta.appだったものが、日本語になりました。だんだん日本語対応が進んでいるようです。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のmacOS Sequoiaベータ版インストール.appを開くと、インストーラウィンドウが現れました。今までは英語表示でしたが、これも日本語に変わってました。

インストーラー

この後は、通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。ここの表示も日本語化されていました。

インストーラ

このSSDには、前回インストールしたBeta 3が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

再起動の案内も日本語化されてました。

installer

この先、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況はBeta 1と3と同じでした。HDMI端子には映像が出ます。

About this Mac

WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

まとめ

macOS Sequoia Beta 4を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。日本語表示される部分が増えて、日本語対応が進んでいる様子です。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。

macOS Sequoia 15 Beta 3をインストール

Mon, 15 Jul 2024 14:10:08 +0900

macOS Sequoia 15のBeta 3が2024/07/10に公開されていました。Beta 2も2024/6/24に公開されていたようです。そこで、Beta 1に引き続き、Beta 3も自作PCにインストールしたところ、動作しました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonoma 14.5を起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作します。

Beta 3インストーラを入手

今回も、Beta 1と同様に、最初は以下のサイトのお世話になりました。

macOS Sequoia Full Installer Database. Download Directly from Apple!

ここには、https://swcdn.apple.com/というアップルのサイトのダウンロード用URLが紹介されています。ここにBeta 3インストーラへのリンクがありました。ダウンロードすると、InstallAssistant.pkgというファイルが出来上がります。

これを開きインストールすると、Install macOS Sequoia Beta.appというアプリが、「アプリケーション」の中に作られます。

フォーラムで教えていただいた内容によると、ターミナルからsoftwareupdateコマンドを使ってダウンロードすることも可能のようです。これも試してみました。

まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておきます。

Screenshot

次に、ターミナルからsoftwareupdate --list-full-installersコマンドを打ち、ベータ版がダウンロード可能なことを確認します。

% softwareupdate --list-full-installers
Finding available software
Software Update found the following full installers:
* Title: macOS Sequoia Beta, Version: 15.0, Size: 14112733KiB, Build: 24A5289g, Deferred: NO
* Title: macOS Sonoma, Version: 14.5, Size: 13353373KiB, Build: 23F79, Deferred: NO
* Title: macOS Sonoma, Version: 14.4.1, Size: 13298513KiB, Build: 23E224, Deferred: NO
* Title: macOS Ventura, Version: 13.6.7, Size: 11924125KiB, Build: 22G720, Deferred: NO
* Title: macOS Ventura, Version: 13.6.6, Size: 11917983KiB, Build: 22G630, Deferred: NO
* Title: macOS Monterey, Version: 12.7.5, Size: 12116686KiB, Build: 21H1222, Deferred: NO
* Title: macOS Monterey, Version: 12.7.4, Size: 12117810KiB, Build: 21H1123, Deferred: NO
* Title: macOS Big Sur, Version: 11.7.10, Size: 12125478KiB, Build: 20G1427, Deferred: NO
* Title: macOS Catalina, Version: 10.15.7, Size: 8055650KiB, Build: 19H15, Deferred: NO
* Title: macOS Catalina, Version: 10.15.7, Size: 8055522KiB, Build: 19H2, Deferred: NO
* Title: macOS Catalina, Version: 10.15.6, Size: 8055450KiB, Build: 19G2021, Deferred: NO
* Title: macOS Mojave, Version: 10.14.6, Size: 5896894KiB, Build: 18G103, Deferred: NO
* Title: macOS High Sierra, Version: 10.13.6, Size: 5099306KiB, Build: 17G66, Deferred: NO

次に、softwareupdate --fetch-full-installer --full-installer-version 15.0コマンドで、バージョンを指定してダウンロードします。

% softwareupdate --fetch-full-installer --full-installer-version 15.0
Scanning for 15.0 installer
Install finished successfully

この結果、アプリケーションフォルダにインストーラがダウンロードされました。

Sequoiaアイコン登場

「アプリケーション」の中に作られた、Install macOS Sequoia Beta.appのサイズは14.5GBと、Beta 1から少しだけ増えてました。何よりもアイコンが新しくなってます。Sequoiaのアイコンが決定したのかと思います。

Beta 3

「パッケージの内容」を見ると、

Beta 3

Contents/Resources の中に、ProductPageIcon.icnsというファイルが見つかりました。

Sequoia Icon file

これがSequoiaのアイコンのようです。これをプレビュー.appで開くと、複数サイズのアイコンPNGデータを得ることができます。アイコンのデザインはSonomaの方が凝っていて良かった気もします・・・

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。

インストーラを開くと、あとは通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。

このSSDには、前回インストールしたBeta 1が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

インストールでは、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況はBeta 1の時と同じでした。HDMI端子には映像が出ます。

OpenCoreの最新版があれば、Sequoiaも問題ないようです。

WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

まとめ

macOS SequoiaのBeta 3を動かして、OpenCoreの最新版で動作することを確認しました。アイコンが、Sequoiaのものに更新されました。Sonomaを起動しているOpenCore設定と全く同じ設定で、動作します。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。

Sequoia

Tue, 11 Jun 2024 23:50:44 +0900

macOS Sequoia（セコイア）15.0 をhackintoshで使う上で有用と思われる情報をメモしておきます。

機種設定

Sequoiaの対応Intel Macの機種IDは以下です。

iMac19,1 iMac19,2
iMac20,1 iMac20,2
iMacPro1,1
MacBookAir9,1
MacBookPro15,1 MacBookPro15,2 MacBookPro15,3 MacBookPro15,4 MacBookPro16,1 MacBookPro16,2 MacBookPro16,3 MacBookPro16,4
Macmini8,1
MacPro7,1

macOS SonomaでサポートされていたMacは、すべてSequoiaでもサポートされるようです。

ダウンロード方法

いろいろあります。

「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると入手できます。（下図。自動的にアップデート開始するので非推奨）
https://developer.apple.com/macos/ からもダウンロード可能です。（Apple Silicon版のみらしいので非推奨）
こちらのサイトで、ダウンロード用URLが紹介されています。このURLは、https://swcdn.apple.com/ というサーバーで、Apple公式ソフトウェアアップデートが使うサイトのようです。（簡単だけどダウンロード時間がかかる）
記事のコメントから、Mistというツールを教えていただきました。各種macOSをダウンロードして、インストーラを作るユーティリティです。次の項目の方法をGUI画面で自動化しているのだと思われます。
ターミナルからsoftwareupdateコマンドを使います。「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておき（下図）、

softwareupdate --list-full-installers

コマンドで目当てのベータ版がダウンロード可能なことを確認し、それが15.0ならば、

softwareupdate --fetch-full-installer --full-installer-version 15.0

コマンドでダウンロードできます。アプリケーションフォルダにインストーラが作られます。

Broadcom WiFi対策

Sonomaと同様、BroadcomのWi-Fi (BCM94360NG など) はサポートされません。そこでOCLPが必要です。OCLP 2.0.0からSequoiaに対応したので、これを使ってWi-Fiを有効化します。

OpenCore Legacy PatcherがSequoiaに対応

動作報告

以下はSequoiaの動作記録です。ASRock Z690 Steel Legend、Intel 13900KF、AMD Radeon RX 6600、OpenCore 1.0.1、OCLP 2.0.1で動作してます。

macOS Sequoia を自作PCにインストール

EFIファイル類

ここで使ったOpenCoreの設定 (EFIのファイル類) を、こちらに置いておきました。参考になさってください。（シリアル番号などは適当に書いてありますのでこちらを参考にしてconfig.plistを書き換えてください）

リリースの経緯

2024/6/10: 開発者向けベータ版 Beta 1 の無償配布開始
その後のベータ版：
- 2024/6/24: Beta 2
- 2024/7/10: Beta 3
- 2024/7/15: Public Beta 1
- 2024/7/24: Beta 4 (Public Beta 2)
- 2024/8/6: Beta 5 (Public Beta 3)
- 2024/8/13: Beta 6 (Public Beta 4)
- 2024/8/21: Beta 7 (Public Beta 5)
- 2024/8/29: Beta 8 (Public Beta 6)
2024/9/17 (JST) ：正式版 macOS 15.0 Sequoia 配布開始

macOS Sequoia Beta 1を第13世代Intel CPUで動かす

Tue, 11 Jun 2024 20:00:36 +0900

2024/06/10のWWDC24キーノートでmacOS Sequoiaが発表され、ベータ版が無償公開されました。さっそく自作PCにインストールして動作することを確認しました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonomaを起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作するようで安心しました。

ベータ版インストーラを入手

開発ベータ版は無償で配布されています。開発ベータ版を入手するための方法はいくつかありますが、一番簡単なのは、「システム設定…」「一般」「ソフトウェアアップデート」で、「ベータアップデート」から「macOS Sequoia Developer Beta」を選択することです。

すると、ベータアップデートにmacOS Sequoia Developer Betaの項目が現れます。

ただ、この方式で続けると、起動中のmacOSをベータ版に入れ替えてアップデートされます。使用中のSSDではなくて、予備のSSDにインストールしたかったので、macOSのインストーラを入手したいと思いました。

インストーラ単体は、おそらくはdeveloper.apple.comからダウンロードできると思います。ただ、Sonomaの時はIntel用を入手できなかったので、これを試すことなく、前回と同様に、以下のサイトのお世話になりました。

macOS Sequoia Full Installer Database. Download Directly from Apple!

ここには、https://swcdn.apple.com/というアップルのサイトのダウンロード用URLが紹介されています。ダウンロードすると、InstallAssistant.pkgというファイルが出来上がります。

これを開くと、Install macOS 15 beta.appというアプリが、「アプリケーション」の中に作られます。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のInstall macOS 15 beta.appを開くと、インストーラウィンドウが現れました。

アイコンはSonomaの流用です。Sonomaのbetaの時と同様、この後のバージョンアップでSequoiaのアイコンが採用されるはずです。

このSSDはフォーマットした直後なので、そのESPにOpenCoreなどが入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。

画面が出ない

この後、インストールがほぼ終了し、グラフィックスカードに制御が切り替わるタイミングで、画面が真っ黒になりました。しばらく待っていたところボイスオーバーの案内がスピーカーから流れました。音が出るように用意しておくことは重要ですね。画面が出ていないだけで、インストールは成功しているようでした。

画面が出ない症状は、1年前にSonomaの開発ベータをインストールしたときにも発生していました。なので、同様に試したところ、グラフィックスカードのRadeon RX 6600のHDMI端子には映像が出ているようでした。今まではDP端子を接続していたのですが、そちらはブラックスクリーンになったようです。ということで、ディスプレイをHDMI端子に接続すれば、問題なくmacOSのインストールを進めることができました。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。OpenCoreの最新版があれば、Sequoiaも問題ないようです。

全コアが動作してます。

ただ、Sonomaの時と同様にWiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。

まとめ

macOS Sequoiaの開発ベータ版を動かして、OpenCoreの最新版で動作することを確認しました。Sonomaを起動しているOpenCore設定と全く同じ設定で、動作します。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調に進みそうなので安心しました。

macOS Sonoma 14.5 に更新

Mon, 27 May 2024 01:09:13 +0900

macOS Sonoma 14.5がリリース（2024/5/13）されていたので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。OCLPは、マザボのE key M.2ソケットに取り付けたWiFiモジュールBCM94360NGを動作させるために使用してます。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.6GBです。

いつもはアップデートの説明が表示されるのに、今回は白紙でした。「今すぐ再起動」というボタンが表示されていて、すでにダウンロードは終了している様子です。なので今更ダウンロードサイズを節約する必要もなさそうなので、今回はOCLPのパッチを外さないまま続けました。「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23F79でした。

この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。

この結果、無事Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.4.1から14.5にアップデートしました。今まで通り、安定して動作しています。

OpenCore 0.9.9 から1.0.0に更新

Sun, 26 May 2024 23:37:00 +0900

OpenCoreの1.0.0が公開されていたので0.9.9からアップデートしました。config.plistに追加された項目はありません。なので0.9.9 のconfig.plistそのままでも動きます。

1.0.0をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。とはいえ、バージョンがとうとう1.0.0に到達しました。

Releases · acidanthera/OpenCorePkg

OpenCore 1.0.0とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.4.1
OpenCore Legacy Patcher 1.4.3 (WiFi対応のため)

今回のタイミングでAppleALC.kextがアップデートされてましたので、これも最新にしました。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

macOS Sonoma 14.4.1 に更新

Sat, 30 Mar 2024 18:21:00 +0900

macOS Sonoma 14.4.1がリリースされた（2024/3/25）ので、更新しました。一時はWi-Fiが動作しなくなってしまいましたが、kextを更新して解決しました。このほか、特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。Wi-Fiは、マザボのE key M.2ソケットに取り付けたBCM94360NGです。

追記：初稿ではWi-Fiが不調でしたが、kext入れ替えで復活しました。2024/03/31

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。マイナーな機能拡張と、バグ修正、セキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.6GBです。

今回も、差分だけのダウンロードをしたいと思い、OCLPのパッチを外しました。OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。なお、OCLPにも新しいバージョン1.4.2が来ていたので、アップデートしました。14.4.1に対応するためには、1.4.2を使ってくださいとのことでした。

この後、再起動するとWi-Fiが使えなくなってました。Wi-Fi用パッチを外したので当然の現象です。改めて、更新通知を確認すると、サイズが2.01GBになってました。少し前に話題になっていた、USBハブが認識されない問題が解決されているようです。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23E224でした。

Wi-Fiが復活しない

この後、OCLPのPost-Install Root Patchを当て直しました。メッセージには、Modern Wirelessに対応するためのネットワークパッチが当てられると表示されています。

パッチを当てて、再起動しましたが、しかしながらWi-Fiは動作しませんでした。今までの様子と異なり、メニューバーのWi-Fiアイコンに!マークが出ています。

ちなみに使用しているWi-Fiモジュールは、マザーボードのE key M.2ソケットに取り付けたBCM94360NGです。

IOSkywalkFamily.kextを更新する

そこで、Wi-Fiを有効化した時の手順：

SonomaでBroadcom Wi-Fiを有効にする

を見直しました。その結果、追加していた2個のkext：

のうち、IOSkywalkFamily.kextが、3週間前に更新されていることがわかりました。Sonoma 14.4のベータに合わせて、更新されていたようです。使用中のkextを、最新のものに置き換えることで、無事、Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.3.1から14.4.1にアップデートしました。Broadcom社のWi-Fiが動作しない問題が発生しましたが、対応するkextを更新したところ解決しました。今まで通り、安定して動作しています。

OpenCore 0.9.8 から0.9.9に更新

Thu, 28 Mar 2024 11:40:40 +0900

OpenCoreの0.9.9が公開されていたので0.9.8からアップデートしました。config.plistに追加された項目はありません。なので0.9.8 のconfig.plistそのままでも動きます。

0.9.9をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。とうとう0.9.9まできました。次はいよいよ1.0.0なのでしょうか？

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.9とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.3.1
OpenCore Legacy Patcher 1.4.1 (WiFi対応のため)

今回のタイミングでkextのアップデートはありませんでした。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

macOS Sonoma 14.3.1 に更新

Fri, 09 Feb 2024 22:33:15 +0900

macOS Sonoma 14.3.1がリリースされた（2024/2/9）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来る

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。詳細情報をクリックしたところ、マイナーな機能拡張と、バグ修正、セキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.37GBです。

今回も、差分だけのダウンロードをしたいと思い、OCLPのパッチを外しました。OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。

この後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが526.5MBになってました。また、アップデートの内容がより具体的に説明されるようになりました。タイプ入力中のテキスト表示の不具合を直したようです。その不具合には遭遇してなかったので、よくわかりません。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23D60でした。

この後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。

まとめ

macOS Sonoma 14.3から14.3.1にアップデートしました。今回も、OCLPのパッチを一旦外すことで、差分でのアップデートを行いました。アップデート後に、再びOCLPのパッチを当てました。

OpenCore 0.9.7 から0.9.8に更新

Fri, 09 Feb 2024 21:33:37 +0900

OpenCoreの0.9.8が公開されていたので0.9.7からアップデートしました。config.plistに追加された項目はありません。なので0.9.7 のconfig.plistそのままでも動きます。

0.9.8をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.8とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.3
OpenCore Legacy Patcher 1.3.0 (WiFi対応のため)

今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.7の時のままです。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目はありませんでした。なので、今まで動作していたのであれば、古いconfig.plistのままでも、変更なしで起動します。

macOS Sonoma 14.3 に更新

Tue, 23 Jan 2024 13:27:51 +0900

macOS Sonoma 14.3がリリースされた（2024/1/22）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来てた

この後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが935.9MBになってました。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23D56でした。

この後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。

まとめ

macOS Sonoma 14.2.1から14.3にアップデートしました。今回も、OCLPのパッチを一旦外すことで、差分でのアップデートを行いました。アップデート後に、再びOCLPのパッチを当てました。

macOS Sonoma 14.2.1 に更新

Thu, 21 Dec 2023 17:10:58 +0900

macOS Sonoma 14.2.1がリリースされた（2023/12/19）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来てた

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.36GBです。

前回のアップデートの記事のコメントで、アップデートのサイズがフルサイズなのは、パッチが当たっているからなので、OCLPのパッチを外すと差分でアップデートできると教えていただきました。今回はそれを試しました。それで、OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。

この後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが421.8MBになってました。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。

更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23C71でした。

この後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。

まとめ

macOS Sonoma 14.2から14.2.1にアップデートしました。OCLPでパッチを当てて以来、アップデーターがmacOS本体くらいのサイズだったのですが、パッチを一旦外すことで、差分でのアップデートになりました。再起動1回分の手間がかかりますが、ダウンロード時間が短くなります。今後も一旦パッチを外してからアップデート作業したいと思います。

macOS Sonoma 14.2 に更新

Tue, 12 Dec 2023 17:15:31 +0900

macOS Sonoma 14.2がリリースされた（2023/12/12）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来てた

「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。

詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.36GBです。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23C64でした。

OCLPを当て直す

これでmacOS 14.2が起動しました。でもOCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。

そこで、OCLPの新しいバージョン1.3.0を起動しました。

Post-Install Root Patchをクリックしてパッチを当てなおしたところ、Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.1.2から14.2にアップデートしました。アップデート通知画面でボタンクリックすることで、自動的にアップデートできました。またWi-Fiを有効化するために、アップデート後に再びOCLPを当てました。

OpenCore 0.9.5 から0.9.6に更新

Tue, 12 Dec 2023 17:03:41 +0900

OpenCoreの0.9.6が公開されていたので0.9.5からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.5 のconfig.plistそのままでも動きます。

0.9.6をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.6とmacOS Sonomaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K
Radeon RX 6600 XT
macOS Sonoma 14.2
OpenCore Legacy Patcher 1.3.0 (WiFi対応のため)

今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.5の時のままです。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

Booter/QuirksにFixupAppleEfiImagesが追加されていました。bool型データで、デフォルトはfalseです。macOS 10.4から10.12のboot.efiへのパッチとのことです。最新macOSしか使わないので、デフォルトのままfalseにしておきました。

今まで動作していたのであれば、追加された項目はデフォルトで問題無いようですので、古いconfig.plistのままでも、変更なしで起動します。

macOS Sonoma 14.1.2 に更新

Tue, 05 Dec 2023 22:35:56 +0900

macOS Sonoma 14.1.2がリリースされた（2023/11/30）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知が来てた

前回、更新通知が来るように設定しましたので、今回は、「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。

詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ12.89GBです。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B92でした。

OCLPを当て直す

これでmacOS 14.1.2が起動しました。でもOCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。

そこで、OCLPからPost-Installを実行したところ、新しいバージョン1.2.1の案内が表示されました。

Download and Installボタンをクリックして1.2.1をインストールしました。

Post-Install Root Patchをクリックしてパッチを当てなおしたところ、Wi-Fiが復活しました。

まとめ

macOS Sonoma 14.1.1から14.1.2にアップデートしました。アップデートの通知画面から、ボタンクリックで自動的にアップデートしてくれました。またWi-Fiを有効化するために、アップデート後に再びOCLPを当てました。

macOS Sonoma 14.1.1 に更新

Wed, 08 Nov 2023 17:42:22 +0900

本日（2023/11/8）macOS Sonoma 14.1.1がリリースされたので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

更新通知を有効にする

macOS Sonoma 14.1.1がリリースされたはずなのですが、Sonomaになって以来、「システム設定」「一般」「ソフトウェアアップデート」に更新の表示が出なくなってました。

その記事へのコメントで「RestrictEvents.kextを入れてsbvmmを設定すればアップデートが表示されますよ」と教えていただいたのでそれを試しました。RestrictEventsの設定については、こちらをご覧ください。

RestrictEvents.kextで更新通知を有効化する

その結果、アップデートの通知が来るようになりました。これで今まで通り、アップデートできそうです。

詳細情報をクリックしたところ、Sonomaそのものの紹介しか書いてありませんでした。0.0.1のマイナーアップデートなので、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ12.89GBです。

ここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B81でした。

OCLPを当て直す

これでmacOS 14.1.1が起動しました。しかし、OCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。

そこで、OCLPからPost-Installを実行し、パッチを当て直しました。これでWi-Fiが復活しました。

まとめ

macOS Sonoma 14.1から14.1.1にアップデートしました。RestrictEvents.kextを使ったので、今まで通り「システム設定」にアップデートの通知が来るようになりました。Wi-Fiを有効化するために、アップデート後に再びOCLPを当てました。

macOS Sonoma 14.1 に更新

Thu, 26 Oct 2023 18:10:22 +0900

本日（2023/10/26）macOS Sonoma 14.1がリリースされたので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。

アップデートが来ない

macOS Sonoma 14.1がリリースされたのですが、「システム設定」「一般」「ソフトウェアアップデート」に表示はありません。

Sonomaになったためか、それともOCLPでパッチを当てたためなのか、アップデート案内が来なくなってしまったようです。

OCLPで14.1をダウンロード

OCLPには、macOSのダウンロード機能があったのでそれを使うことにしました。OCLPメインメニューの左下のCreate macOS Installerを選びます。

この中から、macOS 14.1 Sonomaのダウンロードが可能でした。

差分ではないので、12.9GBあり、ダウンロードに20分程度かかるようです。

ダウンロードが終わると、Applicationsにインストーラが保存されています。

これを開いて、macOSのバージョンアップをしました。

この後、自動的に再起動しました。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B74でした。

OCLPを当て直す

これでmacOS 14.1が起動しました。しかし、OCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。

この状態は、OCLPにもわかっているようで、再度パッチを当てることを促すメッセージが出ました。

そこで、パッチを当て直しました。これでWi-Fiが復活しました。

まとめ

macOS Sonoma 14.0から14.1にアップデートしました。OCLPを使って以来初めてのマイナーアップデートなので、今までと少し違ってました。まずは、「システム設定」にアップデートの通知が来なくなってました。またアップデート後に、再びOCLPを当てる必要がありました。それ以外は、今までのマイナーアップデートと同じく、問題なくアップデートできて動作しました。

OpenCore Legacy PatcherがSonomaに対応

Tue, 03 Oct 2023 16:17:05 +0900

前回の記事では、Sonomaになって使えなくなったBroadcomのWi-Fiを、OpenCore Legacy Patcher (OCLP) のNightly Buildを使って対応させました。

SonomaでBroadcom Wi-Fiを有効にする

その後、OCLPが更新されてSonomaに正式対応したので、それを使って再びパッチ当てしました。

OCLPがSonomaに対応

OCLPが Ver. 1.0.0 になってSonomaに対応しました。前回の記事で使用した0.6.9を起動したところ、バージョンアップのお知らせが表示されました。

これで正式にSonomaに対応したようです。リリースページからダウンロードできます。

Releases · dortania/OpenCore-Legacy-Patcher

Download and installボタンを押すと更新されました。

起動すると1.0.0になってます。

Post-Install Root Patchを選ぶと、前回同様にパッチを当てられます。

メッセージを見ると、macOSのシステム部分にかなりパッチが当たっています。それだけ大変な作業のようです。

1.0.1に更新（追記）

2023年10月4日に、OCLPが1.0.1に更新されていました。

アップデートしてパッチし直しました。特に変化はありません。

まとめ

OCLPの公開版がアップデートされてSonoma対応になりました。Nightly版で、Broadcom Wi-Fi対応のパッチを当てていたので、公開版でパッチし直しました。Config.plistはすでに対応しているので、OCLPを起動してボタンを押すだけで終了します。Wi-Fiを動かし続けるために、これからもOCLPにお世話になります。

SonomaでBroadcom Wi-Fiを有効にする

Sun, 01 Oct 2023 22:15:06 +0900

SonomaでBroadcomのWi-Fiを使えるようにしました。iPhoneとのコピペ（ユニバーサルクリップボード）やAirDropが再び使えるようになりました。

SonomaでWi-Fiが使えない

Sonomaでは、マザーボードのM.2ソケットに取り付けたBroadcom Wi-Fiカード

が動作しませんでした。Bluetooth部分は動作します。これらのBroadcom Wi-Fiを搭載しているMacが全て、Sonomaのサポート対象から外れたためです。Venturaまでは動作し、Sonomaで動作しなくなったチップは以下です。

BCM94350 (BCM94352を含む)
BCM94360
BCM43602
BCM94331
BCM943224

Wi-Fiが使えなくなったマシンは、デスクトップ（Z690マザーボード、13900K、Radeon RX 6600）なので、有線LANがあれば一般的なネット利用には支障ありません。しかしWi-Fiが機能しないと、iPhoneとの連携機能（ユニバーサルクリップボードやHandoffなど）やAirDropが使えないので、なんとかしたいところです。

OCLPで対応する

OpenCore Legacy Patcher（以下ではOCLP）を使用して、Broadcomチップを有効にする方法が以下で説明されていました。

Preliminary support for macOS Sonoma by khronokernel · Pull Request #1077 · d…

OCLPは、新しいmacOSを、サポート対象外の古いMacにインストールするツールです。OpenCoreを利用しています。Macの機種を選択すると自動的に設定してくれるので便利です。Sonomaでサポート外になったBroadcomのWi-Fiを有効にするOCLPが、Nightly Build版で用意されています。公式版は10月2日とのことです。

このSonoma対応の最新版OCLPをHackintoshで使います。上記のページの「Hackintosh Note」という項目に説明があります。本来の使い方ではないので、OpenCoreの設定準備が多少必要です。ちなみにOpenCoreも最新版にすると良いとのことなので、Nightly Build 0.9.6にしました。

OCLPを使ってみる

まずは上記のページからOCLPのNightly Buildを入手しました。直接リンクを公開しないようにと書いてありますので、このページから探してください。Nightly.link: OpenCore-Patcher.app (Sonoma Development)と書いてあるリンクをクリックすると、OpenCore-Pacherのアプリがダウンロードされます。10月2日には公開版が出るそうなので、それまで待っても良いと思います。

実はOCLPを使うのは今回が初めてです。それで、とりあえずダウンロードしたアプリを起動してみました。開いたメインメニューに、いろいろなツールがあって便利そうです。Sonomaのダウンロードも、これを使えばきっと簡単でした。

この中の「Post-Install Root Patch」という項目で、Wi-Fiのパッチが当てられます。「Post-Install Root Patch」をクリックすると、以下のメッセージが現れました。

要するに、

あなたのマシンに対してできることはModern Wirelessのパッチです
でもセキュリティ設定がキツいのでパッチ当てられません

ということです。状況をとても的確に把握してくれているようです。Modern Wirelessというのは、今回のSonomaで使えなくなったBroadcomのチップです。OCLPのプロジェクトでは、Montereyで切り捨てられた古いWi-FiチップをLegacy Wirelessと呼んでいたので、それに対してSonomaで切り捨てられたチップをModernと呼んでいるようです。

OpenCoreの調整

そこで、まずはOpenCoreの設定を整えて、OCLPが動作するようにします。Hackintoshに対して行う先ほどの手順を参考にしました。ちなみに、古いMacに対して行う手順がこちらに説明されています。これも参考にしました。これらに従ってconfigとEFIを調整します。

1. Kextの追加

まずはkextを追加します。必要なkextは、以下の3個です。うち1個は、他のkext/Contents/PlugInsの中に含まれてますので、入手するkextは2個です。

IOSkywalkFamily.kext
IO80211FamilyLegacy.kext
- AirPortBrcmNIC.kext (IO80211FamilyLegacyに含まれてます)

ちなみに古いMac向けのガイドのほうには、このほかにも3個のkextを入れるように書かれてました。それを試みるとカーネルパニックになったり、暗黒画面になりました。上記の3個だけで良いようです。

2. config.plistの変更

次に、config.plistを変更します。まずは、上記の3個のkextが動作するように、Kernel/Addに以下を追加します。Xplistアプリで編集している様子です。

次に、macOSにあるIOSkywalk.kextを停止させます。このために、以下の項目をKernel/Blockに追加します。

さらに、Misc/Securityで、SecureBootModelを無効にします。

また、NVRAM/Addで、boot-argsにamfi=0x80 を追加し、csr-active-configを03080000に設定します。

NVRAM/Deleteに、csr-active-configを追加します。

config.plistの変更は以上です。csr関係の設定は、パッチ作業後は元に戻しても良いのかもしれません。詳しくはこちらの説明をみてください。

OCLPを起動

これでOCLPが使えるようになりました。メインメニューからPost-Install Root Patchを選ぶと、先ほどと違って、以下のように表示されます。

いよいよパッチが当てられるようになったようです。Start Root Patchingを選択すると、rootとして作業するかどうかの確認と、パスワードを求められます。

パスワードを入力すると、パッチ作業が開始されます。

パッチが終了したら、再起動です。

Wi-Fi動作を確認する

再起動したところ、無事、Wi-Fiが動作するようになりました。

Wi-Fiを接続したところ、iPhoneとのユニバーサルクリップボード、Handoff、AirDropなどが動作するようになりました。

まとめ

Sonomaになって使えなくなっていたWi-Fiが、OCLPによって復活しました。その結果iPhoneや他のMacとの連携が再び使えるようになりました。macOSのバージョンアップの時にはいろいろ試練がありますが、それを克服しているコミュニティの皆さんの努力に感謝です。

今回は、M.2 Wi-Fiカード BCM94360NGを使いましたが、も同じ手順で復活するはずです。

SonomaのUSBインストーラを作ってクリーンインストール

Fri, 29 Sep 2023 18:31:35 +0900

macOS Sonoma 14.0が公開されましたので、USBインストーラを作って、クリーンインストールしました。最新版のOpenCore (0.9.5) とkext類でVenturaが動く環境ならば、Sonomaが動作するはずです。

システム構成

日本時間2023/9/27に、macOS Sonoma 14.0 が配布されました。Venturaが配布されたのは去年の10月25日でしたので、例年より1月ほど早いです。インストール先のマシンは、以下で、Z690マザーボードに13900Kを搭載しています。グラフィックスはRadeon RX 6600です。ブートローダはOpenCore 0.9.5でkext類は最新にしてあります。

Raptor Lake-S 13900KFの32コアをmacOSで使う

直近まで使っていたmacOSはVentura 13.5.2 (22G91)です。現在、13.6が配布されていますが、それをスキップして14.0に移行しました。

アップデートできない

Venturaの「システム設定」に「ソフトウェアアップデートがあります」というメッセージが出ていました。これを選択すると、macOS Sonoma 14.0の説明が表示されます。

ここで「今すぐアップデート」を選ぶと、ダウンロードが開始します。でもしばらくすると、以下のようなメッセージが出て中断してしまいます。

Public Betaの時と同様な症状です。Public BetaはApple Silicon版との関係でエラーが出ているのかと思ったのですが、他の要因かもしれません。

裏口からダウンロード

それで結局、こちらのサイトのリンク情報からインストーラをダウンロードしました。ダウンロード先はhttps://swcdn.apple.com/というサーバで、Apple公式ソフトウェアアップデートが使うサイトのようです。

InstallAssistant.pkgというファイルがダウンロードされました。これを開くと、デフォルトで/Applicationsフォルダに、macOSインストーラが出来上がります。

ということで、めでたくmacOS Sonomaインストールを入手できました。

クリーンインストールする

現用のVenturaに上書きインストールしても良いかとは思いますが、せっかくの年に一度のメジャーアップデートです。現在の起動ディスクであるM.2 SSDの内容を綺麗さっぱりと全消去して、クリーンインストールしようと思います。実は、ホームディレクトリは、同じSSDの別のAPFSボリュームに作ってあるので、起動M.2 SSDを消去してもそれほど面倒なことにはなりません。そこで次の手順でアップデートを進めます。

USBメモリを用意してSonomaインストールUSBを作る
USBメモリのESPに現在のESPをコピーして起動できるようにする
USBメモリーからインストーラを起動する
インストーラからディスクユーティリティを起動し、M.2 SSDを消去する
インストーラからSonomaをインストールする

1. SonomaインストールUSBを作る

インストーラ用のUSBメモリを用意します。必要な容量は13.5GBですが、今回は32GBのUSB 3.0メモリーを用意しました。このUSBメモリーをディスクユーティリティ.appを使って初期化します。USBメモリを選択して、消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。ここでAPFSを選んでも良さそうな気もしますが、以前のバージョンのcreateinstallmediaコマンドではエラーが出ました。今回は試していませんが、Mac OS拡張（ジャーナリング）にしておくのが無難です。

次に、SonomaインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもSonomaをインストールできるUSBメモリになります。ターミナルを使用して、Sonomaインストーラの中のContents/Resourcesに移動するとcreateinstallmediaというファイルがあります。そこで以下のコマンドを入力します。（下の例は、インストーラが/Applicationsにある場合です）

$ cd /Applications/Install\ macOS\ Sonoma.app/Contents/Resources/
% sudo ./createinstallmedia --volume /Volumes/USB/
Password: 
Ready to start. 
To continue we need to erase the volume at /Volumes/USB. 
If you wish to continue type (Y) then press return: y 
Erasing disk: 0%... 10%... 20%... 30%... 100% 
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100% 
Making disk bootable... 
Copying boot files... 
Install media now available at "/Volumes/Install macOS Sonoma"

パスワード入力と、確認のyを押すと、いろいろ進捗して終了します。これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。

2. USBメモリのESPに現用のESPをコピーする

この先の操作でも、稼働しているESPは残るので、それから起動してUSBメモリを起動できるはずです。でも念のためにメモリでも起動できるようにしておきたいと思います。そこでインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。

それぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ&ドロップすれば良いです。この先、Venturaの起動ボリュームは消去しますので、他にも必要なデータがありましたらバックアップしておきます。ホームディレクトリは別ボリュームですし、インストールしているソフトウェアの大半はクラウドから再度ダウンロードしても良いので、バックアップは適当です。

3. USBメモリーからインストーラを起動する

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにInstall macOS Sonomaというボリュームが見えるはずです。

ただ、OpenCoreでデフォルト通りの設定をしていると、起動ボリュームの一覧にこのUSBメモリが現れないかもしれないです。それはconfig.plistのMisc, Security, ScanPolicyのデフォルト設定が原因です。これのデフォルト値（Sample.plistに書いてある値も同じく）は、0x010F0103 (10進数では17760515) です。この設定のまま使っている場合、2重の理由で、今回のUSBメモリが起動ボリューム候補に現れません。

まず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。
また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。

なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はXplistを使って変更している様子です。

これで起動項目にUSBメモリのインストーラが現れるようになります。Sonomaアイコンのボリュームが、USBメモリーです。このInstall macOS Sonomaを選択して起動します。

4. インストール先ボリュームを消去する

USBメモリから起動すると、下のようなメニューが現れます。

ここでディスクユーティリティを選んで、インストール先ボリュームを綺麗さっぱりフォーマットしました。インストール先のAPFSボリュームグループを選択し、名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。

ユーザのホームディレクトリは、上記のhomeという場所に置いています。Macintosh HDというボリュームは、macOS本体とアプリケーションが使ってます。なのでこちらを消去しても、大半のデータはそのまま残せます。

5. Sonomaをインストールする

Disk Utilityを閉じると、またメニューに戻ります。次にmacOS Sonomaインストールを選択します。するとおなじみのmacOSインストーラが起動します。後は、いつものようにインストールを進めていくだけです。

インストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。この後数分で再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。

何度かの再起動の後で、インストール先ドライブにつけた名前 (ここではMacintosh HD) の選択肢が現れ、選択されています。これで起動します。

さらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。あとはいつものように、設定を行ないます。

インストール終了したあと、このMacについてを確認しました。

これで、BIOS起動設定を内蔵SSDにすれば、今まで通り起動します。上の手順では、APFSボリュームグループをフォーマットしてたのでESPの内容は無事でした。ドライブ全体をフォーマットするとESPの内容も消えてしまいます。その場合は、USBメモリのESPの内容を、内蔵SSDに書き戻しておきます。

まとめ

OpenCoreで起動しているZ690マシンにSonomaをクリーンインストールしました。Wi-Fi以外は今のところ問題なく動作しています。ベータ版の時から、日本語と英語の入力モードの切り替えが高速になりわかりやすくなったのは、すごく良いです。

追記：Venturaで使用できてたWi-Fiが使えなくなった問題に対しては、OCLPで対応可能です。詳しくはこちらをご覧ください。

SonomaでBroadcom Wi-Fiを有効にする

OpenCore 0.9.4 から0.9.5に更新

Wed, 13 Sep 2023 16:52:25 +0900

OpenCoreの0.9.5が公開されていたので0.9.4からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.4 のconfig.plistそのままでも動きます。

0.9.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.5とmacOS Venturaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.5.2

今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.4の時のままです。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

UEFI/QuirksにShimRetainProtocolが追加されていました。boolデータで、デフォルトはfalseです。LinuxのセキュアなブートローダーShimという仕組みでOpenCoreを動かすためのものらしいです。使うことはないかと考え、デフォルトのままfalseにしておきました。

追加された項目はデフォルトで問題無いようですので、古いconfig.plistのままでも、変更なしで起動します。

macOS Ventura 13.5.2 に更新

Fri, 08 Sep 2023 20:34:55 +0900

macOS Ventura 13.5.2に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.5.2の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。セキュリティ修正とのことで、小さなバグ修正のようです。サイズは475MBです。機能に変更は無い様子です。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動は3回で、最初がmacOS Installerから、2回3回目は通常の起動ボリュームから起動しました。

ビルド番号は22G91でした。13.5.1と末尾1番違いです。問題なく動作しています。

macOS Sonoma 14 Public Beta 5をインストール

Sun, 03 Sep 2023 14:13:02 +0900

macOS Sonoma 14のPublic Beta 5が公開されていました。OpenCore 0.9.4と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。

Sonoma Public Beta 5が来た

米国時間の2023/8/31にSonomaのPublic Beta 5 にして、Dev Beta 7に相当するベータ版が無償配布されました。今回も今までと同様、developer.apple.comにはApple silicon版しかありませんでした。

「システム設定…」「一般」「ソフトウェアアップデート」にもPublic Beta 5の通知は来ていますが、ダウンロードを試みると、これも

前回同様に、インストールできないと言われます。

そこで、再びこちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ここからダウンロードしたPublic Beta 5のファイルはpkg形式です。

ダブルクリックして、適当なフォルダにインストールすると、その中にmacOS 14 public beta 5インストーラが出来上がります。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.4とmacOS 13.5.1で動作しています。

macOS Ventura 13.5 に更新

このmacOSの環境から、入手したインストーラを起動しました。

今回も、テスト用に用意した2.5インチSATA SSDをフォーマットして、これにインストールしました。最初の再起動では、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されました。それで自動的にインストール終了しました。

動作確認

特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5337aでした。デフォルトの壁紙は引き続きSonoma (?)の葡萄畑ですが、ズームの比率が変わったように見えました。

まとめ

macOS SonomaのPublic Beta 5が公開されたのでダウンロードして動作確認しました（この記事を書きました）。WiFiが使えない状態は相変わらずですが、それ以外の動作は試した限り問題ありませんでした。

macOS Ventura 13.5.1 に更新

Sat, 26 Aug 2023 12:02:12 +0900

macOS Ventura 13.5.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.5.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。8月18日から配布されていたようです。「位置情報へのアクセス許可が表示されない問題の修正」とのことで、小さなバグ修正のようです。サイズは475.9MBです。機能に変更は無いようです。

ビルド番号は22G90でした。問題なく動作しています。

macOS Sonoma 14 Public Beta 4をインストール

Fri, 25 Aug 2023 21:23:24 +0900

macOS Sonoma 14のPublic Beta 4が公開されていました。OpenCore 0.9.4と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。

Sonoma Public Beta 4が来た

米国時間の2023/8/22にSonomaのPublic Beta 4 にして、Dev Beta 6に相当するベータ版が無償配布されました。前回はBeta 1をインストールしましたが、Beta 2とBeta 3は見逃してしまいました。それでBeta 4をインストールしてみることにしました。

今回も今までと同様、developer.apple.comにはApple silicon版しかありませんでした。

「システム設定…」「一般」「ソフトウェアアップデート」にもBeta 4の通知は来ていますが、ダウンロードを試みると、これも

前回同様に、インストールできないと言われます。

そこで、再びこちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ここからダウンロードしたPublic Beta 4のファイルはpkg形式です。

ダブルクリックして、適当なフォルダにインストールすると、その中にmacOS 14 public beta 4インストーラが出来上がります。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.4とmacOS 13.5で動作しています。

macOS Ventura 13.5 に更新

このmacOSの環境から、入手したインストーラを起動しました。

今回も、テスト用に用意した2.5インチSATA SSDをフォーマットして、これにインストールしました。再起動の様子を観察していなかったのですが、おそらく今までと同じく、最初の再起動では、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されたと思います。それで自動的にインストール終了しました。

動作確認

特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5328bでした。デフォルトの壁紙が、カラフルな抽象模様から、おそらくはSonomaの葡萄畑に変わってました。

また、これは最初のベータ版から気づいていたのですが、文字入力の状態がカーソル位置に表示されるのが地味に便利です。英語キーボード派なので、Caps Lockを日本語・英数字の切り替えに使っています。時々、切り替え状態を間違えるのですが、Sonomaからは、カーソル位置に、「A」または「あ」のマークが現れて、どちらに切り替わったかを知らせてくれます。これだけでも早くSonomaに移行したいと思います。

まとめ

macOS SonomaのPublic Beta 4が公開されたのでダウンロードして動作確認しました。WiFiは使えないですが、それ以外の動作は試した限り問題ありませんでした。

OpenCore 0.9.3 から0.9.4に更新

Mon, 21 Aug 2023 21:19:06 +0900

OpenCoreの0.9.4が公開されていたので0.9.3からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.3 のconfig.plistそのままでも動きます。

0.9.4をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.4とmacOS Venturaで動作確認していた手元のマシンは以下です。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.5

今回のタイミングで、AppleALC.kext、Lilu.kext、WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.3の時のままです。

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

Misc/BootにInstanceIdentifierが追加されていました。stringデータで、デフォルトは空です。「OpenCoreのインスタンスを識別するためのIDを英数字のstringで指定する」ためのものらしいです。現在は、「.contentVisibilityファイルがOpenCoreのインスタンスを識別するために使用する」そうです。.contentVisibilityは、OpenCore 0.8.8で導入された機能で、ピッカーが表示するブート項目を調整する機能のようです。よく理解できていないのですが、ピッカーが表示する項目が煩雑または、少なすぎて困ることがなければ、使わないものと考えました。それでデフォルトのまま空にしておきました。

追加された項目はデフォルトで問題無いようでしたので、古いconfig.plistのままでも、変更なしで起動します。

macOS Ventura 13.5 に更新

Tue, 25 Jul 2023 12:56:57 +0900

macOS Ventura 13.5に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.5の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。メジャーなアップデートだけあって、サイズも1.04GBあります。とはいえ、内容はバグ修正とセキュリティーアップデートのようです。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22G74でした。

バグ修正ということで、特に変化した点はありませんでした。例年のスケジュールでは、Sonomaが出るまで、あと13.6までのアップデートがありそうです。

macOS Sonoma 14 Public Beta 1をインストール

Thu, 13 Jul 2023 18:16:33 +0900

macOS Sonoma 14のPublic Betaがいよいよ公開されました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。

Sonoma Public Beta 1が来た

米国時間の2023/7/12にSonomaの最初のPublic Betaが無償配布されました。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。

「システム設定…」「一般」「ソフトウェアアップデート」にも通知は来ていますが、ダウンロードを試みると、これも

インストールできないと言われます。

機種の設定の関係なのか、それともこちらでも配布されているのがApple Silicon用だけなのかもしれません。そこで、前回と同じく、こちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ダウンロードしたPublic Beta 1のファイルはpkg形式です。これを適当なドライブにインストールすると、

その中にmacOS 14 public beta 1インストーラが入ってます。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1 (c)で動作しています。

macOS Ventura 13.4.1 (c)に更新

このmacOSの環境から、入手したインストーラを起動しました。

今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。Beta Dev 3までは、3回再起動しましたが、今回は2回でした。最初は、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されます。

動作確認

特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5286iでした。

GeekBenchする

GeekBench 6でベンチマークしてみました。シングルコア2900, マルチコア15750くらいでした。

シングルコアスコアはどのMacよりも高速で、

マルチコアスコアはM1 UltraのMac Studioに負けるくらいの性能でした。

まとめ

macOS SonomaのPublic Beta 1が公開されたのでダウンロードして動作確認しました。今まで通りWiFiは使えないですが、それ以外は、問題なく動作しました。

macOS Ventura 13.4.1 (c)に更新

Thu, 13 Jul 2023 16:33:10 +0900

macOS Ventura 13.4.1 (c)に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.4.1 (c)の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。緊急のセキュリティアップデートのようで、サイズが6.6MBと極小です。機能に変更は無いようです。少し前に、(a)などのバージョンが出たそうですが、不具合があって差し替えられて(c)になったようです。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動は1回だけでした。ビルド番号は22F770829dでした。

MacOS Sonoma 14 Beta Dev 3に更新

Fri, 07 Jul 2023 22:23:23 +0900

Sonoma Beta Dev 3が出たので、Beta Dev 2からアップデートしました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードで問題なく動作します。

Sonoma Beta Dev 3が来た

米国時間の2023/7/5にSonomaのBeta Dev 3が無償配布されました。開発者向けベータのバージョン3です。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。

そこで、前回と同じく、こちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ダウンロードしたファイルはpkg形式です。これを適当なドライブにインストールすると、

その中にmacOS 14 beta Dev 3インストーラが入ってます。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1で動作しています。

ASRock Z690 Steel LegendでmacOSを動かす

このmacOSの環境から、入手したインストーラを起動しました。今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。インストールでは、Beta Dev 2までの時と同じく3回再起動します。最初は、macOS Installerというボリュームが、2回目以降は、インストール先のボリュームが自動的に選択されてます。

動作確認

特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。

まとめ

macOS SonomaのBeta Dev 3をダウンロードして動作確認しました。今まで通りWiFiは使えないですが、それ以外は、問題なく動作しました。

MacOS Sonoma 14 Beta Dev 2に更新

Sat, 24 Jun 2023 01:07:44 +0900

Sonoma Beta Dev 2が出たので、最初のBetaからアップデートしました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードで問題なく動作します。

Sonoma Beta 2が来た

米国時間の2023/6/21にSonomaのBeta Dev 2が無償配布されました。開発者向けベータのバージョン2です。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。

その中にmacOS 14 beta Dev 2インストーラが入ってます。今回はインストーラのみで、他のファイルはありませんでした。Beta Dev 1と違い、Sonomaのアイコンに変わってます。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1で動作しています。

ASRock Z690 Steel LegendでmacOSを動かす

このmacOSの環境から、入手したインストーラを起動しました。今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。インストールでは、Beta Dev 1の時と同じく3回再起動します。最初は、macOS Installerというボリュームが、2回目以降は、インストール先のボリュームが自動的に選択されてます。

動作確認

Beta 1では、Radeon RX 6600のDPに映像が出ず、HDMI端子に映像が出てました。今回は、DPにも映像が出るようになってました。

WiFiが動作しない状況は変わってません。Broadcom搭載Macがサポート対象から外れたのでドライバが無くなったようです。それ以外は、問題なく動作します。

まとめ

macOS SonomaのBeta Dev 2を動作確認しました。グラフィックカードのDP出力が動くようになりました。WiFiは使えないですが、それ以外は、問題なく動作しました。

macOS Ventura 13.4.1に更新

Thu, 22 Jun 2023 13:56:45 +0900

macOS Ventura 13.4.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。

Venturaの13.4.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。セキュリティアップデートのようで、サイズが501.2MBと小さいです。機能に変更は無いようです。

そのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22F82でした。

OpenCore 0.9.2 から0.9.3に更新

Tue, 13 Jun 2023 17:18:39 +0900

OpenCoreの0.9.3が公開されていたので0.9.2からアップデートしました。config.plistに変更はありませんでしたので、0.9.2 のconfig.plistそのままでも動きます。

0.9.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。バグフィックスと機能追加がされているようですが、大きな変更は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.2とmacOS Venturaで動作確認していた手元のマシンは以下です。今回のタイミングで、AppleALC.kext、Lilu.kext、WhateverGreen、VirtualSMC関連がアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.2の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.4

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

UEFI/OutputにConsoleFontが追加されていました。デフォルトは空です。OpenCoreの文字表示で使うフォントの指定のようです。多言語サポートしているEFIアプリ（例えばmemtest86）を使う場合に指定が必要な場合があるようです。通常は指定無しで良いようなので空白のままにしました。
UEFI/ProtocolOverridesにPciIoが追加されていました。デフォルトはfalseです。メモリ管理関係のパッチのようで、一部のUEFIドライバに関係するようです。特に該当しないようだったので、falseのままにしておきました。

追加された項目はデフォルトでも問題無いようでしたので、古いconfig.plistのままでも、変更なしで起動します。

macOS Sonomaを第13世代Intel CPUで動かす

Thu, 08 Jun 2023 12:35:21 +0900

2023/06/05のWWDC23キーノートでmacOS Sonomaが発表され、ベータ版が公開されました。Z690マザーボードとIntel Core i9-13900の自作PCにインストールして動作することを確認しました。

開発ベータ版

例年、WWDCと同時に公開されるmacOSの開発ベータ版は、会費を払った開発者だけが対象でした。一般の人に配布されるのは、7月に入って公開されるパブリックベータ版からでした。しかし今年からは、開発ベータ版から無償で配布されています。

Apple、各OSの開発者向けβを誰でも無料でダウンロード可能に（Apple IDは必要）

ただ、developer.apple.comから試したところApple silicon版しか公開されていないようでした。実際にダウンロードしたところ、ファイルは14GBくらいのipswという形式で、Apple silicon用らしいです。

macOS Venturaのシステム設定・一般・ソフトウェアアップデートの、ベータアップデートのメニューの中にも、Sonomaが現れていました。これを選んだらインストーラを入手できるかと思い、試しました。

しかし、やはり対象では無いとのことでした。機種IDはiMacPro1,1にしていて、Sonomaの動作対象Macです。こちらでも、Apple silicon版のみが配布されているのかもしれません。

探したところ、こちらのサイトで、直接ダウンロードできるリンク先が紹介されていました。”macOS Sonoma Beta Full Installer”という項目のリンクです。https://swcdn.apple.com/というURLなので、ちゃんとしたAppleのサイトのようです。

ダウンロードしたファイルはpkg形式です。これを適当なドライブにインストールすると、

その中にmacOS 14 betaインストーラが入ってます。これ以外にもファイルやフォルダがありますが、必要なのはこれだけでした。

インストールする

インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.2とmacOS 13.4で動作しています。

ASRock Z690 Steel LegendでmacOSを動かす

このmacOSの環境から、入手したインストーラを起動しました。

インストーラを開くと、あとは通常のmacOSのインストールと同様です。テスト用に2.5インチSATA SSDを用意しました。これをインストール先にします。

このSSDはフォーマットした直後なので、そのESPにOpenCoreなどが入っていません。なので、マザーボードのEFIの起動は今まで通りのmacOS 13.4が入っているSSDで行います。OpenCoreの選択メニューで、新しいSonomaのSSDを選択します。

インストールでは、3回ほど再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。

画面が出ない

少し試したところ、グラフィックスカードのRadeon RX 6600のHDMI端子に映像が出ているようでした。今まではDP端子を接続していたのですが、そちらはブラックスクリーンになったようです。ということで、ディスプレイをHDMI端子に接続すれば、問題なくmacOSのインストールを進めることができました。

動作確認

この先、いつも通りのインストール手順で進み、無事にmacOS Sonomaが動作しました。OpenCoreの最新版があれば、Sonomaも問題無いようです。

全コアが動作してます。

WiFiが動かない

有線LANもBluetoothも動作してますが、WiFiは動いていません。今となっては古いBroadcomのWiFiなので、ちょっと心配ですが、最初のベータ版なのでまだドライバが入ってないだけだと思いたいです。（追記：いただいたコメントによるとBroadcom搭載Macがサポート対象から外れたのでドライバが無くなったようです）

まとめ

macOS Sonomaの開発ベータ版を動かして、OpenCoreの最新版で動作することを確認しました。新しいmacOSへの対応も順調に進みそうなので安心しました。

ASRock Z690 Steel LegendでmacOSを動かす

Thu, 01 Jun 2023 22:58:23 +0900

第 13 世代および第 12 世代 Intel® Core™ プロセッサーに対応 (LGA1700)

ASRock Z690 Steel Legendで組んだコンピュータにmacOS Ventura 13.4をインストールします。現在メインマシンとして使っているマザーボードです。何度か紹介記事を書いているのですが、分散していて古くもなったので、更新してまとめます。

今までの記事

詳細は以下をご覧ください。最初のうちは第12世代CPUを使用していました。最後の2記事では、第13世代に移行してます。今回はこれの総集編・最新版です。

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

ASRock Z690 Steel Legendのオーディオを動かす

ASRock Z690 Steel Legendをスリープさせる

メインマシンをASRock Z690 Steel Legendに移行

ASROCK Z690 STEEL LEGENDのUSBを設定する

Raptor Lake-S 13900KFの32コアをmacOSで使う

CpuTopologyRebuildで13900KFのコア構成を調整する

パーツ構成

マザーボード

使用するマザーボードはASRock Z690 Steel Legendです。WiFi付きのASRock Z690 Steel Legend WiFiでも良いです。

最新マザーボードではないですが、現在も入手可能です。

Z690は、第12世代 Intel® Core™ プロセッサーと第13世代 Intel® Core™ プロセッサーに対応しています。macOSのIntel CPUサポートは第10世代で止まっているので、Z690が対象とする世代のCPUはサポートされていません。今後もサポートされることはないと思われます。でもOpenCoreの設定で、CPU IDを古いCPUに見せかけることで動作します。第10世代CPUよりも性能が上がっているので、最新CPUを使うメリットはあります。

数あるZ690マザーボードの中で、ASRock Z690 Steel Legendを選んだ理由は、

PCIeスロットの数が多い（5個あります）
こなれた有線LANチップ搭載でmacOS互換性が高い
macOS互換の無線用key Eソケットとアンテナ穴がある

という理由です。ここ数年のASRockは、比較的こなれたチップを搭載する傾向があり、macOSとの相性が良いと思ってます。Z590ではExtremeを選んでいたのですが、Z690 ExtremeではPCIeスロット数が減ってしまったので、Steel Legendにしました。見た目が派手目ですが、悪くはないです。

CPU

12と13世代CPUが使用可能ですが、macOSのサポートを超えたCPUを使うなら、最新の第13世代が良いと思います。性能も向上してます。

13900, F, K, KF, KS
13700, F, K, KF
13600K, KF
13500
13400, F
13100, F

などが動作するはずです。今回は13900KFで動作確認しています。

ちなみに第12世代では、12900Kと12700Kで動作確認しました。他にも、12900, KS, K, KF, F, T, 12700, K, KF, F, T, 12600, K, KF, T, 12500, T, 12400, F, T, 12300, T, 12100, F, Tなどが動作するはずです。

グラフィックボード

第12, 13世代CPUのiGPUはmacOSでサポートされていません。なのでグラフィックボードは必須です。現在のmacOSで使用可能なグラフィックスボードは、以下です。

AMD Vega 56, Vega 64, Radeon VII (OOB)
AMD RX 400 series, RX 500 series (OOB)
AMD RX 5000 series (“agdpmod=pikera”オプション使用)
AMD RX 6600 XT, RX 6800, RX 6800 XT, RX 6900 XT (“agdpmod=pikera”オプション使用)

これらならば、lilu.kextとwhatevergreen.kextを入れるだけで、そのまま (OOBで) 使用できます。ただし、RX 5000, 6000シリーズに関しては、config.plistのplist:NVRAM:7C436110-AB2A-4BBB-A880-FE41995C9F82:boot-argsの場所に、agdpmod=pikeraという設定が必要です。今回は、AMD RX 6600 XTを使用しました。

WiFi

このマザーボードには、M.2 WiFiのスロットがあります。WiFiモデルマザーボードにはIntelのM.2カードが既に入っています。最近では、Intelの無線カードもkextを入れると使用可能なようですが、ここでは、macOSがネイティブにサポートしているBroadcom BCM94360NGを使いました。macOSとの相性が良くて、Handoff, Airdrop, Apple WatchでのログインなどがOOBで動きます。M.2無線カードとしては、互換性の高い唯一のカードだと思います。おすすめです。日本のが少し高価です。 AliExpressでは複数の販売者から安価に入手できます。

その他のパーツ

その他のパーツは、定評のある自作PCパーツならどれを使っても大丈夫だと思います。メインドライブは、WD_BLACK 1TB SN770 NVMe SSDを使用しました。

BIOS設定

BIOSは、デフォルトの工場出荷時状態でも問題なく動作します。以下の設定は行っても良いと思います。

OC Tweaker > DRAM Configuration > Load XMP Setting > XMP 2.0 Profile 1
Advanced > USB Configuration > XHCI Hand-off > Enabled
Boot > Bootup Num-Lock > off

デフォルトのままで良いのですが、変更されていると起動に支障の出る項目は、以下です。

Advanced > CPU Configuration > CFG Lock > Disabled (default)
Advanced > Chipset Configuration > Above 4G Decoding > Enabled (default)

EFIを作る

次に、マザーボードのEFIが起動するときに実行されるボリュームの内容を作成します。ここにはmacOSのブートシーケンスが始まる前に必要となるファイル、つまりOpenCoreを構成するファイルとKext類を入れます。通常は、起動ドライブのESP (EFI System Partition)をFATでフォーマットしてその中に入れておきます。

作成したEFIをこちらに置いておきます。参考にしてください。

実は、FATでフォーマットしたUSBメモリにEFIというディレクトリを作ってその中に入れておいても良いです。このUSBメモリをEFIから起動すれば、OpenCoreなどが実行されます。USBメモリにmacOSなどが入っている必要はありません。OpenCoreの起動ドライブ選択メニューで、macOSボリュームを選択します。Hackintoshを作る最初は、色々と試行錯誤する必要がありますので、USBメモリの通常のディレクトリで設定作業すれば、作業が楽です。完成したら、その内容をmacOS起動ドライブのESPにコピーすれば良いです。

OpenCore

OpenCoreは最新の0.9.2を使いました。OpenCore Vanilla GuideもComet Lakeの項目しかありません。参考にしつつ、設定を進めました。tonymacx86のこちらのコメントも参考にしました。

Kext

使用したKext類は以下です。

Lilu.kext
WhateverGreen.kext
VirtualSMC.kext
SMCSuperIO.kext
SMCProcessor.kext
LucyRTL8125Ethernet.kext
AppleALC.kext
NVMeFix.kext
CpuTopologyRebuild.kext
USBPorts.kext

USBPorts.Kextは、自作です。USBの項目で説明します。

ACPI

ACPIディレクトリに入れたSSDT類は以下です。

SSDT-AWAC.aml
SSDT-EC-USBX.aml
SSDT-SBUS.aml
SSDT-PLUG-ALT.aml

config.plist

第12, 13世代CPUは、macOSでサポートされていないCPUなので、CPU IDをi9-10850KなどのID である000A0655に偽装しています。config.plistのKernel/Emulateの中に以下のように記述します。

機種名 (SystemProductName) はiMacPro1,1にしました。第12, 13世代CPUで使用する場合、 iMacPro1,1 または MacPro7,1 が良いようです。どちらを選んでも性能はほぼ変わらないそうです。今回、iMacPro1,1にした理由は、性能調整が簡単そうだったからです。MacPro7,1に設定した場合は、CPUFriend.kextと関連kextsが必要らしいです。機種に関連するconfig.plist項目は以下です。

公開したconfig.plistも、この設定になってます。ここでは、

MLB
SystemSerialNumber
SystemUUID
ROM

の情報が未記入または適当な値になってます。各自で設定した固有の情報を書き込んでください。設定の方法はこちらをご覧ください。以下ではiMac20,1の固有情報を生成していますが、これをiMacPro1,1に変えて生成してください。

最後のIntel iMacのシリアル番号を作る

USB設定

macOSにはUSBポート数の制限があります。なのでそれに対応する必要があります。詳しくはこちらをご覧ください。

ASROCK Z690 STEEL LEGENDのUSBを設定する

これによると、ASRock Z690 Steel LegendのUSBポートは、以下です。

HS01:マザーボード上のUSB Type-Cコネクタ (F_USB32_TC_1)
HS02:バックパネルのEtherの下の上のType-A (USB3_3_4)
HS03:バックパネルのEtherの下の下のType-A (USB3_3_4)
HS04:バックパネルのPS/2下の下のType-A (USB3_1_2)
HS05:バックパネルのPS/2下の上のType-A (USB3_1_2)
HS06:バックパネルのType-C (USB31_TC_1)
HS07:バックパネルのType-Cの上のType-A (USB31_TA_1)
HS08:オンボード搭載ハブ(ASM107x) (**USB3_5_6,**USB3_7_8)
HS09:オンボードUSB2.0 (USB_3_4 のCPU反対側)
HS10:オンボードUSB2.0 (USB_3_4 のCPU側)
HS11:オンボードUSB2.0 (USB_1_2 のCPUの反対側)
HS12: オンボードUSB2.0 (USB_1_2 のCPU側)
HS13: ASRock LED Controller
HS14:マザーボード上のM.2 E keyソケット接続 (BCM94360NGがBTで使用）
HS15〜:（不明）
SS01:マザーボード上のUSB Type-Cコネクタ (F_USB32_TC_1)
SS02:バックパネルのEtherの下の下のType-A (USB3_3_4)
SS03:バックパネルのEtherの下の上のType-A (USB3_3_4)
SS04:バックパネルのPS/2下の下のType-A(USB3_1_2)
SS05:バックパネルのPS/2下の上のType-A(USB3_1_2)
SS06:バックパネルのType-C (USB31_TC_1)
SS07:バックパネルのType-Cの上のType-A (USB31_TA_1)
SS08:オンボード搭載ハブ(ASM107x) (**USB3_5-6,**USB3_7_8)
SS09〜SS15:（不明）

またマザーボード上のUSBピンは、それぞれ以下の名前です。

macOSには最大15口までの制限があります。なので、ここから使用するポートを15個選んでUSBPorts.kextに設定します。どのポートを使うかは、マシンの構成次第です。例えば、上記のリストで、太字になっているポートを残すと、

のような設定になります。これを元にUSBPorts.kextを作ります。配布しているUSBPorts.kextは、もしかしたらこれから変更したバージョンかもしれません。必要に応じで調整してください。

動作確認

macOS Ventura 13.4をインストールして動作確認しました。メインでずっと使用しているマザーボードなので、かなり調整が進んでいて、動作状態も良好です。

動くこと

安定した動作
シャットダウン、再起動
有線LAN (ボード上の2.5GbE, Realtek RTL8125BG)
M.2 WiFi, Bluetooth (Broadcom BCM94360NGを使用)
オーディオ (ALC897, layout-id=12)
Quick Look、プレビュー
メッセージ、FaceTime
iCloud, App Store, Apple TV
Universal clipboard, Continuity, AirDrop
Safari/Google ChromeでのAmazon Prime Video再生
AirPlay Receiver (DRM コンテンツの再生)
スリープ (CPU とケースファンが停止)
Bluetoothキーボード類, USB接続キーボード類、電源スイッチによるスリープ復帰（ACPIをサポートしない USB3_1_2 を除く）
Universal Control (macOS 12.3以降)

動かないこと

Sidecar (iGPUが無いために動作しない）

ベンチマーク

このマザーボードに、13900KFを搭載した時のCinebench R23のスクリーンショットを以下に示します。

同じくこのマザーボードに12900Kを搭載した場合との比較を以下に示します。また、ネットにあったMac Studio M1 MaxとUltraのスコアとも比較します。

まとめ

現在メインマシンとして使っているASRock Z690 Steel LegendへmacOSをインストールする手順、動作状況などを、改めてまとめました。また、使用中のEFI一式もアップロードしておきました。

ASRock Z590 ExtremeでmacOSを動かす

Wed, 31 May 2023 22:58:47 +0900

ASRock Z590 Extremeで組んだコンピュータにmacOS Ventura 13.4をインストールします。以前、メインマシンとして使っていたマザーボードですが、紹介記事が分散していて古くもなったので、更新してまとめます。

今までの記事

以前は、ASRock Z590 Extremeで作ったmacOSマシンをメインに使ってました。色々調整して、安定して動作してました。その過程を紹介した様子は、以下をご覧ください。散らばっていてわかりにくいので、まとめ記事が欲しいと思っていました。

ASRock Z590マザーボードでmacOSを起動する

ASRock Z590マザーボード搭載ALC1220で音を出す (その1)

ASRock Z590マザーボード搭載ALC1220で音を出す (その2)

ASRock Z590 Extremeに無線モジュールを取り付ける

ASRock Z590 ExtremeのUSBを設定する

メインマシンをASRock Z590 Extremeに移行

その後、Z690マザーボードに移行したので、このマシンはずっとお蔵入りになってました。最近になって、復活させてOpenCoreとmacOSを最新版 (OpenCore 0.9.2, macOS Ventura 13.4) に入れ替えてみました。動作確認や調整などまだ必要ですが、設定をまとめて、動作するEFIファイルを配布したいと思います。

パーツ構成

マザーボード

使用するマザーボードはASRock Z590 Extremeです。WiFi付きのASRock Z590 Extreme WiFiでも良いです。

もはや中古でしか入手できないのではと思いましたが、現在も入手可能です。

Z590は、第10世代 Intel® Core™ プロセッサーと第11世代 Intel® Core™ プロセッサーに対応しています。第10世代CPU (Comet Lake) は、Intel版macOSがサポートする最後のIntel Core-i CPUです。iMac 2020 (iMac20,1とiMac20,2) に、Intel Core i5 10500, 10600, i7 10700K, i9 10910が搭載されています。現時点でこれが最新で最後のIntel版Macになると思われています。macOSがIntel CPUをサポートしているうちに、最新のCPUで安定したHackintoshを作るとしたら、この世代のマザーボードに行きつきます。

数あるZ590マザーボードの中で、ASRock Z590 Extremeを選んだ理由は、

PCIeスロットの数が多い
こなれた有線LANチップ搭載でmacOS互換性が高い
見た目がスッキリしている
macOS互換の無線用key Eソケットとアンテナ穴がある

という理由です。ここ数年のASRockは、比較的こなれたチップを搭載する傾向があり、macOSとの相性が良いと思ってます。有線LANが1個だけになりますが、ほぼ同じ構成のも良いと思います。個人的には、Extremeの方が見た目も良いと思います。

（現在のメインマシンではASRockのZ690 Steel Legendを使ってます。本当はZ690もExtremeを使いたかったのですが、PCIeスロットの数が減ってしまったので、Steel Legendにしました。）

CPU

Core i9-10900Kを使用しました。これ以外の第10世代Core i CPUはほぼ使用可能だと思います。

とくにiMacで搭載されているCPUならば、間違いなく動作するはずです。Macで使用されているComet Lake CPUは、Intel Core i5 10500, 10600, i7 10700K, i9 10910です。このうち、10910はApple専用チップですので、市販されていません。なので、

Core i7-10700K (3.8Ghz / 8 Cores / 16 Threads)
Core i7-10700 (2.9Ghz / 8 Cores / 16 Threads)
Core i5-10600K (4.1Ghz / 6 Cores / 12 Threads)
Core i5-10600 (3.3Ghz / 6 Cores / 12 Threads)
Core i5-10500 (3.1Ghz / 6 Cores / 12 Threads)

ならば、Macで使われているCPUと同じCPUだと言えます。このほか、

Core i9-10900K(3.7Ghz / 10 Cores / 20 Threads)
Core i9-10900 (2.8Ghz / 10 Cores / 20 Threads)
Core i9-10850K (3.6Ghz / 10 Cores / 20 Threads)
Core i5-10400 (2.9Ghz / 6 Cores / 12 Threads)
Core i3-10320 (3.8Ghz / 4 Cores / 8 Threads)
Core i3-10300 (3.7Ghz / 4 Cores / 8 Threads)
Core i3-10100 (3.6Ghz / 4 Cores / 8 Threads)

なども安定して使用可能です。

Z590チップセットでは、第11世代CPUも使用可能です。しかし11世代はmacOSが正式対応していません。対応させることも可能ではありますが、性能が振るわずあまり人気のなかった11世代を使うくらいならば、もっと最新の13世代を使いたいところです。

グラフィックボード

macOSを動かすためにグラフィックボードはほぼ必須です。CPU内蔵のiGPUも使えなくは無いですが、設定が大変です。そもそもZ590クラスのATXマザーボードを使うならば、iGPUを使うことはないと思います。

現在のmacOSで使用可能なグラフィックスボードは、以下です。

AMD Vega 56, Vega 64, Radeon VII (OOB)
AMD RX 400 series, RX 500 series (OOB)
AMD RX 5000 series (“agdpmod=pikera”オプション使用)
AMD RX 6600 XT, RX 6800, RX 6800 XT, RX 6900 XT (“agdpmod=pikera”オプション使用)

WiFi

その他のパーツ

その他のパーツは、定評のある自作PCパーツならどれを使っても大丈夫だと思います。メインドライブは、WD_BLACK 1TB SN770 NVMe SSDを使用しました。

BIOS設定

BIOSは、デフォルトの工場出荷時状態でも問題なく動作します。以下の設定は行っても良いと思います。

Advanced > USB Configuration > XHCI Hand-off > Enabled

デフォルトのままで良いのですが、変更されていると起動に支障の出る項目は、以下です。

Advanced > CPU Configuration > CFG Lock > Disabled (default)
Advanced > Chipset Configuration > Above 4G Decoding > Enabled (default)

EFIを作る

作成したEFIをこちらに置いておきます。参考にしてください。

OpenCore

OpenCoreは最新の0.9.2を使いました。OpenCore Vanilla GuideのComet Lakeの項目に従って、以下を設定しました。

Desktop Comet Lake | OpenCore Install Guide

Kext

使用したKext類は以下です。

Lilu.kext
WhateverGreen.kext
VirtualSMC.kext
SMCSuperIO.kext
SMCProcessor.kext
LucyRTL8125Ethernet.kext
IntelMausi.kext
AppleALC.kext
USBPorts.kext

LucyRTL8125Ethernet.kextとIntelMausi.kextはどちらも有線LAN用のkextです。ASRock Z590 ExtremeにはRealtekの2.5GbpsとIntelの1Gbps Ethernetが搭載されています。それぞれのためのkextです。

USBPorts.Kextは、自作です。USBの項目で説明します。

ACPI

ACPIディレクトリに入れたSSDT類は以下です。

SSDT-RHUB.aml
SSDT-AWAC.aml
SSDT-EC-USBX.aml
SSDT-PLUG.aml
SSDT-TB4.aml

config.plist

これもVanilla Guideに従って設定します。機種名は、第10世代CPUが搭載されたiMac20,1にしました。cofig.plistの中の、plist/Platforminfo/Genericの内容は以下のようにしました。

公開したconfig.plistも、この設定になってます。ここでは、

MLB
SystemSerialNumber
SystemUUID
ROM

の情報が未記載または適当な値になっています。各自で設定した固有の情報を書き込んでください。設定の方法はこちらをご覧ください。

最後のIntel iMacのシリアル番号を作る

USB設定

macOSにはUSBポート数の制限があります。なのでそれに対応する必要があります。詳しくはこちらをご覧ください。

ASRock Z590 ExtremeのUSBを設定する

これによると、ASRock Z590 ExtremeのUSBポートは、以下のように23個あります。

HS01 マザーボード上の2.0ヘッダピン（縁側） USB_3_4
HS02 マザーボード上の2.0ヘッダピン（縁側） USB_3_4
HS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
HS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
HS05 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
HS06 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
HS07 バックパネルのType-A、PS/2上の2個のうち下 (2.0 USB_2)
HS08 バックパネルのType-A、PS/2上の2個のうち上 (2.0 USB_1)
HS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)
HS10 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
HS11 マザーボード上の2.0ヘッダピン（内側） USB_5_6
HS12 マザーボード上の2.0ヘッダピン（内側） USB_5_6
HS13 （不明）
HS14 M.2 key Eソケット (Bluetoothで使用)
SS01 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
SS02 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
SS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
SS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
SS05 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
SS06 （不明）
SS07 （不明）
SS08 （不明）
SS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)

不明のポートは、発見できていないか、または元々どこにも接続されていないだけかもしれません。USBで始まる番号・記号は、ASRockのマニュアルに記載されているポートの名前です。マニュアルのバックパネルの図にポート名を書き込むと以下になります。

またマザーボード上のUSBピンは、それぞれ以下の名前になります。

マザーボード上のUSB2.0ピンはチップセット直結なのに対して、USB3.xピンはUSBハブ経由なのが面白いところです。Gen2x2のコネクタは、裏表で同じSSポートに割り当てられています。

macOSでは15個のUSBポートが使用可能です。使用形態に合わせて選択して、USBPorts.kextに反映させます。配布しているEFIでは、マザーボード上のUSB2.0ヘッダ端子を無効にしました。その結果、以下を動作させています。

HS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
HS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
HS05 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
HS06 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
HS07 バックパネルのType-A、PS/2上の2個のうち下 (2.0 USB_2)
HS08 バックパネルのType-A、PS/2上の2個のうち上 (2.0 USB_1)
HS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)
HS10 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
HS14 M.2 key Eソケット (Bluetoothで使用)
SS01 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
SS02 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
SS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
SS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
SS05 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
SS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)

動作確認

macOS Ventura 13.4をインストールして動作確認しました。実はメインマシンは13世代CPUに移行していて、このマザーボードは、最近になって復活させました。Z590をmacOS Montereyで使っていた頃は、もう少し動作していた（スリープやDRMビデオ再生など）ように思います。さらに調整しつつ、動作確認していきたいと思います。

動くこと

安定した動作
シャットダウン、再起動
有線LAN
M.2 WiFi, Bluetooth (Broadcom BCM94360NGを使用)
オーディオ（Realtek ALC1220)
Quick Look、プレビュー
メッセージ、FaceTime
Google Chrome上でのAmazon Prime Video

動かないこと

Safari上でのAmazon Prime Video: iGPUの設定関係かと思ってます。
Sleep：スリープしてもすぐに復帰します。
iGPUからの映像出力： config.plistではヘッドレス設定していますが、設定しなおしても映像出力されません。iGPUは使用しないので良いことにしてます。

未確認のこと

iCloud, App Store, Apple TV
Universal clipboard, Continuity, AirDrop
AirPlay Receiver (DRMコンテンツの再生)
Universal Control
Sidecar

まとめ

以前メインマシンとして使っていたASRock Z590 Extremeを、久々に復活させて、OpenCoreとmacOSを最新に入れ替えました。その構成をまとめておきました。最後のIntel iMacで使用されている世代のCPUなので、安心して自作できるかと思います。macOSとして安定して動作していますが、スリープ動作などもう少し調整したい項目もあります。サブマシンなのでゆっくりですが、この先、動作確認項目などを更新していきます。

最後のIntel iMacのシリアル番号を作る

Wed, 31 May 2023 16:20:48 +0900

2020年モデルiMacは、macOSが動く最後のIntel iMacです。このシリアル番号を生成する方法を、更新して再度掲載しておきます。

最後のIntel iMac

macOSが動作する最新で最後のIntel iMacが2020年iMacです。モデルIDは、iMac20,1とiMac20,2です。第10世代Intel CPUを搭載した自作PCで、現行のmacOSを動作させるとしたら、このiMacを模倣することになると思います。

iMac20,1と20,2の違いは搭載されているRadeon GPUの違いです。他には大きな違いはないと思われます。

iMac20,1とiMac20,2の違い

とはいえ、iMac20,1の方が、広いCPUをカバーしています。また、次に述べるように、iMac20,2は、あまり出回っていませんので、シリアル番号に関する情報も少ないです。なので、自作PCの機種IDには、iMac20,1を選んでおくのが良いと思います。

シリアル番号を作る

macOSの起動には、コンピュータハードウェアにシリアル番号が必要です。実際のMacでは、マザーボードのファームウェアの中にシリアル番号が書き込まれています。自作PCでは、ESPの中のconfig.plistに書いておきます。OpenCoreがこの情報を、Macのシリアル番号としてmacOSに伝えてくれます。

OpenCoreのconfig.plistに書くべきシステムシリアル番号 (SystemSerialNumber)、ボードシリアル番号 (MLB) を自動生成してくれるツールの一つにmacserialがあります。OpenCore配布サイトや、Kext Updateでダウンロードすると、

Releases · acidanthera/OpenCorePkg

ダウンロードされたファイルの、OpenCore/Utilities/macserialの中に、macserialコマンドとして入っています。これを

$ ./macserial

として起動すると、現在のMac/Hackintoshのシリアル番号などの情報が表示されます。–helpとすれば使い方の説明が表示されます。

$ ./macserial --help
./macserial arguments:
 --help (-h) show this help
 --version (-v) show program version
 --deriv <serial> (-d) generate all derivative serials
 --generate (-g) generate serial for current model
 --generate-all (-a) generate serial for all models
 --info <serial> (-i) decode serial information
 --list (-l) list known mac models
 --mlb <serial> generate MLB based on serial
 --sys (-s) get system info

Tuning options:
 --model <model> (-m) mac model used for generation
 --num <num> (-n) number of generated pairs
 --year <year> (-y) year used for generation
 --week <week> (-w) week used for generation
 --country <loc> (-c) country location used for generation
 --copy <copy> (-o) production copy index
 --line <line> (-e) production line
 --platform <ppp> (-p) platform code used for generation

–generateオプションで現在モデルのシリアル番号とボードシリアル番号を複数生成してくれます。–generate-allで全てのモデルの番号を生成します。–model iMac20,1などとすれば特定のモデルの番号を生成してくれます。iMac20,1のシリアル番号を生成した例が以下です。｜の左側がシステムシリアル番号で、右側がMLBです。

% ./macserial --model iMac20,1
C02G39Y0PN5T | C02129300GUPHC11M
C02GQ1ZMPN5T | C02147200CDPHC1FB
C02G6SYFPN5T | C02132600J9PHC11H
C02H9ZYYPN5T | C02208207GUPHC11H
C02CQ0GZPN5T | C02020501J9PHC1JA
C02D1UYRPN5T | C02027501GUPHC1JA
C02CL1Z8PN5T | C020161004NPHC1CB
C02CNLZ5PN5T | C02018902QXPHC1JA
C02CRWYHPN5T | C02021902GUPHC1AD
C02DPKYTPN5T | C020462074NPHC18C

iMac20,2のシリアル番号も生成してみます。

% ./macserial --model iMac20,2
C02DJUZW046M | C02041405GU0000UE
C02HH0XD046M | C022136004N0000JC
C02D80SH046M | C020344054N0000UE
C02DQ9ZN046M | C02047310QX0000FB
C02FP0V0046M | C02119303CD00008C
C02CK06Z046M | C02015403J900008C
C02CKLY4046M | C020153034N0000JC
C02FQKZ1046M | C021203034N0000AD
C02DQPZS046M | C02047100GU00001H
C02FKTZZ046M | C02115802J90000JA

iMac20,2では、MLBの最後の方の4文字が0000になってます。ここは機種依存の情報の場所です。iMac20,2は、iMac20,1に比べてほとんど出回っていません。Apple Storeの店頭にもありません。なので、この部分の情報がなく、0000になってしまっているようです。自作するならば、割り当てるべき情報が判明しているiMac20,1を選んだ方が良いでしょう。

–info シリアル番号でそのシリアル番号を分析してくれます。例えば、上記のiMac20,1の例で生成した最初のシリアル番号C02G39Y0PN5Tでしたら、

% ./macserial --info C02G39Y0PN5T 
 Country: C02 - China (Quanta Computer)
 Year: G - 2021
 Week: 3 - 29 (16.07.2021-22.07.2021)
 Line: 9Y0 - 1700 (copy 1)
 Model: PN5T - iMac20,1
SystemModel: iMac (Retina 5K, 27-inch, 2020)
 Valid: Possibly

のように表示されます。2021年の第3週から第29週製造のモデルとのことです。

実存しないことの確認

シリアル番号はランダムに生成されます。実存するMacと同じ番号が生成されることは滅多にありませんが、念のために確認します。確認のためには、以下のAppleのサイトを利用します。

Check Your Service and Support Coverage - Apple Support

このページに、生成されたシリアル番号を入力して、

上記のように「有効なシリアル番号を入力してください。」と表示されたらOKです。保証期間などの情報が現れてしまったら、このシリアル番号のMacを誰かが実際に使っている可能性があります。iCloudサービスなどを使用する際に問題が生じる可能性がありますので、別のシリアル番号を使用します。

config.plistに書き込む

問題がなければ、このシリアル番号をOpenCoreのconfig.plistで使えます。config.plistのplist:Platforminfo:Genericの部分に機種固有情報を以下のように書き込みます。（以下は例です。この機種情報は使わないでください）

<key>Generic</key>
<dict>
 <key>AdviseFeatures</key>
 <false/>
 <key>MLB</key>
 <string>C02129300GUPHC11M</string>
 <key>MaxBIOSVersion</key>
 <false/>
 <key>ProcessorType</key>
 <integer>0</integer>
 <key>ROM</key>
 <data>112233445566</data>
 <key>SpoofVendor</key>
 <true/>
 <key>SystemMemoryStatus</key>
 <string>Auto</string>
 <key>SystemProductName</key>
 <string>iMac20,1</string>
 <key>SystemSerialNumber</key>
 <string>>C02G39Y0PN5T</string>
 <key>SystemUUID</key>
 <string>EEF45689-BBE5-4FB6-9E80-41B78F6578E2</string>
</dict>

macserialコマンドで作成した情報を、MLBとSystemSerialNumberに書き込みます。そのほかに、固有の番号としてROMとSystemUUIDがあります。

ROMは、本来はMac搭載のROMの固有IDらしいですが、固有ならばなんでも良いようです。なので、OpenCoreのガイドでは、EthernetカードのMACアドレスを使うと良いと説明しています。適当な6バイトのデータでも良いようです。

SystemUUIDもユニークならばなんでも良いです。Macのターミナルには、uuidgenというコマンドがあり、適当にUUIDを作ってくれるので、これを使います。上記の例では、この値を書き込んでいます。

% uuidgen
EEF45689-BBE5-4FB6-9E80-41B78F6578E2

まとめ

第10世代Intel CPUを使った自作PCに、macOSをインストールする際に必要な、機種固有情報の作り方を紹介しました。ここで作成した、SystemSerialNumber, MLB, ROM, SystemUUIDをOpenCoreのconfig.plistに書き込んでおきます。実際にインストールする際には、記事の中の機種固有情報とは違うものを使ってください。

これらの機種固有情報は、一旦設定したら、できる限り変更しないほうが良いです。機種固有情報が頻繁に変化するデバイスは、Appleのクラウドサービスに拒絶される可能性があります。

OpenCore 0.9.1 から0.9.2に更新

Wed, 17 May 2023 11:39:50 +0900

OpenCoreの0.9.2が公開されていたので0.9.1からアップデートしました。config.plistに変更はありませんでしたので、0.9.1 のconfig.plistそのままでも動きます。

0.9.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。最近の更新に比べると変更点は多いようですが、大半はバグフィックスのようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.2とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextとLilu.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.1の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.3.1 (a)

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

新たにsample.plistに追加された項目は以下です。

Kernel/QuirksにDisableIoMapperMappingが追加されていました。デフォルトはfalseです。macOS 13.3（以降？）でのみ必要らしいです。またAMD cpuでは不要らしいです。特定の条件でVT-dを使う際、Wi-Fi, Ethernet, Thunderboltの互換性問題を解決するために必要な、メモリ管理に関する指定のようです。ニッチな問題のように思えるので、デフォルトのfalseでも良いかとも思いましたが、 sample.plistの値がtrueになっていたので、それに合わせてtrueにしました。デフォルトのfalseでも一見問題なく動作します。
UEFI/OutputにInitialModeが追加されていました。デフォルトはAutoで、sample.plistの値も同じなので、合わせてAutoにしておきました。UEFIのコンソールコントロールモードを選択するらしいです。Auto, Text, Graphicsが選べます。OpenCoreとmacOSはTextモードを前提にしているけど、グラフィックスも描画可能らしいです。効果はUEFIの実装によって異なるようです。

追加された項目はデフォルトでも問題無いようでしたので、古いconfig.plistのままでも、変更なしで起動します。

OpenCore 0.9.0 から0.9.1に更新

Sat, 08 Apr 2023 18:55:04 +0900

OpenCoreの0.9.1が公開されていたので0.9.0からアップデートしました。config.plistに変更はありませんでしたので、0.9.0 のconfig.plistそのままでも動きます。

0.9.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はほとんど無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.1とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.0の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.3

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

今回も、config.plistで変更された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。

OpenCore 0.8.9 から0.9.0に更新

Tue, 28 Mar 2023 12:05:20 +0900

OpenCoreの0.9.0が公開されていたので0.8.9からアップデートしました。config.plistに変更はありませんでしたので、0.8.9 のconfig.plistそのままでも動きます。

0.9.0をダウンロードする

0.9になりました。1.0までもう少しですね。公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はほとんど無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.9.0とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, Lilu.kext, VirtualSMC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.9の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.2.1および13.3

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

今回、config.plistで変更された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。

OpenCore 0.8.8 から0.8.9に更新

Tue, 28 Feb 2023 19:10:39 +0900

OpenCoreの0.8.9が公開されていたので0.8.8からアップデートしました。config.plistに大きな変更はありませんでしたので、0.8.8 のconfig.plistそのままでも動きます。

0.8.9をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.9とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.8の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.2.1

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

config.plistで変更された項目は以下だけでした。

UEFI/QuirksにResizeUsePciRbIoという項目が追加されていました。メモリー確保に関連してCapability I/O Errorを出すシステム対策のようでした。デフォルトはfalseだったのでそのままfalseに設定しました。

結局は、デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動します。

OpenCore 0.8.7 から0.8.8に更新

Thu, 26 Jan 2023 15:31:53 +0900

OpenCoreの0.8.8が公開されていたので0.8.7からアップデートしました。config.plistに大きな変更はありませんでしたので、0.8.7 のconfig.plistそのままでも動きます。

0.8.8をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.8とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, Lilu.kext, WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.7の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.1

.efiファイルを差し替える

更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを作り直す

config.plistで変更された項目は以下だけでした。

Misc/BootにHibernateSkipsPickerという項目が追加されていました。macOSハイバーネーションから復帰した場合に、ピッカーを表示しないための設定です。デフォルトはfalseだったのでそのままfalseに設定しました。

結局は、デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動します。

OpenCore 0.8.6 から0.8.7に更新

Wed, 14 Dec 2022 22:34:41 +0900

OpenCoreの0.8.7が公開されていたので0.8.6からアップデートしました。config.plistに変更はありませんでしたので、0.8.6 のconfig.plistそのままで動きます。

0.8.7をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.7とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextとWhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.6の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.0.1

.efiファイルを差し替える

更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistは変更なし

結局は、config.plistの項目には変更ありませんでした。なので、古いconfig.plistのまま、変更なしでも問題なく起動します。

OpenCore 0.8.5 から0.8.6に更新

Thu, 10 Nov 2022 21:33:17 +0900

OpenCoreの0.8.6が公開されていたので0.8.5からアップデートしました。config.plistに大きな変更はありませんので、0.8.5 のconfig.plistそのままでも動くはずです。

0.8.6をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.6とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.5の時のままです。

ASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.0.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点は以下でした。

UEFI/AppleInput/Power/PointerDwellClickTimeoutが追加されていました。Sample.plistの値が0でしたのでそのまま使いました。
UEFI/AppleInput/Power/PointerDwellDoubleClickTimeoutが追加されていました。Sample.plistの値が0でしたのでそのまま使いました。
UEFI/AppleInput/Power/PointerDwellRadiusが追加されていました。Sample.plistの値が0でしたのでそのまま使いました。

PointerDwellRadiusの数値以内にポインタが止まっていたら、指定したタイムアウトでクリックやダブルクリックが発生するらしいです。0の場合は無効なので、デフォルトではこの機能はoffです。何のための機能なのかわかりませんが、問題なければoffで良いと思いました。いずれもデフォルトのままでokなので、古いconfig.plistのまま、変更なしでも問題なく起動するはずです。

CpuTopologyRebuildで13900KFのコア構成を調整する

Sat, 05 Nov 2022 16:10:24 +0900

前回アップグレードしたCore i9-13900KFは、その後もmacOS Ventura 13.0で順調に稼働してます。

Raptor Lake-S 13900KFの32コアをmacOSで使う

この記事へのコメントで、CpuTopologyRebuildというkextを作者の方から教えて頂きました。物理コアとハイパースレッド (HT) の構成をmacOSに伝えるkextです。Alder Lake-Sのために作られて、Raptor Lake-Sでは未検証とのことでしたが、試したところ正しく動作しました。13900K, KFは、Pコア8, HT 8, Eコア16の全32スレッド構成 (8P16E32T) ですが、これを

物理コア24, HT 8、全32スレッド (24C32T) または、
物理コア8, HT 24、全32スレッド (8C32T)

に見せることが可能でした。ベンチマークテストの結果、マルチコアのスコアはどの構成でも大差はありませんが、シングルコアのスコアは物理コア8 (8C32T) と設定した場合が高性能でした。

CpuTopologyRebuild.kext

今回試したkextは、以下のCpuTopologyRebuild.kextです。

GitHub - b00t0x/CpuTopologyRebuild

Core i9-13900は、Pコア8, HT 8, Eコア16の構成です。macOSがサポートしているインテルCPUには、PコアとEコアが混在するモデルはありません。なので、均一の物理コアとHTの組み合わせとして認識させることになります。OpenCoreそのままで使用すると、全部が物理コアとして扱われて、

物理コア32、全スレッド32 (32C32T)

としてmacOSから見えるようになります。ちょっと乱暴な気はしますが、性能もそこそこ良く、特に問題は発生していませんでした。これに対して、CpuTopologyRebuild.kextを使うと、

物理コア24, 全スレッド32 (24C32T)、または、
物理コア8, 全スレッド32 (8C32T)

のようにmacOSに見せることができました。このkextを有効にすると物理コアが24になり、さらにboot argに-ctrsmtを追加すると物理コアが8コアになります。以下に13900K, KFのコア構成とkextの設定を表で示します。


物理コア	全スレッド	kext	boot arg
32	32	なし	なし
24	32	あり	なし
8	32	あり	-ctrsmt

コア数を確認する

Geekbench 5の表示で確認すると、確かにコアの構成が変わってます。以下はそれぞれ、32コア、24コア、8コアに設定した場合の表示です。

さらに、sysctl -a | grep cpuした結果を、diffで比較しました。<で始まる行がkextなしで、>で始まる行がkextあり（-ctrsmtオプション付き）の項目です。OpenCoreデフォルトだと32コアなところが、このkextで8コアになっていることがわかります。

< hw.perflevel0.physicalcpu: 32
< hw.perflevel0.physicalcpu_max: 32 
> hw.perflevel0.physicalcpu: 8
> hw.perflevel0.physicalcpu_max: 8
< hw.perflevel0.cpusperl2: 1 
> hw.perflevel0.cpusperl2: 2
< hw.physicalcpu: 32
< hw.physicalcpu_max: 32 
> hw.physicalcpu: 8
> hw.physicalcpu_max: 8

Geekbench 5の比較

Geekbench 5のスコアを比較します。数回実施した平均値です。参考に、GeekbenchのサイトにあるM1 Ultraのスコアも加えました。13900は、M1 Ultraにはシングルで勝っているものの、マルチでは負けてます。

コア構成の比較では、マルチの差は1%以下で誤差に近いです。シングルの差は4%くらいあって、8C > 32C > 24Cの順番で、8Cが一番良いです。

Cinebench R23の比較

Cinebench R23でもベンチマークしました。マルチは数回の平均、シングルは2回の平均です。これもM1 Ultraと比較しましたが、こちらはシングル、マルチとも13900がM1 Ultraよりも高速でした。Intel CPUが得意とするベンチマークのようです。

コア構成の比較では、Geekbench 5と同様の傾向が見られました。マルチは32C > 8C > 24Cで、シングルは8C > 32C > 24Cの順番でした。マルチの差は、毎回の測定のばらつきよりも小さいので、誤差範囲かと思います。それでもGeekbenchと同様の傾向だったので、何か意味があるかもしれません。シングルもGeekbenchと同じ傾向でした。これも8Cが一番良い性能でした。

動作の観察

CpuTopologyRebuildの作者の方も考察されてますが、それと同じ結果が得られました。シングルコアの性能は、8C > 32C > 24Cの順に高性能でした。

アクティビティモニターで、Cinebenchシングルスコア測定中のCPUの負荷を観察しました。32個のスレッドの使用状況が棒グラフで表示されます。

まずは32Cの場合の様子です。シングルスコアのベンチマークなので、一度には一つのコアしか使われていないと思いますが、一定時間累積しての表示なのか、複数の棒グラフが反応してました。それを見ると、全部のコアが区別なく使用されているようです。

次は、24Cの場合の様子です。左半分の16本がPコアで、一つおきに本体とそのHTが表示されていると思われます。棒グラフを見ると、そのHTが選択から除外されている様子がわかります。PコアとEコア（おそらく右半分の16本）はあまり区別なく選択されてます。

最後は8Cの場合の様子です。Pコアの物理コア部分のみが選択されてます。右半分のEコアは選択から外れてました。

32Cのシングルコアベンチマークでは、PコアのHTが選択されることもあるので、スコアが下がるのではと予想してました。しかし24Cより好成績でした。想像ですが、HTが選択されても、対応する物理コアが動いていなければ、物理コアと同等の性能が出せるのかもしれません。その結果、作者の方の分析通り、Pコアが選択される確率の高い32Cの方が24Cよりも好成績になったのかと思われます。

ちなみに、マルチコアのベンチマーク時は、どのコア設定でも大差ありませんでした。CPU使用状況を見ると、ほぼどのスレッドもフルに稼働しています。重い作業をさせるベンチマークテストでは、スレッド優先順位が適切に設定されていても、結局は全てのスレッド総出で使用されるので、差が出ないのかと思いました。

まとめ

13900KFのコア数設定を調整するCpuTopologyRebuild.kextを使ってみました。物理コアとハイパースレッド (HT) の数をmacOSに適切に伝えるためのkextです。ベンチマークテストで比較した結果、argで-ctrsmtをつけてこのkextを使い、物理コア8に設定することで、より良い性能を得られました。素晴らしいkextを作っていただきありがとうございます。

Raptor Lake-S 13900KFの32コアをmacOSで使う

Sat, 29 Oct 2022 19:44:20 +0900

IntelのデスクトップPC向け・第13世代CoreプロセッサーRaptor Lake-Sが発売されました。そこで、GPU非搭載版のCore i9-13900KFをmacOS Ventura 13.0で使用し、どれくらいのスコアが出るのか確認しました。マルチコアの結果は、Geekbench 5の場合、M1 MaxとUltraの中間の性能でした。Cinebench R23では、Ultraの1.5倍弱の性能でした。

マシン構成

使用したマシンは、以下で紹介したASRock Z690 Steel Legend WiFi 6Eを使ったマシンです。macOSはVentura 13.0、OpenCoreは0.8.5で、kext類は最新です。

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

今までは12900Kを使っていましたが、これを13900KFに差し替えます。macOSでは内蔵GPUをサポートしていないので、GPUなしのKFモデルにしました。少しでも電力が抑えられるかなと思ったのですがどうでしょうか。Z690マザーボードはBIOSを最新にするとRaptor Lake-Sに対応します。なので、12900Kで動かしている間に、BIOSを更新しておきました。

次に、CPUを交換して起動します。Alder Lake-SとRaptor Lake-Sは、ほとんど同じCPUなのか、OpenCoreのconfig.plistなどの書き換えは全く不要でした。何事もなく、問題なくmacOS Ventura 13.0が起動しました。アクティビティモニターでコア活動状況を見ると、32本の棒グラフが並びます。

Geekbench 5でベンチマーク

Geekbench 5でベンチマークを取りました。シングルは2200以上、マルチは19700以上のスコアが出ます。詳細を見ると、32コアのCPUになっています。HTもEコアも全部通常のコアに見えています。

GeekbenchブラウザのサイトにあるMac Studio M1 Max / Ultraのスコアと、今回測定した13900Kのスコア（3回の平均）を比べたのが下の図です。シングルコアでM1 Max/Ultraの1.3倍くらい、マルチコアでM1 Maxの1.6倍、M1 Ultraの0.85倍くらいでした。

Geekbench 5スコアの比較

Geekbenchブラウザのページで、13900KFのスコアを見ると23000くらいです。Windowsでのスコアなので、macOSではここまでいかないと思われます。M1 Ultraのスコア越えは難しいかと思いました。実は使用しているCPUクーラーが貧弱です。

CPU温度が測れていないのでなんともいえませんが、クーラを強化するとスコア改善するかもしれません。

Cinebench R23でベンチマーク

Cinebenchのスコアも測定しました。3回実行した平均値では、 CPU (Single Core)が1986 pts、CPU (Multi Core)が35390 ptsでした。

ネットの情報によるとMac Studio M1 UltraのCinebench R23のスコアは、シングルで1562, マルチで23566だそうです。またMac Studio M1 MaxのCinebench R23のスコアは、シングルで1562, マルチで12402だそうです。以前に測定した12900Kのスコアは、シングルが1825、マルチが26520でした。これらをグラフで比較します。Intel CPUはCinebenchに強いようです。

まとめ

Intel Core i9-13900KFをmacOS Ventura 13.0で使用しました。Z690マザーボードのBIOSを最新版にした以外、12900K設定のままでmacOSが起動しました。ベンチマークをしたところ、Geekbench 5では、M1 MaxとM1 Ultraの中間、Cinebench R23ではM1 Ultraより良い結果が得られました。12900Kより性能が上がってます。12900Kの記事は以下をご覧ください。

Alder Lake 12900Kの24コアをmacOSで使う

次の世代のインテルCPUは、またアーキテクチャが変化すると言われています。macOSもApple Siliconに移行しつつあるので、これがmacOSが稼働する最後のCPUになるかもしれません。ネットの評価記事では、13700Kや13600Kの方が、発熱も穏やかでコストパフォーマンスが良いとも言われてますので、その選択も良いと思います。発熱に関しては、貧弱な空冷CPUクーラでしたが、短時間のベンチマークでしたら平気でした。

Ventura のUSBインストーラを作ってクリーンインストール

Tue, 25 Oct 2022 18:28:02 +0900

macOS Ventura 13.0がいよいよ公開されました。Monterey 12.6でダウンロードし、起動用USBメモリを作り、クリーンアップデートしました。最新版のOpenCore (0.8.5) とkext類でMontereyが動いていれば、通常の作業でアップデートできるはずです。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

作業に使ったシステム構成

本日 (日本時間2022/10/25)、macOS Ventura 13.0 が正式配布されました。Montereyが配布されたのは去年の10月26日でしたので、ほぼ同じでした。Montereyの最初のバージョンが12.0.1だったのと同様、Venturaも13.0.1が最初の配布バージョンになりました。インストール先のマシンは、以下で、Z690マザーボードに12900Kを搭載しています。グラフィックスはRadeon RX 6600です。ブートローダはOpenCore 0.8.5でkext類は最新にしてあります。

ASROCK Z690 STEEL LEGENDのUSBを設定する

直近まで使っていたmacOSはVentura 13.0 RC (22A380)です。ベータ版ですが、あまりに快適なのでそのままメインで使ってました。ただ、パブリックベータが公開される前まで使っていたMontereyとは別のSSDで使ってました。それで、3ヶ月以上ぶりに、Monterey 12.5が入ったSSDから起動しました。WDの1TB M.2 SSD, WDS100T2B0Cです。ベータ版を使っている間に12.6が公開されましたので、まずは12.6にアップデートしました。その上で、Venturaへアップデートしました。

Venturaアップデートは自動

Venturaに更新したマシンの構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600で、Ventura公開前の最新版で12.6が動いてます。

このMontereyから、「システム環境設定」「ソフトウェアアップデート」を開いたところ、Venturaへのアップデートができるようになってました。容量は3.92GBだそうです。小さい気がしますが、多分必要に応じて追加でダウンロードするのかと思います。

ちなみに、「ほかにもアップデートがあります。」の表示が出ています。これをクリックすると12.6.1が来ていました。Venturaをすぐインストールしないという人も、こちらは入れておいた方が良いと思いました。

Venturaへのアップデート画面で「今すぐインストール」ボタンを押したところ、まずはダウンロードが開始します。

ダウンロード終了後は、アップデートがスルスルと進んで行きました。今までのメジャーアップデートでは、「macOS Venturaをインストールするには、”続ける”をクリックしてください」という画面が出て、そこで中断できました。今回は自動で進むようです。そういえばVenturaで最初にベータ版を導入した時も、自動更新でした。ベータ版でも後には中断できるようになったので、この仕様も、今後変更されるかもしれません。

ということであっけなくVenturaにアップデートされました。快調に動作してます。ビルドは22A380で、Ventura RC 2と同一です。RC 2がそのまま公式版になったようです。

クリーンインストールの手順

Montereyへの上書きインストールが思いがけず完了してしまいましたが、せっかくの年に一度のメジャーアップデートです。現在の起動ディスクであるM.2 SSDの内容を綺麗さっぱりと全消去して、クリーンインストールしようと思います。実は、ホームディレクトリは、別のAPFSボリュームに作ってあるので、起動M.2 SSDを消去してもそれほど面倒なことにはなりません。そこで次の手順でアップデートを進めます。

Venturaインストーラをダウンロードする
USBメモリを用意してVenturaインストールUSBを作る
USBメモリのESPに現在のESPをコピーして起動できるようにする
USBメモリーからインストーラを起動する
インストーラからディスクユーティリティを起動し、M.2 SSDを消去する
インストーラからVenturaをインストールする

1. Venturaインストーラをダウンロード

先ほどの自動アップデート時にダウンロードされたインストーラは、アップデート終了時に消えてしまってます。ということで再度、インストーラをダウンロードし直すことにしました。すでにVenturaになってしまった環境から、App Storeに行き、Venturaを検索したらありました。

入手ボタンをクリックすると、ソフトウェアアップデートが動いてダウンロード開始しました。今回は、なぜか12.15GBとなってます。これなら全部を一括ダウンロードしてくれそうです。

ダウンロード終了すると、インストーラが起動します。今回は、「macOS Venturaをインストールするには、”続ける”をクリックしてください」というダイアログがちゃんと出て、中断可能です。

ここで中断すると、これもいつものようにアプリケーションフォルダに「macOS Venturaインストール」が出来上がっていました。先ほどのようにインストール作業で消えてしまうことがあるので、バックアップしておきましょう。

2. VenturaインストールUSBを作る

次に、VenturaインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもVenturaをインストールできるUSBメモリになります。ターミナルを使用して、Venturaインストーラの中のContents/Resourcesに移動するとcreateinstallmediaというファイルがあります。そこで以下のコマンドを入力します。

$ cd /Applications/Install\ macOS\ Ventura.app/Contents/Resources/
% sudo ./createinstallmedia --volume /Volumes/USB/
Password: 
Ready to start. 
To continue we need to erase the volume at /Volumes/USB. 
If you wish to continue type (Y) then press return: y 
Erasing disk: 0%... 10%... 20%... 30%... 100% 
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100% 
Making disk bootable... 
Copying boot files... 
Install media now available at "/Volumes/Install macOS Ventura"

3. USBメモリのESPに現用のESPをコピーする

こうして作成したインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。それぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ&ドロップすれば良いです。この先、M.2 SSDは消去しますので、他にも必要なデータがありましたらバックアップしておきます。

4. USBメモリーからインストーラを起動する

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにVenturaインストーラが見えるはずです。

まず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。
また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。

なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はXplistを使って変更している様子です。

これで起動項目にUSBメモリのインストーラが現れるようになります。Venturaアイコンのボリュームが、USBメモリーです。このInstall macOS Venturaを選択して起動します。

5. インストール先ボリュームを消去する

USBメモリから起動すると、下のようなメニューが現れます。

ここでディスクユーティリティを選んで、インストール先M.2 SSDを綺麗さっぱりフォーマットしました。インストール先のAPFSボリュームグループを選択し、名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。

6. Venturaをインストールする

Disk Utilityを閉じると、またメニューに戻ります。次にmacOS Venturaインストールを選択します。するとおなじみのmacOSインストーラが起動します。後は、いつものようにインストールを進めていくだけです。

何度かの再起動の後で、インストール先ドライブにつけた名前 (ここではMacintosh HD) の選択肢が現れ、選択されています。これで起動します。

さらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。あとはいつものように、設定を行ないます。

インストール終了したあと、このMacについてを確認しました。

これでM.2 SSDから起動します。上の手順では、APFSボリュームグループをフォーマットしてたのでESPの内容は無事でした。ドライブ全体をフォーマットするとESPの内容も消えてしまいます。その場合は、USBメモリのESPの内容を、M.2 SSDの方に書き戻しておきます。

まとめ

OpenCoreで起動しているZ690マシンにVenturaをクリーンインストールしました。そのために、単体で起動してVenturaがインストールできるUSBメモリを作りました。ベータ版の時から安定していましたが、公開版Venturaも快適に動いています。

OpenCore 0.8.4 から0.8.5に更新

Sat, 08 Oct 2022 14:54:57 +0900

OpenCoreの0.8.5が公開されていたので0.8.4からアップデートしました。config.plistに追加された項目はありませんので、0.8.4 のconfig.plistそのままでも動くはずです。

0.8.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はいつもより少ない様子でした。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.5とmacOS 13 Public Beta 8で動作確認している手元のマシンは以下です。今回のタイミングでのkext類のアップデートはありませんでしたので、kext類は0.8.4の時のままです。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Ventura PB8

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点はありませんでした。変更なしで、問題なく起動しました。間もなくリリースされるmacOS 13も安定して動きそうです。

OpenCore 0.8.4にしてmacOS Ventura 13 Beta 5に更新

Sat, 10 Sep 2022 16:38:37 +0900

OpenCoreの0.8.4が出て、macOS Ventura 13 Beta 5も出たので両方を更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。

OpenCoreの0.8.4が公開されていたので0.8.3からアップデートしました。config.plistに追加・変更された項目はありませんので、0.8.3のconfig.plistそのままで動きます。

一方で、VenturaのPublic Beta 5の案内も「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5342fでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。

macOS Ventura 13 Beta 4をインストール

Sat, 27 Aug 2022 23:38:51 +0900

Ventura Public Betaのアップデート、Public Beta 4が出たので、Beta 3からアップデートしました。公開版OpenCore 0.8.3で問題なく動作します。

Ventura Public Beta 4が来た

昨夜（米国時間で2022/8/26）のうちに VenturaのPublic Beta 4が配布されていたようです。「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。Beta 3の時は、アップデートに失敗して全体をダウンロードし直しましたが、今回はちゃんとアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。

公開版OpenCore 0.8.3で問題なく動作します。ビルド番号は22A5331fでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。

macOS Ventura 13 Beta 3をインストール

Sat, 20 Aug 2022 10:52:36 +0900

Ventura Public Betaのアップデート、Public Beta 3が出たので、Beta 2からアップデートしました。公開版OpenCore 0.8.3で問題なく動作します。

Beta 3が来たけど更新できない

米国時間で2022/8/9に VenturaのPublic Beta 3が配布されていました。Developer Beta 5に相当するビルドらしいです。いつものように、Public Beta 2の、「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。

ただ、今回は「今すぐアップデート」ボタンを押したところ、一瞬でダウンロードが終わって「再起動」ボタンが現れるものの、再起動しません。手動で再起動してもインストール用ボリュームができていないようでした。準備が完璧じゃないのかと思い、しばらくの間放置していました。でも状況が変わらないようなので、gibMacOSを使ってPublic Beta 3のインストーラ本体をダウンロードすることにしました。

gibMacOSでダウンロードする

gibMacOSはアップルの公開サイトから入手できるmacOSを探してダウンロードしてくれるスクリプトです。corpnewtさんのgithubへ行って、gibMacOSの一式をzip形式でダウンロードしました。

GitHub - corpnewt/gibMacOS: Py2/py3 script that can download macOS components…

Python版やシェルスクリプト版などが入ってますが、今回は、シェルスクリプト版のgibMacOS.commandを使用しました。gibMacOSのディレクトリに移動したあと、以下のように起動します。

% ./gibMacOS.command

起動するとmacOSの公開版の一覧が出ます。Public Beta版も公開版として含まれていました。この番号（ここでは3番）を指定してダウンロードします。

3. macOS Ventura beta 13.0 (22A5321d)
 - 012-51393 - Added 2022-08-09 17:07:05 - 11.97 GB

ダウンロードされたファイル類は、gibMacOSディレクトリの中のmacOS Downloads/public/の中に保存されてます。

ここでInstallAssistant.pkgを開くと、インストーラが起動して、/ApplicationsフォルダにInstall macOS Ventura betaが出来上がります。これはインストール後に消えてしまいますので、必要ならばバックアップしておきます。

Ventura Beta 3をインストールする

Install macOS Ventura betaを起動すると、お馴染みのインストール画面になります。インストール先を指定して続けると、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームから再起動します。

OpenCore 0.8.3にしてあれば問題なく動作しました。ビルド番号は22A5321dでした。Beta 2と同様、安定しているのでメインで使用します。

OpenCore 0.8.3 (NB) から0.8.3に更新

Sat, 06 Aug 2022 15:44:51 +0900

OpenCoreの0.8.3が公開されていたので0.8.3 Nightly Buildからアップデートしました。0.8.3公開で、macOS 13対応が確立した印象です。config.plistに追加された項目はありませんので、0.8.2, 0.8.3 (NB) のconfig.plistそのままでも動くはずです。

0.8.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.3とmacOS 13 Public Beta 2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Ventura PB2

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点はありませんでした。変更なしで、問題なく起動しました。macOS 13 Public Betaは非常に安定しているので、このままメインで使い続ける予定です。秋の正式版リリースが楽しみです。

macOS Ventura 13 Beta 2をインストール

Sat, 30 Jul 2022 00:24:08 +0900

Ventura Public Betaのアップデート、Public Beta 2が出たので、Beta 1からアップデートしました。OpenCore 0.8.3で問題なく動作します。0.8.3はKext Updaterで入手したNightly Buildです。

Ventura Public Beta 2が来た

昨夜（米国時間で2022/7/28）のうちに VenturaのPublic Beta 2が配布されていました。Developer Beta 4に相当するビルドらしいです。Public Beta 1の、「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。

OpenCore 0.8.3にしてあれば問題なく動作するようです。ビルド番号は22A5311fでした。Beta 1と同様、安定しているのでメインで使用します。

Monterey 12.5 にアップデートする

Thu, 21 Jul 2022 23:15:30 +0900

macOS Monterey 12.5が配布されていましたので12.4からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.5の情報はまだありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。いつもはVentura public betaを動かしている関係でOpenCore 0.8.3にしてましたが問題ありません。0.8.2での起動もokです。kext類は最新です。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT

システム環境設定のソフトウェアアップデートに、12.5のアップデートの通知が来ていました。

アップデートは、TVとSafariの不具合に対応したものらしいです。「今すぐインストール」ボタンを押すと、2.2GBのファイルがダウンロードされます。

その後、自動的に4回再起動して、12.5に更新されました。前回同様、1回目の再起動にはmacOS Installerという名前のボリュームが現れ選択されていて、2回目以降はこのボリュームは消えて、通常の起動ボリューム（Macintosh HDという名前にしてます）が選択されました。

いつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.5が起動しました。ビルドは21G72です。

12.5が起動するESPのファイル一式はここに置いてあります。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

Windowsだけで作るmacOSインストーラUSB

Thu, 21 Jul 2022 13:59:59 +0900

macOSインストール用のUSBメモリをWindowsだけを使って作成しました。まず、OpenCoreパッケージに付属しているmacrecovery.pyというPythonプログラムを使ってMacの復元イメージをダウンロードし、次にFAT32のUSBメモリに保存します。これでMacで起動するRecoveryボリュームを作ることができました。手順だけを手短に見たい人は、以下のStep: 1, Step: 2, Step: 3の節を見てください。

macOS導入USB

macOSをインストールするためのインストール用USBメモリは、通常はmacOS上で作成します。macOSが動いていないとmacOSをインストールできないので、Macを持っていないと鶏と卵状態に陥ります。Windowsだけを使ってmacOSをインストールすることも、不可能ではないけどとても面倒です。

・・・と、思っていたのですが、試してみたところ予想していたよりずっと簡単でした。OpenCoreのバニラなインストールガイドで知られているDortaniaさんの説明ページを参考にしました。

このページを見るとややこしそうに見えますが、基本的には、

OpenCoreパッケージに入っているPythonプログラムを起動してmacOS復元イメージ（これを使うとmacOSをインストールできる）をダウンロードする
それをFAT32でフォーマットしたUSBメモリに入れる

だけです。

macOS環境ならば、Appleが配布しているmacOSインストーラの中にある、createinstallmediaコマンドを使ってインストーラUSBを作る方法が、Apple公式の方法で簡単です。この方法で作るUSBメモリは、HFS+でフォーマットされていて、MacやOpenCoreの起動選択画面ではそのOSのアイコンで表示されます。MontereyのインストーラUSBなら、下の写真にある「Install macOS Monterey」のようにOpenCoreの起動ボリューム選択画面に現れます。

これと同じものをWindowsで作るには、Windowsとは無縁なHFS+フォーマットのボリュームをなんとか作り出さないといけないので、とても大変だと思ってました。Dortaniaさんのページで紹介されているのは、HFS+形式USBメモリではなく、上の写真の右端に見切れて映っている、「Recovery 12.x (dmg)」という歯車アイコンに相当する復元用イメージを作る方法でした。

Step1: 復元ファイルをダウンロード

Windowsから、OpenCoreダウンロードのサイトを開き、最新版パッケージ一式をダウンロードします。ダウンロードサイトはここです。

Releases · acidanthera/OpenCorePkg

ここから、OpenCore-x.x.x-RELEASE.zipをダウンロードします。ダウンロードしたファイルは、Downloadsディレクトリの中に、OpenCore-x.x.x-RELEASE.zipというファイル名で保存されてます。次に、このzipファイルの中にあるPythonプログラムを実行します。

Pythonの実行のために、通常はWindowsにPythonをインストールします。手元のWindowsマシンでは、WSLの UbuntuにすでにPythonをインストール済みだったので、以下では、WindowsとWSL Ubuntuを行ったり来たりして作業しました。WindowsにPythonがインストール済み、もしくはWSLを使っていない場合は、Windows側でPythonを実行してください。

Pythonの実行をWSL環境で行うために、Ubuntuを開けて、OpenCoreのzipファイルを作業しやすい場所にコピーします。次に、zipを解凍し、その中のUtilities/macrecoveryというフォルダに移動します。そしてそこにあるmacrecovery.pyというPythonプログラムを起動します。以下がその作業です。

cp /mnt/c/Userx/xxxx/Downloads/OpenCore-x.x.x-RELEASE.zip .
unzip OpenCore-x.x.x-RELEASE.zip
cd Utilities/macrecovery
python3 ./macrecovery.py -b Mac-E43C1C25D4880AD6 -m 00000000000000000 download

macrecovery.pyは、http://osrecovery.apple.comというAppleのサイトから、特定のロジックボード用のリカバリーファイルをダウンロードするプログラムのようです。-bオプションでロジックボードのIDを指定します。上の操作で指定した番号 (Mac-E43C1C25D4880AD6) は、MacBook Pro (13-inch, Early 2015)、機種ID MacBookPro12,1のものです。検索したところ、以下のページにBoard ID一覧がありました。

List of Mac BoardID, DeviceID, Model Identifiers & Machine Models

MacBookPro12,1の機種対応の最終OSがMontereyなので、この指定でMontereyをインストールするリカバリーイメージをダウンロードできます。MacBookPro12,1はVentura未対応なので、この先もMontereyがダウンロードできるはずです。

他のmacOS、例えばBig Surのリカバリーイメージをダウンロードしたい場合は、最終サポートOSがBig Surである機種のロジックボードIDを指定します。Dortaniaさんのガイドでは、Big SurではMac-42FD25EABCABB274を指定することになってます。これはiMac (Retina 5K, 27-inch, Late 2014) iMac15,1のIDで、最終サポートOSはBig Surです。

macrecovery.pyを実行すると、

BaseSystem.chunklist
BaseSystem.dmg

という2つのファイルが出来上がってます。この先、Windowsでの操作を行うので、Windowsからアクセスしやすいように、Downloadsディレクトリに戻しておきます。

cp BaseSystem.* /mnt/c/Users/xxxx/Downloads/.

Step2: USBメモリを初期化する

次に起動用USBメモリを初期化します。GUIDパーティションマップ (GPT)で用意したパーティションをFAT32でフォーマットします。一般的なフォーマットなので、特に難しいところはないように思われました。実際、macOSのディスクユーティリティで作ったMS-DOS (FAT) (GUIDパーティションマップ)のUSBメモリもそのまま使えました。ただ、macOSからUSBメモリの名前を変更したところ、通常の起動ドライブとして見えてしまうようになり、リカバリーイメージとしては表示されなくなり、使えなくなりました。微妙なパーティション・フォーマットの違いで動作しなくなるようです。

Dortaniaさんの手順では、WindowsでUSBメモリをフォーマットするツールとして、

Windows標準のDisk Management （日本語名「ディスクの管理」）
Rufusというオープンソフトウェア
Windows標準のdiskpart

を使う3つの方式が紹介されています。ここではWindows標準装備の1. と 3.の方法を試し、動作することを確認しました。

Disk Managementを使う

Disk Managementは日本語名で「ディスクの管理」というツールです。macOSのディスクユーティリティに相当するツールかと思います。これで、USBメモリを選択し、初期化します。すでにGPTのパーティションが用意されていたら、それを削除して、未割り当てにして、「新しいシンプルボリューム」を作ります。

このメニューを選択すると、「新しいシンプルボリュームウィザード」というプログラムが起動します。これを用いて、FAT32のボリュームを作成します。ここでボリュームラベルを指定することもできます。

これでFAT32のUSBメモリが完成するので、Step 3に進んで、ファイルをコピーします。

Disk Managementは操作が簡単ですが、パーティションスキームを作り直す方法がわかりませんでした。MBR (Master Boot Record) でパーティション作られたUSBメモリは、FAT32でフォーマットされていてもリカバリーには使えないのですが、これをGPTに変更する方法がメニューには見つかりませんでした（Windowsスキルが低くてすみません）。次に示すdiskpartを使う方が確実だと思います。

diskpartを使う

diskpartもWindows標準搭載の、20年以上昔からあるツールです。CUIでサクサク操作できて良いです。これを用いると、パーティションの設定から完璧に作り直せるので、USBメモリを間違いなく初期化できます。Windowsメニューからdiskpartとタイプすると起動します。USBメモリはUSBポートに挿しておきます。

Microsoft DiskPart バージョン 10.0.22000.653

Copyright (C) Microsoft Corporation.
コンピューター: XXXXXXXXXX

DISKPART>

list diskコマンドでUSBメモリの番号を見つけて（ここでは2番）それを選択します。USBメモリは32GBなので、これに間違い無いです。

DISKPART> list disk
 ディスク 状態 サイズ 空き ダイナミック GPT 
 ------------ ------------- ------- ------- --- ---
 ディスク 0 オンライン 465 GB 0 B *
 ディスク 1 オンライン 232 GB 1024 KB *
 ディスク 2 オンライン 29 GB 127 MB *
DISKPART> select disk 2
ディスク 2 が選択されました。

次に、このUSBメモリを、

cleanして（ディスク構成情報を削除）
GPTに変換して（最小のパーティションができる）
primaryパーティションを作って（確認して、選択して）
fat32でフォーマットして
Eドライブに割り当てて
出来上がったvolumeを確認

します。その様子を下に示します。

DISKPART> clean
DiskPart はディスクを正常にクリーンな状態にしました。
DISKPART> convert gpt
DiskPart は選択されたディスクを GPT フォーマットに正常に変換しました。
DISKPART> create partition primary
DiskPart は指定したパーティションの作成に成功しました。
DISKPART> list partition
 Partition ### Type Size Offset
 ------------- ------------------ ------- -------
 Partition 1 予約済み 15 MB 17 KB
* Partition 2 プライマリ 29 GB 16 MB
DISKPART> select partition 2
パーティション 2 が選択されました。
DISKPART> format fs=fat32 quick
 100% 完了しました
DiskPart は、ボリュームのフォーマットを完了しました。
DISKPART> assign letter=e 
DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。
DISKPART> list volume
 Volume ### Ltr Label Fs Type Size Status Info
 ---------- --- ----------- ---- ---------- ------- --------- --------
 Volume 0 NTFS Partition 465 GB 正常
 Volume 1 FAT32 Partition 100 MB 正常 システム
 Volume 2 C NTFS Partition 232 GB 正常 ブート
 Volume 3 NTFS Partition 635 MB 正常 非表示
* Volume 4 E FAT32 Partition 29 GB 正常

太字部分が入力したコマンドです。これでエクスプローラーからEドライブとして見えます。

Step3: USBメモリにコピーする

次に、ダウンロードファイルをUSBメモリにコピーします。ここから先はエクスプローラーから操作できます。USBメモリに、以下の2つのフォルダを作ります。

com.apple.recovery.boot
EFI

com.apple.recovery.bootには、Step 1で入手した、

BaseSystem.chunklist
BaseSystem.dmg

を入れます。エクスプローラーのコピー・ペーストで行いました。

またEFIには、現在macOSを動かしているコンピュータのEFIをそのままコピーしておきました。

今回試したコンピュータは、ASRock Z690 Steel Legend + 12900K + RX 6600XTの組み合わせです。EFIはこちらに置いてあります（使う場合はシリアル番号などを入れてください）。ディレクトリ構成は結局、以下のようになりました。

com.apple.recovery.boot
- BaseSystem.chunklist
- BaseSystem.dmg
EFI
- APPLE
- BOOT
- OC

これでmacOSがインストール可能なUSBメモリが完成しました。

USBメモリで起動

このUSBメモリを挿してコンピュータを起動します。大抵は、起動可能なUSBメモリが挿さっているとそこから起動するようですが、BIOSメニューから確認・設定するのが確実かもしれません。USBメモリのルートにあるEFIディレクトリに、EFIファイル一式が正しくコピーできていれば、OpenCoreの起動ボリューム選択画面が表示されます。

ただ、この中にRecoveryイメージはありません。実は、使用しているconfig.plistで、選択メニューに復元イメージが表示されないよう設定してあるためでした。そのように設定されている場合、スペースキーを押すと、全部の候補が現れます。その結果、macOSがインストールされたそれぞれのボリュームの横に、Recovery xxx (dmg)という歯車アイコンの選択肢が現れます。実際のMacにも現れる復元用の起動ボリュームで、これを選択してOSの再インストールなどが可能です。

そして並びの左端に、今回Windowsだけを使って作成したUSBメモリが現れました。今回使用しているOpenCanopyの設定アイコンでは、他のRecoveryアイコンと違ってオレンジ色です。外付けドライブにあることで、色がオレンジのようです。アイコンの名前がNO NAMEなのは、FAT32のドライブ名のデフォルトがNO NAMEだからです。

これを選択して起動すると、リカバリーのメニューが現れます。ここでmacOS Montereyのインストールを選択すると、

インストーラが起動しました。この先インストールを進めることで、Montereyを動かすことが可能でした。

まとめ

Windowsだけを用いて、macOSをインストールするUSBメモリを作り、動作を確認しました。以前調べた方法はもっと複雑でしたが、今回はあっけなくできてしまいました。macrecovery.pyプログラムを開発された皆さんのおかげだと思います。Mac本体を持っていない人でも簡単にmacOSをインストールできると思います。その場合でも、OSを使わせてもらうお礼にApple製品やサービスを買ってあげてください。

macOS Ventura PBの導入用USBを作る

Wed, 20 Jul 2022 15:41:26 +0900

macOS 13 Venturaを起動してインストールできるUSBメモリを作成しました。配布されているpublic betaから、いつものようにcreateinstallmediaコマンドで作成します。USBメモリのESPには、すでにVenturaが動作しているOpenCoreとそのファイルを入れました。このUSBで起動して、Venturaをインストールできました。

Ventura PBの配布方式変更

macOS 13 VenturaのPB (public beta)を使用して10日近く経過しました。とても安定しているので、もはやメインOSとして使ってます。PBが配布された当初は、マイナーアップデートの時のように、「今すぐアップグレード」ボタンを押すと、本当にすぐにアップデートが開始してしまい、中断できませんでした。

最近試したところ、いつものメジャーアップデートのように、インストーラプログラムがApplicationsフォルダに格納されるようになってました。本番に備えて改善されたようです。ソフトウェアアップデートのアイコンも、Venturaのものに変わってました。ダウンロードされるデータサイズも12.3GBに増加してます。なので、インストールし直すことにしました。インストールしなおしても、ビルド番号は変更ないようです (22A5295i) 。

ソフトウェア・アップデートで、「今すぐアップグレード」を押すと、ダウンロードが開始され、終了するとインストーラプログラムが起動します。

ここでインストールを中断します。メニューから終了を選んで終了させると、Applicationsフォルダにインストーラが見つかります。中断せずにインストールを完了すると、このインストーラが消えてしまいます。他の場所にコピーをとっておくと良いです。これもいつも通りの動作です。

インストール用USBメモリを作る

この先も、いつものmacOSインストール用メモリ作成の手順と全く同じです。まずはUSBメモリをフォーマットします。ディスクユーティリティでUSBメモリの項目を選んで、「消去」ボタンを押し、「APFS」フォーマット「GUIDパーティションマップ」方式でフォーマットします。名前はなんでも良いのですがUSBとしました。

次に、ターミナルを開き、VenturaインストーラのResourcesディレクトリに移動します。そこにあるcreateinstallmediaコマンドを実行します。インストール先には、上で作成したUSBメモリを指定します。

$ cd /Applications/Install\ macOS\ Ventura\ beta.app/Contents/Resources/ 

$ sudo ./createinstallmedia --volume /Volumes/USB 
Password:
Ready to start.
To continue we need to erase the volume at /Volumes/USB.
If you wish to continue type (Y) then press return: y
Erasing disk: 0%... 10%... 20%... 30%... 100%
Making disk bootable...
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100%
Install media now available at "/Volumes/Install macOS Ventura beta"

この後、diskutil listコマンドでUSBメモリと起動中のドライブのEFIの場所を探して、それぞれをマウントして、ファインダーでEFIフォルダをコピーします。

% diskutil list

(略)
/dev/disk10 (external, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *31.4 GB disk10
 1: EFI ⁨EFI⁩ 209.7 MB disk10s1
 2: Apple_HFS ⁨Install macOS Ventur...⁩ 31.0 GB disk10s2
(略)

% sudo diskutil mountdisk disk10s1

USBメモリで起動する

今動いているEFIの内容を、USBメモリのESPにコピーできていれば、USBメモリから起動できます。OpenCoreの選択画面には、インストーラが現れます。今動いているドライブで起動して、OpenCoreの起動ボリューム選択画面でUSBメモリを選択しても良いです。

これを選択すれば、Macをリカバリーする画面が現れ、この中からドライブのフォーマットやVenturaのインストールを行えます。

macOS Ventura 13 Beta をインストール

Tue, 12 Jul 2022 16:05:47 +0900

VenturaのPublic Betaをインストールしました。OpenCoreとkext類をnightly build版にアップデートしておけば、macOS 12.4を起動する設定のままで問題なくインストール、起動できました。

Ventura Public Betaが来た

昨夜（米国時間で2022/7/11）のうちに VenturaのPublic Betaが配布されていました。Apple Beta Software Program登録済みMacの「システム環境設定」「ソフトウェア・アップデート」に登場してました。容量は3.84GBだそうです。前回のMontereyパブリックベータの容量が11.73GBでしたので、4分の1です。今回のアップデートは小規模なようです。インストールしたマシンは、ASRock Z690 Steel Legend + 12900K + RX 6600 XT + OpenCore 0.8.2 + macOS Monterey 12.4で構成した自作PCです。

追記 (2022/7/20)：配布方式が変更されたようで、従来のメジャーアップデートと同じくインストーラをダウンロードできるようになりました。こちらをご覧ください。

macOS Ventura PBの導入用USBを作る

以下の説明は古い情報ですので取り消しておきます。

いつものメジャーアップグレードでは、「今すぐアップグレード」ボタンを押すとインストーラがダウンロードされて起動しますが、そこで中断可能でした。しかしVenturaのベータ版は、アップデートが自動的に進んで、現在のmacOSを書き換えてしまうらしいです。

【要注意】macOS Venturaベータ版のインストール前に絶対知っておくべき落とし穴【…

パブリックベータでも同様と思われたので、新しいSSDを用意して、macOS 12.4とOpenCore 0.8.2で起動するように設定しておきました。そしてSSDからソフトウェアアップデートしました。実際に、ボタンを押すと自動でアップデートが進んでしまいました。

再起動でループ

ダウンロードが終わると再起動します。いつものように、ターゲットのドライブ（ここではVenturaという名前をつけてます）以外に、インストール用のmacOS Installerという暫定ドライブができていて、これから起動しようとします。しかしこの先、再起動してしまい、それが無限に続きます。

そこでOpenCoreをnightly版に入れ替えました。Kext UpdaterからOpenCore 0.8.3をダウンロードします。そして現在のEFIパーティションのファイルを、nightly build版のものに置き換えました。

カーネルパニック

すると先に進んだのですが、今度はカーネルパニックになりました。

そこでkext類もnightly build版にしました。これもKext Updaterから取り寄せました。nightly buildsから使用中のkextを取り寄せます。これをEFIパーティションにあるものと差し替えます。

なおOpenCoreとkextのnightly buildは以下のサイトからも入手できます。コメントで教えていただきました。Kext Updaterで入手するものより新しいバージョンが手に入ります。古いバージョンも入手できるので元に戻す場合にも便利です。

Builds

Venturaが起動

この結果、インストールが進み、いつものアップデートと同じように合計3回再起動し、Venturaが起動しました。バージョンは、13.0 Beta (22A5295i)でした。（ベータ版はスクショ禁止なのでバージョン番号以外の部分をぼかしてあります）

というわけで、OpenCoreとkextを最新のnightly build版にしておけば、特に設定を変えることなくインストールできました。今のところ問題なく動作してます。このままメインコンピュータとして使い続けることにしました。

Metal 3対応

システム情報・ハードウェア・グラフィックス／ディスプレイを見ると、RX 6600 XTがMetal 3対応になってました。

AMD Radeon RX 6600 XT:

 チップセットの機種: AMD Radeon RX 6600 XT
 種類: GPU
 バス: PCIe
 PCIeレーン幅: x16
 VRAM（総量）: 8 GB
 製造元: AMD（0x1002）
 装置ID: 0x73ff
 リビジョンID: 0x00c1
 ROMリビジョン: 113-3E4480U-S6L
 Metal対応: Metal 3
 ディスプレイ:

ASRock Z690 SLを最新BIOS (8.01) に更新

Wed, 06 Jul 2022 22:59:31 +0900

ASRock Z690 Steel Legendで作ったmacOSマシンは安定して動いていたのですが、BIOSを8.01にアップデートしたら起動途中で止まるようになってしまいました。tonymacx86で紹介されていた修正で起動するようになりました。こちらのマシン構成です。（ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4です。）

ASROCK Z690 STEEL LEGENDのUSBを設定する

tonymacx86で、BIOSを最新版の8.01に上げると起動が止まることと、その解決策を教えてもらいました。BIOSのネットワーク経由アップデート機能を動かすと、6.03のままで最新と言われていたので気づかなかったのですが、サポートサイトで確認したら6月に最新版が2個も出てました。それで7を飛ばして8.01をUSBメモリにダウンロードして、BIOSの更新を試みました。今まで、BIOS更新しても何の問題もなかったのですが、今回は、tonymacx86で教えてもらったように、

Stuck on [EB|#LOG:EXITBS:START]

と言うメッセージが出て止まってしまいました。起動ドライブの選択をした後の、macOSの読み込みに取り掛かるくらいのタイミングです。

この問題は、config.plistで、

Booter -> Quirks -> SetupVirtualMap をTRUEにする

ことで解決するとのことです。その通り設定したら、起動するようになりました。OpenCore 0.8.2に上げたことでもありますので、またEFIをアップロードしておきました。ご利用ください。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

OpenCore 0.8.1から0.8.2に更新: Ventura祭に備える

Wed, 06 Jul 2022 00:34:40 +0900

OpenCoreの0.8.2が公開されていたので0.8.1からアップデートしました。今回のアップデートはmacOS 13対応の項目が多いです。config.plistに追加された項目はありませんので、0.8.1のconfig.plistそのままでも動くはずです。

0.8.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.2とmacOS 12.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点はありませんでした。変更なしで、問題なく起動しました。macOS 13に対応するための修正が施されたようで、間も無くリリースされるpublic betaが楽しみです。

「このMacについて」表示でCPUが不明なことへの対処

Fri, 17 Jun 2022 12:31:28 +0900

Intelの12900K CPUを搭載したメインマシンはとても安定しているのですが、「このMacについて」を表示するとプロセッサが不明だと表示されます。弊害はないのですが、見た目が悪いので、それっぽく表示されるように直しました。

プロセッサ表示なんて飾りです

「このMacについて」のプロセッサの表示は単なる飾りで、不明と表示されても何の問題もないらしいです。不明と表示されていてもsysctlコマンドで調べると、以下のように

% sysctl machdep.cpu.brand_string 
machdep.cpu.brand_string: 12th Gen Intel(R) Core(TM) i9-12900K

搭載CPUが正確に認識されていることがわかります。とはいえ、「不明」と表示されるのはみっともないので、それっぽい表示が出るように直すことにしました。対象のマシン構成は以下です。

ASRock Z690 Steel Legend
12900K
Radeon RX 6600 XT
macOS Monterey 12.4
OpenCore 0.8.1

デフォルトは自動検出

表示を直す方法はいくつかあるようですが、今回は、OpenCoreのconfig.plistの中の、PlatformInfo / Generic / ProcessorTypeの値を変更します。設定可能な値は、AppleのSMBIOSヘッダ定義ファイルを見てくださいとのことです。ProcessorTypeのデフォルトは0で、その場合、最もそれらしい値を自動的に提示するようです。大抵の場合は、デフォルトの自動設定で問題ありませんでした。

現在のマシンでも、自動設定でIntel Core i9プロセッサであると正しく自動認識されていると考えられます。それでも「不明」と表示されてしまうのは、Appleの想定外のコア数で使用していることが原因のようです。12900はPコアが8、そのHTが8、Eコアが8ありますが、OpenCoreの機能でこれらを24コアと認識させて使ってます。

24コアのCore i9プロセッサは実存しないので、不明と表示されるようです。

コアを減らしてみる

このことを確認するために、BIOS設定でコア数を減らしてみます。Appleの想定内のコア数ならば、正しく表示されるはずです。そこで下のようにEコアを無効にして起動させます。

するとPコアだけになるので、コア数が8、スレッド数が16になりました。

コア数が8のCore i9プロセッサは実存するので、「このMacについて」のプロセッサ表示が正しく行われるようになりました。

Xeonだと思わせる

飾りでしかない「このMacについて」表示のためにEコアを諦めるのは本末転倒ですので、BIOSでEコアを復活させて、24コア設定に戻します。これで「不明」の表示に戻ってしまいました。そこで今度は、CPU種別自動判定を停止して、24コアでも問題の無いプロセッサに手動で設定することにします。

AppleのSMBIOSヘッダ定義ファイルを見ると、0以外に使用できるProcessor Typeの値がわかります。今回、関係しそうな値は以下のようになってます。コメントの説明によると、Core i9は6/8/10コアが存在することになっていて、当然ですが24コアはありません。その代わりXeon Wならば24コアの構成があり得ることになってます。iMac Proに搭載されているCPUです。

//
 155// Apple Processor Type Information - Processor Types.
 156//
 157 enum {

 ...

 138// <0F01> 08 cores Intel Xeon W Intel Xeon W
 139// <0F01> 10 cores Intel Xeon W Intel Xeon W
 140// <0F01> 12 cores Intel Xeon W Intel Xeon W (10.15+)
 141// <0F01> 14 cores Intel Xeon W Intel Xeon W
 142// <0F01> 16 cores Intel Xeon W Intel Xeon W (10.15+)
 143// <0F01> 18 cores Intel Xeon W Intel Xeon W
 144// <0F01> 24 cores Intel Xeon W Intel Xeon W (10.15+)
 145// <0F01> 28 cores Intel Xeon W Intel Xeon W (10.15+)
 146// <1001> 06 cores Intel Core i9 Intel Core i9
 147// <1001> 08 cores Intel Core i9 Intel Core i9 (10.15+)
 148// <1001> 10 cores Intel Core i9 Intel Core i9 (10.15+)

 ...

 215 AppleProcessorTypeXeonW = 0x0F01, // iMacPro1,1
 216 
 217 AppleProcessorTypeCorei9Type1 = 0x1001, // may not be used
 218 AppleProcessorTypeCorei9Type5 = 0x1005, // SKL-X i9, most likely to be invalid!
 219 AppleProcessorTypeCorei9Type9 = 0x1009 // ideal value for Coffee Lake i9, need confirmation
 220 };
 221

今回のマシンは、PlatformInfo / GenericでiMac Proとして設定しています。なのでそれに搭載されているCPUであると偽装するのも自然かと思いました。そこで、PlatformInfo / Generic / ProcessorTypeの値を明示的にXeon Wの値、すなわち0x0F01、10進数で3841に設定することにしました。

この結果、「このMacについて」のプロセッサ表示がXeon Wになりました。コア数は24と表示されました。

「このMacについて」のCPU表示をXeon Wに変更しても、sysctlコマンドは引き続きCPU種類を正しく認識していました。

% sysctl machdep.cpu.brand_string 
machdep.cpu.brand_string: 12th Gen Intel(R) Core(TM) i9-12900K

OpenCore 0.8.0から0.8.1に更新

Wed, 15 Jun 2022 13:19:24 +0900

OpenCoreの0.8.1が公開されていたので0.8.0からアップデートしました。追加された項目はありませんので、0.8.0のconfig.plistでもそのままでも動くはずです。

0.8.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.1とmacOS 12.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi。これらに加えて、新しく追加されたResetNvramEntry.efiも入れておきました。
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点は以下でした。

Misc/SecurityのAllowNvramResetが消えてました。今まではtrueに設定していました。これはOpenCoreの起動時のピッカーにNVRAMをリセットするアイコンを出してくれていた機能です。アイコンを出す機能は、Driversフォルダの中に入れるResetNvramEntry.efiが担うようになったようです。/UEFI/Drivers/の中で、ResetNvramEntry.efiに関係するItemのEnabledをtrueにしておくと、今まで通りReset NVRAMアイコンが出ます。
Misc/SecurityのAllowToggleSipが消えてました。今まではfalseに設定していました。これもNVRAMリセット機能と同様に、Driversフォルダの中にToggleSipEntry.efiを入れることで機能するように変更されたようです。今まで使用していなかったので対応しませんでしたが、必要ならば、同様に、ToggleSipEntry.efiをDriversフォルダに入れて、/UEFI/Drivers/の中で設定すれば良いと思います。
0.8.0の時と同様に、Sample.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の中に、#INFO (prev-lang:kbd)という項目ができていて、これの値 (String型) がen:252 (ABC), set 656e3a323532になってました。コメントアウトなので問題ないはずですが、以前にこれを残しておいたらブラックスクリーンになりました。消しておくと良いです。

以上の設定で、引き続き問題なく起動しました。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4で動かしているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

Monterey 12.4 にアップデートする

Tue, 17 May 2022 21:52:59 +0900

macOS Monterey 12.4が配布されていましたので12.3.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.4の情報はまだありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.8.0で起動していて、kext類は最新です。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT

システム環境設定のソフトウェアアップデートに、12.4のアップデートの通知が来ていました。

アップデートは、PodcastとStudio Displayの機能強化と不具合に対応したものらしいです。これだけ見るとあまり関係なさそうですが、バージョン番号が大きく上がるマイナーアップデートなので期待したいところです。「今すぐインストール」ボタンを押すと、2.29GBのファイルがダウンロードされます。

その後、自動的に4回再起動して、12.4に更新されました。今回の再起動過程では、1回目の再起動にはmacOS Installerという名前のボリュームが現れ選択されていて、2回目以降はこのボリュームは消えて、通常の起動ボリューム（Macintosh HDという名前にしてます）が選択されました。

いつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.4が起動しました。ビルドは21F79です。

特に問題なく動いています。使用しているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

メインマシンをASRock Z690 Steel Legendに移行

Sun, 24 Apr 2022 18:09:33 +0900

Alder Lake-S 12900Kを取り付けたASRock Z690 Steel Legendをメインマシンとして使うことにしました。そこで、今まで使っていたASRock Z590 Extremeマザーボードと交換しました。

古いマシンのSSDが不調に

Z590 Comet Lake-S で動かすmacOSメインマシンは、長らく安定していて全く問題ありませんでした。なので、興味本位で作ってしまったZ690マシンは、ずっとバラック状態で、サブマシンとして使ってました。

そのZ590メインマシンが、ここ1~2ヶ月ほど不調でした。数回に一回くらいの頻度で起動しません。やり直せば問題なく起動して使えるので、BIOS不調かなくらいに思ってました。それがとうとう、ログインできなくなりました。パスワード入力画面は出るのですが、データが壊れていてログインできないという内容のダイアログが出て起動できなくなりました。別のドライブから起動してDisk First Aidをかけてみると、パーティション構成に問題があるとの診断です。使用していたのはかなり前から使っている2.5インチSATA SSDでした。おそらくはフォーマットし直して復旧できると思われます。データはクラウドとTimemachineでバックアップしてあるので復旧は容易です。でもまた壊れるかもしれません。少なくともSSDは交換した方が良さそうです。

それで良いきっかけができたと思い直して、メインマシンからZ590マザボを取り外して、Z690マザボに交換することにしました。

起動SSD交換

Z690マザーボードには、1TB容量のWDのM.2 SSDが取り付けてありました。これにOpenCore 0.8.0とmacOS Monterey 12.3.1が入れてあり、問題なく動いています。なので、マザーボード交換に伴い、起動ドライブもこのM.2 SSDに変更します。一方で、起動しなくなった古い2.5インチSATA SSDは、いつの間にかディスクユーティリティからも見えなくなってました。

CPUクーラー交換

Z690マザーボードで最初に組んだ当時は、Alder LakeのLGA 1700対応クーラー製品が出揃ってませんでした。それでいち早く対応したCorsairの簡易水冷クーラーを使用しました。

一方で、メインマシンのZ590マザーボードには、Noctuaの空冷クーラーをつけてました。ケースには水冷ラジエータを取り付ける場所が確保できなかったので、引き続きこの空冷クーラーを使うことにして、これに交換しました。

現在売られているクーラー製品にはLGA 1700のアダプタも付属しています。でも昔に買った製品だったので、対応アダプタが必要です。NoctuaのLGA 1700アダプタには、サイズ違いのMP78とMP83があります。また、通常モデル用の銀色とchromax.black用の黒色があります。なので、色違い・サイズ違いの以下に示す4種類があります。色は間違えても取り付けられますが、サイズは互換リストを見て確認する必要があります。今回はMP78の黒色を入手しました。

グラフィックスカード交換

今まで使用していたZ590にはRadeon RX 6600を取り付けてました。

一方で、Z690マザーボードにはRadeon RX 580がついていました。これも交換して、今まで通りRX 6600を使うことにしました。RX 6600を使う場合には、config.plistのboot-argsにagdpmod=pikeraを追加します。 RX 580では不要でした。その結果現在の設定は、以下のようになってます。

-v keepsyms=1 debug=0x100 -wegnoigpu agdpmod=pikera

ちなみに-wegnoigpuは、WhateverGreen.kextに、iGPUを使わないように指示するオプションです。Alder LakeのiGPUはmacOSでサポートされていないので、ここで念の為に指定しています。

拡張カード

昔ながらのケースに、複数のHDD、光学ドライブ、SATA拡張ベイなどを取り付けているので、SATAを8本使ってました。Z590 ExtremeにはSATAが6本しか搭載されていなかったので、SATA拡張用のPCIeカードを使用していました。Z690 Steel Legendは、なんとSATAが8本ついています。拡張スロットの本数も多く、拡張性の高いマザーボードだと思います。なので、SATA拡張カードは取り外すことにしました。

また、ほとんど使ってないのですが、IEEE 1394カードを取り付けてました。これは今まで通り使えるよう移行しました。

マザーボード交換

説明が前後しますが、CPUクーラや拡張カード類を取り付ける前に、マザーボードを交換しました。同じASRock製品で、世代が近いこともあり、ボード上のケースファンコネクタ、USBコネクタ、オーディオコネクタなどの内部コネクタの位置がよく似ています。それでケース内の配線をほとんど変更することなく、大体同じ場所に取り付けることができて、とても助かりました。USB 3.0コネクタなどは嵩張るので、取り付け方向が90度違うと配線の取り回しが面倒になりますが、それも一緒なので楽でした。

まとめ

起動SSDが不調になったのをきっかけに、メインマシンのマザーボードをZ690に交換しました。12900Kを使っているので、コアがたくさん見えて満足感があります。

Z590マシンは、同じComet Lake搭載のiMacに合わせて、機種IDをiMac20,1に設定してありました。Z690マシンは、対応するCPU搭載Macが存在しないので、汎用性の高いiMacPro1,1に設定しました。そのおかげで、SafariからAmazon Primeビデオが再生できるようになりました。iMac20,1は本来Apple T2チップを搭載している機種なので、これに設定すると再生できないようです。

今後普段使いする過程で、不具合など見つけて対応していきたいと思います。今のところ、ケースのコネクタに接続したUSBポートの一部が機能しない問題があります。USBの設定を見直したいです。

OpenCore 0.7.9から0.8.0に更新

Sun, 24 Apr 2022 00:04:00 +0900

OpenCoreの0.8.0が公開されていたので0.7.9からアップデートしました。新しい項目はデフォルトのままで問題なかったので、0.7.9のconfig.plistでもそのままでも動くはずです。

0.8.0をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.8.0とmacOS 12.3.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.3.1
ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.3.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。

config.plistの変更点は以下でした。

Kernel/QuirksにCustomPciSerialDeviceという項目が追加されていました。シリアルポートに関する設定のようです。シリアルポートはデバッグの時に使うのかな？今時のマザーボードなので、シリアルポートは搭載していないので、Sample.plistの初期設定のfalseのままにしておきました。
Kernel/QuirksにForceAquantiaEthernetという項目が追加されていました。Aquantia AQtion を使った 10GbE ネットワークカードをサポートしてくれます。このカードは、macOS 10.15.4以前ではネイティブにサポートされていたので、それを有効にする機能のようです。またこのカードを使うためには、DisableIoMapperをdisabledに、DMAR ACPI tableはdropしない設定にして、BIOSでVT-dはenabledに設定する必要があるようです。現状では10GbEカードは取り外して休眠状態なので、Sample.plistの初期設定のfalseのままにしておきました。そのうち試したいです。
Misc/DebugからSerialInitという項目が削除されていました。これもシリアルポートに関するもので、シリアルポートを初期化する機能だったようです。Serialという項目に移動したようです。config.plistから削除しておきました。
MiscにSerialという項目が追加されていました。中には、InitとOverrideというブール値を設定します。シリアルポートを初期化したり設定する機能のようです。Debugから移動したものと思われます。これらも、Sample.plistの初期設定のfalseのままにしておきました。
0.7.9の時と同様に、Sample.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の中に、#INFO (prev-lang:kbd)という項目ができていて、これの値 (String型) がen:252 (ABC), set 656e3a323532になってました。説明書にもない項目で、間違って残っているのかもしれません。これを残しておいたらブラックスクリーンになりました。消しておくと良いです。
Sample.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の中のSystemAudioVolumeDBの設定がSample.plistからは消えてました。説明書には残っているので、機能していると思います。音量のことだけと思うので、Sample.plistに合わせて無しのままにしておきました。

以上の設定で、引き続き問題なく起動しました。

ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.3.1で動かしているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。

Monterey 12.3.1 にアップデートする

Sun, 03 Apr 2022 14:40:59 +0900

macOS Monterey 12.3.1が配布されていましたので12.3からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.3.1の情報はまだありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.9で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K
ASRock Z690 Steel Legend + 12700K

システム環境設定のソフトウェアアップデートに、12.3.1のアップデートの通知が来ていました。

アップデートは、2018 Mac mini外部ディスプレイとBeatsヘッドフォンの不具合に対応したものらしいです。そのほか、バグ修正とセキュリティアップデートが含まれているようです。脆弱性にも対応しているようなので、アップデートを急いだ方が良いと思われます。「今すぐインストール」ボタンを押すと、自動的に3回再起動して、12.3.1に更新されました。いつものアップデートでは、起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されるのですが、今回は、macOS Installerという名前のボリュームが現れました。

いずれにしても、いつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.3.1が起動しました。ビルドは21E258です。

Z690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートできました。

Monterey 12.3 でユニバーサルコントロールを使う

Wed, 16 Mar 2022 18:29:26 +0900

macOS Monterey 12.3が配布されたので12.2.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.3の解説はありません）。ユニバーサルコントロールが使えました。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.9で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + BCM94360NG

システム環境設定のソフトウェアアップデートに、12.3のアップデートの通知が来ていました。

アップデートにより、

「ユニバーサルコントロール（ベータ）」が追加
「空間オーディオ」「絵文字」が改良
Podcastのエピソードが追加
Safariの翻訳がイタリア語と中国語に対応
ショートカットがリマインダーでのタグに対応
保存済みパスワードにメモを追加可能
バッテリ容量測定の精度改善
TVアプリと写真アプリのバグに対応

などが実現されるようです。中でも、ユニバーサルコントロールは目玉機能で、世間で注目されてます。Hackintoshで動くのかどうか、是非とも試したいところです。

早速アップデートしました。「今すぐインストール」ボタンを押すと、4.38GBのファイルがダウンロードされ、その後、自動的に3回再起動して、12.3に更新されました。いつもと同様に、再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。

再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.3が起動しました。ビルドは21E230です。

ユニバーサルコントロールを試す

早速、話題のユニバーサルコントロールを試しました。これを使うためには、システム環境設定のディスプレイから、ユニバーサルコントロール…ボタンを押して設定します。現れるチェックボックスを、とりあえず全部有効にします。

iPadを使う場合は、これも最新のiPadOS 15.4にアップデートしておきます。次に、iPadの「設定」を開き、「一般」から「AirPlayとHandoff」を開いて「カーソルとキーボード」をオンにしておきます。

他のマシンの用意ができたら、macOSのディスプレイから「ディスプレイを追加」を選びます。これで追加するマシンを選べます。以下の例では、中央が、今回12.3をインストールしたASRock Z590 Extreme + 10900Kマシンです。左がMacBookで、右がiPadです。

この配置の場合、ASRock Z590 Extreme に接続したトラックパッドのポインターを、画面左に持っていくとMacBookにポインターが移動します。画面右に持っていくとiPadに移動します。それぞれのマシンに移動した後、テキストが入力できる場所でクリックすると、そこにカーソルが現れ、キーボードから入力できるようになります。とても便利です。ASRock Z590 Extremeの機種設定はApple T2セキュリティチップ搭載機種のiMac20,1に設定しています。このことでユニバーサルコントロールが動かないのではと心配していましたが、全く問題ありませんでした。

Macとの連携は、今までも、画面共有をすればほぼ近い操作が可能なので、それほど大きな変化ではないかもしれないです。でも、iPadとの連携はすごいです。iPadでの文字入力が楽になるので、iPad用のキーボードを買う必要が無くなったかもしれないです。また、写真ファイルなどをドラッグ＆ドラッグすると、その写真を貼り付けられます。ファイルの移動も簡単にできます。今のところ連携できるのは、Mac同士、もしくはMacとiPadだけのようです。この先、MacとiPhoneが連携できたら、ますます便利になるのではと思いました。

OpenCore 0.7.8から0.7.9に更新

Tue, 15 Mar 2022 22:41:52 +0900

OpenCoreの0.7.9が公開されていたので0.7.8からアップデートしました。今回もほとんど更新されていないので、0.7.8のconfig.plistでもそのままでも動くはずです。

0.7.9をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.9とmacOS 12.2.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.2.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更点は以下だけでした。大きな変更はありません。

Misc/DebugにLogModulesという項目が追加されていました。値はStringでSample.plistの値は*でした。ログをモジュールごとにフィルタする機能のようです。例えば+OCCPU,OCA,OCBとするとこれらのモジュールのログだけが表示・記録されるようです。全てを表示するデフォルト値の*にしておきました。
Sample.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の中に、#INFO (prev-lang:kbd)という項目ができていて、これの値 (String型) がen:252 (ABC), set 656e3a323532になってました。説明書にもない項目で、間違って残っているのかもしれません。これを残しておいたらブラックスクリーンになりました。消しておくと良いです。

Sample.plistを見る限りでは他に変更点はありませんでした。Differences.pdfを見ると、他にも多少の変更があるようですが、デフォルト値には関係のないようでした。

Alder Lake 12900Kの24コアをmacOSで使う

Sun, 13 Feb 2022 00:08:04 +0900

OpenCore 0.7.7からAlder Lake CPUのコアが全部使えるようになり、性能をフルに引き出せるようになりました。それで12900Kを使って、どれくらいのスコアが出るのか確認しました。マルチコアでM1 Maxの1.2倍くらいでした。

マシン構成

使用したマシンは、以下で紹介したASRock Z690 Steel Legend WiFi 6Eを使ったマシンです。

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

今までは12700Kを使っていましたが、これを12900Kに差し替えました。同じシリーズのCPUですので、BIOSやconfig.plistの設定は何も変更しなくてもそのまま問題なく動作しました。アクティビティモニターでコア活動状況を見ると、24本の棒グラフが並び、圧倒的です。

HackintoshでAlder Lakeの全コアを使用する記事は以下で紹介しました。

OpenCore 0.7.7でAlder Lake全コアに対応予定

macOSに全コアを使ってもらうために、OpenCore 0.7.7以降では、PコアのHyper Thread (HT)が物理コアとして存在しているようにOSに見せることができます。それで、「システム環境」の「ハードウェアの概要」「コアの総数」が、（Pコア）＋（PコアのHT）＋（Eコア）の合計になります。Alder Lakeより前のCPUだと、HTはコア数に含まれなかったですが、12900Kは、Pコアが8個、そのHTが8個、Eコアが8個あるので、全部で24個コアだと表示されます。

Geekbench 5でベンチマーク

Geekbench 5でベンチマークを取りました。シングルは2000以上、マルチは15500以上のスコアが出ます。詳細を見ると、24コアのCPUになっています。HTもEコアも全部通常のコアに見えているようです。

何度か測定していると、たまにシングルが1800くらいの時があります。この時、もしかしたら測定対象がEコアに当たったのかもしれません。ただ、そのようなスコア低下はほとんど発生しないので、Pコアが空いていればそちらに割り当てられるのかもしれないです。また、シングルが低下した場合でもマルチスコアは変わりません。

GeekbenchブラウザのサイトにあるM1 Maxのスコアと、今回測定した12900Kのスコア（5回の平均）を比べたのが下の図です。M1 Maxと比較すると、シングルで1.13倍、マルチで1.23倍くらいです。

Geekbench 5スコアの比較

Geekbenchブラウザのページで、12900Kで作ったhackintoshらしきスコアを見ても、マルチスコアが大体15000前後のようです。中には20000越えなスコアもありますが、おそらくはオーバークロックしているのだと思われます。

Cinebench R23でベンチマーク

コメントで要望いただきましたのでCinebenchのスコアも紹介しておきます。1回だけの実行結果です。マルチコアのベンチマークでは24個のブロックに分かれて並列描画されます。

結果は、 CPU (Single Core)が1825 pts、CPU (Multi Core)が26520 ptsでした。

ASCII.jpの記事によると、M1 MaxのCinebench R23のスコアは、シングルで1532, マルチで12372だそうです。この値を比較すると、12900KはM1 Maxのシングルで1.2倍、マルチで2.14倍のスコアになりました。

Cinebench R23スコアの比較

Monterey 12.2.1 にアップデートする

Fri, 11 Feb 2022 14:35:46 +0900

macOS Monterey 12.2.1が配布されたので12.2からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.2.1の解説はありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.8で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K
ASRock Z690 Steel Legend + 12700K

システム環境設定のソフトウェアアップデートに、12.2.1のアップデートの通知が来ていました。

アップデート内容は、「Intelプロセッサを搭載したMacコンピュータでBluetooth周辺機器に接続しているとスリープ中にバッテリーを使い切ってしまうことがある問題」を修正したとあります。12.2からすぐのタイミングですし、急いでバグに対応したようです。

12.2で動いているMacBookシリーズをスリープさせると、その間も電池の消耗が進んで数時間で電池切れになってしまう症状がネットで話題になってました。インテルだけでなくM1でも同様な症状が発生すると言われてました。スタパ齋藤氏の記事によると

[スタパ齋藤のApple野郎] 寝てくれっ、M1 Mac mini、徹夜しないでくれっ!!!

M1 Mac miniで、Bluetoothがオンになっているとスリープからすぐに目覚めてしまうそうです。なので、スリープからすぐに目覚めてしまうことが問題のようです。スリープからすぐに目覚める現象は、hackintoshでしばしば遭遇しますが、実機でも発生するようです。ちなみに、手元のM1 MacBook Airで試したところでは、スリープ状態でバッテリーが消耗する現象は見られませんでした。色々複雑な条件のもとで発生する不具合なのかもしれないです。いずれにしてもそれが解決されることは嬉しいです。

なので、早速アップデートしました。「今すぐインストール」ボタンを押すと、自動的に3回ほど再起動して、12.2.1に更新されました。いつもと同様に、再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。

再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.2.1が起動しました。ビルドは21D62です。

Z690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートして全コア、全スレッドで機能しました。

OpenCore 0.7.7から0.7.8に更新

Tue, 08 Feb 2022 18:43:30 +0900

OpenCoreの0.7.8が公開されたので0.7.7からアップデートしました。今回はほとんど更新されていないので、0.7.7のconfig.plistがそのままでも動くはずです。

0.7.8をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.8とmacOS 12.2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12700K + Radeon RX580 + macOS Monterey 12.2
ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.2

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistに変更はありませんでした。ただ、

NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82にSystemAudioVolumeDBが0.7.7から追加されていたのですが、Sample.plistから無くなってました。マニュアルには記載がありますし、残していても警告は出ませんでしたのでそのまま残してあります。0.7.7のSample.plistの値がE2だったのでそのままです。

Monterey 12.2 にアップデートする

Thu, 27 Jan 2022 12:22:41 +0900

macOS Monterey 12.2が配布されたので12.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.2の解説はありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下です。OpenCore 0.7.7で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K
ASRock Z690 Steel Legend + 12700K

システム環境設定のソフトウェアアップデートに、12.2のアップデートの通知が来ていました。

アップデート内容はバグ修正とセキュリティ改善で、新機能が増えたわけではないようです。「今すぐインストール」ボタンを押すと、1.94 GBのファイルがダウンロードされました。その後、インストールを開始すると、自動的に3回ほど再起動して、12.2に更新されました。再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。

再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.2が起動しました。ビルドは21D49です。

Z690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートして全コア、全スレッドで機能しました。

OpenCore 0.7.6から0.7.7に更新

Wed, 12 Jan 2022 23:38:04 +0900

OpenCoreの0.7.7が公開されたので0.7.6からアップデートしました。Alder Lakeへのサポートが充実しました。config.plistには大きな変更は無いので、0.7.6のconfig.plistがそのままでも動くはずです。

0.7.7をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.7とmacOS 12.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z690 Steel Legend + 12700K + Radeon RX580 + macOS Monterey 12.1
ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistの変更は以下でした。

NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82にSystemAudioVolumeDBが追加されていました。Sample.plistの値がE2だったのでそのまま使いました。
UEFI/AppleinputにPointerPollMask, PointerPollMax, PointerPollMinが追加されていました。ポインターの制御用のようです。Sample.plistのデフォルトのまま、それぞれ-1, 80, 10にしておきました。
UEFI/AudioのAudioOutがなくなって代わりにAudioOutMaskが追加されてました。デフォルトの1にしておきました。
UEFI/AudioのMinimumVolumeが無くなってDisconnectHdaに置き換わってました。デフォルトのままfalseにしておきました。
UEFI/AudioのVolumeAmplifierがなくなって代わりにMinimumGain, MinimumAssistGain, MinimumAudibleGainが追加されていました。それぞれデフォルトのまま-15, -30, -55にしておきました。

Alder Lakeサポート

Alder Lakeの非対称コアへのサポートが強化されました。スレッドをコアとみなすことで、例えば8個のPコア、8個のPコアハイパースレッド、8個のEコアのある12900Kの場合、24コアのCPUとして機能します。性能の違うコアを同じものとみなすために、Geekbenchのシングルコアスコアが10%くらいばらつきます。でもマルチコアスコアは高速になりました。

ASRock Z690 Steel Legendをスリープさせる

Sat, 18 Dec 2021 11:34:33 +0900

ASRock Z690 Steel Legendで、スリープからすぐ目覚めてしまう現象が発生してましたが、これを止めることができました。USB関係の問題でした。他のCPU世代の自作でもよく見かける現象ですので、参考になると思います。以下の記事の続きです。OSはMonterey 12.1です。

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

スリープからすぐに目覚める問題

Appleメニューから、もしくは、無操作のタイムアウトからスリープに入ると、以下のような現象が発生してました。

スリープに入る
画面が暗くなる。でもCPUファンは動いている。
1分ほどそのままの後、画面が復帰してログイン画面に戻る。

という現象です。スリープ復帰後は、引き続き正常に使用できます。また、シャットダウンは正常に行えます。

いろいろ試してみたところ、バックパネルのUSB Type-Aコネクタに接続されたデバイス（接続していたのはキーボード用無線USBアダプタとUSBメモリーです）を全部外すと、スリープから目覚めなくなることがわかりました。何かがUSB Type-Aコネクタに挿さっていると、1分ほどでスリープから目覚めてしまいます。

また、バックパネルのUSB Type-Cに同じキーボードとUSBメモリを接続したところ、この場合は正常にスリープし、そのキーボードを押すと復帰します。Type-Cには直接接続できないので、この確認には、MacBookで使うType-Cハブを使いました。

さらには、マザーボード搭載のM.2 E KeyコネクタのUSBも問題ないようで、そこに取り付けたBCM94360NGにBluetooth接続するApple Magic Keyboardなどは問題を起こしません。接続していてもスリープに入りますし、キーを押すとスリープから復帰します。

どうも、バックパネルのType-Aコネクタが問題を起こしている様子です。

USBがスリープを阻害する問題は、hackintoshでよく経験します。昔の記事ですが、こちらではZ390ボードが目覚める原因がUSBハブでした。

USB機器がスリープを阻害することがあります

OpenCoreのバニラガイドを見ると、macOSのUSBドライバに不備があって、スリープ時の電力管理に問題があるらしいです。おそらく、Macの実機で動けば良いので、標準仕様を満たした設計にはなっていないのでしょう。それでパッチを当てて修正する手法が考えられているようです。まずはそれを試しました。

方法1：USB機能にパッチする

USB機器がスリープを邪魔しないようにするパッチがいくつか考えられています。tonymacx86のZ690ビルドのスレッド

で配布されているZ690用のEFIファイル類を見ると、二つの方法が試みられていました。一つは、

SSDT-USBW.amlを使い、
USBWakeFixup.kextを使う

方法です。上記のバニラガイドでも紹介されている方法です。USBデバイスがスリープを妨げることを防ぐための措置らしいです。でも効果がありませんでした。カスタマイズする必要があったのかもしれないです。

もう一つは、

SSDT-GPRW.amlを使い、
Method(GPRW,2,N)にパッチを当てる

方法です。パッチは、config.plistのACPI/Patchに、以下のように書いておきます。USBとBluetoothがスリープを妨げないようにする処置のようです。

生のplistの部分は、以下になります。

<dict>
 <key>Comment</key>
 <string>change Method(GPRW,2,N) to XPRW, pair with SSDT-GPRW.aml</string>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>R1BSVwI=</data>
 <key>Replace</key>
 <data>WFBSVwI=</data>
</dict>

こちらは機能しました。これはUSBデバイスをスリープ解除に使えなくする力技のパッチです。なので、どんなUSBデバイスが挿さっていても、スリープから目覚めなくなりましたが、一方で、USBキーボードやBluetoothキーボードを操作しても、スリープから復帰しなくなります。電源スイッチを押して初めて復帰します。電源スイッチが遠いとちょっと不便なので、なんとかしたいところです。

方法2：USBPorts.kextを書き換える

そこでこの方法を考えました。まずは気になったところが、Type-Aコネクタが使用されている時だけ、スリープから目覚めてしまうという現象です。Type-CやM.2コネクタのUSBデバイスは問題を起こしません。

USBコネクタの種類は、EFIの中で設定してmacOSに知らせています。現在使っている方法は、USBPorts.kextを作って、その中のInfo.plistで設定する方法です。

15個制限のためのUSBPorts.kextをHackintoolで作る

Hackintool.appを使う場合は、以下のようにしてConnectorの種類を設定します。

Connectorとして選択できるのは、USB2, USB3, TypeC+Sw, TypeC, Internalの5種類です。それぞれの選択で、Info.plistのUsbConnectorキーに0, 3, 9, 10, 255が割り当てられます。hackintoolのソースによると、この5種類を含めて、以下の数値が用意されています。

kTypeA		= 0x00,	// Type ‘A’ connector
kMiniAB		= 0x01,	// Mini-AB connector
kExpressCard	= 0x02,	// ExpressCard
kUSB3StandardA	= 0x03,	// USB 3 Standard-A connector
kUSB3StandardB	= 0x04,	// USB 3 Standard-B connector
kUSB3MicroB	= 0x05,	// USB 3 Micro-B connector
kUSB3MicroAB	= 0x06,	// USB 3 Micro-AB connector
kUSB3PowerB	= 0x07,	// USB 3 Power-B connector
kTypeCUSB2Only	= 0x08, // Type C connector - USB2-only
// These only implement the USB2 signal pair, and do not implement the SS signal pairs
kTypeCSSSw	= 0x09, // Type C connector - USB2 and SS with Switch
// These implement the USB2 signal pair, and a Functional Switch with a physical
// Multiplexer that is used to dynamically connect one of the two receptacle SuperSpeed
// signal pairs to a single USB Host Controller port as function of the Type-C plug
// orientation.
kTypeCSS	= 0x0A, // Type C connector - USB2 and SS without Switch
// These implement the USB2 signal pair and a Functional Switch by connecting each
// receptacle SuperSpeed signal pair to a separate USB Host Controller port.
// 0x0B – 0xFE: Reserved
kInternal	= 0xFF	// Proprietary connector

どのコネクタに接続されていてもUSBはUSBなので関係ない気もしますが、macOSの中での電力制御の扱いが異なるようです。IORegistryExplorerなどでコネクタの情報を見ると、コネクタ種類の違いで電流関係のパラメータが異なっています。コネクタ設定の違いが、スリープ時の電流管理にも影響していて、意図しない復帰を誘発している可能性があるかと思います。実際に先の記事にも書きましたが、Bluetoothアダプタが接続するポートは、255に設定しないとスリープを妨げることがあるようです。

今回の不具合も、Type-Aに対するスリープ時の電力管理がうまく働かないのが原因とも考えられます。それで、Type-Aに設定していた部分：

を、以下のように、全てInternalに設定しました。

この結果、Type-AのコネクタにUSBデバイスを接続していても正しくスリープするようになりました。Internal (255) 以外の設定値のうち、一般的なUSB 2.0 (0)とTypeC+Sw (9)も試しましたが、それらでは解決しませんでした。上の実験でType-Cで正しくスリープ動作したのは、ハブのおかげだったのかも知れないです。

スリープ動作の確認

ということで、USBPorts.kextでコネクタをInternalに設定する方法で、問題はほぼ解決しました。以下のaml, kext, パッチ：

SSDT-USBW.aml
USBWakeFixup.kext
SSDT-GPRW.aml
Method(GPRW,2,N)パッチ

は、どれも不要でした。

この方法で正しくスリープに入り、CPUファンが停止した状態が何時間も継続します。その一方で、Bluetooth接続したApple Magic Keyboard, Magic Trackpad, LogicoolのBTマウスなどから目覚めさせることが可能です。また、Type-Cにハブ経由で接続したノーブランドのキーボードからも目覚めます。

ただ、Type-Aに直接接続した一部のキーボードなどから目覚めさせることができない問題があります。フォーラムで教えてもらった情報によると、スリープ復帰するマウスとしないマウスがあるようです。また、Magic KeyboardをUSB接続した状態だと、これからスリープ復帰できるようです。いずれにしてもBluetooth入力デバイスをメインに使っていく予定なので、このことはほとんど気になりません。

macOSの「システム環境設定・省エネルギー」のデフォルトでは、「ネットワークアクセスによるスリープ解除」が有効になっています。これを有効にしておくと、手元の環境では頻繁に目覚めてしまいます。色々な機器が接続されているので、アクセスが多いのかも知れないです。ネットワークがもっと静かな環境なら有効に設定しても良いのかも知れませんが、これを無効にしました。

一方で、「Power Napを有効にする」は、有効にしておいてもそれほど問題はありません。約1時間に1回ほど目覚める程度でした。それが気になるような環境でしたら、無効にしておくと良いと思います。

まとめ

スリープから自動的に目覚めてしまう現象に、USBPorts.kextの設定で対応しました。正しくスリープして、キーボードやポインティングデバイスの操作でスリープ復帰するようになりました。Z690は、性能が良くて安定しているので、すぐにメインマシンにしても良いくらいです。

Monterey 12.1 にアップデートする

Tue, 14 Dec 2021 18:46:50 +0900

macOS Monterey 12.1が配布されたので12.1 RC2からアップデートしました。問題なくアップデートできました。Radeon RX 6600が正式にサポートされました。アップデート情報は以下にあります（現時点では12.1の解説はありません）。

https://support.apple.com/ja-jp/HT212585

アップデートしたマシンは以下の2台です。いずれもOpenCore 0.7.6で起動していて、kext類は最新です。

ASRock Z590 Extreme + 10900K
ASRock Z690 Steel Legend + 12700K

ネットの情報によると、配布された12.1はビルド番号が21C52らしいです。すでにベータ版12.1を導入していて、そのベータ最終版のRC 2も同じ21C52でした。なので、システム環境設定のソフトウェアアップデートに、12.1の通知は来ませんでした。同じもののようですが、念のためにApp Storeに行き、Montereyのダウンロードをしました。

その結果、12.16GBのファイルがダウンロードされました。

ダウンロードされたmacOS Montereyインストール.appは、自動的に起動しました。インストール先を指定するとインストール開始されて、途中、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.1が起動しました。でもビルドは21C52のままで変わりませんでした。

Radeon RX 6600 XTが認識されています。正式サポートされて一安心です。

OpenCore 0.7.7でAlder Lake全コアに対応予定

Sat, 11 Dec 2021 00:34:15 +0900

Intelの新しい第12世代CPU Alder Lake-Sへの対応がOpenCore開発チームによって進捗しています。先の記事では、macOSでAlder Lake-SのEコアを半分まで稼働させる拡張機能であるCpuTopologySync.kextを紹介しました。昨日これが配布終了になり、その機能がOpenCore本体に組み込まれつつあることが明らかになりました。来月公開のOpenCore 0.7.7では全てのEコアが稼働するそうです。

その機能を先立って試すことも可能です。以下のコメント、

で、開発段階のOpenCore.efiが配布されています。これを、

現在のEFI/OC/OpenCore.efiと入れ替えて、
config.plistでKernel/Quirks/ProvideCurrentCpuInfoをtrueにする

ことで、macOSから全コアが利用可能になります。当然ですがBIOSで全コアを有効に設定しておく必要があります。上記のコメントの手順では、CPUFriend.kextとCPUFriendDataProvider.kextを使用して、CPUの周波数ベクターを設定するように書かれていますが、iMacPro1,1の機種IDでは不要でした。書き換えなくても性能は変わりませんでした。

これでGeekBench 5のマルチコアスコアが1000から2000くらい上昇します。明らかなシングルコア性能低下もありませんでした。GeekBenchのCPU情報によると、例えば12700Kは、

1 Processor 20 Cores

と表示されます。8 Pコア＋8 ハイパースレッド (HT) ＋4 Eコア＝20コアという計算だと思われます。 10900Kの場合は、

1 Processor 10 Cores, 20 Threads

のように、物理コアとスレッドが別々に表示されていました。OpenCoreでは、Alder Lake PコアのHTを物理コアとして扱うことで、HT可否コア混在の問題を解決している様子です。

来月のOpenCore 0.7.7へのバージョンアップにより、何事もなく全コアが使えるようになると思いますが、現時点でも簡単に試せて、効果絶大です。

OpenCore 0.7.5から0.7.6に更新

Tue, 07 Dec 2021 19:18:30 +0900

OpenCoreの0.7.6が公開されたので0.7.5からアップデートしました。大きな変更は無いので、0.7.5のconfig.plistそのままでも動くはずです。

0.7.6をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.6とmacOS 12.1 betaで動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.1 beta
ASRock Z690 Steel Legend + 12700K + Radeon RX580 + macOS Monterey 12.1 beta

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目にほとんど変更はありませんでした。

UEFI/Output/にReconnectGraphicsOnConnectが追加されていました。デフォルト値がfalseで、この機能は無効になります。ファームウェアによっては「BiosVideo.efiを使う場合のように、代替のグラフィックスドライバを使うと良い場合がある」そうです。おそらくはEFIの画面のことと思います。またこれを使うにはConnectDriversを有効にする必要があるとのことです。関係なさそうだったので、デフォルトのfalseにしておきました。
UEFI/Output/にUIScaleが追加されていました。以前は、NVRAM/Add/4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14/で指定していた設定です。こちらに移動したようです。sample.plistには0とされています。これは変更なしという意味らしいです。後述するように、Z690マシンで表示が見にくかったので2にしました。
UEFI/Quirks/にEnableVmxが追加されていました。Configuration.pdfには説明がありません。sample.plistにだけ加わっています。0.7.6のアナウンスによると、仮想化関係の設定のようです。sample.plistに書かれている通りfalseにしておきました。

追加項目がデフォルトのままでも起動には問題ありません。なので0.7.5のconfig.plistをそのまま使っても問題ありません。これで、0.7.5から0.7.6に移行できました。

UIScaleを調整

今までは、sample.plistに倣って、UIScaleをNVRAM/Add/4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14で01に設定していました。今回、UEFI/Output/で設定するように変更されたようなので、値を見直しました。sample.plistでのお手本では0に設定されています。0は変更なし、1は1倍ピクセルのことのようです。

Z590マシンでは、ボリューム選択画面は小さく鮮明に表示されていました。でもZ690マシンでは、同じく小さく表示されるものの、表示が滲んで、文字が潰れていました。それでも我慢して使ってました。

UIScaleの設定を試したところ、0や1の設定では、このような滲んだ表示になるようです。4Kディスプレイに正しく対応できていないようでした。そこでUIScaleを2に設定したところ、綺麗に表示されるようになりました。表示サイズは2倍に大きくなりました。

Alder Lake対応

Alder Lakeのために更新された項目もあります。特にXCPM CPU power management ACPI tableが追加されたとのことです。Z690マシンで、これに関して特に変わった感じは分かりませんでした。もう少し調査します。

OpenCoreと同時にアップデートされたkext類も、Alder Lakeに対応しました。AppleALC.kextは1.6.7になりました。これで、ASRock Z690 Steel Legendに搭載されたALC897のデバイス番号に対応し、音が出るようになりました。またVirtualSMC.kextもアップデートされて、HMMonitorでCPU温度や消費電力が表示できるようになりました。

Alder Lake-SをmacOSで動かすハッキング

Mon, 06 Dec 2021 23:14:57 +0900

Intelの新しい第12世代CPU Alder Lake-Sが発売されてから1月あまり経ちました。海外のコミュニティを見ていると、新CPUをmacOSで使うためのハッキングが進捗しています。昨日（2021/12/05）あたりには12900Kの24スレッド中の、20スレッドまでをmacOSで使うkextが紹介されました。近いうちにAlder Lakeの全性能を引き出せるようになるのではと思います。

追記：OpenCore 0.7.6が公開されたので更新しました。

Comet Lakeに偽装する方法

こちらでも紹介しましたが、Alder Lake-SとZ690マザーボードの組み合わせで、macOSがかなり安定して動作しています。macOSで元々サポートされているComet Lake-Sと比べて、遜色のないくらい安定しています。M1 Maxを凌駕する性能でもあることから、早々にメインマシンにしても良いと考えているくらいです。

この手法では、Alder Lake-SをComet Lake-SとしてmacOSに認識させています。その場合、Alder Lakeから導入されたPコア/Eコアの構成は活用できず、一部のコアを使用できません。例えば、最上位モデルの12900Kの場合、P+E+ハイパースレッド(HT)で24スレッドが用意されているのに対して、Eコア、またはHTを除く、合計16スレッドしか使えません。表にまとめておきました。


12900K	Pコア	PコアHT	Eコア	合計TH	GB5 Multi スコア
本来の構成	8	8	8	24	?
macOS (8コア)	8	8	0	16	~13000+
macOS (16コア)	8	0	8	16	~13000-
CpuTopologySync (12コア)	8	8	4	20	~16000

それでもM1 Maxより良いベンチマークスコアが得られます。Geekbench 5のMulti-core Scoreでは13000くらいです。Geekbench 5ブラウザのサイトで検索すると、

12900k Acidanthera - Geekbench 5 CPU Search - Geekbench Browser

このページで、8コアもしくは16コアと表示されるのが、これらの結果です。8コアがPコア+HTの設定、16コアがPコア（HTなし）+Eコアの設定です。Eコアを使わない方が、多少良いスコアになるので、16コアの結果はほとんど見られなくなりました。

CpuTopologySync.kextを使う方法

~~昨日（2021/12/05）あたりに、~~acidentheraさんからCpuTopologySync.kextというkextを使った方法が公開されました。

GitHub - acidanthera/CpuTopologySync: Rebuild asymmetric CPU topology on macOS.

~~まだ開発中で制約がありますが、~~これを使うとEコアをさらに活用できます。正確には、Pコア＋PコアのHTに加えて、Eコアの半分までを使用できるようです。12900Kの場合、物理コアが12コア、HTが8スレッドで、合計20スレッドになります。残りの4スレッドは、アクティビティモニタには24スレッドのグラフが現れるものの、うち4スレッドが動作しないようです。

この理由は、CpuTopologySync.kextのコメントによると、XNU割り込みコントローラの仕様のためらしいです。

 After this only half of the efficient cores will be active.
The reason for this is the way XNU interrupt controller works.
cpu_topology_start_cpu will not start any CPU, which index is
outside machine_info.max_cpus, and max_cpus is equal to a total
number of _active_ CPUs.
* Trying to increase this value results in a stall, likely because
non-existent ("hyperthreaded" counterprarts of E-Cores) CPUs
do not come live.
* Trying to add non-existent CPUs after all E-Cores does not work
either as they are treated as physical cores on the die,
and thus result in the same asymmetric topology crash.

XNU割り込みコントローラがEコアのHTにアクセスしようとするらしいです。それでコアを半分に設定しておいて、HTへアクセスしようとしてもコアが足りるようにしているようです。

それでもEコアが働く効果により、Geekbench 5のマルチコアスコアが16000以上になるそうです。Geekenchブラウザで、コア数12となっているスコアがこれに相当します。シングルスレッド性能のバラツキや低下もなく、効率良く動いている様子です。kextを使用する以外に、

カーネルにパッチを当てる（config.plistにパッチの記載を追加する）
~~開発版~~最新版のLilu.kextを使う
Liluの直後にCpuTopologySync.kextを読み込む

などの作業・要件が必要です。etorixさんのポストに、この方法がコンパクトに書かれています。

全スレッドを使う方法

Geekbench 5 ブラウザを見ていると、24コアで動く12900Kのスコアが掲載されています。詳細を見ると、3 Processors, 24 Coresと書かれています。おそらくは、Pコア、HT、Eコアをそれぞれ仮想CPUに見立てて、24コアを使い切った構成だと考えられます。でも今のところ、CpuTopologySync.kextで12コア20スレッドにする場合と、ベンチマークスコアはあまり変わらないです。

まとめ

Alder Lake-SでmacOSを動かすハッキングは、ここ1ヶ月くらいでどんどん進捗しています。海外のフォーラムを見ていると、その成果に沸く様子が伝わってきて楽しいです。今のところCpuTopologySync.kextでEコアが半分になってしまう点など、まだまだ改善の余地はありそうです。今後のOpenCoreのリリースに合わせて、安定したバージョンが提供されていくと思われます。

ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす

Tue, 30 Nov 2021 23:27:46 +0900

Intelの第12世代CPUになるAlder Lake-Sシリーズが発売されました。今までになく高性能になったと評判です。macOSではサポートされていないCPUですが、Montereyで安定して稼働しました。Radeon RX 6600XTと組み合わせると、M1 Maxをちょっとだけ超える性能が得られます。

ASRock Z690 Steel Legend WiFi 6E

Z690マザーボードにはASRock Z690 Steel Legend WiFi 6Eを選びました。WiFiの付いていないASRock Z690 Steel Legendも同様に使用できます。違いはE key M.2に802.11ax Wi-Fi 6E モジュールIntel AX210NGWが搭載されているかどうか、アンテナ端子とアンテナ配線がされているかどうかだけです。現時点の価格.comでの両者の価格差は550円程度ですので、WiFiモデルを買うのが得策だと思います。AX210NGWを置き換える場合でもアンテナ配線が不要なので楽です。

このマザボを選んだいちばんの理由は、PCIeスロット数が多いことです。5本あります。これだけの拡張性は、実機では高価なMac Proでしか得られないので貴重です。Z590に引き続き、端正な見た目のASRock Z690 Extremeにしたかったのですが、ExtremeはZ690になってPCIeが1本減ってしまいました。Steel Legendは、Z590バージョンと同じスロット数を確保してます。Steel Legendの見た目のデザインは、ゴテゴテしてて好みでは無いのですが、機能重視で選びました。グラボの邪魔にならないバックパネル側に、PCIe x 1スロットがあるのも良いです。SSD用ヒートシンクの角を削って、多少見た目が悪くなっても、ここにPCIeを1本確保しようという設計者の機能性重視な心意気が気に入りました。

E keyのM.2ソケットが、マザーボード上のアクセスしやすい場所にあります。多くの歴代ASRockモデルと同様に、これもCNVi専用ソケットではありません。なのでmacOSと互換性が高く、OOBで稼働するBCM94360NGを取り付けることができました。PCIe用のWiFiアダプタを使用しなくて済むので、PCIeスロットの節約にもなります。

メモリはDDR4です。DDR5を試したかったのですが、メモリーが入手不可能な状態なので現状ではDDR4対応マザーボードしか選択肢がありません。

Alder Lake-S 12700K

今回発売されたAlder Lake-S CPUは、12900, 12700, 12600のKとKFモデルです。どれを使用してもmacOSは稼働するようです。macOSで動作させた場合の12900Kと12700Kの性能を、Geekbench Browserの結果で比較すると、12900Kの方が、12700Kより数%程度高性能です。

Acidanthera 12900k - Geekbench 5 CPU Search - Geekbench Browser

Acidanthera 12700k - Geekbench 5 CPU Search - Geekbench Browser

とはいえ、後述するようにmacOSでは実質的にEコアが使えないので、Pコア数の同じ両者に大きな性能差は出ません。価格差は大きいので、12700Kの方がコスパは高いです。今回は、「M1 Maxにギリギリ勝てる」構成を目指して12700Kにします。（追記：OpenCore 0.7.7からは全コア全スレッドが使用できるようになり、12900Kの優位性が向上します）

macOSではAlder Lake-SのiGPUは使えませんし、今後使えるようになる見込みもありません。そもそもmacOSがサポートしている第10世代CPUのiGPUも、自作マシンではなかなか安定せず使いにくかったです。なのでiGPUが搭載されていないKFモデルを選んでも良いと思います。

BIOSを設定する

BIOSの設定で重要な箇所を以下に列挙しました。大半がデフォルト値のままで良いです。デフォルト値から変更した部分（3箇所だけです）を太字で示します。

OC Tweaker > DRAM Configuration > Load XMP Setting > XMP 2.0 Profile 1
Advanced > CPU Configuration > Intel Hyper Threading Technology > Enabled (default)
Advanced > CPU Configuration > Active Process P-Cores > All (default)
Advanced > CPU Configuration > Active Process E-Cores > 0
Advanced > CPU Configuration > CFG Lock > Disabled (default)
Advanced > Chipset Configuration > Above 4G Decoding > Enabled (default)
Advanced > Chipset Configuration > VT-d > Enabled (default)
Advanced > Chipset Configuration > IGPU Multi-Monitor > Disabled (default)
Advanced > USB Configuration > XHCI Hand-off > Enabled

Eコアを無効にする設定は、macOSを動かす上でとても重要です。これを行わないとカーネルパニックになります。一方で、Hyper Threading (HT)を無効にすれば、Eコアを有効にすることができます。ただし、性能は少しだけ低下します。それで、HTを有効にしてEコアを無効にする設定にしました。（追記：OpenCore 0.7.7からは全コア全スレッドが使用できるようになるので、その場合は、BIOSで全て有効に設定します。）

Above 4G Decodingはデフォルト値の「有効」のままにしておく必要があります。DisabledにするとmacOSの起動途中で止まってしまいます。

なおBIOSはできる限り最新にした方が良いようです。GIGABYTEのマザーボードでは、macOS起動の問題がBIOSアップデートで解決したという報告が多数見つかります。ASRockはマザーボードの発売が遅かったことも関係するのか、最初のBIOSでも問題ありませんでした。でも発売直後のマザーボードはBIOSにバグがあることが多いのでアップデートがあったら実施しておいた方が良いと思います。このマザーボードの現在のBIOSは2.10です。

EFIを設定する

以下のガイド（Gigabyte Z690 Aero G用）を参考にして設定しました。OpenCore 0.7.6を使っています。macOSは12.0.1と12.1 betaで動作確認しました。

使用しているSSDTは以下です。これをACPIフォルダに入れました。

SSDT-AWAC.aml
SSDT-EC-USBX.aml
SSDT-SBUS.aml
SSDT-PLUG-ALT.aml

下の方でリンクしたEFIファイル一式には他のSSDTも入っていますが、config.plistで無効にしてあります。

使用しているkext類は以下です。これをKextsフォルダに入れました。USBPorts.kextは、後述のようにHackintool.appを使って作りました。

Lilu.kext
VirtualSMC.kext
WhateverGreen.kext
SMCProcessor.kext
SMCSuperIO.kext
AppleALC.kext (layout-idは12)
LucyRTL8125Ethernet.kext
NVMeFix.kext
USBPorts.kext

今回公開するEFIファイル一式には他のkextも入っていますが、config.plistで無効にしてあります。

config.plistは、前述のガイドのページで配布されているものを参考に、機種IDなどを設定しました。機種IDはiMacPro1,1にしました。好みでMacPro7,1にしても良いです。ただ、iMacPro1,1の方が設定が簡単です。MacPro7,1の場合は、CPUFriend.kextとそれに付随するkextを使って、動作周波数を最適化しないと、十分な性能が出ません。

12世代CPUはmacOSで採用されていないので、CPU IDをi9-10850KなどのID である000A0655に偽装しています。config.plistのKernel/Emulateの中に以下のように記述します。

オンボードのオーディオは、AppleALC.kextの1.6.7からサポートされています。layout-idは12で動きました。config.plistのDevicePropertiesに追記します。

ボード上のEthernet LANはRealtekのRTL8125BGです。これはLucyRTL8125Ethernet.kextで動きました。

EFIファイルの一式を**ここに**置いておきます。シリアル番号などは削除してありますので、使用される場合は設定してください。

USBポートを設定する

Hackintoolなどでポート番号を調べると、バックパネルのUSBポートは以下のようにアサインされていました。合計で12本です。

マザーボード上の内部コネクタについても少し調査しました。その結果、

マザーボード上のM.2 E keyソケットに接続されたUSBはHS14でした。
また、マザーボード上のUSB Type-Cコネクタは、HS01とSS01でした。

以上の合計がmacOS上限の15本になるので、これらを有効にするようにHackintoolを使ってUSBPorts.kextを作りました。マザーボード上の他の従来型内部コネクタ（USB 2.0と3のピンヘッダ）を使用する場合は、このリストを差し替える必要があります。

スリープ

上記のUSBコネクタ設定は、実際のコネクタの状況を反映した結果ですが、このままだとスリープで問題が発生しました。バックパネルのType-Aコネクタに、キーボードやUSBメモリなどが接続されていると、スリープに入っても1分ほどで復帰してしまいます。その一方で、Type-Aに何も接続されていなければ、正しくスリープします。Bluetoothキーボードなどから復帰することも可能でした。

この問題は、USBPorts.kextでType-AコネクタをInternalに設定することで解決しました。Hackintool.appでしたら、以下のように設定します。

システム環境設定・省エネルギーでは、ネットワークアクセスによるスリープ解除を無効にすると良いかも知れません。Power Napは有効でも問題ありません。1時間に1回くらい起動します。それが気になるようでしたら無効にすると良いです。

ただ、Type-Aに直接接続した一部のキーボードなどから目覚めさせることができないようです。こちらで紹介した格安キーボードではスリープ復帰できませんでした。また、フォーラムで教えてもらった情報によると、スリープ復帰するマウスとしないマウスがあるようです。一方で、Magic KeyboardをUSB接続した状態だと、これからスリープ復帰できました。いずれにしてもBluetooth入力デバイスをメインに使うならば問題ないです。

この設定で残った問題は、Type-Aに接続したキーボードからスリープ復帰できない点です。Bluetooth接続のApple純正キーボード、トラックパッドを使う場合は問題ありません。

ベンチマークで性能評価

Geekbench 5でベンチマークしました。シングルコア性能ではM1 Maxを上回りました。マルチコア性能では互角でした。

以前にGeekbench 5のサイトで確認したM1 Maxのスコアと比較すると以下のようになります。

これにRadeon RX 6600XTを組み合わせれば、M1 Maxより少しだけ性能の良いマシンが作れます。先の記事のGeekbench 5スコア比較を再掲します。

動いていること

ここ2-3日電源を入れっぱなしですが、問題なく安定して動作してます。このままメインマシンにしても良いと考えているくらいです。
システム終了、再起動
有線LAN (ボード上の2.5GbE, Realtek RTL8125BG)
M.2 無線LAN/BT (Broadcom BCM94360NGに交換)
オンボードのオーディオ(ALC897, layout-idを12に設定)
クイックルック、プレビュー
メッセージ、FaceTime, iCloud, App Store, Apple TV
ユニバーサルクリップボード
コンティニュイティ
AirPlayレシーバー（DRMコンテンツの表示も可能）
SafariでのDRMコンテンツ表示（Prime Videoなど）
スリープを開始すると画面が暗くなり、CPUファンが停止します。電源スイッチまたは、Bluetoothキーボード類（Magic Keyboard, Magic Trackpad, 他社のBTマウス）の操作で復帰します。

動いていないこと

Sidecar（自作機にはT2チップが無いので仕方ないです）
Type-A接続の一部のUSBキーボード・マウスからのスリープ復帰（USB接続したMagic Keyboardは復帰可能。BT入力デバイスを使えば問題ありません）

コア数とHTの設定

現在では、Alder Lakeの全てのPコア、ハイパースレッド(HT)、EコアをmacOSで有効にすることができません。（追記：OpenCore 0.7.7から可能になります）上で配布しているEFIは、

BIOSでEコアを無効にしてPコア＋HTを使う（無難で性能が出るのでお勧め）

設定になっています。このほかに、以下の選択肢が可能です。詳しくは上記のetorixさんの投稿をご覧ください。

BIOSでHTを無効にしてPコア＋Eコアを使う（少し性能が落ちる）
BIOSで全コア＋HTを有効にしてSSDTでEコアを無効にする（Windows起動時に性能を出せる）
この場合、SSDT-PLUG-ALT.amlを無効にしてSSDT-PLUG-ALT-12.aml (12600用) もしくはSSDT-PLUG-ALT-12.aml (12900, 12700用) を使う。また、Kernel>Quirk>ProvideCurrentCpuInfoを有効にする。これでmacOSからEコアが見えなくなる。ただしAVX-512が無効になる。
BIOSで全コア＋HTを有効にして、Pコア全部＋Eコアの半分を有効にする。（性能は最大）
この場合、 CpuTopologySync.kextを有効にして、SMCProcessor.kextは無効にして、カーネルのパッチを当てる。パッチは上記のEFIの中のconfig.plistに既に書いてあります。
（追記）OpenCore 0.7.7からBIOSで全コア＋HTを有効にしても動くようになります。Windowsで実行する場合と同程度の性能が出ます。

OpenCore 0.7.6を使う場合は、「BIOSでEコアを無効にしてPコア＋HTを使う」方法が、無難で性能が出るので、Windowsをあまり使わない場合はおすすめだと思います。

Radeon RX 6600 XTをmacOSで使う

Sun, 07 Nov 2021 22:10:51 +0900

Radeon RX 6600 XTをmacOS 12.1で試したところ、問題なく動作しました。5700 XTのベンチマーク比較では、Metalの性能が8%ほど良くなっているようです。ほとんど変わりませんが、TDPは下がっているのでワットパフォーマンスは高いです。

箱から出す

今回使ってみたRX 6600 XTは、Sapphire PULSE Radeon RX 6600 XTです。Sapphire PULSEは、RX 580の時にApple External Graphics Development Kitに搭載されているので、macOSと相性が良さそうな印象があります。グラボ一般が品薄なためか、価格は不安定です。価格.comの価格推移グラフによると、発売直後 (2021年8月) は5.7万円くらいだったものが、10月下旬から7万円程度以上で乱高下しています。11月に入ると少し安定してますが、それでも7万円かそれを切るくらいの価格です。

今まで使っていたRX 5700 XTを取り外して、RX 6600 XTを取り付けました。マザーボードはASRock Z590 ExtremeでCPUは10900Kです。ソフトウェアは、OpenCore 0.7.5 とmacOS Monterey 12.0.1の構成です。

5700 XTが30cm近い大型で重厚なグラボだったのに比べて、6600 XTは一回り小さく、軽く、補助電源も8ピン1個だけです。見るからに格下のモデルなので、交換して性能がどうなるのか不安でした。消費電力にも差があり、5700 XTのTDPが225Wなのに対して、6600 XTは160Wです。

macOS 12.0.1では動かない

現行のmacOSはMonterey 12.0.1です。今まで5700 XTが動いていた状態のところに、グラボだけを6600 XTに交換しました。起動オプションには、

agdpmod=pikera

を指定してあります。この状態で起動したところ、高解像度表示にならず、また表示速度が遅い状態で起動しました。グラフィックスアクセラレーションが効いていない状態です。システム情報を見ても、サポートされていない状況がわかります。

macOS 12.1にアップデート

そこで、パブリックベータとして無料配布されている12.1 Betaにアップデートしました。ビルドは21C5021hです。アップデートしたところ、6600 XTがサポートされて、正常な表示が行われるようになりました。システム情報は以下でした。ベータ版はスクリーンショットの公開ができないので、文字だけで紹介します。

AMD Radeon RX 6600 XT:

チップセットの機種: AMD Radeon RX 6600 XT
種類: GPU
バス: PCIe
PCIeレーン幅: x16
VRAM（総量）: 8 GB
製造元: AMD（0x1002）
装置ID: 0x73ff
リビジョンID: 0x00c1
ROMリビジョン: 113-3E4480U-S6L
Metalファミリー: 対応、Metal GPUFamily macOS 2

Device IDが0x73FFになってます。12.1が6600XTをサポートしたらしいという以下の記事で紹介したDevice IDです。

macOS 12.1からRadeon 6600XTが使える

ちなみに12.1 Betaはなかなか良いです。12.0.1よりもキビキビと動く気がします。大規模アップデートの直後のベータ版なので、改良が進んでいるのだと思います。不安定なところは全くないので、すぐにインストールしても良いのではと思いました。

ベンチマーク

Geekbench 5でベンチマークしました。5700 XTと比較したところ、若干性能向上しています。特にMetalの性能が向上しています。Appleが力を入れているので、デバイスドライバーもMetalに対して手厚く対応しているのではと思いました。6600 XTはTDPが大幅に下がっているので、ワットパフォーマンスで考えると大きく進歩してます。

注目したいのはM1 Maxとの比較です。このスコアは、前回の記事で紹介したGeekbenchに上がっているスコアをそのまま持ってきたものです。5700 XTではOpen CLでM1 Maxに優っているものの、Metalでは僅差で負けてました。6600 XTはMetalの性能が向上したので、明らかにM1 Maxを上回るようになります。大した差ではないですが、M1より良い性能を手に入れらる安心感で、心の平安を得られます。

まとめ

Radeon RX 6600 XTはmacOS 12.1で動きます。性能はRX 5700 XTより少しだけ上で、消費電力は少ないです。グラフィックスボードはまだまだ高値止まりで、6000シリーズローエンドの6600 XTも決して安くはないですが、hackintosh向けおすすめグラボだと思います。

M1 Maxと10コア勝負したら負ける

Sat, 06 Nov 2021 20:39:48 +0900

M1 ProとM1 Maxを搭載したMacBook Proの性能がとても良いらしいです。それで、同じ10コアCPUを搭載した重量級自作マシンとM1 Maxを比較しました。ベンチマークソフトはmacOS 12.0.1上でのGeekbench 5です。結果はわかっていたことですが、負けてます。

比較対象：M1 Max

新型MacBook Proが手元にあるわけではないので、比較対象のM1 MaxスコアはGeekbenchにあるベンチマーク結果です。テンション低くてすみません。M1 MacBook Airで十分な性能ですし、それでも重いので、無印MacBookの復活を待っているところです。OSは、M1 MaxなのでmacOS Monterey 12.0.1のはずです。

Geekbench BrowserのCPUのページでMacBookPro18で検索すると、今回の新製品MacBook Proのスコアが出てきました。

MacBookPro18 - Geekbench 5 CPU Search - Geekbench Browser

18,1から18,4まであるようです。GPUのページでもMacBookPro18で検索しました。

MacBookPro18 - Geekbench 5 Compute Search - Geekbench Browser

新型MacBookProには14インチと16インチモデルがあり、それぞれバリエーションがあります。8コアCPU, 14コアGPUのProが選択が可能なのは、最下位14インチモデルだけです。Geekbenchの結果と照らし合わせると、MacBookPro18,3がこのモデルのようです。また、18,2には32コアGPUの結果のみがあり、18,1と18,4には24コアGPUの結果もあります。これから、32コアGPUのMaxのみを選べる16インチ最上位機種が18,2だと思われます。以上から、

MacBookPro18,3は14インチ最下位モデル
MacBookPro18,2は16インチ最上位モデル
MacBookPro18,1とMacBookPro18,4は中間モデル

と推測しました。番号の並びから18,1が16インチ下位モデル、18,4が14インチ上位モデルと思われますが、両者のCPU/GPU仕様に違いがないので、Geekbenchスコアからは判断できません。

今回の比較対象は、この中から最上位モデルのMacBookPro18,2にしました。Apple Storeで最小構成で見積もると、以下の構成で、税込419,800円です。

32GBメモリ
1TB SSD

比較対象：Intelマシン

最上位M1マシンの挑戦を受けるのは、現在使っているIntelマシンです。M1 Maxと同じ10コアCPUです。OSも同じくmacOS Monterey 12.0.1です。GPUはRX 5700XTです。

CPU: Intel Core i9-10900K (10コア20スレッド)
GPU: AMD Radeon RX 5700XT
ASRock Z590 Extreme
macOS Monterey 12.0.1, OpenCore 0.7.5

これをもとに、MacBook Proと同等の自作機を考えると、以下のような見積もりになると思います。RX 5700XTは新品での入手が困難なので、入手可能でほぼ同等性能と言われるRX 6600XTにしました。macOS 12.1からサポートされます。

M1 Max搭載MacBook Pro対…｜自作PC構成｜自作.com

合計価格は税込281,336円です。MacBook Proよりは安いですが、差額14万円くらいです。割合では3分の2くらいでしょうか。グラフィックスカードの高騰が痛いですね。ノートとデスクトップの違いがありますので、大きくて重くて持ち運べなくてバッテリ無しですが、画面は大きいです。

CPU性能比較

M1無印の時からCPU性能はとても良かったのですが、10コアになってさらに強力になってました。10コアとは言っても、フルスペックのコアは8コアだけなので、10コア全部がフルスペックのインテルCPUも頑張るのではと期待していたのですが、以下のような結果です。M1 Maxのスコアは、Geekbenchのサイトにある最近の測定値3点を選んで平均しました。10900Kのスコアも3回の平均です。

シングルでは、M1無印の頃から負けてましたが、それを引き継いだ性能なので、完敗です。コア数が増えたのでマルチも負けました。M1 Maxの方が、シングルで30％、マルチで15％高性能です。大きなCPUクーラーで冷却している10900Kと、ノート筐体のM1 Maxというハンディを考えると、圧倒的な性能差と言えます。

Geekbenchによると、このマルチ性能に勝てるIntel Macは、iMac Pro最上位（18コア）か、Mac Pro 16コアモデル以上だけのようです。

GPU性能比較

インテルのiGPUは、CPUチップの片隅に載せてもらったおまけのようなiGPUという印象でした。M1だって大したことないだろうと思ってました。比較相手の5700XTは、長さ30cm近い拡張カードに搭載された大きなチップのGPUです。電力も冷却も十分なので、圧勝かと思いました。しかし以下のように、Open CLのスコアは5700XTが17%ほど勝っているものの、Metalのスコアは2％負けてます。これもそれぞれ3回の平均です。2％は誤差と言えますが、数回測っても逆転するのは1〜2回程度でした。

Open CLでM1 Maxが負けているのは、多分AppleがOpen CLに力を入れていないからではないかと思います。一方で、Appleが提唱しているMetalに対しては十分な最適化が施されていて、M1のハードウェア性能をとことん引き出したスコアが出たのではないかと思います。ということで、Open CLでは勝てたけど、Metalでは僅差で負けという結果でした。RX 6900XTだとこの3倍近いスコアが出るとコメントで紹介されていましたので、6900XTなら圧勝できるかもしれません。

まとめ

Intelの10コアCPUと、M1 Maxを比較しました。M1はGeekbenchからもらってきたスコアなので、手抜きです。CPU性能はM1が良いです。Radeon RX 5700XTと比較したグラフィクス性能では、MetalスコアでM1 Maxが僅差で高性能でした。

OpenCore 0.7.4から0.7.5に更新

Tue, 02 Nov 2021 23:15:28 +0900

OpenCoreの0.7.5が公開されたので0.7.4からアップデートしました。大きな変更は無いので、0.7.4のconfig.plistがそのまま動きます。

0.7.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.5とmacOS 12.0.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon 5700 XT + macOS Monterey 12.0.1

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目にほとんど変更はありませんでした。

Booter/Quirks/にResizeAppleGpuBarsが追加されてました。デフォルト値が-1で、この機能は無効になります。BIOSでResizable BAR (Base Address Register)の設定を有効にすると、WindowsではRadeon RX 6000シリーズの性能が上がるらしいです。でもmacOSはこの機能をサポートしていなくて、有効にするとクラッシュする可能性があるとのことです。これに対応するQuirkです。BIOSで設定しない限りは問題なさそうなので、無効にすることとし、-1にしました。
UEFI/Quirks/にResizeGpuBarsが追加されていました。Resizable BARに関係した設定です。デフォルトの-1にして無効にしました。

追加項目はデフォルトのままにしましたので、0.7.4のconfig.plistをそのまま使っているのと同じです。これで、0.7.4から0.7.5に移行できました。

MontereyのUSBインストーラを作ってクリーンインストール

Tue, 26 Oct 2021 12:20:35 +0900

macOS Monterey 12.0.1が配布されたので、Big Surからアップデートしました。最新版のOpenCore (0.7.4) とkext類でBig Surが動いていれば、通常の作業でアップデートできるようです。ここではクリーンインストールしました。

作業に使ったシステム構成

本日 (日本時間2021/10/26)、macOS Monterey 12.0.1 が正式配布されました。Big Surが配布されたのは去年11月13日でしたのでそれより早く、過去のスケジュールに少し戻りました。Big Surの最初のバージョンが11.0.1だったのと同様、Montereyも12.0.1が最初の配布バージョンになりました。インストール先のマシンは、以下で、Z590マザーボードに10900Kを搭載しています。グラフィックスはRadeon RX 5700XTです。ブートローダはOpenCore 0.7.4でkext類は最新にしてあります。

ASRock Z590マザーボードでmacOSを起動する

現在インストールされているmacOSはBig Sur 11.6 (20G165)です。起動ドライブはWDの1TB M.2 SSD, WDS100T2B0Cです。

アップデートの手順

上書きインストールすれば楽なのですが、せっかくの年に一度のメジャーアップデートです。現在のBig Sur起動ディスクであるM.2 SSDの内容を綺麗さっぱりと全消去して、クリーンインストールしようと思います。実は、ホームディレクトリは別ドライブに作ってあるので、起動M.2 SSDを消去してもそれほど面倒なことにはならないと考えました。そこで次の手順でアップデートを進めます。

Montereyインストーラをダウンロードする
USBメモリを用意してMontereyインストールUSBを作る
USBメモリのESPに現在のESPをコピーして起動できるようにする
USBメモリーからインストーラを起動する
インストーラからディスクユーティリティを起動し、M.2 SSDを消去する
インストーラからMontereyをインストールする

1. Montereyインストーラをダウンロード

Big Surの環境から、「システム環境設定」「ソフトウェアアップデート」を開いて、Montereyをダウンロードします。12.13GBあるようです。

ちなみに、「ほかにもアップデートがあります。」の表示が出ています。これをクリックすると11.6.1が来ていました。Montereyをすぐインストールしないという人も、こちらは入れておいた方が良いと思いました。

ダウンロードするといつものように自動的にインストーラが開きます。ここで「続ける」ボタンを押せば上書きインストールが開始します。今回は、クリーンインストールするので、メニューバーから「インストーラを終了」を選び中断します。

2. MontereyインストールUSBを作る

インストーラ用のUSBメモリを用意します。必要な容量は15GB程度ですが、USBメモリの容量は多分32GBはあった方が良いです。今回は32GBのUSB 3.0メモリーを用意しました。このUSBメモリーをディスクユーティリティ.appを使って初期化します。USBメモリを選択して、消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここでAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。Mac OS拡張（ジャーナリング）を選んでおく必要があります。

次に、MontereyインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもMontereyをインストールできるUSBメモリになります。ターミナルを使用して、Montereyインストーラの中のContents/Resourcesに移動するとcreateinstallmediaというファイルがあります。そこで以下のコマンドを入力します。

$ cd /Applications/Install\ macOS\ Monterey.app/Contents/Resources/
% sudo ./createinstallmedia --volume /Volumes/USB/
Password: Ready to start. 
To continue we need to erase the volume at /Volumes/USB. 
If you wish to continue type (Y) then press return: y 
Erasing disk: 0%... 10%... 20%... 30%... 100% 
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100% 
Making disk bootable... 
Copying boot files... 
Install media now available at "/Volumes/Install macOS Monterey"

3. USBメモリのESPに現用のESPをコピーする

4. USBメモリーからインストーラを起動する

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにMontereyインストーラが見えるはずです。

ただ、OpenCoreでデフォルト通りの設定をしていると、起動ボリュームの一覧にこのUSBメモリが現れないかもしれないです。それはconfig.plistのMisc, Security Properties, ScanPolicyのデフォルト設定が原因です。これのデフォルト値は、0x010F0103 (10進数では17760515) です。この設定だと、2重の理由で、今回のUSBメモリが起動ボリューム候補に現れません。

まず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。
また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。

なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はPlistEDPlusを使って変更している様子です。

これで起動項目にUSBメモリのインストーラが現れるようになります。Montereyアイコンのボリュームが、USBメモリーです。このInstall macOS Montereyを選択して起動します。

5. インストール先ボリュームを消去する

USBメモリから起動すると、下のようなメニューが現れます。

6. Montereyをインストールする

Disk Utilityを閉じると、またメニューに戻ります。次にmacOS Montereyインストールを選択します。するとおなじみのmacOSインストーラが起動します。後は、いつものようにインストールを進めていくだけです。

インストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。

この後数分で再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。

次にリンゴマークと棒グラフの表示が出ます。

この後多分5~6分くらいで、また再起動しました。またmacOS Installerが選択されてます。

そして数分でまたまた再起動。今度は、インストール先ドライブにつけた名前 (ここではMacintosh HD) の選択肢が現れ、選択されています。これで起動します。

さらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。あとはいつものように、設定を行ないます。

インストール終了したあと、このMacについてを確認すると、バージョンは12.0.1 (21A559) でした。リリース候補(RC)と同じビルドでした。

まとめ

OpenCoreで起動しているZ590マシンにMontereyをクリーンインストールしました。そのために、単体で起動してMontereyがインストールできるUSBメモリを作りました。いつものようにベータ版で予行演習していたこともありますが、スムーズにMontereyに移行できました。

OpenCore 0.7.3から0.7.4に更新

Sat, 09 Oct 2021 23:46:31 +0900

OpenCoreの0.7.4が公開されたので0.7.3からアップデートしました。大きな変更は無いので、0.7.3のconfig.plistがそのまま動くと思います。

0.7.4をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.4とmacOS 11.6で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。macOS 12 public beta (21A5543b) でも動作しました。

ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.6

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目に変更はありませんでした。ただし、

Misc/Security/SecureBootModelの設定をDefaultに変更しました。T2チップが乗っていないhackintoshでは、x86legacyに設定するのが良いというニュアンスの表現が、前バージョンの説明書に書いてありました。これに対して、今回のバージョンでは、macOS 12以降は機種に合わせた方が良いという追記がありました。DefaultにしておくとSMBIOSのボードIDの記述に合わせて設定してくれるそうです。（以前のバージョンではDefaultにしておくとx86legacyになってました）いずれにしてもDefaultにしておくのが良いようなので、そうしておきました。SMBIOSがしっかり設定できていないようならば、ここで機種を指定した方が良いかもしれません。

これで、0.7.3から0.7.4に移行できました。

BIG SUR 11.6にアップデートする

Tue, 14 Sep 2021 23:11:29 +0900

macOS Big Sur 11.6が配布されたので11.5.2からアップデートしました。通常の方法で、問題なくアップデートできました。アップデートしたのはZ590マザーボードのマシンです。OpenCore 0.7.3で起動していて、kext類は最新です。Montereyがまもなくリリースされると思われますので、これがBig Sur最終版になるのかもしれません。過去のアップデート情報は以下にあります（現時点では11.6の解説はありません）。

https://support.apple.com/ja-jp/HT211896

iMac20,1に設定してあるZ590マシンでは、11.5.2のシステム環境設定の「ソフトウェア・アップデート」に、11.6のアップデートがあらわれていました。「詳しい情報…」をクリックすると、簡単に「macOSのセキュリティが向上します」と説明されてます。

この画面から「今すぐインストール」ボタンを押してアップデートしました。その結果、2.64GBのアップデートファイルがダウンロードされ、複数回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.6が起動しました。ビルドは20G165になってました。

メインマシンをASRock Z590 Extremeに移行

Sun, 12 Sep 2021 22:32:01 +0900

ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けたマシンをメインマシンとして使うことにしました。そこで、今まで使っていたASUS Z390 ROG MAXIMUS XI HEROマザーボードと交換しました。

絶対動くはず

Z390 Coffee Lake-S Refreshで動かすmacOSは、とても安定していて全く問題ありませんでした。なのでZ590に移行する必要性はあまりありませんでした。単に、macOSが動く最後のインテルCPUになるかもしれないComet Lake-Sに移行したかっただけです。とはいえ、8コア16スレッドから10コア20スレッドになるのは、その性能が必要かどうかは別として、嬉しいところです。なので、Z590への移行を以前から計画してました。

移行のために、ASRock Z590 Extremeを検証台（いわゆる、まな板です）で動かして、動作確認してきました。こちらもZ390同様にとても堅牢で安定しています。数日起動し続けても問題ありません。Montereyベータ版も問題なく動作しているので、将来にわたって大丈夫そうです。

今回はいよいよ、検証台のASRock Z590 Extremeを取り外し、PCケースの中のZ390マザーボードと差し替えることにしました。どちらも快調に動いている構成のマザーボードを入れ替えるだけなので、問題は何もなく、すぐに絶対動くものだと思っていました。

一部のSATAが動かない

メインのマシンは、大型のタワーケースで、HDDやSSDをたくさん搭載しています。TimeMachineのバックアップ用大容量HDDや、Windows起動用のSSDなどです。光学ドライブも搭載してます。リムーバブルHDD/SSD用の5.25インチベイも取り付けてます。ASRock Z590 Extremeは、今時のマザーボードとしては珍しくSATAが6ポートあります。今までのASUS MAXIMUS XIと同じ数なので、移行は楽勝のはずでした。でも、6個のうち2個が動きません。

ちゃんとマニュアルを読んでおけばよかったのですが、ASRock Z590 Extremeマザーボードは、3番目のM.2ソケットを使うと、SATAの2個が使えなくなる仕様でした。M.2とSATAに排他的な制約があるのはなんとなく理解してましたが、SATA M.2 SSDを使った場合だけの制約だと勝手に解釈してました。PCIe接続のM.2 SSDを使用した場合でも、2個のSATAが使えなくなるようです。

ということで、M.2 SSDを2番目の（マザーボード中心の）ソケットに移動しました。今の所M.2 SSDは一個しか使ってないのでこれで良いですが、多数のM.2 SSDを使用する場合には、足りないSATAをPCIeカードで拡張しようと思います。

起動が遅い

マザーボードを入れ替えてすぐに気づいた問題は、新しいASRockマザーボードの起動に時間がかかることです。電源を入れるとASRockのロゴが瞬時に出るのですが、その状態が続き、1分くらいかかってOpenCoreの選択画面が表示されます。F2キーでBIOSメニューに入る場合も、同じだけの時間がかかります。この状況から見て、macOSの問題でも、OpenCoreの問題でもなく、ハードウェアかUEFIの問題と思われます。ASRockのロゴを出さないよう設定すると、起動進捗のコードが画面右下に表示されるのですが、この情報からは原因を推測できませんでした。

このマザーボードを検証台で動かしていた時には、起動に時間がかかる問題はありませんでした。PCケースへの引っ越しで新たに追加されたハードウェアが原因と思われます。起動時に少し待てば良いので、我慢できなくはないのですが、OpenCoreやkextの設定を試行錯誤して試す場合には、効率が悪いです。そこで一つ一つ外して起動の様子を観察することにしました。

SATAドライブ

まずはSATA接続のSSD/HDDを全て外しました。HDDの調子が悪くなると、起動時のチェックに問題が出て、時間がかかることがあるそうです。全部外して、検証台での動作と同じくM.2 SSDだけで起動しても、やはり起動時間が長いままでした。原因は他にあるようです。

メモリー

メモリーに問題がある場合もあるようです。でも今回は、検証台で使っていたメモリーをそのまま持ってきたので問題ないはずです。

USBデバイス

次に、USB関係を外しました。以下で紹介した5.25インチベイ取り付けのUSBハブ／カードリーダなどを取り付けてました。でもUSB関係の部品を外しても変化はありませんでした。

USB機器がスリープを阻害することがあります

PCIe拡張カード

今度はPCIeスロットに挿した拡張カード類です。無線カードは以下で紹介したように、BCM94360NGをM.2 key Eソケットに取り付けていて、PCIeスロットは使ってません。マザーボードに取り付けたまま持ってきたのでこれは問題ないはずです。

ASRock Z590 Extremeに無線モジュールを取り付ける

Thunderbolt 4カードも取り付けてます。これも検証台の時から使っていたので問題ないはずです。一応取り外しましたが、起動時間に変化はありませんでした。

macOS で Thunderbolt 4 を使う

引っ越しで追加になったカードは、IEEE 1394カードと、

IEEE 1394 (FireWire) を使う

SATA拡張カードです。

PCIe拡張カードでSATAを増設する

IEEE 1394は、全く使ってないのですが、大昔のiPodやSONYのビデオカメラが動いて面白いのでそのまま取り付けてます。古いカードなので怪しかったですが、取り外してみても変化ありませんでした。

SATA拡張カードが原因

最後にSATA拡張カードを取り外したところ、なんと、一瞬で起動するようになりました。上記の記事では紹介していませんでしたが、実は、HighPoint社の Rocket 640LというSATA拡張カードを取り付けていました。macOSの /Library/Extensions には、HighPoint関係のドライバーが入っているので、macOS標準で動作します。これが問題を起こして、起動に時間がかかっているようです。検索すると、価格コムのレビューが見つかりました。UEFIに対応してなくて、現行のマザーボードとの相性が悪いようです。Z390マザーボードの時は、起動時間の問題は発生しませんでしたが、これに接続したリムーバブルベイに取り付けたHDD/SSDから起動できなかったです。そこで、上記の記事でも紹介したASMedia ASM1061搭載の格安SATA拡張カードに差し替えたところ、問題なく起動しました。このカードもmacOS標準のままで動作します。

まとめ

起動時間が異様に長くなる現象は、自作PCではよくあるトラブルのようです。今回は使用していたPCIeカードが古かったのが原因でした。最小構成になるまで、一つ一つ部品を取り外して動作チェックする定番の方法で原因究明できました。

OpenCore 0.7.2から0.7.3に更新

Fri, 10 Sep 2021 18:01:51 +0900

OpenCoreの0.7.3が公開されたので0.7.2からアップデートしました。config.plistのUEFI/Driversの書き方が変更になったので対応が必要です。それ以外には大きな変更は無いので、0.7.2のconfig.plistがそのまま動くと思います。

0.7.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.3とmacOS 11.5.2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.5.2

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は、以下の2箇所でした。

UEFI/QuirksにForceOcWriteFlashという項目が追加されてました。OpenCoreのシステム変数をフラッシュメモリに書き込めるようにするようです。ThinkPad T430やT530で複数OSを起動する場合などに必要な設定のようです。関係なさそうなので、Default値のfalseにしておきました。
UEFI/Driversの書き方が変更になってました。Driversの中身は配列で、その要素はItem1, Item2, Item3 …という名前です。0.7.2以前はItem1などはstring型で、そこにOpenRuntime.efiとかOpenCanopy.efiとファイル名を書いていました。0.7.3からは、Item1などがdict型になり、Path (string型), Enabled (bool型), Arguments (string型)を書くことになりました。引数が書けるようになったようです。移行するには、Pathに従来通りのefiファイル名を書き、Enabledにtrueを設定すれば良いです。

下は0.7.2以前のUEFI/Driversの書き方です。

0.7.3からは以下のように変更になりました。

これで、0.7.2から0.7.3に移行できました。

BIG SUR 11.5.2にアップデートする

Tue, 17 Aug 2021 22:38:52 +0900

macOS Big Sur 11.5.2が配布されたので11.5.1からアップデートしました。通常の方法で、問題なくアップデートできました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.7.2で起動していて、kext類は最新です。11.5.2が配布されたのは、8月11日(PST)です。

https://support.apple.com/ja-jp/HT211896

更新内容は、簡単に「Macのバグ修正が含まれている」と説明されてます。

iMac20,1に設定してあるZ590マシンでは、11.5.1のシステム環境設定の「ソフトウェア・アップデート」に、11.5.2のアップデートがあらわれていました。そこから「今すぐインストール」ボタンを押してアップデートしました。その結果、2.54GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.5.2が起動しました。ビルドは20G95になってました。

iMac19,1に設定してあるZ390マシンには、システム環境設定には11.5.2のアップデートが現れていませんでした。11.5.1の時と同様で、Monterey betaを受け取るためにApple Beta Software Programに登録してある影響と思われます。今回も、App StoreからBig Surを選択したところ、11.5.2へのアップデートが来ました。この場合、フルサイズのOSがダウンロードされるようで、サイズが12.44GBありました。

OpenCore 0.7.1から0.7.2に更新

Wed, 04 Aug 2021 23:50:15 +0900

OpenCoreの0.7.2が公開されたので0.7.1からアップデートしました。大きな変更は無いです。Montereyの起動で問題になっていたSecure Boot modelのデフォルト設定が変更されて、Monterey起動に対応したようです。新OS対応が進捗している様子です。

0.7.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.2とmacOS 11.5.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS XI HERO + 9900K + Radeon RX 580 + macOS Big Sur 11.5.1
ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.5.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は、以下の1箇所だけでした。

UEFI/AppleInputにGraphicsInputMirroringという項目が追加されていました。非Apple製のグラフィックUEFIアプリケーションにキーストロークが伝わらないことを改善したようです。例えば、WindowsのBitLockerを使う場合に影響が出るそうです。デフォルト値はfalseですが、説明書によるとtrueが推奨値らしいです。Sample.plistでもtrueになってました。macOSを使う限りはfalseでも問題なさそうですが、とりあえず推奨値のtrueに設定しておきました。

これで、0.7.1から0.7.2に移行できました。

SecureBootModelの設定

設定できる値

Apple Secure Bootの機能では、macOSを動かすMacのモデルでは無効な設定や、動かないmacOSバージョンのインストールを防ぐ働きをするようです。config.plistのMisc, Securityの中の SecureBootModelで、Macのモデル名の設定をします。ここで設定できる値は、OpenCoreのマニュアルによると以下です。

Default — Recent available model, currently set to x86legacy.
Disabled — No model, Secure Boot will be disabled.
j137 — iMacPro1,1 (December 2017). Minimum macOS 10.13.2 (17C2111)
j680 — MacBookPro15,1 (July 2018). Minimum macOS 10.13.6 (17G2112)
j132 — MacBookPro15,2 (July 2018). Minimum macOS 10.13.6 (17G2112)
j174 — Macmini8,1 (October 2018). Minimum macOS 10.14 (18A2063)
j140k — MacBookAir8,1 (October 2018). Minimum macOS 10.14.1 (18B2084)
j780 — MacBookPro15,3 (May 2019). Minimum macOS 10.14.5 (18F132)
j213 — MacBookPro15,4 (July 2019). Minimum macOS 10.14.5 (18F2058)
j140a — MacBookAir8,2 (July 2019). Minimum macOS 10.14.5 (18F2058)
j152f — MacBookPro16,1 (November 2019). Minimum macOS 10.15.1 (19B2093)
j160 — MacPro7,1 (December 2019). Minimum macOS 10.15.1 (19B88)
j230k — MacBookAir9,1 (March 2020). Minimum macOS 10.15.3 (19D2064)
j214k — MacBookPro16,2 (May 2020). Minimum macOS 10.15.4 (19E2269)
j223 — MacBookPro16,3 (May 2020). Minimum macOS 10.15.4 (19E2265)
j215 — MacBookPro16,4 (June 2020). Minimum macOS 10.15.5 (19F96)
j185 — iMac20,1 (August 2020). Minimum macOS 10.15.6 (19G2005)
j185f — iMac20,2 (August 2020). Minimum macOS 10.15.6 (19G2005)
x86legacy — Macs without T2 chip and VMs. Minimum macOS 11.0.1 (20B29)

このうちx86legacyはT2チップを搭載していないMacのための選択肢です。一方、jで始まる選択肢は、T2チップを搭載したMacに対応してます。以下のMacが該当します。

Apple T2 セキュリティチップ搭載モデルの Mac

自作PCには当然ながらT2チップを搭載していないので、x86legacyの設定が良さそうです。ただし、x86legacyに設定するとmacOS 11.0.1以降のみしか起動しません。古いmacOSを使いたい場合は、SystemProductNameで設定したモデル名がT2搭載ならば、jから始まる選択肢を設定しても良いかと思います。11.0.1より古いmacOSをT2未搭載モデルで使いたい場合は、SecureBootModelをDisabledに設定すると良いです。DisabledにするとApple Secure Boot自体が無効になります。

SecureBootModelをDefaultにすると、一番無難な選択肢を選んでくれるようです。OpenCore 0.7.1では、Defaultにするとj137、すなわちiMacPro1,1に設定されていました。OpenCore 0.7.2では、Defaultにするとx86legacyに設定されるよう変更されました。

Montereyインストールの注意事項

OpenCore 0.7.1でMontereyのパブリックベータ版をインストールする際には、config.plistのSecureBootModelをDisabledに設定する必要がありました。SecureBootModelをT2チップ搭載Macに設定すると、インストール途中で起動を繰り返す状態になり、先に進みません。インストールが終了した後ならば、T2チップ搭載Macとして設定しても起動するようです。0.7.1でDefaultと設定すると（iMacPro1,1と設定され）インストール途中で再起動が繰り返され、先に進まなくなりました。0.7.2ではx86legacyに設定されたため、Defaultの設定でもインストール可能になりました。Defaultではなく、x86legacyに設定しても同じことなのでMontereyのインストールは可能です。おそらくは0.7.1でもx86legacyに設定すればMontereyのインストールが可能だったのではと思います。

Z590とZ390の設定

iMac20,1に設定してあるASRock Z590 Extreme + 10900Kマシンは、機種名に合わせて j185に設定してみました。j185に設定すると、Montereyのインストールは失敗しますが、インストールされたMontereyは起動します。なのでMontereyをインストールするときだけはx86legacyに設定する必要があります。

iMac19,1に設定してあるもう一台のZ390マシンは、T2チップ未搭載なのでDefaultにしておきました。現行のmacOSしか使わない予定なのもDefaultにした理由です。もしもこのマシンでmacOS 11.0.1より前のmacOSを起動したい場合は、Disabledに設定する必要があると思います。

macOS Monterey 12 Beta をインストール

Mon, 02 Aug 2021 23:14:54 +0900

Public Beta Programで配布されているmacOS Monterey 12.0 Beta（21A5294g）をダウンロードして、ASRock Z590 + 10900K + OpenCore 0.7.1で構成した自作PCにインストールしました。config.plistでSecureBootModelを無効に設定する必要がありました。新機能のAirPlayレシーバーが動作することを確認しました。

ダウンロード

Big Surを動かしているZ590マシンをPublic Beta Programに登録したところ、システム環境設定のソフトウェアアップデートにMontereyが現れました。サイズは11.73GBでした。

1時間弱でダウンロードは終了し、ダウンロード後にインストーラが起動します。それは中断します。するとApplicationフォルダにInstall macOS Monterey beta.app（日本語名はmacOS Montereyベータ版インストール.app）というアプリケーションができています。

インストール用USBメモリを作る

次に32GB容量のUSBメモリを用意しました。これをGUID, Mac OS拡張（ジャーナリング）でフォーマットし、ここではusbという名前をつけました。ターミナルでInstall macOS Monterey beta.appの場所にcdします。この中のContents/Resourcesの中に

% cd /Applications/Install\ macOS\ Monterey\ beta.app
% cd Contents/Resources/

お馴染みのcreateinstallmediaコマンドがあります。オプションなしで起動すると、ヘルプが表示されます。

% ./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

downloadassetsはファームウェア関係のファイルをダウンロードする機能のようです。無効にしたところ、後の工程で失敗したので、有効にした方が良いようです。

% sudo ./createinstallmedia --volume /Volumes/usb --downloadassets

とタイプします。これで用意したusbメモリが初期化されて、そこにMontereyのインストーラが作られます。

インストール

Montereyを試すために、今まで使用していたBig Sur用のM.2 SSDに加えて、250GBのM.2 SSDを新たに追加しました。BIOS起動は、引き続きBig Sur用SSDのESPから行いました。ESP内のOpenCoreとkext類などは最新にしてあります。最新のOpenCore 0.7.1はMontereyにかなり対応しているようです。config.plistの設定は、Big Surと同じです。上で作成したインストール用USBメモリを挿して起動すると、OpenCoreの起動選択画面にUSBメモリのインストーラが現れました。

これを選択すると無事、インストーラが起動しました。インストーラの中でディスクユーティリティを起動して、新しく取り付けたM.2 SSDをGUID, APFSでフォーマットしておきます。次に、インストーラでMontereyのインストールを進めます。いつものようにUSBメモリからの作業が終了すると、再起動し、次にインストール先のSSDから起動します。

SecureBootModelを無効にする

ここまでは順調だったのですが、インストール先SSDからの起動途中で失敗して、再起動されるようになってしまいました。何度も何度も再起動が繰り返されます。USBインストーラを使わない方法（11.5の環境からMontereyインストーラを起動してSSDにインストール）を試みても、やはり再起動で失敗します。それで暫くつまづいていました。でも、これはよく知られた症状のようで、このサイトのフォーラムでも解決方法が紹介されています。灯台下暗しでした。（kgraphさん、ありがとうございました）

macOS Monterey

Montereyのインストール途中で再起動が繰り返される問題は、config.plistのMisc, Securityの中の SecureBootModelの設定をDisabledにすれば良いようです。今まではDefaultに設定していました。これで無事インストールが進み、Montereyが起動しました。起動のセキュリティが仕様変更されたか、もしくは厳しくなったようです。

追記：SecureBootModelがDefaultでも起動が可能

OpenCore 0.7.2からはSecureBootModelの設定がDefaultでも起動可能になったようです。以下をご覧ください。

OpenCore 0.7.1から0.7.2に更新

AirPlayレシーバーが動く

Montereyの新機能にAirPlayレシーバーがあります。Montereyの英語ページで「AirPlay to Mac」という名前で紹介されている機能です。ちなみに日本語ページでは「MacにAirPlayを」です。これで他のApple製品から音楽や動画をMacで再生できます。今まで、HomePodやAppleTVでできていた機能が、Macでも可能になりました。

MontereyでAirPlayレシーバーを動かすためには、本物のMacやM1のセキュリティチップが必要なのではという推測もありましたが、自作PCでも動きました。おそらくは他のiOS連携機能と同じく、無線モジュールが純正に近い必要があるのかもしれません。試したマシンでは、BCM94360NGを使用してます。

ASRock Z590 Extremeに無線モジュールを取り付ける

Montereyの「システム環境設定」から、「共有」を選ぶと選択肢の中に「AirPlayレシーバー」が新たに現れています。これを選択して、一番緩い設定の「すべての人」にAirPlayを許可しました。ベータ版の利用規定の関係でスクリーンショットは省略します。

これでiPhoneなどから動画などをhackintoshに映し出すことが可能になりました。また、MacBookなどから接続すれば、外部ディスプレイのようにも設定できます。画面のミラーリングもできるし、2番目のサブスクリーンにもなります。ただし、コンテンツ保護には元々対応させていなかったので、Amazon Primeビデオなどは表示できませんでした。WhateverGreen.kextなどの設定を頑張ってコンテンツ保護に対応すれば対処できるのかもしれません。YouTube動画などは問題なく表示されました。

BIG SUR 11.5.1にアップデートする

Sat, 31 Jul 2021 17:46:24 +0900

macOS Big Sur 11.5と11.5.1が配布されたので、遅ればせながら11.4からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.7.1で起動していて、kext類は最新です。

更新内容

7月21日に11.5のアップデートが配布されて、7月26日に11.5.1が配布されています。

11.5は、PodCast、Music、M1関連のバグ対応で、

11.5.1はセキュリティ関連のアップデートのようです。

11.5.1へアップデート

iMac20,1に設定してあるZ590マシンでは、11.4のシステム環境設定の「ソフトウェア・アップデート」に、11.5.1のアップデートがあらわれていました。そこから「今すぐインストール」ボタンを押してアップデートしました。その結果、2.93GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.5.1が起動しました。ビルドは20G80になってました。

11.5へアップデート

iMac19,1に設定してあるZ390マシンでは、11.4のシステム環境設定の「ソフトウェア・アップデート」に、11.5のアップデートがあらわれていました。11.5.1は来ていないようです。そこから「今すぐインストール」ボタンを押してアップデートしたところ、1回の再起動でアップデートされました。放置しておいたら、Big Sur 11.5が起動しました。ビルドは20G71になってました。このマシンにも11.5.1へのアップデートがそのうちに来るのではと思ってます。

追記：11.5.1へのアップデート

Z390マシンのアップデートがなかなか来ないので、結局App StoreからBig Surを選択したところ、11.5.1へのアップデートが来ました。自動的に再起動して、問題なくアップデートできました。自動でアップデートが来なかったのは、Monterey betaを受け取るためにApple Beta Software Programに登録してある影響だったのかもしれません。

OpenCore 0.7.0から0.7.1に更新

Sun, 18 Jul 2021 22:23:10 +0900

OpenCoreの0.7.1が公開されたので0.7.0からアップデートしました。config.plistの変更点は2箇所のみで、OpenCanopy関連の変更もありませんでした。macOS Montereyへの対応が進んだようです。

0.7.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。更新点には、macOS Montereyに対応した項目が多くありました。新OSに向けて準備が進んでいる様子で楽しみです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.1とmacOS 11.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS XI HERO + 9900K + Radeon RX 580 + macOS Big Sur 11.4
ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.4

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は以下でした。

ACPI/QuirksにSyncTableIdsという項目が追加されていました。古いWindowsのライセンス関係に影響するSLICテーブルの互換性に関する項目のようです。特に問題を感じていないので、デフォルトのままfalseにしておきました。
Kernel/SchemeにCustomKernelという項目が追加されていました。ESPにカスタマイズカーネルのキャッシュを作ってくれる機能のようです。AtomやAMDのCPUの場合に必要となる可能性があるようです。手元のマシンでは当てはまらないのでデフォルトのままfalseにしておきました。

これで、0.7.0から0.7.1に移行できました。

OpenCore 0.6.9から0.7.0に更新

Sun, 13 Jun 2021 23:16:31 +0900

OpenCoreの0.7.0が公開されたので0.6.9からアップデートしました。config.plistの大きな変更点はありませんでした。またOpenCanopyが動かなくなりましたので、EFIのOC/Resourcesの中身を、配布されているものに差し替えました。

0.7.0をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.7.0とmacOS 11.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS XI HERO + 9900K + Radeon RX 580 + macOS Big Sur 11.4
ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.4

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は以下のようでした。

Kernel/QuirksにProvideCurrentCpuInfoという項目が追加されていました。kernelに現在のCPU情報を提供するというフラグです。Microsoft Hyper-Vのためのパッチだそうです。デフォルトのままfalseにしておきました。
Misc/SecurityにAllowToggleSipという項目が追加されていました。OpenCoreピッカー（起動時の選択メニュー）でSIPをon/offできるようにするかどうかの選択肢です。元々SIPを無効にすることをOpenCoreでは推奨していないので、必要な場合のみ、一時的に使って下さいという記述がありました。なのでデフォルトのままfalseにしておきました。
NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82にForceDisplayRotationInEFIという項目が追加されていました。EFIの表示を回転できるようです。デフォルトの0度にしておきました。
UEFI/OutputにGopPassThroughという項目があります。0.6.9ではbool型でfalseを設定していたのですが、0.7.0ではこれがstring型になってました。on/offの他に、Appleという選択肢が可能になったためstring型になったようです。Appleの場合は、AppleFramebufferInfoを有効にしたプロトコルで提供すると書いてありました。今まで問題なかったので、デフォルトのままのDisabledにしておきました。
UEFI/ProtocolOverridesにAppleEg2Infoという項目が追加されていました。Apple EFI Graphics 2プロトコルをビルトインのバージョンに入れ替えるという機能らしいです。EFI画面の回転に関係するようです。デフォルトのままfalseにしておきました。
Misc/BootにあるPickerVariantの指定方法が変更になった様です。詳細は後述します。デフォルト値は今までと同じくAutoなので、そのままで良いです。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.9から0.7.0に移行できました。

Pickerアイコン指定方法が変更

前節の変更で起動はできましたが、0.6.6や0.6.8の時のようにOpenCanopyが動かなくなり、起動時の選択メニュー (Pickerメニュー）が文字だけのメニューに戻ってしまいました。そこで以前と同じく、以下から、Resources/Image, Font, Labelを取り寄せて交換したところ、動くようになりました。

GitHub - acidanthera/OcBinaryData

上記からダウンロードしたファイルを確認すると、Resources/Imageの中身にさらにディレクトリのある構造になってます。以前は、Imagesの中に直接アイコンファイルが置かれていました。今回からは、ESPのOCフォルダーにも、配布されている形のディレクトリ構造を保ってコピーすれば良いようでした。

コメントで教えていただいて気づいたのですが、Pickerに表示するアイコンの指定方法が変更になった様です。これを指定するパラメータはconfig.plistのMisc/BootにあるPickerVariantです。0.6.9までは、この値（文字列です）は、

Auto (デフォルト) 背景色に合わせて適切なアイコンが自動選択される
Default 通常の名前のアイコンファイルが選択される
Old Oldで始まる名前のアイコンが選択される
Modern Modernで始まる名前のアイコンが選択される
（それ以外の値）カスタムアイコンとしてサポートされていれば指定できる

という規則でした。ファイル名の最初の文字で区別する方式です。例えばHDDのアイコンなら、PickerVariantにDefaultを指定するとHardDrive.icnsという名前のファイルが使用されますが、Modernを指定するとModernHardDrive.icnsという名前のファイルが使用されます。

これに対して、0.7.0では、上で説明したようにディレクトリで分類されるようになりました。アイコンファイルは66個くらいあるので、名前だけで区別するのは面倒ということだと思います。なので0.7.0のPickerVariantは、

Auto 背景に合わせて自動的に選択される。
Default Imageの中のAcidanthera\GoldenGateを選択する。
Acidanthera\GoldenGate Imageの中のこのディレクトリを選択する。macOS 11スタイルのアイコンセット。
Acidanthera\Syrah Imageの中のこのディレクトリを選択する。macOS 10.10スタイルのアイコンセット。
Acidanthera\Chardonnay Imageの中のこのディレクトリを選択する。スタイルのアイコンセット。

特にこだわりがなければ、今まで通り、デフォルト値のAutoを指定しておけば良いと思います。

UEFI ShellをBIOSから起動する

Wed, 02 Jun 2021 23:54:14 +0900

EFI System Partition (ESP)の中のconfig.plistやkext類を変更して、macOSが起動しなくなってしまうことがあります。そんな時のためにUEFI shellを使えるようにしておくと復旧作業に役立ちます。CloverやOpenCoreにはUEFI shellを起動する機能がありますが、BIOSメニューから起動する方法をまとめました。

UEFI Shellで復旧する（おさらい）

UEFI shellを使えば、OSが起動する前段階のUEFIが制御している状態で、ファイルシステムの中身を編集できます。なのでOSの起動に失敗している場合に、その状況を治せる可能性があります。ただしUEFIから読み書きできるファイルシステムに限定されるので、APFSやHFS+の中身は見ることも書き換えることもできません。でも、通常FAT32でフォーマットされるESPは編集可能です。ESPの中のconfig.plistやkext類を変更して起動しなくなってしまった場合は、UEFI shellで編集できるので、システムを復旧させることが可能です。UEFI shellについては、過去の記事でも紹介しました。

起動しないマシンをUEFI Shellで救う

この記事では、CloverまたはBIOSからUEFI shellを起動して、ESPを復旧する方法を説明しました。OpenCoreでも、EFI/OC/ToolsにOpenShell.efiを入れておき、config.plistでこれを認識するよう設定すれば、OpenCoreの起動メニューからUEFI shellを起動できます。この先は、以前の記事のダイジェストになりますが、基本的には

OpenCoreを入れたESPの場所を探して、
shellコマンドで編集する

という作業を行います。UEFI shellの使い方は、こちらのサイトの説明が簡潔でわかりやすかったです。

UEFI Shell のコマンド - 一寸先は/dev/null

UEFIから見えるボリュームは、fs0:, fs1:, fs2: …のように名前がついています。shellコマンドから

ls fs0:

などと入力すれば、この例ではfs0:のルート部分が見えます。この内容を見ながら、OpenCoreが使っているESPの場所を探して行きます。接続されたボリュームの数が少なければ、fs0:かfs1:くらいでOpenCoreのESPが見つかりますが、多い場合は探すのが大変です。そんな時に、mapコマンドが便利です。mapとタイプすると（またはmap -bとすれば画面に合わせて表示が停止します）、例えば以下のような表示がされます。長いので…で省略してます。

> map
Mapping table
FS0: Alias(s):HD0c0a0b:;BLK1:
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x2,0x0)/USB(0x0,0x0)/HD(1,MBR,...
FS1: Alias(s):HD1a65535a1:;BLK3:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,...
FS2: Alias(s):HD1a65535a2:;BLK4:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(2,GPT,...
FS3: Alias(s):HD1a65535a4:;BLK6:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(4,GPT,...
FS4: Alias(s):HD1a65535a5:;BLK7:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(5,GPT,...
FS5: Alias(s):HD1b65535a1:;BLK9:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT,...
FS6: Alias(s):HD1c65535a1:;BLK12:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x2,0xFFFF,0x0)/HD(1,GPT,...
FS7: Alias(s):HD1d65535a1:;BLK15:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x3,0xFFFF,0x0)/HD(1,GPT,...
FS8: Alias(s):HD2b:;BLK20:
PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0)/NVMe(0x1,...)/HD(1,GPT,...
...

これを見れば、探すべきドライブの見当をつけることができます。接続方式がUSB, SATA, NVMeと分類されています。またパーティションマップが、MBRなのかGPTなのかもわかります。このマシンでは、NVMeにOpenCoreのESPを入れているので、fs8:が探しているボリュームだとわかります。その場合、

fs8:

とタイプしてそのボリュームに移動します。Windowsでcドライブやdドライブに移動する方法と同じです。次に、cdコマンドでOCのディレクトリに移動して、

cd EFI\OC

ここでls, cd, cp, mv, cp, rm, edit, type (Unixのcatに相当)コマンドを駆使して、ファイルを操作します。ディレクトリの区切りが、macOSやLinuxと違い、Windows風の逆スラッシュになってます。config.plistのバックアップがあってそれがもしconfig_old.plistという名前なら、

mv config_old.plist config.plist

コマンドで元に戻せます。config.plistを変更する場合には、このように確実に動くバージョンを残しておくと、簡単に元に戻せるので楽です。config.plistを編集したい場合は、

edit config.plist

でエディタを起動します。このエディタでは、コントロールEでヘルプが表示されます。操作は簡単で、

Ctrl-G 行に移動。行番号の入力を促される
Ctrl-S ファイルを保存する
Ctrl-Q 終了する
Ctrl-F 検索する
Ctrl-R 検索・置換する
Ctrl-K 行をカットする
Ctrl-U 行をペーストする
Ctrl-O ファイルを開く
Ctrl-T ASCIIとUNICODEの切り替え
Ctrl-E ヘルプを開く
Ctrl-W ヘルプを閉じる

です。これで大体の編集は可能なので、config.plistを元に戻すことができます。config.plistを保存し、エディタを終了した後で、

exit

もしくは

reset

コマンドをタイプしてシェルを抜けます。resetコマンドはシステムがリセットされます。exitコマンドでは、OpenCore選択画面に戻ります。大体はexitコマンドでokですが、変更内容によっては変更が反映されないことがあります。resetの方がより確実です。

USBメモリーから起動する

UEFI shellはCloverやOpenCoreの選択画面から起動するだけでなく、UEFI環境でshellを直接起動することもできます。UEFI shellはHackintoshのためのツールではありませんので、こちらが本来の使い方です。

通常のUEFIマザーボードの起動ステップでは、FAT32でフォーマットされたドライブの中にある、EFI/Boot/bootx64.efiというファイルを実行しているようです。実際に、OpenCoreのESPにもEFI/BOOT/BOOTx64.efiというファイルがあります。WindowsをインストールしたドライブのESPにも、EFI/Boot/bootx64.efiというファイルがありました。ディレクトリ名やファイル名の大文字小文字はどちらでも良いようです。UEFI shellのプログラムにbootx64.efiという名前をつけて、このディレクトリにおけば良いようです。

そこで、まずはUSBメモリをFAT32でフォーマットします。パーティションマップはMBRでもGPTでも良いようですが、今回は単純にMBRで試しました。次にこのUSBメモリに、EFI/Boot/というディレクトリを作ります。この中に、OpenCoreで配布されている一式に含まれるOpenShell.efiをコピーして、これをbootx64.efiという名前に改名します。OpenShell.efiは、OpenCoreの起動メニューから動かすために、通常はEFI/OC/Tools/の中に入れているファイルです。その結果、USBメモリには、

EFI/Boot/bootx64.efi

のような位置と名前で、OpenShell.efiが入ります。このUSBメモリを挿したままコンピュータを起動し、BIOSメニューに入ると、Boot選択の画面に、以下のようにUSBメモリが現れるはずです。

ここでは、

UEFI: JetFlashTrabscend 4GB 8.07, Partition 1 (4.0GB)

という名前で見えています。小さなサイズのUSB 2.0のUSBメモリを使いました。このボリュームを選択して起動すれば、UEFI shellが起動します。使い道のない古いUSBメモリですが、UEFI shellを入れておけばいざというときに役立ちます。

BIOSメニューから起動する

マザーボードのBIOSメニューに、UEFI shellを起動する機能が提供されていることがあります。マザーボードメーカによって、事情が異なるようです。最近の状況を調べてみました。

MSIマザーボードの場合

以前の記事ではMSIのマザーボードの例を書いていました。MSIのマザーボードでは、独自にUEFI shellのソフトウェアを用意しているようで、BIOSメニューから選択するとそのshellが起動しました。なので、CloverやOpenCoreで用意したshellとは違うバージョンのshellが起動しました。現行のMSIマザーボードが手元に無いので確認できませんが、MSIのZ590マザーボードのマニュアルを見る限りでは、Settings/Save & Exit/Boot Overrideのメニューに、UEFI: Built-in EFI Shellという選択肢が健在のようですので、

引き続き内蔵のshellが起動できるようです。

ASUSマザーボードの場合

Z390 ROG MAXIMUS XI HEROでは、Exitメニューの中に、Launch EFI Shell from USB drivesという項目があります。USBメモリーのルートにUEFI shellのプログラムを、Shell.efiという名前で入れておけば、ここから起動できます。これ以外の名前ではダメなようです。

ただし、BIOS設定でCSMをenabledにしてレガシー起動を可能にしておく必要があります。

Shell.efiを置く場所は、UEFIが見ることのできるボリュームのルートならどこでも良いようです。USBメモリがFAT32でフォーマットされているなら、そのルートで良いです。でもHFS+やAPFSはUEFIから見えないのでダメです。ESP (EFIシステムパーティション）でもokです。また、BIOSメニューにはUSBメモリから起動とありますが、それ以外のドライブでも起動できます。なので、OpenCoreを起動しているESPのルートに、OpenCoreのToolsフォルダからUEFI shellを次のようにコピーしておくと良いと思います。もちろんファインダーのドラッグ&ドロップでもokです。

 % cp /Volumes/EFI/EFI/OC/Tools/OpenShell.efi /Volumes/EFI/Shell.efi

この作業をしておけば、ESPの内容をうっかり間違って設定してしまっても、UEFI shellを起動できます。

GIGABYTEマザーボードの場合

実を言うと最近はGIGABYTEマザーボードを使っていないので、良くわかりません。マザーボードメーカを、GIGABYTE –> MSI –> ASUS –> ASRockと遍歴してきたので、最近の事情に疎くて、UEFI shellがBIOSから起動できるかどうかわかりません。マニュアルを取り寄せて見た限りでは、BIOSメニューからUEFI shellを起動する機能に関しての記載が無いようです。もしかしたら起動できないのかもしれません。ご存知の方いらしたら情報よろしくです。

ASRockマザーボードの場合

ASRockの場合は、Exitメニューの中に、Launch EFI Shell from filesystem deviceという項目があります。これを選択すると、M.2, SATA, USBなどに接続されていてUEFIでアクセスできるファイルシステムのルートに置かれたshellプログラムを起動してくれます。ASUSの機能と全く同じです。なのでASRockでも、OpenCoreでは通常EFI/OC/Toolsに置かれるOpenShell.efiを、EFI直下にコピーして入れて置くと、このメニューからそれが起動します。

ASRockの場合は、シェルプログラムのファイル名はなんでも良いようで、例えばOpenShell.efiのままでも起動しました。OpenCore用に入れているOpenShell.efiを以下のコマンドのようにしてコピーしておくだけです。もちろんファインダーのドラッグ&ドロップでもokです。

 % cp /Volumes/EFI/EFI/OC/Tools/OpenShell.efi /Volumes/EFI/.

とはいえ、ASUSに合わせてShell.efiにしておいた方が混乱しなくて良いかもです。

各社UEFI shell機能のまとめ

各社のBIOS画面からのUEFI shell起動機能をまとめると

MSI: マザーボードに内蔵されているshellプログラムを起動する。
ASUS: EFIがマウントできるボリュームのルートに置いたshellプログラムを起動。プログラム名はShell.efiであること。
GIGABYTE: 不明。起動できないかもしれない。
ASRock: ASUSと同じく、EFIがマウントできるボリュームのルートに置いたshellプログラムを起動。プログラム名は任意のようで、OpenShell.efiなどでも起動。

となりました。MSI > ASRock = ASUS > GIGABYTEの順番に、利便性が良いと思います。ASUSとASRockの場合は、起動ボリュームのEFIにShell.efiとして入れておくと、いざという時に役立ちます。MSIは、shellプログラムがマザーボードに内蔵されているのでもっと安心です。

まとめ

Hackintoshの設定を変更して起動しなくなる経験は誰にでもあると思います。そんな時に便利なUEFI shell機能は、

OpenCoreやCloverの起動メニューから立ち上げる
起動ボリューム（USBメモリでも可）から立ち上げる
BIOSメニューから立ち上げる

などの方法で起動可能です。UEFI shell起動の方法と使い方を知っておくと、いざという時に対処できるかと思います。

macOS で Thunderbolt 4 を使う

Sun, 30 May 2021 20:49:50 +0900

ASRockのZ590 Extreme + 10900KマシンにThunderbolt 4増設カードを取り付けました。これにThunderbolt 3 SSDを接続して動作確認しました。macOS Big Sur 11.4とOpenCore 0.6.9の環境で動かしたところ、hot plugは機能しないものの外付けドライブとして認識されて、M1 MacBook Airと同程度の速度で使用できました。

HackintoshでThunderbolt

Thunderboltの状況について昔の記事で紹介しました。

ThunderboltとHackintosh

現在もあまり変わっていないように思います。hot plugが効かなくても良ければ、つまり起動時に識別されるドライブや機器を使うだけならば、簡単に使用することができます。でもそれ以上の設定を行う場合には、色々と試行錯誤が必要のようです。Thunderboltの初期の頃に、外付けドライブの動作を試したことがありましたが、その時もhot plugは効きませんでした。今回も外付けドライブがとりあえず使えることを目標にします。

Thunderboltの3と4

Thunderbolt 4は、ごく最近、500シリーズチップセットになってから登場した規格です。現行のIntel MacとM1 Macが採用しているのはThunderbolt 3で、4ではありません。なのでmacOSも3だけをサポートしていると考えて良いでしょう。

とはいえ、Thunderbolt 3と4の違いはほとんどありません。最大データ転送速度はどちらも40Gbpsです。Thunderbolt 3の電気特性や仕様にばらつきがあったところを整理したのがThunderbolt 4なのではと理解しています。例えば3では、40Gbpsを実現するケーブル長が0.8mのものもあったところが、4では2mとされてます。また、3では使用するPCIeが2レーンである場合もあったところが、4では4レーンのみになり、32GbpsのPCIe最大データ転送速度が確保されるようです。この結果、PCIe拡張ボックス、Display Port接続などで4レーンの速度が必ず使えるようになってます。

Thunderbolt 3用SSD

Thunderboltの機能を確かめるために、Thunderbolt 3 対応SSDを用意しました。具体的には、以下のThunderbolt 3用SSDケースを用意しました。

少し分厚い (15mm) ですが、革風のエンボス加工がしてあって質感は良いです。内部にはNVMeのM.2 SSDを装着することができ、ヒートシンクも付属しています。搭載されているThunderboltコントローラチップはIntel JHL6540です。

内蔵するSSDは価格コムで安かったPNYのNVMe Gen3 x 4の256GBにしました。今チェックしたら、倍近くに急騰している様子で、あまりお勧めではないかもしれません。パッケージには、読み取り1,700MB/s, 書き込み1,100MB/sと書いてありました。

M1 MacBook Airで動作確認

自作機で試す前に、ちゃんとしたMacでどのように認識されて、速度が出るのかを確認しました。起動しているMacBook Airに接続したところ、hot plugが効いて、Thunderbolt/USB4ハードウェアとして認識されました。

MacもSSDもThunderbolt 3なので、Thunderbolt 3として認識されています。最高速度は40Gbps x 1となってました。ただ、ディスクユーティリティ.appで情報を見るとPCIe接続になっているようです。装置ツリーバスの値を、Hackintool.appの情報と比較したところ、この場所にはPhison Electronics社のPS5013というチップが接続されていました。調べたところ、NVMe SSDをPCIeに接続するコントローラチップで、M.2 SSDに搭載されているチップのようです。

これをAPFSでフォーマットして、AmorphousDiskMarkで測定しました。以下のように、SSDのパッケージに書いてある通りの速度が出ています。

参考までにM1 MacBook Air内蔵のSSDはこの倍くらい高速です。

Thunderboltドライブは取り外し可能ドライブとして認識されています。取り外した後、再度接続すると再認識されてマウントされます。hot plugが完璧に動作していることを確認できました。

(おまけ) Z390のUSB Type Cで使ってみる

MacでのThunderbolt SSDの動作確認ができたので、いよいよhackintoshで試してみます。まずは、Thunderboltの無い自作PCに、Thunderbolt SSDを挿すとどうなるのかを確認しました。使用したのはASUSのZ390マザーボードです。バックパネルにUSB Type Cポートがついていますが、Thunderboltではありません。OpenCore 0.6.9 + macOS Big Sur 11.4の構成です。ここにThunderbolt SSDを接続したところ、しばらくして以下のような通知が出ました。

Thunderboltがついていないので当然の結果ですが、Thunderboltデバイスが接続されたということをmacOSが正しく把握していることが確認できました。

ASRockのTB 4カード

では、いよいよThunderboltハードウェアを搭載したhackintoshで試してみます。使用するマザーボードはASRockのZ590 Extremeです。最近になって。メーカのサイトによると、搭載されているコントローラはIntel JHL8540だそうです。

ASRock「Thunderbolt 4 AIC」製品情報

Thunderbolt 3でよく使われたチップはJHL6x40でファミリー名はAlpine Ridgeでした。JHL8540は、Maple Ridgeというファミリー名だそうです。macOSがサポートしているのはAlpine Ridgeと言われていて、Maple Ridgeがどの程度動くのか未知数です。

カードはPCIe x 4を使用するので、マザーボードの真ん中のPCIe x 16スロット (PCIE3) に挿しました。このソケットは、形状こそx16ですが、マニュアルによると実際にはx4で接続されるようです。ここはチップセット経由のPCIeで、大元のCPUとの接続がx4なので仕方ないですね。Thunderboltカードには十分な仕様です。

カードには、マザーボードに接続するケーブルが2本付属しています。1本はPCIE3ソケットにすぐ隣にあるThunderbolt AICコネクタへ接続します。5ピンでケーブルも太いので、おそらくは電源強化用ですね。Type CのPD (Power Delivery) に対応するための強化策だと思います。もう1本のケーブルは、マザーボード上のUSB 2.0ピンに接続します。Type CにはUSB 2.0を一本用意しないといけないので、その接続用だと思います。

カード背面には2個のType CコネクタとDisplay Portコネクタがついています。DPの方は入力用で、グラフィックスカードなどに接続します。Type Cコネクタにディスプレイを接続する場合に使用します。今回は接続しませんでした。

BIOS設定

次に、Thunderboltが動くようにBIOS設定します。BIOS設定のAdvanced –> Intel Thunderbolt –> Discrete Thunderbolt SupportをEnabledにします。デフォルトではDisabledになっています。

Thunderboltを有効にすると、

Thunderbolt Boot Support
Thunderbolt USB Support
Windows 10 Thunderbolt support

の項目が現れます。最初の2個は、接続したThunderboltまたはUSBドライブからbootするようにするかどうかの設定です。3番目はWindowsでの設定のようです。とりあえず全部Disabledで良いようです。

また、Thunderboltを有効にすると、自動的に PCI Express Native Controlという項目がEnabledに設定されます。この項目のデフォルト設定はDisabledです。何か必要な設定だと思いますので、そのままEnabledにしておきました。

自作PC+macOSでTBの動作確認

以上でインストールと設定は終了です。Thunderbolt端子に、先に紹介したThunderbolt M.2 SSDを接続し、OpenCore 0.6.9でmacOS Big Sur 11.4を起動させました。その結果、リムーバブルドライブとして認識されました。ただしhot plugは効いていないようで、起動時にSSDが接続されている場合しか認識されず、一旦アンマウントすると再接続しても認識されません。

ディスクユーティリティ.appで情報を調べると以下のようでした。実機のMacと同様に、SSDはPCI-Express経由で接続されたドライブとして見えています。

装置ツリーバスの値を、Hackintool.appの情報と比較したところ、実際のMacと同様に、この場所にはPhison Electronics社のPS5013が接続されていました。ここまでは、SSDが実機とほとんど同じように見えているのですが、システム情報のThunderboltの項目を見ると、ハードウェアが見つかりませんとの表示です。

この先、頑張れば、hot plugも効くように調整できるのかもしれません。でも、大昔にThunderboltを試した時も、同様にhot plugが効かず、Thunderboltハードウェアの認識もされませんでした。なので、hot plugの制約を乗り越えるのは難しいかもしれません。Thunderboltはそこまで必要と感じていないので、今回はここまでとしました。

最後に性能のチェックです。Z590マシンにこのSSDを取り付けた状態で、AmorphousDiskMarkで測定しました。なんとM1 MacBook Airの結果とほとんど同じ結果が出ました。ということで、hot plugは効かないものの、実際のMacでのThunderbolt 3接続と同等の性能が出ていることを確認できました。

(おまけ)TB 4 AICをUSBで使う

ASRockのThunderbolt 4 AICにUSB Type-CのUSB 3.1メモリを挿してみたところ、マウントされて認識されました。ThunderboltとしてだけではなくUSBとしても使えるようです。USBとして使う場合は、hot plugが効きました。

まとめ

ASRock Z590 Extremeマザーボードに、ASRockのThunderbolt 4 AICを追加して動作を確認しました。ソフトウェア環境はOpenCore 0.6.9とBig Sur 11.4です。Thunderbolt 3 SSDを接続したところ、hot plugは効かないものの実機のMacと同じ転送速度が達成されていることを確認しました。

BIG SUR 11.4にアップデートする (Navi 21対応)

Tue, 25 May 2021 15:40:28 +0900

macOS Big Sur 11.4が配布されたので、11.3.1からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.9で起動していて、kext類は最新です。AMD Radeonの最新GPUに対応したようです。

一般的更新内容

前回の11.3.1アップデートとは違い、今回はバージョン番号の差異が大きいアップデートです。「ソフトウェア・アップデート」画面の説明によると、Podcastのサブスクリプションとチャンネル追加がされたようです。また重要なバグ修正も含まれているようです。個人的には、プレビューのバグに対応してくれたのが嬉しいです。

AMD Navi 21に対応

またAMD 6800, 6800XT, 6900XTに対応したようです。このことはベータ版の時から話題になっていて、フォーラムでも動作を報告していただいていました。Apple Developerの11.4 Release Notesページにも以下のように書かれています。

You can now use graphics cards based on the AMD Navi RDNA2 architecture (6800, 6800XT and 6900XT). (73709953)

これを確認するために、11.3.1と11.4のグラフィックス関連kextを比較しました。

/System/Library/Extensions

には、AMDRadeonで始まるkextが多数あるのですが、その一部が、Big Sur 11.3.1ではバージョンが4.4.17だったものが、11.4では4.5.14になり、更新されています。その中から、

/System/Library/Extensions/AMDRadeonX6000.kext/Contents/Info.plist

の内容を比較しました。すると、Big Sur 11.3.1では、

AMDNavi10GraphicsAccelerator
AMDNavi12GraphicsAccelerator
AMDNavi14GraphicsAccelerator

というキーが用意されているのに対して、Big Sur 11.4では、

AMDNavi10GraphicsAccelerator
AMDNavi12GraphicsAccelerator
AMDNavi14GraphicsAccelerator
AMDNavi21GraphicsAccelerator

が用意されていて、Navi 21が追加されていました。Navi 21はRadeon RX 6800 / 6800XT / 6900XTに使われているGPUの名前だそうです。Apple Developerのアナウンスもそれに従った内容です。ちなみにRadeon RX 6700はNavi 22だそうなので、6700はmacOSの正式サポート対象ではないようです。

アップデート作業

システム環境設定の「ソフトウェア・アップデート」から「今すぐインストール」ボタンを押してアップデートしました。この後、3.06GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.4が起動しました。特に気づく変更点はありません。ビルドは20F71になってました。

OPENCORE 0.6.8から0.6.9に更新

Wed, 05 May 2021 13:19:01 +0900

OpenCoreの0.6.9が公開されたので0.6.8からアップデートしました。config.plistの変更点はほとんどありませんでした。UEFI/AppleInput/CustomDelaysがstring型からbool型に変更されたのが注意点です。

0.6.9をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.6.9とmacOS 11.3.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS XI HERO + 9900K + Radeon RX 580 + macOS Big Sur 11.3.1
ASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.3.1

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

config.plistで設定する項目の変更点は以下のようでした。

UEFI/AppleInputのCustomDelaysという項目があります。0.6.8ではstring型でAutoを設定してたのですが、0.6.9ではbool型になってました。string型なのは不自然だったとのことです。UEFI/AppleInputではKeyInitialDelayとKeySubsequentDelayを設定するのですが、CustomDelaysがfalseの場合はこれを無視してデフォルト値にしてくれるとのことです。Sample.plistの設定でもfalseなので、falseに設定しておきました。
UEFI/QuirksにEnableVectorAccelerationという項目が追加されていました。SHA-512とSHA-384ハッシングアルゴリズムでAVXベクトルアクセラレーションを有効にするらしいです。デフォルトはfalseだけどsample.plistではtrueでした。性能が上がりそうな説明だったのでtrueにしてみました。
UEFI/QuirksにForgeUefiSupportという項目が追加されていました。UEFI 1.xファームウェアで、UEFI 2.xのサポートを部分的に可能にするという設定らしいです。forgeは確立するとか偽造するという意味なので、UEFI 2.xのふりをするという機能のようです。MacPro5,1でNVIDIA GOPオプションROMを使う場合などに有効とのことです。いずれも該当しないので、デフォルトのままfalseにしておきました。
UEFI/QuirksにReloadOptionRomsという項目が追加されていました。ForgeUefiSupportでUEFI 2.xファームウェアを有効にした後で、NVIDIA GOPオプションROMをリロードするような場合に使うとのことです。ForgeUefiSupportを使わないなら不要のようなので、デフォルトのままfalseにしておきました。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.8から0.6.9に移行できました。

BIG SUR 11.3.1にアップデートする

Tue, 04 May 2021 14:00:06 +0900

macOS Big Sur 11.3.1が配布されたので、11.3からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.8で起動していて、kext類は最新です。OpenCore 0.6.9が公開されていますが、古いバージョンでも対応できました。

前回の11.3アップデートとは違い、今回はバージョン番号の差異が小さいアップデートです。名前も「セキュリティアップデート」です。具体的なアップデート内容は不明ですが、「macOS Big Sur 11.3.1を適用すると、重要なセキュリティアップデートが提供されます。このアップデートをすべてのユーザに推奨します。」と案内されています。11.3の公開から1週間しか経たないタイミングでのアップデートなので、緊急度の高い内容だったのかもしれません。追記：Appleサポートの情報によると、悪意のあるページでWebKit（webページのレンダリングエンジン）が不具合を起こさないよう対応したそうです。

システム環境設定の「ソフトウェア・アップデート」から「今すぐインストール」ボタンを押してアップデートしました。この後、2.4GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.3.1が起動しました。特に気づく変更点はありません。ビルドは20E241になってました。

AirTagを使う

Fri, 30 Apr 2021 16:38:01 +0900

AirTagを試してみました。iPhoneで登録して「探す.app」からAirTagの場所を知ることができます。Z390で作った自作macOSマシンでも、同様に「探す.app」でタグを探すことができました。ただ、UWBデバイスに対応したiPhoneならば、タグの位置と方向を頼りにタグの場所まで案内してもらえるのですが、Macではできません。電池容量の確認、検出できた場合の通知、紛失モードへの設定は可能です。

AirTag

AirTagが来ました。こんな感じに梱包されてます。

ボタン電池の接点を絶縁しているプラスチックフィルムを、矢印の方向に引き抜くと動作開始します。すぐにiPhoneに通知が来ますので、ペアリングして名前をつけておきます。

名前は自由に付けられますが、あらかじめ用意された名前もあります。用意されている名前は、カメラ、ジャケット、バックパック、ハンドバッグ、ヘッドフォン、鍵、財布、傘、自転車、手荷物です。AirTagで探すアイテムとして想定されているもののリストになっていると思いました。

iPhoneで探す

iPhoneで「探す.app」を立ち上げて、画面下の「持ち物を探す」ボタンを押します。iPhoneを探す機能と同じように、地図上にAirTagの位置が表示されます。AirTagがある場所に近づいて「探す」ボタンを押すと、AirTagの方向と距離を表示してくれます。これはUWBに対応したiPhoneだけの機能のようです。

Macで探す

Macでも「探す.app」を起動して試しました。Z390マザーボードの自作マシンで、macOS 11.3、OpenCore 0.6.8の構成です。「探す.app」に新しく用意された「持ち物を探す」タブを押すと、登録したAirTagの場所を知ることができます。（スクリーンショットは加工してあります）

ただ、MacはUWBデバイスに対応していないので、タグの方向と距離を知ることはできません。AirTagはSiriからも問い合わせできるそうなので、MacのSiriで試したところ、iPhoneなどを使ってくださいと言われました。

HomePodのSiriにお願いしたら、タグのスピーカーから音を鳴らしてくれました。

BIG SUR 11.3にアップデートする

Tue, 27 Apr 2021 20:54:36 +0900

macOS Big Sur 11.3が配布されたので、11.2.3からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.8で起動していて、kext類は最新です。

前回の11.2.3アップデートとは違い、今回は小数点以下第1位の大きめのアップデートです。機能も増えている様子で、「探す.app」がAirTagに対応したようです。また「このMacについて」メニューで保証内容が表示されるようになったとのことです。他にも多数の変更・改良点があるようです。

システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。

この後、5.71GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.3が起動しました。ビルドは20E232になってました。

探す.appがAirTagに対応したとのことでしたが、「持ち物を探す」タブは11.2.3から変化はありませんでした。AirTagを登録した段階で、新しい機能が有効になるのかもしれません。

「このMacについて」の「サービス」タブは変化してました。以前はリンクがあるだけだったのですが、状況が表示されます。存在しないシリアル番号を割り当ててあるためか、「推定有効期限切れ」という状態のようです。

Z590マザーボードのマシンにも、無効なシリアル番号を割り当ててあるのですが、表示が少し違っていました。設定したシリアル番号の製造週からまだ1年未満なので、1年保証が有効だという表示なのかと思います。

ASRock Z590 ExtremeのUSBを設定する

Sun, 25 Apr 2021 18:12:47 +0900

ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを動かしています。今回はmacOSのUSB個数制限に合わせてUSBポートの設定を行います。以下で調査した結果はASRock Z590 ExtremeのUSB構成ですが、姉妹製品のZ590 Steel Legendでもおそらく同じなのではと思います。

macOSのUSB個数制限

今までにも何度かご紹介していますが、macOSにはUSBコントローラごとにUSBポートの数が15個までという制限があります。ポートの識別に1バイトしか割り当てられていないのです。実際には0を除いて1から15までの数値でポートを識別しているようです。大抵のマザーボードには15個を超えるポートがありますが、何も対処しないとUSB2.0のポートから順番に15個だけのポートが有効になります。後回しになるUSB3.0のポートがほとんど使えない状態になります。この問題を解決するには、以下のような対処法があります。

USBInjectAll.kextを使い、15個の制限を無視するパッチを当てる。OpenCoreの場合、config.plistで、Kernel/Quirks/XhciPortLimitをtrueにする。
USBInjectAll.kextを使い、使用しないポートをブートオプションのuia_excludeで指定する。
USBInjectAll.kextを使い、使用するポートをSSDTで指定する。
使用するポートを列挙したkextを自作する。hackintool.appなどにkextを作るツールが用意されている。

このうち4番目が一番スマートですので、今回もこの手法で設定します。hackintool.appでkextを作る方法はこちらでも説明してありますのでご覧ください。

15個制限のためのUSBPorts.kextをHackintoolで作る

個数制限を一時的に無効にする

まずは使用したいポートを特定するために、一旦、全部のポートが見えるように、個数制限撤廃パッチを当てます。上で述べた選択肢の1番の手法です。まずは500シリーズチップセットに対応したUSBInjectAll.kextを以下から入手します。

https://gitee.com/softxing/OS-X-USB-Inject-All/releases/v0.7.7

次に、config.plistで、Kernel/Quirks/XhciPortLimitをtrueにします。この結果、全てのポートが見えるようになります。hackintool.appで調べると以下のようになります。14個のHS (USB2.0) と9個のSS (USB3.x) が見えていることがわかります。USRという項目は無視して良いです。

15個制限を無視するパッチをこのまま使い続ければ楽かもしれません。でもLocation IDの項目を見ると、0x14F00000の次の行で0x14000000に戻ってしまっていて、重複していることがわかります。区別のための変数が1バイトしかないためのようです。これが何らかの不具合を引き起こす可能性はあると思いますので、15個以内に制限した方が良いでしょう。

USBポートを特定する

使用するポートを選択する作業の前に、実際のUSBポートがどの名前 (HS01からSS09までの名前）に対応しているかを調べます。15個制限を外すパッチを当てた状態で、hackintool.appを見ながら、USBポートにデバイスを挿して確認します。

何も挿さない状態でも、上記の図のようにHS09, HS14, SS09に反応があります。このうちASM107xというのはAsmedia社のUSBハブ制御チップのことです。マザーボード上に搭載されているようです。BRCM20702 Hubというのは、こちら

ASRock Z590 Extremeに無線モジュールを取り付ける

で取り付けた無線モジュールBCM94360NGのBluetooth部分です。これはM.2 key Eソケットに取り付けてあるのですが、key EにはUSB 2.0のポートが来ていて、それが見えています。

hackintool.appを動かしたまま、バックパネルとマザーボード上のポートを1個ずつ使っていくと、割り当てがわかります。USB 2.0を調べるためには、無線キーボードのドングルを使いました。USB 3.0を調べるためには、3.1対応のUSBメモリを使いました。USBメモリは、挿すとマウントされるので、取り外す前にアンマウントする手間がかかりちょっと面倒です。USBメモリの代わりに、USB 3.0対応のUSBハブを使えば、もっと効率が上がったかもしれません。

マザーボード上のポートを調べるためには、内部コネクタを通常のコネクタに変換するアダプタを使いました。画像にAliExpressへのリンクを貼っておきます。お手軽な値段なので、一通り持っていると何かと便利だと思います。

調査結果

ASRock Z590 ExtremeのUSBポートを調べた結果を以下に示します。

HS01 マザーボード上の2.0ヘッダピン（縁側） USB_3_4
HS02 マザーボード上の2.0ヘッダピン（縁側） USB_3_4
HS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
HS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
HS05 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
HS06 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
HS07 バックパネルのType-A、PS/2上の2個のうち下 (2.0 USB_2)
HS08 バックパネルのType-A、PS/2上の2個のうち上 (2.0 USB_1)
HS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)
HS10 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
HS11 マザーボード上の2.0ヘッダピン（内側） USB_5_6
HS12 マザーボード上の2.0ヘッダピン（内側） USB_5_6
HS13 （不明）
HS14 M.2 key Eソケット (Bluetoothで使用)
SS01 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
SS02 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
SS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
SS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
SS05 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
SS06 （不明）
SS07 （不明）
SS08 （不明）
SS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)

またマザーボード上のUSBピンは、それぞれ以下の名前になります。

マザーボード上のUSB2.0ピンはチップセット直結なのに対して、USB3.xピンはUSBハブ経由なのが面白いところです。Gen2x2のコネクタは、裏表で、別のSSポートに割り当てられているかと思ったのですが、同じでした。

15個に制限する

以上のように全部で19個のポートがあります。15個に制限するには、4個を諦める必要があります。バックパネルは便利なので、全部活かしたいところです。性能重視ならば、マザーボード上のUSB2.0ヘッダ端子を無効にするのが良いと思います。無駄に贅沢に使われている気がしました。これで4個除外できるので全部で15個になります。

HS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
HS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
HS05 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
HS06 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
HS07 バックパネルのType-A、PS/2上の2個のうち下 (2.0 USB_2)
HS08 バックパネルのType-A、PS/2上の2個のうち上 (2.0 USB_1)
HS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)
HS10 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
HS14 M.2 key Eソケット (Bluetoothで使用)
SS01 バックパネルのType-A、2.5GbE下の2個のうち下 (3.2 Gen1 USB3_2)
SS02 バックパネルのType-A、2.5GbE下の2個のうち上 (3.2 Gen1 USB3_1)
SS03 バックパネルのType-C USB3.2 Gen2 USB31_TC_1
SS04 バックパネルのType-A、1GbEの下 USB3.2 Gen2 USB31_TA_1
SS05 マザーボード上の 3.2 Gen2x2 (USB31_TC_2)
SS09 マザーボード搭載ASM107xハブ (USB3_3_4 と USB3_5_6)

hackintool.appのUSB画面で、必要なポートだけを選択して、ファイル書き出しします。するとデスクトップ上にUSBPorts.kextが出来上がります。これを使えばUSBInjectAll.kextはもう不要です。USBPorts.kextをEFIに入れて、config.plistで15個制限を復活させて、起動し、hackintool.appで確認すると以下のようになりました。Commentに説明を書いておくと、後々便利かと思います。

この後、ウィンドウ下のExportボタンを押します。箱から矢印が外に向かっているアイコンの部分がExportボタンです。するとこの設定から、以下の5個のファイルをデスクトップに作ってくれます。

SSDT-EC-USBX.aml
SSDT-EC-USBX.dsl
SSDT-UIAC.aml
SSDT-UIAC.dsl
USBPorts.kext

amlとdslの拡張子のファイルはSSDTファイルです。冒頭で述べた「USBInjectAll.kextを使い、使用するポートをSSDTで指定する」方法で使用するファイルです。以前のガイドで作っていたSSDT-UIACは、ここではSSDT-EC-USBXとSSDT-UIACの2つに分割されています。統合すれば内容は同じものでした。なので、SSDT関係のファイルはUSBInjectAll.kextと一緒に使うものであると思います。

一方、ここで作られるUSBPorts.kextは、Info.plistだけを持ったインジェクタkextという種類のkextファイル（実際にはディレクトリ）です。ターミナルからディレクトリを辿る、もしくはファインダーからパッケージを開くと、

USBPorts.kext/Contents/Info.plist

というテキストファイルが見えます。この中に、上で設定した内容が、plist書式のテキストで書かれています。このkextだけを使用すれば、15個のUSBポートを正しく設定することができます。

ここで作成したUSBPorts.kextをここに置いておきます。ご利用ください。機種名がiMac20,1になっていますので、20,2を使っている人はkextの中のInfo.plistを編集して書き直してください。

今回の設定では、マザーボード上のUSB2.0を全部無効にしました。しかし、無線モジュールを、M.2ソケットではなく、PCIeスロットに挿す場合、USB接続が必要なので、マザーボード上のUSB2.0を1個有効にする必要があります。その場合は、M.2 key EソケットのHS14を除外することになると思います。

まとめ

ASRockのZ590 ExtremeのUSBポートの構成を調べてmacOSの15個制限に対応しました。ここで調べたポート名対応は、構成が似ているZ590 Steel Legendでも同じなのではと思います。また他のASRockマザーボードもこれと似た構成かと思われます。これでZ590マザーボードの設定は一通り完成しました。Z590で作るhackintoshはとても安定しているので、第10世代CPUと組み合わせてmacOSマシンを作るのに適しているかと思います。もしもこの先、iMacが第11世代に対応してくれた場合も、CPU交換で追いつけます。

OPENCORE 0.6.7から0.6.8に更新

Fri, 09 Apr 2021 00:06:33 +0900

OpenCoreの0.6.8が公開されたので、出遅れましたが0.6.7からアップデートしました。config.plistの変更点はほとんどありませんでした。ただ0.6.6の時のようにOpenCanopyが動かなくなってしまいました。EFIのOC/Resourcesの中身を、こちらにあるFont, Image, Labelフォルダの中身に差し替えたところ、OpenCanopyも動くようになりました。

0.6.8をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。これを見ると、今回はOpenCanopy関係の更新項目が多いですね。Rocket Lake と Tiger Lake のCPU IDも追加されたようです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.6.8とmacOS 11.2.3で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。

ASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

変更点は以下のようでした。

Booter/QuirksにForceBooterSignatureが追加されていました。というようなことが書いてありましたので、デフォルトのfalseにしておきました。
UEFI/AppleInputという項目ができていました。AppleEventの詳細な設定が可能になったとのことです。Sample.plistの設定が推奨とのことなので、そのまま設定しておきました。
UEFI/ProtocolOverridesにAppleEventというのが追加されていました。AppleEventプロトコルをビルトインバージョンと入れ替えるかどうかの項目とのことです。VMやレガシーMacの設定でFileVault 2を使う場合に有効かもしれない、というようなことが書いてありましたので、関係ないと考えて、デフォルトのfalseにしておきました。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.7から0.6.8に移行できました。

OpenCanopy関係のファイルを更新する

0.6.7の時のようにnvramのバージョン情報が更新されない問題はありませんでした。しかし0.6.6の時のようにOpenCanopyが動かなくなりました。そこでコメントで教えていただいて、以下から、Resources/Image, Font, Labelを取り寄せて交換したら動くようになりました。

GitHub - acidanthera/OcBinaryData

ASRock Z590マザーボード搭載ALC1220で音を出す (その1)

Mon, 29 Mar 2021 19:57:47 +0900

（こちらは古い情報です。最新のAppleALC.kextを使うことで、ここで行った手順は不要になりました。こちらをご覧ください。2021/4/10）

ASRock Z590 Extremeに搭載されたサウンドチップRealtek ALC1220から音が出るようにしました。Z490のマザーボードを最初に使った時と同様に、FakePCIID.kextを使いIDを偽装します。近い将来、Z490の時と同様に、AppleALC.kextとOpenCoreがZ590チップセットに対応すれば、このような工夫なしで動くようになるのではと期待しています。

Z590マザーボードのサウンド

前の記事で、ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを起動させました。

ASRock Z590マザーボードでmacOSを起動する

この結果、有線と無線のネットワークが動いています。USBは未調整ですがキーボード、Bluetooth関係は動いてます。でもマザーボードに搭載されたサウンドチップであるRealtek ALC1220から音が出ていませんでした。今回は、このサウンドチップを動かします。

Realtek ALC1220は、300シリーズチップセットから搭載されているサウンドチップです。AppleALC.kextで長らくサポートされているので、互換性は高いと思っていました。でもZ590マザーボードでは、AppleALC.kextを入れるだけでは動きませんでした。

一方、一部のZ590マザーボードでは、新しいサウンドチップのRealtek ALC4080 が搭載されています。新しいので互換性が心配でしたが、実はALC4080はUSB接続で動いていて、USBオーディオとして機能するのでドライバの心配がいらないという報告がいくつか上がっています。オンボードサウンドのことだけを考えたら、ALC1220よりも、新しいALC4080が搭載されたマザボの方が面倒がなくて良いかもしれません。

PCIIDを偽装する

まずは、ALC1220がサポートするlayout-idをいくつか試してみましたが、音は出ませんでした。ALC1220の場合、使用できるlayout-idは、1, 2, 3, 5, 7, 11, 13, 15, 16, 21, 27, 28, 29, 30, 34だそうです。layout-idは多少違っていても大抵は音が出るので、全く動かない場合は、layout-idの問題ではないと思われます。

他の方法を検索しましたが、結局、以前、Z490マザーボードが出始めた時に使った方法が有効でした。サウンドチップのPCIIDを偽装する方法です。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

この方法に従って、以下のkext、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を追加し、config.plistのDevicePropertiesに以下を追加しました。PciRoot(0x0)/Pci(0x1F,0x3)はALC1220のデバイスパスです。これのdevice-idをA348に、layout-idを1にする設定です。

Z590マザーボードに搭載されたALC1220には、ベンダー：デバイスIDとして、8086:F0C8が割り当てられています。このIDが、現在のバージョンのOpenCore/AppleALCには登録されていないようで、Hackintool.appで調べると、Device Nameが???という表示になります。

そこで、上記の内容をconfig.plistに加えることで、このIDが8086:A348になります。このIDはCannon LakeのALC1220のdevice-idと同じ値なので、下記のようにCannon Lakeの名前が表示されるようになります。

以上の作業を行うことで、無事、オンボードサウンドが出るようになりました。

まとめ

Z590マザーボードのオンボードサウンドチップであるRealtek ALC1220から音が出るように設定しました。以前のZ490の時もそうでしたが、OpenCore/AppleALCがZ590搭載のALC 1220に対応してくれれば、この作業は不要になると期待しています。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

次の作業はUSBの15個制限の調整です。ぼちぼち対処していきます。

ASRock Z590マザーボードでmacOSを起動する

Sat, 27 Mar 2021 20:56:14 +0900

ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを起動させました。今まで10900KはZ490で動かしていたのですが、なんとZ490のEFIのままでZ590でもログイン画面まで到達しました。課題はありますが一応の動作をしたのでご報告します。

（更新：有線LANがどちらも動くようになりました 2021/3/29)

Z590マザーボード

第10世代CPUの10900Kを、今までASUSのZ490 Micro ATXマザーボードで動かしていました。

ASUS ROG STRIX Z490-G, 10900K

計画変更でこれを通常ATXのマザーボードにしたかったのですが、今更Z490を買うのもつまらないので、いっそZ590のマザーボードにすることにしました。Z590は、今月末に発売される第11世代CPU用のチップセットですが、現行の第10世代CPUも動きます。第10世代＋Z590でmacOSが動くという報告もいくつかあります。

間もなく発売される第11世代CPUは、アーキテクチャやiGPUなどが変更されるので、しばらくはmacOSが動かないと考えられてます。でも将来、iMacに第11世代が搭載されることになれば試してみたいと思います。

それでZ590マザーボードを物色しました。

減少するPCIeスロット

macOSマシンを自作するメリットの一つは、本物のMacに足りない拡張性を補うことだと思ってます。なのでマザボ選びには、いつもPCIeスロットの数を考慮して、スロット数が多いものを選んでいました。

でも、マザーボードに搭載されるPCIeスロットの数がだんだん減っているように思います。せっかく自作するなら良い部品を使いたいと思ってもいるのですが、特に上位モデルのマザーボードでスロットが減っている傾向があります。スロットのあった場所をM.2 SSDが占拠しているようです。Windowsで使う人たちもPCIeの拡張性をあまり重視しなくなっているのでしょうか？

（左がROG STRIX Z490-F, 右がZ590-F）

例えば、hackintoshするのに人気のあったASUSのROG STRIX F GAMINGを見てみます。ASUS ROG STRIX Z490-F GAMINGには6本あったPCIeが、同Z590-F GAMINGでは3本に減ってしまいました。Z590-Fの3本のPCIeスロットのうち、2本はCPU直結を分割しているので、両方とも使うとGPUへのレーン数が16から8に減ってしまいます。使いたくないところです。とすると、GPU性能に影響を与えないPCIeスロットは1本だけになります。Z490-FではGPUに影響を与えないスロットが4本あったので、4分の1に激減です。ASUSはPCIeスロット数が他社に比べて多い方だったのですが、残念です。

一方で、GIGABYTEとMSIは、以前からPCIeスロットが少なめでした。あっても、CPU直結を分割するタイプが多めでした。

そんなところで気づいたのはASRockのミドルレンジ製品でした。ASRockも、歯車が動くことで話題のZ590 Taichiは4スロットで、うち2本はGPU用レーンを分割するタイプです。GPUの性能に影響を与えずに拡張できるスロットは2本です。他社の上位モデルよりは1本多いですが、少ないです。ところがTaichiの下位モデルのZ590 Extreme, Z590 Steel Legend, Z590 Pro4, Z590 Phantom Gaming 4になると、GPU用のレーン数を分割しないタイプのスロットが4本もあります。今まで4大マザボメーカで、ASRockを使ったことがなかったのですが、今回は大いに検討することにしました。

ASRock Z590 Extreme

それで今回選んだのは、ASRock Z590 Extremeです。色々な点で魅力でした。

PCIeスロットが多い

PCIeスロットは5本あります。GPUスロットに割り当てられた16レーンを分割するタイプのスロットはありませんので、どれを使ってもGPU性能に影響は与えません。

見た目が良い

ヒートシンクや基板の模様が斜めにカットされていたり、斜めの溝や斜線が多用されたマザーボードのデザインに飽きていました。GIGABYTEのZ590 VISION DやZ590I VISION Dなどは、斜線の要素がなくて、スクエアで端正だと思います。ATXサイズのZ590 VISION Dはスロット数が少ないのですが、元々スロットがGPU用しかないZ590I VISION Dには、興味があります。

VISION Dほどカッコ良くはありませんが、Z590 Extremeも、斜線要素が抑えられていて、スクエアな印象です。黒と青の配色も、レトロフューチャーなコンピュータのイメージで良い感じです。

互換性の高い有線LAN

2.5GbEのチップがRealtek RTL8125Bです。こちらで紹介したように、RTL8125用のkextが用意されているので、LucyRTL8125Ethernet.kextで動きます。他社のマザーボードだと、Intel I225-Vが搭載されていることが多いです。この場合は、FakePCIIDなどを駆使して動かす必要がありました。専用のkextの方が安心です。

ASRockのZ590 ExtremeとSteel Legendは仕様がほとんど同じなのですが、唯一の違いが、Extremeには1GbEのチップも搭載されていることです。これがIntel I219Vなので、IntelMausi.kextで動きます。IntelMausiEthernet.kextは動きませんでした。Z590マザボのI219Vのベンダー：デバイスIDが8086:15FAなのですが、Contents/Info.plistを見ると、IntelMausi.kextにはこのIDが設定されていますが、IntelMausiEthernet.kextにはありません。それが原因で動かないようです。IntelMausi.kextの方が頻繁に更新されているので、今後もこちらを使った方が良いと思いました。

無線用key Eソケットとアンテナ穴がある

WiFiなしのモデルですが、無線モジュール用のソケットとアンテナ穴があります。

ASRockマザボの無線LAN/Bluetooth用のM.2 key Eソケットは、CNViに加えて、従来型のPCIe + USB接続が可能なタイプです。こちらの記事で紹介したように、最近の多くのマザボはCNViのみの対応になっていて、macOSと互換性のあるWiFi/Bluetoothモジュールを取り付けることができません。ASUS, GIGABYTE, MSIのM.2 key Eソケットは、CNVi専用の場合が多いです。

ところが、ASRockの製品は、スペック表に以下のように書いてあるように、従来型の無線モジュールにも対応しています。これでmacOSにOOBで対応するBroadcomのBCM94360NGが使えます。

1 x M.2 ソケット (Key E), タイプ 2230 WiFi/BT PCIe WiFi モジュールと Intel® CNVi (統合 WiFi/BT) に対応

バックパネルにアンテナ穴が空いているのもポイントです。現在の国内のラインナップではWiFi付きのExtremeはありませんが（Steel LegendにはWiFi付きと無しがあります）、WiFi非搭載モデルにもアンテナ穴がちゃんと空いてます。バックパネルを統一してコストダウンするのが目的だとは思いますが、あとから無線モジュールを取り付ける場合には、とても助かります。

サウンドチップの互換性が高い

サウンドチップがRealtek ALC1220です。AppleALC.kextでサポートされているチップなので、互換性が高いはずです。実はまだ動かせてませんが、なんとかなると思ってます。ASRockは上位モデルのTaichiにもALC1220を使っているので、安心かと思います。他社のZ590モデルには、新しいチップのRealtek ALC4080が使われている場合が多いです。このチップにはAppleALC.kextが未対応なので音が出ない可能性が高いと考えました。ただ、TonymacX86の情報によるとGIGABYTE Z590 VISION Gでは、ALC4080がUSBオーディオ接続になっていて、何の問題もなく音が出たという報告があります。なのでサウンドチップの互換性の心配は不要なのかもしれません。

以上のように、ASRockのZ590シリーズは、全般的に安定したこなれた規格と部品が使われている傾向があって、hackintoshするには安心感のある構成かと思いました。

組み立てる

CPU、メモリー、M.2 SSD、CPUクーラー、グラフィックスカード類は、今まで使っていたASUS micro-ATXマザーボードのROG STRIX Z490-G GAMINGから取り外して移植しました。WiFi/BluetoothもBroadcomのBCM94360NGを取り付けました。これはOOBで動く唯一のM.2無線モジュールです。M.2 WiFiと書かれたM.2 key Eソケットにぴったり収まります。この後、アンテナを仮配線しました。

M.2 SSDには、Z490で起動させていた時のEFIがそのまま入っています。OpenCore 0.6.7です。メインのパーティションには、Big Sur 11.2.3がインストールされてます。グラフィックスカードはAMD Radeon 5700XTです。

構成をまとめると、以下になります。

ASRock Z590 Extreme
10900K
M.2 SSD
BCM94360NG
Radeon 5700XT
OpenCore 0.6.7 + Big Sur 11.2.3

BIOS設定

BIOS設定は、工場出荷時設定でも問題ありませんでした。でも通例にしたがって以下のように設定しました。

IGPU Multi-Monitor: Enabled
Primary Graphics Adapter: PCIE1
XHCI Hand-off: Enabled
Above 4G Decoding: Enabled
Onboard HD Audio: Enabled

とりあえず起動

Z490マザーボードで動かしていたM.2 SSDのままで、とりあえず起動を試みました。なんと、ログイン画面まで問題なく到達しました。CPUは同じなのでそれほど問題ないとは思ってましたが、あっけなかったです。でも、キーボード、トラックパッドが効かず、ログインできません。USB機器が動いていないようです。

USBメモリで起動

移植に先立って、M.2 SSDのEFI部分を、USBメモリのEFI部分にコピーしてありました。ログイン画面に至ったところでUSB機器が動かなくなっている様子でしたが、OpenCoreなどが動く段階では、USBメモリーは動いています。なので、このUSBメモリから起動することが可能でした。

そこで、この起動用USBメモリを別のマシンで編集して、多少の調整をしました。まずは、IntelMausiEthernet.kextとLucyRTL8125Ethernet.kextを導入します。この記述をconfig.plistにも追加しました。次にconfig.plistからZ490関係の内容、つまりはDevicePropertiesの有線LANとサウンドに関する部分を削除しました。これでかなりZ590対応したと思うのですが、USB周りは手を加えてないので、やはりログイン画面でUSBが効かなくなったままです。

画面共有する

USB機器が動かない様子なので、画面共有で先を進めようと考えました。ルーターのDHCPのログを見ると、新しいマザーボードに1個だけアドレスが割り当てられていました。そこで、このアドレスに対して画面共有を行ったところ、無事ログイン画面が現れました。ここで、ログインして全ての操作が可能になりました。システム環境設定からネットワークを調べたところ、動いていたのはWiFiのBCM94360NGでした。

当初、有線LANは、Intel I219VもRealtek RTL8125Bも、どちらも動いていませんでした。Intelが動かなかったのは、前述のように、IntelMausiEthernet.kextを使っていたのが原因でした。IntelMausi.kextに変えて動くようになりました。RTL8125Bが動かなかったのは、前のZ490マザーボードの設定で、ジャンボフレームが使用したかったので、2.5Gハブ接続するよう固定してしまっていたからでした。それを1Gハブに接続したので動かないようでした。自動モードにしたら動くようになりました。

USBInjectAll.kextを入れる

画面共有から接続して、Hackintool.appで調べたところ、USBポートが一つも見えてませんでした。元々Hackintool.appで作ったZ490マザボ用USBのためのkextを入れていたので、これが動いていないと考えました。そこで、USBInjectAll.kextを入れてみたのですが、やはりUSBは見えませんでした。ちょっと探したところ、Z590チップセットに対応したUSBInjectAll.kextがあるようでした。

https://gitee.com/softxing/OS-X-USB-Inject-All

Hackintool.appで調べると、Z490のXHCI Host ControllerのVender:Device IDは8086:A36Dですが、Z590の場合8086:43EDでした。これらの違いを反映したUSBInjectAll.kextが必要なようでした。上記のサイトからソースコード一式をダウンロードして、makeコマンドでkextを作ることができました。コンパイルしたZ590用のUSBInjectAll.kextをここに置いておきます。

これでUSBが見えるようになりました。上はHackintool.appで調べた様子です。USB Receiverというのはlogitechのトラックパッド付きキーボードです。これでログインもmacOSの操作もできるようになりました。BRCM20702 Hubは、BCM94360NGのBluetooth部分です。これでBluetoothが見えて、純正Magic Trackpad/Keyboardも接続できるようになりました。ASM107xというのは、マザボ搭載のUSBハブかなと思います。今の状態だとUSB 3.1が使えないので、今後は使うべき15個のUSBポートを選択して、kextを作っていきたいと思います。

EFI構成

以上の作業で、EFIの構成は以下のようになりました。ACPIフォルダが、

SSDT-RHUB.aml
SSDT-PLUG.aml
SSDT-EC-USBX.aml
SSDT-AWAC.aml

Kextsフォルダが

WhateverGreen.kext
VirtualSMC.kext
USBInjectAll.kext
SMCSuperIO.kext
SMCProcessor.kext
LucyRTL8125Ethernet.kext
Lilu.kext
IntelMausi.kext
AppleALC.kext

です。config.plistはDortaniaさんのComet Lakeガイドとほぼ同じです。機種IDはiMac20,1です。

追記：使用中のEFIをこちらに置いておきます。config.plistのシリアル番号などはみなさんで設定してください。Radeon RX 6xxx以外の方は、ブートオプションのagdpmod=pikeraを削除してください。OpenCore 0.7.6です。USBは設定済みで、オンボードオーディオも動きます。

まとめ

ASRockのZ590 Extremeに10900Kを搭載してmacOSを動かしました。現状では

USBは動いているけど15個制限対策は未設定
Intel (1GbE)、Realtek (2.5GbE)のどちらの有線LANも動く
マザボに取り付けたBCM94360NGでWiFi/BTが動く
オンボードオーディオが動かない

状態です。少しずつ対策していきたいと思います。

追記：オンボードオーディオが動きました：

ASRock Z590マザーボード搭載ALC1220で音を出す (その1)

BIG SUR 11.2.3にアップデートする

Fri, 12 Mar 2021 20:27:47 +0900

macOS Big Sur 11.2.3が配布されたので、11.2.2からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.7で起動していて、kext類は最新です。

前回の11.2.2アップデートに引き続き、またマイナーなアップデートのようで、WebページのレンダリングをするWebKitの脆弱性を修正するもののようです。機能が拡充するわけではなさそうですが、バージョン番号を上げてまで配布するということは深刻な不具合なのかもしれないです。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。

この後、2.44GBのアップデートファイルがダウンロードされ、複数回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.2.3が起動してました。

特に気づく変更点はありません。ビルドは20D91になってました。

OPENCORE 0.6.6から0.6.7に更新

Fri, 12 Mar 2021 07:43:01 +0900

OpenCoreの0.6.7が公開されてかなり経ってしまいましたが、ようやく0.6.6からアップデートしました。config.plistの変更点はほとんどありませんでした。

0.6.7をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.6.7とmacOS 11.2.3で動作確認している手元のマシンは以下です。

ASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

変更点は以下のようでした。

UEFI/AudioにResetTrafficClassが追加されていました。レガシーHDAにおいてTCSEL (トラフィッククラスセレクトレジスター) をTC0にリセットすると書いてあります。AppleALCを使う場合はそちらで設定したほうが良い、というようなことが書いてありましたので、デフォルトのfalseにしておきました。
UEFI/Input/KeyMergeThresholdは機能しなくなったので削除されたようです。削除しておきました。
UEFI/Output/GopPassThroughという項目が追加されていました。UGAプロトコル上にGOP (グラフィックアウトプットプロトコル) を提供するとの説明です。ProvideConsoleGopの設定と関係があるようです。macOSのブートローダが必要とするグラフィックスと、マザーボードの内蔵グラフィックスの乖離を埋める一連の機能のようです。最近のiGPU付きCPUを使いながら、MacPro5,1の設定をする場合に関係するパラメータのようです。iMacで設定しているので不要かと思い、デフォルトのfalseにしておきました。
UEFI/Quirks/ActivateHpetSupportという項目が追加されていました。ICH6などを使った古いマザーボード設定でHPET (高精度イベントタイマー) を有効にできない場合に、それを可能にするオプションだそうです。ICH6は2003年頃のサウスブリッジチップです。古いマザボへの対応のようなので不要かと思い、デフォルトのfalseにしておきました。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.6から0.6.7に移行できました。

バージョンが更新されない

0.6.7にアップデートしたものの、Kext UpdaterやHackintoolでチェックすると0.6.6のままだと言われて、0.6.7のダウンロードを推奨されました。これはnvramの更新ができていないためのようです。ターミナルから、

nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version

とタイプして、OpenCoreのバージョンを示す変数を取得すると、以下のように表示されてしまいました。

4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version	REL-066-2021-02-02

066の設定のままでした。この問題は、OpenCoreの起動画面でnvramをリセットする項目を選べば解決します。もしくは、ターミナルから

sudo nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version=""

とタイプして、この変数を削除してしまうことでも解決します。nvramコマンドでは、何も無い値を設定することで変数を削除できます。なので、この後にnvramコマンドで確認すると、

nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version
nvram: Error getting variable - '4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version': (iokit/common) data was not found

というように表示されて、この変数が消えていることがわかります。正しいopencore-version値は、次の再起動時に自動的に更新されます。再起動後にnvramコマンドを入力すれば、

4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version	REL-067-2021-03-01

と表示されるようになりました。Kext UpdaterやHackintoolもOpenCoreの新しいバージョンを認識するようになりました。

BIG SUR 11.2.2にアップデートする

Fri, 26 Feb 2021 23:25:35 +0900

macOS Big Sur 11.2.2が配布されたので、11.2.1からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.6で起動していて、kext類は最新です。

前回の11.2.1アップデートに引き続き、またマイナーなアップデートのようです。サードパーティUSB-Cハブやドックを接続したときに、2019年以降のMacBook Proと2020年以降のMacBook Airが破損することを防ぐ効果があるようです。デスクトップのhackintoshにはとことん無関係な気もしましたが、最新macOSではありますので、アップデートしました。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。

この後、2.17GBのアップデートファイルがダウンロードされ、2回、再起動しました。1回目のアップデートのOpenCore画面では、いつもの起動ボリュームにしているMacintosh HDというボリュームが2個見えてましたが、デフォルトで選択されているままでokでした。インストール後、何の問題もなくBig Sur 11.2.2が起動しました。

特に気づく変更点はありません。ビルドは20D80になってました。

ThinkPad T460sの更新 (OpenCore 0.6.6 + macOS 11.2.1)

Thu, 11 Feb 2021 16:32:01 +0900

中古で入手して色々設定したThinkPad T460sですが、すっかり放置してました。久々に起動したらOpenCoreは0.5.7でmacOSは10.15.6でした。今回は、OpenCoreを0.6.6に、macOSを11.2.1にアップデートします。

T460sのGitHubから更新

あまり使う予定はないのですが、手持ちのマシンは最新にしておきたいという気持ちがあるので、アップデートを考えました。以前の記事、

ThinkPad T460s (6300U) にOpenCoreでCatalinaを導入

では、T460s用にチューンナップしたEFI一式を配布してくれているサイト

GitHub - simprecicchiani/ThinkPad-T460s-macOS-OpenCore: Bootloader configurat…

のEFIデータをそのまま使ってmacOSをインストールしました。今回は自前で頑張るかなと思ったのですが、上記のサイトを再び見てみたところ、活発に更新されていました。タイミングが良いことに、これを書いている13時間前にOC 0.6.6用のEFI一式が更新されていました。ここまで面倒を見てくださるのなら、活用しない手はないと思い、早速EFI一式をダウンロードしました。

基本的にはこれで問題なく0.6.6にアップデートできたのですが、以下の点で多少手をかけました。

起動音を止める

ジャーンという起動音を止めました。最近のMacで復活した起動音ですが、本物Macでも止めてます。今回、何度か起動を試みることになり、その度に大きな音で起動するので、止めました。

SecureBootModel

Catalinaが起動している状態から、githubで公開されているEFIに差し替えると、起動しなくなりました。

OCB: Apple Secure Boot prohibits this boot entry, enforcing!

というエラーが出ます。検索したところSecureBootModelをDisabledにすれば良いとわかりました。今まではDefaultに設定してありました。OpenCoreのマニュアルにもこのことは書いてありました。そこでこれをDisabledにしたところ、起動するようになりました。

ただその後、後述のようにBig Surをクリーンインストールしたところ、SecureBootModelをDefaultにしても問題なく起動するようになりました。なので、現在は元のデフォルト値である、Defaultに戻しました。

矢印アイコンを追加

EFIを入れ替えたところOpenCanopyが動かなくなってました。例の矢印アイコンが足りないのが原因でした。なのでそれを追加しました。ただ、現在githubで配布されている一式には矢印アイコンも入っているようです。

Big Surをクリーンインストール

これでOpenCore 0.6.6 + Catalinaで動くようになりました。そこで、次のステップとして、Big Surにアップデートしようとしました。すると、Big Surのインストーラが途中で止まってしまいました。なので、Big Surインストール用のUSBメモリを作り、これにEFI一式を入れました。そしてUSBメモリから起動して、内蔵SSDを消去してのクリーンインストールを行いました。その結果、Big Surがインストールできました。SecureBootModelもDefaultで動くようになりました。ファイルシステムに何らかの不整合があったのかもしれません。その後、11.2.1にアップデートしました。

Big Sur 11.2.1にアップデートする

Wed, 10 Feb 2021 17:42:55 +0900

macOS Big Sur 11.2.1が配布されたので、11.2からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.6で起動していて、kext類は最新です。

いつものマイナーアップデートのさらにマイナーなアップデートのようです。古いMacBook Proで充電できない問題が修正されているようです。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。

この後、アップデートファイルがダウンロードされ、3回、再起動しました。1回目のアップデートのOpenCore画面では、いつもの起動ボリュームにしているMacintosh HDというボリュームが2個見えてましたが、デフォルトで選択されているままでokでした。インストール後、何の問題もなくBig Sur 11.2.1が起動しました。

特に気づく変更点はありません。ビルドは20D74になってました。

OpenCore 0.6.5から0.6.6に更新

Wed, 03 Feb 2021 22:35:18 +0900

OpenCoreの0.6.6が公開されたので0.6.5からアップデートしました。config.plistの変更点はほとんどありませんでした。~~なぜかOpenCanopyが動かなくなってしまいましたが、機能としては問題ありません。~~/EFI/OC/Resources/ImageにLeft/Right.icnsファイルを追加するとOpenCanopyも動きました。

0.6.6をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

OpenCore 0.6.6とmacOS 11.2で動作確認している手元のマシンは以下です。

ASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580
ASUS Z490G + 10900K + Radeon RX 5700XT

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。でも今回は、Bootstrap.efiがフォルダーごと消えてました。以下はありません。

EFI/OC/Bootstrap/Bootstrap.efi

それ以外は前回と同様です。なので入れ替えるべきファイルは以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。

config.plistを更新する

現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、比較しながら新しいconfig.plistを作りました。

変更点は以下のようでした。

Kernel/QuirksにSetApfsTrimTimeoutが追加されていました。SSDコントローラが行うtrimの作業のためのタイムアウトをmsで指定するようです。sample.plistでは-1になってました（多分何も設定しないという意味？）ので、そのまま-1にしておきました。
Misc/BootにLauncherOptionとLauncherPathが追加されていました。Windowsを使うときのNVRAM設定に関連するものかと思いました。sample.plistではそれぞれDisabledとDefaultになってました。今までも問題なかったので、sample.plistのままにしておきました。
Misc/SecurityからBootProtectが消えてました。0.6.5ではBootstrapという値が入れてありました。LauncherOption/LauncherPathがこの代わりになったのかと思われます。
PlatformInfoにUseRawUuidEncodingが追加されていました。SMBIOS UUIDをbig endianにするか、little endianにするかの設定のようです。sample.plistではfalseになってました。今更変えるとUUIDが変わってしまうのかと思ったので、そのままfalseにしておきました。
UEFI/QuirksにDisableSecurityPolicyが追加されていました。platform security policyを無効にするという意味らしいです。UEFI Secure Bootを有効にしているならこれは使うなと書いてありました。sample.plistではfalseになってましたので、そのままfalseにしておきました。

いずれも大きな変更ではなさそうです。

OpenCanopyが動かない

以上の設定で、0.6.5から0.6.6に移行できました。問題なく起動して動いているのですが、なぜかOpenCanopyが動かなくなりました。ピッカー画面が、シンプルなテキストメニューに戻ってしまいました。OpenCanopy周りが色々変わったというような記述がありましたので、何か設定を変更しなければならなかったのだと思います。見た目の問題なので、とりあえずこれで使って行きます。

OpenCanopyを動かす（追記）

コメントで教えていただいて調べたところ、/EFI/OC/Resources/Imageに

Left.icns/Right.icns
ModernLeft.icns/ModernRight.icns
OldLeft.icns/OldRight.icns

というファイルが必要になっているようです。それぞれ、Misc -> Boot -> PickerVariantを、Default、Modern、Oldに設定した時に使われるアイコンファイルです。これらをこちらから入手して追加したところ、OpenCanopyが動くようになりました。

Big Sur 11.2にアップデートする

Tue, 02 Feb 2021 22:02:22 +0900

macOS Big Sur 11.2が配布されたので、11.1からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.5で起動していて、kext類は最新です。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐアップデート」ボタンを押しました。

この後、アップデートファイルがダウンロードされ、2回、再起動しました。インストール後、何の問題もなくBig Sur 11.2が起動しました。

特に気づく変更点はありません。ビルドは20D64になってました。

2.5G BASE-T PCIe Ethernetカードを使う

Wed, 06 Jan 2021 18:12:52 +0900

RealtekのRTL8125チップを搭載した2.5Gbps Ethernet PCIeカードを、macOSが動く自作PCで使ってみました。ドライバにはLucyRTL8125Ethernet.kextを使います。2.5Gbpsの速度が出ていることを確認しました。安価なので1G超えLANを試すのに良いと思います。

RTL8125搭載2.5G PCIeカード

AmazonやAliExpressのページでRTL8125を検索すると、2.5G BASE-TのEthernet拡張カード製品が多数見つかります。RTL8125はRealtekの2.5GbE用のチップです。現在主流のZ490マザーボードの多くにはIntelのI225-Vが採用されていますが、一部の製品にはRTL8125が搭載されています。例えばGIGABYTEのマザーボードにはRTL8125が搭載されています。GIGABYTE関係者の方が「I225-VよりRTL8125の方が安定しているから採用している」と、YouTubeで宣伝してました。それくらいメジャーなチップなので、2.5Gbps PCIe拡張カードの多くがRTL8125を搭載しているようです。Amazonでの価格は2,000円〜4,000円くらいです。10Gbpsのカードに比べると安価なので、導入しやすいです。

価格以外にも、2.5Gbpsカードのメリットがあります。2.5Gbpsカードは10Gbpsに比べて速度が遅いので、カードエッジコネクタはPCIe x 1です。それに対して、高速な10GbpsカードではPCIe x 4になります。今回使用したマザーボード（ASUSのROG Maximus XI Hero Z390マザーボード）には3本のPCIe x 16スロットと3本のPCIe x 1スロットがあります。3本のPCIe x 16スロットのうち、CPU直結スロットはグラフィックスに、チップセット経由のスロットはSATAカード (PCIe x 4)で使ってしまっていました。CPU直結のPCIe x 16のスロットがもう一本空いてはいますが、それを使うとグラフィックスカードを挿しているPCIe x 16と帯域を分け合うことになり、どちらもx 8になってしまいます。LANのためにグラフィックスの性能が下がるのは避けたいと思いました。そうすると空いているスロットはPCIe x 1だけです。x 1スロットで使える2.5 Gカードは、現状に即した選択と思いました。

今回注目したのは、2.5Gカードとして最安値で販売されている以下の製品です。AmazonとAliExpressのどちらにも、同じ写真の製品が複数販売されています。扱っている店が違うだけで、おそらく全て同じ製品だと思われます。

Amazonだと送料込みで2300円程度ですが、AliExpressでは1900円程度です。差額は大差ないのですが、Amazonの納期は3週間以上で、AliExpressの方は1週間未満でした。価格と納期は時期により変化すると思いますが、現状ではAliExpressの方が優秀な様子でした。以下ではAliExpressから届いたカードを使ってみた報告です。

LucyRTL8125Ethernet.kext

実際のMacでは採用されていないチップなので、macOSにはドライバーが含まれていません。でもmacOSで動くRTL8125用のドライバー（kextファイル）が以下で公開されています。Kext Updater.appにも登録されているので、そちらからもダウンロード可能です。

GitHub - Mieze/LucyRTL8125Ethernet: macOS driver for Realtek RTL8125

ちなみにLucyというのは作者のMiezeさんの猫の名前のようです。

LucyRTL8125Ethernet.kextをOpenCoreのKextsフォルダに入れ、ProperTreeのスナップショット機能を使ってconfig.plistに登録したところ、このRTL8125カードは問題なく動作しました。ただしWake On Lanは効きませんでした。カードの販売サイトではWOL対応していると書いてあるので、おそらくはmacOSとの相性問題ではないかと思います。

システム情報で確認

動作したところでmacOSの「システム情報」を開くと、RTL8125Aを搭載したPCIeカードだと確認できました。ちなみに、もう一つ見えているEthernetカードは、ASUS Z390マザーボード上に実装された1G Base-TのI219です。

速度測定

速度が出ていることを確認するためにiperf3コマンドで速度測定しました。このカードを取り付けたASUS Z390マシンを、ASUS Z490マシンに接続しました。どちらのマシンも、OpenCore 0.6.4 + Big Sur 11.1の構成です。Z490には、Intel I225-Vが搭載されています。なので接続は以下のようになります。

Z390 (Big Sur) + RTL8125A <-----> Intel I225-V + Z490 (Big Sur)

また、今回の測定ではジャンボフレームをonに設定しました。なので前回の測定より性能が出ました。ジャンボフレームを有効にするには、システム環境設定の、ネットワーク、詳細、ハードウエアで構成を手動にします。手動で2.5Gに設定すると、相手は2.5G Base-T限定になり、1Gハブなどには接続できなくなります。

iPerf3のクライアント側の結果を以下に示します。2.5Gbpsの速度が達成されている様子がわかります。

% iperf3 -c 192.168.x.x
Connecting to host 192.168.x.x, port 5201
[ 5] local 192.168.x.x port 49642 connected to 192.168.x.x port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 295 MBytes 2.48 Gbits/sec
[ 5] 1.00-2.00 sec 297 MBytes 2.49 Gbits/sec
[ 5] 2.00-3.00 sec 295 MBytes 2.47 Gbits/sec
[ 5] 3.00-4.00 sec 295 MBytes 2.47 Gbits/sec
[ 5] 4.00-5.00 sec 294 MBytes 2.47 Gbits/sec
[ 5] 5.00-6.00 sec 296 MBytes 2.48 Gbits/sec
[ 5] 6.00-7.00 sec 295 MBytes 2.48 Gbits/sec
[ 5] 7.00-8.00 sec 293 MBytes 2.46 Gbits/sec
[ 5] 8.00-9.00 sec 294 MBytes 2.46 Gbits/sec
[ 5] 9.00-10.00 sec 295 MBytes 2.47 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 2.88 GBytes 2.47 Gbits/sec sender
[ 5] 0.00-10.00 sec 2.88 GBytes 2.47 Gbits/sec receiver

iperf Done.

OpenCore 0.6.4から0.6.5に更新

Tue, 05 Jan 2021 18:01:54 +0900

OpenCoreの0.6.5が公開されたので0.6.4からアップデートしました。config.plistの変更点はほとんどありませんでした。何も変更しなくても問題なく起動すると思われます。

0.6.5をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

.efiファイルを差し替える

更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。前回と同様、入れ替えるべきファイルは以下でした。

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Bootstrap/Bootstrap.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。ACPIに関しては、今回からパッケージにamlとdslのファイル一式が含まれるようになりました。こちらの表から必要なdslファイルを確認してコピーすれば良いので、ESP作成が楽になります。念のために、ACPIフォルダの中身を配布ファイルに差し替えておきました。

config.plistを更新する

変更点は以下のようでした。

Misc/BootにPickerVariantが追加されていました。OpenCoreの選択画面で表示するアイコンセットを指定する項目のようです。Auto, Default, Old, Modern,その他の値が選べるそうです。OldとModernは、アイコンのファイル名がOld, Modernで始まるアイコンを選んでくれるそうです。AutoはDefaultBackgroundカラーに合わせて自動的に選択、DefaultはOld, Modernの文字がないものを選んでくれます。これでアイコンを簡単に切り替えられるようです。EFIごとに設定を変えておけば、どのドライブから起動したかを判断しやすくなると思います。sample.plistではAutoになってましたので、そのままAutoにしておきました。
UEFI/AudioにSetupDelayが追加されていました。ミリ秒単位のディレイを指定します。ボリュームなどの設定をした後、ディレイが必要な場合に指定します。通常は0.5秒で良いようです。多分起動音を正しく出すための設定だと思われます。sample.plistでは0になってました。そのまま0にしておきました。
UEFI/QuirksからDeduplicateBootOrderの設定が消えてました。以前のconfig.plistではtrueにしていた項目です。BootOrderで重複しているエントリーを取り除いてくれる機能だったようです。不要になったので削除されたとのことです。config.plistからもサンプル通り削除しておきました。

いずれも大きな変更ではなさそうです。以上の設定で、0.6.4から0.6.5に移行できました。

HomePod miniをASUS Z390マザーボードのType-Cに接続する

Fri, 01 Jan 2021 23:07:01 +0900

HomePod miniにはType-Cのケーブルがついています。これをASUSマザーボードバックパネルのType-Cコネクタに接続したら、macOSのファインダーにHomePodが現れました。この状態でHomePodのメンテナンスが可能です。

HomePodをhackintoshに接続する

HomePodにはUSB Type-Cのケーブルが1本だけついてます。本体からは抜けないので、生えている感じです。電力供給専用だとばかり思っていたので、これを自作PCに接続したらどうなるかとは考えてませんでした。

ところで、最近HomePod miniの調子が時々良く無いです。iPhoneと連携する機能をリクエストすると

「接続で問題が起きています。iPhoneがこのHomePodと同じWi-Fiに接続されていることを確認してください。」

という返答をすることがあります。検索すると、そういう状況で困っている人は多くて、

Wi-Fiを2.4GHzにしたり、
HomePodを初期化したり、
iPhoneを再起動する

と一時的に治るようでした。その対処法の一つに、HomePodをMacにUSB接続して初期化する方法が書いてありました。

「そんなことが可能ならばhackintoshでも試したい」ということで、ASUS Z390 + 9900K + OpenCore 0.6.4 + Big Sur 11.1で構成した自作マシンのバックパネルType-Cコネクタに、HomePodを直結してみました。するとなんと、ファインダーにHomePodが現れました。

HomePodの上面LEDはオレンジ色で点滅します。これはオーディオ用パワーアンプを駆動するためには電力が不足していることを表しているらしいです。マザーボードのType-CコネクタにはUSB 3.1 PDの機能はなく、5V 2Aが出ているだけなので電力不足です。でも「HomePodを復元…」する機能は使えるようです。

システム情報で調べると、480Mbps接続しているようです。USB 2.0のHigh-Speedモードですので、おそらくは変換器経由でUSB 2.0/3.0 Type-Aコネクタに接続しても、同様にファインダーに現れるのではと思います。

HomePodを復元する

ファインダーウィンドウで唯一できることは、「HomePodを復元…」することのようです。試さないわけにはいかないです。これをクリックすると、こんなダイアログが出ます。

何かのメディアもデータを入れたつもりもないので、ためらうことなく、復元ボタンを押しました。

すると2.29GBの「HomePodソフトウェア・アップデート」のダウンロードが始まりました。おそらくはHomePodのOSがアップルのサーバからダウンロードされ、これによりHomePodがアップデートされるのだと思われます。

この後「ファームウェアが復元」されて、工場出荷時状態になりました。

おまけ：Apple TVも接続してみた

5年前のApple TV (2015) にもType-Cのポートがあったので、同じくZ390マザーボードに接続してみました。こちらもファインダーに現れて、復元とアップデートができました。ソフトウェアアップデートのサイズは2.85GBでした。USBの接続は、やはり480MbpsのHigh-Speedモードです。ちなみにApple TVにメンテナンス用USBポートがついているのは2015モデルまでで、2017モデルからは廃止されてます。またType-Cなのは2015モデルだけです。

まとめ

Big Surが動いている自作PCに、HomePod miniをUSB接続したら、ファインダー上に現れて、ソフトウェアのアップデートなどが可能でした。Type-Cケーブルは単なる電源用だと思っていたので意外でした。

Wake On LAN (WOL) を使ってmacOSの電源を入れる

Sat, 26 Dec 2020 20:49:22 +0900

電源を落としたmacOSコンピュータをWake On LAN (Ethernet経由) で起動するよう設定しました。本物のMacだと電源を落とした状態からのWOLは不可能らしいです。条件はありますが、hackintoshならば電源off状態からのWOLが可能です。

Wake On LAN機能

Wake On LAN (WOL) は、スリープ状態や電源offのコンピュータを、ネットワークからのコマンドで起動させる機能です。WOL設定されたマシンのMACアドレス宛に、マジックパケットというデータを送りつけることで、目覚めさせます。WinowsをインストールしたHP EliteDesk 800 G2 DMでは、電源offからのWOLが動きました。でも実機のMacでは、検索した限りでは、電源offからのWOLは不可能なようです。

WOLの設定は、どのコンピュータでも結構、困難を伴うようです。色々な要素が絡んでいて、不安定なことも多いようです。Hackintosh関係のサイトでも、WOLの設定が時々話題になりますが、大変そうでした。WOLが必要な状況にあるなら、常時電源onにしたサーバとして動かしておけば良いのにと思ってましたので、あまり興味はありませんでした。でも、手を出してみたら、停止していたコンピュータをネットワークから起動させる事が純粋に面白かったです。何かの目的のためにWOLするのではなく、人はWOLしたいからWOLしているのだと感じました。また、実機のMacでは出来ないことを達成するという要素も、hackintoshの醍醐味です。

WOLには以下のような要素が関係するようです。このうち一つでも不完全だとWOLしません。またOSやドライバーのバージョンが変わると動かないこともあるようです。前回紹介したWindowsの場合でも設定は面倒でした。

BIOSでの設定：電源off時にもEthernetポートに通電するよう設定。
OSでの設定：macOSではシステム環境設定でWOLを有効にする。
ネットワークドライバ：WOLをサポートしたkextを使う。
NIC：WOLをサポートしたLANアダプタが必要。

後半の2条件：ネットワークドライバとNICに関しては、相性の問題かもしれないです。同じチップを使ったアダプターカードでも、WOLが効く・効かないものがあるようです。またこれ以外にも、OSのバージョンが変わるなどの状況で、WOLが動かなくなったりします。WOLが動く条件が満たされると、電源がoffでもEthernetコネクタのLEDが点灯するようになります。Hubの接続モニターLEDも点灯します。LEDが点灯しない状態では、NICへの電源が遮断されているので、WOLは無理なようです。電源off状態のLEDを観察すれば、WOLできるかどうかがある程度判定できます。

ASUS Z390 + Big SurでWOL

今回設定したマシン構成は、ASUS ROG MAXIMUS XI HERO Z390 + OpenCore 0.6.4 + Big Sur 11.1です。WOLに使用したのは、このマザーボードに搭載されているIntel I219-VギガビットLANです。

BIOS設定

BIOSのAdvanced –> APM ConfigurationからPower On By PCI-EをEnabledに設定します。デフォルトはDisabledです。下の欄に、「オンボードLANコントローラやPCIeスロット上LANカードのwake-on-LAN機能を有効・無効にします」という説明が出てます。オンボードチップの場合も、PCIeスロット搭載カードの場合も、この項目でWOL設定できるようです。

macOSの設定

システム環境設定の省エネルギーで「ネットワークアクセスによるスリープ解除」にチェックを入れます。これはデフォルト設定です。実際のMacでは、この設定によりスリープからのWOLが可能になります。でも、電源offの場合はWOLしません。

WOL対応kextを使う

以上のBIOSとmacOSの設定を行っても、当初はWOLが効きませんでした。BIOSで設定した直後に、電源を落とすと、WOLが効きます。でも一度でもmacOSを起動すると、それ以降、WOLが効かなくなりました。macOSの動作で、WOLが無効化されているような振る舞いです。ということで、macOSではWOLできないと書きましたが、その記事のコメントで、まっくぷろさんから、WOL対応しているらしいIntelMausiEthernet.kextバージョンを教えていただきました。このkextを使うことで、安定してWOLが動作するようになりました。

GitHub - fischerscode/IntelMausiEthernet-WOL: OS X driver for Intel onboard LAN

WOLするアプリケーション

WOL状態で待機しているコンピュータは、そのMACアドレス宛にマジックパケットを送ると起動します。マジックパケットを送るには、先の記事でも紹介した簡単なPythonプログラムでokです。

#!/usr/bin/python
import socket
s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
s.sendto('\xFF'*6+'\x99\xAA\xBB\xCC\xDD\xEE'*16, ('192.168.xxx.255', 7))

最後の行が、目覚めさせたいコンピュータのNIC情報です。\x99\xAA\xBB\xCC\xDD\xEEの部分がMACアドレスで、192.168.xxx.255がIPアドレスです。IPアドレスの最後が255なので、ブロードキャストします。

Homebrewで導入できるコマンドのwakeonlanをコメントで教えてもらいました。これをインストールすると以下のようにMACアドレスを指定してWOLできました。wakeonlanの中身はperlのスクリプトのようです。

wakeonlan 99:AA:BB:CC:DD:EE

App Storeには、GUIで機種を登録したり、MACアドレスを自動検出できる有料アプリ・広告付きアプリが多数あります。でも、遠隔地からWOLすることを目的と考えたら、シンプルなPythonプログラムで十分かと思いました。また、WOLのためのiPhoneアプリも多数あります。RemoteBoot WOLは、無料でユーザも多いようです。Windows用やAndroid用にももちろん多数のアプリがありますし、Amazonのデバイス用にもあるようです。記事冒頭のアイコンをお借りしたアプリは、FireTVなどで動くようです。

まとめ

ASUS Z390マザーボード搭載のIntel I219-V経由で、Big Surが動くコンピュータのWOLを試みました。電源offの状態から電源を入れられました。このために、BIOSを設定し、WOLに対応したIntelMausiEthernet.kextを使いました。これで外出先から電源を入れることもできそうです。

10G BASE-T PCIe Ethernetカードを使う

Thu, 24 Dec 2020 18:38:17 +0900

10GbpsのPCIe Ethernetカードを使ってみました。iMac Pro (2017) で使われているAquantia AQC107というチップを搭載したカードです。ドライバーが元々のmacOSに含まれているのでkext不要で動きます。同じチップ搭載でも、簡単なパッチが必要な製品と、OOBで動く製品があるようです。

ASUSの10Gbps Ethernetカード

フォーラムで教えていただいたMorgonautさんのビデオで、ASUSの10 Gbps EthernetカードがCatalinaでOOB動作すると紹介されてました。

紹介されているのは、Aquantia AQC107という製品です。以下のように、送料込みで1.1万円くらいです。

このカードを、実はかなり前に買ったのですが、macOSで動かなくてお蔵入りになってました。「OOBで動くようになっていたのか」と思い、発掘して（なかなか見つかりませんでした）試してみました。結論から言うと、OOBでは動きませんでしたが、パッチを当てて動くようになりました。

Aquantiaチップ用パッチ（Big Sur版）

Aquantiaの10Gbps EthernetカードのためのBig Sur版のパッチが以下で紹介されていました。これを使いました。動かした環境はZ390 + 9900K + OpenCore 0.6.4 + Big Sur 11.1です。

AppleEthernetAquantiaAqtion.kextを以下のように書き換えれば良いようです。このkextは、

Kext: com.apple.driver.AppleEthernetAquantiaAqtion
Find: D4TAAgAA (16進数: 0f 84 c0 02 00 00 )
Replace: Zg8fRAAA (16進数: 66 0f 1f 44 00 00 )

このkextの実体は以下の場所にあります。

/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleEthernetAquantiaAqtion.kext

テキストエディタで作業するなら、OpenCoreのconfig.plistのKernel, Patchの項目に、次のdictを足せば良いです。

<dict>
 <key>Comment</key>
 <string>ASUS XG-C100C (Aquantia AQtion AQC-107)</string>
 <key>Count</key><integer>1</integer>
 <key>Enabled</key><true/>
 <key>Find</key>
 <data>YnVpbHQtaW4=</data>
 <key>Identifier</key>
 <string>com.apple.driver.AppleEthernetAquantiaAqtion</string>
 <key>Replace</key>
 <data>YmJiYmJiYmI=</data>
</dict>

PlistEDPlusで作業するなら、以下のようにします。

このように追記したconfig.plistを保存して再起動したところ、10G bps Ethernetカードが動きました。今のところ特に不具合はありません。

iperf3で動作試験

Morgonautさんのビデオではiperf3というツールで速度測定してました。これはLinuxなどで一般的な測定ツールのようで、Homebrewからbrew install iperf3コマンドでインストールできました。iperf3コマンドを2台のコンピュータで動かし、それぞれをサーバーとクライアントにして、通信速度を計測するツールです。

今回、ASUSの10Gbpsカードを取り付けたのがZ390マザーボードです。測定の相方は、ASUS ROG STRIX Z490-GのマザーボードにmacOS Big Surをインストールしたコンピュータです。このマザーボードには2.5 GbpsのIntel I225-Vが搭載されています。1Gbps超えのハブを持っていないので、ASUSの10GbpsカードとZ490をEthernetケーブル（CAT 6Aで十分らしいです）で直結しました。

Z390 (Aquantia 10Gbps) <-----> (Intel 2.5Gbps) Z490

それぞれのマシンに手作業で適当なアドレスを割り当てておきます。まずは、Z490マシンでiperf3をサーバーモードで動かしました。

iperf3 -s

一方、10Gbpsカードが載ったZ390マシンでは、サーバアドレスを指定して、クライアントモードでiperf3を動かしました。

iperf3 -c 192.168.x.x

その結果、両方に同じ測定結果が表示されます。クライアント側の表示を以下に示します。

% iperf3 -c 192.168.x.x
Connecting to host 192.168.x.x, port 5201
[ 5] local 192.168.x.x port 49648 connected to 192.168.x.x port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 244 MBytes 2.05 Gbits/sec
[ 5] 1.00-2.00 sec 246 MBytes 2.06 Gbits/sec
[ 5] 2.00-3.00 sec 247 MBytes 2.07 Gbits/sec
[ 5] 3.00-4.00 sec 244 MBytes 2.05 Gbits/sec
[ 5] 4.00-5.00 sec 247 MBytes 2.07 Gbits/sec
[ 5] 5.00-6.00 sec 245 MBytes 2.05 Gbits/sec
[ 5] 6.00-7.00 sec 247 MBytes 2.07 Gbits/sec
[ 5] 7.00-8.00 sec 245 MBytes 2.05 Gbits/sec
[ 5] 8.00-9.00 sec 250 MBytes 2.10 Gbits/sec
[ 5] 9.00-10.00 sec 249 MBytes 2.09 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 2.41 GBytes 2.07 Gbits/sec sender
[ 5] 0.00-10.00 sec 2.41 GBytes 2.07 Gbits/sec receiver
iperf Done.

結果は2.07Gbpsと、2G以上の速度が出ていました。片方が2.5 Gbpsなので、それ以上は出ません。ネットの転送には色々オーバーヘッドがあるので、これくらい出ていれば十分だと思いました。また、今まで相方がいなかったので不明だったのですが、Z490の2.5Gオンボード有線LANが性能通りの速度で動いていることも確認できました。

OOBの10Gbpsカード

同じAquantiaのチップ搭載カードでも、Sonnetの製品ならばOOBで動くようです。以下のAmazonの販売ページにも、macOS対応と書かれてます。ASUSのカードより3,000円ほど高価です。今回はたまたま手元にASUSのカードがあったのでそれを試しましたが、この価格差ならば、パッチが不要なSonnetカードの方が良いと思います。（コメントいただいた情報によると、SequoiaではこのカードもOOB動作しないようです。 2025/09/15）

Big Sur 11.1にアップデートする

Fri, 18 Dec 2020 23:49:55 +0900

macOS Big Sur 11.1が配布されたので、11.0.1からアップデートしました。アップデートしたのは、Z390マザーボードとZ490マザーボードのマシンです。どちらもOpenCore 0.6.4で起動していて、kext類は最新です。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐアップデート」ボタンを押しました。

この後、3.27GBのアップデートファイルがダウンロードされ、再起動します。最初の再起動では、どういうわけか同じ名前の起動ボリュームが見えていました。どちらかがアップデーターのボリューム（従来だとBoot macOS Install from …というような名前でした）で、どちらかが古いmacOSだと思われます。デフォルトで起動ドライブになっていた左側を選択すると、インストールが進みました。

この後、2回ほど再起動をします。2回目以降の再起動時には、起動ボリュームは1個だけに戻っていました。インストール後、何の問題もなくBig Sur 11.1が起動しました。

特に気づく変更点はありません。ビルドは20C69になってました。

M1 MacでHackintoshを作る

Sun, 13 Dec 2020 18:17:14 +0900

本物のMacが無い状態からhackintoshを作るのは困難です。また、macOSを無料で使わせていただいているお礼としても、本物のMacを1台は持っていても良いと思います。その1台がM1 Macでも大丈夫でしょうか？ということを確認するため、M1 MacBook Airでhackintosh起動・インストール用USBメモリーを作ってみます。

Macを買おう

Hackintoshを作るためにmacOS上での作業が必要です。この記事は「M1 Macをhackintoshにする」と言う内容ではなく、「hackintoshを作る作業にM1 Macを使用する」と言う内容です。Hackintoshを作るなら、Macを買っておこうという内容の記事を、以前書きました。

Macintoshを買おう

今なら省電力な割に高性能なM1 MacBook Air/Proがおすすめです。M1 Mac miniも良いですね。今までのMac下位モデルはインテルのiGPUを使っていましたが、性能は良くありませんでした。M1のiGPUはインテルより数倍性能が良いです。反面、miniのようなデスクトップモデルでも拡張性はほぼ無いです。そこで、拡張性を補い、インテルmacOS環境を手に入れるために、自作macOSマシンを作るのも良いと思います。でもM1マックでhackintoshは作れるのでしょうか。Rosetta 2があるので、ツール類も正しく動くとは思いますが、確認します。

Big Surをダウンロードする

一番の懸念は、インテル版Big Surが正規のApp Storeから入手可能かどうかです。そこで、M1マシンからApp Storeに行き、Big Surをダウンロードしました。

「入手」をクリックすると、「ソフトウェア・アップデート」が起動して、ダウンロードが始まります。12.18GBあるので、そこそこ時間がかかります。サイズは大きいので、インテルのコードも入っていそうです。

ダウンロードが終わると、アプリケーションフォルダにインストーラができています。

/Applications/Install macOS Big Sur.app

「情報」を見るとUniversalアプリケーションになっているようで安心しました。インテル環境でも大丈夫なようです。

macOSインストール用USBメモリ

次に、「Macで起動できて、MacにmacOSをインストールできるUSBメモリ」を作ります。まずはUSBメモリをHFS+でフォーマットします。USBメモリを接続し、M1 Macで「ディスクユーティリティ」を起動します。まずは「表示」から「すべてのデバイスを表示」を選んでおきます。（以下の2枚のスクリーンショットは以前のmacOSで撮ったものなので、見た目が違います）

この次に、USBメモリのデバイス名（一番上の階層の名前）を選択し、「消去」ボタンを押します。そこで現れるパネルから、方式として「GUIDパーティションマップ」を選びます。フォーマットには「MacOS拡張（ジャーナリング）」を選びます。

これ以外の選択をすると、後の作業でエラーが出たり、起動ドライブにならなかったりします。名前はなんでも良いです。ここではUSBにしておきました。次に、ターミナルを開いて、

/Applications/Install macOS Big Sur.app/Contents/Resources

に移動して、インストーラの中に移動して、createinstallmediaコマンドを使います。

% sudo ./createinstallmedia --volume /Volumes/USB/

しばらく時間がかかり、無事、macOSインストール用USBメモリが完成しました。これで本物のMacを起動すれば、macOSがインストールできるはずです。M1 Macが文鎮化する事案が話題になってますが、このUSBメモリーさえ持っていれば安心です。

diskutil listコマンドで、USBメモリの場所を調べて、diskutil mountコマンドでESPをマウントしておきます。以下はESPがdisk4s1の場合の例です。この結果、/Volumes/EFIの場所にマウントされるはずです。

% diskutil list 
% sudo diskutil mount disk4s1

ターゲットマシンを決める

今回は、Z390 + 9900K + RX580の構成へのインストールUSBを目指します。これに必要なkextは以下です。

AppleALC.kext
IntelMausiEthernet.kext
Lilu.kext
VirtualSMC.kext
WhateverGreen.kext

また、必要とされるSSDTは、こちらの表を見るとわかります。このマシン（Coffee Lake）に必要なSSDTは、

です。リンク先から、それぞれのコンパイル済みamlファイルを入手できます。

この構成なら、システムモデルはiMac19,1が良いと思います。マシン用のシリアル番号やUUIDなどを決めておきます。今回は、すでに動いているマシンの番号をそのまま利用します。AppleIDの関係で、シリアル番号はできる限り変更しない方が良いです。新しいマシンにインストールする場合は、正しいフォーマットのシリアル番号を新たに作ります。OpenCoreをダウンロードすると、その中のUtilitiesの中にmacserialというコマンドがありますので、これで生成します。–modelオプションでモデルを指定すればそれに合うシリアル番号とボードシリアル番号を生成してくれます。macserialもM1で動きました。

% ./macserial --model iMac19,1
C02ZTHYTJV3Q | C02950108CDLNV91M
C02YDVZSJV3Q | C02910403CDLNV9UE
C02YP6Z8JV3Q | C02919301GULNV9CB
C02DDCZDJV3Q | C02037104CDLNV98C

OC Gen XでESPを作る

先ほどマウントした/Volumes/EFI/の場所に、EFIフォルダを作っていきます。そこで、OC Gen Xツールを使います。M1版Big Surでも起動しました。

OC Gen-XでESPを作る

System TypeとしてCoffee Lakeを選び、上でリストアップしたkextを選びます。またSystem ModelをiMac19,1にして、決めておいたシリアル番号などを入力します。最後に「Generate EFI」ボタンを押すと、デスクトップにEFIフォルダができています。これをUSBメモリのEFIの中にドラッグ&ドロップでコピーします。

ESPを手直しする

OC Gen Xツールは大体のことはしてくれるのですが、足りない部分を補います。まずはSSDTが入っていません。先ほどダウンロードしたamlファイルをACPIフォルダの中に入れます。また、config.plistの中に、kextやamlファイルの記載がありません。そこで、ProperTreeの、OC Clean Snapshot機能を使い、ACPI, Drivers, Kexts, Toolsの内容をconfig.plistに反映させます。ProperTreeもM1版Big Surで問題なく動きました。

自作マシンで起動する

これで100% M1で作ったhackintoshインストール用USBメモリーが出来上がりました。自作Z390マシンで起動を試みたところ、無事起動しました。macOSのインストールに使えそうです。

文鎮化しても救える？

先に述べましたが、M1 Macが文鎮化する事案が話題になっています。ファームウェアのアップデートに失敗すると起動しなくなるらしいです。その対策の一つが、ほかのMacからApple Configurator 2を起動して、ファームウェアをアップデートする方法らしいです。自作macOSマシンで、M1 MacBook Airの文鎮化を救えるのかどうか、試してみました。とは言っても、本当に文鎮化しているわけではないので、様子を見た程度です。

自作マシン（Z390 + 9900K + RX-580 + OpenCore 0.6.4 + BigSur) とM1 MacBook AirをType-Cケーブルで接続します。Z390側は、マザーボードのバックパネルのType-Cコネクタを使いました。そしてApple Configurator 2を起動しました。Apple Configurator 2はApp Storeからダウンロードできます。

するとMacBook Airが認識されていました。

文鎮化しているわけではなく、元気に起動していますが、Z390マシンの方からは、これのファームウェアアップデートが可能なようです。「このアクションは取り消せません」とありますので、この先試していません。インテルベースの安定したHackintoshを持っていると、M1が文鎮化しても安心な気がします。

まとめ

M1Macでhackintoshが作れることを確認しました。このほか、Kext Updater.appやPlistEDPlus.appなどのツールも使えました。モバイルでは省電力なM1 MacBookを使い、デスクトップは拡張性のある装備満載な自作マシンを使うのが良いのではと思いました。

M1 MacBook Airの良いところ

Sat, 12 Dec 2020 01:08:40 +0900

普段使いのノートとして古いMacBook無印を使っていたところへ、M1 MacBook Airがやってきました。重いけど速くて使いやすくて気に入りました。使ってみて気づいたところを書き連ねます。

M1 Mac

M1搭載MacはMac mini, MacBook Air, MacBook Proと3機種出ました。ハードウエア更新がいつも後回しな印象のあるMac miniが、新CPU搭載ラインナップに加わっているのは嬉しかったです。ただ、こんなにスカスカなのに、一切拡張できないのは残念です。メモリーソケットとM.2ソケットをつけて、2.5インチSATAドライブを2台は搭載可能な感じです。

(出典：egpu.io)

それで注目なのはAirだと思いました。3機種とも同じCPU/GPUで、メモリとSSDの構成も同じです。一切拡張できない点も同じです。ならばM1の小型・省電力という特徴を生かした軽くてファンレスのAirが面白いと考えました。

キーボードが良い

Late 2019 MacBook Proからすでに改良されている点で、今更報告するほどのことではないかと思いますが・・・キーボードが良くなってました。MacBook無印のキーボードは、評判の悪いバタフライ型でした。薄いけど、沈み込みが少なく、ペチペチと安っぽい打鍵音がします。打ちにくさは慣れれば克服できるのですが、打鍵音がうるさいので、周囲に人が居る会議や公共の場で使いにくかったです。薄さを追求したMacBook無印には薄いバタフライ型が必要だったのかもしれないですが、厚いMacBook Proにも使われてました。評判が悪い上に、動作不良になることも多くて、2019年11月からのMacBookシリーズでは、元のシザー型のキーに戻りました。薄いキーを諦めた結果、MacBook無印は終了になってしまいました。

M1 MacBook Airも、改良されたキーを搭載しています。デスクトップ用のApple Magic Keyboardと同じキーになっているそうで、慣れ親しんだいつもの打鍵感覚を得られます。MacBook無印と比べると打鍵音がほとんどしないのがとてもありがたいです。ファンレスで動くM1チップならば、MacBook無印の筐体で薄型軽量なモデルを作って欲しかったと最初は考えていました。実際、無印に比べてAirはずっしりと重いのですが、このキーボードのためなら我慢しても良いと思えました。それくらいキーボードが良いです。

Touch IDが便利

これも目新しいことではないですが、Touch IDが便利でした。Windowsノートには指紋デバイスが、はるか昔から搭載されてました。MacBookシリーズにも2016年のTouch Barから搭載されてます。なので単に疎かっただけなのですが、使ってみたら便利でした。Apple Watchで認証するには、装着していないと使えません。指紋ならいつでも対応できます。デスクトップ向けのMagic KeyboardにもTouch IDをつけてくれたら良いのにと思いました。

CPUとGPUが速い

省電力で小型軽量マシン向けのCPUだと思われていたところが、ベンチマークのスコアが予想以上に高くて、評判になってます。ここでは、デスクトップの自作macOSマシンと、改めて比較しました。構成はASUS Z490-G + 10900K + RX-5700XT + OpenCore 0.6.4 + Big Surです。まずはGeekbench 5のCPUスコアの比較です。シングルコアはM1が優ってます。マルチコアの結果も、4+4物理コア対 10物理コア+10HTの対決にしては、M1は頑張っています。省電力物理コアは、インテルのHTによる仮想コアよりも仕事が出来る感じです。グラフィックスの性能は冷却もしっかり効いたdGPUに敵いませんが、IntelのiGPUに比べたら高性能です。


	M1 MacBook Air	自作 macOS
CPU	M1	10900K
GPU	M1	RX-5700XT
メモリ/SSD	8GB/256GB	32GB/250GB
CPU シングル	1,714	1,335
CPU マルチ	7,394	11,041
GPU OpenCL	16,701	66,296
GPU Metal	18,727	69,797

Cinebench R23も試しました。デフォルトでは10分間の試験をすることになってますが、時間がかかるので１回だけ走らせました。10分間テストを実施したらファンレスのMacBook Airはスコアが下がったかもしれません。アクティビティモニターによるCPU稼働率も一緒に示します。M1では、高性能コアも省電力コアもどちらもしっかり仕事をしている印象です。省電力コアが足を引っ張るような振る舞いは見られませんでした。

こちらは10900Kの様子です。

スコアは、以下のようです。GeekbenchのCPUマルチのスコアよりは差が開きました。でも、ローエンドMacに搭載された省電力CPUとしては、今までにない高性能です。


	M1 MacBook Air	自作 macOS
Cinebench R23	7,063	16,230

SSDの速度をAmorphousDiskMarkで測定しました。時間がかかるのでこれも最初の項目だけのテストです。M1 MacBook Airも自作PCもどちらも250GBなので、SSDの性能は同じようなものだと思います。後述するように、M1は接続がApple Fabricです。スコアは以下のようでした。

こちらはASUSマザーボード上のM.2ソケットに取り付けたWDの250GB SSDの速度です。M.2 SSDの方がWriteは遅かったですが、Readは同程度でした。接続方式の違いではなく、SSDの特性の違いと思われます。

iOSアプリが使える

M1チップのMacではiOSアプリが使えます。App Storeで検索するときに、「iPhone および iPad App」を選ぶとiOSのアプリが出てきます。これを見ると、iOSのアプリのかなりがM1 macOSで動作するようです。キャッシュレス決済アプリを入れておけば、スマホを忘れても、MacBookさえ持っていればコンビニで買い物ができます。画面上部のカメラも起動できるので、店頭QRコード支払いも可能なようです。このほかiPhoneで使っていたタイマーアプリ、Wi-Fi接続家電のリモコン、電卓などをダウンロードして使えました。

謎アーキテクチャの探索が楽しい

今回のMac新モデルで一番楽しい点は、Apple Siliconという新しいアーキテクチャを探索できるところです。謎なところをいくつか探ってみました。もし詳しい情報をご存知の方がいらしたら、教えていただければと思います。まずは、Z490マシンでmacOSのCPU名を調べるコマンドを打ち込むと、

% sysctl -n machdep.cpu.brand_string 
Intel(R) Core(TM) i9-10900K CPU @ 3.70GHz

のように、詳しい名前やクロック数が表示されていました。M1 MacBook Airでこのコマンドを打つと、こんな表示になります。

% sysctl -n machdep.cpu.brand_string
Apple processor

そっけなくて、詳細な仕様を謎のままにしておきたいという意図を感じます。

unameコマンドでは、OSの名前を表示できます。インテル版のBig Surで実行すると以下のような表示が出ます。

% uname -a
Darwin chimney.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64

X86 64のためのリリースだと書いてあります。M1 MacBook Airでこのコマンドを打つと、以下のように表示されました。

% uname -a
Darwin air2020.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:10 PDT 2020; root:xnu-7195.50.7~2/RELEASE_ARM64_T8101 arm64

ARM64アーキテクチャの、ARM64 T8101のためのリリースとのことです。T8101をネットで検索してみたら、iPhone 12シリーズに搭載されているApple A14 Bionic SoCの型番だそうです。M1チップは、A14に非常に近い仕様なのではと想像できます。

Z490マザーボードのM.2ソケットに取り付けたSSDをディスクユーティリティで見ると以下のようでした。名前の説明に「PCI-Express内蔵物理ディスク」となっていて、PCI-Express接続になってます。

M.2ソケットにはPCIeの配線がつながっていて、SSDはそれに接続しているので当然の表示です。一方、M1 MacBook AirのSSDを、同様にディスクユーティリティで調べてみます。すると、名前の説明が「Apple Fabric内蔵物理ディスク」になり、接続先がApple Fabricになってます。このSSDはPCI-Expressとは違った接続のようです。

「システム環境」のSSDの項目にもApple Fabricの記述があります。Appleのサイトの図によると、FabricとはCPU, GPU, メモリーなどが接続されている内部バスのようなものらしいです。ここにSSDが接続されているようです。PCIeは無くなってしまったのでしょうか？

HackintoolやIORegistryExplorerなどで調べると、一応はPCIeらしきものの一覧が出てきます。また、Display controllerとしてAMDのRadeon R7 370 / R9 270X/370XがPCIeの一覧に見えます。

でもどのDevice Pathも0番になっていて、怪しい感じです。Systemのタブを見ると、CPUは2.50GHzのVirtualAppleとなってます。

同様の情報は、MacCPUIDを動かしても得られました。やはりVirtualAppleという名前のCPUになってます。アーキテクチャはWestmereという太古のインテルCPUの設定です。おそらくは、Hackintoolに表示されている情報の、Intel Generationが???になっている部分を、Westmereと判断したのだと思います。

Hackintoolを動かす前にRosetta 2をインストールしてくださいというダイアログが出てました。なので、これらの情報は、Rosetta 2が提供しているフェイクな情報ではないかと思います。Intel版macOSアプリを動かすために、Apple SiliconアーキテクチャをIntelアーキテクチャに偽装しているとしたら、これはhackintoshに通じるテクニックだと思います。

まとめ

新しいM1 MacBook Airを使ってみました。今まで使っていたMacBook無印と比べると重量が重くなりましたが、動作は軽く、キーボード、Touch ID、iOSアプリが使えて便利です。Appleオリジナルの新しいCPUになったので、今までと違う内部情報が得られました。

OpenCore 0.6.3から0.6.4に更新

Wed, 09 Dec 2020 01:12:11 +0900

OpenCoreの0.6.4が公開されたので0.6.3からアップデートしました。config.plistの変更点は少ないですが、PlayChime項目がbool型からstring型に変更されてます。なので今までのconfig.plistではエラーが出るようです。

0.6.4をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

.efiファイルを差し替える

EFI/BOOT/BOOTX64.efi
EFI/OC/OpenCore.efi
EFI/OC/Bootstrap/Bootstrap.efi
EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi
EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。

config.plistを更新する

現在のconfig.plistをconfig_063.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、比較しながら新しいconfig.plistを作りました。

気付いた変更点は以下です。

Booter/Patchが追加されていました。Itemが1個有りますが、sample.plistではenabled=falseなので機能はしていないようです。
Booter/QuirksにAllowRelocationBlockが追加されてます。これもfalseなので影響はないようです。「relocation blockからmacOSを起動する」という指定らしいです。カーネルを読み込むメモリが足りないときに使えるようです。起動に問題なければfalseで良いようです。
Misc/SecurityにBlacklistAppleUpdateが追加されてsample.plistではtrueになってます。デフォルトはfalseです。Apple周辺ファームウェアのアップデートを試みないように設定します。Big Surで、NVRAMでこれを設定できない場合のために設けられました。Big Surならtrueでも良いと思いました。
Misc/SecurityのBootProtectがsample.plistではNoneになってます。以前のsample.plistではBootstrapでした。bootloader persistence を提供する機能らしいです。新しいサンプルに従ってNoneを試したところ、一応起動するのですがESPがマウントできない問題が発生しました。再起動ではokでした。なのでBootstrapに戻しました。
UEFI/Audio/PlayChimeがstring型のAutoになってます。今まではbool型のfalseにしてましたが、それではエラーが出るようです。string型のAuto, Enabled, Disabledから選びます。起動音を使ってないのでDisabledにしました。

いずれも大きな変更ではなさそうです。でも、PlayChimeのフォーマットが変更されたことには、対応が必要です。以上の設定で、0.6.3から0.6.4に移行できました。

OpenCore用のミニマムなテーマ

Tue, 08 Dec 2020 00:54:18 +0900

OpenCore用のミニマムな起動画面アイコンが公開されてます。作者の方がredditで紹介してました。これを使う前に、まずはOpenCanopyの設定をしておきます。

OpenCoreの選択画面をグラフィカルにする

次に、以下のGithubのサイトからダウンロードして、アイコンファイルをEFI/OC/Resources/Imageにコピーして、同じ名前のアイコンを差し替えます。また、config.plistのMisc -> Boot -> PickerAttributesを1にしておいてくださいとのことです。デフォルトは0ですが、1にするとカスタムアイコンを読む設定になります。

GitHub - tekteq/opencanopy-minimal-theme: Minimal theme for OpenCanopy/OpenCore

OpenCanopyのデフォルトアイコンは、実機と同じデザインなので、できる限り本物のMacを再現したいという目的には合ってます。以下がOpenCanopyのアイコンで、

以下が実機Macでのボリューム選択画面の表示です。HDDの反射具合や支柱の太さが微妙に違いますが、ほぼ同じです。

リアリティを志向したオリジナルアイコンとはかなり違って、tekteqさんのアイコンはおしゃれな感じです。さらに、OpenCoreの起動画面に引き続き、macOSが表示するブート画面にも同じ形とサイズのAppleアイコンが表示されるので、一連の流れが美しいです。どっちもありかなと思いました。

OC Gen-XでESPを作る

Mon, 07 Dec 2020 00:14:37 +0900

OpenCoreの設定を行うツールOC Gen-Xを使ってみました。Z390 + 9900Kで構成したマシンのために、このツールでEFIフォルダを作成しました。多少の手直しは必要ですが、そのまま起動するEFIフォルダが出来上がりました。

OC Gen-X

フォーラムで便利だったという話をお聞きして、試してみることにしました。夢日記にも紹介されてます。OpenCoreの設定を楽にするツールは、いくつかあるらしいですが、Dortaniaさんのガイドに、configuratorは使うな、手作業で設定せよ、と書いてあったので、避けてました。OC Gen-Xは、そのDortaniaさんのガイドに準拠したconfig.plistを生成するとの説明があるので、良いのかもしれないと思い、試してみることにしました。以下からダウンロードできます。

https://github.com/Pavo-IM/OC-Gen-X

現用マシンと同じ設定をする

今使っているASUS ROG MAXIMUS XI HERO + 9900Kの構成でインストールしたOpenCore 0.6.3 Big Surの組み合わせで使っている構成を目指して同じように設定を試みました。

OC Gen Xを起動して、タブを選んで項目を選択していきます。最初はプロセッサーです。Z390 + 9900KなのでCoffee Lakeを選びます。

次はKextです。使用中のKextを選びました。Lilu, VirtualSMC, SMCProcessor, SMCSuperIO, WhateverGreen, AppleALC, IntelMausiを選びます。Kext選択は、システムに依存しますし、知識も必要なので、初見で簡単に決められる作業ではないですね。さらに、自前で作ったUSBポートの設定kextは、当然ですがここでは選択できないです。

Firmware Driversは、OpenRuntimeとHfsPlusを選びます。今はVBoxHfsを使っているのですが、HfsPlusの方が高速なはずです。他に、ブートの見た目をよくするためにOpenCanopyを使ってますが、これは選択肢に出てこないです。

次はSMBIOSの設定です。System Model, Serial Number, MLB, UUIDに、今使っているそのままの値を入れました。System Model (機種ID) はiMac19,1です。

起動オプションも、現用と同じ

-v keepsyms=1

を書き込んでおきました。

これでGenerate EFIボタンを押すと、デスクトップにEFIフォルダが出来上がります。

完成したEFIフォルダを確認

デスクトップに作られたEFIフォルダを確認します。config.plistが出来上がっていて、OpenCore関連のファイル類も入ってます。またKextsとDriversフォルダには設定したファイルが入っていました。下の図のように、OC Gen-X.appの中のContents/Resourcesの中に、OpenCoreとkext類の一式が入っています。これがそのままコピーされたのだと思います。OpenCore, kext, efiの最新版が出ていたらこちらを差し替えれば良いと思いました。

ただし、ACPIフォルダは空です。これも用意してくれれば良いのにと思いました。ここは手作業で入れておきます。Coffee Lakeに必要なACPI類は、

SSDT-PMC.aml
SSDT-PLUG.aml
SSDT-EC-USBX.aml
SSDT-AWAC.aml

です。ACPIフォルダにamlファイルを追加したので、config.plistにも反映しておかねばなりません。ProperTreeの機能を使いました。元々はACPIの記述は何もありません。

ProperTreeのSnapshot機能を使うと、今追加した4個のamlファイルが追加されました。

起動するかどうかを試す

ここまで行ったステップは、

OC Gen-Xを使ってEFIフォルダを作る
ACPIファイル(aml)を追加する
ProperTreeのsnap shot機能を使う

の3ステップです。使用すべきkextファイルがわかっているとか、シリアル番号などは決めてあるとか、使用すべきamlファイルが手元にあるとか、ProperTreeを用意しておくなど、下拵えは必要ですが、それが準備できていれば、3分くらいでEFIフォルダが完成すると思います。

では、このEFIフォルダで起動するでしょうか？

HFS+でフォーマットしたUSBメモリを用意して、これのEFIフォルダに書き込んで試しました。BIOSでUSBメモリを設定して起動したところ、なんと問題なく起動しました！

USBの15個対応のkextを入れてないのでUSBの一部が動かない
その関係でBluetoothが動かない
サウンドの設定をしていなかったので音はまだ出ない

などの問題はあるものの、これは設定を行えば済むことです。とりあえず起動を目指すには、便利なツールだと思いました。

config.plistを比較する

自動生成されたconfig.plistを、いろいろ調整して作っていた自家製config.plistと比較しました。以下の項目は、実質的に同じ内容でした。

ACPI
Booter
UEFI

以下の項目で自動生成版と自家製版config.plistが違いました。

DeviceProperties

自動生成されたconfig.plistのDevicePropertiesにはデバイスの記述がありません。自家製config.plistには、サウンドとiGPUの設定がしてあります。音が出なかった原因はこの設定がなかったことです。iGPUは設定なしでも起動できましたが、構成によっては（特にiGPUを使う場合）起動しない可能性があります。DevicePropertiesに記述がないと動かないデバイス（特定のLANチップなど）があるとその機能は動かないことになります。

Kernel

いろいろ工夫して加えていたkernelパッチ（光ディスクのスリープ対策とリムーバブルベイのホットプラグ対策）が自動作成版に無かったのは当然ですが、これらは起動には問題ない項目です。

Quirksは、いくつか違ってました。自動作成版はDortaniaガイドのデフォルトに従っています。自家製設定と比較すると、ガイドの一部を変更していた項目が違ってました。以下にそれを示します。でも、いずれも起動には問題なかったです。

AppleCpuPmCfgLock: BIOS設定で設定したのでここで対応する必要がなく、デフォルトを変更してfalseにしてます。
AppleXcpmCfgLock: BIOS設定で設定したのでここで対応する必要がなく、デフォルトを変更してfalseにしてます。
DisableIoMapper: デフォルトを変更してfalseにしてます。
DisableRtcChecksum: デフォルトを変更してtrueにしてます。
XhciPortLimit: USB 15個制限を無理やり回避する項目です。ちゃんと対策してfalseにすべき項目です。デフォルトではtrueですが、今回の実験ではそれでも一部のUSBポートが機能してませんでした。対応するkextを作ってデフォルトを変更してfalseにしてます。

Misc

Debugカテゴリーのうち、自家製版では、AppleDebug, ApplePanic, DisableWatchDogのデフォルトを変更してfalseにしてます。またDisplayLevelを2147483648にしてます。

Securityカテゴリーでは、ExposeSensitiveDataを7に、ScanPolicyを19858179にしてましたが、これは大した違いではないです。自動生成版では、SecureBootModelがdisabledになっていますが、0.6.3からはSecureBootModelはdefaultで良いようです。でもどちらでも起動はします。

NVRAM

自動生成では、prev-lang:kbdがデフォルトのロシア語になってます。自家製版では、これを英語（16進数で656E2D55533A30）にしてます。

PlatformInfo

自動生成版ではmemoryに関する記述が増えています。ただ、システムの値を自動的に使う設定にもなっているので、ここは無駄なところかと思いました。それ以外は、手作業で設定していたconfig.plistと同じでした。

まとめ

OpenCoreのEFIフォルダ内容を作成するツール、OC Gen-Xを使ってみました。ACPIのファイルを設定する機能が無いこと、config.plistの設定でできれば直したいと思う点も多少はあるものの、起動するEFIフォルダーを短時間で作ることができました。初めて挑戦する環境でhackintoshするときに、とても役立つと思いました。OpenCoreにたくさんあってややこしいQuirksの設定をとりあえず無難にこなしてくれるだけでも助かります。

HPの小型デスクトップEliteDesk (6: Windowsを入れる)

Sun, 06 Dec 2020 00:53:46 +0900

いろいろ頑張ってきたHP EliteDesk 800 G2 DM (Core i5-6500T)ですが、Windowsをインストールしました。Hackintoshとしては完敗です。macOSからはWindowsを画面共有で使います。sshでUbuntuも使います。電源が切れてても使えるようにWake On LANの設定もしました。

Microsoft Remote Desktop

最近はWindowsが絶対必要という場面が少なくなりましたが、世の中がWindows前提なので、たまにWindowsを使わざるを得ない時があります。Hackintoshなら、マルチブートにしておけば、同じマシンでWindowsが使えますが、切り替えが面倒です。VMware Fusion Player 12 が個人利用で無償になって、かなり快適でした。なので仮想環境でWindowsを使う手もあります。マルチブートに比べて性能は出ませんが、macOSとの切り替えが簡単です。今回は第3の選択肢として、Windowsマシンを別に用意して、これにリモートデスクトップする方法を試します。

そこで、macOSをインストールしようとして暗黒画面問題で挫折したHP EliteDesk 800 G2 DM

HPの小型デスクトップEliteDesk (4: 暗黒画面問題で頓挫)

にWindowsを入れて、ディスプレイ無しのリモートデスクトップサーバにします。macOSは諦めて、ただのWindowsマシンに戻すのですから、BootmacOSの路線からしたらダメダメな状況です。すみません。でもWindowsマシンが用意できれば、これにmacOS用のMicrosoft Remote Desktopで接続することでWindowsが使えます。Remote Desktopクライアントプログラムは、無償で配布されていて、使いやすいです。応答も素早いので、仮想マシンより快適な気がしました。

Remote Desktopを起動すると、接続先を選べるようになります。接続先のマシンを何個も登録できるインタフェースでした。職場の何台ものWindowsマシンを管理するような状況を想定しているのかもしれません。

HP EliteDesk 800 G2 DMは小型なのでiGPUで動きます。M1が話題になって貧弱さが際立っているインテルiGPUなので、このままディスプレイには接続しないで、ヘッドレスのリモートデスクトップサーバとして使おうと考えてます。小さなマシンなので、邪魔にならないです。

Windowsをインストール

まずはHP EliteDesk 800 G2 DMにWindowsをクリーンインストールします。macOSマシンにされていたところが、本来の姿に戻ることになります。でも元からあったWindowsは綺麗に全消去されているので、起動できるUSBメモリインストーラを作ります。そこで、Z390 + 9900K + OpenCore 0.6.3 + Big Sur の構成のマシン（機種IDはiMac19,1）で以下の作業をしました。Windowsインストール用のISOイメージファイルがダウンロードできるMicrosoftのサイトに行きました。

Windows 10 のディスクイメージ (ISO ファイル) のダウンロード

とりあえずダウンロードしてみたところ、Windowsのイメージファイルは6GBほどでした。12GB超えてるBig Surに比べて優しいですね。

これから頑張れば、インストール用USBメモリをmacOS環境でも作れないことはないです。でも結構難しい作業で、適当に試しても失敗ばかりでした。USBメモリをFAT32でフォーマットするのですが、コピーしなければならないファイルの一つが、FAT32の限界の2GBを超えているところがネックです。それを乗り越える技が複雑過ぎました。

結局、macOSで頑張るのは諦めて、Windowsでインストール用USBを作ることにしました。このマシンの、Big Surとは別のSSDにWindows 10が入っています。OpenCoreでWindows起動SSDを選択して起動し、上記のMicrosoftのサイトに接続しました。すると、ISOイメージファイル以外に、起動可能なUSBインストーラを作成するアプリケーション「Media Creation Tool」がダウンロードできるようになってます！。macOSからこのページを開いても、Media Creation Toolの選択肢は見えませんでした。Media Creation Toolは、macOSのcreateinstallmediaコマンドとよく似た名前で、同じような機能のプログラムです。ですが、Windows版の方が完成度高いです。CUIコマンドのmacOS版と違って、GUIで起動して、ISOイメージを自動でダウンロードして、そのままUSBメモリに書き込んでくれます。とても楽でした。

BIOSもアップデート

ついでにBIOSもアップデートしておきました。HP EliteDesk 800 G2 DMのBIOS画面に、ネットワークからダウンロードして更新するメニューがあります。クリックするだけで最新版 (2020/11/6版の02.51 Rev.A) になりました。以下はHPのサイトですが、ここからダウンロードする必要はありませんでした。

HP EliteDesk 800 35W G2 Mini PC ソフトウェア及びドライバーのダウンロード | HP…

デジタルライセンス

HP EliteDesk 800 G2 DMの筐体のどこを見てもWindowsのプロダクトキーが書いてありません。Windowsを買わないとダメなのか、全消去するんじゃなかったと少し後悔しました。ところが今やデジタルライセンスの時代だったんですね。このマシンの情報がすでにどこかのサーバに登録されているらしく、Windowsインストール作業最初のプロダクトキー入力をスキップしても、自動的に認証されてました。SSDもメモリもCPUも交換してしまっているので、BIOSのシリアル番号のようなもので個体識別しているようです。メーカー製PCにはWindows代が含まれているので当然の結果かもしれませんが、予想外でありがたかったです。ハードにOS代が含まれていることは、よく考えたらmacOSも同じです。

HP EliteDesk 800 G2 DMの中古価格は、Core i3モデルが1.5万円くらい、i5モデルでも2万円くらいです。一方で、マルチブートしたり、仮想環境を使ってWindows 10 Proを起動する場合には、パーツに紐付けたDSP版でも1.7万円くらい、通常版なら2万円以上のライセンス代が必要になります。そう考えると、デジタルライセンスが付いた上にCPUもメモリも手に入る中古のハードを買うのは、お得な手段なのではと思いました。

リモートデスクトップサーバを有効化

インストールしたWindows 10で最初に行った作業は、リモートデスクトップサーバをonにすることです。これでmacOSから作業ができます。設定する場所が「設定」だったり「コントロールパネル」だったり混乱します。

WSLを入れる

次に行った作業は、WSL (Windows Subsystem for Linux) を有効にすることです。

そして、Microsoft StoreからUbuntu 20.04 LTSをダウンロードしてインストールしました。WSLがあってLinuxが使えることは、macOSユーザから見てちょっと羨ましいです。

とはいえ、WindowsとLinuxではディレクトリ構成が違います。ディレクトリ階層の区切りも¥と／で違います。ファイルやフォルダをUbuntuのウィンドウにドラッグ&ドロップしても、Linuxが理解できるディレクトリ文字列になりません。macOSファインダとターミナルのような円滑な操作性ではなく、ぎくしゃくしている印象です。Windows上の仮想環境でLinuxを動かしているので仕方ないですが、もう少し統合してほしいと思いました。ネイティブに動いているmacOSのUNIX環境が、シームレスで使いやすいことを改めて実感しました。

Dropboxを入れる

One Driveの方がWindowsとの相性が良いのでしょうが、Dropboxを使ってます。One Driveは、昔試したことがありますが、macOSとの相性が悪かったです。One Driveでは、Windowsの規則で、ファイル名に使えない文字があります。例えば、CON, PRN, AUXという名前はファイル名・フォルダ名に使えません。また、” * : < > ? / \ |などの文字も使えません。Dropboxにはそのような制約はありません。自分で作るファイルなら命名に気をつければ良いのですが、例えばアプリケーションのパッケージの中に、たまたまこのような名前のファイル・フォルダがあると厄介です。これらがOne Driveにコピーする際に除外され、アプリケーションの内容が変わってしまいます。実際にそのような事例が発生しました。現在のOne Driveも同様な命名規則を引き継いでいるのかどうかわかりませんが、こういう理由で使用を避けてました。

SSHサーバを入れる

昔のWindowsでsshを使うのは面倒だった記憶がありました。でもWindows 10ではsshクライアントが標準で入っているようです。PowerShellから使えました。でもsshサーバ (sshd) はOpenSSHを自力でインストールする必要があります。

一方で、WSLのUbuntuには、あって当然なのですが、sshのクライアントとサーバが入っています。Ubuntuのsshサーバは、以下のコマンドで起動することができます。

sudo service ssh start

ということで、sshdを使うには、

Windowsのsshdを使う
Linux (WSL-Ubuntu)のsshdを使う

の2種類の選択肢があります。ここはすでにインストール済みのLinuxにしました。Windowsルートは手順が大変そうでしたが、Linuxルートにも罠がありました。普通のLinuxなら

sudo systemctl enable sshd.service

というような類のコマンドで、起動時に自動的にsshdが起動するように設定できました。でもWSLでは技術的な事情でsystemctlコマンドが動かないようです。なので、コンピュータを起動するたびごとに、

sudo service ssh start

のコマンドを発行する必要があります。これは自動化したいところです。ちょっと調べたところ、PowerShellからWSLのコマンドを発行する命令があるらしいです。その名もwslです。これを使って、

@echo off
wsl -u root -- service ssh start

というbatファイルを作ると、Windows環境から、–の後に書いたLinuxの命令がroot権限で出せるようです。batファイルなんて書くのはものすごく久々でした。

Windowsのbatファイルなので、これはWindowsで実行できます。なのでこのbatファイルを、Windowsが起動した直後に実行するよう設定すれば良いです。でもこの方法もかなり試行錯誤しました。結局は、コントロールパネル–>システムとセキュリティ–>管理ツール–>タスクスケジューラに行きついて、ここで「スタートアップ時（システム起動時）に」「ログインしているかどうかにかかわらず実行する」設定で、batファイルを登録すれば良いようでした。

sshdが起動するように設定するには、Linuxならコマンドひとつ、macOSだと「システム環境設定」「共有」で「リモートログイン」をクリックするだけです。Windows (WSL) だと深い階層の幾つもの設定が必要で大変でした。でもこの作業の結果、電源を入れるだけでLinuxのsshdが応答してくれる状態になるので、別のマシンからssh接続すればUbuntuのシェル環境が使えます。Windows環境が用意されただけでなく、いつでも試せるLinux環境も出来上がったので、ちょっと嬉しいです。

Wake On LANを設定

次にWake On LAN (WOL)を設定しました。これに関しては、Windowsは素晴らしい！です。WOLは、ネットワークの他のマシンから、スリープ中や電源切れているコンピュータを目覚めさせる機能です。そのために、相手のMACアドレスを指定して、マジックパケットという謎のパケットを送りつけます。マジックパケットを送るアプリケーションは多数ありますが、Pythonで書けばこんなプログラムで可能なようです。

#!/usr/bin/python
import socket
s=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
s.sendto('\xFF'*6+'\x99\xAA\xBB\xCC\xDD\xEE'*16, ('192.168.xxx.255', 7))

最後の行に、目覚めさせたいコンピュータのNICの情報を書きます。\x99\xAA\xBB\xCC\xDD\xEEの部分がMACアドレスで、192.168.xxx.255がIPアドレスです。IPアドレスの最後が255なのは、ブロードキャストするためです。ここを機器のアドレス通りにしても、一応は起動するようです。でも今回のマシンで試したところ、offした後しばらくは起動しますが、時間が経つと失敗します。シャットダウンしてからしばらくすると、スリープモードが深まるのか、自分のIPアドレスがわからなくなるようです。255にしておけば、必ず成功します。

macOSでは、「システム環境設定」「省エネルギー」の「ネットワークアクセスによるスリープ解除」で、Wake On LANを有効にできます。以下は、「省エネルギー」のデフォルト設定ですが、デフォルトで有効になってます。このほかにもBIOSでWOLを有効にしておく設定が必要です。

Windowsの場合は、デバイスマネージャの中のいくつかの設定でWOLを有効にします。ここではWake On Magic Packetが有効であることを確認してますが、このほか「電源の管理」タブも関係があります。一般的にmacOSよりも設定箇所が多い傾向にあると感じますが、デフォルトのままで大丈夫でした。ちなみにネットワークアダプターのドライバを、上記のHPのサイトからダウンロードしないと、WOL関係の設定が現れなかったです。Windowsの標準ドライバーでは、最新に更新してもWOLの設定がありませんでした。このほかBIOSの設定も確認する必要があります。

幾つか試行錯誤しつつ設定したところ、macOS（前述のZ390マシン）でも、このWindowsでも、どちらもマジックパケットを送ってスリープから目覚めさせることができました。

macOSでは、スリープ状態に対してのみ、WOLが効くようでした。電源を落としてしまうとWOLは効かなくなります。少し検索しただけなのですが、ネットにもやっぱりそう書いてありました。もし、電源も入れられるようなWOL設定の情報ありましたら、教えていただければとても助かります。

一方、Windowsでは、なんと電源を切った状態でもWOLが効きます。電源の落ちたマシンにマジックパケットを送ると電源投入できました。これはちょっと素晴らしいです。

訂正：hackintoshなら電源を切った状態からのWOLが効きます。以下をご覧ください。

Wake On LAN (WOL) を使ってmacOSの電源を入れる

追記：Windows 10のWOL

その後、起動ディスクをM.2 SSDに変更しようとして、Windows 10のクリーンインストールを再度行いました。そうしたら電源offでのWOLが効かなくなりました。結局は、再びWOLが動くようにできたのですが、そのポイントをメモしておきます。

LANのドライバーは最新にします。Windowsに最初に入っている、または更新からダウンロードできるIntel LANドライバーにはWOLの設定項目がありません。HPのサイトからダウンロードするとWOLの設定があります。これがないとsleepからのWOLもできないです。
「高速スタートアップ」をoffにします。これがOnだとシャットダウンからのWOLができなかったです。
スリープ中やシャットダウン時に、LANコネクタのLEDが点灯していることが重要です。これが消灯している状態だと如何なるパケットも受け付けないようで、WOLもしません。
BIOSでシャットダウン時にS5に移行するよう設定すると、WOLしません。Off状態ではLANコネクタのLEDも点灯しません。デフォルトはS5ではないので、注意すべき点ではないですが。

WOLはいろいろとややこしいです。シャットダウンしないと、機能しているかどうかを確認できないので、結果がなかなかわからないこともあり、手間がかかります。そこを設定するところが達成感を得られて楽しいところです。

まとめ

暗黒画面問題で頓挫したHP EliteDeskは、結局のところWindowsマシンとして復活しました。ディスプレイは接続せず、macOSからMicrosoft Remote Desktopで使用します。Windowsのデジタルライセンスが効いていたので無償でした。さらにWSL、SSHサーバ、Wake on LANなどを設定しました。このプライベートネットワークには、ルータのVPN機能を使ってL2TP over IPSecでインターネットから入れるようにしてあります。なので

外出先からVPNで接続する
Pythonプログラムでマジックパケットを送る
電源が切れているHP EliteDeskが起動する
sshまたはRemote Desktopで接続する

という手順で、世界中どこからでも、このWindowsマシン（Ubuntu付き）をmacOSから利用できるようになりました。今後は、電源が切れている自作Z390 macOSマシンも、外部から起動して使えるように考えたいです。

VMware Fusion Player 12を使う

Thu, 03 Dec 2020 21:34:52 +0900

無償で個人利用できるようになったVMware Fusion 12 Playerを使ってみました。無償ライセンスを入手するのが手間でしたが、インストールは簡単で素早く、機能も動作も満足のいくものでした。

無償になったPlayer版

VirtualBoxを使う記事、

HackintoshでVirtualBoxを使う

のコメントで、VMware Fusion 12 Playerが無償になったことを教えていただきました。こちらの記事が詳しいです。

個人なら無償インテルMac用仮想環境アプリ「VMware Fusion Player 12」レビュー (…

VMware Fusion 12はBig Surに対応したバージョンらしいですが、そのスタンダード版に当たるPlayer用のライセンスキーが、今回、個人利用者に対して無償で配布されることになったそうです。ということで現状のmacOSで利用できるVMアプリケーションは以下のようになりました。

Parallels（有料）
VMWare Fusion（個人利用は無料）
VirtualBox（無料）

VMwareの有料版も、かなり昔に使っていた記憶があります。有料なだけあって、Parallelsと同様に使いやすく性能が良かったです。それで早速、ASCIIの記事を参考に無償ライセンスキーと本体を入手しました。ASCIIの記事にあるように、入手場所は、webページの中のわかりにくい場所にあります。またユーザ登録が必要です。大昔に有料版を使っていた時に登録してあったのか（すっかり忘れてましたが）アカウントが残ってました。

ダウンロードして動かす

次にVMwareのサイトから本体をダウンロードします。インストールが終了するとこんなウィンドウが出ます。使用したマシンの構成はハードウェアがASUS Z390マザーボード + 9900Kで、ソフトウェアがOpenCore 0.6.3 + macOS Big Sur 11.0.1です。

VMware Fusionを起動すると、ライセンスキーを聞かれるので、サイトで入手した番号を入力します。

このウィンドウにも、無償ライセンスキーを取得するリンクのボタンがあります。先にソフトウェア本体をダウンロードして、その後に、ライセンスキーを取得に行くのがわかりやすかったかもしれないです。ライセンスキーを入れると、無事、受け付けてくれました。

この後、起動用のイメージファイルを選択する画面になります。Windows 10のisoファイルがあったので、それを選択しました。すると、特に設定の必要もなく、稼働ボリュームのイメージファイルが作られて、インストールが始まり、Windowsが起動しました。10分ちょっとくらいで終わってしまった感じで、速かったです。Windowsをアップデートしたりなどして、多少使った後の稼働ボリュームのファイルは20GB程度でした。今後さらに使用を続けていくと、必要に応じてサイズが大きくなっていくのだと思います。

まとめ

VMware Fusion 12が無償で利用できるようになっていたことを知り、インストールしました。ゲストOSとしてWindows 10をインストールしたところ、キビキビと動いていて快適です。VirtualBoxと比べて、元々が有償ソフトウェアなためか、高速に動く気がしました。以前から無償で利用できたVirtualBoxにはお世話になりましたが、Fusionをしばらく使ってみようと思いました。

HomePod miniを使う

Sun, 29 Nov 2020 00:19:43 +0900

HomePod miniを使ってみました。macOSからはAirPlayのスピーカーとして使えます。またHome.appからアラームの設定ができます。HomeKitのホームハブとして使えるそうですが、そちらは試せてません。

HomePod mini

Amazon EchoやGoogle Homeに比べて、Appleのスマートスピーカは高価なHomePod無印が1機種だけしかなく、普及に力を入れているという様子がありませんでした。でもHomePod miniが出て、競争力が付いたと思います。Echoは、安いのでいくつか使用してますが、結構便利です。でもAppleのエコシステムで生きているので、カレンダーやメッセージにアクセスできなくて物足りなく思ってました。今回、手頃な価格でコンパクトなHomePod miniが出たので、ようやく試せました。

設定

箱から出して、電源に接続して、iPhoneを近づけると、iPhoneに設定画面が現れます。このあとは数個の選択肢を設定していくだけです。

この辺りは、iOSを所有している会社の製品だけあって、手間要らずです。自社のアプリをダウンロードさせたり、起動させたりする手間が不要なだけでも有利です。Wi-Fiなどの設定も、Amazon Echoに比べたら格段に容易でした。てっぺんのLEDの点滅をiPhoneで撮影して、デバイスをペアリングする手法もスマートです。その結果、Wi-FiもBluetoothもApple IDも全てが、気づかないうちに設定終了してました。逆に言うと、iPhoneが無いと使い始めることもできないデバイスです。

このあと、Z390 + 9900KにOpenCore 0.6.3 + Big Sur 11.0.1の構成のmacOSマシンから何ができるのか試しました。無線ユニットは、純正Macと同じBCM94360CDです。

Hackintoshのパーツ選び【その4：無線編】

HomePod miniとの通信でBluetoothなども使っているのかなと思ったのですが、以下で紹介するAirPlayもHome.appも有線LANだけで動きました。BluetoothとWi-Fiをoffにしても同様に動きます。

AirPlayスピーカー

まずはサウンドです。デフォルトの選択肢からオフィスを選んであったのですが、その名前でAirPlayデバイスとして見えてます。これを選択するだけで、すぐに音が出ました。Bluetoothのペアリングは、簡単そうで失敗することも多いのですが、こちらは手間要らず機能します。キーボードの音量キーも操作可能でした。HDMIやUSBオーディオだとキーボードの音量キーが効かないことも多いので、これは助かります。

すでに色々な人が音質が良いとレビューしてますが、評判通り、音質はそこそこ良いです。ステレオスピーカーと比較すると、HomePod miniはモノラルなので、広がりに欠けるのは仕方ないです。ちなみに、2台のHomePod miniを用意すると、iPhoneからはステレオになります。でもmacOSのAirPlayではモノラルのスピーカーが2個に増えただけになってしまうらしいです。macOSで使う限り、1台だけ買えば良いようです。

しばらく使ってみると、いくつか不具合に気づきました。まず、YouTubeで動画を止めたり動かしたりしていると、HomePod miniの設定音量とずれてしまうことがありました。また、macOS警告音の「サウンドエフェクトの再生装置」として、システム環境設定の選択肢にHomePod miniが現れることもあれば、現れないこともあります。バグのような感じなので、そのうち直してくれるかもしれません。

もう一点、気になったところは、遅延が大きい場合があることです。サウンドエフェクトの再生装置として現れる場合、通知音のサンプルをクリックしてから1~2秒くらい遅れて音が出ます。MusicやQuickTime Playerなどで音楽の再生・停止ボタンを押すと、2秒くらいしてから反応します。動画再生・停止でも遅延します。でも映像も遅延するので、音との同期がズレる現象はないのです。いずれの場合も、マザーボードのサウンドチップでは瞬時に応答するので、AirPlayが原因だと思われます。何処かのバッファメモリが一杯、または空っぽになるまで、操作結果が反映されない感じです。遠隔会議ではこの遅延のために対話が成り立ちません。いろいろ謎の遅延ですが、これもそのうち直してくれるのかもしれないです。

ホーム.app

ホーム.appを開いてみました。オフィスという場所に、HomePod miniが見えてました。名前は変更できます。いくつかの設定も変更できます。でもできることは、アラームを設定する程度の事でした。macOSから操作するよりも、Siriに音声でお願いしたほうが楽そうです。

純正環境との比較

AirPlayの遅延などに関しては、hackintosh環境なので、不具合が起こっても当然だったのかもしれません。それで純正Mac, iPhone環境ではどうなのかを確認しました。

純正Macとの比較

Big Sur 11.0.1が動いている本物のMacBookからこのHomePod miniに接続して確認しました。警告音のデバイスに現れない、2秒くらい遅延するという状況は、同様に発生しました。hackintoshの問題ではないようです。

iPhoneとの比較

iPhoneから接続すると、Musicアプリでも、一般のアプリ（例えばSafariで見るYoutubeサイトの動画）でも、遅延はありませんでした。

AirPlay 2.0

先の説明で、macOSのAirPlayではHomePodはステレオにならないと書きました。正確には、macOSでも、Music.appからだけはステレオになるそうです。

調べたところ、初代HomePodが発表された2017年に同時に、AirPlay 2.0が発表されて、そこで複数スピーカーの同期ストリーミングがサポートされたのだそうです。これにより2台のHomePodでのステレオ再生がサポートされたのだと思われます。この時に、遅延の問題も改善されたのでは無いかと思いました。それで、iOSは全面的にAirPlay 2.0に対応しているので、遅延が発生しないけど、macOSではMusic.appだけが2.0に対応しているので、Music.appを使う時だけは、ステレオにもなるし、遅延も発生しないということかと思いました。

実はmacOSのMusic.appでも、設定によっては2秒の遅延が発生します。純正Macでも同様です。Music.appのAirPlayアイコンから、HomePod miniを選択すると、遅延は発生しません。「オフィス」というのがHomePod miniです。

でもここで「コンピュータ」を選んで、macOSの「システム環境設定」「サウンド」からAirPlayデバイスを選ぶと遅延が発生します。前者は、

Music.app ---> ( AirPlay 2.0 ) ---> HomePod mini

という接続になっていて、ステレオになって遅延も発生しないけど、後者は、

Music.app ---> macOS ---> ( AirPlay ) ---> HomePod mini

というようにmacOSを経由した設定で、この場合、古いAirPlay無印が使用されて、その結果遅延が発生するということかと推測できます。macOSのMusic.appは自前でAirPlay 2.0を実装しているのか、それとも2.0を提供するmacOSの未公開APIがあってそれを使用しているのかと思われます。

まとめ

HomePod miniが自作マシンのmacOSから使えることを確認しました。AirPlay接続のスピーカーとして使えて、さらにホーム.appにはデバイスとして現れます。ただ遅延が大きいので、コンピュータ用スピーカーには向いてませんでした。常設のSiriデバイスとして使っていきます。

OpenCoreのpicker画面を設定する

Tue, 24 Nov 2020 18:43:49 +0900

OpenCore 0.6.3のSample.plistを真似て作ったconfig.plistでは、ブート時のpicker選択画面で、macOSのUSBインストーラやWindowsドライブが現れませんでした。これを治しました。またpicker画面で使える便利な機能も設定しました。

デフォルト設定のpicker

OpenCoreが起動する際に、箇条書きやアイコンで現れる選択肢のことをpickerというのだそうです。Cloverの時は起動ボリュームが現れましたが、OpenCoreではツールのアイコンも一緒に現れるので、pickerと呼ぶのが適切なのかと思いました。

最近、このpicker画面にWindowsが入ったSSDが現れなくなっているのに気づきました。でもWindowsの使用頻度がほとんど皆無なので放置してました。その後、Big Surをクリーンインストールしようとしたときに、USBメモリーに入れたBig Surインストーラもpicker画面に現れませんでした。それで対応することにしました。OpenCoreのデフォルト設定では、WindowsもUSBメモリもpickerとして現れないようです。実際の例で示します。以下は、

macOSの入ったM.2 SSD
Windowsの入ったSATA SSD
Big Surインストーラが入ったUSBメモリ

が接続されたZ390マシンが起動した直後のpicker画面です。config.plistのほとんどの項目は、Sample.plistに記述のデフォルト状態です。上記の3個のボリュームに相当するpickerが現れて欲しいところですが、このうちの1個、macOSの入ったM.2 SSD (Macintosh HDという名前）しか現れません。Recovery はそのSSDに入っている復旧用ボリュームです。ほかに、UEFI ShellとNVRAMリセットのpickerが見えてます。

ScanPolicyを設定する

pickerを変更する方法の一つが、config.plistのMisc –> Security –> ScanPolicyという整数値を変更する方法です。これは起動選択のボリュームをスキャンする際のセキュリティ方針を決める項目のようです。得体の知れないボリュームから起動することは、セキュリティとして良く無いので、起動対象ボリュームの種類を決めておきましょうという項目のようです。

ScanPolicy = 0

ScanPolicyには、どのファイルシステムとどのデバイスを対象とするかをビットで設定します。詳細はOpenCoreのマニュアルに書いてあります。

• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.
• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported. Known device types are prefixed with OC_SCAN_ALLOW_DEVICE_.
• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.
• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.
• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.
• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.
• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_LINUX_ROOT, allows scanning of Linux Root file systems.
• 0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems.
• 0x00004000 (bit 14) — OC_SCAN_ALLOW_FS_XBOOTLDR, allows scanning the Extended Boot Loader Partition
as defined by the Boot Loader Specification.
• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.
• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.
• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.
• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.
• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.
• 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.
• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.
• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.
• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus
(e.g. VIRTIO).

LSB 2ビットは、ファイルシステムとデバイスを限定するかどうかのビットで、0にしておけば全てのボリュームが現れるようになります。なのでScanPolicyを0に設定してしまえば、全てのボリュームが現れます。下の例は、同上のマシンでScanPolicyを0にした時のpickerの様子です。WindowsとUSBインストーラ（丸いBig Surアイコン）が追加されました。

左端に現れているオレンジ色のEFIというpickerは、USBメモリのESPです。OpenCoreが入ってます。これを選択すると、「すでにOpenCoreで起動している」というような内容のメッセージが出るだけです。Cloverの入ったESPが他のドライブにあると、それも現れます。ESPの内容がCloverの場合はCloverに切り替わります。起動できるESPがある場合に、それが現れてしまうのは、ちょっと煩雑な感じがします。でも、実際のMacでも、オプションキーで起動すると、同様に起動可能なESPがpicker画面に出現します。実機と同じ仕様と思えば納得できます。

ScanPolicy = 19859203

ScanPolicy = 0で全く困らないのですし、そう設定するように指示するガイドページもあります。実際OC Gen-Xが自動生成するconfig.plistも0に設定してます。ただ、せっかくセキュリティの機能が用意されているのに、無視するのももったいない気がします。正しく必要なものだけ設定したいと考えました。

ScanPolicyのデフォルト値は17760515です。ScanPolicyの設定そのものをconfig.plistから削除するとこのデフォルト値になります。Sample.plistでもこの値が設定されています。このデフォルト値では、

ファイルシステムはAPFSのみ
デバイスはSATA, SAS, NVMe, SCSI

を対象とする設定です。APFSのみなので、Windowsはもちろん、HFS+だったBig SurインストーラUSBも現れないわけです。さらには、デバイスでは、USB, DVD, FireWire, SDカード, PCIバスが除外されています。Big SurインストーラUSBはデバイスとしても除外されていました。そこで、このデフォルト値に追加して、

ファイルシステムにHFS+とEFI System Partition (ESP) を追加する
デバイスにUSBを追加する

ような設定にしました。それが10進数で19859203になります。ファイルシステムの選択肢にNTFSのビットがあったので、Windowsならそれだろうと考えたのですが、違ってました。ブートローダーがESPにある関係か、NTFSビットを立ててもWindowsのpickerは現れませんでした。ESPビットを設定する必要があるようです。ScanPolicyを19859203に設定すると、（上の写真と同じですが）以下のようになりました。

ビットの計算をする

皆さんはビットを立てたり、外したりするのにどうやって計算されてます？今回は手軽で便利なmacOS標準搭載の「計算機」を使いました。「計算機」はメニューの「表示」「プログラマ」を選ぶと16進数、8進数などを扱えます。入力や結果はコピペできるので便利です。

今回の計算は以下のようにして行いました。まずは、ScanPolicyのデフォルト値の、17760515をコピーします。計算機を10進数に切り替えて、ペーストします。その後、16進数に切り替えると、0x010F0103であることがわかります。ビットがわかりやすいです。

ここで、スキャン対象のファイルシステムにHFS+とESPを追加して、対象デバイスにUSBを追加します。それぞれのビットは、OpenCoreのマニュアルによると、以下です。

HFS+ : 0x200
ESP : 0x400
USB : 0x200000

なので、合計で0x200600のビットを立てれば良いわけです。そこで「計算機」で「OR」を押した後、0x200600を入力して、イコールを押します。出てきた結果は16進数で0x12F0703になります。10進数に切り替えれば、設定すべき10進数、19859203が得られます。これもコピーしてProperTreeまたはPlistEDPlusにペーストすれば良いです。

「計算機」にはRPN（逆ポーランド記法）で操作するモードもあるので、マニアックな人も満足できると思います。

おまけ1: 表示pickerを減らす

Pickerがこれくらい並んでも（USBメモリーが挿さってなければ2個減りますし）適切に賑わっていて良いと思いました。でも、efiツールをたくさんインストールしている場合は、それが右端に追加されるので、煩雑だと感じることもあるようです。

そこで、使用頻度の低いpickerを非表示にするオプションがあるようです。config.plistのMisc –> Boot –> HideAuxiliaryです。デフォルトではfalseですが、これをtrueにすると、写真のpickerのうち、Recovery, Reset NVRAMが非表示になります。また、Misc –> Toolsで追加しているefiツールItemの中のAuxiliaryをtrueにしているツールも非表示になります。現在はOpenShell.efiを追加してありますので、HideAuxiliaryをtrueにした上で、さらにOpenShell.efiの設定でAuxiliaryをtrueにしました。その結果、表示されるpickerが以下のように減りました。

ここでスペースキーを押すと、非表示にしていたpickerが元通りに表示されます。

おまけ2: -vを一時的に有効にする

Misc –> Boot –> PollAppleHotKeysをtrueにすると（デフォルトではfalseです）picker画面でApple標準のホットキーがいくつか使えるようになります。使用可能になるキーは以下です。

CMD+C+MINUS — disable board compatibility checking.
CMD+K — boot release kernel, similar to kcsuffix=release.
CMD+S — single user mode.
CMD+S+MINUS — disable KASLR slide, requires disabled SIP.
CMD+V — verbose mode.
Shift — safe mode.

ありがたいのはコマンド + vです（vは小文字でok）。ブートオプションには-vを付けずに、シンプルなリンゴマークだけで通常は起動していて、ちょっと動作が怪しい時だけ、コマンド + vでverbose modeに入れるようになります。Cloverだと起動画面からオプションを一時的に切り替えることができたので、同じように運用できます。

まとめ

ScanPolicyをデフォルト値から変更して、WindowsやUSBインストーラがpickerに現れるよう設定しました。また、HideAuxiliaryとPollAppleHotKeysもデフォルト値から変更しました。

Intel NUC D54250 (i5-4250U) にBig Sur 11.0.1を入れる

Mon, 23 Nov 2020 13:08:34 +0900

Haswell世代Core i5-4250U搭載Intel NUCにBig Sur 11.0.1をクリーンインストールしました。もともと11.0.1 RCを動かしていたので問題なく起動しました。サポート対象中の最弱マシン相当仕様ですがキビキビ動きます。

Intel NUC D54250

Intel NUCは、ノートPC用CPUを搭載したデスクトップです。MacBook Airからディスプレイを外してデスクトップにしたような仕様です。低消費電力なので電源を入れっぱなしの家庭用サーバに向いていると思います。

Intel NUC D54250, 4250U

10月に、これにOpenCoreを入れて、Big Sur Beta 9をインストールしました。その後、11.0.1 RCを入れてます。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

今回は、これに公開版のBig Sur 11.0.1をクリーンインストールしました。11.0.1 RCが問題なく動いている状態だったので、動いて当然の作業です。

構成は以下です。

Intel NUC D54250WYKH (2.5 inchドライブを内蔵できる背の高いモデルです。ちなみに兄弟モデルにはWYK, WYBがあります。WYKは2.5 inchの入らない薄型。WYBは基板だけです。)
CPUはIntel(R) Core(TM) i5-4250U CPU @ 1.30GHz
BIOSは2019年9月2日版のWYLPT10H-86A.0054
グラフィックスはIntel HD Graphics 5000 (ごく稀にアーティファクトが出ます)
mSATAソケットにが付いています。
2.5インチドライブベイには2TB HDDが付いています。
無線カードはです。WiFiはOOBですがBluetoothには追加のkextが必要です。
機種IDは4250Uが搭載されているMacBookAir6,2にしました。

ESPの設定

ブートに必要なESPの中身は、以下のように設定してあります。まず、ブートローダは、OpenCore 0.6.3です。

ACPIフォルダの中は以下です。

SSDT-PLUG.aml
SSDT-EC-DESKTOP.aml

Kextフォルダの中は以下です。SMC….kextはハードウェアモニター用なのでなくても良いです。Brcm….kextはBluetoothを使うために入れました。これらが無くてもWi-FiはOOBで動きます。

WhateverGreen.kext
VirtualSMC.kext
SMCSuperIO.kext (HWモニター用)
SMCProcessor.kext (HWモニター用)
Lilu.kext
IntelMausi.kext
AppleALC.kext
BrcmPatchRAM3.kext (Bluetoothが必要な場合)
BrcmFirmwareData.kext (Bluetoothが必要な場合)
BrcmBluetoothInjector.kext (Bluetoothが必要な場合)

Driversフォルダの中身は以下です。

VBoxHfs.efi (HFS+で起動しなければ不要)
OpenRuntime.efi
OpenCanopy.efi (OpenCore起動画面でアイコン出さなければ不要)

Config.plistの設定

config.plistの内容は、Haswell用ガイドのページに従って設定してあります。DevicePropertiesの箇所には、

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>AwAiDQ==</data>
 </dict>

を加えました。Intel HD Graphics 5000を表示用に使用する設定です。また、

<key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
 <dict>
 <key>layout-id</key>
 <data>AQAAAA==</data>
 </dict>

も加えました。オーディオのレイアウトIDを1番に設定する記述です。また、デフォルトではExposeSensitiveDataが6だったのを7にしました。NUCには搭載されるUSB数が元々少ないので、15個制限対策は不要です。実機のMacと同様ですね。

以前の記事で、

Misc – Security – SecureBootModel を Disabled にする

必要があると書きましたが、OpenCore 0.6.3からは、デフォルトのDefaultのままで起動します。

Big Surを入れる

前述のように、このNUCは

mSATA SSD (Big Sur 11.0.1 RC)
2.5 inch HDD (Catalina最終版)

を搭載してます。mSATA SSDにはBig Sur 11.0.1 RCを入れてました。また、2.5 inch HDDには緊急用ブートのために小さなパーティションが切ってあって、そこにはCatalina最終版が入っています。

今回は、mSATA SSDにBig Sur公開版をクリーンインストールしようとしました。そこで、HDDのCatalinaで起動して、mSATAをまっさらにフォーマットし直しました。そしてCatalinaからBig Surインストーラを起動して、mSATA SSDにインストールしました。

インストール過程の最初の再起動で、BIOSの警告が出ました。

特に設定はおかしくなってませんでしたし、この先は、警告が出ることはありませんでしたので、このまま続けました。今までのBig Surインストール作業と同様に、最初の2-3回の起動では、macOS Installerという名前のドライブから再起動します。

でも進捗すると、フォーマット時に設定したドライブの名前になってます。

その後、また２回ほど再起動して、設定画面に入りました。

MacBookAir6,1と6,2は、Big Surが動く最古のMacで、4250UはBig Surが公式対応する最弱のCPUと言えます。ギリギリのスペックですが、Big Surは充分にキビキビ動きました。とはいえ、Geekbench 5で、シングル600, マルチ1200と遅いです。これと比較すると、新しいM1のシングル1600, マルチ7200というスコアはすごいですね。

まとめ

Haswell版Intel NUCにも、OpenCore 0.6.3とBig Sur公開版をクリーンインストールしました。Big Surがサポート対象とする最弱Macに相当するスペックですが、問題なく動きました。

Big SurでRadeon RX 5700 XTのスコアが大幅に改善

Sun, 15 Nov 2020 16:46:58 +0900

Big SurになってRadeon RX 5700 XTのGeekbench 5のスコアが格段に改善されました。RX 580と比較するとOpenCLもMetalも1.6倍くらい高いスコアでした。

Geekbench 5ベンチ結果

Catalina (10.15.5および10.15.6)とBig Sur (11.0.1) で、RX 580とRX 5700 XTのOpenCL/Metalスコアを計測しました。いずれもOpenCLとMetalのベンチマークを交互にそれぞれ３回測定し、その結果を平均したものです。測定に使用した本体は、ほぼZ490マザーボードに10900Kの構成ですが、Big SurでのRX 580の測定だけはZ390 + 9900Kの構成です。

Catalinaのスコアは以前の記事などで計測したものです。Catalinaだと、RX 5700 XTはRX 580に比べて同程度か、場合によっては劣っていることもありました。特にMetalの性能が弱い感じでした。本来なら古くて安価なRX 580よりも性能が高いはずなのですが、macOSのドライバの作り込みが不足しているようでした。

Big Surのパブリックベータが出ると状況は変わります。ベータのバージョンが進むたびに、RX 5700 XTのスコアが少しずつ改善されていきました。そして公開版11.0.1では、最後のベータ版からさらに改良されたようで、RX 580に圧倒的な差をつけてます。一方でRX 580は、Catalinaの頃とスコアがほとんど変わっていません。

ちなみに話題のM1のiGPUは、OpenCLが19000くらいのようです。Intel UHD Graphics 630が5000くらいでしたから、iGPUとしては頑張ってますが、ちゃんとしたグラフィックスカードには及ばないようです。

macOSでグラフィックス性能を求めるなら、RX 5700 XTが1番の選択肢と思います。また、他のNaviアーキテクチャのRX 5000シリーズも性能改善されているのではないかと思われます。RX 5000シリーズを使うためには、

WhateverGreen.kext (グラフィックス関係のパッチ集)
Lilu.kext (パッチを当てる機能を提供するkext)

を入れ、CloverやOpenCoreのブートオプションに、WhateverGreenに指示するオプションである、

agdpmod=pikera

を追加します。

Vega 64も性能向上

コメントでyoshiiさんから教えていただいた情報によるとVega 64でも17% ~ 19%くらい改善しているようです。

MacOS 10.15　54050(OpenCL)/52086(Metal)
MacOS 11　64061(OpenCL)/60921(Metal)

リムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)

Sun, 15 Nov 2020 01:10:14 +0900

抜き挿し可能なリムーバブルSATAドライブベイで、HDD/SSDのホットプラグを可能にするパッチを以前ご紹介しました。Big Surでパッチパターンが変わったので、これに対応しました。

5.25インチベイ用リムーバブルHDDラック

上の写真のような、5.25インチベイに取り付けるリムーバブルHDDラックは、本物のMacには無い、自作hackintoshならではの便利な装備です。でもHDDラックを取り付けただけではHDD/SSDのホットプラグが効きませんでした。macOS起動時にリムーバブルベイに装着されているHDD/SSDは認識され、ファインダー上でアンマウントして、安全に取り外すことはできます。しかし、macOS稼動中にHDD/SSDを挿しても認識されません。そこでホットプラグが機能するようにconfig.plistにkextパッチを当て、対応していました。

SATA接続HDD/SSDのホットプラグ

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

このパッチが効くと、マザーボードのチップセットが持っているSATA端子以外、つまり、マザーボード上にSATAチップを追加して増設したSATA端子が、リムーバブルドライブとして扱われるようになります。チップセットがサポートするSATAは通常6個ですので、8個のSATAを持っているマザーボードは、最後の2個が対象になります。また、PCIeスロットにSATAアダプターカードを挿してSATA端子を増設した場合も、そこに接続されるドライブがリムーバブルになります。例えば以下のような、Marvell 88SE9230チップセットや、ASMedia ASM1061チップセットを搭載したカードです。

ところが、Big Surにバージョンアップしたら、このパッチが効かなくなったようで、ホットプラグが機能しなくなりました。調べたところパッチパターンが変わっていたようです。

パッチの方法

パッチは、/System/Library/ExtensionsにあるAppleAHCIPort.kextのバイナリファイルの該当部分を、0x90 (マシンコードでNOP, No OPerationに相当します) に置き換えるものです。置き換える範囲は、ファイルの中の0x40200000というデータ列の4バイト、その前8バイト、その後14バイトの、合計26バイトです。この26バイトのパターンが、Big Surになって変わっていたようで、パッチが効かなくなっていました。

そこで、Big Surのkextの中で0x40200000を探して、書き換えるべきデータ列を調べなおすことにしました。まずは、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをhexdumpして、lessコマンドで表示を一旦停止しておきます。

% hexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less

lessが起動しているところ、以下のサーチコマンドをタイプし、40 20 00 00を探します。

/40 20 00 00

ところが運悪く途中に改行が入っているようで見つかりません。40 20だけでもう一度探索します。

/40 20

今度は見つかりました。改行の先に00 00があるので、間違い無いようです。他にも40 20は見つかりますが、その先に00 00が続く場所はありません。もしもこれで見つからなければ、他の場所に改行が入っているかもしれませんので、

/20 00 00

で探せば良いと思います。

今回、発見できた場所の前後のデータは以下です。

0003da0 01 00 00 89 d1 81 e1 40 60 02 00 81 f9 40 20 00
0003db0 00 75 0c 81 e2 bf 7f ff ff 89 93 69 01 00 00 f6
0003dc0 c2 40 74 7e 3d 09 01 01 00 72 77 44 89 fe c1 ee
0003dd0 0a 81 e6 80 00 00 00 81 e2 7f ff ff ff 89 d1 09

ここで発見した0x40200000の4バイト、その前8バイト、その後14バイトの、合計26バイトをNOP (90) に置き換えるパッチを作ります。つまり、

Find --> 81E14060 020081F9 40200000 750C81E2 BF7FFFFF 89936901 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

というパッチを作ります。前回のパッチパターンに類似していますのでおそらく合っていると思います。

config.plistをテキストエディタで編集する場合はbase 64に変換します。詳しくはこちらをご覧ください。Findするデータはbase 64では以下になります。

% echo -en "\x81\xE1\x40\x60\x02\x00\x81\xF9\x40\x20\x00\x00\x75\x0C\x81\xE2\xBF\x7F\xFF\xFF\x89\x93\x69\x01\x00\x00" | base64 
geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=

Replaceするデータは、NOPコマンド列である9090…なのですが、このbase 64は以下です。

% echo -en "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" | base64
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=

Cloverの場合

最近Cloverは使っていないので検証できませんが、Cloverの場合、config.plistに以下を書けば良いはずです。

<key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>

OpenCoreの場合

OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、使用するキーは以下です。

Comment : Cloverと同じ。人が読むためのメモ書き。
Find : Cloverと同じ。検索データ列。
Replace : Cloverと同じ。置き換えるデータ列。
Identifier : CloverのNameに相当するキー。kextを指定するためのIDで、バンドルIDを使う。
Enabled : パッチを有効にする場合はtrueにする。（有効にしたいのでtrueにする）
Count : パッチを当てる箇所の数。今回の場合は1回なので1。
その他のキー : デフォルトで良いので省略。

kextのバンドルIDは、システム情報で知ることができます。

システム情報の拡張機能のAppleAHCIPortの項目を選択すると、

com.apple.driver.AppleAHCIPort

であることがわかります。これはBig Surになっても変更はありませんでした。そこで、OpenCoreのパッチは以下になります。

<key>Kernel</key>
<dict>
 <key>Patch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Count</key>
 <integer>1</integer>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=</data>
 <key>Identifier</key>
 <string>com.apple.driver.AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>
</dict>

ProperTreeやPlistEDPlusなどのアプリケーションで設定するなら、16進数でそのまま書けます。ProperTreeでは16進数のデータの8バイトごとにスペースを入れる流儀のようですが、

81E14060 020081F9 40200000 750C81E2 BF7FFFFF 89936901 0000

PlistEDPlusではスペースを入れないようです。

81E14060020081F940200000750C81E2BF7FFFFF899369010000

以下はPlistEDPlusの例です。Item番号はたまたま7番目になっていますが、何番目でも大丈夫です。

動作確認

パッチをOpenCore 0.6.3のconfig.plistに追加したところ、Big Surでもこのホットプラグが機能しました。オレンジ色のドライブがmacOS起動後にリムーバブルベイに取り付けた3.5インチHDDです。

補足

最初の記事、

では、

Find --> 40600200
Replace --> 00000000
AppleAHCIPort

というパッチを当てれば、ASMediaやMarvellのチップでホットプラグが可能になるという情報を紹介しました。今回、Big Surで試したところ、マウントする際にシステムが落ちてしまう現象が発生しました。PCIeに挿すASMediaやMarvellのSATAカードでも、ここで紹介した長いパッチは安定して動きますので、この記事の方式を使ってください。

まとめ

リムーバブルドライブベイのホットプラグを可能にするパッチを、Big Sur用に書き換えて動作を確認しました。これからも、しばらくはBig Surへの対応作業を楽しめそうです。

Big Surをクリーンインストールする (OpenCore + Z390)

Sat, 14 Nov 2020 19:24:47 +0900

メインで使っているZ390マシンにmacOS Big Sur 11.0.1をクリーンインストールしました。macOSの本体とユーザディレクトリを別のSSDに分けて入れてありました。そこで、前回作成したインストール用USBを起動し、macOS本体が入っているSSDだけを初期化し、Big Surをインストールしました。

システムの構成

Big Sur公開初日にZ490マシンにクリーンインストールしました。

Big Surをクリーンインストールする (OpenCore + Z490)

2日目の今日は、メインで使用しているZ390マシンにもクリーンインストールします。こちらのマシンです。現在は、OpenCore 0.6.3とCatalinaの最新版が動いています。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

Z490の方は、ほとんどデータがなかったので、クリーンインストールも簡単でした。でもこちらのマシンは、いろいろデータが入っています。Dropbox、iCloud, Timemachineなどでバックアップされているので、最悪、全部消えても困りませんが、できれば残しておきたいです。

幸いなことに、macOSの本体と、ホームディレクトリを別のSSDに置いていました。diskutil listコマンドで見ると、以下のようになってます。（TimemachineやWindowsなどのドライブも接続されているのですが省略しました。なので、番号が飛んでます）

% diskutil list
/dev/disk1 (internal, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *250.1 GB disk1
 1: EFI EFI 209.7 MB disk1s1
 2: Apple_APFS Container disk6 249.8 GB disk1s2

/dev/disk4 (internal, physical):
 #: TYPE NAME SIZE IDENTIFIER
 0: GUID_partition_scheme *960.2 GB disk4
 1: EFI EFI 209.7 MB disk4s1
 2: Apple_APFS Container disk7 960.0 GB disk4s2

/dev/disk6 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +249.8 GB disk6
 Physical Store disk1s2
 1: APFS Volume Mojave 56.6 GB disk6s1
 2: APFS Volume Preboot 127.3 MB disk6s2
 3: APFS Volume Recovery 1.0 GB disk6s3
 4: APFS Volume VM 2.1 GB disk6s4
 5: APFS Volume Macintosh HD - Data 139.8 GB disk6s5
 6: APFS Volume Macintosh HD 12.2 GB disk6s6

/dev/disk7 (synthesized):
 #: TYPE NAME SIZE IDENTIFIER
 0: APFS Container Scheme - +960.0 GB disk7
 Physical Store disk4s2
 1: APFS Volume home 830.7 GB disk7s2
 2: APFS Volume Preboot 20.5 KB disk7s3
 3: APFS Volume Recovery 20.5 KB disk7s4
 4: APFS Volume VM 2.1 GB disk7s5

物理ディスクは

disk1 (250GBのM.2 SSD) と
disk4 (960GBのSATA SSD)

です。

disk1 (250GB SSD) には、APFSコンテナである
- disk6が作られていて、現用のCatalinaの論理ボリューム (Macintosh HD – DataとMacintosh HD) と、先代のMojaveの論理ボリュームがあります。
disk4 (960GB SSD) には、APFSコンテナである
- disk7が作られていて、homeという論理ボリュームがあります。ここには、ホームディレクトリのデータを置いてあります。

つまり、disk1および6がある250GB SSDには、macOS本体と、後から追加したドライバーやアプリケーション類が入っています。最近はパッケージで買うアプリケーションは皆無になりましたので、いずれもネットから再ダウンロードすれば良いものです。なので、250GB SSDの論理ボリュームは全部消去しても困らないと考えました。また、250GB SSDのESPには、OpenCore類が一式入っています。これは残しても良いのですが、サイズは小さいので、バックアップしていてから、SSD全体を削除して、その後復活させることにしました。

USBインストーラを起動

昨日の記事で作ったUSBインストーラを使います。まずは、このUSBメモリのESPの部分に、現在使用しているdisk1のEFIをコピーしておきます。これでUSBメモリから起動できます。disk1から起動することも可能ですが、これから消去する予定なので、ここでバックアップしておきます。

これでBIOSでUSBインストーラを指定して起動できます。昨日のZ490へのインストールの時は復旧（Revoery）画面が日本語でしたが、今回はなぜか英語画面でした。

クリーンインストールする

まずはDisk Utilityを選んで、250GB SSDを綺麗に全消去します。

ここでEraseボタンを押したら元には戻れません。ひたすら進むだけです。Disk Utilityを終了して、最初の画面に戻り、Install macOS Big Surを選びます。

さらに、インストール先に、先ほどフォーマットしたボリュームを選び、インストールを開始します。

この先は、前回と同じく、数回ほど再起動しつつ、インストールが進んでいきます。インストールが一通り終了すると、国選択の画面になります。

この後、いくつかの設定をすればインストール完了です。

USBメモリのESPの内容を、M.2 SSDの方に書き戻しておけば、SSDで起動するはずです。

ホームディレクトリを復活

インストール直後は、インストール先の/Users以下にホームディレクトリがあります。クリーンインストールしたので中身は空です。そこで、今まで使っていた2.5インチSSDの場所にあるディレクトリに、ホームディレクトリを移動します。「システム環境設定」「ユーザとグループ」で「変更するにはカギをクリックします。」を選び、自分のユーザアカウントの上で右クリックして、「詳細オプション…」を選べば、ホームディレクトリを元の場所に戻せます。これで再起動すれば、Catalinaで使っていたファイルが全て使えます。

まとめ

OpenCoreで起動しているZ390マシンにBig Surをクリーンインストールしました。ホームディレクトリをmacOSとは別のSSDに入れてありましたので、それを残しつつ作業しました。

Big Surをクリーンインストールする (OpenCore + Z490)

Fri, 13 Nov 2020 23:56:37 +0900

macOS Big Sur 11.0.1の配布が開始されました。早速、Catalinaからアップデートしました。最新版のOpenCore (0.6.3) とkext類でCatalinaが動いていれば、通常の作業でアップデートできるようです。

システムの構成

本日 (日本時間2020/11/13)、macOS Big Sur 11.0.1 の配布が開始されました。過去のメジャーアップデートのナンバリング方式から、最初に出るのは11.0だと思ってましたが、今回は最初から11.0.1でした。インストール先のマシンは、こちらです。Z490マザーボードに10900Kを搭載しています。グラフィックスはRadeon RX 5700XTです。

ASUS ROG STRIX Z490-G, 10900K

このマザーボードに取り付けたWestern Digitalの250GB M.2 SSD, WD BLACK SN750 NVMeにクリーンインストールしました。SSDには、OpenCore 0.6.3と最新のkext類が入っていて、Catalina 10.15.7が動いています。diskutil listコマンドで見ると以下のようになっています。

% diskutil list
/dev/disk0 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *250.1 GB disk0
1: EFI ⁨EFI⁩ 209.7 MB disk0s1
2: Apple_APFS ⁨Container disk1⁩ 249.8 GB disk0s2

/dev/disk1 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +249.8 GB disk1
 Physical Store disk0s2
1: APFS Volume ⁨Macintosh HD - Data⁩ 32.6 GB disk1s1
2: APFS Volume ⁨Preboot⁩ 83.6 MB disk1s2
3: APFS Volume ⁨Recovery⁩ 528.9 MB disk1s3
4: APFS Volume ⁨VM⁩ 2.1 GB disk1s4
5: APFS Volume ⁨Macintosh HD⁩ 11.2 GB disk1s5

disk0s1がESPです。disk0s2にAPFSコンテナが作られていて、この中に論理ディスクdisk1があり、その中にCatalina一式が入っています。Macintosh HDがシステムの中核部分で、簡単には書き換えられないよう保護されています。Macintosh HD – Data⁩がその他のシステムとユーザのデータです。PrebootはFileVault用のボリューム、Recoveryはリカバリーモードで起動するためのボリューム、VMは仮想メモリー用のボリュームです。

アップデートの手順

せっかくのメジャーアップデートなので、現在のM.2 SSDは綺麗さっぱりと全消去して、クリーンインストールしようと思います。なので次の手順でアップデートを進めます。

disk1のCatalinaでBig Surインストーラをダウンロードする
USBメモリを用意してBig SurインストールUSBを作る
USBメモリのESPにdisk1のESPをコピーして起動できるようにする
USBメモリーからインストーラを起動する
インストーラからディスクユーティリティを起動し、disk1を消去する
インストーラからBig Surをdisk1にインストールする

1. Big Surインストーラをダウンロード

Catalinaを起動して、「システム環境設定」「ソフトウェアアップデート」を開いて、Big Surをダウンロードします。12.18GBあるようです。公開直後はネットが混み合ってダウンロード困難だったらしいですが、30分くらいでダウンロードできました。

ダウンロードするといつものように自動的にインストーラが開きます。ここではインストールしないので、インストーラは一旦終了します。

2. Big SurインストールUSBを作る

インストーラ用のUSBメモリを用意します。32GBはあった方が良いです。今回は32GBのUSB 3.0メモリーを用意しました。起動速度がとても遅くなってしまいますがUSB 2.0メモリーの方が確実です。今回は設定済みのESPがあるので問題ありませんが、未知のマザーボードの場合、USBの15個制限の影響で、USB 3.0ポートがUSB 2.0として動いてしまうことがあります。その場合、BIOS起動時は3.0だったポートが、macOSに制御が切り替わった途端に2.0に変貌してしまうので、起動作業が止まってしまうのです。（config.plistで15個制限を外しておくという方法もありますが）

USBメモリをHFS+で初期化する

次に、USBメモリーをディスクユーティリティ.appを使って初期化します。ディスクユーティリティ.appのデフォルトではボリュームのみが表示されますので、まずは、メニューバーの表示から「すべてのデバイスを表示」を選んでおきます。

こうすると、USBメモリ製品名が入ったデバイス名がウィンドウ左側リストに現れますので、これを選択します。今回はJetFlash Transcendという製品名を選択しています。次に消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここでAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。Mac OS拡張（ジャーナリング）を選んでおく必要があります。

次に、Big SurインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもBig SurをインストールできるUSBメモリになります。ターミナルを使用して、Big Surインストーラの中のContents/Resourcesに移動して、lsするとcreateinstallmediaというファイルが見つかるはずです。

$ cd /Applications/Install\ macOS\ Big\ Sur.app/Contents/Resources/
$ ls create*
createinstallmedia

これを使用して、macOSインストールUSBメモリを作成します。とりあえず起動すると、ヘルプ情報が表示されます。

$ ./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

downloadassetsオプションは、起動用USBメモリを作成する場合に、最新ファームウェアやApple T2チップ用ファームウェアをダウンロードする機能のようです。Hackintoshでは不要な機能なので使わないでおきます。–volumeオプションでは、先ほど作成したUSBメモリへのパスを書いておきます。ということで、以下のコマンドを入力します。

% sudo ./createinstallmedia --volume /Volumes/USB/

sudoしているのでパスワードを求められます。その後、確認を求められるのでyを押します。そうするといろいろ進捗して終了します。

Password:
Ready to start.
To continue we need to erase the volume at /Volumes/USB.
If you wish to continue type (Y) then press return: y
Erasing disk: 0%... 10%... 20%... 30%... 100%
Copying to disk: 0%... 10%... 20%... 30%... 40%... 50%... 60%... 70%... 80%... 90%... 100%
Making disk bootable...
Copying boot files...
Install media now available at "/Volumes/Install macOS Big Sur"

これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。

3. USBメモリのESPにdisk1のESPをコピーする

4. USBメモリーからインストーラを起動する

これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにBig Surインストーラが見えるはずです。

まず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。
また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。

なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はProperTreeを使って変更している様子です。

これで起動項目にUSBメモリのインストーラが現れるようになります。Big Surアイコンのボリュームが、USBメモリーです。このInstall macOS Big Surを選択して起動します。

5. インストール先ボリュームを消去する

USBメモリから起動すると、復旧 (Recovery) というアプリケーションが起動します。

Time Machineから復元する、macOS Big Surインストールする、Safari (を開く)、ディスクユーティリティ（を開く）、の選択が可能になります。この他、メニューバーの「ユーティリティ」から、「起動セキュリティユーティリティ」と「ターミナル」が選べます。「起動セキュリティユーティリティ」は、Apple T2チップ用の機能と思われます。hackintoshでは関係ないです。

今回はクリーンインストールを目指すので、Catalinaが入っているdisk 1を消去します。ディスクユーティリティを開き、全てのドライブを表示するようにし、Catalinaが入っているドライブを選択して、消去します。

名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。

6. Big Surをインストールする

Disk Utilityを閉じると、またRecoveryのメニューに戻ります。次にInstall macOS Big Surを選択します。するとおなじみのBig Surインストーラが起動します。後は、いつものようにインストールを進めていくだけです。

インストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。（ここでもう一つ見えているアイコンはUSBメモリです）

17分くらいでインストールできるそうです。

でも17分も経たないうちに（多分5~6分）、再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。

次は30分程度のようです。

この後、30分も経たないうちに（これも多分5~6分くらい）また再起動しました。またmacOS Installerが選択されてます。

そして数分でまたまた再起動。今度は、インストール先ドライブにつけた名前 (Macintosh HD) の選択肢が現れ、選択されています。これで起動します。

さらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。

あとはいつものように、設定を行なっていくだけです。

インストール終了したあと、このMacについてを確認すると、バージョンは11.0.1 (20B29) でした。Geekbenchブラウザに出回っている情報によると、M1搭載MacBook Airなどと同じOSが搭載されているようです。

USBメモリのESPの内容を、M.2 SSDの方に書き戻しておけば、SSDで起動するはずです。

まとめ

OpenCoreで起動しているZ490マシンにBig Surをクリーンインストールしました。そのために、単体で起動してBig SurがインストールできるUSBメモリを作りました。以前のバージョンの場合と手順は同じです。ベータ版で予行演習していたこともありますが、スムーズにBig Surに移行できました。

macOS Big Sur 11.0.1 RC 2をインストール

Thu, 12 Nov 2020 00:42:55 +0900

macOS Big Sur 11.0.1 RC 2 (Release Candidate 2) が、パブリックベータとして公開されたので、11.0.1 RCからアップデートしました。ビルド番号は20B28です。システム環境設定のソフトウェア・アップデートから簡単にアップデートできました。Big Surの公式リリースの2日前に配布されたということは、最初のBig Surはこれではなくて、順当に11.0なのかもしれません。いずれにしても11.0.1もすぐに出そうです。

11.0.1 RC 2にアップデートする

前回の記事で11.0.1 RCを入れたZ490マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0.1 RCをインストール

のソフトウェアアップデートにmacOS Big Sur 11.0.1 RC 2の案内が来ていました。ネット上のニュースでは開発者向けに公開されたと書かれていましたが、Public Betaとしても公開されたようです。

OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.3
kext類は一般公開されている最新のもの
機種設定はiMac20,1

「今すぐアップデート」ボタンをクリックすると、3.22GBのファイルがダウンロードされ、その後、3回くらい再起動してインストールが終了し、macOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、20B28になっていることを確認できます。RC 2 になって、Betaという文字が消えてますし、ビルド番号もクリックしないと現れなくなりました。公開を見越したバージョンになっていると思いました。

ちなみに発表されたばかりのMacBook Airに搭載されるBig Surは、Geekbenchブラウザによると20B29のようです。

Apple Payでお買い物する

Sun, 08 Nov 2020 00:18:18 +0900

Apple Storeのページの買い物を、macOSからApple Payで手続きしました。iPhoneで認証する必要があり、また何回か試行錯誤しましたが支払いできました。

使用したマシン構成

Apple Storeサイトで買い物をしようとしたら「Apple Payで注文手続きを行う」というボタンがありました。これで支払いができるのかどうか、試してみました。

使用したハードウェアは、ASUSのZ390マザーボード、9900K、Radeon RX580の構成です。マザーボードのPCIeスロットに、Broadcom BCM94360CDを搭載したWiFi/Bluetoothカードを取り付けています。macOSはCatalina 10.15.7で、OpenCore 0.6.3でブートしています。機種IDはiMac19,1に設定してあります。

Apple Pay使用可能なMac

Apple Payは、Suicaやクレジットカードなどを紐付けたiPhone/Watchで、非接触で支払いができる機能です。用途が限定されますがMacでも使えることになってます。Macの場合、web上で支払いができます。対象は2012年以降に発売されたMacです。iMac19,1は問題ないですし、BCM94360CDも2013年モデルから採用されているので大丈夫と思いました。

また、Apple Payのサイトには、「Touch IDを搭載したMacBook AirとMacBook Proではワンタッチで支払いが完了。」と書いてあります。指紋認証機能が未搭載のMacでは、ワンタッチでは完了しないという意味に読み取れます。そのようなMacでは本人認証にiPhoneを使用するようです。

iPhoneを接続する

「Apple Payで注文手続きを行う」ボタンをクリックしたところ、iPhoneをBluetooth接続するように指示されました。指紋認証があるMacだと、もしかしたらiPhoneは不要なのかもしれません。

そこで、iPhoneを動作させて近くに持ってきたのですが、Bluetooth接続に失敗しているようです。最近のBluetoothでは、ペアリング画面が表示されている時だけ、ペアリングのための情報をブロードキャストするらしいです。ということで、iPhoneの「設定」「Bluetooth」画面を開きました。Bluetoothはすでにオンになってましたが、この画面を開くことでペアリングが可能になるようです。次のステップに進みました。

クレジットカードで支払う

iPhoneに接続できると、次に支払いカードの選択画面になります。カードの請求先を選択することもできます。

と同時に、iPhoneにもApple Payの画面が現れて、右ボタンダブルクリックで承認できるようになってます。ここでiPhoneで承認すれば、支払い処理が終了するようでした。

ただ、最初のうちは、「請求先住所が無効です」とか「このカードはウェブ支払いに使えません（この通りの文言では無かったです）」というようなメッセージが出て、処理が進みませんでした。

iPhone側では、WalletアプリでApple Payで使うクレジットカードを登録します。この情報を確認したところ請求先住所が未登録でした。Macの画面でも請求先を指定できるのですが、iPhone側でも登録する必要があるのかもしれません。また、MasterCard系のクレジットカードではなかなか処理が進みませんでしたが、JCB系のカードに切り替えたらすんなり進みました。ということで、何回か試行錯誤した結果、結局は支払いに成功しました。失敗したケースでは、カードの設定か手続きが不十分だったように思います。JCB系のカードではすぐに承認されたので、Hackintoshだからダメだったという様子ではないです。

ということで無事、Apple Payでお買い物ができました。ちなみに買ったのは、HomePod miniです。最近は、近所のファミリーマートで受け取りができるんですね。これはありがたいです。

macOS Big Sur 11.0.1 RCをインストール

Fri, 06 Nov 2020 22:50:14 +0900

macOS Big Sur 11.0.1 RC (Release Candidate) が、パブリックベータとして本日公開されたので、11.0.1 Betaからアップデートしました。ビルド番号は20B5022aです。システム環境設定のソフトウェア・アップデートから簡単にアップデートできました。RCは、問題がなければこのまま正式リリースになるバージョンです。11.0が出ることなく、最初のBig Surは11.0.1になるのかもしれません。

11.0.1 RCにアップデートする

前回の記事で11.0.1 Betaを入れたZ490マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0.1 Betaをインストール

のソフトウェアアップデートにmacOS Big Sur 11.0.1 RCの案内が来ていました。ネット上の多数のニュースでは開発者向けに公開されたと書かれていましたが、Public Betaとしても公開されたようです。（パブリックベータ版のスクリーンショットは公開してはいけないらしいので、前回同様に加工しました。）

OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.3
kext類は一般公開されている最新のもの
機種設定はiMac20,1

「今すぐアップデート」ボタンをクリックすると、2.8GBのファイルがダウンロードされ、その後、2回再起動してインストールが終了しました。その後、macOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、20B5022aになっていることを確認できます。

Intel NUCもアップデート

以下で、HaswellベースのIntel NUCにBeta 9とBeta 10をインストールした記事を書きました。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

さらに11.0.1 Betaにしていました。このマシンにも11.0.1 RCのアップデートのお知らせが来ていたので、アップデートしたところ、問題なく起動しました。これもOpenCoreは0.6.3です。

OpenCore 0.6.2から0.6.3に更新

Tue, 03 Nov 2020 19:35:58 +0900

OpenCoreの0.6.3が公開されたので0.6.2からアップデートしました。差分は少ないので新しくなったファイルを差し替えるだけで移行できると思います。Big Surがいつ公開されてもこれで大丈夫と思います。

0.6.3をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

.efiファイルを差し替える

前回のアップデートからは古いIA32アーキテクチャ用バイナリーが追加されましたが、今回も同様です。最近のCPU/macOSを使うならIA32フォルダは無視して、X64の方のフォルダの中身を、現用のファイルと入れ替えれば良いです。

前回0.6.1から0.6.2へアップデートした時と同じ作業を行いました。現在0.6.2が動いている状態ですので、現在のESPに含まれる.efiファイルを、0.6.3のものに差し替えます。以下のスクリーンキャプチャは前回のアップデートのものですが、同じなので流用します。まずはBOOTの中のBOOTx64.efiを差し替えます。

次に、OC直下のOpenCore.efiです。

また、OC/Bootstrap/の中のBootstrap.efiも差し替えます。

OC/Driversの中のうち、現在使用しているものだけを差し替えました。手元のマシンでは、OpenCanopy.efiとOpenRuntime.efiだけを使っているので、それを差し替えました。OpenRuntime.efiが一番重要ですね。

OC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。

PlistEDPlusを使ってみる

今回、config.plistを編集するにあたり、Mifjpnさんのサイトで紹介されていたPlistEDPlusというXMLエディタを使ってみました。

Releases · ic005k/PlistEDPlus

ミニマムなデザインのProperTreeと比べて、アイコンが並んでいて賑やかです。タブでファイルを切り替えられるので、新旧のconfig.plistを切り替えて比較するのが楽でした。下は、0.6.2のconfig.plistと、OpenCore 0.6.3に付属してきたSample.plist（をコピーしてconfig063.plistという名前に改名したファイル）を開いているところです。

一般的なXMLエディタなので、ProperTreeにあるKexts, ACPI, Toolsフォルダをスキャンしてその記述を追加してくれるようなOpenCoreに特化した機能はありません。でも今回は前バージョンで動いているconfig.plistがあるので、その機能は使いません。

0.6.3での変更点

今回アップデートしたマシンは、Coffee Lake-S + CatalinaとComet Lake-S + Big Sur 11.0.1 Betaです。Change logを見たところ、この環境で対処すべき項目は見つかりませんでした。すでに0.6.2で問題なく動いているなら、config.plistがそのまま使えて、変更は不要なようです。

PlatformInfoの中にメモリを設定する項目が追加されてます。特に、Memory Propertiesという一連の項目ができました。メモリーのデータ幅、ECCの有無、DIMMなのかSODIMMなのか、最大容量、DDR2,3,4などの指定ができるようです。「このMacについて」でメモリ情報が正しく現れない場合や、ECC付きなどの特殊なメモリを使う場合に必要なのかもしれません。Sample.plistにもMemory Propertiesは設定されてないので、設定が必要な場合はあまりないと思われます。

UEFIのOutput PropertiesにForceResolutionという項目ができました。Intel GMAや第1世代のIntel HD Graphics向けのようです。KernelのQuirksの中にForceSecureBootSchemeができたくらいです。説明を見ると仮想マシン向けの設定です。いずれも今回の環境には関係ありませんでした。

Big Sur Beta 10以降では、SecureBootModelをDisabledにしないとカーネルパニックする現象がありました。これが0.6.3で改善されたようです。11.0.1 RCで試したところ、SecureBootModelのデフォルト値であるDefaultのままで、問題なく起動しました。

Config.plistはこちら

OpenCoreに付属のSample.plistに、0.6.2で使用していたconfig.plistの内容を反映させました。新しく追加された項目は、全てデフォルト値のままです。その結果、ASUS Z390 ROG MAXIMUS XI + 9900K + RX580の構成のconfig.plistはこのようになりました。

config.plist for ASUS Z390 OC060 - Pastebin.com

ASUS Z490G + 10900K + RX5700XTの構成のconfig.plistは以下です。

config.plist for ASUS Z390 OC060 - Pastebin.com

いずれもPlatformInfoの項目は未記入ですので、macserialなどを使って生成してください。

macOS Big Sur 11.0.1 Betaをインストール

Fri, 30 Oct 2020 18:49:45 +0900

Big Sur 11.0.1 Betaがパブリックベータとして本日公開されたので、11.0 Beta 10からアップデートしました。ビルド番号は20B5012dです。簡単にアップデートできました。今までのPBではmacOSインストーラが起動したのですが、今回は単に1回再起動しただけでした。11.0正式版が出ない状況で11.0.1 Betaが出るのは珍しいことかと思います。11.0正式版リリースは近いと思いました。

11.0.1 Betaにアップデートする

前回の記事で入れた11.0 Beta 10マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0 Beta 9 をインストール

のソフトウェアアップデートにmacOS Big Sur 11.0.1 Betaの案内が来ていました。（ベータ版のスクリーンショットは公開してはいけないらしいので、前回同様に加工しましたw）

OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.2
kext類は一般公開されている最新のもの
機種設定はiMac20,1

「今すぐアップデート」ボタンをクリックすると、「アップデートするには、Macを再起動する必要があります。」というメッセージが出ます。ここで再起動を選択すると、アップデートが始まります。

再起動の後、ダウンロードが始まり、しばらくしてmacOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、11.0.1になっていることを確認できます。

ちなみに、ベータ版一般の注意なのですが、デフォルトで「Mac解析を共有する」設定になっています。Hackintoshの不具合情報をアップルに送付しても、どちらにとっても無意味なことですので、システム環境設定–>セキュリティとプライバシー–>解析と改善を選んで無効にしておきましょう。

5700XTのMetal性能が微増

このマシン (Z490 + 10900K) にはRadeon 5700XTを取り付けてあります。その性能をGeekbench 5で測定しました。下のグラフはCatalina 10.15.6、Big Sur Beta 6、Beta 9、Beta 10、11.0.1 Betaでの比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。

Betaが出るたびに改良されてきた5700XTのスコアは、今回はほぼ据え置きのようです。ただ、Metalに関しては、測定ばらつき以上に微増していて、まだまだ改良されているようです。macOS開発チームの5700XTへの愛が垣間見える気がしました。

Intel NUCもアップデート

以下で、HaswellベースのIntel NUCにBeta 9とBeta 10をインストールした記事を書きました。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

このマシンも11.0.1にアップデートしてみました。問題なく起動しました。

macOS Big Sur 11.0 Beta 10 をインストール

Sat, 17 Oct 2020 17:04:59 +0900

Beta 10がパブリックベータとして昨日公開されたので、Beta 9からアップデートしました。ビルド番号は20A5395gです。RX 5700XTの性能が更に向上しました。Beta 10を起動させるために、config.plistのSecureBootModelをDisabledに設定する必要がありました。

Beta 10をダウンロードする

前回の記事で入れたBeta 9マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0 Beta 9 をインストール

のソフトウェアアップデートにmacOS Big Sur Betaの案内が来ていました。（ベータ版のスクリーンショットは公開してはいけないらしいので、詳細がわからないように加工しましたw）

OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.2
kext類は一般公開されている最新のもの
機種設定はiMac20,1

「今すぐアップデート」ボタンをクリックすると、「このシステムでアップグレードするには、フルインストーラが必要です。」というメッセージが出ます。

アップデートできないのかなと思って、諦めてOKボタンを押したら、親切なことに、「macOS Big Sur Beta 11.0をダウンロードしてもよろしいですか？」というダイアログが出ました。

ダウンロードボタンを押したら、12.21GBのフルインストーラーがダウンロードされました。

Beta 10をインストールする

ダウンロード後に、いつもと同じようにBig Surのインストーラが起動します。

そのままインストールを続けました。途中で2回、再起動しました。再起動の時の一時的なボリューム名は、「macOS Installer」になり、わかりやすくなりました。

**（追記）**以下の、起動に失敗する問題はOpenCore 0.6.3で修正されたようです。SecureBootModelはデフォルトのDefaultのままで起動します。

この後、インストールが終了したらしい状態になりましたが、起動しなくなりました。カーネルパニックが発生しているのか、メモリーパニックという表示で再起動を繰り返すようになってしまいました。

~~フォーラムで、須磨の辰五郎さん、Mifjpnさんから、~~

~~Misc – Security – ExposeSensitiveData を 3 にする~~
~~Misc – Security – DmgLoading を Any にする~~
~~Misc – Security – SecureBootModel を Disabled にする~~
~~NVRAM – Add – csr-active-config を 00000000 にする~~

の4点に気をつけるとBeta 10が起動すると教えていただきました。このうち1.と4.は対応済みでした（1.は7にしてます）。また、DmgLoadingはデフォルトのSignedでも大丈夫でした。ということで、

~~Misc – Security – SecureBootModel を Disabled にする~~

~~だけを対応したところ、無事、Beta 10が起動しました。~~

5700XTの性能がまたまた向上

このマシン (Z490 + 10900K) にはRadeon 5700XTを取り付けてあります。その性能をGeekbench 5で測定しました。下のグラフはCatalina 10.15.6、Big Sur Beta 6、Beta 9、Beta 10での比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。

これを見ると、5700XTの性能がまたまた向上した様子です。OpenCLもMetalもどちらも、明らかにRX 580のスコアを上回ってます。これからは、5×00シリーズの時代なのかもしれません（もう生産終了らしいですが）。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

Mon, 12 Oct 2020 00:29:02 +0900

昔作った、Haswell世代Core i5-4250U搭載Intel NUCをOpenCoreとBig Sur (Beta 9) にアップデートしました。Ivy Bridge搭載初代NUCの代わりに省電力サーバとして使いたいと考えてます。

Intel NUC D54250

Intel NUCは、ノートPC用CPUを搭載したデスクトップです。低消費電力なので電源を入れっぱなしの家庭用サーバに向いていると思います。今までは、サーバとしてIvy Bridge搭載の初代NUCを使っていました。でもBig Surでサポートされなくなるので、Haswell搭載のD54250に更新することにしました。D54250には、すでにMojaveを入れてあったのですが長らく放置してました。押し入れから引っ張り出して、CloverからOpenCoreに差し替えて、Big Surに備えることにしました。

Intel NUC D54250, 4250U

Intel NUC D54250が搭載するCore i5-4250Uは、MacBookAir6,1, 6,2で使用されているCPUで、macOSとの互換性が高く安定しています。Big Surでもサポートされます。D54250には2種類のケースがあり、末尾がWYKのモデルは薄型筐体で、WYKHは2.5インチドライブを内蔵できる厚型モデルです。古いので探せば安価に入手可能です。WYKHはドスパラで一時期税込3万円未満で売られていましたし、現在は中古店で2万円くらい、オークションでは1万円前後で入手可能なようです。

ハードウェアの構成をまとめると以下です。

Intel NUC D54250WYKH (WYKHの他にWYK, WYBがあります。WYKは2.5inchの入らない薄型。WYBは基板だけです。)
CPUはIntel(R) Core(TM) i5-4250U CPU @ 1.30GHz
グラフィックスはIntel HD Graphics 5000 (稀にアーティファクトが出ます)
無線カードはです。WiFiはOOBです。Bluetoothは後で説明するようにkextが必要です。

シリアル番号にこだわる

昔に割り当てたシリアル番号には、今から見るといろいろ疑問なところがあったので、変更しました。まず機種IDは、4250Uが搭載されているMacBookAir6,2にしました。6,1でもほぼ同じなので、どちらでも良いです。OpenCoreの一式に入っているmacserialコマンドで機種を指定すると、シリアル番号とボードシリアル番号の候補が出ます。

 % ./macserial --model MacBookAir6,2
C02L20YVF5V7 | C02328501GUFD47JA
C02NLHYMF5V7 | C02443100J9FD471M
C02NNLZBF5V7 | C02445802GUFD47JA
C02MT0WEF5V7 | C02423500GUFD47AD
C02KGYYNF5V7 | C02312301QXFD471M
C02P3QYNF5V7 | C025022004NFD47FB
C02ND4Y8F5V7 | C02437303QXFD478C
C02M20CTF5V7 | C024011304NFD471H
C02NMFYJF5V7 | C02444501CDFD47UE
C02MNSZ6F5V7 | C02418301J9FD47AD

この中から一つを選べば良いのですが、念のためにその一つの詳細を調べてみます。

% ./macserial --info C02P3QYNF5V7
Country: C02 - China (Quanta Computer)
Year: P - 2015
Week: 3 - 3 (15.01.2015-21.01.2015)
Line: QYN - 2742 (copy 1)
Model: F5V7 - MacBookAir6,2
SystemModel: MacBook Air (13-inch, Mid 2013)
Valid: Possibly

製造週が2015年の第3週になってます。MacBookAir6,1, 6,2は2013年6月から2015年3月まで製造されたのですが、2014年4月に4250Uから4260Uにマイナーアップグレードされています。なので同じMacBookAir6,2用のシリアルでも、できれば2013年6月から2014年4月までの番号にしたいところです。ということで、macserialで製造年を2013、製造週を30に指定し、シリアル生成します。

./macserial --model MacBookAir6,2 --year 2013 --week 30
C02L40WPF5V7 | C02330701QXFD471M
C02L4LYLF5V7 | C023303064NFD471M
C02L4YYTF5V7 | C023309024NFD47FB
C02L4BZFF5V7 | C02330102GUFD47FB
C02L40S8F5V7 | C023303064NFD471M
C02L4XZEF5V7 | C02330101QXFD47UE
C02L4TY0F5V7 | C02330405CDFD47AD
C02L40ENF5V7 | C02330403GUFD471F
C02L4069F5V7 | C02330102GUFD47FB
C02L40FQF5V7 | C023303064NFD471M

このうちの一つを–infoオプションで調べてみると、2013年の30週（2013年7月23日から2013年7月29日）でした。発売されて1ヶ月後くらいなので妥当な製造日だと思います。

シリアル番号の特定の4桁部分、上の例では、F5V7とFD47は機種特有の番号です。macserialのソースコードを見ると、他にも多数の選択肢があるのですが、オプションで指定しないとこの番号しか生成されません。このF5V7が4250U搭載の2013年版MacBookAirなのかどうかは、すぐに調べる方法がなさそうでした。ただ、Appleのサイトでシリアル番号が有効かどうかを調べたところ、たまたま実機と同じシリアル番号が見つかりました。（実機と合致する番号は使ってはいけないです）

これから、F5V7はMid 2013の4250U搭載モデルの番号と考えて良いと思いました。

BIOSをアップデートする

このNUCでは起動時に時々「CMOSのチェックサムがおかしい」というメッセージがBIOS起動画面に出ました。ボタン電池を外して放置しても出てくるので、BIOSが壊れかけている疑惑もありました。なので、この際、アップデートすることにしました。現在のBIOSは、昔メンテナンスした時にアップデートしたWYLPT10H-86A.0045というバージョンでした。

インテルのサイトで調べたところ、2019年9月2日に最新のBIOSが出ていて、それは、WYLPT10H-86A.0054でした。早速ダウンロードして、USBメモリーに入れて、BIOS起動画面からアップデートしました。

https://downloadcenter.intel.com/ja/download/29075/BIOS-WYLPT10H-?product=76977

NUCのBIOSアップデートにはちょっとした注意点があります。アップデートが一段落すると、画面に、「正常にアップデートされました」という表示が出て、そのまま動かなくなります。Ivy BridgeモデルのNUC BIOSをアップデートした時に、しばらく放置しても何の変化もなかったので、ここでリセットすれば良いのかと思い電源を切ったことがありました。すると2度と起動しなくなりました。（このNUCをしばらく放置していたら起動するようになってました。理由は不明ですが、バックアップされていた設定が消えて起動できるようになったのかもしれません。）なので重要なことは、「正常にアップデートされました」という表示が出ても、自動的に再起動されるまで辛抱強く待つということです。2〜3分くらい待たされる感じがします。

OpenCore 0.6.2を入れる

シリアル番号をより正しいものに変更し、BIOSを最新にアップデートした後、入っているCloverも最近のもの (5122) に入れ替え、macOSも最新の10.15.7 (19H2) にアップデートしました。問題なく稼働しているのですが、Big Surへの移行準備のために、ブートローダをOpenCoreに入れ替えることにしました。

まずはダウンロードしたOpenCore 0.6.2のX64フォルダにあるEFIフォルダを、ESPにコピーします。次に以下のガイドに従って、設定を進めます。

Desktop Haswell and Broadwell | OpenCore Install Guide

ACPIフォルダの中には、以下の二点が必要です。

SSDT-PLUG.aml
SSDT-EC-DESKTOP.aml

CPU毎に必要なamlのリストは以下でまとめられています。

What SSDTs do each platform need | Getting Started With ACPI

ここで必要とされているデスクトップ用SSDT-EC.amlはこちらのサイトからダウンロードしました。そこでのファイル名がSSDT-EC-DESKTOP.amlとなってましたので、名前をそのまま使うことにしました。

Kextフォルダの中は、今回は以下にしました。

WhateverGreen.kext
VirtualSMC.kext
SMCSuperIO.kext
SMCProcessor.kext
Lilu.kext
IntelMausi.kext
AppleALC.kext

SMC….kextはハードウェアモニター用なのでなくても良いです。

config.plistの内容は、上記のガイドのページに従って設定しました。説明を読めば、どれが必要か判断できると思います。DevicePropertiesの箇所には、

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>AwAiDQ==</data>
 </dict>

を加えました。Intel HD Graphics 5000を表示用に使用する設定です。また、

<key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
 <dict>
 <key>layout-id</key>
 <data>AQAAAA==</data>
 </dict>

も加えました。オーディオのレイアウトIDを1番に設定する記述です。Pci(0x1b,0x0)のPci番号は、Hackintoolを使って、そのPciタブからPCIデバイス一覧を見て、このIOReg NameにHDEFとある行を探して、HDオーディオデバイスを特定しました。

レイアウト番号はとりあえず1番からテストしようとしたら、1番で正解でした。前面のヘッドフォン端子から音が出ることを確認しました。

Sample.plistの初期設定でKext Updater.appを起動すると、「Misc, Security, ExposeSensitiveDataの1, 2ビットをonにする」ように指示が出ます。デフォルトではExposeSensitiveDataが6だったので7にしました。

このNUCには、前面にUSB 2.0端子が2個、背面にUSB 3.0端子が2個あります。また内部のmini PCIeソケットには、USB 2.0が1個あります。さらに、ケースに配線の余裕が無いので使うことはないですが、基板上にUSBコネクタがいくつかあります。ただ、それらを全部加えても15個のようです。なのでconfig.plistのXhciPortLimitで15個制限を外したり、15個制限に対応するkextを作ったりする必要は無いです。

Big Sur beta 9を入れる

Big Surベータ9を入れました。MacBookAir6,1と6,2は、Big Surが動く最古のMacです。また4250UはBig Surが公式対応する最弱のCPUと言えます。ギリギリのスペックでしたが、インストールは、インストーラを起動するだけで簡単でした。インストール途中の再起動では、macOS Installerというドライブが現れて選択されていました。インストール後の動作も問題ありませんでした。ベータ9は安定していて充分にキビキビ動くので、完成度は高いと思います。

Geekbenchをしてみたところシングル600, マルチ1200台程度でした。遅いですね。Apple Silicon搭載Mac miniが800/2900くらいと言われてますので、完全に負けてます。（追記：Apple Silicon搭載Mac miniが発売された後、スコアが明らかになりました。1680/7400くらいのようです。圧倒的に負けてました。）

ちなみに同じ4250U搭載のMacBook Air Mid 2013のスコアも大体同程度です。妥当な結果のようです。

Bluetoothを使う

NUCのmini PCIeソケットに、無線カードを挿しています。WiFiとBluetoothの機能のあるカードです。このうちWiFiはOOBで設定不要で動きます。Bluetoothを動かすためには以下のkextが必要でした。

BrcmPatchRAM3.kext
BrcmFirmwareData.kext
BrcmBluetoothInjector.kext

これらはKext-Updater.appからダウンロードしました。メイン画面のKextmanagerボタンをクリックして、次の画面でBrcmPatchRamを選びます。

すると8個のkextがダウンロードされます。このうち太字の3個を使ったわけです。

BrcmBluetoothInjector.kext
BrcmFirmwareData.kext
BrcmFirmwareRepo.kext
BrcmNonPatchRAM.kext
BrcmNonPatchRAM2.kext
BrcmPatchRAM.kext
BrcmPatchRAM2.kext
BrcmPatchRAM3.kext

無線カードのファームウェアにパッチを当てるもののようです。初期の頃は、このうちBrcmFirmwareData.kextとBrcmPatchRAM.kextを使用するのが一般的だったようです。ファームウェアのデータkextとパッチしてくれるkextという組み合わせかと思います。その後Catalinaの頃のガイドでは、BrcmPatchRAM2.kextとBrcmFirmwareData.kextに加えて、BrcmBluetoothInjector.kextも必要になったと書かれていました。今回ダウンロードしたら、さらにBrcmPatchRAM3.kextという新しそうな名前のkextがありました。ということで、上記の3個のkextを使うことにしました。この結果、システム環境設定からBluetoothが見えて、アップル純正キーボード・トラックパッドでの動作を確認しました。

Big Sur beta 10を入れる

追記です。その後、Big Surベータ10を入れました。ベータ9からのアップデートはインストーラを起動するだけです。ただ、config.plistで、

Misc – Security – SecureBootModel を Disabled にする

ように変更しました。これをしないと多分起動しないようです。詳しくはこちらをご覧ください。

macOS Big Sur 11.0 Beta 10 をインストール

OpenCore 0.6.1から0.6.2に更新

Tue, 06 Oct 2020 21:39:32 +0900

OpenCoreの0.6.2が公開されたので0.6.1からアップデートしました。0.0.1の違いなので新しくなったファイルを差し替えただけで移行できました。

0.6.2をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

IA32というフォルダができている

今回から、IA32アーキテクチャ用のバイナリーも入っています。Intelの古い32ビットアーキテクチャです。古いハードウェアやmacOSのサポートのために32ビット版も配布されるようになったそうです（まっくぷろさん、解説ありがとうございました）。最近のCPU/macOSを使うならIA32フォルダは無視して、X64の方のフォルダの中身を使うことになると思います。

EFIファイルを差し替える

前回0.6.0から0.6.1へアップデートした時と同じ作業を行いました。現在0.6.1が動いている状態でしたら、現在のESPに含まれる.efiファイルを、0.6.2のものと差し替えることでアップデートできます。具体的には以下のファイルです。まずはBOOTの中のBOOTx64.efiです。

次に、OC直下のOpenCore.efiです。

また、OC/Bootstrap/の中のBootstrap.efiも差し替えます。

OC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。

変更点

今回アップデートしたマシンは、Coffee Lake-S + CatalinaとComet Lake-S + Big Surです。Change logを見たところ、このような環境では、対処すべき項目はほとんど見つかりませんでした。すでに0.6.1で問題なく動いているなら、config.plistがそのまま使えて、変更は不要なようです。

PlatformInfoの中にSystemMemoryStatusという項目ができました。デフォルトは自動ですが、メモリーが交換可能か、はんだ付けされてて交換不可能かを設定するようです。また、Processor Typeという項目もできました。デフォルトは0で、その場合、自動的に設定されるようです。自動認識されない場合はここで手動設定するようです。

macserialなどで使用される機種情報のうち、iMac20,1などの最新機種の細かい情報がアップデートされたようです。BIOSのバージョンとか日付が実際のものに近づいたようです。iMac20,1を使っているのでこれはありがたいです。更新された部分は、OpenCoreの中で自動的に構成してくれる部分なので、config.plistの設定には影響ありません。macserialが生成してくれるシリアル番号などにも変更はありません。iMac20,2のボードシリアル番号の機種ID部分は相変わらず不明で0000になっているようです。iMac20,2にアクセスできるなら貢献できるチャンスかもしれないです。

% ./macserial --model iMac20,2 --num 5
C02DW05T046M | C02052600QX00008C
C02DF4YW046M | C02038130GU0000AD
C02DQ2YH046M | C02047701QX00001H
C02D76Y9046M | C02033902QX0000UE
C02DL0K8046M | C02043101CD00001M

いずれにせよ、Comet Lake-Sの自作機でiMac20,2を選ぶことのメリットは特にありませんので、iMac20,1を選んでおくのが良いと思います。

DummyPowerManagement の場所が変更されたようです。手元の環境では使っていなかったので気づきませんでした。コメントで教えていただきました。config.plistの中のこの設定が、Kernel > Emulate Propertiesに移動しています。このフラグでPower managementをoffにしている場合は、config.plistを更新する必要があります。

Config.plistはこちら

その後、OpenCoreに付属のSample.plistを見ながら、新しく追加された項目も含んだconfig.plistを作り直しました。ASUS Z390 ROG MAXIMUS XI + 9900K + RX580の構成のconfig.plistはこのようになりました。

config.plist for ASUS Z390 OC060 - Pastebin.com

一方、ASUS Z490G + 10900K + RX5700XTの構成のconfig.plistは以下です。

config.plist for ASUS Z490 10900K OC062 - Pastebin.com

いずれもPlatformInfoの項目は未記入ですので、macserialなどを使って生成してください。

accountsdが暴走してCPU使用率700％

Mon, 05 Oct 2020 22:17:00 +0900

Catalina 10.15.7が動いているZ390 + 9900Kマシンで、ポインターが虹色円盤になり動作不能に陥りました。先日のアップデートの副作用のようで、再起動したら治りました。10.15.7 Comboアップデートを当てておきました。再発しないかどうか様子見します。

症状

突然、Catalina 10.15.7が動いているマシンで、ポインターが虹色円盤になり、文字入力がほとんど動かなくなり、ほぼ動作不能に陥りました。いわゆるSpinning wheel of deathです。アクティビティモニターで調べてみると、accountsdというデーモンがしきりに稼働していて、このデーモンだけでCPU使用率が700%近くになってました。マシンはこちらで作成したZ390 + 9900Kの構成です。

macOS Catalina 10.15.7 (19H2)
ASUS ROG MAXIMUS XI HERO (Z390)
9900K
OpenCore 0.6.1
kext類は最新

とりあえず再起動したところ治りました。スクリーンショットを撮っておけば良かったですが忘れてました。Hackintoshしている弱みで、トラブルがあるとついついhackintoshの動作と設定を疑ってしまうのですが、どうやら最近話題になっているアップデートの副作用のようです。フォーラムでまっくぷろさんに紹介されているのを見て気づきました。ネットで紹介されている症状とほぼ同じでした。

対策？

ネットの情報では、10.15.7 Comboアップデートを当てると効果があるようです。古い設定を捨ててくれるのかもしれないです。ということで、AppleのサイトからComboアップデートをダウンロードして、インストールしておきました。ビルド番号は19H2と変わらないです。再発するかどうか様子見します。

Download macOS Catalina 10.15.7 Combo Update

macOS Big Sur 11.0 Beta 9 をインストール

Fri, 02 Oct 2020 17:52:06 +0900

Beta 9がパブリックベータとして公開されたので、Beta 6からアップデートしました。ビルド番号は20A5384cです。Radeon 5700XTの性能がかなり向上しました。Z490, 10900K, OpenCore 0.6.1の環境で快適に動作しています。

インストール手順

前回の記事で入れたBeta 6マシン（Z490 + 10900K + 5700XT）

macOS Big Sur 11.0 Beta 6 をインストール

のソフトウェアアップデートにmacOS Big Sur Betaの案内が来ていました。

このMac用のアップデートがあります
・macOS Big Sur Beta 9 11.0

という表示です。Beta 6からBeta 9に飛んだのは、パブリックベータだからだと思います（もしかしたら途中のアップデータに気づかなかったのかもしれませんが）。

早速「今すぐアップデート」ボタンを押したのですが、ダウンロードが開始した後で、「インターネットの接続を確認してください」というようなエラーが出て進まなくなりました。夢日記で紹介されている状況とおそらく同じだと思います。さらに、別のCatalinaマシンもベータテスターに登録しているので、こちらでもダウンロードを試みましたが、やはりネットが不調というメッセージで止まります。

サーバが不調なのかと思い、一晩待ちましたがやはり同じエラーでした。そこで、ベータテストのサイトからmacOSPublicBetaAccessUtility.pkgをダウンロードし直して、インストールし直したところアップデートが進みました。自動的に何回か再起動して、問題なくアップデートが完了しました。一方のCatalinaマシンも、macOSPublicBetaAccessUtility.pkgを入れ直すことでダウンロードが成功しました。原因は不明ですが、何らかのアクションをすると改善するようです。

インストールが終わったBig Sur Beta 9はとても快適です。この分ならメイン環境として使っても良いと思いました。OpenCoreなどのバージョンは以下のとおりです。

OpenCore 0.6.1
kext類は一般公開されている最新のもの
機種設定はiMac20,1

5700XTの性能がさらに向上

このマシン (Z490 + 10900K) にはRadeon 5700XTを取り付けてあります。Beta 6の時と同様に、その性能をGeekbench 5で測定しました。下のグラフはCatalina 10.15.6、Big Sur Beta 6、Beta 9との比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。

Radeon 5700XTの性能がかなり改善されています。Beta 6では、RX 580と比較して、OpenCLでは優っているもののMetalで負けていました。Beta 9ではBeta 6より2~3割改善されて、OpenCLもMetalもどちらもRX 580のスコアを上回りました。5700XTの性能をようやく引き出せるようになったようです。

OpenCore 0.6.0から0.6.1に更新

Thu, 10 Sep 2020 22:23:35 +0900

OpenCoreの0.6.1が公開されたので0.6.0からアップデートしました。Big Surに対応してComet Lakeに対応したところが大きな変更点かと思います。0.0.1の違いなので新しくなったファイルを差し替えただけで移行できました。

0.6.1をダウンロードする

公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。

Releases · acidanthera/OpenCorePkg

EFIファイルを差し替える

現在0.6.0が動いている状態でしたら、0.6.1に含まれる.efiファイルを、0.6.0のものと差し替えることでアップデートできます。具体的には以下のファイルです。まずはBOOTの中のBOOTx64.efiです。

次に、OC直下のOpenCore.efiです。

また、OC/Bootstrap/の中のBootstrap.efiも差し替えます。

OC/Driversの中のうち、現在使用しているものだけを差し替えました。手元のマシンでは、OpenCanopy.efiとOpenRuntime.efiだけを使っているので、それを差し替えました。

OC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。

ACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。OpenCoreに付属している差分を説明するファイルや、インストールガイドのページを見ても、書き換えるべきconfig.plistの項目はなかったように思います。

iMac20,1に対応

0.6.1で最新のComet Lake-S CPUを搭載したiMac20に対応しました。最新パーツで組む場合にはありがたいところです。付属しているmacserialコマンドでも、iMac20,1と20,2のシリアル番号とボードシリアル番号の対を生成できるようになっています。

% ./macserial --model iMac20,1 --num 5
C02D1KZGPN5T | C02027600GUPHCD1F
C02DP1Z3PN5T | C02046104GUPHCD1H
C02CFNYTPN5T | C02011401GUPHCDA8
C02D6PZWPN5T | C02032200QXPHCDAD
C02D36YPPN5T | C02029101CDPHCDAD
% ./macserial --model iMac20,2 --num 5
C02DW05T046M | C02052600QX00008C
C02DF4YW046M | C02038130GU0000AD
C02DQ2YH046M | C02047701QX00001H
C02D76Y9046M | C02033902QX0000UE
C02DL0K8046M | C02043101CD00001M

ただし、iMac20,2は、ボードシリアル番号の機種IDの部分が更新されていなくて0000になってます。実機を調べてきた人がいないためです。Comet Lake-Sの自作機でiMac20,2を選ぶことのメリットは特にありませんので、iMac20,1を選んでおくのが良いと思います。

macOS Big Sur 11.0 Beta 6 をインストール

Wed, 09 Sep 2020 22:40:47 +0900

Beta 6が公開されたのでアップデートしました。ビルド番号は20A5364eです。Beta 5では起動で失敗していたComet Lake-Sで、Beta 6は動きました！また、Catalinaに比較してRadeon 5700XTの性能が向上していることを確認しました。

インストール手順

前回の記事では、createinstallmediaコマンドを使ってインストール用USBメモリを作成し、それで起動してSSDにインストールしました。今回はUSBメモリを作るのが面倒だったので、真っ新な2.5インチSATA SSD（今回は250GB）をCatalinaマシンに接続し、フォーマットし、macOS Big Surベータ版インストール.appから直接インストールしました。

このSSDを、Catalinaマシンに接続したまま、Catalinaが入っているESPの中のOpenCoreで起動します。そして起動ボリューム選択画面で、Big SurをインストールしたこのSSDを選択して起動しました。Beta 5に引き続き、Prebootという分かりにくい名前で現れています。Prebootの右に見えるMacintosh HDというドライブは、いつも起動しているCatalinaのボリュームです。

Z490で動きました

前回の記事でBeta 5が既に動作していたZ390上のCoffee Lake-Sマシンでは、Beta 6も引き続き問題なく起動しました。一方で、Beta 5が動かなかったZ490上のComet Lake-Sでも、Beta 6ならば起動しました。このマシンです。

ASUS ROG STRIX Z490-G, 10900K

ESPの構成は以下です。config.plistも、Catalina 10.15.6を起動させている状態のそのままです。

OpenCore 0.6.1
kext類は一般公開されている最新のもの
機種設定はiMac20,1

OpenCore 0.6.1はGitHubで公開されているソースからビルドしたものです。iMac20,1の機種設定・シリアル番号が使用したかったので0.6.1にしてあります。0.6.1が必須というわけではありません。（追記：この記事を書いている間に0.6.1は公開版として出てました。）Z390マシンでは公開版の0.6.0でも動いています。Z490マシンでBeta 5を試みた時には、OpenCoreが動いてすぐに

[EB|#LOG:EXITBS:START]

という表示で止まってしまい、起動しませんでした。このメッセージで止まることへの対策を色々試みたのですが、解決しませんでした。それがBeta 6にしたら、何の問題もなく起動しました。Beta 6はComet Lake-S搭載のiMac 2020に対応したという話をコメントで教えていただきました。Hackintoshなのが原因ではなく、もともと今回でComet Lake-Sに対応したということだったのかもしれません。

5700XTの性能が向上

このComet Lake-Sマシン (CPUは10900K) にはRadeon 5700XTを取り付けてあります。その性能を測定しました。下のグラフはCatalina 10.15.6とBig Sur Beta 6との比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。

Radeon 5700XTは、RX 580と比較して、OpenCLでは優っているもののMetalで負けているという状態でした。その傾向は変わらないのですが、Big Surになってそれぞれ10%程度性能が向上しているようです。

macOS Big Sur 11.0 Beta 5 をインストール

Sat, 05 Sep 2020 19:23:54 +0900

ようやくBig Surを入れました。Public Beta Programで現在配布されているBig Sur 11 beta 5 (20A5354i) です。Catalinaを動かしているZ390マシンの、OpenCoreとその設定が入っているESPから起動して、すんなり動きました。この記事もBig Surで書いてます。この調子ならBig Surへのアップデートも順調に行えるように思います。

ダウンロード

Catalinaを動かしているZ390マシンをPublic Beta Programに登録し、システム環境設定のソフトウェアアップデートからダウンロードしました。デベロッパー向けにはbeta 6 (20A5364e)が既に出ているようですが、Public Betaはbeta 5のようです。ダウンロード後にインストーラが起動しますが、それは中断します。ApplicationフォルダにmacOS Big Surベータ版インストールというアプリケーションができています。

インストール用USBメモリを作る

次に32GB容量のUSBメモリを用意しました。これをフォーマットし、ここではusbという名前をつけました。ターミナルでmacOS Big Surベータ版インストールの場所にcdします。この中のContents/Resourcesの中に

% cd /Applications/Install\ macOS\ Big\ Sur\ Beta.app/
% cd Contents/Resources/

お馴染みのcreateinstallmediaコマンドがあります。オプションなしで起動すると、ヘルプが表示されます。

% ./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

downloadassetsを指定すると、インストール途中でネットにアクセスする必要がないような説明がされているので、これは使うことにします。そこで、

% sudo ./createinstallmedia --volume /Volumes/usb --downloadassets

とタイプします。これで用意したusbメモリが初期化されて、そこにBig Surのインストーラが作られます。

USBメモリから起動する

実際のMacなら、このUSBメモリで起動して、インストールをすることができます。Macでの動作を確認しました。インストール途中で再起動するときに、中間のボリュームの名前がいつもと違って「EFI」というように表示されて違和感がありました。この後で行ったhackintoshへのインストールでも後述のように、名前がおかしかったです。ベータ版なので、後に改善されると思います。

USBメモリを起動したhackintoshは、こちらで紹介したZ390マザーボードの構成です。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ESPの構成は以下です。通常は最新版のCatalinaを起動させています。

OpenCore 0.6.0 (一般公開されている最新バージョンです)
kext類は一般公開されている最新のもの
機種設定はiMac19,1

このESPから起動し、OpenCoreのメニューからBig Surインストール用USBメモリを選ぶと、インストーラが起動しました。

SSDを用意してインストール

インストール用に、余っていた64GBの2.5インチSSDを用意しました。これをUSB接続のHDDケースに入れて、USB接続しました。Big Surインストール用USBメモリで起動すると、そこからDisk Utilityを起動できるので、これを使ってSSDをAPFSでフォーマットします。フォーマットが終わったらインストーラプログラムに戻って、SSDにインストールをします。

インストール途中で再起動を求められます。NVRAMが機能していれば再起動時に選択すべきドライブがデフォルトで選択されているのですが、場合によってはOpenCoreやCloverの起動ボリューム選択画面で選択する必要があります。

最初の再起動では、macOS Installerというボリュームが見えたので、それを選択しました。これでインストールが正しく進みました。今まではBoot macOS Install from xxxxというような名前のボリュームを選ぶことになったので、少し違った様子です。

次の再起動では、さらに悩みました。Prebootというボリュームが見えていて、これを選択するのが正しかったです。従来は、PrebootはFileVaultのログイン用に使うボリュームだと思っていたのですが、今回は違うようです。

ボリュームの名前に関しては、前述のように実機でも同じようにわかりにくい不具合（実機ではEFIという名前になってました）があります。公開バージョンになれば改善されると思います。Mifjpnさんのブログに、再起動時に選択肢が現れない場合への対処法や、Prebootから改名する方法などが紹介されています。

インストール後のBig Sur起動ディスクの容量は40.05GBでした。64GB SSDで十分でした。今回使用した64GB SSDは骨董品なので180MB/sくらいしか読み取り速度が出ないのですが、最近だとこれより高速な64 GB USBメモリーが1,000円台で買えるのですね。

Big Surで起動

Prebootから起動すると、いつものような設定画面を経て、Big Surが起動します。デフォルト壁紙が、今までの写真から、カラフルな絵に変わって、新鮮な感じです。少し操作を試しましたが、特に問題はないようです。サクサクといつものように動作します。この調子ならば、例年のようにスムーズにバージョンアップが出来そうです。

おまけ：Z490では苦戦中

こうして動かしたSSDを、Z490のマシン

ASUS ROG STRIX Z490-G, 10900K

で動かそうとしたのですが、こちらは、OpenCoreが動いてすぐに

[EB|#LOG:EXITBS:START]

という表示で止まってしまい、起動しません。Catalinaは問題なく起動するのですが、なぜかBig Surだと起動しません。こちらのトラブル対策を試してはいるのですがまだ解決していません。メモリーマップが変わったのかなとは思ってます。

追記：Beta 6になったらZ490マシンで動くようになりました。

macOS Big Sur 11.0 Beta 6 をインストール

自作PCにiMac20,1のシリアル番号を設定する

Sun, 23 Aug 2020 00:49:27 +0900

Comet Lake-S搭載自作PCの機種IDを、iMac 2020に合わせてiMac20,1に設定しました。iMac 2020が発売されたばかりなので、現バージョンのOpenCoreとmacserialがiMac20,1に未対応です。そこでGitHubから最新版を入手して、MLB情報を追加して、ビルドしました。

OpenCoreをビルドする

先の記事で紹介したように、第10世代Comet Lake-S搭載のマシンは、iMac 2020に合わせてiMac20,1に設定するのが良いと思います。最新のmacOS 10.15.6 (19G2021)は、iMac20,1に対応しています。でも現在のOpenCore 0.6.0は、iMac 2020が発売される前のバージョンなのでiMac20,1に対応していません。

OpenCoreは現在0.6.1の開発が進んでいて、GitHubでソースコード一式を入手できます。後で詳しく説明しますが、0.6.1ではiMac20,1, 20,2の機種IDに対応しつつあります。なのでこれをビルドすれば、対応したOpenCoreを入手できます。

GitHub - acidanthera/OpenCorePkg: OpenCore bootloader

OpenCoreのビルドはやったことがなかったのですが、いつもコメントを書いていただいているMifjpnさんのサイトの記事を見て、試してみました。最初はいくつかのツールをダウンロードすることになりましたが、基本的には自動で簡単にビルドできました。

デイリービルドの日々・・・Big Sur Betaが終わるまで

ビルドした結果は、こちらに置いておきました。後で説明するiMac20,1対応のmacserialも含まれています。

OpenCore-0.6.1-RELEASE.zip

これでiMac20,1に対応したmacserialとOpenCoreが得られます。そこで、macserialでiMac20,1のシリアル番号を生成して、これをconfig.plistに書き込み、OpenCore 0.6.1を使えば、iMac 2020に相当するマシンになります。

ここから先は、ソースコードの細かい話ですので、興味の無い方は、「IDを生成する」の節まで飛ばしてください。

macserialとOpenCore

Hackintoshのconfig.plistに書くべきシステムシリアル番号、ボードシリアル番号 (MLB) などを自動生成してくれるツールにmacserialがあります。以前の記事でも紹介しました。macserialのソースコードは、今は同じacidantheraさんが管理するOpenCoreのソースに組み込まれています。以前のmacserialの部分は、OpenCoreのUtilitiesディレクトリに収められています。

macserialは、機種ID、シリアル番号の規則、MLBの規則などの様々なMacの機種情報を把握した上で、シリアル番号などを自動生成しています。Macの機種情報は、従来はmacserialのヘッダファイルに手作業で書き込まれていました。しかし今は、OpenCoreのAppleModelsというディレクトリの中で、MacBook, iMacなどの種類ごとにテキストファイルで書き込まれています。機種情報は、macserialだけでなくOpenCoreパッケージの他のプログラムでも利用されています。なので、config.plistに個体特有の機種情報を書くだけで、それ以外の機種共通の情報、例えばBoard IDやファームウェアバージョンなどは、自動的に用意されるのです。

iMacの情報は、AppleModels/DataBase/iMacの中にあります。最初、OpenCore 0.6.1のGitHubを見ていたときには、iMac20,1, iMac20,2の情報はDataBaseの中にありませんでした。しかし、最近になって有志の方が書き込んでくれたようで、IM201.yaml, IM202.yamlという2個のファイルが作られています。そこで、現時点でOpenCore 0.6.1をビルドすると、iMac 2020に対応したOpenCoreが得られます。またターミナルでmacserialのディレクトリに移動してmakeコマンドを打ち込めば、macserialもビルドできます。

macserialを使ってみる

この記事を書いている時点で配布されているmacserialを使ってみると、生成されるiMac20,1, 20,2のMLBが不完全でした。例えば、iMac20,1のシリアルとMLBを生成すると、以下のようになります。

% ./macserial --model iMac20,1
C02C68ZDPN5T | C02005101QX00008C
C02D90GAPN5T | C02035401J900008C
C02CRFZPPN5T | C020213034N0000AD
C02C9MZFPN5T | C02008108QX00001H
C02DK0K5PN5T | C02042501GU0000UE
C02CK0A6PN5T | C02015130CD0000CB
C02CK6Y6PN5T | C02015902J90000JC
C02D1MYSPN5T | C02027501QX00001M
C02D2CYVPN5T | C02028101GU00001F
C02C5VZKPN5T | C020041304N0000JC

シリアル番号は正しく生成されているようですが、MLBの方は下6桁から下3桁の4文字が0になっています。シリアル番号を紹介する記事で説明したように、本来ならばここにはiMac20,1特有のボードコード(AppleBoardCode)が書かれるべき場所です。AppleBoardCodeが0なのは、前述のIMAC201.yamlに記載が無く、仮の値として0000が書き込まれているからです。

MLBを見つけてくる

シリアル番号とMLBを生成するためには、実機のiMacの番号を見つけて、それから機種固有のコードを知る必要があります。上の例で、シリアルに共通しているのはPN5Tという下4桁の部分で、これが機種固有のAppleModelCodeです。シリアル番号は、以前の記事でも紹介したように、ネットを探すとわりと簡単に見つかります。「このMacについて」にシリアル番号が表示されるからです。これに対してMLBは簡単には表示されません。なのでGitHubに機種情報を書いてくださった方も、ネットからわかる範囲でDataBaseを用意してくれたので、生成されるMLBの一部が0000になってしまっています。

ということで酷暑の中、iMac 2020が展示されているお店を巡ってMLBを調べてきました。大都会のアップルストアに行ければ良かったのですが、近場の量販店に置いてあったのはどこも10500搭載モデルが1台だけでした。つまりiMac20,1だけでした。そのMLBを調べた結果、いずれの展示品iMacのMLBも、AppleBoardCodeの部分はPHCDでした。ちなみに、シリアルのAppleModelCodeはどれもPN5Tでした。貴重な情報を得られたので、お礼に買い物もしてきました。

macserialをビルドする

このAppleBoardCodeを

OpenCore/AppleModels/DataBase/iMac/IM201.yaml

に書き込みます。以下のようになります。

# Note, first model code is used by macserial
AppleModelCode:
- "PN5T"
- "PN5Y"
- "PN5X"
- "PN5W"
- "PN5V"
- "PN78"
- "PN7D"
- "PN77"
- "PN7C"
# Note, first board code is used by macserial
AppleBoardCode:
- "PHCD"

ちなみに現時点でAppleModelCodeは9個登録されています。9個あっても、コメントにあるように、シリアル番号生成には最初の1個だけが使用されます。なので、特定のAppleModelCodeを使いたかったら、それを最上位に移動しておくと良いです。この後、

OpenCore/AppleModels/update_generated.py

を実行します。このコマンドでmacserialの機種情報ヘッダファイル、modelinfo_autogen.hが更新されます。README.mdにあるように、yamlを解釈するPythonライブラリであるpyyamlを事前にインストールしておく必要があります。

この後、OpenCore全体をビルドすればmacserialもビルドされてiMac20,1対応になります。macserialだけをビルドするのであれば、ターミナルで

OpenCore/Utilities/macserial

に移動し、

make

とタイプすると、macserialをビルドできます。makeするための条件を満たすために、

touch macserial.c

としてソースファイルの日付を更新しておく必要があるかもしれないです。

IDを生成する

こうしてビルドした新macserialを使えば、以下のようにAppleBoardCodeがPHCDのMLBを生成してくれます。これをconfig.plistに書き込めば良いです。

% ./macserial --model iMac20,1 --week 30
C02D4SZ5PN5T | C02030100GUPHCDAD
C02D409PPN5T | C02030500J9PHCD1F
C02D4LZGPN5T | C02030130J9PHCDCB
C02D4GYUPN5T | C02030100CDPHCD8C
C02D4BZ8PN5T | C02030404GUPHCD8C
C02D4DYJPN5T | C02030403CDPHCDJA
C02D47YYPN5T | C02030600GUPHCDA8
C02D4EY9PN5T | C02030303GUPHCDA8
C02D40JYPN5T | C02030100GUPHCDAD
C02D40QHPN5T | C020304054NPHCDAD

ちなみに、上記ではmacserialのweekオプションを使って製造週を30週に指定しています。これを指定しないと、例えば2020年1月製造とか、2020年10月製造のシリアルが生成されてしまいます。iMac 2020が未発売時点の製造日や、未来の製造日は避けたいです。30週は、2020年7月22日から28日なので、この記事の時点で妥当な値です。

OpenCore 0.6.1に反映されました

この記事を書いている間に、今回紹介したAppleBoardCode情報がOpenCore 0.6.1に反映されました。GitHubに出してあったpull requestをvit9696さんが受理してくれました。たったの4文字だけですがOpenCoreに貢献できて嬉しいです。

まとめ

iMac20,1のMLBを街で探して、OpenCoreのソースに反映しました。これでiMac20,1のシリアル番号と完全なMLBが作れるようになります。これらをconfig.plistに書き込み、OpenCore 0.6.1とmacOS 10.15.6 (19G2021) でComet Lake-S自作機を動かしていますが、今のところ問題はありません。

第10世代自作PCの機種IDはiMac20,1が良い

Sat, 22 Aug 2020 12:34:43 +0900

第10世代CPU, Comet Lake-Sで自作したら、機種IDはiMac20,1にするのが良いと思います。iMac 2020に搭載されるComet Lake-S CPUの全てに適用されるIDだからです。ただ、Radeon RX 5700 XTなどを使用する場合は、類似GPUを搭載するiMac20,2の方が性能を引き出せる可能性も無いとは言えません。でも、実測したところ性能に違いはありませんでした。

iMac 2020には2種類の機種IDがある

前回の記事で紹介しましたように、iMac 2020には、iMac20,1とiMac20,2の2種類の機種IDがあります。ここでは、Comet Lake-Sの自作PCでmacOSマシンを作る場合、そのどちらを使用したら良いかをさらに考えてみます。

iMac20,1とiMac20,2の違い

とりあえずは全てのComet Lake-Sモデルが対象になっているiMac20,1にしておくのが良いと思われます。特に10500や10600などを使う場合はiMac20,1にすべきでしょう。また多くの人がiMac20,1に設定すると思われるので、iMac20,1にしておけば、トラブル解決情報も容易に得られると思います。

ただ、iMac20,2はRadeon Pro 5700とPro 5700 XT搭載モデルなので、よく似た型番のRadeon RX 5700とRX 5700 XT搭載グラフィックスカードを使用する場合だけに関しては、iMac20,2の方が適切なのかもしれない、とも考えられます。もしかしたらiMac20,2にした方が、5700 (XT)のグラフィックス性能がより引き出せるのかもしれません。そこで今回は、RX 5700 XT搭載マシンで、性能差を検証しました。

iMac20,1と20,2でベンチマーク

機種IDをiMac20,1もしくはiMac20,2に設定するためには、それぞれのシリアル番号などを正しく生成して、対応したmacOSとOpenCoreを使用するのが良いです。この話題については次の記事で紹介します。

今回のベンチマークで使用したマシンは、こちらで紹介したものを基にして、さらにCPU, macOSとOpenCore, kext類をアップデートしてあります。

ASUS ROG STRIX Z490-G GAMING (WiFi)
Intel Core i9 10900K
macOS 10.15.6 (19G2021)
OpenCore 0.6.1
Radeon RX 5700 XT (ASUSのリファレンスファン)

このマシンの機種IDをiMac20,1とiMac20,2に設定して、それぞれでGeekbench 5のOpenCLとMetalのテストを5回ずつ実施しました。その平均を以下に示します。相変わらずしょぼいスコアで、同じ条件のRX 580に負けているのではと思いますが、今回はモデルIDの違いだけに注目します。

その結果、iMac20,1とiMac20,2では差がないことが判明しました。むしろiMac20,1の方が多少良いくらいです。ただ、個々のスコアを見ると、それぞれ逆転しているスコアもあり、違いは誤差範囲かと思われます。

まとめ

Radeon RX 5700 (XT)を使用した場合、iMac20,2に設定した方が性能を引き出せるのかどうかを検証しました。その結果、iMac20,1との差はありませんでした。第10世代で自作するなら、どの構成でも、機種IDはiMac20,1にすれば良いと思います。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

Thu, 06 Aug 2020 21:56:56 +0900

OpenCore 0.6.0が出たので、ASUSのZ490マザーボードのオーディオを再設定しました。OpenCore 0.6.0とAppleALC.kext 1.5.1がZ490マザーボードに対応したことから、PCI IDを偽装しなくても動くようになりました。

今までの設定

前回は、OpenCore 0.5.9を使ってZ490マザーボード搭載コーデックを動かしました。特別な設定不要で音が出たASUSの先代Z390マザーボードには、ASUSの仕様書によると、オーディオユニットにはSupremeFX S1220という名前が付けられています。Hackintoolなどで調べるとコーデックはRealtekのALC1220のようです。Z490マザーボードになって、これがSupremeFX S1220Aになってました。HackintoolではRealtek ALCS1220Aになっています。SやAが追加されていますが数字部分は同じなのであまり変わらないと思ったのでしたが、デバイスIDを偽装する設定を行わないと、音が出ませんでした。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

ここに書きましたように、kextに、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を入れ、さらにconfig.plistでデバイスIDを指定し、レイアウトIDを7に指定する必要がありました。

<key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
<dict>
 <key>device-id</key>
 <data>cKEAAA==</data>
 <key>layout-id</key>
 <data>BwAAAA==</data>
</dict>

OpenCoreとAppleALCの最新版を使う

OpenCoreが0.6.0になり、またAppleALC.kextが1.5.1になり、その両方の資料で、Z490マザーボード搭載オーディオに対応したとの記述を見つけました。ならば、FakePCIIDを使わなくても音が出るようになったのかと思い、試してみました。

まずはAppleALC.kextだけ更新しました。それでFakePCIID_Intel_HDMI_Audio.kextを外してみました。FakePCIID.kextは、Ethernetチップを動かすためにも必要なので、外してません。でも音は出ませんでした。そこでOpenCoreも0.6.0にアップデートしました。0.5.9から0.6.0へのアップデート作業は、こちらをご覧ください。

OpenCore 0.5.9 から 0.6.0 に更新

AppleALCとOpenCoreの両方をアップデートしたところ、FakePCIID_Intel_HDMI_Audio.kext無しで、config.plistにもデバイスIDを書かなくても、音が出ました。config.plistの該当部分は、こんな感じになりました。

<key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
<dict>
 <key>layout-id</key>
 <data>BwAAAA==</data>
</dict>

レイアウトIDは必要です。このマザーボードは7でしたので、それがBase64形式で書いてあります。

まとめ

ということで、OpenCoreとAppleALCの現行バージョンなら、レイアウトIDの指定だけで、何も特別なことをしなくてもZ490の音が出るようになりました。コメントでもOpenCoreとAppleALCの最新版でPCIIDの偽装が不要になったとの情報をいただいています。新型iMacで第10世代CPUが採用されたこともあり、これでZ490がさらに気軽に使えるようになったと思います。

OpenCore 0.5.9 から 0.6.0 に更新

Wed, 05 Aug 2020 00:11:54 +0900

OpenCore 0.6.0が公開されたので、0.5.9から更新しました。まずは0.6.0になって更新されたファイルを差し替えるだけでもとりあえず動きました。次にconfig.plistを正しく変更しました。

Release 0.6.0 · acidanthera/OpenCorePkg

使用したのは、ASUS Z390 ROG MAXIMUS XI HERO、Intel 9900K、 Radeon RX 580の組み合わせのこちらのマシンです。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

更新ファイルだけ置き換える

とりあえず、更新されたファイルだけ差し替えてみました。ESPの中身のうち、OpenCoreの配布物に含まれないファイルは0.5.9からそのまま引き継ぎました。0.5.9から引き継いだのは、

最新にしてあったKextsフォルダの中身、
ACPIフォルダの中身はそのまま、
Resourcesの中身もそのまま、
とりあえず0.5.9のconfig.plistをそのまま使います。

0.6.0のファイルと入れ替えたのは、

BOOTフォルダの中身 (BOOTx64.efi)
Bootstrapフォルダの中身 (Bootstrap.efi)
Driversフォルダの中身 (AudioDxe.efi, OpenCanopy.efi, OpenRuntime.efi)
OpenCore.efi
Toolsフォルダの中身 (OpenShell.efiだけ)

です。quirkが変わったりしているようなので、config.plistも正しく更新すべきですが、とりあえずは、0.5.9から0.6.0へは、何もしなくても移行できました。

config.plistを正しく更新する

一応は動いたのですが、config.plistを正しく設定することにしました。OpenCore 0.6.0に付属しているsample.plistと現行のCoffee Lake-S用のconfig.plistをProperTreeを使って比較しました。変更点は以下のキーでした。

Booter–>Quirks–>ProvideMaxSlide

0.6.0で追加されました。タイプはNumberです。デフォルトでは0で、sample.plistでも0が設定してあります。KASLRのスライド値の最大を決めるようです。デフォルトの0はスライドさせないという意味かと思います。使用しているマザーボード（ASUS Z390 ROG MAXIMUS XI）はスライド幅に余裕があった気がしましたので、最大の255に設定してみました。KASLRの考え方からして、スライド幅が大きいほどセキュリティが向上するはずです。今のところ問題なく起動しています。もしも起動失敗することがあれば減らせば良いです。KASLRとスライドについてはこちらの記事で説明しました。

Misc–>Security–>BlacklistAppleUpdate

0.6.0で無くなりました。なので0.5.9のまま起動すると、画面に一瞬、BlacklistAppleUpdateに対するスキームが無いよというエラーメッセージが出ます。Appleのペリフェラルファームウェアのアップデートを無視する機能との説明です。指定する場所が、Misc–>Securityの場所から、次に説明するNVRAMに移動したようです。なので0.5.9のconfig.plistからこのキーを削除しました。

NVRAM–>7C436110-AB2A-4BBB-A880-FE41995C9F82–>run-efi-updater

0.6.0で追加されました。上記のBlacklistAppleUpdateの代わりです。設定場所がこちらに移動しました。macOSのEFIファームウェアアップデートを上書きします。これをNoに設定すると、macOSのファームウェアアップデート機能を阻止します。APFSに移行した時に、EFIがAPFSから起動できるようにアップデートされたのですが、あのようなことを阻止する機能のようです。実機ではないhackintoshならばファームウェアが全く違いますからNoに設定するのが妥当です。

UEFI–>APFS–>GlobalConnect

0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。0.5.9のconfig.plistにはありませんので、Falseとして追加しておきました。APFSドライバーをロードする時の、ハンドル（ポインターみたいなもの？）の扱いを、通常のやり方から再帰的なやり方に変更するオプションらしいです。これをTrueにすると起動に時間がかかるけど、古いHPラップトップがAPFSにアクセスするためには必要らしいです。なので古いHPラップトップ向けの設定ですね。

UEFI–>Output–>UgaPassThrough

0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。これもデフォルト通り、Falseとして追加しておきました。GOPプロトコルの上にUGAプロトコルを提供すると、説明にあります。UGAは古いプロトコルなのでもはやサポートされていない場合もあるのですが、古いEFIではUGAが画面表示に必要なこともあるらしいです。EFIの画面表示に問題がなければFalseで良いようです。

UEFI–>ProtocolOverrides–>AppleFramebufferInfo

0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。これもデフォルト通り、Falseとして追加しておきました。Apple Framebuffer Infoプロトコルをインストールし直す機能との説明です。VMや古いMacのフレームバッファ情報を上書きしてmacOS 10.4の古いEFIブートとの互換性を改善するとのことです。問題なければFalseで良いようです。

まとめ

OpenCore 0.5.9から0.6.0に移行しました。まずは新しくなったファイルを一つ一つ差し替えました。そのままで起動しました。次に、より正しく設定するために、config.plistを以下のように書き換えました。diffコマンドで0.6.0と0.5.9のconfig.plistを比較しています。<で示す行が追加した行で、>で示す行が削除した行です。

% diff config_060.plist config_059.plist
197,198d196
< <key>ProvideMaxSlide</key>
< <integer>255</integer>
648a647,648
> <key>BlacklistAppleUpdate</key>
> <true/>
704,705d703
< <key>run-efi-updater</key>
< <string>No</string>
801,802d798
< <key>GlobalConnect</key>
< <false/>
872,873d867
< <key>UgaPassThrough</key>
< <false/>
907,908d900
< <key>AppleFramebufferInfo</key>
< <false/>

ASUS ROG STRIX Z490-G, 10900K

Tue, 28 Jul 2020 23:45:58 +0900

第10世代デスクトップCPU 10900Kを搭載したASUSのZ490マザーボードに、OpecCoreで起動するmacOS Catalinaをインストールしました。CPU, GPU, スリープ、Ethernet, サウンド, WiFiが全て動き、安定しています。間も無く登場すると言われているComet Lake-S搭載iMacに匹敵するマシンになると思います。

ハードウェア構成

こちらの記事で、10600を使ったhackintoshを作りました。これのCPUだけを10900Kに交換しました。他の設定は全く変更なく、引き続き動きました。

Comet Lake-S 10600とZ490でmacOSを動かす

マザーボード

マザーボードは、です。しっかりした作りでよくできています。販売サイトの製品写真ではバックパネルカバーのロゴが黄色です。でもこれはフルカラーLEDなので、Windowsからならば何色にも設定できると思われます。デフォルトでは時間と共に色が変化します。は2,000円安いです。WiFi用のM.2ソケットでBroadcomのカードが動くかと思ったのですが、これはCNVi専用でした。なのでWi-Fi無しの方が良かったかもしれないです。

CPU

10900Kです。10コア20スレッドです。12面体という奇抜な外箱だった9900Kに比べて、普通のコンパクトな外箱になったと思っていたのですが、実物を見るとこれもなかなか奇抜でサイズ感がありました。微妙な角度でCPUが保持されています。

GPU

CPU内蔵のiGPUであるIntel UHD Graphics 630はほぼ稼働しました。ただし、Display Portのみが機能し、HDMIでは出力できないです。また、「画面共有」を設定しても他マシンから接続できませんでした。このCPUでiGPUを使い続けることはないと思うので、緊急用としたらこれで十分でしょう。

そこで、PCIeスロットにグラフィックスボードを接続し、こちらを主に利用します。現在挿してあるのは、Sapphire NITRO+ ブランドのRadeon RX 580です。全く問題なく動いています。

WiFi / Bluetooth

BroadcomのBCM94360NGを使用してます。アンテナ端子は、マザーボードのバックパネルに取り付けてあります。詳細は、こちらをご覧ください。

Z490マザボ搭載WiFiをmacOS対応品に交換する

BIOS設定

BIOSの設定は、ほぼ工場出荷時設定で大丈夫です。Legacy USBをdisabledにするなど、やっておけば良い程度の変更をしました。デフォルト設定のままであってもmacOSの起動に支障をきたすことはありません。

よくあることのようですがメモリーが2133MHzと認識されていました。2666MHzのメモリーなのでBIOSでそのように設定しました。メモリー速度設定はGeekbench 5のスコアに影響を与えます。

使用したefiとkext

ACPIには

SSDT-AWAC.aml
SSDT-EC-USBX.aml
SSDT-PLUG.aml
SSDT-RHUB.aml

を入れました。Driversには、

VBoxHfs.efi
OpenRuntime.efi
OpenCanopy.efi

を入れました。Kextsには、

AppleALC.kext
FakePCIID.kext
FakePCIID_Intel_I225-V.kext
Lilu.kext
SMCProcessor.kext
SMCSuperIO.kext
USBPorts.kext
VirtualSMC.kext
WhateverGreen.kext

を入れました。このうち、macOSの起動に最低限必要なのは、以下の3個です。

WhateverGreen.kext
VirtualSMC.kext
Lilu.kext

USBPorts.kextは、USBを15個指定する自作kextです。なくても、USBポートの一部が動かないだけで、macOSの起動には問題ありません。作り方は以下をご覧ください。

ASUS ROG STRIX Z490-G GAMINGのUSBを設定する

SMCSuperIO.kextとSMCProcessor.kextは、CPU温度などをモニターするkextです。これも特に必要なものではありません。使い方は以下をご覧ください。

HWMonitorを使う

FakePCIID.kext, FakePCIID_Intel_I225-V.kextの2個は、マザーボード搭載のEthernetチップを動かすために入れてあります。このマザーボードから新しくなったチップなので、偽装する必要がありました。将来的には不要になるかと思います。これも無くても、LANが動かなくなるだけで、macOSの起動には問題ありません。詳しくはこちらをご覧ください。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

ToolにはOpenShell.efiを入れました。ちなみにOSとブートローダは以下です。

macOS Catalina 10.15.6
OpenCore 0.6.0

config.plistを作る

OpenCore配布パッケージにあるsample.plistを元に、変更を加えてconfig.plistを作っていきます。下記のComet Lakeガイドのページにほぼ従いました。

Desktop Comet Lake | OpenCore Install Guide

ディスプレイの設定は、Radeonのグラフィックスボードを使うので、ヘッドレス用の以下の設定にしました。

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
<dict>
	<key>AAPL,ig-platform-id</key>
	<data>AwDImw==</data>
</dict>

サウンドの設定はこちらをご覧ください。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

ここで使用したconfig.plistを以下で公開しておきます。シリアル番号などは有効な番号が入っていますが、ネットに接続する前に必ず自分用の番号に置き換えてください。

config.plist for ASUS Z490G and 10900K - Pastebin.com

シリアル番号などの作り方は、こちらをご覧ください。

GenSMBIOSを使って機種情報を設定する

動作確認

ほぼ問題なく動作します。動作確認したことは、

スリープ
iGPU (DisplayPortのみ。画面共有は不調)
グラフィックスボード (RX 5700XTとRX 580で確認)
WiFi/Bluetooth

などです。このほかに問題はありません。

ベンチマーク

Geekbench 5でベンチマークしました。マルチコアスコアで10,000超えが目標だったのですが、達成できました。

ちなみにCore i5 10600では6300くらいでした。コア数が6だったので、妥当な値でした。

今回のスコアを実際のMacと比較すると14コアiMac Proと12コアMac Proの中間くらいです。クロックが高いのでコア数が多いMacに勝ってます。Apple Siliconが10,000超えのスコアを出してくれるまでは、Intel搭載デスクトップは安泰な気がします。

ベンチマークを動かしていた時のActivity Monitorです。20コアが働いてます。

iMac20,2が出ました（追記）

Comet Lake-S搭載の27インチ iMacが発表されました。最上位モデルのCPUは10910のようです。Apple用のカスタムチップで一般には販売されないモデルです。10900Kと10900の中間の性能のようです。Geekbenchに上がっているスコアによると以下のようです。10900Kよりはクロックが低いので、スコアは10000前後ギリギリのようです。実機よりちょっと高いベンチマーク結果が得られるところが、自作PC hackintoshの醍醐味だと思います。

まとめ

Core i5 10600で動かしていたマシンのCPUを10900Kに交換しました。全く問題なく動きました。Geekbench 5でのマルチコアスコアは10,000を超えました。Comet Lake-S搭載のiMacが出たら、シリアル番号などをそれに合わせて設定し、本格的に使用したいと思います。

OpenCoreで起動音を鳴らす

Tue, 14 Jul 2020 21:40:03 +0900

OpenCoreでMacの起動音が出るようにしました。起動画面をGUI化した際にインストールしたリソースファイルに起動音のファイルも入っていました。これとAudioDxe.efiを用意し、config.plistに幾つかの設定をすることで、起動音が鳴りました。

今回は、こちらの記事の続きです。

OpenCoreの選択画面をグラフィカルにする

少し前のMacでは起動音が出ましたが、煩わしいので消している人も多かったです。でも、最近のMacでは復活するという噂もあります。そうなると、起動音があっても良いのかなと思い、OpenCoreで試してみることにしました。今回も以下のガイドに従っています。

制限

起動音は、macOSが起動する前に鳴らすので、macOSのドライバーは使えません。コミュニティの皆さんが頑張って作ってくれたドライバーで音を出します。なのでマザーボード上の音源チップからのみ音が出せます。つまり、以下の制限があります。

USBオーディオからは起動音を出せません。
GPUオーディオからは出せる場合もありますしダメな場合もあります。

実際のMacは電源を入れると即座に音が出ます。ファームウェアが音を出しているのでタイミングが早いです。でもHackintoshで起動音の出るタイミングは、電源を入れて、BIOSのスプラッシュ画面が出て、OpenCoreのメニュー選択画面になったところです。電源投入から少し待たされます。ここまで来て、制御がようやくOpenCoreに引き渡されるので、仕方がないところです。

設定手順

音声ファイルを用意する

メニューGUI化の時にアイコンファイルを入手したのと同様に、以下から音声ファイルを手に入れます。

GitHub - acidanthera/OcBinaryData

このうち、OCEFIAudio_VoiceOver_Boot.wavが起動音のファイルです。これをOC/Resources/Audioの中に入れておきます。

ドライバーを用意する

AudioDxe.efiをOC/Driversの中に入れておきます。AudioDxe.efiはOpenCoreの配布ファイルに含まれています。

config.plistを設定する

config.plistをProperTreeで開いて、設定作業を行います。まずはSnapshot機能でAudioDxe.efiを登録しておきます。次に以下の設定を行います。

NVRAM -> Add -> 7C436110-AB2A-4BBB-A880-FE41995C9F82 -> SystemAudioVolume を0x46にする。10進数では70です。
UEFI -> Audio -> AudioSupportをTrueにする
UEFI -> Audio -> MinimumVolumeを50にする
UEFI -> Audio -> PlayChimeをTrueにする
UEFI -> Audio -> VolumeAmplifierを143にする

数字のところはボリュームの設定なので適当で良いようです。ただ、適切な範囲や大小関係の制約はあるようです。

ここまではガイドの例に合わせて設定するだけなので簡単です。問題は、ハードウェアごとに調整しなければならない3個のパラメータです。UEFI -> AudioのAudioDevice、AudioCodec、AudioOutです。

AudioDeviceを設定する

PciRoot(0x0)/Pci(0x1f,0x3)に設定しました。オーディオチップに割り当てられたPCIeのパスを指定します。すでにconfig.plistのDevicePropertiesで、マザーボード搭載コーデックのレイアウト IDが指定してあれば、そこのPciRoot以下の数値です。下の例ならPciRoot(0x0)/Pci(0x1f,0x3)です。

<key>DeviceProperties</key>
<dict>
 <key>Add</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
 <dict>
 <key>layout-id</key>
 <data>AQAAAA==</data>
 </dict>

HackintoolのPCIeボタンからAudio deviceを探して調べることもできます。

またgfxutilというツールを使っても良いです。これを起動すると出てくるHDEFの行に、チップのPCIeパスが書いてあります。

% ./gfxutil | grep HDEF
00:1f.3 8086:a348 /PCI0@0/HDEF@1F,3 = PciRoot(0x0)/Pci(0x1F,0x3)

AudioCodecを設定する

0に設定しました。オーディオチップのアドレスIOHDACodecAddressを設定します。これはioregコマンドやIORegistryExplorerなどで調べることができます。ガイドに従って、以下のようにioregコマンドをタイプしたところ、

% ioreg -rxn IOHDACodecDevice | grep IOHDACodecAddress
 | "IOHDACodecAddress" = 0x0
 | "IOHDACodecAddress" = 0x2

上のように、0番と2番の二つの選択肢がありました。ここでアドレスが1個しか出てこなければ、迷うことなくその数値（たぶん0です）をAudioCodecに書いておけば良いです。ちなみに0番と2番が出てきたマザーボードはASUS ROG MAXIMUS XI HERO Z390です。一方で、ASUS ROG STRIX Z490-Gのマシンでは、IOHDACodecAddressは一個（0番）だけでした。

今回は2個の候補が出てきてしまったので、このどちらかを指定します。どちらかが、マザーボードに搭載されているコーデックです。ちなみにこのマザーボードのコーデックはRealtek ALC1220です。いろいろ調べる方法はあるようですが、ここでは以下のようにしました。まずは、grepの条件を緩めて、前後の情報を表示しました。

% ioreg -rxn IOHDACodecDevice | grep IOHDACodec
+-o IOHDACodecDevice@1F,3,0 <class IOHDACodecDevice, id 0x10000059d, registered, matched, active, busy 0 (1024 ms), retain 27>
 | "IOHDACodecVendorID" = 0x10ec1220
 | "IOHDACodecRevisionID" = 0x100101
 | "IOHDACodecAddress" = 0x0
 +-o IOHDACodecDriver <class IOHDACodecDriver, id 0x1000005a5, !registered, !matched, active, busy 0 (1022 ms), retain 25>
 +-o IOHDACodecFunction@1F,3,0,1 <class IOHDACodecFunction, id 0x1000005a7, registered, matched, active, busy 0 (1022 ms), retain 27>
+-o IOHDACodecDevice@1F,3,2 <class IOHDACodecDevice, id 0x10000059e, registered, matched, active, busy 0 (138 ms), retain 27>
 | "IOHDACodecVendorID" = 0xffffffff8086280b
 | "IOHDACodecRevisionID" = 0x100000
 | "IOHDACodecAddress" = 0x2
 +-o IOHDACodecDriver <class IOHDACodecDriver, id 0x1000005a6, !registered, !matched, active, busy 0 (135 ms), retain 25>
 +-o IOHDACodecFunction@1F,3,2,1 <class IOHDACodecFunction, id 0x1000005a8, registered, matched, active, busy 0 (135 ms), retain 25>

これを見ると、下のIOHDACodecAddressが2番のもののVendorIDに8086という数値が見えます。これはインテル社のものです。一方で、0番には、VendorIDに10ecという数値が見えます。Vendor IDは世界的に決められている番号なので「vendor id 10ec」でGoogle検索すると、メーカの名前が分かります。これは、Realtek Semiconductor Co., Ltd.のIDだそうです。

PCI Devices

ということで、これがRealtekのチップらしいので、AudioCodecには0番を指定すれば良いようでした。

AudioOutを設定する

0に設定しました。こちらは苦労しました。この番号で、オーディオピンの番号を指定するようです。バックパネルにアナログ5本、SPDIFが1本、さらにはマザーボード上にケースのヘッドフォン端子に接続するオーディオ用ヘッダピンもあります。これのいずれかを番号で指定するようです。0番から順番に試すしかないようです。手元のマシンで0番を試したところ、それがバックパネルのスピーカ出力でした。

まとめ

OpenCoreで起動音を出せるように設定しました。ほとんどの作業は、バニラガイドに書いてある通りで簡単ですが、AudioDevice、AudioCodec、AudioOutの設定は、環境に合わせて変更する必要があります。特にAudioOutは手探りでした。起動音は、最後まで鳴る時もありますが、どういうわけか中途で音が出なくなることもあります。起動音がなると、さらに本物のMacっぽくなって良いのですが、ちょっと煩いかもしれません。しばらく楽しむけど、常用はしないと思います。

最近の構成で新旧グラボ (RX 580 vs. RX 5700) 性能を再測定

Sun, 05 Jul 2020 17:45:14 +0900

macOS Catalina 10.15.5, OpenCore 0.5.9, Z490 + 10600の構成で、再度、Radeon RX 580とRX 5700 XTのベンチマークを取り直しました。依然としてRX 580の方が高スコアでした。MacではApple特別仕様のNAVIを採用しているのですが、一般デスクトップ用GPUではドライバーが性能を発揮できないようです。Thunderbolt接続eGPUとして市販グラフィックスボードを使うユーザもいると思うので、対応してくれると良いと思います。

今までもRadeon GPUのベンチマークを紹介しました。

10.15.2にしたけどNaviの性能は向上しませんでした

Z490マシンをバラックで組んでいるので、最新の環境でもう一度ベンチマークをしなおしてみました。使用した機材と構成は以下です。

Intel UHD Graphics 630 (おまけで測定しました)
AMD Radeon RX 580, Sapphire NITRO+
AMD Radeon RX 5700 XT, ASUSのリファレンスファン
macOS Catalina 10.15.5 (19F101)
OpenCore 0.5.9
ASUS ROG STRIX Z490-G GAMING (Wi-Fi)
Core i5-10600
機種ID iMac19,1

Geekbench 5の結果は以下でした。前回の計測から、1回目の測定が良いスコアを出したので、今回は回数をあまりやっていません。ベンチを繰り返すと温度上昇してスコアが低下するのではないかと思います。以下の数値はベンチマークを2-3回実施した平均値です。


GPU	OpenCL	Metal
UHD 630	5020	4782
RX 580	43546	44448
RX 5700XT	41139	35489

グラフにしました。依然としてRX 580の方がベンチマークスコアが高いようです。以前の測定よりもさらに差が開いたような気がしないでもないです。ということで、RX 580がHackintoshに最適な状態はまだまだ変わらないようです。

GenSMBIOSを使って機種情報を設定する

Sun, 28 Jun 2020 10:04:25 +0900

以前、シリアル番号を決めるツールとしてmacserialを紹介しました。macserialを使いやすくしたツールにGenSMBIOSがあります。OpenCoreのガイドでよく使われていますので試してみました。config.plistにシリアル情報などを書きこめて便利でした。

Hackintoshの機種設定

Hackintoshを作ったら、それに機種ID、シリアル番号、UUID情報などのID情報を設定しておく必要があります。正しく設定しないと、macOSが動かないことがありますし、iCloudのサービスが使えないことがあります。さらにはユーザのApple IDが使用禁止にされてしまうこともあります。これらの設定はconfig.plistの中に書きます。CloverではSMBIOSのセクション、OpenCoreではPlatformInfoのセクションに書き込みます。

UUIDなどのIDは世界に一つしかない番号ならばなんでも良いです。uuidgenなどのコマンドで乱数発生させて作れば良いです。またOpenCoreのROM番号はEthernetのMACアドレスを流用するのが一般的です。一方でMacのシリアル番号は、生産地、生産年・週、番号、機種固有番号などから構成されています。全体の構成はMacの世代で違うことがありますし、機種固有番号は機種ごとに違います。シリアル番号の規則をリバースエンジニアリングして、生成・チェックするソフトが作られています。それがmacserialです。シリアル番号の仕組みとmacserialの使い方は、以下の記事で詳しく紹介しました。

Macシリアル番号の仕組み

GenSMBIOSの使い方

最近のOpenCoreのガイドでは、シリアル番号などの機種情報を生成するために、GenSMBIOSというPythonプログラムがよく使われています。これも中ではmacserialを動かしているのですが、より簡単に使えて、さらにconfig.plistへの書き込み機能を備えているので便利です。この記事ではGenSMBIOSを使ってみます。GenSMBIOSは以下からダウンロードできます。

GitHub - corpnewt/GenSMBIOS: Py script that uses acidanthera’s macserial…

ダウンロードするとGenSMBIOS.commandというファイルがあります。これが本体です。Terminal.appでこれを起動します（アイコンをダブルクリックしても良いです）。すると以下のメインメニューが現れます。

#######################################################
# GenSMBIOS #
#######################################################
MacSerial v2.1.2
Current plist: None
Plist type: Unknown

1. Install/Update MacSerial
2. Select config.plist
3. Generate SMBIOS
4. Generate UUID
5. List Current SMBIOS

Q. Quit

Please select an option:

このメニューを順番に説明します。

1. Install/Update MacSerial

最初のメニューは、内部で使用するmacserialの更新です。GenSMBIOS.commandがあるディレクトリの中に、Scriptsというディレクトリがあります。この中にmacserialが入っています。macserialの使い方は、過去の記事を見てください。macserialは、新しいMacが出るたびに、それをサポートするために更新されています。なので、GenSMBIOSのこのメニューは、macserialを最新版に更新します。既存のMacのシリアル番号生成規則も更新されている可能性もありますので、とりあえずは選択しておくのが良いと思います。

 #######################################################
 # Getting MacSerial #
#######################################################
Gathering latest macserial info...
- MacURL: https://github.com/acidanthera/macinfopkg/releases/download/2.1.2/macinfo-2.1.2-mac.zip

Downloading macinfo-2.1.2-mac.zip...
- Extracting...
- Found macserial
- Chmod +x...
- Copying to Scripts directory...

Cleaning up...

Done.

2. Select config.plist

生成したシリアル番号などを書き込む先のconfig.plistを指定します。ここで書き込み先のconfig.plistへのパスを入力するか、もしくは説明にあるとおりそのアイコンをドラッグ&ドロップします。すごいところは、Cloverのconfig.plistにも、OpenCoreのconfig.plistにもどちらにも対応しているところです。

 #######################################################
 # Select Plist #
#######################################################

Current:
Type: OpenCore

C. Clear Selection
M. Main Menu
Q. Quit

Please drag and drop the target plist:

試しに、OpenCoreに付属のデフォルトconfig.plistであるSample.plistをコピーして、config.plistに改名して入力してみました。

3. Generate SMBIOS

GenSMBIOSのメイン機能です。このメニューでSMBIOS情報を生成します。Macの機種IDを聞かれますので、入力します。ここではiMac19,1を指定しました。

 #######################################################
 # Generate SMBIOS #
#######################################################

M. Main Menu
Q. Quit

Please type the SMBIOS to gen and the number
of times to generate [max 20] (i.e. iMac18,3 5): iMac19,1

その結果、シリアル番号、ボードシリアル番号、UUIDが生成されます。2番目のメニューで、変更先のconfig.plistを指定してあれば、それに書き込まれます。指定していなければ、情報が表示されるだけです。その場合はテキストエディタなどで開いたconfig.plistにコピペします。

 #######################################################
 # iMac19,1 SMBIOS Info #
#######################################################

Type: iMac19,1
Serial: C02DN9ZSJV3Q
Board Serial: C020453004NLNV91M
SmUUID: 2BCB8DF6-7633-4F0E-B63C-975E3EFCEDFE

Flushing SMBIOS entry to /Volumes/Users/bootmacos/config.plist

Press [enter] to return...

今回は、前述のようにデフォルトのSample.plistと同一内容のconfig.plistを変更するように指定してあります。どのように変更されたかを確認するために、diffコマンドでconfig.plistと、元データのSample.plistを比較してみました。一見、多くの差分があるように見えますが、実は、

% diff config.plist Sample.plist
134,136c134
< <data>
< Q3B1UG0AAAA=
< </data>
---
> <data>Q3B1UG0AAAA=</data>

とあるように、元のSample.plistで情報という1行で記述された内容が、GenSMBIOSの処理により3行に分けられただけの場所が多いです。このような変更点を除いた、実質的に差分のある場所は、以下でした。

% diff config.plist Sample.plist

(略)
893c824
< 			<string>C020453004NLNV91M</string>
---
> 			<string>M0000000000000001</string>
903c832
< 			<string>C02DN9ZSJV3Q</string>
---
> 			<string>W00000000001</string>
905c834
< 			<string>2BCB8DF6-7633-4F0E-B63C-975E3EFCEDFE</string>
---
> 			<string>00000000-0000-0000-0000-000000000000</string>

ということで、000000…などの数値で仮に書かれていたシリアル番号、ボードシリアル番号、UUIDの場所だけが、今回新しく生成されたデータで書き直されていることがわかります。

なお、シリアル番号は、下記のサイトでそれが未使用であることを確認しておくべきです。ここで生成された番号を入力し、「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば、その番号は未使用です。今回生成した番号はOKでした。

Check Your Service and Support Coverage - Apple Support

4. Generate UUID

これはおまけ的な機能だと思いました。UUIDだけを生成します。uuidgenというコマンドを動かしているだけだと思います。ちなみにこのメニューを選択しても、config.plistには書き込まれません。

#######################################################
# Generated UUID #
#######################################################

773F1659-07F1-4130-8C3B-FE2F900F9E95

Press [enter] to return...

5. List Current SMBIOS

これは現在起動中のマシンの情報を表示します。上のメニューで指定したconfig.plistファイルの内容ではありません。macserialの–infoオプションと同様に、シリアル番号の分析と有効性を表示してくれます。

まとめ

GenSMBIOSコマンドで、シリアル番号を生成して、config.plistに書き込む作業が楽になります。その過程で、シリアル番号が有効かどうかをAppleのサイトで確認しておく必要はあります。また、このコマンドでは、OpenCoreのconfig.plistにおけるPlatformInfo–>Generic–>ROMの設定は行ってくれません。Sample.plistでは0x112233445566になっています（Base64ではESIzRFVm）。任意の6バイトの数値で良いのですが、唯一の数字にしておくべきです。通常はEthernetのMACアドレスに設定しておくと良いようです。生成したシリアル番号は大抵の場合未使用ですし、ROMの値もAppleによって厳しくチェックされる情報でもありませんので、GenSMBIOSで設定すれば、とりあえずは起動してしまっても大丈夫だと思います。

Big Sur

Tue, 23 Jun 2020 11:20:06 +0900

macOS 11.0 Big Surインストールに関する情報をメモしておきます。

機種設定

Big Surは、以下のIntel Macで稼働します。

MacBook：2015年 (MacBook8,1) 以降
MacBook Air：2013年 (MacBookAir6,1) 以降
MacBook Pro：2013年後半（Late 2013）(MacBookPro11,1) 以降
Mac mini：2014年 (Macmini7,1) 以降
iMac：2014年 (iMac14,4) 以降
iMac Pro：全モデル (iMacPro1,1)
Mac Pro：2013年 (MacPro6,1) 以降

なので機種設定は上の機種ID以降の番号にしないと起動しません。

追記：MacBookPro11,1とMacBookPro11,2も避けた方が良いらしいです。

Apple、アップグレード後に起動しなくなる不具合が確認された2013~2014年製のMacBook Proのサポートを一時的に中止した「macOS Big Sur 11.0.1 Build 20B50」をリリースしています。

ブートローダー

OpenCoreとCloverで起動することができます。ただ、OpenCoreが主流になりつつあるので、よくサポートされていて良いと思います。

Big Surがリリースされた時点でのOpenCoreは0.6.3でしたので、それ以降のバージョンを使うと良いです。Kext Updaterなどで、最新リリース版を使えば良いです。

Kext類

Kext Updaterで得られる最新版を使用しておけば良いです。

USB起動インストーラ

従来通り、createinstallmediaコマンドで起動USBインストーラを作ることができます。

macOS の起動可能なインストーラを作成する方法

インストール例

Big SurをインストールしたインストールやフォーラムトピックスをBig Surのタグをつけてまとめておきます（準備中）。

Big Surをクリーンインストールする (OpenCore + Z490)

Big Surをクリーンインストールする (OpenCore + Z390)

ASUS ROG STRIX Z490-G GAMINGのUSBを設定する

Fri, 12 Jun 2020 22:18:10 +0900

ASUSのZ490マザーボードのUSBポートを調査して、USBPorts.kextを作りました。レジストリに何故か現れないオンボードUSB 2.0ピンの割り当てを探し当てました。また、15個制限撤廃パッチが危険なことを確認しました。

USBポート設定の手順

前回作成したASUS Z490マザーボードマシンのUSBポートを設定し、El Capitanで導入されたUSBポート数15個制限に対処します。このマシンのOSはmacOS Catalina 10.15.5でブートローダーはOpenCoreです。

Comet Lake-S 10600とZ490でmacOSを動かす

USBポート設定の方法はこちらで紹介した方法です。

15個制限のためのUSBPorts.kextをHackintoolで作る

以下の手順で行います。この作業のツールには、ProperTreeとHackintoolを使います。

一時的に15個制限を撤廃して全部のUSBポートが見えるようにします。
USBコネクタに無線ドングルやメモリを挿して、ポートが割り当てられた名前を特定します。
15個以内で使用したいポートを選びます。
使用する15個以内のポートとそのコネクターを記述したUSBPorts.kextを作ります。
15個制限撤廃を中止して、USBPorts.kextを有効にして再起動します。

15個制限を撤廃する

ポートの調査のために、OpenCoreのUSB 15個制限撤廃quirkであるXhciPortLimitを使います。まず、エディタやProperTreeなどでconfig.plistを開いて、XhciPortLimitをtrueにします。つぎに再起動して、HackintoolでUSB一覧を見ると、レジストリーに現れるXHCポートの一覧が出ます。このマザーボードでは、以下のように21個のポートが見えていました。Hackintoolでは既にZ490マザーボードにも対応してくれているらしく、コントローラ名にComet Lakeの文字が読めます。

上の図では、HS11にだけデバイスが見えます。操作のために、以前紹介したトラックパッド付き無線キーボードを使っているので、その2.4 GHz無線ドングルが見えています。2.4 Gの文字の続きは文字化けしています。（「システム情報」で確認したら意味不明の漢字の羅列になってました。）

格安のトラックパッド付き無線キーボード

USBポートを特定する

初期状態では、Connectorの種類がでたらめです。またCommentの欄は空白です。そこで、USB 2.0と3.0のUSBデバイスをポートに一つ一つ挿しては外して調べます。バックパネルに出ているUSBポートはType-AとType-Cのコネクタになっているので調査は簡単です。でもマザーボード上のコネクタは通常のUSBコネクタではなく、内部接続用のヘッダピンとType-C用の特殊なコネクタ (Key-Aという名前らしいです) です。そこで、従来型USBヘッダピンをType-Aに変換するアダプター（と）と、を、それぞれ用意しました。

試験のために使うUSB 2.0デバイスには、出所不明のUSB WiFiドングルを使いました。USBメモリを使うと外す時にアンマウントの手間が不要ですが、無線ドングルならいきなり抜けます。USB 3.0のデバイスとしてはUSBメモリーを使いました。USBデバイスを挿していくと、Hackintoolの一覧の該当するポート名の行にデバイスの情報が現れます。これにより、ポート名と実際のポートの割り当てが特定できます。この時に、そのポート名のコネクタータイプ (USB2, USB3, Type-C Sw, Type-C, Internalのいずれか）を選択しておきます。またコメント欄に、対応する物理ポートの情報を英語でメモ書きしておくと、その内容がkextに反映されます。将来のメンテナンスなどの時に便利です。

バックパネルのType-Cは、反対向きに挿しても同じSS04に接続されました。これはスイッチで切り替えているようなのでコネクタタイプをTypeC+Swに設定します。一方で、オンボードのType-Cは、反対向きに挿すとそれぞれSS05とSS06に接続します。なのでUSB 3.2が2本使われている本格的なTypeCのようです。この作業により、上の図のポートの全てが、それぞれバックパネル（ASUSの仕様書に合わせてRearとコメントしました）とマザーボード上（仕様書に合わせてFrontとコメントしました）のUSBコネクタであることを確認しました。こうして完成したUSBポート一覧が以下です。何故かHS06が見当たりません。

オンボードUSB 2.0が見つからない

上の結果では、Z490-Gマザーボード上のUSB 2.0が見つかりませんでした。これは、昔ながらの黒いピンヘッダで、マニュアルにUSB_E12とUSB_E34と書かれています。

一つのヘッダピンに2個のUSB 2.0が配線されているので、合計4個のUSB 2.0が行方不明です。マザーボードのヘッダピンに、Type-A変換アダプタを挿して、USBデバイスを付けても、HackintoolやIORegistryExplorerの一覧に出てきません。USBメモリを付けても、マウントされずファインダーにも現れません。Windowsでは試していませんが、BIOSではここに挿したUSBメモリが起動ドライブとして見えています。macOSだけの問題のようです。Hackintoshで、純正WiFi/BluetoothモジュールをPCIe接続する場合、基板上のUSB 2.0ヘッダピンに信号を接続するのが一般的です。USB 3.1の2.0信号ピンに接続しても良いのですが、コネクタを付け替えるのが面倒です。なので、できればマザーボード上のUSB 2.0ヘッダピンを使いたいところです。

そこで怪しいのが欠番のHS06です。上のUSBポート一覧はHackintoolの画面をですが、IORegistryExplorerで調べてもやはりHS06は見えません。見えていないHS06がオンボードUSB 2.0である可能性が高いです。ASUSの最近のマザーボードでは（Z390がそうでしたが）オンボードのUSB 2.0は、USBハブを通して分割されて実装されているようです。このマザーボードも、HS06をハブで4個に分割してヘッダピンに接続していると思われます。もしかしたらハブを使っているために、レジストリーに現れないのかもしれません。

ということで、HackintoolのExportボタンで作ったUSBPorts.kextのInfo.plistに、HS06のエントリーを追加してみることにしました。具体的には、以下の記述を、HS05とHS07の記述の間に挿入しました。base64のBgAAAA==は、0x06000000です。

<key>HS06</key>
<dict>
 <key>Comment</key>
 <string>Front USB 2.0 (USB_E1234)</string>
 <key>UsbConnector</key>
 <integer>255</integer>
 <key>name</key>
 <string>HS06</string>
 <key>port</key>
 <data>
 BgAAAA==
 </data>
</dict>

こうして作成したUSBPorts.kextを使って起動した結果が以下です。目論見通り、HS06が現れて、それがUSB2.0 Hubに接続されている様子が表示されました。この状態で、Type-Aアダプタを経由してUSBメモリを接続すると、macOSのファインダー上に正しくマウントされました。

ここで作成したUSBPort.kextのInfo.plistを以下に公開しておきます。

USBPorts.Info.plist_ASUS_Z490G - Pastebin.com

注意していただきたいのは、このplistの中の、25行目と344行目です。それぞれ、

<key>iMac19,1-XHC</key>

と

<string>iMac19,1</string>

となっています。これは機種IDをiMac19,1にした場合の設定です。実はこの後、iMac20,1が発売されたので、config.plistの設定をCPUが合致するiMac20,1に変更しました。そしたらこのkextが動かなくなって悩んだのですが、ここに機種ID依存の設定が入っていました。Hackintool.appは、稼働しているマシンの機種IDを自動的に書き込んでくれます。なので、後から機種IDを変更する場合は、ここも変更する必要があります。

ASUS Z490-GのUSBポート一覧

ASUS Z490マザーボードROG STRIX Z490-G GAMINGのUSBポートは以下のように割り当てられていました。このマザーボードを使う方は参考になさってください。

HS01：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から1番目（基板から遠い方）
HS02：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から2番目
HS03：リアパネルEthernet直下のUSB 3.2 Gen 2 Type-A
HS04：リアパネルUSB 3.2 Gen 2 Type-C
HS05：マザーボード上のUSB 3.2 Gen 2 Key-A
HS06：ハブ経由でマザーボード上のUSB 2.0 USB_E12とUSB_34に接続
HS07：マザーボード上のUSB 3.2 Gen1 U32G1_78
HS08：マザーボード上のUSB 3.2 Gen1 U32G1_78
HS09：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から3番目
HS10：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から4番目（基板側）
HS11：リアパネルに2個あるUSB 2.0 Type-Aの上（基板から遠い方）
HS12：リアパネルに2個あるUSB 2.0 Type-Aの下（基板側）
SS01：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から1番目（基板から遠い方）
SS02：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から2番目
SS03：リアパネルEthernet直下のUSB 3.2 Gen 2 Type-A
SS04：リアパネルUSB 3.2 Gen 2 Type-C
SS05：マザーボード上のUSB 3.2 Gen 2 Key-A
SS06：マザーボード上のUSB 3.2 Gen 2 Key-A
SS07：マザーボード上のUSB 3.2 Gen1 U32G1_78
SS08：マザーボード上のUSB 3.2 Gen1 U32G1_78
SS09：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から3番目
SS10：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から4番目（基板側）

リアパネルの配置は以下になりました。

マザーボード上のUSBピンの割り当ては以下です。

15個のポートを選別する

こうして全てのポートがHackintoolに現れるようになったところで、全部で15個になるように選別します。今回は、マザーボード上のUSB 3.1ポートを全て使わない設定にしました。バックパネルのポート全てと、マザーボード上のUSB 2.0ポートだけを有効にします。ということで、以下の15個のポートを使うことにしました。

HS01：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から1番目（基板から遠い方）
HS02：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から2番目
HS03：リアパネルEthernet直下のUSB 3.2 Gen 2 Type-A
HS04：リアパネルUSB 3.2 Gen 2 Type-C
HS06：ハブ経由でマザーボード上のUSB 2.0 USB_E12とUSB_34に接続
HS09：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から3番目
HS10：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から4番目（基板側）
HS11：リアパネルに2個あるUSB 2.0 Type-Aの上（基板から遠い方）
HS12：リアパネルに2個あるUSB 2.0 Type-Aの下（基板側）
SS01：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から1番目（基板から遠い方）
SS02：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から2番目
SS03：リアパネルEthernet直下のUSB 3.2 Gen 2 Type-A
SS04：リアパネルUSB 3.2 Gen 2 Type-C
SS09：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から3番目
SS10：リアパネルに4個あるUSB 3.2 Gen 1 Type-Aの上から4番目（基板側）

HackintoolのExportボタンを使って15個制限版USBPorts.kextを作ります。全部を有効にしたUSBPorts.kextは、後に使用するポートを変更する場合に再利用できるので、USBPorts_all.kextというように改名して保存しておくことにしました。個数を制限したUSBPorts.kexを使い、XhciPortLimitをfalseにして起動したところ、以下のようになりました。全部で15個が有効になっています。マザーボード上のUSB 2.0 (HS06) も使えているので無線カードの使用にも問題ありません。

15個制限撤廃パッチは危険

今回の作業中に、USBポート一覧表に異常な現象が発生して、15個制限撤廃パッチはやはり危険なのではと実感しました。そのことをご紹介します。

USBポート一覧表をもう一度見てみましょう。上の一覧にUSBコントローラ（XHC）の情報が書いてあります。そのIDが0x14です。USB Portsの一覧には、Location IDの項目があり、XHC IDの0x14に引き続き1番から番号が振られています。つまり、0x141, 0x142, 0x143, …と順番にLocation ID番号が振られています。OpenCoreのマニュアルによると、macOSのLocation IDが4ビットしかないのに無理して個数を増やしているのが、15個制限撤廃パッチの問題点だと書いてありました。なので、macOSが正式に使っているLocation IDは、この場合、0x141から0x14Fまでの15種類だと思われます。パッチで15個以上のポートを有効にしてしまったので、0x14Fの次に来るSS05はIDが0x140になり、次のSS06以降では再び0x141に戻ってしまっています。つまりSS06以降のポートには、HS01以降のポートと同じLocation IDが割り当てられてしまっています。

Location IDが重複していては、何かの不具合が出ても不思議ではありません。さらには、本来割り当てされないはずの0番、つまり0x140のIDが割り当てられていることも問題のようでした。

ポートを調査している段階では、Location ID 0x140はSS05に割り当てられていました。これはマザーボード上のType-C (key-A) のUSB 3.1 Gen2の2個のうちの一つでした。ここにMacBookなどで使用する以下のようなType-Cアダプタ

を接続した時の一覧を下に示します。このアダプタには、USB 3.1 Gen1 Type-Aが3個、HDMIコネクタ、SDカードリーダーが装備されています。その結果、SS05に変換器の中にあるUSB3.0 Hubが現れています。また、HS05にもUSB 2.0 Hubが現れています。ここまでは正常なのですが、リアパネルに接続されているはずのHS03にも何故かUSB3.0 Hubが現れ、さらにはこれもリアパネルのHS04にも、NS1081という謎のデバイスが現れています。しかも、HS03に現れるUSB3.0 Hubの表示は、現れたり消えたりを毎秒数回繰り返し不安定です。謎のデバイスであるNS1081を検索したところ、SDカードなどをUSB接続するコントローラチップのようです。アダプタ内部のハブとデバイスが、全く関係ないポート(HS03とHS04)に不安定に現れてしまっているようです。ちなみにType-Cの向きを変えて、USB 3.1としてSS06の方を使用すると、このような不具合は発生しませんでした。本来使用されない0番のLocation ID (0x140) が割り当てられたSS05ポートが活性化してしまったので、このような不具合が発生しているのではと思われます。15個制限をパッチで回避したための副作用なのでしょう。

今回行ったように、15個を指定するkextを作って、XhciPortLimitをfalseにしていれば、このような異常現象は発生しません。15個制限撤廃パッチは、インストール直後の調整用の場面でのみ使用し、使い続けない方が良いと思いました。

まとめ

ASUSのROG STRIX Z490-G GamingマザーボードのUSBポート名を特定して、使用する15個を選択するkextを作りました。無線カードで使用するオンボードのUSB 2.0がレジストリに現れないので、kextで指定したところ認識できました。また15個制限撤廃するパッチは副作用があることがわかりました。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

Sun, 07 Jun 2020 16:27:15 +0900

前回紹介したASUSのZ490マザーボードで、動かなかったオンボードオーディオとEthernetが動きました。少しトリッキーな方式のような気がしますが、hackintoshコミュニティのサポートが充実するまでのつなぎとしては十分です。

追記：OpenCore 0.6.0とAppleALC.kext 1.5.1になり、オーディオはレイアウトID（このマザボは7）を指定するだけで動くようになりました。こちらをご覧ください。

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

参考にしたページ

前回は、OopenCoreのComet Lake-S　バニラインストールガイドに従って、正攻法なインストールを行いました。そのためか、マザーボード搭載のオーディオコーデックと2.5 Gbps Ethernetが動きませんでした。

Comet Lake-S 10600とZ490でmacOSを動かす

OpenCoreのバニラガイドが出る前に、SchmockLoadさんがGIGABYTE Z490 Vision Dにインストールした様子をGitHubにまとめてくれていました。そこでは、オーディオも2.5 Gbps Ethernetも動いているようです。今回はこれを参考に作業しました。

GitHub - SchmockLord/Hackintosh-Intel-i9-10900k-Gigabyte-Z490-Vision-D: https…

オーディオを動かす

追記：オーディオに関するこの節の情報は古いです。こちらをご覧ください。

今回使用しているマザーボードに搭載されたコーデックはRealtek ALC1220です。もしかしたらALC1220Aなのかもしれません。ASUSはSupremeFX S1220Aと呼んでいます。300シリーズマザーボードでも搭載されていたコーデック（そちらはSupremeFX S1220無印）と数字部分は同じです。なので、AppleALC.kextで動くと思ったのですが、簡単には動きませんでした。

そこで、上記のSchmockLoadさんのGitHubガイドに従って、以下のkext、

FakePCIID.kext
FakePCIID_Intel_HDMI_Audio.kext

を追加し、config.plistのDevicePropertiesに

<key>DeviceProperties</key>
<dict>
 <key>Add</key>
 <dict>

（略）

 <key>PciRoot(0x0)/Pci(0x1F,0x3)</key>
 <dict>
 <key>device-id</key>
 <data>cKEAAA==</data>
 <key>layout-id</key>
 <data>BwAAAA==</data>
 </dict>

を追加しました。FakePCIIDの仕組みはこちらで説明されてます。ちゃんと理解できていないのですが、PCIeのデバイスIDを、macOSのドライバが認識するIOPCIDeviceに結びつけてくれる機能のようです。本体がFakePCIID.kextで、デバイスIDの情報だけが書いてあるInfo.plistだけのkext（今回の場合はFakePCIID_Intel_HDMI_Audio.kext）と組み合わせて使います。これによりmacOSが認識しないIDのデバイスを動かしてしまおうという機能のようです。

FakePCIID_Intel_HDMI_Audio.kextは、その名前の通り、100, 200, 300シリーズのHDMIオーディを実現する目的で作られているようです。今回の場合に当てはまるのか疑問でした。説明を見ると、100シリーズ以降で0xA170もしくは0x9D70のデバイスIDを使えるようにしてくれるようです。ここでは0xA170を使っています。これを動かすためには、動かしたいオーディオデバイスの、ACPIに現れるデバイスIDを0xA170に変更しておく必要があります。それが上記のconfig.plistの記述です。

Hackintoolで確認してみます。オーディオチップはPci(0x1f,0x3)のPCIeデバイスパスに配線されています。そのデバイスIDは0x06C8でした。

上記のconfig.plistを使うと、このデバイスIDが0xA170に変更されていることがわかります。デバイス名も、100 Series/C230 Series Chipset Family HD Audio Controllerと表示されるようになっています。それでも実際のコーデック名とはちょっと違う気がしますが、これで音声が再生されるようになりました。

Z490マザーボードでのサウンドチップの変更は、おそらくはデバイスIDなどが多少変更された程度の違いと思いますので、そのうちにAppleALC.kextが対応してくれるのだと期待しています。それまではこの対応で凌げると思います。

Ethernetを動かす

このマザーボードに搭載されているEthernetチップは、2.5 GbpsのIntel I225-Vです。上位のマザーボードでLANが2個あるタイプのものは、もう片方が従来と同じ1 GbpsのIntel I219-Vだったりします。I219-Vは300シリーズでも使われたチップなので、IntelMausi.kexe, IntelMausiEthernet.kextで動くようです。でもi225-Vしか搭載されていないマザーボードは有線LANに接続できません。

こちらも、オーディオと同様に、FakePCIIDを使って解決できました。FakePCIID_Intel_I225-V.kextが設定をしてくれます。

FakePCIID.kext
FakePCIID_Intel_I225-V.kext

また同様にconfig.plistでEthernetチップのデバイスIDを0x15F2に設定します。ちなみにこのマザーボードでは、元々のデバイスIDは0x15F3でした。

	<key>PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)</key>
	<dict>
		<key>device-id</key>
		<data>8hUAAA==</data>
	</dict>

SchmockLoadさんによるとFakePCIID_Intel_I225-V.kextを作ってこの設定を紹介したのはドイツのHackintosh-forum.deのBrumbaerさんだそうです。GitHubにあるconfig.plistの例では

 <key>PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0)</key>

になっていますが、上記のHackintoolの一覧に現れているように、ASUSマザーボードではデバイスpathが違うようです。

 <key>PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)</key>

を指定したところ動きました。これでネット接続できるようになりました。おそらくはIDを偽装して、macOS標準のドライバで動かしているのだと思われます。とはいえ、1Gbpsのハブに接続して使用したところでは、速度が遅いとか、データが滞るなどの問題は感じられませんでした。IntelMausi.kextが対応するまでのつなぎとして十分に使用できそうです。

Geekbench 5でベンチマーク

ネットに接続できるようになったので、Geekbenchで測定しました。Geekbenchは結果がweb上で表示されるので、ネット接続してないと起動できませんでした。結果は、以下のようにマルチコアスコアで6000越えでした。

現行の非BTO版最上位iMacは3.7 GHz 9600Kを搭載しています。は無印なので（K付きは未発売でした。今もかな？）クロックが遅い (3.3 GHz) です。でも9600Kでは無効にされたハイパースレッドが復活しています。互角の性能である気がしましたので、Geekbench Browserで9600K搭載iMacのスコアを検索してみました。

マルチコアスコアが5000を切ったスコアも、6000を超えたスコアもありましたが、大半が5000代でした。結局、クロックが10%くらい低下しても、ハイパースレッドが効いたのか、10600無印の方が高速のようです。

まとめ

10600搭載Z490マザーボードの自作マシンでマザーボード搭載のオーディオとEthernetが動きました。AppleALC.kextとIntelMausi.kextが対応してくれるまでのつなぎとして使えます。ネットが動いたのでGeekbench 5でベンチマークをしました。これに相当する性能と思われる9600K搭載のiMacより高いスコアが出ました。

Comet Lake-S 10600とZ490でmacOSを動かす

Sat, 06 Jun 2020 00:07:34 +0900

を搭載したASUSのZ490マザーボードに、OpenCoreで起動するmacOS Catalinaをインストールしました。とりあえずは動く状況です。CPU, iGPU, スリープは動いていますが、オンボードのEthernet, サウンドがまだ動きません。

参考にしたページ

SchmockLoadさんが、GIGABYTE Z490 Vision Dにインストールした様子をGitHubにまとめてくれていたので最初はこれを参考にしていました。でも作業を進めているうちに、OpenCoreが0.5.9になり、ガイドのページも更新されて、なんとComet Lake-S用のconfig.plistを作るガイドが追加されました。

Desktop Comet Lake | OpenCore Install Guide

ということでこのガイドを参考に、作業を進めました。

使用ハードウェア

マザーボード

使用したマザーボードは、です。サブマシンがmicro-ATXなので、ゆくゆくはそれに搭載しようと考えました。メインマシンがASUSなので、同じメーカにしました。しっかりした作りでよくできています。製品写真ではバックパネルカバーのロゴが黄色です。でもこれはフルカラーLEDなので、Windowsからならば何色にも設定できると思われます。デフォルトでは時間と共に色が変化します。

は2,000円安いです。IntelのWi-FiアダプタをmacOS互換のM.2無線カードに差し替えたら、数が少ないm-ATXマザボのPCIeスロットを節約できると思いWi-Fi付きにしました。300シリーズチップセットマザーボードなら、CNViカードだけでなく、一般のM.2無線カードが使えました。なのでmacOSと互換性のあるBroadcomのM.2カードが使えました。しかし新しいマザーボードは、ソケットの物理的な形状はM.2でしたが、動作しませんでした。CNVi対応カードだけが動くようになったようです。なのでWi-Fi無しの方が良かったかもしれないです。そのうち、マザーボード上のSSD用M.2ソケットに無線カードを取り付けて、バックパネルのアンテナ端子だけを利用しようと考えています。

CPU

どうせなら話題の10コア20スレッドの10900Kを使おうかとも思いました。でも、当初はComet Lake-SがmacOSで動くかどうか不明でしたので、日和って安価な6コア12スレッドの10600無印にしました。10900Kが品切れで入手不可能だったことも理由です。とはいえ同じ6コア12スレッドなら、Ryzen 5 1600 (AF) の方がコストパフォーマンスが良いですね。

BIOS設定

BIOSの設定は、ほぼ工場出荷時設定で大丈夫です。Legacy USBをdisabledにするなど、やっておけば良い程度の変更をしました。デフォルト設定のままでmacOSの起動に支障をきたすことはありません。

使用したefiとkext

ACPIには

SSDT-AWAC.aml
SSDT-EC-USBX.aml
SSDT-PLUG.aml

を入れました。Driversには、

VBoxHfs.efi
OpenRuntime.efi
OpenCanopy.efi

を入れました。Kextsには、

WhateverGreen.kext
VirtualSMC.kext
Lilu.kext
IntelMausi.kext (動かないのでつづきの記事では外しました)
AppleALC.kext

を入れ、ToolにはOpenShell.efiを入れました。ちなみにOSとブートローダは以下です。

macOS Catalina 10.15.5
OpenCore 0.5.9

config.plistを作る

OpenCore配布パッケージにあるsample.plistを元に、変更を加えてconfig.plistを作っていきます。上記のサイトのComet Lakeのページにほぼ従いました。とはいえ、以前紹介したCoffee Lakeとほぼ同じ設定です。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

まずは、上記のefi, kextファイル類を所定の場所に収めた後、Proper TreeのOC Clean Snapshot機能を使って、これらの設定を終えます。これで半分くらいの作業は終了です。次に残りの項目を設定していきます。とはいえほとんどはsample.plistにあるデフォルト値のままで良いです。

Comet Lake-Sは、Macで搭載されたことのない最新CPUなので、Core 2の時代の古いCPUに偽装しないと動かないという報告が多くありました。CPUの偽装には、config.plistのKernel, Emulateの項目を使います。ところが、macOS 10.15.5からComet Lake-Sがサポートされて、Emulateに何も設定しなくても動くようになったそうです！。

<key>Emulate</key>
<dict>
	<key>Cpuid1Data</key>
	<data></data>
	<key>Cpuid1Mask</key>
	<data></data>
</dict>

また、iGPUのig-platform-idも解明されているようです。ディスプレイ接続用と、ヘッドレス用それぞれに対しての推薦のig-platform-id値が、ガイドのページに書かれています。今回は、ディスプレイ接続用の以下の設定にしました。

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
<dict>
	<key>AAPL,ig-platform-id</key>
	<data>BwCbPg==</data>
</dict>

動いたこと

ということで、思いのほか順調に動作しました。CPUは完全に動いています。ターミナルからCPU名を問い合わせると、名前とクロック数が正しく返ってきます。

% sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i5-10600 CPU @ 3.30GHz

iGPUも機能しています。下のスクリーンショットでわかるように、ドックの背景が半透明です。グラフィックス加速が正しく機能しています。ただし、Display Portのみ機能し、HDMIでは出力できないです。グラフィックスボードを使用する予定なので、これで十分です。

追記：iGPUをしばらく使ってみたのですが、「画面共有」を設定しても他マシンから接続できませんでした。コンソール.appからsystem.logを見ると、他のマシンから接続した際に、screensharingサービスが中断シグナルを受けて落とされているようでした。sshやsmbのサービスは問題ありませんのでネットワークの問題ではなく、iGPUの問題だと思われます。後でグラフィックスボード（Radeon RX5700XT）を接続してそちらで動かしたところ、「画面共有」を受け付けられるようになりました。iGPUはHDMI出力できないこともありますし、使わない方が良いと思いました。

スリープも正しく動いています。スリープすると画面が消え、CPUファンが停止します。キーボードを押すと復帰して、画面が現れます。遮断も正しく行われます。

動かないこと

追記：Ethernetとオーディオは動きました。詳しくは「つづき」の節のリンクを見てください。

IntelMausi.kextを使っていますが、Ethernetが動きません。400シリーズからEthernetチップが、2.5 GbitのIntel I225-Vになりました。新しいチップなので、IntelMausi.kextの元になっているLinuxのドライバでもまだサポートされていないらしいです。SchmockLoadさんのガイドによると、I225-Vが動いたようなことが書いてありますのでもう少し確認します。

マザーボード搭載オーディオが動いていません。上記のOpenCoreのガイドによるとオーディオチップは、PciRoot(0x0)/Pci(0x1b,0x0) にマップされていると書かれています。でも、Coffee Lakeの時と同様に、これはPciRoot(0x0)/Pci(0x1F,0x3) ではないかと思っています。というのは、こちらの設定にすれば、システム環境設定、サウンドに、オーディオ端子の一覧が表示されるからです。ただ、音の再生はされません。ASUSの仕様によると、300シリーズはSupremeFX CODECs S1220で、400シリーズはS1220Aなのだそうです。SupremeFXはASUSが付けた名前で、実際にはALC1220が使われているようです。AppleALC.kextでサポートしているALC1220のlayout-idは全部試しました。これももう少し確認します。

まとめ

Comet Lake-SでmacOSを動かしました。CPUは偽装することなく使用できました。DP経由のiGPUグラフィックスが加速状態で使用可能でした。スリープも動きます。~~一方で、LANとオーディオがまだ動いていません。~~もう少し確認していきたいと思っています。

つづき

その後の展開です。安定して動いているので、このままメインマシンにしても良いと考えています。

ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす

ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）

ASUS ROG STRIX Z490-G GAMINGのUSBを設定する

Z490マザボ搭載WiFiをmacOS対応品に交換する

ASUS ROG STRIX Z490-G, 10900K

macOS 10.15.6へのアップデートをシステム環境設定から行いました。問題なくアップデートできました。（2020/7/16）

OpenCoreを0.5.9に更新

Fri, 05 Jun 2020 00:32:55 +0900

Kext Updaterを起動したらOpenCoreの0.5.9が来ていました。OpenCoreに移行してから初めてのアップデートだったので、戸惑いました。使用しているefiファイル類を、ダウンロードされたEFIフォルダの中のefiファイルで一つ一つ置き換えました。問題なく動いているので、この方法で正しく更新できたかと思ってます。

追記：コメントで指摘いただいて気付きました。上の作業ではconfig.plistはそのまま流用していましたが、0.5.9に添付してきた新しいsample.plistを見ると、形式が多少変更されているようです。BlockというキーがDeleteに変更されていたり、Quirksが入れ替わったりしていました。ガイドのページの内容も0.5.9に対応しているので、古いconfig.plistと比較しつつ、新しいsample.plistを元に新しいconfig.plistを作るのが良いようです。Proper TreeのOC Clean Snapshot機能を使えば、ACPI, Drivers, Kexts, Toolsの内容は反映されるので、比較する場所はそれほど多くないです。また、Proper Treeを使えばキーの内容をまとめて削除・コピーできるので、古いconfig.plistからの設定の移行作業も楽でした。

カーネル読み込みメモリ空間を確保する (OpenCore編)

Tue, 02 Jun 2020 23:10:12 +0900

macOSが起動する時、ブートローダがカーネルをメモリに読み込みます。この時、連続した十分な大きさのメモリ領域が確保できないと、起動に失敗して禁止マークが出ます。この状況への対処方法が、OpenCoreではCloverよりも充実しています。

以前の記事では、メモリの使用状況（メモリマップ）を確認して、空き領域を起動オプションのslide値で指定することで、カーネル用メモリを確実に確保する方法を紹介しました。今回はそのOpenCore編です。

slideでカーネル読み込み番地を調整する (Clover編)

以下のOpenCoreのガイドで、この問題への対処方法が詳しく説明されています。以下はこのサイトの抄訳です。

KASLR Slide値を設定する

このページでは、 “Couldn’t allocate runtime area” (ランタイム領域を割り当てられませんでした) というエラーを理解し、修正したいユーザーのために説明します。これは Z390, X99, X299 などで最もよく現れるエラーです。このページはOpenCoreだけでなく、Cloverも対象にします。

KASLRとは何か？

KASLRは、Kernel address space layout randomizationの略で、セキュリティ目的で使用されます。これにより攻撃者がメモリ内の重要なオブジェクトがどこにあるのかを把握するのを難しくします。

HackintoshでKASLRが問題になるのは、マザーボードに連続した十分なサイズのメモリー空間がなく、カーネルが完全に収まらない場合です。そこで、slide=xxx を使って、KASLRをキャンセルしてメモリーアドレスを固定していました。このパラメータを設定すると、macOSに起動ごとに動作するランダムな領域にカーネルを読み込む代わりに、動作することがわかっている場所を使用します。

このガイドが必要な人達

カーネルを読み込むメモリ空間が足りなかったり、細分化されたメモリー空間に読み込み場所が移動してしまったユーザーのためのガイドです。その場合、このようなエラーが出ます。

Error allocating 0x1197b pages at 0x0000000017a80000 alloc type 2
Couldn't allocate runtime area

以下のようなエラーが出ることもあります。

Only 244/256 slide values are usable!

または、macOSの実行中にカーネルパニックが発生することもあります。

panic(cpu 6 caller 0xffffff801fc057ba): a freed zone element has been modified in zone kalloc.4096: expected 0x3f00116dbe8a46f6 but found 0x3f00116d00000000

これらのエラーの1番の特徴は、発生にランダム性があることです。大抵は20回も起動を繰り返せば、1回くらいはエラーを出さないで起動します。

問題解決の方法

これを修正するのは非常に簡単で、その手順はCloverユーザでもOpenCoreユーザーでも同じです。Clover ユーザに必要なものは以下です。

Clover Shell : shell64.efi などと呼ばれているファイルを、EFI/CLOVER/tools の下に置きます。
OcQuirks : Aptioの修正、OsxAptioFixDrvX, AptioMemoryFixなどと混在させないでください。このガイドでは OcQuirks のみサポートします。EFI/CLOVER/drivers/UEFI の中に置きます。
OpenRuntime.efi : OcQuirksのパッケージに含まれます。EFI/CLOVER/drivers/UEFI の中に入れます。
OcQuirks.plist : (これもOcQuirksに含まれてます) EFI/CLOVER/drivers/UEFI の中に入れます。

一方、OpenCoreユーザに必要なものは以下です。

OpenRuntime
OpenShell これをconfig.plistのRoot -> Misc -> Toolsで有効にしておきます。

そして、config.plist -> Booter (OpenCore用) かOcQuirks.plist (Clover用) で以下の設定をします。

AvoidRuntimeDefrag: YES
日付、時刻、NVRAM、電源制御などのUEFIランタイムサービスの修正
DevirtualiseMmio : YES
Stolen Memory のサイズを削減し、slide=N値のオプションを拡張し、Z390のメモリ割り当ての問題を修正するのに非常に役立ちます。
EnableSafeModeSlide : YES
slide 値をセーフモードで使用できるようにします。
ProtectUefiServices : NO
UEFI サービスがファームウェアによってオーバーライドされないように保護します。主に VM、300 シリーズ、および Ice Lake や Comet Lake のような新しいシステムに関連します。
ProvideCustomSlide : YES
これにより、カーネルが、読み込みに適したメモリー空間のみを選択し、起動に失敗する可能性のある場所を避けるようになります。読み込み場所のランダム性は維持していますが、ランダムに選択する際に、不適切なメモリ領域を除外するようになります。（訳注：これが従来のslide設定の役割を果たしてくれるようです。ただし、slideを固定するのではなく、使用可能なslide値を自動で探して、その中からランダムに選んでくれているようです。）
RebuildAppleMemoryMap : YES
macOSと互換性のあるメモリマップを生成します。いくつかのラップトップのOEMファームウェアで失敗することがありますので、早期段階でブートに失敗する場合は、これを無効にします。

BIOS設定

BIOSを以下のように設定します。

BIOSを更新する (初期のBIOSにはメモリマップの問題があることが知られているので、非常に重要です, 特にZ390で重要です。)
CMOSを工場出荷時設定にリセットする
とても必要とされる以下のBIOS設定をします。
Above4GDecoding : 有効にします。デバイスが4GB以上のメモリ領域を使用できるようになり、macOSカーネルが収まるメモリー空間が増えます。
Boot Options -> Windows8.1/10 mode : これにより古いレガシーなゴミのようなコードがロードされなくなります。誤解されがちですが、other OSというもう一つの選択肢は、古いバージョンのWindowsを起動するための選択肢であり、LinuxやmacOSのための選択肢ではありません。（訳注：ASUSのZ490マザーボードにCatalinaを入れたマシンでは、other OSにしないと起動しませんでした。）
BIOS内の不要なデバイスをできるだけ多く無効にします。これにより、起動時のマップの細分化が減少するので、起動失敗の可能性が減ります。
CSM : 無効にします。有効化してしまうと、レガシーサポートのため、不要なゴミの束が追加され、またUEFIシェルが起動できなくなります。
Intel SGX : 無効にします。SGXとはSoftware Guard Extensionsの略です。有効にしても、多くのメモリ空間を占有するだけで、macOSでは何もしません。
Parallel Port と Serial Port：無効にします。macOSではParallel portは認識しませんし、Serialを必要とする人はいないです。
iGPU : やむを得ない場合は、これを無効にすることで、メモリを大幅に解放できます。
Thunderbolt : 無効にします。ほとんどのマザーボードはTBを搭載していませんし、搭載していても使用しないなら、無効にすることでメモリ空間を確保できます。
LED lighting : 無効にします。もう光らせなくても良いでしょう。
Legacy USB : 無効にします。これもレガシーなガラクタです。

テストブート

上記のように、EFI、config.plist、BIOSの設定を調整したら、これで起動を試してください。これでめでたく解決したら、この先の作業は不要です。まだ問題が発生する場合は、次のステップで、もっとディープな作業、つまりslide値の計算をしましょう。

slide値を探す

ブートマネージャでEFIシェルを開き、memmapを実行します。すべてのページとそのサイズのリストが以下のように表示されます。ここからが楽しみの始まりです。

Type Start End # Pages Attributes
RT_Data	 0000000000000000 0000000000000FFF 0000000000000001 800000000000000F
Available 0000000000001000 0000000000057FFF 0000000000000057 000000000000000F
Reserved 0000000000058000 0000000000058FFF 0000000000000001 000000000000000F
Available 0000000000059000 000000000008FFFF 0000000000000037 000000000000000F
RT_Code 0000000000090000 0000000000090FFF 0000000000000001 800000000000000F
Available 0000000000091000 000000000009DFFF 000000000000000D 000000000000000F
Reserved 000000000009E000 000000000009FFFF 0000000000000002 000000000000000F
Available 0000000000100000 000000005B635FFF 000000000005B536 000000000000000F
BS_Data 000000005B636000 000000005B675FFF 0000000000000040 000000000000000F
Available 000000005B676000 000000006AF77FFF 000000000000F902 000000000000000F
LoaderCode000000006AF78000 000000006B155FFF 00000000000001DE 000000000000000F
BS_Data 000000006B156000 000000006B523FFF 00000000000003CE 000000000000000F
ACPI_NVS 000000006B524000 000000006B524FFF 0000000000000001 000000000000000F
BS_Data 000000006B526000 000000006B625FFF 0000000000000100 000000000000000F
Available 000000006B626000 000000006B634FFF 000000000000000F 000000000000000F

（訳注：このあと、slide値を決める手順が書かれています。どういうわけか、一番高い番地のAvailableを第一候補として〜15ページしかないのに〜、slideが255を超えるので諦めて、順当に0x100000番地からの領域、すなわちslide=0を選択しています。ということで少し遠回りしている感じもしますし、また、こちらで解説した内容と同じなので省略します。またRedditの/r/hackintoshのdiscordにもツールらしきものがあるらしく、その説明もありますが、これも省略します。）

DevirtualiseMmioを使う

（

訳注：この先はあまり理解できませんでした。推測を交えて内容をまとめると、次のようなことだと思います。推測部分は間違っているかもしれません。

config.plistでDevirtualiseMmioをtrueにする

DevirtualiseMmioのデフォルトはfalseですが、これをtrueにします。これにより、カーネルを読み込む場所のメモリー使用が64から256MB程度節約できて、KASLRの失敗を防止できます。

MMIOはMemory Mapped IOのことです。入出力デバイスのコントロールをメモリーのアドレス線を利用して行うのがMMIOです。上でのべたEFI Shellのmemmapコマンドによると、E0000000番地からFFFFFFFF番地までの512MBにMMIOが割り当てられています。インテルチップセットのマザーボードなら同様のようです。この番地には、メモリーが割り当てられていたとしても、IOへのアクセスになってしまい使えません。

Type Start End # Pages Attributes
MMIO 00000000E0000000-00000000EFFFFFFF 0000000000010000 800000000000100D
MMIO 00000000FE000000-00000000FE010FFF 0000000000000011 8000000000000001
MMIO 00000000FEC00000-00000000FEC00FFF 0000000000000001 800000000000100D
MMIO 00000000FED00000-00000000FED03FFF 0000000000000004 800000000000100D
MMIO 00000000FEE00000-00000000FEE00FFF 0000000000000001 8000000000000001
MMIO 00000000FF000000-00000000FFFFFFFF 0000000000001000 800000000000100D

（以下はフォーラムで教えていただいた図をもとに考えた説明です、間違っていたらすみません）EFIによってOSが起動する際に、通常はMMIOに論理アドレスを与えて（仮想化して）、論理アドレスからMMIOを使用できる状態にするようです。ただMMIOの仮想化を行わなくても(de-virtualiseしても)、物理アドレスにアクセスできるプロセスからはMMIOを使えるのでそれほど問題はないようです。MMIOを仮想化しない場合は、MMIOの部分もメモリーにマップできるので、64MBから256MBの空き領域が稼げるようです。DevirtualiseMmioフラグをtrueにすると、カーネルが読み込まれる領域を少しでも多く確保できるので、起動失敗の確率を下げられます。

Kaby Lake以前のCPUでは、デフォルト通りfalseが、Coffee Lake, Comet Lakeなどではtrueにすると良いとされていますが、手元のCoffee Lake-Sではfalseでも動きました。通常はfalseで、起動失敗する場合にはtrueを試すのが良いと思います。

ちなみにどうでも良いことですが、virtualize (仮想化) をvirtualiseと書くのは英国風らしいです。

config.plistにMmioWhitelistを指定する

DevirtualiseMmioをtrueにした場合に、メモリは節約できるものの、Threadripper TRX40 19H などの一部のシステムで起動しなくなることがあるらしいです。そのような場合、DevirtualiseMmioを適用しない領域を指定します。これがMmioWhitelistです。これの作り方について説明がありますが省略します。ほとんどのシステムではMmioWhitelistは不要とのことです。

）

ここまでが抄訳です。

結局どうしたら良いのか

OpenCoreでどう対応すべきかについてまとめます。上記のガイドでは、slide値を求める方法は書いてありますが、ブートオプションなどで設定する方法にまでは書かれていませんでした。当然のことで省略されたのかもしれないですし、slideを使うことをあまり推奨していないのかもしれません。

OpenCoreのReference Manual (0.5.8) の最初の方（15ページ）には、最初にすべきことの一つに、「slideを使うな」と書いてあります。config.plistの設定からも、NVRAMのboot argumentからも削除しておくようにとのことです。そして、「No slide values are usable! Use custom slide!」というエラーが出てから検討してくださいとあります。slideは、KASLRを回避する上、SIPを緩める必要があるので、セキュリティに影響を与えるという考えなのかもしれません。まずはslideを使わなくても済む方法を試みて、それでもダメな場合だけにslideを使いましょうとの方針だと思います。

ということで、このガイドのステップをまとめると、以下になります。まずはマザーボードの設定です。

BIOSを更新する
Above 4G Decodingを有効にする
CSMを無効にする
Boot Options -> Windows8.1/10 mode にする（訳注：前述のようにother OSを選択しないと起動しないことがあります）
Parallel Port と Serial Portを無効にします

可能ならば以下も設定します。

Intel SGX : 使用していないなら無効にします。
Thunderbolt : 使用していないなら無効にします。
LED lighting : 無効にします。
Legacy USB : 無効にします。

そしてconfig.plistで以下のように設定します。

AvoidRuntimeDefrag: true
DevirtualiseMmio : true
EnableSafeModeSlide : true
ProtectUefiServices : false
ProvideCustomSlide : true
RebuildAppleMemoryMap : true

設定は、環境に合わせて必要なものを選択して、正常に起動するまで少しずつ足して行くのが良いと思います。

まとめ

KASLRに関係した理由でmacOSが起動しないことへの対処法を紹介しました。基本的には、メモリー空間を確保する処置をして、KASLRの選択範囲を狭めることで対応しています。BIOS設定とOpenCoreの機能で大体の場合に対応できて、slideによるカーネル読み込み番地固定は最終手段のようです。

15個制限のためのUSBPorts.kextをHackintoolで作る

Sun, 31 May 2020 17:36:51 +0900

macOSのUSB 15個制限を解決するために、使用する15個未満のUSBポートを決定し、macOSに伝えます。以前の記事でいくつかの方法を紹介しましたが、今回はHackintoolを使ってkextを作ります。作業が楽で、作ったkextを1個インストールするだけなので簡単でした。

USBポート個数対処の方法

今までの記事では、USBポート個数制限に対処する方法として、

AppleUSBXHCIPCI.kextにパッチを当てる
OpenCoreのconfig.plistでXhciPortLimitをtrueにする
DSDTを書き換えて使用する15個のUSBポートを指定する
USBInjectAll.kextとブートオプションで15個を指定する
USBInjectAll.kextとこれに指示するSSDTを作って15個を指定する

などの方法を紹介しました。

USBポートを設定する

ASUS MAXIMUS XI HEROのUSBを設定する

先日の記事で、OpenCore用の手順を書いたところ、P2B-Fさんからコメントで「Hackintoolを使ってUSBPorts.kextを作る方が簡単です」と教えていただきました。試してみたら確かに簡単でした。その手順をまとめておきます。以下の方法は、個数制限に対応する方法の中で、現時点で一番おすすめの方法だと思います。

Hackintoolを入手する

Hackintoolは以下から入手できます。HackintoolはiGPUの設定でも使いました。色々便利な機能があります。USBポートの情報などのハードウェア構成情報はIORegistryExplorerでも見ることができますので、併用して確認するのも良いです。

Releases · headkaze/Hackintool

一時的に制限を撤廃する

まずOpenCoreのconfig.plistでXhciPortLimitをtrueにするなどして一時的に15個制限を解除します。Cloverでしたらconfig.plistで15個制限撤廃パッチを当てても良いです。また、以前紹介したようにUSBInjectAll.kextとブートオプションを使って少しずつ解除しても良いです。以下では、全てを解除した状態で説明します。全解除状態でHackintoolを起動し、ウィンドウ上部のボタンからUSBを選択すると、下の図のようになります。

ウィンドウの下には、7個のボタンが表示されています。マウスを持っていくと機能が文字表示されます。それによると左から、Info, マイナスマークのDelete, ホウキのマークのClear All, 回転矢印マークのRefresh, 注射器マークのInject, Import, Exportのボタンです。Clear All, Inject, Refreshの順に押していくと、現在認識されているポートが全て表示されます。Z390チップセットのASUS ROG MAXIMUS XI HEROでは以下のようになりました。上部のウィンドウに、Cannon Lake用の300シリーズチップセットのマザーボードであることが表示されていて、マザーボードが正しく認識されています。

ここでHS03とHS12がアクティブになっています。HS03には、一時的にLogicoolのタッチパッド付きキーボード用の無線ドングルを接続したので、それが見えています。また、HS12にはUSB 2.0のハブを接続しているので、それが見えてます。実はHS13には、Apple純正のBluetoothモジュールが接続されているのですが見えていません。マザーボード上のUSB 2.0コネクタなのですが、これがマザーボード内蔵のhub経由で接続されているらしく、そのためか、XhciPortLimitをtrueにしても見えないようです。なので設定作業用にLogicoolのキーボードを接続しているわけです。（さらにはSS10にもハブがつながっているのですがそれも見えていないようです。後の図で示すように、15個制限を設定したら、これらも見えるようになりました。）

USBポートを特定して選別する

この状態で、USBポートにデバイスを取り付けて、変化を観察します。例えば上の状態では、バックパネルのUSB 3ポートにLogicoolのキーボードドングルが反応したので、これがHS03であることがわかります。この作業には、キーボード、マウス、USB Bluetoothアダプタなどを使うと良いです。これらはUSB 2.0ですし、抜き差しも簡単です。USB 2.0メモリーを使用すると、アンマウントする手間が必要です。USB 3のポートを確認するには、USB 3対応のUSBメモリーなどを使います。この場合は、取り外す際にアンマウントしないと、データを壊す危険があります。（大抵は大丈夫ですが）

HackintoolのConnectorの欄をクリックするとポップアップメニューが出ます。この欄には、USBの速度ではなく、接続された物理的なコネクタの形状を書きます。HS03はUSB 2ですが、USB 3コネクターに接続されています。なのでHackintoolのConnectorの欄はUSB3に設定します。

Connectorとして選択できるのは、USB2, USB3, TypeC+Sw, TypeC, Internalの5種類です。ここでの選択で、後で述べる出力ファイルのUsbConnectorプロパティ値が変化します。それによると、それぞれの選択で、0, 3, 9, 10, 255が割り当てられることがわかりました。これらの値について、Hackintoolのソースを調べたところ、ヘッダファイルに以下の記述がありました。

kTypeA		= 0x00,	// Type ‘A’ connector
kMiniAB		= 0x01,	// Mini-AB connector
kExpressCard	= 0x02,	// ExpressCard
kUSB3StandardA	= 0x03,	// USB 3 Standard-A connector
kUSB3StandardB	= 0x04,	// USB 3 Standard-B connector
kUSB3MicroB	= 0x05,	// USB 3 Micro-B connector
kUSB3MicroAB	= 0x06,	// USB 3 Micro-AB connector
kUSB3PowerB	= 0x07,	// USB 3 Power-B connector
kTypeCUSB2Only	= 0x08, // Type C connector - USB2-only
// These only implement the USB2 signal pair, and do not implement the SS signal pairs
kTypeCSSSw	= 0x09, // Type C connector - USB2 and SS with Switch
// These implement the USB2 signal pair, and a Functional Switch with a physical
// Multiplexer that is used to dynamically connect one of the two receptacle SuperSpeed
// signal pairs to a single USB Host Controller port as function of the Type-C plug
// orientation.
kTypeCSS	= 0x0A, // Type C connector - USB2 and SS without Switch
// These implement the USB2 signal pair and a Functional Switch by connecting each
// receptacle SuperSpeed signal pair to a separate USB Host Controller port.
// 0x0B – 0xFE: Reserved
kInternal	= 0xFF	// Proprietary connector

0, 3, 9, 10, 255以外にも、いくつかの設定値があるようです。ただ、Hackintoolのメニューにあるように、この5種類が一般的で、これ以外を設定することはなさそうです。この説明から、割り当ては以下のようです。

USB2 (0) はUSB 2.0 Type Aコネクター
USB3 (3) はUSB 3.x Type Aコネクター
TypeC+Sw (9) はスイッチ経由USB Type-C (Gen1またはGen2)
TypeC (10) はスイッチを経由しないUSB Type-C (Gen1x2またはGen2x2)
Internal (255) はマザーボード上の専用コネクタ

USB規格のType-A, Type-Cコネクタの場合は、0, 3, 9, 10を指定するのに対して、マザーボード上にあるヘッダピンのようなUSB規格外のコネクタに接続されている場合はInternal (255) を選択します。どのコネクタに接続されていてもUSBはUSBなので関係ない気もしますが、macOSの中での電力制御の扱いが異なるようです。IORegistryExplorerなどでコネクタの情報を見ると、コネクタ種類の違いで電流関係のパラメータが異なっています。その関係と思われますが、Bluetoothアダプタが接続するポートは、255に設定しないとスリープを妨げることがあるようです。

Type-Cコネクタの設定

Hackintoolのコネクタ選択肢であるTypeC+SwとTypeCの違いを説明します。Type-Cケーブルは、以下のように1セットのUSB2配線（A6, A7とB6, B7）と、2セットのUSB3配線（A2, A3, B11, B10とA10, A11, B3, B2）で構成されています。

このうち、Type-CのUSB2 (信号名はD+とD-) は、コネクタを裏表どちらに挿しても同じUSB2が接続されます。コネクタが冗長に使用されています。それに対して、2個のUSB3 (TX1+/-, RX1+/-, TX2+/-, RX2+/-) は、裏表どちらかに挿すことで、2セットのUSB3が別々に接続されます。なのでUSB3に関しては、2セット分用意しないといけないわけです。これを実現するために、もともと1個しかないUSB3をスイッチングハブで分岐して2個にして接続するか、もしくは2個のUSB 3ポートを用意するか、の2種類の実装方法があります。これがHackintoolのメニューにあるTypeC+Sw（スイッチ付）とTypeCです。どちらも2個のUSB3が使えますが、前者は一つを2個に分岐しています。なので2個のUSB3を両方とも使用した場合は、速度が半々になります。後者は、両方のUSB3を共に使用してもそれぞれのフルスピードが出ます。

最近になって従来のUSB 3.0や3.1の表記に代わって、USB 3.2という名称が使われるようになり、ややこしくなってます。色々調べてみると、以下のような分類になったようです。

USB 3.2 Gen1 : 昔のUSB 3.0 または今のUSB 3.1 Gen1と同じもの (5Gbps線を1組使用)
USB 3.2 Gen2 : 昔のUSB 3.1または今のUSB 3.1 Gen2と同じもの (10Gbps線を1組使用)
USB 3.2 Gen1x2 : Type-Cでスイッチを使わずに独立した5Gbps線を2組使う (合計10Gbps)
USB 3.2 Gen2x2 : Type-Cでスイッチを使わずに独立した10Gbps線を2組使う (合計20Gbps)

ちなみにGen2x2は「じぇんつーばいつう」と読むようです。x2が末尾につくコネクタはHackintoolのTypeCを選択し, x2がつかないコネクタはTypeC+Swを選択します。今回チェックしたマザーボードでは、裏表どちらに挿してもSS06に接続されました。スイッチで分岐しているだけのようなのでこれはUSB 3.1 Gen2x1です。HackintoolのConnectorメニューではTypeC+Swを選択します。

使わないポートを除外

こうしてUSBポートを特定していくと同時に、使わないポートを外していきます。最終的に15個のUSBポートまで削減していきます。使えるものなら使いたいけど、個数制限で諦めざるを得ないポートもあると思います。また、Comment欄のところにメモ書きをしておくと、後で説明する出力ファイルにもコメント記載されます。テキストエディタで修正する場合などに便利です。

今回も、以前の記事で選んだUSBポートを使うことにしました。結果として以下のようになりました。

USBPorts.kextを作る

この後、ウィンドウ下のExportボタンを押します。するとこの設定から、

SSDT-EC-USBX.aml
SSDT-EC-USBX.dsl
SSDT-UIAC.aml
SSDT-UIAC.dsl
USBPorts.kext

の5個のファイルをデスクトップに作ってくれます。以前のガイドで作っていたSSDT-UIACは、ここではSSDT-EC-USBXとSSDT-UIACの2つに分割されています。統合すれば内容は同じものでした。なので、SSDT関係のファイルはUSBInjectAll.kextと一緒に使うものであると思います。

USBPorts.kext/Contents/Info.plist

というテキストファイルが見えます。この中に、上で設定した内容が、plist書式のテキストで書かれています。こうして作成されたInfo.plistの内容を以下のところに置いておきました。

USBPorts.kext for ASUS Z390 - Pastebin.com

このUSBPorts.kextだけを使用すれば、15個のUSBを指定して動かすことができました。kextを使う場合は、USBInjectAll.kextやSSDT-EC.aml, SSDT-UIAC.amlは不要です。実は、Z97の時代にはこの手のインジェクトkextを使って使用USBのリストを設定していました。その後、チップセットが代わって、雛形となるファイルが見つからなくなったので、USBInjectAll.kextとSSDTを組み合わせて使っていました。Hackintoolでこんなに簡単に生成してくれるなら、今後はこのkextを使っていきたいと思います。

USBMap.commandを使う

こちらもコメントで教えていただきました。Hackintool.appと同様に、インジェクトkextを作るPythonスクリプト、USBMap.commandがcorpnewtさんによって配布されています。

GitHub - corpnewt/USBMap: Python script for mapping USB ports in macOS and cr…

こちらはCUIベースで設定していきます。操作が多少独特ですが、USB設定専用のアプリですのでシンプルです。生成されるインジェクトkextはUSBMap.kextという名前ですが、Hackintoolで作るUSBPorts.kextと全く同じ内容です。

% ./USBMap.command

#######################################################
# USBMap #
#######################################################

Plist: USB.plist
UIA Boot Args: None
USBInjectAll: Not Loaded - NVRAM boot-args WILL NOT WORK
AptioMemoryFix: Unknown

NVRAM Arg Options:
H. Exclude HSxx Ports (-uia_exclude_hs)
S. Exclude SSxx Ports (-uia_exclude_ss)
C. Clear Exclusions

R. Remove USB.plist from Scripts Folder
T. Reset Settings to Defaults
P. Edit Plist & Create SSDT/Kext
D. Discover Ports
U. Validate USB Power Settings
Q. Quit

Please select an option:

コメントでMifjpnさんから、USBMap.commandの使用例を教えていただきました。

USBMap.commandによるUSBポートの選択

まとめ

USBポート15個制限に対応するため、Hackintoolを使って、USBPorts.kextを作りました。このkextを使用するだけで、15個制限の設定が可能でした。今まで紹介した方法のどれよりも簡単だと思いますので、今後はこの方法で設定していこうと思います。コメントで教えていただきありがとうございました。

SSDのtrimを有効にする (OpenCore編)

Thu, 28 May 2020 22:42:16 +0900

2.5インチSSDのtrim機能をtrimforceコマンドで有効にしました。nvramを正しく動くようにしておいたためか、trimforceが効きました。もしtrimforceが効かない場合、Cloverでは、IOAHCIBlockStorage.kextにパッチ当てしてましたが、OpenCoreではThirdPartyDrivesをtrueにするだけで良いようです。

trim有効化方法 (OC対応版)

今回、trimの有効化を試したマシンは、ASUSのZ390マザーボードとSanDiskの2.5インチSATA SSDの構成です。また、trimの仕組みと設定方法は以下の記事で紹介しました。

SSDのTRIMを有効にする

SSDを使う場合、trimは有効になっていた方が良いと言われてます。そこで以下のステップでtrim設定に対処します。

SSDによっては、macOSがtrim対応している場合があります。特にNVMe方式のM.2 SSDはOOBでtrimが働くようです。その場合は、何もしなくて良いです。
非対応SSDの場合、trim機能をmacOSのtrimforceコマンドで起動することができます。このコマンドには、nvramが関係している様子です。ただし、trimforceが効かないこともあります。
trimforceが効かない場合は、config.plistに設定してパッチを当てます。Cloverでは、IOAHCIBlockStorage.kextにパッチ当てしてます。OpenCoreではThirdPartyDrivesをtrueにします。

でも実のところ、このマシンでは、メインのSSDをM.2 NVMeにしたため、データを入れる場所にした2.5インチSSDのtrim設定は長らくほったらかしにしていました。trimforceは効かないし、パッチ当てるのも面倒だったのも理由です。

ThirdPartyDrivesの説明を読む

という状況だったのですが、OpenCoreにしたところ、パッチ当てが簡単になっていることに気づきました。上のステップに書いたように、config.plistの中で設定できるThirdPartyDrivesというプロパティをtrueにすれば、IOAHCIBlockStorage.kextにパッチを当ててくれます。これなら簡単にtrim有効化できます。さらにその説明を読むと、以下のように、できればtrimforceが望ましいようなことが書いてありました。

**ThirdPartyDrives :**デフォルトはfalseです。IOAHCIBlockStorage.kextにパッチを当て、サードパーティのドライブでtrimやハイバーネーションを可能にします。このオプションは、ユーザの判断で使わないことにしても良いです。最近のmacOSバージョンには、専用のユーティリティであるtrimforceが提供されています。10.15以降では、このユーティリティは、01 00 00 00という値のEnableTRIMという変数をnvramに作ります。

ThirdPartyDrivesでパッチ当てをしてくれるものの、trimforceはmacOSがサポートするtrim機能を活性化するmacOSのコマンドなので、これでtrim有効化するのが望ましいそうです。trimforceで有効化できない場合の時だけ、ThirdPartyDrivesをtrueするのが良いと思います。

trimforceコマンドでtrim有効化する

そこで、久々にtrimforceを試したところ、すんなり動いてしまいました。Terminalからtrimforceとタイプすると、説明が出ます。

% trimforce
Usage:
trimforce enable
trimforce disable
trimforce help

次に、OpenCoreの説明にある、EnableTRIMがnvramの中にあるかどうか調べてみました。

% nvram -p | grep EnableTRIM

何も表示されません。定義されていないようです。そこでtrimforceコマンドで、trimを有効にするよう試みました。色々警告が出ますが進めます。

% sudo trimforce enable
Password:
IMPORTANT NOTICE:  This tool force-enables TRIM for all relevant attached devices, even though such devices may not have been validated for data integrity while using TRIM.  Use of this tool to enable TRIM may result in unintended data loss or data corruption.  It should not be used in a commercial operating environment or with important data. Before using this tool, you should back up all of your data and regularly back up data while TRIM is enabled.  This tool is provided on an “as is” basis. APPLE MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, REGARDING THIS TOOL OR ITS USE ALONE OR IN COMBINATION WITH YOUR DEVICES, SYSTEMS, OR SERVICES. BY USING THIS TOOL TO ENABLE TRIM, YOU AGREE THAT, TO THE EXTENT PERMITTED BY APPLICABLE LAW, USE OF THE TOOL IS AT YOUR SOLE RISK AND THAT THE ENTIRE RISK AS TO SATISFACTORY QUALITY, PERFORMANCE, ACCURACY AND EFFORT IS WITH YOU.
Are you sure you wish to proceed (y/N)? y
Your system will immediately reboot when this is complete.
Is this OK (y/N)?

この後、警告の通り、自動的に再起動してしまいます。再起動後に、先ほどのnvram変数を調べてみました。

% nvram -p | grep EnableTRIM
EnableTRIM %01

OpenCoreのマニュアルにある通り、01という値のEnableTRIM変数が出来上がっていました。システム情報を見ると、設定前は「いいえ」だったTRIMサポートの項目が「はい」に変化していました。trimforceで正しく設定できたようです。

trimforceは長らく機能しなかったので、あきらめていましたが、設定できるようになっていました。trimforceがnvramを使うようになったためか、さらにはSSDT-PMC.amlでnvramが正しく使えるようになったおかげのようです。

まとめ

ひさびさにtrimforceコマンドを試したら、2.5インチSSDのtrimが有効になりました。ちなみにM.2 NVMe SSDの方は、何もしない状態でtrim有効でした。もしtrimforceが効かない場合は、OpenCoreでしたらThirdPartyDrivesをtrueにすれば良いと思われます。

第10世代デスクトップCPUでmacOSは動く？

Sat, 23 May 2020 13:49:32 +0900

インテルの第10世代デスクトップCPUであるComet Lake-Sとこれに対応した400シリーズマザーボードが発売されました。これでhackintoshは可能なのでしょうか。結論としては、まだ難しいようです。

追記：Redditの別の情報によると、CPU, LAN, Thunderboltなど含めて、かなり動いているようです。(2020/5/29)

新CPUと新チップセット

第10世代デスクトップの最上位CPUであるCore i9-10900Kは10コア20スレッドです。i7-10700Kとi5-10600Kはそれぞれ8/16、6/12 コア/スレッドで、従来の第9世代より少し価格が安く低消費電力らしいです。400シリーズチップセットでは、メモリの対応クロックが少し上がり、LAN/WiFi周りが新しくなりました。全体的に第9世代と比べてそれほど進歩は無いとも言われていますが、その分、macOSの互換性が高いのではと期待しました。新CPUと新チップセットのmacOS互換性に関して、Redditに簡単な解説がありました。

r/hackintosh - Desktop Comet Lake launch! What you need to know for Hackintos…

これによると以下のようです。

CPUの互換性

現在のmacOSはモバイル用のComet Lakeはサポートしているが、デスクトップ用のComet Lake-Sはサポートしません。新型iMacがComet Lake-Sを搭載する未来が来るまで、macOSのサポートはないです。そのためか、試した人たちによると、macOSがカーネルパニックを起こすようです。今のところ、新CPUを動かすためには、Penryn CPUにフェイクする必要があるそうです。Penrynっていつの時代だろうと思って調べたら、Core 2 無印 / Duo / Quad時代のCPUでした。かなり昔のCPUに偽装する必要があるようです。詳しくはこちらをみてくださいと、ロシア語の掲示板が紹介されてます。ロシアのハッカーの皆さんに頑張ってもらいたいです。

ACPI fix

IcelakeとZ390に比べて大きな違いはないので、DSDTへの対応も同様で良いと思われるそうです。以下のSSDTを加えておけば良いようです。SSDT-PLUGに関しては、上記のようにCPUの対応ができていないので、しばらくは効果が無いそうです。

SSDT-AWAC : AWACクロックを無効にして昔ながらのRTCを有効にする
SSDT-PMC : 300と同様に400でもNVRAMが使えるようにする
SSDT-EC-USBX : ECを無効にして偽装することで正しいUSBパワーを供給
SSDT-PLUG : XCPMをロードして正しい電力管理を有効にする。ただしCPUがネイティブに動くようになるまでXCPMは動かないと思われる。

Firmware fix

Icelakeと同様に、OpenCoreのBooterセクションに引き続き以下が必要です。ただ、現状でもFirmware fixが全ての場合で安定しているわけではないので、カーネルパニックが治っても、問題が発生する可能性はあるそうです。

DevirtualiseMmio: カーネルを適切にロードするため。
ProtectUefiServices: イメージローディングのfix

iGPU

第9世代デスクトップCPUと同じUHD 630を引き続き搭載しているものの、フレームバッファが不明らしいです。これは第10世代CPU搭載iMacが出荷されるまで決まらないので、それまでは手作業で設定する必要がありそうです。

USB

残念ながら新しいUSBはネイティブに互換ではないようです。Xhci-Unsupported.kextを使い、PCI IDとして8086:06edを追加する必要があるとのことです。

Ethernet

400シリーズチップセットになってmacOSが一番影響を受けたのはLANとWiFiのようです。このプラットフォームは新しい2.5Gbe NICであるI225Vを搭載しています。これはLinuxでのE1000eドライバがサポートしていないので、それを元にしているIntelMausi.kextでも動かないです。対応待ちです。

一方で、RTL8125やI211などのNICを搭載しているメーカもあります。これらは今のIntelMausi.kextで対応しているそうです。調べてみたところ、MSIはRTL8125を、ASRockはRTL8125とI219Vを搭載しているようです。I219VはIntelMausi.kextのサポートリストに載ってます。一方で、GigabyteとASUSに搭載されるNICは新型のI225Vのようで、使えるまでしばらく時間がかかりそうです。

続報：tonymacx86の情報によるとIntelMausiEthernet.kext (IntelMausi.kext?) でIntel I225-V Ethernetが動いたようです。(2020/5/29)

無線カード

Z390までのマザーボードの無線カードソケットでは、チップセットが支援するCNVi方式のカードに加えて、汎用のM.2無線カードも使えました。なので、BroadcomのBCM94360NGのようなmacOSとOOBでの互換性のあるM.2無線カードが使用可能でした。でもZ490になって、多くのマザーボードでCNVi非互換カードが使用不可になってしまったようです。PCIeスロット数が多いマザーボードなら、BroadcomのApple純正カードをPCIeに変換するアダプタを使用すれば問題ありません。でもmini ITXのようにPCIeが1本しかない場合は、これをdGPUで使いたいところですので、M.2ソケットが使えないのは残念です。Redditのディスカッションによると、はCNVi非互換カードに対応しているそうです。WiFiの規格がaxではなくacとなっているマザーボードが狙い目らしいです。それに対して、光らない渋いマザボとして人気のは、Reddit参加者がメーカのサポートに確認したところ、CNVi非互換カードは使用不可能とのことでした。

続報：Gigabyte Z490 Vision D + 10900Kの動作報告

こちらのGitHubページで2020/5/28頃に動作例が紹介されました。

GitHub - SchmockLord/Hackintosh-Intel-i9-10900k-Gigabyte-Z490-Vision-D: https…

OpenCoreでブートしているようで、以下が動作しているそうです。

Wifi and Bluetooth (FenviのBCM94360CDを使用)
Audio: Realtek ALC1220-VB (AppleALC.kext, layout-id=7, device-id=0xA170, FakeID.kext, FakePCIID_Intel_HDMI_Audio.kext)
USB
Thunderbolt 3 ではhot-plugも動作
1Gbit Ethernet (Intel I219-V)
2.5Gbit Ethernet (Intel I225-V)
Sleep/Wake
Shutdown
Restart

EFIファイル類も公開されています。それによるとCPUを以下のようにfakeしているようです。

<key>Emulate</key>
	<dict>
		<key>Cpuid1Data</key>
		<data>6wYIAAAAAAAAAAAAAAAAAA==</data>
		<key>Cpuid1Mask</key>
		<data>/////wAAAAAAAAAAAAAAAA==</data>
	</dict>

6wYIAAAAAAAAAAAAAAAAAA==は、0x0806EBになり、第7世代と第8世代のCPUの値を使っているようです。

使用するUSBポートを15個指定する (OpenCore編)

Wed, 20 May 2020 23:27:08 +0900

ここではUSBInjectAll.kextを使っていますが、最近はサポートが途絶えているので、以下の方法がよりシンプルでおすすめです。

15個制限のためのUSBPorts.kextをHackintoolで作る

———————————-

（以下は今でも有効ですが、古い情報です。）

OpenCoreではconfig.plistでXhciPortLimitをtrueにすれば15個制限を解除できます。Cloverでのパッチ作業より楽です。でもUSBInjectAll.kextとSSDTで使用する15個を指定する従来の方法も可能で、その方式がおすすめです。

OpenCoreで15個制限を全撤廃

macOS El Capitanから使用可能なUSBポートの数が、コントローラ当たり15までと制限されました。その解説と、Cloverのconfig.plistに書く制限解除パッチを以下の記事で紹介しました。この記事では、AppleUSBXHCIPCI.kextにパッチを当ててました。

USBポートを設定する

OpenCoreでは、config.plistのKernel, QuirksのXhciPortLimit項目をtrueにしておくと（デフォルトはfalse）、必要なパッチを当ててくれます。 AppleUSBXHCIPCI.kextの他に、AppleUSBXHCI.kextとIOUSBHostFamily.kextにパッチを当ててくれるようです。このパッチは、各種macOSバージョンに合わせた内容が必要なので、その点にも対応してくれているようです。なので、簡単に15個制限を解除できます。

しかし、OpenCoreのReferenceマニュアルにはこんな注意書きがあります。

このオプションは、可能な限り避けてください。USBポート制限は、locationIDの書式で割り当てられたビット数による制限です。この制限は、OSを大々的に変更しない限り解除できません。正しい解決策は、使わないポートを除外して、使用したいUSBポート15個を選定することです。

つまり、macOS内部で使用しているプロパティのlocationIDの中で、ポートを識別するための変数に、どうやら4ビットしか割り当てられていない様子です。15個を超えるポートを使用可能にすると、違うポートに同じIDが割り当てられる可能性があるわけで、とても危険なことだと推測できます。実際には15個制限を外したことで問題が発生した事例は、報告も無いし経験もしていませんが、避ける方が良いでしょう。XhciPortLimitの使用は、macOSをインストールする際や、使用するポートを取捨選択する作業の時だけに制限すべきでしょう。

OpenCoreで使用する15個を指定する

そこで、15個制限を撤廃するのではなく、必要な15個のポートだけを登録するようにします。まずはマシンのUSBポート割り当てを調べて、使用したい15個のUSBポートを選定します。この方法は、以下で説明しました。OpenCoreならば、この手順の中で、一時的にXhciPortLimitをtrueにすることで簡単に15個制限解除できるので、作業が楽になると思います。

ASUS MAXIMUS XI HEROのUSBを設定する

macOSは発見した15個までのUSBポートをアプリケーションに提供します。なので、使用する15個のポートを決定したら、その15個のポートだけがマシンに存在しているかのようにmacOSに伝えます。これにはいろいろな方法が可能ですが、USBInjectAll.kextと専用のSSDTを使用するのが一番おすすめだと思います。以下の記事で、仕組みと設定方法を説明しました。

15個制限を回避するUSBInjectAll.kextの役割と使用法

上の記事では、Cloverで使うための方法を書いていますが、OpenCoreでも同じように設定できます。ただし、kextとSSDTファイルを置く場所は、Cloverと違うディレクトリです。つまり、kextはKextsに、

SSDTは（SSDT-UIAC.amlという名前にしました）ACPIに置きます。

また、OpenCoreでは、config.plistにも、使用するkextとSSDTを記述する必要があるのは、すでに説明した通りです。ProperTreeのsnapshot機能を使えば、kextとSSDTを正しいディレクトリに置くだけで、config.plistの設定をしてくれるので楽です。

まとめ

OpenCoreでもUSBポート15個制限に対応するため、Cloverで使っていたUSBInjectAll.kextとSSDT-UIAC.amlをOpenCoreのESPに入れました。config.plistにも登録しました。これらは、Cloverの時と同じように、OpenCoreでも機能して、必要な15個のUSBポートが使えるようになりました。

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

Tue, 19 May 2020 22:29:04 +0900

抜き挿し可能なリムーバブルSATAドライブベイを使うために、Cloverでは、macOS稼動中にHDD/SSDドライブのホットプラグを可能にするパッチをconfig.plistに書いてました。OpenCoreに移行したのでこのパッチも移行しました。

5.25インチベイ用リムーバブルHDDラック

上の写真のような、5.25インチベイに取り付けるリムーバブルHDDラックは、本物のMacには無い、自作hackintoshならではの便利な装備です。でもHDDラックを取り付けただけではHDD/SSDのホットプラグが効きませんでした。macOS起動時にリムーバブルベイに装着されているHDD/SSDは認識され、ファインダー上でアンマウントして、安全に取り外すことはできます。しかし、macOS稼動中にHDD/SSDを挿しても認識されません。そこでCloverでは、ホットプラグが機能するようにconfig.plistにkextパッチを当て対応していました。

SATA接続HDD/SSDのホットプラグ

Cloverで使用していたパッチ

このパッチは、AppleAHCIPort.kextの一部を0x90 (マシンコードでNOPに相当します) に置き換えるものです。置き換える範囲は、kextの中の0x40200000というデータ列の4バイト、その前8バイト、その後14バイトの、合計26バイトです。コメントでまっくぷろさんに教えていただいたパッチです。

このパッチを作るために、kextの中で0x40200000を探して、書き換えるべきデータ列を調べます。例として、macOS 10.15.4で、書き換えるべきデータを探してみます。まずは、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをhexdumpします。

% hexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less

lessが起動しているところ、以下のサーチコマンドをタイプし、40 20 00 00を探します。

/40 20 00 00

ところが運悪く途中に改行が入っているようで見つかりません。40 20だけでもう一度探索します。

/40 20

今度は見つかりました。改行の先に00 00があるので、間違い無いようです。他にも40 20は見つかりますが、その先に00 00が続く場所はありません。おそらくは2バイト単位で位置揃えされているので、この場所以外に改行が来る可能性は無いと思います。40 20 00 00と40 20の2種類の探索を試みれば、40 20 00 00の場所を発見できると思います。

0002a40 69 01 00 00 89 ca 81 e2 40 60 02 00 81 fa 40 20
0002a50 00 00 75 0c 81 e1 bf 7f ff ff 89 8b 69 01 00 00
0002a60 f6 c1 40 74 7e 3d 09 01 01 00 72 77 44 89 fa c1
0002a70 ea 0a 81 e2 80 00 00 00 81 e1 7f ff ff ff 09 d1

ここで発見した0x40200000の4バイト、その前8バイト、その後14バイトの、合計26バイトをNOP (90) に置き換えるパッチを作ります。つまり、

Find --> 81E24060 020081FA 40200000 750C81E1 BF7FFFFF 898B6901 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

というパッチを作ります。ProperTreeなどのツールならこのまま16進数が使えますが、テキストエディタで作る場合はbase 64に変換します。詳しくはこちらをご覧ください。Findするデータはbase 64では以下になります。

% echo -en "\x81\xE2\x40\x60\x02\x00\x81\xFA\x40\x20\x00\x00\x75\x0C\x81\xE1\xBF\x7F\xFF\xFF\x89\x8B\x69\x01\x00\x00" | base64
geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=

Replaceするデータは、NOPコマンド列である9090…なのですが、このbase 64は以下です。

% echo -en "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" | base64
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=

なのでCloverのconfig.plistには、

<key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>

というパッチを追加していました。これでBIOSでホットスワップ指定したチップセットSATA接続ドライブがオレンジ色アイコンになり、随時マウント・アンマウントできるようになりました。またスリープしても問題ありませんでした。

OpenCore用のパッチに書き換える

OpenCoreには、CloverのようなKextToPatchの項目はありません。OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、使用するキーの一部がCloverのパッチとは異なります。OpenCoreのパッチで使うキーは以下です。

Comment : Cloverと同じ。人が読むためのメモ書き。
Find : Cloverと同じ。検索データ列。
Replace : Cloverと同じ。置き換えるデータ列。
Identifier : CloverのNameに相当するキー。kextを指定するためのIDで、バンドルIDを使う。
Enabled : パッチを有効にする場合はtrueにする。（有効にしたいのでtrueにする）
Count : パッチを当てる箇所の数。今回の場合は1回なので1。
その他のキー : デフォルトで良いので省略。

kextのバンドルIDは、システム情報で知ることができます。

システム情報の拡張機能のAppleAHCIPortの項目を選択すると、

com.apple.driver.AppleAHCIPort

であることがわかります。そこで、上記のCloverのパッチに相当する、OpenCoreのパッチは以下になります。

<key>Kernel</key>
<dict>
 <key>Patch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Count</key>
 <integer>1</integer>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=</data>
 <key>Identifier</key>
 <string>com.apple.driver.AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>
</dict>

ProperTreeで設定するなら、以下のようになります。（0番から4番までに、OpenCore付属のSample.plistにあった無効設定のパッチを残してあるので、たまたま5番目になっていますが、何番目でも大丈夫です。）

このパッチをOpenCoreのconfig.plistに追加したところ、OpenCoreでも、ホットプラグが機能しました。オレンジ色のドライブがmacOS起動後にリムーバブルベイに取り付けた2.5インチHDDです。

パッチを施したconfig.plistを以下に置いておきます。もしこれを使用する場合は、SystemSerialNumber, SystemUUID, MLB, ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

まとめ

リムーバブルドライブベイのホットプラグを可能にするCloverパッチを、OpenCoreのconfig.plist用に書き換えて動作を確認しました。これでまた一歩、OpenCoreに適応できた気がします。

つづき

Big Sur対応パッチはこちらをご覧ください。

リムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)

OpenCoreの選択画面をグラフィカルにする

Mon, 18 May 2020 21:04:59 +0900

OpenCoreのデフォルトブートメニューはシンプルすぎるので、Cloverのようにアイコンで選択するよう設定しました。0.5.7以降でこの機能が使えるようです。

OpenCore GUI

前の記事で、ASUSマザーボードマシンのブートローダーをCloverからOpenCoreに移行しました。そのコメントで、OpenCoreでもアイコンによる起動選択ができるようになっていることを教えていただきましたので、試しました。以下での設定が終了していることが前提です。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

OpenCoreの起動画面をGUI化する方法に関しては、以下のページに使い方の説明があります。これに沿って進めました。アイコンによる選択のほか、起動チャイムやボイスオーバーも設定できるようです。ただ起動チャイムは、今のMacにはもうありませんし、不要かと思い設定しませんでした。

Resourcesの中身を用意する

配布されているOpenCoreのパッケージでは、OC/Resourcesの中にAudio, Font, Image, Labelというディレクトリがあるものの、中身は空でした。この中身を、以下のページから取り寄せて、入れておきます。たくさんのファイルがあります。特にAudioは、多国籍語のボイスオーバー用音声ファイルが入っていて、数が多いです。今回は、アイコン表示だけの作業なので音声ファイルは不要だとは思いますが、一緒に入れておきました。

GitHub - acidanthera/OcBinaryData

OpenCanopy.efiを設定する

アイコン選択を動かすためには、OpenCanopy.efiというドライバーが必要なようです。配布されているOpenCoreパッケージには含まれていましたが、前回の作業ではDrivers_offというディレクトリを作って、これに入れて外していました。これをDriversディレクトリに戻します。こんな感じになりました。最小限の構成です。

新しくDriversに追加したので、config.plistも書き換えておきます。簡単な作業なのでProperTreeのSnapshot機能は使わずに、ProperTree上での手作業でOpenCanopy.efiを追加しました。これくらいの作業ならテキストエディタで十分で、ProperTreeを使うまでも無いかもしれません。

config.plistのMisc項目を設定する

引き続きProperTreeを使い、以下の項目を設定します。

Misc -> Boot -> PickerMode: Sample.plistではBuiltinだった値をExternalに変更しました。
Misc -> Boot -> PickerAttributes:1 ガイドには1にせよとありましたが最初から1でした。この値のデフォルト値は0です。今回設定した1の他に、2, 4, 8とその組み合わせの選択肢があるようです。8を試してみたのですが、見た目は変わりませんでした。

この結果、このページの冒頭の写真のように、アイコンで選択できるようになりました。

まとめ

OpenCoreの起動選択画面でアイコン表示されるように設定しました。Cloverコミュニティの皆さんが競って作っているようなド派手な画面やミニマムでおしゃれな画面ではありませんが、本物のMacと同じアイコンを使った正統な起動画面だと感じました。今回は起動音の設定を行いませんでしたが、設定すれば起動チャイムやボイスオーバーが可能になるようです。ボイスオーバーは、本来はバリアフリーのための機能です。OpenCoreの開発者の方々も、その意識を持って起動音機能を整備していることがガイドに書かれていました。

追記：モダンなアイコン

コメントでまっくぷろさんから、今風の起動選択画面アイコンの情報をいただきました。Cloverのようにこれから増えていきそうですね。

GitHub - blackosx/OpenCanopyIcons: A range of .icns files designed specifical…

OpenCanopy Icons

追記：ミニマムなテーマ

ミニマムなテーマもありました。実機とは違うアイコンになりますが、macOS起動前の白りんごアイコンにマッチしたシンプルなアイコンです。

OpenCore用のミニマムなテーマ

追記：起動音を出す

こちらをご覧ください。

OpenCoreで起動音を鳴らす

追記：アイコンファイルの変更

最近のOpenCoreでは、アイコンファイルの設定方法が変更されています。こちらをご覧ください。（2021/7追記）

OpenCore 0.6.9から0.7.0に更新

Pioneer光学ドライブのパッチをOpenCoreに適用する

Sun, 17 May 2020 11:16:49 +0900

Pioneerの光学ドライブを使用していると「空のdvdがセットされました」というメッセージが出て、操作不能になることがあります。Cloverのconfig.plistでパッチを当てて対処していたのですが、OpenCoreに移行したので同様のパッチを当てました。

Cloverで使用していたパッチ

「空のdvdがセットされました」というエラーメッセージが出ることの原因と対策をこちらの記事で紹介しました。macOSがPioneerのドライブにスリープ指令を送りつけると、スリープ後も復帰しないことが原因のようです。そこで、光学ドライブにはスリープ命令を送らないように、macOSでは設定してあるらしいです。

光学ドライブを使う

なので、本物のMacと同型番のPioneer DVDドライブを使っていれば、操作不能に陥る問題は多分発生しないです。でも違う型番、例えばBDドライブを使う場合は、PioneerSuperDrive.kextにパッチを当てて、本物のMacが搭載している型番 (DVD-RW DVR-105) を、hackintoshで使用している型番 (例えばBD-RW BDR-205) に書き換えることで、この問題を解決できます。実際には、config.plistに以下のパッチを追加していました。これでスリープ命令が送られなくなり、操作不能に陥ることを回避できました。

<key>KextsToPatch</key>
  <array>
  <dict>
          <key>Comment</key>
          <string>PioneerBD-RW No Sleep</string>
          <key>Find</key>
          <data>RFZELVJXICBEVlItMTA1</data>
          <key>Name</key>
          <string>PioneerSuperDrive</string>
          <key>Replace</key>
          <data>QkQtUlcgICBCRFItMjA1</data>
  </dict>
  </array>

OpenCoreに移行したところ、再び、「空のdvdがセットされました」というエラーメッセージが出るようになりました。Cloverで使っていたパッチと同様の内容を、OpenCoreのconfig.plistにも書いておく必要があるようです。

CloverのKextToPatchをOpenCoreに移行する方法

OpenCoreには、CloverのようなKextToPatchの項目はありません。OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、書式もCloverのパッチとは多少異なります。上記のCloverのパッチを、OpenCoreで書く場合は、以下になります。ちなみにReplaceの値は、BD-RW BDR-205の型番になっています。他の型番の光学ドライブを使用している方は、その型番に書き換えてください。詳しくは、以前の記事をご覧ください。

<key>Kernel</key>
<dict>
 <key>Patch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>PioneerBD-RW No Sleep</string>
 <key>Count</key>
 <integer>1</integer>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>RFZELVJXICBEVlItMTA1</data>
 <key>Identifier</key>
 <string>com.apple.driver.PioneerSuperDrive</string>
 <key>Replace</key>
 <data>QkQtUlcgICBCRFItMjA1</data>
 </dict>
 </array>
</dict>

Cloverと比べてOpenCoreでは、一部のキーが削除追加されています。OpenCoreのサンプルconfig.plistを見ると、もっとたくさんのキーがあります。ただOpenCoreのパッケージに付属するマニュアルを読んでみたところ、デフォルト値のままで問題ないキーが多かったです。それらは省略しました。

Cloverのkeyのうち、Comment, Find, ReplaceはOpenCoreでも同じ名前で、同じ意味です。つまり、Commentは人が読むためのメモ書き、Findは検索データ列、Replaceは置き換えるデータ列です。これらはCloverの内容からそのままコピーしました。

Cloverでは、kextをファイル名（この例ではPioneerSuperDrive）で指定していました。使用するキーの名前はNameでした。OpenCoreでは、Identifierというキーで指定します。URLを逆順にしたような形式の一意の名前なので、より正確です。PioneerSuperDrive.kextがどのようなIdentifierなのかは、システム情報の拡張機能で、該当するkextを選択すると調べられます。

identifierは、バンドルIDという項目に書いてあります。以下のようです。Identifierの項目にはこれを書いておきます。

com.apple.driver.PioneerSuperDrive

Enabledキーでは、このパッチを有効にするかどうかを指定します。デフォルトがfalseですので、明示的にtrueを書いておかないと有効になりません。なので追加しました。

Countキーは発見された項目を何個置き換えるかを指定する箇所です。1個置換えてくれれば十分（それ以上検索する必要は無い）なので、1を指定しておきました。デフォルトは0で、それは発見できうる限り全て置換するという指定です。1箇所変換することで十分ならば、Countには1を指定したほうが、残りの部分を全部検索するという無駄な処理が不要になるので、高速になると思います。

このパッチをOpenCoreのconfig.plistに追加したところ、Pioneerのブルーレイドライブが正常に動くようになりました。パッチを施したconfig.plistを以下に置いておきます。もしこれを使用する場合は、SystemSerialNumber、SystemUUID、MLB、ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

PlistEDPlusで編集

（追記）PlistEDPlusでOpenCore 0.6.9のconfig.plistを編集する様子を以下に示します。いくつか項目が増えていますがデフォルトで良いです。データがASCII表示もされるので確認が楽です。

まとめ

Cloverに当てていた光学ドライブのパッチを、OpenCoreのconfig.plist用に書き換えて動作を確認しました。CloverとOpenCoreでは、パッチのキー構成が多少違います。Cloverに当てていた他のkext用パッチも、必要に応じてOpenCoreに移行して、動作を確認していこうと考えています。

ASUSマザーボードがPOST失敗してF1対応を促される

Sat, 16 May 2020 10:50:57 +0900

OpenCoreに移行したら再起動するたびに「safe modeでPOSTしたのでF1キーを押してsetupしてね」と言われるようになりました。config.plistでDisableRtcChecksumをtrueにすると治りました。

追記：当初、対策2と対策3の内容で対応していましたが、コメントでTakさんからDisableRtcChecksumで対応できることを教えていただきましたので、対策1として追記しました。

OpenCore移行したらPOSTエラー発生

ASUS ROG MAXIMUS HERO WIFI (Z390) をOpenCoreに順調に移行できたかに見えました。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

でも再起動をすると、POSTのエラーメッセージが出て、SETUP画面を起動しないと先に進めなくなりました。エラーメッセージは、

システムはセーフモードでPOSTしました。
これはシステムが不安定なために前回のPOSTの試みが失敗したこと、または、電源ボタンが長押しにより強制終了されたことが原因かもしれません。
もしUEFI設定を変更した後にPOST失敗したのでしたら、安定した設定に戻したいと希望されているでしょう。F1キーを押してSETUPを起動してください。

との表示です。この後、F1キーを押してSETUPに入り、そこから起動を選ぶと、今度は正しく起動します。なので大して困る状況ではないですが、次の再起動でまたこの画面になり、対応が面倒です。

Cloverの時はこのような現象はありませんでした。OpenCoreでシャットダウンして、Cloverを起動する場面でも発生します。なので、OpenCoreでシャットダウンするときに、何かしらの不具合が発生しているのかもしれないです。

ASUSでよくあること？

検索してみたところ、同様の現象は多数報告されています。今回と同様に、CloverからOpenCoreに移行したらこうなったという人も多いです。でも過去には、Cloverでも発生していたようです。発生はしていたけど、Cloverのバージョンが上がったら治ったという報告もありました。ということで、よくある現象のようです。

対策1：DisableRtcChecksumをtrueにする

対策2以降の記事を書いたところ、コメントでTakさんから教えていただきました。この方法で解決しました。OpenCoreコミュニティのおすすめの解決方法のようですので、対策2以降は無視していただいて良いです。config.plistのKernel, Quirksの場所にあるDisableRtcChecksumを、以下のようにtrue（デフォルトはfalse）に設定すれば治ります。OpenCore 0.5.8から可能になった方法です。

 <key>Kernel</key>
 <dict>
（中略）
 <key>Quirks</key>
 <dict>
（中略）
 <key>DisableRtcChecksum</key>
 <true/>

この問題はリアルタイムクロック (RTC) が関係する問題だそうです。macOSのAppleRTC.kextが、シャットダウンするときにチェックサム値をファームウェア（電池バックアップされたマザーボード上のCMOSメモリ？）に書き込むようです。おそらくはそのことでマザーボードのデータを壊してしまうらしく、次のPOSTで失敗を引き起こしているようです。チェックサムを書き込む場所が0x58~0x59（番地？）で、DisableRtcChecksumをtrueにするとそこへの書き込みを禁止してくれるようです。以下にも説明があります。

この説明によると、DisableRtcChecksumをtrueにしてもまだ問題が発生するようなら、RTCMemoryFixup.kextを入れて、ブートオプションで、

rtcfx_exclude=00-FF

のようにして、0x58~0x59以外の領域も保護するようにすると良いようです。これでうまくいった場合は、ブートオプションを変更して、保護する範囲を狭めると良いようです。

対策2：BIOSで設定する

追記：対策1が簡単で根本的なのでおすすめです。

有効な対策の一つが、このメッセージを出さないようにBIOSで設定する方法です。メッセージをよく読むと、「BIOS設定を間違って失敗した場合は、元に戻したいと思うから、F1キーでSETUPにすぐに入れるようにしておいてあげたよ。」という意味の内容が書いてあります。どうやらsafe modeでPOSTしたこと自体は大した問題ではなくて、利便性のためにF1キーですぐにSETUPに入れるよう配慮してくれているようです。今回はBIOS設定を間違えたわけではありませんので、この「親切機能」をoffにしても良いと思います。

BIOSの設定では、Boot, Boot Configurationの中に、Wait For ‘F1’ If Errorという項目があります。これが「POSTに不具合あったらF1キーを待つ」という設定です。デフォルトではEnabledなので、これをDisabledにします。これで問題なく起動するようになりました。

とはいえ、大元の原因は解決できていないので、応急措置な感じは拭いきれません。探したところ、もう少し根本的な対策もあるようです。

対策3：AppleRTCにパッチを当てる

追記：対策1の方が簡単です。そちらをおすすめします。

こちらで対策が紹介されていました。

OpenCore causes UEFI to POST in safe mode

ここで紹介されているパッチをOpenCoreのconfig.plistのKernel, Patchに追加したところ、この現象は発生しなくなりました。config.plistをテキストエディタで開いて、パッチを挿入します。Patchという項目は、ACPIの項目にもあるので、間違えないように注意です。（最初は間違えてしまってパッチが効きませんでした。）パッチを施したconfig.plistを以下に置いておきます。もしこのconfig.plistを使用する場合は、SystemSerialNumber、SystemUUID、MLB、ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

まとめ

OpenCoreにしたらsafe modeでPOSTする症状が出ました。ASUSではよくあることらしいです。SETUPに入ることを求められるので面倒です。config.plistでDisableRtcChecksumをtrueにして、シャットダウン時にmacOSがチェックサムを書き込まないように設定すると治りました。ということでOpenCoreの問題ではなくて、macOSとマザーボードの相性の問題のようです。Cloverで発生していなかったのは、単にデフォルトで対策されていただけなのかもしれないです。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

Fri, 15 May 2020 01:17:30 +0900

ASUSのZ390マザーボードと9900Kの組み合わせでmacOSを動かしているマシンのブートローダーを、CloverからOpenCoreに移行しました。OpenCoreのconfig.plistはCloverに比べて複雑ですが、親切なページと便利なツールがあったので円滑に移行できました。

OpenCoreのガイドとツール

Youtubeのビデオ

OpenCoreを使ってみた、という程度の記事を書きました。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のための機能を追加されたようです。

GitHub - corpnewt/ProperTree: Cross platform GUI plist editor written in python.

今まで、config.plistはテキストエディタで編集する、というストイックな対応をしてきましたが、OpenCoreのconfig.plistは長くて複雑です。なので今後はこのツールを使っていきます。

ProperTreeを使うためには、上記のサイトからファイル一式をダウンロードします。ダウンロードしたファイルの中のProperTree.commandがメインのPythonプログラムです。ファインダーからこれを開くか、またはTerminalから起動します。ファインダーから開く場合は、Terminalのウィンドウが一つ開いて、GUIウィンドウが現れます。Automator.appなどを使えばもっとアプリケーションっぽく見せられるとは思いますが、こういう形式も無骨で良いと思います。これでconfig.plistなどを開くと、XcodeのPlistエディタのように項目を開いたり閉じたりして閲覧し、内容を変更・追加・削除できます。

OpenCore Sanity Checker

OpenCoreのconfig.plistの正常性をチェックしてくれるページです。CPUとOpenCoreのバージョンを指定して、config.plistファイルをドラッグ&ドロップすると検査結果を表示します。この記事の最後で、作成したconfig.plistのチェックを行いました。

OpenCore config.plist Sanity Checker

ハードウェア構成

この記事の対象としたマシンは、以下で紹介したZ390マザーボード＋9900Kです。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ハードウェアの構成を再掲すると、

マザーボード： (値上がりしてますね)
CPU： @ 4.00GHz
グラフィックス：
WiFi/Bluetooth： (中身は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ボタンをクリックして、全選択して、MaciASL.appでコンパイルします。MaciASLについては、こちらをご覧ください。

DSDTを編集する

例えば、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個になりました。

15個制限を回避するUSBInjectAll.kextの役割と使用法

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 Clean Snapshot機能は、その順番も正しく判断してくれます。Kexts以外に、ACPIとDriversとToolsの中身も検索して、自動的に該当する箇所の記述を更新してくれます。

ACPIとKextsとToolsディレクトリのファイルに関しては、config.plistの記述の中でEnabledキーをTrueまたはFalseにすることで、個別にon/offすることが可能です。OC Clean Snapshot機能は、全てTrueにしてくれます。一方、OC Snapshot機能は、全てFalseにします。手動で必要なものを選ぶことになります。ACPIとKextsとToolsディレクトリ内にあるSSDT, kext, efiツールを有効にしたいという目的からしたら、OC Clean Snapshotの方が理にかなっていますし、こちらを使うのが便利だと思います。

ACPI項目

ではガイドのページと、ProperTreeのウィンドウを見比べながら細かい設定をしていきます。まずはACPI項目です。OC Clean 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.plistの初期値では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.plistの通り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 Clean Snapshot機能により自動設定されています。Quirksの項目のいくつかをデフォルトから変更します。デフォルトから変更する箇所は以下です。

AppleCpuPmCfgLock: True、BIOSでCFG lockが解除できるなら不要です。ASUSのZ390マザボは解除できるのでFalseでも良いです。CloverのAppleIntelCPUPMに相当します。
AppleXcpmCfgLock: True、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 timerを無効にします。
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 Clean Snapshot機能により自動設定されています。Quirksの項目のRequestBootVarFallbackをTrueに変更します。と書いてありますが、説明読んでもあまり違いはない気がしました。

以上でconfig.plistの設定が終了しました。それぞれの項目の説明がそれなりに書いてあるので、Cloverよりも明朗な感じです。説明資料が整っている印象があります。この状態で再起動すればOpenCoreから起動するはずです。起動しなければ、UEFI shellからEFIディレクトリの名前を書き換えて、Cloverに戻せば良いと思います。と考えて再起動を試したところ、なんと1回で成功しました。完成したconfig.plistを以下に置いておきます。SystemSerialNumber、SystemUUID、MLB、ROMの値は、これを使用せず、みなさんで必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

Sanity Checkerで検証

ここで作ったconfig.plistを、OpenCore Sanity Checkerで検証しました。

OpenCore config.plist 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の設定を行なっています。

ASUSマザーボードがPOST失敗してF1対応を促される

Pioneer光学ドライブのパッチをOpenCoreに適用する

OpenCoreの選択画面をグラフィカルにする

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

使用するUSBポートを15個指定する (OpenCore編)

まとめ

Z390マザーボードのマシンをCloverからOpenCoreに移行しました。それなりに時間はかかりましたが、すんなりと運びました。今回はCoffee Lake CPUマシンの移行でしたが、他のCPUについても同様に詳しい手順が説明されているので、問題なく移行可能と思います。説明資料やチュートリアルが充実していて、ツールも揃っているので、そろそろOpenCoreに移行しても大丈夫な時期になったかと感じました。細かい設定などを調べつつ、他のマシンも、順次切り替えていきたいと思います。

100シリーズチップセットで本物のNVRAMを使う

Sat, 09 May 2020 23:34:38 +0900

SSDT-PMC.amlをEFI/CLOVER/ACPI/patchedに入れると、Intel 100シリーズチップセットでもNVRAMの値が保存されるようです。Q170搭載のHP社小型デスクトップPC、HP EliteDesk 800 G2 DMで試した結果を報告します。

これも、「HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM にmacOSを入れる」シリーズの記事ですが、小ネタです。

HPの小型デスクトップEliteDesk (1: macOS導入)

300チップセットでNVRAMを使う

NVRAMを使うために、従来は、EmuVariableUefi.efiドライバを入れていました。でも300シリーズチップセットではNVRAMの内容が正しく保存されない問題がありました。しかし、最近OpenCoreの成果で作られたSSDT-PMC.amlを使えば、300シリーズチップセットでもNVRAMが正しく使えます。という記事を、以下に書きました。

300シリーズマザーボードでも本物のNVRAMを使いたい

100チップセットでもNVRAMを使う

最近、HP EliteDesk 800 G2 DMのスリープ対策で色々試していたところ、このマシンでもEmuVariableUefi.efiではNVRAMに書き込めないことに気づきました。公開されている仕様書によると、HP EliteDesk 800 G2 DMはQ170チップセットを使っています。100シリーズチップセットでも300シリーズチップセットと同様な問題があるようです。

そこでSSDT-PMC.amlを使ってみたところ、なんと正しくNVRAMが動きました。ということで、SSDT-PMC.amlは、300シリーズに限らず、おそらく100シリーズでも有効なようです。以下に、EmuVariableUefi.efiを使った場合と、SSDT-PMC.amlを使った場合の比較を書いておきます。

EmuVariableUefi.efiを使う

まずは、EmuVariableUefi.efiを

EFI/CLOVER/drivers/UEFI/EmuVariableUefi.efi

の場所に入れて起動した場合です。ターミナルからnvramコマンドで、意味のないhogeという名前の変数にtestという文字を登録します。nvram -pコマンドで確認できるので、そこからhogeだけ取り出して表示します。この一連の作業を行った結果を以下に示します。

% sudo nvram hoge=test
Password:
% nvram -p | grep hoge
hoge	test

ここで再起動します。再起動後に、nvram -pコマンドを試すと以下になりました。

% nvram -p | grep hoge

再起動前に設定した変数が消えています。

SSDT-PMC.amlを使う

次にSSDT-PMC.amlを

EFI/CLOVER/ACPI/patched/SSDT-PMC.aml

に入れて起動します。この状態で、ターミナルからnvramコマンドで、同様に変数hogeにtestという文字を登録して、nvram -pコマンドで確認します。

% sudo nvram hoge=test
Password:
% nvram -p | grep hoge
hoge	test

ここで再起動します。再起動後に、nvram -pコマンドを試すと以下になりました。

% nvram -p | grep hoge
hoge	test

SSDT-PMC.amlを入れておけば、Q170チップセットでもNVRAMに値を入れて、再起動後も読み込めるようです。ちなみにSSDT-PMC.amlを入れた状態で設定した変数は、これを外してEmuVariableUefi.efiを入れた状態でも読み込めました。EmuVariableUefi.efiを使うと、再起動前に変更したり書き込んだ結果が消えてしまうものの、正しく書き込まれているNVRAM値は読めるようです。

まとめ

SSDT-PMC.amlは300シリーズチップセットだけでなく、他のチップセットでも有効なようです。300シリーズ以外のユーザの皆さんも、ぜひお試しください。その結果をコメント欄で報告いただければありがたいです。ちなみに設定してしまった意味のない変数は、

% sudo nvram hoge=

とすれば消せます。

ThinkPad T460s (6300U) にOpenCoreでCatalinaを導入

Tue, 14 Apr 2020 22:53:41 +0900

Skylake 6300Uを搭載したThinkPad T460sにOpenCore (OC) でmacOS Catalinaをインストールしました。手順と必要ファイルが揃っているGitHubページがあったので、苦労なしで完成度の高いmacOSマシンが出来上がりました。

動作状況

最初に動作状況をまとめておきます。完成度はかなり高いです。

動くこと

macOS Catalina 10.15.4
macOSのアップデート (10.15 –> 10.15.4)
シャットダウンおよびSleepとsleepからの復帰
iGPUのグラフィックス加速
LAN
USB 3.0 x 3 (Gen 1, 5Gbps)
サウンド（内蔵スピーカ・ヘッドフォン自動切り替え）
内蔵カメラ・マイクロフォン
Fnキーからの明るさ・音量調整
Siriの音声認識
バッテリー残量表示
HDMIからの表示
高DPIスケール動作（720p相当を1.5倍の1080pで表示中）
Night Shift
マルチタッチジェスチャ（2本指でスクロールできる程度）
App Store

動かないこと

Wifi/Bluetooth (M.2モジュールを交換予定)
SDカード、指紋認証（macOSが非対応なので無理です）

未確認なこと

continuity, iPhone, iPad, Watchとの連携, AirDrop, Sidecar, iCloud, iMessage, FaceTime（WiFi/BT交換後に試します）
Mini DisplayPortからの表示（mini DPはもはや使わない）
WWANカードとSIM（動かしている例もあるらしいです）

ThinkPad T460sについて

以前、X220にmacOSをインストールしました。今回は少し大きめのT460sにmacOSをインストールします。

Lenovo ThinkPad X220, 2620M

X220は昔ながらの作りの良いキーボードを採用した最後のモデルです。でも第2世代Sandy Bridge CPUなのでCatalinaは公式サポートされてません。次にノートPCでhackintoshするなら、現行macOSが動く第3世代 (IvyBridge) 以降のCPUで試したいと思っていました。また、先日、HPのHP EliteDesk 800 G2 DMがとても簡単に動いて、気に入っていました。

HPの小型デスクトップEliteDesk (1: macOS導入)

第6世代 (Skylake)はmacOSとの相性が良さそうな気がします。またSkylakeならCatalinaで動くだけでなく、Sidecarにもギリギリ対応しています。Kaby Lake, Coffee Lakeならばさらに新しくて良いのですが、遊ぶ目的としてはまだ高価です。Lakeシリーズ初代のSkylake搭載製品ならば、5-6年前の製品なので、リース終了後の法人物件が出回っていて、値段が手ごろです。8GBメモリ、256GB SSD程度の構成で、デスクトップなら1万円代、ノートPCでも2万円代で中古品が購入可能です。

Skylake搭載ThinkPadで中古品を探すと、X260とT460sが目につきました。ThinkPadは型番3桁部分の、100の位がディスプレイの大きさ（12インチなら2, 14インチなら4）で、10の位がCPUの世代数を表しています。例えばX260は第6世代の12インチモデルで、T460sは第6世代の14インチです。X260とT460sはほぼ同じくらいの中古価格で取引されています。どちらにするか大いに迷いました。でも、macOSのインストール状況を検索した限りでは、X260では多くの人が困難に遭遇しているのに対して、T460sではインストール手順情報が充実していて成功率が高い様子でした。構造はほとんど変わらないと思うので、単にユーザ数の違いかもしれません。それでも成功例報告の多いT460sにしました。後述のように、T460sの到着前に、さらに親切なGitHubページを発見できてラッキーでした。

到着して開封した時、予想以上に薄いので驚きました。実は、T460とT460sは販路が違うだけで同じものだと思い込んでいました。ネットにあったT460の分解動画をいくつか見ていて、その厚さだと思ってました。sが付くだけで全然違うモデルなのですね。T460は、2.5 inch SSD, 取り外し可能バッテリーなのに対して、T460sは、M.2 SSD, 内蔵バッテリーのみになり、薄くなっています。他にもいくつか変更されています。メモリーソケットが2個から1個に減っています。これは少し残念ですが、マザーボードに8GB搭載されていたので十分です。T460sになって一番嬉しいことは、裏蓋を止めている爪が簡単に外れるようになったことです。T460の分解動画では裏蓋の隙間にヘラを入れてベキベキと外していた様子だったのが、なんの苦労もなく裏蓋が外れます。裏蓋を止めているネジも8個から5個に減りました。

入手したT460sの液晶はfull HDのIPS液晶でした。国内販売品は全部FHDのようです。タッチ入力対応のモデルもありますが、macOSでは不要でしょう。

キーボードは相当にテカってます。プラスチック表面のシボ加工が取れて、ツルツルの面になってます。汚れているわけではないですが、触るとペタペタした感触があります。さらにはA, H, Nなどのキーは文字も消えかけています。前のユーザのお役に立って活躍していたようです。で売ってますので、交換したいと考えています。同じ世代のThinkPadでもX260はキーボード交換がかなり面倒なのですが、T460シリーズはThinkPadの伝統を引き継いでいて、交換が楽です。

裏蓋は5個のネジで外れます。ネジは蓋から外れない方式なので、行方不明になる心配がありません。分解動画で比較すると、T460に比べてT460sは爪がすぐに外れるように作られているようで、分解が楽です。裏蓋を開けた中は以下のようです。

内蔵バッテリーが写真の上下に2個あります。全体にかなり薄型なのですが、まだまだいろいろいじれる部品構成です。中央右のヒートパイプの端あたりにCPUがあります。その下に、DDR4 SODIMMの空ソケットが一つあります。マザーボードにメモリーが既に搭載されていて（今回入手したモデルは8GB）、これに加えて増設できます。CPU左側の黒い絶縁シートが貼られた大きなエリアは、空き地です。Nvidia GeForce 930MというGPUを搭載するモデルがあり、そのGPUの接点がある場所です。macOSではサポートされていないGPUですので、GPU搭載モデルを選ぶ必要はありません。

左の部分には3種類のM.2のソケットがあります。それぞれ、WLAN, WWAN, SSD用です。WLANはインテルのM.2モジュールが取り付けられています。無線LANとBluetoothが搭載されています。インテルの無線LANはmacOSでは使えません。Bluetoothはどういうわけかシステム環境設定に現れますが、これも使用不可能です。BroadcomのM.2モジュールに交換する予定です。参考にしたGitHubページでは、M.2用アダプタを使って純正のBroadcomモジュール、BCM94360CS2を取り付ける様子が紹介されています。厚みが増えるため裏蓋が少し浮くようですが、この方式ならmacOSとの互換性は完璧です。

WWAN用のM.2ソケットは空です。でもアンテナは配線されています。国内の一般販路ではWWANモデルは流通していないらしいです。

M.2 SSDソケットには切り欠きが2箇所あるSSDが装着されていました。型番から東芝のSATAタイプの256GB M.2 SSDだと判明しました。これだけ容量があれば、macOSの動作には問題ありません。手元のSSDで試したところ、NVMe方式のM.2 SSD（切り欠きが1箇所のタイプ）も使えました。

OpenCoreで導入を試みる

今回のmacOS導入は、全く努力してなくて、落ちていたESPファイル類を拾ってコピーしただけのヘタレなハッキングです。こちらのサイトのおかげです。本当に感謝したいです。

GitHub - simprecicchiani/ThinkPad-T460s-macOS-OpenCore: Bootloader configurat…

実はこのGitHubページは、先月末にできたばかりのようです。このページを使ってT460sでmacOSを動かせたことが、T460sの到着前日にRedditで紹介されていて知りました。デスクトップに比べてノートPCのhackintoshは複雑なので、tonymacx86やredditで実績のある機種を選んだ後で、実際に調達するという手順が良いように思います。

BIOSを設定する

上記のサイトにはBIOS設定も書いてあります。以下の設定が必要とのことです。

Security -> Security Chip Disabled
Memory Protection -> Execution Prevention Enabled
Virtualization -> Intel Virtualization Technology Enabled
Virtualization -> Intel VT-d Feature Disabled
Anti-Theft -> Current Setting Disabled
Anti-Theft -> Computrace -> Current Setting Disabled
Secure Boot -> Secure Boot Disabled
Intel SGX -> Intel SGX Control Disabled
Device Guard -> Disabled
UEFI/Legacy Boot -> UEFI Only
CSM Support -> No

これ以外も趣味に合わせて設定しました。例えば、WiFi, Bluetooth, 指紋センサー、SDカード読み取り機などはmacOSで動きませんので、節電になるかと思いdisabledに設定しました。

macOS導入用USBメモリを作成する

まずは通常のhackintoshの手順に従って、まずはインストール用のUSBメモリーを作成しました。Appleのサイトに書いてあるようにcreateinstallmediaコマンドを使います。こうして作成したUSBメモリのESP (EFI System Partition) をマウントします（diskutil listコマンドでUSBメモリのESPが例えばdisk5s1だとわかったら、sudo diskutil mount disk5s1とタイプします）。次に、上記のサイトからダウンロードしたESPの内容を、ごっそりとUSBメモリのESPにコピーします。ファインダーのドラッグ&ドロップで可能です。

こうして設定されるkext類は以下です。VoodooPS2Controllerなどは、キーボードやトラックポイントを動かすためのkextだと思います。

WhateverGreen.kext
VoodooPS2Controller.kext
USBPorts.kext
VirtualSMC.kext
VoodooInput.kext
SMCProcessor.kext
SMCSuperIO.kext
SMCLightSensor.kext
SMCBatteryManager.kext
Lilu.kext
IntelMausi.kext
CPUFriend.kext
AppleALC.kext

efiドライバーは以下です。Cloverに比べると少ないですね。

OpenRuntime.efi
HfsPlus.efi
ApfsDriverLoader.efi

SSDT類は大量にあります。バッテリー、電力制御、PS2関係など色々用意されているようです。これらを自分で作るのは大変なので、ありがたいです。

SSDT-XCPM.aml
SSDT-ALS0.aml
SSDT-BAT.aml
SSDT-BATC.aml
SSDT-BKeyQ14Q15.aml
SSDT-DMAC.aml
SSDT-EXT3-LedReset.aml
SSDT-EXT4-WakeScreen.aml
SSDT-MCHC.aml
SSDT-PMCR.aml
SSDT-PNLF.aml
SSDT-PS2K.aml
SSDT-PTSWAK.aml
SSDT-PWRB.aml
SSDT-SMBU.aml
SSDT-UIAC.aml
SSDT-USBX.aml

config.plistをカスタマイズする

配布されているconfig.plistでは、機種がMacBookPro13,1に設定されていました。この機種はCPUとして6360U, 6600Uを搭載しているので、6300Uで使用するには適切な選択です。ただMacBookPro13,1のiGPUはIntel Iris Graphics 540なので、6300UのIntel HD Graphics 520とは違います。でもこれで問題なく動きました。ただ、このconfig.plistには個別のマシンの情報が入っていないので、それだけは編集します。

CloverとOCでは個別マシン情報の項目名が異なります。Cloverのconfig.plistでSerialNumberとBoardSerialNumberは、OCのconfig.plistでは、それぞれPlatformInfo, Genericの中のSystemSerialNumberとMLBに相当します。Cloverの時と同様にClover Configuratorなどで生成して、シリアル番号が使えるかどうかをAppleのサイトで確認して、その値を記入します。SystemUUIDも、ターミナルのuuidgenコマンドを使って生成して設定します。

また、PlatformInfo, Generic, ROMの値も独自の値を入力します。これは6バイトの数値です。サンプルでは0x112233440000というような値が入っています。世界に存在しない独自の値を入れれば良いようで、通常はEthernetのMACアドレスを使います。これは、システム環境設定、ネットワーク、Ethernet、詳細、ハードウェアと辿ると分かります。例えばこれがc0:7e:bf:c3:af:ffでしたら、

echo -en "\xc0\x7e\xbf\xc3\xaf\xff" | base64
wH6/w6//

とするとbase64値、この場合wH6/w6//が得られます。これをチェックするには、

echo -n wH6/w6// | base64 -d | hexdump 
0000000 c0 7e bf c3 af ff

とすれば確認できます。この値を、PlatformInfo, Generic, ROMのところに

<key>ROM</key>
<data>wH6/w6//</data>

として書き込みます。

USBメモリで起動してmacOS導入

これでOCから問題なくmacOSのインストーラが起動しました。まずは東芝のM.2 SATA SSDをAPFSでフォーマットしてインストールを試みました。するとmacOSのインストール先にAPFSドライブを選択できません。「APFSのボリュームにインストールするためにはMacのfirmwareアップデートが必要だからHFS+を選べ」と言っているようです。MacBookPro13,1はSierraの時代のマシンですので、firmwareがAPFS起動に対応していないです。なのでmacOSインストールの時についでにfirmwareアップデートも行われます。この場面では、firmwareアップデート前の状態と判断されたので、APFSが選べなくなっているのだと思います。

Your Mac needs a firmware update in order to install to this volume. Please select a Mac OS Extended (Journaled) volume instead.

仕方なくHFS+に戻しました。いったんAPFSにすると、DiskUtility.appのGUI画面からはHFS+に戻せなくなってました。ターミナルから

diskutil eraseDisk JHFS+ "Macintosh HD" disk0

などすればHFS+に戻せます（対象がdisk0だった場合の例です）。

これでインストール先として選択できるようになるのですが、インストールを少し進めると、以下のようなエラーメッセージで止まってしまいました。firmwareを検証中にエラーが出るようです。

An error occurred while verifying firmware.

hackintoshなのでfirmwareのバージョン等情報がおかしいのは当然です。Cloverはそれを自動的に偽装してくれます。また、config.plistのBiosReleaseDateやBiosVersionの項目で偽装用の情報を指定することもできます。同じようなfirmwareバージョン偽装設定をOCのconfig.plistでやろうとしたのですが、方法がわかりませんでした。Cloverの項目名では判別できないというエラーが出ました。

Cloverで導入を試みる

この状況に対処するために、M.2 SSDをmacOSマシンに接続してmacOSをインストールすることも可能だったと思います。でも今回は、手元にM.2 SATA SSDをUSB変換するアダプタがなかったので、Cloverで起動することに方針変換しました。kextとSSDTはこのGitHubページのものをそのまま使いました。UEFIドライバは、Cloverでいつも使っている内容です。

VirtualSmc.efi
VBoxHfs.efi
OsxAptioFix3Drv.efi
FSInject.efi
EmuVariableUefi.efi
ApfsDriverLoader.efi

config.plistも、Cloverで使っているシンプルなものを使いました。ただDevicesの場所は、OCのconfig.plistを参考にして以下の設定にしました。

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
	<dict>
		<key>AAPL,ig-platform-id</key>
		<data>AAAWGQ==</data>
		<key>enable-hdmi20</key>
		<data>AQAAAA==</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-unifiedmem</key>
		<data>AAAAgA==</data>
	</dict>

この設定によると、ig-platform-idは0x19160000です。こちらのサイトによると、Intel HD Graphics 510から580搭載laptopのための推奨値のようです。

この結果、Cloverでも無事起動して、しかも今回はfirmware関係のエラーメッセージも出ず、順調にmacOSインストールが可能でした。macOSをM.2 SATA SSDにインストールした後で、そのSSDのESPにも、インストール用USBメモリーと同じ内容をコピーしました。これでSSDからCatalinaが起動します。

動作確認とベンチマーク

このMacについて、を見ると以下のようです。Thunderbolt 3のあるモデル番号なので、無いのに表示されてしまいました。

CPUの名前は、以下のコマンドで確認できます。

sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz

正しく6300Uだと認識されています。Geekbench 5でスコアをとってみました。Haswell, Broadwell, Skylakeあたりはだいたい同じくらいのスコアですね。2コアなのでそれほどスコアが上がりません。

結局OpenCoreに移行する

Cloverでほぼ問題なく動いている様子でしたが、バッテリーの表示が正しく表示されないことに気づきました。GitHubからダウンロードしたそのままのOpenCoreのESP内容に置き換えて起動したところ、今度はバッテリー残量が表示されました。

Cloverでも、おそらくはちゃんと設定すれば、バッテリー残量の表示を可能にできたとは思います。でも、楽ですし、時代はOpenCoreに移行する方向らしいので、結局、最初のようにOCで使うことにしました。firmwareの確認は初めてAPFSを使うときにのみ現れる様子で、macOSアップデートなどでは問題ないようです。

以下に続きます

引き続き、WiFiを整備したり、キーボードを交換したりしたいと計画しています。以下もご覧ください。

ThinkPad T460sのBIOSを更新する

ThinkPad T460s にWiFi/BTカードBCM94360NGを取り付ける

ThinkPad T460sのキーボード交換

まとめ

この機種用の情報を提供してくれたGitHubページのおかげで、完成度の高いmacOSノートPCが完成しました。実のところかなり気に入っています。無線カードなどを調達して、もう少し遊んでみたいと思います。

300シリーズマザーボードでも本物のNVRAMを使いたい

Wed, 22 Jan 2020 23:43:17 +0900

現行の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投稿の抄訳です。

r/hackintosh - NVRAM for all! 300 series users rejoice!

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に設定する必要もあります。

300チップセットマザーボードのRTC設定

Sat, 28 Dec 2019 15:06:42 +0900

Intel 300チップセットを搭載した現行のマザーボードからRTCの扱いが変わりつつあるようです。これが原因でmacOSの起動に失敗する事があります。DSDTへのパッチをconfig.plistに加える、もしくはBIOSで設定する事により回避できます。

BIOSをアップデートして失敗したというこちらの記事

ASUSのBIOSを1105以上に更新すると起動しない

で紹介した内容ですが、いまやHackintoshを作る上での一般的な注意事項になったと思います。なので、GUIDESカテゴリーに見合った内容に書き直して再掲します。

Real Time Clock (RTC)

コンピュータは、ファイルのタイムスタンプ管理やネットワーク同期など、いろいろな場面で正確な日付と現在時刻を必要とします。そこで、コンピュータの電源がoffになっても、日付と現在時刻を更新し続ける水晶時計機能が用意されました。これがRTC（Real Time Clock, 実時間時計）です。RTCは小さな部品としてマザーボードの片隅に載っていました。今ではチップセットに組み込まれています。RTCは、マザーボードの電源が切られた場合でも、マザーボード上のコインバッテリーで動き続けます。ちなみに太古のコンピュータにはRTCはありませんでした。なので、コンピュータ室を占拠する大型計算機も、AppleやNECの初期のパソコンも、電源を入れて最初に行う仕事の一つが、今日の日付と現在時刻の入力作業でした。

RTCは現時刻を知る時計として使われるだけでなく、プログラム実行のきっかけを提供する目覚まし時計としても使われます。RTCにはコンピュータ作業に割り込みをする機能があり、割り込みで起動するタスクやスレッドを設定可能です。なので、毎日決まった時間に行う仕事、一定時間で繰り返す仕事などを設定しておけます。さらには、仕事の時間切れ管理にも使われます。例えば、特定のハードウェアがコンピュータに装備されているかどうかを確認する作業を考えてみます。そのハードウェアに、あなたは存在しますか？と問いかけるのですが、返事をじっと待っていては時間の無駄です。装備されていないために、永遠に返事が来ない可能性も高いです。そこで確認呼びかけと同時に、RTCに例えば10秒後にアラームしてくれるようにお願いします。そうすれば、返事を待つ間に別の仕事を実行したり、待っている間は休眠して他のスレッドにCPU資源を譲ることもできます。このように、外部デバイスにアクセスしつつ、アラームを仕掛けて返事を確認する作業は、macOSの起動時にもいくつも行われているようです。このような過程で、もしRTCのアラーム機能が動かなければ、macOSの起動が止まってしまう可能性があります。

RTCの世代交代

300シリーズチップセットになってRTCの世代交代が進んでいるようです。BIOSメニューの表現を借りると、従来型のRTCからACPI (Advanced Configuration and Power Interface)のTime and Alarmデバイス（長いので以下、ACPI時計と書きます）に移行しているようです。そしてACPI時計を使う事がデフォルト設定になりつつあるようです。

ACPI時計ではOSが起動しない

ところが、ACPI時計を使うとmacOSの起動が止まってしまうようです。最初に紹介した過去の記事では、ASUSのZ390マザーボードのBIOSを1105に更新したところ、ACPI時計がデフォルトで使われるようになってしまって、macOSが起動しなくなったことを書きました。-vで起動すると起動途中で文字表示が止まってそのまま動かなくなります。apfs.efiなのかVirtualSMCのあたりのメッセージで止まります。そのあたりの処理（apfsなら起動ドライブへのアクセスかもしれません）でRTCの割り込みが効かなくなり、処理が止まってしまったような様子です。RTCがACPI時計に置き換わって、使えなくなったのが原因だと思います。Cloverの問題なのか、macOSそのものがRTCに依存しているのかわかりませんが、この問題に対策を施さないとmacOSが起動しません。

実はこの問題は、1年以上前からASRockのマザーボードで発生していました。ASRockはいち早くACPI時計をデフォルトにしたようです。これを回避するパッチが見つかるまで、ASRockのマザーボードではmacOSが起動しない状態がしばらく続きました。HackintoshするならASRockは避けた方が良いかなと思っていたところ、数ヶ月後のBIOSアップデートでASUSのマザーボードも同様にACPI時計がデフォルトになってしまいました。フォーラムの方で教えていただきましたが、MSIのマザーボードでもACPI時計がデフォルトになっているようです。GIGABYTEの様子は把握していませんが、おそらくここ1年くらいで、どのマザーボードもレガシーRTCからACPI時計に移行していると思われます。この対策として次の4つの方法があります。

対策1 : BIOSでRTCを選択する

ACPI時計への移行をやめて、レガシーなRTCを使い続ける設定が一部のBIOSにあるようです。以下で紹介されています。

ASUSのマザーボードには、Advanced–>PCH Configurationの中に、System Time and Alarm Sourceの設定があります。これをデフォルトのACPI Time and Alarm DeviceからLegacy RTCに変更すれば良いようです。

ところが全てのマザーボードにこのメニューが出てくるわけではないようです。例えば、ROG MAXIMUS XI HEROのBIOS ver. 1105, 1302, 1401の画面にはこの選択肢が出てきません。もしかしたら将来のバージョンでRTCの選択肢が出てくるようになるのかもしれません。という事で、このメニューが出ないマザーボードでは、BIOSでLegacy RTCを指定する方法は使えません。

対策2：DSDTパッチを当てる

幸いなことに、ASRockのために配布されたパッチは、他のマザーボードでも動くようです。例えばこちらで紹介されています。

パッチの元記事によると、「ASRockマザーボードのDSDTのバグで、そのうちASRockが治してくれると思うけど、とりあえずこのパッチが動く」という意見らしいです。でも、このパッチが他のマザーボードでも有効らしいので、ASRock限定のバグ対策では無い気がします。これはACPI時計への移行を無効にしているパッチ、もしくはACPI時計を利用する問題点を回避するパッチなのではと思われます。パッチの方法は、config.plistのACPI –> DSDT –> Patchesに以下の記述をすることです。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ACPI</key>
	<dict>
		<key>DSDT</key>
		<dict>
			<key>Patches</key>
			<array>
				<dict>
					<key>Comment</key>
					<string>RTC fix</string>
					<key>Disabled</key>
					<false/>
					<key>Find</key>
					<data>
					oAqTU1RBUwE=
					</data>
					<key>Replace</key>
					<data>
					oAqRCv8L//8=
					</data>
				</dict>
			</array>
		</dict>
	</dict>
</dict>
</plist>

ちなみにこのパッチが探しているデータ列と、置き換えているデータ列はそれぞれ以下のようです。

% echo -n oAqTU1RBUwE= | base64 -d | hexdump -C
00000000 a0 0a 93 53 54 41 53 01 |...STAS.|
00000008
% echo -n oAqRCv8L//8= | base64 -d | hexdump -C
00000000 a0 0a 91 0a ff 0b ff ff |........|
00000008

STASという文字を消そうとしているようにも見えます。

対策3 : SSDTで対処する

コメントで教えてもらいました。OpenCoreプロジェクトで、この問題に対処するSSDTが作られているようです。こちらにある

OpenCorePkg/Docs/AcpiSamples at master · acidanthera/OpenCorePkg

SSDT-AWAC.dslをMaciASLでコンパイルしてSSDT-AWAC.amlを作り、これを、EFI/CLOVER/ACPI/patchedに入れれば良いようです。それがうまく動かない場合は、SSDT-RTC0.dslを試すと良いようです。SSDT-AWAC.dslはこんな感じの内容です。先程のDSDTパッチと同様に、STASというパラメータらしきものを変更しようとしているようです。

/*
 * For 300-series only. If you can't force enable Legacy RTC in BIOS GUI.
 * macOS does yet not support AWAC, so we have to force enable RTC. Do not use RTC ACPI patch.
 * 
 * The Time and Alarm device provides an alternative to the real time clock (RTC), which is defined as a fixed feature hardware device.
 * The wake timers allow the system to transition from the S3 (or optionally S4/S5) state to S0 state after a time period elapses.
 * In comparison with the Real Time Clock (RTC) Alarm, the Time and Alarm device provides a larger scale of flexibility in the operation of the wake timers,
 * and allows the implementation of the time source to be abstracted from the OSPM.
 */

DefinitionBlock ("", "SSDT", 2, "ACDT", "AWAC", 0x00000000)
{
 External (STAS, IntObj)

 Scope (_SB)
 {
 Method (_INI, 0, NotSerialized) // _INI: Initialize
 {
 If (_OSI ("Darwin"))
 {
 STAS = One
 }
 }
 }
}

ASUSのROG MAXIMUS XI HEROで試してみました。現時点で最新BIOSは1401ですが、なんの対処もしない場合はmacOSが起動しません。そこで、SSDT-AWAC.amlをpatchedに入れたところ、無事macOSが起動しました。なお、これでうまく動いたので、SSDT-RTC0.amlは試していません。

対策4 : 古いBIOSを使い続ける

レガシーなRTCがデフォルトになっている古いBIOSからアップデートしないという消極的な解決策もあります。いろいろなバグが修正されているはずなので、一般的には最新バージョンの方が気持ち良いです。でもBIOSに限っては、動いているなら更新するなと注意しているメーカーのページも時折見かけます。全ての環境を網羅して動作試験を行うことは困難なので、問題なければアップデートして欲しくないという事情もわからないではありません。なので、古いまま使い続けるのは良い選択肢かもしれません。

うっかりアップデートしてしまっても、古いBIOSがメーカーサイトで配布され続けていますので、それに戻せば良いです。ただ、新しいBIOSにすると、通常の手順では古いバージョンに戻せなくなる場合があります。そこでこちらの記事ではUSB BIOS Flashbackという機能を使って古いバージョンに戻しています。

まとめ

現行のマザーボードがレガシーRTCからACPI時計に移行した事でmacOSが起動しない問題が発生することがあります。この問題は、DSDTへのパッチをconfig.plistに加える、もしくはBIOSで設定する、もしくはSSDTで設定を変更する事により回避できます。

ワンクリックで最新KEXTに〜Kext Updater.app (Ver. 3)

Fri, 30 Aug 2019 21:13:28 +0900

この記事は、以下の古い記事のv.3対応改訂版です。

Hackintoshで使っているClover, EFIドライバ、kext類は、最新版を使うのが良いです。色々なバグが直されていて、安定しています。また常に最新にしておけば、macOSのバージョンアップにも対応できます。Catalinaに備えていつも最新状態にしておきたいものです。ただ、開発者の方々のページを巡回して最新版をチェックするのも大変です。

Hackintoshで使用中のkext類最新版をチェックして、新バージョンがあった場合にダウンロードしてくれる便利なツールがあります。ドイツのHackintoshフォーラムの人たちが作ってくれているKext Updaterです。以下から最新版が公開されています。

この記事ではVer. 3を紹介します。古い記事で紹介したVer. 2に比べてスッキリした画面構成になりました。

ボタンがいくつかあります。以下でそれぞれのボタンが提供する機能の説明をします。

Start

メインの機能です。「Start」ボタンを押すと、使用されているHackintoshのkextを全部調べ上げてくれて、それが最新版であるかどうか判断してくれます。最新版では無いkextは、自動的にダウンロードされて、デフォルトでは、デスクトップのKext-Updatesという名前のフォルダに入ります。このフォルダはフォルダーアイコンをクリックすると開けられます。そこで、必要ならば「EFI」ボタンを押してESPをマウントして、ダウンロードした最新版と入れ替えます。

Kexts

必要なkextを個別にダウンロードします。ソースコードのダウンロードもできます。また、更新があってもダウンロードしないkextの指定もできます。

WebDriver

nVidiaのグラフィックスドライバをダウンロードします。nVidiaドライバはMojaveから使えないのが残念です。この機能をボタンに割り当てているところに、開発者の皆さんがnVidia復活に期待している様子が伺えます。

Bootloader

ブートローダーをダウンロードできます。CloverとOpenCoreから選べます。OpenCoreは、Kext Updaterと同じコミュニティの人たちが開発している様子なので、ここに含まれているのだと思われます。

Report

ハードウェアやインストールされたkext, efiドライバ類の一覧の情報を作ります。しばらく時間がかかります。kext類についての情報を得るためは、SIPで署名のないkextを許容する設定が必要です。config.plistのRtVariablesのCsrActiveConfigの下位ビットを1にします（例えば0x01）。シリアル番号などは自動的にゼロにしてくれます。このまま公開して、フォーラムで質問するときに使ってくださいという意図のようです。

レポートファイルは、/tmp/kextupdater/の下にHTML形式で作成されます。情報取得が終了すると自動的に開くので、Safariなどのウィンドウで表示されます。

Tools

4種類のツールが使えます。どういう意図でこれらのツールが選ばれたのか少し謎です。いずれもちょっと微妙な機能です。

kextキャッシュと権限修復

/System/Library/Extensionsと/Library/Extensionsにあるkextのファイル権限とkextキャッシュを作り直します。バニラなインストールをしている場合は、この機能を使うことは無いかと思います。

AtherosのWiFi機能

Atheros (現在はQualcommと合併してQualcomm Atheros, Inc.)のAR92xx/93xxのためのkextが入手できるようです。ボタンを押してみたのですが、うまく機能しないようです。AliExpressで検索してみたら、AR92xx/93xxという名前のチップには、AR9380, AR9285, AR9280, AR9271, AR9377などがあり、PCIeカードの製品や、mini PCIe (mSATA)の製品などがあるようです。ただ、最新世代のWiFiではないようです。型番の数値が大きい、少しでも最新と思われるAR9380には以下のような製品があるようです。どれも14ドルくらいと安価です。こちらを参考にすると、IO80211Family.kextの中のInfo.plistのIDを変更すれば良いようです。でもOOBで動くBroadcomを使った方が良いですね。

Sleep設定

sleepに問題がある場合、役立つかもしれませんと書かれた機能もあります。hibernationが0に設定されて、hibernation用のイメージファイルが作成されないように、書き込み禁止でサイズがゼロのファイルが作られるようです。これも押してみましたがあまり動作がわかりません。pmset -a hibernatemode = 0とタイプするのと同じことが起こるのかと思われます。

ESPをマウントする機能

ドライブを指定して、ESPをマウントしたりアンマウントできます。これは妥当な機能かなと思いました。

新ブートローダーOpenCoreを使う

Sat, 20 Jul 2019 16:30:07 +0900

OpenCoreはCloverから分岐し、OZMOSISの流れを取り込んだ新しいオープンソースのブートローダーです。Z390マザーボードで動かしたところとりあえずはmacOSが起動しました。

追記：最近のOpenCore関連の記事もご覧ください。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

OpenCoreとは

OpenCoreは、完璧にオープンソースであることが特徴の新しいブートローダーです。Cloverから分岐し、OZMOSISの流れを取り込んでいます。OZMOSISを開発していたドイツのHackintosh-Forum.deの人たちが開発を進めているようです。OZMOSISってどんなものだったかと言うと、ファームウェア形式のブートローダーで、マザーボードのBIOSを置き換えて動作します。OZMOSISをマザーボードのBIOS更新機能を使ってインストールすれば、普通のマザーボードがmacOSを直接起動できるマザーボードに変身します。macOSもmacOSインストーラも実機と同様にそのまま起動できるという理想を追ったブートローダーだったのですが、調整やアップデートのたびにBIOS更新作業をするのは大変でした。ChameleonやCloverみたいにドライブの一部に書き込む方式の方が色々楽です。ということでOZMOSISはあまり流行りませんでした。開発チームもそれを認識して、今度はClover方式のブートローダーを作ることにしたのだと思われます。

使用したハードウェア

OpenCoreを試したハードウェアは、以下で紹介したZ390マシンです。モデルIDはiMac19,1で、macOS Mojave 10.14.5です。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ここで使っているkextは

AppleALC.kext
IntelMausiEthernet.kext
Lilu.kext
USBInjectAll.kext
VirtualSMC.kext
WhateverGreen.kext

です。efiファイルは大半がClover 5018で配布されているものです。

ApfsDriverLoader.efi
AptioMemoryFix.efi (これはKext Updater.appで入手)
FSInject.efi
VirtualSmc.efi （VirtualSMC.kextに同梱されているもの）
VBoxHfs.efi
EmuVariableUefi.efi

またUSBInjectAll.kextで使うためのSSDTファイルも使っています。こちらで作成したものです。これがSSDT-UIAC.amlという名前です。

OpenCoreを入手する方法

いろいろな方法がありますが、一番お手軽なのは最近のKext Updater.appを使う方法です。Kext UpdaterもOpenCoreを作っている人たちが活躍しているHackintosh-Forum.deで作られていますので、その関係でOpenCoreダウンロード機能が実装されているのだと思います。Load Bootloaderのラジオボタンを選択して、右のポップアップメニューからOpenCoreを選択します。

ダウンロードすると、Kext-Updatesフォルダの中にOpenCoreというフォルダができて、この中にデバッグ版とリリース版

OpenCore-0.0.4-DEBUG
OpenCore-0.0.4-RELEASE

のフォルダが出来ています。今回はRELEASE版を使ってみましたが、DEBUG版の方がより多くのエラーメッセージを出してくれるらしいです。

ESPディレクトリ構築

Docsフォルダの中には、とても詳しい取扱説明書が入っています。Cloverにはあまりなくて、ネット上のマニュアルも古かったりします。説明書を一緒に配布してくれているのは助かります。まだちゃんと読んでませんが、必要な情報は全部書いてあるのではないかと思います。マニュアルによると、構築すべきディレクトリ構造は以下の通りのようです。

グレーの項目は任意の項目です。なので、EFIの下に、BOOTとOCを作って、OCの中のDriversにefiファイルを、Kextsにkextファイルを入れれば良いようです。またOCの中にconfig.plistを置きます。名前がOCになっただけで、CloverのESP配置とだいたい同じです。この図に従ってESPの中にディレクトリを用意し、DriversフォルダとKextsフォルダに上記のefiファイルとkextファイルを入れました。またACPIフォルダにSSDT-UIAC.amlを入れました。

config.plist編集

Docsフォルダの中に、マニュアルと一緒にconfig.plistのサンプルファイルも入っています。名前が、Sample.plistとなっています。今回はこのファイルをもとに動かしてみました。まずはSample.plistをconfig.plistに名称変更します。そして以下の手順で書き変えました。

SMBIOS設定

まずは機種設定からです。どうやらPlatformInfoの中のGenericの中が機種設定関連のようです。この部分のMLBがCloverでのBoardSerialNumberに対応し、SystemProductNameがProductNameに、SystemUUIDがSmUUIDに対応するようです。それぞれの値を書いておきます。

	<key>MLB</key>
	<string>C02921130GULNV9JA</string>
	
	<key>SystemProductName</key>
	<string>iMac19,1</string>

	<key>SystemSerialNumber</key>
	<string>C02YR2YHJV3Q</string>

	<key>SystemUUID</key>
	<string>E45005B4-95C7-4B0C-9739-30947DDEB37C</string>

FileVault設定

この状態で起動させようとしたところ、FileVaultの用意ができていないというような内容のメッセージが出て起動が中断しました。config.plistを見ると、MiscSecurityの中にFileVaultらしい設定があり、有効にされているようです。ここのtrueの部分2箇所をfalseに書き換えました。これでメッセージが出なくなりました。

<key>Security</key>
	<dict>
		<key>ExposeSensitiveData</key>
		<integer>2</integer>
		<key>HaltLevel</key>
		<integer>2147483648</integer>
		<key>RequireSignature</key>
		<false/>
		<key>RequireVault</key>
		<false/>
		<key>ScanPolicy</key>
		<integer>983299</integer>
	</dict>

efi設定

次に、HFSPlus.efiが見つからないというメッセージで起動が中断されました。最近はAPFSになって、HFS+での起動は使わないので、上記のリストのようにCloverデフォルトのVBoxHfs.efiを使っていました。なんでこのメッセージが出るのかと思ったらconfig.plistのUEFIDriversの中にefiファイルの一覧が書いてありました。フォルダに入れるだけでなくconfig.plistにも書いておくようです。FileVaultに関係したefiファイルも入っています。これらのリストを、実際に使っているefiファイルに書き換えました。

<key>UEFI</key>
<dict>

	<key>Drivers</key>
	<array>
		<string>VBoxHfs.efi</string>
		<string>ApfsDriverLoader.efi</string>
		<string>EmuVariableUefi.efi</string>
		<string>FSInject.efi</string>
		<string>AptioMemoryFix.efi</string>
		<string>VirtualSmc.efi</string>
	</array>

kext設定

ほかも見てみると、KernelAddの場所に、kextに関する記載もあります。この記述順にロードされるようなので順番も大事なようです。

IntelMausiEthernet.kextの名前が違っている（IntelMausi.kextになっている）のとEnabledされていないようなので、修正しました。

<dict>
	<key>BundlePath</key>
	<string>IntelMausiEthernet.kext</string>
	<key>Comment</key>
	<string></string>
	<key>Enabled</key>
	<true/>
	<key>ExecutablePath</key>
	<string>Contents/MacOS/IntelMausiEthernet</string>
	<key>MatchKernel</key>
	<string></string>
	<key>PlistPath</key>
	<string>Contents/Info.plist</string>
</dict>

また、USBInjectAll.kextの記述も追加しました。順番が大事のようです。arrayの最初の方に入れたら動きません。arrayの最後に追加しました。

 <dict>
 <key>BundlePath</key>
 <string>USBInjectAll.kext</string>
 <key>Comment</key>
 <string></string>
 <key>Enabled</key>
 <true/>
 <key>ExecutablePath</key>
 <string>Contents/MacOS/USBInjectAll</string>
 <key>MatchKernel</key>
 <string></string>
 <key>PlistPath</key>
 <string>Contents/Info.plist</string>
 </dict>

SSDT設定

使用するSSDTもconfig.plistで指定する必要があるようです。今回は、SSDT-UIAC.amlを使います。そこで、ACPIAddのarrayの中に、

 <dict>
 <key>Comment</key>
 <string>USB list for USBInjectAll</string>
 <key>Enabled</key>
 <true/>
 <key>Path</key>
 <string>SSDT-UIAC.aml</string>
 </dict>

を追加しました。

動作確認

BIOSでOpenCoreをインストールしたドライブを選択すると、Cloverと同様に起動ボリュームの選択画面が出ます。テキストだけのシンプルな画面です。ここで10.14.5の入ったMacintosh HDを選択しました（この例ではキーボードの5を押す）。この後、設定に不備があると上記のようなエラーメッセージが出ることもありますし、起動が停止することもあります。

でも、ここまでの設定で、なんと起動しました。config.plistで手付かずの項目がいっぱいあるのに、とりあえず起動したのは意外でした。よかったです。

使用したconfig.plistを以下においておきます。

OpenCore config.plist for Z390 - Pastebin.com

動くこと

画面が出て動作します。Radeon RX 580が正しく動きます。IntelMausiEthernet.kextも動きます。なのでLAN接続ができます。またBroadcomの純正WiFiも動きます。

USBInjectAll.kextと自作のSSDTの組み合わせで、USBの取捨選択ができています。15個制限問題を解決できています。

動かないこと

シャットダウンすると画面は消え、シャットダウンプロセスが実行されるのですが、電源が切れるところまで行き着きません。電源スイッチを長押しして強制的にoffにする必要があります。その影響で次の起動の時にBIOS表示で警告が出ます。ACPI関係の設定が足りないのだと思います。

OpenCoreに行くべきか？

ということで、OpenCoreでの起動を確認できました。今後は、USBの指定方法や、今回見た以外のconfig.plistの設定など、マニュアルや検索して調べて見たいと思います。

ではCloverをやめてOpenCoreに移行すべきでしょうか。OpenCoreの人たちは、以下のようなメリットを訴えています。

完全にオープンソースなので安心
設計が新しい

確かにCloverは開発過程がそれほどオープンになっていないので、わかりにくいところがあるかと思います。ロシアで開発されているCloverとドイツで開発されているOpenCoreでは、偏見かもしれませんが、なんとなくOpenCoreに安心感を感じます。開発がオープンなのでHackintoshの主流がOpenCoreに移行していく可能性は高いです。でも今現在では、Cloverに関するノウハウが大量にネットにありますし、しばらくはCloverが使われると思います。

主流ブートローダーは、数年前にChameleonからCloverに交代しました。ただ、この交代では、レガシーなMBR (マスターブートレコード)からESPに対応すること、起動時に動的にパッチを当ててくれる機能、macOSとの相性が良くなることなど、いくつもメリットがありました。CloverからOpenCoreに変えても、目に見えるメリットはないので、移行は緩やかかもしれません。CloverからOpenCoreに移行したらグラフィックスカードの動作が安定したと言う情報も見かけました。今後どうなるにしても、選択肢が複数あることは良いことです。

Macシリアル番号の仕組み

Sun, 24 Mar 2019 12:52:47 +0900

Hackintoshを作る時には、機種IDやシリアル番号などのいくつかのIDを決める必要があります。今回はシリアル番号とボードシリアル番号の文字・数値の意味を説明します。以下の、シリアル番号自動生成ツールの資料とソースコードを参考にしました。

GitHub - acidanthera/macserial: Decode mac serial number

Hackintoshに必要な番号

HackintoshがMacとして機能するためには、機種ID、様々なシリアル番号、ファームウェアバージョンなどを決めておく必要があります。これらはconfig.plistのSMBIOSセクションに記述されます。Clover configuratorを使うと、Macの機種を指定するだけでSMBIOSに書くべき内容を自動的に作成してくれます。しかし、最近のバージョンのCloverでは、SMBIOSのほとんどの内容を自動的に設定してくれますので、この機能に任せた方が間違いが無くて良いです。またBIOSバージョンなどの数値は、本来ならばmacOSインストーラがファームウェアアップデートすると更新される数値なので、Cloverが決めてくれる最新値を使う方が良いです。Cloverに任せておけば、間違いのない最新の数値を設定してくれます。

その一方で、手作業で設定した方が良い番号もあります。以下の設定です。

 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>xxxxxxxxxxxxx</string>
 <key>ProductName</key>
 <string>Macmini8,1</string>
 <key>SerialNumber</key>
 <string>xxxxxxxxxxxx</string>
 <key>SmUUID</key>
 <string>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</string>
 </dict>

ProductNameは、機種IDに相当します。一般には、ハードウェア構成（特にCPUの種類）が一番近いMacの機種IDを設定するのが良いです。SmUUIDは、ターミナルから何度かuuidgenとタイプして得られる32桁の適当な数値を設定しておきます。一部のソフトウェアではインストール台数制限のチェックにも使っているようです。一度決めたら変えない方が良いです。

SerialNumberはMacのシリアル番号です。本物のMacでは筐体に刻印されています。また、BoardSerialNumberはロジックボード（Apple社はマザーボードをロジックボードと呼びます）のシリアル番号です。ロジックボードに刻印されていることがあります。普通にMacを使っている限り、どちらの番号もずっと同じものですが、Macを修理してロジックボードを交換するとBoardSerialNumberは違うものになる可能性があります。

SerialNumberとBoardSerialNumberはとても重要です。これが正しい値に設定されていない場合、iMessageやApp Storeなどが正しく機能しない場合があります。2014年8月から2015年2月にかけて、iMessageでのシリアル番号チェックが非常に厳しくなった時期がありました。これをきっかけにシリアル番号のリバースエンジニアリングが進みました。

シリアル番号

Macのシリアル番号には11桁のものと12桁のものがあります。古い機種は11桁で、最近の機種では12桁です。それぞれの桁は、以下のような意味があります。

| Type | Location | Year | Week | Line | Platform |
| --------- | --------- | ---- | ---- | ---- | -------- |
| Old (11) | LL | Y | WW | SSS | PPP |
| New (12) | LLL | Y | W | SSS | PPPP |

以下では、以下のiMac15,1のシリアル番号の例（12桁）を使って説明します。

C02PJTYNFY10

製造場所番号(2 or 3桁)

最初の3桁 C02は製造国、製造都市、メーカなどを表します。C02は中国のQuantaコンピュータが製造したという意味だそうです。他に判明している3桁コードは以下です。

 - C02, China (Quanta Computer)
 - C07, China (Quanta Computer)
 - C17, China
 - C1M, China
 - C2V, China
 - CK2, Ireland (Cork)
 - D25, Unknown
 - F5K, USA (Flextronics)
 - W80, Unknown
 - W88, Unknown
 - W89, Unknown
 - CMV, Unknown
 - YM0, China (Hon Hai/Foxconn)
 - DGK, Unknown

ちなみに11桁シリアル番号では製造場所コードは2桁です。以下の意味だそうです。

 - CK, Ireland (Cork)
 - CY, Korea
 - FC, USA (Fountain, Colorado)
 - G8, USA
 - QP, USA
 - XA, USA (ElkGrove/Sacramento, California)
 - XB, USA (ElkGrove/Sacramento, California)
 - PT, Korea
 - QT, Taiwan (Quanta Computer)
 - UV, Taiwan
 - RN, Mexico
 - RM, Refurbished Model
 - SG, Singapore
 - W8, China (Shanghai)
 - YM, China
 - H0, Unknown
 - C0, China (Quanta Computer, Tech-Com)
 - C3, China (Shenzhen, Foxconn)
 - C7, China (Shanghai, Pegatron)
 - MB, Malaysia
 - EE, Taiwan
 - VM, Czech Republic (Pardubice, Foxconn)
 - 1C, China
 - 4H, China
 - MQ, China
 - WQ, China
 - 7J, China (Hon Hai/Foxconn)
 - FK, China (Zhengzhou, Foxconn)
 - F1, China (Zhengzhou, Foxconn)
 - F2, China (Zhengzhou, Foxconn)
 - F7, China
 - DL, China (Foxconn)
 - DM, China (Foxconn)
 - 73, Unknown

RMは整備品であることを表しています。

製造年(1桁)

例に示したシリアル番号の、次の一桁であるPは製造年を表します。12桁のシリアル番号では各年号に英字が割り当てられています。ペアの最初の英字が1-6月で、後半が7-12月を表しているそうです。なので、Pは2015年前半を表します。アルファベットのうち英字のI, Oなどが抜けているのは1や0と間違えやすいからだと思われます。他の欠番も何か理由があってのことと思います。

| Pair | Year |
| -------- | ---- |
| `C`, `D` | 2010 |
| `F`, `G` | 2011 |
| `H`, `J` | 2012 |
| `K`, `L` | 2013 |
| `M`, `N` | 2014 |
| `P`, `Q` | 2015 |
| `R`, `S` | 2016 |
| `T`, `V` | 2017 |
| `W`, `X` | 2018 |
| `Y`, `Z` | 2019 |

追記 : 上記の方式では2020にコードを使い切ることになります。実際にどうなったかというと、iMacの2020年モデルでは、こちらで紹介したように、CとDが使われています。2010のコードを再利用しているようです。(2020/8/14)

11桁シリアル番号では、製造年は西暦一桁めの数値です。

| Char | Year |
| ---- | ---- |
| `3` | 2003 |
| `4` | 2004 |
| `5` | 2005 |
| `6` | 2006 |
| `7` | 2007 |
| `8` | 2008 |
| `9` | 2009 |
| `0` | 2010 |
| `1` | 2011 |
| `2` | 2012 |

こちらは2012年に一巡して破綻してます。現行のシリアル番号も2020年以降の年番号がどうなるのか心配です。

製造週(2 or 1桁)

例に示したシリアル番号の、次の一桁であるJは製造週を表します。これは1月1日から始まる7日を最初の週としています。なので最後の週以外は全て7日間です。次の27種類の英数字が使われます。シリアル番号の例では、2015年の前半年とわかりましたので、Jは15週目を表しています。

| Char | 1st half | 2nd half |
| ---- | -------- | -------- |
| `1` | `1` | `27` |
| `2` | `2` | `28` |
| `3` | `3` | `29` |
| `4` | `4` | `30` |
| `5` | `5` | `31` |
| `6` | `6` | `32` |
| `7` | `7` | `33` |
| `8` | `8` | `34` |
| `9` | `9` | `35` |
| `C` | `10` | `36` |
| `D` | `11` | `37` |
| `F` | `12` | `38` |
| `G` | `13` | `39` |
| `H` | `14` | `40` |
| `J` | `15` | `41` |
| `K` | `16` | `42` |
| `L` | `17` | `43` |
| `M` | `18` | `44` |
| `N` | `19` | `45` |
| `P` | `20` | `46` |
| `Q` | `21` | `47` |
| `R` | `22` | `48` |
| `T` | `23` | `49` |
| `V` | `24` | `50` |
| `W` | `25` | `51` |
| `X` | `26` | `52` |
| `Y` | `-` | `53` |

11桁のシリアル番号では週は2桁で表記されて、週の数値がそのまま、00から53までの数値で表現されます。

製造ライン(3桁)

例に示したシリアル番号の、次の3桁であるTYNは製造ラインもしくは、組み立て担当者のIDを表していると考えられています。それぞれの桁は、IとOを除く0からZまでの英数字を0から33に割り当てた数値を表しています。この3桁は、製品個体ごとに違い、一台一台を特定する部分です。

| Char | Value | Char | Value |
| ---- | ----- | ---- | ----- |
| `0` | `0` | `H` | `17` |
| `1` | `1` | `J` | `18` |
| `2` | `2` | `K` | `19` |
| `3` | `3` | `L` | `20` |
| `4` | `4` | `M` | `21` |
| `5` | `5` | `N` | `22` |
| `6` | `6` | `P` | `23` |
| `7` | `7` | `Q` | `24` |
| `8` | `8` | `R` | `25` |
| `9` | `9` | `S` | `26` |
| `A` | `10` | `T` | `27` |
| `B` | `11` | `U` | `28` |
| `C` | `12` | `V` | `29` |
| `D` | `13` | `W` | `30` |
| `E` | `14` | `X` | `31` |
| `F` | `15` | `Y` | `32` |
| `G` | `16` | `Z` | `33` |

この3桁の値は次の式でIDに変換されているようです。

1桁目 x 68 + 2桁目 x 34 + 3桁目

この例のTYNは、それぞれ27, 32, 22を表し、上の式から2,946になります。

27 x 68 + 32 x 34 + 22 = 2,946

製造コピー

上の計算式はちょっと変わっています。34進数だと考えたら最初の桁は34×34倍すべきなのですが、68倍になっています。何か根拠のある計算式ではあると思われますが、この計算では、得られる数値に重複が発生します。

例えば、 0L0, 1J0, 2G0, 3E0, …, 920という複数の英数字が、どれも680という製造ライン番号になります。別の例では、KYL, LWL, MUL, …, Z4Lという英数字は、どれも2400という数字になります。同じ数値になってしまう英数字の組を、製造コピーと呼んでいます。最初の桁の値の小さい方から1, 2, 3,…と番号をつけます。この例では、0L0やKYLがコピー1、1J0やLWLがコピー2などです。920と74Lは、最後のコピーです。英数字の組み合わせによりコピーの総数は変わります。色々な実験で、最初のいくつかのコピーだけが、Appleから有効だと判定されるようです。無効だと判定されたコピー番号より大きな番号のコピーは全て無効になります。Apple内部のことはもちろんわかりませんが、一つのラインから製品が製造されるごとに、コピー値が増加するのではないかと推定されています。何れにしても、ある値を示す製造ライン番号のうち、最初のコピーを使用するのが安全であると言えます。

プラットホームモデル(3 or 4桁)

11桁シリアルでは最後の3桁、12桁シリアルでは最後の4桁が、製品種類を表す番号です。例に示したシリアル番号では、最後の4桁であるFY10がこのプラットホームモデルです。この4桁が製品機種を表していることは、以下のURLにアクセスすることで確認できます。

http://support-sp.apple.com/sp/index?page=cpuspec&cc=PPPP

ここのPPPPの部分にFY10を入れてアクセスすると

http://support-sp.apple.com/sp/index?page=cpuspec&cc=FY10

iMac15,1の仕様書ページにリダイレクトされます。iMac15,1にはLate 2014とMid 2015の2機種がありますが、このモデルはMid 2015年のiMacであることがわかります。

ちなみに一つの機種ID（例えばiMac15,1）が全て同じプラットホームモデル（ここではFY10）になるわけではありません。同じ機種IDでも製造時期が違うと仕様が異なります。それで複数のプラットフォームモデルが割り当てられています。例えば、iMac15,1に相当するプラットホームモデルは、以下の27種類が確認されています。

"FY10", "FY11", "FY14", "FY68", "FY6F", "GCTM", "GDQY", "GDR3", "GDR4", "GDR5", "GDR6", "GDR7", "GDR8", "GDR9", "GDRC", "GFFQ", "GJDM", "GJDN", "GJDP", "GJDQ", "FY13", "FY6D", "GL1Q", "GL1R", "GL1T", "GL1V", "GL1W"

シリアル番号の注意事項

シリアル番号は上記のフォーマットに従って、適切な値が入っている必要があります。そうしないと、iMessageへのアクセスなどでAppleから無効なモデルと判定される可能性があります。

また、細かい整合性もチェックしておいた方が良いと思われます。例えば、製造年、製造週は、プラットホームモデルが示す発売日より後の日付である方が良いでしょう。また、製造ラインのコピー数は、できるだけ小さい値、できればコピー1である方が安全です。

上の例で示したC02PJTYNFY10は、

Country: C02 - China (Quanta Computer)
Year: P - 2015 (前半)
Week: J - 15 (2015年4月9日-2015年4月15日)
Line: TYN - 2946 (copy 1)
Model: FY10 - iMac15,1 Retina 5K, 27 inch, Mid 2015, 2015年5月発売

となります。製造日が発売日より早いのが気になりますが、発売日に備えて前もって製造しているはずなので、それほど不自然ではないと思います。

また、下記のサイトで生成したシリアル番号が未使用であることは、確認しておくべきかと思います。「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。

ボードシリアル番号

SMBIOSでもう一つ設定しないといけない番号がボードシリアル番号です。12桁シリアル番号の場合、ボードシリアル番号は17桁です。ロジックボードのシリアル番号です。修理によってロジックボードは交換される可能性があることもあり、Appleはそれほど厳密にはチェックしていないと感じています。昔のガイドでは、12桁のシリアル番号に適当な英数字を5個足しておけば良いとか、LANのMACアドレスの一部を足しておけば良いなどというゆるい手法が説明されていることもあります。

Clover configuratorなどに搭載されている最近のシリアル番号発生機能では、シリアル番号と対になってボードシリアル番号も作り出してくれます。それを採用しておけば良いです。例えば、先の例で使用したシリアル番号C02PJTYNFY10と対で生成されたボードシリアル番号は

C02514701CDG2Y71H

でした。これを例に構成を調べていきます。

製造場所番号(3桁)

シリアル番号と同じで、最初の3桁は製造国、製造都市、メーカなどを表します。この例のC02は中国のQuantaコンピュータです。

製造年(1桁)

4桁目は年号です。西暦年号の1の位です。この例では、シリアル番号が2015年なので、それに合わせて5になっているようです。

製造週(2桁)

次の2桁は製造週です。上の例では、14週目の製造という意味です。シリアル番号は15週目でした。ロジックボードが製造されたあとで、本体が製造されるのが自然ですから、前の週に製造されたことにしているのだと思います。

MLBBlock1(3桁)

以下のいずれか一つの数値です。Clover configuratorやmacserialが自動生成する場合には、この中から乱数で選んでいるようです。

"200", "600", "403", "404", "405", "303", "108", "207", "609", "501", "306", "102", "701", "301", "501", "101", "300", "130", "100", "270", "310", "902", "104", "401", "902", "500", "700", "802"

MLBBlock2(2桁)

以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。

"GU", "4N", "J9", "QX", "OP", "CD", "GU"

ボードコード(3 or 4桁)

ロジックボードの種類を示す英数字です。一つのモデルに対して多数のコードが発見されているようです。例えば、上の例のiMac15,1では、以下のコードが使われているようです。このリストのうち、最初のコードG2Y7が、問題が少ないとされているので、これが使われることが多いようです。

"G2Y7", "G2Y8", "GG3L", "GG3N", "G2QD", "G2QF", "GG3T", "GG3W", "FT04", "FW6K", "GG3K", "GG3M", "FW29", "FW2C", "GG3Q", "GG3V", "FQY8", "FTPF"

MLBBlock3(2桁)

以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。

"1H", "1M", "AD", "1F", "A8", "UE", "JA", "JC", "8C", "CB", "FB"

ボードシリアル番号の注意事項

上記で、「自動生成する場合には乱数で選んでいる」と書きましたが、生成プログラムのソースを見ると、チェックサムも考慮しています。ボードシリアル番号が表す値を、最初から奇数番目の桁はそのまま、偶数番目の桁は3倍して足していき、その合計が34の倍数である場合は正しいチェックサムを持ったボードシリアル番号としているようです。正しいチェックサムになるまで、ランダムに候補を選んでいるようです。手作業では面倒なので、自動生成ツールを使うのが良いです。

機種のシリアル番号に比べて、ボードシリアル番号はAppleにより厳しく検査されることはないので割と適当でも大丈夫な印象があります。シリアル番号の製造週より前の製造週にしておいた方が良いでしょう。自動生成ツールでは、シリアル番号の前の週になるように生成しているようです。ただ、ロジックボード交換修理する可能性も考えると、それもチェックされていないと思います。何れにしても、以下の自動生成ツールを使えば、整合性のある番号を生成してくれますので問題ありません。

シリアル番号自動生成ツール

シリアル番号はClover configuratorでも生成できますし、この記事の冒頭で示したmacserialというツールでも生成できます。おそらくはClover configuratorもmacserialと同じアルゴリズムを使っているのではないかと思います。macserialは、冒頭のリンクからソースコードを入手してコンパイルしても良いです。また以下のサイトで、コンパイル済みのコードも配布されています。

Releases · acidanthera/macserial

更新：現在は以下で配布されているようです (2019/12/28)。

Releases · acidanthera/MacInfoPkg

更新2 : 現在はOpenCoreに含まれています (2020/8/14)。

GitHub - acidanthera/OpenCorePkg: OpenCore bootloader

現時点では2.0.4が最新のようです。mac版とwindows 32版があるようです。zipをダウンロードすると解凍されてmacserialというファイルができます。

$ ./macserial

として起動すると、現在のMac/Hackintoshのシリアル番号などの情報が表示されます。–helpとすれば使い方の説明が表示されます。

$ ./macserial --help
./macserial arguments:
 --help (-h) show this help
 --version (-v) show program version
 --deriv <serial> (-d) generate all derivative serials
 --generate (-g) generate serial for current model
 --generate-all (-a) generate serial for all models
 --info <serial> (-i) decode serial information
 --list (-l) list known mac models
 --mlb <serial> generate MLB based on serial
 --sys (-s) get system info

Tuning options:
 --model <model> (-m) mac model used for generation
 --num <num> (-n) number of generated pairs
 --year <year> (-y) year used for generation
 --week <week> (-w) week used for generation
 --country <loc> (-c) country location used for generation
 --copy <copy> (-o) production copy index
 --line <line> (-e) production line
 --platform <ppp> (-p) platform code used for generation

–generateオプションで現在モデルのシリアル番号とボードシリアル番号を複数生成してくれます。–generate-allで全てのモデルの番号を生成します。–model Macmini8,1などとすれば特定のモデルの番号を生成してくれます。–info シリアル番号でそのシリアル番号を分析してくれます。例えば、この記事で例に使ったC02PJTYNFY10でしたら、

$ ./macserial --info C02PJTYNFY10
 Country: C02 - China (Quanta Computer)
 Year: P - 2015
 Week: J - 15 (09.04.2015-15.04.2015)
 Line: TYN - 2946 (copy 1)
 Model: FY10 - iMac15,1
 Valid: Possibly

のように表示されます。

光学ドライブを使う

Mon, 11 Sep 2017 13:57:04 +0900

現行のMacintoshからはすっかり駆逐されてしまった光学ドライブですが、Hackintoshなら5.25インチベイ搭載ケースを使っていくらでも復活できます。CD-ROMでもDVDでもokです。実機にはついぞ搭載されなかったBlu-rayドライブも搭載可能です。1台だけでなく2台3台と搭載することだって可能です。読み出すだけじゃなくて書き込むこともできます。搭載するに当たって、特に難しいことはありません。SATAケーブルと電源を配線するだけです。

「可能な場合でもハードディスクをスリープさせない」

簡単、かんたん、a piece of cakeだと思っていたら、「空のdvdがセットされました」というメッセージが出て、操作不能になることがあります。Pioneerのドライブで発生するような気がします。

一部の光学ドライブは、スリープコマンドを送りつけて動作を止めると、次にアクセスした時に復帰できないようです。にもかかわらず、macOSの省エネルギー設定では、「可能な場合はハードディスクをスリープさせる」ことがデフォルト設定になってます。これがトラブルの原因です。なので、この問題は、「システム環境設定」の「可能な場合はハードディスクをスリープさせる」のチェックを外すことで解決します。

カーネル拡張(kext)にパッチを当てる

上記の方法だと、当然ですがハードディスクはスリープしなくなります。また、私は経験したことがありませんが、この方法でも解決しないという報告もあるようです。そこで正攻法で根本的解決方法、つまりシステムにパッチを当てる方法を紹介します。

アップル社は対策済み

アップル社もこの問題はよ〜く分かっていて、旧型Mac Proに搭載されているPioneerの光学ドライブに対して対策をしています。PioneerSuperDrive.kextの中で、Pioneerの光学ドライブの型番を指定して、このドライブだけはスリープさせないようにという設定がされているようです。その型番とは、

DVD-RW DVR-105

です。この対策を担当しているkextは、PioneerSuperDrive.kextです。試しに、

/System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/PioneerSuperDrive.kext/Contents/PlugIns/PioneerSuperDrive.kext/Contents/MacOS/PioneerSuperDrive

をhexdump -Cしてみると、

00000fb0  70 6c 65 5f 64 72 69 76  65 72 5f 50 69 6f 6e 65  |ple_driver_Pione|

00000fc0  65 72 53 75 70 65 72 44  72 69 76 65 00 44 56 44  |erSuperDrive.DVD|

00000fd0  2d 52 57 20 20 44 56 52  2d 31 30 34 00 31 2e 31  |-RW  DVR-104.1.1|

00000fe0  30 00 44 56 44 2d 52 57  20 20 44 56 52 2d 31 30  |0.DVD-RW  DVR-10|

00000ff0  35 00 4e 6f 20 53 6c 65  65 70 00 54 72 75 65 00  |5.No Sleep.True.|

と書いてあります。DVD-RW DVR-105をNo Sleepにするって書いてあるように見えます。DVR-104も対策済みみたいにも見えます。運良く、これらの型番のドライブをHackintoshに搭載した人は、きっとこの問題に遭遇しないのでしょう。そうでない人は、ファイルに書かれた型番を、実際に使っているドライブの型番に書き換えればよいわけです。

光学ドライブの型番を知る

光学ドライブの型番は、「リンゴマーク」「このMacについて」「システムレポート（システム情報）」「ハードウェア」「SATA/SATA Express」とだどっていけば、見つかります。手元の例ではPIONEERという表記を除いて、

BD-RW   BDR-205

でした。スペースの数（3個あります）も重要で、全部で15文字のはずです。

Cloverのconfig.plistでパッチを当てる

古代の手法では、 PioneerSuperDrive.kextの該当ファイルをバイナリーエディタで開いて、データを書き換えていました。これは色々問題があります。特に、OSのバージョンアップのたびに同じことをやらなければならないのが面倒です。現代風の方法では、Cloverの動的パッチ機能を使います。起動するタイミングでパッチを当ててくれる機能です。

設定ファイルconfig.plistにパッチ情報を書き込むのですが、この時、バイナリーデータを文字に対応させて変換するBase64という方式を使います。Base64への変換は、ターミナルのbase64コマンドで可能です。例えば、DVD-RW DVR-105（スペースは2個）とBD-RW BDR-205（スペースは3個）の文字列をBase64に変換するには、ターミナルで以下のようにタイプすれば良いです。

$ echo -n "DVD-RW DVR-105" | base64
RFZELVJXICBEVlItMTA1
$ echo -n "BD-RW BDR-205" | base64
QkQtUlcgICBCRFItMjA1

変換前後の文字列のBase64表記がわかりましたので、いよいよconfig.plistを開いて、KextsToPatchセクションに以下を追加します。

 <key>KextsToPatch</key>
 <array>
 <dict>
         <key>Comment</key>
         <string>PioneerBD-RW No Sleep</string>
         <key>Find</key>
         <data>RFZELVJXICBEVlItMTA1</data>
         <key>Name</key>
         <string>PioneerSuperDrive</string>
         <key>Replace</key>
         <data>QkQtUlcgICBCRFItMjA1</data>
 </dict>
 </array>

なんとなくわかると思いますが、PioneerSuperDrive.kextの、RFZELVJXICBEVlItMTA1というデータを検索して、QkQtUlcgICBCRFItMjA1に置き換えてくださいという指示です。これでめでたくスリープ問題が根本的に解決されるはずです。

OpenCoreのconfig.plistでパッチを当てる

OpenCoreでも同様に、config.pistの指定で動的にパッチ当てが可能です。以下にその方法を紹介しておきました。

Pioneer光学ドライブのパッチをOpenCoreに適用する

キーボードから開閉したい

ご存知のようにアップルの純正キーボードには光学ドライブをイジェクトするキーがついています。今風のMacintoshでは使いようのない無駄なキーですが、光学ドライブを搭載したHackintoshなら有効に使ってあげられます。と、思ったら、これが効かないこともありました。

解決策がこちら、

www.tonymacx86.com

で紹介されています。AHCI_3rdParty_SATA.kextに手を加えて使用する方法です。日本語で紹介された解説が、こちらにあります。