[{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.63GBです。OCLPでパッチを当てているので、フルサイズになっているようです。\nOCLPを外すと、678.2MBになりました。アップデートの内容は、セキュリティ修正のようです。\nアップデートする 「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。ビルド番号は24G90でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.6から15.6.1にアップデートしました。今まで通り、安定して動作しています。\n","date":"2025-08-26T13:37:01+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22606/","title":"macOS Sequoia 15.6.1 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.63GBです。OCLPでパッチを当てているので、フルサイズになっています。\nOCLPを外すと、1.43GBになりました。アップデートの内容は、バグとか脆弱性への対応のようです。\nアップデートする 「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24G84でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.5から15.6にアップデートしました。今まで通り、安定して動作しています。\n","date":"2025-08-07T21:58:53+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22593/","title":"macOS Sequoia 15.6 に更新"},{"content":"OpenCoreの1.0.5が公開 (2025年7月7日) されていたので1.0.4からアップデートしました。config.plistに追加された項目はありませんでしたので、1.0.4 のconfig.plistそのままでも動きます。\n1.0.5をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\n大きな変更は無いようですが、\nFixed kext injection compatibility issues with macOS 26 という項目があるので、macOS Tahoeに少し対応したのかもしれません。\nOpenCore 1.0.5とmacOS Sequoiaで動作確認していた手元のマシンは以下です。\nASRock 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 がアップデートされてましたので、これも最新にしました。\nEFIのバックアップを取る 何かあって起動しなくなると大変ですから、EFIのバックアップをとっておきます。EFIフォルダをどこかにコピーしておけば良いだけの簡単な作業です。Kext Updaterには、EFI Backupというボタンがありますからこれを押すと ~/Documents/EFI-Backup/EFI_Backup_2024.12.13-19-17.zipというような名前でバックアップしてくれるので、さらに簡単です。ただ、起動しなくなった場合に、このファイルにアクセスできる手段は用意しておく必要があります。通常はAPFSなので、EFIシェルやWindowsからはアクセスできません。\n起動しなくなった場合に即座に対応したいならば、FAT32でフォーマットしたUSBメモリに、EFIという名前のフォルダを作り、起動に使っているEFIファイル類をコピーしておくと良いです。BIOSからこのUSBメモリを指定すれば、アップデート前と同様に起動します。私の場合は、iCloudでDocuments以下を同期してあるので、他のMacからすぐに読み出せます。\n.efiファイルを差し替える 更新するために、今までと同様に、X64/EFIフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nBOOT/BOOTX64.efi OC/OpenCore.efi OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。 OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。 ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作ります。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n今回追加された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2025-08-07T20:13:25+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/22586/","title":"OpenCore 1.0.4 から1.0.5に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.62GBです。OCLPでパッチを当てているので、フルサイズになっています。\nOCLPを外すと、1.53GBになりました。Apple Intelligenceが売りのようです。でも、Apple IntelligenceはIntel Macでは動かないので、Hackintoshでも使えません。\nアップデートする 「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24F74でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.4.1から15.5にアップデートしました。今まで通り、安定して動作しています。\nApple Intelligenceには未対応でした。 例えば、Apple Silicon搭載MacだとインストールされるImage Playground.app（AIによる画像生成を試すアプリ）は、インストールされませんでした。Apple Intelligenceを使うためには、Apple Silicon搭載Macに買い換える必要があります。\n","date":"2025-05-26T01:37:09+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22521/","title":"macOS Sequoia 15.5 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.58GBです。OCLPでパッチを当てているので、フルサイズになっています。\nOCLPを外すと、842.1MBになりました。脆弱性に対応したセキュリティアップデートのようです。\nアップデートする 「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24E263でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.4から15.4.1にアップデートしました。今まで通り、安定して動作しています。\n","date":"2025-04-23T12:15:18+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22509/","title":"macOS Sequoia 15.4.1 に更新"},{"content":"OpenCoreの1.0.4が公開 (2025年3月4日) されていたので1.0.3からアップデートしました。config.plistに追加された項目は1件だけですが、デフォルトで対応しました。なので1.0.3 のconfig.plistそのままでも動きます。\n1.0.4をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 1.0.4とmacOS Sequoiaで動作確認していた手元のマシンは以下です。\nASRock Z690 Steel Legend + 13900K Radeon RX 6600 XT macOS Sequoia 15.4 OpenCore Legacy Patcher 2.3.2 (WiFi対応のため) 今回のタイミングでAppleALC.kext, VirtualSMC.kextがアップデートされてましたので、これも最新にしました。\nEFIのバックアップを取る 何かあって起動しなくなると大変ですから、EFIのバックアップをとっておきます。EFIフォルダをどこかにコピーしておけば良いだけの簡単な作業です。Kext Updaterには、EFI Backupというボタンがありますからこれを押すと ~/Documents/EFI-Backup/EFI_Backup_2024.12.13-19-17.zipというような名前でバックアップしてくれるので、さらに簡単です。ただ、起動しなくなった場合に、このファイルにアクセスできる手段は用意しておく必要があります。通常はAPFSなので、EFIシェルやWindowsからはアクセスできません。\n起動しなくなった場合に即座に対応したいならば、FAT32でフォーマットしたUSBメモリに、EFIという名前のフォルダを作り、起動に使っているEFIファイル類をコピーしておくと良いです。BIOSからこのUSBメモリを指定すれば、アップデート前と同様に起動します。私の場合は、iCloudでDocuments以下を同期してあるので、他のMacからすぐに読み出せます。\n.efiファイルを差し替える 更新するために、今までと同様に、X64/EFIフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nBOOT/BOOTX64.efi OC/OpenCore.efi OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。 OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。 ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作ります。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n今回追加された項目は、以下でした。\nBooter/Quirksに、ClearTaskSwitchBit が追加されました。古いmacOSで32bitカーネルが動作する場合に必要な機能らしいです。古いmacOSは使ってないので、デフォルトのまま、falseにしておきました。 デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動すると思います。\n","date":"2025-04-12T21:53:08+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/22502/","title":"OpenCore 1.0.3 から1.0.4に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.58GBです。OCLPでパッチを当てているので、フルサイズになっています。\nOCLPを外すと、3.34GBになりました。写真でメモリー動画が作れるようになったようです。AIでメール仕分けするとか、いろいろ便利になりそうです。\nアップデートする 「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ログインしようとすると、今までのアップデートとは違って、「次回から自動ダウンロードします」とか、「ようこそMacへ」などの画面が出ましたが、そのあとは、普通通りログインします。\nビルド番号は24E248でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.3.2から15.4にアップデートしました。今まで通り、安定して動作しています。\n","date":"2025-04-01T22:53:51+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22488/","title":"macOS Sequoia 15.4 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.22GBです。OCLPでパッチを当てているので、フルサイズになっています。そのせいか、説明もSequoiaが公開されたメジャーアップデートの時の内容になってます。\nOCLPを外すと、642.9MBになりました。アップデート内容は、セキュリティアップデートのようです。\nアップデートする 「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D81でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.3.1から15.3.2にアップデートしました。今まで通り、安定して動作しています。\n","date":"2025-03-12T19:27:05+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22473/","title":"macOS Sequoia 15.3.2 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.22GBです。OCLPでパッチを当てているので、フルサイズになっています。そのせいか、説明もSequoiaが公開されたメジャーアップデートの時の内容になってます。\nOCLPを外すと、640MBになりました。アップデート内容は、セキュリティアップデートのようです。\nアップデートする 「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D70でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.3から15.3.1にアップデートしました。今まで通り、安定して動作しています。\n","date":"2025-02-21T17:53:59+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22450/","title":"macOS Sequoia 15.3.1 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.22GBです。OCLPでパッチを当てているので、フルサイズになっています。そのせいか、説明もSequoiaが公開されたメジャーアップデートの時の内容になってます。\nOCLPを外すと、1.39GBになりました。説明は、前回のアップデートからの差分の内容になりました。15.3では、計算機に機能が追加されたようです。もちろん、これだけでなく、多数のアップデートがされているはずと思います。\nアップデートする 「今すぐアップデート」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24D60でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\n新機能を試す アップデート内容に、「“計算機”で、等号をもう一度クリックすると、最後の数式の演算を繰り返すことができます」という項目がありましたので、試してみました。計算機を開いて、100×1.05=を計算します。\n100×1.05=を入力\n100万円を年利5%の定期預金に預けた1年後の預金額、の計算です。結果は105万円です。ここで=キーをさらに押したところ、最後のx1.05=の演算が繰り返されました。=キーを全部で10回押せば、複利計算されて、10年後の預金額、162.889万円になります。\n100×1.05==========を入力\nちなみに、バージョン15.2の計算機では、=を複数回押しても、結果は変化しませんでした。\nまとめ macOS Sequoia 15.2から15.3にアップデートしました。今まで通り、安定して動作しています。\n","date":"2025-02-05T14:44:54+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22425/","title":"macOS Sequoia 15.3 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ15.25GBです。OCLPでパッチを当てているので、フルサイズになっています。説明もSequoiaが公開されたメジャーアップデートの時の内容になってます。\nOCLPを外すと、2.17GBになりました。説明は、前回のマイナーアップデートからの差分の内容になりました。15.2では、写真とSafariなどに機能が追加されたようです。\n更新する 「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24C101でした。\nOCLPを復活 この後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\n新機能を試す 天気 アップデート内容に、「メニューバーに“天気”を追加すると、現在の気象状況をMacのメニューバーで確認したり、クリックして詳しい天気予報に素早くアクセスしたりできます」という項目がありましたので、試してみました。「アップルマーク」「システム設定」「コントロールセンター・メニューバーのみ」の天気を「メニューバーに表示」にします。デフォルトは非表示でした。これで、以下のように、メニューバーから天気を確認できます。\n株価 「“株価”の時間外（立会時間前）の株価で、市場が開く前にNASDAQとNYSEの銘柄を追跡できます」という機能も追加されたので確認しました。以下は、15.1.1での株価（上）と、15.2での株価（下）のスクショです。\n日本時間で18時過ぎのスクショなので、NASDAQは立会時間前取引の時刻です。日本時間早朝に終了した立会時間取引の終値に加えて、立会前価格が実時間で表示されるようになりました。グラフ部分は、立会時間内の価格グラフだけで、今までと変わりません。\nまとめ macOS Sequoia 15.1.1から15.2にアップデートしました。今まで通り、安定して動作しています。\n","date":"2024-12-13T19:15:10+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22399/","title":"macOS Sequoia 15.2 に更新"},{"content":"OpenCoreの1.0.3が公開 (2024年12月4日) されていたので1.0.2からアップデートしました。config.plistに追加された項目はありません。なので1.0.2 のconfig.plistそのままでも動きます。\n1.0.3をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 1.0.3とmacOS Sequoiaで動作確認していた手元のマシンは以下です。\nASRock 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がアップデートされてましたので、これも最新にしました。\nEFIのバックアップを取る 何かあって起動しなくなると大変ですから、EFIのバックアップをとっておきます。EFIフォルダをどこかにコピーしておけば良いだけの簡単な作業です。Kext Updaterには、EFI Backupというボタンがありますからこれを押すと ~/Documents/EFI-Backup/EFI_Backup_2024.12.13-19-17.zipというような名前でバックアップしてくれるので、さらに簡単です。ただ、起動しなくなった場合に、このファイルにアクセスできる手段は用意しておく必要があります。通常はAPFSなので、EFIシェルやWindowsからはアクセスできません。\n起動しなくなった場合に即座に対応したいならば、FAT32でフォーマットしたUSBメモリに、EFIという名前のフォルダを作り、起動に使っているEFIファイル類をコピーしておくと良いです。BIOSからこのUSBメモリを指定すれば、アップデート前と同様に起動します。\n.efiファイルを差し替える 更新するために、今までと同様に、X64/EFIフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nBOOT/BOOTX64.efi OC/OpenCore.efi OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。 OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。 ACPIとKextsは、OpenCoreのアップデートには含まれないので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作ります。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n今回追加された項目はありませんでした。古いconfig.plistのままでも、変更なしで起動すると思います。\n","date":"2024-12-13T16:31:40+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/22394/","title":"OpenCore 1.0.2 から1.0.3に更新"},{"content":"OpenCoreの1.0.2が公開 (2024年10月9日) されていたので1.0.1からアップデートしました。config.plistに追加された項目は1点だけで、デフォルトのままで問題ありません。なので1.0.1 のconfig.plistそのままでも動きます。\n1.0.2をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 1.0.2とmacOS Sequoiaで動作確認していた手元のマシンは以下です。\nASRock 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がアップデートされてましたので、これも最新にしました。\n.efiファイルを差し替える 更新するために、今までと同様に、X64/EFIフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nBOOT/BOOTX64.efi OC/OpenCore.efi OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。 OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n今回追加された項目は、以下でした。\nUEFI/ReservedMemoryに、Unload が追加されました。array型の情報で、初期値は空です。すでに存在するファームウェアドライバをアンロードする項目とのことです。デフォルトのまま、空にしておきました。 大きな変更はありませんので、古いconfig.plistのままでも、変更なしで起動すると思います。\n","date":"2024-11-27T22:09:42+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/22380/","title":"OpenCore 1.0.1 から1.0.2に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。セキュリティアップデートとのことなので、機能は変わらないと思われます。\nサイズは、macOSの本体とほぼ同じ14.53GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、651.1MBになりました。\n「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24B91でした。\nこの後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.1から15.1.1にアップデートしました。今まで通り、安定して動作しています。\n","date":"2024-11-22T23:51:53+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22367/","title":"macOS Sequoia 15.1.1 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。iPhoneミラーリングでドラッグ\u0026amp;ドロップが可能になったようです。iPhoneミラーリングは、セキュリティチップのないHackintoshでは使えない機能ですが、実機のMacで使うととても便利です。\nサイズは、macOSの本体とほぼ同じ14.53GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、1.883GBになりました。「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24B83でした。\nこの後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.0.1から15.1にアップデートしました。今まで通り、安定して動作しています。\n","date":"2024-10-29T17:58:55+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22344/","title":"macOS Sequoia 15.1 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。アップデート項目が多数列挙されていますが、Sequoiaになっての新機能がまだ表示されているだけのようです。今回の更新目的は、バグ修正なので機能の変更は無いものと思われます。\nSoftware Update\nサイズは、macOSの本体とほぼ同じ14.45GBです。OCLPでパッチを当てているので、フルサイズになっています。OCLPを外すと、774.8MBになりました。「今すぐ再起動」を選択すると、すぐにダウンロード開始し、その後再起動しました。\nDownload\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は24A348でした。\nAbout This Mac\nこの後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、Wi-Fiが復活しました。\nまとめ macOS Sequoia 15.0から15.0.1にアップデートしました。今まで通り、安定して動作しています。\n","date":"2024-10-05T20:22:15+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22321/","title":"macOS Sequoia 15.0.1 に更新"},{"content":"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の機能はあるかと思いますが、基本的に問題なく動作します。\nOpenCoreの設定 OpenCoreの設定は、Sonomaを動かしていた時と同様で、全く変更していません。Wi-Fiに関する設定については、こちらをご覧ください。\nSonomaでBroadcom Wi-Fiを有効にする\n以下の作業で使ったOpenCoreの設定 (EFIのファイル類) を、こちらに置いておきました。参考になさってください。（シリアル番号などは適当に書いてありますのでこちらを参考にしてconfig.plistを書き換えてください）\nSequoiaインストーラを入手 macOSインストーラーを入手するために、ベータ版の時と同様にsoftwareupdateコマンドを使いました。Sequoia対応のMacのターミナルで、以下のコマンドを入力すると、Sequoiaがダウンロード可能なことがわかります。ちなみに、Sonomaの方も14.7が配布されているようでした。\n% 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をダウンロードできました。公開日当日で混んでいるためか、時間がかかりました。\n% 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というインストーラが出来上がってました。\nmacOS Sequoia Installer\nクリーンインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、Intel 13900KF、AMD Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.1です。このコンピュータには、以下の２個のSSD（他にも多数接続してます）が接続されてます。\nMacintosh 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をフォーマットして、クリーンインストールすることにしました。\nちなみに、ユーザー用のディレクトリは、homeと名付けた別のボリュームに入れてます。システムだけがMacintosh HDに入っているので、これだけを消去しました。EFIもユーザデータも無事なはずです。\nHDD構成\n次に、Sequoia Beta 8で起動している状態で、先のInstall macOS インストール.appを開きます。\nmacOS Sequoia Installer\n続けるボタンを押して、消去したばかりのMacintosh HDボリュームをインストール先に選択しました。これでクリーンインストールができるはずです。\nインストールの準備が終わると、再起動を促す表示が現れます。この先2-3回ほど再起動し、最初はmacOS Installerというボリュームから起動し、次回以降はMacintosh HDから起動しました。EFIボリュームに残したOpenCoreは正しく機能していたようです。\n動作確認 この後、無事Sequoiaが起動して、通常通り使用できました。\nAbout This Mac\nユーザディレクトリを、元のhomeボリュームに戻したので、データも全部引き継がれました。実用的に使えてますので、Sonomaから完全移行することにします。\nOCLPは2.0.1になってましたので、これでBroadcomのWi-Fi設定をしました。Wi-Fiも接続可能になりました。\nOCLP 2.0.1\nSequoiaの目玉機能の一つだったiPhoneミラーリングは、動作しませんでした。iPhoneとBluetoothで接続できて、コード認証の画面までは進むのですが、その後、Wi-Fiで接続する段階で動作しなくなりました。T2チップ、もしくはApple Siliconが必要らしく、今後も無理そうです。\niPhone mirroring\nまとめ macOS 15.0 Sequoiaが公開されたので、ASRock Z690 Steel Legendで自作したPCにインストールしました。Sonomaの時に使用していたのと同じOpenCore設定で動作しました。EFIファイル類は以下で公開してますので、参考になさってください。\nSequoia\nT2チップを利用した一部機能は動作しませんが、実用的には問題なく使用できてます。\n","date":"2024-09-17T15:29:37+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22262/","title":"macOS Sequoia を自作PCにインストール"},{"content":"OpenCore Legacy Patcher (OCLP)の 2.0.0がリリースされました。Sequoiaのベータ版にインストールしたところ、SequoiaでもBroadcomのWi-Fiが使えることを確認しました。\nSonoma以降で使えなくなったBroadcomのWi-Fiは、OpenCore Legacy Patcher (OCLP) を使うと復活できます。詳細は以下の記事をご覧ください。\nSonomaでBroadcom Wi-Fiを有効にする\nOCLPがSequoiaに対応 SonomaのWi-Fi対応のために使っているOCLPから、アップデートの案内が出てました。Ver. 2.0.0になって、Sequoiaに対応したようです。\nOpenCore Legacy Patcher update\nそこで早速試してみることにします。\nSequoiaベータ版にインストール ここからは、Sequoiaベータ版を起動して進めました。ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600を以下の設定で使ってます。\nmacOS Sequoia 15 Beta 8をインストール\nSequoiaベータ版は、メインで使っているSSDとは別のSSDにインストールしてあります。コンピュータのUEFIの起動は、SonomaがインストールされたメインのSSDで行い、OpenCoreの起動ボリューム選択で、Sequoia SSDを起動します。なので、OpenCoreの設定やkext類はSonomaを動かしている状態のままです。\n次に、OCLPリリースページから、2.0.0をダウンロードします。\nhttps://github.com/dortania/OpenCore-Legacy-Patcher/releases\nここから、OpenCore-Patcher.pkgをダウンロードしました。pkgファイルを開くと、インストーラが起動します。\nOCLPインストーラ\nインストール終了すると、アプリケーションフォルダの中にOCLPアプリができているので起動します。\nOCLP 2.0.0\nここで、Post-Install Root Patchを選ぶと、Wi-Fi関係のパッチを当てられます。\nPost-Install Root Patch\n再起動するとWi-Fiが使えるようになってました。\nWi-Fi\nまとめ OCLPがアップデートされて2.0.0になり、Sequoiaに対応しました。そこでSequoiaベータ版で、動作を確認しました。OCLPを起動してボタンを押すだけでWi-Fiが動作するようになりました。SonomaとSequoiaの差は少ないようで、同じOpenCore設定で問題なく動作してます。OCLPのおかげでWi-Fiも動くようになったので、Sequoiaリリース日には、すぐに移行しようと考えてます。\n","date":"2024-09-15T13:15:05+09:00","image":"/uploads/2023/09/lc05.png","permalink":"/posts/22247/","title":"OpenCore Legacy PatcherがSequoiaに対応"},{"content":"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の機能はあるかと思いますが、基本的に動作します。\nBeta 8インストーラを入手 今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Betaを選ぶとBeta 6が、Developer Betaを選ぶとBeta 8がダウンロードできるようになります。\nScreenshot\nsoftwareupdateコマンドで確認すると、どちらを選んでもビルド番号は24A5331bで、同じもののようです。以下では単にBeta 8と書くことにします。\n% 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をダウンロードできました。\n% 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というインストーラが出来上がってました。\nScreenshot\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.1で、macOS 14.6.1で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。\nInstaller\nこの後は、通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。\nこのSSDには、前回インストールしたBeta版が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。\nインストールの準備が終わると、再起動を促す表示が現れます。\nRestart Your Mac\nこの先3回再起動し、最初はmacOS Installerというボリュームから起動し、次回以降はインストール先に指定したボリュームから起動しました。\n動作確認 この先、無事にmacOS Sequoiaが動作しました。前回同様、Radeon RX 6600のDP端子にも画像が出ました。日本語変換のインラインインタフェースも前回同様に正常動作しました。\nAbout This Mac\nこれは仕方ないことですが、WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。\nWiFi\nまとめ macOS Sequoia Developer Beta 8を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。\n","date":"2024-08-30T14:25:42+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22215/","title":"macOS Sequoia 15 Beta 8をインストール"},{"content":"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の機能はあるかと思いますが、基本的に動作します。\nBeta 7インストーラを入手 今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Betaを選ぶとBeta 5が、Developer Betaを選ぶとBeta 7がダウンロードできるようになります。\nScreenshot: Download Beta\nsoftwareupdateコマンドで確認すると、どちらを選んでもビルド番号は24A5327aで、同じもののようです。以下では単にBeta 7と書くことにします。\n% 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をダウンロードできました。\n% 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というインストーラが出来上がってました。\nScreenshot\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.1で、macOS 14.6.1で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。\nInstaller\nこの後は、通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。\nこのSSDには、前回インストールしたBeta 6が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。\nインストールの準備が終わると、再起動を促す表示が現れます。\nRestart Your Mac\nこの先、2回再起動し、いずれもmacOS Installerというボリュームから起動しました。\n動作確認 DPから映像が出る この先、無事にmacOS Sequoiaが動作しました。今回から、Radeon RX 6600のDP端子に画像が出るようになりました！今までのようにHDMI端子に切り替える必要はありませんでした。\nScreenshot\nインラインでの日本語変換 日本語変換のインタフェースにも進展がありました。今までは、メモアプリなどの一部のアプリでしかインラインでの変換ができませんでした。Safariで文章を入力すると、確定するまで表示されない状態でした。これが改善されて、正常に日本語入力できるようになりました。\nそのほか これは仕方ないことですが、WiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。\nWiFi\nまとめ macOS Sequoia Developer Beta 7を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。ディスプレイポートからの映像出力ができるようになり、日本語入力のインタフェースも完璧になりました。使い込んでいないので、動作しない機能があるのかもしれませんが、すぐに移行しても問題ない気もします。\n","date":"2024-08-24T18:02:30+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22201/","title":"macOS Sequoia 15 Beta 7をインストール"},{"content":"OpenCoreの1.0.1が公開されていたので1.0.0からアップデートしました。config.plistに追加された項目はありません。なので1.0.0 のconfig.plistそのままでも動きます。\n1.0.1をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。Sequoia対応に関しても記述はありませんが、手元の環境ではSequoiaベータ版が問題なく起動できているので、大きな問題は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 1.0.1とmacOS Sonomaで動作確認していた手元のマシンは以下です。\nASRock 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がアップデートされてましたので、これも最新にしました。\n.efiファイルを差し替える 更新するために、今までと同様に、X64/EFIフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nBOOT/BOOTX64.efi OC/OpenCore.efi OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiでした。 OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiでした。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n比較した結果、新たにsample.plistに追加された項目はありませんでした。なので、今まで動作していたのであれば、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2024-08-22T11:50:56+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/22197/","title":"OpenCore 1.0.0 から1.0.1に更新"},{"content":"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の機能はあるかと思いますが、基本的に動作します。\nBeta 6インストーラを入手 今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると、アップデートが表示されます。Public Beta, Developer Beta, 15.1 Developer Betaの選択肢がありますが、どれを選んでも、この先でダウンロードされるベータ版は同じでした。\nScreenshot: Download Beta\n今回はPublic Betaを選んでみたところ、macOS Sequoia 15 Beta 5というアップデートが現れました。\nScreenshot: Public Beta 5\nDeveloper Betaを選ぶと、今度はmacOS Sequoia 15 Beta 7というアップデートが現れます。でもsoftwareupdateで調べたところ、どちらも同じビルド番号24A5320aでした。\n% 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と書くことにします。\nsoftwareupdateコマンドでVersion 15.0を指定すると、Beta 6をダウンロードできます。\n% 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というインストーラが出来上がってました。どういうわけかアプリ名が英語に戻ってました。\nScreenshot\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.6.1で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。これも英語表示に戻りました。\nInstaller\nこの後は、通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。\nこのSSDには、前回インストールしたBeta 4が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.6.1が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。\nインストールの準備が終わると、再起動を促す表示（これも英語に戻りました）が現れます。\nRestart Your Mac\nこの先、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。\n動作確認 この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況は今までのBeta版と同じでした。HDMI端子には映像が出ます。デフォルトの壁紙が、セコイアの森に変わってました。\nAbout This Mac\nWiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。\nWiFi\nまとめ macOS Sequoia Developer Beta 6を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。壁紙がセコイアの森に変更されていました。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。\n","date":"2024-08-22T10:49:44+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22172/","title":"macOS Sequoia 15 Beta 6をインストール"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.64GBです。\nScreenshot: software update\n「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23G93でした。\nScreenshot: About This Mac\nこの後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、無事Wi-Fiが復活しました。\nまとめ macOS Sonoma 14.6から14.6.1にアップデートしました。今まで通り、安定して動作しています。\n","date":"2024-08-20T21:43:36+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/22167/","title":"macOS Sonoma 14.6.1 に更新"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.64GBです。\nUpdate 14.6\n「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23G80でした。\nAbout this Mac.\nこの後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、無事Wi-Fiが復活しました。\nまとめ macOS Sonoma 14.5から14.6にアップデートしました。今まで通り、安定して動作しています。\n","date":"2024-08-03T23:14:28+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/22125/","title":"macOS Sonoma 14.6 に更新"},{"content":"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の機能はあるかと思いますが、基本的に動作します。\nBeta 4インストーラを入手 今回もsoftwareupdateコマンドを使いました。まずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておきます。今まではDeveloper Betaの項目しかありませんでしたが、今回はPublic Betaの項目も現れていました。どちらを選ぶと良いかわからなかったので、最初は新しく現れたPublic Betaを選んでみました。\nすると、macOS Sequoia 15 Beta 2というアップデートが現れます。これはPublic Beta 2という意味のようです。\nPublic Beta 2\n次に今までと同じDeveloper Betaを選んでみると、macOS Sequoia 15 Beta 4が現れます。これはDeveloper Beta 4という意味のようです。\nDeveloper Beta 4\nそれぞれのバージョンを、softwareupdateで調べたところ、どちらも同じビルド番号24A5298hでした。Public Beta 2とDeveloper Beta 4は同じもののようです。ややこしいので、ここでは単にBeta 4として紹介します。\n% 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を指定すると、これをダウンロードできます。\n% 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です。\nインストーラー\n今までは、名称がInstall macOS Sequoia Beta.appだったものが、日本語になりました。だんだん日本語対応が進んでいるようです。\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のmacOS Sequoiaベータ版インストール.appを開くと、インストーラウィンドウが現れました。今までは英語表示でしたが、これも日本語に変わってました。\nインストーラー\nこの後は、通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。ここの表示も日本語化されていました。\nインストーラ\nこのSSDには、前回インストールしたBeta 3が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。\n再起動の案内も日本語化されてました。\ninstaller\nこの先、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。\n動作確認 この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況はBeta 1と3と同じでした。HDMI端子には映像が出ます。\nAbout this Mac\nWiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。\nまとめ macOS Sequoia Beta 4を動かして、OpenCoreの最新版で動作することを確認しました。今回も、Sonomaを起動しているOpenCore設定と全く同じ設定で、動作しました。日本語表示される部分が増えて、日本語対応が進んでいる様子です。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。\n","date":"2024-07-29T12:51:03+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22082/","title":"macOS Sequoia 15 Beta 4をインストール"},{"content":"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の機能はあるかと思いますが、基本的に動作します。\nBeta 3インストーラを入手 今回も、Beta 1と同様に、最初は以下のサイトのお世話になりました。\nmacOS Sequoia Full Installer Database. Download Directly from Apple!\nここには、https://swcdn.apple.com/というアップルのサイトのダウンロード用URLが紹介されています。ここにBeta 3インストーラへのリンクがありました。ダウンロードすると、InstallAssistant.pkgというファイルが出来上がります。\nこれを開きインストールすると、Install macOS Sequoia Beta.appというアプリが、「アプリケーション」の中に作られます。\nフォーラムで教えていただいた内容によると、ターミナルからsoftwareupdateコマンドを使ってダウンロードすることも可能のようです。これも試してみました。\nまずは、「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておきます。\nScreenshot\n次に、ターミナルからsoftwareupdate --list-full-installersコマンドを打ち、ベータ版がダウンロード可能なことを確認します。\n% 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コマンドで、バージョンを指定してダウンロードします。\n% softwareupdate --fetch-full-installer --full-installer-version 15.0 Scanning for 15.0 installer Install finished successfully この結果、アプリケーションフォルダにインストーラがダウンロードされました。\nSequoiaアイコン登場 「アプリケーション」の中に作られた、Install macOS Sequoia Beta.appのサイズは14.5GBと、Beta 1から少しだけ増えてました。何よりもアイコンが新しくなってます。Sequoiaのアイコンが決定したのかと思います。\nBeta 3\n「パッケージの内容」を見ると、\nBeta 3\nContents/Resources の中に、ProductPageIcon.icnsというファイルが見つかりました。\nSequoia Icon file\nこれがSequoiaのアイコンのようです。これをプレビュー.appで開くと、複数サイズのアイコンPNGデータを得ることができます。アイコンのデザインはSonomaの方が凝っていて良かった気もします・・・\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のInstall macOS Sequoia Beta.appを開くと、インストーラウィンドウが現れました。\nインストーラを開くと、あとは通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。\nこのSSDには、前回インストールしたBeta 1が入ってます。上書きインストールになります。このSSDのESP (EFI System Partition) 部分にはOpenCoreは入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。\nインストールでは、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。\n動作確認 この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。Radeon RX 6600のDP端子に画像が出ない状況はBeta 1の時と同じでした。HDMI端子には映像が出ます。\nOpenCoreの最新版があれば、Sequoiaも問題ないようです。\nWiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。\nまとめ macOS SequoiaのBeta 3を動かして、OpenCoreの最新版で動作することを確認しました。アイコンが、Sequoiaのものに更新されました。Sonomaを起動しているOpenCore設定と全く同じ設定で、動作します。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調のようです。\n","date":"2024-07-15T14:10:08+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22036/","title":"macOS Sequoia 15 Beta 3をインストール"},{"content":"macOS Sequoia（セコイア）15.0 をhackintoshで使う上で有用と思われる情報をメモしておきます。\n機種設定 Sequoiaの対応Intel Macの機種IDは以下です。\niMac19,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でもサポートされるようです。\nダウンロード方法 いろいろあります。\n「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にすると入手できます。（下図。自動的にアップデート開始するので非推奨） https://developer.apple.com/macos/ からもダウンロード可能です。（Apple Silicon版のみらしいので非推奨） こちらのサイトで、ダウンロード用URLが紹介されています。このURLは、https://swcdn.apple.com/ というサーバーで、Apple公式ソフトウェアアップデートが使うサイトのようです。（簡単だけどダウンロード時間がかかる） 記事のコメントから、Mistというツールを教えていただきました。各種macOSをダウンロードして、インストーラを作るユーティリティです。次の項目の方法をGUI画面で自動化しているのだと思われます。 ターミナルからsoftwareupdateコマンドを使います。「システム環境」「一般」「ソフトウェアアップデート」でベータアップデートを有効にしておき（下図）、 softwareupdate --list-full-installers コマンドで目当てのベータ版がダウンロード可能なことを確認し、それが15.0ならば、\nsoftwareupdate --fetch-full-installer --full-installer-version 15.0 コマンドでダウンロードできます。アプリケーションフォルダにインストーラが作られます。\nBroadcom WiFi対策 Sonomaと同様、BroadcomのWi-Fi (BCM94360NG など) はサポートされません。そこでOCLPが必要です。OCLP 2.0.0からSequoiaに対応したので、これを使ってWi-Fiを有効化します。\nOpenCore Legacy PatcherがSequoiaに対応\n動作報告 以下はSequoiaの動作記録です。ASRock Z690 Steel Legend、Intel 13900KF、AMD Radeon RX 6600、OpenCore 1.0.1、OCLP 2.0.1で動作してます。\nmacOS Sequoia を自作PCにインストール\nEFIファイル類 ここで使ったOpenCoreの設定 (EFIのファイル類) を、こちらに置いておきました。参考になさってください。（シリアル番号などは適当に書いてありますのでこちらを参考にしてconfig.plistを書き換えてください）\nリリースの経緯 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 配布開始 ","date":"2024-06-11T23:50:44+09:00","image":"/uploads/2024/07/sequoia512.png","permalink":"/posts/22003/","title":"Sequoia"},{"content":"2024/06/10のWWDC24キーノートでmacOS Sequoiaが発表され、ベータ版が無償公開されました。さっそく自作PCにインストールして動作することを確認しました。マシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、kext類は最新です。OpenCoreの設定は、Sonomaを起動している設定と全く同じです。使用できないSequoiaの機能はあるかと思いますが、基本的に動作するようで安心しました。\nベータ版インストーラを入手 開発ベータ版は無償で配布されています。開発ベータ版を入手するための方法はいくつかありますが、一番簡単なのは、「システム設定…」「一般」「ソフトウェアアップデート」で、「ベータアップデート」から「macOS Sequoia Developer Beta」を選択することです。\nすると、ベータアップデートにmacOS Sequoia Developer Betaの項目が現れます。\nただ、この方式で続けると、起動中のmacOSをベータ版に入れ替えてアップデートされます。使用中のSSDではなくて、予備のSSDにインストールしたかったので、macOSのインストーラを入手したいと思いました。\nインストーラ単体は、おそらくはdeveloper.apple.comからダウンロードできると思います。ただ、Sonomaの時はIntel用を入手できなかったので、これを試すことなく、前回と同様に、以下のサイトのお世話になりました。\nmacOS Sequoia Full Installer Database. Download Directly from Apple!\nここには、https://swcdn.apple.com/というアップルのサイトのダウンロード用URLが紹介されています。ダウンロードすると、InstallAssistant.pkgというファイルが出来上がります。\nこれを開くと、Install macOS 15 beta.appというアプリが、「アプリケーション」の中に作られます。\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。ブートローダーはOpenCore 1.0.0で、macOS 14.5で動作しています。ここから、先のInstall macOS 15 beta.appを開くと、インストーラウィンドウが現れました。\nアイコンはSonomaの流用です。Sonomaのbetaの時と同様、この後のバージョンアップでSequoiaのアイコンが採用されるはずです。\nインストーラを開くと、あとは通常のmacOSのインストールと同様です。テスト用に250GBの2.5インチSATA SSD（名前はSequoia）を用意しました。これをインストール先にします。\nこのSSDはフォーマットした直後なので、そのESPにOpenCoreなどが入っていません。なので、マザーボードのEFIの起動設定は変更せず、今まで通りの起動SSD（macOS 14.5が入っているSSD）で行いました。なので、OpenCoreの設定や使用kext類などは、Sonomaの場合と全く同じものを使用したことになります。\nインストールでは、3回再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。\n画面が出ない この後、インストールがほぼ終了し、グラフィックスカードに制御が切り替わるタイミングで、画面が真っ黒になりました。しばらく待っていたところボイスオーバーの案内がスピーカーから流れました。音が出るように用意しておくことは重要ですね。画面が出ていないだけで、インストールは成功しているようでした。\n画面が出ない症状は、1年前にSonomaの開発ベータをインストールしたときにも発生していました。なので、同様に試したところ、グラフィックスカードのRadeon RX 6600のHDMI端子には映像が出ているようでした。今まではDP端子を接続していたのですが、そちらはブラックスクリーンになったようです。ということで、ディスプレイをHDMI端子に接続すれば、問題なくmacOSのインストールを進めることができました。\n動作確認 この先、いつも通りのインストール手順で進み、無事にmacOS Sequoiaが動作しました。OpenCoreの最新版があれば、Sequoiaも問題ないようです。\n全コアが動作してます。\nただ、Sonomaの時と同様にWiFiは動いていません。Open Core Legacy Patcher (OCLP)が対応してくれるはずです。現状はまだ未対応なので、今のOCLPをSequoiaで試さない方が良いそうです。\nまとめ macOS Sequoiaの開発ベータ版を動かして、OpenCoreの最新版で動作することを確認しました。Sonomaを起動しているOpenCore設定と全く同じ設定で、動作します。使い込んでいないので、動作しない機能があるのかもしれませんが、とりあえずは新macOS対応が順調に進みそうなので安心しました。\n","date":"2024-06-11T20:00:36+09:00","image":"/uploads/2024/06/installer4.jpg","permalink":"/posts/21982/","title":"macOS Sequoia Beta 1を第13世代Intel CPUで動かす"},{"content":"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を動作させるために使用してます。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。サイズは、macOSの本体とほぼ同じ13.6GBです。\nいつもはアップデートの説明が表示されるのに、今回は白紙でした。「今すぐ再起動」というボタンが表示されていて、すでにダウンロードは終了している様子です。なので今更ダウンロードサイズを節約する必要もなさそうなので、今回はOCLPのパッチを外さないまま続けました。「今すぐ再起動」を選択すると、すぐに再起動して、更新過程が開始しました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23F79でした。\nこの後、OCLPのPost-Install Root Patchを当て直しました。OCLPが自動的に出してくれるダイアログに従って、OKを押してパッチを当てます。\nこの結果、無事Wi-Fiが復活しました。\nまとめ macOS Sonoma 14.4.1から14.5にアップデートしました。今まで通り、安定して動作しています。\n","date":"2024-05-27T01:09:13+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21961/","title":"macOS Sonoma 14.5 に更新"},{"content":"OpenCoreの1.0.0が公開されていたので0.9.9からアップデートしました。config.plistに追加された項目はありません。なので0.9.9 のconfig.plistそのままでも動きます。\n1.0.0をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。とはいえ、バージョンがとうとう1.0.0に到達しました。\nReleases · acidanthera/OpenCorePkg\nOpenCore 1.0.0とmacOS Sonomaで動作確認していた手元のマシンは以下です。\nASRock Z690 Steel Legend + 13900K Radeon RX 6600 XT macOS Sonoma 14.4.1 OpenCore Legacy Patcher 1.4.3 (WiFi対応のため) 今回のタイミングでAppleALC.kextがアップデートされてましたので、これも最新にしました。\n.efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n比較した結果、新たにsample.plistに追加された項目はありませんでした。なので、今まで動作していたのであれば、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2024-05-26T23:37:00+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21957/","title":"OpenCore 0.9.9 から1.0.0に更新"},{"content":"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です。\n追記：初稿ではWi-Fiが不調でしたが、kext入れ替えで復活しました。2024/03/31\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。マイナーな機能拡張と、バグ修正、セキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.6GBです。\n今回も、差分だけのダウンロードをしたいと思い、OCLPのパッチを外しました。OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。なお、OCLPにも新しいバージョン1.4.2が来ていたので、アップデートしました。14.4.1に対応するためには、1.4.2を使ってくださいとのことでした。\nこの後、再起動するとWi-Fiが使えなくなってました。Wi-Fi用パッチを外したので当然の現象です。改めて、更新通知を確認すると、サイズが2.01GBになってました。少し前に話題になっていた、USBハブが認識されない問題が解決されているようです。\nここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23E224でした。\nWi-Fiが復活しない この後、OCLPのPost-Install Root Patchを当て直しました。メッセージには、Modern Wirelessに対応するためのネットワークパッチが当てられると表示されています。\nパッチを当てて、再起動しましたが、しかしながらWi-Fiは動作しませんでした。今までの様子と異なり、メニューバーのWi-Fiアイコンに!マークが出ています。\nちなみに使用しているWi-Fiモジュールは、マザーボードのE key M.2ソケットに取り付けたBCM94360NGです。\nIOSkywalkFamily.kextを更新する そこで、Wi-Fiを有効化した時の手順：\nSonomaでBroadcom Wi-Fiを有効にする\nを見直しました。その結果、追加していた2個のkext：\nIOSkywalkFamily.kext IO80211FamilyLegacy.kext のうち、IOSkywalkFamily.kextが、3週間前に更新されていることがわかりました。Sonoma 14.4のベータに合わせて、更新されていたようです。使用中のkextを、最新のものに置き換えることで、無事、Wi-Fiが復活しました。\nまとめ macOS Sonoma 14.3.1から14.4.1にアップデートしました。Broadcom社のWi-Fiが動作しない問題が発生しましたが、対応するkextを更新したところ解決しました。今まで通り、安定して動作しています。\n","date":"2024-03-30T18:21:00+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21883/","title":"macOS Sonoma 14.4.1 に更新"},{"content":"OpenCoreの0.9.9が公開されていたので0.9.8からアップデートしました。config.plistに追加された項目はありません。なので0.9.8 のconfig.plistそのままでも動きます。\n0.9.9をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。とうとう0.9.9まできました。次はいよいよ1.0.0なのでしょうか？\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.9とmacOS Sonomaで動作確認していた手元のマシンは以下です。\nASRock Z690 Steel Legend + 13900K Radeon RX 6600 XT macOS Sonoma 14.3.1 OpenCore Legacy Patcher 1.4.1 (WiFi対応のため) 今回のタイミングでkextのアップデートはありませんでした。\n.efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n比較した結果、新たにsample.plistに追加された項目はありませんでした。なので、今まで動作していたのであれば、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2024-03-28T11:40:40+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21879/","title":"OpenCore 0.9.8 から0.9.9に更新"},{"content":"macOS Sonoma 14.3.1がリリースされた（2024/2/9）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。\n更新通知が来る 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。詳細情報をクリックしたところ、マイナーな機能拡張と、バグ修正、セキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.37GBです。\n今回も、差分だけのダウンロードをしたいと思い、OCLPのパッチを外しました。OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。\nこの後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが526.5MBになってました。また、アップデートの内容がより具体的に説明されるようになりました。タイプ入力中のテキスト表示の不具合を直したようです。その不具合には遭遇してなかったので、よくわかりません。\nここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23D60でした。\nこの後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。\nまとめ macOS Sonoma 14.3から14.3.1にアップデートしました。今回も、OCLPのパッチを一旦外すことで、差分でのアップデートを行いました。アップデート後に、再びOCLPのパッチを当てました。\n","date":"2024-02-09T22:33:15+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21801/","title":"macOS Sonoma 14.3.1 に更新"},{"content":"OpenCoreの0.9.8が公開されていたので0.9.7からアップデートしました。config.plistに追加された項目はありません。なので0.9.7 のconfig.plistそのままでも動きます。\n0.9.8をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.8とmacOS Sonomaで動作確認していた手元のマシンは以下です。\nASRock 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の時のままです。\n.efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n新たにsample.plistに追加された項目はありませんでした。なので、今まで動作していたのであれば、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2024-02-09T21:33:37+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21794/","title":"OpenCore 0.9.7 から0.9.8に更新"},{"content":"macOS Sonoma 14.3がリリースされた（2024/1/22）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。\n更新通知が来てた 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。詳細情報をクリックしたところ、マイナーな機能拡張と、バグ修正、セキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.37GBです。\n今回も、差分だけのダウンロードをしたいと思い、OCLPのパッチを外しました。OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。\nこの後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが935.9MBになってました。\nここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23D56でした。\nこの後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。\nまとめ macOS Sonoma 14.2.1から14.3にアップデートしました。今回も、OCLPのパッチを一旦外すことで、差分でのアップデートを行いました。アップデート後に、再びOCLPのパッチを当てました。\n","date":"2024-01-23T13:27:51+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21758/","title":"macOS Sonoma 14.3 に更新"},{"content":"macOS Sonoma 14.2.1がリリースされた（2023/12/19）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。\n更新通知が来てた 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.36GBです。\n前回のアップデートの記事のコメントで、アップデートのサイズがフルサイズなのは、パッチが当たっているからなので、OCLPのパッチを外すと差分でアップデートできると教えていただきました。今回はそれを試しました。それで、OCLPで、Revert Root Patchesを選び、パッチを外します。このマシンでは、BroadcomのWi-Fiのパッチが当たっているのですが、それを外すことになります。\nこの後、再起動するとWi-Fiが使えなくなってました。改めて、更新通知を確認すると、サイズが421.8MBになってました。\nここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。\n更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23C71でした。\nこの後、OCLPのPost-Install Root Patchを当て直すことで、BroadcomのWi-Fiが復活しました。\nまとめ macOS Sonoma 14.2から14.2.1にアップデートしました。OCLPでパッチを当てて以来、アップデーターがmacOS本体くらいのサイズだったのですが、パッチを一旦外すことで、差分でのアップデートになりました。再起動1回分の手間がかかりますが、ダウンロード時間が短くなります。今後も一旦パッチを外してからアップデート作業したいと思います。\n","date":"2023-12-21T17:10:58+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21735/","title":"macOS Sonoma 14.2.1 に更新"},{"content":"macOS Sonoma 14.2がリリースされた（2023/12/12）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。\n更新通知が来てた 「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。\n詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ13.36GBです。\nここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23C64でした。\nOCLPを当て直す これでmacOS 14.2が起動しました。でもOCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。\nそこで、OCLPの新しいバージョン1.3.0を起動しました。\nPost-Install Root Patchをクリックしてパッチを当てなおしたところ、Wi-Fiが復活しました。\nまとめ macOS Sonoma 14.1.2から14.2にアップデートしました。アップデート通知画面でボタンクリックすることで、自動的にアップデートできました。またWi-Fiを有効化するために、アップデート後に再びOCLPを当てました。\n","date":"2023-12-12T17:15:31+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21713/","title":"macOS Sonoma 14.2 に更新"},{"content":"OpenCoreの0.9.6が公開されていたので0.9.5からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.5 のconfig.plistそのままでも動きます。\n0.9.6をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.6とmacOS Sonomaで動作確認していた手元のマシンは以下です。\nASRock 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の時のままです。\n.efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n新たにsample.plistに追加された項目は以下です。\nBooter/QuirksにFixupAppleEfiImagesが追加されていました。bool型データで、デフォルトはfalseです。macOS 10.4から10.12のboot.efiへのパッチとのことです。最新macOSしか使わないので、デフォルトのままfalseにしておきました。 今まで動作していたのであれば、追加された項目はデフォルトで問題無いようですので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2023-12-12T17:03:41+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21715/","title":"OpenCore 0.9.5 から0.9.6に更新"},{"content":"macOS Sonoma 14.1.2がリリースされた（2023/11/30）ので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。\n更新通知が来てた 前回、更新通知が来るように設定しましたので、今回は、「システム設定」「一般」「ソフトウェアアップデート」にアップデートの通知が来ました。\n詳細情報をクリックしたところ、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ12.89GBです。\nここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B92でした。\nOCLPを当て直す これでmacOS 14.1.2が起動しました。でもOCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。\nそこで、OCLPからPost-Installを実行したところ、新しいバージョン1.2.1の案内が表示されました。\nDownload and Installボタンをクリックして1.2.1をインストールしました。\nPost-Install Root Patchをクリックしてパッチを当てなおしたところ、Wi-Fiが復活しました。\nまとめ macOS Sonoma 14.1.1から14.1.2にアップデートしました。アップデートの通知画面から、ボタンクリックで自動的にアップデートしてくれました。またWi-Fiを有効化するために、アップデート後に再びOCLPを当てました。\n","date":"2023-12-05T22:35:56+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21691/","title":"macOS Sonoma 14.1.2 に更新"},{"content":"本日（2023/11/8）macOS Sonoma 14.1.1がリリースされたので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。\n更新通知を有効にする macOS Sonoma 14.1.1がリリースされたはずなのですが、Sonomaになって以来、「システム設定」「一般」「ソフトウェアアップデート」に更新の表示が出なくなってました。\nその記事へのコメントで「RestrictEvents.kextを入れてsbvmmを設定すればアップデートが表示されますよ」と教えていただいたのでそれを試しました。RestrictEventsの設定については、こちらをご覧ください。\nRestrictEvents.kextで更新通知を有効化する\nその結果、アップデートの通知が来るようになりました。これで今まで通り、アップデートできそうです。\n詳細情報をクリックしたところ、Sonomaそのものの紹介しか書いてありませんでした。0.0.1のマイナーアップデートなので、バグ修正とセキュリティアップデートが更新内容のようです。サイズは、macOSの本体とほぼ同じ12.89GBです。\nここで、「今すぐアップデート」を選択すると、自動的にダウンロードが開始して、更新されました。更新の過程で、自動的に再起動します。再起動回数は4回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B81でした。\nOCLPを当て直す これでmacOS 14.1.1が起動しました。しかし、OCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。\nそこで、OCLPからPost-Installを実行し、パッチを当て直しました。これでWi-Fiが復活しました。\nまとめ macOS Sonoma 14.1から14.1.1にアップデートしました。RestrictEvents.kextを使ったので、今まで通り「システム設定」にアップデートの通知が来るようになりました。Wi-Fiを有効化するために、アップデート後に再びOCLPを当てました。\n","date":"2023-11-08T17:42:22+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21644/","title":"macOS Sonoma 14.1.1 に更新"},{"content":"RestrictEvents.kextを使って、Sonomaの更新通知が来るように設定しました。またCPU種類が表示されるようにもしました。\nRestrictEvents.kextを導入 Sonomaにしてから、macOSのアップデートの通知が来なくなったという記事を書きました。その記事へのコメントで「RestrictEvents.kextを入れてsbvmmを設定すればアップデートが表示されますよ」と教えていただきました。こちらで公開されているkextです。\nGitHub - acidanthera/RestrictEvents\nその説明によるとRestrictEventsは、ハードウェア互換性を確保するために、不要なプロセスをブロックしたり、機能を復活させるためのkextで、Lilu.kextの機能を利用しているとのことです。これをダウンロードして、EFI/OC/Kextsの中に入れました。また、config.plistのKernel/Addの中に、このkextのことを追記しました。Liluを利用するkextなので、Liluの記述より後に記入します。Xplistで編集した様子を、以下に示します。\n次に、config.plistのNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82/boot-argsに、\nrevpatch=sbvmm,cpuname revcpu=1 を追加しました。このうち、\nrevpatch=sbvmm の部分は、説明によると一部のモデルでネットからの更新を可能にさせる機能とのことです。VMM SBモデルというのが何に相当するのかは、探したものの不明でした。\nまた、以下の部分では、\nrevpatch=cpuname revcpu=1 システム情報でのCPUの表示をカスタマイズします。RestrictEvents.kextの効果は、以下で確認します。\nソフトウェア更新通知が来る Sonomaになってから、ソフトウェア更新の通知が来なくなってました。それが復活しました。リンゴマークのメニューに「アップデート」の表示がされるようになりました。App Storeの更新も復活してます。\nシステム設定を開くと、Sonoma 14.1.1のアップデートが可能になってます。\nCPUの種別が表示される 「このMacについて」や「システム情報」で、CPUの名前が表示されなくなってました。いつ頃からなのか不明なのですが、Macで使われていないCPUを使っているので、仕方ないかと思ってました。これが復活しました。\nターミナルからは、sysctlコマンドでCPU名を取得できていました。\n% sysctl machdep.cpu.brand_string machdep.cpu.brand_string: 13th Gen Intel(R) Core(TM) i9-13900KF この情報が表示されるようになるようです。システム環境設定では、今までは、「プロセッサ名」がUnknownだったものが、\n正しく表示されるようになりました。\n「このMacについて」でも、以下のようにCPU名表示されるようになりました。\nまとめ RestrictEvents.kextを使い、Sonomaのアップデートの通知が来るようにしました。また、CPU種類の表示も復活させました。この他に、RestrictEvents.kextを使うことで、\nMacBookAir と MacBookPro10,xで「システム情報」のメモリータブを表示させる、 MacPro7,1でPCI構成の警告を表示させない、 「初期化されていないディスク」との警告を表示させない、 コンテンツキャッシングを可能にする、 Ivy BridgeでCoreGraphicsがクラッシュする問題を解決する、 などの設定が可能とのことです。\n","date":"2023-11-08T17:06:26+09:00","image":"/uploads/2023/11/a06.jpg","permalink":"/posts/21639/","title":"RestrictEvents.kextで更新通知を有効化する"},{"content":"本日（2023/10/26）macOS Sonoma 14.1がリリースされたので、更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCore、OCLP、kext類は最新です。\nアップデートが来ない macOS Sonoma 14.1がリリースされたのですが、「システム設定」「一般」「ソフトウェアアップデート」に表示はありません。\nSonomaになったためか、それともOCLPでパッチを当てたためなのか、アップデート案内が来なくなってしまったようです。\nOCLPで14.1をダウンロード OCLPには、macOSのダウンロード機能があったのでそれを使うことにしました。OCLPメインメニューの左下のCreate macOS Installerを選びます。\nこの中から、macOS 14.1 Sonomaのダウンロードが可能でした。\n差分ではないので、12.9GBあり、ダウンロードに20分程度かかるようです。\nダウンロードが終わると、Applicationsにインストーラが保存されています。\nこれを開いて、macOSのバージョンアップをしました。\nこの後、自動的に再起動しました。再起動回数は3回で、最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は23B74でした。\nOCLPを当て直す これでmacOS 14.1が起動しました。しかし、OCLPのパッチが当たっていない状態のmacOSなので、BroadcomのWi-Fiが動作しません。\nこの状態は、OCLPにもわかっているようで、再度パッチを当てることを促すメッセージが出ました。\nそこで、パッチを当て直しました。これでWi-Fiが復活しました。\nまとめ macOS Sonoma 14.0から14.1にアップデートしました。OCLPを使って以来初めてのマイナーアップデートなので、今までと少し違ってました。まずは、「システム設定」にアップデートの通知が来なくなってました。またアップデート後に、再びOCLPを当てる必要がありました。それ以外は、今までのマイナーアップデートと同じく、問題なくアップデートできて動作しました。\n","date":"2023-10-26T18:10:22+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21593/","title":"macOS Sonoma 14.1 に更新"},{"content":"前回の記事では、Sonomaになって使えなくなったBroadcomのWi-Fiを、OpenCore Legacy Patcher (OCLP) のNightly Buildを使って対応させました。\nSonomaでBroadcom Wi-Fiを有効にする\nその後、OCLPが更新されてSonomaに正式対応したので、それを使って再びパッチ当てしました。\nOCLPがSonomaに対応 OCLPが Ver. 1.0.0 になってSonomaに対応しました。前回の記事で使用した0.6.9を起動したところ、バージョンアップのお知らせが表示されました。\nこれで正式にSonomaに対応したようです。リリースページからダウンロードできます。\nReleases · dortania/OpenCore-Legacy-Patcher\nDownload and installボタンを押すと更新されました。\n起動すると1.0.0になってます。\nPost-Install Root Patchを選ぶと、前回同様にパッチを当てられます。\nメッセージを見ると、macOSのシステム部分にかなりパッチが当たっています。それだけ大変な作業のようです。\n1.0.1に更新（追記） 2023年10月4日に、OCLPが1.0.1に更新されていました。\nアップデートしてパッチし直しました。特に変化はありません。\nまとめ OCLPの公開版がアップデートされてSonoma対応になりました。Nightly版で、Broadcom Wi-Fi対応のパッチを当てていたので、公開版でパッチし直しました。Config.plistはすでに対応しているので、OCLPを起動してボタンを押すだけで終了します。Wi-Fiを動かし続けるために、これからもOCLPにお世話になります。\n","date":"2023-10-03T16:17:05+09:00","image":"/uploads/2023/09/lc05.png","permalink":"/posts/21563/","title":"OpenCore Legacy PatcherがSonomaに対応"},{"content":"SonomaでBroadcomのWi-Fiを使えるようにしました。iPhoneとのコピペ（ユニバーサルクリップボード）やAirDropが再び使えるようになりました。\nSonomaでWi-Fiが使えない Sonomaでは、マザーボードのM.2ソケットに取り付けたBroadcom Wi-Fiカード\nが動作しませんでした。Bluetooth部分は動作します。これらのBroadcom Wi-Fiを搭載しているMacが全て、Sonomaのサポート対象から外れたためです。Venturaまでは動作し、Sonomaで動作しなくなったチップは以下です。\nBCM94350 (BCM94352を含む) BCM94360 BCM43602 BCM94331 BCM943224 Wi-Fiが使えなくなったマシンは、デスクトップ（Z690マザーボード、13900K、Radeon RX 6600）なので、有線LANがあれば一般的なネット利用には支障ありません。しかしWi-Fiが機能しないと、iPhoneとの連携機能（ユニバーサルクリップボードやHandoffなど）やAirDropが使えないので、なんとかしたいところです。\nOCLPで対応する OpenCore Legacy Patcher（以下ではOCLP）を使用して、Broadcomチップを有効にする方法が以下で説明されていました。\nPreliminary support for macOS Sonoma by khronokernel · Pull Request #1077 · d\u0026hellip;\nOCLPは、新しいmacOSを、サポート対象外の古いMacにインストールするツールです。OpenCoreを利用しています。Macの機種を選択すると自動的に設定してくれるので便利です。Sonomaでサポート外になったBroadcomのWi-Fiを有効にするOCLPが、Nightly Build版で用意されています。公式版は10月2日とのことです。\nこのSonoma対応の最新版OCLPをHackintoshで使います。上記のページの「Hackintosh Note」という項目に説明があります。本来の使い方ではないので、OpenCoreの設定準備が多少必要です。ちなみにOpenCoreも最新版にすると良いとのことなので、Nightly Build 0.9.6にしました。\nOCLPを使ってみる まずは上記のページからOCLPのNightly Buildを入手しました。直接リンクを公開しないようにと書いてありますので、このページから探してください。Nightly.link: OpenCore-Patcher.app (Sonoma Development)と書いてあるリンクをクリックすると、OpenCore-Pacherのアプリがダウンロードされます。10月2日には公開版が出るそうなので、それまで待っても良いと思います。\n実はOCLPを使うのは今回が初めてです。それで、とりあえずダウンロードしたアプリを起動してみました。開いたメインメニューに、いろいろなツールがあって便利そうです。Sonomaのダウンロードも、これを使えばきっと簡単でした。\nこの中の「Post-Install Root Patch」という項目で、Wi-Fiのパッチが当てられます。「Post-Install Root Patch」をクリックすると、以下のメッセージが現れました。\n要するに、\nあなたのマシンに対してできることはModern Wirelessのパッチです でもセキュリティ設定がキツいのでパッチ当てられません ということです。状況をとても的確に把握してくれているようです。Modern Wirelessというのは、今回のSonomaで使えなくなったBroadcomのチップです。OCLPのプロジェクトでは、Montereyで切り捨てられた古いWi-FiチップをLegacy Wirelessと呼んでいたので、それに対してSonomaで切り捨てられたチップをModernと呼んでいるようです。\nOpenCoreの調整 そこで、まずはOpenCoreの設定を整えて、OCLPが動作するようにします。Hackintoshに対して行う先ほどの手順を参考にしました。ちなみに、古いMacに対して行う手順がこちらに説明されています。これも参考にしました。これらに従ってconfigとEFIを調整します。\n1. Kextの追加 まずはkextを追加します。必要なkextは、以下の3個です。うち1個は、他のkext/Contents/PlugInsの中に含まれてますので、入手するkextは2個です。\nIOSkywalkFamily.kext IO80211FamilyLegacy.kext AirPortBrcmNIC.kext (IO80211FamilyLegacyに含まれてます) ちなみに古いMac向けのガイドのほうには、このほかにも3個のkextを入れるように書かれてました。それを試みるとカーネルパニックになったり、暗黒画面になりました。上記の3個だけで良いようです。\n2. config.plistの変更 次に、config.plistを変更します。まずは、上記の3個のkextが動作するように、Kernel/Addに以下を追加します。Xplistアプリで編集している様子です。\n次に、macOSにあるIOSkywalk.kextを停止させます。このために、以下の項目をKernel/Blockに追加します。\nさらに、Misc/Securityで、SecureBootModelを無効にします。\nまた、NVRAM/Addで、boot-argsにamfi=0x80 を追加し、csr-active-configを03080000に設定します。\nNVRAM/Deleteに、csr-active-configを追加します。\nconfig.plistの変更は以上です。csr関係の設定は、パッチ作業後は元に戻しても良いのかもしれません。詳しくはこちらの説明をみてください。\nOCLPを起動 これでOCLPが使えるようになりました。メインメニューからPost-Install Root Patchを選ぶと、先ほどと違って、以下のように表示されます。\nいよいよパッチが当てられるようになったようです。Start Root Patchingを選択すると、rootとして作業するかどうかの確認と、パスワードを求められます。\nパスワードを入力すると、パッチ作業が開始されます。\nパッチが終了したら、再起動です。\nWi-Fi動作を確認する 再起動したところ、無事、Wi-Fiが動作するようになりました。\nWi-Fiを接続したところ、iPhoneとのユニバーサルクリップボード、Handoff、AirDropなどが動作するようになりました。\nまとめ Sonomaになって使えなくなっていたWi-Fiが、OCLPによって復活しました。その結果iPhoneや他のMacとの連携が再び使えるようになりました。macOSのバージョンアップの時にはいろいろ試練がありますが、それを克服しているコミュニティの皆さんの努力に感謝です。\n今回は、M.2 Wi-Fiカード BCM94360NGを使いましたが、も同じ手順で復活するはずです。\n","date":"2023-10-01T22:15:06+09:00","image":"/uploads/2023/09/lc05.png","permalink":"/posts/21501/","title":"SonomaでBroadcom Wi-Fiを有効にする"},{"content":"macOS Sonoma 14.0が公開されましたので、USBインストーラを作って、クリーンインストールしました。最新版のOpenCore (0.9.5) とkext類でVenturaが動く環境ならば、Sonomaが動作するはずです。\nシステム構成 日本時間2023/9/27に、macOS Sonoma 14.0 が配布されました。Venturaが配布されたのは去年の10月25日でしたので、例年より1月ほど早いです。インストール先のマシンは、以下で、Z690マザーボードに13900Kを搭載しています。グラフィックスはRadeon RX 6600です。ブートローダはOpenCore 0.9.5でkext類は最新にしてあります。\nRaptor Lake-S 13900KFの32コアをmacOSで使う\n直近まで使っていたmacOSはVentura 13.5.2 (22G91)です。現在、13.6が配布されていますが、それをスキップして14.0に移行しました。\nアップデートできない Venturaの「システム設定」に「ソフトウェアアップデートがあります」というメッセージが出ていました。これを選択すると、macOS Sonoma 14.0の説明が表示されます。\nここで「今すぐアップデート」を選ぶと、ダウンロードが開始します。でもしばらくすると、以下のようなメッセージが出て中断してしまいます。\nPublic Betaの時と同様な症状です。Public BetaはApple Silicon版との関係でエラーが出ているのかと思ったのですが、他の要因かもしれません。\n裏口からダウンロード それで結局、こちらのサイトのリンク情報からインストーラをダウンロードしました。ダウンロード先はhttps://swcdn.apple.com/というサーバで、Apple公式ソフトウェアアップデートが使うサイトのようです。\nInstallAssistant.pkgというファイルがダウンロードされました。これを開くと、デフォルトで/Applicationsフォルダに、macOSインストーラが出来上がります。\nということで、めでたくmacOS Sonomaインストールを入手できました。\nクリーンインストールする 現用のVenturaに上書きインストールしても良いかとは思いますが、せっかくの年に一度のメジャーアップデートです。現在の起動ディスクであるM.2 SSDの内容を綺麗さっぱりと全消去して、クリーンインストールしようと思います。実は、ホームディレクトリは、同じSSDの別のAPFSボリュームに作ってあるので、起動M.2 SSDを消去してもそれほど面倒なことにはなりません。そこで次の手順でアップデートを進めます。\nUSBメモリを用意して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拡張（ジャーナリング）にしておくのが無難です。\n次に、SonomaインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもSonomaをインストールできるUSBメモリになります。ターミナルを使用して、Sonomaインストーラの中のContents/Resourcesに移動するとcreateinstallmediaというファイルがあります。そこで以下のコマンドを入力します。（下の例は、インストーラが/Applicationsにある場合です）\n$ 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 \u0026#34;/Volumes/Install macOS Sonoma\u0026#34; パスワード入力と、確認のyを押すと、いろいろ進捗して終了します。これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。\n2. USBメモリのESPに現用のESPをコピーする この先の操作でも、稼働しているESPは残るので、それから起動してUSBメモリを起動できるはずです。でも念のためにメモリでも起動できるようにしておきたいと思います。そこでインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。\nそれぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ\u0026amp;ドロップすれば良いです。この先、Venturaの起動ボリュームは消去しますので、他にも必要なデータがありましたらバックアップしておきます。ホームディレクトリは別ボリュームですし、インストールしているソフトウェアの大半はクラウドから再度ダウンロードしても良いので、バックアップは適当です。\n3. USBメモリーからインストーラを起動する これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにInstall macOS Sonomaというボリュームが見えるはずです。\nただ、OpenCoreでデフォルト通りの設定をしていると、起動ボリュームの一覧にこのUSBメモリが現れないかもしれないです。それはconfig.plistのMisc, Security, ScanPolicyのデフォルト設定が原因です。これのデフォルト値 （Sample.plistに書いてある値も同じく）は、0x010F0103 (10進数では17760515) です。この設定のまま使っている場合、2重の理由で、今回のUSBメモリが起動ボリューム候補に現れません。\nまず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。 また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。 なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はXplistを使って変更している様子です。\nこれで起動項目にUSBメモリのインストーラが現れるようになります。Sonomaアイコンのボリュームが、USBメモリーです。このInstall macOS Sonomaを選択して起動します。\n4. インストール先ボリュームを消去する USBメモリから起動すると、下のようなメニューが現れます。\nここでディスクユーティリティを選んで、インストール先ボリュームを綺麗さっぱりフォーマットしました。インストール先のAPFSボリュームグループを選択し、名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。\nユーザのホームディレクトリは、上記のhomeという場所に置いています。Macintosh HDというボリュームは、macOS本体とアプリケーションが使ってます。なのでこちらを消去しても、大半のデータはそのまま残せます。\n5. Sonomaをインストールする Disk Utilityを閉じると、またメニューに戻ります。次にmacOS Sonomaインストールを選択します。するとおなじみのmacOSインストーラが起動します。後は、いつものようにインストールを進めていくだけです。\nインストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。この後数分で再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。\n何度かの再起動の後で、インストール先ドライブにつけた名前 (ここではMacintosh HD) の選択肢が現れ、選択されています。これで起動します。\nさらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。あとはいつものように、設定を行ないます。\nインストール終了したあと、このMacについてを確認しました。\nこれで、BIOS起動設定を内蔵SSDにすれば、今まで通り起動します。上の手順では、APFSボリュームグループをフォーマットしてたのでESPの内容は無事でした。ドライブ全体をフォーマットするとESPの内容も消えてしまいます。その場合は、USBメモリのESPの内容を、内蔵SSDに書き戻しておきます。\nまとめ OpenCoreで起動しているZ690マシンにSonomaをクリーンインストールしました。Wi-Fi以外は今のところ問題なく動作しています。ベータ版の時から、日本語と英語の入力モードの切り替えが高速になりわかりやすくなったのは、すごく良いです。\n追記：Venturaで使用できてたWi-Fiが使えなくなった問題に対しては、OCLPで対応可能です。詳しくはこちらをご覧ください。\nSonomaでBroadcom Wi-Fiを有効にする\n","date":"2023-09-29T18:31:35+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21470/","title":"SonomaのUSBインストーラを作ってクリーンインストール"},{"content":"OpenCoreの0.9.5が公開されていたので0.9.4からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.4 のconfig.plistそのままでも動きます。\n0.9.5をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.5とmacOS Venturaで動作確認していた手元のマシンは以下です。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.5.2 今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.4の時のままです。\n.efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n新たにsample.plistに追加された項目は以下です。\nUEFI/QuirksにShimRetainProtocolが追加されていました。boolデータで、デフォルトはfalseです。LinuxのセキュアなブートローダーShimという仕組みでOpenCoreを動かすためのものらしいです。使うことはないかと考え、デフォルトのままfalseにしておきました。 追加された項目はデフォルトで問題無いようですので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2023-09-13T16:52:25+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21448/","title":"OpenCore 0.9.4 から0.9.5に更新"},{"content":"macOS Ventura 13.5.2に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。\nVenturaの13.5.2の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。セキュリティ修正とのことで、小さなバグ修正のようです。サイズは475MBです。機能に変更は無い様子です。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動は3回で、最初がmacOS Installerから、2回3回目は通常の起動ボリュームから起動しました。\nビルド番号は22G91でした。13.5.1と末尾1番違いです。問題なく動作しています。\n","date":"2023-09-08T20:34:55+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21435/","title":"macOS Ventura 13.5.2 に更新"},{"content":"macOS Sonoma 14のPublic Beta 5が公開されていました。OpenCore 0.9.4と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。\nSonoma Public Beta 5が来た 米国時間の2023/8/31にSonomaのPublic Beta 5 にして、Dev Beta 7に相当するベータ版が無償配布されました。今回も今までと同様、developer.apple.comにはApple silicon版しかありませんでした。\n「システム設定…」「一般」「ソフトウェアアップデート」にもPublic Beta 5の通知は来ていますが、ダウンロードを試みると、これも\n前回同様に、インストールできないと言われます。\nそこで、再びこちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ここからダウンロードしたPublic Beta 5のファイルはpkg形式です。\nダブルクリックして、適当なフォルダにインストールすると、その中にmacOS 14 public beta 5インストーラが出来上がります。\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.4とmacOS 13.5.1で動作しています。\nmacOS Ventura 13.5 に更新\nこのmacOSの環境から、入手したインストーラを起動しました。\n今回も、テスト用に用意した2.5インチSATA SSDをフォーマットして、これにインストールしました。最初の再起動では、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されました。それで自動的にインストール終了しました。\n動作確認 特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5337aでした。デフォルトの壁紙は引き続きSonoma (?)の葡萄畑ですが、ズームの比率が変わったように見えました。\nまとめ macOS SonomaのPublic Beta 5が公開されたのでダウンロードして動作確認しました（この記事を書きました）。WiFiが使えない状態は相変わらずですが、それ以外の動作は試した限り問題ありませんでした。\n","date":"2023-09-03T14:13:02+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21427/","title":"macOS Sonoma 14 Public Beta 5をインストール"},{"content":"macOS Ventura 13.5.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。\nVenturaの13.5.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。8月18日から配布されていたようです。「位置情報へのアクセス許可が表示されない問題の修正」とのことで、小さなバグ修正のようです。サイズは475.9MBです。機能に変更は無いようです。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動は3回で、最初がmacOS Installerから、2回3回目は通常の起動ボリュームから起動しました。\nビルド番号は22G90でした。問題なく動作しています。\n","date":"2023-08-26T12:02:12+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21416/","title":"macOS Ventura 13.5.1 に更新"},{"content":"macOS Sonoma 14のPublic Beta 4が公開されていました。OpenCore 0.9.4と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。\nSonoma Public Beta 4が来た 米国時間の2023/8/22にSonomaのPublic Beta 4 にして、Dev Beta 6に相当するベータ版が無償配布されました。前回はBeta 1をインストールしましたが、Beta 2とBeta 3は見逃してしまいました。それでBeta 4をインストールしてみることにしました。\n今回も今までと同様、developer.apple.comにはApple silicon版しかありませんでした。\n「システム設定…」「一般」「ソフトウェアアップデート」にもBeta 4の通知は来ていますが、ダウンロードを試みると、これも\n前回同様に、インストールできないと言われます。\nそこで、再びこちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ここからダウンロードしたPublic Beta 4のファイルはpkg形式です。\nダブルクリックして、適当なフォルダにインストールすると、その中にmacOS 14 public beta 4インストーラが出来上がります。\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.4とmacOS 13.5で動作しています。\nmacOS Ventura 13.5 に更新\nこのmacOSの環境から、入手したインストーラを起動しました。\n今回も、テスト用に用意した2.5インチSATA SSDをフォーマットして、これにインストールしました。再起動の様子を観察していなかったのですが、おそらく今までと同じく、最初の再起動では、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されたと思います。それで自動的にインストール終了しました。\n動作確認 特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5328bでした。デフォルトの壁紙が、カラフルな抽象模様から、おそらくはSonomaの葡萄畑に変わってました。\nまた、これは最初のベータ版から気づいていたのですが、文字入力の状態がカーソル位置に表示されるのが地味に便利です。英語キーボード派なので、Caps Lockを日本語・英数字の切り替えに使っています。時々、切り替え状態を間違えるのですが、Sonomaからは、カーソル位置に、「A」または「あ」のマークが現れて、どちらに切り替わったかを知らせてくれます。これだけでも早くSonomaに移行したいと思います。\nまとめ macOS SonomaのPublic Beta 4が公開されたのでダウンロードして動作確認しました。WiFiは使えないですが、それ以外の動作は試した限り問題ありませんでした。\n","date":"2023-08-25T21:23:24+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21388/","title":"macOS Sonoma 14 Public Beta 4をインストール"},{"content":"OpenCoreの0.9.4が公開されていたので0.9.3からアップデートしました。config.plistに追加された項目は一つだけで、デフォルトでも問題ありません。なので0.9.3 のconfig.plistそのままでも動きます。\n0.9.4をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.4とmacOS Venturaで動作確認していた手元のマシンは以下です。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.5 今回のタイミングで、AppleALC.kext、Lilu.kext、WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.3の時のままです。\n.efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n新たにsample.plistに追加された項目は以下です。\nMisc/BootにInstanceIdentifierが追加されていました。stringデータで、デフォルトは空です。「OpenCoreのインスタンスを識別するためのIDを英数字のstringで指定する」ためのものらしいです。現在は、「.contentVisibilityファイルがOpenCoreのインスタンスを識別するために使用する」そうです。.contentVisibilityは、OpenCore 0.8.8で導入された機能で、ピッカーが表示するブート項目を調整する機能のようです。よく理解できていないのですが、ピッカーが表示する項目が煩雑または、少なすぎて困ることがなければ、使わないものと考えました。それでデフォルトのまま空にしておきました。 追加された項目はデフォルトで問題無いようでしたので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2023-08-21T21:19:06+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21381/","title":"OpenCore 0.9.3 から0.9.4に更新"},{"content":"macOS Ventura 13.5に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。\nVenturaの13.5の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。メジャーなアップデートだけあって、サイズも1.04GBあります。とはいえ、内容はバグ修正とセキュリティーアップデートのようです。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22G74でした。\nバグ修正ということで、特に変化した点はありませんでした。例年のスケジュールでは、Sonomaが出るまで、あと13.6までのアップデートがありそうです。\n","date":"2023-07-25T12:56:57+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21350/","title":"macOS Ventura 13.5 に更新"},{"content":"macOS Sonoma 14のPublic Betaがいよいよ公開されました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードにインストールしたところ問題なく動作しました。\nSonoma Public Beta 1が来た 米国時間の2023/7/12にSonomaの最初のPublic Betaが無償配布されました。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。\n「システム設定…」「一般」「ソフトウェアアップデート」にも通知は来ていますが、ダウンロードを試みると、これも\nインストールできないと言われます。\n機種の設定の関係なのか、それともこちらでも配布されているのがApple Silicon用だけなのかもしれません。そこで、前回と同じく、こちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ダウンロードしたPublic Beta 1のファイルはpkg形式です。これを適当なドライブにインストールすると、\nその中にmacOS 14 public beta 1インストーラが入ってます。\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1 (c)で動作しています。\nmacOS Ventura 13.4.1 (c)に更新\nこのmacOSの環境から、入手したインストーラを起動しました。\n今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。Beta Dev 3までは、3回再起動しましたが、今回は2回でした。最初は、macOS Installerというボリュームが、2回目は、インストール先のボリュームが自動的に選択されます。\n動作確認 特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。ビルド番号は23A5286iでした。\nGeekBenchする GeekBench 6でベンチマークしてみました。シングルコア2900, マルチコア15750くらいでした。\nシングルコアスコアはどのMacよりも高速で、\nマルチコアスコアはM1 UltraのMac Studioに負けるくらいの性能でした。\nまとめ macOS SonomaのPublic Beta 1が公開されたのでダウンロードして動作確認しました。今まで通りWiFiは使えないですが、それ以外は、問題なく動作しました。\n","date":"2023-07-13T18:16:33+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21319/","title":"macOS Sonoma 14 Public Beta 1をインストール"},{"content":"macOS Ventura 13.4.1 (c)に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。\nVenturaの13.4.1 (c)の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。緊急のセキュリティアップデートのようで、サイズが6.6MBと極小です。機能に変更は無いようです。少し前に、(a)などのバージョンが出たそうですが、不具合があって差し替えられて(c)になったようです。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動は1回だけでした。ビルド番号は22F770829dでした。\n","date":"2023-07-13T16:33:10+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21321/","title":"macOS Ventura 13.4.1 (c)に更新"},{"content":"Sonoma Beta Dev 3が出たので、Beta Dev 2からアップデートしました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードで問題なく動作します。\nSonoma Beta Dev 3が来た 米国時間の2023/7/5にSonomaのBeta Dev 3が無償配布されました。開発者向けベータのバージョン3です。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。\nそこで、前回と同じく、こちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ダウンロードしたファイルはpkg形式です。これを適当なドライブにインストールすると、\nその中にmacOS 14 beta Dev 3インストーラが入ってます。\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1で動作しています。\nASRock Z690 Steel LegendでmacOSを動かす\nこのmacOSの環境から、入手したインストーラを起動しました。今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。インストールでは、Beta Dev 2までの時と同じく3回再起動します。最初は、macOS Installerというボリュームが、2回目以降は、インストール先のボリュームが自動的に選択されてます。\n動作確認 特に問題なく動作してます。WiFiが動作しない状況は変わってません。それ以外は、問題なく動作します。\nまとめ macOS SonomaのBeta Dev 3をダウンロードして動作確認しました。今まで通りWiFiは使えないですが、それ以外は、問題なく動作しました。\n","date":"2023-07-07T22:23:23+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21308/","title":"MacOS Sonoma 14 Beta Dev 3に更新"},{"content":"Sonoma Beta Dev 2が出たので、最初のBetaからアップデートしました。OpenCore 0.9.3と最新Kextで起動するZ690マザーボードで問題なく動作します。\nSonoma Beta 2が来た 米国時間の2023/6/21にSonomaのBeta Dev 2が無償配布されました。開発者向けベータのバージョン2です。ただ、developer.apple.comには、今回もApple silicon版しかありませんでした。\nそこで、前回と同じく、こちらのサイトのリンクからダウンロードしました。ダウンロード先は、https://swcdn.apple.com/というサーバーで、アップルがソフトウェア配布に使用しているサイトです。ダウンロードしたファイルはpkg形式です。これを適当なドライブにインストールすると、\nその中にmacOS 14 beta Dev 2インストーラが入ってます。今回はインストーラのみで、他のファイルはありませんでした。Beta Dev 1と違い、Sonomaのアイコンに変わってます。\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.3とmacOS 13.4.1で動作しています。\nASRock Z690 Steel LegendでmacOSを動かす\nこのmacOSの環境から、入手したインストーラを起動しました。今回も、テスト用に用意した2.5インチSATA SSDをインストール先にします。インストールでは、Beta Dev 1の時と同じく3回再起動します。最初は、macOS Installerというボリュームが、2回目以降は、インストール先のボリュームが自動的に選択されてます。\n動作確認 Beta 1では、Radeon RX 6600のDPに映像が出ず、HDMI端子に映像が出てました。今回は、DPにも映像が出るようになってました。\nWiFiが動作しない状況は変わってません。Broadcom搭載Macがサポート対象から外れたのでドライバが無くなったようです。それ以外は、問題なく動作します。\nまとめ macOS SonomaのBeta Dev 2を動作確認しました。グラフィックカードのDP出力が動くようになりました。WiFiは使えないですが、それ以外は、問題なく動作しました。\n","date":"2023-06-24T01:07:44+09:00","image":"/uploads/2023/06/icon512.png","permalink":"/posts/21277/","title":"MacOS Sonoma 14 Beta Dev 2に更新"},{"content":"macOS Ventura 13.4.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。OpenCoreとkext類は最新です。\nVenturaの13.4.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。セキュリティアップデートのようで、サイズが501.2MBと小さいです。機能に変更は無いようです。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22F82でした。\n","date":"2023-06-22T13:56:45+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21264/","title":"macOS Ventura 13.4.1に更新"},{"content":"OpenCoreの0.9.3が公開されていたので0.9.2からアップデートしました。config.plistに変更はありませんでしたので、0.9.2 のconfig.plistそのままでも動きます。\n0.9.3をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。バグフィックスと機能追加がされているようですが、大きな変更は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.2とmacOS Venturaで動作確認していた手元のマシンは以下です。今回のタイミングで、AppleALC.kext、Lilu.kext、WhateverGreen、VirtualSMC関連がアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.2の時のままです。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.4 .efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n新たにsample.plistに追加された項目は以下です。\nUEFI/OutputにConsoleFontが追加されていました。デフォルトは空です。OpenCoreの文字表示で使うフォントの指定のようです。多言語サポートしているEFIアプリ（例えばmemtest86）を使う場合に指定が必要な場合があるようです。通常は指定無しで良いようなので空白のままにしました。 UEFI/ProtocolOverridesにPciIoが追加されていました。デフォルトはfalseです。メモリ管理関係のパッチのようで、一部のUEFIドライバに関係するようです。特に該当しないようだったので、falseのままにしておきました。 追加された項目はデフォルトでも問題無いようでしたので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2023-06-13T17:18:39+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21257/","title":"OpenCore 0.9.2 から0.9.3に更新"},{"content":"2023/06/05のWWDC23キーノートでmacOS Sonomaが発表され、ベータ版が公開されました。Z690マザーボードとIntel Core i9-13900の自作PCにインストールして動作することを確認しました。\n開発ベータ版 例年、WWDCと同時に公開されるmacOSの開発ベータ版は、会費を払った開発者だけが対象でした。一般の人に配布されるのは、7月に入って公開されるパブリックベータ版からでした。しかし今年からは、開発ベータ版から無償で配布されています。\nApple、各OSの開発者向けβを誰でも無料でダウンロード可能に（Apple IDは必要）\nただ、developer.apple.comから試したところApple silicon版しか公開されていないようでした。実際にダウンロードしたところ、ファイルは14GBくらいのipswという形式で、Apple silicon用らしいです。\nmacOS Venturaのシステム設定・一般・ソフトウェアアップデートの、ベータアップデートのメニューの中にも、Sonomaが現れていました。これを選んだらインストーラを入手できるかと思い、試しました。\nしかし、やはり対象では無いとのことでした。機種IDはiMacPro1,1にしていて、Sonomaの動作対象Macです。こちらでも、Apple silicon版のみが配布されているのかもしれません。\n探したところ、こちらのサイトで、直接ダウンロードできるリンク先が紹介されていました。”macOS Sonoma Beta Full Installer”という項目のリンクです。https://swcdn.apple.com/というURLなので、ちゃんとしたAppleのサイトのようです。\nダウンロードしたファイルはpkg形式です。これを適当なドライブにインストールすると、\nその中にmacOS 14 betaインストーラが入ってます。これ以外にもファイルやフォルダがありますが、必要なのはこれだけでした。\nインストールする インストールしたコンピュータは、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600の自作PCです。OpenCore 0.9.2とmacOS 13.4で動作しています。\nASRock Z690 Steel LegendでmacOSを動かす\nこのmacOSの環境から、入手したインストーラを起動しました。\nインストーラを開くと、あとは通常のmacOSのインストールと同様です。テスト用に2.5インチSATA SSDを用意しました。これをインストール先にします。\nこのSSDはフォーマットした直後なので、そのESPにOpenCoreなどが入っていません。なので、マザーボードのEFIの起動は今まで通りのmacOS 13.4が入っているSSDで行います。OpenCoreの選択メニューで、新しいSonomaのSSDを選択します。\nインストールでは、3回ほど再起動します。最初は、macOS Installerというボリュームを選びますが、2回目以降は、インストール先のボリューム名を選びます。\n画面が出ない この後、インストールがほぼ終了し、グラフィックスカードに制御が切り替わるタイミングで、画面が真っ黒になりました。しばらく待っていたところボイスオーバーの案内がスピーカーから流れました。音が出るように用意しておくことは重要ですね。画面が出ていないだけで、インストールは成功しているようでした。\n少し試したところ、グラフィックスカードのRadeon RX 6600のHDMI端子に映像が出ているようでした。今まではDP端子を接続していたのですが、そちらはブラックスクリーンになったようです。ということで、ディスプレイをHDMI端子に接続すれば、問題なくmacOSのインストールを進めることができました。\n動作確認 この先、いつも通りのインストール手順で進み、無事にmacOS Sonomaが動作しました。OpenCoreの最新版があれば、Sonomaも問題無いようです。\n全コアが動作してます。\nWiFiが動かない 有線LANもBluetoothも動作してますが、WiFiは動いていません。今となっては古いBroadcomのWiFiなので、ちょっと心配ですが、最初のベータ版なのでまだドライバが入ってないだけだと思いたいです。（追記：いただいたコメントによるとBroadcom搭載Macがサポート対象から外れたのでドライバが無くなったようです）\nまとめ macOS Sonomaの開発ベータ版を動かして、OpenCoreの最新版で動作することを確認しました。新しいmacOSへの対応も順調に進みそうなので安心しました。\n","date":"2023-06-08T12:35:21+09:00","image":"/uploads/2023/06/Apple-WWDC23-macOS-Sonoma-hero-230605_big.jpg.large_.jpg","permalink":"/posts/21186/","title":"macOS Sonomaを第13世代Intel CPUで動かす"},{"content":"第 13 世代および第 12 世代 Intel® Core™ プロセッサーに対応 (LGA1700)\nASRock Z690 Steel Legendで組んだコンピュータにmacOS Ventura 13.4をインストールします。現在メインマシンとして使っているマザーボードです。何度か紹介記事を書いているのですが、分散していて古くもなったので、更新してまとめます。\n今までの記事 詳細は以下をご覧ください。最初のうちは第12世代CPUを使用していました。最後の2記事では、第13世代に移行してます。今回はこれの総集編・最新版です。\nASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす\nASRock Z690 Steel Legendのオーディオを動かす\nASRock Z690 Steel Legendをスリープさせる\nメインマシンをASRock Z690 Steel Legendに移行\nASROCK Z690 STEEL LEGENDのUSBを設定する\nRaptor Lake-S 13900KFの32コアをmacOSで使う\nCpuTopologyRebuildで13900KFのコア構成を調整する\nパーツ構成 マザーボード 使用するマザーボードはASRock Z690 Steel Legendです。WiFi付きのASRock Z690 Steel Legend WiFiでも良いです。\n最新マザーボードではないですが、現在も入手可能です。\nZ690は、第12世代 Intel® Core™ プロセッサーと第13世代 Intel® Core™ プロセッサーに対応しています。macOSのIntel CPUサポートは第10世代で止まっているので、Z690が対象とする世代のCPUはサポートされていません。今後もサポートされることはないと思われます。でもOpenCoreの設定で、CPU IDを古いCPUに見せかけることで動作します。第10世代CPUよりも性能が上がっているので、最新CPUを使うメリットはあります。\n数あるZ690マザーボードの中で、ASRock Z690 Steel Legendを選んだ理由は、\nPCIeスロットの数が多い（5個あります） こなれた有線LANチップ搭載でmacOS互換性が高い macOS互換の無線用key Eソケットとアンテナ穴がある という理由です。ここ数年のASRockは、比較的こなれたチップを搭載する傾向があり、macOSとの相性が良いと思ってます。Z590ではExtremeを選んでいたのですが、Z690 ExtremeではPCIeスロット数が減ってしまったので、Steel Legendにしました。見た目が派手目ですが、悪くはないです。\nCPU 12と13世代CPUが使用可能ですが、macOSのサポートを超えたCPUを使うなら、最新の第13世代が良いと思います。性能も向上してます。\n13900, F, K, KF, KS 13700, F, K, KF 13600K, KF 13500 13400, F 13100, F などが動作するはずです。今回は13900KFで動作確認しています。\nちなみに第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などが動作するはずです。\nグラフィックボード 第12, 13世代CPUのiGPUはmacOSでサポートされていません。なのでグラフィックボードは必須です。現在のmacOSで使用可能なグラフィックスボードは、以下です。\nAMD Vega 56, Vega 64, Radeon VII (OOB)\nAMD RX 400 series, RX 500 series (OOB)\nAMD RX 5000 series (“agdpmod=pikera”オプション使用)\nAMD RX 6600 XT, RX 6800, RX 6800 XT, RX 6900 XT (“agdpmod=pikera”オプション使用)\nこれらならば、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を使用しました。\nWiFi このマザーボードには、M.2 WiFiのスロットがあります。WiFiモデルマザーボードにはIntelのM.2カードが既に入っています。最近では、Intelの無線カードもkextを入れると使用可能なようですが、ここでは、macOSがネイティブにサポートしているBroadcom BCM94360NGを使いました。macOSとの相性が良くて、Handoff, Airdrop, Apple WatchでのログインなどがOOBで動きます。M.2無線カードとしては、互換性の高い唯一のカードだと思います。おすすめです。日本のが少し高価です。 AliExpressでは複数の販売者から安価に入手できます。\nその他のパーツ その他のパーツは、定評のある自作PCパーツならどれを使っても大丈夫だと思います。メインドライブは、WD_BLACK 1TB SN770 NVMe SSDを使用しました。\nBIOS設定 BIOSは、デフォルトの工場出荷時状態でも問題なく動作します。以下の設定は行っても良いと思います。\nOC Tweaker \u0026gt; DRAM Configuration \u0026gt; Load XMP Setting \u0026gt; XMP 2.0 Profile 1 Advanced \u0026gt; USB Configuration \u0026gt; XHCI Hand-off \u0026gt; Enabled Boot \u0026gt; Bootup Num-Lock \u0026gt; off デフォルトのままで良いのですが、変更されていると起動に支障の出る項目は、以下です。\nAdvanced \u0026gt; CPU Configuration \u0026gt; CFG Lock \u0026gt; Disabled (default) Advanced \u0026gt; Chipset Configuration \u0026gt; Above 4G Decoding \u0026gt; Enabled (default) EFIを作る 次に、マザーボードのEFIが起動するときに実行されるボリュームの内容を作成します。ここにはmacOSのブートシーケンスが始まる前に必要となるファイル、つまりOpenCoreを構成するファイルとKext類を入れます。通常は、起動ドライブのESP (EFI System Partition)をFATでフォーマットしてその中に入れておきます。\n作成したEFIをこちらに置いておきます。参考にしてください。\n実は、FATでフォーマットしたUSBメモリにEFIというディレクトリを作ってその中に入れておいても良いです。このUSBメモリをEFIから起動すれば、OpenCoreなどが実行されます。USBメモリにmacOSなどが入っている必要はありません。OpenCoreの起動ドライブ選択メニューで、macOSボリュームを選択します。Hackintoshを作る最初は、色々と試行錯誤する必要がありますので、USBメモリの通常のディレクトリで設定作業すれば、作業が楽です。完成したら、その内容をmacOS起動ドライブのESPにコピーすれば良いです。\nOpenCore OpenCoreは最新の0.9.2を使いました。OpenCore Vanilla GuideもComet Lakeの項目しかありません。参考にしつつ、設定を進めました。tonymacx86のこちらのコメントも参考にしました。\nKext 使用したKext類は以下です。\nLilu.kext WhateverGreen.kext VirtualSMC.kext SMCSuperIO.kext SMCProcessor.kext LucyRTL8125Ethernet.kext AppleALC.kext NVMeFix.kext CpuTopologyRebuild.kext USBPorts.kext USBPorts.Kextは、自作です。USBの項目で説明します。\nACPI ACPIディレクトリに入れたSSDT類は以下です。\nSSDT-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の中に以下のように記述します。\n機種名 (SystemProductName) はiMacPro1,1にしました。第12, 13世代CPUで使用する場合、 iMacPro1,1 または MacPro7,1 が良いようです。どちらを選んでも性能はほぼ変わらないそうです。今回、iMacPro1,1にした理由は、性能調整が簡単そうだったからです。MacPro7,1に設定した場合は、CPUFriend.kextと関連kextsが必要らしいです。機種に関連するconfig.plist項目は以下です。\n公開したconfig.plistも、この設定になってます。ここでは、\nMLB SystemSerialNumber SystemUUID ROM の情報が未記入または適当な値になってます。各自で設定した固有の情報を書き込んでください。設定の方法はこちらをご覧ください。以下ではiMac20,1の固有情報を生成していますが、これをiMacPro1,1に変えて生成してください。\n最後のIntel iMacのシリアル番号を作る\nUSB設定 macOSにはUSBポート数の制限があります。なのでそれに対応する必要があります。詳しくはこちらをご覧ください。\nASROCK Z690 STEEL LEGENDのUSBを設定する\nこれによると、ASRock Z690 Steel LegendのUSBポートは、以下です。\nHS01:マザーボード上の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ピンは、それぞれ以下の名前です。\nmacOSには最大15口までの制限があります。なので、ここから使用するポートを15個選んでUSBPorts.kextに設定します。どのポートを使うかは、マシンの構成次第です。例えば、上記のリストで、太字になっているポートを残すと、\nのような設定になります。これを元にUSBPorts.kextを作ります。配布しているUSBPorts.kextは、もしかしたらこれから変更したバージョンかもしれません。必要に応じで調整してください。\n動作確認 macOS Ventura 13.4をインストールして動作確認しました。メインでずっと使用しているマザーボードなので、かなり調整が進んでいて、動作状態も良好です。\n動くこと 安定した動作 シャットダウン、再起動 有線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のスクリーンショットを以下に示します。\n同じくこのマザーボードに12900Kを搭載した場合との比較を以下に示します。また、ネットにあったMac Studio M1 MaxとUltraのスコアとも比較します。\nまとめ 現在メインマシンとして使っているASRock Z690 Steel LegendへmacOSをインストールする手順、動作状況などを、改めてまとめました。また、使用中のEFI一式もアップロードしておきました。\n","date":"2023-06-01T22:58:23+09:00","image":"/uploads/2021/11/image.png","permalink":"/posts/21136/","title":"ASRock Z690 Steel LegendでmacOSを動かす"},{"content":"ASRock Z590 Extremeで組んだコンピュータにmacOS Ventura 13.4をインストールします。以前、メインマシンとして使っていたマザーボードですが、紹介記事が分散していて古くもなったので、更新してまとめます。\n今までの記事 以前は、ASRock Z590 Extremeで作ったmacOSマシンをメインに使ってました。色々調整して、安定して動作してました。その過程を紹介した様子は、以下をご覧ください。散らばっていてわかりにくいので、まとめ記事が欲しいと思っていました。\nASRock Z590マザーボードでmacOSを起動する\nASRock Z590マザーボード搭載ALC1220で音を出す (その1)\nASRock Z590マザーボード搭載ALC1220で音を出す (その2)\nASRock Z590 Extremeに無線モジュールを取り付ける\nASRock Z590 ExtremeのUSBを設定する\nメインマシンをASRock Z590 Extremeに移行\nその後、Z690マザーボードに移行したので、このマシンはずっとお蔵入りになってました。最近になって、復活させてOpenCoreとmacOSを最新版 (OpenCore 0.9.2, macOS Ventura 13.4) に入れ替えてみました。動作確認や調整などまだ必要ですが、設定をまとめて、動作するEFIファイルを配布したいと思います。\nパーツ構成 マザーボード 使用するマザーボードはASRock Z590 Extremeです。WiFi付きのASRock Z590 Extreme WiFiでも良いです。\nもはや中古でしか入手できないのではと思いましたが、現在も入手可能です。\nZ590は、第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を作るとしたら、この世代のマザーボードに行きつきます。\n数あるZ590マザーボードの中で、ASRock Z590 Extremeを選んだ理由は、\nPCIeスロットの数が多い こなれた有線LANチップ搭載でmacOS互換性が高い 見た目がスッキリしている macOS互換の無線用key Eソケットとアンテナ穴がある という理由です。ここ数年のASRockは、比較的こなれたチップを搭載する傾向があり、macOSとの相性が良いと思ってます。有線LANが1個だけになりますが、ほぼ同じ構成のも良いと思います。個人的には、Extremeの方が見た目も良いと思います。\n（現在のメインマシンではASRockのZ690 Steel Legendを使ってます。本当はZ690もExtremeを使いたかったのですが、PCIeスロットの数が減ってしまったので、Steel Legendにしました。）\nCPU Core i9-10900Kを使用しました。これ以外の第10世代Core i CPUはほぼ使用可能だと思います。\nとくにiMacで搭載されているCPUならば、間違いなく動作するはずです。Macで使用されているComet Lake CPUは、Intel Core i5 10500, 10600, i7 10700K, i9 10910です。このうち、10910はApple専用チップですので、市販されていません。なので、\nCore 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だと言えます。このほか、\nCore 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) なども安定して使用可能です。\nZ590チップセットでは、第11世代CPUも使用可能です。しかし11世代はmacOSが正式対応していません。対応させることも可能ではありますが、性能が振るわずあまり人気のなかった11世代を使うくらいならば、もっと最新の13世代を使いたいところです。\nグラフィックボード macOSを動かすためにグラフィックボードはほぼ必須です。CPU内蔵のiGPUも使えなくは無いですが、設定が大変です。そもそもZ590クラスのATXマザーボードを使うならば、iGPUを使うことはないと思います。\n現在のmacOSで使用可能なグラフィックスボードは、以下です。\nAMD 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 580を使用しました。\nWiFi このマザーボードには、M.2 WiFiのスロットがあります。WiFiモデルマザーボードにはIntelのM.2カードが既に入っています。最近では、Intelの無線カードもkextを入れると使用可能なようですが、ここでは、macOSがネイティブにサポートしているBroadcom BCM94360NGを使いました。macOSとの相性が良くて、Handoff, Airdrop, Apple WatchでのログインなどがOOBで動きます。M.2無線カードとしては、互換性の高い唯一のカードだと思います。おすすめです。日本のが少し高価です。 AliExpressでは複数の販売者から安価に入手できます。\nその他のパーツ その他のパーツは、定評のある自作PCパーツならどれを使っても大丈夫だと思います。メインドライブは、WD_BLACK 1TB SN770 NVMe SSDを使用しました。\nBIOS設定 BIOSは、デフォルトの工場出荷時状態でも問題なく動作します。以下の設定は行っても良いと思います。\nAdvanced \u0026gt; USB Configuration \u0026gt; XHCI Hand-off \u0026gt; Enabled デフォルトのままで良いのですが、変更されていると起動に支障の出る項目は、以下です。\nAdvanced \u0026gt; CPU Configuration \u0026gt; CFG Lock \u0026gt; Disabled (default) Advanced \u0026gt; Chipset Configuration \u0026gt; Above 4G Decoding \u0026gt; Enabled (default) EFIを作る 次に、マザーボードのEFIが起動するときに実行されるボリュームの内容を作成します。ここにはmacOSのブートシーケンスが始まる前に必要となるファイル、つまりOpenCoreを構成するファイルとKext類を入れます。通常は、起動ドライブのESP (EFI System Partition)をFATでフォーマットしてその中に入れておきます。\n作成したEFIをこちらに置いておきます。参考にしてください。\n実は、FATでフォーマットしたUSBメモリにEFIというディレクトリを作ってその中に入れておいても良いです。このUSBメモリをEFIから起動すれば、OpenCoreなどが実行されます。USBメモリにmacOSなどが入っている必要はありません。OpenCoreの起動ドライブ選択メニューで、macOSボリュームを選択します。Hackintoshを作る最初は、色々と試行錯誤する必要がありますので、USBメモリの通常のディレクトリで設定作業すれば、作業が楽です。完成したら、その内容をmacOS起動ドライブのESPにコピーすれば良いです。\nOpenCore OpenCoreは最新の0.9.2を使いました。OpenCore Vanilla GuideのComet Lakeの項目に従って、以下を設定しました。\nDesktop Comet Lake | OpenCore Install Guide\nKext 使用したKext類は以下です。\nLilu.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です。\nUSBPorts.Kextは、自作です。USBの項目で説明します。\nACPI ACPIディレクトリに入れたSSDT類は以下です。\nSSDT-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の内容は以下のようにしました。\n公開したconfig.plistも、この設定になってます。ここでは、\nMLB SystemSerialNumber SystemUUID ROM の情報が未記載または適当な値になっています。各自で設定した固有の情報を書き込んでください。設定の方法はこちらをご覧ください。\n最後のIntel iMacのシリアル番号を作る\nUSB設定 macOSにはUSBポート数の制限があります。なのでそれに対応する必要があります。詳しくはこちらをご覧ください。\nASRock Z590 ExtremeのUSBを設定する\nこれによると、ASRock Z590 ExtremeのUSBポートは、以下のように23個あります。\nHS01 マザーボード上の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のマニュアルに記載されているポートの名前です。マニュアルのバックパネルの図にポート名を書き込むと以下になります。\nまたマザーボード上のUSBピンは、それぞれ以下の名前になります。\nマザーボード上のUSB2.0ピンはチップセット直結なのに対して、USB3.xピンはUSBハブ経由なのが面白いところです。Gen2x2のコネクタは、裏表で同じSSポートに割り当てられています。\nmacOSでは15個のUSBポートが使用可能です。使用形態に合わせて選択して、USBPorts.kextに反映させます。配布しているEFIでは、マザーボード上のUSB2.0ヘッダ端子を無効にしました。その結果、以下を動作させています。\nHS03 バックパネルの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ビデオ再生など）ように思います。さらに調整しつつ、動作確認していきたいと思います。\n動くこと 安定した動作 シャットダウン、再起動 有線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として安定して動作していますが、スリープ動作などもう少し調整したい項目もあります。サブマシンなのでゆっくりですが、この先、動作確認項目などを更新していきます。\n","date":"2023-05-31T22:58:47+09:00","image":"/uploads/2021/03/Z590-ExtremeL6.jpg","permalink":"/posts/21138/","title":"ASRock Z590 ExtremeでmacOSを動かす"},{"content":"2020年モデルiMacは、macOSが動く最後のIntel iMacです。このシリアル番号を生成する方法を、更新して再度掲載しておきます。\n最後のIntel iMac macOSが動作する最新で最後のIntel iMacが2020年iMacです。モデルIDは、iMac20,1とiMac20,2です。第10世代Intel CPUを搭載した自作PCで、現行のmacOSを動作させるとしたら、このiMacを模倣することになると思います。\niMac20,1と20,2の違いは搭載されているRadeon GPUの違いです。他には大きな違いはないと思われます。\niMac20,1とiMac20,2の違い\nとはいえ、iMac20,1の方が、広いCPUをカバーしています。また、次に述べるように、iMac20,2は、あまり出回っていませんので、シリアル番号に関する情報も少ないです。なので、自作PCの機種IDには、iMac20,1を選んでおくのが良いと思います。\nシリアル番号を作る macOSの起動には、コンピュータハードウェアにシリアル番号が必要です。実際のMacでは、マザーボードのファームウェアの中にシリアル番号が書き込まれています。自作PCでは、ESPの中のconfig.plistに書いておきます。OpenCoreがこの情報を、Macのシリアル番号としてmacOSに伝えてくれます。\nOpenCoreのconfig.plistに書くべきシステムシリアル番号 (SystemSerialNumber)、ボードシリアル番号 (MLB) を自動生成してくれるツールの一つにmacserialがあります。OpenCore配布サイトや、Kext Updateでダウンロードすると、\nReleases · acidanthera/OpenCorePkg\nダウンロードされたファイルの、OpenCore/Utilities/macserialの中に、macserialコマンドとして入っています。これを\n$ ./macserial として起動すると、現在のMac/Hackintoshのシリアル番号などの情報が表示されます。–helpとすれば使い方の説明が表示されます。\n$ ./macserial --help ./macserial arguments: --help (-h) show this help --version (-v) show program version --deriv \u0026lt;serial\u0026gt; (-d) generate all derivative serials --generate (-g) generate serial for current model --generate-all (-a) generate serial for all models --info \u0026lt;serial\u0026gt; (-i) decode serial information --list (-l) list known mac models --mlb \u0026lt;serial\u0026gt; generate MLB based on serial --sys (-s) get system info Tuning options: --model \u0026lt;model\u0026gt; (-m) mac model used for generation --num \u0026lt;num\u0026gt; (-n) number of generated pairs --year \u0026lt;year\u0026gt; (-y) year used for generation --week \u0026lt;week\u0026gt; (-w) week used for generation --country \u0026lt;loc\u0026gt; (-c) country location used for generation --copy \u0026lt;copy\u0026gt; (-o) production copy index --line \u0026lt;line\u0026gt; (-e) production line --platform \u0026lt;ppp\u0026gt; (-p) platform code used for generation –generateオプションで現在モデルのシリアル番号とボードシリアル番号を複数生成してくれます。–generate-allで全てのモデルの番号を生成します。–model iMac20,1などとすれば特定のモデルの番号を生成してくれます。iMac20,1のシリアル番号を生成した例が以下です。｜の左側がシステムシリアル番号で、右側がMLBです。\n% ./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のシリアル番号も生成してみます。\n% ./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を選んだ方が良いでしょう。\n–info シリアル番号でそのシリアル番号を分析してくれます。例えば、上記のiMac20,1の例で生成した最初のシリアル番号C02G39Y0PN5Tでしたら、\n% ./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週製造のモデルとのことです。\n実存しないことの確認 シリアル番号はランダムに生成されます。実存するMacと同じ番号が生成されることは滅多にありませんが、念のために確認します。確認のためには、以下のAppleのサイトを利用します。\nCheck Your Service and Support Coverage - Apple Support\nこのページに、生成されたシリアル番号を入力して、\n上記のように「有効なシリアル番号を入力してください。」と表示されたらOKです。保証期間などの情報が現れてしまったら、このシリアル番号のMacを誰かが実際に使っている可能性があります。iCloudサービスなどを使用する際に問題が生じる可能性がありますので、別のシリアル番号を使用します。\nconfig.plistに書き込む 問題がなければ、このシリアル番号をOpenCoreのconfig.plistで使えます。config.plistのplist:Platforminfo:Genericの部分に機種固有情報を以下のように書き込みます。（以下は例です。この機種情報は使わないでください）\n\u0026lt;key\u0026gt;Generic\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AdviseFeatures\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MLB\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02129300GUPHC11M\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;MaxBIOSVersion\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;ProcessorType\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;0\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;ROM\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;112233445566\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;SpoofVendor\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;SystemMemoryStatus\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Auto\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SystemProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac20,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SystemSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;\u0026gt;C02G39Y0PN5T\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SystemUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;EEF45689-BBE5-4FB6-9E80-41B78F6578E2\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; macserialコマンドで作成した情報を、MLBとSystemSerialNumberに書き込みます。そのほかに、固有の番号としてROMとSystemUUIDがあります。\nROMは、本来はMac搭載のROMの固有IDらしいですが、固有ならばなんでも良いようです。なので、OpenCoreのガイドでは、EthernetカードのMACアドレスを使うと良いと説明しています。適当な6バイトのデータでも良いようです。\nSystemUUIDもユニークならばなんでも良いです。Macのターミナルには、uuidgenというコマンドがあり、適当にUUIDを作ってくれるので、これを使います。上記の例では、この値を書き込んでいます。\n% uuidgen EEF45689-BBE5-4FB6-9E80-41B78F6578E2 まとめ 第10世代Intel CPUを使った自作PCに、macOSをインストールする際に必要な、機種固有情報の作り方を紹介しました。ここで作成した、SystemSerialNumber, MLB, ROM, SystemUUIDをOpenCoreのconfig.plistに書き込んでおきます。実際にインストールする際には、記事の中の機種固有情報とは違うものを使ってください。\nこれらの機種固有情報は、一旦設定したら、できる限り変更しないほうが良いです。機種固有情報が頻繁に変化するデバイスは、Appleのクラウドサービスに拒絶される可能性があります。\n","date":"2023-05-31T16:20:48+09:00","image":"/uploads/2020/08/Apple_imac-magickeyboardnum-magicmouse2-macos-wallpaper_08042020.jpg","permalink":"/posts/21152/","title":"最後のIntel iMacのシリアル番号を作る"},{"content":"macOS Ventura 13.4に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。\nVenturaの13.4の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは1.03GBです。「機能向上」の項目に、「再起動後にMacへのキーボードの接続に時間がかかるBluetoothの問題を修正」とあります。スリープ後のBluetooth復帰に時間がかかる場面があったので、もしかして効果があるかなと期待しました。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22F66でした。\nスリープ復帰後のBluetoothへの接続は、スムーズになった気がしますが、気のせいかもしれません。もう少し様子を見ます。\n","date":"2023-05-19T12:11:54+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21123/","title":"macOS Ventura 13.4に更新"},{"content":"OpenCoreの0.9.2が公開されていたので0.9.1からアップデートしました。config.plistに変更はありませんでしたので、0.9.1 のconfig.plistそのままでも動きます。\n0.9.2をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。最近の更新に比べると変更点は多いようですが、大半はバグフィックスのようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.2とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextとLilu.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.1の時のままです。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.3.1 (a) .efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n新たにsample.plistに追加された項目は以下です。\nKernel/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のままでも、変更なしで起動します。\n","date":"2023-05-17T11:39:50+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21117/","title":"OpenCore 0.9.1 から0.9.2に更新"},{"content":"macOS Ventura 13.3.1 (a)に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。\nVenturaの13.3.1 (a)の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。いつものアップデートではなく、「緊急セキュリティ対応」(Rapid Security Response、RSR) というものらしいです。サイズは53.2MBでした。非常に小さいです。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は1回で、通常のインストール先ボリュームからでした。ビルド番号は22E772610aでした。\n","date":"2023-05-02T23:22:00+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21101/","title":"macOS Ventura 13.3.1 (a)に更新"},{"content":"macOS Ventura 13.3.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。\nVenturaの13.3.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは584.7MBでした。いつもよりかなり小さいです。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22E261でした。\n","date":"2023-04-08T19:25:53+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21073/","title":"macOS Ventura 13.3.1に更新"},{"content":"OpenCoreの0.9.1が公開されていたので0.9.0からアップデートしました。config.plistに変更はありませんでしたので、0.9.0 のconfig.plistそのままでも動きます。\n0.9.1をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はほとんど無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.1とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.9.0の時のままです。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.3 .efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n今回も、config.plistで変更された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2023-04-08T18:55:04+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21070/","title":"OpenCore 0.9.0 から0.9.1に更新"},{"content":"macOS Ventura 13.3に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。\nVenturaの13.3の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは2.24GBでした。13.2.1の時に比べて大きいです。\n今回のアップデートで、「“写真”の“重複項目”アルバムで、iCloud共有写真ライブラリ内の重複する写真やビデオの検出にも対応」されました。iOSではすでに対応している機能のようですが、macOSからも重複解消機能が使えるようになりました。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は3回でした。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22E252でした。\n","date":"2023-03-28T12:44:42+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21047/","title":"macOS Ventura 13.3に更新"},{"content":"OpenCoreの0.9.0が公開されていたので0.8.9からアップデートしました。config.plistに変更はありませんでしたので、0.8.9 のconfig.plistそのままでも動きます。\n0.9.0をダウンロードする 0.9になりました。1.0までもう少しですね。公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はほとんど無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.9.0とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, Lilu.kext, VirtualSMC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.9の時のままです。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.2.1および13.3 .efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nこの際、plist直下の#WARNINGの4行と、plist/NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82の#INFO (prev-lang:kbd)のコメント行は、それぞれ削除しました。特に後者は、これが書いてあると起動に失敗することがあります。\n今回、config.plistで変更された項目はありませんでした。なので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2023-03-28T12:05:20+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21043/","title":"OpenCore 0.8.9 から0.9.0に更新"},{"content":"OpenCoreの0.8.9が公開されていたので0.8.8からアップデートしました。config.plistに大きな変更はありませんでしたので、0.8.8 のconfig.plistそのままでも動きます。\n0.8.9をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.9とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.8の時のままです。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.2.1 .efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで変更された項目は以下だけでした。\nUEFI/QuirksにResizeUsePciRbIoという項目が追加されていました。メモリー確保に関連してCapability I/O Errorを出すシステム対策のようでした。デフォルトはfalseだったのでそのままfalseに設定しました。 結局は、デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2023-02-28T19:10:39+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/21036/","title":"OpenCore 0.8.8 から0.8.9に更新"},{"content":"macOS Ventura 13.2.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。\nVenturaの13.2.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは547.6MBでした。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。再起動回数は、いつものアップデートより多くて4回でした。ただ4回目は、電源が一旦落ちての再起動だったので、手元の環境独自の事情があったのかもしれません。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームからでした。ビルド番号は22D68でした。\nフォーラムで、macOS13.2からmacOS13.2.1へのアップデートで、PioneerのBDドライブが認識されるように戻ったという情報がありました。\n","date":"2023-02-14T18:36:22+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/21016/","title":"macOS Ventura 13.2.1に更新"},{"content":"macOS Ventura 13.2に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。\nVenturaの13.2の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは1.05GBでした。\nそのまま「今すぐインストール」ボタンを押したところ、自動的にアップデートされました。今回は再起動の回数が少なくて、最初の再起動もインストール先のボリュームでした。小さめのアップデートだったようです。ビルド番号は22D49でした。\n今回のアップデートにより、HomePod miniが測定した室温・湿度をホーム.appに表示してくれるようになり、温度・湿度をトリガーにしたオートメーションが作れるようになりました。\n","date":"2023-01-26T15:43:46+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20976/","title":"macOS Ventura 13.2に更新"},{"content":"OpenCoreの0.8.8が公開されていたので0.8.7からアップデートしました。config.plistに大きな変更はありませんでしたので、0.8.7 のconfig.plistそのままでも動きます。\n0.8.8をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.8とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kext, Lilu.kext, WhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.7の時のままです。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.1 .efiファイルを差し替える 更新するために、今までと同様に、X64フォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを作り直す 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで変更された項目は以下だけでした。\nMisc/BootにHibernateSkipsPickerという項目が追加されていました。macOSハイバーネーションから復帰した場合に、ピッカーを表示しないための設定です。デフォルトはfalseだったのでそのままfalseに設定しました。 結局は、デフォルトのままですので、古いconfig.plistのままでも、変更なしで起動します。\n","date":"2023-01-26T15:31:53+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/20971/","title":"OpenCore 0.8.7 から0.8.8に更新"},{"content":"macOS Ventura 13.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。\nVenturaの13.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは1.18GBでした。\nそのまま「今すぐインストール」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22C65でした。\n","date":"2022-12-17T20:43:56+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20929/","title":"macOS Ventura 13.1に更新"},{"content":"OpenCoreの0.8.7が公開されていたので0.8.6からアップデートしました。config.plistに変更はありませんでしたので、0.8.6 のconfig.plistそのままで動きます。\n0.8.7をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.7とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextとWhateverGreen.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.6の時のままです。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.0.1 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistは変更なし 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\n結局は、config.plistの項目には変更ありませんでした。なので、古いconfig.plistのまま、変更なしでも問題なく起動します。\n","date":"2022-12-14T22:34:41+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/20924/","title":"OpenCore 0.8.6 から0.8.7に更新"},{"content":"OpenCoreの0.8.6が公開されていたので0.8.5からアップデートしました。config.plistに大きな変更はありませんので、0.8.5 のconfig.plistそのままでも動くはずです。\n0.8.6をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。大きな変更点は無いようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.6とmacOS Venturaで動作確認している手元のマシンは以下です。今回のタイミングで、AppleALC.kextがアップデートされましたのでそれを入れ替えてました。そのほかのkext類は0.8.5の時のままです。\nASRock Z690 Steel Legend + 13900K + Radeon RX 6600 XT + macOS Ventura 13.0.1 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistの変更点は以下でした。\nUEFI/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のまま、変更なしでも問題なく起動するはずです。\n","date":"2022-11-10T21:33:17+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/20895/","title":"OpenCore 0.8.5 から0.8.6に更新"},{"content":"macOS Ventura 13.0.1に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、13900KF、 Radeon RX 6600です。\nVenturaの13.0.1の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。サイズは493.5MBでした。\nそのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A400でした。\n先日13.0が出て、間をおかずに13.0.1が出たように思いますが、過去の例を見るとMontereyもBig Surも最初の公開バージョン自体が12.0.1, 11.0.1だったんですね。\n","date":"2022-11-10T12:42:12+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20890/","title":"macOS Ventura 13.0.1に更新"},{"content":"前回アップグレードしたCore i9-13900KFは、その後もmacOS Ventura 13.0で順調に稼働してます。\nRaptor Lake-S 13900KFの32コアをmacOSで使う\nこの記事へのコメントで、CpuTopologyRebuildというkextを作者の方から教えて頂きました。物理コアとハイパースレッド (HT) の構成をmacOSに伝えるkextです。Alder Lake-Sのために作られて、Raptor Lake-Sでは未検証とのことでしたが、試したところ正しく動作しました。13900K, KFは、Pコア8, HT 8, Eコア16の全32スレッド構成 (8P16E32T) ですが、これを\n物理コア24, HT 8、全32スレッド (24C32T) または、 物理コア8, HT 24、全32スレッド (8C32T) に見せることが可能でした。ベンチマークテストの結果、マルチコアのスコアはどの構成でも大差はありませんが、シングルコアのスコアは物理コア8 (8C32T) と設定した場合が高性能でした。\nCpuTopologyRebuild.kext 今回試したkextは、以下のCpuTopologyRebuild.kextです。\nGitHub - b00t0x/CpuTopologyRebuild\nCore i9-13900は、Pコア8, HT 8, Eコア16の構成です。macOSがサポートしているインテルCPUには、PコアとEコアが混在するモデルはありません。なので、均一の物理コアとHTの組み合わせとして認識させることになります。OpenCoreそのままで使用すると、全部が物理コアとして扱われて、\n物理コア32、全スレッド32 (32C32T) としてmacOSから見えるようになります。ちょっと乱暴な気はしますが、性能もそこそこ良く、特に問題は発生していませんでした。これに対して、CpuTopologyRebuild.kextを使うと、\n物理コア24, 全スレッド32 (24C32T)、または、 物理コア8, 全スレッド32 (8C32T) のようにmacOSに見せることができました。このkextを有効にすると物理コアが24になり、さらにboot argに-ctrsmtを追加すると物理コアが8コアになります。以下に13900K, KFのコア構成とkextの設定を表で示します。\n物理コア 全スレッド kext boot arg 32 32 なし なし 24 32 あり なし 8 32 あり -ctrsmt コア数を確認する Geekbench 5の表示で確認すると、確かにコアの構成が変わってます。以下はそれぞれ、32コア、24コア、8コアに設定した場合の表示です。\nさらに、sysctl -a | grep cpuした結果を、diffで比較しました。\u0026lt;で始まる行がkextなしで、\u0026gt;で始まる行がkextあり（-ctrsmtオプション付き）の項目です。OpenCoreデフォルトだと32コアなところが、このkextで8コアになっていることがわかります。\n\u0026lt; hw.perflevel0.physicalcpu: 32 \u0026lt; hw.perflevel0.physicalcpu_max: 32 \u0026gt; hw.perflevel0.physicalcpu: 8 \u0026gt; hw.perflevel0.physicalcpu_max: 8 \u0026lt; hw.perflevel0.cpusperl2: 1 \u0026gt; hw.perflevel0.cpusperl2: 2 \u0026lt; hw.physicalcpu: 32 \u0026lt; hw.physicalcpu_max: 32 \u0026gt; hw.physicalcpu: 8 \u0026gt; hw.physicalcpu_max: 8 Geekbench 5の比較 Geekbench 5のスコアを比較します。数回実施した平均値です。参考に、GeekbenchのサイトにあるM1 Ultraのスコアも加えました。13900は、M1 Ultraにはシングルで勝っているものの、マルチでは負けてます。\nコア構成の比較では、マルチの差は1%以下で誤差に近いです。シングルの差は4%くらいあって、8C \u0026gt; 32C \u0026gt; 24Cの順番で、8Cが一番良いです。\nCinebench R23の比較 Cinebench R23でもベンチマークしました。マルチは数回の平均、シングルは2回の平均です。これもM1 Ultraと比較しましたが、こちらはシングル、マルチとも13900がM1 Ultraよりも高速でした。Intel CPUが得意とするベンチマークのようです。\nコア構成の比較では、Geekbench 5と同様の傾向が見られました。マルチは32C \u0026gt; 8C \u0026gt; 24Cで、シングルは8C \u0026gt; 32C \u0026gt; 24Cの順番でした。マルチの差は、毎回の測定のばらつきよりも小さいので、誤差範囲かと思います。それでもGeekbenchと同様の傾向だったので、何か意味があるかもしれません。シングルもGeekbenchと同じ傾向でした。これも8Cが一番良い性能でした。\n動作の観察 CpuTopologyRebuildの作者の方も考察されてますが、それと同じ結果が得られました。シングルコアの性能は、8C \u0026gt; 32C \u0026gt; 24Cの順に高性能でした。\nアクティビティモニターで、Cinebenchシングルスコア測定中のCPUの負荷を観察しました。32個のスレッドの使用状況が棒グラフで表示されます。\nまずは32Cの場合の様子です。シングルスコアのベンチマークなので、一度には一つのコアしか使われていないと思いますが、一定時間累積しての表示なのか、複数の棒グラフが反応してました。それを見ると、全部のコアが区別なく使用されているようです。\n次は、24Cの場合の様子です。左半分の16本がPコアで、一つおきに本体とそのHTが表示されていると思われます。棒グラフを見ると、そのHTが選択から除外されている様子がわかります。PコアとEコア（おそらく右半分の16本）はあまり区別なく選択されてます。\n最後は8Cの場合の様子です。Pコアの物理コア部分のみが選択されてます。右半分のEコアは選択から外れてました。\n32Cのシングルコアベンチマークでは、PコアのHTが選択されることもあるので、スコアが下がるのではと予想してました。しかし24Cより好成績でした。想像ですが、HTが選択されても、対応する物理コアが動いていなければ、物理コアと同等の性能が出せるのかもしれません。その結果、作者の方の分析通り、Pコアが選択される確率の高い32Cの方が24Cよりも好成績になったのかと思われます。\nちなみに、マルチコアのベンチマーク時は、どのコア設定でも大差ありませんでした。CPU使用状況を見ると、ほぼどのスレッドもフルに稼働しています。重い作業をさせるベンチマークテストでは、スレッド優先順位が適切に設定されていても、結局は全てのスレッド総出で使用されるので、差が出ないのかと思いました。\nまとめ 13900KFのコア数設定を調整するCpuTopologyRebuild.kextを使ってみました。物理コアとハイパースレッド (HT) の数をmacOSに適切に伝えるためのkextです。ベンチマークテストで比較した結果、argで-ctrsmtをつけてこのkextを使い、物理コア8に設定することで、より良い性能を得られました。素晴らしいkextを作っていただきありがとうございます。\n","date":"2022-11-05T16:10:24+09:00","image":"/uploads/2022/10/package.jpg","permalink":"/posts/20847/","title":"CpuTopologyRebuildで13900KFのコア構成を調整する"},{"content":"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倍弱の性能でした。\nマシン構成 使用したマシンは、以下で紹介したASRock Z690 Steel Legend WiFi 6Eを使ったマシンです。macOSはVentura 13.0、OpenCoreは0.8.5で、kext類は最新です。\nASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす\n今までは12900Kを使っていましたが、これを13900KFに差し替えます。macOSでは内蔵GPUをサポートしていないので、GPUなしのKFモデルにしました。少しでも電力が抑えられるかなと思ったのですがどうでしょうか。Z690マザーボードはBIOSを最新にするとRaptor Lake-Sに対応します。なので、12900Kで動かしている間に、BIOSを更新しておきました。\n次に、CPUを交換して起動します。Alder Lake-SとRaptor Lake-Sは、ほとんど同じCPUなのか、OpenCoreのconfig.plistなどの書き換えは全く不要でした。何事もなく、問題なくmacOS Ventura 13.0が起動しました。アクティビティモニターでコア活動状況を見ると、32本の棒グラフが並びます。\nGeekbench 5でベンチマーク Geekbench 5でベンチマークを取りました。シングルは2200以上、マルチは19700以上のスコアが出ます。詳細を見ると、32コアのCPUになっています。HTもEコアも全部通常のコアに見えています。\nGeekbenchブラウザのサイトにあるMac Studio M1 Max / Ultraのスコアと、今回測定した13900Kのスコア（3回の平均）を比べたのが下の図です。シングルコアでM1 Max/Ultraの1.3倍くらい、マルチコアでM1 Maxの1.6倍、M1 Ultraの0.85倍くらいでした。\nGeekbench 5スコアの比較\nGeekbenchブラウザのページで、13900KFのスコアを見ると23000くらいです。Windowsでのスコアなので、macOSではここまでいかないと思われます。M1 Ultraのスコア越えは難しいかと思いました。実は使用しているCPUクーラーが貧弱です。\nCPU温度が測れていないのでなんともいえませんが、クーラを強化するとスコア改善するかもしれません。\nCinebench R23でベンチマーク Cinebenchのスコアも測定しました。3回実行した平均値では、 CPU (Single Core)が1986 pts、CPU (Multi Core)が35390 ptsでした。\nネットの情報によるとMac Studio M1 UltraのCinebench R23のスコアは、シングルで1562, マルチで23566だそうです。またMac Studio M1 MaxのCinebench R23のスコアは、シングルで1562, マルチで12402だそうです。以前に測定した12900Kのスコアは、シングルが1825、マルチが26520でした。これらをグラフで比較します。Intel CPUはCinebenchに強いようです。\nまとめ Intel Core i9-13900KFをmacOS Ventura 13.0で使用しました。Z690マザーボードのBIOSを最新版にした以外、12900K設定のままでmacOSが起動しました。ベンチマークをしたところ、Geekbench 5では、M1 MaxとM1 Ultraの中間、Cinebench R23ではM1 Ultraより良い結果が得られました。12900Kより性能が上がってます。12900Kの記事は以下をご覧ください。\nAlder Lake 12900Kの24コアをmacOSで使う\n次の世代のインテルCPUは、またアーキテクチャが変化すると言われています。macOSもApple Siliconに移行しつつあるので、これがmacOSが稼働する最後のCPUになるかもしれません。ネットの評価記事では、13700Kや13600Kの方が、発熱も穏やかでコストパフォーマンスが良いとも言われてますので、その選択も良いと思います。発熱に関しては、貧弱な空冷CPUクーラでしたが、短時間のベンチマークでしたら平気でした。\n","date":"2022-10-29T19:44:20+09:00","image":"/uploads/2022/10/package.jpg","permalink":"/posts/20810/","title":"Raptor Lake-S 13900KFの32コアをmacOSで使う"},{"content":"macOS Ventura 13.0がいよいよ公開されました。Monterey 12.6でダウンロードし、起動用USBメモリを作り、クリーンアップデートしました。最新版のOpenCore (0.8.5) とkext類でMontereyが動いていれば、通常の作業でアップデートできるはずです。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。\n作業に使ったシステム構成 本日 (日本時間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類は最新にしてあります。\nASROCK Z690 STEEL LEGENDのUSBを設定する\n直近まで使っていたmacOSはVentura 13.0 RC (22A380)です。ベータ版ですが、あまりに快適なのでそのままメインで使ってました。ただ、パブリックベータが公開される前まで使っていたMontereyとは別のSSDで使ってました。それで、3ヶ月以上ぶりに、Monterey 12.5が入ったSSDから起動しました。WDの1TB M.2 SSD, WDS100T2B0Cです。ベータ版を使っている間に12.6が公開されましたので、まずは12.6にアップデートしました。その上で、Venturaへアップデートしました。\nVenturaアップデートは自動 Venturaに更新したマシンの構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600で、Ventura公開前の最新版で12.6が動いてます。\nこのMontereyから、「システム環境設定」「ソフトウェアアップデート」を開いたところ、Venturaへのアップデートができるようになってました。容量は3.92GBだそうです。小さい気がしますが、多分必要に応じて追加でダウンロードするのかと思います。\nちなみに、「ほかにもアップデートがあります。」の表示が出ています。これをクリックすると12.6.1が来ていました。Venturaをすぐインストールしないという人も、こちらは入れておいた方が良いと思いました。\nVenturaへのアップデート画面で「今すぐインストール」ボタンを押したところ、まずはダウンロードが開始します。\nダウンロード終了後は、アップデートがスルスルと進んで行きました。今までのメジャーアップデートでは、「macOS Venturaをインストールするには、”続ける”をクリックしてください」という画面が出て、そこで中断できました。今回は自動で進むようです。そういえばVenturaで最初にベータ版を導入した時も、自動更新でした。ベータ版でも後には中断できるようになったので、この仕様も、今後変更されるかもしれません。\nということであっけなくVenturaにアップデートされました。快調に動作してます。ビルドは22A380で、Ventura RC 2と同一です。RC 2がそのまま公式版になったようです。\nクリーンインストールの手順 Montereyへの上書きインストールが思いがけず完了してしまいましたが、せっかくの年に一度のメジャーアップデートです。現在の起動ディスクであるM.2 SSDの内容を綺麗さっぱりと全消去して、クリーンインストールしようと思います。実は、ホームディレクトリは、別のAPFSボリュームに作ってあるので、起動M.2 SSDを消去してもそれほど面倒なことにはなりません。そこで次の手順でアップデートを進めます。\nVenturaインストーラをダウンロードする USBメモリを用意してVenturaインストールUSBを作る USBメモリのESPに現在のESPをコピーして起動できるようにする USBメモリーからインストーラを起動する インストーラからディスクユーティリティを起動し、M.2 SSDを消去する インストーラからVenturaをインストールする 1. Venturaインストーラをダウンロード 先ほどの自動アップデート時にダウンロードされたインストーラは、アップデート終了時に消えてしまってます。ということで再度、インストーラをダウンロードし直すことにしました。すでにVenturaになってしまった環境から、App Storeに行き、Venturaを検索したらありました。\n入手ボタンをクリックすると、ソフトウェアアップデートが動いてダウンロード開始しました。今回は、なぜか12.15GBとなってます。これなら全部を一括ダウンロードしてくれそうです。\nダウンロード終了すると、インストーラが起動します。今回は、「macOS Venturaをインストールするには、”続ける”をクリックしてください」というダイアログがちゃんと出て、中断可能です。\nここで中断すると、これもいつものようにアプリケーションフォルダに「macOS Venturaインストール」が出来上がっていました。先ほどのようにインストール作業で消えてしまうことがあるので、バックアップしておきましょう。\n2. VenturaインストールUSBを作る インストーラ用のUSBメモリを用意します。必要な容量は13.5GBですが、今回は32GBのUSB 3.0メモリーを用意しました。このUSBメモリーをディスクユーティリティ.appを使って初期化します。USBメモリを選択して、消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。ここでAPFSを選んでも良さそうな気もしますが、以前のバージョンのcreateinstallmediaコマンドではエラーが出ました。今回は試していませんが、Mac OS拡張（ジャーナリング）にしておくのが無難です。\n次に、VenturaインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもVenturaをインストールできるUSBメモリになります。ターミナルを使用して、Venturaインストーラの中のContents/Resourcesに移動するとcreateinstallmediaというファイルがあります。そこで以下のコマンドを入力します。\n$ 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 \u0026#34;/Volumes/Install macOS Ventura\u0026#34; パスワード入力と、確認のyを押すと、いろいろ進捗して終了します。これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。\n3. USBメモリのESPに現用のESPをコピーする こうして作成したインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。それぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ\u0026amp;ドロップすれば良いです。この先、M.2 SSDは消去しますので、他にも必要なデータがありましたらバックアップしておきます。\n4. USBメモリーからインストーラを起動する これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにVenturaインストーラが見えるはずです。\nただ、OpenCoreでデフォルト通りの設定をしていると、起動ボリュームの一覧にこのUSBメモリが現れないかもしれないです。それはconfig.plistのMisc, Security, ScanPolicyのデフォルト設定が原因です。これのデフォルト値 （Sample.plistに書いてある値も同じく）は、0x010F0103 (10進数では17760515) です。この設定のまま使っている場合、2重の理由で、今回のUSBメモリが起動ボリューム候補に現れません。\nまず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。 また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。 なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はXplistを使って変更している様子です。\nこれで起動項目にUSBメモリのインストーラが現れるようになります。Venturaアイコンのボリュームが、USBメモリーです。このInstall macOS Venturaを選択して起動します。\n5. インストール先ボリュームを消去する USBメモリから起動すると、下のようなメニューが現れます。\nここでディスクユーティリティを選んで、インストール先M.2 SSDを綺麗さっぱりフォーマットしました。インストール先のAPFSボリュームグループを選択し、名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。\n6. Venturaをインストールする Disk Utilityを閉じると、またメニューに戻ります。次にmacOS Venturaインストールを選択します。するとおなじみのmacOSインストーラが起動します。後は、いつものようにインストールを進めていくだけです。\nインストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。この後数分で再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。\n何度かの再起動の後で、インストール先ドライブにつけた名前 (ここではMacintosh HD) の選択肢が現れ、選択されています。これで起動します。\nさらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。あとはいつものように、設定を行ないます。\nインストール終了したあと、このMacについてを確認しました。\nこれでM.2 SSDから起動します。上の手順では、APFSボリュームグループをフォーマットしてたのでESPの内容は無事でした。ドライブ全体をフォーマットするとESPの内容も消えてしまいます。その場合は、USBメモリのESPの内容を、M.2 SSDの方に書き戻しておきます。\nまとめ OpenCoreで起動しているZ690マシンにVenturaをクリーンインストールしました。そのために、単体で起動してVenturaがインストールできるUSBメモリを作りました。ベータ版の時から安定していましたが、公開版Venturaも快適に動いています。\n","date":"2022-10-25T18:28:02+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20766/","title":"Ventura のUSBインストーラを作ってクリーンインストール"},{"content":"macOS Ventura 13 RC 2に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。\nmacOS Ventura 13.0という案内が「システム設定」「一般」「ソフトウェアアップデート」にまた来ていました。一昨日RCになったばかりだと思ったのですが、今度はRC 2のようです。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A380になってました。10月25日の正式リリースが近づき差し替えが頻繁になったのでしょうか。\n","date":"2022-10-21T13:52:53+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20754/","title":"macOS Ventura 13 RC 2に更新"},{"content":"macOS Ventura 13 RCに更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。\nmacOS Ventura 13.0という案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。今まであったBetaの文字が無くなってました。RC (Release Candidate) 版のようです。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号からは末尾bが無くなり、22A379になってました。正式版は10月25日に公開されるそうなので楽しみです。\n","date":"2022-10-19T22:21:30+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20742/","title":"macOS Ventura 13 RCに更新・正式版は10月25日"},{"content":"macOS Ventura 13 Beta 9に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。\nVenturaのPublic Beta 9の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5373bでした。開発者向けのBeta 11に相当するらしいです。正式版は今月中に公開されるそうなので楽しみです。\n","date":"2022-10-13T12:19:45+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20728/","title":"macOS Ventura 13 Beta 9に更新"},{"content":"OpenCoreの0.8.5が公開されていたので0.8.4からアップデートしました。config.plistに追加された項目はありませんので、0.8.4 のconfig.plistそのままでも動くはずです。\n0.8.5をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。変更点はいつもより少ない様子でした。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.5とmacOS 13 Public Beta 8で動作確認している手元のマシンは以下です。今回のタイミングでのkext類のアップデートはありませんでしたので、kext類は0.8.4の時のままです。\nASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Ventura PB8 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistの変更点はありませんでした。変更なしで、問題なく起動しました。間もなくリリースされるmacOS 13も安定して動きそうです。\n","date":"2022-10-08T14:54:57+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/20725/","title":"OpenCore 0.8.4 から0.8.5に更新"},{"content":"macOS Ventura 13 Beta 8に更新しました。更新間隔が短くなってきたので、正式リリースが近くなったかなと感じます。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。\nVenturaのPublic Beta 8の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5365dでした。開発者向けのBeta 10に相当するらしいです。\n","date":"2022-10-06T11:09:30+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20712/","title":"macOS Ventura 13 Beta 8に更新"},{"content":"macOS Ventura 13 Beta 7に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。\nVenturaのPublic Beta 7の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5358eでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。デフォルトの壁紙がダイナミックになって、時刻に合わせて変化するようになりました。\n","date":"2022-10-04T18:58:02+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20696/","title":"macOS Ventura 13 Beta 7に更新"},{"content":"macOS Ventura 13 Beta 6に更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。（配布された当初はBeta 8となってましたが、どうやら6だったようです。訂正しました）\nVenturaのPublic Beta 6の案内が「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5352eでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。\n","date":"2022-09-28T20:09:57+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20675/","title":"macOS Ventura 13 Beta 6に更新"},{"content":"OpenCoreの0.8.4が出て、macOS Ventura 13 Beta 5も出たので両方を更新しました。特に問題なく、安定して動いてます。動作確認したマシン構成は、ASRock Z690 Steel Legend、12900K、 Radeon RX 6600です。\nOpenCoreの0.8.4が公開されていたので0.8.3からアップデートしました。config.plistに追加・変更された項目はありませんので、0.8.3のconfig.plistそのままで動きます。\n一方で、VenturaのPublic Beta 5の案内も「システム設定」「一般」「ソフトウェアアップデート」に来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。ビルド番号は22A5342fでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。\n","date":"2022-09-10T16:38:37+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/20657/","title":"OpenCore 0.8.4にしてmacOS Ventura 13 Beta 5に更新"},{"content":"Ventura Public Betaのアップデート、Public Beta 4が出たので、Beta 3からアップデートしました。公開版OpenCore 0.8.3で問題なく動作します。\nVentura Public Beta 4が来た 昨夜（米国時間で2022/8/26）のうちに VenturaのPublic Beta 4が配布されていたようです。「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。Beta 3の時は、アップデートに失敗して全体をダウンロードし直しましたが、今回はちゃんとアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。\n公開版OpenCore 0.8.3で問題なく動作します。ビルド番号は22A5331fでした。今までのPublic Beta版と同様に、安定しているのでメインで使用します。\n","date":"2022-08-27T23:38:51+09:00","image":"/uploads/2022/07/icon1024.png","permalink":"/posts/20640/","title":"macOS Ventura 13 Beta 4をインストール"},{"content":"macOS 13 Ventura beta 3 (22A5321d) を、ASRock Z690 Steel Legend, 12900Kの環境で常用していたのですが、最近になって、CPUファンがうるさく回転していることに気づきました。アクティビティモニタでCPU使用状況を調べると、powerdというプロセスが104%くらいのCPUを使ってます。CPU使用の棒グラフを見ると左の方のコアの負荷が高いです。HWMonitorで温度を調べると、CPU Core 1が最高で77度くらいになって赤字表示でした。CPU Heatsink, Proximityも77度くらいまで上がってました。下のスクショは対応直後で、下がって余熱が残っている状況です。\nventura powerdで検索したところすぐに解決策が見つかりました。こちらです。\nMacOS Ventura powerd activity util… | Apple Developer Forums\nターミナルから、\n% sudo pmset schedule cancelall とすれば良いようです。このコマンドを発行したら、CPUファンはすぐに静かになり、CPU温度も低下して、全部のコアが30度台になりました。この問題はredditでも話題になっているようです。\npmsetコマンドは、電力管理の設定を変更するコマンドです。schedule cancelallは、起動・再起動・終了・スリープ・スリープ解除を行うスケジュールを全部キャンセルするという指定のようです。このコマンドを発行する前に、pmset -g schedすると、異常なスケジュールが設定されている様子を確認できるらしいです。スケジュールは、「システム環境設定」「省エネルギー」から、曜日を指定して設定できる機能です。もともと設定していないので、キャンセルしても問題無いです。\n手元の環境では、これで解決していますが、また暴走が始まることもあるそうです。ベータ版の途中から発生した問題のようですので、今後改善されると思います。\n","date":"2022-08-26T11:48:52+09:00","image":"/uploads/2022/08/powerd2.jpg","permalink":"/posts/20629/","title":"Venturaのpowerd暴走を止める"},{"content":"Ventura Public Betaのアップデート、Public Beta 3が出たので、Beta 2からアップデートしました。公開版OpenCore 0.8.3で問題なく動作します。\nBeta 3が来たけど更新できない 米国時間で2022/8/9に VenturaのPublic Beta 3が配布されていました。Developer Beta 5に相当するビルドらしいです。いつものように、Public Beta 2の、「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。\nただ、今回は「今すぐアップデート」ボタンを押したところ、一瞬でダウンロードが終わって「再起動」ボタンが現れるものの、再起動しません。手動で再起動してもインストール用ボリュームができていないようでした。準備が完璧じゃないのかと思い、しばらくの間放置していました。でも状況が変わらないようなので、gibMacOSを使ってPublic Beta 3のインストーラ本体をダウンロードすることにしました。\ngibMacOSでダウンロードする gibMacOSはアップルの公開サイトから入手できるmacOSを探してダウンロードしてくれるスクリプトです。corpnewtさんのgithubへ行って、gibMacOSの一式をzip形式でダウンロードしました。\nGitHub - corpnewt/gibMacOS: Py2/py3 script that can download macOS components\u0026hellip;\nPython版やシェルスクリプト版などが入ってますが、今回は、シェルスクリプト版のgibMacOS.commandを使用しました。gibMacOSのディレクトリに移動したあと、以下のように起動します。\n% ./gibMacOS.command 起動するとmacOSの公開版の一覧が出ます。Public Beta版も公開版として含まれていました。この番号（ここでは3番）を指定してダウンロードします。\n3. macOS Ventura beta 13.0 (22A5321d) - 012-51393 - Added 2022-08-09 17:07:05 - 11.97 GB ダウンロードされたファイル類は、gibMacOSディレクトリの中のmacOS Downloads/public/の中に保存されてます。\nここでInstallAssistant.pkgを開くと、インストーラが起動して、/ApplicationsフォルダにInstall macOS Ventura betaが出来上がります。これはインストール後に消えてしまいますので、必要ならばバックアップしておきます。\nVentura Beta 3をインストールする Install macOS Ventura betaを起動すると、お馴染みのインストール画面になります。インストール先を指定して続けると、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームから再起動します。\nOpenCore 0.8.3にしてあれば問題なく動作しました。ビルド番号は22A5321dでした。Beta 2と同様、安定しているのでメインで使用します。\n","date":"2022-08-20T10:52:36+09:00","image":"/uploads/2022/07/icon1024.png","permalink":"/posts/20620/","title":"macOS Ventura 13 Beta 3をインストール"},{"content":"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そのままでも動くはずです。\n0.8.3をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.3とmacOS 13 Public Beta 2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Ventura PB2 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistの変更点はありませんでした。変更なしで、問題なく起動しました。macOS 13 Public Betaは非常に安定しているので、このままメインで使い続ける予定です。秋の正式版リリースが楽しみです。\n","date":"2022-08-06T15:44:51+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/20600/","title":"OpenCore 0.8.3 (NB) から0.8.3に更新"},{"content":"Ventura Public Betaのアップデート、Public Beta 2が出たので、Beta 1からアップデートしました。OpenCore 0.8.3で問題なく動作します。0.8.3はKext Updaterで入手したNightly Buildです。\nVentura Public Beta 2が来た 昨夜（米国時間で2022/7/28）のうちに VenturaのPublic Beta 2が配布されていました。Developer Beta 4に相当するビルドらしいです。Public Beta 1の、「システム設定」「一般」「ソフトウェアアップデート」に案内が来ていました。そのまま「今すぐアップデート」ボタンを押したところ、いつものアップデート同様に、3回の再起動で自動的にアップデートされました。最初の再起動がmacOS Installerボリュームから、次回以降がインストール先のボリュームだったのもいつもと同様でした。\nOpenCore 0.8.3にしてあれば問題なく動作するようです。ビルド番号は22A5311fでした。Beta 1と同様、安定しているのでメインで使用します。\n","date":"2022-07-30T00:24:08+09:00","image":"/uploads/2022/07/icon1024.png","permalink":"/posts/20584/","title":"macOS Ventura 13 Beta 2をインストール"},{"content":"macOS Monterey 12.5が配布されていましたので12.4からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.5の情報はまだありません）。\nhttps://support.apple.com/ja-jp/HT212585 アップデートしたマシンは以下です。いつもはVentura public betaを動かしている関係でOpenCore 0.8.3にしてましたが問題ありません。0.8.2での起動もokです。kext類は最新です。\nASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT システム環境設定のソフトウェアアップデートに、12.5のアップデートの通知が来ていました。\nアップデートは、TVとSafariの不具合に対応したものらしいです。「今すぐインストール」ボタンを押すと、2.2GBのファイルがダウンロードされます。\nその後、自動的に4回再起動して、12.5に更新されました。前回同様、1回目の再起動にはmacOS Installerという名前のボリュームが現れ選択されていて、2回目以降はこのボリュームは消えて、通常の起動ボリューム（Macintosh HDという名前にしてます）が選択されました。\nいつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.5が起動しました。ビルドは21G72です。\n12.5が起動するESPのファイル一式はここに置いてあります。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。\n","date":"2022-07-21T23:15:30+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/20560/","title":"Monterey 12.5 にアップデートする"},{"content":"macOSインストール用のUSBメモリをWindowsだけを使って作成しました。まず、OpenCoreパッケージに付属しているmacrecovery.pyというPythonプログラムを使ってMacの復元イメージをダウンロードし、次にFAT32のUSBメモリに保存します。これでMacで起動するRecoveryボリュームを作ることができました。手順だけを手短に見たい人は、以下のStep: 1, Step: 2, Step: 3の節を見てください。\nmacOS導入USB macOSをインストールするためのインストール用USBメモリは、通常はmacOS上で作成します。macOSが動いていないとmacOSをインストールできないので、Macを持っていないと鶏と卵状態に陥ります。Windowsだけを使ってmacOSをインストールすることも、不可能ではないけどとても面倒です。\n・・・と、思っていたのですが、試してみたところ予想していたよりずっと簡単でした。OpenCoreのバニラなインストールガイドで知られているDortaniaさんの説明ページを参考にしました。\nこのページを見るとややこしそうに見えますが、基本的には、\nOpenCoreパッケージに入っているPythonプログラムを起動してmacOS復元イメージ（これを使うとmacOSをインストールできる）をダウンロードする それをFAT32でフォーマットしたUSBメモリに入れる だけです。\nmacOS環境ならば、Appleが配布しているmacOSインストーラの中にある、createinstallmediaコマンドを使ってインストーラUSBを作る方法が、Apple公式の方法で簡単です。この方法で作るUSBメモリは、HFS+でフォーマットされていて、MacやOpenCoreの起動選択画面ではそのOSのアイコンで表示されます。MontereyのインストーラUSBなら、下の写真にある「Install macOS Monterey」のようにOpenCoreの起動ボリューム選択画面に現れます。\nこれと同じものをWindowsで作るには、Windowsとは無縁なHFS+フォーマットのボリュームをなんとか作り出さないといけないので、とても大変だと思ってました。Dortaniaさんのページで紹介されているのは、HFS+形式USBメモリではなく、上の写真の右端に見切れて映っている、「Recovery 12.x (dmg)」という歯車アイコンに相当する復元用イメージを作る方法でした。\nStep1: 復元ファイルをダウンロード Windowsから、OpenCoreダウンロードのサイトを開き、最新版パッケージ一式をダウンロードします。ダウンロードサイトはここです。\nReleases · acidanthera/OpenCorePkg\nここから、OpenCore-x.x.x-RELEASE.zipをダウンロードします。ダウンロードしたファイルは、Downloadsディレクトリの中に、OpenCore-x.x.x-RELEASE.zipというファイル名で保存されてます。次に、このzipファイルの中にあるPythonプログラムを実行します。\nPythonの実行のために、通常はWindowsにPythonをインストールします。手元のWindowsマシンでは、WSLの UbuntuにすでにPythonをインストール済みだったので、以下では、WindowsとWSL Ubuntuを行ったり来たりして作業しました。WindowsにPythonがインストール済み、もしくはWSLを使っていない場合は、Windows側でPythonを実行してください。\nPythonの実行をWSL環境で行うために、Ubuntuを開けて、OpenCoreのzipファイルを作業しやすい場所にコピーします。次に、zipを解凍し、その中のUtilities/macrecoveryというフォルダに移動します。そしてそこにあるmacrecovery.pyというPythonプログラムを起動します。以下がその作業です。\ncp /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一覧がありました。\nList of Mac BoardID, DeviceID, Model Identifiers \u0026amp; Machine Models\nMacBookPro12,1の機種対応の最終OSがMontereyなので、この指定でMontereyをインストールするリカバリーイメージをダウンロードできます。MacBookPro12,1はVentura未対応なので、この先もMontereyがダウンロードできるはずです。\n他の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です。\nmacrecovery.pyを実行すると、\nBaseSystem.chunklist BaseSystem.dmg という2つのファイルが出来上がってます。この先、Windowsでの操作を行うので、Windowsからアクセスしやすいように、Downloadsディレクトリに戻しておきます。\ncp BaseSystem.* /mnt/c/Users/xxxx/Downloads/. Step2: USBメモリを初期化する 次に起動用USBメモリを初期化します。GUIDパーティションマップ (GPT)で用意したパーティションをFAT32でフォーマットします。一般的なフォーマットなので、特に難しいところはないように思われました。実際、macOSのディスクユーティリティで作ったMS-DOS (FAT) (GUIDパーティションマップ)のUSBメモリもそのまま使えました。ただ、macOSからUSBメモリの名前を変更したところ、通常の起動ドライブとして見えてしまうようになり、リカバリーイメージとしては表示されなくなり、使えなくなりました。微妙なパーティション・フォーマットの違いで動作しなくなるようです。\nDortaniaさんの手順では、WindowsでUSBメモリをフォーマットするツールとして、\nWindows標準のDisk Management （日本語名「ディスクの管理」） Rufusというオープンソフトウェア Windows標準のdiskpart を使う3つの方式が紹介されています。ここではWindows標準装備の1. と 3.の方法を試し、動作することを確認しました。\nDisk Managementを使う Disk Managementは日本語名で「ディスクの管理」というツールです。macOSのディスクユーティリティに相当するツールかと思います。これで、USBメモリを選択し、初期化します。すでにGPTのパーティションが用意されていたら、それを削除して、未割り当てにして、「新しいシンプルボリューム」を作ります。\nこのメニューを選択すると、「新しいシンプルボリュームウィザード」というプログラムが起動します。これを用いて、FAT32のボリュームを作成します。ここでボリュームラベルを指定することもできます。\nこれでFAT32のUSBメモリが完成するので、Step 3に進んで、ファイルをコピーします。\nDisk Managementは操作が簡単ですが、パーティションスキームを作り直す方法がわかりませんでした。MBR (Master Boot Record) でパーティション作られたUSBメモリは、FAT32でフォーマットされていてもリカバリーには使えないのですが、これをGPTに変更する方法がメニューには見つかりませんでした（Windowsスキルが低くてすみません）。次に示すdiskpartを使う方が確実だと思います。\ndiskpartを使う diskpartもWindows標準搭載の、20年以上昔からあるツールです。CUIでサクサク操作できて良いです。これを用いると、パーティションの設定から完璧に作り直せるので、USBメモリを間違いなく初期化できます。Windowsメニューからdiskpartとタイプすると起動します。USBメモリはUSBポートに挿しておきます。\nMicrosoft DiskPart バージョン 10.0.22000.653 Copyright (C) Microsoft Corporation. コンピューター: XXXXXXXXXX DISKPART\u0026gt; list diskコマンドでUSBメモリの番号を見つけて（ここでは2番）それを選択します。USBメモリは32GBなので、これに間違い無いです。\nDISKPART\u0026gt; list disk ディスク 状態 サイズ 空き ダイナミック GPT ------------ ------------- ------- ------- --- --- ディスク 0 オンライン 465 GB 0 B * ディスク 1 オンライン 232 GB 1024 KB * ディスク 2 オンライン 29 GB 127 MB * DISKPART\u0026gt; select disk 2 ディスク 2 が選択されました。 次に、このUSBメモリを、\ncleanして（ディスク構成情報を削除） GPTに変換して（最小のパーティションができる） primaryパーティションを作って（確認して、選択して） fat32でフォーマットして Eドライブに割り当てて 出来上がったvolumeを確認 します。その様子を下に示します。\nDISKPART\u0026gt; clean DiskPart はディスクを正常にクリーンな状態にしました。 DISKPART\u0026gt; convert gpt DiskPart は選択されたディスクを GPT フォーマットに正常に変換しました。 DISKPART\u0026gt; create partition primary DiskPart は指定したパーティションの作成に成功しました。 DISKPART\u0026gt; list partition Partition ### Type Size Offset ------------- ------------------ ------- ------- Partition 1 予約済み 15 MB 17 KB * Partition 2 プライマリ 29 GB 16 MB DISKPART\u0026gt; select partition 2 パーティション 2 が選択されました。 DISKPART\u0026gt; format fs=fat32 quick 100% 完了しました DiskPart は、ボリュームのフォーマットを完了しました。 DISKPART\u0026gt; assign letter=e DiskPart はドライブ文字またはマウント ポイントを正常に割り当てました。 DISKPART\u0026gt; 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ドライブとして見えます。\nStep3: USBメモリにコピーする 次に、ダウンロードファイルをUSBメモリにコピーします。ここから先はエクスプローラーから操作できます。USBメモリに、以下の2つのフォルダを作ります。\ncom.apple.recovery.boot EFI com.apple.recovery.bootには、Step 1で入手した、\nBaseSystem.chunklist BaseSystem.dmg を入れます。エクスプローラーのコピー・ペーストで行いました。\nまたEFIには、現在macOSを動かしているコンピュータのEFIをそのままコピーしておきました。\n今回試したコンピュータは、ASRock Z690 Steel Legend + 12900K + RX 6600XTの組み合わせです。EFIはこちらに置いてあります（使う場合はシリアル番号などを入れてください）。ディレクトリ構成は結局、以下のようになりました。\ncom.apple.recovery.boot BaseSystem.chunklist BaseSystem.dmg EFI APPLE BOOT OC これでmacOSがインストール可能なUSBメモリが完成しました。\nUSBメモリで起動 このUSBメモリを挿してコンピュータを起動します。大抵は、起動可能なUSBメモリが挿さっているとそこから起動するようですが、BIOSメニューから確認・設定するのが確実かもしれません。USBメモリのルートにあるEFIディレクトリに、EFIファイル一式が正しくコピーできていれば、OpenCoreの起動ボリューム選択画面が表示されます。\nただ、この中にRecoveryイメージはありません。実は、使用しているconfig.plistで、選択メニューに復元イメージが表示されないよう設定してあるためでした。そのように設定されている場合、スペースキーを押すと、全部の候補が現れます。その結果、macOSがインストールされたそれぞれのボリュームの横に、Recovery xxx (dmg)という歯車アイコンの選択肢が現れます。実際のMacにも現れる復元用の起動ボリュームで、これを選択してOSの再インストールなどが可能です。\nそして並びの左端に、今回Windowsだけを使って作成したUSBメモリが現れました。今回使用しているOpenCanopyの設定アイコンでは、他のRecoveryアイコンと違ってオレンジ色です。外付けドライブにあることで、色がオレンジのようです。アイコンの名前がNO NAMEなのは、FAT32のドライブ名のデフォルトがNO NAMEだからです。\nこれを選択して起動すると、リカバリーのメニューが現れます。ここでmacOS Montereyのインストールを選択すると、\nインストーラが起動しました。この先インストールを進めることで、Montereyを動かすことが可能でした。\nまとめ Windowsだけを用いて、macOSをインストールするUSBメモリを作り、動作を確認しました。以前調べた方法はもっと複雑でしたが、今回はあっけなくできてしまいました。macrecovery.pyプログラムを開発された皆さんのおかげだと思います。Mac本体を持っていない人でも簡単にmacOSをインストールできると思います。その場合でも、OSを使わせてもらうお礼にApple製品やサービスを買ってあげてください。\n","date":"2022-07-21T13:59:59+09:00","image":"/uploads/2021/07/cropped-icon512.png","permalink":"/posts/20515/","title":"Windowsだけで作るmacOSインストーラUSB"},{"content":"macOS 13 Venturaを起動してインストールできるUSBメモリを作成しました。配布されているpublic betaから、いつものようにcreateinstallmediaコマンドで作成します。USBメモリのESPには、すでにVenturaが動作しているOpenCoreとそのファイルを入れました。このUSBで起動して、Venturaをインストールできました。\nVentura PBの配布方式変更 macOS 13 VenturaのPB (public beta)を使用して10日近く経過しました。とても安定しているので、もはやメインOSとして使ってます。PBが配布された当初は、マイナーアップデートの時のように、「今すぐアップグレード」ボタンを押すと、本当にすぐにアップデートが開始してしまい、中断できませんでした。\n最近試したところ、いつものメジャーアップデートのように、インストーラプログラムがApplicationsフォルダに格納されるようになってました。本番に備えて改善されたようです。ソフトウェアアップデートのアイコンも、Venturaのものに変わってました。ダウンロードされるデータサイズも12.3GBに増加してます。なので、インストールし直すことにしました。インストールしなおしても、ビルド番号は変更ないようです (22A5295i) 。\nソフトウェア・アップデートで、「今すぐアップグレード」を押すと、ダウンロードが開始され、終了するとインストーラプログラムが起動します。\nここでインストールを中断します。メニューから終了を選んで終了させると、Applicationsフォルダにインストーラが見つかります。中断せずにインストールを完了すると、このインストーラが消えてしまいます。他の場所にコピーをとっておくと良いです。これもいつも通りの動作です。\nインストール用USBメモリを作る この先も、いつものmacOSインストール用メモリ作成の手順と全く同じです。まずはUSBメモリをフォーマットします。ディスクユーティリティでUSBメモリの項目を選んで、「消去」ボタンを押し、「APFS」フォーマット「GUIDパーティションマップ」方式でフォーマットします。名前はなんでも良いのですがUSBとしました。\n次に、ターミナルを開き、VenturaインストーラのResourcesディレクトリに移動します。そこにあるcreateinstallmediaコマンドを実行します。インストール先には、上で作成したUSBメモリを指定します。\n$ 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 \u0026#34;/Volumes/Install macOS Ventura beta\u0026#34; この後、diskutil listコマンドでUSBメモリと起動中のドライブのEFIの場所を探して、それぞれをマウントして、ファインダーでEFIフォルダをコピーします。\n% 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メモリを選択しても良いです。\nこれを選択すれば、Macをリカバリーする画面が現れ、この中からドライブのフォーマットやVenturaのインストールを行えます。\n","date":"2022-07-20T15:41:26+09:00","image":"/uploads/2022/07/cropped-icon1024.png","permalink":"/posts/20535/","title":"macOS Ventura PBの導入用USBを作る"},{"content":"VenturaのPublic Betaをインストールしました。OpenCoreとkext類をnightly build版にアップデートしておけば、macOS 12.4を起動する設定のままで問題なくインストール、起動できました。\nVentura 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です。\n追記 (2022/7/20)：配布方式が変更されたようで、従来のメジャーアップデートと同じくインストーラをダウンロードできるようになりました。こちらをご覧ください。\nmacOS Ventura PBの導入用USBを作る\n以下の説明は古い情報ですので取り消しておきます。\nいつものメジャーアップグレードでは、「今すぐアップグレード」ボタンを押すとインストーラがダウンロードされて起動しますが、そこで中断可能でした。しかしVenturaのベータ版は、アップデートが自動的に進んで、現在のmacOSを書き換えてしまうらしいです。\n【要注意】macOS Venturaベータ版のインストール前に絶対知っておくべき落とし穴【\u0026hellip;\nパブリックベータでも同様と思われたので、新しいSSDを用意して、macOS 12.4とOpenCore 0.8.2で起動するように設定しておきました。そしてSSDからソフトウェアアップデートしました。実際に、ボタンを押すと自動でアップデートが進んでしまいました。\n再起動でループ ダウンロードが終わると再起動します。いつものように、ターゲットのドライブ（ここではVenturaという名前をつけてます）以外に、インストール用のmacOS Installerという暫定ドライブができていて、これから起動しようとします。しかしこの先、再起動してしまい、それが無限に続きます。\nそこでOpenCoreをnightly版に入れ替えました。Kext UpdaterからOpenCore 0.8.3をダウンロードします。そして現在のEFIパーティションのファイルを、nightly build版のものに置き換えました。\nカーネルパニック すると先に進んだのですが、今度はカーネルパニックになりました。\nそこでkext類もnightly build版にしました。これもKext Updaterから取り寄せました。nightly buildsから使用中のkextを取り寄せます。これをEFIパーティションにあるものと差し替えます。\nなおOpenCoreとkextのnightly buildは以下のサイトからも入手できます。コメントで教えていただきました。Kext Updaterで入手するものより新しいバージョンが手に入ります。古いバージョンも入手できるので元に戻す場合にも便利です。\nBuilds\nVenturaが起動 この結果、インストールが進み、いつものアップデートと同じように合計3回再起動し、Venturaが起動しました。バージョンは、13.0 Beta (22A5295i)でした。（ベータ版はスクショ禁止なのでバージョン番号以外の部分をぼかしてあります）\nというわけで、OpenCoreとkextを最新のnightly build版にしておけば、特に設定を変えることなくインストールできました。今のところ問題なく動作してます。このままメインコンピュータとして使い続けることにしました。\nMetal 3対応 システム情報・ハードウェア・グラフィックス／ディスプレイを見ると、RX 6600 XTがMetal 3対応になってました。\nAMD 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 ディスプレイ: ","date":"2022-07-12T16:05:47+09:00","image":"/uploads/2022/07/icon1024.png","permalink":"/posts/20429/","title":"macOS Ventura 13 Beta をインストール"},{"content":"ASRock Z690 Steel Legendで作ったmacOSマシンは安定して動いていたのですが、BIOSを8.01にアップデートしたら起動途中で止まるようになってしまいました。tonymacx86で紹介されていた修正で起動するようになりました。こちらのマシン構成です。（ASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4です。）\nASROCK Z690 STEEL LEGENDのUSBを設定する\ntonymacx86で、BIOSを最新版の8.01に上げると起動が止まることと、その解決策を教えてもらいました。BIOSのネットワーク経由アップデート機能を動かすと、6.03のままで最新と言われていたので気づかなかったのですが、サポートサイトで確認したら6月に最新版が2個も出てました。それで7を飛ばして8.01をUSBメモリにダウンロードして、BIOSの更新を試みました。今まで、BIOS更新しても何の問題もなかったのですが、今回は、tonymacx86で教えてもらったように、\nStuck on [EB|#LOG:EXITBS:START] と言うメッセージが出て止まってしまいました。起動ドライブの選択をした後の、macOSの読み込みに取り掛かるくらいのタイミングです。\nこの問題は、config.plistで、\nBooter -\u0026gt; Quirks -\u0026gt; SetupVirtualMap をTRUEにする ことで解決するとのことです。その通り設定したら、起動するようになりました。OpenCore 0.8.2に上げたことでもありますので、またEFIをアップロードしておきました。ご利用ください。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。\n","date":"2022-07-06T22:59:31+09:00","image":"/uploads/2021/11/image.png","permalink":"/posts/20449/","title":"ASRock Z690 SLを最新BIOS (8.01) に更新"},{"content":"OpenCoreの0.8.2が公開されていたので0.8.1からアップデートしました。今回のアップデートはmacOS 13対応の項目が多いです。config.plistに追加された項目はありませんので、0.8.1のconfig.plistそのままでも動くはずです。\n0.8.2をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.2とmacOS 12.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efi, OpenRuntime.efi, ResetNvramEntry.efiです。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efiです。 ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistの変更点はありませんでした。変更なしで、問題なく起動しました。macOS 13に対応するための修正が施されたようで、間も無くリリースされるpublic betaが楽しみです。\n","date":"2022-07-06T00:34:40+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/20433/","title":"OpenCore 0.8.1から0.8.2に更新: Ventura祭に備える"},{"content":"Intelの12900K CPUを搭載したメインマシンはとても安定しているのですが、「このMacについて」を表示するとプロセッサが不明だと表示されます。弊害はないのですが、見た目が悪いので、それっぽく表示されるように直しました。\nプロセッサ表示なんて飾りです 「このMacについて」のプロセッサの表示は単なる飾りで、不明と表示されても何の問題もないらしいです。不明と表示されていてもsysctlコマンドで調べると、以下のように\n% sysctl machdep.cpu.brand_string machdep.cpu.brand_string: 12th Gen Intel(R) Core(TM) i9-12900K 搭載CPUが正確に認識されていることがわかります。とはいえ、「不明」と表示されるのはみっともないので、それっぽい表示が出るように直すことにしました。対象のマシン構成は以下です。\nASRock 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で、その場合、最もそれらしい値を自動的に提示するようです。大抵の場合は、デフォルトの自動設定で問題ありませんでした。\n現在のマシンでも、自動設定でIntel Core i9プロセッサであると正しく自動認識されていると考えられます。それでも「不明」と表示されてしまうのは、Appleの想定外のコア数で使用していることが原因のようです。12900はPコアが8、そのHTが8、Eコアが8ありますが、OpenCoreの機能でこれらを24コアと認識させて使ってます。\n24コアのCore i9プロセッサは実存しないので、不明と表示されるようです。\nコアを減らしてみる このことを確認するために、BIOS設定でコア数を減らしてみます。Appleの想定内のコア数ならば、正しく表示されるはずです。そこで下のようにEコアを無効にして起動させます。\nするとPコアだけになるので、コア数が8、スレッド数が16になりました。\nコア数が8のCore i9プロセッサは実存するので、「このMacについて」のプロセッサ表示が正しく行われるようになりました。\nXeonだと思わせる 飾りでしかない「このMacについて」表示のためにEコアを諦めるのは本末転倒ですので、BIOSでEコアを復活させて、24コア設定に戻します。これで「不明」の表示に戻ってしまいました。そこで今度は、CPU種別自動判定を停止して、24コアでも問題の無いプロセッサに手動で設定することにします。\nAppleのSMBIOSヘッダ定義ファイルを見ると、0以外に使用できるProcessor Typeの値がわかります。今回、関係しそうな値は以下のようになってます。コメントの説明によると、Core i9は6/8/10コアが存在することになっていて、当然ですが24コアはありません。その代わりXeon Wならば24コアの構成があり得ることになってます。iMac Proに搭載されているCPUです。\n// 155// Apple Processor Type Information - Processor Types. 156// 157 enum { ... 138// \u0026lt;0F01\u0026gt; 08 cores Intel Xeon W Intel Xeon W 139// \u0026lt;0F01\u0026gt; 10 cores Intel Xeon W Intel Xeon W 140// \u0026lt;0F01\u0026gt; 12 cores Intel Xeon W Intel Xeon W (10.15+) 141// \u0026lt;0F01\u0026gt; 14 cores Intel Xeon W Intel Xeon W 142// \u0026lt;0F01\u0026gt; 16 cores Intel Xeon W Intel Xeon W (10.15+) 143// \u0026lt;0F01\u0026gt; 18 cores Intel Xeon W Intel Xeon W 144// \u0026lt;0F01\u0026gt; 24 cores Intel Xeon W Intel Xeon W (10.15+) 145// \u0026lt;0F01\u0026gt; 28 cores Intel Xeon W Intel Xeon W (10.15+) 146// \u0026lt;1001\u0026gt; 06 cores Intel Core i9 Intel Core i9 147// \u0026lt;1001\u0026gt; 08 cores Intel Core i9 Intel Core i9 (10.15+) 148// \u0026lt;1001\u0026gt; 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に設定することにしました。\nこの結果、「このMacについて」のプロセッサ表示がXeon Wになりました。コア数は24と表示されました。\n「このMacについて」のCPU表示をXeon Wに変更しても、sysctlコマンドは引き続きCPU種類を正しく認識していました。\n% sysctl machdep.cpu.brand_string machdep.cpu.brand_string: 12th Gen Intel(R) Core(TM) i9-12900K ","date":"2022-06-17T12:31:28+09:00","image":"/uploads/2022/06/unknown.png","permalink":"/posts/20361/","title":"「このMacについて」表示でCPUが不明なことへの対処"},{"content":"OpenCoreの0.8.1が公開されていたので0.8.0からアップデートしました。追加された項目はありませんので、0.8.0のconfig.plistでもそのままでも動くはずです。\n0.8.1をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.1とmacOS 12.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi。これらに加えて、新しく追加されたResetNvramEntry.efiも入れておきました。 EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。Xplistを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistの変更点は以下でした。\nMisc/SecurityのAllowNvramResetが消えてました。今まではtrueに設定していました。これはOpenCoreの起動時のピッカーにNVRAMをリセットするアイコンを出してくれていた機能です。アイコンを出す機能は、Driversフォルダの中に入れるResetNvramEntry.efiが担うようになったようです。/UEFI/Drivers/の中で、ResetNvramEntry.efiに関係するItemのEnabledをtrueにしておくと、今まで通りReset NVRAMアイコンが出ます。\nMisc/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になってました。コメントアウトなので問題ないはずですが、以前にこれを残しておいたらブラックスクリーンになりました。消しておくと良いです。 以上の設定で、引き続き問題なく起動しました。\nASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.4で動かしているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。\n","date":"2022-06-15T13:19:24+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/20330/","title":"OpenCore 0.8.0から0.8.1に更新"},{"content":"macOS Monterey 12.4が配布されていましたので12.3.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.4の情報はまだありません）。\nhttps://support.apple.com/ja-jp/HT212585 アップデートしたマシンは以下です。OpenCore 0.8.0で起動していて、kext類は最新です。\nASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT システム環境設定のソフトウェアアップデートに、12.4のアップデートの通知が来ていました。\nアップデートは、PodcastとStudio Displayの機能強化と不具合に対応したものらしいです。これだけ見るとあまり関係なさそうですが、バージョン番号が大きく上がるマイナーアップデートなので期待したいところです。「今すぐインストール」ボタンを押すと、2.29GBのファイルがダウンロードされます。\nその後、自動的に4回再起動して、12.4に更新されました。今回の再起動過程では、1回目の再起動にはmacOS Installerという名前のボリュームが現れ選択されていて、2回目以降はこのボリュームは消えて、通常の起動ボリューム（Macintosh HDという名前にしてます）が選択されました。\nいつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.4が起動しました。ビルドは21F79です。\n特に問題なく動いています。使用しているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。\n","date":"2022-05-17T21:52:59+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/14669/","title":"Monterey 12.4 にアップデートする"},{"content":"ASRock Z690 Steel Legendをメインで使うことにして、ケースに入れたので、USBの設定を見直しました。15個制限があるので、使用するポートを選別して調整する必要があります。これまでの経緯は以下をご覧ください。\nメインマシンをASRock Z690 Steel Legendに移行\nASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす\nUSBポートの調査（前回） 以前の記事で書きましたように、バックパネルにアサインされているポート類は、以下のように割り当てられてました。ポート数は合計で12本です。Ethernetコネクタの下の２個のUSBポートのHSとSSの数字が入れ替わってますが、この通りでした。\nまた、マザーボード上の内部コネクタに関しては、以下の2ヶ所を調べてありました。\nマザーボード上のM.2 E keyソケットに接続されたUSBはHS14でした また、マザーボード上のUSB Type-Cコネクタは、HS01とSS01でした ちなみにマザーボードの電源を切った時に、ほとんどのUSBコネクタに5Vが供給されるのですが、PS/2コネクタの下のUSB3_1_2だけには電力供給されないことがわかりました。\nUSBポートの全調査（今回） 今回は、マザーボードの他の内部USBポートも全部調べました。前回作ったUSBPorts.kextを書き換えて、キーボード類が接続されているHS14以外を、未確認のポート番号に入れ替えました。これで再起動すれば、未確認のポートが機能します。次に内部コネクタに、以下のようなアダプタを取り付けて、USBメモリなどのデバイスを取り付けます。その時の挙動をHackintoolなどで調べることで、ポート番号とコネクタの関係を知ることができます。\nその結果、以下のように配線されていることが判明しました。\n以上をまとめると、以下のリストになります。\nHS01:マザーボード上の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:（不明） HS08とSS08には、ASMedia社のUSB 3.0ハブ用チップのASM107xが接続されていると、Hackintoolに表示されました。ASM107xはマザーボードに搭載されていて、ASRockのマニュアルに記されたボード上のUSB 3.0コネクタ、USB3_5_6とUSB3_7_8に接続されているようです。\nHS13には、ASRock LED Controllerというデバイスが接続されていました。名前から推測するに、マザーボードの電飾LEDコントローラに接続されているようです。Windowsのアプリケーションから電飾の設定を行う際に使用されるのだと思います。macOSでは使えません。\n利用状況に合わせて調整 発見されたUSBポートが全部利用できれば良いのですが、macOSには最大15口までの制限があります。なので、ここから使用するポートを15個選んでUSBPorts.kextに設定します。どのポートを使うかは、マシンの構成次第です。マザーボード上の内部ポートを一切使わなければ、バックパネルのポートだけを活かせば良いです。でも、PCケースや5.25インチ拡張ベイなどで内部ポートを使用するならば、調整する必要があります。\nBluetoothで使用するポート：HS14 現在の構成では、BCM94360NGをマザーボード上のM.2 E keyソケットに取り付けて、WiFiとApple Magic Keyboard/Trakpadを使用しています。設定不要で機能する便利な無線アダプタです。BCM94360NGのBluetoothチップがHS14にUSB接続されているので、HS14は必須です。\nケースで使用するポート：HS/SS08 PCケースにUSB3.0コネクタが2個あり、これをマザーボード上のUSB3_7_8と刻印された内部USB 3.0コネクタに接続しています。上記で説明したように、このコネクタはASM107xハブに接続されてます。なのでHS08, SS08は使用したいです。\n拡張ベイで使用するポート：HS/SS06, 07, 08, HS12 5.25インチ拡張ベイに、USBハブ＋SDカードリーダーを取り付けてます。\nこれが、マザーボード上のUSB3_5_6とUSB_1_2、バックパネルのEthernet下Type-Aに接続されてます。なので、HS06, HS07, HS08, HS12, SS06, SS07, SS08は活かしたいです。\n拡張スロットに引出すポート：HS01, SS01 マザーボード上の内部Type-Cコネクタは、延長ケーブル経由で拡張スロットに引き出しています。なのでHS01とSS01は活かしたいです。\n使用を断念するポート：HS/SS05, SS04 以上のポートと、残りのバックパネルポートを全部活かそうとすると、18個になります。使用できるポート数が15なので、3個の使用を諦めないといけません。高機能・高性能なポート、例えばType-CやUSB 3 Gen2のポートは活用したいところです。除外するとしたら、普通のUSB 3ポートです。\nそこで、PS/2コネクタの下の２個のType-Aコネクタのうち、上のポートは使用を諦めました。また、PS/2コネクタ下の下のポートは、USB 2.0専用とすることにしました。HS05, SS05, SS04を諦めたことになります。PS/2下のコネクタは、通常はマウス・キーボード用に使われることが多いと思います。ここがUSB 2.0になっているマザーボードも多いので、2.0専用にしました。また前述のように、このポートは電源offの時に5Vが給電されません。使いにくい場合もあります。\nということで、上記のリストで番号が太字になっているポートを使用することにしました。その内容になるよう、USBPorts.kextの中のinfo.plistを書き換えました。\n作成したUSBPorts.kextをこちらに置いておきました。皆さんの使用状況に合わせて、この中のinfo.plistの内容を変更して使ってください。\nまとめ 仮組みで使ってたZ690マシンをケースに入れたことで、マザーボード上の内部USBを使用することになりました。それらが使用できるように、USBPorts.kextを調整しました。macOSには15個制限があるので、一部のバックパネルUSBコネクタを諦めました。厄介な制約ですが、苦労して調整するのも楽しく思えてきました。\n","date":"2022-05-02T00:14:20+09:00","image":"/uploads/2021/11/image.png","permalink":"/posts/14626/","title":"ASROCK Z690 STEEL LEGENDのUSBを設定する"},{"content":"Alder Lake-S 12900Kを取り付けたASRock Z690 Steel Legendをメインマシンとして使うことにしました。そこで、今まで使っていたASRock Z590 Extremeマザーボードと交換しました。\n古いマシンのSSDが不調に Z590 Comet Lake-S で動かすmacOSメインマシンは、長らく安定していて全く問題ありませんでした。なので、興味本位で作ってしまったZ690マシンは、ずっとバラック状態で、サブマシンとして使ってました。\nそのZ590メインマシンが、ここ1~2ヶ月ほど不調でした。数回に一回くらいの頻度で起動しません。やり直せば問題なく起動して使えるので、BIOS不調かなくらいに思ってました。それがとうとう、ログインできなくなりました。パスワード入力画面は出るのですが、データが壊れていてログインできないという内容のダイアログが出て起動できなくなりました。別のドライブから起動してDisk First Aidをかけてみると、パーティション構成に問題があるとの診断です。使用していたのはかなり前から使っている2.5インチSATA SSDでした。おそらくはフォーマットし直して復旧できると思われます。データはクラウドとTimemachineでバックアップしてあるので復旧は容易です。でもまた壊れるかもしれません。少なくともSSDは交換した方が良さそうです。\nそれで良いきっかけができたと思い直して、メインマシンからZ590マザボを取り外して、Z690マザボに交換することにしました。\n起動SSD交換 Z690マザーボードには、1TB容量のWDのM.2 SSDが取り付けてありました。これにOpenCore 0.8.0とmacOS Monterey 12.3.1が入れてあり、問題なく動いています。なので、マザーボード交換に伴い、起動ドライブもこのM.2 SSDに変更します。一方で、起動しなくなった古い2.5インチSATA SSDは、いつの間にかディスクユーティリティからも見えなくなってました。\nCPUクーラー交換 Z690マザーボードで最初に組んだ当時は、Alder LakeのLGA 1700対応クーラー製品が出揃ってませんでした。それでいち早く対応したCorsairの簡易水冷クーラーを使用しました。\n一方で、メインマシンのZ590マザーボードには、Noctuaの空冷クーラーをつけてました。ケースには水冷ラジエータを取り付ける場所が確保できなかったので、引き続きこの空冷クーラーを使うことにして、これに交換しました。\n現在売られているクーラー製品にはLGA 1700のアダプタも付属しています。でも昔に買った製品だったので、対応アダプタが必要です。NoctuaのLGA 1700アダプタには、サイズ違いのMP78とMP83があります。また、通常モデル用の銀色とchromax.black用の黒色があります。なので、色違い・サイズ違いの以下に示す4種類があります。色は間違えても取り付けられますが、サイズは互換リストを見て確認する必要があります。今回はMP78の黒色を入手しました。\nグラフィックスカード交換 今まで使用していたZ590にはRadeon RX 6600を取り付けてました。\n一方で、Z690マザーボードにはRadeon RX 580がついていました。これも交換して、今まで通りRX 6600を使うことにしました。RX 6600を使う場合には、config.plistのboot-argsにagdpmod=pikeraを追加します。 RX 580では不要でした。その結果現在の設定は、以下のようになってます。\n-v keepsyms=1 debug=0x100 -wegnoigpu agdpmod=pikera ちなみに-wegnoigpuは、WhateverGreen.kextに、iGPUを使わないように指示するオプションです。Alder LakeのiGPUはmacOSでサポートされていないので、ここで念の為に指定しています。\n拡張カード 昔ながらのケースに、複数のHDD、光学ドライブ、SATA拡張ベイなどを取り付けているので、SATAを8本使ってました。Z590 ExtremeにはSATAが6本しか搭載されていなかったので、SATA拡張用のPCIeカードを使用していました。Z690 Steel Legendは、なんとSATAが8本ついています。拡張スロットの本数も多く、拡張性の高いマザーボードだと思います。なので、SATA拡張カードは取り外すことにしました。\nまた、ほとんど使ってないのですが、IEEE 1394カードを取り付けてました。これは今まで通り使えるよう移行しました。\nマザーボード交換 説明が前後しますが、CPUクーラや拡張カード類を取り付ける前に、マザーボードを交換しました。同じASRock製品で、世代が近いこともあり、ボード上のケースファンコネクタ、USBコネクタ、オーディオコネクタなどの内部コネクタの位置がよく似ています。それでケース内の配線をほとんど変更することなく、大体同じ場所に取り付けることができて、とても助かりました。USB 3.0コネクタなどは嵩張るので、取り付け方向が90度違うと配線の取り回しが面倒になりますが、それも一緒なので楽でした。\nまとめ 起動SSDが不調になったのをきっかけに、メインマシンのマザーボードをZ690に交換しました。12900Kを使っているので、コアがたくさん見えて満足感があります。\nZ590マシンは、同じComet Lake搭載のiMacに合わせて、機種IDをiMac20,1に設定してありました。Z690マシンは、対応するCPU搭載Macが存在しないので、汎用性の高いiMacPro1,1に設定しました。そのおかげで、SafariからAmazon Primeビデオが再生できるようになりました。iMac20,1は本来Apple T2チップを搭載している機種なので、これに設定すると再生できないようです。\n今後普段使いする過程で、不具合など見つけて対応していきたいと思います。今のところ、ケースのコネクタに接続したUSBポートの一部が機能しない問題があります。USBの設定を見直したいです。\n","date":"2022-04-24T18:09:33+09:00","image":"/uploads/2021/11/image.png","permalink":"/posts/14599/","title":"メインマシンをASRock Z690 Steel Legendに移行"},{"content":"OpenCoreの0.8.0が公開されていたので0.7.9からアップデートしました。新しい項目はデフォルトのままで問題なかったので、0.7.9のconfig.plistでもそのままでも動くはずです。\n0.8.0をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.8.0とmacOS 12.3.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock 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ファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistの変更点は以下でした。\nKernel/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に合わせて無しのままにしておきました。 以上の設定で、引き続き問題なく起動しました。\nASRock Z690 Steel Legend + 12900K + Radeon RX 6600 XT + macOS Monterey 12.3.1で動かしているESPのファイル一式をここに置いておきました。機種IDはiMacPro1,1に設定してあります。シリアル番号などは各自で設定してください。\n","date":"2022-04-24T00:04:00+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/14589/","title":"OpenCore 0.7.9から0.8.0に更新"},{"content":"macOS Monterey 12.3.1が配布されていましたので12.3からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.3.1の情報はまだありません）。\nhttps://support.apple.com/ja-jp/HT212585 アップデートしたマシンは以下です。OpenCore 0.7.9で起動していて、kext類は最新です。\nASRock Z590 Extreme + 10900K ASRock Z690 Steel Legend + 12700K システム環境設定のソフトウェアアップデートに、12.3.1のアップデートの通知が来ていました。\nアップデートは、2018 Mac mini外部ディスプレイとBeatsヘッドフォンの不具合に対応したものらしいです。そのほか、バグ修正とセキュリティアップデートが含まれているようです。脆弱性にも対応しているようなので、アップデートを急いだ方が良いと思われます。「今すぐインストール」ボタンを押すと、自動的に3回再起動して、12.3.1に更新されました。いつものアップデートでは、起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されるのですが、今回は、macOS Installerという名前のボリュームが現れました。\nいずれにしても、いつものようにデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.3.1が起動しました。ビルドは21E258です。\nZ690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートできました。\n","date":"2022-04-03T14:40:59+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/14560/","title":"Monterey 12.3.1 にアップデートする"},{"content":"macOS Monterey 12.3が配布されたので12.2.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.3の解説はありません）。ユニバーサルコントロールが使えました。\nhttps://support.apple.com/ja-jp/HT212585 アップデートしたマシンは以下です。OpenCore 0.7.9で起動していて、kext類は最新です。\nASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + BCM94360NG システム環境設定のソフトウェアアップデートに、12.3のアップデートの通知が来ていました。\nアップデートにより、\n「ユニバーサルコントロール（ベータ）」が追加 「空間オーディオ」「絵文字」が改良 Podcastのエピソードが追加 Safariの翻訳がイタリア語と中国語に対応 ショートカットがリマインダーでのタグに対応 保存済みパスワードにメモを追加可能 バッテリ容量測定の精度改善 TVアプリと写真アプリのバグに対応 などが実現されるようです。中でも、ユニバーサルコントロールは目玉機能で、世間で注目されてます。Hackintoshで動くのかどうか、是非とも試したいところです。\n早速アップデートしました。「今すぐインストール」ボタンを押すと、4.38GBのファイルがダウンロードされ、その後、自動的に3回再起動して、12.3に更新されました。いつもと同様に、再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。\n再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.3が起動しました。ビルドは21E230です。\nユニバーサルコントロールを試す 早速、話題のユニバーサルコントロールを試しました。これを使うためには、システム環境設定のディスプレイから、ユニバーサルコントロール…ボタンを押して設定します。現れるチェックボックスを、とりあえず全部有効にします。\niPadを使う場合は、これも最新のiPadOS 15.4にアップデートしておきます。次に、iPadの「設定」を開き、「一般」から「AirPlayとHandoff」を開いて「カーソルとキーボード」をオンにしておきます。\n他のマシンの用意ができたら、macOSのディスプレイから「ディスプレイを追加」を選びます。これで追加するマシンを選べます。以下の例では、中央が、今回12.3をインストールしたASRock Z590 Extreme + 10900Kマシンです。左がMacBookで、右がiPadです。\nこの配置の場合、ASRock Z590 Extreme に接続したトラックパッドのポインターを、画面左に持っていくとMacBookにポインターが移動します。画面右に持っていくとiPadに移動します。それぞれのマシンに移動した後、テキストが入力できる場所でクリックすると、そこにカーソルが現れ、キーボードから入力できるようになります。とても便利です。ASRock Z590 Extremeの機種設定はApple T2セキュリティチップ搭載機種のiMac20,1に設定しています。このことでユニバーサルコントロールが動かないのではと心配していましたが、全く問題ありませんでした。\nMacとの連携は、今までも、画面共有をすればほぼ近い操作が可能なので、それほど大きな変化ではないかもしれないです。でも、iPadとの連携はすごいです。iPadでの文字入力が楽になるので、iPad用のキーボードを買う必要が無くなったかもしれないです。また、写真ファイルなどをドラッグ＆ドラッグすると、その写真を貼り付けられます。ファイルの移動も簡単にできます。今のところ連携できるのは、Mac同士、もしくはMacとiPadだけのようです。この先、MacとiPhoneが連携できたら、ますます便利になるのではと思いました。\n","date":"2022-03-16T18:29:26+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/14524/","title":"Monterey 12.3 でユニバーサルコントロールを使う"},{"content":"OpenCoreの0.7.9が公開されていたので0.7.8からアップデートしました。今回もほとんど更新されていないので、0.7.8のconfig.plistでもそのままでも動くはずです。\n0.7.9をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.9とmacOS 12.2.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.2.1 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistの変更点は以下だけでした。大きな変更はありません。\nMisc/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を見ると、他にも多少の変更があるようですが、デフォルト値には関係のないようでした。\n","date":"2022-03-15T22:41:52+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/14520/","title":"OpenCore 0.7.8から0.7.9に更新"},{"content":"OpenCore 0.7.7からAlder Lake CPUのコアが全部使えるようになり、性能をフルに引き出せるようになりました。それで12900Kを使って、どれくらいのスコアが出るのか確認しました。マルチコアでM1 Maxの1.2倍くらいでした。\nマシン構成 使用したマシンは、以下で紹介したASRock Z690 Steel Legend WiFi 6Eを使ったマシンです。\nASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす\n今までは12700Kを使っていましたが、これを12900Kに差し替えました。同じシリーズのCPUですので、BIOSやconfig.plistの設定は何も変更しなくてもそのまま問題なく動作しました。アクティビティモニターでコア活動状況を見ると、24本の棒グラフが並び、圧倒的です。\nHackintoshでAlder Lakeの全コアを使用する記事は以下で紹介しました。\nOpenCore 0.7.7でAlder Lake全コアに対応予定\nmacOSに全コアを使ってもらうために、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個コアだと表示されます。\nGeekbench 5でベンチマーク Geekbench 5でベンチマークを取りました。シングルは2000以上、マルチは15500以上のスコアが出ます。詳細を見ると、24コアのCPUになっています。HTもEコアも全部通常のコアに見えているようです。\n何度か測定していると、たまにシングルが1800くらいの時があります。この時、もしかしたら測定対象がEコアに当たったのかもしれません。ただ、そのようなスコア低下はほとんど発生しないので、Pコアが空いていればそちらに割り当てられるのかもしれないです。また、シングルが低下した場合でもマルチスコアは変わりません。\nGeekbenchブラウザのサイトにあるM1 Maxのスコアと、今回測定した12900Kのスコア（5回の平均）を比べたのが下の図です。M1 Maxと比較すると、シングルで1.13倍、マルチで1.23倍くらいです。\nGeekbench 5スコアの比較\nGeekbenchブラウザのページで、12900Kで作ったhackintoshらしきスコアを見ても、マルチスコアが大体15000前後のようです。中には20000越えなスコアもありますが、おそらくはオーバークロックしているのだと思われます。\nCinebench R23でベンチマーク コメントで要望いただきましたのでCinebenchのスコアも紹介しておきます。1回だけの実行結果です。マルチコアのベンチマークでは24個のブロックに分かれて並列描画されます。\n結果は、 CPU (Single Core)が1825 pts、CPU (Multi Core)が26520 ptsでした。\nASCII.jpの記事によると、M1 MaxのCinebench R23のスコアは、シングルで1532, マルチで12372だそうです。この値を比較すると、12900KはM1 Maxのシングルで1.2倍、マルチで2.14倍のスコアになりました。\nCinebench R23スコアの比較\n","date":"2022-02-13T00:08:04+09:00","image":"/uploads/2021/12/alderlake.jpg","permalink":"/posts/14406/","title":"Alder Lake 12900Kの24コアをmacOSで使う"},{"content":"macOS Monterey 12.2.1が配布されたので12.2からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.2.1の解説はありません）。\nhttps://support.apple.com/ja-jp/HT212585 アップデートしたマシンは以下です。OpenCore 0.7.8で起動していて、kext類は最新です。\nASRock Z590 Extreme + 10900K ASRock Z690 Steel Legend + 12700K システム環境設定のソフトウェアアップデートに、12.2.1のアップデートの通知が来ていました。\nアップデート内容は、「Intelプロセッサを搭載したMacコンピュータでBluetooth周辺機器に接続しているとスリープ中にバッテリーを使い切ってしまうことがある問題」を修正したとあります。12.2からすぐのタイミングですし、急いでバグに対応したようです。\n12.2で動いているMacBookシリーズをスリープさせると、その間も電池の消耗が進んで数時間で電池切れになってしまう症状がネットで話題になってました。インテルだけでなくM1でも同様な症状が発生すると言われてました。スタパ齋藤氏の記事によると\n[スタパ齋藤のApple野郎] 寝てくれっ、M1 Mac mini、徹夜しないでくれっ!!!\nM1 Mac miniで、Bluetoothがオンになっているとスリープからすぐに目覚めてしまうそうです。なので、スリープからすぐに目覚めてしまうことが問題のようです。スリープからすぐに目覚める現象は、hackintoshでしばしば遭遇しますが、実機でも発生するようです。ちなみに、手元のM1 MacBook Airで試したところでは、スリープ状態でバッテリーが消耗する現象は見られませんでした。色々複雑な条件のもとで発生する不具合なのかもしれないです。いずれにしてもそれが解決されることは嬉しいです。\nなので、早速アップデートしました。「今すぐインストール」ボタンを押すと、自動的に3回ほど再起動して、12.2.1に更新されました。いつもと同様に、再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。\n再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.2.1が起動しました。ビルドは21D62です。\nZ690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートして全コア、全スレッドで機能しました。\n","date":"2022-02-11T14:35:46+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/14412/","title":"Monterey 12.2.1 にアップデートする"},{"content":"OpenCoreの0.7.8が公開されたので0.7.7からアップデートしました。今回はほとんど更新されていないので、0.7.7のconfig.plistがそのままでも動くはずです。\n0.7.8をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.8とmacOS 12.2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock Z690 Steel Legend + 12700K + Radeon RX580 + macOS Monterey 12.2 ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.2 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistに変更はありませんでした。ただ、\nNVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82にSystemAudioVolumeDBが0.7.7から追加されていたのですが、Sample.plistから無くなってました。マニュアルには記載がありますし、残していても警告は出ませんでしたのでそのまま残してあります。0.7.7のSample.plistの値がE2だったのでそのままです。 ","date":"2022-02-08T18:43:30+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/14401/","title":"OpenCore 0.7.7から0.7.8に更新"},{"content":"macOS Monterey 12.2が配布されたので12.1からアップデートしました。問題なくアップデートできました。アップデート情報は以下にあります（現時点では12.2の解説はありません）。\nhttps://support.apple.com/ja-jp/HT212585 アップデートしたマシンは以下です。OpenCore 0.7.7で起動していて、kext類は最新です。\nASRock Z590 Extreme + 10900K ASRock Z690 Steel Legend + 12700K システム環境設定のソフトウェアアップデートに、12.2のアップデートの通知が来ていました。\nアップデート内容はバグ修正とセキュリティ改善で、新機能が増えたわけではないようです。「今すぐインストール」ボタンを押すと、1.94 GBのファイルがダウンロードされました。その後、インストールを開始すると、自動的に3回ほど再起動して、12.2に更新されました。再起動の際のOpenCore起動ボリューム選択には、通常の起動ボリュームと同じ名前の選択肢が現れて、そちらがデフォルト選択されています。\n再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.2が起動しました。ビルドは21D49です。\nZ690マザーボードにAlder Lake CPUを組み合わせたマシンでも、問題なくアップデートして全コア、全スレッドで機能しました。\n","date":"2022-01-27T12:22:41+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/14362/","title":"Monterey 12.2 にアップデートする"},{"content":"AMD Radeon RX 6500 XTの販売が始まりました。6000シリーズの最下位モデルで、価格は3万円台前半くらいです。GPUが高騰している昨今にしてはそこそこ安価です。macOSで使えると良いのですが、残念ながら動かないのではないかと言われています。\n6000シリーズのGPU型番は、Navi 21, 22, 23, 24です。今回のRX 6500 XTはNavi 24を搭載しているそうです。なので、GPU型番とRX 6000シリーズの関係は以下になります。\nNavi 21は RX 6800, RX 6900シリーズに搭載 Navi 22は RX 6700シリーズに搭載 Navi 23は RX 6600シリーズに搭載 Navi 24は RX 6500 XTに搭載 macOSはBig Sur 11.4からRX 6900 XT, RX 6800 XT, 6800に対応し、\nBIG SUR 11.4にアップデートする (Navi 21対応)\nMonterey 12.1からRX 6600 XT, 6600に対応しています。\nmacOS 12.1からRadeon 6600XTが使える\nしかし、6700, 6700 XTは動きませんでした。macOSにはNavi 21, 23のドライバが含まれているものの、Navi 22のドライバは用意されていないためと考えられます。なので、Navi 24を搭載する6500 XTに関しても、6700シリーズと同様に、macOSが動かないと予想されています。\n今後サポートされる可能性 将来のmacOSで6500 XTがサポートされる可能性も低いと思われます。\n現在、Navi 21を搭載したMac Pro用のグラフィックスカードはAppleから販売されています。Navi 23ベースの製品はまだ発売されていません。今後、最も安価なグラフィックスカードとして発売されるのではないかと思われます。でも、なかなか発売されないので不透明です。ドライバーだけでも提供されているのは、幸運なことかもしれません。\nそう考えると、さらに下位モデルのNavi 24用のドライバは、今後も提供されないのではないでしょうか。Navi 23はM1 MaxのiGPUより一回り性能が良いので、これを搭載する意味はありました。でも、M1のiGPUより性能が劣るNavi 24をサポートする必要性は低いと考えられるからです。\n","date":"2022-01-23T00:07:57+09:00","image":"/uploads/2022/01/rx6500xt.jpg","permalink":"/posts/14352/","title":"新製品Radeon RX 6500 XT はmacOSで動く？"},{"content":"OpenCoreの0.7.7が公開されたので0.7.6からアップデートしました。Alder Lakeへのサポートが充実しました。config.plistには大きな変更は無いので、0.7.6のconfig.plistがそのままでも動くはずです。\n0.7.7をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.7とmacOS 12.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock Z690 Steel Legend + 12700K + Radeon RX580 + macOS Monterey 12.1 ASRock Z590 Extreme + 10900K + Radeon RX 6600 XT + macOS Monterey 12.1 .efiファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistの変更は以下でした。\nNVRAM/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%くらいばらつきます。でもマルチコアスコアは高速になりました。\n","date":"2022-01-12T23:38:04+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/14311/","title":"OpenCore 0.7.6から0.7.7に更新"},{"content":"ASRock Z690 Steel Legendで、スリープからすぐ目覚めてしまう現象が発生してましたが、これを止めることができました。USB関係の問題でした。他のCPU世代の自作でもよく見かける現象ですので、参考になると思います。以下の記事の続きです。OSはMonterey 12.1です。\nASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす\nスリープからすぐに目覚める問題 Appleメニューから、もしくは、無操作のタイムアウトからスリープに入ると、以下のような現象が発生してました。\nスリープに入る 画面が暗くなる。でもCPUファンは動いている。 1分ほどそのままの後、画面が復帰してログイン画面に戻る。 という現象です。スリープ復帰後は、引き続き正常に使用できます。また、シャットダウンは正常に行えます。\nいろいろ試してみたところ、バックパネルのUSB Type-Aコネクタに接続されたデバイス（接続していたのはキーボード用無線USBアダプタとUSBメモリーです）を全部外すと、スリープから目覚めなくなることがわかりました。何かがUSB Type-Aコネクタに挿さっていると、1分ほどでスリープから目覚めてしまいます。\nまた、バックパネルのUSB Type-Cに同じキーボードとUSBメモリを接続したところ、この場合は正常にスリープし、そのキーボードを押すと復帰します。Type-Cには直接接続できないので、この確認には、MacBookで使うType-Cハブを使いました。\nさらには、マザーボード搭載のM.2 E KeyコネクタのUSBも問題ないようで、そこに取り付けたBCM94360NGにBluetooth接続するApple Magic Keyboardなどは問題を起こしません。接続していてもスリープに入りますし、キーを押すとスリープから復帰します。\nどうも、バックパネルのType-Aコネクタが問題を起こしている様子です。\nUSBがスリープを阻害する問題は、hackintoshでよく経験します。昔の記事ですが、こちらではZ390ボードが目覚める原因がUSBハブでした。\nUSB機器がスリープを阻害することがあります\nOpenCoreのバニラガイドを見ると、macOSのUSBドライバに不備があって、スリープ時の電力管理に問題があるらしいです。おそらく、Macの実機で動けば良いので、標準仕様を満たした設計にはなっていないのでしょう。それでパッチを当てて修正する手法が考えられているようです。まずはそれを試しました。\n方法1：USB機能にパッチする USB機器がスリープを邪魔しないようにするパッチがいくつか考えられています。tonymacx86のZ690ビルドのスレッド\nhttps://www.tonymacx86.com/threads/z690-chipset-and-alder-lake-cpus.316618/ https://www.tonymacx86.com/threads/gigabyte-z690-aero-g-i5-12600k-amd-rx-6800-xt.317179/ で配布されているZ690用のEFIファイル類を見ると、二つの方法が試みられていました。一つは、\nSSDT-USBW.amlを使い、 USBWakeFixup.kextを使う 方法です。上記のバニラガイドでも紹介されている方法です。USBデバイスがスリープを妨げることを防ぐための措置らしいです。でも効果がありませんでした。カスタマイズする必要があったのかもしれないです。\nもう一つは、\nSSDT-GPRW.amlを使い、 Method(GPRW,2,N)にパッチを当てる 方法です。パッチは、config.plistのACPI/Patchに、以下のように書いておきます。USBとBluetoothがスリープを妨げないようにする処置のようです。\n生のplistの部分は、以下になります。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change Method(GPRW,2,N) to XPRW, pair with SSDT-GPRW.aml\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Enabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;R1BSVwI=\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;WFBSVwI=\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; こちらは機能しました。これはUSBデバイスをスリープ解除に使えなくする力技のパッチです。なので、どんなUSBデバイスが挿さっていても、スリープから目覚めなくなりましたが、一方で、USBキーボードやBluetoothキーボードを操作しても、スリープから復帰しなくなります。電源スイッチを押して初めて復帰します。電源スイッチが遠いとちょっと不便なので、なんとかしたいところです。\n方法2：USBPorts.kextを書き換える そこでこの方法を考えました。まずは気になったところが、Type-Aコネクタが使用されている時だけ、スリープから目覚めてしまうという現象です。Type-CやM.2コネクタのUSBデバイスは問題を起こしません。\nUSBコネクタの種類は、EFIの中で設定してmacOSに知らせています。現在使っている方法は、USBPorts.kextを作って、その中のInfo.plistで設定する方法です。\n15個制限のためのUSBPorts.kextをHackintoolで作る\nHackintool.appを使う場合は、以下のようにしてConnectorの種類を設定します。\nConnectorとして選択できるのは、USB2, USB3, TypeC+Sw, TypeC, Internalの5種類です。それぞれの選択で、Info.plistのUsbConnectorキーに0, 3, 9, 10, 255が割り当てられます。hackintoolのソースによると、この5種類を含めて、以下の数値が用意されています。\nkTypeA\t= 0x00,\t// Type ‘A’ connector kMiniAB\t= 0x01,\t// Mini-AB connector kExpressCard\t= 0x02,\t// ExpressCard kUSB3StandardA\t= 0x03,\t// USB 3 Standard-A connector kUSB3StandardB\t= 0x04,\t// USB 3 Standard-B connector kUSB3MicroB\t= 0x05,\t// USB 3 Micro-B connector kUSB3MicroAB\t= 0x06,\t// USB 3 Micro-AB connector kUSB3PowerB\t= 0x07,\t// USB 3 Power-B connector kTypeCUSB2Only\t= 0x08, // Type C connector - USB2-only // These only implement the USB2 signal pair, and do not implement the SS signal pairs kTypeCSSSw\t= 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\t= 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\t= 0xFF\t// Proprietary connector どのコネクタに接続されていてもUSBはUSBなので関係ない気もしますが、macOSの中での電力制御の扱いが異なるようです。IORegistryExplorerなどでコネクタの情報を見ると、コネクタ種類の違いで電流関係のパラメータが異なっています。コネクタ設定の違いが、スリープ時の電流管理にも影響していて、意図しない復帰を誘発している可能性があるかと思います。実際に先の記事にも書きましたが、Bluetoothアダプタが接続するポートは、255に設定しないとスリープを妨げることがあるようです。\n今回の不具合も、Type-Aに対するスリープ時の電力管理がうまく働かないのが原因とも考えられます。それで、Type-Aに設定していた部分：\nを、以下のように、全てInternalに設定しました。\nこの結果、Type-AのコネクタにUSBデバイスを接続していても正しくスリープするようになりました。Internal (255) 以外の設定値のうち、一般的なUSB 2.0 (0)とTypeC+Sw (9)も試しましたが、それらでは解決しませんでした。上の実験でType-Cで正しくスリープ動作したのは、ハブのおかげだったのかも知れないです。\nスリープ動作の確認 ということで、USBPorts.kextでコネクタをInternalに設定する方法で、問題はほぼ解決しました。以下のaml, kext, パッチ：\nSSDT-USBW.aml USBWakeFixup.kext SSDT-GPRW.aml Method(GPRW,2,N)パッチ は、どれも不要でした。\nこの方法で正しくスリープに入り、CPUファンが停止した状態が何時間も継続します。その一方で、Bluetooth接続したApple Magic Keyboard, Magic Trackpad, LogicoolのBTマウスなどから目覚めさせることが可能です。また、Type-Cにハブ経由で接続したノーブランドのキーボードからも目覚めます。\nただ、Type-Aに直接接続した一部のキーボードなどから目覚めさせることができない問題があります。フォーラムで教えてもらった情報によると、スリープ復帰するマウスとしないマウスがあるようです。また、Magic KeyboardをUSB接続した状態だと、これからスリープ復帰できるようです。いずれにしてもBluetooth入力デバイスをメインに使っていく予定なので、このことはほとんど気になりません。\nmacOSの「システム環境設定・省エネルギー」のデフォルトでは、「ネットワークアクセスによるスリープ解除」が有効になっています。これを有効にしておくと、手元の環境では頻繁に目覚めてしまいます。色々な機器が接続されているので、アクセスが多いのかも知れないです。ネットワークがもっと静かな環境なら有効に設定しても良いのかも知れませんが、これを無効にしました。\n一方で、「Power Napを有効にする」は、有効にしておいてもそれほど問題はありません。約1時間に1回ほど目覚める程度でした。それが気になるような環境でしたら、無効にしておくと良いと思います。\nまとめ スリープから自動的に目覚めてしまう現象に、USBPorts.kextの設定で対応しました。正しくスリープして、キーボードやポインティングデバイスの操作でスリープ復帰するようになりました。Z690は、性能が良くて安定しているので、すぐにメインマシンにしても良いくらいです。\n","date":"2021-12-18T11:34:33+09:00","image":"/uploads/2021/11/image.png","permalink":"/posts/14113/","title":"ASRock Z690 Steel Legendをスリープさせる"},{"content":"macOS Monterey 12.1が配布されたので12.1 RC2からアップデートしました。問題なくアップデートできました。Radeon RX 6600が正式にサポートされました。アップデート情報は以下にあります（現時点では12.1の解説はありません）。\nhttps://support.apple.com/ja-jp/HT212585 アップデートしたマシンは以下の2台です。いずれもOpenCore 0.7.6で起動していて、kext類は最新です。\nASRock Z590 Extreme + 10900K ASRock Z690 Steel Legend + 12700K ネットの情報によると、配布された12.1はビルド番号が21C52らしいです。すでにベータ版12.1を導入していて、そのベータ最終版のRC 2も同じ21C52でした。なので、システム環境設定のソフトウェアアップデートに、12.1の通知は来ませんでした。同じもののようですが、念のためにApp Storeに行き、Montereyのダウンロードをしました。\nその結果、12.16GBのファイルがダウンロードされました。\nダウンロードされたmacOS Montereyインストール.appは、自動的に起動しました。インストール先を指定するとインストール開始されて、途中、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくMonterey 12.1が起動しました。でもビルドは21C52のままで変わりませんでした。\nRadeon RX 6600 XTが認識されています。正式サポートされて一安心です。\n","date":"2021-12-14T18:46:50+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/14093/","title":"Monterey 12.1 にアップデートする"},{"content":"Intelの新しい第12世代CPU Alder Lake-Sへの対応がOpenCore開発チームによって進捗しています。先の記事では、macOSでAlder Lake-SのEコアを半分まで稼働させる拡張機能であるCpuTopologySync.kextを紹介しました。昨日これが配布終了になり、その機能がOpenCore本体に組み込まれつつあることが明らかになりました。来月公開のOpenCore 0.7.7では全てのEコアが稼働するそうです。\nその機能を先立って試すことも可能です。以下のコメント、\nで、開発段階のOpenCore.efiが配布されています。これを、\n現在のEFI/OC/OpenCore.efiと入れ替えて、 config.plistでKernel/Quirks/ProvideCurrentCpuInfoをtrueにする ことで、macOSから全コアが利用可能になります。当然ですがBIOSで全コアを有効に設定しておく必要があります。上記のコメントの手順では、CPUFriend.kextとCPUFriendDataProvider.kextを使用して、CPUの周波数ベクターを設定するように書かれていますが、iMacPro1,1の機種IDでは不要でした。書き換えなくても性能は変わりませんでした。\nこれでGeekBench 5のマルチコアスコアが1000から2000くらい上昇します。明らかなシングルコア性能低下もありませんでした。GeekBenchのCPU情報によると、例えば12700Kは、\n1 Processor 20 Cores と表示されます。8 Pコア＋8 ハイパースレッド (HT) ＋4 Eコア＝20コアという計算だと思われます。 10900Kの場合は、\n1 Processor 10 Cores, 20 Threads のように、物理コアとスレッドが別々に表示されていました。OpenCoreでは、Alder Lake PコアのHTを物理コアとして扱うことで、HT可否コア混在の問題を解決している様子です。\n来月のOpenCore 0.7.7へのバージョンアップにより、何事もなく全コアが使えるようになると思いますが、現時点でも簡単に試せて、効果絶大です。\n","date":"2021-12-11T00:34:15+09:00","image":"/uploads/2021/12/alderlake.jpg","permalink":"/posts/14066/","title":"OpenCore 0.7.7でAlder Lake全コアに対応予定"},{"content":"OpenCoreの0.7.6が公開されたので0.7.5からアップデートしました。大きな変更は無いので、0.7.5のconfig.plistそのままでも動くはずです。\n0.7.6をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.6とmacOS 12.1 betaで動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock 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ファイルを差し替える 更新するために、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで設定する項目にほとんど変更はありませんでした。\nUEFI/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に移行できました。\nUIScaleを調整 今までは、sample.plistに倣って、UIScaleをNVRAM/Add/4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14で01に設定していました。今回、UEFI/Output/で設定するように変更されたようなので、値を見直しました。sample.plistでのお手本では0に設定されています。0は変更なし、1は1倍ピクセルのことのようです。\nZ590マシンでは、ボリューム選択画面は小さく鮮明に表示されていました。でもZ690マシンでは、同じく小さく表示されるものの、表示が滲んで、文字が潰れていました。それでも我慢して使ってました。\nUIScaleの設定を試したところ、0や1の設定では、このような滲んだ表示になるようです。4Kディスプレイに正しく対応できていないようでした。そこでUIScaleを2に設定したところ、綺麗に表示されるようになりました。表示サイズは2倍に大きくなりました。\nAlder Lake対応 Alder Lakeのために更新された項目もあります。特にXCPM CPU power management ACPI tableが追加されたとのことです。Z690マシンで、これに関して特に変わった感じは分かりませんでした。もう少し調査します。\nOpenCoreと同時にアップデートされたkext類も、Alder Lakeに対応しました。AppleALC.kextは1.6.7になりました。これで、ASRock Z690 Steel Legendに搭載されたALC897のデバイス番号に対応し、音が出るようになりました。またVirtualSMC.kextもアップデートされて、HMMonitorでCPU温度や消費電力が表示できるようになりました。\n","date":"2021-12-07T19:18:30+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/14039/","title":"OpenCore 0.7.5から0.7.6に更新"},{"content":"Intelの新しい第12世代CPU Alder Lake-Sが発売されてから1月あまり経ちました。海外のコミュニティを見ていると、新CPUをmacOSで使うためのハッキングが進捗しています。昨日（2021/12/05）あたりには12900Kの24スレッド中の、20スレッドまでをmacOSで使うkextが紹介されました。近いうちにAlder Lakeの全性能を引き出せるようになるのではと思います。\n追記：OpenCore 0.7.6が公開されたので更新しました。\nComet Lakeに偽装する方法 こちらでも紹介しましたが、Alder Lake-SとZ690マザーボードの組み合わせで、macOSがかなり安定して動作しています。macOSで元々サポートされているComet Lake-Sと比べて、遜色のないくらい安定しています。M1 Maxを凌駕する性能でもあることから、早々にメインマシンにしても良いと考えているくらいです。\nこの手法では、Alder Lake-SをComet Lake-SとしてmacOSに認識させています。その場合、Alder Lakeから導入されたPコア/Eコアの構成は活用できず、一部のコアを使用できません。例えば、最上位モデルの12900Kの場合、P+E+ハイパースレッド(HT)で24スレッドが用意されているのに対して、Eコア、またはHTを除く、合計16スレッドしか使えません。表にまとめておきました。\n12900K 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ブラウザのサイトで検索すると、\n12900k Acidanthera - Geekbench 5 CPU Search - Geekbench Browser\nこのページで、8コアもしくは16コアと表示されるのが、これらの結果です。8コアがPコア+HTの設定、16コアがPコア（HTなし）+Eコアの設定です。Eコアを使わない方が、多少良いスコアになるので、16コアの結果はほとんど見られなくなりました。\nCpuTopologySync.kextを使う方法 ~~昨日（2021/12/05）あたりに、~~acidentheraさんからCpuTopologySync.kextというkextを使った方法が公開されました。\nGitHub - acidanthera/CpuTopologySync: Rebuild asymmetric CPU topology on macOS.\n~~まだ開発中で制約がありますが、~~これを使うとEコアをさらに活用できます。正確には、Pコア＋PコアのHTに加えて、Eコアの半分までを使用できるようです。12900Kの場合、物理コアが12コア、HTが8スレッドで、合計20スレッドになります。残りの4スレッドは、アクティビティモニタには24スレッドのグラフが現れるものの、うち4スレッドが動作しないようです。\nこの理由は、CpuTopologySync.kextのコメントによると、XNU割り込みコントローラの仕様のためらしいです。\nAfter 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 (\u0026#34;hyperthreaded\u0026#34; 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へアクセスしようとしてもコアが足りるようにしているようです。\nそれでもEコアが働く効果により、Geekbench 5のマルチコアスコアが16000以上になるそうです。Geekenchブラウザで、コア数12となっているスコアがこれに相当します。シングルスレッド性能のバラツキや低下もなく、効率良く動いている様子です。kextを使用する以外に、\nカーネルにパッチを当てる（config.plistにパッチの記載を追加する） 開発版最新版のLilu.kextを使う Liluの直後にCpuTopologySync.kextを読み込む などの作業・要件が必要です。etorixさんのポストに、この方法がコンパクトに書かれています。\n全スレッドを使う方法 Geekbench 5 ブラウザを見ていると、24コアで動く12900Kのスコアが掲載されています。詳細を見ると、3 Processors, 24 Coresと書かれています。おそらくは、Pコア、HT、Eコアをそれぞれ仮想CPUに見立てて、24コアを使い切った構成だと考えられます。でも今のところ、CpuTopologySync.kextで12コア20スレッドにする場合と、ベンチマークスコアはあまり変わらないです。\nまとめ Alder Lake-SでmacOSを動かすハッキングは、ここ1ヶ月くらいでどんどん進捗しています。海外のフォーラムを見ていると、その成果に沸く様子が伝わってきて楽しいです。今のところCpuTopologySync.kextでEコアが半分になってしまう点など、まだまだ改善の余地はありそうです。今後のOpenCoreのリリースに合わせて、安定したバージョンが提供されていくと思われます。\n","date":"2021-12-06T23:14:57+09:00","image":"/uploads/2021/12/alderlake.jpg","permalink":"/posts/14028/","title":"Alder Lake-SをmacOSで動かすハッキング"},{"content":"NVIDIAのKeplerアーキテクチャは、macOSで長らくサポートされていましたが、とうとうMontereyからサポートされなくなりました。でもBig Sur以前のドライバをインストールすれば動きます。\nKeplerが動かない 久しぶりに古いKeplerアーキテクチャのグラボ、GTX 770を使ってみたところ、macOSで動かなくなってました。低解像度で表示はされますが、グラフィックス加速が効いてなくて、動きがギクシャクします。試したのは、ASRock Z690 + Intel 12700K + macOS Monterey 12.0.1の構成です。調べたところMontereyからKeplerのサポートが終了しているようです。ちなみにこれまでmacOSで動くとされていたKeplerのグラボは、以下です。Montereyから、これらが動かなくなったようです。（正確にはMonterey beta 6まではドライバがあったらしいです）\nGTX Titan (GK 110 Maxwell core) GTX Titan Black (GK 110 Maxwell core) GTX Titan Z GTX 780/Ti GTX 770 GTX 760/Ti GT 740 GT 730 (GK208 variant) GT 720 GT 710 GTX 690 GTX 680 GTX 670 GTX 660Ti GTX 660(MUST BE RUNNING A GK 104 core, NOT GK 106) GTX 650(GK 107 core) GT 640(Kepler edition, GK 107/208 core) GT 630(Kepler edition, GK 107/208 core) Quadro 410 Quadro K420 Quadro K600 Quadro K2000/D Quadro K4000/D Quadro K4200 Quadro K5000 Quadro K5200 Quadro K6000 ちなみに、NVIDIA自体も2021年10月の最新ドライバでKeplerのサポートを終了したそうです。なのでmacOSのKeplerサポート終了は、仕方のないことでしょう。\nNVIDIA、Kepler世代GPUやWindows 8.1以前のサポートを終了\nkextが無い なのでMontereyにはKeplerをサポートする拡張ファイルが無くなりました。Keplerは、macOSでサポートされていたNVIDIA唯一のアーキテクチャだったので、これでNVIDIA製品が完全にサポートされなくなりました。\nkextが無くなったことを確認するために、macOS 11.2.1 Big Sur (20D74)の/S/L/Eの中身を調べてみました。NVDAで始まるファイルとして、以下が見つかります。\n/System/Library/Extensions/NVDAGF100Hal.kext /System/Library/Extensions/NVDAGK100Hal.kext /System/Library/Extensions/NVDAResman.kext /System/Library/Extensions/NVDAStartup.kext 同様にGeForceで始まるファイルとして以下がありました。\n/System/Library/Extensions/GeForce.kext /System/Library/Extensions/GeForceAIRPlugin.bundle /System/Library/Extensions/GeForceGLDriver.bundle /System/Library/Extensions/GeForceMTLDriver.bundle /System/Library/Extensions/GeForceVADriver.bundle 一方で、macOS 12.0.1 Monterey (21A559)にはこれらが存在していません。\n古いKextを使う Kextが無くなってしまったのなら、古いmacOSから持って来れば良いです。ただ、システムに必須のディレクトリは保護されていて、手作業でkextを持ってくるのは面倒です。なので、それを自動化してくれるツールがありました。\nReleases · chris1111/Geforce-Kepler-patcher\n前述の9個のkextとbundleをインストールしてくれます。\nただし、システムファイル用のディレクトリに手を加えるのでSIP (System Integrity Protection) を無効にする必要があります。通常は、\ncsrutil status で確認できるように、SIPが有効になってます。Macの実機だと、リカバリーモードで起動してcsrutilコマンドでSIPを解除するのですが、hackintoshならconfig.plistで変更できます。NVRAM/Add/7C436110-AB2A-4BBB-A880-FE41995C9F82/csr-active-configの値（大抵は00000000のはずです）をEF0F0000に変更します。この数値はGeforce Kepler patcherで指示されます。\nRunボタンを押すと、インストールが開始されます。インストール先のボリュームを指定して、その中のDATAになっているAPFSのボリュームを指定するステップを経て、インストール終了です。\ncsr-active-configの値は、kext類をインストールした後もそのままにしておく必要があるようです。SIPを有効に戻してしまうと、起動しなくなりました。また起動ボリュームの名前が、Monterey-DISKに変更されます。\n動きました 再起動すると、高解像度の画面で表示されていました。macOSで認識されているようです。Geekbench 5も動くようになりました。でもOpenCLのテストはなぜか途中で中断します。Metalのテストは最後まで動きます。スコアは以下のようでした。\n古いGPUですからこんなものでしょうか。M1 Maxの1/10くらいです。\nまとめ NVIDIA GeForce KeplerはMontereyからサポート外になってました。古いmacOSのkextをインストールすることで使えるようになります。古いカードですのでそれなりの性能でした。\n","date":"2021-12-04T00:10:33+09:00","image":"/uploads/2021/12/pngwing.com_.png","permalink":"/posts/14000/","title":"NVIDIA GeForce KeplerをMontereyで動かす"},{"content":"ASRock Z690 Steel Legendのオンボードオーディオが動きました。AppleALC.kextのGithubのページを見に行ったら、Z690用のパッチの当たったバージョンがありました。以下の記事の続きです。\nASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす\nKext Updaterから開発版を入手する Kext類の公開前開発バージョンは、Kext Updaterからも入手できます。Kextmanagerを選んで、Nightly Buildsの項目を見ます。ここから入手可能な開発バージョンの中に、AppleALCがありました。\nこれでダウンロードしたところ1.6.7を入手できました。EFIにある1.6.6と差し替えます。ASRock Z690 Steel Legendに搭載されているコーデックはALC897です。このlayout-idは、12, 23, 66, 69のいずれかとのことです。\nSupported codecs · acidanthera/AppleALC Wiki\n大抵はどれでも動くのですが、やはり最初に試した12で動きました。\nこれで音が出るようになりました。\n","date":"2021-12-01T23:15:43+09:00","image":"/uploads/2021/11/image.png","permalink":"/posts/13987/","title":"ASRock Z690 Steel Legendのオーディオを動かす"},{"content":"Intelの第12世代CPUになるAlder Lake-Sシリーズが発売されました。今までになく高性能になったと評判です。macOSではサポートされていないCPUですが、Montereyで安定して稼働しました。Radeon RX 6600XTと組み合わせると、M1 Maxをちょっとだけ超える性能が得られます。\nASRock 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を置き換える場合でもアンテナ配線が不要なので楽です。\nこのマザボを選んだいちばんの理由は、PCIeスロット数が多いことです。5本あります。これだけの拡張性は、実機では高価なMac Proでしか得られないので貴重です。Z590に引き続き、端正な見た目のASRock Z690 Extremeにしたかったのですが、ExtremeはZ690になってPCIeが1本減ってしまいました。Steel Legendは、Z590バージョンと同じスロット数を確保してます。Steel Legendの見た目のデザインは、ゴテゴテしてて好みでは無いのですが、機能重視で選びました。グラボの邪魔にならないバックパネル側に、PCIe x 1スロットがあるのも良いです。SSD用ヒートシンクの角を削って、多少見た目が悪くなっても、ここにPCIeを1本確保しようという設計者の機能性重視な心意気が気に入りました。\nE keyのM.2ソケットが、マザーボード上のアクセスしやすい場所にあります。多くの歴代ASRockモデルと同様に、これもCNVi専用ソケットではありません。なのでmacOSと互換性が高く、OOBで稼働するBCM94360NGを取り付けることができました。PCIe用のWiFiアダプタを使用しなくて済むので、PCIeスロットの節約にもなります。\nメモリはDDR4です。DDR5を試したかったのですが、メモリーが入手不可能な状態なので現状ではDDR4対応マザーボードしか選択肢がありません。\nAlder Lake-S 12700K 今回発売されたAlder Lake-S CPUは、12900, 12700, 12600のKとKFモデルです。どれを使用してもmacOSは稼働するようです。macOSで動作させた場合の12900Kと12700Kの性能を、Geekbench Browserの結果で比較すると、12900Kの方が、12700Kより数%程度高性能です。\nAcidanthera 12900k - Geekbench 5 CPU Search - Geekbench Browser\nAcidanthera 12700k - Geekbench 5 CPU Search - Geekbench Browser\nとはいえ、後述するようにmacOSでは実質的にEコアが使えないので、Pコア数の同じ両者に大きな性能差は出ません。価格差は大きいので、12700Kの方がコスパは高いです。今回は、「M1 Maxにギリギリ勝てる」構成を目指して12700Kにします。（追記：OpenCore 0.7.7からは全コア全スレッドが使用できるようになり、12900Kの優位性が向上します）\nmacOSではAlder Lake-SのiGPUは使えませんし、今後使えるようになる見込みもありません。そもそもmacOSがサポートしている第10世代CPUのiGPUも、自作マシンではなかなか安定せず使いにくかったです。なのでiGPUが搭載されていないKFモデルを選んでも良いと思います。\nBIOSを設定する BIOSの設定で重要な箇所を以下に列挙しました。大半がデフォルト値のままで良いです。デフォルト値から変更した部分（3箇所だけです）を太字で示します。\nOC Tweaker \u0026gt; DRAM Configuration \u0026gt; Load XMP Setting \u0026gt; XMP 2.0 Profile 1 Advanced \u0026gt; CPU Configuration \u0026gt; Intel Hyper Threading Technology \u0026gt; Enabled (default) Advanced \u0026gt; CPU Configuration \u0026gt; Active Process P-Cores \u0026gt; All (default) Advanced \u0026gt; CPU Configuration \u0026gt; Active Process E-Cores \u0026gt; 0 Advanced \u0026gt; CPU Configuration \u0026gt; CFG Lock \u0026gt; Disabled (default) Advanced \u0026gt; Chipset Configuration \u0026gt; Above 4G Decoding \u0026gt; Enabled (default) Advanced \u0026gt; Chipset Configuration \u0026gt; VT-d \u0026gt; Enabled (default) Advanced \u0026gt; Chipset Configuration \u0026gt; IGPU Multi-Monitor \u0026gt; Disabled (default) Advanced \u0026gt; USB Configuration \u0026gt; XHCI Hand-off \u0026gt; Enabled Eコアを無効にする設定は、macOSを動かす上でとても重要です。これを行わないとカーネルパニックになります。一方で、Hyper Threading (HT)を無効にすれば、Eコアを有効にすることができます。ただし、性能は少しだけ低下します。それで、HTを有効にしてEコアを無効にする設定にしました。（追記：OpenCore 0.7.7からは全コア全スレッドが使用できるようになるので、その場合は、BIOSで全て有効に設定します。）\nAbove 4G Decodingはデフォルト値の「有効」のままにしておく必要があります。DisabledにするとmacOSの起動途中で止まってしまいます。\nなおBIOSはできる限り最新にした方が良いようです。GIGABYTEのマザーボードでは、macOS起動の問題がBIOSアップデートで解決したという報告が多数見つかります。ASRockはマザーボードの発売が遅かったことも関係するのか、最初のBIOSでも問題ありませんでした。でも発売直後のマザーボードはBIOSにバグがあることが多いのでアップデートがあったら実施しておいた方が良いと思います。このマザーボードの現在のBIOSは2.10です。\nEFIを設定する 以下のガイド（Gigabyte Z690 Aero G用）を参考にして設定しました。OpenCore 0.7.6を使っています。macOSは12.0.1と12.1 betaで動作確認しました。\n使用しているSSDTは以下です。これをACPIフォルダに入れました。\nSSDT-AWAC.aml SSDT-EC-USBX.aml SSDT-SBUS.aml SSDT-PLUG-ALT.aml 下の方でリンクしたEFIファイル一式には他のSSDTも入っていますが、config.plistで無効にしてあります。\n使用しているkext類は以下です。これをKextsフォルダに入れました。USBPorts.kextは、後述のようにHackintool.appを使って作りました。\nLilu.kext VirtualSMC.kext WhateverGreen.kext SMCProcessor.kext SMCSuperIO.kext AppleALC.kext (layout-idは12) LucyRTL8125Ethernet.kext NVMeFix.kext USBPorts.kext 今回公開するEFIファイル一式には他のkextも入っていますが、config.plistで無効にしてあります。\nconfig.plistは、前述のガイドのページで配布されているものを参考に、機種IDなどを設定しました。機種IDはiMacPro1,1にしました。好みでMacPro7,1にしても良いです。ただ、iMacPro1,1の方が設定が簡単です。MacPro7,1の場合は、CPUFriend.kextとそれに付随するkextを使って、動作周波数を最適化しないと、十分な性能が出ません。\n12世代CPUはmacOSで採用されていないので、CPU IDをi9-10850KなどのID である000A0655に偽装しています。config.plistのKernel/Emulateの中に以下のように記述します。\nオンボードのオーディオは、AppleALC.kextの1.6.7からサポートされています。layout-idは12で動きました。config.plistのDevicePropertiesに追記します。\nボード上のEthernet LANはRealtekのRTL8125BGです。これはLucyRTL8125Ethernet.kextで動きました。\nEFIファイルの一式を**ここに**置いておきます。シリアル番号などは削除してありますので、使用される場合は設定してください。\nUSBポートを設定する Hackintoolなどでポート番号を調べると、バックパネルのUSBポートは以下のようにアサインされていました。合計で12本です。\nマザーボード上の内部コネクタについても少し調査しました。その結果、\nマザーボード上のM.2 E keyソケットに接続されたUSBはHS14でした。 また、マザーボード上のUSB Type-Cコネクタは、HS01とSS01でした。 以上の合計がmacOS上限の15本になるので、これらを有効にするようにHackintoolを使ってUSBPorts.kextを作りました。マザーボード上の他の従来型内部コネクタ（USB 2.0と3のピンヘッダ）を使用する場合は、このリストを差し替える必要があります。\nスリープ 上記のUSBコネクタ設定は、実際のコネクタの状況を反映した結果ですが、このままだとスリープで問題が発生しました。バックパネルのType-Aコネクタに、キーボードやUSBメモリなどが接続されていると、スリープに入っても1分ほどで復帰してしまいます。その一方で、Type-Aに何も接続されていなければ、正しくスリープします。Bluetoothキーボードなどから復帰することも可能でした。\nこの問題は、USBPorts.kextでType-AコネクタをInternalに設定することで解決しました。Hackintool.appでしたら、以下のように設定します。\nシステム環境設定・省エネルギーでは、ネットワークアクセスによるスリープ解除を無効にすると良いかも知れません。Power Napは有効でも問題ありません。1時間に1回くらい起動します。それが気になるようでしたら無効にすると良いです。\nただ、Type-Aに直接接続した一部のキーボードなどから目覚めさせることができないようです。こちらで紹介した格安キーボードではスリープ復帰できませんでした。また、フォーラムで教えてもらった情報によると、スリープ復帰するマウスとしないマウスがあるようです。一方で、Magic KeyboardをUSB接続した状態だと、これからスリープ復帰できました。いずれにしてもBluetooth入力デバイスをメインに使うならば問題ないです。\nこの設定で残った問題は、Type-Aに接続したキーボードからスリープ復帰できない点です。Bluetooth接続のApple純正キーボード、トラックパッドを使う場合は問題ありません。\nベンチマークで性能評価 Geekbench 5でベンチマークしました。シングルコア性能ではM1 Maxを上回りました。マルチコア性能では互角でした。\n以前にGeekbench 5のサイトで確認したM1 Maxのスコアと比較すると以下のようになります。\nこれにRadeon RX 6600XTを組み合わせれば、M1 Maxより少しだけ性能の良いマシンが作れます。先の記事のGeekbench 5スコア比較を再掲します。\n動いていること ここ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は、\nBIOSでEコアを無効にしてPコア＋HTを使う（無難で性能が出るのでお勧め） 設定になっています。このほかに、以下の選択肢が可能です。詳しくは上記のetorixさんの投稿をご覧ください。\nBIOSでHTを無効にしてPコア＋Eコアを使う（少し性能が落ちる） BIOSで全コア＋HTを有効にしてSSDTでEコアを無効にする（Windows起動時に性能を出せる）\nこの場合、SSDT-PLUG-ALT.amlを無効にしてSSDT-PLUG-ALT-12.aml (12600用) もしくはSSDT-PLUG-ALT-12.aml (12900, 12700用) を使う。また、Kernel\u0026gt;Quirk\u0026gt;ProvideCurrentCpuInfoを有効にする。これでmacOSからEコアが見えなくなる。ただしAVX-512が無効になる。 BIOSで全コア＋HTを有効にして、Pコア全部＋Eコアの半分を有効にする。（性能は最大）\nこの場合、 CpuTopologySync.kextを有効にして、SMCProcessor.kextは無効にして、カーネルのパッチを当てる。パッチは上記のEFIの中のconfig.plistに既に書いてあります。 （追記）OpenCore 0.7.7からBIOSで全コア＋HTを有効にしても動くようになります。Windowsで実行する場合と同程度の性能が出ます。 OpenCore 0.7.6を使う場合は、「BIOSでEコアを無効にしてPコア＋HTを使う」方法が、無難で性能が出るので、Windowsをあまり使わない場合はおすすめだと思います。\n","date":"2021-11-30T23:27:46+09:00","image":"/uploads/2021/11/image.png","permalink":"/posts/13940/","title":"ASRock Z690 Steel LegendとAlder Lake-SでmacOSを動かす"},{"content":"インテルの第12世代CPUであるAlder Lake-Sシリーズは、Pコア（高性能コア）とEコア（高効率コア）で構成されてます。現状のhackintoshではEコアが適切に使えていません。なので12900KよりもPコア性能が高い12700Kの方が、高性能を引き出せるようです。\n追記：最近の動作報告では、最適化が進捗して、12900Kの方が12700Kより若干高性能になってます。それでも差は小さいので、コストパフォーマンスを考えると12700KがmacOSに適していると言えます。（2021/11/29）\n仕様を比較 発売されたモデルは、12900, 12700, 12600のKとKFモデルです。今後はもっと幅広いモデルが揃ってくると思われます。それぞれのコア数とクロック数を表にしました。\nCPU Pコア数 PベースCLK Eコア数 EベースCLK 12900K,KF 8 3.2GHz 8 2.4GHz 12700K,KF 8 3.6GHz 4 2.7GHz 12600K,KF 6 3.7GHz 4 2.8GHz 12900と12700はPコア数が同じ、12700と12600はEコア数が同じです。また、どちらのコアも、下位モデルの方がクロック数が高いです。ということで、例えばPコアだけを使う場合を考えると、12900よりも12700の方が性能が上と言えます。\n追記：ベースクロック数の比較では12700の方が高性能ですが、キャッシュ容量などは12900の方が多いので、トータルな性能では12900が上のようです。\nAlder Lake-SでmacOSを動かす tonymacx86のスレッドを見ていると、Alder Lake-S上で、macOSがそこそこ順調に動いている様子です。\nただ、ハイパースレッド(HT)の動作に課題があるようで、完璧な性能は引き出せていないようです。現状でカーネルパニックを引き起こすことなくmacOSが稼働するパターンは、\nPコアのHTを有効にしてEコアを無効にする PコアのHTを無効にしてEコアを有効にする というようにBIOS設定した場合です。HTが効く・効かないコアが混在したコア構成にmacOSが対応できていないのかもしれません。\nGeekbenchのスコアで比較 公開されているGeekbenchスコアを見て、12900, 12700, 12600の性能比較を試みました。Acidantheraで検索するとhackintosh関係のベンチマークが現れます。その後にプロセッサ名をつければ、それを使ったhackintoshのスコアが見られます。例えば、\nhttps://browser.geekbench.com/v5/cpu/search?q=Acidanthera+12700k\nとすると、12700Kのスコアが見られます。こうして見つけた12900K, 12700K, 12600Kスコアのグラフが以下です。\n12600Kは現在1件しか登録がないので、このスコアはあまり参考にならないかと思います。12900Kと12700Kは、30件程度の登録があります。8コア、12コア、16コアのデータがありました。Eコアを無効にしてHTを有効にした結果が8コア、Eコアを有効にした結果がそれ以外だと思われます。12700Kを8コアで使用（Pコアのみ使用）した場合が、一番性能が良いようです。\n追記：最近の報告では、最適化が進捗して、12900Kのマルチコアスコアは13,000から16,000くらいに向上してました。ただし15,000超えのスコアはオーバークロックした場合のスコアのようです。定格使用での差は少ないのでmacOS用としては12700Kが良いと思います。\nmacOSには12700Kが良い？ Geekbenchに8コアと6コアのスコアをアップロードしたmacOSマシンは、Eコアを無効にしているのだと思われます。おおむね仕様を反映した結果になっています。下位モデルの方がクロックが高いので、シングルスコアも高いです。マルチスコアにもそれが反映されています。12900Kと12700KはPコアの数が同じですので、Eコアを無効にした条件では、12700Kの方が高いスコアになったと考えられます。追記：現在では12900Kの方が高スコアです。\nということで、Pコアしか使えないmacOSを使用するなら、高価な最上位機種の12900Kを買うよりも、12700Kの方が高い性能を得られそうです。ただし、もしも今後、Pコアのハイパースレッドと、Eコアが全て使えるようになれば、逆転すると思われます。\n","date":"2021-11-19T23:37:13+09:00","image":"/uploads/2021/11/51klBAsxGHL.jpg","permalink":"/posts/13896/","title":"macOSに適したAlder Lake-S CPUはどれ？"},{"content":"Radeon RX 6600 XTをmacOS 12.1で試したところ、問題なく動作しました。5700 XTのベンチマーク比較では、Metalの性能が8%ほど良くなっているようです。ほとんど変わりませんが、TDPは下がっているのでワットパフォーマンスは高いです。\n箱から出す 今回使ってみた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万円かそれを切るくらいの価格です。\n今まで使っていたRX 5700 XTを取り外して、RX 6600 XTを取り付けました。マザーボードはASRock Z590 ExtremeでCPUは10900Kです。ソフトウェアは、OpenCore 0.7.5 とmacOS Monterey 12.0.1の構成です。\n5700 XTが30cm近い大型で重厚なグラボだったのに比べて、6600 XTは一回り小さく、軽く、補助電源も8ピン1個だけです。見るからに格下のモデルなので、交換して性能がどうなるのか不安でした。消費電力にも差があり、5700 XTのTDPが225Wなのに対して、6600 XTは160Wです。\nmacOS 12.0.1では動かない 現行のmacOSはMonterey 12.0.1です。今まで5700 XTが動いていた状態のところに、グラボだけを6600 XTに交換しました。起動オプションには、\nagdpmod=pikera を指定してあります。この状態で起動したところ、高解像度表示にならず、また表示速度が遅い状態で起動しました。グラフィックスアクセラレーションが効いていない状態です。システム情報を見ても、サポートされていない状況がわかります。\nmacOS 12.1にアップデート そこで、パブリックベータとして無料配布されている12.1 Betaにアップデートしました。ビルドは21C5021hです。アップデートしたところ、6600 XTがサポートされて、正常な表示が行われるようになりました。システム情報は以下でした。ベータ版はスクリーンショットの公開ができないので、文字だけで紹介します。\nAMD 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です。\nmacOS 12.1からRadeon 6600XTが使える\nちなみに12.1 Betaはなかなか良いです。12.0.1よりもキビキビと動く気がします。大規模アップデートの直後のベータ版なので、改良が進んでいるのだと思います。不安定なところは全くないので、すぐにインストールしても良いのではと思いました。\nベンチマーク Geekbench 5でベンチマークしました。5700 XTと比較したところ、若干性能向上しています。特にMetalの性能が向上しています。Appleが力を入れているので、デバイスドライバーもMetalに対して手厚く対応しているのではと思いました。6600 XTはTDPが大幅に下がっているので、ワットパフォーマンスで考えると大きく進歩してます。\n注目したいのはM1 Maxとの比較です。このスコアは、前回の記事で紹介したGeekbenchに上がっているスコアをそのまま持ってきたものです。5700 XTではOpen CLでM1 Maxに優っているものの、Metalでは僅差で負けてました。6600 XTはMetalの性能が向上したので、明らかにM1 Maxを上回るようになります。大した差ではないですが、M1より良い性能を手に入れらる安心感で、心の平安を得られます。\nまとめ Radeon RX 6600 XTはmacOS 12.1で動きます。性能はRX 5700 XTより少しだけ上で、消費電力は少ないです。グラフィックスボードはまだまだ高値止まりで、6000シリーズローエンドの6600 XTも決して安くはないですが、hackintosh向けおすすめグラボだと思います。\n","date":"2021-11-07T22:10:51+09:00","image":"/uploads/2021/10/71Z50I5bIaL.jpg","permalink":"/posts/13782/","title":"Radeon RX 6600 XTをmacOSで使う"},{"content":"M1 ProとM1 Maxを搭載したMacBook Proの性能がとても良いらしいです。それで、同じ10コアCPUを搭載した重量級自作マシンとM1 Maxを比較しました。ベンチマークソフトはmacOS 12.0.1上でのGeekbench 5です。結果はわかっていたことですが、負けてます。\n比較対象：M1 Max 新型MacBook Proが手元にあるわけではないので、比較対象のM1 MaxスコアはGeekbenchにあるベンチマーク結果です。テンション低くてすみません。M1 MacBook Airで十分な性能ですし、それでも重いので、無印MacBookの復活を待っているところです。OSは、M1 MaxなのでmacOS Monterey 12.0.1のはずです。\nGeekbench BrowserのCPUのページでMacBookPro18で検索すると、今回の新製品MacBook Proのスコアが出てきました。\nMacBookPro18 - Geekbench 5 CPU Search - Geekbench Browser\n18,1から18,4まであるようです。GPUのページでもMacBookPro18で検索しました。\nMacBookPro18 - Geekbench 5 Compute Search - Geekbench Browser\n新型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だと思われます。以上から、\nMacBookPro18,3は14インチ最下位モデル MacBookPro18,2は16インチ最上位モデル MacBookPro18,1とMacBookPro18,4は中間モデル と推測しました。番号の並びから18,1が16インチ下位モデル、18,4が14インチ上位モデルと思われますが、両者のCPU/GPU仕様に違いがないので、Geekbenchスコアからは判断できません。\n今回の比較対象は、この中から最上位モデルのMacBookPro18,2にしました。Apple Storeで最小構成で見積もると、以下の構成で、税込419,800円です。\n32GBメモリ 1TB SSD 比較対象：Intelマシン 最上位M1マシンの挑戦を受けるのは、現在使っているIntelマシンです。M1 Maxと同じ10コアCPUです。OSも同じくmacOS Monterey 12.0.1です。GPUはRX 5700XTです。\nCPU: 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からサポートされます。\nM1 Max搭載MacBook Pro対…｜自作PC構成｜自作.com\n合計価格は税込281,336円です。MacBook Proよりは安いですが、差額14万円くらいです。割合では3分の2くらいでしょうか。グラフィックスカードの高騰が痛いですね。ノートとデスクトップの違いがありますので、大きくて重くて持ち運べなくてバッテリ無しですが、画面は大きいです。\nCPU性能比較 M1無印の時からCPU性能はとても良かったのですが、10コアになってさらに強力になってました。10コアとは言っても、フルスペックのコアは8コアだけなので、10コア全部がフルスペックのインテルCPUも頑張るのではと期待していたのですが、以下のような結果です。M1 Maxのスコアは、Geekbenchのサイトにある最近の測定値3点を選んで平均しました。10900Kのスコアも3回の平均です。\nシングルでは、M1無印の頃から負けてましたが、それを引き継いだ性能なので、完敗です。コア数が増えたのでマルチも負けました。M1 Maxの方が、シングルで30％、マルチで15％高性能です。大きなCPUクーラーで冷却している10900Kと、ノート筐体のM1 Maxというハンディを考えると、圧倒的な性能差と言えます。\nGeekbenchによると、このマルチ性能に勝てるIntel Macは、iMac Pro最上位（18コア）か、Mac Pro 16コアモデル以上だけのようです。\nGPU性能比較 インテルのiGPUは、CPUチップの片隅に載せてもらったおまけのようなiGPUという印象でした。M1だって大したことないだろうと思ってました。比較相手の5700XTは、長さ30cm近い拡張カードに搭載された大きなチップのGPUです。電力も冷却も十分なので、圧勝かと思いました。しかし以下のように、Open CLのスコアは5700XTが17%ほど勝っているものの、Metalのスコアは2％負けてます。これもそれぞれ3回の平均です。2％は誤差と言えますが、数回測っても逆転するのは1〜2回程度でした。\nOpen CLでM1 Maxが負けているのは、多分AppleがOpen CLに力を入れていないからではないかと思います。一方で、Appleが提唱しているMetalに対しては十分な最適化が施されていて、M1のハードウェア性能をとことん引き出したスコアが出たのではないかと思います。ということで、Open CLでは勝てたけど、Metalでは僅差で負けという結果でした。RX 6900XTだとこの3倍近いスコアが出るとコメントで紹介されていましたので、6900XTなら圧勝できるかもしれません。\nまとめ Intelの10コアCPUと、M1 Maxを比較しました。M1はGeekbenchからもらってきたスコアなので、手抜きです。CPU性能はM1が良いです。Radeon RX 5700XTと比較したグラフィクス性能では、MetalスコアでM1 Maxが僅差で高性能でした。\n","date":"2021-11-06T20:39:48+09:00","image":"/uploads/2021/11/m1maxpro.jpg","permalink":"/posts/13699/","title":"M1 Maxと10コア勝負したら負ける"},{"content":"OpenCoreの0.7.5が公開されたので0.7.4からアップデートしました。大きな変更は無いので、0.7.4のconfig.plistがそのまま動きます。\n0.7.5をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.5とmacOS 12.0.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock Z590 Extreme + 10900K + Radeon 5700 XT + macOS Monterey 12.0.1 .efiファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで設定する項目にほとんど変更はありませんでした。\nBooter/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に移行できました。\n","date":"2021-11-02T23:15:28+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/13765/","title":"OpenCore 0.7.4から0.7.5に更新"},{"content":"AppleのmacOS 12.1 betaリリースノートによると、AMD Radeon RX 6600XTが使えるようになったとのことです。色々なサイトで話題になっていますが、元ネタは以下のようです。\nApple Developer Documentation\n情報のまとめ これによると「ディスプレイに関するmacOS Monterey 12.1 betaの新機能：AMD Radeon 6600XT GPUを搭載したグラフィックスカードが使用可能になります。」とのことです！\nRedditのコメントには以下のような内容が書かれてました。\nRadeon RX 6600無印も6600XTと同じくNavi 23なのでdevice IDを偽装すればたぶん動く Radeon RX 6900XTの新しいバージョン（XTXHチップ）もdevice IDを0x73BFに偽装する必要があるけど動く Radeon RX 6700XTはNavi 22であり、GPUチップが違うので引き続き動かないと考えられる 6700だけはなぜかmacOSでサポートされない様子です。次期Mac製品ラインナップに関係しているのかもしれません。ということで、macOS 12.1でサポートされるRadeon RX 6000シリーズは\nRadeon RX 6900XT Radeon RX 6800XT, 6800 Radeon RX 6600XT (6600無印も対応可能？) ということになりそうです。\n12.0と12.1のkext比較 グラフィックスドライバーは、/System/Library/Extensions にあると思われます。macOS 12.0とmacOS 12.1で、それらしい名前のファイルを探してみたところ、そのどちらにも、AMDRadeonX6000という名前で始まる.kextファイルが3個、同じく.bundleファイルが3個ありました。\n内部的にはこれらはディレクトリです。その中のContents/Info.plistを比較したところ、.bundle/Contents/Info.plistの中身は、バージョンの記述の違いだけでした。一方で、.kext/Contents/Info.plistの中身には違いがありました。このため、6600XT対応のために内容が更新されたのは、以下の3個の.kextファイルだと思われます。\nAMDRadeonX6000.kext AMDRadeonX6000Framebuffer.kext AMDRadeonX6000HWServices.kext AMDRadeonX6000.kext 12.0と12.1でAMDRadeonX6000.kextのInfo.plistを比較すると、以下の行を含む内容が追加されていました。6600XTに搭載されたNavi 23のために対応した部分と思われます。\n\u0026lt;key\u0026gt;AMDNavi23GraphicsAccelerator\u0026lt;/key\u0026gt; （略） \u0026lt;key\u0026gt;IOClass\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AMDRadeonX6000_AMDNavi23GraphicsAccelerator\u0026lt;/string\u0026gt; AMDRadeonX6000Framebuffer.kext こちらにのInfo.plistも比較したところ、12.1版には、Navi23に対応して追加されたフレームバッファと思われる情報が書かれていました。\nAMDRadeonX6000HWServices.kext このContents/Info.plistの中に、IOPCIMatchというキーがあります。12.0の内容が以下だったのに対して、\n\u0026lt;string\u0026gt;0x73101002 0x73121002 0x73181002 0x73191002 0x731A1002 0x731B1002 0x731F1002 0x73401002 0x73411002 0x73431002 0x73471002 0x734F1002 0x73601002 0x73A21002 0x73AB1002 0x73BF1002 0x73A31002\u0026lt;/string\u0026gt; 12.1では以下のように変更されていました。\n\u0026lt;string\u0026gt;0x73101002 0x73121002 0x73181002 0x73191002 0x731A1002 0x731B1002 0x731F1002 0x73401002 0x73411002 0x73431002 0x73471002 0x734F1002 0x73601002 0x73A21002 0x73AB1002 0x73BF1002 0x73A31002 0x73E31002 0x73FF1002\u0026lt;/string\u0026gt; これは、対応デバイスの情報だと思われます。8桁の16進数のうち、下4桁がベンダーIDで、1002はAMDのvendor IDです。上4桁がdevice IDです。\n0x73E31002 0x73FF1002 の2機種が追加されています。実際の商品とデバイスIDの組み合わせのしっかりした情報は見つけられなかったですが、巷の情報では、以下の対応だそうです。\n73E3: Radeon Pro W6600 73FF: RX 6600, 6600M, \u0026amp; 6600 XT 6600無印には対応している可能性があります。\n","date":"2021-10-30T19:03:25+09:00","image":"/uploads/2021/10/71Z50I5bIaL.jpg","permalink":"/posts/13747/","title":"macOS 12.1からRadeon 6600XTが使える"},{"content":"macOS Monterey 12.0.1が配布されたので、Big Surからアップデートしました。最新版のOpenCore (0.7.4) とkext類でBig Surが動いていれば、通常の作業でアップデートできるようです。ここではクリーンインストールしました。\n作業に使ったシステム構成 本日 (日本時間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類は最新にしてあります。\nASRock Z590マザーボードでmacOSを起動する\n現在インストールされているmacOSはBig Sur 11.6 (20G165)です。起動ドライブはWDの1TB M.2 SSD, WDS100T2B0Cです。\nアップデートの手順 上書きインストールすれば楽なのですが、せっかくの年に一度のメジャーアップデートです。現在のBig Sur起動ディスクであるM.2 SSDの内容を綺麗さっぱりと全消去して、クリーンインストールしようと思います。実は、ホームディレクトリは別ドライブに作ってあるので、起動M.2 SSDを消去してもそれほど面倒なことにはならないと考えました。そこで次の手順でアップデートを進めます。\nMontereyインストーラをダウンロードする USBメモリを用意してMontereyインストールUSBを作る USBメモリのESPに現在のESPをコピーして起動できるようにする USBメモリーからインストーラを起動する インストーラからディスクユーティリティを起動し、M.2 SSDを消去する インストーラからMontereyをインストールする 1. Montereyインストーラをダウンロード Big Surの環境から、「システム環境設定」「ソフトウェアアップデート」を開いて、Montereyをダウンロードします。12.13GBあるようです。\nちなみに、「ほかにもアップデートがあります。」の表示が出ています。これをクリックすると11.6.1が来ていました。Montereyをすぐインストールしないという人も、こちらは入れておいた方が良いと思いました。\nダウンロードするといつものように自動的にインストーラが開きます。ここで「続ける」ボタンを押せば上書きインストールが開始します。今回は、クリーンインストールするので、メニューバーから「インストーラを終了」を選び中断します。\n2. MontereyインストールUSBを作る インストーラ用のUSBメモリを用意します。必要な容量は15GB程度ですが、USBメモリの容量は多分32GBはあった方が良いです。今回は32GBのUSB 3.0メモリーを用意しました。このUSBメモリーをディスクユーティリティ.appを使って初期化します。USBメモリを選択して、消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここでAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。Mac OS拡張（ジャーナリング）を選んでおく必要があります。\n次に、MontereyインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもMontereyをインストールできるUSBメモリになります。ターミナルを使用して、Montereyインストーラの中のContents/Resourcesに移動するとcreateinstallmediaというファイルがあります。そこで以下のコマンドを入力します。\n$ 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 \u0026#34;/Volumes/Install macOS Monterey\u0026#34; パスワード入力と、確認のyを押すと、いろいろ進捗して終了します。これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。\n3. USBメモリのESPに現用のESPをコピーする こうして作成したインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。それぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ\u0026amp;ドロップすれば良いです。この先、M.2 SSDは消去しますので、他にも必要なデータがありましたらバックアップしておきます。\n4. USBメモリーからインストーラを起動する これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにMontereyインストーラが見えるはずです。\nただ、OpenCoreでデフォルト通りの設定をしていると、起動ボリュームの一覧にこのUSBメモリが現れないかもしれないです。それはconfig.plistのMisc, Security Properties, ScanPolicyのデフォルト設定が原因です。これのデフォルト値は、0x010F0103 (10進数では17760515) です。この設定だと、2重の理由で、今回のUSBメモリが起動ボリューム候補に現れません。\nまず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。 また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。 なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はPlistEDPlusを使って変更している様子です。\nこれで起動項目にUSBメモリのインストーラが現れるようになります。Montereyアイコンのボリュームが、USBメモリーです。このInstall macOS Montereyを選択して起動します。\n5. インストール先ボリュームを消去する USBメモリから起動すると、下のようなメニューが現れます。\nここでディスクユーティリティを選んで、インストール先M.2 SSDを綺麗さっぱりフォーマットしました。インストール先のAPFSボリュームグループを選択し、名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。\n6. Montereyをインストールする Disk Utilityを閉じると、またメニューに戻ります。次にmacOS Montereyインストールを選択します。するとおなじみのmacOSインストーラが起動します。後は、いつものようにインストールを進めていくだけです。\nインストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。\nこの後数分で再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。\n次にリンゴマークと棒グラフの表示が出ます。\nこの後多分5~6分くらいで、また再起動しました。またmacOS Installerが選択されてます。\nそして数分でまたまた再起動。今度は、インストール先ドライブにつけた名前 (ここではMacintosh HD) の選択肢が現れ、選択されています。これで起動します。\nさらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。あとはいつものように、設定を行ないます。\nインストール終了したあと、このMacについてを確認すると、バージョンは12.0.1 (21A559) でした。リリース候補(RC)と同じビルドでした。\nこれでM.2 SSDから起動します。上の手順では、APFSボリュームグループをフォーマットしてたのでESPの内容は無事でした。ドライブ全体をフォーマットするとESPの内容も消えてしまいます。その場合は、USBメモリのESPの内容を、M.2 SSDの方に書き戻しておきます。\nまとめ OpenCoreで起動しているZ590マシンにMontereyをクリーンインストールしました。そのために、単体で起動してMontereyがインストールできるUSBメモリを作りました。いつものようにベータ版で予行演習していたこともありますが、スムーズにMontereyに移行できました。\n","date":"2021-10-26T12:20:35+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/13688/","title":"MontereyのUSBインストーラを作ってクリーンインストール"},{"content":"OpenCoreの0.7.4が公開されたので0.7.3からアップデートしました。大きな変更は無いので、0.7.3のconfig.plistがそのまま動くと思います。\n0.7.4をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.4とmacOS 11.6で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。macOS 12 public beta (21A5543b) でも動作しました。\nASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.6 .efiファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで設定する項目に変更はありませんでした。ただし、\nMisc/Security/SecureBootModelの設定をDefaultに変更しました。T2チップが乗っていないhackintoshでは、x86legacyに設定するのが良いというニュアンスの表現が、前バージョンの説明書に書いてありました。これに対して、今回のバージョンでは、macOS 12以降は機種に合わせた方が良いという追記がありました。DefaultにしておくとSMBIOSのボードIDの記述に合わせて設定してくれるそうです。（以前のバージョンではDefaultにしておくとx86legacyになってました）いずれにしてもDefaultにしておくのが良いようなので、そうしておきました。SMBIOSがしっかり設定できていないようならば、ここで機種を指定した方が良いかもしれません。 これで、0.7.3から0.7.4に移行できました。\n","date":"2021-10-09T23:46:31+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/13657/","title":"OpenCore 0.7.3から0.7.4に更新"},{"content":"Montereyがなかなか出ないので、Windows 11で遊びました。10で動いているHP EliteDesk 800 G2 DM (Core i5-6500T) を11にアップデートしました。CPUは11に非対応ですが、インストール用USBメモリを作ったらインストールできました。各種設定は、Windowsに慣れていないこともあっていつもながら大変でした。10から11で変わってさらに面倒になったところもありました。\nWindows 11がインストールできない HP EliteDesk 800 G2 DMは、macOSではiGPUが動作しなくて挫折して、Windows 10を入れていました。それでMacからはRemote DesktopでWindowsを使ったり、WSL機能で動かすUbuntuにsshしたりして使っていました。このマシンをWindows 11にアップデートして、設定をやり直しました。\nこのマシンは、普通のアップデートではWindows 11がインストールできません。CPUが非サポートの第6世代なので致し方ないことです。本来ならばサポート対象の第8世代以降のCPUが必要です。でも、USBメモリーにWindows 11のインストーラを作れば可能でした。インストーラ作りは、Windows 10の環境で作業しました。USBメモリは8GBあれば良いようです。\nこのUSBメモリで起動すると、Windowsインストーラが動きます。インストーラのメニューには、過去の設定を引き継いでアップデートする選択肢もありましたが、選択できませんでした。クリーンインストールしなければならないようです。これで特に問題なくWindows 11が動くようになりました。\n以前、Windows 10を設定した時の様子を紹介しました。\nHPの小型デスクトップEliteDesk (6: Windowsを入れる)\n今回もこれに従って、11での各種設定をしていこうと考えました。ただ、色々細かいところが10とは違っていて、少し苦労しました。\nWSL2が動かない WindowsはmacOSと違って、UNIX的な機能や操作が使えなくて残念です。でもWSL (Windows Subsystem for Linux) を使えばLinux機能が動きます。WSLは、LinuxとWindowsが連携できるように結構頑張って作られています。ただ、ファイルシステムもコマンド体系も違うので、macOSのターミナル操作とGUI操作のような一体感は望めないです。\n今まではWSLを使っていたのですが、Windows 11にしたことで、WSL2に移行することになります。WSL2になって、LinuxとWindowsがより統合されたのかと期待したのですが、どちらかというと溝が深まった印象でした。インストールの手間も少し増えました。\nWindows 10でWSLを有効にしてUbuntuを起動するための準備作業は、かなりシンプルでした。\n「コントロールパネル – プログラム – Windowsの機能の有効化または無効化」から「Linux用Windowsサブシステム」にチェックする Microsoft StoreからUbuntu 20.04 LTSをダウンロードして起動する この2ステップだけでした。今回も同様の作業をしてWSLを起動したところ、以下のように\nWslRegisterDistribution failed with error: 0x800701bc ????? 0x800701bc WSL 2 ??????? ????? https://aka.ms/wsl2kernel 謎の文字化けエラーメッセージが出ます。???の部分は正確では無いです。日本語でエラーを出しているけど、表示に失敗しているようです。読める英語部分の文言で検索したところ、「https://aka.ms/wsl2kernelに行ってカーネルコンポーネントを更新しなさい」というエラーのようです。最新の（WSL2 Linux カーネル更新プログラム）パッケージをダウンロードします。後で分かったのですが、StoreにあるUbuntuはWSL用のもので、WSL2では動かないので、WSL2に対応したカーネルパッケージが必要なようです。\nこれを解決すると、次には、仮想マシンの機能を有効にしなさいというようなエラーメッセージが出ます。Windowsの機能の有効化または無効化の項目の2つ上に見えているHyper-Vの設定のことのようです。以前は、以下のように無効でも問題なく動いていました。\nこれを有効にしたところ、WSL2でUbuntuが無事起動しました。これも後で知ったのですが、WSL2からはLinuxがHyper-Vの仮想環境で動作するよう変更になったようです。\nSSHサーバが動かない Ubuntuには最初からsshサーバが入っています。通常のUbuntuならば、sshサーバを以下のコマンドで起動することができます。\nsudo service ssh start WSLの時はこのコマンドで、他のマシン、例えばMacからWindowsマシンのIPアドレスを指定して、WSLのUbuntuにssh接続できました。WSL2ではこれができませんでした。Ubuntuと、同じコンピュータ上のWindowsからも localhostにはssh接続できますが、WindowsマシンのIPアドレスを指定すると接続できません。\nUbuntuでifconfigすると、eth0に見慣れないIPアドレスが設定されています。WSLではWindowsのIPアドレスがそのままLinuxに設定されていたのですが、WSL2では仮想のアドレスが割り当てられるようになったそうです。なので、外部のマシンからWindowsのIPアドレスを指定してもWSLのLinux環境に接続できません。\nWSL2になってから、Linuxは仮想環境で動くようになり、Windowsとは別のIPアドレスが割り当てられるようになったのが、原因のようです。\nhttps://atmarkit.itmedia.co.jp/ait/articles/1909/09/news020.html より引用\nLinuxカーネルにも仮想環境に対応したパッチが当てられているようです。上記で、Hyper-Vが必須になったり、Ubuntuのカーネルを差し替える必要があったのも、これが理由のようです。\nhttps://atmarkit.itmedia.co.jp/ait/articles/1906/14/news019.html より引用\n素人の見解なので的外れなのかもしれませんが、VMwareとかVirtualBoxなどの仮想化ソフトウェア製品やDockerなんかと代わり映えしない気がしてしまいました。Linux環境がもっとWindowsにガチガチに絡みついて、よりシームレスに一体化して欲しかった気がします。\n話を戻しますと、外部からssh接続できない問題は、WindowsマシンのIPアドレスを指定しても、WSL2のLinux環境に接続できないことでした。WSL2は独立した仮想のネットワークに接続されているからです。さらに厄介なことに、WSL2がLinuxに割り当てるアドレスは、起動するたびに変化するらしいです。\n色々検索したところ、解決策はあるようでした。以下で紹介されていました。Windows側から、Ubuntu側にポートフォワーディングする設定です。これで、sshの22番のアクセスが来たら、Ubuntuのアドレスの22番に送ります。\nwsl2でsshサーバを起動し、外部からそこに接続 - Qiita\nまずは、Ubuntu側に、自分のIPアドレスを取得して、Windows側のポートフォワード機能に登録するスクリプトを書きます。ホームディレクトリに適当な名前をつけて保存します。\n#!/bin/bash IP=`hostname -I` netsh.exe interface portproxy delete v4tov4 listenport=22 netsh.exe interface portproxy add v4tov4 listenport=22 connectaddress=$IP sc.exe config iphlpsvc start=auto sc.exe start iphlpsvc hostnameコマンドからIPアドレスを取得して変数IPに入れて、それを使ってWindowsのnetshとscコマンドで設定しています。次に、このファイル（例えば /home/bootmacos/port_f22.sh ）を、Windowsから起動するバッチファイルを書きます。ついでにsshdを起動しておく記述も加えておきます。\n@echo off WSL -u root -- service ssh start WSL --exec /home/bootmacos/port_f22.sh そして、Windowsを起動したときに、このバッチファイルが管理者として実行されるように設定します。コントロールパネル–\u0026gt;システムとセキュリティ–\u0026gt;Windowsツール–\u0026gt;タスクスケジューラに行き、ここで「スタートアップ時（システム起動時）に」「ログインしているかどうかにかかわらず実行する」設定で、バッチファイルを登録します。結構ややこしいです。Windows 10では「管理ツール」という名前だったのが11では「Windowsツール」に名前が変わっていたりしました。\nこれにより以下のように処理が行われます。\nWindowsが起動するとバッチファイルが動く バッチの中で、Linuxコマンドでsshdを起動する バッチの中で、Linuxのシェルスクリプトを起動する シェルスクリプトの中でIPアドレスを取得してWindowsコマンドでポートフォワードを設定する となります。WindowsとLinuxを行ったり来たりしてややこしいです。参考にしたサイトでは、全部の作業をWindowsバッチファイルで行う方法も紹介されていましたが、試したところ動作が不安定でした。\nsshdが起動するように設定するには、Linuxならコマンドひとつ、macOSだと「システム環境設定」「共有」で「リモートログイン」をクリックするだけです。sshdの設定は、WSLでも結構面倒だったのですが、WSL2ではさらに大変でした。でもこれで、今まで通り、電源を入れるだけで、ssh経由でUbuntuに接続できるようになりました。\nWake On LANが動かない WOLの設定も、いつもながらややこしいです。でもこれは10の時から変更点はありませんでした。\nこのマシンには、IntelのI219-LMというネットワークアダプター(NIC)チップが使われています。Windows 11には標準でNICのドライバが入っているのですが、この標準ドライバではWOLが動作しません。IntelやHPのサイトからダウンロードしたドライバならWOL可能です。このことをすっかり忘れて、ネットを検索して試行錯誤してしまいました。最初から、自分の書いた記事をちゃんと読めば良かったです。\nWOLに対応するドライバを探すために、チップセット名などで検索しました。そして以下のIntelのサイトからドライバをダウンロードしました。\nWindows® 10 用インテル®・ネットワーク・アダプター・ドライバー\nWindowsのデバイスマネージャからこのドライバを入れようとすると、「すでに最新ドライバが入ってます」と言われてインストールできませんでした。ダウンロードした一式に入っているインストーラでインストールしました。\nこの結果、デバイスマネージャの設定でWOLを有効できるようになります。以下のスクリーンショットでは、Wake On Magic Packetが有効になるように設定しています。このほか「電源の管理」タブでもWOL関連の設定がありますが、多分デフォルトでokです。\nBIOSにもWOLに関係する設定があります。こちらは、既に設定済みなので、今回は作業不要でした。\n以前、Homebridgeを導入したのですが、\nHomebridgeにはWOLによりコンピュータ機器の電源を投入するプラグインがいくつか公開されています。その中から、Homebridge Wolというプラグインを使ってます。\nGitHub - AlexGustafsson/homebridge-wol: A Wake on Lan plugin for Homebridge\nこれにより、HomeKitからWindowsマシンの電源を投入し、On/Offの状態を確認できました。下はMacのホーム.appの画面です。Siriにお願いしてWindowsの電源を入れることも可能です。\nBIOSもアップデート ついでにBIOSもアップデートしておきました。HP EliteDesk 800 G2 DMのBIOS画面に、ネットワークから最新BIOSをダウンロードして更新するメニューがあります。クリックするだけで最新版 (2021/4/16版のN21 02.53) になりました。\nまとめ 暗黒画面問題で頓挫したHP EliteDeskは、とうとうWindows 11マシンになりました。10より画面が洗練されて、良くなった気がします。引き続き、このマシンにはディスプレイを接続せず、macOSからMicrosoft Remote Desktopとssh経由で使用する予定です。\n","date":"2021-10-09T16:53:58+09:00","image":"/uploads/2020/03/hp800g2dm.jpg","permalink":"/posts/13641/","title":"HPの小型デスクトップEliteDesk (7: Windows 11を入れる)"},{"content":"macOS Big Sur 11.6が配布されたので11.5.2からアップデートしました。通常の方法で、問題なくアップデートできました。アップデートしたのはZ590マザーボードのマシンです。OpenCore 0.7.3で起動していて、kext類は最新です。Montereyがまもなくリリースされると思われますので、これがBig Sur最終版になるのかもしれません。過去のアップデート情報は以下にあります（現時点では11.6の解説はありません）。\nhttps://support.apple.com/ja-jp/HT211896 iMac20,1に設定してあるZ590マシンでは、11.5.2のシステム環境設定の「ソフトウェア・アップデート」に、11.6のアップデートがあらわれていました。「詳しい情報…」をクリックすると、簡単に「macOSのセキュリティが向上します」と説明されてます。\nこの画面から「今すぐインストール」ボタンを押してアップデートしました。その結果、2.64GBのアップデートファイルがダウンロードされ、複数回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.6が起動しました。ビルドは20G165になってました。\n","date":"2021-09-14T23:11:29+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/13540/","title":"BIG SUR 11.6にアップデートする"},{"content":"ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けたマシンをメインマシンとして使うことにしました。そこで、今まで使っていたASUS Z390 ROG MAXIMUS XI HEROマザーボードと交換しました。\n絶対動くはず Z390 Coffee Lake-S Refreshで動かすmacOSは、とても安定していて全く問題ありませんでした。なのでZ590に移行する必要性はあまりありませんでした。単に、macOSが動く最後のインテルCPUになるかもしれないComet Lake-Sに移行したかっただけです。とはいえ、8コア16スレッドから10コア20スレッドになるのは、その性能が必要かどうかは別として、嬉しいところです。なので、Z590への移行を以前から計画してました。\n移行のために、ASRock Z590 Extremeを検証台（いわゆる、まな板です）で動かして、動作確認してきました。こちらもZ390同様にとても堅牢で安定しています。数日起動し続けても問題ありません。Montereyベータ版も問題なく動作しているので、将来にわたって大丈夫そうです。\n今回はいよいよ、検証台のASRock Z590 Extremeを取り外し、PCケースの中のZ390マザーボードと差し替えることにしました。どちらも快調に動いている構成のマザーボードを入れ替えるだけなので、問題は何もなく、すぐに絶対動くものだと思っていました。\n一部のSATAが動かない メインのマシンは、大型のタワーケースで、HDDやSSDをたくさん搭載しています。TimeMachineのバックアップ用大容量HDDや、Windows起動用のSSDなどです。光学ドライブも搭載してます。リムーバブルHDD/SSD用の5.25インチベイも取り付けてます。ASRock Z590 Extremeは、今時のマザーボードとしては珍しくSATAが6ポートあります。今までのASUS MAXIMUS XIと同じ数なので、移行は楽勝のはずでした。でも、6個のうち2個が動きません。\nちゃんとマニュアルを読んでおけばよかったのですが、ASRock Z590 Extremeマザーボードは、3番目のM.2ソケットを使うと、SATAの2個が使えなくなる仕様でした。M.2とSATAに排他的な制約があるのはなんとなく理解してましたが、SATA M.2 SSDを使った場合だけの制約だと勝手に解釈してました。PCIe接続のM.2 SSDを使用した場合でも、2個のSATAが使えなくなるようです。\nということで、M.2 SSDを2番目の（マザーボード中心の）ソケットに移動しました。今の所M.2 SSDは一個しか使ってないのでこれで良いですが、多数のM.2 SSDを使用する場合には、足りないSATAをPCIeカードで拡張しようと思います。\n起動が遅い マザーボードを入れ替えてすぐに気づいた問題は、新しいASRockマザーボードの起動に時間がかかることです。電源を入れるとASRockのロゴが瞬時に出るのですが、その状態が続き、1分くらいかかってOpenCoreの選択画面が表示されます。F2キーでBIOSメニューに入る場合も、同じだけの時間がかかります。この状況から見て、macOSの問題でも、OpenCoreの問題でもなく、ハードウェアかUEFIの問題と思われます。ASRockのロゴを出さないよう設定すると、起動進捗のコードが画面右下に表示されるのですが、この情報からは原因を推測できませんでした。\nこのマザーボードを検証台で動かしていた時には、起動に時間がかかる問題はありませんでした。PCケースへの引っ越しで新たに追加されたハードウェアが原因と思われます。起動時に少し待てば良いので、我慢できなくはないのですが、OpenCoreやkextの設定を試行錯誤して試す場合には、効率が悪いです。そこで一つ一つ外して起動の様子を観察することにしました。\nSATAドライブ まずはSATA接続のSSD/HDDを全て外しました。HDDの調子が悪くなると、起動時のチェックに問題が出て、時間がかかることがあるそうです。全部外して、検証台での動作と同じくM.2 SSDだけで起動しても、やはり起動時間が長いままでした。原因は他にあるようです。\nメモリー メモリーに問題がある場合もあるようです。でも今回は、検証台で使っていたメモリーをそのまま持ってきたので問題ないはずです。\nUSBデバイス 次に、USB関係を外しました。以下で紹介した5.25インチベイ取り付けのUSBハブ／カードリーダなどを取り付けてました。でもUSB関係の部品を外しても変化はありませんでした。\nUSB機器がスリープを阻害することがあります\nPCIe拡張カード 今度はPCIeスロットに挿した拡張カード類です。無線カードは以下で紹介したように、BCM94360NGをM.2 key Eソケットに取り付けていて、PCIeスロットは使ってません。マザーボードに取り付けたまま持ってきたのでこれは問題ないはずです。\nASRock Z590 Extremeに無線モジュールを取り付ける\nThunderbolt 4カードも取り付けてます。これも検証台の時から使っていたので問題ないはずです。一応取り外しましたが、起動時間に変化はありませんでした。\nmacOS で Thunderbolt 4 を使う\n引っ越しで追加になったカードは、IEEE 1394カードと、\nIEEE 1394 (FireWire) を使う\nSATA拡張カードです。\nPCIe拡張カードでSATAを増設する\nIEEE 1394は、全く使ってないのですが、大昔のiPodやSONYのビデオカメラが動いて面白いのでそのまま取り付けてます。古いカードなので怪しかったですが、取り外してみても変化ありませんでした。\nSATA拡張カードが原因 最後にSATA拡張カードを取り外したところ、なんと、一瞬で起動するようになりました。上記の記事では紹介していませんでしたが、実は、HighPoint社の Rocket 640LというSATA拡張カードを取り付けていました。macOSの /Library/Extensions には、HighPoint関係のドライバーが入っているので、macOS標準で動作します。これが問題を起こして、起動に時間がかかっているようです。検索すると、価格コムのレビューが見つかりました。UEFIに対応してなくて、現行のマザーボードとの相性が悪いようです。Z390マザーボードの時は、起動時間の問題は発生しませんでしたが、これに接続したリムーバブルベイに取り付けたHDD/SSDから起動できなかったです。そこで、上記の記事でも紹介したASMedia ASM1061搭載の格安SATA拡張カードに差し替えたところ、問題なく起動しました。このカードもmacOS標準のままで動作します。\nまとめ 起動時間が異様に長くなる現象は、自作PCではよくあるトラブルのようです。今回は使用していたPCIeカードが古かったのが原因でした。最小構成になるまで、一つ一つ部品を取り外して動作チェックする定番の方法で原因究明できました。\n","date":"2021-09-12T22:32:01+09:00","image":"/uploads/2021/03/Z590-ExtremeL6.jpg","permalink":"/posts/13529/","title":"メインマシンをASRock Z590 Extremeに移行"},{"content":"OpenCoreの0.7.3が公開されたので0.7.2からアップデートしました。config.plistのUEFI/Driversの書き方が変更になったので対応が必要です。それ以外には大きな変更は無いので、0.7.2のconfig.plistがそのまま動くと思います。\n0.7.3をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.3とmacOS 11.5.2で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASRock Z590 Extreme + 10900K + Radeon 5700XT + macOS Big Sur 11.5.2 .efiファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで設定する項目の変更点は、以下の2箇所でした。\nUEFI/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の書き方です。\n0.7.3からは以下のように変更になりました。\nこれで、0.7.2から0.7.3に移行できました。\n","date":"2021-09-10T18:01:51+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/13517/","title":"OpenCore 0.7.2から0.7.3に更新"},{"content":"macOS Big Sur 11.5.2が配布されたので11.5.1からアップデートしました。通常の方法で、問題なくアップデートできました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.7.2で起動していて、kext類は最新です。11.5.2が配布されたのは、8月11日(PST)です。\nhttps://support.apple.com/ja-jp/HT211896 更新内容は、簡単に「Macのバグ修正が含まれている」と説明されてます。\niMac20,1に設定してあるZ590マシンでは、11.5.1のシステム環境設定の「ソフトウェア・アップデート」に、11.5.2のアップデートがあらわれていました。そこから「今すぐインストール」ボタンを押してアップデートしました。その結果、2.54GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.5.2が起動しました。ビルドは20G95になってました。\niMac19,1に設定してあるZ390マシンには、システム環境設定には11.5.2のアップデートが現れていませんでした。11.5.1の時と同様で、Monterey betaを受け取るためにApple Beta Software Programに登録してある影響と思われます。今回も、App StoreからBig Surを選択したところ、11.5.2へのアップデートが来ました。この場合、フルサイズのOSがダウンロードされるようで、サイズが12.44GBありました。\n","date":"2021-08-17T22:38:52+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/13462/","title":"BIG SUR 11.5.2にアップデートする"},{"content":"「いま一番おすすめの自作MACOS PCパーツ構成」という記事を書いてから1年経ってしまいました。状況が色々変化しているので2021年版として更新します。前回同様、「一番」と言うお題なので、無理して一つ選んで、その後に言い訳や代替案を書きました。ご意見・ご異論あると思いますのでコメントでお知らせください。\nなお、いろいろな作例をBUILDSのカテゴリーでまとめてあります。\n逆風の1年 思い返せばこの1年は色々ありました。まずはM1 Macが実際に発売されて大評判でした。CPU性能が予想以上に優れていて、iGPUもIntel内蔵GPUに比べたら圧倒的に高性能でした。Mac mini全モデル, MacBook下位モデル、iMac下位モデルはM1に置き換わるとは予想していましたが、これだけM1の性能・評判が良いと、Mac上位機種は今のままでしばらくは更新されないかもしれません。その結果、メインストリームIntel CPU搭載のMacはもう発表されない可能性もあります。とはいえ今のM1は拡張性が無いので、Intel CPUで自作するメリットはまだあると思います。将来のmacOSではIntel CPUが使えなくなる予定ですが、次世代のMac ProもXeon W-3300シリーズだという噂もあります。まだしばらくは、macOSでのIntel CPUサポートは継続されると思います。\nもう一つは、マイニングブーム再燃と半導体不足の影響で、グラフィックスボードが高騰していることです。多少は市場が落ち着きつつあるようですが、それでもまだまだ高価です。Radeon RX570/RX580の中古ですら3万円〜4万円で取引されている状況です。Windowsで自作する人たちを含めて、自作PCに向いていない時期です。\nそのような状況ですが、お勧めの自作最新パーツ構成を考えてみます。\nCPU: Intel Core i9-10850K または 10900K 現行のMac製品の中で最新Intel CPUを搭載しているのがiMac20,1と20,2です。Intelの第10世代CPU (Comet Lake-S) である10500, 10600, 10700K, 10910を搭載しています。このうち市販されているCPUは10500, 10600, 10700Kですので、これらを使用すれば、実機と同じCPUで自作できます。10910は、Appleが特注したCPUらしく、市販されていません。後述のように10910は、10900Kより若干低い性能で、10850Kと同等性能のようです。10900Kより性能が下がっているのですが、下位モデルと思われたくなくて数字を上げて10910としたのではないかと勘ぐってます。ということで、10850K, 10900Kなども問題なく動くと思われます。\n一方、tonymacx86のUltimate Buyer’s Guideでは以下のCPUが推薦されています。（太字は特にお勧めできると考えたCPUです）\n10900K (3.7Ghz / 10 Cores / 20 Threads) 10850K (3.6Ghz / 10 Cores / 20 Threads) 10900 (2.8Ghz / 10 Cores / 20 Threads) 10700K (3.8Ghz / 8 Cores / 16 Threads) 10700 (2.9Ghz / 8 Cores / 16 Threads) 10600K (4.1Ghz / 6 Cores / 12 Threads) 10600 (3.3Ghz / 6 Cores / 12 Threads) 10500 (3.1Ghz / 6 Cores / 12 Threads) 10400 (2.9Ghz / 6 Cores / 12 Threads) 10320 (3.8Ghz / 4 Cores / 8 Threads) 10300 (3.7Ghz / 4 Cores / 8 Threads) 10100 (3.6Ghz / 4 Cores / 8 Threads) このリストのどれを選んでも安定して稼働すると期待できます。今回は推薦CPUとして10850Kを選びました。理由は、どうせ自作するならM1に勝つ最強マシンにしたかったからです。M1のGeekbench 5スコアは、シングルコア性能で1700、マルチコア性能で7400くらいです。第9, 10世代のIntel CPUはどれもシングル性能で勝てない（1250くらい）ですが、マルチなら10600, 10700あたりが近いスコアを出しています。10コアの10850Kと10900Kならば、マルチが10000を超えるので、M1に勝てると考えました。\n10900Kの方が10850Kより高性能です。ただその差は、クロック数で2%~3%違うだけです。同じウェハーから作って選別しているという推測から、10900Kの方がオーバークロックには強そうですが、定格で使う限りは性能差は誤差程度だと思われます。価格差に見合う性能差ではありません。でも、潔く最高の性能を目指すなら10900Kが良いと思います。（追記：最近の価格を再度調べたら、10850Kは値上がりし、記事執筆時に比べて、10900Kとの価格差が大幅に縮小してました。現時点なら10900Kのほうが良いと思います。2021/11/12）\nProduct Specifications\nProduct Specifications\n一方、10850KとiMacに搭載された10910のスペックはおそらく完全に同一です。特注品の10910に相当する市販製品が10850Kだと考えることができます。\nProduct Specifications\niMac発売当時は10850Kが発表されていませんでした。おそらくは排熱の制約からクロックを下げた10900Kが欲しかったAppleは、やむを得ず10910を特注したのかと思います。後に10910相当品をIntelが商品化したモデルが10850Kだと思われます。なので、10850Kにすれば最上位iMac20,1, 20,2と可能な限り同じ構成にできる点も多少嬉しいです。\nM1に対抗する必要はないと考えるのでしたら、コストパフォーマンスの良い、10700K, 10400がおすすめかと思います。kakaku.comを見ると、10400, 10700, 10100, 10700Kあたりが売れ筋上位にあるようです。iMac20,1に搭載されている10600, 10500は、初期の製品であるためなのかあまり売れていないようです。これらの上位、下位製品の10700、10400の方がコストパフォーマンスが良いと考えられているのだと思います。\n10850Kを選んだもう一つの理由は、IntelメインストリームCPUでは最強だからです。Intelの現行製品はすでに第11世代に移行しています。第10世代に比べて、シングルコアの性能は上がったものの、10コア製品が作れなくて、マルチコア性能では10900Kや10850Kに負けています。第11世代がイマイチな出来だったので、すぐに第12世代に移行するらしいですが、引き続きマルチコア性能で10900K, 10850Kに負けているという噂が流れています。第10世代10コアを選んでおけば、しばらくは新製品に性能負けしないのが嬉しいです。実際に10コアあると仕事が捗るというような事情は全くありませんが、ロマンです。\nちなみに現行の第11世代のCPUは、macOSで動く報告があります。ただし、CPU IDを書き換える必要があるようです。また、macOSが第11世代をサポートしていないので、そのiGPUも使えないそうです。今後のiMacが第11世代を搭載するまでは（その可能性は低いですが）、第11世代を採用するメリットは少ないと思います。\nマザボ：ASRock Z590 Extreme CPUに第10世代を採用するなら、マザーボードのチップセットは400番か500番シリーズになります。ZタイプのチップセットならZ490かZ590が第10世代対応です。Z590は第11世代にも対応しています。第11世代ではCPUから周辺チップへのバス性能が向上して、ほとんどのZ590ボードではCPU直結のM.2 SSDソケットが用意されています。第10世代CPUではこのソケットが使えず無駄になるデメリットはあります。ただ、売れ筋はZ590に移行していますし、将来、第11世代に移行することも考えるとZ590マザーボードを選んでも良いと思います。macOSとの互換性も問題ありません。\nそれでお勧めのマザーボードとしてASRock Z590 Extremeを選びました。この製品にはWiFi付きのASRock Z590 Extreme WiFiもありますが、WiFi無しがお勧めです。（WiFi付きは今は国内に流通していない様子です）以下の記事と、それに引き続く記事にあるように、現在手元で使っているマザーボードです。\nASRock Z590マザーボードでmacOSを起動する\n選んだ理由も上記の記事で詳しく説明しました。要約すると、\nPCIeスロットの数が多い こなれた有線LANチップ搭載でmacOS互換性が高い 見た目がスッキリしている macOS互換の無線用key Eソケットとアンテナ穴がある のがこれを選んだ理由です。詳しくは上記の記事をご覧ください。\nほぼ同じ機能のASRock Z590 Steel Legendも良いと思います。違いは、1GbE 有線LANが省かれて、サウンドチップがALC 1220からALC 897にダウングレードしているくらいです。そのため少しだけ安いです。PCIeスロットが多く、有線LANチップ、無線カードソケットの互換性が高い点はExtremeと同じです。デザインは、個人的にはExtremeの方が好きです。でも白いコンピュータを作りたい場合は、こちらが良いです。Steel Legendは、2,000円高いWiFiモデルも国内流通してます。互換性の高い無線カードに置き換える場合でも、アンテナ配線の手間を省くためにWiFiモデルを買うのもありかもしれません。\nグラボ：Radeon RX 6600 XT macOS Monterey 12.0.1がサポートしている現行グラフィックスボードは、Radeon RX 6800, 6800 XT, 6900 XTのみで、どれも価格は最低でも15万円です。しかし、macOS 12.1からは、RX 6600, 6600 XTがサポートされることになりました。\nmacOS 12.1からRadeon 6600XTが使える\nRadeon RX 6600 XTをmacOSで使う\nなぜかRX 6700はサポートされませんが、ローエンドの6600が対応したことで、お手頃な価格で入手可能になりました。\n上記の記事で紹介したように、6600 XTでも、Radeon RX 5700 XTを超える性能が得られます。ベンチマークスコアでM1 Maxにも勝てます。12.1以降ならば非常に安定して動くのでおすすめです。予算に余裕があるなら、6800, 6800 XT, 6900 XTも良いです。6600に比べて3倍近い性能があるとのことです。\nグラボの価格がさらに落ち着くまで、iGPUで凌ぐのも良いかもしれません。でも最近のiGPUは設定が結構大変です。実はこの記事に先立って、10900KのIntel UHD Graphics 630の設定を試みたのですが、うまく動かなくて挫折しました。すでにグラボを持っていて、頑張るモチベーションが足りないこともありますが、なかなか難しいと思いました。\n6600でも予算オーバーという場合は、互換性のある古いカードを中古やオークションで探すのも良いかもしれません。以下の記事にmacOSと互換性のあるボードが説明されています。例えばNVIDIAのKeplerシリーズなら動きます。\nmacOSのためのGPUの選び方\nただしMontereyからKeplerがサポートされなくなりました。古いドライバを持ってくることで動かすことは可能です。\nReleases · chris1111/Geforce-Kepler-patcher\n無線モジュール：Fenvi FV-T919 これは迷うところはないです。WiFi/Bluetoothが、取り付けるだけですぐに動きます。設定やkext類が不要です。macOSにはWiFi/Bluetoothが前提の機能がありますので、互換性の高い無線モジュールが必要です。詳しくはこちらを。\nWiFi/BluetoothアダプタFenvi FV-T919\nマザーボードにASRockのZ590 ExtremeやZ590 Steel Legendを使う場合は、BCM94360NGを使うのも良いと思います。このカードはmacOSでそのまま機能する唯一のM.2用WiFi-Bluetoothモジュールです。これも取り付けるだけでそのまま動いて、Apple IDやiPhone連携、MontereyのAirPlayサーバーなどが問題なく動きます。\nASUS, GIGABYTE, MSIの、Z490/Z590マザーボードのM.2 key Eソケットは、CNVi専用の場合が多く、動かない可能性があるので注意が必要です。ASRockは従来型のM.2 key E無線モジュールを引き続きサポートしてくれているのでBCM94360NGが動作します。詳しくはこちらの記事をご覧ください。\nASRock Z590 Extremeに無線モジュールを取り付ける\nこの他のパーツ M.2 SSDに関しては、SamsungのNVMe SSDは避けた方が良いようです。 WD SN750 や SN850 などは確実なようです。それ以外のパーツ、例えばメモリー、電源、HDD、CPUクーラー、などは大体どれでも良いです。メモリーは16GBもあれば十分です。電源は600Wくらい、起動ドライブはSSDがおすすめで256GBあれば当分は使えて、最低必要なのは30GBくらいです。一般の自作PCでの評判を参考に適当に選んでください。\n現在のM1搭載Macでは、メモリーも内蔵SSDも購入時に容量を決めた後は増設できません。しかもかなり高価です。自作する場合にメモリー、M.2 SSDをより多く確保すれば、自作のメリットがより大きくなります。\n","date":"2021-08-08T17:39:10+09:00","image":"/uploads/2017/10/20171029113120.png","permalink":"/posts/13383/","title":"いま一番おすすめの自作macOSパーツ構成 (2021年版)"},{"content":"OpenCoreの0.7.2が公開されたので0.7.1からアップデートしました。大きな変更は無いです。Montereyの起動で問題になっていたSecure Boot modelのデフォルト設定が変更されて、Monterey起動に対応したようです。新OS対応が進捗している様子です。\n0.7.2をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.2とmacOS 11.5.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASUS 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ファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで設定する項目の変更点は、以下の1箇所だけでした。\nUEFI/AppleInputにGraphicsInputMirroringという項目が追加されていました。非Apple製のグラフィックUEFIアプリケーションにキーストロークが伝わらないことを改善したようです。例えば、WindowsのBitLockerを使う場合に影響が出るそうです。デフォルト値はfalseですが、説明書によるとtrueが推奨値らしいです。Sample.plistでもtrueになってました。macOSを使う限りはfalseでも問題なさそうですが、とりあえず推奨値のtrueに設定しておきました。 これで、0.7.1から0.7.2に移行できました。\nSecureBootModelの設定 設定できる値 Apple Secure Bootの機能では、macOSを動かすMacのモデルでは無効な設定や、動かないmacOSバージョンのインストールを防ぐ働きをするようです。config.plistのMisc, Securityの中の SecureBootModelで、Macのモデル名の設定をします。ここで設定できる値は、OpenCoreのマニュアルによると以下です。\nDefault — 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が該当します。\nApple T2 セキュリティチップ搭載モデルの Mac\n自作PCには当然ながらT2チップを搭載していないので、x86legacyの設定が良さそうです。ただし、x86legacyに設定するとmacOS 11.0.1以降のみしか起動しません。古いmacOSを使いたい場合は、SystemProductNameで設定したモデル名がT2搭載ならば、jから始まる選択肢を設定しても良いかと思います。11.0.1より古いmacOSをT2未搭載モデルで使いたい場合は、SecureBootModelをDisabledに設定すると良いです。DisabledにするとApple Secure Boot自体が無効になります。\nSecureBootModelをDefaultにすると、一番無難な選択肢を選んでくれるようです。OpenCore 0.7.1では、Defaultにするとj137、すなわちiMacPro1,1に設定されていました。OpenCore 0.7.2では、Defaultにするとx86legacyに設定されるよう変更されました。\nMontereyインストールの注意事項 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のインストールが可能だったのではと思います。\nZ590とZ390の設定 iMac20,1に設定してあるASRock Z590 Extreme + 10900Kマシンは、機種名に合わせて j185に設定してみました。j185に設定すると、Montereyのインストールは失敗しますが、インストールされたMontereyは起動します。なのでMontereyをインストールするときだけはx86legacyに設定する必要があります。\niMac19,1に設定してあるもう一台のZ390マシンは、T2チップ未搭載なのでDefaultにしておきました。現行のmacOSしか使わない予定なのもDefaultにした理由です。もしもこのマシンでmacOS 11.0.1より前のmacOSを起動したい場合は、Disabledに設定する必要があると思います。\n","date":"2021-08-04T23:50:15+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/13351/","title":"OpenCore 0.7.1から0.7.2に更新"},{"content":"Public Beta Programで配布されているmacOS Monterey 12.0 Beta（21A5294g）をダウンロードして、ASRock Z590 + 10900K + OpenCore 0.7.1で構成した自作PCにインストールしました。config.plistでSecureBootModelを無効に設定する必要がありました。新機能のAirPlayレシーバーが動作することを確認しました。\nダウンロード Big Surを動かしているZ590マシンをPublic Beta Programに登録したところ、システム環境設定のソフトウェアアップデートにMontereyが現れました。サイズは11.73GBでした。\n1時間弱でダウンロードは終了し、ダウンロード後にインストーラが起動します。それは中断します。するとApplicationフォルダにInstall macOS Monterey beta.app（日本語名はmacOS Montereyベータ版インストール.app）というアプリケーションができています。\nインストール用USBメモリを作る 次に32GB容量のUSBメモリを用意しました。これをGUID, Mac OS拡張（ジャーナリング）でフォーマットし、ここではusbという名前をつけました。ターミナルでInstall macOS Monterey beta.appの場所にcdします。この中のContents/Resourcesの中に\n% cd /Applications/Install\\ macOS\\ Monterey\\ beta.app % cd Contents/Resources/ お馴染みのcreateinstallmediaコマンドがあります。オプションなしで起動すると、ヘルプが表示されます。\n% ./createinstallmedia Usage: createinstallmedia --volume \u0026lt;path to volume to convert\u0026gt; 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はファームウェア関係のファイルをダウンロードする機能のようです。無効にしたところ、後の工程で失敗したので、有効にした方が良いようです。\n% sudo ./createinstallmedia --volume /Volumes/usb --downloadassets とタイプします。これで用意したusbメモリが初期化されて、そこにMontereyのインストーラが作られます。\nインストール 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メモリのインストーラが現れました。\nこれを選択すると無事、インストーラが起動しました。インストーラの中でディスクユーティリティを起動して、新しく取り付けたM.2 SSDをGUID, APFSでフォーマットしておきます。次に、インストーラでMontereyのインストールを進めます。いつものようにUSBメモリからの作業が終了すると、再起動し、次にインストール先のSSDから起動します。\nSecureBootModelを無効にする ここまでは順調だったのですが、インストール先SSDからの起動途中で失敗して、再起動されるようになってしまいました。何度も何度も再起動が繰り返されます。USBインストーラを使わない方法（11.5の環境からMontereyインストーラを起動してSSDにインストール）を試みても、やはり再起動で失敗します。それで暫くつまづいていました。でも、これはよく知られた症状のようで、このサイトのフォーラムでも解決方法が紹介されています。灯台下暗しでした。（kgraphさん、ありがとうございました）\nmacOS Monterey\nMontereyのインストール途中で再起動が繰り返される問題は、config.plistのMisc, Securityの中の SecureBootModelの設定をDisabledにすれば良いようです。今まではDefaultに設定していました。これで無事インストールが進み、Montereyが起動しました。起動のセキュリティが仕様変更されたか、もしくは厳しくなったようです。\n追記：SecureBootModelがDefaultでも起動が可能 OpenCore 0.7.2からはSecureBootModelの設定がDefaultでも起動可能になったようです。以下をご覧ください。\nOpenCore 0.7.1から0.7.2に更新\nAirPlayレシーバーが動く Montereyの新機能にAirPlayレシーバーがあります。Montereyの英語ページで「AirPlay to Mac」という名前で紹介されている機能です。ちなみに日本語ページでは「MacにAirPlayを」です。これで他のApple製品から音楽や動画をMacで再生できます。今まで、HomePodやAppleTVでできていた機能が、Macでも可能になりました。\nMontereyでAirPlayレシーバーを動かすためには、本物のMacやM1のセキュリティチップが必要なのではという推測もありましたが、自作PCでも動きました。おそらくは他のiOS連携機能と同じく、無線モジュールが純正に近い必要があるのかもしれません。試したマシンでは、BCM94360NGを使用してます。\nASRock Z590 Extremeに無線モジュールを取り付ける\nMontereyの「システム環境設定」から、「共有」を選ぶと選択肢の中に「AirPlayレシーバー」が新たに現れています。これを選択して、一番緩い設定の「すべての人」にAirPlayを許可しました。ベータ版の利用規定の関係でスクリーンショットは省略します。\nこれでiPhoneなどから動画などをhackintoshに映し出すことが可能になりました。また、MacBookなどから接続すれば、外部ディスプレイのようにも設定できます。画面のミラーリングもできるし、2番目のサブスクリーンにもなります。ただし、コンテンツ保護には元々対応させていなかったので、Amazon Primeビデオなどは表示できませんでした。WhateverGreen.kextなどの設定を頑張ってコンテンツ保護に対応すれば対処できるのかもしれません。YouTube動画などは問題なく表示されました。\n","date":"2021-08-02T23:14:54+09:00","image":"/uploads/2021/07/icon512.png","permalink":"/posts/13259/","title":"macOS Monterey 12 Beta をインストール"},{"content":"macOS Big Sur 11.5と11.5.1が配布されたので、遅ればせながら11.4からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.7.1で起動していて、kext類は最新です。\n更新内容 7月21日に11.5のアップデートが配布されて、7月26日に11.5.1が配布されています。\nhttps://support.apple.com/ja-jp/HT212602 https://support.apple.com/ja-jp/HT212622 11.5は、PodCast、Music、M1関連のバグ対応で、\n11.5.1はセキュリティ関連のアップデートのようです。\n11.5.1へアップデート iMac20,1に設定してあるZ590マシンでは、11.4のシステム環境設定の「ソフトウェア・アップデート」に、11.5.1のアップデートがあらわれていました。そこから「今すぐインストール」ボタンを押してアップデートしました。その結果、2.93GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.5.1が起動しました。ビルドは20G80になってました。\n11.5へアップデート iMac19,1に設定してあるZ390マシンでは、11.4のシステム環境設定の「ソフトウェア・アップデート」に、11.5のアップデートがあらわれていました。11.5.1は来ていないようです。そこから「今すぐインストール」ボタンを押してアップデートしたところ、1回の再起動でアップデートされました。放置しておいたら、Big Sur 11.5が起動しました。ビルドは20G71になってました。このマシンにも11.5.1へのアップデートがそのうちに来るのではと思ってます。\n追記：11.5.1へのアップデート Z390マシンのアップデートがなかなか来ないので、結局App StoreからBig Surを選択したところ、11.5.1へのアップデートが来ました。自動的に再起動して、問題なくアップデートできました。自動でアップデートが来なかったのは、Monterey betaを受け取るためにApple Beta Software Programに登録してある影響だったのかもしれません。\n","date":"2021-07-31T17:46:24+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/13324/","title":"BIG SUR 11.5.1にアップデートする"},{"content":"OpenCoreの0.7.1が公開されたので0.7.0からアップデートしました。config.plistの変更点は2箇所のみで、OpenCanopy関連の変更もありませんでした。macOS Montereyへの対応が進んだようです。\n0.7.1をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。更新点には、macOS Montereyに対応した項目が多くありました。新OSに向けて準備が進んでいる様子で楽しみです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.1とmacOS 11.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASUS 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ファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで設定する項目の変更点は以下でした。\nACPI/QuirksにSyncTableIdsという項目が追加されていました。古いWindowsのライセンス関係に影響するSLICテーブルの互換性に関する項目のようです。特に問題を感じていないので、デフォルトのままfalseにしておきました。 Kernel/SchemeにCustomKernelという項目が追加されていました。ESPにカスタマイズカーネルのキャッシュを作ってくれる機能のようです。AtomやAMDのCPUの場合に必要となる可能性があるようです。手元のマシンでは当てはまらないのでデフォルトのままfalseにしておきました。 これで、0.7.0から0.7.1に移行できました。\n","date":"2021-07-18T22:23:10+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/13290/","title":"OpenCore 0.7.0から0.7.1に更新"},{"content":"OpenCoreの0.7.0が公開されたので0.6.9からアップデートしました。config.plistの大きな変更点はありませんでした。またOpenCanopyが動かなくなりましたので、EFIのOC/Resourcesの中身を、配布されているものに差し替えました。\n0.7.0をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.7.0とmacOS 11.4で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASUS 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ファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\nconfig.plistで設定する項目の変更点は以下のようでした。\nKernel/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に移行できました。\nPickerアイコン指定方法が変更 前節の変更で起動はできましたが、0.6.6や0.6.8の時のようにOpenCanopyが動かなくなり、起動時の選択メニュー (Pickerメニュー）が文字だけのメニューに戻ってしまいました。そこで以前と同じく、以下から、Resources/Image, Font, Labelを取り寄せて交換したところ、動くようになりました。\nGitHub - acidanthera/OcBinaryData\n上記からダウンロードしたファイルを確認すると、Resources/Imageの中身にさらにディレクトリのある構造になってます。以前は、Imagesの中に直接アイコンファイルが置かれていました。今回からは、ESPのOCフォルダーにも、配布されている形のディレクトリ構造を保ってコピーすれば良いようでした。\nコメントで教えていただいて気づいたのですが、Pickerに表示するアイコンの指定方法が変更になった様です。これを指定するパラメータはconfig.plistのMisc/BootにあるPickerVariantです。0.6.9までは、この値（文字列です）は、\nAuto (デフォルト) 背景色に合わせて適切なアイコンが自動選択される Default 通常の名前のアイコンファイルが選択される Old Oldで始まる名前のアイコンが選択される Modern Modernで始まる名前のアイコンが選択される （それ以外の値）カスタムアイコンとしてサポートされていれば指定できる という規則でした。ファイル名の最初の文字で区別する方式です。例えばHDDのアイコンなら、PickerVariantにDefaultを指定するとHardDrive.icnsという名前のファイルが使用されますが、Modernを指定するとModernHardDrive.icnsという名前のファイルが使用されます。\nこれに対して、0.7.0では、上で説明したようにディレクトリで分類されるようになりました。アイコンファイルは66個くらいあるので、名前だけで区別するのは面倒ということだと思います。なので0.7.0のPickerVariantは、\nAuto 背景に合わせて自動的に選択される。 Default Imageの中のAcidanthera\\GoldenGateを選択する。 Acidanthera\\GoldenGate Imageの中のこのディレクトリを選択する。macOS 11スタイルのアイコンセット。 Acidanthera\\Syrah Imageの中のこのディレクトリを選択する。macOS 10.10スタイルのアイコンセット。 Acidanthera\\Chardonnay Imageの中のこのディレクトリを選択する。スタイルのアイコンセット。 特にこだわりがなければ、今まで通り、デフォルト値のAutoを指定しておけば良いと思います。\n","date":"2021-06-13T23:16:31+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/13220/","title":"OpenCore 0.6.9から0.7.0に更新"},{"content":"EFI System Partition (ESP)の中のconfig.plistやkext類を変更して、macOSが起動しなくなってしまうことがあります。そんな時のためにUEFI shellを使えるようにしておくと復旧作業に役立ちます。CloverやOpenCoreにはUEFI shellを起動する機能がありますが、BIOSメニューから起動する方法をまとめました。\nUEFI Shellで復旧する（おさらい） UEFI shellを使えば、OSが起動する前段階のUEFIが制御している状態で、ファイルシステムの中身を編集できます。なのでOSの起動に失敗している場合に、その状況を治せる可能性があります。ただしUEFIから読み書きできるファイルシステムに限定されるので、APFSやHFS+の中身は見ることも書き換えることもできません。でも、通常FAT32でフォーマットされるESPは編集可能です。ESPの中のconfig.plistやkext類を変更して起動しなくなってしまった場合は、UEFI shellで編集できるので、システムを復旧させることが可能です。UEFI shellについては、過去の記事でも紹介しました。\n起動しないマシンをUEFI Shellで救う\nこの記事では、CloverまたはBIOSからUEFI shellを起動して、ESPを復旧する方法を説明しました。OpenCoreでも、EFI/OC/ToolsにOpenShell.efiを入れておき、config.plistでこれを認識するよう設定すれば、OpenCoreの起動メニューからUEFI shellを起動できます。この先は、以前の記事のダイジェストになりますが、基本的には\nOpenCoreを入れたESPの場所を探して、 shellコマンドで編集する という作業を行います。UEFI shellの使い方は、こちらのサイトの説明が簡潔でわかりやすかったです。\nUEFI Shell の コマンド - 一寸先は/dev/null\nUEFIから見えるボリュームは、fs0:, fs1:, fs2: …のように名前がついています。shellコマンドから\nls fs0: などと入力すれば、この例ではfs0:のルート部分が見えます。この内容を見ながら、OpenCoreが使っているESPの場所を探して行きます。接続されたボリュームの数が少なければ、fs0:かfs1:くらいでOpenCoreのESPが見つかりますが、多い場合は探すのが大変です。そんな時に、mapコマンドが便利です。mapとタイプすると（またはmap -bとすれば画面に合わせて表示が停止します）、例えば以下のような表示がされます。長いので…で省略してます。\n\u0026gt; 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:が探しているボリュームだとわかります。その場合、\nfs8: とタイプしてそのボリュームに移動します。Windowsでcドライブやdドライブに移動する方法と同じです。次に、cdコマンドでOCのディレクトリに移動して、\ncd EFI\\OC ここでls, cd, cp, mv, cp, rm, edit, type (Unixのcatに相当)コマンドを駆使して、ファイルを操作します。ディレクトリの区切りが、macOSやLinuxと違い、Windows風の逆スラッシュになってます。config.plistのバックアップがあってそれがもしconfig_old.plistという名前なら、\nmv config_old.plist config.plist コマンドで元に戻せます。config.plistを変更する場合には、このように確実に動くバージョンを残しておくと、簡単に元に戻せるので楽です。config.plistを編集したい場合は、\nedit config.plist でエディタを起動します。このエディタでは、コントロールEでヘルプが表示されます。操作は簡単で、\nCtrl-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を保存し、エディタを終了した後で、\nexit もしくは\nreset コマンドをタイプしてシェルを抜けます。resetコマンドはシステムがリセットされます。exitコマンドでは、OpenCore選択画面に戻ります。大体はexitコマンドでokですが、変更内容によっては変更が反映されないことがあります。resetの方がより確実です。\nUSBメモリーから起動する UEFI shellはCloverやOpenCoreの選択画面から起動するだけでなく、UEFI環境でshellを直接起動することもできます。UEFI shellはHackintoshのためのツールではありませんので、こちらが本来の使い方です。\n通常のUEFIマザーボードの起動ステップでは、FAT32でフォーマットされたドライブの中にある、EFI/Boot/bootx64.efiというファイルを実行しているようです。実際に、OpenCoreのESPにもEFI/BOOT/BOOTx64.efiというファイルがあります。WindowsをインストールしたドライブのESPにも、EFI/Boot/bootx64.efiというファイルがありました。ディレクトリ名やファイル名の大文字小文字はどちらでも良いようです。UEFI shellのプログラムにbootx64.efiという名前をつけて、このディレクトリにおけば良いようです。\nそこで、まずはUSBメモリをFAT32でフォーマットします。パーティションマップはMBRでもGPTでも良いようですが、今回は単純にMBRで試しました。次にこのUSBメモリに、EFI/Boot/というディレクトリを作ります。この中に、OpenCoreで配布されている一式に含まれるOpenShell.efiをコピーして、これをbootx64.efiという名前に改名します。OpenShell.efiは、OpenCoreの起動メニューから動かすために、通常はEFI/OC/Tools/の中に入れているファイルです。その結果、USBメモリには、\nEFI/Boot/bootx64.efi のような位置と名前で、OpenShell.efiが入ります。このUSBメモリを挿したままコンピュータを起動し、BIOSメニューに入ると、Boot選択の画面に、以下のようにUSBメモリが現れるはずです。\nここでは、\nUEFI: JetFlashTrabscend 4GB 8.07, Partition 1 (4.0GB) という名前で見えています。 小さなサイズのUSB 2.0のUSBメモリを使いました。このボリュームを選択して起動すれば、UEFI shellが起動します。使い道のない古いUSBメモリですが、UEFI shellを入れておけばいざというときに役立ちます。\nBIOSメニューから起動する マザーボードのBIOSメニューに、UEFI shellを起動する機能が提供されていることがあります。マザーボードメーカによって、事情が異なるようです。最近の状況を調べてみました。\nMSIマザーボードの場合 以前の記事ではMSIのマザーボードの例を書いていました。MSIのマザーボードでは、独自にUEFI shellのソフトウェアを用意しているようで、BIOSメニューから選択するとそのshellが起動しました。なので、CloverやOpenCoreで用意したshellとは違うバージョンのshellが起動しました。現行のMSIマザーボードが手元に無いので確認できませんが、MSIのZ590マザーボードのマニュアルを見る限りでは、Settings/Save \u0026amp; Exit/Boot Overrideのメニューに、UEFI: Built-in EFI Shellという選択肢が健在のようですので、\n引き続き内蔵のshellが起動できるようです。\nASUSマザーボードの場合 Z390 ROG MAXIMUS XI HEROでは、Exitメニューの中に、Launch EFI Shell from USB drivesという項目があります。USBメモリーのルートにUEFI shellのプログラムを、Shell.efiという名前で入れておけば、ここから起動できます。これ以外の名前ではダメなようです。\nただし、BIOS設定でCSMをenabledにしてレガシー起動を可能にしておく必要があります。\nShell.efiを置く場所は、UEFIが見ることのできるボリュームのルートならどこでも良いようです。USBメモリがFAT32でフォーマットされているなら、そのルートで良いです。でもHFS+やAPFSはUEFIから見えないのでダメです。ESP (EFIシステムパーティション）でもokです。また、BIOSメニューにはUSBメモリから起動とありますが、それ以外のドライブでも起動できます。なので、OpenCoreを起動しているESPのルートに、OpenCoreのToolsフォルダからUEFI shellを次のようにコピーしておくと良いと思います。もちろんファインダーのドラッグ\u0026amp;ドロップでもokです。\n% cp /Volumes/EFI/EFI/OC/Tools/OpenShell.efi /Volumes/EFI/Shell.efi この作業をしておけば、ESPの内容をうっかり間違って設定してしまっても、UEFI shellを起動できます。\nGIGABYTEマザーボードの場合 実を言うと最近はGIGABYTEマザーボードを使っていないので、良くわかりません。マザーボードメーカを、GIGABYTE –\u0026gt; MSI –\u0026gt; ASUS –\u0026gt; ASRockと遍歴してきたので、最近の事情に疎くて、UEFI shellがBIOSから起動できるかどうかわかりません。マニュアルを取り寄せて見た限りでは、BIOSメニューからUEFI shellを起動する機能に関しての記載が無いようです。もしかしたら起動できないのかもしれません。ご存知の方いらしたら情報よろしくです。\nASRockマザーボードの場合 ASRockの場合は、Exitメニューの中に、Launch EFI Shell from filesystem deviceという項目があります。これを選択すると、M.2, SATA, USBなどに接続されていてUEFIでアクセスできるファイルシステムのルートに置かれたshellプログラムを起動してくれます。ASUSの機能と全く同じです。なのでASRockでも、OpenCoreでは通常EFI/OC/Toolsに置かれるOpenShell.efiを、EFI直下にコピーして入れて置くと、このメニューからそれが起動します。\nASRockの場合は、シェルプログラムのファイル名はなんでも良いようで、例えばOpenShell.efiのままでも起動しました。OpenCore用に入れているOpenShell.efiを以下のコマンドのようにしてコピーしておくだけです。もちろんファインダーのドラッグ\u0026amp;ドロップでもokです。\n% cp /Volumes/EFI/EFI/OC/Tools/OpenShell.efi /Volumes/EFI/. とはいえ、ASUSに合わせてShell.efiにしておいた方が混乱しなくて良いかもです。\n各社UEFI shell機能のまとめ 各社のBIOS画面からのUEFI shell起動機能をまとめると\nMSI: マザーボードに内蔵されているshellプログラムを起動する。 ASUS: EFIがマウントできるボリュームのルートに置いたshellプログラムを起動。プログラム名はShell.efiであること。 GIGABYTE: 不明。起動できないかもしれない。 ASRock: ASUSと同じく、EFIがマウントできるボリュームのルートに置いたshellプログラムを起動。プログラム名は任意のようで、OpenShell.efiなどでも起動。 となりました。MSI \u0026gt; ASRock = ASUS \u0026gt; GIGABYTEの順番に、利便性が良いと思います。ASUSとASRockの場合は、起動ボリュームのEFIにShell.efiとして入れておくと、いざという時に役立ちます。MSIは、shellプログラムがマザーボードに内蔵されているのでもっと安心です。\nまとめ Hackintoshの設定を変更して起動しなくなる経験は誰にでもあると思います。そんな時に便利なUEFI shell機能は、\nOpenCoreやCloverの起動メニューから立ち上げる 起動ボリューム（USBメモリでも可）から立ち上げる BIOSメニューから立ち上げる などの方法で起動可能です。UEFI shell起動の方法と使い方を知っておくと、いざという時に対処できるかと思います。\n","date":"2021-06-02T23:54:14+09:00","image":"/uploads/2021/03/Z590-ExtremeL6.jpg","permalink":"/posts/13056/","title":"UEFI ShellをBIOSから起動する"},{"content":"ASRockのZ590 Extreme + 10900KマシンにThunderbolt 4増設カードを取り付けました。これにThunderbolt 3 SSDを接続して動作確認しました。macOS Big Sur 11.4とOpenCore 0.6.9の環境で動かしたところ、hot plugは機能しないものの外付けドライブとして認識されて、M1 MacBook Airと同程度の速度で使用できました。\nHackintoshでThunderbolt Thunderboltの状況について昔の記事で紹介しました。\nThunderboltとHackintosh\n現在もあまり変わっていないように思います。hot plugが効かなくても良ければ、つまり起動時に識別されるドライブや機器を使うだけならば、簡単に使用することができます。でもそれ以上の設定を行う場合には、色々と試行錯誤が必要のようです。Thunderboltの初期の頃に、外付けドライブの動作を試したことがありましたが、その時もhot plugは効きませんでした。今回も外付けドライブがとりあえず使えることを目標にします。\nThunderboltの3と4 Thunderbolt 4は、ごく最近、500シリーズチップセットになってから登場した規格です。現行のIntel MacとM1 Macが採用しているのはThunderbolt 3で、4ではありません。なのでmacOSも3だけをサポートしていると考えて良いでしょう。\nとはいえ、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レーンの速度が必ず使えるようになってます。\nThunderbolt 3用SSD Thunderboltの機能を確かめるために、Thunderbolt 3 対応SSDを用意しました。具体的には、以下のThunderbolt 3用SSDケースを用意しました。\n少し分厚い (15mm) ですが、革風のエンボス加工がしてあって質感は良いです。内部にはNVMeのM.2 SSDを装着することができ、ヒートシンクも付属しています。搭載されているThunderboltコントローラチップはIntel JHL6540です。\n内蔵するSSDは価格コムで安かったPNYのNVMe Gen3 x 4の256GBにしました。今チェックしたら、倍近くに急騰している様子で、あまりお勧めではないかもしれません。パッケージには、読み取り1,700MB/s, 書き込み1,100MB/sと書いてありました。\nM1 MacBook Airで動作確認 自作機で試す前に、ちゃんとしたMacでどのように認識されて、速度が出るのかを確認しました。起動しているMacBook Airに接続したところ、hot plugが効いて、Thunderbolt/USB4ハードウェアとして認識されました。\nMacもSSDもThunderbolt 3なので、Thunderbolt 3として認識されています。最高速度は40Gbps x 1となってました。ただ、ディスクユーティリティ.appで情報を見るとPCIe接続になっているようです。装置ツリーバスの値を、Hackintool.appの情報と比較したところ、この場所にはPhison Electronics社のPS5013というチップが接続されていました。調べたところ、NVMe SSDをPCIeに接続するコントローラチップで、M.2 SSDに搭載されているチップのようです。\nこれをAPFSでフォーマットして、AmorphousDiskMarkで測定しました。以下のように、SSDのパッケージに書いてある通りの速度が出ています。 参考までにM1 MacBook Air内蔵のSSDはこの倍くらい高速です。\nThunderboltドライブは取り外し可能ドライブとして認識されています。取り外した後、再度接続すると再認識されてマウントされます。hot plugが完璧に動作していることを確認できました。\n(おまけ) 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を接続したところ、しばらくして以下のような通知が出ました。\nThunderboltがついていないので当然の結果ですが、Thunderboltデバイスが接続されたということをmacOSが正しく把握していることが確認できました。\nASRockのTB 4カード では、いよいよThunderboltハードウェアを搭載したhackintoshで試してみます。使用するマザーボードはASRockのZ590 Extremeです。最近になって。メーカのサイトによると、搭載されているコントローラはIntel JHL8540だそうです。\nASRock「Thunderbolt 4 AIC」製品情報\nThunderbolt 3でよく使われたチップはJHL6x40でファミリー名はAlpine Ridgeでした。JHL8540は、Maple Ridgeというファミリー名だそうです。macOSがサポートしているのはAlpine Ridgeと言われていて、Maple Ridgeがどの程度動くのか未知数です。\nカードはPCIe x 4を使用するので、マザーボードの真ん中のPCIe x 16スロット (PCIE3) に挿しました。このソケットは、形状こそx16ですが、マニュアルによると実際にはx4で接続されるようです。ここはチップセット経由のPCIeで、大元のCPUとの接続がx4なので仕方ないですね。Thunderboltカードには十分な仕様です。\nカードには、マザーボードに接続するケーブルが2本付属しています。1本はPCIE3ソケットにすぐ隣にあるThunderbolt AICコネクタへ接続します。5ピンでケーブルも太いので、おそらくは電源強化用ですね。Type CのPD (Power Delivery) に対応するための強化策だと思います。もう1本のケーブルは、マザーボード上のUSB 2.0ピンに接続します。Type CにはUSB 2.0を一本用意しないといけないので、その接続用だと思います。\nカード背面には2個のType CコネクタとDisplay Portコネクタがついています。DPの方は入力用で、グラフィックスカードなどに接続します。Type Cコネクタにディスプレイを接続する場合に使用します。今回は接続しませんでした。\nBIOS設定 次に、Thunderboltが動くようにBIOS設定します。BIOS設定のAdvanced –\u0026gt; Intel Thunderbolt –\u0026gt; Discrete Thunderbolt SupportをEnabledにします。デフォルトではDisabledになっています。\nThunderboltを有効にすると、\nThunderbolt Boot Support Thunderbolt USB Support Windows 10 Thunderbolt support の項目が現れます。最初の2個は、接続したThunderboltまたはUSBドライブからbootするようにするかどうかの設定です。3番目はWindowsでの設定のようです。とりあえず全部Disabledで良いようです。\nまた、Thunderboltを有効にすると、自動的に PCI Express Native Controlという項目がEnabledに設定されます。この項目のデフォルト設定はDisabledです。何か必要な設定だと思いますので、そのままEnabledにしておきました。\n自作PC+macOSでTBの動作確認 以上でインストールと設定は終了です。Thunderbolt端子に、先に紹介したThunderbolt M.2 SSDを接続し、OpenCore 0.6.9でmacOS Big Sur 11.4を起動させました。その結果、リムーバブルドライブとして認識されました。ただしhot plugは効いていないようで、起動時にSSDが接続されている場合しか認識されず、一旦アンマウントすると再接続しても認識されません。\nディスクユーティリティ.appで情報を調べると以下のようでした。実機のMacと同様に、SSDはPCI-Express経由で接続されたドライブとして見えています。\n装置ツリーバスの値を、Hackintool.appの情報と比較したところ、実際のMacと同様に、この場所にはPhison Electronics社のPS5013が接続されていました。ここまでは、SSDが実機とほとんど同じように見えているのですが、システム情報のThunderboltの項目を見ると、ハードウェアが見つかりませんとの表示です。\nこの先、頑張れば、hot plugも効くように調整できるのかもしれません。でも、大昔にThunderboltを試した時も、同様にhot plugが効かず、Thunderboltハードウェアの認識もされませんでした。なので、hot plugの制約を乗り越えるのは難しいかもしれません。Thunderboltはそこまで必要と感じていないので、今回はここまでとしました。\n最後に性能のチェックです。Z590マシンにこのSSDを取り付けた状態で、AmorphousDiskMarkで測定しました。なんとM1 MacBook Airの結果とほとんど同じ結果が出ました。ということで、hot plugは効かないものの、実際のMacでのThunderbolt 3接続と同等の性能が出ていることを確認できました。\n(おまけ)TB 4 AICをUSBで使う ASRockのThunderbolt 4 AICにUSB Type-CのUSB 3.1メモリを挿してみたところ、マウントされて認識されました。ThunderboltとしてだけではなくUSBとしても使えるようです。USBとして使う場合は、hot plugが効きました。\nまとめ ASRock Z590 Extremeマザーボードに、ASRockのThunderbolt 4 AICを追加して動作を確認しました。ソフトウェア環境はOpenCore 0.6.9とBig Sur 11.4です。Thunderbolt 3 SSDを接続したところ、hot plugは効かないものの実機のMacと同じ転送速度が達成されていることを確認しました。\n","date":"2021-05-30T20:49:50+09:00","image":"/uploads/2021/05/asrock_card.jpg","permalink":"/posts/13119/","title":"macOS で Thunderbolt 4 を使う"},{"content":"macOS Big Sur 11.4が配布されたので、11.3.1からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.9で起動していて、kext類は最新です。AMD Radeonの最新GPUに対応したようです。\n一般的更新内容 前回の11.3.1アップデートとは違い、今回はバージョン番号の差異が大きいアップデートです。「ソフトウェア・アップデート」画面の説明によると、Podcastのサブスクリプションとチャンネル追加がされたようです。また重要なバグ修正も含まれているようです。個人的には、プレビューのバグに対応してくれたのが嬉しいです。\nAMD Navi 21に対応 またAMD 6800, 6800XT, 6900XTに対応したようです。このことはベータ版の時から話題になっていて、フォーラムでも動作を報告していただいていました。Apple Developerの11.4 Release Notesページにも以下のように書かれています。\nYou can now use graphics cards based on the AMD Navi RDNA2 architecture (6800, 6800XT and 6900XT). (73709953)\nこれを確認するために、11.3.1と11.4のグラフィックス関連kextを比較しました。\n/System/Library/Extensions には、AMDRadeonで始まるkextが多数あるのですが、その一部が、Big Sur 11.3.1ではバージョンが4.4.17だったものが、11.4では4.5.14になり、更新されています。その中から、\n/System/Library/Extensions/AMDRadeonX6000.kext/Contents/Info.plist の内容を比較しました。すると、Big Sur 11.3.1では、\nAMDNavi10GraphicsAccelerator AMDNavi12GraphicsAccelerator AMDNavi14GraphicsAccelerator というキーが用意されているのに対して、Big Sur 11.4では、\nAMDNavi10GraphicsAccelerator AMDNavi12GraphicsAccelerator AMDNavi14GraphicsAccelerator AMDNavi21GraphicsAccelerator が用意されていて、Navi 21が追加されていました。Navi 21はRadeon RX 6800 / 6800XT / 6900XTに使われているGPUの名前だそうです。Apple Developerのアナウンスもそれに従った内容です。ちなみにRadeon RX 6700はNavi 22だそうなので、6700はmacOSの正式サポート対象ではないようです。\nアップデート作業 システム環境設定の「ソフトウェア・アップデート」から「今すぐインストール」ボタンを押してアップデートしました。この後、3.06GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのまま進めて大丈夫で、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.4が起動しました。特に気づく変更点はありません。ビルドは20F71になってました。\n","date":"2021-05-25T15:40:28+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/13124/","title":"BIG SUR 11.4にアップデートする (Navi 21対応)"},{"content":"OpenCoreの0.6.9が公開されたので0.6.8からアップデートしました。config.plistの変更点はほとんどありませんでした。UEFI/AppleInput/CustomDelaysがstring型からbool型に変更されたのが注意点です。\n0.6.9をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.6.9とmacOS 11.3.1で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASUS 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ファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは、いつもの通り以下です。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。PlistEDPlusのバージョンが上がって、機能が増えました。\nconfig.plistで設定する項目の変更点は以下のようでした。\nUEFI/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に移行できました。\n","date":"2021-05-05T13:19:01+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/13084/","title":"OPENCORE 0.6.8から0.6.9に更新"},{"content":"macOS Big Sur 11.3.1が配布されたので、11.3からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.8で起動していて、kext類は最新です。OpenCore 0.6.9が公開されていますが、古いバージョンでも対応できました。\n前回の11.3アップデートとは違い、今回はバージョン番号の差異が小さいアップデートです。名前も「セキュリティアップデート」です。具体的なアップデート内容は不明ですが、「macOS Big Sur 11.3.1を適用すると、重要なセキュリティアップデートが提供されます。このアップデートをすべてのユーザに推奨します。」と案内されています。11.3の公開から1週間しか経たないタイミングでのアップデートなので、緊急度の高い内容だったのかもしれません。追記：Appleサポートの情報によると、悪意のあるページでWebKit（webページのレンダリングエンジン）が不具合を起こさないよう対応したそうです。\nシステム環境設定の「ソフトウェア・アップデート」から「今すぐインストール」ボタンを押してアップデートしました。この後、2.4GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.3.1が起動しました。特に気づく変更点はありません。ビルドは20E241になってました。\n","date":"2021-05-04T14:00:06+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/13075/","title":"BIG SUR 11.3.1にアップデートする"},{"content":"AirTagを試してみました。iPhoneで登録して「探す.app」からAirTagの場所を知ることができます。Z390で作った自作macOSマシンでも、同様に「探す.app」でタグを探すことができました。ただ、UWBデバイスに対応したiPhoneならば、タグの位置と方向を頼りにタグの場所まで案内してもらえるのですが、Macではできません。電池容量の確認、検出できた場合の通知、紛失モードへの設定は可能です。\nAirTag AirTagが来ました。こんな感じに梱包されてます。\nボタン電池の接点を絶縁しているプラスチックフィルムを、矢印の方向に引き抜くと動作開始します。すぐにiPhoneに通知が来ますので、ペアリングして名前をつけておきます。\n名前は自由に付けられますが、あらかじめ用意された名前もあります。用意されている名前は、カメラ、ジャケット、バックパック、ハンドバッグ、ヘッドフォン、鍵、財布、傘、自転車、手荷物です。AirTagで探すアイテムとして想定されているもののリストになっていると思いました。\niPhoneで探す iPhoneで「探す.app」を立ち上げて、画面下の「持ち物を探す」ボタンを押します。iPhoneを探す機能と同じように、地図上にAirTagの位置が表示されます。AirTagがある場所に近づいて「探す」ボタンを押すと、AirTagの方向と距離を表示してくれます。これはUWBに対応したiPhoneだけの機能のようです。\nMacで探す Macでも「探す.app」を起動して試しました。Z390マザーボードの自作マシンで、macOS 11.3、OpenCore 0.6.8の構成です。「探す.app」に新しく用意された「持ち物を探す」タブを押すと、登録したAirTagの場所を知ることができます。（スクリーンショットは加工してあります）\nただ、MacはUWBデバイスに対応していないので、タグの方向と距離を知ることはできません。AirTagはSiriからも問い合わせできるそうなので、MacのSiriで試したところ、iPhoneなどを使ってくださいと言われました。\nHomePodのSiriにお願いしたら、タグのスピーカーから音を鳴らしてくれました。\n","date":"2021-04-30T16:38:01+09:00","image":"/uploads/2021/04/airtag_sample.jpg","permalink":"/posts/13033/","title":"AirTagを使う"},{"content":"macOS Big Sur 11.3が配布されたので、11.2.3からアップデートしました。アップデートしたのは、Z390とZ590マザーボードのマシンです。OpenCore 0.6.8で起動していて、kext類は最新です。\n前回の11.2.3アップデートとは違い、今回は小数点以下第1位の大きめのアップデートです。機能も増えている様子で、「探す.app」がAirTagに対応したようです。また「このMacについて」メニューで保証内容が表示されるようになったとのことです。他にも多数の変更・改良点があるようです。\nシステム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。\nこの後、5.71GBのアップデートファイルがダウンロードされ、3回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.3が起動しました。ビルドは20E232になってました。\n探す.appがAirTagに対応したとのことでしたが、「持ち物を探す」タブは11.2.3から変化はありませんでした。AirTagを登録した段階で、新しい機能が有効になるのかもしれません。\n「このMacについて」の「サービス」タブは変化してました。以前はリンクがあるだけだったのですが、状況が表示されます。存在しないシリアル番号を割り当ててあるためか、「推定有効期限切れ」という状態のようです。\nZ590マザーボードのマシンにも、無効なシリアル番号を割り当ててあるのですが、表示が少し違っていました。設定したシリアル番号の製造週からまだ1年未満なので、1年保証が有効だという表示なのかと思います。\n","date":"2021-04-27T20:54:36+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/13011/","title":"BIG SUR 11.3にアップデートする"},{"content":"ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを動かしています。今回はmacOSのUSB個数制限に合わせてUSBポートの設定を行います。以下で調査した結果はASRock Z590 ExtremeのUSB構成ですが、姉妹製品のZ590 Steel Legendでもおそらく同じなのではと思います。\nmacOSのUSB個数制限 今までにも何度かご紹介していますが、macOSにはUSBコントローラごとにUSBポートの数が15個までという制限があります。ポートの識別に1バイトしか割り当てられていないのです。実際には0を除いて1から15までの数値でポートを識別しているようです。大抵のマザーボードには15個を超えるポートがありますが、何も対処しないとUSB2.0のポートから順番に15個だけのポートが有効になります。後回しになるUSB3.0のポートがほとんど使えない状態になります。この問題を解決するには、以下のような対処法があります。\nUSBInjectAll.kextを使い、15個の制限を無視するパッチを当てる。OpenCoreの場合、config.plistで、Kernel/Quirks/XhciPortLimitをtrueにする。 USBInjectAll.kextを使い、使用しないポートをブートオプションのuia_excludeで指定する。 USBInjectAll.kextを使い、使用するポートをSSDTで指定する。 使用するポートを列挙したkextを自作する。hackintool.appなどにkextを作るツールが用意されている。 このうち4番目が一番スマートですので、今回もこの手法で設定します。hackintool.appでkextを作る方法はこちらでも説明してありますのでご覧ください。\n15個制限のためのUSBPorts.kextをHackintoolで作る\n個数制限を一時的に無効にする まずは使用したいポートを特定するために、一旦、全部のポートが見えるように、個数制限撤廃パッチを当てます。上で述べた選択肢の1番の手法です。まずは500シリーズチップセットに対応したUSBInjectAll.kextを以下から入手します。\nhttps://gitee.com/softxing/OS-X-USB-Inject-All/releases/v0.7.7\n次に、config.plistで、Kernel/Quirks/XhciPortLimitをtrueにします。この結果、全てのポートが見えるようになります。hackintool.appで調べると以下のようになります。14個のHS (USB2.0) と9個のSS (USB3.x) が見えていることがわかります。USRという項目は無視して良いです。\n15個制限を無視するパッチをこのまま使い続ければ楽かもしれません。でもLocation IDの項目を見ると、0x14F00000の次の行で0x14000000に戻ってしまっていて、重複していることがわかります。区別のための変数が1バイトしかないためのようです。これが何らかの不具合を引き起こす可能性はあると思いますので、15個以内に制限した方が良いでしょう。\nUSBポートを特定する 使用するポートを選択する作業の前に、実際のUSBポートがどの名前 (HS01からSS09までの名前）に対応しているかを調べます。15個制限を外すパッチを当てた状態で、hackintool.appを見ながら、USBポートにデバイスを挿して確認します。\n何も挿さない状態でも、上記の図のようにHS09, HS14, SS09に反応があります。このうちASM107xというのはAsmedia社のUSBハブ制御チップのことです。マザーボード上に搭載されているようです。BRCM20702 Hubというのは、こちら\nASRock Z590 Extremeに無線モジュールを取り付ける\nで取り付けた無線モジュールBCM94360NGのBluetooth部分です。これはM.2 key Eソケットに取り付けてあるのですが、key EにはUSB 2.0のポートが来ていて、それが見えています。\nhackintool.appを動かしたまま、バックパネルとマザーボード上のポートを1個ずつ使っていくと、割り当てがわかります。USB 2.0を調べるためには、無線キーボードのドングルを使いました。USB 3.0を調べるためには、3.1対応のUSBメモリを使いました。USBメモリは、挿すとマウントされるので、取り外す前にアンマウントする手間がかかりちょっと面倒です。USBメモリの代わりに、USB 3.0対応のUSBハブを使えば、もっと効率が上がったかもしれません。\nマザーボード上のポートを調べるためには、内部コネクタを通常のコネクタに変換するアダプタを使いました。画像にAliExpressへのリンクを貼っておきます。お手軽な値段なので、一通り持っていると何かと便利だと思います。\n調査結果 ASRock Z590 ExtremeのUSBポートを調べた結果を以下に示します。\nHS01 マザーボード上の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のマニュアルに記載されているポートの名前です。マニュアルのバックパネルの図にポート名を書き込むと以下になります。\nまたマザーボード上のUSBピンは、それぞれ以下の名前になります。\nマザーボード上のUSB2.0ピンはチップセット直結なのに対して、USB3.xピンはUSBハブ経由なのが面白いところです。Gen2x2のコネクタは、裏表で、別のSSポートに割り当てられているかと思ったのですが、同じでした。\n15個に制限する 以上のように全部で19個のポートがあります。15個に制限するには、4個を諦める必要があります。バックパネルは便利なので、全部活かしたいところです。性能重視ならば、マザーボード上のUSB2.0ヘッダ端子を無効にするのが良いと思います。無駄に贅沢に使われている気がしました。これで4個除外できるので全部で15個になります。\nHS03 バックパネルの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に説明を書いておくと、後々便利かと思います。\nこの後、ウィンドウ下のExportボタンを押します。箱から矢印が外に向かっているアイコンの部分がExportボタンです。するとこの設定から、以下の5個のファイルをデスクトップに作ってくれます。\nSSDT-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と一緒に使うものであると思います。\n一方、ここで作られるUSBPorts.kextは、Info.plistだけを持ったインジェクタkextという種類のkextファイル（実際にはディレクトリ）です。ターミナルからディレクトリを辿る、もしくはファインダーからパッケージを開くと、\nUSBPorts.kext/Contents/Info.plist というテキストファイルが見えます。この中に、上で設定した内容が、plist書式のテキストで書かれています。このkextだけを使用すれば、15個のUSBポートを正しく設定することができます。\nここで作成したUSBPorts.kextをここに置いておきます。ご利用ください。機種名がiMac20,1になっていますので、20,2を使っている人はkextの中のInfo.plistを編集して書き直してください。\n今回の設定では、マザーボード上のUSB2.0を全部無効にしました。しかし、無線モジュールを、M.2ソケットではなく、PCIeスロットに挿す場合、USB接続が必要なので、マザーボード上のUSB2.0を1個有効にする必要があります。その場合は、M.2 key EソケットのHS14を除外することになると思います。\nまとめ ASRockのZ590 ExtremeのUSBポートの構成を調べてmacOSの15個制限に対応しました。ここで調べたポート名対応は、構成が似ているZ590 Steel Legendでも同じなのではと思います。また他のASRockマザーボードもこれと似た構成かと思われます。これでZ590マザーボードの設定は一通り完成しました。Z590で作るhackintoshはとても安定しているので、第10世代CPUと組み合わせてmacOSマシンを作るのに適しているかと思います。もしもこの先、iMacが第11世代に対応してくれた場合も、CPU交換で追いつけます。\n","date":"2021-04-25T18:12:47+09:00","image":"/uploads/2021/03/Z590-ExtremeL6.jpg","permalink":"/posts/12995/","title":"ASRock Z590 ExtremeのUSBを設定する"},{"content":"ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを動かしています。今回はこれにmacOSでOOBで機能するWiFi-BluetoothモジュールBroadcomのBCM94360NGを取り付けました。このマザーボードはバックパネルにアンテナ取り付け穴が空いているので、アンテナ取り付けが楽です。\nBCM94360NG BCM94360NGはmacOSでそのまま機能する唯一のM.2用WiFi-Bluetoothモジュールです。お値段は少し高いですが、kext類なしでそのまま動いて、Apple IDやiPhone連携なども問題なく動くので、hackintoshするには定番の無線モジュールです。\n今回使用しているASRock Z590 Extremeには、M.2 key Eソケットがついていて、この無線モジュールを取り付けて動かすことができます。ただし、ASUS, GIGABYTE, MSIの、Z490/Z590マザーボードのM.2 key Eソケットは、CNVi専用の場合が多く、動かない可能性があるので注意が必要です。ASRockは従来型のM.2 key E無線モジュールを引き続きサポートしてくれているのでありがたいです。\nアンテナ取り付け穴 マザーボード上のM.2ソケットに、WiFiモジュールを取り付けた場合に悩むのが、アンテナ取り付け位置です。PCIeスロットにつけても良いのですが、拡張スロットをアンテナで塞いでしまうのがもったいないです。マザー上のM.2ソケットを使うなら、PCIeスロット以外の場所からアンテナを引き出したいところです。\nWiFi搭載マザーボードは大体がバックパネルにアンテナが付いてます。そこで、自分でモジュールを取り付ける場合も、バックパネルにアンテナを取付けたいと考えました。M.2ソケットからの距離も近いので、配線の引き回しも楽です。\nマザーボードによっては同じモデルで、WiFi搭載・非搭載バージョンが用意されています。例えばASRockのZ590 Steel Legendだと、\nがありますし、今回使ったExtremeにも\n[ASRock Z590 Extreme WiFi付き](https://www.asrock.com/MB/Intel/Z590 Extreme WiFi 6E/index.asp) があります。WiFiなしの方が3300円くらい安いです。WiFiなしを買ってBCM94360NGを取り付けるなら、WiFiなしの方が無駄になりません。他のマザーボードメーカも、WiFiあり・なしのバージョンのあるモデルがあるのですが、ASRockの素晴らしいところは「WiFiなしのバージョンもバックパネルにアンテナ穴が開いている」という点です。部品共通化してコストダウンを図っているだけなのでしょうが、後からWiFiモジュールを取り付ける場合には、とてもありがたいです。実際に、WiFiなしのZ590 Extremeのバックパネルは、こんな感じにアンテナ穴が開いています。\n無線モジュールとアンテナ取り付け ということで早速ASRock Z590 ExtremeのM.2 key EソケットにBCM94360NGを取り付けました。ここからアンテナ線を配線します。アンテナ配線のM.2モジュール側は、U.FL MH4という規格です。またアンテナ側は、通常はRP-SMAという規格です。オスメス反対の組み合わせのSMAにしても良いのですが、通常のマザーボードのアンテナがRP-SMAになっているので、こちらの方が使い回せて便利です。アンテナとケーブルはAliExpressでもAmazonでも買えます。\nM.2モジュールの近くの配線はこんな感じになりました。\nバックパネルとそのカバー部分は、マザーボード裏側の4個のネジを外すと取り外せます。\nアンテナをバックパネルに取付け、バックパネルを戻します。アンテナ穴が開いているおかげで、標準装備のWiFiアンテナみたいに綺麗に取付けられました。\nまとめ ASRockのZ590 ExtremeにM.2無線モジュールのBCM94360NGを取り付けました。このマザーボードはバックパネルにアンテナ穴が開いているので、アンテナを綺麗に取り付けることができました。\n","date":"2021-04-12T18:39:56+09:00","image":"/uploads/2021/03/Z590-ExtremeL6.jpg","permalink":"/posts/12917/","title":"ASRock Z590 Extremeに無線モジュールを取り付ける"},{"content":"AppleALC.kextがバージョンアップされて、Z590に搭載されたALC1220のPCIIDをサポートしてくれるようになりました。そのおかげで、PCIIDを偽装しなくても、ASRock Z590 Extremeに搭載されたサウンドチップRealtek ALC1220から音が出るようになりました。\nZ590マザーボードのサウンド 前の記事で、ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを起動させました。\nASRock Z590マザーボードでmacOSを起動する\nまたPCIIDを偽装してRealtek ALC1220から音が出るようにしました。\nASRock Z590マザーボード搭載ALC1220で音を出す (その1)\nAppleALC.kextがそのうち対応してくれると期待していたのですが、v1.5.9になったAppleALC.kextの説明に、以下のように書いてありました。ありがたいです。\nAdded 500 Series (0xF0C8 Z590 + Intel 10 Gen) PCH HD Audio Controller Added 500 Series (0x43C8 Z590 + Intel 11 Gen) PCH HD Audio Controller 実際、Hackintool.appなどで確認すると、第10世代CPUを搭載した状態でのPCIIDはF0C8でした。これを以前のチップセットのものに偽装していたのですが、この更新でその必要がなくなりました。実際、新しいAppleALC.kextに差し替えることで、\nFakePCIID.kext FakePCIID_Intel_HDMI_Audio.kext が不要になり、config.plistでのDevicePropertiesでのdevice-idの記述も不要になりました。layout-idは引き続き1を使用しました。\n","date":"2021-04-10T15:53:49+09:00","image":"/uploads/2021/03/Z590-ExtremeL6.jpg","permalink":"/posts/12898/","title":"ASRock Z590マザーボード搭載ALC1220で音を出す (その2)"},{"content":"OpenCoreの0.6.8が公開されたので、出遅れましたが0.6.7からアップデートしました。config.plistの変更点はほとんどありませんでした。ただ0.6.6の時のようにOpenCanopyが動かなくなってしまいました。EFIのOC/Resourcesの中身を、こちらにあるFont, Image, Labelフォルダの中身に差し替えたところ、OpenCanopyも動くようになりました。\n0.6.8をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。これを見ると、今回はOpenCanopy関係の更新項目が多いですね。Rocket Lake と Tiger Lake のCPU IDも追加されたようです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.6.8とmacOS 11.2.3で動作確認している手元のマシンは以下です。また、kext類はKext Updaterを使って最新版に入れ替えてあります。\nASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580 .efiファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\n変更点は以下のようでした。\nBooter/QuirksにForceBooterSignatureが追加されていました。というようなことが書いてありましたので、デフォルトのfalseにしておきました。 UEFI/AppleInputという項目ができていました。AppleEventの詳細な設定が可能になったとのことです。Sample.plistの設定が推奨とのことなので、そのまま設定しておきました。 UEFI/ProtocolOverridesにAppleEventというのが追加されていました。AppleEventプロトコルをビルトインバージョンと入れ替えるかどうかの項目とのことです。VMやレガシーMacの設定でFileVault 2を使う場合に有効かもしれない、というようなことが書いてありましたので、関係ないと考えて、デフォルトのfalseにしておきました。 いずれも大きな変更ではなさそうです。以上の設定で、0.6.7から0.6.8に移行できました。\nOpenCanopy関係のファイルを更新する 0.6.7の時のようにnvramのバージョン情報が更新されない問題はありませんでした。しかし0.6.6の時のようにOpenCanopyが動かなくなりました。そこでコメントで教えていただいて、以下から、Resources/Image, Font, Labelを取り寄せて交換したら動くようになりました。\nGitHub - acidanthera/OcBinaryData\n","date":"2021-04-09T00:06:33+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/12893/","title":"OPENCORE 0.6.7から0.6.8に更新"},{"content":"（こちらは古い情報です。最新のAppleALC.kextを使うことで、ここで行った手順は不要になりました。こちらをご覧ください。2021/4/10）\nASRock Z590 Extremeに搭載されたサウンドチップRealtek ALC1220から音が出るようにしました。Z490のマザーボードを最初に使った時と同様に、FakePCIID.kextを使いIDを偽装します。近い将来、Z490の時と同様に、AppleALC.kextとOpenCoreがZ590チップセットに対応すれば、このような工夫なしで動くようになるのではと期待しています。\nZ590マザーボードのサウンド 前の記事で、ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを起動させました。\nASRock Z590マザーボードでmacOSを起動する\nこの結果、有線と無線のネットワークが動いています。USBは未調整ですがキーボード、Bluetooth関係は動いてます。でもマザーボードに搭載されたサウンドチップであるRealtek ALC1220から音が出ていませんでした。今回は、このサウンドチップを動かします。\nRealtek ALC1220は、300シリーズチップセットから搭載されているサウンドチップです。AppleALC.kextで長らくサポートされているので、互換性は高いと思っていました。でもZ590マザーボードでは、AppleALC.kextを入れるだけでは動きませんでした。\n一方、一部のZ590マザーボードでは、新しいサウンドチップのRealtek ALC4080 が搭載されています。新しいので互換性が心配でしたが、実はALC4080はUSB接続で動いていて、USBオーディオとして機能するのでドライバの心配がいらないという報告がいくつか上がっています。オンボードサウンドのことだけを考えたら、ALC1220よりも、新しいALC4080が搭載されたマザボの方が面倒がなくて良いかもしれません。\nPCIIDを偽装する まずは、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の問題ではないと思われます。\n他の方法を検索しましたが、結局、以前、Z490マザーボードが出始めた時に使った方法が有効でした。サウンドチップのPCIIDを偽装する方法です。\nASUS ROG STRIX Z490-G GAMINGの音とLANを動かす\nこの方法に従って、以下のkext、\nFakePCIID.kext FakePCIID_Intel_HDMI_Audio.kext を追加し、config.plistのDevicePropertiesに以下を追加しました。PciRoot(0x0)/Pci(0x1F,0x3)はALC1220のデバイスパスです。これのdevice-idをA348に、layout-idを1にする設定です。\nZ590マザーボードに搭載されたALC1220には、ベンダー：デバイスIDとして、8086:F0C8が割り当てられています。このIDが、現在のバージョンのOpenCore/AppleALCには登録されていないようで、Hackintool.appで調べると、Device Nameが???という表示になります。\nそこで、上記の内容をconfig.plistに加えることで、このIDが8086:A348になります。このIDはCannon LakeのALC1220のdevice-idと同じ値なので、下記のようにCannon Lakeの名前が表示されるようになります。\n以上の作業を行うことで、無事、オンボードサウンドが出るようになりました。\nまとめ Z590マザーボードのオンボードサウンドチップであるRealtek ALC1220から音が出るように設定しました。以前のZ490の時もそうでしたが、OpenCore/AppleALCがZ590搭載のALC 1220に対応してくれれば、この作業は不要になると期待しています。\nASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）\n次の作業はUSBの15個制限の調整です。ぼちぼち対処していきます。\n","date":"2021-03-29T19:57:47+09:00","image":"/uploads/2021/03/Z590-ExtremeL6.jpg","permalink":"/posts/12857/","title":"ASRock Z590マザーボード搭載ALC1220で音を出す (その1)"},{"content":"ASRock Z590 ExtremeにComet Lake-S 10900Kを取り付けてmacOS Big Surを起動させました。今まで10900KはZ490で動かしていたのですが、なんとZ490のEFIのままでZ590でもログイン画面まで到達しました。課題はありますが一応の動作をしたのでご報告します。\n（更新：有線LANがどちらも動くようになりました 2021/3/29)\nZ590マザーボード 第10世代CPUの10900Kを、今までASUSのZ490 Micro ATXマザーボードで動かしていました。\nASUS ROG STRIX Z490-G, 10900K\n計画変更でこれを通常ATXのマザーボードにしたかったのですが、今更Z490を買うのもつまらないので、いっそZ590のマザーボードにすることにしました。Z590は、今月末に発売される第11世代CPU用のチップセットですが、現行の第10世代CPUも動きます。第10世代＋Z590でmacOSが動くという報告もいくつかあります。\n間もなく発売される第11世代CPUは、アーキテクチャやiGPUなどが変更されるので、しばらくはmacOSが動かないと考えられてます。でも将来、iMacに第11世代が搭載されることになれば試してみたいと思います。\nそれでZ590マザーボードを物色しました。\n減少するPCIeスロット macOSマシンを自作するメリットの一つは、本物のMacに足りない拡張性を補うことだと思ってます。なのでマザボ選びには、いつもPCIeスロットの数を考慮して、スロット数が多いものを選んでいました。\nでも、マザーボードに搭載されるPCIeスロットの数がだんだん減っているように思います。せっかく自作するなら良い部品を使いたいと思ってもいるのですが、特に上位モデルのマザーボードでスロットが減っている傾向があります。スロットのあった場所をM.2 SSDが占拠しているようです。Windowsで使う人たちもPCIeの拡張性をあまり重視しなくなっているのでしょうか？\n（左がROG STRIX Z490-F, 右がZ590-F）\n例えば、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スロット数が他社に比べて多い方だったのですが、残念です。\n一方で、GIGABYTEとMSIは、以前からPCIeスロットが少なめでした。あっても、CPU直結を分割するタイプが多めでした。\nそんなところで気づいたのは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を使ったことがなかったのですが、今回は大いに検討することにしました。\nASRock Z590 Extreme それで今回選んだのは、ASRock Z590 Extremeです。色々な点で魅力でした。\nPCIeスロットが多い PCIeスロットは5本あります。GPUスロットに割り当てられた16レーンを分割するタイプのスロットはありませんので、どれを使ってもGPU性能に影響は与えません。\n見た目が良い ヒートシンクや基板の模様が斜めにカットされていたり、斜めの溝や斜線が多用されたマザーボードのデザインに飽きていました。GIGABYTEのZ590 VISION DやZ590I VISION Dなどは、斜線の要素がなくて、スクエアで端正だと思います。ATXサイズのZ590 VISION Dはスロット数が少ないのですが、元々スロットがGPU用しかないZ590I VISION Dには、興味があります。\nVISION Dほどカッコ良くはありませんが、Z590 Extremeも、斜線要素が抑えられていて、スクエアな印象です。黒と青の配色も、レトロフューチャーなコンピュータのイメージで良い感じです。\n互換性の高い有線LAN 2.5GbEのチップがRealtek RTL8125Bです。こちらで紹介したように、RTL8125用のkextが用意されているので、LucyRTL8125Ethernet.kextで動きます。他社のマザーボードだと、Intel I225-Vが搭載されていることが多いです。この場合は、FakePCIIDなどを駆使して動かす必要がありました。専用のkextの方が安心です。\nASRockの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の方が頻繁に更新されているので、今後もこちらを使った方が良いと思いました。\n無線用key Eソケットとアンテナ穴がある WiFiなしのモデルですが、無線モジュール用のソケットとアンテナ穴があります。\nASRockマザボの無線LAN/Bluetooth用のM.2 key Eソケットは、CNViに加えて、従来型のPCIe + USB接続が可能なタイプです。こちらの記事で紹介したように、最近の多くのマザボはCNViのみの対応になっていて、macOSと互換性のあるWiFi/Bluetoothモジュールを取り付けることができません。ASUS, GIGABYTE, MSIのM.2 key Eソケットは、CNVi専用の場合が多いです。\nところが、ASRockの製品は、スペック表に以下のように書いてあるように、従来型の無線モジュールにも対応しています。これでmacOSにOOBで対応するBroadcomのBCM94360NGが使えます。\n1 x M.2 ソケット (Key E), タイプ 2230 WiFi/BT PCIe WiFi モジュールと Intel® CNVi (統合 WiFi/BT) に対応 バックパネルにアンテナ穴が空いているのもポイントです。現在の国内のラインナップではWiFi付きのExtremeはありませんが（Steel LegendにはWiFi付きと無しがあります）、WiFi非搭載モデルにもアンテナ穴がちゃんと空いてます。バックパネルを統一してコストダウンするのが目的だとは思いますが、あとから無線モジュールを取り付ける場合には、とても助かります。\nサウンドチップの互換性が高い サウンドチップがRealtek ALC1220です。AppleALC.kextでサポートされているチップなので、互換性が高いはずです。実はまだ動かせてませんが、なんとかなると思ってます。ASRockは上位モデルのTaichiにもALC1220を使っているので、安心かと思います。他社のZ590モデルには、新しいチップのRealtek ALC4080が使われている場合が多いです。このチップにはAppleALC.kextが未対応なので音が出ない可能性が高いと考えました。ただ、TonymacX86の情報によるとGIGABYTE Z590 VISION Gでは、ALC4080がUSBオーディオ接続になっていて、何の問題もなく音が出たという報告があります。なのでサウンドチップの互換性の心配は不要なのかもしれません。\n以上のように、ASRockのZ590シリーズは、全般的に安定したこなれた規格と部品が使われている傾向があって、hackintoshするには安心感のある構成かと思いました。\n組み立てる 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ソケットにぴったり収まります。この後、アンテナを仮配線しました。\nM.2 SSDには、Z490で起動させていた時のEFIがそのまま入っています。OpenCore 0.6.7です。メインのパーティションには、Big Sur 11.2.3がインストールされてます。グラフィックスカードはAMD Radeon 5700XTです。\n構成をまとめると、以下になります。\nASRock Z590 Extreme 10900K M.2 SSD BCM94360NG Radeon 5700XT OpenCore 0.6.7 + Big Sur 11.2.3 BIOS設定 BIOS設定は、工場出荷時設定でも問題ありませんでした。でも通例にしたがって以下のように設定しました。\nIGPU 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機器が動いていないようです。\nUSBメモリで起動 移植に先立って、M.2 SSDのEFI部分を、USBメモリのEFI部分にコピーしてありました。ログイン画面に至ったところでUSB機器が動かなくなっている様子でしたが、OpenCoreなどが動く段階では、USBメモリーは動いています。なので、このUSBメモリから起動することが可能でした。\nそこで、この起動用USBメモリを別のマシンで編集して、多少の調整をしました。まずは、IntelMausiEthernet.kextとLucyRTL8125Ethernet.kextを導入します。この記述をconfig.plistにも追加しました。次にconfig.plistからZ490関係の内容、つまりはDevicePropertiesの有線LANとサウンドに関する部分を削除しました。これでかなりZ590対応したと思うのですが、USB周りは手を加えてないので、やはりログイン画面でUSBが効かなくなったままです。\n画面共有する USB機器が動かない様子なので、画面共有で先を進めようと考えました。ルーターのDHCPのログを見ると、新しいマザーボードに1個だけアドレスが割り当てられていました。そこで、このアドレスに対して画面共有を行ったところ、無事ログイン画面が現れました。ここで、ログインして全ての操作が可能になりました。システム環境設定からネットワークを調べたところ、動いていたのはWiFiのBCM94360NGでした。\n当初、有線LANは、Intel I219VもRealtek RTL8125Bも、どちらも動いていませんでした。Intelが動かなかったのは、前述のように、IntelMausiEthernet.kextを使っていたのが原因でした。IntelMausi.kextに変えて動くようになりました。RTL8125Bが動かなかったのは、前のZ490マザーボードの設定で、ジャンボフレームが使用したかったので、2.5Gハブ接続するよう固定してしまっていたからでした。それを1Gハブに接続したので動かないようでした。自動モードにしたら動くようになりました。\nUSBInjectAll.kextを入れる 画面共有から接続して、Hackintool.appで調べたところ、USBポートが一つも見えてませんでした。元々Hackintool.appで作ったZ490マザボ用USBのためのkextを入れていたので、これが動いていないと考えました。そこで、USBInjectAll.kextを入れてみたのですが、やはりUSBは見えませんでした。ちょっと探したところ、Z590チップセットに対応したUSBInjectAll.kextがあるようでした。\nhttps://gitee.com/softxing/OS-X-USB-Inject-All\nHackintool.appで調べると、Z490のXHCI Host ControllerのVender:Device IDは8086:A36Dですが、Z590の場合8086:43EDでした。これらの違いを反映したUSBInjectAll.kextが必要なようでした。上記のサイトからソースコード一式をダウンロードして、makeコマンドでkextを作ることができました。コンパイルしたZ590用のUSBInjectAll.kextをここに置いておきます。\nこれでUSBが見えるようになりました。上はHackintool.appで調べた様子です。USB Receiverというのはlogitechのトラックパッド付きキーボードです。これでログインもmacOSの操作もできるようになりました。BRCM20702 Hubは、BCM94360NGのBluetooth部分です。これでBluetoothが見えて、純正Magic Trackpad/Keyboardも接続できるようになりました。ASM107xというのは、マザボ搭載のUSBハブかなと思います。今の状態だとUSB 3.1が使えないので、今後は使うべき15個のUSBポートを選択して、kextを作っていきたいと思います。\nEFI構成 以上の作業で、EFIの構成は以下のようになりました。ACPIフォルダが、\nSSDT-RHUB.aml SSDT-PLUG.aml SSDT-EC-USBX.aml SSDT-AWAC.aml Kextsフォルダが\nWhateverGreen.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です。\n追記：使用中のEFIをこちらに置いておきます。config.plistのシリアル番号などはみなさんで設定してください。Radeon RX 6xxx以外の方は、ブートオプションのagdpmod=pikeraを削除してください。OpenCore 0.7.6です。USBは設定済みで、オンボードオーディオも動きます。\nまとめ ASRockのZ590 Extremeに10900Kを搭載してmacOSを動かしました。現状では\nUSBは動いているけど15個制限対策は未設定 Intel (1GbE)、Realtek (2.5GbE)のどちらの有線LANも動く マザボに取り付けたBCM94360NGでWiFi/BTが動く オンボードオーディオが動かない 状態です。少しずつ対策していきたいと思います。\n追記：オンボードオーディオが動きました：\nASRock Z590マザーボード搭載ALC1220で音を出す (その1)\n","date":"2021-03-27T20:56:14+09:00","image":"/uploads/2021/03/Z590-ExtremeL6.jpg","permalink":"/posts/12835/","title":"ASRock Z590マザーボードでmacOSを起動する"},{"content":"macOS Big Sur 11.2.3が配布されたので、11.2.2からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.7で起動していて、kext類は最新です。\n前回の11.2.2アップデートに引き続き、またマイナーなアップデートのようで、WebページのレンダリングをするWebKitの脆弱性を修正するもののようです。機能が拡充するわけではなさそうですが、バージョン番号を上げてまで配布するということは深刻な不具合なのかもしれないです。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。\nこの後、2.44GBのアップデートファイルがダウンロードされ、複数回再起動しました。再起動はデフォルトで選択されているボリュームのままでokで、操作不要でした。放置しておいたら、何の問題もなくBig Sur 11.2.3が起動してました。\n特に気づく変更点はありません。ビルドは20D91になってました。\n","date":"2021-03-12T20:27:47+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/12776/","title":"BIG SUR 11.2.3にアップデートする"},{"content":"OpenCoreの0.6.7が公開されてかなり経ってしまいましたが、ようやく0.6.6からアップデートしました。config.plistの変更点はほとんどありませんでした。\n0.6.7をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.6.7とmacOS 11.2.3で動作確認している手元のマシンは以下です。\nASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580 .efiファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。入れ替えるべきファイルは以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、古いconfig.plistの項目をコピーする方針で、新しいconfig.plistを作りました。\n変更点は以下のようでした。\nUEFI/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に移行できました。\nバージョンが更新されない 0.6.7にアップデートしたものの、Kext UpdaterやHackintoolでチェックすると0.6.6のままだと言われて、0.6.7のダウンロードを推奨されました。これはnvramの更新ができていないためのようです。ターミナルから、\nnvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version とタイプして、OpenCoreのバージョンを示す変数を取得すると、以下のように表示されてしまいました。\n4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version\tREL-066-2021-02-02 066の設定のままでした。この問題は、OpenCoreの起動画面でnvramをリセットする項目を選べば解決します。もしくは、ターミナルから\nsudo nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version=\u0026#34;\u0026#34; とタイプして、この変数を削除してしまうことでも解決します。nvramコマンドでは、何も無い値を設定することで変数を削除できます。なので、この後にnvramコマンドで確認すると、\nnvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version nvram: Error getting variable - \u0026#39;4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version\u0026#39;: (iokit/common) data was not found というように表示されて、この変数が消えていることがわかります。正しいopencore-version値は、次の再起動時に自動的に更新されます。再起動後にnvramコマンドを入力すれば、\n4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:opencore-version\tREL-067-2021-03-01 と表示されるようになりました。Kext UpdaterやHackintoolもOpenCoreの新しいバージョンを認識するようになりました。\n","date":"2021-03-12T07:43:01+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/12768/","title":"OPENCORE 0.6.6から0.6.7に更新"},{"content":"macOS Big Sur 11.2.2が配布されたので、11.2.1からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.6で起動していて、kext類は最新です。\n前回の11.2.1アップデートに引き続き、またマイナーなアップデートのようです。サードパーティUSB-Cハブやドックを接続したときに、2019年以降のMacBook Proと2020年以降のMacBook Airが破損することを防ぐ効果があるようです。デスクトップのhackintoshにはとことん無関係な気もしましたが、最新macOSではありますので、アップデートしました。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。\nこの後、2.17GBのアップデートファイルがダウンロードされ、2回、再起動しました。1回目のアップデートのOpenCore画面では、いつもの起動ボリュームにしているMacintosh HDというボリュームが2個見えてましたが、デフォルトで選択されているままでokでした。インストール後、何の問題もなくBig Sur 11.2.2が起動しました。\n特に気づく変更点はありません。ビルドは20D80になってました。\n","date":"2021-02-26T23:25:35+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/12742/","title":"BIG SUR 11.2.2にアップデートする"},{"content":"iPhone 12から登場したMagSafeは、便利で優れた機能なのですが、純正アダプタが高価です。そこでAliExpressで探したところ、多種類の互換品が安価に販売されていました。これならMagSafeを気軽に活用できます。\nMagSafe 名前が昔のMacBook用MagSafeと同じで紛らわしいですが、ここでご紹介するMagSafeはiPhone 12から登場した磁石内蔵無線給電アダプタです。iPhone 8以降からQi規格に対応していたので、無線給電自体は可能でした。その給電コイル部分に磁石を内蔵したのがMagSafeです。iPhone 12側にも、受電コイルの場所に磁石が埋め込まれていて、ピッタリと位置合わせしてくっつきます。Apple以外にも同じアイディアを製品化していた会社があったとは思いますが、これでデファクトスタンダードになった点が進歩だと思います。\n無線給電は便利なのですが、位置合わせが面倒でした。給電・受電コイルの位置がズレると給電効率が悪くなり、充電できないこともあります。Appleが純正の無線給電アダプタを製品化するという噂があったものの、中止になってました。ネットの情報では、コイルカップリングの不確実さが問題だったそうです。MagSafeでそれが解決されたので、無線給電アダプタ類を本格的に製品化することになったのかと思います。\n磁石でくっつけるアイディアは良いのですが、磁力なので距離の二乗に反比例して弱くなります。なので、iPhone背面とMagSafeアダプタの間に保護ケースが挟まると、MagSafeアダプタはほとんどくっつかなくなってしまいます。これを解決するために、ケース背面部分に磁性体部品を組み込んだMagSafe対応ケースが用意されてます。この構造により、iPhone裏からケースの裏まで、磁力線が拡散する事なく導かれるので、MagSafeアダプタがしっかり付きます。\nMagSafe充電器 磁石内蔵の給電コイルを、Apple Storeでは「MagSafe充電器」という製品名で売ってます。充電器という名前ですが、ACアダプタ部分は別売です。MagSafeは15Wの充電をするので、純正の20W USB-C電源アダプタと一緒に使うことが推奨されてます。丸いパーツの中には給電コイルの他に、Qi規格に基づいてiPhoneと電磁誘導で通信して、相手を確認してネゴシエーションして、適切な電力を供給するためのコンピュータチップも内蔵されているはずです。\nApple Storeの価格は税別4,800円です。純正ACアダプタを買うとしたら、さらに税別2,000円が必要です。便利なのでたくさん備えて色々な場所で使いたいのですが、この価格だとちょっと躊躇します。そこでMagSafe充電器の互換品を探してみました。Amazonでも互換品は見つかりますが割と高価で3,000円前後します。でもAliExpressでは送料込1,100円くらいで売ってます。20WのUSB-C ACアダプタをセットにしても送料込1,600円くらいです。いくつかを入手しましたが、どれも問題なく使用できました。純正品1個の価格で互換品が4個以上買えるので、色々な場所で気軽にMagSafeを使えると思います。\nMagSafe対応ケース MagSafeを使うなら、iPhoneの保護ケースもMagSafe対応にすべきです。非対応のケースでも給電できなくはないですが、前述のように磁力が弱まるのですぐに外れてしまいます。中に磁性体パーツが内蔵された対応ケースなら、ケース無しの場合と同様にしっかりと固定され、簡単には外れません。\niPhoneの純正ケースが高価なのは昔からのことです。MagSafe対応の純正ケースで一番高級なケースは、「MagSafe対応iPhone 12 | iPhone 12 Proレザーケース」で、税別6,800円です。AmazonにもAliExpressにも、非純正のMagSafe対応ケースが手頃な価格でたくさん販売されているので、そちらを試した方が良いと思います。純正品にはない特徴のある製品も多いです。例えば、画面保護ガラスがセットになった製品、ケースの角部分を強化して保護力を向上させた製品、ストラップ取り付け穴のある製品などがあります。\n一方、AliExpressでは純正品そっくりのレザーケース、シリコーンケース、レザーウォレットも販売されています。同様の他の商品に比べて少し高価（とはいっても1,800円前後）な値付けになっていて、ロゴ付き (with logo) と書かれていることもあります。これらの製品は、実際にAppleロゴがついて、純正品と同じ紙ケースに入って販売されているようです。おそらくは、Appleが委託生産した余剰品が流出しているのではないかと思います。アパレル製品などでよく聞く話ですね。\nMagSafeスタンド MagSafe充電器をはめ込んで、iPhoneを充電しつつ支えるスタンドも多数販売されています。金型さえ用意すれば量産できるこのタイプの製品は、AliExpressのお得意分野です。例えば以下の製品は送料込みで1,030円くらいです。丸い部分にMagSafeのコイルをはめ込みます。それにより、iPhoneを当てるだけでしっかりと支え、同時に充電もしてくれます。角度調整できる点も便利でした。別途MagSafe充電器が必要です。\n車載ホルダー 車のダッシュボードにiPhoneを取り付けるホルダーです。この手の製品は以前からたくさんあり、iPhoneにカーナビさせるときに便利です。以前は、iPhoneをバネで挟んだり、iPhoneに鉄板を貼って磁石で固定したりしてました。それがMagSafeになってスマートで便利になりました。iPhoneをそのまま当てるだけで固定できて、同時に充電も可能になります。\nエアコン吹き出し口フィンに固定するタイプならば、両面テープでダッシュボードを汚す心配もありません。AliExpressならば送料込みで2,881円です。ちゃんと使えます。なお、Apple StoreではBelkinの製品が税別4,980円で売られてます。Apple純正MagSafe充電器に比べたら妥当な価格ですので、Apple Storeで買ってあげても良いかもです。\nMagSafeデュアル充電パッド iPhoneとApple Watchの両方を無線給電できるMagSafe充電器です。旅先で便利そうです。でも純正品は、税別14,800円と、高すぎな気がします。AliExpressなら送料込みで1,907円です。実際に入手したのは、下のリンク先の製品ではありませんでしたが、安っぽい感じでした。Apple Watch充電コイルがポップアップするヒンジ部分がすぐに壊れてしまいました。壊れた部分は接着剤で固定して、載せるだけで充電することにしました。以下の製品はちゃんとしているかもしれません。\nまとめ iPhoneの固定と充電が同時に可能なMagSafeは、iPhone 12の新機能の中で一番便利な機能なのではと思ってます。でも純正アダプタ類が高価なので、なかなか使いづらいです。互換品を使って活用したいと思います。\n","date":"2021-02-14T20:55:39+09:00","image":"/uploads/2021/02/Apple_iPhone12Pro-back-camera-magsafe-charger_10132020.gif","permalink":"/posts/12493/","title":"AliExpressで売っている格安MagSafe製品"},{"content":"中古で入手して色々設定したThinkPad T460sですが、すっかり放置してました。久々に起動したらOpenCoreは0.5.7でmacOSは10.15.6でした。今回は、OpenCoreを0.6.6に、macOSを11.2.1にアップデートします。\nT460sのGitHubから更新 あまり使う予定はないのですが、手持ちのマシンは最新にしておきたいという気持ちがあるので、アップデートを考えました。以前の記事、\nThinkPad T460s (6300U) にOpenCoreでCatalinaを導入\nでは、T460s用にチューンナップしたEFI一式を配布してくれているサイト\nGitHub - simprecicchiani/ThinkPad-T460s-macOS-OpenCore: Bootloader configurat\u0026hellip;\nのEFIデータをそのまま使ってmacOSをインストールしました。今回は自前で頑張るかなと思ったのですが、上記のサイトを再び見てみたところ、活発に更新されていました。タイミングが良いことに、これを書いている13時間前にOC 0.6.6用のEFI一式が更新されていました。ここまで面倒を見てくださるのなら、活用しない手はないと思い、早速EFI一式をダウンロードしました。\n基本的にはこれで問題なく0.6.6にアップデートできたのですが、以下の点で多少手をかけました。\n起動音を止める ジャーンという起動音を止めました。最近のMacで復活した起動音ですが、本物Macでも止めてます。今回、何度か起動を試みることになり、その度に大きな音で起動するので、止めました。\nSecureBootModel Catalinaが起動している状態から、githubで公開されているEFIに差し替えると、起動しなくなりました。\nOCB: Apple Secure Boot prohibits this boot entry, enforcing! というエラーが出ます。検索したところSecureBootModelをDisabledにすれば良いとわかりました。今まではDefaultに設定してありました。OpenCoreのマニュアルにもこのことは書いてありました。そこでこれをDisabledにしたところ、起動するようになりました。\nただその後、後述のようにBig Surをクリーンインストールしたところ、SecureBootModelをDefaultにしても問題なく起動するようになりました。なので、現在は元のデフォルト値である、Defaultに戻しました。\n矢印アイコンを追加 EFIを入れ替えたところOpenCanopyが動かなくなってました。例の矢印アイコンが足りないのが原因でした。なのでそれを追加しました。ただ、現在githubで配布されている一式には矢印アイコンも入っているようです。\nBig Surをクリーンインストール これでOpenCore 0.6.6 + Catalinaで動くようになりました。そこで、次のステップとして、Big Surにアップデートしようとしました。すると、Big Surのインストーラが途中で止まってしまいました。なので、Big Surインストール用のUSBメモリを作り、これにEFI一式を入れました。そしてUSBメモリから起動して、内蔵SSDを消去してのクリーンインストールを行いました。その結果、Big Surがインストールできました。SecureBootModelもDefaultで動くようになりました。ファイルシステムに何らかの不整合があったのかもしれません。その後、11.2.1にアップデートしました。\n","date":"2021-02-11T16:32:01+09:00","image":"/uploads/2020/04/t460s.jpg","permalink":"/posts/12606/","title":"ThinkPad T460sの更新 (OpenCore 0.6.6 + macOS 11.2.1)"},{"content":"macOS Big Sur 11.2.1が配布されたので、11.2からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.6で起動していて、kext類は最新です。\nいつものマイナーアップデートのさらにマイナーなアップデートのようです。古いMacBook Proで充電できない問題が修正されているようです。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐインストール」ボタンを押しました。\nこの後、アップデートファイルがダウンロードされ、3回、再起動しました。1回目のアップデートのOpenCore画面では、いつもの起動ボリュームにしているMacintosh HDというボリュームが2個見えてましたが、デフォルトで選択されているままでokでした。インストール後、何の問題もなくBig Sur 11.2.1が起動しました。\n特に気づく変更点はありません。ビルドは20D74になってました。\n","date":"2021-02-10T17:42:55+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/12627/","title":"Big Sur 11.2.1にアップデートする"},{"content":"OpenCoreの0.6.6が公開されたので0.6.5からアップデートしました。config.plistの変更点はほとんどありませんでした。なぜかOpenCanopyが動かなくなってしまいましたが、機能としては問題ありません。/EFI/OC/Resources/ImageにLeft/Right.icnsファイルを追加するとOpenCanopyも動きました。\n0.6.6をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nOpenCore 0.6.6とmacOS 11.2で動作確認している手元のマシンは以下です。\nASUS Z390 ROG MAXIMUS HERO + 9900K + Radeon RX 580 ASUS Z490G + 10900K + Radeon RX 5700XT .efiファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。でも今回は、Bootstrap.efiがフォルダーごと消えてました。以下はありません。\nEFI/OC/Bootstrap/Bootstrap.efi それ以外は前回と同様です。なので入れ替えるべきファイルは以下でした。\nEFI/BOOT/BOOTX64.efi EFI/OC/OpenCore.efi EFI/OC/Driversの中のうち、現在使用しているもの：手元のマシンでは、OpenCanopy.efiとOpenRuntime.efi EFI/OC/Toolsの中のうち、現在使用しているもの：手元のマシンでは、OpenShell.efi ACPIとKextsは、OpenCoreの範疇では無いので変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、比較しながら新しいconfig.plistを作りました。\n変更点は以下のようでした。\nKernel/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にしておきました。 いずれも大きな変更ではなさそうです。\nOpenCanopyが動かない 以上の設定で、0.6.5から0.6.6に移行できました。問題なく起動して動いているのですが、なぜかOpenCanopyが動かなくなりました。ピッカー画面が、シンプルなテキストメニューに戻ってしまいました。OpenCanopy周りが色々変わったというような記述がありましたので、何か設定を変更しなければならなかったのだと思います。見た目の問題なので、とりあえずこれで使って行きます。\nOpenCanopyを動かす（追記） コメントで教えていただいて調べたところ、/EFI/OC/Resources/Imageに\nLeft.icns/Right.icns ModernLeft.icns/ModernRight.icns OldLeft.icns/OldRight.icns というファイルが必要になっているようです。それぞれ、Misc -\u0026gt; Boot -\u0026gt; PickerVariantを、Default、Modern、Oldに設定した時に使われるアイコンファイルです。これらをこちらから入手して追加したところ、OpenCanopyが動くようになりました。\n","date":"2021-02-03T22:35:18+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/12508/","title":"OpenCore 0.6.5から0.6.6に更新"},{"content":"macOS Big Sur 11.2が配布されたので、11.1からアップデートしました。アップデートしたのは、Z390マザーボードのマシンです。OpenCore 0.6.5で起動していて、kext類は最新です。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐアップデート」ボタンを押しました。\nこの後、アップデートファイルがダウンロードされ、2回、再起動しました。インストール後、何の問題もなくBig Sur 11.2が起動しました。\n特に気づく変更点はありません。ビルドは20D64になってました。\n","date":"2021-02-02T22:02:22+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/12496/","title":"Big Sur 11.2にアップデートする"},{"content":"RealtekのRTL8125Bチップを搭載した2.5Gbps Ethernet PCIeカードを、macOSで動作確認しました。前回の記事で8125A搭載カードの動作確認しましたが、今回は改良版のBです。Aと比較すると、Bは発熱がほとんどありませんでした。\nRTL8125A搭載カード Realtekの2.5GbE用チップを搭載した2.5G BASE-TのEthernet拡張カードがmacOSで使用可能だったことを書きました。\n2.5G BASE-T PCIe Ethernetカードを使う\nこの記事で紹介したカードは以下の製品です。AliExpressやAmazonで2,000円程度で販売されてます。\nこれをシステム情報で確認すると、チップ名はRealtek RTL8125Aとなってました。\nRTL8125AとB 調べてみると、RTL8125には型番末尾がAのものとBのものの2種類があり、最初に出たのがAで、後継モデルがBのようです。Realtekのサイトによると「 (RTL8125Bは) 第２世代2.5G チップで、世界最小の消費電力（\u0026lt;700mW）と最小パッケージサイズ（6mmx6mm）の2.5Gイーサネット製品です。」というような説明があります。ネットの情報にも、末尾にBがついたRTL8125Bは、省電力改良版であるとの説明がありました。発熱が抑えられているようです。\nRTL8125B搭載カード どうやらAよりBの方が改良されているようです。B搭載カードは多少お高いのかなと思い検索したところ、同じかむしろ安いくらいでした。ということで改めて以下のカードを取り寄せて、macOSでの動作を確認することにしました。\nRTL8125Aは熱い 8125Bに交換する前に、8125Aの様子を観察しました。小さな放熱板が取り付けられているのですが、それがかなり熱くなってました。熱いお風呂くらいに感じたので50度くらいかと思ったのですが、その後、触れた指先が2-3日ヒリヒリしてました。もっと高温だったのかもしれません。\nRTL8125Bの動作確認 Bのチップに交換しても、正常に機能しました。RTL8125用のドライバー、LucyRTL8125Ethernet.kextで動作しました。\nGitHub - Mieze/LucyRTL8125Ethernet: macOS driver for Realtek RTL8125\nシステム情報でチェックすると、RTL8125Bであることを確認できました。\n前回と同様にiperf3コマンドで速度測定もしましたが、Aのチップと性能は同じでした。今回のカードには、上の写真でわかるように、少し大きめのヒートシンクが取り付けられてます。これに指で触れても、ほぼ常温でした。iperf3コマンドを何度も起動しましたが、発熱を感じることはありませんでした。発熱がかなり抑えられていて、低消費電力になっているようです。\n実はRTL8125AのカードではWOLが全く効きませんでした。RTL8125Bに変えたところ、２回に１回くらいの割合で、WOLが機能しました。でも、これではWOLとして使えないと思いました。幸い、マザーボード搭載のI219VはWOLが効くので、LANからの起動にはこちらを使っていきます。\nまとめ RTL8125AのカードをBのカードに交換しました。性能は変わらないですが、チップの発熱が圧倒的に少なくなりました。同じくらいの価格で販売されているので、買うならRTL8125Bのチップが搭載されているカードが良いと思います。\n","date":"2021-01-28T22:58:00+09:00","image":"/uploads/2021/01/RTL8125Bs.jpg","permalink":"/posts/12247/","title":"RTL8125B搭載の2.5GbE PCIeカード"},{"content":"電源をoffにしたhackintoshをWake On LANの機能によって起動する記事を少し前に書きました。今回は、WOL機能をSiriから呼び出して「Hey Siri, マックをつけて」で電源投入できるようにしました。hackintoshに限らず大抵のコンピュータ（ただし本物のMacは除く）に使える手法です。\nSiriでショートカット呼び出し Apple製品に搭載されたSiriは、HomeKit対応デバイス（アクセサリ）に直接接続して、色々なコントロールをしてくれます。HomeKit対応デバイスには、照明器具とか学習リモコンとかデロンギのヒーターなどがあります。なのでWOLのマジックパケットを送出するコンピュータを、HomeKit対応サーバとして設定すれば、これをSiriから操作することも可能です。でも今回はこれはやりません。\nHomePodとWatchは特定のiPhoneと紐付けられているので、SiriはそのiPhoneに登録したショートカットも実行できます。ショートカットとは、一連の操作を記録したiOS版バッチファイルのようなものです。macOSだとApple ScriptやAutomator.appのような存在です。なのでショートカットからWOLできるように設定すれば、これをSiriから起動することが可能です。今回は、iPhoneショートカットを利用する方法で、SiriからWOLします。\nSiri (HomePod mini) --\u0026gt; iPhone short-cut --\u0026gt; WOL起動 iOS用にWOLを行ってくれる無料アプリにRemoteBoot WOLがあります。これもショートカットに対応しているので、RemoteBoot WOLを起動してWOLを実行するショートカットを作れます。これで設定しておけば、iPhoneのSiriならば音声でお願いしてWOLを起動させることが可能です。\nSiri --\u0026gt; iPhone short-cut --\u0026gt; RemoteBoot WOL --\u0026gt; WOL ただとても残念なことに、HomePod miniのSiriからこのショートカットを起動すると「コンパニオンデバイスで続きの操作を行う必要があります」と言われてしまい、この後iPhoneでの画面操作が必要になります。結局はiPhoneを使用することになるので、HomePodを使う意味がありません。そこで、「コンパニオンデバイス (iPhone) で続きの操作を行う必要」の無いショートカット作りを目指します。\n全体の流れ RemoteBoot WOLを利用したショートカットでは、その後のiPhone操作が必要になりました。もっと単純なショートカット、例えば単に特定のURLにアクセスするだけのショートカットならば、iPhoneでの操作は不要なのではと考えました。以下に示すように、実際にiPhone画面操作不要のショートカットが作れました。\nそこでURLアクセスされるとWOLのマジックパケットを送出するNode.jsサーバを作ることにします。全体の流れは、Siriに「Hey Siri, マックをつけて」と音声でお願いすると、iPhoneのショートカットが起動して、Node.jsが動くサーバが反応し、WOLを発動させます。以下に順番を示します。\nSiri --\u0026gt; iPhone short-cut --\u0026gt; Node.js --\u0026gt; WOL なので以下のものが必要です。\nSiriを動かすHomePod、Apple Watch、iPhoneなど\nショートカットを実行するiPhone\nNode.jsが常時動いているサーバ (Raspberry Piなど)\nWOLで起動するコンピュータ (hackintoshなど)\nと4.が必要なのは当然ですね。HomePodを使う上でiPhoneは必須なので2.はあるはずです。HomePodはiPhoneの機能を呼び出す端末のような存在なので、動作中にもiPhoneが必要です。\n3.に関して、今回はたまたまNode.jsを使いますが、他にも実現方法はたくさんあります。いずれにしてもSiriからの命令を受け付けるために待機するサーバが必要です。実際には、macOSマシンでも、Windowsでも、Linuxマシンでも良いです。Intel CPU搭載のQNAPのNASもNode.jsが提供されているので、それでも良いです。今回は、安価・省電力に実現するためにRaspberry Piを使いました。将来色々と活用したいところですが、今の所WOLのためだけのサーバなので、できる限り簡単なものにしたかったです。インストールしたLinux (Raspbian) もCUIだけです。\nNode.jsを使う Node.jsをインストールする WebアクセスするとWOLのためのマジックパケットを送出するサーバをNode.jsを使って作ります。そのためにまずはNode.jsをインストールします。macOSならばHomebrewでインストールできます。\n$ brew install nodejs Updating Homebrew... Raspberry PiやWindowsのWSLなどのLinux環境ならaptを使います。\n$ sudo apt install nodejs Node.jsでHello World! Node.jsをインストールするとnodeコマンドが使えるようになります。Node.jsはサーバーサイドでのJavaScript実行環境です。って言われてもなんのことかピンと来なかったのですが、乱暴に言ってしまうと普通のプログラミングに使えるJava Scriptインタプリターです。pythonコマンドとかrubyコマンドと同じようにnodeコマンドでJava Scriptファイルを実行できます。例えば、hello.jsというテキストファイルに\nconsole.log(\u0026#34;Hello World!\u0026#34;); という1行のJavaScriptプログラムが書かれていた時、シェル環境からnodeコマンドを使うと\n% node hello.js Hello World! のように実行できます。nodeコマンドのパスを1行目に書いて、\n#!/usr/local/bin/node console.log(\u0026#34;Hello World!\u0026#34;); のような内容のテキストファイルを作って、実行パーミッションを与えておけば、shellスクリプトファイルとして実行することもできます。\n通常、Java Scriptはクライアント側のwebブラウザで実行するので、ファイルアクセスやハードウェアアクセスに制限があります。サーバ機能も書けません。一方で、nodeコマンドで実行すると、制限無しで普通のプログラミングができます。サーバーサイドの実行環境と言われる所以です。\nNode.jsでWOL Node.jsでは色々なパッケージをnpmコマンドでインストールしたり、削除したり、管理します。Wake on LANをサポートしてくれるパッケージもあります。その名もwake_on_lanです。これをインストールするには、\n$ npm install wake_on_lan とします。npmが無いと言われたら、homebrewやaptなどで\n$ sudo apt install npm というようにしてインストールします。これでWOLに関する機能が使えるようになります。WOLさせたいコンピュータのMACアドレスが例えば11:22:33:44:55:66の場合、\nvar wol = require(\u0026#39;wake_on_lan\u0026#39;); wol.wake(\u0026#39;11:22:33:44:55:66\u0026#39;); というプログラムでWOLを機能させることができます。\nNode.jsでサーバーアプリ nodeコマンドは、webサーバー側でJava Scriptを動かすコマンドですので、webサーバの機能もあります。そもそもNode.jsが作られた目的がサーバ機能だったようです。例えば、以下のようなJava Scriptプログラムを用意して、nodeコマンドで動かしておきます。\nvar http = require(\u0026#39;http\u0026#39;); var server = http.createServer(function(req,res){ res.write(\u0026#34;Hello world!\\n\u0026#34;); res.end(); }); server.listen(8080); このプログラムを起動しておいて、このコンピュータのアドレスのポート8080番にhttpアクセスすると（例えばhttp://192.168.xxx.xxx:8080にアクセスすると）、Hello world!の文字列を返します。curlコマンドでアクセスするとこんな結果になります。\n$ curl http://192.168.xxx.xxx:8080 Hello world! SafariでこのURLにアクセスすると以下のような表示になります。\nこのようにプログラミングすれば、特定のURLに対して、決められた処理を実行するプログラムが簡単に書けます。\nURLアクセスでWOL 上で紹介したWOLのサンプルと、サーバアプリのサンプルを組み合わせると、特定のURLにアクセスした時にWOLするプログラムが書けます。例えば、\nvar http = require(\u0026#39;http\u0026#39;); var wol = require(\u0026#39;wake_on_lan\u0026#39;); var server = http.createServer(function(req,res){ wol.wake(\u0026#39;11:22:33:44:55:66\u0026#39;); res.write(\u0026#34;Wake on LAN.\\n\u0026#34;); res.end(); }); server.listen(8080); というプログラムを起動しておきます。すると、他のコンピュータからこのコンピュータのアドレス、http://192.168.xxx.xxx:8080にアクセスすることで、WOLを発動させることができます。このときWOLが動いたことがわかるようにWake on LAN.と返答するようにしておきました。\nRaspberry Piに固定IPアドレスを設定して、このプログラムを実行しておけば、Raspberry PiがWOLを発動するサーバになります。サーバとして動かしたい場合は、Raspberry Piからログオフしても動いていて欲しいので、\n$ node hello_server.js \u0026amp; というように最後に\u0026amp;をつけて実行します。これを終了するときはps -xコマンドでPIDを調べてkillします。動作が確認できたら、Raspberry Piの起動時に自動的に実行されるよう設定すると良いでしょう。ちなみに、\n/etc/rc.localに書き込む crontab -eの@reboot行に書く などの方法があります。\niPhoneショートカットでWOLする 次に、上で作ったNode.js WebサーバにiPhoneからアクセスするショートカットを作ります。iOSにはショートカットというアプリが標準で入ってます。こんなアイコンのアプリです。\nショートカットは、macOSだとAutomator.appに相当するソフトで、iOS操作やプログラム実行を自動化するショートカットを作成します。ここでは、上で作ったWOLサーバにアクセスするショートカットを作り、それに「マックをつけて」という名前を付けます。ショートカット作成後に「ホーム画面に追加」という設定を行うと、iPhoneの画面にショートカットアイコンが現れます。\n最初に、ショートカットアプリの中で、「すべてのショートカット」を閲覧すると、右上に+のボタンが現れます。これを押すと新規ショートカットが作れます。\nここでは、URLを指定して、それを開くという2個のアクションを追加します。まずは最初のアクションを追加します。\nアクションの候補が出てくるので、検索窓にurlと打ち込んで、URL関連のアクションを検索します。\nすると、「URL」というアクションがあるので選びます。URLを指定するアクションです。\nここで、WOLサーバのアドレスと、ポート番号を示すURLを指定しておきます。さらにその下の+ボタンを押して、次のアクションを追加します。\nここでは、「URLを開く」もしくは「URLの内容を取得」あたりのアクションが使えそうです。URLを開くは、実際にはSafariが起動します。これを試したところ、iPhoneでの操作が必要で、Siriには「コンパニオンデバイスで続きの操作を行う必要があります」と言われてしまいました。RemoteBoot WOLの場合と同じで、これでは元の木阿弥です。\n一方で、「URLの内容を取得」アクションの方は、最初の起動で確認を求められるものの、以降はiPhoneの操作なしで実行できました。なので、こちらを選びます。\nこれで完成です。URLを指定して、その内容を取得する手順となりました。URLの内容には意味がなくて、アクセスさえしてくれれば良いのです。この後、名前をつけて保存します。この名前は、Siriに依頼する時の名前になります。「マックをつけて」にしました。\nこれで「マックをつけて」ショートカットが完成します。最初に起動すると、先に述べたように、アクセスの設定を求められます。ここでOKを押しておけば、以降は何もしなくても実行してくれるようになります。\nHey Siri, マックをつけて これで、HomePod miniに「Hey Siri, マックをつけて」と話しかけてみます。iPhoneのショートカットが反応し、WOLサーバが応答し、hackintoshが起動するはずです。本物のMacだと電源遮断の状態からのWOLは出来ないらしいので、これはhackintoshならではの機能です。\niPhoneショートカットを呼び出す機能は、iPhoneと連携して動くHomePodとWatchのSiriでのみ可能です。macOSのSiriにお願いするとこんな返事が返ってきます。もしかしたらハンバーガー屋さんの方を探そうとしてくれているのかもしれません。\nまとめ HomePod miniに話しかけてhackintoshの電源を投入できるようになりました。そのために、Raspberry PiにNode.jsをインストールして、WOLを発動するサーバとし、これにアクセスするショートカットをiPhone上に作成しました。Siriからプログラムを起動させたい場合、以前はHomeKit互換のデバイスとして構築する必要がありました。今はショートカットが使えるので、楽になりました。\n","date":"2021-01-13T23:55:08+09:00","image":"/uploads/2020/12/black512.jpg","permalink":"/posts/12217/","title":"「Hey Siri, マックをつけて」で電源を投入する"},{"content":"Mac mini Late 2012の中古に2.5 inch SSDと大容量HDDを内蔵してサーバマシンにしました。この世代のminiは、Big Sur以降は動きませんがメモリもストレージも拡張可能で、さらにM1 Mac miniが出て値下がり傾向にあり魅力的です。\nMac miniで自宅サーバ ストレージをたくさん搭載できる自作hackintoshを自宅サーバにするのは良いアイディアだと思ったのですが、遠隔から再起動する時は不安です。ソフトウェアアップデートや設定変更などで起動しなくなると、マシンのところまで出向いて操作をしないといけません。その点、本物のMacなら安心です。ということで、安価で、ストレージをたくさん搭載できて、邪魔にならない中古Mac miniを探してました。\n拡張性の高いmini 今話題のM1 Mac miniは高性能ですが、拡張性が貧弱です。いろいろ増設したいサーバには不向きだと思います。さらには、大したサーバではないので、安価な中古品が欲しいです。それで古いモデルを検討しました。最近の世代のMac miniを比較すると以下のようになります。\nMac mini 2020 2018 2014 2012 2011 CPU M1 Coffee Lake Haswell Ivy Bridge Sandy Bridge macOS Ventura Ventura Monterey Catalina High Sierra メモリ交換 – 可能 – 可能 可能 HDD/SSD交換 – – 可能(M.2, SATA) 可能(SATA x2) 可能(SATA x2) 2020と2018モデルは現行製品です。どちらかを買うならM1 Mac miniが断然良いです。CPU性能が良いですし、それ以上にiGPUが強化されています。サーバとして使うならiGPUはあまり関係無いですが。\n2014モデルはMontereyまで対応してます。SSDソケットは独自仕様ですがM.2への変換ケーブルが安価に入手可能です。でも2014年モデルは、メモリ交換ができない点がとても残念です。4, 8, 16GBモデルが販売されましたが、流通している中古の大半が4GBで、8GB以上のモデルは見つけられても高価です。少しお金を足したらM1 Mac miniが買えてしまうくらいです。2014モデルがメモリ交換可能だったら、安価に16GB程度へ交換できたのにと思います。\n2012年以前のモデルは拡張性に優れてました。メモリ・HDDのどちらも増設が簡単です。あの小さな筐体に2.5インチSATAドライブが2個も入ります。2012年までは、Mac mini Serverというモデルが併売されていて、これが2台のドライブに対応していました。非Serverモデルにも2個目のSATAコネクタがちゃんとはんだ付けされているので、Serverモデルのケーブル部品を取り寄せることで、安価にSATA増設できます。\nApple、macOS 10.14 MojaveとmacOS 10.15 Catalina向けに「セキュリティアップデート2020-007/-001」を公開し、High Sierraのサポートを終了。\nただ2011年モデルはHigh Sierraまでの対応で、すでにサポートが打ち切られています。2012年モデルも、Catalinaまでしかサポートされません。2011よりはマシですし、2011と2012で中古価格はそれほど違わないです。そこで2012年モデルを探すことにしました。Serverモデルが作られた最後の世代なので、サーバ向きかと思います。\n探してみると、税・送料込み2万円台前半で中古Mac mini 2012が売られてます。中古のほぼ全てが、Serverではない通常のMac miniなので、SATAドライブは1個のみ搭載されてます。これにSATAドライブを増設して2個として、Mac mini Server 2012相当に作り変えることにしました。\nストレージ交換 久々にminiを手にすると、記憶以上にでかいと感じました。Intel NUCよりはるかに大きいですし、HP EliteDesk 800 G2 DMよりも一回り大きいです。NUCやEliteDeskに比べると、Mac miniは電源も内蔵していますし、2.5インチも2台入るので、ある程度大きくなるのは仕方ないです。\n裏の丸いプラスチック蓋は少し回すと外れます。蓋を外した丸い穴から作業することになるので作業はなかなか大変です。HP EliteDesk 800 G2 DMのような普通のデザインならば、もっと簡単に分解できるはずです。オシャレな見た目の代わりに、メンテナンス性はよくないです。以下では、IFIXITから写真お借りして説明します。\n蓋を外してすぐに見えるファンは簡単に外せます。ネジ3本で止まってます。またロジックボードに繋がっているコネクタは、上に持ち上げると外れます。一見するとスライドして外れそうな形をしてますが、違います。方向を間違えると壊れます。昔それで失敗したことがあります。\n(引用元：IFIXIT)\n次に、薄いプラスチックの黒いカバーを外します。これはファンが、ヒートパイプの熱を外気と一緒に吸い込まないためのカバーです。バックパネルに近いあたりでネジ1本で固定されてます。薄いので割れやすく注意が必要です。これがまた、なかなか外れません。少しずつ歪ませて、回転させて外します。コツを掴めば次からはもう少し楽に外せるかもしれません。\n(引用元：IFIXIT)\n次に、アンテナのついているメッシュ金属パネルを外します。最初にネジ4本を外します。その後、バックパネル側にスライドして外すのですが、これもとても難しいです。いろいろ動かしながら、多少歪ませながら、苦労して外します。アンテナケーブルがロジックボードに繋がってますが、HDDが邪魔で外せません。しばらくは繋がったままにします。\n(引用元：IFIXIT)\nこの世代のminiには、上段と下段に合計2台の2.5 inchドライブを内蔵可能です。通常のminiには、HDDが「下段」に1個入ってます。ややこしいですが、写真は本体の裏から見ているので、手前が本体の下側になります。Mac mini Serverには、上段と下段に合計2台のHDDが入ってました。HDDは基板上に四角いコネクタが挿さってるので、プラスチックのヘラのようなもので持ち上げて外します。このコネクタからはそのままHDDに接続されているので、SATAコネクタだと思われます。隣に、使われてない空のSATAコネクタもあります。通常のminiにも2個目のドライブ用SATAコネクタを残してくれているのは、とてもありがたいです。\n(引用元：IFIXIT)\nここまでくると、ロジックボードはネジを1本で筐体に固定された状態です。バックパネル近くにあるそのネジを外します。かなり長いネジです。そのあとは、コの字型の金具でロジックボードを後ろに1cmくらいスライドします。ロジックボードがバックパネルと一緒に出てきます。SATAケーブル、フロントパネルLED/リモコンへのケーブル、電源ケーブルがつながっているので、それ以上はスライドしません。ケーブルを外すのが面倒なので1cmスライドしたところで止めておきます。それでもHDDは外せます。\n(引用元：IFIXIT)\nHDDは空間にはまっているだけなので、斜めに傾けたり、押したり引いたりしているとなんとか外せます。HDDが外せると、Wi-Fiアンテナ端子へのアクセスも楽になるので、これも外しておくのが良いと思います。この後の作業でアンテナ線にダメージを与える心配がなくなります。\nHDDを取り外すと、跡には2.5インチドライブが2個入る、巨大な空間が現れます。Mac mini Serverはここに2台のHDD/SSDが入ります。このminiにも、「上段」にSSDを、「下段」にHDDと、2台のドライブを入れることにしました。ただ、元々内蔵されている上段ドライブ用のSATAコネクタはありますが、上段用の部品はありません。それでAmazonで「上段ドライブ用ケーブル」を買います。交換に必要な全ての工具と取り付けねじ込みで、送料込み800円くらいと安いです。\nこの取り付けキットの取り付けネジで、上段ドライブをすでにある枠に取り付けられます。でも上段ドライブ用の枠に取り付けようとすると、このあと、いくつかのケーブルを外し、ロジックボードと電源を外す作業が必要です。面倒ですし、この先ドライブを変更したい時にもすぐにアクセスできることを考えて、上段のドライブも下段のドライブと同様に嵌め込むだけにしておきます。ただ、最近のSSDだと2012年代HDDに比べて薄過ぎて安定しません。そこで100円均一で売っている防振ジェルでスペースを埋めて、これにSSDを貼り付けておくことにしました。\nこんな感じで収まります。ケーブルがコネクタの上に来るように位置調整しておきます。\n上段のSSDと下段のHDDの間にも防振ジェルを挟んで、元の位置にHDDを嵌め込みました。中古品に内蔵されていたHDDはへたれている可能性があるので、新しいHDDに交換しました。\nこの後は、逆の手順で組み直します。最初は、ファンのコネクタがちゃんと挿さっていなかったので、回転しませんでした。お気をつけください。\n動作確認 搭載されていたCPUを確認したところi7-3615QMという型番でした。\n% sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz Late 2012に3機種あった真ん中のグレードです。モバイル用のCPUですが、それでも4コア8スレッドなので、Zoomのバーチャル背景も動きます。Geekbench 5でのスコアは、マルチコアで2800くらいでした。\nM1に比べたら0.4倍くらいの性能です。でも、普段使いには問題ないくらいキビキビ動きます。これくらい古いMacでもSSDに交換すれば実用的に使えますね。\nまとめ Mac mini Late 2012中古のストレージを増設してサーバマシンにしました。このモデルは拡張性があった古き良き時代のMacです。最新macOSは走りませんが、安く流通していますし、拡張してまだまだ使えると思いました。\n","date":"2021-01-10T21:51:51+09:00","image":"/uploads/2020/12/m2.jpg","permalink":"/posts/11951/","title":"2012年のMac miniをServerにする"},{"content":"RealtekのRTL8125チップを搭載した2.5Gbps Ethernet PCIeカードを、macOSが動く自作PCで使ってみました。ドライバにはLucyRTL8125Ethernet.kextを使います。2.5Gbpsの速度が出ていることを確認しました。安価なので1G超えLANを試すのに良いと思います。\nRTL8125搭載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のカードに比べると安価なので、導入しやすいです。\n価格以外にも、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カードは、現状に即した選択と思いました。\n今回注目したのは、2.5Gカードとして最安値で販売されている以下の製品です。AmazonとAliExpressのどちらにも、同じ写真の製品が複数販売されています。扱っている店が違うだけで、おそらく全て同じ製品だと思われます。\nAmazonだと送料込みで2300円程度ですが、AliExpressでは1900円程度です。差額は大差ないのですが、Amazonの納期は3週間以上で、AliExpressの方は1週間未満でした。価格と納期は時期により変化すると思いますが、現状ではAliExpressの方が優秀な様子でした。以下ではAliExpressから届いたカードを使ってみた報告です。\nLucyRTL8125Ethernet.kext 実際のMacでは採用されていないチップなので、macOSにはドライバーが含まれていません。でもmacOSで動くRTL8125用のドライバー（kextファイル）が以下で公開されています。Kext Updater.appにも登録されているので、そちらからもダウンロード可能です。\nGitHub - Mieze/LucyRTL8125Ethernet: macOS driver for Realtek RTL8125\nちなみにLucyというのは作者のMiezeさんの猫の名前のようです。\nLucyRTL8125Ethernet.kextをOpenCoreのKextsフォルダに入れ、ProperTreeのスナップショット機能を使ってconfig.plistに登録したところ、このRTL8125カードは問題なく動作しました。ただしWake On Lanは効きませんでした。カードの販売サイトではWOL対応していると書いてあるので、おそらくはmacOSとの相性問題ではないかと思います。\nシステム情報で確認 動作したところでmacOSの「システム情報」を開くと、RTL8125Aを搭載したPCIeカードだと確認できました。ちなみに、もう一つ見えているEthernetカードは、ASUS Z390マザーボード上に実装された1G Base-TのI219です。\n速度測定 速度が出ていることを確認するためにiperf3コマンドで速度測定しました。このカードを取り付けたASUS Z390マシンを、ASUS Z490マシンに接続しました。どちらのマシンも、OpenCore 0.6.4 + Big Sur 11.1の構成です。Z490には、Intel I225-Vが搭載されています。なので接続は以下のようになります。\nZ390 (Big Sur) + RTL8125A \u0026lt;-----\u0026gt; Intel I225-V + Z490 (Big Sur) また、今回の測定ではジャンボフレームをonに設定しました。なので前回の測定より性能が出ました。ジャンボフレームを有効にするには、システム環境設定の、ネットワーク、詳細、ハードウエアで構成を手動にします。手動で2.5Gに設定すると、相手は2.5G Base-T限定になり、1Gハブなどには接続できなくなります。\niPerf3のクライアント側の結果を以下に示します。2.5Gbpsの速度が達成されている様子がわかります。\n% 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. ","date":"2021-01-06T18:12:52+09:00","image":"/uploads/2021/01/25GbENIC.jpg","permalink":"/posts/12347/","title":"2.5G BASE-T PCIe Ethernetカードを使う"},{"content":"OpenCoreの0.6.5が公開されたので0.6.4からアップデートしました。config.plistの変更点はほとんどありませんでした。何も変更しなくても問題なく起動すると思われます。\n0.6.5をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\n.efiファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。前回と同様、入れ替えるべきファイルは以下でした。\nEFI/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フォルダの中身を配布ファイルに差し替えておきました。\nconfig.plistを更新する 現在のconfig.plistをconfig_old.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、比較しながら新しいconfig.plistを作りました。\n変更点は以下のようでした。\nMisc/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に移行できました。\n","date":"2021-01-05T18:01:54+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/12325/","title":"OpenCore 0.6.4から0.6.5に更新"},{"content":"HomePod miniにはType-Cのケーブルがついています。これをASUSマザーボードバックパネルのType-Cコネクタに接続したら、macOSのファインダーにHomePodが現れました。この状態でHomePodのメンテナンスが可能です。\nHomePodをhackintoshに接続する HomePodにはUSB Type-Cのケーブルが1本だけついてます。本体からは抜けないので、生えている感じです。電力供給専用だとばかり思っていたので、これを自作PCに接続したらどうなるかとは考えてませんでした。\nところで、最近HomePod miniの調子が時々良く無いです。iPhoneと連携する機能をリクエストすると\n「接続で問題が起きています。iPhoneがこのHomePodと同じWi-Fiに接続されていることを確認してください。」 という返答をすることがあります。検索すると、そういう状況で困っている人は多くて、\nWi-Fiを2.4GHzにしたり、 HomePodを初期化したり、 iPhoneを再起動する と一時的に治るようでした。その対処法の一つに、HomePodをMacにUSB接続して初期化する方法が書いてありました。\n「そんなことが可能ならばhackintoshでも試したい」ということで、ASUS Z390 + 9900K + OpenCore 0.6.4 + Big Sur 11.1で構成した自作マシンのバックパネルType-Cコネクタに、HomePodを直結してみました。するとなんと、ファインダーにHomePodが現れました。\nHomePodの上面LEDはオレンジ色で点滅します。これはオーディオ用パワーアンプを駆動するためには電力が不足していることを表しているらしいです。マザーボードのType-CコネクタにはUSB 3.1 PDの機能はなく、5V 2Aが出ているだけなので電力不足です。でも「HomePodを復元…」する機能は使えるようです。\nシステム情報で調べると、480Mbps接続しているようです。USB 2.0のHigh-Speedモードですので、おそらくは変換器経由でUSB 2.0/3.0 Type-Aコネクタに接続しても、同様にファインダーに現れるのではと思います。\nHomePodを復元する ファインダーウィンドウで唯一できることは、「HomePodを復元…」することのようです。試さないわけにはいかないです。これをクリックすると、こんなダイアログが出ます。\n何かのメディアもデータを入れたつもりもないので、ためらうことなく、復元ボタンを押しました。\nすると2.29GBの「HomePodソフトウェア・アップデート」のダウンロードが始まりました。おそらくはHomePodのOSがアップルのサーバからダウンロードされ、これによりHomePodがアップデートされるのだと思われます。\nこの後「ファームウェアが復元」されて、工場出荷時状態になりました。\nおまけ：Apple TVも接続してみた 5年前のApple TV (2015) にもType-Cのポートがあったので、同じくZ390マザーボードに接続してみました。こちらもファインダーに現れて、復元とアップデートができました。ソフトウェアアップデートのサイズは2.85GBでした。USBの接続は、やはり480MbpsのHigh-Speedモードです。ちなみにApple TVにメンテナンス用USBポートがついているのは2015モデルまでで、2017モデルからは廃止されてます。またType-Cなのは2015モデルだけです。\nまとめ Big Surが動いている自作PCに、HomePod miniをUSB接続したら、ファインダー上に現れて、ソフトウェアのアップデートなどが可能でした。Type-Cケーブルは単なる電源用だと思っていたので意外でした。\n","date":"2021-01-01T23:07:01+09:00","image":"/uploads/2020/12/black512.jpg","permalink":"/posts/12230/","title":"HomePod miniをASUS Z390マザーボードのType-Cに接続する"},{"content":"\n電源を落としたmacOSコンピュータをWake On LAN (Ethernet経由) で起動するよう設定しました。本物のMacだと電源を落とした状態からのWOLは不可能らしいです。条件はありますが、hackintoshならば電源off状態からのWOLが可能です。\nWake On LAN機能 Wake On LAN (WOL) は、スリープ状態や電源offのコンピュータを、ネットワークからのコマンドで起動させる機能です。WOL設定されたマシンのMACアドレス宛に、マジックパケットというデータを送りつけることで、目覚めさせます。WinowsをインストールしたHP EliteDesk 800 G2 DMでは、電源offからのWOLが動きました。でも実機のMacでは、検索した限りでは、電源offからのWOLは不可能なようです。\nWOLの設定は、どのコンピュータでも結構、困難を伴うようです。色々な要素が絡んでいて、不安定なことも多いようです。Hackintosh関係のサイトでも、WOLの設定が時々話題になりますが、大変そうでした。WOLが必要な状況にあるなら、常時電源onにしたサーバとして動かしておけば良いのにと思ってましたので、あまり興味はありませんでした。でも、手を出してみたら、停止していたコンピュータをネットワークから起動させる事が純粋に面白かったです。何かの目的のためにWOLするのではなく、人はWOLしたいからWOLしているのだと感じました。また、実機のMacでは出来ないことを達成するという要素も、hackintoshの醍醐味です。\nWOLには以下のような要素が関係するようです。このうち一つでも不完全だとWOLしません。またOSやドライバーのバージョンが変わると動かないこともあるようです。前回紹介したWindowsの場合でも設定は面倒でした。\nBIOSでの設定：電源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できるかどうかがある程度判定できます。\nASUS Z390 + Big SurでWOL 今回設定したマシン構成は、ASUS ROG MAXIMUS XI HERO Z390 + OpenCore 0.6.4 + Big Sur 11.1です。WOLに使用したのは、このマザーボードに搭載されているIntel I219-VギガビットLANです。\nBIOS設定 BIOSのAdvanced –\u0026gt; APM ConfigurationからPower On By PCI-EをEnabledに設定します。デフォルトはDisabledです。下の欄に、「オンボードLANコントローラやPCIeスロット上LANカードのwake-on-LAN機能を有効・無効にします」という説明が出てます。オンボードチップの場合も、PCIeスロット搭載カードの場合も、この項目でWOL設定できるようです。\nmacOSの設定 システム環境設定の省エネルギーで「ネットワークアクセスによるスリープ解除」にチェックを入れます。これはデフォルト設定です。実際のMacでは、この設定によりスリープからのWOLが可能になります。でも、電源offの場合はWOLしません。\nWOL対応kextを使う 以上のBIOSとmacOSの設定を行っても、当初はWOLが効きませんでした。BIOSで設定した直後に、電源を落とすと、WOLが効きます。でも一度でもmacOSを起動すると、それ以降、WOLが効かなくなりました。macOSの動作で、WOLが無効化されているような振る舞いです。ということで、macOSではWOLできないと書きましたが、その記事のコメントで、まっくぷろさんから、WOL対応しているらしいIntelMausiEthernet.kextバージョンを教えていただきました。このkextを使うことで、安定してWOLが動作するようになりました。\nGitHub - fischerscode/IntelMausiEthernet-WOL: OS X driver for Intel onboard LAN\nWOLするアプリケーション WOL状態で待機しているコンピュータは、そのMACアドレス宛にマジックパケットを送ると起動します。マジックパケットを送るには、先の記事でも紹介した簡単なPythonプログラムでokです。\n#!/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(\u0026#39;\\xFF\u0026#39;*6+\u0026#39;\\x99\\xAA\\xBB\\xCC\\xDD\\xEE\u0026#39;*16, (\u0026#39;192.168.xxx.255\u0026#39;, 7)) 最後の行が、目覚めさせたいコンピュータのNIC情報です。\\x99\\xAA\\xBB\\xCC\\xDD\\xEEの部分がMACアドレスで、192.168.xxx.255がIPアドレスです。IPアドレスの最後が255なので、ブロードキャストします。\nHomebrewで導入できるコマンドのwakeonlanをコメントで教えてもらいました。これをインストールすると以下のようにMACアドレスを指定してWOLできました。wakeonlanの中身はperlのスクリプトのようです。\nwakeonlan 99:AA:BB:CC:DD:EE App Storeには、GUIで機種を登録したり、MACアドレスを自動検出できる有料アプリ・広告付きアプリが多数あります。でも、遠隔地からWOLすることを目的と考えたら、シンプルなPythonプログラムで十分かと思いました。また、WOLのためのiPhoneアプリも多数あります。RemoteBoot WOLは、無料でユーザも多いようです。Windows用やAndroid用にももちろん多数のアプリがありますし、Amazonのデバイス用にもあるようです。記事冒頭のアイコンをお借りしたアプリは、FireTVなどで動くようです。\nまとめ ASUS Z390マザーボード搭載のIntel I219-V経由で、Big Surが動くコンピュータのWOLを試みました。電源offの状態から電源を入れられました。このために、BIOSを設定し、WOLに対応したIntelMausiEthernet.kextを使いました。これで外出先から電源を入れることもできそうです。\n","date":"2020-12-26T20:49:22+09:00","image":"/uploads/2020/12/bios2.png","permalink":"/posts/12223/","title":"Wake On LAN (WOL) を使ってmacOSの電源を入れる"},{"content":"10GbpsのPCIe Ethernetカードを使ってみました。iMac Pro (2017) で使われているAquantia AQC107というチップを搭載したカードです。ドライバーが元々のmacOSに含まれているのでkext不要で動きます。同じチップ搭載でも、簡単なパッチが必要な製品と、OOBで動く製品があるようです。\nASUSの10Gbps Ethernetカード フォーラムで教えていただいたMorgonautさんのビデオで、ASUSの10 Gbps EthernetカードがCatalinaでOOB動作すると紹介されてました。\n紹介されているのは、Aquantia AQC107という製品です。以下のように、送料込みで1.1万円くらいです。\nこのカードを、実はかなり前に買ったのですが、macOSで動かなくてお蔵入りになってました。「OOBで動くようになっていたのか」と思い、発掘して（なかなか見つかりませんでした）試してみました。結論から言うと、OOBでは動きませんでしたが、パッチを当てて動くようになりました。\nAquantiaチップ用パッチ（Big Sur版） Aquantiaの10Gbps EthernetカードのためのBig Sur版のパッチが以下で紹介されていました。これを使いました。動かした環境はZ390 + 9900K + OpenCore 0.6.4 + Big Sur 11.1です。\nAppleEthernetAquantiaAqtion.kextを以下のように書き換えれば良いようです。このkextは、\nKext: com.apple.driver.AppleEthernetAquantiaAqtion Find: D4TAAgAA (16進数: 0f 84 c0 02 00 00 ) Replace: Zg8fRAAA (16進数: 66 0f 1f 44 00 00 ) このkextの実体は以下の場所にあります。\n/System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleEthernetAquantiaAqtion.kext テキストエディタで作業するなら、OpenCoreのconfig.plistのKernel, Patchの項目に、次のdictを足せば良いです。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;ASUS XG-C100C (Aquantia AQtion AQC-107)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Count\u0026lt;/key\u0026gt;\u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;Enabled\u0026lt;/key\u0026gt;\u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;YnVpbHQtaW4=\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Identifier\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.AppleEthernetAquantiaAqtion\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;YmJiYmJiYmI=\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; PlistEDPlusで作業するなら、以下のようにします。\nこのように追記したconfig.plistを保存して再起動したところ、10G bps Ethernetカードが動きました。今のところ特に不具合はありません。\niperf3で動作試験 Morgonautさんのビデオではiperf3というツールで速度測定してました。これはLinuxなどで一般的な測定ツールのようで、Homebrewからbrew install iperf3コマンドでインストールできました。iperf3コマンドを2台のコンピュータで動かし、それぞれをサーバーとクライアントにして、通信速度を計測するツールです。\n今回、ASUSの10Gbpsカードを取り付けたのがZ390マザーボードです。測定の相方は、ASUS ROG STRIX Z490-GのマザーボードにmacOS Big Surをインストールしたコンピュータです。このマザーボードには2.5 GbpsのIntel I225-Vが搭載されています。1Gbps超えのハブを持っていないので、ASUSの10GbpsカードとZ490をEthernetケーブル（CAT 6Aで十分らしいです）で直結しました。\nZ390 (Aquantia 10Gbps) \u0026lt;-----\u0026gt; (Intel 2.5Gbps) Z490 それぞれのマシンに手作業で適当なアドレスを割り当てておきます。まずは、Z490マシンでiperf3をサーバーモードで動かしました。\niperf3 -s 一方、10Gbpsカードが載ったZ390マシンでは、サーバアドレスを指定して、クライアントモードでiperf3を動かしました。\niperf3 -c 192.168.x.x その結果、両方に同じ測定結果が表示されます。クライアント側の表示を以下に示します。\n% 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が性能通りの速度で動いていることも確認できました。\nOOBの10Gbpsカード 同じAquantiaのチップ搭載カードでも、Sonnetの製品ならばOOBで動くようです。以下のAmazonの販売ページにも、macOS対応と書かれてます。ASUSのカードより3,000円ほど高価です。今回はたまたま手元にASUSのカードがあったのでそれを試しましたが、この価格差ならば、パッチが不要なSonnetカードの方が良いと思います。（コメントいただいた情報によると、SequoiaではこのカードもOOB動作しないようです。 2025/09/15）\n","date":"2020-12-24T18:38:17+09:00","image":"/uploads/2020/12/811VxWd5jNL._AC_SL1500_.jpg","permalink":"/posts/12192/","title":"10G BASE-T PCIe Ethernetカードを使う"},{"content":"macOS Big Sur 11.1が配布されたので、11.0.1からアップデートしました。アップデートしたのは、Z390マザーボードとZ490マザーボードのマシンです。どちらもOpenCore 0.6.4で起動していて、kext類は最新です。システム環境設定の「ソフトウェア・アップデート」に通知が来ていたので、そのまま「今すぐアップデート」ボタンを押しました。\nこの後、3.27GBのアップデートファイルがダウンロードされ、再起動します。最初の再起動では、どういうわけか同じ名前の起動ボリュームが見えていました。どちらかがアップデーターのボリューム（従来だとBoot macOS Install from …というような名前でした）で 、どちらかが古いmacOSだと思われます。デフォルトで起動ドライブになっていた左側を選択すると、インストールが進みました。\nこの後、2回ほど再起動をします。2回目以降の再起動時には、起動ボリュームは1個だけに戻っていました。インストール後、何の問題もなくBig Sur 11.1が起動しました。\n特に気づく変更点はありません。ビルドは20C69になってました。\n","date":"2020-12-18T23:49:55+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/12135/","title":"Big Sur 11.1にアップデートする"},{"content":"本物のMacが無い状態からhackintoshを作るのは困難です。また、macOSを無料で使わせていただいているお礼としても、本物のMacを1台は持っていても良いと思います。その1台がM1 Macでも大丈夫でしょうか？ということを確認するため、M1 MacBook Airでhackintosh起動・インストール用USBメモリーを作ってみます。\nMacを買おう Hackintoshを作るためにmacOS上での作業が必要です。この記事は「M1 Macをhackintoshにする」と言う内容ではなく、「hackintoshを作る作業にM1 Macを使用する」と言う内容です。Hackintoshを作るなら、Macを買っておこうという内容の記事を、以前書きました。\nMacintoshを買おう\n今なら省電力な割に高性能なM1 MacBook Air/Proがおすすめです。M1 Mac miniも良いですね。今までのMac下位モデルはインテルのiGPUを使っていましたが、性能は良くありませんでした。M1のiGPUはインテルより数倍性能が良いです。反面、miniのようなデスクトップモデルでも拡張性はほぼ無いです。そこで、拡張性を補い、インテルmacOS環境を手に入れるために、自作macOSマシンを作るのも良いと思います。でもM1マックでhackintoshは作れるのでしょうか。Rosetta 2があるので、ツール類も正しく動くとは思いますが、確認します。\nBig Surをダウンロードする 一番の懸念は、インテル版Big Surが正規のApp Storeから入手可能かどうかです。そこで、M1マシンからApp Storeに行き、Big Surをダウンロードしました。\n「入手」をクリックすると、「ソフトウェア・アップデート」が起動して、ダウンロードが始まります。12.18GBあるので、そこそこ時間がかかります。サイズは大きいので、インテルのコードも入っていそうです。\nダウンロードが終わると、アプリケーションフォルダにインストーラができています。\n/Applications/Install macOS Big Sur.app 「情報」を見るとUniversalアプリケーションになっているようで安心しました。インテル環境でも大丈夫なようです。\nmacOSインストール用USBメモリ 次に、「Macで起動できて、MacにmacOSをインストールできるUSBメモリ」を作ります。まずはUSBメモリをHFS+でフォーマットします。USBメモリを接続し、M1 Macで「ディスクユーティリティ」を起動します。まずは「表示」から「すべてのデバイスを表示」を選んでおきます。（以下の2枚のスクリーンショットは以前のmacOSで撮ったものなので、見た目が違います）\nこの次に、USBメモリのデバイス名（一番上の階層の名前）を選択し、「消去」ボタンを押します。そこで現れるパネルから、方式として「GUIDパーティションマップ」を選びます。フォーマットには「MacOS拡張（ジャーナリング）」を選びます。\nこれ以外の選択をすると、後の作業でエラーが出たり、起動ドライブにならなかったりします。名前はなんでも良いです。ここではUSBにしておきました。次に、ターミナルを開いて、\n/Applications/Install macOS Big Sur.app/Contents/Resources に移動して、インストーラの中に移動して、createinstallmediaコマンドを使います。\n% sudo ./createinstallmedia --volume /Volumes/USB/ しばらく時間がかかり、無事、macOSインストール用USBメモリが完成しました。これで本物のMacを起動すれば、macOSがインストールできるはずです。M1 Macが文鎮化する事案が話題になってますが、このUSBメモリーさえ持っていれば安心です。\ndiskutil listコマンドで、USBメモリの場所を調べて、diskutil mountコマンドでESPをマウントしておきます。以下はESPがdisk4s1の場合の例です。この結果、/Volumes/EFIの場所にマウントされるはずです。\n% diskutil list % sudo diskutil mount disk4s1 ターゲットマシンを決める 今回は、Z390 + 9900K + RX580の構成へのインストールUSBを目指します。これに必要なkextは以下です。\nAppleALC.kext IntelMausiEthernet.kext Lilu.kext VirtualSMC.kext WhateverGreen.kext また、必要とされるSSDTは、こちらの表を見るとわかります。このマシン（Coffee Lake）に必要なSSDTは、\nSSDT-PLG SSDT-EC-USBX SSDT-AWAC SSDT-PMC です。リンク先から、それぞれのコンパイル済みamlファイルを入手できます。\nこの構成なら、システムモデルはiMac19,1が良いと思います。マシン用のシリアル番号やUUIDなどを決めておきます。今回は、すでに動いているマシンの番号をそのまま利用します。AppleIDの関係で、シリアル番号はできる限り変更しない方が良いです。新しいマシンにインストールする場合は、正しいフォーマットのシリアル番号を新たに作ります。OpenCoreをダウンロードすると、その中のUtilitiesの中にmacserialというコマンドがありますので、これで生成します。–modelオプションでモデルを指定すればそれに合うシリアル番号とボードシリアル番号を生成してくれます。macserialもM1で動きました。\n% ./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でも起動しました。\nOC Gen-XでESPを作る\nSystem TypeとしてCoffee Lakeを選び、上でリストアップしたkextを選びます。またSystem ModelをiMac19,1にして、決めておいたシリアル番号などを入力します。最後に「Generate EFI」ボタンを押すと、デスクトップにEFIフォルダができています。これをUSBメモリのEFIの中にドラッグ\u0026amp;ドロップでコピーします。\nESPを手直しする OC Gen Xツールは大体のことはしてくれるのですが、足りない部分を補います。まずはSSDTが入っていません。先ほどダウンロードしたamlファイルをACPIフォルダの中に入れます。また、config.plistの中に、kextやamlファイルの記載がありません。そこで、ProperTreeの、OC Clean Snapshot機能を使い、ACPI, Drivers, Kexts, Toolsの内容をconfig.plistに反映させます。ProperTreeもM1版Big Surで問題なく動きました。\n自作マシンで起動する これで100% M1で作ったhackintoshインストール用USBメモリーが出来上がりました。自作Z390マシンで起動を試みたところ、無事起動しました。macOSのインストールに使えそうです。\n文鎮化しても救える？ 先に述べましたが、M1 Macが文鎮化する事案が話題になっています。ファームウェアのアップデートに失敗すると起動しなくなるらしいです。その対策の一つが、ほかのMacからApple Configurator 2を起動して、ファームウェアをアップデートする方法らしいです。自作macOSマシンで、M1 MacBook Airの文鎮化を救えるのかどうか、試してみました。とは言っても、本当に文鎮化しているわけではないので、様子を見た程度です。\n自作マシン（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からダウンロードできます。\nするとMacBook Airが認識されていました。\n文鎮化しているわけではなく、元気に起動していますが、Z390マシンの方からは、これのファームウェアアップデートが可能なようです。「このアクションは取り消せません」とありますので、この先試していません。インテルベースの安定したHackintoshを持っていると、M1が文鎮化しても安心な気がします。\nまとめ M1Macでhackintoshが作れることを確認しました。このほか、Kext Updater.appやPlistEDPlus.appなどのツールも使えました。モバイルでは省電力なM1 MacBookを使い、デスクトップは拡張性のある装備満載な自作マシンを使うのが良いのではと思いました。\n","date":"2020-12-13T18:17:14+09:00","image":"/uploads/2020/12/chip__fffqz3ljssi2_medium_2x.jpg","permalink":"/posts/12065/","title":"M1 MacでHackintoshを作る"},{"content":"普段使いのノートとして古いMacBook無印を使っていたところへ、M1 MacBook Airがやってきました。重いけど速くて使いやすくて気に入りました。使ってみて気づいたところを書き連ねます。\nM1 Mac M1搭載MacはMac mini, MacBook Air, MacBook Proと3機種出ました。ハードウエア更新がいつも後回しな印象のあるMac miniが、新CPU搭載ラインナップに加わっているのは嬉しかったです。ただ、こんなにスカスカなのに、一切拡張できないのは残念です。メモリーソケットとM.2ソケットをつけて、2.5インチSATAドライブを2台は搭載可能な感じです。\n(出典：egpu.io)\nそれで注目なのはAirだと思いました。3機種とも同じCPU/GPUで、メモリとSSDの構成も同じです。一切拡張できない点も同じです。ならばM1の小型・省電力という特徴を生かした軽くてファンレスのAirが面白いと考えました。\nキーボードが良い Late 2019 MacBook Proからすでに改良されている点で、今更報告するほどのことではないかと思いますが・・・キーボードが良くなってました。MacBook無印のキーボードは、評判の悪いバタフライ型でした。薄いけど、沈み込みが少なく、ペチペチと安っぽい打鍵音がします。打ちにくさは慣れれば克服できるのですが、打鍵音がうるさいので、周囲に人が居る会議や公共の場で使いにくかったです。薄さを追求したMacBook無印には薄いバタフライ型が必要だったのかもしれないですが、厚いMacBook Proにも使われてました。評判が悪い上に、動作不良になることも多くて、2019年11月からのMacBookシリーズでは、元のシザー型のキーに戻りました。薄いキーを諦めた結果、MacBook無印は終了になってしまいました。\nM1 MacBook Airも、改良されたキーを搭載しています。デスクトップ用のApple Magic Keyboardと同じキーになっているそうで、慣れ親しんだいつもの打鍵感覚を得られます。MacBook無印と比べると打鍵音がほとんどしないのがとてもありがたいです。ファンレスで動くM1チップならば、MacBook無印の筐体で薄型軽量なモデルを作って欲しかったと最初は考えていました。実際、無印に比べてAirはずっしりと重いのですが、このキーボードのためなら我慢しても良いと思えました。それくらいキーボードが良いです。\nTouch IDが便利 これも目新しいことではないですが、Touch IDが便利でした。Windowsノートには指紋デバイスが、はるか昔から搭載されてました。MacBookシリーズにも2016年のTouch Barから搭載されてます。なので単に疎かっただけなのですが、使ってみたら便利でした。Apple Watchで認証するには、装着していないと使えません。指紋ならいつでも対応できます。デスクトップ向けのMagic KeyboardにもTouch IDをつけてくれたら良いのにと思いました。\nCPUと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に比べたら高性能です。\nM1 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では、高性能コアも省電力コアもどちらもしっかり仕事をしている印象です。省電力コアが足を引っ張るような振る舞いは見られませんでした。\nこちらは10900Kの様子です。\nスコアは、以下のようです。GeekbenchのCPUマルチのスコアよりは差が開きました。でも、ローエンドMacに搭載された省電力CPUとしては、今までにない高性能です。\nM1 MacBook Air 自作 macOS Cinebench R23 7,063 16,230 SSDの速度をAmorphousDiskMarkで測定しました。時間がかかるのでこれも最初の項目だけのテストです。M1 MacBook Airも自作PCもどちらも250GBなので、SSDの性能は同じようなものだと思います。後述するように、M1は接続がApple Fabricです。スコアは以下のようでした。\nこちらはASUSマザーボード上のM.2ソケットに取り付けたWDの250GB SSDの速度です。M.2 SSDの方がWriteは遅かったですが、Readは同程度でした。接続方式の違いではなく、SSDの特性の違いと思われます。\niOSアプリが使える M1チップのMacではiOSアプリが使えます。App Storeで検索するときに、「iPhone および iPad App」を選ぶとiOSのアプリが出てきます。これを見ると、iOSのアプリのかなりがM1 macOSで動作するようです。キャッシュレス決済アプリを入れておけば、スマホを忘れても、MacBookさえ持っていればコンビニで買い物ができます。画面上部のカメラも起動できるので、店頭QRコード支払いも可能なようです。このほかiPhoneで使っていたタイマーアプリ、Wi-Fi接続家電のリモコン、電卓などをダウンロードして使えました。\n謎アーキテクチャの探索が楽しい 今回のMac新モデルで一番楽しい点は、Apple Siliconという新しいアーキテクチャを探索できるところです。謎なところをいくつか探ってみました。もし詳しい情報をご存知の方がいらしたら、教えていただければと思います。まずは、Z490マシンでmacOSのCPU名を調べるコマンドを打ち込むと、\n% sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i9-10900K CPU @ 3.70GHz のように、詳しい名前やクロック数が表示されていました。M1 MacBook Airでこのコマンドを打つと、こんな表示になります。\n% sysctl -n machdep.cpu.brand_string Apple processor そっけなくて、詳細な仕様を謎のままにしておきたいという意図を感じます。\nunameコマンドでは、OSの名前を表示できます。インテル版のBig Surで実行すると以下のような表示が出ます。\n% 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でこのコマンドを打つと、以下のように表示されました。\n% 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に非常に近い仕様なのではと想像できます。\nZ490マザーボードのM.2ソケットに取り付けたSSDをディスクユーティリティで見ると以下のようでした。名前の説明に「PCI-Express内蔵物理ディスク」となっていて、PCI-Express接続になってます。\nM.2ソケットにはPCIeの配線がつながっていて、SSDはそれに接続しているので当然の表示です。一方、M1 MacBook AirのSSDを、同様にディスクユーティリティで調べてみます。すると、名前の説明が「Apple Fabric内蔵物理ディスク」になり、接続先がApple Fabricになってます。このSSDはPCI-Expressとは違った接続のようです。\n「システム環境」のSSDの項目にもApple Fabricの記述があります。Appleのサイトの図によると、FabricとはCPU, GPU, メモリーなどが接続されている内部バスのようなものらしいです。ここにSSDが接続されているようです。PCIeは無くなってしまったのでしょうか？\nHackintoolやIORegistryExplorerなどで調べると、一応はPCIeらしきものの一覧が出てきます。また、Display controllerとしてAMDのRadeon R7 370 / R9 270X/370XがPCIeの一覧に見えます。\nでもどのDevice Pathも0番になっていて、怪しい感じです。Systemのタブを見ると、CPUは2.50GHzのVirtualAppleとなってます。\n同様の情報は、MacCPUIDを動かしても得られました。やはりVirtualAppleという名前のCPUになってます。アーキテクチャはWestmereという太古のインテルCPUの設定です。おそらくは、Hackintoolに表示されている情報の、Intel Generationが???になっている部分を、Westmereと判断したのだと思います。\nHackintoolを動かす前にRosetta 2をインストールしてくださいというダイアログが出てました。なので、これらの情報は、Rosetta 2が提供しているフェイクな情報ではないかと思います。Intel版macOSアプリを動かすために、Apple SiliconアーキテクチャをIntelアーキテクチャに偽装しているとしたら、これはhackintoshに通じるテクニックだと思います。\nまとめ 新しいM1 MacBook Airを使ってみました。今まで使っていたMacBook無印と比べると重量が重くなりましたが、動作は軽く、キーボード、Touch ID、iOSアプリが使えて便利です。Appleオリジナルの新しいCPUになったので、今までと違う内部情報が得られました。\n","date":"2020-12-12T01:08:40+09:00","image":"/uploads/2020/12/macbook-air-S.jpg","permalink":"/posts/12003/","title":"M1 MacBook Airの良いところ"},{"content":"OpenCoreの0.6.4が公開されたので0.6.3からアップデートしました。config.plistの変更点は少ないですが、PlayChime項目がbool型からstring型に変更されてます。なので今までのconfig.plistではエラーが出るようです。\n0.6.4をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\n.efiファイルを差し替える 更新するためには、今までと同様に、X64の方のフォルダの中身を、現用のファイルと入れ替えます。前回と同様、入れ替えるべきファイルは以下でした。\nEFI/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の範疇では無いので、変更不要です。\nconfig.plistを更新する 現在のconfig.plistをconfig_063.plistと改名し、配布パッケージに入っているsample.plistをコピーして持ってきて、これをconfig.plistにしました。PlistEDPlusを使って、双方を開いて、比較しながら新しいconfig.plistを作りました。\n気付いた変更点は以下です。\nBooter/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に移行できました。\n","date":"2020-12-09T01:12:11+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/11982/","title":"OpenCore 0.6.3から0.6.4に更新"},{"content":"OpenCore用のミニマムな起動画面アイコンが公開されてます。作者の方がredditで紹介してました。これを使う前に、まずはOpenCanopyの設定をしておきます。\nOpenCoreの選択画面をグラフィカルにする\n次に、以下のGithubのサイトからダウンロードして、アイコンファイルをEFI/OC/Resources/Imageにコピーして、同じ名前のアイコンを差し替えます。また、config.plistのMisc -\u0026gt; Boot -\u0026gt; PickerAttributesを1にしておいてくださいとのことです。デフォルトは0ですが、1にするとカスタムアイコンを読む設定になります。\nGitHub - tekteq/opencanopy-minimal-theme: Minimal theme for OpenCanopy/OpenCore\nOpenCanopyのデフォルトアイコンは、実機と同じデザインなので、できる限り本物のMacを再現したいという目的には合ってます。以下がOpenCanopyのアイコンで、\n以下が実機Macでのボリューム選択画面の表示です。HDDの反射具合や支柱の太さが微妙に違いますが、ほぼ同じです。\nリアリティを志向したオリジナルアイコンとはかなり違って、tekteqさんのアイコンはおしゃれな感じです。さらに、OpenCoreの起動画面に引き続き、macOSが表示するブート画面にも同じ形とサイズのAppleアイコンが表示されるので、一連の流れが美しいです。どっちもありかなと思いました。\n","date":"2020-12-08T00:54:18+09:00","image":"/uploads/2020/12/m.png","permalink":"/posts/11968/","title":"OpenCore用のミニマムなテーマ"},{"content":"OpenCoreの設定を行うツールOC Gen-Xを使ってみました。Z390 + 9900Kで構成したマシンのために、このツールでEFIフォルダを作成しました。多少の手直しは必要ですが、そのまま起動するEFIフォルダが出来上がりました。\nOC Gen-X フォーラムで便利だったという話をお聞きして、試してみることにしました。夢日記にも紹介されてます。OpenCoreの設定を楽にするツールは、いくつかあるらしいですが、Dortaniaさんのガイドに、configuratorは使うな、手作業で設定せよ、と書いてあったので、避けてました。OC Gen-Xは、そのDortaniaさんのガイドに準拠したconfig.plistを生成するとの説明があるので、良いのかもしれないと思い、試してみることにしました。以下からダウンロードできます。\nhttps://github.com/Pavo-IM/OC-Gen-X\n現用マシンと同じ設定をする 今使っているASUS ROG MAXIMUS XI HERO + 9900Kの構成でインストールしたOpenCore 0.6.3 Big Surの組み合わせで使っている構成を目指して同じように設定を試みました。\nOC Gen Xを起動して、タブを選んで項目を選択していきます。最初はプロセッサーです。Z390 + 9900KなのでCoffee Lakeを選びます。\n次はKextです。使用中のKextを選びました。Lilu, VirtualSMC, SMCProcessor, SMCSuperIO, WhateverGreen, AppleALC, IntelMausiを選びます。Kext選択は、システムに依存しますし、知識も必要なので、初見で簡単に決められる作業ではないですね。さらに、自前で作ったUSBポートの設定kextは、当然ですがここでは選択できないです。\nFirmware Driversは、OpenRuntimeとHfsPlusを選びます。今はVBoxHfsを使っているのですが、HfsPlusの方が高速なはずです。他に、ブートの見た目をよくするためにOpenCanopyを使ってますが、これは選択肢に出てこないです。\n次はSMBIOSの設定です。System Model, Serial Number, MLB, UUIDに、今使っているそのままの値を入れました。System Model (機種ID) はiMac19,1です。\n起動オプションも、現用と同じ\n-v keepsyms=1 を書き込んでおきました。\nこれでGenerate EFIボタンを押すと、デスクトップにEFIフォルダが出来上がります。\n完成したEFIフォルダを確認 デスクトップに作られたEFIフォルダを確認します。config.plistが出来上がっていて、OpenCore関連のファイル類も入ってます。またKextsとDriversフォルダには設定したファイルが入っていました。下の図のように、OC Gen-X.appの中のContents/Resourcesの中に、OpenCoreとkext類の一式が入っています。これがそのままコピーされたのだと思います。OpenCore, kext, efiの最新版が出ていたらこちらを差し替えれば良いと思いました。\nただし、ACPIフォルダは空です。これも用意してくれれば良いのにと思いました。ここは手作業で入れておきます。Coffee Lakeに必要なACPI類は、\nSSDT-PMC.aml SSDT-PLUG.aml SSDT-EC-USBX.aml SSDT-AWAC.aml です。ACPIフォルダにamlファイルを追加したので、config.plistにも反映しておかねばなりません。ProperTreeの機能を使いました。元々はACPIの記述は何もありません。\nProperTreeのSnapshot機能を使うと、今追加した4個のamlファイルが追加されました。\n起動するかどうかを試す ここまで行ったステップは、\nOC Gen-Xを使ってEFIフォルダを作る ACPIファイル(aml)を追加する ProperTreeのsnap shot機能を使う の3ステップです。使用すべきkextファイルがわかっているとか、シリアル番号などは決めてあるとか、使用すべきamlファイルが手元にあるとか、ProperTreeを用意しておくなど、下拵えは必要ですが、それが準備できていれば、3分くらいでEFIフォルダが完成すると思います。\nでは、このEFIフォルダで起動するでしょうか？\nHFS+でフォーマットしたUSBメモリを用意して、これのEFIフォルダに書き込んで試しました。BIOSでUSBメモリを設定して起動したところ、なんと問題なく起動しました！\nUSBの15個対応のkextを入れてないのでUSBの一部が動かない その関係でBluetoothが動かない サウンドの設定をしていなかったので音はまだ出ない などの問題はあるものの、これは設定を行えば済むことです。とりあえず起動を目指すには、便利なツールだと思いました。\nconfig.plistを比較する 自動生成されたconfig.plistを、いろいろ調整して作っていた自家製config.plistと比較しました。以下の項目は、実質的に同じ内容でした。\nACPI Booter UEFI 以下の項目で自動生成版と自家製版config.plistが違いました。\nDeviceProperties 自動生成されたconfig.plistのDevicePropertiesにはデバイスの記述がありません。自家製config.plistには、サウンドとiGPUの設定がしてあります。音が出なかった原因はこの設定がなかったことです。iGPUは設定なしでも起動できましたが、構成によっては（特にiGPUを使う場合）起動しない可能性があります。DevicePropertiesに記述がないと動かないデバイス（特定のLANチップなど）があるとその機能は動かないことになります。\nKernel いろいろ工夫して加えていたkernelパッチ（光ディスクのスリープ対策とリムーバブルベイのホットプラグ対策）が自動作成版に無かったのは当然ですが、これらは起動には問題ない項目です。\nQuirksは、いくつか違ってました。自動作成版はDortaniaガイドのデフォルトに従っています。自家製設定と比較すると、ガイドの一部を変更していた項目が違ってました。以下にそれを示します。でも、いずれも起動には問題なかったです。\nAppleCpuPmCfgLock: 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にしてます。\nSecurityカテゴリーでは、ExposeSensitiveDataを7に、ScanPolicyを19858179にしてましたが、これは大した違いではないです。自動生成版では、SecureBootModelがdisabledになっていますが、0.6.3からはSecureBootModelはdefaultで良いようです。でもどちらでも起動はします。\nNVRAM 自動生成では、prev-lang:kbdがデフォルトのロシア語になってます。自家製版では、これを英語（16進数で656E2D55533A30）にしてます。\nPlatformInfo 自動生成版ではmemoryに関する記述が増えています。ただ、システムの値を自動的に使う設定にもなっているので、ここは無駄なところかと思いました。それ以外は、手作業で設定していたconfig.plistと同じでした。\nまとめ OpenCoreのEFIフォルダ内容を作成するツール、OC Gen-Xを使ってみました。ACPIのファイルを設定する機能が無いこと、config.plistの設定でできれば直したいと思う点も多少はあるものの、起動するEFIフォルダーを短時間で作ることができました。初めて挑戦する環境でhackintoshするときに、とても役立つと思いました。OpenCoreにたくさんあってややこしいQuirksの設定をとりあえず無難にこなしてくれるだけでも助かります。\n","date":"2020-12-07T00:14:37+09:00","image":"/uploads/2020/11/68747470733a2f2f692e696d6775722e636f6d2f4751336c38646e2e706e67.png","permalink":"/posts/11622/","title":"OC Gen-XでESPを作る"},{"content":"いろいろ頑張ってきたHP EliteDesk 800 G2 DM (Core i5-6500T)ですが、Windowsをインストールしました。Hackintoshとしては完敗です。macOSからはWindowsを画面共有で使います。sshでUbuntuも使います。電源が切れてても使えるようにWake On LANの設定もしました。\nMicrosoft Remote Desktop 最近はWindowsが絶対必要という場面が少なくなりましたが、世の中がWindows前提なので、たまにWindowsを使わざるを得ない時があります。Hackintoshなら、マルチブートにしておけば、同じマシンでWindowsが使えますが、切り替えが面倒です。VMware Fusion Player 12 が個人利用で無償になって、かなり快適でした。なので仮想環境でWindowsを使う手もあります。マルチブートに比べて性能は出ませんが、macOSとの切り替えが簡単です。今回は第3の選択肢として、Windowsマシンを別に用意して、これにリモートデスクトップする方法を試します。\nそこで、macOSをインストールしようとして暗黒画面問題で挫折したHP EliteDesk 800 G2 DM\nHPの小型デスクトップEliteDesk (4: 暗黒画面問題で頓挫)\nにWindowsを入れて、ディスプレイ無しのリモートデスクトップサーバにします。macOSは諦めて、ただのWindowsマシンに戻すのですから、BootmacOSの路線からしたらダメダメな状況です。すみません。でもWindowsマシンが用意できれば、これにmacOS用のMicrosoft Remote Desktopで接続することでWindowsが使えます。Remote Desktopクライアントプログラムは、無償で配布されていて、使いやすいです。応答も素早いので、仮想マシンより快適な気がしました。\nRemote Desktopを起動すると、接続先を選べるようになります。接続先のマシンを何個も登録できるインタフェースでした。職場の何台ものWindowsマシンを管理するような状況を想定しているのかもしれません。\nHP EliteDesk 800 G2 DMは小型なのでiGPUで動きます。M1が話題になって貧弱さが際立っているインテルiGPUなので、このままディスプレイには接続しないで、ヘッドレスのリモートデスクトップサーバとして使おうと考えてます。小さなマシンなので、邪魔にならないです。\nWindowsをインストール まずはHP EliteDesk 800 G2 DMにWindowsをクリーンインストールします。macOSマシンにされていたところが、本来の姿に戻ることになります。でも元からあったWindowsは綺麗に全消去されているので、起動できるUSBメモリインストーラを作ります。そこで、Z390 + 9900K + OpenCore 0.6.3 + Big Sur の構成のマシン（機種IDはiMac19,1）で以下の作業をしました。Windowsインストール用のISOイメージファイルがダウンロードできるMicrosoftのサイトに行きました。\nWindows 10 のディスク イメージ (ISO ファイル) のダウンロード\nとりあえずダウンロードしてみたところ、Windowsのイメージファイルは6GBほどでした。12GB超えてるBig Surに比べて優しいですね。\nこれから頑張れば、インストール用USBメモリをmacOS環境でも作れないことはないです。でも結構難しい作業で、適当に試しても失敗ばかりでした。USBメモリをFAT32でフォーマットするのですが、コピーしなければならないファイルの一つが、FAT32の限界の2GBを超えているところがネックです。それを乗り越える技が複雑過ぎました。\n結局、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メモリに書き込んでくれます。とても楽でした。\nBIOSもアップデート ついでにBIOSもアップデートしておきました。HP EliteDesk 800 G2 DMのBIOS画面に、ネットワークからダウンロードして更新するメニューがあります。クリックするだけで最新版 (2020/11/6版の02.51 Rev.A) になりました。以下はHPのサイトですが、ここからダウンロードする必要はありませんでした。\nHP EliteDesk 800 35W G2 Mini PC ソフトウェア及びドライバーのダウンロード | HP\u0026hellip;\nデジタルライセンス HP EliteDesk 800 G2 DMの筐体のどこを見てもWindowsのプロダクトキーが書いてありません。Windowsを買わないとダメなのか、全消去するんじゃなかったと少し後悔しました。ところが今やデジタルライセンスの時代だったんですね。このマシンの情報がすでにどこかのサーバに登録されているらしく、Windowsインストール作業最初のプロダクトキー入力をスキップしても、自動的に認証されてました。SSDもメモリもCPUも交換してしまっているので、BIOSのシリアル番号のようなもので個体識別しているようです。メーカー製PCにはWindows代が含まれているので当然の結果かもしれませんが、予想外でありがたかったです。ハードにOS代が含まれていることは、よく考えたらmacOSも同じです。\nHP EliteDesk 800 G2 DMの中古価格は、Core i3モデルが1.5万円くらい、i5モデルでも2万円くらいです。一方で、マルチブートしたり、仮想環境を使ってWindows 10 Proを起動する場合には、パーツに紐付けたDSP版でも1.7万円くらい、通常版なら2万円以上のライセンス代が必要になります。そう考えると、デジタルライセンスが付いた上にCPUもメモリも手に入る中古のハードを買うのは、お得な手段なのではと思いました。\nリモートデスクトップサーバを有効化 インストールしたWindows 10で最初に行った作業は、リモートデスクトップサーバをonにすることです。これでmacOSから作業ができます。設定する場所が「設定」だったり「コントロールパネル」だったり混乱します。\nWSLを入れる 次に行った作業は、WSL (Windows Subsystem for Linux) を有効にすることです。\nそして、Microsoft StoreからUbuntu 20.04 LTSをダウンロードしてインストールしました。WSLがあってLinuxが使えることは、macOSユーザから見てちょっと羨ましいです。\nとはいえ、WindowsとLinuxではディレクトリ構成が違います。ディレクトリ階層の区切りも¥と／で違います。ファイルやフォルダをUbuntuのウィンドウにドラッグ\u0026amp;ドロップしても、Linuxが理解できるディレクトリ文字列になりません。macOSファインダとターミナルのような円滑な操作性ではなく、ぎくしゃくしている印象です。Windows上の仮想環境でLinuxを動かしているので仕方ないですが、もう少し統合してほしいと思いました。ネイティブに動いているmacOSのUNIX環境が、シームレスで使いやすいことを改めて実感しました。\nDropboxを入れる One Driveの方がWindowsとの相性が良いのでしょうが、Dropboxを使ってます。One Driveは、昔試したことがありますが、macOSとの相性が悪かったです。One Driveでは、Windowsの規則で、ファイル名に使えない文字があります。例えば、CON, PRN, AUXという名前はファイル名・フォルダ名に使えません。また、” * : \u0026lt; \u0026gt; ? / \\ |などの文字も使えません。Dropboxにはそのような制約はありません。自分で作るファイルなら命名に気をつければ良いのですが、例えばアプリケーションのパッケージの中に、たまたまこのような名前のファイル・フォルダがあると厄介です。これらがOne Driveにコピーする際に除外され、アプリケーションの内容が変わってしまいます。実際にそのような事例が発生しました。現在のOne Driveも同様な命名規則を引き継いでいるのかどうかわかりませんが、こういう理由で使用を避けてました。\nSSHサーバを入れる 昔のWindowsでsshを使うのは面倒だった記憶がありました。でもWindows 10ではsshクライアントが標準で入っているようです。PowerShellから使えました。でもsshサーバ (sshd) はOpenSSHを自力でインストールする必要があります。\n一方で、WSLのUbuntuには、あって当然なのですが、sshのクライアントとサーバが入っています。Ubuntuのsshサーバは、以下のコマンドで起動することができます。\nsudo service ssh start ということで、sshdを使うには、\nWindowsのsshdを使う Linux (WSL-Ubuntu)のsshdを使う の2種類の選択肢があります。ここはすでにインストール済みのLinuxにしました。Windowsルートは手順が大変そうでしたが、Linuxルートにも罠がありました。普通のLinuxなら\nsudo systemctl enable sshd.service というような類のコマンドで、起動時に自動的にsshdが起動するように設定できました。でもWSLでは技術的な事情でsystemctlコマンドが動かないようです。なので、コンピュータを起動するたびごとに、\nsudo service ssh start のコマンドを発行する必要があります。これは自動化したいところです。ちょっと調べたところ、PowerShellからWSLのコマンドを発行する命令があるらしいです。その名もwslです。これを使って、\n@echo off wsl -u root -- service ssh start というbatファイルを作ると、Windows環境から、–の後に書いたLinuxの命令がroot権限で出せるようです。batファイルなんて書くのはものすごく久々でした。\nWindowsのbatファイルなので、これはWindowsで実行できます。なのでこのbatファイルを、Windowsが起動した直後に実行するよう設定すれば良いです。でもこの方法もかなり試行錯誤しました。結局は、コントロールパネル–\u0026gt;システムとセキュリティ–\u0026gt;管理ツール–\u0026gt;タスクスケジューラに行きついて、ここで「スタートアップ時（システム起動時）に」「ログインしているかどうかにかかわらず実行する」設定で、batファイルを登録すれば良いようでした。\nsshdが起動するように設定するには、Linuxならコマンドひとつ、macOSだと「システム環境設定」「共有」で「リモートログイン」をクリックするだけです。Windows (WSL) だと深い階層の幾つもの設定が必要で大変でした。でもこの作業の結果、電源を入れるだけでLinuxのsshdが応答してくれる状態になるので、別のマシンからssh接続すればUbuntuのシェル環境が使えます。Windows環境が用意されただけでなく、いつでも試せるLinux環境も出来上がったので、ちょっと嬉しいです。\nWake On LANを設定 次にWake On LAN (WOL)を設定しました。これに関しては、Windowsは素晴らしい！です。WOLは、ネットワークの他のマシンから、スリープ中や電源切れているコンピュータを目覚めさせる機能です。そのために、相手のMACアドレスを指定して、マジックパケットという謎のパケットを送りつけます。マジックパケットを送るアプリケーションは多数ありますが、Pythonで書けばこんなプログラムで可能なようです。\n#!/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(\u0026#39;\\xFF\u0026#39;*6+\u0026#39;\\x99\\xAA\\xBB\\xCC\\xDD\\xEE\u0026#39;*16, (\u0026#39;192.168.xxx.255\u0026#39;, 7)) 最後の行に、目覚めさせたいコンピュータのNICの情報を書きます。\\x99\\xAA\\xBB\\xCC\\xDD\\xEEの部分がMACアドレスで、192.168.xxx.255がIPアドレスです。IPアドレスの最後が255なのは、ブロードキャストするためです。ここを機器のアドレス通りにしても、一応は起動するようです。でも今回のマシンで試したところ、offした後しばらくは起動しますが、時間が経つと失敗します。シャットダウンしてからしばらくすると、スリープモードが深まるのか、自分のIPアドレスがわからなくなるようです。255にしておけば、必ず成功します。\nmacOSでは、「システム環境設定」「省エネルギー」の「ネットワークアクセスによるスリープ解除」で、Wake On LANを有効にできます。以下は、「省エネルギー」のデフォルト設定ですが、デフォルトで有効になってます。このほかにもBIOSでWOLを有効にしておく設定が必要です。\nWindowsの場合は、デバイスマネージャの中のいくつかの設定でWOLを有効にします。ここではWake On Magic Packetが有効であることを確認してますが、このほか「電源の管理」タブも関係があります。一般的にmacOSよりも設定箇所が多い傾向にあると感じますが、デフォルトのままで大丈夫でした。ちなみにネットワークアダプターのドライバを、上記のHPのサイトからダウンロードしないと、WOL関係の設定が現れなかったです。Windowsの標準ドライバーでは、最新に更新してもWOLの設定がありませんでした。このほかBIOSの設定も確認する必要があります。\n幾つか試行錯誤しつつ設定したところ、macOS（前述のZ390マシン）でも、このWindowsでも、どちらもマジックパケットを送ってスリープから目覚めさせることができました。\nmacOSでは、スリープ状態に対してのみ、WOLが効くようでした。電源を落としてしまうとWOLは効かなくなります。少し検索しただけなのですが、ネットにもやっぱりそう書いてありました。もし、電源も入れられるようなWOL設定の情報ありましたら、教えていただければとても助かります。\n一方、Windowsでは、なんと電源を切った状態でもWOLが効きます。電源の落ちたマシンにマジックパケットを送ると電源投入できました。これはちょっと素晴らしいです。\n訂正：hackintoshなら電源を切った状態からのWOLが効きます。以下をご覧ください。\nWake On LAN (WOL) を使ってmacOSの電源を入れる\n追記：Windows 10のWOL その後、起動ディスクをM.2 SSDに変更しようとして、Windows 10のクリーンインストールを再度行いました。そうしたら電源offでのWOLが効かなくなりました。結局は、再びWOLが動くようにできたのですが、そのポイントをメモしておきます。\nLANのドライバーは最新にします。Windowsに最初に入っている、または更新からダウンロードできるIntel LANドライバーにはWOLの設定項目がありません。HPのサイトからダウンロードするとWOLの設定があります。これがないとsleepからのWOLもできないです。 「高速スタートアップ」をoffにします。これがOnだとシャットダウンからのWOLができなかったです。 スリープ中やシャットダウン時に、LANコネクタのLEDが点灯していることが重要です。これが消灯している状態だと如何なるパケットも受け付けないようで、WOLもしません。 BIOSでシャットダウン時にS5に移行するよう設定すると、WOLしません。Off状態ではLANコネクタのLEDも点灯しません。デフォルトはS5ではないので、注意すべき点ではないですが。 WOLはいろいろとややこしいです。シャットダウンしないと、機能しているかどうかを確認できないので、結果がなかなかわからないこともあり、手間がかかります。そこを設定するところが達成感を得られて楽しいところです。\nまとめ 暗黒画面問題で頓挫したHP EliteDeskは、結局のところWindowsマシンとして復活しました。ディスプレイは接続せず、macOSからMicrosoft Remote Desktopで使用します。Windowsのデジタルライセンスが効いていたので無償でした。さらにWSL、SSHサーバ、Wake on LANなどを設定しました。このプライベートネットワークには、ルータのVPN機能を使ってL2TP over IPSecでインターネットから入れるようにしてあります。なので\n外出先からVPNで接続する Pythonプログラムでマジックパケットを送る 電源が切れているHP EliteDeskが起動する sshまたはRemote Desktopで接続する という手順で、世界中どこからでも、このWindowsマシン（Ubuntu付き）をmacOSから利用できるようになりました。今後は、電源が切れている自作Z390 macOSマシンも、外部から起動して使えるように考えたいです。\n","date":"2020-12-06T00:53:46+09:00","image":"/uploads/2020/03/hp800g2dm.jpg","permalink":"/posts/11724/","title":"HPの小型デスクトップEliteDesk (6: Windowsを入れる)"},{"content":"M1 Mac miniが予想以上に高性能なので話題になってます。価格も安いので、自作する意味は無くなったのでしょうか。自作機とコストパフォーマンスを比較しました。\nM1 Mac miniのスコア Geekbench Browserによると、M1 Mac miniのCPUスコアは\nSingle 1,700 Multi 7,500 くらいのようです。発売前の予想以上に性能が高いので評判になってます。特にシングルの性能が高いです。一方で内蔵GPU (iGPU) は、\nOpenCL 19,500 Metal 22,000 くらいのようです。どちらも同程度の値なので、以下ではOpenCLで比較します。\nM1相当の自作パーツ 最近のOpenCoreベースのhackintoshは、Geekbenchにスコアを上げるとAcidantheraというキーワードが入ります。そのキーワードで検索しました。現行CPUの中で、マルチで7,500が出るものを探すと、10700あたりになります。10700は概ね以下のスコアでした。\nSingle 1,200 Multi 8,500 M1と比較するとシングルで負けてマルチで勝ってます。マルチは9000超える結果も多数登録されてますが、シングルで負けているので、10700あたりがM1に相当する性能かと考えました。一つグレードを下げて、10600の結果を探すと、マルチが7000未満になるので、こちらは明らかにM1に劣ってしまいます。\n一方で、OpenCL, Metalで2万台のスコアを出す結果を探してみると、RX-560を搭載したマシンが、大体25,000程度のスコアでした。ということで、M1搭載Mac miniと同等の性能を出すマシンを自作するためには、CPUに10700を、GPUにRX-560を選択すれば良いことになります。\nmini最小構成で比較 M1 Mac miniの最小構成ではメモリが8GBで、SSDが256GBです。デスクトップマシンとしては少ないです。でも世間の評価を見ていると、メモリの効率が良くなったので8GBでも困らないという説もあります。SSDも少ないですが、クラウドストレージが一般的なのでこれでも実用性があるのかもしれないです。最小構成の価格は、税込で80,080円です。\nこれに対して、10700 + RX-560の構成で、いくらで自作できるのか調べてみました。kakaku.comの価格で計算してくれるサイトがありました。\nここで現行製品で見積もってみます。RX-560は既に販売されてなくて中古しかないようです。RX-570なら販売されてました。中古価格で見積もっては不公平だと思うので、RX-570に変更しました。こちらはGeekbenchで調べるとスコアが4万くらいなので、性能はM1 iGPUの倍になります。他の部品は、安めのものを選びました。その結果、\n【CPU】インテル Core i7 10700 ¥38,272 【CPUクーラー】サイズ 虎徹 MarkII SCKTT-2000 ¥3,938 【メモリ】Corsair CMK16GX4M2A2666C16 [DDR4 PC4-21300 8GB 1枚] ¥3,290 【マザーボード】ASRock H470 Phantom Gaming 4 ¥12,882 【ビデオカード】MSI Radeon RX 570 8GT OCV1 [PCIExp 8GB] ¥15,734 【SSD】ADATA XPG SX6000 Lite ASX6000LNP-256GT-C ¥3,980 【ケース】Thermaltake CA-1J5-00M6WN-01 ¥4,117 【電源】玄人志向 KRPW-BK650W/85+ ¥6,264 【Wi-Fi/Bluetooth】Fenvi T919 ¥5,100 【合計】¥ 93,677 となりました。Wi-Fi/Bluetoothカードは、上記の見積もりサイトには当然ながらありませんので、を追加しました。コストと性能をまとめると以下になります。\nM1 Mac mini 自作 macOS CPU M1 10700 GPU M1 RX-570 メモリ/SSD 8GB/256GB 8GB/256GB CPU シングル 1,700 1,200 CPU マルチ 7,500 8,500 GPU OpenCL 19,500 40,000 税込価格 80,080 93,677 改めてM1 Mac miniのお買い得度がわかります。miniはメモリもSSDも拡張できないという欠点があります。SSDは外付けするという手がありますが、メモリは増強できません。でも純正Macなので、hackintoshの苦労（たのしみ？）が不要という大きなメリットがあります。この構成ならばMac miniを買った方が良いですね。\nmini最大構成で比較 次に、Mac miniをオプション全部盛りの条件で比較します。とは言っても、メモリを16GBにしてSSDを2TBにできるだけです。SSDは個人的には1TBもあれば十分なのですが、動画編集などされる方は、これくらい必要なのかもしれません。価格は税込190,080円になります。\n自作する場合も計算しなおします。メモリを16GBにして、SSDを2TBすると、以下になります。\n【CPU】インテル Core i7 10700 ¥38,272 【CPUクーラー】サイズ 虎徹 MarkII SCKTT-2000 ¥3,938 【メモリ】Corsair CMK16GX4M2A2666C16 [DDR4 PC4-21300 8GB 2枚組] ¥6,573 【マザーボード】ASRock H470 Phantom Gaming 4 ¥12,882 【ビデオカード】MSI Radeon RX 570 8GT OCV1 [PCIExp 8GB] ¥15,734 【SSD】WESTERN DIGITAL WD Blue SN550 NVMe WDS200T2B0C ¥26,379 【ケース】Thermaltake CA-1J5-00M6WN-01 ¥4,117 【電源】玄人志向 KRPW-BK650W/85+ ¥6,264 【Wi-Fi/Bluetooth】Fenvi T919 ¥5,100 【合計】¥ 119,359 こちらも表にまとめると以下になります。\nM1 Mac mini 自作 macOS CPU M1 10700 GPU M1 RX-570 メモリ/SSD 16GB/2TB 16GB/2TB CPU シングル 1,700 1,200 CPU マルチ 7,500 8,500 GPU OpenCL 19,500 40,000 税込価格 190,080 119,359 AppleのBTOでメモリ/SSDを追加すると割高ですね。自作との差額は7万円強になります。SSDを1TBにすれば、差額は縮まって5.5万円くらいです。純正か自作かどちらを選ぶか微妙になってきます。将来のアップグレードの可能性があるという点で、自作を選ぶ選択肢もありかと思います。\nこだわりのパーツで自作 ここまで考えた自作構成は、M1のiGPUに合わせて、かなり控えめの構成です。こだわりのパーツで作ってみようと思ったら、この構成にはならないように思います。ある程度予算には配慮しつつも、こんな自作をしてみたいという構成を考えてみました。\n【CPU】インテル Core i9 10900K BOX ¥58,376 【CPUクーラー】サイズ 虎徹 MarkII SCKTT-2000 ¥3,938 【メモリ】Corsair CMK16GX4M2A2666C16 [DDR4 PC4-21300 8GB 2枚組] ¥6,573 【マザーボード】ASUS ROG STRIX Z490-F GAMING ¥25,278 【ビデオカード】MSI Radeon RX 5700 XT GAMING X [PCIExp 8GB] ¥41,000 【SSD】crucial P1 CT1000P1SSD8JP ¥11,248 【ケース】Thermaltake CA-1J5-00M6WN-01 ¥4,117 【電源】玄人志向 KRPW-BK650W/85+ ¥6,264 【Wi-Fi/Bluetooth】Fenvi T919 ¥5,100 【合計】¥ 161,894 SSDは1TBで十分と考えました。CPUは一般向けIntel CPU最強の10900Kです。グラフィックスも、macOS対応モデル中最強クラスの5700XTです。マザーボードも良いものにしたいと考えました。良いマザーボードは高い部品が使われていて、手に持った感じがずっしりしていて良いです。でも、こだわったわりには、先ほどのリストから4万円くらいしか価格上昇してないです。\nこの構成を、同等のメモリ/SSD構成のMac miniと比較すると以下のようになります。\nM1 Mac mini 自作 macOS CPU M1 10900K GPU M1 RX-5700XT メモリ/SSD 16GB/1TB 16GB/1TB CPU シングル 1,700 1,300 CPU マルチ 7,500 11,000 GPU OpenCL 19,500 69,200 税込価格 146,080 161,894 同じメモリ/SSD構成のMac miniと比べて、自作機は1.5万円くらい割高ですが、性能はとても良いです。この性能が必要かどうかは別として、自己満足できる数値だと思います。\nまとめ 新Mac miniと自作macOSマシンを、コストパフォーマンス比較してみました。miniはコスパが高いので、実用的な性能のマシンを安く作りたいという動機でhackintoshする意味は無くなったかもしれません。hackintoshする動機の一つに、「Mac miniとMac Proの中間のディスプレイ無しデスクトップマシンが欲しい」という理由がありました。今回登場したM1 Mac miniのおかげで、その希望を叶える純正選択肢ができたと思います。\nとはいえ、上位iMacに相当する性能には到達していません。インテルのiGPUに比べたらM1のiGPUは別格の性能ですが、RadeonシリーズのdGPUには劣ってます。またメモリ, SSD, PCIeなどの拡張性はありません。自作には、好きな部品を選んで、拡張や組み合わせを楽しむ余地が残っていると思います。自作PCの歴史を振り返ると、メーカ製品に比べてコスパが良いという理由で、Windowsマシンの自作が流行した時代がありました。今は、そういう動機の一般人は撤退して、楽しいから自作するという人（と、最近はゲーマーの人かな）だけが自作界隈に居る状態だと思います。hackintoshもそうなったのかもしれません。macOSがインテルプラットフォームから完全撤退するまでの間は、自作を楽しんでいきたいと考えてます。\n","date":"2020-12-04T21:56:45+09:00","image":"/uploads/2020/12/m2.jpg","permalink":"/posts/11887/","title":"M1 Mac miniと自作PCのコスパ勝負"},{"content":"無償で個人利用できるようになったVMware Fusion 12 Playerを使ってみました。無償ライセンスを入手するのが手間でしたが、インストールは簡単で素早く、機能も動作も満足のいくものでした。\n無償になったPlayer版 VirtualBoxを使う記事、\nHackintoshでVirtualBoxを使う\nのコメントで、VMware Fusion 12 Playerが無償になったことを教えていただきました。こちらの記事が詳しいです。\n個人なら無償 インテルMac用仮想環境アプリ「VMware Fusion Player 12」レビュー (\u0026hellip;\nVMware Fusion 12はBig Surに対応したバージョンらしいですが、そのスタンダード版に当たるPlayer用のライセンスキーが、今回、個人利用者に対して無償で配布されることになったそうです。ということで現状のmacOSで利用できるVMアプリケーションは以下のようになりました。\nParallels（有料） VMWare Fusion（個人利用は無料） VirtualBox（無料） VMwareの有料版も、かなり昔に使っていた記憶があります。有料なだけあって、Parallelsと同様に使いやすく性能が良かったです。それで早速、ASCIIの記事を参考に無償ライセンスキーと本体を入手しました。ASCIIの記事にあるように、入手場所は、webページの中のわかりにくい場所にあります。またユーザ登録が必要です。大昔に有料版を使っていた時に登録してあったのか（すっかり忘れてましたが）アカウントが残ってました。\nダウンロードして動かす 次にVMwareのサイトから本体をダウンロードします。インストールが終了するとこんなウィンドウが出ます。使用したマシンの構成はハードウェアがASUS Z390マザーボード + 9900Kで、ソフトウェアがOpenCore 0.6.3 + macOS Big Sur 11.0.1です。\nVMware Fusionを起動すると、ライセンスキーを聞かれるので、サイトで入手した番号を入力します。\nこのウィンドウにも、無償ライセンスキーを取得するリンクのボタンがあります。先にソフトウェア本体をダウンロードして、その後に、ライセンスキーを取得に行くのがわかりやすかったかもしれないです。ライセンスキーを入れると、無事、受け付けてくれました。\nこの後、起動用のイメージファイルを選択する画面になります。Windows 10のisoファイルがあったので、それを選択しました。すると、特に設定の必要もなく、稼働ボリュームのイメージファイルが作られて、インストールが始まり、Windowsが起動しました。10分ちょっとくらいで終わってしまった感じで、速かったです。Windowsをアップデートしたりなどして、多少使った後の稼働ボリュームのファイルは20GB程度でした。今後さらに使用を続けていくと、必要に応じてサイズが大きくなっていくのだと思います。\nまとめ VMware Fusion 12が無償で利用できるようになっていたことを知り、インストールしました。ゲストOSとしてWindows 10をインストールしたところ、キビキビと動いていて快適です。VirtualBoxと比べて、元々が有償ソフトウェアなためか、高速に動く気がしました。以前から無償で利用できたVirtualBoxにはお世話になりましたが、Fusionをしばらく使ってみようと思いました。\n","date":"2020-12-03T21:34:52+09:00","image":"/uploads/2020/11/vmwareicon.png","permalink":"/posts/11822/","title":"VMware Fusion Player 12を使う"},{"content":"HomePod miniを使ってみました。macOSからはAirPlayのスピーカーとして使えます。またHome.appからアラームの設定ができます。HomeKitのホームハブとして使えるそうですが、そちらは試せてません。\nHomePod mini Amazon EchoやGoogle Homeに比べて、Appleのスマートスピーカは高価なHomePod無印が1機種だけしかなく、普及に力を入れているという様子がありませんでした。でもHomePod miniが出て、競争力が付いたと思います。Echoは、安いのでいくつか使用してますが、結構便利です。でもAppleのエコシステムで生きているので、カレンダーやメッセージにアクセスできなくて物足りなく思ってました。今回、手頃な価格でコンパクトなHomePod miniが出たので、ようやく試せました。\n設定 箱から出して、電源に接続して、iPhoneを近づけると、iPhoneに設定画面が現れます。このあとは数個の選択肢を設定していくだけです。\nこの辺りは、iOSを所有している会社の製品だけあって、手間要らずです。自社のアプリをダウンロードさせたり、起動させたりする手間が不要なだけでも有利です。Wi-Fiなどの設定も、Amazon Echoに比べたら格段に容易でした。てっぺんのLEDの点滅をiPhoneで撮影して、デバイスをペアリングする手法もスマートです。その結果、Wi-FiもBluetoothもApple IDも全てが、気づかないうちに設定終了してました。逆に言うと、iPhoneが無いと使い始めることもできないデバイスです。\nこのあと、Z390 + 9900KにOpenCore 0.6.3 + Big Sur 11.0.1の構成のmacOSマシンから何ができるのか試しました。無線ユニットは、純正Macと同じBCM94360CDです。\nHackintoshのパーツ選び 【その4：無線編】\nHomePod miniとの通信でBluetoothなども使っているのかなと思ったのですが、以下で紹介するAirPlayもHome.appも有線LANだけで動きました。BluetoothとWi-Fiをoffにしても同様に動きます。\nAirPlayスピーカー まずはサウンドです。デフォルトの選択肢からオフィスを選んであったのですが、その名前でAirPlayデバイスとして見えてます。これを選択するだけで、すぐに音が出ました。Bluetoothのペアリングは、簡単そうで失敗することも多いのですが、こちらは手間要らず機能します。キーボードの音量キーも操作可能でした。HDMIやUSBオーディオだとキーボードの音量キーが効かないことも多いので、これは助かります。\nすでに色々な人が音質が良いとレビューしてますが、評判通り、音質はそこそこ良いです。ステレオスピーカーと比較すると、HomePod miniはモノラルなので、広がりに欠けるのは仕方ないです。ちなみに、2台のHomePod miniを用意すると、iPhoneからはステレオになります。でもmacOSのAirPlayではモノラルのスピーカーが2個に増えただけになってしまうらしいです。macOSで使う限り、1台だけ買えば良いようです。\nしばらく使ってみると、いくつか不具合に気づきました。まず、YouTubeで動画を止めたり動かしたりしていると、HomePod miniの設定音量とずれてしまうことがありました。また、macOS警告音の「サウンドエフェクトの再生装置」として、システム環境設定の選択肢にHomePod miniが現れることもあれば、現れないこともあります。バグのような感じなので、そのうち直してくれるかもしれません。\nもう一点、気になったところは、遅延が大きい場合があることです。サウンドエフェクトの再生装置として現れる場合、通知音のサンプルをクリックしてから1~2秒くらい遅れて音が出ます。MusicやQuickTime Playerなどで音楽の再生・停止ボタンを押すと、2秒くらいしてから反応します。動画再生・停止でも遅延します。でも映像も遅延するので、音との同期がズレる現象はないのです。いずれの場合も、マザーボードのサウンドチップでは瞬時に応答するので、AirPlayが原因だと思われます。何処かのバッファメモリが一杯、または空っぽになるまで、操作結果が反映されない感じです。遠隔会議ではこの遅延のために対話が成り立ちません。いろいろ謎の遅延ですが、これもそのうち直してくれるのかもしれないです。\nホーム.app ホーム.appを開いてみました。オフィスという場所に、HomePod miniが見えてました。名前は変更できます。いくつかの設定も変更できます。でもできることは、アラームを設定する程度の事でした。macOSから操作するよりも、Siriに音声でお願いしたほうが楽そうです。\n純正環境との比較 AirPlayの遅延などに関しては、hackintosh環境なので、不具合が起こっても当然だったのかもしれません。それで純正Mac, iPhone環境ではどうなのかを確認しました。\n純正Macとの比較 Big Sur 11.0.1が動いている本物のMacBookからこのHomePod miniに接続して確認しました。警告音のデバイスに現れない、2秒くらい遅延するという状況は、同様に発生しました。hackintoshの問題ではないようです。\niPhoneとの比較 iPhoneから接続すると、Musicアプリでも、一般のアプリ（例えばSafariで見るYoutubeサイトの動画）でも、遅延はありませんでした。\nAirPlay 2.0 先の説明で、macOSのAirPlayではHomePodはステレオにならないと書きました。正確には、macOSでも、Music.appからだけはステレオになるそうです。\n調べたところ、初代HomePodが発表された2017年に同時に、AirPlay 2.0が発表されて、そこで複数スピーカーの同期ストリーミングがサポートされたのだそうです。これにより2台のHomePodでのステレオ再生がサポートされたのだと思われます。この時に、遅延の問題も改善されたのでは無いかと思いました。それで、iOSは全面的にAirPlay 2.0に対応しているので、遅延が発生しないけど、macOSではMusic.appだけが2.0に対応しているので、Music.appを使う時だけは、ステレオにもなるし、遅延も発生しないということかと思いました。\n実はmacOSのMusic.appでも、設定によっては2秒の遅延が発生します。純正Macでも同様です。Music.appのAirPlayアイコンから、HomePod miniを選択すると、遅延は発生しません。「オフィス」というのがHomePod miniです。\nでもここで「コンピュータ」を選んで、macOSの「システム環境設定」「サウンド」からAirPlayデバイスを選ぶと遅延が発生します。前者は、\nMusic.app ---\u0026gt; ( AirPlay 2.0 ) ---\u0026gt; HomePod mini という接続になっていて、ステレオになって遅延も発生しないけど、後者は、\nMusic.app ---\u0026gt; macOS ---\u0026gt; ( AirPlay ) ---\u0026gt; HomePod mini というようにmacOSを経由した設定で、この場合、古いAirPlay無印が使用されて、その結果遅延が発生するということかと推測できます。macOSのMusic.appは自前でAirPlay 2.0を実装しているのか、それとも2.0を提供するmacOSの未公開APIがあってそれを使用しているのかと思われます。\nまとめ HomePod miniが自作マシンのmacOSから使えることを確認しました。AirPlay接続のスピーカーとして使えて、さらにホーム.appにはデバイスとして現れます。ただ遅延が大きいので、コンピュータ用スピーカーには向いてませんでした。常設のSiriデバイスとして使っていきます。\n","date":"2020-11-29T00:19:43+09:00","image":"/uploads/2020/11/white.jpg","permalink":"/posts/11745/","title":"HomePod miniを使う"},{"content":"OpenCore 0.6.3のSample.plistを真似て作ったconfig.plistでは、ブート時のpicker選択画面で、macOSのUSBインストーラやWindowsドライブが現れませんでした。これを治しました。またpicker画面で使える便利な機能も設定しました。\nデフォルト設定のpicker OpenCoreが起動する際に、箇条書きやアイコンで現れる選択肢のことをpickerというのだそうです。Cloverの時は起動ボリュームが現れましたが、OpenCoreではツールのアイコンも一緒に現れるので、pickerと呼ぶのが適切なのかと思いました。\n最近、このpicker画面にWindowsが入ったSSDが現れなくなっているのに気づきました。でもWindowsの使用頻度がほとんど皆無なので放置してました。その後、Big Surをクリーンインストールしようとしたときに、USBメモリーに入れたBig Surインストーラもpicker画面に現れませんでした。それで対応することにしました。OpenCoreのデフォルト設定では、WindowsもUSBメモリもpickerとして現れないようです。実際の例で示します。以下は、\nmacOSの入った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が見えてます。\nScanPolicyを設定する pickerを変更する方法の一つが、config.plistのMisc –\u0026gt; Security –\u0026gt; ScanPolicyという整数値を変更する方法です。これは起動選択のボリュームをスキャンする際のセキュリティ方針を決める項目のようです。得体の知れないボリュームから起動することは、セキュリティとして良く無いので、起動対象ボリュームの種類を決めておきましょうという項目のようです。\nScanPolicy = 0 ScanPolicyには、どのファイルシステムとどのデバイスを対象とするかをビットで設定します。詳細はOpenCoreのマニュアルに書いてあります。\n• 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アイコン）が追加されました。\n左端に現れているオレンジ色のEFIというpickerは、USBメモリのESPです。OpenCoreが入ってます。これを選択すると、「すでにOpenCoreで起動している」というような内容のメッセージが出るだけです。Cloverの入ったESPが他のドライブにあると、それも現れます。ESPの内容がCloverの場合はCloverに切り替わります。起動できるESPがある場合に、それが現れてしまうのは、ちょっと煩雑な感じがします。でも、実際のMacでも、オプションキーで起動すると、同様に起動可能なESPがpicker画面に出現します。実機と同じ仕様と思えば納得できます。\nScanPolicy = 19859203 ScanPolicy = 0で全く困らないのですし、そう設定するように指示するガイドページもあります。実際OC Gen-Xが自動生成するconfig.plistも0に設定してます。ただ、せっかくセキュリティの機能が用意されているのに、無視するのももったいない気がします。正しく必要なものだけ設定したいと考えました。\nScanPolicyのデフォルト値は17760515です。ScanPolicyの設定そのものをconfig.plistから削除するとこのデフォルト値になります。Sample.plistでもこの値が設定されています。このデフォルト値では、\nファイルシステムはAPFSのみ デバイスはSATA, SAS, NVMe, SCSI を対象とする設定です。APFSのみなので、Windowsはもちろん、HFS+だったBig SurインストーラUSBも現れないわけです。さらには、デバイスでは、USB, DVD, FireWire, SDカード, PCIバスが除外されています。Big SurインストーラUSBはデバイスとしても除外されていました。そこで、このデフォルト値に追加して、\nファイルシステムにHFS+とEFI System Partition (ESP) を追加する デバイスにUSBを追加する ような設定にしました。それが10進数で19859203になります。ファイルシステムの選択肢にNTFSのビットがあったので、Windowsならそれだろうと考えたのですが、違ってました。ブートローダーがESPにある関係か、NTFSビットを立ててもWindowsのpickerは現れませんでした。ESPビットを設定する必要があるようです。ScanPolicyを19859203に設定すると、（上の写真と同じですが）以下のようになりました。\nビットの計算をする 皆さんはビットを立てたり、外したりするのにどうやって計算されてます？今回は手軽で便利なmacOS標準搭載の「計算機」を使いました。「計算機」はメニューの「表示」「プログラマ」を選ぶと16進数、8進数などを扱えます。入力や結果はコピペできるので便利です。\n今回の計算は以下のようにして行いました。まずは、ScanPolicyのデフォルト値の、17760515をコピーします。計算機を10進数に切り替えて、ペーストします。その後、16進数に切り替えると、0x010F0103であることがわかります。ビットがわかりやすいです。\nここで、スキャン対象のファイルシステムにHFS+とESPを追加して、対象デバイスにUSBを追加します。それぞれのビットは、OpenCoreのマニュアルによると、以下です。\nHFS+ : 0x200 ESP : 0x400 USB : 0x200000 なので、合計で0x200600のビットを立てれば良いわけです。そこで「計算機」で「OR」を押した後、0x200600を入力して、イコールを押します。出てきた結果は16進数で0x12F0703になります。10進数に切り替えれば、設定すべき10進数、19859203が得られます。これもコピーしてProperTreeまたはPlistEDPlusにペーストすれば良いです。\n「計算機」にはRPN（逆ポーランド記法）で操作するモードもあるので、マニアックな人も満足できると思います。\nおまけ1: 表示pickerを減らす Pickerがこれくらい並んでも（USBメモリーが挿さってなければ2個減りますし）適切に賑わっていて良いと思いました。でも、efiツールをたくさんインストールしている場合は、それが右端に追加されるので、煩雑だと感じることもあるようです。\nそこで、使用頻度の低いpickerを非表示にするオプションがあるようです。config.plistのMisc –\u0026gt; Boot –\u0026gt; HideAuxiliaryです。デフォルトではfalseですが、これをtrueにすると、写真のpickerのうち、Recovery, Reset NVRAMが非表示になります。また、Misc –\u0026gt; Toolsで追加しているefiツールItemの中のAuxiliaryをtrueにしているツールも非表示になります。現在はOpenShell.efiを追加してありますので、HideAuxiliaryをtrueにした上で、さらにOpenShell.efiの設定でAuxiliaryをtrueにしました。その結果、表示されるpickerが以下のように減りました。\nここでスペースキーを押すと、非表示にしていたpickerが元通りに表示されます。\nおまけ2: -vを一時的に有効にする Misc –\u0026gt; Boot –\u0026gt; PollAppleHotKeysをtrueにすると（デフォルトではfalseです）picker画面でApple標準のホットキーがいくつか使えるようになります。使用可能になるキーは以下です。\nCMD+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だと起動画面からオプションを一時的に切り替えることができたので、同じように運用できます。\nまとめ ScanPolicyをデフォルト値から変更して、WindowsやUSBインストーラがpickerに現れるよう設定しました。また、HideAuxiliaryとPollAppleHotKeysもデフォルト値から変更しました。\n","date":"2020-11-24T18:43:49+09:00","image":"/uploads/2020/11/title.jpg","permalink":"/posts/11657/","title":"OpenCoreのpicker画面を設定する"},{"content":"Haswell世代Core i5-4250U搭載Intel NUCにBig Sur 11.0.1をクリーンインストールしました。もともと11.0.1 RCを動かしていたので問題なく起動しました。サポート対象中の最弱マシン相当仕様ですがキビキビ動きます。\nIntel NUC D54250 Intel NUCは、ノートPC用CPUを搭載したデスクトップです。MacBook Airからディスプレイを外してデスクトップにしたような仕様です。低消費電力なので電源を入れっぱなしの家庭用サーバに向いていると思います。\nIntel NUC D54250, 4250U\n10月に、これにOpenCoreを入れて、Big Sur Beta 9をインストールしました。その後、11.0.1 RCを入れてます。\nIntel NUC D54250にOpenCoreとBig Sur Beta 9を入れる\n今回は、これに公開版のBig Sur 11.0.1をクリーンインストールしました。11.0.1 RCが問題なく動いている状態だったので、動いて当然の作業です。\n構成は以下です。\nIntel 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です。\nACPIフォルダの中は以下です。\nSSDT-PLUG.aml SSDT-EC-DESKTOP.aml Kextフォルダの中は以下です。SMC….kextはハードウェアモニター用なのでなくても良いです。Brcm….kextはBluetoothを使うために入れました。これらが無くてもWi-FiはOOBで動きます。\nWhateverGreen.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フォルダの中身は以下です。\nVBoxHfs.efi (HFS+で起動しなければ不要) OpenRuntime.efi OpenCanopy.efi (OpenCore起動画面でアイコン出さなければ不要) Config.plistの設定 config.plistの内容は、Haswell用ガイドのページに従って設定してあります。DevicePropertiesの箇所には、\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AwAiDQ==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; を加えました。Intel HD Graphics 5000を表示用に使用する設定です。また、\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1b,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;layout-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; も加えました。オーディオのレイアウトIDを1番に設定する記述です。また、デフォルトではExposeSensitiveDataが6だったのを7にしました。NUCには搭載されるUSB数が元々少ないので、15個制限対策は不要です。実機のMacと同様ですね。\n以前の記事で、\nMisc – Security – SecureBootModel を Disabled にする 必要があると書きましたが、OpenCore 0.6.3からは、デフォルトのDefaultのままで起動します。\nBig Surを入れる 前述のように、このNUCは\nmSATA 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最終版が入っています。\n今回は、mSATA SSDにBig Sur公開版をクリーンインストールしようとしました。そこで、HDDのCatalinaで起動して、mSATAをまっさらにフォーマットし直しました。そしてCatalinaからBig Surインストーラを起動して、mSATA SSDにインストールしました。\nインストール過程の最初の再起動で、BIOSの警告が出ました。\n特に設定はおかしくなってませんでしたし、この先は、警告が出ることはありませんでしたので、このまま続けました。今までのBig Surインストール作業と同様に、最初の2-3回の起動では、macOS Installerという名前のドライブから再起動します。\nでも進捗すると、フォーマット時に設定したドライブの名前になってます。\nその後、また２回ほど再起動して、設定画面に入りました。\nMacBookAir6,1と6,2は、Big Surが動く最古のMacで、4250UはBig Surが公式対応する最弱のCPUと言えます。ギリギリのスペックですが、Big Surは充分にキビキビ動きました。とはいえ、Geekbench 5で、シングル600, マルチ1200と遅いです。これと比較すると、新しいM1のシングル1600, マルチ7200というスコアはすごいですね。\nまとめ Haswell版Intel NUCにも、OpenCore 0.6.3とBig Sur公開版をクリーンインストールしました。Big Surがサポート対象とする最弱Macに相当するスペックですが、問題なく動きました。\n","date":"2020-11-23T13:08:34+09:00","image":"/uploads/2017/11/20171116093346.png","permalink":"/posts/11605/","title":"Intel NUC D54250 (i5-4250U) にBig Sur 11.0.1を入れる"},{"content":"公的個人認証サービス対応ICカードリーダーが600円で売られてました。USB接続の接触型ICカードリーダーで、マイナンバーカードが読めます。自作macOSマシンでも使えてマイナポータルにログインできました。\nマイナンバーカード対応リーダー 「Hackintoshで確定申告」という記事を、何年も前に書きました。この時使うのが、マイナンバーカードを読み取るための「公的個人認証サービス対応ICカードリーダ」です。今まで、SCR3310-NTTComというカードリーダを使用してました。ずっと以前に販売終了になった古代の製品ですが、秋葉原のジャンク屋さんに山積みされていたのを、使う当てもなく買ったものでした。こういう衝動買いは、大体は無駄に終わるのですが、この物件に関してはとても役に立ってます。\n今は後継機種が販売されているようですが結構な価格です。実はマイナンバーカードは非接触型ICカードでもあるらしくNFCリーダやスマートフォンでも読めるようです。後継機種のカードリーダーも非接触型らしく、それもあって高価なようです。接触型なら端子だけで済むところを、無線送受信機とアンテナが必要なので高くなるのは仕方ないです。\nデジタル庁もできることですし、これから利用する機会も増えそうなので、カードリーダーを買い足そうと考えました。AliExpressで探したら、接触型ICカードリーダーは送料込みで7ドルくらいでした。\nAmazon.co.jpで探したら、ほぼ同じものらしい製品が送料無料で600円でした。今は少し値上がりしてましたがそれでも700円程度です。\nならばということで、信頼と安心のAmazonで手配しました。これをBig Surをインストールした自作マシンに接続すると、システム情報に現れました。動きそうです。\nここに書かれているEMV Smartcard Readerという名前のEMVは、ICチップ搭載クレジットカードの標準規格の名前だそうです。Europay, Master Card, Visaの頭文字らしいです。マイナンバーカードもEMV規格に合わせて作られているようです。考えてみれば、日本のマイナンバーカードにしか使えないガラパゴスなリーダーだったら、ネットで格安で売られているわけがないですよね。試してみたところ、クレジットカードを挿しても反応しますので、本来はPOS端末用などの用途で販売されているのかと思われます。\n公的個人認証サービス マイナンバーカードがあるとどうして確定申告がオンラインでできるのか、謎だったので、総務省のページに行って勉強してきました。\n総務省｜マイナンバー制度とマイナンバーカード｜公的個人認証サービスによる電子\u0026hellip;\nちなみに冒頭のキャラクタはマイキーくんと言って総務省の職員の方がデザインされたようです。JPKI (Japanese Public Key Infrastructure) の頭文字が入っているそうです。\nこのページに書いてあることによると、マイナンバーカードのメモリーには2個の証明書と2個の秘密鍵が記録してあるようです。秘密鍵は公開鍵暗号方式で使う鍵です。公開鍵暗号方式では、データを秘密鍵で暗号化して、公開鍵で解読します。秘密鍵を持っている人だけがその暗号化データを作れたことを証明できます。証明書と秘密鍵は、マイナンバーカードを作るときに要望すると書き込んでくれます。お役所でカードを作ってもらうときに、よく分からないけど無料だったので、とりあえず書き込んでもらった記憶があります。\nマイナンバーカードに入っている秘密鍵は取り出すことができないように作られているそうです。一方で、2個の証明書は取り出せて、以下の用途に使われます。\n署名用電子証明書：確定申告提出書類など、お役所に提出する書類の署名用証明書。公開鍵などの情報の他に、氏名、住所、性別、生年月日の情報（4基本情報）が書いてあります。 利用者証明用電子証明書：マイナポータル（マイナンバーカードを使った電子手続きのポータルサイト）などのサイトにログインするときに使う利用者証明書。公開鍵やシリアル番号などが書かれていますが、4基本情報は書かれていません。 総務省のサイトの説明を読む限りでは、以下のような手順で使用するようです。マイナポータルにログインするときは、おそらくはサーバ側から乱数のようなデータが送られてきて、それを秘密鍵で暗号化して、利用者証明用電子証明書と一緒に送り返すのかと思います。確定申告申請書に関しては、提出書類そのものを秘密鍵で暗号化して、署名用電子証明書と一緒に送り返すという説明が書いてありました。書類そのものを暗号化するのではなくて、書類は平文のままで、書類のハッシュ値を暗号化しているのかなと思わないでもないです。\n秘密鍵の秘密 おおよその仕組みは把握できたのですが、秘密鍵の扱いが疑問でした。証明書を使用する際にはパスワード（英数字6~16桁または数字4桁）が必要です。その時に秘密鍵も読み出せるのかとも想像したのですが、それでは簡単に秘密鍵が漏洩してしまいます。総務省のページにも、秘密鍵はカードからは出てこないと説明してあります。そうすると暗号化できるのはカードの中の人（CPU）だけですが、NFCアンテナからの微小な電力でも動くカードで暗号化などできるのでしょうか。\n検索していたら、「マイナンバーカードを使ってSSHする」という記事が見つかりました。\nマイナンバーカードでSSHする - AAA Blog\nマイナンバーカードにアクセスするためのプロトコルは、なんと未公開らしいです。（少し古い記事なので今は違うのかもしれません）どうりで謎だったわけです。ただ世界標準に準拠しているので、ハッキングできているようです。この記事によると、カードの中には、以下のようなディレクトリで機能が管理されているようです。APはアプリケーションの略らしいです。MFはメインフレームの略です（rootってくらいの意味かな）。\n公的個人認証APが、公開鍵暗号方式を担っているディレクトリです。署名xxxというユニットが、確定申告などで使う4基本情報を含んだ証明書による認証を担当して、認証xxxというユニットが、マイナポータルへのログインなどで使う、個人情報（4基本情報）を含まない認証を担当してます。\nこの記事によると、標準的なカードドライバを元にしたオープンソースアプリで、プロトコルに即した数バイトのデータをマイナンバーカードとやり取りすることで、秘密鍵による暗号化ができるそうです。認証xxxユニットを使う手順をまとめると以下です。\nとあるバイト列をカードに送信して公的個人認証APを選択する 同様に認証用PIN (IEF0018) を選択する 4桁の暗証番号をASCIIコードで送る 認証用鍵 (IEF0017) を選択する 暗号化してほしいデータ（ハッシュ値など）を送る その結果、カードから署名データが返送される これで最終的には、暗号化されたデータと公開鍵が得られるのだと思われます。ということで、なんと、マイナンバーカードが暗号化をしてくれているようです。それなら秘密鍵が外に出ることはないですね。冒頭のタイトルを「マイナンバーカードを読む」としましたが、実はもっと高度な処理をしていたようです。この記事によると、秘密鍵を内部に保持して、外に出さずに内部で暗号化できるデバイスは、まだまだ高価らしいです。それを国民全員に無料で配布しているのですから、もっと活用できるようにすべきだとのことでした。\nマイナポータルにログインする 冒頭で紹介した格安カードリーダーを使ってマイナポータルにログインを試みました。\nマイナポータルは政府が運営しているオンラインサービスで、マイナンバーカードを使った電子手続きのポータルサイトです。ここにログインするには、マイナンバーカードが必要です。おそらくはSSHのログインと同様に、サーバーからタイムスタンプのような乱数が送られてくるので、それをマイナンバーカードの中のチップが暗号化して、公開鍵を含んだ証明書と一緒に送り返すのだと思われます。\nBig Surをクリーンインストールした後なので、前回インストールしたSafari拡張機能が消えてました。ログインをしようとしたら、Safari機能拡張のダウンロードとインストールを求められました。\nOKボタンを押すと、Safari拡張機能がダウンロードされます。これを、Safariの「環境設定…」から有効にすると、この先に進みます。ちなみに、マイナンバーカードを使ういろいろなサイトで、それぞれ別々の拡張機能のダウンロードを求められます。一本化して簡素化しようとする動きはあるようですが、まだまだややこしいです。\n公的個人認証サービスとは | 公的個人認証サービス ポータルサイト\nSafari拡張機能を有効にすると、カードリーダーが認識されて、マイナンバーカードをセットするよう促されました。600円のカードリーダーが正しく動いているようです！\nマイナンバーカードをセットすると、4桁数字のパスワード入力を求められます。このパスワードを使ってマイナカードに指示すると、マイナカードが、サーバーから送られた既知のデータを暗号化し、公開鍵を含む「利用者証明用電子証明書」と一緒に返してくれるのだと思います。\nこれで無事ログインできました。\nまとめ Amazonで安価に売られているマイナンバー読み取りカードリーダーは、マイナポータルのログインに使えました。まだ試していませんが、他の公的個人認証サービスでも、おそらく問題なく使えると思います。マイナンバーカードの公的個人認証サービスは、無料で使える電子実印みたいな機能なので、お役所のサイトだけでなく、もっと色々な場面で使えるようになれば良いと思います。\n","date":"2020-11-22T17:52:04+09:00","image":"/uploads/2020/11/mykey.png","permalink":"/posts/11449/","title":"マイナンバーカードを読む"},{"content":"以前から予告があったのですが、Big SurからとうとうAFPファイルサーバ機能が無くなっていました。SMBだけになったようです。AFPサーバへ接続するクライアント機能はBig Surになってもまだ動いていました。\nAFP AFP (Apple Filing Protocol または AppleTalk Filing Protocol) は、ファイル共有機能を実現するプロトコルの一つです。これにより、ネットワーク上のサーバにあるファイルを、手元のハードディスクにあるかのように扱うことが可能になります。元々AppleTalk用に開発されたのですが、TCP/IP上で動くように移植されて、今も使われてます。macOSの新ファイルシステムであるAPFSと紛らわしい名前ですが、別物です。AFPの仲間には、老舗のNFS (Network File System) とか、Windowsでお馴染みのSMB (Server Message Block) があります。\n最近のmacOSの「システム環境設定」「共有」では、標準でAFPとSMBのサーバー機能がサポートされていました。なので、面倒な手続き無しでどちらのサーバも設定できました。でも、AppleはどうやらAFPから手を引きたいと考えているようで、しばらく前から「AFPをやめてSMBを使ってください」と言ってました。HFS+に代わってAPFSがmacOSの主流のファイルシステムになっても、AFPサーバではAPFSをサポートしてませんでした。なのでAPFSボリュームは、AFP方式でのファイル共有に使えませんでした。\nCatalinaのファイル共有 Catalinaでは、「システム環境設定」「共有」からファイル共有の設定をすると、デフォルトではSMB方式のサーバとして機能するようになってました。AFPファイルサーバの設定も可能でしたが、「オプション…」ボタンを押してからようやく選択できるようになってました。できればAFPは使って欲しくないというメッセージが読み取れる設定画面でした。\nBig Surのファイル共有 Big Surになって確認したところ、ファイル共有設定のオプションボタンを押しても、AFPの選択ができなくなってました。選択できるのはSMBだけです。\nちなみに、Big SurになってもAFPクライアント機能は健在です。AFPで立ち上げているファイルサーバに、Big Surから接続することができました。でもこれもそのうち廃止されるのかもしれないですね。\n","date":"2020-11-20T23:18:52+09:00","image":"/uploads/2020/11/network.png","permalink":"/posts/11548/","title":"Big SurでAFPファイルサーバ機能が廃止されました"},{"content":"Time Machine用に大容量HDDを搭載できるのは自作hackintoshの大きなメリットです。そのTime MachineがBig SurになってAPFSに対応したようです。APFSになると色々メリットがあるので、現用のTime Machineも移行しました。\nTime MachineとAPFS Time Machineによる自動バックアップ機能がOS標準なことは、macOSの大きなメリットだと思います。うっかり削除したり、書き換えてしまったファイルを、Time Machineに何度も救われてます。Macに安い大容量HDDを内蔵すれば、安価に高速にバックアップできます。お手軽なマシンでそれが可能なのが自作PCです。\nそのTime Machineが、Big SurになってようやくAPFSに対応しました。今までのTime Machineは、古いHFS+ファイルシステムを使っていました。Time Machineでは、特定時間ごとの全ファイルのスナップショットをバックアップします。１回目は、全てのファイルをバックアップコピーしますが、２回目以降は、差分だけを記録します。でもTime Machineのドライブをファインダーで見ると、あたかも毎回の記録が全て揃っているように見えます。Time Machineが頑張ってそのように見せているのです。\nこの機能は、APFSで導入されたクローン機能と似ています。あるファイルをクローン機能で複写すると、物理的なデータは一つしかないけど、それを2個に見せてくれます。片方のコピーに変更が加わると、その変更分だけを記録します。おそらくは、Time MachineのコードがAPFSの開発にも役立っていたのではないかと思います。逆に、APFSに備わったクローン機能をTime Machineで使えば、よりシンプルに効率よく実現できるはずです。ファイルシステムの機能ならば色々な場面で動作チェックされますから、バグが減って、堅牢になって、さらには最適化が進んで高速化すると期待できます。でもAPFSが実用化されても、今までTime MachineはHFS+を使ってました。移行に手こずっていたのかもしれません。でもようやくBig Surで対応しました。\nAPFS対応の確認 Time MachineがAPFS対応したことの確認をしました。Time Machineは、今までのHFS+のバックアップファイルも、サポートします。でも、新しいバックアップディスクを作る場合は、APFSになるようです。まずは、500GBの2.5インチHDDを用意して、HFS+でフォーマットしました。先の記事で紹介したリムーバブルHDDラックに入れてあるので、オレンジ色のリムーバブルディスクに見えてます。\nファイダーにも、オレンジのアイコンで、New Diskという名前で見えてます。\ndiskutilコマンドでチェックすると、確かにHFS+になってます。全体が一つのHFSボリュームです。\n/dev/disk8 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.1 GB disk8 1: EFI ⁨EFI⁩ 209.7 MB disk8s1 2: Apple_HFS ⁨New Disk⁩ 499.8 GB disk8s2 この後、「システム環境設定」「Time Machine」から、「ディスクを選択」ボタンを押し、このドライブをTime Machine用に設定します。\nここで消去を選ぶと、Time Machine用のHDDとして再度フォーマットされます。HDDの名前は同じですが、アイコンがTime Machine用に変わりました。\ndiskutilコマンドで調べると、\n/dev/disk8 (external, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.1 GB disk8 1: EFI ⁨EFI⁩ 209.7 MB disk8s1 2: Apple_APFS ⁨Container disk9⁩ 499.8 GB disk8s2 /dev/disk9 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +499.8 GB disk9 Physical Store disk8s2 1: APFS Volume ⁨New Disk⁩ 692.2 KB disk9s2 となってます。論理的な入れ物であるコンテナができて、その中にAPFSボリュームができてます。ボリュームの名前は、HFS+のボリュームの名前のNew Diskを引き継いでいます。このように、HFS+からAPFSにファイルシステムが変更されました。この後は、今までと同じように、Time Machineを利用できます。なお、ディスクユーティリティで確認すると、APFS（大文字、小文字を区別）になっていました。\nAPFSの利点 APFS化されたことで、堅牢になって高速化される可能性はあります。利便性も上がります。APFSのボリュームになったので、サイズが柔軟に変更できます。一台のHDDを丸ごとTime Machineに割り当てる場合は、悩む必要はないのですが、パーティションに分けて、一つのパーティションをTime Machine用に使う場合は、サイズの決定が難しかったです。Time Machineには大容量のHDDを割り当てるので、パーティションを分けて、その一つをデータ置き場にしようとか、別の一つにはバックアップのmacOSを入れておこうなどと考えることが多いです。\nHFS+のパーティションの場合、パーティションの大きさを、フォーマット時に決める必要があり、それ以降変更することがほとんど不可能でした。なので、運用してみるとサイズが足りなかったり、大きすぎたので勿体無かったりします。APFSボリュームならば、可変サイズなので必要に応じて記録領域が伸縮します。後から別のボリュームを追加することも可能です。\nボリュームを追加する すでにTime Machine用に設定してしまったこのHDDに、新たにデータを書き込んでおくボリュームを追加してみます。HFS+だと実現できなかった手順です。ディスクユーティリティで、コンテナを選び、上の+ボタンを選択します。これでAPFSボリュームを追加できます。dataという名前のボリュームを追加しました。\nついでなので、macOSというボリュームも追加しておきます。その結果、\n/dev/disk10 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +499.8 GB disk10 Physical Store disk9s2 1: APFS Volume ⁨New Disk⁩ 84.8 GB disk10s2 2: APFS Volume ⁨data⁩ 999.4 KB disk10s1 3: APFS Volume ⁨macOS⁩ 991.2 KB disk10s3 こんな感じに3個のボリュームが出来上がりました。macOSには、本体macOSが壊れた時のために、Big Surをインストールしてみます。インストーラを立ち上げて、このボリュームを選択します。\nこれでBig Surもインストールできて、起動できるようになります。macOSがインストールされた後のコンテナを見ると、\n/dev/disk10 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +499.8 GB disk10 Physical Store disk0s2 1: APFS Volume ⁨data⁩ 1.1 MB disk10s1 2: APFS Volume ⁨New Disk⁩ 84.8 GB disk10s2 3: APFS Volume ⁨macOS - Data⁩ 20.4 GB disk10s3 4: APFS Volume ⁨macOS⁩ 14.9 GB disk10s5 5: APFS Volume ⁨Preboot⁩ 282.1 MB disk10s6 6: APFS Volume ⁨Recovery⁩ 655.5 MB disk10s7 7: APFS Volume ⁨VM⁩ 1.1 MB disk10s8 手動で作成した、New Disk, data, macOSの3個のボリュームに加えて、macOSインストーラが作成した、macOS – Data, Preboot, Recovery, VMのボリュームが作られています。\nまとめ Time MachineがAPFSに対応したことを確認しました。Time Machine用のディスクを新たに作ると、APFSになります。APFSになったおかげで、Time Machineのデータはそのまま残しつつ、後からボリュームを追加したり、macOSをインストールしたりできるようになりました。ということで、今使っているTime Machineドライブも消去して、APFSに移行することにしました。\n","date":"2020-11-16T17:19:52+09:00","image":"/uploads/2020/11/hddicon.png","permalink":"/posts/11435/","title":"Big SurでTime MachineがAPFS対応する"},{"content":"Big SurになってRadeon RX 5700 XTのGeekbench 5のスコアが格段に改善されました。RX 580と比較するとOpenCLもMetalも1.6倍くらい高いスコアでした。\nGeekbench 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の構成です。\nCatalinaのスコアは以前の記事などで計測したものです。Catalinaだと、RX 5700 XTはRX 580に比べて同程度か、場合によっては劣っていることもありました。特にMetalの性能が弱い感じでした。本来なら古くて安価なRX 580よりも性能が高いはずなのですが、macOSのドライバの作り込みが不足しているようでした。\nBig Surのパブリックベータが出ると状況は変わります。ベータのバージョンが進むたびに、RX 5700 XTのスコアが少しずつ改善されていきました。そして公開版11.0.1では、最後のベータ版からさらに改良されたようで、RX 580に圧倒的な差をつけてます。一方でRX 580は、Catalinaの頃とスコアがほとんど変わっていません。\nちなみに話題のM1のiGPUは、OpenCLが19000くらいのようです。Intel UHD Graphics 630が5000くらいでしたから、iGPUとしては頑張ってますが、ちゃんとしたグラフィックスカードには及ばないようです。\nmacOSでグラフィックス性能を求めるなら、RX 5700 XTが1番の選択肢と思います。また、他のNaviアーキテクチャのRX 5000シリーズも性能改善されているのではないかと思われます。RX 5000シリーズを使うためには、\nWhateverGreen.kext (グラフィックス関係のパッチ集) Lilu.kext (パッチを当てる機能を提供するkext) を入れ、CloverやOpenCoreのブートオプションに、WhateverGreenに指示するオプションである、\nagdpmod=pikera を追加します。\nVega 64も性能向上 コメントでyoshiiさんから教えていただいた情報によるとVega 64でも17% ~ 19%くらい改善しているようです。\nMacOS 10.15　54050(OpenCL)/52086(Metal) MacOS 11　64061(OpenCL)/60921(Metal) ","date":"2020-11-15T16:46:58+09:00","image":"/uploads/2020/11/rx5700xt.jpg","permalink":"/posts/11426/","title":"Big SurでRadeon RX 5700 XTのスコアが大幅に改善"},{"content":"抜き挿し可能なリムーバブルSATAドライブベイで、HDD/SSDのホットプラグを可能にするパッチを以前ご紹介しました。Big Surでパッチパターンが変わったので、これに対応しました。\n5.25インチベイ用リムーバブルHDDラック 上の写真のような、5.25インチベイに取り付けるリムーバブルHDDラックは、本物のMacには無い、自作hackintoshならではの便利な装備です。でもHDDラックを取り付けただけではHDD/SSDのホットプラグが効きませんでした。macOS起動時にリムーバブルベイに装着されているHDD/SSDは認識され、ファインダー上でアンマウントして、安全に取り外すことはできます。しかし、macOS稼動中にHDD/SSDを挿しても認識されません。そこでホットプラグが機能するようにconfig.plistにkextパッチを当て、対応していました。\nSATA接続HDD/SSDのホットプラグ\nリムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する\nこのパッチが効くと、マザーボードのチップセットが持っているSATA端子以外、つまり、マザーボード上にSATAチップを追加して増設したSATA端子が、リムーバブルドライブとして扱われるようになります。チップセットがサポートするSATAは通常6個ですので、8個のSATAを持っているマザーボードは、最後の2個が対象になります。また、PCIeスロットにSATAアダプターカードを挿してSATA端子を増設した場合も、そこに接続されるドライブがリムーバブルになります。例えば以下のような、Marvell 88SE9230チップセットや、ASMedia ASM1061チップセットを搭載したカードです。\nところが、Big Surにバージョンアップしたら、このパッチが効かなくなったようで、ホットプラグが機能しなくなりました。調べたところパッチパターンが変わっていたようです。\nパッチの方法 パッチは、/System/Library/ExtensionsにあるAppleAHCIPort.kextのバイナリファイルの該当部分を、0x90 (マシンコードでNOP, No OPerationに相当します) に置き換えるものです。置き換える範囲は、ファイルの中の0x40200000というデータ列の4バイト、その前8バイト、その後14バイトの、合計26バイトです。この26バイトのパターンが、Big Surになって変わっていたようで、パッチが効かなくなっていました。\nそこで、Big Surのkextの中で0x40200000を探して、書き換えるべきデータ列を調べなおすことにしました。まずは、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをhexdumpして、lessコマンドで表示を一旦停止しておきます。\n% hexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less lessが起動しているところ、以下のサーチコマンドをタイプし、40 20 00 00を探します。\n/40 20 00 00 ところが運悪く途中に改行が入っているようで見つかりません。40 20だけでもう一度探索します。\n/40 20 今度は見つかりました。改行の先に00 00があるので、間違い無いようです。他にも40 20は見つかりますが、その先に00 00が続く場所はありません。もしもこれで見つからなければ、他の場所に改行が入っているかもしれませんので、\n/20 00 00 で探せば良いと思います。\n今回、発見できた場所の前後のデータは以下です。\n0003da0 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) に置き換えるパッチを作ります。つまり、\nFind --\u0026gt; 81E14060 020081F9 40200000 750C81E2 BF7FFFFF 89936901 0000 Replace --\u0026gt; 90909090 90909090 90909090 90909090 90909090 90909090 9090 AppleAHCIPort というパッチを作ります。前回のパッチパターンに類似していますのでおそらく合っていると思います。\nconfig.plistをテキストエディタで編集する場合はbase 64に変換します。詳しくはこちらをご覧ください。Findするデータはbase 64では以下になります。\n% echo -en \u0026#34;\\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\u0026#34; | base64 geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA= Replaceするデータは、NOPコマンド列である9090…なのですが、このbase 64は以下です。\n% echo -en \u0026#34;\\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\u0026#34; | base64 kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA= Cloverの場合 最近Cloverは使っていないので検証できませんが、Cloverの場合、config.plistに以下を書けば良いはずです。\n\u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Enables hot plug for removal drives\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; OpenCoreの場合 OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、使用するキーは以下です。\nComment : Cloverと同じ。人が読むためのメモ書き。 Find : Cloverと同じ。検索データ列。 Replace : Cloverと同じ。置き換えるデータ列。 Identifier : CloverのNameに相当するキー。kextを指定するためのIDで、バンドルIDを使う。 Enabled : パッチを有効にする場合はtrueにする。（有効にしたいのでtrueにする） Count : パッチを当てる箇所の数。今回の場合は1回なので1。 その他のキー : デフォルトで良いので省略。 kextのバンドルIDは、システム情報で知ることができます。\nシステム情報の拡張機能のAppleAHCIPortの項目を選択すると、\ncom.apple.driver.AppleAHCIPort であることがわかります。これはBig Surになっても変更はありませんでした。そこで、OpenCoreのパッチは以下になります。\n\u0026lt;key\u0026gt;Kernel\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Patch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Enables hot plug for removal drives\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Count\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;Enabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Identifier\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; ProperTreeやPlistEDPlusなどのアプリケーションで設定するなら、16進数でそのまま書けます。ProperTreeでは16進数のデータの8バイトごとにスペースを入れる流儀のようですが、\n81E14060 020081F9 40200000 750C81E2 BF7FFFFF 89936901 0000 PlistEDPlusではスペースを入れないようです。\n81E14060020081F940200000750C81E2BF7FFFFF899369010000 以下はPlistEDPlusの例です。Item番号はたまたま7番目になっていますが、何番目でも大丈夫です。\n動作確認 パッチをOpenCore 0.6.3のconfig.plistに追加したところ、Big Surでもこのホットプラグが機能しました。オレンジ色のドライブがmacOS起動後にリムーバブルベイに取り付けた3.5インチHDDです。\n補足 最初の記事、\nでは、\nFind --\u0026gt; 40600200 Replace --\u0026gt; 00000000 AppleAHCIPort というパッチを当てれば、ASMediaやMarvellのチップでホットプラグが可能になるという情報を紹介しました。今回、Big Surで試したところ、マウントする際にシステムが落ちてしまう現象が発生しました。PCIeに挿すASMediaやMarvellのSATAカードでも、ここで紹介した長いパッチは安定して動きますので、この記事の方式を使ってください。\nまとめ リムーバブルドライブベイのホットプラグを可能にするパッチを、Big Sur用に書き換えて動作を確認しました。これからも、しばらくはBig Surへの対応作業を楽しめそうです。\n","date":"2020-11-15T01:10:14+09:00","image":"/uploads/2020/11/orangeicon.png","permalink":"/posts/11406/","title":"リムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)"},{"content":"メインで使っているZ390マシンにmacOS Big Sur 11.0.1をクリーンインストールしました。macOSの本体とユーザディレクトリを別のSSDに分けて入れてありました。そこで、前回作成したインストール用USBを起動し、macOS本体が入っているSSDだけを初期化し、Big Surをインストールしました。\nシステムの構成 Big Sur公開初日にZ490マシンにクリーンインストールしました。\nBig Surをクリーンインストールする (OpenCore + Z490)\n2日目の今日は、メインで使用しているZ390マシンにもクリーンインストールします。こちらのマシンです。現在は、OpenCore 0.6.3とCatalinaの最新版が動いています。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\nZ490の方は、ほとんどデータがなかったので、クリーンインストールも簡単でした。でもこちらのマシンは、いろいろデータが入っています。Dropbox、iCloud, Timemachineなどでバックアップされているので、最悪、全部消えても困りませんが、できれば残しておきたいです。\n幸いなことに、macOSの本体と、ホームディレクトリを別のSSDに置いていました。diskutil listコマンドで見ると、以下のようになってます。（TimemachineやWindowsなどのドライブも接続されているのですが省略しました。なので、番号が飛んでます）\n% 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 物理ディスクは\ndisk1 (250GBのM.2 SSD) と disk4 (960GBのSATA SSD) です。\ndisk1 (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全体を削除して、その後復活させることにしました。\nUSBインストーラを起動 昨日の記事で作ったUSBインストーラを使います。まずは、このUSBメモリのESPの部分に、現在使用しているdisk1のEFIをコピーしておきます。これでUSBメモリから起動できます。disk1から起動することも可能ですが、これから消去する予定なので、ここでバックアップしておきます。\nこれでBIOSでUSBインストーラを指定して起動できます。昨日のZ490へのインストールの時は復旧（Revoery）画面が日本語でしたが、今回はなぜか英語画面でした。\nクリーンインストールする まずはDisk Utilityを選んで、250GB SSDを綺麗に全消去します。\nここでEraseボタンを押したら元には戻れません。ひたすら進むだけです。Disk Utilityを終了して、最初の画面に戻り、Install macOS Big Surを選びます。\nさらに、インストール先に、先ほどフォーマットしたボリュームを選び、インストールを開始します。\nこの先は、前回と同じく、数回ほど再起動しつつ、インストールが進んでいきます。インストールが一通り終了すると、国選択の画面になります。\nこの後、いくつかの設定をすればインストール完了です。\nUSBメモリのESPの内容を、M.2 SSDの方に書き戻しておけば、SSDで起動するはずです。\nホームディレクトリを復活 インストール直後は、インストール先の/Users以下にホームディレクトリがあります。クリーンインストールしたので中身は空です。そこで、今まで使っていた2.5インチSSDの場所にあるディレクトリに、ホームディレクトリを移動します。「システム環境設定」「ユーザとグループ」で「変更するにはカギをクリックします。」を選び、自分のユーザアカウントの上で右クリックして、「詳細オプション…」を選べば、ホームディレクトリを元の場所に戻せます。これで再起動すれば、Catalinaで使っていたファイルが全て使えます。\nまとめ OpenCoreで起動しているZ390マシンにBig Surをクリーンインストールしました。ホームディレクトリをmacOSとは別のSSDに入れてありましたので、それを残しつつ作業しました。\n","date":"2020-11-14T19:24:47+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/11388/","title":"Big Surをクリーンインストールする (OpenCore + Z390)"},{"content":"macOS Big Sur 11.0.1の配布が開始されました。早速、Catalinaからアップデートしました。最新版のOpenCore (0.6.3) とkext類でCatalinaが動いていれば、通常の作業でアップデートできるようです。\nシステムの構成 本日 (日本時間2020/11/13)、macOS Big Sur 11.0.1 の配布が開始されました。過去のメジャーアップデートのナンバリング方式から、最初に出るのは11.0だと思ってましたが、今回は最初から11.0.1でした。インストール先のマシンは、こちらです。Z490マザーボードに10900Kを搭載しています。グラフィックスはRadeon RX 5700XTです。\nASUS ROG STRIX Z490-G, 10900K\nこのマザーボードに取り付けたWestern Digitalの250GB M.2 SSD, WD BLACK SN750 NVMeにクリーンインストールしました。SSDには、OpenCore 0.6.3と最新のkext類が入っていて、Catalina 10.15.7が動いています。diskutil listコマンドで見ると以下のようになっています。\n% 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は仮想メモリー用のボリュームです。\nアップデートの手順 せっかくのメジャーアップデートなので、現在のM.2 SSDは綺麗さっぱりと全消去して、クリーンインストールしようと思います。なので次の手順でアップデートを進めます。\ndisk1の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分くらいでダウンロードできました。\nダウンロードするといつものように自動的にインストーラが開きます。ここではインストールしないので、インストーラは一旦終了します。\n2. 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個制限を外しておくという方法もありますが）\nUSBメモリをHFS+で初期化する 次に、USBメモリーをディスクユーティリティ.appを使って初期化します。ディスクユーティリティ.appのデフォルトではボリュームのみが表示されますので、まずは、メニューバーの表示から「すべてのデバイスを表示」を選んでおきます。\nこうすると、USBメモリ製品名が入ったデバイス名がウィンドウ左側リストに現れますので、これを選択します。今回はJetFlash Transcendという製品名を選択しています。次に消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここでAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。Mac OS拡張（ジャーナリング）を選んでおく必要があります。\n次に、Big SurインストーラーをUSBメモリ内に作ります。これは実機（本物のMac）でもBig SurをインストールできるUSBメモリになります。ターミナルを使用して、Big Surインストーラの中のContents/Resourcesに移動して、lsするとcreateinstallmediaというファイルが見つかるはずです。\n$ cd /Applications/Install\\ macOS\\ Big\\ Sur.app/Contents/Resources/ $ ls create* createinstallmedia これを使用して、macOSインストールUSBメモリを作成します。とりあえず起動すると、ヘルプ情報が表示されます。\n$ ./createinstallmedia Usage: createinstallmedia --volume \u0026lt;path to volume to convert\u0026gt; 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メモリへのパスを書いておきます。ということで、以下のコマンドを入力します。\n% sudo ./createinstallmedia --volume /Volumes/USB/ sudoしているのでパスワードを求められます。その後、確認を求められるのでyを押します。そうするといろいろ進捗して終了します。\nPassword: 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 \u0026#34;/Volumes/Install macOS Big Sur\u0026#34; これでインストール用USBメモリが出来上がりました。本物のMacなら、このUSBメモリで起動するはずです。\n3. USBメモリのESPにdisk1のESPをコピーする こうして作成したインストーラUSBメモリのESPに、稼働しているOpenCore一式をコピーして、USBメモリだけで起動するようにします。それぞれのESPをマウントして、EFIフォルダをファインダーでドラッグ\u0026amp;ドロップすれば良いです。この先、M.2 SSDは消去しますので、他にも必要なデータがありましたらバックアップしておきます。\n4. USBメモリーからインストーラを起動する これで、BIOSからこのUSBドライブを指定して起動すれば、今まで通りOpenCoreが起動して、起動ドライブにBig Surインストーラが見えるはずです。\nただ、OpenCoreでデフォルト通りの設定をしていると、起動ボリュームの一覧にこのUSBメモリが現れないかもしれないです。それはconfig.plistのMisc, Security Properties, ScanPolicyのデフォルト設定が原因です。これのデフォルト値は、0x010F0103 (10進数では17760515) です。この設定だと、2重の理由で、今回のUSBメモリが起動ボリューム候補に現れません。\nまず、USB接続された起動ボリュームをスキャン対象に認める設定が、0x00200000のビットですが、これがデフォルトでは0になっています。なのでUSBデバイスをスキャンしてくれません。 また、HFS+のボリュームをスキャン対象として認める設定が、0x00000200のビットです。これもデフォルトでは0なので、候補に現れません。 なので、デフォルト値を変えて、ScanPolicyを0x012F0303 (10進数では19858179) に設定します。下の図はProperTreeを使って変更している様子です。\nこれで起動項目にUSBメモリのインストーラが現れるようになります。Big Surアイコンのボリュームが、USBメモリーです。このInstall macOS Big Surを選択して起動します。\n5. インストール先ボリュームを消去する USBメモリから起動すると、復旧 (Recovery) というアプリケーションが起動します。\nTime Machineから復元する、macOS Big Surインストールする、Safari (を開く)、ディスクユーティリティ（を開く）、の選択が可能になります。この他、メニューバーの「ユーティリティ」から、「起動セキュリティユーティリティ」と「ターミナル」が選べます。「起動セキュリティユーティリティ」は、Apple T2チップ用の機能と思われます。hackintoshでは関係ないです。\n今回はクリーンインストールを目指すので、Catalinaが入っているdisk 1を消去します。ディスクユーティリティを開き、全てのドライブを表示するようにし、Catalinaが入っているドライブを選択して、消去します。\n名前を設定して、フォーマットをAPFSにして、Eraseボタンを押します。これで綺麗さっぱり消去されます。\n6. Big Surをインストールする Disk Utilityを閉じると、またRecoveryのメニューに戻ります。次にInstall macOS Big Surを選択します。するとおなじみのBig Surインストーラが起動します。後は、いつものようにインストールを進めていくだけです。\nインストール先のリストには、先ほどフォーマットしたディスクが現れますのでそれを選択します。（ここでもう一つ見えているアイコンはUSBメモリです）\n17分くらいでインストールできるそうです。\nでも17分も経たないうちに（多分5~6分）、再起動しました。このとき、macOS Installerというドライブが選ばれているはずです。もしも他が選択されていたら、これを選んでおきます。\n次は30分程度のようです。\nこの後、30分も経たないうちに（これも多分5~6分くらい）また再起動しました。またmacOS Installerが選択されてます。\nそして数分でまたまた再起動。今度は、インストール先ドライブにつけた名前 (Macintosh HD) の選択肢が現れ、選択されています。これで起動します。\nさらに、2~3分で、またまたまた同様に再起動しました。そして次の起動で、設定画面が現れました。\nあとはいつものように、設定を行なっていくだけです。\nインストール終了したあと、このMacについてを確認すると、バージョンは11.0.1 (20B29) でした。Geekbenchブラウザに出回っている情報によると、M1搭載MacBook Airなどと同じOSが搭載されているようです。\nUSBメモリのESPの内容を、M.2 SSDの方に書き戻しておけば、SSDで起動するはずです。\nまとめ OpenCoreで起動しているZ490マシンにBig Surをクリーンインストールしました。そのために、単体で起動してBig SurがインストールできるUSBメモリを作りました。以前のバージョンの場合と手順は同じです。ベータ版で予行演習していたこともありますが、スムーズにBig Surに移行できました。\n","date":"2020-11-13T23:56:37+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/10986/","title":"Big Surをクリーンインストールする (OpenCore + Z490)"},{"content":"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もすぐに出そうです。\n11.0.1 RC 2にアップデートする 前回の記事で11.0.1 RCを入れたZ490マシン（Z490 + 10900K + 5700XT）\nmacOS Big Sur 11.0.1 RCをインストール\nのソフトウェアアップデートにmacOS Big Sur 11.0.1 RC 2の案内が来ていました。ネット上のニュースでは開発者向けに公開されたと書かれていましたが、Public Betaとしても公開されたようです。\nOpenCoreなどのバージョンは以下のとおりです。\nOpenCore 0.6.3 kext類は一般公開されている最新のもの 機種設定はiMac20,1 「今すぐアップデート」ボタンをクリックすると、3.22GBのファイルがダウンロードされ、その後、3回くらい再起動してインストールが終了し、macOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、20B28になっていることを確認できます。RC 2 になって、Betaという文字が消えてますし、ビルド番号もクリックしないと現れなくなりました。公開を見越したバージョンになっていると思いました。\nちなみに発表されたばかりのMacBook Airに搭載されるBig Surは、Geekbenchブラウザによると20B29のようです。\n","date":"2020-11-12T00:42:55+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/11292/","title":"macOS Big Sur 11.0.1 RC 2をインストール"},{"content":"Apple Storeのページの買い物を、macOSからApple Payで手続きしました。iPhoneで認証する必要があり、また何回か試行錯誤しましたが支払いできました。\n使用したマシン構成 Apple Storeサイトで買い物をしようとしたら「Apple Payで注文手続きを行う」というボタンがありました。これで支払いができるのかどうか、試してみました。\n使用したハードウェアは、ASUSのZ390マザーボード、9900K、Radeon RX580の構成です。マザーボードのPCIeスロットに、Broadcom BCM94360CDを搭載したWiFi/Bluetoothカードを取り付けています。macOSはCatalina 10.15.7で、OpenCore 0.6.3でブートしています。機種IDはiMac19,1に設定してあります。\nApple Pay使用可能なMac Apple Payは、Suicaやクレジットカードなどを紐付けたiPhone/Watchで、非接触で支払いができる機能です。用途が限定されますがMacでも使えることになってます。Macの場合、web上で支払いができます。対象は2012年以降に発売されたMacです。iMac19,1は問題ないですし、BCM94360CDも2013年モデルから採用されているので大丈夫と思いました。\nまた、Apple Payのサイトには、「Touch IDを搭載したMacBook AirとMacBook Proではワンタッチで支払いが完了。」と書いてあります。指紋認証機能が未搭載のMacでは、ワンタッチでは完了しないという意味に読み取れます。そのようなMacでは本人認証にiPhoneを使用するようです。\niPhoneを接続する 「Apple Payで注文手続きを行う」ボタンをクリックしたところ、iPhoneをBluetooth接続するように指示されました。指紋認証があるMacだと、もしかしたらiPhoneは不要なのかもしれません。\nそこで、iPhoneを動作させて近くに持ってきたのですが、Bluetooth接続に失敗しているようです。最近のBluetoothでは、ペアリング画面が表示されている時だけ、ペアリングのための情報をブロードキャストするらしいです。ということで、iPhoneの「設定」「Bluetooth」画面を開きました。Bluetoothはすでにオンになってましたが、この画面を開くことでペアリングが可能になるようです。次のステップに進みました。\nクレジットカードで支払う iPhoneに接続できると、次に支払いカードの選択画面になります。カードの請求先を選択することもできます。\nと同時に、iPhoneにもApple Payの画面が現れて、右ボタンダブルクリックで承認できるようになってます。ここでiPhoneで承認すれば、支払い処理が終了するようでした。\nただ、最初のうちは、「請求先住所が無効です」とか「このカードはウェブ支払いに使えません（この通りの文言では無かったです）」というようなメッセージが出て、処理が進みませんでした。\niPhone側では、WalletアプリでApple Payで使うクレジットカードを登録します。この情報を確認したところ請求先住所が未登録でした。Macの画面でも請求先を指定できるのですが、iPhone側でも登録する必要があるのかもしれません。また、MasterCard系のクレジットカードではなかなか処理が進みませんでしたが、JCB系のカードに切り替えたらすんなり進みました。ということで、何回か試行錯誤した結果、結局は支払いに成功しました。失敗したケースでは、カードの設定か手続きが不十分だったように思います。JCB系のカードではすぐに承認されたので、Hackintoshだからダメだったという様子ではないです。\nということで無事、Apple Payでお買い物ができました。ちなみに買ったのは、HomePod miniです。最近は、近所のファミリーマートで受け取りができるんですね。これはありがたいです。\n","date":"2020-11-08T00:18:18+09:00","image":"/uploads/2020/11/Apple_Pay_logo.png","permalink":"/posts/11228/","title":"Apple Payでお買い物する"},{"content":"macOS Big Sur 11.0.1 RC (Release Candidate) が、パブリックベータとして本日公開されたので、11.0.1 Betaからアップデートしました。ビルド番号は20B5022aです。システム環境設定のソフトウェア・アップデートから簡単にアップデートできました。RCは、問題がなければこのまま正式リリースになるバージョンです。11.0が出ることなく、最初のBig Surは11.0.1になるのかもしれません。\n11.0.1 RCにアップデートする 前回の記事で11.0.1 Betaを入れたZ490マシン（Z490 + 10900K + 5700XT）\nmacOS Big Sur 11.0.1 Betaをインストール\nのソフトウェアアップデートにmacOS Big Sur 11.0.1 RCの案内が来ていました。ネット上の多数のニュースでは開発者向けに公開されたと書かれていましたが、Public Betaとしても公開されたようです。（パブリックベータ版のスクリーンショットは公開してはいけないらしいので、前回同様に加工しました。）\nOpenCoreなどのバージョンは以下のとおりです。\nOpenCore 0.6.3 kext類は一般公開されている最新のもの 機種設定はiMac20,1 「今すぐアップデート」ボタンをクリックすると、2.8GBのファイルがダウンロードされ、その後、2回再起動してインストールが終了しました。その後、macOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、20B5022aになっていることを確認できます。\nIntel NUCもアップデート 以下で、HaswellベースのIntel NUCにBeta 9とBeta 10をインストールした記事を書きました。\nIntel NUC D54250にOpenCoreとBig Sur Beta 9を入れる\nさらに11.0.1 Betaにしていました。このマシンにも11.0.1 RCのアップデートのお知らせが来ていたので、アップデートしたところ、問題なく起動しました。これもOpenCoreは0.6.3です。\n","date":"2020-11-06T22:50:14+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/11217/","title":"macOS Big Sur 11.0.1 RCをインストール"},{"content":"OpenCoreの0.6.3が公開されたので0.6.2からアップデートしました。差分は少ないので新しくなったファイルを差し替えるだけで移行できると思います。Big Surがいつ公開されてもこれで大丈夫と思います。\n0.6.3をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\n.efiファイルを差し替える 前回のアップデートからは古いIA32アーキテクチャ用バイナリーが追加されましたが、今回も同様です。最近のCPU/macOSを使うならIA32フォルダは無視して、X64の方のフォルダの中身を、現用のファイルと入れ替えれば良いです。\n前回0.6.1から0.6.2へアップデートした時と同じ作業を行いました。現在0.6.2が動いている状態ですので、現在のESPに含まれる.efiファイルを、0.6.3のものに差し替えます。以下のスクリーンキャプチャは前回のアップデートのものですが、同じなので流用します。まずはBOOTの中のBOOTx64.efiを差し替えます。\n次に、OC直下のOpenCore.efiです。\nまた、OC/Bootstrap/の中のBootstrap.efiも差し替えます。\nOC/Driversの中のうち、現在使用しているものだけを差し替えました。手元のマシンでは、OpenCanopy.efiとOpenRuntime.efiだけを使っているので、それを差し替えました。OpenRuntime.efiが一番重要ですね。\nOC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。\nACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。\nPlistEDPlusを使ってみる 今回、config.plistを編集するにあたり、Mifjpnさんのサイトで紹介されていたPlistEDPlusというXMLエディタを使ってみました。\nReleases · ic005k/PlistEDPlus\nミニマムなデザインのProperTreeと比べて、アイコンが並んでいて賑やかです。タブでファイルを切り替えられるので、新旧のconfig.plistを切り替えて比較するのが楽でした。下は、0.6.2のconfig.plistと、OpenCore 0.6.3に付属してきたSample.plist（をコピーしてconfig063.plistという名前に改名したファイル）を開いているところです。\n一般的なXMLエディタなので、ProperTreeにあるKexts, ACPI, Toolsフォルダをスキャンしてその記述を追加してくれるようなOpenCoreに特化した機能はありません。でも今回は前バージョンで動いているconfig.plistがあるので、その機能は使いません。\n0.6.3での変更点 今回アップデートしたマシンは、Coffee Lake-S + CatalinaとComet Lake-S + Big Sur 11.0.1 Betaです。Change logを見たところ、この環境で対処すべき項目は見つかりませんでした。すでに0.6.2で問題なく動いているなら、config.plistがそのまま使えて、変更は不要なようです。\nPlatformInfoの中にメモリを設定する項目が追加されてます。特に、Memory Propertiesという一連の項目ができました。メモリーのデータ幅、ECCの有無、DIMMなのかSODIMMなのか、最大容量、DDR2,3,4などの指定ができるようです。「このMacについて」でメモリ情報が正しく現れない場合や、ECC付きなどの特殊なメモリを使う場合に必要なのかもしれません。Sample.plistにもMemory Propertiesは設定されてないので、設定が必要な場合はあまりないと思われます。\nUEFIのOutput PropertiesにForceResolutionという項目ができました。Intel GMAや第1世代のIntel HD Graphics向けのようです。KernelのQuirksの中にForceSecureBootSchemeができたくらいです。説明を見ると仮想マシン向けの設定です。いずれも今回の環境には関係ありませんでした。\nBig Sur Beta 10以降では、SecureBootModelをDisabledにしないとカーネルパニックする現象がありました。これが0.6.3で改善されたようです。11.0.1 RCで試したところ、SecureBootModelのデフォルト値であるDefaultのままで、問題なく起動しました。\nConfig.plistはこちら OpenCoreに付属のSample.plistに、0.6.2で使用していたconfig.plistの内容を反映させました。新しく追加された項目は、全てデフォルト値のままです。その結果、ASUS Z390 ROG MAXIMUS XI + 9900K + RX580の構成のconfig.plistはこのようになりました。\nconfig.plist for ASUS Z390 OC060 - Pastebin.com\nASUS Z490G + 10900K + RX5700XTの構成のconfig.plistは以下です。\nconfig.plist for ASUS Z390 OC060 - Pastebin.com\nいずれもPlatformInfoの項目は未記入ですので、macserialなどを使って生成してください。\n","date":"2020-11-03T19:35:58+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/11189/","title":"OpenCore 0.6.2から0.6.3に更新"},{"content":"Big Sur 11.0.1 Betaがパブリックベータとして本日公開されたので、11.0 Beta 10からアップデートしました。ビルド番号は20B5012dです。簡単にアップデートできました。今までのPBではmacOSインストーラが起動したのですが、今回は単に1回再起動しただけでした。11.0正式版が出ない状況で11.0.1 Betaが出るのは珍しいことかと思います。11.0正式版リリースは近いと思いました。\n11.0.1 Betaにアップデートする 前回の記事で入れた11.0 Beta 10マシン（Z490 + 10900K + 5700XT）\nmacOS Big Sur 11.0 Beta 9 をインストール\nのソフトウェアアップデートにmacOS Big Sur 11.0.1 Betaの案内が来ていました。（ベータ版のスクリーンショットは公開してはいけないらしいので、前回同様に加工しましたw）\nOpenCoreなどのバージョンは以下のとおりです。\nOpenCore 0.6.2 kext類は一般公開されている最新のもの 機種設定はiMac20,1 「今すぐアップデート」ボタンをクリックすると、「アップデートするには、Macを再起動する必要があります。」というメッセージが出ます。ここで再起動を選択すると、アップデートが始まります。\n再起動の後、ダウンロードが始まり、しばらくしてmacOS Big Sur 11.0.1が起動します。設定画面の後、「このMacについて」を見ると、11.0.1になっていることを確認できます。\nちなみに、ベータ版一般の注意なのですが、デフォルトで「Mac解析を共有する」設定になっています。Hackintoshの不具合情報をアップルに送付しても、どちらにとっても無意味なことですので、システム環境設定–\u0026gt;セキュリティとプライバシー–\u0026gt;解析と改善を選んで無効にしておきましょう。\n5700XTの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の結果も掲載しました。\nBetaが出るたびに改良されてきた5700XTのスコアは、今回はほぼ据え置きのようです。ただ、Metalに関しては、測定ばらつき以上に微増していて、まだまだ改良されているようです。macOS開発チームの5700XTへの愛が垣間見える気がしました。\nIntel NUCもアップデート 以下で、HaswellベースのIntel NUCにBeta 9とBeta 10をインストールした記事を書きました。\nIntel NUC D54250にOpenCoreとBig Sur Beta 9を入れる\nこのマシンも11.0.1にアップデートしてみました。問題なく起動しました。\n","date":"2020-10-30T18:49:45+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/11148/","title":"macOS Big Sur 11.0.1 Betaをインストール"},{"content":"Beta 10がパブリックベータとして昨日公開されたので、Beta 9からアップデートしました。ビルド番号は20A5395gです。RX 5700XTの性能が更に向上しました。Beta 10を起動させるために、config.plistのSecureBootModelをDisabledに設定する必要がありました。\nBeta 10をダウンロードする 前回の記事で入れたBeta 9マシン（Z490 + 10900K + 5700XT）\nmacOS Big Sur 11.0 Beta 9 をインストール\nのソフトウェアアップデートにmacOS Big Sur Betaの案内が来ていました。（ベータ版のスクリーンショットは公開してはいけないらしいので、詳細がわからないように加工しましたw）\nOpenCoreなどのバージョンは以下のとおりです。\nOpenCore 0.6.2 kext類は一般公開されている最新のもの 機種設定はiMac20,1 「今すぐアップデート」ボタンをクリックすると、「このシステムでアップグレードするには、フルインストーラが必要です。」というメッセージが出ます。\nアップデートできないのかなと思って、諦めてOKボタンを押したら、親切なことに、「macOS Big Sur Beta 11.0をダウンロードしてもよろしいですか？」というダイアログが出ました。\nダウンロードボタンを押したら、12.21GBのフルインストーラーがダウンロードされました。\nBeta 10をインストールする ダウンロード後に、いつもと同じようにBig Surのインストーラが起動します。\nそのままインストールを続けました。途中で2回、再起動しました。再起動の時の一時的なボリューム名は、「macOS Installer」になり、わかりやすくなりました。\n**（追記）**以下の、起動に失敗する問題はOpenCore 0.6.3で修正されたようです。SecureBootModelはデフォルトのDefaultのままで起動します。\nこの後、インストールが終了したらしい状態になりましたが、起動しなくなりました。カーネルパニックが発生しているのか、メモリーパニックという表示で再起動を繰り返すようになってしまいました。\nフォーラムで、須磨の辰五郎さん、Mifjpnさんから、\nMisc – 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でも大丈夫でした。ということで、\nMisc – Security – SecureBootModel を Disabled にする だけを対応したところ、無事、Beta 10が起動しました。\n5700XTの性能がまたまた向上 このマシン (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の結果も掲載しました。\nこれを見ると、5700XTの性能がまたまた向上した様子です。OpenCLもMetalもどちらも、明らかにRX 580のスコアを上回ってます。これからは、5×00シリーズの時代なのかもしれません（もう生産終了らしいですが）。\n","date":"2020-10-17T17:04:59+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/11045/","title":"macOS Big Sur 11.0 Beta 10 をインストール"},{"content":"昔作った、Haswell世代Core i5-4250U搭載Intel NUCをOpenCoreとBig Sur (Beta 9) にアップデートしました。Ivy Bridge搭載初代NUCの代わりに省電力サーバとして使いたいと考えてます。\nIntel NUC D54250 Intel NUCは、ノートPC用CPUを搭載したデスクトップです。低消費電力なので電源を入れっぱなしの家庭用サーバに向いていると思います。今までは、サーバとしてIvy Bridge搭載の初代NUCを使っていました。でもBig Surでサポートされなくなるので、Haswell搭載のD54250に更新することにしました。D54250には、すでにMojaveを入れてあったのですが長らく放置してました。押し入れから引っ張り出して、CloverからOpenCoreに差し替えて、Big Surに備えることにしました。\nIntel NUC D54250, 4250U\nIntel NUC D54250が搭載するCore i5-4250Uは、MacBookAir6,1, 6,2で使用されているCPUで、macOSとの互換性が高く安定しています。Big Surでもサポートされます。D54250には2種類のケースがあり、末尾がWYKのモデルは薄型筐体で、WYKHは2.5インチドライブを内蔵できる厚型モデルです。古いので探せば安価に入手可能です。WYKHはドスパラで一時期税込3万円未満で売られていましたし、現在は中古店で2万円くらい、オークションでは1万円前後で入手可能なようです。\nハードウェアの構成をまとめると以下です。\nIntel 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コマンドで機種を指定すると、シリアル番号とボードシリアル番号の候補が出ます。\n% ./macserial --model MacBookAir6,2 C02L20YVF5V7 | C02328501GUFD47JA C02NLHYMF5V7 | C02443100J9FD471M C02NNLZBF5V7 | C02445802GUFD47JA C02MT0WEF5V7 | C02423500GUFD47AD C02KGYYNF5V7 | C02312301QXFD471M C02P3QYNF5V7 | C025022004NFD47FB C02ND4Y8F5V7 | C02437303QXFD478C C02M20CTF5V7 | C024011304NFD471H C02NMFYJF5V7 | C02444501CDFD47UE C02MNSZ6F5V7 | C02418301J9FD47AD この中から一つを選べば良いのですが、念のためにその一つの詳細を調べてみます。\n% ./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に指定し、シリアル生成します。\n./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ヶ月後くらいなので妥当な製造日だと思います。\nシリアル番号の特定の4桁部分、上の例では、F5V7とFD47は機種特有の番号です。macserialのソースコードを見ると、他にも多数の選択肢があるのですが、オプションで指定しないとこの番号しか生成されません。このF5V7が4250U搭載の2013年版MacBookAirなのかどうかは、すぐに調べる方法がなさそうでした。ただ、Appleのサイトでシリアル番号が有効かどうかを調べたところ、たまたま実機と同じシリアル番号が見つかりました。（実機と合致する番号は使ってはいけないです）\nこれから、F5V7はMid 2013の4250U搭載モデルの番号と考えて良いと思いました。\nBIOSをアップデートする このNUCでは起動時に時々「CMOSのチェックサムがおかしい」というメッセージがBIOS起動画面に出ました。ボタン電池を外して放置しても出てくるので、BIOSが壊れかけている疑惑もありました。なので、この際、アップデートすることにしました。現在のBIOSは、昔メンテナンスした時にアップデートしたWYLPT10H-86A.0045というバージョンでした。\nインテルのサイトで調べたところ、2019年9月2日に最新のBIOSが出ていて、それは、WYLPT10H-86A.0054でした。早速ダウンロードして、USBメモリーに入れて、BIOS起動画面からアップデートしました。\nhttps://downloadcenter.intel.com/ja/download/29075/BIOS-WYLPT10H-?product=76977\nNUCのBIOSアップデートにはちょっとした注意点があります。アップデートが一段落すると、画面に、「正常にアップデートされました」という表示が出て、そのまま動かなくなります。Ivy BridgeモデルのNUC BIOSをアップデートした時に、しばらく放置しても何の変化もなかったので、ここでリセットすれば良いのかと思い電源を切ったことがありました。すると2度と起動しなくなりました。（このNUCをしばらく放置していたら起動するようになってました。理由は不明ですが、バックアップされていた設定が消えて起動できるようになったのかもしれません。）なので重要なことは、「正常にアップデートされました」という表示が出ても、自動的に再起動されるまで辛抱強く待つということです。2〜3分くらい待たされる感じがします。\nOpenCore 0.6.2を入れる シリアル番号をより正しいものに変更し、BIOSを最新にアップデートした後、入っているCloverも最近のもの (5122) に入れ替え、macOSも最新の10.15.7 (19H2) にアップデートしました。問題なく稼働しているのですが、Big Surへの移行準備のために、ブートローダをOpenCoreに入れ替えることにしました。\nまずはダウンロードしたOpenCore 0.6.2のX64フォルダにあるEFIフォルダを、ESPにコピーします。次に以下のガイドに従って、設定を進めます。\nDesktop Haswell and Broadwell | OpenCore Install Guide\nACPIフォルダの中には、以下の二点が必要です。\nSSDT-PLUG.aml SSDT-EC-DESKTOP.aml CPU毎に必要なamlのリストは以下でまとめられています。\nWhat SSDTs do each platform need | Getting Started With ACPI\nここで必要とされているデスクトップ用SSDT-EC.amlはこちらのサイトからダウンロードしました。そこでのファイル名がSSDT-EC-DESKTOP.amlとなってましたので、名前をそのまま使うことにしました。\nKextフォルダの中は、今回は以下にしました。\nWhateverGreen.kext VirtualSMC.kext SMCSuperIO.kext SMCProcessor.kext Lilu.kext IntelMausi.kext AppleALC.kext SMC….kextはハードウェアモニター用なのでなくても良いです。\nconfig.plistの内容は、上記のガイドのページに従って設定しました。説明を読めば、どれが必要か判断できると思います。DevicePropertiesの箇所には、\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AwAiDQ==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; を加えました。Intel HD Graphics 5000を表示用に使用する設定です。また、\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1b,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;layout-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; も加えました。オーディオのレイアウトIDを1番に設定する記述です。Pci(0x1b,0x0)のPci番号は、Hackintoolを使って、そのPciタブからPCIデバイス一覧を見て、このIOReg NameにHDEFとある行を探して、HDオーディオデバイスを特定しました。\nレイアウト番号はとりあえず1番からテストしようとしたら、1番で正解でした。前面のヘッドフォン端子から音が出ることを確認しました。\nSample.plistの初期設定でKext Updater.appを起動すると、「Misc, Security, ExposeSensitiveDataの1, 2ビットをonにする」ように指示が出ます。デフォルトではExposeSensitiveDataが6だったので7にしました。\nこのNUCには、前面にUSB 2.0端子が2個、背面にUSB 3.0端子が2個あります。また内部のmini PCIeソケットには、USB 2.0が1個あります。さらに、ケースに配線の余裕が無いので使うことはないですが、基板上にUSBコネクタがいくつかあります。ただ、それらを全部加えても15個のようです。なのでconfig.plistのXhciPortLimitで15個制限を外したり、15個制限に対応するkextを作ったりする必要は無いです。\nBig Sur beta 9を入れる Big Surベータ9を入れました。MacBookAir6,1と6,2は、Big Surが動く最古のMacです。また4250UはBig Surが公式対応する最弱のCPUと言えます。ギリギリのスペックでしたが、インストールは、インストーラを起動するだけで簡単でした。インストール途中の再起動では、macOS Installerというドライブが現れて選択されていました。インストール後の動作も問題ありませんでした。ベータ9は安定していて充分にキビキビ動くので、完成度は高いと思います。\nGeekbenchをしてみたところシングル600, マルチ1200台程度でした。遅いですね。Apple Silicon搭載Mac miniが800/2900くらいと言われてますので、完全に負けてます。（追記：Apple Silicon搭載Mac miniが発売された後、スコアが明らかになりました。1680/7400くらいのようです。圧倒的に負けてました。）\nちなみに同じ4250U搭載のMacBook Air Mid 2013のスコアも大体同程度です。妥当な結果のようです。\nBluetoothを使う NUCのmini PCIeソケットに、無線カードを挿しています。WiFiとBluetoothの機能のあるカードです。このうちWiFiはOOBで設定不要で動きます。Bluetoothを動かすためには以下のkextが必要でした。\nBrcmPatchRAM3.kext BrcmFirmwareData.kext BrcmBluetoothInjector.kext これらはKext-Updater.appからダウンロードしました。メイン画面のKextmanagerボタンをクリックして、次の画面でBrcmPatchRamを選びます。\nすると8個のkextがダウンロードされます。このうち太字の3個を使ったわけです。\nBrcmBluetoothInjector.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が見えて、アップル純正キーボード・トラックパッドでの動作を確認しました。\nBig Sur beta 10を入れる 追記です。その後、Big Surベータ10を入れました。ベータ9からのアップデートはインストーラを起動するだけです。ただ、config.plistで、\nMisc – Security – SecureBootModel を Disabled にする ように変更しました。これをしないと多分起動しないようです。詳しくはこちらをご覧ください。\nmacOS Big Sur 11.0 Beta 10 をインストール\n","date":"2020-10-12T00:29:02+09:00","image":"/uploads/2017/11/20171116093346.png","permalink":"/posts/10914/","title":"Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる"},{"content":"OpenCoreの0.6.2が公開されたので0.6.1からアップデートしました。0.0.1の違いなので新しくなったファイルを差し替えただけで移行できました。\n0.6.2をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nIA32というフォルダができている 今回から、IA32アーキテクチャ用のバイナリーも入っています。Intelの古い32ビットアーキテクチャです。古いハードウェアやmacOSのサポートのために32ビット版も配布されるようになったそうです（まっくぷろさん、解説ありがとうございました）。最近のCPU/macOSを使うならIA32フォルダは無視して、X64の方のフォルダの中身を使うことになると思います。\nEFIファイルを差し替える 前回0.6.0から0.6.1へアップデートした時と同じ作業を行いました。現在0.6.1が動いている状態でしたら、現在のESPに含まれる.efiファイルを、0.6.2のものと差し替えることでアップデートできます。具体的には以下のファイルです。まずはBOOTの中のBOOTx64.efiです。\n次に、OC直下のOpenCore.efiです。\nまた、OC/Bootstrap/の中のBootstrap.efiも差し替えます。\nOC/Driversの中のうち、現在使用しているものだけを差し替えました。手元のマシンでは、OpenCanopy.efiとOpenRuntime.efiだけを使っているので、それを差し替えました。OpenRuntime.efiが一番重要ですね。\nOC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。\nACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。\n変更点 今回アップデートしたマシンは、Coffee Lake-S + CatalinaとComet Lake-S + Big Surです。Change logを見たところ、このような環境では、対処すべき項目はほとんど見つかりませんでした。すでに0.6.1で問題なく動いているなら、config.plistがそのまま使えて、変更は不要なようです。\nPlatformInfoの中にSystemMemoryStatusという項目ができました。デフォルトは自動ですが、メモリーが交換可能か、はんだ付けされてて交換不可能かを設定するようです。また、Processor Typeという項目もできました。デフォルトは0で、その場合、自動的に設定されるようです。自動認識されない場合はここで手動設定するようです。\nmacserialなどで使用される機種情報のうち、iMac20,1などの最新機種の細かい情報がアップデートされたようです。BIOSのバージョンとか日付が実際のものに近づいたようです。iMac20,1を使っているのでこれはありがたいです。更新された部分は、OpenCoreの中で自動的に構成してくれる部分なので、config.plistの設定には影響ありません。macserialが生成してくれるシリアル番号などにも変更はありません。iMac20,2のボードシリアル番号の機種ID部分は相変わらず不明で0000になっているようです。iMac20,2にアクセスできるなら貢献できるチャンスかもしれないです。\n% ./macserial --model iMac20,2 --num 5 C02DW05T046M | C02052600QX00008C C02DF4YW046M | C02038130GU0000AD C02DQ2YH046M | C02047701QX00001H C02D76Y9046M | C02033902QX0000UE C02DL0K8046M | C02043101CD00001M いずれにせよ、Comet Lake-Sの自作機でiMac20,2を選ぶことのメリットは特にありませんので、iMac20,1を選んでおくのが良いと思います。\nDummyPowerManagement の場所が変更されたようです。手元の環境では使っていなかったので気づきませんでした。コメントで教えていただきました。config.plistの中のこの設定が、Kernel \u0026gt; Emulate Propertiesに移動しています。このフラグでPower managementをoffにしている場合は、config.plistを更新する必要があります。\nConfig.plistはこちら その後、OpenCoreに付属のSample.plistを見ながら、新しく追加された項目も含んだconfig.plistを作り直しました。ASUS Z390 ROG MAXIMUS XI + 9900K + RX580の構成のconfig.plistはこのようになりました。\nconfig.plist for ASUS Z390 OC060 - Pastebin.com\n一方、ASUS Z490G + 10900K + RX5700XTの構成のconfig.plistは以下です。\nconfig.plist for ASUS Z490 10900K OC062 - Pastebin.com\nいずれもPlatformInfoの項目は未記入ですので、macserialなどを使って生成してください。\n","date":"2020-10-06T21:39:32+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/10872/","title":"OpenCore 0.6.1から0.6.2に更新"},{"content":"\nCatalina 10.15.7が動いているZ390 + 9900Kマシンで、ポインターが虹色円盤になり動作不能に陥りました。先日のアップデートの副作用のようで、再起動したら治りました。10.15.7 Comboアップデートを当てておきました。再発しないかどうか様子見します。\n症状 突然、Catalina 10.15.7が動いているマシンで、ポインターが虹色円盤になり、文字入力がほとんど動かなくなり、ほぼ動作不能に陥りました。いわゆるSpinning wheel of deathです。アクティビティモニターで調べてみると、accountsdというデーモンがしきりに稼働していて、このデーモンだけでCPU使用率が700%近くになってました。マシンはこちらで作成したZ390 + 9900Kの構成です。\nmacOS Catalina 10.15.7 (19H2) ASUS ROG MAXIMUS XI HERO (Z390) 9900K OpenCore 0.6.1 kext類は最新 とりあえず再起動したところ治りました。スクリーンショットを撮っておけば良かったですが忘れてました。Hackintoshしている弱みで、トラブルがあるとついついhackintoshの動作と設定を疑ってしまうのですが、どうやら最近話題になっているアップデートの副作用のようです。フォーラムでまっくぷろさんに紹介されているのを見て気づきました。ネットで紹介されている症状とほぼ同じでした。\n対策？ ネットの情報では、10.15.7 Comboアップデートを当てると効果があるようです。古い設定を捨ててくれるのかもしれないです。ということで、AppleのサイトからComboアップデートをダウンロードして、インストールしておきました。ビルド番号は19H2と変わらないです。再発するかどうか様子見します。\nDownload macOS Catalina 10.15.7 Combo Update\n","date":"2020-10-05T22:17:00+09:00","image":"/uploads/2018/05/20180522163728.png","permalink":"/posts/10861/","title":"accountsdが暴走してCPU使用率700％"},{"content":"Beta 9がパブリックベータとして公開されたので、Beta 6からアップデートしました。ビルド番号は20A5384cです。Radeon 5700XTの性能がかなり向上しました。Z490, 10900K, OpenCore 0.6.1の環境で快適に動作しています。\nインストール手順 前回の記事で入れたBeta 6マシン（Z490 + 10900K + 5700XT）\nmacOS Big Sur 11.0 Beta 6 をインストール\nのソフトウェアアップデートにmacOS Big Sur Betaの案内が来ていました。\nこのMac用のアップデートがあります ・macOS Big Sur Beta 9 11.0 という表示です。Beta 6からBeta 9に飛んだのは、パブリックベータだからだと思います（もしかしたら途中のアップデータに気づかなかったのかもしれませんが）。\n早速「今すぐアップデート」ボタンを押したのですが、ダウンロードが開始した後で、「インターネットの接続を確認してください」というようなエラーが出て進まなくなりました。夢日記で紹介されている状況とおそらく同じだと思います。さらに、別のCatalinaマシンもベータテスターに登録しているので、こちらでもダウンロードを試みましたが、やはりネットが不調というメッセージで止まります。\nサーバが不調なのかと思い、一晩待ちましたがやはり同じエラーでした。そこで、ベータテストのサイトからmacOSPublicBetaAccessUtility.pkgをダウンロードし直して、インストールし直したところアップデートが進みました。自動的に何回か再起動して、問題なくアップデートが完了しました。一方のCatalinaマシンも、macOSPublicBetaAccessUtility.pkgを入れ直すことでダウンロードが成功しました。原因は不明ですが、何らかのアクションをすると改善するようです。\nインストールが終わったBig Sur Beta 9はとても快適です。この分ならメイン環境として使っても良いと思いました。OpenCoreなどのバージョンは以下のとおりです。\nOpenCore 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の結果も掲載しました。\nRadeon 5700XTの性能がかなり改善されています。Beta 6では、RX 580と比較して、OpenCLでは優っているもののMetalで負けていました。Beta 9ではBeta 6より2~3割改善されて、OpenCLもMetalもどちらもRX 580のスコアを上回りました。5700XTの性能をようやく引き出せるようになったようです。\n","date":"2020-10-02T17:52:06+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/10829/","title":"macOS Big Sur 11.0 Beta 9 をインストール"},{"content":"OpenCoreの0.6.1が公開されたので0.6.0からアップデートしました。Big Surに対応してComet Lakeに対応したところが大きな変更点かと思います。0.0.1の違いなので新しくなったファイルを差し替えただけで移行できました。\n0.6.1をダウンロードする 公式のダウンロードページは以下です。Kext Updater.appがダウンロードしてくれる内容を使っても良いです。\nReleases · acidanthera/OpenCorePkg\nEFIファイルを差し替える 現在0.6.0が動いている状態でしたら、0.6.1に含まれる.efiファイルを、0.6.0のものと差し替えることでアップデートできます。具体的には以下のファイルです。まずはBOOTの中のBOOTx64.efiです。\n次に、OC直下のOpenCore.efiです。\nまた、OC/Bootstrap/の中のBootstrap.efiも差し替えます。\nOC/Driversの中のうち、現在使用しているものだけを差し替えました。手元のマシンでは、OpenCanopy.efiとOpenRuntime.efiだけを使っているので、それを差し替えました。\nOC/Toolsの中も、使用しているものだけ差し替えれば良いです。手元では、OpenShell.efiだけを使っているので、それを差し替えました。\nACPIとKextsは、OpenCoreの範疇では無いので、変更不要です。また、config.plistも変更無しでそのまま動きました。OpenCoreに付属している差分を説明するファイルや、インストールガイドのページを見ても、書き換えるべきconfig.plistの項目はなかったように思います。\niMac20,1に対応 0.6.1で最新のComet Lake-S CPUを搭載したiMac20に対応しました。最新パーツで組む場合にはありがたいところです。付属しているmacserialコマンドでも、iMac20,1と20,2のシリアル番号とボードシリアル番号の対を生成できるようになっています。\n% ./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を選んでおくのが良いと思います。\n","date":"2020-09-10T22:23:35+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/10684/","title":"OpenCore 0.6.0から0.6.1に更新"},{"content":"Beta 6が公開されたのでアップデートしました。ビルド番号は20A5364eです。Beta 5では起動で失敗していたComet Lake-Sで、Beta 6は動きました！また、Catalinaに比較してRadeon 5700XTの性能が向上していることを確認しました。\nインストール手順 前回の記事では、createinstallmediaコマンドを使ってインストール用USBメモリを作成し、それで起動してSSDにインストールしました。今回はUSBメモリを作るのが面倒だったので、真っ新な2.5インチSATA SSD（今回は250GB）をCatalinaマシンに接続し、フォーマットし、macOS Big Surベータ版インストール.appから直接インストールしました。\nこのSSDを、Catalinaマシンに接続したまま、Catalinaが入っているESPの中のOpenCoreで起動します。そして起動ボリューム選択画面で、Big SurをインストールしたこのSSDを選択して起動しました。Beta 5に引き続き、Prebootという分かりにくい名前で現れています。Prebootの右に見えるMacintosh HDというドライブは、いつも起動しているCatalinaのボリュームです。\nZ490で動きました 前回の記事でBeta 5が既に動作していたZ390上のCoffee Lake-Sマシンでは、Beta 6も引き続き問題なく起動しました。一方で、Beta 5が動かなかったZ490上のComet Lake-Sでも、Beta 6ならば起動しました。このマシンです。\nASUS ROG STRIX Z490-G, 10900K\nESPの構成は以下です。config.plistも、Catalina 10.15.6を起動させている状態のそのままです。\nOpenCore 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が動いてすぐに\n[EB|#LOG:EXITBS:START] という表示で止まってしまい、起動しませんでした。このメッセージで止まることへの対策を色々試みたのですが、解決しませんでした。それがBeta 6にしたら、何の問題もなく起動しました。Beta 6はComet Lake-S搭載のiMac 2020に対応したという話をコメントで教えていただきました。Hackintoshなのが原因ではなく、もともと今回でComet Lake-Sに対応したということだったのかもしれません。\n5700XTの性能が向上 このComet Lake-Sマシン (CPUは10900K) にはRadeon 5700XTを取り付けてあります。その性能を測定しました。下のグラフはCatalina 10.15.6とBig Sur Beta 6との比較です。OpenCLとMetalでそれぞれ3回測定した結果を平均しました。さらに比較のために以前紹介したCatalina 10.15.5でのRX 580の結果も掲載しました。\nRadeon 5700XTは、RX 580と比較して、OpenCLでは優っているもののMetalで負けているという状態でした。その傾向は変わらないのですが、Big Surになってそれぞれ10%程度性能が向上しているようです。\n","date":"2020-09-09T22:40:47+09:00","image":"/uploads/2020/09/bigsur512.png","permalink":"/posts/10673/","title":"macOS Big Sur 11.0 Beta 6 をインストール"},{"content":"ようやくBig Surを入れました。Public Beta Programで現在配布されているBig Sur 11 beta 5 (20A5354i) です。Catalinaを動かしているZ390マシンの、OpenCoreとその設定が入っているESPから起動して、すんなり動きました。この記事もBig Surで書いてます。この調子ならBig Surへのアップデートも順調に行えるように思います。\nダウンロード Catalinaを動かしているZ390マシンをPublic Beta Programに登録し、システム環境設定のソフトウェアアップデートからダウンロードしました。デベロッパー向けにはbeta 6 (20A5364e)が既に出ているようですが、Public Betaはbeta 5のようです。ダウンロード後にインストーラが起動しますが、それは中断します。ApplicationフォルダにmacOS Big Surベータ版インストールというアプリケーションができています。\nインストール用USBメモリを作る 次に32GB容量のUSBメモリを用意しました。これをフォーマットし、ここではusbという名前をつけました。ターミナルでmacOS Big Surベータ版インストールの場所にcdします。この中のContents/Resourcesの中に\n% cd /Applications/Install\\ macOS\\ Big\\ Sur\\ Beta.app/ % cd Contents/Resources/ お馴染みのcreateinstallmediaコマンドがあります。オプションなしで起動すると、ヘルプが表示されます。\n% ./createinstallmedia Usage: createinstallmedia --volume \u0026lt;path to volume to convert\u0026gt; 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を指定すると、インストール途中でネットにアクセスする必要がないような説明がされているので、これは使うことにします。そこで、\n% sudo ./createinstallmedia --volume /Volumes/usb --downloadassets とタイプします。これで用意したusbメモリが初期化されて、そこにBig Surのインストーラが作られます。\nUSBメモリから起動する 実際のMacなら、このUSBメモリで起動して、インストールをすることができます。Macでの動作を確認しました。インストール途中で再起動するときに、中間のボリュームの名前がいつもと違って「EFI」というように表示されて違和感がありました。この後で行ったhackintoshへのインストールでも後述のように、名前がおかしかったです。ベータ版なので、後に改善されると思います。\nUSBメモリを起動したhackintoshは、こちらで紹介したZ390マザーボードの構成です。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\nESPの構成は以下です。通常は最新版のCatalinaを起動させています。\nOpenCore 0.6.0 (一般公開されている最新バージョンです) kext類は一般公開されている最新のもの 機種設定はiMac19,1 このESPから起動し、OpenCoreのメニューからBig Surインストール用USBメモリを選ぶと、インストーラが起動しました。\nSSDを用意してインストール インストール用に、余っていた64GBの2.5インチSSDを用意しました。これをUSB接続のHDDケースに入れて、USB接続しました。Big Surインストール用USBメモリで起動すると、そこからDisk Utilityを起動できるので、これを使ってSSDをAPFSでフォーマットします。フォーマットが終わったらインストーラプログラムに戻って、SSDにインストールをします。\nインストール途中で再起動を求められます。NVRAMが機能していれば再起動時に選択すべきドライブがデフォルトで選択されているのですが、場合によってはOpenCoreやCloverの起動ボリューム選択画面で選択する必要があります。\n最初の再起動では、macOS Installerというボリュームが見えたので、それを選択しました。これでインストールが正しく進みました。今まではBoot macOS Install from xxxxというような名前のボリュームを選ぶことになったので、少し違った様子です。\n次の再起動では、さらに悩みました。Prebootというボリュームが見えていて、これを選択するのが正しかったです。従来は、PrebootはFileVaultのログイン用に使うボリュームだと思っていたのですが、今回は違うようです。\nボリュームの名前に関しては、前述のように実機でも同じようにわかりにくい不具合（実機ではEFIという名前になってました）があります。公開バージョンになれば改善されると思います。Mifjpnさんのブログに、再起動時に選択肢が現れない場合への対処法や、Prebootから改名する方法などが紹介されています。\nインストール後のBig Sur起動ディスクの容量は40.05GBでした。64GB SSDで十分でした。今回使用した64GB SSDは骨董品なので180MB/sくらいしか読み取り速度が出ないのですが、最近だとこれより高速な64 GB USBメモリーが1,000円台で買えるのですね。\nBig Surで起動 Prebootから起動すると、いつものような設定画面を経て、Big Surが起動します。デフォルト壁紙が、今までの写真から、カラフルな絵に変わって、新鮮な感じです。少し操作を試しましたが、特に問題はないようです。サクサクといつものように動作します。この調子ならば、例年のようにスムーズにバージョンアップが出来そうです。\nおまけ：Z490では苦戦中 こうして動かしたSSDを、Z490のマシン\nASUS ROG STRIX Z490-G, 10900K\nで動かそうとしたのですが、こちらは、OpenCoreが動いてすぐに\n[EB|#LOG:EXITBS:START] という表示で止まってしまい、起動しません。Catalinaは問題なく起動するのですが、なぜかBig Surだと起動しません。こちらのトラブル対策を試してはいるのですがまだ解決していません。メモリーマップが変わったのかなとは思ってます。\n追記：Beta 6になったらZ490マシンで動くようになりました。\nmacOS Big Sur 11.0 Beta 6 をインストール\n","date":"2020-09-05T19:23:54+09:00","image":"/uploads/2020/09/install_bigsur.png","permalink":"/posts/10623/","title":"macOS Big Sur 11.0 Beta 5 をインストール"},{"content":"Comet Lake-S搭載自作PCの機種IDを、iMac 2020に合わせてiMac20,1に設定しました。iMac 2020が発売されたばかりなので、現バージョンのOpenCoreとmacserialがiMac20,1に未対応です。そこでGitHubから最新版を入手して、MLB情報を追加して、ビルドしました。\nOpenCoreをビルドする 先の記事で紹介したように、第10世代Comet Lake-S搭載のマシンは、iMac 2020に合わせてiMac20,1に設定するのが良いと思います。最新のmacOS 10.15.6 (19G2021)は、iMac20,1に対応しています。でも現在のOpenCore 0.6.0は、iMac 2020が発売される前のバージョンなのでiMac20,1に対応していません。\nOpenCoreは現在0.6.1の開発が進んでいて、GitHubでソースコード一式を入手できます。後で詳しく説明しますが、0.6.1ではiMac20,1, 20,2の機種IDに対応しつつあります。なのでこれをビルドすれば、対応したOpenCoreを入手できます。\nGitHub - acidanthera/OpenCorePkg: OpenCore bootloader\nOpenCoreのビルドはやったことがなかったのですが、いつもコメントを書いていただいているMifjpnさんのサイトの記事を見て、試してみました。最初はいくつかのツールをダウンロードすることになりましたが、基本的には自動で簡単にビルドできました。\nデイリービルドの日々・・・Big Sur Betaが終わるまで\nビルドした結果は、こちらに置いておきました。後で説明するiMac20,1対応のmacserialも含まれています。\nOpenCore-0.6.1-RELEASE.zip\nこれでiMac20,1に対応したmacserialとOpenCoreが得られます。そこで、macserialでiMac20,1のシリアル番号を生成して、これをconfig.plistに書き込み、OpenCore 0.6.1を使えば、iMac 2020に相当するマシンになります。\nここから先は、ソースコードの細かい話ですので、興味の無い方は、「IDを生成する」の節まで飛ばしてください。\nmacserialとOpenCore Hackintoshのconfig.plistに書くべきシステムシリアル番号、ボードシリアル番号 (MLB) などを自動生成してくれるツールにmacserialがあります。以前の記事でも紹介しました。macserialのソースコードは、今は同じacidantheraさんが管理するOpenCoreのソースに組み込まれています。以前のmacserialの部分は、OpenCoreのUtilitiesディレクトリに収められています。\nmacserialは、機種ID、シリアル番号の規則、MLBの規則などの様々なMacの機種情報を把握した上で、シリアル番号などを自動生成しています。Macの機種情報は、従来はmacserialのヘッダファイルに手作業で書き込まれていました。しかし今は、OpenCoreのAppleModelsというディレクトリの中で、MacBook, iMacなどの種類ごとにテキストファイルで書き込まれています。機種情報は、macserialだけでなくOpenCoreパッケージの他のプログラムでも利用されています。なので、config.plistに個体特有の機種情報を書くだけで、それ以外の機種共通の情報、例えばBoard IDやファームウェアバージョンなどは、自動的に用意されるのです。\niMacの情報は、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もビルドできます。\nmacserialを使ってみる この記事を書いている時点で配布されているmacserialを使ってみると、生成されるiMac20,1, 20,2のMLBが不完全でした。例えば、iMac20,1のシリアルとMLBを生成すると、以下のようになります。\n% ./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が書き込まれているからです。\nMLBを見つけてくる シリアル番号とMLBを生成するためには、実機のiMacの番号を見つけて、それから機種固有のコードを知る必要があります。上の例で、シリアルに共通しているのはPN5Tという下4桁の部分で、これが機種固有のAppleModelCodeです。シリアル番号は、以前の記事でも紹介したように、ネットを探すとわりと簡単に見つかります。「このMacについて」にシリアル番号が表示されるからです。これに対してMLBは簡単には表示されません。なのでGitHubに機種情報を書いてくださった方も、ネットからわかる範囲でDataBaseを用意してくれたので、生成されるMLBの一部が0000になってしまっています。\nということで酷暑の中、iMac 2020が展示されているお店を巡ってMLBを調べてきました。大都会のアップルストアに行ければ良かったのですが、近場の量販店に置いてあったのはどこも10500搭載モデルが1台だけでした。つまりiMac20,1だけでした。そのMLBを調べた結果、いずれの展示品iMacのMLBも、AppleBoardCodeの部分はPHCDでした。ちなみに、シリアルのAppleModelCodeはどれもPN5Tでした。貴重な情報を得られたので、お礼に買い物もしてきました。\nmacserialをビルドする このAppleBoardCodeを\nOpenCore/AppleModels/DataBase/iMac/IM201.yaml に書き込みます。以下のようになります。\n# Note, first model code is used by macserial AppleModelCode: - \u0026#34;PN5T\u0026#34; - \u0026#34;PN5Y\u0026#34; - \u0026#34;PN5X\u0026#34; - \u0026#34;PN5W\u0026#34; - \u0026#34;PN5V\u0026#34; - \u0026#34;PN78\u0026#34; - \u0026#34;PN7D\u0026#34; - \u0026#34;PN77\u0026#34; - \u0026#34;PN7C\u0026#34; # Note, first board code is used by macserial AppleBoardCode: - \u0026#34;PHCD\u0026#34; ちなみに現時点でAppleModelCodeは9個登録されています。9個あっても、コメントにあるように、シリアル番号生成には最初の1個だけが使用されます。なので、特定のAppleModelCodeを使いたかったら、それを最上位に移動しておくと良いです。この後、\nOpenCore/AppleModels/update_generated.py を実行します。このコマンドでmacserialの機種情報ヘッダファイル、modelinfo_autogen.hが更新されます。README.mdにあるように、yamlを解釈するPythonライブラリであるpyyamlを事前にインストールしておく必要があります。\nこの後、OpenCore全体をビルドすればmacserialもビルドされてiMac20,1対応になります。macserialだけをビルドするのであれば、ターミナルで\nOpenCore/Utilities/macserial に移動し、\nmake とタイプすると、macserialをビルドできます。makeするための条件を満たすために、\ntouch macserial.c としてソースファイルの日付を更新しておく必要があるかもしれないです。\nIDを生成する こうしてビルドした新macserialを使えば、以下のようにAppleBoardCodeがPHCDのMLBを生成してくれます。これをconfig.plistに書き込めば良いです。\n% ./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日なので、この記事の時点で妥当な値です。\nOpenCore 0.6.1に反映されました この記事を書いている間に、今回紹介したAppleBoardCode情報がOpenCore 0.6.1に反映されました。GitHubに出してあったpull requestをvit9696さんが受理してくれました。たったの4文字だけですがOpenCoreに貢献できて嬉しいです。\nまとめ iMac20,1のMLBを街で探して、OpenCoreのソースに反映しました。これでiMac20,1のシリアル番号と完全なMLBが作れるようになります。これらをconfig.plistに書き込み、OpenCore 0.6.1とmacOS 10.15.6 (19G2021) でComet Lake-S自作機を動かしていますが、今のところ問題はありません。\n","date":"2020-08-23T00:49:27+09:00","image":"/uploads/2020/08/Apple_imac-magickeyboardnum-magicmouse2-macos-wallpaper_08042020.jpg","permalink":"/posts/10572/","title":"自作PCにiMac20,1のシリアル番号を設定する"},{"content":"第10世代CPU, Comet Lake-Sで自作したら、機種IDはiMac20,1にするのが良いと思います。iMac 2020に搭載されるComet Lake-S CPUの全てに適用されるIDだからです。ただ、Radeon RX 5700 XTなどを使用する場合は、類似GPUを搭載するiMac20,2の方が性能を引き出せる可能性も無いとは言えません。でも、実測したところ性能に違いはありませんでした。\niMac 2020には2種類の機種IDがある 前回の記事で紹介しましたように、iMac 2020には、iMac20,1とiMac20,2の2種類の機種IDがあります。ここでは、Comet Lake-Sの自作PCでmacOSマシンを作る場合、そのどちらを使用したら良いかをさらに考えてみます。\niMac20,1とiMac20,2の違い\nとりあえずは全てのComet Lake-Sモデルが対象になっているiMac20,1にしておくのが良いと思われます。特に10500や10600などを使う場合はiMac20,1にすべきでしょう。また多くの人がiMac20,1に設定すると思われるので、iMac20,1にしておけば、トラブル解決情報も容易に得られると思います。\nただ、iMac20,2はRadeon Pro 5700とPro 5700 XT搭載モデルなので、よく似た型番のRadeon RX 5700とRX 5700 XT搭載グラフィックスカードを使用する場合だけに関しては、iMac20,2の方が適切なのかもしれない、とも考えられます。もしかしたらiMac20,2にした方が、5700 (XT)のグラフィックス性能がより引き出せるのかもしれません。そこで今回は、RX 5700 XT搭載マシンで、性能差を検証しました。\niMac20,1と20,2でベンチマーク 機種IDをiMac20,1もしくはiMac20,2に設定するためには、それぞれのシリアル番号などを正しく生成して、対応したmacOSとOpenCoreを使用するのが良いです。この話題については次の記事で紹介します。\n今回のベンチマークで使用したマシンは、こちらで紹介したものを基にして、さらにCPU, macOSとOpenCore, kext類をアップデートしてあります。\nASUS 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の違いだけに注目します。\nその結果、iMac20,1とiMac20,2では差がないことが判明しました。むしろiMac20,1の方が多少良いくらいです。ただ、個々のスコアを見ると、それぞれ逆転しているスコアもあり、違いは誤差範囲かと思われます。\nまとめ Radeon RX 5700 (XT)を使用した場合、iMac20,2に設定した方が性能を引き出せるのかどうかを検証しました。その結果、iMac20,1との差はありませんでした。第10世代で自作するなら、どの構成でも、機種IDはiMac20,1にすれば良いと思います。\n","date":"2020-08-22T12:34:43+09:00","image":"/uploads/2020/07/10900K.jpg","permalink":"/posts/10541/","title":"第10世代自作PCの機種IDはiMac20,1が良い"},{"content":"Comet Lake-S搭載のiMac 2020には、iMac20,1とiMac20,2という2種類のModel IDが存在します。Geekbench Browserなどからの類推によると、どうやらRadeon Pro 5300と5500 XTを搭載したモデルがiMac20,1で、5700と5700 XTを搭載したモデルがiMac20,2のようです。\nCPUが違う？ こちらで、iMac20,1と20,2の違いが議論されていました。Geekbench Browserで確認すると、iMac20,1に搭載されるCPUは以下の4種類があり、iMac 2020に搭載されてる全てのCPUを網羅しています。\n10500 10600 10700K 10910 一方でiMac20,2に搭載されるCPUは以下の2種類だけです。\n10700K 10910 なので10700Kと10910搭載iMacには、iMac20,1と20,2の2種類のハードウェアが存在することがわかります。その違いが性能差に現れるかどうかをGeekbench Browserで検索して調べてみました。すると、同じCPUでCPU Resultsを比較すると、若干iMac20,2の方が高いような気もしますが、逆転している結果もあります。たとえば、10910を搭載したiMac20,1と20,2を検索して比較すると、スコア10,000超えはなぜか全て20,2ですが、それ以下のスコアでは両方のIDが入り乱れて競っています。Model IDによるCPU性能の違いはあまり無いようです。\nGPUが違う。 一方でMetalとOpenCLのスコアを比較すると、iMac20,2がiMac20,1を明らかに上回っています。たとえばOpenCLで比較すると、20,1のスコアは36,000から50,000くらいなのに対して、20,2は44,000から61,000くらいです。このことからModel IDの違いは、GPUの違いなのではと言われています。つまり、iMac20,1は、\nRadeon Pro 5300 Radeon Pro 5500 XT を搭載していて、iMac20,2は\nRadeon Pro 5700 Radeon Pro 5700 XT を搭載しているようです。\n仕様で確認 Appleの仕様ページをもとにすると、この結果から以下のように分類できます。これから10500, 10600搭載のiMacは必ずiMac20,1であることが確認できます。10700K搭載iMacは、搭載GPUの違いによってiMac20,1とiMac20,2の両方の可能性があります。また10910へは、どのGPU搭載モデルからもアップグレード可能なので、これにも両方のModel IDが存在します。\nどちらのIDを使うべきか この推測が正しいとしたら、自作PCにはどちらのIDを割り当てるべきでしょうか。\nまず、10500や10600で組む場合には、おそらくiMac20,1が良いと思います。そのまま、将来10700Kや10900Kなどにアップグレードする場合も、iMac20,1を使い続けて良いはずです。\n一方、10700Kや10900Kなどで組む場合には、20,1でも20,2でもどちらでも良いと思います。グラフィックスカードに、Radeon RX 5700や5700 XTを搭載する場合には、もしかしたら20,2の方が良いのかもしれません。ただ、Radeon ProはApple専用の特別版（クロック低下版）で、市販のRadeon RXとは同一ではありません。なのでこだわる必要はそれほど無いかもしれないです。MacRumorsの議論にあるように、20,2はおそらくは、高性能GPUのために電源、冷却機構などのハードウェアを対応させた程度の上位バージョンで、macOSとしての対応は変わらないのではないかと思います。\nということで、自作PCに対しては、iMac20,1を割り当てておけば良いと思います。\n","date":"2020-08-18T23:43:32+09:00","image":"/uploads/2020/08/Apple_imac-magickeyboardnum-magicmouse2-macos-wallpaper_08042020.jpg","permalink":"/posts/10515/","title":"iMac20,1とiMac20,2の違い"},{"content":"ネット上にある開封動画から、iMac 2020のシリアル番号のフォーマットを解析しました。以下の記事のこの部分に追記しました。\n第10世代CPU搭載iMac登場\nロジックボードのシリアル番号 (MLB) を生成するには、MLBの下6-3桁 (AppleBoardCode) が必要のようです。こればかりは実機で調べてこないとわからないかな。\n","date":"2020-08-08T18:51:08+09:00","image":"/uploads/2020/08/Apple_imac-magickeyboardnum-magicmouse2-macos-wallpaper_08042020.jpg","permalink":"/posts/10453/","title":"iMac 2020シリアル番号の仕組み"},{"content":"\nOpenCore 0.6.0が出たので、ASUSのZ490マザーボードのオーディオを再設定しました。OpenCore 0.6.0とAppleALC.kext 1.5.1がZ490マザーボードに対応したことから、PCI IDを偽装しなくても動くようになりました。\n今までの設定 前回は、OpenCore 0.5.9を使ってZ490マザーボード搭載コーデックを動かしました。特別な設定不要で音が出たASUSの先代Z390マザーボードには、ASUSの仕様書によると、オーディオユニットにはSupremeFX S1220という名前が付けられています。Hackintoolなどで調べるとコーデックはRealtekのALC1220のようです。Z490マザーボードになって、これがSupremeFX S1220Aになってました。HackintoolではRealtek ALCS1220Aになっています。SやAが追加されていますが数字部分は同じなのであまり変わらないと思ったのでしたが、デバイスIDを偽装する設定を行わないと、音が出ませんでした。\nASUS ROG STRIX Z490-G GAMINGの音とLANを動かす\nここに書きましたように、kextに、\nFakePCIID.kext FakePCIID_Intel_HDMI_Audio.kext を入れ、さらにconfig.plistでデバイスIDを指定し、レイアウトIDを7に指定する必要がありました。\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1F,0x3)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;cKEAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;layout-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BwAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; OpenCoreとAppleALCの最新版を使う OpenCoreが0.6.0になり、またAppleALC.kextが1.5.1になり、その両方の資料で、Z490マザーボード搭載オーディオに対応したとの記述を見つけました。ならば、FakePCIIDを使わなくても音が出るようになったのかと思い、試してみました。\nまずはAppleALC.kextだけ更新しました。それでFakePCIID_Intel_HDMI_Audio.kextを外してみました。FakePCIID.kextは、Ethernetチップを動かすためにも必要なので、外してません。でも音は出ませんでした。そこでOpenCoreも0.6.0にアップデートしました。0.5.9から0.6.0へのアップデート作業は、こちらをご覧ください。\nOpenCore 0.5.9 から 0.6.0 に更新\nAppleALCとOpenCoreの両方をアップデートしたところ、FakePCIID_Intel_HDMI_Audio.kext無しで、config.plistにもデバイスIDを書かなくても、音が出ました。config.plistの該当部分は、こんな感じになりました。\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1F,0x3)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;layout-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BwAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; レイアウトIDは必要です。このマザーボードは7でしたので、それがBase64形式で書いてあります。\nまとめ ということで、OpenCoreとAppleALCの現行バージョンなら、レイアウトIDの指定だけで、何も特別なことをしなくてもZ490の音が出るようになりました。コメントでもOpenCoreとAppleALCの最新版でPCIIDの偽装が不要になったとの情報をいただいています。新型iMacで第10世代CPUが採用されたこともあり、これでZ490がさらに気軽に使えるようになったと思います。\n","date":"2020-08-06T21:56:56+09:00","image":"/uploads/2020/08/3gOQtse.jpg","permalink":"/posts/10361/","title":"ASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）"},{"content":"Comet Lake-Sを搭載した新しいiMacがようやく登場しました。Z490マシンのSMBIOS情報に早速にも反映させたいところですが、いつものようにスペックが謎です。そこで、わかる範囲でメモしました。明らかになり次第、更新していきたいと思ってます。情報ありましたらコメントでお知らせください。\nModel ID 今までの経緯からすると新27インチiMacのモデルIDは、iMac20,1になるのではないかと思います。と思って検索していたら、Appleの公式ページにiMac20,1とiMac20,2というモデル番号が出ていました。これによると27インチにはiMac20,1とiMac20,2の両方があるようです。どのCPUがどちらのIDになるのか知りたいところですが、20番になるのは確定です。またパーツナンバーはMXWT2xx/A, MXWU2xx/A, MXWV2xx/Aになるようです。\nIdentify your iMac model\n追記：Geekbench Browserのベンチ結果投稿によると、Core i5-10500, Core i5-10600, Core i7-10700K搭載モデルがiMac20,1で、Core i9-10910搭載モデルが20,2のようです。上位モデルが「,1」だったiMac 2019モデルとは逆ですね。\nCPU 新iMac 27インチには、ベースモデルが3種類、オプションで1種類、合計4種類があります。iMacの搭載CPUが何なのかあまり情報はありません。搭載CPUに興味があるのはhackintoshしている人たちだけなのかも。公開されているスペック情報も限られています。その公式情報によると搭載されているCPUの説明は以下のようです。\n3.1GHz 6コア第10世代Intel Core i5（Turbo Boost使用時最大4.5GHz） 3.3GHz 6コア第10世代Intel Core i5（Turbo Boost使用時最大4.8GHz） 3.8GHz 8コア第10世代Intel Core i7（Turbo Boost使用時最大5.0GHz） 3.6GHz 10コア第10世代Intel Core i9（Turbo Boost使用時最大5.0GHz） いつものようにコア数とクロック数しかわかりません。これだけの情報と、Comet Lake-Sとして公開されている情報からすると、6コアCPUと8コアCPUには、該当するクロック数のComet Lake-Sモデルがあります。なので、それぞれの機種のCPUは以下と思われます。\nIntel Core i5 10500 (65W) Intel Core i5 10600 (65W) Intel Core i7 10700K (125W) ? 最上位のCPUに関しては、北森瓦版で10910というモデルが紹介されていました。元記事はtom’s Hardwareです。10900Kと10900の中間のモデルだそうです。ベースクロックが3.6GHzというのは合っていますがTBの値が少し違います。でもこの可能性は高いと思います。\n追記：Geekbench Browserからの情報から10910なのは確実のようです\nIntel Core i5 10500 (65W) Intel Core i5 10600 (65W) Intel Core i7 10700K (125W) Intel Core i9 10910 (95W) Geekbench Browserで検索する Geekbench BrowserでiMac20,1を検索したところ、現時点で3件の結果が見つかりました。時間的にどれも同じ人が上げている様子です。Hackintoshである可能性もあるのですが、macOS 10.15.6のBuildが19G2005という見慣れない数値ですし、MotherboardのIDもそれっぽいので、いち早くiMac20,1を入手した人が動作させた可能性が高いです。これを見ると、3.8GHzマシン（ベースモデル最上位）のCPUは確かに10700Kのようです。\nGeekbench Browserで検索する（続報） その後、さらにGeekbench BrowserでiMac20の検索を試みました。投稿がさらに増えていました。この結果、全ての搭載CPUが判明しました。上の予想通りで、最上位モデルは、やはり10910だったようです。ということでGeekbench Browserから推測する搭載CPUとモデルIDは以下です。\nCore i5-10500 3100 MHz (6 cores) iMac20,1 BID=Mac-CFF7D910A743CAAF Core i5-10600 3300 MHz (6 cores) iMac20,1 BID=Mac-CFF7D910A743CAAF Core i7-10700K 3800 MHz (8 cores) iMac20,1 BID=Mac-CFF7D910A743CAAF Core i9-10910 3600 MHz (10 cores) iMac20,2 BID=Mac-AF89B6D9451A490B それにしても10500と10600の性能差が僅差で、逆転している報告も多いですね。搭載グラフィックスも同じだし、なんでこんな微妙な製品構成にしたのかな。\nGPU 上記のAppleのスペックページによると、GPUには\nRadeon Pro 5300 Radeon Pro 5500 XT Radeon Pro 5700 Radeon Pro 5700 XT が搭載されているそうです。多分新しいチップです。以前と同じくProは、同じ型番のRXシリーズのApple社用カスタムチップだと思います。例えばPro 5700 XTは、RX 5700 XTより省電力にしてiMacの筐体に収まるようにしたバージョンのようです。新GPUに関する記事がこちらにありました。これによると、例えばPro 5700 XTはRX 5700 XTに比べて、プロセッサユニット数は同じですが、性能が9.75TFLOPSから7.6TFLOPSに落ちているようです。おそらくクロック数を落として発熱を抑えて、iMac筐体に対応させたのではと思います。でもProとRXは、ハード構成は同じようなので、新iMacをサポートしたmacOS (19G2005 ?)で、RX 5700 XTの互換性が向上したらありがたいです。\n内部構造 分解記事と動画が上がっているようです。コメントで教えていただきました。\n[VIDEO] Unboxing \u0026amp; Teardown: The 27-inch iMac 5K (2020)\nSSDは半田づけで交換不可能ですが、CPUはソケット式で交換可能なようです。\nシリアル番号フォーマット シリアル番号の生成プログラムmacserialなどがまだ新機種に対応していませんので、新機種シリアル番号のフォーマットをぜひ知りたいところです。\nネットを徘徊していたら、開封動画がぼちぼち公開されていて、その中にシリアル番号を見せてくれている動画がありました。それからフォーマットを解析します。皆さんもネット上で新機種のシリアル番号を発見したらぜひコメントでお知らせください。\n10700K搭載モデル こちらは10700K搭載モデルのようで、C02CV0VDPN5Wという数値が読めます。この番号から、今まで通りの伝統的な12桁のシリアル番号フォーマットに従っているらしいことがわかります。それぞれの桁を調べると以下になります。フォーマットの詳細は、こちらの記事で紹介してあります。\nC02: 製造場所番号で、中国のQuanta Computer製造です。 C: 製造年。2019年でZまで使い切ったので2010年の表記 (CとD) に戻ったと思われます。2020年前半を示しています。 V: 製造週。24週目（後半なら50週目）を表します。つまり2020年の6月8日からの1週間に製造されてます。 XXX: 次の3桁は、製造ライン番号もしくは、組み立て担当者のIDです。製品個体ごとに異なる番号です。 PN5W: プラットフォームモデルです。製品の種類を表す番号です。この番号は、一つのModel IDに複数存在します。iMac20,1の一つのプラットフォームモデル番号はこの番号だとわかります。 こちらでも10700K搭載モデルの番号が読めます。C02D33YEPN5Wです。PN5Wが10700K搭載iMac20,1の番号なのは間違い無いです。\n10910搭載モデル こちらの動画では10コアモデルのシリアル番号が読めます。C02D2018046Tです。これによると、\nC02: 製造場所番号。中国のQuanta Computer製造です。 D: 製造年。2020年後半を示しています。 2: 製造週。28週目を表します。つまり2020年の7月6日からの1週間に製造されてます。 XXX: 次の3桁は製品個体ごとに異なる番号です。 046T: iMac20,2の一つのプラットフォームモデル番号はこの番号だとわかります。 こちらでも10910搭載モデルの番号が読めます。C02D5007090Yです。また、こちらにもありました。こちらは、C02D401H090Yです。090Yというプラットフォームモデル番号もあるようです。\n10500搭載モデル こちらの動画のAbout this Macでは、「3.1GHz六核」と読めるので、10500搭載モデルのようです。C02D4311PN5Tです。これから、\nC02: 製造場所番号。中国のQuanta Computer製造です。 D: 製造年。2020年後半を示しています。 4: 製造週。30週目を表します。つまり2020年の7月20日からの1週間に製造されてます。 XXX: 次の3桁は製品個体ごとに異なる番号です。 PN5T: 6コアiMac20,1の一つのプラットフォームモデル番号はこの番号だとわかります。 シリアル番号のまとめ 2020 iMacも従来通りのフォーマットのシリアル番号のようでした。また、プラットフォームモデル番号は、それぞれ、\nPN5T: Core i5-10500 3100 MHz (6 cores) iMac20,1 ????: Core i5-10600 3300 MHz (6 cores) iMac20,1 PN5W : Core i7-10700K 3800 MHz (8 cores) iMac20,1 046T, 090Y : Core i9-10910 3600 MHz (10 cores) iMac20,2 となります。10600搭載モデルが発見されていませんが、グラフィックスが同じなのでおそらく10500と同じなのではと思います。ただ、10600搭載モデルは10910に変更できるのですが、10500搭載モデルはできないのでもしかしたら違うかもしれません。10600の情報が欲しいですね。\nこれで、iMac20,1とiMac20,2のシリアルを作れます。上記の製造週と、製造ライン番号を少し変えれば良いはずです。ただ、製造ライン番号は、同じ数値に対して重複して存在するので、そのうちの適切な数値を選ぶ必要があります。他のModel ID用に生成ソフトで作った製造ライン番号を使うと良いと思います。\nまとめ 27インチ iMac2020に関して、仕様をまとめました。Geekbenchの情報は参考になりました。今のところ\nCPUは4種類 (10500, 10600, 10700K, 10910) GPUは4種類 (Radeon Pro 5300, 5500 XT, 5700, 5700 XT) Model IDはiMac20,1(下位3モデル)とiMac20,2(最上位モデル) Board IDはMac-CFF7D910A743CAAF (iMac20,1)とMac-AF89B6D9451A490B (iMac20,2) というようなことが判明してます。\n","date":"2020-08-05T23:28:12+09:00","image":"/uploads/2020/08/Apple_imac-magickeyboardnum-magicmouse2-macos-wallpaper_08042020.jpg","permalink":"/posts/10340/","title":"第10世代CPU搭載iMac登場"},{"content":"OpenCore 0.6.0が公開されたので、0.5.9から更新しました。まずは0.6.0になって更新されたファイルを差し替えるだけでもとりあえず動きました。次にconfig.plistを正しく変更しました。\nRelease 0.6.0 · acidanthera/OpenCorePkg\n使用したのは、ASUS Z390 ROG MAXIMUS XI HERO、Intel 9900K、 Radeon RX 580の組み合わせのこちらのマシンです。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\n更新ファイルだけ置き換える とりあえず、更新されたファイルだけ差し替えてみました。ESPの中身のうち、OpenCoreの配布物に含まれないファイルは0.5.9からそのまま引き継ぎました。0.5.9から引き継いだのは、\n最新にしてあったKextsフォルダの中身、 ACPIフォルダの中身はそのまま、 Resourcesの中身もそのまま、 とりあえず0.5.9のconfig.plistをそのまま使います。 0.6.0のファイルと入れ替えたのは、\nBOOTフォルダの中身 (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へは、何もしなくても移行できました。\nconfig.plistを正しく更新する 一応は動いたのですが、config.plistを正しく設定することにしました。OpenCore 0.6.0に付属しているsample.plistと現行のCoffee Lake-S用のconfig.plistをProperTreeを使って比較しました。変更点は以下のキーでした。\nBooter–\u0026gt;Quirks–\u0026gt;ProvideMaxSlide 0.6.0で追加されました。タイプはNumberです。デフォルトでは0で、sample.plistでも0が設定してあります。KASLRのスライド値の最大を決めるようです。デフォルトの0はスライドさせないという意味かと思います。使用しているマザーボード（ASUS Z390 ROG MAXIMUS XI）はスライド幅に余裕があった気がしましたので、最大の255に設定してみました。KASLRの考え方からして、スライド幅が大きいほどセキュリティが向上するはずです。今のところ問題なく起動しています。もしも起動失敗することがあれば減らせば良いです。KASLRとスライドについてはこちらの記事で説明しました。\nMisc–\u0026gt;Security–\u0026gt;BlacklistAppleUpdate 0.6.0で無くなりました。なので0.5.9のまま起動すると、画面に一瞬、BlacklistAppleUpdateに対するスキームが無いよというエラーメッセージが出ます。Appleのペリフェラルファームウェアのアップデートを無視する機能との説明です。指定する場所が、Misc–\u0026gt;Securityの場所から、次に説明するNVRAMに移動したようです。なので0.5.9のconfig.plistからこのキーを削除しました。\nNVRAM–\u0026gt;7C436110-AB2A-4BBB-A880-FE41995C9F82–\u0026gt;run-efi-updater 0.6.0で追加されました。上記のBlacklistAppleUpdateの代わりです。設定場所がこちらに移動しました。macOSのEFIファームウェアアップデートを上書きします。これをNoに設定すると、macOSのファームウェアアップデート機能を阻止します。APFSに移行した時に、EFIがAPFSから起動できるようにアップデートされたのですが、あのようなことを阻止する機能のようです。実機ではないhackintoshならばファームウェアが全く違いますからNoに設定するのが妥当です。\nUEFI–\u0026gt;APFS–\u0026gt;GlobalConnect 0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。0.5.9のconfig.plistにはありませんので、Falseとして追加しておきました。APFSドライバーをロードする時の、ハンドル（ポインターみたいなもの？）の扱いを、通常のやり方から再帰的なやり方に変更するオプションらしいです。これをTrueにすると起動に時間がかかるけど、古いHPラップトップがAPFSにアクセスするためには必要らしいです。なので古いHPラップトップ向けの設定ですね。\nUEFI–\u0026gt;Output–\u0026gt;UgaPassThrough 0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。これもデフォルト通り、Falseとして追加しておきました。GOPプロトコルの上にUGAプロトコルを提供すると、説明にあります。UGAは古いプロトコルなのでもはやサポートされていない場合もあるのですが、古いEFIではUGAが画面表示に必要なこともあるらしいです。EFIの画面表示に問題がなければFalseで良いようです。\nUEFI–\u0026gt;ProtocolOverrides–\u0026gt;AppleFramebufferInfo 0.6.0で追加されました。タイプはBooleanでデフォルトはFalseです。これもデフォルト通り、Falseとして追加しておきました。Apple Framebuffer Infoプロトコルをインストールし直す機能との説明です。VMや古いMacのフレームバッファ情報を上書きしてmacOS 10.4の古いEFIブートとの互換性を改善するとのことです。問題なければFalseで良いようです。\nまとめ OpenCore 0.5.9から0.6.0に移行しました。まずは新しくなったファイルを一つ一つ差し替えました。そのままで起動しました。次に、より正しく設定するために、config.plistを以下のように書き換えました。diffコマンドで0.6.0と0.5.9のconfig.plistを比較しています。\u0026lt;で示す行が追加した行で、\u0026gt;で示す行が削除した行です。\n% diff config_060.plist config_059.plist 197,198d196 \u0026lt; \u0026lt;key\u0026gt;ProvideMaxSlide\u0026lt;/key\u0026gt; \u0026lt; \u0026lt;integer\u0026gt;255\u0026lt;/integer\u0026gt; 648a647,648 \u0026gt; \u0026lt;key\u0026gt;BlacklistAppleUpdate\u0026lt;/key\u0026gt; \u0026gt; \u0026lt;true/\u0026gt; 704,705d703 \u0026lt; \u0026lt;key\u0026gt;run-efi-updater\u0026lt;/key\u0026gt; \u0026lt; \u0026lt;string\u0026gt;No\u0026lt;/string\u0026gt; 801,802d798 \u0026lt; \u0026lt;key\u0026gt;GlobalConnect\u0026lt;/key\u0026gt; \u0026lt; \u0026lt;false/\u0026gt; 872,873d867 \u0026lt; \u0026lt;key\u0026gt;UgaPassThrough\u0026lt;/key\u0026gt; \u0026lt; \u0026lt;false/\u0026gt; 907,908d900 \u0026lt; \u0026lt;key\u0026gt;AppleFramebufferInfo\u0026lt;/key\u0026gt; \u0026lt; \u0026lt;false/\u0026gt; ","date":"2020-08-05T00:11:54+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/10330/","title":"OpenCore 0.5.9 から 0.6.0 に更新"},{"content":"第10世代デスクトップCPU 10900Kを搭載したASUSのZ490マザーボードに、OpecCoreで起動するmacOS Catalinaをインストールしました。CPU, GPU, スリープ、Ethernet, サウンド, WiFiが全て動き、安定しています。間も無く登場すると言われているComet Lake-S搭載iMacに匹敵するマシンになると思います。\nハードウェア構成 こちらの記事で、10600を使ったhackintoshを作りました。これのCPUだけを10900Kに交換しました。他の設定は全く変更なく、引き続き動きました。\nComet Lake-S 10600とZ490でmacOSを動かす\nマザーボード マザーボードは、です。しっかりした作りでよくできています。販売サイトの製品写真ではバックパネルカバーのロゴが黄色です。でもこれはフルカラーLEDなので、Windowsからならば何色にも設定できると思われます。デフォルトでは時間と共に色が変化します。は2,000円安いです。WiFi用のM.2ソケットでBroadcomのカードが動くかと思ったのですが、これはCNVi専用でした。なのでWi-Fi無しの方が良かったかもしれないです。\nCPU 10900Kです。10コア20スレッドです。12面体という奇抜な外箱だった9900Kに比べて、普通のコンパクトな外箱になったと思っていたのですが、実物を見るとこれもなかなか奇抜でサイズ感がありました。微妙な角度でCPUが保持されています。\nGPU CPU内蔵のiGPUであるIntel UHD Graphics 630はほぼ稼働しました。ただし、Display Portのみが機能し、HDMIでは出力できないです。また、「画面共有」を設定しても他マシンから接続できませんでした。このCPUでiGPUを使い続けることはないと思うので、緊急用としたらこれで十分でしょう。\nそこで、PCIeスロットにグラフィックスボードを接続し、こちらを主に利用します。現在挿してあるのは、Sapphire NITRO+ ブランドのRadeon RX 580です。全く問題なく動いています。\nWiFi / Bluetooth BroadcomのBCM94360NGを使用してます。アンテナ端子は、マザーボードのバックパネルに取り付けてあります。詳細は、こちらをご覧ください。\nZ490マザボ搭載WiFiをmacOS対応品に交換する\nBIOS設定 BIOSの設定は、ほぼ工場出荷時設定で大丈夫です。Legacy USBをdisabledにするなど、やっておけば良い程度の変更をしました。デフォルト設定のままであってもmacOSの起動に支障をきたすことはありません。\nよくあることのようですがメモリーが2133MHzと認識されていました。2666MHzのメモリーなのでBIOSでそのように設定しました。メモリー速度設定はGeekbench 5のスコアに影響を与えます。\n使用したefiとkext ACPIには\nSSDT-AWAC.aml SSDT-EC-USBX.aml SSDT-PLUG.aml SSDT-RHUB.aml を入れました。Driversには、\nVBoxHfs.efi OpenRuntime.efi OpenCanopy.efi を入れました。Kextsには、\nAppleALC.kext FakePCIID.kext FakePCIID_Intel_I225-V.kext Lilu.kext SMCProcessor.kext SMCSuperIO.kext USBPorts.kext VirtualSMC.kext WhateverGreen.kext を入れました。このうち、macOSの起動に最低限必要なのは、以下の3個です。\nWhateverGreen.kext VirtualSMC.kext Lilu.kext USBPorts.kextは、USBを15個指定する自作kextです。なくても、USBポートの一部が動かないだけで、macOSの起動には問題ありません。作り方は以下をご覧ください。\nASUS ROG STRIX Z490-G GAMINGのUSBを設定する\nSMCSuperIO.kextとSMCProcessor.kextは、CPU温度などをモニターするkextです。これも特に必要なものではありません。使い方は以下をご覧ください。\nHWMonitorを使う\nFakePCIID.kext, FakePCIID_Intel_I225-V.kextの2個は、マザーボード搭載のEthernetチップを動かすために入れてあります。このマザーボードから新しくなったチップなので、偽装する必要がありました。将来的には不要になるかと思います。これも無くても、LANが動かなくなるだけで、macOSの起動には問題ありません。詳しくはこちらをご覧ください。\nASUS ROG STRIX Z490-G GAMINGの音とLANを動かす\nToolにはOpenShell.efiを入れました。ちなみにOSとブートローダは以下です。\nmacOS Catalina 10.15.6 OpenCore 0.6.0 config.plistを作る OpenCore配布パッケージにあるsample.plistを元に、変更を加えてconfig.plistを作っていきます。下記のComet Lakeガイドのページにほぼ従いました。\nDesktop Comet Lake | OpenCore Install Guide\nディスプレイの設定は、Radeonのグラフィックスボードを使うので、ヘッドレス用の以下の設定にしました。\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AwDImw==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; サウンドの設定はこちらをご覧ください。\nASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）\nここで使用したconfig.plistを以下で公開しておきます。シリアル番号などは有効な番号が入っていますが、ネットに接続する前に必ず自分用の番号に置き換えてください。\nconfig.plist for ASUS Z490G and 10900K - Pastebin.com\nシリアル番号などの作り方は、こちらをご覧ください。\nGenSMBIOSを使って機種情報を設定する\n動作確認 ほぼ問題なく動作します。動作確認したことは、\nスリープ iGPU (DisplayPortのみ。画面共有は不調) グラフィックスボード (RX 5700XTとRX 580で確認) WiFi/Bluetooth などです。このほかに問題はありません。\nベンチマーク Geekbench 5でベンチマークしました。マルチコアスコアで10,000超えが目標だったのですが、達成できました。\nちなみにCore i5 10600では6300くらいでした。コア数が6だったので、妥当な値でした。\n今回のスコアを実際のMacと比較すると14コアiMac Proと12コアMac Proの中間くらいです。クロックが高いのでコア数が多いMacに勝ってます。Apple Siliconが10,000超えのスコアを出してくれるまでは、Intel搭載デスクトップは安泰な気がします。\nベンチマークを動かしていた時のActivity Monitorです。20コアが働いてます。\niMac20,2が出ました（追記） Comet Lake-S搭載の27インチ iMacが発表されました。最上位モデルのCPUは10910のようです。Apple用のカスタムチップで一般には販売されないモデルです。10900Kと10900の中間の性能のようです。Geekbenchに上がっているスコアによると以下のようです。10900Kよりはクロックが低いので、スコアは10000前後ギリギリのようです。実機よりちょっと高いベンチマーク結果が得られるところが、自作PC hackintoshの醍醐味だと思います。\nまとめ Core i5 10600で動かしていたマシンのCPUを10900Kに交換しました。全く問題なく動きました。Geekbench 5でのマルチコアスコアは10,000を超えました。Comet Lake-S搭載のiMacが出たら、シリアル番号などをそれに合わせて設定し、本格的に使用したいと思います。\n","date":"2020-07-28T23:45:58+09:00","image":"/uploads/2020/07/DDR4_3600.png","permalink":"/posts/10236/","title":"ASUS ROG STRIX Z490-G, 10900K"},{"content":"OpenCoreでMacの起動音が出るようにしました。起動画面をGUI化した際にインストールしたリソースファイルに起動音のファイルも入っていました。これとAudioDxe.efiを用意し、config.plistに幾つかの設定をすることで、起動音が鳴りました。\n今回は、こちらの記事の続きです。\nOpenCoreの選択画面をグラフィカルにする\n少し前のMacでは起動音が出ましたが、煩わしいので消している人も多かったです。でも、最近のMacでは復活するという噂もあります。そうなると、起動音があっても良いのかなと思い、OpenCoreで試してみることにしました。今回も以下のガイドに従っています。\n制限 起動音は、macOSが起動する前に鳴らすので、macOSのドライバーは使えません。コミュニティの皆さんが頑張って作ってくれたドライバーで音を出します。なのでマザーボード上の音源チップからのみ音が出せます。つまり、以下の制限があります。\nUSBオーディオからは起動音を出せません。 GPUオーディオからは出せる場合もありますしダメな場合もあります。 実際のMacは電源を入れると即座に音が出ます。ファームウェアが音を出しているのでタイミングが早いです。でもHackintoshで起動音の出るタイミングは、電源を入れて、BIOSのスプラッシュ画面が出て、OpenCoreのメニュー選択画面になったところです。電源投入から少し待たされます。ここまで来て、制御がようやくOpenCoreに引き渡されるので、仕方がないところです。\n設定手順 音声ファイルを用意する メニューGUI化の時にアイコンファイルを入手したのと同様に、以下から音声ファイルを手に入れます。\nGitHub - acidanthera/OcBinaryData\nこのうち、OCEFIAudio_VoiceOver_Boot.wavが起動音のファイルです。これをOC/Resources/Audioの中に入れておきます。\nドライバーを用意する AudioDxe.efiをOC/Driversの中に入れておきます。AudioDxe.efiはOpenCoreの配布ファイルに含まれています。\nconfig.plistを設定する config.plistをProperTreeで開いて、設定作業を行います。まずはSnapshot機能でAudioDxe.efiを登録しておきます。次に以下の設定を行います。\nNVRAM -\u0026gt; Add -\u0026gt; 7C436110-AB2A-4BBB-A880-FE41995C9F82 -\u0026gt; SystemAudioVolume を0x46にする。10進数では70です。 UEFI -\u0026gt; Audio -\u0026gt; AudioSupportをTrueにする UEFI -\u0026gt; Audio -\u0026gt; MinimumVolumeを50にする UEFI -\u0026gt; Audio -\u0026gt; PlayChimeをTrueにする UEFI -\u0026gt; Audio -\u0026gt; VolumeAmplifierを143にする 数字のところはボリュームの設定なので適当で良いようです。ただ、適切な範囲や大小関係の制約はあるようです。\nここまではガイドの例に合わせて設定するだけなので簡単です。問題は、ハードウェアごとに調整しなければならない3個のパラメータです。UEFI -\u0026gt; AudioのAudioDevice、AudioCodec、AudioOutです。\nAudioDeviceを設定する PciRoot(0x0)/Pci(0x1f,0x3)に設定しました。オーディオチップに割り当てられたPCIeのパスを指定します。すでにconfig.plistのDevicePropertiesで、マザーボード搭載コーデックのレイアウト IDが指定してあれば、そこのPciRoot以下の数値です。下の例ならPciRoot(0x0)/Pci(0x1f,0x3)です。\n\u0026lt;key\u0026gt;DeviceProperties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Add\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1f,0x3)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;layout-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; HackintoolのPCIeボタンからAudio deviceを探して調べることもできます。\nまたgfxutilというツールを使っても良いです。これを起動すると出てくるHDEFの行に、チップのPCIeパスが書いてあります。\n% ./gfxutil | grep HDEF 00:1f.3 8086:a348 /PCI0@0/HDEF@1F,3 = PciRoot(0x0)/Pci(0x1F,0x3) AudioCodecを設定する 0に設定しました。オーディオチップのアドレスIOHDACodecAddressを設定します。これはioregコマンドやIORegistryExplorerなどで調べることができます。ガイドに従って、以下のようにioregコマンドをタイプしたところ、\n% ioreg -rxn IOHDACodecDevice | grep IOHDACodecAddress | \u0026#34;IOHDACodecAddress\u0026#34; = 0x0 | \u0026#34;IOHDACodecAddress\u0026#34; = 0x2 上のように、0番と2番の二つの選択肢がありました。ここでアドレスが1個しか出てこなければ、迷うことなくその数値（たぶん0です）をAudioCodecに書いておけば良いです。ちなみに0番と2番が出てきたマザーボードはASUS ROG MAXIMUS XI HERO Z390です。一方で、ASUS ROG STRIX Z490-Gのマシンでは、IOHDACodecAddressは一個（0番）だけでした。\n今回は2個の候補が出てきてしまったので、このどちらかを指定します。どちらかが、マザーボードに搭載されているコーデックです。ちなみにこのマザーボードのコーデックはRealtek ALC1220です。いろいろ調べる方法はあるようですが、ここでは以下のようにしました。まずは、grepの条件を緩めて、前後の情報を表示しました。\n% ioreg -rxn IOHDACodecDevice | grep IOHDACodec +-o IOHDACodecDevice@1F,3,0 \u0026lt;class IOHDACodecDevice, id 0x10000059d, registered, matched, active, busy 0 (1024 ms), retain 27\u0026gt; | \u0026#34;IOHDACodecVendorID\u0026#34; = 0x10ec1220 | \u0026#34;IOHDACodecRevisionID\u0026#34; = 0x100101 | \u0026#34;IOHDACodecAddress\u0026#34; = 0x0 +-o IOHDACodecDriver \u0026lt;class IOHDACodecDriver, id 0x1000005a5, !registered, !matched, active, busy 0 (1022 ms), retain 25\u0026gt; +-o IOHDACodecFunction@1F,3,0,1 \u0026lt;class IOHDACodecFunction, id 0x1000005a7, registered, matched, active, busy 0 (1022 ms), retain 27\u0026gt; +-o IOHDACodecDevice@1F,3,2 \u0026lt;class IOHDACodecDevice, id 0x10000059e, registered, matched, active, busy 0 (138 ms), retain 27\u0026gt; | \u0026#34;IOHDACodecVendorID\u0026#34; = 0xffffffff8086280b | \u0026#34;IOHDACodecRevisionID\u0026#34; = 0x100000 | \u0026#34;IOHDACodecAddress\u0026#34; = 0x2 +-o IOHDACodecDriver \u0026lt;class IOHDACodecDriver, id 0x1000005a6, !registered, !matched, active, busy 0 (135 ms), retain 25\u0026gt; +-o IOHDACodecFunction@1F,3,2,1 \u0026lt;class IOHDACodecFunction, id 0x1000005a8, registered, matched, active, busy 0 (135 ms), retain 25\u0026gt; これを見ると、下のIOHDACodecAddressが2番のもののVendorIDに8086という数値が見えます。これはインテル社のものです。一方で、0番には、VendorIDに10ecという数値が見えます。Vendor IDは世界的に決められている番号なので「vendor id 10ec」でGoogle検索すると、メーカの名前が分かります。これは、Realtek Semiconductor Co., Ltd.のIDだそうです。\nPCI Devices\nということで、これがRealtekのチップらしいので、AudioCodecには0番を指定すれば良いようでした。\nAudioOutを設定する 0に設定しました。こちらは苦労しました。この番号で、オーディオピンの番号を指定するようです。バックパネルにアナログ5本、SPDIFが1本、さらにはマザーボード上にケースのヘッドフォン端子に接続するオーディオ用ヘッダピンもあります。これのいずれかを番号で指定するようです。0番から順番に試すしかないようです。手元のマシンで0番を試したところ、それがバックパネルのスピーカ出力でした。\nまとめ OpenCoreで起動音を出せるように設定しました。ほとんどの作業は、バニラガイドに書いてある通りで簡単ですが、AudioDevice、AudioCodec、AudioOutの設定は、環境に合わせて変更する必要があります。特にAudioOutは手探りでした。起動音は、最後まで鳴る時もありますが、どういうわけか中途で音が出なくなることもあります。起動音がなると、さらに本物のMacっぽくなって良いのですが、ちょっと煩いかもしれません。しばらく楽しむけど、常用はしないと思います。\n","date":"2020-07-14T21:40:03+09:00","image":"/uploads/2020/07/chimewaveform.png","permalink":"/posts/9961/","title":"OpenCoreで起動音を鳴らす"},{"content":"\nASUSのZ490マザーボード のIntel製WiFi/BTモジュールをBroadcom製のBCM94360NGに交換しました。ただZ490から無線用M.2ソケットがCNVi専用になってしまいました。それでSSD用のM.2ソケットに、M Key, E Key変換M.2カードを使用して取り付けました。\nデスクトップでE Key M.2を使う macOSで使えるWiFi/Bluetoothモジュールは、こちらの記事で紹介してあります。\nHackintoshのパーツ選び 【その4：無線編】\n通常は、デスクトップマシンならPCIeスロット、ノートPCやミニPCならばM.2コネクタを使用して無線モジュールを取り付けるのが一般的です。とはいえ、デスクトップ構成でもPCIeスロットが使えない、もしくは温存しておきたい場合があります。特にmini ITXマザーボードにはPCIeが1本しかありません。これをmacOSでほぼ必須のグラフィックスボードに使用してしまうと、無線モジュール用のPCIeスロットがなくなってしまいます。その場合、M.2ソケットが空いていれば、それに無線モジュールを取り付けられます。\n非CNViにも対応したマザボ 市販のWiFi機能搭載マザーボードには、M.2ソケット方のWiFi/Bluetooth無線モジュールが搭載されています。バックパネルのところにアンテナ端子が用意されていますが、その内側にシールドされた金属箱がある場合が多いです。この中に、M.2ソケットと無線モジュールが入っています。最近のかっこいいバックパネルカバーのついたマザボも、裏側のネジを外せばカバーが外れて、コネクタ部品が見えるようになります。\nなお、このシールド箱内部のM.2ソケットは、SSDを接続するM Key M.2ソケットとは違い、E Key M.2ソケットと言うタイプです。M KeyがPCIeを4レーン持っているのに対して、E Keyは2レーンで、その代わりにUSBなどを備えています。Bluetooth機能はE KeyのUSBを利用しています。\nM Key M.2 : PCIe x 4 E Key M.2 : PCIe x 2, USB ほか シールド箱は、マザーボード裏側のネジを外すと取り外せます。取り外すと中にはE Key M.2無線モジュールがあり、マザーボードのM.2ソケットに挿さっています。\nZ370世代までのWiFi搭載マザーボードでは、このE Key M.2ソケットに通常のPCIe/USB接続のM.2無線カードが取り付けられていました。Z390世代になって、インテルチップセットにWiFiサポート機能が搭載されていて、それと連携するインテル統合接続 (CNVi) という仕組みが用意されました。これは、WiFiのMAC層をチップセットで担当して、信号処理や無線の物理層をM.2カードで担当します。でもZ390では従来型の非CNVi方式M.2無線カードも引き続きサポートされていました。なので、Z390世代より前のマザーボードなら、以下の方法で、macOSと互換性のあるBCM94360NGに交換できます。\nこの金属シールドは、さらにネジ1個を外すと開けられます。これで、中の無線モジュールをBCM94360NGに交換し、macOSで使用できます。\nZ490マザボの大半はCNVi限定 ところがZ490になって、多くの無線搭載マザーボードのE Key M.2ソケットが、インテルCNViに対応した無線モジュール専用になってしまいました。前回、ASUS ROG STRIX Z490-G GAMING (Wi-Fi)にmacOSをインストールしました。\nComet Lake-S 10600とZ490でmacOSを動かす\nこのマザーボードも、バックパネルのシールド内コネクタは引き続きE Key M.2ですが、従来型のM.2無線カードが動きません。ASUS ROG STRIX Z490-G GAMINGには、少し安価なWiFi無しのモデルもあります。あえてWiFiモデルを入手したのは、もしかしたらBCM94360NGが使えるかもしれないと思ったからです。でも、残念ながらE Key M.2ソケットはCNVi専用でした。SchmockLordさんのGitHubにも「使えません、信じてください」と書いてありました。実は上に掲載した写真は、このマザーボードでも、もしかしたら動くのではと思いつつ、作業した際の写真でした。\nZ490でも非CNViに対応するマザボ Z490でも従来型の非CNVi無線カードが使える製品もあります。これならば、上記で紹介した手順で、Broadcom製のBCM94360NGに交換可能です。IEEE802.11a/b/g/n/ac/axのWi-Fiは、新しいのでこれに対応したZ490マザーボードは恐らくCNVi専用と思われます。一方で、IEEE802.11a/b/g/n/acのみのZ490マザーボードならば、非CNViの可能性があります。例えば以下の製品はIEEE802.11a/b/g/n/ac対応なので、使えるかもしれません。\nSSD用M.2に無線を取り付ける 今回はmicro ATXなので、PCIeスロットにも余裕があり、そちらにWiFi/BTカードを挿しても良かったです。でもせっかく割高のWiFiモデルなので、そのアンテナ穴を生かすことにしました。そこで、SSD用のM Key M.2ソケットを使うことにしました。このマザーボードは、SSD用のM.2ソケットが2個あります。1個しか使わない予定なので、余りを活用しようと考えました。\n長いアンテナケーブル バックパネルのアンテナ穴から、SSD用M.2まで配線するために、長めのアンテナケーブルを手配しました。バックパネルのコネクタの形状は、RP-SMA femaleと言うらしいです。見た目はmaleなのですが、名前はfemaleです。また、モジュールと接続する方の小さなコネクタにも種類があります。U.FLとかMHF4とかの名前のコネクタがBCM94360NGに適合します。ややこしいので、販売サイトの写真と実物を比較して確認するのが良いと思います。ケーブル長さは、30 cmを手配しましたが少し長すぎました。下のような20 cm長で十分でした。\nM Key – E Key変換 マザーボード上のSSD用M.2ソケットに無線モジュールを装着する際に2つの選択肢があります。一つは、SSD用ソケットをBroadcom専用ソケットに変換して、純正のBCM94360CDなどを使う方法です。もう一つは、E Key M.2に変換してBCM94360NGを使う方法です。前者は、互換性としては安心ですが、変換器が少し特殊です。後者は、これもOOBで動き十分互換性が高い上に、一般的なM.2同士の変換なので変換器が容易に入手できます。今回は後者のE Key変換を行うことにしました。また、バックパネルのアンテナ穴が2個しかないので、同じアンテナ数2個のBCM94360NGで十分とも考えました。用意した変換器は、下のような製品です。\nE KeyにはUSBがありますが、M Keyにはありません。そこで、アダプタには白いUSB用コネクタが付いています。付属のケーブルでマザーボードのUSB 2.0ピンヘッダに接続します。\n取り付けと配線 実際に取り付け、配線を行った様子です。\nバックパネルシールドからアンテナ端子を取り外して、長いアンテナケーブルの端子を取り付けます。アンテナ取り付け・取り外しで緩むことがないよう、ボックスレンチで締めておきました。ここからアンテナ線をM.2 SSDソケットまで引き回します。30cmと長すぎたので、CPU側のPCIeスロットを大回りして配線しました。USB 2.0のケーブルも長すぎたので、こちらもPCIeスロットを大きく迂回して配線しました。アダプタ上のUSBコネクタは、基板の端にあるので、ケーブルが隣のM.2 SSD用ヒートシンクに多少干渉します。でもケーブルを強く曲げておけばなんとか回避できます。バックパネルアンテナ端子のシールドは外したままですが、バックパネル端子カバーを取り付ければ見えなくなり、不自然さはありません。\nまとめ WiFi搭載マザーボードのインテルモジュールを外して、macOS互換無線モジュールを取り付けました。バックパネル部分のE Key M.2がCNVi専用だったので、M.2 SSD用のソケットを使い、そこにBCM94360NGを取り付けました。これにより、macOSの無線関連機能がOOBで動作しました。\n400シリーズチップセットでも、一般的なM.2無線モジュールがバックパネルのM.2ソケットに取り付けられる製品もあるようです。WiFiの仕様が、802.11 a/b/g/n/ac/axとなっているマザーボードはおそらくCNVi専用で、802.11a/b/g/n/acとされているマザーボードはCNVi以外も動作する可能性があるようです。Redditの情報によるとASRock Z490M-ITX/acなどはBCM94360NGが使えるらしいです。\n追記：コメントで教えていただきましたが、ASRock Z490M-ITX/acでBCM94360NGが動いたそうです。その一方で、Z390でも、GIGABYTE Z390I AORUS PRO Wi-FiはCNVi専用だったようです。\n","date":"2020-07-08T23:57:12+09:00","image":"/uploads/2020/07/backpanel.jpg","permalink":"/posts/9857/","title":"Z490マザボ搭載WiFiをmacOS対応品に交換する"},{"content":"macOS Big SurではBroadcomのWiFi/Bluetoothモジュールが動かなくなるとか、そんなことはないとか情報が飛び交ってました。古いMacにBig Surを導入するパッチを作っているサイトによると、2012年モデル以前ではWiFiが動かないらしいです。今後は2013年以降モデル搭載の802.11 ac対応Broadcomの無線モジュールを使用するのが良いと思います。無線モジュールに関してはこちらのページをご覧ください。\nHackintoshのパーツ選び 【その4：無線編】\n古いMacは無線が動かない iMac14,1, iMac14,2, iMac14,3ってHaswellなのになぜBig Surのサポート外なのだろうと不思議に思って色々検索していたら、こんなページを見つけました。Big Sur非サポートMacで動かすためのパッチを配布しているDosdude1さんらのページです。フォーラムでもまっくぷろさんに紹介いただいています。\nmacOS Big Sur Patcher Is No Longer Available\n最初の疑問は解決しませんでしたが、別のことを発見しました。このページのパッチがサポートしている機種一覧表によると、パッチを使っても、2012年以前のMacではWiFiが動かないらしいです。もともとがサポート対象外の古いMacに搭載された無線モジュールですので、パッチを当てて動かそうとしている人たちにしか検証できない貴重な情報だと思います。\n802.11ac対応が動作条件? 実は2013年モデルMacからWiFiが802.11acに対応して、搭載されているBroadcom社製モジュールが入れ替わっています。これが関係していると思われます。それ以前の、802.11nのみ対応のBroadcomモジュールがBig Surで切り捨てられたのではないでしょうか。ちなみに、Broadcomモジュール型番と搭載Macの関係は、以下のページ（ロシア語）が詳しいです。\nhttps://deviwiki.com/wiki/User:Omega/Broadcom_modules_(Apple)\nこの2つのページの情報を組み合わせると、以下の古いBroadcomモジュールは、Big Surでサポートされなくなったと考えられます。型番がBCM9431、BCM9432、BCM9433で始まるモジュールです。\nBroadcom BCM94311MCAG Broadcom BCM94321MC Broadcom BCM94321COEX2 Broadcom BCM94322USA Broadcom BCM94322MC Broadcom BCM943224PCIEBT Broadcom BCM943224PCIEBT2 Broadcom BCM94331PCIEBT3A Broadcom BCM94331PCIEBT3B Broadcom BCM94331PCIEBT4 Broadcom BCM94331CSAX Broadcom BCM94331CD このうちの一部は、AliExpressで1,000円前後で格安販売されています。Catalinaまでは動いていた実績があるので、互換性があるように紹介されている場合もあります。Big Surを使用する予定でしたら、避けた方が良いと思います。\n一方で、引き続きBig Surでサポートされると考えられるBroadcomモジュールは、BCM9436シリーズの、\nです。はBCM94360CDを使っているので引き続き使用できると思われます。M.2 無線モジュールのもこの世代なのでBig Surで使用可能と思われます。\n","date":"2020-07-08T23:50:29+09:00","image":"/uploads/2020/07/oldwifi2.png","permalink":"/posts/9861/","title":"Big Surでは古いBroadcom無線モジュールが使えない?"},{"content":"フォーラムの話題に刺激されて「いま一番おすすめの自作Hackintoshのためのパーツ構成」を考えてみました。「一番」と言うお題なので、無理して一つだけ選んで、その後に言い訳を書きました。ご意見・ご異論あると思いますのでコメントでお知らせください。\nなお、いろいろな作例をBUILDSのカテゴリーでまとめてあります。\n追記：Big Surが出たので追記しました (2020/11/16)\nマザボ：ASUS ROG STRIX Z390-F GAMING これからの主流のZ490も良いのですが、2.5Gbps LANが新しすぎるのでPCI IDを偽装しないといけない点が面倒です。設定すればLANは動きますし、従来通りの1Gbps LANが搭載されたZ490マザボを買っても良いです。でも1つだけ選ぶということで、ここでは実績のある300シリーズにしました。ただ古い世代なので、間も無く市場から消える可能性があります。また、新しい方が好きという人は400シリーズにして問題ないです。\nマザーボードの選択肢は多いので、300シリーズに限定しても、たくさんの良い候補があります。ユーザが多く、Hackintoshを成功させたと言う報告の多いものが良いです。何かのトラブルがあった場合に、解決策が見つかる可能性が高いです。と言うことで、マザーボードシェアが1位のASUSと、Hackintosh黎明期に人気のあったGIGABYTEが良いです。MSIやASRockも同様に動きますが、あえて一番と言うと、このどちらかです。Zではなく、HやBなどのチップセットも良く動きます。でも、マザーボードはそれほど価格差も大きくないので、あえて一つを選ぶならZで良いでしょう。またATXフォームファクタを選びましたが、目的によって他のサイズでももちろん良いです。\n1番を選ぶと言うことで、ASUS ROG STRIX Z390を選びましたが、他にも良い候補はたくさんあります。このマザーボードが飛び抜けて適しているわけではありません。でも良く売れているので、ネット上に報告も多いです。BIOS設定もおそらくはデフォルトでも動くくらいに簡単なはずです。また他の同クラスのマザボと比べて、PCIeスロットがたくさんあります。拡張性が欲しくてHackintoshする人には最適です。個人的に感じるイマイチな点は、文字を多用したデザインがちょっと好きじゃないところです。なので実はASUS ROG MAXIMUS XI HEROを使ってます。\n400シリーズでしたら、同じASUS ROG STRIX Z490が良いかなと思います。これもよく使われていて、またPCIeスロットが多い機種です。CPUは、これも実機に近いものが搭載されている10900(K), 10700(K), 10600, 10500あたりでしょうか。\nCPU: Intel Core i5-9600K マザボをZ390にしたらCPUはCoffee Lake-Sです。ここではコストパフォーマンスを考えて9600Kにしましたが、Core i9-9900Kでも同様に良いです。理由は、iMacで採用されている第9世代CPUが9900Kと9600Kだからです。なので、一つだけ選ぶとしたら、9900Kか9600Kのどちらかになると思います。無印の9900, 9600でも同様に良いと思います。さらにはコストパフォーマンスと予算を考えて、9700K, 9700, 9500, 9400, 9100なども良いです。 iGPUの無いFモデルも動きますが、macOSにはiGPU前提の機能が多少あるので、iGPUのあるCPUが無難です。\nComet Lake-Sで作るなら、10700K, 10600, 10500が良いと思います。これも理由はiMac 2020で採用されているモデルだからです。10900K, 10900も、iMac 2020でクロック違いのApple専用モデル10910が採用されているので、互換性は高いです。\nグラボ：Sapphire RX 580 Pulse 一つだけ選ぶとしたら、Sapphire RX 580 Pulseです。理由は、Apple準純正とも言えるeGPU開発キットに組み込まれていたモデルだからです。以前のmacOSでは、このカードだけが完璧に認識されていた時期もありました。とは言え、今はどのブランドのRX 580でも互換性は問題ありません。RX 580はOOBで動くだけでなく、macOSのドライバーと相性が良いのか性能が良く引き出されています。しばらくはおすすめのグラボであり続けると思います。だんだん品薄になってきているので、確保しておいた方が良いでしょう。\nBig SurになってRadeon Naviアーキテクチャのサポートが充実して、RX 5700 XTがRX 580の1.6倍くらいのスコアを出すようになりました。なのでRX 5000シリーズも良いと思います。\nBig SurでRadeon RX 5700 XTのスコアが大幅に改善\n無線モジュール：Fenvi FV-T919 これは迷うところはないです。WiFi/Bluetoothが、取り付けるだけですぐに動きます。設定やkext類が不要です。macOSにはWiFi/Bluetoothが前提の機能がありますので、互換性の高い無線モジュールが必要です。詳しくはこちらを。\nWiFi/BluetoothアダプタFenvi FV-T919\nこの他のパーツ これ以外のパーツ、例えばメモリー、電源 (600Wくらいかな)、SSD/HDD、CPUクーラー、などは何でも良いです。メモリーは16GBもあれば十分です。電源は600Wくらいかな。起動ドライブはSSDがおすすめで256GBあれば当分は使えて、最低必要なのは30GBくらいです。一般の自作PCでの評判を参考に適当に選んでください。\n","date":"2020-07-06T22:11:13+09:00","permalink":"/posts/9791/","title":"いま一番おすすめの自作macOS PCパーツ構成"},{"content":"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として市販グラフィックスボードを使うユーザもいると思うので、対応してくれると良いと思います。\n今までもRadeon GPUのベンチマークを紹介しました。\n10.15.2にしたけどNaviの性能は向上しませんでした\nZ490マシンをバラックで組んでいるので、最新の環境でもう一度ベンチマークをしなおしてみました。使用した機材と構成は以下です。\nIntel 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回実施した平均値です。\nGPU OpenCL Metal UHD 630 5020 4782 RX 580 43546 44448 RX 5700XT 41139 35489 グラフにしました。依然としてRX 580の方がベンチマークスコアが高いようです。以前の測定よりもさらに差が開いたような気がしないでもないです。ということで、RX 580がHackintoshに最適な状態はまだまだ変わらないようです。\n","date":"2020-07-05T17:45:14+09:00","image":"/uploads/2018/12/nitro.png","permalink":"/posts/9757/","title":"最近の構成で新旧グラボ (RX 580 vs. RX 5700) 性能を再測定"},{"content":"以前、シリアル番号を決めるツールとしてmacserialを紹介しました。macserialを使いやすくしたツールにGenSMBIOSがあります。OpenCoreのガイドでよく使われていますので試してみました。config.plistにシリアル情報などを書きこめて便利でした。\nHackintoshの機種設定 Hackintoshを作ったら、それに機種ID、シリアル番号、UUID情報などのID情報を設定しておく必要があります。正しく設定しないと、macOSが動かないことがありますし、iCloudのサービスが使えないことがあります。さらにはユーザのApple IDが使用禁止にされてしまうこともあります。これらの設定はconfig.plistの中に書きます。CloverではSMBIOSのセクション、OpenCoreではPlatformInfoのセクションに書き込みます。\nUUIDなどのIDは世界に一つしかない番号ならばなんでも良いです。uuidgenなどのコマンドで乱数発生させて作れば良いです。またOpenCoreのROM番号はEthernetのMACアドレスを流用するのが一般的です。一方でMacのシリアル番号は、生産地、生産年・週、番号、機種固有番号などから構成されています。全体の構成はMacの世代で違うことがありますし、機種固有番号は機種ごとに違います。シリアル番号の規則をリバースエンジニアリングして、生成・チェックするソフトが作られています。それがmacserialです。シリアル番号の仕組みとmacserialの使い方は、以下の記事で詳しく紹介しました。\nMacシリアル番号の仕組み\nGenSMBIOSの使い方 最近のOpenCoreのガイドでは、シリアル番号などの機種情報を生成するために、GenSMBIOSというPythonプログラムがよく使われています。 これも中ではmacserialを動かしているのですが、より簡単に使えて、さらにconfig.plistへの書き込み機能を備えているので便利です。この記事ではGenSMBIOSを使ってみます。GenSMBIOSは以下からダウンロードできます。\nGitHub - corpnewt/GenSMBIOS: Py script that uses acidanthera\u0026rsquo;s macserial\u0026hellip;\nダウンロードするとGenSMBIOS.commandというファイルがあります。これが本体です。Terminal.appでこれを起動します（アイコンをダブルクリックしても良いです）。すると以下のメインメニューが現れます。\n####################################################### # 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: このメニューを順番に説明します。\n1. Install/Update MacSerial 最初のメニューは、内部で使用するmacserialの更新です。GenSMBIOS.commandがあるディレクトリの中に、Scriptsというディレクトリがあります。この中にmacserialが入っています。macserialの使い方は、過去の記事を見てください。macserialは、新しいMacが出るたびに、それをサポートするために更新されています。なので、GenSMBIOSのこのメニューは、macserialを最新版に更新します。既存のMacのシリアル番号生成規則も更新されている可能性もありますので、とりあえずは選択しておくのが良いと思います。\n####################################################### # 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へのパスを入力するか、もしくは説明にあるとおりそのアイコンをドラッグ\u0026amp;ドロップします。すごいところは、Cloverのconfig.plistにも、OpenCoreのconfig.plistにもどちらにも対応しているところです。\n####################################################### # 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に改名して入力してみました。\n3. Generate SMBIOS GenSMBIOSのメイン機能です。このメニューでSMBIOS情報を生成します。Macの機種IDを聞かれますので、入力します。ここではiMac19,1を指定しました。\n####################################################### # 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にコピペします。\n####################################################### # 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を比較してみました。一見、多くの差分があるように見えますが、実は、\n% diff config.plist Sample.plist 134,136c134 \u0026lt; \u0026lt;data\u0026gt; \u0026lt; Q3B1UG0AAAA= \u0026lt; \u0026lt;/data\u0026gt; --- \u0026gt; \u0026lt;data\u0026gt;Q3B1UG0AAAA=\u0026lt;/data\u0026gt; とあるように、元のSample.plistで情報という1行で記述された内容が、GenSMBIOSの処理により3行に分けられただけの場所が多いです。このような変更点を除いた、実質的に差分のある場所は、以下でした。\n% diff config.plist Sample.plist (略) 893c824 \u0026lt; \u0026lt;string\u0026gt;C020453004NLNV91M\u0026lt;/string\u0026gt; --- \u0026gt; \u0026lt;string\u0026gt;M0000000000000001\u0026lt;/string\u0026gt; 903c832 \u0026lt; \u0026lt;string\u0026gt;C02DN9ZSJV3Q\u0026lt;/string\u0026gt; --- \u0026gt; \u0026lt;string\u0026gt;W00000000001\u0026lt;/string\u0026gt; 905c834 \u0026lt; \u0026lt;string\u0026gt;2BCB8DF6-7633-4F0E-B63C-975E3EFCEDFE\u0026lt;/string\u0026gt; --- \u0026gt; \u0026lt;string\u0026gt;00000000-0000-0000-0000-000000000000\u0026lt;/string\u0026gt; ということで、000000…などの数値で仮に書かれていたシリアル番号、ボードシリアル番号、UUIDの場所だけが、今回新しく生成されたデータで書き直されていることがわかります。\nなお、シリアル番号は、下記のサイトでそれが未使用であることを確認しておくべきです。ここで生成された番号を入力し、「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば、その番号は未使用です。今回生成した番号はOKでした。\nCheck Your Service and Support Coverage - Apple Support\n4. Generate UUID これはおまけ的な機能だと思いました。UUIDだけを生成します。uuidgenというコマンドを動かしているだけだと思います。ちなみにこのメニューを選択しても、config.plistには書き込まれません。\n####################################################### # Generated UUID # ####################################################### 773F1659-07F1-4130-8C3B-FE2F900F9E95 Press [enter] to return... 5. List Current SMBIOS これは現在起動中のマシンの情報を表示します。上のメニューで指定したconfig.plistファイルの内容ではありません。macserialの–infoオプションと同様に、シリアル番号の分析と有効性を表示してくれます。\nまとめ GenSMBIOSコマンドで、シリアル番号を生成して、config.plistに書き込む作業が楽になります。その過程で、シリアル番号が有効かどうかをAppleのサイトで確認しておく必要はあります。また、このコマンドでは、OpenCoreのconfig.plistにおけるPlatformInfo–\u0026gt;Generic–\u0026gt;ROMの設定は行ってくれません。Sample.plistでは0x112233445566になっています（Base64ではESIzRFVm）。任意の6バイトの数値で良いのですが、唯一の数字にしておくべきです。通常はEthernetのMACアドレスに設定しておくと良いようです。生成したシリアル番号は大抵の場合未使用ですし、ROMの値もAppleによって厳しくチェックされる情報でもありませんので、GenSMBIOSで設定すれば、とりあえずは起動してしまっても大丈夫だと思います。\n","date":"2020-06-28T10:04:25+09:00","image":"/uploads/2020/06/macos-catalina-about-this-mac-1.png","permalink":"/posts/9597/","title":"GenSMBIOSを使って機種情報を設定する"},{"content":"macOS 11.0 Big Surインストールに関する情報をメモしておきます。\n機種設定 Big Surは、以下のIntel Macで稼働します。\nMacBook：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以降の番号にしないと起動しません。\n追記：MacBookPro11,1とMacBookPro11,2も避けた方が良いらしいです。\nApple、アップグレード後に起動しなくなる不具合が確認された2013~2014年製のMacBook Proのサポートを一時的に中止した「macOS Big Sur 11.0.1 Build 20B50」をリリースしています。\nブートローダー OpenCoreとCloverで起動することができます。ただ、OpenCoreが主流になりつつあるので、よくサポートされていて良いと思います。\nBig Surがリリースされた時点でのOpenCoreは0.6.3でしたので、それ以降のバージョンを使うと良いです。Kext Updaterなどで、最新リリース版を使えば良いです。\nKext類 Kext Updaterで得られる最新版を使用しておけば良いです。\nUSB起動インストーラ 従来通り、createinstallmediaコマンドで起動USBインストーラを作ることができます。\nmacOS の起動可能なインストーラを作成する方法\nインストール例 Big SurをインストールしたインストールやフォーラムトピックスをBig Surのタグをつけてまとめておきます（準備中）。\nBig Surをクリーンインストールする (OpenCore + Z490)\nBig Surをクリーンインストールする (OpenCore + Z390)\n","date":"2020-06-23T11:20:06+09:00","image":"/uploads/2020/06/bigsur.jpg","permalink":"/posts/9525/","title":"Big Sur"},{"content":"CPUの温度、電力などをモニターするためにVirtualSMCに付属するモニター用kextを入れました。これにより、HWMonitorやHWMonitorSMC2などのアプリケーションでハードウェア状況をモニターすることができるようになりました。\nHWMonitorなどのモニターアプリケーションをhackintoshで使用するためには、VirtualSMCやFakeSMCに用意されている、ハードウェアモニターkext類を使用します。いままでは、とにかく動作することが肝心だと思ってモニター用kextを使っていませんでしたが、ようやく試してみました。すでに使っている方は多いと思いますので、今さらな話題かもしれません。\nIntel Power Gadget CPUの状態をモニターする目的には、今まで、Intel Power Gadgetというアプリケーションは使ってました。これはインテルが配布しているアプリで、Windows, Linux, macOSで動きます。Hackintoshでも同様に動作するところがすごいです。このアプリは、FakeSMC/VirtualSMC用のkextが無くても動きます。\nIntel Power Gadget\nmacOSにインストールすると、/Library/Extensionsの中に、EnergyDriver.kextというカーネル拡張がインストールされます。おそらくはこれがインテルのCPU周辺チップセットにアクセスして、温度や消費電力情報を取得してくれるのだと思います。なので、Macでもhackintoshでも同様に動作するようです。\nただ最近、Power GadgetのmacOS版がインテルのサイトから消えてしまったようです。一時的な状況かもしれませんが、メンテナンスが面倒で更新をやめてしまったのかもしれません。ということで別の手段を探しました。\nHWMonitor macOS専用のハードウェアモニターアプリケーションにHWMonitorがあります。昔のブラウン管式オシロスコープのアイコンです。ただ、これも最近は更新が止まっているように思いました。探したところ、以下のサイトでつい最近にアップデートされたバージョンが見つかりました。ダークモードに対応したとのことです。これ以外にもいろいろなアプリケーションがあるように思います。お勧めがありましたら、コメントで教えてください。（追記：HWMonitorSMC2を教えていただきましたので、記事の最後に追加しました）\nRelease HWSensors-V6.26.1465 EFI · chris1111/HWSensors-V6.26.1465-EFI\nHWMonitorを、まずはMacBookで動かしてみました。インストーラを起動するとFakeSMC.kextなどをインストールするオプションもありますが、本物のMacなら不要です。アプリケーション本体だけあれば機能するので、アプリ本体だけをコピーして持ってきても動きます。起動するとメニューバーにアイコンが現れて、これをクリックするとプルダウンの中にCPU温度と電力が表示されます。バッテリーの残量も表示されます。\n歯車のところをクリックするとメニューが現れ、このプルダウンをメニューバーから取り外すこともできます。\nこのMacBookのCPUは2コアです。なぜかCore 2とCore 3になっていますが、番号は気にしない方が良いようです。バックグラウンドでDropboxやiCloudドライブの更新が動いていたためかもしれませんが、CPU温度が90度後半です。MacBookはファンレスで静かなのですがこのように、触れないくらい熱くなり、応答動作がものすごく遅くなることがしばしばあります。グラフのボタンを押すと、温度・電力変化をグラフで見ることもできます。最高温度は100度ですね。\nHackintoshで動かす 次にHWMonitorを、先日作成したASUSのZ490マザーボードのマシンです動かしてみました。何の表示も出ません。\nHWMonitorはMacに搭載されているSMC (System Management Controller) にアクセスして温度情報などを得ているようです。HackintoshではFakeSMC.kextやVirtualSMC.kextがSMCのフリをしてくれていますが、起動に必須ではない温度情報提供などの機能は無いようです。\n次に別の、ASUSのZ390マザーボードマシンで動かしてみました。CPUの情報は、先ほどと同様に何も表示されません。しかし、搭載しているSATA SSD/HDDと、接続しているMagic Keyboard/Trackpadの情報が出ました。SSD Remaining Lifeは謎の表示がされて100％になってます。M.2 SSDも接続しているのですが、そちらの情報は表示されませんでした。どうやらSATA経由で温度情報が得られるようで、それが表示されているようです。\nkextを入れて動かす FakeSMD.kextにもVirtualSMC.kextにも、ハードウェア情報にアクセスするためのkextが作られています。VirtualSMC.kextの場合、配布パッケージに、\nSMCSuperIO.kext SMCProcessor.kext SMCLightSensor.kext SMCBatteryManager.kext が同梱されて配布されています。このうち、SMCLightSensor.kextと SMCBatteryManager.kextはノートPC用のものです。光センサやバッテリーを搭載していないデスクトップマシンでは使いません。 デスクトップでCPU温度などをモニターするのに必要なkextはSMCProcessor.kextです。SMCSuperIO.kextは、ファンコントロールなどを担当する入出力に関するもののようですが、HWMonitorの表示には変化がありませんでした。（追記：後述するHWMonitorSMC2というアプリケーションでは、SMCSuperIO.kextを入れておくとファン回転数などの情報が表示されるようになります。）\nSMCProcessor.kextを上記のZ490マシンに入れて、HWMonitorを動かした結果が以下です。搭載したCPUは10600なので、6個のコアの温度が表示されました。コア1が2個表示されていますが、これも気にしないでおきます。MacBookと比較するとまともな温度で安心できます。\n次に、上記のZ390マシンに入れた結果を以下に示します。搭載CPUが8コアなので、それぞれの温度が表示されています。ここでもCore 1が2個見えてます。\nZ490マシンで、Geekbench 5を動かしつつ、Intel Power GadgetとHWMonitorを同時に動かした様子を下に示します。両方のアプリケーションで同じような結果が出ているので、信頼できる情報だと思いました。ベンチマークを動かすと瞬間的に70度を超えましたが、通常作業で90度越えの状態が続くMacBookよりはまともです。\nHWMonitorSMC2 もう一つのハードウェアモニターアプリケーションです。コメントでまっくぷろさんから教えていただきました。これを使用するにあたって、HWMonitorと同様に、VirtualSMCに加えて以下をインストールしました。\nSMCSuperIO.kext SMCProcessor.kext 起動するとHWMonitorと同様にメニューバーに現れますが、表示される情報はより多いです。ファンの回転数、グラフィックス温度などの情報、メモリー使用状況などが表示されます。また、項目をダブルクリックするとその数値がメニューバーに常時表示されるようになります。ただグラフ表示する機能は無いようです。Z490マシンでHWMonitorSMC2を動かした結果を下に示します。\nこのマシンはマザーボードをケースに格納していない状態で試験中です。なので、CPUファンだけが接続されていて、その回転数が正しく取得できているようです。また、HWMonitorSMC2はVirtualSMCやFakeSMCの情報取得kext以外に、Intel Power GadgetのEnergyDriver.kextも利用するようです。Power Gadgetがインストールされた状態で、歯車ボタンで以下のように設定すると（デフォルトでは無効）、表示されるCPU情報項目が倍増します。\n","date":"2020-06-22T00:21:52+09:00","image":"/uploads/2020/06/HWMonitor.png","permalink":"/posts/9487/","title":"HWMonitorを使う"},{"content":"\nASUSのZ490マザーボードのUSBポートを調査して、USBPorts.kextを作りました。レジストリに何故か現れないオンボードUSB 2.0ピンの割り当てを探し当てました。また、15個制限撤廃パッチが危険なことを確認しました。\nUSBポート設定の手順 前回作成したASUS Z490マザーボードマシンのUSBポートを設定し、El Capitanで導入されたUSBポート数15個制限に対処します。このマシンのOSはmacOS Catalina 10.15.5でブートローダーはOpenCoreです。\nComet Lake-S 10600とZ490でmacOSを動かす\nUSBポート設定の方法はこちらで紹介した方法です。\n15個制限のためのUSBPorts.kextをHackintoolで作る\n以下の手順で行います。この作業のツールには、ProperTreeとHackintoolを使います。\n一時的に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の文字が読めます。\n上の図では、HS11にだけデバイスが見えます。操作のために、以前紹介したトラックパッド付き無線キーボードを使っているので、その2.4 GHz無線ドングルが見えています。2.4 Gの文字の続きは文字化けしています。（「システム情報」で確認したら意味不明の漢字の羅列になってました。）\n格安のトラックパッド付き無線キーボード\nUSBポートを特定する 初期状態では、Connectorの種類がでたらめです。またCommentの欄は空白です。そこで、USB 2.0と3.0のUSBデバイスをポートに一つ一つ挿しては外して調べます。バックパネルに出ているUSBポートはType-AとType-Cのコネクタになっているので調査は簡単です。でもマザーボード上のコネクタは通常のUSBコネクタではなく、内部接続用のヘッダピンとType-C用の特殊なコネクタ (Key-Aという名前らしいです) です。そこで、従来型USBヘッダピンをType-Aに変換するアダプター（と）と、を、それぞれ用意しました。\n試験のために使うUSB 2.0デバイスには、出所不明のUSB WiFiドングルを使いました。USBメモリを使うと外す時にアンマウントの手間が不要ですが、無線ドングルならいきなり抜けます。USB 3.0のデバイスとしてはUSBメモリーを使いました。USBデバイスを挿していくと、Hackintoolの一覧の該当するポート名の行にデバイスの情報が現れます。これにより、ポート名と実際のポートの割り当てが特定できます。この時に、そのポート名のコネクタータイプ (USB2, USB3, Type-C Sw, Type-C, Internalのいずれか）を選択しておきます。またコメント欄に、対応する物理ポートの情報を英語でメモ書きしておくと、その内容がkextに反映されます。将来のメンテナンスなどの時に便利です。\nバックパネルのType-Cは、反対向きに挿しても同じSS04に接続されました。これはスイッチで切り替えているようなのでコネクタタイプをTypeC+Swに設定します。一方で、オンボードのType-Cは、反対向きに挿すとそれぞれSS05とSS06に接続します。なのでUSB 3.2が2本使われている本格的なTypeCのようです。この作業により、上の図のポートの全てが、それぞれバックパネル（ASUSの仕様書に合わせてRearとコメントしました）とマザーボード上（仕様書に合わせてFrontとコメントしました）のUSBコネクタであることを確認しました。こうして完成したUSBポート一覧が以下です。何故かHS06が見当たりません。\nオンボードUSB 2.0が見つからない 上の結果では、Z490-Gマザーボード上のUSB 2.0が見つかりませんでした。これは、昔ながらの黒いピンヘッダで、マニュアルにUSB_E12とUSB_E34と書かれています。\n一つのヘッダピンに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ヘッダピンを使いたいところです。\nそこで怪しいのが欠番のHS06です。上のUSBポート一覧はHackintoolの画面をですが、IORegistryExplorerで調べてもやはりHS06は見えません。見えていないHS06がオンボードUSB 2.0である可能性が高いです。ASUSの最近のマザーボードでは（Z390がそうでしたが）オンボードのUSB 2.0は、USBハブを通して分割されて実装されているようです。このマザーボードも、HS06をハブで4個に分割してヘッダピンに接続していると思われます。もしかしたらハブを使っているために、レジストリーに現れないのかもしれません。\nということで、HackintoolのExportボタンで作ったUSBPorts.kextのInfo.plistに、HS06のエントリーを追加してみることにしました。具体的には、以下の記述を、HS05とHS07の記述の間に挿入しました。base64のBgAAAA==は、0x06000000です。\n\u0026lt;key\u0026gt;HS06\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Front USB 2.0 (USB_E1234)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;UsbConnector\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;255\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;HS06\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;port\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; BgAAAA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; こうして作成したUSBPorts.kextを使って起動した結果が以下です。目論見通り、HS06が現れて、それがUSB2.0 Hubに接続されている様子が表示されました。この状態で、Type-Aアダプタを経由してUSBメモリを接続すると、macOSのファインダー上に正しくマウントされました。\nここで作成したUSBPort.kextのInfo.plistを以下に公開しておきます。\nUSBPorts.Info.plist_ASUS_Z490G - Pastebin.com\n注意していただきたいのは、このplistの中の、25行目と344行目です。それぞれ、\n\u0026lt;key\u0026gt;iMac19,1-XHC\u0026lt;/key\u0026gt; と\n\u0026lt;string\u0026gt;iMac19,1\u0026lt;/string\u0026gt; となっています。これは機種IDをiMac19,1にした場合の設定です。実はこの後、iMac20,1が発売されたので、config.plistの設定をCPUが合致するiMac20,1に変更しました。そしたらこのkextが動かなくなって悩んだのですが、ここに機種ID依存の設定が入っていました。Hackintool.appは、稼働しているマシンの機種IDを自動的に書き込んでくれます。なので、後から機種IDを変更する場合は、ここも変更する必要があります。\nASUS Z490-GのUSBポート一覧 ASUS Z490マザーボードROG STRIX Z490-G GAMINGのUSBポートは以下のように割り当てられていました。このマザーボードを使う方は参考になさってください。\nHS01：リアパネルに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番目（基板側） リアパネルの配置は以下になりました。\nマザーボード上のUSBピンの割り当ては以下です。\n15個のポートを選別する こうして全てのポートがHackintoolに現れるようになったところで、全部で15個になるように選別します。今回は、マザーボード上のUSB 3.1ポートを全て使わない設定にしました。バックパネルのポート全てと、マザーボード上のUSB 2.0ポートだけを有効にします。ということで、以下の15個のポートを使うことにしました。\nHS01：リアパネルに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) も使えているので無線カードの使用にも問題ありません。\n15個制限撤廃パッチは危険 今回の作業中に、USBポート一覧表に異常な現象が発生して、15個制限撤廃パッチはやはり危険なのではと実感しました。そのことをご紹介します。\nUSBポート一覧表をもう一度見てみましょう。上の一覧に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が割り当てられてしまっています。\nLocation IDが重複していては、何かの不具合が出ても不思議ではありません。さらには、本来割り当てされないはずの0番、つまり0x140のIDが割り当てられていることも問題のようでした。\nポートを調査している段階では、Location ID 0x140はSS05に割り当てられていました。これはマザーボード上のType-C (key-A) のUSB 3.1 Gen2の2個のうちの一つでした。ここにMacBookなどで使用する以下のようなType-Cアダプタ\nを接続した時の一覧を下に示します。このアダプタには、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個制限をパッチで回避したための副作用なのでしょう。\n今回行ったように、15個を指定するkextを作って、XhciPortLimitをfalseにしていれば、このような異常現象は発生しません。15個制限撤廃パッチは、インストール直後の調整用の場面でのみ使用し、使い続けない方が良いと思いました。\nまとめ ASUSのROG STRIX Z490-G GamingマザーボードのUSBポート名を特定して、使用する15個を選択するkextを作りました。無線カードで使用するオンボードのUSB 2.0がレジストリに現れないので、kextで指定したところ認識できました。また15個制限撤廃するパッチは副作用があることがわかりました。\n","date":"2020-06-12T22:18:10+09:00","image":"/uploads/2020/06/USB_00.png","permalink":"/posts/9392/","title":"ASUS ROG STRIX Z490-G GAMINGのUSBを設定する"},{"content":"\n前回紹介したASUSのZ490マザーボードで、動かなかったオンボードオーディオとEthernetが動きました。少しトリッキーな方式のような気がしますが、hackintoshコミュニティのサポートが充実するまでのつなぎとしては十分です。\n追記：OpenCore 0.6.0とAppleALC.kext 1.5.1になり、オーディオはレイアウトID（このマザボは7）を指定するだけで動くようになりました。こちらをご覧ください。\nASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）\n参考にしたページ 前回は、OopenCoreのComet Lake-S　バニラインストールガイドに従って、正攻法なインストールを行いました。そのためか、マザーボード搭載のオーディオコーデックと2.5 Gbps Ethernetが動きませんでした。\nComet Lake-S 10600とZ490でmacOSを動かす\nOpenCoreのバニラガイドが出る前に、SchmockLoadさんがGIGABYTE Z490 Vision Dにインストールした様子をGitHubにまとめてくれていました。そこでは、オーディオも2.5 Gbps Ethernetも動いているようです。今回はこれを参考に作業しました。\nGitHub - SchmockLord/Hackintosh-Intel-i9-10900k-Gigabyte-Z490-Vision-D: https\u0026hellip;\nオーディオを動かす 追記：オーディオに関するこの節の情報は古いです。こちらをご覧ください。\n今回使用しているマザーボードに搭載されたコーデックはRealtek ALC1220です。もしかしたらALC1220Aなのかもしれません。ASUSはSupremeFX S1220Aと呼んでいます。300シリーズマザーボードでも搭載されていたコーデック（そちらはSupremeFX S1220無印）と数字部分は同じです。なので、AppleALC.kextで動くと思ったのですが、簡単には動きませんでした。\nそこで、上記のSchmockLoadさんのGitHubガイドに従って、以下のkext、\nFakePCIID.kext FakePCIID_Intel_HDMI_Audio.kext を追加し、config.plistのDevicePropertiesに\n\u0026lt;key\u0026gt;DeviceProperties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Add\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; （略） \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1F,0x3)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;cKEAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;layout-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BwAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; を追加しました。FakePCIIDの仕組みはこちらで説明されてます。ちゃんと理解できていないのですが、PCIeのデバイスIDを、macOSのドライバが認識するIOPCIDeviceに結びつけてくれる機能のようです。本体がFakePCIID.kextで、デバイスIDの情報だけが書いてあるInfo.plistだけのkext（今回の場合はFakePCIID_Intel_HDMI_Audio.kext）と組み合わせて使います。これによりmacOSが認識しないIDのデバイスを動かしてしまおうという機能のようです。\nFakePCIID_Intel_HDMI_Audio.kextは、その名前の通り、100, 200, 300シリーズのHDMIオーディを実現する目的で作られているようです。今回の場合に当てはまるのか疑問でした。説明を見ると、100シリーズ以降で0xA170もしくは0x9D70のデバイスIDを使えるようにしてくれるようです。ここでは0xA170を使っています。これを動かすためには、動かしたいオーディオデバイスの、ACPIに現れるデバイスIDを0xA170に変更しておく必要があります。それが上記のconfig.plistの記述です。\nHackintoolで確認してみます。オーディオチップはPci(0x1f,0x3)のPCIeデバイスパスに配線されています。そのデバイスIDは0x06C8でした。\n上記のconfig.plistを使うと、このデバイスIDが0xA170に変更されていることがわかります。デバイス名も、100 Series/C230 Series Chipset Family HD Audio Controllerと表示されるようになっています。それでも実際のコーデック名とはちょっと違う気がしますが、これで音声が再生されるようになりました。\nZ490マザーボード でのサウンドチップの変更は、おそらくはデバイスIDなどが多少変更された程度の違いと思いますので、そのうちにAppleALC.kextが対応してくれるのだと期待しています。それまではこの対応で凌げると思います。\nEthernetを動かす このマザーボードに搭載されているEthernetチップは、2.5 GbpsのIntel I225-Vです。上位のマザーボード でLANが2個あるタイプのものは、もう片方が従来と同じ1 GbpsのIntel I219-Vだったりします。I219-Vは300シリーズでも使われたチップなので、IntelMausi.kexe, IntelMausiEthernet.kextで動くようです。でもi225-Vしか搭載されていないマザーボードは有線LANに接続できません。\nこちらも、オーディオと同様に、FakePCIIDを使って解決できました。FakePCIID_Intel_I225-V.kextが設定をしてくれます。\nFakePCIID.kext FakePCIID_Intel_I225-V.kext また同様にconfig.plistでEthernetチップのデバイスIDを0x15F2に設定します。ちなみにこのマザーボードでは、元々のデバイスIDは0x15F3でした。\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;8hUAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; SchmockLoadさんによるとFakePCIID_Intel_I225-V.kextを作ってこの設定を紹介したのはドイツのHackintosh-forum.deのBrumbaerさんだそうです。GitHubにあるconfig.plistの例では\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1C,0x1)/Pci(0x0,0x0)\u0026lt;/key\u0026gt; になっていますが、上記のHackintoolの一覧に現れているように、ASUSマザーボードではデバイスpathが違うようです。\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1C,0x4)/Pci(0x0,0x0)\u0026lt;/key\u0026gt; を指定したところ動きました。これでネット接続できるようになりました。おそらくはIDを偽装して、macOS標準のドライバで動かしているのだと思われます。とはいえ、1Gbpsのハブに接続して使用したところでは、速度が遅いとか、データが滞るなどの問題は感じられませんでした。IntelMausi.kextが対応するまでのつなぎとして十分に使用できそうです。\nGeekbench 5でベンチマーク ネットに接続できるようになったので、Geekbenchで測定しました。Geekbenchは結果がweb上で表示されるので、ネット接続してないと起動できませんでした。結果は、以下のようにマルチコアスコアで6000越えでした。\n現行の非BTO版最上位iMacは3.7 GHz 9600Kを搭載しています。は無印なので（K付きは未発売でした。今もかな？）クロックが遅い (3.3 GHz) です。でも9600Kでは無効にされたハイパースレッドが復活しています。互角の性能である気がしましたので、Geekbench Browserで9600K搭載iMacのスコアを検索してみました。\nマルチコアスコアが5000を切ったスコアも、6000を超えたスコアもありましたが、大半が5000代でした。結局、クロックが10%くらい低下しても、ハイパースレッドが効いたのか、10600無印の方が高速のようです。\nまとめ 10600搭載Z490マザーボードの自作マシンでマザーボード搭載のオーディオとEthernetが動きました。AppleALC.kextとIntelMausi.kextが対応してくれるまでのつなぎとして使えます。ネットが動いたのでGeekbench 5でベンチマークをしました。これに相当する性能と思われる9600K搭載のiMacより高いスコアが出ました。\n","date":"2020-06-07T16:27:15+09:00","image":"/uploads/2020/06/before-1.png","permalink":"/posts/9365/","title":"ASUS ROG STRIX Z490-G GAMINGの音とLANを動かす"},{"content":"\nを搭載したASUSのZ490マザーボードに、OpenCoreで起動するmacOS Catalinaをインストールしました。とりあえずは動く状況です。CPU, iGPU, スリープは動いていますが、オンボードのEthernet, サウンドがまだ動きません。\n参考にしたページ SchmockLoadさんが、GIGABYTE Z490 Vision Dにインストールした様子をGitHubにまとめてくれていたので最初はこれを参考にしていました。でも作業を進めているうちに、OpenCoreが0.5.9になり、ガイドのページも更新されて、なんとComet Lake-S用のconfig.plistを作るガイドが追加されました。\nDesktop Comet Lake | OpenCore Install Guide\nということでこのガイドを参考に、作業を進めました。\n使用ハードウェア マザーボード 使用したマザーボードは、です。サブマシンがmicro-ATXなので、ゆくゆくはそれに搭載しようと考えました。メインマシンがASUSなので、同じメーカにしました。しっかりした作りでよくできています。製品写真ではバックパネルカバーのロゴが黄色です。でもこれはフルカラーLEDなので、Windowsからならば何色にも設定できると思われます。デフォルトでは時間と共に色が変化します。\nは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ソケットに無線カードを取り付けて、バックパネルのアンテナ端子だけを利用しようと考えています。\nCPU どうせなら話題の10コア20スレッドの10900Kを使おうかとも思いました。でも、当初はComet Lake-SがmacOSで動くかどうか不明でしたので、日和って安価な6コア12スレッドの10600無印にしました。10900Kが品切れで入手不可能だったことも理由です。とはいえ同じ6コア12スレッドなら、Ryzen 5 1600 (AF) の方がコストパフォーマンスが良いですね。\nBIOS設定 BIOSの設定は、ほぼ工場出荷時設定で大丈夫です。Legacy USBをdisabledにするなど、やっておけば良い程度の変更をしました。デフォルト設定のままでmacOSの起動に支障をきたすことはありません。\n使用したefiとkext ACPIには\nSSDT-AWAC.aml SSDT-EC-USBX.aml SSDT-PLUG.aml を入れました。Driversには、\nVBoxHfs.efi OpenRuntime.efi OpenCanopy.efi を入れました。Kextsには、\nWhateverGreen.kext VirtualSMC.kext Lilu.kext IntelMausi.kext (動かないのでつづきの記事では外しました) AppleALC.kext を入れ、ToolにはOpenShell.efiを入れました。ちなみにOSとブートローダは以下です。\nmacOS Catalina 10.15.5 OpenCore 0.5.9 config.plistを作る OpenCore配布パッケージにあるsample.plistを元に、変更を加えてconfig.plistを作っていきます。上記のサイトのComet Lakeのページにほぼ従いました。とはいえ、以前紹介したCoffee Lakeとほぼ同じ設定です。\nASUS Z390 + Coffee LakeのブートローダをOpenCoreにする\nまずは、上記のefi, kextファイル類を所定の場所に収めた後、Proper TreeのOC Clean Snapshot機能を使って、これらの設定を終えます。これで半分くらいの作業は終了です。次に残りの項目を設定していきます。とはいえほとんどはsample.plistにあるデフォルト値のままで良いです。\nComet Lake-Sは、Macで搭載されたことのない最新CPUなので、Core 2の時代の古いCPUに偽装しないと動かないという報告が多くありました。CPUの偽装には、config.plistのKernel, Emulateの項目を使います。ところが、macOS 10.15.5からComet Lake-Sがサポートされて、Emulateに何も設定しなくても動くようになったそうです！。\n\u0026lt;key\u0026gt;Emulate\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Cpuid1Data\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Cpuid1Mask\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; また、iGPUのig-platform-idも解明されているようです。ディスプレイ接続用と、ヘッドレス用それぞれに対しての推薦のig-platform-id値が、ガイドのページに書かれています。今回は、ディスプレイ接続用の以下の設定にしました。\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BwCbPg==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; 動いたこと ということで、思いのほか順調に動作しました。CPUは完全に動いています。ターミナルからCPU名を問い合わせると、名前とクロック数が正しく返ってきます。\n% sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i5-10600 CPU @ 3.30GHz iGPUも機能しています。下のスクリーンショットでわかるように、ドックの背景が半透明です。グラフィックス加速が正しく機能しています。ただし、Display Portのみ機能し、HDMIでは出力できないです。グラフィックスボードを使用する予定なので、これで十分です。\n追記：iGPUをしばらく使ってみたのですが、「画面共有」を設定しても他マシンから接続できませんでした。コンソール.appからsystem.logを見ると、他のマシンから接続した際に、screensharingサービスが中断シグナルを受けて落とされているようでした。sshやsmbのサービスは問題ありませんのでネットワークの問題ではなく、iGPUの問題だと思われます。後でグラフィックスボード（Radeon RX5700XT）を接続してそちらで動かしたところ、「画面共有」を受け付けられるようになりました。iGPUはHDMI出力できないこともありますし、使わない方が良いと思いました。\nスリープも正しく動いています。スリープすると画面が消え、CPUファンが停止します。キーボードを押すと復帰して、画面が現れます。遮断も正しく行われます。\n動かないこと 追記：Ethernetとオーディオは動きました。詳しくは「つづき」の節のリンクを見てください。\nIntelMausi.kextを使っていますが、Ethernetが動きません。400シリーズからEthernetチップが、2.5 GbitのIntel I225-Vになりました。新しいチップなので、IntelMausi.kextの元になっているLinuxのドライバでもまだサポートされていないらしいです。SchmockLoadさんのガイドによると、I225-Vが動いたようなことが書いてありますのでもう少し確認します。\nマザーボード搭載オーディオが動いていません。上記の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は全部試しました。これももう少し確認します。\nまとめ Comet Lake-SでmacOSを動かしました。CPUは偽装することなく使用できました。DP経由のiGPUグラフィックスが加速状態で使用可能でした。スリープも動きます。~~一方で、LANとオーディオがまだ動いていません。~~もう少し確認していきたいと思っています。\nつづき その後の展開です。安定して動いているので、このままメインマシンにしても良いと考えています。\nASUS ROG STRIX Z490-G GAMINGの音とLANを動かす\nASUS ROG STRIX Z490-G GAMINGの音を動かす（続編）\nASUS ROG STRIX Z490-G GAMINGのUSBを設定する\nZ490マザボ搭載WiFiをmacOS対応品に交換する\nASUS ROG STRIX Z490-G, 10900K\nmacOS 10.15.6へのアップデートをシステム環境設定から行いました。問題なくアップデートできました。（2020/7/16）\n","date":"2020-06-06T00:07:34+09:00","image":"/uploads/2020/06/10600.png","permalink":"/posts/9328/","title":"Comet Lake-S 10600とZ490でmacOSを動かす"},{"content":"Kext Updaterを起動したらOpenCoreの0.5.9が来ていました。OpenCoreに移行してから初めてのアップデートだったので、戸惑いました。使用しているefiファイル類を、ダウンロードされたEFIフォルダの中のefiファイルで一つ一つ置き換えました。問題なく動いているので、この方法で正しく更新できたかと思ってます。\n追記：コメントで指摘いただいて気付きました。上の作業では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からの設定の移行作業も楽でした。\n","date":"2020-06-05T00:32:55+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/9334/","title":"OpenCoreを0.5.9に更新"},{"content":"macOSが起動する時、ブートローダがカーネルをメモリに読み込みます。この時、連続した十分な大きさのメモリ領域が確保できないと、起動に失敗して禁止マークが出ます。この状況への対処方法が、OpenCoreではCloverよりも充実しています。\n以前の記事では、メモリの使用状況（メモリマップ）を確認して、空き領域を起動オプションのslide値で指定することで、カーネル用メモリを確実に確保する方法を紹介しました。今回はそのOpenCore編です。\nslideでカーネル読み込み番地を調整する (Clover編)\n以下のOpenCoreのガイドで、この問題への対処方法が詳しく説明されています。以下はこのサイトの抄訳です。\nKASLR Slide値を設定する このページでは、 “Couldn’t allocate runtime area” (ランタイム領域を割り当てられませんでした) というエラーを理解し、修正したいユーザーのために説明します。これは Z390, X99, X299 などで最もよく現れるエラーです。このページはOpenCoreだけでなく、Cloverも対象にします。\nKASLRとは何か？ KASLRは、Kernel address space layout randomizationの略で、セキュリティ目的で使用されます。これにより攻撃者がメモリ内の重要なオブジェクトがどこにあるのかを把握するのを難しくします。\nHackintoshでKASLRが問題になるのは、マザーボードに連続した十分なサイズのメモリー空間がなく、カーネルが完全に収まらない場合です。そこで、slide=xxx を使って、KASLRをキャンセルしてメモリーアドレスを固定していました。このパラメータを設定すると、macOSに起動ごとに動作するランダムな領域にカーネルを読み込む代わりに、動作することがわかっている場所を使用します。\nこのガイドが必要な人達 カーネルを読み込むメモリ空間が足りなかったり、細分化されたメモリー空間に読み込み場所が移動してしまったユーザーのためのガイドです。その場合、このようなエラーが出ます。\nError allocating 0x1197b pages at 0x0000000017a80000 alloc type 2 Couldn\u0026#39;t allocate runtime area 以下のようなエラーが出ることもあります。\nOnly 244/256 slide values are usable! または、macOSの実行中にカーネルパニックが発生することもあります。\npanic(cpu 6 caller 0xffffff801fc057ba): a freed zone element has been modified in zone kalloc.4096: expected 0x3f00116dbe8a46f6 but found 0x3f00116d00000000 これらのエラーの1番の特徴は、発生にランダム性があることです。大抵は20回も起動を繰り返せば、1回くらいはエラーを出さないで起動します。\n問題解決の方法 これを修正するのは非常に簡単で、その手順はCloverユーザでもOpenCoreユーザーでも同じです。Clover ユーザに必要なものは以下です。\nClover 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ユーザに必要なものは以下です。\nOpenRuntime OpenShell これをconfig.plistのRoot -\u0026gt; Misc -\u0026gt; Toolsで有効にしておきます。 そして、config.plist -\u0026gt; Booter (OpenCore用) かOcQuirks.plist (Clover用) で以下の設定をします。\nAvoidRuntimeDefrag: YES\n日付、時刻、NVRAM、電源制御などのUEFIランタイムサービスの修正 DevirtualiseMmio : YES\nStolen Memory のサイズを削減し、slide=N値のオプションを拡張し、Z390のメモリ割り当ての問題を修正するのに非常に役立ちます。 EnableSafeModeSlide : YES\nslide 値をセーフモードで使用できるようにします。 ProtectUefiServices : NO\nUEFI サービスがファームウェアによってオーバーライドされないように保護します。主に VM、300 シリーズ、および Ice Lake や Comet Lake のような新しいシステムに関連します。 ProvideCustomSlide : YES\nこれにより、カーネルが、読み込みに適したメモリー空間のみを選択し、起動に失敗する可能性のある場所を避けるようになります。読み込み場所のランダム性は維持していますが、ランダムに選択する際に、不適切なメモリ領域を除外するようになります。（訳注：これが従来のslide設定の役割を果たしてくれるようです。ただし、slideを固定するのではなく、使用可能なslide値を自動で探して、その中からランダムに選んでくれているようです。） RebuildAppleMemoryMap : YES\nmacOSと互換性のあるメモリマップを生成します。いくつかのラップトップのOEMファームウェアで失敗することがありますので、早期段階でブートに失敗する場合は、これを無効にします。 BIOS設定 BIOSを以下のように設定します。\nBIOSを更新する (初期のBIOSにはメモリマップの問題があることが知られているので、非常に重要です, 特にZ390で重要です。) CMOSを工場出荷時設定にリセットする とても必要とされる以下のBIOS設定をします。\nAbove4GDecoding : 有効にします。デバイスが4GB以上のメモリ領域を使用できるようになり、macOSカーネルが収まるメモリー空間が増えます。\nBoot Options -\u0026gt; Windows8.1/10 mode : これにより古いレガシーなゴミのようなコードがロードされなくなります。誤解されがちですが、other OSというもう一つの選択肢は、古いバージョンのWindowsを起動するための選択肢であり、LinuxやmacOSのための選択肢ではありません。（訳注：ASUSのZ490マザーボードにCatalinaを入れたマシンでは、other OSにしないと起動しませんでした。） BIOS内の不要なデバイスをできるだけ多く無効にします。これにより、起動時のマップの細分化が減少するので、起動失敗の可能性が減ります。\nCSM : 無効にします。有効化してしまうと、レガシーサポートのため、不要なゴミの束が追加され、またUEFIシェルが起動できなくなります。\nIntel SGX : 無効にします。SGXとはSoftware Guard Extensionsの略です。有効にしても、多くのメモリ空間を占有するだけで、macOSでは何もしません。\nParallel Port と Serial Port：無効にします。macOSではParallel portは認識しませんし、Serialを必要とする人はいないです。\niGPU : やむを得ない場合は、これを無効にすることで、メモリを大幅に解放できます。\nThunderbolt : 無効にします。ほとんどのマザーボードはTBを搭載していませんし、搭載していても使用しないなら、無効にすることでメモリ空間を確保できます。\nLED lighting : 無効にします。もう光らせなくても良いでしょう。\nLegacy USB : 無効にします。これもレガシーなガラクタです。 テストブート 上記のように、EFI、config.plist、BIOSの設定を調整したら、これで起動を試してください。これでめでたく解決したら、この先の作業は不要です。まだ問題が発生する場合は、次のステップで、もっとディープな作業、つまりslide値の計算をしましょう。\nslide値を探す ブートマネージャでEFIシェルを開き、memmapを実行します。すべてのページとそのサイズのリストが以下のように表示されます。ここからが楽しみの始まりです。\nType Start End # Pages Attributes RT_Data\t0000000000000000 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にもツールらしきものがあるらしく、その説明もありますが、これも省略します。）\nDevirtualiseMmioを使う （\n訳注：この先はあまり理解できませんでした。推測を交えて内容をまとめると、次のようなことだと思います。推測部分は間違っているかもしれません。\nconfig.plistでDevirtualiseMmioをtrueにする DevirtualiseMmioのデフォルトはfalseですが、これをtrueにします。これにより、カーネルを読み込む場所のメモリー使用が64から256MB程度節約できて、KASLRの失敗を防止できます。\nMMIOはMemory Mapped IOのことです。入出力デバイスのコントロールをメモリーのアドレス線を利用して行うのがMMIOです。上でのべたEFI Shellのmemmapコマンドによると、E0000000番地からFFFFFFFF番地までの512MBにMMIOが割り当てられています。インテルチップセットのマザーボードなら同様のようです。この番地には、メモリーが割り当てられていたとしても、IOへのアクセスになってしまい使えません。\nType 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にすると、カーネルが読み込まれる領域を少しでも多く確保できるので、起動失敗の確率を下げられます。\nKaby Lake以前のCPUでは、デフォルト通りfalseが、Coffee Lake, Comet Lakeなどではtrueにすると良いとされていますが、手元のCoffee Lake-Sではfalseでも動きました。通常はfalseで、起動失敗する場合にはtrueを試すのが良いと思います。\nちなみにどうでも良いことですが、virtualize (仮想化) をvirtualiseと書くのは英国風らしいです。\nconfig.plistにMmioWhitelistを指定する DevirtualiseMmioをtrueにした場合に、メモリは節約できるものの、Threadripper TRX40 19H などの一部のシステムで起動しなくなることがあるらしいです。そのような場合、DevirtualiseMmioを適用しない領域を指定します。これがMmioWhitelistです。これの作り方について説明がありますが省略します。ほとんどのシステムではMmioWhitelistは不要とのことです。\n）\nここまでが抄訳です。\n結局どうしたら良いのか OpenCoreでどう対応すべきかについてまとめます。上記のガイドでは、slide値を求める方法は書いてありますが、ブートオプションなどで設定する方法にまでは書かれていませんでした。当然のことで省略されたのかもしれないですし、slideを使うことをあまり推奨していないのかもしれません。\nOpenCoreの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を使いましょうとの方針だと思います。\nということで、このガイドのステップをまとめると、以下になります。まずはマザーボードの設定です。\nBIOSを更新する Above 4G Decodingを有効にする CSMを無効にする Boot Options -\u0026gt; Windows8.1/10 mode にする（訳注：前述のようにother OSを選択しないと起動しないことがあります） Parallel Port と Serial Portを無効にします 可能ならば以下も設定します。\nIntel SGX : 使用していないなら無効にします。 Thunderbolt : 使用していないなら無効にします。 LED lighting : 無効にします。 Legacy USB : 無効にします。 そしてconfig.plistで以下のように設定します。\nAvoidRuntimeDefrag: true DevirtualiseMmio : true EnableSafeModeSlide : true ProtectUefiServices : false ProvideCustomSlide : true RebuildAppleMemoryMap : true 設定は、環境に合わせて必要なものを選択して、正常に起動するまで少しずつ足して行くのが良いと思います。\nまとめ KASLRに関係した理由でmacOSが起動しないことへの対処法を紹介しました。基本的には、メモリー空間を確保する処置をして、KASLRの選択範囲を狭めることで対応しています。BIOS設定とOpenCoreの機能で大体の場合に対応できて、slideによるカーネル読み込み番地固定は最終手段のようです。\n","date":"2020-06-02T23:10:12+09:00","image":"/uploads/2018/09/20180628102100.png","permalink":"/posts/9291/","title":"カーネル読み込みメモリ空間を確保する (OpenCore編)"},{"content":"macOSのUSB 15個制限を解決するために、使用する15個未満のUSBポートを決定し、macOSに伝えます。以前の記事でいくつかの方法を紹介しましたが、今回はHackintoolを使ってkextを作ります。作業が楽で、作ったkextを1個インストールするだけなので簡単でした。\nUSBポート個数対処の方法 今までの記事では、USBポート個数制限に対処する方法として、\nAppleUSBXHCIPCI.kextにパッチを当てる OpenCoreのconfig.plistでXhciPortLimitをtrueにする DSDTを書き換えて使用する15個のUSBポートを指定する USBInjectAll.kextとブートオプションで15個を指定する USBInjectAll.kextとこれに指示するSSDTを作って15個を指定する などの方法を紹介しました。\nUSBポートを設定する\nASUS MAXIMUS XI HEROのUSBを設定する\n先日の記事で、OpenCore用の手順を書いたところ、P2B-Fさんからコメントで「Hackintoolを使ってUSBPorts.kextを作る方が簡単です」と教えていただきました。試してみたら確かに簡単でした。その手順をまとめておきます。以下の方法は、個数制限に対応する方法の中で、現時点で一番おすすめの方法だと思います。\nHackintoolを入手する Hackintoolは以下から入手できます。HackintoolはiGPUの設定でも使いました。色々便利な機能があります。USBポートの情報などのハードウェア構成情報はIORegistryExplorerでも見ることができますので、併用して確認するのも良いです。\nReleases · headkaze/Hackintool\n一時的に制限を撤廃する まずOpenCoreのconfig.plistでXhciPortLimitをtrueにするなどして一時的に15個制限を解除します。Cloverでしたらconfig.plistで15個制限撤廃パッチを当てても良いです。また、以前紹介したようにUSBInjectAll.kextとブートオプションを使って少しずつ解除しても良いです。以下では、全てを解除した状態で説明します。全解除状態でHackintoolを起動し、ウィンドウ上部のボタンからUSBを選択すると、下の図のようになります。\nウィンドウの下には、7個のボタンが表示されています。マウスを持っていくと機能が文字表示されます。それによると左から、Info, マイナスマークのDelete, ホウキのマークのClear All, 回転矢印マークのRefresh, 注射器マークのInject, Import, Exportのボタンです。Clear All, Inject, Refreshの順に押していくと、現在認識されているポートが全て表示されます。Z390チップセットのASUS ROG MAXIMUS XI HEROでは以下のようになりました。上部のウィンドウに、Cannon Lake用の300シリーズチップセットのマザーボードであることが表示されていて、マザーボードが正しく認識されています。\nここでHS03とHS12がアクティブになっています。HS03には、一時的にLogicoolのタッチパッド付きキーボード用の無線ドングルを接続したので、それが見えています。また、HS12にはUSB 2.0のハブを接続しているので、それが見えてます。実はHS13には、Apple純正のBluetoothモジュールが接続されているのですが見えていません。マザーボード上のUSB 2.0コネクタなのですが、これがマザーボード内蔵のhub経由で接続されているらしく、そのためか、XhciPortLimitをtrueにしても見えないようです。なので設定作業用にLogicoolのキーボードを接続しているわけです。（さらにはSS10にもハブがつながっているのですがそれも見えていないようです。後の図で示すように、15個制限を設定したら、これらも見えるようになりました。）\nUSBポートを特定して選別する この状態で、USBポートにデバイスを取り付けて、変化を観察します。例えば上の状態では、バックパネルのUSB 3ポートにLogicoolのキーボードドングルが反応したので、これがHS03であることがわかります。この作業には、キーボード、マウス、USB Bluetoothアダプタなどを使うと良いです。これらはUSB 2.0ですし、抜き差しも簡単です。USB 2.0メモリーを使用すると、アンマウントする手間が必要です。USB 3のポートを確認するには、USB 3対応のUSBメモリーなどを使います。この場合は、取り外す際にアンマウントしないと、データを壊す危険があります。（大抵は大丈夫ですが）\nHackintoolのConnectorの欄をクリックするとポップアップメニューが出ます。この欄には、USBの速度ではなく、接続された物理的なコネクタの形状を書きます。HS03はUSB 2ですが、USB 3コネクターに接続されています。なのでHackintoolのConnectorの欄はUSB3に設定します。\nConnectorとして選択できるのは、USB2, USB3, TypeC+Sw, TypeC, Internalの5種類です。ここでの選択で、後で述べる出力ファイルのUsbConnectorプロパティ値が変化します。それによると、それぞれの選択で、0, 3, 9, 10, 255が割り当てられることがわかりました。これらの値について、Hackintoolのソースを調べたところ、ヘッダファイルに以下の記述がありました。\nkTypeA\t= 0x00,\t// Type ‘A’ connector kMiniAB\t= 0x01,\t// Mini-AB connector kExpressCard\t= 0x02,\t// ExpressCard kUSB3StandardA\t= 0x03,\t// USB 3 Standard-A connector kUSB3StandardB\t= 0x04,\t// USB 3 Standard-B connector kUSB3MicroB\t= 0x05,\t// USB 3 Micro-B connector kUSB3MicroAB\t= 0x06,\t// USB 3 Micro-AB connector kUSB3PowerB\t= 0x07,\t// USB 3 Power-B connector kTypeCUSB2Only\t= 0x08, // Type C connector - USB2-only // These only implement the USB2 signal pair, and do not implement the SS signal pairs kTypeCSSSw\t= 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\t= 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\t= 0xFF\t// Proprietary connector 0, 3, 9, 10, 255以外にも、いくつかの設定値があるようです。ただ、Hackintoolのメニューにあるように、この5種類が一般的で、これ以外を設定することはなさそうです。この説明から、割り当ては以下のようです。\nUSB2 (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に設定しないとスリープを妨げることがあるようです。\nType-Cコネクタの設定 Hackintoolのコネクタ選択肢であるTypeC+SwとTypeCの違いを説明します。Type-Cケーブルは、以下のように1セットのUSB2配線（A6, A7とB6, B7）と、2セットのUSB3配線（A2, A3, B11, B10とA10, A11, B3, B2）で構成されています。\nこのうち、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を共に使用してもそれぞれのフルスピードが出ます。\n最近になって従来のUSB 3.0や3.1の表記に代わって、USB 3.2という名称が使われるようになり、ややこしくなってます。色々調べてみると、以下のような分類になったようです。\nUSB 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を選択します。\n使わないポートを除外 こうしてUSBポートを特定していくと同時に、使わないポートを外していきます。最終的に15個のUSBポートまで削減していきます。使えるものなら使いたいけど、個数制限で諦めざるを得ないポートもあると思います。また、Comment欄のところにメモ書きをしておくと、後で説明する出力ファイルにもコメント記載されます。テキストエディタで修正する場合などに便利です。\n今回も、以前の記事で選んだUSBポートを使うことにしました。結果として以下のようになりました。\nUSBPorts.kextを作る この後、ウィンドウ下のExportボタンを押します。するとこの設定から、\nSSDT-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と一緒に使うものであると思います。\n一方、ここで作られるUSBPorts.kextは、Info.plistだけを持ったインジェクタkextという種類のkextファイル（実際にはディレクトリ）です。ターミナルからディレクトリを辿る、もしくはファインダーからパッケージを開くと、\nUSBPorts.kext/Contents/Info.plist というテキストファイルが見えます。この中に、上で設定した内容が、plist書式のテキストで書かれています。こうして作成されたInfo.plistの内容を以下のところに置いておきました。\nUSBPorts.kext for ASUS Z390 - Pastebin.com\nこのUSBPorts.kextだけを使用すれば、15個のUSBを指定して動かすことができました。kextを使う場合は、USBInjectAll.kextやSSDT-EC.aml, SSDT-UIAC.amlは不要です。実は、Z97の時代にはこの手のインジェクトkextを使って使用USBのリストを設定していました。その後、チップセットが代わって、雛形となるファイルが見つからなくなったので、USBInjectAll.kextとSSDTを組み合わせて使っていました。Hackintoolでこんなに簡単に生成してくれるなら、今後はこのkextを使っていきたいと思います。\nUSBMap.commandを使う こちらもコメントで教えていただきました。Hackintool.appと同様に、インジェクトkextを作るPythonスクリプト、USBMap.commandがcorpnewtさんによって配布されています。\nGitHub - corpnewt/USBMap: Python script for mapping USB ports in macOS and cr\u0026hellip;\nこちらはCUIベースで設定していきます。操作が多少独特ですが、USB設定専用のアプリですのでシンプルです。生成されるインジェクトkextはUSBMap.kextという名前ですが、Hackintoolで作るUSBPorts.kextと全く同じ内容です。\n% ./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 \u0026amp; Create SSDT/Kext D. Discover Ports U. Validate USB Power Settings Q. Quit Please select an option: コメントでMifjpnさんから、USBMap.commandの使用例を教えていただきました。\nUSBMap.commandによるUSBポートの選択\nまとめ USBポート15個制限に対応するため、Hackintoolを使って、USBPorts.kextを作りました。このkextを使用するだけで、15個制限の設定が可能でした。今まで紹介した方法のどれよりも簡単だと思いますので、今後はこの方法で設定していこうと思います。コメントで教えていただきありがとうございました。\n","date":"2020-05-31T17:36:51+09:00","image":"/uploads/2017/09/20170930110251.png","permalink":"/posts/9177/","title":"15個制限のためのUSBPorts.kextをHackintoolで作る"},{"content":"\n2.5インチSSDのtrim機能をtrimforceコマンドで有効にしました。nvramを正しく動くようにしておいたためか、trimforceが効きました。もしtrimforceが効かない場合、Cloverでは、IOAHCIBlockStorage.kextにパッチ当てしてましたが、OpenCoreではThirdPartyDrivesをtrueにするだけで良いようです。\ntrim有効化方法 (OC対応版) 今回、trimの有効化を試したマシンは、ASUSのZ390マザーボードとSanDiskの2.5インチSATA SSDの構成です。また、trimの仕組みと設定方法は以下の記事で紹介しました。\nSSDのTRIMを有効にする\nSSDを使う場合、trimは有効になっていた方が良いと言われてます。そこで以下のステップでtrim設定に対処します。\nSSDによっては、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は効かないし、パッチ当てるのも面倒だったのも理由です。\nThirdPartyDrivesの説明を読む という状況だったのですが、OpenCoreにしたところ、パッチ当てが簡単になっていることに気づきました。上のステップに書いたように、config.plistの中で設定できるThirdPartyDrivesというプロパティをtrueにすれば、IOAHCIBlockStorage.kextにパッチを当ててくれます。これなら簡単にtrim有効化できます。さらにその説明を読むと、以下のように、できればtrimforceが望ましいようなことが書いてありました。\n**ThirdPartyDrives :**デフォルトはfalseです。IOAHCIBlockStorage.kextにパッチを当て、サードパーティのドライブでtrimやハイバーネーションを可能にします。このオプションは、ユーザの判断で使わないことにしても良いです。最近のmacOSバージョンには、専用のユーティリティであるtrimforceが提供されています。10.15以降では、このユーティリティは、01 00 00 00という値のEnableTRIMという変数をnvramに作ります。\nThirdPartyDrivesでパッチ当てをしてくれるものの、trimforceはmacOSがサポートするtrim機能を活性化するmacOSのコマンドなので、これでtrim有効化するのが望ましいそうです。trimforceで有効化できない場合の時だけ、ThirdPartyDrivesをtrueするのが良いと思います。\ntrimforceコマンドでtrim有効化する そこで、久々にtrimforceを試したところ、すんなり動いてしまいました。Terminalからtrimforceとタイプすると、説明が出ます。\n% trimforce Usage: trimforce enable trimforce disable trimforce help 次に、OpenCoreの説明にある、EnableTRIMがnvramの中にあるかどうか調べてみました。\n% nvram -p | grep EnableTRIM 何も表示されません。定義されていないようです。そこでtrimforceコマンドで、trimを有効にするよう試みました。色々警告が出ますが進めます。\n% 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変数を調べてみました。\n% nvram -p | grep EnableTRIM EnableTRIM %01 OpenCoreのマニュアルにある通り、01という値のEnableTRIM変数が出来上がっていました。システム情報を見ると、設定前は「いいえ」だったTRIMサポートの項目が「はい」に変化していました。trimforceで正しく設定できたようです。\ntrimforceは長らく機能しなかったので、あきらめていましたが、設定できるようになっていました。trimforceがnvramを使うようになったためか、さらにはSSDT-PMC.amlでnvramが正しく使えるようになったおかげのようです。\nまとめ ひさびさにtrimforceコマンドを試したら、2.5インチSSDのtrimが有効になりました。ちなみにM.2 NVMe SSDの方は、何もしない状態でtrim有効でした。もしtrimforceが効かない場合は、OpenCoreでしたらThirdPartyDrivesをtrueにすれば良いと思われます。\n","date":"2020-05-28T22:42:16+09:00","image":"/uploads/2020/05/systeminfo-2.png","permalink":"/posts/9109/","title":"SSDのtrimを有効にする (OpenCore編)"},{"content":"インテルの第10世代デスクトップCPUであるComet Lake-Sとこれに対応した400シリーズマザーボードが発売されました。これでhackintoshは可能なのでしょうか。結論としては、まだ難しいようです。\n追記：Redditの別の情報によると、CPU, LAN, Thunderboltなど含めて、かなり動いているようです。(2020/5/29)\n新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に簡単な解説がありました。\nr/hackintosh - Desktop Comet Lake launch! What you need to know for Hackintos\u0026hellip;\nこれによると以下のようです。\nCPUの互換性 現在のmacOSはモバイル用のComet Lakeはサポートしているが、デスクトップ用のComet Lake-Sはサポートしません。新型iMacがComet Lake-Sを搭載する未来が来るまで、macOSのサポートはないです。そのためか、試した人たちによると、macOSがカーネルパニックを起こすようです。今のところ、新CPUを動かすためには、Penryn CPUにフェイクする必要があるそうです。Penrynっていつの時代だろうと思って調べたら、Core 2 無印 / Duo / Quad時代のCPUでした。かなり昔のCPUに偽装する必要があるようです。詳しくはこちらをみてくださいと、ロシア語の掲示板が紹介されてます。ロシアのハッカーの皆さんに頑張ってもらいたいです。\nACPI fix IcelakeとZ390に比べて大きな違いはないので、DSDTへの対応も同様で良いと思われるそうです。以下のSSDTを加えておけば良いようです。SSDT-PLUGに関しては、上記のようにCPUの対応ができていないので、しばらくは効果が無いそうです。\nSSDT-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が全ての場合で安定しているわけではないので、カーネルパニックが治っても、問題が発生する可能性はあるそうです。\nDevirtualiseMmio: カーネルを適切にロードするため。 ProtectUefiServices: イメージローディングのfix iGPU 第9世代デスクトップCPUと同じUHD 630を引き続き搭載しているものの、フレームバッファが不明らしいです。これは第10世代CPU搭載iMacが出荷されるまで決まらないので、それまでは手作業で設定する必要がありそうです。\nUSB 残念ながら新しいUSBはネイティブに互換ではないようです。Xhci-Unsupported.kextを使い、PCI IDとして8086:06edを追加する必要があるとのことです。\nEthernet 400シリーズチップセットになってmacOSが一番影響を受けたのはLANとWiFiのようです。このプラットフォームは新しい2.5Gbe NICであるI225Vを搭載しています。これはLinuxでのE1000eドライバがサポートしていないので、それを元にしているIntelMausi.kextでも動かないです。対応待ちです。\n一方で、RTL8125やI211などのNICを搭載しているメーカもあります。これらは今のIntelMausi.kextで対応しているそうです。調べてみたところ、MSIはRTL8125を、ASRockはRTL8125とI219Vを搭載しているようです。I219VはIntelMausi.kextのサポートリストに載ってます。一方で、GigabyteとASUSに搭載されるNICは新型のI225Vのようで、使えるまでしばらく時間がかかりそうです。\n続報：tonymacx86の情報によるとIntelMausiEthernet.kext (IntelMausi.kext?) でIntel I225-V Ethernetが動いたようです。(2020/5/29)\n無線カード 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非互換カードは使用不可能とのことでした。\n続報：Gigabyte Z490 Vision D + 10900Kの動作報告 こちらのGitHubページで2020/5/28頃に動作例が紹介されました。\nGitHub - SchmockLord/Hackintosh-Intel-i9-10900k-Gigabyte-Z490-Vision-D: https\u0026hellip;\nOpenCoreでブートしているようで、以下が動作しているそうです。\nWifi 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しているようです。\n\u0026lt;key\u0026gt;Emulate\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Cpuid1Data\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;6wYIAAAAAAAAAAAAAAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Cpuid1Mask\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;/////wAAAAAAAAAAAAAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; 6wYIAAAAAAAAAAAAAAAAAA==は、0x0806EBになり、第7世代と第8世代のCPUの値を使っているようです。\n","date":"2020-05-23T13:49:32+09:00","image":"/uploads/2020/05/10900K.png","permalink":"/posts/9159/","title":"第10世代デスクトップCPUでmacOSは動く？"},{"content":"ここではUSBInjectAll.kextを使っていますが、最近はサポートが途絶えているので、以下の方法がよりシンプルでおすすめです。\n15個制限のためのUSBPorts.kextをHackintoolで作る\n———————————-\n（以下は今でも有効ですが、古い情報です。）\nOpenCoreではconfig.plistでXhciPortLimitをtrueにすれば15個制限を解除できます。Cloverでのパッチ作業より楽です。でもUSBInjectAll.kextとSSDTで使用する15個を指定する従来の方法も可能で、その方式がおすすめです。\nOpenCoreで15個制限を全撤廃 macOS El Capitanから使用可能なUSBポートの数が、 コントローラ当たり15までと制限されました。その解説と、Cloverのconfig.plistに書く制限解除パッチを以下の記事で紹介しました。この記事では、AppleUSBXHCIPCI.kextにパッチを当ててました。\nUSBポートを設定する\nOpenCoreでは、config.plistのKernel, QuirksのXhciPortLimit項目をtrueにしておくと（デフォルトはfalse）、必要なパッチを当ててくれます。 AppleUSBXHCIPCI.kextの他に、AppleUSBXHCI.kextとIOUSBHostFamily.kextにパッチを当ててくれるようです。このパッチは、各種macOSバージョンに合わせた内容が必要なので、その点にも対応してくれているようです。なので、簡単に15個制限を解除できます。\nしかし、OpenCoreのReferenceマニュアルにはこんな注意書きがあります。\nこのオプションは、可能な限り避けてください。USBポート制限は、locationIDの書式で割り当てられたビット数による制限です。この制限は、OSを大々的に変更しない限り解除できません。正しい解決策は、使わないポートを除外して、使用したいUSBポート15個を選定することです。\nつまり、macOS内部で使用しているプロパティのlocationIDの中で、ポートを識別するための変数に、どうやら4ビットしか割り当てられていない様子です。15個を超えるポートを使用可能にすると、違うポートに同じIDが割り当てられる可能性があるわけで、とても危険なことだと推測できます。実際には15個制限を外したことで問題が発生した事例は、報告も無いし経験もしていませんが、避ける方が良いでしょう。XhciPortLimitの使用は、macOSをインストールする際や、使用するポートを取捨選択する作業の時だけに制限すべきでしょう。\nOpenCoreで使用する15個を指定する そこで、15個制限を撤廃するのではなく、必要な15個のポートだけを登録するようにします。まずはマシンのUSBポート割り当てを調べて、使用したい15個のUSBポートを選定します。この方法は、以下で説明しました。OpenCoreならば、この手順の中で、一時的にXhciPortLimitをtrueにすることで簡単に15個制限解除できるので、作業が楽になると思います。\nASUS MAXIMUS XI HEROのUSBを設定する\nmacOSは発見した15個までのUSBポートをアプリケーションに提供します。なので、使用する15個のポートを決定したら、その15個のポートだけがマシンに存在しているかのようにmacOSに伝えます。これにはいろいろな方法が可能ですが、USBInjectAll.kextと専用のSSDTを使用するのが一番おすすめだと思います。以下の記事で、仕組みと設定方法を説明しました。\n15個制限を回避するUSBInjectAll.kextの役割と使用法\n上の記事では、Cloverで使うための方法を書いていますが、OpenCoreでも同じように設定できます。ただし、kextとSSDTファイルを置く場所は、Cloverと違うディレクトリです。つまり、kextはKextsに、\nSSDTは（SSDT-UIAC.amlという名前にしました）ACPIに置きます。\nまた、OpenCoreでは、config.plistにも、使用するkextとSSDTを記述する必要があるのは、すでに説明した通りです。ProperTreeのsnapshot機能を使えば、kextとSSDTを正しいディレクトリに置くだけで、config.plistの設定をしてくれるので楽です。\nまとめ OpenCoreでもUSBポート15個制限に対応するため、Cloverで使っていたUSBInjectAll.kextとSSDT-UIAC.amlをOpenCoreのESPに入れました。config.plistにも登録しました。これらは、Cloverの時と同じように、OpenCoreでも機能して、必要な15個のUSBポートが使えるようになりました。\n","date":"2020-05-20T23:27:08+09:00","image":"/uploads/2017/09/20170930110251.png","permalink":"/posts/9096/","title":"使用するUSBポートを15個指定する (OpenCore編)"},{"content":"抜き挿し可能なリムーバブルSATAドライブベイを使うために、Cloverでは、macOS稼動中にHDD/SSDドライブのホットプラグを可能にするパッチをconfig.plistに書いてました。OpenCoreに移行したのでこのパッチも移行しました。\n5.25インチベイ用リムーバブルHDDラック 上の写真のような、5.25インチベイに取り付けるリムーバブルHDDラックは、本物のMacには無い、自作hackintoshならではの便利な装備です。でもHDDラックを取り付けただけではHDD/SSDのホットプラグが効きませんでした。macOS起動時にリムーバブルベイに装着されているHDD/SSDは認識され、ファインダー上でアンマウントして、安全に取り外すことはできます。しかし、macOS稼動中にHDD/SSDを挿しても認識されません。そこでCloverでは、ホットプラグが機能するようにconfig.plistにkextパッチを当て対応していました。\nSATA接続HDD/SSDのホットプラグ\nCloverで使用していたパッチ このパッチは、AppleAHCIPort.kextの一部を0x90 (マシンコードでNOPに相当します) に置き換えるものです。置き換える範囲は、kextの中の0x40200000というデータ列の4バイト、その前8バイト、その後14バイトの、合計26バイトです。コメントでまっくぷろさんに教えていただいたパッチです。\nこのパッチを作るために、kextの中で0x40200000を探して、書き換えるべきデータ列を調べます。例として、macOS 10.15.4で、書き換えるべきデータを探してみます。まずは、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをhexdumpします。\n% hexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less lessが起動しているところ、以下のサーチコマンドをタイプし、40 20 00 00を探します。\n/40 20 00 00 ところが運悪く途中に改行が入っているようで見つかりません。40 20だけでもう一度探索します。\n/40 20 今度は見つかりました。改行の先に00 00があるので、間違い無いようです。他にも40 20は見つかりますが、その先に00 00が続く場所はありません。おそらくは2バイト単位で位置揃えされているので、この場所以外に改行が来る可能性は無いと思います。40 20 00 00と40 20の2種類の探索を試みれば、40 20 00 00の場所を発見できると思います。\n0002a40 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) に置き換えるパッチを作ります。つまり、\nFind --\u0026gt; 81E24060 020081FA 40200000 750C81E1 BF7FFFFF 898B6901 0000 Replace --\u0026gt; 90909090 90909090 90909090 90909090 90909090 90909090 9090 AppleAHCIPort というパッチを作ります。ProperTreeなどのツールならこのまま16進数が使えますが、テキストエディタで作る場合はbase 64に変換します。詳しくはこちらをご覧ください。Findするデータはbase 64では以下になります。\n% echo -en \u0026#34;\\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\u0026#34; | base64 geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA= Replaceするデータは、NOPコマンド列である9090…なのですが、このbase 64は以下です。\n% echo -en \u0026#34;\\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\u0026#34; | base64 kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA= なのでCloverのconfig.plistには、\n\u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Enables hot plug for removal drives\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; というパッチを追加していました。これでBIOSでホットスワップ指定したチップセットSATA接続ドライブがオレンジ色アイコンになり、随時マウント・アンマウントできるようになりました。またスリープしても問題ありませんでした。\nOpenCore用のパッチに書き換える OpenCoreには、CloverのようなKextToPatchの項目はありません。OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、使用するキーの一部がCloverのパッチとは異なります。OpenCoreのパッチで使うキーは以下です。\nComment : Cloverと同じ。人が読むためのメモ書き。 Find : Cloverと同じ。検索データ列。 Replace : Cloverと同じ。置き換えるデータ列。 Identifier : CloverのNameに相当するキー。kextを指定するためのIDで、バンドルIDを使う。 Enabled : パッチを有効にする場合はtrueにする。（有効にしたいのでtrueにする） Count : パッチを当てる箇所の数。今回の場合は1回なので1。 その他のキー : デフォルトで良いので省略。 kextのバンドルIDは、システム情報で知ることができます。\nシステム情報の拡張機能のAppleAHCIPortの項目を選択すると、\ncom.apple.driver.AppleAHCIPort であることがわかります。そこで、上記のCloverのパッチに相当する、OpenCoreのパッチは以下になります。\n\u0026lt;key\u0026gt;Kernel\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Patch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Enables hot plug for removal drives\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Count\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;Enabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Identifier\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; ProperTreeで設定するなら、以下のようになります。（0番から4番までに、OpenCore付属のSample.plistにあった無効設定のパッチを残してあるので、たまたま5番目になっていますが、何番目でも大丈夫です。）\nこのパッチをOpenCoreのconfig.plistに追加したところ、OpenCoreでも、ホットプラグが機能しました。オレンジ色のドライブがmacOS起動後にリムーバブルベイに取り付けた2.5インチHDDです。\nパッチを施したconfig.plistを以下に置いておきます。もしこれを使用する場合は、SystemSerialNumber, SystemUUID, MLB, ROMの値を必ず置換えてください。\nOpenCore config.plist for 9900K - Pastebin.com\nまとめ リムーバブルドライブベイのホットプラグを可能にするCloverパッチを、OpenCoreのconfig.plist用に書き換えて動作を確認しました。これでまた一歩、OpenCoreに適応できた気がします。\nつづき Big Sur対応パッチはこちらをご覧ください。\nリムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)\n","date":"2020-05-19T22:29:04+09:00","image":"/uploads/2017/09/20170926165208.png","permalink":"/posts/9033/","title":"リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する"},{"content":"OpenCoreのデフォルトブートメニューはシンプルすぎるので、Cloverのようにアイコンで選択するよう設定しました。0.5.7以降でこの機能が使えるようです。\nOpenCore GUI 前の記事で、ASUSマザーボードマシンのブートローダーをCloverからOpenCoreに移行しました。そのコメントで、OpenCoreでもアイコンによる起動選択ができるようになっていることを教えていただきましたので、試しました。以下での設定が終了していることが前提です。\nASUS Z390 + Coffee LakeのブートローダをOpenCoreにする\nOpenCoreの起動画面をGUI化する方法に関しては、以下のページに使い方の説明があります。これに沿って進めました。アイコンによる選択のほか、起動チャイムやボイスオーバーも設定できるようです。ただ起動チャイムは、今のMacにはもうありませんし、不要かと思い設定しませんでした。\nResourcesの中身を用意する 配布されているOpenCoreのパッケージでは、OC/Resourcesの中にAudio, Font, Image, Labelというディレクトリがあるものの、中身は空でした。この中身を、以下のページから取り寄せて、入れておきます。たくさんのファイルがあります。特にAudioは、多国籍語のボイスオーバー用音声ファイルが入っていて、数が多いです。今回は、アイコン表示だけの作業なので音声ファイルは不要だとは思いますが、一緒に入れておきました。\nGitHub - acidanthera/OcBinaryData\nOpenCanopy.efiを設定する アイコン選択を動かすためには、OpenCanopy.efiというドライバーが必要なようです。配布されているOpenCoreパッケージには含まれていましたが、前回の作業ではDrivers_offというディレクトリを作って、これに入れて外していました。これをDriversディレクトリに戻します。こんな感じになりました。最小限の構成です。\n新しくDriversに追加したので、config.plistも書き換えておきます。簡単な作業なのでProperTreeのSnapshot機能は使わずに、ProperTree上での手作業でOpenCanopy.efiを追加しました。これくらいの作業ならテキストエディタで十分で、ProperTreeを使うまでも無いかもしれません。\nconfig.plistのMisc項目を設定する 引き続きProperTreeを使い、以下の項目を設定します。\nMisc -\u0026gt; Boot -\u0026gt; PickerMode: Sample.plistではBuiltinだった値をExternalに変更しました。 Misc -\u0026gt; Boot -\u0026gt; PickerAttributes:1 ガイドには1にせよとありましたが最初から1でした。この値のデフォルト値は0です。今回設定した1の他に、2, 4, 8とその組み合わせの選択肢があるようです。8を試してみたのですが、見た目は変わりませんでした。 この結果、このページの冒頭の写真のように、アイコンで選択できるようになりました。\nまとめ OpenCoreの起動選択画面でアイコン表示されるように設定しました。Cloverコミュニティの皆さんが競って作っているようなド派手な画面やミニマムでおしゃれな画面ではありませんが、本物のMacと同じアイコンを使った正統な起動画面だと感じました。今回は起動音の設定を行いませんでしたが、設定すれば起動チャイムやボイスオーバーが可能になるようです。ボイスオーバーは、本来はバリアフリーのための機能です。OpenCoreの開発者の方々も、その意識を持って起動音機能を整備していることがガイドに書かれていました。\n追記：モダンなアイコン コメントでまっくぷろさんから、今風の起動選択画面アイコンの情報をいただきました。Cloverのようにこれから増えていきそうですね。\nGitHub - blackosx/OpenCanopyIcons: A range of .icns files designed specifical\u0026hellip;\nOpenCanopy Icons\n追記：ミニマムなテーマ ミニマムなテーマもありました。実機とは違うアイコンになりますが、macOS起動前の白りんごアイコンにマッチしたシンプルなアイコンです。\nOpenCore用のミニマムなテーマ\n追記：起動音を出す こちらをご覧ください。\nOpenCoreで起動音を鳴らす\n追記：アイコンファイルの変更 最近のOpenCoreでは、アイコンファイルの設定方法が変更されています。こちらをご覧ください。（2021/7追記）\nOpenCore 0.6.9から0.7.0に更新\n","date":"2020-05-18T21:04:59+09:00","image":"/uploads/2020/05/GUI4.jpg","permalink":"/posts/9061/","title":"OpenCoreの選択画面をグラフィカルにする"},{"content":"\nPioneerの光学ドライブを使用していると「空のdvdがセットされました」というメッセージが出て、操作不能になることがあります。Cloverのconfig.plistでパッチを当てて対処していたのですが、OpenCoreに移行したので同様のパッチを当てました。\nCloverで使用していたパッチ 「空のdvdがセットされました」というエラーメッセージが出ることの原因と対策をこちらの記事で紹介しました。macOSがPioneerのドライブにスリープ指令を送りつけると、スリープ後も復帰しないことが原因のようです。そこで、光学ドライブにはスリープ命令を送らないように、macOSでは設定してあるらしいです。\n光学ドライブを使う\nなので、本物のMacと同型番のPioneer DVDドライブを使っていれば、操作不能に陥る問題は多分発生しないです。でも違う型番、例えばBDドライブを使う場合は、PioneerSuperDrive.kextにパッチを当てて、本物のMacが搭載している型番 (DVD-RW DVR-105) を、hackintoshで使用している型番 (例えばBD-RW BDR-205) に書き換えることで、この問題を解決できます。実際には、config.plistに以下のパッチを追加していました。これでスリープ命令が送られなくなり、操作不能に陥ることを回避できました。\n\u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;PioneerBD-RW No Sleep\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;RFZELVJXICBEVlItMTA1\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;PioneerSuperDrive\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;QkQtUlcgICBCRFItMjA1\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; OpenCoreに移行したところ、再び、「空のdvdがセットされました」というエラーメッセージが出るようになりました。Cloverで使っていたパッチと同様の内容を、OpenCoreのconfig.plistにも書いておく必要があるようです。\nCloverのKextToPatchをOpenCoreに移行する方法 OpenCoreには、CloverのようなKextToPatchの項目はありません。OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、書式もCloverのパッチとは多少異なります。上記のCloverのパッチを、OpenCoreで書く場合は、以下になります。ちなみにReplaceの値は、BD-RW BDR-205の型番になっています。他の型番の光学ドライブを使用している方は、その型番に書き換えてください。詳しくは、以前の記事をご覧ください。\n\u0026lt;key\u0026gt;Kernel\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Patch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;PioneerBD-RW No Sleep\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Count\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;Enabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;RFZELVJXICBEVlItMTA1\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Identifier\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.PioneerSuperDrive\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;QkQtUlcgICBCRFItMjA1\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; Cloverと比べてOpenCoreでは、一部のキーが削除追加されています。OpenCoreのサンプルconfig.plistを見ると、もっとたくさんのキーがあります。ただOpenCoreのパッケージに付属するマニュアルを読んでみたところ、デフォルト値のままで問題ないキーが多かったです。それらは省略しました。\nCloverのkeyのうち、Comment, Find, ReplaceはOpenCoreでも同じ名前で、同じ意味です。つまり、Commentは人が読むためのメモ書き、Findは検索データ列、Replaceは置き換えるデータ列です。これらはCloverの内容からそのままコピーしました。\nCloverでは、kextをファイル名（この例ではPioneerSuperDrive）で指定していました。使用するキーの名前はNameでした。OpenCoreでは、Identifierというキーで指定します。URLを逆順にしたような形式の一意の名前なので、より正確です。PioneerSuperDrive.kextがどのようなIdentifierなのかは、システム情報の拡張機能で、該当するkextを選択すると調べられます。\nidentifierは、バンドルIDという項目に書いてあります。以下のようです。Identifierの項目にはこれを書いておきます。\ncom.apple.driver.PioneerSuperDrive Enabledキーでは、このパッチを有効にするかどうかを指定します。デフォルトがfalseですので、明示的にtrueを書いておかないと有効になりません。なので追加しました。\nCountキーは発見された項目を何個置き換えるかを指定する箇所です。1個置換えてくれれば十分（それ以上検索する必要は無い）なので、1を指定しておきました。デフォルトは0で、それは発見できうる限り全て置換するという指定です。1箇所変換することで十分ならば、Countには1を指定したほうが、残りの部分を全部検索するという無駄な処理が不要になるので、高速になると思います。\nこのパッチをOpenCoreのconfig.plistに追加したところ、Pioneerのブルーレイドライブが正常に動くようになりました。パッチを施したconfig.plistを以下に置いておきます。もしこれを使用する場合は、SystemSerialNumber、SystemUUID、MLB、ROMの値を必ず置換えてください。\nOpenCore config.plist for 9900K - Pastebin.com\nPlistEDPlusで編集 （追記）PlistEDPlusでOpenCore 0.6.9のconfig.plistを編集する様子を以下に示します。いくつか項目が増えていますがデフォルトで良いです。データがASCII表示もされるので確認が楽です。\nまとめ Cloverに当てていた光学ドライブのパッチを、OpenCoreのconfig.plist用に書き換えて動作を確認しました。CloverとOpenCoreでは、パッチのキー構成が多少違います。Cloverに当てていた他のkext用パッチも、必要に応じてOpenCoreに移行して、動作を確認していこうと考えています。\n","date":"2020-05-17T11:16:49+09:00","image":"/uploads/2018/10/20181029215850.png","permalink":"/posts/9006/","title":"Pioneer光学ドライブのパッチをOpenCoreに適用する"},{"content":"OpenCoreに移行したら再起動するたびに「safe modeでPOSTしたのでF1キーを押してsetupしてね」と言われるようになりました。config.plistでDisableRtcChecksumをtrueにすると治りました。\n追記：当初、対策2と対策3の内容で対応していましたが、コメントでTakさんからDisableRtcChecksumで対応できることを教えていただきましたので、対策1として追記しました。\nOpenCore移行したらPOSTエラー発生 ASUS ROG MAXIMUS HERO WIFI (Z390) をOpenCoreに順調に移行できたかに見えました。\nASUS Z390 + Coffee LakeのブートローダをOpenCoreにする\nでも再起動をすると、POSTのエラーメッセージが出て、SETUP画面を起動しないと先に進めなくなりました。エラーメッセージは、\nシステムはセーフモードでPOSTしました。\nこれはシステムが不安定なために前回のPOSTの試みが失敗したこと、または、電源ボタンが長押しにより強制終了されたことが原因かもしれません。\nもしUEFI設定を変更した後にPOST失敗したのでしたら、安定した設定に戻したいと希望されているでしょう。F1キーを押してSETUPを起動してください。\nとの表示です。この後、F1キーを押してSETUPに入り、そこから起動を選ぶと、今度は正しく起動します。なので大して困る状況ではないですが、次の再起動でまたこの画面になり、対応が面倒です。\nCloverの時はこのような現象はありませんでした。OpenCoreでシャットダウンして、Cloverを起動する場面でも発生します。なので、OpenCoreでシャットダウンするときに、何かしらの不具合が発生しているのかもしれないです。\nASUSでよくあること？ 検索してみたところ、同様の現象は多数報告されています。今回と同様に、CloverからOpenCoreに移行したらこうなったという人も多いです。でも過去には、Cloverでも発生していたようです。発生はしていたけど、Cloverのバージョンが上がったら治ったという報告もありました。ということで、よくある現象のようです。\n対策1：DisableRtcChecksumをtrueにする 対策2以降の記事を書いたところ、コメントでTakさんから教えていただきました。この方法で解決しました。OpenCoreコミュニティのおすすめの解決方法のようですので、対策2以降は無視していただいて良いです。config.plistのKernel, Quirksの場所にあるDisableRtcChecksumを、以下のようにtrue（デフォルトはfalse）に設定すれば治ります。OpenCore 0.5.8から可能になった方法です。\n\u0026lt;key\u0026gt;Kernel\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; （中略） \u0026lt;key\u0026gt;Quirks\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; （中略） \u0026lt;key\u0026gt;DisableRtcChecksum\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; この問題はリアルタイムクロック (RTC) が関係する問題だそうです。macOSのAppleRTC.kextが、シャットダウンするときにチェックサム値をファームウェア（電池バックアップされたマザーボード上のCMOSメモリ？）に書き込むようです。おそらくはそのことでマザーボードのデータを壊してしまうらしく、次のPOSTで失敗を引き起こしているようです。チェックサムを書き込む場所が0x58~0x59（番地？）で、DisableRtcChecksumをtrueにするとそこへの書き込みを禁止してくれるようです。以下にも説明があります。\nこの説明によると、DisableRtcChecksumをtrueにしてもまだ問題が発生するようなら、RTCMemoryFixup.kextを入れて、ブートオプションで、\nrtcfx_exclude=00-FF のようにして、0x58~0x59以外の領域も保護するようにすると良いようです。これでうまくいった場合は、ブートオプションを変更して、保護する範囲を狭めると良いようです。\n対策2：BIOSで設定する 追記：対策1が簡単で根本的なのでおすすめです。\n有効な対策の一つが、このメッセージを出さないようにBIOSで設定する方法です。メッセージをよく読むと、「BIOS設定を間違って失敗した場合は、元に戻したいと思うから、F1キーでSETUPにすぐに入れるようにしておいてあげたよ。」という意味の内容が書いてあります。どうやらsafe modeでPOSTしたこと自体は大した問題ではなくて、利便性のためにF1キーですぐにSETUPに入れるよう配慮してくれているようです。今回はBIOS設定を間違えたわけではありませんので、この「親切機能」をoffにしても良いと思います。\nBIOSの設定では、Boot, Boot Configurationの中に、Wait For ‘F1’ If Errorという項目があります。これが「POSTに不具合あったらF1キーを待つ」という設定です。デフォルトではEnabledなので、これをDisabledにします。これで問題なく起動するようになりました。\nとはいえ、大元の原因は解決できていないので、応急措置な感じは拭いきれません。探したところ、もう少し根本的な対策もあるようです。\n対策3：AppleRTCにパッチを当てる 追記：対策1の方が簡単です。そちらをおすすめします。\nこちらで対策が紹介されていました。\nOpenCore causes UEFI to POST in safe mode\nここで紹介されているパッチをOpenCoreのconfig.plistのKernel, Patchに追加したところ、この現象は発生しなくなりました。config.plistをテキストエディタで開いて、パッチを挿入します。Patchという項目は、ACPIの項目にもあるので、間違えないように注意です。（最初は間違えてしまってパッチが効きませんでした。）パッチを施したconfig.plistを以下に置いておきます。もしこのconfig.plistを使用する場合は、SystemSerialNumber、SystemUUID、MLB、ROMの値を必ず置換えてください。\nOpenCore config.plist for 9900K - Pastebin.com\nまとめ OpenCoreにしたらsafe modeでPOSTする症状が出ました。ASUSではよくあることらしいです。SETUPに入ることを求められるので面倒です。config.plistでDisableRtcChecksumをtrueにして、シャットダウン時にmacOSがチェックサムを書き込まないように設定すると治りました。ということでOpenCoreの問題ではなくて、macOSとマザーボードの相性の問題のようです。Cloverで発生していなかったのは、単にデフォルトで対策されていただけなのかもしれないです。\n","date":"2020-05-16T10:50:57+09:00","image":"/uploads/2020/05/posterror0.jpg","permalink":"/posts/8984/","title":"ASUSマザーボードがPOST失敗してF1対応を促される"},{"content":"ASUSのZ390マザーボードと9900Kの組み合わせでmacOSを動かしているマシンのブートローダーを、CloverからOpenCoreに移行しました。OpenCoreのconfig.plistはCloverに比べて複雑ですが、親切なページと便利なツールがあったので円滑に移行できました。\nOpenCoreのガイドとツール Youtubeのビデオ OpenCoreを使ってみた、という程度の記事を書きました。OpenCoreの基礎知識に関してはこちらをご覧ください。\n新ブートローダーOpenCoreを使う\nこの当時は、OpenCoreは、Cloverに比べてconfig.plistがややこしくて面倒という印象でした。設定項目が多いだけでなく、kextやSSDTやefiドライバーの一つ一つをconfig.plistで記述する必要がありました。ところが最近、YoutubeでOpenCoreの設定ビデオを見ていたら、ProperTreeという便利なツールと、手順を解説した親切なサイトが紹介されていました。ハードウェア構成も、手元のメインマシンに近いので、このビデオを参考に、OpenCoreへの移行を試すことにしました。\nOpenCore設定解説ページ こちらのページがとても親切です。デスクトップPCを対象にした解説ページです。\nconfig.plistのそれぞれの設定項目を、詳細に網羅的に説明してくれているので、Cloverよりもわかりやすいかもしれません。歴史の長いCloverは、すでに使われない設定項目なども多く、説明を探して読んでも無意味だったりすることもあります。OpenCoreの設定は、Cloverに比べて簡単ではありませんが、最新の設定方法情報がCPU別に整理されているのは助かります。\nProperTree このページでconfig.plist編集に使われているツールがProperTreeです。ProperTreeはPythonで書かれたクロスプラットフォームのプロパティ編集ソフトで、macOSやhackintoshを前提としたツールではありません。それに、RedditのHackintoshサブレディットで活躍されているcorpnewtさんが手を入れて、OpenCoreのための機能を追加されたようです。\nGitHub - corpnewt/ProperTree: Cross platform GUI plist editor written in python.\n今まで、config.plistはテキストエディタで編集する、というストイックな対応をしてきましたが、OpenCoreのconfig.plistは長くて複雑です。なので今後はこのツールを使っていきます。\nProperTreeを使うためには、上記のサイトからファイル一式をダウンロードします。ダウンロードしたファイルの中のProperTree.commandがメインのPythonプログラムです。ファインダーからこれを開くか、またはTerminalから起動します。ファインダーから開く場合は、Terminalのウィンドウが一つ開いて、GUIウィンドウが現れます。Automator.appなどを使えばもっとアプリケーションっぽく見せられるとは思いますが、こういう形式も無骨で良いと思います。これでconfig.plistなどを開くと、XcodeのPlistエディタのように項目を開いたり閉じたりして閲覧し、内容を変更・追加・削除できます。\nOpenCore Sanity Checker OpenCoreのconfig.plistの正常性をチェックしてくれるページです。CPUとOpenCoreのバージョンを指定して、config.plistファイルをドラッグ\u0026amp;ドロップすると検査結果を表示します。この記事の最後で、作成したconfig.plistのチェックを行いました。\nOpenCore config.plist Sanity Checker\nハードウェア構成 この記事の対象としたマシンは、以下で紹介したZ390マザーボード＋9900Kです。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\nハードウェアの構成を再掲すると、\nマザーボード： (値上がりしてますね) CPU： @ 4.00GHz グラフィックス： WiFi/Bluetooth： (中身はBCM94360CD) です。最新のmacOS, Clover, kext類の構成で、全く問題なく稼働しています。以下では、これをOpenCoreに移行します。\nファイルを入手してESPに置く OpenCoreのダウンロード 以前の記事で紹介したように、Kext Updater.appを使いました。ダウンロードした中身には、Docs, EFI, Utilitiesの3個のディレクトリがありました。DocsとUtilitiesの中身は、そのうち少しずつ調べていきたいと思います。メインなのはEFIです。\nOpenCoreの初期EFIをコピーする ダウンロードしたOpenCoreファイルの中にあったEFIフォルダは、そのままESPにコピーして使います。またDocsの中にあるSample.plistを、config.plistと改名して使います。そのために、現在のマシンのESPをマウントします。そして現行のEFIを、例えばEFI_Cloverという名前に改名します。いきなり稼働中ドライブのESPを変更するのは危険かもしれませんので、他のドライブのESPやUSBメモリのESPで試しても良いかもしれません。起動に失敗したらUEFIシェルで名前を戻せば良いと思ったので、今回はメインドライブを直接変更してしまいます。\n% 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に入れます。\n% cp -R ~/Desktop/Kext-Updates/OpenCore/EFI . % cp ~/Desktop/Kext-Updates/OpenCore/Docs/Sample.plist EFI/OC/config.plist % ls EFI\tEFI_Clover % ls EFI/OC ACPI\tDrivers\tOpenCore.efi\tTools Bootstrap\tKexts\tResources\tconfig.plist ここではTerminalでシェルコマンドを使って操作していますが、ファインダーでドラッグ\u0026amp;ドロップで行っても全く問題ありません。（ドラッグ\u0026amp;ドロップ中のスクリーンショットを撮るのが面倒だったのです、すみません）。結果としてこんな状態になりました。\nACPIの中身を用意する EFI/OCの中をこれから設定していきます。まずはACPIフォルダの中です。EFI/OCに移動して、ACPIフォルダの中を見ると、空っぽです。\n% cd EFI/OC % ls ACPI % 上記の解説ページのCoffee Lakeの説明によると、Coffee Lakeマシンに必要なSSDTは、以下の4個です。\nSSDT-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については、こちらをご覧ください。\nDSDTを編集する\n例えば、SSDT-PLUGをコンパイルする場合は、ガイドに書かれているGitHubのページに行き、Rawボタンを押します。これで現れるテキストを全部コピーします。\n次にMaciASL.appを起動し、新規ウィンドウを開いておき、ここにペーストします。\n次に、MaciASL.appのFile, Save As…メニューを選び、出てくるダイアログでFile Format:をACPI Machine Language Binaryに設定し、SSDT-PLUG.amlという名前で保存します。こうして得られた4個のSSDTをACPIディレクトリに入れます。\nあともう一つ。USBの15個制限対応のために、SSDTを作ってありました。このSSDT-UIAC.amlも、ACPIディレクトリに入れておきました。なので使用するSSDTは全部で5個になりました。\n15個制限を回避するUSBInjectAll.kextの役割と使用法\nDriversの中身を整理する Driversディレクトリは、初期状態では以下のようになっています。\n解説によると、必要なDriverは以下の2個だけのようです。\nHfsPlus.efi OpenRuntime.efi HfsPlus.efiはCloverでも使われている、HFS+ファイルシステムを読み込むドライバーです。HFS+から起動する場合に必要です。OpenRuntime.efiは、CloverでのAptioMemoryFix.efiに相当するドライバーのようです。Catalinaの時代なのでHFS+で起動することはもう無いと思いました。配布物にもHfsPlus.efi (もしくはVBoxHfs.efi) が含まれていません。そこでOpenRuntime.efiだけを使うことにします。\n使用しないドライバーを消してしまうと、後で必要になるかもしれないので、ファイルは残しておきたいと思いました。おそらく、ファイル自体はこのディレクトリに残しておいて、config.plistの方で無効にするのがOpenCore流儀なのではと思います。でも不要なファイルは所定のディレクトリから外すというClover方式に慣れているので、offにするディレクトリを作って、使わないファイルをそちらに移すことにしました。以下の例では、Drivers_offというディレクトリを作って、OpenRuntime.efi以外はそちらに移動しました。\nKextsの中身を用意する Kextsディレクトリも初期状態では空っぽです。現在、Cloverで使っている以下のkextをそのまま入れておくことにします。\nAppleALC.kext IntelMausi.kext Lilu.kext USBInjectAll.kext VirtualSMC.kext WhateverGreen.kext Toolsの中身を整理する これもDriversディレクトリと同様に、多数のファイルが初期状態で入っています。\nデバッグするときに使用するツールらしいです。上記のガイドによると全部不要らしいです。でもUEFI Shellは絶対に欲しいと思いました。なのでそれだけを残して、他はTools_offというディレクトリを作って、そちらに移動しておきました。\n以上で必要なファイルが、必要な場所に保存されました。あとはconfig.plistを設定するだけです。\nConfig.plistを設定する コメントを消す config.plistの全ての設定にはProperTreeを使います。config.plistが複雑すぎるので、テキストエディタを使うことは諦めました。ProperTreeを起動して先ほどSample.plistをコピーして作ったconfig.plistを開きます。\n最初の5項目の#WARNINGとあるのはSample.plistの警告のコメントです。不要なので削除します。行の上でコンテクストメニューを開くと、メニュー項目にRemove …があります。これを選びます。\nOC Clean Snapshotを使う ProperTreeにはOC Clean Snapshotというメニュー項目があります。この機能が凄いです。これがあることを知ったことで、OpenCoreに移行する気になりました。OpenCoreのconfig.plistで一番面倒だと思っている点は、使用するSSDT, kext, efiドライバー, efiツールなどを全部config.plistに記載しておく必要があることです。名前を書いておくだけでなく、いろいろな設定も書いておく必要があります。ディレクトリに放り込んでおくだけでokだったCloverに比べて、面倒でした。kextを起動する順番を、config.plistの記述順で指定できるので、必要な機能なのかもしれませんが。\nこのようなconfig.plistへの記述を自動化してくれるのがOC Clean Snapshotです。ProperTreeのメニューを開くと、OC SnapshotとOC Clean Snapshotの二つのメニューが現れます。\nおすすめは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の項目がありません。従来ならば手作業で修正する必要がありました。\nここでProperTreeのOC Clean Snapshotを動かします。すると、ファイルを検出するOCディレクトリの場所を聞いてきます。そこで作業中のOCディレクトリを指定します。\nすると、Kextsディレクトリに入っているkextのリストに自動的に置き換えてくれます。\nこのkextリストは、この順番に読み込まれるので、基本的なkextを先に読み込む必要があります。例えばLilu.kextは一番上に、次がVirtualSMC.kextなどの順番で記述する必要があります。ProperTreeのOC Clean Snapshot機能は、その順番も正しく判断してくれます。Kexts以外に、ACPIとDriversとToolsの中身も検索して、自動的に該当する箇所の記述を更新してくれます。\nACPIと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の方が理にかなっていますし、こちらを使うのが便利だと思います。\nACPI項目 ではガイドのページと、ProperTreeのウィンドウを見比べながら細かい設定をしていきます。まずはACPI項目です。OC Clean Snapshot機能によりAddの内容は自動設定されています。これ以外の項目は全てデフォルト（Sample.plistの記述）のままで良いようです。\nBooter項目 Quirksの項目のいくつかをデフォルトから変更します。辞書によるとquirksは、予想外の曲がり、ひねり、とか気まぐれのような意味だそうです。fuchsiaさんからコメントで教えていただいたUbuntu wikiの記載によると、ハードウェアのバグを回避するためのソフトウェア手法というような意味だそうです。ソースコードを読む時に、「なんでこんなことやっているんだろう」と不思議に思うだろうことから、予想外に曲折した状態というニュアンスで使われているのではと思いました。Sample.plistの設定から変更するQuirksは以下です。\nDevirtualiseMmio: True、slideオプションの拡張。Z390のメモリ確保に有効。 RebuildAppleMemoryMap: True、macOS互換のメモリーマップを作る。 SyncRuntimePermissions: True、Skylake以降でMATテーブルの問題を解決。 SetupVirtualMap: False、仮想アドレスの問題を解決。Skylake以降では不要。 DeviceProperties項目 この項目の設定方法はCloverの該当項目と同様です。Sample.plistの初期値ではPciRoot(0x0)/Pci(0x1b,0x0)のオーディオに関する情報しか書いてありません。\nmifjpnさんからコメントで指摘いただいたのですが、オーディオのdevice pathが違っていました。多分、マザーボードの配線によるのだと思いますが、使用したマザーボードでは、PciRoot(0x0)/Pci(0x1b,0x0)ではなくて、PciRoot(0x0)/Pci(0x1f,0x3)でした。Hackintool.appでも確認できますし、ioregコマンドでも確認できました。\n% ioreg | grep AppleHDAController | | | +-o AppleHDAController@1F,3 \u0026lt;class AppleHDAController, id 0x10000055a, registered, matched, active, busy 0 (976 ms), retain 34\u0026gt; なのでPciRoot(0x0)/Pci(0x1b,0x0)をPciRoot(0x0)/Pci(0x1f,0x3)に書き換えます。内容の方の、Layout IDはCloverの時も、Sample.plistの通り1でしたのでこれはそのままです。\nAudioに加えて、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にします。結果として、以下のようになります。\nKernel項目 Addの項目に記述するkextファイルの情報は、OC Clean Snapshot機能により自動設定されています。Quirksの項目のいくつかをデフォルトから変更します。デフォルトから変更する箇所は以下です。\nAppleCpuPmCfgLock: 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のいくつかの項目をデフォルトから変更します。\nAppleDebug: 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では、\nboot-argsのデフォルトにdebug=0x100 alcid=1を追加しますとあります。どちらも追加しなくても良いように思います。debug不要ならその指定は不要だと思います。DevicePropertiesのところで1に設定してあるので、alcid=1も不要です。 prev-lang:kbdを手持ちのキーボードに合わせて設定します。デフォルトはロシア語になっています。USキーボードの場合は656e2d55533a30にします。 を変更します。またWriteFlashはNVRAMに設定値を書き込む設定で、Trueにしますと書いてありますが、どちらでも良いように思います。\nPlatform項目 CloverのSMBIOSに相当する項目ですね。機種IDは、Mojave以降はiMac19,1, High Sierra以前はiMac18,3が良いようです。その時代に未発売なMacの機種IDは使うなということですね。現在使用中のCloverのconfig.plistからSerialNumber, BoardSerialNumber, SmUUIDをコピーして、それぞれを、\nSystemSerialNumber MLB SystemUUID にコピーしました。またROMの項目には、NICのMACアドレスを書いておけば良いようです。システム環境設定のネットワークから取得したEthernetのMACアドレスを書いておきました。\nUEFI項目 Driversの項目に記述するefiドライバーの名前は、OC Clean Snapshot機能により自動設定されています。Quirksの項目のRequestBootVarFallbackをTrueに変更します。と書いてありますが、説明読んでもあまり違いはない気がしました。\n以上でconfig.plistの設定が終了しました。それぞれの項目の説明がそれなりに書いてあるので、Cloverよりも明朗な感じです。説明資料が整っている印象があります。この状態で再起動すればOpenCoreから起動するはずです。起動しなければ、UEFI shellからEFIディレクトリの名前を書き換えて、Cloverに戻せば良いと思います。と考えて再起動を試したところ、なんと1回で成功しました。完成したconfig.plistを以下に置いておきます。SystemSerialNumber、SystemUUID、MLB、ROMの値は、これを使用せず、みなさんで必ず置換えてください。\nOpenCore config.plist for 9900K - Pastebin.com\nSanity Checkerで検証 ここで作ったconfig.plistを、OpenCore Sanity Checkerで検証しました。\nOpenCore config.plist Sanity Checker\n赤い❌マークで警告を受けたのはUEFI, Driversの箇所で、VBoxHfs.efiもしくはHFSPlus.efiが無いという項目1点だけでした。上でも説明しましたが、Catalinaより古いmacOSを使う予定がなかったので、入れてませんでした。無しのままにしておきます。\n青い❗️マークが1点、Misc, Toolsで出ていました。「You can remove the tool EFIs here」と表示されています。Toolsには、OpenShell.efiだけを入れてあります。UEFI Shellは、File Vault起動のセキュリティを回避できてしまうので、デバッグが終わったら外しておくようにという意味かと思いました。Toolsの記述を消すと、このマークは出なくなります。ただ、File Vault起動は使っていないですし、いざというときにUEFI Shellは欲しいので、これも無視しておきます。\n黄色の❓マークが、以下の3カ所で表示されていました。\nSetupVirtualMapがNoだけど通常はYesです。 DisableIoMapperがNoだけど通常はYesです。 PointerSupportModeがASUSだけど通常は空白です。 上記で説明したように、SetupVirtualMapは仮想アドレスの問題を解決する機能ですが、Skylake以降では不要とのことでNoにしました。DisableIoMapperは、VT-Dを無効にする機能ですが、BIOSで無効にできているのでNoにしました。PointerSupportModeは、大もとのSample.plistでASUSとなっていました。OpenCoreのマニュアルを調べたところ、マウスポインター操作をサポートする設定らしいのですが、ASUSのZ87, Z97マザーボードだけがサポートされているらしいです。このパラメータは指摘どおりに空白にしておきました。\nその他の設定 コメントでいただいた情報と、その後の記事で設定した項目を以下にまとめておきます。いろいろ情報をいただいて本当にありがとうございます。\n起動ボリュームの指定 初期設定のままだと、リストの最初のドライブから起動します。起動ドライブを指定するには、macOSのシステム環境設定の起動ディスクを使います。ここで、起動させたいボリュームを選ぶと、その後、それで起動するようになります。Cloverでは起動ドライブの名前などをconfig.plistに書いていましたが、OpenCoreではよりmacOSに近い方法が可能になりました。\nKext Updaterを使う Sample.plistの設定でKext Updater.appを起動すると、「Misc, Security, ExposeSensitiveDataの1, 2ビットをonにする」ように指示が出ます。デフォルトでは6だったので7にしました。コメントで教えていただきました。\nrtc-blacklistが見つからない警告 起動時に出るかもしれない警告、\nWarn:oc:setting nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:rtc-blacklist – not found oc は、NVRAMの4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102のrtc-blacklistを消すと出なくなります。 コメントで教えていただきました。\nWindowsが起動しない Misc, Boot, BlessOverrideに, \\EFI\\Microsoft\\Boot\\bootmgfw.efi などと追加します。コメントで教えていただきました。\n続きの記事 この記事に続く以下の記事でもOpenCoreの設定を行なっています。\nASUSマザーボードがPOST失敗してF1対応を促される\nPioneer光学ドライブのパッチをOpenCoreに適用する\nOpenCoreの選択画面をグラフィカルにする\nリムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する\n使用するUSBポートを15個指定する (OpenCore編)\nまとめ Z390マザーボードのマシンをCloverからOpenCoreに移行しました。それなりに時間はかかりましたが、すんなりと運びました。今回はCoffee Lake CPUマシンの移行でしたが、他のCPUについても同様に詳しい手順が説明されているので、問題なく移行可能と思います。説明資料やチュートリアルが充実していて、ツールも揃っているので、そろそろOpenCoreに移行しても大丈夫な時期になったかと感じました。細かい設定などを調べつつ、他のマシンも、順次切り替えていきたいと思います。\n","date":"2020-05-15T01:17:30+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/8895/","title":"ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする"},{"content":"中古で入手したThinkPad T460sのテカっていたJISキーボードをUSキーボードに交換しました。T460のキーボード交換は簡単です。交換後は何事もなく起動し認識してくれました。\nThinkPad T460s (6300U) にOpenCoreでCatalinaを導入\nキーボードのテカり キーボードは使い込むとテカりますよね。人の脂で汚れるわけではなくて、プラスチック表面のシボ加工が擦れて取れてしまい、プラスティック本来のツルツルな状態になってしまうのだと思います。なので、掃除しても元どおりにはなりません。擦れば擦るほどツルツルになるだけです。\n中古のノートPCはキーボードが大抵テカってます。今回入手したT460sはかなり激しく摩耗しています。一部の印字も消えています。手触りもツルツルで、触れたくない感じです。おそらく企業のリースバック品で、日々の業務で酷使されたのだと思います。大活躍できて道具として幸せだったでしょう。今後は、macOSをたまに動かすだけの暇な余生になりますが、その前に綺麗なキーボードに交換してあげたいと思います。\n交換用キーボード ThinkPad, Dell, HPなどのグローバルな製品の中古を選ぶ利点は、補修部品が比較的潤沢に流通している点だと思います。T460s用のキーボードもAmazonやAliExpressなどで売られています。今回は以下のサイトから入手しました。送料税込3,000円くらいです。T460S, T460P, T470S, T470Pなどに対応しているようです。長らくUSキーボードだけを使い続けているので、これもUSです。Linuxするとか、hackintoshするなどのコアな使い方では、設定の一部でUSキーボードしか使えない場面も多いです。コンピュータ発祥の地で使われるUSキーボードが何かと便利です。\nキーボードを交換 同世代のX260は、ほとんどバラバラに分解しないとキーボードにたどり着けないらしいですが、T460sのキーボード交換は楽です。交換手順を紹介する動画もたくさんあります。\nまずは、裏側にあるダイアルのようなプラスティックのロックを60度ほど回します。写真にはプラスドライバーが写っていますが、これでは溝を痛めそうでした。幅広のプラスチックヘラのようなものを使った方が良いです。ロックにはキーボードと南京錠のアイコンが書いてあり、分かりやすいです。キーボードは消耗品だから、古くなったら取り替えて、大事に末長く使ってください、というメッセージが感じられます。\n裏側のダイヤルを開錠状態にすると、表側のキーボードの背面板がスライドできるようになります。プラスチックヘラのような道具を使って、背面板を少しずつ上方にスライドさせると、隙間から6個のネジが見えます。下の写真では右側の3個が写ってます。\n6個のネジを緩めると、キーボードがThinkPad本体から外れます。ただ、右下部分で2本のフラットケーブルで本体とつながっています。コネクタには黒いストッパーがあり、これを跳ね上げるとフラットケーブルが外せます。\nこれでキーボードを完全に取り外せるので、新しいキーボードに交換し、逆の手順で取り付けていきます。新品のUSキーボードは美しいです。\nそしてこのキーボード、なんと光ります。初めはどうやって光らせるのかわからなかったので、macOSでは無理なのかと諦めていました。たまたま他機種のThinkPadを紹介するYoutube動画を見て、光らせ方がわかりました。Fnキーとスペースを押すと、暗くon, 明るくon, offの3段階に切り替わります。よく見たらスペースキーに、キーが光っている様子を表すアイコンがあります。\nまとめ ThinkPad T460sのキーボードを新品のUSキーボードに交換しました。裏のロックを外して、表側の6個のネジを緩め、フラットケーブルを外すだけの作業でした。macOSで問題なく動きました。\n","date":"2020-05-12T17:30:48+09:00","image":"/uploads/2020/04/t460s.jpg","permalink":"/posts/8554/","title":"ThinkPad T460sのキーボード交換"},{"content":"SSDT-PMC.amlをEFI/CLOVER/ACPI/patchedに入れると、Intel 100シリーズチップセットでもNVRAMの値が保存されるようです。Q170搭載のHP社小型デスクトップPC、HP EliteDesk 800 G2 DMで試した結果を報告します。\nこれも、「HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM にmacOSを入れる」シリーズの記事ですが、小ネタです。\nHPの小型デスクトップEliteDesk (1: macOS導入)\n300チップセットでNVRAMを使う NVRAMを使うために、従来は、EmuVariableUefi.efiドライバを入れていました。でも300シリーズチップセットではNVRAMの内容が正しく保存されない問題がありました。しかし、最近OpenCoreの成果で作られたSSDT-PMC.amlを使えば、300シリーズチップセットでもNVRAMが正しく使えます。という記事を、以下に書きました。\n300シリーズマザーボードでも本物のNVRAMを使いたい\n100チップセットでもNVRAMを使う 最近、HP EliteDesk 800 G2 DMのスリープ対策で色々試していたところ、このマシンでもEmuVariableUefi.efiではNVRAMに書き込めないことに気づきました。公開されている仕様書によると、HP EliteDesk 800 G2 DMはQ170チップセットを使っています。100シリーズチップセットでも300シリーズチップセットと同様な問題があるようです。\nそこでSSDT-PMC.amlを使ってみたところ、なんと正しくNVRAMが動きました。ということで、SSDT-PMC.amlは、300シリーズに限らず、おそらく100シリーズでも有効なようです。以下に、EmuVariableUefi.efiを使った場合と、SSDT-PMC.amlを使った場合の比較を書いておきます。\nEmuVariableUefi.efiを使う まずは、EmuVariableUefi.efiを\nEFI/CLOVER/drivers/UEFI/EmuVariableUefi.efi の場所に入れて起動した場合です。ターミナルからnvramコマンドで、意味のないhogeという名前の変数にtestという文字を登録します。nvram -pコマンドで確認できるので、そこからhogeだけ取り出して表示します。この一連の作業を行った結果を以下に示します。\n% sudo nvram hoge=test Password: % nvram -p | grep hoge hoge\ttest ここで再起動します。再起動後に、nvram -pコマンドを試すと以下になりました。\n% nvram -p | grep hoge 再起動前に設定した変数が消えています。\nSSDT-PMC.amlを使う 次にSSDT-PMC.amlを\nEFI/CLOVER/ACPI/patched/SSDT-PMC.aml に入れて起動します。この状態で、ターミナルからnvramコマンドで、同様に変数hogeにtestという文字を登録して、nvram -pコマンドで確認します。\n% sudo nvram hoge=test Password: % nvram -p | grep hoge hoge\ttest ここで再起動します。再起動後に、nvram -pコマンドを試すと以下になりました。\n% nvram -p | grep hoge hoge\ttest SSDT-PMC.amlを入れておけば、Q170チップセットでもNVRAMに値を入れて、再起動後も読み込めるようです。ちなみにSSDT-PMC.amlを入れた状態で設定した変数は、これを外してEmuVariableUefi.efiを入れた状態でも読み込めました。EmuVariableUefi.efiを使うと、再起動前に変更したり書き込んだ結果が消えてしまうものの、正しく書き込まれているNVRAM値は読めるようです。\nまとめ SSDT-PMC.amlは300シリーズチップセットだけでなく、他のチップセットでも有効なようです。300シリーズ以外のユーザの皆さんも、ぜひお試しください。その結果をコメント欄で報告いただければありがたいです。ちなみに設定してしまった意味のない変数は、\n% sudo nvram hoge= とすれば消せます。\n","date":"2020-05-09T23:34:38+09:00","image":"/uploads/2020/03/hp800g2dm.jpg","permalink":"/posts/8879/","title":"100シリーズチップセットで本物のNVRAMを使う"},{"content":"HDMI端子用のダミープラグを使ってみました。HDMI端子に挿しておくと、端子にディスプレイが繋がっているフリをしてくれます。ディスプレイ無しで動かしているmacOSサーバを安定動作させるために使いました。\nmacOSをディスプレイ無しで使う macOS Serverはいろんな機能が削られてしまって、macOSラインナップから消滅したも同然です。でももともとmacOSはUnix系OSなので、サーバーバージョンではないmacOSもサーバとして十分に使えます。小型で省電力で安価なmacOSマシンをたくさん作っていると、サーバとしても使う気になってきます。ということで、NUCマシンにディスプレイを接続しないでサーバとして使っています。作業する場合は、別マシンから画面共有を使います。\nただ、macOSをディスプレイ無しで起動すると、少し不便なことがあります。まずは大抵の場合、画面画素数が1024×768画素になってしまいます。画面共有先からフルスクリーンにすると小さいので、いちいち変更するのが面倒です。また、場合によってはディスプレイを接続しないと、起動が不安定になることもありました。ということで、ディスプレイがつながっているように見せかけてくれるダミープラグを用意しました。\nダミープラグは、ディスプレイ無しサーバ以外でも使われます。グラフィックスカードを数値計算やマイニングに使う場合に、動作を安定させるためにも使われるようです。またコメントでは、グラフィックカードに負荷を掛けてベンチマークを取るというコアな使い方を紹介いただいています。\nディスプレイ無接続Intel NUCに使用 Core i3-3217U搭載のIntel NUCで使いたかったので、必要なのはHDMI用のダミープラグです。他にもDisplay Port用、mini DP用などがあります。また昔ながらのVGA用のダミープラグもあります。HDMI用は、需要がたくさんあるので、価格が安いです。送料込みで300円未満で手に入ります。\nこれをIntel NUCに接続したところ、1080pのフルHDディスプレイとして認識されていました。ディスプレイが無いと起動しない時もあったのですが、ダミープラグを取り付けたら安定しました。\nシステム情報を見ると、通常ならメーカーを類推できる型番が表示される場所が、28E860という数字になっています。プラグ本体には4K UHDと書いてあるのですが、NUCではFHDとして動いています。おそらくmacOSのIntel HD Graphics 4000ドライバーが4K非対応なので、そのように認識されているようです。\n試しにメインマシンのRadeon RX580のHDMIポートに挿してみました。以下のように、4Kの選択肢も現れました。表記通りにUHDとして機能するようです。\n","date":"2020-05-04T13:36:06+09:00","image":"/uploads/2020/04/hdmiemulator.jpg","permalink":"/posts/8621/","title":"HDMI用ダミープラグ"},{"content":"HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM のCPUをCore i3-6100Tからi5-6500Tに交換しました。交換に先立ってBIOSも最新にしました。2コア4スレッドから4C4Tになって、ベンチマークスコアが1.4倍改善しました。\nHPの小型デスクトップEliteDesk (1: macOS導入)\n4コアCPUが使いたい スリープからの復帰で暗黒画面になってしまうことが判明して、少し残念なのですが、スリープしない設定でしばらく使うことにしました。このマシンは、リモートワークで盛り上がっているZoom専用機にしようと考えています。なのでスリープは必須ではありません。ただどうしても4コアCPUにしたいと考えました。というのも、Zoomは4コアあれば賢く背景を切り抜いて仮想背景に差し替えてくれるのですが、4コア未満では処理性能が足りないと判断されて、ブルーバックが必須になります。このことが最初からわかっていたら、4コアモデルを探すべきでした。\nHP EliteDesk 800 G2 DMの色々なグレードの仕様を探してみたところ、第6世代Core i搭載製品で使用されているCPUは、\n6100T 6500T 6600T 6700T だそうです。6500T以上なら4コアなのでZoomの要求仕様を満たします。ただ、6600T, 6700Tはほとんど中古市場に出回っていませんし、あっても高価です。その点、6500Tならば、この手の小型PCに大量に使われているためか流通量も多いです。オークションサイトで8,000円程度で取引されています。ということで6500Tを入手しました。\nBIOSを更新する CPUを新しくするならばBIOSは最新版に更新しておいた方が良いと思います。BIOSのバージョン毎に対応CPUが違う可能性がありますが、最新版ならば旧版があつかうCPUの全てに対応しているはずです。HP EliteDesk 800 G2 DM のBIOSは以下で配布されています。ただ、OSとしてWindowsを選択しないと行き着けないです。BIOS更新はWindowsを前提としているようです。\nHP EliteDesk 800 35W G2 Mini PC ソフトウェア及びドライバーのダウンロード | HP\u0026hellip;\nここからダウンロードしたファイルはexe拡張子のファイルでした。自己伸長ファイルのようです。zipなどの一般的な形式で配布してくれればmacOSで扱えて楽なのですが残念です。伸長するためにVirtualBoxでWindowsを起動しました。配布されていたファイル類は、BIOS本体の他に、多分これをインストールするためのWindowsソフトと、資料文書で構成されていました。N21_0245.binというファイルがBIOS本体のようです。一方、History.txtというファイルには、BIOS更新の記録が書かれています。ざっとみたところ、CPUのいろいろなバージョンへ、その都度対応されている様子です。また、バグも多数修正されています。こういう記録を見ると、ソフトウェアは更新すべきだなと実感します。ちなみに、購入したマシンのBIOSバージョンは2.19で、このリストのずっと下の方です。それ以降、バージョン2.45まで様々なアップデートと修正が行われているようです。\nBIOSアップデート作業は、一般のマザーボードと同様に、BIOSメニューから行えます。USBメモリーにHewlett-Packard/BIOS/new/というディレクトリを作り、その中に新BIOSのイメージファイル (N21_0245.bin) を入れれば、BIOSアップデートメニューから認識してくれます。そして無事、最新版のBIOSであるN21 Ver.02.45 12/25/2019になりました。今から4ヶ月くらい前の新しいバージョンです。\nCPUを交換 交換前のCPUを確認しておきます。6100Tは2コア4スレッドで3.2GHzです。\nCPUのヒートシンクとファンは、HP EliteDesk 800 G2 DM の中身の半分を占めています。ファンは、跳ね上げて下のメモリー交換できるようになっています。その軸受けの部分からファンを引き出して取り外すことができます。ファンはマザーボードから電源ケーブルでつながっていますが、外さなくても脇に置いておけます。\nファンを外した残りの部分、ヒートシンクはT15番のトルクスネジ3個で固定されています。ネジはコイルバネの中を通してあり、ヒートシンクはバネの力で押さえつけられています。以前、CPU交換を行ったMac Proのように、ネジを締め付ける力で直接ヒートシンクを押さえているわけではありません。なので、ネジ締めトルクは適当でも良いと思います。でもを使い正確にネジ締めします。写真にあるように工具としてカッコ良いです。このトルクドライバーで調べたところ、どのネジも30 cNm (センチニュートンメートル) で締められてました。かなり緩いです。\nファンとヒートシンクを外した状態です。ファンの電源ケーブルはつながったままです。グリースはまだしっとりしていました。また、美しく均一に塗られています。さすがはプロの技です。\nグリースをアルコールで拭き取り、CPUを交換します。新しいグリースはいつもより高級にThermal Grizzlyを使いました。グリースを塗り、薄く伸ばして、ヒートシンクを取り付けます。締め付けトルクは30 cNmです。ファンを戻せば完成です。\nこれで起動を試みましたが、なぜか数回は起動しませんでした。BIOS画面が出ず、電源ボタンを押すとすぐに電源が切れます。ビープ音が短く鳴る時もありました。それでも起動を何度か繰り返すと、5-6回目くらいにBIOS画面が出ました。CPUが変わって、BIOSが混乱していたのかもしれないです。BIOS画面が出るようになってからは全く問題なくmacOSが起動しました。CPUも正しく認識されています。コア数は倍増するのですがクロック数は2.5GHzに落ちます。\nまずはGeekbench 5のCPUスコアです。1740だったところが2442と、1.4倍ほど向上しました。\n次はCinebench R20のCPUスコア比較です。825だったところが1121になり、こちらは1.36倍くらい向上しました。\nクロックが下がった影響で、コア数が倍増しても、顕著に性能向上するわけではなかったです。コア数が倍増、スレッド数は同じ、クロック数が0.8倍なので、全体として1.4倍くらいなのは妥当なところかと思います。\nまとめ HP EliteDesk 800 G2 DM のCPUをCore i-3からCore i-5に交換しました。元々のラインナップにあったCPUだったこともあり、交換するだけで認識してくれました。性能向上は1.4倍程度でした。でも、ZoomはこのCPUを4コアの高性能CPUと認定してくれたようで、めでたく仮想背景がブルーバック無しで動くようになりました。よかったです。\n","date":"2020-05-03T18:39:11+09:00","image":"/uploads/2020/03/hp800g2dm.jpg","permalink":"/posts/8727/","title":"HPの小型デスクトップEliteDesk (5: BIOS/CPU更新)"},{"content":"M.2ソケット用のWiFi/BluetoothアダプターBCM94360NGは、OOBで使える唯一のM.2無線カードです。T460sに取り付けたところ、BIOSで拒絶されることも無く問題なく動作しました。\nBCM94360NG BCM94360NGは、M.2ソケット用のWiFi/Bluetooth無線アダプターカードです。macOSとの相性が良くて、Handoff, Airdrop, Apple Watchでのログイン, SidecarなどがOOBで動きます。M.2無線カードとしては、互換性の高い唯一のカードだと思います。おすすめです。今のところ日本のAmazonでは扱っていないですが、AliExpressでは複数の販売者から入手できます。\nAliExpressのサイトでは、macOS用無線カードを幾つかつ製造しているFenviのロゴが掲げられていました。そのサイトから送られてきたカードは、Fenviのロゴが入った透明パッケージに入っていました。\nT460sに取り付ける T460sの裏蓋を開けます。もともと付いていた無線カードは、Intelの8260NGWという製品でした。\nこれをBCM94360NGに差し替えます。どちらもアンテナ線2本のカードなので、交換は楽です。ただ、アンテナコネクタの位置が違うので、アンテナ線の取り回しが辛くなります。その上、いつものことですが、MHF4アンテナコネクタは小さくてはめにくいです。うまく位置が合えばカチッと気持ちよくはまります。ただ、元からのインテルのカードのコネクタより緩い感じで、力を入れると外れてしまいます。テープなどで固定した方が良いかもしれません。2本のアンテナは、最初のカードと同じく三角アイコンの白・黒を合わせて接続しました。ダイバーシティアンテナになっているだけだと思うので、逆にしても大丈夫とは思います。\n交換後、T460sを起動したところ、直後はBIOS画面が2-3回現れて再起動している様子でした。その後無事macOSが起動しました。ThinkPadのBIOSは、動作確認のあるパーツのwhitelistを持っていて、それ以外のパーツを取り付けると起動しないと言われていました。その制約を外すために、ThinkPad X220のmini PCIeカードを交換した際には、改造BIOSに差し替えました。でも第5世代CPU搭載のThinkPadから徐々にwhitelist方式を廃止しているらしいです。なのでT460sではwhitelistの問題無く、動作したようです。ありがたいです。\n動作チェック カードの認識状況を「システム情報」でチェックしました。まずはネットワークとしては、種類もハードウェアもAirMacと表示されました。Apple純正カードであると認識されているようです。\n次に、USBの項目でBluetooth部分を確認しました。製造元がApple Inc.となっています。これも純正のカードとして認識されているようです。ちなみに、Integrated CameraはT460sの液晶上部のカメラです。内部ではUSB接続しているようです。互換性が高かったはずです。\nソフトウェアの動作を確認したところ、App Store, iMessage, AirDrop, Sidecarが問題なく動作し、Apple Watchでのログイン認証も動作しました。iPhoneで開いていたwebページが、dockに現れるので、HandoffやContinuityも動作しているようです。Sidecarは、最初は動きませんでした。でも、以前もそうだったのですが、2-3日後になって動き始めました。Apple IDの認証に時間がかかっているなどのサーバー上の問題なのかもしれません。\nM.2無線カードのおすすめ 今まで、M.2の無線カードは、BCM943602BAEDまたはDW1830の型番で販売されているカードが互換性が高いと考えていました。\nこちらはアンテナが3本あります。WiFiの性能も上位で、今回使用したBCM94360NGが5GHzで867Mbpsなのに対して、BCM943602BAEDは1300Mbpsの規格です。なので高速なのですが、価格は3倍程度です。また、今回のT460sもそうですが、M.2無線カードはアンテナ2本が一般的なようで、ノートPCやデスクトップマザーボードでもアンテナは2本しか用意されていない場合が多いです。3本目のアンテナを追加するのに苦労します。さらには、BCM943602BAEDは完全なOOB動作をしないです。WiFiはそのまま動きますが、Bluetoothを動かすためには、いくつかのkextを追加する必要があります。\nということで、互換性からも、アンテナの本数でも、さらにはコストパフォーマンスの点でも、M.2無線カードはBCM94360NGがおすすめだと思います。将来、マザーボードのM.2カードを交換するかもしれない時のために、予備を確保しておこうかと思っています。\nまとめ ThinkPad T460sにM.2無線カードであるBCM94360NGを取り付けました。今のところmacOSの全ての機能が問題なく動いています。ThinkPadのBIOS whitelist機能によりカード交換が拒絶されるのではという心配も無用でした。BCM94360NGはmacOS下でOOBで動く、互換性の高い唯一のM.2無線カードだと思います。\n","date":"2020-04-27T22:19:13+09:00","image":"/uploads/2020/04/BCM94360NG.png","permalink":"/posts/8579/","title":"ThinkPad T460s にWiFi/BTカードBCM94360NGを取り付ける"},{"content":"HP EliteDesk 800 G2 DM (Core i3-6100T)がスリープ復帰後にブラックスクリーンになることに気づきました。Intel HD Graphics 530特有の問題のようで解決策が無いようです。\n症状 前回、このマシンにmacOSをインストールして、オーディオを設定し、USBの設定をしました。順調に動いていると思っていたのですが、スリープ復帰後に画面が暗いままであることに気づきました。映像信号が止まっていて、しばらく放置するとディスプレイが自動パワーoffします。でも画面が暗い状態でも画面共有からは正しく表示して操作できます。スリープ復帰後のiGPUの動作がおかしい様子で、macOS自体は正しく動き続けているようです。実は、主に画面共有して他のマシンから使用していたので、この問題に気づきませんでした。\n解決策は無い？ 色々調べたのですが、こちらのフォーラムの流れを見る限り、\nどうやらIntel HD Graphics 530とmacOSの相性の問題のようで、解決策は無い様子です。HD 530はiMacなどで使用されているので、使えそうに思ったのですが残念です。当面はスリープしない設定で使うことにしつつ、引き続き調べてみます。\nWindowsでも発生してる？ いろいろ検索したところWindows 10でHD Graphics 530がスリープ復帰後に暗黒画面になるという報告もあるようです。macOSだけの問題ではないのかもしれないです。\nhttps://forums.intel.com/s/question/0D50P0000490M51SAE https://forum-en.msi.com/index.php?topic=297728.0 ","date":"2020-04-27T00:33:07+09:00","image":"/uploads/2020/03/hp800g2dm.jpg","permalink":"/posts/8583/","title":"HPの小型デスクトップEliteDesk (4: 暗黒画面問題で頓挫)"},{"content":"ThinkPad T460sのBIOSを更新しました。通常はWindows用アプリケーションで更新するようですが、macOSでBIOS更新用USBメモリーを作りました。Windowsを使わずに更新できました。\nThinkPadのBIOS ThinkPad T460sで作ったhackintoshの続きです。\nThinkPad T460s (6300U) にOpenCoreでCatalinaを導入\nBIOS設定画面で見ると、BIOSバージョンが古いことが気になっていました。2016年11月30日版の1.20です。\nLenovoのサポートサイトで配布されているBIOSは2019年12月13日版の1.47です。\nBIOS アップデート (ユーティリティ および 起動CD用) (Windows 10 64bit/ 8.1 64b\u0026hellip;\nBIOSが古くても動いていれば問題なしです。むしろ新しくすることでOSが動かなくなる可能性もあります。サポートサイトに「問題なく動いているならBIOSは更新しなくても良い」と書いているマザーボードメーカもあります。でもソフトウェアには必ずバグがあって、それをバージョンアップで直してます。なので、アプリケーションも、OSも、BIOSもとにかく最新版にしたいと常々思っています。ということでThinkPadのBIOSを最新版にバージョンアップしました。\n上記のサイトによるとBIOSバージョンアップには次の3通りの方法があるようです。\nWindowsのツールをダウンロードして起動する CD-ROM用isoファイルをダウンロードしてCD-ROMを焼いてそれで起動する 新BIOSのデータをダウンロードしてLinuxのツールを使う です。通常のマザーボードだと、BIOSのメニューからUSBメモリに入れた新BIOSデータを指定して更新できます。でもThinkPadのBIOSにはそのようなメニューがありません。ユーザがうっかりBIOSを書き換えられないようにしてあるのだと思います。\n1番のWindowsのツールは使いません。Windowsは使わないので、入手してすぐに内蔵SSDを初期化して消してしまったからです。残しておけば良かったと若干後悔していないわけではないですが、新たにインストールするのは面倒です。\n3番のLinuxのを使う方法は試しました。UbuntuのLive CDイメージをUSBメモリーに焼いて起動して、ダウンロードしたBIOSイメージを指示されたLinuxコマンドで書き込もうとしました。しかしハードウェアを認識できないというメッセージが出て、更新できませんでした。Live CDなのでダメだったのかもしれません。でも新たにインストールするのは面倒なので、断念しました。\nそこで、2番目の起動CD-ROMイメージを使う方法を採用しました。ただ、CD-ROMを焼くのも、ThinkPadにUSB接続CD-ROMドライブを接続するのも面倒なので、これもUSBメモリーから起動させるようにします。手順は以下です。\nBIOS更新手順 Step 1: 起動CD-ROM用isoファイルを入手する 上記のLenovoのサイトから、「BIOS アップデートユーティリティ (起動CD用)」をダウンロードします。n1cur34w.isoという名前の24.5MBのファイルを入手できました。\nStep 2: isoファイルをUSBメモリイメージファイルに変換する 起動用CD-ROMのデータと起動用USBメモリのデータは多少違うようです。ブートのためのファイルの配置場所などが違うのではないかと思います。なので、isoファイルを、起動用USBメモリー用のファイルに変換します。このツールとして、geteltorito.plというツールを以下のサイトから入手します。\nIndex of /~krienke/ftp/noarch/geteltorito\nこれはperlで書かれたプログラムなのでmacOSでも動きます。これを使い、ターミナルで以下のようにタイプします。\n% ./geteltorito.pl -o bios.img n1cur34w.iso ここでは、n1cur34w.isoからbios.imgというファイルを作っています。この結果、以下のように表示され、bios.imgが生成されました。\n% ./geteltorito.pl -o bios.img n1cur34w.iso Booting catalog starts at sector: 20 Manufacturer of CD: NERO BURNING ROM Image architecture: x86 Boot media type is: harddisk El Torito image starts at sector 27 and has 47104 sector(s) of 512 Bytes Image has been written to file \u0026#34;bios.img\u0026#34;. Step 3: imgファイルをUSBメモリーに書き込む USBメモリーを用意します。容量は24MBあれば良いです。手元にあった8GBのメモリーを使いました。一応、マスターブートレコードスキーム、FAT32でフォーマットして、アンマウントしておきました。次にddコマンドを使うので、このようなフォーマット作業は不要だったかもしれません。\n次にターミナルからddコマンドで、USBメモリーにimgファイルを書き込みます。ddコマンドはファイルシステムなどは無視して、物理的に書き込んでいくコマンドです。USBメモリの場所がdisk2でしたので、以下のコマンドで書き込みます。disk2ではなくrdisk2にしたのは、その方が少し高速らしいからです。容量が小さいので/dev/disk2でも問題ありません。\n% sudo dd if=bios.img of=/dev/rdisk2 その結果、以下のような表示が出て、USBメモリーが完成します。\n% sudo dd if=bios.img of=/dev/rdisk2 47104+0 records in 47104+0 records out 24117248 bytes transferred in 15.043802 secs (1603135 bytes/sec) Step 4: USBメモリーで起動してBIOSを書き換える このUSBメモリーをThinkPadに挿し、起動します。その際にF12を連打します。すると起動ドライブ選択画面になるので、USBメモリーを選択します。BIOSでLegacy bootに設定しなければならないというネット上情報もありましたが、UEFI bootのままで大丈夫でした。USBメモリーで起動すると、以下のような画面になります。\n1.のRead this first…は一応目を通しておいた方が良いです。2.のUpdate system programを選択すると、いろいろと警告が出てから、BIOS更新が行われます。\n新BIOSを試す BIOS画面でバージョンを確認します。最新バージョンになっていました。\nmacOSの起動にも問題ありませんでした。BIOSが更新されたから何が良くなったというわけではないので、単なる気持ちの問題です。\n苦労したところ 起動用CD-ROMデータであるisoファイルから、起動用USBメモリーデータであるimg（またはdmg) ファイルに変換する際に、hdiutilというコマンドがお馴染みでした。例えば、今回のようにn1cur34w.isoという名前のファイルでしたら、\n% hdiutil convert -format UDRW -o n1cur34w n1cur34w.iso のコマンドで、n1cur34w.dmgというファイルが出来上がります。dmgとimgは同じもののようで、改名しても良いようです。また、UDRWというのは、read/writeできる光ディスクのフォーマットのようです。こうして作った結果のファイルを、ddコマンドでUSBメモリーに書き込めば、起動USBメモリーが作れるはずです。\nしかし、ThinkPadでは起動しませんでした。BIOS設定を色々試したのですがダメでした。ところがこのUSBメモリーを、ASUSマザーボードの自作デスクトップで起動したら、メニュー画面が現れます。他のisoファイルで試しましたが、同様に、自作PCでは起動するものの、ThinkPadでは起動しません。そこで色々試行錯誤して、ネットを検索したところ、ThinkPadで起動させるためには、上で使用したgeteltorito.plが使えることがわかりました。\nまとめ ThinkPad T450sのBIOSが古かった (2016年版) ので最新版 (2019年版) に更新しました。サポートサイトで配布されている起動用CDのデータを変換してUSBメモリーに書き込みました。変換には通常のhdiutilコマンドではなく、ネットで配布されていたperlプログラムを使いました。BIOSが新しくなって変化した点はありませんが、以前と同じようにmacOSが起動しています。\n","date":"2020-04-25T00:34:02+09:00","image":"/uploads/2020/04/t460s.jpg","permalink":"/posts/8556/","title":"ThinkPad T460sのBIOSを更新する"},{"content":"Skylake 6300Uを搭載したThinkPad T460sにOpenCore (OC) でmacOS Catalinaをインストールしました。手順と必要ファイルが揃っているGitHubページがあったので、苦労なしで完成度の高いmacOSマシンが出来上がりました。\n動作状況 最初に動作状況をまとめておきます。完成度はかなり高いです。\n動くこと macOS Catalina 10.15.4 macOSのアップデート (10.15 –\u0026gt; 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をインストールします。\nLenovo ThinkPad X220, 2620M\nX220は昔ながらの作りの良いキーボードを採用した最後のモデルです。でも第2世代Sandy Bridge CPUなのでCatalinaは公式サポートされてません。次にノートPCでhackintoshするなら、現行macOSが動く第3世代 (IvyBridge) 以降のCPUで試したいと思っていました。また、先日、HPのHP EliteDesk 800 G2 DMがとても簡単に動いて、気に入っていました。\nHPの小型デスクトップEliteDesk (1: macOS導入)\n第6世代 (Skylake)はmacOSとの相性が良さそうな気がします。またSkylakeならCatalinaで動くだけでなく、Sidecarにもギリギリ対応しています。Kaby Lake, Coffee Lakeならばさらに新しくて良いのですが、遊ぶ目的としてはまだ高価です。Lakeシリーズ初代のSkylake搭載製品ならば、5-6年前の製品なので、リース終了後の法人物件が出回っていて、値段が手ごろです。8GBメモリ、256GB SSD程度の構成で、デスクトップなら1万円代、ノートPCでも2万円代で中古品が購入可能です。\nSkylake搭載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ページを発見できてラッキーでした。\n到着して開封した時、予想以上に薄いので驚きました。実は、T460とT460sは販路が違うだけで同じものだと思い込んでいました。ネットにあったT460の分解動画をいくつか見ていて、その厚さだと思ってました。sが付くだけで全然違うモデルなのですね。T460は、2.5 inch SSD, 取り外し可能バッテリーなのに対して、T460sは、M.2 SSD, 内蔵バッテリーのみになり、薄くなっています。他にもいくつか変更されています。メモリーソケットが2個から1個に減っています。これは少し残念ですが、マザーボードに8GB搭載されていたので十分です。T460sになって一番嬉しいことは、裏蓋を止めている爪が簡単に外れるようになったことです。T460の分解動画では裏蓋の隙間にヘラを入れてベキベキと外していた様子だったのが、なんの苦労もなく裏蓋が外れます。裏蓋を止めているネジも8個から5個に減りました。\n入手したT460sの液晶はfull HDのIPS液晶でした。国内販売品は全部FHDのようです。タッチ入力対応のモデルもありますが、macOSでは不要でしょう。\nキーボードは相当にテカってます。プラスチック表面のシボ加工が取れて、ツルツルの面になってます。汚れているわけではないですが、触るとペタペタした感触があります。さらにはA, H, Nなどのキーは文字も消えかけています。前のユーザのお役に立って活躍していたようです。で売ってますので、交換したいと考えています。同じ世代のThinkPadでもX260はキーボード交換がかなり面倒なのですが、T460シリーズはThinkPadの伝統を引き継いでいて、交換が楽です。\n裏蓋は5個のネジで外れます。ネジは蓋から外れない方式なので、行方不明になる心配がありません。分解動画で比較すると、T460に比べてT460sは爪がすぐに外れるように作られているようで、分解が楽です。裏蓋を開けた中は以下のようです。\n内蔵バッテリーが写真の上下に2個あります。全体にかなり薄型なのですが、まだまだいろいろいじれる部品構成です。中央右のヒートパイプの端あたりにCPUがあります。その下に、DDR4 SODIMMの空ソケットが一つあります。マザーボードにメモリーが既に搭載されていて（今回入手したモデルは8GB）、これに加えて増設できます。CPU左側の黒い絶縁シートが貼られた大きなエリアは、空き地です。Nvidia GeForce 930MというGPUを搭載するモデルがあり、そのGPUの接点がある場所です。macOSではサポートされていないGPUですので、GPU搭載モデルを選ぶ必要はありません。\n左の部分には3種類のM.2のソケットがあります。それぞれ、WLAN, WWAN, SSD用です。WLANはインテルのM.2モジュールが取り付けられています。無線LANとBluetoothが搭載されています。インテルの無線LANはmacOSでは使えません。Bluetoothはどういうわけかシステム環境設定に現れますが、これも使用不可能です。BroadcomのM.2モジュールに交換する予定です。参考にしたGitHubページでは、M.2用アダプタを使って純正のBroadcomモジュール、BCM94360CS2を取り付ける様子が紹介されています。厚みが増えるため裏蓋が少し浮くようですが、この方式ならmacOSとの互換性は完璧です。\nWWAN用のM.2ソケットは空です。でもアンテナは配線されています。国内の一般販路ではWWANモデルは流通していないらしいです。\nM.2 SSDソケットには切り欠きが2箇所あるSSDが装着されていました。型番から東芝のSATAタイプの256GB M.2 SSDだと判明しました。これだけ容量があれば、macOSの動作には問題ありません。手元のSSDで試したところ、NVMe方式のM.2 SSD（切り欠きが1箇所のタイプ）も使えました。\nOpenCoreで導入を試みる 今回のmacOS導入は、全く努力してなくて、落ちていたESPファイル類を拾ってコピーしただけのヘタレなハッキングです。こちらのサイトのおかげです。本当に感謝したいです。\nGitHub - simprecicchiani/ThinkPad-T460s-macOS-OpenCore: Bootloader configurat\u0026hellip;\n実はこのGitHubページは、先月末にできたばかりのようです。このページを使ってT460sでmacOSを動かせたことが、T460sの到着前日にRedditで紹介されていて知りました。デスクトップに比べてノートPCのhackintoshは複雑なので、tonymacx86やredditで実績のある機種を選んだ後で、実際に調達するという手順が良いように思います。\nBIOSを設定する 上記のサイトにはBIOS設定も書いてあります。以下の設定が必要とのことです。\nSecurity -\u0026gt; Security Chip Disabled Memory Protection -\u0026gt; Execution Prevention Enabled Virtualization -\u0026gt; Intel Virtualization Technology Enabled Virtualization -\u0026gt; Intel VT-d Feature Disabled Anti-Theft -\u0026gt; Current Setting Disabled Anti-Theft -\u0026gt; Computrace -\u0026gt; Current Setting Disabled Secure Boot -\u0026gt; Secure Boot Disabled Intel SGX -\u0026gt; Intel SGX Control Disabled Device Guard -\u0026gt; Disabled UEFI/Legacy Boot -\u0026gt; UEFI Only CSM Support -\u0026gt; No これ以外も趣味に合わせて設定しました。例えば、WiFi, Bluetooth, 指紋センサー、SDカード読み取り機などはmacOSで動きませんので、節電になるかと思いdisabledに設定しました。\nmacOS導入用USBメモリを作成する まずは通常のhackintoshの手順に従って、まずはインストール用のUSBメモリーを作成しました。Appleのサイトに書いてあるようにcreateinstallmediaコマンドを使います。こうして作成したUSBメモリのESP (EFI System Partition) をマウントします（diskutil listコマンドでUSBメモリのESPが例えばdisk5s1だとわかったら、sudo diskutil mount disk5s1とタイプします）。次に、上記のサイトからダウンロードしたESPの内容を、ごっそりとUSBメモリのESPにコピーします。ファインダーのドラッグ\u0026amp;ドロップで可能です。\nこうして設定されるkext類は以下です。VoodooPS2Controllerなどは、キーボードやトラックポイントを動かすためのkextだと思います。\nWhateverGreen.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に比べると少ないですね。\nOpenRuntime.efi HfsPlus.efi ApfsDriverLoader.efi SSDT類は大量にあります。バッテリー、電力制御、PS2関係など色々用意されているようです。これらを自分で作るのは大変なので、ありがたいです。\nSSDT-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には個別のマシンの情報が入っていないので、それだけは編集します。\nCloverとOCでは個別マシン情報の項目名が異なります。Cloverのconfig.plistでSerialNumberとBoardSerialNumberは、OCのconfig.plistでは、それぞれPlatformInfo, Genericの中のSystemSerialNumberとMLBに相当します。Cloverの時と同様にClover Configuratorなどで生成して、シリアル番号が使えるかどうかをAppleのサイトで確認して、その値を記入します。SystemUUIDも、ターミナルのuuidgenコマンドを使って生成して設定します。\nまた、PlatformInfo, Generic, ROMの値も独自の値を入力します。これは6バイトの数値です。サンプルでは0x112233440000というような値が入っています。世界に存在しない独自の値を入れれば良いようで、通常はEthernetのMACアドレスを使います。これは、システム環境設定、ネットワーク、Ethernet、詳細、ハードウェアと辿ると分かります。例えばこれがc0:7e:bf:c3:af:ffでしたら、\necho -en \u0026#34;\\xc0\\x7e\\xbf\\xc3\\xaf\\xff\u0026#34; | base64 wH6/w6// とするとbase64値、この場合wH6/w6//が得られます。これをチェックするには、\necho -n wH6/w6// | base64 -d | hexdump 0000000 c0 7e bf c3 af ff とすれば確認できます。この値を、PlatformInfo, Generic, ROMのところに\n\u0026lt;key\u0026gt;ROM\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;wH6/w6//\u0026lt;/data\u0026gt; として書き込みます。\nUSBメモリで起動してmacOS導入 これでOCから問題なくmacOSのインストーラが起動しました。まずは東芝のM.2 SATA SSDをAPFSでフォーマットしてインストールを試みました。するとmacOSのインストール先にAPFSドライブを選択できません。「APFSのボリュームにインストールするためにはMacのfirmwareアップデートが必要だからHFS+を選べ」と言っているようです。MacBookPro13,1はSierraの時代のマシンですので、firmwareがAPFS起動に対応していないです。なのでmacOSインストールの時についでにfirmwareアップデートも行われます。この場面では、firmwareアップデート前の状態と判断されたので、APFSが選べなくなっているのだと思います。\nYour 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+に戻せなくなってました。ターミナルから\ndiskutil eraseDisk JHFS+ \u0026#34;Macintosh HD\u0026#34; disk0 などすればHFS+に戻せます（対象がdisk0だった場合の例です）。\nこれでインストール先として選択できるようになるのですが、インストールを少し進めると、以下のようなエラーメッセージで止まってしまいました。firmwareを検証中にエラーが出るようです。\nAn error occurred while verifying firmware. hackintoshなのでfirmwareのバージョン等情報がおかしいのは当然です。Cloverはそれを自動的に偽装してくれます。また、config.plistのBiosReleaseDateやBiosVersionの項目で偽装用の情報を指定することもできます。同じようなfirmwareバージョン偽装設定をOCのconfig.plistでやろうとしたのですが、方法がわかりませんでした。Cloverの項目名では判別できないというエラーが出ました。\nCloverで導入を試みる この状況に対処するために、M.2 SSDをmacOSマシンに接続してmacOSをインストールすることも可能だったと思います。でも今回は、手元にM.2 SATA SSDをUSB変換するアダプタがなかったので、Cloverで起動することに方針変換しました。kextとSSDTはこのGitHubページのものをそのまま使いました。UEFIドライバは、Cloverでいつも使っている内容です。\nVirtualSmc.efi VBoxHfs.efi OsxAptioFix3Drv.efi FSInject.efi EmuVariableUefi.efi ApfsDriverLoader.efi config.plistも、Cloverで使っているシンプルなものを使いました。ただDevicesの場所は、OCのconfig.plistを参考にして以下の設定にしました。\n\u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAWGQ==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;enable-hdmi20\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-fbmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AACQAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-stolenmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAwAQ==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-unifiedmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAAgA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; この設定によると、ig-platform-idは0x19160000です。こちらのサイトによると、Intel HD Graphics 510から580搭載laptopのための推奨値のようです。\nこの結果、Cloverでも無事起動して、しかも今回はfirmware関係のエラーメッセージも出ず、順調にmacOSインストールが可能でした。macOSをM.2 SATA SSDにインストールした後で、そのSSDのESPにも、インストール用USBメモリーと同じ内容をコピーしました。これでSSDからCatalinaが起動します。\n動作確認とベンチマーク このMacについて、を見ると以下のようです。Thunderbolt 3のあるモデル番号なので、無いのに表示されてしまいました。\nCPUの名前は、以下のコマンドで確認できます。\nsysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz 正しく6300Uだと認識されています。Geekbench 5でスコアをとってみました。Haswell, Broadwell, Skylakeあたりはだいたい同じくらいのスコアですね。2コアなのでそれほどスコアが上がりません。\n結局OpenCoreに移行する Cloverでほぼ問題なく動いている様子でしたが、バッテリーの表示が正しく表示されないことに気づきました。GitHubからダウンロードしたそのままのOpenCoreのESP内容に置き換えて起動したところ、今度はバッテリー残量が表示されました。\nCloverでも、おそらくはちゃんと設定すれば、バッテリー残量の表示を可能にできたとは思います。でも、楽ですし、時代はOpenCoreに移行する方向らしいので、結局、最初のようにOCで使うことにしました。firmwareの確認は初めてAPFSを使うときにのみ現れる様子で、macOSアップデートなどでは問題ないようです。\n以下に続きます 引き続き、WiFiを整備したり、キーボードを交換したりしたいと計画しています。以下もご覧ください。\nThinkPad T460sのBIOSを更新する\nThinkPad T460s にWiFi/BTカードBCM94360NGを取り付ける\nThinkPad T460sのキーボード交換\nまとめ この機種用の情報を提供してくれたGitHubページのおかげで、完成度の高いmacOSノートPCが完成しました。実のところかなり気に入っています。無線カードなどを調達して、もう少し遊んでみたいと思います。\n","date":"2020-04-14T22:53:41+09:00","image":"/uploads/2020/04/aboutthismac.jpg","permalink":"/posts/8399/","title":"ThinkPad T460s (6300U) にOpenCoreでCatalinaを導入"},{"content":"HDMI端子からUSB 3.0経由でフルHD動画を取り込めるアダプターを使ってみました。USB Video Class (UVC) というUSB標準のデバイスクラスに対応しているので、macOSで（hackintoshでも）OOBで使用できます。\nUSB Device Class USBの規格には、データを通信するための基本的な規格の他に、もっと上位の、使用目的別のプロトコルを決めたDevice Classという規格があります。macOSは多くのDevice Classを標準でサポートしてます。なので、様々なデバイスを、それ専用のデバイスドライバーをインストールすることなく、OOBで動かすことができます。この状況は、USBの基本的なデータ通信ができていれば、hackintoshでも同じです。なので、キーボードやマウス (HID class)、USBメモリー (Mass storage class)、USBスピーカー (Audio class)、webカメラ (Video class)などが、hackintoshでもMacと同様に、ドライバー不要で使用することができます。\nUSBビデオキャプチャー HDMI端子から1080pのフルHD (FHD) 動画を取り込めるUSB Video Class (UVC) 対応ビデオキャプチャー製品が多数出回っています。これを使えばHDMI動画を、webカメラからの映像のように取り込むことができます。macOS標準機能で動画を録画したり、ゲーム配信、動画配信、ビデオ会議でHDMI映像を流すことも可能です。動画を取り込むのは、昔は結構大変でした。MacだとIEEE 1394とか使ってました。\nIEEE 1394 (FireWire) を使う\nでも今ならUSB が十分速いので、安価なデバイスが使えます。AmazonやAliExpressで、USBビデオキャプチャーとして販売されている製品は、大体がUVC対応なので、macOSで使用可能です。\nこれなどは1,599円と格安です。ただし、USB 2.0接続で、フルHDで取り込めるのは30fpsまでです。\nUSB 3.0接続になると値段が高くなります。その代わりフルHDで60fpsの取り込みが可能になります。さらにこれはHDMI出力もついています。\n実は、1年以上前に入手したまま未開封だったこちらの製品が手元にありました。USB 3.0接続でフルHD 60fps対応の製品です。今回はこちらを使ってみました。\n大きさはクレジットカードくらいの小さなアルミ製の箱です。放熱効果は良いようで、長時間使用してもそれほど熱くなりません。入出力はシンプルで、HDMI入力、USBコネクタ、LEDがあるだけです。USBが特殊で、Type-Aのコネクタがついています。本来ならばType-Bが正しいと思います。なので、両端がType-Aになった、あまり見かけない、USBケーブルが付属しています。これをmacOSマシンに接続します。\nUVC規格なので、macOSからは通常のwebカメラのように認識されます。例えばPhotoBoothから見たところ、FHD Webcameraという名前で見えていて、HDMIの動画を取り込んで利用できます。FaceTime, Skype, Zoomなどのアプリケーションからも同様にこの名前で認識されています。\nHDMIの音声に関しては、USB Audio Classデバイスとして機能している様子です。webカメラのマイクロフォンのような扱いです。システム環境設定–\u0026gt;サウンド–\u0026gt;入力を見ると、マザーボードの音声入力端子と並んで、FHD Webcameraという名前で見えています。\nHDMI動画を撮影する これがあれば、HDMI端子の映像ならばなんでも取り込めます。例えば、Intel NUCを起動して、BIOS設定画面を開いて再起動して、CloverでmacOSを起動する様子もキャプチャすることができます。以下の動画は、QuickTime Playerの動画取り込み機能を利用して作成した動画です。取り込んだ生データは1080pの画素数ですが、動画編集ソフトで720pに削減してあります。また起動過程の一部をカットしてあります。\nBootmacOSfromNUC230a.m4v\nまとめ USB接続のHDMIビデオキャプチャデバイスを試しました。OOBで使用することができました。高性能CPUと大容量HDDを搭載した自作PCを使ったhackintoshは、動画編集や動画配信に最適だと思います。HDMI出力のゲーム機の画面も取り込めるので、ゲーム実況にも使えます。動画配信、テレビ会議などで自作hackintoshの強みを生かせると思います。\n","date":"2020-04-11T18:59:17+09:00","image":"/uploads/2020/04/hdmiusb.jpg","permalink":"/posts/8366/","title":"USB接続のHDMIビデオキャプチャを使う"},{"content":"初代NUC、DC3217の表示が乱れてしまいました。2個あるHDMIのうちの片方が異常で、もう一方は正常です。WhateverGreen.kextで設定フラグを同一にしたら、両方とも正常になりました。\n症状 DC3217は最初に販売されたCore i搭載NUCで、Ivy Bridge Core i3-3217Uを搭載しています。GPUはIntel HD Graphics 4000です。こちらの構成です。\nIntel NUC DC3217, 3217U\nサーバ的に常時稼働させていて、必要な時は画面共有で接続していました。Clover r5108のアップグレードのためにディスプレイに接続したら、画面が乱れていることに気づきました。ログイン画面がこんな表示になります。横方向の画素数が正しく伝わっていない様子です。ロストテクノロジーのアナログテレビで例えると水平同期が取れていない感じかな。\nいつからこうなったのか不明です。前回のClover r5107アップデートか、macOS 10.15.4へのアップデートあたりがきっかけかもしれません。また、このディスプレイはメインマシンで使っているのですが、最近起動直後に色がおかしいことがあります。NUCの問題ではなくディスプレイが不調で、設定情報EDIDがうまく送出できなくなっているのかもしれません。\nig-platform-idの決め方 ig-platform-idは0x01620005にしてあります。config.plistのDevices –\u0026gt; Propertiesセクションには、これのBase64値であるBQBiAQ==が設定してあり、WhateverGreen.kext (WEG)にこの値を伝えてあります。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BQBiAQ==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; どういう理由でig-platform-idを0x01620005にしたのか、もはや記憶がありません。多分、どこかでNUC DC3217の作例を見て、真似たのだと思います。最近、ig-platform-idのことを調べたので、今なら少し説明できるかと思います。\nまずは、Intel HD Graphics 4000で使えそうなig-platform-idを探します。こちらのサイトによると、以下のIDが知られているようです。\n0x01660000 (desktop, 4 connectors, 24 MB) 0x01620006 (desktop, 0 connectors, no fbmem, 0 bytes) 0x01620007 (desktop, 0 connectors, no fbmem, 0 bytes) 0x01620005 (desktop, 3 connectors, 16 MB) 0x01660001 (mobile, 4 connectors, 24 MB) 0x01660002 (mobile, 1 connectors, 24 MB) 0x01660008 (mobile, 3 connectors, 16 MB) 0x01660009 (mobile, 3 connectors, 16 MB) 0x01660003 (mobile, 4 connectors, 16 MB) 0x01660004 (mobile, 1 connectors, 16 MB) 0x0166000A (desktop, 3 connectors, 16 MB) 0x0166000B (desktop, 3 connectors, 16 MB) ここでmobileと書かれたidは、一つのビデオ端子がLVDSになっています。LVDSというのは、LCDのためのインタフェースだそうです。ノートPCを使う場合はこれのどれかを使いますが、NUCもそうですが、デスクトップ構成ではLCDインタフェースは使わないので、desktopのidから選びます。また、端子が無い (0個の) idは、ヘッドレス構成、つまりiGPUにはディスプレイを接続しないで、PCIe接続のグラフィックスカードを使う場合に使います。なので、iGPUを外部ディスプレイに接続するNUCの構成では、desktopで端子ありのidを使うことになります。つまり以下のどれかです。\n0x01660000 (desktop, 4 connectors, 24 MB) 0x01620005 (desktop, 3 connectors, 16 MB) (推奨) 0x0166000A (desktop, 3 connectors, 16 MB) (推奨、default, Macmini6,1) 0x0166000B (desktop, 3 connectors, 16 MB) (Macmini6,2) 上記のサイトでは、推奨idが0x0166000A (default), 0x01620005 であると書いています。またHackintool.appでは、0x0166000AがMacmini6,1、0x0166000BがMacmini6,2であると表示されます。おそらく、SMBIOSでそれぞれのMac miniのシステムIDを設定すると、何も指定しなければそれぞれ、0x0166000Aまたは0x0166000Bが選択されるのだと思います。\n選択肢が4個だけなので、これを全部試してみました。その結果、DC3217では、0x01620005 だけが使えることがわかりました。それ以外の3個では、次のような症状になります：つまり、Cloverの起動ボリューム選択画面の後の林檎マーク表示で、進捗バーが止まります。-vモードで起動すると、文字表示がIOConsoleUsers: …というような表示場所で滞ります。でも、実は表示以外は起動していて、画面共有で接続すると機能しているようでした。\nig-platform-idに0x01620005を設定するには、config.plistのDevices–\u0026gt;Propertiesセクションに以下のように書きます。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BQBiAQ==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; 症状をもっと調べる 0x01620005を設定することで、長らく正しく表示できていたのですが、最初に述べたように、画面が乱れるようになりました。乱れていても、画面共有で接続すると正しく動いているようです。また、起動時にディスプレイを接続せず、起動した後で接続すると正しく表示されます。先に述べたように設定情報EDID関係なのかもしれません。\nさらに、もっと興味深いことを発見しました。DC3217には、2個のHDMI端子がついています。以下、左（電源端子に近い方）をHDMI(1)、右（LAN端子に近い方）をHDMI(2)と呼びます。\n画面が乱れる現象は、HDMI(2)で発生します。HDMI(1)を使えば、どのタイミングでディスプレイに接続しても、画面は乱れません。実はHaswell世代のNUC D54250でも、片方のHDMIの調子が悪いことがありました。今回も同じような現象のようです。ディスプレイは1台しか使っていませんので、HDMI(1)だけを使うことにすれば、とりあえず解決します。でも、最近はig-platform-id関連の設定に凝っているので、もう少しなんとかしたいと考えました。\nHDMI端子のフラグ値を合わせる Hackintool.appで0x01620005のコネクタ設定画面を見ました。3個のコネクタの設定があります。これがおそらく端子ごとのデフォルト設定なのだと思います。ここでのコネクタへの設定結果は、config.plistを生成する場合にそれぞれ上からcon0, con1, con2というコネクタ名で反映されます。なのでスクリーンショットにそのラベルを書き込んでおきました。\nコネクタは3個ともDP端子になっています。実際にはDC3217には2個のHDMI端子があります。DPからHDMIへの変更は、この画面から設定できて、それを記述するconfig.plistのDevices –\u0026gt; Propertiesセクションも自動生成できます。ただ、どこかで読んだのですが、WEG(?)はDPからHDMIの変換を必要に応じてやってくれるらしく、デフォルトに任せておけば良いようです。\nなので、DPであることはこのままで良いようなのですが、よく見ると3個のDPでFlagsの項目が違います。con0は0x00000011ですが、con1とcon2は0x00000107です。Flagsは、その下のリストにあるように、いろいろな設定を行うビットの集まりです。意味は不明ですし、さらにもともと機能が不明 (unknown) なフラグも多いようです。ということで、端子ごとに画面が乱れる・乱れないという振る舞いが違うことは、フラグが違うことにより引き起こされていると考えました。つまりHDMI(1)とHDMI(2)のどちらかが0x00000011で、もう一方は0x00000107になっていると考えられます。ちなみに0x00000011と0x00000107の違いは、いずれもunknownフラグが違うだけなので、違いの意味は不明です。\ncon1を調べる まずはcon1を0x00000011に設定してみました。Flagsのカラムに数値を入力しても良いですし、下のConnector Flags:でクリックしても良いです。\nこの後、Patchタブを選び、Generate Patchボタンを押すと、config.plistが現れます。この時、Generalでは、DeviceProperties, Connectors, Graphic Devicesを選びます。またAdvancedとLSPCONは何も選択しません。コネクターの設定が現れ、かつ他の余分な設定が反映されないように調整すれば良いです。\nここで得られたパッチ部分を、config.plistのconfig.plistのDevices –\u0026gt; Propertiesセクションにコピーして、起動を試みました。この結果、何の変化もありませんでした。con1は、使われていないコネクターのようです。\ncon2を調べる 次にcon2に対しても、con1とおなじFlags設定、つまり0x00000011への設定を試みました。上で作ったconfig.plistの記述で、con1のframebuffer-con1-flagsの値を、framebuffer-con2-flagsにコピーします。これでcon0, con1, con2の全てのframebuffer-conX-flagsの設定が0x00000011 (Base64表記ではEQAAAA==) になりました。このconfig.plistで起動したところ、なんとHDMI(2)からの映像の乱れが治りました。以上の試みから、\nHDMI(1)はcon0である HDMI(2)はcon2である flagsを0x00000011にすれば画面が乱れない ということがわかりました。\nconfig.plistを整える これでHDMI(1)もHDMI(2)もどちらも正常に動くconfig.plistが得られました。でもDevices –\u0026gt; Propertiesセクションの記述が煩雑に思います。コメントみたいな説明の項目は不要に思われます。とりあえずコメント風の設定を外すと以下になります。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BQBiAQ==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con0-busid\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con0-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con0-flags\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;EQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con0-index\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AgAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con0-pipe\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con0-type\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAQAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con1-busid\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con1-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con1-flags\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;EQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con1-index\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AwAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con1-pipe\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con1-type\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAQAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con2-busid\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BgAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con2-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con2-flags\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;EQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con2-index\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con2-pipe\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con2-type\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAQAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con3-busid\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con3-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con3-flags\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;QAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con3-index\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con3-pipe\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con3-type\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; 変更したいのはcon2のflagsに関する設定だけで、あとはデフォルトで良いはずです。このconfig.plistは自動生成されたので、デフォルト値もそのまま書き込まれているようです。ということで、con2のflagsと、共通と思われる項目を除いて、以下のような記述にしました。これ以上、設定を削除すると画面乱れが復活します。なので、これがflagsを変更するための必要最小限の記述項目だと思われます。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BQBiAQ==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con2-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con2-flags\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;EQAAAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AQAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; config.plistの全文は以下に置いておきます。いつものように、シリアル番号は実機とコンフリクトしないことを確認してあります。このままで動作するはずですが、実際に使用する場合は、シリアル番号、UUIDを設定し直してください。\nconfig.plist for NUC DC3217IYE - Pastebin.com\nまとめ 初代NUCのDC3217の2個のHDMI端子のうち、片方の端子で画面の乱れが発生しました。Hackintool.appで調べてみると、端子ごとにフラグのデフォルト値が異なっていました。画面が乱れる端子のフラグを、正常に表示される端子のフラグと同じになるよう設定することで、画面が乱れなくなりました。\nディスプレイはどうせ1台しか使わないので、画面が乱れるHDMIポートを封印するだけでも良かったです。でも使わないポートでも、動くように設定できると気持ちが良いです。こういう作業が楽しいと感じられないと、hackintoshは面倒くさいだけかもしれないですね。\n","date":"2020-04-08T23:20:26+09:00","image":"/uploads/2019/04/dc3217iye.png","permalink":"/posts/8346/","title":"Intel NUC DC3217のiGPU画面が乱れる"},{"content":"CPU内蔵グラフィックス(iGPU)を使うために、機器によってはconfig.plistでig-platform-idを指定する必要があります。idを記述できる場所は2カ所あります。Cloverの機能を使う場合と、WhateverGreen.kextを使う場合で場所が違います。\nig-platform-idについて ig-platform-idとは何で、どうして指定する必要があるのでしょうか？大変申し訳ありませんが、よく知りません。以下は推測です。勘違いしているようでしたら、コメントで教えてください。\nhackintool.appを色々いじっていて、以下のように推測しました。iGPUはCPUダイの中に焼き込まれていますが、おそらくは様々なモードで稼働可能です。例えばノートPCでしたら液晶パネルが接続されますし、デスクトップでしたらDPやHDMIディスプレイが接続されます。フレームバッファの量も設定できるでしょう。他にも、実装されるハードウェアに対応していろいろな設定が可能なはずです。その設定デフォルトのセットをインテル(?)が提供していて、それがig-platform-idなのではと思います。同一のiGPUに対して複数のig-platform-idが存在していて、コンピュータメーカは製品の構成に合わせて、そのうち一つを使っているのでしょう。\nMacも同様に、ハードウェア構成に合わせて適切なig-platform-idを使っています。例えばCoffee Lakeに搭載されているIntel UHD Graphics 630を使う場合、MacBookPro15,1ではig-platform-idとして0x3E9B0000を使用し、Macmini8,1では0x3E9B0007を使用します。なので、config.plistでシステムIDとしてMacmini8,1を指定すると、macOSはig-platform-idが0x3E9B0007だと解釈して動作すると考えられます。0x3E9B0000は液晶ディスプレイを接続する構成用のidで、0x3E9B0007はDPポートを接続する構成用のidです。hackintoolの画面を示します。LVDSというのはLCD用のインタフェースらしいです。\nig-platform-idは、使用しているiGPUの種類と、出力ピンの組み合わせに合うものから探していくことになります。一般的な指針は、こちらで詳しく書かれています。この中のrecommended framebuffersから選択すると良いです。LCDを内蔵しない自作デスクトップPCなどの場合はdesktop用のidを、市販のノートPCにmacOSをインストールする場合はlaptop用のidが適しているようです。\nWhateverGreen/FAQ.IntelHD.en.md at master · acidanthera/WhateverGreen\nhackintoshのマザーボードやノートPCの構成が、macOSの想定にたまたま合致していれば、問題なく起動するでしょう。でも、異なっているとiGPUが動かず、画面が出ません。Windowsの場合は、ハードウェアにidを問い合わせるなどして、現実に合わせてくれるのかもしれません。Macの場合はApple自身がハードウェアも作っているので、柔軟に対応する必要はない、という状態なのかもしれません。ig-platform-idが間違っている場合、\niGPUに切り替わるタイミングで再起動してしまう。 macOSが起動するけど、グラフィックス加速が効いていなくて、ドックの背景などが半透明にならない。 Cloverで起動ボリューム選択画面の後の林檎マーク表示で、進捗バーが止まる。-vモードで起動すると、文字表示がIOConsoleUsers: …というような表示場所で滞る。でも、表示以外は起動していて、画面共有で接続すると機能している。 などの状態になります。このような場合は、起動しようとしているhackintoshに合ったig-platform-id（システムIDで指定したMacが使うidとは違うid）に指定し直す必要があります。動作するig-platform-idを探し出す作業に困難が伴う場合がありますが、idを差し替える作業自体は、CloverやWhateverGreen.kextが行ってくれます。\nCloverで設定する Cloverで設定する場合は、config.plistのGraphicsのセクションを使います。例えば、iGPUしか使用しない場合で、ig-platform-idを0x01620005にする場合は、以下のようにします。つまり、Intelをインジェクトするよう設定し、ig-platform-idを16進数で指定します。\n\u0026lt;key\u0026gt;Graphics\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ATI\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Intel\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;NVidia\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x01620005\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; この方法はCloverが行ってくれるので、WhateverGreen.kext (WEG) は不要です。むしろWEGの動作に悪影響を与える可能性もあるらしいので、この設定を使うならWEGは使うべきではないでしょう。WEGはグラフィックスに関する様々なパッチを自動的に当ててくれます。なので、WEGを使わない場合は、iGPUで発生するいろいろなトラブルに対応したkextをいくつか使用する必要があります。ただ、Cloverを使うと、Cloverの起動画面のoptionメニューによりig-platform-idを変更できます。違うidを簡単に試すことができるので、動くidを探す作業では便利だと思いました。\nWhateverGreen (WEG) で設定する 同じ設定をWEGで行うには以下のようにします。まずはCloverでの機能を無効にします。このためGraphicsセクションで以下のように書きます。\n\u0026lt;key\u0026gt;Graphics\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ATI\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Intel\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;NVidia\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; これでCloverはグラフィックス機能に対して何もしなくなります。あとは全てWEGに任せることになります。WEGにig-platform-idを伝える場合は、Devices –\u0026gt; Propertiesセクションに以下のように書きます。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BQBiAQ==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; PciRoot(0x0)/Pci(0x2,0x0)は、iGPUが接続されているPCIe番地です。AAPL,ig-platform-idにidをBase64で書きます。0x01620005のBase64値を求めるには、ターミナルで以下のようにタイプします。BQBiAQ==です。\necho -en \u0026#34;\\x05\\x00\\x62\\x01\u0026#34; | base64 BQBiAQ== Devices, Propertiesで書く方法は、Graphicsセクションに書く方法に比べて、ややこしくてわかりにくいですが、WEGを使うならこちらを使うべきです。\nまとめ ig-platform-idは、Cloverでも、WEGでも設定できます。WEGの万能なパッチ機能はもはや手放せないので、config.plistでのig-platform-id設定も、WEGのための設定をすべきです。\n今回例示したig-platform-idは、Intel NUC DC3217で使われているidです。最近、このNUCの表示が不安定になったので対処しました。その際に、config.plistを見たら、Cloverを使う古い方法だったので手直ししました。なのでClover方式、WEG方式の両方で動作することを確認してあります。NUCの表示不具合対応の顛末は次の記事で紹介します。\n","date":"2020-04-03T18:29:57+09:00","image":"/uploads/2020/04/hdgraphics.jpg","permalink":"/posts/8325/","title":"ig-platform-idの設定方法"},{"content":"HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM (Core i3-6100T)のUSBを設定しました。使わないポートを除外して15個以内に収めます。Cloverの起動オプションで除外しても良いですし、SSDTを作っても良いです。\nHPの小型デスクトップEliteDesk (1: macOS導入)\n前回、このマシンにmacOSをインストールして、オーディオを設定しました。でもmacOSがUSBを15個に制限している関係で、USB 3.1ポートが全てUSB 2.0として稼働する状態でした。この続編では、USBが正しく見えるように設定を行います。USBポートの設定方法は、こちらのZ390、B360チップセットマザーボードの記事もご覧ください。\n15個制限を回避するUSBInjectAll.kextの役割と使用法\nMSI B360M MORTAR TITANIUMのUSBポートを設定する\nUSBポートの観察 HP EliteDesk 800 G2 DMには、前面パネルに3個、背面パネルに4個のUSBポートがあります。詳細は、こちらのスペック表でも確認できます。USBは全部3.1 Gen 1だそうです。ちなみにマザーボードのチップセットはQ170です。\n前面パネルには、向かって左から右に、\nUSB 3.1 Type-C 【Type-C】 Type-A SS表示、稲妻表示【前面SS稲妻】 Type-A SS表示【前面SS無印】 の3個のポートがあります。SSの表示はSuper Speedの略で、USB 3.1であることを示しています。後のチェックでわかりやすいようにカギカッコ【】で示した名前をつけました。稲妻マーク付きポートは、USB充電に適しているという意味だと思います。供給電流量が強化されているのか、もしくは電源OFF状態でも5V供給されているのかもしれません。\n背面には、同じく左から、\nType-A SS表示が2個【背面SS上】【背面SS下】 Type-A キーボード表示が2個【KBD上】【KBD下】 があります。キーボード表示のポートにはSSの表記が無いのですが、これも3.1です。\n前面・背面パネルの他に、マザーボード上の無線接続用M.2コネクタにも、1本USB 2.0が出ているはずです。M.2無線カードがBluetoothの接続に際して、M.2コネクタのUSB端子を使用します。以下ではM.2コネクタに出ているはずのHSポートを【M.2のHS】と呼びます。\nHS (High Speed)ポートを調べる まずはUSBInjectAll.kextだけを入れて、IORegistryExplorer.appを起動します。次に、ウィンドウの右上にある拡大鏡アイコンのついた検索窓にxhcとタイプします。すると以下のようになりました。\nUSB 2.0であるHSが14本見えています。こんなに多数のポートを使っていませんので、USBInjectAllのデフォルトでこう解釈されているのだと思われます。SSもあるはずなのですが、HSが多すぎて15個制限のためにSSは見えていません。このため、USB 3.1ポートに含まれるUSB 2.0ピンしか機能しなかったのです。\nHSは全て見えているので、最初にHSとUSBポートの関係を調べます。そのために、USB機器をポートに接続します。USBポートにデバイスを接続するとIORegistryExplorerのport-statusの数値が変化するので、これで位置関係が分かります。USBメモリーを使うと、抜き差しのほかにアンマウントする必要があるので、キーボードのドングルのようなデバイスの方が楽です。【M.2のHS】を探すためには、マザーボード上のM.2ソケットに無線ユニットを挿します。今回は、余っていたmacOS非サポートのインテルWiFiカードを挿しました。この結果、各項目とUSB 2.0ポートの関係が分かりました。ここで発見できなかった不明なHSは多分未使用です。\nHS01 2.0 3.1 Gen 1【背面SS上】 HS02 2.0 3.1 Gen 1【背面SS下】 HS03 2.0 3.1 Gen 1【前面SS稲妻】 HS04 2.0 3.1 Gen 1【KBD下】 HS05 2.0 3.1 Gen 1【KBD上】 HS06 （不明） HS07 2.0 3.1 Gen 1【M.2のHS】 HS08（不明） HS09 2.0 3.1 Gen 1【Type-C】 HS10 （不明） HS11（不明） HS12（不明） HS13 2.0 3.1 Gen 1【前面SS無印】 HS14 （不明） SS (Super Speed) ポートを調べる 次に、今は見えていないSSポートを調べることにします。そこでUSBInjectAllの機能を使ってHSポートを一時的に無効にします。全部のHSポートを無効にすると、キーボード・ポインティングデバイスが使えないので、HS01だけは生かしました。また元から不要なUSR1, USR2も無効にします。このために、Cloverの起動オプションを以下にしました。\n\u0026lt;string\u0026gt;-v uia_exclude=HS02;HS03;HS04;HS05;HS06;HS07;HS08;HS09;HS10;HS11;HS12;HS13;HS14;USR1;USR2\u0026lt;/string\u0026gt; この結果、IORegistryExplorerの様子は以下のようになりました。\nSSが10個見えるようになりました。HS01を加えて全部で11個あります。15個制限以下ですので、SSはこれで全てだと思われます。そこで今度は、USB 3.1のUSBメモリーを使って、IORegistryExplorerの反応を調べました。その結果、以下のように割り当てられているようです。\nSS01 3.1 Gen 2【背面SS上】 SS02 3.1 Gen2 【背面SS下】 SS03 3.1 Gen 1 【前面SS稲妻】 SS04 3.1 Gen 1 【KBD下】 SS05 3.1 Gen 1 【KBD上】 SS06 3.1 Gen 1 【Type-C】（逆挿しも同じ） SS07 （不明） SS08 3.1 Gen 1【前面SS無印】 SS09 （不明） SS10 （不明） これも不明の番号は多分未使用です。SS01からSS05まではSSとHSで同じ番号になっています。でもSS06とSS08は微妙にずれています。実際のパネルに合わせると以下になります。\n以上から、未使用のポートを全て除外するためには、起動オプションに以下の設定を行えば良いことになりました。\n\u0026lt;string\u0026gt;-v uia_exclude=HS06;HS08;HS10;HS11;HS12;HS14;USR1;USR2;SS07;SS09;SS10\u0026lt;/string\u0026gt; この結果、以下のように必要なポートが見えるようになりました。存在しているポートの数がちょうど15個ですので、macOSの個数制限で諦めなければならないポートはありません。\nUSBを設定するSSDTを作る こちらで説明したように、Clover起動オプションを使うよりも、USBを設定するSSDTを作成して、使用すべきポートを指定するやり方がより正しいようです。USBポートの素性を正しく記述できるので、macOSの動きがより正しくなるはずです。詳しくは該当記事を見てください。この作業で必要な情報は、USBコントローラのdevice-idです。HP EliteDeskが使っているQ170の場合、vendor-idが0x8086で、device-idが0xa12fです。0x8086はインテルの番号ですので、インテルのチップセットを表しています。これらの数値はIORegistryExplorerでXHCの項目の中で発見できます。またファインダーで、「アップルメニュー」「このMacについて」「システムレポート」と進み「システム情報」を開き、このUSBの項目にも書いてあります。\nそこで、先の記事で紹介したお手本amlファイルから、”8086_a12f”と書かれた”Package”の定義だけを残して、他のPackageの定義を削除します。残すのは以下の項目です。\n\u0026#34;8086_a12f\u0026#34;, Package() { ........... }, この中にはHS01からSS10までのUSBの情報が書かれています。これに対してコネクタの情報を実際に合わせて変更していきます。UsbConnectorの値は、\n0: USB 2.0のコネクタ 3: USB 3.1のコネクタ。3.1に付随するUSB 2.0も3にします。 255: 内部接続で外部に接続しないコネクタ。マザーボード内部でBluetoothユニットに接続しているなどの場合にこれを使います。マザーボード上のコネクタで外部に引き出す可能性のあるものは0または3にします。 9: USB Type-Cのコネクタ。逆挿しにしてもSSの番号が変化しない場合。内部でハブに接続されているらしいです。 10: USB Type-Cのコネクタ。逆挿しするとSSの番号が変化する場合。個別に接続されています。 を表しています。上で調べた内容を反映すると、以下のようなファイルになりました。\nSSDT-UIAC.dsl for Q170 motherboard in HP EliteDesk 800 G2 DM - Pastebin.com\nこれをMaciASLで開きます。次に、MaciASLのFileメニューからSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。こうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_excludeを指定しなくても、実存するポートのみが有効になるはずです。IORegistryExplorerで確認すると以下のようになりました。上で、Clover起動オプションで設定した場合と同じ結果です。\n","date":"2020-03-26T23:16:29+09:00","image":"/uploads/2020/03/hp800g2dm.jpg","permalink":"/posts/8251/","title":"HPの小型デスクトップELITEDESK (3: USB設定)"},{"content":"HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM (Core i3-6100T)のオーディオを設定しました。config.plistでDevices-\u0026gt;Audio-\u0026gt;Injectを11に設定すれば良いです。搭載された内蔵スピーカーからも音が出ました。\n前回、このマシンにmacOSをインストールして、動作確認とベンチマークをしました。実はここで紹介したconfig.plistではオーディオが動いていませんでした。この続編では、オーディオの設定を行います。\nHPの小型デスクトップEliteDesk (1: macOS導入)\nAppleALCの設定 マザーボード搭載オーディオを動かすための最も一般的な方法は、Lilu.kextと、オーディオ用プラグインであるAppleALC.kextを使う方法です。最初に、\nこの2個のフォルダをEFI/CLOVER/kexts/Otherに入れ、 config.plistで設定 すれば作業完了です。AppleALC.kextに関してはこちらの記事をご覧ください。\nLiluとプラグイン：(2) AppleALCの使い方\nこれによると、config.plistのDevices-\u0026gt;Propertiesでオーディオ設定する方法が推奨されています。でも古いやり方とされている、Devices-\u0026gt;Audioで設定する方法の方が簡単です。将来のLiluでサポートされなくなるかもしれない方法らしいのですが、簡単な非推奨な方法を使いました。\n前回の作業では、Devices-\u0026gt;Audioで以下の設定を行いました。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ResetHDA\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Audioには二つのkeyを設定しています。最初のkeyはResetHDAで、これを有効にしています。これにより、macOSを再起動した後に、コーデックをニュートラルに戻してくれます。別のOSを起動してmacOSに戻ってきたときに発生する問題を解決します。macOSだけを使う場合には不要かもしれません。ちなみに、(オーディオ)コーデックとはcoder/decoderの略で、圧縮された(音)データを復号して(音の波形)データに戻したり、その逆を行うソフトウェアとか装置とかアルゴリズムのことです。そう言う機能を行うICチップを指すこともあります。ここではICチップのことです。\n次のkeyのInjectではレイアウト番号と言う値を指定します。レイアウト番号は、今まで大体1番で動いていたので、とりあえず1番を設定しました。しかしこれでは音が出ませんでした。この他に、2,3,4,5,6あたりまで試してみたのですが、どれも音が出ません。手当たり次第に試しても先が長そうだったので、筐体の蓋を開けて、マザーボード搭載コーデックを特定することにしました。\nコーデックはALC221 このマシンの蓋はネジ一つで開くので簡単です。マザーボードの上の2.5インチベイやCPUクーラを外さないとコーデックが見えないかと思ったところ、手前の端のなんとか見える場所にありました。前面パネルには、オーディオ用のミニジャックが2個あるのですが、その近くでした。2.5インチベイの金具がかぶさってますが、斜めから覗き込めました。おなじみの蟹マークのRealtekのチップで、ALC221でした。（追記：こちらのスペック表にもALC221と書いてありました）\nそれぞれのコーデックで使用すべきレイアウト番号の一覧は、こちらのサイトに掲載されています。これによると11または15を指定すべきようです。両方を試してみましたが、11が正しいようです。15では音が出ませんでした。と言うことで、config.plistのAudioの項目は、以下にします。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ResetHDA\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;11\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; ヘッドフォンと内蔵スピーカ 前面パネルには、ヘッドフォンのマークが描かれたミニジャック端子（左側）と、ヘッドフォン＋マイクロフォンのマークが描かれたミニジャック端子（右側）の、合計2個のミニジャックがあります。後者（右側）はどう言う種類なのか不明でした。iPhoneのイヤフォン（イヤフォンとマイクロフォンが一体になっています）を挿してはみたのですが、どちらも使えませんでした。とはいえ、FaceTimeなどではUSB接続のwebカメラかスピーカーフォンを使い、アナログマイクロフォンを使うことはまず無いと思います。なのでこれ以上は調べませんでした。\n使用できたのは、ヘッドフォンのマークが描かれた左側のミニジャック端子です。ここにミニプラグを挿し、アンプ付きスピーカに接続したところ、良い音で音楽を聴くことができました。システム環境設定のサウンド-\u0026gt;出力の表示にも、名前：ヘッドフォン、種類：ヘッドフォンポートと表示されました。\n左のジャックからプラグを抜くと、今度は内蔵スピーカーから音が出ます。3cmくらいの小型のスピーカーなので、電話の受話器のような音質・音量ですが、一所懸命頑張っている感じで可愛いです。サウンドの表示も、内蔵スピーカー、内蔵に自動的に切り替わります。\nもう一つの出力項目である、ライン出力、オーディオライン出力ポートは、どこにあるのか所在不明でした。1世代前の、HP EliteDesk 800 G1 DMには、背面パネルにオーディオライン出力ジャックがありました。G2で背面オーディオ出力ジャックが無くなってしまったのが残念なのですが、あの名残がマザーボード上にあるのかもしれません。\n一方、サウンド入力画面には、ライン入力、オーディオライン入力ポート、と言う項目が2個表示されています。この2個についても所在不明でした。前述の、前面パネルにあるヘッドフォン＋マイクロフォンの描かれたミニジャックかと思いましたが、ちょっと試した限りでは使えませんでした。\nまとめ HP EliteDesk 800 G2 DMのヘッドフォン端子と内蔵スピーカーから音を出すことができました。\n自作PCに、ビープ音を鳴らすスピーカーをつける例は多いですが、コーデック接続のスピーカを内蔵する例はあまり見かけません。タワー型の筐体ならスペースはあるので、内蔵スピーカがあれば省スペースになって良い気がします。実際に、デスクトップMacにはどれもスピーカーが内蔵されてます。なので、メーカ製デスクトップPCで内蔵スピーカから音楽を出せたのが面白かったです。\n","date":"2020-03-24T00:10:51+09:00","image":"/uploads/2020/03/hp800g2dm.jpg","permalink":"/posts/8173/","title":"HPの小型デスクトップELITEDESK (2: Audio設定)"},{"content":"\nAliExpressから届いた格安の5250U搭載小型ベアボーンPC XCY X36にmacOS Catalina 10.15 をインストールしました。macOSは一応すぐに動いたのですがiGPUがいまだに動きません。その経緯を書いておきます。こちらの製品です。\n前回はこのベアボーンPCを分解して中身を確認しました。前回からずいぶん間が空いてしまいました。iGPUのドライバーが動かなくて難航してます。もう少し頑張ろうと思ったのですが、6100T搭載メーカー製中古デスクトップの方が性能、価格、サイズ、メンテナンス性で勝っているのでこちらはお蔵入りにします。ということでドライバーが動かず、描画加速が効かない状態ですが、この先進捗しなさそうですので、現状報告しておきます。\n5250U搭載小型PC XCY X36 (1: 分解編)\nメモリーとSSDを用意する ベアボーンなのでメモリーとSSDが必要です。ケーブルが筐体からはみ出しますが、2.5インチSSDも接続可能です。メモリーは1.35Vの低電圧タイプDDR3 S.O.DIMMが必要です。1本しか取り付けられず、8GBが最大です。1333MHzと1600MHzで価格は変わらないので1600が良いと思います。ソケット取り付けSSDはM.2に移行してしまって、mSATA SSDは国内サイトではあまり見かけなくなりました。ちょっと試すつもりなら120GBや250GBで良いと思います。KingSpecというKingstonに紛らわしいブランドでお手頃な製品がありました。\nBIOSを設定する メモリーとSSDを取り付ければPCとして機能します。さらにACアダプター、キーボード、トラックパッド、HDMIケーブル（の先にディスプレイ）を取り付けました。電源を入れたら、American Megatrendsのロゴが表示され、その後、めでたくBIOS画面が表示されました。お馴染みのAptioブランドのBIOSです。最近の大手マザーボード製品と違って、昔ながらのシンプルな表示です。CPUは鉛筆書きの番号通り、i5-5250Uだったようです。良かったです。\nとりあえずはF9を押して、設定を工場出荷状態に戻します。次に、BIOS設定をします。BIOS設定に関しては、こちらの記事もご覧ください。\nマザーボード (BIOS) 設定\nBIOSメニューを順番に見て、変更すべきところを探します。まずはIntel Anti-Theft Technologyという機能の設定があり、Enabledになっていました。検索すると、ネットに接続しない状態が指定日数経過すると盗難モードに入り、マザーボードをロックする機能です。しかしすでにサービス終了しているようです。このクラスのマザーボードに、BIOSからネット接続する機能は無いと思われますので、Windowsアプリと一緒に動く機能かと思います。ロックする部分をBIOSが担当しているだけでしょう。なのでmacOSで使う限りは無害と思います。でもトラブルの予感しかしませんのでDisabledにしておきました。\n次に搭載シリアルポートの設定がありました。前回の分解で分かったように、マザーボードにはシリアルポート用のヘッダピンが2セットあります。BIOSメニューにもSerial Port 1と2の設定があり、この2セットに対応しているようです。BIOSではそれぞれをon/offできます。シリアルポートはmacOSではサポートされていませんし、これが有効になっていると起動に失敗した経験もあります。そうでなくても電気の無駄なので、両方ともDisabledにしておきます。\niGPU関連の設定に、DVMT Pre-Allocatedという項目があります。初期設定は32MBなのですが、macOSでは64MB以上にしないと動かないとのことです。少し余裕を持たせて96MBにしておきました。実際に32MBの設定で試したところ、Cloverの起動画面が出た後、グラフィックスが切り替わるタイミングで再起動してしまいます。ちなみにBIOSでこの設定が可能なのは幸運らしいです。ノートPCのBIOSなどではこれが設定できないこともあるそうです。多分、変な設定をして動かなくなるとサポートが面倒なので、設定項目から除外してあるのかと思います。この製品はAptioのオリジナルのままのBIOSを使っているので、この設定も可能なのだと思います。\n初期設定ではVT-dがEnabledでした。他の設定でリカバーできるらしいですが、ここはHackintoshの定石なので、Disabledに設定しました。\nこれは単に不便なだけですが、デフォルトではキーボードがNum Lock状態になります。以前紹介したテンキー無しのトラックパッド付き無線キーボードを使うと、右の文字キーがテンキーになってしまい不便です。macOSが起動してしまえば関係ないですが、UEFI Shellでの操作やCloverでの設定作業に支障が出ます。そこでBootup NumLock StateをOffにしました。\nまとめると、初期設定から変更した点は以下の5箇所です。\nIntel Anti-Theft TechnologyをDisabledにする 2個のシリアルポートをDisabledにする DVMT Pre-Allocatedを96MBにする VT-dをDisabledにする Bootup NumLock StateをOffにする インストール用USBメモリーを作る 次に、このX36で\nmacOSユーティリティを起動して mSATA SSDをフォーマットして macOSをインストールする ことが可能なUSBメモリーを作成します。大まかな手順はこちらをご覧ください。\nCatalina導入用USBメモリーを作成する\n手順をまとめると、\nUSBメモリーをフォーマットする createinstallmediaコマンドを使ってMacで起動するmacOSインストーラ作成する CloverインストーラでブートローダとUEFIドライバを入れる 必要なkextを入れる config.plistを作成する このUSBメモリーを作成する手順で一番難しいところは、USBメモリーのESP部分を作成する部分のステップ3, 4, 5です。特にconfig.plist作りが難しいです。でもこれさえできれば、Hackintoshはほとんど完成したも同然です。まずはCloverインストーラでブートローダーとUEFIドライバを入れます。今回のビルドで使用したUEFIドライバは、以下です。VirtualSMCを使ったので、VirtualSmc.efiを手作業で入れています。\nApfsDriverLoader.efi EmuVariableUefi.efi FSInject.efi OsxAptioFix3Drv.efi VBoxHfs.efi VirtualSmc.efi また使用したkextは以下です。\nAppleALC.kext Lilu.kext RealtekRTL8111.kext USBInjectAll.kext VirtualSMC.kext WhateverGreen.kext USBInjectAll.kextは不要だったかもしれません。LANチップがRealtekだったのでそれ用のkextを入れました。この後、難関のconfig.plist作りをします。\n暫定Config.plistを作る こちらでHaswell用のconfig.plistの作り方の解説を載せておきました。\ncorpnewtさんのバニラガイド~Haswell用config.plist\n今回はBroadwellなのですが、数が出ていないCPUなのかCorpnewtさんのガイドにはありません。でもHaswellに近いCPUなので、ほとんどHaswell用のconfig.plistで動作すると思いました。\n機種ID SMBIOSは、5250U搭載Macに合わせることにしました。該当するMacは、MacBookAir7,1, MacBookAir7,2, iMac16,1, iMac16,2です。どれもiGPU使用機種ですし、どれでも良いと思います。完成すればデスクトップマシンなので、iMacが近いかと考えて、iMac16,1にしました。Clover Configurator.appでSMBIOS部分を作り、Corpnewtさんのガイドのconfig.plistのSMBIOS部分と差し替えます。Clover Configurator.appが作成してくれたSMBIOS部分をそのままコピーすると長ったらしいので、最小限にします。足りない部分はCloverが補ってくれます。シリアル番号、ボードシリアル番号、SmUUIDはこのサンプルをまねずに必ず独自の値を設定してください。重複した値を使うとアップルから拒否される可能性があります。\n\u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C027456004NGH34JC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Mobile\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac16,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02VNYZ7GF1J\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;483F7DE7-6698-4EAC-B7A3-6B39FC4264F6\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; サウンドの設定 音を出すためにDevices-\u0026gt;Audioのインジェクトするレイアウト番号を1にしました。\n\u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;1\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; こちらのページ\nSupported codecs · acidanthera/AppleALC Wiki\nによるとRealtek ALC892の場合は、1, 2, 3, 4, 5, 7, 12, 15, 16, 17, 18, 28, 31, 90, 92, 97, 99などの選択肢があるようですが、大体1で良いようです。\niGPUの設定 WhateverGreen.kextを使う場合、iGPUの情報はDevices-\u0026gt;Propertiesに書きます。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AwAiDQ==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; としてig-platform-idを指定しています。場合によってはconfig.plistに何も設定しなくても、WhateverGreen.kextがとりあえず動作する値を割り当ててくれることが多いです。しかし、今回の構成ではconfig.plistでの設定が必須だったようで、最低でもig-platform-idの設定がされていないとmacOSの起動が途中で止まってしまいました。ig-platform-idに何を設定すべきかは、正解があるわけでなく、試行錯誤で探る場合もあるようです。以下の情報\nIntel Framebuffer patching using WhateverGreen\nによると、Broadwellの場合のdevice-idとig-platform-idは\nGen 5: Broadwell (Intel HD Graphics 5300-6300) - device-id: 0x0BD1 0x0BD2 0x0BD3 0x1606 0x160E 0x1616 0x161E 0x1626 0x1622 0x1612 0x162B - AAPL,ig-platform-id (desktop): 0x16220007 (default) - AAPL,ig-platform-id (laptop): 0x16260006 (default) であると、書かれています。ig-platform-idは、0x16220007または0x16260006が良いようです。Hackintool.appで調べてみると、0x16260006は5250UとそのiGPUで動作するiMac16,1, MacBookAir7,1, 7,2で使われる値のようです。おそらく実機で調べた結果だと思います。いかにも良さそうです。0x16260006を使う場合は、これの並びを逆順0x06002616にし、base64変換します。すると、\n% echo -en \u0026#34;\\x06\\x00\\x26\\x16\u0026#34; | base64 BgAmFg== になります。この値を採用する場合、Propertiesの項目は、以下となります。\n\u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;BgAmFg==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; ということで、ig-platform-idに0x16260006を採用した場合のconfig.plistは以下のようになりました。\nconfig.plist for X36 with 5250U - Pastebin.com\niGPUドライバを諦める 実は、ig-platform-idを1番正しい値だと思われる0x16260006にした場合、画面が正しく出ません。-vオプションではずっと文字画面のままです。時々OSが順調に動いているらしいメッセージが出ます。実際、macOSをなんとかインストールして、LANを有効にした状態でリモートデスクトップ接続すると、macOSは正しく動作していることが確認できました。ディスプレイドライバの問題です。\n調べてみたところ、iGPUを使おうとする場合のよくあるトラブルのようです。iGPUのドライバが機能しようとしているものの、他の設定が不十分で正しく表示されていない様子です。もう少し頑張ればなんとかなる状態です。一方で、ig-platform-idを全く間違った値に設定すると、ドライバー自体が起動に失敗します。その場合は標準的なデフォルトのディスプレイとして認識されるので、画面表示が出ます。ただし、グラフィックス加速が効いていないので、動作が遅く不安定で、macOS画面の半透明などの視覚効果が効きません。今回の例ですと、Hackintoolに登録されていない1番違いの0x16260007、つまりbase64ではBwAmFg==を使うと、この状態になり、一応の表示が行えます。以下はこの状態で進めました。\nmacOSをインストールする このUSBメモリをX36に挿して起動します。\n無事起動して、macOSユーティリティが動きました。\nUSBメモリーで起動したmacOSユーティリティから、mSATA SSDをフォーマットします。ここでは伝統に従ってMacintosh HDという名前をつけました。これにmacOSをインストールします。\nインストール途中で再起動しますが、その時は、Boot macOS Install from xxxxという項目を選択します。\nインストールが終了すれば、USBメモリ、mSATA SSDのリカバリーパーティション、そしてインストールしたmacOSの本体の選択肢が現れます。\nこれでUSBメモリーから起動して、本体のmSATA SSDから起動するようになりました。USBメモリーのESP部分をmSATA SSDにコピーすれば、mSATA SSDから起動するようになります。\nmacOSを使ってみる 前述のようにグラフィックス加速は効いていませんが一応の操作は可能です。グラフィックスはIntel HD Graphics 6000と認識されていますが、グラフィックスメモリが31MBしか無いことになってます。\nサウンドは動いています。X36のオーディオ出力ジャックは、内蔵スピーカーに対応しているようです。光デジタル出力ポートも動いているようですが、対応機器を持っていないので確認できませんでした。\nGeekBench 4を動かしてみたところ、マルチコアのスコアは5500くらいでした。\nGeekbench Browserで他の人のベンチスコアを検索したところ、5250U搭載iMac (21.5-inch Late 2015)のGeekbench 4スコアはこの程度の値で、妥当な結果です。\nまとめ とりあえずは動作しましたが、iGPUのグラフィックスドライバが動いていないので、未完成です。Hackintool.appによると、ig-platform-idを変更するだけでなく、device-idを設定したり、コネクタがデフォルトでDPであるのを実装に合わせてHDMIに変更したり、フレームバッファの各種フラグを変更するなど、いろいろな選択肢があるようです。手当たり次第試してはみたのですが、正解は見つけられていません。組み合わせが多すぎて全部は網羅できていないためかもしれないです。もしくは、iGPU周りの設計がMacとは違う構成になっていて、動作困難な機種だったのかもしれません。冒頭に書きましたように、メーカー品の中古デスクトップが優秀だったので、こちらは当面お蔵入りにすることにしました。\n","date":"2020-03-21T21:53:47+09:00","image":"/uploads/2019/10/bios1.jpg","permalink":"/posts/6867/","title":"5250U搭載小型PC XCY X36 (2: OS導入未完編)"},{"content":"HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM (Core i3-6100T)にmacOSをインストールしました。まずはiGPUとLANが動きました。第5~6世代のメーカー製中古デスクトップPCは1万円前後で入手できます。この値段ですぐに動くmacOSマシンが手に入るのでお得です。\n追記：その後、スリープ復帰後にiGPUの信号が出ないブラックスクリーン状態が発生していることに気づきました。最近のmacOSで発生しているようで解決策は無いようです。スリープさせない設定にしても長時間放置するとブラックスクリーンになることもありました。画面共有では問題ないので、ディスプレイ無しのサーバーなら問題ないかもしれません。Intel HD Graphics 530とmacOSの相性の問題のようです。\nHPの小型デスクトップEliteDesk (4: 暗黒画面問題で頓挫)\nメーカー製小型PC メーカー製PCと自作PCはそれぞれ長所短所がありますが、macOSを入れるという観点から見ると、予め相性の良いパーツを選択できて、必要ならば交換も容易な自作PCの方が有利です。でもメーカー製品でも、デスクトップPCならパーツ交換や改造が容易なので、ノートPCよりは柔軟に対応可能です。そこで初めての試みとして、メーカー製デスクトップにmacOSを入れてみます。\n今回選んだ製品カテゴリーは各社でtiny, micro, desk miniなどと呼ばれる一番小さなデスクトップです。Lenovo, Dell, HP各社から発売されています。これ以外のメーカーからも発売されていますが、ネット上の情報が多いのでこれらの大手3社が良いと考えました。中古で手頃に入手可能な第5世代CPUモデルには\nLenovo ThinkCenter M93p Tiny Dell OptiPlex 3020 Micro HP EliteDesk 800 G1 DM などがあります。YouTubeではTechNolliさんという方がこれらを使ったhackintoshを説明しています。以下は、Lenovo M93p Tiny, Dell 3020 Micro, HP 800 G1 DMにmacOSをインストールする方法の解説ビデオです。\nhttps://www.youtube.com/watch?v=M1pnWKNaqUs\nhttps://www.youtube.com/watch?v=BJqhvzjx-yo\nhttps://www.youtube.com/watch?v=6hZo2dZH_V0\nこれらの製品はどちらかというと法人向けのようです。時々秋葉原に大量に放出されます。ほぼ同じ仕様でポートの種類が違うなどのバリエーションも多いです。またHPにはEliteDeskの他にProDeskというブランドもあって紛らわしいです。ProDeskはより法人向けのようで、サポートセンタの対応が無いとか、チップセットが格下だったりする違いがあります。\nこれらの製品群は、一般のデスクトップPCと同じLGAソケットのCPUが搭載されています。CPUを交換できるのでアップグレードも可能です。Intel NUCがノートPC向けBGAパッケージ（半田付け）のCPUを使っているのと対照的です。上記でリストしたCore iモデル機種には、どれもCore i3-4160T, i5-4570T, i5-4590Tなどの省電力のTモデルCPUが搭載されています。Tモデルは無印モデルよりクロックが多少低いですがそれ以外の仕様は無印と同じです。ソケットなので上位グレードのTモデルCPUに交換可能です。\nHP EliteDesk 800 G2 DM 今回はこのカテゴリーの中古コンピュータから、HP EliteDesk 800 G2 DMという第6世代CPU (Core i3-6100T) 搭載モデルを選びました。スペック表がこちらにあります。TechNolliさんのビデオに登場する第5世代CPU搭載モデルのHP EliteDesk 800 G1 DMと外見はよく似ていますが、前面パネルにUSB Type-Cが追加されている点が異なります。YouTubeの比較動画によると、CPUクーラの構造も変更されていて、ファン音が静かになったそうです。ヤフオクではG1が1万円未満で取引されているのに対して、G2は1万円を少し超えるくらいです。\nコンピュータの前面には、ヘッドフォン、マイクロフォン、USB Type-C, USB 3.1 Gen1, 電源スイッチがついています。HPの丸いマークの左側のスリットが長くなった部分にスピーカーが入っています。また前面パネル内側のスピーカー下部には（写真では見えていませんが）無線LANのアンテナ取り付け場所があります。無線LANはオプションなので、今回入手したマシンにはついていません。\nコンピュータ背面には、左からDP, VGA, DP, USB 3.1 Gen1, LAN, 電源端子があります。真ん中のDPの部分は、モジュール式になっていて、シリアルポート、DVI-D、HDMIになっているモデルもあります。VGA端子はmacOSでは動かないようです。今回は左端のDPを使いました。背面左端の四角い穴が3個見える部分も無線LANのアンテナを取り付ける部分です。これも装着されていません。背面側の中央上には上蓋を固定しているネジがあります。\nこの一個だけのネジを手で回して外せば、上蓋が取り外せます。Mac miniに比べたらとても簡単です。\n上蓋を開けると、内部には、左側に2.5インチドライブベイ（HDDは外しました）、右側にCPUとクーラーがあります。CPUクーラー部分は、ヒートシンクとファンで構成されています。ファンは簡単に持ち上げることができて（写真では爪楊枝で支えています）、その下にあるメモリーソケットにアクセスできます。このマシンは2.5インチドライブを前提としたフォームファクターだと言えます。2.5インチHDD/SSDのコストパフォーマンスが高かった時代には合理的な構造です。最近のように、M.2 SSDが十分に安価になり、2.5インチドライブが不要になってくると、もっとコンパクトな形状が好まれるかもしれないです。\n2.5インチベイはT15のトルクスドライバで外せます。その下にM.2 SSD用と、M.2 無線モジュール用のソケットがあります。上に2.5インチベイの金具があるので、放熱板は取り付け困難です。熱伝導シートを使って、2.5インチベイ金具に接触させるのが良いかもしれないです。\nCatalinaで動かす とりあえずmacOSが動くことを確認します。不具合はあるかもしれないですが、今回は、iGPUドライバが動くこと、LAN接続ができることを確認しました。\nBIOS設定 まずはBIOS設定画面で設定をデフォルト状態に戻しました。デフォルトではiGPUへの割り当てメモリが32MBになっています。この場合、iGPUが動き始めるとすぐに再起動に戻ってしまいました。そこで128MBくらいに設定しました。それ以外の設定はデフォルトのままで以下を進めました。今後、もう少し最適化すべきかもしれないです。\nCatalina SSDを作る 2.5インチSATA SSDを用意しました。いつも試験に使っている32GBの小さなSSDです。これを、既に動いているmacOSマシンに接続し、GUIDスキーム＋Mac OS拡張（ジャーナリング）でフォーマットしました。ただ、この後のインストール作業でAPFSに変換されました。\nこのSSDにCatalinaをインストールしました。手元にあったインストーラが10.15でしたので初期バージョンです。このSSDでmacOSマシンが起動することを確認しました。\nCloverとkextをインストール 次にESPの部分を作成します。このSSDのESPを\ndiskutil list コマンドで探して、それを（disk1s1だった場合）\nsudo diskutil mount disk1s1 としてマウントします。ここに現用のZ390マザーボード用のESPの中身をコピーしました。この際、Z390用のSSDT, kext, config.plist項目は、当然ながら不要ですので削除しました。ということでconfig.plistも最小限のシンプルなものになりました。config.plistは以下になりました。いつものようにシリアル番号とUUIDは有効な値を設定してありますが、アップルのサービスに接続する前に自分用のシリアルとIDを、Clover Configuratorなどを使用して生成して、config.plistを書き換えてください。\nConfig.plist for HP EliteDesk 800 G2 DM - Pastebin.com\n機種はiMac17,1にしました。Intel HD Graphics 530を搭載した6500, 6600, 6700Kを搭載するMacはこれだけです。6100Tは6100の省電力版でほぼ同等ですし、6100は同じSkyLakeのCPU (6500, 6600, 6700K) と互換性は高いです。config.plistではGPUのig platformの設定などを通常行うのですが、省略できるようです。当初Intel HD Graphics 530のIDを設定して動きましたが、削っても動きました。\nHPマシンでCatalinaを起動 こうして用意したSSDをHP EliteDesk 800 G2 DMに取り付け、起動します。先に述べたように、BIOSでiGPUへのメモリ割り当てが少なかったこと、VGAコネクタからは映像が出なかったことを試行錯誤した程度で、すんなりと起動しました。ここまで簡単だとは予想していませんでした。\nDockに被っている部分は半透明になっています。iGPUのドライバーがちゃんと動いてiGPUによるグラフィックス加速が行われていることを示してます。LANも、kextに入れたIntelMausi.kextで問題なく動きました。LANのチップは、上で紹介したスペック表によるとIntel I219LMだそうで、これはIntelMausi.kextの対応表に掲載されています。\n今後の予定 とりあえずは動きましたが、まだチューニングの余地があります。長時間使用するとiGPU特有のノイズに気付くかもしれません。サウンドは動くかどうか確認していません。USBは15個制限のために2.0側だけが動いているようです。なのでせっかくのType-Cも動作していません。WiFi/Bluetoothカードは取り付けたいと思います。\nベンチマーク Geekbench 5でベンチマークしました。シングルコアスコアが801でマルチコアが1838でした。\nちなみに今回のお手本にした無印6100を搭載したiMac17,1のベンチマークスコアはそれぞれ900/2100くらいです。6100Tは無印6100の省電力モデルのため、クロック数が14％低いです。クロック数の差に見合った妥当な結果となりました。（追記：勘違いしていました。6100を搭載したiMac17,1なんて存在しないですね。なのでこのGeekbench結果は全部hackintoshのスコアだと思います。6500を搭載したiMac17,1のシングルコアスコアも900くらいなので、やはり妥当なスコアです。）\nまとめ HPの小型デスクトップPCにmacOSをインストールし、とりあえず動作確認しました。特に難しいところはなく、あっさりと動いてしまいました。ベンチマークスコアもそこそこ出て、実用的に使用できそうです。同じくらいのサイズのMac miniと比較すると、筐体を開けるのは簡単ですし、メモリー、CPU, SSDなどのアップグレードも容易です。Mac miniは確かにおしゃれでかっこいいですが、HPの無骨な感じの外観も悪くないと思います。\n今回のマシンはお遊び用なので、邪魔にならない小型デスクトップにしました。でもメインで使用されるのでしたら、DVDドライブが付いているモデルやPCIeスロットが付いているモデルにするのが良いと思います。グラフィックスカードがあれば快適ですし（iGPUでも気にならないですが）、iGPUよりmacOSとの互換性が高いので安心です。さらには、嵩張るマシンは人気が無いようで、より大きなサイズの中古製品の方が、より安価に入手できます。\n今後は電力制御、iGPUの動作、サウンド、USB設定、WiFi/Bluetooth、メモリー、SSDなどを確認・追加していきます。\n関連記事 以下の記事に続きます。\nHPの小型デスクトップEliteDesk (1: macOS導入)\nHPの小型デスクトップELITEDESK (2: Audio設定)\nHPの小型デスクトップELITEDESK (3: USB設定)\nHPの小型デスクトップEliteDesk (4: 暗黒画面問題で頓挫)\n","date":"2020-03-20T21:37:26+09:00","image":"/uploads/2020/03/hp800g2dm.jpg","permalink":"/posts/8176/","title":"HPの小型デスクトップEliteDesk (1: macOS導入)"},{"content":"久々に仮想環境のVirtualBoxでWindowsを起動しました。ついでにmacOSも動かしてみました。仮想マシンを動かすためにはBIOSでVT-xを有効にする必要があります。今回使用したASUS Z390マザーボードではVT-xはデフォルトで無効でした。\nmacOSで動くVMアプリ 「macOSだけで生きていけます」と言い切りたいところですが、たまにWindowsが必要になります。WindowsからしかアクセスできないWebサイトがあります。また、AliExpressなどから怪しいIoTデバイスを買うと、設定ソフトがWindows版だけのこともあります。なので3ヶ月に1回くらいWindowsが必要になります。マシンの性能を100%引出したいのでしたらマルチブートを設定すると良いです。こちらをご覧ください。\nWindowsと同居する\nでも、ほんの少しだけ利用するなら、仮想マシン(VM)で動かすのが楽です。再起動しなくても良いですし、macOSと一緒に動かせます。macOS上のVMアプリケーションにはご存知のように、\nParallels（有料） VMWare Fusion（有料） VirtualBox（無料） があります。数年くらい前まではしばらくParallelsを使ってました。性能や機能の点からは、有料製品の方が良いです。でも、OSに深く関与しているVM製品はmacOSのバージョンアップに揃えてアップデートする必要があります。なので、毎年のようにアップデート料金がかかり、意外とコストがかかります。少ししか使わないなら、VirtualBoxで十分だと思います。ということで、最近はVirtualBoxを使わせていただいてます。\n追記：最近VMWare Fusionが無料になったらしいです。コメントで教えていただきました。\n個人なら無償 インテルMac用仮想環境アプリ「VMware Fusion Player 12」レビュー (\u0026hellip;\nVirtualBoxをインストールする VirtualBoxはOracleのサイトから無料でダウンロードできます。こんな素晴らしいソフトウェアを無料で配布してくれるなんて素晴らしいです。\nパッケージには、アンインストールのスクリプトも入っています。今回、以前インストールした古いバージョンが動かなくなってました。そこで、まずはアンインストーラを動かして、古いバージョンを除去しました。次に、VirtualBox.pkgを起動してインストールします。\nCatalinaになってセキュリティが厳しくなったのか、インストールと起動を阻む色々な罠がありました。基本的には指示に従って、「システム環境設定」の「セキュリティとプライバシー」を開き、セキュリティ設定を緩めていけば良いです。\nVT-xを有効にする VirtualBoxのインストールが終わったら、VMを作って起動です。まずはWindowsを動かすための仮想環境を作って起動しようとしました。そしたら、\nのようなエラーが出て開きません。メッセージを見ると「BIOSでVT-xが無効に設定されている」のが原因のようです。MacユーザがBIOSの設定と言われても訳が分からないでしょう。おそらく本物のMacでは出ないメッセージなのだと思います。Windows版のVirtualBoxと同じメッセージを用意しているだけなのかもしれませんが、これを用意したプログラマーは、hackintoshのことが頭の片隅にあったのかもしれません。エラーメッセージ通りだとすると、BIOSでVT-xを有効に設定すれば良いことになります。\n今回使用した、ASUS ROG MAXIMUS XI HERO (Z390) のBIOSでVT-xの設定を探しました。Advancedの中のCPU Configurationの中に、Intel (VMX) Virtualization Technologyという名前で設定項目がありました。VTがVirtualization Technologyの略だと知ってないと、見つけにくい設定項目です。しかもこの設定は、デフォルトでは無効でした。VirtualBoxの方の設定でVT-xを使わないこともできるのかもしれませんが、macOSの動作には影響無いので、BIOSで有効にしておきます。これで無事VMが起動するようになりました。\nVMでWindowsを動かす 大昔に購入したWindows 10インストール用DVDイメージファイルがありましたので、これを仮想光学ドライブに設定して、Windows 10をインストールしました。特に問題なく動きます。SSDの上にVMファイルを作ったおかげかと思いますが、割と高速に動きます。ネットへの接続やIoT機器程度の用途でしたら問題ありません。\nネット接続やUSB関係は、macOSが管理しているEthernet, WiFi, USBポートを、VirtualBoxが頑張って中継してくれているので、ゲストOSからもアクセスできます。なのでネットやUSB経由で接続する機器なら問題なく扱えます。一方で、標準化されていないインタフェースで接続するハードウェアはVM上のWindowsからアクセスできません。端的な例が、前回紹介したマザーボードのスプラッシュ画面の設定です。ここで使ったASUSのユーティリティは、マザーボード搭載のASUS独自インタフェースにアクセスするので、VMのWindowsから設定することはできません。BIOSアップデートツール、オーバークロックツールなども無理なのではと思います。\nVMでmacOSを動かす VirtualBoxではmacOSのVMを作成することもできます。メニューを見ると、macOS一般設定の他に、Snow Leopard, Lion, Mountain Lion, Mavericks, Yosemite, El Capitan, Sierra, High Sierra用の設定が用意されています。MojaveとCatalinaはメニューに無いので、もしかしたらAPFSの関係などで難しいのかもしれません。\n手元にSnow LeopardのDVDがあるのでインストールを試しました。MacユーザやMobileMeユーザに無料配布されていた非売品DVDです。Snow Leopardを最後にDVDでの配布が終了し、ダウンロード配布に移行したので、古いmacOSを使用している人のためにこのDVDは長らくAppleのオンラインサイトで販売されていました。でも今回チェックしたら販売終了していました。\nこのインストーラを起動するために、まずはSnow Leopard用のVMを作成します。\n光学ドライブをVMに割り当てて、Snow Leopard DVDをセットしてVMを起動します。すると懐かしい壁紙でインストーラが起動しました。\nこの後は、いつものようにインストールを進めます。無事Snow Leopardが起動しました。macOSバージョンがわかりやすいように、デフォルトの宇宙壁紙から、雪豹壁紙に変更しました。古いmacOSが動くVMを用意しておけば、昔のアプリケーション、特に32bitアプリケーションを動かす必要に迫られた時など、便利かもしれません。\nまとめ VirtualBoxをインストールして、Windows 10とSnow Leopardを動かしてみました。OSに関与するアプリケーションということもあり、セキュリティ設定変更がいくつか必要でした。また、BIOS設定でVT-xを有効にしておく必要がありました。\n","date":"2020-03-08T22:44:24+09:00","image":"/uploads/2020/03/vboxicon.png","permalink":"/posts/8059/","title":"HackintoshでVirtualBoxを使う"},{"content":"起動時にマザーボードBIOSが起動するロゴマークを、本物Mac風に変更しました。ASUSのROGシリーズZ390マザーボードなので、ブート時に下のような画面が現れます。これを、上に示したようなAppleマークにしました。変更にはWindowsのツールを使用しました。\nシステムやアプリが起動する時に現れる画面をスプラッシュ (splash) 画面と呼びます。アプリ画面に「突入」する直前に現れる画面だからなのだと思います。本物のMacでは、電源投入直後のスプラッシュ画面に黒字に白のAppleマークが表示されます。昔の機種では、グレー地に黒いAppleだった気がします。一方で、一般的なマザーボードではマザーボードブランドのロゴが表示されます。ASUS ROGシリーズでは多少控えめな上のようなロゴが表示されますが、一般的にはかなり派手です。簡単に変更できるものならシンプルなAppleロゴに変更したいと思っていました。\nmacOSだけで変更する Windowsのツールを使えば簡単に変更できるらしいと知っていたのですが、できればWindowsを使わないでなんとかしたいと思っていました。そんな時、Redditに解説が投稿されていたのを発見しました。\nr/hackintosh - [GUIDE] How to create your own BIOS Splash Page with new custo\u0026hellip;\nこの投稿者はASRock Z390ボードで試したところ成功したらしいです。でも結論から言うと、ASUS ROG Z390では簡単ではなかったです。以下で、この方法を簡単にご紹介します。\nUEFIToolを入手する UEFIToolというツールでBIOSイメージを変更できます。このツールをダウンロードします。Hackintoshコミュニティでお馴染みのvit9696さんもフォークしているようで、なんとmacOS版もありました。以下から、UEFITool.appをダウンロードします。\nReleases · LongSoft/UEFITool\nBIOSのイメージを読み込む 次にUEFIToolを起動して、マザーボードのBIOS ROMファイルを読み込みます。今回は、ASUSのサイトから入手したROG-MAXIMUS-XI-HERO-WIFI-ASUS-1401.CAPという名前のファイルを使いました。読み込みが終了すると、以下のような表示になります。\n下のメッセージ欄に、「BIOSイメージを加工するとAptio カプセル署名が無効になります」という警告が出ています。後でこれが問題になりました。\n現在のスプラッシュ画像を確認する ROMファイルが読み込めたら、現在のスプラッシュ画像の場所を確認します。そこで、File–\u0026gt;Searchメニューを開いてSearchダイアログを開きます。GUIDタブを選択し、7BB28B99-61BB-11D5-9A5D-0090273FC14Dを検索します。\nUEFIToolウィンドウの下部のMessageウィンドウに、「GUID pattern “7BB28B99-61BB-11D5-9A5D-0090273FC14D” found as …」という表示が出るはずです。これの一つをダブルクリックすると、BIOSスプラッシュ画像が保存されているセクションが表示されます。\n今回、3箇所見つかりましたが、一つだけが下位階層のあるFileでした。これしか開くことができないので、この検索結果をダブルクリックしました。この中のRaw Sectionがスプラッシュ画面のようです。これを選択して右クリックします。Extract Body…を選択します。\nここでファイル名を指定すると（今回はROGという名前にしました）、ファイルタイプがrawのファイルが作られます。プレビューで開くこともできて、以下のように現在のスプラッシュ画面であることが確認できました。\n新しい画像に差し替える 新しい画像を用意します。画像は、1024×768画素 (72または96dpi) 以下が良いとか、1MB以下が良いなどのサイズ上限があるようです。50 ~ 100KBくらいが良いのではとのことです。今回は、Cloverテーマの一つのMinimalismからファイルをいただいてきました。ファイル形式は、jpegやpngやtiffなどが使えるそうです。raw形式でなくてもUEFIToolが自動的にrawに変換してくれるようです。先程の右クリックのメニューからReplace body…を選べば差し替えることができます。\n画像を差し替えたら、いったん保存します。そしてUEFIToolで再度開き、先程のように7BB28B99-61BB-11D5-9A5D-0090273FC14Dを検索し、新しい画像に差し替えられているかを確認します。今回用意したpngとtiffのアイコンと、変更したBIOSファイルから取り出したrawのアイコンを示します。\nこうして作成した新しいBIOSファイルにアップデートすれば良いのですが、ASUS ROG Z390ではダメでした。BIOSのアップデートツールEzFlashで、”Selected file is not a proper BIOS!”というメッセージが出てしまいます。\nおそらくは上で書いたように、ファイルの署名情報が狂ってしまったことが原因だと思います。いろいろ検索したら、改造BIOSをインストールする方法もあるようです。UEFIツールだけを使ってできるようです。ただ複雑な手順が必要で、またセキュリティ機能を外して行う作業なため、面倒で危険な作業のようです。スプラッシュ画像を差し替えたいだけのためにそこまでやるのは割りに合わないと思いました。\nWindowsのツールで変更する ということで、仕方なくWindowsを使うことにしました。操作も不慣れなのであまり使いたくなくて、Windowsはもう何ヶ月も起動していません。久々に起動したら、更新項目が多数溜まっていて、起動するだけでも大変でした。使用するツールはASUS AI Suite 3です。この中にEZ UpdateというBIOSアップデートの機能があり、これを使います。ネットでも配布されていますが、マザーボード付属のDVDからインストールしました。アプリをインストールするだけなのに、何度か再起動させられたのですが、Windowsってこんなものでしょうか？ASUS AI Suite 3のメニューの中からEZ Updateを起動し、BIOSファイルを指定したBIOSアップデートをします。\nここではバージョン1401を選んでいますが、マザーボードはすでに1401になっているのでもう一度上書きすることになります。BIOSファイルを指定すると、右下のMyLogoのボタンが選べるようになります。これを選択すると、\n新しいスプラッシュ画像を選択できるようになります。上で紹介したCloverテーマのMinimalismのアイコンをそのまま使うと、少し巨大過ぎました。UEFIToolで取り出したオリジナルの画像があれば、それを元に、消したり重ねたりして調整すると目指す大きさで表示されると思います。画像設定後、再起動になり、BIOSがアップデートされます。いつものBIOSアップデート作業と同様に、CMOS設定もクリアされるので、USBメモリーなどにバックアップしておくと再設定が楽です。\nGIGABYTEのガイド ここまではASUSのマザーボードの話でした。GIGABYTEに関するコメントをいただいたので調べてみたら、こちらにGIGABYTEマザーボードのスプラッシュを変更する方法が書いてありました。GIGABYTEが配布しているWindows用ツールを使う方法と、（なんと！）macOSユーザ用にUEFIToolを使う方法が説明してありました。\nまとめ ASUS ROG Z390マザーボード起動時の画像を白いAppleマークに書き換えました。UEFIToolを使用するとBIOSの書き換えが出来、これを使ってスプラッシュ画像も変更できます。ただメーカの署名が無効になり、アップデートが非常に困難だとわかりました。そこでやむなくASUSが配布しているWindows用ツールを使用しました。久々に慣れないWindowsを起動して大変でしたが、作業自体は簡単でした。Macのようなシンプルな起動画面になりました。だからと言って何も変わらないのですが、再起動してはニヤニヤしています。\n","date":"2020-02-29T17:22:41+09:00","image":"/uploads/2020/02/splash_after320.png","permalink":"/posts/7999/","title":"マザーボード起動スプラッシュ画像をMac風に変更する"},{"content":"現行の300シリーズマザーボードの大半にUSB Type-Cが搭載されています。これをMacBookと接続すれば、ある程度の充電とデータ交換が可能です。充電電圧をUSBテスターで確認しました。データ交換は、MacBookのターゲットディスクモードが使えました。\nType-Cコネクタに関してはこちらの記事で詳しく紹介しましたので、こちらもご覧ください。\nUSB 3.1とType-Cコネクタ\n充電 パワーデリバリー Type-Cで導入された新機能の一つがPD (Power delivery パワーデリバリー) 機能です。従来のUSB-Aコネクタなどでも5Vの電源を供給していて、電力供給したり充電したりしていました。これをさらに強化したのがPD機能です。PDでは大容量の電力を供給します。電流を増やせば電力は上げられますが、銅線に流せる電流量には上限があります。なのでPDでは、必要に応じて電圧を上げて、同じ電流でより多くの電力を供給する工夫がされています。そのために信号線を使って送電側と受電側で何ボルトに対応しているのかネゴシエーションします。最終的には20Vまで電圧を上げて、最大で5Aまでの電流を流します。これで最大100Wもの電力を供給します。下が、電圧と電流の組み合わせです。例えば30Wの電力供給をする場合は15V2Aで動作します。\nUSBテスター 従来は、USBといえば5Vを供給する規格だったのですが、PDにより様々な電圧が出てくることになります。これはぜひとも確認したいと思いました。そこで、USB Type-Cの電圧と電流を測定するUSBテスターを手に入れました。いつものAliExpressです。多種類のコネクタに対応していて、カラー表示で、この価格（執筆時点で送料込859円）はすごいと思いました。\nいろいろなピンの電流・電圧が測定できて、さらには指定した電圧・電流になると警告音がなるようです（使わないですが）。まずはMacBookを30Wアダプターに接続して測定してみました。\n電圧は19.8Vで電流が1.39Aです。27.5Wでした。MacBookの電池の充電状態によって電力は変動するようです。なおこのテスターの表示モードは数種類に切り替えられますが、ここでは電流線の電圧・電流が大きく表示される表示モードを使っています。\nマザーボードから充電 では、いよいよMacBookをマザーボードのType-Cに接続してみます。マザーボードは、こちらのビルド例で紹介したASUS ROG MAXIMUS HERO WIFIです。\n4.26V, 2.53Aで、10.8Wです。MacBookからは最大限の電力を受け入れようとしているけど、マザーボードのType-Cコネクタは5Vを超える電圧は供給してくれないようです。以前の記事で紹介しましたように、マザーボードのType-Cに接続したのではなかなか充電できない（数時間かかる）様子がここからもわかるかと思います。\nデータ転送 ターゲットディスクモード Macに搭載された伝統的な機能に、ターゲットディスクモード(TDM: Target Disk Mode)があります。電源起動時にキーボードのTを押しているとTDMモードに入り、Macがハードディスクとして機能します。SCSI端子があった時代には、TDMによりMacの内蔵ドライブがSCSIハードディスクとして機能しました。FireWire (IEEE 1394)が搭載されていた時代にはFireWireドライブになりました。現在の機種はThunderboltが搭載されているので、TDMによりMacがThunderboltドライブとして機能します。SCSIもFireWireもThunderboltも、接続された機器同士が対等でした。TDMは、接続機器のどれもがコンピュータ側にもドライブ側にもなれる規格だったからこそできた機能です。つまり、Macを通常のように起動すれば他を制御するコンピュータ側になりますが、TDMで機能すれば、他のコンピュータから制御されるドライブ側になれるのです。\nところが従来型USBはコンピュータ側とドライブ側がハード的に固定でした。そもそもキーボードとマウスを接続するために考えられた規格なので仕方ないです。コンピュータ側はType Aのコネクタを持ち、ドライブ側はType Bのコネクタを持ちます。反対の関係で接続することはできないので、TDMを機能させることができません。なので、SCSIもFireWireもThunderboltも持たないMacはTDMが機能しませんでした。\nでも、USB Type-Cは特別な新型USBです。コネクタ形状は1種類しかなくて、コンピュータ側もドライブ側も同じ形状です。接続された機種それぞれがネゴシエーションして、誰が制御側になるかを決められます。なので、USB Type-Cを備えていて、尚且つType-Cを使ったThunderboltを搭載していないMacは、TDMによりUSB規格のドライブになることができます。手元にありましたMacBook 2017はこのタイプのレアものMacで、TDMによりUSB Type-C接続のドライブとして機能します。\nMacBookをTDMで起動 そこでMacBookをTDMで起動しました。Tキーを押したまま電源を入れるだけです。macOSのバージョンによっては、システム環境設定から起動ディスクを選ぶことでも、ターゲットディスクモードで起動できます。\nちなみに上の図は、Hackintoshのスクリーンショットです。IEEE 1394カードを接続していたので、このダイアログが出たようです。このように、HackintoshでもTDMの選択肢が現れる場合もあります。でもこれを選んでもTDMでは起動しません。TDMはmacOSの機能ではなく、Macのファームウェアが実現する機能（自作PCだとBIOSやUEFIの機能）なので、Hackintoshでは動きません。\nTDMになるとMacの画面は真っ暗な背景になり、接続コネクターを示すアイコンが浮遊するように表示されます。今回のようにUSB Type-CのドライブとしてTDM起動すると、USBのロゴマークが画面に現れます。\nTDMでデータ転送 この状態で、MacBookと上記のZ390マザーボードHackintoshをUSB Type-Cケーブルで接続します。すると、ファインダーにMacBookのドライブがマウントされます。今回はMacBookでFileVaultを設定してあったので、パスワードを聞かれました。\nその結果、Hackintoshのデスクトップに、MacBookのドライブ内容が、リムーバブルであることを示すオレンジ色アイコンで現れました。\nこれを開けば、どのファイルにもアクセス可能で、読み書き自由です。余談になりますが、TDM可能な本物Macを持ち運んで使用するならば、ぜひともFileVault指定しておくべきだと思いました。盗難にあってTDM起動されたら、中身を閲覧されまくりです。検索したらこちらの記事などでも、TDMが危ないからFileVaultした方が良いと書いてありました。またFileVaultを使う方法以外に、Firmware passwordを設定するという手段もあるようです。ただFirmware passwordは簡単に回避できるのであまり当てにできないようです。\nTDMの速度測定 便利なTDMですが、データ転送速度はそれほど高くありません。\n60MB/s前後ですので、ざっくり600Mbps程度のようです。システム情報を見ると、接続自体は5Gbpsで接続されているようではあります。接続速度の1/10程度しか出ていません。TDMのオーバーヘッドが大きいようです。\nちなみにMacBookのUSB Type-CはUSB 3.1 Gen1なので5Gbpsなのです。Gen2ならば10Gbpsなのに、そこも残念ポイントです。\nType-Cのケーブル MacBookのType-Cのもう一つの残念なポイントは、付属しているケーブルがなんとUSB 2.0であることです。何を言っているのかわからないかもしれませんが、Type-Cのケーブルだけど、中のUSB 2.0のケーブルしか接続されていないのです。これを使ってデータ接続すると、上記のベンチマーク結果 (60MB/s) のさらに1/10くらいの結果になってしまいます。MacBookに付属のケーブルは、充電を目的としたケーブルであり、データ転送はおまけ程度なのです。\nこのようにType-Cのケーブルはいろいろなものがありますので、注意が必要です。MacBook付属のケーブルはUSB 2.0接続でしたが、さらには電源だけしか接続されてないケーブルも世の中にはあるかもしれません。またUSB 3.1が接続されてはいてもGen 1速度用(5Gbps)であってGen 2の速度 (10Gbps) には対応していない可能性もあります。銅線ケーブルにとって10Gbpsは、物理法則の限界に挑戦する周波数です。良い素材を使って高速通信を前提に設計された製品でない場合は、額面通りの性能が出ません。Gen 2だけでなく、Thunderbolt 3 (40Gbps) やDisplayPortモードで使用する場合も、規格通りの性能の出るケーブルを選ぶ必要があります。大体は価格で見当がつきます。\nAliExpressで300円くらいで売られているType-Cケーブルは、PDは機能するもののデータ転送はUSB 2.0です。PDにも対応して10Gbpsの性能も出るケーブルは1,000円程度します。例えば、AliExpressで300円くらいで売られている以下のUSB2.0接続ケーブル、\nと900円くらいの以下のUSB3.0接続ケーブル\nを比較してみました。どちらもPDの性能は60Wのようです。接続状態を比較すると、以下のように、ケーブルの違いで10Gbps接続になったり480Mbps接続になったりと、違いが出ることがわかります。\nただ高速通信対応のType-Cケーブルは、高価なだけでなく、太く、硬く、短いため取り回しが不便です。充電にしか使わない、低速通信にしか使わないならば、あえて安価な低速ケーブルを選ぶのも良いかと思います。\nまとめ 自作HackintoshをMacBookとUSB Type-C接続しました。供給電圧は5V止まりで十分な電力は供給されませんでした。MacBookをTDMで起動すると、ドライブの内容をHackintoshから自由に読み書きできました。速度はあまり出ませんでしたが、ちょっとしたデータの交換に便利かもしれません。\n手元にあるHackintoshはどれもThunderboltが付いていません。なので、ThunderboltコネクタでのTDMが起動するMacでの動作は確認できません。でもIEEE 1394カードはつけてあるので、FireWire方式TDMが起動する古いMacでならデータ交換できるかもしれません。\n","date":"2020-02-15T01:39:41+09:00","image":"/uploads/2020/02/usbtypeclogo.png","permalink":"/posts/7782/","title":"MacBookと自作HackintoshをType-Cで接続する"},{"content":"SATA接続HDD/SSDのホットプラグに関する以下の記事をアップデートしました。最近のmacOSバージョンでホットプラグが効かなくなっていたのですが、コメントでパッチを教えていただき、快調に動くようになりました。\nSATA接続HDD/SSDのホットプラグ\n","date":"2020-02-11T17:15:22+09:00","image":"/uploads/2017/09/20170926165208.png","permalink":"/posts/7857/","title":"SATA接続HDD/SSDのホットプラグ（改訂版）"},{"content":"現行の300シリーズチップセットマザーボードでは、macOSがNVRAMにアクセスできない問題があります。NVRAMが使えないと設定が保存されないだけでなく、シャットダウンやスリープの動作にも支障が出ます。そのためにEmuVariableUefi.efiを使って、NVRAMをソフトウェアエミュレーションする必要がありました。NVRAM問題を、エミュレーションを使わずに、根本的に解決するSSDTがRedditで紹介されていました。\nこのSSDT-PMC.amlをEFI/CLOVER/ACPI/patchedに入れてみました。その結果、ASUS ROG MAXIMUS XI HERO (Z390)マザーボードのNVRAMが使えるようになりました。MSI B360M Mortar Titaniumでも試しましたが、同じ方法でNVRAMが使えるようになりました。\nEmuVariableUefi.efiのエミュレーションは優秀で、ちゃんと動作して何の問題もありませんでした。でも、本来のNVRAMが使えると気分が良いです。たとえば、SSDT-PMC.amlを使った結果、以下のnvramコマンド\n% sudo nvram hoge=test で試験的に設定したパラメータが、システム終了・再起動後に確認すると、\n% nvram -p | grep hoge hoge\ttest のように、電源を切っても保存されていた様子が確認できました。EmuVariableUefi.efiを使って動かしていた時には、保存されませんでした。これができなくてもmacOSの動作には関係ない様子ですが、何らかの機能で互換性が上がったかもしれないです。\n追記：コメントで教えてもらいましたが、NVRAMが動くようになると、config.plistのBootのセクションで起動ドライブを設定するときの、LastBootedVolumeの設定が動くようになります。\n以下はReddit投稿の抄訳です。\nr/hackintosh - NVRAM for all! 300 series users rejoice!\nOpenCoreパッケージの最新更新では、SSDT-PMC.dslという新しいSSDTが追加されました。このSSDTは、B360、B365、H310、H370、Z390用のNVRAMを復活させてくれます。\nそもそもなぜ、300シリーズマザーボードのNVRAMは壊れているのでしょうか？とても簡単です。ACPIの中で、MMIOとしてファームウェアチップを宣言することを、**Intelが「忘れた」**のです。そのため、XNUはUEFIメモリマップで宣言されたMMIO領域を無視します。そしてマップされていないページアクセスによってNVRAM SMMページフォルトが発生してしまうのです。\nこのSSDTの使い方 使い方は簡単で、設定不要で入れるだけです。OpenCoreに縛られていないため、Cloverユーザーも使うことができます。このDSDTにはLPCBが必要ですが、Z390ではこれが非常に一般的であることに注意してください。PCI0.LPCBを検索すれば確認できます。（訳注：この意味がよく理解できないのですが、おそらくDSDTのDevice (PCI0)の項目の中に、Device (LPCB)の定義がされていることが必要という意味だと思います。MaciASLを起動するとデフォルトのDSDTが開くので確認できます。）\n（訳注：このあと、macOS, Windows, Linuxでdslのコンパイル方法が説明されています。MaciASLの使い方についてはこちらをご覧ください。）\nファイルがコンパイルされると、SSDT-PMC.amlが得られます。コンパイルされたバージョンであるため、拡張子は重要です。dslは単なるソースコードです。SSDTを作成したら、これをEFI/CLOVER/ACPI/patchedまたはEFI/OC/ACPI (OpenCoreを実行している場合は、忘れずに設定に追加してください。) に入れます。コンパイルが面倒と思う人のために、ここにコンパイル済みのSSDT-PMC.amlを配布しておきます。\nNVRAMエミュレーションを削除する方法 以下を削除します。CloverでRCスクリプトをインストールしている場合は色々削除します。（訳注：デフォルトではRCスクリプトをインストールしない設定なので、EmuVariableUefiの削除だけで良いと思います）SIPをオフにしてR/Wでマウントする必要があるかもしれません。\n/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ユーザーの場合は、設定で次の項目を無効にするだけです。\nBooter-\u0026gt;DisableVariableWrite-\u0026gt;False NVRAM-\u0026gt;LegacyEnable-\u0026gt;False そしてEFIのルートにあるnvram.plistを削除するのを忘れないでください。\nNVRAMの動作をテストする方法 ターミナルを開き、一度に1行ずつペーストします。（訳注：sudo nvram -cは実行しなくても良いと思いました。適当なエントリーに値を設定するだけなら、SIPを無効にする必要はありませんでした。）\nsudo -s sudo nvram -c sudo nvram myvar=test exit 再起動して次のコマンドを実行します。\nnvram -p | grep -i myvar 何も返されない場合は、NVRAMが動作していません。myvar testを含む行が返された場合、NVRAMは動作しています。\nNote: nvram-cを使用するにはSIPがオフになっている必要があります。もしくはブートメニューでNVRAMを消去します。Cloverの場合は、F11キーを押します。OpenCoreの場合は、 CleanNvramを選択します。Misc-\u0026gt;Security-\u0026gt;AllowNvramReset-\u0026gt;YESに設定する必要もあります。\n","date":"2020-01-22T23:43:17+09:00","image":"/uploads/2020/01/image.png","permalink":"/posts/7682/","title":"300シリーズマザーボードでも本物のNVRAMを使いたい"},{"content":"長らくほったらかしになっていた銀色のマザーボード、MSI B360M Mortar TitaniumのUSBポートをちゃんと設定しました。USBポートの設定方法は、こちらのZ390チップセットマザーボードの記事もご覧ください。\n15個制限を回避するUSBInjectAll.kextの役割と使用法\n今回ご紹介するB360は、廉価版チップセットなのでUSBのポート数が少ないです。Z390が使用できるUSBポートは以下です。\nUSB2.0が14本 USB3.1が10本（そのうち6本までをGen 2にできる） これに対して、B360は廉価版ですので、\nUSB2.0が12本 USB3.1が6本（そのうち4本までをGen 2にできる） です。なのでmacOSの制限で15ポートになっても、諦めなければならないポート数は少ないです。\nUSBInjectAll.kextを入れる まずはUSBInjectAll.kextだけを入れて、IORegistryExplorerでxhcを検索します。ウィンドウの右上にある拡大鏡アイコンのついた検索窓にxhcとタイプします。すると、\nUSB 2.0であるHSが14本見えています。B360は12本なのですが、USBInjectAllにB360の情報がなくて、Z390だと思われているのかもしれません。ここで、マザーボードにUSB機器を接続して、それぞれのポートの位置を調べます。USBメモリーを使うと、抜き差しのほかにアンマウントする必要があるので、キーボードのドングルのようなデバイスの方が楽です。またマザーボード上のピンをチェックするために、USB Type A変換器を用意しておくと便利です。こういう小物パーツはAliで買うと格安ですね。\nこの結果、USB 2.0の関係がだいたい分かりました。\nHS01 2.0 2.0基板上 JUSB1 縁側 HS02 2.0 2.0基板上 JUSB1 内側 HS03 2.0 2.0バックパネル PS/2の下の上 HS04 2.0 2.0バックパネル PS/2の下の下 HS05 2.0 3.1 Gen 2 バックパネルのType-Cの上のUSB A HS06 2.0 Type-C (HS05にも反応する。） HS07 2.0 2.0バックパネル LANの下の下 HS08 2.0 2.0バックパネル LANの下の上 HS09 2.0 3.1 Gen 1 基板上 JUSB2 (どちら側かは不明） HS10 2.0 3.1 Gen 1 基板上 JUSB2 (どちら側かは不明） HS11 HS12 HS13 (B360なので使わない？） HS14 (B360なので使わない？） HS11からHS14は不明です。マザーボード上にはUSB 3.1 Gen2 Type-Cコネクタに接続するための内部コネクタがあるのですが、これに対応するパーツを持っていないので、試せませんでした。不明のうち2本は、おそらくそれに接続していると思います。また、B360はHSが12本のはずなので、不明のうちの2本 (多分HS13, HS14) は、元々存在していなかった可能性もあります。\n使用しない2.0を無効にする いずれにしてもこの4本は使用しないので、USBInjectAll.kextで無効にして良いと思われます。また、USB 3.1の様子を知りたいので、HS09とHS10も一時的に無効にしてみます。元から不要なUSR1, USR2も無効にします。そこで、Cloverの起動オプションを以下にしました。（slideはこちらの記事で設定したオプションです）\n\u0026lt;string\u0026gt;-v slide=128 uia_exclude=HS09;HS10;HS11;HS12;HS13;HS14;USR1;USR2\u0026lt;/string\u0026gt; この結果、IORegistryExplorerの様子は以下のようになりました。\nSSが6個見えるようになりました。総数が14個ですので、これで全部のSSが見えているはずです。今度は、USB 3.1のUSBメモリーを使って、IORegistryExplorerの反応を調べました。その結果、以下のように割り当てられているようです。\nSS01 3.1 Gen 2 バックパネルType-Cの上のUSB A SS02 3.1 Gen2 バックパネルのType-C 裏返しても同じ SS03 SS04 SS05 3.1 Gen 1 基板上 JUSB2 (どちら側かは不明） SS06 3.1 Gen 1 基板上 JUSB2 (どちら側かは不明） SS03, SS04は、HSと同様にパーツが無くて調べられなかった基板上のUSB 3.1 Gen2 コネクタの可能性が高いです。このコネクタを使わないなら、USBInjectAllのオプションで\n\u0026lt;string\u0026gt;-v slide=128 uia_exclude=HS11;HS12;HS13;HS14;USR1;USR2;SS03;SS04\u0026lt;/string\u0026gt; という設定を行えば良いかと思います。\nUSBを設定するSSDTを作る こちらで説明したように、USBを設定するSSDTを作成して、使用すべきポートを指定するやり方がより正しいようです。USBポートの素性を正しく記述できるので、macOSの動きがより正しくなるはずです。詳しい手順は過去の記事を見てください。流れを説明すると、まずは適当な名前でdslという拡張子のテキストファイルを作ります（例えばSSDT-UIAC.dsl）。以下のようなファイルです。ここでは、HS11からHS14、SS03, SS04, SS07以上、USR1, USR2を削除しています。\nSSDT-UIAC.dsl for MSI B360M MORTAR TITANIUM - Pastebin.com\nこれをMaciASLで開きます。次に、MaciASLのFileメニューからSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。こうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_exclude=を指定しなくても、指定したポートのみが有効になるはずです。IORegistryExplorerで確認すると以下のようになりました。\n","date":"2020-01-09T23:20:04+09:00","image":"/uploads/2019/06/product_6_20180402151821_5ac1d93dd6d06.png","permalink":"/posts/7401/","title":"MSI B360M MORTAR TITANIUMのUSBポートを設定する"},{"content":"Intel 300チップセットを搭載した現行のマザーボードからRTCの扱いが変わりつつあるようです。これが原因でmacOSの起動に失敗する事があります。DSDTへのパッチをconfig.plistに加える、もしくはBIOSで設定する事により回避できます。\nBIOSをアップデートして失敗したというこちらの記事\nASUSのBIOSを1105以上に更新すると起動しない\nで紹介した内容ですが、いまやHackintoshを作る上での一般的な注意事項になったと思います。なので、GUIDESカテゴリーに見合った内容に書き直して再掲します。\nReal Time Clock (RTC) コンピュータは、ファイルのタイムスタンプ管理やネットワーク同期など、いろいろな場面で正確な日付と現在時刻を必要とします。そこで、コンピュータの電源がoffになっても、日付と現在時刻を更新し続ける水晶時計機能が用意されました。これがRTC（Real Time Clock, 実時間時計）です。RTCは小さな部品としてマザーボードの片隅に載っていました。今ではチップセットに組み込まれています。RTCは、マザーボードの電源が切られた場合でも、マザーボード上のコインバッテリーで動き続けます。ちなみに太古のコンピュータにはRTCはありませんでした。なので、コンピュータ室を占拠する大型計算機も、AppleやNECの初期のパソコンも、電源を入れて最初に行う仕事の一つが、今日の日付と現在時刻の入力作業でした。\nRTCは現時刻を知る時計として使われるだけでなく、プログラム実行のきっかけを提供する目覚まし時計としても使われます。RTCにはコンピュータ作業に割り込みをする機能があり、割り込みで起動するタスクやスレッドを設定可能です。なので、毎日決まった時間に行う仕事、一定時間で繰り返す仕事などを設定しておけます。さらには、仕事の時間切れ管理にも使われます。例えば、特定のハードウェアがコンピュータに装備されているかどうかを確認する作業を考えてみます。そのハードウェアに、あなたは存在しますか？と問いかけるのですが、返事をじっと待っていては時間の無駄です。装備されていないために、永遠に返事が来ない可能性も高いです。そこで確認呼びかけと同時に、RTCに例えば10秒後にアラームしてくれるようにお願いします。そうすれば、返事を待つ間に別の仕事を実行したり、待っている間は休眠して他のスレッドにCPU資源を譲ることもできます。このように、外部デバイスにアクセスしつつ、アラームを仕掛けて返事を確認する作業は、macOSの起動時にもいくつも行われているようです。このような過程で、もしRTCのアラーム機能が動かなければ、macOSの起動が止まってしまう可能性があります。\nRTCの世代交代 300シリーズチップセットになってRTCの世代交代が進んでいるようです。BIOSメニューの表現を借りると、従来型のRTCからACPI (Advanced Configuration and Power Interface)のTime and Alarmデバイス（長いので以下、ACPI時計と書きます）に移行しているようです。そしてACPI時計を使う事がデフォルト設定になりつつあるようです。\nACPI時計ではOSが起動しない ところが、ACPI時計を使うとmacOSの起動が止まってしまうようです。最初に紹介した過去の記事では、ASUSのZ390マザーボードのBIOSを1105に更新したところ、ACPI時計がデフォルトで使われるようになってしまって、macOSが起動しなくなったことを書きました。-vで起動すると起動途中で文字表示が止まってそのまま動かなくなります。apfs.efiなのかVirtualSMCのあたりのメッセージで止まります。そのあたりの処理（apfsなら起動ドライブへのアクセスかもしれません）でRTCの割り込みが効かなくなり、処理が止まってしまったような様子です。RTCがACPI時計に置き換わって、使えなくなったのが原因だと思います。Cloverの問題なのか、macOSそのものがRTCに依存しているのかわかりませんが、この問題に対策を施さないとmacOSが起動しません。\n実はこの問題は、1年以上前からASRockのマザーボードで発生していました。ASRockはいち早くACPI時計をデフォルトにしたようです。これを回避するパッチが見つかるまで、ASRockのマザーボードではmacOSが起動しない状態がしばらく続きました。HackintoshするならASRockは避けた方が良いかなと思っていたところ、数ヶ月後のBIOSアップデートでASUSのマザーボードも同様にACPI時計がデフォルトになってしまいました。フォーラムの方で教えていただきましたが、MSIのマザーボードでもACPI時計がデフォルトになっているようです。GIGABYTEの様子は把握していませんが、おそらくここ1年くらいで、どのマザーボードもレガシーRTCからACPI時計に移行していると思われます。この対策として次の4つの方法があります。\n対策1 : BIOSでRTCを選択する ACPI時計への移行をやめて、レガシーなRTCを使い続ける設定が一部のBIOSにあるようです。以下で紹介されています。\nASUSのマザーボードには、Advanced–\u0026gt;PCH Configurationの中に、System Time and Alarm Sourceの設定があります。これをデフォルトのACPI Time and Alarm DeviceからLegacy RTCに変更すれば良いようです。\nところが全てのマザーボードにこのメニューが出てくるわけではないようです。例えば、ROG MAXIMUS XI HEROのBIOS ver. 1105, 1302, 1401の画面にはこの選択肢が出てきません。もしかしたら将来のバージョンでRTCの選択肢が出てくるようになるのかもしれません。という事で、このメニューが出ないマザーボードでは、BIOSでLegacy RTCを指定する方法は使えません。\n対策2：DSDTパッチを当てる 幸いなことに、ASRockのために配布されたパッチは、他のマザーボードでも動くようです。例えばこちらで紹介されています。\nパッチの元記事によると、「ASRockマザーボードのDSDTのバグで、そのうちASRockが治してくれると思うけど、とりあえずこのパッチが動く」という意見らしいです。でも、このパッチが他のマザーボードでも有効らしいので、ASRock限定のバグ対策では無い気がします。これはACPI時計への移行を無効にしているパッチ、もしくはACPI時計を利用する問題点を回避するパッチなのではと思われます。パッチの方法は、config.plistのACPI –\u0026gt; DSDT –\u0026gt; Patchesに以下の記述をすることです。\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;!DOCTYPE plist PUBLIC \u0026#34;-//Apple//DTD PLIST 1.0//EN\u0026#34; \u0026#34;http://www.apple.com/DTDs/PropertyList-1.0.dtd\u0026#34;\u0026gt; \u0026lt;plist version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;RTC fix\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; oAqTU1RBUwE= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; oAqRCv8L//8= \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/plist\u0026gt; ちなみにこのパッチが探しているデータ列と、置き換えているデータ列はそれぞれ以下のようです。\n% 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という文字を消そうとしているようにも見えます。\n対策3 : SSDTで対処する コメントで教えてもらいました。OpenCoreプロジェクトで、この問題に対処するSSDTが作られているようです。こちらにある\nOpenCorePkg/Docs/AcpiSamples at master · acidanthera/OpenCorePkg\nSSDT-AWAC.dslをMaciASLでコンパイルしてSSDT-AWAC.amlを作り、これを、EFI/CLOVER/ACPI/patchedに入れれば良いようです。それがうまく動かない場合は、SSDT-RTC0.dslを試すと良いようです。SSDT-AWAC.dslはこんな感じの内容です。先程のDSDTパッチと同様に、STASというパラメータらしきものを変更しようとしているようです。\n/* * For 300-series only. If you can\u0026#39;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 (\u0026#34;\u0026#34;, \u0026#34;SSDT\u0026#34;, 2, \u0026#34;ACDT\u0026#34;, \u0026#34;AWAC\u0026#34;, 0x00000000) { External (STAS, IntObj) Scope (_SB) { Method (_INI, 0, NotSerialized) // _INI: Initialize { If (_OSI (\u0026#34;Darwin\u0026#34;)) { STAS = One } } } } ASUSのROG MAXIMUS XI HEROで試してみました。現時点で最新BIOSは1401ですが、なんの対処もしない場合はmacOSが起動しません。そこで、SSDT-AWAC.amlをpatchedに入れたところ、無事macOSが起動しました。なお、これでうまく動いたので、SSDT-RTC0.amlは試していません。\n対策4 : 古いBIOSを使い続ける レガシーなRTCがデフォルトになっている古いBIOSからアップデートしないという消極的な解決策もあります。いろいろなバグが修正されているはずなので、一般的には最新バージョンの方が気持ち良いです。でもBIOSに限っては、動いているなら更新するなと注意しているメーカーのページも時折見かけます。全ての環境を網羅して動作試験を行うことは困難なので、問題なければアップデートして欲しくないという事情もわからないではありません。なので、古いまま使い続けるのは良い選択肢かもしれません。\nうっかりアップデートしてしまっても、古いBIOSがメーカーサイトで配布され続けていますので、それに戻せば良いです。ただ、新しいBIOSにすると、通常の手順では古いバージョンに戻せなくなる場合があります。そこでこちらの記事ではUSB BIOS Flashbackという機能を使って古いバージョンに戻しています。\nまとめ 現行のマザーボードがレガシーRTCからACPI時計に移行した事でmacOSが起動しない問題が発生することがあります。この問題は、DSDTへのパッチをconfig.plistに加える、もしくはBIOSで設定する、もしくはSSDTで設定を変更する事により回避できます。\n","date":"2019-12-28T15:06:42+09:00","image":"/uploads/2019/11/macosclock.png","permalink":"/posts/7195/","title":"300チップセットマザーボードのRTC設定"},{"content":"新Mac Proが供給され始めたので、Geekbenchのベンチマークサイトにスコアが上がるようになりました。最下位モデルは8コア16スレッドのXeon W-3223を搭載しています。これにならGeekbenchのスコアで9900Kが勝てるようです。\nMac Proと自作hackintoshで勝負 新Mac Proのベンチマークスコアが、紹介されています。（日本語の記事はこちらなどにあります。）\nBase and Middle Tier Mac Pro Models Offer CPU Performance Similar to iMac Pro\nそれによると、最下位8コアモデルのマルチコアスコアが7606くらい、16コアモデルが14285程度のようです。また、8コアMac Proは、8コアiMac Proや9900K搭載の8コアiMacに負けているようです。勝負しても虚しいだけなのですが、自作hackintoshと比較しました。ベンチマークしたのは、9900Kを使った自作\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\nと9600Kを使った自作です。\nMSI B360M MORTAR TITANIUM, 9600K\nそれぞれでGeekbench 5を3-4回動かし、シングルコア値が一番良かったスコアを比較に使いました。シングルコアとマルチコアのベンチマーク結果は以下です。Mac Proのスコアは、上記の元記事からいただきました。シングルスコアは、コア数少なめで設計してある9900K, 9600Kの方が、Xeonよりも優れています。\nSingle-core Multi-core Mac Pro 16 cores 1104 14285 Mac Pro 12 cores 1090 11599 9900K hackintosh 1360 8317 Mac Pro 8 cores 1008 7606 9600K hackintosh 1178 5601 一方で、Multi-coreの数値を比較すると以下のグラフになりました。\nコア数の多いMac Proの性能は圧倒的です。でも、コア数の一番少ないMac Pro 8コアにならば、9900K搭載自作hackintoshは勝てました。元記事では、9900K搭載のiMacも比較対象になっていますが、同程度のスコアになっていて、Mac Pro 8コアを上回っています。9900K自作PCは、RX 580搭載の場合、税込20万円以内で組めると思います。これに対して8コアMac Pro（こちらもRX 580相当を搭載）は税別で599,800円、税込ならば66万円くらいします。3倍以上の差がありますので、自作hackintoshのコスパは圧倒的です。とはいえ、開封動画を見るとMac Proの作りは素晴らしいです。高いだけに贅沢な作りがされています。\nWhat\u0026rsquo;s Inside the 2019 Mac Pro? Complete Disassembly and Analysis\n一方、9600Kは、コア数が6なのでやはり厳しいです。（シングルコアならばどのMac Proよりもハイスコアです。）でも9600Kで普通のコンピュータ作業は全く快適なので、これくらいのスコアを出すモジュラー型MacがApple製品の選択肢に無いことが残念です。iMacからディスプレイを外したデスクトップ、もしくは、Mac miniとMac Proの中間のディスプレイ無しデスクトップの選択肢として、hackintoshの存在価値は大きいと思います。\n","date":"2019-12-21T22:07:30+09:00","image":"/uploads/2019/12/macpro.png","permalink":"/posts/7393/","title":"新Mac Proと勝負する"},{"content":"AMDのNaviグラフィックスがmacOS 10.15.1からサポートされたものの性能が引き出せないでいました。先週 (2019/12/11) 10.15.2がリリースされたので、改善されると期待しましたが変化なしでした。\nRadeon RX580と5700XTの比較 進捗無しの記事です、すみません。AMDの新しいNaviアーキテクチャグラフィックスはmacOS 10.15.1から標準サポートされて、OOBで動きます。RX 580などのPolarisアーキテクチャ製品の後継として期待していました。でも、macOS上でのRadeon RX580と5700XTの性能を比較したところ、あまり差がなくて残念でした。\nRadeon RX580/Vega 64/5700XTの性能を比較\nこの時使ったmacOSは10.15.1でした。10.15.1のリリース後に、NaviアーキテクチャGPUを搭載したMacBook Proが発売されました。なので、10.15.2になれば、ドライバーが改善されて性能が向上するのではと期待していました。でも実測したところ、10.15.1と10.15.2で性能差はありませんでした。残念でした。\n上のグラフは、電源投入直後にGeekbench 5で5回計測したスコアの最大値です。実際の測定値は、以下です。\n10.15.1-OpenCL 10.15.1-Metal 10.15.2-OpenCL 10.15.2-Metal 580 47807 49600 47132 49624 5700XT 51988 41266 51170 42244 MacBook Proに搭載されているのは、実はPro 5300MとPro 5500Mという型番のGPUです。モバイル用のGPUで、市販されていません。先日、5500 XTというグラフィックスカードが発売されました。番号が同じなので、もしかしたら性能を引き出せているのかも知れないです。でもお手頃価格で入手できる旧型のRX 580の方がハードウェア仕様は上なので、微妙なところですね。しばらくはRX 580/590がHackintoshに最適な状態は変わらない気がします。\nMac Proでも同様の結果 先日発売されたMac Proに、Radeon RX 5700XT, Radeon VII, Radeon, Radeon RX Vega 64のリファレンスモデルを装着してGeekbench 5のスコアを測ってくれている動画がありました。\n2019 Mac Pro - Everything you can Upgrade \u0026amp; How!\nこれによると、それぞれのリファレンスモデルの\nRadeon RX 5700XTのMetalのスコアは42905 Radeon VII, RadeonのMetalのスコアは45885 Radeon RX Vega 64のOpenCLのスコアは57841 だそうです。今回と、前回の測定とほぼ同様のようです。実機でも、市販のカードだとこのくらいなのですね。\n","date":"2019-12-14T16:23:05+09:00","image":"/uploads/2019/06/catalinaicon.png","permalink":"/posts/7365/","title":"10.15.2にしたけどNaviの性能は向上しませんでした"},{"content":"Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありましたのでご紹介します。今回はAirportBrcmFixupとその他のkextの部分の抄訳です。原文は下のリンクを見てください。\nLiluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いです。前回は、WhateverGreenとAppleALCを紹介しました。\nLiluとプラグイン：(1) WhateverGreenの使い方\nLiluとプラグイン：(2) AppleALCの使い方\n（ここから抄訳）\nAirportBrcmFixup このプラグインの使い方は簡単です。これは、ネイティブまたは非ネイティブなBroadcom Airport WiFiカードに必要なパッチのセットを含んでいます。これによりcontinuityやhandoffを動かすこと, WiFiの名前をAirportデバイスと表示すること、そのほかいくつかのパッチを提供します。（訳注：日本語版macOSでは登録商標の関係でAirportではなくAirMacになります）他のLiluプラグインと同じく、大抵の場合、それまで試用していた全てのWiFi関係のパッチとエネーブラーkextを取り除いておく必要があります。このプラグインを使う理由の一つは、これがmacOS 10.13.Xと10.14.XでHandoffを有効にするCloverのパッチを使わなくて済む点です。このkextが自動的にWiFiデバイスを発見できれば、必要なすべてのパッチを当ててくれるので、Device Propertyを設定する必要はありません。\nもし、インストールされたWiFiアダプターのVIDとPIDが不明ならば、Hackintoolを使って、デバイスを特定し、PCIアイコンをクリックして、リストの中からWiFiデバイスを発見して、VID (Vendor ID) とPID (Device ID) を知ることができます。\n上の例では、WiFiデバイスのVIDは14E4 (Broadcom社のIDです) であり、PIDは43BA (BCM43602チップセット）です。\nWiFiデバイスがサポートされているのかどうかは、Git-Hubプロジェクトページのinfo.plistを見て、そこでWiFiデバイスのPIDを探せば確認できます。\nもしこのリストにVIDとPIDがあればokです。単にAirportBrcmFixup（とLilu）をインストールするだけです。\n必要ならばmacOSのWiFi地域設定を書き換えることもできます。起動オプションに\nbrcmfx-country=XX を追加します。これによりWiFiデバイスの国コードを明示的に設定することができます。（訳注：日本に設定するのでしたらbrcmfx-country=JPです）5GHz WiFiを稼働させたり、WiFiルーターをフルスピードで稼働させる場合、国コード設定が必要なことが時々あります。一般的な値は\nbrcmfx-country=#a です。これはルーターが設定する国コードを無視するようにmacOSに指示する特別な値です。私のルーターでは、どのバージョンのmacOSでも、#aを付けないと5GHz WiFiの最大速度が得られませんでした。\n注意： AirportBrcmFixupは、WiFiのことだけの面倒を見てくれます。Bluetoothを有効にするためには、RehabManさんのBrcmPatchRAMを使います。（訳注：コメントで指摘いただきましたがこちらもご覧ください。そちらのread meを見たら、アップル純正無線カードには関係のないようでした。）\n私は、 DW1830 (BCM43602) 搭載ラップトップでAirportBrcmFixupをテストしました。また、BCM943602CS搭載のデスクトップでも使いました。とてもよく動作し、他のパッチもエネーブラーも不要です。\nその他のLiluプラグイン 以下は、有用なLiluプラグインのリストです。ほとんどは、/L/Eに入れるだけです（訳注：ESPのkexts/Otherで良いと思います）。追加の設定は不要です。\nVirtualSMC Apple SMC (System Management Controller) を有効にするプラグインです。以前はFakeSMCを使うのが一般的でしたが、長らくアップデートされていません。環境によりますが、VirtualSMCは現在と未来のmacOSでより互換性があります。\nFakeSMCからVirtualSMCに移行するためには、FakeSMC.kextを取り除くだけでなく、EFIドライバーのSMCHelper.efiも取り除きます。また、FakeSMCセンサープラグインも取り除きます。\nVirtualSMCをインストールするには、VirtualSMC.kextの他に、VirtualSMC.efiもUEFIドライバーとしてインストールします。VirtualSMCの配布パッケージには、この他、光センサー、バッテリーモニター、CPU温度モニターやマザーボードセンサなどのプラグインkextも用意されています。詳しくはこちらをご覧ください。\nBT4LEContiunityFixup AirportBrcmFixupを入れてもなおBluetooth関連のcontinuity問題（AirDrop, Handoff, FaceTime, Apple Watch, Continuity など）が発生するようでしたら、BT4LEContinuityFixup を試してみるもの良いです。macOSのBluetooth LE Continuityを有効にするパッチが含まれています。 BrcmPatchRAM kextも一緒に使ってください。\nHibernationFixup その名の通り、HibernationFixup.kextはディスクにデータを保存するハイバーネーションモード3と25を特定のシステムで有効にします。私は使ったことがないのですが、これが動いたという報告は多数あります。ネイティブなNVRAMが使えることが条件です。エミュレートされたNVRAMでは使えません。\nNoTouchID 最近のMacBookシリーズSMBIOS設定はアップルの指紋認証(TouchID)搭載機種を対象としています。これらのSMBIOSをHackintoshで使用すると、起動時とシステムパスワードを表示する場面で遅延が発生します。というのは指紋認証デバイスが搭載されていないからです。NoTouchIDプラグインは、この問題を解決します。\nNightShiftUnlocker デフォルトではアップルのnight shiftは一部のSMBIOSでしか機能しません。この簡単なプラグインは、通常はnight shiftをサポートしていない機種設定でも、有効にします。\n","date":"2019-12-06T23:06:11+09:00","image":"/uploads/2018/08/20170915223211-e1556936489370.png","permalink":"/posts/7251/","title":"Liluとプラグイン：(3) AirportBrcmFixupなどの使い方"},{"content":"Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありましたのでご紹介します。今回はAppleALCの使い方の部分の抄訳です。原文は下のリンクを見てください。\nLiluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いです。前回は、WhateverGreenを紹介しました。\nLiluとプラグイン：(1) WhateverGreenの使い方\nAirportBrcmFixupに関しても後ほど紹介したいと思います。\n（ここから抄訳）\nAppleALCとは AppleALCはLiluのプラグインです。ネイティブでないオーディオコーデックに対してHigh Definition Audio (HDA)を有効にするために、AppleHDA kextに動的にパッチを当てます。WhateverGreen (以下WEG) と同様に、オーディオを有効にするために従来使用していた多くのパッチとkextを置き換えてくれます。なのでAppleALCを使用する前には、既にあるAppleHDAを有効にするパッチ、ダミーのkext、DSDTへの変更などを取り除いておき、AppleHDAをオリジナルの状態のkextに戻しておく必要があります。\nNvidia HDMIオーディオ AppleALCはほとんどのNvidia GPUでHDMIオーディオを有効にします。必要な作業は、LiluとAppleALCをインストールする事だけです。もしHDMIをサポートしたNvidiaカードが使われていたら、AppleALCはこれを検出して、HDMIオーディオコントローラを有効にします。サポートされたNvidiaデバイスはこちらのページを見てください。Nvidiaデバイスのこのリストの最後にあります。\nオンボードオーディオコーデック AppleALCは、Raltek (ALC)、Conexant、IDTなどの多くのビルトイン（オンボードの）オーディオコーデックをサポートします。大抵の場合、やるべきことは、LiluとAppleALCをインストールして、config.plistに簡単な変更を加えるだけです。が、その作業の前に、AppleALCがどのように機能するか知っておくと良いです。\nAppleALCはどのように動くのか AppleALCの動作は従来の、AppleHDAに予めパッチを当てたり、ダミーを使ったりする方法と少し違います。AppleALCはコネクター、レイアウト、プラットフォームパッチの大規模なデータベースと理解できます。ロードされる際に、LiluとAppleALCは使用されているオーディオコーデックのタイプを自動的に検出し、データベースからパッチを探して、AppleHDAに動的にパッチを当てます。\nAppleALCが使うパッチは、インデックス識別子により定義されています。バックワード互換性のために、パッチセットのインデックス識別子はlayout-idと呼ばれるプロパティ値で定義されています。layout-idはhackintoshのコミュニティで昔から使われてきた値で、パッチを当てたバージョンのAppleHDA（もしくはダミーHDA kextの）のレイアウトを選択する値です。\nAppleALCのwake verb 追加の機能として、AppleALCはほとんどのコーデックのwake verbの面倒を見てくれます。なので、Codec Commanderをインストールしたり使用する必要はありません。（訳注：コンピュータがスリープするとオーディオアンプもoffになります。スリープから目覚めるときに、アンプがonにならなくて、スリープ復帰後に音が出ない問題が発生する事があります。wake verbはスリープ復帰時にアンプをonにするための特別なデータのようです。これを流す事でアンプがonになるようです。〜という理解で正しいでしょうか？間違っているようでしたらコメントで指摘してください。）\nLiluとAppleALCのインタラクション （訳注：この節の内容は理解できませんでした。すみません）\nLiluがロードされると、Liluはlayout-idの値を見つけて、その値をAppleALCに渡します。この値を継承して、AppleALCはalc-layout-idという名前の新しいデバイスプロパティを作ります。AppleALCは次に、layout-idの値を新しいターゲットID（通常は7）に設定し、AppleHDAのターゲットレイアウトに（Liluのパッチエンジンを使って）パッチします。この時、指定した（alc-layout-idで指定された）コーデックのための、コネクターID情報、infoファイル、プラットフォームファイルが使われます。\nこの方法により、AppleALCはMojaveのドロップドレイアウトIDを無視します。（詳細はこの記事のオーディオの節を見てください）。というのは、インジェクトされたlayout-id値は、AppleALCのコーデックパッチデータベースのインデックスとしてのみ使われるからです。AppleALCはこのlayout-idによる再マップする枠組みを、Mojaveだけでなく、全てのバージョンのmacOSで使います。\nサポートされているコーデックを確認 使用しようとしているコーデックをAppleALCがサポートしているかどうかは、ソースコードのResoucesフォルダの中で名前を探せば確認できます。コーデックがサポートされていなかったら、公式のAppleALCヘルプスレッドに投稿して、次のバージョンで入れてもらうよう依頼してください。そのコーデックの詳細（このスレッドの#1投稿を見てください）を投稿します。達人の誰かが、その投稿を見て、手助けを申し出てくれるでしょう。おそらく、Linuxを使ってコーデックのダンプを用意する必要があります。このガイドの対象外の話題なので、ここでは詳細に関して説明しませんが、あなたの投稿を見た誰かがダンプの取り方を説明するリンクを示してくれるはずです。\nもし、使用しようとしているコーデックが、既にAppleALCでサポートされていたら、どのレイヤーがサポートされているかを、対応するコーデックフォルダにある、info.plistファイルを開いて知ることができます。これから、どのレイヤーIDが使用可能なのかがわかり、また、コメントからそのうちのどれを使うべきかを知ることができます。\n一例として、私の2017年版HP Spectre X360ラップトップの場合は、Realtek ALC295コーデックを搭載しています。そこで、ALC295フォルダの中のinfo.plistを開きます。以下に示します。\nALC295 の info.plist（tonymacx86.com の画像）\nこの例では、Mironeさんのパッチが必要なパッチであり、これがレイアウト3であることがわかります。このように、コメントを読めば、システムに必要なレイアウトの記述を簡単に見つけられます。もし、全ての使用可能なレイアウトID値のリストが不明な場合、一つ一つ試して動く値を探します。また、Hackintoolを使ってどのレイアウトがサポートされているのか（下の方法で詳細を説明します）知ることもできます。\nAppleALCの設定 AppleALC.kextをインストールした後ですべきことは、layout-idを設定することです。2つの方法があります。\n方法1：Audio Injectで設定する（古い方法） Liluはconfig.plist内のレガシーなパラメータであるClover/Device/Audio/Injectからlayout-id値をCloverに問い合わせる機能があります。なのでInjectのString値を正しいlayout IDに設定すれば良いです。以下のようにします。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AFGLowPowerState\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;3\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ResetHDA\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; LiluがClover/Devices/Audio/Injectからlayout-idを取得するというレガシーな方法をサポートしなくなる可能性があることは注意すべきです。なので、次に示す方法2が良いです。\n方法2：Device Propertiesを使う（おすすめ） AppleALCとLiluをインストールした後、config.plistを編集して、Devices/Audio/Injectを”No”にします。そしてLayout-idをカスタムDevice Propertyとして設定します。ここで、Audio Device Propertyコードを作成するために、Hackintoolを使います。HackintoolのAudioアイコンをクリックすると、検出されたコーデックタイプが表示されます。ここで設定したいHDAオーディオデバイスを選びます。するとAudio Infoに詳細な情報が出て、ドロップメニューでLayoutを選べるようになります。ドロップメニューには検出されたコーデックに適用可能なlayout IDのみが表示されます。\n項目選択が終了したらPatchアイコンを押し、Patch機能を呼び出します。もしオーディオデバイスがシステム情報のPCIデバイスセクションの中で正しい名前で表示させたかったら、Advanced optionsの中のSpoof Audioオプションを選択します。この時Advancedページの他の項目は全てチェックを外します。\n次に、Generalをクリックして、Device / PropertiesとAudio Deviceオプション以外のチェックを全部外して、Generate Patchをクリックします。\nここに現れたコードを、config.plistの該当する部分にコピーペーストします。以下のようになります。（訳注：Z390チップセット搭載マザボのALC1220を対象に同じ操作をしたのですが、心当たりのないmodel名になっていたり、hda-gfxという項目があったりしました。model名は適当に編集して、hda-gfxの項目は削除して良いのだと思います。）\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x1f,0x3)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,slot-name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Internal\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; cKEAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;device_type\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Audio device\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;layout-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AwAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;model\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Sunrise Point-LP HD Audio\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; config.plistの変更が完了したら、再起動してオーディオが動いているかどうかテストします。もし動いていなければ、他の有効なlayout-IDを試してください。\nもし、全ての有効な値を試してもオーディオがまだ動かない場合は、新しいパッチセットが必要なコーデックを使っているのかもしれません。サポートされていないコーデックに関しては、AppleALCのヘルプスレッドを利用してください。\nAppleALCのトラブル対策 AppleALCがロードされていることを確認する AppleALCが正しくロードされて初期化されていることは、IORegisteryExplorerで確認できます。これはこちらのリンクからダウンロードできます。\nIORegisteryExplorerを動かして、HDEFという文字を検索ボックスに入れます。ioregディレクトリーツリーにHDEFデバイスが見えるはずです。上の例では、次のように見えます。\nHDEFが見えないようでしたら、LiluとAppleALCのインストール手順を確認してください。以下のACPI HDA/Codec Rename 問題も見てください。\n上のスクリーンショットでは、AppleALCが動的に新しいプロパティalc-layout-idを作り出している事がわかります。ここでの3という値は、config.plistで設定した値です。同様に、layout-idという項目は7とあります。これは、AppleALCがパッチを当てようとしている対象のAppleHDAでのレイアウトで、macOSが使っているものです。\nもし、HDEFの中にalc-layout-idが見つからない場合、AppleALCが正しくロードされていない、もしくは初期化されていないのかもしれません。この原因は、kextが正しくインストールされていないからです。kextを削除して、インストールを再度試みてください。\nHPET 問題 (High Precision Event Timer) 上記のステップが正常でもなお音が出ない場合、HPETによってIRQの衝突が発生している可能性があります。\nmacOSにおいて、HPETは基本的に必要な仕組みです。これが正しく働く必要があります。このフォーラム（訳注：tonymacx86のフォーラム）のほとんどのガイドでは、BIOSでHPETを有効に設定していることを前提としています。しかしながら、いくつかのマザーボードとラップトップでは、HPETに関するネイティブなDSDTコードがIRQ衝突を引き起こし、AppleHDAの正しい初期化を妨げたり、雑音を出す事があります。\nこの問題を確認する一つの方法は、ターミナルで次のコマンドを入力する事です。\nkextstat | grep \u0026#39;Lilu\\|AppleALC\\|AppleHDA\u0026#39; この結果、Lilu, AppleALC, AppleHDA kextがリストアップされるはずです。\nMonkeyPro-2018:~ Jay$ kextstat | grep \u0026#39;Lilu\\|AppleALC\\|AppleHDA\u0026#39; 20 4 0xffffff7f81041000 0x22000 0x22000 as.vit9696.Lilu (1.2.8) 54014689-C8DA-318B-84F4-944BBA7AD2AC \u0026lt;8 6 5 3 2 1\u0026gt; 23 0 0xffffff7f811bd000 0xdf000 0xdf000 as.vit9696.AppleALC (1.3.3) B60FCBAF-6BC2-36EF-A1E6-D5BE2863C35B \u0026lt;20 13 8 6 5 3 2 1\u0026gt; 138 1 0xffffff7f830a7000 0x1d000 0x1d000 com.apple.driver.AppleHDAController (282.10) 70256EC9-AF38-31BD-A3C5-9C0E30B64AA3 \u0026lt;137 113 107 13 8 7 6 5 3 1\u0026gt; 157 0 0xffffff7f8323a000 0xb7000 0xb7000 com.apple.driver.AppleHDA (282.10) B2208DA8-8CD9-36D8-BD59-C6D9A5379585 \u0026lt;156 138 137 124 113 107 7 6 5 3 1\u0026gt; 159 0 0xffffff7f830c6000 0x2000 0x2000 com.apple.driver.AppleHDAHardwareConfigDriver (282.10) C4F674A0-5828-3D97-82BF-A81C8B8BDDBA \u0026lt;5 3\u0026gt; この例から分かるように、AppleHDA、AppleHDAController、 AppleHDAHardwareConfigDriverとインストールされています。ここで重要なのは、 AppleHDAです。\nもしAppleHDA (com.apple.driver.AppleHDA)が出力に現れていなかったら、HPETオプションが正しく有効になっているかどうかを確認してください。もし有効になっていてもAppleHDAが現れなければ、DSDTのHPETコードにパッチを当てる必要があります。\nこれを行う最も簡単な方法は、CloverのACPI/DSDT/Fixesの中の FixHPETをtrueにする事です。\n\u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Fixes\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixHPET\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; この方法はほとんどのユーザで有効です。でも、もしCloverのHPETフィックスでもまだAppleHDAがロードされない場合、DSDTに直接パッチを当てる必要があるかもしれないです。RehabManさんがこのパッチを作ってくれていて、MaciASLを使って適用できます。\n#Maintained by: RehabMan # HPET fix to avoid AppleIntelCPUPowerManagement panic into method label _STA parent_hid PNP0103 remove_entry; into device name_hid PNP0103 code_regex Name\\s\\(_STA\\,\\s+0x0F\\) remove_matched; into device name_hid PNP0103 insert begin Name (_STA, 0x0F)\\n end; into method label _CRS parent_hid PNP0103 remove_entry; into device name_hid PNP0103 insert begin Method (_CRS, 0, NotSerialized)\\n {\\n Return (BUF0)\\n }\\n end; このパッチをDSDTに当てるためには、MaciASLを使い、Patchボタンを押し、上記のコードをパッチエディターにコピーペーストします。そしてApplyボタンをクリックして、DSDTを保存します。詳しい情報は、Rehabmanさんのガイドを見てください。また、DSDTにパッチを当てた場合は、Cloverのfixは無効にしておきましょう。\nACPI HDA/Codec 改名問題 WhateverGreenと同様に、 AppleALCとLiluはDSDTの中のACPIの名称を適切に自動的に改名してくれます。しかし時々失敗することもあり、手作業で改名する必要があります。この改名が正しく実施されているかどうかは、IORegistryExplorerを開いて、HDEFを検索してみればわかります。\nもしHDEFがioregに存在すれば、これ以上の作業は不要です。しかし、もし存在していなければ、ここまで述べた作業が正しく行われているかどうかを確認してください。それでも解決しなければ、HDEF名称変更を手作業で行ってみる必要があります。\nまずは、バニラな状態のDSDTをMaciASLで開いて、HDEFで検索して、元々のHDAデバイスの名前を確認します。もし検索結果がなければ、HDASで検索します。それがなければAZALで検索します。\nもしHDAデバイスがHDEFと名付けられていたら、デバイスを改名する必要はありません。もしHDASと呼ばれていたら、次のコードをconfig.plistのACPI/Patchesに追加します。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change HDAS to HDEF\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SERBUw== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SERFRg== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; もしAZALでしたら、以下のパッチを追加します。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change AZAL to HDEF\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; QVpBTA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SERFRg== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; ","date":"2019-12-01T11:30:54+09:00","image":"/uploads/2018/08/20170915223211-e1556936489370.png","permalink":"/posts/7134/","title":"Liluとプラグイン：(2) AppleALCの使い方"},{"content":"Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありました。ここからLiluとWhateverGreenの部分を抄訳して紹介します。原文は下のリンクを見てください。\nLiluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いですので、LiluとWhateverGreenの部分を紹介します。残りの、 AppleALCに関してはこちらをご覧ください。\nLiluとプラグイン：(2) AppleALCの使い方\nAirportBrcmFixupに関しても後ほど抄訳したいと思います。\n（ここから抄訳）\nLiluとは何か LiluはmacOSのパッチエンジンです。カーネルとシステム拡張を起動時に拡張します。使用することのメリットは多いです。\n特定のブートローダーに依存しない リカバリーモードやmacOSインストーラ・アップデータでも動く シンボリックパッチエンジンもサポートする カーネルとシステム拡張へのAPIアクセスを可能にする 起動中のプロセスの変更も可能 Liluはパッチの仕組みを提供するだけで、それだけでは何もしません。プラグインと一緒に使うことで機能します。Liluパッチを作成するための開発キット(SDK) も用意されています。有名な3種のパッチは、WhateverGrenn, AppleALC, AirportBrcmFixupです。以下ではこれらについて説明します。Liluプラグインの全てのリストはLiluのGitHubをご覧ください。（訳注：VirtualSMCもLilu使ってたんですね。）\nLiluプラグインはそれだけで機能し、同様の機能を提供する従来型のCloverのパッチやkextを置き換えます。そのため、関係するClover設定、FakeID, パッチ、kextがすでに導入されていたら、それを取り除いてください。例えば、LiluプラグインであるAppleALC.kextをインストールしたら、CloverのAppleHDAパッチとHDA Enabelerのパッチやダミーのkextは全て取り除くか無効にします。競合するパッチが残っていると、システムが予想外の動作をしたり、不安定な状態になります。\nHackintool 以下の説明ではHackintoolを使います。ぜひ備えておいていただきたいツールですので、ここからダウンロードしておいてください。\nLiluとプラグインのインストール方法 LiluとそのプラグインはmacOSのkextとして提供されます。これらは、 /Library/Extensionsに入れるべきです。Cloverのkexts/Otherに入れるとしたガイドも多いですが、この方法は試験や開発だけに留めておくのが良いです。サードパーティのkextを入れる正式な場所は/Library/Extensionsです。（訳注：どちらが良いかは議論のあるところだと思います。簡単なのでkexts/Otherで良いのではないかと思います。これ以降、/Library/Extensionsに入れるための方法が続きますが省略します。Catalinaになるとセキュリティ保護が厳しくなるので、かなり面倒なようですね。）\nWhateverGreen (WEG) WhateverGreen（以下WEG）は2017年にAMD GPUのためにリリースされましたが、現在（2019年）では以下の機能を統合しています。\nIntelGraphicsDVMTFixup –\u0026gt; Intel IGPU DVMT Pre-allocationのパッチ IntelGraphicsFixup –\u0026gt; Intel IGPU’sをサポートするための多数のパッチ NvidiaGraphicsFixup –\u0026gt; Nvidia GPUをサポートするための多数のパッチ CoreDisplayFixup –\u0026gt; High DPI表示のパッチ (pixel clock patch) Shiki –\u0026gt; DRMで保護されたビデオ再生のためのパッチ AzulPatcher4600 –\u0026gt; HD4600 IGPUのAzulフレームバッファのためのパッチ AppleBacklightFixup –\u0026gt; バックライト制御のプラグイン EnableLidWake –\u0026gt; ラップトップの蓋操作でスリープ解除するためのパッチ このようにWEGは、GPU/IGPUとディスプレイに関する全ての解決策を提供します。また、統合されてしまった上記のプラグインは、WEGと一緒に使わないでください。カーネルパニックやOSの異常動作を引き起こす可能性があります。\nWEGの前準備 Cloverのconfig.plistから、IGPUに関する全てのインジェクション、設定、フェイクIDなどを除去してください。これを行わないと、WEGの動作と衝突することになり、想定外の結果を引き起こします。\n最新版のLiluとWEGを/L/Eに入れます。（訳注：kexts/Otherでも良いと思います。）\nWEGはデバイス改名処理も行います。なので、Cloverのconfig.plistに次のようなACPI Fix/Renameの箇所があれば、これを削除します（もしくは無効にします）。\nGFX0をIGPUに変更するパッチ PEG0をGFX0に変更するパッチ HECIをIMEIに変更するパッチ これらのClover ACPI Fix/Renameの手法は、ACPIのテーブル全体に変更を与えてしまうために、後に問題を引き起こす可能性があります。WEGの方法は特定のACPIコードを探索して、そこだけを変更しますので、優れています。\nAMDとNvidiaのdGPU AMDとNvidiaユーザは、Lilu と WEGをインストールすることで、フレームバッファもdGPU関係のパッチも全て対応できます。上級者向けには起動オプションが多数ありますので、WEGのreadme.mdを見てください。Liluの概要で述べたように、AMDとNvidiaのGPUに関するパッチは、config.plistから削除してください。WEGがこれらを全てやってくれます。\nIntelのiGPU iGPUだけのシステム、もしくはdGPUと併用するシステムでは、WEGは従来の方法より早くて簡単なカスタマイズ手段を提供します。従来の方法では、Cloverを使ったり、Intel iGPUドライバーにパッチを当てたり、フレームバッファkextにパッチを当てたりしていました。\nWEGをそのまま使う 最近のWEG (V1.3.0以降) は、改善されたiGPU自動検出と自動設定の機能があり、追加の作業なしでたいていのシステムでそのまま動きます。まずは、上記で説明したWEGの前準備を実行しておいてください。その後、単にLiluとWEGをインストールして再起動するだけです。なお、SMBIOSの記述はWEGの自動設定に影響を与えます。\n（訳注：GPUを動かすためには、「前準備」をして、LiluとWEGを入れるだけで良いということです。それで問題なく動く場合は、この先は参考程度に読んでください。）\nWEGの自動設定は非常に改善されてはいますが、完璧ではなく、全てのシステムで機能するわけではありません。自動設定が機能しない場合は、WEGを手作業で設定しなければなりません。また、dGPUが搭載されている場合、WEGはiGPUを「ヘッドレス」に設定したいところです。でもそのためにはiGPUとdGPUがBIOSで正しく設定されている必要があります。ヘッドレスに関して後で詳細に説明します。\nWEG手動設定に必要なID情報 WEGはDevice Propertiesを使って設定を行います。これはCloverを使ってデバイスioregディレクトリーツリーのカスタムプロパティを定義する比較的新しい方法です。Lilu開発メンバーからのリクエストでCloverに実装された手法です。デバイスプロパティについての詳細はClover開発ブログのこちらをご覧ください。\nデバイスプロパティは、Cloverのconfig.plistのDevices –\u0026gt; Propertiesセクションで定義されます。プロパティは、PCIパスで決まる名前とデータ値から構成されます。名前とPCIパスはタイプで、データ値は次の3種類のうちの一つで表現されます。\niGPU デバイスプロパティ 全てのiGPUパッチは、Hackintoolのトップメニューの2番目のアイコンにあるパッチモードで実行できます。また、下のバーメニューを使ってパッチモードのサブ機能を使えます。Patchをクリックして、infoを選択してみました。\nもしHackintoolがシステムのCPU世代を正しく特定しているものの、Platform IDドロップダウンメニューが空で、FramebufferとConnectorサブメニューにデータが表示されない場合は、HackintoolのメニューバーのFramebufferをクリックして、macOSバージョンを使用中のものに設定してください。\nもしHackintoolがCPU世代を自動的に特定できなくて、Current Framebuffer Infoボックスに???が表示されたり、Hackintoolが誤った世代のCPUを選択しているようならば、ドロップダウンメニューから手作業で正しいCPU世代を設定できます。\nHackintoolを最初に起動すると、iGPUを検出して、それ用のデフォルトPlatformIDを選択しますが、多くの場合、これらは正しくないので、最初にこれを正しく選択させる必要があります。\nInfoサブ機能を選択すると、検出されたiGPUのタイプが下のCurrent Framebuffer Infoボックスに表示されます。また選択されたPlatformIDの詳細と、合致したSystem Definitions (SMBIOS)が上のSelected Framebuffer Infoボックスに表示されます。\n例えば、2017年版HP Spectre X350ラップトップで最初にHackintoolを動かした時は、PlatformIDとして0x591B0000が選択されて、System Definition (SMBIOS) としてMacBookPro 14,3が推奨されました。\n上の図では、矛盾した情報が表示されています。iGPUは正しく検出されていて、Current Framebuffer InfoボックスにはHD 620であると表示されていますが、Selected Framebuffer Infoボックスには0x591B0000はHD 630 iGPUであると表示されています。なので、PlatformID 0x591B0000は間違っていることがわかります。これをPlatformIDドロップダウンメニューから正しいものに変更します。もし、必要とするPlatformIDが分からないなら、ドロップダウンメニューから一つ一つ順番に選択して、iGPUタイプに合致するIDを探します。（訳注：https://arc.intel.com/で使用しているCPUを検索すると16進数4桁のデバイスIDが分かります。IntelのベンダーIDは8086なので、このデバイスIDと8086をつなげた番号がGPU Device IDに現れるべき数値になります。Platform IDを変えていくと画面に表示されるGPU Device IDも変化するので、上位4桁がarc.intel.comの番号に合うように選択すると良いと思います。）\nラップトップPCの場合は、モバイル用のPlatform ID（Mobile の欄に Yesと表示が出ます）を選択します。デスクトップPCの場合はMobileがNoのものを選択します。\n私のHP Spectre X360ラップトップでは、0x59160000が必要であると分かっていましたので、ドロップダウンメニューからこれを選択しました。\nさてこれで、Selected Framebuffer InfoボックスとCurrent Framebuffer Infoボックスで同じiGPUタイプが表示されるようになりました。HP Spectre X360ラップトップはMobile HD 620 iGPUで、推奨のSystem Definition (SMBIOS)はMacBookPro14,2です。\nプロの技：@headkazeさんによるリストを使うことでも、PlatformIDを見つけることができます。これは、macOSで使えるPlatformIDとFrameBufferのリストです。これを使えば、例えば、Coffee Lake CPUを使う場合、Coffee Lake CPUセクションまでスクロールすると、最初に全てのPlatform IDがまとめられています。ここには、MobileかDesktopシステムなのかが書いてあります。またコネクタの数が0になっているIDは、ヘッドレスのものです。\nそれぞれのPlatform IDの詳細は、少しスクロールすると見ることができます。例えばPlatform ID 0x3E9B0000の詳細は以下のように書かれています。\nこの情報から、このPlatform IDがMacBookPro15,1で使われていることがわかり、これがIntel UHD 630 iGPUのPlatform IDだとわかります。Hackintoolからもこれらの情報はわかりますが、リストアップされた形式で確認する方が簡単なこともあります。\nHD 4600 iGPUに関する特記事項：上記のリストでIntel HD 4600 のPlatform IDが0x4160000になっています。でも私の経験では、Platform IDを0x0D220003 (これはIntel Iris Pro Graphics 5200のものです）にし、device-idは0x0412 (これはIntel HD 4600のもの）にし、iMac14,2にするのがよかったです。またHDMIを使うためには、こちらのパッチが必要です。この理由はわかりませんが、おそらくmacOSが他のIntel CPUとは違うAZUL Framebuffer kextを使っていることが原因かと思われます。\n**重要：**選択したPlatform IDに合ったSystem Definition (SMBIOS)を使うようにしましょう。Hackintoolは多くの場合、推奨するSMBIOSを上のSelected Framebuffer InfoボックスのModel(s)欄に表示してくれます。Platform IDと合致しないSMBIOSを使うとmacOSが動作不良に陥ります。\n**注意：**いくつかのPlatformIDでHackintoolのModel(s)欄に推奨System Definition (SMBIOS)が表示されない、もしくはUnknownと表示されることがあります。これはそのGPU、IGPU、Platform IDと合致するMac機種が存在しないからです。しかし、IGPU Platform IDは有効で機能するはずです。でも、できるならば、使用しているiGPUに合致したフレームバッファを持つ他のPlatform IDを選択し、それから推奨されるSMBIOSを選ぶのが良いです。\n適合するPlatformIDが見つからない場合 もし使用しているiGPUに合致するPlatform IDを見つけられない場合、最も近いものを代わりに選ぶことになります。例えば、UHD 620を使っている場合、最も近いのはおそらくUHD 630のPlatform IDです。他の例では、HD 4400 iGPUの場合は、HD 4600またはHD 5200のPlatform IDを選ぶと良いです。これらの場合、システムをちゃんと動かすために、異なるPlatform IDをいくつか試すことになります。\nもしシステムがラップトップならば、MobileがYesになっているモバイル用のiGPU Platform IDを選択します。（訳注： arc.intel.comで該当するCPUの仕様を見ると、「システムの種類：Mobile」などと書かれた項目があるので、それに合わせるのが良いと思います。）\nもし、iGPUと合致しないPlatform IDを使う場合、対象のiGPUタイプのデバイスIDを知る必要があります。これは後で説明します。\n適合するSMBIOSが見つからない場合 もし推奨SMBIOSに対するPlatform IDが見つからない場合でも、動かないわけではありません。この場合は、作ろうとしているシステムに一番近い、合致するSMBIOSを推測することになります。この作業に便利なツールがMacTrackerです。\n**注意：**もしSMBIOSを変更する必要がある場合、iCloudなどのAppleのオンラインサービスからログアウトすることを忘れないでください。また、iDiot’s Guide To iMessage を見て、新たに設定をおこなってください。（訳注：Appleからbanされることもあるので注意しましょう。SMBIOSの試行錯誤をする場合は、ネットから切り離して作業するのが良いと思います。）\nヘッドレスPlatform ID デスクトップHackintoshユーザが、Hackintoolが推奨するPlatform IDを上書き変更したいと思うもう一つの状況は、iGPUをヘッドレスモードで使いたいという場合です。（訳注：ヘッドレスというと、通常は、PCをネットから制御することを前提に、ディスプレイ無し使用することを言います。でもここでは、dGPUにはディスプレイを接続するけど、iGPUにはディスプレイを接続しないという意味のようです。）\niMacや幾つかのMac miniのように、デュアルGPUを搭載している純正のデスクトップ型Macは、ヘッドレスPlatform IDを使っています。これにより、macOSにiGPUには物理的なディスプレイが接続されていないこと、しかしハードウェア加速機能のためにmacOSがiGPUを使用できること、を伝えています。iGPUがヘッドレス利用と設定されると、macOSはiGPUを、AirPlayのミラーリング表示機能や、静止画・動画の符号化・復号化機能 (Intel Quick Sync -iOS)などで使うための、ある種のGPU副プロセッサとして使用します。これはmacOSの重要な機能です。ですので、もしdGPUの他にサポート対象のiGPUがあるならば、iGPUをヘッドレス構成に設定すべきです。\n**注意：**ワークステーションクラスのCPU (Intel Xeon) を搭載したシステムは、iGPUを備えていません。なので、ヘッドレスPlatform IDを設定してはいけません。\nもし、ヘッドレス構成が不要ならば、次の、「WEGの手動設定」まで読み飛ばしてください。\nHackintoshの主ディスプレイアダプターがNvidiaやAMDのdGPUであり、サポート対象のiGPUも備えていたら、ヘッドレスPlatform IDを使えば、そのHackintoshシステムは安定になり、iGPUによるハードウェア加速機能を備えた純正のMacのように振る舞います。\niGPUをヘッドレスモードで動かすためには、以下のBIOS設定を行います。\nIGPU -\u0026gt; Enabled Primary Display Adapter -\u0026gt; dGPU (PEG) Multi-Monitor Mode -\u0026gt; Enabled (このオプションがある場合) また、デュアルGPU構成をサポートし、使用中のCPU/iGPUタイプに合致するMacのSystem Definition (SMBIOS) を正しく設定しておく必要があります。ヘッドレスPlatform IDのためのオススメのSMBIOSは以下です。\nCoffee Lake CPU = SysDef: imac19,x Kaby Lake CPU = SysDef: imac18,x SkyLake CPU = SysDef: imac17,x Haswell CPU SysDef: imac14,x または imac15,x Ivy Bridge CPU SysDef: imac13,x または macmini6,x Sandy Bridge CPU = SysDef: imac12,x または macmini5,x **注意：**もし使用中のCPU. iGPUと選択したヘッドレスPlatform IDが既知のMac構成と合致するなら、Hackintoolは合致したSystem Definition (SMBIOS)を上のSelected Framebuffer Infoボックスに表示します。\n現在知られているヘッドレスPlatform IDは以下です。\nCoffee Lake CPU\n9th Gen UHD-630 IGPU = 0x3E980003 (MacOS 10.14.4+で使用)\n8th Gen UHD-630 IGPU = 0x3E920003 or 0x3E910003 (MacOS 10.13.6 〜 10.14.Xで使用) Kaby Lake CPU\nHD-630 IGPU = 0x59120003 (MacOS 10.13.Xで使用)\nUnknown = 0x59180002 (推奨しません) SkyLake CPU\nHD-510 IGPU = 0x19020001\nGT2f IGPU = 0x19170001\nHD-530 IGPU = 0x19120001\nIris Pro 580 = 0x19320001 Haswell CPU\nHD-4600 IGPU = 0x0412000B or 0x04120004 Ivy Bridge CPU\nHD-4000 IGPU = 0x01620006 or 0x01620007 Sandy Bridge CPU\nHD-3000 IGPU = 0x00030030 **注意：**モバイル用CPUであるCannon-Lake と Ice-Lake CPUにはヘッドレスPlatform IDはありません。\nHackintoolを使って、Connectors機能を選択することで、選択したPlatform IDがヘッドレスであるかどうかを確認できます。全てのエントリーは次の値を持っている場合、ヘッドレスです。\nindex = -1 bus id = 0x00 pipe = 0 type = dummy これに加えてHeadlessアイコンが表示されます。HaswellのヘッドレスPlatform IDである0x0412000Bの例を示します。\n注意-1: ヘッドレスiGPUモードはデスクトップ機のデュアルGPU構成 (dGPU + iGPUの構成)でのみ良好に動きます。両方のGPUの出力が同じディスプレイに接続されるラップトップ機のデュアルGPU構成では動きません。このような構成では、RehabManさんのガイドのようにdGPUを常に無効にしないとmacOSが動かないからです。\n注意-2: 既に述べたように、ヘッドレスPlatform IDの使用は、推奨された機種のSMBIOSでのみ機能します。それ以外のシステムを設定すると不安定になります。\n注意-3: ヘッドレスPlatform IDを使う場合、iGPUは、BIOSで有効に設定してあっても、システム情報 -\u0026gt; ハードウェア -\u0026gt; グラフィックス/ディスプレイ には現れません。これは正常です。これによりヘッドレスiGPUモードが機能していることを確認できます。\n注意-4: Hackintoshに1個または複数のThunderbolt 3ポートが実装されていて、これをdGPU + ヘッドレスiGPUの表示に使いたい場合は、BIOSで”Above 4G Decoding”オプションを有効にする必要があります。\n注意-5: iGPUをヘッドレスに設定した後、IORegistryExplorerを使ってIOREGを調べることで、全てが正しく設定できたことを確認できます。”IGPU”で検索して、iGPUエントリーのAAPL, ig-platform-idプロパティが、ヘッドレスPlatform IDに設定されていて（バイト順が逆になっています）、適合したモデル設定になっていることを確認します。\nWEGの手動設定 HackintoolのPatchモードの他のサブ機能のボタンをクリックすると、現在選択されたフレームバッファー設定と変更をチェックできます。大抵の場合、ここでは何も変更する必要はないです。詳しくは WEG guideのpost #2を見てください。全てokでしたらPatchサブ機能ボタンを押します。\niGPUなりすまし もしiGPUに合致しないPlatform IDを使用しているなら、iGPUのdevice IDを他の値に偽装しなければなりません。\n例えば、UHD 620 iGPUを使用する場合、これに対応するPlatform IDはありません。もっとも近いPlatform IDはUHD 630 iGPUです。それでUHD 630のPlatform IDを選ぶことになり、iGPUをUHD 630に偽装する必要があります。\niGPUのなりすましを行うためには、Advancedページを使います。（訳注：上のアイコンでPatchを選び、下のボタンでPatchを選んだ後に上部に現れるAdvancedタブです。）ここでSpoof Video Deviceにチェックを入れ、ターゲットのiGPUデバイスIDを隣にあるドロップダウンメニューから選びます。下のスクリーンショットでは、UHD 620 iGPUをUHD 630になりすましさせています。\niGPUパッチ生成 次に、Generalのサブページをクリックして、Devices/Propertiesラジオボタンを選択して、Graphic Deviceチェックボックスを選択し、それ以外のチェックボックスはとりあえず非選択にします。そしてGenerate Patchボタンをクリックします。大抵の場合、AAPL,ig-platform-id (またはSandy Bridgeの場合はAAPL,snb-platform-id)がDevice Propertyとして設定されれば、WEGはiGPUを正しく設定できます。追加のプロパティーは、オプショナルですが、iGPUを正しく特定するために役立ちます。以下では、HackintoolをIntel HD 620 iGPUを搭載し、Platform IDが0x59160000である2017年版HP Spectre X360ラップトップで動かした例を示します。\nこのパッチコードを、plistの正しい構造を維持しつつ、config.plistにコピーペーストします。とのブロックの部分を選択してコピーします。\n次に、これをconfig.plistのDevices -\u0026gt; Propertiesセクションにペーストします。上の例の場合、このような感じになります。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;\u0026lt;----- ここの後にHackintoolのパッチをペーストする \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAAWWQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;AAPL,slot-name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Internal\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; FlkAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;device_type\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;VGA compatible controller\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;model\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;HD Graphics 620\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; 注意: Sandy BridgeではDevice Propertyの名前はAAPL,snb-platform-idになります。 (AAPL,ig-platform-idではありません)\n暗黒画面とコネクター不全 ほとんどの場合Hackintoolが生成するデバイスプロパティはWEGが正しくiGPUを構成するのに十分な情報量です。 しかし、いくつかのシステムではさらにフレームバッファデフォルト値を変更する必要があります。例えば、iGPUのポートをDVIからDPに変更したい場合や、DPからHDMIに変更したい場合です。この場合、Hackintoolを使ってさらなる設定を行い、新たなパッチを作成して、config.plistのDevice Propertiesに追加します。これに関してはCaseySJさんの素晴らしいガイドがあるので、以下を見てください。\n高DPI表示とデュアルモニター 高DPIディスプレイを使う場合、または私の場合のようにラップトップに外部ディスプレイを接続する場合、macOSの起動オプションに -cdfon を追加します。これにより、WEGのピクセルクロックパッチを有効にします。これにより高DPI表示に必要な解像度とリフレッシュレートを可能にします。この機能は、以前はCoreDisplayFixUpプラグインが担っていましたが、今はWEGに統合されました。\nこの場合iGPUのVRAMをデフォルト値の1536MBから2048MBに増加しておくことをお勧めします。これにより2面の1080P表示が可能になります。これには、config.plistのDevice Propertiesセクションに以下を追加します。\n\u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-unifiedmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAAAgA== \u0026lt;/data\u0026gt; 注意: VRAMを2048MBに増やす設定は1080Pディスプレイ1個のシステムや、ヘッドレスPlatform IDのシステムでは何の効果もありません。\n変更をテストする 必要な変更をconfig.plistに書き込んで再起動します。うまく起動したらHackintoolで状況を把握して、加速機構などが機能していることを確認します。\nまた、WEGがHECIデバイスを正しくIMEI (Intel Management Engine Interface)に改名できているかどうか確認することをお勧めします。これにはターミナルで以下のコマンドをタイプします。\nioreg | grep IMEI IMEIに改名するパッチが効いている場合、以下のように表示されるはずです。\n| | +-o IMEI@16 \u0026lt;class IOPCIDevice, id 0x100000264, registered, matched, active, busy 0 (36 ms), retain 11\u0026gt; もしWEGによる改名が確認できない場合は、従来のCloverのHECI -\u0026gt; IMEI改名パッチを使ってください。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change HECI to IMEI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SEVDSQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SU1FSQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; DRM問題 DRM (Digital Rights Management, デジタル著作権保護）されたコンテンツが再生できないことがあります。解決は困難です。特にKaby Lake以降のiGPUだけを使ったシステムでMojave以降を使用する場合、現状では対応不可能です。\nWEGはDRMに対応していたShikiの機能を引き継いでいます。もし、iTunes、ウェブブラウザでのNetFlix再生などができない場合は、起動オプションでshikigva=1などして、試してください。shikigvaの番号には以下の機能があります。\n001 = Force Hardware Online Renderer 002 = Allow Non BGRA 004 = Force Compatible Online Renderer 008 = Add Executable Whitelist 016 = Disabled Unused 032 = Replace Board ID 064 = Unlock FP10 Streaming もしshikigva=1 (001 = Force Hardware Online Renderer)でも表示されなければ、shikigva=57 (001 + 008 + 016 + 032) を試してください。これはmacOSに別のBoard IDを使わせることになり、DRM問題を解決することもあります。\nshikigvaの001オプションを使うと、macOSはもっとも適切なハードウェアレンダラーを使うようになります。でもこの自動設定を変更してDRM再生GPUを指定したい場合は、以下のどれかのコマンドを使います。\nIntel iGPUを使うように指定する\ndefaults write com.apple.AppleGVA forceIntel -boolean yes AMD/ATI dGPUを使うように指定する\ndefaults write com.apple.AppleGVA forceATI -boolean yes Nvidia dGPUを使うように指定する\ndefaults write com.apple.AppleGVA forceNV -boolean yes 私の理解では、AMD GPUは多くの場合、良好に動作します。一方でNvidia GPUとIntel IGPUは世代によって良かったり悪かったりします。\nもしshikigva=1でもshikigva=57でもDRM再生ができない場合は、shikigva=60 (004 + 008 + 016 + 032) を試してみてください。これは、代替Board IDを使い、さらに別の互換性のある、GPUハードウェアを使用しないDRMレンダラー手法を使う設定です。もしどれも（1, 57, 60のいずれも）だめなようでしたら、他に問題があると思われます。他の値を試してみてください。\nちなみにmacOSのDRM設定を元のデフォルト設定に戻すには、以下のコマンドを一つずつ使います。\ndefaults delete com.apple.coremedia defaults delete com.apple.AppleGVA sudo rm -rf /Users/Shared/SC\\ Info sudo defaults delete com.apple.coremedia sudo defaults delete com.apple.AppleGVA DRM問題はいまだに上手くいくこともあれば動かないこともある問題です。おそらくはハードウェアの特定の組み合わせ (Chipset + CPU + GPU) とSMBIOS設定に関係していると思われます。純正のMacであっても、Appleフォーラムで動かないという問題が指摘されています。主にIvy BridgeとHaswellで問題が多いようです。Appleのドライバーそのものが原因かもしれません。\nDRM再生はCoffee Lakeシステム (第8世代と第9世代)において特に困難なようです。私はCoffee Lakeを持っていないのですが、@Jaco1960さんによる第8世代を使った報告によると、DRMを動かすたった一つの方法は、iMacPro1,1に設定することだそうです。その結果は以下のようです。（訳注：どの方法を使ってもSideCarが動かなくなるということかな。これは手を出しにくいですね。）\n@pastrychefさんも、Coffee Lakeで動かすためには、iMacPro1,1の設定が必要と報告しています。現在は、DRMを100%動かせる方法はありません。\n","date":"2019-11-23T23:49:44+09:00","image":"/uploads/2018/08/20170915223211-e1556936489370.png","permalink":"/posts/7116/","title":"Liluとプラグイン：(1) WhateverGreenの使い方"},{"content":"Radeon Rx 580, Vega 64, RX 5700 XTの性能をGeekbench 5で比較しました。いずれもmacOSで動きますが、上位モデル・最新モデルの性能を引き出せていないようです。macOSしか使わないのであれば価格・電力性能比の良いRX 580が良いです。\n巷のRadeon評価 AMDのRadeonシリーズGPUとmacOSの互換性は高く、現行製品のほとんどがmacOSで使えます。でもWindowsで動かすほどの性能を引き出せていないという意見をよく目にします。実際のところはどうなのかを、Radeon現行製品それぞれのアーキテクチャ製品を比較して調べました。現行製品のアーキテクチャと代表的な上位モデルを列挙すると次の表になります。製品は左カラムから右へ、発売日順に並んでいます。\n580 Vega 64 VII 5700 XT 構造 Polaris Vega10 Vega20 Navi(RDNA) 線幅 14nm 14nm 7nm 7nm CU数 36 64 60 40 SU数 2,304 4,096 3,840 2,560 ROP数 32 64 64 64 クロック数 1,257MHz 1,274MHz 1,400MHz 1,605MHz メモリ GDDR5 HBM2 HBM2 GDDR6 消費電力 185W 295W 300W 225W 4K性能 31.2fps 47.5fps 57.0fps 56.0fps 価格 ここで4K性能と書いた部分は、gpucheck.comでの結果です。演算性能よりはCG性能を重視した評価指標かと思われます。詳細な比較結果は以下をご覧ください。\nこの表の製品のうち、580とVega 64は去年（2018年）の製品です。なので発売当初の半額から1/3程度の値段で買えます。VIIと5700 XTは、今年（2019年）発売の製品なので、まだ価格は高いです。プロセッサー数などの仕様と発売当初価格から分かるように、Vegaアーキテクチャの2製品は、Radeonシリーズの最上位モデルです。それに対して、5700 XTは580/590に相当する中位モデルです。でも本年モデルのVIIと5700 XTを比較すると、5700 XTのコストパフォーマンスと、電力パフォーマンスがとても良いことがわかります。5700 XTはAMDのGPUとしては久々の優れたモデルとして人気があるようです。ただこれはWindows環境での話です。macOSではどれも動作はしますが、ドライバの作りが完璧でないためか、Windows環境と同じような性能は得られていないようです。\nGeekbenchで測定 macOS環境では、それぞれどのような性能なのでしょうか。VIIは用意できなかったので、それ以外の3機種、RX 580, Vega 64, 5700 XTをGeekbench 5で調べました。RX 580がオリジナルファン版、他はリファレンス版です。\nSAPPHIRE NITRO+ RADEON RX 580 MSIブランドのリファレンスファンRadeon RX Vega 64 ASUSブランドのリファレンスファン Radeon RX 5700 XT 今回はRX 580としてNITRO+を使いましたが、PULSEの方が安いですし、Apple純正のeGPUで採用されてますので何かと安心かと思います。一時期販売終了していましたが、最近は安定供給されているようです。\nGeekbench 5のGPUベンチマークには、OpenCLとMetalの選択があります。それぞれを交互に5回測定しました。5回測定したものの、最初の1〜2回に良いスコアが出て、それ以降はだんだん低下していくようでした。おそらくはベンチマーク実行のためにGPUが発熱し、速度が抑えられるのでは無いかと思います。\n特に、Vega 64は発熱が激しく、基板バックパネルの温度で52度以上になってました。触れない熱さです。GPU本体はもっと高温になっていると思います。それだけ電力を消費しているということですね。その一方で、580と5700 XTのバックパネルはほんのり温かくなる程度です。\nちなみにここで使った温度計は、AliExpressで送料込み800円くらいで売っている非接触赤外線温度計です。レーザ光線も出てカッコ良いです。\nということで、以下の比較では、5回測定したうちの最高スコア（大体は1回目のスコアでした）を採用しました。\n測定結果 ベンチマークの結果を下に示します。上の表から、gpucheck.comの値も書いておきました。これはWindows環境のベンチマークなので、項目名の頭に(W)と書いておきます。今回測定したOpenCLとMetalのベンチマークはmacOS環境なので、項目の頭に(M)と書いておきます。\n580 Vega 64 VII 5700 XT (W) 4K性能 31.2fps 47.5fps 57.0fps 56.0fps (M) OpenCL 47807 61330 51988 (M) Metal 49600 60577 41266 RX 580, Vega 64, RX 5700 XTのOpenCL/MetalのGeekbenchスコアをグラフにすると以下のようになります。\nこうしてみると、Windows世界の評価に対して、かなり異なる結果になりました。まず、Vega 64は確かに高速です。でもWindows環境だとRX 580の1.5倍くらい速いことになっていますが、こちらの結果では1.3倍くらいです。また、Windows環境ではVega 64よりも高速な5700 XTに至っては、RX 580と比較して、OpenCLで10%くらい高いスコアを出している程度で、Metalでは負けています。\n手元の環境だけの異常なスコアなのかとも思いましたが、Geekbenchのサイトで検索しても似たような結果でした。下は、Geekbench 5のcompute resultsで、RX 5700 XT macOSで検索した結果です。\nMetalのスコアは大体、30000後半から40000台でした。上記のスコアは一般的な結果のようです。\nまとめ 5700 XTは残念なスコアでした。RX 580とVega 64に近いGPUは、Mac製品に搭載されています。しかし5700 XT、もしくはそれに近いGPUは採用されていませんでした。そのため、macOSのドライバーが5700 XTのアーキテクチャに十分に対応していないのかもしれません。\nでも、つい最近に出た16インチMacBook ProではNaviアーキテクチャGPU (Radeon Pro 5300M, 5500M) が搭載されています。10.15.1で5700シリーズが動いたのもこのおかげかと思います。ちなみにProと名前がつくモデルはアップル専用モバイルチップです。強そうな名前ですが、実は計算ユニット数やクロック数を多少減らして発熱を抑えたチップです。Appleの公式サイトによると、前モデルのRadeon Pro 560Xに比べてRadeon Pro 5500Mは2.1倍速いそうです。Radeon Pro Vega 20と比較しても35%速いそうです。新MacBook Pro対応のmacOS （多分10.15.2）になれば、ドライバが改良されて性能改善されるのではと期待しています。\n","date":"2019-11-15T19:55:55+09:00","image":"/uploads/2019/11/geekbenchicon.png","permalink":"/posts/7030/","title":"Radeon RX580/Vega 64/5700XTの性能を比較"},{"content":"macOS Catalina 10.15.1からAMD Radeon RX5700シリーズがサポートされました。それでRX 5700 XTを使ってみたところ動きました。最新のWhateverGreen.kextが必要です。でも現状のmacOSでは性能を活かし切れていないようです。\n話題のRX 5700/5700XT AMDのグラフィックスカードRadeon RX 5700シリーズは、7nmプロセスで製造され、新設計のNaviアーキテクチャを採用しています。プロセッサ数はRadeon RX Vega 64より少ないですが、下表のようにVega 64より性能が良いとのことです。その上、消費電力は少なく、安価な設定です。ただ、Vega 64は発売時に比べたら暴落しているので、実売価格は逆転しています。\n5700 XT 5700 Vega 64 580 構造 Navi(RDNA) Navi(RDNA) Vega Polaris 線幅 7nm 7nm 14nm 14nm CU数 40 36 64 36 SU数 2,560 2,304 4,096 2,304 ROP数 64 64 64 32 クロック数 1,605MHz 1,454MHz 1,274MHz 1,257MHz メモリ GDDR6 GDDR6 HBM2 GDDR5 消費電力 225W 185W 295W 185W 4K性能 56.0fps 51.3fps 47.5fps 31.2fps 価格 (「4K性能」はgpucheck.comの比較結果です。)\n5700シリーズは優れた製品なので、Radeon派のWindowsユーザからは、久々にAMDが良い製品を出してくれたと、高い評価を受けています。この人気GPUが、macOS Catalina 10.15.1から正式にサポートされました。Sonnet社の互換GPUリストにも早速登場しています。\nSonnetの互換GPUリスト (10.15.1以降)\nそこで、リファレンスファンモデルのRX 5700 XTをmacOSで動かしてみました。GPU用水冷ブロックは、ほぼリファレンスファンモデル用しか用意されないので、将来水冷することを考えるとリファレンスモデルが欲しいところです。しかも、オリジナルファンモデルのグラフィックスカードが出回ってくるとリファレンス版の流通は無くなってしまいます。実際、現在は入手困難です。\nでも、水冷のことを考えなければ、現在流通している空冷性能の良いオリジナルファン版が良いと思います。\nCatalinaで動かす macOS 10.15.1で正式サポートされたので、特に問題なく動きます。ただ、WhateverGreen.kextは最新版の1.3.4を使う必要があります。また、Cloverの起動オプションに\nagdpmod=pikera を追加する必要がありました。環境によってはこのオプションが無くても動くこともあるようです。ちなみにこのオプションは、WhateverGreen.kextのもので、解説によると、\nAppleGraphicsDisplayPolicy.kextは、その中のInfo.plistをチェックして特定のboard-idに対してどのモードを使うか決定します。どのモードが良いかはGPUに依存し、試してみるしかありません。WhateverGreenはいく通りかの方法で電力管理モードを設定します： system board-idのConfigMap dictにnoneを書き込むパッチ (agdpmod=cfgmap) 文字比較を無効にするパッチ (agdpmod=vit9696, デフォルトで有効です) board-idをboard-ixで置き換えるパッチ (agdpmod=pikera) と書いてあります。Catalinaではこのkextは見つからないので、おそらくは、\n/System/Library/Extensions/AppleGraphicsPowerManagement.kext/Contents/Info.plist に書かれているsystem board-idと関係するのだと思います。このInfo.plistには、それぞれのボードIDに対して、どのように電力管理するかが書かれている様子です。このInfo.plistを見ていると、いろいろ面白いです。今年発売と思われているMacPro7,1のIDと言われるMac-27AD2F918AE68F61の項目に、Radeonシリーズの機種IDが複数書き込まれています。このInfo.plistが示す内容が何なのか不明ですが、いずれにしても、WhateverGreenのこのオプションは、特定機種に対する設定を無効にするパッチ手段を選ぶオプションのようです。\n動作確認 agdpmod=pikeraを起動オプションに追加するだけで問題なく動いています。システム情報を見ると上のようでした。機種IDが0x731fです。これは先ほどのInfo.plistには書かれてません。（RX 580などは書かれています）サポートが今後改善されれば追加されるのかもしれないです。\nベンチマーク Geekbench 5を使ってベンチマークし、スコアをSapphire Pulse Radeon RX 580と比較します。まずはOpenCLとMetalのスコアを以下に示します。\nRX 5700 XT RX 580 OpenCL 45299 45106 Metal 39554 44843 OpenCLスコアは、僅差ですがRX580より多少良いスコアでした。しかし、Metalのスコアでは、なんと格安のRX 580に負けてしまいました。Windows環境ならばRX 5700 XTの方がずっと性能が高いはずです。上で紹介したgpucheck.comによると、5700 XTは580に比べて1.7倍くらい性能が上です。なので予想しなかった結果となりました。でもGeekbenchの結果が登録されるGeekbench Browserで検索してみたところ、macOS上のRX 5700 (XT)スコアは今回の結果と同程度のようでした。またネット上にも、macOSではあまり性能が出ない話を見かけます。今後のmacOSバージョンで改善されると期待したいです。\nまとめ Radeon RX 5700シリーズはmacOS 10.15.1以降で容易に動かすことができます。ただOpenCLベンチマークスコアではRX 580と差がなく、Metalでは負けてます。今後のmacOSバージョンアップで性能向上が期待できますが、現状ではRX 580/590で十分だと思いました。Windowsとデュアルブートする場合は、Windowsで性能が出せてmacOSでも使えるGPUとして価値があるかと思います。\n","date":"2019-11-09T00:06:25+09:00","image":"/uploads/2019/11/5700XT.png","permalink":"/posts/6735/","title":"Radeon RX 5700を使う"},{"content":"macOSで使えるGPU MacのThunderbolt 3コネクタに接続する外部GPUボックス\nを販売しているSonnet社が、macOS 10.15.1以降と互換性のあるグラフィックスカードの一覧を以下のPDFファイルで公開しています。\nhttps://www.sonnettech.com/support/downloads/manuals/Compatibility_Graphics_C\u0026hellip;\n各ブランドごとの多数のモデルを掲載しています。Sonnetの外部GPUボックスは、AppleのExternal Graphics Development Kitにも採用されているほぼ純正みたいな存在です。なので、このリストで互換性があるとされたグラフィックスカードは、Hackintoshで、そのまま動くカードと考えて良いです。市場に出回っている多数の製品に対して互換性がチェックされているようですので、Hackintosh用グラフィックスカード購入の際は、これで確認しておきましょう。 これを見ると、例えば、AMDリファレンス（ファンデーション）バージョンでは、以下のMがマークされた機種がmacOSと互換のようです。\n主に、GPUチップによってのみ互換・非互換が決定するようです。まとめると以下のようになります。ただ、一部のブランドでは互換性が無いとされているモデルもあります。互換性確認ができていないだけなのか、何らかの問題があるのかは不明ですが、そのようなモデルは避けた方が良いと思います。\nRX 470, RX 480, RX 570, RX 580は互換性あり RX 560, RX 590は10.14.6から互換性あり RX 460, RX 550は互換性なし RX Vega 56/64は互換性あり Radeon VIIは10.14.6から動くがスリープ・シャットダウンでファンが全開になる RX 5500は非互換で、RX 5700, RX 5700 XTは互換性あり R9 NANO/FURY は互換性なし WX 5100は非互換で、WX 7100, WX8200, WX 9100は10.15.1から互換性あり NVIDIA GeForce は互換性なし また、Mac mini 2018では以下の制約があるそうです。\n10.15.1ならば、Vega 56, Vega 64, WX8200, WX9100, Radeon 5700, Radeon 5700XTはGPUカードにモニターを接続してブートできるものの、 RX 560/570/580/590の場合はiGPUのHDMI端子にのみブート表示が出る。 以前の情報 古いmacOSに関する記述についてはこちらもご覧ください。\nSonnetの互換GPUリスト (10.13.4以降)\nSonnetの互換GPUリスト (10.13.2以降)\n","date":"2019-11-04T11:21:15+09:00","image":"/uploads/2018/04/20180416222802.png","permalink":"/posts/6973/","title":"Sonnetの互換GPUリスト (10.15.1以降)"},{"content":"Catalinaから始まったApple Arcadeを使ってみました。一月600円でゲームが楽しめるサブスクリプションサービスです。Hackintoshでも問題なくプレイできました。\nApple Arcadeの良いところ 昔のゲーム機のように、ゲームが買取式だった頃は、買ってみたらつまらなかったという状況に陥りがちでした。一方で現代のスマホゲームで一般的な、のめり込んだ人から課金する方式では、高額課金を恐れて熱くなれない側面もあります。どんなゲームも定額で試せて、自分が楽しめるゲームを探せるサブスクリプション方式は、良いアイディアだと思います。またApple Arcadeの月額600円という料金はお得なのではないかと思います。\nCatalinaで一番期待していたのがApple Arcadeです。macOSを愛する立場からしたら、iOSと同じゲームがmacOSで動作する点が最高に素晴らしいです。追加料金も不要です。また、iOSマシンとmacOSマシン間で、ゲーム進捗状況がある程度同期されるようです。Windowsをインストールしてゲームをするのが自作PCの一つの使い道でしたが、Apple Arcadeの登場で、ゲームのためにmacOSを使うことのメリットがようやく生まれたと思います。\n利用してみた ゲームはヘタレなのでちゃんとしたレビューはできません。超大作という感じのタイトルはあまり無いような気がします。でもAppleが管理しているだけあってどれも完成度は高く、お洒落な画面と効果音の作品が多いです。Mini MortorwaysというSim Cityみたいな街づくりゲームが面白かったです。家と勤務先が現れるので、その間を道路でつないで、通勤自動車を円滑に流すのが目的です。短いターンで終わってしまうので、空き時間で気軽に楽しめました。\n‎Mini Motorways\n調べてみると同じ会社からMini Metoroというタイトルで、地下鉄路線を設計する同様なゲームがSteamで発売されています。980円です。macOS版のSteamでも動くようです。Mini Mortorwaysはその会社の新作のようです。Steamから出ていたら、同程度の値付けになっていたと思われます。単体で買うなら買取980円の方が得かもしれませんが、この手のゲームを継続していくつか試したい場合にはApple Arcadeの方がお得な気がします。今までmacOS用ゲームプラットフォームとしてはSteamが頑張っていました。でも、Windows, Linux, macOSで展開できるSteamと、iOSとmacOSで展開できるApple Arcadeを比較すると、後者も負けていないと思います。Appleのことなので、一つコードを書けば、iOSとmacOSの両方で動く仕掛けを用意しているはずです。なので今後は開発者が、macOS版SteamからApple Arcadeに移行していくかもしれないです。今後の品揃えに期待したいです。\nHackintoshで動かす Appleのサーバで提供されるサービスですので、App StoreやiCloudなどと同じように注意してHackintoshを設定する必要があると思います。ただ、iMessageでの設定ほど厳格ではないような気がします。いずれにしても、iMessageが動く程度のしっかりした設定を行なった方が良いと思います。こちらをご覧ください。\niMessageを動かす\nEULAに反してOSを使わせていただいているので、エコシステムの養分になってお礼をしていきたいと思います。macOSユーザが増えることでエコシステムが栄えることになれば、今後も黙認し続けてくれるかもしれないです。\nまとめ Apple ArcadeはHackintoshで問題なく動きます。画面の動きも、実機と同様です。iOSのアプリがmacOSで動くのは面白い体験です。でもiOSとmacOSはほとんど同じものですので、親和性が高いのは当然です。Windows 8でモバイルとの統合を強行して失敗したMicrosoftと違って、Appleは順当に統合を進めているようです。次はiOSアプリがmacOSで動くようになるかもしれないです。\n","date":"2019-11-03T16:20:24+09:00","image":"/uploads/2019/10/arcadeslpash.png","permalink":"/posts/6848/","title":"HackintoshでApple Arcadeする"},{"content":"Catalinaで導入されたSidecar機能が無線接続で使えました。使用したWiFi/BluetoothモジュールはBCM94360CDとFenvi T919です。どちらも最初は有線でのみ動作してましたが、うやむやのうちに無線でも動くようになりました。\nSidecar動作のための条件 Sidecarを使うと、iPadがmacOSマシンのセカンドディスプレイになります。ミラーリングもできます。またiPad側のApple Pencil操作で、macOS画面を操作できます。でもSidecarを動かすためには、いくつかの条件が必要なようです。必要そうな条件を以下にあげました。Hackintoshでは、この条件は間違っているかもしれませんし、今後のアップル社の対応で変わってくるかもしれません。\nApple IDと無線 実機のMacでは、macOSマシンとiPadが\n同じApple IDでログインしていること、 同じWiFiに接続していること（有線LANでは駄目です）、 Bluetoothの到達範囲にあること、 がSidecarを使う条件だと言われています。もちろんHackintoshでも必要条件です。USBケーブルでSidecarする場合には、無線条件が満たされていなくても大丈夫のようです。\niGPUの条件 試したところでは、BIOSレベルでiGPUが機能していることが必要のようでした。macOSからiGPUが認識されている必要はないようです。なのでグラフィックスカードを使用しているマシンでも問題ありません。BIOSからiGPUを無効にしていると、Sidecarで接続はしても画面が暗いままです。おそらくは、iGPUの画像圧縮機能を使って、画面を転送しているので、それがないと表示されないのだと思われます。後述するようにBIOS設定でiGPUがマルチモニターで動くように設定します。\n追記：コメントでは、iGPUの無いXシリーズCPUでも動いたという情報をいただきました。\nT2チップ搭載の機種IDは使えない コメントでいただきましたが、tonymacx86の情報によると、T2チップ搭載機種IDを使ったHackintoshではSidecarは動かないらしいです。T2チップ搭載モデルでは、Sidecarの認証または画面圧縮にT2チップを使っているのだと思われます。なので、以下のページで示された機種IDを使用している場合は、Sidecarは使えません。\nApple T2 セキュリティチップ搭載モデルの Mac\nBCM94360CDで動かす 最初は、Z390+9900Kを搭載したマシンでSidecarを試した経緯を書いておきます。このマシンのパーツ構成、ESP構成、config.plistなどは、下のリンクを見てください。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\n使用しているWiFi/Bluetoothモジュールは、純正のMacで使用されているBCM94360CDです。以下の製品です。これをPCIeカードに挿して使用しています。\nHackintoshでSidecarを動かす前に、同じiPad/Apple PencilとMacBookで動作確認しました。この場合は、Sidecarが問題なく動きました。次に、このHackintoshで試したところ、画面は出たのですが、有線接続でしか動きませんでした。iPadをUSB接続しない状態では、システム環境設定・Sidecarの「接続先」に「デバイスなし」と表示されてしまい、iPadが現れません。\n有線で接続すると、接続先が選べるようになり、iPadが選択できます。MacBookでは無線でも問題なく接続できるので、Hackintoshなりの調整が色々必要なのだと思って、しばらく放置していました。ところが、何かの拍子で繋がるようになりました。実際に何をしたのかというと\nZ390マシンとiPadを有線接続でSidecarしました。 Apple Pencil をペアリングするためにiPadから線を外してPencilを挿しました。 この時「接続が切断されるよ」というような内容のダイアログがiPadに出ました。 ペアリングが終わってPencilを外したらなぜか無線でSidecar接続しました。 これで無線でもiPadが選択できるようになりました。iPadがセカンドディスプレイになりますし、またPencilを使って画面操作もできます。Hackintoshであっても、Sidecarの本来の機能は全て利用できていると思います。\nこれ以前に、有線でSidecar接続中にUSBケーブルを外すことは試みていました。でも接続が切れるだけで、無線では接続できませんでした。今回なぜ可能になったのかわかりません。\n今回行ったPencilペアリング操作は、無線接続できたことは多分無関係です。SidecarはApple IDを介して動作していると説明されています。それぞれのマシンが同じApple IDで動作していることがSidecarを使うための条件です。なので対になるマシンの認定をアップル社のサーバーが行なっているはずです。今回、無線接続できた理由は、何らかのきっかけ、時間経過、またはアップル社の方針変更によって、Sidecar動作条件が満たされたからだと思います。有線接続の場合は、直接接続されていることが確実なので、ペアリング認定条件が緩かったのでしょう。このようなmacOS機能は、iMessageやFaceTimeと同じく、動作するかどうかはアップルのサーバー次第です。条件はいつでも変化するし、真相は謎のままです。\nFenvi T919で動かす 次に、Fenvi T919でも試しました。以下で紹介した無線PCIeカードです。中身は、おそらくBCM94360CDと同一と思われているので、問題なく動くはずです。\nWiFi/BluetoothアダプタFenvi FV-T919\n使用したマシンは、以下で紹介したMSI B360M MORTAR TITANIUMに9600Kを搭載したHackintoshです。\nMSI B360M MORTAR TITANIUM, 9600K\nこちらも最初は接続できませんでした。Sidecarの接続先がグレーになっていて、iPadが選択できませんでした。しかし、Z390マシンでSidecarが可能になった後で、こちらもどう言うわけか、iPad選択できるようになっていました。Sidecarのペアリングを管理するサーバの設定が変わったのかもしれません。しかしZ390マシンの場合とは違って、iPadをSidecar接続しても、iPad画面が真っ暗でした。画面をミラーリングにしてApple PencilでiPadを操作すると、macOS画面のポインターは動きます。なので、遠隔ポインティングは効いているけど、表示が出ていないことがわかります。\nSidecarのビデオ転送にはiGPUの機能が使われているらしいと言う話を聞いたことがありましたので、iGPUをチェックすることにしました。BIOSで設定を見るとIGD Multi-Monitorの設定がDisabledになっていました。iGPUにもモニターを接続して、マルチモニターにするかどうかの設定だと思います。Disabledの場合は、iGPUの機能を無効にしていると思われます。そこで、これをEnabledにしました。メモリの設定はデフォルトの64MBにしました。この結果、無事にiPadに画面表示されるようになりました。\nまとめ HackintoshでもSidecarが動きました。USB有線接続なら問題なく接続できました。無線経由では、最初は接続できませんでしたが、よくわからないうちに無線接続できるようになっていました。また接続を実現するためには、通常のMac/iPadの条件に加えて、iGPUが動いている必要があるようです。とはいえiGPUを搭載していないiMac ProでもSidecarは可能なようなので、機種IDにも依存しているのかもしれません。\n今回、Apple Pencilを初めて使ってみました。使い勝手や速度はちゃんとしてました。でもiPadに差し込むという初代Apple Pencilの充電方式は、緊急時には良いけど、普通に充電したい場面では使いにくいです。そのうちにこんなアクセサリを揃えてみたいと思ってます。\n","date":"2019-10-27T00:45:55+09:00","image":"/uploads/2019/10/Sidecar.png","permalink":"/posts/6851/","title":"HackintoshでSidecarを使う"},{"content":"\nAliExpressから格安の小型ベアボーンPCを調達しました。XCY社のX36という型番です。価格は送料無料の$183.17でした。到着したので開封・分解して中身を確認しました。\nXCYのベアボーンX36 中国のショッピングサイトで格安の小型PCがいくつも販売されています。こちらの記事では、Macと同じCPUを搭載した製品をいくつかピックアップしました。\n中国の小型ベアボーンPC\nこの中で一番気になったのは、5250U搭載のXCY社のX36です。ユニークな円盤ケースのPCです。円盤形なので360度にちなんでこの型番なのでしょう。ベアボーンなら$183と格安です。そこそこ格好の良い外観なのですが、癖のある使いづらい形状なので、値段が安いのではないかと思います。同じCPUを搭載していても、一般的な四角いケースの製品だともっと高価です。コストが掛かっているのにやってしまった感のある円形Macと同じ雰囲気がして、気に入りました。ちなみに、このPCの直径は15.5cmで、現行の円筒型Mac Proの直径は16.7cmです。同じくらいの大きさです。もし円筒型Mac Proが大成功していたら、こんな大きさの円盤型Mac miniが発売されていたかもしれないですね。\n搭載CPUのBroadwell Core i5-5250Uは、MacBookAir7,1, 7,2, iMac16,1, 16,2で採用されています。ノート型とデスクトップ型の両方で採用されるくらいApple社に気に入られたCPUなので、macOSとの互換性に期待できます。小型ベアボーンPC本家のIntel NUCにも5250U採用モデルがあります。Intel NUC 5i5シリーズです。ただそのほとんどの無線モジュールが半田付けタイプで、macOS互換製品に交換不可能です。汎用性の高い5250U搭載ベアボーンが格安で買えるなら試してみたいと思いました。\n開封する 発注から2週間ほどしたら、しっかりした梱包で香港から届きました。本体の他に、ACアダプター、電源ケーブル、SATA信号ケーブル、SATA電源ケーブル、mSATA/mPCIeカード取り付けネジが付属しています。\n本体はずっしり重くて、しっかりとした作りの印象があります。ファンレスで、肉厚なアルミ製ケース自体がヒートシンクになっています。\nマザーボード裏側 外から見えるネジがあるのは底板だけです。底板は、他より薄いアルミ板です。ここには、滑り止めの足と、VESA取り付け用の穴、そして4本のネジがあります。この4本のネジを外すと底板が外れます。\n底板を開けると、マザーボードの裏面が見えます。ケースが丸いので、マザーボードも丸いです。丸くするために、手間やコストがかかっていそうです。裏面にあるITEと書かれた大きなチップは、レガシー入出力やファンコントローラなどのようです。\nLANコネクタの裏側にあたる部分に、蟹マークのチップが見えます。刻印を見るとRealtekのRTL8111です。なので有線LANを使うためには、RealtekRTL8111.kextを使えば良いはずです。\nマザーボード表側 この状態で、マザーボードとケース上面の天板が外れそうな感じですが、ケース側面の穴と、USBコネクタ・ビデオコネクタ類が干渉して、外すことはできません。この先分解するには、マザーボード裏面に見えるスペーサーをマイナスドライバーか六角ボックスレンチで外します。するとケース天板が外れます。\nケース上面天板が外れると、マザーボード上面が見えます。天板は、ヒートシンクになっていて、グリースでCPUと接触しています。天板には、電源スイッチと電源LEDが付いているので、それに接続するケーブルが4本あります。このケーブルは、マザーボード表の4×2のヘッダピンに接続しています。ヘッダピンの残りの4本は、リセット、ドライブアクセスLEDかもしれません。この隣にある、5×2ピンのヘッダピンは、基盤のマークによるとUSBらしいです。\nマザーボード上面には、CPU, メモリーソケット (1個のみ)、mini PCIe (mPCIe) ソケット（無線モジュール用）、SATAコネクター、mini SATAソケット (mSATA, SSD用) などが見えます。CPUには鉛筆書きでi5 5250Uと書き込まれていました。中国サイトの小型PCでは、注文したCPU以外のCPUが搭載されている場合があるらしいです。その場合、上位モデルのCPUが入っているらしいですが、Mac搭載以外のCPUが届いても嬉しくありません。今回は、ちゃんと注文通りのCPUが搭載されているようで良かったです。メモリーソケットは1個だけです。この規格では、メモリーソケットあたり最大8GBまでらしいので、今時の搭載可能メモリー容量としてはちょっと心許ないです。\n下の写真の右側には、SATA信号コネクターがあります。そのすぐ上の白い2pinコネクタは、付属のSATA電源ケーブルのコネクタに合いますので、SATA電源用です。ここには5Vが出ていて、2.5インチドライブの電源供給ができるようです。ちょっと謎なのは、基板上にSATAコネクターがあって、ケーブルまで付属するのに、ケースには2.5インチドライブを入れるスペースが全く無いことです。外にケーブルを引っ張り出して使って欲しいということかもしれません。ともあれ、SATAコネクタがあることで、OSインストールの試行錯誤が楽になるのでありがたいです。\nSATA電源コネクタの隣のアイボリー色の4ピンコネクタは、基板のマークによるとCPUファン用らしいです。4ピンなので、PWM方式のファンが接続できるのだと思います。でもケースにはファンをつける場所も余裕もないのでこれも謎仕様です。もしかしたら、ヒートシンクになっているケース天板を、CPUファン付や、2.5インチドライブ内蔵可能なパーツに交換できるオプションが、かつては用意されていたのかもしれません。などと、不思議に思いましたが、ファンに関してはこの後、謎が解明します。\nマザーボード写真の右上部分のヘッダピンにはCOM1, COM2と書かれています。RS-232Cのシリアルポートらしいです。この手の小型PCは、制御用PCとしての需要があるためか、シリアルポートが搭載されている機種が多いです。でも、ケースが対応していないのですぐには使えませんし、もともとmacOSはシリアルポートをサポートしていないので使えません。\nこのマザーボードの1番の良いところは、無線モジュール用のmPCIeソケットが用意されていることです。Broadwell搭載のIntel NUCは、ほとんどの機種でインテル製の無線モジュールが半田付けされてます。なので、macOSと互換性のあるBroadcom製のモジュールに交換できません。さらに、無線モジュール用のソケット周りに余裕があることもありがたいです。Macに搭載されている純正のBroadcom無線モジュールを、mPCIeに変換するアダプタが売られていますが、これを介して純正モジュールを取り付けることができそうだからです。多くの小型PCでは、コンパクト化のために、無線モジュールの上にSSDを重ねる二重構造になっています。その場合、無線モジュールが2階建になる変換アダプタを使用できません。mPCIeソケット上方には余裕がありますが、近くには背の高い電源コネクタやHDMIコネクタがあります。標準的な無線モジュールより大型のアダプターを取り付けると、これらに干渉するかもしれません。\nマイクとスピーカージャックの近くには、また蟹マークのチップが見えます。この刻印を見ると、オーディオチップはRealtek ALC892でした。 AppleALC.kextとLilu.kextで対応できそうです。\n側面は取り外し可能 上の写真でわかるように、底板、天板の間には、リング状の側面カバーがあります。肉厚のアルミ枠で、高級感はあります。このアルミ枠を外して再組み立てすると、下の写真のように、底板と天板がマザーボードをスペーサーでサンドイッチした構造になります。側面の全周囲が無くなった状態になり、ケーブル類を引っ張り出すのが容易です。この状態で、無線アンテナやSATAケーブルを引っ張り出すと、動作試験が容易だと思いました。\n天板の構造 上の写真でわかるように、天板部分は2重構造になっています。この部分がどうなっているのか、AliExpressの写真を見た時からとても気になっていました。天板中央部分には、銀色のアルミの放熱ブロックが付いていて、これが基板中央のCPUに接しています。この構造は、最初の方の天板を外した写真でご覧ください。天板は、放熱フィンで覆われた中蓋と、電源スイッチ穴のある外蓋で構成されています。二つのパーツは、アルミ製スペーサーを介して、ねじ止めされています。この様子を下の写真に示します。\nこれを見ると、中蓋部分に薄型の冷却ファンが2個取り付け可能だったことがわかります。サイズは40mmです。取り付け部分からフィンの上端までは8mmあるので、1cm厚のファンくらいなら取り付けられそうです。でも現状では銀色の放熱ブロックがファン穴をほとんど塞いでいます。おそらくは、当初、2重構造の2枚の蓋の隙間に風を流す方式で、ファンを使った冷却を考えて設計されたのだと思います。その後、ファンレスを目指す方針に設計変更して、銀色の放熱ブロックが後から追加されたのでしょう。それでマザーボードにも、ファン用のコネクタがあるのだと考えられます。\n中蓋の上には、スペーサーを挟んで外蓋が被さるので、ファンの風の流れは、外蓋に当たってしまいます。でも、ファンの風は、外蓋に当たった後、中蓋のフィンに沿って円周方向に流れ出ることになるので、CPUの熱を取り込んだ中蓋を効率良く冷却できるように思います。なかなかよく考えられた構造だと思うのですが、そのファン穴が塞がれてしまっているのは残念です。黒いフィン付きの中蓋は、重量のあるアルミニウム製なので、熱容量はありそうです。なのでファンレス動作が可能と考えられたのかと思いますが、自然冷却だけで長時間の使用に対応できるのかは疑問です。もし熱くなるようなら、放熱ブロックを加工して、ファン穴を復活して、ファンを取り付けてみたいと思います。\nまとめ 円形の見た目がユニークなだけでなく、工夫のしがいがありそうな楽しいマシンだと思いました。試作段階では、SATAケーブルを引き出して、外部2.5インチSSDを用いて試験運転できそうです。純正無線モジュールを取り付け、アンテナも取り付けたいです。ファンレスですが、ファン付きにも加工可能な様子です。ケースに排気口がほとんど無い、いわゆる窒息ケースですが、40mmファンを2個つければそこそこ冷却性能の良いケースになりそうです。時間をかけてmacOSマシンに仕上げていきたいと思います。\nおまけ：XCYで検索してみました。同社製品の一部は日本Amazonでも買えるみたいです。\n","date":"2019-10-18T23:32:09+09:00","image":"/uploads/2019/10/packing.jpg","permalink":"/posts/6607/","title":"5250U搭載小型PC XCY X36 (1: 分解編)"},{"content":"Base64変換（文字列を変換） echo -n \u0026#34;AMD RX 580\u0026#34; | base64 QU1EIFJYIDU4MA== Base64変換（16進数を変換） echo -en \u0026#34;\\x9B\\x3e\\x00\\x00\u0026#34; | base64 mz4AAA== Base64逆変換（文字列をデコード） echo QU1EIFJYIDU4MA== | base64 -D AMD RX 580 Base64逆変換（16進数をデコード） echo mz4AAA== | base64 -D | hexdump 0000000 9b 3e 00 00 0000004 いつも使い方を忘れてしまうのでメモしておきます。Base64はバイナリーデータを文字で表記する場面でよく使用されます。config.plistでもお馴染みです。なので、時々、変換・逆変換したいことがあります。そのためのツールはたくさんありますし、変換してくれるwebページもあります。でも、ターミナルから使えるbase64コマンドならすぐに使えて便利です。使い方さえ忘れていなければ。\nBase64の仕組み 文字しか表記できない・通信できない環境で、任意のデータを効率良く表現するために考えられました。英大文字、英子文字、数字、記号(+と/) に数字を割り当てます。アルファベットは26文字なので、Aが0でZが25です。引き続き小文字のaに26を割り当ててzまで使うと51まで表現できます。この後、数字の0 (=52)から9 (=61)を割り当てると、61まで表現できます。後2つあればキリが良いので、+ (=62)と/ (=63)を最後に使います。これで、AZ, az, 0-9, +, /を使って0から63を表現できます。64進数です。ビット数は6ビットになります。\n通常のコンピュータのデータはバイト単位、8ビット単位です。なので上位から6ビットごとに区切って変換します。端数は0ということにします。例えば、ASCIIコードで大文字のAは、0x41です。ビットで表すと、0100 0001です。6ビットに分けると、010000 01です。端数に0を追加すると、010000 010000です。010000は10進数で16になり、これが2個続きます。16には、Base64では、17番目のアルファベットQが割り当てられています。なのでBase64で表すとQQになります。また、Base64では4文字の倍数になるよう調整します。足りない部分には＝を追加します。ということで、大文字AをBase64で表現すると、QQ==になります。\nbase64コマンド macOSにはターミナルから使えるbase64コマンドがあります。使い方は以下です。\nbase64 [-h | -D | -d] [-b count] [-i input_file] [-o output_file] I, oオプションで入出力ファイルを指定できますが、指定しなければ標準入出力が使用されます。hはヘルプ表示です。bで数値を指定すると、出力に改行を入れてくれます。Dオプションしか使うことはないと思います。オプションなしならエンコード、Dオプションでデコードです。\n標準入出力を使うので、echoコマンドをパイプします。echo helloとタイプするとhelloという文字が表示されるのですが、デフォルトでは最後に改行が入ります。-nオプションで改行を出さないよう指定できます。echoコマンドを、16進数標示するhexdumpコマンドにパイプしてみます。こんな感じです。0aが改行コードです。\n% echo hello | hexdump 0000000 68 65 6c 6c 6f 0a 0000006 % echo -n hello | hexdump 0000000 68 65 6c 6c 6f 0000005 なのでhelloという文字列だけ（改行は不要）をBase64にしたい場合は、\n% echo -n hello | base64 aGVsbG8= とします。結果が7文字だったので＝が1個追加されました。-Dオプションで元に戻してみましょう。\n% echo aGVsbG8= | base64 -D hello echoで16進数を出すのはちょっと面倒です。0x01, 0x02, 0x03という3バイトを出すには、”\\x01\\x02\\x03″と書きます。\\xで次の2文字が16進数だということを表現します。またこのように\\xで16進数渡すためには-eオプションが必要です。hexdumpにパイプして確認します。\n% echo -en \u0026#34;\\x01\\x02\\x03\u0026#34; | hexdump 0000000 01 02 03 0000003 これをbase64にパイプすれば、変換できます。\n% echo -en \u0026#34;\\x01\\x02\\x03\u0026#34; | base64 AQID 逆変換して確認しておきます。\n% echo AQID | base64 -D | hexdump 0000000 01 02 03 0000003 ","date":"2019-10-16T23:52:12+09:00","image":"/uploads/2019/10/base64table.png","permalink":"/posts/6753/","title":"base64コマンドの使い方"},{"content":"macOSをインストールする方法をご紹介してきたのですが、多数の記事に分散してしまっています。そこで、10.15 Catalinaをインストールするための参考になる関連記事へのポインタをまとめた総集編を作りました。\n10.14を対象とした情報は、以下をご覧ください。\nHackintoshの作り方（総集編:10.14版）\n10.13を対象とした情報は、以下をご覧ください。\nHackintoshの作り方（総集編:10.13版）\n手順の概要を把握する こちらは9TO5MacのライターのJeffさんのビデオです。テンポよく紹介されていますので、全体の流れを確認するのに良いと思います。High Sierra時代のビデオですが、ほぼ変わらないので参考にしてください。\nJeffさんのインストールガイドビデオ\nmacOSインストールのアプローチはたくさんありますが、一番おすすめなのは、Cloverを使ってバニラなインストールをすることだと思います。そのことを説明しています。\n/posts/131/\nCloverインストーラだけを使って、手順を理解しつつインストールすることが理想だと思いますが、それが困難な場合は、tonymacx86で配布されているツールを使っても良いと思います。こちらをご覧ください。\ntonymacx86式インストール手順 (その1: UniBeast)\nハードウェアを用意する Hackintoshを作るためには、互換性のあるハードウェアを自由に選んで組み合わせられる自作PCが、問題が少なく楽です。ノートPCなども可能ではありますが、上級者向けだと思います。\nCPU CPUは、最新の第9世代Coffee Lake-S Refreshが良いと思います。最近では品揃えも増えたので選びやすいと思います。第9世代Core iシリーズ最安の9100Fでは、問題なくmacOSが動きます。以下はMojaveの例ですがCatalinaも同様の手順で動きます。\nMSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh\nこの記事を執筆段階でのMac製品で採用されているデスクトップ向け第9世代Core iシリーズCPUは9600Kと9900Kです。このどちらかを選べば、CPU関係の設定で苦労することなく、macOSを動かすことができます。\nMSI B360M MORTAR TITANIUM, 9600K\n9900K搭載Z390マザーボードでHackintoshを作る\nマザーボード マザーボードは、第9世代CPUをサポートするZ390, H370, B360などのチップセット搭載マザーボードを選ぶことになります。新規に購入するなら、古いマザーボードを選ぶ理由はないので、最新のものを選んだ方が良いと思います。安く自作するためにパーツの一部を中古で購入することもあるとは思いますが、マザーボードは新品が良いと思います。中古のマザーボードは、部品が劣化していることもあるようで、動作が安定しない印象があります。HackintoshはそもそもOSレベルで怪しいことをやりますので、ハードウェアは信頼性のあるものを選んでおきたいと思います。\nマザーボードメーカーに関して、昔はGigabyteの互換性が高いと言われていましたが、今は、あまり関係ないです。カーネル読み込みのためのメモリー確保の容易さを考えるとASUSやASRockが良いように思います。MSIのメモリーマップも癖がありますが、対応は容易です。Gigabyteは、メモリー確保設定が難しい機種もあるようです。詳しくはこちらをご覧ください。いずれにしても、ネット上に成功例があり、詳しく解説されているマザーボードを選ぶのが良いと思います。\nslideでカーネル読み込み番地を調整する (Clover編)\nグラフィックス iGPUを使っても良いですが、拡張できるという自作のメリットを生かすならグラフィックスカードを使いたいところです。こちらに最近のmacOS互換グラフィックスカードを紹介してあります。\nmacOSのためのGPUの選び方\nこちらもご覧ください。\nHACKINTOSHのパーツ選び 【その3：グラフィックス編】10.14以降版\nそのほかのパーツ 無線アダプタ、SSD, そのほかのパーツについても紹介しておきました。\n/posts/138/\nHackintoshのパーツ選び 【その5：SSD】\nHackintoshのパーツ選び 【その6：その他】\nマザーボードのBIOS/UEFIを設定する インストール先のコンピュータを組み上げたら、macOSが稼働するようにBIOS/UEFIを設定しておきます。この設定が間違っていると、それだけで起動しない場合もあります。ただ、最近のマザーボードでは、ほぼデフォルトで大丈夫だったりします。\nマザーボード (BIOS) 設定\n必要なソフトウェアを入手する Hackintoshするには、macOS本体以外にオープンソースで有志が開発しているソフトウェアがいくつか必要です。その最新版を入手しておくべきです。\n必要なソフトウェアの名前で検索すれば、大抵の場合、ダウンロード先が見つかります。オープンソースのソフトウェアは、オリジナルを作った人の他に、いろいろな人がソースコードを引き継いで分岐（フォーク）して、開発を行なっている場合もあります。中には元祖の開発者が放置して、開発が止まっていることもあります。なので、検索して、現在一番活発に利用されているバージョンを使うのが良いです。ということで、古いハウツー情報のダウンロード先から入手するよりも、検索をして探すのがおすすめです。\n最近はKext Updater.appというアプリケーションを使っています。Clover, OpenCore, kext類などの最新版をダウンロードしてくれます。これを使えば、一番信頼できるフォークの最新版が手に入ると思います。この他にも、Clover Configurator.appなどの設定支援アプリケーションでも、最新版が入手できる機能が備わっています。\nワンクリックで最新KEXTに〜Kext Updater.app (Ver. 3)\nClover EFI bootloaderとefiドライバー “Clover EFI bootloader”で検索します。以下が本家かと思われます。\nhttps://sourceforge.net/projects/cloverefiboot/\nKext UpdaterのアプリケーションからBootloaderのボタンを選ぶことで、コンパイルされた最新版が得られます。Cloverをダウンロードすると、インストーラ、efiドライバ、テーマファイルなども一緒に入手できます。\nkext類 FakeSMCをはじめとしたkext （カーネル拡張）が必要です。名前で検索すれば、支持されているバージョンが見つかります。例えば、FakeSMC.kextならば、”FakeSMC.kext”で検索すると、こちらで入手可能なことがわかります。\nRehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket\nKext Updaterを使うと、使用しているkext類のバージョンを自動的にチェックして、最新版を入手できます。名前を指定してkext類を個別に入手することもできます。こまめに更新されているので、最新版を確実に入手することができます。\nMac上で導入用のUSBメモリを作る macOSをインストールする一般的な方法は、macOSを入手して、インストール用のUSBメモリを作る方法です。この作業は実際のMacで作業します。ついでに、実際のMacでこのUSBメモリが起動することを確認しておきましょう。次に、インストール対象のマシンで起動できるように、Cloverのインストールと設定を行います。\nCatalina導入用USBメモリーを作成する\n次に、インストール先のマシンで、このUSBメモリを起動して、インストール先のドライブをフォーマットし、macOSをインストールします。インストール先マシンでUSBメモリが起動するように調整する作業が一番大変です。\nmacOSのインストール途中で、何度か再起動することがあります。インストール途中のCloverの起動画面で、”Boot macOS Install from (インストール先のボリューム名)”という項目を選びます。\nUSB 3.0/3.1のUSBメモリを使った場合、Cloverの選択画面は現れるけど、そのあとのプロセスで失敗することがあります。macOSにはUSBの個数に制限があり、3.0/3.1のポートが2.0としてしか動かない場合があるからです。対応法は以下の記事の「ポートを増やすパッチ」をご覧ください。\nUSBポートを設定する\nただ、USB 2.0でしたら確実に起動しますので、\nUSB 2.0のUSBメモリを使う マザーボードのUSB 2.0専用ポートを使用する（全部が3.0/3.1の最近のマザーボードではこの手法は使えないです） USB 2.0ハブを経由して無理やり2.0にする などで対応するのが簡単です。2.0なのでインストールに時間がかかる欠点はあります。\nMac上でmacOSドライブを作る 冒頭で示した動画を含めて、多くのガイドではMac上で導入用のUSBメモリを作る方法を紹介しています。でも、本物のMacやHackintoshなどのmacOSが動くマシン（以下、親マシンと書きます）上でmacOSドライブを作ることも可能です。Hackintoshで使おうとするSATA SSDドライブ、mSATA SSDカード、M.2 SSDカードなどを、直接、もしくは、USB外付けHDDケースに入れて、親マシンに接続します。これをGUIDパーティションマップでフォーマットします。パーティションのフォーマットはHFS+でも良いですが、インストール時にAPFSに変更されるので、最初からAPFSで良いかと思います。\n次にmacOSにインストーラを使ってmacOSを入れます。このドライブでちゃんと起動することを確かめておけば、問題を切り分けることができて楽です。以下の記事では、この方法でインストールしましたので参考にしてください。\n9900K搭載Z390マザーボードでHackintoshを作る\nCloverとkextを入れる USBメモリーを作ってインストール先で起動させる方法でも、親マシンでmacOSを直接インストールする方法でも、いずれの場合でも、Hackintoshを起動させるためのESP部分を作成することが1番困難な部分です。ここには、Cloverとkext類を入れます。新しいmacOSに対応していて、各種バグが改善されている最新版をダウンロードすることをお勧めします。Cloverインストールの手順はこちらにも書いてあります。\nCloverインストーラの設定\nCatalinaの出る少し前に、Cloverが管理するESPの構成が少し変わりました。古い説明を読む場合は、注意してください。\nCLOVER 4988 でEFIドライバ関連が変更されました\n以下では、config.plistの例を示して、説明しました。\nconfig.plistの実例紹介\nconfig.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。\n正しく機種設定する (SMBIOSの設定)\nconfig.plistの解説では、Corpnewtさんのバニラガイドが簡潔で良いと思います。「Coffee Lakeマシンのためのconfig.plistの作り方」のページを以下で紹介しています。\ncorpnewtさんのバニラガイド~Coffee Lake用config.plist\nCloverをインストールしたら、次にkext類をESPの部分に入れます。kextについてはいくつかの記事で解説しましたが、こちらが簡潔かもしれません。\nCORPNEWTさんのバニラガイド~ Clover設定とkext\nなお、CatalinaでCloverインストーラが動かない問題もあるようです。SIPを解除すればインストールできます。こちらをご覧ください。\nCatalinaにしたらCloverがインストールできない\nmacOS環境を整える 以上の設定で、とりあえずの起動が行えることを目指します。それができたら、さらに、グラフィックスカード、Ethernet, サウンドの設定をします。以下の記事が参考になるかと思います。\n/posts/90/\nEthernetを設定する\n/posts/120/\n","date":"2019-10-13T23:00:57+09:00","image":"/uploads/2019/10/%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2019-10-09-12.27.57.png","permalink":"/posts/6538/","title":"Hackintoshの作り方（総集編: macOS 10.15版）"},{"content":"CatalinaからCloverをインストールしようとすると、Cannot install without ensuring the file system is read-write というメッセージが出て、インストールできませんでした。これはSIP設定で回避できます。手作業でインストールする際には問題にならないので、将来のインストーラで対応されるかもしれません。\nインストールできない Catalinaからファイルアクセスの制限が厳しくなったと感じています。いろいろなアプリケーションにファイルアクセスの許可を出したり、ネットからのダウンロードを許可する作業などが必要になりました。システムの一部が読み出し専用になったことも関係していると思います。その影響で、インストーラでCloverをインストールしようとすると、上記のようなダイアログボックスが出てインストールできないことがあります。このようなソフトウェアインストーラは、macOS標準の「インストーラ.app」を使っています。/System/Library/CoreServices/に置かれているアプリケーションです。エラーメッセージは、このアプリケーションが引き起こしていると考えられます。\n対策をネットで調べると、「リカバリーモードで再起動してターミナルからSIPを無効にすれば良い」という回答がありました。先日の記事へのコメントでも同様の方法を教えていただきました。ありがとうございます。ちなみに、リカバリーモードでSIPを解除しても、次の次の起動ではちゃんと元に戻るそうです。\nr/hackintosh - Clover - Cannot Install w/o Ensuring File System is Read/Write\nでもこの方法だと、インストーラを動かすまでに2回の再起動をする必要があります。手間の少ない方法を考えました。\nSIPを限定解除 Hackintoshのconfig.plistで、SIPを全部外した設定をしていれば、このメッセージは出ないのかと思います。手元のマシンでは、できるだけバニラな設定にして実機と同じにしたいと考えていたので、SIPも全部有効になってました。なのでターミナルで確認すると、以下のように、SIPは全項目で有効になっていると表示されます。\n% csrutil status System Integrity Protection status: enabled. SIPは色々な保護をしてくれますが、今回の問題に対してはファイルシステムへの制限を解除すれば良さそうです。SIPを完全に機能させている場合、config.plistのCsrActiveConfigの数値は、\n\u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x00\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; となっていると思います。これの下位2ビット目を立てて、例えば、\n\u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x02\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; のように書き換えれば良いです。でも、SIPを元に戻すにはまたこれを書き直すことになり面倒です。そこでCloverの起動画面のOptionから変更しました。まずは、下のメニューからOptionsを選択します。\n次にSystem Parameters, System Integrity Protection (SIPのことです)と選んでいきます。SIPの設定は、config.plistで全部有効にしてあるので、設定値が0になってます。\nここでSIPの各項目を設定できるので、Allow Unrestricted FSを選びます。FSはファイルシステムの意味で、ファイルシステムアクセスの制約を外すという設定です。\nこれで起動すると、SIPが限定解除されています。ターミナルで確認すると、\n% csrutil status System Integrity Protection status: unknown (Custom Configuration). Configuration: Apple Internal: disabled Kext Signing: enabled Filesystem Protections: disabled Debugging Restrictions: enabled DTrace Restrictions: enabled NVRAM Protections: enabled BaseSystem Verification: enabled This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state. のように表示されます。Filesystem Protectionsが無効になっています。どういうわけかApple Internalも無効になっていますが、セットで設定すべき値なのかもしれません。この状態でCloverインストールを行うと、問題なく実行できます。Cloverの起動画面で一時的に設定しましたので、次の再起動ではSIPは元に戻っています。\n","date":"2019-10-12T12:14:13+09:00","image":"/uploads/2019/10/alarticon.png","permalink":"/posts/6682/","title":"CatalinaにしたらCloverがインストールできない"},{"content":"CatalinaをクリーンインストールするためのUSBメモリーを作ります。まずはCatalinaに含まれるcreateinstallmediaコマンドを使います。次にESPを作ります。すでにMojaveが動いているHackintoshがあればESPのファイルをコピーするだけです。\nMojave用ESPを最新にする Catalinaは、Mojaveの場合と同じefiドライバー、kext、config.plistでCatalinaが起動できることを確認しています。ただしどれも最新版にしておくのが望ましいです。\nCatalinaにアップデートする\nということで、Kext Updater.appなどを使用して、Cloverとkext類を最新にしておきます。\nCatalinaをダウンロードする macOSが動いているマシンからAppleのサイトに接続して、Catalinaのインストーラをダウンロードします。ダウンロード後に、自動的に起動しますが、メニューから終了させます。アプリケーションフォルダにmacOS Catalinaインストール.appというアプリケーションができているはずです。\nUSBメモリを初期化する インストーラ用のUSBメモリを用意します。インストーラのサイズが8GBを超えていますので、16GB以上のメモリが必要です。今回は32GBのUSB 3.0メモリーを用意しました。起動速度がとても遅くなってしまいますが、本当ならばUSB 2.0メモリーの方が確実です。今回は設定済みのESPがあるので問題ありませんが、未知のマザーボードの場合、USBの15個制限の影響で、USB 3.0ポートがUSB 2.0として動いてしまうことがあります。その場合、BIOS起動時は3.0だったポートが、macOSに制御が切り替わった途端に2.0に変貌してしまうので、起動作業が止まってしまうのです。\n次に、USBメモリーをディスクユーティリティ.appを使って初期化します。この時、ESP (EFI System Partition) から起動可能なように、ESPが作られるように初期化します。ディスクユーティリティ.appのデフォルトではボリュームのみが表示されますので、まずは、メニューバーの表示から「すべてのデバイスを表示」を選んでおきます。\nこうすると、USBメモリ製品名が入ったデバイス名がウィンドウ左側リストに現れますので、これを選択します。今回はSanDisk Extreme Mediaという製品名を選択しています。次に消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここで、最新のAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。\n実機用インストーラを作る まずは実機（本物のMac）でも使えるCatalinaインストール用USBメモリを作ります。ターミナルを使用して、Catalinaインストーラの中に移動します。ターミナルから見ることができるmacOSオリジナルの世界では、アプリケーションフォルダは、Applications, インストーラはInstall macOS Catalina.appという名前になっています。ここでlsするとcreateinstallmediaというファイルが見つかるはずです。\ncd /Applications/Install\\ macOS\\ Catalina.app/Contents/Resources/ ls create* createinstallmedia これを使用して、macOSインストールUSBメモリを作成します。とりあえず起動すると、ヘルプ情報が表示されます。\n./createinstallmedia Usage: createinstallmedia --volume \u0026lt;path to volume to convert\u0026gt; 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メモリへのパスを書いておきます。ということで、以下のコマンドを入力します。\nsudo ./createinstallmedia --volume /Volumes/USB\\ Memory/ パスワード入力の後、USBメモリを消去する確認を求められ (yを押します)、USBメモリ作成が開始します。しばらく経つと、以下のようなメッセージが出てインストーラUSBメモリが完成です。\nsudo ./createinstallmedia --volume /Volumes/USB\\ Memory/ Ready to start. To continue we need to erase the volume at /Volumes/USB Memory/. 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 \u0026#34;/Volumes/Install macOS Catalina\u0026#34; こうして完成したCatalinaインストール用USBメモリは、実機のMacでこれ単体で起動して、Catalinaのクリーンインストールが可能です。\nHackintoshの場合も、今までMojaveを起動していたのと同じドライブのESPから起動すれば、このUSBメモリーインストーラを使用できます。Cloverの起動選択肢に「Boot macOS Install from Install macOS Catalina」という項目が見えているはずです。これがここで作ったUSBメモリですので、これを選んで再起動します。この手順でCatalinaのインストーラが起動することを確認できます。\nESPを作成する ドラッグアンドドロップで複製する 前のステップで、今までmacOSを起動していたESPからUSBメモリ内のCatalinaインストーラが起動したことが確認できました。そうであれば、USBメモリ単体で起動させる手順は簡単です。USBメモリのESPに、これを起動させることができたESPの内容をコピーするだけです。下のスクリーンショットでは、起動ドライブのESPの中身を、USBメモリのESPに、ファインダのドラッグ\u0026amp;ドロップ操作でコピーしています。\nこれで単体で起動するUSBインストーラが完成しました。BIOSでこのUSBメモリーから起動するよう指定すれば、USBメモリー単体で起動します。\nCloverを新規にインストールする ドラッグアンドドロップで今までのESPを複製する代わりに、Cloverインストーラを使って新規にインストールしても良いです。結果は同じで、新規に作るので気分が多少良い程度の違いです。Cloverのインストール時に必要なefiドライバを選んでおきます。次にconfig.plistとkext類を、現行のものと同じにしておきます。ただ、SIPを有効にした状態でCloverインストーラを動かすと、現時点ではエラー表示が出て進捗しないようです。こちらの記事をご覧ください。\nCatalinaにしたらCloverがインストールできない\nUSBメモリーから起動する USBメモリーから起動すると、すぐにインストーラが起動するのではなく、macOSユーティリティというソフトウェアが起動します。ここから、ネットワーク設定、ターミナル、Time Machine操作、ディスクユーティリティなどが使用できますので、インストール以外にも色々と役立ちます。\nまとめ 単体で起動するmacOSインストーラUSBメモリを作りました。Catalinaを対象としましたが、以前のバージョンの場合と手順は同じです。今回ご紹介した手順は、tonymacx86のサイトで配布しているUniBeastが行う作業に相当します。ただ、MojaveでHackintoshがすでに動いていることを前提にしているので、ESP部分の作成は簡単でした。\nこのインストーラUSBメモリがあれば、これ単体で起動してmacOSユーティリティを起動できます。ここから、ボリュームをフォーマットできるので、マシンに新規のドライブだけが接続されている場合でもインストールできます。また、ターミナルで様々な操作が可能です。macOSが起動できなくなった場合の緊急時用にこのようなUSBメモリを持っていると、復旧作業が楽です。\n","date":"2019-10-10T23:37:53+09:00","image":"/uploads/2019/06/%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2019-06-25-15.15.28.png","permalink":"/posts/5661/","title":"Catalina導入用USBメモリーを作成する"},{"content":"macOS Catalina 10.15の配布が開始されました。早速、Mojaveからアップデートしました。Cloverとkext類を最新版にすれば、時間はかかるものの通常の作業でアップデートできるようです。\nアップデートの準備 昨日 (2019/10/8 JST)、macOS Catalina 10.15の配布が開始されました。例年だと1-2週間前に配布開始日がアナウンスされたのですが、今回は突然のことでした。慌ててインストールしたのですが、インストールが止まって見えてしまうトラブルがあって報告が遅れました。実は、単に時間がかかっていただけのようでした。\nシステムの構成 インストール先のマシンは、こちらです。\nMSI B360M MORTAR TITANIUM, 9600K\nこれに取り付けたCrucialの1TB M.2 SSD, CT1000P1SSD8にインストールしました。\nCrucialの1TB NVMe M.2 SSD (CT1000P1SSD8) を使う\n光学ドライブとTimeMachine用のHDDなどが接続されているのですが、わかりやすいように一時的に取り外した状態で進めました。また、起動ボリュームは慣例に従ってMacintosh HDにしてあったのですが、これもわかりやすいようにMojaveにしました。ということで、diskutil listコマンドで見ると、次のように見えます。\n$ diskutil list /dev/disk0 (internal): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme 1.0 TB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk1 1000.0 GB disk0s2 /dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +1000.0 GB disk1 Physical Store disk0s2 1: APFS Volume Mojave 629.6 GB disk1s1 2: APFS Volume Preboot 47.5 MB disk1s2 3: APFS Volume Recovery 510.4 MB disk1s3 4: APFS Volume VM 3.2 GB disk1s4 SSDにはEFIシステムパーティション(ESP)と、APFSコンテナのパーティションができています。APFSコンテナのパーティションは、SSDの空きを全て割り当てて確保してあります。APFSコンテナの中には、改名したばかりのMojaveという名前のメインボリュームがあります。macOSのシステムもデータも全部がこの中に入っています。PrebootはFileVault用のボリューム、Recoveryはリカバリーモードで起動するためのボリュームです。VMは仮想メモリー用のボリュームです。APFSのボリュームは、サイズが可変で、必要な容量に対して柔軟に対応できます。\nESPを最新にする バニラなインストールをしているので、Hackintoshに必要なファイルは全てESPに入っています。Catalinaに備えて、この内容を最新にアップデートしておきます。開発者の皆さんが対応してくださっていますので、アップデートで発生する問題の多くは、Cloverやkextが最新版にすることで対処できます。現時点でのCloverの最新バージョンは、5070です。最新でしたのでそのままにします。次に、Kext Updater.appで使用中のkextを最新にします。手元のシステムでは、WhateverGreen.kext, IntelMausiEthernet.kext, AppleALC.kextを更新しました。更新したら、念のために再起動して、Mojaveとして起動することを確認しておきます。\nワンクリックで最新KEXTに〜Kext Updater.app (Ver. 3)\n新ボリューム作成 現在のMojaveに上書きアップデートしても問題ないとは思います。でも念のためにMojave環境は残しておきたいです。また、せっかくだから気持ちよくクリーンインストールしたいとの考えもありました。APFSなら、新しいボリュームを作成するのは簡単です。ディスクユーティリティ.appを開いて、Macintosh HDという名前の新しいボリュームを作成しました。（よく考えたらもはやHDじゃないですね）\n念のためにdiskutilコマンドでも確認しておきました。\n$ diskutil list /dev/disk0 (internal): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme 1.0 TB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk1 1000.0 GB disk0s2 /dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +1000.0 GB disk1 Physical Store disk0s2 1: APFS Volume Mojave 631.1 GB disk1s1 2: APFS Volume Preboot 47.5 MB disk1s2 3: APFS Volume Recovery 510.4 MB disk1s3 4: APFS Volume VM 3.2 GB disk1s4 5: APFS Volume Macintosh HD 647.2 KB disk1s5 Catalinaをダウンロードする これで準備万端ですので、Mojaveで起動して、「システム環境設定」「ソフトウェアアップデート」を開いて、Catalinaをダウンロードします。8GBあるようです。\nインストールする ダウンロードするといつものように自動的にインストーラが開きます。デフォルトのインストール先は、現在起動しているMojaveになっていますが、新しく作ったMacintosh HDを選択します。\nインストールが始まると、間も無く再起動します。再起動時のCloverの起動選択画面では、Boot macOS Install from Macintosh HDを選択します。デフォルトでこれが選ばれていると思います。\nこのあとインストール画面になります。今回の環境では、この先が長かったです。About 11 minutes remaining…という表示が出たまま、インストールが止まってしまったように見えました。小一時間様子を見たのですが、変化がありません。そこで強制終了していろいろ試したのですが、どうしても11分のところで止まってしまいました。仕方がないので、そのまま一晩放置したところ、インストールが終わっていました。単に、時間がかかっていただけだったようです。\n実は以下で紹介したZ390マシンでも、同様な手順でCatalinaのインストールを並行して行いました。そちらでも、やはり11分で止まりました。でもZ390マシンはしばらくするとインストールが進みました。ということで、Catalinaへのアップデートでは辛抱強く様子を見る余裕が必要だと感じました。ちなみに本物MacのCatalinaアップデートでは、プログレスバーが停滞することはなく、割と順調に進みました。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\nインストールが終了すると、再び再起動します。今度は、インストール用のボリュームは消えていて、Boot macOS from Macintosh HDに変わってます。この挙動はいつものアップデート作業と同じです。\nインストール途中で、TimeMachineバックアップや他のMacのデータを転送するかどうかを聞かれます。最初の手順で、Mojaveのドライブを残してありました。これが転送元の選択肢に現れますので、これから復帰しました。クリーンインストールという観点からすると、古いデータを引き継ぐことになってしまうかもしれませんが、設定は楽です。ユーザデータは大量になるので、それ以外の設定とアプリケーションだけを引き継ぎました。ユーザデータは、古いUsers以下のディレクトリを、システム環境設定のアカウントで指定すれば簡単に引き継げるので、ここで転送する必要はないと思いました。\nインストールが終了した状態で、diskutilコマンドでボリュームの様子を見てみます。インストール先のMacintosh HDに加えて、Macintosh HD – Dataという名前のボリュームができています。これがCatalinaから新しく作られたボリュームです。インストール先に指定したMacintosh HDボリュームは読み出し専用になって、保護されているらしいです。- Dataのついたボリュームに、ユーザデータを含む、書き換えするデータが置かれるようです。\n% diskutil list /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *1.0 TB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk1 1000.0 GB disk0s2 /dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +1000.0 GB disk1 Physical Store disk0s2 1: APFS Volume Mojave 639.0 GB disk1s1 2: APFS Volume Preboot 129.2 MB disk1s2 3: APFS Volume Recovery 1.0 GB disk1s3 4: APFS Volume VM 3.2 GB disk1s4 5: APFS Volume Macintosh HD - Data 47.6 GB disk1s5 6: APFS Volume Macintosh HD 10.6 GB disk1s6 まとめ インストールに時間がかかったので、待ちきれなくて試行錯誤してしまいました。でも、我慢強くじっと待っていればCatalinaへは何事もなく順調にアップデートできたと思います。\n","date":"2019-10-09T20:02:46+09:00","image":"/uploads/2019/06/catalinaicon.png","permalink":"/posts/6666/","title":"Catalinaにアップデートする"},{"content":"10.14.6追加アップデート2を入れたマシンのうち1台が起動しませんでした。APFSが原因でした。ApfsDriverLoader.efiを外して10.14.6 (18G103) 付属のapfs.efiに差し替えたら起動しました。\n症状 2019年9月27日にmacOS Mojave 10.14.6追加アップデート2 (Supplemental Update 2) が配布されました。ビルドは18G103です。追加アップデートの名前の最後に2という番号がつくのは珍しいと思います。Catalinaがまもなく出るので、おそらく最後のバージョンになると思います。追加アップデートを続ける理由は、もしかしたらMojaveを10.14.6で終わりにして、バージョン番号をあげたくなかったのかもしれません。\nいくつかのマシンで、アップデータ経由で通常通りの更新が問題なく可能でした。ただ、iMac19,1に設定した9600Kマシン\nMSI B360M MORTAR TITANIUM, 9600K\nでは、どういうわけか起動しませんでした。最近は大体問題なくOSアップデートできるのですが、たまにこういう状況になるのはHackintoshの宿命で仕方ないところです。\n-vオプションで調べた症状は以下のようです。Cloverのメニューは出て、メモリー確保も正しく行えるのですが、その後メッセージが続いた後、表示が止まってしまいます。しばらく経過すると画面には、\nbusy timeout[0], (60s): \u0026#39;iMac19,1\u0026#39; という表示が出ます。iMac19,1に設定したこのマシンが60秒間応答しないという意味だと思います。この状態で、キーボードを接続すると、\nkextd stall[1], (60s): \u0026#39;Magic Keyboard\u0026#39; というような表示が出ることもあります。\nまた、いろいろなUSB機器を抜き差しすると、同様にkextd stallというメッセージが出ます。\n原因の推測 メッセージのkextdは、kext daemonのことだと思います。kext (カーネル拡張) を読み込んでカーネルに登録する機能を担っていると思われます。stallは、自動車のエンスト（エンジンストール）と同じ単語で、応答がなくて動かない、という程度の意味でしょう。つまりメッセージから判断するに、kextデーモンが特定のkextを呼び出そうとしたけど、60秒経っても応答がないようです。\n失敗しているkextはどれもmacOS本体のkextです。Clover類はESP (FAT) にありますが、macOS本体のkextは主パーティション (APFS) の中にあります。となるとAPFS (アップルファイルシステム) の読み出しに失敗している可能性があると考えました。また、上記で紹介したtimeoutメッセージも、APFSからの読み出しをする局面になって、マシンから応答がなくなりタイムアウトしたとも解釈できます。\napfs.efiで解決 CloverがAPFSにアクセスするためには、macOS本体のapfs.efiを使っています。以前はmacOSからAPFSのドライバーである\n/usr/standalone/i386/apfs.efi をESPにコピーして使っていたのですが、最近は、 ApfsDriverLoader.efiを使って、macOSから自動的に読み込んでいます。動的に読み込むことで、macOSのバージョンに合わせたapfs.efiが使えるメリットがあります。でも今回は、この仕組みが何らかの理由で機能していないようでした。そこで、EFI/CLOVER/drivers/UEFIの中の\nApfsDriverLoader.efiを削除して macOS本体からapfs.efiをコピー しました。すると10.14.6 (18G103) が立ち上がりました。\n実際に行った手順は、もう少し複雑です。というのは、このマシンは起動しないのでapfs.efiを取得できません。そこで、別のMacにUSBメモリーを挿して、これに\ncp /usr/standalone/i386/apfs.efi /Volumes/USB のようにしてapfs.efiをコピーします。次にこのUSBメモリを、起動しないマシンに接続し、CloverのメニューからUEFI Shellを起動し、cpコマンドでESPのEFI/CLOVER/drivers/UEFIにコピーしました。また、ApfsDriverLoader.efiは、rmコマンドで削除しました。UEFI Shellの使い方は、以下をご覧ください。\n起動しないマシンをUEFI Shellで救う\nApfsDriverLoader.efiが動かなかった理由は不明です。他のマシンでは18G103でも動いていますので、このマシンだけの問題かと思います。ApfsDriverLoader.efiのアップデートで解決するかもしれません。何れにせよ、起動でtimeoutやkextd stallのメッセージで止まる場合には、APFS関係を疑うと良いかと思いました。\n","date":"2019-10-05T14:06:57+09:00","image":"/uploads/2018/11/mojave.png","permalink":"/posts/6631/","title":"kextd stallというエラーで起動しないことに対処"},{"content":"AliExpressなどで格安の小型ベアボーンPCが多数販売されています。Intel NUCのような製品群ですが、形状が多彩でファンレスの構成が多いです。その中でも、Macに搭載されたCPUを搭載している製品なら、macOSとの互換性が高いのではと思います。\n格安小型PC AliExpressなどの中国のショッピングサイトで小型PCがいくつも販売されています。格安のモデルはCeleron系のCPUを搭載しています。少し上の価格帯になると、末尾がUのインテルCPUを搭載しています。MacBook Airなどで使用されているモバイル用CPUです。Celeronに比べると高価ですが、それでもメモリーやストレージの無いベアボーンだと200ドル前後で買うことができます。UタイプCPUを使った小型PCの規格としてはIntel NUCが有名でHackintoshも試みられています。\nNUCで作る超小型macOSマシン\nただ、Broadwell以降のNUCは、無線モジュールが半田付けになってしまい、macOSと互換性のあるモジュールに交換できなくなりました。また価格が高いです。中国ショッピングサイトの小型PCがNUCの代替になるなら魅力的です。\nmacOSと相性の良い製品 中国ショッピングサイトの小型PCは、日本語サイトでもあちこちで紹介されているようです。YouTubeでも紹介されていました。でもどれもWindowsで使用することを前提に紹介されています。macOSは動くのでしょうか？\nmacOSが動くためには搭載パーツに互換性のあることが重要です。CPUが同じか、近い機種が良いでしょう。また、iGPUが同じでは無いと、画面表示ができない可能性が高いです。そこでAliExpressの小型PCラインナップの中から、Macで採用されているCPUと同じCPUを搭載している小型PCを探しました。先日作成したMac搭載CPUリストを活用しました。\nMacに搭載されたCPU\nCore i5-3317U 3317UはMacBookAir5,1で使用されているIvy Bridge世代のCPUです。初代のIntel NUCはi3-3217Uを搭載していますが、それのi5バージョンです。初代NUCはmacOSとの互換性が高かったのですが、3317Uは実機で採用されているのでさらに適していると思われます。\nこちらの製品は3317U搭載していて、メモリー、SSD、WiFi無しのベアボーン状態で$158送料込みのようです。Mac miniによく似た形状をしています。古いCPUですがCatalinaもギリギリサポート対象です。CPUが古いので価格が安いのですが、Webや動画閲覧くらいの用途なら問題ないと思われます。\nCore i5-4260U Haswell世代CPUの4260Uは、MacBookAir6,1, 6,2, Macmini7,1, iMac14,4というMacのすべてのカテゴリーで採用されています。macOSに最も愛されていたCPUと言えます。\nこの製品は、4260Uを搭載しているようです。べアボーン構成で、送料込み240ドルくらいとちょっと高めです。これもMac mini的な外観です。素材はヘアライン加工されたアルミ板のようです。CPUにはファンもついていて、さらに2.5インチドライブを格納する場所もあり、実用性は高いと思われます。\nIntel NUCにはこれに近い4250Uを搭載した機種があります。HaswellはmacOSと互換性が高く安定して動作するという定評がありました。4250U搭載Intel NUCを使った動作例は以下で紹介しています。このNUCはもう入手困難ですし、格安だった時でも3万円程度しました。240ドルで潤沢に入手できるならありがたいかと思います。macOSが安定して稼働すると思われます。\nIntel NUC D54250, 4250U\nCore i7-4650U 4650Uは、MacBookAir6,1,と6,2で採用されています。Core i7に分類されるCPUですので強力そうな印象があります。価格は送料込み$237程度です。これも価格が高めですが、LANとHDMIが2個ついています。SDカードソケットもついているようですが、おそらくmacOSでは動かないと思います。\nCore i5-5250U Broadwell世代の5250UはMacBookAir7,1, 7,2, iMac16,1で採用されています。ノート型とデスクトップ型の両方で採用されているので、これもmacOSとの互換性に期待できます。\nAliExpressには5250U搭載の小型PCがいくつか見つかりました。その一つがこれです。円形でとても変な形です。XCYというメーカの製品で、X36という型番のようです。360度にわたって丸いのでX36という型番なのではと思います。最安の出品では送料無料の$183.17でした。\nなお、そっくりな製品が販売サイトによっては、OLOEYとか、TOPDA SOURCEというブランド名で紹介されています。でもXCYは他にも小型PCを多数製造しているメーカなので、他のブランドはXCYからOEM供給を受けているのではと思われます。\n黒だけでなく、金色のモデルもあるようです。神々しいです。でも黒色モデルより10ドル程度高いようです。\n同じBroadwell 5250Uを搭載していますが、もっとまともな形状をした製品もあります。\nアルミ一体型の作りで、どこからみてもカッコ良いです。Mac miniの雰囲気があります。上のX36に比べて、2.5 inchドライブも内蔵できるようです。またメモリーも2枚取り付けられます。ただしベアボーンで$260するので価格はちょっと高いです。$230の販売ページもありましたが「5250Uと5200U搭載モデルがランダムに届く」という謎の条件なので気をつけた方が良いです。同じCPUなのに、上で紹介したX36が安いのは、どうみても使いにくい円形なので安くしないと売れないという事情のような気がします。\nIntel NUCにも5250U採用モデルがあります。Intel NUC 5i5シリーズです。ただそのシリーズでは、ほとんどモデルで無線モジュールが半田付けタイプです。これをmacOS互換性品に交換することが不可能です。5i5MYHEというモデルだけは交換可能なようですが、出荷量が少ないのか入手困難です。5i5MYHEに相当する小型PCが$200前後なので、価値があると思います。\nCore i5-6360U Skylake世代の6360UはMacBookPro13,1で採用されています。送料込みで$259です。外観は、上で紹介した5250U搭載製品に似ていますが、アンテナ位置やパネルの細工に多少の違いがあります。CPUが新しくなっても、価格に差が無いので、こちらを選んだ方が良いと思います。ケースは少し大きめですが、その分、2.5インチドライブを搭載可能なようです。\nCore i7-6700HQ, 7700HQ Skylake 6700HQはMacBookPro13,3に、Kaby Lake 7700HQはMacBookPro14,3に搭載されています。MacBook Pro用なので高性能です。こちらの製品は、オプションでそれぞれのCPUを選択できるようです。ベアボーン構成でそれぞれ送料込みで$308と$332です。\nCore i7-8750H, i9-8950HK 8750Hも8950HKも、2018年モデルのMacBookPro15,1, 15,3に搭載されています。ごく最近のCPUです。なので最小構成でもそれぞれ$400、$700以上します。ここまで高くなると、買って試すには危険な領域かもしれないです。なお、第9世代の小型デスクトップ製品は見つかりませんでした。\nまとめと注意点 気になった製品 中国からの輸入になるので、不安定要素も多いですし時間もかかります。なので、最初から最新の高価格モデルに挑戦するには少しハードルが高い気がします。古いCPUで価格が安くなった製品を選ぶのが良いように思います。Core i5-3317U搭載製品は$158から入手できるので、安くて良いと思いました。また、Core i5-5250Uは、少し新しいCPUにも関わらず$183から選択肢があり、お得感があると思います。奇抜な丸い筐体のXCY X36は面白いと思いました。\n違うCPUが届く？ 上でも述べましたが、出荷のタイミングにより異なるCPUが搭載されると説明のある製品があります。また、最初に紹介したYoutubeのビデオによると、そういう説明がなくても、少し上位モデルのCPUが搭載されて届くこともあるようです。実際のMacと同じCPUを手に入れようとするには、多少のリスクが伴いそうです。何が届いてもおおらかに受け入れる心構えが必要かと思いました。\n","date":"2019-10-02T23:56:14+09:00","image":"/uploads/2019/10/スクリーンショット-2019-10-06-23.27.54.png","permalink":"/posts/6550/","title":"中国の小型ベアボーンPC"},{"content":"macOSをMac以外のマシンで動かすことは想定されていません。なのでmacOS開発陣が動作保証するCPUは、Macに搭載されたCPUだけです。この記事ではMac搭載CPUを列挙しました。Hackintoshを作る際のCPU選びの参考にしてください。\n実機のCPUとiGPU macOSはMacのために開発されていますので、正式に対応しているCPUはMac搭載CPUだけと言えます。実際には、Mac搭載CPUに近い仕様のCPUならばmacOSは問題なく動きますが、それはたまたま動いていると考えるべきかと思います。macOS開発陣は、そのCPUでの動作チェックをしていないと思います。HackintoshのCPU選びは、以下の記事にまとめておきました。そのCPUが実機に搭載されているかどうかは、パーツ選びの重要なポイントと思います。\nHackintoshのパーツ選び 【その1：CPU編】\nそんなCPU選びの場面で便利に使えるMac搭載CPUの一覧情報って、ありそうでなかなか無かったかと思います。MacTracker.appなどのアプリやMacの仕様をまとめたページはたくさんありますが、CPU選びに使うには使いにくいです。そこで、公開されているMacの仕様から、搭載CPUの一覧を作ってみました。全部調べるのは大変ですので、CatalinaでもサポートされているIvy Bridge以降のCPUとそのiGPUについて、まとめました。\nデスクトップMac iMac 自作PCでHackintoshを作る場合にCPU選びの基準となるのはiMacです。パーツ店で買えて、市販のマザーボードに搭載できる「組める」CPUが採用されています。なのでiMac搭載CPUは、自作PCのCPU選びの基準になります。末尾がKなのは、オーバークロック対応CPU (実機ではOCしていません)、Sなのは省電力モデルです。無印とクロックが違うだけですので、macOS互換性は変わらないです。かつてのエントリーモデルiMacで使用されたUとRは、半田付けタイプのCPUですので、自作PCの対象にはなりにくいです。\niMacにはiGPUのみで稼働するモデルと、専用のGPU（dGPU）を別途搭載しているモデルがあります。dGPUを前提とした使われ方をしているCPUや、それに対応するMacのモデル番号を使用する場合には、ビデオカードと組み合わせて使う方が安定すると思われます。\n3470S, 3470, 3770 \u0026lt;– iMac13,2 3225, 3330S, 3470S, 3770S \u0026lt;– iMac13,1 4570R, 4570S, 4770S \u0026lt;– iMac14,1, 14,3 4570, 4670, 4771 \u0026lt;– iMac14,2 4260U \u0026lt;– iMac14,4 4590, 4690, 4790K \u0026lt;– iMac15,1 5250U, 5575R \u0026lt;– iMac16,1, 16,2 5675R, 5775R \u0026lt;– iMac16,2 6500, 6600, 6700K \u0026lt;– iMac17,1 7360U \u0026lt;– iMac18,1 7400, 7500, 7700 \u0026lt;– iMac18,2 7500, 7600, 7600K, 7700K \u0026lt;– iMac18,3 8100, 8500, 8700 \u0026lt;– iMac19,2 8500, 8600, 9600K, 9900K \u0026lt;– iMac19,1 iMac Pro Hackintoshコミュニティでそれほど積極的には解明されていないXeon搭載なので、自作の参考にはあまりならないかと思います。\nW-2140B, W-2150B, W-2170B, W-2190B \u0026lt;– iMacPro1,1 Mac mini miniは概ねモバイルCPUが搭載されています。Macmini8,1に搭載の末尾がBのモデルは、半田付けタイプですが、無印と同一の仕様です。中身は同じと考えて良いです。miniは、すべてがiGPUで動いています。なのでiGPUはmacOSでサポートされていると考えて良いです。\n3210M, 3615QM, 3720QM (Intel HD Graphics 4000) \u0026lt;– Macmini6,1, 6,2 4260U, 4278U, 4308U, 4578U (Intel HD Graphics 5000, 5100) \u0026lt;– Macmini7,1 8100B, 8500B, 8700B (Intel UHD Graphics 630) \u0026lt;– Macmini8,1 モバイルMac MacBookシリーズには半田付けタイプのCPUしか搭載されていません。なので、通常の自作PCでは、あまり参考にできないです。ただ、Intel NUCのようなCPU搭載ベアボーンとして提供されている製品や、ノートPC選びの参考になります。CPUが実機と同じならHackintoshの成功率は高いです。Intel NUCには、7567U、5557U、5250U、4250U、3427U搭載モデルがあります。これらはMacBook AirやMacBook Pro搭載CPUです。これらのCPUは一般的なのか、NUC以外の他社の小型べアボーン製品やノートPCでもよく使われています。\nCPUが違っても、iGPUが同じなら、これもHackintoshできる可能性が高いと考えて良いです。そのiGPUのためのドライバーがmacOSに含まれているのでiGPU表示が期待できます。また、iGPUが同じなら、CPU仕様も類似しているので、macOSとの互換性が高いと言えます。例えば初代NUCでは3217Uが使われましたが、これはMacBookAir5,1搭載の3317Uに近いのでmacOSとの互換性が高かったです。\nNUCで作る超小型macOSマシン\nMacBook Air MacBook AirはすべてiGPUで動作します。同じCPUが使えれば、動作も表示も安定しています。\n3317U, 3367U (Intel HD Graphics 4000) \u0026lt;– MacBookAir5,1 3427U, 3667U (Intel HD Graphics 4000) \u0026lt;– MacBookAir5,2 4250U, 4260U, 4650U (Intel HD Graphics 5000) \u0026lt;– MacBookAir6,1, 6,2 5250U, 5350U, 5650U (Intel HD Graphics 6000) \u0026lt;– MacBookAir7,1, 7,2 8210Y (Intel UHD Graphics 617) \u0026lt;– MacBookAir8,1, 8,2 MacBook Pro MacBookシリーズの主力機であるMacBook Proには多数のモデルがあり、搭載CPUも多いです。MacBook Proの一部のモデルはdGPUを搭載しています。\n3615QM, 3720QM, 3890QM (Intel HD Graphics 4000) \u0026lt;– MacBookPro9,1 3210M, 3520M (Intel HD Graphics 4000) \u0026lt;– MacBookPro9,2 3615QM, 3630QM, 3720QM, 3740QM, 3820QM, 3840QM (Intel HD Graphics 4000) \u0026lt;– MacBookPro10,1 3210M, 3230M, 3450QM, 3520M (Intel HD Graphics 4000) \u0026lt;– MacBookPro10,2 4258U, 4278U, 4288U, 4308U, 4558U, 4578U (Intel Iris 5100) \u0026lt;– MacBookPro11,1 4750HQ, 4770HQ, 4850HQ, 4870HQ, 4960HQ, 4980HQ (Intel Iris Pro 5200) \u0026lt;– MacBookPro11,2, 11,3, 11,4 5257U, 5287U, 5557U (Intel Iris Graphics 6100) \u0026lt;– MacBookPro12,1 6360U, 6660U (Intel Iris Graphics 540) \u0026lt;– MacBookPro13,1 6267U, 6287U, 6567U (Intel Iris Graphics 550) \u0026lt;– MacBookPro13,2 6700HQ, 6820HQ, 6920HQ (Intel HD Graphics 530) \u0026lt;– MacBookPro13,3 7360U, 7660U (Intel Iris Plus Graphics 640) \u0026lt;– MacBookPro14,1 7267U, 7287U, 7567U (Intel Iris Plus Graphics 650) \u0026lt;– MacBookPro14,2 7700HQ, 7820HQ, 7920HQ (Intel HD Graphics 630) \u0026lt;– MacBookPro14,3 8259U, 8279U, 8559U, 8569U (Intel Iris Plus Graphics 655) \u0026lt;– MacBookPro15,2 8750H, 8850H, 8950HK (Intel UHD Graphics 655) \u0026lt;– MacBookPro15,1, 15,3 9750H, 9880H, 9980HK (Intel UHD Graphics 630) \u0026lt;– MacBookPro 15,3 8257U, 8557U (Intel Iris Plus Graphics 645) \u0026lt;– MacBookPro 15,4 MacBook 無印MacBookは、さらに省電力を追求しています。自作PCではあまり機会がないかもしれません。以前紹介したLattePanda Alpha初号機は7Y30を使用していて、MacBook10,1搭載の7Y32に仕様が近いのでmacOSとの互換性が高いです。\nLattePanda Alpha 800, m3-7Y30\n5Y31, 5Y51, 5Y71 (Intel HD Graphics 5300) \u0026lt;– MacBook8,1 6Y30, 6Y54, 6Y75 (Intel HD Graphics 515) \u0026lt;– MacBook9,1 7Y32, 7Y54, 7Y75 (Intel HD Graphics 615) \u0026lt;– MacBook10,1 CPU番号順のリスト 上の情報を、CPUの番号順に並べました。そのCPUがMac搭載CPUなのかどうか、すぐに調べられるのではと思います。\nデスクトップCPU Mac搭載CPUのうち、自作で使えるLGAタイプのCPUです。一般のマザーボードのソケットに付けられます。KモデルはOC対応、Sモデルは省電力版です。これに、BGAタイプの半田付けするCPU（末尾がRとB）も含めました。内部は無印とほぼ同様なので、同番号の無印CPUのモデルIDとして使えると思います。どこかでジャンクのデスクトップPCを見つけた時に、この番号のCPUだったらぜひ確保してHackintoshしましょう。\n3225 (Intel HD Graphics 4000) \u0026lt;– iMac13,1 3330S (Intel HD Graphics 2500) \u0026lt;– iMac13,1 3470 (Intel HD Graphics 2500) \u0026lt;– iMac13,2 3470S (Intel HD Graphics 2500) \u0026lt;– iMac13,1, iMac13,2 3770 (Intel HD Graphics 4000) \u0026lt;– iMac13,2 3770S (Intel HD Graphics 4000) \u0026lt;– iMac13,1 4570 (Intel HD Graphics 4600) \u0026lt;– iMac14,2 4570S (Intel HD Graphics 4600) \u0026lt;– iMac14,1, 14,3 4570R (Intel Iris Pro Graphics 5200) \u0026lt;– iMac14,1, 14,3 4590 (Intel HD Graphics 4600) \u0026lt;– iMac15,1 4670 (Intel HD Graphics 4600) \u0026lt;– iMac14,2 4690 (Intel HD Graphics 4600) \u0026lt;– iMac15,1 4770S (Intel HD Graphics 4600) \u0026lt;– iMac14,1, 14,3 4771(Intel HD Graphics 4600) \u0026lt;– iMac14,2 4790K (Intel HD Graphics 4600) \u0026lt;– iMac15,1 5575R (Intel Iris Pro Graphics 6200) \u0026lt;– iMac16,1, 16,2 5675R (Intel Iris Pro Graphics 6200) \u0026lt;– iMac16,2 5775R (Intel Iris Pro Graphics 6200) \u0026lt;– iMac16,2 6500 (Intel HD Graphics 530) \u0026lt;– iMac17,1 6600 (Intel HD Graphics 530) \u0026lt;– iMac17,1 6700K (Intel HD Graphics 530) \u0026lt;– iMac17,1 7400 (Intel HD Graphics 630) \u0026lt;– iMac18,2 7500 (Intel HD Graphics 630) \u0026lt;– iMac18,2, iMac18,3 7600 (Intel HD Graphics 630) \u0026lt;– iMac18,3 7600K (Intel HD Graphics 630) \u0026lt;– iMac18,3 7700 (Intel HD Graphics 630) \u0026lt;– iMac18,2 7700K (Intel HD Graphics 630) \u0026lt;– iMac18,3 8100 (Intel UHD Graphics 630) \u0026lt;– iMac19,2 8100B (Intel UHD Graphics 630) \u0026lt;– Macmini8,1 8500 (Intel UHD Graphics 630) \u0026lt;– iMac19,2, iMac19,1 8500B (Intel UHD Graphics 630) \u0026lt;– Macmini8,1 8700 (Intel UHD Graphics 630) \u0026lt;– iMac19,2 8700B (Intel UHD Graphics 630) \u0026lt;– Macmini8,1 8600 (Intel UHD Graphics 630) \u0026lt;– iMac19,1 9600K (Intel UHD Graphics 630) \u0026lt;– iMac19,1 9900K (Intel UHD Graphics 630) \u0026lt;– iMac19,1 モバイルCPU モバイル用のCPUです。iGPUも併記しました。ノートPCのCPUがこの番号でしたら、ぜひHackintoshを試みたいところです。\n3210M (Intel HD Graphics 4000) \u0026lt;– Macmini6,1, 6,2, MacBookPro9,2, MacBookPro10,2 3230M (Intel HD Graphics 4000) \u0026lt;– MacBookPro10,2 3317U (Intel HD Graphics 4000) \u0026lt;– MacBookAir5,1 3367U (Intel HD Graphics 4000) \u0026lt;– MacBookAir5,1 3427U (Intel HD Graphics 4000) \u0026lt;– MacBookAir5,2 3450QM (Intel HD Graphics 4000) \u0026lt;– MacBookPro10,2 3520M (Intel HD Graphics 4000) \u0026lt;– MacBookPro9,2, MacBookPro10,2 3615QM (Intel HD Graphics 4000) \u0026lt;– Macmini6,1, 6,2, MacBookPro9,1, MacBookPro10,1 3630QM (Intel HD Graphics 4000) \u0026lt;– MacBookPro10,1 3667U (Intel HD Graphics 4000) \u0026lt;– MacBookAir5,2 3720QM (Intel HD Graphics 4000) \u0026lt;– Macmini6,1, 6,2, MacBookPro9,1, MacBookPro10,1 3740QM (Intel HD Graphics 4000) \u0026lt;– MacBookPro10,1 3820QM (Intel HD Graphics 4000) \u0026lt;– MacBookPro10,1 3840QM (Intel HD Graphics 4000) \u0026lt;– MacBookPro10,1 3890QM (Intel HD Graphics 4000) \u0026lt;– MacBookPro9,1 4250U (Intel HD Graphics 5000) \u0026lt;– MacBookAir6,1, 6,2 4258U (Intel Iris 5100) \u0026lt;– MacBookPro11,1 4260U (Intel HD Graphics 5000) \u0026lt;– Macmini7,1, MacBookAir6,1, 6,2, iMac14,4 4278U (Intel HD Graphics 5100) \u0026lt;– Macmini7,1, MacBookPro11,1 4288U (Intel Iris 5100) \u0026lt;– MacBookPro11,1 4308U (Intel HD Graphics 5100) \u0026lt;– Macmini7,1, MacBookPro11,1 4558U (Intel Iris 5100) \u0026lt;– MacBookPro11,1 4578U (Intel HD Graphics 5000, 5100) \u0026lt;– Macmini7,1, MacBookPro11,1 4650U (Intel HD Graphics 5000) \u0026lt;– MacBookAir6,1, 6,2 4750HQ (Intel Iris Pro 5200) \u0026lt;– MacBookPro11,2, 11,3, 11,4 4770HQ (Intel Iris Pro 5200) \u0026lt;– MacBookPro11,2, 11,3, 11,4 4850HQ (Intel Iris Pro 5200) \u0026lt;– MacBookPro11,2, 11,3, 11,4 4870HQ (Intel Iris Pro 5200) \u0026lt;– MacBookPro11,2, 11,3, 11,4 4960HQ (Intel Iris Pro 5200) \u0026lt;– MacBookPro11,2, 11,3, 11,4 4980HQ (Intel Iris Pro 5200) \u0026lt;– MacBookPro11,2, 11,3, 11,4 5250U (Intel HD Graphics 6000) \u0026lt;– MacBookAir7,1, 7,2, iMac16,1, 16,2 5257U (Intel Iris Graphics 6100) \u0026lt;– MacBookPro12,1 5287U (Intel Iris Graphics 6100) \u0026lt;– MacBookPro12,1 5350U (Intel HD Graphics 6000) \u0026lt;– MacBookAir7,1, 7,2 5557U (Intel Iris Graphics 6100) \u0026lt;– MacBookPro12,1 5650U (Intel HD Graphics 6000) \u0026lt;– MacBookAir7,1, 7,2 6267U (Intel Iris Graphics 550) \u0026lt;– MacBookPro13,2 6287U (Intel Iris Graphics 550) \u0026lt;– MacBookPro13,2 6360U (Intel Iris Graphics 540) \u0026lt;– MacBookPro13,1 6660U (Intel Iris Graphics 540) \u0026lt;– MacBookPro13,1 6567U (Intel Iris Graphics 550) \u0026lt;– MacBookPro13,2 6700HQ (Intel HD Graphics 530) \u0026lt;– MacBookPro13,3 6820HQ (Intel HD Graphics 530) \u0026lt;– MacBookPro13,3 6920HQ (Intel HD Graphics 530) \u0026lt;– MacBookPro13,3 7267U (Intel Iris Plus Graphics 650) \u0026lt;– MacBookPro14,2 7287U (Intel Iris Plus Graphics 650) \u0026lt;– MacBookPro14,2 7360U (Intel Iris Plus Graphics 640) \u0026lt;– MacBookPro14,1, iMac18,1 7567U (Intel Iris Plus Graphics 650) \u0026lt;– MacBookPro14,2 7660U (Intel Iris Plus Graphics 640) \u0026lt;– MacBookPro14,1 7700HQ (Intel HD Graphics 630) \u0026lt;– MacBookPro14,3 7820HQ (Intel HD Graphics 630) \u0026lt;– MacBookPro14,3 7920HQ (Intel HD Graphics 630) \u0026lt;– MacBookPro14,3 8210Y (Intel UHD Graphics 617) \u0026lt;– MacBookAir8,1, 8,2 8257U (Intel Iris Plus Graphics 645) \u0026lt;– MacBookPro 15,4 8259U (Intel Iris Plus Graphics 655) \u0026lt;– MacBookPro15,2 8279U (Intel Iris Plus Graphics 655) \u0026lt;– MacBookPro15,2 8557U (Intel Iris Plus Graphics 645) \u0026lt;– MacBookPro 15,4 8559U (Intel Iris Plus Graphics 655) \u0026lt;– MacBookPro15,2 8569U (Intel Iris Plus Graphics 655) \u0026lt;– MacBookPro15,2 8750H (Intel UHD Graphics 655) \u0026lt;– MacBookPro15,1, 15,3 8850H (Intel UHD Graphics 655) \u0026lt;– MacBookPro15,1, 15,3 8950HK (Intel UHD Graphics 655) \u0026lt;– MacBookPro15,1, 15,3 9750H (Intel UHD Graphics 630) \u0026lt;– MacBookPro 15,3 9880H (Intel UHD Graphics 630) \u0026lt;– MacBookPro 15,3 9980HK (Intel UHD Graphics 630) \u0026lt;– MacBookPro 15,3 ","date":"2019-09-20T19:23:10+09:00","image":"/uploads/2017/10/20171029113120.png","permalink":"/posts/6543/","title":"Macに搭載されたCPU"},{"content":"FenviのWiFi/Bluetooth PCIe拡張カードを入手しました。FV-T919という型番です。これに搭載された無線モジュールBCM94360CD はMac Pro 2013などで使用されているので、macOSと互換性が高く、OOBで問題なく動きます。\nFenviのFV-T919を発注 Fenviというメーカが、Broadcomの無線モジュールであるBCM94360CDを使用したWiFi/Bluetoothアダプタを作ってます。PCIe拡張スロット (PCIe x 1) に挿して使用する拡張カードです。BCM94360CDはMac Pro 2013などで使用されている最上位モデル無線モジュールで、macOSとの互換性が高いです。取り付けただけで問題なく動き、iOSとのContinuity関係の機能も動作します。\n最近のMacのWiFi/Bluetoothは、無線モジュール方式ではなくなって、マザーボードに直接組み込まれています。BCM94360CDは、自作ユーザが使える純正モジュールとしては、最後の世代です。BCM94360CDのようなBroadcomのmacOS用無線モジュールは、単体でも販売されていて入手可能です。おそらくは中古取り外しパーツや補修部品が流通しているのだと思われます。でも生産は終了していると思います。将来にわたって入手できる保証はありませんので、市場にあるうちに確保しておくのが良いと思います。\nHackintoshのパーツ選び 【その4：無線編】\n上の記事で紹介したように、BCM94360CDは単体で入手可能です。BCM94360CDのコネクタからはPCIeとUSBが出ているのですが、規格が特殊です。これをPCIeスロット、mini PCIe, M.2などに接続するためには、変換アダプタが必要です。アダプタはAmazon, eBay, AliExpressなどで多数販売されています。また、BCM94360CDとPCIeアダプタをセットにした商品もいくつかあります。FenviのFV-T919もその一つです。ただ、下の写真で示すように、製品としての見た目が良く、完成度が高い印象があります。tonymacx86のパーツガイドでも長らく推奨されていました。最近、AliExpressで継続して販売されている様子でしたので、一台を確保しました。\n届いたので開封する 発注から2-3週間して送料無料（送料込み）でシンガポールから届きました。エアキャップ緩衝材付き封筒を開けると、光沢カラー印刷された綺麗なボール紙外箱が入っていました。こんな感じの外箱です。\nこちらは箱の裏です。輸送の途中で、箱の裏がへこんでいましたが製品には影響ありませんでした。macOS対応と書いてあります。\n箱を開けると、中には、本体、アンテナ4本、USBケーブル、PCIeスロット取り付けネジ、カラー印刷の取扱説明書、CR-ROMが入っています。Hackintoshで使うWiFi/Bluetooth PCIeアダプタは大抵はそっけない本体だけの部品が届くのが普通ですが、これは一般消費者向け商品の体裁を保っています。\nカード本体に、USB接続ケーブルを取り付けた様子です。アンテナ端子には、キャップもついています。カードの見た目で特徴的なのは、無線モジュールを覆う派手なFenviの金属カバーです。\nこの金属カバーは回路の接地に接続されて電磁シールドの役を果たしています。商品webページによると、このカバーと無線モジュールの間には、熱伝導シートが挟まれていて、放熱にも役立っているようです。カバーを外せば、Broadcom BCM94360CDが入っているはずですが、カバーは裏側4箇所で半田付け止めしてあるようです。半田を溶かして、シールドカバーを外して中を確認したい気もしましたが、やめておきました。\nこの手の無線モジュールは、電磁シールドして使うのが本来の使い方のようです。なので、Fenviの派手なカバーは伊達ではないと思います。アンテナ線はこのカバーの中で無線モジュールのアンテナ端子に接続されていると思われます。カバー部分からPCIeスロット側のアンテナまでは、プリント配線されています。アンテナ線が露出せず、カバー内部に格納されているので、見た目がすっきりしています。また、アンテナ線やコネクタに触れたり引っ張ったりして、線が外れるトラブルがない点も良いと思います。\nマニュアルとCDROM 箱の一番底に、マニュアルとCDROMが入っていました。\n付属しているマニュアルを広げると、レターサイズ1枚もの印刷物でした。表裏で英語・中国語の説明が入ったイラストがカラー印刷されていて、簡単な取り付け手順が書かれています。実際のカードとイラストでは、形状、コネクタ、付属品が多少違います。例えばイラストはアンテナ2本のモデルになっています。またロープロファイルのパネルも描かれていますが、付属していませんでした。アンテナ4本ではロープロファイルは無理なので仕方ないです。説明書としてはわかりやすいです。\nCDROMには、94360cd.rarというファイルが一つ入っているだけです。この名前からしてBCM94360CDが搭載されていることが推測できます。rarファイルを伸張すると、Windows 7/8/10用のドライバと、インストール方法をごく簡単に書いたテキストファイルが入っていました。macOSには不要のCDROMでした。\n取り付けて動作確認 OOBで動く 取り付けは、他のPCIe無線アダプタと同じく、PCIeに挿して、アダプタからのUSBケーブルをマザーボード上の内部配線用USB 2.0コネクタに接続するだけです。こちらで紹介したMSI B360M Mortar Titaniumに9600Kを搭載したマシンに取り付けました。これ以外のハードウェア構成でも問題なく動くはずです。\nMSI B360M MORTAR TITANIUM, 9600K\n取り付けたところ、kext類やconfig.plistの設定は一切不要で、Wifi/Bluetooth両方ともOOBで機能しました。\nContinuityとスリープ iOSとのContinuityなども機能していて、Apple Watchを利用してのロック解除も可能でした。MSIのBIOSから、Wake Up Event Setupを選び、Wake Up Event By BIOSに設定し、Resume By USB Device, Wake from Sleepを有効にしたところ、スリープが正常に機能し、CPUファンや マザボのLEDが停止し、スリープ状態が保たれました。スリープからは、Bluetoothキーボード、トラックパッド操作で復帰させることもできました。ただ、すべてのマザーボードでも同じようにスリープが機能するかどうかはわかりません。また、すぐに目覚めてしまうことも時々あるようです。Power Napやネットワークアクセスによる解除などを有効にしているので、それらの関係かと思います。\nモジュールの確認 シールドカバーを外して内部を確認することはしませんでしたが、販売サイトで説明されている通り、中身はBroadcom BCM94360CDだと思われます。手元には、Macで使われるBroadcom BCM94360CDモジュールをPCIeアダプタに取り付けたカードがあります。これを取り付けて、システム環境設定からUSBデバイスを確認すると、BluetoothモジュールのIDや仕様が確認できます。その全ての情報が、Fenvi FV-T919と一致していたので、まちがいなく同じハードウェアです。\nまとめと補足 AliExpressでFenviのFV-T919というWiFi/Bluetooth PCIeカードを入手して使ってみました。Broadcom BCM94360CDを搭載しているようで、macOSでOOBで機能しました。アンテナ配線がすっきりしていて使いやすいカードだと思います。\nこの製品の外箱の裏にも、カードの裏のラベルにも、macOSに対応していることが書かれています。AliExpressの販売サイトを見ても、Hackintoshをターゲットにしていることがわかります。macOSをサポート対象にしてくれているので多少安心です。ただ、販売サイトには、macOS 10.12でBluetoothが動かないことが書かれています。BCM94360CDがSierraで動かないという情報は聞いたことがなかったので謎です。Sierraでも動く気がしますが、限られた条件で不具合のクレームがあったのかもしれません。10.12での使用を考えている場合は、一応注意した方が良いかもしれません。\n追記：国内でも調達可能 記事ではAliExpressのリンクを紹介しましたが、最近ではAmazonでも売っているようです。\n","date":"2019-09-12T20:46:23+09:00","image":"/uploads/2019/09/IMG_1325.jpg","permalink":"/posts/6476/","title":"WiFi/BluetoothアダプタFenvi FV-T919"},{"content":"スリープするとすぐに目覚めてしまうマシンがありました。ずっと諦めていたのですがようやく原因がわかりました。5インチベイに取り付けたUSBハブでした。取り外したら正しくスリープし続けるようになりました。\nスリープからすぐに目覚める こちらで紹介したコンピュータ（ASUSのZ390チップセットマザーボードを使用）が、ここのところずっと、スリープからすぐに目覚めてしまう問題を抱えていました。一旦はスリープに入るのですが、2~3秒で目覚めてしまいます。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\n上の記事を書いた時点では、ケースに入れない状態で仮組をして動かしていたのですが、その時は正しくスリープしていました。ケースに入れて、本格的に使用し始めたら、スリープからすぐに目覚める現象が発生しました。pmset -gなどで目覚める原因を調べると、色々なデーモンがスリープを解除したと表示されて、またiCloudやDropboxの同期がずっと動いて、ドライブへのアクセスが続いていたので、環境構築過程の一時的な状況だと思っていました。\nでもよく思い出してみたら、このマザボの先代のMSIのマザーボードでも同様にスリープから目覚める問題がありました。6年くらい前から引きずっていた問題でした。MSIマザーボードでは、BIOSメニューからOSからスリープ復帰しないという設定をして、電源ボタンでスリープ復帰していました。新しいASUSのBIOSでは同様な設定項目が見つからなくて、回避できません。そこで本格的に原因究明することにしました。\n目覚めのきっかけ スリープから目覚める原因には色々なものがあります。電源遮断するのではなくスリープすることの目的は、すぐに目覚めて動作再開することです。ですから、いろんなきっかけで目覚める事自体は正しい動作と言えます。\n目覚めのきっかけは、大きく分けて2通りに分類できると思います。一つはOSのデーモンが引き起こす目覚めです。Power Napなどは代表的なものです。iCloud関連の同期や、Spot Lightの索引作成作業もスリープを妨げるようです。実際の仕組みは、RTCを目覚まし時計のように使って、デーモンが一定時間間隔で動作しているものと思われます。もう一つは入出力関係の信号変化です。キーボードを押すとスリープ復帰しますが、これはUSBに信号が来ることがきっかけです。他にも、ネットワーク, SATA, ディスプレイなどからの信号でスリープ復帰することもあります。\n目覚める原因を調べる macOSで設定する 目覚めの原因になりそうな要素を取り除いていくことで、原因究明できると考えました。\nまずは「システム環境設定」の「省エネルギー」で、「ネットワークアクセスによるスリープ解除」「Power Napを有効にする」のチェックを外します。また、「Bluetooth」の「詳細設定…」で、「Bluetoothデバイスでコンピュータのスリープ解除を可能にする」のチェックも外します。これで、一般ユーザ向けのmacOS設定でできることをやり尽くしたはずです。でもスリープからすぐに復帰する問題は解決しませんでした。\nネットワークは問題なし 不本意なスリープ復帰は、ネットワークがらみで発生することも多いようです。そこで、まずはLANケーブルを取り外し、WiFiをoffにしました。これでネットワークからの働きかけで目覚める事はなくなると思いました。でも、スリープからすぐに復帰してしまいました。\nUSBとBluetoothを調べる 次に、バックパネルのUSBケーブルを全部外しました。これでもすぐに復帰します。Apple純正Magic Trackpad/KeyboardをBluetooth接続しているのですが、BTもoffにしてみました。その代わりに前回ご紹介した非Bluetooth接続の無線キーボードを取り付けました。それでもすぐに復帰します。OSでBTをoffにするのでは生ぬるいのかもしれないと考えて、BTアダプタが接続されているUSBポートをoffにしました。本当はケースの蓋を開けてコネクタを外すのが確実だったのですが、面倒だったので、まずはUSBInjectAll.kextの機能を使いました。config.plistのブートオプションに、以下を追加しました。BTはHS13に接続しているからです。これで13番目のUSB 2.0ポートが無効になります。するとスリープし続けるようになりました！\nuia_exclude=HS13 どうもHS13に接続されている何かが問題のようです。ここには純正BTアダプタのBroadcom BCM94360CDが接続されています。macOSと高い互換性のあるアダプタでOOBで動くはずのものです。ここでようやく、ケースの蓋を開けてBCM94360CDのUSB接続を外しました。そしてuia_excludeの設定を削除してもと通りに戻しました。なんとスリープからすぐに復帰する現象が再発するようになりました。ということで、HS13が原因であるものの、これに接続したBTモジュールの問題ではなかったようです。\n原因は5インチベイI/Oパネル 実は、ASUSのこのマザーボードでは、HS13はマザーボード内部のUSBハブに接続され4本に分岐します。これらはマザーボード上の4個のUSB 2.0ピンに接続されています。取扱説明書の図を以下に引用します。USB_E12とUSB_E34が、HS13から分岐したUSB 2.0ピンです。\nそのうち1個 (USB_E34のうちの1つ) がBTアダプタに接続されていて、今はそれを外したところです。残りのUSB 2.0ピンのうち、2個 (USB_E12) は、実は5インチベイに取り付けたUSBハブ＋SDカードリーダーに接続していました。もう販売中止になっているこの製品です。これを買ったのがちょうど6年前でした。スリープが解除される現象が発生した頃です。\nこの5インチベイパネルには、USB 3.1 gen1ポートとUSB 2.0ポートがぞれぞれ4個あります。またUSB 3.1 gen1接続のSDカードリーダが搭載されています。このうちのUSB 2.0ポートをHS13 (USB_E12) に接続していました。そこで、マザーボードからこの5インチベイパネルへの接続を外してみました。するとスリープからすぐに復帰してしまう現象は治まりました。5インチベイアダプタの中にあるUSB 2.0ハブが、スリープ直後になんらかの信号（ノイズ？）を出して、スリープを妨げているようです。USB 3.1の接続には問題ないようなので、USB 3.1ポートとSDカードリーダは引き続き使用できます。でもUSB 2.0のポートは諦めました。\nまとめ スリープからすぐに目覚めてしまう原因はUSBハブでした。pmsetコマンドやDSDTファイルを駆使して高度な技術で解決するのだと意気込んでいたのですが、あっけない結末でした。USB機器は、スリープ設定でトラブルの原因になりがちな気がします。以前にも、USBスピーカーが原因でスリープしないことがありました。スリープ開始でUSBスピーカへの供給電源が遮断されることで、USB信号線に何らかの信号（ノイズ？）が出るようで、これが引き金でスリープを妨げていました。その時は、外部電源からUSB電力を供給し続けるタイプのUSBハブを調達して、これを介して接続したところスリープするようになりました。何らかの入力によってスリープが復帰される状況自体は、ソフトウェアとしては正しい動作です。なので、機器を取り外して様子を見るという単純なアプローチが有効なようです。\n","date":"2019-09-07T20:51:21+09:00","image":"/uploads/2019/05/enegysavericon.png","permalink":"/posts/6393/","title":"USB機器がスリープを阻害することがあります"},{"content":"macOSの操作には純正キーボードとトラックパッドがお勧めです。しかしBluetooth (BT) 接続なので、OS起動前段階のBIOSやCloverの操作で使えないことがあります。なので非常用に非BT方式のトラックパッド付き無線キーボードを調達しました。\nBIOSとCloverの設定 macOSが起動する前段階で、BIOS (UEFI) の設定を変えたい、Cloverの設定を変えたい、EFI Shellを使いたいなど、キーボードを使いたい場面は多いです。ポインティングデバイスも使いたいかもしれません。そこで、macOS起動前に使用する入力装置の選択肢について考えてみます。\nBluetooth HID Proxy 以前に紹介したように、macOSの操作には純正キーボードとトラックパッドがお勧めです。特にトラックパッドで実現できるマルチタッチジェスチャは便利で、これなしでは使いやすさが売りのmacOSが台無しです。\nMagic Trackpad 2は良いです\n純正のトラックパッドを使うなら、キーボードもデザイン統一された純正BTキーボードを使うことになります。でもOS起動前にBluetoothキーボードを使用しようとしても動作しない場合があります。というのはBTを制御するプログラムはOSのドライバとして提供されているからです。OSの指示でペアリングをしてデータ通信を確立しています。なのでOSが起動する前の段階ではBluetoothドライバは使用できないのです。\nそれでは不便だということで、HID Proxyという機能が用意されています。BT入力機器と簡易的にペアリングをして、HID（Human Interface Device, 具体的にはマウスやキーボードのこと）として機能させる仕組みです。本物のMacでも、macOS起動前に、オプションキー組み合わせでNVRAMをクリアしたり、起動ドライブが選択できます。これはHID Proxyのおかげです。この機能はBluetooth受信機に組み込まれているものなので、対応していない受信機もあります。Broadcom製の純正BTアダプタは対応しています。なので、HackintoshでもApple純正BTキーボードでBIOS/Cloverの設定を行うことが可能です。\nMagic KeyboardをUSB接続 とはいえ、HID Proxyは時々失敗します。特にBIOS設定画面に入れないことがあります。マシンが起動直後なので、HID Proxyの準備が間に合わないのが原因ではないかと想像しています。キーボードが接続されていないという警告をBIOS起動画面が表示する場合は、HID Proxyが動いていないと考えて良いです。\n最新モデルのMagic KeyboardとMagic TrackPad 2ならば、USBケーブルで有線接続することで、Bluetooth接続がキャンセルされて、通常のUSBキーボード／トラックパッドとして使用できます。ついでに充電できます。なのでHID Proxyがうまく動かない場合は、USBケーブルを用意してマシンに接続すれば良いです。USB接続なら確実です。\n話が逸れますが、USBキーボードもBIOS設定に使えなかった時期がありました。PS/2キーボードからUSBキーボードへの移行直後のしばらくの間は、USBキーボードではBIOS設定できませんでした。当時はBIOSがUSBキーボードに対応してなかったためです。なので通常はUSBキーボードを使いつつ、BIOS設定のためにPS/2キーボードが手放せませんでした。\n起動前作業用のキーボード いっそのこと、OS起動前作業専用のキーボードを用意しておくのも良いと思います。ただ、有線USBキーボードは接続に手間がかかります。有線キーボードを用意するなら、Magic KeyboardとUSBケーブルの組み合わせの方が便利です。なので、用意するなら非Bluetooth接続の無線キーボードが良いと思います。非BT接続ならば、USBドングル（コネクターに挿す小さなアダプタ）がペアリングからデータ転送までの全て面倒を見てくれます。マザーボードからはUSB有線キーボードが接続されているかのように見えます。なのでOS起動前の作業に何の支障もありません。たくさんのWindows向けの無線キーボードが、手頃な価格で売られています。これらのUSB受信機ドングルをマシンに常時接続しておいて、BIOS/Clover設定したい時だけキーボードを取り出して電源を入れれば良いと思います。\n価格以外にWindows向けのキーボードを使用するメリットがもう一つあります。それはdeleteキーが使えることです。BIOS画面を呼び出すキーとして、昔からdeleteキーが使われてきました。最近ではdeleteキーの他に、ファンクションキーでもBIOS画面を呼び出せますが、メーカーによってキー対応が違います。起動時の短い時間では焦って思い出せないこともあります。deleteキーなら確実です。Appleのキーボードにもdeleteと書いたキーはありますが、実はあれはback spaceキーなので、BIOS画面呼び出しには使えません。\nAliExpressでキーボードを買う 独自規格の2.4GHz無線を使用したワイヤレスキーボードは多数販売されています。Amazonで探せば安価なものが見つかります。最近はタブレットPC用の製品も多いですが、それらはBluetooth方式なので、OS起動前作業には不向きです。独自の無線規格のものを選びます。また、トラックパッドやトラックボールのようなポインティングデバイスも一体化したキーボードが便利だと思います。BIOSでポインティングデバイスが使いたいこともありますし、互換性の低いBTアダプタを使う場合には、設定のために非BTのポインティングデバイスが必要になることがあります。\nこれは好みの問題なのですが、英語キーボードをずっと使っています。なのでJISキーボードじゃないUS配置のキーボードが欲しいと思いました。また、EFI Shellのような玄人向けのツールでは、しばしばUS配列が前提になっていることが多いです。パソコンはもともとUS発祥の技術ですので、ディープな作業をしようとするとUSキーボードが必要になります。ところが国内ではUSキーボードはなかなか入手できません。海外でも展開しているLogicool ( Logitec ) なども、国内ではJISキーボードしか販売していません。\nということでAliExpressを探してみました。海外サイトなのでUSキーボードが多数販売されています。ロシア語、スペイン語、UKなどのキーボードもあります。無線キーボードだけでなく、本格的なメカニカルキーボードの品揃えも多いので、うっかりキーボード沼にはまってしまいそうで危険です。それで選んだ製品は以下です。\n送料込みで$17くらいのタッチパネル（トラックパッド）付きキーボードです。格安ですが、問題なく動作しました。探してみたところ、日本のamazonでもそっくりなキーボードを売っていました。ちょっとだけ高いです。\n一体型なので、タイピングもポインティングも1台で行えるので便利です。に似た製品です。でも日本ではUS配列のK400が入手困難なのでありがたいです。プラスティック本体が安っぽいですが、K400でも同様なので仕方ないでしょう。K400に比べると、全部のキートップが標準サイズなので使いやすいです。キーボード部分のサイズは25cm x 14cmくらいです。Magic Keyboardとほぼ同じ大きさです。K400は単3電池ですが、この製品は単4電池です。電池の持ちは悪いのかもしれませんが、スリムで片付けやすいです。\nタッチパネル部分のサイズは7.2 x 7.2 cmくらいです。同じ製品らしい他の販売店のページには、macOSでタッチ操作が機能しないようなことが書いてありました。でもこれは純正のMagic Trackpadと同等では無いという意味のようです。1本指ポインティングはもちろん、2本指でのスクロール（純正のようにはスムーズではありません）や、2本指タッチでのコンテクストメニュー呼び出しなどは機能します。でもmacOSの多彩なマルチタッチジェスチャは使えません。macOSが起動したらMagic Trackpadに引き継ぐ非常用キーボードなので、単純なマウスとして動けば良いと考えました。\n格安海外物なので、日本の技適（技術基準適合証明）マークが無く、厳格には国内で使用してはいけません。でも、Bluetoothは3mくらい離れると動作しない微弱な電波で、おそらくはWiFiの電界強度の1/10以下です。そのうえ電子レンジやUSB 3.1 gen2のノイズだらけの2.4GHz帯なので、数メートルも離れたら測定不可能だと思います。使用時間もOS起動前の短時間ですので見逃してもらえたら嬉しいです。\n","date":"2019-09-04T19:45:28+09:00","image":"/uploads/2019/08/alikey.png","permalink":"/posts/6370/","title":"格安のトラックパッド付き無線キーボード"},{"content":"以下で紹介されていた記事の抄訳です。ちなみに原題の101というのは入門とか初級という程度の意味です。アメリカの大学で初学年向け授業の科目番号が100番台で、最初に履修すべき科目番号が101であることに由来しているらしいです。\nr/hackintosh - Power Management 101\nこれを読むとdarkwakeの設定は謎です。いろいろ検索すると、0はPower Napをしない、それ以外はするなど、多少分析しているページもありますが、試してみるしかないようです。また、sleepで再起動してしまうとか、sleepから復帰しないような重篤な状態には対処すべきですが、sleepからすぐ目覚めてしまう症状は、ある程度仕方ないような気がしています。\n（以下は上記ページの抄訳です）\nHackintoshが動いたら、次にはパワーマネジメントの設定をします。このガイドは、macOSがインストールできていて、安定して使用できていることを前提としています。まずはパワーマネジメントに関連したマシンの状態を説明します。\nShutdown: macOSが終了してハードウェアへの電源供給がoffになった状態です。新しいセッションを始めるためには、電源スイッチを押します。 Hibernate: macOS はセッションの内容をRAMからディスクに書き込み、RAMの内容を消去します。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はディスクに保存した状態へ復帰します。 Hybrid: macOS はセッションの内容をRAMからディスクに書き込み一方で、RAMの内容も保持します。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はRAMから読み込まれますが、スタンバイ中に電源が途絶えてRAMの情報が消えていた場合はディスクから読み込まれます。 Sleep: macOSはセッションをRAMに保持してディスクには書き込みません。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はRAMから読み込まれます。スタンバイ中に電源が途絶えてRAMの情報が消えていた場合は、元に復帰できないので、新規に起動します。 以下ではターミナルを使うことになります。高度な電力制御設定をしてくれるGUIツールはありません。また管理者のみが行える設定のために、sudoやsuコマンドも使います。以下の作業で使う一番重要なコマンドは、次のものです。\npmset -g assertions – パワー状態を邪魔した原因を簡潔に示します。 pmset -g log – logからパワー状態を詳細に示します。 電力管理設定を行う前に、configでdarkwake=0フラグを指定しておく必要があります。ここで=の後にyesやnoをつけては駄目です。0から10までの数字を指定します。そしてシステム環境設定を開いて以下の設定をします。\n省エネルギー \u0026gt; ・・・コンピュータを自動スリープさせない \u0026gt; （チェックする） 省エネルギー \u0026gt; 可能な場合はハードディスクをスリープさせる \u0026gt; （チェックする） 省エネルギー \u0026gt; ネットワークアクセスによるスリープ解除 \u0026gt; （チェックを外す） 省エネルギー \u0026gt; Start up automatically after power failure \u0026gt; （チェックを外す） 省エネルギー \u0026gt; Power Nap を有効にする\u0026gt; （チェックを外す） Bluetooth \u0026gt; 詳細設定 \u0026gt; Bluetoothデバイスでコンピュータのスリープ解除を可能にする \u0026gt; （チェックを外す） スリープした後で、オーディオが動かなくなる場合があります。その時は、最初にAppleALCを試してみます。次にCloverオプションのAFGLowPowerStateを使ってみます。どちらも駄目で、まだCodecCommanderを入れてなければ、これが役立つかもしれません。Darkwakeは後で扱うことにして、ここでは簡単な部分を手がけます。\nこの記事の最初に示したスリープの状態から、どれを使うかをまずは決めます。もし電源喪失が心配ならば、3を使います。私は安心のために3を使っています。（訳注：デスクトップの場合は0で良いと思います。）\nhibernatemode=0 – デスクトップのデフォルト。基本的なスリープ（訳注：手元の10.14.6 19G95ではiMac19,1でもデフォルトが3でした。） hibernatemode=3 – ラップトップのデフォルト。ハイブリッドと呼ばれている。 hibernatemode=25 – pmsetからのみ設定可能。伝統的なHibernate。 どれを使用するか決めたら、それを指定します。でも、この変更を有効にする電源状況も指定することになります。pmsetコマンドは、いくつかのタイプの電源に対して設定できて、それらは-a, -b, -c, -uで指定します。\n-a 全ての電源を対象にする -b バッテリー電源を対象にする -c 充電器を対象にする -u UPS電源を対象にする ラップトップに対しては、-a, -b, -cのいずれかを選びます。デスクトップには-a, -uを選びます。例えば以下のようにします。. 必要ならば、それぞれの電源条件に対して、違う設定をします。デスクトップに対しては、-aまたは-uを指定します。私が使用している設定例は以下です。\npmset -a hibernatemode 3 個人的には、デスクトップには3か25を推薦します（訳注：0でも良いと思います）。ラップトップを使うなら、既に設定してある数値で良いですが、変更もできます。\nスリープ時にはセッションが常にRAMに保存されます。これにより素早く復帰できます。そこでdarkwakeの設定が重要になります。darkwakeはPower Napに関係します。Power Napはスリープ中にのみ機能します。そのプロセスは、トラブルを引き起こしやすいです。一連のエラーにより、スリープが機能しなくなり、時にはカーネルパニックを引き起こします。残念ながらdarkwakeで指定する値に関する資料はどこにもありません。他の人たちと同様に、一つずつの値を、正しく動くまで試してみるしかありません。私がみるところでは、多くの人たちはdarkwake=8かdarkwake=9が最良であると言っています。私自身は、darkwake=8を使っています。darkwake=1を使う人も多いです。（訳注：コメントで教えていただきましたが、こちらに参考になりそうな説明があります。また、darkwakeの8と10はCatalinaでは使われなくなったらしいです。）\nこの記事の最初に示した2つのコマンドで、スリープのデバッグができます。以下は、知っておくべき項目の一部です。\nWake from Normal Sleep [CDNVA] due to XDCI XHC/UserActivity Assertion: Using AC (Charge:0%) – これはスリープからの正常な復帰です。私のデスクトップマシンでは、キーボードを押すとスリープから目覚めます。 Kernel Idle sleep preventers: – カーネルがスリープを中断した理由が 部分で説明されています。Noneであるのが理想です。 Wake reason: – スリープ直後にすぐに電源が復活してしまう場合、この部分を見てください。最も一般的なは、GLAN (internet)とXHCI (usb)です。 もしXHCIが問題を引き起こしているならば、USB SSDTを作って、不要なハードウェアを除去しておくと良いです。これは重要ですが初心者にはわかりにくいです。SSDTを作ることは、難しそうですがそうではありません。電力設定を正しく行いたいならば、避けては通れません。電力設定以外にも、デバイス接続の問題も解決します。もしコンピュータがGLANによってスリープ復帰しているなら、（訳注：Wake on Lanの）マジックパケット、またはEthernetからの復帰設定を、BIOSで無効にすべきです。これはバニラなインストールガイドにも書かれている項目です。OSの中でも無効にできます。最後にCloverインストーラにも、Ethernetを目覚めさせてしまうSleep Proxy Client (mDNSResponder)を無効にするRCスクリプトがあります。\nこれで、Power Napを有効にできて、ディスプレイをoffにした時に自動的にコンピュータをスリープにする、スリープの設定ができます。電力設定は以下のコマンドで確認できます。\npmset -g live. （私が公開するテキスト情報はCC BY-NC-SA 4.0 ライセンスに準拠します。）\n","date":"2019-08-31T18:17:13+09:00","image":"/uploads/2019/05/enegysavericon.png","permalink":"/posts/5107/","title":"パワーマネジメント入門"},{"content":"この記事は、以下の古い記事のv.3対応改訂版です。\nワンクリックで最新kextに〜Kext Updater.app (Ver. 2)\nHackintoshで使っているClover, EFIドライバ、kext類は、最新版を使うのが良いです。色々なバグが直されていて、安定しています。また常に最新にしておけば、macOSのバージョンアップにも対応できます。Catalinaに備えていつも最新状態にしておきたいものです。ただ、開発者の方々のページを巡回して最新版をチェックするのも大変です。\nHackintoshで使用中のkext類最新版をチェックして、新バージョンがあった場合にダウンロードしてくれる便利なツールがあります。ドイツのHackintoshフォーラムの人たちが作ってくれているKext Updaterです。以下から最新版が公開されています。\nこの記事ではVer. 3を紹介します。古い記事で紹介したVer. 2に比べてスッキリした画面構成になりました。\nボタンがいくつかあります。以下でそれぞれのボタンが提供する機能の説明をします。\nStart メインの機能です。「Start」ボタンを押すと、使用されているHackintoshのkextを全部調べ上げてくれて、それが最新版であるかどうか判断してくれます。最新版では無いkextは、自動的にダウンロードされて、デフォルトでは、デスクトップのKext-Updatesという名前のフォルダに入ります。このフォルダはフォルダーアイコンをクリックすると開けられます。そこで、必要ならば「EFI」ボタンを押してESPをマウントして、ダウンロードした最新版と入れ替えます。\nKexts 必要なkextを個別にダウンロードします。ソースコードのダウンロードもできます。また、更新があってもダウンロードしないkextの指定もできます。\nWebDriver nVidiaのグラフィックスドライバをダウンロードします。nVidiaドライバはMojaveから使えないのが残念です。この機能をボタンに割り当てているところに、開発者の皆さんがnVidia復活に期待している様子が伺えます。\nBootloader ブートローダーをダウンロードできます。CloverとOpenCoreから選べます。OpenCoreは、Kext Updaterと同じコミュニティの人たちが開発している様子なので、ここに含まれているのだと思われます。\nReport ハードウェアやインストールされたkext, efiドライバ類の一覧の情報を作ります。しばらく時間がかかります。kext類についての情報を得るためは、SIPで署名のないkextを許容する設定が必要です。config.plistのRtVariablesのCsrActiveConfigの下位ビットを1にします（例えば0x01）。シリアル番号などは自動的にゼロにしてくれます。このまま公開して、フォーラムで質問するときに使ってくださいという意図のようです。\nレポートファイルは、/tmp/kextupdater/の下にHTML形式で作成されます。情報取得が終了すると自動的に開くので、Safariなどのウィンドウで表示されます。\nTools 4種類のツールが使えます。どういう意図でこれらのツールが選ばれたのか少し謎です。いずれもちょっと微妙な機能です。\nkextキャッシュと権限修復 /System/Library/Extensionsと/Library/Extensionsにあるkextのファイル権限とkextキャッシュを作り直します。バニラなインストールをしている場合は、この機能を使うことは無いかと思います。\nAtherosの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を使った方が良いですね。\nSleep設定 sleepに問題がある場合、役立つかもしれませんと書かれた機能もあります。hibernationが0に設定されて、hibernation用のイメージファイルが作成されないように、書き込み禁止でサイズがゼロのファイルが作られるようです。これも押してみましたがあまり動作がわかりません。pmset -a hibernatemode = 0とタイプするのと同じことが起こるのかと思われます。\nESPをマウントする機能 ドライブを指定して、ESPをマウントしたりアンマウントできます。これは妥当な機能かなと思いました。\n","date":"2019-08-30T21:13:28+09:00","image":"/uploads/2018/07/20180625132658-300x300.png","permalink":"/posts/6371/","title":"ワンクリックで最新KEXTに〜Kext Updater.app (Ver. 3)"},{"content":"FileVaultを使うとファイルが全て暗号化されて、パスワードを知らない人は開けなくなります。OS標準組みなので面倒な設定や手順が不要です。以前はHackintoshで使えないと言われていましたが、最近では使えるようになってました。\nFileVault FileVaultはMac OS X 10.3で登場したシステム組み込みのディスク暗号化機能です。10.7でFileVault2になりました。ちなみにvaultというのは金庫室という意味です。Windowsにも標準機能でBitLockerというツールがあるようです。どちらも多分、同様な機能を提供するツールだと思います。\n今のパソコンOSはアカウントのパスワードで保護されているから、暗号化の必要性をあまり感じないかもしれません。でもアカウント／パスワードは、ネットワーク経由のアクセスには一応の役に立ちますが、コンピュータ本体を操作されるとひとたまりもありません。シングルユーザモードで起動したらなんでもできてしまいます。リカバリーボリュームで起動されても同じです。さらにはSSD/HDDを取り外して他のマシンでマウントしたら、全て読み書きできてしまいます。そんな場面でも、FileVaultで保護してあれば、パスワードが知られない限り、アクセスされる恐れはありません。FileVaultを施したSSDをマウントしようとすると、以下のように必ずパスワードを要求されるからです。\nFileVaultを使うと、読み書きに暗号化・復号化のオーバーヘッドがかかるために、ファイルアクセスが遅くなる欠点があります。そのため使っている人は少ないと思います。さらにHackintoshでは使えない、つまり、FileVaultを設定した途端に起動不可能になると長年言われていました。でも、最近ではFileVaultを使うためのEFIドライバーが充実しているようです。そこで、HackintoshでFileVaultを使ってみました。\nUSBメモリをFileVaultする 暗号化機能は、コンピュータやドライブを何処かに置き忘れたり、盗難にあったりした時に頼りになります。逆に、家から持ち出さないデスクトップコンピュータの場合、それほど必要ではないかもしれません。デスクトップコンピュータがメインのHackintoshユーザには、使わなくても良い機能かもしれないです。私もずっと使っていませんでした。\nでも、持ち歩くUSBドライブに対しては是非活用したいところです。他人の個人データが入ったUSBメモリーを電車の中にでも置き忘れたら、このご時世では大変な事案になってしまいます。暗号化されていれば安心です。非起動ディスクのFileVault化は、Hackintoshであっても面倒な準備不要です。USBメモリーをディスクユーティリティ.appでフォーマットする際に、「暗号化」と書かれたフォーマットを選択するだけです。これでHackintoshでも実機でも同様に使用することができます。\n起動ディスクをFileVaultにする さていよいよ本題です。Hackintoshの起動ディスクをFileVaultにするとどうなるでしょう？こちらで紹介したマシンに接続した起動可能SSDに対してFileVaultを有効にしてみました。起動ディスクをFileVaultにするには、macOS稼働中に「システム環境設定」「セキュリティとプライバシー」から「FileVault」タブを選択します。次にウィンドウ左下の鍵マークをクリックして、パスワードを入力し、「FileVaultをオンにする」ボタンを押します。\n次に、パスワードを忘れた時の対策を選択します。iCloudを使用する方法と、復旧キーをユーザが管理する方法を選択できます。復旧キーを選択した場合は、次のステップで表示される24文字のキーを記録しておく必要があります。\nこの後、バックグラウンドで暗号化処理が開始されます。起動ボリューム容量に依存しますが、インストールしたばかりのmacOSなら数分で暗号化されます。これで起動ディスクがFileVaultで保護されるようになります。\n本物のMacならこれで設定終了です。次に起動する場合も、FileVaultになった起動ディスクから何事もなく起動します。しかしHackintoshではそうはいきません。\nHackintoshでFileVaultから起動する 起動ボリュームが見えない FileVaultにした起動ボリュームは、Cloverの選択画面から消えてしまいます。\n下のスクリーンショットは、コンピュータに2個の起動可能なドライブである、2.5 inch SATA SSDと、M.2 SSDを取り付けた場合のボリューム選択画面です。左3個のリンゴマークがSATA SSDのボリュームで、右4個のリンゴマークがM.2 SSDです。ここでは、SATA SSDがFileVault化されていて、M.2 SSDは通常のドライブです。\n通常のドライブでは、右側のM.2 SSDの項目に現れているように、\nBoot FileVault Prebooter from Preboot Boot macOS Install Prebooter from preboot Boot macOS from XXXX （XXXXは起動ボリューム名） Boot Recovery from Recovery の4個の選択肢があります。起動ボリュームが、Boot macOS from XXXXという名前で見えています。一方で左側のFileVault化されたSATA SSDの項目には、\nBoot FileVault Prebooter from Preboot Boot macOS Install Prebooter from preboot Boot Recovery from Recovery の3個しかありません。通常の起動で使用するBoot macOS from XXXXというボリューム名の選択肢がなくなってしまっています。このボリュームがFileVaultで暗号化されたので、選択肢に現れなくなったのです。FileVaultになった起動ボリュームから起動するには、左端のBoot FileVault Prebooter from Prebootを選択します。preboot(er)という名前の通り、通常のブート手順に先立って処理を行うための選択肢です。ただ、FileVault用のefiドライバが入っていないと、この選択肢を選んだとしても、通常のブート手順に至る前に止まってしまいます。\nFileVaultのためのefiドライバを追加する Boot FileVault Prebooter from Prebootを選択して起動させるためには、FileVault用のefiドライバを入れておく必要があります。最近のCloverインストーラでは、efiドライバーが機能ごとに分類分けされています。分類カテゴリーに「FileVault 2 UEFI Drivers」があります。この中にあるefiドライバーを入れておけば起動できます。ここには6個のefiドライバーがあります。それぞれクリックすると、説明が出ます。それらは、\nAppleImageCodec.efi : FileVaultのためにPNGとBMPをデコードします。 AppleKeyAggregator.efi : FileVaultのためにブートUIダイアログをサポートします。 AppleKeyFeeder.efi : FileVaultで使うためにPS/2キーボードをサポートします。 AppleUITheme.efi : FileVaultのためにブート用UIテーマをサポートします。 FirmwareVolume.efi : FileVaultで使うポインター画像用のためにFirmwareVolumeを作ります。 HashServiceFix.efi : UEFI BIOSに含まれていない場合のためにhashフィックスをサポートします。 です。説明文を見ると、ダイアログの表示、イメージの表示、キーボードのサポートというように、ユーザインタフェースを実現する機能ばかりです。後でわかりますが、実はこのユーザインタフェース機能が重要なようです。実際、これらのefiが無い場合には、「ログインダイアログを開けなかった」というような内容のエラーが出て止まります。\n説明を見ると、全部は必要がないように思えます。例えば、PS/2キーボードを使わなければ、AppleKeyFeeder.efiは不要なような説明になっています。でも、このefiが無い場合、USBやBluetoothキーボードからの入力ができませんでした。他のドライバには、不要なものがあるかもしれませんが、とりあえずは、6個のドライバーの全部をCLOVER/drivers/UEFI/の中に入れることでFileVaultが機能しました。\nFileVaultから起動する これらのefiドライバーをCLOVER/drivers/UEFI/フォルダに入れた後、マシンを起動します。そして、上記で説明したように「Boot FileVault Prebooter from Preboot」を選択します。ちなみに「Boot macOS Install Prebooter from preboot」を選択すると途中で止まります。名前から推測すると、FileVaultの中のmacOSをインストール・アップデートするときに使う選択肢のように思えます。（ご存知の方いらしたらコメント欄で教えてください）。いずれにしてもここでは使いません。\n「Boot FileVault Prebooter from Preboot」から起動すると、すぐに通常のmacOSのログイン画面が出ます。ただ、実際のログイン画面と違って、解像度が低い画面でした。恐らくは、本物のログイン画面ではなく、Cloverが頑張って表示している画面なのかもしれません。ディスプレイドライバーが機能する前段階なので、解像度が低いと思われます。このログイン画面でアカウントを選択しパスワードを入力することで、起動ボリュームの復号化が行われます。-vオプションで様子を見ると、この後、通常の起動手順が開始されるようです。これで正常に起動し、通常通りのmacOS操作が可能でした。\nまとめ HackintoshでもFileVaultは不具合なく使用することができました。ただ、起動ドライブをFileVaultにした場合、Bluetoothキーボード／トラックパッドが認識されるまで多少時間がかかる様子もありました。また、Prebootから起動した後で、起動ボリュームの起動を行うので、起動時間は長くなります。Hackintoshに適したコンピュータは、置き忘れや盗難の危険性が少ないデスクトップコンピュータですので、Hackintoshの起動ドライブにFileVaultを設定する必要性は低いと思いました。\n一方で、ノートPCでHackintoshして外に持ち出している方は（あまりいらっしゃらないかもしれませんが）FileVaultを設定しておくと安心だと思います。またデスクトップユーザも、USBメモリーなどのリムーバブルドライブに対しては、FileVaultを活用すると良いと思います。起動ドライブ以外でしたら、実際のMacもHackintoshも同じようにFileVaultを利用できます。\n","date":"2019-08-22T23:01:31+09:00","image":"/uploads/2019/08/FileVaultIcon.png","permalink":"/posts/6256/","title":"HackintoshでFileVaultを使う"},{"content":"銀色のマザーボードMSI B360M Mortar Titaniumに6コア6スレッドのCore i5 9600Kを組み合わせたHackintoshです。実機27インチiMac 2019に搭載されている第9世代CPUと同じCPUなので互換性が高いと期待しました。\nハードウェア構成 マザーボード マザーボードはMSI B360M Mortar Titaniumです。以下で使ったものと同じマザーボードです。CPU以外の構成は変わっていません。マザーボードのBIOS設定もこの記事をご覧ください。\nMSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh\n300シリーズチップセットの白いマザーボードを使いたい場合は、選択肢がこれしかありません。B360は、Z390/H370と同じ世代の廉価版チップセットです。それでもこの世代から導入されたUSB 3.1 Gen2とWiFi MAC層をチップセットに内蔵しています。WiFiサポートはmacOSに恩恵ありませんし、このマザーボードにはWiFi搭載されていないので関係ないです。一方で、USB 3.1 Gen2は、実機でもチップセットのGen2を利用しているようなので、OOBで動きます。Z390/H370と比較して一番劣る機能はチップセット経由のPCIeレーン数が少ない（H370は20に対してB360は12レーン）ことです。でもグラフィックス用のCPU直結16レーンは別に用意されていますし、micro ATXならPCIeスロットが少ないので、十分かと思います。\nCPUアップグレード 上の記事では9100Fで作りましたが、メインで使うにはもう少し上位のCPUを使いたくなり、交換しました。ゲームも動画編集もしないので、9100Fでも全く問題のない性能だったのですが、ロマンです。コア数を増やす方向でロマンを追求することにしました。9100Fは4コアです。別に9900Kマシンがあるので、同じ8コアを2台使うのも面白みがないので6コアを目指すことにしました。第9世代 (Coffee Lake Refresh-S) CPUの品揃えが増えて、中位モデルの選択肢が広がっています。6コアだと9400F, 9400, 9500, 9600Kあたりが妥当なところと思います。特に9400Fは、9500と性能がほとんど変わらないのにお得な価格で人気です。でも、現在使用中の9100Fと比べるとクロックが下がります。シングルコアしか使わない状況だとむしろ性能低下する恐れもあります。9100Fのコスパとバランスはすごいと今更ながら思いました。\nCore i5 9600K ということで選んだのは、ちょっとお高めで、第9世代では古参のIntel(R) Core(TM) i5-9600K CPU @ 3.70GHzです。これならクロック数が9100Fとほぼ同等 (0.1GHzだけ高い) でコアが増えます。\nクロック数やコア数以外に、9600Kを選んだもう一つの理由は、実機の27インチiMacの上位モデルがこのCPUを採用していることです。実機で採用しているCPUを使用すると、互換性が高いメリットがあります。実機で使用されていないCPUであっても、仕様が近いモデルならば、多くの場合は動作します。それでも場合によってはconfig.plistの中でFakeCPUIDなどを設定して、macOSがサポートしているCPUに誤魔化す必要が生じます。また、実際の動作には支障はないのですが、「このMacについて」のCPU名が正しく表示されない場合もあります。iGPUのIDが違うと、これを実機に合わせる必要がある場合もあります。実機で搭載されているCPUと同一のCPUを選んでおけば、そのような手間は不要です。価格や性能に大きな違いがない候補で迷っているなら、実機で採用されているかどうかを基準に決めてしまうのも良いと思います。今回もそうしました。\nちなみに非BTO第9世代iMacが9700Kではなく9600Kを採用したのは、6コアであったのが理由だと思います。8コアCPU 9900K搭載の最上位BTOモデルを用意したので、通常モデルを6コアに差別化したかったところ、当時の第9世代にはこれしか選択肢がなかったのでしょう。\nそのほかのハードウェア グラフィックスはRadeon Vega 64です。（OOBで動作） WiFi/BluetoothはBCM94360CD（OOBで動作） ソフトウェア構成 OS, CLOVER, 機種ID 以下を使用しました。\nmacOS Mojave 10.14.6 (18G87) Clover v2.4k r5033 iMac19,1 BIOS設定 マザーボードのBIOS設定は、ほぼデフォルトのままです。色々な項目のデフォルト設定が、macOS向きの設定でした。PCIe接続のビデオカードを使用していますが、クイックルックなどを動かすためにiGPUも稼働する設定にしました。また、ブートするドライブをUEFI限定にして、MSIマザーボードの便利な機能GO2BIOSを有効にしました。GO2BIOSは電源スイッチ長押しでBIOS設定画面が現れる機能です。\nUEFIドライバ 以下を使用しています。以前のビルドではOsxAptioFix2Drv-free2000.efiを使っていましたが、slideパラメータを調節することで最新のAptioMemoryFix.efiが使えました。slideの設定はconfig.plistの項目で説明します。\nApfsDriverLoader.efi AptioMemoryFix.efi EmuVariableUefi.efi FSInject.efi VBoxHfs.efi VirtualSmc.efi Kext類 以下のkextをkexts/Otherに入れました。マザーボード搭載LANはインテル製なのでIntelMausiEthernet.kextを使います。AppleALCで音も出ました。HDMIからも音が出ます。\nWhateverGreen.kext VirtualSMC.kext USBInjectAll.kext Lilu.kext IntelMausiEthernet.kext AppleALC.kext Config.plist 他の第9世代CPUで使っているconfig.plistとほぼ同じです。MSIの最近のマザーボードはmacOSカーネルを読み込むためのメモリー確保で失敗することが多いです。そこで、強制的にメモリーを解放するOsxAptioFix2Drv-free2000.efiを使っていました。今回は、以下の記事で紹介した方式を採用しました。\nslideでカーネル読み込み番地を調整する (Clover編)\nBoot, Argumentsにslideオプションを設定して、使用中のメモリーを避けてメモリー確保するよう設定します。さらに、slide機能を使うためにSIP機能の一部を解除しました。RtVariables, CsrActiveConfigを0x40にしてあります。\n下は、SIPのNVRAM制限を解除する設定です。\n\u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x40\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; こちらはブートオプションです。slideは128に設定しました。とりあえず使わないUSB 2.0を指定して、暫定的に15個制限を解決しています。\n\u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;-v slide=128 uia_exclude=HS09;HS10;HS11;HS12;HS13;HS14;USR1;USR2\u0026lt;/string\u0026gt; 使用したconfig.plistを以下に置いておきます。\nconfig.plist for MSI B360M and 9600K - Pastebin.com\n動作確認 以上の設定で問題なく動きました。スリープも機能しているようです。CPUも正しく認識されているようです。\nsysctlコマンドでCPUの名前を見ると以下のようになります。\n$ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz Geekbenchのスコアは、シングルが約5900でマルチコア(6コア6スレッド)で約22000でした。以前測定した9100Fはシングル5298、マルチコア(4コア4スレッド)が14966でした。また9900Kはシングル6086, マルチコア(8コア16スレッド)で30114でした。9100Fと9900Kの中間くらいの性能であることがわかります。ちなみに、当たり前ですが、同じCPUを搭載した本物の27インチiMacのGeekbenchとほぼ同じスコアです。\n今後は、USBの15個制限に対する調整を進めたいと思います。\n","date":"2019-08-16T22:06:46+09:00","image":"/uploads/2019/06/product_6_20180402151821_5ac1d93dd6d06.png","permalink":"/posts/6191/","title":"MSI B360M MORTAR TITANIUM, 9600K"},{"content":"macOSが起動するときに、早い段階で禁止マークが出て停止してしまうことがあります。多くの場合、カーネルを読込むメモリが確保できないエラーです。これをslideオプションで解決します。\n追記：この記事はCloverを前提に書いてあります。OpenCoreに関してはこちらをご覧ください。またコメントいただいたように、CloverにOpenCoreのツールを流用して対応することも可能なようです。\nカーネル読み込みメモリ空間を確保する (OpenCore編)\n症状 禁止マークが出て早々に起動停止してしまう場合に、-vオプションで起動すると、”Error Allocating xxxx pages at xxxxxxxx”というようなメッセージが出ていることがあります。例えば下のメッセージは、「0xe590000番地から0x11c01ページのメモリー空間を確保しようとしたけど失敗しました」という意味です。1ページは0x1000バイト、つまり4096バイトのことです。10進数を使ってわかりやすく書くと、「240メガバイトあたりの番地から298メガバイトくらいのメモリー空間を確保しようとしたけど失敗しました」といった感じのエラーです。100番台になってからのMSIマザーボードでよく発生するエラーです。\nこのエラーの特徴は、「何回か起動を試みるとそのうち成功することがある」とか、「大抵は起動するけどたまにこのエラーで起動しない」など、再現性が低いことです。\n簡単な対策法 この問題を直してくれるのが以下のefiドライバです。\nAptioMemoryFix.efi OsxAptioFix3Drv.efi OsxAptioFixDrv.efi OsxAptioFix2Drv-free2000.efi 以下の記事で説明したように、このリストの順番がお勧め順らしいので、上から試して、問題なく起動するefiドライバを使います。一度に2個以上のefiドライバを入れてしまうと、どちらが動くのか定まらないので避けるべきとのことです。\nCloverで使うEFIドライバ\nリストの上の方ほど新しく開発されたefiドライバで副作用が少ないらしいです。一番強力なのが最後のOsxAptioFix2Drv-free2000.efiです。その名前の通りメモリーを強制的に開放させます。どのマザーボードでもほぼ機能する最強のefiドライバです。でも強力すぎるので、大丈夫なのかという意見はあります。Redditには、OsxAptioFix2Drv-free2000.efiの利用は避けて、slideオプションで対応した方が良いという意見もありました。とはいえ、私もMSIのマザーボードでOsxAptioFix2Drv-free2000.efiを使い続けていますが、特に問題はありません。でもせっかくですので、slideを使った正しい解決策を試してみます。\nカーネル読込に失敗する理由 KASLR (カーネル番地乱数化) そもそもどういうことが原因で、カーネル読み込みに失敗するのかを調べました。macOSが起動する際に、カーネルが0x100000以降の番地（10進数で1,048,576、1MB程度です）のメモリーに読み込まれます。実際に何番地に読み込まれるかは定まってなく、ランダムです。上記のエラーの例では、カーネル（またはその一部）を0xe590000番地から始まるメモリー空間に読み込もうとして失敗しています。読み込み番地はセキュリティのためにわざとランダムにしているそうです。この仕組みを、KASLR (Kernel Address Space Location Randomization: カーネル番地空間場所乱数化) というらしいです。カーネルが読み込まれる番地が常に一定だと、その番地を狙って悪さを試みるマルウェアが可能です。特定の番地からプログラムを動かしたり、特定の番地の内容を書き換えることでOS動作を操れてしまうからです。そういう操作をされないために、起動毎に違う番地にカーネルを読み込んでいるそうです。\n失敗しないマザーボード 以下で説明した方法で、UEFIシェルを起動すると、\n起動しないマシンをUEFI Shellで救う\nマザーボードのメモリーマップを見ることができます。これに使うコマンドがmemmapです。memmap -bとすると画面いっぱいになったところで一旦停止してくれます。また、fs0:などでドライブを指定して、必要ならばcdコマンドで適当なディレクトリに移動した後、memmap \u0026gt; memmap.txt などとタイプすると、その場所にメモリーマップをテキストファイルで保存します。\nAptioMemoryFix.efiなどの穏当なドライバで問題なく起動するマザーボードもたくさんあります。そのメモリーマップを見てみましょう。以下は、ASUSのZ390マザーボードの例です。（memmapの出力にはAttributesという項目もありますが、長くなるので省略してます。）\nType Start End # Pages RT_Data 0000000000000000-0000000000000FFF 0000000000000001 Available 0000000000001000-000000000008FFFF 000000000000008F RT_Code 0000000000090000-0000000000090FFF 0000000000000001 Available 0000000000091000-000000000009EFFF 000000000000000E Reserved 000000000009F000-000000000009FFFF 0000000000000001 Available 0000000000100000-000000005315CFFF 000000000005305D BS_Data 000000005315D000-0000000055101FFF 0000000000001FA5 ここを見ると、カーネルが読み込まれる可能性のある0x100000番地を先頭に、0x5315CFFF番地までが空き地になっていることがわかります。ページ数にして0x5305D番地の空き地です。1.4GBくらい空いているようです。最初に示したエラーメッセージによると、カーネル読み込みに必要なメモリー量は300MB程度らしいのです。なので、これだけ空いていれば、どの番地に読み込んでも順当にメモリー確保できます。おかげで、このマザーボードではメモリーアロケーションのエラーが出たことはありません。\nちなみにこの空き領域の容量は、起動するたびに多少変化することがあるようです。それでも変動は高々100MB程度です。また、iGPU割り当てメモリー量を変更してもほとんど変化しません。ASUSのメモリーマップはmacOSに適しているようです。\n失敗するマザーボード 一方、最近のMSIマザーボードでAptioMemoryFix.efiなどを使うと、かなりの確率で起動しません。MSIはZ170チップセットモデルからOsxAptioFix2Drv-free2000.efiが手放せなくなってしまいました。どんなメモリーマップになっているのか見てみます。以下はB350Mマザーボードのメモリーマップです。最近のMSIマザーボードでは、どれもこんな感じのメモリーマップです。\nType Start End # Pages BS_Code 0000000000000000-0000000000007FFF 0000000000000008 Available 0000000000008000-000000000005DFFF 0000000000000056 BS_Data 000000000005E000-000000000005EFFF 0000000000000001 Reserved 000000000005F000-000000000005FFFF 0000000000000001 BS_Code 0000000000060000-000000000009FFFF 0000000000000040 Available 0000000000100000-000000000FFFFFFF 000000000000FF00 BS_Code 0000000010000000-000000001000AFFF 000000000000000B Available 000000001000B000-000000007751AFFF 0000000000067510 BS_Data 000000007751B000-000000007755AFFF 0000000000000040 ASUSとMSIのメモリーマップを比較してみましょう。0x100000番地から先のページ数で示しています。ASUSは0x100000番地から0x53000ページ以上が空き地です。しかしMSIは0x100000番地から0xFF00ページが空き地で、その後0xBページ（10進数で11ページ）が使われていて（小さすぎて図では見えません）、その後、0x67510ページが空いています。\nつまり、MSIマザーボードでは、0x100000番地からは、0xFF00ページ、つまり267MB程度のメモリーしか空いていません。その後に、0x10000000番地から、たったの11ページ、バイト数にして45KBだけ、誰かが使っています。BS_Codeというのがそれです。そしてその後、0x1000B000番地から0x7751AFFF番地まで大量に空き地があります。そのため、0x100000番地から300MB程度を確保しようとすると、使用中の45KBが邪魔をして確保できません。これでエラーが出ます。なんでこんな邪魔なところに使用中のメモリーがあるんだ、という気持ちになります。\nただ、何度も何度も起動を試みると、たまに起動することもあります。エラーになるかどうかは、上で説明したKASLRが使用する乱数次第です。0x1000B000より大きい番地からメモリー確保しようとした場合は、エラーは出ず、問題なく起動します。\nslideオプションで解決する slideの仕組み config.plistなどに書くmacOSの起動オプションの中で、slide=x などと書くと、メモリーを確保する開始番地を指定できます。その規則は次のようになっているそうです。つまり起動オプションにslide=xと書くと、\n最近のCPUでは、0x100000 + x * 0x200000が読み込み開始番地になります ただし、SandyBridgeまたはIvyBridgeの場合は、xが0x00から0x7Fまでは、上記の計算ですが、xが0x80から0xFFまでの場合、0x10300000 + x * 200000になります となることが知られてます。最近のCPUだけを考えれば、slide値を0x200000倍して0x100000を足すだけなので簡単です。以下ではこの計算が適用できるCPUを前提に説明を進めます。\n空き地番地をSlideで指定する 上記のMSIマザーボードの場合、0x1000B000から、使われていないメモリーが大量にあるので、この番地以降を割り当てたいです。ということは、\n0x100000 + x * 0x200000 = 0x1000B000 x * 0x200000 = 0x1000B000 - 0x100000 = 0xFF0B000 x = 0xFF0B000 / 0x200000 = 0x7F = 127 という計算になり、slide=127 （もしくはそれ以上の値）とすれば良さそうです。でもこの計算は切り捨てになっているので、実は127ではスライド量が足りません。127 (0x7F) の場合、\n0x100000 + 127 * 0x200000 = 0xFF00000 からのメモリー確保がされるので、0x1000b000に引っかかってしまいます。1増やして128 (0x80) にすれば、\n0x100000 + 128 * 0x200000 = 0x10100000 になるので、ようやく0x1000B000より大きな番地からの割り当てになります。つまりconfig.plistのBoot, Argumentに、以下のようにslide=128パラメタを追加すれば、このようなメモリー空き地が不連続な問題を回避できます。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;slide=128 (他に必要なパラメータが続く)\u0026lt;/string\u0026gt; KASLRを無効にする ブートオプションでslide値を指定しても、KASLRが効いているとslide値としては相変わらず乱数（0x00から0xFFまでの乱数）が割り当てられます。ブートオプションのslide値は無視されるようです。slide値を指定すると同時にKASLRを無効にする必要があります。\nKASLRを無効にするためには、SIPでCSR_ALLOW_UNRESTRICTED_NVRAMフラグを立てる必要があります。これはNVRAMの変更制限を解除するフラグですが、同時にKASLRも解除されるようです。このフラグは、Appleが公開しているソースコードによると、\n#define CSR_ALLOW_UNRESTRICTED_NVRAM\t(1 \u0026lt;\u0026lt; 6) だそうです。1を6ビットだけ高位にシフトするという意味で、結果は0x40です。ということで、config.plistのRtVariables, CsrActiveConfigに0x40を書いておきます。\n\u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x40\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; 7ビット目が1ならば他の数字でも良いです。CsrActiveConfigとして、元々0x03という設定をされていたのであれば、0x43にすれば良いです。0x64という設定をしていたなら、これはすでに7ビット目が立っていますから、そのままで良いです。セキュリティをできるだけ確保するという観点からは、0x40が良いと思います。\nこれでブートオプションで指定したslide値が使用されるようになります。このようなconfig.plist設定で、MSIのマザーボードでもOsxAptioFix2Drv-free2000.efiを使わずに済むようになりました。AptioMemoryFix.efiで動きます。\nただ、CSR_ALLOW_UNRESTRICTED_NVRAMを許可すると、NVRAMの書き換えでSIPのすべての設定が変更可能になるので、セキュリティは脆弱になります。とはいえ、Hackintoshなのでconfig.plist書き換えて再起動すればSIPはどのようにも設定できるので、気にすることではないかもしれないです。さらにはslideパラメータでカーネル読み込みアドレスが固定されるのでKASLRの恩恵もなくなり、それも弱点になります。これに対しては、時々config.plistのslide値を微妙に書き換えて、人力KASLRしても良いかもしれません。\nまとめ：マザボ別対処法 KASLRが機能していると、Slide値は0から0xFFまで乱数で設定されます。つまりカーネルが展開される先頭番地は、\n0x100000 + 0 * 200000 = 0x100000 = 0番地から1MB程度先の番地 から\n0x100000 + 0xFF * 200000 = 0x1FF00000 = 0番地から530MB程度先 になります。ここから、300MB程度の領域にカーネルが展開されるわけです。KASLRがどのようなslide値を指定しても、300MBのカーネルが読み込まれるためには、0x100000番地から900MB程度の空き地が必要ということになります。そこで0x100000番地からの空き地がどれくらいあるかによって次の対処法が考えられます。\nなお、空き地容量の数値は、確保されるメモリーが300MB程度と仮定した場合の目安です。環境によってはもっと必要とされるかもしれません。\n空き地が900MB以上あるマザボ 何もしなくて良いです。ASUSのマザーボードでは0x100000番地から1.4GBくらいの空き地がありました。なので、KASLRがどのように先頭番地を割り当てても平気です。SIPを弱めてKASLRを無効にする必要もありません。macOSに最適なメモリーマップを持つマザーボードと言えます。\n空き地が300MB以下のマザボ slideで空き地番地を指定します。MSIのマザーボードは、0x100000番地からの空き地が267MB程度しかありませんでした。次にある空き地が十分大きくてKASLRの範囲内にあるので、たまに起動しますが、大抵は起動に失敗します。このようなマザボでは、上記で説明したように、KASLRの範囲内にある300MB以上の空き地をslideで指定します。\n空き地が300MB以上900MB未満のマザボ slide=0にします。コメントで教えていただいたGIGABYTE Z390M GAMINGでは、0x100000番地からの空き地は480MBとのことです。この場合は、小さなslide値だと起動しますが（80以下程度）、KASLRで大きなslide値が指定されると失敗します。そこで、slide=0を指定して0x100000から必ず展開するように指定します。\n","date":"2019-08-10T00:28:14+09:00","image":"/uploads/2018/09/20180628102100.png","permalink":"/posts/6108/","title":"slideでカーネル読み込み番地を調整する (Clover編)"},{"content":"Appleキーボードにはディスプレイの明るさを調整するキーがあります。ところが、このキーを押しても外付け液晶ディスプレイの明るさは変化しません。そこでアプリケーションを入れて明るさ調整を可能にします。\n太陽のキー キーボードのF1, F2キーには、お日様マークが書いてあり、これに明るさ調整機能が割り当てられています。\n本物のMacではこのキーを使って画面の明るさを調整できます。とはいえ、調整できるMacは、MacBookシリーズとiMacシリーズだけです。それ以外のデスクトップMac（Mac miniとMac Proだけですが）に市販のディスプレイを接続した構成では、このキーは機能しません。アップル社はMacBookとiMac以外には力を入れていないので、気にしていないのだと思います。なのでこれらのマイナーマシンユーザは、ディスプレイの調整ボタンに手を伸ばして、明るさ調整をする必要がありました。\nVESAのDDC 外付けディスプレイだから、コンピュータから明るさを調整できないのは仕方ない、と思っていました。でもディスプレイの標準化を進めているVESA (Video Electronics Standards Association) では、コンピュータプログラムからディスプレイを設定するためのプロトコルを決めているようです。それがDDC (Display Data Channel) です。これを使えば、コンピュータからディスプレイの明るさ・コントラストを調整できて、さらにはディスプレイ内蔵（されていれば）スピーカ音量も調整できます。Mac miniやMac Proには通常はVESA規格のディスプレイが接続されるので、macOSでもDDCをサポートしてくれれば良いのにと思います。\nDDCを使うアプリケーション DDC機能を利用して、コンピュータからディスプレイの明るさやコントラストなどを調整するアプリケーションが複数開発されています。このようなアプリはWindowsやLinuxにもあるようで、macOSにもあります。私はこちらの記事へのコメントで教えていただき知りました。Redditでも紹介されていました。その一つがNativeDisplayBrightnessだそうです。でもファンクションキーへの割り当てなどで不具合があるようで、以下のMonitorControl.appが良いようです。記事冒頭は、このアプリケーションのアイコンです。\nRelease MonitorControl v1.3.0 · MonitorControl/MonitorControl\nMonitorControl.appを使う メニューバーから明るさ調整 GitHubのサイトからMonitorControl.appをダウンロードして、起動するとメニューバーにアイコンが表示されます。\nこれでモニターの明るさと音量が変えられます。Preferences…のメニューから設定すれば、コントラストも調整できます。Preferencesからは動作や、キーボードショートカット設定、ディスプレイ選択などを行えます。\nショートカットキーの設定 MonitorControl.appを起動すると以下のようなダイアログパネルが表示されます。キーボードの明るさキーから調整するためにはショートカットキーを設定してくださいという内容です。\nその裏側には日本語のダイアログも出ていました。どのアプリケーションが動いていても、このアプリがイベントを受け取れるように許可してくださいという意味です。\nそこで、「システム環境設定」「セキュリティとプライバシー」「プライバシー」「アクセシビリティ」と選択して、MonitorControl.appに「コンピュータの制御を許可」します。\nこれでキーボードから明るさ調整できるようになります。F1, F2キーを押すと画面に明るさ状態が表示され、これを変更できます。画面明るさがキーボードで簡単に変更できるのはなかなか快適です。\n音量もキーで変更できるようにPreferences…で設定すれば、音量キーによりボリュームも変更できます。HDMIとは別にサウンドを設定しているので、下の写真ではmacOSのボリューム表示とディスプレイのOSDで表示されるボリューム表示が同時に出ています。\nApple純正キーボードの他にLogitech (Logicool) のキーボードも試してみました。F1/F2キーで明るさ変更できて、音量キーで音量調整できました。\n自動起動 MonitorControl.appのメニューのPreferences…から、ログインで自動的に起動するというオプションが選べます。ただ、私の環境ではうまく動かなかったです。その代わり、「システム環境設定」「ユーザとグループ」「ログイン項目」にMonitorControl.appを追加したところ、問題なく自動起動するようになりました。\nExternalDisplayBrightnessというのもある コメントでこういうアプリもあると教えてもらいました。本物のMacでも必要な機能なので、いろいろな人が作ってくれているようでありがたいです。\nExternalDisplayBrightness | František Nesveda\n","date":"2019-08-06T20:18:29+09:00","image":"/uploads/2019/08/MonitorControlIcon.png","permalink":"/posts/6149/","title":"Appleキーボードの☀︎キーで明るさ調整する"},{"content":"config.plistに「XHCIをXHCに変更」とか「SAT0をSATAに変更」などのパッチを書いている方も多いと思います。これは一体何なのか考えてみました。\nDSDTのPatches USBを設定するスクリプトであるUSBMapを試していたところ（そのうち紹介できれば良いと思い試行錯誤しています）、次のようなメッセージが出ました。\n「あなたのマシンにはEC0ってのがあるけどこれはECに変えた方が良いと思う。だからESPにあるconfig.plistを書き換えてあげましょうか？」\nよくわからないのでとりあえず辞退させていただきました。これは、config.plistのDSDTの中にPatchesというkeyを作って、そのarrayとして下のようなdictを追加してあげようかという提案です。\n\u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change EC0 to EC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUMwXw== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUNfXw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; config.plistのサンプルには、このようなPatchesが書かれていることがあります。書かれているBase64の内容は、base64コマンドで確認できます。\necho RUMwXw== | base64 -D EC0_ echo RUNfXw== | base64 -D EC__ それぞれの結果はEC0_とEC__になります。コメント通り、EC0をECに変更しようとするパッチです。\nこの他にconfig.plist設定例でしばしば紹介される典型的な名称変更パッチには以下のようなものがあります。（変更前の名前）—\u0026gt;（変更後の名前）の形式で記載しました。\nEC0 —\u0026gt; EC XHCI —\u0026gt; XHC XHC1 —\u0026gt; XHC EHC1 —\u0026gt; EH01 EHC2 —\u0026gt; EH02 SAT0 —\u0026gt; SATA Clover Configurator.appでもパッチを簡単に選べる機能があります。ACPI \u0026gt; DSDTを選択すると、パッチを選ぶメニューが出てきます。ここにはなぜかXHCに関するメニュー項目はありませんが、他にも多数のパッチ候補が表示されています。\nこの中からいくつかのパッチをよくわからずとりあえずconfig.plistに書いている方も多いと思います。私もよくわかっていませんでした。\nパッチの目的 RehabManさんの解説などを読んで私なりに理解した理由は次のようなものです。間違っているかもしれません。私の理解が正しいのかどうか、皆さんにお聞きしたいと思い、この記事を書きました。詳しい方がいらしたら、ぜひコメントでお知らせいただけるとありがたいです。適宜修正していきます。\nDSDTの項目名変更 これらのパッチは、config.plistのコメントから類推できるように、DSDTの項目名を変更する目的で使用されています。\nDSDTは電源管理のための情報で、マザーボードに搭載されているハードウェアの状況が記載されています。例えばどういう名前のUSBやSATAが何本あってどう接続されているかなどが書いてあるようです。マザーボードのBIOS（ファームウェア）がこの情報を持っていて、OSに提供します。WindowsやLinuxなどのOSはこの情報を参考にしてハードウェアにアクセスします。ファームウェアが提供するDSDT情報と、これを利用するOSの関係は、同じようにEFIに基づいて設計されているMacでも同様です。Macのファームウェアがハードウェア構成をDSDTを通して提供し、macOSはそれに従ってハードウェアを制御します。\nDSDTが提供する名称は、マザーボードによって違います。それがMacと同じ名前であることもありますし、違う名前のこともあります。例えば、iMac19,2のUSBコントローラはXHCIという名前ですが（最近のMac製品ならほぼ同じでXHCIです）、手元のZ390マザーボードはXHCです。\n自作で使うマザーボードでの名前を、本物のMacで採用されている名前に合わせたり、あえて名前を変えたりしているのがconfig.plistで使われるパッチの役割です。上で紹介した例で、Macで採用されている名前を太字体にした対応表が以下です。\nEC0 —\u0026gt; EC XHCI —\u0026gt; XHC XHC1 —\u0026gt; XHC EHC1 —\u0026gt; EH01 EHC2 —\u0026gt; EH02 SAT0 —\u0026gt; SATA EC0とSAT0に対するパッチは、Macで使われる名前に合わせるためのパッチで、残りのXHCI, XHC1, EHC1, EHC2へのパッチは、これとは逆にMacで使われている名前と違う名前にするためのパッチです。同じ改名パッチではありますが、動作が全く逆ですので、そのパッチを当てる動機も違います。\n実機のMacに名前を合わせるパッチ 上記の例ですと以下の2つのパッチは、ATXマザーボードが提供するDSDTの項目名をMacで使われる名前に変更するパッチです。本物のMacにより近い設定にしたいという意図は理解できると思います。\nEC0 —\u0026gt; EC SAT0 —\u0026gt; SATA どうやら10.11以前の古いmacOSは、DSDTの情報をあまり活用していなかったようです。どんなハードウェアが使われるか予想できないWindowsと違って、自社のハードウェアでしか動かさないOSなので、ハードウェア仕様をDSDTから得る必要がなかったのかもしれません。機種IDさえわかればハードウェアの詳細情報はわかってしまいますから。なのでこのようなパッチが必要だったようです。しかし、現在のmacOSではDSDT情報をちゃんと利用するようになったためか、この種類のパッチを当てなくても、大抵の場合、問題は発生しないようです。\n例えば、手元のASUS Z390マザーボードでIORegistryExplorer.appを起動して検索したところ、SAT0という項目がありました。その一方でSATAという項目はありませんでした。\nClover Configurator.appのメニューには、SAT0 —\u0026gt; SATAというパッチ候補があります。これを選ぶと以下のパッチがconfig.plistに書き込まれるようです。\n\u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change SAT0 to SATA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUMA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUQQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; これも動かしてみたところ、SAT0からSATAに正しく名称変更されました。でもSATA関連は変更前でも変更後でも全く問題なく稼働しています。\n冒頭ではEC0をECに変えるようにと指示された話を紹介しました。Hackintosh用のツールでは、実機の名前になっていることを前提にして動いていることもあるのかもしれません。でも、問題が発生しなければ当てなくても良いパッチだと思います。\n実機のMacの名前を避けるパッチ 以下のパッチはどれも、実機で使われるUSBコントローラの名前と違う名前に設定するためのパッチです。\nXHCI —\u0026gt; XHC XHC1 —\u0026gt; XHC EHC1 —\u0026gt; EH01 EHC2 —\u0026gt; EH02 ATXマザーボードと実機の名前が一致しているのに、わざわざ別名にするパッチなので、なぜ必要なのか理解に苦しむと思います。その経緯は以下のようです。\n上で、macOSも10.11からDSDTに書かれた情報を利用するようになったらしいと書きました。ところが一部のMacハードウェアは、あろうことかUSBに関する正しいDSDT情報を持っていなかったようです。DSDT情報をOSで利用する予定がなかったのでいい加減に記述してあったのかもしれません。本来なら正しいDSDTを提供するようにファームウェアアップデートするべきですが、それは大変なのでOS側で対応したそうです。つまり、DSDTのUSB情報が間違っているMacに対しては、macOSで用意したUSB構成情報を使用することになりました。全てのMac機種のDSDT情報を無視しているわけではなく、DSDT情報が怪しいとわかっているMac機種に関してはOSで用意した値を使っているようです。\nなのでATXマザーボードが持っているUSBコントローラに、たまたまMac実機と同じ名前がついていると、DSDTが提供する情報を使わずに、macOSが用意したMac実機の情報を使ってしまう可能性があります。それを避けるために、Mac実機と違う名前に改名するのがこれらのパッチです。\nこのパッチも、いろいろな理由で不要な場合が多いです。\nまずは、もともとDSDTのUSBコントローラ名がMacの実機と違う名前だったら名称変更は不要です。例えば手元のASUS Z390マザーボード（機種IDはiMac19,1）でIORegistryExplorer.appを起動して、XHCを検索してみたところ、名称変更パッチを当てなくても、XHCという名前で存在していました。名称変更パッチの変更対象名として使われるXHCIとかXHC1という名前の項目はそもそも存在していませんでした。このような場合は、名称変更パッチは不要と考えて良いと思います。\n次に、macOSがDSDTを信用してくれる機種IDなら名称変更は不要と考えられます。例えばこちらはNUCで作ったHackintoshの例です。機種IDはMacBookAir5,1です。IORegistryExplorer.appを起動して確認すると、名称変更対象に上がっているEHC1とEHC2があるようです。その一方でEH01やEH02は見つかりません。でもmacOSは、この機種のDSDTは正しいと認識しているようで、このままでも全く問題なくUSBが認識されています。NUCはUSBの数が少ないので15個制限も問題無いようです。\nちなみに、このNUCで、\nEHC1 —\u0026gt; EH01 EHC2 —\u0026gt; EH02 の名称変更パッチを当ててみるとちゃんと変更されることが確認できました。config.plistに追加したパッチは、以下のものです。\n\u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change EHC1 to EH01\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUhDMQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUgwMQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change EHC2 to EH02\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUhDMg== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUgwMg== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; この結果EH01とEH02がIORegistryExplorer.appのウィンドウに現れました。その一方で、EHC1とEHC2は無くなりました。名称変更のパッチが効いているようです。でもどちらの場合でも、USBは問題なく機能しました。\n以上のように、Mac実機のDSDT項目名を避けるパッチを当てることで、DSDTのUSB情報がありのままにmacOSに伝わり、Hackintoshの動作が安定する可能性があります。ただし最近の機種IDを設定していれば、DSDTの情報がそのまま正しくmacOSで使われるのでパッチは不要な気がします。古い機種IDであっても、MojaveのAPFS起動に対応した時にファームウェアアップデートされたので、信用できるDSDTに置き換わっている可能性もあります。なのでmacOSがDSDTを無視する必要性が少なくなったはずです。そのような状況を考えると、実機の名前を避けるパッチも、もはやそれほど必要でない気もしています。\nまとめ ということで、config.plistのDSDT Patchesの機能を考察しました。半分推測なので、間違っているかもしれません。詳しい方いらしたら、コメントで教えていただければ助かります。\nまとめると、DSDT Patchesは、DSDTの項目名を変更するパッチでした。改名結果はIORegistryExplorer.appで確認できました。改名するとDSDT情報が正しくmacOSに伝わり、Hackintoshの動作が安定する可能性があります。ただし最近では、パッチの必要性が下がっている気がします。使用しているマザーボードのDSDT項目が、パッチ対象の名前かどうかを調べておいて、パッチ対象の名称であった場合は、何か問題があった時に名称変更のパッチを試すのが良いと思います。\n","date":"2019-07-28T23:28:12+09:00","image":"/uploads/2019/07/patch2.png","permalink":"/posts/5957/","title":"config.plistでDSDT項目名を変更するパッチ"},{"content":"NVMeプロトコルのM.2 SSDが安くなっています。1TBでも1万円代前半です。ということでCrucialのお安い1TB M.2 SSD, CT1000P1SSD8をmacOSで使ってみました。問題なく動作し性能もそこそこ良いです。\nSSDが安くなった メモリーの価格が下がっている関係か、M.2 NVMe SSDも安くなっているようです。以前は、1TBだと結構なお値段だったのですが、セールだと1万円を切ってたりします。以下はその時のスクリーンショットです。\n残念ながら現在の価格は1,400円ほど上昇して11,323円ですが、それでも1TBでのこの価格は、ちょっと前なら考えられなかった状況です。ただし、品薄のようで納期が長いです。（この記事の執筆時の状況です。現在の価格、納期は下のリンクから確認してください。）\nマザーボードに取り付け ということで、このSSDをmacOSで動かしました。使用したハードウェア構成は以下です。マザーボードはMSIのB360搭載Micro ATXです。SATAコネクタに接続した2.5 inch SATA SSDでmacOS Mojaveが問題なく動作しています。\nMSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh\nCT1000P1SSD8JPをマザーボードのSSD用M.2ソケット（CPUのすぐ隣の方のソケット）に取り付けました。廉価版のB360マザーボードなので、M.2 SSD用のヒートシンクは用意されていません。なので別途ヒートシンクを用意しました。CPU隣のM.2ソケットは、PCIe拡張カードに干渉しない場所にあるので、背の高いヒートシンクを取り付けられます。大型の空冷CPUクーラを使わなければ、ケースの高さまで上空が空いています。ギリギリの高さまでヒートシンクとしたいところです。そこで入手し得る限り背の高いヒートシンクを探して取り付けました。以下の製品で高さは3cmあります。マザーボードがチタン色なのでシルバー（塗装無しアルミ）版を購入しましたが、黒いマザーボードをお使いならブラック（塗装ありアルミ）版が合うと思います。\nAmazonの写真では、取り付けゴムが輪ゴム色（ブラック版は白色）で多少微妙でしたが、実際に届いた製品には白い耐熱ゴムでした。マザーボードに取り付けるとこんな感じです。それほど違和感はありません。CPUのリテールクーラと比べると、背の高さがわかるかと思います。このM.2 SSDも他製品と同様に、酷使するとコントローラチップが発熱します。でもこれだけの熱容量のあるヒートシンクだと、穏やかに暖かくなる程度でした。\nフォーマット M.2 SSDをマザーボードに取り付けたら、ディスクユーティリティ.appでAPFSでフォーマットします。HFS+でフォーマットしても良いですが、macOSをインストールする際に結局はAPFSに自動変換されると思います。以前だとシステム用とデータ用にパーティション分けしたりしていたのですが、今はAPFSのコンテナ機能により柔軟にボリューム作成できるので、ちまちまとパーティション分けするのはやめました。ということで1TBを丸ごと一つのパーティションにしました。ディスクユーティリティ.appでは、M.2 SSDを選んで「消去」ボタンを押します。この操作により、SSD全体を占める1パーティションが作られ、その中にコンテナが一つ出来上がり、コンテナにボリュームが1個追加されます。macOSの伝統に従って、ボリューム名はMacintosh HDにしました。APFSコンテナなので、将来、このコンテナにデータ用のボリュームを新設・追加することが容易です。そうすれば、システム用とデータ用の2つのボリューム構成になり、macOSをクリーンインストールするときに便利になります。\nMojaveのインストール 現用の2.5 inch SATA SSDで起動して、macOS最新版をダウンロードし、M.2 SSDにインストールします。ここまでは通常のMac機種と同じです。今回は、ダウンロードの時間節約のために、あらかじめダウンロードしてあった10.14.5をインストールしました。10.14.6へのアップデートも問題ないはずです。9900Kマシンでは10.14.6インストール時にiGPUを無効にする必要がありましたが、このマシンはFモデルCPUで、そもそもiGPUが存在しないので、その心配はないと思います。この段階ではM.2 SSDから起動できません。2.5 inch SATA SSDからCloverを起動してM.2 SSDのmacOSの動作を確認します。\nESP内容のインストール 次に、現用の2.5 inch SATA SSDと、M.2 SSDの両方のESPをマウントし（それぞれ/Volumes/EFIと/Volumes/EFI 1としてマウントされるはずです）、2.5 inch SATA SSDの内容をM.2 SSDに、ファインダーのドラッグ\u0026amp;ドロップ操作でコピーします。あとはBIOSでM.2 SSDを起動ドライブに設定するだけで、macOSが起動しました。\nシステム環境で確認 システム情報を開いてM.2 SSDの動作を確認しました。TRIMが有効になっているようです。しばらく使用しましたが、特に問題はありませんでした。Crucialの格安のSSDがmacOSで使用できることが確認できました。\n速度測定 この格安SSDは自作PCユーザの間で評判のようで、Windowsで測定した速度がいくつかのページで紹介されています。例えば、以下のページです。\nQLC型NVMe M.2 SSD「Crucial P1 1TB」をレビュー。SATA SSDに近い容量単価でSATA S\u0026hellip;\nこれによるとCrucialの1TBモデルは、メーカー発表の仕様書通りの性能を発揮して、Readが2000MB/s, Writeが1700MB/sのようです。Windowsベンチマークでよく使われるCrystalDiskMarkに近い動作をするmacOS用の AmorphousDiskMark.app を使って速度を測定しました。その結果、仕様書通りの性能が得られました。macOSでもこのSSD本来の性能を活かせているようです。\n","date":"2019-07-26T01:16:55+09:00","image":"/uploads/2019/07/m2ssd-1.jpg","permalink":"/posts/5883/","title":"Crucialの1TB NVMe M.2 SSD (CT1000P1SSD8) を使う"},{"content":"10.14.6が出たのでアップデートしました。いつものように簡単だとたかをくくっていたら、ちょっとつまづきましたので簡単にご報告します。アップデートしたハードウェア構成は、こちらです。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\n以前も「グラフィックスカード(RX 580) に切り替わるタイミングで起動が止まる、もしくは止まって再起動する」という現象が発生しました。フォーラムで情報を頂いたように、この場合、BIOS設定でCPU内蔵グラフィックス (iGPU) を無効にすると直るようです。ただしiGPUが動かないとJPEGファイルのクイックルックが効かないので、ブートオプションに以下の記述をして、WhateverGreenに指示する必要があります。\nshikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94 今回、10.14.6へのアップデート作業の途中で再起動する過程で、この現象が発生しました。そこでBIOSでiGPUを無効にするよう設定したところ、無事にアプデートが完了しました。面白いことにアップデート後は、iGPUを有効にしても問題なくブートしました。なので上記のブートオプションは不要でした。原因はメモリー利用（メモリーマップ）の関係のように思えるのですが、条件によって発生したりしなかったりする微妙な現象のようです。\n何れにしても、この問題が発生した時はiGPUを無効にすることで対応できるようです。\nそういえばMojaveのインストーラやアップデータが、「インストーラリソースが見つかりません。」というメッセージを出して止まってしまうこともありました。これはインストールに無関係なドライブを一時的に切り離せば対応できました。今回の問題は、一時的なBIOS設定で回避できるので、少しは楽かもしれません。\nMojaveの「インストーラリソースが見つかりません」問題\n","date":"2019-07-24T20:30:55+09:00","image":"/uploads/2019/07/%e3%82%b9%e3%82%af%e3%83%aa%e3%83%bc%e3%83%b3%e3%82%b7%e3%83%a7%e3%83%83%e3%83%88-2019-07-24-19.46.07.png","permalink":"/posts/5997/","title":"10.14.6更新に失敗するのでiGPUを一時的に無効にしました"},{"content":"OpenCoreはCloverから分岐し、OZMOSISの流れを取り込んだ新しいオープンソースのブートローダーです。Z390マザーボードで動かしたところとりあえずはmacOSが起動しました。\n追記：最近のOpenCore関連の記事もご覧ください。\nASUS Z390 + Coffee LakeのブートローダをOpenCoreにする\nOpenCoreとは OpenCoreは、完璧にオープンソースであることが特徴の新しいブートローダーです。Cloverから分岐し、OZMOSISの流れを取り込んでいます。OZMOSISを開発していたドイツのHackintosh-Forum.deの人たちが開発を進めているようです。OZMOSISってどんなものだったかと言うと、ファームウェア形式のブートローダーで、マザーボードのBIOSを置き換えて動作します。OZMOSISをマザーボードのBIOS更新機能を使ってインストールすれば、普通のマザーボードがmacOSを直接起動できるマザーボードに変身します。macOSもmacOSインストーラも実機と同様にそのまま起動できるという理想を追ったブートローダーだったのですが、調整やアップデートのたびにBIOS更新作業をするのは大変でした。ChameleonやCloverみたいにドライブの一部に書き込む方式の方が色々楽です。ということでOZMOSISはあまり流行りませんでした。開発チームもそれを認識して、今度はClover方式のブートローダーを作ることにしたのだと思われます。\n使用したハードウェア OpenCoreを試したハードウェアは、以下で紹介したZ390マシンです。モデルIDはiMac19,1で、macOS Mojave 10.14.5です。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\nここで使っているkextは\nAppleALC.kext IntelMausiEthernet.kext Lilu.kext USBInjectAll.kext VirtualSMC.kext WhateverGreen.kext です。efiファイルは大半がClover 5018で配布されているものです。\nApfsDriverLoader.efi AptioMemoryFix.efi (これはKext Updater.appで入手) FSInject.efi VirtualSmc.efi （VirtualSMC.kextに同梱されているもの） VBoxHfs.efi EmuVariableUefi.efi またUSBInjectAll.kextで使うためのSSDTファイルも使っています。こちらで作成したものです。これがSSDT-UIAC.amlという名前です。\nOpenCoreを入手する方法 いろいろな方法がありますが、一番お手軽なのは最近のKext Updater.appを使う方法です。Kext UpdaterもOpenCoreを作っている人たちが活躍しているHackintosh-Forum.deで作られていますので、その関係でOpenCoreダウンロード機能が実装されているのだと思います。Load Bootloaderのラジオボタンを選択して、右のポップアップメニューからOpenCoreを選択します。\nダウンロードすると、Kext-Updatesフォルダの中にOpenCoreというフォルダができて、この中にデバッグ版とリリース版\nOpenCore-0.0.4-DEBUG OpenCore-0.0.4-RELEASE のフォルダが出来ています。今回はRELEASE版を使ってみましたが、DEBUG版の方がより多くのエラーメッセージを出してくれるらしいです。\nESPディレクトリ構築 Docsフォルダの中には、とても詳しい取扱説明書が入っています。Cloverにはあまりなくて、ネット上のマニュアルも古かったりします。説明書を一緒に配布してくれているのは助かります。まだちゃんと読んでませんが、必要な情報は全部書いてあるのではないかと思います。マニュアルによると、構築すべきディレクトリ構造は以下の通りのようです。\nグレーの項目は任意の項目です。なので、EFIの下に、BOOTとOCを作って、OCの中のDriversにefiファイルを、Kextsにkextファイルを入れれば良いようです。またOCの中にconfig.plistを置きます。名前がOCになっただけで、CloverのESP配置とだいたい同じです。この図に従ってESPの中にディレクトリを用意し、DriversフォルダとKextsフォルダに上記のefiファイルとkextファイルを入れました。またACPIフォルダにSSDT-UIAC.amlを入れました。\nconfig.plist編集 Docsフォルダの中に、マニュアルと一緒にconfig.plistのサンプルファイルも入っています。名前が、Sample.plistとなっています。今回はこのファイルをもとに動かしてみました。まずはSample.plistをconfig.plistに名称変更します。そして以下の手順で書き変えました。\nSMBIOS設定 まずは機種設定からです。どうやらPlatformInfoの中のGenericの中が機種設定関連のようです。この部分のMLBがCloverでのBoardSerialNumberに対応し、SystemProductNameがProductNameに、SystemUUIDがSmUUIDに対応するようです。それぞれの値を書いておきます。\n\u0026lt;key\u0026gt;MLB\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02921130GULNV9JA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SystemProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac19,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SystemSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02YR2YHJV3Q\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SystemUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;E45005B4-95C7-4B0C-9739-30947DDEB37C\u0026lt;/string\u0026gt; FileVault設定 この状態で起動させようとしたところ、FileVaultの用意ができていないというような内容のメッセージが出て起動が中断しました。config.plistを見ると、MiscSecurityの中にFileVaultらしい設定があり、有効にされているようです。ここのtrueの部分2箇所をfalseに書き換えました。これでメッセージが出なくなりました。\n\u0026lt;key\u0026gt;Security\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ExposeSensitiveData\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;2\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;HaltLevel\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;2147483648\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;RequireSignature\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;RequireVault\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;ScanPolicy\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;983299\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; efi設定 次に、HFSPlus.efiが見つからないというメッセージで起動が中断されました。最近はAPFSになって、HFS+での起動は使わないので、上記のリストのようにCloverデフォルトのVBoxHfs.efiを使っていました。なんでこのメッセージが出るのかと思ったらconfig.plistのUEFIDriversの中にefiファイルの一覧が書いてありました。フォルダに入れるだけでなくconfig.plistにも書いておくようです。FileVaultに関係したefiファイルも入っています。これらのリストを、実際に使っているefiファイルに書き換えました。\n\u0026lt;key\u0026gt;UEFI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Drivers\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;string\u0026gt;VBoxHfs.efi\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;ApfsDriverLoader.efi\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;EmuVariableUefi.efi\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;FSInject.efi\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;AptioMemoryFix.efi\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;VirtualSmc.efi\u0026lt;/string\u0026gt; \u0026lt;/array\u0026gt; kext設定 ほかも見てみると、KernelAddの場所に、kextに関する記載もあります。この記述順にロードされるようなので順番も大事なようです。\nIntelMausiEthernet.kextの名前が違っている（IntelMausi.kextになっている）のとEnabledされていないようなので、修正しました。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BundlePath\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;IntelMausiEthernet.kext\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Enabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;ExecutablePath\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Contents/MacOS/IntelMausiEthernet\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;MatchKernel\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;PlistPath\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Contents/Info.plist\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; また、USBInjectAll.kextの記述も追加しました。順番が大事のようです。arrayの最初の方に入れたら動きません。arrayの最後に追加しました。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BundlePath\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;USBInjectAll.kext\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Enabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;ExecutablePath\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Contents/MacOS/USBInjectAll\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;MatchKernel\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;PlistPath\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Contents/Info.plist\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; SSDT設定 使用するSSDTもconfig.plistで指定する必要があるようです。今回は、SSDT-UIAC.amlを使います。そこで、ACPIAddのarrayの中に、\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;USB list for USBInjectAll\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Enabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Path\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;SSDT-UIAC.aml\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; を追加しました。\n動作確認 BIOSでOpenCoreをインストールしたドライブを選択すると、Cloverと同様に起動ボリュームの選択画面が出ます。テキストだけのシンプルな画面です。ここで10.14.5の入ったMacintosh HDを選択しました（この例ではキーボードの5を押す）。この後、設定に不備があると上記のようなエラーメッセージが出ることもありますし、起動が停止することもあります。\nでも、ここまでの設定で、なんと起動しました。config.plistで手付かずの項目がいっぱいあるのに、とりあえず起動したのは意外でした。よかったです。\n使用したconfig.plistを以下においておきます。\nOpenCore config.plist for Z390 - Pastebin.com\n動くこと 画面が出て動作します。Radeon RX 580が正しく動きます。IntelMausiEthernet.kextも動きます。なのでLAN接続ができます。またBroadcomの純正WiFiも動きます。\nUSBInjectAll.kextと自作のSSDTの組み合わせで、USBの取捨選択ができています。15個制限問題を解決できています。\n動かないこと シャットダウンすると画面は消え、シャットダウンプロセスが実行されるのですが、電源が切れるところまで行き着きません。電源スイッチを長押しして強制的にoffにする必要があります。その影響で次の起動の時にBIOS表示で警告が出ます。ACPI関係の設定が足りないのだと思います。\nOpenCoreに行くべきか？ ということで、OpenCoreでの起動を確認できました。今後は、USBの指定方法や、今回見た以外のconfig.plistの設定など、マニュアルや検索して調べて見たいと思います。\nではCloverをやめてOpenCoreに移行すべきでしょうか。OpenCoreの人たちは、以下のようなメリットを訴えています。\n完全にオープンソースなので安心 設計が新しい 確かにCloverは開発過程がそれほどオープンになっていないので、わかりにくいところがあるかと思います。ロシアで開発されているCloverとドイツで開発されているOpenCoreでは、偏見かもしれませんが、なんとなくOpenCoreに安心感を感じます。開発がオープンなのでHackintoshの主流がOpenCoreに移行していく可能性は高いです。でも今現在では、Cloverに関するノウハウが大量にネットにありますし、しばらくはCloverが使われると思います。\n主流ブートローダーは、数年前にChameleonからCloverに交代しました。ただ、この交代では、レガシーなMBR (マスターブートレコード)からESPに対応すること、起動時に動的にパッチを当ててくれる機能、macOSとの相性が良くなることなど、いくつもメリットがありました。CloverからOpenCoreに変えても、目に見えるメリットはないので、移行は緩やかかもしれません。CloverからOpenCoreに移行したらグラフィックスカードの動作が安定したと言う情報も見かけました。今後どうなるにしても、選択肢が複数あることは良いことです。\n","date":"2019-07-20T16:30:07+09:00","image":"/uploads/2019/07/image.png","permalink":"/posts/5914/","title":"新ブートローダーOpenCoreを使う"},{"content":"新しいClover 4988が公開されたので深く考えずに更新しました。そしたら起動しなくなりました。EFIドライバの管理方法がいろいろ変更になったようです。\n（EFIドライバの古い情報は以下に書いてあります。今でも参考になる部分はありますので、ご覧ください。）\nCloverで使うEFIドライバ\nEFIドライバの管理方法 4988では、拡張子が.efiのEFIドライバーの管理方法が変わったようです。Cloverインストーラの選択肢もグループ分けされています。その影響なのか、次に述べるEFIドライバの格納フォルダ名が変更になった影響なのかわかりませんが、前回のインストール情報が継承されていないようです。単にアップデートすると全てのEFIドライバが非選択になっています。そのままインストールすると、EFIドライバが足りない状態で起動しようとして、当然ながら起動に失敗したようです。\nもともと私のマシンでは、前のバージョンのClover 4972以前で、以下のようにEFIドライバを設定していました（6個です）。\n補足：この6個のうち、SMCHelper.efiはFakeSMC.kextと一緒に使用するためのEFIドライバだそうです。VirtualSMC.kextを使用する場合はこれは不要らしいです。VirtualSMCを使用する場合は、VirtualSMCと一緒に配布されているVirtualSmc.efiを使用するのが正しい方法らしいです。\nこの状態で、4988を自動的にインストールしようとすると、以下のようになりました。ApfsDriverLoader-64以外が全部消えてしまいました。たまたまこれが残されたのは、新バージョンで名前から64が外れたためのようです。driversという新しいフォルダができていますが、こちらは空っぽです。このままでは起動しません。\nインストーラでEFIドライバを選択し直さないといけないようです。以下のようになりました。このスクリーンショットではわかりませんが、グループ分けされたEFIフォルダの中から上記の6個を選択してあります。\nその結果以下のようにインストールされました。driversのフォルダの中に、UEFIというフォルダが作られて、その中にEFIドライバーがインストールされるようです。ちなみに古いdrivers64UEFIフォルダはもはや使われていないようで、削除しても大丈夫でした。これで起動するようになりました。\n新オプションDrivers off 4988のインストーラにDrivers offというオプションが追加されています。説明によると、利用可能な全てのドライバをEFI/CLOVER/drivers/off/にインストールするそうです。offフォルダは名前の通り使用されないドライバの置き場所で、ここに全てのドライバを入れておけば、必要になった場合にEFI/CLOVER/drivers/UEFI/にコピーして使えます。\nこれを選択すると、説明通りdriversフォルダの中にoffフォルダが作られて、その中に大量の (33個) ドライバが入ります。インストールしなかったドライバを試したい場合に便利です。こちらで紹介したようにEFI SHELLでmvコマンドで操作することもできるでしょう。offフォルダの中身の合計（ドライバの総容量）は815KBです。ESPの容量（200MB程度）からして負担になる量ではありません。\nAptioMemoryFix-64が消えた macOSカーネルを読み込むための連続メモリ領域確保を支援するAptio系のEFIにも変更があります。インストール画面からおなじみのAptioMemoryFix-64.efiが消えて選べません。\n上記のoffフォルダを見ていただくとわかるように、こちらにも存在しません。ドイツ語のHackintosh-forumにはいち早く説明が書いてありました。英語に翻訳したURLは以下です。AptioMemoryFixは新しいドライバなのですが、CLOVERの開発者チームの作ではないので、同梱されなくなったようです。\n今回は代わりにOsxAptioFix3Drvを使用しました。問題なく使えました。なお、フォーラムでいただいた情報によるとAptioMemoryFix-64.efiの-64を名前から外して、新しくできたdrivers/UEFIに入れれば動くらしいです。でも同梱されたドライバで問題ないならばその方が整合性の点で良いかと思いました。\nまたAptioMemoryFix.efiの最新版はKext Updater.appからも入手できます。こちらからは-64の名前のない、最新版が入手できます。これを利用しても良いと思います。\nレガシーインストールが選べない これはEFIドライバの話だけではありませんが、MBR (マスターブートレコード）にインストールするレガシーBIOSの方法がインストーラで選択できなくなっています。レガシーブートは手作業でインストールすれば可能かもしれません。でも自動的にインストールできるのはUEFIブートだけになりました。下は4972のインストール画面です。\nこれに対して下が4988のインストーラです。MBR, PBR（パーティションブートレコード）へのインストールオプションがなくなりました。\n最近はMBRしかサポートしないレガシーなマザーボードはほとんど見当たらなくなりましたし、わかりやすくなって良いのかもしれません。\nまだいろいろ変更されたことはありそうです。AptioMemoryFixがなくなったので、Aptioシリーズの選択方法も再検討すべきかもしれません。この記事に加筆していきたいと思います。\n","date":"2019-07-13T22:14:47+09:00","image":"/uploads/2018/09/20170916220921.png","permalink":"/posts/5821/","title":"CLOVER 4988 でEFIドライバ関連が変更されました"},{"content":"ASUSのZ390マザーボード、ROG MAXIMUS XI HERO WiFiのBIOSを最新版1105にアップデートしたところmacOSが起動しなくなりました。1005にダウングレードしたら復活しました。\nBIOSアップデートで起動しない ASUSの最新BIOS 1105が公開されていますが、これにアップデートするとmacOSが起動しなくなるとのことです。こちらのコメントで教えていただきました。検索すると色々なところで紹介されていました。\nならば試してみようということで、こちらのビルドで紹介したASUS ROG MAXIMUS XI HERO WiFiのBIOSをアップデートしてみました。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\nROG MAXIMUS XI HEROは、BIOSからネットワーク接続してBIOSアップデートできます。この機能を使って最新の1105にアップデートしました。するとやはりmacOSが起動しませんでした。-vで起動すると起動途中で文字表示が止まってそのまま動かなくなります。apfs.efiなのかVirtualSMCのあたりのメッセージで止まります。\nBIOSでRTCを設定する この記事へのコメント欄で教えていただいた情報によると、原因はRTC (リアルタイムクロック）の関係のようです。BIOS設定でレガシーなRTCを使うように指定すれば解決するようです。RTCは、システムの日付や時計を管理しているだけでなく、割り込みでプログラムを制御するような使い方もされているようです。起動時に、RTC割り込みがある事を前提に作業を始めた起動プログラムが、RTCからの割り込みが発生しないために動作継続できなくなって、起動が止まってしまうようです。\n上記のサイトでは以下のような設定画面の写真が紹介されていました。ASUSのBIOSメニューの、Advanced–\u0026gt;PCH Configuration–\u0026gt;System Time and Alarm SourceをLegacy RTCにすれば良いようです。メニューの内容などから判断すると、ACPIが提供するタイマー・アラーム機能を利用する方式がデフォルト設定になったため、Clover + macOSが対応できなくなったようです。従来型のRTCのタイマー・アラーム機能を使用するよう設定すれば、macOSを起動できるようです。\nところがどういうわけか、ROG MAXIMUS XI HEROのBIOS ver. 1105の画面にこの選択肢が出てきません。\nIOAPICのエントリーの選択肢は、以前のBIOSでは表示されていました。今回は、それも無くなっていました。もしかしたら次のバージョンでRTCの選択肢が出てくるようになるのかもしれません。という事で、BIOSでLegacy RTCを指定する方法は使えませんでした。\n追記：1302でもダメでした 2019/9/11付で1302が公開されていたので、アップデートを試みました。やはりそのままでは起動せず、また、System Time Alarm Sourceのメニューも現れませんでした。下記に説明したUSB BIOS Flashbackの方法で1005に戻しました。（2019年9月29日）\n追記：1401でもダメでした 2019/12/11付で1401が公開されていたので、アップデートを試みました。やはりそのままでは起動せず、また、System Time Alarm Sourceのメニューも現れませんでした。下記に説明したUSB BIOS Flashbackの方法で1005に戻しました。（2019年12月21日）\nパッチを当てる ASRockのマザーボードなどで必要とされていたDSDTへのパッチ\nを当てることでも対応できるようです。これで新しいBIOSでもmacOSが起動したそうです。以下のパッチをconfig.plistのACPI\\DSDT\\Patchesに書き込めば良いようです。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Fix Z390 BIOS DSDT Device(RTC) bug\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; oAqTU1RBUwE= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; oAqRCv8L//8= \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; ただ、パッチを当ててまで新しいBIOSが使いたいわけではないです。そこで、ダウングレードすることにしました。ところが…\nBIOSダウングレード出来ない 失敗したら古いバージョンにダウングレードすれば良いと思って、気楽に手がけたのですが、実は簡単ではありませんでした。実際に試したところ、1105より古いBIOSでは、BIOS画面からEzFlashというツールを起動して、古いBIOSイメージを指定すれば、簡単にBIOSダウングレードできました。しかし最新の1105では、1105より古いバージョンのBIOSイメージを指定すると、適切なBIOSでは無いと言われてインストールしてくれません。\nUSB BIOS Flashbackでダウングレード MAXIMUS XI HEROにはUSB BIOS Flashbackという機能があります。ネットワークやUSBメモリからBIOSを更新できるEzFlashはBIOSのメニューから起動するツールで、搭載したCPUやメモリーを使用して動いています。これに対してUSB BIOS Flashbackは、CPUやメモリーを搭載していなくても動く更新ツールです。おそらくマザーボード上に専用のマイクロコンピュータを搭載していて、CPUの力を借りずにBIOS更新する仕組みかと思います。BIOS更新のためにわざわざコンピュータを搭載していると考えると、とても贅沢に思えます。上位機種のマザーボードにしか搭載されていません。これでBIOSダウングレードを試しました。\nUSB BIOS Flashbackを使用するには、FATでフォーマットしたUSBメモリーのルートに、更新したいBIOSイメージをM11HW.CAPという名前で置いておきます。これをバックパネルの、USB BIOS Flashback用のUSBポートに挿しておきます。PS/2コネクタ下にあります。次に、電源を切った状態で、バックパネル左端のUSB BIOS Flashボタンを3秒ほど長押しします。するとこのボタンが点滅を始めます。あとは点滅が終了するまで待つだけです。自動的に再起動しなければ電源投入します。2-3回再起動した後、インストールしたバージョンのBIOS画面になります。ここでmacOS向けの設定をすれば良いです。\n今回は、1105の一つ前のバージョンである、1005に戻すことにしました。そこで、ROG-MAXIMUS-XI-HERO-WIFI-ASUS-1005.CAPをM11HW.CAPという名前に変更して、USBメモリに入れました。ちなみに現在の設定は、工場出荷状態に加えて、\nIntel (VMX) Virtualization Technology –\u0026gt; [Enabled] Memory Remap –\u0026gt; [Disabled] iGPU Multi-Monitor –\u0026gt; [Enabled] Connectivity mode (Wi-Fi \u0026amp; Bluetooth) –\u0026gt; [Disabled] XHCI Hand-off –\u0026gt; [Enabled] です。\nSSDTで対応する 追記です。こちらの記事で紹介しましたようにSSDT-AWAC.amlを使っても解決しました。\n300チップセットマザーボードのRTC設定\nまとめ ということで、ACPIのタイマー・アラーム機能を使うようになった最新のマザーボードでは、BIOSで古い形式のRTCを使うように設定する必要があります。ASUSのBIOSメニューでは、Advanced–\u0026gt;PCH Configuration–\u0026gt;System Time and Alarm SourceをLegacy RTCにすれば良いです。この設定ができない場合は、config.plistにパッチを書き込むことでも解決します。このマザーボードではどういうわけか、BIOSでLegacy RTCを選択できませんでした。そこで、パッチを当ててまで新しいBIOSを利用する必要はないと判断して、古いBIOSに戻しました。BIOSをダウングレードするために、マザーボードのFlashback機能を使用しました。\n今回、マザーボードにとってBIOSを復活させる機能が重要だと思い知らされました。USB BIOS Flashbackならば、BIOSが徹底的に破壊されても復活できると思われます。再びマザーボードを買い換えるときには、この種の機能を重視していきたいと思います。\n","date":"2019-07-07T22:12:38+09:00","image":"/uploads/2019/07/BIOSupdate.png","permalink":"/posts/5734/","title":"ASUSのBIOSを1105以上に更新すると起動しない"},{"content":"\ntonymacx86のツールUniBeastを使って、単体で起動できるmacOSインストーラUSBメモリーを作成する方法を、Hackintosh初心者向けに紹介します。tonymacx86で開発配布されているツールにUniBeastとMultiBeastがあります。どちらもHackintosh初心者によく使われています。そこで、3つの記事で、以下の手順：\nその1：UniBeastを使って単体で起動するmacOSインストーラUSBメモリーを作り、これを使ってmacOSをインストールする。 その2：MultiBeastを使ってCloverやkext類をインストールし、macOSを起動できる状態にする。 その3：kextの場所とconfig.plistを修正してバニラ化してチューニングする。 を説明します。この記事は、その1です。その2、その3は以下の記事です。\ntonymacx86式インストール手順 (その2: MultiBeast)\ntonymacx86式インストール手順 (その3: バニラ化と調整)\nUniBeast UniBeastはtonymacx86.comで作られて配布されているHackintosh作成ツールです。単体で起動するUSBメモリーを作成します。\nUniBeastが行うことは、\nmacOSがMacで起動するUSBメモリーを作成する これにCloverをインストールする これに必要なkext類をインストールしてconfig.plistを作成する という3つの作業です。1番の作業は、通常のMacユーザも行なっている作業です。Appleのサイトにも丁寧な説明があります。\nmacOS の起動可能なインストーラを作成する方法\n2番目の作業は、Cloverを入手すれば、そのインストーラが行ってくれる作業です。インストール時のオプション選択には多少の知識が必要です。3番目の作業はUSBメモリーのESP (EFI System Partition)をマウントして、適切なkextファイル追加し、config.plistを正しく編集する作業です。このように2番目3番目の作業には、ハードウェア構成に関係したいろいろなノウハウが必要です。でも、それを知らなくても無難に起動できるUSBメモリーを作成してくれるところがUniBeastの便利なところです。\n作業の準備 まずは、macOSが動いている環境（MacもしくはHackintosh）が必要です。これに、インストールしたいmacOSのインストーラをAppleのサイトからダウンロードしておきます。具体的な方法は上記のアップルのサイトに説明があります。この作業で、アプリケーションフォルダにmacOSインストーラが保存されます。\n次に、UniBeastをtonymacx86からダウンロードします。macOSのメジャーバージョン別に用意されています。この記事の時点での最新はMojaveです。\n12GB以上（Appleのサイトの情報）の容量のUSBメモリーを用意します。これをGUIDスキームでMac OS 拡張フォーマットでフォーマットします（どちらもディスクユーティリティ.appのデフォルト設定です）。\nUniBeastで起動USBメモリーを作成 macOSインストーラがアプリケーションフォルダにあり、フォーマットしたUSBメモリが挿されたmacOSマシンで、UniBeastを起動します。言語が英語になっていないと起動しないので、必要ならばシステム環境設定の「言語と地域」から英語に設定しておきます。\nUniBeastを起動して注意事項のページを経ると、USBメモリーを選択する画面になります。ここで、対象のUSBメモリーを選択します。内容はこのあと削除されるので、選択を間違えないでください。\n次にmacOSインストールファイルの選択です。AppleのサイトからMojaveをダウンロードするとmacOS Mojaveインストール.appというインストーラプログラムがアプリケーションフォルダに出来上がります。UniBeastはアプリケーションフォルダにあるインストーラを表示しますので、選択します。\n次にESPにインストールする (UEIF Boot Mode) か、macOS本体パーティションにインストールする (Legacy Boot Mode) かの選択肢が出ます。Cloverのインストーラを使う場合でもこの選択を問われます。この先、バニラなインストールを目指すので、混乱しないようにここもUEFI Boot Modeを選択しておきます。\n次にグラフィックスのオプションを聞かれます。ここに出ているNvidiaとAMDのグラフィックスカードを使用する場合はチェックを入れます。いずれもかなり古いカードですので、チェックを入れる必要のある場合は少ないと思います。\nこのあと確認のウィンドウが出て、USBメモリー作成作業が始まります。USB 3.1 Gen1接続で3分くらいかかります。完成すると以下のメッセージが表示されます。\nBIOSを設定する macOSをインストールしようとしている対象のマザーボードのBIOS設定を、macOS向けに設定しておきます。最近のマザーボードではほとんどデフォルトで大丈夫ですが、一応チェックしておいてください。\nUSBメモリーで起動する このUSBメモリーを、インストール対象のマシンに取り付けて起動します。大抵は、USBからの起動を優先するBIOS設定をしていないと思います。その場合は、起動時にBIOS画面でUSBメモリーを指定する必要があります。\nUSBメモリーから起動すると、Cloverの起動ドライブ選択画面が出ます。ここで、USBメモリーを選択します。\nUniBeastの設定は、かなり汎用的な設定になっているようで、起動する成功率は高いです。今回は、ASUSのZ390マザーボード、Radeon RX580、macOS 10.14.5 Mojaveの組み合わせで実験したところ、とりあえずはインストーラが起動しました。tonymacx86で推奨されているハードウェアならインストーラ起動までは進めるのではないかと思います。\nこの後、言語を選択して、macOSのインストールを開始します。すると3-5分程度でインストール用イメージが用意され、再起動します。この時もUSBメモリーから起動します。Cloverのブート選択に、「Boot macOS Install from xxxx」という項目が増えているはずです。これを選択します。\nこの後、もう1回くらい起動します。その時も、Cloverのブート選択に「Boot macOS Install from xxxx」という選択肢があればこれを選択します。インストールが最終段階になると、この選択肢は消えて、「Boot macOS from XXXX」という項目が現れます。これを選択すれば、macOSのアカウント設定などの画面を経て、インストール終了です。\nこんな感じでインストールされます。config.plistでiMac14,2と設定されているのでiMac Late 2013になっています。\n実は、今回のハードウェア構成で試したところ、以上の手順ではmacOSインストール途中で失敗しました。そこで、次にUniBeastが作るESPの構成と、トラブル対策を紹介します。\nUniBeastが作るESP トラブル対策を説明する前に、まずはUniBeastにより作られるESPの中身を見てみます。多くのハードウェアで機能するためにNullCPUPowerManagementなどの汎用性を高めるkextなどが使われているのかと思ってましたが、使われていませんでした。標準的でシンプルな作りでした。\nefiドライバー drivers64UEFIフォルダには以下のefiドライバが入っています。無くても問題のないドライバも含まれていますが、Cloverのデフォルトに準じた一般的な構成です。必須もしくはあった方が良いドライバは、太字にした5個くらいかと思います。後で説明しますが、今回のマザーボードでは、これらのefiに加えてEmuVariableUefi-64.efiが必須であることがわかりました。\nApfsDriverLoader-64.efi （APFSドライバを取り寄せる） AptioMemoryFix-64.efi （kernel用メモリを確保） AudioDxe-64.efi （起動音を出す。あまり必要ではない） DataHubDxe-64.efi （DataHubプロトコル、すでに機能していれば不要） FSInject-64.efi （ESPに置いたkextを機能させる） PartitionDxe-64.efi （特殊なパーティションの対応。なくても良い） SMCHelper-64.efi （FakeSMCのためにNVRAMのSMCキーを保存） VBoxHfs-64.efi （HFS+を読むためのドライバ） kextファイル kextは全てkexts/Otherに入っています。ESPに全て入れてあるのでバニラな構成と言えます。macOSインストール作業ではLANは必須ではないのですが、Intel, Atheros, Realtek向けのLANのドライバが全部入っています。全てのマザボに対応するためかと思います。最近流行りのVirtualSMC.kextではなく、昔ながらのFakeSMC.kextが使われています。\nAtherosE2200Ethernet.kext （LANドライバー） FakeSMC.kext （SMCをエミュレートする必須kext） IntelMausiEthernet.kext （LANドライバー） Lilu.kext （パッチを当てるkext） RealtekRTL8111.kext （LANドライバー） WhateverGreen.kext （グラフィックス用パッチ。Liluを使用） config.plist 以下のようなconfig.plistを作ってくれます。DSDTの設定が長々とありますが、ほとんどがコメントアウトされたりfalseに設定してあり、無効になっています。その後の設定はごく一般的です。Boot Argumentsのnv_disable=1はもはや古いので不要かと思います。その代わりBoot Argumentsに-vオプションを追加しておくと、トラブル特定に役立ったのではと思いました。\nconfig.plist by UniBeast 9.2.0 - Mojave - Pastebin.com\nKextToPatchではUSBポートの15個制限を回避するパッチが書いてあります。ただこれはmacOS 10.14.4用のパッチですので、今回使用した10.14.5では使えません。他のバージョンにパッチを試みて不具合が起きないように、MatchOSキーで10.14.4以外では機能しないように設定してあります。USB個数制限を回避するためにパッチを当てる方法は、どのマザーボードでも動くので楽なのですが、macOSバージョンごとにパッチを変更する必要があります。あまりお勧めではありません。詳しくはこちらをご覧ください。\nSMBIOSではiMac14,2に設定されています。シリアル番号などは指定されていません。Cloverが適当に設定してくれます。\nトラブルとその対策 インストーラUSBメモリが完成したら、インストール先マシンで起動して、macOSをインストールします。その過程で発生しうるトラブルを時系列で解説します。\nメモリー確保の失敗 メモリー確保失敗は、Cloverで起動ドライブを選択して起動プロセスが開始した直後に発生します。-vオプションをつけていないと、白いリンゴマークに代わって禁止マークが出ます。-vオプションをつけていれば、kernel読み込みのためのメモリーの確保 (allocation) に失敗したというメッセージが読み取れます。\n今回使用したASUSのZ390マザーボードは、AptioMemoryFix-64.efiで、メモリー確保に成功します。GigabyteのZ390もこのefiファイルでOKのようです。MSIとASRockの300シリーズはAptioMemoryFix-64.efiで失敗するという報告が多数あります。メモリー空間を強制的にクリアするので副作用が心配ですが、OsxAptioFix2Drv-free2000.efiを使えば良いようです。詳細は以下をご覧ください。\nCloverインストーラの設定\nUSB個数制限問題 USB個数制限による失敗はmacOS（ここではmacOSインストーラ）が起動するプロセスの中盤以降で発生します。-vオプションをつけていないと、白いリンゴマークに代わって禁止マークが出ます。-vオプションをつけていると、メッセージが突然停止します。メッセージの表示が崩れることもあります。\nmacOSにはUSBの個数が15個までの制限がありUSB 2.0が優先されます。また、USBInjectAll.kextが入っていない場合、全てのUSB 2.0が確実に見えるわけでもなく、取りこぼしされることもあります。ということで、USB 3.0 (最近の表記で正しく書くとUSB 3.1 Gen 1) を使用しようとすると、かなりの確率でmacOSからは読めません。USB 2.0でも見えないことがあります。\nマザーボードのBIOSが制御している段階では、全てのUSBメモリーが見えています。なので、起動ドライブとして選択できるし、Cloverの起動ドライブ選択画面も出ます。しかし、その後、macOSに制御が移管されるタイミングで運悪く15個の個数制限に引っかかると、起動の途中で突然USBメモリーが認識されなくなってしまいます。当然ながら起動には失敗して、画面に禁止マークが出ます。起動作業の中程で発生します。\nUSB 3.0のUSBメモリーであっても、USB 2.0用のコネクタに接続するとUSB 2.0として機能します。なので、除外される可能性は低くなります。それでも除外される可能性はあります（今回もそれに遭遇してしまいました）。そのような場合でも、機能している2.0コネクタはどこかに必ずあるので、他のコネクタに挿し直して起動を試みます。\n今回入手した最新のUniBeastのconfig.plistには、上で説明したように、10.14.4の個数制限を回避するパッチは書いてありますが、10.14.5には対応していません。10.14.5に対応したパッチに書き換えればこのような苦労はありません。ただ、パッチで対応することはあまりお勧めできません。USB制限問題は、macOSが正しくインストールされた後で、じっくりと対応するのが良いと思います。インストール段階で、機能するUSBポートを探して対処したら良いと思います。\nNVRAMの不具合 上の2つの問題は回避できたものの、今回の試みではまだ正しくインストールできませんでした。言語選択の画面\nの後、最初の再起動の手前で画面が動かなくなります。調べたところ、efiドライバにEmuVariableUefi-64.efiが足りないのが原因でした。drivers64UEFIフォルダにこれをいれておきます。現行の300シリーズチップセットのマザーボードは、どれもEmuVariableUefi-64が必要のようです。マザーボードには設定内容を記憶するNVRAMがありますが、これがmacOSから読めない場合があります。EmuVariableUefi-64は、NVRAMをエミュレーションして、この問題を解決します。\nまとめ UniBeastですんなりとインストールできれば楽なのですが、実際にはここで説明したような問題がかなりの頻度で発生します。それならば最初から、createinstallmediaで起動USBメモリーを作って、Cloverインストーラでefiを選びつつインストールしても良いように思いました。\nmacOSがインストールできれば、Hackintoshは7割方完成です。USBメモリーから起動すればmacOSは起動できます。USBメモリーのESPを、macOSをインストールしたドライブのESPにコピーすれば、USBメモリー不要で起動させることもできます。tonymacx86の方法では、この後MultiBeastを使ってインストールを完成させます。その後、それぞれのハードウェアに合わせて、バニラに起動するよう調整するのが良いと思います。続きは以下をご覧ください。\ntonymacx86式インストール手順 (その2: MultiBeast)\ntonymacx86式インストール手順 (その3: バニラ化と調整)\n","date":"2019-06-30T15:33:31+09:00","image":"/uploads/2018/11/20181112224438.png","permalink":"/posts/5624/","title":"tonymacx86式インストール手順 (その1: UniBeast)"},{"content":"Public Betaの配布 本日 (2019/6/25) からいよいよPublic Betaが配布され、無料で誰でも試せるようになりました。去年とほぼ同じタイミングです。\nmacOS Mojave Public Beta版を試す\n無料配布のPublic版とは言っても、例年通り緩い守秘義務はあります。「Appleが公表していない情報はPublic Betaプログラム参加者以外に伝えてはいけない」のだそうです。以下の情報は公開済みの内容と思いますが、念のためにベータプログラム参加ページで登録してから読んでください。\nApple Beta Software Program\nうっかり読まないように空行を入れておきます🙂\nさて、上記のページから登録するとmacOSPublicBetaAccessUtility.dmgというファイルをダウンロードできます。この中に入っている\nmacOSPublicBetaAccessUtility.pkgを起動すると、ソフトウェアアップデートでPublic Betaが受信できるようになります。\nベータ受信機能は、ウィンドウ左下の「詳細」をクリックすれば、簡単にキャンセルもできますので、気軽に試してみましょう。\nインストール方法 ダウンロードしたCatalinaのインストーラ、Install macOS Catalina Beta.app\nを開いて、HDD内のHFS+でフォーマットした空きパーティションにインストールしてみました。使ったマシンは、こちらの構成です。Z390、第9世代CPU、Radeon RX580の構成です。\nASUS ROG MAXIMUS XI HERO (Z390), 9900K\nEFIファイル類は上記のリンク先で紹介したものをそのまま使いました。Mojaveの起動に使用している構成です。ただ、Lilu関係のバージョンチェックを避けるために、念のために\n-lilubetaall を起動オプションに追加しました。これで問題なく起動しました。\n（訂正：初稿に書いたリセット問題はCatalinaとは関係なく、BIOSの設定が足りなかったのが原因のようでした。BIOS設定の中で、System Agent (SA)関連のメモリ設定を色々変えていたら治りました。）\nコンテナ構成が刷新 Public Betaをインストールしてコンテナ構成が新しくなったことに気づきました。上で書いたように試したボリュームはHFS+の古いタイプのHDDだったのですが、Catalinaのインストールで自動的にAPFSに変換されました。さらに、APFSのコンテナが2個作られました。今回はインストール先をCatalinaという名前にしたのですが、Catalina – Dataというコンテナが新たに作成されました。ディスクユーティリティ.appで見ると以下のようになります。\nCatalinaで書き込み不可になったファイルとディレクトリー類が本体のコンテナに、それ以外の内容が – Data が末尾についたコンテナに自動的に振り分けられるようです。\nまとめ インストールは簡単でMojaveと同じ構成で起動可能です。また、サクサク動いて快適です。このままメインで使い続けても問題ないように思いました。\n","date":"2019-06-25T18:45:55+09:00","image":"/uploads/2019/06/catalinaicon.png","permalink":"/posts/5573/","title":"Catalina Public Betaが配布されました"},{"content":"高価だったVega 64が税・送料込みで4万円を切ってました。これを第9世代CPUとMojaveで動かしてみました。OOBで問題なく動作しました。\nVega 64 今回使用したVega 64はMSIから発売されているAir Boostという製品で、日本ではつい1ヶ月前に発売されたもののようです。そのMSIのプレスリリースによると予想販売価格は税別95,980円だったそうです。これがAmazonで税・送料込みで39,810円で売られていました。同じAir BoostのVega 56バージョンが39,500円と僅差だったので、これは64を買うチャンスだと思ってしまいました。そして気づいたら手にしていたこのVega 64をこちらで紹介した第9世代CPUとMojaveのビルドで動かしました。ちなみに、執筆時点では数千円値上がりしてしまっているようです。それでも予想販売価格の半額ですね。\n使用した構成 使用したマシンは、軽い作業用のコスパの良いmacOSマシンです。普通はこのようなお買い得マシンのグラボにVega 64という選択はしないかもしれません。\nMSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh\nマザーボード：MSI B360M Mortar Titanium CPU：Intel Core i3 9100F メモリー：暫定的に8GB SSD：暫定的に2.5インチSSD OS：macOS 10.14.5 Mojave OOBで動く 9100FはiGPU無しなのでそのあたりに転がっていたNvidia GTX 770を使っていました。かつてMacに搭載されたことのあるKeplerアーキテクチャなので、今でもmacOSでネイティブにサポートされています。なのでWhateverGreenとLiluだけで、特に設定なく動いていました。GTX 770を抜いて、Vega 64に挿し替えました。その結果、何事もなかったかのように動きました。Vega 64として認識されています。\nフォーラムではVegaが動かないという事例が報告されていますが、今回は全く問題ありませんでした。フォーラムを読んでいると、iGPUを無効にすると動くようになるという報告もあるので、もともとiGPUが搭載されていない9100Fだったので、余計すんなり動いたのかもしれません。もしも問題が出る人は、iGPUを無効にする、もしくはiGPU関係のメモリ設定を変えてみて下さい。\nこれまで使っていたGTX 770は古いのか、4Kディスプレイに接続した時のUI擬似解像度が1920×1080しか選択できませんでした。\nそれで問題なかったのですが、Vega 64に変えると他の解像度も選択できるようになっています。ドライバが新しいためか、4Kへの対応も充実したということかもしれません。\n再掲になりますが、使用したefi, kextファイル類とconfig.plistを以下に示します。\nVBoxHfs-64.efi SMCHelper-64.efi OsxFatBinaryDrv-64.efi OsxAptioFix2Drv-free2000.efi FSInject-64.efi EmuVariableUefi-64.efi DataHubDxe-64.efi ApfsDriverLoader-64.efi WhateverGreen.kext VirtualSMC.kext USBInjectAll.kext Lilu.kext IntelMausiEthernet.kext AppleALC.kext config.plist for MSI B360M and 9100F - Pastebin.com\n","date":"2019-06-25T00:30:20+09:00","image":"/uploads/2019/06/1504012346.272_6_o.png","permalink":"/posts/5496/","title":"Radeon RX Vega 64をmacOSで使う"},{"content":"銀色のマザーボードMSI B360M Mortar TitaniumにCore i3 9100Fを組み合わせたHackintoshを作りました。予算に優しい構成ですが最新4コアCPUと現行チップセットの組み合わせで高性能です。\nMSI B360M Mortar Titanium チタン色マザボ MSI B360M Mortar Titaniumは、現行チップセットを使ったマザーボードで唯一の銀色マザーボードです。一世代前の200シリーズの時には白いマザーボードとしてH270搭載のMSI H270M MORTAR ARCTICがありました。MORTAR ARCTICは北極圏をイメージした白と灰色のシリーズでした。Titaniumも昔からあるMSIのシリーズで、チタンをイメージした銀色のマザーボードです。チタン色の塗装は綺麗で、基板の厚みがあり、たわむこともなくしっかりとした作りです。でも前作はPCIeスロットやメモリースロットまで白にこだわっていたのが、本製品では黒くなってしまいました。\nB360チップセット MSIの白系マザボは200シリーズでH270だったものが、300シリーズになったらB360に格下げになってしまいました。B360はZ390, H370と同世代チップセットの廉価版です。Z390と比べると、H370と同様にオーバークロック非対応でCPU直結PCIeの分割機能がありません。またH370と比べるとチップセット経由のPCIe数が20から12レーンに減り、USBポートが減ってます。Intel Rapid Storage Technologyにも非対応です。とはいえ、SLIやCross Fireに非対応のmacOSではCPU直結PCIeの分割機能は出番がありません。またIntel Rapid Storage Technologyも非対応です。チップセット経由のPCIe数も、これを使用するスロットが3本しかないmicro ATX規格なら十分な数です。ということで、スペックを冷静に分析するとB360でも十分なのかと思います。チップが廉価版なのでマザーボード価格もそこそこお買い得です。\nこのマザーボードにはx16, x1, x1, x16のPCIeスロットが付いています。CPUに一番近いx16はCPU直結の高速なスロットでGPU用です。後のx1, x1, x16スロットはチップセット経由のPCIeです。CPUから遠い方のx16スロットは形状はx16ですが実際にはx4です。拡張スロット全体で6レーン使っているわけです。\nSSD用の（Key Mの）M.2スロットが2個あります。それぞれPCIe x4です。しかしM2_2（CPUから遠い方のスロット）はPCIE_4（CPUから一番遠いPCIeスロット）と共用なので、PCIE_4にカードを挿すと使えません。なのでM.2では4レーン使っています。PCIeスロットと合わせて合計10レーンです。チップセットの上限が12レーンなので、排他動作にせざるを得なかったのだと思います。\n一方、M2_1（CPUに近い方）はSATAにも対応していますが、4個のSATAコネクタのうちSATA2と排他利用です。チップセットのSATAは6個あるのですが、4個しか配線されていないようです。MSIのマザーボードはSATA数が少ない傾向がある気がします。PCIeカードで拡張したいところです。\nCore i3 9100F 9100Fは先月発売されたばかりの最新CPUです。第9世代 (Coffee Lake Refresh-S) のCPUの中で一番安いモデルで1万円前半で買えます。\nCore i3ですがコア数は4あります。安価で高性能なので、B360チップセットと組み合わせるのに最適なCPUかもしれません。FモデルはiGPUを搭載していない製品です。噂によるとインテルの製造技術に問題があってチップ製造の歩留まりが悪いので、iGPUを無効にしたバージョンであるFモデルで凌いでいるらしいです。\nmacOSを動かす とりあえずmacOSを動かしてみましたところ、意外と簡単に動いてしまいました。\nハードウエア構成 マザボとCPUは上で書いたとおりです。それ以外は、たまたま手元に転がっていたパーツを使いました。GPUはNvidiaの古いカード、GTX 770です。KeplerアーキテクチャのNvidiaカードはmacOSのドライバがネイティブに対応します。NvidiaのWebDriverを必要としないのでMojaveでも使えます。メモリもその辺りに転がっていたものです。8GBしかつけていません。WiFiやBluetoothはまだ取り付けていません。\nマザーボード：MSI B360M Mortar Titanium CPU：Core i3 9100F GPU：Nvidia GTX 770 2.5インチSATA SSD BIOS設定 マザーボードのBIOS設定は、開封したまま、デフォルトのままです。色々な項目のデフォルト設定が、macOS向きの設定でした。iGPUの無いCPUなので、GPU設定も迷いようがありませんでした。デフォルトのまま動くのですが、ブートするドライブをUEFI限定にして、またMSIマザーボードの便利な機能GO2BIOSを有効にしました。GO2BIOSは電源スイッチ長押しでBIOS設定画面が現れる機能です。\nOSのバージョン macOS 10.14.5を、2.5インチSSDにクリーンインストールしました。このSSDのEFI部分に以下のファイルを置きました。\nUEFIドライバ drivers64UEFIフォルダの中身は以下です。不要なものもあるかもしれません。今回のマザーボードに必須と思われるのがOsxAptioFix2Drv-free2000.efiです。当初はAptioMemoryFix-64.efiで起動したのですが、条件を変えると起動しない場合がありました。メモリーマップの状況が変化するためと思われます。色々なビルドを見ると、MSIとASRockの300シリーズチップセットではOsxAptioFix2Drv-free2000.efiが必要らしいです。バージョンアップされていない古いドライバなのであまり使いたくないのですが、確実に起動させるためには使わざるを得ないです。VirtualSmc.efiはVirtualSMC.kextと一緒に配布されているドライバーです。\nVBoxHfs-64.efi VirtualSmc.efi OsxAptioFix2Drv-free2000.efi FSInject-64.efi EmuVariableUefi-64.efi ApfsDriverLoader-64.efi 追記：slideパラメタを利用すればOsxAptioFix2Drv-free2000.efiを使用しなくて済むようです。詳しくはこちらをご覧ください。\nKext類 以下のkextをkexts/Otherに入れました。マザーボード搭載のLANチップはインテル製なのでIntelMausiEthernet.kextを使います。AppleALCで音も出ました。HDMIからも音が出ます。\nWhateverGreen.kext VirtualSMC.kext USBInjectAll.kext Lilu.kext IntelMausiEthernet.kext AppleALC.kext Config.plist 9900Kで使用したconfig.plistがほぼそのまま使えました。機種IDも9900Kの時と同じiMac19,1にしました。シリアル番号やUUIDなどは変更しました。\n9900Kのconfig.plistをそのまま使ったところ、クイックルックでJPEGファイルを見る（JPEGファイルを選択してコマンドスペースを押して内容を表示する）ことができませんでした。9100FはiGPUが無いことが原因らしいです。9100FでJPEGのクイックルックを機能させるためには以下のブートオプションが必要でした。オプション名はshiki用のものに見えますが、shikiはWhateverGreenに統合されたのでWhateverGreen用オプションです。フォーラムで教えていただきました。ありがとうございます。\nshikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94 使用したconfig.plistを以下に置いておきます。\nconfig.plist for MSI B360M and 9100F - Pastebin.com\n動作確認 以上の設定で問題なく動きました。スリープも機能しているようです。CPUも正しく認識されているようです。\nsysctlコマンドでCPUの名前を見ると以下のようになります。\n$ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i3-9100F CPU @ 3.60GHz Nvidiaの古いグラフィックスでしたが4KのUI擬似解像度にも対応しています。Metalにも対応しています。\nGeekbenchのスコアは、シングルが約5300でマルチコア(4コア4スレッド)で約15000でした。以前測定した9900Kはシングル6086, マルチコア(8コア16スレッド)で30114でした。コア数なりの差です。価格差を考えたらよくできたCPUだと思います。\n今後は、引き続き使用して不具合を確かめると同時に、USBの15個制限に対する調整、M.2 SSDへの移行、無線モジュール搭載などを進めたいと思います。\nRadeon Vega 64に載せ替える 価格が下がっていたのでRadeon Vega 64に載せ替えました。こちらをご覧ください。\nRadeon RX Vega 64をmacOSで使う\n","date":"2019-06-21T23:16:11+09:00","image":"/uploads/2019/06/product_6_20180402151821_5ac1d93dd6d06.png","permalink":"/posts/5459/","title":"MSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh"},{"content":"GitHub - khronokernel/Catalina-GPU-Buyers-Guide: Host for files for the Catal\u0026hellip;\nCatalinaのためにどのGPUを選んだら良いかという記事がありましたので抄訳して紹介します。また、その後のmacOSでNaviシリーズがサポートされたので、この情報を追記しました。結論は、AMDならばRadeonの\nRX 6600, RX 6600 XT, RX 6800, RX 6800 XT, RX 6900 XT RX 5500, RX 5500 XT, RX 5600, RX 5600 XT, RX 5700, RX 5700 XT RX 460 / 560 / 470 / 570 / 480 / 580 / 590 RX Vega 56 / 64 / VII を、Nvidiaならば\nKepler シリーズ (GTX 6xx, 7xx など) が動きます。ただし、MontereyからKeplerシリーズは動かなくなりました。古いmacOSからドライバを持ってくることで動かすことは可能です。\nReleases · chris1111/Geforce-Kepler-patcher\n（ここから抄訳）\nNvidiaとWebDriverの現状 WebDriverが使えなくなった状況のままMojaveからCatalinaに移行しそうです。おそらくはこのあと、MojaveでもCatalinaでもWebDriverはサポートされないと思われます。ただしKeplerベースのGPUを使っているユーザは引き続きmacOSネイティブのドライバが利用できます。\nなぜWhateverGreenが必要なのか？ macOSがネイティブにサポートするグラフィックスカードなのに、なぜWhateverGreenとLiluを使う必要があるのでしょうか？その理由は、PCとMacの内部配線が異なるため、Hackintoshでうまく機能しないためです。これを回避するために、デバイスの名前変更、フレームバッファ接続、オーディオコネクタのパッチ適用、ACPIを介したaty_config、cail_propertiesの変更などが必要です。WhateverGreenとLiluがこれらの作業を行ってくれます。内部構造に詳しい人達によってWhateverGreenは開発され、必要に応じてアップデートされていますので、これを使用しない理由はありません。以下の推奨カード、iGPUのすべてでWhateverGreenとLiluを使ってください。\nそのほかに知っておくべきこと macOSはSLI、Crossfire、複数コアGPU (Radeon Pro Duo)のいずれもサポートしていません HDMI / DisplayPortを介して音声出力するには、AppleALC.kextとその他のIO-REG編集が必要になる場合があります GPUオーバークロックができるのはVega 10 GPUだけです（PyVegaというツールが必要） サポートされているGPUとサポートしていないGPUを併用するとスリープやその他の機能が中断される問題があります。詳細については、GPUを無効化するためのガイドを参照してください。 動くAMD GPU Navi シリーズ Catalina 10.15.1からRX 5500, 5600, 5700シリーズがサポートされました。 Big Sur 11.4からAMD RX 6800, RX 6800XT, RX 6900XTがサポートされました。 Monterey 12.1からAMD RX 6600, 6600 XTがサポートされました。 Naviシリーズでは以下の GPUがネイティブにサポートされています。ただし起動オプションに、agdpmod=pikeraを追加する必要があります。\nAMD Radeon RX 6600, RX 6600 XT, RX 6800, RX 6800 XT, RX 6900 XT AMD Radeon RX 5700, RX 5700 XT, RX 5700 XT 50th Anniversary AMD Radeon RX 5600, RX 5600 XT AMD Radeon RX 5500, RX 5500 XT Vega 20シリーズ MojaveからVega 20シリーズのGPUがネイティブにサポートされています。すなわち\nRadeon VII が動きます。\nVega 10シリーズ High SierraからVega 10シリーズのGPUがネイティブにサポートされています。すなわち\nVega 56 Vega 64 Vega 64 Liquid Vega Frontier Edition Radeon Pro WX 9100 Radeon Pro WX 7100 が動きます。Vega 10で避けるべきGPUブランドはXFXとSapphireです。ビデオBIOSとmacOSの互換性に問題があるようです。\nRadeon 400/500 シリーズ (Polaris) PolarisはmacOSによりネイティブにサポートされています。以下のシリーズです。ローエンドのRX550はPolarisではなくLexaコアなのでmacOSでサポートされていません。Polarisシリーズで避けるべきGPUブランドはXFXとASRockです。これもビデオBIOSとmacOSの相性に問題があります。解決できたという報告もありますが駄目なこともあるようです。避けたほうが無難です。\n（訳注：コメントいただいた内容によると、以下の状況でASRockが問題なく使用できたそうです。ASRock, Phantom Gaming D RX580、macOS 10.15.4 、Metal: 対応、機能セットmacOS GPUFamily2 v1、CPU: Core i7 2600K、RAM: DDR3 32GB、M/B: ASUS MAXIMUS V GENE。またフォーラムでもASRockのRX 580が動いた報告をいただいています。ASRockを避ける必要はどうやら無いようです。）\nRX 460/560/560X RX 470/570/570X RX 470D RX 480/580/580X RX 590 WX 2100 WX 3100 WX 4100 WX 5100 GCN 3 以前のカード GCN 3以前のカードは、CatalinaでMetalをサポートすると思われますが、一部のカードは動かない可能性もあります。おそらくHD 7XXXシリーズ以降のGPUはMetal互換ですが、Catalinaでの動作確認はされていません。\nRadeon R9 3xx (Fiji) FijiもCatalinaでサポートされるとは思われます。しかし報告がありませんのでR5およびR7カードの成功を保証することはできません。また、リファレンスデザインと違うカードでは、macOSで動かすために多くの作業を必要とする場合があります。という条件のもとで、サポートされているカードは以下です。\nR7 240 R7 250 R9 260/360 R7 260x/360x R7 265 R7 270/370 R9 270X/370X R9 280/380 R9 280x/380x R9 290/390(FakeID が必要) R9 290X/390X R9 390(FakeID が必要) R9 Nano R9 Fury R9 Fury X 動かないAMD GPU Navi シリーズ (RX 5000) macOSにはNavi用ドライバがありません。このカードが入っているとスリープなどの機能に支障をきたします。その場合は、サポートされていないGPUを無効化にするためのガイドを参照してください。以下のカードはサポートされていません。\n訳注：「動くAMD GPU」のセクションに追加したように、Catalina 10.15.1から元記事で紹介されている以下のカードは動きます。\nRX 5700 RX 5700 XT RX 5700 XT 50th Anniversary Edition Lexa シリーズ (RX 400/500) Polaris GPUに似た型番ですが、全然異なり、どのバージョンのmacOSもサポートしていません。これもスリープ機能などで問題を引き起こしますので、併用する場合は、サポートされていないGPUを無効化にするためのガイドを参照してください。以下のカードはサポートされていません。\nRX 540/X RX 550/X 動くNvidia GPU Kepler シリーズ (GTX 6xx, 7xx) KeplerシリーズはCatalinaで動作する唯一の100％ネイティブのNvidiaカードです。このうちGTX 650Ti、660、660tiで問題が報告されていますが、これはmacOSがGK106コアをサポートしていないことが原因です。（訳注：コメントでいただいた情報によると、Mojave,Catalina環境では、GK106のバグは直されたようで、問題なく動くようです。）\nもう一つの注意点は、初期の製品には、FermiコアなのにKeplerコアと紛らわしい型番のローエンド製品があることです。また後期の製品のうち、GTX 745、750、750tiはKeplerではなく次世代のMaxwellですので注意が必要です。（訳注：こちらのページを見ると、どの製品がどのアーキテクチャなのかわかります。コア名がGFなのがFermi, GKなのがKepler, GMなのがMaxwellです。GKの製品を選べば良いです。 ）\n動作するカードは以下です。\nGTX Titan (GK 110 Maxwell core) GTX Titan Black (GK 110 Maxwell core) GTX Titan Z (macOSでサポートされている数少ないデュアルGPUの一つ) GTX 780/Ti GTX 770 GTX 760/Ti GT 740 GT 730 (GK208 variant) GT 720 GT 710 GTX 690 (macOSでサポートされているもう一つのデュアルGPU) GTX 680 GTX 670 GTX 660Ti GTX 660(MUST BE RUNNING A GK 104 core, NOT GK 106)（訳注：GK 106もokらしい。) GTX 650(GK 107 core) GT 640(Kepler edition, GK 107/208 core) GT 630(Kepler edition, GK 107/208 core) Quadro 410 Quadro K420 Quadro K600 Quadro K2000/D Quadro K4000/D Quadro K4200 Quadro K5000 Quadro K5200 Quadro K6000 動かない nVidia GPU Turing シリーズ (GTX 20xx, 16xx) 以下のカードはどのmacOSでも動きません。\nTitan RTX RTX 2080/Ti RTX 2070 RTX 2060 GTX 1660/Ti GTX 1650/Ti Quadro RTX 4000 Quadro RTX 5000 Quadro RTX 6000 Quadro RTX 8000 Volta シリーズ 以下のカードもどのmacOSでも動きません。\nTitan V Titan V CEO Edition Quadro GV100 Pascal Series (GTX 10xx) PascalとMaxwellのサポート状況についてはみなさんご存知と思いますが、簡単に繰り返します。MojaveとCatalinaではサポートされていませんが、High Sierra 10.13.6以前ならばNvidiaのWebDriverとWhateverGreenの組み合わせで動きます。この条件で動くカードは以下です。\nGTX Titan X(GP 102-400 Pascal core) GTX Titan Xp(GP 102-450 Pascal core) GTX 1080/Ti GTX 1070/Ti GTX 1060 GTX 1050/Ti GT 1030 Quadro P400 Quadro P600 Quadro P620 Quadro P1000 Quadro P2000 Quadro P4000 Quadro P5000 Quadro P6000 Quadro GP100 Maxwell シリーズ (GTX 9xx, 745, 750 とその ti版) GTXでは900番台がMaxwellです。ただ、GTX 745, 750, および750tiは型番が紛らわしいですがMaxwellベースです。MaxwellシリーズもPascalと同じ状況です。つまり、以下のカードは、High Sierra 10.13.6以前ならばNvidiaのWebDriverとWhateverGreenの組み合わせで動きます。\nGTX Titan X(GM 200 Maxwell core) GTX 980/ti GTX 970 GTX 960 GTX 950 GTX 750/ti GTX 745 Quadro K620 Quadro K1200 Quadro K220 Quadro M2000 Quadro M4000 Quadro M5000 Quadro M6000 NVS 510 Intel CPU 内蔵 GPU iGPUを動かすために、FrameBufferパッチを適用する必要があります。また、Pentium、Celeron、Atom CPUに存在するiGPUは、ネイティブにサポートされたことがなく、かなりの作業が必要になるため、除外します。\nWestmere i3/5/7-xxx 単にHD Graphicsと呼ばれていたiGPUです。High Sierra 10.13.6までのmacOSで動きます。残念ながらMojaveではサポートされなくなりました。古いkextを使って無理やり動かすことは可能です。\nSandy Bridge i3/5/7-2XXX HD 2000, HD 3000です。これもHigh Sierra 10.13.6までのmacOSで動きます。残念ながらMojaveではサポートされなくなりました。古いkextを使って無理やり動かすことは可能です。\nIvy Bridge i3/5/7-3XXX HD 4000に関しては、Catalinaで完全にネイティブに動きます。一方、HD 2500に関しては、Mojaveで一部分しかサポートされず、Quick Sync機能がサポートされていません。\nHaswell i3/5/7-4XXX 以下のiGPUです。ほとんどがCatalinaでネイティブに動きます。ただHD4400だけは、DeviceID改変 + FakePCIID.kext + FakePCIID_HDGraphics.kextが必要か、もしくは、APCIパッチが必要です。\nHD 4200 HD 4400(FakeID が必要) HD 4600 HD 5000 HD 5100 HD P4600(動くはず) HD P4700(動くはず) Broadwell以降のiGPU 以下のiGPUです。すべての動作報告が得られているわけではありませんが、Catalinaで使えると考えられます。\nHD 5300 HD 5500 HD 5600 HD 6000 HD 6100 HD 6200 HD P5700(動くはず) Iris Pro P6300 Skylake i3/5/7-6XXX 以下のiGPUです。すべての動作報告が得られているわけではありませんが、Catalinaで使えると考えられます。\nHD 510 HD 515 HD 520 HD 530 HD P530 Iris 540 Iris 550 Iris Pro 580 Iris Pro P555 Iris Pro P580 Kabylake i3/5/7-7XXX 以下のiGPUです。すべての動作報告が得られているわけではありませんが、Catalinaで使えると考えられます。ただし、Pentium G4560に搭載されているHD 610は動きません。\nHD 615 HD 620 HD 630 Iris Plus 640 Iris Plus 650 Kabylake refresh/ Coffeelake i3/5/7-8XXX/9XXX 以下のiGPUです。すべての動作報告が得られているわけではありませんが、Catalinaで使えると考えられます。ただし、i3 8100と8350Kはそれ以外のCPUとは違うUHD 630を使用しています。\n（訳注：対応方法はこちらをご覧ください。）\nUHD 610 UHD 620 UHD 630 Iris Plus 655 早い話、何を買ったら良いの？ 現時点でお勧めできるカードはAMDのPolaris(Rx 4xx, 5xx) 以降だけです。AMDのGCN 3以前とNvidiaのKeplerのような古いカードも動きますが、いつサポートを打ち切られるかわかりません。なので以下がお勧めカードです。リファレンスカードが一般的に安全です。XFXは避けたほうが良いです。\nRX 460/560 RX 470/570 RX 480/580 RX 590 RX Vega 56 RX Vega 64 Radeon VII RX 5500, RX 5500 XT, RX 5600, RX 5600 XT, RX 5700 / 5700 XT RX 6800, RX 6800XT, RX6900XT （抄訳おわり）\nRedditの反応 この元記事に関してredditでいくつかコメントがありました。\nVegaではXFXとSapphireを避けるべき？ r/hackintosh - Avoid Sapphire and XFX Vega?\nこれに対するコメントは以下のようでした。\nSapphireブランドのVega 56を使っているが問題は無い XFXブランドのVegaは明らかに避けた方が良い SapphireブランドのVegaは快調に使えている報告もあるがトラブっている報告もある。トラブルは厄介で解決したという報告は稀。 Vegaを買うならMSIかASUSが良い。Gigabyteも良さそうだけどあまり出回っていないためか2件しか動作報告が無い。 Radeon VIIのブランド毎の違いはある？ r/hackintosh - Differences in Radeon VII brand?\nこれに対するコメントによると、「Redeon VIIは全てAMDが作っているリファレンスカードで、VBIOSのソースコードも提供されていない。そのためどのブランドのカードも同じもの」なのだそうです。\n","date":"2019-06-16T17:25:04+09:00","image":"/uploads/2019/06/catalina-gpu-buyers-guide.jpg","permalink":"/posts/5422/","title":"macOSのためのGPUの選び方"},{"content":"USB Type-Cは逆さにも挿せる便利なUSBコネクタです。最近のほとんどのマザーボードに搭載されています。Z390/H370以降のマザーボードならOOBでgen 2の速度が達成できます。\nUSBの速度 まずはUSBの規格のおさらいです。今のコンピュータで使えるUSBには以下の三種類があります。\nUSB 2.0 速度は480Mbps。以下では簡単に2.0と書きます。5V、接地、信号線2本（D+とD-) の4本の配線を使います。D+とD-は、一般的にはhigh/lowが逆で動作しますが、特別の場合にはどちらもhighやlowになります。 USB 3.1 Gen 1 速度は5Gbps。長い間USB 3.0と呼ばれていた規格です。以下ではGen 1と書きます。信号線は、送信用に2本、受信用に2本の合計4本になります。それぞれの2本は、high/lowが逆になる差動対です。互換性のためにUSB 2.0の配線と一緒に使われます。 USB 3.1 Gen 2 速度は10Gbps (毎秒10Gビット)。以下では簡単にGen 2と書きます。また、Gen 1とGen 2のことをまとめて3.1と書くことにします。配線は Gen 1と同じです。 USBのコネクタ 速度の規格とは別に、コネクタもいろいろあります。ここではUSB AとUSB Type-Cを説明します。\nUSB Aコネクタ 一般的な四角のコネクタです。2.0, 3.1のどちらもAコネクタを使えます。\nのぞきこむと4個の接点が見えます。これは2.0が使う電源、接地、D+、D-の4本です。\n3.1も同じ形のコネクタを使い、やはりのぞきこむと4本の接点があります。ただこれは互換性のために残された2.0のコネクタです。なので3.1対応のAコネクタに2.0のケーブルや機器を接続すると2.0として機能します。3.1用のAコネクタの奥の方には、3.1のために、さらに5本のピンがあります。この5本は、送信用の2対、受信用の2対、接地用の1本です。\nUSB Type-C コネクタ USB Type-Cのコネクタは24ピンで、逆挿ししても機能します。なので以下のように、上下に点対称でピンが配置されています。\n中央のD+, D-は2.0の速度の通信のためのピンです。メス側（マザーボード側）は2組ありますが、これに接続するケーブル側は片方しかありません。なので、実際には裏か表の1組（D+, D-）だけが動作します。そこで、表のD+, D-と裏のD+, D-は同じものです。\nこれに対して3.1のための高速通信ピンには独立した2組があります。TX1+, TX1-, RX1+, RX1-の4本は1組目のピンで、TX2+, TX2-, RX2+, RX2-の4本が2組目のピンです。2組の3.1があるので同時に通信したら2倍高速になるような気もします。しかし、多くのマザーボードでは内部に3.1用USBハブを持っていて、TX1+, TX1-, RX1+, RX1-と、TX2+, TX2-, RX2+, RX2-は、1本の3.1を分岐しているだけのようです。なので同時に通信できたとしても合計で1本分の速度にしかならないです。\nType-Cの特殊能力 USB Type-C PD Type-Cには以前のUSBコネクタには無かった新しい機能があります。その一つがPD (Power delivery パワーデリバリー)機能です。Aコネクタなどでも5Vの電源を供給していて、これを使って機器に電力供給したり充電したりしていました。これをさらに強化したのがType-CのPD機能です。PDでは、上記のコネクタに示す4本のVBUS線を使って大容量の電力を供給します。しかし、配線に流せる電流量には上限があります。なので必要に応じて電圧を上げて、同じ電流でより多くの電力を供給する工夫がされています。そのために、CCと書かれたピンを使って送電側と受電側で何ボルトに対応しているのかネゴシエーションします。双方が高電圧に対応している場合、20Vまで電圧を上げて、5Aまでの電流を流します。これで最大100Wもの電力を供給します。\n多くのマザーボードはPDに対応していません。なのでMacBookを接続してもACアダプターほどの速度で充電できません。市販の30W PD対応ACアダプターとASUS ROG MAXIMUS XIで充電時間を比較しました。以下のように、ACアダプターだと1時間46分で充電できるところが、マザーボードだと約6時間かかるという表示になりました。\n単純に比例計算するとマザーボードの供給電力は9Wのようです。通常のUSB 2.0端子が5V 2A程度（10W）ですので、従来のUSBの5Vがそのまま出ているだけでPDには対応していない様子です。\n仕様書に「PDに対応している」ことが明記されたマザーボードもあります。例えば、[ASRockのZ390 Phantom Gaming-ITX/acは12V-3A (36W) までのPDに対応](https://www.asrock.com/mb/Intel/Z390 Phantom Gaming-ITXac/index.jp.asp#Specification)しているようです。このマザーボードを使えばMacBook付属ACアダプター並みの充電が可能と思われます。\nUSB Type-C Alternate-mode Type-Cのすごい機能で、それゆえわかりにくいのがオルタネートモードです。ケーブルのデータ信号線を他のプロトコルによるデータ送受信に転用できるという機能です。3.1のデータ線のうち4本、2.0のデータ線2本などが他のプロトコルの信号を流すために使えます。使えるプロトコルには、Thunderbolt 3, DisplayPort, HDMIなどがあります。Type-CのコネクタがThunderboltやHDMIなどとして使えるのはこの機能があるからです。\n現行製品でType-CがThunderbolt 3としても機能するマザーボードには、上記のASRock[Phantom Gaming-ITX/ac](https://www.asrock.com/mb/Intel/Z390 Phantom Gaming-ITXac/index.jp.asp#Specification)や、GIGABYE Z390 DESIGNAREなどがあります。ASRockのType-Cはディスプレイへの接続も可能と記されています。\nGen 1 も 2 もあるType-C USB 3.1の速度仕様には紛らわしい点が多い気がします。長い間5GbpsのUSB 3.0が使われてきて、10GbpsのUSB 3.1が登場しました。その後、前者がUSB 3.1 Gen 1、後者がUSB 3.1 Gen 2と呼ばれるようになりました。5Gbpsでも3.1と呼んで良いことになり、なんとなく騙されそうな気分になります。一方、Type-CはUSB 3.1のためのコネクタとして登場しました。なのでType-Cに装備されている3.1は当然Gen 2だと思っている人も多いと思います。実際には、Type-CにもGen 1のものとGen 2のものがあります。\nMac Macは他社製品に比べて早い時期からType-Cを積極的に搭載し、PD機能やThunderbolt, DisplayPortなどのオルタネートモード機能を採用してきました。でもUSB機能に関しては最近の機種でようやく対応したところです。MacBookシリーズではMacBookがまだGen 1です。デスクトップ機はMac ProがGen 1です。\nマザーボード マザーボードの3.1用Aコネクタにも、Type-Cにも、Gen 1とGen 2の両方があります。インテルのチップセットでGen 2がサポートされたのは300シリーズからです。（ちなみにZ370はZ270と同じ200シリーズです）。なので、300シリーズのマザーボードに搭載されているType-CコネクタはGen 2と考えて良いです。\n200シリーズ以前でも、付加価値が求められる上位機種マザーボードでは、AsmediaなどのサードパーティUSBチップを搭載してGen 2をサポートしています。これらもHackintoshで使えなくはないようですが、使われているチップのバリエーションが多く不安定要素があります。これに対して、300シリーズのチップセット搭載Gen 2はmacOSがサポートしています。OOBで使えることが確実なので安心です。\n同様な状況はGen 1の時にもありました。インテルのチップセットがGen 1（当時のUSB 3.0）をサポートしたのは7シリーズからです。それ以前のチップセットは2.0しかサポートしていませんでした。そこで色々なサードパーティUSBチップを搭載していたので、2.0は問題なく動くけどGen 1は不安定な状況でした。7シリーズになって何の問題もなくOOBで動くようになりました。\nType-Cの速度を実測する 測定方法 手元にあるマシンのType-Cの速度を計測しました。現在入手できるUSBメモリはType-C接続であってもほとんどすべてGen 1です。なので、M.2 SSDをGen 2ケースに入れて測定しました。M.2 SSDには以前のビルドでmacOSと相性の良かったWestern Digitalの250GB M.2 SSDを使用しました。\nこれをType-Cケースに入れました。これでUSB 3.1 Gen 2外付けSSDになります。このケースは透明で放熱板もついています。\nケーブルがGen 1にしか対応していなかったら台無しですので、Gen 2対応製品を購入しました。10Gbpsは電気的に厳しい周波数になるので、品質や長さに注意する必要があります。\n測定にはAmorphousDiskMarkを使いました。\nhttp://www.katsurashareware.com/pgs/adm-j.html\n素のままのSSDは、M.2接続で以下のようなスピードでした。Readが30Gbpsです。Gen 2の速度 (10Gbps) よりはるかに高速ですので、外付けケースに入れるとUSB通信速度がボトルネックになります。\nMacBook 2017のType-C 現行の製品ですがType-CはGen 1です。測定したらReadが4.3Gbpsでした。Gen 1の速度である5Gbpsと同程度です。\nMSI H270M Mortar ArcticのType-C こちらで紹介したビルトです。200シリーズのチップセットなのでGen 1です。チップセットのUSBがType-Cで使われているので、Type-CもGen 1です。MacBookと同程度の速度です。\nシステム情報を見てもスピードが5Gbpsであることが確認できます。コントローラのPCI製造元IDを見るとIntel (0x8086) なのでインテルチップセットを使っていることがわかります。ちなみにJMicron Technology Corp.は、このUSB Type-Cケースで使われているチップの製造会社と思われます。\nASUS ROG Maximus XI Hero (Z390)のType-C こちらの記事で紹介したビルドです。こちらは300シリーズのチップセットなのでGen 2です。速度が9.7Gbpsと、ほぼGen 2の上限の10Gbpsになっています。\nシステム情報を見てもスピードが10Gbpsであることが確認できます。これもIntel (0x8086) のチップセットを使っています。\n","date":"2019-06-09T17:30:24+09:00","image":"/uploads/2017/09/20170930110251.png","permalink":"/posts/5314/","title":"USB 3.1とType-Cコネクタ"},{"content":"拡張性の高いMac Proが6年ぶりに復活しました。PCIeスロットがなんと8本も装備されているようです。昔ながらのMac Proが復活したことはHackintoshにとっても嬉しいニュースです。\nMac Pro\nPCIeスロットが復活 スロットは復活しないか、復活したとしても独自仕様になるのではと心配していました。なので標準規格のPCIeスロットが復活してよかったです。しかも4本しかなかった2012 Mac Proよりも本数が増えて8本もあります。太古のMacintosh IIですら6本でしたので、Mac史上最強の拡張性を誇ります。8本のうち4本は通常の倍の幅のカード用なので、標準PCIeの12本分のマザーボード領域が拡張スロットのために使用されています。ATX規格（最大7本）よりもはるかに拡張性があります。拡張性のなくなったゴミ箱Mac Proが不評だったことの反動ですね。これでmacOS対応のPCIeカードが、昔のように色々な会社から販売される可能性が高まりました。Hackintoshで使えるカードが増えるはずです。\nケースの形も期待以上 新型は、昔のタワー型Mac Proから、光学ドライブと3.5インチベイを取り外して、拡張スロットを増やしたような形状です。なので全体の大きさも重量もそれほど変わりません。（旧型が51.1 x 20.6 x 47.5 cm 18.1 kgに対して新型は52.9 x 21.8 x 45.0 cm 18.0 kg）穴だらけの外観は賛否両論あるようですが、昔のMac Proと同様に開けやすくてメンテナンス性の高い設計は好感が持てます。\n昔のタワー型Mac Proにも取手と足がついていましたが、あまり実用的ではありませんでした。握ろうとすると角が立っていて手が痛かったです。アルミ板を曲げた構造だったので、見た目より華奢で、足の部分が変形しやすかったです。2019モデルの取っ手と足はステンレス丸棒らしく、頑丈で持ちやすそうです。キャスターも取り付けられるようです。ケースデザインはMac Proモデルの中で一番良いかもしれません。目ざといPCケースメーカーから、これを真似た構造のケースがすぐに発売されそうで楽しみです。Mac ProみたいなHackintoshが作れるようになると思います。\nHackintoshする必要性 この暗黒の6年間は、拡張性のあるMac製品が不在でした。なので拡張性のあるMacが必要なら、Hackintoshしか選択肢がありませんでした。その状況が6年前に戻り、拡張性のある最高グレードのハードウェアが欲しい場合には、再びアップル製品を買うことができるようになりました。なのでHackintoshの必要性は下がったと思います。ただ6年前と同様に、「Mac ProとMac miniの中間の性能でディスプレイ無しのデスクトップMacが欲しい」という要望にはHackintoshしか応えられません。デスクトップマシンとして一番需要のあるプロダクトラインが不在なのは以前と同じです。価格帯で見ても、miniが9万円からですが、新Proは5,999ドルからと、その間にかなりギャップがあります。この中間なら支払えるので、この中間の性能のデスクトップが欲しいというユーザは多いと思います。\n搭載パーツとHackintosh 新Mac ProのCPUは公表されているコア数、クロック数などの仕様から、\nIntel Xeon W3223 Intel Xeon W3235 Intel Xeon W3245 Intel Xeon W3265M Intel Xeon W3275M だと思われます。価格は749ドルから7,453ドルだそうです。これらのCPUを使ってのHackintoshは可能だと思われますが、今まで同様、メインストリームのCPUを使うより設定は大変だと思います。\nグラフィックスカードは、AMD Radeon Pro 580X、AMD Radeon Pro Vega IIとのことです。どちらも新しいGPUのようですが、前者はiMac 2019にも搭載されています。後者はVega 20をベースにしたGPUらしいです。今までも、AMDはApple用に特別バージョンのGPUを提供していて、どれもProという名前が付いています。無印のオリジナルのモデルに比べてPro版は、Macの小さな筐体に合わせて少しクロックを落として発生熱量を下げているようです。何れにしてもRadeon RX 580やVegaがmacOSと相性が良い現状は変わらないと思います。新Mac Proは一番安いモデルでも5,999ドルだそうです。おそらく8コア12スレッドのXeon W3223とRadeon Pro 580Xが搭載されるのだと思います。i9 9900KとRX 580で組めば1/4くらいの価格で同程度の性能が手に入りそうです。\n新Mac ProではT2チップが搭載されました。iMac 2019では搭載されなかったので、デスクトップではT2を使わないのかもという観測がありましたが、違っていたようです。もしもT2チップがハードウェアへのアクセスや拡張性を監視するようになると、Hackintoshに影響が出るかもしれません。でも先のことなので心配しても仕方ないでしょう。\n","date":"2019-06-05T22:18:02+09:00","image":"/uploads/2019/06/image.png","permalink":"/posts/5299/","title":"2019年式Mac Pro"},{"content":"SATAポートをASM1061搭載の格安PCIe拡張カードを使って増設しました。macOSから見たSATAチップの互換性は高いようで、大抵の拡張カードはそのまま「一般的なSATA」として認識されて動作します。\n減少するSATAポート マザーボードに搭載されているSATAポートの数が減っています。HDDの容量が増えたので、3.5インチのHDDを多数搭載する人が減ったためかもしれないです。光学ドライブも使われなくなりました。高速SSDはM.2でPCIeに直接接続するようになりました。このような理由なのか、従来のフルサイズマザーボードにはSATAが8本くらい搭載されていたところが、今は多くて6本止まりです。\nSATA最大数が6本なのには理由があります。現行の300シリーズチップセット (Z390, H370, Q370, B360) がサポートするSATA 3.0の数が6本だからです（H310は4本）。これ以前のチップセットでも、サポートするSATAの数はだいたい6本でした。6本を超えるSATAポートを搭載したマザーボードは、チップセット以外にサードパーティのSATA 3.0チップを搭載していたのです。サードパーティメーカーには、ASMedia, JMicron, Marvellなどがあります。\nSATAインタフェースカード 今の時代、SATAは6本もあれば大体足ります。でも昔風の大型ケースで作った自作パソコンに、光学ドライブを1台、3.5インチHDDを3台、2.5インチSSDを2台、さらにHDD2台搭載のリムーバブルベイを取り付けたりしていると、これでSATAが8本必要になります。そんなSATAを増やしたい人のために、PCIeソケット用SATAインタフェースカードが多数販売されています。そこで、SATAインタフェースカードを取り付けて増設することにしました。PCIeスロットを使ってなんでも増設できるところが、自作macOSマシンの強みです。\nmacOSは、インテルチップセットのSATAに加えて、サードパーティのSATAもサポートしています。なので大抵のSATAインタフェースカードはPCIeスロットに挿すだけで動作します。でも、「システム情報」のSATA装置ツリーを見ると、インテルのSATAはその名前で認識されているのに対して、サードパーティのSATAは「一般的なSATA」となっています。下は、後述するASMediaのSATAカードを取り付けた様子です。6本のインテルチップセットは正しく反映されているのに対して、追加の2本はGeneric Controllerと表示されています。\nそのような場合に、MultiBeastと一緒に配布されているAHCI_3rdParty_SATA.kextまたは、AHCI_3rdParty_eSATA.kextを使用すると、正しい名称を表示してくれるようになります。\ntonymacx86式インストール手順 (その2: MultiBeast)\n更新：eのつく方のkextを使うと、以前のmacOSでは、接続したドライブが外部ドライブとして表示され、ホットスワップできました。ただ、Sierraあたりからこれが機能しなくなったようです。Sierra以降の対処法をこちらに書いておきました。\nSATA接続HDD/SSDのホットプラグ（改訂版）\nこのkextの中のInfo.plistには、PCIeの製造者ID, 製品IDと製品名を結びつける記述があります。逆に、このkextに記述されたチップならば、macOSで間違いなく機能すると考えて良いです。すなわち、macOSで機能するSATAチップは、\nASMedia ASM1061 JMicron JMB360 AHCI JMicron JMB360 RAID JMicron JMB361 AHCI JMicron JMB361 RAID JMicron JMB362 AHCI JMicron JMB362 RAID JMicron JMB363 AHCI JMicron JMB363 RAID JMicron JMB366 AHCI JMicron JMB366 RAID Marvell 88SE9120 Marvell 88SE9123 Marvell 88SE9125 Marvell 88SE9128 Marvell 88SE9172 Marvell 88SE9230 です。これが搭載されたSATAインタフェースカードを入手すると良いです。ASM1061を搭載したカードは、2個のSATA 3.0コネクタがあります。価格は安いです。eSATA端子もついているので、外部HDDも使用できます。\nこちらはeSATAの無いタイプです。\nちょっと高級なのがMarvell 88SE9230搭載のカードです。SATA 3.0が4個付いています。放熱板も付いて少し良い作りです。\n激安SATAカードを試す 今回はSATAがあと2個欲しい状況でしたし、破格のカードを試してみたい気もしたので、ASM1061のカードを入手してみました。Amazonで送料込み1,000円未満なのがすごいです。（追記：その後、1,000円未満の商品は見つからなくなりました）中国から配送されるので、到着までに2週間ほどかかりました。購入した製品は、ジャンパーピンで、eSATAと内部用SATAコネクタを切り替えることができるタイプでした。挿すだけで認識されて機能します。AHCI_3rdParty_eSATA.kextを入れたところ、以下のように製造元・製品名が正しく表示されました。SATAが2.0しか搭載されていないタワー型Mac Proにも使えるカードだと思います。\n","date":"2019-05-25T23:17:47+09:00","image":"/uploads/2019/05/2560px-Serial_ATA.svg_.png","permalink":"/posts/2036/","title":"PCIe拡張カードでSATAを増設する"},{"content":"Kaby Lake世代CPUでの作例です。スリープ、iMessage, FaceTimeが機能します。純正無線モジュールなのでContinuity関連も問題ありません。270チップセット世代で唯一の白いマザーボードです。\nハードウェア マザーボードはMSI H270M MORTAR ARCTIC CPUはIntel(R) Core(TM) i7-7700K CPU @ 4.20GHz グラフィックスは（OOBで動作） WiFi/BluetoothはBCM94360CD（OOBで動作） BIOS設定 こちらの設定どおりです。\nマザーボード (BIOS) 設定\nソフトウェアと機種ID macOS Mojave 10.14.4 (18E226) Clover v2.4k r4920 iMac18,3 ESPの設定 kext類 (kexts/Other) AppleALC.kext IntelMausiEthernet.kext Lilu.kext USBInjectAll.kext VirtualSMC.kext WhateverGreen.kext マザーボード搭載LANはIntel I219-Vで、オーディオはRealtek ALC892 です。そこでLANのためにIntelMausiEthernet.kextを使います。また、オーディオはAppleALC.kextで動きます。\nefiドライバ (drivers64UEFI) ApfsDriverLoader-64.efi DataHubDxe-64.efi EmuVariableUefi-64.efi FSInject-64.efi OsxAptioFix2Drv-free2000.efi SMCHelper-64.efi VBoxHfs-64.efi ブート時のメモリ領域配置の関係で、OsxAptioFix2Drv-free2000.efiが必要でした。AptioMemoryFix-64.efiなどでは起動時に禁止マークが出ます。DataHubDxe-64.efiは不要かもしれません。\n追記：Clover 5018にしたついでに、OsxAptioFix2Drv-free2000.efi をOsxAptioFix3Drv.efi に交換してみたところ、問題なく起動しました。また、他のefiも調整しました。DataHubDxe.efiは不要でした。またSMCHelper.efiはVirtualSMC.kextでは不要と聞いたので外しました。代わりにVirtualSmc.efiを入れました。現時点で使用しているefiファイルは以下です(2019/7/17)。\nApfsDriverLoader.efi EmuVariableUefi.efi FSInject.efi OsxAptioFix3Drv.efi VBoxHfs.efi VirtualSmc.efi config.plist 以下です。実機で未使用のシリアル番号を生成して書き込みましたので、このままでも問題なく使えます。しかし、Apple社のサービスを使う前にシリアル番号、UUIDを独自の値に設定し直してください。\nconfig.plist for MSI H270M - Pastebin.com\n","date":"2019-05-23T23:22:28+09:00","image":"/uploads/2019/05/H270M.jpg","permalink":"/posts/5097/","title":"MSI H270M MORTAR ARCTIC, 7700K"},{"content":"Sandy Bridgeの作例です。スリープ、LAN、サウンドが機能します。iMessage、FaceTime、Continuity関連は未確認ですが純正無線ユニットをいれているので多分大丈夫です。CPUが古いのでMojaveではiGPUが動きません。たまたま手元にパーツがあったので試みましたが、Mojaveで動かすには色々無理があります。\nハードウェア マザーボードはGIGABYTE GA-Z68MX-UD2H-B3 CPUはIntel(R) Core(TM) i5-2500K CPU @ 3.30GHz (MojaveではiGPU不可) グラフィックスはNVIDIA GTX 770, ブランドはELSA（OOBで動作） WiFi/BluetoothはBCM94360CD（OOBで動作） マザーボードに搭載されているチップは以下です。\nインテルチップセットに追加のSATAがMarvell 88SE9172（OOBで動作） 有線LANがRealtek RTL8111E（RealtekRTL8111.kextで動作） オーディオがRealtek ALC889（AppleALC.kextで動作） USB 3.0がEtron EJ168（動作しません） グラフィックスカードには手元にあったGTX 770を使いました。MojaveからNVIDIAのドライバが使えなくなりましたが、GTX 770は古いカードなので、もともとmacOSがサポートしています。なのでドライバ不要で動きます。\nBIOS設定 まずはLoad Optimized Defaultsを選択して工場出荷時状態にします。その後で以下の設定をしました。\nAdvanced BIOS Features –\u0026gt; Onboard VGA –\u0026gt; Enable If No Ext PEG Integrated Peripherals –\u0026gt; PCH SATA Control Mode –\u0026gt; AHCI Integrated Peripherals –\u0026gt; F_USB30 Controller –\u0026gt; Disabled Integrated Peripherals –\u0026gt; R_USB30 Controller –\u0026gt; Disabled Integrated Peripherals –\u0026gt; GSATA3 Ctrl Mode –\u0026gt; AHCI Integrated Peripherals –\u0026gt; Onboard Serial Port 1 –\u0026gt; Disabled Power Management Setup –\u0026gt; HPET Mode –\u0026gt; 64-bit mode Onboard VGAは、PCIeにグラフィックスカードが挿さっている場合にはiGPUを動かさないという設定にします。これ以外の設定にすると非サポートのiGPUが機能しようとするためか、sleepからの復帰に失敗します。電源は回復するのですが表示が真っ黒なままになります。\nSATAのモードはmacOSがサポートするAHCIにします。最近のマザーボードではAHCIがデフォルトですが、古いマザーではIDEがデフォルトなので変更する必要があります。GSATA3の項目は、追加SATAチップのMarvell 88SE9172のことです。これもAHCIにします。シリアルポートはmacOSがサポートしていないのでDisabledにします。これが有効だと起動に失敗することがあります。HPETもmacOSに合わせて64-bit modeに設定します。\nUSB 3.0にはEtron EJ168というチップが使われています。当時のインテルのチップセットはUSB 2.0だけをサポートし、USB 3.0をサポートしていませんでした。なのでUSB 3.0はサードパーティのチップが使われました。EtronのチップはmacOSで不安定だったり使えない場合がありました。特に最近のmacOSでは古すぎてサポートされていないようです。今回の場合も、BIOS設定でUSB 3.0がEnabledになっているとMojaveの起動に失敗します。\nソフトウェアと機種ID macOS Mojave 10.14.3 (18D109) Clover v2.4k r4920 iMac12,2 機種IDはこの世代のiMacのIDを採用しました。iMac12,2ではSandy BridgeのCore i5 2500S、i5 2400、i7 2600が採用されています。MojaveではSandy Bridgeはサポート外です。なのでそのままでは起動しません。後述のようにconfig.plistで互換性チェックを無効にして使います。またiMac12,1を指定しているとMojaveのインストールもアップデートもできません。今回は起動ドライブにmacOSを別のマシンからインストールしています。\nESPの設定 kext類 (kexts/Other) AHCI_3rdParty_SATA.kext AppleALC.kext Lilu.kext RealtekRTL8111.kext USBInjectAll.kext VirtualSMC.kext WhateverGreen.kext このマザボの8個のSATAのうち2個はMarvell 88SE9172が担当しています。これを正しい名前で認識させるためにAHCI_3rdParty_SATA.kextまたはAHCI_3rdParty_eSATA.kextを使います。eの付く方はホットスワップ対応です。また、LANのチップのRealtek RTL8111Eを使用するためにRealtekRTL8111.kextを使います。オーディオのALC889はAppleALC.kextで動きます。\nefiドライバ (drivers64UEFI) ApfsDriverLoader-64.efi AptioMemoryFix-64.efi DataHubDxe-64.efi EmuVariableUefi-64.efi FSInject-64.efi SMCHelper-64.efi VBoxHfs-64.efi DataHubDxe-64.efiとEmuVariableUefi-64.efiはもしかしたら不要かもしれません。\nconfig.plist 以下です。実機で未使用のシリアル番号を生成して書き込みましたので、このままでも問題なく使えます。しかし、Apple社のサービスを使う前にシリアル番号、UUIDを独自の値に設定し直してください。\nMojaveはSandy Bridgeをサポートしていないので、iMac12,2では起動しません。そこで起動オプションに-no_compat_checkを入れて、互換性チェックを無視するよう指定しています。\nconfig.plist for GA-Z68MX - Pastebin.com\n","date":"2019-05-18T02:39:43+09:00","image":"/uploads/2019/05/4279_big.jpg","permalink":"/posts/5123/","title":"GIGABYTE GA-Z68MX-UD2H-B3, 2500K"},{"content":"（Cloverが対応したので古い情報です。）\n第9世代CPUに対応した公開版macOSである10.14.5が配布されました。更新したところCPUが「不明」の表記が改まりました。ただしCore i7になっているのでconfig.plistでCPU Typeを指定してCore i9と表示されるようにしました。\n新iMac対応Mojaveが公開される 第8, 9世代CPUに対応したiMacが出た時点のmacOSは10.14.4でした。ただ対応したmacOSは製品に搭載されるだけで、他の機種IDのマシンでは入手できませんでした。先日(2019/5/14)ようやく10.14.5が公開され、最新CPUに正式対応したmacOSが入手できるようになりました。 早速、9900Kマシンをアップデートしました。問題なく動きます。\n10.14.5から署名のないkextが除外されるという噂もありましたが、問題ありません。バニラなインストールをして、SIPも実機と同じく有効にしているから問題が無いのかもしれません。\nCPUの名称表示を改善する 10.14.4ではCPUが「不明」 「このMacについて…」や「システム情報」を見るとCPU名が表示されます。しかし10.14.4では、以下のようにCPUが「不明」になっていました。\n第9世代CPUを搭載したMacを対象にしていないバージョンでしたので、表示の用意がなかったと思われます。でもsysctlで確認すると、ちゃんと9900Kだと認識されています。\nsysctl -n machdep.cpu.brand_string Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz 10.14.5ではCPUが「Core i7」 10.14.5にアップデートしたところ、これがかなり改善されました。「このMacについて…」では以下のように表示されます。「不明」の表示は出なくなりました。でもなぜかCore i7の表示になります。\n良いところまで来たのに、今一歩足りない感じです。そこでこちらで頂いたコメントを元に、こちらからCPU情報を確認して、CPU Typeに0x1009を設定しました。config.plistの最上位dictの中に、以下のようにkeyとdictを追加すれば良いようです。\n追記：コメントいただいたように実機では0x1005だったという情報があります。0x1005の方が良いかと思い、以下も変更しました。\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;!DOCTYPE plist PUBLIC \u0026#34;-//Apple//DTD PLIST 1.0//EN\u0026#34; \u0026#34;http://www.apple.com/DTDs/PropertyList-1.0.dtd\u0026#34;\u0026gt; \u0026lt;plist version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CPU\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Type\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x01005\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/plist\u0026gt; この結果、Core i9と表示されるようになりました。（もしかしたら10.14.4でもCPU Type指定でこのようにできたのかもしれません）見た目だけなのかもしれませんが、CPU名が正しく表示されるようになると気分が良いです。\n10.14.5 + Clover 4934ではCPUが「Core i9」 追記：Cloverをリビジョン4934に更新したらconfig.plistでCPU Typeに0x1009を設定しなくても（上記の記述を全部削除しても）正しく3.9 GHz Intel Core i9と表示されるようになりました。ということで、Cloverが面倒を見てくれるようになったようですので、config.plistではCPU Typeを記載しないことにしました。ただ、「Clover 4934でiMac19,1にSMBIOS設定すると、i7 9700Kでもi9にされてしまう。」という報告が5chにありました。今後改善されると思います。\n","date":"2019-05-15T23:51:27+09:00","image":"/uploads/2018/11/mojave.png","permalink":"/posts/5116/","title":"9900KマシンをmacOS 10.14.5に更新する"},{"content":"LattePanda Alpha 800は、Intel Core m3-7Y30を搭載したシングルボードコンピュータです。MacBook 2017に搭載されているm3-7Y32のクロック違いバージョンなのでmacOSとの互換性が高いです。3回にわたって過去に紹介しましたが、まとめ記事にしました。\nハードウェア 本体は LattePanda Alpha 800 (他に864があり。搭載無線はBIOSでdisable) CPUは Intel(R) Core(TM) m3-7Y30 CPU @ 1.10GHz グラフィックスはIntel HD Graphics 615 SSDはSATA M.2 SSD WD WDS120G2G0B (NVMeも使用可能) WiFi/BluetoothはDW1560 (Continuity非対応) ソフトウェアと機種ID macOS Mojave 10.14.4 Clover v2.4k r4920 MacBook10,1 ESPの設定 kext類 (kexts/Other) WhateverGreen.kext USBInjectAll.kext RealtekRTL8111.kext IntelMausiEthernet.kext Lilu.kext FakeSMC.kext FakePCIID_Intel_HDMI_Audio.kext FakePCIID.kext FakePCIID_Broadcom_WiFi.kext BrcmPatchRAM2.kext BrcmFirmwareData.kext AppleHDA.kext AppleALC.kext efiドライバ (drivers64UEFI) ApfsDriverLoader-64.efi AptioMemoryFix-64.efi DataHubDxe-64.efi FSInject-64.efi PartitionDxe-64.efi SMCHelper-64.efi VBoxHfs-64.efi config.plist 以下に示します。これで動作するはずですが、シリアル番号、UUIDは設定し直してください。\nconfig.plist for LattePanda Alpha 800 - Pastebin.com\n外部情報 以下でESPの中に入れるべきファイルが全て配布されています。\nReleases · novaspirit/macpanda\n関連記事 このビルドに関する記事です。詳細はこちらをご覧ください。\nLattePanda AlphaでmacOSを起動する\nLattePanda AlphaのBluetooth/WiFi\nLattePanda AlphaのUSB\n","date":"2019-05-12T13:23:11+09:00","image":"/uploads/2018/12/IMG_3939-2.jpg","permalink":"/posts/2002/","title":"LattePanda Alpha 800, m3-7Y30"},{"content":"USBInjectAll.kextの役割を確認するために外して調べてみました。マザボ搭載USBポートの情報を正しく反映するために必要でした。さらに正確に反映させるためのSSDTを作りました。\nUSBInjectAll.kextの役割 このkextを外してみる RehabManさんが開発してくれているUSBInjectAll.kextは、いつも使用しているのですが、そのありがたみがイマイチ理解できていませんでした。そこで外してみたらどうなるのか調べました。\nUSBポートの状態を調べるために、macOSから見えるハードウェア構成を確認するツールであるIORegistryExplorerを使用します。これを起動して、右上の検索欄でxhcとタイプすると、USB関連のポート一覧を見ることができます。この時、USBポートの名前がXHCではなくて、XHCIだったりXHC0だったりした場合は、config.plistでパッチを当てておいたほうが良いです。オリジナルのMacで使われている名前と衝突して問題を引き起こす可能性があるらしいです。\n今回使用したのはASUSのZ390マザーボードであるROG MAXIMUS XI HEROです。これに搭載されているZ390チップセットの仕様を調べると搭載しているUSBは、\nUSB2.0が14本 USB3.1が10本（そのうち6本までをGen 2にできる） だそうです。つまりIORegistryExplorerから見ると、HS01からHS14までの14本のUSB 2.0と, SS01からSS10までの10本のUSB 3.1が見える可能性があります。ただし、macOS El Capitanから導入された制約から、このうちの15本しか見えないはずです。\nでは、USBInjectAll.kextを外した状態でのMAXIMUS XIのUSBポート一覧です。こんな感じでした。\n無意味に番号が飛んでいて、でたらめな感じがします。前の記事で調べたように、HS01はマザーボードのLED電飾機能が使っていて、HS14は内蔵Bluetoothが使っています。OSでもアプリケーションでも使用する重要なポートなのに、見えていません。また、このマザーボードでは、USB 3.1に付随する2.0は同じ番号を持っています。なのでSS01があるのにHS01が無いのは不自然です。明らかに、ASUSが提供しているマザーボード情報では無いと思われます。何かの方法で適当にリストアップされたように見えます。他にもHS13が見えてません。これはマザーボード上のUSB 2.0コネクタに接続しています。今回はここにmacOSと互換性のあるBluetoothモジュールを接続しているので、それがリストに無いと、Bluetoothキーボード、トラックパッドが使えません。\nこのkextを使ってみる 次に、USBInjectAll.kextを入れて起動した状態でのUSBポート一覧です。こうなります。\nHS01から順番に欠番なくポートが見えていることがわかります。HSの次にあまり意味のないUSR1が来ていて、ここで15個の制限に達しています。なのでUSB 3.1のポートは見えていません。15個の制限がなければ、この後、USR2, SS01, SS02, …, SS10が、欠番なく全て見えるはずです。ということでUSBInjectAll.kextは、その名前の通り、もともと備えているUSBポートを全て認識させる機能を持っていることがわかりました。\nこのkextの中身を見る このkextが、USBポート一覧をどうやって入手できたのかというと、作者のRehabManさんが用意しておいてくれたからです。kextの中の、Contentsの中に、Info.plistというテキストファイルがあります。これを開くと、前半部分に、USBコントローラのベンダーID、デバイスIDごとに、構成されているポート一覧が記載されていることがわかります。\n使っているUSBコントローラのベンダーID、デバイスIDもIORegistryExplorerで知ることができます。\nコントローラと思われるあたりをクリックすると、右側の詳細ペーンにvendor-id, device-idが現れます。リトルエンディアン方式なので逆に読みます。これによると、ASUSのこのマザーボードの場合、vendor-idは0x8086でインテル社であることがわかり、device-idは0xA36Dだとわかります。おそらくこれがZ390チップセットのUSBコントローラだと思われます。Info.plistで8086_a36dの場所を探すと、HS01からHS14と、SS01からSS10が記載されていることがわかります。\nSSDTを作ってUSB15個制限に対応する 次に、USBInjectAll.kextの機能を使って、USB15個制限に対応する方法を説明します。今までの記事では、Cloverのブートオプションでuia_excludeを使う方法を紹介してきました。例えば、除外したいポートを以下のように指定します。\n\u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;uia_exclude=USR1;USR2;HS01;HS02;HS09;HS10;HS14\u0026lt;/string\u0026gt; などと書く方法です。この方式では、オプションをUSBInjectAll.kextが引き取って、Info.plistのリストから外してくれています。でも、RehabManさんおすすめの方法は、SSDTを作りUSBInjectAll.kextに知らせる方法のようです。\nSSDTというのは、ハードウェアの情報を記載するDSDTファイルの補助的なファイルです。DSDTの一部の情報を上書きして変更します。USBポートに関する情報を上書きするSSDTを用意することで、USBInjectAll.kextは、Info.plistの内容ではなく、SSDTの情報を使用してくれるようです。この手順を以下で説明します。\nUSBポートを調べる まずは、マザーボードに搭載されているUSBポートを調べて、使用したい15個のポートを決定します。上記のページには手順が詳しく説明してありますが、以前の記事で紹介したので省略します。その結果、今回使用したマザーボード、ASUS ROG MAXIMUS XI HEROには以下のポートがありました。\nHS01 AsusTek社のAURA MOTHERBOARDが使用 HS02 (不明, マザーボード上のU31G2_2の可能性あり) HS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”) HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”) HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″) HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下) HS07 バックパネルUSB 3のUSB 2.0 (4列上から1番目、青、”SS”) HS08 バックパネルUSB 3のUSB 2.0 (4列上から2番目、青、”SS”) HS09 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0 HS10 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0 HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記) HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”) HS13 マザーボードの2.0端子USB_E12, USB_E34 (USB2.0 Hub経由) HS14 マザーボード上のWiFi/Bluetoothモジュールが使用 SS01 (不明, 未使用?) SS02 (不明, マザーボード上のU31G2_2の可能性あり) SS03 バックパネルUSB 3.1 Gen 2 (4列上から3番目、赤、”SS10”) SS04 バックパネルUSB 3.1 Gen 2 (4列上から4番目、赤、”SS10”) SS05 バックパネルUSB 3.1 Gen 2 (Ethernetの下、赤、”SS10″) SS06 バックパネルUSB TYPE CのUSB 3.1 Gen 2 (Ethernetの下) SS07 バックパネルUSB 3.1 Gen 1 (4列上から1番目、青、”SS”) SS08 バックパネルUSB 3.1 Gen 1 (4列上から2番目、青、”SS”) SS09 マザーボードのU31G1_910の USB3.1 Gen 1 SS10 マザーボードのU31G1_910の USB3.1 Gen 1 このうち、以下の15個を使うことにしました。\nHS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”) HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”) HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″) HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下) HS09 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0 HS10 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0 HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記) HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”) HS13 マザーボードの2.0端子USB_E12, USB_E34 (USB2.0 Hub経由) SS03 バックパネルUSB 3.1 Gen 2 (4列上から3番目、赤、”SS10”) SS04 バックパネルUSB 3.1 Gen 2 (4列上から4番目、赤、”SS10”) SS05 バックパネルUSB 3.1 Gen 2 (Ethernetの下、赤、”SS10″) SS06 バックパネルUSB TYPE CのUSB 3.1 Gen 2 (Ethernetの下) SS09 マザーボードのU31G1_910の USB3.1 Gen 1 SS10 マザーボードのU31G1_910の USB3.1 Gen 1 テンプレートからdslファイルを作る この15個のUSBポートを指定するSSDTファイルを作成するために、そのテンプレートになるファイルSSDT-UIAC-ALL.dslを、こちらから入手します。コピーして、SSDT-UIAC.dslと改名しておきます。\nこのファイルには多数のUSBコントローラの情報が書いてあります。実際に使用するコントローラの項目だけを残して、他を削除します。ASUS Z390マザーボードの場合、vendor-idが0x8086で、device-idが0xA36Dです。この数値は上で説明したように、IORegistryExplorerでXHCの項目の中を探せば、vendor-id, device-idとして書いてあります。0x8086はインテルの番号ですので、インテルのチップセットを表しています。そこで”8086_a36d”と書かれた”Package”の定義だけを残して、他のPackageの定義を削除します。残すのは以下の項目です。\n\u0026#34;8086_a36d\u0026#34;, Package() { ........... }, この中にはHS01からSS10までのUSBの情報が書かれています。これに対して以下の作業をします。\nコメントでポートの説明を記録しておく。後のメモになります。//で書き始めればコメントになります。 不要なポートをコメントアウトする。行頭に//を書いて、使用しないポートを除外していきます。削除せずにコメントにすれば、あとから復活させるのが楽です。 UsbConnector情報を更新する。これについては次に説明します。 UsbConnector情報 SSDT-UIAC.dslのそれぞれのUSBポート情報には、コネクタ種類が数字で記載されています。これを更新します。具体的には、以下のように書かれている部分の数字を、実際に合わせて書き換えます。\n\u0026#34;UsbConnector\u0026#34;, 3, 書き換える値は、以下の通りです。\n0: USB 2.0のコネクタ 3: USB 3.1のコネクタ。3.1に付随するUSB 2.0も3にします。 255: 内部接続で外部に接続しないコネクタ。マザーボード内部でBluetoothユニットに接続しているなどの場合にこれを使います。マザーボード上のコネクタで外部に引き出す可能性のあるものは0または3にします。 9: USB Type-Cのコネクタ。逆挿しにしてもHSとSSの番号が変化しない場合。内部でハブに接続されているらしいです。 10: USB Type-Cのコネクタ。逆挿しするとHSとSSの番号が変化する場合。個別に接続されています。 この数字がどのように反映されるのか詳しくは知りません。でもIORegistryExplorerを見ると、255にした場合に電流に関するパラメータなどが消えるので、OSからの扱いが変化する可能性があります。また255にしたポートにArduinoを接続してみたところ、/dev/cu.usbserial-*などのデバイスが見えませんでした。USBシリアルドライバーが、この数字を基準に動作を変えているようです。Arduinoを接続するなら、0や3に設定しておくのが良いです。\nどのHSポートがUSB 2.0になるのかUSB 3.1になるのか、さらにはどのポートがType-Cになるのかは、マザーボード次第です。USBInjectAll.kextのInfo.plistにマザーボードごとの情報まで反映できないので、RehabManさんは各自でSSDTを作って、使用するマザーボードに即したUsbConnector情報をOSに伝えることを推奨しています。\nport-countを設定する SSDT-UIAC.dslの最初の部分に、portsのセクションの前に、port-countというセクションがあります。\n\u0026#34;port-count\u0026#34;, Buffer() { 26, 0, 0, 0 }, \u0026#34;ports\u0026#34;, Package() { ここに書く数値（10進数）には、今回作ったポートのバッファー値、例えば、\n\u0026#34;port\u0026#34;, Buffer() { 26, 0, 0, 0 }, などと表される数のうちの最大の数値を書きます。 今回はたまたま末尾のSS10まで使用したので、26のままで変更無しです。\ndslをコンパイルしてamlを作る こうして作ったdslファイルはSSDTのソースファイルのようなものです。これをコンパイルしてSSDTであるamlファイルを作ります。これにはMaciASLを使用します。こちらの記事で説明しています。\nDSDTを編集する\nMaciASLで、上で作成したSSDT-UIAC.dslを開きます。次に、FileのSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。\nこうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_exclude=を指定しなくても、指定したポートのみが有効になるはずです。参考のために、今回作成したSSDT-UIAC.dslファイルを以下に置いておきます。\nSSDT-UIAC.dsl for ASUS Z390 - Pastebin.com\n","date":"2019-05-04T18:22:15+09:00","image":"/uploads/2018/08/20170915223211-e1556936489370.png","permalink":"/posts/2059/","title":"15個制限を回避するUSBInjectAll.kextの役割と使用法"},{"content":"Haswell世代のCore i5-4250Uを搭載しています。これはMacBookAir6,1, 6,2で使用されているCPUで、macOSとの互換性が高く安定しています。D54250WYKは薄型筐体で、WYKHは2.5インチドライブを内蔵できる厚型モデルです。WYKHは一時期ドスパラで税込3万円未満で売られていました。\nハードウェア Intel NUC D54250WYKH (WYKHの他にWYK, WYBがあり) CPUはIntel(R) Core(TM) i5-4250U CPU @ 1.30GHz グラフィックスはIntel HD Graphics 5000 (稀にノイズが出ます) WiFiモジュールはDW1510を搭載（OOBで動作） BluetoothはI-O DATAのUSB-BT40LE（Magic Trackpad/keyboardはOOBで動作するもののContinuityは非対応） ソフトウェアと機種ID macOS Mojave 10.14.4 Clover v2.4k r4920 MacBookAir6,2 ESPの設定 kext類 (kexts/Other) IntelMausiEthernet.kext Lilu.kext VirtualSMC.kext WhateverGreen.kext efiドライバ (drivers64UEFI) ApfsDriverLoader-64.efi AptioMemoryFix-64.efi DataHubDxe-64.efi FSInject-64.efi SMCHelper-64.efi VBoxHfs-64.efi config.plist 以下です。これで動作するはずですが、シリアル番号、UUIDは設定し直してください。\nconfig.plist for NUC D54250WYK(H) - Pastebin.com\n関連記事 Intel NUC D54250の続きはこちらです。\nIntel NUC D54250にOpenCoreとBig Sur Beta 9を入れる\nIntel NUCに関する記事は以下です。\nNUCで作る超小型macOSマシン\n","date":"2019-05-03T16:11:57+09:00","image":"/uploads/2017/11/20171116093346.png","permalink":"/posts/1991/","title":"Intel NUC D54250, 4250U"},{"content":"最初に販売されたCore i搭載のNUCで、Ivy Bridge Core i3-3217Uを搭載しています。Macで同じCPUは使われていませんが、近いi5-3317UがMacBookAir5,1で使われています。Intel HD Graphics 4000が共通なこともあり、安定に動作します。\nハードウェア Intel NUC DC3217IYE (IYEの他に IYR, BY, GKE, CKなどあり) CPUはIntel(R) Core(TM) i3-3217U CPU @ 1.80GHz グラフィックスはIntel HD Graphics 4000 SSDはAliで買った格安mSATA WiFiモジュールはDW1510を搭載（OOBで動作） BluetoothはI-O DATAのUSB-BT40LE（Magic Trackpad/keyboardはOOBで動作するもののContinuityは非対応） ソフトウェアと機種ID macOS Mojave 10.14.4 Clover v2.4k r4920 MacBookAir5,1 ESPの設定 kext類 (kexts/Other) IntelMausiEthernet.kext Lilu.kext VirtualSMC.kext WhateverGreen.kext efiドライバ (drivers64UEFI) ApfsDriverLoader-64.efi AptioMemoryFix-64.efi DataHubDxe-64.efi FSInject-64.efi SMCHelper-64.efi VBoxHfs-64.efi config.plist 以下です。シリアル番号は実機とコンフリクトしないことを確認してあります。このままで動作するはずですが、シリアル番号、UUIDは設定し直してください。\nconfig.plist for NUC DC3217IYE - Pastebin.com\n関連記事 Intel NUCに関する記事は以下です。\nNUCで作る超小型macOSマシン\nIntel NUC DC3217のiGPU画面が乱れる\n","date":"2019-05-01T20:29:02+09:00","image":"/uploads/2019/04/dc3217iye.png","permalink":"/posts/1993/","title":"Intel NUC DC3217, 3217U"},{"content":"Haswell CPUの作例です。スリープ、iMessage、FaceTimeが機能します。純正無線ユニットを使用しているのでContinuity関連も問題ありません。HaswellはmacOSで問題を引き起こすことが少なく安定しているという評判でした。\nハードウェア マザーボードはMSI Z97A GAMING 7 CPUはIntel(R) Core(TM) i7-4790K CPU @ 4.00GHz グラフィックスは（OOBで動作） WiFi/BluetoothはBCM94360CD（OOBで動作） BIOS設定 こちらの設定どおりです。\nマザーボード (BIOS) 設定\nソフトウェアと機種ID macOS Mojave 10.14.4 (18E226) Clover v2.4k r4920 iMac15,1 ESPの設定 kext類 (kexts/Other) AHCIPortInjector.kext AHCI_3rdParty_eSATA.kext AppleALC.kext AtherosE2200Ethernet.kext EFICheckDisabler.kext Lilu.kext USBInjectAll.kext VirtualSMC.kext WhateverGreen.kext このマザボは8個のSATAのうち2個にASMedia ASM1061を使っています。これを使うためにAHCI_3rdParty_SATA.kextまたはAHCI_3rdParty_eSATA.kextを使います。eの付く方はホットスワップ対応です。\nefiドライバ (drivers64UEFI) ApfsDriverLoader-64.efi AptioMemoryFix-64.efi FSInject-64.efi SMCHelper-64.efi VBoxHfs-64.efi config.plist 以下です。実機で未使用のシリアル番号を生成して書き込みましたので、このままでも問題なく使えます。しかし、Apple社のサービスを使う前にシリアル番号、UUIDを独自の値に設定し直してください。\nconfig.plist for MSIZ97AGAMING7 - Pastebin.com\n","date":"2019-05-01T10:35:48+09:00","image":"/uploads/2019/04/product_5_20160825171944_57beb830288cc.jpg","permalink":"/posts/1929/","title":"MSI Z97A GAMING 7, 4790K"},{"content":"Coffee Lake-S Refreshの作例です。スリープ、iMessage、FaceTimeが機能します。純正無線ユニットを使用しているのでContinuity関連も問題ありません。過去に公開した記事のまとめです。このマシンは常用していますので、ここで紹介している作例で一番自信のある構成です。\nハードウェア マザーボードは (国内ではWiFi付モデルのみのようです。WiFi/BTは動作しないのでdisable) @ 4.00GHz グラフィックスは（OOBで動作） WiFi/BluetoothはBCM94360CD（OOBで動作） ソフトウェアと機種ID macOS Mojave 10.14.4 Clover v2.4k r4920 iMac19,1 ESPの設定 kext類 (kexts/Other) AppleALC.kext IntelMausiEthernet.kext Lilu.kext USBInjectAll.kext VirtualSMC.kext WhateverGreen.kext efiドライバ (drivers64UEFI) ApfsDriverLoader-64.efi AptioMemoryFix-64.efi FSInject-64.efi VirtualSmc.efi （VirtualSMC.kextに同梱されているもの） VBoxHfs-64.efi EmuVariableUefi-64.efi config.plist 以下です。iGPUを使わない場合の設定です。シリアル番号は実機で使われていないことを確認してあります。しかしアップルのサービスを使用する前に独自のシリアル番号、UUID値を設定し直してください。\nconfig.plist for 9900K w/o iGPU display - Pastebin.com\n関連記事 詳細な手順などはこちらをご覧ください。\n9900K搭載Z390マザーボードでHackintoshを作る\nASUS Z390マザーボードのshutdown/sleep対応\n9900Kのsleep問題〜原因はiGPUのデバイスID\nASUS MAXIMUS XI HEROにM.2 SSD (WD SN750)を取り付ける\n10.14.4で第9世代CPUの互換性が向上\n第9世代CPU用のSMBIOSを書く\n9900KのためにmacOS 10.14.4 (18E2034) を入手する\nASUS MAXIMUS XI HEROのUSBを設定する\n9900KマシンをmacOS 10.14.5に更新する\nASUSのBIOSを1105以上に更新すると起動しない\nASUS Z390 + Coffee LakeのブートローダをOpenCoreにする\nOpenCore 0.6.2から0.6.3に更新\nBig Surをクリーンインストールする (OpenCore + Z390)\n","date":"2019-04-29T20:17:38+09:00","image":"/uploads/2019/03/1899146-n0.png","permalink":"/posts/1915/","title":"ASUS ROG MAXIMUS XI HERO (Z390), 9900K"},{"content":"ThinkPad X220にmacOSをインストールした過去記事のまとめです。定評のある昔ながらのキーボードとトラックポイントを採用した最終モデルThinkPadでmacOSを動かします。Sandy BridgeなのでMojave非対応です。\nハードウェア 本体は Lenovo ThinkPad X220 (パッチ済みBIOSに変更) CPUは Intel(R) Core(TM) i7-2620M CPU @ 2.70GHz (Mojave非対応) グラフィックスは インテル® HD グラフィックス 3000 (Metal非対応) Bluetoothは本体内蔵(BCM92070MD0-LENO) (OOB。Continuity非対応) WiFiはDW1510に交換（OOBで動作） ソフトウェアと機種ID macOS High Sierra 10.13.6 Clover v2.4k r4920 MacBookPro8,1 ESPの設定 kext類 (kexts/Other) ACPIBatteryManager.kext ACPIPoller.kext AppleBacklightInjector.kext AppleHDA_20672.kext BlueTooth_Injector.kext FakeSMC.kext IntelMausiEthernet.kext IOAHCIBlockStorageInjector.kext VoodooPS2Controller.kext efiドライバ (drivers64UEFI) VBoxHfs-64.efi UsbKbDxe.efi SMCHelper-64.efi OsxFatBinaryDrv-64.efi OsxAptioFixDrv-64.efi.NotUsed OsxAptioFix2Drv-64.efi FSInject-64.efi DataHubDxe-64.efi AudioDxe-64.efi ApfsDriverLoader-64.efi DSDT 次の「外部情報」に記載したページでdsdt.amlが配布されていますので、EFI/CLOVER/ACPI/patchedの中に入れます。\n外部情報 以下に全てのガイドがあります。ここでは、パッチを当てたBIOSと、ESPの中に入れるべきファイルが全て配布されています。Cloverやkext類も最新版になるよう更新されています。\nThinkPad X220 macOS High Sierra Installation - ThinkPad X220\n関連記事 このビルドに関する記事です。詳細はこちらをご覧ください。\nThinkpad X220でHigh Sierra (1)機種選定\nThinkpad X220でHigh Sierra (2)準備・到着・起動\nThinkpad X220でHigh Sierra (3)BIOSと無線\nThinkpad X220でHigh Sierra (4:最終回)まとめ・これから\nCPU/GPUがサポート対象外のMojaveをなんとか動かす記事はこちらです。\nSandy Bridge搭載Thinkpad X220でMojave\n","date":"2019-04-28T12:04:11+09:00","image":"/uploads/2018/06/overview.png","permalink":"/posts/1978/","title":"Lenovo ThinkPad X220, 2620M"},{"content":"一時期市場から姿を消したSAPPHIRE PULSE RADEON RX 580が、今年の3月から再販売されています。Apple純正のeGPU開発キットに搭載されている製品でmacOSとの互換性が高いです。\neGPU開発キット ほぼ2年前のWWDC 2017でeGPUボックスの公式サポートが発表されました。一般的なPCIeグラフィックスカードをThunderbolt経由でMacに接続する外付けボックスです。そしてeGPUボックスを使ったアプリケーション開発のために、AMD Radeon RX 580を内蔵した開発者向けキット「External Graphics Development Kit」が発売されました。ただ、現在は品切れのようです。このキットに内蔵されているRX 580カードがSAPPHIRE PULSE RADEON RX 580です。\nExternal Graphics Processors - Apple Developer\nPULSEとNITRO+ SAPPHIRE社のRX 580製品にはPULSEとNITRO+があります。NITRO+は「品質と安定性に優れた」上位モデルで、PULSEはコスパ重視の下位モデルです。PULSEのブーストクロックは1,366MHzなのに対して、NITRO+は1,411MHzとよりオーバークロックされています。NITRO+の方が放熱モジュールも大きく、カードの高さ、長さ、幅が大きいです。PULSEはPCIe 2スロットで収まりますが、NITRO+は2.5スロットくらい占有します。PULSEもNITRO+も国内ではどちらも2017年4月に発売されました。\nSAPPHIRE、Radeon RX 580/570搭載グラフィックスカード計6製品リリース - エルミタ\u0026hellip;\nしかしその後しばらくして、PULSEは店頭や販売サイトから姿を消して、NITRO+しか手に入らなくなりました。長らくそんな状態が続いていたのですが、今年の3月からPULSEが再発売されたようです。よく比べると型番の末尾が一文字だけ違いますが、仕様は同じです。おそらくは品切れに対応して、再度生産したのかと思われます。\nセミファンレス対応のRadeon RX 580がSAPPHIREから、税込25,700円\nPULSEのmacOS互換性 とにかく安いグラフィックスカードが欲しいとか、逆に高くて良いから最高性能が欲しいなどの強い要望がなければ、SAPPHIRE PULSE RADEON RX 580は良い選択だと思います。\n上で述べたようにAppleが配布している開発キットのカードと同じなので、互換性が高いと考えられるからです。実際に、開発キットが出たばかりの初期の10.13.3では、PULSEだけが「このMacについて」に正しく名称表示されました。もっともこれは、単に表示だけの問題ですし、10.13.4以降では他の製品も正しく表示されています。なので他のカードを選んでも互換性の問題は全くありませんが、それでも、どれでもよければPULSEが良いと思います。開発者に出回っているカードなので、将来にわたって不具合が発生しにくいと考えられるからです。\nPULSEは、販売サイトでも再登場しています。元々が普及価格帯モデルでしたので、マイニングブームの頃に比べたら手頃な価格になってます。\n","date":"2019-04-27T20:29:13+09:00","image":"/uploads/2019/04/71z0O7fVFFL._SL1500_.png","permalink":"/posts/1950/","title":"SAPPHIRE PULSE RADEON RX 580 8G 再発売"},{"content":"Ivy Bridge時代の作例です。macOS Mojaveでも安定して動いています。スリープも機能します。未確認ですがiMessage/FaceTimeも大丈夫だと思います。BluetoothをBCM20702で構成していますので、キーボード・トラックパッドは問題ないですが、Continuityなどには対応していません。大昔に作ったマザボを引っ張り出して現行Mojaveを入れてみましたが、正しく動きました。\nハードウェア マザーボードはGigabyte GA-Z77N-WIFI CPUはIntel(R) Core(TM) i5-3570K CPU @ 3.40GHz グラフィックスはNVIDIA GTX650, ブランドはASUS（OOBで動作） 搭載されていたIntelのWiFiモジュールはDW1510に交換（OOBで動作） BluetoothはI-O DATAのUSB-BT40LE（Magic Trackpad/keyboardはOOBで動作するもののContinuityは非対応） ソフトウェアと機種ID macOS Mojave 10.14.4 Clover v2.4k r4920 iMac13,2 ESPの設定 kext類 (kexts/Other) Lilu.kext RealtekRTL8111.kext USBInjectAll.kext VirtualSMC.kext WhateverGreen.kext efiドライバ (drivers64UEFI) ApfsDriverLoader-64.efi DataHubDxe-64.efi EmuVariableUefi-64.efi FSInject-64.efi OsxAptioFix3Drv-64.efi SMCHelper-64.efi VBoxHfs-64.efi config.plist 以下です。これで動作するはずですが、シリアル番号、UUIDは設定し直してください。\nconfig.plist for GA-Z77N - Pastebin.com\n","date":"2019-04-27T10:19:35+09:00","image":"/uploads/2019/04/GAZ77N.jpg","permalink":"/posts/1926/","title":"Gigabyte GA-Z77N-WIFI, 3570K"},{"content":"Xeon X5690が安かったので2個買いました。これを殻割りしてMac Pro Early 2009に取り付けました。コア/スレッド数が8/16から12/24に増えて、Cinebenchのスコアが1.9倍向上しました。\n古いMac Pro用のXeonが安い 今回は、Hackintoshの話ではありません。期待された方、すみません。\n少し前にAliExpressでXeon X5690が1個$61で販売されていました。安さに惹かれて2個購入しました。この記事を公開した後、一時は$100くらいまで値上がりしましたが、今はまた$70以下に下がっているようです。国内でも、ヤフオクやメルカリを探すと1個あたり1万円台前半くらいで取引されているようです。\nX5600シリーズは、Core iシリーズ第1世代のCore i7-980あたりと同世代の6コア12スレッドのCPUです。980も6コア12スレッドでしたのでそれのXeon版です。発売（2011年2月ころ）直後のX5690は15万円くらいだったようです。2個で30万円ですね。\n3.46GHzの「X5690」など、Xeonシリーズに3つの新モデル！\nいくら$61だったからと言って、こんな古いXeonをなぜ買ったのかと言うと、手元にあるMac Pro Early 2009 (MacPro4,1) のCPUと入れ替えようと思ったからです。このMac ProにはX5550 (2.65GHz)というCPUが2個搭載されています。4コア8スレッドなので2個で8コア16スレッドです。X5550だって発売当時（2009年3月ころ）は11万円以上したらしいです。\n新型Xeonが一挙に8モデル登場！　LGA 1366×2マザーも (1/2)\nこのMac Proの次のモデル、Mac Pro Mid 2010 (MacPro5,1) では最上位機種にX5670が、Mid 2012 (これもMacPro5,1)にはX5675が搭載されました。X5670, X5675とX5690はクロック違いのほぼ同じCPUなので、同じハードウェアで動きます。X5690はクロックが上がっている分、TDPも上がっているので多少心配なところもありますが、気にしないことにします。\n実はMacPro5,1とMacPro4,1は、ハードウェアはほぼ同じで、ファームウェアのみが異なっています。なので4,1のファームウェアを5,1にアップデートすれば、X5600シリーズCPUにも対応できます。この先のCPU交換を行うためには、ファームウェアをMacPro5,1にしておく必要があります。ファームウェアアップデートにはさらに大きなメリットがあります。MacPro5,1では現行のmacOS Mojave 10.14が動きますが、MacPro4,1ではmacOS 10.11までしか動きません。ファームウェアアップデートによりこの制限も解除されて、最新macOSを使えるようになります。ファームウェアのアップデートの手順は以下です。アップデートすると「このMacについて…」「システムレポート…」の表示がMacPro5,1になります。\n2009 Mac Pro 4,1のファームウェアをアップグレードする方法\nX5690を殻割りする 一般的に流通しているX5600シリーズCPUをMac Pro Early 2009に取り付けるためには、上で述べたファームウェアアップグレードの他にもう一手間必要です。というのは、Early 2009にはヒートスプレッダ（殻）のついていない、ダイがむき出しのCPUが使われているからです。それに対して流通しているCPUはほとんどが殻付きです。なので、Mac Pro Early 2009のCPUを交換している人たちは、次のどちらかの方法を行なっています。\n殻付きのままのCPUを取り付ける。 殻を外して（殻割りをして）取り付ける。 殻割りをしない前者の方法には、色々と問題があります。本来、殻無しで設計されているところに、殻付きのCPUを無理やり取り付けることになります。なので殻の分だけCPUが分厚くなってしまい、CPUクーラーが浮き上がります。浮いたクーラーに対応するためにワッシャ等を入れてスペーサーとする方法もありますが、適切な高さに調整する事は困難です。適切に高さ調整できない場合は、クーラ締め付け圧力がCPU本体に直接加わってしまいます。その場合、ダイが破損したり、CPU基板が曲がる可能性があります。ちなみに、Early 2009では殻無しCPUに合わせたプラスチックカバーを用いて、締め付け圧力をソケットに逃がしています。殻付きのCPUを使う2010/2011年モデルのMac Proでは、通常の自作PCと同じくレバーで抑える金属のソケットカバーがあり、これが締め付け圧力を受け取り、CPU本体に力がかかりません。殻付きCPUをEarly 2009で使うと、このような仕組みが効かなくなってしまうのです。\n一方、クーラーが浮き上がることは、周辺回路の冷却効果も損ないます。後の写真で示すように、CPUクーラーはCPUに電力供給しているVRM回路のMOSFET部分にも接触して冷却しています。しかしクーラー位置が上昇するとMOSFETとCPUクーラーが離れてしまいます。これを防ぐためには、熱伝導ゴムを重ねる必要があり、放熱効果が低下します。でも一番の欠点は、CPUクーラー内のファンに電力を供給するコネクタも浮き上がるので、コネクタ取り付け部分を破壊して、コネクタ位置を下げる必要がある事です。殻割りしない方法は、殻割りのリスクが無い以外は、デメリットだらけです。\n殻割りをする後者の方法は、殻割りでCPUを壊すリスクがある以外は、何のデメリットもありません。取り付けの安定性も放熱効果も、設計通りのまま維持できます。Mac Pro Mid 2010 以降では殻付きCPUが使われていますが、これに対して無駄なヒートスプレッダが無いMac Pro Early 2009はより高い放熱性能が得られます。殻割りさえ成功すれば、この方法が理想です。\nCPUを格安で入手したので、ここは殻割りをすることにしました。殻割りといえば、オーバクロックを目指す自作PCマニアの憧れイベントです。是非とも1度はやってみたかったです。しかもXeonはヒートスプレッダがダイに半田付けされています。グリスで付いている普通のCPUと違って、挑戦のしがいがあります。そこで、以下を参考に、CPU殻割りと交換を行いました。\n『Mac Pro 2009アップグレード Xeon X5670装着 ＜CPU交換・換装編＞』\n殻のシールを切る ヒートスプレッダは周囲をゴム状の接着剤で貼り付けられています。また、中央部はCPUダイに低融点合金（以下、半田）で貼り付いています。まずは周囲の接着剤の部分を切り離しておきます。これにはカミソリの刃をつかいました。怪我をしないように手には軍手をはめ、CPU裏と縁はマスキングテープで養生しました。接着剤は硬いゴムのような手応えなので、力を入れてザクザク切っていきます。\n下は、剥がしたヒートスプレッダの裏側写真です。黒い部分がゴム状シールです。このくらいの幅だけ差し込めば接着剤は切れます。これより内側には、コンデンサが表面実装されている場所もあるので、深く切り込まない方が良いです。周囲を切り終わっても、殻の中央がダイに半田付けされているので、殻は外れません。\n半田を溶かす 次に半田を溶かして、殻を外します。Youtubeを見ると、たくさんの例が上がっています。基本的には、殻を外すような力を加えた状態で、殻を加熱します。加熱には、ヒートガン、アイロン、ガスバーナー、ライターなどが使われているようです。今回は、手近にあったヒートガンを使いました。またこの後の作業のために、スクレーパーを用意しました。\nヒートスプレッダにカミソリの刃を差し込んで、そこにスクレーパーを差し込みます。スクレーパーは片刃なので、刃の斜めになった面を下にして、刃の部分を差し込みます。カミソリの刃の弾力で、スクレーパーは差し込まれたまま固定されます。\nまたCPUの反対側をクリップでアルミ板片に固定しました。これでスクレーパーの片刃の根元部分が梃子の支点になり、これに柄の重みが加わって、梃子の作用点に当たる刃先に殻を外そうとする上方向の力が加わります。これを作業用の耐熱ゴム（写真の背景で青く見えている部分です）の上に置きました。このゴムシートは、500度までの耐熱性能があるらしいです。\n次にヒートスプレッダをヒートガンで加熱します。あまり加熱すると、CPUが破損するかもしれません。そこで熱電対で温度を計測できるテスターを使って、CPUの温度をモニターしながら進めました。20-30秒くらい加熱したところで温度が200度を超え、230度くらいになったところでスクレーパーの柄の重みで殻が外れました。殻割りはあっけなく終了しました。\n半田を剥がす 殻が外れても、ダイの上に半田が残っています。ダイが熱いうちにスクレーパーで剥がします。表面実装のコンデンサを保護するために、マスキングテープで養生した方が良いです。実は養生する前に、スクレーパーが滑ってコンデンサを1個剥がしてしまった気がします（小さすぎてよくわかりません）。コンデンサは、電圧を安定させるためのパスコンデンサーではないかと思います。結果としては、1個ぐらい外れても大丈夫でした。半田は、硬いチーズくらいの感じです。温度が下がったらヒートガンで再加熱すると柔らかくなります。\nスクレーパーの刃はかなり精度が良いので、これだけでほぼダイの部分まで半田を剥がすことができました。指で触れても滑らかです。でも、鏡のように平らにした方が気分が良いので、さらにピカールで磨きました。綿棒でゴシゴシこすります。その結果、鏡面になりました（撮影しているスマホが写っています）。\n接着剤を剥がす CPUの基板の周囲には、ゴム状の黒い接着剤が残っています。これを剥がします。この後のCPU取り付けを、\nソケットにCPUを置く その上にプラスチックの枠を置く CPUクーラーを乗せてソケットにネジで締める という手順で行います。黒いプラスチックの枠は、ソケットの周囲までカバーする形状をしていて、上に置いたCPUクーラーを締め付けた時の圧力を、ソケットに逃がす機能があるように見えます。この部品を使わないと、CPUのダイのみに力が加わってしまい、CPU基板が湾曲してダイを破損する可能性があるかもしれません。\nこのプラスチック部品は、ダイの厚みに合わせてあり、力を逃がしてくれつつ、ダイの表面がCPUクーラーに密着するよう作られているように見えます。ところが2番目の写真のように、殻を固定していた接着剤が残っていると、CPUクーラーとダイが、本来の間隔より接着剤の厚みだけ離れてしまいます。その場合、ダイがCPUクーラーに密着せず、放熱が妨げられる心配があります。そこで、接着剤をしっかりと除去しておこうと考えました。\nゴム状接着剤はかなり頑固で、アルコールでは除去できません。そのためにエレクトリッククリーナという製品を使ってみました。\nクリーナーを吹き付けてると、硬いゴム状接着剤が消しゴムのように柔らかくなります。そこで、プラスチックのカードや、清掃用プラスチックのヘラ（100円均一で売ってます）で剥がします。クリーナーはしばらくすると蒸発して、綺麗になります。\nさらにアルコールを浸したキムワイプで拭き取りました。これで、半田も取れて、シール材も取れて、美しいCPUになりました。\nCPUを交換する CPUボードを外す Mac Proは良くできていてメンテナンスが楽です。CPUとメモリー部分は、マザーボードとは別にドーターボードに実装されています。これは、2本のレバーを外すだけで取り外せます。\nドーターボードの上に、銀色のCPUクーラーが2個あります。それぞれは3mmの六角ネジ4本で固定されています。上の黒い穴にドライバーを差し込んでネジを回します。細い穴の入り口からネジまでの距離が7.5cmくらいあるので、軸が細くて長い六角ドライバか六角レンチが必要です。そのために用意したのがこちらの六角軸ビットです。\n5本セットですが、必要なのは3mmの1本だけです。バラ売りもあったのですが割高でした。バラ売り2本で5本セットが買える価格（2本買えば3本が無料）だったので、ついこちらにしてしまいました。普通の長い六角レンチなら、もっと安価な選択肢が多数あるのですが、今回は、次に述べるトルクドライバーを使いたいために、軸径6.35mmの六角軸ビットを用意しました。\nトルクドライバー CPUクーラーは六角レンチで簡単に外せます。でも外す前にトルクを調べておくことにしました。\n自作PCで一般的に使われるCPUクーラーは、ヒートシンク部分をバネの力で押し付けています。取り付けネジが止まるまで締めれば、バネの力で適切な圧力がかかる設計です。これに対して、Mac ProのCPUクーラーは、ネジのトルクでCPUを押さえつけます。その場合、ネジ締めトルクがそのままCPUクーラーを押さえる力になるので、設計通りのトルク値でネジ締めする必要があります。自作PCに馴染みの深いCPUでは、RyzenのThreadripperがその方式で、CPUパッケージには一定のトルクで締められるドライバーが付属しています。\nMac ProのCPU交換をした先人の情報によると、CPUクーラーの取り付けネジは、締めすぎても、締め足りなくて駄目で、適切なトルクで締めないと起動しないそうです。そこで、トルクを調整できるドライバーを用意しました。少し高価ですが、金属製で精密な作りのドライバーで所有する喜びがあります。このドライバーには＋ネジ用のビットが2サイズ付属していますが、それではCPUクーラーに対処できないので、上で紹介した六角軸ビットが必要です。\nCPUクーラーを外す前に、このドライバーを使って締め増しを試みました。トルクを40cNmに設定したところすぐに空回りをしますが、50cNmでは10度くらい回転し締め増すことができました。8本全てのネジを試しましたが同様でした。ということで、50cNmのトルクで締めれば適切のようです。\nCPUを取付ける あとは自作PCとほぼ同様です。まずは、CPUクーラーを取り外します。この時、グリスにくっついてCPUとプラスチック部品も外れるので、ソケット上に落とさないように注意します。また、CPUクーラ内のファンに電源を供給するコネクタを外す必要があるので力加減に気をつけます。埃が溜まっていると思いますので、掃除もしておきます。CPUクーラーのヘリには熱伝導ゴムが貼り付いていて、これがCPUのVRMのMOSFETにも接触して冷却しています。下の写真の細長い銀色のゴム状部分（青矢印）が熱伝導ゴムで、基板上の1列の四角い金属チップ（黄矢印）がMOSFET類です。埃で汚れている可能性があるので、これらもアルコールで掃除しておきます。\n次に、殻割りしたX5690をソケットに乗せて、プラスチック部品を乗せて、グリスを塗って、CPUクーラーを取り付けます。ファンコネクタがはまるように注意します。トルクを50cNmに調整して、6角ネジを締めます。この時、4個のネジを、対角にあるネジを次に締めるような順番で、少しずつ締めていきます。最後にMac Proに取り付ければ完成です。電源を投入すれば、ジャーンという起動音が聞こえるはずです。\n性能比較 X5550からX5690に交換したことで、GeekBenchのマルチコアスコアは、15168から22583と1.5倍向上しました。コア数が8から12と1.5倍になったので、その程度の差が出ました。\n9900Kで動くmacOSのマルチコアスコアは30000超えが普通ですので、それには及びません。GeekBenchブラウザで他機種のスコアと比較すると、Mac Pro Mid 2012の最上位機種 (X5675) 程度のスコアです。\nまたCinebenchのCPUスコアは843から1579に向上しました。1.9倍の改善です。ベンチマークしながらアクティビティモニターでCPUコア一覧を開くと24スレッドが働いていて圧巻です。\n発熱の状態（追記） コメントでCPU温度やファンの状態について質問いただきました。確かに、本来のモデルはTDPが95WのX5670, X5675を搭載する設定に対して、ここではTDPが130WのX5690を取り付けました。排熱が追いついているのか気になるところです。\n温度を測るために、Intel Power Gadgetをインストールしようとしたところ、マルチCPUには対応していませんでした。\nそれでHWMonitorを使うことにしました。\nHWMonitorを使う\nこれらの準備をしている程度の負荷では、CPU温度は35~45度くらいのようでした。11月なので室温は20度くらいと思います。ファンはとても静かに回ってます。ちなみにPCH Dieという場所の温度が80度なのは何かの間違いな気がします。CPU交換以前でも、この場所は異常な温度を示していたように思います。\nまずはGeekbench 5のCPUベンチマークを動かします。このベンチマークは、負荷を短時間しか与えないので、それほど温度は上昇しませんでした。最大で72度くらいです。\nGeekbench 5の結果は、マルチコアで6055でした。上で示したGeekbenchとはバージョンが違うので、数値も違います。10コア20スレッドの10900Kが11,000くらいです。出たばかりのM1搭載MacBook Airは7400くらいらしいので、それにも負けてます。2 CPU 12 コア 24スレッドと構成ユニットの数は最強なのですが。\n次にCinebench R23を数回連続して稼働してみました。\nちなみにCinebench R23の結果は8464 ptsでした。弟分のX5650が6867なので、妥当な結果でしょうか。\n温度は80度を超えましたが、まだ頭打ちにはなってないのでもう少し頑張れるようです。また、ファンが爆音状態になるということはなかったです。\nあとがき CPUは格安だったのですが、これに対して結構色々と道具や工具を揃えてしまいました。でも往時なら総額30万円のCPUのためですから、これくらい良いかと思いました。とはいえ、CPUが2個、総コア数が12個もあって、消費電力も多いのにも関わらず、現代の8コア16スレッドの9900Kで作ったHackintoshの3分の2くらいの性能です。最新CPUで作るmacOSマシンのコストパフォーマンスの良さを再認識しました。\n","date":"2019-04-20T16:08:00+09:00","image":"/uploads/2019/04/x5690.jpg","permalink":"/posts/1686/","title":"Xeon X5690を殻割りしてMac Pro Early 2009に取り付ける"},{"content":"UEFIマザーボードには各種設定やファイル表示・変更ができるコマンドラインシェル機能があります。これを使用すればOSが起動する前にファイル変更・移動・削除できるので、誤設定で起動しなくなったマシンを救えます。\nUEFI Shellへの入り方 UEFI Shellは、UEFI環境で動作するオープンソフトウェアです。Cloverをインストールすると、EFI/CLOVER/toolsの下にShell64.efiというような名前でインストールされます。Cloverの起動ドライブ設定画面から「Start UEFI Shell 64」を選択すると起動します。\n最近のマザーボードには、マザーボード内のメモリーにもすでにUEFI Shellがインストールされています。なので、BIOSメニューの中からもシェルを起動できます。起動メニューは、BIOSのSave \u0026amp; Exitの項目の中にあることが多いです。下は、MSIのマザーボードの例です。「UEFI: Built-in EFI Shell」というメニューを選ぶとシェルに入ります。\nCloverのESPにあるシェルとマザーボードで用意されているシェルは、バージョンが異なります。Cloverから起動できるシェルの方が機能が多いです。以下では、Cloverから起動したシェルで説明します。\nESPのあるファイルシステムに移動する シェルが起動したら、\nhelp -b とタイプするとヘルプの一覧が出ます。-bオプションは、画面１ページごとに一旦停止して表示するためのオプションです。このオプションはほかのコマンドでも使えます。今回使うべき機能は、\nbcfg NVRAMに保存されたbootとdriverオプションを管理します。 cd ディレクトリーを移動します cp ファイルやディレクトリをコピーします edit エディタを起動してファイルを編集します exit シェルを終了します ls ディレクトリの中のファイルを表示します map ファイルシステム (FS) のマップを表示・定義します reset システムをリセットします mv ファイルやディレクトリを移動・改名します rm ファイルやディレクトリを消去します です。このうちbcfg, edit, map以外はmacOSの（というかUnixの）シェルコマンドと同じです。シェルが起動したらまずは、\nbcfg boot dump とタイプします。NVRAMに保存された起動情報をdump（画面表示）するコマンドです。これでboot可能なドライブ一覧が表示されます。boot可能ドライブが1個しかなければ、1個が表示されます。複数あれば複数表示されます。複数現れる場合はbootの優先順です。\n何かの不具合でブートドライブとして見えない場合はこのコマンドで追加もできます。例えばaddコマンドを使って、fs1:\\EFI\\EFI\\BOOT\\にあるBOOTX64.efiをブート順位2（先頭は0）に、Boot macOSという表示名で追加する場合は以下のようにします。\nbcfg boot add 2 fs1:\\EFI\\EFI\\BOOT\\BOOTX64.efi \u0026#34;Boot macOS\u0026#34; また不要なドライブを一覧から消すこともできます。例えばrmコマンドを使って順位4を削除する場合は、以下のようにします。\nbcfg boot rm 4 今回はdumpコマンドを使って単に閲覧するだけにします。以下は、bootドライブが一つだけの場合のdumpコマンドの実行例です。\nUEFIはBOOTX64.EFIというファイルを見つけてコンピュータのbootを行うのですが、そこに至るパスがDevPathという項目に書いてあります。最初がドライブの種類で、パーティションがGPTであるかなどが書かれています。そのあとに32桁の16進数があります。これはパーティションを特定するUUIDです。ESP (EFI System Partition) がdisk0s1の場合、macOSのターミナルからdiskutilコマンドを使って、\ndiskutil info disk0s1 とタイプするとESPのパーティションUUIDがわかるのですが、それと同一のものが見えているはずです。これでESPのパーティションUUIDの目星をつけてメモしておきます。UUID全部をメモする必要はなくて、最初と最後の数桁で良いです。\n次に\nmap -b とタイプします。ファイルシステムのマップが出てきます。この中に、先ほどのESPのUUIDと同じものがあるはずです。それを見つけて、ESPのファイルシステム番号を確認します。行頭にFSと書いてある次の番号です。ドライブが1個しかなければ、ESPは大抵FS0:に割り当てられています。以下は、ESPがFS0:に割り当てられていた場合で説明します。\n次に\nfs0: とタイプします。Unix系のファイル操作と違って、ファイルシステム（ほぼパーティションに相当します）ごとにルートディレクトリがあります。C:ドライブやD:ドライブのあるWindowsの方式に近いです。Windowsではドライブキャラクタにコロンをつけるとそのドライブ内のルートディレクトリに移動します。このシェルでも同様にfs0:でESPのルートディレクトリに移動します。なのでこの後、\nls コマンドをタイプすると、ESPのルートのファイル名（多分EFIというディレクトリが一つ）見えます。この後は、ls, cd, cp, mv, cp, rm, edit, type (Unixのcatに相当)コマンドを駆使して、ファイルを操作します。\nconfig.plistを書き換える 動いているマシンのconfig.plistをちょっと変更したら起動しなくなってしまった、という経験は皆さん何度もされていると思います。そんな場合はUEFI Shellでconfig.plistを元のように書き換えてしまうことができます。起動しなくなってもCloverの起動選択画面表示はされると思いますので、そこでUEFI Shellを起動します。上記の手順を踏んで、ESPのファイルシステムに移動します。その後、\ncd EFI\\CLOVER ls edit config.plist とタイプすれば、CLOVERのディレクトリに行き、ファイルを一覧し、config.plistを編集できます。ディレクトリの区切りは、Unixのように/（スラッシュ）ではなく、\\（逆スラッシュ）です。これもWindowsのような流儀ですね。また、タブキーで補完機能が効くので、例えばedit conあたりでタブを押せばあとを補完してくれます。（Unixの補完と違って最初にヒットした名前に補完されるので多少注意が必要です。）\neditコマンドではフルスクリーンのテキストエディタが開きます。コントロールEでヘルプが表示されます。操作は簡単で、\nCtrl-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を保存し、エディタを終了した後で、\nexit もしくは\nreset コマンドをタイプしてシェルを抜けます。resetコマンドはシステムがリセットされます。exitコマンドでは、Clover選択画面に戻ります。大体はexitコマンドでokですが、変更内容によっては変更が反映されないことがあります。resetの方がより確実です。\nkext/efiファイルを差し替える kextやefiファイルを追加したり削除したことで起動しなくなる事故も多いです。これもEFI Shellの操作で復帰できます。kextやefiファイルを外したい場合は、cdコマンドでEFI/CLOVER/kexts/Otherに移動して（EFI Shellの中では区切りを逆スラッシュで指定します）、rmコマンドで削除するか、mvコマンドでバックアップ用のディレクトリに移動させるのが良いです。例えば、_unusedというディレクトリ（名前の最初の文字をアンダースコアにした理由は、ファインダーで上位に表示されるので分かりやすいかと思ったからです）がkextsの中に作ってある場合、ABCD.kextというkextは、\nmv ABCD.kext ..\\_unused\\. で移動します。もしくは、mvコマンドで、ABCD.kext.backupというようにファイルタイプを変えてしまうのも良いかと思います。バックアップせずにrmコマンドで消してしまっても良いです。\n起動に必須だったkext/efiを削除して起動しなくなった場合も同様な方法が可能です。上の例と同様に、もし削除する前に_unusedフォルダのような場所にバックアップされてあればそこから戻せます。\nmv ..\\_unused\\ABCD.kext . kext/efiとは違うファイルタイプに変えてあるのでしたら、名称変更すれば良いです。\nmv ABCD.kext.backup ABCD.kext ということで、kext/efiを削除する場合は、起動しなくなる状況に備えて戻せるように、ESPのどこかに残しておく事が重要です。\nまた新たに必要なファイルをUSBメモリに入れて、それを起動ESPに追加することも可能です。例えば、USBメモリの場所がfs3だったら、\ncp fs3:\\DSDT-XXXX.aml . のようにしてコピーすることが可能です。\n","date":"2019-04-18T20:06:05+09:00","image":"/uploads/2019/04/startUEFISHELL.jpg","permalink":"/posts/1754/","title":"起動しないマシンをUEFI Shellで救う"},{"content":"設定を変更したら起動しなくなってしまったという経験は誰にでもあると思います。その前に少しだけ準備しておけば復旧の手間を減らすことができます。そんな工夫をいくつか書き連ねてみました。\n本物のMacではmacOSが起動しない事態に陥ることは滅多にありません。しかし色々設定してなんとか本物のMacに近い動きを実現しているHackintoshでは、ちょっとした設定の変更やOSのバージョンアップでマシンが起動しなくなることはよくあることです。真っ黒な画面を目にして、設定を変えなければよかったとか、もっと考えてからバージョンアップすればよかったと後悔することが多いです。どんなに間違った設定をしても、それ以前に動いていたなら、インストールした手順を最初から繰り返せば元に戻せます。でもそこまで手間をかけなくても、大抵の失敗はもっと簡単に取り戻せます。\n追記：EFI Shellを使うと良いですとコメントいただきました。確かに、ここで書いた事態は、EFI Shellを使って回復できるようです。ということで、続きは以下をご覧ください。\n起動しないマシンをUEFI Shellで救う\n動作するconfig.plistをバックアップしておく config.plistをちょっとだけ書き換えたら動かなくなるという失敗はいつもやってます。こんな事態に備えて、動いているconfig.plistを変更する場合には、そのコピーを作っておくと良いです。コピーの名前は、configXXXXX.plistとします。例えば、\ncp config.plist config_old.plit としてから、config.plistに変更を加えます。こうするとESPのCLOVERディレクトリにconfig.plistとconfig_old.plistの二つの設定ファイルが出来上がります。CLOVERはconfig.plistの内容を読んで起動します。config.plistを書き換えたことにより起動に失敗する場合は、Cloverの起動ドライブを選ぶ画面から、Optionメニューを選んで、config.plistメニューを選びます。するとconfig_old.plistをラジオボタンで選択できます。これを選べば元どおり起動するはずです。\nESP全体をクラウドにバックアップしておく config.plistを別名でコピーしておくことを忘れてしまい、起動するconfig.plistがESPにもはや存在しない場合は、上の方法は使えません。ただ、Cloverのオプションメニューからは、いろいろな設定を一時的に変更できるので、それで復旧できることもあります。でも、config.plist編集以外の作業をした場合、例えばefiファイルやkextファイルを差し替えたとか、DSDTを書き換えたなどの場合は、復旧が難しい場合が多いです。\nその場合、動いていた時のESP全体のバックアップがあれば復旧は楽です。バニラなインストールをしている場合、ESP以外は実機のMacと同じで、いろいろな復旧方法があります。OSならApp Storeからダウンロードし直せば良いです。またTime Machineでバックアップしておけば、データが壊れたとしても取り戻せます。HDDを多数接続できる自作HackintoshはTime Machineの利用がやりやすいので、是非検討してください。\nTime Machineは良いです\nESPは常時マウントするものでは無いので、Time Machineバックアップには不向きです。量も少ないですし、手作業でバックアップしておくのが良いでしょう。バックアップ先は色々考えられますが、今時ならばクラウドが良いと思います。絶対安全ですし、紛失しませんし、他のマシンからアクセスできるので、復旧用USBメモリーを作成するのも簡単です。バックアップのタイミングも色々考えられますが、一番効率が良いのは、ESP書き換え作業の直前です。作業直前に動作している最新のESPをバックアップしておけば、次の起動に失敗しても復旧できます。ということで、ESPをマウントすると同時にバックアップを取っておく方法を以前にこちらで説明しました。\nESPをマウントしてついでにバックアップする\n訓練：バックアップESPから復旧する いざという時に本当に復旧できるのかどうか、訓練してみました。まずはメインで使っているHackintoshをシャットダウンします。次に、サブで使っているMacBookで、以下の作業をしました。\n適当なUSBメモリ(GUIDパーティション) のESPをマウントして開く iCloudドライブにアクセスして最新ESPをUSBメモリにコピーする 手持ちのGUIDパーティションのUSBメモリーにEFIがなかったり、diskutil repairdiskコマンドでEFIが作れるらしいとか、でもUSBメモリーのサイズが小さいとEFIが作れないなど、色々発見がありましたが、最終的にはUSBメモリーで無事起動できました。\n画面共有・sshサーバを起動しておく macOSのインストールに成功して、ネットワーク機能が動くようになったらすぐにやっておくと良いことがあります。それは、「システム環境設定」「共有」から「画面共有」と「リモートログイン」を有効にしておくことです。リモートログインはsshd (sshのサーバ) を動かす機能です。これらが有効になっていれば、他のマシンから画面共有やsshで接続することができます。\nHackintoshを設定していて、グラフィックス機能が動かなくなり、起動しても画面が出ないことがあります。また、スリープから目覚めた時に、グラフィックス機能が復帰できずに画面が真っ黒なままなこともあります。このような場合、コンピュータは止まっているように見えますが、内部では動いています。なので、画面共有やsshで接続して、設定を調整し直すことが可能です。また、それが可能ならば、不具合の原因がグラフィックス関係であることが特定できます。\nAPFSコンテナにボリュームを作っておく macOSのバージョンアップで起動しなくなる場合もあります。Cloverやkext類が最新でないことが原因である場合が多いです。また、kextをバージョン別のフォルダに入れている場合、新しいバージョン用のフォルダを作り忘れるというケアレスミスもあります。現在動いているmacOSを非常用のシステムとしてインストールしておくと、このような場合に早く復旧作業に入れます。外付けのドライブやUSBメモリーに非常用のシステムを作っておくと、いざという時に見つからない場合もあります。接続中のドライブに非常用システムのボリュームを作っておくのが安心です。\nAPFSになってからボリュームを作る作業が楽になりました。APFSコンテナの中に、好きな時に必要なだけのボリュームを作ったり消したりできます。パーティション一つがボリューム一つだった時代は、使われない記憶領域ができて無駄だったのですが、APFSのボリュームなら必要な記憶容量しか使用しません。何も加えないmacOSならば14GBほどのサイズです。私が作ったMojaveの起動ボリュームは13.6GBでした。これが苦にならない程度のAPFSコンテナがあれば、非常用システムを作っておくと良いと思います。こちらで説明しておきました。\nAPFSのVolumeを活用する\n","date":"2019-04-14T15:59:40+09:00","image":"/uploads/2018/09/20180628102100.png","permalink":"/posts/1621/","title":"Hackintoshが起動しなくなる前にやっておくこと"},{"content":"ASUS マザーボードのUSB設定をしました。使わないUSBポートの番号を調べ、その番号をconfig.plistに書きます。これでmacOSの個数制限によりUSB 3が使えなくなる事態を回避します。以下の記事で紹介しているように、ASUS MAXIMUS HEROマザーボードに9900Kを搭載したマシンは順調に稼働しています。\n9900K搭載Z390マザーボードでHackintoshを作る\n今回、回避しようとしているのは、macOSのUSB個数制限です。macOS El Capitanから使用可能なUSBポートの数が、 コントローラ当たり15までと制限されてしまいました。理由は不明です。この対策は何通りかありますが、15個の制限は残したまま、使用しないUSBポートを除外するようconfig.plistに設定するのが一番良いと思います。\nUSBポートを設定する\n上の記事では、MSI Z97A Gaming 7マザーボードを例に、使用しないポートをconfig.plistに書くことで、必要なUSBポートが使用可能になるよう設定しました。同じ手順をASUS MAXIMUS XI HEROマザーボードでも行いました。\nUSBInjectAll.kext まずはUSBInjectAll.kextを入手してEFI/CLOVER/kexts/Otherフォルダに入れます。\nRehabMan / OS-X-USB-Inject-All / Downloads — Bitbucket\nこのkextは、チップセットで用意されているUSBポートの全てをmacOSから参照できるように設定する機能があります。この記事で利用しようとしている機能、config.plistの起動オプションで使用しないポートを除外する機能は、このkextが提供しています。\n何も対策しない場合のUSB構成 まずは、何も対策しないとどのUSBポートが見えているのかを確認します。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。\nmac.softpedia.com\nIORegistryExplorer.appを起動して、右上の虫眼鏡アイコンのところに、xhcと入力します。するとXHC関係の情報が現れます。全く対策しない状態のASUS MAXIMUS XI HEROマザーボードでは、以下のような結果になりました。\nXHCの下にHS01~14とUSR1が見えています。これらが現在OSが認識しているUSBポートです。macOSは15個しか認識しないので、アドレスの低い方から15個のポートが見えています。マザーボードにはこれ以外にもUSBポートがあるのですが、15個超えているものは見えません。\nUSRを除外する HSはHigh Speedの略でUSB 2.0のことです。USRは、tonymacx86の説明によると何らかの都合で見えてしまっているダミーのポートらしいです。なので除外しても良いらしいです。とりあえずUSR1を除外してみましょう。USBInjectAll.kextを使用した上で、config.plistのBoot Argumentsに以下のように指定します。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;uia_exclude=USR1\u0026lt;/string\u0026gt; この結果、IORegistryExplorer.appの表示が以下のようになりました。\n新たにUSR2が見えるようになりました。実はこれも実存しない不要なポートらしいです。これも除外しましょう。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;uia_exclude=USR1;USR2\u0026lt;/string\u0026gt; この結果、IORegistryExplorer.appの表示が以下のようになりました。\n不要なUSR1, USR2を消したので、ようやくSSが見えてきました。SSはSuper Speedの略で、USB 3のポートを示しています。\nHS (USB 2.0) ポートを特定する この段階で見えているHSポートであるHS01からHS14の14個が、マザーボードにあるとmacOSが認識している全てのUSB 2.0ポートです。これがどこのポートなのか特定していきます。ちょっと大変な作業ですが、マザーボードの構成を把握できるので、達成感はあります。\nマザーボード上のUSB 2.0ピンソケットを調べるためには、こんなアダプタがあると便利です。\nそれぞれのポートに対応する番号を調べるためには、\nそれぞれのポートにUSB機器（無線アダプタやマウスなど）を接続し、 IORegistryExplorer.app の表示の変化を確認する ことで、特定できます。下の例は、とあるUSB 2.0ポートにLogicoolの無線キーボードアダプタを挿入してみたところです。HS11のport-statusが、最初は0x0だったのですが、下の図のように0x1100に変化しました。これで、このポートはHS11だということがわかります。USB 3のポートの場合、2.0と3の両方を持っていますから、USB 3.0のデバイスを挿せばUSB 3.0の番号が、USB 2.0のデバイスを接続すれば、USB 2.0端子の番号の、それぞれの該当項目が変化します。\nこうしてASUS MAXIMUS XI HEROマザーボードのUSB 2.0を調べました。各ポートの番号は以下のようになっていました。\nHS01 AsusTek社のAURA MOTHERBOARDが使用 HS02 (不明, マザーボード上のU31G2_2の可能性あり) HS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”) HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”) HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″) HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下) HS07 バックパネルUSB 3のUSB 2.0 (4列上から1番目、青、”SS”) HS08 バックパネルUSB 3のUSB 2.0 (4列上から2番目、青、”SS”) HS09 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0 HS10 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0 HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記) HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”) HS13 マザーボードの2.0端子USB_E12, USB_E34 (USB2.0 Hub経由) HS14 マザーボード上のWiFi/Bluetoothモジュールが使用 HS09とHS10は、マザーボード上のUSB 3.1 Gen 1ポートに接続しています。マニュアルには下のような図面があります。マザーボード上にU31G1_910と書かれたソケットがあり、ここにUSB 3.1 Gen 1が2本出ています。それぞれに付随しているUSB 2.0端子がHS09とHS10に接続しています。\nHS13は、マザーボード上のUSB 2.0端子に接続しています。マニュアルには下のような図面があります。マザーボード上にはUSB_E12, USB_E34という名称のソケットがあり、ここにUSB 2.0が4ポート出ています。ただ、これらの4ポートは内部でUSBハブに接続していて、HS13が大元になっているようです。今回は、この基板上USB 2.0端子の一つにBluetoothユニットを接続しています。なので、HS13だけは除外できない重要なポートです。\nバックパネル部分は以下になります。\n少し面白い発見だったのはHS01です。IORegistryExplorer.appの検索窓の文字を消すと、絞込み機能が無効になり、全ての情報が見えるようになります。そしてHS01の詳細を見てみます。すると以下のように、名前がAURA MOTHERBOARDになっていて、製造者名はAsusTek Computer Inc.と表示されます。どうやらマザーボードの電飾ユニットに接続されている様子です。もしもこれをプログラムできればmacOSから電飾をコントロールできるのかと思われます。\nマザーボードが使っているUSB 2.0はもう一つあります。HS14です。これはバックパネルにアンテナが出ているインテル製のWiFi/Bluetoothモジュールが使っています。この無線モジュールは、内部がA/E KeyのM.2ソケットになっているのですが、このKeyのソケットにはUSB 2.0が1個含まれています。そのUSB 2.0がHS14に接続されているようです。BIOSで無線モジュールをEnabledにして起動すると以下のようにBluetooth Host Controllerと表示されます。Disableにした時は何も接続されない状態の表示になります。idVendorの項目を見ると0x8087です。これはインテル社のIDです。\nBluetooth以外のHS (USB 2.0)を全部除外する USR1, USR2を除外したことで、USB 3としてはSS01があることはわかりました。他のUSB 3ポートは15個の制限で隠されています。そこで、全てのUSB 3ポートを調べるために、絶対必要なHS以外を一時的に除外します。Bluetoothは基板のHS13に接続されているので、これが無いとキーボードとトラックパッドの操作ができなくなってしまいます。そこで、これ以外のHSを全部除外してみます。Boot Argumentsに以下を書いてみました。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;\u0026gt;uia_exclude=USR1;USR2;HS01;HS02;HS03;HS04;HS05;HS06;HS07;HS08;HS09;HS10;HS11;HS12;HS14\u0026lt;/string\u0026gt; この結果、IORegistryExplorer.appの表示が以下のようになりました。\nHS13を含めて全部で11項目あります。15個未満なので、これで全てです。ということでこのマザーボードにはSS01からSS10までの10個のUSB 3があることがわかりました。\nこのマザーボードはインテルのZ390チップセットを使っているのですが、インテルの仕様によるとUSB 2.0が14本、USB 3.1が10本あり、最大で14本のUSB 2.0/3.1を使用できることになっています。このマザーボードはチップセットが提供するUSBの全てを使っているようです。\nSS (USB 3) ポートを特定する USB 3であるSSがSS01からSS10まで10個見えるようになりました。これらのうちバックパネルのSSを特定しました。これにはUSB 3.0のUSBメモリを挿しながら調べました。\nSS01 (不明, 未使用?) SS02 (不明, マザーボード上のU31G2_2の可能性あり) SS03 バックパネルUSB 3.1 Gen 2 (4列上から3番目、赤、”SS10”) SS04 バックパネルUSB 3.1 Gen 2 (4列上から4番目、赤、”SS10”) SS05 バックパネルUSB 3.1 Gen 2 (Ethernetの下、赤、”SS10″) SS06 バックパネルUSB TYPE CのUSB 3.1 Gen 2 (Ethernetの下) SS07 バックパネルUSB 3.1 Gen 1 (4列上から1番目、青、”SS”) SS08 バックパネルUSB 3.1 Gen 1 (4列上から2番目、青、”SS”) SS09 マザーボードのU31G1_910の USB3.1 Gen 1 SS10 マザーボードのU31G1_910の USB3.1 Gen 1 このマザーボードはHSとSSの数字部分が対応しているようです。バックパネル写真に合わせると以下のようです。ちなみに、バックパネルのUSB 3ポートには、青いポートにSS、そして赤いポートにSS10と表示が書いてあるのですが、これはそれぞれ3.1 Gen 1とGen 2を示しているようです。10というのはおそらくGen 2の転送速度である10 Gbpsのことだと思います。\nSS09とSS10はマザーボード上のUSB 3.1 Gen 1ポートであるU31G1_910に接続しています。マニュアルの図を再掲します。\nSS01とSS02は発見できませんでした。上で書いたように、このマザーボードはUSB 3.1とこれに付随するUSB 2.0のそれぞれのHSとSSに、同じ番号を割り当てています。HS01はマザーボードの電飾コントローラと思われるので、これに対応するSS01は存在しないのかと推測されます。SS02とこれに関係する可能性のあるHS02は、共に発見できませんでした。このマザーボード上にはUSB 3.1 Gen 2のコネクタもついています。U31G2_2という名前です。別売の「USB 3.1 Gen 2 ポート増設用モジュール」というものを接続するコネクタらしいのですが、手元に無いのでチェックできませんでした。SS02とHS02は、このU31G2_2に接続しているのかもしれません。\n必要なUSBポートを選んで他を除外する さて以上からほぼ全てのUSBポートの番号がわかりました。ここから、使用したいUSBポートを最大15個選び、それ以外の使用しないポートを除外する設定をします。\n基板上の3.1 Gen 1コネクタを使用しない場合 マザーボード上のUSB 3.1 Gen 1ポートであるU31G1_910を使用しない場合を考えます。基板上のUSB 2.0コネクタに関しては、Bluetoothモジュールが使用するのでこれ (HS13) は外せません。HS13と、バックパネルのポートを全て使うことにすると、必要なポートは以下のようになりました。\nHS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”) HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”) HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″) HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下) HS07 バックパネルUSB 3のUSB 2.0 (4列上から1番目、青、”SS”) HS08 バックパネルUSB 3のUSB 2.0 (4列上から2番目、青、”SS”) HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記) HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”) HS13 基板の2.0端子USB_E12, USB_E34 (USB2.0 Hub経由) SS03 バックパネルUSB 3 Gen 2 (4列上から3番目、赤、”SS10”) SS04 バックパネルUSB 3 Gen 2 (4列上から4番目、赤、”SS10”) SS05 バックパネルUSB 3 Gen 2 (Ethernetの下、赤、”SS10″) SS06 バックパネルUSB TYPE CのUSB 3 Gen 2 (Ethernetの下) SS07 バックパネルUSB 3 Gen 1 (4列上から1番目、青、”SS”) SS08 バックパネルUSB 3 Gen 1 (4列上から2番目、青、”SS”) なんと全部でちょうど15個です。そこで、これ以外を除外するよう設定します。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;uia_exclude=USR1;USR2;HS01;HS02;HS09;HS10;HS14;SS01;SS02\u0026lt;/string\u0026gt; 末尾に近いSS09以降は、除外リストに入れる必要はないです。この結果、IORegistryExplorer.appの表示が以下のようになりました。\n基板上の3.1 Gen 1コネクタを使用する場合 大抵のPCケースには全面パネル近辺にUSB 3.1 Gen 1ポートが2個付いています。これを使用するためには、マザーボード上のU31G1_910に接続することになります。U31G1_910は、HS09, HS10, SS09, SS10です。先のリストは最大限度の15個に達しているので、4個を削除しないとこれらを使えません。そこでバックパネルにあるUSB 3.1 Gen 1の青いポートであるHS07, HS08, SS07, SS08を除外することにしました。なんとなく残念ですが仕方ないです。そうすると使用するポートは以下になります。\nHS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”) HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”) HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″) HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下) HS09 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0 HS10 マザーボードの3.1 Gen 1端子U31G1_910に付随するUSB2.0 HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記) HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”) HS13 基板の2.0端子USB_E12, USB_E34 (USB2.0 Hub経由) SS03 バックパネルUSB 3 Gen 2 (4列上から3番目、赤、”SS10”) SS04 バックパネルUSB 3 Gen 2 (4列上から4番目、赤、”SS10”) SS05 バックパネルUSB 3 Gen 2 (Ethernetの下、赤、”SS10″) SS06 バックパネルUSB TYPE CのUSB 3 Gen 2 (Ethernetの下) SS09 マザーボードのU31G1_910の USB3.1 Gen 1 SS10 マザーボードのU31G1_910の USB3.1 Gen 1 これ以外を除外するには以下のように設定します。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;uia_exclude=USR1;USR2;HS01;HS02;HS07;HS08;HS14;SS01;SS02;SS07;SS08\u0026lt;/string\u0026gt; この結果、IORegistryExplorer.appの表示が以下のようになりました。\n補足：バックパネルのUSBポート マザーボードのマニュアルに掲載されているバックパネルのポートの説明図は以下です。USB 3ポートのうち、青いポートがGen 1ポート、赤いポートとType CポートがGen 2ポートのようです。\nつづき：USB構成を記述したSSDTを作る この記事では起動オプションで使用USBポートを指定しています。USBInjectAllの機能をフルに活用するためには、SSDTファイルを作ることが理想的です。続きは以下の記事をご覧ください。\n15個制限を回避するUSBInjectAll.kextの役割と使用法\n","date":"2019-04-09T23:35:30+09:00","image":"/uploads/2019/03/backpanel.png","permalink":"/posts/1424/","title":"ASUS MAXIMUS XI HEROのUSBを設定する"},{"content":"コメント欄にいろいろ書き込みをいただけるようになったので、記事内容にこだわらない話題や質問などを書き込めるフォーラムを作ってみました。上のメニューから「フォーラム一覧」を選ぶとフォーラムに移動します。今の所、カテゴリー分けしていませんので、なんでも自由に書き込んでください。フォーラム機能を使うことは初めてのことなので、色々と不具合あるかもしれません。それもおしらせください。匿名でも書き込めるよう設定したつもりなのですが、どうでしょう？メールアドレスはダミーでも投稿できるとおもいます。\n","date":"2019-04-07T23:45:28+09:00","image":"/uploads/external/pc_radeon_rx590.png","permalink":"/posts/1604/","title":"フォーラム（掲示板）を作りました"},{"content":"（10.14.5が配布されたのでこの情報は不要になりました。）\nこの記事の執筆時点で配布されているmacOS Mojave 10.14.4はビルド18E226です。しかし最新のiMac Early 2019には18E2034が搭載されています。これが簡単に入手できることがわかりました。\n新iMac対応Mojaveが欲しい 第9世代CPU 9900KでHackintoshを作ったら、機種ID、シリアル番号、ボードIDなどのSMBIOS設定も同じCPUを搭載するiMac Early 2019に合わせたいところです。ところがボードIDを27インチiMac Early 2019の値、Mac-AA95B1DDAB278B95に設定するとmacOSが起動しません。\nCloverのブートオプションに-no_compat_checkを追加するだけで簡単に回避できるのですが、できれば対応したmacOS Mojaveが使いたいと考えていました。10.14.5が出るまで待たねばと思っていたところ、コメント欄から、実機に搭載されている10.14.4 (18E2034)が入手できたとの情報をいただきました。試してみました。\niMac19,1の設定でMojaveを入手 入手方法は簡単で、iMac19,1として動いているマシンからApp Storeに接続してMojaveをダウンロードするだけです。\n今回使用したマシンは、ASUS MAXIMUS XI HEROに9900Kを搭載したHackintoshです。iMac E2019が店頭に出回る前には、このマシンをMacmini8,1と設定していました。その時に、App StoreからMojaveを入手して、インストールしていました。これをiMac19,1のSMBIOS情報に設定し直した状態の「このMacについて」ウィンドウが以下です。\nビルドは通常配布されている18E226であることがわかります。iMac19,1に設定すると、上で述べたようにそのままでは起動しないので、Cloverのブートオプションに-no_compat_checkを追加して無理やり起動しています。CPUは9900Kなのですが、表示では不明になっています。この状態で、再び10.14.4を入手し直します。まずは、App Storeへ接続し、Mojaveを検索してそのページに移動します。\nここで「入手」をクリックすると、いつものようにソフトウェア・アップデートのウィンドウに移動します。次にダウンロードボタンを押すと、macOS Mojaveインストール.appを入手することができます。\nこの方法で入手できるインストーラのバージョンは14.4.10です。\nこれを使ってMojaveをインストールすると、ビルドが18E2034になります。\nプロセッサは不明のままです。（途中でメモリを追加したので容量が増えていますが同じマシンの画面です。）\n18E2034はEarly 2019限定？ 面白いことにiMac19,1（と多分iMac19,2）に設定されていないマシンからApp Storeに行っても、18E2034はダウンロードできないようです。本物のMacでも試みましたがダメでした。その場合、ダウンロードされるインストーラのバージョンは14.4.08になります。これをインストールするといつものビルド番号である18E226になります。\n手順のまとめ 以上から、現時点で、9900Kマシンを作って対応したmacOSを入手する手順はこうなると思います。\n9900Kマシンを作る 本物のMacでMojave 10.14.4インストーラを入手する。本物はおそらくMacがiMac Early 2019では無いので、18E226になる。 9900Kマシンにインストールする。この時、SMBIOSをiMac19,1に設定しても良いが、ボードIDの関係で起動しないので、ブートオプションに-no_compat_checkを追加しておく。 起動した9900KマシンからApp Storeへ行って、再度10.14.4を入手してインストールする。これでビルドが18E2034になる。 ","date":"2019-04-06T12:47:04+09:00","image":"/uploads/2018/11/mojave.png","permalink":"/posts/1576/","title":"9900KのためにmacOS 10.14.4 (18E2034) を入手する"},{"content":"iMac Early 2019でようやく第9世代CPUがサポートされました。出回っている機種情報を使ってシリアル生成ソフトを用意して、config.plistのSMBIOSセクションを作りました。実機に近い設定ができたと思います。\niMac E2019の情報 以下で紹介しましたが、新型iMac Early 2019 (27インチのiMac19,1と21.5インチのiMac19,2) が出たおかげで、macOSもようやく最新のデスクトップCPUに対応しました。ただし新型iMacには、最新の10.14.4のビルド番号18E226よりも新しいバージョン (18E2034) が搭載されているようです。第9世代CPUに完璧に対応したmacOSを一般人が入手できるのは次のバージョン (10.14.5もしくはSU) になりそうです。\n新型iMacに第9世代CPUがようやく搭載される\nここで参考にした情報は、「マックお宝」が公開しているYoutubeのビデオ、Geekbenchのスコアページ、店頭で見てきた情報などです。\nシリアル番号 シリアル番号は「このMacについて」を見ればすぐにわかります。現在店頭にあるiMac E2019は、全て中国製で、（当たり前ですが）2019年製造です。なので、シリアル番号の最初4桁は、全てC02Yです。シリアル番号の仕組みはこちらをご覧ください。\nMacシリアル番号の仕組み\n次の桁は製造週ですが、店頭にある製品は9週もしくは8週です。9週のものが多かったです。2019年の第9週は2/26から3/4の週で、8週はその前の2/19から2/25の週を表します。\n次の3桁は製造ライン番号と言われていて、製品個別の番号です。最後の4桁がモデルコードです。iMac19,1のモデルコードにはJV3Q, JV3P, JV3N, JV40が、iMac19,2のモデルコードにはJWDW, JWDXが発見されました。この他にも多数のコードがあるはずです。みなさんも発見できたら是非ともコメントでおしらせください。他の記事でも紹介していますが、正しいモデルコードならば次のURLのPPPPの場所に指定すると該当マシンの仕様ページが表示されます。\nhttp://support-sp.apple.com/sp/index?page=cpuspec\u0026amp;cc=PPPP 以上のことから、現在店頭にあるシリアル番号は、C02Y9xxxJV3Qなどとなります。\nボードシリアル番号 ボードシリアル番号は、シリアル番号より確認しづらいです。後述のmacserialプログラムでも確認できますが、macOSの標準コマンドでしたらnvramコマンドが使えます。ターミナルから次のコマンドをタイプすれば表示されます。\nnvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB 現在店頭にあるiMac E2019のボードシリアル番号は、本体と同じく中国製のようです。製造年は、当然ながら2019年で、製造週は、本体より1週間早く、07週もしくは08週でした。ボードシリアル番号の後半には、ボードの種類を示すボードコードがあります。iMac19,1のボードコードにはLNV9, KDP0が、iMac19,2のボードコードにはKGQGが発見されました。なので、現在店頭にある製品のボードシリアル番号は C02908xxxxxLNV9xxなどになります。\nその他のID ボードIDは、iMac19,1がMac-AA95B1DDAB278B95、iMac19,2がMac-63001698E7A34814でした。これはGeekbenchのページでも確認できます。これ以外にはありません。\nまた、システム情報に出てくる番号として、ブートROMのバージョンがあります。これはどれも220.250.368.0.0でした。\nシリアル生成プログラム シリアル番号の仕組みの記事では、シリアル番号を自動生成してくれるプログラムmacserialをご紹介しました。これをforkさせていただき、上記で得たシリアル番号生成のための情報を付け加えました。これでiMac E2019のシリアル番号を自動生成できます。Intelの8600, 9600K, 9900KをCPUとして使用したHackintoshを作る場合には、iMac19,1のシリアル番号が最適です。8100, 8500, 8700の場合は、Macmini8,1でも良いかもしれませんが、iMac19,2も使えます。コンパイルしたバージョンのmacserialをこちらに置いておきました。\nReleases · bootmacos/macserial\n./macserialとして起動すると現在のマシンのIDを表示します。./macserial -hでヘルプが出ます。iMac19,1のシリアル番号を生成したいのでしたら、./macserial –model iMac19,1とタイプすると、シリアル番号、ボードシリアル番号の一覧を出してくれます。\n./macserial --model iMac19,1 C02YC017JV3Q | C02909207GULNV9AD C02Z7JYAJV3Q | C02933102GULNV9JA C02YNYZNJV3Q | C02918200GULNV91F C02ZP0XSJV3Q | C02946802QXLNV91H C02YRAYQJV3Q | C02921200GULNV9A8 C02YN3ZGJV3Q | C02918403GULNV9CB C02YM085JV3Q | C02917403CDLNV9AD C02ZC0AFJV3Q | C02936303GULNV91F C02Y800NJV3Q | C029078024NLNV9FB C02ZP2YPJV3Q | C029467004NLNV91M ./macserial –info とすると、そのシリアルの情報を表示します。例えば、上の例の最初の候補の場合、\n./macserial --info C02YC017JV3Q Country: C02 - China (Quanta Computer) Year: Y - 2019 Week: C - 10 (05.03.2019-11.03.2019) Line: 017 - 41 (copy 1) Model: JV3Q - iMac19,1 Valid: Possibly と表示されます。2019年第10週の製造です。最初の製品の2週間後の製造なので、ちょうど良いくらいかと思います。数か月後くらいの多少の未来の番号でもおそらく大丈夫だと思います。しかし、最初の製品が第8週製造なので、これよりも以前の2019年1~7週の番号は避けた方が良いと思います。\nシリアル番号を既に決めているのであれば、./macserial –mlb で、同じ国で、前の週に製造されたロジックボードのシリアルを生成してくれます。\n./macserial --mlb C02YC017JV3Q C02909108GULNV9AD SMBIOSを書く それではiMac19,1に限りなく近い設定のSMBIOSセクションを書いてみましょう。上記の例のシリアル番号・ボードシリアル番号を使う場合、以下のようになるかと思います。（皆さんのご自分の番号を使ってください）SmUUIDも、ターミナルのuuidgenコマンドで適当に生成して記入してください。\n\u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Board-ID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Mac-AA95B1DDAB278B95\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02909108GULNV9AD\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;EfiVersion\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;220.250.368.0.0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMacm19,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02YC017JV3Q\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; Board-IDはiMac19,1に使用されているロジックボードIDを入れました。EfiVersionは、ここに書いておけば、本物のiMac E2019と同様に、「システム情報」のブートROMのバージョンの項目に表示されます。これ以外のSMBIOSの項目はCLOVERが自動生成してくれます。もしかしたら現バージョンのCloverはiMac19,1に対応していないかもしれませんが、将来のバージョンでは対応するはずです。\nこのSMBIOSを使ってみた このSMBIOSを9900K搭載のHackintoshに設定し、App Storeで配布されている通常のmacOS Mojave 10.14.4 (18E226)で使ってみたところ、残念なことに起動しませんでした。こんな画面になってしまいました。\n一般配布されている10.14.4は、iMac19,1に搭載されているビルド番号18E2034と異なっていて、ボードIDがサポートされていないようです。10.14.5まで待てば解決されるかと思います。それまでの間は、config.plistのBootオプションに、\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;-no_compat_check\u0026lt;/string\u0026gt; と記載して、互換性チェックをしないように指定しておくことにしました。\niMac E2019対応の10.14.4を入手する と、思っていたところ、iMac E2019対応の10.14.4 (18E2034)を入手する方法をコメント欄で教えてもらいました。おかげさまで、-no_compat_checkのブートオプションを付けなくても起動するようになりました。この10.14.4を入手する方法は簡単で、iMac19,1 または19,2に設定したマシンでApp Storeを起動して、Mojaveを検索してダウンロードするだけです。これをインストールすると、iMacに搭載されているビルドと同じ18E2034になります。それでも、プロセッサは「不明」と表示されてしまいます。これはちょっと謎です。\nClover ConfiguratorがiMac19,xに対応 macserialをforkしてiMac19,1, 19,2に対応させた後、オリジナルのmacserialのacidantheraさんにPull requestsしておきました。そうしたらすぐに承認されて、macserialのソースコードに反映されました。コミュニティへの本当に些細な寄与ですが、初めてなので嬉しいです。その結果、かどうかわかりませんが、Clover ConfiguratorもiMac19,xに対応してくれたようです。これでSMBIOSが簡単に作れるようになりました。\nシリアル番号をいくつか発生させてみたところ、上で紹介したモデルコードとボードコードを使ったシリアルが現れます。今回調べた情報を使ってくれているようです。\n","date":"2019-04-03T18:04:56+09:00","image":"/uploads/2019/04/notsupported_small.jpg","permalink":"/posts/1534/","title":"第9世代CPU用のSMBIOSを書く"},{"content":"10.14.4へのアップデートが現地時間で昨日公開されました。早速インストールしてみたところ、9900KのiGPUを使うためのconfig.plistの設定が不要になっていました。第9世代CPU搭載のiMacが発売された直後のリリースなのでこれに対応したものと思われます。\n10.14.3以前で必要だった設定 9900Kを使うためには、config.plistのDevices, Propertiesの項目にiGPUの設定が必要でした。9900Kにも、MacBook Pro 2018やMac mini 2018のCPUにも、同じIntel UHD グラフィックス630が搭載されています。しかし、デバイスIDが異なっていました。そのため、config.plistに、本物Macに搭載されているiGPUのデバイスIDを書いておく必要がありました。以下のようにです。\n\u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; mz4AAA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; これを設定すれば完璧に動作しますが、書いておかないと、\nスリープが正しく機能しない。（画面は暗くなるもののCPUファン電源が遮断されない。さらには、その後スリープから復帰しない。） JPEGファイルのクイックルックができない。 などの不具合が発生しました。こちらをご覧ください。\n9900Kのsleep問題〜原因はiGPUのデバイスID\n10.14.4で互換性が向上 10.14.4にアップデートしたところ、device-idの記述を含めて、Propertiesの記載を全部削除しても、スリープとクイックルックが問題なく動作しました。（10.14.3でPropertiesの記載を削除すると、これらの問題が発生することを確認しています。）。新型iMacが対応したことで第9世代CPUの互換性がさらに向上したものと思われます。これを反映した9900K用のconfig.plistを以下に掲載しておきます。SMBIOSのProductNameはMacmini8,1です。新型iMacの情報が判明したら差し替えたいと思っています。\nconfig.plist for 9900K w/o iGPU display - Pastebin.com\n","date":"2019-03-26T17:58:21+09:00","image":"/uploads/2018/12/cpu.png","permalink":"/posts/1489/","title":"10.14.4で第9世代CPUの互換性が向上"},{"content":"Hackintoshを作る時には、機種IDやシリアル番号などのいくつかのIDを決める必要があります。今回はシリアル番号とボードシリアル番号の文字・数値の意味を説明します。以下の、シリアル番号自動生成ツールの資料とソースコードを参考にしました。\nGitHub - acidanthera/macserial: Decode mac serial number\nHackintoshに必要な番号 HackintoshがMacとして機能するためには、機種ID、様々なシリアル番号、ファームウェアバージョンなどを決めておく必要があります。これらはconfig.plistのSMBIOSセクションに記述されます。Clover configuratorを使うと、Macの機種を指定するだけでSMBIOSに書くべき内容を自動的に作成してくれます。しかし、最近のバージョンのCloverでは、SMBIOSのほとんどの内容を自動的に設定してくれますので、この機能に任せた方が間違いが無くて良いです。またBIOSバージョンなどの数値は、本来ならばmacOSインストーラがファームウェアアップデートすると更新される数値なので、Cloverが決めてくれる最新値を使う方が良いです。Cloverに任せておけば、間違いのない最新の数値を設定してくれます。\nその一方で、手作業で設定した方が良い番号もあります。以下の設定です。\n\u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;xxxxxxxxxxxxx\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Macmini8,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;xxxxxxxxxxxx\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; ProductNameは、機種IDに相当します。一般には、ハードウェア構成（特にCPUの種類）が一番近いMacの機種IDを設定するのが良いです。SmUUIDは、ターミナルから何度かuuidgenとタイプして得られる32桁の適当な数値を設定しておきます。一部のソフトウェアではインストール台数制限のチェックにも使っているようです。一度決めたら変えない方が良いです。\nSerialNumberはMacのシリアル番号です。本物のMacでは筐体に刻印されています。また、BoardSerialNumberはロジックボード（Apple社はマザーボードをロジックボードと呼びます）のシリアル番号です。ロジックボードに刻印されていることがあります。普通にMacを使っている限り、どちらの番号もずっと同じものですが、Macを修理してロジックボードを交換するとBoardSerialNumberは違うものになる可能性があります。\nSerialNumberとBoardSerialNumberはとても重要です。これが正しい値に設定されていない場合、iMessageやApp Storeなどが正しく機能しない場合があります。2014年8月から2015年2月にかけて、iMessageでのシリアル番号チェックが非常に厳しくなった時期がありました。これをきっかけにシリアル番号のリバースエンジニアリングが進みました。\nシリアル番号 Macのシリアル番号には11桁のものと12桁のものがあります。古い機種は11桁で、最近の機種では12桁です。それぞれの桁は、以下のような意味があります。\n| Type | Location | Year | Week | Line | Platform | | --------- | --------- | ---- | ---- | ---- | -------- | | Old (11) | LL | Y | WW | SSS | PPP | | New (12) | LLL | Y | W | SSS | PPPP | 以下では、以下のiMac15,1のシリアル番号の例（12桁）を使って説明します。\nC02PJTYNFY10 製造場所番号(2 or 3桁) 最初の3桁 C02は製造国、製造都市、メーカなどを表します。C02は中国のQuantaコンピュータが製造したという意味だそうです。他に判明している3桁コードは以下です。\n- 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桁です。以下の意味だそうです。\n- 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は整備品であることを表しています。\n製造年(1桁) 例に示したシリアル番号の、次の一桁であるPは製造年を表します。12桁のシリアル番号では各年号に英字が割り当てられています。ペアの最初の英字が1-6月で、後半が7-12月を表しているそうです。なので、Pは2015年前半を表します。アルファベットのうち英字のI, Oなどが抜けているのは1や0と間違えやすいからだと思われます。他の欠番も何か理由があってのことと思います。\n| 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)\n11桁シリアル番号では、製造年は西暦一桁めの数値です。\n| Char | Year | | ---- | ---- | | `3` | 2003 | | `4` | 2004 | | `5` | 2005 | | `6` | 2006 | | `7` | 2007 | | `8` | 2008 | | `9` | 2009 | | `0` | 2010 | | `1` | 2011 | | `2` | 2012 | こちらは2012年に一巡して破綻してます。現行のシリアル番号も2020年以降の年番号がどうなるのか心配です。\n製造週(2 or 1桁) 例に示したシリアル番号の、次の一桁であるJは製造週を表します。これは1月1日から始まる7日を最初の週としています。なので最後の週以外は全て7日間です。次の27種類の英数字が使われます。シリアル番号の例では、2015年の前半年とわかりましたので、Jは15週目を表しています。\n| 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までの数値で表現されます。\n製造ライン(3桁) 例に示したシリアル番号の、次の3桁であるTYNは製造ラインもしくは、組み立て担当者のIDを表していると考えられています。それぞれの桁は、IとOを除く0からZまでの英数字を0から33に割り当てた数値を表しています。この3桁は、製品個体ごとに違い、一台一台を特定する部分です。\n| 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に変換されているようです。\n1桁目 x 68 + 2桁目 x 34 + 3桁目 この例のTYNは、それぞれ27, 32, 22を表し、上の式から2,946になります。\n27 x 68 + 32 x 34 + 22 = 2,946 製造コピー 上の計算式はちょっと変わっています。34進数だと考えたら最初の桁は34×34倍すべきなのですが、68倍になっています。何か根拠のある計算式ではあると思われますが、この計算では、得られる数値に重複が発生します。\n例えば、 0L0, 1J0, 2G0, 3E0, …, 920という複数の英数字が、どれも680という製造ライン番号になります。別の例では、KYL, LWL, MUL, …, Z4Lという英数字は、どれも2400という数字になります。同じ数値になってしまう英数字の組を、製造コピーと呼んでいます。最初の桁の値の小さい方から1, 2, 3,…と番号をつけます。この例では、0L0やKYLがコピー1、1J0やLWLがコピー2などです。920と74Lは、最後のコピーです。英数字の組み合わせによりコピーの総数は変わります。色々な実験で、最初のいくつかのコピーだけが、Appleから有効だと判定されるようです。無効だと判定されたコピー番号より大きな番号のコピーは全て無効になります。Apple内部のことはもちろんわかりませんが、一つのラインから製品が製造されるごとに、コピー値が増加するのではないかと推定されています。何れにしても、ある値を示す製造ライン番号のうち、最初のコピーを使用するのが安全であると言えます。\nプラットホームモデル(3 or 4桁) 11桁シリアルでは最後の3桁、12桁シリアルでは最後の4桁が、製品種類を表す番号です。例に示したシリアル番号では、最後の4桁であるFY10がこのプラットホームモデルです。この4桁が製品機種を表していることは、以下のURLにアクセスすることで確認できます。\nhttp://support-sp.apple.com/sp/index?page=cpuspec\u0026amp;cc=PPPP ここのPPPPの部分にFY10を入れてアクセスすると\nhttp://support-sp.apple.com/sp/index?page=cpuspec\u0026amp;cc=FY10 iMac15,1の仕様書ページにリダイレクトされます。iMac15,1にはLate 2014とMid 2015の2機種がありますが、このモデルはMid 2015年のiMacであることがわかります。\nちなみに一つの機種ID（例えばiMac15,1）が全て同じプラットホームモデル（ここではFY10）になるわけではありません。同じ機種IDでも製造時期が違うと仕様が異なります。それで複数のプラットフォームモデルが割り当てられています。例えば、iMac15,1に相当するプラットホームモデルは、以下の27種類が確認されています。\n\u0026#34;FY10\u0026#34;, \u0026#34;FY11\u0026#34;, \u0026#34;FY14\u0026#34;, \u0026#34;FY68\u0026#34;, \u0026#34;FY6F\u0026#34;, \u0026#34;GCTM\u0026#34;, \u0026#34;GDQY\u0026#34;, \u0026#34;GDR3\u0026#34;, \u0026#34;GDR4\u0026#34;, \u0026#34;GDR5\u0026#34;, \u0026#34;GDR6\u0026#34;, \u0026#34;GDR7\u0026#34;, \u0026#34;GDR8\u0026#34;, \u0026#34;GDR9\u0026#34;, \u0026#34;GDRC\u0026#34;, \u0026#34;GFFQ\u0026#34;, \u0026#34;GJDM\u0026#34;, \u0026#34;GJDN\u0026#34;, \u0026#34;GJDP\u0026#34;, \u0026#34;GJDQ\u0026#34;, \u0026#34;FY13\u0026#34;, \u0026#34;FY6D\u0026#34;, \u0026#34;GL1Q\u0026#34;, \u0026#34;GL1R\u0026#34;, \u0026#34;GL1T\u0026#34;, \u0026#34;GL1V\u0026#34;, \u0026#34;GL1W\u0026#34; シリアル番号の注意事項 シリアル番号は上記のフォーマットに従って、適切な値が入っている必要があります。そうしないと、iMessageへのアクセスなどでAppleから無効なモデルと判定される可能性があります。\nまた、細かい整合性もチェックしておいた方が良いと思われます。例えば、製造年、製造週は、プラットホームモデルが示す発売日より後の日付である方が良いでしょう。また、製造ラインのコピー数は、できるだけ小さい値、できればコピー1である方が安全です。\n上の例で示したC02PJTYNFY10は、\nCountry: 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月発売 となります。製造日が発売日より早いのが気になりますが、発売日に備えて前もって製造しているはずなので、それほど不自然ではないと思います。\nまた、下記のサイトで生成したシリアル番号が未使用であることは、確認しておくべきかと思います。「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。\nボードシリアル番号 SMBIOSでもう一つ設定しないといけない番号がボードシリアル番号です。12桁シリアル番号の場合、ボードシリアル番号は17桁です。ロジックボードのシリアル番号です。修理によってロジックボードは交換される可能性があることもあり、Appleはそれほど厳密にはチェックしていないと感じています。昔のガイドでは、12桁のシリアル番号に適当な英数字を5個足しておけば良いとか、LANのMACアドレスの一部を足しておけば良いなどというゆるい手法が説明されていることもあります。\nClover configuratorなどに搭載されている最近のシリアル番号発生機能では、シリアル番号と対になってボードシリアル番号も作り出してくれます。それを採用しておけば良いです。例えば、先の例で使用したシリアル番号C02PJTYNFY10と対で生成されたボードシリアル番号は\nC02514701CDG2Y71H でした。これを例に構成を調べていきます。\n製造場所番号(3桁) シリアル番号と同じで、最初の3桁は製造国、製造都市、メーカなどを表します。この例のC02は中国のQuantaコンピュータです。\n製造年(1桁) 4桁目は年号です。西暦年号の1の位です。この例では、シリアル番号が2015年なので、それに合わせて5になっているようです。\n製造週(2桁) 次の2桁は製造週です。上の例では、14週目の製造という意味です。シリアル番号は15週目でした。ロジックボードが製造されたあとで、本体が製造されるのが自然ですから、前の週に製造されたことにしているのだと思います。\nMLBBlock1(3桁) 以下のいずれか一つの数値です。Clover configuratorやmacserialが自動生成する場合には、この中から乱数で選んでいるようです。\n\u0026#34;200\u0026#34;, \u0026#34;600\u0026#34;, \u0026#34;403\u0026#34;, \u0026#34;404\u0026#34;, \u0026#34;405\u0026#34;, \u0026#34;303\u0026#34;, \u0026#34;108\u0026#34;, \u0026#34;207\u0026#34;, \u0026#34;609\u0026#34;, \u0026#34;501\u0026#34;, \u0026#34;306\u0026#34;, \u0026#34;102\u0026#34;, \u0026#34;701\u0026#34;, \u0026#34;301\u0026#34;, \u0026#34;501\u0026#34;, \u0026#34;101\u0026#34;, \u0026#34;300\u0026#34;, \u0026#34;130\u0026#34;, \u0026#34;100\u0026#34;, \u0026#34;270\u0026#34;, \u0026#34;310\u0026#34;, \u0026#34;902\u0026#34;, \u0026#34;104\u0026#34;, \u0026#34;401\u0026#34;, \u0026#34;902\u0026#34;, \u0026#34;500\u0026#34;, \u0026#34;700\u0026#34;, \u0026#34;802\u0026#34; MLBBlock2(2桁) 以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。\n\u0026#34;GU\u0026#34;, \u0026#34;4N\u0026#34;, \u0026#34;J9\u0026#34;, \u0026#34;QX\u0026#34;, \u0026#34;OP\u0026#34;, \u0026#34;CD\u0026#34;, \u0026#34;GU\u0026#34; ボードコード(3 or 4桁) ロジックボードの種類を示す英数字です。一つのモデルに対して多数のコードが発見されているようです。例えば、上の例のiMac15,1では、以下のコードが使われているようです。このリストのうち、最初のコードG2Y7が、問題が少ないとされているので、これが使われることが多いようです。\n\u0026#34;G2Y7\u0026#34;, \u0026#34;G2Y8\u0026#34;, \u0026#34;GG3L\u0026#34;, \u0026#34;GG3N\u0026#34;, \u0026#34;G2QD\u0026#34;, \u0026#34;G2QF\u0026#34;, \u0026#34;GG3T\u0026#34;, \u0026#34;GG3W\u0026#34;, \u0026#34;FT04\u0026#34;, \u0026#34;FW6K\u0026#34;, \u0026#34;GG3K\u0026#34;, \u0026#34;GG3M\u0026#34;, \u0026#34;FW29\u0026#34;, \u0026#34;FW2C\u0026#34;, \u0026#34;GG3Q\u0026#34;, \u0026#34;GG3V\u0026#34;, \u0026#34;FQY8\u0026#34;, \u0026#34;FTPF\u0026#34; MLBBlock3(2桁) 以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。\n\u0026#34;1H\u0026#34;, \u0026#34;1M\u0026#34;, \u0026#34;AD\u0026#34;, \u0026#34;1F\u0026#34;, \u0026#34;A8\u0026#34;, \u0026#34;UE\u0026#34;, \u0026#34;JA\u0026#34;, \u0026#34;JC\u0026#34;, \u0026#34;8C\u0026#34;, \u0026#34;CB\u0026#34;, \u0026#34;FB\u0026#34; ボードシリアル番号の注意事項 上記で、「自動生成する場合には乱数で選んでいる」と書きましたが、生成プログラムのソースを見ると、チェックサムも考慮しています。ボードシリアル番号が表す値を、最初から奇数番目の桁はそのまま、偶数番目の桁は3倍して足していき、その合計が34の倍数である場合は正しいチェックサムを持ったボードシリアル番号としているようです。正しいチェックサムになるまで、ランダムに候補を選んでいるようです。手作業では面倒なので、自動生成ツールを使うのが良いです。\n機種のシリアル番号に比べて、ボードシリアル番号はAppleにより厳しく検査されることはないので割と適当でも大丈夫な印象があります。シリアル番号の製造週より前の製造週にしておいた方が良いでしょう。自動生成ツールでは、シリアル番号の前の週になるように生成しているようです。ただ、ロジックボード交換修理する可能性も考えると、それもチェックされていないと思います。何れにしても、以下の自動生成ツールを使えば、整合性のある番号を生成してくれますので問題ありません。\nシリアル番号自動生成ツール シリアル番号はClover configuratorでも生成できますし、この記事の冒頭で示したmacserialというツールでも生成できます。おそらくはClover configuratorもmacserialと同じアルゴリズムを使っているのではないかと思います。macserialは、冒頭のリンクからソースコードを入手してコンパイルしても良いです。また以下のサイトで、コンパイル済みのコードも配布されています。\nReleases · acidanthera/macserial\n更新：現在は以下で配布されているようです (2019/12/28)。\nReleases · acidanthera/MacInfoPkg\n更新2 : 現在はOpenCoreに含まれています (2020/8/14)。\nGitHub - acidanthera/OpenCorePkg: OpenCore bootloader\n現時点では2.0.4が最新のようです。mac版とwindows 32版があるようです。zipをダウンロードすると解凍されてmacserialというファイルができます。\n$ ./macserial として起動すると、現在のMac/Hackintoshのシリアル番号などの情報が表示されます。–helpとすれば使い方の説明が表示されます。\n$ ./macserial --help ./macserial arguments: --help (-h) show this help --version (-v) show program version --deriv \u0026lt;serial\u0026gt; (-d) generate all derivative serials --generate (-g) generate serial for current model --generate-all (-a) generate serial for all models --info \u0026lt;serial\u0026gt; (-i) decode serial information --list (-l) list known mac models --mlb \u0026lt;serial\u0026gt; generate MLB based on serial --sys (-s) get system info Tuning options: --model \u0026lt;model\u0026gt; (-m) mac model used for generation --num \u0026lt;num\u0026gt; (-n) number of generated pairs --year \u0026lt;year\u0026gt; (-y) year used for generation --week \u0026lt;week\u0026gt; (-w) week used for generation --country \u0026lt;loc\u0026gt; (-c) country location used for generation --copy \u0026lt;copy\u0026gt; (-o) production copy index --line \u0026lt;line\u0026gt; (-e) production line --platform \u0026lt;ppp\u0026gt; (-p) platform code used for generation –generateオプションで現在モデルのシリアル番号とボードシリアル番号を複数生成してくれます。–generate-allで全てのモデルの番号を生成します。–model Macmini8,1などとすれば特定のモデルの番号を生成してくれます。–info シリアル番号でそのシリアル番号を分析してくれます。例えば、この記事で例に使ったC02PJTYNFY10でしたら、\n$ ./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 のように表示されます。\n","date":"2019-03-24T12:52:47+09:00","image":"/uploads/2019/03/About-this-Mac-Mojave.png","permalink":"/posts/1432/","title":"Macシリアル番号の仕組み"},{"content":"昨日(2019/3/19)、唐突に発表された新型27インチiMacに、第9世代CPUがようやく搭載されました。第8世代CPUを搭載したiMacもいくつか発表されました。搭載されているCPUの具体的な型番は公表されていませんが、第9世代CPUはCore i5-9600KとCore i9-9900Kのようです。\n21.5インチモデル 21.5インチモデルでは新型2機種が発表されました。いずれもRetina 4Kディスプレイモデルです。ここでは仕様のページ\n27インチiMac - 仕様\nに準じて、CPUのクロック数でモデルを区別します。新発売されたのは以下の2機種です。\n3.6GHzモデル 新発売の21.5インチの下位モデルです。最下位モデルがそのまま継続されているので、21.5インチモデルの中では中位モデルです。仕様によると「3.6GHzクアッドコア第8世代Intel Core i3プロセッサ」とあります。インテルのCPU仕様書サイト\nインテル製品の仕様\nで調べてみると、該当するCPUはCore i3-8100 もしくは Core i3-8100Bのようです。無印とBモデルの違いは、ピンがソケットか半田付けかの違いだけです。\n3.0GHzモデル 新発売の21.5インチの最上位モデルです。仕様によると「3.0GHz 6コア第8世代Intel Core i5プロセッサ\nTurbo Boost使用時最大4.1GHz」とあります。インテルのCPU仕様書サイトによると、Core i5-8500 もしくは Core i5-8500Bのようです。\nオプション 新製品の2モデルともに、CPUをアップグレードできます。仕様によると「3.2GHz 6コアIntel Core i7（Turbo Boost使用時最大4.6GHz）に変更可能」だそうです。インテルのCPU仕様書サイトによると、Core i7-8700 もしくは Core i7-8700Bのようです。\n27インチモデル 27インチモデルは全て刷新されました。3モデルあります。そのうち最上位モデルのみが第9世代CPUです。インテルの第9世代は生産の問題があり、下位モデルが発売されていません。アップルも苦肉の策で、最上位モデルのみ最新CPUを採用することになったようです。ここでもクロック数でモデルを区別します。\n3.0GHzモデル 新発売の27インチの最下位モデルです。仕様によると「3.0GHz 6コア第8世代Intel Core i5プロセッサ\nTurbo Boost使用時最大4.1GHz」とあります。インテルのCPU仕様書サイトによると、Core i5-8500 もしくは Core i5-8500Bのようです。21.5インチ最上位モデルと同じですね。\n3.1GHzモデル 新発売の27インチの中位モデルです。仕様によると「3.1GHz 6コア第8世代Intel Core i5プロセッサ\nTurbo Boost使用時最大4.3GHz」とあります。インテルのCPU仕様書サイトによると、Core i5-8600のようです。\n3.7GHzモデル 新発売の27インチの最上位モデルです。仕様によると「3.7GHz 6コア第9世代Intel Core i5プロセッサ\n（Turbo Boost使用時最大4.6GHz）」とあります。ようやく第9世代CPU搭載モデルの登場です。インテルのCPU仕様書サイトによると、Core i5-9600K ~~または Core i5-9600KFのようです。KFモデルはiGPUが搭載されていないモデルです。~~今までの流れからしてiGPU無しのCPUは使われないと思います。なのでCPUはCore i5-9600Kのようです。\nオプション 27インチモデルの上位2モデルは、CPUをアップグレードできます。仕様によると「3.6GHz 8コアIntel Core i9（Turbo Boost使用時最大5.0GHz）に変更可能」だそうです。インテルのCPU仕様書サイトによると、Core i9-9900Kのようです。\n現行iMacのCPU一覧 ということで予想したCPU番号をまとめておきます。継続して販売されている21.5インチ最下位モデルもまとめに入れておきました。\n21.5インチiMac最下位モデル Core i5-7360U 21.5インチiMac中位モデル Core i3-8100 or Core i3-8100B 21.5インチiMac最上位モデル Core i5-8500 or Core i5-8500B 21.5インチiMacオプション Core i7-8700 or Core i7-8700B 27インチiMac最下位モデル Core i5-8500 or Core i5-8500B 27インチiMac中位モデル Core i5-8600 27インチiMac最上位モデル Core i5-9600K 27インチiMacオプションCore i9-9900K 第9世代CPUが搭載されたことで、9900Kや9600Kを使ったHackintoshがさらに安定すると思われます。新iMacに対応したmacOSは次のアップデートから入手可能ですので、次のmacOS Mojave 10.14.4が楽しみです。\n標準モデルの27インチ最上位が6コア6スレッドの9600Kなのはちょっとバランスが悪い気がします。コア・スレッド数は下位モデルと同じです。ここは8コア8スレッドの9700Kを搭載して欲しいと思いました。\nT2チップは搭載されず 今回はCPU交換のマイナーチェンジのようです。そのためかT2チップは搭載されていないようです。Hackintoshから見ると色々厄介になることが予想できるので、搭載されなくてよかったです。次の本格的なアップデートでは搭載されるのかもしれません。\nその後の情報 2019年3月19日あたりから店頭でも販売されるようになりました。実機に触れるようになったので、色々情報がわかってきました。SMBIOSが構成できるだけの情報が早く用意されると嬉しいです。\n搭載macOS コメントでいただいた情報などによると搭載されているmacOSは10.14.4 (18E2034)だそうです。一般の10.14.4が18E226なのでだいぶ違うようです。ちなみに10.14.3 SUは18D109でした。\n機種ID コメントでいただいた情報や、他のネット上の情報などを見ると、機種IDは以下のようです。いままでは、27インチモデルの方が,2になっていたことが多いと思うので、逆ですね。\niMac19,2 21.5インチiMac Early 2019 iMac19,1 27インチiMac Early 2019 CPU 英語版のWikipediaに仕様が書かれていました。公式の情報ではないですが、ある程度信用できそうな気がします。それによると、CPUは、\niMac19,2 8100, 8500, 8700 (option) iMac19,1 8500, 8600, 9600K, 9900K (option) とのことで、上の予想であっているようです。第8世代は、Mac miniとは違い、Bモデルでは無いようです。\nシリアル番号 アップルストアで「このMacについて」を撮影していた動画がありました。これです。それによると、以下のシリアル番号が確認できました。\niMac 27-inch 3.7 GHz Intel Core i5-9600K: C02Y90H3JV3Q iMac 21.5-inch 3 GHz Intel Core i5-8500: C02Y93YXJWDX iMac 21.5-inch 3.6 GHz Intel Core i3-8100: C02Y81DCJWDW 最後の4文字、JV3Q, JWDX, JWDWがモデルIDです。以下のURLでApple社の仕様のページに行くことができるので、モデルIDであることを確認できます。\nhttp://support-sp.apple.com/sp/index?page=cpuspec\u0026cc=JV3Q http://support-sp.apple.com/sp/index?page=cpuspec\u0026cc=JWDX http://support-sp.apple.com/sp/index?page=cpuspec\u0026cc=JWDW C02Yは、中国製造で2019年上期の製造を表し、その次の9は2/26から3/4の週、8は2/19から2/25の週にそれぞれ製造されたことを表しています。残りの3文字は個体の番号です。\nボードID Geekbenchにもベンチマーク結果が上がるようになってきました。iMac19,1で検索するといくつか見つかります。Build 18E2034となっているので、Hackintoshではなくて本物のようです。ここからボードIDがわかります。Apple Inc. Mac-AA95B1DDAB278B95 iMac19,1のようです。BIOSはApple Inc. 220.250.368.0.0のようです。SMBIOSのどれに当たるのかはちょっと不明です。ちなみに、iMac19,2の方はApple Inc. Mac-63001698E7A34814 iMac19,2とのことです。\n","date":"2019-03-20T12:06:36+09:00","image":"/uploads/2019/03/imac.png","permalink":"/posts/1457/","title":"新型iMacに第9世代CPUがようやく搭載される"},{"content":"Z390チップセットの9900Kマシンは順調に動いているのですが、起動ドライブは手元にあった2.5 inch SSDを流用してました。これを今風のM.2 SSDに交換しました。\n9900K搭載Z390マザーボードでHackintoshを作る\nストレージ構成をどうするか ATX基板を使っていますし、ケースはそれなりの大きなケースを考えているので、SATAケーブルで接続するドライブはいくつか使用するつもりです。大容量の3.5 inch HDDを2台くらいは使って、片方をデータの倉庫に、もう一方をTimeMahineのバックアップに使おうと考えています。Windowsは滅多に使わないのですが、気が変わってWindows用に2.5 inch SSDを一個くらい付けるかもしれません。\nM.2 SSDは高速・小型なので、将来はM.2が主流になって、SATAケーブルで接続するドライブはマイナーな存在になると思います。ただ現状では、M.2 SSDは、割高ですし、体感速度で考えると2.5 inch SSDとそれほど違わないし、他のマシンやMacにつなぎ変えて動作を確認するなどの場面では取り外し・取り付けが面倒です。ということで、メインで作業するデータ領域（/Users）は、2.5 inch SSDにして、システム領域（/、/System、/Applications、/Libraryなど）だけをM.2 SSDにするのが良いと考えました。ということで、ゆくゆくは\n250GB程度のシステム用（root用）M.2 SSD 1TB程度のデータ用（/Users）2.5 inch SSD 4TB程度のTimeMachine用3.5 inch HDD 4TB程度のデータ倉庫用3.5 inch HDD の構成を考えています。\nM.2 SSDを選定 そこで第一歩として、中小容量のシステム用M.2 SSDを物色しました。OSとアプリケーションを入れるだけなら120GB程度でも十分な容量なのですが、SSDの構造上、容量が小さいと書き込み時間が遅くなります。120GBは製品もあまり多くないので、選択肢の多い250GBを選ぶことにしました。Hackintoshでは、SamsungのSSDがよく使われているようです。tonymacx86などでも実績があります。今回はいろいろ探して評判の良かったWestern DigitalのWD BLACK SN750を使うことにしました。カタログスペックでは、シーケンシャルRead:3,100MB/s、シーケンシャルWrite:1,600MB/sで高速です。以前使っていたSSDはコントローラがかなり高温になったものですが、この製品はそれほど発熱しないような気がします。\n最近のSSDの低価格化に寄与している技術が、記憶セルあたりの情報量を増やす手法です。通常のメモリは、セルに電荷を貯める・貯めないの2状態で1ビットを記録します。貯める電荷量を、3段階にすれば、電荷が無い状態を含めて4状態になり、2ビット記録できます。記憶セルあたり1ビット記録する方式をSLC (シングルレベルセル)、2ビットをMLC (マルチ〜)と呼ぶようです。さらに8状態にして3ビット記録するTLC (トリプル〜)や、16状態にして4ビット記録するQLC (クアドラプル〜)があるようです。セルあたりの記憶量を増やすことで、低価格なSSDが作れます。その一方で、速度や耐久性が弱くなると指摘されています。WD BLACK SN750はTLCのSSDのようです。（最初の記事ではSLCだと勘違いしていました。訂正します。）若干不安はありますが、ちゃんとした製品なので当然のことですが、何の問題もなく動いています。\nマザーボードに取り付ける ASUS MAXIMUS XI HEROにはSSD用に2個のM.2ソケットが用意されています。\nマザーボードの中央、CPUの近くにあるM.2_1と、マザーボードの端にあるM.2_2です。それぞれ多少機能が違います。\nM.2_1はKey M, Type 2242/2260/2280のSSD用で、インタフェースはPCI Express 3.0 x4およびSATAに対応します。ただしSATA SSD取り付けた場合、SATA 6Gb/s 第 2ポート(SATA6G_2)は無効になります。 M.2_2はKey M, Type 2242/2260/2280/22110のSSD用で、インタフェースはPCI Express 3.0 x4のみに対応します。 WD BLACK SN750は、2280のSSDでPCI Express 3.0 x4接続なので、どちらのソケットにも取り付けることができます。どちらでも良かったのですが、M.2_2の方を使うことにしました。というのは、M.2_1は、CPUに近くて、大きなCPUクーラを使用すると、取り付け・取り外し作業が困難です。また、M.2_2の方がより大型の22110対応なのでヒートシンクが大きく、多少は放熱性能が良いと考えたからです。\nHackintoshのインストール すでに2.5 inch SSDでHackintoshが動いているので、この先の作業は簡単です。成功することが見えているようなものです。\nM.2 SSDをソケットに取り付ける 現在の2.5 inch SSDで起動してM.2 SSDをAPFSでフォーマットする App StoreからmacOS Mojaveインストール.appを入手する macOS Mojaveインストール.appを起動してM.2 SSDにmacOSをインストールする\n（インストール中に2度ほど再起動しました。Cloverのドライブ選択画面でBoot macOS install from xxxx (M.2 SSDにつけた名前）が表示される間は、そのドライブを選びます。） Cloverインストーラを起動してブートローダ類をM.2 SSDにインストールする config.plist, efi, kext類を2.5 inch SSDからM.2 SSDのESPにコピーする 今回は、何の問題もなくインストールできました。しかしMojaveになってからmacOSのインストールに失敗する場面が増えたように思います。どうしてもmacOSがインストールできない場合は、最後の手段として、M.2 SSDを本物のMacにUSB接続してインストールするのも良いと思います。その場合、M.2 SSDを2.5 inch SATAドライブのように変換してくれるアダプタがあると便利です。\nmacOSのインストールが終わったら、2.5 inch SSDのCloverからM.2のmacOSを起動します。macOSとしての設定を色々終了したら、CloverをM.2にインストールします。また、2.5 inch SSDのESPから、config.plistやkext類を、M.2のESPにコピーします。以上で、M.2 SSDに問題なく移行できました。\n","date":"2019-03-11T18:08:02+09:00","image":"/uploads/2019/03/1899146-n0.png","permalink":"/posts/1416/","title":"ASUS MAXIMUS XI HEROにM.2 SSD (WD SN750)を取り付ける"},{"content":"更新：ここで紹介した対策は10.14.4で不要になりました。以下は10.14.3以前の情報です。不要になった理由は、9900K CPUがmacOSでサポートされるようになったからだと思われます。10.14.4以降では、以下で説明しているデバイスIDも9900Kの本来の値で問題ありません。本来の値はWhateverGreen.kextが自動で設定してくれますので、config.plistにデバイスIDを書く必要がありません。\nASUSのZ390マザーボードで作ったHackintoshのその後の報告です。sleep/shutdownが全て完璧に動くようになりました。最初の記事はこちらです。（今回の対策を追記してあります）\n9900K搭載Z390マザーボードでHackintoshを作る\nその後、シャットダウンが不完全な問題を解決すべく試行錯誤したところで、EmuVariableUefi-64.efiを使うことで解決しました。\nASUS Z390マザーボードのshutdown/sleep対応\nsleepがまだ不完全 一時はこれで解決したかに見えたのですが、sleepからの復帰がおかしいです。iGPUを使うと、sleepで画面が消えた後、キーボード押下で画面が復帰します。ただし、画面が消えるだけで、CPUファンは回転し続けています。一方、グラフィックスカード(dGPU)を使うと、sleepで画面が消えた後、しばらくはキーボード押下で画面復帰するのですが、15秒くらい経つと画面が復帰しなくなります。さらに放置するとCPUファンの回転も中止しますが、やはり復帰しません。また、この状態ですとJPEGファイルのクイックルックも効かないようです。\nという状態で、しばらく頓挫していたのですが、ようやく解決したので報告します。たまたま hackintosher.comで紹介されていたconfig.plistを使ってみたらsleepが機能するようになったので、それと、問題を引き起こしているconfig.plistとの比較からの結論です。\nUHD Graphics 630のデバイスID Intel UHD グラフィックス630は、MacBook Pro 2018やMac mini 2018で使用されています。なのでmacOSの標準ドライバーでサポートされています。でも、UHD 630のデバイスIDはCPUごとに微妙に違います。例えばMacBook Pro 2018で使用される8750HのUHD 630のデバイスIDは0x3E9Bです。Mac mini 2018で使用される8700BのUHD 630デバイスIDも同じく0x3E9Bです。ところが今回使用している9900KのUHD 630のデバイスIDは微妙に違っていて0x3E98なのです。このデバイスIDの不一致が、sleep問題の原因のようでした。\ni3-8100でも対応必要 Intel UHDグラフィックス630のデバイスIDの違いは、他のCPUでも問題を引き起こすようです。こちらの記事\ncorpnewtさんのバニラガイド~Coffee Lake用config.plist\nで紹介しましたが、Core i3-8100のUHD 630もデバイスIDが異なっていて(0x3E92および0x3E91)、対応が必要だそうです。結果として今回も同じ問題のようです。\n9900KのデバイスID対応 上記の記事では、8700K搭載UHD 630のデバイスIDの指定方法が書いてあります。この方法に従うと、デバイスIDを逆順に（little endian方式に）並べた数値に、0x0000を付け加えた値をconfig.plistで指定すれば良いようです。\nただ、上記のサイトでは、「実際のデバイスIDをconfig.plistに書く」とありますが、今回の解決策は、「Macで使われているデバイスIDをconfig.plistに書く」という方法でした。逆のようです。9900KのデバイスIDは先に述べたように0x3E98ですが、これをconfig.plistに書くのではなく、Macで使われているiGPUのデバイスIDである0x3E9Bをconfig.plistで指定するようです。そこで、まずは0x3E9Bの順番を入れ替え、ゼロを追加します。つまり、0x9B3E0000を指定すれば良いことになります。config.plistではBase64で記述するので、変換します。ターミナルコマンドbase64で0x9B3E0000をBase64変換するには以下のようにタイプします。\necho -ne \u0026#34;\\x9B\\x3e\\x00\\x00\u0026#34; | base64 この結果\nmz4AAA== が得られます。この値を、Devicesの中のPropertiesにdevice-idキーとして追加します。\n\u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AwCSPg== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; mz4AAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; この結果、sleepが完璧に動くようになりました。つまり、sleepになるよう設定した時間になると、画面が消え、数秒してCPUファンが停止します。その後、キーボード押下などにより、元どおりの画面に復帰します。\n今回のconfig.plistの全体を以下に置いておきます。シリアル番号などは伏せ字になっています。\nconfig.plist for 9900K w/o iGPU display - Pastebin.com\n","date":"2019-03-06T21:10:29+09:00","image":"/uploads/2018/12/cpu.png","permalink":"/posts/1403/","title":"9900Kのsleep問題〜原因はiGPUのデバイスID"},{"content":"Intel NUCのmacOSをアップデートしようとしたら起動しなくなりました。原因は、CMOSメモリーバックアップ関係のようです。電池交換しても改善しませんでしたので、電池なしで使うことにしました。Hackintosh自体の問題ではないのですが、ありがちなトラブルの一つなのかと思います。\nOSアップデートで不調に IntelのNUCは、小型省電力のHackintoshを作るのに適しているので\nNUCで作る超小型macOSマシン\nHaswell搭載のD54250WYKHでmacOSをサーバにしています。これをmacOS 10.14.2で動かしていたものを、10.14.3にアップグレードしようとしたことがトラブルの発端でした。Mojaveになってから一部のHackintoshで、macOSインストーラが止まってしまうトラブルがあります。\nMojaveの「インストーラリソースが見つかりません」問題\nこのNUCもその一つで、High SierraからMojaveへのアップデート、10.14 –\u0026gt; 10.14.1, 10.14.1–\u0026gt;10.14.2のアップデートでこの問題が発生しました。mSATA経由のSSD（システムとユーザデータ用）とSATA経由の2.5インチHDD（データ保存用）を搭載しているのですが、HDDを一時的に外すことで問題なくアップデートできました。今回試みた10.14.2–\u0026gt;10.14.3へのアップデートでも同様に、「インストーラリソースが見つかりません。」のメッセージが出ました。そこでHDDを取り外すことにしました。\nHDD取り外しのために、電源を外して、裏蓋を開けて、HDDを取り外します。その後、起動しようとしたのですが、画面に何も表示されなくなりました。電源LEDも点灯しません。何度か試しているうちに、CPUファンが高回転で回り始めました。でも画面には相変わらず何も表示されません。\nEFIのCMOSが原因？ UEFIの設定画面を含めて画面への表示が一切出ません。NUCのファームウェア関係の問題のようです。念のために、HDD、SSD、無線LANカードなど、メモリー以外の後付け部品を取り外しました。が、症状は変わりません。\n検索したらこんな情報がありました。\nこの人は、Ubuntuを入れていたようです。CMOSメモリのバックアップ用ボタン電池を外して戻したら復活したとあります。この方法を試してみることにしました。ボタン電池は、基板の裏側にあるので、相当分解しないと到達しません。基板はギリギリでハマっているので、外すには手間がかかります。ようやくボタン電池に行き着いて、取り外したところ無事起動しました。CMOSデータのチェックサムがおかしいとか、時刻が未設定とのメッセージが出ます。電池外したので当然かと思います。UEFI設定画面も出たので、念のために工場出荷時状態にリセットして、Hackintosh用の設定（iGPUへの割り当てメモリを増やす、Vt-Dをdisableにする、起動ドライブを設定する）を行いました。\nこれで無事、10.14.3にアップデートできました。ただ、ボタン電池をつけた状態で、電源を外すと再び起動不可能になるようです。ボタン電池を外したままなら、時刻が初期化されますが、正常に起動します。そのほかのUEFIの設定は、短時間電源を外したくらいでは消えないようでした。ボタン電池が消耗していて中途半端にバックアップされているようにも思えます。ただ、ボタン電池の電圧をテスターで測ると3.25ボルトあるので、無負荷ならば電圧に問題はないようです。\nそこで同等のボタン電池を取り寄せて、取り付けてみました。新品の電池は3.40V程度でしたので、改善するかと思いましたが、残念ながら結果は同じです。CMOSメモリ本体の問題なのかもしれません。ということで電池を外したまま運用することにしました。ACアダプタを抜かなければ、起動に問題はありません。ACアダプタを抜いても、CMOSの内容が一部クリアされることと、時刻がリセットされること、チェックサムエラーの警告が出るだけです。起動ドライブが変わってしまうので設定し直す必要がありますが、それ以外の手間はありません。時刻も、macOSが起動すればNTPサーバから時刻を取り寄せて設定してくれます。\n","date":"2019-03-03T12:04:50+09:00","image":"/uploads/2017/11/20171116093346.png","permalink":"/posts/1376/","title":"macOSをアップデートしたらNUCが起動しない"},{"content":"過去の特定のバージョンのmacOSが必要になることが稀にあります。でも古いバージョンのmacOSは入手困難です。アップルから正規に入手できる時期に忘れずにダウンロードして確保しておきましょう。\n（更新：CatalinaとBig Surの情報を追記しました。2021/10/29）\n古いmacOSが必要になる時 OSの更新で使えなくなったハードウェアでマシンを組もうと思う時、古いOSが必要です。例えば10.14 MojaveからIntel HD Graphics 3000のドライバが削除されてしまったので、Sandy Bridgeの内蔵GPUは動かなくなってしまいました。そこで10.12 SierraからIntel HD Graphics 3000のドライバを持ってくると動きました。10.13 High Sierraのドライバでは動きませんでした。2世代前のmacOSをたまたま持っている人だけが対応できる方法です。\nまた、最初のiMac Proには10.13.2が搭載されていましたが、この時に10 GbpsのEthernetがmacOSで動くようになりました。搭載されているのは、一般的に使われているAquantia AQC107というチップです。ただし拡張カードのファームウェアが違うのでそのままでは動きません。10.13.3になった時に、なぜかmacOS対応のファームウェアが含まれていて、10 Gbpsカードを挿したままアップデートするとファームウェアが書き換えられてmacOSで動くと報告されています。10.13.2以下のHigh Sierraをたまたま持っている人だけが対応できる方法です。\n以上はかなりニッチな事例です。しかしMojaveでNVIDIAのドライバが動かなくなったので、いまだにHigh Sierraなどの古いmacOSが必要になる場面は多いかと思います。\n古いmacOSの入手方法 App Storeアプリから入手する App Storeから一旦購入したアプリケーションは、いつでも入手可能なところがApp Storeの優れた点です。この原則はmacOSでも有効で、一旦ダウンロードした古いmacOSは「購入済み」ボタンを押すとApp Storeの画面に現れました。\nでもMojaveになって、これが出来なくなりました。Mojaveからは、左下の名前をクリックすると現れる「アカウント」のページに、購入済みのアプリケーションが現れるようになりました。ただmacOSは現れません。私の場合は、なぜか古いmacOSのPublic BetaやGM Candidateが表示されます。昔購入したServer版も現れます。でもmacOSは現れません。現行のMojaveだけは、検索窓からMojaveを検索すると現れます。\nということでまだMojaveに移行していないみなさんは、High Sierra以前で稼働しているうちに、昔に購入したmacOSをダウンロードしておきましょう。\nプロダクトIDを手掛かりに入手する App Storeで配布されているソフトウェアは、プロダクトIDという一意の番号で管理されています。これを知っていればMojaveで選択肢に現れない古いmacOSをダウンロードできる可能性があります。\nこちらのサイト\nOS X 10.7 Lion ~ macOS 10.13 High Sierraまでのインストーラーアプリをダウンロ\u0026hellip;\nではいくつかのmacOSのプロダクトIDを紹介してくれています。それによると、\nOS X 10.7 Lion 444303913 OS X 10.8 Mountain Lion 537386512 OS X 10.9 Mavericks 675248567 OS X 10.10 Yosemite 915041082 OS X 10.11 El Capitan 1018109117または 1147835434 macOS 10.12 Sierra 1127487414 macOS 10.13 High Sierra 1246284741 macOS 10.14 Mojave 1398502828 macOS 10.15 Catalina 1466841314 macOS 11 Big Sur 1526878132 だそうです。この番号を使って、\nhttps://itunes.apple.com/jp/app/idプロダクトID?mt=12 にアクセスすると古いmacOSのApp Storeアプリ画面が開きます。ただ、現時点で試したところではYosemite以前はこんなダイアログが出て利用できないようです。\nこの方法でダウンロードできるのは以下のバージョンでした。\nEl Capitan https://itunes.apple.com/jp/app/id1147835434?mt=12 Sierra https://itunes.apple.com/jp/app/id1127487414?mt=12 High Sierra https://itunes.apple.com/jp/app/id1246284741?mt=12 Mojave https://itunes.apple.com/jp/app/id1398502828?mt=12 Catalina https://itunes.apple.com/jp/app/id1466841314?mt=12 Big Sur https://apps.apple.com/jp/app/macos-big-sur/id1526878132?mt=12 masコマンドを使う 上記のサイトではHomebrewで導入できるmasコマンドを紹介してくれています。コマンドラインからMacのApp Storeにアクセスするためのアプリケーションです。ターミナルで以下のようにすれば、Homebrewをインストールして、次にmasをインストールできます。\n/usr/bin/ruby -e \u0026#34;$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)\u0026#34; brew install mas 単にmasとだけタイプすると\nmas Available commands: account Prints the primary account Apple ID help Display general or command-specific help home Opens MAS Preview app page in a browser info Display app information from the Mac App Store install Install from the Mac App Store list Lists apps from the Mac App Store which are currently installed lucky Install the first result from the Mac App Store open Opens app page in AppStore.app outdated Lists pending updates from the Mac App Store reset Resets the Mac App Store search Search for apps from the Mac App Store signin Sign in to the Mac App Store signout Sign out of the Mac App Store uninstall Uninstall app installed from the Mac App Store upgrade Upgrade outdated apps from the Mac App Store vendor Opens vendor\u0026#39;s app page in a browser version Print version number とヘルプが出ます。\nmas intall プロダクトID とすればダウンロードできるようです。info, searchなどはあまり効きません。それに出てこなくてもinstallコマンドは動くことがあるようです。\nmas install 444303913 でプロダクトIDが分かっているうちの一番古いLionをダウンロードしてみました。\nApp Storeアプリからダウンロードする方法も、masコマンドも、どちらも購入したことのあるmacOSしか再入手できません。一旦はダウンロードしておく必要があります。\nマイナーバージョンを入手する 今までの方法で、運が良ければ古いmacOSを入手できます。でも入手できるのは、それぞれのメジャーバージョン（MojaveとかHigh Sierraなどのバージョン）の最終版です。例えばHigh Sierraなら10.13.6が入手できます。では10.13.3が必要な場合はどうしたら入手できるでしょうか？\nアップル社は統合アップデート(combo update)を長期にわたって配布してくれています。統合アップデートなら同じメジャーバージョンのすべての古いバージョンからアップデートできます。統合アップデートは、サポートページで検索したり、\n[Apple - Support - Downloads](https://support.apple.com/downloads/combo update)\nGoogleの検索で「macOS 10.13.3 combo update」などと検索すると出てきます。私が探せた一番古いcombo updateは10.2.4でした。\nOSメーカとしては、少しでも新しいバージョンにアップデートして欲しいので、全てのマイナーバージョンへのアップデートを配布し続けてくれているのだと思います。なのでできるだけ最初のマイナーバージョンを持っていれば、多くのマイナーバージョンへアップデートできます。例えば、10.13.0を持っていれば、10.13.1から10.13.6のすべてにアップデートできます。10.13.0は1ヶ月少しだけ配布されていました。今では入手できない貴重なバージョンですので、大事に保存しておきましょう。\nLionとMountain Lionが無償配布 （追記：2021/7/18）Appleの公式サポートページから、LionとMountain Lionが無料でダウンロードできるようになったようです。以下です。\nMac OS X Lion Installer\nMac OS X Mountain Lion Installer\nまとめ 古いmacOSを入手可能にしておくためには以下のことが重要です。\nどのメジャーバージョンのmacOSも一度はダウンロードしておくと良いです。例えば、Mojaveは嫌いだからといって次のバージョンが出るまでダウンロードせず放置していると、正規に入手するチャンスを逃してしまいます。 古いmacOSがApp Storeで入手できることをあてにしてはいけないです。いつダウンロードできなくなるかわかりません。手元にコピーを置いておくべきです。 できるだけ最初のマイナーバージョンを持っておくと良いです。全部のマイナーバージョンのコピーを集めておくのは面倒ですし、ストレージの場所も必要です。10.xx.0を持っていれば統合アップデートでどのバージョンにもアップデートできます。実用上は一番安定と思われる最終バージョンも持っていると良いと思います。High Sierraなら10.13.0と10.13.6を持っていれば完璧なコレクションになります。 ","date":"2019-02-11T12:54:54+09:00","image":"/uploads/2019/02/macos-family-240.png","permalink":"/posts/1309/","title":"古いmacOSをコレクションする"},{"content":"macOSをインストールする方法をご紹介してきたのですが、多数の記事に分散してしまっています。そこで、10.14 Mojaveをインストールするための参考になる関連記事へのポインタをまとめた総集編を作りました。より新しい10.15を対象とした情報は以下をご覧ください。\nHackintoshの作り方（総集編: macOS 10.15版）\n古い10.13を対象とした情報は、以下をご覧ください。\nHackintoshの作り方（総集編:10.13版）\n手順の概要を把握する こちらは9TO5MacのライターのJeffさんのビデオです。テンポよく紹介されていますので、全体の流れを確認するのに良いと思います。High Sierra時代のビデオですが、ほぼ変わらないので参考にしてください。\n/posts/121/\nmacOSインストールのアプローチはたくさんありますが、一番おすすめなのは、Cloverを使ってバニラなインストールをすることだと思います。そのことを説明しています。\n/posts/131/\nハードウェアを用意する Hackintoshを作るためには、互換性のあるハードウェアを自由に選んで組み合わせられる自作PCが、問題が少なく楽です。ノートPCなども可能ではありますが、上級者向けだと思います。以下では、第9世代CPUであるCoffee Lake-S Refreshで作った自作PCにMojaveをインストールする手順を書いておきましたので、参考にしてください。\n9900K搭載Z390マザーボードでHackintoshを作る\nCPUは、最新の第9世代Coffee Lake-S Refreshが良いと思います。Macで採用されている最新CPUは第8世代です。例えば最新Mac miniでは、モバイル版ではありますが、第8世代CPUが使われています。ピンが半田付け方式なだけで、デスクトップの第8世代Coffee Lake-Sと同じCPUですので、第8世代Coffee Lake-Sでも良いでしょう。インテルは現在、CPUの量産体制に問題があり、第8世代もローエンドモデルを中心にまだ現役ですので、入手は容易です。\nHackintoshのパーツ選び 【その1：CPU編】\nそうすると、マザーボードは、CPUに合わせて370もしくは390チップセット搭載マザーボードを選ぶことになります。ただ、これもわざわざ古いマザーボードを選ぶ理由はないので390チップセットが良いと思います。\nHackintoshのパーツ選び 【その2：マザーボード編】\nMojaveではNVIDIAのweb driverがサポートされなくなってしまいました。なので、グラフィックスカードはAMDしか選択肢はありません。Web driverが不要な古いNVIDIAなら使えますが、古い製品をこれから調達することもないと思います。詳しくは以下を参考にしてください。\nHACKINTOSHのパーツ選び 【その3：グラフィックス編】10.14以降版\n無線アダプタ、SSD, そのほかのパーツについても紹介しておきました。\n/posts/138/\nHackintoshのパーツ選び 【その5：SSD】\nHackintoshのパーツ選び 【その6：その他】\nマザーボードのBIOS/UEFIを設定する インストール先のコンピュータを組み上げたら、macOSが稼働するようにBIOS/UEFIを設定しておきます。この設定が間違っていると、それだけで起動しない場合もあります。\nマザーボード (BIOS) 設定\n必要なソフトウェアを入手する Hackintoshするには、macOS本体以外にオープンソースで有志が開発しているソフトウェアがいくつか必要です。必要なソフトウェアの名前で検索すれば、大抵の場合、ダウンロード先が見つかります。オープンソースのソフトウェアは、オリジナルを作った人の他に、いろいろな人がソースコードを引き継いで分岐（フォーク）して、開発を行なっている場合もあります。中には元祖の開発者が放置して、開発が止まっていることもあります。なので、検索して、現在一番活発に利用されているバージョンを使うのが良いです。ということで、古いハウツー情報のダウンロード先から入手するよりも、検索をして探すのがおすすめです。\nClover EFI bootloaderとefiドライバー “Clover EFI bootloader”で検索します。以下が本家かと思われます。\nhttps://sourceforge.net/projects/cloverefiboot/\nこちらでも最新版が配布されています。\nReleases · Dids/clover-builder\nCloverをダウンロードすると、インストーラ、efiドライバ、テーマファイルなども一緒に入手できます。\nkext類 FakeSMCをはじめとしたkext （カーネル拡張）が必要です。名前で検索します。例えば、FakeSMC.kextならば、”FakeSMC.kext”で検索すると、こちらで入手可能なことがわかります。\nRehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket\nこちらで紹介したKext Updaterを使うと、kextやCloverを個別にダウンロードすることもできます。こまめに更新されているので、最新版を確実に入手することができます。\nワンクリックで最新kextに〜Kext Updater.app (Ver. 2)\nMac上で導入用のUSBメモリを作る 次に、macOSを入手して、インストール用のUSBメモリを作ります。これは実際のMacで作業します。ついでに、実際のMacでこのUSBメモリが起動することを確認しておきましょう。次に、インストール対象のマシンで起動できるように、Cloverのインストールと設定も行っておきます。\n/posts/93/\nMac上でmacOSドライブを作る 冒頭で示した動画を含めて、多くのガイドではMac上で導入用のUSBメモリを作る方法を紹介しています。でも、最近では、本物のMacやHackintoshなどのmacOSが動くマシン（以下、親マシンと書きます）上でmacOSドライブを作る方が楽な気がしてきました。特にMojaveになったあたりから、createinstallmediaで作ったUSBメモリーからインストールしようとすると途中で止まってしまうことが時々あります。他のドライブを外したりすると解決することもありましたが、親マシンでインストールした方が確実です。\nそこで、Hackintoshで使おうとするSATA SSDドライブ、mSATA SSDカード、M.2 SSDカードなどを、直接、もしくは、USB外付けHDDケースに入れて、親マシンに接続します。これをGUIDパーティションマップでフォーマットします。パーティションのフォーマットはHFS+でも良いですが、インストール時にAPFSに変更されるので、最初からAPFSで良いかと思います。\n次にmacOSにインストーラを使ってmacOSを入れます。このドライブでちゃんと起動することを確かめておけば、問題を切り分けることができて楽です。以下の記事では、この方法でインストールしましたので参考にしてください。\n9900K搭載Z390マザーボードでHackintoshを作る\nmacOSのインストール途中で、何度か再起動することがあります。親マシンがHackintoshの場合は、インストール途中のCloverの起動画面で、”Boot macOS Install from (インストール先のボリューム名)”という項目を選びます。\nCloverとkextを入れる 親マシンで起動できるmacOSディスクが出来上がったら、親マシンに接続したまま、Cloverをインストールします。Cloverインストールの手順はこちらにも書いてあります。\nCloverインストーラの設定\nconfig.plistの例を示して、説明しました。\nconfig.plistの実例紹介\nconfig.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。\n正しく機種設定する (SMBIOSの設定)\nconfig.plistの解説では、Corpnewtさんのバニラガイドが簡潔で良いと思います。「Coffee Lakeマシンのためのconfig.plistの作り方」のページを以下で紹介しています。\ncorpnewtさんのバニラガイド~Coffee Lake用config.plist\nCloverをインストールしたら、次にkext類をESPの部分に入れます。kextについてはいくつかの記事で解説しましたが、こちらが簡潔かもしれません。\nCORPNEWTさんのバニラガイド~ Clover設定とkext\nmacOS環境を整える 以上の設定で、とりあえずの起動が行えることを目指します。それができたら、さらに、グラフィックスカード、Ethernet, サウンドの設定をします。以下の記事が参考になるかと思います。\n/posts/90/\nEthernetを設定する\n/posts/120/\n","date":"2019-02-08T15:54:05+09:00","image":"/uploads/2017/09/20170911214228.png","permalink":"/posts/1339/","title":"Hackintoshの作り方（総集編:10.14版）"},{"content":"今までkextファイルはEFI/Clover/kexts/Otherに置くと良いと紹介してきました。でも以下の投稿によるとそれは「全く正しくない」のだそうです。\n今回はHackintoshに必要なカーネル拡張ファイル（kextファイル）を置く場所に関する議論を紹介します。（コメントで紹介いただいた情報です。ありがとうございます。）\nkextを/L/Eに置く利点と方法 上記の投稿にはkextを/L/Eに置くべきである理由と、推奨するkextの置き方が書かれています。抄訳します：\nmacOSの流儀である FakeSMCなどを含むすべての3rdパーティkextは/Library/Extensions (以下/L/E) に置くべきです。多くの人が「これらのkextをEFI/Clover/kexts/Other (以下ESP) に置き、config.plistでInject KextsをYESにすることが、メンテナンスフリーであり、よりネイティブなmacOSインストール方法だ」という印象を持っているように思えます。しかしこの考えは完全に間違っています。\nこの俗説とは逆に、Cloverに3rdパーティkextをインジェクトしてもらうことは、クリーンなインストールにはならないどころか、その逆です。インジェクトされたkextはmacOSの保護メモリー空間の外側で機能します。大量のkextをインジェクトすると、システムが不安定になる可能性があります。Cloverによってインジェクトされる多くの3rdパーティkextは正しく動きません。インジェクトされたkextはカーネルキャッシュに含まれず、その結果macOSが行うエラー検査の対象外になります。kextを/L/Eに置くことは、アップルが推奨しています。何らかの周辺機器を買ってドライバをインストールする時、kextは/L/Eにインストールされます。Hackintoshのkextも同じです。\nCloverのkext読み込み機能の目的 /L/Eに追加のkextを置くのが正しいやり方なのだとしたら、なぜCloverはESPに置いたkextをインジェクトする機能を持っているのでしょうか？それは、次のような形式のmacOS、つまり\nMacOS Installer MacOS Updater MacOS Recovery をブートする場合に、最小限必要なkextを読み込むために必要だからです。これらはどれもフルサイズのmacOSではないため、通常の方法では必須kextを読み込めないので、Cloverがそれを行う必要があるのです。ほとんどの場合、これらのパッケージを機能させるためには、通常はEFI/Clover/kexts/Other に FakeSMC があれば良いです。場合によっては3rdパーティのストレージ制御用ドライバ、NASで動かすTimeMachineバックアップへのアクセス用ドライバ、ノートPCのマウス用ドライバなどが必要なこともあります。このような、本当に必要なkextだけをEFI/Clover/kexts/Otherに入れます。\nCloverのDetect設定 Hackintoshに必要なkext類を、\n通常のmacOSブート時は、/L/Eにkextを置いてmacOSでロードしつつ、 Installer/Updater/Recoveryの時だけESPに置いてCloverでインジェクトする ように設定するには以下のようにします。\nCloverのconfig.plistのSystem Parameters セクションでは、Inject Kextsの設定ができます。ここでは、Cloverがkextをインジェクトしてくれるよう、通常はYESを設定します。\n\u0026lt;key\u0026gt;InjectKexts\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;YES\u0026lt;/string\u0026gt; これをDetectに設定すると、\n\u0026lt;key\u0026gt;InjectKexts\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Detect\u0026lt;/string\u0026gt; Cloverは/L/Eにあるkextを調べて、\nFakeSMCが/L/EにあればCloverはkextをインジェクトしない FakeSMCが/L/Eに無ければCloverはkextをインジェクトする という動作をします。なので、macOSの/L/Eと、CloverのEFI/Clover/kexts/Otherの両方にkext類を入れておけば、フルサイズのmacOSを起動するときは/L/Eのkextを、Installer/Updater/Recoveryの時はCloverがインジェクトするkextを使えることになります。\n抄訳はここまでです。\n/L/Eにkextを入れる方法 今まではバニラな方法しか説明していませんでした。/L/Eにkextを入れるとするといくつかの手順が必要です。\nまずはHackintosh用のkext類は、当然ながらアップル社の承認を受けていませんので、「署名されていないkextも動く」設定にSIP (System Integrity Protection)を設定する必要があります。これにはconfig.plistで\n\u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x01\u0026lt;/string\u0026gt; と設定します。また、/L/Eに必要なkextをコピーした後で、パーミッションを設定して、キャッシュを作り直す必要があります。ターミナルから行うには、\nsudo cp -R *.kext /Library/Extensions/. sudo chown -R 0:0 /Library/Extensions/*.kext sudo kextcache -i / などとします。*.kextの部分は、追加するkextだけ指定すれば良いです。これで再起動するとキャッシュが再構成されます。\nkextをESPに置く利点と欠点 以上で、/L/Eにkextを置く方法が良いという意見とその実際を紹介しました。kextをESPに置くバニラな方法と比較して、長所短所を検討してみます。\nmacOSの流儀からは外れる macOSの設計では追加のkextは/L/Eに置くべきのようです。Cloverがインジェクトする方法では、メモリー不足になる可能性があるようです。ただ、そのような報告はあまり聞いたことがないので、実際には支障はないのかもしれません。\nまた、/L/Eに置くと、キャッシュに入れる際にkextのエラーチェックをしてくれるそうです。ただこれも、kext開発者でなければあまり恩恵の無い機能のように思います。ちなみに、/L/Eに置くと、そのkextがシステム情報–\u0026gt;ソフトウェア–\u0026gt;拡張機能に現れます。これを使って得られる情報がトラブル対応の参考になるかもしれません。\nESPでは動かないkextもある 一部の kextはESPでは正しく動きません。これらは/L/Eに置かざるを得ません。ただ、そのようなkextは少数で、大体はESPで動きます。\nSIPを有効にできる もともとHackintoshのkextは、macOSの規格外の拡張です。なので署名が無く、/L/Eで有効にするにはSIPで署名の無いkextを許可する設定が必要です。せっかくのSIPの仕組みなので、マルウェア対策としてSIPは有効のまま使いたい気がします。もちろんESPにkextを置くことも同様に危険なことですが、Hackintoshを狙ったマルウェアは少なそうですし、署名のあるkextと、署名の無いkextを、/L/EとESPに分けて管理するのは、セキュリティ対策として有効です。/L/EにHackintoshのkextを入れると、混在してしまいます。\nESPに置くと管理が楽 /L/Eに置くと、パーミッションを設定し、キャッシュを作り直す手間がかかります。ESPへ置くのはコピーするだけなので簡単です。また、上記で説明したInject KextsをDetectにする手法では、/L/EとESPの両方にkextを置かないといけません。この方式ではkextの入れ替えや、アップデートの手間が倍以上になります。/L/Eにkextを簡単に置くためのツールもありますが、手間が増えることには変わりありません。\n以上のことを考えると、このままバニラな方法（ESPに置く方法）を続けても良いように思いました。\n","date":"2019-02-02T22:17:14+09:00","image":"/uploads/2018/08/20170915223211.png","permalink":"/posts/1236/","title":"kextはどこに置けば良いのか"},{"content":"Sonnet社が自社GPUボックス経由で使用できるmacOS互換グラフィックスカード一覧を公開しています。今回、RX 560/590が互換リストに追加されました(2019.1)。Hackintosh用パーツ選択の参考になります。\nSonnetはMacのThunderbolt 3コネクタに接続する外部GPUボックスを開発・製造・販売しています。\nそして、下記のページで、macOSと互換性のあるグラフィックスカードの一覧などの資料を公開しています。\nSonnet Technologies\nSonnetの外部GPUボックスは、AppleのExternal Graphics Development Kitにも採用されているほぼ純正みたいな存在です。またOSからは、Thunderbolt 3はPCIe x4 (PCIeのレーンが4本) と同等に見えます。Thunderbolt 3での接続は、PCIe x4スロットへの接続と同様に扱われます。なので、このリストで互換性があるとされたグラフィックスカードは、HackintoshのPCIeスロットに挿してそのまま動くカードと考えて良いです。\nmacOSで使えるAMD GPU 互換表のPDFファイルは以下から入手できます。\nhttp://www.sonnettech.com/support/downloads/manuals/Compatibility_Graphics_Cards.pdf\n市場に出回っている多数の製品に対して互換性がチェックされているようですので、Hackintosh用グラフィックスカード購入の際は、これで確認しておきましょう。ただし、元々の外部GPUボックスがmacOS High Sierra 10.13.4以降を動作対象としています。なので、このリストは、\n10.13.4以降のmacOSでの互換性 一部は10.14.1以降で互換であること を示しています。その冒頭部分、AMDリファレンス（ファンデーション）バージョンの部分を示します。\n「macOS/Windows」の項目にMの文字があるものがmacOSで互換性のあるカードです。これを見ると、AMD純正製品では、\nRadeon Pro WX 7100 / WX 9100 Radeon RX 560/570/580/590 Radeon RX Vega 56/64 Radeon Vega Frontier Edition（水冷・空冷） が互換カードとされています。ただ、RX 560は、他の項目を見ると10.14.1以降限定かもしれません。\nAMD純正カードに続いて、以下のブランドで販売されているAMD GPUカードの互換性が記されています。\nASUS GIGABYTE HIS Digital MSI POWERCOLOR SAPPHIRE VisionTek XFX これによると、ブランドごとの差は無いようです。GPUチップによってのみ互換・非互換が決定するようです。まとめると以下のようになります。\nRX 470, RX 480, RX 560, RX 570, RX 580, RX 590はどのブランドも互換性あり ただしRX 560はmacOS 10.14.1以降で互換性あり RX Vega 56/64はどのブランドも互換性あり RX 460/550は互換性なし R9 NANO/FURY は互換性なし 2018年末に発売されたRX 590が互換リストに加わりました。RX 580の製造プロセスが微細化されてクロックが上がっただけのモデルらしいので当然かと思います。また、10.14.1になりRX 560が追加されました。RX 560は不具合があるという報告もあったのですが、10.14.1で対策されたのかもしれません。一方でRX 460/550は非互換です。460と560は近いモデルなので、10.14.1以降なら動くような気もしますが、古いモデルなので除外しているのかもしれません。\nNVIDIA GeForce は非互換 macOS 10.14になってからアップル社の認証が下りずにWebドライバを公開できていないNVIDIAのカードは、このリストで非互換となっています。macOS 10.13なら動く気もするのですが、10.14が出る前のリストでも非互換となっていました。ひょっとしたら10.14でNVIDIAを排除するというアップルの方針を予知していたのかもしれません。\n","date":"2019-01-29T12:38:52+09:00","image":"/uploads/2018/04/20180416222802.png","permalink":"/posts/1251/","title":"Sonnetの互換GPUリスト (2019年1月版)"},{"content":"Cloverが起動した直後に、起動ドライブや起動オプションの選択をする画面があります。この画面はカスタマイズ可能で、色々な人が凝った画面を作ってくれています。これらの「テーマ」は以下のサイトなどで配布されています。\nClover EFI bootloader / Themes / [649fa8] /themes\n設定方法 ここから気に入ったテーマのフォルダをダウンロードして、EFI/CLOVER/themes/フォルダの中に入れます。次に、（例えばフォルダの名前がMinimalismの場合）config.plistで\n\u0026lt;key\u0026gt;GUI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Theme\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Minimalism\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; のように設定します。config.plistや起動ドライブを変えて色々実験する時に、それぞれ違ったテーマを設定しておけば、切り替えられたことを確認できて便利です。\nおすすめのテーマ テーマのフォルダの中に、必ずscreenshot.pngというファイルがあります。これがテーマの画面サンプルです。これを見れば大体の雰囲気がわかります。ただテーマには、凝った動きのあるものもあります。それはscreenshot.pngからはわかりません。\n配布されているCloverのテーマは、ゲーミングPC的な派手なものが多い気がします。それも楽しいのですが、起動画面にマッチしたシンプルなテーマが好ましいと思います。ということで、気に入ったシンプルなテーマをいくつか紹介します。\nMinimalism いつも使っているテーマです。シンプルで気に入っています。Cloverの起動ドライブ切り替え画面の後に、macOSがブートされますが、この時に、黒地に白いリンゴマークが出て下にプログレスバーが表示されます。Minimalismテーマは、この起動画面への切り替えが自然なので、違和感が少ないです。\nMinimalism Blue Minimalismの黒い背景に色をつけたようなテーマです。ただ、上記のサイトで配布されているリンゴマークは、下に交差した一対の刀剣が配置されています。派手すぎるので、シンプルなリンゴマークに作り直して使っています。フォルダにある画像ファイルを編集するだけの簡単な作業で可能です。\nオリジナル　改変後\nbootcamp 本物のMacでの起動ドライブ選択画面に近いデザインのテーマもいくつか配布されています。Hackintoshとしての違和感が出なくて良いかと思います。ただ、Macのドライブ選択画面は、一般的な画面でないためか、それほどよくできている感じがしません。細部までチェックするJobsも見落としたのかもしれません。\nBeautyとMetro すっきりとして綺麗なテーマもいくつかあります。下はBeautyというテーマです。\nこちらはご存知、Windowsで不評だったと思われる画面デザインを模したMetroというテーマです。\nMojave macOSの標準デスクトップにぼかしを入れて背景にしたテーマもいくつかあります。macOSへのログイン画面のような感じで違和感がありません。使用しているmacOSに合わせて選んでも良いかと思います。ただ、繰り返しになりますが、この後、黒地に白いリンゴマークとプログレスバーの画面になります。なので順番としては不自然な感じは否めません。\nまた一部のテーマには4kに対応したバージョンがあります。4kディスプレイは起動時には画素密度が高すぎて、小さな表示になってしまいます。それを見越してアイコンや文字を大きくしたバージョンです。MojaveにもMojave4kというバージョンがあります。4kディスプレイでは見やすくて良いです。\nCatalina こちらはCatalina版です。同様に4K対応のCatalina4kもあります。MojaveテーマだとCatalinaのアイコンが出ませんので、Catalinaに移行したら、テーマもこれにしましょう。\nsteampunk ド派手なテーマもたまには良いです。中でもsteampunkはよくできていると思います。歯車のアイコンは動きます。\n","date":"2019-01-27T17:00:26+09:00","image":"/uploads/2017/10/20171031234615.png","permalink":"/posts/98/","title":"Cloverのテーマ"},{"content":"Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Cloverの設定」と「kextを集める」のページをご紹介します。Hackintoshで使うカーネル拡張(kext)ファイルを簡潔に説明しています。\nPage not found\nPage not found\n（ここから抄訳）\nCloverをインストールする Cloverインストーラパッケージを起動します。インストーラの2番目のページで、 インストール先（USBメモリとかSSD/HDD）を選択するよう気をつけます。また、デフォルト設定はイマイチなので、カスタマイズします。（訳注：図は私が用意したスクリーンショットです）\n左下のカスタマイズボタンを押すとカスタムインストールのページが出ます。ここで、以下を選択します。\n「UEFIブート用にインストール」 「ESPにインストール」 Drivers64UEFIの中の設定（訳注：現在バージョンではUEFI Drivers） AptioMemoryFix: VRAM に関する修正を含んだ新版です。より良いメモリ管理をします。 VBoxHfs-64.efi: 入手できれば HFSPlus.efiでも良いです。CloverがHFS+起動ボリュームにアクセスするために必要です。HFS+で起動したいのに、起動オプションに現れないようなら、 EFI -\u0026gt; CLOVER -\u0026gt; drivers64UEFI フォルダにこれが入っていることを確認すると良いです。 ApfsDriverLoader: Didsさんの Cloverビルドもしくはこちらから入手可能です。これはCloverがAPFS起動ボリュームにアクセスするために必要なapfs.efiを、ブロックデバイスのApfsContainerからロードします。もしAptioMemoryFixを使用しているなら、R21以降が必要です。（訳注：現在バージョンでは最新版が入っているので項目を選択するだけです） 以上です。\nもしもFileVaultが不要で、標準的なUEFIインストールをするだけなら、これらが必要なものの全てです。これ以外のものも、Drivers64UEFIセクションに現れます。しかし、選択しなくても良いです。むしろ他の設定と衝突する項目（例えば SMCHelper-64.efi ）すらあります。なのでDrivers64UEFIセクションでの選択は最小限にするのが良いです。\n（訳注：最近のCloverインストーラではFileVault関係のefiはFileVault 2 UEFI Driversという別のセクションに分類されました。FileVaultを使わなければ、多分誰も使わないと思いますが、これは全部除外して良いです。このガイドでは3個のefiしか必要ないと書かれていますが、ハードウェアによってはこれ以外が必須のこともあります。EmuVariableUefiが必要だったり、AptioMemoryFixの代わりにOsxAptioFixDrvが必要だったりします。）\nKextをコピーする Cloverのインストールが終了したら、/Volumes/EFI/EFI/CLOVER/kexts/Otherに移動して「kextを集める」で用意したkextをここにコピーします。 .dSYMファイルは不要です。.kextだけが必要です。\n/Volumes/EFI/EFI/CLOVER/kextsフォルダの中には、Otherフォルダと、10.xxフォルダがあります。この違いは以下です。Cloverがkextをインジェクトしようとするとき、10.xxフォルダのkextは、macOSのバージョンが合致している時だけインジェクトされます。ところがmacOSのバージョンに依存するkextはほとんどありません。また、macOSをアップデートした時にそのバージョン番号のフォルダを用意することを忘れてしまうと、起動できなくなってしまいます。Otherフォルダのkextは、検出されたmacOSバージョン番号とは関係なくインジェクトされます。なのでOtherフォルダを使うことをお勧めします。\n必要なkextはどれ？ VirtualSMC.kextは必須です。これはMacに搭載されているSMC (System Management Controller) チップをエミュレートしてくれます。これによりOSは本当のMacだと思い込みます。これなしではHackintoshできません。\n以下のすべてのkextはGoldfish64さんにより整備されたこちらのサイトで入手可能です。それぞれのkextは更新されると自動的にビルドされます。自分でビルドしたかったら私のLilu And Friendsのスクリプトを使用してください。\nEthernet関係 ​IntelMausiEthernet.kext – これはほとんどのIntel LANチップで動きます。 AppleIntelE1000e.kext – これは古いIntel LAN チップで動きますが、新しいチップではカーネルパニックすることもあります。 ​AtherosE2200Ethernet.kext – これはほとんどのAtheros または Killer のチップで動きます。 ​RealtekRTL8111.kext – これはほとんどのギガビットRealtek LAN チップで動きます。 ​RealtekRTL8100.kext – これは10/100bps Realtek LAN チップで動きます。 USB関係 多分 USBInjectAll.kextが必要です。もし、H370, B360, H310のCoffee Lake system、またはX79/X99/X299を使うなら、XHCI-unsupported.kextも必要になると思います。\n10.11からアップルはUSBコントローラごとに15個のポート数制限をしています。大した問題ではないと思われるかもしれませんが、USB 3ポートは2個（USB 3として1個、USB 2として1個で合計2個）としてカウントされますので、この制限には割と簡単に到達してしまいます。\nSkylake以降では、USB 2とUSB 3はXHCIとしてのみ扱われて、それぞれのUSB 3が2個としてカウントされ、すぐに制限に達します。USB 2をEHCIに割り当てることで改善する方法もあります。これにはRehabManさんの FakePCIID.kext + FakePCIID_XHCIMux.kext を使います。これによりXHCIの負担を軽減します（ただし一部のチップセットでしか機能しません）。\nAudio関係 マザーボードのAudioチップがサポートされたコーデックであるなら、/u/vit9696さんの AppleALC.kext と、これと一緒に使う Lilu.kext が必要です。AppleALCはAppleHDA.kextに動的にパッチ当てし、macOSのオーディオでサポートされていないコーデックを動かす機能があります。スリープ復帰後のオーディオ機能を手助けする機能もあります。\nGraphics関係 GPUのためには、WhateverGreen.kextと、支援kextである Lilu.kextを使うべきです。これは、以前は別々のkextであった、IntelGraphicsFixup, NvidiaGraphicsFixup, CoreDisplayFixup, Shikiの機能を合わせ持っています。\nWiFi と Bluetooth関係 Appleは最低限のWiFiチップしかサポートしていません。そこで、2つのチップセットだけを紹介します。私は、PCIeアダプタに取り付けたBCM94360CDと、BCM94352HMB / BCM94352Z だけを使っています。BCM94360CDはOOBでバニラなままで動きます。BCM94352風味の場合では、 WiFi設定のためにAirportBrcmFixup.kextと Lilu.kextを使い、 さらに、BrcmBluetoothInjector.kext (10.13.6以降の場合) または BrcmPatchRAM2.kext を、 BrcmFirmwareData.kext と一緒に使います。すべてのBrcm* kextsという名前のkextは、RehabManさんの OS-X-BrcmPatchRAM から入手可能です。\nその他 使用するハードウェアに応じて、これ以外のkextも必要になるかもしれません。でもこのガイドは一般的で基礎的な内容を目指したので、あとはGoogleで検索してください。\n","date":"2019-01-26T17:01:20+09:00","image":"/uploads/2019/01/image.png","permalink":"/posts/1224/","title":"CORPNEWTさんのバニラガイド~ Clover設定とkext"},{"content":"ASUSのZ390マザーボードで作ったHackintoshのその後の報告です。\n9900K搭載Z390マザーボードでHackintoshを作る\nシャットダウンが不完全な問題を解決すべく試行錯誤したところで、EmuVariableUefi-64.efiを使うことで解決しました。あまりにも呆気ない結末なのですが、EmuVariableUefi-64.efiがshutdownに関係するのは知りませんでしたし、もしかして困っている人がいるかもしれないので紹介します。\nシャットダウンの症状 症状が出たマザーボードは、Z390チップセット搭載マザーボードのASUS ROG MAXIMUS XI HERO です。macOSのメニューバーから「システム終了…」を選んでシャットダウンしようとすると、そのままの画面で止まってしまいます。Cloverを-vオプションで立ち上げた状態でシャットダウンしようとすると、画面が暗くなった後に、右上に以下のようなメッセージが出ます。\nvm_map_delete: map \u0026lt;ptr\u0026gt; [0x1003c1000...0x1003c2000] nothing at 0x1003c1000 Man Jan 21 21:29:26 2019 hoge.local com.apple.xpc.launchd[1] \u0026lt;Notice\u0026gt; Generating report ... Man Jan 21 21:29:26 2019 hoge.local com.apple.xpc.launchd[1] \u0026lt;Notice\u0026gt; Report generation in 1 seconds. bash: /private/var/install/shutdown_installer_tasks: No such file or directory bash: /private/var/install/deferred_install: No such file or directory Man Jan 21 21:29:26 2019 hoge.local com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system) \u0026lt;Notice\u0026gt; Userspace teardown took: 5032 ms Man Jan 21 21:29:26 2019 hoge.local com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.system) \u0026lt;Notice\u0026gt; Will be calling reboot(2) with flags: 0x0 スリープの時も同様です。-vオプションなしでは、画面が止まってしまい、-vオプションで起動していると、黒くなった画面右上に同じメッセージが出て反応がなくなります。\n後からわかったのですが、このメッセージは異常を示すものではなく、ここで処理が停滞して止まっているだけのようです。実はこのマシンを組み上げた直後は、スリープもシャットダウンも正常に動いていた気がしていました。これも後からわかったのですが、気のせいではなかったようです。\nシャットダウン問題解決 色々な方法を試したのですが、結局は最初に書いた通り、Clover の drivers64UEFI フォルダに、 EmuVariableUefi-64.efi を入れることですんなり解決しました。 EmuVariableUefi-64.efi は、macOSからATXマザーボード上のNVRAMがうまく読めない場合に、NVRAMのふり（エミュレーション）をしてくれるefiドライバーです。\nNVRAMのエミュレーション\nマザーボード上のNVRAMがmacOSから利用できていればEmuVariableUefi-64.efiは不要なのですが、ASUSのこのマザーボードの場合は必要だったようです。NVRAMが機能しない場合は、\nNVIDIAのWeb driverが動かない（Web driverを使用するかどうかをNVRAMに書き込んでいる） 音量などの値が保存されない などの症状が出ることは知っていましたが、スリープ、シャットダウンで固まってしまう現象が起こりうるとは知りませんでした。多分、シャットダウン時にNVRAMに情報を書き込もうとして、それができなくて処理が止まっていたと考えられます。\n実のところ、最初にこのマシンを組んだ時には、EmuVariableUefi-64.efi を入れていてうまく動いていました。その後、試しに外しても動くようなので、マザーボードのNVRAMにアクセスできていると思い込んで、外していました。EmuVariableUefi-64.efi を外してから、シャットダウンに影響が出るまで時間がかかるので、因果関係に気づきにくいです。\nSleep問題 追記：この問題は10.14.4で発生しなくなりました。\nということで、一時は解決したかに思ったのですが、スリープの問題が発生していました。スリープに入って15秒くらいまではキーボード操作などで画面復帰するのですが、それ以降では画面が暗くなったままです。RX 580で発生しているようです。解決策見つかったら報告します。\n(追記) こちらの方法で解決しました。\n9900Kのsleep問題〜原因はiGPUのデバイスID\nSleep/shutdown対策のまとめ スリープ、シャットダウンできない不具合はHackintoshでよくあるトラブルです。ただ、様々なことが原因で発生するので、対策も多岐に渡ります。一般的な解決策、ASUSの類似マザーボード案件を探して見つかった解決策、今回の解決策を列挙しておきます。\nconfig.plistでFixShutdownをtrueにする。一番一般的な解決策です。だいたいこれで解決します。\nconfig.plistでFixShutdown_0004をtrueにする。Cloverのマニュアルにも書かれているASUSマザーボード対策です。古くからの方法なので今は効かないかもしれません。今回も関係ありませんでした。\nCloverの起動オプションで、darkwake=0またはdarkwake=1とする。ASUSマザボの問題が解決したという報告がありましたが、今回は無効でした。\nmacOSのシステム環境設定でPower Napを無効にする。今回は関係ありませんでした。\nBIOS設定で、Advanced / APM Configuration / Power On By PCI-E/PCIをEnabledにする（出荷時設定はDisable)。ASUSマザボの問題が解決したという報告がありましたが、今回は無効でした。\nEmuVariableUefi-64.efiもしくはEmuVariableUefi.efiを入れる（今回のシャットダウン解決策）。\nCloverブートメニューでF11を押してnvramをリセットする。\n/Library/Preferences/com.apple.PowerManagement.*ファイルを消す。これを消してもmacOSが自動作成してくれます。\nsudo rm /Library/Preferences/com.apple.PowerManagement.* スリープからの復帰で画面が暗いままな状況はグラフィックスの問題でした。iGPUのデバイスIDを指定したら治りました。\nいただいたコメントによると、ディスプレイを接続しているカードのコネクタを変えると治ることもあるようです。HDMIではダメだったけどDPにしたらスリープ解決したそうです。\n","date":"2019-01-22T22:55:15+09:00","image":"/uploads/2018/12/cpu.png","permalink":"/posts/1233/","title":"ASUS Z390マザーボードのshutdown/sleep対応"},{"content":"Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Haswellマシンのためのconfig.plistの作り方」のページをご紹介します。\nPage not found\nちなみにこのガイドでは、\nHaswell Skylake Kaby Lake Coffee Lake のconfig.plistの作り方が解説してあります。他のCPUを使う場合はそれを見てください。また、Config.plistの基礎編もご覧ください。\n世代の近いCPUではそれぞれかなりの部分が共通です。Haswellは実際のiMacで採用されていて、歴代CPUの中でも互換性が高いと評判です。なので特殊な設定はありません。\n（ここから抄訳）\n（訳注：元記事ではClover Configuratorのスクリーンショットも多数掲載されていますが、config.plistだけを紹介します。Configuratorの操作は元記事を見てください。）\nACPI CloverのACPIデフォルト設定は、多すぎで、やりすぎなところがあります。そのために問題を引き起こす可能性があります。そこで、できるだけ単純に書き直します。\n\u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Fixes\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixHPET\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixIPIC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixRTC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixShutdown\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixTMR\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change EHC1 to EH01\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUhDMQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUgwMQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change EHC2 to EH02\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUhDMg== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RUgwMg== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change SAT0 to SATA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUMA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUQQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;DropTables\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Signature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;DMAR\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Signature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;MATS\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;key\u0026gt;FixHeaders\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;SSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Generate\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PluginType\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Fixes: Fixesでは以下を指定しました。\nFixShutdown – いくつかのマザーボードでシャットダウンしようとしても再起動してしまう問題を解決します。これをtrueにすると、今度は逆にシャットダウンの問題を引き起こすこともあります。その場合はdisableにします。 このほか、IRQの衝突を解消するなどの指定がしてあります。これらは全てのハードウェアに必要ではないかもしれませんが、適用しても大きな害はありません。 Patches: Patchesセクションでは、DSDTのパーツをCloverにより動的に改名します。本物のMacを使っているわけではないうえ、macOSは特定のDSDTパーツ名を前提にしていません。そこでmacOSが稼働するように、名前を非破壊的に変更します。ここでは以下の改名をしています。\nEHC1 を EH01に変更 – これによりbuilt-in USB injectorsとの衝突を避けます EHC2 を EH02に変更 – これによりbuilt-in USB injectorsとの衝突を避けます SAT0 を SATAに変更 – 潜在的なSATA 互換性を改善します Drop Tables: PatchesセクションではDSDTに軽い変更を施します。SSDTはDSDTの一部分を置き換えるものです。Drop Tablesは、特定のSSDTテーブルを起動時に無視するよう指定します。先に述べたように、MacとATXマザーボードは異なるので、macOSが問題を起こすのです。ここでは以下の2個を追加しています。\nDMAR – これはVt-dに関する問題を防止します。Vt-dは仮想マシンのためのPCIパススルーで、Hackintoshではほぼ全く機能しません。 MATS – High Sierra以降で、このテーブルが読み込まれると印刷不可能なキャラクタによりカーネルパニックする可能性があります。 FixHeadersとSSDT: ここでは以下の指定をします。\nFixHeaders – MATSテーブルをドロップすることに加えて念の為に設定します。 これをtrueにするとCloverは印刷不可能なキャラクタによるカーネルパニックを防止します。 PluginType – X86PlatformPlugin をロードするためにいくつかのDSDTデータをインジェクトします。これにより、ネイティブなCPU電力制御を実現する手助けになります。この設定はHaswell以降のCPUでのみ機能します。 Boot ここではあまり重要な項目はありません。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;keepsyms=1 dart=0 debug=0x100 shikigva=40 -v\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;DefaultVolume\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;LastBootedVolume\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Timeout\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;5\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; Arguments: いくつかの起動オプションを追加しました。\n-v – verboseモードになり、Apple logoとプログレスバーの裏側に表示されるメッセージが見えるようになります。Hackintoshする人に貴重な情報です。 dart=0 – Vt-d問題に対するもう一つの対策です。なくても良いです。 debug=0x100 – カーネルパニック時の再起動を防止します。運が良ければカーネルパニックに至った原因を発見できるかもしれません。 keepsyms=1 – これはdebug=0x100と一緒に設定し、macOSがカーネルパニック画面にシンボルも表示するよう設定します。これでカーネルパニックの原因追求の手助けになるかもしれません。 shikigva=40 – これはiGPU専用の設定です。Shiki関係の設定を行います。これにより以下のことが可能になります。 8 – AddExecutableWhitelist – whitelistがパッチされる 32 – ReplaceBoardID – AppleGVAで使うboard-idが別の値に置き換えられる DefaultBootVolume と Timeout: DefaultBootVolume – NVRAMが次に起動するドライブを覚えておくために使用します。 Timeout – DefaultBootVolumeで起動するまでの待ち時間の秒数です。負の値にするとタイムアウトしません。0にするとGUI画面をスキップします。 Boot Graphics 特に設定することはありません。\nCpu ここも特に設定することはありません。\nDevices WhateverGreenのための設定と音声の基本的な設定をします。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;ResetHDA\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AwAiDQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;USB\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixOwnership\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Fake ID（上のconfig.plistからは削除済み）: このセクションは空白で良いです。昔は、HD4400のようなほぼサポートされているiGPUをサポートされたiGPUに見せかけるためにこの機能を使っていました。でも、今は、そのような目的には、よりクリーンなPropertiesセクションを使います。\nAudio: ここではaudioにinject Layout 1を指定します。これは皆さんが使っているマザーボードのコーデックで動く値ではないかもしれません。その場合は、AppleALCのSupported Codec Pageで番号を調べてください。\nここではさらにResetHDAを有効にしています。これはmacOSを再起動した後に、コーデックをニュートラルに戻してくれます。別のOSを起動してmacOSに戻ってきたときに発生する問題を解決します。\nUSB: このセクションでは、FixOwnershipを指定します。 これで、-vオプションで表示されるEnabling Legacy Matchingメッセージの真ん中あたりで止まってしまう問題を解決します。この問題は、HCI Hand OffをBIOSでセットしても解決します。\nProperties: このセクションの設定にはHeadkazeさんの Intel Framebuffer Patching Guideを参考にしました。そして、 ig-platform-idというプロパティを一つだけ記述しました。ここでは16進数の値の順番を入れ替えています。つまりig-plat が 0xAABBCCDDの場合、この記述でこれを0xDDCCBBAAにします。\nここで使う二つのig-platform-idは以下です。実態に合わせていずれかを使用します。\n0x0D220003 – これはiGPUがディスプレイを使用する場合に使われます。 16進数を入れ替えると0300220Dになります。 入れ替えたバージョンをBase 64で表すとAwAiDQ== になります。 0x04120004 – これはiGPUが計算タスクにだけ使用される場合（表示には使われない場合）に使われます。 16進数を入れ替えると04001204 になります。 入れ替えたバージョンをBase 64で表すとBAASBA== になります。 このほか、2つのプロパティを追加しました。framebuffer-patch-enable と framebuffer-stolenmemです。前者はWhateverGreen.kext経由でのパッチ当てを有効にし、後者は最小流用メモリを19MBにします。\n(訳注：framebuffer-patch-enable と framebuffer-stolenmemは、本サイトのconfig.plistにも書かれていないので、古い情報が残っている可能性があります。特に指定しなくても良いようです。一方、ig-platform-idは有用です。これを指定したら画面の乱れがなくなりました。)\nHD 4400への対応 HD 4400をiGPUに搭載しているHaswellでは、以下のdevice-idの差し替えが必要です。HD 4400はmacOSではサポートされていないからです。\nこのdevice-idの差し替えには、上のig-platform-idの16進数入れ替えに類似した手順で行います。でも今回は最初の4桁だけの違いです。device-idは8桁の16進数なのですが、最初の4桁がデバイスIDで後半の4桁が製造社IDです。後半はどちらもインテル社なので同じだからです。そこで、デバイスIDが0xAABB0000であるものを 0xBBAA0000のように入れ替えれば良いのです。後半の4桁は変更する必要がありません。\n(訳注：最後の4桁の8086の部分は製造社IDで、インテルを示します。歴史的に有名な16bit CPUの8086を表しています。その前の4桁がデバイスIDです。1番違いの異なるデバイスであることを示しています。)\ndevice-idを偽装するための値は次のようになります。この値をdevice-idの項目に書いておけば、HD 4600が使えるようになります。\n0x04120000 – これはmacOSでサポートされていないHD 4400デバイスIDです。 12040000 最初の2桁を入れ替えます。 EgQAAA== そのbase 64です。 以上を基にしたPropertiesの設定です。先に説明したように、 ig-platform-id は個別の用法に合わせてください。\n\u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; EgQAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AwAiDQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Disable Drivers ここでは特に設定することはありません。\nGui \u0026lt;key\u0026gt;GUI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Scan\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Entries\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Tool\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Scan: Scan settingsを変更します。この設定でブート出来ないエントリーを除外します。\nHide Volumes: 起動時に表示したくないボリュームを書いておきます。今回は何も指定しませんでした。以下が現れて困るようでしたら追加しておきます。\nPreboot VM 名前以外にUUIDもつかえます。これを知るには、以下のようにします。diskXsYのXとYは実際のボリューム番号にします。\ndiskutil info diskXsY | grep -i \u0026#34;Partition UUID\u0026#34; | rev | cut -d\u0026#39; \u0026#39; -f 1 | rev Theme: 新しいテーマをテストしたかったら (lover-next-blackがおすすめ)、 /Volumes/EFI/EFI/CLOVER/themes ディレクトリに置いて、Themeフィールドに名前を書いておけば良いです。\nGraphics 昔は、iGPUをここで設定していましたが、DeviceセクションのPropertiesですでに設定しましたので、ここでは何もする必要はありません。Cloverが、インテルのiGPUを検出すると、config.plistにGraphicsセクションが無くても、自動的にIntel Injectionを有効にします。もしインテルiGPUを無効にしたい場合は、下のように明示的に書くことで無効にできます。\n\u0026lt;key\u0026gt;Graphics\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; Kernel And Kext Patches \u0026lt;key\u0026gt;KernelAndKextPatches\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;KernelPm\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g710////EA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.12.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g710////Gw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (RehabMan)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g32IDw+DpwQAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.13.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g32ID5CQkJCQkA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (PMHeart)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPD4MDBQAA \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.14.0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPkJCQkJCQ \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (Ricky)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPD4OPBAAA \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.14.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPkJCQkJCQ \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;External Icons Patch\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RXh0ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SW50ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; このセクションでは、いくつかの設定とkextパッチを行なっています。Clover Configuratorを使う場合は、以下の項目にチェックを入れます。\nApple RTC – これにより再起動でBIOSがリセットされてしまう現象を防止します。 KernelPM – これにより、MSR 0xe2に書き込みをしてしまうことを防ぎ、ブート時のカーネルパニックを防止します。 KextsToPatch: ここでは4個の異なるkextパッチを設定しています。そのうち3個はUSBポート数制限に関するものです。1個はオレンジアイコン問題への対処です。これは内部ドライブがホットプラグ可能と判断されてオレンジ色のアイコンの外部ドライブとして現れてしまう問題です。\nUSBポート数制限のパッチにはMatchOS値が設定されています。実際に使用するOSバージョンのものだけを残しておいて、それ以外は削除して良いです。\nRtVariables と SMBIOS \u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BooterConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x28\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x3E7\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;MLB\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02532300QXG2Y7AD\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ROM\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;UseMacAddr0\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02532300QXG2Y7AD\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac15,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02Q6FYUFY10\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C495EE18-C8EA-4100-8CAD-3099AC27772F\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; SMBIOS情報の設定に関して私は、acidantheraの macserial アプリケーションを使っています。私は、同様なpythonスクリプトを書きました。これはconfig.plistに自動保存します。多くの項目は空白であってもCloverが自動的に埋めてくれます。これは、書き込むべき値にアップデートが必要になった時に自動的に書き換えてくれるということを意味します。\nこのHaswellの例では、互換性のためにiMac15,1 のSMBIOSを使いました。細かい機種割り当ては、次のようにすれば良いです。\niGPUを使うHaswellマシンならiMac14,1を使う dGPUを使うHaswellマシンならiMac14,2を使う Haswell RefreshマシンならiMac15,1を使う macserialアプリケーションでSMBIOS情報を取得するために、これを-aオプションで起動します。これによりシリアル番号とボードシリアル番号を生成します。またgrepコマンドで検索するSMBIOSタイプを制約できます。 iMac15,1の例では、次のようにmacserialアプリケーションを起動します。\nmacserial -a | grep -i iMac15,1 これにより以下の結果を得られます。\niMac15,1 | C02NFZZYFY10 | C02438207QXG2Y7FB iMac15,1 | C02P32YJFY10 | C02502303GUG2Y78C iMac15,1 | C02P2VZ7FY10 | C02501306QXG2Y7AD iMac15,1 | C02NM0EDFY10 | C02444701CDG2Y71H iMac15,1 | C02NVHZCFY10 | C02451303CDG2Y7JA iMac15,1 | C02QLRZ4FY10 | C02543300GUG2Y7JC iMac15,1 | C02QJ0UPFY10 | C02541902GUG2Y7JA iMac15,1 | C02QG0NGFY10 | C02539700J9G2Y71M iMac15,1 | C02N3XYEFY10 | C02429104J9G2Y7UE iMac15,1 | C02QW0M3FY10 | C02552700GUG2Y7JA 順番は、以下です。\nProduct | Serial | Board Serial (MLB) iMac15,1の部分はSMBIOS -\u0026gt; Product Nameにコピーします。 Serialの部分はSMBIOS -\u0026gt; Serial Numberにコピーします。 Boardの部分はSMBIOS -\u0026gt; Board Serial Number と Rt Variables -\u0026gt; MLBにコピーします。 SmUUIDの値はターミナルのuuidgenコマンドで得られます。もしくは私のPlist-Toolスクリプトで自動生成できます。この結果を、SMBIOS -\u0026gt; SmUUIDにコピーします。\nRt Variables -\u0026gt; ROM を UseMacAddr0 に設定しました。これを設定するとオンボードのMACアドレスを流用してくれます。\nBooterConfigは0x28に、CsrActiveConfigは0x3e7に設定しました。これで効果的にSIPを無効にしてくれます。このほか、よく使われる値は以下です。\n0x0 – SIPを完全に有効にする 0x3 – 署名のないkextsの使用と保護されたディレクトリへの書き込みを許可する 0x3e7 – SIPを完全に無効にする System Parameters \u0026lt;key\u0026gt;SystemParameters\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;InjectKexts\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Yes\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;InjectSystemID\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; Inject Kexts: この設定には3種類が可能です。ここではYesを使用しました。\nYes – CloverがEFIのkextを使用するよう指定する。 No – CloverがEFIのkextを使用しないよう指定する。 Detect – FakeSMC.kextがkextキャッシュに存在していない時だけkextを使用するよう、Cloverに指定する。 InjectSystemID: この設定は、ブート時に、SmUUIDをsystem-idに設定するようCloverに指示します。これはiMessageなどに重要です。\nまとめ 以上のconfig.plistを全部まとめたものをこちらで公開しておきます。\n","date":"2019-01-13T12:34:22+09:00","image":"/uploads/2019/01/image.png","permalink":"/posts/1216/","title":"corpnewtさんのバニラガイド~Haswell用config.plist"},{"content":"Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Skylakeマシンのためのconfig.plistの作り方」のページをご紹介します。\nPage not found\nちなみにこのガイドでは、\nHaswell Skylake Kaby Lake Coffee Lake のconfig.plistの作り方が解説してあります。他のCPUを使う場合はそれを見てください。また、Config.plistの基礎編もご覧ください。\n世代の近いCPUではそれぞれかなりの部分が共通です。Skylakeは実際のiMacで採用されているので、互換性が高く特殊な設定はありません。\n（ここから抄訳）\n（訳注：元記事ではClover Configuratorのスクリーンショットも多数掲載されていますが、config.plistだけを紹介します。Configuratorの操作は元記事を見てください。）\nACPI CloverのACPIデフォルト設定は、多すぎで、やりすぎなところがあります。そのために問題を引き起こす可能性があります。そこで、できるだけ単純に書き直します。\n\u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Fixes\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixHPET\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixIPIC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixRTC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixShutdown\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixTMR\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change XHCI to XHC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDSQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDXw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change XHC1 to XHC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDMQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDXw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change SAT0 to SATA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUMA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUQQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;DropTables\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Signature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;DMAR\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Signature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;MATS\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;key\u0026gt;FixHeaders\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;SSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Generate\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PluginType\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Fixes: Fixesでは以下を指定しました。\nFixShutdown – いくつかのマザーボードでシャットダウンしようとしても再起動してしまう問題を解決します。これをtrueにすると、今度は逆にシャットダウンの問題を引き起こすこともあります。その場合はdisableにします。 このほか、IRQの衝突を解消するなどの指定がしてあります。これらは全てのハードウェアに必要ではないかもしれませんが、適用しても大きな害はありません。 Patches: Patchesセクションでは、DSDTのパーツをCloverにより動的に改名します。本物のMacを使っているわけではないうえ、macOSは特定のDSDTパーツ名を前提にしていません。そこでmacOSが稼働するように、名前を非破壊的に変更します。ここでは以下の改名をしています。\nXHCI を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます XHC1 を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます SAT0 を SATAに変更 – 潜在的なSATA 互換性を改善します Drop Tables: PatchesセクションではDSDTに軽い変更を施します。SSDTはDSDTの一部分を置き換えるものです。Drop Tablesは、特定のSSDTテーブルを起動時に無視するよう指定します。先に述べたように、MacとATXマザーボードは異なるので、macOSが問題を起こすのです。ここでは以下の2個を追加しています。\nDMAR – これはVt-dに関する問題を防止します。Vt-dは仮想マシンのためのPCIパススルーで、Hackintoshではほぼ全く機能しません。 MATS – High Sierra以降で、このテーブルが読み込まれると印刷不可能なキャラクタによりカーネルパニックする可能性があります。 FixHeadersとSSDT: ここでは以下の指定をします。\nFixHeaders – MATSテーブルをドロップすることに加えて念の為に設定します。 これをtrueにするとCloverは印刷不可能なキャラクタによるカーネルパニックを防止します。 PluginType – X86PlatformPlugin をロードするためにいくつかのDSDTデータをインジェクトします。これにより、ネイティブなCPU電力制御を実現する手助けになります。この設定はHaswell以降のCPUでのみ機能します。 Boot ここではあまり重要な項目はありません。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;keepsyms=1 dart=0 debug=0x100 shikigva=40 -v\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;DefaultVolume\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;LastBootedVolume\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Timeout\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;5\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; Arguments: いくつかの起動オプションを追加しました。\n-v – verboseモードになり、Apple logoとプログレスバーの裏側に表示されるメッセージが見えるようになります。Hackintoshする人に貴重な情報です。 dart=0 – Vt-d問題に対するもう一つの対策です。なくても良いです。 debug=0x100 – カーネルパニック時の再起動を防止します。運が良ければカーネルパニックに至った原因を発見できるかもしれません。 keepsyms=1 – これはdebug=0x100と一緒に設定し、macOSがカーネルパニック画面にシンボルも表示するよう設定します。これでカーネルパニックの原因追求の手助けになるかもしれません。 shikigva=40 – これはiGPU専用の設定です。Shiki関係の設定を行います。これにより以下のことが可能になります。 8 – AddExecutableWhitelist – whitelistがパッチされる 32 – ReplaceBoardID – AppleGVAで使うboard-idが別の値に置き換えられる DefaultBootVolume と Timeout: DefaultBootVolume – NVRAMが次に起動するドライブを覚えておくために使用します。 Timeout – DefaultBootVolumeで起動するまでの待ち時間の秒数です。負の値にするとタイムアウトしません。0にするとGUI画面をスキップします。 Boot Graphics 特に設定することはありません。\nCpu ここも特に設定することはありません。\nDevices WhateverGreenのための設定と音声の基本的な設定をします。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;ResetHDA\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAASGQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-stolenmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAAwAQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;USB\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixOwnership\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Fake ID（上のconfig.plistからは削除済み）: このセクションは空白で良いです。昔は、HD4400のようなほぼサポートされているiGPUをサポートされたiGPUに見せかけるためにこの機能を使っていました。でも、今は、そのような目的には、よりクリーンなPropertiesセクションを使います。\nAudio: ここではaudioにinject Layout 1を指定します。これは皆さんが使っているマザーボードのコーデックで動く値ではないかもしれません。その場合は、AppleALCのSupported Codec Pageで番号を調べてください。\nここではさらにResetHDAを有効にしています。これはmacOSを再起動した後に、コーデックをニュートラルに戻してくれます。別のOSを起動してmacOSに戻ってきたときに発生する問題を解決します。\nUSB: このセクションでは、FixOwnershipを指定します。 これで、-vオプションで表示されるEnabling Legacy Matchingメッセージの真ん中あたりで止まってしまう問題を解決します。この問題は、HCI Hand OffをBIOSでセットしても解決します。\nProperties: このセクションの設定にはHeadkazeさんの Intel Framebuffer Patching Guideを参考にしました。そして、 ig-platform-idというプロパティを一つだけ記述しました。ここでは16進数の値の順番を入れ替えています。つまりig-plat が 0xAABBCCDDの場合、この記述でこれを0xDDCCBBAAにします。\nここで使う二つのig-platform-idは以下です。実態に合わせていずれかを使用します。\n0x19120000 – これはiGPUがディスプレイを使用する場合に使われます。 16進数を入れ替えると00001219になります。 入れ替えたバージョンをBase 64で表すとAAASGQ== になります。 0x19120001 – これはiGPUが計算タスクにだけ使用される場合（表示には使われない場合）に使われます。 16進数を入れ替えると01001219 になります。 入れ替えたバージョンをBase 64で表すとAQASGQ== になります。 このほか、2つのプロパティを追加しました。framebuffer-patch-enable と framebuffer-stolenmemです。前者はWhateverGreen.kext経由でのパッチ当てを有効にし、後者は最小流用メモリを19MBにします。\nDisable Drivers ここでは特に設定することはありません。\nGui \u0026lt;key\u0026gt;GUI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Scan\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Entries\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Tool\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Scan: Scan settingsを変更します。この設定でブート出来ないエントリーを除外します。\nHide Volumes: 起動時に表示したくないボリュームを書いておきます。今回は何も指定しませんでした。以下が現れて困るようでしたら追加しておきます。\nPreboot VM 名前以外にUUIDもつかえます。これを知るには、以下のようにします。diskXsYのXとYは実際のボリューム番号にします。\ndiskutil info diskXsY | grep -i \u0026#34;Partition UUID\u0026#34; | rev | cut -d\u0026#39; \u0026#39; -f 1 | rev Theme: 新しいテーマをテストしたかったら (lover-next-blackがおすすめ)、 /Volumes/EFI/EFI/CLOVER/themes ディレクトリに置いて、Themeフィールドに名前を書いておけば良いです。\nGraphics 昔は、iGPUをここで設定していましたが、DeviceセクションのPropertiesですでに設定しましたので、ここでは何もする必要はありません。Cloverが、インテルのiGPUを検出すると、config.plistにGraphicsセクションが無くても、自動的にIntel Injectionを有効にします。もしインテルiGPUを無効にしたい場合は、下のように明示的に書くことで無効にできます。\n\u0026lt;key\u0026gt;Graphics\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; Kernel And Kext Patches \u0026lt;key\u0026gt;KernelAndKextPatches\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;KernelPm\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g710////EA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.12.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g710////Gw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (RehabMan)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g32IDw+DpwQAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.13.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g32ID5CQkJCQkA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (PMHeart)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPD4MDBQAA \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.14.0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPkJCQkJCQ \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (Ricky)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPD4OPBAAA \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.14.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPkJCQkJCQ \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;External Icons Patch\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RXh0ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SW50ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; このセクションでは、いくつかの設定とkextパッチを行なっています。Clover Configuratorを使う場合は、以下の項目にチェックを入れます。\nApple RTC – これにより再起動でBIOSがリセットされてしまう現象を防止します。 KernelPM – これにより、MSR 0xe2に書き込みをしてしまうことを防ぎ、ブート時のカーネルパニックを防止します。 KextsToPatch: ここでは4個の異なるkextパッチを設定しています。そのうち3個はUSBポート数制限に関するものです。1個はオレンジアイコン問題への対処です。これは内部ドライブがホットプラグ可能と判断されてオレンジ色のアイコンの外部ドライブとして現れてしまう問題です。\nUSBポート数制限のパッチにはMatchOS値が設定されています。実際に使用するOSバージョンのものだけを残しておいて、それ以外は削除して良いです。\nRtVariables と SMBIOS \u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BooterConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x28\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x3E7\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;MLB\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02634902QXGPF7FB\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ROM\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;UseMacAddr0\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02634902QXGPF7FB\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac17,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02S8DY7GG7L\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;DD574F3E-5774-414A-8FF9-5B0089B09480\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; SMBIOS情報の設定に関して私は、acidantheraの macserial アプリケーションを使っています。私は、同様なpythonスクリプトを書きました。これはconfig.plistに自動保存します。多くの項目は空白であってもCloverが自動的に埋めてくれます。これは、書き込むべき値にアップデートが必要になった時に自動的に書き換えてくれるということを意味します。\nこのCoffee Lakeの例では、互換性のためにiMac17,1 のSMBIOSを使いました。\nmacserialアプリケーションでSMBIOS情報を取得するために、これを-aオプションで起動します。これによりシリアル番号とボードシリアル番号を生成します。またgrepコマンドで検索するSMBIOSタイプを制約できます。 iMac17,1の例では、次のようにmacserialアプリケーションを起動します。\nmacserial -a | grep -i iMac17,1 これにより以下の結果を得られます。\niMac17,1 | C02S8DY7GG7L | C02634902QXGPF7FB iMac17,1 | C02T4WZSGG7L | C02703104GUGPF71M iMac17,1 | C02QQAYPGG7L | C025474014NGPF7FB iMac17,1 | C02SNLZ3GG7L | C02645501CDGPF7AD iMac17,1 | C02QQRY8GG7L | C025474054NGPF71F iMac17,1 | C02QK1ZXGG7L | C02542200GUGPF7JC iMac17,1 | C02SL0YXGG7L | C026436004NGPF7JA iMac17,1 | C02QW0J5GG7L | C02552130QXGPF7JA iMac17,1 | C02RXDZYGG7L | C02626100GUGPF71H iMac17,1 | C02R4MYRGG7L | C02603200GUGPF7JA 順番は、以下です。\nProduct | Serial | Board Serial (MLB) iMac17,1の部分はSMBIOS -\u0026gt; Product Nameにコピーします。 Serialの部分はSMBIOS -\u0026gt; Serial Numberにコピーします。 Boardの部分はSMBIOS -\u0026gt; Board Serial Number と Rt Variables -\u0026gt; MLBにコピーします。 SmUUIDの値はターミナルのuuidgenコマンドで得られます。もしくは私のPlist-Toolスクリプトで自動生成できます。この結果を、SMBIOS -\u0026gt; SmUUIDにコピーします。\nRt Variables -\u0026gt; ROM を UseMacAddr0 に設定しました。これを設定するとオンボードのMACアドレスを流用してくれます。\nBooterConfigは0x28に、CsrActiveConfigは0x3e7に設定しました。これで効果的にSIPを無効にしてくれます。このほか、よく使われる値は以下です。\n0x0 – SIPを完全に有効にする 0x3 – 署名のないkextsの使用と保護されたディレクトリへの書き込みを許可する 0x3e7 – SIPを完全に無効にする System Parameters \u0026lt;key\u0026gt;SystemParameters\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;InjectKexts\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Yes\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;InjectSystemID\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; Inject Kexts: この設定には3種類が可能です。ここではYesを使用しました。\nYes – CloverがEFIのkextを使用するよう指定する。 No – CloverがEFIのkextを使用しないよう指定する。 Detect – FakeSMC.kextがkextキャッシュに存在していない時だけkextを使用するよう、Cloverに指定する。 InjectSystemID: この設定は、ブート時に、SmUUIDをsystem-idに設定するようCloverに指示します。これはiMessageなどに重要です。\nまとめ 以上のconfig.plistを全部まとめたものをこちらで公開しておきます。\n","date":"2019-01-13T11:58:32+09:00","image":"/uploads/2019/01/image.png","permalink":"/posts/1213/","title":"corpnewtさんのバニラガイド~Skylake用config.plist"},{"content":"Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Kaby Lakeマシンのためのconfig.plistの作り方」のページをご紹介します。\nPage not found\nちなみにこのガイドでは、\nHaswell Skylake Kaby Lake Coffee Lake のconfig.plistの作り方が解説してあります。他のCPUを使う場合はそれを見てください。また、Config.plistの基礎編もご覧ください。\n世代の近いCPUではそれぞれかなりの部分が共通です。Kaby Lakeは実際のMacのモバイルモデルで採用されているので、互換性が高く特殊な設定はありません。\n（ここから抄訳）\n（訳注：元記事ではClover Configuratorのスクリーンショットも多数掲載されていますが、config.plistだけを紹介します。Configuratorの操作は元記事を見てください。）\nACPI CloverのACPIデフォルト設定は、多すぎで、やりすぎなところがあります。そのために問題を引き起こす可能性があります。そこで、できるだけ単純に書き直します。\n\u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Fixes\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixHPET\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixIPIC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixRTC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixShutdown\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixTMR\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change XHCI to XHC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDSQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDXw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change XHC1 to XHC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDMQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDXw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change SAT0 to SATA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUMA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUQQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;DropTables\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Signature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;DMAR\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Signature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;MATS\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;key\u0026gt;FixHeaders\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;SSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Generate\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PluginType\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Fixes: Fixesでは以下を指定しました。\nFixShutdown – いくつかのマザーボードでシャットダウンしようとしても再起動してしまう問題を解決します。これをtrueにすると、今度は逆にシャットダウンの問題を引き起こすこともあります。その場合はdisableにします。 このほか、IRQの衝突を解消するなどの指定がしてあります。これらは全てのハードウェアに必要ではないかもしれませんが、適用しても大きな害はありません。 Patches: Patchesセクションでは、DSDTのパーツをCloverにより動的に改名します。本物のMacを使っているわけではないうえ、macOSは特定のDSDTパーツ名を前提にしていません。そこでmacOSが稼働するように、名前を非破壊的に変更します。ここでは以下の改名をしています。\nXHCI を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます XHC1 を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます SAT0 を SATAに変更 – 潜在的なSATA 互換性を改善します Drop Tables: PatchesセクションではDSDTに軽い変更を施します。SSDTはDSDTの一部分を置き換えるものです。Drop Tablesは、特定のSSDTテーブルを起動時に無視するよう指定します。先に述べたように、MacとATXマザーボードは異なるので、macOSが問題を起こすのです。ここでは以下の2個を追加しています。\nDMAR – これはVt-dに関する問題を防止します。Vt-dは仮想マシンのためのPCIパススルーで、Hackintoshではほぼ全く機能しません。 MATS – High Sierra以降で、このテーブルが読み込まれると印刷不可能なキャラクタによりカーネルパニックする可能性があります。 FixHeadersとSSDT: ここでは以下の指定をします。\nFixHeaders – MATSテーブルをドロップすることに加えて念の為に設定します。 これをtrueにするとCloverは印刷不可能なキャラクタによるカーネルパニックを防止します。 PluginType – X86PlatformPlugin をロードするためにいくつかのDSDTデータをインジェクトします。これにより、ネイティブなCPU電力制御を実現する手助けになります。この設定はHaswell以降のCPUでのみ機能します。 Boot ここではあまり重要な項目はありません。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;keepsyms=1 dart=0 debug=0x100 shikigva=40 -v\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;DefaultVolume\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;LastBootedVolume\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Timeout\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;5\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; Arguments: いくつかの起動オプションを追加しました。\n-v – verboseモードになり、Apple logoとプログレスバーの裏側に表示されるメッセージが見えるようになります。Hackintoshする人に貴重な情報です。 dart=0 – Vt-d問題に対するもう一つの対策です。なくても良いです。 debug=0x100 – カーネルパニック時の再起動を防止します。運が良ければカーネルパニックに至った原因を発見できるかもしれません。 keepsyms=1 – これはdebug=0x100と一緒に設定し、macOSがカーネルパニック画面にシンボルも表示するよう設定します。これでカーネルパニックの原因追求の手助けになるかもしれません。 shikigva=40 – これはiGPU専用の設定です。Shiki関係の設定を行います。これにより以下のことが可能になります。 8 – AddExecutableWhitelist – whitelistがパッチされる 32 – ReplaceBoardID – AppleGVAで使うboard-idが別の値に置き換えられる DefaultBootVolume と Timeout: DefaultBootVolume – NVRAMが次に起動するドライブを覚えておくために使用します。 Timeout – DefaultBootVolumeで起動するまでの待ち時間の秒数です。負の値にするとタイムアウトしません。0にするとGUI画面をスキップします。 Boot Graphics 特に設定することはありません。\nCpu ここも特に設定することはありません。\nDevices WhateverGreenのための設定と音声の基本的な設定をします。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;ResetHDA\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAASWQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-stolenmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAAwAQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;USB\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixOwnership\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Fake ID（上のconfig.plistからは削除済み）: このセクションは空白で良いです。昔は、HD4400のようなほぼサポートされているiGPUをサポートされたiGPUに見せかけるためにこの機能を使っていました。でも、今は、そのような目的には、よりクリーンなPropertiesセクションを使います。\nAudio: ここではaudioにinject Layout 1を指定します。これは皆さんが使っているマザーボードのコーデックで動く値ではないかもしれません。その場合は、AppleALCのSupported Codec Pageで番号を調べてください。\nここではさらにResetHDAを有効にしています。これはmacOSを再起動した後に、コーデックをニュートラルに戻してくれます。別のOSを起動してmacOSに戻ってきたときに発生する問題を解決します。\nUSB: このセクションでは、FixOwnershipを指定します。 これで、-vオプションで表示されるEnabling Legacy Matchingメッセージの真ん中あたりで止まってしまう問題を解決します。この問題は、HCI Hand OffをBIOSでセットしても解決します。\nProperties: このセクションの設定にはHeadkazeさんの Intel Framebuffer Patching Guideを参考にしました。そして、 ig-platform-idというプロパティを一つだけ記述しました。ここでは16進数の値の順番を入れ替えています。つまりig-plat が 0xAABBCCDDの場合、この記述でこれを0xDDCCBBAAにします。\nここで使う二つのig-platform-idは以下です。\n0x59120000 – これはiGPUがディスプレイを使用する場合に使われます。 16進数を入れ替えると00001259になります。 入れ替えたバージョンをBase 64で表すとAAASWQ== になります。 0x59120003 – これはiGPUが計算タスクにだけ使用される場合（表示には使われない場合）に使われます。 16進数を入れ替えると03001259 になります。 入れ替えたバージョンをBase 64で表すとAwASWQ== になります。 このほか、2つのプロパティを追加しました。framebuffer-patch-enable と framebuffer-stolenmemです。前者はWhateverGreen.kext経由でのパッチ当てを有効にし、後者は最小流用メモリを19MBにします。\nDisable Drivers ここでは特に設定することはありません。\nGui \u0026lt;key\u0026gt;GUI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Scan\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Entries\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Tool\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Scan: Scan settingsを変更します。この設定でブート出来ないエントリーを除外します。\nHide Volumes: 起動時に表示したくないボリュームを書いておきます。今回は何も指定しませんでした。以下が現れて困るようでしたら追加しておきます。\nPreboot VM 名前以外にUUIDもつかえます。これを知るには、以下のようにします。diskXsYのXとYは実際のボリューム番号にします。\ndiskutil info diskXsY | grep -i \u0026#34;Partition UUID\u0026#34; | rev | cut -d\u0026#39; \u0026#39; -f 1 | rev Theme: 新しいテーマをテストしたかったら (lover-next-blackがおすすめ)、 /Volumes/EFI/EFI/CLOVER/themes ディレクトリに置いて、Themeフィールドに名前を書いておけば良いです。\nGraphics 昔は、iGPUをここで設定していましたが、DeviceセクションのPropertiesですでに設定しましたので、ここでは何もする必要はありません。Cloverが、インテルのiGPUを検出すると、config.plistにGraphicsセクションが無くても、自動的にIntel Injectionを有効にします。もしインテルiGPUを無効にしたい場合は、下のように明示的に書くことで無効にできます。\n\u0026lt;key\u0026gt;Graphics\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; Kernel And Kext Patches \u0026lt;key\u0026gt;KernelAndKextPatches\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;KernelPm\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g710////EA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.12.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g710////Gw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (RehabMan)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g32IDw+DpwQAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.13.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g32ID5CQkJCQkA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (PMHeart)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPD4MDBQAA \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.14.0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPkJCQkJCQ \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (Ricky)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPD4OPBAAA \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.14.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPkJCQkJCQ \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;External Icons Patch\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RXh0ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SW50ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; このセクションでは、いくつかの設定とkextパッチを行なっています。Clover Configuratorを使う場合は、以下の項目にチェックを入れます。\nApple RTC – これにより再起動でBIOSがリセットされてしまう現象を防止します。 KernelPM – これにより、MSR 0xe2に書き込みをしてしまうことを防ぎ、ブート時のカーネルパニックを防止します。 KextsToPatch: ここでは4個の異なるkextパッチを設定しています。そのうち3個はUSBポート数制限に関するものです。1個はオレンジアイコン問題への対処です。これは内部ドライブがホットプラグ可能と判断されてオレンジ色のアイコンの外部ドライブとして現れてしまう問題です。\nUSBポート数制限のパッチにはMatchOS値が設定されています。実際に使用するOSバージョンのものだけを残しておいて、それ以外は削除して良いです。\nRtVariables と SMBIOS \u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BooterConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x28\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x3E7\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;MLB\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02726902CDH69F1M\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ROM\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;UseMacAddr0\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02726902CDH69F1M\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac18,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02TX0VDH7JY\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;91492A73-595C-4D97-A6FC-2B5D3ED1B54D\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; SMBIOS情報の設定に関して私は、acidantheraの macserial アプリケーションを使っています。私は、同様なpythonスクリプトを書きました。これはconfig.plistに自動保存します。多くの項目は空白であってもCloverが自動的に埋めてくれます。これは、書き込むべき値にアップデートが必要になった時に自動的に書き換えてくれるということを意味します。\nこのCoffee Lakeの例では、互換性のためにiMac18,1 のSMBIOSを使いました。Kaby Lakeと互換性の高いSMBIOSは以下の2種類です。\niMac18,1 – これはiGPUを表示に使用するコンピュータで使われます。 iMac18,3 – これはdGPUを表示に使用し、iGPUは計算のみに使用するコンピュータで使われます macserialアプリケーションでSMBIOS情報を取得するために、これを-aオプションで起動します。これによりシリアル番号とボードシリアル番号を生成します。またgrepコマンドで検索するSMBIOSタイプを制約できます。 iMac18,1の例では、次のようにmacserialアプリケーションを起動します。\nmacserial -a | grep -i iMac18,1 これにより以下の結果を得られます。\niMac18,1 | C02T8SZNH7JY | C02707101J9H69F1F iMac18,1 | C02VXBYDH7JY | C02753100GUH69FCB iMac18,1 | C02T7RY6H7JY | C02706310GUH69FA8 iMac18,1 | C02VD07ZH7JY | C02737301J9H69FCB iMac18,1 | C02TQPYPH7JY | C02720802CDH69FAD iMac18,1 | C02VXYYVH7JY | C02753207CDH69FJC iMac18,1 | C02VDBZ0H7JY | C02737700QXH69FA8 iMac18,1 | C02VP0H6H7JY | C02746300CDH69FJA iMac18,1 | C02VL0W9H7JY | C02743303CDH69F8C iMac18,1 | C02V2NYMH7JY | C02728600J9H69FAD 順番は、以下です。\nProduct | Serial | Board Serial (MLB) iMac18,1の部分はSMBIOS -\u0026gt; Product Nameにコピーします。 Serialの部分はSMBIOS -\u0026gt; Serial Numberにコピーします。 Boardの部分はSMBIOS -\u0026gt; Board Serial Number と Rt Variables -\u0026gt; MLBにコピーします。 SmUUIDの値はターミナルのuuidgenコマンドで得られます。もしくは私のPlist-Toolスクリプトで自動生成できます。この結果を、SMBIOS -\u0026gt; SmUUIDにコピーします。\nRt Variables -\u0026gt; ROM を UseMacAddr0 に設定しました。これを設定するとオンボードのMACアドレスを流用してくれます。\nBooterConfigは0x28に、CsrActiveConfigは0x3e7に設定しました。これで効果的にSIPを無効にしてくれます。このほか、よく使われる値は以下です。\n0x0 – SIPを完全に有効にする 0x3 – 署名のないkextsの使用と保護されたディレクトリへの書き込みを許可する 0x3e7 – SIPを完全に無効にする System Parameters \u0026lt;key\u0026gt;SystemParameters\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;InjectKexts\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Yes\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;InjectSystemID\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; Inject Kexts: この設定には3種類が可能です。ここではYesを使用しました。\nYes – CloverがEFIのkextを使用するよう指定する。 No – CloverがEFIのkextを使用しないよう指定する。 Detect – FakeSMC.kextがkextキャッシュに存在していない時だけkextを使用するよう、Cloverに指定する。 InjectSystemID: この設定は、ブート時に、SmUUIDをsystem-idに設定するようCloverに指示します。これはiMessageなどに重要です。\nまとめ 以上のconfig.plistを全部まとめたものをこちらで公開しておきます。\n","date":"2019-01-13T11:31:42+09:00","image":"/uploads/2019/01/image.png","permalink":"/posts/1204/","title":"corpnewtさんのバニラガイド~Kaby Lake用config.plist"},{"content":"Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Coffee Lakeマシンのためのconfig.plistの作り方」のページをご紹介します。\nPage not found\nちなみにこのガイドでは、\nHaswell Skylake Kaby Lake Coffee Lake のconfig.plistの作り方が解説してあります。他のCPUを使う場合はそれを見てください。Config.plistの基礎編もご覧ください。\n世代の近いCPUではそれぞれかなりの部分が共通です。Coffee Lakeは実際のMacでの搭載実績がないため、iGPUを使う部分が少し複雑になっています。iGPUを使わなければほぼKaby Lake以前と同じで良いようです。\n（ここから抄訳）\n（訳注：元記事ではClover Configuratorのスクリーンショットも多数掲載されていますが、config.plistだけを紹介します。Configuratorの操作は元記事を見てください。）\nACPI CloverのACPIデフォルト設定は、多すぎで、やりすぎなところがあります。そのために問題を引き起こす可能性があります。そこで、できるだけ単純に書き直します。\n\u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Fixes\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AddMCHC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixHPET\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixIPIC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixRTC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixShutdown\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixTMR\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change XHCI to XHC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDSQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDXw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change XHC1 to XHC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDMQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WEhDXw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change SAT0 to SATA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUMA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUQQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;DropTables\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Signature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;DMAR\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Signature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;MATS\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;key\u0026gt;FixHeaders\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;SSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Generate\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PluginType\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Fixes: Fixesでは以下を指定しました。\nFixShutdown – いくつかのマザーボードでシャットダウンしようとしても再起動してしまう問題を解決します。これをtrueにすると、今度は逆にシャットダウンの問題を引き起こすこともあります。その場合はdisableにします。 このほか、IRQの衝突を解消するなどの指定がしてあります。これらは全てのハードウェアに必要ではないかもしれませんが、適用しても大きな害はありません。 Patches: Patchesセクションでは、DSDTのパーツをCloverにより動的に改名します。本物のMacを使っているわけではないうえ、macOSは特定のDSDTパーツ名を前提にしていません。そこでmacOSが稼働するように、名前を非破壊的に変更します。ここでは以下の改名をしています。\nXHCI を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます XHC1 を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます SAT0 を SATAに変更 – 潜在的なSATA 互換性を改善します Drop Tables: PatchesセクションではDSDTに軽い変更を施します。SSDTはDSDTの一部分を置き換えるものです。Drop Tablesは、特定のSSDTテーブルを起動時に無視するよう指定します。先に述べたように、MacとATXマザーボードは異なるので、macOSが問題を起こすのです。ここでは以下の2個を追加しています。\nDMAR – これはVt-dに関する問題を防止します。Vt-dは仮想マシンのためのPCIパススルーで、Hackintoshではほぼ全く機能しません。 MATS – High Sierra以降で、このテーブルが読み込まれると印刷不可能なキャラクタによりカーネルパニックする可能性があります。 FixHeadersとSSDT: ここでは以下の指定をします。\nFixHeaders – MATSテーブルをドロップすることに加えて念の為に設定します。 これをtrueにするとCloverは印刷不可能なキャラクタによるカーネルパニックを防止します。 PluginType – X86PlatformPlugin をロードするためにいくつかのDSDTデータをインジェクトします。これにより、ネイティブなCPU電力制御を実現する手助けになります。この設定はHaswell以降のCPUでのみ機能します。 Boot ここではあまり重要な項目はありません。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;keepsyms=1 dart=0 debug=0x100 shikigva=40 -v\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;DefaultVolume\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;LastBootedVolume\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Timeout\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;5\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; Arguments: いくつかの起動オプションを追加しました。\n-v – verboseモードになり、Apple logoとプログレスバーの裏側に表示されるメッセージが見えるようになります。Hackintoshする人に貴重な情報です。 dart=0 – Vt-d問題に対するもう一つの対策です。なくても良いです。 debug=0x100 – カーネルパニック時の再起動を防止します。運が良ければカーネルパニックに至った原因を発見できるかもしれません。 keepsyms=1 – これはdebug=0x100と一緒に設定し、macOSがカーネルパニック画面にシンボルも表示するよう設定します。これでカーネルパニックの原因追求の手助けになるかもしれません。 shikigva=40 – これはiGPU専用の設定です。Shiki関係の設定を行います。これにより以下のことが可能になります。 8 – AddExecutableWhitelist – whitelistがパッチされる 32 – ReplaceBoardID – AppleGVAで使うboard-idが別の値に置き換えられる DefaultBootVolume と Timeout: DefaultBootVolume – NVRAMが次に起動するドライブを覚えておくために使用します。 Timeout – DefaultBootVolumeで起動するまでの待ち時間の秒数です。負の値にするとタイムアウトしません。0にするとGUI画面をスキップします。 Boot Graphics 特に設定することはありません。\nCpu ここも特に設定することはありません。\nDevices WhateverGreenのための設定と音声の基本的な設定をします。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;ResetHDA\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; BwCbPg== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-stolenmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAAwAQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;USB\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixOwnership\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Fake ID（上のconfig.plistからは削除済み）: このセクションは空白で良いです。昔は、HD4400のようなほぼサポートされているiGPUをサポートされたiGPUに見せかけるためにこの機能を使っていました。でも、今は、そのような目的には、よりクリーンなPropertiesセクションを使います。\nAudio: ここではaudioにinject Layout 1を指定します。これは皆さんが使っているマザーボードのコーデックで動く値ではないかもしれません。その場合は、AppleALCのSupported Codec Pageで番号を調べてください。\nここではさらにResetHDAを有効にしています。これはmacOSを再起動した後に、コーデックをニュートラルに戻してくれます。別のOSを起動してmacOSに戻ってきたときに発生する問題を解決します。\nUSB: このセクションでは、FixOwnershipを指定します。 これで、-vオプションで表示されるEnabling Legacy Matchingメッセージの真ん中あたりで止まってしまう問題を解決します。この問題は、HCI Hand OffをBIOSでセットしても解決します。\nProperties: このセクションの設定にはHeadkazeさんの Intel Framebuffer Patching Guideを参考にしました。そして、 ig-platform-idというプロパティを一つだけ記述しました。ここでは16進数の値の順番を入れ替えています。つまりig-plat が 0xAABBCCDDの場合、この記述でこれを0xDDCCBBAAにします。\nここで使う二つのig-platform-idは以下です。\n0x3E9B0007 – これはiGPUがディスプレイを使用する場合に使われます。 16進数を入れ替えると07009B3Eになります。 入れ替えたバージョンをBase 64で表すとBwCbPg== になります。 0x3E920003 – これはiGPUが計算タスクにだけ使用される場合（表示には使われない場合）に使われます。 16進数を入れ替えると0300923E になります。 入れ替えたバージョンをBase 64で表すとAwCSPg== になります。 ここで使った値は、Coffee Lake (第8世代) とCoffee Lake Refresh (第9世代) で使われるインテル UHD グラフィックス 630の値です。macOS 10.12 から 10.13.5では、インテル UHD グラフィックス 630搭載CPUの発売前でしたので、この値はサポートされていません。なので、macOS 10.12 から 10.13.5では、Kaby Lakeのガイドと同じ値 (インテル HD グラフィックス 630の値) にすべきです。\nこのほか、2つのプロパティを追加しました。framebuffer-patch-enable と framebuffer-stolenmemです。前者はWhateverGreen.kext経由でのパッチ当てを有効にし、後者は最小流用メモリを19MBにします。\ni3-8100のUHD 630への対応 i3-8100にもUHD 630が搭載されていますが、8700Kなど、実際のMacに搭載されているCPUとはdevice-idが異なっています。具体的には3e918086 と 3e928086の違いです。そこで、i3-8100のUHD 630を使用するためにはIDの差し替えが必要です。\nこのdevice-idの差し替えには、上のig-platform-idの16進数入れ替えに類似した手順で行います。でも今回は最初の4桁だけの違いです。デバイスIDが0xAABB0000であるものを 0xBBAA0000のように入れ替えれば良いのです。後半の4桁は変更する必要がありません。\n(訳注：最後の4桁の8086の部分は製造社IDで、インテルを示します。歴史的に有名な16bit CPUの8086を表しています。その前の4桁がデバイスIDです。1番違いの異なるデバイスであることを示しています。)\ndevice-idを偽装するための値は次のようになります。この値をdevice-idの項目に書いておけば、8100のUHD 630が問題なく使えるようになります。\n0x3e920000 – これは8700K搭載UHD 630のデバイスIDです。 923e0000 最初の2桁を入れ替えます。 kj4AAA== そのbase 64です。 以上を基にしたPropertiesの設定です。先に説明したように、 ig-platform-id は個別の用法に合わせてください。\n\u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; kj4AAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; BwCbPg== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-stolenmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAAwAQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; ピンク問題 UHD 630 iGPUをHDMIで使用すると画面がピンクぽくなる問題が発生することがあります。私も経験して、いくつかの方法で解決しました。\nまずは、この問題をRedditの投稿で見て、ディスプレイを強制的にRGBモードにすることで解決すると知りました。YCbCrモードだと不具合が出るようです。そのためのスクリプトを作りました。うまく動きますが、本当の解決法とは思えませんでした。以下、手元のマシンで解決した手順を示します。\nIORegのConnector Types そこで、IORegistryExplorerを開いて 検索窓に IGPU (これはACPIのなかの GFX0 となっていることがありますが、Lilu + WhateverGreen が正しく変更してくれているはずです。) とタイプすると次の画面になります。\nIORegの中にIGPUを見つけたら、検索窓をクリアします。これにより、IGPUセクションのすべての情報が見えるようになります。\nこのスクリーンショットでわかるように、いくつかの異なる AppleIntelFramebuffer connectionsが表示されています。私がディスプレイに接続している特定のフレームバッファを探してみます。私の場合、これは、AppleIntelFramebuffer@1でした。これを左のペーンで選択すると、connector-type propertyがわかります。私の場合、これはもともと \u0026lt;00 04 00 00\u0026gt; に設定されていました。このconnector typeは次の値を持つことができます。\n\u0026lt;00 04 00 00\u0026gt; – これはDisplayPort \u0026lt;00 08 00 00\u0026gt; – これはHDMI \u0026lt;04 00 00 00\u0026gt; – これはDigital DVI \u0026lt;02 00 00 00\u0026gt; – これはLVDS (モバイルPC用) \u0026lt;01 00 00 00\u0026gt; – これは単なるダミーのポート これで私の場合、HDMIポートがDisplayPortとして認識されていたことが判明しました。そこでWhateverGreenのパッチ機能を使ってconnector-typeを変更します。\n間違っていたポートはAppleIntelFramebuffer@1でした。これはポート1です。そこでPropertiesでport patchを有効にします。そして、connector typeをHDMIにします。これを実現するために、次のProperties エントリーを使います。\nframebuffer-conX-enable = 01000000 framebuffer-conX-type = 00080000 これをbase 64に変換して、エントリーを追加した結果は以下になります。\n\u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; BwCbPg== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; kj4AAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con1-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-con1-type\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAgAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-stolenmem\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAAwAQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; この設定により、私の環境ではHDMIオーディオも有効になりました。\nDisable Drivers ここでは特に設定することはありません。\nGui \u0026lt;key\u0026gt;GUI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Scan\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Entries\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Tool\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Scan: Scan settingsを変更します。この設定でブート出来ないエントリーを除外します。\nHide Volumes: 起動時に表示したくないボリュームを書いておきます。今回は何も指定しませんでした。以下が現れて困るようでしたら追加しておきます。\nPreboot VM 名前以外にUUIDもつかえます。これを知るには、以下のようにします。diskXsYのXとYは実際のボリューム番号にします。\ndiskutil info diskXsY | grep -i \u0026#34;Partition UUID\u0026#34; | rev | cut -d\u0026#39; \u0026#39; -f 1 | rev Theme: 新しいテーマをテストしたかったら (clover-next-blackがおすすめ)、 /Volumes/EFI/EFI/CLOVER/themes ディレクトリに置いて、Themeフィールドに名前を書いておけば良いです。\nGraphics 昔は、iGPUをここで設定していましたが、DeviceセクションのPropertiesですでに設定しましたので、ここでは何もする必要はありません。Cloverが、インテルのiGPUを検出すると、config.plistにGraphicsセクションが無くても、自動的にIntel Injectionを有効にします。もしインテルiGPUを無効にしたい場合は、下のように明示的に書くことで無効にできます。\n\u0026lt;key\u0026gt;Graphics\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; Kernel And Kext Patches \u0026lt;key\u0026gt;KernelAndKextPatches\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;KernelPm\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g710////EA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.12.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g710////Gw== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (RehabMan)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g32IDw+DpwQAAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.13.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g32ID5CQkJCQkA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (PMHeart)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPD4MDBQAA \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.14.0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPkJCQkJCQ \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Port limit increase (Ricky)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPD4OPBAAA \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;MatchOS\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;10.14.x\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.apple.driver.usb.AppleUSBXHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; g/sPkJCQkJCQ \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;External Icons Patch\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RXh0ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SW50ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; このセクションでは、いくつかの設定とkextパッチを行なっています。Clover Configuratorを使う場合は、以下の項目にチェックを入れます。\nApple RTC – これにより再起動でBIOSがリセットされてしまう現象を防止します。 KernelPM – これにより、MSR 0xe2に書き込みをしてしまうことを防ぎ、ブート時のカーネルパニックを防止します。 KextsToPatch: ここでは4個の異なるkextパッチを設定しています。そのうち3個はUSBポート数制限に関するものです。1個はオレンジアイコン問題への対処です。これは内部ドライブがホットプラグ可能と判断されてオレンジ色のアイコンの外部ドライブとして現れてしまう問題です。\nUSBポート数制限のパッチにはMatchOS値が設定されています。実際に使用するOSバージョンのものだけを残しておいて、それ以外は削除して良いです。\nRtVariables と SMBIOS \u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BooterConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x28\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x3E7\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;MLB\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02726902CDH69F1M\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ROM\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;UseMacAddr0\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02726902CDH69F1M\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac18,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02TX0VDH7JY\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;91492A73-595C-4D97-A6FC-2B5D3ED1B54D\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; SMBIOS情報の設定に関して私は、acidantheraの macserial アプリケーションを使っています。私は、同様なpythonスクリプトを書きました。これはconfig.plistに自動保存します。多くの項目は空白であってもCloverが自動的に埋めてくれます。これは、書き込むべき値にアップデートが必要になった時に自動的に書き換えてくれるということを意味します。\nこのCoffee Lakeの例では、互換性のためにiMac18,1 のSMBIOSを使いました。Coffee Lakeと互換性の高いSMBIOSは以下の2種類です。\niMac18,1 – これはiGPUを表示に使用するコンピュータで使われます。 iMac18,3 – これはdGPUを表示に使用し、iGPUは計算のみに使用するコンピュータで使われます macserialアプリケーションでSMBIOS情報を取得するために、これを-aオプションで起動します。これによりシリアル番号とボードシリアル番号を生成します。またgrepコマンドで検索するSMBIOSタイプを制約できます。 iMac18,1の例では、次のようにmacserialアプリケーションを起動します。\nmacserial -a | grep -i iMac18,1 これにより以下の結果を得られます。\niMac18,1 | C02T8SZNH7JY | C02707101J9H69F1F iMac18,1 | C02VXBYDH7JY | C02753100GUH69FCB iMac18,1 | C02T7RY6H7JY | C02706310GUH69FA8 iMac18,1 | C02VD07ZH7JY | C02737301J9H69FCB iMac18,1 | C02TQPYPH7JY | C02720802CDH69FAD iMac18,1 | C02VXYYVH7JY | C02753207CDH69FJC iMac18,1 | C02VDBZ0H7JY | C02737700QXH69FA8 iMac18,1 | C02VP0H6H7JY | C02746300CDH69FJA iMac18,1 | C02VL0W9H7JY | C02743303CDH69F8C iMac18,1 | C02V2NYMH7JY | C02728600J9H69FAD 順番は、以下です。\nProduct | Serial | Board Serial (MLB) iMac18,1の部分はSMBIOS -\u0026gt; Product Nameにコピーします。 Serialの部分はSMBIOS -\u0026gt; Serial Numberにコピーします。 Boardの部分はSMBIOS -\u0026gt; Board Serial Number と Rt Variables -\u0026gt; MLBにコピーします。 SmUUIDの値はターミナルのuuidgenコマンドで得られます。もしくは私のPlist-Toolスクリプトで自動生成できます。この結果を、SMBIOS -\u0026gt; SmUUIDにコピーします。\nRt Variables -\u0026gt; ROM を UseMacAddr0 に設定しました。これを設定するとオンボードのMACアドレスを流用してくれます。\nBooterConfigは0x28に、CsrActiveConfigは0x3e7に設定しました。これで効果的にSIPを無効にしてくれます。このほか、よく使われる値は以下です。\n0x0 – SIPを完全に有効にする 0x3 – 署名のないkextsの使用と保護されたディレクトリへの書き込みを許可する 0x3e7 – SIPを完全に無効にする System Parameters \u0026lt;key\u0026gt;SystemParameters\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;InjectKexts\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Yes\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;InjectSystemID\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; Inject Kexts: この設定には3種類が可能です。ここではYesを使用しました。\nYes – CloverがEFIのkextを使用するよう指定する。 No – CloverがEFIのkextを使用しないよう指定する。 Detect – FakeSMC.kextがkextキャッシュに存在していない時だけkextを使用するよう、Cloverに指定する。 InjectSystemID: この設定は、ブート時に、SmUUIDをsystem-idに設定するようCloverに指示します。これはiMessageなどに重要です。\nまとめ 以上のconfig.plistを全部まとめたものをこちらで公開しておきます。\n","date":"2019-01-13T00:52:22+09:00","image":"/uploads/2019/01/image.png","permalink":"/posts/962/","title":"corpnewtさんのバニラガイド~Coffee Lake用config.plist"},{"content":"Redditのhackintosh掲示板で丁寧に質問に答えてくれているCorpnewtさんが、hackintoshのためのバニラデスクトップガイドというページを用意してくれています。バニラなインストールのためのガイドとして優れています。今回は「config.plistの基礎」というページをご紹介します。\nPage not found\nまたCorpnewtさんのガイドには、CPUごとのconfig.plistの内容が解説されていて、とても参考になります。以下で紹介しておきました。\ncorpnewtさんのバニラガイド~Haswell用config.plist\ncorpnewtさんのバニラガイド~Skylake用config.plist\ncorpnewtさんのバニラガイド~Kaby Lake用config.plist\ncorpnewtさんのバニラガイド~Coffee Lake用config.plist\n（ここから基礎編の抄訳）\nconfig.plistは、/Volumes/EFI/EFI/CLOVER/config.plist にあります。Hackintosh初心者が苦労するファイルの一つです。\nこれは何か? config.plistはXMLで書かれたpropertyリストです。 XMLはマークアップ言語でHTMLと似ています。\n構造 Cloverは、config.plistに正しいパーツが正しい場所に書かれていることを前提にして参照します。configの順番やスコープはとても大事で、間違った場所に書かれた情報はCloverに伝わりません。\nデータタイプ いくつかのメインのデータタイプがあります。一般的なものを紹介します。注意：ここでは開始タグしか示さない場合があります。実際には終了タグも必要です。\nStrings（文字列） \u0026lt;string\u0026gt;This is a string\u0026lt;/string\u0026gt; Stringsはそのままです。\nIntegers（整数値） \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; 数字そのものです。\nData（base64データ） \u0026lt;data\u0026gt;RXh0ZXJuYWw=\u0026lt;/data\u0026gt; 上のstringsに似ていますが、これは何らかのデータをbase64で表現したものです。この例は、ASCII文字列のデータをbase64で表示したものです。次のターミナル操作でこの例のbase64を元のデータに戻してASCII文字として表示できます。\necho RXh0ZXJuYWw= | python -m base64 -d \u0026amp;\u0026amp; echo この結果、「External」という文字が表示されます。\u0026amp;\u0026amp;を使って文字列が表示された後に改行しています。これで見やすくなっています。\nASCII文字からbase64へはこのようにして変換できます。\necho External | base64 この結果、RXh0ZXJuYWw= が得られます。\n（訳注：4の整数倍の個数になるよう=を足しているようです。またbase64 -Dコマンドでもデコードできるようです。）\nBooleans（論理型） \u0026lt;true/\u0026gt; or \u0026lt;false/\u0026gt; これはboolean値です。\nArrays（配列） \u0026lt;array\u0026gt; \u0026lt;string\u0026gt;Bob\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;Jim\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;Chris\u0026lt;/string\u0026gt; \u0026lt;/array\u0026gt; アイテムの unordered list です。\nDictionaries（辞書） \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Bob\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Age\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;20\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;Knows XML\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; これはdictionaryです。keyとvalueがセットです。keyは文字です。\n例 True/Falseを書き換える 最初の例では、boolean valueをtrueからfalseに書き換えてみます。KextsToPatchエントリーはDisabledがfalseなので機能しています。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;External icons patch\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RXh0ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SW50ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; たくさん記載されていますが、まずはkeyの意味を説明します。\nComment – なんのパッチなのかを示す単なるコメントです Disabled – 逆な感じを受けますが、パッチを無効にするかしないかの指定です。trueだと無効になり、falseだと有効です。 InfoPlistPatch – Cloverに、Info.plistなのか、kextのバイナリーなのか、どちらの方にパッチを当てようとしていることを伝えます。falseなのでバイナリーです Name – パッチを当てようとしているkextの名前です Find – バイナリの中で検索すべきbase64データです Replace – findデータを置き換えるためのデータです（発見できた場合） Cloverは、AppleAHCIPort kextの中の、RXh0ZXJuYWw= (デコードするとExternalという文字です)というデータを探して SW50ZXJuYWw= (デコードするとInternalという文字です)に置き換えます。その結果、(通常はexternalドライブと考えられる）ホットプラグ可能なドライブが、internalドライブとしてデスクトップに表示されます。このパッチは、起動時に自動的に当てられます。そして非破壊です、すなわちAppleAHCIPort kextを書き換えません。\nこのパッチを無効にするには、Disabledキーをfalseからtrueにすれば良いです。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;External icons patch\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; RXh0ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; SW50ZXJuYWw= \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; 簡単でしょ?\nArrayに新しいdictを追加する 以下のようなconfig.plistのconfig.plist -\u0026gt; ACPI -\u0026gt; DSDT -\u0026gt; Patchesに新しいパッチを追加してみます。\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;!DOCTYPE plist PUBLIC \u0026#34;-//Apple//DTD PLIST 1.0//EN\u0026#34; \u0026#34;http://www.apple.com/DTDs/PropertyList-1.0.dtd\u0026#34;\u0026gt; \u0026lt;plist version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Fixes\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixHPET\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixIPIC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixRTC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixTMR\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change OSID to XSID (to avoid match against _OSI XOSI patch)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; T1NJRA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WFNJRA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change _OSI to XOSI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; X09TSQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WE9TSQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; まずはACPIがあり、その下位にDSDTがあることがわかります。DSDTの下に、Fixesがあり、それと並んでPatchesがあります。今はFixesセクションはおいておきます。Patchesだけに注目します。\nまずは、Patchesの下に、開始タグ () があり、2個のdictionariesがあります。上で説明したのに似た内容が書いてあります(Comment, Disabled, Find, Replaceという項目があります)。dictionariesの後に、arrayの終了タグ()があります。ここではと タグの間に新しいdictionaryを追加します。こんなdictionaryです。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change SAT0 to SATA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUMA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUQQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; まずはarrayには順番がありません、どこに入れても良いです。ここでは最後に追加します。すると：\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;!DOCTYPE plist PUBLIC \u0026#34;-//Apple//DTD PLIST 1.0//EN\u0026#34; \u0026#34;http://www.apple.com/DTDs/PropertyList-1.0.dtd\u0026#34;\u0026gt; \u0026lt;plist version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Fixes\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixHPET\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixIPIC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixRTC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;FixTMR\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;Patches\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change OSID to XSID (to avoid match against _OSI XOSI patch)\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; T1NJRA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WFNJRA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change _OSI to XOSI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; X09TSQ== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; WE9TSQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;change SAT0 to SATA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUMA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; U0FUQQ== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; 以上のようになります。\n","date":"2019-01-10T23:43:55+09:00","image":"/uploads/2019/01/image.png","permalink":"/posts/1174/","title":"corpnewtさんのバニラガイド~config.plistの基礎"},{"content":"シングルボードコンピュータLattePanda AlphaにmacOSをインストールした記事を書きました。その続編です。今回は、USB環境を整えました。\nLattePanda AlphaでmacOSを起動する\nUSBポートの名前を調べる LattePanda Alphaには3個のUSB 3 Type-Aコネクタと、1個のUSB 3 Type-Cコネクタがついています。USB 3 Type-Cコネクタは電源供給に使っていますが、こういうタイプの変換器を使ってみたらUSB 3として機能していることが確認できました。\nBIOS設定画面では、USB 3が4個あることになっていました。それぞれをenable/disableできます。\nどうやらType-CのコネクタにはUSB 3が一本あって（Type-Cの本来の規格ではUSB 3は2本可能です）、それがPort1という名前になっているようです。ということは明らかにPort2, 3, 4が3個のType-Aのどれかに相当するはずです。BIOSで一つずつdisableにして、どのコネクタが使えなくなるのか確認しました。その結果、\n上のような名前が割り当てられていることがわかりました。以下、この名前でコネクタを区別していきます。\nmacOSのUSB個数制限 こちらで説明したようにEl Capitan以来のmacOSには、使えるUSBが最大15ポートであるという謎の制限があります。その制限に該当してしまうと、USBコネクタが使えなくなります。回避の方法はいくつかありますが、一番簡単で、副作用がなくて、macOSのアップデートに影響されない方法は、\nUSBInjectAll.kextを使用して config.plistのBoot Argumentsで除外するポートを記述する という方法です。これを行うためには、LattePanda Alphaのどのポート番号が使いたいUSBコネクタに対応しているのかを特定する必要があります。\nLattepanda AlphaのUSB構成 無対策で起動 まずは、USB個数制限に対してなんの対策もせずにmacOSを起動してみました。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。IORegistryExplorer.appはAppleの開発サイトからダウンロードできます。\nSign In - Apple\nここからAppleIDでログインして、Additional Toolsで検索して出てくるツールをダウンロードします。検索結果は複数出てきますが、最新のものをダウンロードすれば良いです。その中にIORegistryExplorer.appがあります。\nIORegistryExplorerが起動したら、xhcで検索します。するとUSBポート一覧が出てきます。15個制限がかかっているので15個しか現れません。HSはHigh Speedの略でUSB 2のポートで、SSはSuper Speedの略でUSB 3のポートです。USRは何か不明ですが、SSよりも優先的に機能するポートのようですので、何か重要なものなのかもしれません。とりあえずここでは無視しました。\nそれぞれのポートをクリックすると右のエリアに詳細が出ます。ここで、port-statusが0の値になっているポートは未使用のポートで、0以外は現在使用中のポートです。\nLattePanda AlphaについているPort1, 2, 3, 4にそれぞれUSB 2.0のデバイス（ここではLogitechの無線キーボード・マウス用USBドングルを使いました）を挿して変化を見ていきます。その結果、\nHS03 USB3 Port2のUSB 2.0 HS05 USB3 Port3のUSB 2.0 HS07 USB3 Port4のUSB 2.0 であることがわかりました。Type-C（つまりPort1）には規格上はUSB 3.0が2本あり、それぞれにUSB 2.0が付属しているはずですが、反応しませんでした。テストにはApple社のMacBook用の純正Type-C –\u0026gt; display, USB, Type-C 変換器を使いました。この変換器の中でUSB 2.0が配線されていないのかもしれませんし、元々LattePandaで配線されていないのかもしれません。またこの変換機にはUSB Type-Aが1個しか付いていないので、もう一つのUSBも存在する可能性はあります。今回はType-Cは電源供給にしか使用するつもりがなかったので、これ以上は調べませんでした。\n無反応のHSポートを除外する LattePanda AlphaのUSBポートにLogitech無線ドングルを挿しても反応しなかったポートは\nHS04 HS05 HS08 HS10 でした。不要な様子ですのでこれらを除外します。こちらの方法を使います。つまりUSBInjectAll.kextを使った上で、config.plistのBootセクションに以下を書きます。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;uia_exclude=HS04;HS05;HS08;HS10\u0026lt;/string\u0026gt; 他に必要なArgumentsがあればスペースで区切って列挙しておけば良いです。また、Cloverの起動画面でOptionを選べば一時的にArgumentsを書き換えられます。一時的な試験の場合は、起動画面で書き換えるのが便利です。この結果、\nこのようになりました。優先的に選択されるHSのポートが減ったので、SSが増えました。結果としてSS04, SS05, SS06が増え、総数は全部で14になりました。15以下ですので、これ以上SSは無いと思われます。この状態では、4個のポートを除外しましたが、3個でも良いようです。\nLattePanda AlphaのUSB構成 HS01, 02, 09は、USBコネクタの接続状態に関わらず常に使用中になっています。内部で使用されているようです。uia_excludeオプションで一つずつ除外して、何が動かなくなるかを確認しました。またSSポートもUSB 3のUSBメモリを挿して、動作を確認しました。その結果、SS01, 02, 03, 04がLattePanda AlphaのUSB 3コネクタに接続していて、SS05, 06は使われている様子はありませんでした。ということで、LattePanda AlphaのUSB構成が以下のようであることがわかりました。\nHS01 システムが使用中（搭載無線チップのBluetooth） HS02 システムが使用中（不明のUSBシリアル。M.2 E-keyソケット用？） HS03 USB3 Port2のUSB 2.0 HS04 未使用? HS05 USB3 Port3のUSB 2.0 HS06 未使用? HS07 USB3 Port4のUSB 2.0 HS08 未使用? HS09 システムが使用中（Arduinoに接続） HS10 未使用? SS01 USB3 Port1 (Type-C) SS02 USB3 Port3 SS03 USB3 Port4 SS04 USB3 Port2 SS05 未使用? SS06 未使用? HS02については確認しませんでしたが、M.2 E-keyにはUSB 2.0が出ていて、Bluetoothチップなどで使用します。なのでおそらくこれはM.2ソケットに接続されていると思います。\n除外するUSBポート 何も除外しないと、最初に示したように、優先度の高い10個のHSと謎の2個のUSRから使用されて、SSは3個しか機能しません。すると、SS04が機能しないのでPort2のUSB 3が使えません。HSを1個以上除外すれば、SS04まで使用できることになります。そこで、\nuia_exclude=HS10;SS05;SS06 をArgumentsに指定して、必要なUSBポートが全て動くようにしました。除外リストにSS05, SS06を含めなくても、15個制限に引っかかって除外されるので同じですが、覚書の意味から記載しました。今後、USBがらみで動作不良になるようでしたら、除外リストを再検討することにします。\n","date":"2019-01-06T14:12:18+09:00","image":"/uploads/2018/12/logo.png","permalink":"/posts/1132/","title":"LattePanda AlphaのUSB"},{"content":"シングルボードコンピュータLattePanda AlphaにmacOSをインストールした記事を書きました。その続編です。今回は、Bluetooth/WiFi環境を整えました。\nLattePanda AlphaでmacOSを起動する\nLattePanda搭載無線モジュール LattePandaには、Intelの無線モジュールが半田付けされています。Model 3165D2Wと書いてあります。これは802.11 ac（2.4 G \u0026amp; 5 G）のWi-Fiに加えて、Bluetooth 4.2をサポートしています。インテルのモジュールなのでmacOSからは全く使用できません。なので、BIOSメニューでDisabledに設定します。\n無線モジュールを追加する WiFi/Bluetooth無しで使う用途もあると思います。Arduinoを搭載している特徴を生かして、組み込み用のシステムを作るなら有線LANだけで使うことも多いと思います。また画面共有などのネットワーク越しで開発がメインなら、マウスやキーボードの利用頻度は少ないのでBluetooth無しでも良いかもしれません。\nIO DATAのUSB-BT40LE とはいえ、せっかくmacOSが動くのですから、macOSを生かせるトラックパッドを接続したいです。それにはBluetoothだけは欲しいところです。簡単に安価にBluetoothを追加するなら、USBアダプタのIO DATAのUSB-BT40LEが良いです。iOSとのcontinuityは難しいですが、通常のキーボード、トラックパッド、サウンドデバイス接続なら問題なく使用できます。\nただ、少ないUSBソケットを一つ占有してしまうのはちょっともったいないかもしれません。LattePanda Alphaには、せっかくM.2 E-keyソケットが付いていて空いているので、これを生かしたいと思います。以下では、ここに追加する無線ユニットを考えてみます。無線モジュールの詳細は、こちらの記事をみてください。\nDW1830 M.2ソケットのモジュールでmacOSと互換性の高い製品に、DW1830があります。$50程度とちょっとお高いのですが、互換性は高いです。WiFiはOOBで動き、Bluetoothもkextを追加すれば動くようです。iOSとの連携も期待できます。\n純正カードアダプタを使う 多少分厚くなっても構わないなら、純正品で使われているBCM943602CSと、それをM.2に変換するカードを使用しても良いかもしれません。こちらの方が互換性が完璧な上に、合計金額も安いです。ただ、ネジ穴が合いませんので、両面テープと結束バンドなどで固定する必要があると思います。\nDW1560 iOSとの連携を諦めれば、DW1560も良いと思います。DW1560のWiFiは安定して動きます。またBluetoothにはIO DATAのUSB-BT40LEと同じく、昔のMacで使われたBCM20703が採用されています。iOSとの連携が無かった時代のチップですのでその機能はありません。頑張ってパッチを当てれば連携機能が動かなくはないようですが、困難な作業です。しかし、通常のキーボード、トラックパッド、サウンドデバイス接続なら問題なく使用できます。今回は、iOS連携は不要と考えたので、これを使ってみました。RehabMan-FakePCIIDと、 RehabMan-BcrmPatchRAMから以下のkextを入手すれば動きました。\nFakePCIID.kext FakePCIID_Broadcom_WiFi.kext BrcmFirmwareData.kext BrcmPatchRAM2.kext DW1560はDW1830と比べると半額くらいです。また技適マークも入っていましたので安心して使えると思います。ただ、LattePandaには2280サイズ用の取り付け穴しかありませんので、ネジで固定できませんでした。ネジの代わりに、100円ショップで売っている強力両面テープで貼ってみましたが、かなり発熱するためか、しばらくすると浮いてきます。プラスチック板で押さえ板のようなものを作って、固定した方が良いかと思いました。\nDW1560はamazon.co.jpでも売られていますが、少し・かなり高いです。\n","date":"2019-01-06T12:14:13+09:00","image":"/uploads/2018/12/logo.png","permalink":"/posts/1130/","title":"LattePanda AlphaのBluetooth/WiFi"},{"content":"現行マザーボードに必ず付いているM.2のソケットについて、Hackintoshに必要な知識をまとめてみました。\nM.2はWiFi/Bluetoothの無線ユニットやSSDなどの拡張カードを取り付けるソケットです。M.2では、拡張カードの形状と端子が規格化されています。昔はNGFF（Next Generation Form Factor）と呼ばれていたので、今でもそう併記されることもあります。えむどっとつーと呼ぶのが一般的で、Mは大文字のようです。これ以前に、mini PCI Express, Mini-SATA, mSATAという形のソケットがありましたが、これを小型化してPCIeのレーン数を増やした後継規格です。少し前のマザーボードにはmPCIe, mSATAのソケットがついていましたが、今はM.2です。例えば、古いIntel NUCではmPCIe, mSATAが付いていますが、現行モデルはM.2です。\nM.2の形と端子 形 サイズが決められています。Wikipediaによると、幅は12、16、22、30mmの4種、長さは16、26、30、38、42、60、80、110mmの8種類だそうです。でも実際に売られている製品は、幅が22mmで、長さが30、42、60、80mmのものが一般的です。それぞれ、2230, 2242, 2260, 2280というような名前がついています。\n端子 端子には、PCIe が最大4レーン、SATA、USB 2.0, USB 3.0, I2C, オーディオなどが出ています。このうち一般に使われているのはPCIe, SATA, USBです。さらに全てが使えるわけではなく、バリエーションがいくつか用意されています。その違いをわかりやすくして、間違って使用されないように、端子に切り欠きが入っています。ソケットの方にも切り欠きに合わせた仕切りが作ってあり、間違ったカードが挿さらないようになっています。\n現在のマザーボードには、主に以下の二種類のソケットがついています。\nE key: 24-31番ピンの場所が切り欠きになっています。PCIeが2レーン、USB 2.0などが使えます。 M key: 59-66番ピンの場所が切り欠きになっています。PCIeが4レーンとSATAが使えます。SATAが使えないものもあります。 一方で、よく見かけるM.2用カードは、以下の四種類です。\nE key: 24-31番ピンの場所が切り欠きになっています。 A-E key: 8-15番ピンと24-31番ピンの場所が切り欠きになっています。 M key: 59-66番ピンの場所が切り欠きになっています。 B-M key: 12-19番ピンと59-66番ピンの場所が切り欠きになっています。 ソケットの方は仕切り板で、カードの方は切り欠きなので、ソケットの仕切り板の位置さえあっていれば、物理的には挿すことができます。なので、\nA-E keyとE keyのカードはE key用ソケットに挿さります。 B-M keyとM keyのカードはM key用ソケットに挿さります。 左がE keyソケットとA-E keyカードの例、右がM keyソケットとB-M keyの例です。どちらも挿さります。ただし挿さっても動作するとは限りません。\nM.2カードの使い道 何にでも使える規格ですが、現在一般的に使われているのが、WiFi/Bluetoothの無線カードと、SSDカードです。無線カードは、E keyソケットに、SSDはM keyソケットに挿して使います。\n無線カード 一般的なM.2用無線カードは、A-E keyもしくはE keyです。どちらもE keyのソケットに刺さります。E keyには2レーンのPCIeと、USB 2.0の端子があります。WiFiのチップはPCIeに接続して動作し、BluetoothのチップはUSB 2.0に接続します。無線カードはそれほど高速ではないので、PCIeは1レーンで十分です。M keyだとUSBが配線されていないので、Bluetoothが使えません。という理由でE keyなのです。\nmacOSで使えるM.2無線カードの種類は、それほど多くないです。こちら\nHackintoshのパーツ選び 【その4：無線編】\nでも紹介しましたが、macOSでOOBで動作するM.2 WiFi/Bluetoothカードは、BCM94360NGです。\nDell DW1830 (BCM943602BAED)はより高速で高価ですが、多少互換性が落ちます。こちらの情報のよると、\nWifiはOOBで動く WiFiのパフォーマンスはFakePCIID Kextで改善できる Bluetoothを動かすためにはkextが必要 だそうです。\n予算が限られているならDell DW1560 (BCM4352)も選択肢になります。DW1830よりは安いです。4個のkextが必要です。詳細はこちらをご覧ください。\n純正無線カード変換器 HackintoshでWiFi/Bluetoothカードを使う場合、Macで使われている純正の無線カード、BCM94360CD BCM943602CS BCM94360CSなどを使うと互換性が高く、そのままで問題なく使用できます。純正無線カードは、特殊なピン構成ですが、PCIeとUSBに接続されています。そこで、E keyのPCIeとUSBに変換するアダプタが売られています。\n最初からE key用に設計されたカードと違い、アダプタを使用すると長くなってしまいます。厚みも増えます。マザーボードによっては、他の部品と干渉して取り付けられない場合もあります。シールド用の金属カバーを外せばなんとかなる場合もあります。余裕があっても取り付けネジ位置が合わない場合もあります。ネジだけの問題なら、両面テープで貼り付ければなんとかなります。\nA-E keyもしくはE keyのM.2用ソケットを延長するアダプターもあります。こういう製品を使えば、小型のインテル製無線カードが入っているソケットから、延長して外に引き出して、macOS純正のBroadcom製カードを取り付けることができると思います。\nM.2用の無線カードは通常はE keyソケットに挿しますが、M keyで無線カードを使うことも可能ではあります。Macで使用されている純正無線カードを、E keyではなく、M keyに変換するアダプターを使えば可能です。ただし、M keyにはUSBは配線されていないので、ケーブルでマザーボード上のUSBコネクタに配線することになります。\nSSD カード M.2 SSDカードは、通常M keyソケットに取り付けます。E keyにもPCIeが2レーン来ているので、速度低下の懸念はあるものの接続可能と思うのですが、そのような製品は無いです。\nM.2 SSDカードには、配線の種類でSATA接続のものとPCIe接続のものがあります。また、データ転送のプロトコル（手順）にAHCIとNVMeのものがあります。NVMeが新しいプロトコルでSSDに特化していて高速です。High Sierraからネイティブにサポートされています。macOSの起動も可能です。\nHackintoshのパーツ選び 【その5：SSD】\nSATAまたはPCIeと、AHCIまたはNVMeで4通りの組み合わせがありますが、現在販売されているのは、\nSATAでAHCIのもの PCIeでNVMeのもの がほとんどです。SATAでNVMeという製品はありません。PCIeでAHCIという製品はNVMeが一般的になる前は一時ありました。中古で出回っているかもしれませんが互換性が心配ですので避けた方が良いと思います。\nSATA SSD SATAで接続する場合はPCIeは不要ですのでPCIeが2レーンになるB keyが最適です。でもM keyのソケットにも挿さるように、M keyも切り欠いてあるB-M keyの製品がほとんどです。なので2箇所切り欠きがあるのはSATAだと考えて良いです。こんな感じです。\nNVMeの方がベンチマークでははるかに高速ですが、使ってみて差を感じる場面はありません。その上、現状ではSATAの方が半額くらいですので、SATA SSDを使っても良いと思います。\nB-M key SATA SSDはM keyも切り欠いてあるので、M keyソケットに挿すことができます。しかし必ず使えるわけではありません。SATA接続も可能なM keyソケットである必要があります。例えばASUSのZ390チップマザーボードであるROG MAXIMUS XIにはM keyソケットが2本ありますが、マニュアルの記述によるとSATAをサポートしているのはそのうちの1本だけです。SATA SSDをM keyソケットに挿す場合は、SATAがサポートされているかどうか確認する必要があります。\nPCIe NVMe SSD 一方でPCIe接続のNVMe SSDは高速データ転送を実現するためにPCIeを4レーン使います。そこでPCIeが4レーンあるM keyの構成で使います。なので切り欠きが一つしかないSSDはPCIe接続のNVMe SSDだと考えて良いです。こんな感じです。現状ではSATAタイプの倍くらいの価格ですが、本来のM.2の速度を得たいのでしたらこちらが良いかと思います。\n","date":"2019-01-02T21:44:50+09:00","image":"/uploads/2019/01/M2SSD.png","permalink":"/posts/1101/","title":"M.2のソケット"},{"content":"最近発売されたシングルボードコンピュータLattePanda Alphaは、Intelの第7世代Core m3-7Y30を搭載しています。MacBook 2017の最下位モデルに搭載されているm3-7Y32のクロック違いバージョンです。公式にはWindowsとLinuxをサポートしていますがmacOSがブートできないはずはありません。インストールの方法を紹介したビデオも複数公開されています。そんなLattePanda Alphaがいよいよ国内で発売になりました。\nこれにmacOSをインストールすると以下が可能になりました。\nスリープとシャットダウン M.2経由SATAタイプSSDの使用 有線LAN Bluetooth（こちらをご覧ください） M.2 WiFiの使用（こちらをご覧ください） HDMI経由のサウンド 搭載されているArduino USB Type A USB Type C （こちらをご覧ください） 試していない機能は以下です。でも多分動くと思います。\nM.2経由のNVMeタイプSSD アナログ音声 LattePanda Alphaの仕様 LattePanda Alphaの特徴は、 m3-7y30プロセッサ搭載ワンボードコンピュータに、サブプロセッサとしてArduinoが搭載されていることです。Arduinoの入出力ピンも基板の縁についています。macOSからArduino IDEでプログラミングして、LEDを点滅させたりできるわけです。仕様を書き出しておきます。\nCPUはIntel 第7世代 Core m3-7y30で1.0-2.6 GHz 2コア/ 4スレッドです。MacBook 2017搭載のm3-7Y32は、クロックが1.1-3.0 GHzである以外は、全く同じCPU仕様です。デバイスIDも同じです。 GPUはIntel HD Graphics 615 900 MHzです。これもm3-7Y32と同一です。Hackintoshとして互換性が高いと思われます。 RAM：LPDDR3-1866 デュアルチャンネルのRAMを8GB搭載しています。MacBookの標準モデルと同じです。 ストレージ（補助記憶装置）の有無により2種類のモデルがあります。無しモデルがAlpha 800, 有りがAlpha 864です。Alpha 864は64GBのeMMC (embedded Multi Media Card: 基板に直接半田付けするSDカードのような規格) を搭載しています。ただしeMMCはmacOSで使用できないそうです。 無線ユニットは、Wi-Fi：802.11 ac（2.4 G \u0026amp; 5 G）とBluetooth 4.2をサポートしています。インテルのモジュールなのでmacOSからは使用できません。半田付なので交換することもできません。 M.2ソケットが基板裏面に2個あります。1つはMキー（PCIe 4x NVMe SSD、SATA SSD用）で、もう1つはEキー（PCIe 2x USB2.0、UART、PCM用）です。Eキーが付いているところが素晴らしいです。ここにmacOS互換の無線ユニットを取り付けられます。Hackintoshのために用意されたソケットのようなものです。 ギガビットイーサネットは多分インテル製Realtek製でmacOSから使用可能です。 USBポートは3 x USB 3.0 TypeA、1 x USB Type C（PD、DP対応　USB3.0） ディスプレイ出力はHDMI。macOSから音声も出せます。 コプロセッサ：Arduino Leonardo搭載。LeonardoはUSBキーボード・マウスのエミュレーションもできるので、既存のmacOSアプリとの連携させるのも面白いと思います。 サイズ：115 × 78 mm 販売店と機種選定 国内ではスイッチサイエンスと秋月電子が販売しています。LattePandaのサイトが紹介するオンラインショッピングページで買うこともできます。AmazonにもLattePandaの代理店が出店しているので、そのうち買えるようになるかと思います。\n上で述べたように、LattePanda Alphaには800と864の2つのモデルがあり、違いは補助記憶装置の有無です。864は64GBのeMMCを搭載しています。eMMCは半田付けSDカードのようなチップなので、SSDより低速でHDD程度の速度です。800と864の価格差は秋月で5,100円、本国でも3,300円くらいするので、差額で小容量M.2 SSDが買えてしまいます。その上、こちらの動画のコメントによるとeMMCはmacOSから使用できないようです。SDカードは専用のシリアルインタフェースを採用しているので、ノートPCのHackintoshでも大抵は動きません。eMMCも同じ理由でmacOSから認識できないのだと思われます。ということでmacOSをインストールするならeMMC無しモデルが適していると思います。LattePanda Alpha 800は秋月で40,600円、本家サイトではACアダプタ・送料込み298ドルです。\n追記：m3-7y30（第7世代CPU）が入手困難なため、次期バージョンからCPUが第8世代のm3-8100yに変更になるようです。m3-8100yは今の所、現行モデルのMacで採用されていないので互換性は未知数です（動く可能性は高いと思います）。グラフィックスはIntel UHD Graphics 615になります。UHD 615は8100Bを搭載したMac mini (2018) などで使用されています。また、新しいCPUのLattePanda Alphaは、型番の最後にsが付き800sとなり、価格も$100値上がりするようです。秋月電子ではまだ古い800を売っています。(2019/4/19)\nmacOSをインストールする ドライブを用意 ドライブ無しのモデルなのでM.2 SSDを調達します。SSDは、NVMeでもSATAでもどちらでも機能します。現状ではSATAの方が安いですし、あまり性能を追求する場面でもないので、安いM.2 SATA SSDを用意しました。2280タイプだとネジ穴がピッタリ合います。\nBIOSの設定 LattePanda Alphaを起動してBIOS設定画面に入ります。だいたいは工場出荷時状態でokです。Intel VT-D Techはデフォルトで有効でしたのでdisableにします。次で説明するESP内容を配布しているサイトでは、HDMIから音を出すにはiDisplay Audioをenableにしなければいけないとありますが、これもデフォルトでそうなっていた気がします。\nESP内容の入手 現行のMacBookに限りなく近い構成ですが、macOSを動かすには色々とパッチを当てないといけないようです。Z390マザボで使ったようなシンプルなconfig.plistでは起動しませんでした。検索すると色々な人がmacOSインストールを試していました。以下のサイトではESPの内容を配布してくれていましたので、ESPの一式をダウンロードしました。\nReleases · novaspirit/macpanda\nインストール用USBメモリ作成 別のmacOSマシンで、App StoreからmacOS Mojaveインストール.appをダウンロードします。この中にあるcreateinstallmediaコマンドを使い、インストール用USBメモリを作成します。これが起動することをmacOSマシンで確認しておきます。\n次に、このUSBのESPに、前述のサイトからダウンロードしたESPの中身をコピーします。中身のコピー先がよくわからない場合は、一旦CloverをESPにインストールして、そのCLOVERディレクトリをダウンロードしたものと入れ替えれば良いです。ダウンロードしたものに入っているCloverは多分最新版では無いので、最新のCloverインストーラを使ってインストールし直しておくのも良いと思います。\nLattePandaでインストール用USBを起動 LattePandaにUSBメモリを接続して、BIOSで起動ドライブをこれに設定して起動します。ESP一式が揃っていますので難なく起動します。ここからM.2 SSDをフォーマットしてmacOSをインストールします。インストール終了したら、USBのESPを使ってSSDのmacOSを起動します。\nM.2 SSDのESPを構成する macOSが起動したM.2 SSDのESPに必要ファイルを入れます。まずはCloverインストーラでCloverをインストールしても良いです。USBのESPからconfig.plistやkext類をM.2 SSDのESPにコピーし、最終的には同じ状態に構成します。LattePandaを再起動して、BIOSでSSDを起動ドライブに設定すれば、macOSが起動します。\nCloverを設定する 入手したconfig.plistには、コメントアウトされている記述も多く、削除してスッキリさせたい気もしました。ただ、色々チューンされた結果のようで、あまり変更しない方が良いようでした。\nただ、SMBIOSは新しく設定した方が良いと感じました。少なくともシリアル番号はオリジナルな値にしておくべきでしょう。上記サイトで配布されている設定では、なぜかMacBook9,1の設定になっています。Core m3-7Y30に類似したCore m3-7Y32はMacBook10,1ですので、その方が何かと互換性が良くなる気がします。CPUの世代の古い機種に設定してある理由は何かあるのかもしれませんが、気持ちよくMacBook10,1に設定しました。シリアル番号やSmUUIDも新しくします。詳しくはこちらをご覧ください。\nSIPを設定するCsrActiveConfigは0x67になっています。0x00にしたかったのですが、起動しませんでした。色々試みたところ0x02が限界のようです。Filesystemへの変更を許可する設定です。起動時にどこかで制限ディレクトリ内容を更新するような動きがあるのかもしれません。\nSystemParametersにはCustomUUIDの指定があります。これもuuidgenコマンドで新たに生成した値に変えておいた方が良いと思います。ただ、この項目はなくてもCloverが生成してくれますし、それに失敗した場合はSmUUIDが使われるようです。SMBIOSの設定をしておけば、これは不要かもしれません。\nまた手元の環境では、「システム終了…」を選んでも、すぐに再起動してしまう不具合がありました。config.plistにFixShutdownをtrueにする設定を追加したところ、これは解決しました。\n\u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Fixes\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FixShutdown\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; 配布されているdrivers64EFIには以下のefiドライバが入っています。\nApfsDriverLoader-64.efi AppleImageCodec-64.efi AppleKeyAggregator-64.efi AppleKeyFeeder-64.efi AppleUITheme-64.efi AptioMemoryFix-64.efi DataHubDxe-64.efi FirmwareVolume-64.efi FSInject-64.efi PartitionDxe-64.efi SMCHelper-64.efi VBoxHfs-64.efi このうち、\nAppleImageCodec-64.efi AppleKeyAggregator-64.efi AppleKeyFeeder-64.efi AppleUITheme-64.efi FirmwareVolume-64.efi はFileVaultのためのドライバですので、FileVaultを使わないなら（多分使わないと思いますので）外しても良いと思います。ちなみにkext類は以下がインストールされています。LANはRealtekだったようです。\nAppleALC.kext AppleHDA.kext FakePCIID_Intel_HDMI_Audio.kext FakePCIID.kext FakeSMC.kext Lilu.kext RealtekRTL8111.kext USBInjectAll.kext WhateverGreen.kext 動作と性能の確認 以上で問題なく起動しました。ESP内容をダウンロードしてきたので楽でした。スリープもしますし、シャットダウンも正常です。LANも動きます。音声はHDMIディスプレイから出ます。CPUを確認するコマンドをターミナルから入力すると以下のようにCore m3-7Y30であることが確認できます。\n$ sysctl -n machdep.cpu.brand_string Intel(R) Core(TM) m3-7Y30 CPU @ 1.00GHz WiFiとBluetoothは動きません。macOSと互換性のある無線モジュールが必要です。詳細はこちらをご覧ください。\nGeekBenchで測定したところ妥当な結果でした。本物のMacBook10,1のスコアよりは多少悪いのですが、クロックが遅い下位CPUなのでこの程度と思います。クロック差程度の違いです。GeekBenchのサイトにはCore m3-7y30搭載のMacBook10,1という謎仕様MacBookのスコアもいくつか上がっています。どう見てもLattePanda AlphaでmacOSを動かしているお仲間の仕業のようです。\nIntel Power GadgetでCPUの動きを確認しました。負荷に応じてクロック数、消費電力、温度が変化するので、電力制御も機能している様子です。アイドル時の消費電力はわずかの1.3wです。IvyBridgeモバイル版Core i3 3217U搭載のNUCですら調整しても2.7wでしたので、その半分の消費電力です。低消費電力macOSサーバとして適していると思います。\nArduinoを使う 開発環境を用意する LattePandaの特徴はArduinoが搭載されていることです。Arduino Leonardoが搭載されたmacOSマシンは他にはありませんので、注目すべきところです。Arduinoは自作愛好者向けのプログラミングが簡単な組み込みマイクロコンピュータです。そのデジタル・アナログ入出力ピンがボードに搭載されていて、センサー、LED、モーター、リレーなどいろいろな部品を接続できます。ArduinoのチップとメインのCore m3はUSBで接続されています。要するにMacBookにUSB接続でArduino Leonardoを接続した状態になっているわけです。ちなみにArduino Leonardoはこんな製品として売られています。少し安めの互換品も多数出回っています。\nArduinoを使うには開発環境Arduino IDEをここからダウンロードします。寄付を募られますが、無料でも使えます。起動したら、まずは「ツール」から「ボード」を選択します。Arduinoには多くのモデルがあって、ポート番号の割り当てや多少命令系統が違います。ここでは搭載されているArduino Leonardoを選択します。\n次に「ツール」「シリアルポート」からシリアルポートを選びます。選択肢の中にArduino Leonardoがありました。内部でUSB接続されていることが確認できます。これを選択します。\nこれであとはプログラム（Arduinoではスケッチと呼んでいます）を書いて、ダウンロードすれば良いです。\nLチカする 開発環境が整ったら、まずは最も簡単なプログラムを書いて動作確認したいところです。プログラミング言語では、”Hello World!”という文字を画面に表示するプログラムがよく使われます。マイクロコンピュータ開発環境では、接続したLEDをチカチカ点滅させるプログラム、略してLチカがHello World!みたいな存在です。Lチカを書いてみましょう。新規スケッチウィンドウを開きます。Processingという開発環境を使ったことのある人なら、馴染みのあるウィンドウです。Processingを真似て作られたので似ています。ちなみにProcessingの裏ではJavaが動いていますが、ArduinoではC++コンパイラが動きます。\n新規ウィンドウにはプログラムの雛形があります。setupとloopという二つの関数があります。setupは起動時・リセット時に1回だけ実行される関数で、loopはその後、無限に繰り返し実行される関数です。setupに初期化関係の処理を書いて、loopに本体を書きます。Lチカを以下のように書きました。\n最初に整数型（しかありませんが）変数としてLEDを宣言して、値を13にしています。Arduinoの入出力ポートの13番を使おうとしています。他の番号でももちろん良いです。ちなみに13番は、大抵のArduinoで、ボード上に搭載したLEDに接続されています。LattePanda Alphaでも電源LEDの隣のLEDに接続されています。なので、LEDを接続しなくてもテストができるので楽です。\nsetupでは、13番ポートを出力モードにしています。この手のマイクロコンピュータは、ピンを有効利用するために、入力にも出力にも切り替えて使えるように設計されています。なので、最初にどちらかに設定しておく必要があるのです。loopでは13番ポートに、最初に電圧を出力し、1000ミリ秒待ち、次に電圧を切り、次にまた1000ミリ秒待つプログラムを書きました。1秒おきに点灯と消灯を繰り返すプログラムで、これでLEDがチカチカします。\nウィンドウの左上にある矢印アイコンをクリックすると、スケッチがコンパイルされて、Arduinoにダウンロードされます。ダウンロード後にArduinoがリセットされて、スケッチが実行されます。LattePanda Alphaの角にある青い電源LEDの隣に赤いLEDがあります。その下にD13と書いてあります。デジタルピンの13番に接続されたLEDという意味です。これが1秒ごとに点滅するはずです。\nArduinoの入出力ポートには、この他、スイッチなどを接続するデジタル入力、アナログ入出力、シリアル接続など様々な機能があります。センサやアクチュエータ、ディスプレイなどを接続することができます。Lチカができればあとは無限の可能性があります。\nUSBデバイスにする Arduino LeonardoはArduinoシリーズの中でも高機能なボードです。USBコントローラをチップに内蔵しているので、USBキーボードやUSBマウスの機能を実現することもできます。ここでは、Arduino LeonardoをUSBマウスとして機能させてみます。次のようなスケッチを用意します。\n最初にMouse.hをインクルードしています。USBマウス機能を使うためのヘッダファイルです。setupではMouse機能を起動させています。loopの中ではmove関数を使って、x, y方向に30画素進ませて、次に逆方向に30画素戻しています。これをコンパイルして動かすと・・・マウスポインタが右下に少しだけ移動し、0.2秒後に戻ってきて、再び0.2秒後に右下に移動します。とっても邪魔なプログラムが完成しました。頑張って0.2秒のうちにスケッチウィンドウに文字カーソルを置いて、無害なプログラムに書き直して（最終的にはLチカに戻すと良いです）、0.2秒のうちに頑張ってコンパイル・ダウンロードアイコンを押しましょう。\nこれは邪魔なだけで何の役にも立たないプログラムでした。でもうまく使えば、例えばArduinoのピンにスイッチをつけて、そのスイッチを押すと、「現在のマウスポインタを中心に300×300画素部分をドラッグして選択してくれる機能」、などが実現できます。多少便利かもしれません。\nポストインストール 以上のように問題なくmacOSが動きました。この後は、インストール後の調整をして、少しずつ快適な環境に設定していけば良いです。\nWiFi/Bluetoothの設定 こちらで紹介しています。\nLattePanda AlphaのBluetooth/WiFi\nUSBの設定 こちらで紹介しています。macOSの15個制限で、USB 3 Type-Aポートの一つが使えません。これを使えるようにするために、明らかに不要なUSBポートを除外する設定をします。\nLattePanda AlphaのUSB\nバッテリー設定を消す 機種をMacBookにしたので当然なのですが、「システム環境設定…」「省エネルギー」の設定で、「電源アダプタ」と「バッテリー」の2つのタブが表示されます。「電源アダプタ」タブがデフォルトで表示されるので、こちらで設定しておけば問題ないのです。でもconfig.plistのSMBIOS設定でバッテリーのタブを消すことができます。以下をご覧ください。\n電池を搭載してないことをOSに知らせる\nLattePanda Alphaの使い道 もともとLattePanda AlphaはWindowsやLinuxが動いてArduinoで制御できるボードとして売っています。Raspberry Piが近いライバルですが、あちらよりはかなり高性能で、しかもWindowsが動くところが売りです。Raspberry PiはLinuxしか動きません。さらには、そこでmacOSが動くのですから、面白いガジェットだと思います。とはいえその面白さが心に響く人はそれほど多くないかもしれません。何が嬉しいのか考えてみました。\n超小型・低消費電力のmacOSコンピュータ。ディスプレイ裏に取り付ければ、iMacみたいなコンピュータが作れます。低消費電力なので常時電源を入れるサーバ向きかもしれません。もしくは、デジタルサイネージのような使い方も良いかもです。近い位置付けのコンピュータにIntel NUCがあります。NUCには標準のSATAソケットがついているモデルもあるので大容量のHDDを接続できます。それができないのでLattePanda Alphaはファイルサーバには向いていないです。一方、最近のNUCはWiFi/Bluetoothの無線ユニットが半田付けで、無線ユニット用のソケットがありません。macOSと互換性の高い純正無線ユニットは使えないと考えて良いです。LattePanda Alphaには純正無線ユニットが変換アダプター経由で接続できるEキータイプのM.2ソケットが搭載されています。本体ボードに無線ユニットが搭載されているのに、別にEキーソケットを用意するというのは変わった設計のような気がします。SSD用のMキーのソケットをもう一つ用意しても良いのにと思います。EキーをつけてくれたのはmacOSに配慮したとしか思えません。 Arduinoを使えるmacOS環境がワンボードで用意できます。もっとも、MacBookにArduino LeonardoをUSB接続すれば、同じことができます。Arduinoが外付けなら、回路を壊しても安価に交換できます。なので、これもどうしてもワンボードで実現したい用途に限定されます。LattePandaのサイトでは、自立走行小型ロボットに搭載する例が紹介されています。高度な画像処理や機械学習をしながら、モータやセンサを駆使したい場合には、軽量、小型に実現できるので向いているかもしれません。 カスタマイズできるUSBキーボード・マウス機能を持ったmacOSマシンとして使えます。上で示したように、マウスやキーボードで行うことはなんでもプログラムで実現できます。センサの結果やネットの状況を、キーボード・マウス経由で反映することが可能です。センサの結果をプログラムで受け取るのが簡単になります。 ウェアラブルなmacOSが実現できます。これもLattePandaのサイトで紹介されています。HMDに接続したり、画像処理を行ったり、センサに接続したりする高性能なコンピュータを、小型、省電力で提供できます。USB Type-Cで電源供給するので、豊富なモバイルバッテリー製品が電源として利用できます。 ということで、万人ウケする製品ではないかもしれません。でも、「ディスプレイとキーボード・トラックパッドと、バッテリーを取り外したMacBook 2017」に相当するコンピュータですので、こういうものが欲しかったという人が必ず居ると思いました。\nつづき 以下もごらんください。\nLattePanda AlphaのBluetooth/WiFi\nLattePanda AlphaのUSB\n","date":"2018-12-25T00:10:29+09:00","image":"/uploads/2018/12/logo.png","permalink":"/posts/1031/","title":"LattePanda AlphaでmacOSを起動する"},{"content":"久々に最新パーツで組んでみたところ、macOSがすんなり動きました。インテルの第9世代CoreプロセッサCoffee Lake-S Refresh搭載のZ390チップセットマザーボードです。\nスロット数で選んだマザーボード 最新パーツでHackintoshを作る上で、マザーボードは選択肢が豊富なパーツです。市販の300シリーズチップセット搭載マザーボードのほとんどでHackintosh可能です。拡張スロット構成、SATA/USB/m.2コネクタ構成、追加機能、色とデザインなど考慮して、各人の目的や好みに合わせて自由に選んで良いです。だいたいどれでもちゃんと動くと良いと思います。特にこだわりがなければ、掲示板やブログでHackintoshに成功したとの報告のあるマザーボードを選んでおけば良いです。今回はASUS ROG MAXIMUS XI HEROを選びました。問題なく動きます。\nASUS ROG MAXIMUS XI HEROを選定した１番の理由はPCIeスロット数が多いことです。多くの人はMacからなくなってしまった拡張性を求めてHackintoshをしていると思います。なのでPCIe空きスロットが多いことは重要です。ATXマザーボードには規格上最大7本のPCIeスロットを搭載できます。たくさんありますが、どうしても必要なスロットを考えると、自由に使える「空きスロット」はだんだん少なくなっていきます。\nまずは、Hackintoshでは高性能で安定しているグラフィックスボード（以下グラボ）を使用することが多いです。一般的なグラボは2スロット占有するので、グラボを1枚挿すと空きは5本になります。\n使いにくいスロットもあります。Z390チップセットにはグラボ2枚挿しできるように、CPU直結PCIeを分割する機能があります。グラボ2枚あれば、NVIDIAではSLI, AMDではCrossFireと呼ばれる機能を使って描画を高速化できます。しかしmacOSではこの機能が使えないので、分割されたPCIeスロットは使いにくいです。分割用スロットを使ってしまうと、グラボへのデータ転送スピードが低下するからです。詳細は以下の記事で説明しました。ということでCPU直結PCIeを分割したPCIeスロットがあったら、それは使わないことにしたいです。とすると、その場合、空きは4本になります。\nZ390 m-ATXマザボのPCIe\nkakaku.comでZ390マザーボードを検索すると、現時点で38製品もあります。選択肢は豊富です。これらの製品のPCIeスロットから、グラボ用のスロット、その隣のスロット、SLI用分割スロットを除外した「空きスロット」を数えてみました。すると以下のようでした。\nGIGABYTE AORUS製品群: 3本 MSI MEG製品群：3本 ASUS ROG MAXIMUS EXTREME/FORMULA/CODE: 2本 ASRock Taichi製品群/Phantom Gaming 9: 3本 ASUS ROG MAXIMUS HERO/ROG STRIX: 4本 ASUS PRIME: 4本 GIGABYTE GAMING X: 5本 ASRock Phantom Gaming 6/4/Pro 4: 4本 ASUS TUF: 5本 GIGABYTE GAMING SLI: 4本 ASRock Extreme 4: 4本 ASUS PRIME Z390-P: 5本 GIGABYTE AORUS ELITE: 4本 MSI MEG GAMING PLUS：4本 GIGABYTE UD: 5本 MSI Z390-A PRO: 4 このリストは、各製品群最上位モデルの価格順に並べてあります。大体は空きスロットが、上で計算したように、4本か5本です。3本とか2本というモデルもリストの上位にあります。つまり空きスロット数は、上位モデルに少なく、下位モデルに多い傾向があります。GIGABYTE, MSI, ASUS, ASRockの上位モデルが属する製品群ブランドが、AORUS, MEG, MAXIMUS, Taichiです。AORUS, MEG, MAXIMUS製品群の最高価格モデルは、かなり高価なのですが、実は空きスロット数が少ないです。一方で、各メーカの廉価版にはCPU直結PCIe分割機能がないので空きスロットが5本あるモデルもあります。ただ、廉価版になるとUSB Type-Cコネクタが無いモデルになり、本物のMacと比較して見劣りがします。\n自作PCの良いところはメーカ製PCに比べて良質なパーツを選べる点だと思います。なので、マザーボードもそこそこ良い製品を選びたいと考えています。過去に安いマザーボードを選んだところ、動作に問題はないのですが、基板が薄くてヘリが曲がっていたこともあります。しっかりとした厚みがあり、重量感のあるマザーボードを選びたいと思います。また上位の製品には、オンボードのスイッチや状態LEDなどがあり色々と便利です。\nという観点からマザーボードを選定し、リストの比較的上位にありながらスロット数が4本あるASUS ROG MAXIMUS XI HEROを選びました。高級感があり、BIOSで設定できる内容も多くて満足できる製品でした。ASUS ROG STRIXも良いと思いましたが、英語や漢字をあしらった模様が施されているのが趣味に合わなかったです。ASUS ROG MAXIMUS XI HEROで一番気に入った機能は、OS不要かつネットワーク経由でBIOSアップデートが行えることです。BIOSメニューからASUSのサーバにアクセスして新しいBIOSをダウンロードしてアップデートできます。\nCPUは9900K CPUは話題のCore i9-9900Kにしました。インテルの第9世代CoreプロセッサCoffee Lake-S Refreshシリーズです。現在も品薄傾向がありますが、以前よりは買いやすくなったようです。8コア16スレッドあるのが楽しみです。\n9900Kの正12面体パッケージは想像していた以上に大きいです。かさばって邪魔です。ちなみにこれほどの性能が日々の作業に必要かというと、全くのオーバースペックです。自動車・カメラ・ピュアオーディオなどのオタクが身の丈に合わない機材を揃えるのと同じです。macOSをブートすることが楽しみなのでそれで良いのです。\nグラフィックスはRX 580 グラフィックスボードはRadeon RX580を使用しました。Mojaveで使う現行製品としてはRX560/570/580/590/Vega56/Vega64しか選択肢はありません。今回はSapphireを使用しました。でも、どこのブランドでも大丈夫です。\nドライブはSSD 以下の作業では、手元に余っていた2.5インチSSDを使ってインストールしています。その後、M.2 SSDに移行しました。将来的には、\n256GB程度のシステム用（root用）M.2 SSD 1TB程度のデータ用（/Users）2.5 inch SSD 4TB程度のTimeMachine用3.5 inch HDD 4TB程度のデータ倉庫用3.5 inch HDD の構成で運用しようと考えているので、Western Digitalの250GB M.2 SSDを購入しました。\nM.2 SSDを取り付けた作業の詳細は以下をご覧ください。\nASUS MAXIMUS XI HEROにM.2 SSD (WD SN750)を取り付ける\nそのほかのパーツ マザーボード搭載のWiFiはインテル製なので動かないです。一方で、マザーボード搭載のBluetoothは、Ericsson製品のようですが、macOSからある程度認識されました。LattePandaの場合のように、kextを用意すれば動くのかもしれません。でもこれらは使わずに純正と同じ無線モジュールを手配しました。今回は、BCM943602CSを使ってみました。入手可能な純正無線モジュールの中では最新製品で安価です。\n電源、CPUクーラは、その辺りに転がっていた余り物を使いました。マザーボードには8pin + 4pinのCPU補助電源コネクタがあるのですが、電源には8pinしかなかったので、4pinは接続していません。OCしないこともあり、それでも大丈夫のようです。当分はケースもなしです。パーツが机の上に並べてあるだけです。メモリー, 2.5インチSSDは、動いているマシンから抜き取って流用しました。なので特に紹介するほどの内容ではありません。\nBIOS設定 macOSを起動させるにはBIOSを設定する必要があります。\nマザーボード (BIOS) 設定\nでも今回使用したASUS ROG MAXIMUS XI HEROではほとんど設定する必要がありませんでした。試してみたら、なんと工場出荷時状態でもmacOSが起動しました。ちなみに、何か設定してしまった後で工場出荷時状態に戻すには、EXIT/Load Optimized Defaultsを選びます。工場出荷時状態で使うのはあまりにも手抜きなので、以下のメニューだけを変更しました。\nBoot/Boot Configuration/Fast Boot [Enabled] –\u0026gt; [Disabled] Advanced/USB Configuration/XHCI Hand-off [Disabled] –\u0026gt; [Enabled] Advanced/USB Configuration/Legacy USB Support [Enabled] –\u0026gt; [Auto] Advanced/Onboard Devices Configuration/Connectivity mode (Wi-Fi \u0026amp; Bluetooth) [Enabled] –\u0026gt; [Disabled] Advanced/CPU Configuration/Intel (VMX) Virtualization Technology [Disabled] –\u0026gt; [Enabled] 1番目のFast Bootはdisabledにした方が良いようです。2, 3番目のUSBに関する設定は効果があるのかどうかよくわかりません。\n4番目のWi-Fi \u0026amp; Bluetoothはマザーボード搭載モジュールのことです。このマザーボードにはインテルの無線モジュールが搭載されているのでmacOSでは動きません。なので、無線モジュールはdisabledにします。これをEnabledのままにしていると、macOSはBluetoothとしてマザーボード搭載モジュールを使用しようとします。そうすると、macOSと互換性のあるBluetoothモジュールを後から取り付けても、認識されません。アップルの開発者向けページで配布されているツールを使えば使用するBluetoothモジュールを変更できますが面倒です。WiFi/Bluetoothはどうせ使えないので、Disabledにしておきましょう。\n5番目のIntel (VMX) Virtualization Technologyは、デフォルトのDisabledのままでもずっと問題ありませんでした。でも仮想マシンのアプリ（具体的にはVirtual Box）を使おうとしたところ、これをEnabledにしておく必要がありました。\n起動用SSDを作る ハードウェアが揃って、BIOS設定が終わったら、いよいよmacOSのインストールを行います。通常のHackintoshインストール手法では、起動用のUSBメモリを作ってmacOSをインストールします。しかし、今回はmacOSが動いているマシンがあるので、それで起動用の2.5インチSSDを作りました。USBメモリを作る場合も、macOSが動いているマシン（以下、親マシンと呼びます）が必要ですので、いっそそれでSSDを作った方が確実だと思います。その親マシンが本物のMacならmacOSが起動することが確認できますし、親マシンがHackintoshならそれに加えてCloverの動作も確認できます。\nStep1: Mojaveをインストール 親マシンに2.5インチSSDを接続したら、Disk Utility.appを使ってAPFSでフォーマットします。2.5インチSSDなのでMojave25SSDという名前にしました。\n次に、App Storeから正規にダウンロードしたMojaveをこのSSDにインストールします。App Storeからダウンロードすると、「macOS Mojaveインストール.app」がアプリケーションフォルダ内に現れます。ダウンロード後に、これが自動的に開きますので、SSDにインストールします。終了後に、この2.5インチSSDからmacOSが起動できることを確認して、ついでに自分のアカウントも作っておきます。作ったアカウントのディレクトリに色々なツールも入れておくと良いです。\nStep2: Cloverをインストール 親マシンに2.5インチSSDを接続したまま、これにCloverをインストールします。親マシンにCloverがインストールされているのであれば、起動ESPの内容をSSDのESPにドラッグ\u0026amp;ドロップでコピーしても良いです。ESPのマウントの方法は、ここなどに書いておきました。\n新規にインストールしたい場合はCloverインストーラを起動して、SSDにインストールします。Cloverインストーラが起動したら、カスタマイズボタンを押してインストールする内容を選択します。まずは、ESPにインストールするチェックボックスを選びます。\nUEFI Driversでは有効にするEFIドライバを選択します。今回は、以下を選択しました。\nVBoxHfs-64.efi SMCHelper-64.efi FSInject-64.efi DataHubDxe-64.efi AptioMemoryFix-64.efi ApfsDriverLoader-64.efi EmuVariableUefi-64.efi ほぼCloverのデフォルトのままです。デフォルトではEmuVariableUefi-64.efiも入れられるのですが、これがなくてもNVRAMがちゃんと動くことを確認したので外しました。EmuVariableUefi-64.efiは必須でした。これが無いとスリープとシャットダウンで固まってしまいます。このことは、以下の記事で書いておきました。\nASUS Z390マザーボードのshutdown/sleep対応\nStep3: kextを入手・インストール 以下のkextの最新版を入手し、親マシンを使って2.5インチSSDにインストールします。\nFakeSMC.kext Lilu.kext WhateverGreen.kext IntelMausiEthernet.kext AppleALC.kext USBInjectAll.kext このうち、最初のFakeSMCは必須です。LiluとWhateverGreenはディスプレイ関係のパッチを当ててくれます。今回使用したRadeon RX580は互換性が高いので無しでも動くかと思います。でも表示が出ないと復旧作業も大変ですので、念のために入れておくべきでしょう。残りの3個は、それぞれLAN, サウンド、USB関連です。LANはあると作業が楽なので欲しいかもしれません。このマザーボードにはIntelのLANチップが搭載されているのでIntelMausiEthernet.kextを入れました。サウンド（AppleALC.kext）とUSB（USBInjectAll.kext）は後回しにしても良いです。\n今回は手元にある別のHackintoshから持ってきました。もし初めてHackintoshを作るのでしたら、ネットで検索して最新版を入手します。kextを管理するのに便利なKext Updater.appを使っても良いです。このアプリケーションのウィンドウで、”Load Single Kext”オプションを使用し、欲しいkextを指定し、ダウンロードします。Kext Updater.appの説明はこちらをご覧ください。\n最後にこれらのkextをESPの中のEFI/CLOVER/kexts/Otherに入れます。ターミナルでEFI/CLOVERにcdして以下のコマンドを入れるとディレクトリがツリー状に表示されます。\npwd;find . | sort | sed \u0026#39;1d;s/^\\.//;s/\\/\\([^/]*\\)$/|--\\1/;s/\\/[^/|]*/| /g\u0026#39; インストールの結果、CLOVER以下のファイルはこのようになります。枝葉の部分は省略しました。\n/Volumes/EFI/EFI/CLOVER |--ACPI | |--WINDOWS | |--patched（中身は空） |--CLOVERX64.efi |--OEM （省略） |--ROM |--config.plist |--doc （省略） |--drivers64UEFI | |--ApfsDriverLoader-64.efi | |--AptioMemoryFix-64.efi | |--DataHubDxe-64.efi | |--EmuVariableUefi-64.efi | |--FSInject-64.efi | |--SMCHelper-64.efi | |--VBoxHfs-64.efi |--kexts | |--10.10 | |--10.11 | |--10.12 | |--10.13 | |--10.14 | |--10.6 | |--10.7 | |--10.8 | |--10.9 | |--Other | | |--AppleALC.kext | | |--FakeSMC.kex | | |--IntelMausiEthernet.kext | | |--Lilu.kext | | |--USBInjectAll.kextt | | |--WhateverGreen.kext |--misc （省略） |--themes （省略） |--tools （省略） Step4: config.plistを作る 次にEFI/CLOVER/config.plistを作ります。こちらにCoffee Lake用のconfig.plistのガイドをご紹介しておきました。これを基にして作っていきます。\ncorpnewtさんのバニラガイド~Coffee Lake用config.plist\nSMBIOSの項目には、固有のシリアル番号を書き込みます。これは、Clover Configuratorを使って機種を設定して作成したSMBIOSをコピーします。詳しい説明は以下をご覧ください。\n正しく機種設定する (SMBIOSの設定)\nただ、最近のCloverでは、SMBIOSのかなりの部分を自動的に作ってくれるようです。ファームウェアバージョンなどを最新にしてくれるようなので、config.plistで指定しない方が良いかもしれません。ということで最近は、\nBoardSerialNumber ProductName SerialNumber SmUUID だけを書くようにしています。この結果、SMBIOS部分は以下のようになりました。xxxxの部分は、Clover Configuratorとuuidgenコマンドで生成してください。\n\u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;xxxxxxxxxxxxx\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Macmini8,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;xxxxxxxxxxxx\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; ProductNameはMacmini8,1にしました。最新版のMacで第8世代CPU Coffee Lakeが搭載されています。第9世代のCoffee Lake-S Refreshは第8世代の改良版ですし、チップセットは同じ300シリーズですので、相性が良いと考えました。本当なら今回と同じ第9世代CPU搭載のiMacがあればそれを選びたいところです。早く新型iMacを出してほしいものです。\n一方、Devicesの中のPropertiesの部分は以下のようにしました。\n追記：10.14.4ではPropertiesの記載は不要になりました。10.14.3以前では必要です。\n\u0026lt;key\u0026gt;Properties\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;PciRoot(0x0)/Pci(0x2,0x0)\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AAPL,ig-platform-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AwCSPg== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;device-id\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; mz4AAA== \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;framebuffer-patch-enable\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AQAAAA== \u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; device-idをzD4AAA==にします。9900KのIntel UHD Graphics 630は、Macmini8,1のUHD 630とは違うデバイスIDを持っています。それでデバイスIDをMacmini8,1のIDに合わせました。これを合わせないと、スリープで問題が出たり、JPEGファイルのクイックルックが動かない不具合が発生します。こちらの記事もご覧ください。\n9900Kのsleep問題〜原因はiGPUのデバイスID\nAAPL,ig-platform-idは、iGPUを計算のために使う設定（表示にはdGPUを使う設定）にしています。iGPUを表示に使う場合は、AwCSPg== になっている現在の設定をBwCbPg==に変更します。\n追記：9900K対応のiMac Early 2019が発売されて、これ専用のmacOS Mojave 10.14.4 (18E2034) が入手可能になりました。なので以下に示すようにSMBIOSも新型iMacに合わせました。\nSMBIOSは、9900K搭載の27インチiMac Early 2019に合わせることにしました。最新のClover Configuratorを使うと新型iMacであるiMac19,1のSMBIOSを生成することができます。まずはClover Configuratorの左のメニューからSMBIOSを選び、モデルのアイコンの下でiMac19,1を選びます。すると以下のように各種値の候補値を出してくれます。\nこの後、左のメニューから、Text Modeを選ぶとSMBIOS部分が表示されます。\nこの結果、SMBIOS部分は以下になります。（シリアル番号、ボードシリアル番号、SmUUIDはこの記事のために生成したサンプルです。実際には違う値を設定してください。）\n\u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BiosReleaseDate\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;02/18/2019\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BiosVendor\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Apple Inc.\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BiosVersion\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;IM191.88Z.F000.B00.1902181222\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Board-ID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Mac-AA95B1DDAB278B95\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BoardManufacturer\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Apple Inc.\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02921130GULNV9JA\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BoardType\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;10\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;BoardVersion\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;1.0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ChassisAssetTag\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac-Aluminum\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ChassisManufacturer\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Apple Inc.\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ChassisType\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x09\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;EfiVersion\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;220.250.368.0.0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Family\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;FirmwareFeatures\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0xFC0FE137\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;FirmwareFeaturesMask\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0xFF1FFF3F\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;LocationInChassis\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Part Component\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Manufacturer\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Apple Inc.\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Mobile\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;PlatformFeature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x00\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;iMac19,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;C02YR2YHJV3Q\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SmUUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;04FF56E3-085F-443D-9005-5E6915EDDC33\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Version\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;1.0\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; 最近は、Cloverが補完してくれるので、SMBIOSに書くべきパラメータは以下の4個で良いようです。ただ、まだCloverがiMac19,1に完全に対応していないと思われるので（ベータ版はかなり対応しているようです）今回は長いですが全部書き込みました。将来は以下の4個に削っても良いと思います。\nBoardSerialNumber ProductName SerialNumber SmUUID Step5: 互換性チェックをさせない指定をする これは、現時点（2019/4/8) のmacOS 10.14.4 (18E226) でiMac19,1, iMac19,2を使う場合のみに必要なステップです。間も無く出ると思われる10.14.5では不要になります。iMac19,1のボードIDであるMac-AA95B1DDAB278B95を指定すると、現時点（2019/4/8)のmacOS 10.14.4では起動できません。起動させるためには、Cloverのブートオプションに-no_compat_checkを追加する必要があります。そこで、config.plistのBootオプションに、\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;-no_compat_check\u0026lt;/string\u0026gt; と記載します。これでmacOS 10.14.4 (18E226) で起動するようになります。\nこのようにして作ったconfig.plistの全体を以下に置いておきます。\nconfig.plist for 9900K w/o iGPU display - Pastebin.com\nconfig.plistをテキストエディタで編集すると、うっかり間違った入力をしてしまうことがあります。以下のplutilコマンドでplistとして正しいかどうかチェックをしておくと良いです。\nplutil config.plist 正しければ以下のように表示されます。\nconfig.plist: OK 動作の確認 こうして作成したSSDを親マシンから外して、ASUS ROG MAXIMUS XI HEROに接続します。これから起動すると、無事macOSが起動しました。以下のように、ほぼ問題なく動きました。\nシャットダウンが正しく機能します。 スリープも正しく機能します。設定したスリープ時間になると、画面が消えて、マザーボードのLED類が消えて、CPUファンが停止します。キーボードを押すと復帰します。また、画面共有やsshなどで接続しても復帰します。 有線ネットワークも問題ありません。 WiFiとBluetoothも、純正のカードを用意したので、何もせずにそのまま動きました。 音声も出ます。config.plistではLayout番号1を設定しましたが、これとAppleALC.kextの組み合わせで問題なく音が出るようです。 RX580のHDMIポートからも音が出ます。 さらにはCPU内蔵のIntel UHD Graphics 630から表示もできますし、マザーボードのHDMIから音声も出ます。 10.14.3へのアップデートもシステム環境設定で行うことができました。\nActivity Monitor.appで「CPUの使用率」を開くと、16本の棒グラフが出てきます。圧巻です。\nGeekbenchでベンチマークしてみました。シングルコアが6,000, マルチコアが30,000超えました。Geekbench BrowserでiMac Pro Late 2017のスコアを見てみると8コアモデルでそれぞれがだいたい5,300と33,000くらいのようです。8コアiMac Pro程度の速度が得られているようです。\n今回使用したマザーボードは、そこそこ高級感があって良い感じでした。基板上にCPU温度表示などがあります。また電源スイッチ、リセットスイッチもあるためHackintoshの試行錯誤にも便利です。最近流行りのLED電飾機能ASUS Aura Syncも搭載しています。温度や音に同期して色を変えるなどの機能を使うためにはWindowsアプリケーションが必要ですが、刻々と変色するだけで良ければマザーボードだけで機能します。LinuxからLEDを制御しようとしている人もいるようですので、そのうちmacOSからも制御できる日が来るかもしれません。\nその後の調整 これでとりあえず動きました。もう少し手を入れて完璧にしていきましょう。\n10.14.4 (18E2034) の入手 上で述べたように、iiMac19,1のボードIDであるMac-AA95B1DDAB278B95を指定すると、現時点（2019/4/8) のmacOS Mojave 10.14.4 (18E226)では起動できません。起動させるためには、Cloverのブートオプションに-no_compat_checkを追加する必要がありました。本物のiMac Early 2019に搭載されているmacOS Mojave 10.14.4 (18E2034) ならばこの互換性回避オプションは不要です。\n実はiMac19,1や19,2として一旦起動すれば、18E2034が入手可能になります。詳細は以下をご覧ください。\n9900KのためにmacOS 10.14.4 (18E2034) を入手する\nUSB macOSはUSBの個数を15個に制限しています。今回は何の対策もしていないので、制限を超えるUSBポートのいくつかは機能していません。そこで不要なUSBポートを使わない指定をconfig.plistに書き込みます。詳細は、以下をご覧ください。\nASUS MAXIMUS XI HEROのUSBを設定する\n要約するとこうです。このマザーボードが使っているポートは、\nHS01 AsusTek社のAURA MOTHERBOARDが使用 HS02 HS03 バックパネルUSB 3のUSB 2.0 (4列上から3番目、赤、”SS10”) HS04 バックパネルUSB 3のUSB 2.0 (4列上から4番目、赤、”SS10”) HS05 バックパネルUSB 3のUSB 2.0 (Ethernetの下、赤、”SS10″) HS06 バックパネルUSB TYPE CのUSB 2.0 (Ethernetの下) HS07 バックパネルUSB 3のUSB 2.0 (4列上から1番目、青、”SS”) HS08 バックパネルUSB 3のUSB 2.0 (4列上から2番目、青、”SS”) HS09 （基板上のUSB 3に含まれるUSB 2.0端子と思われる） HS10 （基板上のUSB 3に含まれるUSB 2.0端子と思われる） HS11 バックパネルUSB 2.0 (PS/2の真下, 無表記) HS12 バックパネルUSB 2.0 (PS/2の下, “BIOS”) HS13 基板の2.0端子USB_E12, USB_E34 (USB2.0 Hub経由) HS14 マザーボード上のWiFi/Bluetoothモジュールが使用 USR1 (なんらかの理由で見えているダミーのポート) USR2 (なんらかの理由で見えているダミーのポート) SS01 SS02 SS03 バックパネルUSB 3.1 Gen 2 (4列上から3番目、赤、”SS10”) SS04 バックパネルUSB 3.1 Gen 2 (4列上から4番目、赤、”SS10”) SS05 バックパネルUSB 3.1 Gen 2 (Ethernetの下、赤、”SS10″) SS06 バックパネルUSB TYPE CのUSB 3.1 Gen 2 (Ethernetの下) SS07 バックパネルUSB 3.1 Gen 1 (4列上から1番目、青、”SS”) SS08 バックパネルUSB 3.1 Gen 1 (4列上から2番目、青、”SS”) SS09 （基板上のUSB 3.1 Gen 1端子と思われる） SS10 （基板上のUSB 3.1 Gen 1端子と思われる） です。この中から必要な15個を選択して、それ以外を使用しないように、例えば以下のようにconfig.plistに書き込みます。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;uia_exclude=USR1;USR2;HS01;HS02;HS09;HS10;HS14;SS01;SS02\u0026lt;/string\u0026gt; SS10は末尾なので、除外リストに入れる必要はないです。この場合、バックパネルのUSBポート全てと、基板上のUSB 2.0が使えるようになります。\n","date":"2018-12-15T16:59:13+09:00","image":"/uploads/2018/12/cpu.png","permalink":"/posts/988/","title":"9900K搭載Z390マザーボードでHackintoshを作る"},{"content":"\nUniBeastとMultiBeastを使ってmacOSをインストールした前回\ntonymacx86式インストール手順 (その1: UniBeast)\ntonymacx86式インストール手順 (その2: MultiBeast)\nに引き続き、今回はバニラな構成にし、設定を調整する方法を紹介します。\nESPをマウントする 前回の作業で一応Hackintoshが起動するようになりました。MultiBeastは何をしてくれたのでしょうか。まずはMultiBeastがどこに何をインストールしてくれたのかを確認します。そのためにまずはESPをマウントします。\nESPをマウントするには、専用のアプリもありますしKext Updater.appなどでも可能です。でも一番基礎的なターミナルでの作業を知っておくのも良いと思います。まずはドライブを確認します。ターミナルから、\n$ diskutil list とタイプすると、マシンに接続されたドライブの一覧が出ます。MultiBeastがインストールした起動ドライブ関係を見ると、\n/dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *80.0 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk1 79.8 GB disk0s2 /dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +79.8 GB disk1 Physical Store disk0s2 1: APFS Volume Mojave25SSD 6.0 GB disk1s1 2: APFS Volume Preboot 20.6 MB disk1s2 3: APFS Volume Recovery 1.0 GB disk1s3 4: APFS Volume VM 4.3 GB disk1s4 となっています。物理的にはdisk0の一つのドライブしかありませんが、その中に仮想的なドライブ（コンテナ）であるdisk1が作られています。disk1には、macOSの本体であるdisk1s1があります。それ以外の内容 (Preboot, Recovery, VM) については、こちらをご覧ください。\nここでESP (EFI System Partition)はdisk0s1であることがわかります。以下のdiskutil mountコマンドでマウントできます。管理者権限が必要なのでsudoコマンドを使っています。実行するとパスワードを聞かれます。\n$ sudo diskutil mount disk0s1 Volume EFI on disk0s1 mounted これにより、/Volumes/EFIの下にESPがマウントされます。\nここには、Cloverブートストラップローダプログラムや、efiドライバ、config.plistなどがインストールされています。\nKextをESPに移動してバニラ化する macOS本体に手をつけないバニラなインストールでは、kext類もESP、すなわちCLOVERのkexts以下に入れておきます。しかしMultiBeastではkextをESPに入れてくれません。MultiBeastはkext類を/Library/Extensions以下（略して/L/E）にインストールします。/L/E以下の内容を見てみましょう。\nここで選択した8個のkextがMultiBeastがインストールしたものです。とりあえずは動いているので、このままで良いでしょう。AHCI_3rdParty_eSATA.kextは、MultiBeastのインストールで指示したので入っています。でも、効果は感じられないですので、外しても良いかもしれません。FakePCIIDで始まる2個のkextもインストールの時に指示したものです。これもなくても問題なく動いていますので、外しても良かったかもしれません。\nMultiBeastがなぜESPじゃなくて/L/Eにkextをインストールするのかについて公式の説明はないと思います。おそらくは、kextによってはESPでは動かないものが稀にあるので、/L/Eにインストールしているのではないかと思われます。でもここでインストールされたkextはESPでも動くものばかりです。ESPに移せば、macOS部分は手つかずのバニラな状態になります。EFI/CLOVER/kexts/Otherの中に移動しておきましょう。ドラッグ\u0026amp;ドロップではコピーになってしまいます。kextが二重に存在するのは好ましくないので、MultiBeastがインストールした/L/Eのkextは消しておきましょう。\nEFIドライバ ESPの中のEFI/CLOVER/drivers64UEFIの中にはEFIドライバ類が入っています。MultiBeastが何を入れたか確認しておきます。\nVBoxHfs-64.efi PartitionDxe-64.efi SMCHelper-64.efi FSInject-64.efi FirmwareVolume-64.efi DataHubDxe-64.efi AptioMemoryFix-64.efi AppleUITheme-64.efi AppleKeyAggregator-64.efi AppleImageCodec-64.efi ApfsDriverLoader-64.efi Cloverのインストーラで「場合によっては必要」とされるefiが全て入っている様子です。色々な環境で動くことを考えての選択だと思います。これもkextと同じく、とりあえずは動いているので、このままで良いと思います。でも外しても動くようなら除外しても良いと思います。今回のハードウェア構成では、以下のドライバだけで問題なく動きます。\nVBoxHfs-64.efi SMCHelper-64.efi FSInject-64.efi AptioMemoryFix-64.efi ApfsDriverLoader-64.efi Config.plist MultiBeastが作ってくれたconfig.plistを次に見てみます。以下に掲載しておきました。これも、起動しやすいことを目指して、安全よりの設定になっています。下記で説明するSMBIOSの項目以外は、このまま使い続けて構わないと思います。\nconfig.plist by MultiBeast - Pastebin.com\nACPI ACPIの最初のキーはDSDTです。この中のDropOEM_DSMのkeyは、#DropOEM_DSMと改名されています。存在しないキーに改変されていることで、コメントアウトになっています。ここの設定は消してしまっても構わないです。Fixesのkeyは、すべてfalseです。デフォルトがfalseなのでこれも全部消してしまっても構わないです。ということでDSDTはNameキーくらいはあっても良いけど、他は消してしまっても大丈夫です。\n次のDropTablesのkeyではMATSが外してあります。昔はMATSがカーネルパニックを引き起こしやすかったらしいのですが、今はdropしなくても大丈夫です。消しても構わないです。\n次のHaltEnablerはfalseなので消してしまって構わないです。シャットダウンした後で起動してしまう症状が現れるようならtrueにしてみると効果があるかもしれません。\nSSDTはこのままでも良いです。DropOEMは消しても良いです。\n結果、ACPIはこれくらい書いてあれば十分です。\n\u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;DSDT.aml\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;SSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Generate\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CStates\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;PStates\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; Boot Bootはこのままで良いです。DefaultVolumeは起動ドライブの名前にしておきます。Timeoutはマイナスにするとキーボード入力待ちします。色々調整する場合はマイナスにしておくと便利です。\nDevices, DisableDrivers FakeIDは全部ゼロのままなので、効いていません。DisableDriversも何も指定していません。両方とも消してしまっても構わないです。\nGUI, Graphics このままで良いと思います。必要に応じて変更します。\nKernelAndKextPatches KextsToPatchのキーに外部ドライブがオレンジ色アイコンになることを阻止するパッチが書いてあります。ほとんど困らないと思いますので、削除しても良いと思います。副作用を考えるとパッチは少ない方が良いですから、不要なパッチは外しておきましょう。\nRtVariables CsrActiveConfigは0にしておくとSIPが有効になります。kextをESPにすべて移動したので0でも大丈夫なはずです。SIP有効にすれば実機と同じになるので気持ちが良いです。\nBooterConfigは、実は何も使われていないです。以前、Cloverのソースを見て確認しました。消しても構わないです（あっても大丈夫ですが）。\nSMBIOS MultiBeastはTrustのキーしか作ってくれません。最近のCloverはSMBIOSのいくつかの項目を自動で作ってくれますが、完全ではありません。こちらのガイド\n正しく機種設定する (SMBIOSの設定)\nを見て、少なくとも以下の項目は作成しておくのが良いです。\nBiosVersion ProductName SerialNumber 実際、MultiBeastの前回の設定では、ProductNameをiMac15,1にしました。しかしconfig.plistではそれが書かれておらず、iMac14,2になってしまっています。SMBIOSをしっかり設定することで、ハードウェアに合致した機種IDになり、トラブルを回避できます。\nSystemParameters この部分は、MultiBeastがインストールしたそのままで大丈夫です。\n今後の調整 今回の作業で、バニラなシステムになり、機種名が正しく設定できて、より安定なシステムになったのではと思います。終了、スリープなども機能します。ネットワークにも接続できていると思いますので、一通りの機能は使えていると思います。ただ、いくつかやり残している機能もあります。\nサウンド AppleALC.kextがあり、またconfig.plistのAudioでInject 1としているので、運が良ければ音は出ます。でなければ、Injectの数値を変えるか、VoodooHDAを使うか、USBオーディオを使うと良いです。\n音を出す\nUSB USBの上限個数15を外すパッチを採用しませんでした。そのため使えないUSBポートがあるかもしれません。こちらを見て対応すると良いです。\nUSBポートを設定する\nおまけ：名前の由来 Cloverの前に一般的だったブートローダープログラムがChameleonでした。macOSがインストールできるようにマシンを変化させる機能を、色を変えられるカメレオンになぞらえたのだと思います。Chameleonはオープンソースだったので、tonymacx86の中の人がこれをフォークしてtonymacx86版のブートローダープログラムを作り、これをChimeraと名付けました。異種のOSを起動できる機能を、色々な動物の部位を併せ持った伝説上の生き物になぞらえたのだと思います。\n(Chimeraのアイコン)\nChameleonは古いハードウェアから最新ハードウェアまで満遍なくサポートするのに対して、Chimeraは古いハードウェアは切り捨てつつ、最新ハードウェアに積極的に対応する違いがありました。tonymacx86で提供するおすすめハードウェア構成で確実に動くことを目指していました。\nその後、Chimeraとkext類をインストールして設定するためのインストーラが作られて、その名前がMultiBeastになったわけです。キメラをもじっての命名だと思います。その後に出た、インストール用USBメモリー作成ツールは、USBのUniversalと、どのマシンでも起動するユニバーサルなアプリであることからUniBeastと名付けられたと思われます。\n","date":"2018-12-14T01:17:00+09:00","image":"/uploads/2018/11/20181112224438.png","permalink":"/posts/968/","title":"tonymacx86式インストール手順 (その3: バニラ化と調整)"},{"content":"\nMultiBeastを使って「ポストインストール」する方法をHackintosh初心者向けに紹介します。MultiBeastはtonymacx86.comで作られて配布されているHackintosh作成ツールです。Apple純正インストーラやUniBeastによりmacOSがインストールされたドライブに、Cloverやkext類をインストールし、macOSを起動できる状態にしてくれます。インストールが簡単になってしまうので何をやっているか理解しないでHackintoshを作ってしまうとか、バニラなインストールにならないなどの批判もあります。しかし何をどうしたら良いかわからない初心者にはありがたいツールです。動かすまでに苦労することがHackintoshの醍醐味ではありますが、とりあえず動かないと心が折れます。なので、Hackintosh初心者は、まずはMultiBeastでインストールして、動くことを確認して、チューニングを施してバニラな構成に持っていくのも良いと思います。\ntonymacx86式インストール手順 tonymacx86で推奨されているインストールの手順は：\n動いているmacOSマシン（以下、親マシン）でApp StoreからmacOSをダウンロードする。 親マシン上でUSBメモリを初期化する。 親マシン上で、tonymacx86配布のUniBeastというツールを使ってインストール用USBメモリを作る。（UniBeastはcreateinstallmediaコマンドと同様にインストール用USBメモリを作り、それに標準的な構成でCloverをインストールします） Hackintoshを作ろうとしているマシン（以下対象マシン）でインストール用USBメモリを起動する。 対象マシンに接続したドライブにmacOSをインストールする。（インストール用USBメモリを使うとこのドライブからmacOSを起動できます） macOSで起動した対象マシン上でMultiBeastを使ってClover等をインストールし、そのドライブ単体でmacOSを起動できるようにする です。1から5のステップは以下で説明しました。\ntonymacx86式インストール手順 (その1: UniBeast)\nこの記事では6番目の最後のステップを説明します。この太字部分を「ポストインストール」とも呼んでいます。\nMultiBeastでポストインストール UniBeastは大抵のマシンで起動できるUSBドライブを作ってくれて操作も簡単です。それに対してMultiBeastによるポストインストールの手順は選択肢も多くて大変です。完成度を高めるためには調整も必要です。今回は、とりあえず動くところを目指し、バニラなインストールを目指した調整を次回に行います。\n今回インストールを試みるマシンは、Haswell CPUとRadeon RX-580を使ったマシンです。まずはインストール先のハードウェアを調査しておきます。このマシンのマザーボードはMSI Z97A Gaming 7で、これには、以下のチップが搭載されています。\nIntel Z97 チップセット 6本のSATAとUSB 2.0/3.0をサポートします ASMedia ASM1061 SATAコントローラ 追加の2本のSATAを提供します Qualcomm Atheros Killer E2205 Ethernetを提供します ASMedia ASM1142 2本のUSB 3.1を提供します Realtek ALC1150 サウンド機能を提供します これらを適切に機能させるべくMultiBeastで設定していきます。最初にMultiBeastを起動するとこんなウィンドウが出ます。\n左上にはアイコンが並んでいます。このアイコンを左から順番に選択して作業を進めていきます。また、アイコンを選択すると、何のためにどの様な作業が行われるかの説明が表示されます。これを読んでいくと勉強になります。\nQuick Startアイコン まずはQuick Startアイコンを押します。すると、UEFI Boot ModeとLegacy Boot Modeの選択が可能になります。UEFI対応になったマザーボードですのでUEFI Boot Modeを選びます。CloverやkextがESPにインストールされるので、バニラなインストールに近くなります。\nこれを選択すると、\nCloverがUEFIブート状態でインストールされ、 システムの設定がiMac14,2になって、 kextはFakeSMCがインストール されるようになります。\nDriversアイコン 次にDriversアイコンをクリックします。すると、Audio, Disk, Misc, Network, USBのアイコンが出ます。\nAudioでは、音を出すドライバとして、以下の3種類を選択できます。音は後回しにしても良いと思うのでしたらどれも選択しなくても良いです。\nAppleALC これを選んでおきましょう。一番新しくておすすめな方法です。Lilu.kextと一緒にインストールされて必要なパッチも全て行ってくれます。 Realtek ALCxxx 少し前に一般的だった方法です。色々とパッチを当てる必要があります。 Universal Voodooシリーズのドライバを入れる選択肢です。一番確実に動きますが、音が割れたりすることもあります。 Diskでは、以下を選択できます。インテルチップセット接続のSATAは、ここで何もしなくても動きますので、追加のSATAが不要ならどれも選択しなくて良いです。\n3rd Party SATA ASM1061, JMicron 36x, Marvel 88SE912x, 88SE9172, 88SE9230 SATAコントローラをサポートします。ここに接続したドライブは内部ドライブとして表示されてホットスワップできません。AHCI_3rdParty_SATA.kextがインストールされます。 3rd Party eSATA サポートするチップは上記と同じです。違いは、ここに接続したドライブが外部ドライブとして表示され、ホットスワップできることです。AHCI_3rdParty_eSATA.kextがインストールされます。今回のマザボにはASM1061が搭載されていて、リムーバブルドライブベイに接続しましたので、使うならこれを使います。 Intel Graphic AHCI SATA 200, X79, X99, 一部の9シリーズチップセットのSATAコントローラが「一般的なAHCIコントローラ」と表示されるところを、実際のチップセット名にします。接続されたドライブは内部ドライブになります。AHCI_Intel_Generic_SATA.kextがインストールされます。Z97でもSATAコントローラ名が表示されませんので、気になるならばこれを使うと良いです。ちなみにMultiBeastには含まれていませんが、AHCIPortInjector.kextでも同じ効果が得られます。 Miscでは、以下を選択できます。絶対必要な項目はFakeSMCです。これだけはチェックします。\nFakeSMC Hackintoshに必須の唯一のkextであるFakeSMC.kextをインストールします。実機にあるSMC (System Management Controller)のフリをします。必要です。 FakeSMC Plugins ハードウェアモニターのためのプラグインです。温度などを見る必要がなければ不要です。 FakeSMC HWMonitor Application ハードウェアモニターのためのアプリケーションです。温度などを見る必要がなければ不要です。 NullCPUPowerManagement 電力制御を無効にするNullCPUPowerManagement.kextをインストールします。電力制御に関する設定に失敗していても起動するようになります。最終的には外したいkextですが、電力制御が失敗して起動しない場合は導入しても良いです。 Core Graphics Fixup AKA WhateverGreen WhateverGreen.kextとLilu.kextをインストールします。AMD/Intel/Nvidiaグラフィックス関係の有効なパッチをいくつか当ててくれるので、入れておいた方が良いです。 VoodooTSCSync LGA2011 CPUが対象ですので、今回は不要です。 NetworkではLAN用のドライバを選択します。Atheros, Intel, Realtekの選択肢があります。今回は、Atheros E2205を使っているので、Atheros E2200シリーズ用の最新版を選択します。これで、AtherosEthernet.kextがインストールされます。\nUSBでは、以下を選択できます。\n3rd Party USB 3.0 マザーボードのチップセットにUSB 3.0が搭載されていなかった時代の選択肢です。今回のマザーボードでは不要です。 7/8/9 Series USB Support 今回のマザーボードがこれに該当します。FakePCIID.kextとFakePCIID_XHCIMux.kextをインストールするようです。実はどちらのkextも使っていなかったのですが、せっかくだから試してみます。 Remove XHCI USB Port Limit OSがサポートするUSBの数が15個であることの制限を撤廃するパッチです。これはmacOSのバージョンごとに変わりますので、あまり素性の良いパッチではありません。使うのはやめておきましょう。 USBInjectAll 15個の制限内で使用するUSBポートを選択することに使えます。入れておきます。 USBに関するちゃんとした設定はあとで行いましょう。詳しくはこちらをご覧ください。\nUSBポートを設定する\nBootloaderアイコン 次にBootloaderアイコンをクリックします。\nこのアイコンでは以下の選択ができます。\nClover UEFI Boot ModeはEFIブート用にインストールし、さらにAptioMemoryFix, ApfsDriverLoaderがインストールされます Clover Legacy Boot ModeはBIOSベースのマザーボード用です Clover UEFI Boot Mode + Emulated NVRamは、OsxAptioFix2Drv, EmuVariableUefi, apfs.efiをインストールします ここでは最初のUEFI Boot Modeを選んでおけば良いです。Legacyを選択する必要性はないです。また、最後のオプションはNVRAMエミュレーションを行うドライバを導入します。しかし、NVRAMエミュレーションが機能しなくても起動はしますので、必要な場合は、あとで行えば良いです。NVRAMの設定に関して、詳しくはこちらをご覧ください。\nNVRAMのエミュレーション\nCustomizeアイコン 次にCustomizeアイコンをクリックします。\nGraphics Configurationでは以下の選択がでます。しかし、今回の構成で必要な項目はありません。何も選択しなくて良いです。\nIntel HD 6xx, 今回のiGPUはこれではないです。 Inject ATI, 今回のGPUはAMDですが、GPU部門はATIという会社でした。ですがこれは古いATI製品用の選択肢です。 Inject NVIDIA 今回のGPUはNVIDIAではないので選びません。 NVIDIA Web Drivers Boot Flag 今回のGPUはNVIDIAではないので選びません。 SSDT Optionsの項目にはSandy Bridge用のSSDTが用意されています。今回のCPUに必要な項目はありません。何も選択しなくて良いです。\nSystem Definitionsでは、今回の構成に近いMacのモデルを選択します。Macの仕様は、MacTracker.appなどで調べると良いかと思います。今回は、iMac15,1を選択します。\nBuildアイコン 最後にBuildアイコンを選択すると今までの設定のまとめが出ます。これで問題無いことを確認できたら、右下のInstallアイコンをクリックします。するとSelect Install Driveで示されたドライブ（ここではMojave255SSD）のESPと/Library/Extensionsに必要なファイルがインストールされます。\n以上で、ポストインストールが終了します。\n起動する いよいよこのドライブで起動してみましょう。tonymacX86で用意された特別なthemeが設定されているので、Cloverの起動選択画面はこんな感じになります。\nこれで問題なく起動します。\nシリアル番号は（たぶん）Cloverが適当に生成してくれています。機種名はちょっとおかしいです。そのあたりはまた次回に調べたいです。でも問題なく起動して動作します。とりあえず起動するドライブを作れるという点で、MultiBeastは優れたツールだと思います。\n次回は、MultiBeastが何をどこにインストールしたのか、それをどう改善していけるかを調べてみたいと思います。こちらに続きます：\ntonymacx86式インストール手順 (その3: バニラ化と調整)\n","date":"2018-12-10T00:30:56+09:00","image":"/uploads/2018/11/20181112224438.png","permalink":"/posts/21/","title":"tonymacx86式インストール手順 (その2: MultiBeast)"},{"content":"これは古い情報です。10.16 Catalina以降のmacOSのためのグラフィックスカードについてはこちらをご覧ください。\nmacOSのためのGPUの選び方\nHackintosh自作に適したグラフィックスカードを紹介します。macOS 10.14 Mojave以降のmacOSでHackintoshする人向けに情報をまとめました。10.13以前のmacOSの情報を含む詳しい経緯は、以下をご覧ください。10.13.4から10.13.6の情報はこちらをご覧ください。\nHackintoshのパーツ選び 【その3：グラフィックス編】10.13.4以降版\n10.13.3以前の情報はこちらをご覧ください。\nHackintoshのパーツ選び 【その3：グラフィックス編】\nCatalinaを前提とした場合の情報はこちらをご覧ください。\nmacOSのためのGPUの選び方\n結論としては、AMDのRadeon RX 560/570/580/590、Radeon VII、VEGA 56/64がおすすめです。\nAMDグラフィックス 10.14以降のmacOSでは、AMDグラフィックスがお薦めです。AMD Radeon RX 470/480/560/570/580/590およびVEGA 56/64の4モデルならば取り付けるだけでそのまま動きます。10.13.4からThunderbolt 3接続の外付けGPUボックスがmacOSで正式にサポートされたからです。\nAppleはeGPUで使うカードをいくつか推薦しています。また、eGPUボックスを実際に開発しているSonnetも推奨AMD GPUを発表しています。これらを使えば、簡単にHackintoshできるので、お勧めです。このうち、Pro WXシリーズは高価なので一般的なHackintoshからは除外できるかもしれません。なので実質的には、\nAMD Radeon RX 560, RX 570, RX 580, RX 590 AMD Radeon RX Vega 56, RX Vega 64 廃盤製品を中古から探しても良いなら\nAMD Radeon RX 470, RX 480 も候補になります。\nVegaでは搭載空冷ファンのコントロールが効かず最大スピードになるという報告もあります。それも直せたという報告もありますので、対応可能なようです。 一般的な自作PCの世界では、AMDの製品は、NVIDIAと比較して上位機種の性能、性能あたりの消費電力で未だに劣っていると言われています。ただ、これはWindowsで使うことを前提にした話です。macOSで使う場合、AMDはOSで正式にサポートされているアーキテクチャなので、色々と最適化されています。例えば、Final Cut Pro Xなどを使って性能比較すると、同じ性能ランクのNVIDIAよりも良いスコアを出します。\nNVIDIAグラフィックス NvidiaはmacOS用のドライバを供給してくれていたため、多くの製品がmacOSで動きました。ただMojaveでは手こずっているようです。Appleの認可が得られないため遅れていると噂されています。Mojaveが出てから間も無く3ヶ月になりますが、まだドライバが出る気配がありません。そのため、残念ながら現行のNvidia GPUはMojaveで動きません。\nKeplerアーキテクチャとそれ以前の古いカードは、Nvidiaのドライバを入れなくてもmacOSの標準ドライバだけで動きます。なのでMojaveでも動きます。Keplerアーキテクチャの代表的なモデルは以下です。\nGTX780Ti GTX780 GTX770 GTX760 GTX680 GTX670 GTX660 GTX650Ti GTX650 GTX640 macOSの標準ドライバだけで動く古いNVDIAカードはたくさんあります。例えば以下のような製品が手に入るなら、安価に使えるようです。\nnvidia gt 9400 nvidia gt 9500 nvidia gt 210 nvidia gt 220 nvidia gt 9600 nvidia gt 240 nvidia gts 250 nvidia gt 610 nvidia gt 630 nvidia gt 640 nvidia gt 710 nvidia gt 730 ただしHigh Sierra以降では、Keplerは動くけど、それより古いFermiは動かなかったという報告があるようです。あまり古いものは避けて、Keplerのモデルにしておいたほうが無難かもしれません。できるだけ安く探すとなるとGT 710とかGT 730あたりでしょうか。\nIntel CPU内蔵GPU MacintoshでIntel CPU内蔵GPU (iGPU) を使っている機種は多数あります。これらと同じGPUは問題なく使用できると考えて良いです。純正Macで採用されていないIntel GPUも、近いモデルならば動くことがあります。 MojaveからはMetal対応のGPUのみがサポートされるようになります。Sandy Bridge以前のIntel CPU内蔵GPUは、Metalに対応していません。Ivy Bridge以降のCPUならば大丈夫です。ちなみにMojaveをサポートしているiMacとMac mini 2018が搭載しているデスクトップ向けIntel HD Graphicsは\nIntel HD Graphics 4000 Intel HD Graphics 5000 Intel HD Graphics 6000 Intel HD Graphics 530 Intel HD Graphics 630 Intel UHD Graphics 630 です。Intel UHD GraphicsはMojaveからサポートされています。 ただCPU内蔵グラフィックスは、 時々画面が乱れるとか、スリープからの復帰に失敗してハングするなどの問題も報告されています。互換性のあるPCIeのグラフィックスカードの方が安定しています。もともと、Intelのデスクトップ用CPUの内蔵GPUはモバイル用に比べて非力です。トラブルに遭遇したら「モバイル機種に負けるようなグラフィックスは使わない」と考えてPCIeグラフィックスカードを検討するのが良いと思います。\n","date":"2018-12-08T18:34:46+09:00","image":"/uploads/2018/08/20171118234329-300x182.png","permalink":"/posts/945/","title":"HACKINTOSHのパーツ選び 【その3：グラフィックス編】10.14以降版"},{"content":"macOSをインストールすると、macOSの本体が入るボリュームの他に、Recovery（回復）用のボリュームが自動的に作成されます。Recoveryボリュームは、Cloverの起動画面に起動選択肢として現れます。右下の十字マークは、赤十字や病院の印です。macOS本体が起動しなくなってしまった非常時には、Recoveryボリュームから起動して復旧作業を行えます。\nRecoveryボリューム Recoveryボリュームの場所 diskutil listコマンドでマシンに接続されているドライブを見ることができます。コマンドの結果例を以下に示します。このマシンには512GBのSSDが接続されていますが、それがdisk0に割り当てられていることがわかります。disk0はEFIが使用するESP (EFI System Partition)とAPFSのコンテナに分割されています。APFSのコンテナは仮想的なドライブとしてdisk1に割り当てられています。\n$ diskutil list /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *500.2 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk1 500.0 GB disk0s2 disk1の項目を見ると、これが合成された(synthesized)ドライブであると書いてあります。disk1という名前は付いているけど、物理的なドライブではないということです。disk1の中には4つのボリュームができています。これも仮想的なボリュームです。SSDの上では、それぞれがコンテナに割り当てられた500GBを共有しています。ここには実際に使用している容量が書いてあります。\n/dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +500.0 GB disk1 Physical Store disk0s2 1: APFS Volume Macintosh SSD 331.6 GB disk1s1 2: APFS Volume Preboot 46.0 MB disk1s2 3: APFS Volume Recovery 517.0 MB disk1s3 4: APFS Volume VM 20.5 KB disk1s4 ここに現れたボリュームの中で重要なのはdisk0s1, disk1s1, disk1s3です。\ndisk0s1: ESPです。ここにClover関係のファイル、Cloverが読み込むkext類があります。マザーボードのBIOS設定では、起動ボリュームとしてここを設定します。電源投入後、Cloverがkext読み込みとパッチ当てを終えるとmacOSを動かせます。 disk1s1: macOSの本体です。通常はこれで起動します。電源投入後にESPからHackintoshに必要なパッチやkextが読み込まれていれば、純正インストーラがインストールしたそのままで（バニラの状態で）動きます。 disk1s3: Recoveryボリュームです。非常時に起動することができます。ESPのファイル群によりHackintoshに必要な処理が終っていれば、これもバニラのまま動きます。 というわけで、バニラなCloverインストールが行われていれば、純正インストーラによりインストールされたmacOSだけでなく、Recoveryからも起動できるわけです。\n/posts/131/\nちなみに、残りの二つのボリューム、PrebootとVMは、以下のものです。PrebootはAPFSボリュームからmacOSをブートするための作業用ボリュームらしいです。詳しい働きはわかりません。VMは仮想メモリ(Virtual Memory) のスワップ用ボリュームのようです。使われていないメモリ内容をここに保存します。以前のmacOSではスワップ領域がファイルだったようですが、APFSになってボリュームになりました。従来の物理的なボリュームだと記憶領域が固定されてしまうけど、APFSなら他のボリュームと共用できるので無駄がありません。ということで、ファイルよりおそらく効率の良いボリュームに変更されたのかと思います。\nRecoveryボリュームの内容 Recoveryの中に何が保存されているかを調べてみましょう。これがdisk1s3だとわかっているので、以下のコマンドでマウントできます。この結果、/Volumes/Recoveryというフォルダにマウントされます。\n$ diskutil mount disk1s3 Volume Recovery on disk1s3 mounted マウントされたフォルダにはUUIDらしい名前のフォルダが一つだけありました。その中を見てみると以下のようでした。（結果を編集して作業ファイルらしい細かいファイルは省略してあります。）\n$ ls -l /Volumes/Recovery/A486A01B-7777-8888-9999-000000000000/ total 1058320 -rw-r--r--@ 1 root wheel 1984 11 30 15:41 BaseSystem.chunklist -rw-r--r--@ 1 root wheel 485344690 11 30 14:28 BaseSystem.dmg -rw-r--r--@ 1 root wheel 3900 11 14 13:44 PlatformSupport.plist -r--r--r--@ 1 root wheel 533 11 30 13:07 SystemVersion.plist -rw-r--r--@ 1 root wheel 592440 11 30 14:20 boot.efi -rw-r--r-- 1 root wheel 397 12 6 22:36 com.apple.Boot.plist -rw-r--r--@ 2 root wheel 27924868 11 15 17:52 immutablekernel -rw-r--r--@ 2 root wheel 27924868 11 15 17:52 prelinkedkernel ここにあるBaseSystem.dmgが、最小限の機能でmacOSを動かすための一式が入ったディスクイメージファイルです。これを使って非常時の起動を行なえるようです。\nRecoveryでできること Cloverの起動画面からRecoveryボリュームで起動すると、以下の画面が現れます。Recovery起動中のスクリーンショットの撮り方がわからなかったので、写真です。見にくくてすみません。画面にはmacOSユーティリティが現れます。macOSをインストールするときに現れるお馴染みの画面です。ここから4つの機能を利用できます。\nメニューバーにはユーティリティという項目があり、ここにはさらに3個の機能が用意されています。全部で7種類のツールを使えます。順番に見ていきます。\n起動セキュリティユーティリティ Hackintoshでは動きません。Appleのサポートサイトに機能の説明があります。Apple T2 セキュリティチップを搭載した Mac コンピュータでファームウェアパスワードによる保護、安全な起動、外部起動を実現するツールのようです。HackintoshだけでなくT2非搭載のMacでは動かない機能です。\nネットワークユーティリティ ネットワークの状況がわかります。Ethernetが機能していてDHCPでアドレス取得しているようです。LANチップのAtheros Killer E2200が動いています。CloverがESPにあるAtherosE2200Ethernet.kextを読み込んでくれていて、それが機能していることが確認できます。\nWiFiも動いています。こちらはパスワードを入れなくても接続していました。いつものパスワードがRecoveryから使用できているようです。画面右上にはWiFiアイコンが出ています。もしアクセスポイントの選択やパスワード入力が必要ならば、WiFiアイコンから行えます。\nターミナル ターミナルさえ動けばなんでもできるので安心です。大体のボリュームがすでにマウントされていますので、/Volumesからどれでも操作できます。ESPの内容も、diskutilコマンドでマウントすれば編集・修正できます。ただ、ESPの内容に不具合があったらRecoveryの起動もできない可能性が高いので、ESPを変更する場面は少ないかもしれません。通常はmacOSボリュームやNVRAMなどが変更対象になるかと思います。\nTimeMachineバックアップから復元 これを選択すると、接続されているドライブとネットワーク上TimeMachineサーバが表示されます。その中から、必要なタイムスタンプのバックアップを復元できます。Recoveryから起動しているので、macOSのシステムも復旧できます。\nmacOSを再インストール おなじみのmacOSインストーラが起動してインストールできます。インストールのためにはネットワークに接続している必要があるらしいです。\nヘルプ情報をオンラインで取得 Safariが起動してヘルプのファイルが開きます。ネットワークが接続されていれば、外部にも接続できます。\nディスクユーティリティ ディスクユーティリティ.appが起動します。BaseSystem.dmgがディスクとしてマウントされている様子がわかります。ディスクユーティリティ.appが動けばドライブのフォーマットもボリューム追加・初期化も思いのままです。ただし起動しているRecoveryボリュームは使用中ですので初期化できません。\nmacOSに不具合がある場合は、初期化されたボリュームに新規インストールすることが多かったかと思います。APFSになってボリュームが幾つでも作れて、容量も気にする必要がなくなりました。なので、macOSを新規インストールする場合に、既存のボリュームを消去せず、それを残したまま新規にボリュームを追加しても良いかと思います。\n","date":"2018-12-08T01:54:37+09:00","image":"/uploads/2018/12/recovery.png","permalink":"/posts/903/","title":"Recoveryからブートする"},{"content":"マザーボードのPCIe構成 現在、Z390搭載のMicro-ATXマザーボードでCoffee-Lakeマシンを自作しようとすると6種類の選択肢しかありません。人気の無いフォームファクタなのでしょうか、寂しい限りです。そのうちASUSとMSIからは２モデルが出ています。（リンク先はAmazonのページです）\nこの2社の２モデルのうち、高額な方のモデルは、他のMicro-ATXマザーボードとPCIeスロットの構成が違うことがわかります。以下は4本あるPCIeスロット部分の写真です。写真の上の方にCPUがあります。\n長いスロットがPCIe x16と呼ばれるもので短い方がx1です。CPUから近い方からぞれぞれ、\n16, 1, 16, 1（最初の写真） 16, 1, 1, 16（次の写真） のように並んでいます。16と1が交互に並んでいる方が高級マザーボード、16が両端にあるのがそれ以外の一般的なマザーボード（H370/B360などもこちら）です。macOSをインストールする場合は、どちらの構成が有利なのかを考えてみました。\nレーン数 ところで、PCIe x16とかPCIe x1と表記するときの数字の部分は、PCIeのレーン数です。PCIeは、超高速（PCIe 3.0では2Gb/s程度）のシリアル転送を行なっています。このシリアル転送の配線を何組用意しているかがレーン数になります。1レーンは1組、16レーンは16組のシリアル転送配線セットを持っていることになります。1レーンあれば2Gb/sの、16レーンあれば32Gb/sのデータ転送ができます。1レーンのデータ転送では、送信受信にそれぞれ1対の差動配線を用いるので、1レーン当たり合計で4本の信号線を使用します。実際にはそれぞれにノイズ低減のための接地線が用意されるので、レーンが1増えるごとに、スロットのピン数は8個増え、だんだんと長くなります。\n(上からx4, x16, x1, x16のPCIeスロット。一番下は古い規格のPCIスロット。Wikipediaより）\nスロットの物理的な長さと、実施されるデータ転送の速度は必ずしも一致しません。長い16レーン用のスロットが用意されていても、全部が配線されているとは限りません。あとで紹介するように4レーンしか配線されていないこともあります。また、長いPCIeスロットに短いPCIeカードを挿すことも可能ですが、その場合は、接続された接点だけで通信します。例えば16レーンの長いスロットに4レーンの短いカードを挿すと、4レーンで接続されます。\nCPUとチップセット Coffee Lake CPUとZ390チップセットのブロック図がIntel社のサイトで公開されています。引用します。ここで上の箱がCPUで下の箱がチップセットです。\nPCIeスロットには、CPUに直結しているものと、CPUからはDMI 3.0を経由してチップセットの先に接続されたものの2種類があることがわかります。図で言うと、左上にある16レーンのPCIeがCPU直結、チップセットの左にある24レーンのPCIeがチップセット経由です。最近のIntelのメインストリームCPUはZ170の時代からほぼこれと同じ構成です。CPU直結のPCIeはフルスピードが出ます。16レーンなので32Gb/sくらいの速度が出ます。一方でチップセット経由のPCIeは合計24レーン使えますが、8Gb/sのDMI 3.0がボトルネックになっていて、合計で8Gb/sしか速度が出ません。8Gb/sというのはPCIe 3.0のレーン数にすると4レーンです。\n高級と一般マザボのスロットの違い 最初に、高級なマザボと一般のマザボでPCIeスロットの並びが違うことを示しました。並びが違うだけではなく、接続先も違うのです。つまり、上記で示した2種類のPCIe構成において、以下の青い太字のスロットがCPU直結のPCIeで、それ以外の細字のスロットがチップセットのPCIeです。\n16, 1, 16, 1 16, 1, 1, 16 高級マザーボードでは、CPU直結のPCIeが２本あります。というのはZシリーズのチップセットでは、CPU直結のPCIeを分割する機能があるからです。この機能は、CPU直結の16レーンを、\n16 8+8 8+4+4 の３通りに分割することができます。ブロック図の左上に書いてあります。フルサイズのATXマザボでは8+4+4の3本に分割することもありますが、スロットが4本しかないm-ATXでは8+8の2本に分割されます。また、この分割は、PCIeカードが挿された時に自動的に実施されます。つまり、\n16, 4, 16, 4 の構成のマザボは、CPU直結の両方のスロットにカードを挿すと、8 + 8に分割されるのです。以下は、のマニュアルからの抜粋です。CPUに近い方のx16レーンスロットPCIEX16_1と、遠い方のx16レーンスロットPCIE16_2にカードが挿された場合に、何レーンで接続されるかが表に書いてあります。これを見ると、CPUに近い方のx16レーンスロットにのみカードを挿すと16レーンで接続されて、一方のx16レーンスロットにもカードを挿すとそれぞれが8レーンに分割され接続されると書いてあります。\n一方で、\n16, 1, 1, 16 の構成のマザボでは、CPUに近いx16レーンのスロットのみが、CPUに直結しています。CPUから遠い方のx16レーンスロットはチップセット経由です。この構成では、CPU直結レーンが分割されることはありません。以下は、のマニュアルからの抜粋です。PCIEX16_2にカードを挿しても、PCIEX16_1の速度が変化しないことがわかります。\nこれを見ると、合計レーン数が多いので、この構成の方が優れているように思うかもしれません。しかし、PCIE16_2のレーンはチップセットが管理していて、他のPCIe, M.2, SATA, USB, LANなどと一緒にDMI 3.0の8Gb/s帯域を共有しています。それもあってPCIE16_2のレーンは4レーンしかないのです。4レーンは8Gb/s相当なので、これ以上のレーンがあってもデータ転送速度に対応できないためです。\nPCIeに複数のグラフィックスカードを接続して、グラフィックスや並列計算を高速化する手法があります。グラフィックスの場合、NVIDIAではSLI, AMDではCrossFireと呼ばれている機能で、複数のグラフィックスカードを接続して、ゲームなどの画面描画を高速にすることができます。グラフィックスカードには通常16レーンのコネクタが付いていますので、本来なら16レーンずつのPCIeスロットに挿したいところです。しかしCPU直結が全部で16レーンしか無いので、半分に分けて接続します。\n16, 1, 16, 1 の構成のPCIeは、2本のx16スロットが、8レーンになってしまいますが、どちらも高速なCPU直結になり、SLI/CrossFireに適しています。なのでグラフィックスカードを2枚使用する場合は、こちらの構成の高級マザーボードを買うべきです。ちなみに\n16, 1, 1, 16 の構成のマザーボードでもSLI/CrossFire対応している製品が多数あります。\nmacOSはSLI/CFできない 多くのマザーボードが対応しているSLI/CrossFire機能ですが、これはWindowsかLinuxでしか使用できないです。それも対応したアプリケーションからのみ利用可能です。macOSでは、円筒型Mac ProでAMDのGPUを2個使ったデュアルGPUを構成していますが、CrossFireとは違う使い方をしています。なのでmacOSを使う限り、m-ATX, ATXマザーボードにグラフィックスカードを2枚挿しするメリットはほとんどありません。グラフィックスカードを1枚しか使用しない場合、\n16, 1, 16, 1 の構成のPCIeのメリットはほとんどありません。逆に、こんなデメリットも考えられます。\nグラフィックスカードを1枚使用する場合、CPU直結のPCIeを利用するために、CPUに一番近い16レーンスロットに挿すことになります。そうすればグラフィックスカードの16レーンが全てCPU直結になり、最高の性能が期待できます。この時、直結PCIeを分割する機能がある\n16, 1, 16, 1 の構成のマザーボードで、2番目の16レーンスロットを使用しようとすると、1番目のスロットの帯域が半減して8レーンになってしまいます。グラフィックスカード以外のカードを挿しても分割機能が働いて帯域が半減します。なので直結16レーンの性能をフルに活かしたいなら、2番目の16レーンスロットは使用しないほうが良いです。一方で、\n16, 1, 1, 16 のマザーボードなら、残りのどのスロットを利用してもGPUの帯域は低下しません。フルバージョンのATXマザーボードならスロットは多数ありますので、分割しないスロットを選んで使用すれば良いです。しかし、4本しかスロットの無いm-ATXでは、残りの3本のうちの1本が使えないのは辛いです。さらに、最近のグラフィックスカードは2スロット占有するので、グラフィックスカードの搭載比率が高いHackintoshでは、空きスロットが1本になってしまいます。これにWiFi/Bluetoothカードを挿したらもう空きはありません。ということでmacOSを使うなら\n16, 1, 1, 16 の構成のマザーボードが良いと思います。これなら2本占有グラフィックスカード、WiFi/Bluetoothカードを挿しても、まだ1本の空きがあります。グラフィックスカードを2枚挿しする以外に、8レーンのPCIeを2スロット必要とする用途は今の所まず無いと思います。NVMe SSDカードでも8レーンの速度が必要な製品は無いです。ということで、macOS用にZ390 Micro-ATXマザーボードを選ぶなら、以下から選ぶのが良いと思います。\n","date":"2018-12-01T14:32:31+09:00","image":"/uploads/2018/11/2000px-PCI_Express.svg_.png","permalink":"/posts/702/","title":"Z390 m-ATXマザボのPCIe"},{"content":"AMDの新しいグラフィックスカードRX 590が発売されました。試してくれた皆さんの情報によると、これもRX 570/580と同様に、OOB（箱から出してそのまま）で動くらしいです。動いたという2報の報告は10.14.2βのようです。10.14.1で試したけど動かなかったという報告もあるので、10.14.2からのサポートなのかもしれません。\nVendor IDは0x1002 (これはAMDのIDです), Device IDは0x67dfだそうで、RX 580と全く同じです。ただ, Revision IDが0x00e1だそうです(RX 580は0x00e7)。なので同じデバイスのバージョン違いと認識されて動いているようです。「このMacについて」の表記は、Radeon RX 590ではなくて、Radeon Polarisになるようです。性能はというと、\nGeekBenchのOpenCLのスコアは144782だそうです。ちなみに手元のRX 580で試すと145563でした。違いはないですね。 Unigine ValleyのExtreme HDは51.4fps/2149Scoreだそうです。手元の580 では47.3fps/1981Scoreでした。こちらはかなり改善されているようです。 ジサトラKTU #84 ～Polaris 30ことRadeon RX 590はフルHDゲーマーを導く星になれる\u0026hellip;\nジサトラKTUのビデオで590のわかりやすい解説とベンチマークテスト結果が紹介されています。580との違いは、\nプロセスルールがシュリンクした (14nm→12nm) クロックが上がった (1340MHz→1545MHz) 消費電力が上がった (185W→225W) ことのようです。こちらのビデオでは、クロックが上がった分の高速化は確認できているようです。 将来のサポートeGPUに590が追加されるのはおそらく間違いないですから、今後のmacOS更新で性能が生かされるようになると思います。なかなかWeb driverが提供されないのでAMDに移行しようと考えているNVIDIAユーザの人には良い候補かもしれません。\n","date":"2018-11-25T15:24:07+09:00","image":"/uploads/2018/11/590.png","permalink":"/posts/663/","title":"AMD Radeon RX 590が10.14.2βで動く"},{"content":"SMCとは何か？ SMC (System Management Controller) はIntel版Macに搭載されたサブシステムです。小さなコンピュータチップですね。Intel版になる前にもこのようなサブシステムは存在していて、SMU (System Management Unit)とかPMU (Power Management Unit)などと呼ばれていたようです。SMCは、メインのIntel CPUとは独立して動いて、次のような仕事を担当しています。\n温度と電力のモニターと制御 バッテリー充電 ビデオモードの切り替え スリープ、wake, ハイバネーション、LED表示 ちなみに最近のMacに搭載されているApple T2セキュリティチップは、SMCも内蔵しているらしいです。\nSMCのふりをするFakeSMC.kext 一般的なATXマザーボードにはSMCは搭載されていません。SMCは独立したサブシステムですが、OSからアクセスすることもあるので、SMCが無いとmacOSが起動しません。FakeSMC.kextは、名前の通り、SMCがあるかのように振舞ってくれるkextです。macOSを起動するために唯一必須のkextなのです。\nまた上述のように、SMCには温度をセンシングして冷却コントロールする機能もあります。FakeSMCはこれらの機能も提供するので、連携するアプリケーションを使用することで、コンピュータの温度やファン回転数を知ることもできます。\n新登場のVirtualSMC FakeSMCと同じ機能を実現するために、最近VirtualSMCというkextが登場しているようです。最初のリリースは今年(2018)の9月12日です。出たばかりです。\nGitHub - acidanthera/VirtualSMC: SMC emulator layer\ngithubのページには、特徴として以下のことが書かれています。\nmacOS 10.8 以降をサポート（10.9 以降を推奨） MMIOプロトコルと割り込み応答により最近のOSとの互換性を確保（MMIOってメモリマップドIOのことかなぁ？） キー割り当てとR/W保護を正しく報告 機種に合わせたチューニングとSMCバージョンを提供 センサとキーのためのプラグイン拡張可能 smcdebug=xxブートオプションをサポート 本物のSMCが見つかったらそれを置き換える（本物のMacのSMCを置き換える目的でも使用できる） 全機能を発揮するにはLilu.kextが必要 だそうです。redditでも紹介されて、FakeSMCとVirtualSMCの比較が書かれていました。\nr/hackintosh - FakeSMC vs VirtualSMC\nredditの達人達の評価によると、\nFakeSMCは歴史もあって安定していてちゃんと動く FakeSMCはハードウェアモニタ機能が充実しているので、それを使いたい場合には引き続き使用すべき VirtualSMCは新しい設計に基づいてより厳密なエミュレーションを目指している。性能やデバッグで有利なので、将来性がある。 ということです。安定性を求めるなら定評のあるFakeSMCを使い続けて、新しいものに興味があるならVirtualSMCを使ったら良いのではということでした。ChameleonがCloverに置き換わった時も、こんな感じの評判でしたので、将来はVirtualSMCに置き換わっていくと思われます。\nVirtualSMCを使ってみた そこで早速使ってみました。githubからダウンロードしてmakeするのは面倒なので、コンパイル済みを探します。そこで、最近お世話になっているKext Updater.appを使いました。\nワンクリックで最新kextに〜Kext Updater.app (Ver. 2)\nここで、Load Single Kextを選ぶと、VirtualSMCをダウンロードできます。\nこうして入手したVirtualSMC.kextをFakeSMC.kextと置き換えてみました。\n入れた場所は、ESPの中です。ドキドキしながら再起動したところ、無事、ブートできました。最初の起動には少し時間がかかった気がしましたが、２回目以降の起動はFakeSMCの時よりも早くなったような気がしました。ただし気のせいかもしれません。FakeSMCと同じく、問題なく動く様子ですので、新しい物好きとしてはVirtualSMCを使っていきたいと思います。\nダウンロードしたファイルには、VirtualSMC.kext本体の他に、センサー関係のkextらしきものがいくつか入っています。\n今回は、一つもインストールしませんでしたが、そのうち調査したいと思います。\n蛇足：両方使うとどうなる？ 試しているうちに、うっかりFakeSMCとVirtualSMCを両方使ってしまった期間がありました。気づかず使っていたのですが、手元の環境では、macOSを終了しても電源が切れずにまた起動するようです。気づいて片方のみにしたら、正常に戻りました。両方使う意味はないですし他にも副作用が出ると思いますのでご注意ください。\n","date":"2018-11-23T00:12:56+09:00","image":"/uploads/2018/11/20181122224250.png","permalink":"/posts/654/","title":"VirtualSMC: もう1つのFakeSMC"},{"content":"NVRAMは不揮発性メモリの意味で、電源を落としても記憶が消えないメモリーのことです。マザーボード上にもありボタン電池などでバックアップされています。コンピュータ機器では、音量とか起動ディスクなどの情報が記憶されています。昔のMacではPRAM (パラメータRAM) と呼ばれていたこともありますが、NVRAMと同じものです。\n本物のMacのハードウェアにも、ATXマザーボード上にも、どちらにもNVRAMはあります。しかしHackintoshでは、macOSからATXマザーボード上のNVRAMがうまく読めないこともあるようです。\nそこで使われるのがEmuVariableUefi-64.efiです。Cloverのdrivers64UEFIフォルダに入れておくと、NVRAMのふり（エミュレーション）をしてくれます。NVRAMが覚えておくべき情報を、おそらくSSD/HDDなどの上で記憶しておいてくるのだと思います。マザーボード上のNVRAMがmacOSから利用できていればEmuVariableUefi-64.efiは不要です（あっても構わないです）。利用できていなければ、後述するNvidia Webドライバの利用などで必要になります。\nNVRAMの内容を見る NVRAMはterminalからnvramコマンドで読み書きできます。man nvramとすると使い方が表示されます。それを見ると：\nnvram [ -p ] [ -f filename ] [ -d name ] [ -c ] [ name [= value ]] ... OPTIONS -d name Deletes the named firmware variable. -f filename Set firmware variables from a text file. The file must be a list of \u0026#34;name value\u0026#34; statements. The first space on each line is taken to be the separator between \u0026#34;name\u0026#34; and \u0026#34;value\u0026#34;. If the last character of a line is \\, the value extends to the next line. -x Use XML format for reading and writing variables. This option must be used before the -p or -f options, since arguments are processed in order. -c Delete all of the firmware variables. -p Print all of the firmware variables. のように、いろいろなことができるようです。例えば-pxオプションでNVRAMの内容をXML風に見ることができます。長いのでlessにパイプすれば、スクロールや検索もできて便利かもしれません。\nnvram -xp | less -xpオプションでわかるように、NVRAMにはキーとデータの対でデータが保存されています。Hackintoshで重要なキーの一つがNVIDIAのWebドライバを使うかどうかを記憶するキー、nvda_drvです。Webドライバが機能しているならば、以下のコマンド\nnvram nvda_drv で1%00というデータが返ってくるはずです。16進数で表すと0x3100というデータで、アスキーコードの1と、数値のゼロの2バイトです。C言語などの文字列は、文字列の最後を0x00で表しますので、1を表す文字列だと思われます。使用中ということでtrueを表す1になっていると思われます。このキーが無い場合はドライバが動かないため、低解像度表示になったり、画面表示されない可能性もあります。\nNVRAMの機能を確認する NVRAMが機能しているかどうかを確認するためには、適当なキー・データ対を作って電源を切っても保存されているかどうか調べれば良いです。例えば、\nsudo nvram hogehoge=HelloWorld とすると、hogehogeというなんの意味もないキーが作られて、それにHelloWorldという文字が割り当てられます。\nnvram hogehoge で確認することができます。ここで、マシンを再起動してもこのデータが残っていればNVRAMが働いていることになります。確認ができたら、以下のようにして消しておきます。\nsudo nvram -d hogehoge 手元の3台のマシンで調べたところ、2台はNVRAMを保持してくれていました。hogehogeも残っていました。一方で、1台はNVRAMが消えてしまいました。hogehogeが消えるだけではなく、nvramコマンドが返してくれるキーの数も6個しかありません。\nnvram -xp | grep key \u0026lt;key\u0026gt;EFIBluetoothDelay\u0026lt;/key\u0026gt; \u0026lt;key\u0026gt;LocationServicesEnabled\u0026lt;/key\u0026gt; \u0026lt;key\u0026gt;SystemAudioVolume\u0026lt;/key\u0026gt; \u0026lt;key\u0026gt;SystemAudioVolumeDB\u0026lt;/key\u0026gt; \u0026lt;key\u0026gt;bluetoothActiveControllerInfo\u0026lt;/key\u0026gt; \u0026lt;key\u0026gt;bluetoothInternalControllerInfo\u0026lt;/key\u0026gt; NVRAMが消えてしまうマシンでも、EmuVariableUefi-64.efiを入れておけば、NVRAMが消えなくなります。\n","date":"2018-11-15T19:20:52+09:00","image":"/uploads/2018/11/20181115191339.png","permalink":"/posts/20/","title":"NVRAMのエミュレーション"},{"content":"これはMojaveでNvidiaのドライバを動かす方法ではありません。Mojave対応ドライバが待ち望まれている時節柄紛らわしい記事ですみません。この方法でWebドライバがMojaveで動かなくはないらしいですが、性能が全く出ないらしいです。\n経緯 MojaveではNvidiaドライバが動かないので、Nvidiaを搭載したマシンはHigh Sierraで使っていました。先日、それにうっかりPublic Beta版のセキュリティアップデートを当ててしまいました。これです。\n通常版のアップデートだと勘違いしました。ベータ版配布をoffにしておくべきでした。\nもうmacOSベータ版は要らないと思ったあなたに\nアップデートしたことでmacOSのビルドが上がりました。17G4005です。\n配布されているWebドライバの最新版は17G3025用なのでバージョンチェックで動かなくなってしまいました。そこで、17G3025用のドライバを、無理やり17G4005にインストールして動かすことにしました。\nバージョン違いのドライバをインストールする 17G3025用のドライバ（こんなアイコンです）\nをダウンロードサイト\nNVIDIA DRIVERS Quadro \u0026amp; GeForce macOS Driver Release 387.10.10.10.40.108\nから入手しても、バージョンが違うと、そもそもインストールできません。そこで17G3025用ドライバのパッケージを開いて、設定を変更します。まずは、パッケージユーティリティを使って展開します。\npkgutil --expand (pkgへのパス) (展開先ディレクトリ) 例えば\npkgutil --expand WebDriver-387.10.10.10.40.108.pkg exp とします。こうするとexpというディレクトリに内容が展開されます。この中に、Distributionという名前のテキストファイルがあります。これを開いて、インストールチェックをしているところ\nfunction InstallationCheck() { if (!validateSoftware()) return false; return true; } をコメントアウトします。\nfunction InstallationCheck() { //if (!validateSoftware()) return false; return true; } もしくは、後ろの方にvalidateSoftware()関数の定義がありますので、そこのビルド番号を書き換えても良いです。つまり、\nfunction validateSoftware() { var supportedOSVer = \u0026#34;10.13.6\u0026#34;; var supportedOSBuildVer = \u0026#34;17G3025\u0026#34;; というところを、\nfunction validateSoftware() { var supportedOSVer = \u0026#34;10.13.6\u0026#34;; var supportedOSBuildVer = \u0026#34;17G4005\u0026#34;; とします。\n次に、以下のコマンドでパッケージし直します。\npkgutil --flatten exp webdriver.pkg これは上の例でexpという名前のフォルダを作った場合です。このパッケージを使ってWebドライバをインストールします。\nバージョン違いのドライバを動かす インストールはできましたが、バージョンが合わないのでドライバが動きません。Not compatibleというメッセージが出てしまいます。そこでパッチを当てます。\nドライバにパッチを当てるためのスクリプトが、benjamin.dobellさんによって配布されています。以下のコマンドで入手できます。\ncurl -O https://raw.githubusercontent.com/Benjamin-Dobell/nvidia-update/master/nvidia-update.sh こうしてできたnvidia-update.shを実行可能にして起動します。\nchmod a+x nvidia-update.sh ./nvidia-update.sh 最初の質問（ダウンロードするか？）にはN、次の質問（パッチを当てるか？）にはYとタイプします。そして再起動します。無事動くようになりました。\nここまで、SIPは有効のままでも問題なく作業を進められました。\n","date":"2018-11-09T00:30:00+09:00","image":"/uploads/2018/11/20181106231456-300x221.png","permalink":"/posts/22/","title":"バージョンを誤魔化してNVIDIAドライバを入れる"},{"content":"Mac miniが4年ぶりにリニューアルされて話題になっています。Apple社はディスプレイなしのデスクトップMacなどにもはや興味がないのではと思っていました。特にローコストのminiは見捨てられているのだと感じていました。なので、今回の新製品は意外でした。素晴らしいです。\nCPUはモバイル用のBモデル 一番素晴らしいことはCPUがデスクトップに匹敵するCPUになったと言われていることです。従来のminiはひ弱なモバイル用CPUを搭載していたのが残念に感じていました。重量やサイズの制約がないデスクトップなら、性能を追求して欲しいと思っていました。\nCPUはインテルの第８世代CPUと言われています。型番が8000番台のCPUです。製品が出回ればすぐに明らかになると思いますが、実際にどの型番なのかは今現在では明らかになっていません。でもおそらく8100, 8500, 8700ではないかと思われます。というのは３モデルの仕様が、インテルの仕様に合致しているからです。公式サイトで紹介されている仕様は以下です。\nmini i3 4コア mini i5 6コア mini i7 6コア 動作周波数 3.6GHz 2.8GHz 3.2GHz Turbo Boost 記載無し 4.1GHz 4.6GHz L3キャッシュ 6MB 9MB 12MB これに対して、8100, 8500, 8700の仕様は以下です。\nCore i3 8100 Core i5-8500 Core i7-8700 Core/TH 4/4 6/6 6/12 動作周波数 3.6GHz 2.8GHz 3.2GHz Turbo Boost 非対応 4.1GHz 4.6GHz L3キャッシュ 6MB 9MB 12MB TDP 65W 65W 65W 完全に一致しているので、ほぼ間違いないと思います。いずれもTDPが65Wなので、miniの筐体に入ると思われます。\nただし、通常の自作PC用に販売されているデスクトップ用の8100, 8500, 8700ではないと思われます。実は、本年４月に、Intelがデスクトップ版Core i7-8700と同仕様の8700Bを投入したというニュースがありました。\nIntel、デスクトップ版Core i7-8700と同仕様の8700Bをモバイル向けに投入\nBモデルは、デスクトップ用無印CPUと同じスペックのようです。ただ、パッケージがデスクトップ向けのLGA1151ではなく、モバイル向けのHプロセッサと同じFCBGA1440となっています。8700Bについてはこちらのサイトで詳細が紹介されています。\nCore i7-8700B – Intel – WikiChip\nCPUの形状はこんな感じです。\nこの記事の冒頭にある、アップル公式サイトの写真とそっくりです。なので2018 miniのCPUは8100B, 8500B, 8700Bだと思われます。\n自作PCで使う現行インテルCPUはマザボとの接続がLGAです。ランドグリッドアレイという名前で、CPUの底にランドと呼ばれる楕円の電極パターンが印刷されています。マザボのソケットのピンがランドに接して接続されます。ソケットを使用することを前提とした構造です。これに対してminiで使われるBモデルはBGAだそうです。Bはボールで、接点部分にハンダボールが付いています。マザボ上の接点パターンに乗せて炉で加熱してハンダ付けします。なのでiMacのように簡単にCPU交換する事は出来ないでしょう。\n今のタイミングなら、9000番台の第９世代CPUで作って欲しかった気もします。とはいえ、第８世代デスクトップ用CPUがmacOSで正式サポートされたことで、同じCPUを使っているHackintoshの安定性がさらに向上するものと思います。\nチップセット iFixItで分解されたところによるとチップセットはCM246というもののようです。CM246はCoffee Lake用のモバイル版チップセットで、H370/Z390などと同様にUSB 3.1 Gen 2と無線機能も搭載している様子です。これらがmacOSでサポートされていれば、H370/Z390搭載マザーボードでの自作が楽になると期待できます。\nでも、新しいMac miniの「システム情報」を見ると、macOSではチップセットの無線機能を使わずに、従来通りBroadcom互換チップを使っているようです。こちらの記事に、システム情報のスクリーンショットが紹介されています。\n一方でUSB 3.1 Gen 2の方は、インテル製コントローラをmacOSが使用しているようです。店頭にあった新Mac miniの「システム情報」を見たところ、USB 3.1バスのホストコントローラの記載に、PCI製造元IDが0x8086とありました。8086は、インテルの有名な初代16bit CPUの型番ですが、インテルのID番号にもなっています。インテル製ということです。ちなみに今までのmacOSではASMediaのコントローラを使っていましたので、PCI製造元IDはASMedia Technology Inc.のIDである0x1b21でした。インテルチップセットのUSB 3.1 Gen 2にmacOSのドライバが対応したと思われます。\n省電力・iGPU Hackintoshは無用 今回のminiはピンは半田付けBGA方式のモバイル版ではありますが、中身はデスクトップ用と同等のCore i3 CPUを初めて搭載しています。CPU内蔵のiGPUだけを使って、省スペースで強力なHackintoshを作る必要性がなくなりました。グラフィクスカードを搭載しないMini ITXやMINI STX型小型Hackintoshはもはや不要です。本物のMac miniを買えば、デスクトップCPU搭載macOSマシンが手頃な価格で入手できるからです。もともとApple社が欲しいMacを作ってくれないので自作Hackintoshを始めたので、今回のMac miniが出て、Hackintoshが不要になることは嬉しい限りです。モバイル用省電力CPUではなくなったので、省電力を目指してi3 NUCでHackintoshする価値はまだあるかもしれません。\n一方で、グラフィックスカードを搭載した重量級デスクトップHackintoshはまだまだ必要です。強力なグラフィックス性能が必要ならば、Thunderbolt経由の外部GPUボックスを使って欲しいというのがAppleの方針かと思います。でもThunderboltはPCIe x 4なので、フルサイズPCIe x 16に比べると接続ケーブルがボトルネックになります。ジサトラKTUのベンチマークテストでもかなりの差が出ています。\nyoutu.be\n小型軽量が重要なモバイル機器ならThunderboltで拡張する意義はありますが、デスクトップではせっかくのGPUがもったいないと感じます。来年発表されると噂の「モジュラー型」Mac Proで、タワー型デスクトップHackintoshも無用の存在にして欲しいと願っています。\n","date":"2018-11-02T00:30:00+09:00","image":"/uploads/2018/11/20181101193214-300x300.png","permalink":"/posts/24/","title":"2018 Mac miniはすごい"},{"content":"MojaveではAMD Radeon RX570 RX580などがOOBでほぼ問題なく動きます。でも多少の不具合はあります。それをメモしておきたいと思います。以下では、CPU内蔵GPUをiGPU, 内蔵ではないGPUをdGPU, Thunderbolt拡張ボックスで増設するGPUをeGPUと書くことにします。\nGeekBenchの性能低下は解決 BIOSでiGPUを機能させないように設定すると、しばらく使っているうちにGeekBenchのOpenCLスコアが下がってしまう問題がHigh Sierraではありました。この問題はMojaveになってから解決したようです。iGPUはoffのままでも、性能低下は発生しないようです。\nSafariでAmazonの動画が見られない BIOSでiGPUが機能するように設定すると、なぜかSafariでAmazon動画が見られません。謎です。Google Chromeなどでは見られます。表示が出ない・乱れるという訳ではなく、「再生エラー」というダイアログがAmazonから出されるので、デジタル著作権保護に関する問題かもしれません。もしかしたら、実機のeGPUでも同様の症状が発生するのかもしれません。またAmazon以外でも動画再生に問題が発生するのかもしれません。でもSafari以外のブラウザを使えばokなので大した問題ではないです。~~BIOSでiGPUを機能させない設定にすれば、SafariでもAmazon動画が再生されます。~~BIOSでiGPUを機能させない設定にすると、今度はSafariで「プラグインが見つかりません」というエラーメッセージが出ます（10.14.1で確認)。\nJPEGファイルがクイックルックできない BIOSでiGPUを機能させないように設定すると、JPEGファイルのクイックルックができません。プレビュー.appでもJPEGファイルを開くことができません。レインボーカーソルが出て止まってしまいます。JPEGの展開にiGPUの機能を使っているためこうなるようです。これはかなり不便です。この問題はNVIDIAのグラフィックスカードでも発生するようです。この問題の解決策として以下の３通りが知られています。\nBIOSでiGPUが機能するように設定します。ただし、上の、SafariでAmazon動画が再生されない問題が発生します。 同系統のdGPUを搭載しているMacの機種IDになるように、config.plistのSMBIOS設定を変更します。ただしCPUやチップセットが違う機種に設定することになりうるので、動作が不完全になる可能性があります。あまりお勧めできません。 NoVPAJpeg.kextをLilu.kextと一緒に使います。これを使えば、iGPUがoffでもJPEGファイルクイックルックの問題が発生しません。 www.insanelymac.com\nということで、３番目の方法であるNoVPAJpeg.kextを使えばすべて解決するようです。でも、実のところ私はiGPUを機能させる設定でしばらく使うことにしました。せっかく搭載されているのにiGPUを使わないのはもったいない気がするからです。SafariでAmazon動画を見なければ良いだけですので。\n今回紹介した問題は、iGPU, dGPUの切り替えがうまくいっていないことで発生しているように思います。実機でも、GPU切り替えが原因のトラブルが時々話題になっています。Hackintoshの問題ではなくて、どちらかというとmacOSの問題のような気がします。eGPUを公式サポートするようになったのは最近のことなので、今はあまり気にしなくても将来のmacOSで改善されると期待しています。\n追記：NoVPAJpeg.kextについて NoVPAJpeg.kextはWhateverGreen.kextに統合されたようです。\n今後はWhateverGreen.kextだけで問題が解決するようです。ただ、それでもJPEGファイルのクイックルックが動かない場合は、ブートオプションに以下を追加すれば良いようです。\nshikigva=32 shiki-id=Mac-7BA5B2D9E42DDD94 ","date":"2018-10-27T00:30:00+09:00","image":"/uploads/2018/10/20180929094941-300x270.png","permalink":"/posts/25/","title":"MojaveでJPEGファイルが開けない"},{"content":"HFS+から大幅刷新されたAPFS (Apple File System)には色々便利な機能があります。今回は、Hackintoshライフに役立つAPFS Volume機能をご紹介します。\n（更新：Catalinaのことを追記しました。2020/3/3）\nHFS+のVolume HFS+でもAPFSでも、アプリケーションから見えるのは最終的にVolumeです。Volumeは物理的にはストレージの一部なのですが、アプリケーションからは\n/Volumes/ 以下にマウントされ、ディレクトリのように見えます。\n物理的なストレージからVolumeに至る階層構造を以下にまとめます。HFS+では、\n物理的なドライブ。物理的なSSDやHDDです。本当はファイルではないのですが、システムからは/dev/disk0のように見えます。ファイルのようにも見えますが、実際にはファイルではありません。ストレージの内容を読み書きするデバイスドライバへアクセスする場所として使われます。システムファイルとも呼ばれます。 物理的なパーティション。SSDやHDDを分割した領域です。これも/dev/disk0s1のようなスペシャルファイルとして現れます。 HFS+のVolume。パーティションに名前をつけてHFS+でフォーマットしたもの。/Volumes以下にその名前で現れます。一つのパーティションに一つのVolumeを作ります。 という構造になっています。2個の異なる物理ドライブの2つのパーティションを一つにみなす機能もあって、それでRAID 1ミラーリングやFusion Driveを実現しています。\nAPFSのVolume APFSではこの構造に、コンテナという要素が加わります。物理的なストレージからVolumeに至る階層構造はAPFSでは以下になります。物理的な構造であるドライブとパーティションはHFS+と同じです。\n物理的なドライブ 物理的なパーティション コンテナ。通常は1個のパーティションを1つのコンテナにします。2個のパーティションを1つのコンテナにするとFusion Driveになります。 APFSのVolume。コンテナの中にAPFSでフォーマットされたVolumeを作ります。これが/Volumes以下に現れます。容量はコンテナの容量と同じです。1つのコンテナを、複数のVolumeで共有することができます。複数Volumeの場合、容量はどれもコンテナの容量と同じですが、他のVolumeが領域を使用すると、その分空き領域が減ります。 High SierraやMojaveのインストーラはHFS+をAPFSに自動変換してしまいますが、そのとき、パーティション→Volumeの構造を、パーティション→コンテナ→Volumeに変換します。「コンテナが間に挟まってややこしくなってしまった」と感じていたのですが、実は便利だとわかりました。\nFusion Driveがコンテナの機能で実現されることは、以前の記事で紹介しました。\nAPFSに対応したFusion Driveを作る\n以下では、コンテナの中に複数のVolumeが作れる機能を利用して、Hackintoshの保守を簡単にする方法をご紹介します。\nHFS+で複数Volumeを使う HFS+以前は1パーティションが1 Volumeでした。\nHackintoshに限らないのですが、OSをインストールする際に、ストレージを用途ごとにパーティションに分け、別Volumeにする手法が一般的でした。LinuxなどのUnix系OSでは、システムが使用するルート/、利用者がファイルを置くホーム/home、一時ファイルが置かれる/tmpなどなどを、複数のドライブにまたがった複数のパーティションに割り当てます。ファイルシステムにトラブルがあってもパーティションごとに独立していれば被害は少ないし、パーティションごとにフォーマットし直したり、別のドライブに移動するのが容易だという理由です。\nそこまで細かく分けなくても、macOSでも、システムと/Users以下を別パーティションにしている人も多いと思います。分けておけば、macOSのメジャーアップデートの時に、システムパーティションをフォーマットして、綺麗さっぱりクリーンインストールすることも容易です（利用者データは別パーティションに残っていますから）。\n例えば、1TBのSSDがある場合、システムに120GB、/Usersに880GB割り当てたりします。でもmacOS Mojaveをインストールした直後のサイズは約13GBなので、この割り当てだと最初はシステムパーティションが勿体無いです。一方で、Xcodeなどのサイズの大きなアプリケーションをどんどんインストールしていくと、120GBでは苦しくなります。Disk Utility.appでパーティションサイズを変更できることになってはいます。ただ、制約が大きくて、変更できない状況がほとんどです。パーティションを分けるときに、割り当てサイズをどう決めるかは、いつもいつも難しい問題でした。\nAPFSで複数Volumeを使う例 APFSでは1パーティションが1コンテナになり、複数Volumeを作れます。\n先ほどの例に対して、今度はAPFSコンテナのVolume共有機能を活用します。1TBのSSDを買ってきたら、とりあえず全体をAPFSでフォーマットしてmacOSをインストールします。ここで出来上がったVolumeの名前を例えばmacOSとします。SSD全体に1つのパーティションができて、これに1つのVolumeができるので、サイズは1TBになります。/Volumes/macOSというようにマウントされます。\n次に、新しいVolumeを作って、そこにホームディレクトリを移動させてみましょう。デフォルトでは、/Users以下のアカウント名と同じディレクトリがホームディレクトリになっています。以下では、homeというVolumeを作ってその中にホームディレクトリを置くことにします。まず、Disk Utility.appを開いて、現在のコンテナを選択して、「パーティション作成…」ボタンを押します。すると以下の案内が出ます。\n1つのコンテナは1つのパーティションを占有し、コンテナ内のストレージ領域はコンテナ内の複数のAPFSボリュームで共有されます。APFSボリュームの追加や削除は、パーティションマップを編集するよりも簡単かつ高速に実行できます。\nここに書いてあるように、新しいVolumeを作るためには、“編集”メニューの“APFSボリュームを追加”コマンドを使用するか、ツールバーの“ボリュームを追加/削除”ボタンを使用しても良いです。本当はそちらの方法が正当で、このメッセージは従来のパーティション作成を試みようとしたユーザにAPFSへの移行を促す目的の案内なのだと思います。\nここで「ボリュームを追加」を選ぶと、このコンテナにVolumeを追加できます。homeという名前のVolumeを追加します。結果を以下に示します。「このMacについて」から見たいストレージの状況です。ここでお詫びです。ここまで1TBのSSDなどと豪勢なことを言っておりましたが、余分な1TB SSDを持っていなかったので打ち捨てられていた160GB HDDを使いました。\n/Volumes/macOSも/Volumes/homeも同じ容量であることがわかります。同じ1つのパーティションを共有しているためです。それぞれのVolumeで使った分だけ空き容量が同じように減っていきます。パーティションのサイズで悩む必要がなくなったのです。\nターミナルのdiskutil listコマンドで見ると、以下のようになります。\n$ diskutil list /dev/disk1 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *160.0 GB disk1 1: EFI EFI 209.7 MB disk1s1 2: Apple_APFS Container disk4 159.7 GB disk1s2 /dev/disk4 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +159.7 GB disk4 Physical Store disk1s2 1: APFS Volume macOS 13.3 GB disk4s1 2: APFS Volume home 57.6 MB disk4s2 3: APFS Volume Preboot 46.1 MB disk4s3 4: APFS Volume Recovery 512.4 MB disk4s4 5: APFS Volume VM 20.5 KB disk4s5 今回作成したコンテナの物理的な実体は、disk1s2にあります。コンテナの中には現在5個のVolumeができていて、コンテナ全体を共有しています。それぞれの使用量は、macOSが13.3GB（これがmacOS Mojaveの本体です）、homeが57.6MB（こちらは/Users以下のサイズです）などとなっています。\nこうして作った/Volumes/homeの中にホームディレクトリを移動するには以下のようにします。まずアカウント名と同じ名前で空のディレクトリを作ります。アカウント名が例えばhogeだったら /Volumes/home/hoge を作ります。次にシステム環境設定から「ユーザとグループ」を選び、ウィンドウ左からユーザhogeを選んで、右クリックで「詳細オプション」を選び、ホームディレクトリとして/Volumes/home/hogeを指定します。これで再起動すれば、このディレクトリがホームディレクトリになります。\nCatalinaからはmacOS本体の部分が二つに分割されるようになりました。macOSの基本部分は保護されてrootアカウントからも書き込み禁止になりました。別のボリュームの例ですが、以下のようになります。\n/dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +249.8 GB disk1 Physical Store disk0s2 1: APFS Volume Preboot 127.3 MB disk1s1 2: APFS Volume Recovery 1.0 GB disk1s2 3: APFS Volume VM 2.1 GB disk1s3 4: APFS Volume Macintosh HD - Data 41.7 GB disk1s4 5: APFS Volume Macintosh HD 11.6 GB disk1s5 ここで Macintosh HDと書かれた部分が保護されたエリアで、Macintosh HD – Dataがそれ以外の書き込み可能な部分です。/Users以下も通常はここに書き込まれます。\nOS切り替えにも複数Volumeが便利 APFS Volumeは、簡単に追加したり削除したりできます。ストレージの容量は実際に使用している分だけしか消費しません。Mojaveならたったの13GBです。なので、複数Volumeを用意して、複数のmacOSをインストールしておけば、以下のようなことが可能です。\n別バージョンのmacOSに切り替える。例えば別のVolumeにCatalina, Mojave, High Sierraをインストールしておく。 テストバージョンのmacOS、例えばCatalinaを別Volumeにインストールする。古いmacOSは残っていますから、不具合があったらすぐに戻れます。新OSのベータ版を試すような場合にも便利です。 メインで使うVolumeの他に、別 VolumeにもmacOSをインストールしておく。うっかり怪しいアプリやkextをインストールして起動できなくなった場合でも、バックアップから起動して、修正作業ができます。 などの使い方が考えられます。\nバニラなインストールをしておけば、macOSは通常のインストールで機能するので、管理が簡単です。\n/posts/131/\n不具合があっても別のVolumeのmacOSから起動できます。ただし、ESPの部分は同じものを使いますので、こちらもバックアップをしておくと安心です。\nESPをマウントしてついでにバックアップする\n","date":"2018-10-19T00:30:00+09:00","image":"/uploads/2018/10/20181008122822.png","permalink":"/posts/27/","title":"APFSのVolumeを活用する"},{"content":"Mojaveへの移行は基本的に簡単で、Cloverやkext類が最新なら何の問題もありません。ただ、一部の環境で、macOSインストーラが止まってしまうトラブルがあるようです。手元のマシンでも2台が止まってしまいました。どういうわけか不明です。インストーラの不具合ではないかという説もあります。ただ、世の中ではあまり話題になっていなくて、Hackintoshで主に発生しているようです。\n症状 macOS Mojaveインストール.appを起動して、インストールの準備は順調に進みます。その次、1回目の再起動が発生します。ここで、Boot macOS Install from xxxxというエントリーから再起動すればインストーラが立ち上がって問題なく次に進むはずです。\nしかしこの時に、「インストーラリソースが見つかりません。」と言われてインストーラが止まってしまうことがあります。再起動しても、またここで止まります。\n画面に表示されるメッセージは、日本語では、\nコンピュータにmacOSをインストールできませんでした\nインストーラリソースが見つかりません。\nインストーラを終了してコンピュータを再起動してからやり直してください。\nです。英語の環境でインストーラが立ち上がった場合には、\nmacOS could not be installed on your computer\nThe installer resources were not found.\nQuit the installer to restart your computer and try again.\nと表示されます。 句読点は表示のままです。\n発生する時は、上書きインストールでも、クリーンインストールでも発生します。ファイルシステムがAPFSでもHFS+でも発生します。\n解決策 このメッセージで検索しても事例はあまり見つかりません。それでもtonymacx86にはいくつかの報告と解決事例がありました。それによると、\nUSBに接続したSSDにインストールしようとしたらこうなったので、内部ドライブにインストールしたら成功した M.2に挿していたNVMeを外したらインストールできた などとありました。どうも、ストレージを複数接続している場合に発生しやすいようです。とは言え、手元のHDDを多数搭載したマシンでは問題ありませんので、数の問題ではないようです。\nいろいろ探していたら、まとめてあるページを発見しました。\n\u0026lsquo;macOS could not be installed on your computer\u0026rsquo; error when installi\u0026hellip;\n書いてある内容をまとめると、以下になります。\nSATAドライブだけの構成の場合は、インストール先以外の全てのドライブを取り外してインストールする M.2 NVMe SSDにインストールしているときは、M.2を外して、SATAドライブにインストールしてからコピーする どうもスッキリ解決というわけにはいかないようです。\nやってみた 手元で問題を起こしている1台のマシンはM.2 NVMe SSDを搭載しています。M.2 SSDにも、SATAのドライブにもどちらにインストールしようとしても、このエラーメッセージで止まってしまいます。上記のサイトのガイドでは実質的にお手上げのケースです。\nM.2 SSDを取り外すのが厄介でしたので、別のマシンで予備のSSDにインストールしました。32GBの2.5インチSSDを外付けUSBケースに入れて、MacBook Proに接続しました。インストール直後のMojaveの容量は14GB以下なので、16GBくらいのUSBメモリでも可能かもしれません。Mojaveインストーラを起動して、USB経由でインストールしました。\n2度再起動して、国名を選択する設定画面で、ちょっと乱暴でしたが、電源を切ってSSDをとりはずしました。これを、問題起こしているマシンのUSBに接続します。\nM.2 SSDはAPFSでしたのでボリューム作るのが簡単です。クリーンインストール用にボリューム作ります。先ほどのUSB SSDの内容を、新しく作ったボリュームにコピーすれば良いのです。\n上記のサイトでは、ここで使うツールとしてCarbon Copy Cloner (CCC)を一例にあげています。CCCに問題がある訳ではありませんが、出来るだけ素朴なツールを使いたい主義なので、まずはDisk Utility.appの復元をためしました。内部では多分ddコマンドが動いていると推測してます。でもエラーで止まってしまいました。\nそこでrsyncコマンドをつかってみました。上手くいきました。/Volumesに、コピー元がsource 、コピー先がtargetとマウントされている場合、以下のコマンドでコピー出来ます。\nsudo rsync -av /Volumes/source/ /Volumes/target/ 次に、M.2 SSDのこの新ボリュームから起動させたところ、インストールの続きが始まり、無事完了しました。\n手元でインストーラが止まっているもう一台のマシンにはmSATA SSDとSATAのHDDが接続されています。前述のサイトによると、こちらは使わないドライブを外すだけで良いようです。~~そのうち試して報告します。~~実際にやってみました。HDDを取り外して起動させたところ、このメッセージは出なくなり、無事インストールできました。\n","date":"2018-10-12T00:30:00+09:00","image":"/uploads/2018/10/20180929094941-300x270.png","permalink":"/posts/28/","title":"Mojaveの「インストーラリソースが見つかりません」問題"},{"content":"\n「コンピュータに問題が発生している可能性があることが検出されました」\nというダイアログパネルが先週唐突に現れました。Mojaveにアップデートしてからだいたい1週間目のことです。正確には604,800秒後のことです。\nAppleのサポートに公式の説明があります。\nsupport.apple.com\nこのメッセージは、Mac に実際にインストールされているファームウェアと、macOS で必要とされるファームウェアとの間に違いが認められた場合に表示されます。\n（略）\nmacOS High Sierra 10.13 から、Mac はファームウェアが変更されていないか定期的にチェックし、そうした変更点について Apple に情報を送信できるようになりました。\nそういえば1年以上前、High Sierraのベータ版が出た頃にこの新機能が話題になっていました。このチェックを定期的に行なっているのはeficheckというプログラムです。本体は、\n/usr/libexec/firmwarecheckers/eficheck/eficheck にあります。\nMacのEFIファームウェアのチェックサムを、Apple社の何処かにあるデータベースと比較して、違っている場合には安定性やセキュリティに問題があると判断して、警告を出してくれるプログラムだそうです。Hackintoshの場合は、当然のことながらEFIファームウェアは本物のMacと違うので、警告出まくりになるだろうと、当時は話題になっていました。でも一度も警告は出たことがなく、すっかり忘れていました。ネットで調べても、警告が出たという報告はすごく少ないです。私も初めてです。なんで出たのか不明ですが、Mojaveにアップデートしたことと関係がありそうです。\neficheckの動く仕組み eficheckはコンピュータに常駐して動き続けるデーモンと呼ばれるタイプのプログラムです。macOSではデーモンの起動と設定を、\n/System/Library/LaunchDaemons/ ディレクトリで行います。この中に一つのデーモンを設定する.plistファイルを置くと、Macの起動時に動くようになります。今回のeficheckを設定しているのは、\n/System/Library/LaunchDaemons/com.apple.driver.eficheck.plist というファイルです。書き換えて遊んでみましょう。\nただ、SIPを有効にしている場合、/System以下のファイルはSIPで保護されています。sudoコマンドでも書き換えることができません。その場合は、SIPを無効にしてから作業します。書き換え作業した後はSIPを有効に戻しても大丈夫です。\n/posts/132/\ncom.apple.driver.eficheck.plistの中身を見てみましょう。以下は抜粋です。\n\u0026lt;key\u0026gt;ProgramArguments\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;string\u0026gt;/usr/libexec/firmwarecheckers/eficheck/eficheck\u0026lt;/string\u0026gt; \u0026lt;string\u0026gt;--integrity-check-daemon\u0026lt;/string\u0026gt; \u0026lt;/array\u0026gt; 略 \u0026lt;key\u0026gt;com.apple.driver.eficheck\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Interval\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;604800\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; 最初の方に、eficheckへのフルパスと、起動の引数が書かれています。真ん中あたりに、間隔が604,800と書かれています。単位は秒です。割り算してみると、ちょうど7日間になります。つまり、1週間ごとにEFIが正しいものであるかどうかをチェックして、警告を出してくれるようです。\n1週間待って次の警告が出るかどうか確認するのは大変でしたので、\n\u0026lt;key\u0026gt;com.apple.driver.eficheck\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Interval\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;180\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; と書き換えて再起動してみました。3分くらいで警告が出ました。やはりこのまま毎週警告が出てしまうようです。\neficheckを止める なんにせよ厄介なので、起動しないようにしてみました。\ncd /System/Library/LaunchDaemons/ sudo mv com.apple.driver.eficheck.plist com.apple.driver.eficheck.plist.org としました。オリジナルというつもりでorgという拡張子に変更しましたが、oldでもbackupでもなんでも好きな名前で良いです。いずれにせよ、plistという拡張子ではなくなったので、多分大丈夫なはずです。結果は来週以降報告します。 plistという拡張子ではなくなったことで起動しなくなります。１週間後、２週間後にも起動しませんでした。\nEFICheckDisabler.kextを使う コメントで紹介していただいた\nwww.insanelymac.com\nでRehabManさんが配布しているEFICheckDisabler.kextを使ってみました。これをESPに入れるだけでも、エラーメッセージは止まりました。\nメッセージが出ないこともある 原因は不明ですが、このエラーメッセージが一向に出ないマシンもあります。何が違うのかよくわからないのですが（ご存知でしたらコメントでお知らせください）、メッセージが出ないなら、上記の対応をしなくても良いと思います。\n追記：いつからかこの問題は発生しなくなりました。少なくともCatalinaでは経験していません。なので古い情報です。(2020/3)\n","date":"2018-10-07T15:55:55+09:00","image":"/uploads/2018/10/20181007151835.png","permalink":"/posts/30/","title":"eficheckにファームウェアが違うと注意されました"},{"content":" 火曜日にmacOS Mojaveが公開されました。Hackintoshをアップデートする時間がなかなか取れなかったのですが、ようやく作業できました。結論としては、ベータ版で確認されていた通りで、今回のアップデートには難しいところは全くありません。\n上書きアップデート編 macOSアップデートの一番お手軽な方法は、App Storeからダウンロードして、そのままアップデートする方法です。環境設定も、インストールしたアプリケーションも、ユーザ設定もデータも全部そのまま引き継げますので簡単です。今回のアップデートは、OSの根本に大きな変化が少ないので、上書きアップデートができそうです。今回は、High Sierraが動いている初代NUC, DC3217IYEで試してみました。Ivy Bridgeマシンなので、なんとかギリギリでMojaveに対応しています。\nNUCで作る超小型macOSマシン\nClover, KEXTをアップデートしておく macOSのアップデートが簡単になった舞台裏では、Hackintosh開発者の皆さんの努力があります。ベータ版を元に不具合検証して、多数のアップデートが施されています。感謝です。なのでmacOSアップデート前に、最新版にアップデートしておきましょう。\n現時点でのCloverの最新版リビジョンは4674です。古いようでしたらアップデートしておきます。\nKext類のアップデートにはKext Updater.appが便利です。起動すると、Kext Updaterそのものがアップデートされることもあります。最新版kextに関するデータベースが更新されるのだと思いますので、これもやっておきます。\nワンクリックで最新kextに〜Kext Updater.app (Ver. 2)\nアップデートしたら、もう一度Kext Updaterで最新になっていることを確認しても良いです。ただ、再起動を行わないと、新しいClover, Kextが機能しませんので、再起動してから確認します。\nKextをMojaveの場所に複製する もしKext類をEFI/CLOVER/kexts/10.13/に入れているようでしたら、同じ内容をEFI/CLOVER/kexts/10.14/にもコピーしておきます。これを忘れるとMojaveが起動しません。当たり前のことですがうっかり忘れて慌てた経験が複数回あります。\nそういう可能性をなくすために、EFI/CLOVER/kexts/Other/にKextを入れておくのも良いかと思います。CloverはOtherの場所のkextを読み込んだ後で、10.14などの場所のkext類を読み込みます。同じkextがOtherとバージョン番号のフォルダの両方に存在しても、片方しか動かないので問題ありませんが、無駄なのでどちらか片方だけに入れておくのが良いです。\nApp StoreからMojaveをダウンロードする App Storeに行くと、今ならバナー広告でmacOS Mojaveが絶賛宣伝中になっている思います。ダウンロードボタンを押してダウンロードします。6.03GBあります。\nダウンロードが終了すると、自動的に起動してインストーラが起動します。これは一旦終了して（しなくても良いですが）、アプリケーションフォルダを見てください。macOS Mojaveインストール.appというアプリケーションがありますので、これをどこかに複製して保存しておきます。バックアップしておかないと、インストール後に消えてしまうことがあります。せっかく時間をかけてダウンロードしたのですから、バックアップしておきましょう。\nインストーラを起動する macOS Mojaveインストール.appを起動すると以下のウィンドウが現れます。\n「続ける」をクリックして、あとは指示に従ってどんどんインストールして行くだけです。\nインストール途中で再起動する場面があります。この時、「Boot macOS Install from xxxx」という項目が作られていて、それから起動するようになっているはずです。xxxxの部分は、アップデートしようとしているパーティションの名前です。\n以上の結果、無事アップデートできました。App Storeからのダウンロードによる上書きアップデートで問題なくMojaveに移行できることが確認できました。\nクリーンインストール編 クリーンインストールも試してみました。問題ありません。こちらはタワー型デスクトップのHackintoshで試しました。HDDを多数搭載していて、予備のHDDにもmacOSとCloverがインストールしてあります。\n作業の前に、メインのドライブと予備のドライブのESPに入っているCloverとkextを最新版にしておきます。メインのドライブのESPだけを使って以下の作業を行うことは可能ですが、将来、サブのESPを使うことも考えて、ついでにアップデートしておきました。\n次に、予備のmacOSで起動して、メインで使っているシステムの入ったパーティションをAPFSでフォーマットしてしまいます。そしてmacOS Mojaveインストール.appを起動し、空になったパーティションにインストールしました。この場合も、インストール途中で1回再起動しますので、Boot macOS Install from …の項目から再起動します。\n広告\n","date":"2018-09-29T11:32:52+09:00","image":"/uploads/2018/09/20180929094638-300x76.png","permalink":"/posts/32/","title":"Mojaveにアップデート"},{"content":"Mojaveは9月25日に登場 今朝未明のキーノートは、いつもの秋のイベント同様にiPhoneメインで、ささやかに期待された新型Macの情報は皆無で寂しい限りです。ただ最後の3分を切ったところで、macOS Mojave配布日が発表されました。日本時間で9月25日だそうです。あと12日ですね。それまでのあなたのHackintoshに新バージョンをお迎えする準備をしておきましょう。（去年の状況と同じですね😀あと13日！High Sierraのお迎え準備）\n以下はMojaveのベータ版での情報ですが正式版Mojaveでも同様と思われます。\nHigh Sierraからのアップデートは簡単 今現在HackintoshをHigh Sierraで動かしているならアップデートは簡単です。Cloverとkext類を最新にしておけばokです。High Sierraへの移行では、APFS起動に伴いファームウェアアップデートされ、多少の対応が必要でしたが、今回はそれも不要です。\nなお、Kext Updater.appを使うと、使用中のkextの最新版をチェックして、ダウンロードしてくれるので楽です。\nワンクリックで最新kextに〜Kext Updater.app (Ver. 2)\nMojave移行の注意 Cloverなどを最新版にしておく以外にほとんど問題はないはずです。それでもありえそうな注意事項を列挙して見ます。\nkextの格納場所 kextをEFI/CLOVER/kexts/10.13に入れている人は、10.14を新たに作って、全部のkextをコピーしておきます。もしくは、Otherフォルダにコピーしておいても良いです。10.14で起動する場合は、Otherの内容が先に読み込まれ、次に10.14フォルダが読み込まれます。10.13のフォルダの内容は無視されてしまいます。当たり前のことですが、うっかりして失敗した経験が何度かあります。\nAPFS High SierraのインストールではAPFSを使わない選択肢がありました。でもMojaveからは必須になったようです。システムドライブをまだHFS+で運用している人は、対応が必要かと思います。ファイルシステムの移行は大事なので、APFS移行でも問題が発生するのではという懸念がありました。しかし、APFS移行問題は、実機でもHackintoshでもほとんど報告されていません。円滑に移行できていると思われます。\nHigh Sierraが出た頃は、macOSからapfs.efiをESPにコピーしていました。その後公開されたApfsDriverLoader-64.efiを入れておけば、macOSに含まれる最新のapfs.efiを使ってくれるようになります。\nClover 4558で登場したApfsDriverLoader.efi\nMojave非対応Mac 公式サイトの情報によるとMojave対応機種は以下です。\nMacBook (Early 2015 以降) MacBook Air (Mid 2012 以降) MacBook Pro (Mid 2012 以降) Mac mini (Late 2012 以降) iMac (Late 2012 以降) iMac Pro (全モデル) Mac Pro ( Mid 2010, Mid 2012, Late 2013) CPU世代でいうとSandybridge以前が非対応になりました。これ以外の機種名をconfig.plistで設定しているHackintoshでは、起動時に禁止マークが出て止まってしまいます。\nこれを避けるためには、Cloverのブートオプションに\n-no_compat_check を追加します。これで機種チェックを回避できます。例えばconfig.plistに以下のように設定します。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;-v -no_compat_check\u0026lt;/string\u0026gt; 少なくともベータ版では、これでMojaveが起動しました。\nMojave非対応グラフィックス MojaveからはMetal対応グラフィックスが必須になりました。ただ、今のところは、Metalの機能が無いと全く動かないという状態ではなく、Metal非対応のドライバをmacOSから除外したという状態のようです。なので、古いmacOSからMojaveで削除されたドライバを持って来ればなんとか動くようです。ただ、Metalの機能を使っている部分もあるので、多少の不具合（ぼかしが機能しないなど）はあるようです。\n古いグラフィックスドライバを入れたり、また機種名を誤魔化すためのパッチを当てるツールも公開されています。実機向けのツールですが、Hackintoshでも使えると思います。\nmacOS Mojave Patcher\n古いハードウェアがMojaveに対応していないのは実機でも同様のことですので、Hackintoshもハードウェアのアップデートを検討するのが良いと思います。自作機ならアップデートは簡単ですから。\nMojaveへの移行方法 これは実機でも同じですが、新しいOSバージョンへ移行するには、大胆または慎重などの移行方針を選べます。バニラなインストール方法でHackintoshしているなら、実機とほぼ同様の方法でアップデート可能です。\n/posts/131/\n主ドライブを上書きアップデートする 今動いているHigh SierraからMojaveのアップデータを起動する方法です。実機と同様に、App Storeからダウンロードしたアップデータをそのまま起動すれば、問題なくアップデートされるはずです。Appleお勧めの一番簡単な方法です。ただ、上記で説明したCloverとkext類のアップデートは済ませておきましょう。\n別ドライブにインストールする 別ドライブにクリーンインストールする方法です。新OSの動作を確認して、問題がなければ移行しようという慎重な人向けです。自作HackintoshならSSDなどの追加は簡単だと思います。macOSだけならSSDは30GBもあれば十分ですが、現行製品だと120GBか256GBあたりがビット単価からしてお得感があります。直接内蔵しなくても、外付けケースに入れてUSB接続した別ドライブでもokです。\n方法は簡単で、今動いているHigh Sierraから別ドライブをフォーマットして、Mojaveのアップデータを起動してインストールすれば良いです。クリーンインストールするために、単体で起動できるUSBメモリを作る方法もありますが、すでに起動できるドライブがあるならその必要はないと思います。インストールの途中で古い環境からの移行をするオプションが現れます。これを使えば、High Sierraでの設定などを移行することも簡単です。\n別ドライブにmacOSをインストールしたら、そのドライブのESPにCloverとkext類も入れておきましょう。それで起動できれば、Hackintosh設定で失敗して主ドライブが起動しない時のバックアップになります。\n主ドライブにクリーンインストールする 単体で起動できるUSBメモリを作った場合は、主ドライブにクリーンインストールすることもできるでしょう。または、「別ドライブにインストール」した後であれば、それを起動して、主ドライブにクリーンインストールすることもできます。\nユーザデータまでフォーマットすると復帰が大変ですが、/Users以下を別ドライブや別パーティションに入れてあれば、システム部分をフォーマットしてクリーンインストールしてもそれほど手間はかからないと思います。\n","date":"2018-09-13T21:00:00+09:00","image":"/uploads/2018/09/20180913104255-300x165.png","permalink":"/posts/34/","title":"あと12日！Mojaveの受け入れ準備"},{"content":"時々は行ってやらないといけないHackintoshのメンテナンスでは、ESPをマウントする必要があります。またESPのバックアップがあれば、メンテナンスで失敗しても復帰できます。ということで、メンテナンスでESPをマウントするときに、同時にバックアップも行えば、万一メンテナンスで失敗しても、稼働していた最後のESPを取り戻せると考えました。\n今までの関連記事 振り返ってみると、ESPをマウントする方法と、ESPをバックアップする方法を色々書いてきました。10.13.6でdiskutil mountコマンドにパスワードが必要になったので、使えなくなった方法もあります。\nESPをマウントするためのシェルスクリプト\nESPを自動バックアップする\n10.13.6でESPをマウントする権限が変更される\n単にマウントしてバックアップする 今回は、シンプルにマウントしてバックアップするスクリプトを考えました。過去に紹介したスクリプトを足し合わせた内容です。現在はこのスクリプトで、ESPのマウントもバックアップもどちらも行っています。ESPに手を加える直前にバックアップすることになるので、合理的かと思います。\n#!/bin/sh ESPUUID=00000000-0000-0000-0000-000000000000 BACKUP=~/Documents/OSX86/_currentESP/ sudo diskutil mount $ESPUUID MP=`diskutil info $ESPUUID | grep \u0026#34;Mount Point\u0026#34;` MP3=`echo $MP | awk \u0026#39;{print $3}\u0026#39;` MP4=`echo $MP | awk \u0026#39;{print $4}\u0026#39;` if [ -n \u0026#34;$MP4\u0026#34; ]; then cd $MP3\u0026#34; \u0026#34;$MP4 rsync -av --delete $MP3\u0026#34; \u0026#34;$MP4\u0026#34;/\u0026#34; $BACKUP else cd $MP3 rsync -av --delete $MP3\u0026#34;/\u0026#34; $BACKUP fi date \u0026gt; timestamp.txt cd EFI/CLOVER 過去記事の重複になりますが、各ステップを説明します。\n最初に定義した変数、ESPUUIDはESPのUUIDです。例えばESPがdisk0s1に割り当てられた場合、\ndiskutil info disk0s1 とすると色々な情報が出てきます。この中に\nDisk / Partition UUID: 00000000-0000-0000-0000-000000000000 というように表示されているのが、ESPのUUIDです。\n次に定義した変数、BACKUPはESPの内容をバックアップしたい場所です。最後に/をつけます。これはのちに実行するrsyncコマンドの仕様上、重要です。バックアップ場所としては、iCloudやDropboxなどでクラウドと同期しているディレクトリを指定すると良いと思います。そうしておけば、万一マシンが起動しなくなっても、他のマシンから内容を取り寄せることができます。\ndiskutil mountの行で、ESPUUIDで指定したESPをマウントします。10.13.6からsuper user権限が必要になったのでsuコマンドをつけています。実行するとパスワードを求められるのでタイプします。\ndiskutil infoの行で、マウントポイントを得ています。このコマンドでマウントポイントが\nMount Point: /Volumes/EFI のように表示されます。この行を取得しています。\n次のawkコマンドとif文が続くところで、diskutil infoコマンドで得られる行から、マウントポイントだけを抽出しています。ややこしいですが、マウントポイントは、最初は\n/Volumes/EFI になるのですが、2個目以降は\n/Volumes/EFI 1 のように、空白＋数字になります。どっちでも対応できるようにif文で対応しています。\ncd $MP3″ “$MP4もしくはcd $MP3でESPの場所にカレントディレクトリを移動しています。シェルスクリプトの実行で移動する場合は、このスクリプトに例えばESPBackup.shと名前をつけた場合、\n. ESPBackup.sh として実行します。.の後には空白を入れます。\nrsyncコマンドで、$BACKUPで指定したディレクトリにバックアップしています。更新のあったファイルだけが置き換わります。\ndateコマンドでバックアップを取ったタイムスタンプを入れてみました。なくても良いですが、最後にバックアップした時刻がわかるので便利かと思います。\nおまけ。本当の最後にCLOVERディレクトリに移動しています。引き続き作業するのに便利かと思いました。\n","date":"2018-09-08T14:23:46+09:00","image":"/uploads/2017/09/20170926165208.png","permalink":"/posts/35/","title":"ESPをマウントしてついでにバックアップする"},{"content":"このページは古い情報です。macOS 10.14以降で使うGPUの情報は以下をご覧ください。\nHACKINTOSHのパーツ選び 【その3：グラフィックス編】10.14以降版\nHackintosh自作に適したグラフィックスカードを紹介します。10.13.4以降の最新macOSでHackintoshする人向けに、最新情報のみをまとめました。それ以前のmacOSの情報を含む詳しい経緯は、以下をご覧ください。2018年7月17日\n/posts/139/\nHackintoshグラフィックスの選択肢 一般的な自作PCと同じ状況なのですが、現在のコンピュータグラフィックスチップは、Intel, AMD, NVIDIAの3社でほぼ独占されています。この中から選ぶことになります。Hackintoshで使うことを検討する場合、\nIntelのCPU内蔵グラフィックス ノートPCに内蔵されたモバイル用AMDもしくはNVIDIAグラフィックス PCIeスロット用AMDグラフィックス PCIeスロット用NVIDIAグラフィックス のいずれかになると思います。 このうち2番目の、ノートPCに内蔵されたモバイル用AMDもしくはNVIDIAグラフィックスは、Hackintoshでは使えません。Macと全く同一のチップを搭載したアップル社製品以外のノートPCが存在していないためです。それ以外のモバイル用グラフィックスチップに対して、macOS用のグラフィックスドライバは提供されていません。なので、ノートPCでHackintoshする場合は、Intel CPU内蔵グラフィックスのみが利用可能です。 他の3個の選択肢は、Hackintoshで動きます。ただ、macOS Mojave 10.14からはMetal非対応のドライバが削除されたので、Metal対応モデルを使う必要があります。また、10.13.4からAMDグラフィックスの互換性が向上し、macOSに最初から搭載されたドライバでRadeon製品の一部がそのまま動くようになりました。 このような状況からHackintoshするグラフィックスのお薦め順位は、\nPCIeスロット用AMDグラフィックス PCIeスロット用NVIDIAグラフィックス IntelのCPU内蔵グラフィックス になると思います。PCIeスロットに搭載するグラフィックスカードは、互換性のあるものを選べば安定して稼働します。おすすめです。Intel CPU内蔵グラフィックスも安定して動きますが、場合によっては多少のノイズが発生することもあります。 以下で1. 2. 3. のそれぞれについて説明します。\nAMDグラフィックス 10.13.4以降のmacOSでは、AMDグラフィックスがお薦めです。AMD Radeon RX 470/480/570/580およびVEGA 56/64の4モデルならば取り付けるだけでそのまま動きます。10.13.4からThunderbolt 3接続の外付けGPUボックスがmacOSで正式にサポートされ、AMDのグラフィックスカードをApple社が推奨したからです。\nApple推奨グラフィックスカード\nこれによると、Polaris, Vega 56, Vega 64の3種類のアーキテクチャがサポートされているようです。具体的なチップは、以下です。\nAMD Radeon RX 470, RX 480, RX 570, RX 580, Radeon Pro WX 7100 AMD Radeon RX Vega 56 AMD Radeon RX Vega 64, Frontier Edition Air, Radeon Pro WX 9100 Sonnet社も、10.13.4に対応して、詳細な互換性リストを発表しました。AMDグラフィックスカードを購入する場合は、以下の記事で紹介したSonnetのPDF資料に、互換性があると記されているカードを購入すると良いです。\nSonnetの互換GPUリスト (10.13.4以降)\nということで、AppleやSonnetが推奨するAMD GPUを使えば、簡単にHackintoshできるので、お勧めです。このうち、Pro WXシリーズは高価なので一般的なHackintoshからは除外できるかもしれません。また、RX 470/480はすでに廃盤の製品で、後継の570/580はこのクロックアップバージョンにすぎません。なので実質的には、\nAMD Radeon RX 570 AMD Radeon RX 580 AMD Radeon RX Vega 56 AMD Radeon RX Vega 64 から選択することになると思います。先述のSonnetのリストによると、ブランドはどこでも同じようです。マザーボードとデザインを合わせるなど、好みのブランドを選べば良いようです。 もっと低価格のRX 560でも動くという報告も多数あります。ただ、Appleは560を推奨リストに挙げていませんし、Sonnetは非互換とマークしています。スリープ復帰などに問題があるという報告もありますので、多少の苦労が発生するかもしれません。 Vegaでは搭載空冷ファンのコントロールが効かず最大スピードになるという報告もあります。それも直せたという報告もありますので、対応可能なようです。 RX 580を使った経験では、しばらく使用すると性能（具体的にはGeekbenchのスコア）が低下する現象がありました。これはCPUの内蔵グラフィックスをonにすると解決しました。　（この性能低下問題はMojaveでは発生しなくなりました。しかし内蔵グラフィックスを無効にするとJPEGファイルがクイックルックやプレビューで開けないようです。内蔵グラフィックスは有効にしておくのが良いようです。） 一般的な自作PCの世界では、AMDの製品は、NVIDIAと比較して上位機種の性能、性能あたりの消費電力で未だに劣っていると言われています。ただ、これはWindowsで使うことを前提にした話です。macOSで使う場合、AMDはOSで正式にサポートされているアーキテクチャなので、色々と最適化されています。例えば、Final Cut Pro Xなどを使って性能比較すると、同じ性能ランクのNVIDIAよりも良いスコアを叩き出します。\nNVIDIA NVIDIAは、独自でmacOS用のドライバを開発して配布してくれています。なので、これ （NVIDIAのWebページで配布されていて、Webという名前の含まれるkext群で構成されるのでWeb driverと呼ばれます）を使えば、1080Tiなどの最近のPascalアーキテクチャモデルが問題なく動きます。それ以前のモデルもサポートされています。AMDではmacOSがサポートしてくれるモデルに制限がありますが、Web driverはNVIDIAのほとんどのモデルに対応しています。 Web driverをインストールする作業も簡単です。Web driverはmacOSのバージョンごとに配布されています。機能はそれほど変わらないようですが、macOSのバージョンチェックをして、合致しないビルド番号では起動しません。以下のサイトで、それぞれのビルド番号に合ったドライバのダウンロードURLがまとめて整理されています。 www.macvidcards.com macOSのビルド番号は、「リンゴマーク」「このMacについて」のOSバージョンの文字をクリックすると、その横に表示されます。下の例では17E202です。 NVIDIAを選ぶメリットは、Web driverが現行製品のほとんどに対応しているので、高性能なモデルから、安価なモデルまで、選択肢が多いことです。例えば、PC自作ユーザ向けの最上位機種、GeForce GTX 1080Tiはとても強力で、性能あたりの消費電力も低いです。その一つ下のモデルのGTX 1080でも十分強力です。最近発売されたAMDのVega 64でも、性能は1080にある程度追いついたものの、価格と消費電力で負けているようです。特に、Windowsと併用するとか、Windowsでグラフィックス性能を必要とするゲームをするなどの場合は、NVIDIAを選ぶことにメリットがあります。\nグラフィックス性能は不要という人も多いと思います。普通にGUI操作したり動画を見る程度では、グラフィックス性能は問題にならないのも事実です。現行のNVIDIA製品の最下位GT 1030を使用するのも良いでしょう。ファンレスモデルもあります。\n1030はローコストだけど性能は高いようです。 androgamer.net Web driverのおかげでNVIDIAならどれを選んでもだいたい大丈夫ですが、中には多少相性の悪いモデルもあるようです。例えば、GTX 1060はスリープからの復帰でノイズが出る問題が指摘されています。 https://www.tonymacx86.com/threads/05-02-added-temporary-fix-pascal-gtx-1060-glitching-after-waking-from-sleep.220670/page-8 今後、すぐに対応されるとは思いますが、その上位・下位の別モデル、1050tiや1070を購入した方が良いかもしれません。\nKeplerアーキテクチャ NVIDIAでもKeplerアーキテクチャとそれ以前の古いカードになると、Web driverなしでも動くモデルがあります。昔のmacOSではNVIDIAを採用していたので、Web driverを入れなくても（入れても機能します）macOSの標準ドライバだけで動きます。OSのバージョンアップに伴う新Web driverの発表を待つ必要もありません。（もっともNVIDIAの対応はとても早くて、24時間くらいで新OSに対応してくれますが） ただ、Mojaveが対応しているiMacに搭載されているNVIDIA GPUがGT 640M/650Mあたりの型番なので、Keplerアーキテクチャ世代にしておいたほうが無難です。できるだけ安く探すとなるとGT 710とかGT 730あたりでしょうか。\nIntel CPU内蔵GPUは使えるか？ MacintoshでIntel CPU内蔵GPU (iGPU) を使っている機種は多数あります。これらと同じGPUは問題なく使用できると考えて良いです。純正Macで採用されていないIntel GPUも、近いモデルならば動くことがあります。 MojaveからはMetal対応のGPUのみがサポートされるようになります。Sandy Bridge以前のIntel CPU内蔵GPUは、Metalに対応していません。Ivy Bridge以降のCPUならば大丈夫です。ちなみにMojaveをサポートしているiMacが搭載しているデスクトップ向けIntel HD Graphicsは\nIntel HD Graphics 4000 Intel HD Graphics 5000 Intel HD Graphics 6000 Intel HD Graphics 530 Intel HD Graphics 630 Intel UHD Graphics 630 です。Intel UHD GraphicsはMojaveからサポートされています。 ただCPU内蔵グラフィックスは、 時々画面が乱れるとか、スリープからの復帰に失敗してハングするなどの問題も報告されています。互換性のあるPCIeのグラフィックスカードの方が安定しています。もともと、Intelのデスクトップ用CPUの内蔵GPUはモバイル用に比べて非力です。トラブルに遭遇したら「モバイル機種に負けるようなグラフィックスは使わない」と考えてPCIeグラフィックスカードを検討するのが良いと思います。\n","date":"2018-08-26T22:10:42+09:00","image":"/uploads/2018/08/20171118234329-300x182.png","permalink":"/posts/36/","title":"Hackintoshのパーツ選び 【その3：グラフィックス編】10.13.4以降版"},{"content":"ちかごろ4Kとか8Kとかの高精細な動画やディスプレイが話題です。iMacでも4Kや5Kのディスプレイを搭載して、網膜に匹敵するRetinaディスプレイであることを売りにしています。Hackintoshでも高精細表示はもちろん可能です。今回はHackintoshで4Kディスプレイを使ってみます。実のところ4K, 5Kなんて要らないと思っていましたが、使ってみたら予想以上に快適で手放せません。\nディスプレイの規格・iMacの仕様 現行デジタルテレビ規格ではHDやFull HDが一般的です。このさらに高精細な動画・ディスプレイの規格として、それぞれの面積の4倍、8倍の規格があり、これを表示するためのディスプレイが商品化されています。この一覧でわかるように、なんとかKという表記は、横方向の画素数をキロ単位で表したものです。例えば一般的な4Kディスプレイは3840 x 2160画素です。横方向の画素が大体4,000画素なので4Kと称しています。4,000には足りないのでちょっと詐称かもしれません。\nHDは1280 x 720画素 (720p) 2Kは1920 x 1080画素 (Full HD, 1080p) 2.5Kは2560 x 1440画素 (HDの2×2倍) 4Kは3840 x 2160画素 (Ultra HD, Full HDの2×2倍) 5Kは5120 x 2880画素 (HDの4×4倍) 8Kは7680 x 4320画素 (Full HDの4×4倍) コンピュータ用ディスプレイではFull HDディスプレイが一般的で、お求めやすい価格で多数販売されています。最近では、4Kディスプレイも安くなってきました。 一方で我らがiMacではどのような画素数が採用されているかというと、以下のようです。\nRetina 5K iMacやiMac Proは27インチ 5120 x 2880画素 Retina 4K iMacは21.5インチで4096 x 2304画素 RetinaではないiMacは21.5インチで1920 x 1080画素 5Kは、720p HDの4×4倍画素のディスプレイです。アップルストアではLG社のLG UltraFine 5K Displayという27インチディスプレイを税別15万円弱で販売していますが、iMacでもおそらく同じパネルを搭載していると思われます。AmazonでLG以外の同等製品を他に探すと、iiyamaのモニタがありました。スペックが似ているのでもしかしたらこれも同じLGのパネルなのかもしれません。価格は8万円台です。\n4K iMacは、一般的な4Kディスプレイより画素数が多くて、正しく4Kのようです。あまり見かけない画素数なのですが、これも同じような21.5インチディスプレイがアップルストアで、LG UltraFine 4K Displayとして販売されています。税別8万円弱です。おそらく同じLGパネルがiMacで使用されていると思われます。\n4K Displayがおすすめ Hackintoshで使う高精細度ディスプレイとしてどれを選んだら良いでしょうか。上の調査から、以下の選択肢があると思います。\nほぼ純正のLG UltraFine 5K Display (27インチ) 市販の5K Display (27インチ) ほぼ純正のLG UltraFine 4K Display (21.5インチ) 市販の4K Display (24, 27, 31.5インチなど機種が豊富) 1.と3.に上げた、ほぼ純正のLG UltraFine Displayは、おそらく品質は良く、またmacOS上で十分にテストされていると思われるので、トラブルも無いでしょう。しかし高価でコストパフォーマンスが悪いです。特に4Kの方は21.6インチなので、24インチくらいのディスプレイに慣れてしまった今時のデスクトップユーザからすると狭いです。この金額を支出するなら、後述する31.5インチ4Kディスプレイを買ったほうが幸福になれます。 2.の市販5K 27インチディスプレイは、選択肢が少ないです。上記のiiyamaの製品はAmazonで買えますが、tonymacx86のBuyer’s Guideで推奨されているDell UP2715Kは品切れです。他のメーカでは相当する5Kディスプレイを販売していません。 また5Kディスプレイには、Hackintoshとの互換性の問題もあるようです。例えば以下のスレッドによると、\nwww.tonymacx86.com\nNVIDIAのカードで電源投入時の動作がおかしかったり、マウスポインターが安定しない問題があったようです。macOSがネイティブサポートするRadeon RX 580に交換したところ安定して動くようになったそうです。GPUの選択肢が狭まってしまうのはちょっと嫌です。 上記の選択肢の中では、4.の「市販の4K Display」を選ぶのが一番良いと思います。5Kディスプレイに比べて、多数の製品が潤沢に販売されていて、選択肢が多いです。競争があるので価格も手頃で、コストパフォーマンスが良いです。若干の懸念は、純正のiMacでサポートされていない画素数であることですが、ネットの情報では全く問題なく動くようです。こちらのブログの方も、同じような理由で市販のLGの4Kディスプレイを買われたようです。 nop-me.hatenablog.com\n選定機種はLGの27インチ 以上のことから、メーカーはLGにしました。iMacで使用されているパネルなので、macOSとの互換性において多少安心できるかと考えました。品数も多く、商品の選択肢も多いです。 なかでも27インチは5K iMacと同じサイズで、広くて使いやすい大きさかと思います。amazonで入手できるLGの4K 27インチ現行モデルは、価格の安い順に以下の3機種でした。LGの4Kディスプレイのうちこの３機種だけがHDR対応しているようです。\n27UK600-W 27UK650-W 27UK850-W 標準的なモデルは27UK650です。27UK850は、標準モデルに、給電機能を完備したUSB Type-Cポートをつけ、さらにスピーカも搭載したモデルです。MacBookシリーズに接続しつつ充電も行う場合に便利かと思います。 一方で、標準モデルから高さ調整機能を省いたのが27UK600のようです。amazon限定モデルです。タイムセールで値引きされていたこともあり、これを購入することにしました。モニターアームを別に購入するつもりでしたので、高さ調節機能がなくても問題ありません。ちなみに本体の重量は実測で4.7kgでした。プラスティックを多用した薄型設計なので、モニターアームへの負担も少ないです。\nこれ以外のサイズのLG 4Kディスプレイには以下のモデルがあります。上記の27インチモデルに比べて少し古い機種なので、今後HDR対応モデルが出るのかもしれません。24UD58はサイズが小さめですがIPSパネルでお買い得です。32UD59は安いですがVA液晶です。このサイズでIPSの32UD99はそれなりのお値段になりますが、コストパフォーマンスは良いです。\n24UD58-B (24インチ) 32UD59-B (31.5インチ) 32UD99-W (31.5インチ) Hackintoshに接続する ということで今回は、LG 4Kディスプレイ、27UK600を調達しました。でもせっかく4Kディスプレイを買っても、グラフィックスチップとそのドライバが4K解像度をサポートしていないと意味がありません。\n4Kをサポートしていない場合 LG 4Kディスプレイ、27UK600の解像度は3840 x 2160画素です。この解像度に対応していないグラフィックスのマシンに接続すると、4K未満のディスプレイと見なされてしまいます。例えば、Intel HD Graphics 4000を搭載したIvy Bridge NUCにHDMIで接続すると以下のようになります。\nIntel HD Graphics 4000は、Mac mini (Late 2012)で使用されています。このMac miniの仕様を見ると、サポートされている解像度は、HDMI接続で1920×1200だそうです。せっかくの4KディスプレイがただのFull HDディスプレイになってしまうのも仕方ないところです。 このディスプレイを今度は、デスクトップ用Haswell CPUを使用したHackintoshのマザーボードにあるDisplay Port端子に接続してみました。デスクトップ用Haswell CPUに内蔵されているGPUはIntel HD Graphics 4600です。この場合も4K解像度の3840 x 2160画素表示はできませんでした。最大で2560×1440画素です。\nデスクトップ用Haswell CPUを採用したMacはありますが (iMac Late 2014など)、RadeonなどのGPUを別途搭載していて、内蔵GPUであるIntel HD Graphics 4600は表示に使用されていません。でもmacOS搭載のドライバでIntel HD Graphics 4600を使用して表示することが可能です。システム情報–\u0026gt;拡張機能を見ると使用されているドライバがわかります。これによると、\nAppleIntelHD5000Graphics.kextが使用されていることがわかります。Intel HD Graphics 5000は、モバイル用Haswell 4260Uなどに採用されているGPUです。同世代なので互換性があるようです。Intel HD Graphics 5000を搭載したiMac (21.5-inch, Mid 2014)の仕様を見ると、最大サポート画素数は2560×1600画素です。使用しているグラフィックスドライバが4Kをサポートしていないので、4Kの解像度が出ないわけです。\n4Kをサポートしている場合 一方、4Kの解像度に対応したグラフィックスカード搭載Hackintoshに接続するとRetinaディスプレイとしての解像度選択肢が現れます。以下は、AMD Radeon RX 580に接続した例です。NVIDIAのグラフィックスカードに接続しても同様にRetinaディスプレイとして扱われます。\nRetinaディスプレイとして認識されると、解像度の選択が画素数ではなくて、文字・スペースの拡大になります。文字を一番小さく・スペースを一番拡大する右端の選択肢を選ぶと、「擬似解像度」の表示が3840 x 2160になり、画面の解像度と同じになります。この状態では、画面表示の1画素が、ディスプレイの1画素に対応します。なので、メニューやテキストの表示が非常に小さくなります。 一方で文字を一番大きく・スペースを一番縮小する左端の選択肢を選ぶと、「擬似解像度」の表示が1920 x 1080になります。この状態では、画面全体が1920 x 1080画素のディスプレイとしてOSから認識されています。メニューや文字は、27インチのFull HDディスプレイに接続した時と同じ大きさで表示されます。実際にはOSが認識している1画素は、ディスプレイ上で2 x 2画素で構成されています。OSの描画ライブラリは、文字や線の描画を通常の倍の解像度で美しく表示できます。この仕組みはアプリケーションから隠されたOSの奥深い場所で行なっているため、アプリケーションからは通常のFull HD座標系に書き込んでいるつもりでも、自動的に高精細に表示されます。それが「擬似解像度」の意味するところです。\n「システム情報」を見ると、ディスプレイが60Hz 4K表示されていて、「UI擬似解像度」が1920 x 1080であることがわかります。\nちなみに、UI擬似解像度と実際の解像度の比率を、整数倍ではなく、中途半端な値にすることも可能です。例えば以下の設定では、画面上の3840画素を3008画素の擬似解像度として使っています。\nこの場合、擬似解像度から実際の解像度への変換が整数倍ではなくなるので、処理に時間がかかる可能性があるようです。「パフォーマンスに影響する場合があります。」との表示が出ます。ただ、実際に使ってみても、表示が遅くなるような印象はありませんでした。\n4Kは美しい 当初はここまでの解像度は不要なのではと懐疑的でしたが、使ってみると意外と差があり、4Kディスプレイから普通のディスプレイには戻れなくなってしまいました。小さな文字の表示では特に顕著です。例えば、電源投入直後に、「再起動後にはApple Watchではロック解除できず、パスワードの入力が必要になる」という内容のメッセージがログイン画面に現れますが、この表示を4K画素と通常画素で比べると以下のようになります。\nまた、先のディスプレイ設定画面でも、4K画素と通常画素では表示が変わることがわかります。その様子をGIFアニメにしてみました。\nGIFに変換したので色がおかしいところがありますがそこはご容赦を。 ちなみに文字のサンプルとして書かれている文章は、AppleのThink Different広告キャンペーンで使われた文らしいです。\nThink different – Wikipedia\n","date":"2018-08-19T18:32:24+09:00","image":"/uploads/2018/08/20180819182648-300x234.png","permalink":"/posts/37/","title":"4Kディスプレイを使う"},{"content":"\nWhateverGreen.kext 1.2.0\nGPU関連のkextである\nIntelGraphicsFixup NvidiaGraphicsFixup Shiki は、WhateverGreen.kextに統合されました。これからは、GPUがNVIDIAでも、Intelでも、AMD Radeonでも、WhateverGreenだけを使うのが正しいやり方のようです。\nhttps://www.insanelymac.com/forum/topic/325987-whatevergreen-support-topic/?page=20\u0026tab=comments#comment-2625396\nの2018年7月12日の投稿によると、\nIntelGraphicsFixup, NvidiaGraphicsFixup, Shikiは公式に開発中止になり、WhateverGreenの一部になりました。新しいWhateverGreenにより、インストールが簡単になるだけでなく、互換性と全体としての性能が向上します。\nとのことです。\nWhateverGreen.kextは元々はAMD RadeonのGPUを動かすためのパッチを提供していて、Radeon RX 570/580などをmacOSで動かすために必要でした。しかし、10.13.4から最新のRadeonがmacOSでネイティブにサポートされるようになり、不要になっていました。今回の統合で、GPU関係はWhateverGreen.kextを入れておけば解決という便利な状態になったと思います。ちなみに、Nvidiaも（Radeonを作っていてAMDに買収された）旧ATIもロゴが緑色なので、どちらの緑にも対応という名前は合っているのではないかと思います。\nこちらで紹介したKext Updaterを動かしてみたら、\nワンクリックで最新kextに〜Kext Updater.app (Ver. 2)\nIntelGraphicsFixup.kextはもう使うのをやめて、WhateverGreen.kextを使いましょうというメッセージが出るようになりました。\nちなみにWhateverGreenは、今回廃止されたkextと同様に、Lilu.kextと一緒に使う必要があります。\n/posts/118/\n","date":"2018-08-05T17:09:01+09:00","image":"/uploads/2017/09/20170915223211.png","permalink":"/posts/38/","title":"GPU関連kextがWhateverGreen.kext 1.2.0に統合されました"},{"content":"Kext Updater\n古いバージョンの記事です。新しいバージョンに関しては以下をご覧ください。\nBoot macOS\nHackintoshで使っているClover, EFIドライバ、kext類は、最新版を使うのが良いです。色々なバグが直されていて、安定しています。また常に最新にしておけば、macOSのバージョンアップにも対応できます。Mojaveに備えていつも最新状態にしておきたいものです。ただ、開発者の方々のページを巡回して最新版をチェックするのも大変です。\nHackintoshで使用中のkext類最新版をチェックして、新バージョンがあった場合にダウンロードしてくれる便利なツールがあります。ドイツのHackintoshフォーラムの人たちが作ってくれているKext Updaterです。以下でソースが公開されています。\nコンパイル済みの最新版はこちらからダウンロードできます。\n早速起動してみます。ラジオボタンがいくつかありますが、メインの機能は「Check for Updates」のボタンです。これを選択して、「Start」ボタンを押します。すると左のメッセージエリアに以下のような表示が出ます。\n使用されているHackintoshのkextを全部調べ上げてくれて、それが最新版であるかどうか判断してくれます。ここではNvidiaGraphicsFixup.kextが最新版より一つ前のバージョンでした。そこで、これが自動的にダウンロードされて、デフォルトでは、デスクトップのKext-Updatesという名前のフォルダに入ります。このフォルダは「Open」ボタンで開けられます。そこで、必要ならば「Mount EFI」ボタンを押してESPをマウントして、ダウンロードした最新版と入れ替えます。\n他にもラジオボタンから\n基本的なkextをKext-Updatesフォルダにダウンロードする（右のメニューで種類を選べます） 一つのkextをダウンロードする（右のメニューでkextを選べます） NVIDIA Webドライバをダウンロードする（右のメニューでバージョンを選べます） Clover最新版をダウンロードする（Nightly Buildにチェックを入れると非公開最新版をダウンロードできます） このツールにより、最新版をチェックして差し替える作業が大幅に楽になります。\n","date":"2018-07-21T00:30:00+09:00","image":"/uploads/2018/07/20180625132658-300x300.png","permalink":"/posts/39/","title":"ワンクリックで最新kextに〜Kext Updater.app (Ver. 2)"},{"content":"先日発売された新MacBook Proには、Coffee Lake-S CPUがいよいよ搭載されました。新製品に搭載された5種類のCPUと内蔵グラフィックスは以下のとおりです。\nIntel Core i9-8950HK 2.9 GHz (6 cores) Intel UHD Graphics 630 Intel Core i7-8850H 2.6 GHz (6 cores) Intel UHD Graphics 630 Intel Core i7-8750H 2.2 GHz (6 cores) Intel UHD Graphics 630 Intel Core i7-8559U 2.7 GHz (4 cores) Intel Iris Plus Graphics 655 Intel Core i5-8259U 2.3 GHz (4 cores) Intel Iris Plus Graphics 655 上の3機種が15インチモデル、下の2機種が13インチモデルです。15インチモデル搭載の内蔵グラフィックスには、デスクトップCPUのCoffee Lake-Sシリーズと同じIntel UHD Graphics 630が搭載されています。この新MacBook Proのグラフィックスドライバを入手すれば、8700K自作Hackintoshが安定して、そのグラフィックス性能を引き出せると思われます。\n新機種で追加されたハードウェアのドライバを一般のmacOSユーザが入手できる時期は、通常、新機種が出た次のmacOSアップデートになります。今回の新MacBook Pro発表は、macOS 10.13.6が配布された直後なので、アップデートのタイミングを考えると、9月のMojaveでようやく入手できるかと思われます。なのでしばらくは入手不可能なのではと考えていました。ところが5chでこんな情報を教えてもらいました。tonymacx86のスレッドです。\nwww.tonymacx86.com\nリカバリーパーティションで起動して入手する 新MacBook Proに搭載されているのは、App StoreからアップデートできるmacOSと同じ10.13.6です。しかし、App Storeで配布されているのはBuild 17G65なのに対して、新製品にインストールされているBuildは17G2112だそうです。そして、17G2112にしかIntel UHD Graphics 630のドライバは含まれていないようです。\nところが以下の手順で、最新Buildを入手できるそうです。\nSMBIOSの設定でHackintoshの機種を新製品に偽装する。15インチモデルはMacBookPro15,215,1で13インチがMacBookPro15,2です。macosx86の人はMacBookPro15,2を使ったようです。 Clover r4651+をhttps://github.com/Dids/clover-builder/releasesから入手して使います。MacBookPro15,1, 15,2のSMBIOS情報が含まれているそうです。（config.plistに書かない情報などを補完してくれるのだと思われます） リカバリーパーティションで起動します。するとApple社のサーバからmacOSをダウンロードしてインストールできるそうです。 ちなみにUHDグラフィックスドライバは、AppleIntelCFLGraphicsFramebuffer.kextだそうです。\nMojaveまで待てば良いけど とはいえ9月に出ると思われるMojaveまで待てば、グラフィックスドライバは苦労をしなくても入手できます。また、Mojave Dev Beta 4から、このドライバが含まれているそうです。なので、本日出たMojave Public Beata 3にも、新ドライバが含まれているはずです。Mojaveは安定しているので、さっさとBetaに移行しても良いかもしれません。ただ、Coffee Lake-S自作Hackintoshをしている人が、High Sierraを使いたいと希望する場合には、この方法が良いかと思います。\n","date":"2018-07-18T23:48:53+09:00","image":"/uploads/2018/07/20180718224702.png","permalink":"/posts/40/","title":"Intel UHD Graphics 630用純正グラフィックスドライバ"},{"content":"\nHigh SierraとMojaveで/System/Library/Extensions (/S/L/E) の中に含まれるkext類がどう違うのか、調べてみました。\nHigh Sierra 10.13.6をクリーンインストールして、MojaveのPublic Beta 1と比較しました。/S/L/Eの内容をlsしてdiffで比較しました。High Sierra, Mojaveの順にdiff引数を指定したので、行頭に\u0026lt;がついているのがHigh Sierraにのみ存在するkext、行頭に\u0026gt;がついているのがMojaveにのみ存在するkextになります。\n消えたkext High SierraにあったけどMojaveでは消えてしまったkext（アルファベット順）は、以下です。\n$ diff HighSierra.text Mojave.text | grep \u0026#34;\u0026lt;\u0026#34; \u0026lt; AMD2400Controller.kext \u0026lt; AMD2600Controller.kext \u0026lt; AMD3800Controller.kext \u0026lt; AMD4600Controller.kext \u0026lt; AMD4800Controller.kext \u0026lt; AMD5000Controller.kext \u0026lt; AMD6000Controller.kext \u0026lt; AMDLegacyFramebuffer.kext \u0026lt; AMDLegacySupport.kext \u0026lt; AMDRadeonX3000.kext \u0026lt; AMDRadeonX3000GLDriver.bundle \u0026lt; ATIRadeonX2000.kext \u0026lt; ATIRadeonX2000GA.plugin \u0026lt; ATIRadeonX2000GLDriver.bundle \u0026lt; ATIRadeonX2000VADriver.bundle \u0026lt; AppleIntelHD3000Graphics.kext \u0026lt; AppleIntelHD3000GraphicsGA.plugin \u0026lt; AppleIntelHD3000GraphicsGLDriver.bundle \u0026lt; AppleIntelHD3000GraphicsVADriver.bundle \u0026lt; AppleIntelHDGraphics.kext \u0026lt; AppleIntelHDGraphicsFB.kext \u0026lt; AppleIntelHDGraphicsGA.plugin \u0026lt; AppleIntelHDGraphicsGLDriver.bundle \u0026lt; AppleIntelHDGraphicsVADriver.bundle \u0026lt; AppleIntelSNBGraphicsFB.kext \u0026lt; AppleIntelSNBVA.bundle \u0026lt; AppleTyMCEDriver.kext \u0026lt; GeForceGA.bundle \u0026lt; GeForceTesla.kext \u0026lt; GeForceTeslaGLDriver.bundle \u0026lt; GeForceTeslaVADriver.bundle \u0026lt; NVDANV50HalTesla.kext \u0026lt; NVDAResmanTesla.kext 最初の方を見ると、AMDの古いドライバがいくつか削除されたようです。Metalに対応していないグラフィックスカードのドライバと思われます。2400, 2600は2007-2008年代のiMacに搭載されたグラフィックスだと思われます。4600, 4800, 5000, 6000は、おそらくiMacや昔のタワー型Mac Proに搭載されたHD 4000/5000/6000シリーズに対応するドライバだと思われます。ただAMDRadeonX4000,5000,6000.kextはMojaveにも存在しているので、HD 4000/5000/6000シリーズはまだ使えるのかもしれません。\nタワー型Mac ProにはPCIeスロットがありますが、Mac用のBIOSを搭載したカードでない場合には、起動時の表示が出ません。なので古いMac Proユーザはいまだに古いカードを使っていることも多いのですが、Mojaveでは使えなくなったようです。Hackintoshしている人がこのような古いAMDカードを使っていることは稀だと思いますので、影響は少ないと思われます。\n次に、Intel HD Graphics 3000シリーズのドライバと思われるApple Intel HD3000 Graphicsで始まるkext類が削除されています。3000の前には、無印のIntel HD Graphicsという規格がありましたが、Mac製品には搭載されていません。なので、AppleIntelHDGraphicsで始まるkext類も同じく3000シリーズのものと思われます。また、AppleIntelSNBGraphicsで始まるkext類は、検索してみたら、SNBがSaNdy Bridgeの略だそうで、これも3000シリーズのものです。3000シリーズがMetal対応から外されたので、Sandy Bridgeを使っているHackintoshは、PCIeグラフィックスカードを利用するか、CPU/マザーボードアップグレードを検討すべきでしょう。\nまた、GeForceで始まるkext類も一部削除されています。Mojave対応機種がiMacではLate 2012だそうです。グラフィックスチップは、GT 640M, 650M, 660M, 675MX, 680MXのあたりなら対応しているようです。それ以前のGeForceのドライバが外されたのかもしれません。\nグラフィックスドライバ以外では、AppleTyMCEDriver.kextが外されています。検索して見ると、これは ECCメモリに関連する何かのようです。\n登場したkext HighSierraには無くて、Mojaveで新しく登場したkextは以下の5個でした。よくわかりません、すみません。\n$ diff HighSierra.text Mojave.text | grep \u0026#34;\u0026gt;\u0026#34; \u0026gt; AMDRadeonX6000HWServices.kext \u0026gt; AppleUSBCHCOM.kext \u0026gt; AppleUSBPLCOM.kext \u0026gt; AppleUSBRealtek8153Patcher.kext \u0026gt; CoreTrust.kext ちなみにRealtek 8153というのはUSB 3.0 – ギガビットEthernetのチップのようです。こんな製品で使われているようです。Appleブランドにはこのようなアダプタが無いので謎です。\n/L/Eに置かれたkext /Library/Extensionsに置かれたkextに変更はありませんでした。\nちなみに以下のkextが/L/Eに置かれています。CalDigitというのはThunderbolt接続周辺機器を作っている会社のようです。HighPointはRocketなんとかシリーズでPCIeスロット搭載RAIDアダプタなどを作っていますね。ATTOはネットワークカードなどを作っていて、Celerityは光ファイバーカードのようです。\nACS6x.kext ATTOCelerityFC8.kext ATTOExpressSASHBA2.kext ATTOExpressSASRAID2.kext ArcMSR.kext CalDigitHDProDrv.kext HighPointIOP.kext HighPointRR.kext PromiseSTEX.kext SoftRAID.kext ","date":"2018-07-18T00:30:00+09:00","image":"/uploads/2018/07/20180718125949.png","permalink":"/posts/41/","title":"Mojaveで消えたkext、増えたkext"},{"content":"\n（古い情報です。最新情報はこちらをご覧ください。）\nCLOVER 4988 でEFIドライバ関連が変更されました\n—————\n最近のClover*1でEFIドライバ類が色々と変更されている様です。気づいたところをメモしておきます。\n64bit移行のためと思われる名称変更 EFIドライバフォルダ名 だいぶまえにdrivers32というフォルダがなくなってdrivers64だけになっていたと思うのですが、最近ではdrivers64UEFIになったようです。新規にインストールするとこれだけになります。drivers64は空になる事もあります。drivers64は手作業で消してしまっても良いようです。\nまた、Cloverのインストーラは、現在インストールされているドライバを見てチェックマークを更新しているわけでは無いようです。前回、インストールしたログを見て、その記録から更新するドライバを選んでいます。なので、手作業でインストールしたドライバは反映されていません。時々は、インストールされたドライバと照らし合わせて、更新リストに入っているかどうか確認した方が良いかと思います。\n末尾が-64のドライバ 最近、全てのドライバのファイル名末尾に-64が付きました。64bitであることを明白にするためなのかと思います。同名のドライバで、末尾が-64で無いバージョンのドライバがESPに入っていると、アップデートで置き換えられない（両方が残ってしまう）ことがありますので、手作業で削除しておきましょう。\n（更新：Clover 4988から64の名前が外されました。全て64ビットのみになったためと思われます。2019/7/13）\nデフォルトのEFIドライバ デフォルトでインストールされるEFIドライバは、インストーラで表示されなかったと思うのですが、最近では全部表示されるようになっています。以下の８個がデフォルトでインストールされる設定になっているようです。\nデフォルトで選択されているので重要なドライバだとは思います。そのうち調べて、機能をメモしていきたいと思います。\n一部はこちらを参考にしました。\ngithub.com\nAppleImageCodec/AppleKeyAggregator/AppleUITheme は、FileVault 2 のサポートのために必要なファイルです。FileVault 2のフル機能を使うためには、UsbKbDxe/AptioInputFix/AptioHashServiceFixなども必要です。 DataHubDxe はEFI_DATA_HUB_PROTOCOLを実装します。これはboot.efiが必要とします。これは消してしまっても大丈夫です。というのはほとんどのfirmwareはすでにこのプロトコルを実装しているからです（と書いてありますがすみません、意味がわかりませんでした。ここでのfirmwareというのはboot.efiなどのことを指しているのかな？） FirmwareVolume はFileVault 2でAppleカーソルイメージを機能させます。 FSInject は、kextを機能させるために必要です。 SMCHelper は、APPLE_SMC_IO_PROTOCOLの実装を追加します。boot.efiが文句を言うのを防ぎます。多分boot.efiがSystem Management Controllerとやり取りできるよう、そのプロトコルを実装しているのだと思います。 VBoxHfs-64は、HFS+をアクセスするためのオープンソースのドライバです。起動ボリュームがHFS+でフォーマットされている場合に、これを使ってブートローダにアクセスします。 ということで、FileVault 2を使用しないのであれば、最初の5個は不要のようです。最低限必要なのは、後半の3個のみということかと思います。\nオプションのドライバ 次に、デフォルトでは選択されていないドライバをチェックしていきます。\nメモリ確保のドライバ こちらの説明で、\nCloverインストーラの設定\n以下のドライバの役割と、推奨順番を説明しました。推奨順番はこの順番です。\nAptioMemoryFix.efi OsxAptioFix3Drv-64.efi OsxAptioFix2Drv-64.efi OsxAptioFixDrv-64.efi OsxLowMemFixDrv-64.efi 用意されているドライバが、最近では以下に変わっている様です。\nAptioMemoryFix-64.efi OsxAptioFix2Drv-64.efi OsxAptioFixDrv-64.efi OsxLowMemFixDrv-64.efi AptioMemoryFixに-64が付いて、3Drvは無くなったようです。理由は不明です。今後、アップデートされないので3Drvは使わない方が良いかもしれません。（更新：最新バージョンでは3Drvが復活しています。何れにしても最新のCloverインストーラの選択肢に従うのが良いです。）また、上記のいずれもダメな場合は、 OsxAptioFix2Drv-free2000.efi を試すと良いです。これは最強な感じです。\nこれらのドライバが働かない場合、Clover選択画面の直後で起動が停止します。-vオプションで、メモリがallocateできないという様なメッセージが出ていたら、このドライバを差し替えてみてください。メモリのallocateはいろんな条件で失敗する様です。kextを入れ替える事で失敗が発生する事もあります。また、大抵は成功するものの、数回に１度ランダムにallocate失敗する事もあります。\nApfsDriverLoader.efi 前に紹介しましたように、apfs.efiをmacOS本体からロードしてくれるドライバがr4558から登場しました。これがあればapfs.efiを本体から持ってくる必要はありません。ただ、環境によっては失敗する事も稀にあるようですので、apfs.efiを手作業でコピーしておいた方が良い事もあります。今後改良されるのだとは思います。\nClover 4558で登場したApfsDriverLoader.efi\nその他のドライバ ApfsDriverLoader-64もそうですが、最近のインストーラで選択できるドライバが増えている気がします。よくわからないファイルもありますが、今後、検索して機能が判明したらまた紹介していきたいと思います。\nAptioMemoryFix / OsxAptioFix2Drv / OsxAptioFixDrv / OsxLowMemFixDrvは上で説明したメモリ確保のドライバです。 CsmVideoDxe Cloverが動作している時のビデオ表示のためのドライバだったと思います。これを使うと高解像度で表示できるとか。効果のほどはわかりません、すみません。 EmuVariableUefi はNVRAMの機能をソフト的にエミュレートするドライバです。NVRAMは全てのマザーボードが持っていて、OS起動のためのパラメタなどを保持するのに使われているのですが、Hackintoshと相性が悪くてmacOSから読み込めないマザーボードもあるようです。NVRAMが正しく保存、読み込みできないマザーボードの場合はこれを使います。例えば、NVIDIAのドライバを使うかどうかの設定が保持されない場合などこれが必須です。 EnglishDxe UEFI shellで文字表示するために、一部のマザーボードで必要らしいです。 Fat 不明です。調べて見つかったら加筆します。 HashServiceFix もFileVault 2のために必要なようです。HDPIカーソルの問題を修正するのだそうです。よくわかりません、すみません。 NvmExpressDxe NVMeプロトコルのSSDをサポートします。これがあれば、NVMe SSDにブートローダが入っていても読み込むことができます。現在のマザーボードはその機能をEFIに持っているので不要です。古いマザーボードや、古いタワー型Mac Proなどではこれを使うとNMVe SSDから起動できるようになります。 OsxFatBinaryDrv はFAT EFIバイナリのサポートを追加しますが、今は不要です。古いバージョンのmacOSはFATのboot.efiを持っていました。消してしまっても構いません。 PartitionDxe は、論理BlockIOデバイスをサポートします。現在は El Torito CD-ROM, 古いMBR, GPTパーティションがサポートされています。一部のBIOSで必要です。 Ps2MouseDxe PS2接続のマウスを読み取れるようにします。ノートPCなどのポインティングデバイスがPS2接続のこともあります。その場合には必要です。 UsbKbDxe / UsbMouseDxe USBキーボード/マウスを使えるようにするのだと思います。普通のマザーボードは使えるので不要だと思いますが、FileVault 2では必要になるようです。 VBoxExt2 / VBoxExt4 / VBoxIso9660 名前からして、Ext2, Ex4, ISO9660のファイルシステムにアクセスするためのドライバだと思われます。DVDから起動するにはVBoxIso9660が必要ということかなと想像します。 EFIドライバを整理してみる こうして見ると、結構不要なEFIドライバも多いようです。特にFileVault 2を使わないなら、かなりのドライバを省いても良いことになりそうです。今、このマシンのESPのdrivers64UEFIの中に入れてあるEFIドライバは、以下の10個です。\nApfsDriverLoader-64.efi AppleImageCodec-64.efi AppleKeyAggregator-64.efi AppleUITheme-64.efi AptioMemoryFix-64.efi DataHubDxe-64.efi FirmwareVolume-64.efi FSInject-64.efi SMCHelper-64.efi VBoxHfs-64.efi 上の情報によると、FileVault 2を使わないならば、以下の5個は不要のようです。\nAppleImageCodec-64.efi AppleKeyAggregator-64.efi AppleUITheme-64.efi DataHubDxe-64.efi FirmwareVolume-64.efi FileVault 2は使っていませんので、これらを除いて起動を試しました。なんの問題もなく起動しました。使っているのは以下の5個です。\nApfsDriverLoader-64.efi AptioMemoryFix-64.efi FSInject-64.efi SMCHelper-64.efi VBoxHfs-64.efi かなりシンプルになりました。\n*1:執筆時点のv2.4k r4586より少し前くらい\n","date":"2018-07-15T00:13:48+09:00","image":"/uploads/2017/09/20170916220921.png","permalink":"/posts/43/","title":"Cloverで使うEFIドライバ"},{"content":"更新：古い情報です。こちらの方法が良いと思います。(2018/9/8)\n昨夜、おそらく最後のHigh Sierraになる10.13.6が配布されました。すでに配布されているMojave Public Betaを使っていて気づいた変更点が、早々と10.13.6で導入されていました。大したことではないのですが、ESPパーティションをdiskutil mountコマンドでマウントする場合に管理者権限のパスワードが必要になりました。例えば、今までは、disk0s1にあるESPは、diskutil mount /dev/disk0s1 でマウントすることができました。しかし10.13.6で同じコマンドを実行すると、\n$ diskutil mount /dev/disk0s1 Volume on disk1s1 failed to mount If the volume is damaged, try the \u0026#34;readOnly\u0026#34; option のようにエラーが出てしまいます。readOnlyでマウントしても同様です。\n$ sudo diskutil mount /dev/disk0s1 として、この後、パスワードを入力する必要があります。\nESPをマウントするためのシェルスクリプト（改訂版） 以前、ESPをマウントするためのシェルスクリプトを紹介しました。\nESPをマウントするためのシェルスクリプト\n上記で紹介したスクリプトのdiskutil mountの行を、sudoで実行するように以下のように変更する必要があります。\nsudo diskutil mount /dev/disk${DRIVE}s1 ESPを自動バックアップする方法（改訂版） やはり、以前、ESPを自動でバックアップする方法を紹介しました。これも、パスワードが必要になったことで対応する必要があります。\nESPを自動バックアップする\nこの方式は、ログインするときにAutometorで作ったアプリケーションを起動する方法でした。これもパスワードに対応していないので、動かなくなってしまいました。パスワードを求めるように変更するのも良いのですが、いちいち、ログインするごとに、パスワードを入力するのは面倒です。\nそこで、macOSが起動した直後に、root権限でESPをバックアップする方法に変更することにしました。Launchd (ローンチデーモン)を使います。\nLaunchdを使う 以下のサイトなどでLaunchdの説明がされています。\nqiita.com\nコンピュータが起動したときに特定のプログラムを自動的に実行させる仕組みに、Linuxだとrcスクリプトがあります。大昔のDOSにはautoexec.batというのがありました。また、UNIX系OSでは、ある時間になったら特定のプログラムを自動的に実行させる仕組みにcronがあります。\nこのような仕組みを実現するために、macOSにはLaunchdがあります。これでrcスクリプトとcronの両方の機能を実現しています。ちなみに、cronはmacOSにも搭載されています。特定日時、時間、時間間隔でプログラムを実行させたい場合には、Launchdの他にcronも使うことができます。\nLaunchdでは、動かそうとするプログラム1つに対して、設定ファイルを1個用意します。これは、 launchd.plist と呼ばれる各種 XML ファイルです。以下に説明がありました。\nka-zoo.net\nlaunchd.plistは、 以下のいずれかの場所に置きます。\n/System/Library/LaunchAgents/ /System/Library/LaunchDaemons/ /Library/LaunchAgents/ /Library/LaunchDaemons/ ~/Library/LaunchAgents/ /System以下はmacOSが必要とするサーバなどのプログラムを置く場所であり、触らない方が良いでしょう。そもそもSIPで保護されているので簡単には変更できません。\nなので、自作プログラムの設定ファイルを置くとしたら、/LIbrary以下か、もしくは~/Library以下になります。LaunchAgentsとLaunchDaemonsフォルダの違いは次のようです。\nLaunchDaemonsフォルダに設定ファイルを置くプログラムは、サーバや常駐プログラムのようなデーモンであり、これはroot権限で機能します。 LaunchAgentsフォルダに設定ファイルを置くプログラムは、ログインしたユーザごとに、ユーザの権限で起動されます。/Library/LaunchAgents/には、全ユーザ共通で起動したいプログラムを、~/Library/LaunchAgents/には、特定ユーザのみで動作するプログラムの情報を書きます。 launchd.plistを作る 今回のESPバックアッププログラムは、macOSが起動した時点で、root権限で一回だけ起動させたいと考えました。root権限で起動すれば、diskutil mountでのパスワード入力も不要なはずです。ということで、/Library/LaunchDaemons/に設定ファイルを入れることにしました。\nそこで、以下のようなXMLファイルを作成して、/Library/LaunchDaemons/に置きます。このディレクトリにはすでに他のplistファイルが置かれているかもしれません。それを参考にしても良いです。\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;!DOCTYPE plist PUBLIC \u0026#34;-//Apple//DTD PLIST 1.0//EN\u0026#34; \u0026#34;http://www.apple.com/DTDs/PropertyList-1.0.dtd\u0026#34;\u0026gt; \u0026lt;plist version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Label\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;com.bootmacos.ESPbackup\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Program\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt; /Users/bootmacos/Documents/Hackintosh/backup_scripts/ESPBackupZ97A.command \u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;RunAtLoad\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/plist\u0026gt; このplistにはいくつかのキーを設定できますが、今回は、最小限の3個だけ使いました。\nLabelはこのプログラムを特定するための名前です。名前の作り方は全く自由ですが、他のファイルの例を見ると、開発者のURLを逆に書くことで、特定が簡単になる工夫をしているようです。 それに倣って、このブログのURLに機能名を加えて命名しました。 Programキーは、プログラムの場所です。ここはフルパスで書いておきます。起動時にはパスが張られていない可能性がありますので、エラーを引き起こさないために全部書いて置くのが良いです。 RunAtLoadは、Launchdがこのプログラムをロードしたときに実行するかどうかを決めます。 この他、常駐させるかどうかのキーもありますが、デフォルトで常駐しない設定なので、省略しました。この内容を、\n$ cd /Library/LaunchDaemons/ $ sudo vi com.bootmacos.ESPbackup.plist として、/Library/LaunchDaemons/以下に作ります。ファイルの名前も自由なのですが、これも特定しやすいように、URLを逆にして命名するのが一般的のようです。\nバックアップスクリプトを用意する 次に、実際にESPのバックアップを行うスクリプトを作成します。保存場所と名前は、上で作成したlaunchd.plistの内容に合わせます。スクリプトの内容は、Automatorで使ったものとほぼ同じです。パーティションUUIDの探し方は、以前の記事をみてください。\n#!/bin/sh ESPUUID=00000000-0000-0000-0000-000000000000 BACKUP=/Users/bootmacos/Documents/Hackintosh/currentConfig/MSIZ97AG7/ diskutil unmount $ESPUUID diskutil mount $ESPUUID rsync -av --delete --exclude \u0026#39;.*\u0026#39; /Volumes/EFI/ $BACKUP diskutil unmount $ESPUUID 最初のdiskutil unmountのコマンドは本来なら不要です。ただ、これが無い状態では、次のdiskutil mountコマンドがtimed outというエラーを表示して、うまく動作しないことがありました。ネット上で調べたら念のためにunmountしておくとエラーが出ないとあり、それを真似ました。快調に動いています。\nまた、rsyncのパラメータに–excludeを追加しました。ピリオドで始まる隠しディレクトリは不要なので、バックアップから外しました。\nここでは、root権限で起動するのでsudoをしていません。これでパスワードの入力をすることなく、ESPパーティションをマウントして、バックアップできるようになりました。\n完成したら実行可能に設定しておきます。\n$ chmod a+x ESPBackupZ97A.command\nLaunchd.plistの内容 今回、以下のディレクトリを見たところ、意外なファイルが入っていました。\n/Library/LaunchDaemons/ /Library/LaunchAgents/ ~/Library/LaunchAgents/ すでに使っていないドライバやアプリに関するplistや、心当たりがあまり無いplistなどです。macOSをクリーンインストールすると、これらのディレクトリは全て空です。なので、何かが入っているとしたら、アプリケーションのインストーラなどにより後から入れられたものです。特に、/Library/LaunchDaemons/はマシンが起動したら必ず起動して、しかもroot権限で動くプログラムです。時々はチェックして、起動するプログラムを把握して、おかしな設定が残っていたら削除するのが良いかと思います。\n","date":"2018-07-10T21:37:37+09:00","image":"/uploads/2018/07/20180710170425.png","permalink":"/posts/45/","title":"10.13.6でESPをマウントする権限が変更される"},{"content":"\nPublic Betaが出たのでMojaveを試してみたけど問題なく動いたのでひとまず安心。新機能も気に入ったけど、日常的に使うのは、9月の正式発表の時まで楽しみに待っていても良いかな。と、思ったあなた。例年ですとこの後、数回のアップデートが配信されるはずです。さらにはMojave体験希望者にはもれなく10.13.6 Public Betaも配信されています。\n正式版になってから受け取りたい、もうベータ版は要らないと思ったのに、アップデートはどんどんやってきます。他のアップデートと混じってわかりにくいです。うっかりクリックしたらインストールが始まってしまいます。そこで今回はmacOSベータ版の配信を止める方法の紹介です。\nそもそもなぜベータ版が来るようになったのか もちろん私がお願いしたからです。Public Beta参加のページからmacOSPublicBetaAccessUtilityというパッケージをダウンロードして、これをインストールしました。\nすると、すぐにApp Storeが開いて、Mojaveがインストールできるようになったのです。その後、アップデートも送られるようになりました。\nApp Storeの環境設定で止める ベータ版の配信を止めるメニューはApp Storeの「環境設定…」の中にあります。ここに、「お使いのコンピュータは、ベータ・ソフトウェア・アップデートを受信するように設定されています」という項目があります。この右にある「変更…」のボタンを押すと、「App Storeでベータ・ソフトウェア・アップデートを表示するのを停止しますか？」というダイアログが出ます。ここで「ベータ・ソフトウェア・アップデートを表示しない」ボタンを押せば、アップデートが来ても表示されなくなります。\nただしこの作業をしてしまうと、ベータ・ソフトウェア・アップデートに関するメニューは現れなくなってしまいます。配信中止ボタンを押したら後戻りはできません。再び配信して欲しいと思う場合は、もう一度macOSPublicBetaAccessUtilityを起動して、配信を開始してもらう事になります。\n","date":"2018-07-06T00:30:00+09:00","image":"/uploads/2018/07/20180705141105.png","permalink":"/posts/46/","title":"もうmacOSベータ版は要らないと思ったあなたに"},{"content":"Sandy Bridge CPUとIntel HD Graphics 3000を搭載したThinkpad X220でmacOS Mojave Public Betaが動きました。機種チェックをさせないようにブートオプション設定して、グラフィックスドライバーを入れれば動きます。\n前回のあらすじ Thinkpad X220にHigh Sierraをインストールする記事を書きました。\n/posts/53/\nThinkpad X220は、IBMが打ちやすさにこだわって設計したキーボードを備えた最後のモデルです。Sandy Bridge世代の製品で、MacintoshではMacBookPro8,1や、Macmini5,1に相当します。今回のMojaveでこれらは全てサポート外になりました。Thinkpadらしさを留めたX220が、現行macOSで動かなくなるのは残念なことでした。\nMojaveで動かない理由 Mojaveが非対応モデルで動かない理由は次の2点です。一つは、Mojaveの起動時にマシンのBoard-IDをチェックしていることです。チェックの結果、Mojave非対応モデルでは起動を中断します。この結果、画面に禁止マークが出て止まってしまいます。\nもう一つは、グラフィックスドライバーが提供されていない事です。Intel HD Graphics 3000のドライバーが、Mojave から削除されてしまったのです。\n(1) 機種チェックをさせないようにする Cloverを-vオプション付けて起動すると、禁止マークの裏で表示されているエラーメッセージがわかります。\nこの番号はconfig.plistのSMBIOSセクションに書き込んだ Board-IDでした。MacBookPro8,1 (Early/Late 2011) が内蔵しているボードのIDです。これをチェックして、Mojave対応モデルかどうかを調べているようです。\n機種チェックを行わないようにするには、Cloverのブートオプションに\n-no_compat_check を追加します。5chで教えてもらいました。例えばconfig.plistに以下のように設定します。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;-v -no_compat_check\u0026lt;/string\u0026gt; これでMojaveが一応起動するようになります。\n(2) グラフィックスドライバを入れる 機種チェックを回避すれば一応は起動します。しかし解像度は1024×768画素と低解像度で、解像度を上げることはできません。画面はチラつき、画面描画も遅いです。とても実用にはならない状態です。これはMojaveからIntel HD Graphics 3000のドライバが削除されてしまったからです。なんてことをするんだと思いますが、このモデルがOSの動作対象外になったので仕方ないところです。\nでも嬉しいことに、以前のバージョンからドライバを持って来れば動くという情報がtonymacx86にありました。\nwww.tonymacx86.com\nどういうわけか一世代前のSierraのドライバが良いようです。tonymacx86でこの方法を紹介してくれた人の話では、最初は直近世代のHigh Sierraのドライバを試したところ、ブラックスクリーンが出て動作しなかったそうです。そこで、もう一世代前のSierraを試したら成功したとのことでした。ということで、Sierra から、\nAppleIntelHD3000Graphics.kext AppleIntelHD3000GraphicsGA.kext AppleIntelHD3000GraphicsGLDriver.bundle AppleIntelHD3000GraphicsVADriver.bundle AppleIntelSNBGraphicsFB.kext AppleIntelSNBVA.bundle の6個のkext/bundleをMojaveに持ってきます。これを/System/Library/Extensions/に入れます。EFI/CLOVER/kextsの中に入れてもある程度動きますが、Maps.appなどの表示に問題が発生します。/S/L/E/に入れるとvanillaなシステムにならないのですが、仕方ないところです。/S/L/E/にkextを入れてパーミッションやキャッシュを設定するのは手作業でも可能ですが、今回はこのツールを使いました。\nまた、追加したkextを有効にするSIP設定をします。config.plistを以下のように設定します。通常、野良kextを/S/L/Eで使うには0x03にするのですが、今回はApple純正のkextなので0x02でも良いようです。0x01は信頼できないkextを許可する、0x02はファイルシステムへの制限を無効にする設定のようです。できるだけSIPの機能を生かすためには、最小限の0x02が良いと思います。\n\u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x02\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; Mojaveが動いた この結果、フル解像度でMojaveが動くようになりました。グラフィックスがちゃんと動いているかどうかを確認するには、Maps.appで地図が正しく表示されるかどうか、SafariでYoutube動画を再生できるかどうか、などを確認すると良いそうです。\n「このMacについて」を見ると、機種はEarly 2011のMacBook Proになっています。またグラフィックスもIntel HD Graphics 3000になっています。古いドライバが仕事をしていることがわかります。Mojaveでは本来起動もしない仕様なマシンであることが面白いと思います。\nMetalをサポートした機種のみがMojave対応になりましたが、Mojaveを動かすためにMetalは必ずしも必要ではないようです。今回Mojaveが非対応になった実機のMacでも、同じような手法でMojaveを動かすことが可能だと思われます。\nMojaveを動かすもう一つの方法 Mojaveのサポートから外された古いMacでMojaveを動かすためのパッチが公開されています。実機を対象としたパッチですが、Hackintosh でも有効と思われます。\nmacOS Mojave Patcher\nこのパッケージの中を見てみると、Intel HD Graphics 3000のドライバーなどが含まれています。おそらく、上で紹介した手法と同様に、古いmacOSから持ってきたドライバーを利用しているのでしょう。また、macOSにパッチを当てることで機種チェックを回避していると思われます。\n","date":"2018-06-28T22:44:01+09:00","image":"/uploads/2018/06/20180629123322.png","permalink":"/posts/47/","title":"Sandy Bridge搭載Thinkpad X220でMojave"},{"content":"\nいよいよMojaveのPublic Betaが公開されました。そこで早速Hackintoshで動かしてみました。去年のHigh SierraではAPFSが登場しました。でも今回のアップデートでOSの根本が大きく変化している箇所はあまり多くないようです。なので、すでにHigh Sierraが動いているHackintoshでしたらMojaveを動かすのは簡単です。10.13.4から10.13.5のようなマイナーアップデートと変わりません。(とは言え、High Sierra の時もapfs.efiを追加するくらいでした。)\nPublic Betaを入手する MojaveのPublic Betaを入手するには、Appleのサイト\nApple Beta Software Program\nで、macOSPublicBetaAccessUtility.pkgを入手します。Apple IDでのログインが必要です。\nこれをダブルクリックすると、App StoreからInstall macOS Mojave Beta.appをダウンロードできるようになります。\nmacOSPublicBetaAccessUtility.pkgがインストールされたマシンでないと、ダウンロードできません。しかし、一旦App StoreからダウンロードしたInstall macOS Mojave Beta.appは、どのマシンでも使用できます。\nインストールの手順は、こちらにも詳しく紹介されています。\nwww.itmedia.co.jp\nMojaveを導入・起動 こうして入手したInstall macOS Mojave Beta.appさえあれば、Mojaveの起動ディスクを作成できます。また、High Sierraに手を加えないVanillaなHackintoshならば、その起動用ESPを使って、Mojaveを起動できます。\nそこで、以下の手順でMojave起動ドライブを作成して、Mojaveを起動しました。ここではHackintosh上でMojaveをSSDにインストールしましたが、もちろん実機のMacで行っても良いです。\n現在のHigh Sierra起動用ボリュームのESPに入っているCloverとkext類を念のために最新にしておきます。これがHigh Sierraで起動することを確認します。 kext類を10.13のフォルダに入れている場合は、10.14というフォルダを作ってコピーしておきます。もしくはOtherに入れておきます。これでHigh Sierraを起動します。 新OSを試す為のドライブを用意します。今回は余り物の2.5inch SATA SSDを用意してHackintoshに接続しました。SATA接続でもUSBケースに入れてUSB接続でも良いです。動作は遅いですがHDDでもUSBメモリでも良いです。容量は32GBほどあれば良いです。このSSDをDiskutility.appでフォーマットします。パーティションスキームはGUID、フォーマットはMac OS拡張（ジャーナリング）にします。 ダウンロードしたInstall macOS Mojave Beta.appを開き、SSDにMojaveをインストールします。\nインストール途中で何回か再起動（たぶん２回）します。本物のMacの場合は自動で正しく再起動します。Hackintoshの場合は、再起動ボリュームが正しく引き継がれないことがあります。Cloverの選択画面で「Boot macOS Install from xxxx」という項目が選択されている事を確認してください。 Cloverの選択画面が「Boot macOS from xxxx」になったらインストールは終わりです。これを選択すれば、ユーザ設定などの画面になり、Mojaveを使えます。せっかくですからダークモードを試してみましょう。\nMetal非対応では導入できない？ 以上は、Apple社がmacOS純正ドライバーを提供しているRadeon RX 580搭載Hackintoshで作業しました。メーカー配布のドライバーがまだMojaveに対応していないNVIDIA GeForce搭載のHackintoshでインストール作業をしたところ、インストール途中でinstaller resourcesが足りないと言われてしまいました。なんのことか不明ですが、Metal対応のRadeonでは問題なかったことから、Metalに対応していないマシンではインストールできないという意味かと思われます。\nMojaveドライブにCloverを入れる これでMojaveが起動すれば、このドライブにClover類を入れて単体で起動できるようにするのは簡単です。以下の手順でESPを複製すれば良いです。\nMojaveを入れたドライブにCloverをインストールします。（このステップは飛ばしても良いと思います） High Sierraが動いているドライブのESPの内容を、MojaveをインストールしたドライブのESPと同一にします。上のステップでCloverを入れているなら、全部コピーしなくても、CLOVERディレクトリの一部だけを差し替えればokです。kextをバージョンごとのフォルダに入れている場合は、10.14というフォルダを作って入れるようにします。 色々なマシンでMojaveを起動 ここで作成したMojaveの起動SSDを手元のマシンで試してみました。HackintoshではHigh Sierraの起動で使用しているESPを使っての起動を行いました。\nAMD Radeon RX580搭載のHackintosh: 上のステップでMojaveインストールに使用したマシンです。Metal対応のドライバがmacOSに含まれているので、問題なく起動し、全てが快適に動作します。過渡期はmacOS標準サポートされているRadeon RX570/580は安心ですね。\nNUC DC3217IYE Hackintosh: Intelの初代Core i3 NUCです。NUCの初代はIvy Bridgeなので、実はNUC iGPUの多くがMetal対応していて、その結果、Mojave対応です。これも全く問題なく起動しました。\nNvidia GPU搭載Hackintosh: NVIDIAが配布するドライバー (Web driver) がMojaveに未対応なので、表示解像度が低いままで表示がちらつくものの、とりあえずは起動しました。Web driverが対応すればMetalが動いてMojaveが使えると思われます。まず大丈夫と思いますが、実際にドライバが出てみないとわからないですね。\nThinkPad X220 Hackintosh: 非対応CPUであるSandy Bridge搭載ThinkPadです。禁止マークが出て起動しません。\n-vオプションでエラーメッセージを見ると以下のようです。起動しない理由として表示される番号、Mac-94245B3640C91C81 は、MacBook Pro Late 2011 13インチモデルのBoard-IDでした。config.plistのSMBIOSセクションで指定したIDです。試しにこれを2012年モデルのIDである Mac-6F01561E16C75D06に変えてみたところ起動はしました。ただ解像度は低くちらつきます。Metal非対応のグラフィックスにはmacOS標準ドライバが提供されなくなったのかと思われます。実質的にMojaveは使えないです。\n実際に/System/Library/Extensionsを10.13.5と比較すると、Intel HD Graphics 3000に関係すると思われる名前のファイル（AppleIntelHD3000Graphics.kext, AppleIntelHD3000GraphicsGA.plugin, AppleIntelHD3000GraphicsGLDriver.bundle, AppleIntelHD3000GraphicsVADriver.bundle）がごっそりと消えています。\n**追記：**動きました\n/posts/47/\n古いMacBook: Mojave非対応のLate 2009 MacBookに接続して起動を試みました。Hackintoshではなく本物のMacです。X220の時と同様に、禁止マークが出て起動しません。Command-vで起動すると、やはり次のようなメッセージが出ていました。Mac-F22C8AC8はこの機種のBoard-IDです。このような古いMacもBoard-IDを誤魔化す手法でなんとか起動できるのかもしれません。ただその場合も、グラフィックスは低解像度でしか動かないと思われます。\n","date":"2018-06-27T22:43:49+09:00","image":"/uploads/2018/06/20180627124320.png","permalink":"/posts/48/","title":"macOS Mojave Public Beta版を試す"},{"content":"Thinkpad X220でHackintoshしたことのまとめです。結論としては、ThinkpadでHackintoshするのは面白かったけど、モバイルは実機で、デスクトップは自作Hackintoshというのがやはりお勧めだと思いました。\nまとめ x220.mcdonnelltech.com\n上記のサイトの情報とそこで配布されているファイルのおかげで、ほとんど試行錯誤することなくThinkpad X220を動かすことができました。キーボードやタッチパッドなどの動作をちゃんとさせるためにはおそらく色々と作業をする必要があったと思われますが、それが全部用意されていたことで大いに助かりました。スリープ、輝度調整、音量調整だけでなくてランプ(thinklamp)のon/offまでできる作り込みに感心しました。\nThinkpadの特徴的なトラックポイントでmacOSを操作するのは面白いです。トラックポイントは意外と便利で、癖になります。センターボタンを押しながらトラックポイントを操作すると、押しているだけでどんどんスクロールします。力加減でスクロール速度を調整できるのも良いです。ただトラックパッドでのピンチアウト、ピンチイン、スワイプなどのマルチタッチジェスチャ操作が出来ないので、macOSの操作で不便を感じます。特に、ピンチアウト・インでの拡大縮小操作が使えないのが不便です。\n一方、小さくて作りの良くないトラックパッドはオマケな感じです。トラックポイント操作中にトラックパッドにうっかり触れてしまうこともあるので、これはPrtScキーを押してoffにしておくのが良いです。コアなThinkpadマニアもきっとみなさんoffにしていると思います。\nしっかりした作りの古いキーボードも良い感じです。堅牢な作りの筐体で動くmacOSの画面を見るのも楽しいです。キーボードを含めて様々なパーツが、補修部品として多数販売されているのもありがたいです。キーボードのテカリも怖くないです。英語キーボードへの入れ替えも簡単です。\nできること 画面が出る。上記のサイトでも言及されていますが、稀にartifactが出ることがあります。メモリを増強すると頻度が下がるようですが仕方ない現象のようです。 スリープする。消費電力も数ワットです。 音が出る・マイクが動く。Siriの音声インタフェースも動きます。 Bluetooth / WiFiが動く。Thinkpad純正のBluetoothだとContinuityは効かないようです。 USB 3.0が使える。Core-i7モデルにだけ搭載されているUSB 3.0も使えました。ただ、上記のサイトによるとExpress Cardに挿すUSB 3.0カードがそのまま使えるそうです。無理してi7モデルにしなくても、使い道のないExpress Cardスロットを活用すればよかったかもしれません。 できないこと SDカードリーダは機能しません 指紋センサは動きません キーボードのマイクロフォン消音ボタンは機能しません 今後やるべきかもしれないこと LCDの交換。ほとんどのX220は安価なLCDなので、斜めから見ると表示品質が劣化します。このような現象が起きにくいIPS液晶モデルもオプションであったらしく、その液晶パネルが数千円程度で入手できます。表示が美しくなります。 無線モジュールの交換。Apple純正に近いモジュールに交換することでContinuityが動くと思われます。 macOS Mojaveを試す。今回のプロジェクトを手がけた直後に知らされた、Sandy BridgeがmacOS 10.14でサポート外になるという情報は少々ショックでした。Hackintoshなので、もしかしたら機種をごまかしてインストールできるのかもしれません。ただ、今回のアップデートにはMetal機能が関係しているようなので、Metal対応していないIntel HD Graphics 3000では全くダメなのかもしれません。Public Betaが配布されたところで試してみたいと思います。 追記：macOS Mojaveが動きました\n/posts/47/\n","date":"2018-06-24T00:30:43+09:00","image":"/uploads/2018/06/overview.png","permalink":"/posts/49/","title":"Thinkpad X220でHigh Sierra (4:最終回)まとめ・これから"},{"content":"\nApfsDriverLoader.efi\nClover 4558が先ほどアップデートされましたが、これに新しいefiドライバであるApfsDriverLoader.efiが追加されました。これをdrivers64UEFIに入れておくと、DiskIOプロトコルを利用してAPFSコンテナからapfs.efiをロードしてくれるものらしいです。5chで教えてもらいました。\nwww.insanelymac.com\nブートの手順とそれに必要なファイル類について、こちらで説明しました。ブートボリュームがAPFSの場合は、ブートストラップローダを読み込むためにapfs.efiが必要でした。しかし、ApfsDriverLoader.efiを使えば、手作業でapfs.efiを用意する必要がなくなりました。過去の記事にも加筆しておきました。\nHackintoshの長靴 (ブート)\n試しに、EFI/CLOVER/drivers64UEFIからapfs.efiを削除して、代わりにApfsDriverLoader.efiを入れて起動してみたところ、Cloverのブート選択画面で無事APFSディレクトリが表示されました。今までは、バージョンアップでapfs.efiが更新されると、そのたびに念のために新しくなった /usr/standalone/i386/apfs.efi をESPにコピーしていました。ブート時に自動で取り寄せてくれるのでこの作業が不要になったようです。\n","date":"2018-06-19T20:25:48+09:00","image":"/uploads/2018/06/20180619201031.png","permalink":"/posts/50/","title":"Clover 4558で登場したApfsDriverLoader.efi"},{"content":"今回は、WiFiカードを取り付けます。そのために、パッチを当てたBIOSに入れ替えます。パッチを当てる手順は前回に引き続き以下のサイトのお世話になりました。\nx220.mcdonnelltech.com\n（**前回の進捗：**X220がmacOS High Sierraで起動しました。）\nBIOSにパッチを当てる 最近のノートPCでは、カスタマーサービスの都合なのかパーツを勝手に変更できないように設定されています。オリジナルの構成から変更をしてもBIOSがその動作を阻止します。場合によってはコンピュータが起動しないこともあるようです。ちゃんと使っても良いパーツのリスト、white listがあって、それと合っているかをチェックしているようです。HackintoshではIntelの無線モジュールが動かないので、これを交換したいところですが、この仕組みに引っかかってしまいます。ということで、white listのチェックを行わないようパッチを当てたBIOSに交換します。これで無線モジュールを交換しても動くようになります。\nまずは、公式のBIOS 1.44にアップデートします。そこで、Lenovo社が配布している\nhttps://download.lenovo.com/pccbbs/mobiles/8duj29us.exe\nというWindowsのアプリケーションを使用します。これをWindowsの環境で、ダブルクリックして起動します。色々と警告が出ますが、承諾していけばアプデート完了です。元々のBIOSバージョンが1.39だったのが1.44にアップデートされました。\n次に上記のサイトで配布されているパッチ版BIOSに入れ替えます。\nhttp://www.mcdonnelltech.com/X220_v1.44_Modified_BIOS.zip\nこのファイルを解凍したフォルダの中に、Flash.batと言うファイルがあるので、これをWindows環境でダブルクリックして実行します。これも警告がいくつか出て、アップデートされます。バージョンは同じ1.44ですが、めでたくパッチ版に更新できたら、メニューにAdvancedが新たに現れているはずです。\nこれにより、純正パーツリストのチェックを行わないようにBIOSを改造することができます。\nBIOSの設定 上記のサイトでは、推奨のBIOS設定についても説明されています。\n先ずは工場出荷時状態にします。Load SetupからDefaultsを選ぶ 次にConfig \u0026gt; Power \u0026gt; Power On with AC Attach を Disabled 次にConfig \u0026gt; Serial ATA (SATA) を AHCI 次にSecurity \u0026gt; Memory protection \u0026gt; Execution Prevention を Enabled 最後にStartup \u0026gt; UEFI/Legacy Boot を Both (UEFI onlyでも問題ありません) ちなみに、この設定は、全部デフォルト値です。なので、工場出荷時状態にすればあとは何もしなくても大丈夫でした。\nBluetoothモジュール X220の裏側のネジを2個外すとキーボードが外れ、さらに5個外すとパームレスト部分が外れます。パームレスト部分は、軽く噛み合っているので、壊さないように慎重に取り外します。いずれもリボンケーブルで本体とつながっていますが、この下の無線モジュールソケットにアクセスするだけでしたら、ケーブルを外す必要はありません。\n今回入手したX220にはBluetoothが付いていました。Bluetoothモジュールは、パームレスト右手前のあたりにネジで止まっています。ソケットで本体と接続する小さな基板です。（ソケットのピンはUSBだと思われます）\nラベルを見ると、Broadcom BCM92070MD_LENOと読めます。最後の部分は、レノボモデルということかと思われます。この数字部分から推測すると、これは古いモデルのiMacやMacBookで使われているBroadcom社のチップBCM20702の仲間だと思われます。BCM20702はI-O DATA USB-BT40LEでも使われているチップです。\n「システム情報」で見ると、2070B0チップセットだと表示されます。また、BCM20702とは違って、Bluetooth 4.0ではなくて3.0のようです。\nラッキーなことに、X220のこのBluetoothチップはmacOSからそのまま認識されて使うことができました。キーボード、トラックパッド、Bluetoothイヤフォン、スピーカに接続することができました。キーボード類はsleepからの復帰にも使えます。iCloudで連携したiPhoneに電話がかかってくると応答もします。しかしContinuityには対応していないようです。\nWiFiモジュール X220にはIntelのhalf size micro PCIeソケットのWiFiモジュールが付いています。キーボードの右部分の下にあります。macOSで動くIntel WiFiのドライバはありませんので、これは使えません。\nこのモジュールの代わりのWiFiモジュールには、Dellの補修部品として出回っているDW1510がお薦めです。中身はBroadcomのBCM94322というチップです。これに差し替えれば、そのままでmacOSでWiFiを使えます。802.11 a/g/n対応で、5GHzも使えます。Atherosのチップを使ったDW1515もそのまま使えるようですが、macOS Mojaveでは使えないという話も聞きました。DW1510はAliExpressで多数出品されていて送料込み$7くらいで買えます。\nWiFi/BTコンボモジュール 上記のWiFi/Bluetoothモジュールは、1世代前のiMac/MacBookで使われた無線モジュールです。WiFiが802.11 ac対応で、Continuityにも対応していると思われるmini PCIeモジュールが手元にあるので、そのうち試してみたいと思います。\nAzureWave AW-CB150HはWiFiがa/b/g/n/acでBluetoothが搭載されたコンボカードです。BroadcomのBCM94360HMBというモジュールを使っています。数字部分が純正で使われるBroadcomモジュールと同じで、互換性が高いです。アンテナが3本のタイプです (WiFiが2本とBluetoothが1本）。アンテナのコネクタが、一般のmini PCIeのコネクタより小型のタイプなので、対応したアンテナが必要です。AliExpressの製品には、コネクタ形状を変換するケーブルが付属しているものもあります。X220のWiFiは2本アンテナなのですが、モジュール近辺に3G WAN用のアンテナが未使用で放置されています。3GならBluetoothに近い周波数もあるので、これをBluetooth用に使わせてもらうのも可能だと思います。もしくは、Bluetooth用にアンテナを買って、元からあるBluetoothモジュールを外して、その場所にアンテナを設置しても良いかもしれません。\n","date":"2018-06-16T01:30:00+09:00","image":"/uploads/2018/06/overview.png","permalink":"/posts/51/","title":"Thinkpad X220でHigh Sierra (3)BIOSと無線"},{"content":"今回は、macOSとCloverをインストールしたSSD/HDD/USBメモリを作り、これでX220を起動させます。\n（前回の進捗：Thinkpad X220にmacOSをインストールしようと思い立ち、機種選定して中古を発注しました。）\nX220が到着するまで時間がありますので、お迎えの準備をしておきたいところです。モバイルのHackintoshを作るのは久しぶりなので、macOSが立ち上がるのかどうか心配です。とりあえずでも起動すれば、あとの最適化作業の目処が立ちます。ということで、X220が到着したらhackintosh化が可能なことをすぐに確認できるよう、接続すればmacOSが起動するドライブを作っておきます。\n今回の試みでお世話になるのはこちらのサイトです。非常に丁寧に手順が説明されています。内容のアップデートも行われていてHigh Sierraの最新版に対応しています。 下のリンクはHigh Sierra対応のページです。\nx220.mcdonnelltech.com\nまた、必要なconfig.plist, kext類が一式揃えてあります。これがあれば、起動するドライブを作成しておくことは簡単です。このサイトで用意されている一式は、以下のリンク先にあります。これを入手しておきます。\nhttp://www.mcdonnelltech.com/X220_macOS_10.13_Utility_and_Kext_pack_04.24.2019.zip\nこれをダウンロードして解凍すると、EFIというフォルダがあります。その中に、BOOTとCLOVERというフォルダがあります。これをHigh Sierraを起動させたいドライブのESPに入れれば良いのです。\nmacOS起動ドライブを作る そこで、High Sierraの最新版 (執筆時点で10.13.5) が起動するドライブを作ります。macOSは、20GBくらいあればインストール可能です。それくらいの容量のUSBメモリでもokです。X220は、外部から割と簡単に（ねじ５本で）アクセスできる2.5インチドライブベイがあります。なので2.5インチのHDDまたはSDDを用意して、これに一式をインストールしても良いです。手元には、古い古い少容量の2.5インチSSDがあったので、それを使いました。これをSATAやUSBでmacOSが動いているマシンに接続し、macOSをインストールします。\nインストール終了したら、動いているマシンで起動することを確認します。ここでユーザの設定などを行ってしまっても良いです。またもしインストールしたHigh Sierraが最新版ではなかったら、ここでコンボアップデートを当てても良いです。\nESPにファイルを入れる macOS最新版をインストールしたら、そのドライブのESPをマウントします。例えばドライブがdisk3だったら、\ndiskutil mount /dev/disk3s1 というようにして、マウントします。ESPは、/Volumes/EFI以下にマウントされます。なので、\nopen /Volumes/EFI/ として、ここにダウンロードしたBOOTとCLOVERをコピーします。\nAPPLEというフォルダは、macOSインストーラが作ったフォルダです。このように、ESPにのみファイルを加えていて、macOS本体には何も手を加えていません。なので、完全にバニラな状態です。これで、X220で起動するドライブが完成したはずです。きっと、たぶん。\nThinkpad X220が到着 こんな準備をしながらワクワクしてお待ちしていたらThinkpad X220が意外と早く到着しました。 開けてみると外観は期待以上に綺麗でした。とはいえキーボードは、それなりにテカっていて、Aなどは字の一部が消えています。でもキーボードは後で取り替えるつもりなので、気にしません。\n起動するとWindows 7が入っていました。HDDは320GB, メモリは4GBx1でした。昔、iMacのメモリを増量した時に余った古いメモリ4GBx2が残っていたので、メモリ用の裏蓋を開けて交換しました。アップル純正メモリです。ネジ2本外すだけで簡単に交換できました。メンテナンスは今のMacBookシリーズとは比較にならないくらい簡単ですね。\n追記：AliExpressでキーボードを取り寄せて交換しました。裏のネジを２本外して、キーボードを上にスライドさせるとキーボードが外れます。本体と接続しているフラットケーブルを持ち上げてコネクタを外せば簡単に交換できます。テカリも文字消えも無い新品なので、気持ち良いです。\n用意したドライブは起動するのか？ では、いよいよmacOSを起動してみましょう。あらかじめ作っておいたドライブを接続します。USB外付けボックスを使っても良いです。USBの場合、USB 2.0ポートを使います。2.5インチドライブで起動ディスクを作ったのならば、すでに入っているHDDと差し替えても良いです。Thinkpadの脇にあるネジを1本外すとHDD格納ベイのカバーが外れて、HDDを引き出せます。HDDは、すぐに外せるゴムカバーの下で4本のネジで止まっているだけです。ちなみにHDDベイの部品は一式数百円くらいで買えますので、用意しておくとSSD/HDD交換が楽になると思います。\n起動ドライブを指定するには、Thinkpadを起動するときにF12キーを連打します。そうすると起動ドライブを選択する画面になります。これで、macOSのディスクを選びます。その結果、\nこのように見事に立ち上がりました。macOSが起動するドライブを作って、配布されているESPファイル一式を入れただけです。ファイル一式を用意してくれている、上記のサイトのみなさんのおかげです。\nトラックポイントと昔ながらのキーボードがエキゾチックで良い感じなのですが、LCDがほとんど水平になるくらいまで開くところもMacBookシリーズにない面白さです。搭載している液晶がパッシブマトリックスなので角度依存性が高くて真正面を外れると画質が悪いです。角度が大きく調整できることでその弱点も補えます。\nESPファイルの確認と調整 ということで、あっけなく起動しました。配布されていたファイルは何だったのか確認してみます。また、手を入れられるところは調整を試みてみます。\nBOOTX64.efi EFI/BOOT/の中に入れたファイルです。Cloverの本体ですので、Cloverのインストーラが入れるものと同じと思われます。新しいバージョンのCloverを入れれば、それに合わせて置き換わるファイルです。\ndsdt.aml EFI/CLOVER/ACPI/patchedに入れたファイルです。X220のDSDTにパッチを当てたファイルです。どう言うパッチを当ててあるのかわかりませんが、X220に合わせたファイルを配布してくれているおかげで、簡単に動かせました。そのまま使うことにします。\napfs.efi EFI/CLOVER/drivers64UEFIに入れたファイルです。今回は10.13.5に付属する最新のものが入っていました。macOS本体付属のものより古いようなら差し替えておくと良いと思います。また、HFS+のブートファイルを読み込むために、VBoxHfs-64.efiも入っています。\nOsxAptioFix2Drv-64.efi EFI/CLOVER/drivers64UEFIに入れたファイルです。動くものならこれよりも最新のOsxAptioFix3Drv-64.efiが良いと言われています。さらに、AptioMemoryFix.efiで動けば、そのほうがさらに良いと言われています。試したところ、AptioMemoryFix.efiで起動しましたので、これに差し替えて使うことにしました。\nこれ以外のEFI/CLOVER/drivers64UEFIのファイル類は、Cloverインストーラのデフォルトでインストールされる6個のファイル、\nAppleImageCodec-64.efi AppleKeyAggregator-64.efi AppleUITheme-64.efi DataHubDxe-64.efi FirmwareVolume-64.efi FSInject-64.efi に加えて、以下の3個が加わったものです。\nOsxFatBinaryDrv-64.efi SMCHelper-64.efi UsbKbDxe.efi kext類 使われているカーネル拡張は、以下の9種類です。\nACPIBatteryManager.kext ACPIPoller.kext AppleBacklightInjector.kext AppleHDA_20672.kext BlueTooth_Injector.kext FakeSMC.kext IntelMausiEthernet.kext IOAHCIBlockStorageInjector.kext VoodooPS2Controller.kext config.plist 配布されているconfig.plistのSMBIOSは簡易的なもので、シリアル番号などが入っていません。Clover Configurator.appを使って、config.plistを読み込んで、MacBookPro8,1のシリアル番号を生成して書き込んでおきましょう。シリアル番号を自動生成すると、例えば以下のようなSMBIOSセクションが得られます（この中のシリアル番号は一例ですので使わないでください）。\n\u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;BiosReleaseDate\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;01/25/18\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BiosVendor\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Apple Inc.\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BiosVersion\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;MBP81.88Z.004E.B00.1801250923\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Board-ID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Mac-94245B3640C91C81\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BoardManufacturer\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Apple Inc.\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BoardSerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;W89122501OPFF4PJC\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BoardType\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;10\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;BoardVersion\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;1.0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ChassisAssetTag\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;MacBook-Aluminum\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ChassisManufacturer\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Apple Inc.\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ChassisType\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x0A\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Family\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;MacBook Pro\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;FirmwareFeatures\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0xC00DE137\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;FirmwareFeaturesMask\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0xFF1FFF3F\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;LocationInChassis\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Part Component\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Manufacturer\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Apple Inc.\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Mobile\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;PlatformFeature\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0xFFFF\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;ProductName\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;MacBookPro8,1\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;SerialNumber\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;W89FT262DH2G\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Version\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;1.0\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; また配布されているconfig.plistでは、Bootのオプションが\n\u0026lt;string\u0026gt;slide=0 kext-dev-mode=1\u0026lt;/string\u0026gt; となっていますが、slideもkext-dev-modeも今は使われていないと思います。全部を消しても大丈夫なはずです。slideはカーネルを読み込むアドレスをずらすオプションです。0に設定してあるので、特に何もしない設定です。Cloverのソースを見たところでは、slide自体がすでに使われていないようでした。kext-dev-modeはEl CapitanでSIPが導入された時に、使用できなくなったオプションです。\nUSB 3.0 USB 3.0を動かす方法も上記のサイトに書いてあります。RehabManさんが作って配布してくれているGenericUSBXHCI.kextを以下\nhttps://bitbucket.org/RehabMan/os-x-generic-usb3/downloads/\nからダウンロードしてEFI/CLOVER/kexts/Other (もしくはバージョン番号のディレクトリ) に入れるだけです。\nこのkextが無いと、i7 Thinkpad X220の青いUSB 3.0 ポートは動きません。kextを入れると、「システム情報」には現れないものの、ちゃんと動きます。同じUSBメモリを3.0と2.0ポートに挿して速度を計測してみたら、3.0の方が4倍高速でした。\nサウンド 上記のサイトで配布されているkext一式に、AppleHDA_20672.kextが入っています。検索して見たところ、このkextを/System/Library/Extensionsに入れればそのままでサウンドが機能したと言う情報がありました。でも動きませんでした。もしかしたら手元の環境のせいなのかもしれませんが、多分、/S/L/Eでは無くて、ESPに入れたのがダメだったのかと思います。\nとはいえ、せっかくバニラな構成を目指しているので、/S/L/Eにkextを入れたくありません。そこでAppleALC.kextを試してみました。AppleHDA_20672.kextをESPのCLOVER/kexts/から取り出して、代わりにAppleALC.kextとLilu.kextの最新版を入れました。\nこの結果、問題なくサウンドが機能しました。マイクロフォンも動きます。キーボードの音量+/-のキー、消音キーも機能します。でもマイクロフォンoffのキーは機能しませんでした。\n続きはこちら\nThinkpad X220でHigh Sierra (3)BIOSと無線\n","date":"2018-06-09T02:00:00+09:00","image":"/uploads/2018/06/overview.png","permalink":"/posts/52/","title":"Thinkpad X220でHigh Sierra (2)準備・到着・起動"},{"content":"モバイルはMacにして、デスクトップでHackintoshするのが理想的です。\nMacintoshを買おう\nでも、あえて非合理的なHackintoshをするのも楽しいです。１台でも多くのマシンでmacOSを動かしたいと思っています。なので洗練されたエレガントなAppleハードウェアからかけ離れた無骨なマシンで、美しいmacOSが動くのを見るのも楽しいものです。\nということで、Macintoshハードウェアとは対極の、質実剛健なThinkPadにmacOSをインストールしてみたい欲望を抑えきれなくて、とうとうHackintoshしました。\nThinkPad X220を中古で調達 ThinkPadといえばご存知の通り、かつて世界を制覇したコンピュータ業界の巨人IBMが作り出したノートPCです。のちにLenovo社に売り渡されてしまいましたが、堅牢でミニマルな外観にはMacintoshとは違った機能美があります。\nThinkPadには多数の機種がありますが、Hackintoshしやすいと定評のあるThinkPad X220を選びました。後述しますが、インストールに関する情報をとても丁寧に紹介してくれているサイトもあります。ThinkPad X220より後の機種では、いろいろ問題があり、X220が最後のHackintosh向けThinkPadじゃないかという意見もあります。例えば後継機種のX230では、WiFi/Bluetoothモジュールが取り外せないようです。また、何よりもX220は昔ながらのThinkPadらしい無骨なキーボードを備えています。X230以降になると、今のMacのような、キーキャップ同士が離れているアイソレーションキーボードになります。こういう今風のキーボードも嫌いではありませんが、どうせHackintoshするなら、Macintoshらしくないハードウェアで作ってみたいものです。\n実機と同じCPU X220は、Sandy Bridge世代のMモデルCPUを搭載しています。Mac miniとMacBook Proの2011年モデルで採用されているCPUです。具体的には、Macでは以下のSandy Bridge Mモデルが採用されています。\nMac mini Mid 2011 (Macmini5,1) では 2415M, 2520M, 2620M MacBook Pro Early 2011 (MacBookPro8,1) では 2415M, 2620M MacBook Pro Late 2011 (MacBookPro8,1) では 2435M, 2640M このうちThinkPadでも採用されているCPUは、Core i5 2520M, Core i7 2620M, Core i7 2640Mです。 X220が採用しているCPUはどれもIntel HD Graphics 3000搭載のようで、Hackintoshのしやすさに関して差はないようです。でもHackintoshを目指して調達するなら、実機で採用されているCPUと同一のこの３種類を選びたいと思います。\nまた、X220は、Core i7モデルだけUSB 3.0を搭載しています。Sandy Bridge世代なのでUSB 2.0が主流なのは仕方ないところです。でも、高速なUSB 3.0が使えると色々とありがたいですので、ちょっと贅沢してCore i7モデルを選びました。でも、X220をHackintoshにするサイトの情報によると、PCIエクスプレスのUSB 3.0カードが動くらしいです。AliExpressでも類似のカードが販売されています。どうせ使い道のないPCIエクスプレススロットなので、これを買って、CPUはCore i5にしても良かったかもしれません。\n足なんて飾りです ThinkPadシリーズの良いところは、人気機種なので関連パーツをネットで調達可能なところです。AliExpressを見ると関連パーツがたくさん販売されています。\n英語版のキーボードの新品交換部品が販売されています。日本の中古屋さんで日本語キーボード機種を買っても、簡単に英語キーボードに置き換えることができます。日本のAmazonでは日本語キーボードも手に入ります。中古のノートPCでは、キーボードがテカってしまっていることが多いです。指の油でテカるのか、表面が摩耗して光るのか不明ですが、キーボードを差し替えて新品気分を味わえるのはありがたいです。なので、中古で販売されている製品で、「キーボードがテカってます」とか「一部のキーが欠けてます」というような但し書きは、安く買えるチャンスと読み替えることができます。\n「WiFiが動きません」という不具合も、多分問題ありません。搭載されているIntelの無線モジュールは、Hackintoshで使うことができませんので、最初から不要です。\nHDDやメモリの容量も、気にする必要はありません。SSDに差し替えて、メモリー増設することになると思うからです。ちなみに、X220の最大メモリーは仕様では8GBですが、実際には16GB搭載できるようです。\n時々「ゴム足が欠けています」という中古もあります。これなども狙い目です。AliExpressに行けば400円くらいでゴム足一式を買うことができるからです。ゴム足のことは気にしなくて構いません。\n本体、蓋、パームレスト、裏蓋なども修繕部品が出回っています。もうなんでもありですね。部品が調達できる場所の傷、欠け、ひび割れのために、中古価格が大きく下がっていたら、それもチャンスかもしれません。\nAmazonで調達 AmazonでX220の中古を物色してみました。 多数出品されていました。このうち実機で搭載されているCPUに限ると、Core i5 2520Mモデルが2.5万円前後、Core i7 2620Mモデルが3万円前後のようです。Core i7 2640Mは数が少なく7万円近いです。USB 3.0が欲しいならばi7 2620M、不要なら数も多くて多少安いi5 2520Mが良いようです。今回は、Core i7 2620Mモデルにしました。到着には4-5日かかるようです。\n追記：USB 3.0にこだわらなくても良かった？ AliExpressを見たら、ExpressCardのUSB 3.0アダプタが多数売られていました。X220にはExpressCardスロットが付いています。廃れてしまった規格なのでUSB 3.0くらいしか使い道はないかと思います。 ExpressCardはPCI Express端子（およびUSB 2.0）を使った端子ですので、内蔵されているUSB 3.0のチップの相性が良ければ、そのまま使える可能性があります。昔のMacBook ProにもExpressCardは使われていました。もしかしたら、こういうのを買えば良かったのかもしれません（試していません）。\n追記：macOS Mojaveは非サポート？ ワクワクして発注してしまいましたが、昨夜のWWDC基調講演によると、次のmacOSのMojaveではSandy Bridge搭載のMacBook Pro, Mac miniがサポート外になるようです。でもHackintosh的な抜け道があるかもしれません。(2018/06/05)\ncorriente.top\n追記：その後macOS Mojaveが動きました /posts/47/\n続きはこちら\nThinkpad X220でHigh Sierra (2)準備・到着・起動\n","date":"2018-06-04T18:02:15+09:00","image":"/uploads/2018/06/overview.png","permalink":"/posts/53/","title":"Thinkpad X220でHigh Sierra (1)機種選定"},{"content":"Hackintoshの情報は海外のサイトやフォーラムに多く掲載されていて、英語で読んだり質問する必要があります。そこで、Hackintosh関連でよく使われる英語表現をいくつかご紹介します。他にもたくさんあると思いますので、気づいたら追加して行きたいと思います。みなさんからの情報もお待ちしています。では辞典っぽくアルファベット順で：\nartifact もとの意味は人工物ということですが、コンピュータ関連の文脈では、画面・画像に現われる人工的な乱れやノイズを指します。自然な画像ではない、人工物的で無機質で異様な物体というニュアンスだと思います。プログラムやグラフィックスドライバの不具合で、ランダムなパターンが表示されてしまうことがあります。例えば、画面表示用に割り当てられたメモリーの一部に、プログラムの不具合で画像とは関係ないデータを書き込んでしまったりするとそのような症状が出ます。そのような不具合をartifactが出現するというように表現します。\natm at this time のことだと思います。 at the momentの略らしいです。「今のところ新CPUではmacOSが起動しない」というような文の冒頭で、atmって書かれてます。\nblackout 停電とか一時的な意識喪失・視力喪失というのが一般的な意味ですが、コンピュータ関連では、画面が真っ暗になり何も表示されないことを指します。Hackintoshだとグラフィックスドライバの不調で画面が出ない状況です。フレームバッファの指定が間違っていたり、その端子（HDMIとかDPとかDVIとか）に信号が供給されていない状況です。画面共有を設定しておけば他のコンピュータから接続できることがあります。また、ディスプレイ端子をつなぎ変えて別の端子を試して見るのも良いです。\ncross your fingers 中指を曲げて人差し指の上に重ねて十字架のような形を作る仕草のことで、成功を祈る・神頼みする意味です。「ドライバをインストールして、設定を変更して、再起動してあとはcross your fingers」というように、手順の説明などでよく現れる表現です。keep your fingers crossed という言い方もするようです。\nglitch たまに現れる機械の誤動作、電流や信号の異常というような意味です。もともとは電流が異常に急増するような状況 (a sudden surge of current) を指すようです。不具合や故障を意味する1960年頃の宇宙飛行士のスラングだったとか。\nコンピュータ関連では、こちらもartifactと同じく、画面が時々乱れたり、ノイズが発生したりする状況を表すために使われます。『シュガー・ラッシュ』（原題：Wreck-It Ralph）というディズニーのアニメ映画があります。コンピュータゲームのキャラクタ達が活躍する映画なのですが、前半ではそのヒロインがglitchと呼ばれていじめられています。プログラムの不具合で、ヒロインの顔や体の一部に時々ノイズが発生するからです。 あえて区別すると、glitchは一時的に発生する画面のノイズで、artifactは、一時的なものに加えて、持続的に表示し続けるノイズも含めているように思います。\nIMHO コンピュータ関連のフォーラムで時々見かける用語です。in my humble opinion (私のつまらない意見だけど)という意味で、文の書き出しで謙遜する場面で使われます。そこまで謙遜しない場合は、IMO (私の意見では)という言い方もします。\nin the same boat I am (We are) in the same boat. というように使います。直訳では「私も同じ船に乗っています」ですが、相手と同じ問題を抱えたり、同じような苦労をして共感できる気持ちを表します。例えばHackintoshのトラブル相談の投稿に対して「こちらでも同じ構成で、同じ問題が発生しているので私も解決策を知りたい」というような返答で使われます。\nlike a charm It worked like a charm. というと魔法のように効いて治った、という意味です。Hackintoshの不具合があったけど、助言に従って設定を少し直したら、効果抜群であっけなく治ってしまった、というような場合に使われます。charm (魔法、呪文) という言葉を使っていることから、「どういう理由で治ったのか仕組みが理解できないけど動くようになった」というニュアンスがあるように思います。\nLOL これは一般的なネットスラングで、lots of laughs や laughing out loud の略で「爆笑」という意味です。爆笑とまでいかなくても、日本語で笑とかwとか書く感じで使われている気がします。\nmod たぶんmodifyとかmodificationのことです。PC case modといえば、PCケースを改造することです。こうして作ったPCをmod PCとも言うようです。オリジナルのMacケースを流用して作るHackintoshもmod PCの一つです。\nApple純正ケースで作るHackintosh\nmobo マザーボード (motherboard) の略。長いので略すことが多いみたいです。日本語でも「マザボ」と言ったりしますよね。ちなみに中国語だと「母板」とも言うみたいです。\nNo entry sign 進入禁止マーク。macOSが正しく起動できない場合に、画面に表示されるアイコンです。厳密に言うと、交通標識の「進入禁止」ではなくて、「車両通行止め」に相当するマークです（海外でも車両進入禁止マークは、日本と同じく、丸い赤地に白い横長矩形です）。禁止マークというのが正しい気もします。このマークの裏には、起動できない状況のエラーが表示されています。Cloverの起動オプションに-vを追加すると、エラーの状況が文字で表示されます。エラー表示がされていたり、カーネルパニックの状況が表示されているはずです。これを手掛かりに、起動できない問題を解決します。\nnoob 初心者という意味。new boyなどが語源では無いかと言われています。昔は新入りを馬鹿にするような意味合いだったそうですが、今は、投稿の書き出しに「初心者なのでよくわからないのですが、」と謙遜して使ったり、「初心者向けガイド」で使ったりと、特に悪口という意味合いはないようです。\nof death コンピュータが動かなくなった状態を大げさに「死の〜」といいます。いろんなバージョンがあって、ポインタが虹色の円盤になったまま回復しないbeachball of death、またはspinning (pin) wheel of deathとか、画面が青い（黒い、灰色の）表示になって止まってしまうblue (black, gray) screen of deathなどがあります。BSOD/GSODなどと略すこともあるようです。Windowsだと青い背景に白い文字でエラーが表示されるブルースクリーンが有名ですね。BSODに相当する日本語の略だとブルースクリーンを縮めたブルスクかも。macOSだと、上述の禁止マークのような黒い背景 (black screen of death) や、これがグレーの背景に出るgray screen of deathになるかと思います。ブルースクリーンは出ないですね。\nちなみにアプリケーションが停止したときに出現する円盤ポインタは、光磁気ディスクが回転している様子を表したものです。初代のNeXTコンピュータでは、起動ディスク・システムディスクに光磁気ディスクという書き込み可能なDVDみたいな光ディスクを使っていました。これからデータを読み込み中のときに、光ディスクが回転する様子をポインタで表現していたのです。初代NeXTのディスプレイはグレースケールだったので、円盤ポインタもモノクロでしたが、のちにカラー化されて虹色になりました。光磁気ディスクの表面では、DVDやCDと同じように光が干渉するので虹色に見えます。それがmacOSでも引き継がれています。なので、あれをビーチボールと表現するのは間違っていると思います。\n昔話ついでに。昔のMacでは、起動時のハードウェアチェックでメモリーエラーなどが発生すると、悲しげなアルペジオが鳴り、画面にサッドマックアイコンが表示されました。あれは、死のチャイムchimes of deathとか死のアルペジオarpeggio of deathと呼ばれます。この機能は1998年のiMacから廃止されたようです。\noff the shelf 既製品なのですぐに手に入る、というような意味です。お店の棚にあるので、棚から手にとってすぐに入手できるという意味だと思います。特殊なパーツで一般には売られていないとか、古い製品なので中古屋とかeBayなどでしか手に入らないというような状況ではないということです。似た英語でon the shelfってのがありますが、これは棚上げされているという意味になるそうです。\nOOB out of the boxの略です。元々は、独創的で形にとらわれないという意味らしいです。箱に入りきらないという意味かな。コンピュータ関係の掲示板では、「箱から出したらすぐに使える: It works OOB.」という意味で使われています。パーツを買ってきて、箱から出して、コンピュータに取り付ければ、あとは、追加で色々設定することなく、すぐに使えるという意味です。Hackintoshで言えば、BCM20702を使ったUSB Bluetoothドングルとか、AMD Radeon RX-580などは、接続すればそのままmacOSで使えるのでOOBです。\nquirk OpenCoreのconfig.plistの設定にquirksという設定項目がたくさん登場します。主に、特定の現象に対応するために、パッチや対応を有効にするかどうかの項目です。辞書によるとquirksは、予想外の曲がり、ひねり、気まぐれのような意味だそうです。Ubuntu wikiの記載によると、ハードウェアのバグを回避するためのソフトウェア手法というような意味だそうです。そんな箇所は、多分、ソースコードを読んでプログラムの流れを追っていくと、「なんでこんなことやっているんだろう」と不思議に思えると思います。それで不具合を回避するための（それだけ見ると）意味不明なプログラムの流れということから、予想外に曲折した状態というニュアンスで使われているのではと思います。\nvanilla バニラアイスクリームのように素材のままという意味です。 Hackintoshでは、macOSのkextやディレクトリ構成に手を加えずにオリジナルのままに保ってインストールすることを、バニラなインストール手法と呼んでいます。OSアップデートのたびにパッチを当てる必要が無いので、メンテナンスが楽です。\n/posts/131/\n","date":"2018-05-23T00:30:00+09:00","image":"/uploads/2018/04/20180405143658.png","permalink":"/posts/54/","title":"Hackintosh英和辞典"},{"content":"\nHackintosher.comの記事紹介です。Z370マザーボードとCoffee Lakeを使ってHackintoshを作りたいという場合に役立つ記事だと思います。\nhackintosher.com\nパーツ選択 High Sierra 10.13.Xを使えばCoffee Lakeはそのまま使えます。iGPUも使えます。Nvidia/AMDのグラフィックスも安定して使えます。この記事では、\nCPU: Intel Core i7-8700k マザーボード：Gigabyte Z370 AORUS Gaming 7 グラフィックス：Gigabyte AMD RX 560 4GB OC SSD: SAMSUNG 960 EVO NVMe SSD の組み合わせを紹介しています。しかし、tonymacx86のガイドで紹介されているパーツなら、これ以外でも同様に問題なく動くと思われます。\nwww.tonymacx86.com\nただ、この記事の手順で期待通りの成果をあげたいのでしたらマザーボードは同じものにした方が良いかもしれません。 グラフィックスはNVIDIAでも良いと書かれていますが、現時点ではAMDが良いです。NVIDIAは最近のmacOSで不具合が報告されています。どの環境でも発生する不具合ではないですし、今後のNVIDIA提供ドライバで解決されると思われますが、macOS標準のドライバで動くAMDの方が安心です。 この記事では、RX 560を使っていますが、もし予算に余裕があるなら、RX 570かRX 580を検討してください。Apple社やSonnet社がmacOSと互換性があると表明しているチップです。Sonnetのリストでは、RX 560はmacOSと互換性が無いとされていますので、今は動いても将来、スリープ復帰などで問題が出てくる可能性があります。 /posts/139/\nNVMe SSDもSAMSUNG EVOシリーズ以外でも動くと思われますが、新規に購入するのであれば他の製品を購入してあえて冒険する必要もないです。（もし動いたらぜひ教えてください） これ以外のパーツ（メモリ、HDD, 電源など）はどれでも良く、tonymacx86のリストから選ぶ必要すらありません。 Clover設定とkext 上で紹介した、Hackintosher.comのページで、ESPに入れるべきファイルの一式を配布しています。これをSSDのESPにそのまま入れるだけで大丈夫なはずです。内容には多少気になる点はありますが、とにかく起動するファイル類を配布してくれているのは初心者にとってありがたいと思います。気になる点は以下です。\nRX 570/580を使うならWhateverGreen.kextは不要です。互換性が低いと思われるRX 560のために必要なのかもしれません。 またconfig.plistでのAppleGraphicsDevicePolicy.kextへのパッチも不要です。これはNVIDIA向けのものです。 ついでに、config.plistにNvidiaWebがtrueになっていますが、AMDを使っているのでfalseで良いはずです。 シリアル番号とBoardSerialNumberは変更しておいた方が良いです。このまま使うと、iMessageなどのサービスを使う時に同じ番号が重複する危険があります。 USBの上限を撤廃しているパッチもあまり使わない方が良い気がします。 OsxAptioFix2Drv-64.efiを使っていますが、もし問題なく起動するならば、これの代わりにAptioMemoryFix.efiを使用するべきです。 他にも気になるところはありますが、配布されている内容で問題なく起動すると思います。そのあとで、config.plistの内容を理解しつつ、シンプルな構成に試行錯誤して書き換えていけば良いと思います。こちらを参考にしてください。\nconfig.plistの実例紹介\nマザーボードを設定する 以下のように設定すると良いようです。\nSave \u0026amp; Exit → Load Optimized Defaults M.I.T. → Advanced Memory Settings Extreme Memory Profile(X.M.P.) : Profile1 BIOS → Fast Boot : Disabled BIOS → LAN PXE Boot Option ROM : Disabled BIOS → Storage Boot Option Control : UEFI Peripherals → Trusted Computing → Security Device Support : Disable Peripherals → Network Stack Configuration → Network Stack : Disabled Peripherals → USB Configuration → Legacy USB Support : Auto Peripherals → USB Configuration → XHCI Hand-off : Enabled Chipset → Vt-d : Disabled Chipset → Wake on LAN Enable : Disabled Chipset → IOAPIC 24-119 Entries : Enabled こちらもご覧ください。\nマザーボード (BIOS) 設定\nこの後グラフィックスの設定をします。このHackintosher.comのガイドでは、グラフィックスカードを使用する場合は、iGPUをDisabledにするようにと書かれています。手元のマシンで経験したところでは、iGPUをDisabledにしているとあるタイミングでAMDのグラフィックス性能が急激に低下します。Enabledにしておくのが良いと思います。以下をご覧ください。\n/posts/62/\nインストール手順 インストールの手順は、通常とほぼ同じですが、ESPに提供されたファイルを入れて使います。インストール用USBメモリなどにより起動用SSDにアクセスできる状態で、以下のステップを行います。\nSSDをフォーマットする macOSをこれにインストールする CloverをESPにインストールする（これは省略可能） ESPに入ったファイルをHackintosher.comで提供されているファイルと置き換える 3.は省略可能ですし、2.と4.の順番を逆にしても大丈夫なはずです。本ブログの解説記事も参考にしてください。\nHackintoshの作り方（総集編:10.13版）\nまとめ この記事の説明と配布ファイルで、とにかく起動すると思われますので、特に初めて挑戦する方にとってありがたいページかと思います。とにかくHackintoshが動けば安心できます。動いたところで、config.plist, kext, efiドライバなどを調査して最適化すると良いと思います。\n","date":"2018-05-10T22:37:37+09:00","image":"/uploads/2018/05/20180504120215.png","permalink":"/posts/55/","title":"Gigabyte Z370 AORUS Gaming 7, 8700K"},{"content":"自作PCの楽しみ方の一つにcase mod (ケースモッド：PCケースの自作改造) があります。ゼロからケースを自作したり、市販のケースをもとに芸術的もしくはオタクな装飾を加えて改造することです。また、かっこいいメーカー製デスクトップ筐体を利用してそこに標準的なマザーボードを組み込む楽しみ方もあります。「かっこいいメーカー製筐体」といえばApple製品が代表的なので、古いMacを改造して最新のPCに作り変える例が、ネットで多数紹介されています。こうして古いMacに組み込んだ最新マザーボードで、Hackintoshを動かす人も多いです。\n古いMacを改造してHackintoshすることのメリットになるのかどうかわかりませんが、よく議論されるのがライセンスの話です。ご存知のようにmacOSの使用許諾書（EULA: End User License Agreement) には「macOSはApple製のMacにのみインストールできる」と書かれています。これに同意しながらHackintoshすることはApple社との契約違反になります。一方でMacのケースにATX基板を入れれば、Apple製コンピュータを最新の部品に交換しただけと主張できなくもないです。その主張が通るのかどうかわかりませんが、100%他社製品でHackintoshするよりも契約違反の度合いが少ないのは確かです。\nデザイン重視Macを改造 Hackintoshをしている人たちの大多数は、MacのハードウェアやmacOSを非常に気に入っているものの、デスクトップ製品のラインナップに不満を持っています。Mac miniとMac Proの中間のデスクトップが欲しいとか、ディスプレイ無しのiMacが欲しいとか考えています。また、新しいCPU/GPUに世代交代しても一向に新製品が出ず、かといって最新の部品に交換したり拡張する手段が無いことにも不満を感じています。Macの外観を持ったままで、最新のハードウェアで作り直すことができれば理想的です。ということでtonymacx86でも、Macを改造してHackintoshしたという投稿が多数あります。そのために、case modのコーナも用意されています。\nここでは様々なMacがHackintoshに改造されています。Macの歴史の中でも、デザインが秀逸で人気のあるモデルの一つがPower Mac G4 Cubeです。多くの人が、G4 Cubeの改造を手がけています。この筐体は、Mac Pro 2013と同様に、筐体の中央が放熱板になっていて、下から上に煙突のように空気が流れる構造です。コンピュータの中身をスライドして取り出せる機構もあり、改造には高度な工作技術が必要です。多くの例では、mini ITX基板に交換しています。標準的な基板を搭載できるよう改造することで、いつでも最新のCPU、チップセット、メモリを使用した高性能なmacOSマシンになります。\nG4 Cubeにmini ITX基板を取り付ける様子を紹介した日本語動画もあります。\nMac G4 Cubeで自作がしたい！#1 分解＆筐体加工 ★ I want to make my own with M\u0026hellip;\n歴代Macの中で、おそらく一番奇抜なデザインだったのが、最初の液晶ディスプレイ (LCD) 搭載iMacです。白い半球型の本体、自在に動かせるアーム、このアームに取り付けられたLCDの構成です。この改造も難易度は高いです。LCDからのケーブルを配線し直してDVIにします。本体部分は、非常にコンパクトなので、NUCが使われます。\nMac Pro/PowerMac G5ケース 一方で筐体の大きなデスクトップ機を使えば、改造はずっと簡単です。大型のデスクトップMacには、Power Macintoshシリーズ、Power Mac G3/G4/G5、タワー型のMac Proがあります。Power Macintoshシリーズは、古くて中古市場にあまり出回っていないことと、Apple暗黒時代の凡庸なデザインなので、これをmodする例はほとんどありません。一方、Jobsが復帰してからのPower Mac G3/G4は、ポリタンクと言われた独特の形状と透明感のある外観で、いまだに人気があります。modのためのキットも売られています。ただ、筐体表面はポリカーボネートですが、筐体内部が硬い鉄製であることと、光学ドライブが標準マザーボードと干渉しやすい構造なので、工作が大変です。\nこれに対して、Power Mac G5と、その形状を引き継いだタワー型Mac Proは、大型で内部空間に余裕があり、素材が柔らかいアルミニウムです。そのため加工が容易で、標準mATX/ATXマザーボードを組み込みやすいです。改造してHackintoshにするには最適な機種です。\nG5とMac Proのどちらが改造に適しているか もしMacのケースにATXマザーボードを組み込むなら、Power Mac G5とタワー型Mac Proのどちらを改造したらよいでしょうか。結論としてG5の方が適しています。\nまず、G5の方が安価です。タワー型Mac Proは、設計が色々と古くなってしまってはいますが、インテルCPUを使用していますし、拡張の余地があるためにまだ実用性があります。CPUを差し替えて性能向上させる人も多いです。そのため中古市場やオークションでもある程度の価格がついています。一方でG5は、流石に古くて、なおかつCPUが古いPower PCであるため、ほとんどがジャンク品として売られています。ケースだけを利用して改造する場合には、中身に価値を求めませんのでG5で十分です。\n改造にG5が適している理由は、価格以外にもあります。一見すると、G5もタワー型Mac Proも穴が多数開いたパンチングパネルの似たような筐体ですが、レイアウトがかなり違います。こちらに比較があります。\nMac Pro vs. PowerMac G5 – Apple’s Mac Pro – A True PowerMac Successor\n正面から見た一番の違いは、光学ドライブの個数です。G5は一台を搭載しますが、Mac Proは2台搭載可能です。でも今時、光学ドライブは1台あれば十分です。不要と思う人も多いくらいです。3.5 インチドライブに関しては、G5は2台、Mac Proは4台内蔵可能です。でも最近は2.5 インチ やm.2のSSDを多数使うことが多くなりました。またMac Proの3.5 inchベイは特殊な配置で、標準マザーボードを搭載した時に利用し難いです。光学ドライブや3.5インチドライブが衰退しつつある今から見ると、皮肉なことに、古いG5の方が新しいProよりも現状に即した設計だと言えます。\n内部の違いも見てみましょう。下の写真は、左がG5で、右がProです。\nどちらも、水平の仕切り板が1枚、棚板のようにあり、上部と下部に分かれています。G5は、上部に光学ドライブが1台、3.5インチHDDが2台配置されています。Proは上部に光学ドライブが2台、電源が配置されています。仕切板上部空間は、G5の方が狭いです。そのためG5の方が、仕切板下のメイン部分が大きいです。メイン部分が大きいG5の方が、部品配置を柔軟に行えるので有利です。\nG5とProでは拡張スロットの数も違います。G5は4本で、Proは5本です。micro ATXのスロット数は4本なので、G5ケースを使うとそのまま全部有効利用できます。Proを使うとスペースが余って無駄が出ます。もっとも、スロット数の多い標準ATXを使う場合は、どちらも加工が必要です。\nProの電源は、標準的なATX電源に近いサイズなので、改造する場合にオリジナルの場所に電源を設置しやすいのではないかと思われるかもしれません。しかし、タワー型マシンで使うような容量の大きいATX電源は、上部もしくは下部に大型のファンがあり、そこから吸気します。Proの電源設置場所は、上下に開口部がありませんので、電源のエアフローが不利です。筐体上部に穴を開けてしまえばよいのですが、見た目が気になります。\nG5の電源は、写真ではわかりにくいのですが、最下部にあります。平たい特殊な形をしています。元の形状を尊重してcase modする人は、標準ATX電源をバラして、平らに配置し直して、G5の電源部分に収納している人もいます。ただ、G5の電源は取り払ってしまって、そこに通常のATX電源をおくことも可能です。メイン部分が広いことのメリットです。\nということで、Macのタワー型アルミニウム筐体をHackintoshに改造するなら、Mac Proよりは、Power Mac G5の方がおすすめかと思います。こちらのブログでは、Power Mac G5やMac Proの改造が紹介されています。日本語の情報は少ないので、参考になります。\nまたYoutubeで”G5 mod”のようなキーワードで検索すると、参考になる動画が多数見つかります。\nhttps://www.youtube.com/results?search_query=g5+mod\ntonymacx86では最新のCoffee Lakeで作った例も紹介されています。\nLaser Hiveの改造キット Macの筐体を改造する場合に苦労する点は、オリジナルとは形状の違うマザーボードの取り付け方法と、そのバックパネルの加工です。こちらのサイトでは、MacケースにATXマザーボードを搭載するためのキットを販売しています。Power Mac G3/G4/G5とMac Pro用のキットを販売しています。\nこれらのキットを使わなくても改造は可能です。特に、Power Mac G5とMac Proは、アルミニウム製で加工が簡単なので、キットを使わなくても改造できなくはないですが、キットを使えば楽になります。上で紹介したサイトでも、Laser Hiveのキットを使った例が紹介されています。\nPower Mac G5とMac Pro向けに、Laser HiveではATXマザーボードとmicro ATX (mATX)マザーボードを取り付けるためのキットをそれぞれ販売しています。Power Mac G5向けには、\nオリジナル92mmファンx2を使ったmATXボードキット 120mmファンx1を使うmATXボードキット オリジナル92mmファンx2を使ったATXボードキット 120mmファンx1を使うATXボードキット があります。\nG5にはもともと4本の拡張スロットがあり、これはmATXの拡張スロット本数と同じです。なので、mATXボードキットは、オリジナルの拡張スロットをそのまま活かすことができます。また、オリジナルの92mmファンを使用するキットでは、元々あるファン取り付けプラスティック部品や、ファンの排気カバーなどを再利用します。なので、Macの元々の形をできるだけ残したい場合には、「92mmx2ファン＋mATXキット」が適しています。一方、mATXマザーボードは製品の種類が少ないので、それが気になる人は標準ATXのキットが良いと思います。\nG5改造の手順 Laser HiveのmATXキットを使って、壊れて廃棄されたG5を改造したことがあります。大した作業ではないのですが、予想以上に手間がかかりました。市販のPCケースを買ってきて組む方が圧倒的に簡単です。手作りする楽しさはありますが、それ以上に、G5の外観を生かしたマシンを作りたいという強い思いが必要です。手順は、以下のようになります。\nジャンクのG5をバラして掃除します。CPUカバーだけは1本の樹脂製ピンを壊さないと取り外せません。他は、破壊せずに分解できます。サイドパネルをロックする機構の分解には、知恵の輪を解くような根気が必要です。でもこれが外せないと棚板、HDD冷却ファン、HDD取り付けケージを外せません。埃を払って綺麗にします。 利用できるパーツを残して、不要なパーツは捨てます。ロジックボードなども捨てることになります。ファン取り付け部品、HDD取り付け部品、スイッチ類、ケーブル類、電源ケーブルソケット、カバー類などを上手に利用できれば、オリジナルの雰囲気をより活かせます。 ロジックボードを取り付けていたスペーサのうち、不要のものは取り外します。スペーサは溶接されたようにケースに固定されていますが、ハンマーで叩くと、簡単に外せます 。ただしLaser Hiveのマザーボードトレイを取り付けるために使用するスペーサは、外さず残します。 裏側パンチングメタルを切り取ります。Laser Hiveのバックパネルの形に合わせて切り取ります。アルミなので、加工は楽です。 Laser Hiveのマザーボードトレイとバックパネルを取り付けます。 マザーボード、ファン、電源、HDDを取り付けて配線します。 手作りのPCケースですので、市販のPCケースに比べると保守やアップグレードが面倒です。でも実機と同じ見た目の美しいHackintoshを作り上げる満足感があります。\n","date":"2018-05-03T11:03:40+09:00","image":"/uploads/2018/05/20180415124036-1.jpg","permalink":"/posts/57/","title":"Apple純正ケースで作るHackintosh"},{"content":"以下で、Hackintosh向けのWiFi / Bluetoothアダプタについて紹介しました。\n/posts/138/\n実機で使われているBroadcom社のチップセット、\nBCM94360CD (2013年採用) BCM943602CS (2015年採用) を搭載したアダプタがお勧めです。これらを使うと、Hackintoshに取り付けるだけで、何の設定もせずにそのまま動いて、本物のMacintoshと同じくContinuity連携ができます。\n今回は、Apple WatchでMacのロックを解除する機能をHackintoshで試してみます。使ったHackintoshにはBCM94360CDを使用した無線アダプタを搭載しています。このHackintoshと、Apple WatchをペアリングしたiPhoneとのContinuityが確立されている状態で、「システム環境設定」「セキュリティとプライバシー」「一般」を開くと、「Apple WatchでこのMacのロックを解除できるようにする」という項目が選択できるようになっています。これにチェックを入れれば準備完了です。\nこの設定を行い、Apple Watchを装着していると、いつものログイン画面に、「Apple Watchでロック解除中…」の表示が出ます。これでパスワード入力を省略してMacにログインできます。\nApple Watchを手首に着けていなかったり、Bluetooth圏外（3m程度）だったり、Apple Watchがロックされていたりすると使えません。なので万一放置したApple Watchを他人に使われても、解除される心配はありません。また、Apple WatchとペアリングしているiPhoneがその場に無くても、その電源がoffになっていても自動解除が機能します。Apple WatchとのBluetooth通信だけで解除機能が完結しているようです。\n","date":"2018-04-24T00:30:00+09:00","image":"/uploads/2018/04/51wFomSFsmL-1._SL250_.png","permalink":"/posts/58/","title":"Apple Watchでログイン"},{"content":"更新：macOS 10.15.1以降の情報はこちらをご覧ください。(2019/11/4)\nSonnetの互換GPUリスト (10.15.1以降)\nmacOSで使えるGPU MacのThunderbolt 3コネクタに接続する外部GPUボックス\nを販売しているSonnet社が、macOS 10.13.4以降と互換性のあるグラフィックスカードの一覧を公開しています。 eGFX Breakaway Box for AMD and NVIDIA GPUs | Sonnet 各ブランドごとの多数のモデルを掲載しています。Sonnetの外部GPUボックスは、AppleのExternal Graphics Development Kitにも採用されているほぼ純正みたいな存在です。なので、このリストで互換性があるとされたグラフィックスカードは、Hackintoshで、そのまま動くカードと考えて良いです。互換表のPDFファイルは以下から入手できます。市場に出回っている多数の製品に対して互換性がチェックされているようですので、Hackintosh用グラフィックスカード購入の際は、これで確認しておきましょう。 http://www.sonnettech.com/support/downloads/manuals/Compatibility_Graphics_Cards.pdf これを見ると、例えば、AMDリファレンス（ファンデーション）バージョンでは、以下の機種（Mがマークされた機種）がmacOSと互換のようです。 また、ブランドごとの差は無いようです。GPUチップによってのみ互換・非互換が決定するようです。まとめると以下のようになります。\nRX 470, RX 480, RX 570, RX 580はどのブランドも互換性あり RX Vega 56/64はどのブランドも互換性あり RX 460/550/560は互換性なし R9 NANO/FURY は互換性なし WX 5100は非互換で、WX 7100, WX 9100は互換性あり NVIDIA GeForce は互換性なし 外部GPUを使えるMac 前述のサイトでは、SonnetのThunderbolt 3接続eGPUボックスのマニュアルも公開されています。 http://www.sonnettech.com/support/downloads/manuals/macos_egpu_info.pdf 以前、こちらで紹介したマニュアルの改訂版です。\nSonnetの互換GPUリスト (10.13.2以降)\n以前のマニュアルではThunderbolt 2搭載Macの一部もサポートすると書いてありましたが、新しい版では、Thunderbolt 3搭載Macに限定されたようです。具体的には、 2016年以降のMacBook Pro 2017年以降のiMac iMac Pro です。この構成でHackintoshすればかなり安心です。ただ、このリストは、Thunderbolt 3が搭載されていることが条件になっていると思われますので、PCIeで接続するHackintoshでは、これ以外の構成でもまず大丈夫です。実際、手元ではiMac15,1で構成したHackintoshでRadeon RX 580が何の問題もなく動いています。 ただ、Sonnetの上記の古い方の資料によると、Thunderbolt 2搭載Macのうち、IntelのiGPUを使わない・搭載しないMac Proなどが互換リストから外されていました。iGPUを動かさないとAMDグラフィックスカードのGeekBenchスコアが低下する現象\n/posts/62/\nもありますので、それと関係があるのかもしれません。\n","date":"2018-04-17T00:30:00+09:00","image":"/uploads/2018/04/20180416222802.png","permalink":"/posts/59/","title":"Sonnetの互換GPUリスト (10.13.4以降)"},{"content":"本物のMacと同じように機能させるのがHackintoshの目的なので、コミュニティの皆さんは日々ハッキングしています。その結果、ほぼ、本物と遜色ない機能を実現していますが、中にはあまり成功していない機能もあります。その一つが、Thunderboltではないかと思います。Thunderboltはそこそこ動きます。でも完璧ではありません。次のような問題があり、解決できていません。\nHot plugが効かない。起動時に接続されているThunderbolt機器はPCIe接続機器として認識されて機能するけど、起動後に接続した機器は認識されない。 スリープからの復帰で、認識されていた機器も見失うなどの問題が発生する。 それでもどうしてもThunderbolt機器を使いたい分野もあるようで（特にサウンド関係かな？）、hot plugを諦め、スリープさせない使い方をしているユーザも多いようです。\nThunderbolt (初代) 実は私がHackintoshで試したことのあるThunderboltは初代・無印のものだけです。インテルNUCの初代モデルDC3217BYに搭載されていたThunderboltです。これに、Apple社のThunderbolt-Ethernetアダプタや、市販のThunderbolt接続HDDを接続してみました。いずれも、起動時に接続してあれば、何の問題もなく機能しました。しかし、起動後に接続した場合は認識されません。また、スリープ復帰後は機能しませんでした。\nThunderbolt 2 80シリーズマザーボードあたりから、Thunderbolt 2を搭載したマザーボードが登場しました。Macと同じThunderboltチップを使用していたこともあり、コミュニティでの期待が高まりましたが、当初は全く使用できませんでした。皆が試行錯誤し、苦戦しているときに、とある人が「WindowsでThunderbolt 2を使用した後、macOSで起動したら使えるようになった」と報告しました。信じられない現象でしたが、次々と成功例が報告されました。でも、Hot plugが効かない問題、スリープ復帰の問題はそのままでした。\nThunderbolt 3 Thunderbolt 3になると、マザーボード上に実装した製品はほとんど見当たらなくなりました。その代わり、どうしても必要な人には、アダプターカードが供給されるようになりました。Thunderboltに対する熱気が冷めたような気がします。\nHackintoshの対応状況も改善されていません。hot plug問題も、そのまま引き継がれていますし、Windowsで一回動かさないとダメな状況も同じです。おそらく、USB 3.0がそうでしたが、インテルのチップセットにThunderbolt機能が組み込まれて、実際のMacがそれをサポートするまでは、完璧な互換性が得られないような気がします。\n最近のHackintosher.comにThunderbolt 3のまとめ記事が掲載されましたので紹介します。\nhackintosher.com\n以下はHackintosher.comの抄訳です 現行のASUS製品ではASUS Prime Z370-Aマザーボードと、ThunderboltEX 3 PCIeカードの組み合わせでThunderbolt 3を実現しています。このカードに対応するASUSのZ170とZ270マザーボードもあります。 Gigabyteは多数のThunderbolt対応マザーボードを揃えていますが、Hackintosher.comでの推奨はGigabyte Z370 AORUS Gaming 5です。これに対応するThunderboltカードは、Gigabyte GC-ALPINE RIDGE Thunderbolt 3 カードです。このほか、Z370 AORUS Gaming 7, Z370 AORUS Gaming 3, Z370XP SLI, Z370 AORUS Ultra Gaming, Z370 AORUS Gaming WIFIマザーボードなどがThunderbolt 3カードをサポートしてます。 ASROCKは、スリープ関係の問題が発生する可能性が報告されているので、ASUSかGigabyteがおすすめです。ASROCKの場合は、ASROCK Z370 Taichi, Z370 SLI/ac, Z370 K6, Z370 Extreme4, Z370 Pro4, Z370 Pro i7マザーボードと、ASROCK THUNDERBOLT 3 AICカードを組み合わせます。 Thunderboltカードを設定するには、\nWindowsを起動してThunderbolt 3カードをアップデートします。これで最新のマザーボードでカードを使えるようになります。ASUSの場合は「ThunderboltEX 3 firmware update tool」で、Gigabyteの場合は「Thunderbolt FW Update Tool」という名前です。 BIOSでthunderboltをenableにします。 また、Hackintoshでは、hot plugの問題があります。\n（ASUSのカードは、マーケットプレイスからの出品しかありませんでした。）\n","date":"2018-04-16T00:30:00+09:00","image":"/uploads/2018/04/20180413220600.png","permalink":"/posts/60/","title":"ThunderboltとHackintosh"},{"content":"Hackintoshを使っていて、Bluetoothキーボードからの入力が途切れたり、逆にキー入力が連打状態になって誤った入力がされたりする経験がありました。Bluetoothのマウスやトラックパッドの入力が不安定になって、ポインターが飛び飛びに移動することもありました。Hackintoshをしていると、どんな不具合でもHackintoshのせいだと思いがちですが、そうでは無いことも多いです。この不具合は以下のようにして解決しましたが、その経緯からしてBluetoothの電波状況が問題だったようです。\nBluetoothは、古い世代のWiFiと同じく2.4GHz帯の無線を使っています。2.4GHz帯は、色々な用途に使われているので影響も受けやすいです。特に問題なのが電子レンジです。加熱のために強力な2.4GHz帯電波を使用しますので、電子レンジが稼働すると、BluetoothやWiFiが不調になることが多いです。また、高速になったUSB 3.0が2.4GHz帯に近いノイズを発生することがあり、シールドが不十分なUSB機器やケーブルが原因で、Bluetooth/WiFiが不調になることがあります。最新のWiFi機器なら5GHz帯の電波を利用することで、これらの問題は回避できます。でも、2.4GHz帯だけを使用するBluetoothでは別の周波数に逃げることができません。WiFiとBluetoothでは電波強度も違います。WiFi電波は100mくらいの距離でも到達します。これに対して、もともと近距離の配線を無線化することが目的だったBluetoothは、到達距離が10m程度です。電波出力が弱い事もノイズにも弱い理由です。\nBluetooth接続が不安定なことには、Hackintoshならではの事情もあります。互換性の高いHackintoshを実現するために、Macで使われているのと同じ無線モジュールを使います。こちらで無線モジュールの選び方を解説してあります。\n/posts/138/\n自作PCでは、この無線モジュールを、下のようなPCIeアダプタに載せて、これをPCIeスロットに挿して使うことが一般的です。そうすると、筐体の後ろ側にアンテナを立てて使用することになります。\nこのような設定だと、机に載せたキーボードやトラックパッドから、筐体のアンテナまでの距離が長くなってしまったり、金属筐体で遮蔽されてしまったりして、電波状況が悪くなることが予想されます。一方で、実際の Mac、例えばiMacでは、画面の周囲にアンテナが配置されているので、机の上のBluetooth機器からの距離は近く、見通しも良いです。\nアンテナを机の上に持ってくる 解決方法の一つは、Bluetoothアンテナを机の上に持ってくることです。アンテナをキーボードやトラックパッドに近づければ、安定した無線通信を実現できます。そのために、下のような延長ケーブル付きアンテナ台を使うと良いです。台にはマグネットが入っているので、金属部分に固定することもできます。\nまずは、PCIeスロット背面やPCケースのアンテナから、Bluetoothアンテナを外します。例えばBCM94360CDには4本のアンテナがあり、J0, J1, J3, J2の順に印がついています。このうちの端から2番目のJ3（コネクタの切り欠きのある側から2番目に遠いアンテナ）がBluetoothのアンテナで、残りの3本はWiFiです。下の写真では上から2番目のアンテナ端子がBluetooth用です。\n他の無線モジュールにも、複数のアンテナ端子が付いていますが、そのうち1本がBluetoothです。どれがBluetoothなのかは、ネットで調べると書いてあることもあります。アンテナを外して感度が下がることで確認しても良いです。\n次に、外したコネクタ端子に、上記のアンテナ台の延長ケーブルを接続します。アンテナ台を机の上に置いて、外したアンテナをアンテナ台に接続すれば完了です。この結果、Bluetoothの電波状況が改善したのか、冒頭に書いたようなキーボード、トラックパッドの不具合が一切発生しなくなりました。\n上で、iMacは画面上部にBluetoothアンテナがあるから問題発生しにくいと書きましたが、ネット掲示板を見ていると、Bluetoothキーボードやトラックパッドの入力が不安定で困っている人が結構いるようです。特に、画面が大きいiMacではアンテナまでが遠いので、ノイズの多い環境では不安定になることもあるようです。アンテナを延長する方法ならば、キーボード・トラックパッドのすぐ脇にアンテナを置くこともできます。Bluetoothアンテナを延長することは実際のMacでは困難ですので、Hackintoshならではの柔軟性が発揮できる方法かと思います。\n","date":"2018-04-09T00:30:00+09:00","image":"/uploads/2018/04/20180329125845.png","permalink":"/posts/61/","title":"Bluetooth電波を改善する"},{"content":"10.13.4では、Radeon搭載のThunderbolt 3接続外部GPUボックスが正式サポートされました。これにより、AMDグラフィックスカードの互換性が向上して、今まで以上に簡単にHackintoshで使えるようになりました。\n10.13.3以前のmacOSでSAPPHIRE NITRO+ RADEON RX 580を使う方法を以下の記事で紹介しました。お勧めしませんが、どうしても10.13.3以前のmacOSを使いたい場合はこちらを参考にしてください。\n/posts/90/\n上記の記事では、kextを使用したり、config.plistに設定を書いたり、kextにパッチを当ててモデル名を書き換えたりしました。10.13.4では、これらの作業が全て不要になりました。結論として、SAPPHIRE NITRO+ RADEON RX 580は、箱から出してそのまま挿せば、なんの設定もしなくてもHackintoshで動作させることができます。\n以下は、上の古い記事を、10.13.4に合わせて書き直したものです。\nAMDから1枚を選ぶ Hackintoshのためのグラフィックスカード選び方に関してこの記事で紹介しました。\n/posts/139/\nまた、Appleが外付けGPUボックスでサポートするAMDのデスクトップ向けグラフィックスカードは、こちらで紹介しました。\nApple推奨グラフィックスカード\nこれによると、Polaris, Vega 56, Vega 64の3種類のアーキテクチャがサポートされているようです。具体的なチップは、以下です。\nAMD Radeon RX 570, 580, 470, 480, Radeon Pro WX 7100 AMD Radeon RX Vega 56 AMD Radeon RX Vega 64, Frontier Edition Air, Radeon Pro WX 9100 これらを使えば、macOS Sierra 10.12.6からHackintoshで実用的に使用できるようになり、さらに、macOS High Sierra 10.13.4以降では箱から出してそのまま動作します。\nSAPPHIREを選ぶ Appleのサポートページでは、RX 570/580 GPUを使った推奨グラフィックスカードとしてSAPPHIRE PULSEシリーズが紹介されています。SAPPHIREは、AMDのグラフィックスカードだけを長年手がけていて、供給も安定している印象があります。そういう実績を評価してか、Appleが販売しているVR開発者用キットであるExternal Graphics Development Kit では、 SAPPHIRE PULSE RADEON RX 580が搭載されています。PULSEを入手できれば、10.13.3以前のmacOSであっても互換性が高いです。ただ、このカードは、すでに販売中止になっていて、入手が困難です。\nPULSEの後継機種は、オーバークロックされたNITRO+です。これなら入手は容易です。また、10.13.4からは、NITRO+でもPULSE並みの互換性が確保されるようになりました。そこで今回は、SAPPHIRE NITRO+ RADEON RX 580 8Gを選びました。SAPPHIRE以外のブランドのカードでも、次に紹介するSONNETの資料によると、問題なく動くようです。ただ、Appleが採用・言及しているブランドですので、マザーボードブランドに合わせて見た目を揃えたいというように、特に選びたいブランドがなければ、HackintoshにはSAPPHIREを選んでおくのが無難かと思います。\nSAPPHIRE以外の選択 Sonnet社が、同社のThunderbolt 3接続外部GPUボックスで使う各社グラフィックスカードの互換性リストを公開しています。\nSonnetの互換GPUリスト (10.13.4以降)\nこれから推測すると、10.13.4ではSAPPHIRE以外のメーカのカードも問題なく使用できるようです。そして、互換性の有無は、搭載しているGPUチップで決まるようです。このリストの内容をまとめると、以下のようです。\nRX 470, RX 480, RX 570, RX 580はどのメーカ製品も互換性あり RX Vega 56/64はどのメーカ製品も互換性あり RX 460/550/560は互換性なし R9 NANO/FURY は互換性なし WX 5100は非互換で、WX 7100, WX 9100は互換性あり NVIDIA GeForce は互換性なし RX 460, 550, 560などは価格が安く入手しやすいですが、この資料では互換性が無いとされています。実際に、Hackintoshで使った場合に、スリープからの復帰などで問題が出ることが報告されています。RX 460, 550, 560は避けた方が良いようです。\nNVIDIAからの乗り換え方法 実はこれまでNvidia Geforceを使っていました。大昔はAMDを使っていましたが、macOSとの互換性が悪くなって、最近は、ずっとNvidiaでした。NVIDIAからAMDに移行するためには、NVIDIAのために入れていたWebドライバやkextやconfig.plistの設定を外します。\nまずは、/Library/Extensions/に導入されたWebドライバをアンインストールします。Webなんとかという名前のkextが複数ありますので、それを消せば良いです。また、iMacのretinaディスプレイの回路を回避してブラックスクリーン発生を防いでくれる機能があるNvidiaGraphicsFixup.kextを入れている人も多いと思いますが、これも外します。また、config.plistでNvidiaWebドライバを有効にしていた所もfalseにします。もしくは、この部分を全部削除してもかまいません。\n\u0026lt;key\u0026gt;SystemParameters\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;NvidiaWeb\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; RADEONを動かす ここでシステム終了して、NVIDIAを使っていた場合はそれを外し、Radeon RX 580に差し替えます。\n初期化の問題（10.13.3以前で発生） AppleのThunderbolt 3外付けGPUボックスでは、外部グラフィックスカードがプライマリディスプレイになることはありません。そのため、Hackintoshでグラフィックスカードをプライマリとして使用すると、初期化の問題が10.13.3以前では発生しました。この問題に対応しないと起動しても画面が表示されませんでした。しかし、10.13.4ではその問題がなくなり、差し替えて、電源を入れるだけで画面表示されます。\n10.13.3以前では、\nRadeonカードをセカンダリで起動する。例えばマルチスクリーン環境にして内蔵GPUをプライマリにする。 kextやDSDTにパッチを当てて初期化をさせないようにする。 これに相当する作業をWhateverGreen.kextとLilu.kextの組み合わせで実施する。 CloverのRadeonDeInit機能で初期化を阻止する のいずれかの手段で初期化問題を回避していました。しかし、これが必要なくなりました。むしろ副作用が出る可能性もあります（10.13.4でRadeonDeInitを使うとノイズが出ました）ので、元の状態に戻すのが良いです。\nモデル名の誤表示（10.13.3以前で発生） 10.13.3以前ではSAPPHIRE PULSEシリーズ以外のカードで、名前が正しく認識されない問題もありました。これは表面上のことで、性能や互換性には関係しないと言われています。見た目にこだわる場合は、対応するkextにパッチを当てることで表示名を変更できました。しかし10.13.4では、NITRO+カードも「システム情報」などで正しい名前が表示されます。\nOpenCLスコアの劣化（10.13.4でも発生） Geekbench 4でのOpenCL Scoreは145000前後です。他でも報告されている程度の妥当な成績なので、正しく設定できていると思います。しかし、しばらく使用していると性能が低下して、ベンチマークスコアが50000くらいになってしまうことがあります。色々試して見たところ、Intel CPU内蔵GPUをマザーボードの設定で無効にしていると性能低下が発生するようです。内蔵GPUはセカンダリーに設定して使用しない場合でも、有効にしておくのが良いようです。（この性能低下問題はMojaveでは発生しなくなりました。しかし内蔵グラフィックスを無効にするとJPEGファイルがクイックルックやプレビューで開けないようです。内蔵グラフィックスは有効にしておくのが良いようです。）\nSafari動画再生の停滞（10.13.4でも発生） Intel CPU内蔵GPUをマザーボードの設定で有効にすると、今度は別の問題が発生することがあります。NITRO+では、SafariでYoutubeなどの動画を再生すると、再生がカクカクして滞ったり、場合によってはハングすることが発生しました。Google Chromeでは問題が出ません。この不具合は、CPU内蔵GPUを無効にすれば解決しますが、上記で述べたような性能低下が発生します。\n以前、Intel HD Graphicsを使って同様な不具合が発生した経験があり、その時は、IntelGraphicsFixup.kextとLilu.kextの組み合わせで解消しました。今回も、これで改善しました。ただし、IntelGraphicsFixup.kextとLilu.kextは最新版を使うのが良いです。古いバージョンだと改善しません。\nということで、Radeon GPUを正しく動作させるために10.13.4であっても\nIntel CPU内蔵GPUは有効にしておく IntelGraphicsFixup.kextを使う のが良いようです。\n更新: RX 480/470がサポートされたことを追記しました。2018/4/16\n","date":"2018-04-03T15:18:16+09:00","image":"/uploads/2018/08/20171118234329.png","permalink":"/posts/62/","title":"SAPPHIRE NITRO+ RADEON RX 580を使う (10.13.4以降)"},{"content":" macOS 10.13.4のリリースに合わせて、Appleのサポートページに「Macで外付けグラフィックスプロセッサを使う」というページが公開されました。\nsupport.apple.com\nThunderbolt 3で接続する外部GPU拡張ボックス (eGPU) が2017のWWDCで開発者向けに発売されましたが、10.13.4になってそれがいよいよ一般アナウンスされたようです。\nこのページによると、10.13.4が搭載された以下のMacでeGPUはサポートされ、Metal, OpenGL, OpenCLを使うアプリケーションを高速化できるそうです。\n2016年以降のMacBook Pro (2016以降の13-inch MacBook Proでは左側のポートを使うとデータ転送が早い ) 2017年以降のiMac iMac Pro. AppleがサポートするGPU このサポートページでは、eGPUで使用する推奨グラフィックスカードも紹介されています。Thunderbolt 3はPCIe x4を一対の信号線で引き出す規格ですので、OSからはPCIeスロットと同じように見えます。なので、AppleがeGPU用に推奨するグラフィックスカードは、HackintoshのPCIeスロットに挿すだけでそのまま使える互換性の高いカードです。ここで推奨されているカードは、Hackintoshでも使えるカードです。\nAMD Radeon RX 570, 580, 470, 480, Radeon Pro WX 7100 これらはAMD Polarisアーキテクチャのグラフィックスカードです。Sapphire Pulseシリーズと、AMD WXシリーズが推奨カードです。\nAmazonで該当するカードを探してみましたが、高騰していますね。Pulseシリーズが販売終了になっているのも痛いです。以前ならSapphire Pulse Radeon RX 580が3.4万円くらいでしたのに。いまでは、Sapphire Pulse Radeon RX 570が、なんとかお手頃なカードかも。\nAMD Radeon RX Vega 56 これはAMD Vega 56アーキテクチャのグラフィックスカードです。Sapphire Vega 56とXFX Vega 56が推奨カードです。\nAMD Radeon RX Vega 64, Frontier Edition Air, Radeon Pro WX 9100 これはAMD Vega 64アーキテクチャのグラフィックスカードです。Sapphire Vega 64とXFX Vega 64, 空冷のAMD Frontier Edition、AMD Radeon Pro WX 9100が推奨カードです。\n補足：ついにtonymacx86でもAMDカードが推奨ハードウェアになりました。\nwww.tonymacx86.com\n更新: RX 480/470がサポートされたことを追記しました。2018/4/16\n","date":"2018-03-31T19:43:57+09:00","image":"/uploads/2018/03/20180331160650.png","permalink":"/posts/63/","title":"Apple推奨グラフィックスカード"},{"content":"\nmacOS Sierraから音声アシスタントのSiriが使えるようになっています。HackintoshでもSiriを使うことができます。ただ、一体型のMacにはSiriに適したマイクロフォンが内蔵されていますが、自作PCで作ったHackintoshでは別途用意する必要があります。\nマザーボード搭載のオーディオチップが使えるように設定してあれば、マザーボードのジャックにアナログマイクロフォンを接続すれば使えます。でも、Webカメラ内蔵のマイクロフォンを使うのが安価、高性能で簡単だと思います。Webカメラがあれば、FaceTimeやSkypeやそのほかのテレビ電話・会議システムで使えます。USB接続のWebカメラなら、Hackintoshでも特別なドライバのインストールなしで、画像入力・音声入力をそのまま使用することができます。Webカメラは多数販売されています。例えばLogicoolのC270は、HD 720pですがテレビ電話・会議に十分な画質で価格も安いです。マイクロフォンも優秀です。LogicoolのWebカメラを接続すると、内蔵マイクロフォンが、「システム環境設定」の「サウンド」「入力」にUnknown USB Audio Deviceとして表示されていますので、これを選択します。\niPhoneなどで使用するBluetoothイヤフォンの多くにも、通話のためのマイクロフォンが内蔵されています。これもHackintoshのSiriで使用することができます。Bluetooth接続すると、「システム環境設定」「サウンド」「入力」にBluetoothに分類される入力装置が現れるのでこれを選択します。\n入力装置の設定が終わったら、「コマンドキー」「スペースキー」の長押しで、Siriが応答します。色々試してみましょう。なお、macOS High Sierraからは、「システム環境設定」「アクセシビリティ」「Siri」から「”Siriにタイプ入力”を有効にする」項目が用意されていて、これをチェックすると音声だけでなくテキスト入力によりSiri利用が可能になります。\nAlexaも使ってみる AppleのスマートスピーカHomePodが米国などで発売されていますが、日本はまだです。Siriベースで、Macとの親和性の高いHomePodは楽しみです。一方、スマートスピーカとしては、GoogleのGoogle HomeとAmazonのAmazon Echoがすでに先行しています。\nAmazon Echoの音声アシスタントであるAlexaもmacOSで使うことができます。App Storeで配布されている以下のアプリケーションをインストールするだけで利用できます。Siriと同様に、HackintoshでもWebカメラやBluetoothイヤフォンのマイクを使ってアクセスできます。\nReverb for Amazon Alexa\nRain 仕事効率化 無料 アプリケーションが起動すると、EchoのLEDのようなリングが表示されて、これを長押ししている間、音声認識します。\nAmazon Echoを使えば、Amazonのサービスで使えるコンテンツにアクセスできるのですが、残念ながらこのプログラムは音楽再生に対応していません。でもニュースなどを再生してくれます。また、iCloudとも連携できるので、カレンダー.appで管理しているスケジュールも教えてくれます。Amazon Echoで制御できる照明器具やスイッチなどが販売されていますが、このアプリケーションを使うと、HackintoshからEcho対応照明をon/offすることもできました。\nOK Googleも使えるはず Google Homeの音声アシスタントもmacOSで使えるようです。以下の記事に詳しく書かれています（この関連記事でmacOS用Alexaのことも知りました）。\nnews.mynavi.jp\nただ、設定が大変な上に英語にしか対応していないようです。また、Googleのエコシステムを前提としているので、iCloudのカレンダーを利用することはできません。ということでこちらは試していません。macOSにはGoogle HomeよりもAmazon Echoの方が親和性が高いようです。\n","date":"2018-03-25T00:30:00+09:00","image":"/uploads/2018/03/20180320205536.png","permalink":"/posts/65/","title":"HackintoshでSiriを使う"},{"content":"\nHackintoshするならMacは買わなくて良いと思うかもしれません。でもMacは素晴らしいですので、ぜひ1台買っておきましょう。それ以外にも、Macを買っておくべき理由があります。\nmacOSを入手するにはMacが必要 初期のmacOSはDVDなどの光ディスクで販売されていましたが、Mac OS X Lionから以降は、App Storeでのみ販売（のちに無料配布）されています。現行のmacOS High SierraもApp Storeからダウンロードする以外に正規に入手する方法はありません。そのためには、macOSが動いているマシンが必要です。HackintoshからでもApp Storeに接続してダウンロードすることは可能ですが、これから1台目のHackintoshを作る場合には、macOS入手のためにMacが必要です。また、インストール用のUSBメモリをフォーマットするにも、これにmacOSインストールイメージをコピーするにも、macOSが必要です。\nネットで検索すると、Macを持たずにHackintoshを作る方法も紹介されています。Windows上にVMWareなどでバーチャルマシン(VM)環境を作って、そこにHackintoshを実装する方法です。ただ、その多くは、ネット上からVMのイメージをダウンロードするとか、ネット上からmacOSをダウンロードする方法です。これは無断で配布されているmacOSをダウンロードすることになり、Appleの著作権を侵害します。正しくHackintoshするには、正規に入手したmacOSを使いたいところです。\n実を言うと、今でもApp Storeに頼らずにmacOSを正規に入手する方法はあります。Mac OS X 10.6 Snow Leopardだけは、いまだにアップルストアでDVD版が販売されています。App Storeが使用可能になるのは10.6.6からなので、それより古いmacOSを使っているユーザはApp Storeが使える最新バージョンにアップグレードすることもできません。その救済のために、10.6がDVD版で販売されています。ただ、販売されている10.6はApp Storeに非対応なので、App Storeを使えるようにするには、ネット接続して10.6.6までアップデートする必要があります。\nなので、VMでHackintoshする場合も、最初に10.6 DVDを購入してVM上にHackintoshを構成し、これをオンラインアップデートし、その後でApp Storeから最新macOSをダウンロードすれば、macOSを正規に入手することが可能ではあります。ただ、古いバージョンに対応したインストールは困難かもしれません。\nwww.apple.com\n本物を知る 本物のMacにも色々な不具合が発生します。Hackintoshで不具合が発生すると、Hackintoshのせいかと思いがちですが、もともとのmacOSの問題である場合も多いです。Macが手元にあれば不具合の原因を知ることができます。そのほか、OS設定を比較して、Hackintoshを最適に設定することもできます。\niMessageやiCloudのサービスを使う場合でも、実機のMacがあると、アカウントの状況などがわかって安心です。\nモバイルはMac、デスクトップはHackintosh Hackintoshする最大の理由は、Appleが提供してくれないタイプのハードウェアを入手できることだと思います。多くのMacユーザは、Appleのディスプレイ分離型デスクトップマシンのラインナップが貧弱で、なかなかアップデートされないことに苛立っています。PCIeスロットでグラフィックスカードなどを自由に拡張できる旧型Mac Proは2012年モデルで終了してしまいました。後継の拡張性の低い円筒形Mac Proも一向に更新されていません。Mac miniも2014年モデルで止まっています。ProはXeonプロセッサを使い、miniはモバイル用CPUを使っています。コストパフォーマンスの高いメインストリームのデスクトップ向けCore iプロセッサを使ったモデルはiMacにしかありません。それも、グラフィックスチップはモバイル用です。なので、デスクトップ向けCPU/GPUを使った拡張性のあるデスクトップマシンは、Hackintoshでのみ実現可能です。\n一方で、ノートPCはHackintoshが難しいです。必要ならば互換性の低いパーツを交換できるデスクトップと違い、ノートPCでは交換が困難です。なので、無線が動かない、ディスプレイが遅い、音が出ないなどの問題を簡単には解決できない場合が多いです。また、現行macOSのユーザインタフェースは多彩なマルチタッチができるTrackPadデバイスに支えられていますが、ノートに搭載されたポインティングデバイスはMacと同じようには使えません。一方で、MacBookシリーズの品揃えは豊富で、アップデートも（デスクトップに比べたら）頻繁に行われています。価格も、同じハードウェア仕様のWindowsノートPCに比べて、格段に高いわけではありません。\nなので、モバイル用途には、非力だけど薄くて軽量な製品をMacBookシリーズから選び、デスクトップ用途には、大型重装備で高速なデスクトップHackintoshを使うのが、理想だと思います。\n","date":"2018-03-18T18:29:10+09:00","image":"/uploads/2018/03/20180318181631.png","permalink":"/posts/66/","title":"Macintoshを買おう"},{"content":"\nHackintoshでe-Tax（確定申告）してみました。ちゃんとできました。マイナンバーカードも読めて、手続き出来ました。普通のMacでもできることなので、当然と言えば当然です。\n整理が下手で控除書類が年末調整時に見つからなくて、確定申告をしています。例年は「確定申告書等作成コーナ」というページから書面提出をしていたのですが、今年は、マイナンバーカードを使用して、初めてe-Taxしてみました。今年からいくつかの提出書類が省略できるようになったこともあり、郵送する手間なく、オンラインで全て完了できました。\ne-Taxするには、住民基本台帳カードもしくはマイナンバーカードと、これを読み取るための「公的個人認証サービス対応ICカードリーダライタ」が必要です。今回は、SCR3310-NTTComというカードリーダを使いました。これはすでに販売終了になった古い製品です。だいぶ前に、秋葉原のジャンク屋さんに積み上げられていたのを、使う当てもなく買ったものです。これが発掘されたのも、今回e-Taxしてみようという動機の一つです。\n今は後継機種が販売されているようです。\nこれらのリーダはUSBで接続します。一般にUSB接続周辺機器は高度に標準化されているため、Hackintoshでも本物のMacでも同様に動く傾向があります。今回も動きました。なお、このリーダのためにドライバが配布されていますが、e-Taxを行う際にはドライバをインストールする必要はありません。むしろ、標準のドライバを消してしまう問題もあるそうで、インストールしてはいけないようです。\ne-Taxのサイトを見てすぐ気になったのがソフトウエア動作環境です。 国税庁で動作を確認した推奨環境は、macOS 10.12とSafari 10.1です。これに対して、手元のHackintoshは、いつも最新にしているのでmacOS 10.13.3とSafari 11.0.3です。でも、結論として、問題ありませんでした。国税庁にもぜひHigh Sierraを導入して動作確認してもらいたいところです。\n問題なく作業できたとはいえ、色々大変でした。Java Runtime Environmentをインストールする必要があります。また、SafariでJavaの動作を許可してあげる必要があります。e-TaxのサイトにはSafari環境設定での方法が書いてありますが、実際には違ってました。サイトには「セキュリティ」のアイコンから設定することになっていますが、Safari 11.0.3では「Webサイト」のアイコンから設定します。Safariのバージョンが変わって、設定場所が移動したようです。ここの設定では、オプション＋クリックで現れる隠しメニュー項目の「安全なモードで実行」するというチェックマークを解除します。この後、警告マークが出続けますので、かなり危ない設定なのだと思います。WebブラウザでのJava利用もあまり行われなくなっていますし、e-Taxの実行環境ももう少し現代風に更新してほしい気がしました。\nとは言え、なんとか終了しました。完了した後で、はてなのブログにe-Taxのやり方が書いてあるのを発見しました。後の祭りですが、だいたい問題なかったです。こちらのブログに書いてあることを全部実施する必要はありませんでした。e-Taxのヘルプページは良く書かれているので、エラーコードを頼りに見ていけば、必要な作業がわかりました。\nd.hatena.ne.jp\n","date":"2018-03-11T23:19:31+09:00","image":"/uploads/2018/03/20180311174120.gif","permalink":"/posts/68/","title":"Hackintoshで確定申告(e-Tax)"},{"content":"デスクトップマシンなのに、「システム環境設定…」「省エネルギー」の設定で、「電源アダプタ」と「バッテリー」の2つのタブが表示されることがあります。MacBook Airとして機種設定したNUCがそうでした。「電源アダプタ」タブがデフォルトで表示されるので、こちらで設定しておけば問題ありません。ちなみに、「バッテリー」の項目はどれを設定しても機能しません。\nバッテリー関連機能が応答しないのは、実際にバッテリーが搭載されていないので当然です。しかし、存在しないバッテリー管理チップにOSがアクセスしようとしているわけで、システムの安定性に影響を与える可能性もあります。とはいえMacBook Airの設定にしたのだから仕方ないと思い、放置してきました。\nところが最近のredditで、「Mac miniの設定でバッテリー表示が出るのでなんとかしたい」という相談が上がり、解決策がわかりました。簡単でした。\nwww.reddit.com\nconfig.plistのSMBIOSセクションに、Mobileという項目があります。これがtrueになっていると、バッテリ搭載機だと見なされるようです。\n\u0026lt;key\u0026gt;Mobile\u0026lt;/key\u0026gt; \u0026lt;ture/\u0026gt; これをfalseにしてみました。\n\u0026lt;key\u0026gt;Mobile\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; その結果、機種設定はMacBook Airのままですが、「省エネルギー設定」にバッテリーの設定が現れなくなりました。\n","date":"2018-02-24T12:54:47+09:00","image":"/uploads/2018/02/20180224115241.png","permalink":"/posts/69/","title":"電池を搭載してないことをOSに知らせる"},{"content":"\n今までCloverのインストーラとは別に、MultiBeastというインストールツールを提供して来たtonymacx86のサイトで、新たにCloverインストーラを提供するようになったようです。\nwww.tonymacx86.com\nCloverのインストーラとMultiBeastの違いを簡単にまとめておきます：\nCloverというのはブートローダで、Clover本体のブートローダプログラムファイルと、機能を分担したドライバーのファイルと、設定ファイルconfig.plist、ブート画面のデザインthemeなどのファイルから構成されています。これらを然るべき場所にインストールしてくれるのがおなじみのCloverインストーラです。 MultiBeastというのは、オリジナルのCloverインストーラがやる作業に加えて、主にtonymacx86での推奨PC構成を動かすためのkextの追加、kextへのパッチ当て、config.plistの設定をやってくれます。 tonymacx86の上記のアナウンスによると、tonymacx86では、MultiBeastとは別に、もう一つのCloverインストーラを配布することにしたようです。Cloverのバージョンアップに素早く追随するのが目的とのことです。ダウンロード先は、以下です。MultiBeast, UniBeastなどと同じく、ユーザ登録してログインしないとダウンロードできません。\nwww.tonymacx86.com\n何をやってくれるのか調べるために、このページのClover UEFI Boot Mode v2.4k r4411を実際にダウンロードして、空いているUSBメモリにインストールしてみました。このページの説明と、実際にインストールされた内容をみるに、以下のことをやってくれるようです。\nCloverの標準インストーラがやってくれる作業をする。 OsxAptioFix3Drv-64.efiをインストールする。ただしこれは、Cloverの標準インストーラでも可能です。 apfs.efiをインストールしてくれる。本体が10.13の場合に本体からコピーするようです。 tonymacx86推奨PC構成用のconfig.plistをインストールする。とはいえ、SMBIOSの設定はほとんど空白です。ちなみにMultiBeastだと指定したMac機種名に合わせてSMBIOSを作成してくれます。 kextのインストールはしない。Cloverの標準インストーラと同じです。 themeにtonymacx86のテーマを入れてくれます。 MultiBeastと違ってkextを入れてくれないので、Cloverの標準インストーラと同じく、これだけで起動するドライブを作ることはできないようです。config.plistがシンプルでメンテナンスしやすい内容になってくれるのはありがたいかもです。apfs.efiを入れてくれるのも面倒が少ないかも。しかし、Cloverの標準インストーラにあるカスタマイズ機能はありません。\nMultiBeastでインストールした人が、Cloverを最新版にアップデートするために使うツールなのかもしれません。でも、それならCloverの標準インストーラで十分ではと思いました。\n","date":"2018-02-17T00:06:14+09:00","image":"/uploads/2018/02/20180216232911.png","permalink":"/posts/70/","title":"tonymacx86版のCloverインストーラ"},{"content":"hackintosher.com\nKabylake（200シリーズチップセット）でHackintoshするなら、どのメーカのマザーボードが良いのかについて、Hackintosher.comに記事があります。4大メーカーを使ってみての感想とのことで、参考になるかと思います。結論は、\nASRock ASUS Gigabyte MSI の順番だそうです。\n世の中一般のイメージでは、ASUSはシェアが高くて安心だけど作りの割には値段が高い、Gigabyteは堅牢、ASRockは変わった（変態な）製品を作っていたけど最近は安くて品質が良い、というようなイメージかなと思います。一方で、Hackintoshに限ると、Gigabyteが古くから互換性が高いと言われていました。ただ、UEFIになってからは、あまり違いはないようです。\n一方でHackintosher.comでは、上記のようなランキングがされました。気になったので読んでみました。オリジナルのページには、それぞれのマザーボードで自作した記事へのリンクもありますので、参考にしてください。\n————以下Hackintosher.comの抄訳です———-\nハイエンドなマザーボードでは、オーディオやLANのチップセットに標準ではない高価なチップを使うこともあります。その場合は、Hackintoshが難しくなることもあります。逆に、ローエンドなマザーボードでは、Hackintoshの問題は発生しないです。\n例えば、MSIのB250はHackintoshが全く問題なく動きますが、CarbonシリーズではUSBの問題が発生します。 ASRockでは、Fatal1tyシリーズではランダムにリセットする問題が発生しましたが、安価なモデルでは発生しませんでした。 GigabyteではゲーミングシリーズでCPU周りの部品が鳴く問題がありましたが、Ultra Durableシリーズでは問題ありませんでした。 ASUSは例外で、ROG Strixシリーズでも問題ありませんでした。ただ、もっと高価なROG HEROボードではオーディオの問題を解決できませんでした。 なので、$200を超えるようなハイエンドなマザーボードは避けて、$200以下の中堅または廉価版マザーボードにこだわるのが良いです。\nまたマザーボードメーカによって、それぞれ強みや問題があることに気づきました。以下でそれをまとめてみます。\n第1位はASRock ASRockのマザーボードは、Hackintoshを作る際の互換性問題を解決する手間が一番少ないです。しかもASUSよりコスパが良いです。\nある時Z270 Fatal1tyのHackintoshが見ていない間に再起動する問題に遭遇しました。原因は不明ですがそれ以降発生していません。ASRock H270-ITX/AC + Intel Pentium G4560で作ったHackintoshでは何の問題も発生していません。\n利点 200シリーズマザーボードはGigabyteと同様に簡単だけど、Gigabyteで経験するような品質の問題は無いです。 200シリーズASRockマザーボードでスリープの問題は無いです。 USBポートの問題が無いです。 欠点 特定のBIOSバージョン（例えばP2.10) でスリープ後のUSB認識問題が発生しますが、それ以外のバージョンでは問題無いです。 使用上の注意 BIOS version P2.10を避けてP1.20またはP2.20以降を使うと良いです。 RAMを一本だけ使うなら、内側のスロットを使うとKPを避けられます。 第2位はASUS 私の経験では、ASUSのZ270は、Z170 ATX Proより良いです。ASUS ROG Strix Z270I ITXで自作した記事を書いています。200シリーズASUSの唯一の問題は、スリープ後にオーディオが途切れることです。これはいつでも起こることではなくて、30回に一回程度です。これの解決方法についてはHackintosher.comの記事をみてください。\n利点 自動スリープはとてもよく機能します。 オーディオ問題を解決すれば問題なく安定します。 darkwake設定はデフォルトのままで良いです。 HWMonitorでCPUコアの電圧が見られます 内蔵GPUも外部GPUも同じconfig.plistとBIOS設定で使えます。 USBポートも問題ありません。 欠点 強制的に再起動したり電源を切ると次の起動でBIOS画面になります。これがちょっと面倒です。 私のところだけだと思いますが部品鳴きがします。 使用上の注意 スリープ後のオーディオの問題は本ブログのガイドを見てください。 オーディオを動かすためにはlayout id 7にします。 終了したいのに再起動してしまうときには、FixShutdown_0004をtrueに設定します。 第3位はGigabyte Gigabyteは長らくHackintoshでオススメのブランドでした。LGA 1511チップセット以来、すべてのブランドが簡単になりました。でも、私の経験では、config.plistの一つのフラグをセットしないとスリープの後に再起動してしまいます。\n私の経験では、複数のGigabyteマザーボードに大きな問題がありました。それはkernel_taskです。アクティビティモニターを起動して、Diskタブを選ぶと、その中にkernel_taskがあります。通常は、今ASUSで試したところ、1GB程度の書き込みバイト数です。しかしZ270 Gigabyte Gamingマザーボードでは70, 100, さらには200GBにもなることがあります。主にSierraの10.12.4でこの問題を経験して、それでGigabyteを止めてしまいました。もしかしたら新しいmacOSバージョンでは治っているのかもしれません。\nもう一つの、でもこちらは対応可能なトラブルは、Gigabyte Hackintoshがスリープの時に再起動してしまう問題です。EFIのAPPLEフォルダを消すと、治りました。\nこれ以外に、Hackintoshとは関係ないけど、品質の問題もありました。部品鳴き、Ethernetの不調、グラフィックスの問題、CMOSクリアしないといけない状況になってしまった問題などです。\n利点 一旦動けば信頼できるブランドです。 HWMonitorでCPUコア電圧が見られます。 安価なマザーボードが用意されています。 darkwake設定はデフォルトのままで良いです。 欠点 kernel_taskの書き込みバイト数が大きくなり、遅延が発生します。再起動をしないと治せません。 自動スリープは、時々動きません。なのでマニュアルでスリープしないといけないです。 特定のBIOSバージョンではmacOSインストールが困難です。(例えばVersion F2) スリープ中にUSBデバイスを抜くとブラックスクリーンの状態で起動し、しばらくすると再起動してしまいます。 USB3.1 Gen2にデバイスを刺すと無線デバイスに干渉します。 なんどもCMOSリセットする必要があるかもしれません。 私の経験ではGigabyte’s Z270 Gaming マザーボードで部品鳴きしました。 特定のバージョンのLilu.kext と AppleALC.kext でオーディオが出なかったりブラックスクリーンになります。 使用上の注意 シャットダウンしたのに再起動してしまうときはconfig.plistのFixShutdownで直します。 ゲーミングシリーズマザーボードでは、EFI検出問題を解決するためにK4もしくはそれ以降のBIOSを使います。 スリープ後で再起動してしまう場合には、EFIのAPPLEフォルダを消します。 NVIDIAのグラフィックスカードを使う時にはEmuUEFIVariable.efiを使います。 第4位はMSI MSIマザーボードは、Hackintoshするのに割とよくて、Gigabyteで経験したような問題もありませんでした。でもKernel_task問題はCarbonシリーズで1回以上ありました。が、それより安いBazookaシリーズでは発生していません。\nMSIマザーボードの問題は、USBです。USB-Cや3.1ポートにUSBメモリを挿した状態で、スリープさせて回復させると、USBメモリがイジェクトされます。またこれらが挿入されると、無線に干渉して、M705無線マウスが遅延します。\n起動時やスリープ回復時に、Cooler Master Mechanical KeyboardやSandisk Cruserフラッシュドライブが認識されません。認識させるためには挿し直す必要があります。これ以外のキーボードやフラッシュドライブではこの不具合を経験していません。USB検出の問題は、macOSの互換性とは関係ないと思われます。\nChromeのタブをたくさん開いていると、スリープの邪魔をすることがあります。\n中級もしくはハイエンドのMSI Z270マザーボードはOsxAptioFix2Drv-free2000.efiが必要です。\n**訳注：**ASUSやMSIのマザーボードでOsxAptioFix2Drv-free2000.efiが必要だった時期がありましたが、いまは、AptioMemoryFix.efiやOsxAptioFix3Drv-64.efiで安定に動いています。\n私の経験では、安いB250mマザーボードは、高価なCarbonシリーズに比べて、より問題なく動きました。\n利点 内蔵、外付けの両方のグラフィックスに同じconfig.plistを使える 安いMSIマザボはスムーズにHackintoshできる。 欠点 Gigabyteと比べたらずっと少ないけど、kernel_task問題が発生します。 スリープさせようとするとChromeで保存ダイアログが出ます。 USB3.1 Gen2 Type A/Type CにUSBメモリを挿しておくと、スリープ回復時にイジェクトされます。 USB3.1 Gen2ポートは無線に干渉します。 特定のUSBデバイスは起動やスリープ回復時に認識されません。 使用上の注意 最新のBIOSにアップデートしましょう。 特定のマザボにはOsxAptioFix2Drv-free2000.efiを使いましょう。\n**訳注：**多分AptioMemoryFix.efiやOsxAptioFix3Drv-64.efiで良いはずです。 RAMを1本だけ使うなら、KPを避けるために一番内側のスロットを使いましょう。 USB/Keyboard/Mouseでスリープ回復させるならBIOSでwakeさせるよう設定しましょう。 config.plistのBootでdarkwake = 8と設定しましょう。 スリープ回復や起動で音が出ない、もしくは音量が低いなら、CodecCommander.kextを追加しましょう。B250マザーボードでは、起動・スリープ回復時にALC887オーディオで音が出ない、もしくは音量が低い問題を解決するために、CodecCommander.kextの使用とdarkwake = 8の設定が必要です。 ————Hackintosher.comの抄訳は以上です———-\n感想文 紹介されたトラブルは、Hackintoshの問題というよりも、一般的な問題が多いような気がしました。製品の当たり外れや部品の相性もありそうです。でも、たくさんのマザーボードを試した結果で、ASRockがおすすめとのことなので、品質が良いと言えるのかもしれません。\n以前の記事でも紹介しましたが最近は、MSIが色々気に入って使っています。\n/posts/97/\n80シリーズチップセット以前はHackintoshに最適と言われていたGigabyteをずっと使ってきました。90シリーズでMSIを使ってみたら、問題なく稼働しただけでなく、ファンコントロールやGO2BIOS機能が便利で、BIOS設定メニューもわかりやすかったです。UEFIマザーボードでは、Gigabyteにこだわらなくても良いことを実感しました。その後、100シリーズでASUSを使ってみたら、これも問題なく使えたのですが、基板が紙のように薄くてバックパネル近辺が曲がっていました。そこそこの価格帯の製品だったのですが、ASUSは全体に価格が高いので、ケチってはいけないようです。BIOSメニューがわかりにくかったこともあり、200シリーズではMSIに戻りました。\n100のASUSと200のMSIでは、OsxAptioFix2Drv-64.efiが動かず、OsxAptioFix2Drv-free2000.efiが必要でした。OsxAptioFix3Drv-64.efiが出たところで試したら、これが動きました。また、もっとバニラなAptioMemoryFix.efiも動きましたので、最初からこれを試すべきだったかもしれません。なので、OsxAptioFix2Drv-free2000.efiの件は、今は気にする必要はないです。\nとはいえ次回、Cannonlakeで自作するときは、ASRockも試してみようという気になりました。\n","date":"2018-02-14T22:07:56+09:00","image":"/uploads/2018/02/H270M-ITXac.png","permalink":"/posts/71/","title":"お薦めマザボメーカ by Hackintosher.com"},{"content":"前回は、寒いから暖を取ろうといういい加減な動機で仮想通貨のマイニングに手を出してみました。 でも性能はイマイチでした。マイナーの数が圧倒的に多くてサポートの手厚いWindowsに性能で負ける結果も仕方ないと思いましたが、残念でした。\n/posts/85/\nそこで今回は本気を出して、性能アップを目指します。\n前回のあらすじ macOS (Darwin) をサポートしてくれているGPU採掘ソフトウェアは、どうやらethminerしかないようです。そこで、このサイト\nReleases · ethereum-mining/ethminer\nからDarwin用にコンパイルされたethminerをダウンロードして、Ethereumを採掘してみました。その結果、RX 580を使った場合、macOSで4.3MH/s (メガハッシュ毎秒) でした。その後、同じハードウェアでWindowsを起動し、ethminerを使ってみたところ16MH/sでした。\nNVIDIAでも試してみた NVIDIAのGeForce GTX 1080Tiでethminerを試す機会がありました。思いのほか性能が出なくて、Ethereumの採掘がmacOSでもWindowsでもどちらも1.5MH/sくらいでした。検索してみると、本当は32MH/sくらいは出るものらしいです。\nベンチマークで分かる、イーサリアムのマイニングに最適なGPUまとめ | ちもろぐ\nWindowsの世界には、もっと色々なツールがあるようなので、そういうのを使わないと性能が上がらないのかと思い、しばらくは放置していました。\n少し気になっていたのは、ethminerでOpenCLモードを使っていたことです。OpenCLはアップル社が提唱した並列コンピューティングのためのフレームワークで、AMDとNVIDIAの両方のグラフィックスカードでサポートされています。一方で、CUDAはNVIDIAが提唱する並列コンピューティング機能です。なので、NVIDIAをCUDAで使えばもっと性能が上がる可能性があります。NVIDIAでCUDAを使用するには、NVIDIAのWeb driverとは別に、CUDAのドライバもインストールする必要があります。CUDAドライバは以下から入手できます。\nMAC アーカイブ用CUDA ドライバ|NVIDIA\netherminerではコマンドオプション (-Gもしくは-U) の指定で、OpenCLとCUDAを切り替えて利用できることになっています。例えば、\n./ethminer -G -S eth.pool.minergate.com:xxxxx -O xxxx@xxxx.com のように-GオプションでOpenCLを使います。ここを-UにするとCUDAを使うことになっています。しかし、上記のサイトで配布されているコンパイル済みバイナリーで-Uオプションを使うと、\n./ethminer -U -S eth.pool.minergate.com:xxxxx -O xxxx@xxxx.com CUDA support disabled. Configure project build with -DETHASHCUDA=ON というメッセージが出て動作しません。どうやら、配布されているバイナリーは、CUDAサポートをOFFにしてコンパイルされているようです。ソースを入手してコンパイルし直す必要があります。\nethminerをコンパイルする そこで、ethminerのソースからコンパイルしてみました。コンパイルするときにCUDAサポートをONにすれば良いのです。上記のサイトからソースコード一式をダウンロードすることができます。実はOpenCLだけをサポートするコンパイルは割と簡単です。OpenCLは、多分Appleが標準でサポートしているためだと思います。でもCUDAは、NVIDIAから開発キットをダウンロードする必要がありました。やった手順を以下に書いていきます。\nXcode.appをインストールする macOSでコンパイルするならXcode.appは必須です。App Storeから無料で購入してインストールします。\nXcode Command Line Toolsをインストールする ターミナルからの操作でXcodeの開発ツールを利用するためのツールを入手します。この手順は、Xcodeのバージョンごとに変わっているようで、ネット上の情報も混乱しています。昔は手作業でインストールしていたのですが、こちらに書いてあるように、今は最初から入っているようです。この手順で確認してください。\nMac での Xcode コマンド ライン ツールのインストール – RAD Studio\nでも、なんかそれだけではダメだったようです。色々やっているうちに、App StoreからCommand Line Toolsの最新版を取り寄せることになりました。\nまた、ターミナルから、\nxcode-select --install をタイプして、Command line developer toolsというもののインストールダイアログを表示させて、インストールする必要がありました。これをやらないと、コンパイル中に、string.hファイルが見つからないと言われました。\nCUDA Toolkitをインストールする このページからCUDA Toolkitをダウンロードします。サイズは1.5GBくらいあります。\nCUDA Toolkit 9.1 Download | NVIDIA Developer\nダウンロードしたイメージの中にあるインストーラを起動します。\nインストールするパッケージを選びます。NVIDIAの通常のドライバ配布サイトでは、おそらくこの1番目のCUDA Driverが配布されているだけだと思います。今回は、2番目のToolkitが必要になります。3番目のSamplesは不要ですが、サイズも小さいので、全部入れてみました。\nこの作業でインストールされるライブラリ、ヘッダファイル、サンプルなどは、\n/Developer/NVIDIA/CUDA-9.1 の場所に保存されるようです。コンパイルなどで必要と思われるパスは自動的に張ってくれているようで、特に設定する必要はなかったです。\nHomebrewをインストールする HomebrewはmacOS用のパッケージマネージャの一つです。UNIX系の色々なコマンド、ツール、アプリケーションをインストールしてくれる便利なツールです。下のページに書いてある一行をターミナルにコピペして実行するとインストールできます。\nmacOSのパッケージマネージャとしては、他にmacportsが有名ですが、Homebrewの方がシンプルで高速で便利だと思います。\nhomebrewとは何者か。仕組みについて調べてみた - Qiita\nなぜHomebrewが必要かというと、この後で使用するcmakeというコマンドを使えるようにするためです。今回はそれだけのためにHomebrewをインストールするのですが、将来も使うと思いますので、入れておいて損はないです。\ncmakeをインストールする Homebrewがインストールできたら、ターミナルから、\nbrew install cmake とタイプします。これでcmakeコマンドが使用できるようになります。\nethminerのソースを入手する すでに紹介したサイトですが、随分と上の方に行ってしまったので、再掲します。このサイトからソースコード一式をダウンロードします。\nReleases · ethereum-mining/ethminer\nこれでダウンロードしたethminer-0.13.0というような名前のフォルダに、必要なファイル一式が入っています。\ncmakeする ターミナルからcdコマンドで、ダウンロードしたソースコードフォルダに移動します。そのフォルダには、CMakeList.txtという設定ファイルがあるはずです。このファイルにコンパイルやリンクの設定やオプションが書かれています。\nCMakeList.txtをテキストエディタで開くと、\noption(ETHASHCL \u0026#34;Build with OpenCL mining\u0026#34; ON) option(ETHASHCUDA \u0026#34;Build with CUDA mining\u0026#34; OFF) という記述があります。これでOpenCLとCUDAのサポートを指定しています。ここでわかるように、配布されている状態ではCUDAがOFFになっています。そこで、\noption(ETHASHCL \u0026#34;Build with OpenCL mining\u0026#34; ON) option(ETHASHCUDA \u0026#34;Build with CUDA mining\u0026#34; ON) このように、OpenCLもCUDAも両方ともONになるように書き換えます。（CUDAだけをONにして、OpenCLをOFFにしてももちろん良いと思います。）次に、以下のコマンドでcmakeします。\ncmake . cmakeのあとは、空白＋ピリオドです。これでcmakeが、カレントディレクトリの設定を使って、Makefileを作ってくれます。\nmakeする cmakeはmakeという名前がついていますがMakefileを作ってくれるだけでコンパイルやリンクはしません。そこで\nmake とタイプして、makeします。エラーが出ずに、コンパイル、リンクが進めば、ethminerというフォルダの中に、ethminerというファイルができています。これが完成したアプリケーションです。\nCUDAの結果は？ こうして作成したethminerで使用可能になった-Uオプションを使って、まずはグラフィックスカードの状況を確認してみます。\n./ethminer -U --list-devices Listing CUDA devices. FORMAT: [deviceID] deviceName [0] GeForce GTX 1080 Ti Compute version: 6.1 cudaDeviceProp::totalGlobalMem: 11810832384 Pci: 0000:01:00 グラフィックスカードがCUDAデバイスとして認識されているようです。そこでいよいよ、以下のようにCUDAを指定してEthereumを採掘してみました。\n./ethminer -U -S eth.pool.minergate.com:xxxxx -O xxxx@xxxx.com 今回は、エラーを出さずに、採掘を開始してくれました。そして、なんと32MH/sのハッシュレートを達成しました！ということでめでたくWindows並みの性能が得られるようになりました。\n以上、HackintoshでEthereumを採掘する場合、\nNVIDIAをCUDAで使えばOpenCLの20倍の採掘性能が得られる その結果macOSでもWindows並みの採掘性能が得られる macOSで採掘するならAMDよりNVIDIAの方が良い という結論でした。\n","date":"2018-02-08T00:30:00+09:00","image":"/uploads/2018/02/20180203222848.png","permalink":"/posts/72/","title":"Hackintoshでマイニング（本気編）"},{"content":"\nHDD/SSDの読み書き HDDやSSDは、大容量のデータを低価格で管理するために、一定のかたまり単位でデータの読み書きを提供しています。このかたまりは、HDDではセクターと呼ばれ、SSDではページと呼んでいます。HDDにはセクターサイズが512バイトと4kBのものがあり、SSDのページは一般的には2kBです。これを、以下ではページと統一して呼ぶことにします。\n新しいファイルは、新しいページから書き始めます。ページを使い切らなくても、そのページは全部そのファイルのものです。例えば以下のようにすると、Aという文字が書かれたファイルができます。ダンプしてみると文字と改行コードの2バイトの大きさのファイルだということがわかります。\necho A \u0026gt; tako hexdump tako このように小さなファイルでも、HDD/SSD上では1ページを使用します。（実際のHFS+では複数ページをまとめた4kBのサイズが最小単位です）\n1ページに収まらないファイルは、複数ページに書き込まれます。どのファイルがどのページに書かれて、続きはどのページなのかを管理するのがファイルシステムです。その情報(目次に相当する情報)は特別なページに書いて管理しています。ページの情報が不要になっても、ページの内容をわざわざ消すことはしません。不要になったページ番号を、目次から削除するだけです。\nSSDのデータ書込手順 HDDは、円板に塗布した磁性体に微小な磁石を多数作成して、これの磁極を変更してビットを記録します。磁極は磁場を加えると反転するので、上書きが容易です。例えば、ページにAという情報を書き込んだ後からBを書くと、それだけでAがBに書き変わってくれます。\n一方SSDは、絶縁された微小な領域に電子を閉じ込める事でビットを記録します。電子を加えるのは比較的に簡単なのですが、取り除くのは手間がかかります。例えると、紙にインクで文字を書くようなものです。とあるページにインクで書かれているAの代わりに、新たにBを書くためには、手間をかけてAの文字を消さないといけません。漂白剤でまっさらな紙に戻してから書き込む必要があります。その上、SSDではページ単位での消去はできません。標準的なSSDでは64ページをまとめてブロックと呼んでいて、消去できるのはこのブロック単位です。いわば、64ページのノートブックになっていて、冊子ごと漂白剤に突っ込んでインクを消さないといけない状況です。\nなのでOSから、例えばとある冊子(ブロック)の10ページ目に新たな情報を書き込んでくれと依頼されたSSDコントローラは、次のような作業をします。10ページ目以外の他のページに情報が書かれていたら、その内容を作業用メモリにバックアップします。次に、この冊子全体を漂白します。最後に、バックアップした情報を書き戻し、10ページ目に依頼された情報を書き込みます。かなり面倒な処理です。一方で、これが初めて使う冊子なら、バックアップは不要です。ですからSSDの書き込み速度は色々な要素で変動しますし、一般的にはSSDを使い込んでいくと書き込み速度が低下していきます。\nTRIMの役割 SSDの書き込み速度を低下させる原因の一つが、HDDのことしか考えないで設計されたOSです。先に述べたように、OSは不要になったページをいちいち消去することはせず、目次から削除するだけです。ですが、目次がどのページに書かれているかとか、目次のデータ構造がどう決められているかは、HDD/SSDのコントローラにはわかりません。もしOSが、不要になったページ番号だけでもSSDコントローラに教えてくれれば、そのページを無駄にバックアップしたり、書き戻さないですむでしょう。SSDのメモリー素子は書き込むごとに疲弊して、故障の原因になると言われています。なので、不要な書き戻しは避けたいところです。また、一回のブロック消去で真っさらなページを多く用意できれば、次回の書き込みが高速になると期待できます。\nこのように、使用しなくなったページをSSDコントローラに知らせる機能がTRIMです。TRIMはSSDのために追加された拡張機能です。不要になった葉っぱ（ページ）を刈り取る (trimする) という意味から名付けられたのだと思います。\nmacOSのTRIM機能 SSDには是非とも欲しいTRIM機能ですが、macOSでは、Macに最初から搭載されているSSDにだけ機能します。なので、本物のMacであっても、ユーザが蓋を開けて交換した市販のSSDでは、TRIM機能が効きません。残念な状況ですが、あらゆるSSDでの動作を保証できないと考えて、そうしているのかと思われます。\nApple非純正のSSDに交換した場合は、macOSに標準で搭載されているtrimforceコマンドを使うと良いです。ターミナルから、\nsudo trimforce enable と打ち込んで、パスワードなどを入力すると、しばらく処理が行われた後、自動的に再起動して、搭載された全てのSSDでTRIMが機能するようになります。\n実際はちょっと違います というような説明がネット上にはあります。が、実際にはそんなに単純ではないです。実際には、\nApple非純正のSSDでも何もせずにTRIMが機能することがあります。 一方でtrimforceコマンドでTRIMが有効にならないSSDもあります。 そんな場合はIOAHCIBlockStorage.kextにパッチを当てれば良いです。 という状況です。\nHackintoshでTRIMを有効化 HackintoshではApple純正SSDなどはまず使いませんので、そのままではTRIMが機能しない可能性が高いです。でも、非純正SSDでもTRIMが機能することもあります。ということでまずは状況を確認しましょう。それで機能していなければ対策をしましょう。\nStep 1. TRIMが有効になっているかどうか確認する リンゴマーク–\u0026gt;このMacについて–\u0026gt;システムレポート…–\u0026gt;ハードウェアから、SATA/SATA ExpressやNVMExpressの項目を見て、接続されているSSDを選択します。この中に、TRIMサポート：という項目があります。これが「はい」ならTRIMが機能しています。手元のマシンでは、M.2ソケット接続のSamsungのNVMe SSDは、バニラなmacOSでTRIMサポートされていました。TRIMサポートが「いいえ」なら次のステップに進みます。\nStep 2. trimforceコマンドを試す 以前のmacOSではtrimforceがよく機能したものの、最近のmacOSではあまり当てにならない気がしています。でも機能することもあります。OS標準機能なので、一度は試しておきましょう。保証はしないよという警告が出ますが、実行してしまいます。再起動した後で、また「システム情報」でTRIMサポートを確認します。手元のSATA接続SanDiskの2.5インチSSDは、trimforceコマンドでもTRIM有効化できませんでした。\nでも、AliExpressで買ったmSATA接続SSDはTRIM有効化できました。\nStep 3. IOAHCIBlockStorage.kextにパッチを当てる これは確実です。本物のMacを対象としたネット上の情報でも、パッチを当てる方法が紹介されています。でも、結構面倒ですし、SIPを無効にする必要がありますし、OSがバニラな状態ではなくなってしまいます。OSのアップデートごとに、同じパッチ当てをする必要があるでしょう。でもCloverを使ったHackintoshなら、config.plistで設定するだけで、起動時に動的にパッチを当てます。OS本体は手つかずのままパッチを当ててくれます。素晴らしいです。config.plistのKextsToPatchにセクションに以下のように書き込みます。\n\u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;IOAHCIBlockStorage\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AEFQUExFIFNTRAA= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt; AAAAAAAAAAAAAAA= \u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;TRIM Enabler\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; このパッチでは、Base64表記でAEFQUExFIFNTRAA=というデータを、AAAAというAの羅列データに置き換えています。16進数で表すと\n004150504c452053534400 というデータを\n0000000000000000000000 で置き換えていることになります（Base64ではAが数値の0です）。元のデータは、最初と最後の0x00を除くと、真ん中はASCIIコードになっていて、APPLE SSDという文字列です。\n004150504c452053534400 A P P L E S S D おそらくApple社のSSDに限定している場所を、0で消しているようです。この結果、手元のSanDisk 2.5インチSSDでもTRIMが有効になりました。\n","date":"2018-02-01T23:39:45+09:00","image":"/uploads/2018/02/20180821123202.png","permalink":"/posts/74/","title":"SSDのTRIMを有効にする"},{"content":"\nHackintoshを作る際に、macOSをバニラな状態でインストールすれば、Hackintoshで加える変更は全てESP (EFI System Partition)の中だけです。\n/posts/131/\nなので、Hackintoshの設定を変えたことが原因で起動しなくなっても、正しく動いているESPさえバックアップされていれば、それを使って起動することができます。ということを以下に書きました。\n起動失敗に備えてバックアップ\n今回は、そのESPをどこに、どうやってバックアップしたら良いかについて考えてみました。\nESPをTime Machineにバックアップする macOSを使うならTime Machineを使わない手はないです。\nTime Machineは良いです\nTime MachineでESPをバックアップしておけば、差分バックアップ機能により、過去の設定に戻すこともできます。ESPの設定を変えて、一見正しく動いているように見えたけど、しばらくしたら不具合に気づいたという場合がたまにあります。そんな時も、変更前の過去の設定に簡単に戻せるので便利です。やり方は、ESPの内容を、書類フォルダや、そのほかの、Time Machineの対象にしているフォルダにコピーしておくだけです。あとはTime Machineが個々のファイルの更新状態を確認して、自動的にバックアップしてくれます。\nESPをクラウドファイルサーバにバックアップする クラウドファイルサーバと同期しているフォルダにESPをバックアップしておけば、他のマシンやWebから参照できます。Hackintoshが起動しなくなっても、他のマシンでESPを使って起動USBメモリを作り、救済することができます。\niCloud Driveを使っていれば書類フォルダをクラウドにバックアップできます。無料アカウントだと容量が少なく書類フォルダをiCloud Driveに置けないかもしれません。その場合は、iCloud Driveの同期対象フォルダの中に専用のフォルダを作っても良いでしょう。iCloud Driveの同期対象フォルダは\n~/Library/Mobile Documents です。もちろん、Dropbox, Google Drive, One Driveなどのサードパーティのクラウドサービスでも良いです。\nまた、これらの同期対象フォルダを、Time Machine対象にもしておけば、前述のように、過去の設定に戻すことも可能です。\nシェルスクリプトでESPバックアップする ということで、ESP全体をTime Machineバックアップ対象で、さらにクラウド同期対象のフォルダにコピーすれば良いわけです。そのためには、\nESPをマウントする 内容をコピーする ESPをアンマウントする 手順が必要です。ESPをマウントしっぱなしにすれば手間は減りますが、誤操作やセキュリティのことを考えると、不要な時はマウントしない方が良いと考えます。ではこの手順をシェルスクリプトで自動化してみましょう。\nターミナルから\ndiskutil list コマンドすれば、SSD/HDDの一覧を見ることができます。複数のSSD/HDDが搭載されていると、/dev/disk0、disk1、disk2と複数のボリュームを確認できます。このドライブ番号の割り当ては起動するごとに変化します。なのでESPのある起動ボリュームの番号も、毎回変動します。一方で、ボリュームやパーティションにはUUID (Universally Unique Identifier)が割り当てられていて、こちらは不変です。\nESPのUUIDは次のコマンドで知ることができます。 例えばESPが、disk0s1に割り当てられている場合、\ndiskutil info disk0s1 とすると、いろいろな情報が出てきます。この中に、\nDisk / Partition UUID: 9FXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX というように表示されているのが、ESPのUUIDです。\nUUIDがわかれば、次のようなスクリプトで、ESPをマウントして、コピーして、アンマウントできます。\n#!/bin/sh ESPUUID=9FXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX BACKUP=~/Documents/Hackintosh/_currentConfig/Z97A/ diskutil mount $ESPUUID rsync -av --delete /Volumes/EFI/ $BACKUP diskutil unmount $ESPUUID ここでは、書類フォルダの中のHackintosh/_currentConfig/Z97A/の中に、ESPの内容をコピーしています。rsyncコマンドは、-aオプションつけることでバックアップに使えます。更新のあったファイルだけがコピーされます。-vは進行状況を詳しく表示するオプションです。動作確認には便利ですが、後で自動化するときには不要かもしれません。また–deleteは、オリジナルファイルが消去された場合に、バックアップ先でも消去するというオプションです。\nログイン項目に設定する このシェルスクリプトをログインするたびに動かせば、最新のESPをバックアップしておけます。そこで、「システム環境設定」「ユーザとグループ」からログイン項目に追加してみます。起動に失敗したらスクリプトは動かないので、必ず動く状態のESPがバックアップされます。バックアップ先がTime Machineの対象なら過去に遡って設定を復元できますし、クラウド同期対象なら他のマシンから見ることができます。\nなお、シェルスクリプトをログイン項目に追加する場合には、拡張子をcommandにしておく必要があります。commandの場合は、ファインダからの起動でTerminal.appが起動するからです。\nAutomatorでアプリケーションにする これまでの方法で、全く問題なくバックアップできるのですが、ログイン直後にTerminal.appが起動したままになるのがちょっと邪魔です。この問題は、シェルスクリプトをアプリケーションにすれば解決します。\nmacOSには、シェルスクリプトをmacOSのアプリケーションにしてしまう、便利なツールがあります。Automator.appです。これを使えば、通常のアプリケーションと同様に、アイコンをダブルクリックすると単体で起動するようになります。今回は使いませんが、ドラッグ\u0026amp;ドロップも機能します。\nAutomator.appを起動し、アプリケーションを選び、アクションから「シェルスクリプトを実行」をドラッグもしくはダブルクリックで選びます。右に出たウィンドウに、先ほどのシェルスクリプトをコピー\u0026amp;ペーストします。\nこれを保存すれば、シェルスクリプトがmacOSアプリケーションになります。\nこれをログイン項目に登録すれば、バックアップが実行された後、痕跡なく終了します。\n","date":"2018-01-28T17:18:13+09:00","image":"/uploads/2018/01/20180128140243.png","permalink":"/posts/76/","title":"ESPを自動バックアップする"},{"content":"X299マザーボードにSkylake-Xを搭載した自作水冷マシンにmacOSをインストールする記事がtonymacx86で紹介されています。iMac Proのようなマシンです。この記事が最初に書かれたのは去年の8月ですが、適宜アップデートされているようです。18コア36スレッドの究極のmacOSハードウェアを作るのは、ロマンですね。記事はかなりの長文ですのでサクッと抄訳してみたいと思います。\nwww.tonymacx86.com\n—————————-ここから抄訳—————————-\u0026laquo;\nSkylake-X/X299のマシンにmacOS High Sierra 10.13.2をインストールしてiMac Pro相当のマシンを作るためのガイドです。\nA.) ハードウェアの概要 i7-7640X と 7740X は、2チャンネルのDDR4-2666であったり、PCI express 3.0が16本しかなかったりで、見劣りがします。i7-7800とi7-7820は4チャンネルDDR4-2666ですがPCIeが28本です。ということで、最高の性能を得るためには、i9-7900X以上のCPUを選択することをお勧めします。\n今回の構成は以下です。\nマザーボード: Asus Prime X299 Deluxe CPU: i9-7980XE (18 core, 4.4Ghz) メモリ: Tridentz DDR-4 3200 Mhz 128GB (8x16GB) GPU: Gigabyte Aorus GTX 1080 Ti Waterforce WB Extreme Edition 11GB システムディスク: EVO 960 NVMe M.2 1TB (system disk macOS High Sierra 10.13.2); EVO 960 NVMe M.2 1TB (system disk macOS Sierra 10.12.6 Sierra) 電源: Corsair AX1500i モニター: LG 38UC99-W 38″ curved 21:9 Ultra Wide QHD+ IPS Display (3840 pix x 1600 pix) Bluetooth + Wifi: BCM94360CD ケース: Thermaltake Core X71 CPUとグラボの水冷： 2台のD5ポンプ、360mm, 280mmのラジエータを複数使ったDIY水冷 B.) マザーボードのBIOS B1.) ASUS BIOSにパッチを当てる 本物のMacでは、MSR 0xE2レジスタが書き込み可能で、これによりOSX XCPM電力制御を行っています。そこで、ASUSのBIOSにパッチを当て、MSR 0xE2レジスターを書き込みできるようにアンロックします。BIOSにパッチを当てる手順は以下です。\nBREWをインストールしてQT5をインストールする CodeRush UEFIPatchをGithubから入手する @interferenc氏によって作られたパッチのファイルpatches.txtを入手する ASUSから最新のBIOSを入手する UEFIPatchコマンドでパッチを当てる 出来上がったBIOSをFAT32のUSBメモリに入れる BIOS起動時にF2を押してUSBからBIOSをアップデートする 再起動した後、ターミナルからbdmesg | grep MSRコマンドを入れると、MSR 0xE2レジスターがアンロックされたことを確認できます。\nB2.) ASUSのBIOS設定 BIOSを設定します。（**訳注：**通常の設定ですので省略します）\nB3.) – GigabyteのBIOS設定 BIOSを設定します。（**訳注：**こちらも省略します）\nC.) エラーを防ぐための重要なアドバイス 配布しているファイルでは、AptioMemoryFix.efiの代わりに再びOsxAptioFix3Drv-64.efiを使うようにしました。 ATI RX560、580のユーザは、WhateverGreen.kextのv1.1.4とLilu.kext v1.2.1を使ってください。Vega 64とFrontier GPUはこれらは不要です NVIDIAのユーザは10.13 Web Driverを使ってください。 Thunderbolt EX3 PCIe拡張カードを使用できているなら、macOSインストールの時にはThunderbolt 2ドライブを外しておきます。まだ使用できていないなら、インストール時には拡張カード自体を外しておきます。 最新のapfs.efiが使われていることを確認しておきます。 sleep/wakeで問題を起こさないためにVoodooTSCSync.kextを入れておきましょう。VoodooTSCSync.kextのInfo.plistファイルの中のIOCPUNumberを書き換えておきます。 ASUS Prime X299 Deluxeで2番目のLANを使用する場合は、SmallTree-Intel-211-AT-PCIe-GBE.kextを入れるか、macOSインストール時に2番目のLANをBIOSでoffにしておきましょう。 Lilu.kextでカーネルパニックを起こしたことがあります。最新のkext類を入れておきましょう。 D.) iMac Pro 用のmacOS 10.13 High Sierraを作る D.1) iMac Pro EFIフォルダの準備 EFI-X299-10.13.2-Release-iMacPro1,1-170118.zipをダウンロードしてください。この内容でEFIフォルダをデスクトップなどに作ります。 EFI/CLOVERのconfig.plistをClover Configurator (v.4.60.0以上) で開いて、SMBIOSセクションのシリアル番号、ボードシリアル番号、SmUUIDを設定します。 VoodooTSCSync.kextをEFI/CLOVER/kexts/Other/に入れます D.2) iMac Pro macOS High Sierra 10.13.2 (17C2120) のInstallerパッケージを作る **訳注：**iMac Proにインストールされているらしい10.13.2 (17C2120)は、現在App Storeでは配布されていません。App Storeにある最新は、17C205です。17C2120をcurlコマンドでアップルのサーバから取り寄せて、インストーラパッケージを作る手順が説明されています。長いのでオリジナルを見てください。もしこれからiMacを作る場合、間も無く10.13.3が出ると思いますので、そうなったらそれを使えば良いので、この作業は不要になります。\nD.3) iMac Pro macOS High Sierra 10.13.2 (17C2120) USB インストーラを作る いつものようにcreateinstallmediaコマンドで、インストール用USBメモリを作ります。作ったUSBメモリをブート可能にするために、以下の操作をします。\ncd /Volumes/USB_VOLUME mkdir .IABootFiles cd .IABootFiles cp /Volumes/USB_VOLUME/System/Library/CoreServices/boot.efi . 前のD.1節で作ったEFIフォルダを、このUSBのEFIパーティションに入れます。\nD.4) iMac Pro macOS High Sierra 10.13.2 (17C2120) のクリーンインストール Skylake-X/X299の自作システムに、17C2120をクリーンインストールします。このために、\n新しいSSDなどを用意してHFS+でフォーマットします 先のD.1節で作ったEFIフォルダをそのSSDのESPに入れます このSSDを自作したシステムに接続し、さらにD.2節で作ったUSBメモリを入れて起動します ブート途中でUSBメモリを起動ドライブに指定します Cloverの起動画面でUSBメモリを選びます macOSをSSDにインストールします。 インストール途中の再起動ではF8キーを押してUSBメモリから起動するようにし、Clover画面ではInstall macOS …を選択します。 次の再起動では、F8でSSDを選んで、Clover画面ではmacOS High Sierraアイコンを選びます D.5) すでに動いている10.13 SSDを自作iMac Pro用に変換する **訳注：**配布されている、iMac Pro非対応のmacOSを、iMac Pro対応にする方法が説明されています。ESP部分を、今回用意したものに差し替え、/System/Library/CoreService/PlatformSupport.plistにBoardID Mac-7BA5B2D9E42DDD94を追加します。これも10.13.3が出れば不要な作業かと思います。\nD.6) iMac Pro macOS High Sierra Build Update Procedure クリーンインストール、もしくは、iMac Pro用macOSへの変換が成功した後、10.13.2追加アップデートを当てることができます。これでビルド番号は17C2120から17C2205になります。10.13.3 Public Beta 4へアップデートすることもできます。これらは通常のApp Storeから可能です。\n**訳注：**もしかしたら10.13.3 Public Beta 4を使えば、そのままiMac対応High Sierraになっていたのかもしれないですね。\nE.) インストール後の設定 E.1) CPU電力制御設定 **訳注：**電力制御を動かすための設定が説明されています。もともとXeonやXシリーズは、電力制御の設定が必要だったのですが、iMac Proのおかげで多少は楽になったようです。それでもいくつか作業が必要のようです。また、ssdtPRGen.shを使ってSSDTも作ります。\nE.2) グラフィックス RX 560, RX 580はWhateverGreen.kext v1.1.4とLilu.kext v1.2.1.の組み合わせで使うことができます。 Vega64とFrontierは10.13でそのままサポートされていますのでWhateverGreen.kextやLilu.kextは不要です。 NVIDIAのカードもWeb Driverでサポートされています。17C2120や17C2205が動くバージョンのWeb Driverも配布されています。10.13.3 Public Beta 4を使う場合は、パッチを当てます。（**訳注：**この後パッチの方法が説明されています。） NVIDIAのブラックスクリーンを回避するには、NvidiaGraphicsFixup.kext v.1.2.1とLilu.kextを使います。10.13.3 Public Beta 4の場合は、NVDAStartupWeb.kextへのパッチが必要です。 E.3) オーディオ オーディオはAppleALC.kext v1.2.1.とLilu.kext v.1.2.1で対応できます。ただしconfig.plistでDSDTにパッチを当てる必要があります。またAudio IDの設定も必要です。 VoodooHDA.kext 2.9.0.d10も使えます。が、VoodooHDA.kextのInfo.plistを書き換える必要があります AppleHDA.kextにパッチを当てることもできます。ただ、これはシステムがバニラでなくなってしまいます。 E.4) USB の設定 10.13.2追加アップデートから、X299マザーボードの全ての外部・内部USB 3.1 Gen 1 とUSB 2.0 Gen 1が仕様通りのスピードで動くようになりました。また、全ての外部・内部USB 3.1 Gen 2ポートも140 MB/sで動きます。\nE.5) ASUS Prime X299 Deluxe Thunderbolt EX3 PCIeカードを使う Thunderboltカードを使うためには、残念ながらWindowsもインストールする必要があります。Windowsでカードが認識されて初期化されて、初めて、BIOSでThunderboltの設定ができるようになります。そこで、Windowsを起動できるようにインストールして、付録のThunderbolt EX3 DVDからドライバをインストールします。この後、BIOSからカードを設定します。\nE.6) NVMe の互換性 10.13からSamsung EVO 960 M.2 NVMe SSDのような市販のSSDがネイティブに使えるようになりました。10.12で必要だったパッチは全て不要になりました。\nE.7.) SSD TRIM Support TRIM機能はアップル純正SSDでしかonになりません。そこで、IOAHCIBlockStorage.kextにconfig.plistでパッチを当てます。それでTRIMが有効になります。\nName* Find*[HEX] Replace*[HEX] Comment MatchOS IOAHCIBlockStorage 4150504c 45205353 4400 00000000 00000000 0000 Trim Enabler 10.12.x,10.13.x E.8) ASUS Prime X299 Deluxe のEthernet このマザーボードには、Intel I219-VとIntel I211_ATの二つのEthernet端子がついています。前者は、Hackintoshで以前からサポートされていました。後者も、SmallTree-Intel-211-AT-PCIe-GBE.kextのおかげで使用できるようになりました。\nE.9) ASUS Prime X299 Deluxe PCI Device Implementation 全てのPCIデバイスを正しくインストールするために、適切なACPI DSDT置き換えパッチテーブルと、SSDT-X299.amlが必要です。ASUS Prime X299 Deluxeのためにどちらも用意されています。添付したconfig.plistに含めてあります。\nE.10) 「このMacについて」のCPU表示 見た目だけの問題ですが、何もしないと、Processorの表示がUnknownになっています。これは\n/System/Library/PrivateFrameworks/AppleSystemInfo.framework/Versions/A/Resources/English.lproj/AppleSystemInfo.strings を書き換え、config.plistのCPUセクションのTypeをUnknownに設定すると修正できます。\nE.11) Logic-X などのAudioソフトウェア機能 MSR 0xE2レジスタのロックを外したことで、macOSのKernelが全て電力制御を担当することになり、以前のLogic-Xやその他のオーディオソフトウェアの問題が解決されました。それでも、Logic-Xで設定しなければならない項目があります。（**訳注：**これらのアプリのことがよくわかってません。すみません。）\nF.) ベンチマーク GeekbenchのCPUベンチマークはMulti-coreが65,348, Single-coreが5,910です。 CinebenchのCPUベンチマークは4,618 CBです。 GeekbenchのOpenGLは229,965です。 GeekbenchのMetal2は242,393です。 Unigine Heaven Benchmark 4.0はFPS: 76.6, Score 1929 Unigine Valley Benchmark 1.0はFPS: 58.2, Score 2435 ","date":"2018-01-24T22:26:56+09:00","image":"/uploads/2018/01/20180120200010.png","permalink":"/posts/77/","title":"Asus Prime X299 Deluxe, 7980XE"},{"content":"↓ブートストラップ\nご存知のようにコンピュータを起動することをブートすると言います。このサイトの名前も、「macOSを起動しよう」という意味です。ブートは一般の辞書にも動詞として載っています。このブートの元の意味は長靴です。\n一方、公式WikiによるとCloverの正式名称は、Clover Bootloaderです。Bootloaderというのは、\n– Bootstrap program loader\nを短くした言い方です。loadするというのは搭載するとか装填するという意味で、HDDなどからプログラムを読み込んで、コンピュータ上のメモリに格納して、プログラムが動作できるように準備する作業をさします。OSは稼働している間、こういう仕事をいつもやっています。当然ですが、loadするのもプログラムで実施しています。\nではコンピュータの電源を入れたばかりで、メモリー上のプログラムが空っぽの状態では、どうやってloadすれば良いのでしょうか。load作業を実施するプログラムはHDDの中にあります。缶切りが缶詰の中に入っている状況です。そこで使われるのが、缶切り機能だけに特化したBootstrap programという短い(OS全体に比べたら)プログラムです。CloverはmacOSを稼働させるために、まずはmacOSの核(kernel)となる基本機能を含むbootstrap programを読み込み (load) ます。次に、bootstrap programに制御を移管し、macOSの全体の読み込みと設定を行ってもらいます。なので、Cloverはbootstrap program loaderなわけです。\nそもそもbootstrapって何かと言うと、上の写真にあるブーツの踵などについている平たい紐のことです。ストラップは平たい革紐のことです。ブーツに足を突っ込んで、このストラップを引っ張ってブーツを持ち上げると、楽に履けます。この時にもっと頑張ってストラップを引っ張ったら、自分で自分の体を持ち上げられるかもしれません。それでpull oneself up by one’s bootstrapsという言い回しは、「自力でなんとかする」という意味になりました。自力でなんとかOSを立ち上げるためのプログラムも、これにちなんでbootstrap programと呼ぶようになりました。\nbootstrap programをloadするためには、\nプログラムを装填するためのメモリ領域を確保して ファイルシステムから読み込む 二つのステップが必要です。Cloverではそのために以下の設定が必要です。\nメモリを確保する マザーボードに電源が投入された直後は、UEFIという簡易的なOSのようなプログラムが動いていて、メモリなどのコンピュータリソースを管理しています。CloverはUEFIにお願いしてmacOSのbootstrap programを格納するためのメモリ領域を確保します。メモリ上には、すでにグラフィックスカードや他の周辺機器のBIOSが居座っていることもあります。空き地を探したり、空き地を確保するためのこれらを移動したり、いろいろな作業が必要です。その手続きが、マザーボードや搭載周辺機器によって異なることがあります。なので、それを行うプログラムもハードウェアに合わせて選択する必要があります。そこで、Cloverの設定作業\nでは、以下の選択肢の中から必要なプログラムを1つだけ選択して、EFI/CLOVER/drivers64UEFI/の中に格納します。\nAptioMemoryFix.efi OsxAptioFix3Drv-64.efi OsxAptioFix2Drv-64.efi OsxAptioFixDrv-64.efi OsxLowMemFixDrv-64.efi 必要なのは、このうちの1つだけです。このリストの複数のファイルをdrivers64UEFIに入れてはいけません。また、推奨する順に番号が振られています。この順番に入れてみて、ちゃんと起動すればそれを使うのが良いです。できれば1か2が望ましいです。\nこの選択が正しくないと、メモリを確保できません。メモリを確保できないと、Cloverが起動した直後に、\nこんなマークが出て止まってしまいます。-vオプションで起動すると、\nOSXAptioFix2Drv: Starting overides for SystemLibrafyCoreServicesoot.efi Using reloc block: no, hibernate wake: no Error allocating 0x116f5 pages at 0x000..... alloc type 2 Couldn\u0026#39;t allocate runtime area Boot failed, sleeping for 10 seconds before exiting... こんなメッセージが現れて止まってしまいます。こんなメッセージの場合もあります。\nAptioMemoryFix(RC5) : Starting SystemLibraryCoreServicesoot.efi Hibernate wake: no does printf work?? また、これらのエラーは、必ず出るとは限りません。起動のタイミングで、周辺機器BIOSがたまたま分散せずにメモリマップ上のかたまった場所に配置され、空き領域が容易に確保できるような場合には、エラーが発生しにくいです。なので、何度も試すとエラーが出る場合もありますし、逆に、ほとんどエラーが出るけど稀に起動できたりすることもあります。\n上記の5個のプログラムの違いは、以下で説明されています。\nwww.insanelymac.com\nそれによると：\nOsxAptioFixDrv-64.efi と OsxAptioFix2Drv-64.efi は、Clover 4368 以前に作られて、NVRAMサポートしていません。歴史的経緯で残されています。高位アドレスにワープしたメモリマップでは、OsxAptioFixDrv-64.efiだけが動くこともあります。 OsxAptioFix2Drv-64.efi は、メモリブロックの配置変えを行わない機能削減バージョンです。いくつかのハードウェアや古いOSバージョンでは動かないかもしれません。しかし、OsxAptioFixDrv-64.efiに比べると、こちらはハイバーネーションをサポートしています。 OsxAptioFix3Drv-64.efi は、Clover 4369でOsxAptioFix2Drv-64.efiから改変されたバージョンです。これはNVRAMをサポートします。Clover 4379ではランタイムの不具合が解消されました。Clover開発チームは今後、このバージョンだけを改良していきます。 AptioMemoryFix.efi は、サードパーティメモリ修正ドライバをそのまま使っています。そのため、色々手を加えているOsxAptioFix*Drv-64.efiシリーズよりもたぶん優れています。まずは、AptioMemoryFix.efiが動くかどうかを試すべきです。 OsxLowMemFixDrv-64.efi は、やはりメモリ修正ドライバですが、Clover 608から改良されていません。 とのことです。それで上記のような優先順位で、1から5の順に、動くプログラムを探すのが良いです。手元のMSIマザーボードでは1が使えました。\n追記：起動に失敗する原因は、連続したメモリー空き空間が確保できないためです。KASLR（カーネル番地乱数化）をoffにしてslideを指定して、カーネル読み込み場所を明示的に指定することで解決します。詳しくはこちらをご覧ください。\nslideでカーネル読み込み番地を調整する (Clover編)\nファイルシステムから読み込む ファイルを管理するOSの仕組みがファイルシステムです。起動パーティションに使われるファイルシステムは、macOS Sierra以前ではHFS+だけですが、macOS High Sierra以降ではHFS+とAPFSの2種類が使われます。OSは、ファイルシステムを知り尽くしていて、その機能を全て使いこなします。bootstrap programに必要なファイルもファイルシステムの中に置かれていて、OSならばそれを読みだすのは簡単です。でも、コンピュータに電源を入れた直後は、ファイルを読みだすプログラムも、ファイルシステムの中にあります。またもや缶切りが缶詰の中にある状態です。\nそこで、なんとかbootstrap program関連ファイルだけでも読みだすためのプログラムが作られています。それが、CloverのEFI/CLOVER/drivers64UEFI/の中に格納される次のファイルです。\nVBoxHfs.efi HFSPlus.efi（Cloverには同梱されてません） apfs.efi VBoxHfs.efiとHFSPlus.efiは、いずれもHFS+ファイルシステムのファイルを読み込むためのドライバーです。apfs.efiはAPFSのファイルを読み込むためのドライバーです。macOSがHFS+に格納されている場合は、VBoxHfs-64.efiもしくはHFSPlus.efiのどちらか一つが必要です。macOSがAPFSに格納されている場合は、apfs.efiが必要です。これらが無いとCloverの起動選択メニューにmacOS起動ボリュームが現れません。\nVBoxHfs.efiだけがCloverの配布セットに含まれています。VBoxHfs-64.efiはオープンソースのHFS+ドライバです。オープンソースであるために、Appleの許可を得ずに（純正ドライバーの配布をお願いしても許可をもらえないと思いますが）配布することが可能なのです。\nHFSPlus.efiはApple社純正のドライバで、本物のMacintoshのファームウェアで使われているものです。ハッカーのみなさんの技術で、ファームウェアから取り出されて、配布されています（名前で検索すれば配布サイトが出てきます）。多くのガイド、例えばこちらでは、VBoxHfs.efiをHFSPlus.efiに置き換えると良いと書かれています。オープンソースのプログラムより、Apple純正の方が高速だからという理由です。ただ、起動時間を実測してみたところ、\nVBoxHfs-64.efiは約14秒 HFSPlus.efiは約9秒 程度の違いしかありませんでした。ブートの時しか関係しないことですし、現行macOSはAPFS起動のみですので、無理して入手して置き換える必要はないと思います。\napfs.efiは、macOS High Sierraの /usr/standalone/i386/ の中にあります。システムがAPFSに格納されている場合は、これが無いとCloverの起動選択画面に現れません。apfs.efi入手方法の詳細な手順は以下をご覧ください。\n2018/06/19更新：Clover 4558からApfsDriverLoader.efiというドライバができて、apfs.efiの機能を自動的にロードしてくれるようになりました。なので、 /usr/standalone/i386/ からapfs.efiを取り寄せてESPに置く必要は無くなりました。\nHackintoshをHigh Sierraにする\n","date":"2018-01-19T12:08:07+09:00","image":"/uploads/2018/01/20180120002246.png","permalink":"/posts/78/","title":"Hackintoshの長靴 (ブート)"},{"content":"\nHackintoshで使うコンピュータはもともとWindowsをインストールする前提で作られているので、当然ながらWindowsも走ります。本物のMacでは、Boot CampというツールでWindowsを動かすようにしますが、その必要はありません（そもそもBoot Campは使えません）。今回は、macOSとWindowsのマルチブートを設定するときの注意事項を書いてみました。\n別ドライブにインストールするのが楽 WindowsとmacOSを同一の物理ドライブの別パーティションにインストールすることは可能ではあります。でも色々面倒なので、できれば別の物理ドライブに、macOSとWindowsを分けてインストールするのが簡単です。デスクトップPCなら複数ドライブ搭載は簡単だと思います。\n同一のドライブの別パーティションにmacOSとWindowsをインストールしようとすると、それぞれがESPを書き換えることになります。Cloverで設定したものが、Windowsをインストールすると動かなくなります。もう一度、設定すれば良いのですが、かなり面倒です。このような問題は、ESP以前のMBR（マスターブートレコード）を使っていた時代からありました。物理的に別のドライブにインストールすれば、それぞれのESPに個別に起動項目が書き込まれるので、干渉しません。別のドライブにインストールされたWindowsは、UEFI/BIOSの起動メニューで選択することもできますし、Cloverの起動選択画面からも起動できます。\n最近の経験では、そもそもパーティションスキームが違ってインストールできないこともありました。特にAPFSになって採用された新しい論理パーティションなどは、Windowsインストーラから使えません。なので同じドライブにインストールしようとする場合は、パーティション分けの方法も面倒になり、試行錯誤が必要になると思います。\nインストールに関係ないドライブを外す Windowsをあまり使わないこともありますが、Windowsインストーラの挙動は、いまだに謎です。インストール対象のドライブ以外のドライブがコンピュータに多数接続されていると、インストールできないことがあります。もしかしたら接続されているドライブがmacOS用にパーティション分けされていたのがいけないのかもしれません。関係ないドライブは外しておいた方が良いです。\n先日、m.2 SSDを外すのが面倒だったので接続したまま別ドライブにインストールを試みたら、m.2 SSDのESPに起動ファイルが書き込まれてCloverが起動しなくなってしまいました。Windowsインストーラは、インストール先として指定しないドライブを書き換えることもあるようです。面倒でもm.2 SSDを外すか、せめてUEFI/BIOSでm.2を読めないように設定して、Windowsインストールするのが良いと思いました。\n時刻を合わせる macOSとWindowsを切り替えて使用すると、時刻が合いません。9時間だけずれます。macOSはUTC (協定世界時: Coordinated Universal Time, 昔はグリニッジ標準時GMTと呼ばれていた時刻）を使っているのに対して、Windowsは現地時間を使っているからです。\nコンピュータは、ファイル作成時刻などを管理するために、時計機能を備えています。マザーボードにはRTC（リアルタイムクロック）というチップが搭載されていて、電源が切れている時も、ボタン電池で時刻を刻んでいます。時差の違う場所に置かれたコンピュータ同士をネットワーク接続で使うことを考えると、コンピュータの時刻はどれか一つの基準時間を使うべきです。そうするとUTCを使用するのが順当です。ということで、macOSやLinuxなどのUNIX系のOSでは、UTCで時刻を管理して、必要に応じて現地時間に換算して表示しています。\nUNIX系OSは専門家が使う高価で大掛かりなコンピュータのためのOSとして開発されました。一方、Windowsの先祖は、単独で動く簡素な個人用コンピュータ（マイクロコンピュータ、マイコン）で使われたOSです。昔のコンピュータには電池バックアップのRTCなどなかったので、起動時に時刻を入力させられました。個人ユーザがいちいちUTCと時差を入力するのは面倒なので、マイコンの時計は現地時間に設定することになっていました。それでWindowsは今でもRTCを現地時間に設定していて、UTCが必要な場合には、現地時間から換算しています。\nRTCがUTCでも現地時間でも、必要に応じて換算すれば良いので問題はありません。でも、macOSとWindowsで同一のRTCを共有すると、OSを切り替えるたびに時間がずれてしまいます。Boot Campではこの問題を解決するドライバが用意されています。Hackintoshでは、当然ながらそういう配慮はありませんので、自力で解決することになります。\nWindowsをUTCにする WindowsとmacOSのどちらを相手に合わせても良いのですが、歴史的な経緯で仕方なく(?)現地時間を使っているWindowsを正統なUTCに切り替える方が簡単です。これにはレジストリを書き換えます。Windowsでregedit.exeを実行するとレジストリエディタが起動します。\n左の階層から、コンピュータ、HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Control, TimeZoneInformationと辿っていきます。TimeZoneInformationで右ボタンクリックでコンテクストメニューを呼び出し、「新規 (N)」「DWORD (32ビット) 値(D)」を選択します。\nここで、RealTimeIsUniversalという値を作り、この名前をダブルクリックして設定ウィンドウを開き、値を1に設定します。このあとWindowsをシャットダウンし、一旦macOSを起動して、またWindowsに戻ってくると、Windowsの時刻がmacOSと一致します。\nコマンドプロンプトで設定する フォーラムで教えていただきましたが、レジストリエディタを使う代わりに、Windowsのコマンドプロンプトから設定することも可能のようです。以下のようにタイプします。\nreg add \u0026#34;HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\TimeZoneInformation\u0026#34; /v RealTimeIsUniversal /d 1 /t REG_DWORD /f ","date":"2018-01-14T14:48:50+09:00","image":"/uploads/2018/01/20180114123231.png","permalink":"/posts/79/","title":"Windowsと同居する"},{"content":"\nCPUのMeltdownとSpectreという脆弱性が話題になっていて、これに対応したmacOS 10.13.2 Supplemental Updateが早速公開されました。 これによりmacOSのbuildは17C88から17C205になります。アップデートは、App Storeからダウンロードしてそのまま自動実行するだけでした。再起動時のClover起動パーティション選択画面でも、Boot macOS Install from …の項目が自動的に選択されましたので、ノータッチでアップデートします。OSでサポートされているグラフィックスカード(Radeon RX 580)でしたので、アップデート後も問題なく画面表示しました。www.tonymacx86.com\nこの脆弱性自体はCPU固有のもので、OSからは影響を緩和することしかできないとも言われています。とはいえ、そんなに心配するものでもないようです。\nsupport.apple.com\nただ、Windowsで対応アップデートをした結果30%程度性能が低下したという話題もあって、気になるところでした。ということで、今回のアップデートを当てる前と、当てた後でベンチマークをとってみました。結論から言うと、性能低下はありませんでした。使用したCPUはCore i7-4790Kです。\nCINEBENCH R15 アップデートを当てる前のCPUスコアは833cbだったのに対して、アップデート後は831cbでした。測定ごとにもっと変動しますので、この差異は測定誤差内です。\nGeekbench 4.0.4 Tryout こちらはスコアが上がりました。アップデートを当てる前のMulti-Core Scoreは14537だったのに対して、アップデート後は15337でした。\nメモリへのアクセスが低下するという情報もありましたが、メモリスコアも上がりました。Multi-Core PerformanceのMemory Scoreは、アップデートを当てる前が4572だったのに対して、アップデート後は5124になりました。\nということで、10.13.2 Supplemental UpdateでCPU性能が低下する心配はないようです。\n追記 10.13.2追加アップデートに対応するNVIDIA Webドライバも出たようです。いつも通りのアップデート方法で、NVIDIAグラフィックスカードを使っているマシンが高解像度表示が可能になりました。NVIDIAの中の人は、いつもながらドライバのアップデートが早くてありがたいです。\nwww.insanelymac.com\n","date":"2018-01-09T23:52:06+09:00","image":"/uploads/2018/01/20180109233021.png","permalink":"/posts/80/","title":"CPU不具合対応10.13.2追加アップデートで性能低下する？"},{"content":"\nHackintoshでkextを入れ替えたり、config.plistを書き換えたりなど、色々実験していると、起動しなくなる状況に遭遇することがあります。そんな場合に対処できるように、起動可能なパーティションのバックアップを持つことは、Hackintoshを使う上での必須の習慣だと思います。\nバニラなインストールをすると、SSD/HDDの本体パーティションにmacOSが入り、macOSでは使用しないEFI System Partition (ESP)にClover bootloaderやkext類がインストールされます。\n/posts/131/\nHackintoshが動かなくなったことに備え、バックアップする対象は、以下のいずれかになります。\nESPとmacOSインストーラ ESPとmacOS ESPのみ それぞれについて、以下で説明します。\n1. 導入用USBメモリを残しておく 一番普通の方法かもしれません。一般的な手順では、USBメモリにmacOSインストーラを作り、これにCloverをインストールします。このUSBメモリを大事に保存しておけば、本体が起動しなくなった場合に利用できます。これがあれば、一切を消去してもう一度インストールし直すことができます。でも、そこまでやらなくても、macOSインストーラで起動できれば、ターミナル.appを起動することができるので、かなりの作業が可能です。起動失敗を引き起こしたkextを取り除いたり、config.plistを元に戻したりできます。\nまたバニラなインストールがされていれば、ESP部分を書き損じても、macOS本体は正しく残っている可能性が高いです。USBメモリのCloverで起動して、起動しなくなったドライブのmacOSから起動できれば、修復作業が容易です。\nこの方式の難点は、非常用のUSBメモリは滅多に使わないので、失くしてしまいやすいことです。手元にあるとついつい他の用途に使ってしまいます。気軽に使えないようにPCケースの中に入れておくのも良いかもしれないです。\n2. CloverとmacOSを複製しておく バニラなインストールをしていれば、macOS本体に手を入れることはないので、Hackintoshの不具合でmacOS本体を壊す危険はありません。でも、macOSのバージョンアップ、特に年に一回のメジャーバージョンアップに備えて、CloverとmacOSの両方をインストールして、バックアップとしておくのが良いです。\nバックアップのためには、いつも使うSSD/HDDとは別のドライブに、macOSとCloverをインストールします。通常のインストールと同様に、インストール用のUSBメモリから起動して、対象とするドライブのパーティションをフォーマットして、macOSとCloverをインストールしても良いです。でも、すでに起動できるmacOSドライブがあってこれをバックアップするならもっと簡単です。以下のようにできます。\nApp StoreからダウンロードするmacOSインストーラを起動して、対象とするパーティションにmacOSをインストールします。 必要ならば移行アシスタントを使って現在の設定とアプリケーションもバックアップします。 対象とするドライブのESPに、現在起動しているESPの内容をコピーします。（Cloverインストーラを起動しても良いですが、ファインダによるドラッグ\u0026amp;ドロップだけでもバックアップできます） もしマシンに複数のHDDを接続していて、その一部をデータ用やTimemachine用にしているような場合、そのHDDの最初に60GBくらいのパーティションを用意します。そしてこのパーティションとESPそれぞれに、上記の手順でmacOSとCloverを入れておくと良いです。macOS自体は30GB弱あればインストールできます。60GBあれば必須のアプリケーションと多少の作業は可能です。内蔵HDDにバックアップを用意しておけば、USBメモリと違って紛失する心配もありません。\n3. ESPを複製しておく バニラなインストールをしておけば、Hackintoshに必要なものは全てESPに入っています。設定を変えて起動しなくなる場合も、ほとんどの場合がESPの内容を書き換えてしまったことが原因です。そこで、ESPだけをバックアップしておけば、大抵の場合は、これから起動することで復帰できます。ESPは容量も少ないですので、バックアップも容易です。データ用のHDDやUSBメモリでは使われていない領域ですので、あちこちにバックアップしておくと良いです。内蔵SSD/HDDにも、空のESPがあったら、今使っているESPの内容をコピーしておきましょう。\nESPにあるファイルだけを、ファイルサーバやクラウドに保存しておいても良いと思います。これまでの説明で用意したバックアップのSSD/HDD/USBメモリが全て無くなってしまっても、ESPの内容さえ持って入れば、手元のSSD/HDD/USBメモリのESPにコピーして起動させることができます。\n4. ESPを自動バックアップする **追記：**ESPを自動的にバックアップする方法をこちらに書きました。\nESPを自動バックアップする\n","date":"2018-01-03T12:01:34+09:00","image":"/uploads/2017/12/20171217172024.png","permalink":"/posts/82/","title":"起動失敗に備えてバックアップ"},{"content":"（更新：2017.1.2 新年の起動画面を追加）\nクリスマスになってCloverの起動画面がクリスマス仕様になりました。最初にこれを見た年はびっくりしたので、今年からHackintosh始めた人は新鮮だったのではないでしょうか。 ちなみに、新年になったら今度はしばらくの間、新年仕様に変わるはずです。旧漢字TalkとかMac OSでは新年になると「あけましておめでとうございます」表示が起動画面に出てました。Macintoshはそういうのを楽しむ文化なんですね。\nとはいえ、複数の設定切り替えを、テーマの切り替えで確認していた人には、全部がクリスマス／新年になってしまうので厄介です。年末年始はHackしないでゆっくり休みなさいという意味かもしれませんが。また、もしかしたらクリスチャンじゃ無いからクリスマスは要らないという人もいるかもしれません。この機能を消して、通常の、設定済み起動画面に戻すのは簡単です。\nご挨拶の消し方 起動画面を定義するCloverの設定フォルダであるthemesにchristmasもしくはnewyearという名前のフォルダが入っているかと思います。これらはCloverのインストーラがデフォルトでインストールしますので、大抵はあるはずです。バニラなインストールでCloverをESPに入れてあるなら、christmasやnewyearは、EFI/CLOVER/themes/の中にあります。これらの名前のフォルダがあると、年末年始に自動的に切り替わります。そこでフォルダ名を別の名前に変更する（例えばchristmasをchristmas2などに変える）と、「季節のご挨拶」機能は効かなくなります。\n新年のご挨拶 新年になりました。Cloverの起動画面も新年バージョンになりました。今年もよろしくお願いします。本物のMacで新年が祝われなくなってしまって、祝ってもらえるのはいまやHackintoshだけというのが面白いですね。以前から疑問なのですが、クリスマスツリーのような門松飾りのようなイラストは何なのでしょうか。Clover開発チームの居るロシアでの新年モニュメントなのかもしれないです。ご存知の方いらしたらよろしく。\n","date":"2017-12-27T10:07:02+09:00","image":"/uploads/2017/12/20171227094223.png","permalink":"/posts/83/","title":"Cloverから季節のご挨拶"},{"content":"\n「Hackintoshは最初は動いてもmacOSのアップデートのたびに大変なトラブルに陥る」というイメージがあるかもしれません。Apple社がちゃんとサポートしてくれている実機に比べたら面倒なのは確かですが、それほど変わらないと思います。macOSが好きで、動かないコンピュータを動かすことが趣味な人間が言うことですので、あまり当てにはなりませんが、\nマイナーアップデートは楽勝 です。例えば10.13.1から10.13.2へのアップデートのように、年に数回行われるマイナーアップデートは実機と同じくらいのお手軽さです。少なくともここ2-3年の状況では、Cloverとkextを最新に保っておけば、App Storeからのアップデートをそのまま受け入れて、macOSアップデートしてもまず問題は起こりません。\nNVIDIAのグラフィックスカードでWeb driverを使っている人は、新しいmacOSに対応したドライバが配布されるまで高解像度表示ができなくなるかもしれません。でもNVIDIAの対応はいつも敏速で、ほぼ24時間以内に新しいドライバを配布しています。Mac Proのユーザも多いのでしょうが、Hackintoshユーザからしたらありがたいメーカーです。\nメジャーアップデートは少し大変 ここのところ年に一度、9月にあるメジャーアップデート（例えば10.12から10.13へのアップデート）は少し面倒な作業が伴います。それも年に一度のお祭りとして楽しんでいただければ良いと思います。\n最近の出来事ですと、10.11でUSBの個数制限が行われて使用可能なUSBポートの数が、 コントローラ当たり15までと制限されました。この制限を解除したり、制限の枠の中で使用するポートを指定する作業が必要でした。\nUSBポートを設定する\n10.11ではSIPも導入されました。/S/L/Eや/L/Eにkextを置く場合ではSIPを無効にする設定が必要になりました。バニラなインストールをすればSIPはデフォルトでも大丈夫です。\n/posts/132/\n10.13ではAPFSが導入され、実機でファームウェアアップデートが行われました。それに合わせて、HackintoshでもSMBIOSの変更が必要でした。APFSボリュームから起動するためにはドライバも入れておかねばなりません。\nHackintoshをHigh Sierraにする\nこのようにメジャーアップデートでは予期しない課題が発生する可能性がありますので、古いmacOSはそのまま残して、予備のSSD/HDDにシステムを作って動作を確認した方が良いと思います。パブリックベータが配布されている時期か試しておけば、正式リリースの時にいち早く導入できるかと思います。\nアップデートは面倒なことだけではなく、新しいCPUへの対応、NVMe SSDの対応、ビデオカードの対応など、新しい技術の恩恵にあずかれるチャンスですので、積極的に受け入れていきたいと思います。\n10.13.2へのマイナーアップデートで躓く マイナーアップデートは楽勝と書きましたが、最近、躓いたことを書いておきます。メインで使用しているHackintoshで10.13.1から10.13.2へのアップデートをしたのですが、これはApp Storeからのダウンロードだけで簡単に終了しました。10.13.2でスリープが効かなくなったとかの噂も聞くのですが、全く問題ありません。\nところが、サブで使っているマシンでアップデートしようとしたら、インストールのための再起動で失敗しました。Boot macOS Install from xxxxが選択された、起動しようとするところで失敗し、再び再起動を無限に繰り返すようになりました。\nたまにしか使わないサブのマシンでしたので、しばらくはあきらめて10.13.1の古いままで使っていました。このところ時間もできたのでじっくりと原因を探して見たら、なんとkextの一つ、Lilu.kextが古いだけでした。Lilu.kextは10.13.2のベータ版に合わせて11月上旬に1.2.1に更新されています。メインのマシンでは早々と更新していたのですが、サブマシンでは1.2.0のままでした。とほほな単純ミスでした。\nということで、最初にも書きましたが、Cloverとkext類は最新に保っておきましょう。\n","date":"2017-12-24T16:34:39+09:00","image":"/uploads/2017/09/20170926115342.png","permalink":"/posts/84/","title":"HackintoshのOSアップデートは難しい？"},{"content":"\n寒いですね。寒いのでオイルヒーターをつけようとしたのですが、キロワット級の電力を熱に変えるのなら、目の前にある自作PCにやってもらおうと思いつきました。ついでに仮想通貨を採掘すれば電気代の節約にもなります。そこでHackintosh でマイニングしてみました。なお、マイニングは全くの初心者ですので、いい加減なことを書いていると思います。ご容赦ください。\n色々検索したところ、 MinerGate.comというところに行けば簡単に採掘を始められると書いてありました。\nminergate.com\nHackintoshのtonymacx86.comみたいなところでしょうか。メールアドレスでアカウントを作って、パスワードを作って、採掘ツールをダウンロードします。意外だったことに採掘ツールにはmacOS版もあるのですね。検索したところ、macOSで採掘したという人もたくさんいました。\nということで当然ながらmacOS版の採掘ツールをダウンロードしました。採掘ツールは、こんなアイコンのMinerGate.appというアプリケーションです。\n起動すると、今一番レートの良いお薦めの通貨の採掘ページが出ます。いまはMonero（通貨単位はXMR）というのがお薦めのようです。CPUマイニングのボタンを押すと、早速開始します。コア数を、いくつ使用するかを決めることもできます。4790Kの全8コア総出の設定で動かしたところ、180 H/s (ハッシュ毎秒）程度でした。\n聞いたことのあるEthereumという通貨（単位はETH）を試してみたら650kH/s程度でした。\nCPUマイニングボタンの隣にはGPUマイニングのボタンもあります。しかし残念ながらmac版ではサポートされてないようです。強力なグラボを何枚も搭載できるHackintosh なら是非ともGPUマイニングを試したいところです。\nEthereumのGPU採掘を行うツールは多数開発されていて、ほんの一部ではmacOSでも動くようです。MinerGate.comのこのページでリンクが案内されています。\nminergate.com\nまた、上で紹介されているethminerというツールをmacOSで使うにあたっての簡潔な使い方説明が、以下にあります。\nsteemit.com\nこのサイトで紹介されている下記のサイトからethminerのバイナリをダウンロードしてみました。\ngithub.com\nグラフィックスカードが認識されているかどうかは、以下のオプションで確認できます。\n$ ./ethminer -G --list-devices OpenCLではなくてNVIDIAのCUDAを使う場合は、-Gのところを-Uにするようですが、上記のサイトからリンクされているバイナリーはCUDAに対応していないようです。コンパイルのオプションで対応できるようなので、ソースからコンパイルすれば可能なのかもしれません。\nその結果、手元のマシンでは、搭載しているAMD Radeon RX 580と、Haswell CPUの内蔵GPUが表示されました。RX 580はメモリーサイズなども正しく認識されているようですが、Intel HD GraphicsはなぜかIris Proになっています。\nListing OpenCL devices. FORMAT: [platformID] [deviceID] deviceName [0] [0] AMD Radeon RX 580 Compute Engine CL_DEVICE_TYPE: GPU CL_DEVICE_GLOBAL_MEM_SIZE: 8589934592 CL_DEVICE_MAX_MEM_ALLOC_SIZE: 2147483648 CL_DEVICE_MAX_WORK_GROUP_SIZE: 256 [0] [1] Iris Pro CL_DEVICE_TYPE: GPU CL_DEVICE_GLOBAL_MEM_SIZE: 1610612736 CL_DEVICE_MAX_MEM_ALLOC_SIZE: 402653184 CL_DEVICE_MAX_WORK_GROUP_SIZE: 512 採掘を行うためのコマンドオプションも上記のページで紹介されています。以下は、登録したeメールアドレスが例えばsiroanko@icloud.comの場合の例です。$ ./ethminer -G -S eth.pool.minergate.com:45791 -O siroanko@icloud.com結果は以下のようになりました。4.3MH/sくらい出ているようです。4790KによるCPUマイニングに比べるとRX 580によるGPUは7倍くらいの性能が出るようです。\nさて4.3MH/sというのが、いくらくらいの収益になるのか気になるところです。以下のサイトで、調べることができます。\nwww.cryptocompare.com\nそれによると4.3MH/sで採掘すると1ヶ月あたり$14.6の収益のようです。電気代を1kWhあたり$0.2とした場合、200Wの電力を1ヶ月消費すると$28.8のようです。なので、稼ぐ金額の倍の電力を使ってしまう計算になります。\nでも、Hackintoshをオイルヒータの代わりに使うと、同じ暖かさを得るのに半分の電力で済むという計算です。これはすごいのではないでしょうか。\nおまけ このハードウェア構成で、信者としてはあまり動かしたくないWindowsを起動して、Windows版のMinerGateアプリを動かしてみました。GPUマイニングは10.6MH/s程度でした。CPUはあまり変わりません。GPUの利用に関してはWindowsのアプリの方が最適化されているようです。この性能なら、先ほどの電気代がかかっても月に$7くらいのギリギリの黒字になります。電気代がゼロもしくはマイナスで、暖房できるのはやはり凄いです。\n本気編に続きます。\nHackintoshでマイニング（本気編）\n","date":"2017-12-20T01:22:37+09:00","image":"/uploads/2017/12/20171218225555.png","permalink":"/posts/85/","title":"Hackintoshでマイニング（入門編）"},{"content":"更新：これはmacOS 10.13.2と10.13.3のための情報です。macOS 10.13.4以降の情報はこちらをご覧ください。(2018/4/17)\nSonnetの互換GPUリスト (10.13.4以降)\nSonnetはThunderbolt経由でMacintoshに接続する外部GPUボックスを販売しています。 Breakaway PuckとBreakaway Boxという製品です。\nBreakaway Puckは小型の外付けボックスで、RX 560/570が組み込まれた2種類のバリエーションがあるようです。Breakaway BoxはPCIeスロットを内蔵していて、グラフィックスカード無しのモデル、Sapphire Radeon PULSE RX 580搭載モデル、電源容量が350/550Wのモデルのバリエーションがあるようです。Sapphire Radeon PULSE RX 580搭載モデルは、Apple External Graphics Development Kitとしてアップル社の開発者向けサイトで販売されています。\nExternal Graphics Development Kit – Apple Developer\nこれらの製品のマニュアルはネット上で閲覧できます。このマニュアルの中で、\nAMDグラフィックスカードと互換性のあるMacintosh macOSと互換性のあるAMDグラフィックスカード が紹介されています。Hackintoshの機種設定と、AMDグラフィックスカードを選ぶ参考になると思いますので、この内容を見てみます。なお、10.13.2が出てからこの書類は更新されています(2017.12.7バージョンになっています)。\nhttp://www.sonnettech.com/support/downloads/manuals/egfx_macos_high_sierra_ug.pdf\n以下はこのマニュアルの翻訳です\n**追記：**なんとこのPDFがSonnetのサイトから削除されてしまったようです。ダウンロードしておけばよかった。と言うことで、以下の翻訳しか手元にありません。\nmacOS High Sierraにおける外部AMDグラフィックス macOS High Sierraにおける外部AMDグラフィックスのサポートは、公式には2018年春までベータ版状態です。現在では、外部グラフィックスによる内部ビデオの高速化は提供されていません。Sonnetがもっとも正確な情報と考えている内容を、このマニュアルでまとめておきます。なお、外部グラフィックスに関して、現時点では、アップルからもAMDからもサポートを得られないことに注意してください。Sonnet社製品を使ってなんらかの問題があったら、Sonnetの顧客サービス、support@sonnettech.comに連絡してください。その際にはSystem Reportを添付してください。\n互換性のあるMac お使いのMacintoshで外部AMDグラフィックスがベータ版サポートされていることを確認してください。Thunderbolt 3を備えたMacは全て互換性があります。\niMac 2017モデル iMac18,1-18,3 MacBook Pro 2016モデル MacBookPro 13,1-13,3 MacBook Pro 2017モデル MacBookPro 14,1-14,3 macOS 10.13.2では多くのThunderbolt 2とThunderbolt搭載Macで、外部AMDグラフィックスが動きます。これらの機種では、Thunderboltケーブルと、Apple Thunderbolt 3 (USB-C) to Thunderbolt 2 Adapterが必要です。\niMac Mid 2011 iMac12,1–12,2 (with AMD Graphics) 未検証 iMac Late 2013-Late 2015 iMac14,1–17,1 (with Intel or AMD Graphics) 互換 iMac Late 2012-Late 2013 (with NVIDIA Graphics) iMac13,1–14,2 非互換 Mac mini Mid 2011–Late 2015 (with Intel Graphics) Macmini5,1– 7,1 互換 Mac mini Mid 2011 (with AMD HD 6630M Graphics) Macmini5,1– 5,2 非互換 Mac Pro Late 2013 MacPro6,1 非互換 MacBook Pro Early 2011–Early 2015 (with Intel or AMD Graphics) MacBookPro8,1–12,1 互換 MacBook Pro Mid 2012–Late 2013 MacBookPro9,2–11,3 (with NVIDIA Graphics) 非互換 **訳注：**互換性があるとされた機種は全てIntel Graphicsからの映像出力を提供しています。Intel Graphicsをenableにしないと性能低下が発生することを確認していますので、それと関係があるのかもしれません。Thunderboltを搭載しているにも関わらずMacPro6,1が非互換なのもiGPUが無いためかと思われます。\n互換性のあるAMDグラフィックス macOS High Sierraと互換性のあるAMDグラフィックスカードを持っていることを確認してください。以下の構成は、macOS High Sierra 10.13.2でプラグアンドプレイの互換性があります。\nRadeon RX 570を搭載したBreakaway Puck (RX 560搭載モデルは非互換) Radeon RX 470, 480, 570, 580を搭載したBreakaway Box 350 Sapphire Radeon PULSE RX 580を搭載したBreakaway Box 350 Developer Edition (**訳注：**Appleの開発キットです) Radeon RX 470, 480, 570, 580, Vega 56を搭載したBreakaway Box 550 Radeon Vega 64またはAMD WX9100を搭載し電源を650Wに強化したBreakaway Box (どのモデルも可) 水冷Radeon Vega 64を搭載し電源を650Wに強化したBreakaway Box 350 訳注：****RX 470, 480, 570, 580, Vega 56, Vega 64およびAMD WX9100が使えるということです。\nセットアップ もしBreakaway Boxを持っているなら、ボックスに互換性のあるグラフィックスカードを差して、補助電源を接続して、ボックスを閉じて下さい。 Breakaway Boxまたは Puckに電源ケーブルをつなぎます。電源スイッチのあるBreakaway Boxの場合は、オンにします。 BoxとPuckは、Thunderbolt 3によりコンピュータ接続されるまでオンになりません。Breakaway BoxまたはPuckをコンピュータにThunderbolt接続し、macOSを起動します。通常の起動より時間がかかるかもしれません。 モニターに配線します。（内部ビデオは外部グラフィックスカードで高速化されません）ゲームや他のアプリケーションでグラフィックス高速化の効果を得るために、外部モニターをメインモニターにしてください。システム環境を選んで、配置を選んで、メニューバーを外部モニタにドラッグします。物理的な位置関係に合わせて、モニタ位置関係を調整してください。 制約や注意事項など\n外部グラフィックスはiMacやMacBook Proの内部ディスプレイを高速化しません。 AMD外部グラフィックスカード名は、システムに正しく表示されないかもしれません。Developer EditionのBreakaway Box 350に組み込まれたSapphire PULSE Radeon RX 580はmacOSで「Radeon RX 580」と正しく識別されます。他のGPUは正しく認識されず、「AMD R9 XXX」のような表示になります。 外部グラフィックスはミラーリングをサポートしません。 起動・再起動するときに外部グラフィックスが接続されていると、オートログインが機能しません。 外部グラフィックスをホットプラグ・アンプラグする場合は、ログイン画面に戻る必要があります。 外部グラフィックスには最大4個のモニターが接続できます。 ブートキャンプはサポートされていません。 FacebookページのBreakaway Boxブログ https://www.facebook.com/SonnetTech/ で使用体験をシェアしてください。 **訳注：**名前の表示を正しくする方法はこちらに書いておきました。\n/posts/90/\nトラブルシューティング Breakaway Boxでグラフィックスカードが認識されない 外部電源を接続したかどうか確認してください。 モニターの最高画素が選択肢に出ない システム環境設定：ディスプレイを開いて、変更ボタンをオプションクリックしてください。可能な画素数が現れます。 外部モニターが暗いまま、またはマルチモニタに表示が出ない ログアウトしてログインしてください。それで表示が出ない場合はNVRAMをリセットしてください。 ©2017 Sonnet Technologies, Inc. December 7, 2017\n","date":"2017-12-15T12:45:42+09:00","image":"/uploads/2017/12/61jbC9sb2hL.jpg","permalink":"/posts/86/","title":"Sonnetの互換GPUリスト (10.13.2以降)"},{"content":"Hackintoshをインストールするときに、すぐに稼動できることは稀で、色々な状況で起動できないことがあります。起動プロセスが停止してしまったり、カーネルパニックを引き起こすこともあります。場合によっては、グラフィックスの設定が悪くて表示が出ていないだけで、OSは起動していることがあります。その場合は、ネットワーク経由で他のコンピュータから接続して、設定をやり直すことが可能です。なので、macOSをインストールしたらすぐにリモートログインと画面共有を有効にしておくと良いです。\nリモートログイン(ssh)を設定する システム環境設定–\u0026gt;共有のサービスリストからリモートログインをオンにしておきます。そうすると「このコンピュータにリモートからログインするには、’ssh xxx@192.168.0.xxx’と入力してください。」という表示が出ます。IPアドレスはDHCPにしている場合が多いと思いますが、それほど頻繁に変わらないので、メモしておくと良いです。\nsshでログインできれば、ターミナルから設定できることは全てできます。\n画面共有(vnc)を設定する macOSに限らずUNIX系のOSは（多分Windowsも）、ターミナルのような文字操作で全ての基本操作ができるものです。同じことをGUIからも簡単に操作できるようにしているだけです。なのでsshでログインできればかなりのことに対応できますが、画面共有ができればもっと楽です。\nシステム環境設定–\u0026gt;共有のサービスリストから画面共有をオンにすると、「ほかのユーザは、vnc://192.168.0.xxx/でこのコンピュータの画面にアクセスしたり、Finderのサイドバーで’xxxx’を検索したりできます。」という表示が出ます。Finderで検索できるので、IPアドレスがわからなくても接続できます。\nTerminalから画面共有をon/offする sshで接続はできるけど、画面共有 (vnc)がオフになっていたことがあります。マシンは生きていて接続できるのに、細かい操作ができなくてもどかしい思いをしました。画面共有は実はターミナルからオンにすることも可能です。なので、このような場合は、sshから以下のように入力します。（改行されているように見えますが1行で入力します）\nsudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -clientopts -setvnclegacy -vnclegacy yes -clientopts -setvncpw -vncpw mypasswd -restart -agent -privs -all こうしてonになった画面共有は、システム環境設定でのオン・オフと違うようで、システム環境設定画面には反映されないです。これをオフにするには、以下のようにします。\nsudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate -configure -access -off ","date":"2017-12-10T12:38:08+09:00","image":"/uploads/2017/12/20171210123552.png","permalink":"/posts/88/","title":"ネットワーク経由で操作する"},{"content":"\n更新：MojaveになってmacOS Serverからほとんどのサーバ機能が廃止されてしまいました。廃止された機能の多くはmacOSに移行されたので、macOSでサーバを立上げるメリットはまだあると思います。\nmacOSは基礎がUNIXなのでWindowsに比べてネットワークやサーバ関連のツールが充実しています。最初からApacheやsshdやPHPなどが搭載されています。なのでサーバとして使うのにも適しています。\nServer.appを購入する Server.appというアプリケーションはApp Storeで購入できます。これをインストールするとmacOS Serverになります。macOSは無料なのですが、Serverは2,400円します。しかし、昔はユーザ数無制限のMac OS X Serverが10万円くらいしたことを考えると、夢のような価格です。\nもっとも、現在のServer.appは、OSそのものではなくて、すでに搭載されているサーバ機能をonにしたり、設定を管理するユーティリティです。昔のようにOSをインストールする手間に比べると、今のmacOS Serverは気軽に導入できるかと思います。\nHackintoshでServerするメリット HackintoshでServerするメリットは多いと考えています。Hackintoshで比較的難しい課題は、iMessageなどのiCloud関連のアプリケーションをちゃんと動かす、iOSやwatchOSとの連携をする、グラフィックスを正しく動かす、スリープを機能させるなどです。どちらかというとクライアントとして使う上での課題です。一方で、24時間稼働させるサーバならば、スリープなどの電源管理はあまり重要ではないです。ディスプレイやキーボード無しで運営するなら、グラフィックス機能は不要です。ssh接続や画面共有で設定すれば良いからです。なので、ちゃんと動くサーバを作ることは、完璧に動くデスクトップマシンを作るよりずっと簡単です。\nまた、必要とするサーバに特化したハードウェア構成が自由に選べるのもHackintoshのメリットです。\n大きなPCケースを選んで、大容量のHDDを多数搭載したサーバを作ることもできます。複数のHDDをRAID 1構成にして、HDD障害に敏速に対応する体制を作ることもできます。また、大容量のHDDを搭載して、TimeMachineサーバを作ることもできます。TimeMachine機能を使って、大容量HDDにサーバー自身のバックアップを作っておくことも簡単です。\nこのような重量級サーバが作れる一方で、NUCなどを使えば、低消費電力のサーバを作ることもできます。NUCはMacBook Airなどで搭載するモバイル用の低消費電力CPUを搭載しているにも関わらず、メモリやストレージなどは簡単に増設できます。家庭で24時間稼働させる小型の省電力サーバを作るのには最適かと思います。\n（NUC消費電力の例）\nmacOS Serverで何ができる ではmacOS Serverで何ができるかというと、実のところ多少微妙なところはあります。例えば、Linuxでサーバを作る方が、多彩なサーバを作ることができます。様々な構成を自作できるメリットはHackintoshと同じです。macOSも、土台がUNIXなので、様々なサーバ機能をLinuxと同じく手作業で設定することももちろん可能です。ただ、これらの設定は、OSのバージョンアップで動かなくなる可能性があります。また、運用しているユーザも少ないので、情報が得られにくいです。macOS Serverが提供している機能だけを素直に使用するのが簡単だと思います。\n一方、macOS Serverは、できることが限られていますが、サーバとしては比較的簡単に設定して、管理することができます。代表的な機能は、Webサーバ、VPNサーバ、メールサーバ、DHCPサーバ、DNSサーバ、カレンダ、メッセージ、連絡先などのサーバがあります。あまり使わないかもしれませんが、プロファイルマネージャサーバ、Netinstallサーバ、Xsanサーバがあります。VPNは、当然ですがmacOSクライアントと相性が良いので、設定が楽です。ちなみに、ファイルサーバ機能は、macOS通常版で提供されていて、macOS Serverには特に機能がありません。また、コンテンツキャッシュ（ソフトウェアアップデートやiCloudのキャッシュ）とTimeMachineサーバの機能は、High Sierra Server機能ではなくなり、High Sierra通常版で提供されるようになりました。コンテンツキャッシュはiCloudデータをキャッシュしてくれるので、自宅と職場で同期するなどの場合に、遅延の少ない確実な同期を期待できます。TimeMachineと共に、便利な機能なので、クライアントmacOSの機能に格上げされたのだと思います。\nmacOSが提供するサーバ機能の多くは、QNAPやSynologyなどのNAS製品を使えば、使いやすいインタフェースで構築可能です。でも、外部から接続できる常時稼働macOSマシンがあると、いろいろな場面で便利かと思います。\n","date":"2017-12-03T22:42:38+09:00","image":"/uploads/2017/10/20171007203625.png","permalink":"/posts/89/","title":"HackintoshでmacOS Serverを運用"},{"content":"ご案内：この記事は10.13.2および10.13.3を対象に書かれたものです。10.13.4では、Radeon搭載のThunderbolt 3接続外部GPUボックスが正式サポートされたことにより、ずっと簡単になりました。この記事の**「方法1」「方法2」「方法3」****「モデル名の修正」は不要**になりました。改訂版は以下です。(2018/4/3)\n/posts/62/\nRadeon RX 580を使ってみました。簡単で性能も良いです。\n/posts/139/\nHackintoshのためのグラフィックスカード選び方に関して上の記事で紹介しました。AMDのデスクトップ向けグラフィックスカードは、最近のmacOSのバージョン(10.12.6以降) で互換性が上がり、使いやすくなってきていました。また、最近のCloverではRadeonのイニシャライズに手を加える機能が搭載されて、パッチやkextを使用せずに使えるようになりました。RX 580の供給と価格も、マイニング騒ぎが収束してきたのか落ち着いてきたように思います。今回試したのは、SAPPHIRE NITRO+ RADEON RX 580です。Amazonでは他のブランドと比べてSapphireのRX 580 8Gが最安でした。SapphireはAppleが販売しているVR開発者用キットであるExternal Graphics Development Kit に搭載されているブランドなので、安心感があります。\nNVIDIAから乗り換え RADEONを動かす方法 方法1: 内蔵GPUをプライマリにする 方法2: WhateverGreen.kextを使う 方法3: CloverのRadeonDeInit機能を使う 動作を確認 モデル名の修正 おまけ：現行macOSがサポートするAMDグラフィックスカード NVIDIAから乗り換え 今まではNvidia Geforceを使っていました。大昔はAMDを使っていましたが、macOSとの互換性が悪くなって、最近は、ずっとNvidiaでした。ということで、NVIDIAが正常に動いているmacOS 10.13.1 からの引越しです。\nまずはNVIDIAのために入れていたWebドライバやkextやconfig.plistの設定を外します。/Library/Extensions/に導入されたWebドライバをアンインストールします。iMacのretinaディスプレイの回路を回避してブラックスクリーン発生を防いでくれる機能があるNvidiaGraphicsFixup.kextを入れていたのですが、これも外します。config.plistでNvidiaWebドライバを有効にしていたのですが、これもfalseにしました。\n\u0026lt;key\u0026gt;SystemParameters\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;NvidiaWeb\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; RADEONを動かす方法 ここでシステム終了して、NVIDIAのグラフィックスカードを外し、Radeon RX 580に差し替えます。でもこのまま起動しても画面は出ません。画面が出ないだけで、macOSは起動していますので、sshサーバや画面共有サーバをonにして、他のマシンからアクセスできるようにしておくと良いでしょう。\n画面が出ない問題は、Radeon RX 580がプライマリの状態では、グラフィックスカードのBIOSが初期化を正しく実行しないために引き起こされているようです。macOSが正しく初期化しようとするタイミングでは、すでに初期化が終了しているため、macOSによる初期化が実行されないらしいです。これを回避するために、いくつかの方法が知られています。\nRadeonカードをセカンダリで起動する。例えば内蔵GPUをプライマリにする。マルチスクリーン環境が前提。 kextやDSDTにパッチを当てて初期化をさせないようにする。 これに相当する作業をWhateverGreen.kextとLilu.kextの組み合わせで実施する。 CloverのRadeonDeInit機能で初期化を阻止する ここでは、以下のように、1番目、3番目、4番目の方法を紹介します。\n方法1: 内蔵GPUをプライマリにする 方法2: WhateverGreen.kextを使う 方法3: CloverのRadeonDeInit機能を使う 方法3がおすすめです。\n方法1: 内蔵GPUをプライマリにする 内蔵GPUをプライマリグラフィックスに、Radeon RX 580をセカンダリーグラフィックスに設定します。Radeonグラフィックスチップを搭載した実機や、Apple External Graphics Development Kitを接続した実機と同様の、一番実機に近い設定です。\nこれを行うためには、BIOS/UEFI設定で内蔵GPUをプライマリに設定します。\nこの設定をして、RX 580のみをディスプレイに接続すると、起動時のBIOS/UEFI画面やCloverの起動画面は表示されず、ディスプレイが真っ暗なままです。ただ、macOSのログイン画面まで来ると、ディスプレイに表示されます。\n起動画面が表示されないので、ある意味、本物のMacのような感じはしますが、BIOSやCloverの操作はできません。通常はこのまま使って、必要な時に、マザーボードのディスプレイ端子にディスプレイを接続するのも良いかと思います。マルチディスプレイ環境や、ディスプレイに複数入力端子があるなら、RX 580とマザーボードの両方に接続しておけば、設定変更も容易になります。\nBIOSの設定だけでRadeonが使えるようになりますが、ちょっと不自由な方法です。\n方法2: WhateverGreen.kextを使う WhateverGreen.kextはRadeonグラフィックスカードをプライマリグラフィックスとして使うためのパッチを当ててくれるkextです。Lilu.kextと一緒に使います。両方を/CLOVER/kextsのOtherもしくは該当するバージョンのフォルダに一緒に入れます。これだけでRadeon RX 580が使用できるようになります。\n/posts/118/\n方法3: CloverのRadeonDeInit機能を使う もう一つの方法は、Cloverが提供しているRadeonDeInitの機能を使う方法です。この機能は、Clover 4296あたりからサポートされたばかりの新機能で、kext不要です。今後もClover開発者によりメンテナンスされることを考えると安心です。Radeonカードをサポートする機能を作り込むあたりに、Clover開発者の人たちのRadeonへの愛が感じられなくもないです。\nこの機能を設定しないで起動してしまい、Radeonからの画面が出なくなってしまっても、Cloverの起動画面からClover Boot Optionsを選ぶことで対処できます。この中から、起動画面からGraphics Injectorを選びます。するとこの中に、DeInitという項目があります。これがRadeonの初期化を無効にするオプションです。これにチェックマークを入れます。\nこれだけの操作で、Radeon RX 580は無事起動します。\nconfig.plistにRadeonDeInitキーを追加して、これをにしておけば、次回の起動から、DeInitの項目を選択した状態になります。\n\u0026lt;key\u0026gt;Graphics\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ATI\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Intel\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;NVidia\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;RadeonDeInit\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; 動作を確認 上で説明した3つの方法を全部試して見ました。どれも問題なく動きましたので、一番シンプルなRadeonDeInitを使う方法で動かすことにしました。\n「システム情報」でチェックしてみると、正しく認識されているようです。Metalにも対応しています。Geekbench 4でのOpenCL Scoreは145000前後でした。他でも報告されている程度の妥当な成績なので、正しく設定できていると思います。\nなお、しばらく使用していると性能が低下して、ベンチマークスコアが50000くらいになってしまうことがありました。色々試して見たところ、Intel CPU内蔵GPUをマザーボードの設定で無効にしていると性能低下が発生するようです。内蔵GPUはセカンダリーに設定して使用しない場合でも、有効にしておくのが良いようです。\n一方、SafariでYoutubeなどの動画を再生すると、再生がカクカクして滞ったり、場合によってはハングすることが発生しました。Google Chromeでは問題が出ません。以前、Intel HD Graphicsを使って同様な不具合が発生した経験があり、その時は、IntelGraphicsFixup.kextとLilu.kextの組み合わせで解消しました。今回も、これで改善しました。ただし、IntelGraphicsFixup.kextとLilu.kextは最新版を使うのが良いです。古いバージョンだと改善しません。この不具合は、CPU内蔵GPUを無効にしても、同様に解決しますが、上記で述べたような性能低下が発生します。\nということで、正しく動作させるために\nIntel CPU内蔵GPUは有効にしておく IntelGraphicsFixup.kextを使う のが良いようです。\nモデル名の修正 「システム情報」や「このMacについて」を見て、ちょっとだけ気になるところがあります。モデル名が実際のカードと違うことです。例えば、RadeonDeInitを使った場合、AMD R9 xxxとなりました。他の方法の場合や、別のブランドのRX 580では別のモデル名になることもあるようです。AppleのExternal Graphics Development Kit に搭載されているのと同じSAPPHIRE PULSE RADEON RX 580を使えば、Radeon RX 580という表示になるという情報もあります。\nでも、これは見た目だけの問題で、気にしなければどうでも良いことのようです。どうしても直したかったら、担当しているドライバにパッチを当てます。以下でも紹介した手法でパッチを当てます。\n光学ドライブを使う\nAMD R9 xxxを担当しているドライバは、AMD9500Controller.kextで、/System/Library/Extensionsにあります。kextの本体は、/System/Library/Extensions/AMD9500Controller.kext/Contents/MacOS/AMD9500Controllerで、これをhexdump -Cすると確かにAMD R9 xxxという文字列が見つかります。これを望みの文字列に書き換えれば良いわけです。AMD R9 xxxという文字列は、Base64変換するとQU1EIFI5IHh4eA==です。これをAMD RX 580に書き換えたかったら、そのBase64に相当するQU1EIFJYIDU4MA==に書き換えるよう、config.plistのKextsToPatchセクションに書き込みます。例えば、以下のようになります。\n\u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Rename AMD R9 xxx\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;QU1EIFI5IHh4eA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AMD9500Controller\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;QU1EIFJYIDU4MA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; ちなみに文字列をBase64へ変換するには、ターミナルで次のようにすれば良いです。\n$ echo -n \u0026#34;AMD R9 xxx\u0026#34; | base64 QU1EIFI5IHh4eA== $ echo -n \u0026#34;AMD RX 580\u0026#34; | base64 QU1EIFJYIDU4MA== これでモデル名がそれっぽく表示されるようになりました。\nおまけ：現行macOSがサポートするAMDグラフィックスカード Sonnetが販売しているThunderbolt接続外付けGPUユニットのマニュアルによると、macOS 10.13.2でSonnetのユニットに内蔵できるグラフィックスカードは、Radeon RX 470, 480, 570, 580, Vega 56, Vega 64およびAMD WX9100だそうです。外付けGPUとして使えるということは、HackintoshのPCIeスロットに接続してセカンダリーGPUとして使えるということで、また、この記事で紹介したようにCloverの設定でプライマリGPUとして使えると思われます。\nSonnetの互換GPUリスト (10.13.2以降)\n","date":"2017-12-01T00:00:00+09:00","image":"/uploads/2018/08/20171118234329.png","permalink":"/posts/90/","title":"SAPPHIRE NITRO+ RADEON RX 580を使う (10.13.3以前)"},{"content":"macOSをインストールする方法をご紹介してきたのですが、多数の記事に分散してしまっています。そこで、macOS 10.13 High Sierraをインストールする際に参考になる記事へのポインタをまとめた総集編を作ってみました。10.14 Mojaveについては以下をご覧ください。\nHackintoshの作り方（総集編:10.14版）\n手順の概要を把握する こちらは9TO5MacのライターのJeffさんのビデオです。テンポよく紹介されていますので、全体の流れを確認するのに良いと思います。\n/posts/121/\nmacOSインストールのアプローチはたくさんありますが、一番おすすめなのは、Cloverを使ってバニラなインストールをすることだと思います。そのことを説明しています。\n/posts/131/\nハードウェアを用意する Hackintoshを作るためには、互換性のあるハードウェアを自由に選んで組み合わせられる自作PCが、問題が少なく楽です。ノートPCなども可能ではありますが、上級者向けだと思います。CPUは、今の最新Mac実機が採用しているKaby Lakeもしくは\nHackintoshのパーツ選び 【その1：CPU編】\n発売されたばかりの最新のCoffee Lakeが良いと思います。多少、チャレンジングですが、将来のことを考えたら最新Coffee Lakeで組んでおくのが良いと思います。\nCoffee Lake-SでmacOS\nそうすると、マザーボードは、CPUに合わせて200シリーズか300シリーズを選ぶことになります。\nHackintoshのパーツ選び 【その2：マザーボード編】\n/posts/97/\nグラフィックスカードはNVIDIAかAMDでしょうが、どちらも長短あります。少し前は、互換性、ドライバの提供、性能の点からNVIDIAがお勧めだったのですが、最近のmacOSではAMDの互換性が上がっています。詳しくは以下を参考にしてください。\nHACKINTOSHのパーツ選び 【その3：グラフィックス編】10.14以降版\n/posts/36/\n/posts/90/\n無線アダプタ、SSD, そのほかのパーツについても紹介しておきました。\n/posts/138/\nHackintoshのパーツ選び 【その5：SSD】\nHackintoshのパーツ選び 【その6：その他】\nマザーボードのBIOS/UEFIを設定する インストール先のコンピュータを組み上げたら、macOSが稼働するようにBIOS/UEFIを設定しておきます。この設定が間違っていると、それだけで起動しない場合もあります。\nマザーボード (BIOS) 設定\n必要なソフトウェアを入手する Hackintoshするには、macOS本体以外にオープンソースで有志が開発しているソフトウェアがいくつか必要です。必要なソフトウェアの名前で検索すれば、大抵の場合、ダウンロード先が見つかります。オープンソースのソフトウェアは、オリジナルを作った人の他に、いろいろな人がソースコードを引き継いで分岐（フォーク）して、開発を行なっている場合もあります。中には元祖の開発者が放置して、開発が止まっていることもあります。なので、検索して、現在一番活発に利用されているバージョンを使うのが良いです。ということで、古いハウツー情報のダウンロード先から入手するよりも、検索をして探すのがおすすめです。\nClover EFI bootloaderとefiドライバー “Clover EFI bootloader”で検索します。以下が本家かと思われます。\nhttps://sourceforge.net/projects/cloverefiboot/\nこちらでも最新版が配布されています。\ngithub.com\nCloverをダウンロードすると、インストーラ、efiドライバ、テーマファイルなども一緒に入手できます。\nkext類 FakeSMCをはじめとしたkext （カーネル拡張）が必要です。名前で検索します。例えば、FakeSMC.kextならば、”FakeSMC.kext”で検索すると、こちらで入手可能なことがわかります。\nRehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket\nMac上で導入用のUSBメモリを作る 次に、macOSを入手して、インストール用のUSBメモリを作ります。これは実際のMacで作業します。ついでに、実際のMacでこのUSBメモリが起動することを確認しておきましょう。次に、インストール対象のマシンで起動できるように、Cloverのインストールと設定も行っておきます。\n/posts/93/\nCloverインストールの手順はこちらにも書いてあります。\nCloverインストーラの設定\nconfig.plistの例を示して、説明しました。\nconfig.plistの実例紹介\nconfig.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。\n正しく機種設定する (SMBIOSの設定)\n対象マシンをUSBメモリで起動してmacOSを導入する このUSBメモリを、インストール先のマシンに挿して起動させます。起動しない場合は、Cloverの設定やkextの選定を確認します。\nUSB 3.0/3.1のUSBメモリを使った場合、Cloverの選択画面は現れるけど、そのあとのプロセスで失敗することがあります。macOSにはUSBの個数に制限があり、3.0/3.1のポートが2.0としてしか動かない場合があるからです。対応方法は以下の記事の「ポートを増やすパッチ」をご覧ください。\nUSBポートを設定する\nただ、USB 2.0でしたら確実に起動しますので、\nUSB 2.0のUSBメモリを使う マザーボードのUSB 2.0専用ポートを使用する（全部が3.0/3.1の最近のマザーボードではこの手法は使えないです） USB 2.0ハブを経由して無理やり2.0にする などで対応するのが簡単です。2.0なのでインストールに時間がかかる欠点はあります。\n無事起動したら、インストール先のSSD/HDDをGUIDパーティションとHFSジャーナリングでフォーマットします。次に、macOSインストーラを起動して、High Sierraをインストールします。インストール先ボリュームがSSDの場合は、ファイルシステムが自動的にAPFSに変更されるかもしれません。\nmacOSのインストール途中で、何度か再起動することがあります。その場合は、USBメモリから起動して、”Boot macOS Install from (インストール先のボリューム名)”という項目を選びます。\n対象マシンにCloverを導入する インストールが終了したら、またUSBメモリのESPから起動して、Cloverの選択画面でインストール先のmacOSを選択して起動します。この後、Cloverインストーラを起動して、インストール先にCloverを入れます。この手順は、先のUSBメモリにCloverを入れたのと同じ作業です。すでに動いているUSBメモリのESPをコピーしても良いです。SierraのHackintoshをHigh Sierraにアップデートする方法をこちらに書いておきましたので、ESPのコピーを行う方法の参考になるかと思います。\nHackintoshをHigh Sierraにする\nmacOS環境を整える USBに入れたCloverとkextで、最低限の起動は行えるようになっているはずです。さらに、グラフィックスカード、Ethernet, サウンドの設定をします。以下の記事が参考になるかと思います。\n/posts/90/\nEthernetを設定する\n/posts/120/\n","date":"2017-11-26T20:16:38+09:00","image":"/uploads/2017/11/20170911214228.png","permalink":"/posts/92/","title":"Hackintoshの作り方（総集編:10.13版）"},{"content":"このページは古いmacOS用の情報です。有用ではありますが、最新macOSに関する情報は以下をご覧ください。\nCatalina導入用USBメモリーを作成する\n今一番よく使われるHackintoshの作成方法は、以下のステップです。\nStep 1: Mac上でmacOSインストール用のUSBメモリーを作成する Step 2: USBメモリーにCloverをインストールする Step 3: USBメモリーで対象マシンを起動してmacOSをインストールする Step 4: 対象マシンにCloverをインストールする Step 1, 2は本物のMacintosh (以下、実機)で行います。一方、Step 3, 4はインストール先のマシンで行います。Step 2とStep 4では、USBメモリとインストール先マシンのそれぞれにCloverをインストールしています。\nよく紹介される手法では以下のような戦略でCloverをインストールしています。つまり、Step 2のUSBメモリへのインストールでは、できるだけ汎用性を持たせた設定にして幅広いマシンで起動できるようにします。一方、Step 4では、対象マシンに合わせたチューニングを施して性能を引き出します。\n例えば、Tonymacx86で配布されているUniBeastは、Step 1, 2を自動化するツールですが、緩いチューニングで多くのハードウェアでとりあえず起動させることを目指しています。そのあと、インストール対象マシン上でMultiBeastツールを動かして、細かいチューニングをする手順を採用しています。この過程で、起動しなくなることも多いです。インストール対象マシンで試行錯誤を繰り返す手法では、起動不能になった場合、USBインストーラのESPからmacOSを再起動し、インストール先のESPの修正を行い、修正したESPを用いて起動する作業を繰り返します。修正と再試行のために、合計2回、macOSを起動し直すには時間がかかります。またとりあえず起動できるだけのmacOSでは画面が低解像度だったりネットに接続できないなどの不便さもあります。\nそこで、Step 2の段階でインストール先マシンに合わせたチューニングを行うことを考えました。Step 2のインストールでチューニングを行えば、起動失敗したらUSBメモリーを実機に戻して修正すれば、再起動の手間は半減します。また、実機の整った環境で効率よく作業できます。ということで、Macintosh信者らしく実機を活用して、ある程度ちゃんとしたチューニングを目指したmacOSインストール用USBメモリーを作ってみます。\n(1) App StoreからHigh Sierraを購入する 無料です。ダウンロードするとインストーラが起動しますが、これは中断します。/Applicationsの中にmacOS High Sierraインストール.appというアプリケーションができているはずです。5GB以上のサイズです。\n(2) USBメモリを用意してフォーマットする USBメモリーを用意します。容量は最低で8GB必要です。でも8GBと表記されている製品でも、ギリギリ足りないこともあります。その上の16GBにしておけば確実です。さらに上の32GBくらいになると、インストーラじゃなくてmacOSそのものをインストールできます。ただしUSB 2.0の速度で起動すると、かなり時間がかかります。\nディスクユーティリティ.appを起動して、USBメモリを、GUIDパーティションマップで、Mac OS拡張（ジャーナリング）フォーマットで初期化します。名前は、後で自動的に改名されてしまうので、ここでは適当で構いません。ここではUSBとしました。\n(3) macOSインストーラをUSBメモリに入れる macOSをクリーンインストールするために、インストール用ドライブを作成する機能, createinstallmediaが用意されています。ターミナルから、以下のようにタイプします。\n$ sudo /Applications/Install\\ macOS\\ High\\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/USB これはUSBメモリがUSBという名前でマウントされている場合の例です。確認のプロンプトの後、しばらく時間がかかってインストール用USBメモリーが出来上がります。\n名前もInstall macOS High Sierraに変わっています。ここで作成したUSBメモリーは、実機で起動して、macOSのクリーンインストールに使用することができます。オプションキーを押しながら実機を起動して、このUSBメモリで正しく起動できることを試しておきましょう。ここまでの手順はAppleのサポートページでも紹介されています。\nmacOS の起動可能なインストーラを作成する方法\n(4) 必要なファイルを入手する Cloverとkextファイルを入手しておきます。いずれも、その名前を使って検索すると、ダウンロードサイトが見つかります。kextについては、こちらの記事を参考にしてください。\n/posts/126/\nClover EFI Bootloader macOSを起動するブートローダです。\nsourceforge.net\nFakeSMC.kext 必須のkextです。MacにはSystem Management Controllerというサブシステムがあり、これのふりをしてくれるのがFakeSMC.kextです。RehabManさんがメンテナンスしてくれているダウンロードサイトです。\nRehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket\nLilu.kext これを使ってパッチを当てるkextを使う場合に必要なkextです。以下で解説しておきました。ダウンロード先も以下をご覧ください。\n/posts/118/\nグラフィックスkext (Intel用) CPU内蔵のiGPU (Intel HD Graphics) を使う場合には、IntelGraphicsFixup.kextを使います。必須ではありませんが、いくつかの不具合を直してくれます。Lilu.kextが必要です。\nsourceforge.net\nグラフィックスkext (NVIDIA用) NVIDIAのGeforceを使う場合には、NvidiaGraphicsFixup.kextを使います。SMBIOSで設定する機種によってはこれがないとブラックスクリーンになってしまい、表示が出ません。Lilu.kextが必要です。\nsourceforge.net\nグラフィックスkext (AMD用) **追記：**10.13.4から、Appleの外部GPUボックス推奨のAMDグラフィックスカードを使う場合は、何もせずそのまま使えるようになりました。なので、以下に紹介したWhateverGreen.kextも不要です。(2018/4/12)\nAMDのRadeonを使う場合には、WhateverGreen.kextを使います。これを使わないとプライマリディスプレイにならず、ブラックスクリーンになります。Lilu.kextが必要です。\ngithub.com\nそのほかのkext 必須ではありませんが、LAN用のkext, オーディオ用のkext, USB設定のためのkextがあっても良いです。後から用意しても良いですが、LAN用は早い段階で欲しいかもしれません。\nEthernetを設定する\n/posts/120/\nUSBポートを設定する\n(5) Cloverをインストールする こちらに詳細に説明しておきました。\nCloverインストーラの設定\nこの手順でインストールを行います。選択する項目は以下です。\nインストールボタンを押せばインストールが終了します。\nインストールが終了した段階で、EFIという名前のボリュームがマウントされています。その中の、CLOVERフォルダに、先ほど指定したOsxAptioFix2Drv-64.efiなどが入っています。\nCloverインストール直後は、EFIがマウントされています。しかしEFIボリュームは通常はマウントされないので、手動でマウントする必要があります。こちらで説明しておきました。\nESPをマウントするためのシェルスクリプト\n(6) kextをUSBメモリに入れる 用意したkextをUSBメモリのESP (EFI System Partition) に入れます。CLOVERの中のkextsというフォルダに、バージョン番号のディレクトリがあります。使いたいmacOSのバージョンに合わせたフォルダに入れます。Otherフォルダに入れたkextは、いずれのバージョンでも使われます。通常は、数字の方か、Otherかのいずれかを使います。\nここでは、macOS High Sierra用に10.13フォルダにkextを入れてみました。AMDグラフィックス搭載マシンを想定してWhateverGreen.kextが入っています。\n(7) apfs.efiを入手してUSBメモリに入れる macOS High Sierraからシステムのファイルシステムが、従来のHFS+からAPFSに変更されました。インストール先がUSBメモリだったりHDDだとHFS+のままですが、SSDだと自動的にAPFSに変換されます。USBメモリ内のインストーラを起動するだけなら関係ないですが、SSDにインストールされたmacOSを起動する場合はAPFSにアクセスできる機能が必要になります。Clover、というか一般にブートローダは、OSが起動する前に、ドライブからブートのためのファイル（例えばカーネルなど）を読み込む必要があるからです。この機能は、High Sierraに入っているapfs.efi で行えます。\nまずはHigh Sierraインストーラの中にあるBaseSystem.dmgをマウントして、その中のusr/standalone/i386を開きます。\n$ open /Applications/Install\\ macOS\\ High\\ Sierra.app/Contents/SharedSupport/BaseSystem.dmg $ open /Volumes/OS\\ X\\ Base\\ System/usr/standalone/i386/ この中にapfs.efiがあるので、これをUSBメモリのCLOVERのdrivers64UEFIにコピーします。\n(8) config.plistを編集する ESPのCLOVERの中には、デフォルトで作成されたconfig.plistが入っています。これをconfig_def.plistのようにコピーしておきます。ちなみに、Cloverの起動画面で、configXXXX.plistのような名前のファイルから起動に使うファイルを選ぶことができます。config.plistについてはこちらで解説しておきました。\nconfig.plistの実例紹介\nデフォルトのconfig.plistはこんな感じになっています。\n[XML] Clover config.plist – Pastebin.com\n結構ややこしくて長ったらしいです。多くはコメントアウトされた記述です。XMLのコメントアウトは書きにくいのか、ここではkeyの名前に#をつけています。#をつけて、ありえない名前にすることで、無視されるようにしているようです。例えば、DisableDriversと書くべき以下の部分を、\nDisableDrivers CsmVideoDxe VBoxExt4 #DisableDriversと以下のように書くことで、\n#DisableDrivers CsmVideoDxe VBoxExt4 この部分をコメントアウトするのと同等の記述をしています。後からこの記述が必要になった時は、#を外せば良いのです。ただ、このようにコメントアウトされている箇所は、必要性の低い場所です。なのでほとんど削除することができます。\nまた、他にも必要性の低い場所があります。昔のマザーボードやハードウェアで必要とされていたものの、現在のマザーボードなどではほとんど不要であったり、むしろ不具合を引き起こしたりする記述が多くあります。それらを削除すると簡単になります。\n(9) SMBIOSを設定する デフォルトのconfig.plistでの機種設定は暫定的な設定です。実際には、インストール先のマシンに合わせて、しっかりと設定する必要があります。こちらに詳しい内容を説明しておきました。\n正しく機種設定する (SMBIOSの設定)\nこうして、コメントアウトされた部分を消して、不要な設定を消して、SMBIOSを設定した例を以下に示します。\n[XML] Customized config.plist – Pastebin.com\n(10) USBメモリで起動する このUSBメモリをインストール対象マザーボードにさして、UEFIで起動ドライブに設定して、起動させます。以下のようなCloverの画面が出てくるはずです。デフォルトはクリスマスになっていました。ここまでは、Cloverをインストールすれば問題なく行き着くはずです。\nなお、USBメモリが3.0である場合（多分、この容量のメモリはほとんど3.0じゃないでしょうか）USB 2.0のポートを使うと安全です。というのはUSBの個数制限で、macOSの起動後にUSB 3.0がアクセスできなくなり、止まってしまう可能性があるからです。2.0は遅いですが仕方ないです。生きている3.0もあるはずなので、ポートを抜き差しして、それを探しても良いです。USBの個数制限に関してはこちらの記事を見てください。\nDSDTを変更してUSBポートを選別する\n(11) macOSを対象マシンで起動することを確認する この後、macOSのインストーラの起動が始まります。macOSのインストーラ画面が出れば無事終了です。現実には、途中で止まってしまうことも多いかと思います。その場合は、ブートオプションに-vをつけてエラーメッセージをみてください。Couldn’t allocate runtime areaというエラーを出して停止している場合は、OsxAptioFix…を別のものに差し替えてみてください。ここで何度か試行錯誤の作業が必要になるかと思います。とても運が良ければ、一回で起動できるかもしれません。\nこの先は、通常の実機でのmacOSクリーンインストールと同じ手順です。すなわち、インストール先のドライブをディスクユーティリティでフォーマットし、macOSをインストールします。何度か再起動することがありますが、その場合は、Cloverのブートドライブ選択画面でBoot macOS Install from…という項目を選びます。\nmacOSのインストールが終了したら、一旦はUSBメモリで起動して、起動項目でインストールしたばかりのmacOSドライブを選択します。そしてCloverをインストールし、USBメモリのESPの内容を、新しいmacOSドライブのESPにそのままコピーすれば、Hackintoshが完成です。\n","date":"2017-11-24T14:10:36+09:00","image":"/uploads/2017/11/20171121154649.png","permalink":"/posts/93/","title":"High Sierra導入用USBメモリ作成方法"},{"content":"Next Unit of Computing (NUC)はIntelが提唱する小型ファームファクタのコンピュータです。10.16 × 10.16 cmのサイズの基板に、モバイル向けCPUが搭載されたマザーボード製品やベアボーン製品として販売されています。今のIntelのモバイル向けCPUはソケットではなく半田付けするタイプなので、自作したい場合にはNUCのようにマザーボードとセットになった製品しか選択肢がありません。Intelのモバイル向けCPUは、MacBookシリーズ、Mac mini、さらには一部のiMacで使われているので、Hackintoshする上での互換性は高いです。\nNUCでmacOSすると良い事・悪い事 良い事 MacBook Air, MacBook Pro に相当する拡張が容易な小型デスクトップを作れます。 拡張困難で新製品がなかなか出ないMac miniより小さいです。 小型なのでMod PCに適しています。大福型iMac, G4 Cube, G4 CubeのACアダプタ、古いMac miniなどに組み込んでmacOSマシンにしている例もあります。 CPUは非力ですが、意外とキビキビ動きます。インテルのモバイル用CPU内蔵GPUがデスクトップ向けCPUより高性能だからだと思います。 モバイルバッテリーをつければ、モバイルなmacOSマシンも可能です。こんなモバイルバッテリーが使えるそうです。基板バージョンのNUCを使って、人体にフィットする薄型筐体を3Dプリンタで作れば、ウェアラブルなmacOSも可能だと思います。 悪い事 コストのメリットは少ないです。Mac miniのエントリーモデルは十分安いので、同じものをNUCで作る場合とほとんど価格は変わりません。本物のMacならばmacOSが将来にわたって確実に動くことを考えると、NUCをすることの価格的なメリットはありません。ただ、メモリやSSDを拡張すると差額は広がりNUCがお得になります。 Broadwell世代からWiFi用のmini PCIe / m.2ソケットが廃止され、WiFiが使えません。USBのWiFiは不安定で実用的ではないらしいです。Ethernet だけで使用するしかありません。 WiFiが無いと、iOSやwatchOSとの連携機能が使えないので、クライアント使用でも、割り切らないと辛いです。サーバ用途なら良いかもです。 macOSとの互換性 Core iシリーズを搭載したNUCの一覧を下の表に示します。\n互換 型番 バリエーション CPU iGPU ? NUC7i5 DNKE, DNHE, DNBE i5-7300U Intel HD Graphics 620 (0x5916) ? NUC7i3 DNKE, DNHE, DNBE i3-7100U Intel HD Graphics 620 (0x5916) CPU NUC7i7 bnh, BNHX1, BNHXG i7-7567U Intel Iris Plus Graphics 650 (0x5927) iGPU NUC7i5 bnk, bnh, BNHX1, BNHXF i5-7260U Intel Iris Plus Graphics 640 (0x5926) ○ NUC7i3 bnk, bnh, BNHX1, BNHXF i3-7100U Intel HD Graphics 620 (0x5916) ○ NUC6i7 kyk i7-6770HQ Intel Iris Pro Graphics 580 (0x193B) iGPU NUC6i5 syk, syh i5-6260U Intel Iris Graphics 540 (0x1926) ○ NUC6i3 syk, syh i3-6100U Intel HD Graphics 520 (0x1916) CPU NUC5i7 ryh i7-5557U Intel Iris Graphics 6100 (0x162B) CPU NUC5i5 ryh, ryk i5-5250U Intel HD Graphics 6000 (0x1626) ○ NUC5i3 ryh, ryk i3-5010U Intel HD Graphics 5500 (0x1616) ○ NUC5i5 MYHE, MYBE i5-5300U Intel HD Graphics 5500 (0x1616) ○ NUC5i3 MYHE, MYBE i3-5010U Intel HD Graphics 5500 (0x1616) CPU D54250 WYK, WYKH, WYB i5-4250U Intel HD Graphics 5000 (0xA26) × D34010 WYK, WYKH, WYB i3-4010U Intel HD Graphics 4400 (0xA16) CPU DC53427 HYE, RKE i5-3427U Intel HD Graphics 4000 (0x166) iGPU DC3217 IYE, IYR, BY, GKE, CK i3-3217U Intel HD Graphics 4000 (0x166) この表の互換の項目は以下の意味です。\nCPU: 同じCPUが実機で使われているので互換性が高いです iGPU: 同じiGPUを搭載したCPUが実機で使われているので互換性があります ○: CPUもiGPUも実機で使われていませんが動作報告があります ?: 動作報告がありません ×: 動作しないとの報告があります 動作報告のある代表的なサイトを以下に示しておきます。\nDC3217 www.tonymacx86.com\nD54250 www.tonymacx86.com\n5i7, 5i5, 5i3 www.tonymacx86.com\n6i7, 6i5, 6i3 www.reddit.com\n7i7, 7i5, 7i3 www.tonymacx86.com\nおすすめのNUC 世代順に、Hackintoshに適したNUCを紹介しておきます。mini PCIeソケットのある機種なら、WiFiには、互換性のあるBroadcom BCM94322HM8L DW 1510などを使うと良いです。Bluetoothは、互換性があり入手容易なI-O DATA USB-BT40LEなどを使うと良いです。\n一方で、最近の製品は、WiFiが半田付けになってしまったので、あまり魅力はないです。WiFiを使わないサーバくらいなら使えるかもです。昔の製品が格安に入手できる機会があったら試してみるのが良いかと思います。\nDC3217IYE 最初に販売されたCore i搭載のNUCです。Ivy Bridge i3 3217Uを搭載しています。i3を搭載したMacintoshはありませんが、Intel HD Graphics 4000はMacmini6,2, MacBookAir5,1, MacBookAir5,2などで使われていて、動作します。DC3217IYEやこれのボードタイプがおすすめです。Ethernetの代わりにThunderboltのついたDC3217BYもありますが、HackintoshではThunderboltのホットプラグが効かず、不安定です。\nDC53427HYE DC3217の少し後に出た、同世代のIvy Bridge i5を使ったNUCです。この機種からUSB 3.0が搭載されました。搭載CPUはMacBookAir5,2で使用されています。\nD54250WYK, D54250WYKH Haswell i5 4250Uを搭載しています。MacBookAir6,1とMacBookAir6,2で使用されているCPUです。WYKは従来のコンパクトサイズの筐体で、WYKHはケースを大きくして2.5インチドライブを内蔵できるようにしたモデルです。一時期ドスパラで税込3万円未満で売られていました。\n5i3MYHE, 5i5MYHE Broadwell以降のNUCでは、大半のモデルでWiFi/Bluetooth無線ユニットがあらかじめ半田付けされるようになってしまいました。インテルチップ搭載の無線ユニットはHackintoshでは使えないので、WiFiとBluetoothを使いたかったらどちらもUSBで拡張する必要があります。しかしUSB WiFiは不安定で実用的では無いという評判です。Ethernetは使えますが、最近のmacOSではiOS / watchOSとの連携にWiFiが必要です。\nその中でも、5i3MYHE, 5i5MYHEは、従来通り、mini PCIeのソケットがあって、ユーザが無線ユニットを差して使うモデルです。ただし、実機で採用されていないCPU/GPUを使っています。(それでも使用できるようです)\n","date":"2017-11-16T09:37:41+09:00","image":"/uploads/2017/11/20171116093346.png","permalink":"/posts/95/","title":"NUCで作る超小型macOSマシン"},{"content":"Cloverの起動画面には、起動選択項目がアイコンで並んでいます。この項目に、選んでも何もおきない項目が現れることがあります。その理由と、不要な起動項目を消す方法を書いておきます。\nBoot macOS Install from xxxの項目を消す macOSのインストールの過程でこの項目が出るようになります。\n正常にインストールが終了するとこの項目は自動的に消えるのですが、何かの手違いがあると残ってしまいます。インストール途中だと判断されてこれがデフォルトで選択されてしまうこともあります。また、次に上書きインストールをすると、これが多数現れることになり、どれが本物か分からなくなります。 ターミナルから以下のようにタイプすると消えます。\nsudo rm -R /Volumes/xxx/.IABootFiles .IABootFilesは.で始まる隠しディレクトリなので、ls -aじゃないと見つかりません。このディレクトリの中のcom.apple.Boot.plistを見るとインストールのために使用するInstallESD.dmgとかBaseSystem.dmgへのパスが書いてあります。大昔にインストールした名残だとすると、その場所にはもう無いので当然のことながら起動に失敗します。\nBoot macOS install from xxx – Dataの項目を消す Catalinaからメインの起動ボリュームが2個の論理ボリュームに分割されて、xxx – Dataというボリュームが追加されました。xxxはMacintosh HDのような起動ボリューム名です。- Dataの方には、変更できる内容が入り、従来の- Dataが付かない方には書き換えては困るシステムのデータが入っています。\nこの方式では、インストール用のデータはxxx – Dataの方にはいるようで、インストールに失敗するとBoot macOS install from xxx – Dataという項目が居残ってしまいます。これの消去方法をコメントでSuperBypassさんから教えていただきましたので以下に追記しておきます。つまり、/System/Volumes/Dataの中にmacOS Install Dataというディレクトリがあるので、これを消去すれば良いようです。こちらが参考になるそうです。\nただ、この中にあるLocked FilesというディレクトリがSIPでアクセス禁止されていますので、SIPを解除して、sudoで/System/Volumes/Data/macOS Install Dataを消去します。\nxxx from Prebootの項目を消す こちらは単なる見た目の問題です。\nAPFSになってから、Recoveryに加えて、Prebootというパーティションが起動項目に新たに加わって煩雑になりました。下の例は、メインのSSDに加えて、バックアップ用のHDDを接続したマシンのClover起動画面です。SSDにはAPFSフォーマットでMacintosh SSDというパーティションが作ってあり、High Sierraがインストールされています。メインのSSDに関係する起動選択肢は右の4個です。\n4個の起動項目には、以下の名前が付いています。\nBoot FileVault Prebooter from Preboot Boot macOS Installer Prebooter from Preboot Boot macOS from Macintosh SSD Boot Recovery from Recovery APFSになってから、Recoveryに加えて、Prebootという選択肢が起動項目に新たに加わって煩雑になりました。\n追記：最近、FileVault関係の起動メニューは現れていません。CloverのFileVault関連のEFIドライバを入れないことにしているのが関係しているかもしれません（2018/12/15)\ndiskutil listコマンドでこのSSDを見ると次のようになっています。\n/dev/disk1 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +500.0 GB disk1 Physical Store disk0s2 1: APFS Volume Macintosh SSD 331.6 GB disk1s1 2: APFS Volume Preboot 46.0 MB disk1s2 3: APFS Volume Recovery 517.0 MB disk1s3 4: APFS Volume VM 20.5 KB disk1s4 PrebootというAPFSボリュームができているようです。APFSボリュームは、物理的なボリュームではなく、APFSコンテナの中に作られた仮想的なボリュームで、それぞれが記憶領域を共有していて追加・削除が簡単です。\nAPFSのVolumeを活用する\nPrebootというAPFSボリュームは起動時の作業に使用するボリュームのようです。Prebootの名前のついた起動メニューを選択して起動しても、結局は本体のシステムが起動するようです。選択肢に表示される意味がないので、非表示にしてみましょう。\n使わない起動選択肢を非表示にして、起動画面をスッキリさせることは、config.plistの記述で簡単に行えます。config.plistのGUIセクションに、Hideというキーを用意して、\n\u0026lt;key\u0026gt;GUI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Hide\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;string\u0026gt;Preboot\u0026lt;/string\u0026gt; \u0026lt;/array\u0026gt; とすれば、Prebootボリュームに含まれる起動オプションは表示されなくなります。（1項目だけなのでarrayにする必要はないかもしれませんが、サンプルがarrayでしたし、将来増やしたいときのためにarrayにしておきました。) 結果がこれです。\n必要な選択肢だけが表示されるようになりました。他にも表示から外したい選択肢があったらconfig.plistのHideの項にで挟んで追記していけば良いです。Hideの項で消してしまった項目を選択したくなった場合は、Clover選択画面でF3キーを押します。隠されたボリュームも表示されるようになります。\n更新：Prebootボリュームを削除する手法を削除しました。(2018/12/15)\n","date":"2017-11-10T13:33:52+09:00","image":"/uploads/2017/09/20170911214228.png","permalink":"/posts/96/","title":"Clover画面から不要項目を除外"},{"content":"\n2017年11月2日にインテルのメインストリーム向け新デスクトップCPUであるCoffee Lake-Sが発売されました。これを搭載したMacintoshはまだありませんが、CPU IDをKaby Lakeに偽装することで6コア12スレッドを堪能できるようです。\nCoffee Lake-SでmacOS\n同時に各社から対応マザーボードも発売されました。まだZ370チップセットだけで、数も少ないようですがこれから増えていくと思われます。\n主要マザーボードメーカといえば、シェア一番のASUS、Hackintoshで昔から人気のGigabyte、コスパが良いASRockがありますが、以前の記事では、\n電源ボタン長押しでBIOSに入れるGO2BIOS機能がある ファン制御をBIOSのGUIで設定できる（ASUSも可能） BIOSメニュー構成がわかりやすい（主観です） という弱い理由でMSIを推しました。\nHackintoshのパーツ選び 【その2：マザーボード編】\nここでもMSIに絞って新製品を見ていこうと思います。でも、実際のところ、UEFIマザーボードならmacOSを導入する上で大した違いはありませんので、どのメーカの製品でも良いです。\nMSIからは9機種 ニュース記事によるとMSIからはZ370チップセット製品が9機種発売されるようです。\n個人的にはArcticシリーズの白い基板が無いのが残念です。今後の製品展開に期待したいです。一般的な仕様はこれらの記事を見ていただくことにして、macOSをインストールする場合にきになるところをチェックして見ます。\n共通の項目 どのマザーボードもUSB 3.1 Gen2にASMediaの新しいチップ、ASM3142を搭載しています。ASRock, Gigabyte, ASUSも同じく、ASM3142を搭載しています。ASM3142がmacOSで使用できるのかどうかは不明です。チップセット直結のUSB 3.1 Gen1は使えるはずです。\nWiFi搭載モデルのWiFiモジュールはIntel製もしくはQualcomm製です。どちらもmacOSではサポートされていませんので、動かないと考えて良いです。\nオーディオのRealtek ALC 892は以前からあるチップで、安定して動きます。上位機種に搭載されているALC 1220は200シリーズチップセットから搭載された新しいチップで、最近になって動くようになったようです。どのマザーボードも動くと考えられます。\nLANにはQualcommのKiller E2500もしくはIntel I219-Vが採用されています。E2500はAtherosE2200Ethernet.kextでサポートされているようです。I219-VはIntelMausiEthernet.kextでサポートされているようです。なので、どのマザーボードも動くと考えられます。\nZ370 GODLIKE GAMING E-ATX規格。店頭予想価格は税別68,980円。WiFi搭載、有線LANは3個搭載です。オンボードグラフィックス機能は非搭載です。macOSではWiFiは動きません。WiFiモジュールはM.2接続なので、Broadcomの同じ規格のモジュールに差し替えることで動くかもしれませんが、アンテナの数がたりませんし、基板のサイズが合うかどうかは不明です。オーディオはALC1220およびESS E9018となっています。前者は動きます。後者のESS E9018は高級なDACらしく、大型のヘッドホンジャックに接続しています。SPDIF入力を持ったチップらしいので、ALC1220に接続しているようなら使えるのかもしれません。Killer E2500のLANは動きます。\nZ370 GAMING M5 ATX規格。店頭予想価格は税別27,680円。オーディオはRealtek ALC1220、有線LANはKiller E2500で、どちらもmacOSで動くでしょう。\nZ370 GAMING PRO CARBON AC ATX規格。店頭予想価格は税別27,480円。IntelのPCIe無線LAN拡張カードが付属しますがmacOSでは動きません。オーディオはRealtek ALC1220、有線LANはIntel I219-Vで、どちらもmacOSで動くでしょう。\nZ370 GAMING PRO CARBON ATX規格。店頭予想価格は税別24,680円。Z370 Gaming Pro Carbon ACからWiFiカードを外したバージョン。macOSで動かないWiFiカードが付属していても無駄なので、どちらかを買うならこちらですね。オーディオはRealtek ALC1220、有線LANはIntel I219-Vで、どちらもmacOSで動くでしょう。\nZ370M GAMING PRO AC micro-ATX規格。店頭予想価格は税別21,980円。IntelのM.2接続WiFiが付いていますが、これは動きません。オーディオはRealtek ALC1220、有線LANはIntel I219-Vで、どちらもmacOSで動くでしょう。\nZ370I GAMING PRO CARBON AC mini-ITX規格。店頭予想価格は税別22,980円。IntelのM.2接続WiFiが付いていますが、これは動きません。オーディオはRealtek ALC1220、有線LANはIntel I219-Vで、どちらもmacOSで動くでしょう。\nZ370 TOMAHAWK ATX規格。店頭予想価格は税別18,680円。オーディオはRealtek ALC892、有線LANはIntel I219-Vで、どちらもmacOSで動くでしょう。\nZ370 GAMING PLUS ATX規格。店頭予想価格は税別14,480円。オーディオはRealtek ALC892、有線LANはIntel I219-Vで、どちらもmacOSで動くでしょう。\nZ370 PC PRO ATX規格。店頭予想価格は税別15,580円。PCIスロットが付いています。オーディオはRealtek ALC887、有線LANはIntel I219-Vで、どちらもmacOSで動くでしょう。\nHackintosh向きの製品は？ 最上位のZ370 GODLIKE GAMINGはWiFiが無駄になるし搭載の高級DACが使えるかどうか不明ですので無謀かもしれないです。またZ370 GAMING PRO CARBON ACは、WiFiなしバージョンを買うのが良いので、除外です。\nmicro-ATXとmini-ITXは、それぞれ1機種しかありません。M.2接続WiFiカードは無駄になりますが、このフォームファクタが必要なら選択の余地はありません。WiFi用M.2ソケットは、BroadcomのM.2カード、もしくはM.2カードアダプタと差し替えて有効利用できるかもしれません。GigabyteとASRockからはWiFi未搭載のmicro-ATXが出ていますので、それ（Z370M D3HまたはZ370M Pro4）にしても良いかもしれません。\nということで、今のMSIのラインナップからすると以下が良いようです。\nZ370 GAMING M5 (地味に光る) Z370 GAMING PRO CARBON (派手に光る) Z370 TOMAHAWK (ミリタリー風) Z370 GAMING PLUS (エントリーモデル. 赤く光る) Z370 PC PRO (ビジネスモデル・PCIソケット) Z370M GAMING PRO AC (micro-ATX. 赤く光る) Z370I GAMING PRO CARBON AC (mini-ITX. 虹色に光る) ","date":"2017-11-03T16:39:19+09:00","image":"/uploads/2017/11/20171103232714.png","permalink":"/posts/97/","title":"Z370マザーボード"},{"content":"MacintoshのCPUには電力管理(パワーマネージメント)の機構が搭載されていて、CPUの負荷が下がるとクロック周波数を下げて、消費電力を削減します。Intel Power Gadgetでその様子を確認できます。大抵のマシンでは、特段の設定をしなくても、クロック周波数が変動して電力管理が実施されます。\nIntel Power Gadget\n以下は、初代Intel NUCのDC3217IYEでの例です。CPUはIvyBridgeのCore i3モデル、3217Uです。真ん中のグラフがクロック周波数です。電力管理がされていないために、クロック周波数が定格近くの1.7GHzに張り付いて一定になっています。車に例えたらアクセル踏みっぱなしのフルスロットルで運転しているような状態です。\nデスクトップ向けのCPUで自作すると、特別な処置をしなくても大抵は正しく電力管理されていて、クロック周波数のグラフは負荷に応じて変動することが多いです。実機ではこのCPUシリーズのi5モデルである3317UがMacBookAir5,1で採用されてますが、i3 3217Uを採用した機種はありません。その関係でCPU情報がOSに登録されてなく、電力管理が効いていないと思われます。\nそんな時はPikeさんが作ってくれたスクリプトを動かしてSSDT.amlファイルを作ると改善することがあります。\nGitHub - Piker-Alpha/ssdtPRGen.sh: Script to generate a SSDT for Power Manage\u0026hellip;\nまずは、ここからssdtPRGen.shというスクリプトをダウンロードします。そしてこれをターミナルで実行します。すると、~/Library/ssdtPRGen/にSSDT.amlができています。 これをEFI/CLOVER/ACPI/patched に入れて再起動します。\nDSDTについてはこちらで説明しましたが、\nDSDTを編集する\nSSDTはDSDTの補足ファイル、サブセットのような位置付けです。DSDTの一部を補足したり、書き換えたりする内容のようです。Pikeさんのスクリプトは、使用しているCPUに合わせて、電力管理に関する記述を作ってくれます。\nこの結果、Power Gadgetの様子は、以下のようになりました。\n真ん中のグラフが示すように、CPUのクロック周波数が、負荷により変化して、省電力を実現しています。電力消費のグラフは一番上です。3.9WだったCPU消費電力が2.8Wに下がっています。クロック周波数が減少しているので、その分、省電力が達成できています。一番下のグラフに表示されている温度も、7度近く下がりました。\n","date":"2017-11-01T14:02:02+09:00","image":"/uploads/2017/11/20171027213047.png","permalink":"/posts/99/","title":"パワーマネジメントを設定する"},{"content":"新しいCPUが2017年11月2日発売 インテルのメインストリーム向け新デスクトップCPU、Coffee Lake-Sシリーズの国内販売が決まったようです。以下の6種類が11月2日に発売されます。\nProducts Cores Threads Base Clock Turbo Boost TDP Core i7-8700K 6 12 3.7GHz 4.7GHz 95W Core i7-8700 6 12 3.2GHz 4.6GHz 65W Core i5-8600K 6 6 3.6GHz 4.3GHz 95W Core i5-8400 6 6 2.8GHz 4GHz 65W Core i3-8350K 4 4 4GHz N/A 91W Core i3-8100 4 4 3.6GHz N/A 65W 今までの経緯から、これらが次期iMacで採用されると予想されます。今回注目されていることは、コア数が増えたことです。今までずっと、\nCore i7は4コア8スレッド、 Core i5は4コア4スレッド、 Core i3は2コア4スレッド の構成が踏襲されてきましたが、今回は、\nCore i7は6コア12スレッド、 Core i5は6コア6スレッド、 Core i3は4コア4スレッド となり、久々のコア数増強です。AMDの新CPUがコア数重視なことに対抗しての結果と思われます。Kaby Lakeの時と売り出し価格は同程度なので、コア数増えたことでお得感があります。今回発売されるi7, i5, i3のそれぞれに、オーバークロック対応のKモデルと、無印のモデルがあります。K付きモデルはこの他に、無印と比べてクロックがより高い、TDPが高いという特徴があります。\nCPU搭載iGPUは、今までのKaby LakeがIntel HD Graphics 630だったのに対して、Intel UHD Graphics 630になりました。しかし、多少クロックが上がったくらいで、内部的な設計やEU数はKaby Lake-S世代と何ら変わっていないそうです。iGPUに関しては、Kaby Lakeと同様の互換性で、macOSのスリープ復帰に多少問題が出るかと思います。\n新CPUに対するHackintosh対応 過去の例を見ると、CPUが新しくなった時に、どれくらいHackintosh対応できるかどうかは、様々でした。\nHaswell/BroadwellからSkylakeに移行した時は、コミュニティの皆さんが割と手こずっていた感じでした。最初はカーネルパニック連発で、なかなか起動せず、iMacがSkylakeを搭載した後も、しばらく不安定でした。安定したのは、MacBook系での採用が進んで、OSが十分に対応してからでした。CPUが発売されてから半年くらい時間がかかったと思います。\n一方で、SkylakeからKaby Lakeの移行は、スムーズでした。 CPU IDとiGPU IDを古いSkylakeに偽装するだけでKaby Lakeは問題なく動き、Kaby Lake搭載iMacが出たタイミングのmacOS 10.12.6 で、偽装も不要になりました。\n今回のKaby LakeからCoffee Lakeへの移行は、さらにマイナーチェンジだと言われています。CPUピンの割り当てが1本変更されたので、マザーボードの互換性は皆無ですが、チップセットはほとんど同じと言われています。iGPUにも違いはほとんどありません。\nCoffee Lake-SでmacOS 実際に動作したという報告が、多数上がっています。Geekbenchにもベンチマークが上がっています。増えた全コア・スレッドがちゃんと認識されるようです。コア数が増えたので、Kaby Lakeに比べてマルチコアのスコアが目に見えて上昇しています。\nmacOS 10.13 | i7-8700K ASUS Strix Z370-F RX 580 : hackintosh HS on 8700K, Coffee Lake – OSx86 10.13 (macOS High Sierra) – InsanelyMac Forum Apple 8700K – Geekbench Search – Geekbench Browser Coffee Lake-Sを使う方法は簡単で、FakeCPUIDで 0x0906E9 にして、Kaby Lakeに偽装するだけで可能とのことです。Clover Configurator.appを使うならKernel and Kext PatchesのFakeCPUIDに0x0906E9を書き込みます。\nconfig.plistを手作業で書き換えるなら、\n\u0026lt;key\u0026gt;KernelAndKextPatches\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;FakeCPUID\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x0906E9\u0026lt;/string\u0026gt; のようにKernelAndKextPachesのセクションにFakeCPUIDを書き込みます。iGPUはKaby Lakeと比べて大きな違いがないので、偽装する必要はないようです。\n追記：FakeCPUIDをしなくてもHigh Sierraで動くようです。ただ、不明のCPUという表示になるようです。http://www.insanelymac.com/forum/topic/328819-hs-on-8700k-coffee-lake/\n追記：MojaveになってCPU名も不明にはならなくなったようです。\nCore i3ではiGPUが動かない？ こちらの報告によると、\nwww.tonymacx86.com\ni3-8100ではIntel UHD Graphics 630が動かないそうです。i3-8100のiGPUのDevice IDは3E91で、i5-8400, i7-8700Kなどは3E92で、3E92のUHD 630じゃないとグラフィックス加速が効かないとのことです。iGPUを使う場合はi5以上を選ぶべきかもしれません。\n新規に自作するならCoffee Lake-S Kaby Lakeの時と同じく、iMacにCoffee Lakeが搭載されてmacOSが対応したら、FakeCPUIDを偽装する記述は不要になるはずです。ということで今現在、新規にHackintoshを組むならCoffee Lake-Sで作った方が良いと思われます。本物のMacintoshで未採用の最新6コアCPUを使えるというのはHackintoshの醍醐味ではないでしょうか。\n","date":"2017-10-28T14:57:59+09:00","image":"/uploads/2017/10/20171029113120.png","permalink":"/posts/100/","title":"Coffee Lake-SでmacOS"},{"content":"メーカ製のデスクトップを買うよりも自作をした方が、カスタマイズが自由で、良い部品を選べて、満足なコンピュータが手に入ると思っています。なので、メーカ製デスクトップPCには実のところあまり興味がないです。でも古いモデルが、格安で売られていたり、廃棄されていたりしたら、macOSを入れてみたくなると思います。\n追記：フォーラムで教えていただきましたが、こちらの記事の方が新しくて、MultiBeastを使わない方法でオススメです。\nということで、tonymacx86に最近出ていた記事を読んでみることにしました。こちらです。\nこの記事では、HPのデスクトップPCであるHP 6300 ProとHP 8300 Eliteを対象にしています。Ivy Bridge時代の製品のようです。Amazonで調べたら、安いところでは1万円台で中古販売されているようです。\nこちらのビデオでも、公共機関払い下げ品のHP 6300 Core i5モデルを$30で入手してmacOS Sierraをインストールしています。後述のように一部のモデルのiGPUはmacOSでサポートされていません。そこでGTX 750Tiを中古で買い、さらに中古HDD, 壊れたと勘違いされたSSDを追加購入して、合計で$70だそうです。\nwww.youtube.com\nということで、以下は、上のmacosx96の記事の抄訳です。\nStep 1. ハードウェア構成をチェック 入手してWindowsがインストールされていたら、とりあえず起動して、間違いなく動くWindowsの元で、ハードウェアに不具合がないか確認します。CPUのグリスを塗り替えるのも良いでしょう。グラフィックスカードを取り付ける予定なら、ここで装着してテストしておくのも良いです。Intel HD4000を搭載したCPUが載っているなら、オンボードの映像出力（VGAを除く）が使えます。Intel HD2500はmacOS Sierraでサポートがありませんので、i3-3220やi5-3470などのHD2500搭載CPUの場合は、グラフィックスカードが必須です。\n訳注：Wikipedia (Intel HD Graphics – Wikipedia)によるとHD2500とHD4000を搭載したデスクトップむけCPUは以下です。\n**HD2500 (macOS非対応):**Core i3-32×0(T), Core i5-3xx0(S/T) **HD4000 (対応):**Core i3-32×5, Core i5-3475S, Core i7-3770(S/T), Core ix-3x70K macOSをインストールする高速なSSDはSATA 0に接続すると良いです。白いコネクタは3GbpsのSATA2規格なので低速なHDD向きです。もしSSDを2台使ってWindows/macOSのデュアルブートしたかったら、SATA3を2個持っているHP 8300 Eliteを買うと良いです。\nStep 2. BIOSをアップデートする F10キーを押しながら起動してBIOSメニューに入り、BIOSバージョンを確認します。v02.83だったらv02.99 Rev. Aにアップデートします。この後、最新の03.04にアップデートしても良いけど必須ではないです。BIOSアップデートにはWindows上のツールか、BIOSメニューにあるツールを使います。\nStep 3. BIOSを工場出荷状態にしてから設定する F10でBIOSに入って時刻、日付、場所が正しく設定されていることを確認します 工場出荷時設定にします（30秒くらいかかる） 電源ボタン長押しでシャットダウンします 電源ボタンを押してF10を押してBIOSに入ります シリアルポートとパラレルポートの設定をdisabledにします NvidiaのGPUでUEFI起動可能なもの（GT 710, GTX 1050, 1050Tiなど）の場合は、シングルモニターで設定します。複数モニター起動は問題を起こすかもしれません。 Save Changes and Exitを選んでBIOS設定を保存します Step 4. SierraをApp Storeから入手する 訳注：今ならHigh Sierraですね。\nStep 5. USBメモリー上にUnibeastインストーラを作る 訳注：createinstallmediaコマンドとCloverで作っても良いと思います。ここからの3ステップは、いつもの手順です。こちらもご覧ください。\n/posts/121/\nStep 6. USBメモリから起動してmacOSをインストール Step 7. MultiBeastの設定 Step 8. config.plistを編集する Clover Configuratorを使います。\nDSDTパッチで、EHC1 を EH01 に、また、EHC2 を EH02に変更します HD4000を使う場合はInject Intelをします SIPを0x67にします（訳注：バニラなインストールするなら不要です） Nvidia Web Driverを使うならNvidiaWebをtrueにします CPUパワーマネジメントを設定しても良いです。CPUに応じたssdt.amlを使います。\nStep 9. HDMIオーディオとアナログオーディオを有効にする GT 710、1030、GTX 1050、1050 Tiなどを使っているなら、VoodooHDA 2.9.0 kextとAppleHDADisabler kextを使うとよいです。CPU内蔵のHD4000グラフィックスを使う場合も同様です。（訳注：/L/Eに入れろと書いてありますが、ESPで良いと思います）フロント右側のヘッドフォン端子が機能するはずです。左側は動きません。リアパネルの緑色の出力端子と入力端子も、動きます。VoodooHDA.prefPaneアプリケーションを使うと、システム環境設定で設定できるようになります。\nいくつかのNVIDIAカードのHDMIオーディオは動きません。2.9.0 kextが動かなかったら​VoodooHDA 2.8.8 kextを試すとうまくいくこともあります。アナログオーディオを使うには、AppleHDADisabler kextを忘れず使ってください。\nもし、アナログオーディオが動かなかったらUSBアダプタを買うのが良いです。\n訳注：こちらもどうぞ\n/posts/120/\nStep 10. iMessageとFaceTimeを動かす iMessageとFaceTimeは、ちゃんと設定すれば動きます。\n訳注：こちらも試してください。\niMessageを動かす\nダウンロードファイル 元の記事には、以下のファイルが添付されています。\nHP.6300 Manual.pdf (9.4 MB) VoodooHDA.kext-2.9.0d10.zip (158.6 KB) VoodooHDA.prefPane.zip (471.6 KB) VoodooHDA.kext-2.8.8.zip (163.5 KB) AppleHDADisabler.kext.zip (7.3 KB) I5-3470 ssdt.aml.zip (1.6 KB) I7-3770 ssdt.aml.zip (1.5 KB) ","date":"2017-10-26T13:08:00+09:00","image":"/uploads/2017/10/20171024121826.png","permalink":"/posts/101/","title":"HP 6300 Pro / HP 8300 Elite, Ivy Bridge"},{"content":"IEEE 1394は昔のシリアルバスの規格です。元々はAppleがFireWireという名前で開発した規格なので、一昔のMacintoshには必ず搭載されていました。Windowsマシンにもだいたい搭載されていました。AV機器でも採用されて、ソニーはi.LINKと呼んでいました。IEEE 1394を搭載したマザーボードもあったのですが、今はありません。\n現行のMacintoshでIEEE 1394を使おうとすると、Apple Thunderbolt FireWire アダプタを購入するくらいしか手段はありません。PCIeスロットのついた自作Hackintoshなら、拡張カードで対応できます。\nIEEE 1394 PCIeカード 今回は、 以下の玄人志向のインタフェースカードを使いました。\nTi社製のXIO2213というチップセットを搭載しています。このカードは、PCIeスロットに挿すだけでmacOS High Sierraで機能しました。他社のカードも、だいたいこのチップセットを使っているようなので、どれでも大抵動くのではないかと思います。玄人志向の製品には、古いPCIe 1.0a対応の製品もあるようですが、Amazonのコメントによると最近のマザーボードとの互換性に問題があるので、この製品の方が良いようです。\n大昔のiPodを使ってみる ずーっと引き出しに眠っていたFireWire時代のiPodをmacOS High Sierraマシンに接続してみました。認識されてなんとiTunesが起動しました。\n「システム情報」を見ると、正しく認識されているようです。\ni.LINKデバイスを接続してみる 大昔のSONYのminiDVビデオカメラを接続してみました。i.LINKなので電源ピンのない、4ピンのケーブルが必要です。iMovieを起動してみると、ちゃんと認識されて、カメラ入力が可能です。ビデオテープを入れると、再生、一旦停止、早送り、巻き戻しのコントロールも可能です。iMovieに動画を取り込むこともできました。これで大昔のビデオテープを取り込めます。\n","date":"2017-10-23T13:26:32+09:00","image":"/uploads/2017/10/20171018232428-1.png","permalink":"/posts/102/","title":"IEEE 1394 (FireWire) を使う"},{"content":"追記：DSDTの編集例としてのUSB個数制限の回避を説明します。USB個数制限を回避するには、こちらの方法をお薦めします。\n15個制限を回避するUSBInjectAll.kextの役割と使用法\nDSDTの役割、取得方法、コンパイルの方法、更新方法をこちらで紹介しました。\nDSDTを編集する\n今回は、簡単な例でDSDTを書き換えるハッキングを試してみます。機能を追加したり、修正するのは難しいですが、機能を削るのなら簡単です。\nUSBポートを設定する\n上の記事では、必要なUSBポートを機能させるために、不使用のUSBポートを除外する方法を説明しました。この記事では、DSDTを書き換えて同じことを実現してみます。\n稼働USBポートを確認する 手元にZ97チップセットのマザーボードがあります。Z97は、8本のUSB 2.0と6本のUSB 3.0（最近の表記ではUSB 3.1 gen 1）をサポートしています。USB 3.xには互換性のためにUSB 2.0の線も含まれているので、実際には、USB 2.0が14本、USB 3が6本あることになります。\nこのマザーボードでmacOSを動かして、IORegistryExplorer.appで認識されたUSB一覧を見てみます。すると、機能しているUSBポートは、以下の通りでした。HSはHigh Speed、SSPはSuper Speed PlusでそれぞれUSBの速度のモードです。HSがUSB 2.0で、SSPはUSB 3です。\nつまり、USB 2.0が14本、USB 3が1本見えています。USBの本数が15本と言う制限があり、2.0から先に稼働した結果です。先の記事では、USBInjectAll.kextを使って、不使用のポートを除外して、必要なポートを生かしました。これをDSDTの書き換えでやってみます。\n未使用のUSBをDSDTから削除する USBの使用状況を調べたところ、HS04はどのコネクタにも接続されていませんでした。チップセットには搭載されているけど、配線されていないようです。そこでこれをDSDTから除外してみます。DSDTのソースを見て、HS04で検索します。するとDeviceの記述でアドレスを定義しているらしい箇所が見つかりました。まずはこれをコメントアウトしてみます。\nコンパイルしたらエラーが出ました。\nScopeにもHS04に関する記述があるようです。これもコメントアウトします。長いのですが、/**/を使って自動コメントされた箇所があるので、頑張って行頭の//でコメントアウトします。\nコンパイルしたら、成功しました。これで作成したDSDT.amlをEFI/CLOVER/ACPI/patchedに入れて、使用して、起動してみます。結果はこうなりました。\n無事、未使用のHS04がリストから除外されているのが確認できます。また、15個制限の1個が空いたので、USB 3のポートの一つ、SSP2が新たに有効になりました。\nこの方法を、他にも使用していないポートに対して実施していけば、15個制限の中に、実際に使用しているポートを全て含めることができます。USBInjectAll.kextなどの追加のkextや、config.plistへのパッチが不要です。ある意味、一番根本的な解決方法です。\n","date":"2017-10-21T13:19:56+09:00","image":"/uploads/2017/10/20171011001002.png","permalink":"/posts/103/","title":"DSDTを変更してUSBポートを選別する"},{"content":"\nDSDT (Differentiated System Description Table) はマザーボードがOSに対して提供するACPI規格に基づく情報です。これを通して、マザーボードの電源イベントに関する情報や、マザーボードが備えている機能、構成部品などの情報を提供します。このテーブルは、メーカーによってマザーボードのファームウェア上に用意されています。\nLinux で ACPI の機能が使えないというのはよくある問題です。例えば、ファンが稼働しない、フタを閉じたときに画面がオフにならない、などの問題が発生します。これらの問題は DSDT が Windows しか考えずに作成されているのが原因で、インストール後にDSDTを書き直して（パッチを当てて）修正できます。\nHackintoshの場合、マザーボードがUEFIになってからは、MacintoshのEFIとの差が少なくなったのか、DSDTを改変しなくても動作するようになりました。ただ、ノートPCなどのパワーマネージメントが特殊なハードウェアの場合は、まだDSDT改変が必要です。また、DSDTを書き換えることで、macOSの動作を調整することも可能です。ということで、DSDTの改変のための基本的な手順を紹介します。有用な改変例は、折に触れて、紹介していければ良いかと思っています。\nDSDT情報の差し替え手順 DSDTはAML (ACPI Machine Language)というプログラムのようなデータ形式で記述されます。通常は、マザーボードがAMLをOSに提供します。マザーボードとOSの中間に割り込んだCloverは、マザーボードに代わって、本来あるものとは別のAMLをmacOSに渡すことができます。config.plistで\n\u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;DSDT.aml\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; と設定してあれば、\nEFI/CLOVER/ACPI/patched/DSDT.aml の場所・名前のファイルに記述されたAMLがmacOSに渡されます。\nDSDTを改変する基本的な手順は、以下です。\nマザーボードが提供しているDSDTをDSDT.amlファイルとして入手する これを逆コンパイルしてDSDT.dslというテキストファイルを作る DSDT.dslに変更を加える DSDT.dslをコンパイルしてDSDT.amlを作る DSDT.amlをEFI/CLOVER/ACPI/patchedに置き再起動する 以下で、この手順の詳細を説明します。\nバニラなDSDTを入手する HackintoshでmacOSが動いている状態では、CloverやHackintosh用kextがすでにDSDTを改変している可能性があります。この状態のDSDTを元に改変を進めると、将来のバージョンのCloverやkextで問題が生じる可能性が高いです。トラブルがあった場合の原因の切り分けも困難になります。そこで、マザーボードが提供しているそのままの（バニラな）DSDTを元に、改変を加えるのが良いです。\nCloverやkextが動く前のDSDTを入手するためには、いくつかの方法があります。シンプルなLinux起動DVDや、MS-DOS起動USBメモリを使って起動して、DSDT.aml取得プログラムを動かして入手することもできます。でも、最近のCloverには、DSDT.aml取得機能がありますので、これを使うのが一番簡単です。Cloverの起動ドライブ選択画面で、F1を押すとヘルプが出ます。\nこれにあるようにF4を押すと、EFI/CLOVER/ACPI/origin/にDSDTを取得してくれます。実際に実行すると、25種類のファイルがここに保存されます。この中の、DSDT.amlが必要とするファイルです。\nMaciASL.appで逆コンパイルする DSDT.amlは、インテルが提供しているASLコンパイラでコンパイルできます。このコンパイラの機能をGUIから操作して、逆コンパイル、編集、コンパイルなどの機能を全部やってくれる便利なツール（シンプルなIDE: 統合開発環境）がいくつか提供されています。定番は、MaciASL.appです。最新版はこちらで入手できます。\nReleases · acidanthera/MaciASL\nMaciASLを起動すると、いきなり.dslの情報が表示されます。これは、現在macOSが動いている状態でのDSDTです。なのでCloverなどがすでに改変した後のDSDTです。そこで、前の節で入手したバニラなDSDT.amlを読み込ませます。すると、これを逆コンパイルして人が読める形になった.dsl形式のテキストが表示されます。\nMaciASL.appでコンパイルする 改変する前に、逆コンパイルされた.dslのテキストが、正しくコンパイルできることを確認します。逆コンパイルしたものを、そのままコンパイルするのですが、大抵の場合は、エラーが出ます。逆コンパイルが完璧でないことが原因のようです。エラーの一覧が表示されるので、それをクリックするとエラーの箇所を示してくれます。\n私の手元の環境では、こんな2個のエラーが出ました。最初のエラーをクリックすると、Zeroという変数の行でした。\nプログラムの流れと関係なく唐突に0という変数が出てきたので、エラーを出しているようです。おそらく、元のデータの余白に0が埋め込まれていて、それがそのまま逆コンパイルされたのではないかと思います。\nこの行だけをコメントアウトすると次の行で同じエラーが出ます。Zeroはかなりの数、続いています。そこでこれを全部コメントアウトします。\n2個目のエラーも、Arg0という変数が唐突に現れたことが原因のようです。これもなんかの事情で埋め込まれた意味のない0のようです。\nこれも（こちらは1行だけでした）\n// Arg0 などとしてコメントアウトします。Returnの後の行なので、絶対に到達しない部分ですので、削除して構わないはずです。\nその結果エラーはゼロになりました。警告が多数出ていますが、これは無視して大丈夫です。めでたくコンパイルできました。コンパイルエラーは、マザーボードによって違うと思います。でもソースを見ていれば、なんとなく対処法がわかるかと思います。\nファイルメニューから、「Save As…」などを選び、現れるファイルダイアログで、ASLとAMLで保存できます。AMLファイルが、最終的に必要とするファイルですし、次回もこれから逆コンパイルして作業することができます。ただ、コメントなどは消えてしまうので、ASL形式でも保存しておくと良いです。\nMaciASL.appで編集する ASLが表示されているメイン領域で、自由に編集できます。結構使いやすいです。また、パッチするための手順だけが配布されていることがあるのですが、それを読み込む機能などがあります。\nDSDT改変で、実際にどんなことができるのかは、今後の記事で、試しながら紹介していきたいと思います。\n例えば以下ではUSBの項目を削除してみました。\nDSDTを変更してUSBポートを選別する\n","date":"2017-10-15T00:26:18+09:00","image":"/uploads/2017/10/20171010141821.png","permalink":"/posts/109/","title":"DSDTを編集する"},{"content":"\nmacOSには、ミラーリング、ストライピング、単純な合算の3通りのRAIDを作る機能が備わっています。RAIDはもともと、安価なディスク(Inexpensive Disks)をたくさん使って冗長なディスクアレイ(Redundant Array)を作って信頼性をあげようという目的で考えられました。なので、ミラーリングを行うRAID 1が本来の姿です。本家のMacintoshで複数のHDDを内蔵できる機種は一部のMac miniだけです（それもSSDを搭載しようとすると、HDDは1台です）。一方でHackintoshなら、大容量のHDDを何台でも内蔵することが可能です。Fusion Driveもそうでしたが、RAIDも、Hackintoshならではのメリットを生かせる機能と言えます。\nRAIDはディスクユーティリティ.appからGUI操作で作成することができます。El Capitanの時にRAID作成機能がディスクユーティリティ.appから削除されたことがあります。しかしGUI機能はSierraから復活して、High Sierraでも使うことができます。ディスクユーティリティ.appは、diskutilコマンドを呼び出しているだけですので、GUIで作れなくてもdiskutilコマンドで作ることにできます。\nここでは、ディスクユーティリティ.appを使ってRAID 1を作ってみます。\nディスクユーティリティでRAIDを作る まずは手元にある古いHDDを2台、Hackintoshに接続しました。そこでディスクユーティリティを起動します。\nファイルメニューからRAIDアシスタントを起動します。ここでRAID 1を選択します。\n次のダイアログで、RAIDにするHDDを選択し、次に名前をつけます。RaidOneという名前にしてみました。\nこれで完成です。\nファインダには、通常のHDDのようにマウントされています。\ndiskutil listコマンドで確認してみると、/dev/disk1と/dev/disk6に実際のハードディスクがマウントされていて、RAIDのドライブは/dev/disk7にマウントされています。\n$ diskutil list /dev/disk1 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *80.0 GB disk1 1: EFI EFI 209.7 MB disk1s1 2: Apple_RAID 79.7 GB disk1s2 3: Apple_Boot Boot OS X 134.2 MB disk1s3 /dev/disk6 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *80.0 GB disk6 1: EFI EFI 209.7 MB disk6s1 2: Apple_RAID 79.7 GB disk6s2 3: Apple_Boot Boot OS X 134.2 MB disk6s3 /dev/disk7 (internal, virtual): #: TYPE NAME SIZE IDENTIFIER 0: Apple_HFS RaidOne +79.7 GB disk7 RAIDのドライブはHFS+でフォーマット済みです。これはAPFSでフォーマットし直すことも可能です。APFSでフォーマットすると、/dev/disk7にはAPFS Containerができて、実際の中身は/dev/disk8にマウントされました。\n/dev/disk7 (internal, virtual): #: TYPE NAME SIZE IDENTIFIER 0: Apple_APFS +79.7 GB disk7 /dev/disk8 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +79.7 GB disk8 Physical Store disk7 1: APFS Volume RaidOne 938.0 KB disk8s1 RAIDを使ってみる 今回使用した2台のHDDは同じもので、Blackmagic Disk Speed Testで計測するとReadが42MB/sでWriteが44MB/sでした。RAIDを構成した場合は、Readは変わらず42MB/sでWriteが56MB/sでした。ほとんど変わらないばかりか、むしろWriteは高速化されていました。RAIDにすることでの速度低下は無いと言えます。\nディスクユーティリティでRAIDの状態を知ることができます。同じことは、diskutil appleRAID listコマンドでも行えます。（ディスクユーティリティの応答が悪かったりする場合があり、diskutilコマンドの方が確実でした。なので以下でも対応するdiskutilコマンドも書いていきます）\nHDDが壊れた状況を作り出す ミラーリングなので、どちらかが故障した時にどう対処できるか試してみました。そこで、電源が入ったまま片方のHDDを引き抜いてみました。\n抜いた方のディスクが「見つからない/破損」の表示になりました。diskutil appleRAID listでは、Missing/Damagedと表示されます。\n壊れたHDDをRAIDから除外する 壊れた（抜いたのですが）HDDをRAIDから切り離してみます。これには、対象のドライブを選択して、マイナスボタンを押します。\nターミナルからは、\ndiskutil appleRAID remove XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX disk7 というコマンドを打ちます。HDDを指定するにはいろいろな方法が提供されています。\ndiskutil appleRAID removeとだけタイプすると説明が出ます。ここでは、listコマンドで出てきたUUIDを使って指定してみました（XXXXの部分が壊れたHDDに相当するUUIDです。またdisk7はRAIDのマウント位置です）。\nこんな感じでRAID 1の片方が解除されました。\n交換のHDDを取り付ける 次に別のHDDを差し込んで、これをRAIDに追加しました。上の画面の「+」ボタンを押して、「メンバーを追加…」を選び、HDDを選択します。\nもしくは、ターミナルから、\ndiskutil ar add member disk2 /Volumes/RaidOne をタイプします。これは交換のHDDが/dev/disk2としてマウントされた場合の例です。この後、rebuild（再構成）が開始されて、1時間後くらいに2台のミラーリングとして復帰しました。再構成の進捗はdiskutil appleRAID listコマンドで確認できます。\nミラーリングの利点 ミラーリングによりHDDの一台が故障してもデータを失わないで済みます。ということで、バックアップできることはメリットなのですが、バックアップだけが目的ならTimemachineでも良いです。むしろ過去の状況に戻ることで、操作ミスによるデータ損失まで復帰できるので、Timemachineの方が優れています。\nミラーリングのメリットは、バックアップ機能そのものよりも、システムを停止しないでバックアップからの復帰ができることだと思います。HDDをいきなり引っこ抜いて故障状況を作り出して、新しいHDDと交換する作業を上記に示しましたが、この復旧作業中にもかかわらず、RAIDディスクにはずっとアクセス可能でした。rebuildには時間がかかりますが、その間もアクセス可能です。\nということで、ミラーリングとTimemachineを組み合わせたら、最強のバックアップになると思います。HDDをたくさん組み込めるマシンを作ったら、HackintoshでしかできないmacOSのRAID機能を活用してはどうでしょう。\n","date":"2017-10-12T22:19:01+09:00","image":"/uploads/2017/10/20171009151639.png","permalink":"/posts/110/","title":"macOSでRAIDを組む"},{"content":"macOSでは、高速なSSDと大容量のHDDを組み合わせてFusion Driveを構成することができます。実際のMacintoshと全く同じく、Hackintoshでも、ターミナル上でdiskutilコマンドを使ってFusion Driveを作れます。今でしたら、ビット単価の安い240GB程度のm.2のNVMe SSDと、3TB~4TB程度の3.5インチHDDを組み合わせることで、高速で大容量のドライブを作ることができます。本家のMacintoshでは、市販のm.2 SSDや大容量3.5インチHDDは内蔵できませんので、Hackintoshのメリットを生かせる機能と言えます。\nFusion Driveは従来はcoreStorageという枠組みを使って構成していました。ところが、APFSになって導入されたAPFS Containerを用いることで、APFS対応のFusion Driveが作れるようです。そこで今回は、APFS ContainerによるFusion Driveを作ってみました。\nAPFS Container ターミナルから、diskutilとだけタイプすると簡単なコマンドリストが出てきます。（詳細はman diskutilで出ます）コマンドリストの最後に、\nappleRAID coreStorage apfs の3つのサブコマンドがあります。appleRAIDはソフトウェアRAIDを作る機能で、ミラーリング、ストライピング、単純な合算の3通りのRAIDを作ってくれます。coreStorageというのは、Macintoshでサポートされている論理ディスクの仕組みです。coreStorageには、性能の異なるディスクをまとめ上げた場合、性能の良い方を優先して使う機能があります。こうして作られていたのが従来型のFusion Driveです。coreStorageはAPFSに対応していません。\n最後のapfsは、新しく追加されたAPFSに関する機能を使うコマンドです。diskutil apfsとタイプすると、apfsサブコマンドで実行できる内容が一覧表示されます。このうちAPFS Containerに関するコマンドには、\ncreateContainer (新しい空のAPFS Containerを作る) deleteContainer (APFS Containerを消して構成ディスクをHFSでフォーマット) resizeContainer (APFS Containerのサイズを変更) addVolume (APFS VolumeをAPFS Containerに追加する) deleteVolume (APFS ContainerからAPFS Volumeを削除する) があります。ここでdiskutil apfs createContainerとタイプするとヘルプが表示されます。\n$ diskutil apfs createContainer Usage: diskutil apfs createContainer [] diskutil apfs createContainer -main [-secondary ] where = MountPoint|DiskIdentifier|DeviceNode Create an empty APFS Container. You can then add APFS Volumes with the diskutil apfs addVolume verb. If you specify two disks, then a \u0026#34;Fusion\u0026#34; Container is created, with the performance roles assigned automatically unless you use the -main and -secondary options, in which case, the secondary disk is assumed to be on \u0026#34;slower\u0026#34; hardware which is preferably not solid solid state, usually larger, and often used to store associated \u0026#34;auxiliary\u0026#34; data such as the Windows partition(s) for Boot Camp Assistant. Ownership of any affected disks is required. Example: diskutil apfs createContainer disk0s2 ここに書いてあるように、createContainerコマンドで、2つのディスクを指定すると、Fusion方式のAPFS Containerが生成されます。2つのディスクのうち、高速なディスクの方が、自動的にメインのディスク（高速な方のディスク。HDDとSSDを組み合わせた場合のSSD側）になります。-mainと-secondaryオプションでメインのディスクをマニュアルで指定することもできます。\nFusion Driveを組んでみる 実際にAPFSでFusion Driveを構成してみます。まずはマシンにssdとhdd（手元にあった古い64GBと160GBのものを使いました）を接続して、番号をdiskutil listで調べておきます。ここではHDDが/dev/disk0に、SSDが/dev/disk3に割り当てられました。\nAPFS Containerはボリュームが出来ていないと構成できないようです。そこで、シンプルにジャーナル付HFS+でフォーマットしました。APFSでフォーマットすると自動的にAPFS Containerが作られてしまうので、この後のステップでcreateContainerコマンドを実行するときに邪魔になるようです。ディスクユーティリティ.appでフォーマットしても良かったと思いますが、コマンドラインでやってみました。\n$ diskutil eraseDisk JHFS+ HDD160GB disk0 $ diskutil eraseDisk JHFS+ SSD64GB disk3 それぞれの名前をHDD160GBとSSD64GBとしました。$ diskutil listで見てみると：\n/dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *160.0 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_HFS HDD160GB 159.7 GB disk0s2 /dev/disk3 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *64.0 GB disk3 1: EFI EFI 209.7 MB disk3s1 2: Apple_HFS SSD64GB 63.7 GB disk3s2 となっていました。ここで\n$ diskutil apfs createContainer disk0s2 disk3s2 とすると、APFS Containerが作られます。フォーマットも自動的にAPFSに変更されます。再び\n$ diskutil list で見ると：\n$ diskutil list /dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *160.0 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_APFS Container disk7 159.8 GB disk0s2 /dev/disk3 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *64.0 GB disk3 1: EFI EFI 209.7 MB disk3s1 2: Apple_APFS Container disk7 63.8 GB disk3s2 /dev/disk7 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +223.6 GB disk7 Physical Stores disk0s2, disk3s2 /dev/disk7というドライブが出来上がっていました（disk4,5,6は実ドライブが搭載されていたので7番になりました）。この状態では、入れ物ができた段階で、まだフォーマットされていません。そこで、例えば\n$ diskutil apfs addVolume disk7 APFS Fusion としてフォーマットします。APFSはファイルフォーマットの指定です。でもAPFS以外は指定できないようです。最後のオプションはボリュームの名前です。わかりやすいようにFusionにしてみました。\nFusion Driveを使ってみる こうして作成したFusion Driveを使ってみました。まずはdiskutil listしてみると、\n/dev/disk7 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +223.6 GB disk7 Physical Stores disk0s2, disk3s2 1: APFS Volume Fusion 880.6 KB disk7s1 というようにFusionドライブができていることがわかります。ボリュームサイズが880KBと、とても小さいのですが、これは動的に拡張されていくようです。実際に3GB以上のサイズのファイルを入れてみたら、それに合わせてサイズが増えていました。addVolumeコマンドの-reserveオプションで最低サイズを指定したり、-quotaオプションで最大サイズを指定することもできるようです。\n/dev/disk7 (synthesized): #: TYPE NAME SIZE IDENTIFIER 0: APFS Container Scheme - +223.6 GB disk7 Physical Stores disk2s2, disk3s2 1: APFS Volume Fusion 3.1 GB disk7s1 この段階で、Fusionという名前のボリュームが自動的にマウントされています。ここでのサイズ表示はSSDとHDDの合計になっています。Blackmagicで読み書き速度を測ってみたら、SSDの速度とほぼ同じでした。ほとんど空の状態なのでSSDだけが仕事をしていたのだと思います。\nこのドライブにHigh Sierraをインストールしてみようとしたところ、APFSを止めてHFS+にするよう指示が出てしまいました。APFS ContainerのFusion Driveであっても、今のHigh SierraではAPFS未対応のようです。\n","date":"2017-10-09T10:44:44+09:00","image":"/uploads/2017/10/20171008193447.png","permalink":"/posts/111/","title":"APFSに対応したFusion Driveを作る"},{"content":"\nIntelが、CPUと内蔵GPUの消費電力、動作クロック、温度が測定できるアプリケーション、Intel Power Gadgetを以下のサイトで配布しています。\nIntel® Power Gadget\n実際のMacintosh以外のハードウェアでmacOSを動かす場合、ハードウェア構成がOSに正しく伝わることが重要です。ハードウェア構成が正しく伝わっていないと、ハードウェアを効果的に、効率的に動かすことができません。今のCPUは省電力のために様々な仕組みを提供しています。多くのCPUは基本的な省電力機能として、負荷が小さい時には動作クロック周波数を下げて省電力を図り、負荷が大きい場合には、動作クロック周波数を上げて処理能力を向上させる機能を持っています。Intel Power Gadgetは、消費電力、クロック周波数、温度をモニターできるので、macOSがCPUの電力制御機能を利用できているかどうか、確認することができます。\nmacOS 10.13をインストールしたCore i5-4250U搭載NUCで動かした様子を上に示します。上から、\nPower（消費電力）：大きい値がCPU全体、IAがコアの消費電力 Frequency（動作周波数）：IAがCPUコアの、GTが内蔵GPUのクロック周波数 Temperature（温度）：CPUパッケージの温度 です。Core i5-4250UはMacBook Air Mid 2013にも搭載されているCPUで、モバイル用の低消費電力モデルです。仕様によるとTDPが15Wです。なので15Wのところに線が引かれているのだと思います。ベース周波数が1.3GHz, ターボブースト最大が2.6GHzだそうで、だいたいその間でクロック数が変動していることがわかります。グラフィックスは、ベース周波数が200MHz, 最大が1GHzだそうです。ベース周波数でだいたい動いていることがわかります。コンピュータを操作したり、逆に放置したりすると、周波数や消費電力が変動します。実際のMacBook Airと同じような動作をしていますので、macOSがCPUの電力制御を正しく行えていると判断できます。\n補足：High Sierraへのインストール High Sierraから、署名されたkextに対しても確認が必要になったようです。クリーンインストールしたシステムにIntel Power Gadgetをインストールすると、下のようなダイアログが出ます。「システム環境設定・セキュリティとプライバシー」から許可をすると動くようになります。\n","date":"2017-10-08T12:26:33+09:00","image":"/uploads/2017/09/20170918234937.png","permalink":"/posts/112/","title":"Intel Power Gadget"},{"content":"macOSを使う上でぜひ用意して欲しいのがApple Magic Trackpad 2です。マルチタッチ機能を利用したスワイプ、回転、ピンチなどのジェスチャを用いた、直感的な画面操作が可能になります。これ無しでは、macOSの直接操作を全て活用することができません。macOSの一部と言っても良いと思います。ただ、マウスに慣れきった体で移行した直後は、少し指がつる思いをするかも知れません。でも2-3日すれば慣れます。使いやすさを知ってしまったら、マウスには戻れないと思います。\n一般的なマウスに比べたら高価ですが、無料でmacOSを使わせていただいて安いハードウェアを利用しているので、これくらいは買ってアップル社に還元しても良いかと思います。さらにはApple Magic Keyboardを並べて使うと、さらに高価になりますが、キートップの高さとトラックパッドの高さが揃って、美しいです。\nApple Magic Trackpad 2は本家アップルストアでは￥12,800 (税別)です。Amazonの方が高い時もあり、安い時もあるようですが、この記事の執筆時点ではAmazonの方が少しだけ安いようです。Apple Magic Keyboardも、本家では￥10,800 (税別)なので、現在はAmazonの方が多少お安いようです。\n","date":"2017-10-07T15:36:19+09:00","image":"/uploads/2017/10/20171007135056.png","permalink":"/posts/113/","title":"Magic Trackpad 2は良いです"},{"content":"追記：この記事ではUSBの15個制限を簡易的に回避します。本気で対応するには、この記事の方法よりも、以下をお薦めします。\n15個制限を回避するUSBInjectAll.kextの役割と使用法\nこの記事の結論を先に書いておきます。\n15個の制限を外すパッチとUSBInjectAll.kextを併用すると全てのUSBポートが使えるようになる (tonymacx86のMultiBeast方式) 15個制限解除パッチを使用せずに、USBInjectAll.kextのみを使って、実際に使用するポートを15個まで選択できる (お勧めの方式) El Capitanから使用可能なUSBポートの数が、 コントローラ当たり15までと制限されました。その後のSierraでもHigh Sierraでも同じです。理由は不明です。15ポートもあれば十分と思われるかもしれませんが、そうでもありません。まず、USB 3ポートは、互換性のためにUSB 2.0の端子も持っています。なので、2ポート分としてカウントされます。また、USB 2.0の端子から先にアサインされるので、USB 3の端子が使えず、USB 3のポートがUSB 2.0相当になってしまうこともあります。その対策について説明します。\n何も対策しない場合のUSB構成 まずは、何も対策しないとどうなるかを見て見ましょう。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。 ちなみに表示される情報は、Cloverのパッチや各種kextが機能した後の結果で、マザーボードのUEFIが提示しているオリジナルの構成ではありません。\nmac.softpedia.com\nIORegistryExplorer.appを起動して、右上の虫眼鏡アイコンのところに、xhcと入力します。するとXHC関係の情報が現れます。XHCの下にHS01やSSP1と見えているのが、現在OSが認識しているUSBポートです。HSはHigh Speed、SSPはSuper Speed PlusでそれぞれUSBの速度のモードです。HSがUSB 2.0で、SSPはUSB 3です。\n全く対策しない状態の手元のマザーボード(MSI Z97A Gaming 7)では、以下のような結果になりました。\nUSB 2.0がHS01からHS14までの14本あり、USB 3がSSP1の1本あるという結果です。このマザーボードには、実際には他にもSSP2からSSP6の5本のUSB 3があるのですが、15本の制限を超えてしまったので、見えなくなっています。そのポート、例えばSSP6に接続しているUSBポートにUSB 3のUSBメモリを挿しても読み書きできません。（ちなみに、そのポートにUSB 2.0のUSBメモリを挿すと、2.0の端子はHS10に接続されているので、読み書きできます。）\n解決策1：15個の制限を取り払う 解決策の一つは、上限15個の制限を外すパッチを当てることです。次の手順で15個の制限を外して、チップセットに接続された全てのUSBポートを使用できます。\nconfig.plistにポート数を増やすパッチを当てる\nUSBInjectAll.kextを使用する\n2.の両方を実施する必要があります。片方だけではダメです。この解決策の問題点は、パッチパターンがmacOSのバージョンごとに異なることです。パッチは、macOSの該当するバージョンにしか効きません。今使っているmacOS用のパッチが見つからない場合は、解決策2に進んでください。\nポート数を増やすパッチ まずは、AppleUSBXHCIPCI.kextに以下のパッチを当てます（ New USB Raise Port Limit Patch for High Sierra | tonymacx86.com より）。\n\u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Change 15 port limit to 24 in XHCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;g32MEA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleUSBXHCIPCI\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;g32MGw==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; これは10.13 PB1をインストールした100シリーズマザーボード用のパッチと書いてありましたが、正式版10.13でZ97チップマザーボードでも動きました。\n一方で、10.13.4からは違うパッチを当てないといけないようです。\nwww.insanelymac.com\n後にも書きましたが、ポート数を増やすパッチはmacOSのマイナーバージョンごとに違っています。マイナーアップデートの都度対応する必要があり、お勧めの方法ではないです。\nUSBInjectAll.kextを使用 次にUSBInjectAll.kextをEFI/CLOVER/kexts/Otherもしくはバージョン番号のフォルダに入れます。\nRehabMan / OS-X-USB-Inject-All / Downloads — Bitbucket\nこのkextは、チップセットで用意されているUSBポートの全てをmacOSから参照できるように設定する機能があります。Z97チップセットのUSBは、PCIeのvender-id/device-idが8086/8cb1に割り当てられています（IORegistryExplorer.appで見ることができます）。USBInjectAll.kextの中のInfo.plistの8086_8xxxというキーを見ると、HS01からHS14とSSP1からSSP6までの20のポートがあることがわかります。\nconfig.plistへのパッチ当てとUSBInjectAll.kextを使った結果を以下に示します。\nこのように、全てのUSBポートが使えるようになっていることがわかります。これで、順番の最後尾に並んでいたUSB 3も全て機能します。簡単に全USBを使えるように設定できました。tonymacx86で配布しているMultiBeastというインストールツールは、この手法を使っています。\n実際に使っているUSBポートを特定する 上記の解決策で、全部のUSBが使えるようになります。簡単ですが、多少問題があります。まずは、そもそもmacOSが何らかの理由で15個に制限しているのに、その上限を増やしてしまって大丈夫なのかという懸念です。今のところ問題点は報告されていませんが、将来、何らかの副作用が出てくる可能性は否定できません。もう一つは、パッチの内容が、OSのバージョンやチップセットによって変わるらしいことです。今回のHigh Sierraへの移行にあたっても、パッチが更新されました。Sierraの時のパッチでは、上限を回避できないようです。この先のバージョンアップでも対応が必要になると思われます。\n一方、USBInjectAll.kextは、名前は、「全てのUSBポートをインジェクトする」ですが、実際には、一部のUSBポートを遮断する機能があります。たとえば、もともとある20個のポートのうち、任意のポートを指定して、使用しないよう設定することができます。実際に使用しているポートだけを15個選んで設定すれば、15個の上限を外す必要は無くなります。そうすればconfig.plistに素性の良くないパッチを書き込む必要がなくなります。USBInjectAll.kextの方は、RehabManさんによってこまめに更新されているので、今後も安心して使用できます。\n使用しないポートを除外するためには、実際に使っているUSBポートを特定する必要があります。ちょっと大変な作業ですが、マザーボードの構成を把握できるので、達成感はあります。それぞれのポートの番号は、\nそれぞれのポートにUSB機器を接続し、 IORegistryExplorer.app の表示の変化を確認する ことで、特定できます。下の例は、とあるUSB 3ポートにUSB 3.0メモリを挿入してみたところです。SSP5のport-statusが、最初は0x0だったのですが、下の図のように0x1400に変化しました。（kUSBBusCurrentAllocationの値も変化しました。）これで、このポートはSSP5だということがわかります。このポートに、USB 2.0のデバイスを接続すれば、USB 2.0端子の番号もわかります。\nこうして手元のマザーボードを調べて見ました。各ポートの番号は以下のようになっていました。\nHS01 基板上のUSB 3の2.0端子 (フロントパネルで使用) HS02 基板上のUSB 3の2.0端子 (フロントパネルで使用) HS03 バックパネルのUSB 3の2.0端子 HS04 不明 HS05 バックパネルのUSB 2.0 HS06 バックパネルのUSB 2.0 HS07 不明 HS08 不明 HS09 バックパネルのUSB 3の2.0端子 HS10 バックパネルのUSB 3の2.0端子 HS11 基板上のUSB 2.0 (フロントパネルで使用) HS12 基板上のUSB 2.0 (未使用) HS13 基板上のUSB 2.0 (未使用) HS14 基板上のUSB 2.0 (Bluetoothで使用) SSP1 基板上のUSB 3 (フロントパネルで使用) SSP2 基板上のUSB 3 (フロントパネルで使用) SSP3 バックパネルのUSB 3 SSP4 不明 SSP5 バックパネルのUSB 3 SSP6 バックパネルのUSB 3 HS01,02,03,09,10は、それぞれSSP1,2,3,5,6のUSB 3ポートに含まれているUSB 2.0端子です。HS14はBluetoothモジュールに接続しているので、これを無効にするとキーボードもトラックパッドも使えなくなります。不明とあるポートは発見できませんでした。マザーボード上で配線されていないのかもしれません。\n解決策2：使うポートを15個以下に選別する 行方不明のポートを使うことはありませんし、マザーボード上で接続していない端子のポートも当分は使いません。これを考えるとUSBポートを15個以下に絞り込むことができます。上の例では、HS04, HS07, HS08, HS12, HS13, SSP4は除外して良いです。\nUSBInjectAll.kextに除外するポートを伝える方法は、いくつかあるようですが、最も簡単なのは、Cloverのブートオプションで伝える方法です。HS04, HS07, HS08, HS12, HS13, SSP4を除外したい場合は、config.plistのBootキーの中にあるArgumentsキーに、\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;uia_exclude=HS04;HS07;HS08;HS12;HS13;SSP4\u0026lt;/string\u0026gt; と書いておけば良いです。もしもすでに他のオプションが書いてあったら、空白で区切って追記します。例えば-vが書いてあって\n\u0026lt;string\u0026gt;-v\u0026lt;/string\u0026gt; これを残したかったら、以下のようにします。\n\u0026lt;string\u0026gt;-v uia_exclude=HS04;HS07;HS08;HS12;HS13;SSP4\u0026lt;/string\u0026gt; このconfig.plistで起動した結果を以下に示します。使用している14個のポート、HS01, 02, 03, 05, 06, 09, 10, 11, 14およびSSP1, 2, 3, 5, 6が機能していることがわかります。これなら15個未満ですので、config.plistへのパッチは不要です。\n解決策3：DSDTを変更してUSBポートを選別する こちらの記事でDSDTの変更でUSBポートを選別する方法を書いておきました。\nDSDTを変更してUSBポートを選別する\n","date":"2017-09-30T22:25:18+09:00","image":"/uploads/2017/09/20170930110251.png","permalink":"/posts/114/","title":"USBポートを設定する"},{"content":"Hackintoshの完成度を評価する目安は色々あります。例えば、起動するかどうか、画面が出るか、音が出るか、LANに接続できるか、WiFiが動くか、iPhoneと連携できるかなどあります。中でも、iMessageが動くかどうかは機種情報が正しく設定できていることの目安になります。\niMessage騒動 2014年の8月に、多くのHackintoshが、iMessageに繋がらなくなりました。「カスタマーコード」が表示され、iMessageサポートに連絡せよというダイアログが出て、締め出されて（ロックアウト）しまったのです。サーバ管理者側でセキュリティポリシーが変更されたことなので、具体的にどうなったのか知る由もありません。でもHackintoshコミュニティが手探りで試し尽くしたところ、機種ID、ロムとメインロジックボードのシリアル番号情報が、接続ごとに変動したり、フォーマットが正しくない場合に接続できないらしいとわかりました。\n2014年のセキュリティ強化はあまりに過激すぎたのか、Appleサポート掲示板を見ると、本物のMacユーザにも支障が出ていたようです。セキュリティはその後、緩んだり厳しくなったりして、11月頃には、とうとう実機のシリアル番号じゃないと接続できなくなったこともありました。でも2015年の2月のバレンタインデーに、突如チェックが緩和され、ロックアウトが発生しなくなりました。それでも、シリアル番号やボードシリアル番号などは、設定機種に合った正しいフォーマットのデータを継続的に使用することが良いとされています。間違った設定を行っても、ロックアウトには至らなくなりましたが、接続できない問題が発生するようです。\nen0に設定する iMessageに限らず、Appleのネットサービスを利用するためには、EthernetもしくはWi-FiのBSD装置名がen0である必要があります。実機がそうなっているからです。en0になっていないと、iMessageは使えませんし、App Storeへの接続でもエラーが出ます。\n以下の記事でも紹介していますが、\nEthernetを設定する\n以下のファイルを消して再起動すれば良いです。\n/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/Preferences.plist また、en0があってもこれの状態がBuiltinになっていないと接続できないことがあるようです。コメントで教えていただきました。こちらに説明があります。これの対処法も、上記のファイルを消して再起動すれば良いようです。\nシリアル番号類を正しいフォーマットで設定する 先のiMessage騒動の時に、iMessageに認められる正しいシリアル番号のフォーマットが、コミュニティの協力で調べられました。その結果が、Clover Configuratorの自動生成機能に組み込まれています。なので、これを利用して、正しい情報を設定しておけば良いです。以下の記事で紹介しておきました。\n正しく機種設定する (SMBIOSの設定)\n注意すべき点は、一回設定したら、継続して使い続けることです。iMessageにログインするたびに機種情報が変動すると、不正な利用とみなされて接続できなくなる場合があるようです。\niMessageへの接続失敗を無かったことにする 以前にiMessageにログインしようとして失敗したことを無かったことにするためには、以下のファイル/ディレクトリを消して再起動すると良いそうです。\n~/Library/Caches/com.apple.Messages* ~/Library/Caches/com.apple.imfoundation* ~/Library/Preferences/com.apple.iChat* ~/Library/Preferences/com.apple.imagent* ~/Library/Preferences/com.apple.imessage* ~/Library/Preferences/com.apple.imservice* ~/Library/Messages ただし、ロックアウトが発生していた時は、ローカルの記録をいくら消去しても無駄でした。失敗した記録は当然ですがサーバ側にも残っているようです。\nそのほかの条件 大抵の場合は、en0にすることと、SMBIOSで機種情報を正しく設定することで、iMessageを利用できます。それでも、接続がうまくいかなくて苦労している人もいるようです。ネット上にはたくさんの対処法が紹介されています。わかりやすいガイドには以下があります。\nwww.tonymacx86.com\nwww.youtube.com\niMessageのメッセージが届かないとか、遅延するなどの問題も報告されますが、実機を使っても、同様なことが発生します。なので、実はHackintoshの問題ではなく、iCloud / AppleID自体のトラブルである可能性も高いです。\nまた、古くからのApple IDユーザのアカウントであったり、クレジットカードを登録しているアカウントは問題を起こしにくいという噂もあります。本当かもしれませんし、都市伝説みたいなものかもしれません。さらには、最近はApple IDが2ファクタ認証に移行しつつあります。2ファクタ認証しているApple IDは従来よりセキュアなので、その結果ロックアウトされにくいように思います。何れにしても、サーバ側でどのように運営しているかは謎ですし、そのポリシーも変化していると思われます。\n","date":"2017-09-28T23:11:19+09:00","image":"/uploads/2017/09/20170928205734.png","permalink":"/posts/116/","title":"iMessageを動かす"},{"content":"\nSierraで動いているHackintoshなら移行は簡単 High Sierraが出ました。HackintoshはOSのバージョンアップの時に設定がダメになって苦労する、と思い込んでいる人も多いかもしれません。でも、最近はとても簡単になりました。マイナーバージョンアップ（例えば10.12.5から10.12.6へのバージョンアップ）なんて、App Storeからダウンロードしてクリックするだけです。実機と同じです。今回のようなメジャーアップデート（10.12から10.13）は、いろいろと対応する必要がある場合もあります。でも、今年は楽勝の部類でした。\nということで、すでにSierraで動いているHackintoshをHigh Sierraにアップデートする方法を書いておきます。ここで紹介する手順は、別ドライブを用意してそこにHigh Sierraをインストールする手順です。\nSierra版の現状のHackintoshを最新版にアップデートしておく(Step 1~2) 別ドライブを用意してそこにHigh Sierraをインストールする(Step 3) APFS起動に必要なapfs.efiをHigh Sierraから手に入れる(Step 4) High SierraドライブにCloverを仮インストールする(Step 5) 現状のSierra HackintoshのESPをHigh Sierraドライブにコピー(Step 6) 別ドライブでちゃんと起動したら、あとはゆっくり、メインドライブのHigh Sierra移行にとりかかってください。\nStep 0: macOSをバニラな状態にしておく 簡単に移行するための前提です。こちらで解説して置きましたのでごらんください。\n/posts/131/\nつまり、macOSが入っているパーティションの内容には一切手を加えないで、実機と全く同じ状態にしておけば、アップデートは簡単になるということです。\nStep 1: 旧バージョンSierraのHackintoshを最新にしておく ここからが作業本番です。Hackintoshコミュニティのハッカーの方々は、High Sierraに向けて更新してくれています。なので、移行前に、最新にしておきましょう。最新にすることでSierraが動かなくなることはありません。最新にしてもSierraがちゃんと動くことを確認してきましょう。\nまずはCloverを最新にします。今日現在ではリビジョン4220が最新のようです。システム環境設定に登録してある場合は、「更新を確認」するだけです。 kextを最新にします。kextの名前でGoogle検索すると配布サイトが出てきますので、最新版に差し替えておきましょう。 kextをEFI/CLOVER/kexts/10.12に入れている人は、10.13を新たに作ってコピーするか、Otherフォルダにコピーしておきます。 詳しくはこちらをご覧ください。\nあと13日！High Sierraのお迎え準備\nStep 2: config.plistのSMBIOS情報を最新にしておく OSとしてのHigh Sierraの一番の変更点は、ファイルシステムがHFS+からAPFSに移行することです。High Sierraのアップデートでは、APFSでも起動できるようにファームウェアもアップデートされます。Hackintoshにとっては関係のないことですが、ファームウェアが対応版にアップデートされていないと判断されると、インストールが止まってしまうようです。そこでconfig.plistのSMBIOSセクションのBIOSバージョンの記述を、最新版ファームウェアと同じバージョン番号に書き換えます。\n詳しい手順は、これもこちらをご覧下さい。\nあと13日！High Sierraのお迎え準備\nStep 3: High Sierraを別ドライブにインストールする ここまでのステップで準備がしっかりできたので、ここから先は簡単です。\nHigh Sierraをインストールするドライブを接続します。SSDでもHDDでも良いです。USB接続でも良いです。自作の人なら、余っているドライブをSATAケーブルでマザーボードに接続しても良いですね。\nこのドライブをディスクユーティリティでフォーマットします。フォーマットは、GUIDパーティションマップとHFS+ (Mac OS拡張 ジャーナリング）とします。SierraのディスクユーティリティではAPFSを選択できません。が、ここでHFS+でフォーマットしても、SSDの場合は、この後のインストールで自動的にAPFSに変換されます。\nApple App StoreからHigh Sierraインストーラをダウンロードして、このドライブにインストールします。インストール途中で再起動することがあります。その場合は、現行のドライブで起動して、Cloverのメニューからインストール途中と思われるドライブを選択します。「Boot macOS Install from XXXX」というのがインストール途中にだけ現れるボリュームで、これを選択します。\n途中の起動回数は、いつもは1回の気がしましたが、今回は2回のようでした。たまたまかもしれませんが、もしかしたらファームウェアをアップデートする作業（Hackintoshでは無駄な作業ですが）があったのかもしれません。もしくは、APFS変換の関係なのかもしれません。\nインストールが終了したら、やはり、再起動します。インストール途中の再起動なのか、インストールが終了した後の再起動なのかは、先ほどの「Boot macOS Install from XXXX」というボリュームの有無で判断できます。Cloverの選択画面にこれがなくなっていれば、インストールは終了しています。\nインストーラがHFS+でHigh Sierraをインストールした場合、Cloverのボリューム選択にHigh Sierraが現れていると思います。High Sierraを起動しても良いのですが、ここは、ぐっと我慢して次のステップに行きましょう。APFSに変換された場合は、High Sierraが現れていないと思います。次のステップで対応します。\n次のステップでは、まずは古いSierraのドライブを選択して起動します。\nStep 4: 最新版のAPFSドライバapfs.efiをESPに入れる 2018/06/19更新：Clover 4558からApfsDriverLoader.efiというドライバができて、apfs.efiの機能を自動的にロードしてくれるようになりました。なので、 /usr/standalone/i386/ からapfs.efiを取り寄せてESPに置く以下の作業は不要になりました。記録のために残しておきます。\nHigh Sierra Public Betaの初期のバージョンでは、HFS+でのインストールがメニュー選択で可能でした。しかし、正式版をSSDにインストールする場合は、自動的にAPFSフォーマットに変換されるようです。HDDやFusion driveの場合はHFS+のままのようです。\nClover、というか一般にブートローダは、OSが起動する前に、ドライブからブートのためのファイル（例えばカーネルなど）を読み込む必要があります。なので、ファイルシステムにアクセスできる必要があります。この機能は、High Sierraの\n/usr/standalone/i386/apfs.efi で行えます。そこで、このファイルを、CloverのESPにコピーします。それを行わないと、APFSでフォーマットされたHigh Sierraを起動できません。そこで、APFSブートには以下のステップが必須です。\nAPFSでインストールしたHigh Sierraの起動はひとまずお預けにして、今まで通りHFS+の古いSierraを選択して起動します。この時High Sierraを選択したくてもAPFSなので選択画面に現れていないはずです。 CloverのESPをマウントします。 High Sierraの中のapfs.efiをEFI/CLOVER/drivers64UEFIの中にコピーします。 再びSierraのボリュームで起動すると、今度はAPFSのHigh SierraがClover選択画面に見えているはずです。これを選択して起動します。 ベータ版時代のバージョンアップでapfs.efiは度々更新されていました。初期のベータ版から入手したapfs.efiで、後期のHigh Sierraが起動できなかったこともあります。apfs.efiがネットに落ちていることもありますが、公開版High Sierraに入っている最新版を使うのが良いでしょう。\nHigh Sierraは起動しましたでしょうか？うまく起動すれば、ユーザ設定などの画面に進み、ログインできます。ここまでくればもう安心です。\nStep 5: High SierraのドライブにCloverをインストールする このステップは飛ばしても良いです。\n現行のドライブのCloverからHigh Sierraのドライブが無事起動できて、アカウントなどの設定が終わったら、Cloverのインストーラを起動して、新しいドライブにCloverを入れます。このとき、ESPにインストールするよう指定します。\nStep 6: 現行のESPからファイルをHigh SierraのESPにコピーする High SierraのESPには、とりあえずインストールしたClover関連のディレクトリができているはずです。前のステップを省略すると、できていないかもしれません。何れにしても、古いSierraのドライブのESPの内容を、新しいHigh SierraのESPにコピーして、同じ内容にします。 ファインダーからのドラッグ\u0026amp;ドロップで作業しても問題ありません。これで、High Sierraのドライブを起動ディスクにしても、ちゃんとHigh Sierraが起動するはずです。\n次のStep: メインドライブのアップデート これで無事、別ドライブで起動できましたでしょうか。問題なければメインドライブもアップデートしましょう。このステップと同様に、今度は、High Sierraのドライブから、メインドライブにインストールしていけば良いです。上書きインストールでも、いっそすっきりとフォーマットしてのクリーンインストールでもどちらでも良いと思います。Time Machineでバックアップとってあれば、クリーンインストールの後で移行することもできます。\n補足 SMBIOSのデフォルト設定 Clover r4179以降では、config.plistで以下の値：\nBiosReleaseDate BiosVersion FirmwareFeatures FirmwareFeaturesMask を指定しなくても、機種モデルの最新の値がデフォルトで設定されるようになったという情報もあります。実際にBiosVersionを削除して見たところ、それでも最新の値が使われていました。Step 2の作業の代わりに、これらの指定を単に削除して、Cloverのデフォルトに任せるのも可能かと思われます。\nhttp://www.insanelymac.com/forum/topic/304530-clover-change-explanations/page-4#entry2482211\napfs.efiを入手するもう一つの方法 上記の説明では、High Sierraをインストールした後で、apfs.efiを入手しています。インストールする以前の、Install macOS High Sierra.app (日本語名は macOS High Sierraインストール.app)から取り出すこともできます。.appの中の\nInstall\\ macOS\\ High\\ Sierra.app/Contents/SharedSupport/BaseSystem.dmg にあるBaseSystem.dmgを開いてマウントします。次に、\n/Volumes/OS X Base System/usr/standalone/i386/apfs.efi の場所にあるapfs.efiを手に入れます。これで、Step 3の段階でapfs.efiを入手してESPに入れることができ、すぐにHigh Sierraから起動できます。\n","date":"2017-09-26T12:18:21+09:00","image":"/uploads/2017/09/20170926115342.png","permalink":"/posts/117/","title":"HackintoshをHigh Sierraにする"},{"content":"Lilu.kextはkext (カーネル拡張)にパッチを当てる仕組みを提供するkextです。ライブラリやプログラムにもパッチを当てられるようですが、kextにパッチを当てるために便利に用いられています。今年になってから登場した新しいkextです。元々は、サウンドを提供するkextであるAppleALC.kextを開発していた人が、パッチ当ての部分を分離して公開してくれたものです。なので、現在のAppleALC.kextもLilu.kextを使っています。\nReleases · acidanthera/Lilu\nLilu.kextはパッチを当てるkextと一緒に使います。バニラな構成ならば、それぞれをEFI/CLOVER/kextsのOtherもしくは該当するバージョンのフォルダに一緒に入れます。Cloverもconfig.plistのKextsToPatchセクションの記述でkextにパッチを当ててくれます。この記述は簡単なのですが、kext本体のバイナリーファイルにしかパッチを当てられません。Lilu.kextは、パッチ方法を指定するkextを開発する必要がありますが、kext本体以外の様々なファイルや設定にパッチを当てられるようです。\n以下で、Lilu.kextと一緒に使うためのkextを紹介します。\nAppleALC macOSのHD audio機能を使って音を出すためのパッチ。こちらで説明しました。\n/posts/120/\n古いバージョンは単独で動きますが、パッチ当て機能をLilu.kextに分離した後のバージョンは、Lilu.kextと一緒に使います。\nReleases · acidanthera/AppleALC\nWhateverGreen ~~10.12.6からRX480/580などのAMDグラフィックスカードがサポートされました。しかし、メインディスプレイにはならず、起動時にはCPU内蔵GPUなどの補助GPUが必要でした。これを解決するのがWhateverGreen.kextです。Radeonを使う人には必須です。~~以前はAMDグラフィックスカードの不具合に対応するkextでした。それでAMDカラーのgreenという名前が付いています。今は、\nIntelGraphicsFixup NvidiaGraphicsFixup Shiki の機能を統合し、ディスプレイに関係するパッチ機能をすべて盛り込んだkextになりました。詳しくは以下をご覧ください。これを入れれば統合されてしまったkextは使う必要がありません。\nGPU関連kextがWhateverGreen.kext 1.2.0に統合されました\nNvidiaGraphicsFixup このkextはWhateverGreenに統合されました。\nNVIDIAのGPUをiMac15,1 iMac17,1 MacPro 6,1のシステム設定で使おうとすると、 ブート後に画面が黒くなって起動しなかったり、画面がスリープしたりする問題が発生します。 WebドライバだけでなくmacOS標準のドライバでも発生します。 iMacのレティナディスプレイやProのデュアルグラフィックスカードハードウェアを前提とした macOSの設定が、この問題を引き起こしているようで、black screen問題と呼ばれています。このkextを使うと、black screenを回避できます。\nReleases · lvs1974/NvidiaGraphicsFixup\nIntelGraphicsFixup このkextはWhateverGreenに統合されました。\nIntel HD Graphicsを使う場合に発生する以下の不具合を解決します。\nIntel Graphics HD4000以降のブートロゴ表示の乱れ Intel Azul Graphics (HD4400, HD4600)におけるPAVPフリーズ問題 ブートロゴの乱れは、起動時のアップルロゴとプログレスバーが表示される場面の後半で、 表示が8個に分裂してストライプ状になる現象です。起動時だけのことで、無視しても良いくらいの問題ですがこれが解決されます。もう一つのPAVPフリーズ問題はもっと深刻で、 一部の動画サイトをSafariで閲覧する場合や、iTunesでiTunes Storeの予告編を見る場面で、動画再生が滞ったり、場合によってはOSがフリーズする問題です。\nReleases · lvs1974/IntelGraphicsFixup\nShiki このkextはWhateverGreenに統合されました。\niTunesにあるDRM保護されているビデオはivy bridge以降で再生できない問題があります。 購入した映画や、その予告編を再生しようとすると、 映像が出ないとか、音だけしか出ない状態です。 これを回避します。\nReleases · acidanthera/Shiki\nNightShiftUnlocker 10.12.4から導入されたNight Shift機能ですが、これにはMacBookPro9,x iMac13,x Macmini6,x MacBookAir5,x MacPro6,x MacBook8,x以降の機種が対応しています。これより古い機種でNight Shiftを動かすためのkextです。\nReleases · 0xFireWolf/NightShiftUnlocker\nそのほか 用途・効果を理解できていないのですが、Lilu.kextのサイトによると、このほかにも以下のようないろいろなパッチがあるようです。\nAirportBrcmFixup Broadcom Airport Wi-Fi cardsへのパッチ\nAzulPatcher4600 Intel HD 4600 へのパッチ\nCoreDisplayFixup 非Iris Intel graphicsの高解像度サポート\nCPUFriend 動的なパワーマネージメント\nEnableLidWake ラップトップで蓋を開けた時のIntel Graphicsスリープ解除対応\nHibernationFixup 3モードと25モードのハイバネーション対応\n","date":"2017-09-23T23:09:00+09:00","image":"/uploads/2018/08/20170915223211.png","permalink":"/posts/118/","title":"パッチを当てるkext: Lilu.kext"},{"content":"長ったらしくてわかりにくいconfig.plistの書き方を、簡単に説明してみます。config.plistはCloverの設定をxml形式で書いたテキストファイルです。そのマニュアルは、Clover Wikiで公開されています。\nhttps://clover-wiki.zetam.org/Configuration#Config.plist-structure\nただ、ここで十分に説明し尽くされていない項目も多く、分かりにくいです。Cloverは、長い間、様々な世代のCPU、チップセット、GPU、周辺機器をサポートしてきて、それに対応した機能を提供してきました。それらを全てconfig.plistで設定しているので、わかりにくくなるのも仕方ありません。古いシステムに関連している設定項目などは、もはやそれが実装された経緯を知らない人も多いはずです。\nということで、実際に動いているconfig.plistを例に、最新のハードウェアに関した項目だけに絞って説明してみます。下に示したconfig.plistの例はMSI Z97Aマザーボードで動いている設定です。デフォルトの設定、最新ハードウェアには無関係な部分などを削除しているので、割と短くてわかりやすいかと思います。9シリーズチップセットのマザーボードの例ですが、UEFIのマザーボードならこのconfig.plistでだいたい動くと思います。\nhttps://pastebin.com/FkCTZEvq\n以下でセクションごとに説明していきます。\nACPI config.plistの冒頭に書かれているのはACPIセクションです。ACPIはAdvanced Configuration and Power Interfaceの略で、マザーボードの電源機能と構成要素を列挙し管理する統一された枠組です。DSDT (Differentiated System Description Table) は、マザーボードごとに固有の電源管理と構成を記述したデータです。SSDT (Secondary System Description Table)は、DSDTの補足データで、DSDTの一部を記述したデータです。SSDTには、DSDTの一部の記述をして、DSDTの内容を上書きします。\nDSDTは全てのマザーボードが持っています。Hackintoshのコミュニティによって、DSDTに足りない記述を書き足したり、書き換えたりして、macOSを動かす努力が長年されてきました。昔のBIOSベースのマザーボードの時代には、それぞれのマザーボードBIOSバージョンごとに、改変されたSSDTが作られて、それを使ってmacOSをインストールしていました。config.plistのACPIセクションのDSDTとSSDTは、マザーボードが持っているACPI情報をどのように改変すべきかを書いた場所です。動的にパッチを当てるCloverの重要機能を指定しています。\nMSI Z97Aマザーボードで動かすconfig.plistのACPIセクションを下に示します。\n\u0026lt;?xml version=\u0026#34;1.0\u0026#34; encoding=\u0026#34;UTF-8\u0026#34;?\u0026gt; \u0026lt;!DOCTYPE plist PUBLIC \u0026#34;-//Apple//DTD PLIST 1.0//EN\u0026#34; \u0026#34;http://www.apple.com/DTDs/PropertyList-1.0.dtd\u0026#34;\u0026gt; \u0026lt;plist version=\u0026#34;1.0\u0026#34;\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ACPI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;DSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;DSDT.aml\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;SSDT\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Generate\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CStates\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;PStates\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; 重要機能の割には、シンプルです。というのも、UEFIマザーボードの時代になって以来、DSDTを変更しなくても、ほとんどそのままで動くようになったからです。なのでDSDTへのパッチ当ての指示は全て削除することができます。Nameでは、将来、手作業でDSDTにパッチ当てをしたいときに備えて、パッチを当てたDSDTファイルの名前を入れてあるだけです。なので、この記述も実は不要です。ちなみに、パッチを当てたDSDTファイルは、CloverのACPI/patchedディレクトリに入れます。\nGenerateでは、CPUの電源制御のCステートとPステートを用意するよう指定しました。これが必要なのかどうかよくわかっていませんが、多くのconfig.plistでこの指定がしてあるので、ここでも使いました。\nまたDSDT項目名を変更するパッチも必要に応じて書きます。こちらで説明しておきました。\nconfig.plistでDSDT項目名を変更するパッチ\nBoot Bootの設定です。\n\u0026lt;key\u0026gt;Boot\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Arguments\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;DefaultVolume\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Macintosh HD\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Timeout\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;key\u0026gt;XMPDetection\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;NO\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; Argumentsは、Cloverがブートするときのオプションです。-vとか-xとか色々あります。また、kextが引き取ってくれるオプションもここに書きます。普通の起動にはオプション不要なので、この項目も不要です。でも、将来何か指定したいときのために、空のstringを書いておきました。\nDefaultVolumeは、起動ボリューム名です。Timeoutは、Cloverのメニューが出てからユーザ入力を待つ時間です。この指定では、1秒後に自動的に起動します。XMPDetectionは、よくわかりません。eXtreme Memory Profileという機能を使うかどうかの設定です。使わないことにしています。\nDevices \u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;1\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;UseIntelHDMI\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; Audioでは、オーディオチップのレイアウトの1番を使うよう指定しました。AppleALC.kextがこの値を使います。詳しくはこちらをご覧下さい。\n/posts/120/\nHDMIは使っていないのでUseIntelHDMIは、無しでも良いのですが、将来のためにfalseを入れておきました。\nGUI Cloverの起動画面の設定です。\n\u0026lt;key\u0026gt;GUI\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Language\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;en:0\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Scan\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Entries\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;Tool\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;key\u0026gt;ScreenResolution\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;1920x1200\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Theme\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Minimalism\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; Scanは、ボリュームやUEFIツールのスキャンをするかどうか。Themeは、画面表示の色やアイコンなどの見た目の選択です。Cloverのthemesフォルダの中から、使用したいテーマのディレクトリ名を指定します。\nGraphics AMD, Intel, NVIDIAのGraphicsに関する指定です。\n\u0026lt;key\u0026gt;Graphics\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;ATI\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Intel\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;NVidia\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; AMDは使っていないのでfalseに、またNVIDIAの最近のモデルはfalseで良いとのことでそうしました。\nデフォルトでは3社ともtrueだそうですが、必要に応じて自動設定されるそうなので、ここでは何も書かなくても良かったのかもしれません。\nKernelAndKextPatches Kernelとkextへのパッチ指定です。起動時に動的にパッチを当ててくれます。これもCloverの重要機能です。\n\u0026lt;key\u0026gt;KernelAndKextPatches\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;AppleRTC\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;KernelPm\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; (省略) \u0026lt;/array\u0026gt; \u0026lt;/dict\u0026gt; AppleRTCを当てないと、スリープでUEFI設定が消えてしまいます。KernelPmはHaswellの電力制御のパッチです。不要かもしれないけど、Z97チップセットマザーボードなので、念のために入れておきました。以上は定番のパッチです。\nパッチ作業を具体的に指定したパッチを記述することもできます。それがKextsToPatchのセクションです。そういうものが必要ならば（省略）と書いた部分に書きます。以下に光ドライブのスリープ対応のパッチを紹介しました。参考にしてください。\n光学ドライブを使う\nRtVariables Runtime 変数というセクションです。Cloverの機能を指定するパラメータを書くところのようです。あまり使い道がありません。\n\u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x0\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; ここではSIPを有効にするよう指定しています。多分デフォルトで有効だと思いますので、この記述は不要だと思います。でも、将来、無効にしたいときのために書いておきました。SIPとCsrActiveConfigの値については、こちらをご覧下さい。\n/posts/132/\nsiroanko.hatenablog.com\nSMBIOS 機種固有情報を書くセクションです。40行以上あるので省略しました。シリアル番号、ファームウェアのバージョン番号などを書きます。\n\u0026lt;key\u0026gt;SMBIOS\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; (省略) \u0026lt;/dict\u0026gt; Clover configuratorを使うと、機種に合わせた値を生成してくれます。それのSMBIOSセクションをここにコピーペーストすれば良いです。詳しくは、こちらをご覧下さい。\n正しく機種設定する (SMBIOSの設定)\nSystemParameters 最近追加されたセクションです。\n\u0026lt;key\u0026gt;SystemParameters\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;InjectKexts\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;YES\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;NvidiaWeb\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/plist\u0026gt; InjectKextsは、/EFI/CLOVER/kexts/に置いたkextを使うかどうかの指定です。自動的に検出するDetectという指定も可能ですが、明示的に指定した方が安心です。\nNvidiaWebは、NVIDIAが配布しているドライバを使用するかどうかの指定です。昔は、ブートオプションで指定していましたが、Sierraからここで指定することになりました。\n","date":"2017-09-21T22:07:11+09:00","image":"/uploads/2017/09/20170917213243.png","permalink":"/posts/119/","title":"config.plistの実例紹介"},{"content":"Hackintoshで音を出すためのアプローチは、いくつかありますが、ここでは、一般的で簡単な3つの方法を難易度の低い順に紹介します。それぞれの作業量は、\n何もしない kextを1個入れる kextを2個入れてconfig.plistを1項目追加する です。\nUSBオーディオを使う マザーボード搭載のオーディオチップを利用せずに、外付けの音源でデジタルアナログ変換するアプローチです。USB接続のDAC (デジタルアナログ変換器)を搭載した、スピーカ、アンプ、アダプターなどを接続するだけです。USBの標準的なオーディオ再生プロファイルを使うので、OSレベルでサポートされています。なので、特別のドライバーは不要で、何の手を加えなくても、音が出ます。ちなみに、Bluetoothスピーカも同様な仕組みで音が出ますので実機と同様に動きます。\nUSBオーディオ製品には、USBポート直結の安いDACがあります。手軽に試せて、実現できます。いくつか購入しましたが、どれもHackintoshで問題なく使用できました。ただスリープ復帰時にボツッというポップノイズが出る製品もありました。手元の環境でたまたま調子の良かったのは、この1,000円未満の製品でした。\nUSB DAC内蔵スピーカーも各種あります。これもいくつか購入しましたが、中でもこちらの製品は価格の割に良い音でした。\nさらに手軽な値段のDAC内蔵アンプも多数あります。これをちゃんとしたスピーカに接続したらかなり良いオーディオ環境を実現できます。ピュアオーディオマニアが使うようなもっともっと高価な機器も使えます。\nVoodooHDA.kextを使う VoodooHDA.kextは、AppleのオーディオドライバであるAppleHDA.kextを置き換えることを目的に開発されているオープンソースのオーディオドライバです。これ単体で機能するドライバで、設定などがほとんど不要で、 自動的にオーディオチップを検出してくれてすぐに機能します。 一時は、クラッシュを引き起こすとか、音質が悪いとか言われていましたが、最近使ったところでは安定しているし、気になるような音質の問題もありませんでした。JeffさんのビデオでもVoodooHDA.kextを使っています。\n**追記：**とあるマシンでVooDooHDA.kextを使っていると音割れがひどいことに気づきました。調整をしてくれるアプリケーションなどもあるので、それで頑張ると良いのかもしれません。でも次節で紹介するAppleALC.kextに替えたら音割れは起きなくなりました。VooDooは簡単ですが環境によっては合わない場合があるようです。(2018/6)\n/posts/121/\nVoodooHDA.kextをダウンロードして、ESPにあるCloverのEFI/CLOVER/kextsのOtherもしくは、該当するバージョンのフォルダに入れます。これだけで機能します。ESPに入れることでmacOSをバニラなままに保てます。\nAppleALC.kextとLilu.kextを使う 3番目の方法は、昔から行われている伝統的な方法で、AppleHDA.kextに何とかオーディオチップを認識させようという方法です。そのために、AppleHDA.kextにパッチを当てたり、config.plistに必要な設定を書き込んだり、インジェクターkextを作ったり、こういう作業を自動化してくれるシェルスクリプトを走らせたり、など色々な手法があります。\nこのアプローチを格段に簡単にしてくれるのがAppleALC.kextです。これは、AppleHDA.kextにパッチを当ててくれるkextです。この開発者が、最近パッチを当てる機能を分離して、Lilu.kextという拡張機能を作りました。現在のバージョンのAppleALC.kextはLilu.kextと一緒に使います。この両方のkextをCloverのEFI/CLOVER/kextsのOtherもしくは、該当するバージョンのフォルダに入れます。AppleHDA.kextにパッチを当てないので、macOSをバニラなまま保つことができます。\nこちらにAppleALC.kextがサポートしているチップ一覧があります。最近のマザーボードで一般的なRealtek以外に、Creative, CirrusLogic, AnalogDevices, Conexant, IDT, VIA, Intelをサポートしています。 IntelはHDグラフィックスのHDMI出力をサポートしています。\ngithub.com\nここに書いてあるどのlayoutを使うかをconfig.plistに記載する必要があります。 Realtekの場合、だいたいは1で良いようです。 以下に例を示します。\n\u0026lt;key\u0026gt;Devices\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Audio\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Inject\u0026lt;/key\u0026gt; \u0026lt;integer\u0026gt;1\u0026lt;/integer\u0026gt; \u0026lt;/dict\u0026gt; ","date":"2017-09-20T20:05:42+09:00","image":"/uploads/2017/09/20170920195849.png","permalink":"/posts/120/","title":"音を出す"},{"content":"ネット上にはたくさんのインストールガイドの文章や動画がありますが、これが一番わかりやすくて見やすいと思います。9TO5Macに記事を書いているJeff Benjaminさんのビデオです。9TO5Macの記事にも連動しています。テンポが良くて、映像が綺麗です。バニラなインストール方式 なので、のちのOSアップデートが簡単です。ナレーションは英語ですが、聞き取れない箇所があったら字幕をonにすると良いです。\nHackintosh 101: the macOS Sierra step-by-step install guide\n次の手順でインストール作業を進めています。\nApple App StoreからSierraをダウンロードする インストーラが起動するので中断する USBメモリーをフォーマットする createinstallmediaコマンドを使ってUSBメモリにmacOSインストーラを入れる 必要ファイル（Clover, FakeSMC.kext, LANとAudioとgraphicsのドライバ）を入手する Cloverインストーラを起動してUSBメモリにCloverを入れる（インストール先はESPにしてバニラインストールする。OsxAptioFixDrv-64を入れる） FakeSMC.kextとLANのkextをUSBメモリに入れる インストール先のマシンにこのUSBメモリを挿す マザーボードのUEFI設定画面で必要な設定をする USBメモリから起動してSierraをマシンにインストールする USBメモリのCloverからマシンのSierraを起動する Cloverを対象マシンにインストールする。FakeSMC.kextとLANとAudioとgraphicsのkextを入れる 色々設定する。例えばブラックスクリーン問題が起きないように機種を設定する 補足 ステップ12のあたりで、マシンから起動したら大成功ですね。あとのステップは、ゆっくり調整すれば良いところです。とてもわかりやすくて、適切なガイドなのですが、補足と、ちょっとだけ気になったところを書いておきます。\nNvidia Web driverの有効化 ビデオの中ではnvda_drv=1というブートコマンドを使っていますが、最近ではこれが効かないらしいです。config.plistに以下のように書くのが良いようです。\n\u0026lt;key\u0026gt;SystemParameters\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;NvidiaWeb\u0026lt;/key\u0026gt; \u0026lt;true/\u0026gt; \u0026lt;/dict\u0026gt; OsxAptioFixDrv-64.efi ビデオでは、OsxAptioFixDrv-64.efiを使っていますが、マザーボードによってはOsxAptioFix2Drv-64.efiの方が良いこともあります。また、どっちでも起動できないことがあります。その場合は、OsxAptioFix2Drv-free2000.efiというドライバをGoogle検索して探して入れて見ましょう。これらのefiが機能しないと、macOSを最初に読み込むところで（++++マークが並んだ直後で）止まってしまいます。なお、これらのドライバを２種類以上入れるとどれが動くかわからないので、一つだけにします。\nmountコマンド ビデオの中では、mountコマンドを使ってEFIをマウントしています。mountコマンドは、UNIX起源の素朴なコマンドです。macOSが提供しているdiskutilコマンドの方が適切です。diskutil mount /dev/disk0s1 などとタイプします。この方法だとパスワードが不要です。このほか、EFIのマウントの話題はこちらもご覧ください。\nESPをマウントするためのシェルスクリプト\nLANのkext ビデオの中では、AppleIntelE1000e.kextを使っています。Ethernetのkextについて、以下の記事を書いておきました。ここにあるようにIntelのチップに対しては、AppleIntelE1000e.kextよりも、IntelMausiEthernet.kextの方が評判が良いようです。また、Intel以外のチップに対しては、それぞれに対応したkextを使います。\nEthernetを設定する\n機種設定 完璧な機種設定方法はこちらに書いておきましたので参考にしてください。ビデオで紹介されている方式は、簡易的な方式で、Jeffさんも言っていますがiMessageが動きません。\n正しく機種設定する (SMBIOSの設定)\nブラックスクリーン問題 機種を正しく設定するとブラックスクリーン問題が発生するかもしれません。Jeffさんのビデオでは、問題の発生しない機種に設定して、この問題を避けています。機種設定を正しくした上でブラックスクリーン問題を回避するには、Lilu.kextとNvidiaGraphicsFixup.kextを使ってください。こちらに解説がありました。\nwww.reddit.com\nそのほかの参考記事 インストールに関するここのブログの記事もご覧ください。\nマザーボードの設定はこちらに書いておきましたので参考にしてください。\nマザーボード (BIOS) 設定\nkextの解説はこちらです。\n/posts/126/\nCloverインストールの解説はこちら。\nCloverインストーラの設定\n","date":"2017-09-19T13:25:38+09:00","image":"/uploads/2017/09/pugSN7REHQg.jpg","permalink":"/posts/121/","title":"Jeffさんのインストールガイドビデオ"},{"content":"Hackintoshは本物のMacintoshではありませんが、macOSは本物の機種上で動いていると思い込んでいます。Macintoshの機種名によってハードウェア構成が違いますから、それに合わせた効率的な動作を行ったりする可能性もあります。またiPhoneとの連携、iMessage, iCloudなどのサービス利用の際に、機種名をチェックし、不整合があると機能を止めることもあります。\nなので、実際のハードウェア構成に近い実機のふりをして、その情報を正しく設定しておくことが重要です。\nClover Configuratorを使って設定 ハードウェアを特定する情報は、Cloverのconfig.plistの中の、SMBIOSセクションに書き込まれます。この記事では、その書き方を説明します。SMBIOS (System Management BIOS)というのは、BIOSを使っていたマザーボードにあるシステムを記述する機能です。\nSMBIOSセクションに書き込む内容を作るために、Clover Configuratorの機能が便利です。これを起動して、左のメニューからSMBIOSを選択します。右の画面で、いろいろな設定をします。\n機種を決める まずは、Macintoshのどの機種にするかを決めます。ハードウェア、特にCPUが近いものが良いです。CPUが近ければ、チップセットも同じですし、ハードウェアの動作も近いと考えられます。Macintoshの仕様を確認するためにはMactrackerというフリーウェアが便利です。\n‎Mactracker\n自作PCならば、おそらくiMacのどれかが適当だと思います。Xeonなどを使う場合は、もしかしたらMac Proかも。またIntel NUCなどで自作する場合は、Mac miniとかMacBook Airなどに同等または近いCPU搭載機種が見つかるかもしれません。\n例えば、Kaby LakeのCore i7 7700Kで自作したマシンなら、iMac18,3が最適です。\nClover ConfiguratorのSMBIOSを選ぶと現れる大きな疑問符の右下のボタンを、クリックします。すると機種一覧が出ますので、ここから目的の機種、例えばiMac18,3を選びます。\nシリアル番号を決める 最初に決めるのはシリアル番号です。左のほうに、Serial Numberと書かれた場所の番号です。\nこのシリアル番号はある規則に従って、自動生成されています。最初のアルファベットが製造地（Cは中国）で、次が年号、その年の週、その週に生産された何台めであるかの番号、機種を表す記号、などが特定の規則に従って記載されています。Generate Newというボタンを押すと、番号を生成し直してくれます。変化する部分が、週と製造番号の部分です。\n未使用のシリアル番号であることを確認 こうして生成したシリアル番号と同じ番号を持つMacintoshが実在する可能性があります。その場合、実機のユーザに迷惑をかけ、Hackintoshする事に支障が出るのではないかと、コミュニティの人たちは心配しています。そこで、実在するシリアル番号と重複しない番号を使うことが強く推奨されています。\n実存の番号と重複しているかどうかの確認方法は、簡単です。生成したシリアル番号をコピーして、以下のページにペーストします。\nCheck Your Service and Support Coverage - Apple Support\nこの結果、「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。もし、保証状況やサービス期間の案内が出るようなら、このシリアル番号は実機で使われている番号です。その場合は、別のシリアル番号を生成し直します。実際に生成してみるとわかるのですが、実存するシリアル番号に当たることはほとんどありません。\nSmUUIDを設定する SmUUID と書かれた欄が空白かと思います。UUIDはオブジェクトを一意に識別するための128ビットの数値です。例えばSSDやHDDにも付いていて、ボリュームを識別できます。ソフトウェアによってはSmUUIDで不正利用のチェックをしているようなので、一旦決めたらめったには変更しないようにしましょう。\nUUIDはターミナルを開いて、uuidgenというコマンドをタイプすると生成できます。\n$ uuidgen 97809030-7837-424E-BB69-246B934CB66D 何度か生成して、適当な番号を選べば良いです。これをコピーして、Clover ConfiguratorのSmUUIDの欄にペーストします。\nその他の値 その他の値は自動生成された値で問題ありません。\nBoard Serial NumberはMacintoshのロジックボードのシリアル番号です。適当にそれっぽい値が生成されているので、そのまま使います。Bios Versionは、High Sierraで重要になりました。APFSからの起動に対応しているかをこれでチェックし、対応していないとインストールできないようです。最新のClover Configuratorを使えば、対応したバージョンが生成されます。この他、Firmware FeaturesやFirmware Features Maskなどは機種を特定するための値です。これもHigh Sierraのインストールに必要なようです。\nconfig.plistに書き込む Clover Configuratorは設定した値を元にCloverのconfig.plistを作ってくれます。とはいえ、SMBIOSの設定しかしていませんので、中身はSMBIOSのセクションだけです。\n作った内容をconfig.plistファイルに書き出すメニューがあります。もしくは、左の一番下にある、Text Modeを選ぶと、設定に基づいたconfig.plistをテキスト形式で観ることができます。これらのSMBIOSセクションをコピーして、Cloverのconfig.plistに書き込みます。\n補足 SMBIOSのデフォルト設定 Clover r4179以降では、config.plistで以下の値：\nBiosReleaseDate BiosVersion FirmwareFeatures FirmwareFeaturesMask を指定しなくても、機種モデルの最新の値がデフォルトで設定されるようになったという情報もあります。実際にBiosVersionを削除して見たところ、それでも最新の値が使われていました。Step 2の作業の代わりに、これらの指定を単に削除して、Cloverのデフォルトに任せるのも可能かと思われます。\nhttp://www.insanelymac.com/forum/topic/304530-clover-change-explanations/page-4#entry2482211\n(2019/4/10 加筆）\nさらに、最近のCloverでは、SMBIOSのかなりの部分を自動的に作ってくれるようです。ファームウェアバージョンなどを最新にしてくれるようなので、config.plistで指定しない方が良いかもしれません。ということで以下の4種類、\nBoardSerialNumber ProductName SerialNumber SmUUID を指定しておくだけで良いらしいです。\n","date":"2017-09-18T19:52:05+09:00","image":"/uploads/2017/09/20170917213243.png","permalink":"/posts/122/","title":"正しく機種設定する (SMBIOSの設定)"},{"content":"5.25インチベイに取り付ける取り外し可能なHDDケース 今のMacintosh製品には5.25インチベイが無いです。最近の自作PCケースも、5.25インチベイの無い製品が増えていますが、あれば色々便利です。中でも、簡単に5.25/2.5インチドライブを取り付け・取り外しできるリムーバブルディスクケースは便利だと思います。自作していれば、小容量の古いHDD/SSDが余ってしまいがちです。それが簡単に取り付けられるリムーバブルケースがあれば、大容量のデータを高速にコピーして持ち運ぶとか、新しいバージョンのOSを実験的にインストールするとか、いろいろな場面で便利に使えます。\n市販の製品 5.25インチベイ自体が廃れ始めているので、製品もひところに比べたら少ないですが、いくつかあるようです。5.25インチと2.5インチの両方が入る製品が多いようです。隙間にUSBコネクタを装備している製品とか、光学ドライブも入れられる製品もあります。ちなみに、大は小を兼ねるので、5.25インチが一台だけしか入らないケースも、工夫すれば2.5インチもなんとかなります。\nHDD/SSDのSATAコネクタは、なんども抜き差しする前提で設計されていないので、壊れやすいと言われています。ちゃんとしたサーバで使うホットプラグケースでは、強度の高いコネクタ付きトレイを用意してHDDをネジ止めする構造になっています。でも、素人がちょっとした実験で抜き差しするくらいなら、全然問題ありません。ねじ止めしなくても取り付けられるケースが楽です。\nまたこれらの製品は、ホットプラグ対応を謳っています。電源を入れたまま、HDD/SSDを抜き差しできるという意味です。ただし、これは電気的に問題を起こさないという意味であって、マウントしたままいきなり取り外すと当然ですがデータが損傷する可能性があります。非マウント状態にしてから抜き差しする必要があります。\nホットプラグなドライブアイコン ドライブはmacOSでいろいろなアイコンで表示されます。一般的なHDD/SSDは銀色のアイコンです。ちょっと古い感じのハードディスクの形です。USBメモリーは白いアイコンで表示されます。スリットがあるので、光学ドライブの絵なのかもしれません。また、取り外し可能なHDDなどはオレンジ色のアイコンで表示されます。取り外し可能なドライブアイコンの隣には、イジェクトアイコンが表示されていて、これを押すとアンマウントされます。\n上で紹介したリムーバブルケースは、取り外し可能なディスクなので、イジェクトマークのあるアイコンになるべきです。でも、USB接続と違い、リムーバブルケースからマザーボードへは内蔵ドライブと同じSATAケーブルで接続します。マザーボードから見たら、SATAコネクタが内部のHDDに接続されているか、もしくはリムーバブルHDDケースに接続されているのかの区別はつきません。人手で指定する必要があります。\nいくつかのマザーボードではデフォルト設定として、インテルのチップセットに接続されたドライブを内部ドライブ（銀色アイコン）にしています。一方で、チップセットのSATAに加えて追加SATAチップを搭載して、SATAの数を増やしている場合、追加のSATAチップに接続されたドライブはリムーバブルボリュームに設定されていることが一般的です。でも全てをホットプラグ対象とみなすマザーボードも中にはあります。こうした割り当てで、内蔵ドライブがオレンジ色のアイコンになってしまうことがあります。それが嫌な人のために、 AHCI_3rdParty_eSATA.kextや AHCI_Intel_Generic_SATA.kextといったkextが用意されていました。これらのkextの主な目的は、オレンジ色のアイコンを銀色に戻すことです。ただ、これらのkextは最近のmacOSでは機能しないことが多いので、あまり使われなくなりました。\nBIOSでホットプラグを設定 マザーボード搭載のSATAに接続したドライブがリムーバブル（ホットプラグ）なのかどうかは、BIOS設定で指定します。下はMSIのマザーボードの例です。\nこの機能で、それぞれのSATAコネクタに接続されているドライブが、固定ドライブなのか、ホットプラグさせるドライブなのかを設定します。これが一番理想的ですね。この方式ならば、オレンジアイコンの割り当てを正しく行うことができます。ただし、後述するように、BIOSでホットプラグに設定しても、macOSで必ずしもオレンジアイコン表示にはならない場合もあるようです。\nなお銀色アイコンで、イジェクトマークがついていないドライブでも、ゴミ箱方向へドラッグ\u0026amp;ドロップすればアンマウントできます。また、ディスクユーティリティを使ってもアンマウントできます。ターミナルから、diskutil unmount /dev/disk… としてもアンマウントできます。\nただ、銀色アイコンとして認識されているSATAドライブは、起動時に接続されていなければ認識されません。macOS起動後に接続しても認識されません。また、起動時に接続されてマウントされても、その後で一旦アンマウントしたら、もう一度接続しても認識されません。なので、リムーバブルケースで接続する場合は、オレンジ色のアイコンで認識されないととても不便です。\nmacOSでホットプラグ BIOSレベルでホットプラグに設定しても、macOSでオレンジアイコンにならない場合があります。銀色アイコンの状態では、起動時にはマウントしますが、ホットプラグによりマウントしてくれない状態になります。SATAチップの種類、マザーボード、macOSのバージョンなどで対応が異なるようです。\nZ97マザーボード＋Sierra以前 この記事を最初に書いた時点では、MSIのZ97チップセットマザーボードでSierraで動かしていました。BIOSのホットプラグ設定をすると、macOSでもオレンジアイコンになりホットプラグでマウントされ、安定に動作していました。\nZ97マザーボード＋High Sierra以降 不安定です。High Sierraになった時点で、BIOSで設定しても銀色アイコンのままのこともあり、動くこともあるようです。ASUS ROG MAXIMUS XI HERO (Z390)マザーボード＋Catalinaの組み合わせでは、BIOS設定のホットプラグが正しくオレンジアイコンに表示されることも何度かありました。その時は、スリープしても問題ありません。でも何度も起動して確認すると、マウントされないこともあります。\nPCIe拡張SATAカード + Catalina 以前、macOSと互換性のあるPCIe拡張SATAカードをご紹介しました。\nPCIe拡張カードでSATAを増設する\n追記：以下の方法では、マウントする際にBig Surが落ちることがありました。後述する長いパターンのパッチを当ててください。ASMediaやMarvellのチップでもホットプラグ可能です。\nこれらのカードの場合、こちらで紹介されているように、\nFind --\u0026gt; 40600200 Replace --\u0026gt; 00000000 AppleAHCIPort というパッチを当てれば、ASMediaやMarvellのチップでホットスワップできるようです。元のサイトの説明では、SATAポートデュプリケータの不具合に対応するパッチらしいですが、ホットプラグ問題も解決するようです。具体的には、config.plistに\n\u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;ALPM IO Error AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;QGACAA==\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;AAAAAA==\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; を追加します。QGACAA==が40600200で、AAAAAA==は00000000です。これでホットスワップが動くようになり、スリープしても大丈夫でした。Marvell 88SE9230チップセットによるカードと、ASMedia ASM1061チップセットカードの両方で動作を確認しました。\nZ390 + Catalinaのパッチ コメントでまっくぷろさんからいただいた情報によると、こちらで紹介されているパッチもしくはその変形を使うと、Z390チップセットのSATAをホットプラグ対応にできるようです。\nFind --\u0026gt; 89C82540 6002003D 40200000 750C81E1 BF7FFFFF 898B5101 0000 Replace --\u0026gt; 90909090 90909090 90909090 90909090 90909090 90909090 9090 AppleAHCIPort または、\nFind --\u0026gt; 81E24060 020081FA 40200000 750C81E1 BF7FFFFF 898B6901 0000 Replace --\u0026gt; 90909090 90909090 90909090 90909090 90909090 90909090 9090 AppleAHCIPort のようです。これに対するBase64文字列を、上で紹介したように、config.plistのKextsToPatchセクションに書き込んでおけば良いようです。\nこのパッチのいずれでも動かないようでしたら（もしくは将来のmacOSバージョンで動かなくなったら）、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをバイナリーサーチして40200000を検索して、その前後から上記のようなパッチを作れば良いようです。例えば以下のようにします。10.15.3での実施例です。まずはバイナリーをhexdumpしました。\nhexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less lessの中で、サーチコマンド\n/40 20 00 00 をタイプし、40 20 00 00を探します。\n00029a0 73 0e 81 ca 40 80 00 00 89 d1 89 93 69 01 00 00 00029b0 89 ca 81 e2 40 60 02 00 81 fa 40 20 00 00 75 0c 00029c0 81 e1 bf 7f ff ff 89 8b 69 01 00 00 f6 c1 40 74 00029d0 7e 3d 09 01 01 00 72 77 44 89 fa c1 ea 0a 81 e2 この方法では、運悪く改行にかかっているとデータ列が見つからない可能性はありますが、首尾よく発見できました。他には存在していないようです。ということで、まっくぷろさんの情報と同じく、40 20 00 00を挟んだデータ列をNOP (90) に置き換える\nFind --\u0026gt; 81E24060 020081FA 40200000 750C81E1 BF7FFFFF 898B6901 0000 Replace --\u0026gt; 90909090 90909090 90909090 90909090 90909090 90909090 9090 AppleAHCIPort というパッチで良いようです。base 64に変換します。詳しくはこちらをご覧ください。\necho -n \u0026#34;\\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\u0026#34; | base64 geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA= ちなみにNOPコマンド列である9090…の方は、\necho -n \u0026#34;\\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\u0026#34; | base64 kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA= です。なのでconfig.plistには\n\u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;Enables hot plug for removal drives\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Disabled\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;InfoPlistPatch\u0026lt;/key\u0026gt; \u0026lt;false/\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;AppleAHCIPort\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; を追加します。これでBIOSでホットスワップ指定したチップセットSATA接続ドライブがオレンジ色アイコンになり、随時マウント・アンマウントできるようになりました。またスリープしても問題ありませんでした。\nつづき 上記のパッチをOpenCoreのconfig.plistで当てる方法を以下で紹介しました。\nリムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する\nまた、Big Sur対応のパッチを以下で紹介しました。\nリムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)\n結論 ホットプラグできるリムーバブルベイは便利です。チップセットSATAの場合は、BIOSでホットプラグを設定します。それでもmacOSにホットプラグ対応と認識されない場合は、AppleAHCIPort.kextにconfig.plistでパッチを当てます。手元の環境 (ASUS Z390 + Catalina) では、MarvellのSATA拡張カードを使っているので、拡張カード用のパッチを当てることにしました。\n","date":"2017-09-17T12:18:24+09:00","image":"/uploads/2017/09/20170926165208.png","permalink":"/posts/123/","title":"SATA接続HDD/SSDのホットプラグ"},{"content":"Ethernetを動かすkext マザーボード搭載やPCIeカード搭載のEthernetチップは大体がサポートされています。Linux用のドライバを元に移植されているようです。最近のマザーボードでは、IntelかAtherosのチップが多いです。マザーボードを購入する場合は、以下のkextがサポートしているEthernetチップを、そのマザーボードが搭載していることを確認すると良いです。\nQualcomm Atheros Miezeさんが作っているAtherosE2200Ethernet.kextを使います。最近のマザーボードに搭載されているKiller E2500がサポートされています。AR816x, AR817x, Killer E220x, Killer E2400, Killer E2500が動きます。\nIntel 最近のマザーボードでは、Intel i219-VやIntel I211ATが搭載されています。いくつかのドライバが用意されています。調子よく動くものを使用すれば良いと思いますが、IntelMausi.kextが一般的に使われていてお勧めです。\nAppleIntelE1000e.kext hnakさんが開発しています。Intel 825xx シリーズをサポートしています。\nAppleIGB.kext これもhnakさん。Intel 82575, 82576, 82580, dh89xxcc, i350, i210, i211をサポートします。\nIntelMausi.kext Miezeさんのドライバで200シリーズに対応しています。オリジナルを、RehabManさん、acidantheraさんらがforkして開発しています。 82578LM, 82578LC, 82578DM, 82578DC, 82579LM, 82579V, I217LM, I217V, I218LM, I218V, I218LM2, I218V2, I218LM3, I219V, I219LM, I219V2, I219LM2, I219LM3をサポートしているとのことです。もともとはIntelMausiEthernet.kextという名前で配布されていましたが、それから枝分かれしてIntelMausi.kextができました。IntelMausi.kextのほうがサポート継続されているらしく、おすすめのようです。\nRealtek Miezeさんが作っているRealtekRTL8111.kextを使います。最近のマザーボードに搭載されている8111Hがサポートされています。\nEthernetの設定 上記のkextが対応しているEthernetチップなら、kextをCloverのkextsディレクトリに入れておくだけで機能します。\nもう一つ注意しておくべき設定があります。それはEthernetがen0に割り当てられる必要があることです。Unixマシンは、ネットワークアダプタにen0, en1, en2と番号を振って管理しています。macOSではOSが発見した順番にen0から番号づけられています。実際のMacintoshでEthernetを持っている機種はEthernetがen0です。WiFiだけの機種はWiFiがen0です。このように割り振られていない場合に、Apple App Storeに接続できなかったり、iMessageが使えなかったりします。\n他のネットワークアダプタが有効になった後で、Ethernetのkextをインストールして動かした場合などは、Ethernetがen0以外の番号に割り振られてしまいます。なので、「リンゴマーク」「このMacについて」「システムレポート」で開くシステム情報の、「ネットワーク」リストを選んで、Ethernetがen0であることを確認しましょう。\nもしen0では無い場合は、以下のファイルを消して、再起動すればen0になります。(もしくはこの中にあるenXという文字をすべてen0にしても良いです。)\n/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist ","date":"2017-09-16T21:59:36+09:00","image":"/uploads/2017/09/20170916220154.png","permalink":"/posts/125/","title":"Ethernetを設定する"},{"content":"改定：2018/9/15\nkextとは kextとはKernel EXTension（カーネル拡張）の略で、カーネルと呼ばれるOSの本体を拡張する一連のファイルです。OSに必要とされる機能が増加し、いちいちカーネルに組み込んでいると管理が大変になったので、別ファイルにして必要に応じて組み込むことになりました。macOSに限らず、多くのOSで一般的な方式です。ネットワーク、グラフィックス、サウンドなどのハードウェアを動かすデバイスドライバの機能も、kextとして提供されています。\nHackintoshのためには、Hackintoshを実現するためにmacOSの機能に手を加えるkextや、実機でサポートされていないハードウェアを動かすためのkextなどが開発されて、配布されています。必要なものを集めてHackintoshにインストールします。\nkextの置き場所〜macOSの場合 macOSでは、kextを/System/Library/Extensions/ (/S/L/Eと略されます）もしくは、/Library/Extensions/に置きます。/S/L/Eに置くkextは、SIPで署名チェックされます。なので、当然ながら署名のないHackintosh用のkextを加える場合、SIPをdisableにする必要があります。\n/posts/132/\nkextは、実はファイルではなくてディレクトリです。macOSのファインダーからファイルのように見えているだけで、中には、多数のファイルが含まれています*1。これらのファイルの全てがカーネルから実行できるように、パーミッションが正しく設定されている必要があります。また、kextを起動のたびにkextファイルから読むと時間がかかってしまいます。そこで、キャッシュして高速化を図っています。なので、新しいkextを加えるためには、単にディレクトリにコピーするだけでなく、中身のすべてのファイルのパーミッションを正しく設定して、キャッシュを作り直さないといけません。この作業をGUIで実行するツールも配布されています。\nkextの置き場所〜Cloverの場合 kextの追加をCloverにお任せすれば、前節のややこしそうなkextインストールの手間は無関係です。EFI/CLOVER/kextsの中にkextを入れておくとCloverが追加してくれます。SIPはenableのままで大丈夫です。またパーミッション設定もキャッシュ作り直しも不要です。ディレクトリに入れるだけです。以前は、kextによっては（例えばLANのkext）/S/L/Eに入れないと機能しないこともありましたが、最近では、ほとんどのkextがCloverのディレクトリに置いても問題なく機能します。それでも依然として、/S/L/Eに置かないと機能しないkextも稀にありますので、その場合は試行錯誤して確認してください。\nEFI/CLOVER/kextsは、macOSのルート、もしくはボリュームのESPのどちらかにあります。デフォルトはmacOSのルートですが、その場合、macOSをまっさらに入れ替えると消えてしまいます。ESPにおいてあれば、アップデートで変更されないので管理が容易です。ESPにCloverをインストールする方法は、バニラインストールとも言われます。以下で説明してあります。\n/posts/131/\nEFI/CLOVER/kextsの中には、macOSのバージョン番号のディレクトリと、Otherという名前のディレクトリがあります。Cloverは、\nまず、Otherに入っているkext 次に、該当するバージョン番号のディレクトリに入っているkext の順番で、kextをインストールします。この後はmacOSに引き継がれて、/L/E、/S/L/Eの順にkextがインストールされます。同じ名前のkextがあったとしたら、後からインストールされた方が優先します。\nkextは、該当するバージョン番号のディレクトリに入れておいても良いです。もしくは、バージョン番号のディレクトリは使わない（空にしておく、もしくはそもそもディレクトリを作らない）でOtherに全部入れておいても良いです。両方に入れても良いですが、混乱しやすいかもしれません。皆さんのやりやすい方法で管理すれば良いです。\nFakeSMC.kext kextはたくさんありますが、FakeSMC.kextは、Hackintoshするために唯一で必須のkextです。SMCはSystem Management Controller（システム管理コントローラ）の略です。昔は、PMU (Power Management Unit)と呼ばれていました。Macintoshの電力をコントロールしたり、ハードウェアをコントロールするサブシステムです。メインのCPUとは別に、SMCと呼ばれるマイクロコンピュータが内蔵されていて、それがハードウェアの管理を仕切っています。Macintosh独自のもので、ATXマザーボードには（もちろん近いものは搭載されていますが、同一のものは）搭載されていません。でもmacOSはSMCがあるものと思って働きかけてきます。そこで、SMCのふりをするフェイクのSMCを実現するのがFakeSMC.kextです。\nNullPowerManagement.kext 現代のCPUは、負荷によって動作周波数を変更したり、スリープをしたりして、消費電力を制御しています。この結果、省電力を実現し、発熱量を減らしています。搭載しているCPUがどのように電力制御を行うかの情報は、マザーボードからACPIテーブルを介してOSに伝えられます。ただ一般のマザーボード使用を想定していないmacOSには、この情報が正しく伝わらないことがあります。そもそも実機で採用されていないCPUの場合には、macOSで対応することができないこともあります。CPUの電力制御が正しく行えない場合、macOSがカーネルパニックを引き起こして起動しないこともあります。\nmacOSでCPUの電力制御を担当しているkextは、AppleIntelCPUPowerManagement.kextです。NullPowerManagement.kextはこのkextを無効にします。その結果、電力制御関連の設定が正しく行われていなくても、とりあえずはHackintoshが起動するようになります。なので、tonymacx86で配布されているインストール用USBメモリ (UniBeast)などのインストーラではこのkextが使われます。\n起動してくれるのはありがたいのですが、電力制御が行われないので、CPUは最大出力で稼働し続けます。そこで、DSDT, SSDT, config.plistなどを正しく設定してこのkextがなくても起動するように調整することが、Hackintosh作りの一つの目標になります。\nこのほかのkext このほかの主なkextには、\nEthernetを動かすためのkext サウンド関係のkext USB関係のkext グラフィックス関係のkext などがあります。これらは、該当するハードウェアを機能させるためのkextです。そのハードウェアが原因のトラブルを解消する機能を持ったkextもあります。FakeSMC.kext以外のkextは、絶対に必要というものではなくて、必要に応じてインストールすれば良いものです。それぞれのハードウェアの話題のところで説明していこうと思います。\nkextの探し方 Hackintoshに必要なkextは、その名前で検索すると開発サイトや配布サイトが見つかります。また、KextUpdater.appを使うと、現在使用しているkextの最新版をチェックしてダウンロードしてくれます。また主要なkextを個別にダウンロードすることも可能です。\nワンクリックで最新kextに〜Kext Updater.app (Ver. 2)\n*1:macOSのアプリケーション、.appも同様にファイルではなくてディレクトリです。\n","date":"2017-09-15T23:23:26+09:00","image":"/uploads/2017/09/20170915223211.png","permalink":"/posts/126/","title":"Hackintoshのためのkext入門"},{"content":"\nmacOSの良いところはたくさんあります。インクリメンタルバックアップのTime Machineが、OS標準でサポートされていることも、他のOSにない、大きなメリットです。Time Machineのおかげで何度も助けられました。\nスタイリッシュなMacintoshと違って、いくらでもHDDを内蔵できる無骨な自作Hackintoshなのですから、是非ともTime Machine専用のドライブを搭載して、Time Machineを動かすべきです。内蔵ドライブにバックアップすれば、ネット越しよりも高速にバックアップできます。なので、OSがバックアップ作業をしていることに気づくことは滅多にありません。快適です。\n今だと、3TBの3.5インチHDDが一番お得な製品です。これを1台内蔵して、全部をバックアップ領域にしてはどうでしょうか。バックアップメディアが大きいほど、過去のデータに戻れます。目安としてはオリジナルデータの2-4倍あると良いらしいです。\nTime Machine用ドライブの活用 単純に全部をバックアップ領域にしても良いです。\n3TBの3.5インチHDDの全体をTime Machine領域にする でも、3TB HDDのESP領域は何にも使われていません。それなら、このHDDのESPにCloverとkextなど、メインボリュームのESPと同じものを入れるのも良いと思います。Hackintoshしていると、「メインボリュームのESPに手を入れていたら、起動しなくなってしまった」というピンチを一度は経験します。間違った設定を元に戻したくても、起動しないので作業ができないという状況です。ESPのバックアップがあれば、そんな時にもあわてなくてすみます。マザーボードのUEFI設定で起動ドライブをTime Machineのドライブにすれば良いのです。\n3TBの3.5インチHDDのESPにメインのESPをバックアップする 残りの領域をTime Machine領域にする ESPは、内蔵HDDだけでなく、当然ながら外付けのHDDやUSBメモリにもバックアップしておけます。でも内蔵ドライブにバックアップしておくと、紛失する心配がありません。間違いなく必ず筐体の中にあって、どこかに行ってしまうことはありませんから。\nまた、3TB HDDに60GBくらいのパーティションを作って、ここにmacOSもバックアップして置くと、さらに安心です。\n3TBの3.5インチHDDのESPにメインのESPをバックアップする 頭に60GBくらいのパーティションを作ってここにmacOSをバックアップする 残りの領域をTime Machine領域にする ","date":"2017-09-14T23:46:39+09:00","image":"/uploads/2017/09/20170914233137.png","permalink":"/posts/128/","title":"Time Machineは良いです"},{"content":"\nClover UEFI Bootloader Hackintoshする方法はいくつかありますが、現在、一番ポピュラーなのは、Cloverブートローダを使う方法です。Cloverの本体は、コンピュータが起動した時に真っ先にブートされるBOOTX64.efiというファイルです（UEFI起動の場合）。\n検索すると、tonymacx86サイトで配布しているUniBeastとかMultiBeastを使った方法が多数見つかりますが、これらもCloverを使っています。MultiBeastは、Cloverをインストールして、kextをインストールして、Cloverの設定をメニュー形式で行ってくれるツールなのです。\nその大元の、Cloverにもインストーラはあり、Cloverの動作に最低限必要なファイルをインストールする機能があります。設定ファイルのカスタマイズや、kextファイルのインストールはやってくれません。しかし、そういう作業はインストーラ任せにしないで、手動で行った方が、システム構成を把握できます。その結果、トラブルにも対応できるようになります。なので、Cloverのインストーラを使う方法をお勧めします。\nこの記事では、Cloverのインストーラでカスタムインストールする方法を説明します。\nインストール先の指定 デフォルトでは以下のような設定になります。以前にCloverをインストールしたことがあるボリュームを対象とした場合は、最後に指定した設定が表示されます。\n最初に、ドライブのどこにインストールするかを決めます。デフォルトのBootloaderというメニューでは、MBRのある昔ながらのBIOS方式がデフォルトです。ここは是非、Cloverの強みが活かせるUEFIブートにしておきましょう。また、EFI System Partition (ESP)にインストールするよう選択しておきましょう。バニラなインストールが可能になります。\nテーマなんて飾りです テーマは、Cloverの起動ドライブ選択画面のデザインを変えるところです。指定しなくても良いですが、インストールするドライブごとに違うテーマを指定しておくと、どれで起動したかがわかって役に立ちます。テーマは、いろいろな人がデザインして配布しています。好きなものを選ぶと良いです。こんなシンプルなのはいかがでしょう。\nDrivers64UEFI 次に選択すべきはDrivers64UEFIの中身です。ここには、OSが起動する前の、UEFIの環境で動作するプログラムが並んでいます。ここにリストされている以外の、必須のプログラムは、ここでの選択とは別に、自動的にCloverのディレクトリに入ります。\n選んでおかねばならない一つは、メモリーを確保する際に生じる問題を修正するドライバです。これらのドライバは、macOSが起動する初期段階で、カーネルを読み込む前に動作します。正しく機能しないと、Couldn’t allocate runtime areaというエラーを出して停止してしまいます。選択肢は、\nAptioMemoryFix.efi OsxAptioFix3Drv-64.efi OsxAptioFix2Drv-64.efi OsxAptioFixDrv-64.efi OsxLowMemFixDrv-64.efi です。必要なのは、このうちの1つだけです。このリストの複数を選択してはいけません。番号は、推奨する順番です。この順番に入れてみて、ちゃんと起動すればそれを使うのが良いです。できれば1か2が望ましいです。Clover開発チームのSliceさんによる説明が、こちらにあります。\nwww.insanelymac.com\nそれによると：\nOsxAptioFixDrv-64.efi と OsxAptioFix2Drv-64.efi は、Clover 4368 以前に作られて、NVRAMサポートしていません。歴史的経緯で残されています。高位アドレスにワープしたメモリマップでは、OsxAptioFixDrv-64.efiだけが動くこともあります。 OsxAptioFix2Drv-64.efi は、メモリブロックの配置変えを行わない機能削減バージョンです。いくつかのハードウェアや古いOSバージョンでは動かないかもしれません。しかし、OsxAptioFixDrv-64.efiに比べると、こちらはハイバーネーションをサポートしています。 OsxAptioFix3Drv.efi は、Clover 4369でOsxAptioFix2Drv-64.efiから改変されたバージョンです。これはNVRAMをサポートします。Clover 4379ではランタイムの不具合が解消されました。Clover開発チームは今後、このバージョンだけを改良していきます。 AptioMemoryFix-64.efi は、サードパーティメモリ修正ドライバをそのまま使っています。そのため、色々手を加えているOsxAptioFix*Drv-64.efiシリーズよりもたぶん優れています。まずは、AptioMemoryFix.efiが動くかどうかを試すべきです。 OsxLowMemFixDrv-64.efi は、やはりメモリ修正ドライバですが、Clover 608から改良されていません。 ということで、動くならばAptioMemoryFix-64.efi が一番のおすすめのようです。また、ごく一部のマザーボードは、上記のいずれもダメで、 OsxAptioFix2Drv-free2000.efi が必要な場合もあります。\nこの他、マザーボードによっては、EmuVariableUefi-64も必要になります。MacintoshにはNVRAMがあって電源をoffにしても一部の設定が保存されています。同様の仕組みはUEFIマザーボードにもあります。ただ、それがうまく動かない場合があります。EmuVariableUefi-64はNVRAM機能をエミュレートしてくれるプログラムです。\n他は非選択でok 他の項目は大体非選択で大丈夫です。「Clover環境設定をインストール」は、システム環境設定にCloverの項目を入れてくれるオプションです。Cloverのアップデートチェックをしてくれるので、チェックを入れておいても良いかと思います。\nインストール後のディレクトリ構成 最終的には、以下のようなディレクトリ構造がESPに作られます。ここでは、Cloverインストーラがインストールしたefiファイルに加えて、High Sierraで必要になったAPFSブートのためのefi, apfs.efiが追加されています。また、OsxAptioFix2Drv-64の代わりにOsxAptioFix2Drv-free2000がインストールされています。\n","date":"2017-09-13T17:08:34+09:00","image":"/uploads/2017/09/20170916220921.png","permalink":"/posts/129/","title":"Cloverインストーラの設定"},{"content":"High Sierraは9月26日に登場 昨夜の発表では、Macintoshはおろか、間も無く登場のmacOSも紹介されなくて寂しい限りです。でもアップルのサイトには、macOS High Sierraの発表日がひっそりと掲載されています。9月26日だそうです。あと、13日ですね。それまでに、あなたのHackintoshに新バージョンをお迎えする準備をしておきましょう。\nドライブを用意 今使っているメインのドライブにいきなりHigh Sierraを入れるのは、多分問題なく動くと思いますが、さすがにチャレンジングです。使っていないドライブを用意しておきましょう。HDDでも良いですが、古いSSDでもあれば尚良いです。動かすには30GBくらいあれば十分です。自作マシンなら、マザーボードにSATAケーブルで接続すれば良いです。最近は、USB 3.0接続のUSBメモリーで高速なものもありますので、下手なHDDよりずっと速いかもしれません。それでもokだと思います。\nCloverを最新版に更新 最新版なほど安心です。現時点での最新版のリビジョンは4200です。古いようなら更新しておきましょう。\nkextファイルを最新版に更新 開発者の皆さんがベータ版を使ってHigh Sierra対応を進めてくれています。使っているkextファイルの最新版が出ていないかどうか確認しましょう。kextファイルの名前でGoogle検索すれば良いです。全部最新版に更新しておきましょう。\nまた、kextをEFI/CLOVER/kexts/10.12に入れている人は、10.13を新たに作って、全部のkextをコピーしておきます。もしくは、Otherフォルダにコピーしておいても良いです。10.13で起動する場合は、Otherの内容が先に読み込まれ、次に10.13フォルダが読み込まれます。10.12のフォルダの内容は無視されてしまいます。\nconfig.plistのSMBIOS情報を更新 High Sierraのアップデートでは、APFSでも起動できるようにファームウェアがアップデートされます。ファームウェアが対応版にアップデートされていないと判断されると、インストールが止まってしまうようです。そこでconfig.plistのSMBIOSセクションのBIOSバージョンの記述を、最新版ファームウェアと同じバージョン番号に書き換えておきましょう。また、Firmware FeaturesとかFirmware Features Maskという謎の情報がSMBIOSにないとインストールできなかったという報告もあります。config.plistにこの記述がなかったら、これも設定しておきましょう。\n書き換えるべき情報は、機種ごとに違います。これを簡単に確実に知る方法の一つは、Clover Configuratorを使う事です。\nmackie100projects.altervista.org\nこれをダウンロードして、左のリストからSMBIOSを選びます。右の疑問符のところをクリックして現れるポップアップメニューから、自分が設定している機種名を選びます（下の写真では疑問符が消えてiMacの写真に変わっています）。すると必要な数値を自動的に作ってくれます\nこの結果を、Save As…でconfig.plistファイルに書き出します。書き出したconfig.plistにはSMBIOSのセクションの記述しかありません。これを見ながら、現在のconfig.plistで足りない記述を書いていきます。 更新、追記しないといけない項目は、以下です。これはiMac18,3の場合の例です。\n\u0026lt;key\u0026gt;BiosReleaseDate\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;08/08/2017\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;BiosVersion\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;IM183.88Z.0151.B00.1708080034\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;FirmwareFeatures\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0xFC0FE136\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;FirmwareFeaturesMask\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0xFF1FFF3F\u0026lt;/string\u0026gt; これ以外の情報、例えば、シリアル番号とかUUIDなどは、現在の値を引き続き使います。書き換えてしまうとiMessageなどの動作に支障をきたすかもしれません。\nSMBIOSの設定についてはこちらでも解説しておきました。\n正しく機種設定する (SMBIOSの設定)\n起動できることを確認 以上の変更を一つずつ行い、その度に起動できるかどうか確かめていきましょう。全部が最新版に更新されて、config.plistの記述が完全になるので、High Sierraにアップデートしないとしても、良いメンテナンス作業になります。\nこれでHigh Sierraを迎える環境は整いました。待ちきれないようでしたら、新しいドライブをディスクユーティリティでフォーマットして、今のドライブから新しいドライブにESP部分を複製して、Cloverが起動するようにしておいても良いでしょう。\n","date":"2017-09-13T14:28:32+09:00","image":"/uploads/2017/09/20170913125758.png","permalink":"/posts/130/","title":"あと13日！High Sierraのお迎え準備"},{"content":"macOSをインストールしてHackintosh をつくる方法、流儀、ツールはいくつかあります。ここでは、一番おすすめの、バニラな方法を紹介します。macOSをできる限りオリジナルなままに保ってインストールする方法です。バニラというのはVanillaアイスクリームのバニラで、チョコレート味とか抹茶味みたいに手を加えてない、素材のままという意味です。\nバニラな方法では、macOSが入っているメインのパーティションの内容には一切手を加えないで、実機と全く同じ状態にしておきます。この方法では、カーネルやカーネル拡張（kextファイル）を書き換えません。HackintoshのためのkextファイルもmacOSパーティションには追加しません。\nバニラのメリット バニラな構成では、macOSメインのパーティションは本物のMac（実機）と同一です。なので、Hackintoshのドライブを本物のMacに取りつければ、そのまま起動します。macOSから見ると、このパーティションが世界の全てです。なので、macOSのバージョンアップをした時、書き換わるのもmacOSが入っているパーティションだけです。この部分に手を加えていると、バージョンアップのたびに対応し直す必要があります。しかしバニラに保っておけば対応の必要が無く、実機と同じようにApp Storeからバージョンアップするだけでの簡単な操作で行えます。\nmacOSのインストール手順 macOSをバニラにインストールする一般的な手順を書いておきます。Hackintoshに必要なファイルを、macOSメインパーティションではなく、ESP (EFI System Partition)に置くのがポイントです。\nボリュームをディスクユーティリティでフォーマットする 通常のインストーラを使ってmacOSをインストールする Clover EFI BootloaderをESPにインストールする Cloverの設定ファイルconfig.plistを目的に応じてカスタマイズする 必要なkextファイルを集めてESPのkext用フォルダに入れる 手順1と手順2は、通常のmacOSインストール手順です。実際のMacintoshにmacOSをインストールするのと同じ手順です。実機ならばm.2/SATA/USBなどで接続したボリュームをフォーマットしてそこにインストールします。Hackintoshならば、macOSインストーラが起動するUSBメモリを以下の手順：\nHigh Sierra導入用USBメモリ作成方法\nで作成して、これで起動して、ディスクユーティリティ.appを使って対象ボリュームをフォーマットして、macOSインストーラを使ってインストールします。\n手順4と手順5は、macOSとHackintosh用ブートローダのCloverをインストールした後の、「ポストインストール」とも呼ばれる作業です。Hackintoshが正しく動くようにする作業で、色々なノウハウが必要です。手順3、手順4、手順5は、以下の記事を参照してください。\nCloverインストーラの設定\n手順3は、macOSをUEFIマザーボードで起動させるためにUEFIブートローダであるCloverをインストールする手順です。Cloverはオープンソースで開発されているツールです。\nCloverのインストーラでは、Hackintoshに必要なファイルを置く場所を選択できます。一つの選択肢は、macOSが入っているメインパーティションのルートです。もう一つは、EFIシステムパーティションです（頭文字でESP）。\n前者の場合、macOSのパーティションにファイルを追加するので、バニラに保つポリシーからは外れます。\n後者でファイルが追加されるESPは、macOSでドライブをフォーマットすると自動的に作ってくれるパーティションの一つです。UEFIマザーボードが起動するときに使用するファイルが置かれる場所です。しかしmacOSはこのパーティションを使用しません。なので、ESPにHackintoshに必要なファイルを全て置けば、バニラなインストールが実現できます。\nESPを利用するためには、Cloverのインストーラで、カスタムインストールを選択し、「ESPにインストール」にチェックマークを付けます。\nこの記事の以下では、\nフォーマット後に出来上がるパーティション構成と、 バニラを目指してCloverをインストールした後のESPの内容 を説明します。\nバニラなディスク構成 バニラな方法で使用するESPは、macOSでドライブをフォーマットすると自動的に作ってくれます。試しに、ディスクユーティリティを使って120GBのSSDをまっさらにフォーマットしてみました。ターミナルからdiskutil listとするとフォーマット後のパーティションの一覧が出てます。例えば以下のようになります。これは全てディスクユーティリティが作ってくれるパーティションです。ただし、メインのパーティション名は、フォーマットの時に指定します（ここではMacintosh HDとしました）\n/dev/disk0 (internal, physical): #: TYPE NAME SIZE IDENTIFIER 0: GUID_partition_scheme *120.0 GB disk0 1: EFI EFI 209.7 MB disk0s1 2: Apple_HFS Macintosh HD 119.2 GB disk0s2 3: Apple_Boot Recovery HD 650.0 MB disk0s3 /dev/disk0s2がメインのパーティションです。macOSのインストーラは、macOSをこの/dev/disk0s2にインストールします。 /dev/disk0s3はリカバリ用のパーティションです。macOSのインストーラは、ここにリカバリ用のデータをインストールしてくれます。 /dev/disk0s1がESPです。macOSはここを使用しません。ESPは実機にももちろんありますが、やはり空のままです。Cloverをインストールする時に、カスタマイズ指定すると、ESPの中に必要なファイルを書き込んでくれます。 ESPは通常はマウントされていませんが、ターミナルから以下のようにすると /Volume/EFI 以下にマウントしてくれます。\nsudo diskutil mount /dev/disk0s1 10.13.6からマウントするためにsudoが必要になりました。それより古いmacOSでしたらsudoなしでもマウントできます。\nESPの中身 先のmacOSのインストール手順の箇条書きに示したように、ボリュームをフォーマットした後に、macOSをインストールして、次にCloverをインストールします。Cloverをインストールした後の、ESPの一例を見てみましょう。\nCLOVERというディレクトリができていて、この中に、設定ファイルconfig.plist, システム拡張ファイルkextを入れるkexts, EFIのドライバを入れるdrivers64UEFIなどが出来上がっています。これらはCloverのインストーラが作ってくれますが、手作業で作っても良いです。すでに動いているHackintoshの環境を移行する場合などは、このディレクトリ構造そのままに新しいドライブのESPにコピーすれば、引き継がれて稼働します。Cloverのインストーラは、最小構成のconfig.plistと、必要なdrivers64UEFIの中身をインストールしてくれます。\nkextsは、必要に応じて手作業でESPに入れておきます。kextsフォルダのOtherフォルダには全てのバージョン用の、数値のフォルダにはそのバージョン番号のmacOS用のkextを入れられます。 macOSでは、kextを/System/Library/Extensions/ (/S/L/Eと略されます) もしくは、/Library/Extensions/ (/L/Eと略されます) に置きます。Hackintoshで使うkextも/S/L/Eや/L/Eに置くこともできますが、それではバニラで無くなってしまうので、ESPに入れるのが良いです。/S/L/Eや/L/Eに置く場合は、パーミッションを正しく設定したり、キャッシュを作り直したり、SIPを無効にしたりなどの作業が必要です。ESPなら、Cloverがkextを有効にしてくれるので手間いらずでもあります。\n","date":"2017-09-12T23:05:32+09:00","image":"/uploads/2017/09/615UaIBUPvL.jpg","permalink":"/posts/131/","title":"macOSをバニラに保ってインストールする"},{"content":"El CapitanでSIP (System Integrity Protection, システム整合性保護）という仕組みが導入されました。SIPは、システム管理者であっても、システムの要のディレクトリのファイルを変更したりファイル追加したりできない仕組みです。また、アップルに認められて署名されたカーネル拡張機能 (kextファイル) 以外は、機能しません。なんでも書き換えられるスーパーユーザであるルートはもはや居ないという意味で、rootlessとも呼ばれています。\nデフォルトではSIPは有効になっていますが、無効にすることもできます。実機の場合は、以下のようにします。\nリカバリーモードで起動します。 ターミナルを起動して csrutil disableもしくはcsrutil enableと入力します。 この後、再起動すれば、それぞれSIPが無効もしくは有効になります。 SIPに関してはこちらの記事に詳しく書いてあって参考になります。\nnews.mynavi.jp\nHackintoshでの対処方法 SIPが登場した時、Hackintoshが困難になるのではという予想もありました。でもCloverの開発者たちが頑張って対応してくれました。今では、Clover設定で、実機と同様に、SIPを有効にも無効にも自在に設定できます。HackintoshでSIPをどう設定して運用するか、対照的な2通りのアプローチがあるかと思います。\nSIPは無効にして自由自在にパッチを当てまくる macOSをバニラな状態に保ってSIPを有効にする 前者はSIP登場前と同様にmacOSに手を加えるアプローチです。後者のアプローチにある「バニラに保つ」方法の詳細は、以下をご覧ください。\n/posts/131/\nバニラな方法では、Hackintoshに必要なファイルは、全てをEFIシステムパーティション (ESP) に置きます。ESPはSIPの管轄外なのです。ここに置いたファイルは自在に書き換えられますし、ここに置いたkextファイルは、署名がなくても動きます。ESPは管理者アカウントなら自由にアクセスできるので、SIPの有効性を低下させてしまいますが、それでも、本体へのアタックはある程度は防げます。また、SIPを有効にできるかどうかは、システムがバニラに保たれているかどうかの指標にもなります。\nCloverでのSIPの設定 起動時のClover設定画面でも一時的にSIP設定変更が可能です。\n継続的に指定する場合はconfig.plistを編集します。config.plistのRtVariableセクションでSIP設定を変えられます。\n\u0026lt;key\u0026gt;RtVariables\u0026lt;/key\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;CsrActiveConfig\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;0x0\u0026lt;/string\u0026gt; \u0026lt;/dict\u0026gt; ここで使う代表的なCsrActiveConfigの値は以下です。\n0x0 = SIPを有効にする (デフォルト値) 0x3 = SIPを部分的に無効にする (署名されていないkextをロードする) 0x67 = SIPを完全に無効にする 現在の設定状態は、csrutil statusコマンドで知ることができます。手元のマシンだと、以下のようになっていました。有効になっているということです。\n$ csrutil status System Integrity Protection status: enabled. ちなみにRtVariablesキーでは、CsrActiveConfig以外にROMとかMLBとかBooterConfigの値を設定できますが、どれも今のCloverでは不要です。CsrActiveConfigだけが有効です。\n","date":"2017-09-12T19:00:25+09:00","image":"/uploads/2019/10/alarticon.png","permalink":"/posts/132/","title":"SIP システム整合性保護機構"},{"content":"パーツ選びシリーズ最終回の6回目は、その他編です。その他のパーツは好きなものを選んで構いません。\nメモリー：マザーボードに合っているならなんでも良いです。 電源：容量が十分あればなんでも良いです。 光るパーツ：流行っていますので光らせてください。 ケース：Macはどれもカッコいいので勝つのは難しいです。 CPUクーラ：付属のでも十分ですが、かっこいいクーラを買っても良いです。 水冷：簡易水冷と言わず、ぜひとも本格水冷をやってみましょう。 Hackintosh自作は、自作PCの楽しみと、macOSの美しさ・使いやすさを堪能できる組み合わせですので、ぜひ楽しんでください。\nリサイクルMODのおすすめ Macintoshも歴史が長いので、古いマシンが廃棄されていることも多いです。そういうのを回収して、最新のハードウェアに作り変えてあげるのも良いかと思います。そのためのパーツを売っているお店もあります。PowerMac G5とかG4などのケースを改造して作るとなかなか自慢できるものが出来上がります。\nwww.thelaserhive.com\n以下にも関連記事を書きましたので参考になさってください。\nApple純正ケースで作るHackintosh\n最後に、最近YouTubeに上がっていた、かなりマニアックなケースMODを紹介しておきます。PowerMac G5ケースを改造して、ハードチューブ水冷して、その上CPUにはRyzenを使っています。AMD CPUを使いこなすのはとても大変なのでオススメしませんが、苦労もHackintoshの楽しみです。\nwww.youtube.com\n","date":"2017-09-11T23:45:06+09:00","image":"/uploads/2018/05/20180415124036-1.jpg","permalink":"/posts/133/","title":"Hackintoshのパーツ選び 【その6：その他】"},{"content":"5回目はストレージについてです。結論を箇条書きすると：\nSATAケーブルで接続する2.5インチSSD/HDD、3.5インチHDD、5.25インチCD-ROM/DVD/Blu-rayドライブは、どのバージョンのmacOSでも動きます。 High Sierra以降ならばM.2 NVMe SSDが使用可能です。ただ相性があるようなのでパーツ選びに注意してください。 AHCIプロトコルのM.2もしくはmSATAのSSDはそれより古いmacOSでも動きます。 SATAケーブルで接続するストレージ、ドライブは、どれも問題もないです。好きなものを選んでください。ちょっとだけややこしいのは、マザーボードなどのソケット（mSATAとM.2）に挿すカード型SSDの類です。\n用語の整理 マザーボードなどに挿すカード型のSSDは色々な種類があります。まずはソケットの形で分類できます。最近のマザーボードについているSSD用ソケットの形状は、次の2種類です。\n一つは、mini SATA (略してmSATA )と呼ばれる形のソケットです。mini PCI Expressというソケットもありますが、形は同じです（これもまたややこしい）。 もう一つ、最近流行りなのがM.2と呼ばれる形のソケットです。さらに小さくて、細長い形状のカードが多いです。 ちなみに実際のMacに内蔵されているカード型SSDは、このどちらでもない、Apple独自規格のソケットです。\nマザーボードソケットに接続される信号線で分類すると、次の2種類があります。\n一つはSATAです。2.5/3.5インチのドライブに接続しているものと同じ信号です。 もう一つはPCIeです。マザーボードのPCIeスロットに出ているのと同じ種類の信号です。 さらに、この信号に流れるプロトコルで分類すると、次の2種類があります。\n一つはAHCIです。2.5/3.5インチのSATAコネクタのドライブで使われているプロトコルです。 もう一つはNVMeです。SSDに適した命令体系になっていて高速です。 この2x2x2=8通りの組み合わせは、さすがにありませんが、色々な組み合わせがあるので注意が必要です。例えば、\nmini SATAでSATA接続でAHCIプロトコルとか、 M.2でSATA接続でAHCIプロトコルとか、 M.2でPCIe接続でAHCIプロトコルとか、 M.2でPCIe接続でNVMeプロトコルとか、 いろいろあります。\nこのうち、macOSのどのバージョンでもサポートしているのが、AHCIプロトコルのSSDです。ソケット形状やSATA/PCIeの違いは問題になりません。OSから見たらそのレベルのハードウェアは抽象化されているので、大丈夫なのです。\nHigh Sierraで完全サポートされたNVMe 問題は、NVMeです。NVMeはEl Capitanのあたりで一般的に流通し始めました。MacBookシリーズには、他のプラットフォームに先駆けて、NVMe登場の早い段階で採用されました。ただし、これはMacintoshの歴史でよくあることですが、一般に売られているNVMe SSDとは互換性のないSSDが使われていました。ソケット形状も独自ですし、データのブロックサイズも違うようです。そのため、一般に販売されているm.2 NVMe SSDは簡単には使えませんでした。\nEl Capitanの時には、NVMeGeneric.kextというカーネル拡張がwww.macvidcards.comから配布されて、これで市販のM.2 NVMe SSDが使えました。しかし、Sierraで動かなくなりました。今は配布もされていないようです。\nSierraでは、市販のM.2 NVMe SSDを動かす長い長いパッチが公開されて、config.plistに組み込んで使うことは可能でした。手間が面倒でした。\nその苦労は、High Sierraで終わりました。High Sierraでは市販のNVMe SSDがサポートされるようになります。今時は、M.2 SSDはどれも高速なNVMeになり、低速のAHCIのモデルは品薄で割高です。とても助かります。\nNVMeのM.2 SSDの製品は増えています。どれもHigh Sierra以降で問題なく使えるはずと思うのですが、ネット上の情報によるとmacOSと相性の悪いものがあるようです。注意が必要です。フォーラムでも貴重な情報をいただいています。それによると：\nSamsung 970 EVO Plus と Samsung PM981 は互換性に問題がある 次のSSDは問題なし：\nSamsung 970 EVO Pro\nSamsung 970 EVO\nSamsung PM961\nSamsung PM951\nWD SN750 私もSamsungの古いSSDとWDのSN750を使っていますが、どちらも問題なく動いています。SamsungのSSDは使用されるコントローラチップの一部がmacOSと相性が悪いようです。M.2 SSDは発展途上の製品なので今後は問題なくなると思いますが、現状ではWDの方が安心できるかもしれません。\n追記：Samsung SSDのファームウェア更新 Samsungの一部のM.2 SSDがmacOSと相性が悪い問題ですが、フォーラムにいただいた情報によるとファームウェア更新で解決するようです。macOSで不安定だった970 evo plus がまともに動くようになったそうです。やはり何か問題があったんですね。こちらがtonymacx86の情報のページだそうです。\n","date":"2017-09-11T22:12:40+09:00","image":"/uploads/2017/09/61GPr8ekdcL.jpg","permalink":"/posts/134/","title":"Hackintoshのパーツ選び 【その5：SSD】"},{"content":"\n現行のMacintoshからはすっかり駆逐されてしまった光学ドライブですが、Hackintoshなら5.25インチベイ搭載ケースを使っていくらでも復活できます。CD-ROMでもDVDでもokです。実機にはついぞ搭載されなかったBlu-rayドライブも搭載可能です。1台だけでなく2台3台と搭載することだって可能です。読み出すだけじゃなくて書き込むこともできます。搭載するに当たって、特に難しいことはありません。SATAケーブルと電源を配線するだけです。\n「可能な場合でもハードディスクをスリープさせない」 簡単、かんたん、a piece of cakeだと思っていたら、「空のdvdがセットされました」というメッセージが出て、操作不能になることがあります。Pioneerのドライブで発生するような気がします。\n一部の光学ドライブは、スリープコマンドを送りつけて動作を止めると、次にアクセスした時に復帰できないようです。にもかかわらず、macOSの省エネルギー設定では、「可能な場合はハードディスクをスリープさせる」ことがデフォルト設定になってます。これがトラブルの原因です。なので、この問題は、「システム環境設定」の「可能な場合はハードディスクをスリープさせる」のチェックを外すことで解決します。\nカーネル拡張(kext)にパッチを当てる 上記の方法だと、当然ですがハードディスクはスリープしなくなります。また、私は経験したことがありませんが、この方法でも解決しないという報告もあるようです。そこで正攻法で根本的解決方法、つまりシステムにパッチを当てる方法を紹介します。\nアップル社は対策済み アップル社もこの問題はよ〜く分かっていて、旧型Mac Proに搭載されているPioneerの光学ドライブに対して対策をしています。PioneerSuperDrive.kextの中で、Pioneerの光学ドライブの型番を指定して、このドライブだけはスリープさせないようにという設定がされているようです。その型番とは、\nDVD-RW DVR-105\nです。この対策を担当しているkextは、PioneerSuperDrive.kextです。試しに、\n/System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/PioneerSuperDrive.kext/Contents/PlugIns/PioneerSuperDrive.kext/Contents/MacOS/PioneerSuperDrive をhexdump -Cしてみると、\n00000fb0 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に搭載した人は、きっとこの問題に遭遇しないのでしょう。そうでない人は、ファイルに書かれた型番を、実際に使っているドライブの型番に書き換えればよいわけです。\n光学ドライブの型番を知る 光学ドライブの型番は、「リンゴマーク」「このMacについて」「システムレポート（システム情報）」「ハードウェア」「SATA/SATA Express」とだどっていけば、見つかります。手元の例ではPIONEERという表記を除いて、\nBD-RW BDR-205 でした。スペースの数（3個あります）も重要で、全部で15文字のはずです。\nCloverのconfig.plistでパッチを当てる 古代の手法では、 PioneerSuperDrive.kextの該当ファイルをバイナリーエディタで開いて、データを書き換えていました。これは色々問題があります。特に、OSのバージョンアップのたびに同じことをやらなければならないのが面倒です。現代風の方法では、Cloverの動的パッチ機能を使います。起動するタイミングでパッチを当ててくれる機能です。\n設定ファイルconfig.plistにパッチ情報を書き込むのですが、この時、バイナリーデータを文字に対応させて変換するBase64という方式を使います。Base64への変換は、ターミナルのbase64コマンドで可能です。例えば、DVD-RW DVR-105（スペースは2個）とBD-RW BDR-205（スペースは3個）の文字列をBase64に変換するには、ターミナルで以下のようにタイプすれば良いです。\n$ echo -n \u0026#34;DVD-RW DVR-105\u0026#34; | base64 RFZELVJXICBEVlItMTA1 $ echo -n \u0026#34;BD-RW BDR-205\u0026#34; | base64 QkQtUlcgICBCRFItMjA1 変換前後の文字列のBase64表記がわかりましたので、いよいよconfig.plistを開いて、KextsToPatchセクションに以下を追加します。\n\u0026lt;key\u0026gt;KextsToPatch\u0026lt;/key\u0026gt; \u0026lt;array\u0026gt; \u0026lt;dict\u0026gt; \u0026lt;key\u0026gt;Comment\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;PioneerBD-RW No Sleep\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Find\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;RFZELVJXICBEVlItMTA1\u0026lt;/data\u0026gt; \u0026lt;key\u0026gt;Name\u0026lt;/key\u0026gt; \u0026lt;string\u0026gt;PioneerSuperDrive\u0026lt;/string\u0026gt; \u0026lt;key\u0026gt;Replace\u0026lt;/key\u0026gt; \u0026lt;data\u0026gt;QkQtUlcgICBCRFItMjA1\u0026lt;/data\u0026gt; \u0026lt;/dict\u0026gt; \u0026lt;/array\u0026gt; なんとなくわかると思いますが、PioneerSuperDrive.kextの、RFZELVJXICBEVlItMTA1というデータを検索して、QkQtUlcgICBCRFItMjA1に置き換えてくださいという指示です。これでめでたくスリープ問題が根本的に解決されるはずです。\nOpenCoreのconfig.plistでパッチを当てる OpenCoreでも同様に、config.pistの指定で動的にパッチ当てが可能です。以下にその方法を紹介しておきました。\nPioneer光学ドライブのパッチをOpenCoreに適用する\nキーボードから開閉したい ご存知のようにアップルの純正キーボードには光学ドライブをイジェクトするキーがついています。今風のMacintoshでは使いようのない無駄なキーですが、光学ドライブを搭載したHackintoshなら有効に使ってあげられます。と、思ったら、これが効かないこともありました。\n解決策がこちら、\nwww.tonymacx86.com\nで紹介されています。AHCI_3rdParty_SATA.kextに手を加えて使用する方法です。日本語で紹介された解説が、こちらにあります。\nwww.reddit.com\n","date":"2017-09-11T13:57:04+09:00","image":"/uploads/2018/10/20181029215850.png","permalink":"/posts/135/","title":"光学ドライブを使う"},{"content":"EFIシステムパーティション(頭文字を並べてESP)には、Cloverブートローダとかconfig.plistとかkextファイルなどが置かれてます。ESPは通常はマウントされていませんので、これをメンテするときに、マウントする必要があります。例えば、ESPが/dev/disk0s1にある場合は、ターミナルから\ndiskutil mount /dev/disk0s1 とすればマウントできます。すると/Volumes/EFI以下にマウントされます。必要ならばここにcdしたり、これをファインダーに表示させます。\nでもこの一連の作業が面倒なので、こんなシェルスクリプトを作って使っています。マウントしたESPは、マウントした順番に/Volumes/EFI, /Volumes/EFI 1, /Volumes/EFI 2のマウントポイントに割り当てられます。このスクリプトでは、マウントした後にCLOVERのディレクトリにcdしています。 この後、open .などすればファインダに表示することもできます。\n#!/bin/sh if [ $# -eq 0 ]; then DRIVE=\u0026#34;0\u0026#34; else DRIVE=$1 fi diskutil mount /dev/disk${DRIVE}s1 MP=`diskutil info disk${DRIVE}s1 | grep \u0026#34;Mount Point\u0026#34;` MP3=`echo $MP | awk \u0026#39;{print $3}\u0026#39;` MP4=`echo $MP | awk \u0026#39;{print $4}\u0026#39;` if [ -n \u0026#34;$MP4\u0026#34; ]; then cd $MP3\u0026#34; \u0026#34;$MP4\u0026#34;/EFI/CLOVER\u0026#34; else cd $MP3\u0026#34;/EFI/CLOVER\u0026#34; fi これをファイルにして、名前をつけて、実行可能にします。例えば、mountESPという名前のファイルにした場合、\n/dev/disk2s1 をマウントしたいならば、ターミナルから以下のようにタイプします。\n. mountESP 2 引数を省略すると/dev/disk0s1がマウントされます。ドライブが1個しかないマシンでは、必ず/dev/disk0に割り当てられるので、番号を省略できると便利と考えました。\n. mountESP ちなみに冒頭のピリオド空白(. )は重要です。通常よくやるように./mountESPとすると、最後のcdコマンドが効きません。実際には効いているのですが、シェルスクリプト実行環境の中で効いているので、ターミナルのプロンプトに戻ると元のディレクトリに帰って来てしまいます。ピリオド空白(. )は、ターミナルの実行環境のままで、キー入力そのもののようにスクリプトを実行するという意味だそうです。\n追記：10.13.6からESPをマウントするのに管理者パスワードが必要になりました。なので、上記のスクリプトも、diskutil mountの行を、以下に変更する必要があります。(2018/7/10)\nsudo diskutil mount /dev/disk${DRIVE}s1 ","date":"2017-09-10T23:43:45+09:00","image":"/uploads/2017/09/20170926165208.png","permalink":"/posts/136/","title":"ESPをマウントするためのシェルスクリプト"},{"content":"\n今回は、Hackintoshのためのマザーボード (BIOS) の設定について書いておきます。Windowsなら適当に設定しても、大きな問題は起きないと思います。でもmacOSをインストールする場合には、間違えると起動しないという重要設定項目が少しだけあります。\n基本設定 最初は工場出荷状態：大体は工場出荷状態で良いです。デフォルトにまずは設定します。最近のマザーボードは、以下の項目が大体デフォルトで設定されています。なので工場出荷時状態にするだけでmacOSが起動することが多いです。 SATAのモードはAHCIモード：最近は、AHCIモードがデフォルトだと思います。AHCIじゃ無いとデータが読めなくて起動しません。 HPETはEnable。もしくは設定する項目があれば64bitモードに。 シリアルとパラレルI/OはDisable：macOS 10.11以前ではシリアルとパラレルのI/Oが有効だとカーネルパニックを起こして起動しないことがあります。そこで無効にします。10.12以降では有効でも起動します。でも、これらを使わないなら無効にした方が安全で効率的だと思います。 USBのXHCI Hand-offはEnable Windows関連の機能は全部Disable：デフォルトもDisableだと思いますが全部Disableにしておきます。Fast BootなどもDisable CPUのIntel VT-D TechはDisable：これもEnableになっていると起動しません。ちなみにIntel Virtualization TechはEnableでも良いです。Enableになっていないと仮想マシンが動きません。 tonymacx86にはメーカーごとに設定の案内があります。ちょっと古い記事ですし、上で述べたように最近はデフォルトでほとんどokなのですが、起動しないなどのトラブルがある場合にはチェックすると良いです。\nGigabyte AMI UEFI BIOS Gigabyte AWARD BIOS ASUS AMI UEFI BIOS MSI AMI UEFI BIOS カーネル読み込み失敗を防ぐための設定 ここまでの設定で、ほぼ大丈夫なはずです。ただmacOSでは使われないので、外しておいた方が良い項目もあります。不要な項目があるとmacOSカーネルを読み込むメモリー領域が細分化されて不足する場合があります。その場合、起動開始直後に失敗する、たまに失敗する、失敗するけどたまに成功する、などの現象が発生します。また、最新マザーボードにはメモリー細分化を防ぐメニューも加わっているようです。必須ではありませんが以下の設定も検討しましょう。\nAbove4GDecoding: enableにします。これにより4GB以上のメモリー空間を使うことになり、カーネル読み込み失敗を防ぐ効果があります。ただしX99, X299などでは問題を引き起こす可能性があるので、注意して設定してください。 Boot Options -\u0026gt; Windows8.1/10 mode: この設定にすることで、レガシーなコードが使用するメモリーを節約できます。これ以外の選択肢に「other OS」がありますが、これはmacOSの事を指しているのではなく、古いバージョンのWindowsの事を指しています。 CSM: disableにします。レガシーサポートのためにたくさんのメモリを消費します。macOSでは不要です。 Intel SGX: disableにします。Software Guard Extensionsという名前の機能ですが、これもメモリ領域を多量に消費しますが、macOSでは何の効果もありません。 Parallel Port: disableにします。上の基礎設定の項目でも説明しましたが、macOSでは使いません。 Serial Port: disableにします。同じくmacOSでは使いません。 iGPU: どうしても起動に失敗する場合はiGPUを切ることも検討しましょう。 Thunderbolt: TBを使わない、搭載されていない場合はdisableにしましょう。これもメモリーを削減できます。これ以外に、Intel WiFi, Intel Bluetooth, SDカードなど、macOSで使用できない機能はdisableにすると良いです。 LED lighting: 起動に失敗する場合はdisableにすることも検討しましょう。 Legacy USB: これは多分不要です。USB接続フロッピーなどを使う予定がなければ多分不要です。 ","date":"2017-09-10T22:19:26+09:00","image":"/uploads/2017/09/20170910221614.png","permalink":"/posts/137/","title":"マザーボード (BIOS) 設定"},{"content":"Hackintosh自作に適したWiFiとBluetoothカードを紹介します。今までお話しした、CPU、マザーボード、グラフィックスカードがHackintosh自作パーツの主役でした。これらが正しく選択されていれば、他のパーツはどれを使ってもとりあえず動きます。でも脇役なりにこだわっておきたいパーツもあります。WiFi / Bluetoothカードはその筆頭かと思います。\n結論 長いので、結論を先に書いておきます。現時点 (2020/7) で、比較的入手可能なモジュールで、そのままで (OOBで) 使用できる製品は、以下です。\nBCM94360CS2 (Broadcom独自コネクタ) BCM94360CD (Broadcom独自コネクタ) BCM943602CS (Broadcom独自コネクタ) BCM943602CDPAX (Broadcom独自コネクタ) Fenvi FV-T919 (PCIe) BCM94360NG (A \u0026amp; E Key M.2コネクタ) Broadcom独自コネクタは、Macで採用されているコネクタですが、そのままでは使えないので、PCIe, mini PCIe, M.2などに変換するアダプタを経由して使用します。デスクトップマシンならPCIeスロット、ノートPCやミニPCならばM.2コネクタを使用して無線モジュールを取り付けるのが一般的です。\nそもそも無線は必要なのか 普通に考えたらデスクトップコンピュータにはBluetoothもWiFiも必須ではないでしょう。キーボードはUSBで接続すれば良いですし、ネットワークは有線LANで接続した方が、高速ですし安定しています。でもmacOSを使うとなると、次の理由で Bluetooth / WiFi が欲しくなると思います。\nMagic Trackpadが使いたい 現行のMagic Trackpad 2と1世代前のMagic TrackpadはBluetooth接続するポインティングデバイスです。macOSでは色々なマルチタッチ入力がサポートされています。MacBookシリーズを使っていれば、マルチタッチ操作はおなじみかとも思います。これらが、非常に使いやすいのです。macOSのインタフェースの素晴らしさは定評があるところですが、その素晴らしさを全て享受するにはMagic Trackpadが必須です。そのためにBluetoothが必要なのです。\nContinuityが使いたい 最近のアップル社のビジネスは、もはやMacintoshがメインではなくなりました。iPhoneがメインで、さらにはそれを取り巻くエコシステムにユーザを取り込んで、クラウドサービスとコンテンツ販売で儲けるビジネスモデルに移行しつつあります。なので、macOSでも、他のMacintoshだけでなく、iPhone, iPad, Apple Watchとの連携機能の強化（Continuity）を進めています。これらを使用するには、BluetoothとWiFiが必要なのです。 iPhoneとmacOSを連携するにも、iPhone経由でiMessageを使うにも、Apple Watchでログインするにも、無線機能が必要です。\n手軽なBluetooth USBアダプタ Magic Trackpadを接続するだけなら、USBのBluetoothアダプタがお手軽です。ただ、どれでも動くわけではありません。おすすめは、iMacやMacBookで採用されているBroadcom社のチップBCM20702を使ったアダプタです。これならMac OS X 10.8以降で動作します。日本で簡単に買える製品だと、例えばI-O DATAのUSB-BT40LEです。\nただ、Magic Trackpadやキーボードは使えますが、Continuityの機能は使えません。\nWiFi USBアダプタは使えない macOS用のドライバが付属していて、macOSでも使えるとされるWiFi USBアダプタがいくつか販売されています。私は使ったことがありませんが、少なくともHackintoshでは非常に不安定らしいです。おすすめできないようです。\nBroadcom社の純正無線モジュール ということでようやく本題です。Hackintoshに取り付けるだけで、何の設定もせずにそのまま動いて、本物のMacintoshとまったく同じくContinuity連携ができる究極のWiFi / Bluetoothアダプタがあります。実機で使われているBroadcom社の製品です。ただ、Broadcom社のものなら何でも良いというわけではありません。実機と少し違うものは、それでも使えることがありますが、パッチを当てて苦労することになります。\nApple社が使っているBroadcomの無線モジュールに関して、このページでまとめられています。\nUser:Omega/Broadcom modules (Apple) - DeviWiki (ex WikiDevi)\nそれによると、最近の802.11acに対応した実機で使われているBroadcom社の無線モジュールは以下です。\nBCM94360CS2 (2013年採用) BCM94360CS (2013年採用) BCM94360CD (2013年採用) BCM943602CS (2015年採用) これらはいずれもBroadcom社から、チップセットが基板に乗ったカードの形で販売されています。AliExpressなどで$10から$40くらいで入手できます。日本のamazonでも時々売られています。ただ、採用された年号から分かるように、いずれも少し古い製品です。最近のMacではApple社内製品モジュールが使われる傾向があるようです。iMac Proのような大型筐体でも、Broadcomのモジュールは使われず、Apple特注のチップが基板上に直接実装されています。現行機種はBluetooth 5.0を搭載していますが、これらはすでに基板上に実装されたチップになっているので、一般には手に入りません。\niMac Proの分解\nということで、今は比較的潤沢に出回っているBroadcomのモジュールも、今後は品薄になるかもしれません。将来使用するかもしれない部品は、今の内に確保しておくのが良いかもしれません。\n以下で、この４種類のモジュールの詳細を説明します。おすすめは、コスパの高い最新型のBCM943602CSか、もしくはMac Proで使われている高級品のBCM94360CD、もしくは2015, 2016年iMacで使われている BCM943602CDPAXです。\nBCM94360CS2 上記のロシアのサイトによると、４種類のモジュールのうち、BCM94360CS2だけはWiFiが少し遅いようです。（他が1.3Gbpsに対して、これは867Mbps）価格は安いです。MacBook Air 2013などで使用されているモジュールです。アンテナの数は２本です。おそらく、１本がBluetoothで、もう１本がWiFiだと思われます。WiFiアンテナを複数持っている場合、一番条件の良いアンテナが使用されます。WiFi電波強度は、壁の反射などで均一ではありません。アンテナの本数が多い方が、離して設置したり、向きを変えたりすることができ、強い信号を受信できる可能性が高まるので有利です。とはいえ、有線LANをメインで使用するデスクトップなら、このモジュールでも十分かもしれません。（追記：もしかしたらBluetoothとWiFiを1本のアンテナで共有していてるのかもしれません。）\nBCM94360CS これはMacBook Pro 2013などで採用されているモジュールです。5GHz WiFiが1.3Gbpsのものです。アンテナの本数は３本です。Bluetoothが１本、WiFiが２本と思われます。\nBCM94360CD これはiMac 2013や、最新の（と言ってもだいぶ古くなってしまいましたが）円筒型Mac Proでも採用されています。最高級モデルと言えます。販売価格も４種類の中では一番高額です。とは言っても$40未満です。5GHz WiFiが1.3Gbpsで、アンテナの本数は４本です。端から２番目の一つがBluetoothで、後の３本がWiFiです。私が入手した当時はこれしかなかったので、今でも使用しています。\nBCM943602CS これはMacBook Pro 2015で採用されている最新のモジュールです。5GHz WiFiが1.3Gbpsで、アンテナの本数は３本です。Bluetoothが１本、WiFiが２本と思われます。外見と型番からしてBCM94360CSの後継機種と思われます。新しいモデルのためか、価格が安いのでお得感があります。流通している個数も多いようです。\nBCM943602CDPAX コメントで情報いただいたカードです。iMac A1418, A1419 (2015, 2016)用のカードらしいです。アンテナは4本あります。入手できる最新のカードかと思われます。\n純正モジュール用変換アダプタ PCIeスロット用アダプタ 上の写真を見ていただくとわかるように、いずれの純正無線モジュールにも、縁には同じコネクタがついています。これらのモジュールに対応したMacBook Air, MacBook Pro, iMac, Mac Proには、このピンに合うソケットがついているので、差し替えて交換することができます。\nコネクタのピン構成はPCIeとUSBです。WiFiがPCIeを使い、BluetoothがUSBを使います。PCIeとUSBが一緒になったコネクタの規格としては、mini PCI Express (miniPCIe, mPCIe)とかm.2が普及しています。特に最近のマザーボードの多くにはm.2が搭載されています。 でも残念なことに、Broadcom社のモジュールのコネクタは、形もサイズも違う独自仕様で、mPCIeやm.2との互換性がありません。\nそこで、このコネクタを、通常のPCIeスロットに変換するアダプタが売られています。通常のPCIeスロットにはUSBのピンはありませんので、このタイプのアダプタにはUSBのためのコネクタがついていて、マザーボード上のUSB 2.0端子に接続します。製品によりアンテナ本数が違いますので、使おうとしている無線モジュールのアンテナ本数と同じかそれ以上のアンテナのあるアダプタを選びます。\nAmazonでも売っています。\nmini PCI Express用アダプタ こちらはmini PCIe変換アダプタです。mini PCIeを搭載したマザーボードで、空間に余裕がある場合は、これを使ってBCM94360CDを取り付けられます。\nm.2用アダプタ (A/Eキー用) m.2に変換するアダプタも売られています。m.2無線ソケットで使われるA/Eキー用の変換アダプタです。m.2のキーは、切れ目の入っている場所で決まります。m.2には色々な配線がされる場合がありますが、キーの違いで、配線されている信号が違います。A/Eキー用のアダプタは、m.2無線ソケットを搭載したマザーボードで使えます。ただ、これにさらに純正のカードを取り付けることになりますので、空間に余裕がある場合に限られます。余裕があれば、これを使ってBCM94360CDなどを取り付けられます。\nBCM94360CS2 カード NGFF (M.2) キーA/Eアダプター Mac OS ・ ハキントッシュ用 |\u0026hellip;\nどう見ても同じものはAliExpressでも売られています。説明によると、BCM94360CD、BCM94360CS、BCM94360CS2、BCM943602CSなどのソケットをm.2に変換するアダプタだそうです。取り付け穴はBCM94360CS2などに対応しているようです。\nA-E keyもしくはE keyのM.2用ソケットを延長するアダプターもあります。こういう製品を使えば、小型のインテル製無線カードが入っているソケットから、延長して外に引き出して、macOS純正のBroadcom製カードを取り付けることができると思います。\nm.2用アダプタ (Mキー用) m.2のMキー用のアダプタもあります。これは、BCM94360CD BCM943602CS BCM94360CSなどに対応しているようです。Mキーは、SSDなどを取り付けるタイプのキーで、PCIeが多めに配線されています。その一方でUSBは配線されていないので、ケーブルでマザーボード上のUSBコネクタに配線することになるようです。それなら、PCIeスロット用のアダプタの方が、アンテナコネクタも設置できるので便利な気がします。でも、SSD用のm.2ソケットが余っている・使っていなくて、さらにPCIeスロットを節約したい用途、例えばmicro ATXやmini ITXなどのPCIeスロットの少ないマザーボードでは有用かと思われます。\n純正モジュールを組み込んだ製品 FenviのPCIeカード Fenviという会社が、BCM94360CDを組み込んだPCIeカードを作っています。\nFenvi Technology\n中身は、BCM94360CDなので、HandoffもContinuityも、何の設定もしなくても全て動作するようです。海外サイトでも好評で、tonymacx86では推奨パーツになっています。純正のBCM94360CDをPCIeアダプタで組み込むと、アンテナを配線する必要があり、コネクタが外れるトラブルがあります。Fenviの製品ではプリント基板上で配線されるのでスッキリしています。\nただ、以前はeBayやAliExpressで$55くらいで売っていましたが、最近は見かけないようです。日本のamazonでも一時売っていましたが、今は無いようです。tonymacx86から米国amazonへのリンク先でも商品が消えています。\n長らく販売されていなかったのですが、最近、AliExpressに復活したようです。でも説明を見ると10.10, 10.11対応とあって10.12ではBluetoothがあまり良く動かないと書いてあります。オリジナルのBCM94360CDは、10.12でも10.13でもBluetoothは問題なく動くので、互換性に問題があるのかもしれません。(2018/5/25)\nこちらもご覧ください。\nWiFi/BluetoothアダプタFenvi FV-T919\nFenvi以外のPCIeカード Fenviの他にも、対応モジュールを組み込んだPCIeカード製品もあるようです。AliExpressで見つけた出品を2つ紹介します。モジュールの型番を選んで発注するページもありますので、\nBCM94360CS2 (2013年採用) BCM94360CS (2013年採用) BCM94360CD (2013年採用) BCM943602CS (2015年採用) から選ぶように気をつけてください。\nまた、macOS対応モジュールと書かれたBCM94331CDを選べるページもありますが、上記の4つの802.11ac対応モジュールより古い世代のものです（802.11n対応で5GHz WiFiが450Mbps）。またBCM94331CDは、機種設定によってはHandoffが不調だという報告もあります。値段は安いですが避けた方が無難です。\n汎用コネクタの互換モジュール ここまで、本物のMacintoshで使われているのと同じ部品を使ったモジュールを紹介しました。でも実機で使われていないモジュールの中にも互換性の高いものがあります。中には実機と同じシリーズのBroadcom製品でたまたま実機に採用されなかった部品もあります。これらはHackintoshでも使えます。\n以下のリンクに、mini PCIeとM.2の無線モジュールの詳しい情報が書かれています。この中で、OOB (箱から出してすぐに使える) の欄がY (Yes)になっているモジュールは、簡単に使えると思われます。ここにリストされた多くの無線モジュールは、ノートPCの補修パーツとしてAliExpressなどで入手可能です。M.2やmini PCIe ソケット周りのスペースが限られていて、純正モジュールアダプタが使えないような場合は、選択肢として検討してみましょう。\nInventory of supported/unsupported wireless cards #1, Snow Leopard -\u0026gt; El Capitan\nこの中で、有用性の高いカードは、1/2 mini PCIeもしくはM.2のカードだと思います。OOBがYになっている非純正モジュールをいくつか見てみましょう。\nDell DW1510 (mini PCIe) 更新：macOS CatalinaでBCM94322用のドライバが外されたという情報があります。DW1510はBCM4322を使っていますのでmacOS 10.15からは動かない可能性があります。\n更新：Catalina 10.15.7で試したところDW1510は動かなくなっていました。\n1/2 PCIeのWiFiカードです。WiFiがa/b/g/n対応のものの多くは、少し古い世代の製品なので、Bluetoothは搭載されていません。この中でも、DW1510はノートPCやNUCのHackintoshでよく使われます。ちなみにDWという型番は、DellのノートPC用の補修部品の型番です。多分Dell Wirelessの略だと思われます。DW1510は、AliExpressでも数ドルで売られていて、安価です。これはmini PCIeに挿せば、そのまま何もせずにHackintoshで動きます。Bluetoothがありませんので、I-O DATAのUSB-BT40LEなどのBluetooth USBアダプタと組み合わせて使うのも良いと思います。Continuityを使用しないなら安定していて良い選択です。\nBCM94360HMB (mini PCIe) 1/2 PCIeのWiFi/Bluetoothカードです。以下の名前で流通しています。\nAzureWave AW-CB160H Alpha Networks WMC-AC01 Arcadyan WN8833B-AC Gemtek WMDB-150AC Unex DAXB-81 Wistron NeWeb DNXB-C1 WiFiがa/b/g/n/acのタイプには、Bluetoothが搭載されたコンボカードが多いです。1/2 mini PCIeでOOBがYなのは、このAzureWave AW-CB160Hのみです。BroadcomのBCM94360HMBというモジュールを使っています。数字部分が純正と同じです。そのため互換性が高いです。アンテナが3本のタイプです (WiFiが2本とBluetoothが1本）。アンテナのコネクタが、一般のmini PCIeのコネクタ(U.FL) より小型のタイプ(MHF4)です。AliExpressの製品には、コネクタ形状を変換するケーブルが付属しているものもあります。アンテナについては最後に説明します。\n上記のリストではOOBとはなっていますが、簡単なkextが必要なようです。詳しくはこちらに説明があります。\nr/hackintosh_ja - WiFi/BT half-mini-PCIeのBCM94360HMB (AzureWave AW-CB160H) \u0026hellip;\n更新：Big Surで試したところ、以下の3個のkextを入れることで、AzureWave AW-CB160Hが動作しました。\nBrcmPatchRAM3.kext BrcmFirmwareData.kext BrcmBluetoothInjector.kext BCM94352HMB (Dell DW1550) (mini PCIe) 1/2 PCIeのWiFi/Bluetoothカードです。以下の名前で流通しています。\nAzureWave AW-CE123H Dell DW1550 HP TPC-Q013 Lenovo Lite-On WCBN606BH これもWiFiがa/b/g/n/acのタイプで、Bluetoothが搭載されたコンボカードです。こちらはアンテナが2本のタイプで、アンテナコネクタも通常サイズです。なので、既存のカードを差し替える場合に、作業が簡単になる場合が多いです。ですが、上記のリストではOOBの項目がN (No)です。そのままではBluetoothが動かないので、いくつかパッチを当てる必要があります。ただ、パッチの方法は確立されているようで、Continuityも動くようです。tonymacx86に詳しい説明が書いてあります。\nBCM94352Z (Dell DW1560) (M.2) M.2のWiFi/Bluetoothカードです。AliExpressで多数売られているM.2用カードです。以下の名前で流通しています。\nDell DW1560 Fenvi AC1200 Lenovo Lite-On WCBN802B(04X6020) (E Keyなのでソケットに注意) AzureWave AW-CB162NF このほか、BCM4352と書かれていることもありますし、BCM94352Zという表記のものもあります。以下の4個のkextを入れれば基本的なWiFi/Bluetooth機能は動きます。AirDropやContinuityなどを動かすにはさらにパッチが必要なようです。必要なファイルを下記からダウンロードして用意します。\nまず、RehabMan-FakePCIIDからダウンロードしたzipの中から\nFakePCIID.kext FakePCIID_Broadcom_WiFi.kext を用意し、次に、 RehabMan-BcrmPatchRAMからダウンロードしたzipの中から\nBrcmFirmwareData.kext BrcmPatchRAM2.kext を用意します。これらをESPのkext用フォルダに入れます。\nBCM94360NG (M.2) 最近、このカードが評判良いらしいです。Fenvi BCM94360NGという商品名でも流通しています。DW1560より良いとのことです。Handoff, Airdrop, appleWatchでのログインなどがOOBで動作します。こちらの記事で紹介しています。M.2無線カードとしてはこれが1番のおすすめです。(2020/4/20追記)\nThinkPad T460s にWiFi/BTカードBCM94360NGを取り付ける\nBCM943602BAED (Dell DW1830) (M.2) M.2のWiFi/Bluetoothカードです。単にBCM943602という名前の場合もあります。先のリストで、M.2カードでOOBがYなのは、BCM943602BAEDのみです。この型番の数字部分は上記で説明した純正品と同じ番号です。チップは同じですが、Apple専用では無い汎用的なM.2ソケットの製品という意味かと思います。こちらの情報のよると、\nWifiはOOBで動く WiFiのパフォーマンスはFakePCIID Kextで改善できる Bluetoothを動かすためにはkextが必要 だそうです。\nBCM94350ZAE (Dell DW1830) (M.2) Dell以外からは、Lenovo Foxconn T77H649, Lite-On WCBN808Bなどの名前で流通しています。macOSで電力制御を正しくサポートしないのでノート向きでは無いようです。\nアンテナ アンテナは必ず取り付けてください。どの無線モジュールにも小さなアンテナコネクタがついていますが、その先にアンテナをつけないと通信できません。近距離ならアンテナ無くても動かなくはないですが、実用にならないです。\n上で紹介した純正モジュールをPCIeに取り付けるアダプターには、だいたい棒状のアンテナが2~4本付属しています。一方、純正モジュールをminiPCIeやM.2に取り付けるアダプタは、PCIeとUSB接続の面倒は見てくれますが、アンテナが付属していません。なので別途手配する必要があります。また、非純正のBroadcomモジュールをマザーボードのminiPCIeやM.2コネクタに取り付ける場合も、アンテナは必須です。\nPCIeカードアダプタでは、取り付け金具にSMAと呼ばれる規格のコネクタが付いていて、ケース外側に棒状アンテナを取り付けます。\nケース内側では内部の無線モジュールに配線するように作られています。無線モジュールには、SMAより小さいU.FLやMHF4という規格のコネクタが付いています。下は、SMAコネクタとU.FLコネクタの変換ケーブルです。\n無線モジュール側のU.FLとMHF4は、どちらも小さなコネクタですが、サイズが違います。一見すると似ているので注意が必要です。下はAmazonで売られている変換ケーブルの写真です。小さい方がMHF4（メス）で、大きい方がU.FL（オス）です。\n純正Broadcom無線モジュールには、小さい方のMHF4が付いています。一方で、非純正のBroadcomの無線モジュールのコネクタは、miniPCIeなどの古い製品は大きい方のU.FL、最近のM.2の製品では小さい方のMHF4です。ただ上で紹介したように、BCM94360HMBはminiPCIeですが小さい方のMHF4です。使用しているモジュールのコネクタが、U.FLなのかMHF4なのかを確認して、それに合わせたケーブル、またはアンテナを購入する必要があります。\nPCIeブラケットに取り付ける棒状のアンテナの代わりに、Mac製品やノートPCの内部で使われているようなアンテナ部品を使うことも可能です。\nただ、閉鎖された金属ケースの中にアンテナを設置すると、電波が飛びません。最近の「見せるケース」のようにアクリルやガラス窓のあるケースなら良いかもしれません。また、アンテナ部品を金属部分に密着して取り付けると、電波が吸収されて感度が低下します。できれば非金属の部分に取り付けます。金属部分に止むを得ず取り付ける場合は、プラスチックやスポンジ片を使って、金属部分から1cmくらい浮かせるように取り付けると良いです。\n","date":"2017-09-10T17:58:16+09:00","image":"/uploads/2017/09/20170924210000.png","permalink":"/posts/138/","title":"Hackintoshのパーツ選び 【その4：無線編】"},{"content":"このページは古い情報です。最新の情報はこちらをご覧ください。\n/posts/36/\n【2018年4月2日改訂：10.13.4以降のRadeonの近況を追記しました。】\n【2017年12月17日改訂：Radeonの近況を追記しました。】\n【2017年12月1日改訂：CloverのRadeon対応を追記しました。】\nHackintosh自作に適したグラフィックスカードを紹介します。\nNVIDIAかAMD(ATI)か グラフィックスカードの2大メーカが、NVIDIAとAMDで、自作する人たちの中では、どっちが良いのかという議論で盛り上がることも度々です。歴代のMacintoshはそのどちらも使っていましたが、最近はAMD派です。ならばHackintoshもAMDが良い、と単純に決まりそうですが、そうでもありません。tonymacx86の推奨パーツのサイトでは、長らくNVIDIAのグラフィックスカードだけが推奨リストに挙げられていました。でも最近では、AMDのグラフィックスカードも少しずつ推奨されています。\nwww.tonymacx86.com\nでは、実際のところどうなんでしょうか。結論を先に書いておくと、それぞれメリット、デメリットがあります。ただ、10.13.4になってからAMDが優勢です。\nNVIDIAを選ぶメリット\nAMDに比べてハイエンドモデルのグラフィックス性能が高くて性能あたりの消費電力が少ない NVIDIAがmacOS用のドライバ(Web driver)を供給している。更新は早い Kepler (GTX 600シリーズと700の一部)以前ならmacOS標準ドライバだけで動く AMDを選ぶメリット\nFinal Cut Pro Xなどが最適化されているのでNVIDIAより高速に動く macOSにドライバが含まれているのでメーカ供給のドライバに頼らなくて良い macOS 10.13.4から外部GPUがサポートされて一部のモデルは接続するだけでそのまま使える AMD 最近のMacintoshではAMDを採用しています。なのでHackintoshでもAMDが最適の選択のように思えるかもしれません。\nmacOS 10.12.5以前 しかし、Hackintoshのグラフィックスカードとしては、AMDは問題の多い選択肢でした。macOSにはAMDのドライバーが含まれているものの、実際にはモバイルバージョンばかりが採用されています。そこでデスクトップ用グラフィックスカードとの互換性が低かったのです。頑張ってカーネル拡張(kext)にパッチしても、スリープからの復帰が不安定だったり、起動時に画面が出なかったりしました。なのでtonymacx86のガイドでもAMDは推奨されていませんでした。\nmacOS 10.12.6 ~ 10.13.3 ところがSierraバージョン10.12.6で事情が激変して、AMDが一気に魅力的な選択肢になりました。きっかけは、2017年のWWDCでThunderbolt接続の外付けGPUサポートが発表されたことです。開発キットとしてアップルが販売開始した外付けGPUボックス（External Graphics Development Kit）にはAMDのRadeon RX 580が内蔵されていました。そこで、AMDの現行モデルの一部が、macOSのドライバで正式にサポートされたのです。AppleのExternal Graphics Development Kit はSonnet社の製品を使っています。そのマニュアルをこちらで紹介しましたのでご覧ください。\nSonnetの互換GPUリスト (10.13.2以降)\nこれによると、macOS 10.13.2で挿すだけで動くグラフィックスカードは、\nRadeon RX 470/480/570/580（特にSapphire Radeon PULSE RX580が良い） Radeon Vega 56/64 AMD WX 9100 とのことです。ThunderboltはPCIeの信号をシリアル化して外部に引っ張り出したものなので、HackintoshでPCIe接続する場合においても、これらのカードを使うのが良いと思われます。\nmacOS 10.13.4 以降 10.13.4では外付けGPUボックスがいよいよ正式にサポートされました。その結果、10.13.3以前にあった問題点が全て解決されました。Apple社からも公式にサポートするグラフィックスカードが紹介されています。\nApple推奨グラフィックスカード\nこれによると、Polaris, Vega 56, Vega 64の3種類のアーキテクチャがサポートされているようです。具体的なチップは、以下です。\nAMD Radeon RX 470, RX 480, RX 570, RX 580, Radeon Pro WX 7100 AMD Radeon RX Vega 56 AMD Radeon RX Vega 64, Frontier Edition Air, Radeon Pro WX 9100 Sonnet社も、10.13.4に対応して、詳細な互換性リストを発表しました。AMDグラフィックスカードを購入する場合は、以下の記事で紹介したSonnetのPDF資料に、互換性があると記されているカードを購入すると良いです。\nSonnetの互換GPUリスト (10.13.4以降)\nということで、AppleやSonnetが推奨するAMD GPUを使えば、簡単にHackintoshできるので、お勧めです。このリストには比較的高価なGPUが多いのですが、お手軽なところではRX 570, RX 580でしょうか。\nその一方、AMDの製品は、NVIDIAと比較して上位機種の性能、性能あたりの消費電力で未だに劣っています。ただ、macOSで使うことを前提にすると、OSで正式にサポートされているアーキテクチャなので、色々と最適化されています。例えば、Final Cut Pro Xなどを使って性能比較すると、NVIDIAよりも圧倒的に良いスコアを叩き出します。\nOSが標準でサポートしてくれていることは、将来にわたって安心感があります。NVIDIAのWeb driverは、OSのバージョンアップにいまのところ敏速に対応してくれていますが、将来にわたって期待できる保証はありません。一方で、macOSが一旦サポートしたハードウェアは、NVIDIAの古いモデルと同様に、今後も機能し続けることが確実です。\nAppleのExternal Graphics Development Kit には、SAPPHIRE PULSE Radeon RX 580が搭載されています。他のブランドでも問題ないと思いますが、SAPPHIREが少しは安心かもしれません。他社ブランドと比べても安価な部類のようです。ちなみにPULSEは代理店の扱いが終了してしまったようで今は入手困難です。現在はクロック数が上がり、放熱部品やコンデンサ部品が強化された上位モデルのNITRO+がSAPPHIREの主流商品です。こちらでこの製品を使用した結果を紹介しています。\n/posts/62/\nNVIDIA Pascal, Maxwell MacintoshがこのところAMDだけを採用しているにもかかわらず、HackintoshではずっとNVIDIAが定番でした。昔、NVIDIAが採用されていた名残で、未だにドライバがOSに含まれていて、そのまま動いたからです。ただその魔法も、新しいアーキテクチャになると効かなくなりました。現行のPascalとその前のMaxwellアーキテクチャを採用したグラフィックスカードは、macOSの標準ドライバでは動きません。\n一方でNVIDIAは、独自でmacOS用のドライバを開発して配布してくれています。なので、これ （NVIDIAのWebページで配布されていて、Webという名前の含まれるkext群で構成されるのでWeb driverと呼ばれます）を使えば、最新のPascalアーキテクチャモデルが問題なく動きます。もちろん、それ以前のモデルもサポートされています。AMDではmacOSがサポートしてくれるモデルに制限があったのに対して、NVIDIAではメーカーが配布してくれるWeb driverをインストールするだけなので、とても簡単です。Web driverはmacOSのバージョンごとに配布されています。機能はそれほど変わらないようですが、macOSのバージョンチェックをして、合致しないビルド番号では起動しません。以下のサイトで、それぞれのビルド番号に合ったドライバのダウンロードURLがまとめて整理されています。\nwww.macvidcards.com\nmacOSのビルド番号は、「リンゴマーク」「このMacについて」のOSバージョンの文字をクリックすると、その横に表示されます。下の例では17E202です。\nPC自作ユーザ向けの最上位機種、GeForce GTX 1080Tiはとても強力で、性能あたりの消費電力も低いです。その一つ下のモデルのGTX 1080でも十分強力です。最近発売されたAMDのVega 64でも、性能は1080にある程度追いついたものの、価格と消費電力で負けているようです。なので、グラフィックス性能を重視したらNVIDIAが良いと思います。特に、Windowsと併用するとか、グラフィックス性能を必要とするゲームをするなどの場合は、NVIDIAを選ぶことにメリットがあります。\nグラフィックス性能は不要という人も多いと思います。普通にGUI操作したり動画を見る程度では、グラフィックス性能は問題にならないのも事実です。現行のNVIDIA製品の最下位GT 1030を使用するのも良いでしょう。8,000円程度です。ファンレスモデルもあります。\n1030はローコストだけど性能は高いようです。\nandrogamer.net\nWeb driverのおかげでNVIDIAならどれを選んでもだいたい大丈夫ですが、中には多少相性の悪いモデルもあるようです。例えば、GTX 1060はスリープからの復帰でノイズが出る問題が指摘されています。\nhttps://www.tonymacx86.com/threads/05-02-added-temporary-fix-pascal-gtx-1060-glitching-after-waking-from-sleep.220670/page-8\n今後、すぐに対応されるとは思いますが、その上位・下位の別モデル、1050tiや1070を購入した方が良いかもしれません。\nNVIDIA Kepler以前 Keplerアーキテクチャとそれ以前の古いカードも良いです。というのは、これらはWeb driverを入れなくても（入れても機能します）macOSの標準ドライバだけで動くからです。OSのバージョンアップに伴う新Web driverの発表を待つ必要もありません。（もっともNVIDIAの対応はとても早くて、24時間くらいで新OSに対応してくれますが）\nmacOSの標準ドライバだけで動く古いNVIDIAカードはたくさんあります。例えば以下のような製品が手に入るなら、安価に使えるようです。\nnvidia gt 9400 nvidia gt 9500 nvidia gt 210 nvidia gt 220 nvidia gt 9600 nvidia gt 240 nvidia gts 250 nvidia gt 610 nvidia gt 630 nvidia gt 640 nvidia gt 710 nvidia gt 730 **追記：**High SierraではKeplerは動くけど、それより古いFermiは動かなかったという報告があるようです。あまり古いものは避けて、Keplerのモデルにしておいたほうが無難かもしれません。できるだけ安く探すとなるとGT 710とかGT 730あたりでしょうか。\nIntel CPU内蔵GPUは使えるか？ 現行のMacintoshでもIntel CPU内蔵GPU (iGPU) を使っている機種はあります。が、それらはMacBookシリーズやMac miniで、モバイル用のCPUを使っていて、iGPUのモデルがデスクトップ用CPUと違います。でも、違うとは言っても、ある程度の互換性はあるようで、デスクトップ用CPU iGPUはHackintoshで「なんとなく動く」のが実情です。「なんとなく」というのは、時々画面が乱れるけど大体使える、とか、スリープからの復帰に失敗してハングする、とか、そういう状態です。iMacではAMDのGPUとデスクトップ用CPU iGPUが併用されることもありますが、使い方が違うのか、だからと言ってすんなり動くわけではないようです。ここで紹介したAMDかNVIDIAのグラフィックスカードを使用するのが良いと思います。\nということで、Kaby Lake, Skylake世代のiGPUは実用的ではないと思います。サーバにして画面はネット越しにしか見ないとか、スリープはさせないとかの使い方ならよいかもしれません。これに対して、Haswellでは、内蔵GPUがちゃんと使えました。Hackintosh界隈では、Haswellは良かったという声が聞こえます。もともと、Intelのデスクトップ用CPUの内蔵GPUはモバイル用に比べて非力です。モバイル機種に負けるようなグラフィックスは諦めて使わない、と考えるのが良いです。\n","date":"2017-09-10T12:15:51+09:00","image":"/uploads/external/41HGT0DgASL.jpg","permalink":"/posts/139/","title":"Hackintoshのパーツ選び 【その3：グラフィックス編】"},{"content":"**改訂版：**Slideの設定について追記しました(2020/2/25)\n**改訂版：**現在の状況に対応しました(2018/12/15, 2020/7/7)\nHackintosh自作のためのマザーボードの選び方を紹介します。\nマザーボードメーカはどこでもok 実のところマザーボードメーカはどこでも良いです。昔のマザーボードはBIOSを使っていました。その当時は、GigabyteがHackintoshと互換性が高いと言われていました。たまたま互換性の高い部品を使っていたこともあり、ハッカーな人たちが調べ尽くしていたからです。また当時は、それぞれのマザボに対応したパッチ当て済みのDSDTが必要でした。Gigabyte用のDSDTが多数配布されていたのに対し、他のメーカのDSDTはほとんど用意されていませんでした。なので、Gigabyte以外を選択する理由はありませんでした。\nところが、今のマザーボードはBIOSからUEFIに移行しました。もともとMacintoshはUEFIの元になったEFIに基づいて独自設計されています。UEFIはBIOSよりはMacintoshのアーキテクチャに近いので互換性が高いです。なので、UEFIに移行した現行のマザーボードなら、どのメーカを選んでも互換性に大差はありません。構成（スロットの本数、LANの数、m.2のソケット数などなど）が自分の目的に合っているか、見た目のデザインが好みかどうかなどで選んで良いです。\n多少注意すべきところは、使用されているLANチップとサウンドチップがHackintoshで使用可能なのかのチェックです。ただ現在流通している主流のマザーボード（つまりCoffee Lake用）は、だいたい大丈夫です。念のためにtonymacx86のサイトで確認するのが良いです。ここに掲載されているマザーボードと同じか、同じLAN, サウンドチップを使っているなら大丈夫です。\n以下に、それぞれのマザーボードメーカの印象をまとめておきます。PC自作する人たちはそれぞれのメーカに対する思い入れがあると思いますので、あくまで私見ということで読み流してください。\nGIGABYTE 一時期より代理店が少なくなったこともあり、PCパーツ売り場の面積も以前ほど大きくなく、シェアが落ちている気がします。しかし、BIOS時代には事実上GIGABYTEしか選択肢がなかったことから、Hackintoshする人たちの間では今でも人気です。GIGABYTEはHackintoshに向いているという評価がいまだにあります。しかし冒頭に書いたように、UEFIの時代になり、カスタマイズしたDSDTが不要になり、互換性は各メーカとも同じと考えて良いです。私もBIOS時代にはGIGABYTEしか使っていませんでした。それでBIOS設定画面は見慣れていて、馴染みのあるメーカです。\nASUS 現在シェアが一番のメーカーです。ユーザが多いので、ネット上でのHackintosh関連情報が得やすいメリットがあります。マザーボードの型番とHackintoshという単語で検索すれば、何かしらの情報が得られるのはありがたいです。ただ売れているブランドだけに価格は少し高めな気がします。他社より高めなので、廉価版を買うなら他社の方が良い気がします。ある程度上級モデルを買うのが良いと思います。慣れの問題かもしれませんが、BIOS設定画面は、個人的にはちょっとわかりにくいです。例えばSystem Agent Configurationというメニューの下に、VT-d設定やGPU設定があることがすぐにはわからないと思います。\nMSI 少し前に気に入って使ってました。まずは設定メニューがわかりやすいです。Gigabyte, ASUSと使ってきましたがMSIが一番わかりやすいです。でもこれはHackintoshとは関係ないですね。Hackintosh向けの理由もあります。それは、電源ボタン長押しでUEFIメニューに入れるGO2BIOS機能があることです。GO2BIOSは便利です。アップルの純正キーボードはBluetooth接続です。これを使っていると、タイミングによっては起動時の連打が効かなくてUEFI設定画面に入れないこともあります。そもそも、テンキー無しの純正キーボードにはDeleteキーが無いので、マザーボードによってはUEFI設定画面にすぐには入れないことがあります。なのでGO2BIOS機能はHackintosh向けの機能です。ただ、最近のMSI製品は、SATAの本数が少なくなっているので少し敬遠しています。\nASRock 最近人気のメーカです。コストパフォーマンスが良い製品を作っています。同じ価格なら作りが良いので、廉価版製品を買うならここが良いです。もちろん上位モデルも良くできていて評判が良いです。Hackintosher.comというサイトの記事ではASRockがお勧めのようです。実は使ったことがないので、Coffee LakeではぜひASRockで組んでみたいと思っていました。でも、PCIeスロット構成を検討した結果、ASUSになりました。\n/posts/71/\nメモリーの空き ブート時にmacOSカーネルが読み込まれるデフォルトのメモリー空間に連続的な空きがない場合、KASLR（カーネル番地乱数化）というセキュリティ機能をオフにして、読み込み番地を指定する（slideする）必要があります。\nslideでカーネル読み込み番地を調整する (Clover編)\n手元の300チップセットマザーボードをいくつか調べたり、皆さんのコメントをいただいたところ、ASUSは素直に空き番地があり、KASLRを有効のままで起動できるようです。MSIはKASLRをoffにしてslideする必要がありますが、それで安定して起動します。一方でGIGABYTEはメモリー空間が断片化されていて、苦労したというコメントをいただいています。ASRockについてもやはり設定に苦労するという話を聞いたことがあります。ということで、300チップセットマザーボードの場合、事例も多いASUSを選んでおくのが無難ではないかと最近考えています。(2020/2/25 追記)\nフォームファクタ もっとも一般的なATXマザーボードは、種類が多くて、好みで選べます。ケースが対応しているなら、ATXにしておけば良いでしょう。ただ通常はATXのPCIeスロットを使い切ることはありませんので、もう少し小さくても良いかもです。スロットの無い現行Macintoshからしたら贅沢な悩みですが。\nmicro-ATXのサイズは、スロット数が手頃なのですが、製品種類があまりなくてさみしいです。\n小型マシンを組めるmini-ITXフォームファクターですが、Hackintosh特有の制約があります。 内蔵GPUの中にはmacOSで使用すると時々画面にノイズが出たり、ちらついたりすることがあります。実際にMacで使われていないiGPUの場合、当然ですが不安定なことが多いです。その場合、グラフィックスカードが必須で、１本しかないmini-ITXのPCIeスロットはグラフィックスカードで埋められてしまいます。mini-ITXには、WiFi/Bluetoothの無線機能が搭載されていることが多いです。しかし、これは完璧には動きません。macOSはずっとBroadcom社の無線カードを使っていて、これ以外のメーカ製品（インテルなど）のカードはドライバがなく使用できないのです。無線機能を使うために、手軽なPCIeカードが入手可能ですが、上で述べたように、一本しかないPCIeスロットはグラフィックスカードで埋まってしまっています。なので、もともと搭載されている無線カードを、互換性のあるものと置き換えるか、またはm.2ソケットに取り付ける必要があります。無線機能については以下をご覧ください。\n/posts/138/\nチップセット 使用するCPUをサポートするチップセットを選びます。とはいえ、新品でパーツを買うとしたら、現行の最新チップセットの製品しか売られていないので、チップセット世代の選択で迷うことはないと思います。第9世代CPUならば、Z390, H370, B360、第10世代CPUならZ490などから選びます。\nZシリーズは、オーバークロック(OC)の機能と、CPUのPCIeを分割できる機能があります。後者は、グラフィックスカード2枚で描画高速化のできないmacOSにはあまりメリットが無いです。OCもしなければHシリーズでも良いです。ただ、Zシリーズは高価格の製品に使用されているので、基板の作りがしっかりしていたり、スイッチや表示の機能が豊富だったりします。また下位のチップセットになると、提供するPCIeのレーン数が少なくなります。PCIeとm.2とSATAなどで排他的な制約（片方を使うともう片方が使えなくなる）が発生しやすくなります。PCIeカードやSATAデバイスを多数利用する予定の場合は、注意が必要です。\n","date":"2017-09-08T11:44:00+09:00","image":"/uploads/external/81ltHOPGS0L._SL1004_.jpg","permalink":"/posts/140/","title":"Hackintoshのパーツ選び  【その2：マザーボード編】"},{"content":" Hackintoshのオススメは自作です。自作することで動作の確実なパーツを選択することができます。ここでは、現行のmacOSを動かすことを前提に、Hackintoshの自作方法を紹介します。tonymacx86のサイトでは、推奨パーツのリストが作られています。\nこのブログでも、自作Hackintoshのためのパーツ選びについて書いていきます。まずはCPU編です。(2020/7/7更新)\n第10世代のComet Lake CPU 第10世代デスクトップ向けCPUがComet Lake-Sです。型番が10から始まります。現時点 (2020/7/7) ではまだこれを搭載したiMacは発売されていませんが、間も無く、10900K, 10910, 10600Kのいずれかを搭載した製品が発売されると思います。以下は10600で作成した例です。AudioとEthernetの設定が多少厄介ですが、問題なく動きます。第9世代以前のパーツはだんだんと入手困難になると思われますので、移行せざるを得ないと思います。\nComet Lake-S 10600とZ490でmacOSを動かす\n第8第9世代のCoffee Lake CPU インテルの第9世代デスクトップ向けCPUがCoffee Lake-S Refreshです。型番が9から始まるCPUです。上記のtonymacx86のサイトでは、以下の9900(K), 9700(K), 9600(K), 9400, 9100が推奨されています。いずれも問題なく動くようです。第9世代CPUを搭載したiMac がEarly 2019モデルです。これに搭載された第9世代CPUは9600Kと9900Kの2種類です。9700Kは実機に搭載されていませんが、互換性に問題はないと思われます。でも、実機に搭載されている9900K, 9600Kは何かと安心できるかもしれません。\n第8世代CPUも現行のMacで採用されています。デスクトップ用CPUでMacに採用されているのは、iMac Early 2019に搭載された8700, 8600, 8500, 8100です。Mac mini Late 2018には、モバイル版の8700B, 8500B, 8100Bが搭載されています。B無しモデルとB付きモデルの違いはピンの違いだけで、中身は同じです。上記のtonymacx86のサイトでは、以下の第8世代CPUが推奨されています。これらは全て問題なく動きます。\n一方で、実機で採用された8600, 8500は、このリストに含まれていませんが、これもおそらく問題なく動きます。むしろ、実機に搭載されているので選択肢としては最適かと思われます。\n9900Kで作るHackintoshに関しては以下の記事もご覧ください。\n9900K搭載Z390マザーボードでHackintoshを作る\n第9世代も第8世代も、それほど違いはありません。名前もRefreshが付くだけで、どちらもCoffee Lakeです。特に理由がない限り、現行の製品の第9世代を選んでおけば良いと思います。ただし、現状（2019年1月）では、インテルの生産体制が整っていなくて、第9世代のローエンド製品が出揃っていません。Core i3で組みたい場合は、仕方なく第8世代しか選択肢がありません。本物のMacでも、現行機種は、上位モデルが第9世代、中位以下が第8世代になっています。\n以下ではさらに古いCPUも紹介します。こちらはさらに入手困難ですし、対応するマザーボードもすでに販売されていません。中古のマザーボードは部品が疲労していて不安定なことも多いです。Hackintoshのように挑戦的なソフトウェアを利用する場合に、ハードウェアまで不安定では原因究明が困難になります。できれば新品製品を使いたいところです。\n第7世代Kaby Lake CPU さらに1世代前のインテルCPUが第7世代Kaby Lakeです。型番が7から始まるCPUです。パーツ選び全体に言えることですが、実機で使われているパーツを選ぶのが確実です。デスクトップ用Kaby Lakeを使っている機種は、以下のiMacです。\nRetina 4K, 21.5-inch, 2017 Retina 5K, 27-inch, 2017 そこで使われているCPUは、以下の6種類です。\nIntel Core i7 (7700K, 7700) Intel Core i5 (7600K, 7600, 7500, 7400) 実機では採用がありませんが、実機に近い仕様のCore i3プロセッサも格別の苦労なく使えます。\nIntel Core i3 (7320, 7100) 第6世代以前のCPU さらに昔のMacで使われたCPUももちろん安定して使えます。入手が容易なCore-iシリーズデスクトップCPUで、実機で使われたものは、\nSkylake Core i7 6700K, Core i5 6600, 6500 Broadwell Core i7 5575R, 5775R, Core i5 5675R Haswell Core i7 4790K, 4771, 4770S, Core i5 4690, 4670, 4590, 4570, 4570R, 4570S Ivy Bridge Core i3 3225, Core i5 3470S, 3470, 3330S Core i7 3770, 3770S があります。これ以前のSandy Bridge世代まで遡ると、内蔵GPUの問題や、USB 3.0の問題などがあり厄介になります。（USB 3.0がチップセットでまだサポートされていなかったため互換性が低い。）古いCPUではHaswellとBroadwellがHackintoshで安定していると言われています。内蔵GPUも問題なく動きます。ただ、Broadwellは流通量が少なかったので入手困難なのでHaswellがおすすめです。\nIntel Core-iシリーズ以外のIntel CPU 一部のPentiumモデルは、Core-iとほとんど同じ構成だったりして、互換性が高いモデルもあります。最近評判になっているモデルに、G4560があります。コストパフォーマンスのあまりの良さに、Core-iシリーズの売り上げを妨害しているので、インテル社が生産縮小に動いているという噂すら立っているモデルです。\nただ、実機で採用されているCPUではないので、色々設定が必要で初心者向けではありません。\nIntel以外のCPU 最近話題のAMDでHackintoshしようとする人もいます。コストパフォーマンスがよく、夢がありますが、難易度は高いです。以前は、カーネルをAMD用にコンパイルし直す必要があり、どうしてもAMDを使いたいという強い意志を持った人以外にはおすすめできませんでした。しかし、最近はパッチが用意されていて、作り易くはなっているようです。\n","date":"2017-09-08T00:00:57+09:00","image":"/uploads/2017/10/20171029113120.png","permalink":"/posts/141/","title":"Hackintoshのパーツ選び 【その1：CPU編】"}]