Clover on Boot macOS

UEFI ShellをBIOSから起動する

Wed, 02 Jun 2021 23:54:14 +0900

EFI System Partition (ESP)の中のconfig.plistやkext類を変更して、macOSが起動しなくなってしまうことがあります。そんな時のためにUEFI shellを使えるようにしておくと復旧作業に役立ちます。CloverやOpenCoreにはUEFI shellを起動する機能がありますが、BIOSメニューから起動する方法をまとめました。

UEFI Shellで復旧する（おさらい）

UEFI shellを使えば、OSが起動する前段階のUEFIが制御している状態で、ファイルシステムの中身を編集できます。なのでOSの起動に失敗している場合に、その状況を治せる可能性があります。ただしUEFIから読み書きできるファイルシステムに限定されるので、APFSやHFS+の中身は見ることも書き換えることもできません。でも、通常FAT32でフォーマットされるESPは編集可能です。ESPの中のconfig.plistやkext類を変更して起動しなくなってしまった場合は、UEFI shellで編集できるので、システムを復旧させることが可能です。UEFI shellについては、過去の記事でも紹介しました。

起動しないマシンをUEFI Shellで救う

この記事では、CloverまたはBIOSからUEFI shellを起動して、ESPを復旧する方法を説明しました。OpenCoreでも、EFI/OC/ToolsにOpenShell.efiを入れておき、config.plistでこれを認識するよう設定すれば、OpenCoreの起動メニューからUEFI shellを起動できます。この先は、以前の記事のダイジェストになりますが、基本的には

OpenCoreを入れたESPの場所を探して、
shellコマンドで編集する

という作業を行います。UEFI shellの使い方は、こちらのサイトの説明が簡潔でわかりやすかったです。

UEFI Shell のコマンド - 一寸先は/dev/null

UEFIから見えるボリュームは、fs0:, fs1:, fs2: …のように名前がついています。shellコマンドから

ls fs0:

などと入力すれば、この例ではfs0:のルート部分が見えます。この内容を見ながら、OpenCoreが使っているESPの場所を探して行きます。接続されたボリュームの数が少なければ、fs0:かfs1:くらいでOpenCoreのESPが見つかりますが、多い場合は探すのが大変です。そんな時に、mapコマンドが便利です。mapとタイプすると（またはmap -bとすれば画面に合わせて表示が停止します）、例えば以下のような表示がされます。長いので…で省略してます。

> map
Mapping table
FS0: Alias(s):HD0c0a0b:;BLK1:
PciRoot(0x0)/Pci(0x14,0x0)/USB(0x2,0x0)/USB(0x0,0x0)/HD(1,MBR,...
FS1: Alias(s):HD1a65535a1:;BLK3:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(1,GPT,...
FS2: Alias(s):HD1a65535a2:;BLK4:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(2,GPT,...
FS3: Alias(s):HD1a65535a4:;BLK6:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(4,GPT,...
FS4: Alias(s):HD1a65535a5:;BLK7:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x0,0xFFFF,0x0)/HD(5,GPT,...
FS5: Alias(s):HD1b65535a1:;BLK9:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT,...
FS6: Alias(s):HD1c65535a1:;BLK12:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x2,0xFFFF,0x0)/HD(1,GPT,...
FS7: Alias(s):HD1d65535a1:;BLK15:
PciRoot(0x0)/Pci(0x17,0x0)/Sata(0x3,0xFFFF,0x0)/HD(1,GPT,...
FS8: Alias(s):HD2b:;BLK20:
PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0)/NVMe(0x1,...)/HD(1,GPT,...
...

これを見れば、探すべきドライブの見当をつけることができます。接続方式がUSB, SATA, NVMeと分類されています。またパーティションマップが、MBRなのかGPTなのかもわかります。このマシンでは、NVMeにOpenCoreのESPを入れているので、fs8:が探しているボリュームだとわかります。その場合、

fs8:

とタイプしてそのボリュームに移動します。Windowsでcドライブやdドライブに移動する方法と同じです。次に、cdコマンドでOCのディレクトリに移動して、

cd EFI\OC

ここでls, cd, cp, mv, cp, rm, edit, type (Unixのcatに相当)コマンドを駆使して、ファイルを操作します。ディレクトリの区切りが、macOSやLinuxと違い、Windows風の逆スラッシュになってます。config.plistのバックアップがあってそれがもしconfig_old.plistという名前なら、

mv config_old.plist config.plist

コマンドで元に戻せます。config.plistを変更する場合には、このように確実に動くバージョンを残しておくと、簡単に元に戻せるので楽です。config.plistを編集したい場合は、

edit config.plist

でエディタを起動します。このエディタでは、コントロールEでヘルプが表示されます。操作は簡単で、

Ctrl-G 行に移動。行番号の入力を促される
Ctrl-S ファイルを保存する
Ctrl-Q 終了する
Ctrl-F 検索する
Ctrl-R 検索・置換する
Ctrl-K 行をカットする
Ctrl-U 行をペーストする
Ctrl-O ファイルを開く
Ctrl-T ASCIIとUNICODEの切り替え
Ctrl-E ヘルプを開く
Ctrl-W ヘルプを閉じる

です。これで大体の編集は可能なので、config.plistを元に戻すことができます。config.plistを保存し、エディタを終了した後で、

exit

もしくは

reset

コマンドをタイプしてシェルを抜けます。resetコマンドはシステムがリセットされます。exitコマンドでは、OpenCore選択画面に戻ります。大体はexitコマンドでokですが、変更内容によっては変更が反映されないことがあります。resetの方がより確実です。

USBメモリーから起動する

UEFI shellはCloverやOpenCoreの選択画面から起動するだけでなく、UEFI環境でshellを直接起動することもできます。UEFI shellはHackintoshのためのツールではありませんので、こちらが本来の使い方です。

通常のUEFIマザーボードの起動ステップでは、FAT32でフォーマットされたドライブの中にある、EFI/Boot/bootx64.efiというファイルを実行しているようです。実際に、OpenCoreのESPにもEFI/BOOT/BOOTx64.efiというファイルがあります。WindowsをインストールしたドライブのESPにも、EFI/Boot/bootx64.efiというファイルがありました。ディレクトリ名やファイル名の大文字小文字はどちらでも良いようです。UEFI shellのプログラムにbootx64.efiという名前をつけて、このディレクトリにおけば良いようです。

そこで、まずはUSBメモリをFAT32でフォーマットします。パーティションマップはMBRでもGPTでも良いようですが、今回は単純にMBRで試しました。次にこのUSBメモリに、EFI/Boot/というディレクトリを作ります。この中に、OpenCoreで配布されている一式に含まれるOpenShell.efiをコピーして、これをbootx64.efiという名前に改名します。OpenShell.efiは、OpenCoreの起動メニューから動かすために、通常はEFI/OC/Tools/の中に入れているファイルです。その結果、USBメモリには、

EFI/Boot/bootx64.efi

のような位置と名前で、OpenShell.efiが入ります。このUSBメモリを挿したままコンピュータを起動し、BIOSメニューに入ると、Boot選択の画面に、以下のようにUSBメモリが現れるはずです。

ここでは、

UEFI: JetFlashTrabscend 4GB 8.07, Partition 1 (4.0GB)

という名前で見えています。小さなサイズのUSB 2.0のUSBメモリを使いました。このボリュームを選択して起動すれば、UEFI shellが起動します。使い道のない古いUSBメモリですが、UEFI shellを入れておけばいざというときに役立ちます。

BIOSメニューから起動する

マザーボードのBIOSメニューに、UEFI shellを起動する機能が提供されていることがあります。マザーボードメーカによって、事情が異なるようです。最近の状況を調べてみました。

MSIマザーボードの場合

以前の記事ではMSIのマザーボードの例を書いていました。MSIのマザーボードでは、独自にUEFI shellのソフトウェアを用意しているようで、BIOSメニューから選択するとそのshellが起動しました。なので、CloverやOpenCoreで用意したshellとは違うバージョンのshellが起動しました。現行のMSIマザーボードが手元に無いので確認できませんが、MSIのZ590マザーボードのマニュアルを見る限りでは、Settings/Save & Exit/Boot Overrideのメニューに、UEFI: Built-in EFI Shellという選択肢が健在のようですので、

引き続き内蔵のshellが起動できるようです。

ASUSマザーボードの場合

Z390 ROG MAXIMUS XI HEROでは、Exitメニューの中に、Launch EFI Shell from USB drivesという項目があります。USBメモリーのルートにUEFI shellのプログラムを、Shell.efiという名前で入れておけば、ここから起動できます。これ以外の名前ではダメなようです。

ただし、BIOS設定でCSMをenabledにしてレガシー起動を可能にしておく必要があります。

Shell.efiを置く場所は、UEFIが見ることのできるボリュームのルートならどこでも良いようです。USBメモリがFAT32でフォーマットされているなら、そのルートで良いです。でもHFS+やAPFSはUEFIから見えないのでダメです。ESP (EFIシステムパーティション）でもokです。また、BIOSメニューにはUSBメモリから起動とありますが、それ以外のドライブでも起動できます。なので、OpenCoreを起動しているESPのルートに、OpenCoreのToolsフォルダからUEFI shellを次のようにコピーしておくと良いと思います。もちろんファインダーのドラッグ&ドロップでもokです。

 % cp /Volumes/EFI/EFI/OC/Tools/OpenShell.efi /Volumes/EFI/Shell.efi

この作業をしておけば、ESPの内容をうっかり間違って設定してしまっても、UEFI shellを起動できます。

GIGABYTEマザーボードの場合

実を言うと最近はGIGABYTEマザーボードを使っていないので、良くわかりません。マザーボードメーカを、GIGABYTE –> MSI –> ASUS –> ASRockと遍歴してきたので、最近の事情に疎くて、UEFI shellがBIOSから起動できるかどうかわかりません。マニュアルを取り寄せて見た限りでは、BIOSメニューからUEFI shellを起動する機能に関しての記載が無いようです。もしかしたら起動できないのかもしれません。ご存知の方いらしたら情報よろしくです。

ASRockマザーボードの場合

ASRockの場合は、Exitメニューの中に、Launch EFI Shell from filesystem deviceという項目があります。これを選択すると、M.2, SATA, USBなどに接続されていてUEFIでアクセスできるファイルシステムのルートに置かれたshellプログラムを起動してくれます。ASUSの機能と全く同じです。なのでASRockでも、OpenCoreでは通常EFI/OC/Toolsに置かれるOpenShell.efiを、EFI直下にコピーして入れて置くと、このメニューからそれが起動します。

ASRockの場合は、シェルプログラムのファイル名はなんでも良いようで、例えばOpenShell.efiのままでも起動しました。OpenCore用に入れているOpenShell.efiを以下のコマンドのようにしてコピーしておくだけです。もちろんファインダーのドラッグ&ドロップでもokです。

 % cp /Volumes/EFI/EFI/OC/Tools/OpenShell.efi /Volumes/EFI/.

とはいえ、ASUSに合わせてShell.efiにしておいた方が混乱しなくて良いかもです。

各社UEFI shell機能のまとめ

各社のBIOS画面からのUEFI shell起動機能をまとめると

MSI: マザーボードに内蔵されているshellプログラムを起動する。
ASUS: EFIがマウントできるボリュームのルートに置いたshellプログラムを起動。プログラム名はShell.efiであること。
GIGABYTE: 不明。起動できないかもしれない。
ASRock: ASUSと同じく、EFIがマウントできるボリュームのルートに置いたshellプログラムを起動。プログラム名は任意のようで、OpenShell.efiなどでも起動。

となりました。MSI > ASRock = ASUS > GIGABYTEの順番に、利便性が良いと思います。ASUSとASRockの場合は、起動ボリュームのEFIにShell.efiとして入れておくと、いざという時に役立ちます。MSIは、shellプログラムがマザーボードに内蔵されているのでもっと安心です。

まとめ

Hackintoshの設定を変更して起動しなくなる経験は誰にでもあると思います。そんな時に便利なUEFI shell機能は、

OpenCoreやCloverの起動メニューから立ち上げる
起動ボリューム（USBメモリでも可）から立ち上げる
BIOSメニューから立ち上げる

などの方法で起動可能です。UEFI shell起動の方法と使い方を知っておくと、いざという時に対処できるかと思います。

OpenCoreのpicker画面を設定する

Tue, 24 Nov 2020 18:43:49 +0900

OpenCore 0.6.3のSample.plistを真似て作ったconfig.plistでは、ブート時のpicker選択画面で、macOSのUSBインストーラやWindowsドライブが現れませんでした。これを治しました。またpicker画面で使える便利な機能も設定しました。

デフォルト設定のpicker

OpenCoreが起動する際に、箇条書きやアイコンで現れる選択肢のことをpickerというのだそうです。Cloverの時は起動ボリュームが現れましたが、OpenCoreではツールのアイコンも一緒に現れるので、pickerと呼ぶのが適切なのかと思いました。

最近、このpicker画面にWindowsが入ったSSDが現れなくなっているのに気づきました。でもWindowsの使用頻度がほとんど皆無なので放置してました。その後、Big Surをクリーンインストールしようとしたときに、USBメモリーに入れたBig Surインストーラもpicker画面に現れませんでした。それで対応することにしました。OpenCoreのデフォルト設定では、WindowsもUSBメモリもpickerとして現れないようです。実際の例で示します。以下は、

macOSの入ったM.2 SSD
Windowsの入ったSATA SSD
Big Surインストーラが入ったUSBメモリ

が接続されたZ390マシンが起動した直後のpicker画面です。config.plistのほとんどの項目は、Sample.plistに記述のデフォルト状態です。上記の3個のボリュームに相当するpickerが現れて欲しいところですが、このうちの1個、macOSの入ったM.2 SSD (Macintosh HDという名前）しか現れません。Recovery はそのSSDに入っている復旧用ボリュームです。ほかに、UEFI ShellとNVRAMリセットのpickerが見えてます。

ScanPolicyを設定する

pickerを変更する方法の一つが、config.plistのMisc –> Security –> ScanPolicyという整数値を変更する方法です。これは起動選択のボリュームをスキャンする際のセキュリティ方針を決める項目のようです。得体の知れないボリュームから起動することは、セキュリティとして良く無いので、起動対象ボリュームの種類を決めておきましょうという項目のようです。

ScanPolicy = 0

ScanPolicyには、どのファイルシステムとどのデバイスを対象とするかをビットで設定します。詳細はOpenCoreのマニュアルに書いてあります。

• 0x00000001 (bit 0) — OC_SCAN_FILE_SYSTEM_LOCK, restricts scanning to only known file systems defined as a part of this policy. File system drivers may not be aware of this policy. Hence, to avoid mounting of undesired file systems, drivers for such file systems should not be loaded. This bit does not affect DMG mounting, which may have any file system. Known file systems are prefixed with OC_SCAN_ALLOW_FS_.
• 0x00000002 (bit 1) — OC_SCAN_DEVICE_LOCK, restricts scanning to only known device types defined as a part of this policy. It is not always possible to detect protocol tunneling, so be aware that on some systems, it may be possible for e.g. USB HDDs to be recognised as SATA instead. Cases like this must be reported. Known device types are prefixed with OC_SCAN_ALLOW_DEVICE_.
• 0x00000100 (bit 8) — OC_SCAN_ALLOW_FS_APFS, allows scanning of APFS file system.
• 0x00000200 (bit 9) — OC_SCAN_ALLOW_FS_HFS, allows scanning of HFS file system.
• 0x00000400 (bit 10) — OC_SCAN_ALLOW_FS_ESP, allows scanning of EFI System Partition file system.
• 0x00000800 (bit 11) — OC_SCAN_ALLOW_FS_NTFS, allows scanning of NTFS (Msft Basic Data) file system.
• 0x00001000 (bit 12) — OC_SCAN_ALLOW_FS_LINUX_ROOT, allows scanning of Linux Root file systems.
• 0x00002000 (bit 13) — OC_SCAN_ALLOW_FS_LINUX_DATA, allows scanning of Linux Data file systems.
• 0x00004000 (bit 14) — OC_SCAN_ALLOW_FS_XBOOTLDR, allows scanning the Extended Boot Loader Partition
as defined by the Boot Loader Specification.
• 0x00010000 (bit 16) — OC_SCAN_ALLOW_DEVICE_SATA, allow scanning SATA devices.
• 0x00020000 (bit 17) — OC_SCAN_ALLOW_DEVICE_SASEX, allow scanning SAS and Mac NVMe devices.
• 0x00040000 (bit 18) — OC_SCAN_ALLOW_DEVICE_SCSI, allow scanning SCSI devices.
• 0x00080000 (bit 19) — OC_SCAN_ALLOW_DEVICE_NVME, allow scanning NVMe devices.
• 0x00100000 (bit 20) — OC_SCAN_ALLOW_DEVICE_ATAPI, allow scanning CD/DVD devices and old SATA.
• 0x00200000 (bit 21) — OC_SCAN_ALLOW_DEVICE_USB, allow scanning USB devices.
• 0x00400000 (bit 22) — OC_SCAN_ALLOW_DEVICE_FIREWIRE, allow scanning FireWire devices.
• 0x00800000 (bit 23) — OC_SCAN_ALLOW_DEVICE_SDCARD, allow scanning card reader devices.
• 0x01000000 (bit 24) — OC_SCAN_ALLOW_DEVICE_PCI, allow scanning devices directly connected to PCI bus
(e.g. VIRTIO).

LSB 2ビットは、ファイルシステムとデバイスを限定するかどうかのビットで、0にしておけば全てのボリュームが現れるようになります。なのでScanPolicyを0に設定してしまえば、全てのボリュームが現れます。下の例は、同上のマシンでScanPolicyを0にした時のpickerの様子です。WindowsとUSBインストーラ（丸いBig Surアイコン）が追加されました。

左端に現れているオレンジ色のEFIというpickerは、USBメモリのESPです。OpenCoreが入ってます。これを選択すると、「すでにOpenCoreで起動している」というような内容のメッセージが出るだけです。Cloverの入ったESPが他のドライブにあると、それも現れます。ESPの内容がCloverの場合はCloverに切り替わります。起動できるESPがある場合に、それが現れてしまうのは、ちょっと煩雑な感じがします。でも、実際のMacでも、オプションキーで起動すると、同様に起動可能なESPがpicker画面に出現します。実機と同じ仕様と思えば納得できます。

ScanPolicy = 19859203

ScanPolicy = 0で全く困らないのですし、そう設定するように指示するガイドページもあります。実際OC Gen-Xが自動生成するconfig.plistも0に設定してます。ただ、せっかくセキュリティの機能が用意されているのに、無視するのももったいない気がします。正しく必要なものだけ設定したいと考えました。

ScanPolicyのデフォルト値は17760515です。ScanPolicyの設定そのものをconfig.plistから削除するとこのデフォルト値になります。Sample.plistでもこの値が設定されています。このデフォルト値では、

ファイルシステムはAPFSのみ
デバイスはSATA, SAS, NVMe, SCSI

を対象とする設定です。APFSのみなので、Windowsはもちろん、HFS+だったBig SurインストーラUSBも現れないわけです。さらには、デバイスでは、USB, DVD, FireWire, SDカード, PCIバスが除外されています。Big SurインストーラUSBはデバイスとしても除外されていました。そこで、このデフォルト値に追加して、

ファイルシステムにHFS+とEFI System Partition (ESP) を追加する
デバイスにUSBを追加する

ような設定にしました。それが10進数で19859203になります。ファイルシステムの選択肢にNTFSのビットがあったので、Windowsならそれだろうと考えたのですが、違ってました。ブートローダーがESPにある関係か、NTFSビットを立ててもWindowsのpickerは現れませんでした。ESPビットを設定する必要があるようです。ScanPolicyを19859203に設定すると、（上の写真と同じですが）以下のようになりました。

ビットの計算をする

皆さんはビットを立てたり、外したりするのにどうやって計算されてます？今回は手軽で便利なmacOS標準搭載の「計算機」を使いました。「計算機」はメニューの「表示」「プログラマ」を選ぶと16進数、8進数などを扱えます。入力や結果はコピペできるので便利です。

今回の計算は以下のようにして行いました。まずは、ScanPolicyのデフォルト値の、17760515をコピーします。計算機を10進数に切り替えて、ペーストします。その後、16進数に切り替えると、0x010F0103であることがわかります。ビットがわかりやすいです。

ここで、スキャン対象のファイルシステムにHFS+とESPを追加して、対象デバイスにUSBを追加します。それぞれのビットは、OpenCoreのマニュアルによると、以下です。

HFS+ : 0x200
ESP : 0x400
USB : 0x200000

なので、合計で0x200600のビットを立てれば良いわけです。そこで「計算機」で「OR」を押した後、0x200600を入力して、イコールを押します。出てきた結果は16進数で0x12F0703になります。10進数に切り替えれば、設定すべき10進数、19859203が得られます。これもコピーしてProperTreeまたはPlistEDPlusにペーストすれば良いです。

「計算機」にはRPN（逆ポーランド記法）で操作するモードもあるので、マニアックな人も満足できると思います。

おまけ1: 表示pickerを減らす

Pickerがこれくらい並んでも（USBメモリーが挿さってなければ2個減りますし）適切に賑わっていて良いと思いました。でも、efiツールをたくさんインストールしている場合は、それが右端に追加されるので、煩雑だと感じることもあるようです。

そこで、使用頻度の低いpickerを非表示にするオプションがあるようです。config.plistのMisc –> Boot –> HideAuxiliaryです。デフォルトではfalseですが、これをtrueにすると、写真のpickerのうち、Recovery, Reset NVRAMが非表示になります。また、Misc –> Toolsで追加しているefiツールItemの中のAuxiliaryをtrueにしているツールも非表示になります。現在はOpenShell.efiを追加してありますので、HideAuxiliaryをtrueにした上で、さらにOpenShell.efiの設定でAuxiliaryをtrueにしました。その結果、表示されるpickerが以下のように減りました。

ここでスペースキーを押すと、非表示にしていたpickerが元通りに表示されます。

おまけ2: -vを一時的に有効にする

Misc –> Boot –> PollAppleHotKeysをtrueにすると（デフォルトではfalseです）picker画面でApple標準のホットキーがいくつか使えるようになります。使用可能になるキーは以下です。

CMD+C+MINUS — disable board compatibility checking.
CMD+K — boot release kernel, similar to kcsuffix=release.
CMD+S — single user mode.
CMD+S+MINUS — disable KASLR slide, requires disabled SIP.
CMD+V — verbose mode.
Shift — safe mode.

ありがたいのはコマンド + vです（vは小文字でok）。ブートオプションには-vを付けずに、シンプルなリンゴマークだけで通常は起動していて、ちょっと動作が怪しい時だけ、コマンド + vでverbose modeに入れるようになります。Cloverだと起動画面からオプションを一時的に切り替えることができたので、同じように運用できます。

まとめ

ScanPolicyをデフォルト値から変更して、WindowsやUSBインストーラがpickerに現れるよう設定しました。また、HideAuxiliaryとPollAppleHotKeysもデフォルト値から変更しました。

Big SurでRadeon RX 5700 XTのスコアが大幅に改善

Sun, 15 Nov 2020 16:46:58 +0900

Big SurになってRadeon RX 5700 XTのGeekbench 5のスコアが格段に改善されました。RX 580と比較するとOpenCLもMetalも1.6倍くらい高いスコアでした。

Geekbench 5ベンチ結果

Catalina (10.15.5および10.15.6)とBig Sur (11.0.1) で、RX 580とRX 5700 XTのOpenCL/Metalスコアを計測しました。いずれもOpenCLとMetalのベンチマークを交互にそれぞれ３回測定し、その結果を平均したものです。測定に使用した本体は、ほぼZ490マザーボードに10900Kの構成ですが、Big SurでのRX 580の測定だけはZ390 + 9900Kの構成です。

Catalinaのスコアは以前の記事などで計測したものです。Catalinaだと、RX 5700 XTはRX 580に比べて同程度か、場合によっては劣っていることもありました。特にMetalの性能が弱い感じでした。本来なら古くて安価なRX 580よりも性能が高いはずなのですが、macOSのドライバの作り込みが不足しているようでした。

Big Surのパブリックベータが出ると状況は変わります。ベータのバージョンが進むたびに、RX 5700 XTのスコアが少しずつ改善されていきました。そして公開版11.0.1では、最後のベータ版からさらに改良されたようで、RX 580に圧倒的な差をつけてます。一方でRX 580は、Catalinaの頃とスコアがほとんど変わっていません。

ちなみに話題のM1のiGPUは、OpenCLが19000くらいのようです。Intel UHD Graphics 630が5000くらいでしたから、iGPUとしては頑張ってますが、ちゃんとしたグラフィックスカードには及ばないようです。

macOSでグラフィックス性能を求めるなら、RX 5700 XTが1番の選択肢と思います。また、他のNaviアーキテクチャのRX 5000シリーズも性能改善されているのではないかと思われます。RX 5000シリーズを使うためには、

WhateverGreen.kext (グラフィックス関係のパッチ集)
Lilu.kext (パッチを当てる機能を提供するkext)

を入れ、CloverやOpenCoreのブートオプションに、WhateverGreenに指示するオプションである、

agdpmod=pikera

を追加します。

Vega 64も性能向上

コメントでyoshiiさんから教えていただいた情報によるとVega 64でも17% ~ 19%くらい改善しているようです。

MacOS 10.15　54050(OpenCL)/52086(Metal)
MacOS 11　64061(OpenCL)/60921(Metal)

リムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)

Sun, 15 Nov 2020 01:10:14 +0900

抜き挿し可能なリムーバブルSATAドライブベイで、HDD/SSDのホットプラグを可能にするパッチを以前ご紹介しました。Big Surでパッチパターンが変わったので、これに対応しました。

5.25インチベイ用リムーバブルHDDラック

上の写真のような、5.25インチベイに取り付けるリムーバブルHDDラックは、本物のMacには無い、自作hackintoshならではの便利な装備です。でもHDDラックを取り付けただけではHDD/SSDのホットプラグが効きませんでした。macOS起動時にリムーバブルベイに装着されているHDD/SSDは認識され、ファインダー上でアンマウントして、安全に取り外すことはできます。しかし、macOS稼動中にHDD/SSDを挿しても認識されません。そこでホットプラグが機能するようにconfig.plistにkextパッチを当て、対応していました。

SATA接続HDD/SSDのホットプラグ

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

このパッチが効くと、マザーボードのチップセットが持っているSATA端子以外、つまり、マザーボード上にSATAチップを追加して増設したSATA端子が、リムーバブルドライブとして扱われるようになります。チップセットがサポートするSATAは通常6個ですので、8個のSATAを持っているマザーボードは、最後の2個が対象になります。また、PCIeスロットにSATAアダプターカードを挿してSATA端子を増設した場合も、そこに接続されるドライブがリムーバブルになります。例えば以下のような、Marvell 88SE9230チップセットや、ASMedia ASM1061チップセットを搭載したカードです。

ところが、Big Surにバージョンアップしたら、このパッチが効かなくなったようで、ホットプラグが機能しなくなりました。調べたところパッチパターンが変わっていたようです。

パッチの方法

パッチは、/System/Library/ExtensionsにあるAppleAHCIPort.kextのバイナリファイルの該当部分を、0x90 (マシンコードでNOP, No OPerationに相当します) に置き換えるものです。置き換える範囲は、ファイルの中の0x40200000というデータ列の4バイト、その前8バイト、その後14バイトの、合計26バイトです。この26バイトのパターンが、Big Surになって変わっていたようで、パッチが効かなくなっていました。

そこで、Big Surのkextの中で0x40200000を探して、書き換えるべきデータ列を調べなおすことにしました。まずは、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをhexdumpして、lessコマンドで表示を一旦停止しておきます。

% hexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less

lessが起動しているところ、以下のサーチコマンドをタイプし、40 20 00 00を探します。

/40 20 00 00

ところが運悪く途中に改行が入っているようで見つかりません。40 20だけでもう一度探索します。

/40 20

今度は見つかりました。改行の先に00 00があるので、間違い無いようです。他にも40 20は見つかりますが、その先に00 00が続く場所はありません。もしもこれで見つからなければ、他の場所に改行が入っているかもしれませんので、

/20 00 00

で探せば良いと思います。

今回、発見できた場所の前後のデータは以下です。

0003da0 01 00 00 89 d1 81 e1 40 60 02 00 81 f9 40 20 00
0003db0 00 75 0c 81 e2 bf 7f ff ff 89 93 69 01 00 00 f6
0003dc0 c2 40 74 7e 3d 09 01 01 00 72 77 44 89 fe c1 ee
0003dd0 0a 81 e6 80 00 00 00 81 e2 7f ff ff ff 89 d1 09

ここで発見した0x40200000の4バイト、その前8バイト、その後14バイトの、合計26バイトをNOP (90) に置き換えるパッチを作ります。つまり、

Find --> 81E14060 020081F9 40200000 750C81E2 BF7FFFFF 89936901 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

というパッチを作ります。前回のパッチパターンに類似していますのでおそらく合っていると思います。

config.plistをテキストエディタで編集する場合はbase 64に変換します。詳しくはこちらをご覧ください。Findするデータはbase 64では以下になります。

% echo -en "\x81\xE1\x40\x60\x02\x00\x81\xF9\x40\x20\x00\x00\x75\x0C\x81\xE2\xBF\x7F\xFF\xFF\x89\x93\x69\x01\x00\x00" | base64 
geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=

Replaceするデータは、NOPコマンド列である9090…なのですが、このbase 64は以下です。

% echo -en "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" | base64
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=

Cloverの場合

最近Cloverは使っていないので検証できませんが、Cloverの場合、config.plistに以下を書けば良いはずです。

<key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>

OpenCoreの場合

OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、使用するキーは以下です。

Comment : Cloverと同じ。人が読むためのメモ書き。
Find : Cloverと同じ。検索データ列。
Replace : Cloverと同じ。置き換えるデータ列。
Identifier : CloverのNameに相当するキー。kextを指定するためのIDで、バンドルIDを使う。
Enabled : パッチを有効にする場合はtrueにする。（有効にしたいのでtrueにする）
Count : パッチを当てる箇所の数。今回の場合は1回なので1。
その他のキー : デフォルトで良いので省略。

kextのバンドルIDは、システム情報で知ることができます。

システム情報の拡張機能のAppleAHCIPortの項目を選択すると、

com.apple.driver.AppleAHCIPort

であることがわかります。これはBig Surになっても変更はありませんでした。そこで、OpenCoreのパッチは以下になります。

<key>Kernel</key>
<dict>
 <key>Patch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Count</key>
 <integer>1</integer>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>geFAYAIAgflAIAAAdQyB4r9///+Jk2kBAAA=</data>
 <key>Identifier</key>
 <string>com.apple.driver.AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>
</dict>

ProperTreeやPlistEDPlusなどのアプリケーションで設定するなら、16進数でそのまま書けます。ProperTreeでは16進数のデータの8バイトごとにスペースを入れる流儀のようですが、

81E14060 020081F9 40200000 750C81E2 BF7FFFFF 89936901 0000

PlistEDPlusではスペースを入れないようです。

81E14060020081F940200000750C81E2BF7FFFFF899369010000

以下はPlistEDPlusの例です。Item番号はたまたま7番目になっていますが、何番目でも大丈夫です。

動作確認

パッチをOpenCore 0.6.3のconfig.plistに追加したところ、Big Surでもこのホットプラグが機能しました。オレンジ色のドライブがmacOS起動後にリムーバブルベイに取り付けた3.5インチHDDです。

補足

最初の記事、

では、

Find --> 40600200
Replace --> 00000000
AppleAHCIPort

というパッチを当てれば、ASMediaやMarvellのチップでホットプラグが可能になるという情報を紹介しました。今回、Big Surで試したところ、マウントする際にシステムが落ちてしまう現象が発生しました。PCIeに挿すASMediaやMarvellのSATAカードでも、ここで紹介した長いパッチは安定して動きますので、この記事の方式を使ってください。

まとめ

リムーバブルドライブベイのホットプラグを可能にするパッチを、Big Sur用に書き換えて動作を確認しました。これからも、しばらくはBig Surへの対応作業を楽しめそうです。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

Mon, 12 Oct 2020 00:29:02 +0900

昔作った、Haswell世代Core i5-4250U搭載Intel NUCをOpenCoreとBig Sur (Beta 9) にアップデートしました。Ivy Bridge搭載初代NUCの代わりに省電力サーバとして使いたいと考えてます。

Intel NUC D54250

Intel NUCは、ノートPC用CPUを搭載したデスクトップです。低消費電力なので電源を入れっぱなしの家庭用サーバに向いていると思います。今までは、サーバとしてIvy Bridge搭載の初代NUCを使っていました。でもBig Surでサポートされなくなるので、Haswell搭載のD54250に更新することにしました。D54250には、すでにMojaveを入れてあったのですが長らく放置してました。押し入れから引っ張り出して、CloverからOpenCoreに差し替えて、Big Surに備えることにしました。

Intel NUC D54250, 4250U

Intel NUC D54250が搭載するCore i5-4250Uは、MacBookAir6,1, 6,2で使用されているCPUで、macOSとの互換性が高く安定しています。Big Surでもサポートされます。D54250には2種類のケースがあり、末尾がWYKのモデルは薄型筐体で、WYKHは2.5インチドライブを内蔵できる厚型モデルです。古いので探せば安価に入手可能です。WYKHはドスパラで一時期税込3万円未満で売られていましたし、現在は中古店で2万円くらい、オークションでは1万円前後で入手可能なようです。

ハードウェアの構成をまとめると以下です。

Intel NUC D54250WYKH (WYKHの他にWYK, WYBがあります。WYKは2.5inchの入らない薄型。WYBは基板だけです。)
CPUはIntel(R) Core(TM) i5-4250U CPU @ 1.30GHz
グラフィックスはIntel HD Graphics 5000 (稀にアーティファクトが出ます)
無線カードはです。WiFiはOOBです。Bluetoothは後で説明するようにkextが必要です。

シリアル番号にこだわる

昔に割り当てたシリアル番号には、今から見るといろいろ疑問なところがあったので、変更しました。まず機種IDは、4250Uが搭載されているMacBookAir6,2にしました。6,1でもほぼ同じなので、どちらでも良いです。OpenCoreの一式に入っているmacserialコマンドで機種を指定すると、シリアル番号とボードシリアル番号の候補が出ます。

 % ./macserial --model MacBookAir6,2
C02L20YVF5V7 | C02328501GUFD47JA
C02NLHYMF5V7 | C02443100J9FD471M
C02NNLZBF5V7 | C02445802GUFD47JA
C02MT0WEF5V7 | C02423500GUFD47AD
C02KGYYNF5V7 | C02312301QXFD471M
C02P3QYNF5V7 | C025022004NFD47FB
C02ND4Y8F5V7 | C02437303QXFD478C
C02M20CTF5V7 | C024011304NFD471H
C02NMFYJF5V7 | C02444501CDFD47UE
C02MNSZ6F5V7 | C02418301J9FD47AD

この中から一つを選べば良いのですが、念のためにその一つの詳細を調べてみます。

% ./macserial --info C02P3QYNF5V7
Country: C02 - China (Quanta Computer)
Year: P - 2015
Week: 3 - 3 (15.01.2015-21.01.2015)
Line: QYN - 2742 (copy 1)
Model: F5V7 - MacBookAir6,2
SystemModel: MacBook Air (13-inch, Mid 2013)
Valid: Possibly

製造週が2015年の第3週になってます。MacBookAir6,1, 6,2は2013年6月から2015年3月まで製造されたのですが、2014年4月に4250Uから4260Uにマイナーアップグレードされています。なので同じMacBookAir6,2用のシリアルでも、できれば2013年6月から2014年4月までの番号にしたいところです。ということで、macserialで製造年を2013、製造週を30に指定し、シリアル生成します。

./macserial --model MacBookAir6,2 --year 2013 --week 30
C02L40WPF5V7 | C02330701QXFD471M
C02L4LYLF5V7 | C023303064NFD471M
C02L4YYTF5V7 | C023309024NFD47FB
C02L4BZFF5V7 | C02330102GUFD47FB
C02L40S8F5V7 | C023303064NFD471M
C02L4XZEF5V7 | C02330101QXFD47UE
C02L4TY0F5V7 | C02330405CDFD47AD
C02L40ENF5V7 | C02330403GUFD471F
C02L4069F5V7 | C02330102GUFD47FB
C02L40FQF5V7 | C023303064NFD471M

このうちの一つを–infoオプションで調べてみると、2013年の30週（2013年7月23日から2013年7月29日）でした。発売されて1ヶ月後くらいなので妥当な製造日だと思います。

シリアル番号の特定の4桁部分、上の例では、F5V7とFD47は機種特有の番号です。macserialのソースコードを見ると、他にも多数の選択肢があるのですが、オプションで指定しないとこの番号しか生成されません。このF5V7が4250U搭載の2013年版MacBookAirなのかどうかは、すぐに調べる方法がなさそうでした。ただ、Appleのサイトでシリアル番号が有効かどうかを調べたところ、たまたま実機と同じシリアル番号が見つかりました。（実機と合致する番号は使ってはいけないです）

これから、F5V7はMid 2013の4250U搭載モデルの番号と考えて良いと思いました。

BIOSをアップデートする

このNUCでは起動時に時々「CMOSのチェックサムがおかしい」というメッセージがBIOS起動画面に出ました。ボタン電池を外して放置しても出てくるので、BIOSが壊れかけている疑惑もありました。なので、この際、アップデートすることにしました。現在のBIOSは、昔メンテナンスした時にアップデートしたWYLPT10H-86A.0045というバージョンでした。

インテルのサイトで調べたところ、2019年9月2日に最新のBIOSが出ていて、それは、WYLPT10H-86A.0054でした。早速ダウンロードして、USBメモリーに入れて、BIOS起動画面からアップデートしました。

https://downloadcenter.intel.com/ja/download/29075/BIOS-WYLPT10H-?product=76977

NUCのBIOSアップデートにはちょっとした注意点があります。アップデートが一段落すると、画面に、「正常にアップデートされました」という表示が出て、そのまま動かなくなります。Ivy BridgeモデルのNUC BIOSをアップデートした時に、しばらく放置しても何の変化もなかったので、ここでリセットすれば良いのかと思い電源を切ったことがありました。すると2度と起動しなくなりました。（このNUCをしばらく放置していたら起動するようになってました。理由は不明ですが、バックアップされていた設定が消えて起動できるようになったのかもしれません。）なので重要なことは、「正常にアップデートされました」という表示が出ても、自動的に再起動されるまで辛抱強く待つということです。2〜3分くらい待たされる感じがします。

OpenCore 0.6.2を入れる

シリアル番号をより正しいものに変更し、BIOSを最新にアップデートした後、入っているCloverも最近のもの (5122) に入れ替え、macOSも最新の10.15.7 (19H2) にアップデートしました。問題なく稼働しているのですが、Big Surへの移行準備のために、ブートローダをOpenCoreに入れ替えることにしました。

まずはダウンロードしたOpenCore 0.6.2のX64フォルダにあるEFIフォルダを、ESPにコピーします。次に以下のガイドに従って、設定を進めます。

Desktop Haswell and Broadwell | OpenCore Install Guide

ACPIフォルダの中には、以下の二点が必要です。

SSDT-PLUG.aml
SSDT-EC-DESKTOP.aml

CPU毎に必要なamlのリストは以下でまとめられています。

What SSDTs do each platform need | Getting Started With ACPI

ここで必要とされているデスクトップ用SSDT-EC.amlはこちらのサイトからダウンロードしました。そこでのファイル名がSSDT-EC-DESKTOP.amlとなってましたので、名前をそのまま使うことにしました。

Kextフォルダの中は、今回は以下にしました。

WhateverGreen.kext
VirtualSMC.kext
SMCSuperIO.kext
SMCProcessor.kext
Lilu.kext
IntelMausi.kext
AppleALC.kext

SMC….kextはハードウェアモニター用なのでなくても良いです。

config.plistの内容は、上記のガイドのページに従って設定しました。説明を読めば、どれが必要か判断できると思います。DevicePropertiesの箇所には、

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>AwAiDQ==</data>
 </dict>

を加えました。Intel HD Graphics 5000を表示用に使用する設定です。また、

<key>PciRoot(0x0)/Pci(0x1b,0x0)</key>
 <dict>
 <key>layout-id</key>
 <data>AQAAAA==</data>
 </dict>

も加えました。オーディオのレイアウトIDを1番に設定する記述です。Pci(0x1b,0x0)のPci番号は、Hackintoolを使って、そのPciタブからPCIデバイス一覧を見て、このIOReg NameにHDEFとある行を探して、HDオーディオデバイスを特定しました。

レイアウト番号はとりあえず1番からテストしようとしたら、1番で正解でした。前面のヘッドフォン端子から音が出ることを確認しました。

Sample.plistの初期設定でKext Updater.appを起動すると、「Misc, Security, ExposeSensitiveDataの1, 2ビットをonにする」ように指示が出ます。デフォルトではExposeSensitiveDataが6だったので7にしました。

このNUCには、前面にUSB 2.0端子が2個、背面にUSB 3.0端子が2個あります。また内部のmini PCIeソケットには、USB 2.0が1個あります。さらに、ケースに配線の余裕が無いので使うことはないですが、基板上にUSBコネクタがいくつかあります。ただ、それらを全部加えても15個のようです。なのでconfig.plistのXhciPortLimitで15個制限を外したり、15個制限に対応するkextを作ったりする必要は無いです。

Big Sur beta 9を入れる

Big Surベータ9を入れました。MacBookAir6,1と6,2は、Big Surが動く最古のMacです。また4250UはBig Surが公式対応する最弱のCPUと言えます。ギリギリのスペックでしたが、インストールは、インストーラを起動するだけで簡単でした。インストール途中の再起動では、macOS Installerというドライブが現れて選択されていました。インストール後の動作も問題ありませんでした。ベータ9は安定していて充分にキビキビ動くので、完成度は高いと思います。

Geekbenchをしてみたところシングル600, マルチ1200台程度でした。遅いですね。Apple Silicon搭載Mac miniが800/2900くらいと言われてますので、完全に負けてます。（追記：Apple Silicon搭載Mac miniが発売された後、スコアが明らかになりました。1680/7400くらいのようです。圧倒的に負けてました。）

ちなみに同じ4250U搭載のMacBook Air Mid 2013のスコアも大体同程度です。妥当な結果のようです。

Bluetoothを使う

NUCのmini PCIeソケットに、無線カードを挿しています。WiFiとBluetoothの機能のあるカードです。このうちWiFiはOOBで設定不要で動きます。Bluetoothを動かすためには以下のkextが必要でした。

BrcmPatchRAM3.kext
BrcmFirmwareData.kext
BrcmBluetoothInjector.kext

これらはKext-Updater.appからダウンロードしました。メイン画面のKextmanagerボタンをクリックして、次の画面でBrcmPatchRamを選びます。

すると8個のkextがダウンロードされます。このうち太字の3個を使ったわけです。

BrcmBluetoothInjector.kext
BrcmFirmwareData.kext
BrcmFirmwareRepo.kext
BrcmNonPatchRAM.kext
BrcmNonPatchRAM2.kext
BrcmPatchRAM.kext
BrcmPatchRAM2.kext
BrcmPatchRAM3.kext

無線カードのファームウェアにパッチを当てるもののようです。初期の頃は、このうちBrcmFirmwareData.kextとBrcmPatchRAM.kextを使用するのが一般的だったようです。ファームウェアのデータkextとパッチしてくれるkextという組み合わせかと思います。その後Catalinaの頃のガイドでは、BrcmPatchRAM2.kextとBrcmFirmwareData.kextに加えて、BrcmBluetoothInjector.kextも必要になったと書かれていました。今回ダウンロードしたら、さらにBrcmPatchRAM3.kextという新しそうな名前のkextがありました。ということで、上記の3個のkextを使うことにしました。この結果、システム環境設定からBluetoothが見えて、アップル純正キーボード・トラックパッドでの動作を確認しました。

Big Sur beta 10を入れる

追記です。その後、Big Surベータ10を入れました。ベータ9からのアップデートはインストーラを起動するだけです。ただ、config.plistで、

Misc – Security – SecureBootModel を Disabled にする

ように変更しました。これをしないと多分起動しないようです。詳しくはこちらをご覧ください。

macOS Big Sur 11.0 Beta 10 をインストール

GenSMBIOSを使って機種情報を設定する

Sun, 28 Jun 2020 10:04:25 +0900

以前、シリアル番号を決めるツールとしてmacserialを紹介しました。macserialを使いやすくしたツールにGenSMBIOSがあります。OpenCoreのガイドでよく使われていますので試してみました。config.plistにシリアル情報などを書きこめて便利でした。

Hackintoshの機種設定

Hackintoshを作ったら、それに機種ID、シリアル番号、UUID情報などのID情報を設定しておく必要があります。正しく設定しないと、macOSが動かないことがありますし、iCloudのサービスが使えないことがあります。さらにはユーザのApple IDが使用禁止にされてしまうこともあります。これらの設定はconfig.plistの中に書きます。CloverではSMBIOSのセクション、OpenCoreではPlatformInfoのセクションに書き込みます。

UUIDなどのIDは世界に一つしかない番号ならばなんでも良いです。uuidgenなどのコマンドで乱数発生させて作れば良いです。またOpenCoreのROM番号はEthernetのMACアドレスを流用するのが一般的です。一方でMacのシリアル番号は、生産地、生産年・週、番号、機種固有番号などから構成されています。全体の構成はMacの世代で違うことがありますし、機種固有番号は機種ごとに違います。シリアル番号の規則をリバースエンジニアリングして、生成・チェックするソフトが作られています。それがmacserialです。シリアル番号の仕組みとmacserialの使い方は、以下の記事で詳しく紹介しました。

Macシリアル番号の仕組み

GenSMBIOSの使い方

最近のOpenCoreのガイドでは、シリアル番号などの機種情報を生成するために、GenSMBIOSというPythonプログラムがよく使われています。これも中ではmacserialを動かしているのですが、より簡単に使えて、さらにconfig.plistへの書き込み機能を備えているので便利です。この記事ではGenSMBIOSを使ってみます。GenSMBIOSは以下からダウンロードできます。

GitHub - corpnewt/GenSMBIOS: Py script that uses acidanthera’s macserial…

ダウンロードするとGenSMBIOS.commandというファイルがあります。これが本体です。Terminal.appでこれを起動します（アイコンをダブルクリックしても良いです）。すると以下のメインメニューが現れます。

#######################################################
# GenSMBIOS #
#######################################################
MacSerial v2.1.2
Current plist: None
Plist type: Unknown

1. Install/Update MacSerial
2. Select config.plist
3. Generate SMBIOS
4. Generate UUID
5. List Current SMBIOS

Q. Quit

Please select an option:

このメニューを順番に説明します。

1. Install/Update MacSerial

最初のメニューは、内部で使用するmacserialの更新です。GenSMBIOS.commandがあるディレクトリの中に、Scriptsというディレクトリがあります。この中にmacserialが入っています。macserialの使い方は、過去の記事を見てください。macserialは、新しいMacが出るたびに、それをサポートするために更新されています。なので、GenSMBIOSのこのメニューは、macserialを最新版に更新します。既存のMacのシリアル番号生成規則も更新されている可能性もありますので、とりあえずは選択しておくのが良いと思います。

 #######################################################
 # Getting MacSerial #
#######################################################
Gathering latest macserial info...
- MacURL: https://github.com/acidanthera/macinfopkg/releases/download/2.1.2/macinfo-2.1.2-mac.zip

Downloading macinfo-2.1.2-mac.zip...
- Extracting...
- Found macserial
- Chmod +x...
- Copying to Scripts directory...

Cleaning up...

Done.

2. Select config.plist

生成したシリアル番号などを書き込む先のconfig.plistを指定します。ここで書き込み先のconfig.plistへのパスを入力するか、もしくは説明にあるとおりそのアイコンをドラッグ&ドロップします。すごいところは、Cloverのconfig.plistにも、OpenCoreのconfig.plistにもどちらにも対応しているところです。

 #######################################################
 # Select Plist #
#######################################################

Current:
Type: OpenCore

C. Clear Selection
M. Main Menu
Q. Quit

Please drag and drop the target plist:

試しに、OpenCoreに付属のデフォルトconfig.plistであるSample.plistをコピーして、config.plistに改名して入力してみました。

3. Generate SMBIOS

GenSMBIOSのメイン機能です。このメニューでSMBIOS情報を生成します。Macの機種IDを聞かれますので、入力します。ここではiMac19,1を指定しました。

 #######################################################
 # Generate SMBIOS #
#######################################################

M. Main Menu
Q. Quit

Please type the SMBIOS to gen and the number
of times to generate [max 20] (i.e. iMac18,3 5): iMac19,1

その結果、シリアル番号、ボードシリアル番号、UUIDが生成されます。2番目のメニューで、変更先のconfig.plistを指定してあれば、それに書き込まれます。指定していなければ、情報が表示されるだけです。その場合はテキストエディタなどで開いたconfig.plistにコピペします。

 #######################################################
 # iMac19,1 SMBIOS Info #
#######################################################

Type: iMac19,1
Serial: C02DN9ZSJV3Q
Board Serial: C020453004NLNV91M
SmUUID: 2BCB8DF6-7633-4F0E-B63C-975E3EFCEDFE

Flushing SMBIOS entry to /Volumes/Users/bootmacos/config.plist

Press [enter] to return...

今回は、前述のようにデフォルトのSample.plistと同一内容のconfig.plistを変更するように指定してあります。どのように変更されたかを確認するために、diffコマンドでconfig.plistと、元データのSample.plistを比較してみました。一見、多くの差分があるように見えますが、実は、

% diff config.plist Sample.plist
134,136c134
< <data>
< Q3B1UG0AAAA=
< </data>
---
> <data>Q3B1UG0AAAA=</data>

とあるように、元のSample.plistで情報という1行で記述された内容が、GenSMBIOSの処理により3行に分けられただけの場所が多いです。このような変更点を除いた、実質的に差分のある場所は、以下でした。

% diff config.plist Sample.plist

(略)
893c824
< 			<string>C020453004NLNV91M</string>
---
> 			<string>M0000000000000001</string>
903c832
< 			<string>C02DN9ZSJV3Q</string>
---
> 			<string>W00000000001</string>
905c834
< 			<string>2BCB8DF6-7633-4F0E-B63C-975E3EFCEDFE</string>
---
> 			<string>00000000-0000-0000-0000-000000000000</string>

ということで、000000…などの数値で仮に書かれていたシリアル番号、ボードシリアル番号、UUIDの場所だけが、今回新しく生成されたデータで書き直されていることがわかります。

なお、シリアル番号は、下記のサイトでそれが未使用であることを確認しておくべきです。ここで生成された番号を入力し、「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば、その番号は未使用です。今回生成した番号はOKでした。

Check Your Service and Support Coverage - Apple Support

4. Generate UUID

これはおまけ的な機能だと思いました。UUIDだけを生成します。uuidgenというコマンドを動かしているだけだと思います。ちなみにこのメニューを選択しても、config.plistには書き込まれません。

#######################################################
# Generated UUID #
#######################################################

773F1659-07F1-4130-8C3B-FE2F900F9E95

Press [enter] to return...

5. List Current SMBIOS

これは現在起動中のマシンの情報を表示します。上のメニューで指定したconfig.plistファイルの内容ではありません。macserialの–infoオプションと同様に、シリアル番号の分析と有効性を表示してくれます。

まとめ

GenSMBIOSコマンドで、シリアル番号を生成して、config.plistに書き込む作業が楽になります。その過程で、シリアル番号が有効かどうかをAppleのサイトで確認しておく必要はあります。また、このコマンドでは、OpenCoreのconfig.plistにおけるPlatformInfo–>Generic–>ROMの設定は行ってくれません。Sample.plistでは0x112233445566になっています（Base64ではESIzRFVm）。任意の6バイトの数値で良いのですが、唯一の数字にしておくべきです。通常はEthernetのMACアドレスに設定しておくと良いようです。生成したシリアル番号は大抵の場合未使用ですし、ROMの値もAppleによって厳しくチェックされる情報でもありませんので、GenSMBIOSで設定すれば、とりあえずは起動してしまっても大丈夫だと思います。

Big Sur

Tue, 23 Jun 2020 11:20:06 +0900

macOS 11.0 Big Surインストールに関する情報をメモしておきます。

機種設定

Big Surは、以下のIntel Macで稼働します。

MacBook：2015年 (MacBook8,1) 以降
MacBook Air：2013年 (MacBookAir6,1) 以降
MacBook Pro：2013年後半（Late 2013）(MacBookPro11,1) 以降
Mac mini：2014年 (Macmini7,1) 以降
iMac：2014年 (iMac14,4) 以降
iMac Pro：全モデル (iMacPro1,1)
Mac Pro：2013年 (MacPro6,1) 以降

なので機種設定は上の機種ID以降の番号にしないと起動しません。

追記：MacBookPro11,1とMacBookPro11,2も避けた方が良いらしいです。

Apple、アップグレード後に起動しなくなる不具合が確認された2013~2014年製のMacBook Proのサポートを一時的に中止した「macOS Big Sur 11.0.1 Build 20B50」をリリースしています。

ブートローダー

OpenCoreとCloverで起動することができます。ただ、OpenCoreが主流になりつつあるので、よくサポートされていて良いと思います。

Big Surがリリースされた時点でのOpenCoreは0.6.3でしたので、それ以降のバージョンを使うと良いです。Kext Updaterなどで、最新リリース版を使えば良いです。

Kext類

Kext Updaterで得られる最新版を使用しておけば良いです。

USB起動インストーラ

従来通り、createinstallmediaコマンドで起動USBインストーラを作ることができます。

macOS の起動可能なインストーラを作成する方法

インストール例

Big SurをインストールしたインストールやフォーラムトピックスをBig Surのタグをつけてまとめておきます（準備中）。

Big Surをクリーンインストールする (OpenCore + Z490)

Big Surをクリーンインストールする (OpenCore + Z390)

カーネル読み込みメモリ空間を確保する (OpenCore編)

Tue, 02 Jun 2020 23:10:12 +0900

macOSが起動する時、ブートローダがカーネルをメモリに読み込みます。この時、連続した十分な大きさのメモリ領域が確保できないと、起動に失敗して禁止マークが出ます。この状況への対処方法が、OpenCoreではCloverよりも充実しています。

以前の記事では、メモリの使用状況（メモリマップ）を確認して、空き領域を起動オプションのslide値で指定することで、カーネル用メモリを確実に確保する方法を紹介しました。今回はそのOpenCore編です。

slideでカーネル読み込み番地を調整する (Clover編)

以下のOpenCoreのガイドで、この問題への対処方法が詳しく説明されています。以下はこのサイトの抄訳です。

KASLR Slide値を設定する

このページでは、 “Couldn’t allocate runtime area” (ランタイム領域を割り当てられませんでした) というエラーを理解し、修正したいユーザーのために説明します。これは Z390, X99, X299 などで最もよく現れるエラーです。このページはOpenCoreだけでなく、Cloverも対象にします。

KASLRとは何か？

KASLRは、Kernel address space layout randomizationの略で、セキュリティ目的で使用されます。これにより攻撃者がメモリ内の重要なオブジェクトがどこにあるのかを把握するのを難しくします。

HackintoshでKASLRが問題になるのは、マザーボードに連続した十分なサイズのメモリー空間がなく、カーネルが完全に収まらない場合です。そこで、slide=xxx を使って、KASLRをキャンセルしてメモリーアドレスを固定していました。このパラメータを設定すると、macOSに起動ごとに動作するランダムな領域にカーネルを読み込む代わりに、動作することがわかっている場所を使用します。

このガイドが必要な人達

カーネルを読み込むメモリ空間が足りなかったり、細分化されたメモリー空間に読み込み場所が移動してしまったユーザーのためのガイドです。その場合、このようなエラーが出ます。

Error allocating 0x1197b pages at 0x0000000017a80000 alloc type 2
Couldn't allocate runtime area

以下のようなエラーが出ることもあります。

Only 244/256 slide values are usable!

または、macOSの実行中にカーネルパニックが発生することもあります。

panic(cpu 6 caller 0xffffff801fc057ba): a freed zone element has been modified in zone kalloc.4096: expected 0x3f00116dbe8a46f6 but found 0x3f00116d00000000

これらのエラーの1番の特徴は、発生にランダム性があることです。大抵は20回も起動を繰り返せば、1回くらいはエラーを出さないで起動します。

問題解決の方法

これを修正するのは非常に簡単で、その手順はCloverユーザでもOpenCoreユーザーでも同じです。Clover ユーザに必要なものは以下です。

Clover Shell : shell64.efi などと呼ばれているファイルを、EFI/CLOVER/tools の下に置きます。
OcQuirks : Aptioの修正、OsxAptioFixDrvX, AptioMemoryFixなどと混在させないでください。このガイドでは OcQuirks のみサポートします。EFI/CLOVER/drivers/UEFI の中に置きます。
OpenRuntime.efi : OcQuirksのパッケージに含まれます。EFI/CLOVER/drivers/UEFI の中に入れます。
OcQuirks.plist : (これもOcQuirksに含まれてます) EFI/CLOVER/drivers/UEFI の中に入れます。

一方、OpenCoreユーザに必要なものは以下です。

OpenRuntime
OpenShell これをconfig.plistのRoot -> Misc -> Toolsで有効にしておきます。

そして、config.plist -> Booter (OpenCore用) かOcQuirks.plist (Clover用) で以下の設定をします。

AvoidRuntimeDefrag: YES
日付、時刻、NVRAM、電源制御などのUEFIランタイムサービスの修正
DevirtualiseMmio : YES
Stolen Memory のサイズを削減し、slide=N値のオプションを拡張し、Z390のメモリ割り当ての問題を修正するのに非常に役立ちます。
EnableSafeModeSlide : YES
slide 値をセーフモードで使用できるようにします。
ProtectUefiServices : NO
UEFI サービスがファームウェアによってオーバーライドされないように保護します。主に VM、300 シリーズ、および Ice Lake や Comet Lake のような新しいシステムに関連します。
ProvideCustomSlide : YES
これにより、カーネルが、読み込みに適したメモリー空間のみを選択し、起動に失敗する可能性のある場所を避けるようになります。読み込み場所のランダム性は維持していますが、ランダムに選択する際に、不適切なメモリ領域を除外するようになります。（訳注：これが従来のslide設定の役割を果たしてくれるようです。ただし、slideを固定するのではなく、使用可能なslide値を自動で探して、その中からランダムに選んでくれているようです。）
RebuildAppleMemoryMap : YES
macOSと互換性のあるメモリマップを生成します。いくつかのラップトップのOEMファームウェアで失敗することがありますので、早期段階でブートに失敗する場合は、これを無効にします。

BIOS設定

BIOSを以下のように設定します。

BIOSを更新する (初期のBIOSにはメモリマップの問題があることが知られているので、非常に重要です, 特にZ390で重要です。)
CMOSを工場出荷時設定にリセットする
とても必要とされる以下のBIOS設定をします。
Above4GDecoding : 有効にします。デバイスが4GB以上のメモリ領域を使用できるようになり、macOSカーネルが収まるメモリー空間が増えます。
Boot Options -> Windows8.1/10 mode : これにより古いレガシーなゴミのようなコードがロードされなくなります。誤解されがちですが、other OSというもう一つの選択肢は、古いバージョンのWindowsを起動するための選択肢であり、LinuxやmacOSのための選択肢ではありません。（訳注：ASUSのZ490マザーボードにCatalinaを入れたマシンでは、other OSにしないと起動しませんでした。）
BIOS内の不要なデバイスをできるだけ多く無効にします。これにより、起動時のマップの細分化が減少するので、起動失敗の可能性が減ります。
CSM : 無効にします。有効化してしまうと、レガシーサポートのため、不要なゴミの束が追加され、またUEFIシェルが起動できなくなります。
Intel SGX : 無効にします。SGXとはSoftware Guard Extensionsの略です。有効にしても、多くのメモリ空間を占有するだけで、macOSでは何もしません。
Parallel Port と Serial Port：無効にします。macOSではParallel portは認識しませんし、Serialを必要とする人はいないです。
iGPU : やむを得ない場合は、これを無効にすることで、メモリを大幅に解放できます。
Thunderbolt : 無効にします。ほとんどのマザーボードはTBを搭載していませんし、搭載していても使用しないなら、無効にすることでメモリ空間を確保できます。
LED lighting : 無効にします。もう光らせなくても良いでしょう。
Legacy USB : 無効にします。これもレガシーなガラクタです。

テストブート

上記のように、EFI、config.plist、BIOSの設定を調整したら、これで起動を試してください。これでめでたく解決したら、この先の作業は不要です。まだ問題が発生する場合は、次のステップで、もっとディープな作業、つまりslide値の計算をしましょう。

slide値を探す

ブートマネージャでEFIシェルを開き、memmapを実行します。すべてのページとそのサイズのリストが以下のように表示されます。ここからが楽しみの始まりです。

Type Start End # Pages Attributes
RT_Data	 0000000000000000 0000000000000FFF 0000000000000001 800000000000000F
Available 0000000000001000 0000000000057FFF 0000000000000057 000000000000000F
Reserved 0000000000058000 0000000000058FFF 0000000000000001 000000000000000F
Available 0000000000059000 000000000008FFFF 0000000000000037 000000000000000F
RT_Code 0000000000090000 0000000000090FFF 0000000000000001 800000000000000F
Available 0000000000091000 000000000009DFFF 000000000000000D 000000000000000F
Reserved 000000000009E000 000000000009FFFF 0000000000000002 000000000000000F
Available 0000000000100000 000000005B635FFF 000000000005B536 000000000000000F
BS_Data 000000005B636000 000000005B675FFF 0000000000000040 000000000000000F
Available 000000005B676000 000000006AF77FFF 000000000000F902 000000000000000F
LoaderCode000000006AF78000 000000006B155FFF 00000000000001DE 000000000000000F
BS_Data 000000006B156000 000000006B523FFF 00000000000003CE 000000000000000F
ACPI_NVS 000000006B524000 000000006B524FFF 0000000000000001 000000000000000F
BS_Data 000000006B526000 000000006B625FFF 0000000000000100 000000000000000F
Available 000000006B626000 000000006B634FFF 000000000000000F 000000000000000F

（訳注：このあと、slide値を決める手順が書かれています。どういうわけか、一番高い番地のAvailableを第一候補として〜15ページしかないのに〜、slideが255を超えるので諦めて、順当に0x100000番地からの領域、すなわちslide=0を選択しています。ということで少し遠回りしている感じもしますし、また、こちらで解説した内容と同じなので省略します。またRedditの/r/hackintoshのdiscordにもツールらしきものがあるらしく、その説明もありますが、これも省略します。）

DevirtualiseMmioを使う

（

訳注：この先はあまり理解できませんでした。推測を交えて内容をまとめると、次のようなことだと思います。推測部分は間違っているかもしれません。

config.plistでDevirtualiseMmioをtrueにする

DevirtualiseMmioのデフォルトはfalseですが、これをtrueにします。これにより、カーネルを読み込む場所のメモリー使用が64から256MB程度節約できて、KASLRの失敗を防止できます。

MMIOはMemory Mapped IOのことです。入出力デバイスのコントロールをメモリーのアドレス線を利用して行うのがMMIOです。上でのべたEFI Shellのmemmapコマンドによると、E0000000番地からFFFFFFFF番地までの512MBにMMIOが割り当てられています。インテルチップセットのマザーボードなら同様のようです。この番地には、メモリーが割り当てられていたとしても、IOへのアクセスになってしまい使えません。

Type Start End # Pages Attributes
MMIO 00000000E0000000-00000000EFFFFFFF 0000000000010000 800000000000100D
MMIO 00000000FE000000-00000000FE010FFF 0000000000000011 8000000000000001
MMIO 00000000FEC00000-00000000FEC00FFF 0000000000000001 800000000000100D
MMIO 00000000FED00000-00000000FED03FFF 0000000000000004 800000000000100D
MMIO 00000000FEE00000-00000000FEE00FFF 0000000000000001 8000000000000001
MMIO 00000000FF000000-00000000FFFFFFFF 0000000000001000 800000000000100D

（以下はフォーラムで教えていただいた図をもとに考えた説明です、間違っていたらすみません）EFIによってOSが起動する際に、通常はMMIOに論理アドレスを与えて（仮想化して）、論理アドレスからMMIOを使用できる状態にするようです。ただMMIOの仮想化を行わなくても(de-virtualiseしても)、物理アドレスにアクセスできるプロセスからはMMIOを使えるのでそれほど問題はないようです。MMIOを仮想化しない場合は、MMIOの部分もメモリーにマップできるので、64MBから256MBの空き領域が稼げるようです。DevirtualiseMmioフラグをtrueにすると、カーネルが読み込まれる領域を少しでも多く確保できるので、起動失敗の確率を下げられます。

Kaby Lake以前のCPUでは、デフォルト通りfalseが、Coffee Lake, Comet Lakeなどではtrueにすると良いとされていますが、手元のCoffee Lake-Sではfalseでも動きました。通常はfalseで、起動失敗する場合にはtrueを試すのが良いと思います。

ちなみにどうでも良いことですが、virtualize (仮想化) をvirtualiseと書くのは英国風らしいです。

config.plistにMmioWhitelistを指定する

DevirtualiseMmioをtrueにした場合に、メモリは節約できるものの、Threadripper TRX40 19H などの一部のシステムで起動しなくなることがあるらしいです。そのような場合、DevirtualiseMmioを適用しない領域を指定します。これがMmioWhitelistです。これの作り方について説明がありますが省略します。ほとんどのシステムではMmioWhitelistは不要とのことです。

）

ここまでが抄訳です。

結局どうしたら良いのか

OpenCoreでどう対応すべきかについてまとめます。上記のガイドでは、slide値を求める方法は書いてありますが、ブートオプションなどで設定する方法にまでは書かれていませんでした。当然のことで省略されたのかもしれないですし、slideを使うことをあまり推奨していないのかもしれません。

OpenCoreのReference Manual (0.5.8) の最初の方（15ページ）には、最初にすべきことの一つに、「slideを使うな」と書いてあります。config.plistの設定からも、NVRAMのboot argumentからも削除しておくようにとのことです。そして、「No slide values are usable! Use custom slide!」というエラーが出てから検討してくださいとあります。slideは、KASLRを回避する上、SIPを緩める必要があるので、セキュリティに影響を与えるという考えなのかもしれません。まずはslideを使わなくても済む方法を試みて、それでもダメな場合だけにslideを使いましょうとの方針だと思います。

ということで、このガイドのステップをまとめると、以下になります。まずはマザーボードの設定です。

BIOSを更新する
Above 4G Decodingを有効にする
CSMを無効にする
Boot Options -> Windows8.1/10 mode にする（訳注：前述のようにother OSを選択しないと起動しないことがあります）
Parallel Port と Serial Portを無効にします

可能ならば以下も設定します。

Intel SGX : 使用していないなら無効にします。
Thunderbolt : 使用していないなら無効にします。
LED lighting : 無効にします。
Legacy USB : 無効にします。

そしてconfig.plistで以下のように設定します。

AvoidRuntimeDefrag: true
DevirtualiseMmio : true
EnableSafeModeSlide : true
ProtectUefiServices : false
ProvideCustomSlide : true
RebuildAppleMemoryMap : true

設定は、環境に合わせて必要なものを選択して、正常に起動するまで少しずつ足して行くのが良いと思います。

まとめ

KASLRに関係した理由でmacOSが起動しないことへの対処法を紹介しました。基本的には、メモリー空間を確保する処置をして、KASLRの選択範囲を狭めることで対応しています。BIOS設定とOpenCoreの機能で大体の場合に対応できて、slideによるカーネル読み込み番地固定は最終手段のようです。

15個制限のためのUSBPorts.kextをHackintoolで作る

Sun, 31 May 2020 17:36:51 +0900

macOSのUSB 15個制限を解決するために、使用する15個未満のUSBポートを決定し、macOSに伝えます。以前の記事でいくつかの方法を紹介しましたが、今回はHackintoolを使ってkextを作ります。作業が楽で、作ったkextを1個インストールするだけなので簡単でした。

USBポート個数対処の方法

今までの記事では、USBポート個数制限に対処する方法として、

AppleUSBXHCIPCI.kextにパッチを当てる
OpenCoreのconfig.plistでXhciPortLimitをtrueにする
DSDTを書き換えて使用する15個のUSBポートを指定する
USBInjectAll.kextとブートオプションで15個を指定する
USBInjectAll.kextとこれに指示するSSDTを作って15個を指定する

などの方法を紹介しました。

USBポートを設定する

ASUS MAXIMUS XI HEROのUSBを設定する

先日の記事で、OpenCore用の手順を書いたところ、P2B-Fさんからコメントで「Hackintoolを使ってUSBPorts.kextを作る方が簡単です」と教えていただきました。試してみたら確かに簡単でした。その手順をまとめておきます。以下の方法は、個数制限に対応する方法の中で、現時点で一番おすすめの方法だと思います。

Hackintoolを入手する

Hackintoolは以下から入手できます。HackintoolはiGPUの設定でも使いました。色々便利な機能があります。USBポートの情報などのハードウェア構成情報はIORegistryExplorerでも見ることができますので、併用して確認するのも良いです。

Releases · headkaze/Hackintool

一時的に制限を撤廃する

まずOpenCoreのconfig.plistでXhciPortLimitをtrueにするなどして一時的に15個制限を解除します。Cloverでしたらconfig.plistで15個制限撤廃パッチを当てても良いです。また、以前紹介したようにUSBInjectAll.kextとブートオプションを使って少しずつ解除しても良いです。以下では、全てを解除した状態で説明します。全解除状態でHackintoolを起動し、ウィンドウ上部のボタンからUSBを選択すると、下の図のようになります。

ウィンドウの下には、7個のボタンが表示されています。マウスを持っていくと機能が文字表示されます。それによると左から、Info, マイナスマークのDelete, ホウキのマークのClear All, 回転矢印マークのRefresh, 注射器マークのInject, Import, Exportのボタンです。Clear All, Inject, Refreshの順に押していくと、現在認識されているポートが全て表示されます。Z390チップセットのASUS ROG MAXIMUS XI HEROでは以下のようになりました。上部のウィンドウに、Cannon Lake用の300シリーズチップセットのマザーボードであることが表示されていて、マザーボードが正しく認識されています。

ここでHS03とHS12がアクティブになっています。HS03には、一時的にLogicoolのタッチパッド付きキーボード用の無線ドングルを接続したので、それが見えています。また、HS12にはUSB 2.0のハブを接続しているので、それが見えてます。実はHS13には、Apple純正のBluetoothモジュールが接続されているのですが見えていません。マザーボード上のUSB 2.0コネクタなのですが、これがマザーボード内蔵のhub経由で接続されているらしく、そのためか、XhciPortLimitをtrueにしても見えないようです。なので設定作業用にLogicoolのキーボードを接続しているわけです。（さらにはSS10にもハブがつながっているのですがそれも見えていないようです。後の図で示すように、15個制限を設定したら、これらも見えるようになりました。）

USBポートを特定して選別する

この状態で、USBポートにデバイスを取り付けて、変化を観察します。例えば上の状態では、バックパネルのUSB 3ポートにLogicoolのキーボードドングルが反応したので、これがHS03であることがわかります。この作業には、キーボード、マウス、USB Bluetoothアダプタなどを使うと良いです。これらはUSB 2.0ですし、抜き差しも簡単です。USB 2.0メモリーを使用すると、アンマウントする手間が必要です。USB 3のポートを確認するには、USB 3対応のUSBメモリーなどを使います。この場合は、取り外す際にアンマウントしないと、データを壊す危険があります。（大抵は大丈夫ですが）

HackintoolのConnectorの欄をクリックするとポップアップメニューが出ます。この欄には、USBの速度ではなく、接続された物理的なコネクタの形状を書きます。HS03はUSB 2ですが、USB 3コネクターに接続されています。なのでHackintoolのConnectorの欄はUSB3に設定します。

Connectorとして選択できるのは、USB2, USB3, TypeC+Sw, TypeC, Internalの5種類です。ここでの選択で、後で述べる出力ファイルのUsbConnectorプロパティ値が変化します。それによると、それぞれの選択で、0, 3, 9, 10, 255が割り当てられることがわかりました。これらの値について、Hackintoolのソースを調べたところ、ヘッダファイルに以下の記述がありました。

kTypeA		= 0x00,	// Type ‘A’ connector
kMiniAB		= 0x01,	// Mini-AB connector
kExpressCard	= 0x02,	// ExpressCard
kUSB3StandardA	= 0x03,	// USB 3 Standard-A connector
kUSB3StandardB	= 0x04,	// USB 3 Standard-B connector
kUSB3MicroB	= 0x05,	// USB 3 Micro-B connector
kUSB3MicroAB	= 0x06,	// USB 3 Micro-AB connector
kUSB3PowerB	= 0x07,	// USB 3 Power-B connector
kTypeCUSB2Only	= 0x08, // Type C connector - USB2-only
// These only implement the USB2 signal pair, and do not implement the SS signal pairs
kTypeCSSSw	= 0x09, // Type C connector - USB2 and SS with Switch
// These implement the USB2 signal pair, and a Functional Switch with a physical
// Multiplexer that is used to dynamically connect one of the two receptacle SuperSpeed
// signal pairs to a single USB Host Controller port as function of the Type-C plug
// orientation.
kTypeCSS	= 0x0A, // Type C connector - USB2 and SS without Switch
// These implement the USB2 signal pair and a Functional Switch by connecting each
// receptacle SuperSpeed signal pair to a separate USB Host Controller port.
// 0x0B – 0xFE: Reserved
kInternal	= 0xFF	// Proprietary connector

0, 3, 9, 10, 255以外にも、いくつかの設定値があるようです。ただ、Hackintoolのメニューにあるように、この5種類が一般的で、これ以外を設定することはなさそうです。この説明から、割り当ては以下のようです。

USB2 (0) はUSB 2.0 Type Aコネクター
USB3 (3) はUSB 3.x Type Aコネクター
TypeC+Sw (9) はスイッチ経由USB Type-C (Gen1またはGen2)
TypeC (10) はスイッチを経由しないUSB Type-C (Gen1x2またはGen2x2)
Internal (255) はマザーボード上の専用コネクタ

USB規格のType-A, Type-Cコネクタの場合は、0, 3, 9, 10を指定するのに対して、マザーボード上にあるヘッダピンのようなUSB規格外のコネクタに接続されている場合はInternal (255) を選択します。どのコネクタに接続されていてもUSBはUSBなので関係ない気もしますが、macOSの中での電力制御の扱いが異なるようです。IORegistryExplorerなどでコネクタの情報を見ると、コネクタ種類の違いで電流関係のパラメータが異なっています。その関係と思われますが、Bluetoothアダプタが接続するポートは、255に設定しないとスリープを妨げることがあるようです。

Type-Cコネクタの設定

Hackintoolのコネクタ選択肢であるTypeC+SwとTypeCの違いを説明します。Type-Cケーブルは、以下のように1セットのUSB2配線（A6, A7とB6, B7）と、2セットのUSB3配線（A2, A3, B11, B10とA10, A11, B3, B2）で構成されています。

このうち、Type-CのUSB2 (信号名はD+とD-) は、コネクタを裏表どちらに挿しても同じUSB2が接続されます。コネクタが冗長に使用されています。それに対して、2個のUSB3 (TX1+/-, RX1+/-, TX2+/-, RX2+/-) は、裏表どちらかに挿すことで、2セットのUSB3が別々に接続されます。なのでUSB3に関しては、2セット分用意しないといけないわけです。これを実現するために、もともと1個しかないUSB3をスイッチングハブで分岐して2個にして接続するか、もしくは2個のUSB 3ポートを用意するか、の2種類の実装方法があります。これがHackintoolのメニューにあるTypeC+Sw（スイッチ付）とTypeCです。どちらも2個のUSB3が使えますが、前者は一つを2個に分岐しています。なので2個のUSB3を両方とも使用した場合は、速度が半々になります。後者は、両方のUSB3を共に使用してもそれぞれのフルスピードが出ます。

最近になって従来のUSB 3.0や3.1の表記に代わって、USB 3.2という名称が使われるようになり、ややこしくなってます。色々調べてみると、以下のような分類になったようです。

USB 3.2 Gen1 : 昔のUSB 3.0 または今のUSB 3.1 Gen1と同じもの (5Gbps線を1組使用)
USB 3.2 Gen2 : 昔のUSB 3.1または今のUSB 3.1 Gen2と同じもの (10Gbps線を1組使用)
USB 3.2 Gen1x2 : Type-Cでスイッチを使わずに独立した5Gbps線を2組使う (合計10Gbps)
USB 3.2 Gen2x2 : Type-Cでスイッチを使わずに独立した10Gbps線を2組使う (合計20Gbps)

ちなみにGen2x2は「じぇんつーばいつう」と読むようです。x2が末尾につくコネクタはHackintoolのTypeCを選択し, x2がつかないコネクタはTypeC+Swを選択します。今回チェックしたマザーボードでは、裏表どちらに挿してもSS06に接続されました。スイッチで分岐しているだけのようなのでこれはUSB 3.1 Gen2x1です。HackintoolのConnectorメニューではTypeC+Swを選択します。

使わないポートを除外

こうしてUSBポートを特定していくと同時に、使わないポートを外していきます。最終的に15個のUSBポートまで削減していきます。使えるものなら使いたいけど、個数制限で諦めざるを得ないポートもあると思います。また、Comment欄のところにメモ書きをしておくと、後で説明する出力ファイルにもコメント記載されます。テキストエディタで修正する場合などに便利です。

今回も、以前の記事で選んだUSBポートを使うことにしました。結果として以下のようになりました。

USBPorts.kextを作る

この後、ウィンドウ下のExportボタンを押します。するとこの設定から、

SSDT-EC-USBX.aml
SSDT-EC-USBX.dsl
SSDT-UIAC.aml
SSDT-UIAC.dsl
USBPorts.kext

の5個のファイルをデスクトップに作ってくれます。以前のガイドで作っていたSSDT-UIACは、ここではSSDT-EC-USBXとSSDT-UIACの2つに分割されています。統合すれば内容は同じものでした。なので、SSDT関係のファイルはUSBInjectAll.kextと一緒に使うものであると思います。

一方、ここで作られるUSBPorts.kextは、Info.plistだけを持ったインジェクタkextという種類のkextファイル（実際にはディレクトリ）です。ターミナルからディレクトリを辿る、もしくはファインダーからパッケージを開くと、

USBPorts.kext/Contents/Info.plist

というテキストファイルが見えます。この中に、上で設定した内容が、plist書式のテキストで書かれています。こうして作成されたInfo.plistの内容を以下のところに置いておきました。

USBPorts.kext for ASUS Z390 - Pastebin.com

このUSBPorts.kextだけを使用すれば、15個のUSBを指定して動かすことができました。kextを使う場合は、USBInjectAll.kextやSSDT-EC.aml, SSDT-UIAC.amlは不要です。実は、Z97の時代にはこの手のインジェクトkextを使って使用USBのリストを設定していました。その後、チップセットが代わって、雛形となるファイルが見つからなくなったので、USBInjectAll.kextとSSDTを組み合わせて使っていました。Hackintoolでこんなに簡単に生成してくれるなら、今後はこのkextを使っていきたいと思います。

USBMap.commandを使う

こちらもコメントで教えていただきました。Hackintool.appと同様に、インジェクトkextを作るPythonスクリプト、USBMap.commandがcorpnewtさんによって配布されています。

GitHub - corpnewt/USBMap: Python script for mapping USB ports in macOS and cr…

こちらはCUIベースで設定していきます。操作が多少独特ですが、USB設定専用のアプリですのでシンプルです。生成されるインジェクトkextはUSBMap.kextという名前ですが、Hackintoolで作るUSBPorts.kextと全く同じ内容です。

% ./USBMap.command

#######################################################
# USBMap #
#######################################################

Plist: USB.plist
UIA Boot Args: None
USBInjectAll: Not Loaded - NVRAM boot-args WILL NOT WORK
AptioMemoryFix: Unknown

NVRAM Arg Options:
H. Exclude HSxx Ports (-uia_exclude_hs)
S. Exclude SSxx Ports (-uia_exclude_ss)
C. Clear Exclusions

R. Remove USB.plist from Scripts Folder
T. Reset Settings to Defaults
P. Edit Plist & Create SSDT/Kext
D. Discover Ports
U. Validate USB Power Settings
Q. Quit

Please select an option:

コメントでMifjpnさんから、USBMap.commandの使用例を教えていただきました。

USBMap.commandによるUSBポートの選択

まとめ

USBポート15個制限に対応するため、Hackintoolを使って、USBPorts.kextを作りました。このkextを使用するだけで、15個制限の設定が可能でした。今まで紹介した方法のどれよりも簡単だと思いますので、今後はこの方法で設定していこうと思います。コメントで教えていただきありがとうございました。

SSDのtrimを有効にする (OpenCore編)

Thu, 28 May 2020 22:42:16 +0900

2.5インチSSDのtrim機能をtrimforceコマンドで有効にしました。nvramを正しく動くようにしておいたためか、trimforceが効きました。もしtrimforceが効かない場合、Cloverでは、IOAHCIBlockStorage.kextにパッチ当てしてましたが、OpenCoreではThirdPartyDrivesをtrueにするだけで良いようです。

trim有効化方法 (OC対応版)

今回、trimの有効化を試したマシンは、ASUSのZ390マザーボードとSanDiskの2.5インチSATA SSDの構成です。また、trimの仕組みと設定方法は以下の記事で紹介しました。

SSDのTRIMを有効にする

SSDを使う場合、trimは有効になっていた方が良いと言われてます。そこで以下のステップでtrim設定に対処します。

SSDによっては、macOSがtrim対応している場合があります。特にNVMe方式のM.2 SSDはOOBでtrimが働くようです。その場合は、何もしなくて良いです。
非対応SSDの場合、trim機能をmacOSのtrimforceコマンドで起動することができます。このコマンドには、nvramが関係している様子です。ただし、trimforceが効かないこともあります。
trimforceが効かない場合は、config.plistに設定してパッチを当てます。Cloverでは、IOAHCIBlockStorage.kextにパッチ当てしてます。OpenCoreではThirdPartyDrivesをtrueにします。

でも実のところ、このマシンでは、メインのSSDをM.2 NVMeにしたため、データを入れる場所にした2.5インチSSDのtrim設定は長らくほったらかしにしていました。trimforceは効かないし、パッチ当てるのも面倒だったのも理由です。

ThirdPartyDrivesの説明を読む

という状況だったのですが、OpenCoreにしたところ、パッチ当てが簡単になっていることに気づきました。上のステップに書いたように、config.plistの中で設定できるThirdPartyDrivesというプロパティをtrueにすれば、IOAHCIBlockStorage.kextにパッチを当ててくれます。これなら簡単にtrim有効化できます。さらにその説明を読むと、以下のように、できればtrimforceが望ましいようなことが書いてありました。

**ThirdPartyDrives :**デフォルトはfalseです。IOAHCIBlockStorage.kextにパッチを当て、サードパーティのドライブでtrimやハイバーネーションを可能にします。このオプションは、ユーザの判断で使わないことにしても良いです。最近のmacOSバージョンには、専用のユーティリティであるtrimforceが提供されています。10.15以降では、このユーティリティは、01 00 00 00という値のEnableTRIMという変数をnvramに作ります。

ThirdPartyDrivesでパッチ当てをしてくれるものの、trimforceはmacOSがサポートするtrim機能を活性化するmacOSのコマンドなので、これでtrim有効化するのが望ましいそうです。trimforceで有効化できない場合の時だけ、ThirdPartyDrivesをtrueするのが良いと思います。

trimforceコマンドでtrim有効化する

そこで、久々にtrimforceを試したところ、すんなり動いてしまいました。Terminalからtrimforceとタイプすると、説明が出ます。

% trimforce
Usage:
trimforce enable
trimforce disable
trimforce help

次に、OpenCoreの説明にある、EnableTRIMがnvramの中にあるかどうか調べてみました。

% nvram -p | grep EnableTRIM

何も表示されません。定義されていないようです。そこでtrimforceコマンドで、trimを有効にするよう試みました。色々警告が出ますが進めます。

% sudo trimforce enable
Password:
IMPORTANT NOTICE:  This tool force-enables TRIM for all relevant attached devices, even though such devices may not have been validated for data integrity while using TRIM.  Use of this tool to enable TRIM may result in unintended data loss or data corruption.  It should not be used in a commercial operating environment or with important data. Before using this tool, you should back up all of your data and regularly back up data while TRIM is enabled.  This tool is provided on an “as is” basis. APPLE MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, REGARDING THIS TOOL OR ITS USE ALONE OR IN COMBINATION WITH YOUR DEVICES, SYSTEMS, OR SERVICES. BY USING THIS TOOL TO ENABLE TRIM, YOU AGREE THAT, TO THE EXTENT PERMITTED BY APPLICABLE LAW, USE OF THE TOOL IS AT YOUR SOLE RISK AND THAT THE ENTIRE RISK AS TO SATISFACTORY QUALITY, PERFORMANCE, ACCURACY AND EFFORT IS WITH YOU.
Are you sure you wish to proceed (y/N)? y
Your system will immediately reboot when this is complete.
Is this OK (y/N)?

この後、警告の通り、自動的に再起動してしまいます。再起動後に、先ほどのnvram変数を調べてみました。

% nvram -p | grep EnableTRIM
EnableTRIM %01

OpenCoreのマニュアルにある通り、01という値のEnableTRIM変数が出来上がっていました。システム情報を見ると、設定前は「いいえ」だったTRIMサポートの項目が「はい」に変化していました。trimforceで正しく設定できたようです。

trimforceは長らく機能しなかったので、あきらめていましたが、設定できるようになっていました。trimforceがnvramを使うようになったためか、さらにはSSDT-PMC.amlでnvramが正しく使えるようになったおかげのようです。

まとめ

ひさびさにtrimforceコマンドを試したら、2.5インチSSDのtrimが有効になりました。ちなみにM.2 NVMe SSDの方は、何もしない状態でtrim有効でした。もしtrimforceが効かない場合は、OpenCoreでしたらThirdPartyDrivesをtrueにすれば良いと思われます。

使用するUSBポートを15個指定する (OpenCore編)

Wed, 20 May 2020 23:27:08 +0900

ここではUSBInjectAll.kextを使っていますが、最近はサポートが途絶えているので、以下の方法がよりシンプルでおすすめです。

15個制限のためのUSBPorts.kextをHackintoolで作る

———————————-

（以下は今でも有効ですが、古い情報です。）

OpenCoreではconfig.plistでXhciPortLimitをtrueにすれば15個制限を解除できます。Cloverでのパッチ作業より楽です。でもUSBInjectAll.kextとSSDTで使用する15個を指定する従来の方法も可能で、その方式がおすすめです。

OpenCoreで15個制限を全撤廃

macOS El Capitanから使用可能なUSBポートの数が、コントローラ当たり15までと制限されました。その解説と、Cloverのconfig.plistに書く制限解除パッチを以下の記事で紹介しました。この記事では、AppleUSBXHCIPCI.kextにパッチを当ててました。

USBポートを設定する

OpenCoreでは、config.plistのKernel, QuirksのXhciPortLimit項目をtrueにしておくと（デフォルトはfalse）、必要なパッチを当ててくれます。 AppleUSBXHCIPCI.kextの他に、AppleUSBXHCI.kextとIOUSBHostFamily.kextにパッチを当ててくれるようです。このパッチは、各種macOSバージョンに合わせた内容が必要なので、その点にも対応してくれているようです。なので、簡単に15個制限を解除できます。

しかし、OpenCoreのReferenceマニュアルにはこんな注意書きがあります。

このオプションは、可能な限り避けてください。USBポート制限は、locationIDの書式で割り当てられたビット数による制限です。この制限は、OSを大々的に変更しない限り解除できません。正しい解決策は、使わないポートを除外して、使用したいUSBポート15個を選定することです。

つまり、macOS内部で使用しているプロパティのlocationIDの中で、ポートを識別するための変数に、どうやら4ビットしか割り当てられていない様子です。15個を超えるポートを使用可能にすると、違うポートに同じIDが割り当てられる可能性があるわけで、とても危険なことだと推測できます。実際には15個制限を外したことで問題が発生した事例は、報告も無いし経験もしていませんが、避ける方が良いでしょう。XhciPortLimitの使用は、macOSをインストールする際や、使用するポートを取捨選択する作業の時だけに制限すべきでしょう。

OpenCoreで使用する15個を指定する

そこで、15個制限を撤廃するのではなく、必要な15個のポートだけを登録するようにします。まずはマシンのUSBポート割り当てを調べて、使用したい15個のUSBポートを選定します。この方法は、以下で説明しました。OpenCoreならば、この手順の中で、一時的にXhciPortLimitをtrueにすることで簡単に15個制限解除できるので、作業が楽になると思います。

ASUS MAXIMUS XI HEROのUSBを設定する

macOSは発見した15個までのUSBポートをアプリケーションに提供します。なので、使用する15個のポートを決定したら、その15個のポートだけがマシンに存在しているかのようにmacOSに伝えます。これにはいろいろな方法が可能ですが、USBInjectAll.kextと専用のSSDTを使用するのが一番おすすめだと思います。以下の記事で、仕組みと設定方法を説明しました。

15個制限を回避するUSBInjectAll.kextの役割と使用法

上の記事では、Cloverで使うための方法を書いていますが、OpenCoreでも同じように設定できます。ただし、kextとSSDTファイルを置く場所は、Cloverと違うディレクトリです。つまり、kextはKextsに、

SSDTは（SSDT-UIAC.amlという名前にしました）ACPIに置きます。

また、OpenCoreでは、config.plistにも、使用するkextとSSDTを記述する必要があるのは、すでに説明した通りです。ProperTreeのsnapshot機能を使えば、kextとSSDTを正しいディレクトリに置くだけで、config.plistの設定をしてくれるので楽です。

まとめ

OpenCoreでもUSBポート15個制限に対応するため、Cloverで使っていたUSBInjectAll.kextとSSDT-UIAC.amlをOpenCoreのESPに入れました。config.plistにも登録しました。これらは、Cloverの時と同じように、OpenCoreでも機能して、必要な15個のUSBポートが使えるようになりました。

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

Tue, 19 May 2020 22:29:04 +0900

抜き挿し可能なリムーバブルSATAドライブベイを使うために、Cloverでは、macOS稼動中にHDD/SSDドライブのホットプラグを可能にするパッチをconfig.plistに書いてました。OpenCoreに移行したのでこのパッチも移行しました。

5.25インチベイ用リムーバブルHDDラック

上の写真のような、5.25インチベイに取り付けるリムーバブルHDDラックは、本物のMacには無い、自作hackintoshならではの便利な装備です。でもHDDラックを取り付けただけではHDD/SSDのホットプラグが効きませんでした。macOS起動時にリムーバブルベイに装着されているHDD/SSDは認識され、ファインダー上でアンマウントして、安全に取り外すことはできます。しかし、macOS稼動中にHDD/SSDを挿しても認識されません。そこでCloverでは、ホットプラグが機能するようにconfig.plistにkextパッチを当て対応していました。

SATA接続HDD/SSDのホットプラグ

Cloverで使用していたパッチ

このパッチは、AppleAHCIPort.kextの一部を0x90 (マシンコードでNOPに相当します) に置き換えるものです。置き換える範囲は、kextの中の0x40200000というデータ列の4バイト、その前8バイト、その後14バイトの、合計26バイトです。コメントでまっくぷろさんに教えていただいたパッチです。

このパッチを作るために、kextの中で0x40200000を探して、書き換えるべきデータ列を調べます。例として、macOS 10.15.4で、書き換えるべきデータを探してみます。まずは、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをhexdumpします。

% hexdump /System/Library/Extensions/AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPort | less

lessが起動しているところ、以下のサーチコマンドをタイプし、40 20 00 00を探します。

/40 20 00 00

ところが運悪く途中に改行が入っているようで見つかりません。40 20だけでもう一度探索します。

/40 20

今度は見つかりました。改行の先に00 00があるので、間違い無いようです。他にも40 20は見つかりますが、その先に00 00が続く場所はありません。おそらくは2バイト単位で位置揃えされているので、この場所以外に改行が来る可能性は無いと思います。40 20 00 00と40 20の2種類の探索を試みれば、40 20 00 00の場所を発見できると思います。

0002a40 69 01 00 00 89 ca 81 e2 40 60 02 00 81 fa 40 20
0002a50 00 00 75 0c 81 e1 bf 7f ff ff 89 8b 69 01 00 00
0002a60 f6 c1 40 74 7e 3d 09 01 01 00 72 77 44 89 fa c1
0002a70 ea 0a 81 e2 80 00 00 00 81 e1 7f ff ff ff 09 d1

ここで発見した0x40200000の4バイト、その前8バイト、その後14バイトの、合計26バイトをNOP (90) に置き換えるパッチを作ります。つまり、

Find --> 81E24060 020081FA 40200000 750C81E1 BF7FFFFF 898B6901 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

というパッチを作ります。ProperTreeなどのツールならこのまま16進数が使えますが、テキストエディタで作る場合はbase 64に変換します。詳しくはこちらをご覧ください。Findするデータはbase 64では以下になります。

% echo -en "\x81\xE2\x40\x60\x02\x00\x81\xFA\x40\x20\x00\x00\x75\x0C\x81\xE1\xBF\x7F\xFF\xFF\x89\x8B\x69\x01\x00\x00" | base64
geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=

Replaceするデータは、NOPコマンド列である9090…なのですが、このbase 64は以下です。

% echo -en "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90" | base64
kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=

なのでCloverのconfig.plistには、

<key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>

というパッチを追加していました。これでBIOSでホットスワップ指定したチップセットSATA接続ドライブがオレンジ色アイコンになり、随時マウント・アンマウントできるようになりました。またスリープしても問題ありませんでした。

OpenCore用のパッチに書き換える

OpenCoreには、CloverのようなKextToPatchの項目はありません。OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、使用するキーの一部がCloverのパッチとは異なります。OpenCoreのパッチで使うキーは以下です。

Comment : Cloverと同じ。人が読むためのメモ書き。
Find : Cloverと同じ。検索データ列。
Replace : Cloverと同じ。置き換えるデータ列。
Identifier : CloverのNameに相当するキー。kextを指定するためのIDで、バンドルIDを使う。
Enabled : パッチを有効にする場合はtrueにする。（有効にしたいのでtrueにする）
Count : パッチを当てる箇所の数。今回の場合は1回なので1。
その他のキー : デフォルトで良いので省略。

kextのバンドルIDは、システム情報で知ることができます。

システム情報の拡張機能のAppleAHCIPortの項目を選択すると、

com.apple.driver.AppleAHCIPort

であることがわかります。そこで、上記のCloverのパッチに相当する、OpenCoreのパッチは以下になります。

<key>Kernel</key>
<dict>
 <key>Patch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Enables hot plug for removal drives</string>
 <key>Count</key>
 <integer>1</integer>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>geJAYAIAgfpAIAAAdQyB4b9///+Ji2kBAAA=</data>
 <key>Identifier</key>
 <string>com.apple.driver.AppleAHCIPort</string>
 <key>Replace</key>
 <data>kJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJA=</data>
 </dict>
 </array>
</dict>

ProperTreeで設定するなら、以下のようになります。（0番から4番までに、OpenCore付属のSample.plistにあった無効設定のパッチを残してあるので、たまたま5番目になっていますが、何番目でも大丈夫です。）

このパッチをOpenCoreのconfig.plistに追加したところ、OpenCoreでも、ホットプラグが機能しました。オレンジ色のドライブがmacOS起動後にリムーバブルベイに取り付けた2.5インチHDDです。

パッチを施したconfig.plistを以下に置いておきます。もしこれを使用する場合は、SystemSerialNumber, SystemUUID, MLB, ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

まとめ

リムーバブルドライブベイのホットプラグを可能にするCloverパッチを、OpenCoreのconfig.plist用に書き換えて動作を確認しました。これでまた一歩、OpenCoreに適応できた気がします。

つづき

Big Sur対応パッチはこちらをご覧ください。

リムーバブルHDD/SSDのホットプラグパッチ (Big Sur版)

OpenCoreの選択画面をグラフィカルにする

Mon, 18 May 2020 21:04:59 +0900

OpenCoreのデフォルトブートメニューはシンプルすぎるので、Cloverのようにアイコンで選択するよう設定しました。0.5.7以降でこの機能が使えるようです。

OpenCore GUI

前の記事で、ASUSマザーボードマシンのブートローダーをCloverからOpenCoreに移行しました。そのコメントで、OpenCoreでもアイコンによる起動選択ができるようになっていることを教えていただきましたので、試しました。以下での設定が終了していることが前提です。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

OpenCoreの起動画面をGUI化する方法に関しては、以下のページに使い方の説明があります。これに沿って進めました。アイコンによる選択のほか、起動チャイムやボイスオーバーも設定できるようです。ただ起動チャイムは、今のMacにはもうありませんし、不要かと思い設定しませんでした。

Resourcesの中身を用意する

配布されているOpenCoreのパッケージでは、OC/Resourcesの中にAudio, Font, Image, Labelというディレクトリがあるものの、中身は空でした。この中身を、以下のページから取り寄せて、入れておきます。たくさんのファイルがあります。特にAudioは、多国籍語のボイスオーバー用音声ファイルが入っていて、数が多いです。今回は、アイコン表示だけの作業なので音声ファイルは不要だとは思いますが、一緒に入れておきました。

GitHub - acidanthera/OcBinaryData

OpenCanopy.efiを設定する

アイコン選択を動かすためには、OpenCanopy.efiというドライバーが必要なようです。配布されているOpenCoreパッケージには含まれていましたが、前回の作業ではDrivers_offというディレクトリを作って、これに入れて外していました。これをDriversディレクトリに戻します。こんな感じになりました。最小限の構成です。

新しくDriversに追加したので、config.plistも書き換えておきます。簡単な作業なのでProperTreeのSnapshot機能は使わずに、ProperTree上での手作業でOpenCanopy.efiを追加しました。これくらいの作業ならテキストエディタで十分で、ProperTreeを使うまでも無いかもしれません。

config.plistのMisc項目を設定する

引き続きProperTreeを使い、以下の項目を設定します。

Misc -> Boot -> PickerMode: Sample.plistではBuiltinだった値をExternalに変更しました。
Misc -> Boot -> PickerAttributes:1 ガイドには1にせよとありましたが最初から1でした。この値のデフォルト値は0です。今回設定した1の他に、2, 4, 8とその組み合わせの選択肢があるようです。8を試してみたのですが、見た目は変わりませんでした。

この結果、このページの冒頭の写真のように、アイコンで選択できるようになりました。

まとめ

OpenCoreの起動選択画面でアイコン表示されるように設定しました。Cloverコミュニティの皆さんが競って作っているようなド派手な画面やミニマムでおしゃれな画面ではありませんが、本物のMacと同じアイコンを使った正統な起動画面だと感じました。今回は起動音の設定を行いませんでしたが、設定すれば起動チャイムやボイスオーバーが可能になるようです。ボイスオーバーは、本来はバリアフリーのための機能です。OpenCoreの開発者の方々も、その意識を持って起動音機能を整備していることがガイドに書かれていました。

追記：モダンなアイコン

コメントでまっくぷろさんから、今風の起動選択画面アイコンの情報をいただきました。Cloverのようにこれから増えていきそうですね。

GitHub - blackosx/OpenCanopyIcons: A range of .icns files designed specifical…

OpenCanopy Icons

追記：ミニマムなテーマ

ミニマムなテーマもありました。実機とは違うアイコンになりますが、macOS起動前の白りんごアイコンにマッチしたシンプルなアイコンです。

OpenCore用のミニマムなテーマ

追記：起動音を出す

こちらをご覧ください。

OpenCoreで起動音を鳴らす

追記：アイコンファイルの変更

最近のOpenCoreでは、アイコンファイルの設定方法が変更されています。こちらをご覧ください。（2021/7追記）

OpenCore 0.6.9から0.7.0に更新

Pioneer光学ドライブのパッチをOpenCoreに適用する

Sun, 17 May 2020 11:16:49 +0900

Pioneerの光学ドライブを使用していると「空のdvdがセットされました」というメッセージが出て、操作不能になることがあります。Cloverのconfig.plistでパッチを当てて対処していたのですが、OpenCoreに移行したので同様のパッチを当てました。

Cloverで使用していたパッチ

「空のdvdがセットされました」というエラーメッセージが出ることの原因と対策をこちらの記事で紹介しました。macOSがPioneerのドライブにスリープ指令を送りつけると、スリープ後も復帰しないことが原因のようです。そこで、光学ドライブにはスリープ命令を送らないように、macOSでは設定してあるらしいです。

光学ドライブを使う

なので、本物のMacと同型番のPioneer DVDドライブを使っていれば、操作不能に陥る問題は多分発生しないです。でも違う型番、例えばBDドライブを使う場合は、PioneerSuperDrive.kextにパッチを当てて、本物のMacが搭載している型番 (DVD-RW DVR-105) を、hackintoshで使用している型番 (例えばBD-RW BDR-205) に書き換えることで、この問題を解決できます。実際には、config.plistに以下のパッチを追加していました。これでスリープ命令が送られなくなり、操作不能に陥ることを回避できました。

<key>KextsToPatch</key>
  <array>
  <dict>
          <key>Comment</key>
          <string>PioneerBD-RW No Sleep</string>
          <key>Find</key>
          <data>RFZELVJXICBEVlItMTA1</data>
          <key>Name</key>
          <string>PioneerSuperDrive</string>
          <key>Replace</key>
          <data>QkQtUlcgICBCRFItMjA1</data>
  </dict>
  </array>

OpenCoreに移行したところ、再び、「空のdvdがセットされました」というエラーメッセージが出るようになりました。Cloverで使っていたパッチと同様の内容を、OpenCoreのconfig.plistにも書いておく必要があるようです。

CloverのKextToPatchをOpenCoreに移行する方法

OpenCoreには、CloverのようなKextToPatchの項目はありません。OpenCoreで、カーネルとkextに対してパッチを当てる項目は、Kernel, Patchの場所です。また、書式もCloverのパッチとは多少異なります。上記のCloverのパッチを、OpenCoreで書く場合は、以下になります。ちなみにReplaceの値は、BD-RW BDR-205の型番になっています。他の型番の光学ドライブを使用している方は、その型番に書き換えてください。詳しくは、以前の記事をご覧ください。

<key>Kernel</key>
<dict>
 <key>Patch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>PioneerBD-RW No Sleep</string>
 <key>Count</key>
 <integer>1</integer>
 <key>Enabled</key>
 <true/>
 <key>Find</key>
 <data>RFZELVJXICBEVlItMTA1</data>
 <key>Identifier</key>
 <string>com.apple.driver.PioneerSuperDrive</string>
 <key>Replace</key>
 <data>QkQtUlcgICBCRFItMjA1</data>
 </dict>
 </array>
</dict>

Cloverと比べてOpenCoreでは、一部のキーが削除追加されています。OpenCoreのサンプルconfig.plistを見ると、もっとたくさんのキーがあります。ただOpenCoreのパッケージに付属するマニュアルを読んでみたところ、デフォルト値のままで問題ないキーが多かったです。それらは省略しました。

Cloverのkeyのうち、Comment, Find, ReplaceはOpenCoreでも同じ名前で、同じ意味です。つまり、Commentは人が読むためのメモ書き、Findは検索データ列、Replaceは置き換えるデータ列です。これらはCloverの内容からそのままコピーしました。

Cloverでは、kextをファイル名（この例ではPioneerSuperDrive）で指定していました。使用するキーの名前はNameでした。OpenCoreでは、Identifierというキーで指定します。URLを逆順にしたような形式の一意の名前なので、より正確です。PioneerSuperDrive.kextがどのようなIdentifierなのかは、システム情報の拡張機能で、該当するkextを選択すると調べられます。

identifierは、バンドルIDという項目に書いてあります。以下のようです。Identifierの項目にはこれを書いておきます。

com.apple.driver.PioneerSuperDrive

Enabledキーでは、このパッチを有効にするかどうかを指定します。デフォルトがfalseですので、明示的にtrueを書いておかないと有効になりません。なので追加しました。

Countキーは発見された項目を何個置き換えるかを指定する箇所です。1個置換えてくれれば十分（それ以上検索する必要は無い）なので、1を指定しておきました。デフォルトは0で、それは発見できうる限り全て置換するという指定です。1箇所変換することで十分ならば、Countには1を指定したほうが、残りの部分を全部検索するという無駄な処理が不要になるので、高速になると思います。

このパッチをOpenCoreのconfig.plistに追加したところ、Pioneerのブルーレイドライブが正常に動くようになりました。パッチを施したconfig.plistを以下に置いておきます。もしこれを使用する場合は、SystemSerialNumber、SystemUUID、MLB、ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

PlistEDPlusで編集

（追記）PlistEDPlusでOpenCore 0.6.9のconfig.plistを編集する様子を以下に示します。いくつか項目が増えていますがデフォルトで良いです。データがASCII表示もされるので確認が楽です。

まとめ

Cloverに当てていた光学ドライブのパッチを、OpenCoreのconfig.plist用に書き換えて動作を確認しました。CloverとOpenCoreでは、パッチのキー構成が多少違います。Cloverに当てていた他のkext用パッチも、必要に応じてOpenCoreに移行して、動作を確認していこうと考えています。

ASUSマザーボードがPOST失敗してF1対応を促される

Sat, 16 May 2020 10:50:57 +0900

OpenCoreに移行したら再起動するたびに「safe modeでPOSTしたのでF1キーを押してsetupしてね」と言われるようになりました。config.plistでDisableRtcChecksumをtrueにすると治りました。

追記：当初、対策2と対策3の内容で対応していましたが、コメントでTakさんからDisableRtcChecksumで対応できることを教えていただきましたので、対策1として追記しました。

OpenCore移行したらPOSTエラー発生

ASUS ROG MAXIMUS HERO WIFI (Z390) をOpenCoreに順調に移行できたかに見えました。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

でも再起動をすると、POSTのエラーメッセージが出て、SETUP画面を起動しないと先に進めなくなりました。エラーメッセージは、

システムはセーフモードでPOSTしました。
これはシステムが不安定なために前回のPOSTの試みが失敗したこと、または、電源ボタンが長押しにより強制終了されたことが原因かもしれません。
もしUEFI設定を変更した後にPOST失敗したのでしたら、安定した設定に戻したいと希望されているでしょう。F1キーを押してSETUPを起動してください。

との表示です。この後、F1キーを押してSETUPに入り、そこから起動を選ぶと、今度は正しく起動します。なので大して困る状況ではないですが、次の再起動でまたこの画面になり、対応が面倒です。

Cloverの時はこのような現象はありませんでした。OpenCoreでシャットダウンして、Cloverを起動する場面でも発生します。なので、OpenCoreでシャットダウンするときに、何かしらの不具合が発生しているのかもしれないです。

ASUSでよくあること？

検索してみたところ、同様の現象は多数報告されています。今回と同様に、CloverからOpenCoreに移行したらこうなったという人も多いです。でも過去には、Cloverでも発生していたようです。発生はしていたけど、Cloverのバージョンが上がったら治ったという報告もありました。ということで、よくある現象のようです。

対策1：DisableRtcChecksumをtrueにする

対策2以降の記事を書いたところ、コメントでTakさんから教えていただきました。この方法で解決しました。OpenCoreコミュニティのおすすめの解決方法のようですので、対策2以降は無視していただいて良いです。config.plistのKernel, Quirksの場所にあるDisableRtcChecksumを、以下のようにtrue（デフォルトはfalse）に設定すれば治ります。OpenCore 0.5.8から可能になった方法です。

 <key>Kernel</key>
 <dict>
（中略）
 <key>Quirks</key>
 <dict>
（中略）
 <key>DisableRtcChecksum</key>
 <true/>

この問題はリアルタイムクロック (RTC) が関係する問題だそうです。macOSのAppleRTC.kextが、シャットダウンするときにチェックサム値をファームウェア（電池バックアップされたマザーボード上のCMOSメモリ？）に書き込むようです。おそらくはそのことでマザーボードのデータを壊してしまうらしく、次のPOSTで失敗を引き起こしているようです。チェックサムを書き込む場所が0x58~0x59（番地？）で、DisableRtcChecksumをtrueにするとそこへの書き込みを禁止してくれるようです。以下にも説明があります。

この説明によると、DisableRtcChecksumをtrueにしてもまだ問題が発生するようなら、RTCMemoryFixup.kextを入れて、ブートオプションで、

rtcfx_exclude=00-FF

のようにして、0x58~0x59以外の領域も保護するようにすると良いようです。これでうまくいった場合は、ブートオプションを変更して、保護する範囲を狭めると良いようです。

対策2：BIOSで設定する

追記：対策1が簡単で根本的なのでおすすめです。

有効な対策の一つが、このメッセージを出さないようにBIOSで設定する方法です。メッセージをよく読むと、「BIOS設定を間違って失敗した場合は、元に戻したいと思うから、F1キーでSETUPにすぐに入れるようにしておいてあげたよ。」という意味の内容が書いてあります。どうやらsafe modeでPOSTしたこと自体は大した問題ではなくて、利便性のためにF1キーですぐにSETUPに入れるよう配慮してくれているようです。今回はBIOS設定を間違えたわけではありませんので、この「親切機能」をoffにしても良いと思います。

BIOSの設定では、Boot, Boot Configurationの中に、Wait For ‘F1’ If Errorという項目があります。これが「POSTに不具合あったらF1キーを待つ」という設定です。デフォルトではEnabledなので、これをDisabledにします。これで問題なく起動するようになりました。

とはいえ、大元の原因は解決できていないので、応急措置な感じは拭いきれません。探したところ、もう少し根本的な対策もあるようです。

対策3：AppleRTCにパッチを当てる

追記：対策1の方が簡単です。そちらをおすすめします。

こちらで対策が紹介されていました。

OpenCore causes UEFI to POST in safe mode

ここで紹介されているパッチをOpenCoreのconfig.plistのKernel, Patchに追加したところ、この現象は発生しなくなりました。config.plistをテキストエディタで開いて、パッチを挿入します。Patchという項目は、ACPIの項目にもあるので、間違えないように注意です。（最初は間違えてしまってパッチが効きませんでした。）パッチを施したconfig.plistを以下に置いておきます。もしこのconfig.plistを使用する場合は、SystemSerialNumber、SystemUUID、MLB、ROMの値を必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

まとめ

OpenCoreにしたらsafe modeでPOSTする症状が出ました。ASUSではよくあることらしいです。SETUPに入ることを求められるので面倒です。config.plistでDisableRtcChecksumをtrueにして、シャットダウン時にmacOSがチェックサムを書き込まないように設定すると治りました。ということでOpenCoreの問題ではなくて、macOSとマザーボードの相性の問題のようです。Cloverで発生していなかったのは、単にデフォルトで対策されていただけなのかもしれないです。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

Fri, 15 May 2020 01:17:30 +0900

ASUSのZ390マザーボードと9900Kの組み合わせでmacOSを動かしているマシンのブートローダーを、CloverからOpenCoreに移行しました。OpenCoreのconfig.plistはCloverに比べて複雑ですが、親切なページと便利なツールがあったので円滑に移行できました。

OpenCoreのガイドとツール

Youtubeのビデオ

OpenCoreを使ってみた、という程度の記事を書きました。OpenCoreの基礎知識に関してはこちらをご覧ください。

新ブートローダーOpenCoreを使う

この当時は、OpenCoreは、Cloverに比べてconfig.plistがややこしくて面倒という印象でした。設定項目が多いだけでなく、kextやSSDTやefiドライバーの一つ一つをconfig.plistで記述する必要がありました。ところが最近、YoutubeでOpenCoreの設定ビデオを見ていたら、ProperTreeという便利なツールと、手順を解説した親切なサイトが紹介されていました。ハードウェア構成も、手元のメインマシンに近いので、このビデオを参考に、OpenCoreへの移行を試すことにしました。

OpenCore設定解説ページ

こちらのページがとても親切です。デスクトップPCを対象にした解説ページです。

config.plistのそれぞれの設定項目を、詳細に網羅的に説明してくれているので、Cloverよりもわかりやすいかもしれません。歴史の長いCloverは、すでに使われない設定項目なども多く、説明を探して読んでも無意味だったりすることもあります。OpenCoreの設定は、Cloverに比べて簡単ではありませんが、最新の設定方法情報がCPU別に整理されているのは助かります。

ProperTree

このページでconfig.plist編集に使われているツールがProperTreeです。ProperTreeはPythonで書かれたクロスプラットフォームのプロパティ編集ソフトで、macOSやhackintoshを前提としたツールではありません。それに、RedditのHackintoshサブレディットで活躍されているcorpnewtさんが手を入れて、OpenCoreのための機能を追加されたようです。

GitHub - corpnewt/ProperTree: Cross platform GUI plist editor written in python.

今まで、config.plistはテキストエディタで編集する、というストイックな対応をしてきましたが、OpenCoreのconfig.plistは長くて複雑です。なので今後はこのツールを使っていきます。

ProperTreeを使うためには、上記のサイトからファイル一式をダウンロードします。ダウンロードしたファイルの中のProperTree.commandがメインのPythonプログラムです。ファインダーからこれを開くか、またはTerminalから起動します。ファインダーから開く場合は、Terminalのウィンドウが一つ開いて、GUIウィンドウが現れます。Automator.appなどを使えばもっとアプリケーションっぽく見せられるとは思いますが、こういう形式も無骨で良いと思います。これでconfig.plistなどを開くと、XcodeのPlistエディタのように項目を開いたり閉じたりして閲覧し、内容を変更・追加・削除できます。

OpenCore Sanity Checker

OpenCoreのconfig.plistの正常性をチェックしてくれるページです。CPUとOpenCoreのバージョンを指定して、config.plistファイルをドラッグ&ドロップすると検査結果を表示します。この記事の最後で、作成したconfig.plistのチェックを行いました。

OpenCore config.plist Sanity Checker

ハードウェア構成

この記事の対象としたマシンは、以下で紹介したZ390マザーボード＋9900Kです。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ハードウェアの構成を再掲すると、

マザーボード： (値上がりしてますね)
CPU： @ 4.00GHz
グラフィックス：
WiFi/Bluetooth： (中身はBCM94360CD)

です。最新のmacOS, Clover, kext類の構成で、全く問題なく稼働しています。以下では、これをOpenCoreに移行します。

ファイルを入手してESPに置く

OpenCoreのダウンロード

以前の記事で紹介したように、Kext Updater.appを使いました。ダウンロードした中身には、Docs, EFI, Utilitiesの3個のディレクトリがありました。DocsとUtilitiesの中身は、そのうち少しずつ調べていきたいと思います。メインなのはEFIです。

OpenCoreの初期EFIをコピーする

ダウンロードしたOpenCoreファイルの中にあったEFIフォルダは、そのままESPにコピーして使います。またDocsの中にあるSample.plistを、config.plistと改名して使います。そのために、現在のマシンのESPをマウントします。そして現行のEFIを、例えばEFI_Cloverという名前に改名します。いきなり稼働中ドライブのESPを変更するのは危険かもしれませんので、他のドライブのESPやUSBメモリのESPで試しても良いかもしれません。起動に失敗したらUEFIシェルで名前を戻せば良いと思ったので、今回はメインドライブを直接変更してしまいます。

% sudo diskutil mount disk0s1
Password:
Volume EFI on disk0s1 mounted
% cd /Volumes/EFI 
% ls
EFI
% mv EFI EFI_Clover
% ls
EFI_Clover

ここに、ダウンロードしたOpenCoreのEFIをコピーします。また、Docsに入っていたSample.plistをconfig.plistに改名してEFIに入れます。

% cp -R ~/Desktop/Kext-Updates/OpenCore/EFI .
% cp ~/Desktop/Kext-Updates/OpenCore/Docs/Sample.plist EFI/OC/config.plist
% ls
EFI		EFI_Clover
% ls EFI/OC 
ACPI		Drivers		OpenCore.efi	Tools
Bootstrap	Kexts		Resources	config.plist

ここではTerminalでシェルコマンドを使って操作していますが、ファインダーでドラッグ&ドロップで行っても全く問題ありません。（ドラッグ&ドロップ中のスクリーンショットを撮るのが面倒だったのです、すみません）。結果としてこんな状態になりました。

ACPIの中身を用意する

EFI/OCの中をこれから設定していきます。まずはACPIフォルダの中です。EFI/OCに移動して、ACPIフォルダの中を見ると、空っぽです。

% cd EFI/OC
% ls ACPI 
%

上記の解説ページのCoffee Lakeの説明によると、Coffee Lakeマシンに必要なSSDTは、以下の4個です。

SSDT-PLUG Haswell以降のネイティブなCPU電力制御を担当。
SSDT-EC-USBX 組み込まれたコントローラーを隠して、macOS用のフェイクなコントローラーを作ります。Catalinaユーザには必須で、他のバージョンでも使うことを推奨します。
SSDT-AWAC 300シリーズチップセット用のRTCパッチ。ほとんどのB360, B365, H310, H370, Z390といくつかのZ370マザーボードでこれがないとブートしない。
SSDT-PMC 本当の300シリーズマザーボード(つまりZ370は除く)はファームウェアでMMIOを宣言していないので、問題を起こします。そのようなマザーボードがNVRAMをサポートするために必要です。

上記のサイトにはコンパイルされたバージョンもありますし、ソースコードが掲載されたGitHubへのリンクもあります。なのでダウンロードすればokです。もしくは、ソースコードからコンパイルしても良いでしょう。その場合、GitHubのページに行き、Rawボタンをクリックして、全選択して、MaciASL.appでコンパイルします。MaciASLについては、こちらをご覧ください。

DSDTを編集する

例えば、SSDT-PLUGをコンパイルする場合は、ガイドに書かれているGitHubのページに行き、Rawボタンを押します。これで現れるテキストを全部コピーします。

次にMaciASL.appを起動し、新規ウィンドウを開いておき、ここにペーストします。

次に、MaciASL.appのFile, Save As…メニューを選び、出てくるダイアログでFile Format:をACPI Machine Language Binaryに設定し、SSDT-PLUG.amlという名前で保存します。こうして得られた4個のSSDTをACPIディレクトリに入れます。

あともう一つ。USBの15個制限対応のために、SSDTを作ってありました。このSSDT-UIAC.amlも、ACPIディレクトリに入れておきました。なので使用するSSDTは全部で5個になりました。

15個制限を回避するUSBInjectAll.kextの役割と使用法

Driversの中身を整理する

Driversディレクトリは、初期状態では以下のようになっています。

解説によると、必要なDriverは以下の2個だけのようです。

HfsPlus.efi
OpenRuntime.efi

HfsPlus.efiはCloverでも使われている、HFS+ファイルシステムを読み込むドライバーです。HFS+から起動する場合に必要です。OpenRuntime.efiは、CloverでのAptioMemoryFix.efiに相当するドライバーのようです。Catalinaの時代なのでHFS+で起動することはもう無いと思いました。配布物にもHfsPlus.efi (もしくはVBoxHfs.efi) が含まれていません。そこでOpenRuntime.efiだけを使うことにします。

使用しないドライバーを消してしまうと、後で必要になるかもしれないので、ファイルは残しておきたいと思いました。おそらく、ファイル自体はこのディレクトリに残しておいて、config.plistの方で無効にするのがOpenCore流儀なのではと思います。でも不要なファイルは所定のディレクトリから外すというClover方式に慣れているので、offにするディレクトリを作って、使わないファイルをそちらに移すことにしました。以下の例では、Drivers_offというディレクトリを作って、OpenRuntime.efi以外はそちらに移動しました。

Kextsの中身を用意する

Kextsディレクトリも初期状態では空っぽです。現在、Cloverで使っている以下のkextをそのまま入れておくことにします。

AppleALC.kext
IntelMausi.kext
Lilu.kext
USBInjectAll.kext
VirtualSMC.kext
WhateverGreen.kext

Toolsの中身を整理する

これもDriversディレクトリと同様に、多数のファイルが初期状態で入っています。

デバッグするときに使用するツールらしいです。上記のガイドによると全部不要らしいです。でもUEFI Shellは絶対に欲しいと思いました。なのでそれだけを残して、他はTools_offというディレクトリを作って、そちらに移動しておきました。

以上で必要なファイルが、必要な場所に保存されました。あとはconfig.plistを設定するだけです。

Config.plistを設定する

コメントを消す

config.plistの全ての設定にはProperTreeを使います。config.plistが複雑すぎるので、テキストエディタを使うことは諦めました。ProperTreeを起動して先ほどSample.plistをコピーして作ったconfig.plistを開きます。

最初の5項目の#WARNINGとあるのはSample.plistの警告のコメントです。不要なので削除します。行の上でコンテクストメニューを開くと、メニュー項目にRemove …があります。これを選びます。

OC Clean Snapshotを使う

ProperTreeにはOC Clean Snapshotというメニュー項目があります。この機能が凄いです。これがあることを知ったことで、OpenCoreに移行する気になりました。OpenCoreのconfig.plistで一番面倒だと思っている点は、使用するSSDT, kext, efiドライバー, efiツールなどを全部config.plistに記載しておく必要があることです。名前を書いておくだけでなく、いろいろな設定も書いておく必要があります。ディレクトリに放り込んでおくだけでokだったCloverに比べて、面倒でした。kextを起動する順番を、config.plistの記述順で指定できるので、必要な機能なのかもしれませんが。

このようなconfig.plistへの記述を自動化してくれるのがOC Clean Snapshotです。ProperTreeのメニューを開くと、OC SnapshotとOC Clean Snapshotの二つのメニューが現れます。

おすすめはOC Clean Snapshotの方です。これを選択すると、ACPI, Drivers, Kexts, Toolsディレクトリに入っているファイルを検出して、必要なconfig.plist設定を自動的に作ってくれます。例としてkextファイルの自動検出を示します。まずは初期状態のconfig.plistです。7個のkextが登録されていますが、先ほど保存したkextとは一致していません。Legacy_USB3.kextとAppleMCEReporterDisabler.kextの2個はKextsディレクトリに入っていません。その一方でKextsディレクトリに入れたUSBInjectAll.kextの項目がありません。従来ならば手作業で修正する必要がありました。

ここでProperTreeのOC Clean Snapshotを動かします。すると、ファイルを検出するOCディレクトリの場所を聞いてきます。そこで作業中のOCディレクトリを指定します。

すると、Kextsディレクトリに入っているkextのリストに自動的に置き換えてくれます。

このkextリストは、この順番に読み込まれるので、基本的なkextを先に読み込む必要があります。例えばLilu.kextは一番上に、次がVirtualSMC.kextなどの順番で記述する必要があります。ProperTreeのOC Clean Snapshot機能は、その順番も正しく判断してくれます。Kexts以外に、ACPIとDriversとToolsの中身も検索して、自動的に該当する箇所の記述を更新してくれます。

ACPIとKextsとToolsディレクトリのファイルに関しては、config.plistの記述の中でEnabledキーをTrueまたはFalseにすることで、個別にon/offすることが可能です。OC Clean Snapshot機能は、全てTrueにしてくれます。一方、OC Snapshot機能は、全てFalseにします。手動で必要なものを選ぶことになります。ACPIとKextsとToolsディレクトリ内にあるSSDT, kext, efiツールを有効にしたいという目的からしたら、OC Clean Snapshotの方が理にかなっていますし、こちらを使うのが便利だと思います。

ACPI項目

ではガイドのページと、ProperTreeのウィンドウを見比べながら細かい設定をしていきます。まずはACPI項目です。OC Clean Snapshot機能によりAddの内容は自動設定されています。これ以外の項目は全てデフォルト（Sample.plistの記述）のままで良いようです。

Booter項目

Quirksの項目のいくつかをデフォルトから変更します。辞書によるとquirksは、予想外の曲がり、ひねり、とか気まぐれのような意味だそうです。fuchsiaさんからコメントで教えていただいたUbuntu wikiの記載によると、ハードウェアのバグを回避するためのソフトウェア手法というような意味だそうです。ソースコードを読む時に、「なんでこんなことやっているんだろう」と不思議に思うだろうことから、予想外に曲折した状態というニュアンスで使われているのではと思いました。Sample.plistの設定から変更するQuirksは以下です。

DevirtualiseMmio: True、slideオプションの拡張。Z390のメモリ確保に有効。
RebuildAppleMemoryMap: True、macOS互換のメモリーマップを作る。
SyncRuntimePermissions: True、Skylake以降でMATテーブルの問題を解決。
SetupVirtualMap: False、仮想アドレスの問題を解決。Skylake以降では不要。

DeviceProperties項目

この項目の設定方法はCloverの該当項目と同様です。Sample.plistの初期値ではPciRoot(0x0)/Pci(0x1b,0x0)のオーディオに関する情報しか書いてありません。

mifjpnさんからコメントで指摘いただいたのですが、オーディオのdevice pathが違っていました。多分、マザーボードの配線によるのだと思いますが、使用したマザーボードでは、PciRoot(0x0)/Pci(0x1b,0x0)ではなくて、PciRoot(0x0)/Pci(0x1f,0x3)でした。Hackintool.appでも確認できますし、ioregコマンドでも確認できました。

% ioreg | grep AppleHDAController 
 | | | +-o AppleHDAController@1F,3 <class AppleHDAController, id 0x10000055a, registered, matched, active, busy 0 (976 ms), retain 34>

なのでPciRoot(0x0)/Pci(0x1b,0x0)をPciRoot(0x0)/Pci(0x1f,0x3)に書き換えます。内容の方の、Layout IDはCloverの時も、Sample.plistの通り1でしたのでこれはそのままです。

Audioに加えて、DevicePropertiesには、iGPUの情報をWhateverGreen.kextに伝える目的で、PciRoot(0x0)/Pci(0x2,0x0)の項目を追加します。Addの項目でコンテクストメニューを開き、New child under …のメニュー項目を選択します。すると新規な項目が現れるので、内容をPciRoot(0x0)/Pci(0x2,0x0)にしてtypeをDictionaryにします。さらにここにchildを作り、名前をAAPL,ig-platform-idにし、typeをDataにします。今回は、iGPUをヘッドレスとして使うので、値は、0300923Eにします。結果として、以下のようになります。

Kernel項目

Addの項目に記述するkextファイルの情報は、OC Clean Snapshot機能により自動設定されています。Quirksの項目のいくつかをデフォルトから変更します。デフォルトから変更する箇所は以下です。

AppleCpuPmCfgLock: True、BIOSでCFG lockが解除できるなら不要です。ASUSのZ390マザボは解除できるのでFalseでも良いです。CloverのAppleIntelCPUPMに相当します。
AppleXcpmCfgLock: True、BIOSでCFG lockが解除できるなら不要です。ASUSのZ390マザボは解除できるのでFalseでも良いです。CloverのKernelPMに相当します。
DisableIoMapper: True、BIOSでVT-Dを無効にできるなら不要です。ASUSのZ390マザボは無効にできるのでFalseでも良いです。dart=0より良い選択肢です。
PanicNoKextDump: True、カーネルパニックの情報が読めるようになります。
PowerTimeoutKernelPanic: True、パワー変化によるカーネルパニックを防ぎます。デジタルオーディオに関係します。

Misc項目

DebugとSecurityのいくつかの項目をデフォルトから変更します。

AppleDebug: True
DisableWatchDog: True watch dog timerを無効にします。
Target: 67、この値が0以外の場合、EFIディレクトリにopencore-2020-05-15-xxxxxx.txtというような名前のログファイルが書き込まれます。Sample.plistでは3になっています。67にするともっと多くのデバッグ情報がログファイルに書き出されます。ログファイルが不要なら0にします。
AllowNvramReset: True
AllowSetDefault: True
ScanPolicy: 0、0にしないとUSBメモリーから起動しないらしいです。
Vault: Optional、デフォルトのSecureのままでは起動しないです。Optionalは大文字で開始します。

NVRAM項目

本物のMacならばNVRAMに記録されるべき項目の設定です。Addでは、

boot-argsのデフォルトにdebug=0x100 alcid=1を追加しますとあります。どちらも追加しなくても良いように思います。debug不要ならその指定は不要だと思います。DevicePropertiesのところで1に設定してあるので、alcid=1も不要です。
prev-lang:kbdを手持ちのキーボードに合わせて設定します。デフォルトはロシア語になっています。USキーボードの場合は656e2d55533a30にします。

を変更します。またWriteFlashはNVRAMに設定値を書き込む設定で、Trueにしますと書いてありますが、どちらでも良いように思います。

Platform項目

CloverのSMBIOSに相当する項目ですね。機種IDは、Mojave以降はiMac19,1, High Sierra以前はiMac18,3が良いようです。その時代に未発売なMacの機種IDは使うなということですね。現在使用中のCloverのconfig.plistからSerialNumber, BoardSerialNumber, SmUUIDをコピーして、それぞれを、

SystemSerialNumber
MLB
SystemUUID

にコピーしました。またROMの項目には、NICのMACアドレスを書いておけば良いようです。システム環境設定のネットワークから取得したEthernetのMACアドレスを書いておきました。

UEFI項目

Driversの項目に記述するefiドライバーの名前は、OC Clean Snapshot機能により自動設定されています。Quirksの項目のRequestBootVarFallbackをTrueに変更します。と書いてありますが、説明読んでもあまり違いはない気がしました。

以上でconfig.plistの設定が終了しました。それぞれの項目の説明がそれなりに書いてあるので、Cloverよりも明朗な感じです。説明資料が整っている印象があります。この状態で再起動すればOpenCoreから起動するはずです。起動しなければ、UEFI shellからEFIディレクトリの名前を書き換えて、Cloverに戻せば良いと思います。と考えて再起動を試したところ、なんと1回で成功しました。完成したconfig.plistを以下に置いておきます。SystemSerialNumber、SystemUUID、MLB、ROMの値は、これを使用せず、みなさんで必ず置換えてください。

OpenCore config.plist for 9900K - Pastebin.com

Sanity Checkerで検証

ここで作ったconfig.plistを、OpenCore Sanity Checkerで検証しました。

OpenCore config.plist Sanity Checker

赤い❌マークで警告を受けたのはUEFI, Driversの箇所で、VBoxHfs.efiもしくはHFSPlus.efiが無いという項目1点だけでした。上でも説明しましたが、Catalinaより古いmacOSを使う予定がなかったので、入れてませんでした。無しのままにしておきます。

青い❗️マークが1点、Misc, Toolsで出ていました。「You can remove the tool EFIs here」と表示されています。Toolsには、OpenShell.efiだけを入れてあります。UEFI Shellは、File Vault起動のセキュリティを回避できてしまうので、デバッグが終わったら外しておくようにという意味かと思いました。Toolsの記述を消すと、このマークは出なくなります。ただ、File Vault起動は使っていないですし、いざというときにUEFI Shellは欲しいので、これも無視しておきます。

黄色の❓マークが、以下の3カ所で表示されていました。

SetupVirtualMapがNoだけど通常はYesです。
DisableIoMapperがNoだけど通常はYesです。
PointerSupportModeがASUSだけど通常は空白です。

上記で説明したように、SetupVirtualMapは仮想アドレスの問題を解決する機能ですが、Skylake以降では不要とのことでNoにしました。DisableIoMapperは、VT-Dを無効にする機能ですが、BIOSで無効にできているのでNoにしました。PointerSupportModeは、大もとのSample.plistでASUSとなっていました。OpenCoreのマニュアルを調べたところ、マウスポインター操作をサポートする設定らしいのですが、ASUSのZ87, Z97マザーボードだけがサポートされているらしいです。このパラメータは指摘どおりに空白にしておきました。

その他の設定

コメントでいただいた情報と、その後の記事で設定した項目を以下にまとめておきます。いろいろ情報をいただいて本当にありがとうございます。

起動ボリュームの指定

初期設定のままだと、リストの最初のドライブから起動します。起動ドライブを指定するには、macOSのシステム環境設定の起動ディスクを使います。ここで、起動させたいボリュームを選ぶと、その後、それで起動するようになります。Cloverでは起動ドライブの名前などをconfig.plistに書いていましたが、OpenCoreではよりmacOSに近い方法が可能になりました。

Kext Updaterを使う

Sample.plistの設定でKext Updater.appを起動すると、「Misc, Security, ExposeSensitiveDataの1, 2ビットをonにする」ように指示が出ます。デフォルトでは6だったので7にしました。コメントで教えていただきました。

rtc-blacklistが見つからない警告

起動時に出るかもしれない警告、

Warn:oc:setting nvram 4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102:rtc-blacklist – not found oc

は、NVRAMの4D1FDA02-38C7-4A6A-9CC6-4BCCA8B30102のrtc-blacklistを消すと出なくなります。コメントで教えていただきました。

Windowsが起動しない

Misc, Boot, BlessOverrideに, \EFI\Microsoft\Boot\bootmgfw.efi などと追加します。コメントで教えていただきました。

続きの記事

この記事に続く以下の記事でもOpenCoreの設定を行なっています。

ASUSマザーボードがPOST失敗してF1対応を促される

Pioneer光学ドライブのパッチをOpenCoreに適用する

OpenCoreの選択画面をグラフィカルにする

リムーバブルHDD/SSDのホットプラグパッチをOpenCoreに適用する

使用するUSBポートを15個指定する (OpenCore編)

まとめ

Z390マザーボードのマシンをCloverからOpenCoreに移行しました。それなりに時間はかかりましたが、すんなりと運びました。今回はCoffee Lake CPUマシンの移行でしたが、他のCPUについても同様に詳しい手順が説明されているので、問題なく移行可能と思います。説明資料やチュートリアルが充実していて、ツールも揃っているので、そろそろOpenCoreに移行しても大丈夫な時期になったかと感じました。細かい設定などを調べつつ、他のマシンも、順次切り替えていきたいと思います。

100シリーズチップセットで本物のNVRAMを使う

Sat, 09 May 2020 23:34:38 +0900

SSDT-PMC.amlをEFI/CLOVER/ACPI/patchedに入れると、Intel 100シリーズチップセットでもNVRAMの値が保存されるようです。Q170搭載のHP社小型デスクトップPC、HP EliteDesk 800 G2 DMで試した結果を報告します。

これも、「HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM にmacOSを入れる」シリーズの記事ですが、小ネタです。

HPの小型デスクトップEliteDesk (1: macOS導入)

300チップセットでNVRAMを使う

NVRAMを使うために、従来は、EmuVariableUefi.efiドライバを入れていました。でも300シリーズチップセットではNVRAMの内容が正しく保存されない問題がありました。しかし、最近OpenCoreの成果で作られたSSDT-PMC.amlを使えば、300シリーズチップセットでもNVRAMが正しく使えます。という記事を、以下に書きました。

300シリーズマザーボードでも本物のNVRAMを使いたい

100チップセットでもNVRAMを使う

最近、HP EliteDesk 800 G2 DMのスリープ対策で色々試していたところ、このマシンでもEmuVariableUefi.efiではNVRAMに書き込めないことに気づきました。公開されている仕様書によると、HP EliteDesk 800 G2 DMはQ170チップセットを使っています。100シリーズチップセットでも300シリーズチップセットと同様な問題があるようです。

そこでSSDT-PMC.amlを使ってみたところ、なんと正しくNVRAMが動きました。ということで、SSDT-PMC.amlは、300シリーズに限らず、おそらく100シリーズでも有効なようです。以下に、EmuVariableUefi.efiを使った場合と、SSDT-PMC.amlを使った場合の比較を書いておきます。

EmuVariableUefi.efiを使う

まずは、EmuVariableUefi.efiを

EFI/CLOVER/drivers/UEFI/EmuVariableUefi.efi

の場所に入れて起動した場合です。ターミナルからnvramコマンドで、意味のないhogeという名前の変数にtestという文字を登録します。nvram -pコマンドで確認できるので、そこからhogeだけ取り出して表示します。この一連の作業を行った結果を以下に示します。

% sudo nvram hoge=test
Password:
% nvram -p | grep hoge
hoge	test

ここで再起動します。再起動後に、nvram -pコマンドを試すと以下になりました。

% nvram -p | grep hoge

再起動前に設定した変数が消えています。

SSDT-PMC.amlを使う

次にSSDT-PMC.amlを

EFI/CLOVER/ACPI/patched/SSDT-PMC.aml

に入れて起動します。この状態で、ターミナルからnvramコマンドで、同様に変数hogeにtestという文字を登録して、nvram -pコマンドで確認します。

% sudo nvram hoge=test
Password:
% nvram -p | grep hoge
hoge	test

ここで再起動します。再起動後に、nvram -pコマンドを試すと以下になりました。

% nvram -p | grep hoge
hoge	test

SSDT-PMC.amlを入れておけば、Q170チップセットでもNVRAMに値を入れて、再起動後も読み込めるようです。ちなみにSSDT-PMC.amlを入れた状態で設定した変数は、これを外してEmuVariableUefi.efiを入れた状態でも読み込めました。EmuVariableUefi.efiを使うと、再起動前に変更したり書き込んだ結果が消えてしまうものの、正しく書き込まれているNVRAM値は読めるようです。

まとめ

SSDT-PMC.amlは300シリーズチップセットだけでなく、他のチップセットでも有効なようです。300シリーズ以外のユーザの皆さんも、ぜひお試しください。その結果をコメント欄で報告いただければありがたいです。ちなみに設定してしまった意味のない変数は、

% sudo nvram hoge=

とすれば消せます。

ThinkPad T460s (6300U) にOpenCoreでCatalinaを導入

Tue, 14 Apr 2020 22:53:41 +0900

Skylake 6300Uを搭載したThinkPad T460sにOpenCore (OC) でmacOS Catalinaをインストールしました。手順と必要ファイルが揃っているGitHubページがあったので、苦労なしで完成度の高いmacOSマシンが出来上がりました。

動作状況

最初に動作状況をまとめておきます。完成度はかなり高いです。

動くこと

macOS Catalina 10.15.4
macOSのアップデート (10.15 –> 10.15.4)
シャットダウンおよびSleepとsleepからの復帰
iGPUのグラフィックス加速
LAN
USB 3.0 x 3 (Gen 1, 5Gbps)
サウンド（内蔵スピーカ・ヘッドフォン自動切り替え）
内蔵カメラ・マイクロフォン
Fnキーからの明るさ・音量調整
Siriの音声認識
バッテリー残量表示
HDMIからの表示
高DPIスケール動作（720p相当を1.5倍の1080pで表示中）
Night Shift
マルチタッチジェスチャ（2本指でスクロールできる程度）
App Store

動かないこと

Wifi/Bluetooth (M.2モジュールを交換予定)
SDカード、指紋認証（macOSが非対応なので無理です）

未確認なこと

continuity, iPhone, iPad, Watchとの連携, AirDrop, Sidecar, iCloud, iMessage, FaceTime（WiFi/BT交換後に試します）
Mini DisplayPortからの表示（mini DPはもはや使わない）
WWANカードとSIM（動かしている例もあるらしいです）

ThinkPad T460sについて

以前、X220にmacOSをインストールしました。今回は少し大きめのT460sにmacOSをインストールします。

Lenovo ThinkPad X220, 2620M

X220は昔ながらの作りの良いキーボードを採用した最後のモデルです。でも第2世代Sandy Bridge CPUなのでCatalinaは公式サポートされてません。次にノートPCでhackintoshするなら、現行macOSが動く第3世代 (IvyBridge) 以降のCPUで試したいと思っていました。また、先日、HPのHP EliteDesk 800 G2 DMがとても簡単に動いて、気に入っていました。

HPの小型デスクトップEliteDesk (1: macOS導入)

第6世代 (Skylake)はmacOSとの相性が良さそうな気がします。またSkylakeならCatalinaで動くだけでなく、Sidecarにもギリギリ対応しています。Kaby Lake, Coffee Lakeならばさらに新しくて良いのですが、遊ぶ目的としてはまだ高価です。Lakeシリーズ初代のSkylake搭載製品ならば、5-6年前の製品なので、リース終了後の法人物件が出回っていて、値段が手ごろです。8GBメモリ、256GB SSD程度の構成で、デスクトップなら1万円代、ノートPCでも2万円代で中古品が購入可能です。

Skylake搭載ThinkPadで中古品を探すと、X260とT460sが目につきました。ThinkPadは型番3桁部分の、100の位がディスプレイの大きさ（12インチなら2, 14インチなら4）で、10の位がCPUの世代数を表しています。例えばX260は第6世代の12インチモデルで、T460sは第6世代の14インチです。X260とT460sはほぼ同じくらいの中古価格で取引されています。どちらにするか大いに迷いました。でも、macOSのインストール状況を検索した限りでは、X260では多くの人が困難に遭遇しているのに対して、T460sではインストール手順情報が充実していて成功率が高い様子でした。構造はほとんど変わらないと思うので、単にユーザ数の違いかもしれません。それでも成功例報告の多いT460sにしました。後述のように、T460sの到着前に、さらに親切なGitHubページを発見できてラッキーでした。

到着して開封した時、予想以上に薄いので驚きました。実は、T460とT460sは販路が違うだけで同じものだと思い込んでいました。ネットにあったT460の分解動画をいくつか見ていて、その厚さだと思ってました。sが付くだけで全然違うモデルなのですね。T460は、2.5 inch SSD, 取り外し可能バッテリーなのに対して、T460sは、M.2 SSD, 内蔵バッテリーのみになり、薄くなっています。他にもいくつか変更されています。メモリーソケットが2個から1個に減っています。これは少し残念ですが、マザーボードに8GB搭載されていたので十分です。T460sになって一番嬉しいことは、裏蓋を止めている爪が簡単に外れるようになったことです。T460の分解動画では裏蓋の隙間にヘラを入れてベキベキと外していた様子だったのが、なんの苦労もなく裏蓋が外れます。裏蓋を止めているネジも8個から5個に減りました。

入手したT460sの液晶はfull HDのIPS液晶でした。国内販売品は全部FHDのようです。タッチ入力対応のモデルもありますが、macOSでは不要でしょう。

キーボードは相当にテカってます。プラスチック表面のシボ加工が取れて、ツルツルの面になってます。汚れているわけではないですが、触るとペタペタした感触があります。さらにはA, H, Nなどのキーは文字も消えかけています。前のユーザのお役に立って活躍していたようです。で売ってますので、交換したいと考えています。同じ世代のThinkPadでもX260はキーボード交換がかなり面倒なのですが、T460シリーズはThinkPadの伝統を引き継いでいて、交換が楽です。

裏蓋は5個のネジで外れます。ネジは蓋から外れない方式なので、行方不明になる心配がありません。分解動画で比較すると、T460に比べてT460sは爪がすぐに外れるように作られているようで、分解が楽です。裏蓋を開けた中は以下のようです。

内蔵バッテリーが写真の上下に2個あります。全体にかなり薄型なのですが、まだまだいろいろいじれる部品構成です。中央右のヒートパイプの端あたりにCPUがあります。その下に、DDR4 SODIMMの空ソケットが一つあります。マザーボードにメモリーが既に搭載されていて（今回入手したモデルは8GB）、これに加えて増設できます。CPU左側の黒い絶縁シートが貼られた大きなエリアは、空き地です。Nvidia GeForce 930MというGPUを搭載するモデルがあり、そのGPUの接点がある場所です。macOSではサポートされていないGPUですので、GPU搭載モデルを選ぶ必要はありません。

左の部分には3種類のM.2のソケットがあります。それぞれ、WLAN, WWAN, SSD用です。WLANはインテルのM.2モジュールが取り付けられています。無線LANとBluetoothが搭載されています。インテルの無線LANはmacOSでは使えません。Bluetoothはどういうわけかシステム環境設定に現れますが、これも使用不可能です。BroadcomのM.2モジュールに交換する予定です。参考にしたGitHubページでは、M.2用アダプタを使って純正のBroadcomモジュール、BCM94360CS2を取り付ける様子が紹介されています。厚みが増えるため裏蓋が少し浮くようですが、この方式ならmacOSとの互換性は完璧です。

WWAN用のM.2ソケットは空です。でもアンテナは配線されています。国内の一般販路ではWWANモデルは流通していないらしいです。

M.2 SSDソケットには切り欠きが2箇所あるSSDが装着されていました。型番から東芝のSATAタイプの256GB M.2 SSDだと判明しました。これだけ容量があれば、macOSの動作には問題ありません。手元のSSDで試したところ、NVMe方式のM.2 SSD（切り欠きが1箇所のタイプ）も使えました。

OpenCoreで導入を試みる

今回のmacOS導入は、全く努力してなくて、落ちていたESPファイル類を拾ってコピーしただけのヘタレなハッキングです。こちらのサイトのおかげです。本当に感謝したいです。

GitHub - simprecicchiani/ThinkPad-T460s-macOS-OpenCore: Bootloader configurat…

実はこのGitHubページは、先月末にできたばかりのようです。このページを使ってT460sでmacOSを動かせたことが、T460sの到着前日にRedditで紹介されていて知りました。デスクトップに比べてノートPCのhackintoshは複雑なので、tonymacx86やredditで実績のある機種を選んだ後で、実際に調達するという手順が良いように思います。

BIOSを設定する

上記のサイトにはBIOS設定も書いてあります。以下の設定が必要とのことです。

Security -> Security Chip Disabled
Memory Protection -> Execution Prevention Enabled
Virtualization -> Intel Virtualization Technology Enabled
Virtualization -> Intel VT-d Feature Disabled
Anti-Theft -> Current Setting Disabled
Anti-Theft -> Computrace -> Current Setting Disabled
Secure Boot -> Secure Boot Disabled
Intel SGX -> Intel SGX Control Disabled
Device Guard -> Disabled
UEFI/Legacy Boot -> UEFI Only
CSM Support -> No

これ以外も趣味に合わせて設定しました。例えば、WiFi, Bluetooth, 指紋センサー、SDカード読み取り機などはmacOSで動きませんので、節電になるかと思いdisabledに設定しました。

macOS導入用USBメモリを作成する

まずは通常のhackintoshの手順に従って、まずはインストール用のUSBメモリーを作成しました。Appleのサイトに書いてあるようにcreateinstallmediaコマンドを使います。こうして作成したUSBメモリのESP (EFI System Partition) をマウントします（diskutil listコマンドでUSBメモリのESPが例えばdisk5s1だとわかったら、sudo diskutil mount disk5s1とタイプします）。次に、上記のサイトからダウンロードしたESPの内容を、ごっそりとUSBメモリのESPにコピーします。ファインダーのドラッグ&ドロップで可能です。

こうして設定されるkext類は以下です。VoodooPS2Controllerなどは、キーボードやトラックポイントを動かすためのkextだと思います。

WhateverGreen.kext
VoodooPS2Controller.kext
USBPorts.kext
VirtualSMC.kext
VoodooInput.kext
SMCProcessor.kext
SMCSuperIO.kext
SMCLightSensor.kext
SMCBatteryManager.kext
Lilu.kext
IntelMausi.kext
CPUFriend.kext
AppleALC.kext

efiドライバーは以下です。Cloverに比べると少ないですね。

OpenRuntime.efi
HfsPlus.efi
ApfsDriverLoader.efi

SSDT類は大量にあります。バッテリー、電力制御、PS2関係など色々用意されているようです。これらを自分で作るのは大変なので、ありがたいです。

SSDT-XCPM.aml
SSDT-ALS0.aml
SSDT-BAT.aml
SSDT-BATC.aml
SSDT-BKeyQ14Q15.aml
SSDT-DMAC.aml
SSDT-EXT3-LedReset.aml
SSDT-EXT4-WakeScreen.aml
SSDT-MCHC.aml
SSDT-PMCR.aml
SSDT-PNLF.aml
SSDT-PS2K.aml
SSDT-PTSWAK.aml
SSDT-PWRB.aml
SSDT-SMBU.aml
SSDT-UIAC.aml
SSDT-USBX.aml

config.plistをカスタマイズする

配布されているconfig.plistでは、機種がMacBookPro13,1に設定されていました。この機種はCPUとして6360U, 6600Uを搭載しているので、6300Uで使用するには適切な選択です。ただMacBookPro13,1のiGPUはIntel Iris Graphics 540なので、6300UのIntel HD Graphics 520とは違います。でもこれで問題なく動きました。ただ、このconfig.plistには個別のマシンの情報が入っていないので、それだけは編集します。

CloverとOCでは個別マシン情報の項目名が異なります。Cloverのconfig.plistでSerialNumberとBoardSerialNumberは、OCのconfig.plistでは、それぞれPlatformInfo, Genericの中のSystemSerialNumberとMLBに相当します。Cloverの時と同様にClover Configuratorなどで生成して、シリアル番号が使えるかどうかをAppleのサイトで確認して、その値を記入します。SystemUUIDも、ターミナルのuuidgenコマンドを使って生成して設定します。

また、PlatformInfo, Generic, ROMの値も独自の値を入力します。これは6バイトの数値です。サンプルでは0x112233440000というような値が入っています。世界に存在しない独自の値を入れれば良いようで、通常はEthernetのMACアドレスを使います。これは、システム環境設定、ネットワーク、Ethernet、詳細、ハードウェアと辿ると分かります。例えばこれがc0:7e:bf:c3:af:ffでしたら、

echo -en "\xc0\x7e\xbf\xc3\xaf\xff" | base64
wH6/w6//

とするとbase64値、この場合wH6/w6//が得られます。これをチェックするには、

echo -n wH6/w6// | base64 -d | hexdump 
0000000 c0 7e bf c3 af ff

とすれば確認できます。この値を、PlatformInfo, Generic, ROMのところに

<key>ROM</key>
<data>wH6/w6//</data>

として書き込みます。

USBメモリで起動してmacOS導入

これでOCから問題なくmacOSのインストーラが起動しました。まずは東芝のM.2 SATA SSDをAPFSでフォーマットしてインストールを試みました。するとmacOSのインストール先にAPFSドライブを選択できません。「APFSのボリュームにインストールするためにはMacのfirmwareアップデートが必要だからHFS+を選べ」と言っているようです。MacBookPro13,1はSierraの時代のマシンですので、firmwareがAPFS起動に対応していないです。なのでmacOSインストールの時についでにfirmwareアップデートも行われます。この場面では、firmwareアップデート前の状態と判断されたので、APFSが選べなくなっているのだと思います。

Your Mac needs a firmware update in order to install to this volume. Please select a Mac OS Extended (Journaled) volume instead.

仕方なくHFS+に戻しました。いったんAPFSにすると、DiskUtility.appのGUI画面からはHFS+に戻せなくなってました。ターミナルから

diskutil eraseDisk JHFS+ "Macintosh HD" disk0

などすればHFS+に戻せます（対象がdisk0だった場合の例です）。

これでインストール先として選択できるようになるのですが、インストールを少し進めると、以下のようなエラーメッセージで止まってしまいました。firmwareを検証中にエラーが出るようです。

An error occurred while verifying firmware.

hackintoshなのでfirmwareのバージョン等情報がおかしいのは当然です。Cloverはそれを自動的に偽装してくれます。また、config.plistのBiosReleaseDateやBiosVersionの項目で偽装用の情報を指定することもできます。同じようなfirmwareバージョン偽装設定をOCのconfig.plistでやろうとしたのですが、方法がわかりませんでした。Cloverの項目名では判別できないというエラーが出ました。

Cloverで導入を試みる

この状況に対処するために、M.2 SSDをmacOSマシンに接続してmacOSをインストールすることも可能だったと思います。でも今回は、手元にM.2 SATA SSDをUSB変換するアダプタがなかったので、Cloverで起動することに方針変換しました。kextとSSDTはこのGitHubページのものをそのまま使いました。UEFIドライバは、Cloverでいつも使っている内容です。

VirtualSmc.efi
VBoxHfs.efi
OsxAptioFix3Drv.efi
FSInject.efi
EmuVariableUefi.efi
ApfsDriverLoader.efi

config.plistも、Cloverで使っているシンプルなものを使いました。ただDevicesの場所は、OCのconfig.plistを参考にして以下の設定にしました。

<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
	<dict>
		<key>AAPL,ig-platform-id</key>
		<data>AAAWGQ==</data>
		<key>enable-hdmi20</key>
		<data>AQAAAA==</data>
		<key>framebuffer-fbmem</key>
		<data>AACQAA==</data>
		<key>framebuffer-patch-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-stolenmem</key>
		<data>AAAwAQ==</data>
		<key>framebuffer-unifiedmem</key>
		<data>AAAAgA==</data>
	</dict>

この設定によると、ig-platform-idは0x19160000です。こちらのサイトによると、Intel HD Graphics 510から580搭載laptopのための推奨値のようです。

この結果、Cloverでも無事起動して、しかも今回はfirmware関係のエラーメッセージも出ず、順調にmacOSインストールが可能でした。macOSをM.2 SATA SSDにインストールした後で、そのSSDのESPにも、インストール用USBメモリーと同じ内容をコピーしました。これでSSDからCatalinaが起動します。

動作確認とベンチマーク

このMacについて、を見ると以下のようです。Thunderbolt 3のあるモデル番号なので、無いのに表示されてしまいました。

CPUの名前は、以下のコマンドで確認できます。

sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) i5-6300U CPU @ 2.40GHz

正しく6300Uだと認識されています。Geekbench 5でスコアをとってみました。Haswell, Broadwell, Skylakeあたりはだいたい同じくらいのスコアですね。2コアなのでそれほどスコアが上がりません。

結局OpenCoreに移行する

Cloverでほぼ問題なく動いている様子でしたが、バッテリーの表示が正しく表示されないことに気づきました。GitHubからダウンロードしたそのままのOpenCoreのESP内容に置き換えて起動したところ、今度はバッテリー残量が表示されました。

Cloverでも、おそらくはちゃんと設定すれば、バッテリー残量の表示を可能にできたとは思います。でも、楽ですし、時代はOpenCoreに移行する方向らしいので、結局、最初のようにOCで使うことにしました。firmwareの確認は初めてAPFSを使うときにのみ現れる様子で、macOSアップデートなどでは問題ないようです。

以下に続きます

引き続き、WiFiを整備したり、キーボードを交換したりしたいと計画しています。以下もご覧ください。

ThinkPad T460sのBIOSを更新する

ThinkPad T460s にWiFi/BTカードBCM94360NGを取り付ける

ThinkPad T460sのキーボード交換

まとめ

この機種用の情報を提供してくれたGitHubページのおかげで、完成度の高いmacOSノートPCが完成しました。実のところかなり気に入っています。無線カードなどを調達して、もう少し遊んでみたいと思います。

USB接続のHDMIビデオキャプチャを使う

Sat, 11 Apr 2020 18:59:17 +0900

HDMI端子からUSB 3.0経由でフルHD動画を取り込めるアダプターを使ってみました。USB Video Class (UVC) というUSB標準のデバイスクラスに対応しているので、macOSで（hackintoshでも）OOBで使用できます。

USB 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と同様に、ドライバー不要で使用することができます。

USBビデオキャプチャー

HDMI端子から1080pのフルHD (FHD) 動画を取り込めるUSB Video Class (UVC) 対応ビデオキャプチャー製品が多数出回っています。これを使えばHDMI動画を、webカメラからの映像のように取り込むことができます。macOS標準機能で動画を録画したり、ゲーム配信、動画配信、ビデオ会議でHDMI映像を流すことも可能です。動画を取り込むのは、昔は結構大変でした。MacだとIEEE 1394とか使ってました。

IEEE 1394 (FireWire) を使う

でも今ならUSB が十分速いので、安価なデバイスが使えます。AmazonやAliExpressで、USBビデオキャプチャーとして販売されている製品は、大体がUVC対応なので、macOSで使用可能です。

これなどは1,599円と格安です。ただし、USB 2.0接続で、フルHDで取り込めるのは30fpsまでです。

USB 3.0接続になると値段が高くなります。その代わりフルHDで60fpsの取り込みが可能になります。さらにこれはHDMI出力もついています。

実は、1年以上前に入手したまま未開封だったこちらの製品が手元にありました。USB 3.0接続でフルHD 60fps対応の製品です。今回はこちらを使ってみました。

大きさはクレジットカードくらいの小さなアルミ製の箱です。放熱効果は良いようで、長時間使用してもそれほど熱くなりません。入出力はシンプルで、HDMI入力、USBコネクタ、LEDがあるだけです。USBが特殊で、Type-Aのコネクタがついています。本来ならばType-Bが正しいと思います。なので、両端がType-Aになった、あまり見かけない、USBケーブルが付属しています。これをmacOSマシンに接続します。

UVC規格なので、macOSからは通常のwebカメラのように認識されます。例えばPhotoBoothから見たところ、FHD Webcameraという名前で見えていて、HDMIの動画を取り込んで利用できます。FaceTime, Skype, Zoomなどのアプリケーションからも同様にこの名前で認識されています。

HDMIの音声に関しては、USB Audio Classデバイスとして機能している様子です。webカメラのマイクロフォンのような扱いです。システム環境設定–>サウンド–>入力を見ると、マザーボードの音声入力端子と並んで、FHD Webcameraという名前で見えています。

HDMI動画を撮影する

これがあれば、HDMI端子の映像ならばなんでも取り込めます。例えば、Intel NUCを起動して、BIOS設定画面を開いて再起動して、CloverでmacOSを起動する様子もキャプチャすることができます。以下の動画は、QuickTime Playerの動画取り込み機能を利用して作成した動画です。取り込んだ生データは1080pの画素数ですが、動画編集ソフトで720pに削減してあります。また起動過程の一部をカットしてあります。

BootmacOSfromNUC230a.m4v

まとめ

USB接続のHDMIビデオキャプチャデバイスを試しました。OOBで使用することができました。高性能CPUと大容量HDDを搭載した自作PCを使ったhackintoshは、動画編集や動画配信に最適だと思います。HDMI出力のゲーム機の画面も取り込めるので、ゲーム実況にも使えます。動画配信、テレビ会議などで自作hackintoshの強みを生かせると思います。

Intel NUC DC3217のiGPU画面が乱れる

Wed, 08 Apr 2020 23:20:26 +0900

初代NUC、DC3217の表示が乱れてしまいました。2個あるHDMIのうちの片方が異常で、もう一方は正常です。WhateverGreen.kextで設定フラグを同一にしたら、両方とも正常になりました。

症状

DC3217は最初に販売されたCore i搭載NUCで、Ivy Bridge Core i3-3217Uを搭載しています。GPUはIntel HD Graphics 4000です。こちらの構成です。

Intel NUC DC3217, 3217U

サーバ的に常時稼働させていて、必要な時は画面共有で接続していました。Clover r5108のアップグレードのためにディスプレイに接続したら、画面が乱れていることに気づきました。ログイン画面がこんな表示になります。横方向の画素数が正しく伝わっていない様子です。ロストテクノロジーのアナログテレビで例えると水平同期が取れていない感じかな。

いつからこうなったのか不明です。前回のClover r5107アップデートか、macOS 10.15.4へのアップデートあたりがきっかけかもしれません。また、このディスプレイはメインマシンで使っているのですが、最近起動直後に色がおかしいことがあります。NUCの問題ではなくディスプレイが不調で、設定情報EDIDがうまく送出できなくなっているのかもしれません。

ig-platform-idの決め方

ig-platform-idは0x01620005にしてあります。config.plistのDevices –> Propertiesセクションには、これのBase64値であるBQBiAQ==が設定してあり、WhateverGreen.kext (WEG)にこの値を伝えてあります。

<key>Devices</key>
<dict>
	<key>Properties</key>
	<dict>
		<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
		<dict>
			<key>AAPL,ig-platform-id</key>
			<data>BQBiAQ==</data>
		</dict>
	</dict>
</dict>

どういう理由でig-platform-idを0x01620005にしたのか、もはや記憶がありません。多分、どこかでNUC DC3217の作例を見て、真似たのだと思います。最近、ig-platform-idのことを調べたので、今なら少し説明できるかと思います。

まずは、Intel HD Graphics 4000で使えそうなig-platform-idを探します。こちらのサイトによると、以下のIDが知られているようです。

0x01660000 (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を使うことになります。つまり以下のどれかです。

0x01660000 (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が選択されるのだと思います。

選択肢が4個だけなので、これを全部試してみました。その結果、DC3217では、0x01620005 だけが使えることがわかりました。それ以外の3個では、次のような症状になります：つまり、Cloverの起動ボリューム選択画面の後の林檎マーク表示で、進捗バーが止まります。-vモードで起動すると、文字表示がIOConsoleUsers: …というような表示場所で滞ります。でも、実は表示以外は起動していて、画面共有で接続すると機能しているようでした。

ig-platform-idに0x01620005を設定するには、config.plistのDevices–>Propertiesセクションに以下のように書きます。

<key>Devices</key>
<dict>
	<key>Properties</key>
	<dict>
		<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
		<dict>
			<key>AAPL,ig-platform-id</key>
			<data>BQBiAQ==</data>
		</dict>
	</dict>
</dict>

症状をもっと調べる

0x01620005を設定することで、長らく正しく表示できていたのですが、最初に述べたように、画面が乱れるようになりました。乱れていても、画面共有で接続すると正しく動いているようです。また、起動時にディスプレイを接続せず、起動した後で接続すると正しく表示されます。先に述べたように設定情報EDID関係なのかもしれません。

さらに、もっと興味深いことを発見しました。DC3217には、2個のHDMI端子がついています。以下、左（電源端子に近い方）をHDMI(1)、右（LAN端子に近い方）をHDMI(2)と呼びます。

画面が乱れる現象は、HDMI(2)で発生します。HDMI(1)を使えば、どのタイミングでディスプレイに接続しても、画面は乱れません。実はHaswell世代のNUC D54250でも、片方のHDMIの調子が悪いことがありました。今回も同じような現象のようです。ディスプレイは1台しか使っていませんので、HDMI(1)だけを使うことにすれば、とりあえず解決します。でも、最近はig-platform-id関連の設定に凝っているので、もう少しなんとかしたいと考えました。

HDMI端子のフラグ値を合わせる

Hackintool.appで0x01620005のコネクタ設定画面を見ました。3個のコネクタの設定があります。これがおそらく端子ごとのデフォルト設定なのだと思います。ここでのコネクタへの設定結果は、config.plistを生成する場合にそれぞれ上からcon0, con1, con2というコネクタ名で反映されます。なのでスクリーンショットにそのラベルを書き込んでおきました。

コネクタは3個ともDP端子になっています。実際にはDC3217には2個のHDMI端子があります。DPからHDMIへの変更は、この画面から設定できて、それを記述するconfig.plistのDevices –> Propertiesセクションも自動生成できます。ただ、どこかで読んだのですが、WEG(?)はDPからHDMIの変換を必要に応じてやってくれるらしく、デフォルトに任せておけば良いようです。

なので、DPであることはこのままで良いようなのですが、よく見ると3個のDPでFlagsの項目が違います。con0は0x00000011ですが、con1とcon2は0x00000107です。Flagsは、その下のリストにあるように、いろいろな設定を行うビットの集まりです。意味は不明ですし、さらにもともと機能が不明 (unknown) なフラグも多いようです。ということで、端子ごとに画面が乱れる・乱れないという振る舞いが違うことは、フラグが違うことにより引き起こされていると考えました。つまりHDMI(1)とHDMI(2)のどちらかが0x00000011で、もう一方は0x00000107になっていると考えられます。ちなみに0x00000011と0x00000107の違いは、いずれもunknownフラグが違うだけなので、違いの意味は不明です。

con1を調べる

まずはcon1を0x00000011に設定してみました。Flagsのカラムに数値を入力しても良いですし、下のConnector Flags:でクリックしても良いです。

この後、Patchタブを選び、Generate Patchボタンを押すと、config.plistが現れます。この時、Generalでは、DeviceProperties, Connectors, Graphic Devicesを選びます。またAdvancedとLSPCONは何も選択しません。コネクターの設定が現れ、かつ他の余分な設定が反映されないように調整すれば良いです。

ここで得られたパッチ部分を、config.plistのconfig.plistのDevices –> Propertiesセクションにコピーして、起動を試みました。この結果、何の変化もありませんでした。con1は、使われていないコネクターのようです。

con2を調べる

次に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)からの映像の乱れが治りました。以上の試みから、

HDMI(1)はcon0である
HDMI(2)はcon2である
flagsを0x00000011にすれば画面が乱れない

ということがわかりました。

config.plistを整える

これでHDMI(1)もHDMI(2)もどちらも正常に動くconfig.plistが得られました。でもDevices –> Propertiesセクションの記述が煩雑に思います。コメントみたいな説明の項目は不要に思われます。とりあえずコメント風の設定を外すと以下になります。

<key>Devices</key>
<dict> 
	<key>Properties</key> 
	<dict>
	<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
	<dict>
		<key>AAPL,ig-platform-id</key>
		<data>BQBiAQ==</data>
		<key>framebuffer-con0-busid</key>
		<data>BQAAAA==</data>
		<key>framebuffer-con0-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-con0-flags</key>
		<data>EQAAAA==</data>
		<key>framebuffer-con0-index</key>
		<data>AgAAAA==</data>
		<key>framebuffer-con0-pipe</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con0-type</key>
		<data>AAQAAA==</data>
		<key>framebuffer-con1-busid</key>
		<data>BAAAAA==</data>
		<key>framebuffer-con1-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-con1-flags</key>
		<data>EQAAAA==</data>
		<key>framebuffer-con1-index</key>
		<data>AwAAAA==</data>
		<key>framebuffer-con1-pipe</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con1-type</key>
		<data>AAQAAA==</data>
		<key>framebuffer-con2-busid</key>
		<data>BgAAAA==</data>
		<key>framebuffer-con2-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-con2-flags</key>
		<data>EQAAAA==</data>
		<key>framebuffer-con2-index</key>
		<data>BAAAAA==</data>
		<key>framebuffer-con2-pipe</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con2-type</key>
		<data>AAQAAA==</data>
		<key>framebuffer-con3-busid</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con3-enable</key>
		<data>AQAAAA==</data>
		<key>framebuffer-con3-flags</key>
		<data>QAAAAA==</data>
		<key>framebuffer-con3-index</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con3-pipe</key>
		<data>AAAAAA==</data>
		<key>framebuffer-con3-type</key>
		<data>AQAAAA==</data>
		<key>framebuffer-patch-enable</key>
		<data>AQAAAA==</data>
	</dict>
	</dict>
</dict>

変更したいのはcon2のflagsに関する設定だけで、あとはデフォルトで良いはずです。このconfig.plistは自動生成されたので、デフォルト値もそのまま書き込まれているようです。ということで、con2のflagsと、共通と思われる項目を除いて、以下のような記述にしました。これ以上、設定を削除すると画面乱れが復活します。なので、これがflagsを変更するための必要最小限の記述項目だと思われます。

<key>Devices</key>
<dict>
	<key>Properties</key>
	<dict>
		<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
		<dict>
			<key>AAPL,ig-platform-id</key>
			<data>BQBiAQ==</data>
			<key>framebuffer-con2-enable</key>
			<data>AQAAAA==</data>
			<key>framebuffer-con2-flags</key>
			<data>EQAAAA==</data>
			<key>framebuffer-patch-enable</key>
			<data>AQAAAA==</data>
		</dict>
	</dict>
</dict>

config.plistの全文は以下に置いておきます。いつものように、シリアル番号は実機とコンフリクトしないことを確認してあります。このままで動作するはずですが、実際に使用する場合は、シリアル番号、UUIDを設定し直してください。

config.plist for NUC DC3217IYE - Pastebin.com

まとめ

初代NUCのDC3217の2個のHDMI端子のうち、片方の端子で画面の乱れが発生しました。Hackintool.appで調べてみると、端子ごとにフラグのデフォルト値が異なっていました。画面が乱れる端子のフラグを、正常に表示される端子のフラグと同じになるよう設定することで、画面が乱れなくなりました。

ディスプレイはどうせ1台しか使わないので、画面が乱れるHDMIポートを封印するだけでも良かったです。でも使わないポートでも、動くように設定できると気持ちが良いです。こういう作業が楽しいと感じられないと、hackintoshは面倒くさいだけかもしれないですね。

ig-platform-idの設定方法

Fri, 03 Apr 2020 18:29:57 +0900

CPU内蔵グラフィックス(iGPU)を使うために、機器によってはconfig.plistでig-platform-idを指定する必要があります。idを記述できる場所は2カ所あります。Cloverの機能を使う場合と、WhateverGreen.kextを使う場合で場所が違います。

ig-platform-idについて

ig-platform-idとは何で、どうして指定する必要があるのでしょうか？大変申し訳ありませんが、よく知りません。以下は推測です。勘違いしているようでしたら、コメントで教えてください。

hackintool.appを色々いじっていて、以下のように推測しました。iGPUはCPUダイの中に焼き込まれていますが、おそらくは様々なモードで稼働可能です。例えばノートPCでしたら液晶パネルが接続されますし、デスクトップでしたらDPやHDMIディスプレイが接続されます。フレームバッファの量も設定できるでしょう。他にも、実装されるハードウェアに対応していろいろな設定が可能なはずです。その設定デフォルトのセットをインテル(?)が提供していて、それがig-platform-idなのではと思います。同一のiGPUに対して複数のig-platform-idが存在していて、コンピュータメーカは製品の構成に合わせて、そのうち一つを使っているのでしょう。

Macも同様に、ハードウェア構成に合わせて適切な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用のインタフェースらしいです。

ig-platform-idは、使用しているiGPUの種類と、出力ピンの組み合わせに合うものから探していくことになります。一般的な指針は、こちらで詳しく書かれています。この中のrecommended framebuffersから選択すると良いです。LCDを内蔵しない自作デスクトップPCなどの場合はdesktop用のidを、市販のノートPCにmacOSをインストールする場合はlaptop用のidが適しているようです。

WhateverGreen/FAQ.IntelHD.en.md at master · acidanthera/WhateverGreen

hackintoshのマザーボードやノートPCの構成が、macOSの想定にたまたま合致していれば、問題なく起動するでしょう。でも、異なっているとiGPUが動かず、画面が出ません。Windowsの場合は、ハードウェアにidを問い合わせるなどして、現実に合わせてくれるのかもしれません。Macの場合はApple自身がハードウェアも作っているので、柔軟に対応する必要はない、という状態なのかもしれません。ig-platform-idが間違っている場合、

iGPUに切り替わるタイミングで再起動してしまう。
macOSが起動するけど、グラフィックス加速が効いていなくて、ドックの背景などが半透明にならない。
Cloverで起動ボリューム選択画面の後の林檎マーク表示で、進捗バーが止まる。-vモードで起動すると、文字表示がIOConsoleUsers: …というような表示場所で滞る。でも、表示以外は起動していて、画面共有で接続すると機能している。

などの状態になります。このような場合は、起動しようとしているhackintoshに合ったig-platform-id（システムIDで指定したMacが使うidとは違うid）に指定し直す必要があります。動作するig-platform-idを探し出す作業に困難が伴う場合がありますが、idを差し替える作業自体は、CloverやWhateverGreen.kextが行ってくれます。

Cloverで設定する

Cloverで設定する場合は、config.plistのGraphicsのセクションを使います。例えば、iGPUしか使用しない場合で、ig-platform-idを0x01620005にする場合は、以下のようにします。つまり、Intelをインジェクトするよう設定し、ig-platform-idを16進数で指定します。

<key>Graphics</key>
<dict>
	<key>Inject</key>
	<dict>
		<key>ATI</key>
		<false/>
		<key>Intel</key>
		<true/>
		<key>NVidia</key>
		<false/>
	</dict>
	<key>ig-platform-id</key>
	<string>0x01620005</string>
</dict>

この方法はCloverが行ってくれるので、WhateverGreen.kext (WEG) は不要です。むしろWEGの動作に悪影響を与える可能性もあるらしいので、この設定を使うならWEGは使うべきではないでしょう。WEGはグラフィックスに関する様々なパッチを自動的に当ててくれます。なので、WEGを使わない場合は、iGPUで発生するいろいろなトラブルに対応したkextをいくつか使用する必要があります。ただ、Cloverを使うと、Cloverの起動画面のoptionメニューによりig-platform-idを変更できます。違うidを簡単に試すことができるので、動くidを探す作業では便利だと思いました。

WhateverGreen (WEG) で設定する

同じ設定をWEGで行うには以下のようにします。まずはCloverでの機能を無効にします。このためGraphicsセクションで以下のように書きます。

<key>Graphics</key>
<dict>
	<key>Inject</key>
	<dict>
		<key>ATI</key>
		<false/>
		<key>Intel</key>
		<false/>
		<key>NVidia</key>
		<false/>
	</dict>
</dict>

これでCloverはグラフィックス機能に対して何もしなくなります。あとは全てWEGに任せることになります。WEGにig-platform-idを伝える場合は、Devices –> Propertiesセクションに以下のように書きます。

<key>Devices</key>
<dict>
	<key>Properties</key>
	<dict>
		<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
		<dict>
			<key>AAPL,ig-platform-id</key>
			<data>BQBiAQ==</data>
		</dict>
	</dict>
</dict>

PciRoot(0x0)/Pci(0x2,0x0)は、iGPUが接続されているPCIe番地です。AAPL,ig-platform-idにidをBase64で書きます。0x01620005のBase64値を求めるには、ターミナルで以下のようにタイプします。BQBiAQ==です。

echo -en "\x05\x00\x62\x01" | base64
BQBiAQ==

Devices, Propertiesで書く方法は、Graphicsセクションに書く方法に比べて、ややこしくてわかりにくいですが、WEGを使うならこちらを使うべきです。

まとめ

ig-platform-idは、Cloverでも、WEGでも設定できます。WEGの万能なパッチ機能はもはや手放せないので、config.plistでのig-platform-id設定も、WEGのための設定をすべきです。

今回例示したig-platform-idは、Intel NUC DC3217で使われているidです。最近、このNUCの表示が不安定になったので対処しました。その際に、config.plistを見たら、Cloverを使う古い方法だったので手直ししました。なのでClover方式、WEG方式の両方で動作することを確認してあります。NUCの表示不具合対応の顛末は次の記事で紹介します。

HPの小型デスクトップELITEDESK (3: USB設定)

Thu, 26 Mar 2020 23:16:29 +0900

HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM (Core i3-6100T)のUSBを設定しました。使わないポートを除外して15個以内に収めます。Cloverの起動オプションで除外しても良いですし、SSDTを作っても良いです。

HPの小型デスクトップEliteDesk (1: macOS導入)

前回、このマシンにmacOSをインストールして、オーディオを設定しました。でもmacOSがUSBを15個に制限している関係で、USB 3.1ポートが全てUSB 2.0として稼働する状態でした。この続編では、USBが正しく見えるように設定を行います。USBポートの設定方法は、こちらのZ390、B360チップセットマザーボードの記事もご覧ください。

15個制限を回避するUSBInjectAll.kextの役割と使用法

MSI B360M MORTAR TITANIUMのUSBポートを設定する

USBポートの観察

HP EliteDesk 800 G2 DMには、前面パネルに3個、背面パネルに4個のUSBポートがあります。詳細は、こちらのスペック表でも確認できます。USBは全部3.1 Gen 1だそうです。ちなみにマザーボードのチップセットはQ170です。

前面パネルには、向かって左から右に、

USB 3.1 Type-C 【Type-C】
Type-A SS表示、稲妻表示【前面SS稲妻】
Type-A SS表示【前面SS無印】

の3個のポートがあります。SSの表示はSuper Speedの略で、USB 3.1であることを示しています。後のチェックでわかりやすいようにカギカッコ【】で示した名前をつけました。稲妻マーク付きポートは、USB充電に適しているという意味だと思います。供給電流量が強化されているのか、もしくは電源OFF状態でも5V供給されているのかもしれません。

背面には、同じく左から、

Type-A SS表示が2個【背面SS上】【背面SS下】
Type-A キーボード表示が2個【KBD上】【KBD下】

があります。キーボード表示のポートにはSSの表記が無いのですが、これも3.1です。

前面・背面パネルの他に、マザーボード上の無線接続用M.2コネクタにも、1本USB 2.0が出ているはずです。M.2無線カードがBluetoothの接続に際して、M.2コネクタのUSB端子を使用します。以下ではM.2コネクタに出ているはずのHSポートを【M.2のHS】と呼びます。

HS (High Speed)ポートを調べる

まずはUSBInjectAll.kextだけを入れて、IORegistryExplorer.appを起動します。次に、ウィンドウの右上にある拡大鏡アイコンのついた検索窓にxhcとタイプします。すると以下のようになりました。

USB 2.0であるHSが14本見えています。こんなに多数のポートを使っていませんので、USBInjectAllのデフォルトでこう解釈されているのだと思われます。SSもあるはずなのですが、HSが多すぎて15個制限のためにSSは見えていません。このため、USB 3.1ポートに含まれるUSB 2.0ピンしか機能しなかったのです。

HSは全て見えているので、最初にHSとUSBポートの関係を調べます。そのために、USB機器をポートに接続します。USBポートにデバイスを接続するとIORegistryExplorerのport-statusの数値が変化するので、これで位置関係が分かります。USBメモリーを使うと、抜き差しのほかにアンマウントする必要があるので、キーボードのドングルのようなデバイスの方が楽です。【M.2のHS】を探すためには、マザーボード上のM.2ソケットに無線ユニットを挿します。今回は、余っていたmacOS非サポートのインテルWiFiカードを挿しました。この結果、各項目とUSB 2.0ポートの関係が分かりました。ここで発見できなかった不明なHSは多分未使用です。

HS01 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の起動オプションを以下にしました。

<string>-v uia_exclude=HS02;HS03;HS04;HS05;HS06;HS07;HS08;HS09;HS10;HS11;HS12;HS13;HS14;USR1;USR2</string>

この結果、IORegistryExplorerの様子は以下のようになりました。

SSが10個見えるようになりました。HS01を加えて全部で11個あります。15個制限以下ですので、SSはこれで全てだと思われます。そこで今度は、USB 3.1のUSBメモリーを使って、IORegistryExplorerの反応を調べました。その結果、以下のように割り当てられているようです。

SS01 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は微妙にずれています。実際のパネルに合わせると以下になります。

以上から、未使用のポートを全て除外するためには、起動オプションに以下の設定を行えば良いことになりました。

<string>-v uia_exclude=HS06;HS08;HS10;HS11;HS12;HS14;USR1;USR2;SS07;SS09;SS10</string>

この結果、以下のように必要なポートが見えるようになりました。存在しているポートの数がちょうど15個ですので、macOSの個数制限で諦めなければならないポートはありません。

USBを設定するSSDTを作る

こちらで説明したように、Clover起動オプションを使うよりも、USBを設定するSSDTを作成して、使用すべきポートを指定するやり方がより正しいようです。USBポートの素性を正しく記述できるので、macOSの動きがより正しくなるはずです。詳しくは該当記事を見てください。この作業で必要な情報は、USBコントローラのdevice-idです。HP EliteDeskが使っているQ170の場合、vendor-idが0x8086で、device-idが0xa12fです。0x8086はインテルの番号ですので、インテルのチップセットを表しています。これらの数値はIORegistryExplorerでXHCの項目の中で発見できます。またファインダーで、「アップルメニュー」「このMacについて」「システムレポート」と進み「システム情報」を開き、このUSBの項目にも書いてあります。

そこで、先の記事で紹介したお手本amlファイルから、”8086_a12f”と書かれた”Package”の定義だけを残して、他のPackageの定義を削除します。残すのは以下の項目です。

"8086_a12f", Package()
{

...........

},

この中にはHS01からSS10までのUSBの情報が書かれています。これに対してコネクタの情報を実際に合わせて変更していきます。UsbConnectorの値は、

0: 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の番号が変化する場合。個別に接続されています。

を表しています。上で調べた内容を反映すると、以下のようなファイルになりました。

SSDT-UIAC.dsl for Q170 motherboard in HP EliteDesk 800 G2 DM - Pastebin.com

これをMaciASLで開きます。次に、MaciASLのFileメニューからSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。こうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_excludeを指定しなくても、実存するポートのみが有効になるはずです。IORegistryExplorerで確認すると以下のようになりました。上で、Clover起動オプションで設定した場合と同じ結果です。

HPの小型デスクトップELITEDESK (2: Audio設定)

Tue, 24 Mar 2020 00:10:51 +0900

HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM (Core i3-6100T)のオーディオを設定しました。config.plistでDevices->Audio->Injectを11に設定すれば良いです。搭載された内蔵スピーカーからも音が出ました。

前回、このマシンにmacOSをインストールして、動作確認とベンチマークをしました。実はここで紹介したconfig.plistではオーディオが動いていませんでした。この続編では、オーディオの設定を行います。

HPの小型デスクトップEliteDesk (1: macOS導入)

AppleALCの設定

マザーボード搭載オーディオを動かすための最も一般的な方法は、Lilu.kextと、オーディオ用プラグインであるAppleALC.kextを使う方法です。最初に、

この2個のフォルダをEFI/CLOVER/kexts/Otherに入れ、
config.plistで設定

すれば作業完了です。AppleALC.kextに関してはこちらの記事をご覧ください。

Liluとプラグイン：(2) AppleALCの使い方

これによると、config.plistのDevices->Propertiesでオーディオ設定する方法が推奨されています。でも古いやり方とされている、Devices->Audioで設定する方法の方が簡単です。将来のLiluでサポートされなくなるかもしれない方法らしいのですが、簡単な非推奨な方法を使いました。

前回の作業では、Devices->Audioで以下の設定を行いました。

<key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>ResetHDA</key>
 <true/>
 <key>Inject</key>
 <integer>1</integer>
 </dict>
 </dict>

Audioには二つのkeyを設定しています。最初のkeyはResetHDAで、これを有効にしています。これにより、macOSを再起動した後に、コーデックをニュートラルに戻してくれます。別のOSを起動してmacOSに戻ってきたときに発生する問題を解決します。macOSだけを使う場合には不要かもしれません。ちなみに、(オーディオ)コーデックとはcoder/decoderの略で、圧縮された(音)データを復号して(音の波形)データに戻したり、その逆を行うソフトウェアとか装置とかアルゴリズムのことです。そう言う機能を行うICチップを指すこともあります。ここではICチップのことです。

次のkeyのInjectではレイアウト番号と言う値を指定します。レイアウト番号は、今まで大体1番で動いていたので、とりあえず1番を設定しました。しかしこれでは音が出ませんでした。この他に、2,3,4,5,6あたりまで試してみたのですが、どれも音が出ません。手当たり次第に試しても先が長そうだったので、筐体の蓋を開けて、マザーボード搭載コーデックを特定することにしました。

コーデックはALC221

このマシンの蓋はネジ一つで開くので簡単です。マザーボードの上の2.5インチベイやCPUクーラを外さないとコーデックが見えないかと思ったところ、手前の端のなんとか見える場所にありました。前面パネルには、オーディオ用のミニジャックが2個あるのですが、その近くでした。2.5インチベイの金具がかぶさってますが、斜めから覗き込めました。おなじみの蟹マークのRealtekのチップで、ALC221でした。（追記：こちらのスペック表にもALC221と書いてありました）

それぞれのコーデックで使用すべきレイアウト番号の一覧は、こちらのサイトに掲載されています。これによると11または15を指定すべきようです。両方を試してみましたが、11が正しいようです。15では音が出ませんでした。と言うことで、config.plistのAudioの項目は、以下にします。

<key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>ResetHDA</key>
 <true/>
 <key>Inject</key>
 <integer>11</integer>
 </dict>
 </dict>

ヘッドフォンと内蔵スピーカ

前面パネルには、ヘッドフォンのマークが描かれたミニジャック端子（左側）と、ヘッドフォン＋マイクロフォンのマークが描かれたミニジャック端子（右側）の、合計2個のミニジャックがあります。後者（右側）はどう言う種類なのか不明でした。iPhoneのイヤフォン（イヤフォンとマイクロフォンが一体になっています）を挿してはみたのですが、どちらも使えませんでした。とはいえ、FaceTimeなどではUSB接続のwebカメラかスピーカーフォンを使い、アナログマイクロフォンを使うことはまず無いと思います。なのでこれ以上は調べませんでした。

使用できたのは、ヘッドフォンのマークが描かれた左側のミニジャック端子です。ここにミニプラグを挿し、アンプ付きスピーカに接続したところ、良い音で音楽を聴くことができました。システム環境設定のサウンド->出力の表示にも、名前：ヘッドフォン、種類：ヘッドフォンポートと表示されました。

左のジャックからプラグを抜くと、今度は内蔵スピーカーから音が出ます。3cmくらいの小型のスピーカーなので、電話の受話器のような音質・音量ですが、一所懸命頑張っている感じで可愛いです。サウンドの表示も、内蔵スピーカー、内蔵に自動的に切り替わります。

もう一つの出力項目である、ライン出力、オーディオライン出力ポートは、どこにあるのか所在不明でした。1世代前の、HP EliteDesk 800 G1 DMには、背面パネルにオーディオライン出力ジャックがありました。G2で背面オーディオ出力ジャックが無くなってしまったのが残念なのですが、あの名残がマザーボード上にあるのかもしれません。

一方、サウンド入力画面には、ライン入力、オーディオライン入力ポート、と言う項目が2個表示されています。この2個についても所在不明でした。前述の、前面パネルにあるヘッドフォン＋マイクロフォンの描かれたミニジャックかと思いましたが、ちょっと試した限りでは使えませんでした。

まとめ

HP EliteDesk 800 G2 DMのヘッドフォン端子と内蔵スピーカーから音を出すことができました。

自作PCに、ビープ音を鳴らすスピーカーをつける例は多いですが、コーデック接続のスピーカを内蔵する例はあまり見かけません。タワー型の筐体ならスペースはあるので、内蔵スピーカがあれば省スペースになって良い気がします。実際に、デスクトップMacにはどれもスピーカーが内蔵されてます。なので、メーカ製デスクトップPCで内蔵スピーカから音楽を出せたのが面白かったです。

5250U搭載小型PC XCY X36 (2: OS導入未完編)

Sat, 21 Mar 2020 21:53:47 +0900

AliExpressから届いた格安の5250U搭載小型ベアボーンPC XCY X36にmacOS Catalina 10.15 をインストールしました。macOSは一応すぐに動いたのですがiGPUがいまだに動きません。その経緯を書いておきます。こちらの製品です。

前回はこのベアボーンPCを分解して中身を確認しました。前回からずいぶん間が空いてしまいました。iGPUのドライバーが動かなくて難航してます。もう少し頑張ろうと思ったのですが、6100T搭載メーカー製中古デスクトップの方が性能、価格、サイズ、メンテナンス性で勝っているのでこちらはお蔵入りにします。ということでドライバーが動かず、描画加速が効かない状態ですが、この先進捗しなさそうですので、現状報告しておきます。

5250U搭載小型PC XCY X36 (1: 分解編)

メモリーと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に紛らわしいブランドでお手頃な製品がありました。

BIOSを設定する

メモリーとSSDを取り付ければPCとして機能します。さらにACアダプター、キーボード、トラックパッド、HDMIケーブル（の先にディスプレイ）を取り付けました。電源を入れたら、American Megatrendsのロゴが表示され、その後、めでたくBIOS画面が表示されました。お馴染みのAptioブランドのBIOSです。最近の大手マザーボード製品と違って、昔ながらのシンプルな表示です。CPUは鉛筆書きの番号通り、i5-5250Uだったようです。良かったです。

とりあえずはF9を押して、設定を工場出荷状態に戻します。次に、BIOS設定をします。BIOS設定に関しては、こちらの記事もご覧ください。

マザーボード (BIOS) 設定

BIOSメニューを順番に見て、変更すべきところを探します。まずはIntel Anti-Theft Technologyという機能の設定があり、Enabledになっていました。検索すると、ネットに接続しない状態が指定日数経過すると盗難モードに入り、マザーボードをロックする機能です。しかしすでにサービス終了しているようです。このクラスのマザーボードに、BIOSからネット接続する機能は無いと思われますので、Windowsアプリと一緒に動く機能かと思います。ロックする部分をBIOSが担当しているだけでしょう。なのでmacOSで使う限りは無害と思います。でもトラブルの予感しかしませんのでDisabledにしておきました。

次に搭載シリアルポートの設定がありました。前回の分解で分かったように、マザーボードにはシリアルポート用のヘッダピンが2セットあります。BIOSメニューにもSerial Port 1と2の設定があり、この2セットに対応しているようです。BIOSではそれぞれをon/offできます。シリアルポートはmacOSではサポートされていませんし、これが有効になっていると起動に失敗した経験もあります。そうでなくても電気の無駄なので、両方ともDisabledにしておきます。

iGPU関連の設定に、DVMT Pre-Allocatedという項目があります。初期設定は32MBなのですが、macOSでは64MB以上にしないと動かないとのことです。少し余裕を持たせて96MBにしておきました。実際に32MBの設定で試したところ、Cloverの起動画面が出た後、グラフィックスが切り替わるタイミングで再起動してしまいます。ちなみにBIOSでこの設定が可能なのは幸運らしいです。ノートPCのBIOSなどではこれが設定できないこともあるそうです。多分、変な設定をして動かなくなるとサポートが面倒なので、設定項目から除外してあるのかと思います。この製品はAptioのオリジナルのままのBIOSを使っているので、この設定も可能なのだと思います。

初期設定ではVT-dがEnabledでした。他の設定でリカバーできるらしいですが、ここはHackintoshの定石なので、Disabledに設定しました。

これは単に不便なだけですが、デフォルトではキーボードがNum Lock状態になります。以前紹介したテンキー無しのトラックパッド付き無線キーボードを使うと、右の文字キーがテンキーになってしまい不便です。macOSが起動してしまえば関係ないですが、UEFI Shellでの操作やCloverでの設定作業に支障が出ます。そこでBootup NumLock StateをOffにしました。

まとめると、初期設定から変更した点は以下の5箇所です。

Intel Anti-Theft TechnologyをDisabledにする
2個のシリアルポートをDisabledにする
DVMT Pre-Allocatedを96MBにする
VT-dをDisabledにする
Bootup NumLock StateをOffにする

インストール用USBメモリーを作る

次に、このX36で

macOSユーティリティを起動して
mSATA SSDをフォーマットして
macOSをインストールする

ことが可能なUSBメモリーを作成します。大まかな手順はこちらをご覧ください。

Catalina導入用USBメモリーを作成する

手順をまとめると、

USBメモリーをフォーマットする
createinstallmediaコマンドを使ってMacで起動するmacOSインストーラ作成する
CloverインストーラでブートローダとUEFIドライバを入れる
必要なkextを入れる
config.plistを作成する

このUSBメモリーを作成する手順で一番難しいところは、USBメモリーのESP部分を作成する部分のステップ3, 4, 5です。特にconfig.plist作りが難しいです。でもこれさえできれば、Hackintoshはほとんど完成したも同然です。まずはCloverインストーラでブートローダーとUEFIドライバを入れます。今回のビルドで使用したUEFIドライバは、以下です。VirtualSMCを使ったので、VirtualSmc.efiを手作業で入れています。

ApfsDriverLoader.efi
EmuVariableUefi.efi
FSInject.efi
OsxAptioFix3Drv.efi
VBoxHfs.efi
VirtualSmc.efi

また使用したkextは以下です。

AppleALC.kext Lilu.kext
RealtekRTL8111.kext
USBInjectAll.kext
VirtualSMC.kext
WhateverGreen.kext

USBInjectAll.kextは不要だったかもしれません。LANチップがRealtekだったのでそれ用のkextを入れました。この後、難関のconfig.plist作りをします。

暫定Config.plistを作る

こちらでHaswell用のconfig.plistの作り方の解説を載せておきました。

corpnewtさんのバニラガイド~Haswell用config.plist

今回はBroadwellなのですが、数が出ていないCPUなのかCorpnewtさんのガイドにはありません。でもHaswellに近いCPUなので、ほとんどHaswell用のconfig.plistで動作すると思いました。

機種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はこのサンプルをまねずに必ず独自の値を設定してください。重複した値を使うとアップルから拒否される可能性があります。

 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>C027456004NGH34JC</string>
 <key>Mobile</key>
 <false/>
 <key>ProductName</key>
 <string>iMac16,1</string>
 <key>SerialNumber</key>
 <string>C02VNYZ7GF1J</string>
 <key>SmUUID</key>
 <string>483F7DE7-6698-4EAC-B7A3-6B39FC4264F6</string>
 </dict>

サウンドの設定

音を出すためにDevices->Audioのインジェクトするレイアウト番号を1にしました。

<key>Audio</key>
 <dict>
 <key>Inject</key>
 <string>1</string>
 </dict>

こちらのページ

Supported codecs · acidanthera/AppleALC Wiki

によるとRealtek ALC892の場合は、1, 2, 3, 4, 5, 7, 12, 15, 16, 17, 18, 28, 31, 90, 92, 97, 99などの選択肢があるようですが、大体1で良いようです。

iGPUの設定

WhateverGreen.kextを使う場合、iGPUの情報はDevices->Propertiesに書きます。

 <key>Devices</key>
 <dict>
 <key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>AwAiDQ==</data>
 </dict>
 </dict>
 </dict>

としてig-platform-idを指定しています。場合によってはconfig.plistに何も設定しなくても、WhateverGreen.kextがとりあえず動作する値を割り当ててくれることが多いです。しかし、今回の構成ではconfig.plistでの設定が必須だったようで、最低でもig-platform-idの設定がされていないとmacOSの起動が途中で止まってしまいました。ig-platform-idに何を設定すべきかは、正解があるわけでなく、試行錯誤で探る場合もあるようです。以下の情報

Intel Framebuffer patching using WhateverGreen

によると、Broadwellの場合のdevice-idとig-platform-idは

Gen 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変換します。すると、

% echo -en "\x06\x00\x26\x16" | base64
BgAmFg==

になります。この値を採用する場合、Propertiesの項目は、以下となります。

<key>Properties</key>
　　　　<dict>
　　　　　　　　<key>PciRoot(0x0)/Pci(0x2,0x0)</key>
　　　　　　　　<dict>
　　　　　　　　　　　　<key>AAPL,ig-platform-id</key>
　　　　　　　　　　　　<data>BgAmFg==</data>
 </dict>
 </dict>

ということで、ig-platform-idに0x16260006を採用した場合のconfig.plistは以下のようになりました。

config.plist for X36 with 5250U - Pastebin.com

iGPUドライバを諦める

実は、ig-platform-idを1番正しい値だと思われる0x16260006にした場合、画面が正しく出ません。-vオプションではずっと文字画面のままです。時々OSが順調に動いているらしいメッセージが出ます。実際、macOSをなんとかインストールして、LANを有効にした状態でリモートデスクトップ接続すると、macOSは正しく動作していることが確認できました。ディスプレイドライバの問題です。

調べてみたところ、iGPUを使おうとする場合のよくあるトラブルのようです。iGPUのドライバが機能しようとしているものの、他の設定が不十分で正しく表示されていない様子です。もう少し頑張ればなんとかなる状態です。一方で、ig-platform-idを全く間違った値に設定すると、ドライバー自体が起動に失敗します。その場合は標準的なデフォルトのディスプレイとして認識されるので、画面表示が出ます。ただし、グラフィックス加速が効いていないので、動作が遅く不安定で、macOS画面の半透明などの視覚効果が効きません。今回の例ですと、Hackintoolに登録されていない1番違いの0x16260007、つまりbase64ではBwAmFg==を使うと、この状態になり、一応の表示が行えます。以下はこの状態で進めました。

macOSをインストールする

このUSBメモリをX36に挿して起動します。

無事起動して、macOSユーティリティが動きました。

USBメモリーで起動したmacOSユーティリティから、mSATA SSDをフォーマットします。ここでは伝統に従ってMacintosh HDという名前をつけました。これにmacOSをインストールします。

インストール途中で再起動しますが、その時は、Boot macOS Install from xxxxという項目を選択します。

インストールが終了すれば、USBメモリ、mSATA SSDのリカバリーパーティション、そしてインストールしたmacOSの本体の選択肢が現れます。

これでUSBメモリーから起動して、本体のmSATA SSDから起動するようになりました。USBメモリーのESP部分をmSATA SSDにコピーすれば、mSATA SSDから起動するようになります。

macOSを使ってみる

前述のようにグラフィックス加速は効いていませんが一応の操作は可能です。グラフィックスはIntel HD Graphics 6000と認識されていますが、グラフィックスメモリが31MBしか無いことになってます。

サウンドは動いています。X36のオーディオ出力ジャックは、内蔵スピーカーに対応しているようです。光デジタル出力ポートも動いているようですが、対応機器を持っていないので確認できませんでした。

GeekBench 4を動かしてみたところ、マルチコアのスコアは5500くらいでした。

Geekbench Browserで他の人のベンチスコアを検索したところ、5250U搭載iMac (21.5-inch Late 2015)のGeekbench 4スコアはこの程度の値で、妥当な結果です。

まとめ

とりあえずは動作しましたが、iGPUのグラフィックスドライバが動いていないので、未完成です。Hackintool.appによると、ig-platform-idを変更するだけでなく、device-idを設定したり、コネクタがデフォルトでDPであるのを実装に合わせてHDMIに変更したり、フレームバッファの各種フラグを変更するなど、いろいろな選択肢があるようです。手当たり次第試してはみたのですが、正解は見つけられていません。組み合わせが多すぎて全部は網羅できていないためかもしれないです。もしくは、iGPU周りの設計がMacとは違う構成になっていて、動作困難な機種だったのかもしれません。冒頭に書きましたように、メーカー品の中古デスクトップが優秀だったので、こちらは当面お蔵入りにすることにしました。

HPの小型デスクトップEliteDesk (1: macOS導入)

Fri, 20 Mar 2020 21:37:26 +0900

HP社の小型デスクトップPC、HP EliteDesk 800 G2 DM (Core i3-6100T)にmacOSをインストールしました。まずはiGPUとLANが動きました。第5~6世代のメーカー製中古デスクトップPCは1万円前後で入手できます。この値段ですぐに動くmacOSマシンが手に入るのでお得です。

追記：その後、スリープ復帰後にiGPUの信号が出ないブラックスクリーン状態が発生していることに気づきました。最近のmacOSで発生しているようで解決策は無いようです。スリープさせない設定にしても長時間放置するとブラックスクリーンになることもありました。画面共有では問題ないので、ディスプレイ無しのサーバーなら問題ないかもしれません。Intel HD Graphics 530とmacOSの相性の問題のようです。

HPの小型デスクトップEliteDesk (4: 暗黒画面問題で頓挫)

メーカー製小型PC

メーカー製PCと自作PCはそれぞれ長所短所がありますが、macOSを入れるという観点から見ると、予め相性の良いパーツを選択できて、必要ならば交換も容易な自作PCの方が有利です。でもメーカー製品でも、デスクトップPCならパーツ交換や改造が容易なので、ノートPCよりは柔軟に対応可能です。そこで初めての試みとして、メーカー製デスクトップにmacOSを入れてみます。

今回選んだ製品カテゴリーは各社でtiny, micro, desk miniなどと呼ばれる一番小さなデスクトップです。Lenovo, Dell, HP各社から発売されています。これ以外のメーカーからも発売されていますが、ネット上の情報が多いのでこれらの大手3社が良いと考えました。中古で手頃に入手可能な第5世代CPUモデルには

Lenovo 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をインストールする方法の解説ビデオです。

https://www.youtube.com/watch?v=M1pnWKNaqUs

https://www.youtube.com/watch?v=BJqhvzjx-yo

https://www.youtube.com/watch?v=6hZo2dZH_V0

これらの製品はどちらかというと法人向けのようです。時々秋葉原に大量に放出されます。ほぼ同じ仕様でポートの種類が違うなどのバリエーションも多いです。またHPにはEliteDeskの他にProDeskというブランドもあって紛らわしいです。ProDeskはより法人向けのようで、サポートセンタの対応が無いとか、チップセットが格下だったりする違いがあります。

これらの製品群は、一般のデスクトップPCと同じLGAソケットのCPUが搭載されています。CPUを交換できるのでアップグレードも可能です。Intel NUCがノートPC向けBGAパッケージ（半田付け）のCPUを使っているのと対照的です。上記でリストしたCore iモデル機種には、どれもCore i3-4160T, i5-4570T, i5-4590Tなどの省電力のTモデルCPUが搭載されています。Tモデルは無印モデルよりクロックが多少低いですがそれ以外の仕様は無印と同じです。ソケットなので上位グレードのTモデルCPUに交換可能です。

HP 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万円を少し超えるくらいです。

コンピュータの前面には、ヘッドフォン、マイクロフォン、USB Type-C, USB 3.1 Gen1, 電源スイッチがついています。HPの丸いマークの左側のスリットが長くなった部分にスピーカーが入っています。また前面パネル内側のスピーカー下部には（写真では見えていませんが）無線LANのアンテナ取り付け場所があります。無線LANはオプションなので、今回入手したマシンにはついていません。

コンピュータ背面には、左からDP, VGA, DP, USB 3.1 Gen1, LAN, 電源端子があります。真ん中のDPの部分は、モジュール式になっていて、シリアルポート、DVI-D、HDMIになっているモデルもあります。VGA端子はmacOSでは動かないようです。今回は左端のDPを使いました。背面左端の四角い穴が3個見える部分も無線LANのアンテナを取り付ける部分です。これも装着されていません。背面側の中央上には上蓋を固定しているネジがあります。

この一個だけのネジを手で回して外せば、上蓋が取り外せます。Mac miniに比べたらとても簡単です。

上蓋を開けると、内部には、左側に2.5インチドライブベイ（HDDは外しました）、右側にCPUとクーラーがあります。CPUクーラー部分は、ヒートシンクとファンで構成されています。ファンは簡単に持ち上げることができて（写真では爪楊枝で支えています）、その下にあるメモリーソケットにアクセスできます。このマシンは2.5インチドライブを前提としたフォームファクターだと言えます。2.5インチHDD/SSDのコストパフォーマンスが高かった時代には合理的な構造です。最近のように、M.2 SSDが十分に安価になり、2.5インチドライブが不要になってくると、もっとコンパクトな形状が好まれるかもしれないです。

2.5インチベイはT15のトルクスドライバで外せます。その下にM.2 SSD用と、M.2 無線モジュール用のソケットがあります。上に2.5インチベイの金具があるので、放熱板は取り付け困難です。熱伝導シートを使って、2.5インチベイ金具に接触させるのが良いかもしれないです。

Catalinaで動かす

とりあえずmacOSが動くことを確認します。不具合はあるかもしれないですが、今回は、iGPUドライバが動くこと、LAN接続ができることを確認しました。

BIOS設定

まずはBIOS設定画面で設定をデフォルト状態に戻しました。デフォルトではiGPUへの割り当てメモリが32MBになっています。この場合、iGPUが動き始めるとすぐに再起動に戻ってしまいました。そこで128MBくらいに設定しました。それ以外の設定はデフォルトのままで以下を進めました。今後、もう少し最適化すべきかもしれないです。

Catalina SSDを作る

2.5インチSATA SSDを用意しました。いつも試験に使っている32GBの小さなSSDです。これを、既に動いているmacOSマシンに接続し、GUIDスキーム＋Mac OS拡張（ジャーナリング）でフォーマットしました。ただ、この後のインストール作業でAPFSに変換されました。

このSSDにCatalinaをインストールしました。手元にあったインストーラが10.15でしたので初期バージョンです。このSSDでmacOSマシンが起動することを確認しました。

Cloverとkextをインストール

次にESPの部分を作成します。このSSDのESPを

diskutil list

コマンドで探して、それを（disk1s1だった場合）

sudo diskutil mount disk1s1

としてマウントします。ここに現用のZ390マザーボード用のESPの中身をコピーしました。この際、Z390用のSSDT, kext, config.plist項目は、当然ながら不要ですので削除しました。ということでconfig.plistも最小限のシンプルなものになりました。config.plistは以下になりました。いつものようにシリアル番号とUUIDは有効な値を設定してありますが、アップルのサービスに接続する前に自分用のシリアルとIDを、Clover Configuratorなどを使用して生成して、config.plistを書き換えてください。

Config.plist for HP EliteDesk 800 G2 DM - Pastebin.com

機種は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を設定して動きましたが、削っても動きました。

HPマシンでCatalinaを起動

こうして用意したSSDをHP EliteDesk 800 G2 DMに取り付け、起動します。先に述べたように、BIOSでiGPUへのメモリ割り当てが少なかったこと、VGAコネクタからは映像が出なかったことを試行錯誤した程度で、すんなりと起動しました。ここまで簡単だとは予想していませんでした。

Dockに被っている部分は半透明になっています。iGPUのドライバーがちゃんと動いてiGPUによるグラフィックス加速が行われていることを示してます。LANも、kextに入れたIntelMausi.kextで問題なく動きました。LANのチップは、上で紹介したスペック表によるとIntel I219LMだそうで、これはIntelMausi.kextの対応表に掲載されています。

今後の予定

とりあえずは動きましたが、まだチューニングの余地があります。長時間使用するとiGPU特有のノイズに気付くかもしれません。サウンドは動くかどうか確認していません。USBは15個制限のために2.0側だけが動いているようです。なのでせっかくのType-Cも動作していません。WiFi/Bluetoothカードは取り付けたいと思います。

ベンチマーク

Geekbench 5でベンチマークしました。シングルコアスコアが801でマルチコアが1838でした。

ちなみに今回のお手本にした無印6100を搭載したiMac17,1のベンチマークスコアはそれぞれ900/2100くらいです。6100Tは無印6100の省電力モデルのため、クロック数が14％低いです。クロック数の差に見合った妥当な結果となりました。（追記：勘違いしていました。6100を搭載したiMac17,1なんて存在しないですね。なのでこのGeekbench結果は全部hackintoshのスコアだと思います。6500を搭載したiMac17,1のシングルコアスコアも900くらいなので、やはり妥当なスコアです。）

まとめ

HPの小型デスクトップPCにmacOSをインストールし、とりあえず動作確認しました。特に難しいところはなく、あっさりと動いてしまいました。ベンチマークスコアもそこそこ出て、実用的に使用できそうです。同じくらいのサイズのMac miniと比較すると、筐体を開けるのは簡単ですし、メモリー、CPU, SSDなどのアップグレードも容易です。Mac miniは確かにおしゃれでかっこいいですが、HPの無骨な感じの外観も悪くないと思います。

今回のマシンはお遊び用なので、邪魔にならない小型デスクトップにしました。でもメインで使用されるのでしたら、DVDドライブが付いているモデルやPCIeスロットが付いているモデルにするのが良いと思います。グラフィックスカードがあれば快適ですし（iGPUでも気にならないですが）、iGPUよりmacOSとの互換性が高いので安心です。さらには、嵩張るマシンは人気が無いようで、より大きなサイズの中古製品の方が、より安価に入手できます。

今後は電力制御、iGPUの動作、サウンド、USB設定、WiFi/Bluetooth、メモリー、SSDなどを確認・追加していきます。

以下の記事に続きます。

HPの小型デスクトップEliteDesk (1: macOS導入)

HPの小型デスクトップELITEDESK (2: Audio設定)

HPの小型デスクトップELITEDESK (3: USB設定)

HPの小型デスクトップEliteDesk (4: 暗黒画面問題で頓挫)

300シリーズマザーボードでも本物のNVRAMを使いたい

Wed, 22 Jan 2020 23:43:17 +0900

現行の300シリーズチップセットマザーボードでは、macOSがNVRAMにアクセスできない問題があります。NVRAMが使えないと設定が保存されないだけでなく、シャットダウンやスリープの動作にも支障が出ます。そのためにEmuVariableUefi.efiを使って、NVRAMをソフトウェアエミュレーションする必要がありました。NVRAM問題を、エミュレーションを使わずに、根本的に解決するSSDTがRedditで紹介されていました。

このSSDT-PMC.amlをEFI/CLOVER/ACPI/patchedに入れてみました。その結果、ASUS ROG MAXIMUS XI HERO (Z390)マザーボードのNVRAMが使えるようになりました。MSI B360M Mortar Titaniumでも試しましたが、同じ方法でNVRAMが使えるようになりました。

EmuVariableUefi.efiのエミュレーションは優秀で、ちゃんと動作して何の問題もありませんでした。でも、本来のNVRAMが使えると気分が良いです。たとえば、SSDT-PMC.amlを使った結果、以下のnvramコマンド

% sudo nvram hoge=test

で試験的に設定したパラメータが、システム終了・再起動後に確認すると、

% nvram -p | grep hoge
hoge	test

のように、電源を切っても保存されていた様子が確認できました。EmuVariableUefi.efiを使って動かしていた時には、保存されませんでした。これができなくてもmacOSの動作には関係ない様子ですが、何らかの機能で互換性が上がったかもしれないです。

追記：コメントで教えてもらいましたが、NVRAMが動くようになると、config.plistのBootのセクションで起動ドライブを設定するときの、LastBootedVolumeの設定が動くようになります。

以下はReddit投稿の抄訳です。

r/hackintosh - NVRAM for all! 300 series users rejoice!

OpenCoreパッケージの最新更新では、SSDT-PMC.dslという新しいSSDTが追加されました。このSSDTは、B360、B365、H310、H370、Z390用のNVRAMを復活させてくれます。

そもそもなぜ、300シリーズマザーボードのNVRAMは壊れているのでしょうか？とても簡単です。ACPIの中で、MMIOとしてファームウェアチップを宣言することを、**Intelが「忘れた」**のです。そのため、XNUはUEFIメモリマップで宣言されたMMIO領域を無視します。そしてマップされていないページアクセスによってNVRAM SMMページフォルトが発生してしまうのです。

このSSDTの使い方

使い方は簡単で、設定不要で入れるだけです。OpenCoreに縛られていないため、Cloverユーザーも使うことができます。このDSDTにはLPCBが必要ですが、Z390ではこれが非常に一般的であることに注意してください。PCI0.LPCBを検索すれば確認できます。（訳注：この意味がよく理解できないのですが、おそらくDSDTのDevice (PCI0)の項目の中に、Device (LPCB)の定義がされていることが必要という意味だと思います。MaciASLを起動するとデフォルトのDSDTが開くので確認できます。）

（訳注：このあと、macOS, Windows, Linuxでdslのコンパイル方法が説明されています。MaciASLの使い方についてはこちらをご覧ください。）

ファイルがコンパイルされると、SSDT-PMC.amlが得られます。コンパイルされたバージョンであるため、拡張子は重要です。dslは単なるソースコードです。SSDTを作成したら、これをEFI/CLOVER/ACPI/patchedまたはEFI/OC/ACPI (OpenCoreを実行している場合は、忘れずに設定に追加してください。) に入れます。コンパイルが面倒と思う人のために、ここにコンパイル済みのSSDT-PMC.amlを配布しておきます。

NVRAMエミュレーションを削除する方法

以下を削除します。CloverでRCスクリプトをインストールしている場合は色々削除します。（訳注：デフォルトではRCスクリプトをインストールしない設定なので、EmuVariableUefiの削除だけで良いと思います）SIPをオフにしてR/Wでマウントする必要があるかもしれません。

/Volumes/EFI/EFI/CLOVER/drivers/UEFI/EmuVariableUefi-64.efi
/Volumes/EFI/nvram.plist
/etc/rc.clover.lib
/etc/rc.boot.d/10.save_and_rotate_boot_log.local
/etc/rc.boot.d/20.mount_ESP.local
/etc/rc.boot.d/70.disable_sleep_proxy_client.local.disabled
/etc/rc.shutdown.d/80.save_nvram_plist.local

OpenCoreユーザーの場合は、設定で次の項目を無効にするだけです。

Booter->DisableVariableWrite->False
NVRAM->LegacyEnable->False

そしてEFIのルートにあるnvram.plistを削除するのを忘れないでください。

NVRAMの動作をテストする方法

ターミナルを開き、一度に1行ずつペーストします。（訳注：sudo nvram -cは実行しなくても良いと思いました。適当なエントリーに値を設定するだけなら、SIPを無効にする必要はありませんでした。）

sudo -s
sudo nvram -c 
sudo nvram myvar=test
exit

再起動して次のコマンドを実行します。

nvram -p | grep -i myvar

何も返されない場合は、NVRAMが動作していません。myvar testを含む行が返された場合、NVRAMは動作しています。

Note: nvram-cを使用するにはSIPがオフになっている必要があります。もしくはブートメニューでNVRAMを消去します。Cloverの場合は、F11キーを押します。OpenCoreの場合は、 CleanNvramを選択します。Misc->Security->AllowNvramReset->YESに設定する必要もあります。

MSI B360M MORTAR TITANIUMのUSBポートを設定する

Thu, 09 Jan 2020 23:20:04 +0900

長らくほったらかしになっていた銀色のマザーボード、MSI B360M Mortar TitaniumのUSBポートをちゃんと設定しました。USBポートの設定方法は、こちらのZ390チップセットマザーボードの記事もご覧ください。

15個制限を回避するUSBInjectAll.kextの役割と使用法

今回ご紹介するB360は、廉価版チップセットなのでUSBのポート数が少ないです。Z390が使用できるUSBポートは以下です。

USB2.0が14本
USB3.1が10本（そのうち6本までをGen 2にできる）

これに対して、B360は廉価版ですので、

USB2.0が12本
USB3.1が6本（そのうち4本までをGen 2にできる）

です。なのでmacOSの制限で15ポートになっても、諦めなければならないポート数は少ないです。

USBInjectAll.kextを入れる

まずはUSBInjectAll.kextだけを入れて、IORegistryExplorerでxhcを検索します。ウィンドウの右上にある拡大鏡アイコンのついた検索窓にxhcとタイプします。すると、

USB 2.0であるHSが14本見えています。B360は12本なのですが、USBInjectAllにB360の情報がなくて、Z390だと思われているのかもしれません。ここで、マザーボードにUSB機器を接続して、それぞれのポートの位置を調べます。USBメモリーを使うと、抜き差しのほかにアンマウントする必要があるので、キーボードのドングルのようなデバイスの方が楽です。またマザーボード上のピンをチェックするために、USB Type A変換器を用意しておくと便利です。こういう小物パーツはAliで買うと格安ですね。

この結果、USB 2.0の関係がだいたい分かりました。

HS01 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) は、元々存在していなかった可能性もあります。

使用しない2.0を無効にする

いずれにしてもこの4本は使用しないので、USBInjectAll.kextで無効にして良いと思われます。また、USB 3.1の様子を知りたいので、HS09とHS10も一時的に無効にしてみます。元から不要なUSR1, USR2も無効にします。そこで、Cloverの起動オプションを以下にしました。（slideはこちらの記事で設定したオプションです）

<string>-v slide=128 uia_exclude=HS09;HS10;HS11;HS12;HS13;HS14;USR1;USR2</string>

この結果、IORegistryExplorerの様子は以下のようになりました。

SSが6個見えるようになりました。総数が14個ですので、これで全部のSSが見えているはずです。今度は、USB 3.1のUSBメモリーを使って、IORegistryExplorerの反応を調べました。その結果、以下のように割り当てられているようです。

SS01 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のオプションで

<string>-v slide=128 uia_exclude=HS11;HS12;HS13;HS14;USR1;USR2;SS03;SS04</string>

という設定を行えば良いかと思います。

USBを設定するSSDTを作る

こちらで説明したように、USBを設定するSSDTを作成して、使用すべきポートを指定するやり方がより正しいようです。USBポートの素性を正しく記述できるので、macOSの動きがより正しくなるはずです。詳しい手順は過去の記事を見てください。流れを説明すると、まずは適当な名前でdslという拡張子のテキストファイルを作ります（例えばSSDT-UIAC.dsl）。以下のようなファイルです。ここでは、HS11からHS14、SS03, SS04, SS07以上、USR1, USR2を削除しています。

SSDT-UIAC.dsl for MSI B360M MORTAR TITANIUM - Pastebin.com

これをMaciASLで開きます。次に、MaciASLのFileメニューからSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。こうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_exclude=を指定しなくても、指定したポートのみが有効になるはずです。IORegistryExplorerで確認すると以下のようになりました。

300チップセットマザーボードのRTC設定

Sat, 28 Dec 2019 15:06:42 +0900

Intel 300チップセットを搭載した現行のマザーボードからRTCの扱いが変わりつつあるようです。これが原因でmacOSの起動に失敗する事があります。DSDTへのパッチをconfig.plistに加える、もしくはBIOSで設定する事により回避できます。

BIOSをアップデートして失敗したというこちらの記事

ASUSのBIOSを1105以上に更新すると起動しない

で紹介した内容ですが、いまやHackintoshを作る上での一般的な注意事項になったと思います。なので、GUIDESカテゴリーに見合った内容に書き直して再掲します。

Real Time Clock (RTC)

コンピュータは、ファイルのタイムスタンプ管理やネットワーク同期など、いろいろな場面で正確な日付と現在時刻を必要とします。そこで、コンピュータの電源がoffになっても、日付と現在時刻を更新し続ける水晶時計機能が用意されました。これがRTC（Real Time Clock, 実時間時計）です。RTCは小さな部品としてマザーボードの片隅に載っていました。今ではチップセットに組み込まれています。RTCは、マザーボードの電源が切られた場合でも、マザーボード上のコインバッテリーで動き続けます。ちなみに太古のコンピュータにはRTCはありませんでした。なので、コンピュータ室を占拠する大型計算機も、AppleやNECの初期のパソコンも、電源を入れて最初に行う仕事の一つが、今日の日付と現在時刻の入力作業でした。

RTCは現時刻を知る時計として使われるだけでなく、プログラム実行のきっかけを提供する目覚まし時計としても使われます。RTCにはコンピュータ作業に割り込みをする機能があり、割り込みで起動するタスクやスレッドを設定可能です。なので、毎日決まった時間に行う仕事、一定時間で繰り返す仕事などを設定しておけます。さらには、仕事の時間切れ管理にも使われます。例えば、特定のハードウェアがコンピュータに装備されているかどうかを確認する作業を考えてみます。そのハードウェアに、あなたは存在しますか？と問いかけるのですが、返事をじっと待っていては時間の無駄です。装備されていないために、永遠に返事が来ない可能性も高いです。そこで確認呼びかけと同時に、RTCに例えば10秒後にアラームしてくれるようにお願いします。そうすれば、返事を待つ間に別の仕事を実行したり、待っている間は休眠して他のスレッドにCPU資源を譲ることもできます。このように、外部デバイスにアクセスしつつ、アラームを仕掛けて返事を確認する作業は、macOSの起動時にもいくつも行われているようです。このような過程で、もしRTCのアラーム機能が動かなければ、macOSの起動が止まってしまう可能性があります。

RTCの世代交代

300シリーズチップセットになってRTCの世代交代が進んでいるようです。BIOSメニューの表現を借りると、従来型のRTCからACPI (Advanced Configuration and Power Interface)のTime and Alarmデバイス（長いので以下、ACPI時計と書きます）に移行しているようです。そしてACPI時計を使う事がデフォルト設定になりつつあるようです。

ACPI時計ではOSが起動しない

ところが、ACPI時計を使うとmacOSの起動が止まってしまうようです。最初に紹介した過去の記事では、ASUSのZ390マザーボードのBIOSを1105に更新したところ、ACPI時計がデフォルトで使われるようになってしまって、macOSが起動しなくなったことを書きました。-vで起動すると起動途中で文字表示が止まってそのまま動かなくなります。apfs.efiなのかVirtualSMCのあたりのメッセージで止まります。そのあたりの処理（apfsなら起動ドライブへのアクセスかもしれません）でRTCの割り込みが効かなくなり、処理が止まってしまったような様子です。RTCがACPI時計に置き換わって、使えなくなったのが原因だと思います。Cloverの問題なのか、macOSそのものがRTCに依存しているのかわかりませんが、この問題に対策を施さないとmacOSが起動しません。

実はこの問題は、1年以上前からASRockのマザーボードで発生していました。ASRockはいち早くACPI時計をデフォルトにしたようです。これを回避するパッチが見つかるまで、ASRockのマザーボードではmacOSが起動しない状態がしばらく続きました。HackintoshするならASRockは避けた方が良いかなと思っていたところ、数ヶ月後のBIOSアップデートでASUSのマザーボードも同様にACPI時計がデフォルトになってしまいました。フォーラムの方で教えていただきましたが、MSIのマザーボードでもACPI時計がデフォルトになっているようです。GIGABYTEの様子は把握していませんが、おそらくここ1年くらいで、どのマザーボードもレガシーRTCからACPI時計に移行していると思われます。この対策として次の4つの方法があります。

対策1 : BIOSでRTCを選択する

ACPI時計への移行をやめて、レガシーなRTCを使い続ける設定が一部のBIOSにあるようです。以下で紹介されています。

ASUSのマザーボードには、Advanced–>PCH Configurationの中に、System Time and Alarm Sourceの設定があります。これをデフォルトのACPI Time and Alarm DeviceからLegacy RTCに変更すれば良いようです。

ところが全てのマザーボードにこのメニューが出てくるわけではないようです。例えば、ROG MAXIMUS XI HEROのBIOS ver. 1105, 1302, 1401の画面にはこの選択肢が出てきません。もしかしたら将来のバージョンでRTCの選択肢が出てくるようになるのかもしれません。という事で、このメニューが出ないマザーボードでは、BIOSでLegacy RTCを指定する方法は使えません。

対策2：DSDTパッチを当てる

幸いなことに、ASRockのために配布されたパッチは、他のマザーボードでも動くようです。例えばこちらで紹介されています。

パッチの元記事によると、「ASRockマザーボードのDSDTのバグで、そのうちASRockが治してくれると思うけど、とりあえずこのパッチが動く」という意見らしいです。でも、このパッチが他のマザーボードでも有効らしいので、ASRock限定のバグ対策では無い気がします。これはACPI時計への移行を無効にしているパッチ、もしくはACPI時計を利用する問題点を回避するパッチなのではと思われます。パッチの方法は、config.plistのACPI –> DSDT –> Patchesに以下の記述をすることです。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>ACPI</key>
	<dict>
		<key>DSDT</key>
		<dict>
			<key>Patches</key>
			<array>
				<dict>
					<key>Comment</key>
					<string>RTC fix</string>
					<key>Disabled</key>
					<false/>
					<key>Find</key>
					<data>
					oAqTU1RBUwE=
					</data>
					<key>Replace</key>
					<data>
					oAqRCv8L//8=
					</data>
				</dict>
			</array>
		</dict>
	</dict>
</dict>
</plist>

ちなみにこのパッチが探しているデータ列と、置き換えているデータ列はそれぞれ以下のようです。

% echo -n oAqTU1RBUwE= | base64 -d | hexdump -C
00000000 a0 0a 93 53 54 41 53 01 |...STAS.|
00000008
% echo -n oAqRCv8L//8= | base64 -d | hexdump -C
00000000 a0 0a 91 0a ff 0b ff ff |........|
00000008

STASという文字を消そうとしているようにも見えます。

対策3 : SSDTで対処する

コメントで教えてもらいました。OpenCoreプロジェクトで、この問題に対処するSSDTが作られているようです。こちらにある

OpenCorePkg/Docs/AcpiSamples at master · acidanthera/OpenCorePkg

SSDT-AWAC.dslをMaciASLでコンパイルしてSSDT-AWAC.amlを作り、これを、EFI/CLOVER/ACPI/patchedに入れれば良いようです。それがうまく動かない場合は、SSDT-RTC0.dslを試すと良いようです。SSDT-AWAC.dslはこんな感じの内容です。先程のDSDTパッチと同様に、STASというパラメータらしきものを変更しようとしているようです。

/*
 * For 300-series only. If you can't force enable Legacy RTC in BIOS GUI.
 * macOS does yet not support AWAC, so we have to force enable RTC. Do not use RTC ACPI patch.
 * 
 * The Time and Alarm device provides an alternative to the real time clock (RTC), which is defined as a fixed feature hardware device.
 * The wake timers allow the system to transition from the S3 (or optionally S4/S5) state to S0 state after a time period elapses.
 * In comparison with the Real Time Clock (RTC) Alarm, the Time and Alarm device provides a larger scale of flexibility in the operation of the wake timers,
 * and allows the implementation of the time source to be abstracted from the OSPM.
 */

DefinitionBlock ("", "SSDT", 2, "ACDT", "AWAC", 0x00000000)
{
 External (STAS, IntObj)

 Scope (_SB)
 {
 Method (_INI, 0, NotSerialized) // _INI: Initialize
 {
 If (_OSI ("Darwin"))
 {
 STAS = One
 }
 }
 }
}

ASUSのROG MAXIMUS XI HEROで試してみました。現時点で最新BIOSは1401ですが、なんの対処もしない場合はmacOSが起動しません。そこで、SSDT-AWAC.amlをpatchedに入れたところ、無事macOSが起動しました。なお、これでうまく動いたので、SSDT-RTC0.amlは試していません。

対策4 : 古いBIOSを使い続ける

レガシーなRTCがデフォルトになっている古いBIOSからアップデートしないという消極的な解決策もあります。いろいろなバグが修正されているはずなので、一般的には最新バージョンの方が気持ち良いです。でもBIOSに限っては、動いているなら更新するなと注意しているメーカーのページも時折見かけます。全ての環境を網羅して動作試験を行うことは困難なので、問題なければアップデートして欲しくないという事情もわからないではありません。なので、古いまま使い続けるのは良い選択肢かもしれません。

うっかりアップデートしてしまっても、古いBIOSがメーカーサイトで配布され続けていますので、それに戻せば良いです。ただ、新しいBIOSにすると、通常の手順では古いバージョンに戻せなくなる場合があります。そこでこちらの記事ではUSB BIOS Flashbackという機能を使って古いバージョンに戻しています。

まとめ

現行のマザーボードがレガシーRTCからACPI時計に移行した事でmacOSが起動しない問題が発生することがあります。この問題は、DSDTへのパッチをconfig.plistに加える、もしくはBIOSで設定する、もしくはSSDTで設定を変更する事により回避できます。

Liluとプラグイン：(3) AirportBrcmFixupなどの使い方

Fri, 06 Dec 2019 23:06:11 +0900

Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありましたのでご紹介します。今回はAirportBrcmFixupとその他のkextの部分の抄訳です。原文は下のリンクを見てください。

Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いです。前回は、WhateverGreenとAppleALCを紹介しました。

Liluとプラグイン：(1) WhateverGreenの使い方

Liluとプラグイン：(2) AppleALCの使い方

（ここから抄訳）

AirportBrcmFixup

このプラグインの使い方は簡単です。これは、ネイティブまたは非ネイティブな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を設定する必要はありません。

もし、インストールされたWiFiアダプターのVIDとPIDが不明ならば、Hackintoolを使って、デバイスを特定し、PCIアイコンをクリックして、リストの中からWiFiデバイスを発見して、VID (Vendor ID) とPID (Device ID) を知ることができます。

上の例では、WiFiデバイスのVIDは14E4 (Broadcom社のIDです) であり、PIDは43BA (BCM43602チップセット）です。

WiFiデバイスがサポートされているのかどうかは、Git-Hubプロジェクトページのinfo.plistを見て、そこでWiFiデバイスのPIDを探せば確認できます。

もしこのリストにVIDとPIDがあればokです。単にAirportBrcmFixup（とLilu）をインストールするだけです。

必要ならばmacOSのWiFi地域設定を書き換えることもできます。起動オプションに

brcmfx-country=XX

を追加します。これによりWiFiデバイスの国コードを明示的に設定することができます。（訳注：日本に設定するのでしたらbrcmfx-country=JPです）5GHz WiFiを稼働させたり、WiFiルーターをフルスピードで稼働させる場合、国コード設定が必要なことが時々あります。一般的な値は

brcmfx-country=#a

です。これはルーターが設定する国コードを無視するようにmacOSに指示する特別な値です。私のルーターでは、どのバージョンのmacOSでも、#aを付けないと5GHz WiFiの最大速度が得られませんでした。

注意： AirportBrcmFixupは、WiFiのことだけの面倒を見てくれます。Bluetoothを有効にするためには、RehabManさんのBrcmPatchRAMを使います。（訳注：コメントで指摘いただきましたがこちらもご覧ください。そちらのread meを見たら、アップル純正無線カードには関係のないようでした。）

私は、 DW1830 (BCM43602) 搭載ラップトップでAirportBrcmFixupをテストしました。また、BCM943602CS搭載のデスクトップでも使いました。とてもよく動作し、他のパッチもエネーブラーも不要です。

その他のLiluプラグイン

以下は、有用なLiluプラグインのリストです。ほとんどは、/L/Eに入れるだけです（訳注：ESPのkexts/Otherで良いと思います）。追加の設定は不要です。

VirtualSMC

Apple SMC (System Management Controller) を有効にするプラグインです。以前はFakeSMCを使うのが一般的でしたが、長らくアップデートされていません。環境によりますが、VirtualSMCは現在と未来のmacOSでより互換性があります。

FakeSMCからVirtualSMCに移行するためには、FakeSMC.kextを取り除くだけでなく、EFIドライバーのSMCHelper.efiも取り除きます。また、FakeSMCセンサープラグインも取り除きます。

VirtualSMCをインストールするには、VirtualSMC.kextの他に、VirtualSMC.efiもUEFIドライバーとしてインストールします。VirtualSMCの配布パッケージには、この他、光センサー、バッテリーモニター、CPU温度モニターやマザーボードセンサなどのプラグインkextも用意されています。詳しくはこちらをご覧ください。

BT4LEContiunityFixup

AirportBrcmFixupを入れてもなおBluetooth関連のcontinuity問題（AirDrop, Handoff, FaceTime, Apple Watch, Continuity など）が発生するようでしたら、BT4LEContinuityFixup を試してみるもの良いです。macOSのBluetooth LE Continuityを有効にするパッチが含まれています。 BrcmPatchRAM kextも一緒に使ってください。

HibernationFixup

その名の通り、HibernationFixup.kextはディスクにデータを保存するハイバーネーションモード3と25を特定のシステムで有効にします。私は使ったことがないのですが、これが動いたという報告は多数あります。ネイティブなNVRAMが使えることが条件です。エミュレートされたNVRAMでは使えません。

NoTouchID

最近のMacBookシリーズSMBIOS設定はアップルの指紋認証(TouchID)搭載機種を対象としています。これらのSMBIOSをHackintoshで使用すると、起動時とシステムパスワードを表示する場面で遅延が発生します。というのは指紋認証デバイスが搭載されていないからです。NoTouchIDプラグインは、この問題を解決します。

NightShiftUnlocker

デフォルトではアップルのnight shiftは一部のSMBIOSでしか機能しません。この簡単なプラグインは、通常はnight shiftをサポートしていない機種設定でも、有効にします。

Liluとプラグイン：(2) AppleALCの使い方

Sun, 01 Dec 2019 11:30:54 +0900

Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありましたのでご紹介します。今回はAppleALCの使い方の部分の抄訳です。原文は下のリンクを見てください。

Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いです。前回は、WhateverGreenを紹介しました。

Liluとプラグイン：(1) WhateverGreenの使い方

AirportBrcmFixupに関しても後ほど紹介したいと思います。

（ここから抄訳）

AppleALCとは

AppleALCはLiluのプラグインです。ネイティブでないオーディオコーデックに対してHigh Definition Audio (HDA)を有効にするために、AppleHDA kextに動的にパッチを当てます。WhateverGreen (以下WEG) と同様に、オーディオを有効にするために従来使用していた多くのパッチとkextを置き換えてくれます。なのでAppleALCを使用する前には、既にあるAppleHDAを有効にするパッチ、ダミーのkext、DSDTへの変更などを取り除いておき、AppleHDAをオリジナルの状態のkextに戻しておく必要があります。

Nvidia HDMIオーディオ

AppleALCはほとんどのNvidia GPUでHDMIオーディオを有効にします。必要な作業は、LiluとAppleALCをインストールする事だけです。もしHDMIをサポートしたNvidiaカードが使われていたら、AppleALCはこれを検出して、HDMIオーディオコントローラを有効にします。サポートされたNvidiaデバイスはこちらのページを見てください。Nvidiaデバイスのこのリストの最後にあります。

オンボードオーディオコーデック

AppleALCは、Raltek (ALC)、Conexant、IDTなどの多くのビルトイン（オンボードの）オーディオコーデックをサポートします。大抵の場合、やるべきことは、LiluとAppleALCをインストールして、config.plistに簡単な変更を加えるだけです。が、その作業の前に、AppleALCがどのように機能するか知っておくと良いです。

AppleALCはどのように動くのか

AppleALCの動作は従来の、AppleHDAに予めパッチを当てたり、ダミーを使ったりする方法と少し違います。AppleALCはコネクター、レイアウト、プラットフォームパッチの大規模なデータベースと理解できます。ロードされる際に、LiluとAppleALCは使用されているオーディオコーデックのタイプを自動的に検出し、データベースからパッチを探して、AppleHDAに動的にパッチを当てます。

AppleALCが使うパッチは、インデックス識別子により定義されています。バックワード互換性のために、パッチセットのインデックス識別子はlayout-idと呼ばれるプロパティ値で定義されています。layout-idはhackintoshのコミュニティで昔から使われてきた値で、パッチを当てたバージョンのAppleHDA（もしくはダミーHDA kextの）のレイアウトを選択する値です。

AppleALCのwake verb

追加の機能として、AppleALCはほとんどのコーデックのwake verbの面倒を見てくれます。なので、Codec Commanderをインストールしたり使用する必要はありません。（訳注：コンピュータがスリープするとオーディオアンプもoffになります。スリープから目覚めるときに、アンプがonにならなくて、スリープ復帰後に音が出ない問題が発生する事があります。wake verbはスリープ復帰時にアンプをonにするための特別なデータのようです。これを流す事でアンプがonになるようです。〜という理解で正しいでしょうか？間違っているようでしたらコメントで指摘してください。）

LiluとAppleALCのインタラクション

（訳注：この節の内容は理解できませんでした。すみません）

Liluがロードされると、Liluはlayout-idの値を見つけて、その値をAppleALCに渡します。この値を継承して、AppleALCはalc-layout-idという名前の新しいデバイスプロパティを作ります。AppleALCは次に、layout-idの値を新しいターゲットID（通常は7）に設定し、AppleHDAのターゲットレイアウトに（Liluのパッチエンジンを使って）パッチします。この時、指定した（alc-layout-idで指定された）コーデックのための、コネクターID情報、infoファイル、プラットフォームファイルが使われます。

この方法により、AppleALCはMojaveのドロップドレイアウトIDを無視します。（詳細はこの記事のオーディオの節を見てください）。というのは、インジェクトされたlayout-id値は、AppleALCのコーデックパッチデータベースのインデックスとしてのみ使われるからです。AppleALCはこのlayout-idによる再マップする枠組みを、Mojaveだけでなく、全てのバージョンのmacOSで使います。

サポートされているコーデックを確認

使用しようとしているコーデックをAppleALCがサポートしているかどうかは、ソースコードのResoucesフォルダの中で名前を探せば確認できます。コーデックがサポートされていなかったら、公式のAppleALCヘルプスレッドに投稿して、次のバージョンで入れてもらうよう依頼してください。そのコーデックの詳細（このスレッドの#1投稿を見てください）を投稿します。達人の誰かが、その投稿を見て、手助けを申し出てくれるでしょう。おそらく、Linuxを使ってコーデックのダンプを用意する必要があります。このガイドの対象外の話題なので、ここでは詳細に関して説明しませんが、あなたの投稿を見た誰かがダンプの取り方を説明するリンクを示してくれるはずです。

もし、使用しようとしているコーデックが、既にAppleALCでサポートされていたら、どのレイヤーがサポートされているかを、対応するコーデックフォルダにある、info.plistファイルを開いて知ることができます。これから、どのレイヤーIDが使用可能なのかがわかり、また、コメントからそのうちのどれを使うべきかを知ることができます。

一例として、私の2017年版HP Spectre X360ラップトップの場合は、Realtek ALC295コーデックを搭載しています。そこで、ALC295フォルダの中のinfo.plistを開きます。以下に示します。

ALC295 の info.plist（tonymacx86.com の画像）

この例では、Mironeさんのパッチが必要なパッチであり、これがレイアウト3であることがわかります。このように、コメントを読めば、システムに必要なレイアウトの記述を簡単に見つけられます。もし、全ての使用可能なレイアウトID値のリストが不明な場合、一つ一つ試して動く値を探します。また、Hackintoolを使ってどのレイアウトがサポートされているのか（下の方法で詳細を説明します）知ることもできます。

AppleALCの設定

AppleALC.kextをインストールした後ですべきことは、layout-idを設定することです。2つの方法があります。

方法1：Audio Injectで設定する（古い方法）

Liluはconfig.plist内のレガシーなパラメータであるClover/Device/Audio/Injectからlayout-id値をCloverに問い合わせる機能があります。なのでInjectのString値を正しいlayout IDに設定すれば良いです。以下のようにします。

<key>Devices</key>
<dict>
 <key>Audio</key>
 <dict>
 <key>AFGLowPowerState</key>
 <true/>
 <key>Inject</key>
 <string>3</string>
 <key>ResetHDA</key>
 <true/>
 </dict>

LiluがClover/Devices/Audio/Injectからlayout-idを取得するというレガシーな方法をサポートしなくなる可能性があることは注意すべきです。なので、次に示す方法2が良いです。

方法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のみが表示されます。

項目選択が終了したらPatchアイコンを押し、Patch機能を呼び出します。もしオーディオデバイスがシステム情報のPCIデバイスセクションの中で正しい名前で表示させたかったら、Advanced optionsの中のSpoof Audioオプションを選択します。この時Advancedページの他の項目は全てチェックを外します。

次に、Generalをクリックして、Device / PropertiesとAudio Deviceオプション以外のチェックを全部外して、Generate Patchをクリックします。

ここに現れたコードを、config.plistの該当する部分にコピーペーストします。以下のようになります。（訳注：Z390チップセット搭載マザボのALC1220を対象に同じ操作をしたのですが、心当たりのないmodel名になっていたり、hda-gfxという項目があったりしました。model名は適当に編集して、hda-gfxの項目は削除して良いのだと思います。）

 <key>Devices</key>
 <dict>
 <key>Properties</key>
 <dict> 

 <key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
 <dict>
 <key>AAPL,slot-name</key>
 <string>Internal</string>
 <key>device-id</key>
 <data>
 cKEAAA==
 </data>
 <key>device_type</key>
 <string>Audio device</string>
 <key>layout-id</key>
 <data>
 AwAAAA==
 </data>
 <key>model</key>
 <string>Sunrise Point-LP HD Audio</string>
 </dict>

 </dict>
 </dict>

config.plistの変更が完了したら、再起動してオーディオが動いているかどうかテストします。もし動いていなければ、他の有効なlayout-IDを試してください。

もし、全ての有効な値を試してもオーディオがまだ動かない場合は、新しいパッチセットが必要なコーデックを使っているのかもしれません。サポートされていないコーデックに関しては、AppleALCのヘルプスレッドを利用してください。

AppleALCのトラブル対策

AppleALCがロードされていることを確認する

AppleALCが正しくロードされて初期化されていることは、IORegisteryExplorerで確認できます。これはこちらのリンクからダウンロードできます。

IORegisteryExplorerを動かして、HDEFという文字を検索ボックスに入れます。ioregディレクトリーツリーにHDEFデバイスが見えるはずです。上の例では、次のように見えます。

HDEFが見えないようでしたら、LiluとAppleALCのインストール手順を確認してください。以下のACPI HDA/Codec Rename 問題も見てください。

上のスクリーンショットでは、AppleALCが動的に新しいプロパティalc-layout-idを作り出している事がわかります。ここでの3という値は、config.plistで設定した値です。同様に、layout-idという項目は7とあります。これは、AppleALCがパッチを当てようとしている対象のAppleHDAでのレイアウトで、macOSが使っているものです。

もし、HDEFの中にalc-layout-idが見つからない場合、AppleALCが正しくロードされていない、もしくは初期化されていないのかもしれません。この原因は、kextが正しくインストールされていないからです。kextを削除して、インストールを再度試みてください。

HPET 問題 (High Precision Event Timer)

上記のステップが正常でもなお音が出ない場合、HPETによってIRQの衝突が発生している可能性があります。

macOSにおいて、HPETは基本的に必要な仕組みです。これが正しく働く必要があります。このフォーラム（訳注：tonymacx86のフォーラム）のほとんどのガイドでは、BIOSでHPETを有効に設定していることを前提としています。しかしながら、いくつかのマザーボードとラップトップでは、HPETに関するネイティブなDSDTコードがIRQ衝突を引き起こし、AppleHDAの正しい初期化を妨げたり、雑音を出す事があります。

この問題を確認する一つの方法は、ターミナルで次のコマンドを入力する事です。

kextstat | grep 'Lilu\|AppleALC\|AppleHDA'

この結果、Lilu, AppleALC, AppleHDA kextがリストアップされるはずです。

MonkeyPro-2018:~ Jay$ kextstat | grep 'Lilu\|AppleALC\|AppleHDA'
 20 4 0xffffff7f81041000 0x22000 0x22000 as.vit9696.Lilu (1.2.8) 54014689-C8DA-318B-84F4-944BBA7AD2AC <8 6 5 3 2 1>
 23 0 0xffffff7f811bd000 0xdf000 0xdf000 as.vit9696.AppleALC (1.3.3) B60FCBAF-6BC2-36EF-A1E6-D5BE2863C35B <20 13 8 6 5 3 2 1>
 138 1 0xffffff7f830a7000 0x1d000 0x1d000 com.apple.driver.AppleHDAController (282.10) 70256EC9-AF38-31BD-A3C5-9C0E30B64AA3 <137 113 107 13 8 7 6 5 3 1>
 157 0 0xffffff7f8323a000 0xb7000 0xb7000 com.apple.driver.AppleHDA (282.10) B2208DA8-8CD9-36D8-BD59-C6D9A5379585 <156 138 137 124 113 107 7 6 5 3 1>
 159 0 0xffffff7f830c6000 0x2000 0x2000 com.apple.driver.AppleHDAHardwareConfigDriver (282.10) C4F674A0-5828-3D97-82BF-A81C8B8BDDBA <5 3>

この例から分かるように、AppleHDA、AppleHDAController、 AppleHDAHardwareConfigDriverとインストールされています。ここで重要なのは、 AppleHDAです。

もしAppleHDA (com.apple.driver.AppleHDA)が出力に現れていなかったら、HPETオプションが正しく有効になっているかどうかを確認してください。もし有効になっていてもAppleHDAが現れなければ、DSDTのHPETコードにパッチを当てる必要があります。

これを行う最も簡単な方法は、CloverのACPI/DSDT/Fixesの中の FixHPETをtrueにする事です。

<key>ACPI</key>
<dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>FixHPET</key>
 <true/>

この方法はほとんどのユーザで有効です。でも、もしCloverのHPETフィックスでもまだAppleHDAがロードされない場合、DSDTに直接パッチを当てる必要があるかもしれないです。RehabManさんがこのパッチを作ってくれていて、MaciASLを使って適用できます。

#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は無効にしておきましょう。

ACPI HDA/Codec 改名問題

WhateverGreenと同様に、 AppleALCとLiluはDSDTの中のACPIの名称を適切に自動的に改名してくれます。しかし時々失敗することもあり、手作業で改名する必要があります。この改名が正しく実施されているかどうかは、IORegistryExplorerを開いて、HDEFを検索してみればわかります。

もしHDEFがioregに存在すれば、これ以上の作業は不要です。しかし、もし存在していなければ、ここまで述べた作業が正しく行われているかどうかを確認してください。それでも解決しなければ、HDEF名称変更を手作業で行ってみる必要があります。

まずは、バニラな状態のDSDTをMaciASLで開いて、HDEFで検索して、元々のHDAデバイスの名前を確認します。もし検索結果がなければ、HDASで検索します。それがなければAZALで検索します。

もしHDAデバイスがHDEFと名付けられていたら、デバイスを改名する必要はありません。もしHDASと呼ばれていたら、次のコードをconfig.plistのACPI/Patchesに追加します。

<dict>
 <key>Comment</key>
 <string>change HDAS to HDEF</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 SERBUw==
 </data>
 <key>Replace</key>
 <data>
 SERFRg==
 </data>
</dict>

もしAZALでしたら、以下のパッチを追加します。

<dict>
 <key>Comment</key>
 <string>change AZAL to HDEF</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 QVpBTA==
 </data>
 <key>Replace</key>
 <data>
 SERFRg==
 </data>
</dict>

Liluとプラグイン：(1) WhateverGreenの使い方

Sat, 23 Nov 2019 23:49:44 +0900

Lilu.kextとLiluプラグイン.kextを設定するためのとても詳細なガイドがtonymacx86にありました。ここからLiluとWhateverGreenの部分を抄訳して紹介します。原文は下のリンクを見てください。

Liluの開発にも携わっているjaymonkeyさんが書いてくださったガイドです。かなり長いですので、LiluとWhateverGreenの部分を紹介します。残りの、 AppleALCに関してはこちらをご覧ください。

Liluとプラグイン：(2) AppleALCの使い方

AirportBrcmFixupに関しても後ほど抄訳したいと思います。

（ここから抄訳）

Liluとは何か

LiluはmacOSのパッチエンジンです。カーネルとシステム拡張を起動時に拡張します。使用することのメリットは多いです。

特定のブートローダーに依存しない
リカバリーモードやmacOSインストーラ・アップデータでも動く
シンボリックパッチエンジンもサポートする
カーネルとシステム拡張へのAPIアクセスを可能にする
起動中のプロセスの変更も可能

Liluはパッチの仕組みを提供するだけで、それだけでは何もしません。プラグインと一緒に使うことで機能します。Liluパッチを作成するための開発キット(SDK) も用意されています。有名な3種のパッチは、WhateverGrenn, AppleALC, AirportBrcmFixupです。以下ではこれらについて説明します。Liluプラグインの全てのリストはLiluのGitHubをご覧ください。（訳注：VirtualSMCもLilu使ってたんですね。）

Liluプラグインはそれだけで機能し、同様の機能を提供する従来型のCloverのパッチやkextを置き換えます。そのため、関係するClover設定、FakeID, パッチ、kextがすでに導入されていたら、それを取り除いてください。例えば、LiluプラグインであるAppleALC.kextをインストールしたら、CloverのAppleHDAパッチとHDA Enabelerのパッチやダミーのkextは全て取り除くか無効にします。競合するパッチが残っていると、システムが予想外の動作をしたり、不安定な状態になります。

Hackintool

以下の説明ではHackintoolを使います。ぜひ備えておいていただきたいツールですので、ここからダウンロードしておいてください。

Liluとプラグインのインストール方法

LiluとそのプラグインはmacOSのkextとして提供されます。これらは、 /Library/Extensionsに入れるべきです。Cloverのkexts/Otherに入れるとしたガイドも多いですが、この方法は試験や開発だけに留めておくのが良いです。サードパーティのkextを入れる正式な場所は/Library/Extensionsです。（訳注：どちらが良いかは議論のあるところだと思います。簡単なのでkexts/Otherで良いのではないかと思います。これ以降、/Library/Extensionsに入れるための方法が続きますが省略します。Catalinaになるとセキュリティ保護が厳しくなるので、かなり面倒なようですね。）

WhateverGreen (WEG)

WhateverGreen（以下WEG）は2017年にAMD GPUのためにリリースされましたが、現在（2019年）では以下の機能を統合しています。

IntelGraphicsDVMTFixup –> Intel IGPU DVMT Pre-allocationのパッチ
IntelGraphicsFixup –> Intel IGPU’sをサポートするための多数のパッチ
NvidiaGraphicsFixup –> Nvidia GPUをサポートするための多数のパッチ
CoreDisplayFixup –> High DPI表示のパッチ (pixel clock patch)
Shiki –> DRMで保護されたビデオ再生のためのパッチ
AzulPatcher4600 –> HD4600 IGPUのAzulフレームバッファのためのパッチ
AppleBacklightFixup –> バックライト制御のプラグイン
EnableLidWake –> ラップトップの蓋操作でスリープ解除するためのパッチ

このようにWEGは、GPU/IGPUとディスプレイに関する全ての解決策を提供します。また、統合されてしまった上記のプラグインは、WEGと一緒に使わないでください。カーネルパニックやOSの異常動作を引き起こす可能性があります。

WEGの前準備

Cloverのconfig.plistから、IGPUに関する全てのインジェクション、設定、フェイクIDなどを除去してください。これを行わないと、WEGの動作と衝突することになり、想定外の結果を引き起こします。

最新版のLiluとWEGを/L/Eに入れます。（訳注：kexts/Otherでも良いと思います。）

WEGはデバイス改名処理も行います。なので、Cloverのconfig.plistに次のようなACPI Fix/Renameの箇所があれば、これを削除します（もしくは無効にします）。

GFX0をIGPUに変更するパッチ
PEG0をGFX0に変更するパッチ
HECIをIMEIに変更するパッチ

これらのClover ACPI Fix/Renameの手法は、ACPIのテーブル全体に変更を与えてしまうために、後に問題を引き起こす可能性があります。WEGの方法は特定のACPIコードを探索して、そこだけを変更しますので、優れています。

AMDとNvidiaのdGPU

AMDとNvidiaユーザは、Lilu と WEGをインストールすることで、フレームバッファもdGPU関係のパッチも全て対応できます。上級者向けには起動オプションが多数ありますので、WEGのreadme.mdを見てください。Liluの概要で述べたように、AMDとNvidiaのGPUに関するパッチは、config.plistから削除してください。WEGがこれらを全てやってくれます。

IntelのiGPU

iGPUだけのシステム、もしくはdGPUと併用するシステムでは、WEGは従来の方法より早くて簡単なカスタマイズ手段を提供します。従来の方法では、Cloverを使ったり、Intel iGPUドライバーにパッチを当てたり、フレームバッファkextにパッチを当てたりしていました。

WEGをそのまま使う

最近のWEG (V1.3.0以降) は、改善されたiGPU自動検出と自動設定の機能があり、追加の作業なしでたいていのシステムでそのまま動きます。まずは、上記で説明したWEGの前準備を実行しておいてください。その後、単にLiluとWEGをインストールして再起動するだけです。なお、SMBIOSの記述はWEGの自動設定に影響を与えます。

（訳注：GPUを動かすためには、「前準備」をして、LiluとWEGを入れるだけで良いということです。それで問題なく動く場合は、この先は参考程度に読んでください。）

WEGの自動設定は非常に改善されてはいますが、完璧ではなく、全てのシステムで機能するわけではありません。自動設定が機能しない場合は、WEGを手作業で設定しなければなりません。また、dGPUが搭載されている場合、WEGはiGPUを「ヘッドレス」に設定したいところです。でもそのためにはiGPUとdGPUがBIOSで正しく設定されている必要があります。ヘッドレスに関して後で詳細に説明します。

WEG手動設定に必要なID情報

WEGはDevice Propertiesを使って設定を行います。これはCloverを使ってデバイスioregディレクトリーツリーのカスタムプロパティを定義する比較的新しい方法です。Lilu開発メンバーからのリクエストでCloverに実装された手法です。デバイスプロパティについての詳細はClover開発ブログのこちらをご覧ください。

デバイスプロパティは、Cloverのconfig.plistのDevices –> Propertiesセクションで定義されます。プロパティは、PCIパスで決まる名前とデータ値から構成されます。名前とPCIパスはタイプで、データ値は次の3種類のうちの一つで表現されます。

iGPU デバイスプロパティ

全てのiGPUパッチは、Hackintoolのトップメニューの2番目のアイコンにあるパッチモードで実行できます。また、下のバーメニューを使ってパッチモードのサブ機能を使えます。Patchをクリックして、infoを選択してみました。

もしHackintoolがシステムのCPU世代を正しく特定しているものの、Platform IDドロップダウンメニューが空で、FramebufferとConnectorサブメニューにデータが表示されない場合は、HackintoolのメニューバーのFramebufferをクリックして、macOSバージョンを使用中のものに設定してください。

もしHackintoolがCPU世代を自動的に特定できなくて、Current Framebuffer Infoボックスに???が表示されたり、Hackintoolが誤った世代のCPUを選択しているようならば、ドロップダウンメニューから手作業で正しいCPU世代を設定できます。

Hackintoolを最初に起動すると、iGPUを検出して、それ用のデフォルトPlatformIDを選択しますが、多くの場合、これらは正しくないので、最初にこれを正しく選択させる必要があります。

Infoサブ機能を選択すると、検出されたiGPUのタイプが下のCurrent Framebuffer Infoボックスに表示されます。また選択されたPlatformIDの詳細と、合致したSystem Definitions (SMBIOS)が上のSelected Framebuffer Infoボックスに表示されます。

例えば、2017年版HP Spectre X350ラップトップで最初にHackintoolを動かした時は、PlatformIDとして0x591B0000が選択されて、System Definition (SMBIOS) としてMacBookPro 14,3が推奨されました。

上の図では、矛盾した情報が表示されています。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の番号に合うように選択すると良いと思います。）

ラップトップPCの場合は、モバイル用のPlatform ID（Mobile の欄に Yesと表示が出ます）を選択します。デスクトップPCの場合はMobileがNoのものを選択します。

私のHP Spectre X360ラップトップでは、0x59160000が必要であると分かっていましたので、ドロップダウンメニューからこれを選択しました。

さてこれで、Selected Framebuffer InfoボックスとCurrent Framebuffer Infoボックスで同じiGPUタイプが表示されるようになりました。HP Spectre X360ラップトップはMobile HD 620 iGPUで、推奨のSystem Definition (SMBIOS)はMacBookPro14,2です。

プロの技：@headkazeさんによるリストを使うことでも、PlatformIDを見つけることができます。これは、macOSで使えるPlatformIDとFrameBufferのリストです。これを使えば、例えば、Coffee Lake CPUを使う場合、Coffee Lake CPUセクションまでスクロールすると、最初に全てのPlatform IDがまとめられています。ここには、MobileかDesktopシステムなのかが書いてあります。またコネクタの数が0になっているIDは、ヘッドレスのものです。

それぞれのPlatform IDの詳細は、少しスクロールすると見ることができます。例えばPlatform ID 0x3E9B0000の詳細は以下のように書かれています。

この情報から、このPlatform IDがMacBookPro15,1で使われていることがわかり、これがIntel UHD 630 iGPUのPlatform IDだとわかります。Hackintoolからもこれらの情報はわかりますが、リストアップされた形式で確認する方が簡単なこともあります。

HD 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を使っていることが原因かと思われます。

**重要：**選択したPlatform IDに合ったSystem Definition (SMBIOS)を使うようにしましょう。Hackintoolは多くの場合、推奨するSMBIOSを上のSelected Framebuffer InfoボックスのModel(s)欄に表示してくれます。Platform IDと合致しないSMBIOSを使うとmacOSが動作不良に陥ります。

**注意：**いくつかのPlatformIDでHackintoolのModel(s)欄に推奨System Definition (SMBIOS)が表示されない、もしくはUnknownと表示されることがあります。これはそのGPU、IGPU、Platform IDと合致するMac機種が存在しないからです。しかし、IGPU Platform IDは有効で機能するはずです。でも、できるならば、使用しているiGPUに合致したフレームバッファを持つ他のPlatform IDを選択し、それから推奨されるSMBIOSを選ぶのが良いです。

適合するPlatformIDが見つからない場合

もし使用しているiGPUに合致するPlatform IDを見つけられない場合、最も近いものを代わりに選ぶことになります。例えば、UHD 620を使っている場合、最も近いのはおそらくUHD 630のPlatform IDです。他の例では、HD 4400 iGPUの場合は、HD 4600またはHD 5200のPlatform IDを選ぶと良いです。これらの場合、システムをちゃんと動かすために、異なるPlatform IDをいくつか試すことになります。

もしシステムがラップトップならば、MobileがYesになっているモバイル用のiGPU Platform IDを選択します。（訳注： arc.intel.comで該当するCPUの仕様を見ると、「システムの種類：Mobile」などと書かれた項目があるので、それに合わせるのが良いと思います。）

もし、iGPUと合致しないPlatform IDを使う場合、対象のiGPUタイプのデバイスIDを知る必要があります。これは後で説明します。

適合するSMBIOSが見つからない場合

もし推奨SMBIOSに対するPlatform IDが見つからない場合でも、動かないわけではありません。この場合は、作ろうとしているシステムに一番近い、合致するSMBIOSを推測することになります。この作業に便利なツールがMacTrackerです。

**注意：**もしSMBIOSを変更する必要がある場合、iCloudなどのAppleのオンラインサービスからログアウトすることを忘れないでください。また、iDiot’s Guide To iMessage を見て、新たに設定をおこなってください。（訳注：Appleからbanされることもあるので注意しましょう。SMBIOSの試行錯誤をする場合は、ネットから切り離して作業するのが良いと思います。）

ヘッドレスPlatform ID

デスクトップHackintoshユーザが、Hackintoolが推奨するPlatform IDを上書き変更したいと思うもう一つの状況は、iGPUをヘッドレスモードで使いたいという場合です。（訳注：ヘッドレスというと、通常は、PCをネットから制御することを前提に、ディスプレイ無し使用することを言います。でもここでは、dGPUにはディスプレイを接続するけど、iGPUにはディスプレイを接続しないという意味のようです。）

iMacや幾つかのMac miniのように、デュアルGPUを搭載している純正のデスクトップ型Macは、ヘッドレスPlatform IDを使っています。これにより、macOSにiGPUには物理的なディスプレイが接続されていないこと、しかしハードウェア加速機能のためにmacOSがiGPUを使用できること、を伝えています。iGPUがヘッドレス利用と設定されると、macOSはiGPUを、AirPlayのミラーリング表示機能や、静止画・動画の符号化・復号化機能 (Intel Quick Sync -iOS)などで使うための、ある種のGPU副プロセッサとして使用します。これはmacOSの重要な機能です。ですので、もしdGPUの他にサポート対象のiGPUがあるならば、iGPUをヘッドレス構成に設定すべきです。

**注意：**ワークステーションクラスのCPU (Intel Xeon) を搭載したシステムは、iGPUを備えていません。なので、ヘッドレスPlatform IDを設定してはいけません。

もし、ヘッドレス構成が不要ならば、次の、「WEGの手動設定」まで読み飛ばしてください。

Hackintoshの主ディスプレイアダプターがNvidiaやAMDのdGPUであり、サポート対象のiGPUも備えていたら、ヘッドレスPlatform IDを使えば、そのHackintoshシステムは安定になり、iGPUによるハードウェア加速機能を備えた純正のMacのように振る舞います。

iGPUをヘッドレスモードで動かすためには、以下のBIOS設定を行います。

IGPU -> Enabled
Primary Display Adapter -> dGPU (PEG)
Multi-Monitor Mode -> Enabled (このオプションがある場合)

また、デュアルGPU構成をサポートし、使用中のCPU/iGPUタイプに合致するMacのSystem Definition (SMBIOS) を正しく設定しておく必要があります。ヘッドレスPlatform IDのためのオススメのSMBIOSは以下です。

Coffee 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ボックスに表示します。

現在知られているヘッドレスPlatform IDは以下です。

Coffee Lake CPU
9th Gen UHD-630 IGPU = 0x3E980003 (MacOS 10.14.4+で使用)
8th Gen UHD-630 IGPU = 0x3E920003 or 0x3E910003 (MacOS 10.13.6 〜 10.14.Xで使用)
Kaby Lake CPU
HD-630 IGPU = 0x59120003 (MacOS 10.13.Xで使用)
Unknown = 0x59180002 (推奨しません)
SkyLake CPU
HD-510 IGPU = 0x19020001
GT2f IGPU = 0x19170001
HD-530 IGPU = 0x19120001
Iris Pro 580 = 0x19320001
Haswell CPU
HD-4600 IGPU = 0x0412000B or 0x04120004
Ivy Bridge CPU
HD-4000 IGPU = 0x01620006 or 0x01620007
Sandy Bridge CPU
HD-3000 IGPU = 0x00030030

**注意：**モバイル用CPUであるCannon-Lake と Ice-Lake CPUにはヘッドレスPlatform IDはありません。

Hackintoolを使って、Connectors機能を選択することで、選択したPlatform IDがヘッドレスであるかどうかを確認できます。全てのエントリーは次の値を持っている場合、ヘッドレスです。

index = -1
bus id = 0x00
pipe = 0
type = dummy

これに加えてHeadlessアイコンが表示されます。HaswellのヘッドレスPlatform IDである0x0412000Bの例を示します。

注意-1: ヘッドレスiGPUモードはデスクトップ機のデュアルGPU構成 (dGPU + iGPUの構成)でのみ良好に動きます。両方のGPUの出力が同じディスプレイに接続されるラップトップ機のデュアルGPU構成では動きません。このような構成では、RehabManさんのガイドのようにdGPUを常に無効にしないとmacOSが動かないからです。

注意-2: 既に述べたように、ヘッドレスPlatform IDの使用は、推奨された機種のSMBIOSでのみ機能します。それ以外のシステムを設定すると不安定になります。

注意-3: ヘッドレスPlatform IDを使う場合、iGPUは、BIOSで有効に設定してあっても、システム情報 -> ハードウェア -> グラフィックス/ディスプレイには現れません。これは正常です。これによりヘッドレスiGPUモードが機能していることを確認できます。

注意-4: Hackintoshに1個または複数のThunderbolt 3ポートが実装されていて、これをdGPU + ヘッドレスiGPUの表示に使いたい場合は、BIOSで”Above 4G Decoding”オプションを有効にする必要があります。

注意-5: iGPUをヘッドレスに設定した後、IORegistryExplorerを使ってIOREGを調べることで、全てが正しく設定できたことを確認できます。”IGPU”で検索して、iGPUエントリーのAAPL, ig-platform-idプロパティが、ヘッドレスPlatform IDに設定されていて（バイト順が逆になっています）、適合したモデル設定になっていることを確認します。

WEGの手動設定

HackintoolのPatchモードの他のサブ機能のボタンをクリックすると、現在選択されたフレームバッファー設定と変更をチェックできます。大抵の場合、ここでは何も変更する必要はないです。詳しくは WEG guideのpost #2を見てください。全てokでしたらPatchサブ機能ボタンを押します。

iGPUなりすまし

もしiGPUに合致しないPlatform IDを使用しているなら、iGPUのdevice IDを他の値に偽装しなければなりません。

例えば、UHD 620 iGPUを使用する場合、これに対応するPlatform IDはありません。もっとも近いPlatform IDはUHD 630 iGPUです。それでUHD 630のPlatform IDを選ぶことになり、iGPUをUHD 630に偽装する必要があります。

iGPUのなりすましを行うためには、Advancedページを使います。（訳注：上のアイコンでPatchを選び、下のボタンでPatchを選んだ後に上部に現れるAdvancedタブです。）ここでSpoof Video Deviceにチェックを入れ、ターゲットのiGPUデバイスIDを隣にあるドロップダウンメニューから選びます。下のスクリーンショットでは、UHD 620 iGPUをUHD 630になりすましさせています。

iGPUパッチ生成

次に、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ラップトップで動かした例を示します。

このパッチコードを、plistの正しい構造を維持しつつ、config.plistにコピーペーストします。とのブロックの部分を選択してコピーします。

次に、これをconfig.plistのDevices -> Propertiesセクションにペーストします。上の例の場合、このような感じになります。

<key>Devices</key>
 <dict>
 <key>Properties</key>
 <dict> <<----- ここの後にHackintoolのパッチをペーストする

 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 AAAWWQ==
 </data>
 <key>AAPL,slot-name</key>
 <string>Internal</string>
 <key>device-id</key>
 <data>
 FlkAAA==
 </data>
 <key>device_type</key>
 <string>VGA compatible controller</string>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 <key>model</key>
 <string>HD Graphics 620</string>
 </dict>

 </dict>
</dict>

注意: Sandy BridgeではDevice Propertyの名前はAAPL,snb-platform-idになります。 (AAPL,ig-platform-idではありません)

暗黒画面とコネクター不全

ほとんどの場合Hackintoolが生成するデバイスプロパティはWEGが正しくiGPUを構成するのに十分な情報量です。しかし、いくつかのシステムではさらにフレームバッファデフォルト値を変更する必要があります。例えば、iGPUのポートをDVIからDPに変更したい場合や、DPからHDMIに変更したい場合です。この場合、Hackintoolを使ってさらなる設定を行い、新たなパッチを作成して、config.plistのDevice Propertiesに追加します。これに関してはCaseySJさんの素晴らしいガイドがあるので、以下を見てください。

高DPI表示とデュアルモニター

高DPIディスプレイを使う場合、または私の場合のようにラップトップに外部ディスプレイを接続する場合、macOSの起動オプションに -cdfon を追加します。これにより、WEGのピクセルクロックパッチを有効にします。これにより高DPI表示に必要な解像度とリフレッシュレートを可能にします。この機能は、以前はCoreDisplayFixUpプラグインが担っていましたが、今はWEGに統合されました。

この場合iGPUのVRAMをデフォルト値の1536MBから2048MBに増加しておくことをお勧めします。これにより2面の1080P表示が可能になります。これには、config.plistのDevice Propertiesセクションに以下を追加します。

<key>framebuffer-patch-enable</key>
<data>
AQAAAA==
</data>
<key>framebuffer-unifiedmem</key>
<data>
AAAAgA==
</data>

注意: VRAMを2048MBに増やす設定は1080Pディスプレイ1個のシステムや、ヘッドレスPlatform IDのシステムでは何の効果もありません。

変更をテストする

必要な変更をconfig.plistに書き込んで再起動します。うまく起動したらHackintoolで状況を把握して、加速機構などが機能していることを確認します。

また、WEGがHECIデバイスを正しくIMEI (Intel Management Engine Interface)に改名できているかどうか確認することをお勧めします。これにはターミナルで以下のコマンドをタイプします。

ioreg | grep IMEI

IMEIに改名するパッチが効いている場合、以下のように表示されるはずです。

| | +-o IMEI@16 <class IOPCIDevice, id 0x100000264, registered, matched, active, busy 0 (36 ms), retain 11>

もしWEGによる改名が確認できない場合は、従来のCloverのHECI -> IMEI改名パッチを使ってください。

<dict>
 <key>Comment</key>
 <string>change HECI to IMEI</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 SEVDSQ==
 </data>
 <key>Replace</key>
 <data>
 SU1FSQ==
 </data>
</dict>

DRM問題

DRM (Digital Rights Management, デジタル著作権保護）されたコンテンツが再生できないことがあります。解決は困難です。特にKaby Lake以降のiGPUだけを使ったシステムでMojave以降を使用する場合、現状では対応不可能です。

WEGはDRMに対応していたShikiの機能を引き継いでいます。もし、iTunes、ウェブブラウザでのNetFlix再生などができない場合は、起動オプションでshikigva=1などして、試してください。shikigvaの番号には以下の機能があります。

001 = 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問題を解決することもあります。

shikigvaの001オプションを使うと、macOSはもっとも適切なハードウェアレンダラーを使うようになります。でもこの自動設定を変更してDRM再生GPUを指定したい場合は、以下のどれかのコマンドを使います。

Intel iGPUを使うように指定する

defaults write com.apple.AppleGVA forceIntel -boolean yes

AMD/ATI dGPUを使うように指定する

defaults write com.apple.AppleGVA forceATI -boolean yes

Nvidia dGPUを使うように指定する

defaults write com.apple.AppleGVA forceNV -boolean yes

私の理解では、AMD GPUは多くの場合、良好に動作します。一方でNvidia GPUとIntel IGPUは世代によって良かったり悪かったりします。

もしshikigva=1でもshikigva=57でもDRM再生ができない場合は、shikigva=60 (004 + 008 + 016 + 032) を試してみてください。これは、代替Board IDを使い、さらに別の互換性のある、GPUハードウェアを使用しないDRMレンダラー手法を使う設定です。もしどれも（1, 57, 60のいずれも）だめなようでしたら、他に問題があると思われます。他の値を試してみてください。

ちなみにmacOSのDRM設定を元のデフォルト設定に戻すには、以下のコマンドを一つずつ使います。

defaults 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のドライバーそのものが原因かもしれません。

DRM再生はCoffee Lakeシステム (第8世代と第9世代)において特に困難なようです。私はCoffee Lakeを持っていないのですが、@Jaco1960さんによる第8世代を使った報告によると、DRMを動かすたった一つの方法は、iMacPro1,1に設定することだそうです。その結果は以下のようです。（訳注：どの方法を使ってもSideCarが動かなくなるということかな。これは手を出しにくいですね。）

@pastrychefさんも、Coffee Lakeで動かすためには、iMacPro1,1の設定が必要と報告しています。現在は、DRMを100%動かせる方法はありません。

Radeon RX 5700を使う

Sat, 09 Nov 2019 00:06:25 +0900

macOS Catalina 10.15.1からAMD Radeon RX5700シリーズがサポートされました。それでRX 5700 XTを使ってみたところ動きました。最新のWhateverGreen.kextが必要です。でも現状のmacOSでは性能を活かし切れていないようです。

話題のRX 5700/5700XT

AMDのグラフィックスカードRadeon RX 5700シリーズは、7nmプロセスで製造され、新設計のNaviアーキテクチャを採用しています。プロセッサ数はRadeon RX Vega 64より少ないですが、下表のようにVega 64より性能が良いとのことです。その上、消費電力は少なく、安価な設定です。ただ、Vega 64は発売時に比べたら暴落しているので、実売価格は逆転しています。


	5700 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の比較結果です。)

5700シリーズは優れた製品なので、Radeon派のWindowsユーザからは、久々にAMDが良い製品を出してくれたと、高い評価を受けています。この人気GPUが、macOS Catalina 10.15.1から正式にサポートされました。Sonnet社の互換GPUリストにも早速登場しています。

Sonnetの互換GPUリスト (10.15.1以降)

そこで、リファレンスファンモデルのRX 5700 XTをmacOSで動かしてみました。GPU用水冷ブロックは、ほぼリファレンスファンモデル用しか用意されないので、将来水冷することを考えるとリファレンスモデルが欲しいところです。しかも、オリジナルファンモデルのグラフィックスカードが出回ってくるとリファレンス版の流通は無くなってしまいます。実際、現在は入手困難です。

でも、水冷のことを考えなければ、現在流通している空冷性能の良いオリジナルファン版が良いと思います。

Catalinaで動かす

macOS 10.15.1で正式サポートされたので、特に問題なく動きます。ただ、WhateverGreen.kextは最新版の1.3.4を使う必要があります。また、Cloverの起動オプションに

agdpmod=pikera

を追加する必要がありました。環境によってはこのオプションが無くても動くこともあるようです。ちなみにこのオプションは、WhateverGreen.kextのもので、解説によると、

AppleGraphicsDisplayPolicy.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は見つからないので、おそらくは、

/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のこのオプションは、特定機種に対する設定を無効にするパッチ手段を選ぶオプションのようです。

動作確認

agdpmod=pikeraを起動オプションに追加するだけで問題なく動いています。システム情報を見ると上のようでした。機種IDが0x731fです。これは先ほどのInfo.plistには書かれてません。（RX 580などは書かれています）サポートが今後改善されれば追加されるのかもしれないです。

ベンチマーク

Geekbench 5を使ってベンチマークし、スコアをSapphire Pulse Radeon RX 580と比較します。まずはOpenCLとMetalのスコアを以下に示します。


	RX 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バージョンで改善されると期待したいです。

まとめ

Radeon RX 5700シリーズはmacOS 10.15.1以降で容易に動かすことができます。ただOpenCLベンチマークスコアではRX 580と差がなく、Metalでは負けてます。今後のmacOSバージョンアップで性能向上が期待できますが、現状ではRX 580/590で十分だと思いました。Windowsとデュアルブートする場合は、Windowsで性能が出せてmacOSでも使えるGPUとして価値があるかと思います。

Hackintoshの作り方（総集編: macOS 10.15版）

Sun, 13 Oct 2019 23:00:57 +0900

macOSをインストールする方法をご紹介してきたのですが、多数の記事に分散してしまっています。そこで、10.15 Catalinaをインストールするための参考になる関連記事へのポインタをまとめた総集編を作りました。

10.14を対象とした情報は、以下をご覧ください。

Hackintoshの作り方（総集編:10.14版）

10.13を対象とした情報は、以下をご覧ください。

Hackintoshの作り方（総集編:10.13版）

手順の概要を把握する

こちらは9TO5MacのライターのJeffさんのビデオです。テンポよく紹介されていますので、全体の流れを確認するのに良いと思います。High Sierra時代のビデオですが、ほぼ変わらないので参考にしてください。

Jeffさんのインストールガイドビデオ

macOSインストールのアプローチはたくさんありますが、一番おすすめなのは、Cloverを使ってバニラなインストールをすることだと思います。そのことを説明しています。

/posts/131/

Cloverインストーラだけを使って、手順を理解しつつインストールすることが理想だと思いますが、それが困難な場合は、tonymacx86で配布されているツールを使っても良いと思います。こちらをご覧ください。

tonymacx86式インストール手順 (その1: UniBeast)

ハードウェアを用意する

Hackintoshを作るためには、互換性のあるハードウェアを自由に選んで組み合わせられる自作PCが、問題が少なく楽です。ノートPCなども可能ではありますが、上級者向けだと思います。

CPU

CPUは、最新の第9世代Coffee Lake-S Refreshが良いと思います。最近では品揃えも増えたので選びやすいと思います。第9世代Core iシリーズ最安の9100Fでは、問題なくmacOSが動きます。以下はMojaveの例ですがCatalinaも同様の手順で動きます。

MSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh

この記事を執筆段階でのMac製品で採用されているデスクトップ向け第9世代Core iシリーズCPUは9600Kと9900Kです。このどちらかを選べば、CPU関係の設定で苦労することなく、macOSを動かすことができます。

MSI B360M MORTAR TITANIUM, 9600K

9900K搭載Z390マザーボードでHackintoshを作る

マザーボード

マザーボードは、第9世代CPUをサポートするZ390, H370, B360などのチップセット搭載マザーボードを選ぶことになります。新規に購入するなら、古いマザーボードを選ぶ理由はないので、最新のものを選んだ方が良いと思います。安く自作するためにパーツの一部を中古で購入することもあるとは思いますが、マザーボードは新品が良いと思います。中古のマザーボードは、部品が劣化していることもあるようで、動作が安定しない印象があります。HackintoshはそもそもOSレベルで怪しいことをやりますので、ハードウェアは信頼性のあるものを選んでおきたいと思います。

マザーボードメーカーに関して、昔はGigabyteの互換性が高いと言われていましたが、今は、あまり関係ないです。カーネル読み込みのためのメモリー確保の容易さを考えるとASUSやASRockが良いように思います。MSIのメモリーマップも癖がありますが、対応は容易です。Gigabyteは、メモリー確保設定が難しい機種もあるようです。詳しくはこちらをご覧ください。いずれにしても、ネット上に成功例があり、詳しく解説されているマザーボードを選ぶのが良いと思います。

slideでカーネル読み込み番地を調整する (Clover編)

グラフィックス

iGPUを使っても良いですが、拡張できるという自作のメリットを生かすならグラフィックスカードを使いたいところです。こちらに最近のmacOS互換グラフィックスカードを紹介してあります。

macOSのためのGPUの選び方

こちらもご覧ください。

HACKINTOSHのパーツ選び【その3：グラフィックス編】10.14以降版

そのほかのパーツ

無線アダプタ、SSD, そのほかのパーツについても紹介しておきました。

/posts/138/

Hackintoshのパーツ選び【その5：SSD】

Hackintoshのパーツ選び【その6：その他】

マザーボードのBIOS/UEFIを設定する

インストール先のコンピュータを組み上げたら、macOSが稼働するようにBIOS/UEFIを設定しておきます。この設定が間違っていると、それだけで起動しない場合もあります。ただ、最近のマザーボードでは、ほぼデフォルトで大丈夫だったりします。

マザーボード (BIOS) 設定

必要なソフトウェアを入手する

Hackintoshするには、macOS本体以外にオープンソースで有志が開発しているソフトウェアがいくつか必要です。その最新版を入手しておくべきです。

必要なソフトウェアの名前で検索すれば、大抵の場合、ダウンロード先が見つかります。オープンソースのソフトウェアは、オリジナルを作った人の他に、いろいろな人がソースコードを引き継いで分岐（フォーク）して、開発を行なっている場合もあります。中には元祖の開発者が放置して、開発が止まっていることもあります。なので、検索して、現在一番活発に利用されているバージョンを使うのが良いです。ということで、古いハウツー情報のダウンロード先から入手するよりも、検索をして探すのがおすすめです。

最近はKext Updater.appというアプリケーションを使っています。Clover, OpenCore, kext類などの最新版をダウンロードしてくれます。これを使えば、一番信頼できるフォークの最新版が手に入ると思います。この他にも、Clover Configurator.appなどの設定支援アプリケーションでも、最新版が入手できる機能が備わっています。

Clover EFI bootloaderとefiドライバー

“Clover EFI bootloader”で検索します。以下が本家かと思われます。

https://sourceforge.net/projects/cloverefiboot/

Kext UpdaterのアプリケーションからBootloaderのボタンを選ぶことで、コンパイルされた最新版が得られます。Cloverをダウンロードすると、インストーラ、efiドライバ、テーマファイルなども一緒に入手できます。

kext類

FakeSMCをはじめとしたkext （カーネル拡張）が必要です。名前で検索すれば、支持されているバージョンが見つかります。例えば、FakeSMC.kextならば、”FakeSMC.kext”で検索すると、こちらで入手可能なことがわかります。

RehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket

Kext Updaterを使うと、使用しているkext類のバージョンを自動的にチェックして、最新版を入手できます。名前を指定してkext類を個別に入手することもできます。こまめに更新されているので、最新版を確実に入手することができます。

Mac上で導入用のUSBメモリを作る

macOSをインストールする一般的な方法は、macOSを入手して、インストール用のUSBメモリを作る方法です。この作業は実際のMacで作業します。ついでに、実際のMacでこのUSBメモリが起動することを確認しておきましょう。次に、インストール対象のマシンで起動できるように、Cloverのインストールと設定を行います。

Catalina導入用USBメモリーを作成する

次に、インストール先のマシンで、このUSBメモリを起動して、インストール先のドライブをフォーマットし、macOSをインストールします。インストール先マシンでUSBメモリが起動するように調整する作業が一番大変です。

macOSのインストール途中で、何度か再起動することがあります。インストール途中のCloverの起動画面で、”Boot macOS Install from (インストール先のボリューム名)”という項目を選びます。

USB 3.0/3.1のUSBメモリを使った場合、Cloverの選択画面は現れるけど、そのあとのプロセスで失敗することがあります。macOSにはUSBの個数に制限があり、3.0/3.1のポートが2.0としてしか動かない場合があるからです。対応法は以下の記事の「ポートを増やすパッチ」をご覧ください。

USBポートを設定する

ただ、USB 2.0でしたら確実に起動しますので、

USB 2.0のUSBメモリを使う
マザーボードのUSB 2.0専用ポートを使用する（全部が3.0/3.1の最近のマザーボードではこの手法は使えないです）
USB 2.0ハブを経由して無理やり2.0にする

などで対応するのが簡単です。2.0なのでインストールに時間がかかる欠点はあります。

Mac上でmacOSドライブを作る

冒頭で示した動画を含めて、多くのガイドではMac上で導入用のUSBメモリを作る方法を紹介しています。でも、本物のMacやHackintoshなどのmacOSが動くマシン（以下、親マシンと書きます）上でmacOSドライブを作ることも可能です。Hackintoshで使おうとするSATA SSDドライブ、mSATA SSDカード、M.2 SSDカードなどを、直接、もしくは、USB外付けHDDケースに入れて、親マシンに接続します。これをGUIDパーティションマップでフォーマットします。パーティションのフォーマットはHFS+でも良いですが、インストール時にAPFSに変更されるので、最初からAPFSで良いかと思います。

次にmacOSにインストーラを使ってmacOSを入れます。このドライブでちゃんと起動することを確かめておけば、問題を切り分けることができて楽です。以下の記事では、この方法でインストールしましたので参考にしてください。

9900K搭載Z390マザーボードでHackintoshを作る

Cloverとkextを入れる

USBメモリーを作ってインストール先で起動させる方法でも、親マシンでmacOSを直接インストールする方法でも、いずれの場合でも、Hackintoshを起動させるためのESP部分を作成することが1番困難な部分です。ここには、Cloverとkext類を入れます。新しいmacOSに対応していて、各種バグが改善されている最新版をダウンロードすることをお勧めします。Cloverインストールの手順はこちらにも書いてあります。

Cloverインストーラの設定

Catalinaの出る少し前に、Cloverが管理するESPの構成が少し変わりました。古い説明を読む場合は、注意してください。

CLOVER 4988 でEFIドライバ関連が変更されました

以下では、config.plistの例を示して、説明しました。

config.plistの実例紹介

config.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。

正しく機種設定する (SMBIOSの設定)

config.plistの解説では、Corpnewtさんのバニラガイドが簡潔で良いと思います。「Coffee Lakeマシンのためのconfig.plistの作り方」のページを以下で紹介しています。

corpnewtさんのバニラガイド~Coffee Lake用config.plist

Cloverをインストールしたら、次にkext類をESPの部分に入れます。kextについてはいくつかの記事で解説しましたが、こちらが簡潔かもしれません。

CORPNEWTさんのバニラガイド~ Clover設定とkext

なお、CatalinaでCloverインストーラが動かない問題もあるようです。SIPを解除すればインストールできます。こちらをご覧ください。

CatalinaにしたらCloverがインストールできない

macOS環境を整える

以上の設定で、とりあえずの起動が行えることを目指します。それができたら、さらに、グラフィックスカード、Ethernet, サウンドの設定をします。以下の記事が参考になるかと思います。

/posts/90/

Ethernetを設定する

/posts/120/

CatalinaにしたらCloverがインストールできない

Sat, 12 Oct 2019 12:14:13 +0900

CatalinaからCloverをインストールしようとすると、Cannot install without ensuring the file system is read-write というメッセージが出て、インストールできませんでした。これはSIP設定で回避できます。手作業でインストールする際には問題にならないので、将来のインストーラで対応されるかもしれません。

インストールできない

Catalinaからファイルアクセスの制限が厳しくなったと感じています。いろいろなアプリケーションにファイルアクセスの許可を出したり、ネットからのダウンロードを許可する作業などが必要になりました。システムの一部が読み出し専用になったことも関係していると思います。その影響で、インストーラでCloverをインストールしようとすると、上記のようなダイアログボックスが出てインストールできないことがあります。このようなソフトウェアインストーラは、macOS標準の「インストーラ.app」を使っています。/System/Library/CoreServices/に置かれているアプリケーションです。エラーメッセージは、このアプリケーションが引き起こしていると考えられます。

対策をネットで調べると、「リカバリーモードで再起動してターミナルからSIPを無効にすれば良い」という回答がありました。先日の記事へのコメントでも同様の方法を教えていただきました。ありがとうございます。ちなみに、リカバリーモードでSIPを解除しても、次の次の起動ではちゃんと元に戻るそうです。

r/hackintosh - Clover - Cannot Install w/o Ensuring File System is Read/Write

でもこの方法だと、インストーラを動かすまでに2回の再起動をする必要があります。手間の少ない方法を考えました。

SIPを限定解除

Hackintoshのconfig.plistで、SIPを全部外した設定をしていれば、このメッセージは出ないのかと思います。手元のマシンでは、できるだけバニラな設定にして実機と同じにしたいと考えていたので、SIPも全部有効になってました。なのでターミナルで確認すると、以下のように、SIPは全項目で有効になっていると表示されます。

% csrutil status
System Integrity Protection status: enabled.

SIPは色々な保護をしてくれますが、今回の問題に対してはファイルシステムへの制限を解除すれば良さそうです。SIPを完全に機能させている場合、config.plistのCsrActiveConfigの数値は、

<key>RtVariables</key>
<dict>
 <key>CsrActiveConfig</key>
 <string>0x00</string>
</dict>

となっていると思います。これの下位2ビット目を立てて、例えば、

<key>RtVariables</key>
<dict>
 <key>CsrActiveConfig</key>
 <string>0x02</string>
</dict>

のように書き換えれば良いです。でも、SIPを元に戻すにはまたこれを書き直すことになり面倒です。そこでCloverの起動画面のOptionから変更しました。まずは、下のメニューからOptionsを選択します。

次にSystem Parameters, System Integrity Protection (SIPのことです)と選んでいきます。SIPの設定は、config.plistで全部有効にしてあるので、設定値が0になってます。

ここでSIPの各項目を設定できるので、Allow Unrestricted FSを選びます。FSはファイルシステムの意味で、ファイルシステムアクセスの制約を外すという設定です。

これで起動すると、SIPが限定解除されています。ターミナルで確認すると、

% 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は元に戻っています。

Catalina導入用USBメモリーを作成する

Thu, 10 Oct 2019 23:37:53 +0900

CatalinaをクリーンインストールするためのUSBメモリーを作ります。まずはCatalinaに含まれるcreateinstallmediaコマンドを使います。次にESPを作ります。すでにMojaveが動いているHackintoshがあればESPのファイルをコピーするだけです。

Mojave用ESPを最新にする

Catalinaは、Mojaveの場合と同じefiドライバー、kext、config.plistでCatalinaが起動できることを確認しています。ただしどれも最新版にしておくのが望ましいです。

Catalinaにアップデートする

ということで、Kext Updater.appなどを使用して、Cloverとkext類を最新にしておきます。

Catalinaをダウンロードする

macOSが動いているマシンからAppleのサイトに接続して、Catalinaのインストーラをダウンロードします。ダウンロード後に、自動的に起動しますが、メニューから終了させます。アプリケーションフォルダにmacOS Catalinaインストール.appというアプリケーションができているはずです。

USBメモリを初期化する

インストーラ用の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に変貌してしまうので、起動作業が止まってしまうのです。

次に、USBメモリーをディスクユーティリティ.appを使って初期化します。この時、ESP (EFI System Partition) から起動可能なように、ESPが作られるように初期化します。ディスクユーティリティ.appのデフォルトではボリュームのみが表示されますので、まずは、メニューバーの表示から「すべてのデバイスを表示」を選んでおきます。

こうすると、USBメモリ製品名が入ったデバイス名がウィンドウ左側リストに現れますので、これを選択します。今回はSanDisk Extreme Mediaという製品名を選択しています。次に消去ボタンを押します。フォーマット方式の項目では、Mac OS拡張（ジャーナリング）とGUIDパーティションマップを選んでおきます。方式をGUIDにしないとESPが作られないです。ここで、最新のAPFSを選んでも良さそうな気もしますが、後のcreateinstallmediaコマンドでエラーが出ます。

実機用インストーラを作る

まずは実機（本物のMac）でも使えるCatalinaインストール用USBメモリを作ります。ターミナルを使用して、Catalinaインストーラの中に移動します。ターミナルから見ることができるmacOSオリジナルの世界では、アプリケーションフォルダは、Applications, インストーラはInstall macOS Catalina.appという名前になっています。ここでlsするとcreateinstallmediaというファイルが見つかるはずです。

cd /Applications/Install\ macOS\ Catalina.app/Contents/Resources/
ls create*
createinstallmedia

これを使用して、macOSインストールUSBメモリを作成します。とりあえず起動すると、ヘルプ情報が表示されます。

./createinstallmedia
Usage: createinstallmedia --volume <path to volume to convert>

Arguments
--volume, A path to a volume that can be unmounted and erased to create the install media.
--nointeraction, Erase the disk pointed to by volume without prompting for confirmation.
--downloadassets, Download on-demand assets that may be required for installation.

Example: createinstallmedia --volume /Volumes/Untitled

This tool must be run as root.

downloadassetsオプションは、起動用USBメモリを作成する場合に、最新ファームウェアやApple T2チップ用ファームウェアをダウンロードする機能のようです。Hackintoshでは不要な機能なので使わないでおきます。–volumeオプションでは、先ほど作成したUSBメモリへのパスを書いておきます。ということで、以下のコマンドを入力します。

sudo ./createinstallmedia --volume /Volumes/USB\ Memory/

パスワード入力の後、USBメモリを消去する確認を求められ (yを押します)、USBメモリ作成が開始します。しばらく経つと、以下のようなメッセージが出てインストーラUSBメモリが完成です。

sudo ./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 "/Volumes/Install macOS Catalina"

こうして完成したCatalinaインストール用USBメモリは、実機のMacでこれ単体で起動して、Catalinaのクリーンインストールが可能です。

Hackintoshの場合も、今までMojaveを起動していたのと同じドライブのESPから起動すれば、このUSBメモリーインストーラを使用できます。Cloverの起動選択肢に「Boot macOS Install from Install macOS Catalina」という項目が見えているはずです。これがここで作ったUSBメモリですので、これを選んで再起動します。この手順でCatalinaのインストーラが起動することを確認できます。

ESPを作成する

ドラッグアンドドロップで複製する

前のステップで、今までmacOSを起動していたESPからUSBメモリ内のCatalinaインストーラが起動したことが確認できました。そうであれば、USBメモリ単体で起動させる手順は簡単です。USBメモリのESPに、これを起動させることができたESPの内容をコピーするだけです。下のスクリーンショットでは、起動ドライブのESPの中身を、USBメモリのESPに、ファインダのドラッグ&ドロップ操作でコピーしています。

これで単体で起動するUSBインストーラが完成しました。BIOSでこのUSBメモリーから起動するよう指定すれば、USBメモリー単体で起動します。

Cloverを新規にインストールする

ドラッグアンドドロップで今までのESPを複製する代わりに、Cloverインストーラを使って新規にインストールしても良いです。結果は同じで、新規に作るので気分が多少良い程度の違いです。Cloverのインストール時に必要なefiドライバを選んでおきます。次にconfig.plistとkext類を、現行のものと同じにしておきます。ただ、SIPを有効にした状態でCloverインストーラを動かすと、現時点ではエラー表示が出て進捗しないようです。こちらの記事をご覧ください。

CatalinaにしたらCloverがインストールできない

USBメモリーから起動する

USBメモリーから起動すると、すぐにインストーラが起動するのではなく、macOSユーティリティというソフトウェアが起動します。ここから、ネットワーク設定、ターミナル、Time Machine操作、ディスクユーティリティなどが使用できますので、インストール以外にも色々と役立ちます。

まとめ

単体で起動するmacOSインストーラUSBメモリを作りました。Catalinaを対象としましたが、以前のバージョンの場合と手順は同じです。今回ご紹介した手順は、tonymacx86のサイトで配布しているUniBeastが行う作業に相当します。ただ、MojaveでHackintoshがすでに動いていることを前提にしているので、ESP部分の作成は簡単でした。

このインストーラUSBメモリがあれば、これ単体で起動してmacOSユーティリティを起動できます。ここから、ボリュームをフォーマットできるので、マシンに新規のドライブだけが接続されている場合でもインストールできます。また、ターミナルで様々な操作が可能です。macOSが起動できなくなった場合の緊急時用にこのようなUSBメモリを持っていると、復旧作業が楽です。

Catalinaにアップデートする

Wed, 09 Oct 2019 20:02:46 +0900

macOS Catalina 10.15の配布が開始されました。早速、Mojaveからアップデートしました。Cloverとkext類を最新版にすれば、時間はかかるものの通常の作業でアップデートできるようです。

アップデートの準備

昨日 (2019/10/8 JST)、macOS Catalina 10.15の配布が開始されました。例年だと1-2週間前に配布開始日がアナウンスされたのですが、今回は突然のことでした。慌ててインストールしたのですが、インストールが止まって見えてしまうトラブルがあって報告が遅れました。実は、単に時間がかかっていただけのようでした。

システムの構成

インストール先のマシンは、こちらです。

MSI B360M MORTAR TITANIUM, 9600K

これに取り付けたCrucialの1TB M.2 SSD, CT1000P1SSD8にインストールしました。

Crucialの1TB NVMe M.2 SSD (CT1000P1SSD8) を使う

光学ドライブとTimeMachine用のHDDなどが接続されているのですが、わかりやすいように一時的に取り外した状態で進めました。また、起動ボリュームは慣例に従ってMacintosh HDにしてあったのですが、これもわかりやすいようにMojaveにしました。ということで、diskutil listコマンドで見ると、次のように見えます。

$ 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のボリュームは、サイズが可変で、必要な容量に対して柔軟に対応できます。

ESPを最新にする

バニラなインストールをしているので、Hackintoshに必要なファイルは全てESPに入っています。Catalinaに備えて、この内容を最新にアップデートしておきます。開発者の皆さんが対応してくださっていますので、アップデートで発生する問題の多くは、Cloverやkextが最新版にすることで対処できます。現時点でのCloverの最新バージョンは、5070です。最新でしたのでそのままにします。次に、Kext Updater.appで使用中のkextを最新にします。手元のシステムでは、WhateverGreen.kext, IntelMausiEthernet.kext, AppleALC.kextを更新しました。更新したら、念のために再起動して、Mojaveとして起動することを確認しておきます。

新ボリューム作成

現在のMojaveに上書きアップデートしても問題ないとは思います。でも念のためにMojave環境は残しておきたいです。また、せっかくだから気持ちよくクリーンインストールしたいとの考えもありました。APFSなら、新しいボリュームを作成するのは簡単です。ディスクユーティリティ.appを開いて、Macintosh HDという名前の新しいボリュームを作成しました。（よく考えたらもはやHDじゃないですね）

念のためにdiskutilコマンドでも確認しておきました。

$ 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あるようです。

インストールする

ダウンロードするといつものように自動的にインストーラが開きます。デフォルトのインストール先は、現在起動しているMojaveになっていますが、新しく作ったMacintosh HDを選択します。

インストールが始まると、間も無く再起動します。再起動時のCloverの起動選択画面では、Boot macOS Install from Macintosh HDを選択します。デフォルトでこれが選ばれていると思います。

このあとインストール画面になります。今回の環境では、この先が長かったです。About 11 minutes remaining…という表示が出たまま、インストールが止まってしまったように見えました。小一時間様子を見たのですが、変化がありません。そこで強制終了していろいろ試したのですが、どうしても11分のところで止まってしまいました。仕方がないので、そのまま一晩放置したところ、インストールが終わっていました。単に、時間がかかっていただけだったようです。

実は以下で紹介したZ390マシンでも、同様な手順でCatalinaのインストールを並行して行いました。そちらでも、やはり11分で止まりました。でもZ390マシンはしばらくするとインストールが進みました。ということで、Catalinaへのアップデートでは辛抱強く様子を見る余裕が必要だと感じました。ちなみに本物MacのCatalinaアップデートでは、プログレスバーが停滞することはなく、割と順調に進みました。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

インストールが終了すると、再び再起動します。今度は、インストール用のボリュームは消えていて、Boot macOS from Macintosh HDに変わってます。この挙動はいつものアップデート作業と同じです。

インストール途中で、TimeMachineバックアップや他のMacのデータを転送するかどうかを聞かれます。最初の手順で、Mojaveのドライブを残してありました。これが転送元の選択肢に現れますので、これから復帰しました。クリーンインストールという観点からすると、古いデータを引き継ぐことになってしまうかもしれませんが、設定は楽です。ユーザデータは大量になるので、それ以外の設定とアプリケーションだけを引き継ぎました。ユーザデータは、古いUsers以下のディレクトリを、システム環境設定のアカウントで指定すれば簡単に引き継げるので、ここで転送する必要はないと思いました。

インストールが終了した状態で、diskutilコマンドでボリュームの様子を見てみます。インストール先のMacintosh HDに加えて、Macintosh HD – Dataという名前のボリュームができています。これがCatalinaから新しく作られたボリュームです。インストール先に指定したMacintosh HDボリュームは読み出し専用になって、保護されているらしいです。- Dataのついたボリュームに、ユーザデータを含む、書き換えするデータが置かれるようです。

% 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へは何事もなく順調にアップデートできたと思います。

kextd stallというエラーで起動しないことに対処

Sat, 05 Oct 2019 14:06:57 +0900

10.14.6追加アップデート2を入れたマシンのうち1台が起動しませんでした。APFSが原因でした。ApfsDriverLoader.efiを外して10.14.6 (18G103) 付属のapfs.efiに差し替えたら起動しました。

症状

2019年9月27日にmacOS Mojave 10.14.6追加アップデート2 (Supplemental Update 2) が配布されました。ビルドは18G103です。追加アップデートの名前の最後に2という番号がつくのは珍しいと思います。Catalinaがまもなく出るので、おそらく最後のバージョンになると思います。追加アップデートを続ける理由は、もしかしたらMojaveを10.14.6で終わりにして、バージョン番号をあげたくなかったのかもしれません。

いくつかのマシンで、アップデータ経由で通常通りの更新が問題なく可能でした。ただ、iMac19,1に設定した9600Kマシン

MSI B360M MORTAR TITANIUM, 9600K

では、どういうわけか起動しませんでした。最近は大体問題なくOSアップデートできるのですが、たまにこういう状況になるのはHackintoshの宿命で仕方ないところです。

-vオプションで調べた症状は以下のようです。Cloverのメニューは出て、メモリー確保も正しく行えるのですが、その後メッセージが続いた後、表示が止まってしまいます。しばらく経過すると画面には、

busy timeout[0], (60s): 'iMac19,1'

という表示が出ます。iMac19,1に設定したこのマシンが60秒間応答しないという意味だと思います。この状態で、キーボードを接続すると、

kextd stall[1], (60s): 'Magic Keyboard'

というような表示が出ることもあります。

また、いろいろなUSB機器を抜き差しすると、同様にkextd stallというメッセージが出ます。

原因の推測

メッセージのkextdは、kext daemonのことだと思います。kext (カーネル拡張) を読み込んでカーネルに登録する機能を担っていると思われます。stallは、自動車のエンスト（エンジンストール）と同じ単語で、応答がなくて動かない、という程度の意味でしょう。つまりメッセージから判断するに、kextデーモンが特定のkextを呼び出そうとしたけど、60秒経っても応答がないようです。

失敗しているkextはどれもmacOS本体のkextです。Clover類はESP (FAT) にありますが、macOS本体のkextは主パーティション (APFS) の中にあります。となるとAPFS (アップルファイルシステム) の読み出しに失敗している可能性があると考えました。また、上記で紹介したtimeoutメッセージも、APFSからの読み出しをする局面になって、マシンから応答がなくなりタイムアウトしたとも解釈できます。

apfs.efiで解決

CloverがAPFSにアクセスするためには、macOS本体のapfs.efiを使っています。以前はmacOSからAPFSのドライバーである

/usr/standalone/i386/apfs.efi

をESPにコピーして使っていたのですが、最近は、 ApfsDriverLoader.efiを使って、macOSから自動的に読み込んでいます。動的に読み込むことで、macOSのバージョンに合わせたapfs.efiが使えるメリットがあります。でも今回は、この仕組みが何らかの理由で機能していないようでした。そこで、EFI/CLOVER/drivers/UEFIの中の

ApfsDriverLoader.efiを削除して
macOS本体からapfs.efiをコピー

しました。すると10.14.6 (18G103) が立ち上がりました。

実際に行った手順は、もう少し複雑です。というのは、このマシンは起動しないのでapfs.efiを取得できません。そこで、別のMacにUSBメモリーを挿して、これに

cp /usr/standalone/i386/apfs.efi /Volumes/USB

のようにしてapfs.efiをコピーします。次にこのUSBメモリを、起動しないマシンに接続し、CloverのメニューからUEFI Shellを起動し、cpコマンドでESPのEFI/CLOVER/drivers/UEFIにコピーしました。また、ApfsDriverLoader.efiは、rmコマンドで削除しました。UEFI Shellの使い方は、以下をご覧ください。

起動しないマシンをUEFI Shellで救う

ApfsDriverLoader.efiが動かなかった理由は不明です。他のマシンでは18G103でも動いていますので、このマシンだけの問題かと思います。ApfsDriverLoader.efiのアップデートで解決するかもしれません。何れにせよ、起動でtimeoutやkextd stallのメッセージで止まる場合には、APFS関係を疑うと良いかと思いました。

格安のトラックパッド付き無線キーボード

Wed, 04 Sep 2019 19:45:28 +0900

macOSの操作には純正キーボードとトラックパッドがお勧めです。しかしBluetooth (BT) 接続なので、OS起動前段階のBIOSやCloverの操作で使えないことがあります。なので非常用に非BT方式のトラックパッド付き無線キーボードを調達しました。

BIOSとCloverの設定

macOSが起動する前段階で、BIOS (UEFI) の設定を変えたい、Cloverの設定を変えたい、EFI Shellを使いたいなど、キーボードを使いたい場面は多いです。ポインティングデバイスも使いたいかもしれません。そこで、macOS起動前に使用する入力装置の選択肢について考えてみます。

Bluetooth HID Proxy

以前に紹介したように、macOSの操作には純正キーボードとトラックパッドがお勧めです。特にトラックパッドで実現できるマルチタッチジェスチャは便利で、これなしでは使いやすさが売りのmacOSが台無しです。

Magic Trackpad 2は良いです

純正のトラックパッドを使うなら、キーボードもデザイン統一された純正BTキーボードを使うことになります。でもOS起動前にBluetoothキーボードを使用しようとしても動作しない場合があります。というのはBTを制御するプログラムはOSのドライバとして提供されているからです。OSの指示でペアリングをしてデータ通信を確立しています。なのでOSが起動する前の段階ではBluetoothドライバは使用できないのです。

それでは不便だということで、HID Proxyという機能が用意されています。BT入力機器と簡易的にペアリングをして、HID（Human Interface Device, 具体的にはマウスやキーボードのこと）として機能させる仕組みです。本物のMacでも、macOS起動前に、オプションキー組み合わせでNVRAMをクリアしたり、起動ドライブが選択できます。これはHID Proxyのおかげです。この機能はBluetooth受信機に組み込まれているものなので、対応していない受信機もあります。Broadcom製の純正BTアダプタは対応しています。なので、HackintoshでもApple純正BTキーボードでBIOS/Cloverの設定を行うことが可能です。

Magic KeyboardをUSB接続

とはいえ、HID Proxyは時々失敗します。特にBIOS設定画面に入れないことがあります。マシンが起動直後なので、HID Proxyの準備が間に合わないのが原因ではないかと想像しています。キーボードが接続されていないという警告をBIOS起動画面が表示する場合は、HID Proxyが動いていないと考えて良いです。

最新モデルのMagic KeyboardとMagic TrackPad 2ならば、USBケーブルで有線接続することで、Bluetooth接続がキャンセルされて、通常のUSBキーボード／トラックパッドとして使用できます。ついでに充電できます。なのでHID Proxyがうまく動かない場合は、USBケーブルを用意してマシンに接続すれば良いです。USB接続なら確実です。

話が逸れますが、USBキーボードもBIOS設定に使えなかった時期がありました。PS/2キーボードからUSBキーボードへの移行直後のしばらくの間は、USBキーボードではBIOS設定できませんでした。当時はBIOSがUSBキーボードに対応してなかったためです。なので通常はUSBキーボードを使いつつ、BIOS設定のためにPS/2キーボードが手放せませんでした。

起動前作業用のキーボード

いっそのこと、OS起動前作業専用のキーボードを用意しておくのも良いと思います。ただ、有線USBキーボードは接続に手間がかかります。有線キーボードを用意するなら、Magic KeyboardとUSBケーブルの組み合わせの方が便利です。なので、用意するなら非Bluetooth接続の無線キーボードが良いと思います。非BT接続ならば、USBドングル（コネクターに挿す小さなアダプタ）がペアリングからデータ転送までの全て面倒を見てくれます。マザーボードからはUSB有線キーボードが接続されているかのように見えます。なのでOS起動前の作業に何の支障もありません。たくさんのWindows向けの無線キーボードが、手頃な価格で売られています。これらのUSB受信機ドングルをマシンに常時接続しておいて、BIOS/Clover設定したい時だけキーボードを取り出して電源を入れれば良いと思います。

価格以外にWindows向けのキーボードを使用するメリットがもう一つあります。それはdeleteキーが使えることです。BIOS画面を呼び出すキーとして、昔からdeleteキーが使われてきました。最近ではdeleteキーの他に、ファンクションキーでもBIOS画面を呼び出せますが、メーカーによってキー対応が違います。起動時の短い時間では焦って思い出せないこともあります。deleteキーなら確実です。Appleのキーボードにもdeleteと書いたキーはありますが、実はあれはback spaceキーなので、BIOS画面呼び出しには使えません。

AliExpressでキーボードを買う

独自規格の2.4GHz無線を使用したワイヤレスキーボードは多数販売されています。Amazonで探せば安価なものが見つかります。最近はタブレットPC用の製品も多いですが、それらはBluetooth方式なので、OS起動前作業には不向きです。独自の無線規格のものを選びます。また、トラックパッドやトラックボールのようなポインティングデバイスも一体化したキーボードが便利だと思います。BIOSでポインティングデバイスが使いたいこともありますし、互換性の低いBTアダプタを使う場合には、設定のために非BTのポインティングデバイスが必要になることがあります。

これは好みの問題なのですが、英語キーボードをずっと使っています。なのでJISキーボードじゃないUS配置のキーボードが欲しいと思いました。また、EFI Shellのような玄人向けのツールでは、しばしばUS配列が前提になっていることが多いです。パソコンはもともとUS発祥の技術ですので、ディープな作業をしようとするとUSキーボードが必要になります。ところが国内ではUSキーボードはなかなか入手できません。海外でも展開しているLogicool ( Logitec ) なども、国内ではJISキーボードしか販売していません。

ということでAliExpressを探してみました。海外サイトなのでUSキーボードが多数販売されています。ロシア語、スペイン語、UKなどのキーボードもあります。無線キーボードだけでなく、本格的なメカニカルキーボードの品揃えも多いので、うっかりキーボード沼にはまってしまいそうで危険です。それで選んだ製品は以下です。

送料込みで$17くらいのタッチパネル（トラックパッド）付きキーボードです。格安ですが、問題なく動作しました。探してみたところ、日本のamazonでもそっくりなキーボードを売っていました。ちょっとだけ高いです。

一体型なので、タイピングもポインティングも1台で行えるので便利です。に似た製品です。でも日本ではUS配列のK400が入手困難なのでありがたいです。プラスティック本体が安っぽいですが、K400でも同様なので仕方ないでしょう。K400に比べると、全部のキートップが標準サイズなので使いやすいです。キーボード部分のサイズは25cm x 14cmくらいです。Magic Keyboardとほぼ同じ大きさです。K400は単3電池ですが、この製品は単4電池です。電池の持ちは悪いのかもしれませんが、スリムで片付けやすいです。

タッチパネル部分のサイズは7.2 x 7.2 cmくらいです。同じ製品らしい他の販売店のページには、macOSでタッチ操作が機能しないようなことが書いてありました。でもこれは純正のMagic Trackpadと同等では無いという意味のようです。1本指ポインティングはもちろん、2本指でのスクロール（純正のようにはスムーズではありません）や、2本指タッチでのコンテクストメニュー呼び出しなどは機能します。でもmacOSの多彩なマルチタッチジェスチャは使えません。macOSが起動したらMagic Trackpadに引き継ぐ非常用キーボードなので、単純なマウスとして動けば良いと考えました。

格安海外物なので、日本の技適（技術基準適合証明）マークが無く、厳格には国内で使用してはいけません。でも、Bluetoothは3mくらい離れると動作しない微弱な電波で、おそらくはWiFiの電界強度の1/10以下です。そのうえ電子レンジやUSB 3.1 gen2のノイズだらけの2.4GHz帯なので、数メートルも離れたら測定不可能だと思います。使用時間もOS起動前の短時間ですので見逃してもらえたら嬉しいです。

パワーマネジメント入門

Sat, 31 Aug 2019 18:17:13 +0900

以下で紹介されていた記事の抄訳です。ちなみに原題の101というのは入門とか初級という程度の意味です。アメリカの大学で初学年向け授業の科目番号が100番台で、最初に履修すべき科目番号が101であることに由来しているらしいです。

r/hackintosh - Power Management 101

これを読むとdarkwakeの設定は謎です。いろいろ検索すると、0はPower Napをしない、それ以外はするなど、多少分析しているページもありますが、試してみるしかないようです。また、sleepで再起動してしまうとか、sleepから復帰しないような重篤な状態には対処すべきですが、sleepからすぐ目覚めてしまう症状は、ある程度仕方ないような気がしています。

（以下は上記ページの抄訳です）

Hackintoshが動いたら、次にはパワーマネジメントの設定をします。このガイドは、macOSがインストールできていて、安定して使用できていることを前提としています。まずはパワーマネジメントに関連したマシンの状態を説明します。

Shutdown: macOSが終了してハードウェアへの電源供給がoffになった状態です。新しいセッションを始めるためには、電源スイッチを押します。
Hibernate: macOS はセッションの内容をRAMからディスクに書き込み、RAMの内容を消去します。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はディスクに保存した状態へ復帰します。
Hybrid: macOS はセッションの内容をRAMからディスクに書き込み一方で、RAMの内容も保持します。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はRAMから読み込まれますが、スタンバイ中に電源が途絶えてRAMの情報が消えていた場合はディスクから読み込まれます。
Sleep: macOSはセッションをRAMに保持してディスクには書き込みません。ハードウェアはスタンバイモードに入ります。キーの押下またはマウスのクリックで最後にOSを使用した状態に素早く復帰します。セッション内容はRAMから読み込まれます。スタンバイ中に電源が途絶えてRAMの情報が消えていた場合は、元に復帰できないので、新規に起動します。

以下ではターミナルを使うことになります。高度な電力制御設定をしてくれるGUIツールはありません。また管理者のみが行える設定のために、sudoやsuコマンドも使います。以下の作業で使う一番重要なコマンドは、次のものです。

pmset -g assertions – パワー状態を邪魔した原因を簡潔に示します。
pmset -g log – logからパワー状態を詳細に示します。

電力管理設定を行う前に、configでdarkwake=0フラグを指定しておく必要があります。ここで=の後にyesやnoをつけては駄目です。0から10までの数字を指定します。そしてシステム環境設定を開いて以下の設定をします。

省エネルギー > ・・・コンピュータを自動スリープさせない > （チェックする）
省エネルギー > 可能な場合はハードディスクをスリープさせる > （チェックする）
省エネルギー > ネットワークアクセスによるスリープ解除 > （チェックを外す）
省エネルギー > Start up automatically after power failure > （チェックを外す）
省エネルギー > Power Nap を有効にする> （チェックを外す）
Bluetooth > 詳細設定 > Bluetoothデバイスでコンピュータのスリープ解除を可能にする > （チェックを外す）

スリープした後で、オーディオが動かなくなる場合があります。その時は、最初にAppleALCを試してみます。次にCloverオプションのAFGLowPowerStateを使ってみます。どちらも駄目で、まだCodecCommanderを入れてなければ、これが役立つかもしれません。Darkwakeは後で扱うことにして、ここでは簡単な部分を手がけます。

この記事の最初に示したスリープの状態から、どれを使うかをまずは決めます。もし電源喪失が心配ならば、3を使います。私は安心のために3を使っています。（訳注：デスクトップの場合は0で良いと思います。）

hibernatemode=0 – デスクトップのデフォルト。基本的なスリープ（訳注：手元の10.14.6 19G95ではiMac19,1でもデフォルトが3でした。）
hibernatemode=3 – ラップトップのデフォルト。ハイブリッドと呼ばれている。
hibernatemode=25 – pmsetからのみ設定可能。伝統的なHibernate。

どれを使用するか決めたら、それを指定します。でも、この変更を有効にする電源状況も指定することになります。pmsetコマンドは、いくつかのタイプの電源に対して設定できて、それらは-a, -b, -c, -uで指定します。

-a 全ての電源を対象にする
-b バッテリー電源を対象にする
-c 充電器を対象にする
-u UPS電源を対象にする

ラップトップに対しては、-a, -b, -cのいずれかを選びます。デスクトップには-a, -uを選びます。例えば以下のようにします。. 必要ならば、それぞれの電源条件に対して、違う設定をします。デスクトップに対しては、-aまたは-uを指定します。私が使用している設定例は以下です。

pmset -a hibernatemode 3

個人的には、デスクトップには3か25を推薦します（訳注：0でも良いと思います）。ラップトップを使うなら、既に設定してある数値で良いですが、変更もできます。

スリープ時にはセッションが常にRAMに保存されます。これにより素早く復帰できます。そこでdarkwakeの設定が重要になります。darkwakeはPower Napに関係します。Power Napはスリープ中にのみ機能します。そのプロセスは、トラブルを引き起こしやすいです。一連のエラーにより、スリープが機能しなくなり、時にはカーネルパニックを引き起こします。残念ながらdarkwakeで指定する値に関する資料はどこにもありません。他の人たちと同様に、一つずつの値を、正しく動くまで試してみるしかありません。私がみるところでは、多くの人たちはdarkwake=8かdarkwake=9が最良であると言っています。私自身は、darkwake=8を使っています。darkwake=1を使う人も多いです。（訳注：コメントで教えていただきましたが、こちらに参考になりそうな説明があります。また、darkwakeの8と10はCatalinaでは使われなくなったらしいです。）

この記事の最初に示した2つのコマンドで、スリープのデバッグができます。以下は、知っておくべき項目の一部です。

Wake 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スクリプトがあります。

これで、Power Napを有効にできて、ディスプレイをoffにした時に自動的にコンピュータをスリープにする、スリープの設定ができます。電力設定は以下のコマンドで確認できます。

pmset -g live.

（私が公開するテキスト情報はCC BY-NC-SA 4.0 ライセンスに準拠します。）

ワンクリックで最新KEXTに〜Kext Updater.app (Ver. 3)

Fri, 30 Aug 2019 21:13:28 +0900

この記事は、以下の古い記事のv.3対応改訂版です。

Hackintoshで使っているClover, EFIドライバ、kext類は、最新版を使うのが良いです。色々なバグが直されていて、安定しています。また常に最新にしておけば、macOSのバージョンアップにも対応できます。Catalinaに備えていつも最新状態にしておきたいものです。ただ、開発者の方々のページを巡回して最新版をチェックするのも大変です。

Hackintoshで使用中のkext類最新版をチェックして、新バージョンがあった場合にダウンロードしてくれる便利なツールがあります。ドイツのHackintoshフォーラムの人たちが作ってくれているKext Updaterです。以下から最新版が公開されています。

この記事ではVer. 3を紹介します。古い記事で紹介したVer. 2に比べてスッキリした画面構成になりました。

ボタンがいくつかあります。以下でそれぞれのボタンが提供する機能の説明をします。

Start

メインの機能です。「Start」ボタンを押すと、使用されているHackintoshのkextを全部調べ上げてくれて、それが最新版であるかどうか判断してくれます。最新版では無いkextは、自動的にダウンロードされて、デフォルトでは、デスクトップのKext-Updatesという名前のフォルダに入ります。このフォルダはフォルダーアイコンをクリックすると開けられます。そこで、必要ならば「EFI」ボタンを押してESPをマウントして、ダウンロードした最新版と入れ替えます。

Kexts

必要なkextを個別にダウンロードします。ソースコードのダウンロードもできます。また、更新があってもダウンロードしないkextの指定もできます。

WebDriver

nVidiaのグラフィックスドライバをダウンロードします。nVidiaドライバはMojaveから使えないのが残念です。この機能をボタンに割り当てているところに、開発者の皆さんがnVidia復活に期待している様子が伺えます。

Bootloader

ブートローダーをダウンロードできます。CloverとOpenCoreから選べます。OpenCoreは、Kext Updaterと同じコミュニティの人たちが開発している様子なので、ここに含まれているのだと思われます。

Report

ハードウェアやインストールされたkext, efiドライバ類の一覧の情報を作ります。しばらく時間がかかります。kext類についての情報を得るためは、SIPで署名のないkextを許容する設定が必要です。config.plistのRtVariablesのCsrActiveConfigの下位ビットを1にします（例えば0x01）。シリアル番号などは自動的にゼロにしてくれます。このまま公開して、フォーラムで質問するときに使ってくださいという意図のようです。

レポートファイルは、/tmp/kextupdater/の下にHTML形式で作成されます。情報取得が終了すると自動的に開くので、Safariなどのウィンドウで表示されます。

Tools

4種類のツールが使えます。どういう意図でこれらのツールが選ばれたのか少し謎です。いずれもちょっと微妙な機能です。

kextキャッシュと権限修復

/System/Library/Extensionsと/Library/Extensionsにあるkextのファイル権限とkextキャッシュを作り直します。バニラなインストールをしている場合は、この機能を使うことは無いかと思います。

AtherosのWiFi機能

Atheros (現在はQualcommと合併してQualcomm Atheros, Inc.)のAR92xx/93xxのためのkextが入手できるようです。ボタンを押してみたのですが、うまく機能しないようです。AliExpressで検索してみたら、AR92xx/93xxという名前のチップには、AR9380, AR9285, AR9280, AR9271, AR9377などがあり、PCIeカードの製品や、mini PCIe (mSATA)の製品などがあるようです。ただ、最新世代のWiFiではないようです。型番の数値が大きい、少しでも最新と思われるAR9380には以下のような製品があるようです。どれも14ドルくらいと安価です。こちらを参考にすると、IO80211Family.kextの中のInfo.plistのIDを変更すれば良いようです。でもOOBで動くBroadcomを使った方が良いですね。

Sleep設定

sleepに問題がある場合、役立つかもしれませんと書かれた機能もあります。hibernationが0に設定されて、hibernation用のイメージファイルが作成されないように、書き込み禁止でサイズがゼロのファイルが作られるようです。これも押してみましたがあまり動作がわかりません。pmset -a hibernatemode = 0とタイプするのと同じことが起こるのかと思われます。

ESPをマウントする機能

ドライブを指定して、ESPをマウントしたりアンマウントできます。これは妥当な機能かなと思いました。

HackintoshでFileVaultを使う

Thu, 22 Aug 2019 23:01:31 +0900

FileVaultを使うとファイルが全て暗号化されて、パスワードを知らない人は開けなくなります。OS標準組みなので面倒な設定や手順が不要です。以前はHackintoshで使えないと言われていましたが、最近では使えるようになってました。

FileVault

FileVaultはMac OS X 10.3で登場したシステム組み込みのディスク暗号化機能です。10.7でFileVault2になりました。ちなみにvaultというのは金庫室という意味です。Windowsにも標準機能でBitLockerというツールがあるようです。どちらも多分、同様な機能を提供するツールだと思います。

今のパソコンOSはアカウントのパスワードで保護されているから、暗号化の必要性をあまり感じないかもしれません。でもアカウント／パスワードは、ネットワーク経由のアクセスには一応の役に立ちますが、コンピュータ本体を操作されるとひとたまりもありません。シングルユーザモードで起動したらなんでもできてしまいます。リカバリーボリュームで起動されても同じです。さらにはSSD/HDDを取り外して他のマシンでマウントしたら、全て読み書きできてしまいます。そんな場面でも、FileVaultで保護してあれば、パスワードが知られない限り、アクセスされる恐れはありません。FileVaultを施したSSDをマウントしようとすると、以下のように必ずパスワードを要求されるからです。

FileVaultを使うと、読み書きに暗号化・復号化のオーバーヘッドがかかるために、ファイルアクセスが遅くなる欠点があります。そのため使っている人は少ないと思います。さらにHackintoshでは使えない、つまり、FileVaultを設定した途端に起動不可能になると長年言われていました。でも、最近ではFileVaultを使うためのEFIドライバーが充実しているようです。そこで、HackintoshでFileVaultを使ってみました。

USBメモリをFileVaultする

暗号化機能は、コンピュータやドライブを何処かに置き忘れたり、盗難にあったりした時に頼りになります。逆に、家から持ち出さないデスクトップコンピュータの場合、それほど必要ではないかもしれません。デスクトップコンピュータがメインのHackintoshユーザには、使わなくても良い機能かもしれないです。私もずっと使っていませんでした。

でも、持ち歩くUSBドライブに対しては是非活用したいところです。他人の個人データが入ったUSBメモリーを電車の中にでも置き忘れたら、このご時世では大変な事案になってしまいます。暗号化されていれば安心です。非起動ディスクのFileVault化は、Hackintoshであっても面倒な準備不要です。USBメモリーをディスクユーティリティ.appでフォーマットする際に、「暗号化」と書かれたフォーマットを選択するだけです。これでHackintoshでも実機でも同様に使用することができます。

起動ディスクをFileVaultにする

さていよいよ本題です。Hackintoshの起動ディスクをFileVaultにするとどうなるでしょう？こちらで紹介したマシンに接続した起動可能SSDに対してFileVaultを有効にしてみました。起動ディスクをFileVaultにするには、macOS稼働中に「システム環境設定」「セキュリティとプライバシー」から「FileVault」タブを選択します。次にウィンドウ左下の鍵マークをクリックして、パスワードを入力し、「FileVaultをオンにする」ボタンを押します。

次に、パスワードを忘れた時の対策を選択します。iCloudを使用する方法と、復旧キーをユーザが管理する方法を選択できます。復旧キーを選択した場合は、次のステップで表示される24文字のキーを記録しておく必要があります。

この後、バックグラウンドで暗号化処理が開始されます。起動ボリューム容量に依存しますが、インストールしたばかりのmacOSなら数分で暗号化されます。これで起動ディスクがFileVaultで保護されるようになります。

本物のMacならこれで設定終了です。次に起動する場合も、FileVaultになった起動ディスクから何事もなく起動します。しかしHackintoshではそうはいきません。

HackintoshでFileVaultから起動する

起動ボリュームが見えない

FileVaultにした起動ボリュームは、Cloverの選択画面から消えてしまいます。

下のスクリーンショットは、コンピュータに2個の起動可能なドライブである、2.5 inch SATA SSDと、M.2 SSDを取り付けた場合のボリューム選択画面です。左3個のリンゴマークがSATA SSDのボリュームで、右4個のリンゴマークがM.2 SSDです。ここでは、SATA SSDがFileVault化されていて、M.2 SSDは通常のドライブです。

通常のドライブでは、右側のM.2 SSDの項目に現れているように、

Boot 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の項目には、

Boot 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ドライバが入っていないと、この選択肢を選んだとしても、通常のブート手順に至る前に止まってしまいます。

FileVaultのためのefiドライバを追加する

Boot FileVault Prebooter from Prebootを選択して起動させるためには、FileVault用のefiドライバを入れておく必要があります。最近のCloverインストーラでは、efiドライバーが機能ごとに分類分けされています。分類カテゴリーに「FileVault 2 UEFI Drivers」があります。この中にあるefiドライバーを入れておけば起動できます。ここには6個のefiドライバーがあります。それぞれクリックすると、説明が出ます。それらは、

AppleImageCodec.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が無い場合には、「ログインダイアログを開けなかった」というような内容のエラーが出て止まります。

説明を見ると、全部は必要がないように思えます。例えば、PS/2キーボードを使わなければ、AppleKeyFeeder.efiは不要なような説明になっています。でも、このefiが無い場合、USBやBluetoothキーボードからの入力ができませんでした。他のドライバには、不要なものがあるかもしれませんが、とりあえずは、6個のドライバーの全部をCLOVER/drivers/UEFI/の中に入れることでFileVaultが機能しました。

FileVaultから起動する

これらのefiドライバーをCLOVER/drivers/UEFI/フォルダに入れた後、マシンを起動します。そして、上記で説明したように「Boot FileVault Prebooter from Preboot」を選択します。ちなみに「Boot macOS Install Prebooter from preboot」を選択すると途中で止まります。名前から推測すると、FileVaultの中のmacOSをインストール・アップデートするときに使う選択肢のように思えます。（ご存知の方いらしたらコメント欄で教えてください）。いずれにしてもここでは使いません。

「Boot FileVault Prebooter from Preboot」から起動すると、すぐに通常のmacOSのログイン画面が出ます。ただ、実際のログイン画面と違って、解像度が低い画面でした。恐らくは、本物のログイン画面ではなく、Cloverが頑張って表示している画面なのかもしれません。ディスプレイドライバーが機能する前段階なので、解像度が低いと思われます。このログイン画面でアカウントを選択しパスワードを入力することで、起動ボリュームの復号化が行われます。-vオプションで様子を見ると、この後、通常の起動手順が開始されるようです。これで正常に起動し、通常通りのmacOS操作が可能でした。

まとめ

HackintoshでもFileVaultは不具合なく使用することができました。ただ、起動ドライブをFileVaultにした場合、Bluetoothキーボード／トラックパッドが認識されるまで多少時間がかかる様子もありました。また、Prebootから起動した後で、起動ボリュームの起動を行うので、起動時間は長くなります。Hackintoshに適したコンピュータは、置き忘れや盗難の危険性が少ないデスクトップコンピュータですので、Hackintoshの起動ドライブにFileVaultを設定する必要性は低いと思いました。

一方で、ノートPCでHackintoshして外に持ち出している方は（あまりいらっしゃらないかもしれませんが）FileVaultを設定しておくと安心だと思います。またデスクトップユーザも、USBメモリーなどのリムーバブルドライブに対しては、FileVaultを活用すると良いと思います。起動ドライブ以外でしたら、実際のMacもHackintoshも同じようにFileVaultを利用できます。

MSI B360M MORTAR TITANIUM, 9600K

Fri, 16 Aug 2019 22:06:46 +0900

銀色のマザーボードMSI B360M Mortar Titaniumに6コア6スレッドのCore i5 9600Kを組み合わせたHackintoshです。実機27インチiMac 2019に搭載されている第9世代CPUと同じCPUなので互換性が高いと期待しました。

ハードウェア構成

マザーボード

マザーボードはMSI B360M Mortar Titaniumです。以下で使ったものと同じマザーボードです。CPU以外の構成は変わっていません。マザーボードのBIOS設定もこの記事をご覧ください。

MSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh

300シリーズチップセットの白いマザーボードを使いたい場合は、選択肢がこれしかありません。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スロットが少ないので、十分かと思います。

CPUアップグレード

上の記事では9100Fで作りましたが、メインで使うにはもう少し上位のCPUを使いたくなり、交換しました。ゲームも動画編集もしないので、9100Fでも全く問題のない性能だったのですが、ロマンです。コア数を増やす方向でロマンを追求することにしました。9100Fは4コアです。別に9900Kマシンがあるので、同じ8コアを2台使うのも面白みがないので6コアを目指すことにしました。第9世代 (Coffee Lake Refresh-S) CPUの品揃えが増えて、中位モデルの選択肢が広がっています。6コアだと9400F, 9400, 9500, 9600Kあたりが妥当なところと思います。特に9400Fは、9500と性能がほとんど変わらないのにお得な価格で人気です。でも、現在使用中の9100Fと比べるとクロックが下がります。シングルコアしか使わない状況だとむしろ性能低下する恐れもあります。9100Fのコスパとバランスはすごいと今更ながら思いました。

Core i5 9600K

ということで選んだのは、ちょっとお高めで、第9世代では古参のIntel(R) Core(TM) i5-9600K CPU @ 3.70GHzです。これならクロック数が9100Fとほぼ同等 (0.1GHzだけ高い) でコアが増えます。

クロック数やコア数以外に、9600Kを選んだもう一つの理由は、実機の27インチiMacの上位モデルがこのCPUを採用していることです。実機で採用しているCPUを使用すると、互換性が高いメリットがあります。実機で使用されていないCPUであっても、仕様が近いモデルならば、多くの場合は動作します。それでも場合によってはconfig.plistの中でFakeCPUIDなどを設定して、macOSがサポートしているCPUに誤魔化す必要が生じます。また、実際の動作には支障はないのですが、「このMacについて」のCPU名が正しく表示されない場合もあります。iGPUのIDが違うと、これを実機に合わせる必要がある場合もあります。実機で搭載されているCPUと同一のCPUを選んでおけば、そのような手間は不要です。価格や性能に大きな違いがない候補で迷っているなら、実機で採用されているかどうかを基準に決めてしまうのも良いと思います。今回もそうしました。

ちなみに非BTO第9世代iMacが9700Kではなく9600Kを採用したのは、6コアであったのが理由だと思います。8コアCPU 9900K搭載の最上位BTOモデルを用意したので、通常モデルを6コアに差別化したかったところ、当時の第9世代にはこれしか選択肢がなかったのでしょう。

そのほかのハードウェア

グラフィックスはRadeon Vega 64です。（OOBで動作）
WiFi/BluetoothはBCM94360CD（OOBで動作）

ソフトウェア構成

OS, CLOVER, 機種ID

以下を使用しました。

macOS Mojave 10.14.6 (18G87)
Clover v2.4k r5033
iMac19,1

BIOS設定

マザーボードのBIOS設定は、ほぼデフォルトのままです。色々な項目のデフォルト設定が、macOS向きの設定でした。PCIe接続のビデオカードを使用していますが、クイックルックなどを動かすためにiGPUも稼働する設定にしました。また、ブートするドライブをUEFI限定にして、MSIマザーボードの便利な機能GO2BIOSを有効にしました。GO2BIOSは電源スイッチ長押しでBIOS設定画面が現れる機能です。

UEFIドライバ

以下を使用しています。以前のビルドではOsxAptioFix2Drv-free2000.efiを使っていましたが、slideパラメータを調節することで最新のAptioMemoryFix.efiが使えました。slideの設定はconfig.plistの項目で説明します。

ApfsDriverLoader.efi
AptioMemoryFix.efi
EmuVariableUefi.efi
FSInject.efi
VBoxHfs.efi
VirtualSmc.efi

Kext類

以下のkextをkexts/Otherに入れました。マザーボード搭載LANはインテル製なのでIntelMausiEthernet.kextを使います。AppleALCで音も出ました。HDMIからも音が出ます。

WhateverGreen.kext
VirtualSMC.kext
USBInjectAll.kext
Lilu.kext
IntelMausiEthernet.kext
AppleALC.kext

Config.plist

他の第9世代CPUで使っているconfig.plistとほぼ同じです。MSIの最近のマザーボードはmacOSカーネルを読み込むためのメモリー確保で失敗することが多いです。そこで、強制的にメモリーを解放するOsxAptioFix2Drv-free2000.efiを使っていました。今回は、以下の記事で紹介した方式を採用しました。

slideでカーネル読み込み番地を調整する (Clover編)

Boot, Argumentsにslideオプションを設定して、使用中のメモリーを避けてメモリー確保するよう設定します。さらに、slide機能を使うためにSIP機能の一部を解除しました。RtVariables, CsrActiveConfigを0x40にしてあります。

下は、SIPのNVRAM制限を解除する設定です。

<key>RtVariables</key>
<dict>
 <key>CsrActiveConfig</key>
 <string>0x40</string>
</dict>

こちらはブートオプションです。slideは128に設定しました。とりあえず使わないUSB 2.0を指定して、暫定的に15個制限を解決しています。

<key>Arguments</key>
<string>-v slide=128 uia_exclude=HS09;HS10;HS11;HS12;HS13;HS14;USR1;USR2</string>

使用したconfig.plistを以下に置いておきます。

config.plist for MSI B360M and 9600K - Pastebin.com

動作確認

以上の設定で問題なく動きました。スリープも機能しているようです。CPUも正しく認識されているようです。

sysctlコマンドでCPUの名前を見ると以下のようになります。

$ 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とほぼ同じスコアです。

今後は、USBの15個制限に対する調整を進めたいと思います。

slideでカーネル読み込み番地を調整する (Clover編)

Sat, 10 Aug 2019 00:28:14 +0900

macOSが起動するときに、早い段階で禁止マークが出て停止してしまうことがあります。多くの場合、カーネルを読込むメモリが確保できないエラーです。これをslideオプションで解決します。

追記：この記事はCloverを前提に書いてあります。OpenCoreに関してはこちらをご覧ください。またコメントいただいたように、CloverにOpenCoreのツールを流用して対応することも可能なようです。

カーネル読み込みメモリ空間を確保する (OpenCore編)

症状

禁止マークが出て早々に起動停止してしまう場合に、-vオプションで起動すると、”Error Allocating xxxx pages at xxxxxxxx”というようなメッセージが出ていることがあります。例えば下のメッセージは、「0xe590000番地から0x11c01ページのメモリー空間を確保しようとしたけど失敗しました」という意味です。1ページは0x1000バイト、つまり4096バイトのことです。10進数を使ってわかりやすく書くと、「240メガバイトあたりの番地から298メガバイトくらいのメモリー空間を確保しようとしたけど失敗しました」といった感じのエラーです。100番台になってからのMSIマザーボードでよく発生するエラーです。

このエラーの特徴は、「何回か起動を試みるとそのうち成功することがある」とか、「大抵は起動するけどたまにこのエラーで起動しない」など、再現性が低いことです。

簡単な対策法

この問題を直してくれるのが以下のefiドライバです。

AptioMemoryFix.efi
OsxAptioFix3Drv.efi
OsxAptioFixDrv.efi
OsxAptioFix2Drv-free2000.efi

以下の記事で説明したように、このリストの順番がお勧め順らしいので、上から試して、問題なく起動するefiドライバを使います。一度に2個以上のefiドライバを入れてしまうと、どちらが動くのか定まらないので避けるべきとのことです。

Cloverで使うEFIドライバ

リストの上の方ほど新しく開発されたefiドライバで副作用が少ないらしいです。一番強力なのが最後のOsxAptioFix2Drv-free2000.efiです。その名前の通りメモリーを強制的に開放させます。どのマザーボードでもほぼ機能する最強のefiドライバです。でも強力すぎるので、大丈夫なのかという意見はあります。Redditには、OsxAptioFix2Drv-free2000.efiの利用は避けて、slideオプションで対応した方が良いという意見もありました。とはいえ、私もMSIのマザーボードでOsxAptioFix2Drv-free2000.efiを使い続けていますが、特に問題はありません。でもせっかくですので、slideを使った正しい解決策を試してみます。

カーネル読込に失敗する理由

KASLR (カーネル番地乱数化)

そもそもどういうことが原因で、カーネル読み込みに失敗するのかを調べました。macOSが起動する際に、カーネルが0x100000以降の番地（10進数で1,048,576、1MB程度です）のメモリーに読み込まれます。実際に何番地に読み込まれるかは定まってなく、ランダムです。上記のエラーの例では、カーネル（またはその一部）を0xe590000番地から始まるメモリー空間に読み込もうとして失敗しています。読み込み番地はセキュリティのためにわざとランダムにしているそうです。この仕組みを、KASLR (Kernel Address Space Location Randomization: カーネル番地空間場所乱数化) というらしいです。カーネルが読み込まれる番地が常に一定だと、その番地を狙って悪さを試みるマルウェアが可能です。特定の番地からプログラムを動かしたり、特定の番地の内容を書き換えることでOS動作を操れてしまうからです。そういう操作をされないために、起動毎に違う番地にカーネルを読み込んでいるそうです。

失敗しないマザーボード

以下で説明した方法で、UEFIシェルを起動すると、

起動しないマシンをUEFI Shellで救う

マザーボードのメモリーマップを見ることができます。これに使うコマンドがmemmapです。memmap -bとすると画面いっぱいになったところで一旦停止してくれます。また、fs0:などでドライブを指定して、必要ならばcdコマンドで適当なディレクトリに移動した後、memmap > memmap.txt などとタイプすると、その場所にメモリーマップをテキストファイルで保存します。

AptioMemoryFix.efiなどの穏当なドライバで問題なく起動するマザーボードもたくさんあります。そのメモリーマップを見てみましょう。以下は、ASUSのZ390マザーボードの例です。（memmapの出力にはAttributesという項目もありますが、長くなるので省略してます。）

Type 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程度らしいのです。なので、これだけ空いていれば、どの番地に読み込んでも順当にメモリー確保できます。おかげで、このマザーボードではメモリーアロケーションのエラーが出たことはありません。

ちなみにこの空き領域の容量は、起動するたびに多少変化することがあるようです。それでも変動は高々100MB程度です。また、iGPU割り当てメモリー量を変更してもほとんど変化しません。ASUSのメモリーマップはmacOSに適しているようです。

失敗するマザーボード

一方、最近のMSIマザーボードでAptioMemoryFix.efiなどを使うと、かなりの確率で起動しません。MSIはZ170チップセットモデルからOsxAptioFix2Drv-free2000.efiが手放せなくなってしまいました。どんなメモリーマップになっているのか見てみます。以下はB350Mマザーボードのメモリーマップです。最近のMSIマザーボードでは、どれもこんな感じのメモリーマップです。

Type 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ページが空いています。

つまり、MSIマザーボードでは、0x100000番地からは、0xFF00ページ、つまり267MB程度のメモリーしか空いていません。その後に、0x10000000番地から、たったの11ページ、バイト数にして45KBだけ、誰かが使っています。BS_Codeというのがそれです。そしてその後、0x1000B000番地から0x7751AFFF番地まで大量に空き地があります。そのため、0x100000番地から300MB程度を確保しようとすると、使用中の45KBが邪魔をして確保できません。これでエラーが出ます。なんでこんな邪魔なところに使用中のメモリーがあるんだ、という気持ちになります。

ただ、何度も何度も起動を試みると、たまに起動することもあります。エラーになるかどうかは、上で説明したKASLRが使用する乱数次第です。0x1000B000より大きい番地からメモリー確保しようとした場合は、エラーは出ず、問題なく起動します。

slideオプションで解決する

slideの仕組み

config.plistなどに書くmacOSの起動オプションの中で、slide=x などと書くと、メモリーを確保する開始番地を指定できます。その規則は次のようになっているそうです。つまり起動オプションにslide=xと書くと、

最近のCPUでは、0x100000 + x * 0x200000が読み込み開始番地になります
ただし、SandyBridgeまたはIvyBridgeの場合は、xが0x00から0x7Fまでは、上記の計算ですが、xが0x80から0xFFまでの場合、0x10300000 + x * 200000になります

となることが知られてます。最近のCPUだけを考えれば、slide値を0x200000倍して0x100000を足すだけなので簡単です。以下ではこの計算が適用できるCPUを前提に説明を進めます。

空き地番地をSlideで指定する

上記のMSIマザーボードの場合、0x1000B000から、使われていないメモリーが大量にあるので、この番地以降を割り当てたいです。ということは、

0x100000 + x * 0x200000 = 0x1000B000
x * 0x200000 = 0x1000B000 - 0x100000 = 0xFF0B000
x = 0xFF0B000 / 0x200000 = 0x7F = 127

という計算になり、slide=127 （もしくはそれ以上の値）とすれば良さそうです。でもこの計算は切り捨てになっているので、実は127ではスライド量が足りません。127 (0x7F) の場合、

0x100000 + 127 * 0x200000 = 0xFF00000

からのメモリー確保がされるので、0x1000b000に引っかかってしまいます。1増やして128 (0x80) にすれば、

0x100000 + 128 * 0x200000 = 0x10100000

になるので、ようやく0x1000B000より大きな番地からの割り当てになります。つまりconfig.plistのBoot, Argumentに、以下のようにslide=128パラメタを追加すれば、このようなメモリー空き地が不連続な問題を回避できます。

<key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>slide=128 (他に必要なパラメータが続く)</string>

KASLRを無効にする

ブートオプションでslide値を指定しても、KASLRが効いているとslide値としては相変わらず乱数（0x00から0xFFまでの乱数）が割り当てられます。ブートオプションのslide値は無視されるようです。slide値を指定すると同時にKASLRを無効にする必要があります。

KASLRを無効にするためには、SIPでCSR_ALLOW_UNRESTRICTED_NVRAMフラグを立てる必要があります。これはNVRAMの変更制限を解除するフラグですが、同時にKASLRも解除されるようです。このフラグは、Appleが公開しているソースコードによると、

#define CSR_ALLOW_UNRESTRICTED_NVRAM	(1 << 6)

だそうです。1を6ビットだけ高位にシフトするという意味で、結果は0x40です。ということで、config.plistのRtVariables, CsrActiveConfigに0x40を書いておきます。

<key>RtVariables</key>
 <dict>
 <key>CsrActiveConfig</key>
 <string>0x40</string>
 </dict>

7ビット目が1ならば他の数字でも良いです。CsrActiveConfigとして、元々0x03という設定をされていたのであれば、0x43にすれば良いです。0x64という設定をしていたなら、これはすでに7ビット目が立っていますから、そのままで良いです。セキュリティをできるだけ確保するという観点からは、0x40が良いと思います。

これでブートオプションで指定したslide値が使用されるようになります。このようなconfig.plist設定で、MSIのマザーボードでもOsxAptioFix2Drv-free2000.efiを使わずに済むようになりました。AptioMemoryFix.efiで動きます。

ただ、CSR_ALLOW_UNRESTRICTED_NVRAMを許可すると、NVRAMの書き換えでSIPのすべての設定が変更可能になるので、セキュリティは脆弱になります。とはいえ、Hackintoshなのでconfig.plist書き換えて再起動すればSIPはどのようにも設定できるので、気にすることではないかもしれないです。さらにはslideパラメータでカーネル読み込みアドレスが固定されるのでKASLRの恩恵もなくなり、それも弱点になります。これに対しては、時々config.plistのslide値を微妙に書き換えて、人力KASLRしても良いかもしれません。

まとめ：マザボ別対処法

KASLRが機能していると、Slide値は0から0xFFまで乱数で設定されます。つまりカーネルが展開される先頭番地は、

0x100000 + 0 * 200000 = 0x100000 = 0番地から1MB程度先の番地

から

0x100000 + 0xFF * 200000 = 0x1FF00000 = 0番地から530MB程度先

になります。ここから、300MB程度の領域にカーネルが展開されるわけです。KASLRがどのようなslide値を指定しても、300MBのカーネルが読み込まれるためには、0x100000番地から900MB程度の空き地が必要ということになります。そこで0x100000番地からの空き地がどれくらいあるかによって次の対処法が考えられます。

なお、空き地容量の数値は、確保されるメモリーが300MB程度と仮定した場合の目安です。環境によってはもっと必要とされるかもしれません。

空き地が900MB以上あるマザボ

何もしなくて良いです。ASUSのマザーボードでは0x100000番地から1.4GBくらいの空き地がありました。なので、KASLRがどのように先頭番地を割り当てても平気です。SIPを弱めてKASLRを無効にする必要もありません。macOSに最適なメモリーマップを持つマザーボードと言えます。

空き地が300MB以下のマザボ

slideで空き地番地を指定します。MSIのマザーボードは、0x100000番地からの空き地が267MB程度しかありませんでした。次にある空き地が十分大きくてKASLRの範囲内にあるので、たまに起動しますが、大抵は起動に失敗します。このようなマザボでは、上記で説明したように、KASLRの範囲内にある300MB以上の空き地をslideで指定します。

空き地が300MB以上900MB未満のマザボ

slide=0にします。コメントで教えていただいたGIGABYTE Z390M GAMINGでは、0x100000番地からの空き地は480MBとのことです。この場合は、小さなslide値だと起動しますが（80以下程度）、KASLRで大きなslide値が指定されると失敗します。そこで、slide=0を指定して0x100000から必ず展開するように指定します。

config.plistでDSDT項目名を変更するパッチ

Sun, 28 Jul 2019 23:28:12 +0900

config.plistに「XHCIをXHCに変更」とか「SAT0をSATAに変更」などのパッチを書いている方も多いと思います。これは一体何なのか考えてみました。

DSDTのPatches

USBを設定するスクリプトであるUSBMapを試していたところ（そのうち紹介できれば良いと思い試行錯誤しています）、次のようなメッセージが出ました。

「あなたのマシンにはEC0ってのがあるけどこれはECに変えた方が良いと思う。だからESPにあるconfig.plistを書き換えてあげましょうか？」

よくわからないのでとりあえず辞退させていただきました。これは、config.plistのDSDTの中にPatchesというkeyを作って、そのarrayとして下のようなdictを追加してあげようかという提案です。

<key>Patches</key>
<array>
	<dict>
		<key>Comment</key>
		<string>change EC0 to EC</string>
		<key>Disabled</key>
		<false/>
		<key>Find</key>
		<data>
		RUMwXw==
		</data>
		<key>Replace</key>
		<data>
		RUNfXw==
		</data>
	</dict>
</array>

config.plistのサンプルには、このようなPatchesが書かれていることがあります。書かれているBase64の内容は、base64コマンドで確認できます。

echo RUMwXw== | base64 -D
EC0_

echo RUNfXw== | base64 -D
EC__

それぞれの結果はEC0_とEC__になります。コメント通り、EC0をECに変更しようとするパッチです。

この他にconfig.plist設定例でしばしば紹介される典型的な名称変更パッチには以下のようなものがあります。（変更前の名前）—>（変更後の名前）の形式で記載しました。

EC0 —> EC
XHCI —> XHC
XHC1 —> XHC
EHC1 —> EH01
EHC2 —> EH02
SAT0 —> SATA

Clover Configurator.appでもパッチを簡単に選べる機能があります。ACPI > DSDTを選択すると、パッチを選ぶメニューが出てきます。ここにはなぜかXHCに関するメニュー項目はありませんが、他にも多数のパッチ候補が表示されています。

この中からいくつかのパッチをよくわからずとりあえずconfig.plistに書いている方も多いと思います。私もよくわかっていませんでした。

パッチの目的

RehabManさんの解説などを読んで私なりに理解した理由は次のようなものです。間違っているかもしれません。私の理解が正しいのかどうか、皆さんにお聞きしたいと思い、この記事を書きました。詳しい方がいらしたら、ぜひコメントでお知らせいただけるとありがたいです。適宜修正していきます。

DSDTの項目名変更

これらのパッチは、config.plistのコメントから類推できるように、DSDTの項目名を変更する目的で使用されています。

DSDTは電源管理のための情報で、マザーボードに搭載されているハードウェアの状況が記載されています。例えばどういう名前のUSBやSATAが何本あってどう接続されているかなどが書いてあるようです。マザーボードのBIOS（ファームウェア）がこの情報を持っていて、OSに提供します。WindowsやLinuxなどのOSはこの情報を参考にしてハードウェアにアクセスします。ファームウェアが提供するDSDT情報と、これを利用するOSの関係は、同じようにEFIに基づいて設計されているMacでも同様です。Macのファームウェアがハードウェア構成をDSDTを通して提供し、macOSはそれに従ってハードウェアを制御します。

DSDTが提供する名称は、マザーボードによって違います。それがMacと同じ名前であることもありますし、違う名前のこともあります。例えば、iMac19,2のUSBコントローラはXHCIという名前ですが（最近のMac製品ならほぼ同じでXHCIです）、手元のZ390マザーボードはXHCです。

自作で使うマザーボードでの名前を、本物のMacで採用されている名前に合わせたり、あえて名前を変えたりしているのがconfig.plistで使われるパッチの役割です。上で紹介した例で、Macで採用されている名前を太字体にした対応表が以下です。

EC0 —> EC
XHCI —> XHC
XHC1 —> XHC
EHC1 —> EH01
EHC2 —> EH02
SAT0 —> SATA

EC0とSAT0に対するパッチは、Macで使われる名前に合わせるためのパッチで、残りのXHCI, XHC1, EHC1, EHC2へのパッチは、これとは逆にMacで使われている名前と違う名前にするためのパッチです。同じ改名パッチではありますが、動作が全く逆ですので、そのパッチを当てる動機も違います。

実機のMacに名前を合わせるパッチ

上記の例ですと以下の2つのパッチは、ATXマザーボードが提供するDSDTの項目名をMacで使われる名前に変更するパッチです。本物のMacにより近い設定にしたいという意図は理解できると思います。

EC0 —> EC
SAT0 —> SATA

どうやら10.11以前の古いmacOSは、DSDTの情報をあまり活用していなかったようです。どんなハードウェアが使われるか予想できないWindowsと違って、自社のハードウェアでしか動かさないOSなので、ハードウェア仕様をDSDTから得る必要がなかったのかもしれません。機種IDさえわかればハードウェアの詳細情報はわかってしまいますから。なのでこのようなパッチが必要だったようです。しかし、現在のmacOSではDSDT情報をちゃんと利用するようになったためか、この種類のパッチを当てなくても、大抵の場合、問題は発生しないようです。

例えば、手元のASUS Z390マザーボードでIORegistryExplorer.appを起動して検索したところ、SAT0という項目がありました。その一方でSATAという項目はありませんでした。

Clover Configurator.appのメニューには、SAT0 —> SATAというパッチ候補があります。これを選ぶと以下のパッチがconfig.plistに書き込まれるようです。

<key>Patches</key>
<array>
	<dict>
		<key>Comment</key>
		<string>change SAT0 to SATA</string>
		<key>Disabled</key>
		<false/>
		<key>Find</key>
		<data>
		U0FUMA==
		</data>
		<key>Replace</key>
		<data>
		U0FUQQ==
		</data>
	</dict>
</array>

これも動かしてみたところ、SAT0からSATAに正しく名称変更されました。でもSATA関連は変更前でも変更後でも全く問題なく稼働しています。

冒頭ではEC0をECに変えるようにと指示された話を紹介しました。Hackintosh用のツールでは、実機の名前になっていることを前提にして動いていることもあるのかもしれません。でも、問題が発生しなければ当てなくても良いパッチだと思います。

実機のMacの名前を避けるパッチ

以下のパッチはどれも、実機で使われるUSBコントローラの名前と違う名前に設定するためのパッチです。

XHCI —> XHC
XHC1 —> XHC
EHC1 —> EH01
EHC2 —> EH02

ATXマザーボードと実機の名前が一致しているのに、わざわざ別名にするパッチなので、なぜ必要なのか理解に苦しむと思います。その経緯は以下のようです。

上で、macOSも10.11からDSDTに書かれた情報を利用するようになったらしいと書きました。ところが一部のMacハードウェアは、あろうことかUSBに関する正しいDSDT情報を持っていなかったようです。DSDT情報をOSで利用する予定がなかったのでいい加減に記述してあったのかもしれません。本来なら正しいDSDTを提供するようにファームウェアアップデートするべきですが、それは大変なのでOS側で対応したそうです。つまり、DSDTのUSB情報が間違っているMacに対しては、macOSで用意したUSB構成情報を使用することになりました。全てのMac機種のDSDT情報を無視しているわけではなく、DSDT情報が怪しいとわかっているMac機種に関してはOSで用意した値を使っているようです。

なのでATXマザーボードが持っているUSBコントローラに、たまたまMac実機と同じ名前がついていると、DSDTが提供する情報を使わずに、macOSが用意したMac実機の情報を使ってしまう可能性があります。それを避けるために、Mac実機と違う名前に改名するのがこれらのパッチです。

このパッチも、いろいろな理由で不要な場合が多いです。

まずは、もともとDSDTのUSBコントローラ名がMacの実機と違う名前だったら名称変更は不要です。例えば手元のASUS Z390マザーボード（機種IDはiMac19,1）でIORegistryExplorer.appを起動して、XHCを検索してみたところ、名称変更パッチを当てなくても、XHCという名前で存在していました。名称変更パッチの変更対象名として使われるXHCIとかXHC1という名前の項目はそもそも存在していませんでした。このような場合は、名称変更パッチは不要と考えて良いと思います。

次に、macOSがDSDTを信用してくれる機種IDなら名称変更は不要と考えられます。例えばこちらはNUCで作ったHackintoshの例です。機種IDはMacBookAir5,1です。IORegistryExplorer.appを起動して確認すると、名称変更対象に上がっているEHC1とEHC2があるようです。その一方でEH01やEH02は見つかりません。でもmacOSは、この機種のDSDTは正しいと認識しているようで、このままでも全く問題なくUSBが認識されています。NUCはUSBの数が少ないので15個制限も問題無いようです。

ちなみに、このNUCで、

EHC1 —> EH01
EHC2 —> EH02

の名称変更パッチを当ててみるとちゃんと変更されることが確認できました。config.plistに追加したパッチは、以下のものです。

<key>Patches</key>
<array>
	<dict>
		<key>Comment</key>
		<string>change EHC1 to EH01</string>
		<key>Disabled</key>
		<false/>
		<key>Find</key>
		<data>
		RUhDMQ==
		</data>
		<key>Replace</key>
		<data>
		RUgwMQ==
		</data>
	</dict>
	<dict>
		<key>Comment</key>
		<string>change EHC2 to EH02</string>
		<key>Disabled</key>
		<false/>
		<key>Find</key>
		<data>
		RUhDMg==
		</data>
		<key>Replace</key>
		<data>
		RUgwMg==
		</data>
	</dict>
</array>

この結果EH01とEH02がIORegistryExplorer.appのウィンドウに現れました。その一方で、EHC1とEHC2は無くなりました。名称変更のパッチが効いているようです。でもどちらの場合でも、USBは問題なく機能しました。

以上のように、Mac実機のDSDT項目名を避けるパッチを当てることで、DSDTのUSB情報がありのままにmacOSに伝わり、Hackintoshの動作が安定する可能性があります。ただし最近の機種IDを設定していれば、DSDTの情報がそのまま正しくmacOSで使われるのでパッチは不要な気がします。古い機種IDであっても、MojaveのAPFS起動に対応した時にファームウェアアップデートされたので、信用できるDSDTに置き換わっている可能性もあります。なのでmacOSがDSDTを無視する必要性が少なくなったはずです。そのような状況を考えると、実機の名前を避けるパッチも、もはやそれほど必要でない気もしています。

まとめ

ということで、config.plistのDSDT Patchesの機能を考察しました。半分推測なので、間違っているかもしれません。詳しい方いらしたら、コメントで教えていただければ助かります。

まとめると、DSDT Patchesは、DSDTの項目名を変更するパッチでした。改名結果はIORegistryExplorer.appで確認できました。改名するとDSDT情報が正しくmacOSに伝わり、Hackintoshの動作が安定する可能性があります。ただし最近では、パッチの必要性が下がっている気がします。使用しているマザーボードのDSDT項目が、パッチ対象の名前かどうかを調べておいて、パッチ対象の名称であった場合は、何か問題があった時に名称変更のパッチを試すのが良いと思います。

Crucialの1TB NVMe M.2 SSD (CT1000P1SSD8) を使う

Fri, 26 Jul 2019 01:16:55 +0900

NVMeプロトコルのM.2 SSDが安くなっています。1TBでも1万円代前半です。ということでCrucialのお安い1TB M.2 SSD, CT1000P1SSD8をmacOSで使ってみました。問題なく動作し性能もそこそこ良いです。

SSDが安くなった

メモリーの価格が下がっている関係か、M.2 NVMe SSDも安くなっているようです。以前は、1TBだと結構なお値段だったのですが、セールだと1万円を切ってたりします。以下はその時のスクリーンショットです。

残念ながら現在の価格は1,400円ほど上昇して11,323円ですが、それでも1TBでのこの価格は、ちょっと前なら考えられなかった状況です。ただし、品薄のようで納期が長いです。（この記事の執筆時の状況です。現在の価格、納期は下のリンクから確認してください。）

マザーボードに取り付け

ということで、このSSDをmacOSで動かしました。使用したハードウェア構成は以下です。マザーボードはMSIのB360搭載Micro ATXです。SATAコネクタに接続した2.5 inch SATA SSDでmacOS Mojaveが問題なく動作しています。

MSI B360M Mortar Titaniumと9100Fで作る格安Hackintosh

CT1000P1SSD8JPをマザーボードのSSD用M.2ソケット（CPUのすぐ隣の方のソケット）に取り付けました。廉価版のB360マザーボードなので、M.2 SSD用のヒートシンクは用意されていません。なので別途ヒートシンクを用意しました。CPU隣のM.2ソケットは、PCIe拡張カードに干渉しない場所にあるので、背の高いヒートシンクを取り付けられます。大型の空冷CPUクーラを使わなければ、ケースの高さまで上空が空いています。ギリギリの高さまでヒートシンクとしたいところです。そこで入手し得る限り背の高いヒートシンクを探して取り付けました。以下の製品で高さは3cmあります。マザーボードがチタン色なのでシルバー（塗装無しアルミ）版を購入しましたが、黒いマザーボードをお使いならブラック（塗装ありアルミ）版が合うと思います。

Amazonの写真では、取り付けゴムが輪ゴム色（ブラック版は白色）で多少微妙でしたが、実際に届いた製品には白い耐熱ゴムでした。マザーボードに取り付けるとこんな感じです。それほど違和感はありません。CPUのリテールクーラと比べると、背の高さがわかるかと思います。このM.2 SSDも他製品と同様に、酷使するとコントローラチップが発熱します。でもこれだけの熱容量のあるヒートシンクだと、穏やかに暖かくなる程度でした。

フォーマット

M.2 SSDをマザーボードに取り付けたら、ディスクユーティリティ.appでAPFSでフォーマットします。HFS+でフォーマットしても良いですが、macOSをインストールする際に結局はAPFSに自動変換されると思います。以前だとシステム用とデータ用にパーティション分けしたりしていたのですが、今はAPFSのコンテナ機能により柔軟にボリューム作成できるので、ちまちまとパーティション分けするのはやめました。ということで1TBを丸ごと一つのパーティションにしました。ディスクユーティリティ.appでは、M.2 SSDを選んで「消去」ボタンを押します。この操作により、SSD全体を占める1パーティションが作られ、その中にコンテナが一つ出来上がり、コンテナにボリュームが1個追加されます。macOSの伝統に従って、ボリューム名はMacintosh HDにしました。APFSコンテナなので、将来、このコンテナにデータ用のボリュームを新設・追加することが容易です。そうすれば、システム用とデータ用の2つのボリューム構成になり、macOSをクリーンインストールするときに便利になります。

Mojaveのインストール

現用の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の動作を確認します。

ESP内容のインストール

次に、現用の2.5 inch SATA SSDと、M.2 SSDの両方のESPをマウントし（それぞれ/Volumes/EFIと/Volumes/EFI 1としてマウントされるはずです）、2.5 inch SATA SSDの内容をM.2 SSDに、ファインダーのドラッグ&ドロップ操作でコピーします。あとはBIOSでM.2 SSDを起動ドライブに設定するだけで、macOSが起動しました。

システム環境で確認

システム情報を開いてM.2 SSDの動作を確認しました。TRIMが有効になっているようです。しばらく使用しましたが、特に問題はありませんでした。Crucialの格安のSSDがmacOSで使用できることが確認できました。

速度測定

この格安SSDは自作PCユーザの間で評判のようで、Windowsで測定した速度がいくつかのページで紹介されています。例えば、以下のページです。

QLC型NVMe M.2 SSD「Crucial P1 1TB」をレビュー。SATA SSDに近い容量単価でSATA S…

これによるとCrucialの1TBモデルは、メーカー発表の仕様書通りの性能を発揮して、Readが2000MB/s, Writeが1700MB/sのようです。Windowsベンチマークでよく使われるCrystalDiskMarkに近い動作をするmacOS用の AmorphousDiskMark.app を使って速度を測定しました。その結果、仕様書通りの性能が得られました。macOSでもこのSSD本来の性能を活かせているようです。

新ブートローダーOpenCoreを使う

Sat, 20 Jul 2019 16:30:07 +0900

OpenCoreはCloverから分岐し、OZMOSISの流れを取り込んだ新しいオープンソースのブートローダーです。Z390マザーボードで動かしたところとりあえずはmacOSが起動しました。

追記：最近のOpenCore関連の記事もご覧ください。

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

OpenCoreとは

OpenCoreは、完璧にオープンソースであることが特徴の新しいブートローダーです。Cloverから分岐し、OZMOSISの流れを取り込んでいます。OZMOSISを開発していたドイツのHackintosh-Forum.deの人たちが開発を進めているようです。OZMOSISってどんなものだったかと言うと、ファームウェア形式のブートローダーで、マザーボードのBIOSを置き換えて動作します。OZMOSISをマザーボードのBIOS更新機能を使ってインストールすれば、普通のマザーボードがmacOSを直接起動できるマザーボードに変身します。macOSもmacOSインストーラも実機と同様にそのまま起動できるという理想を追ったブートローダーだったのですが、調整やアップデートのたびにBIOS更新作業をするのは大変でした。ChameleonやCloverみたいにドライブの一部に書き込む方式の方が色々楽です。ということでOZMOSISはあまり流行りませんでした。開発チームもそれを認識して、今度はClover方式のブートローダーを作ることにしたのだと思われます。

使用したハードウェア

OpenCoreを試したハードウェアは、以下で紹介したZ390マシンです。モデルIDはiMac19,1で、macOS Mojave 10.14.5です。

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

ここで使っているkextは

AppleALC.kext
IntelMausiEthernet.kext
Lilu.kext
USBInjectAll.kext
VirtualSMC.kext
WhateverGreen.kext

です。efiファイルは大半がClover 5018で配布されているものです。

ApfsDriverLoader.efi
AptioMemoryFix.efi (これはKext Updater.appで入手)
FSInject.efi
VirtualSmc.efi （VirtualSMC.kextに同梱されているもの）
VBoxHfs.efi
EmuVariableUefi.efi

またUSBInjectAll.kextで使うためのSSDTファイルも使っています。こちらで作成したものです。これがSSDT-UIAC.amlという名前です。

OpenCoreを入手する方法

いろいろな方法がありますが、一番お手軽なのは最近のKext Updater.appを使う方法です。Kext UpdaterもOpenCoreを作っている人たちが活躍しているHackintosh-Forum.deで作られていますので、その関係でOpenCoreダウンロード機能が実装されているのだと思います。Load Bootloaderのラジオボタンを選択して、右のポップアップメニューからOpenCoreを選択します。

ダウンロードすると、Kext-Updatesフォルダの中にOpenCoreというフォルダができて、この中にデバッグ版とリリース版

OpenCore-0.0.4-DEBUG
OpenCore-0.0.4-RELEASE

のフォルダが出来ています。今回はRELEASE版を使ってみましたが、DEBUG版の方がより多くのエラーメッセージを出してくれるらしいです。

ESPディレクトリ構築

Docsフォルダの中には、とても詳しい取扱説明書が入っています。Cloverにはあまりなくて、ネット上のマニュアルも古かったりします。説明書を一緒に配布してくれているのは助かります。まだちゃんと読んでませんが、必要な情報は全部書いてあるのではないかと思います。マニュアルによると、構築すべきディレクトリ構造は以下の通りのようです。

グレーの項目は任意の項目です。なので、EFIの下に、BOOTとOCを作って、OCの中のDriversにefiファイルを、Kextsにkextファイルを入れれば良いようです。またOCの中にconfig.plistを置きます。名前がOCになっただけで、CloverのESP配置とだいたい同じです。この図に従ってESPの中にディレクトリを用意し、DriversフォルダとKextsフォルダに上記のefiファイルとkextファイルを入れました。またACPIフォルダにSSDT-UIAC.amlを入れました。

config.plist編集

Docsフォルダの中に、マニュアルと一緒にconfig.plistのサンプルファイルも入っています。名前が、Sample.plistとなっています。今回はこのファイルをもとに動かしてみました。まずはSample.plistをconfig.plistに名称変更します。そして以下の手順で書き変えました。

SMBIOS設定

まずは機種設定からです。どうやらPlatformInfoの中のGenericの中が機種設定関連のようです。この部分のMLBがCloverでのBoardSerialNumberに対応し、SystemProductNameがProductNameに、SystemUUIDがSmUUIDに対応するようです。それぞれの値を書いておきます。

	<key>MLB</key>
	<string>C02921130GULNV9JA</string>
	
	<key>SystemProductName</key>
	<string>iMac19,1</string>

	<key>SystemSerialNumber</key>
	<string>C02YR2YHJV3Q</string>

	<key>SystemUUID</key>
	<string>E45005B4-95C7-4B0C-9739-30947DDEB37C</string>

FileVault設定

この状態で起動させようとしたところ、FileVaultの用意ができていないというような内容のメッセージが出て起動が中断しました。config.plistを見ると、MiscSecurityの中にFileVaultらしい設定があり、有効にされているようです。ここのtrueの部分2箇所をfalseに書き換えました。これでメッセージが出なくなりました。

<key>Security</key>
	<dict>
		<key>ExposeSensitiveData</key>
		<integer>2</integer>
		<key>HaltLevel</key>
		<integer>2147483648</integer>
		<key>RequireSignature</key>
		<false/>
		<key>RequireVault</key>
		<false/>
		<key>ScanPolicy</key>
		<integer>983299</integer>
	</dict>

efi設定

次に、HFSPlus.efiが見つからないというメッセージで起動が中断されました。最近はAPFSになって、HFS+での起動は使わないので、上記のリストのようにCloverデフォルトのVBoxHfs.efiを使っていました。なんでこのメッセージが出るのかと思ったらconfig.plistのUEFIDriversの中にefiファイルの一覧が書いてありました。フォルダに入れるだけでなくconfig.plistにも書いておくようです。FileVaultに関係したefiファイルも入っています。これらのリストを、実際に使っているefiファイルに書き換えました。

<key>UEFI</key>
<dict>

	<key>Drivers</key>
	<array>
		<string>VBoxHfs.efi</string>
		<string>ApfsDriverLoader.efi</string>
		<string>EmuVariableUefi.efi</string>
		<string>FSInject.efi</string>
		<string>AptioMemoryFix.efi</string>
		<string>VirtualSmc.efi</string>
	</array>

kext設定

ほかも見てみると、KernelAddの場所に、kextに関する記載もあります。この記述順にロードされるようなので順番も大事なようです。

IntelMausiEthernet.kextの名前が違っている（IntelMausi.kextになっている）のとEnabledされていないようなので、修正しました。

<dict>
	<key>BundlePath</key>
	<string>IntelMausiEthernet.kext</string>
	<key>Comment</key>
	<string></string>
	<key>Enabled</key>
	<true/>
	<key>ExecutablePath</key>
	<string>Contents/MacOS/IntelMausiEthernet</string>
	<key>MatchKernel</key>
	<string></string>
	<key>PlistPath</key>
	<string>Contents/Info.plist</string>
</dict>

また、USBInjectAll.kextの記述も追加しました。順番が大事のようです。arrayの最初の方に入れたら動きません。arrayの最後に追加しました。

 <dict>
 <key>BundlePath</key>
 <string>USBInjectAll.kext</string>
 <key>Comment</key>
 <string></string>
 <key>Enabled</key>
 <true/>
 <key>ExecutablePath</key>
 <string>Contents/MacOS/USBInjectAll</string>
 <key>MatchKernel</key>
 <string></string>
 <key>PlistPath</key>
 <string>Contents/Info.plist</string>
 </dict>

SSDT設定

使用するSSDTもconfig.plistで指定する必要があるようです。今回は、SSDT-UIAC.amlを使います。そこで、ACPIAddのarrayの中に、

 <dict>
 <key>Comment</key>
 <string>USB list for USBInjectAll</string>
 <key>Enabled</key>
 <true/>
 <key>Path</key>
 <string>SSDT-UIAC.aml</string>
 </dict>

を追加しました。

動作確認

BIOSでOpenCoreをインストールしたドライブを選択すると、Cloverと同様に起動ボリュームの選択画面が出ます。テキストだけのシンプルな画面です。ここで10.14.5の入ったMacintosh HDを選択しました（この例ではキーボードの5を押す）。この後、設定に不備があると上記のようなエラーメッセージが出ることもありますし、起動が停止することもあります。

でも、ここまでの設定で、なんと起動しました。config.plistで手付かずの項目がいっぱいあるのに、とりあえず起動したのは意外でした。よかったです。

使用したconfig.plistを以下においておきます。

OpenCore config.plist for Z390 - Pastebin.com

動くこと

画面が出て動作します。Radeon RX 580が正しく動きます。IntelMausiEthernet.kextも動きます。なのでLAN接続ができます。またBroadcomの純正WiFiも動きます。

USBInjectAll.kextと自作のSSDTの組み合わせで、USBの取捨選択ができています。15個制限問題を解決できています。

動かないこと

シャットダウンすると画面は消え、シャットダウンプロセスが実行されるのですが、電源が切れるところまで行き着きません。電源スイッチを長押しして強制的にoffにする必要があります。その影響で次の起動の時にBIOS表示で警告が出ます。ACPI関係の設定が足りないのだと思います。

OpenCoreに行くべきか？

ということで、OpenCoreでの起動を確認できました。今後は、USBの指定方法や、今回見た以外のconfig.plistの設定など、マニュアルや検索して調べて見たいと思います。

ではCloverをやめてOpenCoreに移行すべきでしょうか。OpenCoreの人たちは、以下のようなメリットを訴えています。

完全にオープンソースなので安心
設計が新しい

確かにCloverは開発過程がそれほどオープンになっていないので、わかりにくいところがあるかと思います。ロシアで開発されているCloverとドイツで開発されているOpenCoreでは、偏見かもしれませんが、なんとなくOpenCoreに安心感を感じます。開発がオープンなのでHackintoshの主流がOpenCoreに移行していく可能性は高いです。でも今現在では、Cloverに関するノウハウが大量にネットにありますし、しばらくはCloverが使われると思います。

主流ブートローダーは、数年前にChameleonからCloverに交代しました。ただ、この交代では、レガシーなMBR (マスターブートレコード)からESPに対応すること、起動時に動的にパッチを当ててくれる機能、macOSとの相性が良くなることなど、いくつもメリットがありました。CloverからOpenCoreに変えても、目に見えるメリットはないので、移行は緩やかかもしれません。CloverからOpenCoreに移行したらグラフィックスカードの動作が安定したと言う情報も見かけました。今後どうなるにしても、選択肢が複数あることは良いことです。

CLOVER 4988 でEFIドライバ関連が変更されました

Sat, 13 Jul 2019 22:14:47 +0900

新しいClover 4988が公開されたので深く考えずに更新しました。そしたら起動しなくなりました。EFIドライバの管理方法がいろいろ変更になったようです。

（EFIドライバの古い情報は以下に書いてあります。今でも参考になる部分はありますので、ご覧ください。）

Cloverで使うEFIドライバ

EFIドライバの管理方法

4988では、拡張子が.efiのEFIドライバーの管理方法が変わったようです。Cloverインストーラの選択肢もグループ分けされています。その影響なのか、次に述べるEFIドライバの格納フォルダ名が変更になった影響なのかわかりませんが、前回のインストール情報が継承されていないようです。単にアップデートすると全てのEFIドライバが非選択になっています。そのままインストールすると、EFIドライバが足りない状態で起動しようとして、当然ながら起動に失敗したようです。

もともと私のマシンでは、前のバージョンのClover 4972以前で、以下のようにEFIドライバを設定していました（6個です）。
補足：この6個のうち、SMCHelper.efiはFakeSMC.kextと一緒に使用するためのEFIドライバだそうです。VirtualSMC.kextを使用する場合はこれは不要らしいです。VirtualSMCを使用する場合は、VirtualSMCと一緒に配布されているVirtualSmc.efiを使用するのが正しい方法らしいです。

この状態で、4988を自動的にインストールしようとすると、以下のようになりました。ApfsDriverLoader-64以外が全部消えてしまいました。たまたまこれが残されたのは、新バージョンで名前から64が外れたためのようです。driversという新しいフォルダができていますが、こちらは空っぽです。このままでは起動しません。

インストーラでEFIドライバを選択し直さないといけないようです。以下のようになりました。このスクリーンショットではわかりませんが、グループ分けされたEFIフォルダの中から上記の6個を選択してあります。

その結果以下のようにインストールされました。driversのフォルダの中に、UEFIというフォルダが作られて、その中にEFIドライバーがインストールされるようです。ちなみに古いdrivers64UEFIフォルダはもはや使われていないようで、削除しても大丈夫でした。これで起動するようになりました。

新オプションDrivers off

4988のインストーラにDrivers offというオプションが追加されています。説明によると、利用可能な全てのドライバをEFI/CLOVER/drivers/off/にインストールするそうです。offフォルダは名前の通り使用されないドライバの置き場所で、ここに全てのドライバを入れておけば、必要になった場合にEFI/CLOVER/drivers/UEFI/にコピーして使えます。

これを選択すると、説明通りdriversフォルダの中にoffフォルダが作られて、その中に大量の (33個) ドライバが入ります。インストールしなかったドライバを試したい場合に便利です。こちらで紹介したようにEFI SHELLでmvコマンドで操作することもできるでしょう。offフォルダの中身の合計（ドライバの総容量）は815KBです。ESPの容量（200MB程度）からして負担になる量ではありません。

AptioMemoryFix-64が消えた

macOSカーネルを読み込むための連続メモリ領域確保を支援するAptio系のEFIにも変更があります。インストール画面からおなじみのAptioMemoryFix-64.efiが消えて選べません。

上記のoffフォルダを見ていただくとわかるように、こちらにも存在しません。ドイツ語のHackintosh-forumにはいち早く説明が書いてありました。英語に翻訳したURLは以下です。AptioMemoryFixは新しいドライバなのですが、CLOVERの開発者チームの作ではないので、同梱されなくなったようです。

今回は代わりにOsxAptioFix3Drvを使用しました。問題なく使えました。なお、フォーラムでいただいた情報によるとAptioMemoryFix-64.efiの-64を名前から外して、新しくできたdrivers/UEFIに入れれば動くらしいです。でも同梱されたドライバで問題ないならばその方が整合性の点で良いかと思いました。

またAptioMemoryFix.efiの最新版はKext Updater.appからも入手できます。こちらからは-64の名前のない、最新版が入手できます。これを利用しても良いと思います。

レガシーインストールが選べない

これはEFIドライバの話だけではありませんが、MBR (マスターブートレコード）にインストールするレガシーBIOSの方法がインストーラで選択できなくなっています。レガシーブートは手作業でインストールすれば可能かもしれません。でも自動的にインストールできるのはUEFIブートだけになりました。下は4972のインストール画面です。

これに対して下が4988のインストーラです。MBR, PBR（パーティションブートレコード）へのインストールオプションがなくなりました。

最近はMBRしかサポートしないレガシーなマザーボードはほとんど見当たらなくなりましたし、わかりやすくなって良いのかもしれません。

まだいろいろ変更されたことはありそうです。AptioMemoryFixがなくなったので、Aptioシリーズの選択方法も再検討すべきかもしれません。この記事に加筆していきたいと思います。

tonymacx86式インストール手順 (その1: UniBeast)

Sun, 30 Jun 2019 15:33:31 +0900

tonymacx86のツールUniBeastを使って、単体で起動できるmacOSインストーラUSBメモリーを作成する方法を、Hackintosh初心者向けに紹介します。tonymacx86で開発配布されているツールにUniBeastとMultiBeastがあります。どちらもHackintosh初心者によく使われています。そこで、3つの記事で、以下の手順：

その1：UniBeastを使って単体で起動するmacOSインストーラUSBメモリーを作り、これを使ってmacOSをインストールする。
その2：MultiBeastを使ってCloverやkext類をインストールし、macOSを起動できる状態にする。
その3：kextの場所とconfig.plistを修正してバニラ化してチューニングする。

を説明します。この記事は、その1です。その2、その3は以下の記事です。

tonymacx86式インストール手順 (その2: MultiBeast)

tonymacx86式インストール手順 (その3: バニラ化と調整)

UniBeast

UniBeastはtonymacx86.comで作られて配布されているHackintosh作成ツールです。単体で起動するUSBメモリーを作成します。

UniBeastが行うことは、

macOSがMacで起動するUSBメモリーを作成する
これにCloverをインストールする
これに必要なkext類をインストールしてconfig.plistを作成する

という3つの作業です。1番の作業は、通常のMacユーザも行なっている作業です。Appleのサイトにも丁寧な説明があります。

macOS の起動可能なインストーラを作成する方法

2番目の作業は、Cloverを入手すれば、そのインストーラが行ってくれる作業です。インストール時のオプション選択には多少の知識が必要です。3番目の作業はUSBメモリーのESP (EFI System Partition)をマウントして、適切なkextファイル追加し、config.plistを正しく編集する作業です。このように2番目3番目の作業には、ハードウェア構成に関係したいろいろなノウハウが必要です。でも、それを知らなくても無難に起動できるUSBメモリーを作成してくれるところがUniBeastの便利なところです。

作業の準備

まずは、macOSが動いている環境（MacもしくはHackintosh）が必要です。これに、インストールしたいmacOSのインストーラをAppleのサイトからダウンロードしておきます。具体的な方法は上記のアップルのサイトに説明があります。この作業で、アプリケーションフォルダにmacOSインストーラが保存されます。

次に、UniBeastをtonymacx86からダウンロードします。macOSのメジャーバージョン別に用意されています。この記事の時点での最新はMojaveです。

12GB以上（Appleのサイトの情報）の容量のUSBメモリーを用意します。これをGUIDスキームでMac OS 拡張フォーマットでフォーマットします（どちらもディスクユーティリティ.appのデフォルト設定です）。

UniBeastで起動USBメモリーを作成

macOSインストーラがアプリケーションフォルダにあり、フォーマットしたUSBメモリが挿されたmacOSマシンで、UniBeastを起動します。言語が英語になっていないと起動しないので、必要ならばシステム環境設定の「言語と地域」から英語に設定しておきます。

UniBeastを起動して注意事項のページを経ると、USBメモリーを選択する画面になります。ここで、対象のUSBメモリーを選択します。内容はこのあと削除されるので、選択を間違えないでください。

次にmacOSインストールファイルの選択です。AppleのサイトからMojaveをダウンロードするとmacOS Mojaveインストール.appというインストーラプログラムがアプリケーションフォルダに出来上がります。UniBeastはアプリケーションフォルダにあるインストーラを表示しますので、選択します。

次にESPにインストールする (UEIF Boot Mode) か、macOS本体パーティションにインストールする (Legacy Boot Mode) かの選択肢が出ます。Cloverのインストーラを使う場合でもこの選択を問われます。この先、バニラなインストールを目指すので、混乱しないようにここもUEFI Boot Modeを選択しておきます。

次にグラフィックスのオプションを聞かれます。ここに出ているNvidiaとAMDのグラフィックスカードを使用する場合はチェックを入れます。いずれもかなり古いカードですので、チェックを入れる必要のある場合は少ないと思います。

このあと確認のウィンドウが出て、USBメモリー作成作業が始まります。USB 3.1 Gen1接続で3分くらいかかります。完成すると以下のメッセージが表示されます。

BIOSを設定する

macOSをインストールしようとしている対象のマザーボードのBIOS設定を、macOS向けに設定しておきます。最近のマザーボードではほとんどデフォルトで大丈夫ですが、一応チェックしておいてください。

USBメモリーで起動する

このUSBメモリーを、インストール対象のマシンに取り付けて起動します。大抵は、USBからの起動を優先するBIOS設定をしていないと思います。その場合は、起動時にBIOS画面でUSBメモリーを指定する必要があります。

USBメモリーから起動すると、Cloverの起動ドライブ選択画面が出ます。ここで、USBメモリーを選択します。

UniBeastの設定は、かなり汎用的な設定になっているようで、起動する成功率は高いです。今回は、ASUSのZ390マザーボード、Radeon RX580、macOS 10.14.5 Mojaveの組み合わせで実験したところ、とりあえずはインストーラが起動しました。tonymacx86で推奨されているハードウェアならインストーラ起動までは進めるのではないかと思います。

この後、言語を選択して、macOSのインストールを開始します。すると3-5分程度でインストール用イメージが用意され、再起動します。この時もUSBメモリーから起動します。Cloverのブート選択に、「Boot macOS Install from xxxx」という項目が増えているはずです。これを選択します。

この後、もう1回くらい起動します。その時も、Cloverのブート選択に「Boot macOS Install from xxxx」という選択肢があればこれを選択します。インストールが最終段階になると、この選択肢は消えて、「Boot macOS from XXXX」という項目が現れます。これを選択すれば、macOSのアカウント設定などの画面を経て、インストール終了です。

こんな感じでインストールされます。config.plistでiMac14,2と設定されているのでiMac Late 2013になっています。

実は、今回のハードウェア構成で試したところ、以上の手順ではmacOSインストール途中で失敗しました。そこで、次にUniBeastが作るESPの構成と、トラブル対策を紹介します。

UniBeastが作るESP

トラブル対策を説明する前に、まずはUniBeastにより作られるESPの中身を見てみます。多くのハードウェアで機能するためにNullCPUPowerManagementなどの汎用性を高めるkextなどが使われているのかと思ってましたが、使われていませんでした。標準的でシンプルな作りでした。

efiドライバー

drivers64UEFIフォルダには以下のefiドライバが入っています。無くても問題のないドライバも含まれていますが、Cloverのデフォルトに準じた一般的な構成です。必須もしくはあった方が良いドライバは、太字にした5個くらいかと思います。後で説明しますが、今回のマザーボードでは、これらのefiに加えてEmuVariableUefi-64.efiが必須であることがわかりました。

ApfsDriverLoader-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が使われています。

AtherosE2200Ethernet.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オプションを追加しておくと、トラブル特定に役立ったのではと思いました。

config.plist by UniBeast 9.2.0 - Mojave - Pastebin.com

KextToPatchではUSBポートの15個制限を回避するパッチが書いてあります。ただこれはmacOS 10.14.4用のパッチですので、今回使用した10.14.5では使えません。他のバージョンにパッチを試みて不具合が起きないように、MatchOSキーで10.14.4以外では機能しないように設定してあります。USB個数制限を回避するためにパッチを当てる方法は、どのマザーボードでも動くので楽なのですが、macOSバージョンごとにパッチを変更する必要があります。あまりお勧めではありません。詳しくはこちらをご覧ください。

SMBIOSではiMac14,2に設定されています。シリアル番号などは指定されていません。Cloverが適当に設定してくれます。

トラブルとその対策

インストーラUSBメモリが完成したら、インストール先マシンで起動して、macOSをインストールします。その過程で発生しうるトラブルを時系列で解説します。

メモリー確保の失敗

メモリー確保失敗は、Cloverで起動ドライブを選択して起動プロセスが開始した直後に発生します。-vオプションをつけていないと、白いリンゴマークに代わって禁止マークが出ます。-vオプションをつけていれば、kernel読み込みのためのメモリーの確保 (allocation) に失敗したというメッセージが読み取れます。

今回使用したASUSのZ390マザーボードは、AptioMemoryFix-64.efiで、メモリー確保に成功します。GigabyteのZ390もこのefiファイルでOKのようです。MSIとASRockの300シリーズはAptioMemoryFix-64.efiで失敗するという報告が多数あります。メモリー空間を強制的にクリアするので副作用が心配ですが、OsxAptioFix2Drv-free2000.efiを使えば良いようです。詳細は以下をご覧ください。

Cloverインストーラの設定

USB個数制限問題

USB個数制限による失敗はmacOS（ここではmacOSインストーラ）が起動するプロセスの中盤以降で発生します。-vオプションをつけていないと、白いリンゴマークに代わって禁止マークが出ます。-vオプションをつけていると、メッセージが突然停止します。メッセージの表示が崩れることもあります。

macOSにはUSBの個数が15個までの制限がありUSB 2.0が優先されます。また、USBInjectAll.kextが入っていない場合、全てのUSB 2.0が確実に見えるわけでもなく、取りこぼしされることもあります。ということで、USB 3.0 (最近の表記で正しく書くとUSB 3.1 Gen 1) を使用しようとすると、かなりの確率でmacOSからは読めません。USB 2.0でも見えないことがあります。

マザーボードのBIOSが制御している段階では、全てのUSBメモリーが見えています。なので、起動ドライブとして選択できるし、Cloverの起動ドライブ選択画面も出ます。しかし、その後、macOSに制御が移管されるタイミングで運悪く15個の個数制限に引っかかると、起動の途中で突然USBメモリーが認識されなくなってしまいます。当然ながら起動には失敗して、画面に禁止マークが出ます。起動作業の中程で発生します。

USB 3.0のUSBメモリーであっても、USB 2.0用のコネクタに接続するとUSB 2.0として機能します。なので、除外される可能性は低くなります。それでも除外される可能性はあります（今回もそれに遭遇してしまいました）。そのような場合でも、機能している2.0コネクタはどこかに必ずあるので、他のコネクタに挿し直して起動を試みます。

今回入手した最新のUniBeastのconfig.plistには、上で説明したように、10.14.4の個数制限を回避するパッチは書いてありますが、10.14.5には対応していません。10.14.5に対応したパッチに書き換えればこのような苦労はありません。ただ、パッチで対応することはあまりお勧めできません。USB制限問題は、macOSが正しくインストールされた後で、じっくりと対応するのが良いと思います。インストール段階で、機能するUSBポートを探して対処したら良いと思います。

NVRAMの不具合

上の2つの問題は回避できたものの、今回の試みではまだ正しくインストールできませんでした。言語選択の画面

の後、最初の再起動の手前で画面が動かなくなります。調べたところ、efiドライバにEmuVariableUefi-64.efiが足りないのが原因でした。drivers64UEFIフォルダにこれをいれておきます。現行の300シリーズチップセットのマザーボードは、どれもEmuVariableUefi-64が必要のようです。マザーボードには設定内容を記憶するNVRAMがありますが、これがmacOSから読めない場合があります。EmuVariableUefi-64は、NVRAMをエミュレーションして、この問題を解決します。

まとめ

UniBeastですんなりとインストールできれば楽なのですが、実際にはここで説明したような問題がかなりの頻度で発生します。それならば最初から、createinstallmediaで起動USBメモリーを作って、Cloverインストーラでefiを選びつつインストールしても良いように思いました。

macOSがインストールできれば、Hackintoshは7割方完成です。USBメモリーから起動すればmacOSは起動できます。USBメモリーのESPを、macOSをインストールしたドライブのESPにコピーすれば、USBメモリー不要で起動させることもできます。tonymacx86の方法では、この後MultiBeastを使ってインストールを完成させます。その後、それぞれのハードウェアに合わせて、バニラに起動するよう調整するのが良いと思います。続きは以下をご覧ください。

tonymacx86式インストール手順 (その2: MultiBeast)

tonymacx86式インストール手順 (その3: バニラ化と調整)

MSI H270M MORTAR ARCTIC, 7700K

Thu, 23 May 2019 23:22:28 +0900

Kaby Lake世代CPUでの作例です。スリープ、iMessage, FaceTimeが機能します。純正無線モジュールなのでContinuity関連も問題ありません。270チップセット世代で唯一の白いマザーボードです。

ハードウェア

マザーボードはMSI H270M MORTAR ARCTIC
CPUはIntel(R) Core(TM) i7-7700K CPU @ 4.20GHz
グラフィックスは（OOBで動作）
WiFi/BluetoothはBCM94360CD（OOBで動作）

BIOS設定

こちらの設定どおりです。

マザーボード (BIOS) 設定

ソフトウェアと機種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で動きます。

efiドライバ (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は不要かもしれません。

追記：Clover 5018にしたついでに、OsxAptioFix2Drv-free2000.efi をOsxAptioFix3Drv.efi に交換してみたところ、問題なく起動しました。また、他のefiも調整しました。DataHubDxe.efiは不要でした。またSMCHelper.efiはVirtualSMC.kextでは不要と聞いたので外しました。代わりにVirtualSmc.efiを入れました。現時点で使用しているefiファイルは以下です(2019/7/17)。

ApfsDriverLoader.efi
EmuVariableUefi.efi
FSInject.efi
OsxAptioFix3Drv.efi
VBoxHfs.efi
VirtualSmc.efi

config.plist

以下です。実機で未使用のシリアル番号を生成して書き込みましたので、このままでも問題なく使えます。しかし、Apple社のサービスを使う前にシリアル番号、UUIDを独自の値に設定し直してください。

config.plist for MSI H270M - Pastebin.com

GIGABYTE GA-Z68MX-UD2H-B3, 2500K

Sat, 18 May 2019 02:39:43 +0900

Sandy Bridgeの作例です。スリープ、LAN、サウンドが機能します。iMessage、FaceTime、Continuity関連は未確認ですが純正無線ユニットをいれているので多分大丈夫です。CPUが古いのでMojaveではiGPUが動きません。たまたま手元にパーツがあったので試みましたが、Mojaveで動かすには色々無理があります。

ハードウェア

マザーボードは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で動作）

マザーボードに搭載されているチップは以下です。

インテルチップセットに追加の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がサポートしています。なのでドライバ不要で動きます。

BIOS設定

まずはLoad Optimized Defaultsを選択して工場出荷時状態にします。その後で以下の設定をしました。

Advanced BIOS Features –> Onboard VGA –> Enable If No Ext PEG
Integrated Peripherals –> PCH SATA Control Mode –> AHCI
Integrated Peripherals –> F_USB30 Controller –> Disabled
Integrated Peripherals –> R_USB30 Controller –> Disabled
Integrated Peripherals –> GSATA3 Ctrl Mode –> AHCI
Integrated Peripherals –> Onboard Serial Port 1 –> Disabled
Power Management Setup –> HPET Mode –> 64-bit mode

Onboard VGAは、PCIeにグラフィックスカードが挿さっている場合にはiGPUを動かさないという設定にします。これ以外の設定にすると非サポートのiGPUが機能しようとするためか、sleepからの復帰に失敗します。電源は回復するのですが表示が真っ黒なままになります。

SATAのモードはmacOSがサポートするAHCIにします。最近のマザーボードではAHCIがデフォルトですが、古いマザーではIDEがデフォルトなので変更する必要があります。GSATA3の項目は、追加SATAチップのMarvell 88SE9172のことです。これもAHCIにします。シリアルポートはmacOSがサポートしていないのでDisabledにします。これが有効だと起動に失敗することがあります。HPETもmacOSに合わせて64-bit modeに設定します。

USB 3.0にはEtron EJ168というチップが使われています。当時のインテルのチップセットはUSB 2.0だけをサポートし、USB 3.0をサポートしていませんでした。なのでUSB 3.0はサードパーティのチップが使われました。EtronのチップはmacOSで不安定だったり使えない場合がありました。特に最近のmacOSでは古すぎてサポートされていないようです。今回の場合も、BIOS設定でUSB 3.0がEnabledになっているとMojaveの起動に失敗します。

ソフトウェアと機種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を別のマシンからインストールしています。

ESPの設定

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で動きます。

efiドライバ (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はもしかしたら不要かもしれません。

config.plist

MojaveはSandy Bridgeをサポートしていないので、iMac12,2では起動しません。そこで起動オプションに-no_compat_checkを入れて、互換性チェックを無視するよう指定しています。

config.plist for GA-Z68MX - Pastebin.com

9900KマシンをmacOS 10.14.5に更新する

Wed, 15 May 2019 23:51:27 +0900

（Cloverが対応したので古い情報です。）

第9世代CPUに対応した公開版macOSである10.14.5が配布されました。更新したところCPUが「不明」の表記が改まりました。ただしCore i7になっているのでconfig.plistでCPU Typeを指定してCore i9と表示されるようにしました。

新iMac対応Mojaveが公開される

第8, 9世代CPUに対応したiMacが出た時点のmacOSは10.14.4でした。ただ対応したmacOSは製品に搭載されるだけで、他の機種IDのマシンでは入手できませんでした。先日(2019/5/14)ようやく10.14.5が公開され、最新CPUに正式対応したmacOSが入手できるようになりました。早速、9900Kマシンをアップデートしました。問題なく動きます。

10.14.5から署名のないkextが除外されるという噂もありましたが、問題ありません。バニラなインストールをして、SIPも実機と同じく有効にしているから問題が無いのかもしれません。

CPUの名称表示を改善する

10.14.4ではCPUが「不明」

「このMacについて…」や「システム情報」を見るとCPU名が表示されます。しかし10.14.4では、以下のようにCPUが「不明」になっていました。

第9世代CPUを搭載したMacを対象にしていないバージョンでしたので、表示の用意がなかったと思われます。でもsysctlで確認すると、ちゃんと9900Kだと認識されています。

sysctl -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の表示になります。

良いところまで来たのに、今一歩足りない感じです。そこでこちらで頂いたコメントを元に、こちらからCPU情報を確認して、CPU Typeに0x1009を設定しました。config.plistの最上位dictの中に、以下のようにkeyとdictを追加すれば良いようです。

追記：コメントいただいたように実機では0x1005だったという情報があります。0x1005の方が良いかと思い、以下も変更しました。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CPU</key>
	<dict>
		<key>Type</key>
		<string>0x01005</string>
	</dict>
</dict>
</plist>

この結果、Core i9と表示されるようになりました。（もしかしたら10.14.4でもCPU Type指定でこのようにできたのかもしれません）見た目だけなのかもしれませんが、CPU名が正しく表示されるようになると気分が良いです。

10.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にありました。今後改善されると思います。

LattePanda Alpha 800, m3-7Y30

Sun, 12 May 2019 13:23:11 +0900

LattePanda Alpha 800は、Intel Core m3-7Y30を搭載したシングルボードコンピュータです。MacBook 2017に搭載されているm3-7Y32のクロック違いバージョンなのでmacOSとの互換性が高いです。3回にわたって過去に紹介しましたが、まとめ記事にしました。

ハードウェア

本体は 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は設定し直してください。

config.plist for LattePanda Alpha 800 - Pastebin.com

外部情報

以下でESPの中に入れるべきファイルが全て配布されています。

Releases · novaspirit/macpanda

このビルドに関する記事です。詳細はこちらをご覧ください。

LattePanda AlphaでmacOSを起動する

LattePanda AlphaのBluetooth/WiFi

LattePanda AlphaのUSB

15個制限を回避するUSBInjectAll.kextの役割と使用法

Sat, 04 May 2019 18:22:15 +0900

USBInjectAll.kextの役割を確認するために外して調べてみました。マザボ搭載USBポートの情報を正しく反映するために必要でした。さらに正確に反映させるためのSSDTを作りました。

USBInjectAll.kextの役割

このkextを外してみる

RehabManさんが開発してくれているUSBInjectAll.kextは、いつも使用しているのですが、そのありがたみがイマイチ理解できていませんでした。そこで外してみたらどうなるのか調べました。

USBポートの状態を調べるために、macOSから見えるハードウェア構成を確認するツールであるIORegistryExplorerを使用します。これを起動して、右上の検索欄でxhcとタイプすると、USB関連のポート一覧を見ることができます。この時、USBポートの名前がXHCではなくて、XHCIだったりXHC0だったりした場合は、config.plistでパッチを当てておいたほうが良いです。オリジナルのMacで使われている名前と衝突して問題を引き起こす可能性があるらしいです。

今回使用したのはASUSのZ390マザーボードであるROG MAXIMUS XI HEROです。これに搭載されているZ390チップセットの仕様を調べると搭載しているUSBは、

USB2.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本しか見えないはずです。

では、USBInjectAll.kextを外した状態でのMAXIMUS XIのUSBポート一覧です。こんな感じでした。

無意味に番号が飛んでいて、でたらめな感じがします。前の記事で調べたように、HS01はマザーボードのLED電飾機能が使っていて、HS14は内蔵Bluetoothが使っています。OSでもアプリケーションでも使用する重要なポートなのに、見えていません。また、このマザーボードでは、USB 3.1に付随する2.0は同じ番号を持っています。なのでSS01があるのにHS01が無いのは不自然です。明らかに、ASUSが提供しているマザーボード情報では無いと思われます。何かの方法で適当にリストアップされたように見えます。他にもHS13が見えてません。これはマザーボード上のUSB 2.0コネクタに接続しています。今回はここにmacOSと互換性のあるBluetoothモジュールを接続しているので、それがリストに無いと、Bluetoothキーボード、トラックパッドが使えません。

このkextを使ってみる

次に、USBInjectAll.kextを入れて起動した状態でのUSBポート一覧です。こうなります。

HS01から順番に欠番なくポートが見えていることがわかります。HSの次にあまり意味のないUSR1が来ていて、ここで15個の制限に達しています。なのでUSB 3.1のポートは見えていません。15個の制限がなければ、この後、USR2, SS01, SS02, …, SS10が、欠番なく全て見えるはずです。ということでUSBInjectAll.kextは、その名前の通り、もともと備えているUSBポートを全て認識させる機能を持っていることがわかりました。

このkextの中身を見る

このkextが、USBポート一覧をどうやって入手できたのかというと、作者のRehabManさんが用意しておいてくれたからです。kextの中の、Contentsの中に、Info.plistというテキストファイルがあります。これを開くと、前半部分に、USBコントローラのベンダーID、デバイスIDごとに、構成されているポート一覧が記載されていることがわかります。

使っているUSBコントローラのベンダーID、デバイスIDもIORegistryExplorerで知ることができます。

コントローラと思われるあたりをクリックすると、右側の詳細ペーンにvendor-id, device-idが現れます。リトルエンディアン方式なので逆に読みます。これによると、ASUSのこのマザーボードの場合、vendor-idは0x8086でインテル社であることがわかり、device-idは0xA36Dだとわかります。おそらくこれがZ390チップセットのUSBコントローラだと思われます。Info.plistで8086_a36dの場所を探すと、HS01からHS14と、SS01からSS10が記載されていることがわかります。

SSDTを作ってUSB15個制限に対応する

次に、USBInjectAll.kextの機能を使って、USB15個制限に対応する方法を説明します。今までの記事では、Cloverのブートオプションでuia_excludeを使う方法を紹介してきました。例えば、除外したいポートを以下のように指定します。

<key>Arguments</key>
<string>uia_exclude=USR1;USR2;HS01;HS02;HS09;HS10;HS14</string>

などと書く方法です。この方式では、オプションをUSBInjectAll.kextが引き取って、Info.plistのリストから外してくれています。でも、RehabManさんおすすめの方法は、SSDTを作りUSBInjectAll.kextに知らせる方法のようです。

SSDTというのは、ハードウェアの情報を記載するDSDTファイルの補助的なファイルです。DSDTの一部の情報を上書きして変更します。USBポートに関する情報を上書きするSSDTを用意することで、USBInjectAll.kextは、Info.plistの内容ではなく、SSDTの情報を使用してくれるようです。この手順を以下で説明します。

USBポートを調べる

まずは、マザーボードに搭載されているUSBポートを調べて、使用したい15個のポートを決定します。上記のページには手順が詳しく説明してありますが、以前の記事で紹介したので省略します。その結果、今回使用したマザーボード、ASUS ROG MAXIMUS XI HEROには以下のポートがありました。

HS01 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個を使うことにしました。

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の下)
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と改名しておきます。

このファイルには多数のUSBコントローラの情報が書いてあります。実際に使用するコントローラの項目だけを残して、他を削除します。ASUS Z390マザーボードの場合、vendor-idが0x8086で、device-idが0xA36Dです。この数値は上で説明したように、IORegistryExplorerでXHCの項目の中を探せば、vendor-id, device-idとして書いてあります。0x8086はインテルの番号ですので、インテルのチップセットを表しています。そこで”8086_a36d”と書かれた”Package”の定義だけを残して、他のPackageの定義を削除します。残すのは以下の項目です。

"8086_a36d", Package()
{

...........

},

この中にはHS01からSS10までのUSBの情報が書かれています。これに対して以下の作業をします。

コメントでポートの説明を記録しておく。後のメモになります。//で書き始めればコメントになります。
不要なポートをコメントアウトする。行頭に//を書いて、使用しないポートを除外していきます。削除せずにコメントにすれば、あとから復活させるのが楽です。
UsbConnector情報を更新する。これについては次に説明します。

UsbConnector情報

SSDT-UIAC.dslのそれぞれのUSBポート情報には、コネクタ種類が数字で記載されています。これを更新します。具体的には、以下のように書かれている部分の数字を、実際に合わせて書き換えます。

"UsbConnector", 3,

書き換える値は、以下の通りです。

0: 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に設定しておくのが良いです。

どのHSポートがUSB 2.0になるのかUSB 3.1になるのか、さらにはどのポートがType-Cになるのかは、マザーボード次第です。USBInjectAll.kextのInfo.plistにマザーボードごとの情報まで反映できないので、RehabManさんは各自でSSDTを作って、使用するマザーボードに即したUsbConnector情報をOSに伝えることを推奨しています。

port-countを設定する

SSDT-UIAC.dslの最初の部分に、portsのセクションの前に、port-countというセクションがあります。

"port-count", Buffer() { 26, 0, 0, 0 },
"ports", Package()
{

ここに書く数値（10進数）には、今回作ったポートのバッファー値、例えば、

"port", Buffer() { 26, 0, 0, 0 },

などと表される数のうちの最大の数値を書きます。今回はたまたま末尾のSS10まで使用したので、26のままで変更無しです。

dslをコンパイルしてamlを作る

こうして作ったdslファイルはSSDTのソースファイルのようなものです。これをコンパイルしてSSDTであるamlファイルを作ります。これにはMaciASLを使用します。こちらの記事で説明しています。

DSDTを編集する

MaciASLで、上で作成したSSDT-UIAC.dslを開きます。次に、FileのSave As…を選び、バイナリー出力を指定して書き出すとSSDT-UIAC.amlが出来上がります。

こうして作成したSSDT-UIAC.amlファイルを、ESPのEFI/CLOVER/ACPI/patched/にコピーすれば有効になります。これでCloverのブートオプションにuia_exclude=を指定しなくても、指定したポートのみが有効になるはずです。参考のために、今回作成したSSDT-UIAC.dslファイルを以下に置いておきます。

SSDT-UIAC.dsl for ASUS Z390 - Pastebin.com

Intel NUC D54250, 4250U

Fri, 03 May 2019 16:11:57 +0900

Haswell世代のCore i5-4250Uを搭載しています。これはMacBookAir6,1, 6,2で使用されているCPUで、macOSとの互換性が高く安定しています。D54250WYKは薄型筐体で、WYKHは2.5インチドライブを内蔵できる厚型モデルです。WYKHは一時期ドスパラで税込3万円未満で売られていました。

ハードウェア

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は設定し直してください。

config.plist for NUC D54250WYK(H) - Pastebin.com

Intel NUC D54250の続きはこちらです。

Intel NUC D54250にOpenCoreとBig Sur Beta 9を入れる

Intel NUCに関する記事は以下です。

NUCで作る超小型macOSマシン

Intel NUC DC3217, 3217U

Wed, 01 May 2019 20:29:02 +0900

最初に販売されたCore i搭載のNUCで、Ivy Bridge Core i3-3217Uを搭載しています。Macで同じCPUは使われていませんが、近いi5-3317UがMacBookAir5,1で使われています。Intel HD Graphics 4000が共通なこともあり、安定に動作します。

ハードウェア

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は設定し直してください。

config.plist for NUC DC3217IYE - Pastebin.com

Intel NUCに関する記事は以下です。

NUCで作る超小型macOSマシン

Intel NUC DC3217のiGPU画面が乱れる

MSI Z97A GAMING 7, 4790K

Wed, 01 May 2019 10:35:48 +0900

Haswell CPUの作例です。スリープ、iMessage、FaceTimeが機能します。純正無線ユニットを使用しているのでContinuity関連も問題ありません。HaswellはmacOSで問題を引き起こすことが少なく安定しているという評判でした。

ハードウェア

マザーボードはMSI Z97A GAMING 7
CPUはIntel(R) Core(TM) i7-4790K CPU @ 4.00GHz
グラフィックスは（OOBで動作）
WiFi/BluetoothはBCM94360CD（OOBで動作）

BIOS設定

こちらの設定どおりです。

マザーボード (BIOS) 設定

ソフトウェアと機種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の付く方はホットスワップ対応です。

efiドライバ (drivers64UEFI)

ApfsDriverLoader-64.efi
AptioMemoryFix-64.efi
FSInject-64.efi
SMCHelper-64.efi
VBoxHfs-64.efi

config.plist

config.plist for MSIZ97AGAMING7 - Pastebin.com

ASUS ROG MAXIMUS XI HERO (Z390), 9900K

Mon, 29 Apr 2019 20:17:38 +0900

Coffee Lake-S Refreshの作例です。スリープ、iMessage、FaceTimeが機能します。純正無線ユニットを使用しているのでContinuity関連も問題ありません。過去に公開した記事のまとめです。このマシンは常用していますので、ここで紹介している作例で一番自信のある構成です。

ハードウェア

マザーボードは (国内では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値を設定し直してください。

config.plist for 9900K w/o iGPU display - Pastebin.com

詳細な手順などはこちらをご覧ください。

9900K搭載Z390マザーボードでHackintoshを作る

ASUS Z390マザーボードのshutdown/sleep対応

9900Kのsleep問題〜原因はiGPUのデバイスID

ASUS MAXIMUS XI HEROにM.2 SSD (WD SN750)を取り付ける

10.14.4で第9世代CPUの互換性が向上

第9世代CPU用のSMBIOSを書く

9900KのためにmacOS 10.14.4 (18E2034) を入手する

ASUS MAXIMUS XI HEROのUSBを設定する

9900KマシンをmacOS 10.14.5に更新する

ASUSのBIOSを1105以上に更新すると起動しない

ASUS Z390 + Coffee LakeのブートローダをOpenCoreにする

OpenCore 0.6.2から0.6.3に更新

Big Surをクリーンインストールする (OpenCore + Z390)

Lenovo ThinkPad X220, 2620M

Sun, 28 Apr 2019 12:04:11 +0900

ThinkPad X220にmacOSをインストールした過去記事のまとめです。定評のある昔ながらのキーボードとトラックポイントを採用した最終モデルThinkPadでmacOSを動かします。Sandy BridgeなのでMojave非対応です。

ハードウェア

本体は 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の中に入れます。

外部情報

以下に全てのガイドがあります。ここでは、パッチを当てたBIOSと、ESPの中に入れるべきファイルが全て配布されています。Cloverやkext類も最新版になるよう更新されています。

ThinkPad X220 macOS High Sierra Installation - ThinkPad X220

このビルドに関する記事です。詳細はこちらをご覧ください。

Thinkpad X220でHigh Sierra (1)機種選定

Thinkpad X220でHigh Sierra (2)準備・到着・起動

Thinkpad X220でHigh Sierra (3)BIOSと無線

Thinkpad X220でHigh Sierra (4:最終回)まとめ・これから

CPU/GPUがサポート対象外のMojaveをなんとか動かす記事はこちらです。

Sandy Bridge搭載Thinkpad X220でMojave

Gigabyte GA-Z77N-WIFI, 3570K

Sat, 27 Apr 2019 10:19:35 +0900

Ivy Bridge時代の作例です。macOS Mojaveでも安定して動いています。スリープも機能します。未確認ですがiMessage/FaceTimeも大丈夫だと思います。BluetoothをBCM20702で構成していますので、キーボード・トラックパッドは問題ないですが、Continuityなどには対応していません。大昔に作ったマザボを引っ張り出して現行Mojaveを入れてみましたが、正しく動きました。

ハードウェア

マザーボードは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は設定し直してください。

config.plist for GA-Z77N - Pastebin.com

起動しないマシンをUEFI Shellで救う

Thu, 18 Apr 2019 20:06:05 +0900

UEFIマザーボードには各種設定やファイル表示・変更ができるコマンドラインシェル機能があります。これを使用すればOSが起動する前にファイル変更・移動・削除できるので、誤設定で起動しなくなったマシンを救えます。

UEFI Shellへの入り方

UEFI Shellは、UEFI環境で動作するオープンソフトウェアです。Cloverをインストールすると、EFI/CLOVER/toolsの下にShell64.efiというような名前でインストールされます。Cloverの起動ドライブ設定画面から「Start UEFI Shell 64」を選択すると起動します。

最近のマザーボードには、マザーボード内のメモリーにもすでにUEFI Shellがインストールされています。なので、BIOSメニューの中からもシェルを起動できます。起動メニューは、BIOSのSave & Exitの項目の中にあることが多いです。下は、MSIのマザーボードの例です。「UEFI: Built-in EFI Shell」というメニューを選ぶとシェルに入ります。

CloverのESPにあるシェルとマザーボードで用意されているシェルは、バージョンが異なります。Cloverから起動できるシェルの方が機能が多いです。以下では、Cloverから起動したシェルで説明します。

ESPのあるファイルシステムに移動する

シェルが起動したら、

help -b

とタイプするとヘルプの一覧が出ます。-bオプションは、画面１ページごとに一旦停止して表示するためのオプションです。このオプションはほかのコマンドでも使えます。今回使うべき機能は、

bcfg NVRAMに保存されたbootとdriverオプションを管理します。
cd ディレクトリーを移動します
cp ファイルやディレクトリをコピーします
edit エディタを起動してファイルを編集します
exit シェルを終了します
ls ディレクトリの中のファイルを表示します
map ファイルシステム (FS) のマップを表示・定義します
reset システムをリセットします
mv ファイルやディレクトリを移動・改名します
rm ファイルやディレクトリを消去します

です。このうちbcfg, edit, map以外はmacOSの（というかUnixの）シェルコマンドと同じです。シェルが起動したらまずは、

bcfg boot dump

とタイプします。NVRAMに保存された起動情報をdump（画面表示）するコマンドです。これでboot可能なドライブ一覧が表示されます。boot可能ドライブが1個しかなければ、1個が表示されます。複数あれば複数表示されます。複数現れる場合はbootの優先順です。

何かの不具合でブートドライブとして見えない場合はこのコマンドで追加もできます。例えばaddコマンドを使って、fs1:\EFI\EFI\BOOT\にあるBOOTX64.efiをブート順位2（先頭は0）に、Boot macOSという表示名で追加する場合は以下のようにします。

bcfg boot add 2 fs1:\EFI\EFI\BOOT\BOOTX64.efi "Boot macOS"

また不要なドライブを一覧から消すこともできます。例えばrmコマンドを使って順位4を削除する場合は、以下のようにします。

bcfg boot rm 4

今回はdumpコマンドを使って単に閲覧するだけにします。以下は、bootドライブが一つだけの場合のdumpコマンドの実行例です。

UEFIはBOOTX64.EFIというファイルを見つけてコンピュータのbootを行うのですが、そこに至るパスがDevPathという項目に書いてあります。最初がドライブの種類で、パーティションがGPTであるかなどが書かれています。そのあとに32桁の16進数があります。これはパーティションを特定するUUIDです。ESP (EFI System Partition) がdisk0s1の場合、macOSのターミナルからdiskutilコマンドを使って、

diskutil info disk0s1

とタイプするとESPのパーティションUUIDがわかるのですが、それと同一のものが見えているはずです。これでESPのパーティションUUIDの目星をつけてメモしておきます。UUID全部をメモする必要はなくて、最初と最後の数桁で良いです。

次に

map -b

とタイプします。ファイルシステムのマップが出てきます。この中に、先ほどのESPのUUIDと同じものがあるはずです。それを見つけて、ESPのファイルシステム番号を確認します。行頭にFSと書いてある次の番号です。ドライブが1個しかなければ、ESPは大抵FS0:に割り当てられています。以下は、ESPがFS0:に割り当てられていた場合で説明します。

次に

fs0:

とタイプします。Unix系のファイル操作と違って、ファイルシステム（ほぼパーティションに相当します）ごとにルートディレクトリがあります。C:ドライブやD:ドライブのあるWindowsの方式に近いです。Windowsではドライブキャラクタにコロンをつけるとそのドライブ内のルートディレクトリに移動します。このシェルでも同様にfs0:でESPのルートディレクトリに移動します。なのでこの後、

ls

コマンドをタイプすると、ESPのルートのファイル名（多分EFIというディレクトリが一つ）見えます。この後は、ls, cd, cp, mv, cp, rm, edit, type (Unixのcatに相当)コマンドを駆使して、ファイルを操作します。

config.plistを書き換える

動いているマシンのconfig.plistをちょっと変更したら起動しなくなってしまった、という経験は皆さん何度もされていると思います。そんな場合はUEFI Shellでconfig.plistを元のように書き換えてしまうことができます。起動しなくなってもCloverの起動選択画面表示はされると思いますので、そこでUEFI Shellを起動します。上記の手順を踏んで、ESPのファイルシステムに移動します。その後、

cd EFI\CLOVER
ls
edit config.plist

とタイプすれば、CLOVERのディレクトリに行き、ファイルを一覧し、config.plistを編集できます。ディレクトリの区切りは、Unixのように/（スラッシュ）ではなく、\（逆スラッシュ）です。これもWindowsのような流儀ですね。また、タブキーで補完機能が効くので、例えばedit conあたりでタブを押せばあとを補完してくれます。（Unixの補完と違って最初にヒットした名前に補完されるので多少注意が必要です。）

editコマンドではフルスクリーンのテキストエディタが開きます。コントロールEでヘルプが表示されます。操作は簡単で、

Ctrl-G 行に移動。行番号の入力を促される
Ctrl-S ファイルを保存する
Ctrl-Q 終了する
Ctrl-F 検索する
Ctrl-R 検索・置換する
Ctrl-K 行をカットする
Ctrl-U 行をペーストする
Ctrl-O ファイルを開く
Ctrl-T ASCIIとUNICODEの切り替え
Ctrl-E ヘルプを開く
Ctrl-W ヘルプを閉じる

です。これで大体の編集は可能なので、config.plistを元に戻すことができます。config.plistを保存し、エディタを終了した後で、

exit

もしくは

reset

コマンドをタイプしてシェルを抜けます。resetコマンドはシステムがリセットされます。exitコマンドでは、Clover選択画面に戻ります。大体はexitコマンドでokですが、変更内容によっては変更が反映されないことがあります。resetの方がより確実です。

kext/efiファイルを差し替える

kextやefiファイルを追加したり削除したことで起動しなくなる事故も多いです。これもEFI Shellの操作で復帰できます。kextやefiファイルを外したい場合は、cdコマンドでEFI/CLOVER/kexts/Otherに移動して（EFI Shellの中では区切りを逆スラッシュで指定します）、rmコマンドで削除するか、mvコマンドでバックアップ用のディレクトリに移動させるのが良いです。例えば、_unusedというディレクトリ（名前の最初の文字をアンダースコアにした理由は、ファインダーで上位に表示されるので分かりやすいかと思ったからです）がkextsの中に作ってある場合、ABCD.kextというkextは、

mv ABCD.kext ..\_unused\.

で移動します。もしくは、mvコマンドで、ABCD.kext.backupというようにファイルタイプを変えてしまうのも良いかと思います。バックアップせずにrmコマンドで消してしまっても良いです。

起動に必須だったkext/efiを削除して起動しなくなった場合も同様な方法が可能です。上の例と同様に、もし削除する前に_unusedフォルダのような場所にバックアップされてあればそこから戻せます。

mv ..\_unused\ABCD.kext .

kext/efiとは違うファイルタイプに変えてあるのでしたら、名称変更すれば良いです。

mv ABCD.kext.backup ABCD.kext

ということで、kext/efiを削除する場合は、起動しなくなる状況に備えて戻せるように、ESPのどこかに残しておく事が重要です。

また新たに必要なファイルをUSBメモリに入れて、それを起動ESPに追加することも可能です。例えば、USBメモリの場所がfs3だったら、

cp fs3:\DSDT-XXXX.aml .

のようにしてコピーすることが可能です。

Hackintoshが起動しなくなる前にやっておくこと

Sun, 14 Apr 2019 15:59:40 +0900

設定を変更したら起動しなくなってしまったという経験は誰にでもあると思います。その前に少しだけ準備しておけば復旧の手間を減らすことができます。そんな工夫をいくつか書き連ねてみました。

本物のMacではmacOSが起動しない事態に陥ることは滅多にありません。しかし色々設定してなんとか本物のMacに近い動きを実現しているHackintoshでは、ちょっとした設定の変更やOSのバージョンアップでマシンが起動しなくなることはよくあることです。真っ黒な画面を目にして、設定を変えなければよかったとか、もっと考えてからバージョンアップすればよかったと後悔することが多いです。どんなに間違った設定をしても、それ以前に動いていたなら、インストールした手順を最初から繰り返せば元に戻せます。でもそこまで手間をかけなくても、大抵の失敗はもっと簡単に取り戻せます。

追記：EFI Shellを使うと良いですとコメントいただきました。確かに、ここで書いた事態は、EFI Shellを使って回復できるようです。ということで、続きは以下をご覧ください。

起動しないマシンをUEFI Shellで救う

動作するconfig.plistをバックアップしておく

config.plistをちょっとだけ書き換えたら動かなくなるという失敗はいつもやってます。こんな事態に備えて、動いているconfig.plistを変更する場合には、そのコピーを作っておくと良いです。コピーの名前は、configXXXXX.plistとします。例えば、

cp 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をラジオボタンで選択できます。これを選べば元どおり起動するはずです。

ESP全体をクラウドにバックアップしておく

config.plistを別名でコピーしておくことを忘れてしまい、起動するconfig.plistがESPにもはや存在しない場合は、上の方法は使えません。ただ、Cloverのオプションメニューからは、いろいろな設定を一時的に変更できるので、それで復旧できることもあります。でも、config.plist編集以外の作業をした場合、例えばefiファイルやkextファイルを差し替えたとか、DSDTを書き換えたなどの場合は、復旧が難しい場合が多いです。

その場合、動いていた時のESP全体のバックアップがあれば復旧は楽です。バニラなインストールをしている場合、ESP以外は実機のMacと同じで、いろいろな復旧方法があります。OSならApp Storeからダウンロードし直せば良いです。またTime Machineでバックアップしておけば、データが壊れたとしても取り戻せます。HDDを多数接続できる自作HackintoshはTime Machineの利用がやりやすいので、是非検討してください。

Time Machineは良いです

ESPは常時マウントするものでは無いので、Time Machineバックアップには不向きです。量も少ないですし、手作業でバックアップしておくのが良いでしょう。バックアップ先は色々考えられますが、今時ならばクラウドが良いと思います。絶対安全ですし、紛失しませんし、他のマシンからアクセスできるので、復旧用USBメモリーを作成するのも簡単です。バックアップのタイミングも色々考えられますが、一番効率が良いのは、ESP書き換え作業の直前です。作業直前に動作している最新のESPをバックアップしておけば、次の起動に失敗しても復旧できます。ということで、ESPをマウントすると同時にバックアップを取っておく方法を以前にこちらで説明しました。

ESPをマウントしてついでにバックアップする

訓練：バックアップESPから復旧する

いざという時に本当に復旧できるのかどうか、訓練してみました。まずはメインで使っているHackintoshをシャットダウンします。次に、サブで使っているMacBookで、以下の作業をしました。

適当なUSBメモリ(GUIDパーティション) のESPをマウントして開く
iCloudドライブにアクセスして最新ESPをUSBメモリにコピーする

手持ちのGUIDパーティションのUSBメモリーにEFIがなかったり、diskutil repairdiskコマンドでEFIが作れるらしいとか、でもUSBメモリーのサイズが小さいとEFIが作れないなど、色々発見がありましたが、最終的にはUSBメモリーで無事起動できました。

画面共有・sshサーバを起動しておく

macOSのインストールに成功して、ネットワーク機能が動くようになったらすぐにやっておくと良いことがあります。それは、「システム環境設定」「共有」から「画面共有」と「リモートログイン」を有効にしておくことです。リモートログインはsshd (sshのサーバ) を動かす機能です。これらが有効になっていれば、他のマシンから画面共有やsshで接続することができます。

Hackintoshを設定していて、グラフィックス機能が動かなくなり、起動しても画面が出ないことがあります。また、スリープから目覚めた時に、グラフィックス機能が復帰できずに画面が真っ黒なままなこともあります。このような場合、コンピュータは止まっているように見えますが、内部では動いています。なので、画面共有やsshで接続して、設定を調整し直すことが可能です。また、それが可能ならば、不具合の原因がグラフィックス関係であることが特定できます。

APFSコンテナにボリュームを作っておく

macOSのバージョンアップで起動しなくなる場合もあります。Cloverやkext類が最新でないことが原因である場合が多いです。また、kextをバージョン別のフォルダに入れている場合、新しいバージョン用のフォルダを作り忘れるというケアレスミスもあります。現在動いているmacOSを非常用のシステムとしてインストールしておくと、このような場合に早く復旧作業に入れます。外付けのドライブやUSBメモリーに非常用のシステムを作っておくと、いざという時に見つからない場合もあります。接続中のドライブに非常用システムのボリュームを作っておくのが安心です。

APFSになってからボリュームを作る作業が楽になりました。APFSコンテナの中に、好きな時に必要なだけのボリュームを作ったり消したりできます。パーティション一つがボリューム一つだった時代は、使われない記憶領域ができて無駄だったのですが、APFSのボリュームなら必要な記憶容量しか使用しません。何も加えないmacOSならば14GBほどのサイズです。私が作ったMojaveの起動ボリュームは13.6GBでした。これが苦にならない程度のAPFSコンテナがあれば、非常用システムを作っておくと良いと思います。こちらで説明しておきました。

APFSのVolumeを活用する

ASUS MAXIMUS XI HEROのUSBを設定する

Tue, 09 Apr 2019 23:35:30 +0900

ASUS マザーボードのUSB設定をしました。使わないUSBポートの番号を調べ、その番号をconfig.plistに書きます。これでmacOSの個数制限によりUSB 3が使えなくなる事態を回避します。以下の記事で紹介しているように、ASUS MAXIMUS HEROマザーボードに9900Kを搭載したマシンは順調に稼働しています。

9900K搭載Z390マザーボードでHackintoshを作る

今回、回避しようとしているのは、macOSのUSB個数制限です。macOS El Capitanから使用可能なUSBポートの数が、コントローラ当たり15までと制限されてしまいました。理由は不明です。この対策は何通りかありますが、15個の制限は残したまま、使用しないUSBポートを除外するようconfig.plistに設定するのが一番良いと思います。

USBポートを設定する

上の記事では、MSI Z97A Gaming 7マザーボードを例に、使用しないポートをconfig.plistに書くことで、必要なUSBポートが使用可能になるよう設定しました。同じ手順をASUS MAXIMUS XI HEROマザーボードでも行いました。

USBInjectAll.kext

まずはUSBInjectAll.kextを入手してEFI/CLOVER/kexts/Otherフォルダに入れます。

RehabMan / OS-X-USB-Inject-All / Downloads — Bitbucket

このkextは、チップセットで用意されているUSBポートの全てをmacOSから参照できるように設定する機能があります。この記事で利用しようとしている機能、config.plistの起動オプションで使用しないポートを除外する機能は、このkextが提供しています。

何も対策しない場合のUSB構成

まずは、何も対策しないとどのUSBポートが見えているのかを確認します。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。

mac.softpedia.com

IORegistryExplorer.appを起動して、右上の虫眼鏡アイコンのところに、xhcと入力します。するとXHC関係の情報が現れます。全く対策しない状態のASUS MAXIMUS XI HEROマザーボードでは、以下のような結果になりました。

XHCの下にHS01~14とUSR1が見えています。これらが現在OSが認識しているUSBポートです。macOSは15個しか認識しないので、アドレスの低い方から15個のポートが見えています。マザーボードにはこれ以外にもUSBポートがあるのですが、15個超えているものは見えません。

USRを除外する

HSはHigh Speedの略でUSB 2.0のことです。USRは、tonymacx86の説明によると何らかの都合で見えてしまっているダミーのポートらしいです。なので除外しても良いらしいです。とりあえずUSR1を除外してみましょう。USBInjectAll.kextを使用した上で、config.plistのBoot Argumentsに以下のように指定します。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1</string>

この結果、IORegistryExplorer.appの表示が以下のようになりました。

新たにUSR2が見えるようになりました。実はこれも実存しない不要なポートらしいです。これも除外しましょう。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1;USR2</string>

この結果、IORegistryExplorer.appの表示が以下のようになりました。

不要なUSR1, USR2を消したので、ようやくSSが見えてきました。SSはSuper Speedの略で、USB 3のポートを示しています。

HS (USB 2.0) ポートを特定する

この段階で見えているHSポートであるHS01からHS14の14個が、マザーボードにあるとmacOSが認識している全てのUSB 2.0ポートです。これがどこのポートなのか特定していきます。ちょっと大変な作業ですが、マザーボードの構成を把握できるので、達成感はあります。

マザーボード上のUSB 2.0ピンソケットを調べるためには、こんなアダプタがあると便利です。

それぞれのポートに対応する番号を調べるためには、

それぞれのポートに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端子の番号の、それぞれの該当項目が変化します。

こうしてASUS MAXIMUS XI HEROマザーボードのUSB 2.0を調べました。各ポートの番号は以下のようになっていました。

HS01 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に接続しています。

HS13は、マザーボード上のUSB 2.0端子に接続しています。マニュアルには下のような図面があります。マザーボード上にはUSB_E12, USB_E34という名称のソケットがあり、ここにUSB 2.0が4ポート出ています。ただ、これらの4ポートは内部でUSBハブに接続していて、HS13が大元になっているようです。今回は、この基板上USB 2.0端子の一つにBluetoothユニットを接続しています。なので、HS13だけは除外できない重要なポートです。

バックパネル部分は以下になります。

少し面白い発見だったのはHS01です。IORegistryExplorer.appの検索窓の文字を消すと、絞込み機能が無効になり、全ての情報が見えるようになります。そしてHS01の詳細を見てみます。すると以下のように、名前がAURA MOTHERBOARDになっていて、製造者名はAsusTek Computer Inc.と表示されます。どうやらマザーボードの電飾ユニットに接続されている様子です。もしもこれをプログラムできればmacOSから電飾をコントロールできるのかと思われます。

マザーボードが使っている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です。

Bluetooth以外のHS (USB 2.0)を全部除外する

USR1, USR2を除外したことで、USB 3としてはSS01があることはわかりました。他のUSB 3ポートは15個の制限で隠されています。そこで、全てのUSB 3ポートを調べるために、絶対必要なHS以外を一時的に除外します。Bluetoothは基板のHS13に接続されているので、これが無いとキーボードとトラックパッドの操作ができなくなってしまいます。そこで、これ以外のHSを全部除外してみます。Boot Argumentsに以下を書いてみました。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>>uia_exclude=USR1;USR2;HS01;HS02;HS03;HS04;HS05;HS06;HS07;HS08;HS09;HS10;HS11;HS12;HS14</string>

この結果、IORegistryExplorer.appの表示が以下のようになりました。

HS13を含めて全部で11項目あります。15個未満なので、これで全てです。ということでこのマザーボードにはSS01からSS10までの10個のUSB 3があることがわかりました。

このマザーボードはインテルのZ390チップセットを使っているのですが、インテルの仕様によるとUSB 2.0が14本、USB 3.1が10本あり、最大で14本のUSB 2.0/3.1を使用できることになっています。このマザーボードはチップセットが提供するUSBの全てを使っているようです。

SS (USB 3) ポートを特定する

USB 3であるSSがSS01からSS10まで10個見えるようになりました。これらのうちバックパネルのSSを特定しました。これにはUSB 3.0のUSBメモリを挿しながら調べました。

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

このマザーボードはHSとSSの数字部分が対応しているようです。バックパネル写真に合わせると以下のようです。ちなみに、バックパネルのUSB 3ポートには、青いポートにSS、そして赤いポートにSS10と表示が書いてあるのですが、これはそれぞれ3.1 Gen 1とGen 2を示しているようです。10というのはおそらくGen 2の転送速度である10 Gbpsのことだと思います。

SS09とSS10はマザーボード上のUSB 3.1 Gen 1ポートであるU31G1_910に接続しています。マニュアルの図を再掲します。

SS01と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に接続しているのかもしれません。

必要なUSBポートを選んで他を除外する

さて以上からほぼ全てのUSBポートの番号がわかりました。ここから、使用したいUSBポートを最大15個選び、それ以外の使用しないポートを除外する設定をします。

基板上の3.1 Gen 1コネクタを使用しない場合

マザーボード上のUSB 3.1 Gen 1ポートであるU31G1_910を使用しない場合を考えます。基板上のUSB 2.0コネクタに関しては、Bluetoothモジュールが使用するのでこれ (HS13) は外せません。HS13と、バックパネルのポートを全て使うことにすると、必要なポートは以下のようになりました。

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”)
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個です。そこで、これ以外を除外するよう設定します。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1;USR2;HS01;HS02;HS09;HS10;HS14;SS01;SS02</string>

末尾に近いSS09以降は、除外リストに入れる必要はないです。この結果、IORegistryExplorer.appの表示が以下のようになりました。

基板上の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を除外することにしました。なんとなく残念ですが仕方ないです。そうすると使用するポートは以下になります。

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の下)
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

これ以外を除外するには以下のように設定します。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1;USR2;HS01;HS02;HS07;HS08;HS14;SS01;SS02;SS07;SS08</string>

この結果、IORegistryExplorer.appの表示が以下のようになりました。

補足：バックパネルのUSBポート

マザーボードのマニュアルに掲載されているバックパネルのポートの説明図は以下です。USB 3ポートのうち、青いポートがGen 1ポート、赤いポートとType CポートがGen 2ポートのようです。

つづき：USB構成を記述したSSDTを作る

この記事では起動オプションで使用USBポートを指定しています。USBInjectAllの機能をフルに活用するためには、SSDTファイルを作ることが理想的です。続きは以下の記事をご覧ください。

15個制限を回避するUSBInjectAll.kextの役割と使用法

9900KのためにmacOS 10.14.4 (18E2034) を入手する

Sat, 06 Apr 2019 12:47:04 +0900

（10.14.5が配布されたのでこの情報は不要になりました。）

この記事の執筆時点で配布されているmacOS Mojave 10.14.4はビルド18E226です。しかし最新のiMac Early 2019には18E2034が搭載されています。これが簡単に入手できることがわかりました。

新iMac対応Mojaveが欲しい

第9世代CPU 9900KでHackintoshを作ったら、機種ID、シリアル番号、ボードIDなどのSMBIOS設定も同じCPUを搭載するiMac Early 2019に合わせたいところです。ところがボードIDを27インチiMac Early 2019の値、Mac-AA95B1DDAB278B95に設定するとmacOSが起動しません。

Cloverのブートオプションに-no_compat_checkを追加するだけで簡単に回避できるのですが、できれば対応したmacOS Mojaveが使いたいと考えていました。10.14.5が出るまで待たねばと思っていたところ、コメント欄から、実機に搭載されている10.14.4 (18E2034)が入手できたとの情報をいただきました。試してみました。

iMac19,1の設定でMojaveを入手

入手方法は簡単で、iMac19,1として動いているマシンからApp Storeに接続してMojaveをダウンロードするだけです。

今回使用したマシンは、ASUS MAXIMUS XI HEROに9900Kを搭載したHackintoshです。iMac E2019が店頭に出回る前には、このマシンをMacmini8,1と設定していました。その時に、App StoreからMojaveを入手して、インストールしていました。これをiMac19,1のSMBIOS情報に設定し直した状態の「このMacについて」ウィンドウが以下です。

ビルドは通常配布されている18E226であることがわかります。iMac19,1に設定すると、上で述べたようにそのままでは起動しないので、Cloverのブートオプションに-no_compat_checkを追加して無理やり起動しています。CPUは9900Kなのですが、表示では不明になっています。この状態で、再び10.14.4を入手し直します。まずは、App Storeへ接続し、Mojaveを検索してそのページに移動します。

ここで「入手」をクリックすると、いつものようにソフトウェア・アップデートのウィンドウに移動します。次にダウンロードボタンを押すと、macOS Mojaveインストール.appを入手することができます。

この方法で入手できるインストーラのバージョンは14.4.10です。

これを使ってMojaveをインストールすると、ビルドが18E2034になります。

プロセッサは不明のままです。（途中でメモリを追加したので容量が増えていますが同じマシンの画面です。）

18E2034はEarly 2019限定？

面白いことにiMac19,1（と多分iMac19,2）に設定されていないマシンからApp Storeに行っても、18E2034はダウンロードできないようです。本物のMacでも試みましたがダメでした。その場合、ダウンロードされるインストーラのバージョンは14.4.08になります。これをインストールするといつものビルド番号である18E226になります。

手順のまとめ

以上から、現時点で、9900Kマシンを作って対応したmacOSを入手する手順はこうなると思います。

9900Kマシンを作る
本物の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になる。

第9世代CPU用のSMBIOSを書く

Wed, 03 Apr 2019 18:04:56 +0900

iMac Early 2019でようやく第9世代CPUがサポートされました。出回っている機種情報を使ってシリアル生成ソフトを用意して、config.plistのSMBIOSセクションを作りました。実機に近い設定ができたと思います。

iMac 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) になりそうです。

新型iMacに第9世代CPUがようやく搭載される

ここで参考にした情報は、「マックお宝」が公開しているYoutubeのビデオ、Geekbenchのスコアページ、店頭で見てきた情報などです。

シリアル番号

シリアル番号は「このMacについて」を見ればすぐにわかります。現在店頭にあるiMac E2019は、全て中国製で、（当たり前ですが）2019年製造です。なので、シリアル番号の最初4桁は、全てC02Yです。シリアル番号の仕組みはこちらをご覧ください。

Macシリアル番号の仕組み

次の桁は製造週ですが、店頭にある製品は9週もしくは8週です。9週のものが多かったです。2019年の第9週は2/26から3/4の週で、8週はその前の2/19から2/25の週を表します。

次の3桁は製造ライン番号と言われていて、製品個別の番号です。最後の4桁がモデルコードです。iMac19,1のモデルコードにはJV3Q, JV3P, JV3N, JV40が、iMac19,2のモデルコードにはJWDW, JWDXが発見されました。この他にも多数のコードがあるはずです。みなさんも発見できたら是非ともコメントでおしらせください。他の記事でも紹介していますが、正しいモデルコードならば次のURLのPPPPの場所に指定すると該当マシンの仕様ページが表示されます。

http://support-sp.apple.com/sp/index?page=cpuspec&cc=PPPP

以上のことから、現在店頭にあるシリアル番号は、C02Y9xxxJV3Qなどとなります。

ボードシリアル番号

ボードシリアル番号は、シリアル番号より確認しづらいです。後述のmacserialプログラムでも確認できますが、macOSの標準コマンドでしたらnvramコマンドが使えます。ターミナルから次のコマンドをタイプすれば表示されます。

nvram 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:MLB

現在店頭にあるiMac E2019のボードシリアル番号は、本体と同じく中国製のようです。製造年は、当然ながら2019年で、製造週は、本体より1週間早く、07週もしくは08週でした。ボードシリアル番号の後半には、ボードの種類を示すボードコードがあります。iMac19,1のボードコードにはLNV9, KDP0が、iMac19,2のボードコードにはKGQGが発見されました。なので、現在店頭にある製品のボードシリアル番号は C02908xxxxxLNV9xxなどになります。

その他のID

ボードIDは、iMac19,1がMac-AA95B1DDAB278B95、iMac19,2がMac-63001698E7A34814でした。これはGeekbenchのページでも確認できます。これ以外にはありません。

また、システム情報に出てくる番号として、ブートROMのバージョンがあります。これはどれも220.250.368.0.0でした。

シリアル生成プログラム

シリアル番号の仕組みの記事では、シリアル番号を自動生成してくれるプログラムmacserialをご紹介しました。これをforkさせていただき、上記で得たシリアル番号生成のための情報を付け加えました。これでiMac E2019のシリアル番号を自動生成できます。Intelの8600, 9600K, 9900KをCPUとして使用したHackintoshを作る場合には、iMac19,1のシリアル番号が最適です。8100, 8500, 8700の場合は、Macmini8,1でも良いかもしれませんが、iMac19,2も使えます。コンパイルしたバージョンのmacserialをこちらに置いておきました。

Releases · bootmacos/macserial

./macserialとして起動すると現在のマシンのIDを表示します。./macserial -hでヘルプが出ます。iMac19,1のシリアル番号を生成したいのでしたら、./macserial –model iMac19,1とタイプすると、シリアル番号、ボードシリアル番号の一覧を出してくれます。

./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 とすると、そのシリアルの情報を表示します。例えば、上の例の最初の候補の場合、

./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週の番号は避けた方が良いと思います。

シリアル番号を既に決めているのであれば、./macserial –mlb で、同じ国で、前の週に製造されたロジックボードのシリアルを生成してくれます。

./macserial --mlb C02YC017JV3Q
 C02909108GULNV9AD

SMBIOSを書く

それではiMac19,1に限りなく近い設定のSMBIOSセクションを書いてみましょう。上記の例のシリアル番号・ボードシリアル番号を使う場合、以下のようになるかと思います。（皆さんのご自分の番号を使ってください）SmUUIDも、ターミナルのuuidgenコマンドで適当に生成して記入してください。

<key>SMBIOS</key>
	<dict>
		<key>Board-ID</key>
		<string>Mac-AA95B1DDAB278B95</string>
		<key>BoardSerialNumber</key>
		<string>C02909108GULNV9AD</string>
		<key>EfiVersion</key>
		<string>220.250.368.0.0</string>
		<key>ProductName</key>
		<string>iMacm19,1</string>
		<key>SerialNumber</key>
		<string>C02YC017JV3Q</string>
		<key>SmUUID</key>
		<string>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</string>
	</dict>

Board-IDはiMac19,1に使用されているロジックボードIDを入れました。EfiVersionは、ここに書いておけば、本物のiMac E2019と同様に、「システム情報」のブートROMのバージョンの項目に表示されます。これ以外のSMBIOSの項目はCLOVERが自動生成してくれます。もしかしたら現バージョンのCloverはiMac19,1に対応していないかもしれませんが、将来のバージョンでは対応するはずです。

このSMBIOSを使ってみた

このSMBIOSを9900K搭載のHackintoshに設定し、App Storeで配布されている通常のmacOS Mojave 10.14.4 (18E226)で使ってみたところ、残念なことに起動しませんでした。こんな画面になってしまいました。

一般配布されている10.14.4は、iMac19,1に搭載されているビルド番号18E2034と異なっていて、ボードIDがサポートされていないようです。10.14.5まで待てば解決されるかと思います。それまでの間は、config.plistのBootオプションに、

<key>Boot</key>
   <dict>
     <key>Arguments</key>
     <string>-no_compat_check</string>

と記載して、互換性チェックをしないように指定しておくことにしました。

iMac 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になります。それでも、プロセッサは「不明」と表示されてしまいます。これはちょっと謎です。

Clover ConfiguratorがiMac19,xに対応

macserialをforkしてiMac19,1, 19,2に対応させた後、オリジナルのmacserialのacidantheraさんにPull requestsしておきました。そうしたらすぐに承認されて、macserialのソースコードに反映されました。コミュニティへの本当に些細な寄与ですが、初めてなので嬉しいです。その結果、かどうかわかりませんが、Clover ConfiguratorもiMac19,xに対応してくれたようです。これでSMBIOSが簡単に作れるようになりました。

シリアル番号をいくつか発生させてみたところ、上で紹介したモデルコードとボードコードを使ったシリアルが現れます。今回調べた情報を使ってくれているようです。

Macシリアル番号の仕組み

Sun, 24 Mar 2019 12:52:47 +0900

Hackintoshを作る時には、機種IDやシリアル番号などのいくつかのIDを決める必要があります。今回はシリアル番号とボードシリアル番号の文字・数値の意味を説明します。以下の、シリアル番号自動生成ツールの資料とソースコードを参考にしました。

GitHub - acidanthera/macserial: Decode mac serial number

Hackintoshに必要な番号

HackintoshがMacとして機能するためには、機種ID、様々なシリアル番号、ファームウェアバージョンなどを決めておく必要があります。これらはconfig.plistのSMBIOSセクションに記述されます。Clover configuratorを使うと、Macの機種を指定するだけでSMBIOSに書くべき内容を自動的に作成してくれます。しかし、最近のバージョンのCloverでは、SMBIOSのほとんどの内容を自動的に設定してくれますので、この機能に任せた方が間違いが無くて良いです。またBIOSバージョンなどの数値は、本来ならばmacOSインストーラがファームウェアアップデートすると更新される数値なので、Cloverが決めてくれる最新値を使う方が良いです。Cloverに任せておけば、間違いのない最新の数値を設定してくれます。

その一方で、手作業で設定した方が良い番号もあります。以下の設定です。

 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>xxxxxxxxxxxxx</string>
 <key>ProductName</key>
 <string>Macmini8,1</string>
 <key>SerialNumber</key>
 <string>xxxxxxxxxxxx</string>
 <key>SmUUID</key>
 <string>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</string>
 </dict>

ProductNameは、機種IDに相当します。一般には、ハードウェア構成（特にCPUの種類）が一番近いMacの機種IDを設定するのが良いです。SmUUIDは、ターミナルから何度かuuidgenとタイプして得られる32桁の適当な数値を設定しておきます。一部のソフトウェアではインストール台数制限のチェックにも使っているようです。一度決めたら変えない方が良いです。

SerialNumberはMacのシリアル番号です。本物のMacでは筐体に刻印されています。また、BoardSerialNumberはロジックボード（Apple社はマザーボードをロジックボードと呼びます）のシリアル番号です。ロジックボードに刻印されていることがあります。普通にMacを使っている限り、どちらの番号もずっと同じものですが、Macを修理してロジックボードを交換するとBoardSerialNumberは違うものになる可能性があります。

SerialNumberとBoardSerialNumberはとても重要です。これが正しい値に設定されていない場合、iMessageやApp Storeなどが正しく機能しない場合があります。2014年8月から2015年2月にかけて、iMessageでのシリアル番号チェックが非常に厳しくなった時期がありました。これをきっかけにシリアル番号のリバースエンジニアリングが進みました。

シリアル番号

Macのシリアル番号には11桁のものと12桁のものがあります。古い機種は11桁で、最近の機種では12桁です。それぞれの桁は、以下のような意味があります。

| Type | Location | Year | Week | Line | Platform |
| --------- | --------- | ---- | ---- | ---- | -------- |
| Old (11) | LL | Y | WW | SSS | PPP |
| New (12) | LLL | Y | W | SSS | PPPP |

以下では、以下のiMac15,1のシリアル番号の例（12桁）を使って説明します。

C02PJTYNFY10

製造場所番号(2 or 3桁)

最初の3桁 C02は製造国、製造都市、メーカなどを表します。C02は中国のQuantaコンピュータが製造したという意味だそうです。他に判明している3桁コードは以下です。

 - C02, China (Quanta Computer)
 - C07, China (Quanta Computer)
 - C17, China
 - C1M, China
 - C2V, China
 - CK2, Ireland (Cork)
 - D25, Unknown
 - F5K, USA (Flextronics)
 - W80, Unknown
 - W88, Unknown
 - W89, Unknown
 - CMV, Unknown
 - YM0, China (Hon Hai/Foxconn)
 - DGK, Unknown

ちなみに11桁シリアル番号では製造場所コードは2桁です。以下の意味だそうです。

 - CK, Ireland (Cork)
 - CY, Korea
 - FC, USA (Fountain, Colorado)
 - G8, USA
 - QP, USA
 - XA, USA (ElkGrove/Sacramento, California)
 - XB, USA (ElkGrove/Sacramento, California)
 - PT, Korea
 - QT, Taiwan (Quanta Computer)
 - UV, Taiwan
 - RN, Mexico
 - RM, Refurbished Model
 - SG, Singapore
 - W8, China (Shanghai)
 - YM, China
 - H0, Unknown
 - C0, China (Quanta Computer, Tech-Com)
 - C3, China (Shenzhen, Foxconn)
 - C7, China (Shanghai, Pegatron)
 - MB, Malaysia
 - EE, Taiwan
 - VM, Czech Republic (Pardubice, Foxconn)
 - 1C, China
 - 4H, China
 - MQ, China
 - WQ, China
 - 7J, China (Hon Hai/Foxconn)
 - FK, China (Zhengzhou, Foxconn)
 - F1, China (Zhengzhou, Foxconn)
 - F2, China (Zhengzhou, Foxconn)
 - F7, China
 - DL, China (Foxconn)
 - DM, China (Foxconn)
 - 73, Unknown

RMは整備品であることを表しています。

製造年(1桁)

例に示したシリアル番号の、次の一桁であるPは製造年を表します。12桁のシリアル番号では各年号に英字が割り当てられています。ペアの最初の英字が1-6月で、後半が7-12月を表しているそうです。なので、Pは2015年前半を表します。アルファベットのうち英字のI, Oなどが抜けているのは1や0と間違えやすいからだと思われます。他の欠番も何か理由があってのことと思います。

| Pair | Year |
| -------- | ---- |
| `C`, `D` | 2010 |
| `F`, `G` | 2011 |
| `H`, `J` | 2012 |
| `K`, `L` | 2013 |
| `M`, `N` | 2014 |
| `P`, `Q` | 2015 |
| `R`, `S` | 2016 |
| `T`, `V` | 2017 |
| `W`, `X` | 2018 |
| `Y`, `Z` | 2019 |

追記 : 上記の方式では2020にコードを使い切ることになります。実際にどうなったかというと、iMacの2020年モデルでは、こちらで紹介したように、CとDが使われています。2010のコードを再利用しているようです。(2020/8/14)

11桁シリアル番号では、製造年は西暦一桁めの数値です。

| Char | Year |
| ---- | ---- |
| `3` | 2003 |
| `4` | 2004 |
| `5` | 2005 |
| `6` | 2006 |
| `7` | 2007 |
| `8` | 2008 |
| `9` | 2009 |
| `0` | 2010 |
| `1` | 2011 |
| `2` | 2012 |

こちらは2012年に一巡して破綻してます。現行のシリアル番号も2020年以降の年番号がどうなるのか心配です。

製造週(2 or 1桁)

例に示したシリアル番号の、次の一桁であるJは製造週を表します。これは1月1日から始まる7日を最初の週としています。なので最後の週以外は全て7日間です。次の27種類の英数字が使われます。シリアル番号の例では、2015年の前半年とわかりましたので、Jは15週目を表しています。

| Char | 1st half | 2nd half |
| ---- | -------- | -------- |
| `1` | `1` | `27` |
| `2` | `2` | `28` |
| `3` | `3` | `29` |
| `4` | `4` | `30` |
| `5` | `5` | `31` |
| `6` | `6` | `32` |
| `7` | `7` | `33` |
| `8` | `8` | `34` |
| `9` | `9` | `35` |
| `C` | `10` | `36` |
| `D` | `11` | `37` |
| `F` | `12` | `38` |
| `G` | `13` | `39` |
| `H` | `14` | `40` |
| `J` | `15` | `41` |
| `K` | `16` | `42` |
| `L` | `17` | `43` |
| `M` | `18` | `44` |
| `N` | `19` | `45` |
| `P` | `20` | `46` |
| `Q` | `21` | `47` |
| `R` | `22` | `48` |
| `T` | `23` | `49` |
| `V` | `24` | `50` |
| `W` | `25` | `51` |
| `X` | `26` | `52` |
| `Y` | `-` | `53` |

11桁のシリアル番号では週は2桁で表記されて、週の数値がそのまま、00から53までの数値で表現されます。

製造ライン(3桁)

例に示したシリアル番号の、次の3桁であるTYNは製造ラインもしくは、組み立て担当者のIDを表していると考えられています。それぞれの桁は、IとOを除く0からZまでの英数字を0から33に割り当てた数値を表しています。この3桁は、製品個体ごとに違い、一台一台を特定する部分です。

| Char | Value | Char | Value |
| ---- | ----- | ---- | ----- |
| `0` | `0` | `H` | `17` |
| `1` | `1` | `J` | `18` |
| `2` | `2` | `K` | `19` |
| `3` | `3` | `L` | `20` |
| `4` | `4` | `M` | `21` |
| `5` | `5` | `N` | `22` |
| `6` | `6` | `P` | `23` |
| `7` | `7` | `Q` | `24` |
| `8` | `8` | `R` | `25` |
| `9` | `9` | `S` | `26` |
| `A` | `10` | `T` | `27` |
| `B` | `11` | `U` | `28` |
| `C` | `12` | `V` | `29` |
| `D` | `13` | `W` | `30` |
| `E` | `14` | `X` | `31` |
| `F` | `15` | `Y` | `32` |
| `G` | `16` | `Z` | `33` |

この3桁の値は次の式でIDに変換されているようです。

1桁目 x 68 + 2桁目 x 34 + 3桁目

この例のTYNは、それぞれ27, 32, 22を表し、上の式から2,946になります。

27 x 68 + 32 x 34 + 22 = 2,946

製造コピー

上の計算式はちょっと変わっています。34進数だと考えたら最初の桁は34×34倍すべきなのですが、68倍になっています。何か根拠のある計算式ではあると思われますが、この計算では、得られる数値に重複が発生します。

例えば、 0L0, 1J0, 2G0, 3E0, …, 920という複数の英数字が、どれも680という製造ライン番号になります。別の例では、KYL, LWL, MUL, …, Z4Lという英数字は、どれも2400という数字になります。同じ数値になってしまう英数字の組を、製造コピーと呼んでいます。最初の桁の値の小さい方から1, 2, 3,…と番号をつけます。この例では、0L0やKYLがコピー1、1J0やLWLがコピー2などです。920と74Lは、最後のコピーです。英数字の組み合わせによりコピーの総数は変わります。色々な実験で、最初のいくつかのコピーだけが、Appleから有効だと判定されるようです。無効だと判定されたコピー番号より大きな番号のコピーは全て無効になります。Apple内部のことはもちろんわかりませんが、一つのラインから製品が製造されるごとに、コピー値が増加するのではないかと推定されています。何れにしても、ある値を示す製造ライン番号のうち、最初のコピーを使用するのが安全であると言えます。

プラットホームモデル(3 or 4桁)

11桁シリアルでは最後の3桁、12桁シリアルでは最後の4桁が、製品種類を表す番号です。例に示したシリアル番号では、最後の4桁であるFY10がこのプラットホームモデルです。この4桁が製品機種を表していることは、以下のURLにアクセスすることで確認できます。

http://support-sp.apple.com/sp/index?page=cpuspec&cc=PPPP

ここのPPPPの部分にFY10を入れてアクセスすると

http://support-sp.apple.com/sp/index?page=cpuspec&cc=FY10

iMac15,1の仕様書ページにリダイレクトされます。iMac15,1にはLate 2014とMid 2015の2機種がありますが、このモデルはMid 2015年のiMacであることがわかります。

ちなみに一つの機種ID（例えばiMac15,1）が全て同じプラットホームモデル（ここではFY10）になるわけではありません。同じ機種IDでも製造時期が違うと仕様が異なります。それで複数のプラットフォームモデルが割り当てられています。例えば、iMac15,1に相当するプラットホームモデルは、以下の27種類が確認されています。

"FY10", "FY11", "FY14", "FY68", "FY6F", "GCTM", "GDQY", "GDR3", "GDR4", "GDR5", "GDR6", "GDR7", "GDR8", "GDR9", "GDRC", "GFFQ", "GJDM", "GJDN", "GJDP", "GJDQ", "FY13", "FY6D", "GL1Q", "GL1R", "GL1T", "GL1V", "GL1W"

シリアル番号の注意事項

シリアル番号は上記のフォーマットに従って、適切な値が入っている必要があります。そうしないと、iMessageへのアクセスなどでAppleから無効なモデルと判定される可能性があります。

また、細かい整合性もチェックしておいた方が良いと思われます。例えば、製造年、製造週は、プラットホームモデルが示す発売日より後の日付である方が良いでしょう。また、製造ラインのコピー数は、できるだけ小さい値、できればコピー1である方が安全です。

上の例で示したC02PJTYNFY10は、

Country: C02 - China (Quanta Computer)
Year: P - 2015 (前半)
Week: J - 15 (2015年4月9日-2015年4月15日)
Line: TYN - 2946 (copy 1)
Model: FY10 - iMac15,1 Retina 5K, 27 inch, Mid 2015, 2015年5月発売

となります。製造日が発売日より早いのが気になりますが、発売日に備えて前もって製造しているはずなので、それほど不自然ではないと思います。

また、下記のサイトで生成したシリアル番号が未使用であることは、確認しておくべきかと思います。「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。

ボードシリアル番号

SMBIOSでもう一つ設定しないといけない番号がボードシリアル番号です。12桁シリアル番号の場合、ボードシリアル番号は17桁です。ロジックボードのシリアル番号です。修理によってロジックボードは交換される可能性があることもあり、Appleはそれほど厳密にはチェックしていないと感じています。昔のガイドでは、12桁のシリアル番号に適当な英数字を5個足しておけば良いとか、LANのMACアドレスの一部を足しておけば良いなどというゆるい手法が説明されていることもあります。

Clover configuratorなどに搭載されている最近のシリアル番号発生機能では、シリアル番号と対になってボードシリアル番号も作り出してくれます。それを採用しておけば良いです。例えば、先の例で使用したシリアル番号C02PJTYNFY10と対で生成されたボードシリアル番号は

C02514701CDG2Y71H

でした。これを例に構成を調べていきます。

製造場所番号(3桁)

シリアル番号と同じで、最初の3桁は製造国、製造都市、メーカなどを表します。この例のC02は中国のQuantaコンピュータです。

製造年(1桁)

4桁目は年号です。西暦年号の1の位です。この例では、シリアル番号が2015年なので、それに合わせて5になっているようです。

製造週(2桁)

次の2桁は製造週です。上の例では、14週目の製造という意味です。シリアル番号は15週目でした。ロジックボードが製造されたあとで、本体が製造されるのが自然ですから、前の週に製造されたことにしているのだと思います。

MLBBlock1(3桁)

以下のいずれか一つの数値です。Clover configuratorやmacserialが自動生成する場合には、この中から乱数で選んでいるようです。

"200", "600", "403", "404", "405", "303", "108", "207", "609", "501", "306", "102", "701", "301", "501", "101", "300", "130", "100", "270", "310", "902", "104", "401", "902", "500", "700", "802"

MLBBlock2(2桁)

以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。

"GU", "4N", "J9", "QX", "OP", "CD", "GU"

ボードコード(3 or 4桁)

ロジックボードの種類を示す英数字です。一つのモデルに対して多数のコードが発見されているようです。例えば、上の例のiMac15,1では、以下のコードが使われているようです。このリストのうち、最初のコードG2Y7が、問題が少ないとされているので、これが使われることが多いようです。

"G2Y7", "G2Y8", "GG3L", "GG3N", "G2QD", "G2QF", "GG3T", "GG3W", "FT04", "FW6K", "GG3K", "GG3M", "FW29", "FW2C", "GG3Q", "GG3V", "FQY8", "FTPF"

MLBBlock3(2桁)

以下のいずれか一つの英数字です。自動生成する場合には、この中から乱数で選んでいるようです。

"1H", "1M", "AD", "1F", "A8", "UE", "JA", "JC", "8C", "CB", "FB"

ボードシリアル番号の注意事項

上記で、「自動生成する場合には乱数で選んでいる」と書きましたが、生成プログラムのソースを見ると、チェックサムも考慮しています。ボードシリアル番号が表す値を、最初から奇数番目の桁はそのまま、偶数番目の桁は3倍して足していき、その合計が34の倍数である場合は正しいチェックサムを持ったボードシリアル番号としているようです。正しいチェックサムになるまで、ランダムに候補を選んでいるようです。手作業では面倒なので、自動生成ツールを使うのが良いです。

機種のシリアル番号に比べて、ボードシリアル番号はAppleにより厳しく検査されることはないので割と適当でも大丈夫な印象があります。シリアル番号の製造週より前の製造週にしておいた方が良いでしょう。自動生成ツールでは、シリアル番号の前の週になるように生成しているようです。ただ、ロジックボード交換修理する可能性も考えると、それもチェックされていないと思います。何れにしても、以下の自動生成ツールを使えば、整合性のある番号を生成してくれますので問題ありません。

シリアル番号自動生成ツール

シリアル番号はClover configuratorでも生成できますし、この記事の冒頭で示したmacserialというツールでも生成できます。おそらくはClover configuratorもmacserialと同じアルゴリズムを使っているのではないかと思います。macserialは、冒頭のリンクからソースコードを入手してコンパイルしても良いです。また以下のサイトで、コンパイル済みのコードも配布されています。

Releases · acidanthera/macserial

更新：現在は以下で配布されているようです (2019/12/28)。

Releases · acidanthera/MacInfoPkg

更新2 : 現在はOpenCoreに含まれています (2020/8/14)。

GitHub - acidanthera/OpenCorePkg: OpenCore bootloader

現時点では2.0.4が最新のようです。mac版とwindows 32版があるようです。zipをダウンロードすると解凍されてmacserialというファイルができます。

$ ./macserial

として起動すると、現在のMac/Hackintoshのシリアル番号などの情報が表示されます。–helpとすれば使い方の説明が表示されます。

$ ./macserial --help
./macserial arguments:
 --help (-h) show this help
 --version (-v) show program version
 --deriv <serial> (-d) generate all derivative serials
 --generate (-g) generate serial for current model
 --generate-all (-a) generate serial for all models
 --info <serial> (-i) decode serial information
 --list (-l) list known mac models
 --mlb <serial> generate MLB based on serial
 --sys (-s) get system info

Tuning options:
 --model <model> (-m) mac model used for generation
 --num <num> (-n) number of generated pairs
 --year <year> (-y) year used for generation
 --week <week> (-w) week used for generation
 --country <loc> (-c) country location used for generation
 --copy <copy> (-o) production copy index
 --line <line> (-e) production line
 --platform <ppp> (-p) platform code used for generation

–generateオプションで現在モデルのシリアル番号とボードシリアル番号を複数生成してくれます。–generate-allで全てのモデルの番号を生成します。–model Macmini8,1などとすれば特定のモデルの番号を生成してくれます。–info シリアル番号でそのシリアル番号を分析してくれます。例えば、この記事で例に使ったC02PJTYNFY10でしたら、

$ ./macserial --info C02PJTYNFY10
 Country: C02 - China (Quanta Computer)
 Year: P - 2015
 Week: J - 15 (09.04.2015-15.04.2015)
 Line: TYN - 2946 (copy 1)
 Model: FY10 - iMac15,1
 Valid: Possibly

のように表示されます。

ASUS MAXIMUS XI HEROにM.2 SSD (WD SN750)を取り付ける

Mon, 11 Mar 2019 18:08:02 +0900

Z390チップセットの9900Kマシンは順調に動いているのですが、起動ドライブは手元にあった2.5 inch SSDを流用してました。これを今風のM.2 SSDに交換しました。

9900K搭載Z390マザーボードでHackintoshを作る

ストレージ構成をどうするか

ATX基板を使っていますし、ケースはそれなりの大きなケースを考えているので、SATAケーブルで接続するドライブはいくつか使用するつもりです。大容量の3.5 inch HDDを2台くらいは使って、片方をデータの倉庫に、もう一方をTimeMahineのバックアップに使おうと考えています。Windowsは滅多に使わないのですが、気が変わってWindows用に2.5 inch SSDを一個くらい付けるかもしれません。

M.2 SSDは高速・小型なので、将来はM.2が主流になって、SATAケーブルで接続するドライブはマイナーな存在になると思います。ただ現状では、M.2 SSDは、割高ですし、体感速度で考えると2.5 inch SSDとそれほど違わないし、他のマシンやMacにつなぎ変えて動作を確認するなどの場面では取り外し・取り付けが面倒です。ということで、メインで作業するデータ領域（/Users）は、2.5 inch SSDにして、システム領域（/、/System、/Applications、/Libraryなど）だけをM.2 SSDにするのが良いと考えました。ということで、ゆくゆくは

250GB程度のシステム用（root用）M.2 SSD
1TB程度のデータ用（/Users）2.5 inch SSD
4TB程度のTimeMachine用3.5 inch HDD
4TB程度のデータ倉庫用3.5 inch HDD

の構成を考えています。

M.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はコントローラがかなり高温になったものですが、この製品はそれほど発熱しないような気がします。

最近のSSDの低価格化に寄与している技術が、記憶セルあたりの情報量を増やす手法です。通常のメモリは、セルに電荷を貯める・貯めないの2状態で1ビットを記録します。貯める電荷量を、3段階にすれば、電荷が無い状態を含めて4状態になり、2ビット記録できます。記憶セルあたり1ビット記録する方式をSLC (シングルレベルセル)、2ビットをMLC (マルチ〜)と呼ぶようです。さらに8状態にして3ビット記録するTLC (トリプル〜)や、16状態にして4ビット記録するQLC (クアドラプル〜)があるようです。セルあたりの記憶量を増やすことで、低価格なSSDが作れます。その一方で、速度や耐久性が弱くなると指摘されています。WD BLACK SN750はTLCのSSDのようです。（最初の記事ではSLCだと勘違いしていました。訂正します。）若干不安はありますが、ちゃんとした製品なので当然のことですが、何の問題もなく動いています。

マザーボードに取り付ける

ASUS MAXIMUS XI HEROにはSSD用に2個のM.2ソケットが用意されています。

マザーボードの中央、CPUの近くにあるM.2_1と、マザーボードの端にあるM.2_2です。それぞれ多少機能が違います。

M.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対応なのでヒートシンクが大きく、多少は放熱性能が良いと考えたからです。

Hackintoshのインストール

すでに2.5 inch SSDでHackintoshが動いているので、この先の作業は簡単です。成功することが見えているようなものです。

M.2 SSDをソケットに取り付ける
現在の2.5 inch SSDで起動してM.2 SSDをAPFSでフォーマットする
App StoreからmacOS Mojaveインストール.appを入手する
macOS Mojaveインストール.appを起動してM.2 SSDにmacOSをインストールする
（インストール中に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ドライブのように変換してくれるアダプタがあると便利です。

macOSのインストールが終わったら、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に問題なく移行できました。

Hackintoshの作り方（総集編:10.14版）

Fri, 08 Feb 2019 15:54:05 +0900

macOSをインストールする方法をご紹介してきたのですが、多数の記事に分散してしまっています。そこで、10.14 Mojaveをインストールするための参考になる関連記事へのポインタをまとめた総集編を作りました。より新しい10.15を対象とした情報は以下をご覧ください。

Hackintoshの作り方（総集編: macOS 10.15版）

古い10.13を対象とした情報は、以下をご覧ください。

Hackintoshの作り方（総集編:10.13版）

手順の概要を把握する

/posts/121/

/posts/131/

ハードウェアを用意する

Hackintoshを作るためには、互換性のあるハードウェアを自由に選んで組み合わせられる自作PCが、問題が少なく楽です。ノートPCなども可能ではありますが、上級者向けだと思います。以下では、第9世代CPUであるCoffee Lake-S Refreshで作った自作PCにMojaveをインストールする手順を書いておきましたので、参考にしてください。

9900K搭載Z390マザーボードでHackintoshを作る

CPUは、最新の第9世代Coffee Lake-S Refreshが良いと思います。Macで採用されている最新CPUは第8世代です。例えば最新Mac miniでは、モバイル版ではありますが、第8世代CPUが使われています。ピンが半田付け方式なだけで、デスクトップの第8世代Coffee Lake-Sと同じCPUですので、第8世代Coffee Lake-Sでも良いでしょう。インテルは現在、CPUの量産体制に問題があり、第8世代もローエンドモデルを中心にまだ現役ですので、入手は容易です。

Hackintoshのパーツ選び【その1：CPU編】

そうすると、マザーボードは、CPUに合わせて370もしくは390チップセット搭載マザーボードを選ぶことになります。ただ、これもわざわざ古いマザーボードを選ぶ理由はないので390チップセットが良いと思います。

Hackintoshのパーツ選び【その2：マザーボード編】

MojaveではNVIDIAのweb driverがサポートされなくなってしまいました。なので、グラフィックスカードはAMDしか選択肢はありません。Web driverが不要な古いNVIDIAなら使えますが、古い製品をこれから調達することもないと思います。詳しくは以下を参考にしてください。

HACKINTOSHのパーツ選び【その3：グラフィックス編】10.14以降版

無線アダプタ、SSD, そのほかのパーツについても紹介しておきました。

/posts/138/

Hackintoshのパーツ選び【その5：SSD】

Hackintoshのパーツ選び【その6：その他】

マザーボードのBIOS/UEFIを設定する

インストール先のコンピュータを組み上げたら、macOSが稼働するようにBIOS/UEFIを設定しておきます。この設定が間違っていると、それだけで起動しない場合もあります。

マザーボード (BIOS) 設定

必要なソフトウェアを入手する

Hackintoshするには、macOS本体以外にオープンソースで有志が開発しているソフトウェアがいくつか必要です。必要なソフトウェアの名前で検索すれば、大抵の場合、ダウンロード先が見つかります。オープンソースのソフトウェアは、オリジナルを作った人の他に、いろいろな人がソースコードを引き継いで分岐（フォーク）して、開発を行なっている場合もあります。中には元祖の開発者が放置して、開発が止まっていることもあります。なので、検索して、現在一番活発に利用されているバージョンを使うのが良いです。ということで、古いハウツー情報のダウンロード先から入手するよりも、検索をして探すのがおすすめです。

Clover EFI bootloaderとefiドライバー

“Clover EFI bootloader”で検索します。以下が本家かと思われます。

https://sourceforge.net/projects/cloverefiboot/

こちらでも最新版が配布されています。

Releases · Dids/clover-builder

Cloverをダウンロードすると、インストーラ、efiドライバ、テーマファイルなども一緒に入手できます。

kext類

FakeSMCをはじめとしたkext （カーネル拡張）が必要です。名前で検索します。例えば、FakeSMC.kextならば、”FakeSMC.kext”で検索すると、こちらで入手可能なことがわかります。

RehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket

こちらで紹介したKext Updaterを使うと、kextやCloverを個別にダウンロードすることもできます。こまめに更新されているので、最新版を確実に入手することができます。

Mac上で導入用のUSBメモリを作る

次に、macOSを入手して、インストール用のUSBメモリを作ります。これは実際のMacで作業します。ついでに、実際のMacでこのUSBメモリが起動することを確認しておきましょう。次に、インストール対象のマシンで起動できるように、Cloverのインストールと設定も行っておきます。

/posts/93/

Mac上でmacOSドライブを作る

冒頭で示した動画を含めて、多くのガイドではMac上で導入用のUSBメモリを作る方法を紹介しています。でも、最近では、本物のMacやHackintoshなどのmacOSが動くマシン（以下、親マシンと書きます）上でmacOSドライブを作る方が楽な気がしてきました。特にMojaveになったあたりから、createinstallmediaで作ったUSBメモリーからインストールしようとすると途中で止まってしまうことが時々あります。他のドライブを外したりすると解決することもありましたが、親マシンでインストールした方が確実です。

そこで、Hackintoshで使おうとするSATA SSDドライブ、mSATA SSDカード、M.2 SSDカードなどを、直接、もしくは、USB外付けHDDケースに入れて、親マシンに接続します。これをGUIDパーティションマップでフォーマットします。パーティションのフォーマットはHFS+でも良いですが、インストール時にAPFSに変更されるので、最初からAPFSで良いかと思います。

9900K搭載Z390マザーボードでHackintoshを作る

macOSのインストール途中で、何度か再起動することがあります。親マシンがHackintoshの場合は、インストール途中のCloverの起動画面で、”Boot macOS Install from (インストール先のボリューム名)”という項目を選びます。

Cloverとkextを入れる

親マシンで起動できるmacOSディスクが出来上がったら、親マシンに接続したまま、Cloverをインストールします。Cloverインストールの手順はこちらにも書いてあります。

Cloverインストーラの設定

config.plistの例を示して、説明しました。

config.plistの実例紹介

config.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。

正しく機種設定する (SMBIOSの設定)

corpnewtさんのバニラガイド~Coffee Lake用config.plist

Cloverをインストールしたら、次にkext類をESPの部分に入れます。kextについてはいくつかの記事で解説しましたが、こちらが簡潔かもしれません。

CORPNEWTさんのバニラガイド~ Clover設定とkext

macOS環境を整える

/posts/90/

Ethernetを設定する

/posts/120/

kextはどこに置けば良いのか

Sat, 02 Feb 2019 22:17:14 +0900

今までkextファイルはEFI/Clover/kexts/Otherに置くと良いと紹介してきました。でも以下の投稿によるとそれは「全く正しくない」のだそうです。

今回はHackintoshに必要なカーネル拡張ファイル（kextファイル）を置く場所に関する議論を紹介します。（コメントで紹介いただいた情報です。ありがとうございます。）

kextを/L/Eに置く利点と方法

上記の投稿にはkextを/L/Eに置くべきである理由と、推奨するkextの置き方が書かれています。抄訳します：

macOSの流儀である

FakeSMCなどを含むすべての3rdパーティkextは/Library/Extensions (以下/L/E) に置くべきです。多くの人が「これらのkextをEFI/Clover/kexts/Other (以下ESP) に置き、config.plistでInject KextsをYESにすることが、メンテナンスフリーであり、よりネイティブなmacOSインストール方法だ」という印象を持っているように思えます。しかしこの考えは完全に間違っています。

この俗説とは逆に、Cloverに3rdパーティkextをインジェクトしてもらうことは、クリーンなインストールにはならないどころか、その逆です。インジェクトされたkextはmacOSの保護メモリー空間の外側で機能します。大量のkextをインジェクトすると、システムが不安定になる可能性があります。Cloverによってインジェクトされる多くの3rdパーティkextは正しく動きません。インジェクトされたkextはカーネルキャッシュに含まれず、その結果macOSが行うエラー検査の対象外になります。kextを/L/Eに置くことは、アップルが推奨しています。何らかの周辺機器を買ってドライバをインストールする時、kextは/L/Eにインストールされます。Hackintoshのkextも同じです。

Cloverのkext読み込み機能の目的

/L/Eに追加のkextを置くのが正しいやり方なのだとしたら、なぜCloverはESPに置いたkextをインジェクトする機能を持っているのでしょうか？それは、次のような形式のmacOS、つまり

MacOS Installer
MacOS Updater
MacOS Recovery

をブートする場合に、最小限必要なkextを読み込むために必要だからです。これらはどれもフルサイズのmacOSではないため、通常の方法では必須kextを読み込めないので、Cloverがそれを行う必要があるのです。ほとんどの場合、これらのパッケージを機能させるためには、通常はEFI/Clover/kexts/Other に FakeSMC があれば良いです。場合によっては3rdパーティのストレージ制御用ドライバ、NASで動かすTimeMachineバックアップへのアクセス用ドライバ、ノートPCのマウス用ドライバなどが必要なこともあります。このような、本当に必要なkextだけをEFI/Clover/kexts/Otherに入れます。

CloverのDetect設定

Hackintoshに必要なkext類を、

通常のmacOSブート時は、/L/Eにkextを置いてmacOSでロードしつつ、
Installer/Updater/Recoveryの時だけESPに置いてCloverでインジェクトする

ように設定するには以下のようにします。

Cloverのconfig.plistのSystem Parameters セクションでは、Inject Kextsの設定ができます。ここでは、Cloverがkextをインジェクトしてくれるよう、通常はYESを設定します。

<key>InjectKexts</key>
<string>YES</string>

これをDetectに設定すると、

<key>InjectKexts</key>
<string>Detect</string>

Cloverは/L/Eにあるkextを調べて、

FakeSMCが/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を使えることになります。

抄訳はここまでです。

/L/Eにkextを入れる方法

今まではバニラな方法しか説明していませんでした。/L/Eにkextを入れるとするといくつかの手順が必要です。

まずはHackintosh用のkext類は、当然ながらアップル社の承認を受けていませんので、「署名されていないkextも動く」設定にSIP (System Integrity Protection)を設定する必要があります。これにはconfig.plistで

<key>CsrActiveConfig</key>
<string>0x01</string>

と設定します。また、/L/Eに必要なkextをコピーした後で、パーミッションを設定して、キャッシュを作り直す必要があります。ターミナルから行うには、

sudo cp -R *.kext /Library/Extensions/.
sudo chown -R 0:0 /Library/Extensions/*.kext
sudo kextcache -i /

などとします。*.kextの部分は、追加するkextだけ指定すれば良いです。これで再起動するとキャッシュが再構成されます。

kextをESPに置く利点と欠点

以上で、/L/Eにkextを置く方法が良いという意見とその実際を紹介しました。kextをESPに置くバニラな方法と比較して、長所短所を検討してみます。

macOSの流儀からは外れる

macOSの設計では追加のkextは/L/Eに置くべきのようです。Cloverがインジェクトする方法では、メモリー不足になる可能性があるようです。ただ、そのような報告はあまり聞いたことがないので、実際には支障はないのかもしれません。

また、/L/Eに置くと、キャッシュに入れる際にkextのエラーチェックをしてくれるそうです。ただこれも、kext開発者でなければあまり恩恵の無い機能のように思います。ちなみに、/L/Eに置くと、そのkextがシステム情報–>ソフトウェア–>拡張機能に現れます。これを使って得られる情報がトラブル対応の参考になるかもしれません。

ESPでは動かないkextもある

一部の kextはESPでは正しく動きません。これらは/L/Eに置かざるを得ません。ただ、そのようなkextは少数で、大体はESPで動きます。

SIPを有効にできる

もともとHackintoshのkextは、macOSの規格外の拡張です。なので署名が無く、/L/Eで有効にするにはSIPで署名の無いkextを許可する設定が必要です。せっかくのSIPの仕組みなので、マルウェア対策としてSIPは有効のまま使いたい気がします。もちろんESPにkextを置くことも同様に危険なことですが、Hackintoshを狙ったマルウェアは少なそうですし、署名のあるkextと、署名の無いkextを、/L/EとESPに分けて管理するのは、セキュリティ対策として有効です。/L/EにHackintoshのkextを入れると、混在してしまいます。

ESPに置くと管理が楽

/L/Eに置くと、パーミッションを設定し、キャッシュを作り直す手間がかかります。ESPへ置くのはコピーするだけなので簡単です。また、上記で説明したInject KextsをDetectにする手法では、/L/EとESPの両方にkextを置かないといけません。この方式ではkextの入れ替えや、アップデートの手間が倍以上になります。/L/Eにkextを簡単に置くためのツールもありますが、手間が増えることには変わりありません。

以上のことを考えると、このままバニラな方法（ESPに置く方法）を続けても良いように思いました。

Cloverのテーマ

Sun, 27 Jan 2019 17:00:26 +0900

Cloverが起動した直後に、起動ドライブや起動オプションの選択をする画面があります。この画面はカスタマイズ可能で、色々な人が凝った画面を作ってくれています。これらの「テーマ」は以下のサイトなどで配布されています。

Clover EFI bootloader / Themes / [649fa8] /themes

設定方法

ここから気に入ったテーマのフォルダをダウンロードして、EFI/CLOVER/themes/フォルダの中に入れます。次に、（例えばフォルダの名前がMinimalismの場合）config.plistで

	<key>GUI</key>
	<dict>
		<key>Theme</key>
		<string>Minimalism</string>
	</dict>

のように設定します。config.plistや起動ドライブを変えて色々実験する時に、それぞれ違ったテーマを設定しておけば、切り替えられたことを確認できて便利です。

CORPNEWTさんのバニラガイド~ Clover設定とkext

Sat, 26 Jan 2019 17:01:20 +0900

Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Cloverの設定」と「kextを集める」のページをご紹介します。Hackintoshで使うカーネル拡張(kext)ファイルを簡潔に説明しています。

Page not found

（ここから抄訳）

Cloverをインストールする

Cloverインストーラパッケージを起動します。インストーラの2番目のページで、インストール先（USBメモリとかSSD/HDD）を選択するよう気をつけます。また、デフォルト設定はイマイチなので、カスタマイズします。（訳注：図は私が用意したスクリーンショットです）

左下のカスタマイズボタンを押すとカスタムインストールのページが出ます。ここで、以下を選択します。

「UEFIブート用にインストール」
「ESPにインストール」
Drivers64UEFIの中の設定（訳注：現在バージョンではUEFI Drivers）
- AptioMemoryFix: VRAM に関する修正を含んだ新版です。より良いメモリ管理をします。
- VBoxHfs-64.efi: 入手できれば HFSPlus.efiでも良いです。CloverがHFS+起動ボリュームにアクセスするために必要です。HFS+で起動したいのに、起動オプションに現れないようなら、 EFI -> CLOVER -> drivers64UEFI フォルダにこれが入っていることを確認すると良いです。
- ApfsDriverLoader: Didsさんの Cloverビルドもしくはこちらから入手可能です。これはCloverがAPFS起動ボリュームにアクセスするために必要なapfs.efiを、ブロックデバイスのApfsContainerからロードします。もしAptioMemoryFixを使用しているなら、R21以降が必要です。（訳注：現在バージョンでは最新版が入っているので項目を選択するだけです）

以上です。

もしもFileVaultが不要で、標準的なUEFIインストールをするだけなら、これらが必要なものの全てです。これ以外のものも、Drivers64UEFIセクションに現れます。しかし、選択しなくても良いです。むしろ他の設定と衝突する項目（例えば SMCHelper-64.efi ）すらあります。なのでDrivers64UEFIセクションでの選択は最小限にするのが良いです。

（訳注：最近のCloverインストーラではFileVault関係のefiはFileVault 2 UEFI Driversという別のセクションに分類されました。FileVaultを使わなければ、多分誰も使わないと思いますが、これは全部除外して良いです。このガイドでは3個のefiしか必要ないと書かれていますが、ハードウェアによってはこれ以外が必須のこともあります。EmuVariableUefiが必要だったり、AptioMemoryFixの代わりにOsxAptioFixDrvが必要だったりします。）

Kextをコピーする

Cloverのインストールが終了したら、/Volumes/EFI/EFI/CLOVER/kexts/Otherに移動して「kextを集める」で用意したkextをここにコピーします。 .dSYMファイルは不要です。.kextだけが必要です。

/Volumes/EFI/EFI/CLOVER/kextsフォルダの中には、Otherフォルダと、10.xxフォルダがあります。この違いは以下です。Cloverがkextをインジェクトしようとするとき、10.xxフォルダのkextは、macOSのバージョンが合致している時だけインジェクトされます。ところがmacOSのバージョンに依存するkextはほとんどありません。また、macOSをアップデートした時にそのバージョン番号のフォルダを用意することを忘れてしまうと、起動できなくなってしまいます。Otherフォルダのkextは、検出されたmacOSバージョン番号とは関係なくインジェクトされます。なのでOtherフォルダを使うことをお勧めします。

必要なkextはどれ？

VirtualSMC.kextは必須です。これはMacに搭載されているSMC (System Management Controller) チップをエミュレートしてくれます。これによりOSは本当のMacだと思い込みます。これなしではHackintoshできません。

以下のすべてのkextはGoldfish64さんにより整備されたこちらのサイトで入手可能です。それぞれのkextは更新されると自動的にビルドされます。自分でビルドしたかったら私のLilu And Friendsのスクリプトを使用してください。

Ethernet関係

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も必要になると思います。

10.11からアップルはUSBコントローラごとに15個のポート数制限をしています。大した問題ではないと思われるかもしれませんが、USB 3ポートは2個（USB 3として1個、USB 2として1個で合計2個）としてカウントされますので、この制限には割と簡単に到達してしまいます。

Skylake以降では、USB 2とUSB 3はXHCIとしてのみ扱われて、それぞれのUSB 3が2個としてカウントされ、すぐに制限に達します。USB 2をEHCIに割り当てることで改善する方法もあります。これにはRehabManさんの FakePCIID.kext + FakePCIID_XHCIMux.kext を使います。これによりXHCIの負担を軽減します（ただし一部のチップセットでしか機能しません）。

Audio関係

マザーボードのAudioチップがサポートされたコーデックであるなら、/u/vit9696さんの AppleALC.kext と、これと一緒に使う Lilu.kext が必要です。AppleALCはAppleHDA.kextに動的にパッチ当てし、macOSのオーディオでサポートされていないコーデックを動かす機能があります。スリープ復帰後のオーディオ機能を手助けする機能もあります。

Graphics関係

GPUのためには、WhateverGreen.kextと、支援kextである Lilu.kextを使うべきです。これは、以前は別々のkextであった、IntelGraphicsFixup, NvidiaGraphicsFixup, CoreDisplayFixup, Shikiの機能を合わせ持っています。

WiFi と 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 から入手可能です。

その他

使用するハードウェアに応じて、これ以外のkextも必要になるかもしれません。でもこのガイドは一般的で基礎的な内容を目指したので、あとはGoogleで検索してください。

ASUS Z390マザーボードのshutdown/sleep対応

Tue, 22 Jan 2019 22:55:15 +0900

ASUSのZ390マザーボードで作ったHackintoshのその後の報告です。

9900K搭載Z390マザーボードでHackintoshを作る

シャットダウンが不完全な問題を解決すべく試行錯誤したところで、EmuVariableUefi-64.efiを使うことで解決しました。あまりにも呆気ない結末なのですが、EmuVariableUefi-64.efiがshutdownに関係するのは知りませんでしたし、もしかして困っている人がいるかもしれないので紹介します。

シャットダウンの症状

症状が出たマザーボードは、Z390チップセット搭載マザーボードのASUS ROG MAXIMUS XI HERO です。macOSのメニューバーから「システム終了…」を選んでシャットダウンしようとすると、そのままの画面で止まってしまいます。Cloverを-vオプションで立ち上げた状態でシャットダウンしようとすると、画面が暗くなった後に、右上に以下のようなメッセージが出ます。

vm_map_delete: map <ptr> [0x1003c1000...0x1003c2000] nothing at 0x1003c1000
Man Jan 21 21:29:26 2019 hoge.local com.apple.xpc.launchd[1] <Notice> Generating report ...
Man Jan 21 21:29:26 2019 hoge.local com.apple.xpc.launchd[1] <Notice> 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) <Notice> 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) <Notice> Will be calling reboot(2) with flags: 0x0

スリープの時も同様です。-vオプションなしでは、画面が止まってしまい、-vオプションで起動していると、黒くなった画面右上に同じメッセージが出て反応がなくなります。

後からわかったのですが、このメッセージは異常を示すものではなく、ここで処理が停滞して止まっているだけのようです。実はこのマシンを組み上げた直後は、スリープもシャットダウンも正常に動いていた気がしていました。これも後からわかったのですが、気のせいではなかったようです。

シャットダウン問題解決

色々な方法を試したのですが、結局は最初に書いた通り、Clover の drivers64UEFI フォルダに、 EmuVariableUefi-64.efi を入れることですんなり解決しました。 EmuVariableUefi-64.efi は、macOSからATXマザーボード上のNVRAMがうまく読めない場合に、NVRAMのふり（エミュレーション）をしてくれるefiドライバーです。

NVRAMのエミュレーション

マザーボード上のNVRAMがmacOSから利用できていればEmuVariableUefi-64.efiは不要なのですが、ASUSのこのマザーボードの場合は必要だったようです。NVRAMが機能しない場合は、

NVIDIAのWeb driverが動かない（Web driverを使用するかどうかをNVRAMに書き込んでいる）
音量などの値が保存されない

などの症状が出ることは知っていましたが、スリープ、シャットダウンで固まってしまう現象が起こりうるとは知りませんでした。多分、シャットダウン時にNVRAMに情報を書き込もうとして、それができなくて処理が止まっていたと考えられます。

実のところ、最初にこのマシンを組んだ時には、EmuVariableUefi-64.efi を入れていてうまく動いていました。その後、試しに外しても動くようなので、マザーボードのNVRAMにアクセスできていると思い込んで、外していました。EmuVariableUefi-64.efi を外してから、シャットダウンに影響が出るまで時間がかかるので、因果関係に気づきにくいです。

Sleep問題

追記：この問題は10.14.4で発生しなくなりました。

ということで、一時は解決したかに思ったのですが、スリープの問題が発生していました。スリープに入って15秒くらいまではキーボード操作などで画面復帰するのですが、それ以降では画面が暗くなったままです。RX 580で発生しているようです。解決策見つかったら報告します。

~~(追記) こちらの方法で解決しました。~~

9900Kのsleep問題〜原因はiGPUのデバイスID

Sleep/shutdown対策のまとめ

スリープ、シャットダウンできない不具合はHackintoshでよくあるトラブルです。ただ、様々なことが原因で発生するので、対策も多岐に渡ります。一般的な解決策、ASUSの類似マザーボード案件を探して見つかった解決策、今回の解決策を列挙しておきます。

config.plistでFixShutdownをtrueにする。一番一般的な解決策です。だいたいこれで解決します。
config.plistでFixShutdown_0004をtrueにする。Cloverのマニュアルにも書かれているASUSマザーボード対策です。古くからの方法なので今は効かないかもしれません。今回も関係ありませんでした。
Cloverの起動オプションで、darkwake=0またはdarkwake=1とする。ASUSマザボの問題が解決したという報告がありましたが、今回は無効でした。
macOSのシステム環境設定でPower Napを無効にする。今回は関係ありませんでした。
BIOS設定で、Advanced / APM Configuration / Power On By PCI-E/PCIをEnabledにする（出荷時設定はDisable)。ASUSマザボの問題が解決したという報告がありましたが、今回は無効でした。
EmuVariableUefi-64.efiもしくはEmuVariableUefi.efiを入れる（今回のシャットダウン解決策）。
CloverブートメニューでF11を押してnvramをリセットする。
/Library/Preferences/com.apple.PowerManagement.*ファイルを消す。これを消してもmacOSが自動作成してくれます。
```
sudo rm /Library/Preferences/com.apple.PowerManagement.*
```
スリープからの復帰で画面が暗いままな状況はグラフィックスの問題でした。iGPUのデバイスIDを指定したら治りました。
いただいたコメントによると、ディスプレイを接続しているカードのコネクタを変えると治ることもあるようです。HDMIではダメだったけどDPにしたらスリープ解決したそうです。

corpnewtさんのバニラガイド~Haswell用config.plist

Sun, 13 Jan 2019 12:34:22 +0900

Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Haswellマシンのためのconfig.plistの作り方」のページをご紹介します。

Page not found

ちなみにこのガイドでは、

のconfig.plistの作り方が解説してあります。他のCPUを使う場合はそれを見てください。また、Config.plistの基礎編もご覧ください。
世代の近いCPUではそれぞれかなりの部分が共通です。Haswellは実際のiMacで採用されていて、歴代CPUの中でも互換性が高いと評判です。なので特殊な設定はありません。

（ここから抄訳）

（訳注：元記事ではClover Configuratorのスクリーンショットも多数掲載されていますが、config.plistだけを紹介します。Configuratorの操作は元記事を見てください。）

ACPI

CloverのACPIデフォルト設定は、多すぎで、やりすぎなところがあります。そのために問題を引き起こす可能性があります。そこで、できるだけ単純に書き直します。

 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>FixHPET</key>
 <true/>
 <key>FixIPIC</key>
 <true/>
 <key>FixRTC</key>
 <true/>
 <key>FixShutdown</key>
 <true/>
 <key>FixTMR</key>
 <true/>
 </dict>
 <key>Patches</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>change EHC1 to EH01</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 RUhDMQ==
 </data>
 <key>Replace</key>
 <data>
 RUgwMQ==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change EHC2 to EH02</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 RUhDMg==
 </data>
 <key>Replace</key>
 <data>
 RUgwMg==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change SAT0 to SATA</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 U0FUMA==
 </data>
 <key>Replace</key>
 <data>
 U0FUQQ==
 </data>
 </dict>
 </array>
 </dict>
 <key>DropTables</key>
 <array>
 <dict>
 <key>Signature</key>
 <string>DMAR</string>
 </dict>
 <dict>
 <key>Signature</key>
 <string>MATS</string>
 </dict>
 </array>
 <key>FixHeaders</key>
 <true/>
 <key>SSDT</key>
 <dict>
 <key>Generate</key>
 <dict>
 <key>PluginType</key>
 <true/>
 </dict>
 </dict>
 </dict>

Fixes:

Fixesでは以下を指定しました。

FixShutdown – いくつかのマザーボードでシャットダウンしようとしても再起動してしまう問題を解決します。これをtrueにすると、今度は逆にシャットダウンの問題を引き起こすこともあります。その場合はdisableにします。
このほか、IRQの衝突を解消するなどの指定がしてあります。これらは全てのハードウェアに必要ではないかもしれませんが、適用しても大きな害はありません。

Patches:

Patchesセクションでは、DSDTのパーツをCloverにより動的に改名します。本物のMacを使っているわけではないうえ、macOSは特定のDSDTパーツ名を前提にしていません。そこでmacOSが稼働するように、名前を非破壊的に変更します。ここでは以下の改名をしています。

EHC1 を 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個を追加しています。

DMAR – これはVt-dに関する問題を防止します。Vt-dは仮想マシンのためのPCIパススルーで、Hackintoshではほぼ全く機能しません。
MATS – High Sierra以降で、このテーブルが読み込まれると印刷不可能なキャラクタによりカーネルパニックする可能性があります。

FixHeadersとSSDT:

ここでは以下の指定をします。

FixHeaders – MATSテーブルをドロップすることに加えて念の為に設定します。これをtrueにするとCloverは印刷不可能なキャラクタによるカーネルパニックを防止します。
PluginType – X86PlatformPlugin をロードするためにいくつかのDSDTデータをインジェクトします。これにより、ネイティブなCPU電力制御を実現する手助けになります。この設定はHaswell以降のCPUでのみ機能します。

Boot

ここではあまり重要な項目はありません。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>keepsyms=1 dart=0 debug=0x100 shikigva=40 -v</string>
 <key>DefaultVolume</key>
 <string>LastBootedVolume</string>
 <key>Timeout</key>
 <integer>5</integer>
 </dict>

Arguments:

いくつかの起動オプションを追加しました。

-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

特に設定することはありません。

Cpu

ここも特に設定することはありません。

Devices

WhateverGreenのための設定と音声の基本的な設定をします。

 <key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>Inject</key>
 <integer>1</integer>
 <key>ResetHDA</key>
 <true/>
 </dict>
 <key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 AwAiDQ==
 </data>
 </dict>
 </dict>
 <key>USB</key>
 <dict>
 <key>FixOwnership</key>
 <true/>
 </dict>
 </dict>

Fake ID（上のconfig.plistからは削除済み）:

このセクションは空白で良いです。昔は、HD4400のようなほぼサポートされているiGPUをサポートされたiGPUに見せかけるためにこの機能を使っていました。でも、今は、そのような目的には、よりクリーンなPropertiesセクションを使います。

Audio:

ここではaudioにinject Layout 1を指定します。これは皆さんが使っているマザーボードのコーデックで動く値ではないかもしれません。その場合は、AppleALCのSupported Codec Pageで番号を調べてください。

ここではさらにResetHDAを有効にしています。これはmacOSを再起動した後に、コーデックをニュートラルに戻してくれます。別のOSを起動してmacOSに戻ってきたときに発生する問題を解決します。

USB:

このセクションでは、FixOwnershipを指定します。これで、-vオプションで表示されるEnabling Legacy Matchingメッセージの真ん中あたりで止まってしまう問題を解決します。この問題は、HCI Hand OffをBIOSでセットしても解決します。

Properties:

このセクションの設定にはHeadkazeさんの Intel Framebuffer Patching Guideを参考にしました。そして、 ig-platform-idというプロパティを一つだけ記述しました。ここでは16進数の値の順番を入れ替えています。つまりig-plat が 0xAABBCCDDの場合、この記述でこれを0xDDCCBBAAにします。

ここで使う二つのig-platform-idは以下です。実態に合わせていずれかを使用します。

0x0D220003 – これはiGPUがディスプレイを使用する場合に使われます。
- 16進数を入れ替えると0300220Dになります。
- 入れ替えたバージョンをBase 64で表すとAwAiDQ== になります。
0x04120004 – これはiGPUが計算タスクにだけ使用される場合（表示には使われない場合）に使われます。
- 16進数を入れ替えると04001204 になります。
- 入れ替えたバージョンをBase 64で表すとBAASBA== になります。

このほか、2つのプロパティを追加しました。framebuffer-patch-enable と framebuffer-stolenmemです。前者はWhateverGreen.kext経由でのパッチ当てを有効にし、後者は最小流用メモリを19MBにします。

(訳注：framebuffer-patch-enable と framebuffer-stolenmemは、本サイトのconfig.plistにも書かれていないので、古い情報が残っている可能性があります。特に指定しなくても良いようです。一方、ig-platform-idは有用です。これを指定したら画面の乱れがなくなりました。)

HD 4400への対応

HD 4400をiGPUに搭載しているHaswellでは、以下のdevice-idの差し替えが必要です。HD 4400はmacOSではサポートされていないからです。

このdevice-idの差し替えには、上のig-platform-idの16進数入れ替えに類似した手順で行います。でも今回は最初の4桁だけの違いです。device-idは8桁の16進数なのですが、最初の4桁がデバイスIDで後半の4桁が製造社IDです。後半はどちらもインテル社なので同じだからです。そこで、デバイスIDが0xAABB0000であるものを 0xBBAA0000のように入れ替えれば良いのです。後半の4桁は変更する必要がありません。

(訳注：最後の4桁の8086の部分は製造社IDで、インテルを示します。歴史的に有名な16bit CPUの8086を表しています。その前の4桁がデバイスIDです。1番違いの異なるデバイスであることを示しています。)

device-idを偽装するための値は次のようになります。この値をdevice-idの項目に書いておけば、HD 4600が使えるようになります。

0x04120000 – これはmacOSでサポートされていないHD 4400デバイスIDです。
- 12040000 最初の2桁を入れ替えます。
- EgQAAA== そのbase 64です。

以上を基にしたPropertiesの設定です。先に説明したように、 ig-platform-id は個別の用法に合わせてください。

 <key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>device-id</key>
 <data>
 EgQAAA==
 </data>
 <key>AAPL,ig-platform-id</key>
 <data>
 AwAiDQ==
 </data>
 </dict>
 </dict>

Disable Drivers

ここでは特に設定することはありません。

Gui

 <key>GUI</key>
 <dict>
 <key>Scan</key>
 <dict>
 <key>Entries</key>
 <true/>
 <key>Tool</key>
 <true/>
 </dict>
 </dict>

Scan:

Scan settingsを変更します。この設定でブート出来ないエントリーを除外します。

Hide Volumes:

起動時に表示したくないボリュームを書いておきます。今回は何も指定しませんでした。以下が現れて困るようでしたら追加しておきます。

Preboot
VM

名前以外にUUIDもつかえます。これを知るには、以下のようにします。diskXsYのXとYは実際のボリューム番号にします。

diskutil info diskXsY | grep -i "Partition UUID" | rev | cut -d' ' -f 1 | rev

Theme:

新しいテーマをテストしたかったら (lover-next-blackがおすすめ)、 /Volumes/EFI/EFI/CLOVER/themes ディレクトリに置いて、Themeフィールドに名前を書いておけば良いです。

Graphics

昔は、iGPUをここで設定していましたが、DeviceセクションのPropertiesですでに設定しましたので、ここでは何もする必要はありません。Cloverが、インテルのiGPUを検出すると、config.plistにGraphicsセクションが無くても、自動的にIntel Injectionを有効にします。もしインテルiGPUを無効にしたい場合は、下のように明示的に書くことで無効にできます。

 <key>Graphics</key>
 <dict>
 <key>Inject</key>
 <false/>
 </dict>

Kernel And Kext Patches

 <key>KernelAndKextPatches</key>
 <dict>
 <key>KernelPm</key>
 <true/>
 <key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Port limit increase</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g710////EA==
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.12.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g710////Gw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (RehabMan)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g32IDw+DpwQAAA==
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.13.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g32ID5CQkJCQkA==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (PMHeart)</string>
 <key>Disabled</key>
 <true/>
 <key>Find</key>
 <data>
 g/sPD4MDBQAA
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.14.0</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g/sPkJCQkJCQ
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (Ricky)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g/sPD4OPBAAA
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.14.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g/sPkJCQkJCQ
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>External Icons Patch</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 RXh0ZXJuYWw=
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>
 SW50ZXJuYWw=
 </data>
 </dict>
 </array>
 </dict>

このセクションでは、いくつかの設定とkextパッチを行なっています。Clover Configuratorを使う場合は、以下の項目にチェックを入れます。

Apple RTC – これにより再起動でBIOSがリセットされてしまう現象を防止します。
KernelPM – これにより、MSR 0xe2に書き込みをしてしまうことを防ぎ、ブート時のカーネルパニックを防止します。

KextsToPatch:

ここでは4個の異なるkextパッチを設定しています。そのうち3個はUSBポート数制限に関するものです。1個はオレンジアイコン問題への対処です。これは内部ドライブがホットプラグ可能と判断されてオレンジ色のアイコンの外部ドライブとして現れてしまう問題です。

USBポート数制限のパッチにはMatchOS値が設定されています。実際に使用するOSバージョンのものだけを残しておいて、それ以外は削除して良いです。

RtVariables と SMBIOS

 <key>RtVariables</key>
 <dict>
 <key>BooterConfig</key>
 <string>0x28</string>
 <key>CsrActiveConfig</key>
 <string>0x3E7</string>
 <key>MLB</key>
 <string>C02532300QXG2Y7AD</string>
 <key>ROM</key>
 <string>UseMacAddr0</string>
 </dict>
 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>C02532300QXG2Y7AD</string>
 <key>ProductName</key>
 <string>iMac15,1</string>
 <key>SerialNumber</key>
 <string>C02Q6FYUFY10</string>
 <key>SmUUID</key>
 <string>C495EE18-C8EA-4100-8CAD-3099AC27772F</string>
 </dict>

SMBIOS情報の設定に関して私は、acidantheraの macserial アプリケーションを使っています。私は、同様なpythonスクリプトを書きました。これはconfig.plistに自動保存します。多くの項目は空白であってもCloverが自動的に埋めてくれます。これは、書き込むべき値にアップデートが必要になった時に自動的に書き換えてくれるということを意味します。

このHaswellの例では、互換性のためにiMac15,1 のSMBIOSを使いました。細かい機種割り当ては、次のようにすれば良いです。

iGPUを使うHaswellマシンならiMac14,1を使う
dGPUを使うHaswellマシンならiMac14,2を使う
Haswell RefreshマシンならiMac15,1を使う

macserialアプリケーションでSMBIOS情報を取得するために、これを-aオプションで起動します。これによりシリアル番号とボードシリアル番号を生成します。またgrepコマンドで検索するSMBIOSタイプを制約できます。 iMac15,1の例では、次のようにmacserialアプリケーションを起動します。

macserial -a | grep -i iMac15,1

これにより以下の結果を得られます。

  iMac15,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

順番は、以下です。

Product | Serial | Board Serial (MLB)

iMac15,1の部分はSMBIOS -> Product Nameにコピーします。
Serialの部分はSMBIOS -> Serial Numberにコピーします。
Boardの部分はSMBIOS -> Board Serial Number と Rt Variables -> MLBにコピーします。

SmUUIDの値はターミナルのuuidgenコマンドで得られます。もしくは私のPlist-Toolスクリプトで自動生成できます。この結果を、SMBIOS -> SmUUIDにコピーします。

Rt Variables -> ROM を UseMacAddr0 に設定しました。これを設定するとオンボードのMACアドレスを流用してくれます。

BooterConfigは0x28に、CsrActiveConfigは0x3e7に設定しました。これで効果的にSIPを無効にしてくれます。このほか、よく使われる値は以下です。

0x0 – SIPを完全に有効にする
0x3 – 署名のないkextsの使用と保護されたディレクトリへの書き込みを許可する
0x3e7 – SIPを完全に無効にする

System Parameters

 <key>SystemParameters</key>
 <dict>
 <key>InjectKexts</key>
 <string>Yes</string>
 <key>InjectSystemID</key>
 <true/>
 </dict>

Inject Kexts:

この設定には3種類が可能です。ここではYesを使用しました。

Yes – CloverがEFIのkextを使用するよう指定する。
No – CloverがEFIのkextを使用しないよう指定する。
Detect – FakeSMC.kextがkextキャッシュに存在していない時だけkextを使用するよう、Cloverに指定する。

InjectSystemID:

この設定は、ブート時に、SmUUIDをsystem-idに設定するようCloverに指示します。これはiMessageなどに重要です。

まとめ

以上のconfig.plistを全部まとめたものをこちらで公開しておきます。

corpnewtさんのバニラガイド~Skylake用config.plist

Sun, 13 Jan 2019 11:58:32 +0900

Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Skylakeマシンのためのconfig.plistの作り方」のページをご紹介します。

Page not found

ちなみにこのガイドでは、

のconfig.plistの作り方が解説してあります。他のCPUを使う場合はそれを見てください。また、Config.plistの基礎編もご覧ください。
世代の近いCPUではそれぞれかなりの部分が共通です。Skylakeは実際のiMacで採用されているので、互換性が高く特殊な設定はありません。

（ここから抄訳）

ACPI

 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>FixHPET</key>
 <true/>
 <key>FixIPIC</key>
 <true/>
 <key>FixRTC</key>
 <true/>
 <key>FixShutdown</key>
 <true/>
 <key>FixTMR</key>
 <true/>
 </dict>
 <key>Patches</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>change XHCI to XHC</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 WEhDSQ==
 </data>
 <key>Replace</key>
 <data>
 WEhDXw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change XHC1 to XHC</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 WEhDMQ==
 </data>
 <key>Replace</key>
 <data>
 WEhDXw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change SAT0 to SATA</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 U0FUMA==
 </data>
 <key>Replace</key>
 <data>
 U0FUQQ==
 </data>
 </dict>
 </array>
 </dict>
 <key>DropTables</key>
 <array>
 <dict>
 <key>Signature</key>
 <string>DMAR</string>
 </dict>
 <dict>
 <key>Signature</key>
 <string>MATS</string>
 </dict>
 </array>
 <key>FixHeaders</key>
 <true/>
 <key>SSDT</key>
 <dict>
 <key>Generate</key>
 <dict>
 <key>PluginType</key>
 <true/>
 </dict>
 </dict>
 </dict>

Fixes:

Fixesでは以下を指定しました。

FixShutdown – いくつかのマザーボードでシャットダウンしようとしても再起動してしまう問題を解決します。これをtrueにすると、今度は逆にシャットダウンの問題を引き起こすこともあります。その場合はdisableにします。
このほか、IRQの衝突を解消するなどの指定がしてあります。これらは全てのハードウェアに必要ではないかもしれませんが、適用しても大きな害はありません。

Patches:

XHCI を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます
XHC1 を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます
SAT0 を SATAに変更 – 潜在的なSATA 互換性を改善します

Drop Tables:

DMAR – これはVt-dに関する問題を防止します。Vt-dは仮想マシンのためのPCIパススルーで、Hackintoshではほぼ全く機能しません。
MATS – High Sierra以降で、このテーブルが読み込まれると印刷不可能なキャラクタによりカーネルパニックする可能性があります。

FixHeadersとSSDT:

ここでは以下の指定をします。

FixHeaders – MATSテーブルをドロップすることに加えて念の為に設定します。これをtrueにするとCloverは印刷不可能なキャラクタによるカーネルパニックを防止します。
PluginType – X86PlatformPlugin をロードするためにいくつかのDSDTデータをインジェクトします。これにより、ネイティブなCPU電力制御を実現する手助けになります。この設定はHaswell以降のCPUでのみ機能します。

Boot

ここではあまり重要な項目はありません。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>keepsyms=1 dart=0 debug=0x100 shikigva=40 -v</string>
 <key>DefaultVolume</key>
 <string>LastBootedVolume</string>
 <key>Timeout</key>
 <integer>5</integer>
 </dict>

Arguments:

いくつかの起動オプションを追加しました。

-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

特に設定することはありません。

Cpu

ここも特に設定することはありません。

Devices

WhateverGreenのための設定と音声の基本的な設定をします。

 <key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>Inject</key>
 <integer>1</integer>
 <key>ResetHDA</key>
 <true/>
 </dict>
 <key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 AAASGQ==
 </data>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 <key>framebuffer-stolenmem</key>
 <data>
 AAAwAQ==
 </data>
 </dict>
 </dict>
 <key>USB</key>
 <dict>
 <key>FixOwnership</key>
 <true/>
 </dict>
 </dict>

Fake ID（上のconfig.plistからは削除済み）:

Audio:

USB:

Properties:

ここで使う二つのig-platform-idは以下です。実態に合わせていずれかを使用します。

0x19120000 – これはiGPUがディスプレイを使用する場合に使われます。
- 16進数を入れ替えると00001219になります。
- 入れ替えたバージョンをBase 64で表すとAAASGQ== になります。
0x19120001 – これはiGPUが計算タスクにだけ使用される場合（表示には使われない場合）に使われます。
- 16進数を入れ替えると01001219 になります。
- 入れ替えたバージョンをBase 64で表すとAQASGQ== になります。

Disable Drivers

ここでは特に設定することはありません。

Gui

 <key>GUI</key>
 <dict>
 <key>Scan</key>
 <dict>
 <key>Entries</key>
 <true/>
 <key>Tool</key>
 <true/>
 </dict>
 </dict>

Scan:

Scan settingsを変更します。この設定でブート出来ないエントリーを除外します。

Hide Volumes:

起動時に表示したくないボリュームを書いておきます。今回は何も指定しませんでした。以下が現れて困るようでしたら追加しておきます。

Preboot
VM

名前以外にUUIDもつかえます。これを知るには、以下のようにします。diskXsYのXとYは実際のボリューム番号にします。

diskutil info diskXsY | grep -i "Partition UUID" | rev | cut -d' ' -f 1 | rev

Theme:

Graphics

 <key>Graphics</key>
 <dict>
 <key>Inject</key>
 <false/>
 </dict>

Kernel And Kext Patches

 <key>KernelAndKextPatches</key>
 <dict>
 <key>KernelPm</key>
 <true/>
 <key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Port limit increase</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g710////EA==
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.12.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g710////Gw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (RehabMan)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g32IDw+DpwQAAA==
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.13.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g32ID5CQkJCQkA==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (PMHeart)</string>
 <key>Disabled</key>
 <true/>
 <key>Find</key>
 <data>
 g/sPD4MDBQAA
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.14.0</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g/sPkJCQkJCQ
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (Ricky)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g/sPD4OPBAAA
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.14.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g/sPkJCQkJCQ
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>External Icons Patch</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 RXh0ZXJuYWw=
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>
 SW50ZXJuYWw=
 </data>
 </dict>
 </array>
 </dict>

このセクションでは、いくつかの設定とkextパッチを行なっています。Clover Configuratorを使う場合は、以下の項目にチェックを入れます。

Apple RTC – これにより再起動でBIOSがリセットされてしまう現象を防止します。
KernelPM – これにより、MSR 0xe2に書き込みをしてしまうことを防ぎ、ブート時のカーネルパニックを防止します。

KextsToPatch:

USBポート数制限のパッチにはMatchOS値が設定されています。実際に使用するOSバージョンのものだけを残しておいて、それ以外は削除して良いです。

RtVariables と SMBIOS

 <key>RtVariables</key>
 <dict>
 <key>BooterConfig</key>
 <string>0x28</string>
 <key>CsrActiveConfig</key>
 <string>0x3E7</string>
 <key>MLB</key>
 <string>C02634902QXGPF7FB</string>
 <key>ROM</key>
 <string>UseMacAddr0</string>
 </dict>
 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>C02634902QXGPF7FB</string>
 <key>ProductName</key>
 <string>iMac17,1</string>
 <key>SerialNumber</key>
 <string>C02S8DY7GG7L</string>
 <key>SmUUID</key>
 <string>DD574F3E-5774-414A-8FF9-5B0089B09480</string>
 </dict>

このCoffee Lakeの例では、互換性のためにiMac17,1 のSMBIOSを使いました。

macserialアプリケーションでSMBIOS情報を取得するために、これを-aオプションで起動します。これによりシリアル番号とボードシリアル番号を生成します。またgrepコマンドで検索するSMBIOSタイプを制約できます。 iMac17,1の例では、次のようにmacserialアプリケーションを起動します。

macserial -a | grep -i iMac17,1

これにより以下の結果を得られます。

  iMac17,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

順番は、以下です。

Product | Serial | Board Serial (MLB)

iMac17,1の部分はSMBIOS -> Product Nameにコピーします。
Serialの部分はSMBIOS -> Serial Numberにコピーします。
Boardの部分はSMBIOS -> Board Serial Number と Rt Variables -> MLBにコピーします。

Rt Variables -> ROM を UseMacAddr0 に設定しました。これを設定するとオンボードのMACアドレスを流用してくれます。

BooterConfigは0x28に、CsrActiveConfigは0x3e7に設定しました。これで効果的にSIPを無効にしてくれます。このほか、よく使われる値は以下です。

0x0 – SIPを完全に有効にする
0x3 – 署名のないkextsの使用と保護されたディレクトリへの書き込みを許可する
0x3e7 – SIPを完全に無効にする

System Parameters

 <key>SystemParameters</key>
 <dict>
 <key>InjectKexts</key>
 <string>Yes</string>
 <key>InjectSystemID</key>
 <true/>
 </dict>

Inject Kexts:

この設定には3種類が可能です。ここではYesを使用しました。

Yes – CloverがEFIのkextを使用するよう指定する。
No – CloverがEFIのkextを使用しないよう指定する。
Detect – FakeSMC.kextがkextキャッシュに存在していない時だけkextを使用するよう、Cloverに指定する。

InjectSystemID:

この設定は、ブート時に、SmUUIDをsystem-idに設定するようCloverに指示します。これはiMessageなどに重要です。

まとめ

以上のconfig.plistを全部まとめたものをこちらで公開しておきます。

corpnewtさんのバニラガイド~Kaby Lake用config.plist

Sun, 13 Jan 2019 11:31:42 +0900

Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Kaby Lakeマシンのためのconfig.plistの作り方」のページをご紹介します。

Page not found

ちなみにこのガイドでは、

のconfig.plistの作り方が解説してあります。他のCPUを使う場合はそれを見てください。また、Config.plistの基礎編もご覧ください。
世代の近いCPUではそれぞれかなりの部分が共通です。Kaby Lakeは実際のMacのモバイルモデルで採用されているので、互換性が高く特殊な設定はありません。

（ここから抄訳）

ACPI

 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>FixHPET</key>
 <true/>
 <key>FixIPIC</key>
 <true/>
 <key>FixRTC</key>
 <true/>
 <key>FixShutdown</key>
 <true/>
 <key>FixTMR</key>
 <true/>
 </dict>
 <key>Patches</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>change XHCI to XHC</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 WEhDSQ==
 </data>
 <key>Replace</key>
 <data>
 WEhDXw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change XHC1 to XHC</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 WEhDMQ==
 </data>
 <key>Replace</key>
 <data>
 WEhDXw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change SAT0 to SATA</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 U0FUMA==
 </data>
 <key>Replace</key>
 <data>
 U0FUQQ==
 </data>
 </dict>
 </array>
 </dict>
 <key>DropTables</key>
 <array>
 <dict>
 <key>Signature</key>
 <string>DMAR</string>
 </dict>
 <dict>
 <key>Signature</key>
 <string>MATS</string>
 </dict>
 </array>
 <key>FixHeaders</key>
 <true/>
 <key>SSDT</key>
 <dict>
 <key>Generate</key>
 <dict>
 <key>PluginType</key>
 <true/>
 </dict>
 </dict>
 </dict>

Fixes:

Fixesでは以下を指定しました。

FixShutdown – いくつかのマザーボードでシャットダウンしようとしても再起動してしまう問題を解決します。これをtrueにすると、今度は逆にシャットダウンの問題を引き起こすこともあります。その場合はdisableにします。
このほか、IRQの衝突を解消するなどの指定がしてあります。これらは全てのハードウェアに必要ではないかもしれませんが、適用しても大きな害はありません。

Patches:

XHCI を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます
XHC1 を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます
SAT0 を SATAに変更 – 潜在的なSATA 互換性を改善します

Drop Tables:

DMAR – これはVt-dに関する問題を防止します。Vt-dは仮想マシンのためのPCIパススルーで、Hackintoshではほぼ全く機能しません。
MATS – High Sierra以降で、このテーブルが読み込まれると印刷不可能なキャラクタによりカーネルパニックする可能性があります。

FixHeadersとSSDT:

ここでは以下の指定をします。

FixHeaders – MATSテーブルをドロップすることに加えて念の為に設定します。これをtrueにするとCloverは印刷不可能なキャラクタによるカーネルパニックを防止します。
PluginType – X86PlatformPlugin をロードするためにいくつかのDSDTデータをインジェクトします。これにより、ネイティブなCPU電力制御を実現する手助けになります。この設定はHaswell以降のCPUでのみ機能します。

Boot

ここではあまり重要な項目はありません。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>keepsyms=1 dart=0 debug=0x100 shikigva=40 -v</string>
 <key>DefaultVolume</key>
 <string>LastBootedVolume</string>
 <key>Timeout</key>
 <integer>5</integer>
 </dict>

Arguments:

いくつかの起動オプションを追加しました。

-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

特に設定することはありません。

Cpu

ここも特に設定することはありません。

Devices

WhateverGreenのための設定と音声の基本的な設定をします。

 <key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>Inject</key>
 <integer>1</integer>
 <key>ResetHDA</key>
 <true/>
 </dict>
 <key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 AAASWQ==
 </data>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 <key>framebuffer-stolenmem</key>
 <data>
 AAAwAQ==
 </data>
 </dict>
 </dict>
 <key>USB</key>
 <dict>
 <key>FixOwnership</key>
 <true/>
 </dict>
 </dict>

Fake ID（上のconfig.plistからは削除済み）:

Audio:

USB:

Properties:

ここで使う二つのig-platform-idは以下です。

0x59120000 – これはiGPUがディスプレイを使用する場合に使われます。
- 16進数を入れ替えると00001259になります。
- 入れ替えたバージョンをBase 64で表すとAAASWQ== になります。
0x59120003 – これはiGPUが計算タスクにだけ使用される場合（表示には使われない場合）に使われます。
- 16進数を入れ替えると03001259 になります。
- 入れ替えたバージョンをBase 64で表すとAwASWQ== になります。

Disable Drivers

ここでは特に設定することはありません。

Gui

 <key>GUI</key>
 <dict>
 <key>Scan</key>
 <dict>
 <key>Entries</key>
 <true/>
 <key>Tool</key>
 <true/>
 </dict>
 </dict>

Scan:

Scan settingsを変更します。この設定でブート出来ないエントリーを除外します。

Hide Volumes:

起動時に表示したくないボリュームを書いておきます。今回は何も指定しませんでした。以下が現れて困るようでしたら追加しておきます。

Preboot
VM

名前以外にUUIDもつかえます。これを知るには、以下のようにします。diskXsYのXとYは実際のボリューム番号にします。

diskutil info diskXsY | grep -i "Partition UUID" | rev | cut -d' ' -f 1 | rev

Theme:

Graphics

 <key>Graphics</key>
 <dict>
 <key>Inject</key>
 <false/>
 </dict>

Kernel And Kext Patches

 <key>KernelAndKextPatches</key>
 <dict>
 <key>KernelPm</key>
 <true/>
 <key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Port limit increase</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g710////EA==
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.12.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g710////Gw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (RehabMan)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g32IDw+DpwQAAA==
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.13.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g32ID5CQkJCQkA==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (PMHeart)</string>
 <key>Disabled</key>
 <true/>
 <key>Find</key>
 <data>
 g/sPD4MDBQAA
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.14.0</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g/sPkJCQkJCQ
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (Ricky)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g/sPD4OPBAAA
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.14.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g/sPkJCQkJCQ
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>External Icons Patch</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 RXh0ZXJuYWw=
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>
 SW50ZXJuYWw=
 </data>
 </dict>
 </array>
 </dict>

このセクションでは、いくつかの設定とkextパッチを行なっています。Clover Configuratorを使う場合は、以下の項目にチェックを入れます。

Apple RTC – これにより再起動でBIOSがリセットされてしまう現象を防止します。
KernelPM – これにより、MSR 0xe2に書き込みをしてしまうことを防ぎ、ブート時のカーネルパニックを防止します。

KextsToPatch:

USBポート数制限のパッチにはMatchOS値が設定されています。実際に使用するOSバージョンのものだけを残しておいて、それ以外は削除して良いです。

RtVariables と SMBIOS

 <key>RtVariables</key>
 <dict>
 <key>BooterConfig</key>
 <string>0x28</string>
 <key>CsrActiveConfig</key>
 <string>0x3E7</string>
 <key>MLB</key>
 <string>C02726902CDH69F1M</string>
 <key>ROM</key>
 <string>UseMacAddr0</string>
 </dict>
 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>C02726902CDH69F1M</string>
 <key>ProductName</key>
 <string>iMac18,1</string>
 <key>SerialNumber</key>
 <string>C02TX0VDH7JY</string>
 <key>SmUUID</key>
 <string>91492A73-595C-4D97-A6FC-2B5D3ED1B54D</string>
 </dict>

このCoffee Lakeの例では、互換性のためにiMac18,1 のSMBIOSを使いました。Kaby Lakeと互換性の高いSMBIOSは以下の2種類です。

iMac18,1 – これはiGPUを表示に使用するコンピュータで使われます。
iMac18,3 – これはdGPUを表示に使用し、iGPUは計算のみに使用するコンピュータで使われます

macserialアプリケーションでSMBIOS情報を取得するために、これを-aオプションで起動します。これによりシリアル番号とボードシリアル番号を生成します。またgrepコマンドで検索するSMBIOSタイプを制約できます。 iMac18,1の例では、次のようにmacserialアプリケーションを起動します。

macserial -a | grep -i iMac18,1

これにより以下の結果を得られます。

iMac18,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

順番は、以下です。

Product | Serial | Board Serial (MLB)

iMac18,1の部分はSMBIOS -> Product Nameにコピーします。
Serialの部分はSMBIOS -> Serial Numberにコピーします。
Boardの部分はSMBIOS -> Board Serial Number と Rt Variables -> MLBにコピーします。

Rt Variables -> ROM を UseMacAddr0 に設定しました。これを設定するとオンボードのMACアドレスを流用してくれます。

BooterConfigは0x28に、CsrActiveConfigは0x3e7に設定しました。これで効果的にSIPを無効にしてくれます。このほか、よく使われる値は以下です。

0x0 – SIPを完全に有効にする
0x3 – 署名のないkextsの使用と保護されたディレクトリへの書き込みを許可する
0x3e7 – SIPを完全に無効にする

System Parameters

 <key>SystemParameters</key>
 <dict>
 <key>InjectKexts</key>
 <string>Yes</string>
 <key>InjectSystemID</key>
 <true/>
 </dict>

Inject Kexts:

この設定には3種類が可能です。ここではYesを使用しました。

Yes – CloverがEFIのkextを使用するよう指定する。
No – CloverがEFIのkextを使用しないよう指定する。
Detect – FakeSMC.kextがkextキャッシュに存在していない時だけkextを使用するよう、Cloverに指定する。

InjectSystemID:

この設定は、ブート時に、SmUUIDをsystem-idに設定するようCloverに指示します。これはiMessageなどに重要です。

まとめ

以上のconfig.plistを全部まとめたものをこちらで公開しておきます。

corpnewtさんのバニラガイド~Coffee Lake用config.plist

Sun, 13 Jan 2019 00:52:22 +0900

Corpnewtさんのhackintoshデスクトップのためのバニラガイドから、今回は「Coffee Lakeマシンのためのconfig.plistの作り方」のページをご紹介します。

Page not found

ちなみにこのガイドでは、

のconfig.plistの作り方が解説してあります。他のCPUを使う場合はそれを見てください。Config.plistの基礎編もご覧ください。
世代の近いCPUではそれぞれかなりの部分が共通です。Coffee Lakeは実際のMacでの搭載実績がないため、iGPUを使う部分が少し複雑になっています。iGPUを使わなければほぼKaby Lake以前と同じで良いようです。

（ここから抄訳）

ACPI

 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>AddMCHC</key>
 <true/>
 <key>FixHPET</key>
 <true/>
 <key>FixIPIC</key>
 <true/>
 <key>FixRTC</key>
 <true/>
 <key>FixShutdown</key>
 <true/>
 <key>FixTMR</key>
 <true/>
 </dict>
 <key>Patches</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>change XHCI to XHC</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 WEhDSQ==
 </data>
 <key>Replace</key>
 <data>
 WEhDXw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change XHC1 to XHC</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 WEhDMQ==
 </data>
 <key>Replace</key>
 <data>
 WEhDXw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change SAT0 to SATA</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 U0FUMA==
 </data>
 <key>Replace</key>
 <data>
 U0FUQQ==
 </data>
 </dict>
 </array>
 </dict>
 <key>DropTables</key>
 <array>
 <dict>
 <key>Signature</key>
 <string>DMAR</string>
 </dict>
 <dict>
 <key>Signature</key>
 <string>MATS</string>
 </dict>
 </array>
 <key>FixHeaders</key>
 <true/>
 <key>SSDT</key>
 <dict>
 <key>Generate</key>
 <dict>
 <key>PluginType</key>
 <true/>
 </dict>
 </dict>
 </dict>

Fixes:

Fixesでは以下を指定しました。

FixShutdown – いくつかのマザーボードでシャットダウンしようとしても再起動してしまう問題を解決します。これをtrueにすると、今度は逆にシャットダウンの問題を引き起こすこともあります。その場合はdisableにします。
このほか、IRQの衝突を解消するなどの指定がしてあります。これらは全てのハードウェアに必要ではないかもしれませんが、適用しても大きな害はありません。

Patches:

XHCI を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます
XHC1 を XHCに変更 – これによりbuilt-in USB injectorsとの衝突を避けます
SAT0 を SATAに変更 – 潜在的なSATA 互換性を改善します

Drop Tables:

DMAR – これはVt-dに関する問題を防止します。Vt-dは仮想マシンのためのPCIパススルーで、Hackintoshではほぼ全く機能しません。
MATS – High Sierra以降で、このテーブルが読み込まれると印刷不可能なキャラクタによりカーネルパニックする可能性があります。

FixHeadersとSSDT:

ここでは以下の指定をします。

FixHeaders – MATSテーブルをドロップすることに加えて念の為に設定します。これをtrueにするとCloverは印刷不可能なキャラクタによるカーネルパニックを防止します。
PluginType – X86PlatformPlugin をロードするためにいくつかのDSDTデータをインジェクトします。これにより、ネイティブなCPU電力制御を実現する手助けになります。この設定はHaswell以降のCPUでのみ機能します。

Boot

ここではあまり重要な項目はありません。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>keepsyms=1 dart=0 debug=0x100 shikigva=40 -v</string>
 <key>DefaultVolume</key>
 <string>LastBootedVolume</string>
 <key>Timeout</key>
 <integer>5</integer>
 </dict>

Arguments:

いくつかの起動オプションを追加しました。

-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

特に設定することはありません。

Cpu

ここも特に設定することはありません。

Devices

WhateverGreenのための設定と音声の基本的な設定をします。

 <key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>Inject</key>
 <integer>1</integer>
 <key>ResetHDA</key>
 <true/>
 </dict>
 <key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 BwCbPg==
 </data>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 <key>framebuffer-stolenmem</key>
 <data>
 AAAwAQ==
 </data>
 </dict>
 </dict>
 <key>USB</key>
 <dict>
 <key>FixOwnership</key>
 <true/>
 </dict>
 </dict>

Fake ID（上のconfig.plistからは削除済み）:

Audio:

USB:

Properties:

ここで使う二つのig-platform-idは以下です。

0x3E9B0007 – これは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の値) にすべきです。

i3-8100のUHD 630への対応

i3-8100にもUHD 630が搭載されていますが、8700Kなど、実際のMacに搭載されているCPUとはdevice-idが異なっています。具体的には3e918086 と 3e928086の違いです。そこで、i3-8100のUHD 630を使用するためにはIDの差し替えが必要です。

このdevice-idの差し替えには、上のig-platform-idの16進数入れ替えに類似した手順で行います。でも今回は最初の4桁だけの違いです。デバイスIDが0xAABB0000であるものを 0xBBAA0000のように入れ替えれば良いのです。後半の4桁は変更する必要がありません。

device-idを偽装するための値は次のようになります。この値をdevice-idの項目に書いておけば、8100のUHD 630が問題なく使えるようになります。

0x3e920000 – これは8700K搭載UHD 630のデバイスIDです。
- 923e0000 最初の2桁を入れ替えます。
- kj4AAA== そのbase 64です。

以上を基にしたPropertiesの設定です。先に説明したように、 ig-platform-id は個別の用法に合わせてください。

 <key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>device-id</key>
 <data>
 kj4AAA==
 </data>
 <key>AAPL,ig-platform-id</key>
 <data>
 BwCbPg==
 </data>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 <key>framebuffer-stolenmem</key>
 <data>
 AAAwAQ==
 </data>
 </dict>
 </dict>

ピンク問題

UHD 630 iGPUをHDMIで使用すると画面がピンクぽくなる問題が発生することがあります。私も経験して、いくつかの方法で解決しました。

まずは、この問題をRedditの投稿で見て、ディスプレイを強制的にRGBモードにすることで解決すると知りました。YCbCrモードだと不具合が出るようです。そのためのスクリプトを作りました。うまく動きますが、本当の解決法とは思えませんでした。以下、手元のマシンで解決した手順を示します。

IORegのConnector Types

そこで、IORegistryExplorerを開いて検索窓に IGPU (これはACPIのなかの GFX0 となっていることがありますが、Lilu + WhateverGreen が正しく変更してくれているはずです。) とタイプすると次の画面になります。

IORegの中にIGPUを見つけたら、検索窓をクリアします。これにより、IGPUセクションのすべての情報が見えるようになります。

このスクリーンショットでわかるように、いくつかの異なる AppleIntelFramebuffer connectionsが表示されています。私がディスプレイに接続している特定のフレームバッファを探してみます。私の場合、これは、AppleIntelFramebuffer@1でした。これを左のペーンで選択すると、connector-type propertyがわかります。私の場合、これはもともと <00 04 00 00> に設定されていました。このconnector typeは次の値を持つことができます。

<00 04 00 00> – これはDisplayPort
<00 08 00 00> – これはHDMI
<04 00 00 00> – これはDigital DVI
<02 00 00 00> – これはLVDS (モバイルPC用)
<01 00 00 00> – これは単なるダミーのポート

これで私の場合、HDMIポートがDisplayPortとして認識されていたことが判明しました。そこでWhateverGreenのパッチ機能を使ってconnector-typeを変更します。

間違っていたポートはAppleIntelFramebuffer@1でした。これはポート1です。そこでPropertiesでport patchを有効にします。そして、connector typeをHDMIにします。これを実現するために、次のProperties エントリーを使います。

framebuffer-conX-enable = 01000000
framebuffer-conX-type = 00080000

これをbase 64に変換して、エントリーを追加した結果は以下になります。

 <key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 BwCbPg==
 </data>
 <key>device-id</key>
 <data>
 kj4AAA==
 </data>
 <key>framebuffer-con1-enable</key>
 <data>
 AQAAAA==
 </data>
 <key>framebuffer-con1-type</key>
 <data>
 AAgAAA==
 </data>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 <key>framebuffer-stolenmem</key>
 <data>
 AAAwAQ==
 </data>
 </dict>
 </dict>

この設定により、私の環境ではHDMIオーディオも有効になりました。

Disable Drivers

ここでは特に設定することはありません。

Gui

 <key>GUI</key>
 <dict>
 <key>Scan</key>
 <dict>
 <key>Entries</key>
 <true/>
 <key>Tool</key>
 <true/>
 </dict>
 </dict>

Scan:

Scan settingsを変更します。この設定でブート出来ないエントリーを除外します。

Hide Volumes:

起動時に表示したくないボリュームを書いておきます。今回は何も指定しませんでした。以下が現れて困るようでしたら追加しておきます。

Preboot
VM

名前以外にUUIDもつかえます。これを知るには、以下のようにします。diskXsYのXとYは実際のボリューム番号にします。

diskutil info diskXsY | grep -i "Partition UUID" | rev | cut -d' ' -f 1 | rev

Theme:

新しいテーマをテストしたかったら (clover-next-blackがおすすめ)、 /Volumes/EFI/EFI/CLOVER/themes ディレクトリに置いて、Themeフィールドに名前を書いておけば良いです。

Graphics

 <key>Graphics</key>
 <dict>
 <key>Inject</key>
 <false/>
 </dict>

Kernel And Kext Patches

 <key>KernelAndKextPatches</key>
 <dict>
 <key>KernelPm</key>
 <true/>
 <key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>Port limit increase</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g710////EA==
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.12.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g710////Gw==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (RehabMan)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g32IDw+DpwQAAA==
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.13.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g32ID5CQkJCQkA==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (PMHeart)</string>
 <key>Disabled</key>
 <true/>
 <key>Find</key>
 <data>
 g/sPD4MDBQAA
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.14.0</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g/sPkJCQkJCQ
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>Port limit increase (Ricky)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 g/sPD4OPBAAA
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>MatchOS</key>
 <string>10.14.x</string>
 <key>Name</key>
 <string>com.apple.driver.usb.AppleUSBXHCI</string>
 <key>Replace</key>
 <data>
 g/sPkJCQkJCQ
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>External Icons Patch</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 RXh0ZXJuYWw=
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>
 SW50ZXJuYWw=
 </data>
 </dict>
 </array>
 </dict>

このセクションでは、いくつかの設定とkextパッチを行なっています。Clover Configuratorを使う場合は、以下の項目にチェックを入れます。

Apple RTC – これにより再起動でBIOSがリセットされてしまう現象を防止します。
KernelPM – これにより、MSR 0xe2に書き込みをしてしまうことを防ぎ、ブート時のカーネルパニックを防止します。

KextsToPatch:

USBポート数制限のパッチにはMatchOS値が設定されています。実際に使用するOSバージョンのものだけを残しておいて、それ以外は削除して良いです。

RtVariables と SMBIOS

 <key>RtVariables</key>
 <dict>
 <key>BooterConfig</key>
 <string>0x28</string>
 <key>CsrActiveConfig</key>
 <string>0x3E7</string>
 <key>MLB</key>
 <string>C02726902CDH69F1M</string>
 <key>ROM</key>
 <string>UseMacAddr0</string>
 </dict>
 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>C02726902CDH69F1M</string>
 <key>ProductName</key>
 <string>iMac18,1</string>
 <key>SerialNumber</key>
 <string>C02TX0VDH7JY</string>
 <key>SmUUID</key>
 <string>91492A73-595C-4D97-A6FC-2B5D3ED1B54D</string>
 </dict>

このCoffee Lakeの例では、互換性のためにiMac18,1 のSMBIOSを使いました。Coffee Lakeと互換性の高いSMBIOSは以下の2種類です。

iMac18,1 – これはiGPUを表示に使用するコンピュータで使われます。
iMac18,3 – これはdGPUを表示に使用し、iGPUは計算のみに使用するコンピュータで使われます

macserial -a | grep -i iMac18,1

これにより以下の結果を得られます。

iMac18,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

順番は、以下です。

Product | Serial | Board Serial (MLB)

iMac18,1の部分はSMBIOS -> Product Nameにコピーします。
Serialの部分はSMBIOS -> Serial Numberにコピーします。
Boardの部分はSMBIOS -> Board Serial Number と Rt Variables -> MLBにコピーします。

Rt Variables -> ROM を UseMacAddr0 に設定しました。これを設定するとオンボードのMACアドレスを流用してくれます。

BooterConfigは0x28に、CsrActiveConfigは0x3e7に設定しました。これで効果的にSIPを無効にしてくれます。このほか、よく使われる値は以下です。

0x0 – SIPを完全に有効にする
0x3 – 署名のないkextsの使用と保護されたディレクトリへの書き込みを許可する
0x3e7 – SIPを完全に無効にする

System Parameters

 <key>SystemParameters</key>
 <dict>
 <key>InjectKexts</key>
 <string>Yes</string>
 <key>InjectSystemID</key>
 <true/>
 </dict>

Inject Kexts:

この設定には3種類が可能です。ここではYesを使用しました。

Yes – CloverがEFIのkextを使用するよう指定する。
No – CloverがEFIのkextを使用しないよう指定する。
Detect – FakeSMC.kextがkextキャッシュに存在していない時だけkextを使用するよう、Cloverに指定する。

InjectSystemID:

この設定は、ブート時に、SmUUIDをsystem-idに設定するようCloverに指示します。これはiMessageなどに重要です。

まとめ

以上のconfig.plistを全部まとめたものをこちらで公開しておきます。

corpnewtさんのバニラガイド~config.plistの基礎

Thu, 10 Jan 2019 23:43:55 +0900

Redditのhackintosh掲示板で丁寧に質問に答えてくれているCorpnewtさんが、hackintoshのためのバニラデスクトップガイドというページを用意してくれています。バニラなインストールのためのガイドとして優れています。今回は「config.plistの基礎」というページをご紹介します。

Page not found

またCorpnewtさんのガイドには、CPUごとのconfig.plistの内容が解説されていて、とても参考になります。以下で紹介しておきました。

corpnewtさんのバニラガイド~Haswell用config.plist

corpnewtさんのバニラガイド~Skylake用config.plist

corpnewtさんのバニラガイド~Kaby Lake用config.plist

corpnewtさんのバニラガイド~Coffee Lake用config.plist

（ここから基礎編の抄訳）

config.plistは、/Volumes/EFI/EFI/CLOVER/config.plist にあります。Hackintosh初心者が苦労するファイルの一つです。

これは何か?

config.plistはXMLで書かれたpropertyリストです。 XMLはマークアップ言語でHTMLと似ています。

構造

Cloverは、config.plistに正しいパーツが正しい場所に書かれていることを前提にして参照します。configの順番やスコープはとても大事で、間違った場所に書かれた情報はCloverに伝わりません。

データタイプ

いくつかのメインのデータタイプがあります。一般的なものを紹介します。注意：ここでは開始タグしか示さない場合があります。実際には終了タグも必要です。

Strings（文字列）

<string>This is a string</string>

Stringsはそのままです。

Integers（整数値）

<integer>1</integer>

数字そのものです。

Data（base64データ）

<data>RXh0ZXJuYWw=</data>

上のstringsに似ていますが、これは何らかのデータをbase64で表現したものです。この例は、ASCII文字列のデータをbase64で表示したものです。次のターミナル操作でこの例のbase64を元のデータに戻してASCII文字として表示できます。

echo RXh0ZXJuYWw= | python -m base64 -d && echo

この結果、「External」という文字が表示されます。&&を使って文字列が表示された後に改行しています。これで見やすくなっています。

ASCII文字からbase64へはこのようにして変換できます。

echo External | base64

この結果、RXh0ZXJuYWw= が得られます。

（訳注：4の整数倍の個数になるよう=を足しているようです。またbase64 -Dコマンドでもデコードできるようです。）

Booleans（論理型）

<true/> or <false/>

これはboolean値です。

Arrays（配列）

<array>
 <string>Bob</string>
 <string>Jim</string>
 <string>Chris</string>
</array>

アイテムの unordered list です。

Dictionaries（辞書）

<dict>
 <key>Name</key>
 <string>Bob</string>
 <key>Age</key>
 <integer>20</integer>
 <key>Knows XML</key>
 <true/>
</dict>

これはdictionaryです。keyとvalueがセットです。keyは文字です。

例

True/Falseを書き換える

最初の例では、boolean valueをtrueからfalseに書き換えてみます。KextsToPatchエントリーはDisabledがfalseなので機能しています。

<dict>
 <key>Comment</key>
 <string>External icons patch</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 RXh0ZXJuYWw=
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>
 SW50ZXJuYWw=
 </data>
</dict>

たくさん記載されていますが、まずはkeyの意味を説明します。

Comment – なんのパッチなのかを示す単なるコメントです
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を書き換えません。

このパッチを無効にするには、Disabledキーをfalseからtrueにすれば良いです。

<dict>
 <key>Comment</key>
 <string>External icons patch</string>
 <key>Disabled</key>
 <true/>
 <key>Find</key>
 <data>
 RXh0ZXJuYWw=
 </data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>
 SW50ZXJuYWw=
 </data>
</dict>

簡単でしょ?

Arrayに新しいdictを追加する

以下のようなconfig.plistのconfig.plist -> ACPI -> DSDT -> Patchesに新しいパッチを追加してみます。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>FixHPET</key>
 <true/>
 <key>FixIPIC</key>
 <true/>
 <key>FixRTC</key>
 <true/>
 <key>FixTMR</key>
 <true/>
 </dict>
 <key>Patches</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>change OSID to XSID (to avoid match against _OSI XOSI patch)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 T1NJRA==
 </data>
 <key>Replace</key>
 <data>
 WFNJRA==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change _OSI to XOSI</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 X09TSQ==
 </data>
 <key>Replace</key>
 <data>
 WE9TSQ==
 </data>
 </dict>
 </array>

まずはACPIがあり、その下位にDSDTがあることがわかります。DSDTの下に、Fixesがあり、それと並んでPatchesがあります。今はFixesセクションはおいておきます。Patchesだけに注目します。

まずは、Patchesの下に、開始タグ () があり、2個のdictionariesがあります。上で説明したのに似た内容が書いてあります(Comment, Disabled, Find, Replaceという項目があります)。dictionariesの後に、arrayの終了タグ()があります。ここではとタグの間に新しいdictionaryを追加します。こんなdictionaryです。

<dict>
 <key>Comment</key>
 <string>change SAT0 to SATA</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 U0FUMA==
 </data>
 <key>Replace</key>
 <data>
 U0FUQQ==
 </data>
</dict>

まずはarrayには順番がありません、どこに入れても良いです。ここでは最後に追加します。すると：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Fixes</key>
 <dict>
 <key>FixHPET</key>
 <true/>
 <key>FixIPIC</key>
 <true/>
 <key>FixRTC</key>
 <true/>
 <key>FixTMR</key>
 <true/>
 </dict>
 <key>Patches</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>change OSID to XSID (to avoid match against _OSI XOSI patch)</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 T1NJRA==
 </data>
 <key>Replace</key>
 <data>
 WFNJRA==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change _OSI to XOSI</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 X09TSQ==
 </data>
 <key>Replace</key>
 <data>
 WE9TSQ==
 </data>
 </dict>
 <dict>
 <key>Comment</key>
 <string>change SAT0 to SATA</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>
 U0FUMA==
 </data>
 <key>Replace</key>
 <data>
 U0FUQQ==
 </data>
 </dict>
 </array>

以上のようになります。

LattePanda AlphaのUSB

Sun, 06 Jan 2019 14:12:18 +0900

シングルボードコンピュータLattePanda AlphaにmacOSをインストールした記事を書きました。その続編です。今回は、USB環境を整えました。

LattePanda AlphaでmacOSを起動する

USBポートの名前を調べる

LattePanda Alphaには3個のUSB 3 Type-Aコネクタと、1個のUSB 3 Type-Cコネクタがついています。USB 3 Type-Cコネクタは電源供給に使っていますが、こういうタイプの変換器を使ってみたらUSB 3として機能していることが確認できました。

BIOS設定画面では、USB 3が4個あることになっていました。それぞれをenable/disableできます。

どうやらType-CのコネクタにはUSB 3が一本あって（Type-Cの本来の規格ではUSB 3は2本可能です）、それがPort1という名前になっているようです。ということは明らかにPort2, 3, 4が3個のType-Aのどれかに相当するはずです。BIOSで一つずつdisableにして、どのコネクタが使えなくなるのか確認しました。その結果、

上のような名前が割り当てられていることがわかりました。以下、この名前でコネクタを区別していきます。

macOSのUSB個数制限

こちらで説明したようにEl Capitan以来のmacOSには、使えるUSBが最大15ポートであるという謎の制限があります。その制限に該当してしまうと、USBコネクタが使えなくなります。回避の方法はいくつかありますが、一番簡単で、副作用がなくて、macOSのアップデートに影響されない方法は、

USBInjectAll.kextを使用して
config.plistのBoot Argumentsで除外するポートを記述する

という方法です。これを行うためには、LattePanda Alphaのどのポート番号が使いたいUSBコネクタに対応しているのかを特定する必要があります。

Lattepanda AlphaのUSB構成

無対策で起動

まずは、USB個数制限に対してなんの対策もせずにmacOSを起動してみました。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。IORegistryExplorer.appはAppleの開発サイトからダウンロードできます。

ここからAppleIDでログインして、Additional Toolsで検索して出てくるツールをダウンロードします。検索結果は複数出てきますが、最新のものをダウンロードすれば良いです。その中にIORegistryExplorer.appがあります。

IORegistryExplorerが起動したら、xhcで検索します。するとUSBポート一覧が出てきます。15個制限がかかっているので15個しか現れません。HSはHigh Speedの略でUSB 2のポートで、SSはSuper Speedの略でUSB 3のポートです。USRは何か不明ですが、SSよりも優先的に機能するポートのようですので、何か重要なものなのかもしれません。とりあえずここでは無視しました。

それぞれのポートをクリックすると右のエリアに詳細が出ます。ここで、port-statusが0の値になっているポートは未使用のポートで、0以外は現在使用中のポートです。

LattePanda AlphaについているPort1, 2, 3, 4にそれぞれUSB 2.0のデバイス（ここではLogitechの無線キーボード・マウス用USBドングルを使いました）を挿して変化を見ていきます。その結果、

HS03 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 –> display, USB, Type-C 変換器を使いました。この変換器の中でUSB 2.0が配線されていないのかもしれませんし、元々LattePandaで配線されていないのかもしれません。またこの変換機にはUSB Type-Aが1個しか付いていないので、もう一つのUSBも存在する可能性はあります。今回はType-Cは電源供給にしか使用するつもりがなかったので、これ以上は調べませんでした。

無反応のHSポートを除外する

LattePanda AlphaのUSBポートにLogitech無線ドングルを挿しても反応しなかったポートは

HS04
HS05
HS08
HS10

でした。不要な様子ですのでこれらを除外します。こちらの方法を使います。つまりUSBInjectAll.kextを使った上で、config.plistのBootセクションに以下を書きます。

<key>Boot</key>
<dict>
<key>Arguments</key>
<string>uia_exclude=HS04;HS05;HS08;HS10</string>

他に必要なArgumentsがあればスペースで区切って列挙しておけば良いです。また、Cloverの起動画面でOptionを選べば一時的にArgumentsを書き換えられます。一時的な試験の場合は、起動画面で書き換えるのが便利です。この結果、

このようになりました。優先的に選択されるHSのポートが減ったので、SSが増えました。結果としてSS04, SS05, SS06が増え、総数は全部で14になりました。15以下ですので、これ以上SSは無いと思われます。この状態では、4個のポートを除外しましたが、3個でも良いようです。

LattePanda 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構成が以下のようであることがわかりました。

HS01 システムが使用中（搭載無線チップの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ソケットに接続されていると思います。

除外するUSBポート

何も除外しないと、最初に示したように、優先度の高い10個のHSと謎の2個のUSRから使用されて、SSは3個しか機能しません。すると、SS04が機能しないのでPort2のUSB 3が使えません。HSを1個以上除外すれば、SS04まで使用できることになります。そこで、

uia_exclude=HS10;SS05;SS06

をArgumentsに指定して、必要なUSBポートが全て動くようにしました。除外リストにSS05, SS06を含めなくても、15個制限に引っかかって除外されるので同じですが、覚書の意味から記載しました。今後、USBがらみで動作不良になるようでしたら、除外リストを再検討することにします。

LattePanda AlphaでmacOSを起動する

Tue, 25 Dec 2018 00:10:29 +0900

最近発売されたシングルボードコンピュータLattePanda Alphaは、Intelの第7世代Core m3-7Y30を搭載しています。MacBook 2017の最下位モデルに搭載されているm3-7Y32のクロック違いバージョンです。公式にはWindowsとLinuxをサポートしていますがmacOSがブートできないはずはありません。インストールの方法を紹介したビデオも複数公開されています。そんなLattePanda Alphaがいよいよ国内で発売になりました。

これにmacOSをインストールすると以下が可能になりました。

スリープとシャットダウン
M.2経由SATAタイプSSDの使用
有線LAN
Bluetooth（こちらをご覧ください）
M.2 WiFiの使用（こちらをご覧ください）
HDMI経由のサウンド
搭載されているArduino
USB Type A
USB Type C （こちらをご覧ください）

試していない機能は以下です。でも多分動くと思います。

M.2経由のNVMeタイプSSD
アナログ音声

LattePanda Alphaの仕様

LattePanda Alphaの特徴は、 m3-7y30プロセッサ搭載ワンボードコンピュータに、サブプロセッサとしてArduinoが搭載されていることです。Arduinoの入出力ピンも基板の縁についています。macOSからArduino IDEでプログラミングして、LEDを点滅させたりできるわけです。仕様を書き出しておきます。

CPUは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 & 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の代理店が出店しているので、そのうち買えるようになるかと思います。

上で述べたように、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ドルです。

追記：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)

macOSをインストールする

ドライブを用意

ドライブ無しのモデルなのでM.2 SSDを調達します。SSDは、NVMeでもSATAでもどちらでも機能します。現状ではSATAの方が安いですし、あまり性能を追求する場面でもないので、安いM.2 SATA SSDを用意しました。2280タイプだとネジ穴がピッタリ合います。

BIOSの設定

LattePanda Alphaを起動してBIOS設定画面に入ります。だいたいは工場出荷時状態でokです。Intel VT-D Techはデフォルトで有効でしたのでdisableにします。次で説明するESP内容を配布しているサイトでは、HDMIから音を出すにはiDisplay Audioをenableにしなければいけないとありますが、これもデフォルトでそうなっていた気がします。

ESP内容の入手

現行のMacBookに限りなく近い構成ですが、macOSを動かすには色々とパッチを当てないといけないようです。Z390マザボで使ったようなシンプルなconfig.plistでは起動しませんでした。検索すると色々な人がmacOSインストールを試していました。以下のサイトではESPの内容を配布してくれていましたので、ESPの一式をダウンロードしました。

Releases · novaspirit/macpanda

インストール用USBメモリ作成

別のmacOSマシンで、App StoreからmacOS Mojaveインストール.appをダウンロードします。この中にあるcreateinstallmediaコマンドを使い、インストール用USBメモリを作成します。これが起動することをmacOSマシンで確認しておきます。

次に、このUSBのESPに、前述のサイトからダウンロードしたESPの中身をコピーします。中身のコピー先がよくわからない場合は、一旦CloverをESPにインストールして、そのCLOVERディレクトリをダウンロードしたものと入れ替えれば良いです。ダウンロードしたものに入っているCloverは多分最新版では無いので、最新のCloverインストーラを使ってインストールし直しておくのも良いと思います。

LattePandaでインストール用USBを起動

LattePandaにUSBメモリを接続して、BIOSで起動ドライブをこれに設定して起動します。ESP一式が揃っていますので難なく起動します。ここからM.2 SSDをフォーマットしてmacOSをインストールします。インストール終了したら、USBのESPを使ってSSDのmacOSを起動します。

M.2 SSDのESPを構成する

macOSが起動したM.2 SSDのESPに必要ファイルを入れます。まずはCloverインストーラでCloverをインストールしても良いです。USBのESPからconfig.plistやkext類をM.2 SSDのESPにコピーし、最終的には同じ状態に構成します。LattePandaを再起動して、BIOSでSSDを起動ドライブに設定すれば、macOSが起動します。

Cloverを設定する

入手したconfig.plistには、コメントアウトされている記述も多く、削除してスッキリさせたい気もしました。ただ、色々チューンされた結果のようで、あまり変更しない方が良いようでした。

ただ、SMBIOSは新しく設定した方が良いと感じました。少なくともシリアル番号はオリジナルな値にしておくべきでしょう。上記サイトで配布されている設定では、なぜかMacBook9,1の設定になっています。Core m3-7Y30に類似したCore m3-7Y32はMacBook10,1ですので、その方が何かと互換性が良くなる気がします。CPUの世代の古い機種に設定してある理由は何かあるのかもしれませんが、気持ちよくMacBook10,1に設定しました。シリアル番号やSmUUIDも新しくします。詳しくはこちらをご覧ください。

SIPを設定するCsrActiveConfigは0x67になっています。0x00にしたかったのですが、起動しませんでした。色々試みたところ0x02が限界のようです。Filesystemへの変更を許可する設定です。起動時にどこかで制限ディレクトリ内容を更新するような動きがあるのかもしれません。

SystemParametersにはCustomUUIDの指定があります。これもuuidgenコマンドで新たに生成した値に変えておいた方が良いと思います。ただ、この項目はなくてもCloverが生成してくれますし、それに失敗した場合はSmUUIDが使われるようです。SMBIOSの設定をしておけば、これは不要かもしれません。

また手元の環境では、「システム終了…」を選んでも、すぐに再起動してしまう不具合がありました。config.plistにFixShutdownをtrueにする設定を追加したところ、これは解決しました。

<key>ACPI</key>
<dict>
        <key>DSDT</key>
        <dict>
                <key>Fixes</key>
               <dict>
                        <key>FixShutdown</key>
                        <true/>

配布されているdrivers64EFIには以下のefiドライバが入っています。

ApfsDriverLoader-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

このうち、

AppleImageCodec-64.efi
AppleKeyAggregator-64.efi
AppleKeyFeeder-64.efi
AppleUITheme-64.efi
FirmwareVolume-64.efi

はFileVaultのためのドライバですので、FileVaultを使わないなら（多分使わないと思いますので）外しても良いと思います。ちなみにkext類は以下がインストールされています。LANはRealtekだったようです。

AppleALC.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であることが確認できます。

$ sysctl -n machdep.cpu.brand_string
Intel(R) Core(TM) m3-7Y30 CPU @ 1.00GHz

WiFiとBluetoothは動きません。macOSと互換性のある無線モジュールが必要です。詳細はこちらをご覧ください。

GeekBenchで測定したところ妥当な結果でした。本物のMacBook10,1のスコアよりは多少悪いのですが、クロックが遅い下位CPUなのでこの程度と思います。クロック差程度の違いです。GeekBenchのサイトにはCore m3-7y30搭載のMacBook10,1という謎仕様MacBookのスコアもいくつか上がっています。どう見てもLattePanda AlphaでmacOSを動かしているお仲間の仕業のようです。

Intel Power GadgetでCPUの動きを確認しました。負荷に応じてクロック数、消費電力、温度が変化するので、電力制御も機能している様子です。アイドル時の消費電力はわずかの1.3wです。IvyBridgeモバイル版Core i3 3217U搭載のNUCですら調整しても2.7wでしたので、その半分の消費電力です。低消費電力macOSサーバとして適していると思います。

Arduinoを使う

開発環境を用意する

LattePandaの特徴はArduinoが搭載されていることです。Arduino Leonardoが搭載されたmacOSマシンは他にはありませんので、注目すべきところです。Arduinoは自作愛好者向けのプログラミングが簡単な組み込みマイクロコンピュータです。そのデジタル・アナログ入出力ピンがボードに搭載されていて、センサー、LED、モーター、リレーなどいろいろな部品を接続できます。ArduinoのチップとメインのCore m3はUSBで接続されています。要するにMacBookにUSB接続でArduino Leonardoを接続した状態になっているわけです。ちなみにArduino Leonardoはこんな製品として売られています。少し安めの互換品も多数出回っています。

Arduinoを使うには開発環境Arduino IDEをここからダウンロードします。寄付を募られますが、無料でも使えます。起動したら、まずは「ツール」から「ボード」を選択します。Arduinoには多くのモデルがあって、ポート番号の割り当てや多少命令系統が違います。ここでは搭載されているArduino Leonardoを選択します。

次に「ツール」「シリアルポート」からシリアルポートを選びます。選択肢の中にArduino Leonardoがありました。内部でUSB接続されていることが確認できます。これを選択します。

これであとはプログラム（Arduinoではスケッチと呼んでいます）を書いて、ダウンロードすれば良いです。

Lチカする

開発環境が整ったら、まずは最も簡単なプログラムを書いて動作確認したいところです。プログラミング言語では、”Hello World!”という文字を画面に表示するプログラムがよく使われます。マイクロコンピュータ開発環境では、接続したLEDをチカチカ点滅させるプログラム、略してLチカがHello World!みたいな存在です。Lチカを書いてみましょう。新規スケッチウィンドウを開きます。Processingという開発環境を使ったことのある人なら、馴染みのあるウィンドウです。Processingを真似て作られたので似ています。ちなみにProcessingの裏ではJavaが動いていますが、ArduinoではC++コンパイラが動きます。

新規ウィンドウにはプログラムの雛形があります。setupとloopという二つの関数があります。setupは起動時・リセット時に1回だけ実行される関数で、loopはその後、無限に繰り返し実行される関数です。setupに初期化関係の処理を書いて、loopに本体を書きます。Lチカを以下のように書きました。

最初に整数型（しかありませんが）変数としてLEDを宣言して、値を13にしています。Arduinoの入出力ポートの13番を使おうとしています。他の番号でももちろん良いです。ちなみに13番は、大抵のArduinoで、ボード上に搭載したLEDに接続されています。LattePanda Alphaでも電源LEDの隣のLEDに接続されています。なので、LEDを接続しなくてもテストができるので楽です。

setupでは、13番ポートを出力モードにしています。この手のマイクロコンピュータは、ピンを有効利用するために、入力にも出力にも切り替えて使えるように設計されています。なので、最初にどちらかに設定しておく必要があるのです。loopでは13番ポートに、最初に電圧を出力し、1000ミリ秒待ち、次に電圧を切り、次にまた1000ミリ秒待つプログラムを書きました。1秒おきに点灯と消灯を繰り返すプログラムで、これでLEDがチカチカします。

ウィンドウの左上にある矢印アイコンをクリックすると、スケッチがコンパイルされて、Arduinoにダウンロードされます。ダウンロード後にArduinoがリセットされて、スケッチが実行されます。LattePanda Alphaの角にある青い電源LEDの隣に赤いLEDがあります。その下にD13と書いてあります。デジタルピンの13番に接続されたLEDという意味です。これが1秒ごとに点滅するはずです。

Arduinoの入出力ポートには、この他、スイッチなどを接続するデジタル入力、アナログ入出力、シリアル接続など様々な機能があります。センサやアクチュエータ、ディスプレイなどを接続することができます。Lチカができればあとは無限の可能性があります。

USBデバイスにする

Arduino LeonardoはArduinoシリーズの中でも高機能なボードです。USBコントローラをチップに内蔵しているので、USBキーボードやUSBマウスの機能を実現することもできます。ここでは、Arduino LeonardoをUSBマウスとして機能させてみます。次のようなスケッチを用意します。

最初にMouse.hをインクルードしています。USBマウス機能を使うためのヘッダファイルです。setupではMouse機能を起動させています。loopの中ではmove関数を使って、x, y方向に30画素進ませて、次に逆方向に30画素戻しています。これをコンパイルして動かすと・・・マウスポインタが右下に少しだけ移動し、0.2秒後に戻ってきて、再び0.2秒後に右下に移動します。とっても邪魔なプログラムが完成しました。頑張って0.2秒のうちにスケッチウィンドウに文字カーソルを置いて、無害なプログラムに書き直して（最終的にはLチカに戻すと良いです）、0.2秒のうちに頑張ってコンパイル・ダウンロードアイコンを押しましょう。

これは邪魔なだけで何の役にも立たないプログラムでした。でもうまく使えば、例えばArduinoのピンにスイッチをつけて、そのスイッチを押すと、「現在のマウスポインタを中心に300×300画素部分をドラッグして選択してくれる機能」、などが実現できます。多少便利かもしれません。

ポストインストール

以上のように問題なくmacOSが動きました。この後は、インストール後の調整をして、少しずつ快適な環境に設定していけば良いです。

WiFi/Bluetoothの設定

こちらで紹介しています。

LattePanda AlphaのBluetooth/WiFi

USBの設定

こちらで紹介しています。macOSの15個制限で、USB 3 Type-Aポートの一つが使えません。これを使えるようにするために、明らかに不要なUSBポートを除外する設定をします。

LattePanda AlphaのUSB

バッテリー設定を消す

機種をMacBookにしたので当然なのですが、「システム環境設定…」「省エネルギー」の設定で、「電源アダプタ」と「バッテリー」の2つのタブが表示されます。「電源アダプタ」タブがデフォルトで表示されるので、こちらで設定しておけば問題ないのです。でもconfig.plistのSMBIOS設定でバッテリーのタブを消すことができます。以下をご覧ください。

電池を搭載してないことをOSに知らせる

LattePanda Alphaの使い道

もともとLattePanda AlphaはWindowsやLinuxが動いてArduinoで制御できるボードとして売っています。Raspberry Piが近いライバルですが、あちらよりはかなり高性能で、しかもWindowsが動くところが売りです。Raspberry PiはLinuxしか動きません。さらには、そこでmacOSが動くのですから、面白いガジェットだと思います。とはいえその面白さが心に響く人はそれほど多くないかもしれません。何が嬉しいのか考えてみました。

超小型・低消費電力の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」に相当するコンピュータですので、こういうものが欲しかったという人が必ず居ると思いました。

つづき

以下もごらんください。

LattePanda AlphaのBluetooth/WiFi

LattePanda AlphaのUSB

9900K搭載Z390マザーボードでHackintoshを作る

Sat, 15 Dec 2018 16:59:13 +0900

久々に最新パーツで組んでみたところ、macOSがすんなり動きました。インテルの第9世代CoreプロセッサCoffee Lake-S Refresh搭載のZ390チップセットマザーボードです。

スロット数で選んだマザーボード

最新パーツでHackintoshを作る上で、マザーボードは選択肢が豊富なパーツです。市販の300シリーズチップセット搭載マザーボードのほとんどでHackintosh可能です。拡張スロット構成、SATA/USB/m.2コネクタ構成、追加機能、色とデザインなど考慮して、各人の目的や好みに合わせて自由に選んで良いです。だいたいどれでもちゃんと動くと良いと思います。特にこだわりがなければ、掲示板やブログでHackintoshに成功したとの報告のあるマザーボードを選んでおけば良いです。今回はASUS ROG MAXIMUS XI HEROを選びました。問題なく動きます。

ASUS ROG MAXIMUS XI HEROを選定した１番の理由はPCIeスロット数が多いことです。多くの人はMacからなくなってしまった拡張性を求めてHackintoshをしていると思います。なのでPCIe空きスロットが多いことは重要です。ATXマザーボードには規格上最大7本のPCIeスロットを搭載できます。たくさんありますが、どうしても必要なスロットを考えると、自由に使える「空きスロット」はだんだん少なくなっていきます。

まずは、Hackintoshでは高性能で安定しているグラフィックスボード（以下グラボ）を使用することが多いです。一般的なグラボは2スロット占有するので、グラボを1枚挿すと空きは5本になります。

使いにくいスロットもあります。Z390チップセットにはグラボ2枚挿しできるように、CPU直結PCIeを分割する機能があります。グラボ2枚あれば、NVIDIAではSLI, AMDではCrossFireと呼ばれる機能を使って描画を高速化できます。しかしmacOSではこの機能が使えないので、分割されたPCIeスロットは使いにくいです。分割用スロットを使ってしまうと、グラボへのデータ転送スピードが低下するからです。詳細は以下の記事で説明しました。ということでCPU直結PCIeを分割したPCIeスロットがあったら、それは使わないことにしたいです。とすると、その場合、空きは4本になります。

Z390 m-ATXマザボのPCIe

kakaku.comでZ390マザーボードを検索すると、現時点で38製品もあります。選択肢は豊富です。これらの製品のPCIeスロットから、グラボ用のスロット、その隣のスロット、SLI用分割スロットを除外した「空きスロット」を数えてみました。すると以下のようでした。

GIGABYTE 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と比較して見劣りがします。

自作PCの良いところはメーカ製PCに比べて良質なパーツを選べる点だと思います。なので、マザーボードもそこそこ良い製品を選びたいと考えています。過去に安いマザーボードを選んだところ、動作に問題はないのですが、基板が薄くてヘリが曲がっていたこともあります。しっかりとした厚みがあり、重量感のあるマザーボードを選びたいと思います。また上位の製品には、オンボードのスイッチや状態LEDなどがあり色々と便利です。

という観点からマザーボードを選定し、リストの比較的上位にありながらスロット数が4本あるASUS ROG MAXIMUS XI HEROを選びました。高級感があり、BIOSで設定できる内容も多くて満足できる製品でした。ASUS ROG STRIXも良いと思いましたが、英語や漢字をあしらった模様が施されているのが趣味に合わなかったです。ASUS ROG MAXIMUS XI HEROで一番気に入った機能は、OS不要かつネットワーク経由でBIOSアップデートが行えることです。BIOSメニューからASUSのサーバにアクセスして新しいBIOSをダウンロードしてアップデートできます。

CPUは9900K

CPUは話題のCore i9-9900Kにしました。インテルの第9世代CoreプロセッサCoffee Lake-S Refreshシリーズです。現在も品薄傾向がありますが、以前よりは買いやすくなったようです。8コア16スレッドあるのが楽しみです。

9900Kの正12面体パッケージは想像していた以上に大きいです。かさばって邪魔です。ちなみにこれほどの性能が日々の作業に必要かというと、全くのオーバースペックです。自動車・カメラ・ピュアオーディオなどのオタクが身の丈に合わない機材を揃えるのと同じです。macOSをブートすることが楽しみなのでそれで良いのです。

グラフィックスはRX 580

グラフィックスボードはRadeon RX580を使用しました。Mojaveで使う現行製品としてはRX560/570/580/590/Vega56/Vega64しか選択肢はありません。今回はSapphireを使用しました。でも、どこのブランドでも大丈夫です。

ドライブはSSD

以下の作業では、手元に余っていた2.5インチSSDを使ってインストールしています。その後、M.2 SSDに移行しました。将来的には、

256GB程度のシステム用（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を購入しました。

M.2 SSDを取り付けた作業の詳細は以下をご覧ください。

ASUS MAXIMUS XI HEROにM.2 SSD (WD SN750)を取り付ける

そのほかのパーツ

マザーボード搭載のWiFiはインテル製なので動かないです。一方で、マザーボード搭載のBluetoothは、Ericsson製品のようですが、macOSからある程度認識されました。LattePandaの場合のように、kextを用意すれば動くのかもしれません。でもこれらは使わずに純正と同じ無線モジュールを手配しました。今回は、BCM943602CSを使ってみました。入手可能な純正無線モジュールの中では最新製品で安価です。

電源、CPUクーラは、その辺りに転がっていた余り物を使いました。マザーボードには8pin + 4pinのCPU補助電源コネクタがあるのですが、電源には8pinしかなかったので、4pinは接続していません。OCしないこともあり、それでも大丈夫のようです。当分はケースもなしです。パーツが机の上に並べてあるだけです。メモリー, 2.5インチSSDは、動いているマシンから抜き取って流用しました。なので特に紹介するほどの内容ではありません。

BIOS設定

macOSを起動させるにはBIOSを設定する必要があります。

マザーボード (BIOS) 設定

でも今回使用したASUS ROG MAXIMUS XI HEROではほとんど設定する必要がありませんでした。試してみたら、なんと工場出荷時状態でもmacOSが起動しました。ちなみに、何か設定してしまった後で工場出荷時状態に戻すには、EXIT/Load Optimized Defaultsを選びます。工場出荷時状態で使うのはあまりにも手抜きなので、以下のメニューだけを変更しました。

Boot/Boot Configuration/Fast Boot [Enabled] –> [Disabled]
Advanced/USB Configuration/XHCI Hand-off [Disabled] –> [Enabled]
Advanced/USB Configuration/Legacy USB Support [Enabled] –> [Auto]
Advanced/Onboard Devices Configuration/Connectivity mode (Wi-Fi & Bluetooth) [Enabled] –> [Disabled]
Advanced/CPU Configuration/Intel (VMX) Virtualization Technology [Disabled] –> [Enabled]

1番目のFast Bootはdisabledにした方が良いようです。2, 3番目のUSBに関する設定は効果があるのかどうかよくわかりません。

4番目のWi-Fi & Bluetoothはマザーボード搭載モジュールのことです。このマザーボードにはインテルの無線モジュールが搭載されているのでmacOSでは動きません。なので、無線モジュールはdisabledにします。これをEnabledのままにしていると、macOSはBluetoothとしてマザーボード搭載モジュールを使用しようとします。そうすると、macOSと互換性のあるBluetoothモジュールを後から取り付けても、認識されません。アップルの開発者向けページで配布されているツールを使えば使用するBluetoothモジュールを変更できますが面倒です。WiFi/Bluetoothはどうせ使えないので、Disabledにしておきましょう。

5番目のIntel (VMX) Virtualization Technologyは、デフォルトのDisabledのままでもずっと問題ありませんでした。でも仮想マシンのアプリ（具体的にはVirtual Box）を使おうとしたところ、これをEnabledにしておく必要がありました。

起動用SSDを作る

ハードウェアが揃って、BIOS設定が終わったら、いよいよmacOSのインストールを行います。通常のHackintoshインストール手法では、起動用のUSBメモリを作ってmacOSをインストールします。しかし、今回はmacOSが動いているマシンがあるので、それで起動用の2.5インチSSDを作りました。USBメモリを作る場合も、macOSが動いているマシン（以下、親マシンと呼びます）が必要ですので、いっそそれでSSDを作った方が確実だと思います。その親マシンが本物のMacならmacOSが起動することが確認できますし、親マシンがHackintoshならそれに加えてCloverの動作も確認できます。

Step1: Mojaveをインストール

親マシンに2.5インチSSDを接続したら、Disk Utility.appを使ってAPFSでフォーマットします。2.5インチSSDなのでMojave25SSDという名前にしました。

次に、App Storeから正規にダウンロードしたMojaveをこのSSDにインストールします。App Storeからダウンロードすると、「macOS Mojaveインストール.app」がアプリケーションフォルダ内に現れます。ダウンロード後に、これが自動的に開きますので、SSDにインストールします。終了後に、この2.5インチSSDからmacOSが起動できることを確認して、ついでに自分のアカウントも作っておきます。作ったアカウントのディレクトリに色々なツールも入れておくと良いです。

Step2: Cloverをインストール

親マシンに2.5インチSSDを接続したまま、これにCloverをインストールします。親マシンにCloverがインストールされているのであれば、起動ESPの内容をSSDのESPにドラッグ&ドロップでコピーしても良いです。ESPのマウントの方法は、ここなどに書いておきました。

新規にインストールしたい場合はCloverインストーラを起動して、SSDにインストールします。Cloverインストーラが起動したら、カスタマイズボタンを押してインストールする内容を選択します。まずは、ESPにインストールするチェックボックスを選びます。

UEFI Driversでは有効にするEFIドライバを選択します。今回は、以下を選択しました。

VBoxHfs-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は必須でした。これが無いとスリープとシャットダウンで固まってしまいます。このことは、以下の記事で書いておきました。

ASUS Z390マザーボードのshutdown/sleep対応

Step3: kextを入手・インストール

以下のkextの最新版を入手し、親マシンを使って2.5インチSSDにインストールします。

FakeSMC.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）は後回しにしても良いです。

今回は手元にある別のHackintoshから持ってきました。もし初めてHackintoshを作るのでしたら、ネットで検索して最新版を入手します。kextを管理するのに便利なKext Updater.appを使っても良いです。このアプリケーションのウィンドウで、”Load Single Kext”オプションを使用し、欲しいkextを指定し、ダウンロードします。Kext Updater.appの説明はこちらをご覧ください。

最後にこれらのkextをESPの中のEFI/CLOVER/kexts/Otherに入れます。ターミナルでEFI/CLOVERにcdして以下のコマンドを入れるとディレクトリがツリー状に表示されます。

pwd;find . | sort | sed '1d;s/^\.//;s/\/\([^/]*\)$/|--\1/;s/\/[^/|]*/| /g'

インストールの結果、CLOVER以下のファイルはこのようになります。枝葉の部分は省略しました。

/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のガイドをご紹介しておきました。これを基にして作っていきます。

corpnewtさんのバニラガイド~Coffee Lake用config.plist

SMBIOSの項目には、固有のシリアル番号を書き込みます。これは、Clover Configuratorを使って機種を設定して作成したSMBIOSをコピーします。詳しい説明は以下をご覧ください。

正しく機種設定する (SMBIOSの設定)

ただ、最近のCloverでは、SMBIOSのかなりの部分を自動的に作ってくれるようです。ファームウェアバージョンなどを最新にしてくれるようなので、config.plistで指定しない方が良いかもしれません。ということで最近は、

~~BoardSerialNumber~~
~~ProductName~~
~~SerialNumber~~
~~SmUUID~~

~~だけを書くようにしています。この結果、SMBIOS部分は以下のようになりました。xxxxの部分は、Clover Configuratorとuuidgenコマンドで生成してください。~~

 <key>SMBIOS</key>
 <dict>
 <key>BoardSerialNumber</key>
 <string>xxxxxxxxxxxxx</string>
 <key>ProductName</key>
 <string>Macmini8,1</string>
 <key>SerialNumber</key>
 <string>xxxxxxxxxxxx</string>
 <key>SmUUID</key>
 <string>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</string>
 </dict>

ProductNameはMacmini8,1にしました。最新版のMacで第8世代CPU Coffee Lakeが搭載されています。第9世代のCoffee Lake-S Refreshは第8世代の改良版ですし、チップセットは同じ300シリーズですので、相性が良いと考えました。本当なら今回と同じ第9世代CPU搭載のiMacがあればそれを選びたいところです。早く新型iMacを出してほしいものです。

~~一方、Devicesの中のPropertiesの部分は以下のようにしました。~~

追記：10.14.4ではPropertiesの記載は不要になりました。10.14.3以前では必要です。

<key>Properties</key>
 <dict>
 <key>PciRoot(0x0)/Pci(0x2,0x0)</key>
 <dict>
 <key>AAPL,ig-platform-id</key>
 <data>
 AwCSPg==
 </data>
 <key>device-id</key>
 <data>
 mz4AAA==
 </data>
 <key>framebuffer-patch-enable</key>
 <data>
 AQAAAA==
 </data>
 </dict>
 </dict>

device-idをzD4AAA==にします。9900KのIntel UHD Graphics 630は、Macmini8,1のUHD 630とは違うデバイスIDを持っています。それでデバイスIDをMacmini8,1のIDに合わせました。これを合わせないと、スリープで問題が出たり、JPEGファイルのクイックルックが動かない不具合が発生します。こちらの記事もご覧ください。

9900Kのsleep問題〜原因はiGPUのデバイスID

AAPL,ig-platform-idは、iGPUを計算のために使う設定（表示にはdGPUを使う設定）にしています。iGPUを表示に使う場合は、AwCSPg== になっている現在の設定をBwCbPg==に変更します。

追記：9900K対応のiMac Early 2019が発売されて、これ専用のmacOS Mojave 10.14.4 (18E2034) が入手可能になりました。なので以下に示すようにSMBIOSも新型iMacに合わせました。

SMBIOSは、9900K搭載の27インチiMac Early 2019に合わせることにしました。最新のClover Configuratorを使うと新型iMacであるiMac19,1のSMBIOSを生成することができます。まずはClover Configuratorの左のメニューからSMBIOSを選び、モデルのアイコンの下でiMac19,1を選びます。すると以下のように各種値の候補値を出してくれます。

この後、左のメニューから、Text Modeを選ぶとSMBIOS部分が表示されます。

この結果、SMBIOS部分は以下になります。（シリアル番号、ボードシリアル番号、SmUUIDはこの記事のために生成したサンプルです。実際には違う値を設定してください。）

	<key>SMBIOS</key>
	<dict>
		<key>BiosReleaseDate</key>
		<string>02/18/2019</string>
		<key>BiosVendor</key>
		<string>Apple Inc.</string>
		<key>BiosVersion</key>
		<string>IM191.88Z.F000.B00.1902181222</string>
		<key>Board-ID</key>
		<string>Mac-AA95B1DDAB278B95</string>
		<key>BoardManufacturer</key>
		<string>Apple Inc.</string>
		<key>BoardSerialNumber</key>
		<string>C02921130GULNV9JA</string>
		<key>BoardType</key>
		<integer>10</integer>
		<key>BoardVersion</key>
		<string>1.0</string>
		<key>ChassisAssetTag</key>
		<string>iMac-Aluminum</string>
		<key>ChassisManufacturer</key>
		<string>Apple Inc.</string>
		<key>ChassisType</key>
		<string>0x09</string>
		<key>EfiVersion</key>
		<string>220.250.368.0.0</string>
		<key>Family</key>
		<string>iMac</string>
		<key>FirmwareFeatures</key>
		<string>0xFC0FE137</string>
		<key>FirmwareFeaturesMask</key>
		<string>0xFF1FFF3F</string>
		<key>LocationInChassis</key>
		<string>Part Component</string>
		<key>Manufacturer</key>
		<string>Apple Inc.</string>
		<key>Mobile</key>
		<false/>
		<key>PlatformFeature</key>
		<string>0x00</string>
		<key>ProductName</key>
		<string>iMac19,1</string>
		<key>SerialNumber</key>
		<string>C02YR2YHJV3Q</string>
		<key>SmUUID</key>
		<string>04FF56E3-085F-443D-9005-5E6915EDDC33</string>
		<key>Version</key>
		<string>1.0</string>
	</dict>

最近は、Cloverが補完してくれるので、SMBIOSに書くべきパラメータは以下の4個で良いようです。ただ、まだCloverがiMac19,1に完全に対応していないと思われるので（ベータ版はかなり対応しているようです）今回は長いですが全部書き込みました。将来は以下の4個に削っても良いと思います。

BoardSerialNumber
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オプションに、

<key>Boot</key>
   <dict>
     <key>Arguments</key>
     <string>-no_compat_check</string>

と記載します。これでmacOS 10.14.4 (18E226) で起動するようになります。

このようにして作ったconfig.plistの全体を以下に置いておきます。

config.plist for 9900K w/o iGPU display - Pastebin.com

config.plistをテキストエディタで編集すると、うっかり間違った入力をしてしまうことがあります。以下のplutilコマンドでplistとして正しいかどうかチェックをしておくと良いです。

plutil config.plist

正しければ以下のように表示されます。

config.plist: OK

動作の確認

こうして作成したSSDを親マシンから外して、ASUS ROG MAXIMUS XI HEROに接続します。これから起動すると、無事macOSが起動しました。以下のように、ほぼ問題なく動きました。

シャットダウンが正しく機能します。
スリープも正しく機能します。設定したスリープ時間になると、画面が消えて、マザーボードのLED類が消えて、CPUファンが停止します。キーボードを押すと復帰します。また、画面共有やsshなどで接続しても復帰します。
有線ネットワークも問題ありません。
WiFiとBluetoothも、純正のカードを用意したので、何もせずにそのまま動きました。
音声も出ます。config.plistではLayout番号1を設定しましたが、これとAppleALC.kextの組み合わせで問題なく音が出るようです。
RX580のHDMIポートからも音が出ます。
さらにはCPU内蔵のIntel UHD Graphics 630から表示もできますし、マザーボードのHDMIから音声も出ます。

10.14.3へのアップデートもシステム環境設定で行うことができました。

Activity Monitor.appで「CPUの使用率」を開くと、16本の棒グラフが出てきます。圧巻です。

Geekbenchでベンチマークしてみました。シングルコアが6,000, マルチコアが30,000超えました。Geekbench BrowserでiMac Pro Late 2017のスコアを見てみると8コアモデルでそれぞれがだいたい5,300と33,000くらいのようです。8コアiMac Pro程度の速度が得られているようです。

今回使用したマザーボードは、そこそこ高級感があって良い感じでした。基板上にCPU温度表示などがあります。また電源スイッチ、リセットスイッチもあるためHackintoshの試行錯誤にも便利です。最近流行りのLED電飾機能ASUS Aura Syncも搭載しています。温度や音に同期して色を変えるなどの機能を使うためにはWindowsアプリケーションが必要ですが、刻々と変色するだけで良ければマザーボードだけで機能します。LinuxからLEDを制御しようとしている人もいるようですので、そのうちmacOSからも制御できる日が来るかもしれません。

その後の調整

これでとりあえず動きました。もう少し手を入れて完璧にしていきましょう。

10.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) ならばこの互換性回避オプションは不要です。

実はiMac19,1や19,2として一旦起動すれば、18E2034が入手可能になります。詳細は以下をご覧ください。

9900KのためにmacOS 10.14.4 (18E2034) を入手する

USB

macOSはUSBの個数を15個に制限しています。今回は何の対策もしていないので、制限を超えるUSBポートのいくつかは機能していません。そこで不要なUSBポートを使わない指定をconfig.plistに書き込みます。詳細は、以下をご覧ください。

ASUS MAXIMUS XI HEROのUSBを設定する

要約するとこうです。このマザーボードが使っているポートは、

HS01 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に書き込みます。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string>uia_exclude=USR1;USR2;HS01;HS02;HS09;HS10;HS14;SS01;SS02</string>

SS10は末尾なので、除外リストに入れる必要はないです。この場合、バックパネルのUSBポート全てと、基板上のUSB 2.0が使えるようになります。

tonymacx86式インストール手順 (その3: バニラ化と調整)

Fri, 14 Dec 2018 01:17:00 +0900

UniBeastとMultiBeastを使ってmacOSをインストールした前回

tonymacx86式インストール手順 (その1: UniBeast)

tonymacx86式インストール手順 (その2: MultiBeast)

に引き続き、今回はバニラな構成にし、設定を調整する方法を紹介します。

ESPをマウントする

前回の作業で一応Hackintoshが起動するようになりました。MultiBeastは何をしてくれたのでしょうか。まずはMultiBeastがどこに何をインストールしてくれたのかを確認します。そのためにまずはESPをマウントします。

ESPをマウントするには、専用のアプリもありますしKext Updater.appなどでも可能です。でも一番基礎的なターミナルでの作業を知っておくのも良いと思います。まずはドライブを確認します。ターミナルから、

$ diskutil list

とタイプすると、マシンに接続されたドライブの一覧が出ます。MultiBeastがインストールした起動ドライブ関係を見ると、

/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) については、こちらをご覧ください。

ここでESP (EFI System Partition)はdisk0s1であることがわかります。以下のdiskutil mountコマンドでマウントできます。管理者権限が必要なのでsudoコマンドを使っています。実行するとパスワードを聞かれます。

$ sudo diskutil mount disk0s1
Volume EFI on disk0s1 mounted

これにより、/Volumes/EFIの下にESPがマウントされます。

ここには、Cloverブートストラップローダプログラムや、efiドライバ、config.plistなどがインストールされています。

KextをESPに移動してバニラ化する

macOS本体に手をつけないバニラなインストールでは、kext類もESP、すなわちCLOVERのkexts以下に入れておきます。しかしMultiBeastではkextをESPに入れてくれません。MultiBeastはkext類を/Library/Extensions以下（略して/L/E）にインストールします。/L/E以下の内容を見てみましょう。

ここで選択した8個のkextがMultiBeastがインストールしたものです。とりあえずは動いているので、このままで良いでしょう。AHCI_3rdParty_eSATA.kextは、MultiBeastのインストールで指示したので入っています。でも、効果は感じられないですので、外しても良いかもしれません。FakePCIIDで始まる2個のkextもインストールの時に指示したものです。これもなくても問題なく動いていますので、外しても良かったかもしれません。

MultiBeastがなぜESPじゃなくて/L/Eにkextをインストールするのかについて公式の説明はないと思います。おそらくは、kextによってはESPでは動かないものが稀にあるので、/L/Eにインストールしているのではないかと思われます。でもここでインストールされたkextはESPでも動くものばかりです。ESPに移せば、macOS部分は手つかずのバニラな状態になります。EFI/CLOVER/kexts/Otherの中に移動しておきましょう。ドラッグ&ドロップではコピーになってしまいます。kextが二重に存在するのは好ましくないので、MultiBeastがインストールした/L/Eのkextは消しておきましょう。

EFIドライバ

ESPの中のEFI/CLOVER/drivers64UEFIの中にはEFIドライバ類が入っています。MultiBeastが何を入れたか確認しておきます。

VBoxHfs-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と同じく、とりあえずは動いているので、このままで良いと思います。でも外しても動くようなら除外しても良いと思います。今回のハードウェア構成では、以下のドライバだけで問題なく動きます。

VBoxHfs-64.efi
SMCHelper-64.efi
FSInject-64.efi
AptioMemoryFix-64.efi
ApfsDriverLoader-64.efi

Config.plist

MultiBeastが作ってくれたconfig.plistを次に見てみます。以下に掲載しておきました。これも、起動しやすいことを目指して、安全よりの設定になっています。下記で説明するSMBIOSの項目以外は、このまま使い続けて構わないと思います。

config.plist by MultiBeast - Pastebin.com

ACPI

ACPIの最初のキーはDSDTです。この中のDropOEM_DSMのkeyは、#DropOEM_DSMと改名されています。存在しないキーに改変されていることで、コメントアウトになっています。ここの設定は消してしまっても構わないです。Fixesのkeyは、すべてfalseです。デフォルトがfalseなのでこれも全部消してしまっても構わないです。ということでDSDTはNameキーくらいはあっても良いけど、他は消してしまっても大丈夫です。

次のDropTablesのkeyではMATSが外してあります。昔はMATSがカーネルパニックを引き起こしやすかったらしいのですが、今はdropしなくても大丈夫です。消しても構わないです。

次のHaltEnablerはfalseなので消してしまって構わないです。シャットダウンした後で起動してしまう症状が現れるようならtrueにしてみると効果があるかもしれません。

SSDTはこのままでも良いです。DropOEMは消しても良いです。

結果、ACPIはこれくらい書いてあれば十分です。

 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Name</key>
 <string>DSDT.aml</string>
 </dict>
 <key>SSDT</key>
 <dict>
 <key>Generate</key>
 <dict>
 <key>CStates</key>
 <true/>
 <key>PStates</key>
 <true/>
 </dict>
 </dict>
 </dict>

Boot

Bootはこのままで良いです。DefaultVolumeは起動ドライブの名前にしておきます。Timeoutはマイナスにするとキーボード入力待ちします。色々調整する場合はマイナスにしておくと便利です。

Devices, DisableDrivers

FakeIDは全部ゼロのままなので、効いていません。DisableDriversも何も指定していません。両方とも消してしまっても構わないです。

GUI, Graphics

このままで良いと思います。必要に応じて変更します。

KernelAndKextPatches

KextsToPatchのキーに外部ドライブがオレンジ色アイコンになることを阻止するパッチが書いてあります。ほとんど困らないと思いますので、削除しても良いと思います。副作用を考えるとパッチは少ない方が良いですから、不要なパッチは外しておきましょう。

RtVariables

CsrActiveConfigは0にしておくとSIPが有効になります。kextをESPにすべて移動したので0でも大丈夫なはずです。SIP有効にすれば実機と同じになるので気持ちが良いです。

BooterConfigは、実は何も使われていないです。以前、Cloverのソースを見て確認しました。消しても構わないです（あっても大丈夫ですが）。

SMBIOS

MultiBeastはTrustのキーしか作ってくれません。最近のCloverはSMBIOSのいくつかの項目を自動で作ってくれますが、完全ではありません。こちらのガイド

正しく機種設定する (SMBIOSの設定)

を見て、少なくとも以下の項目は作成しておくのが良いです。

BiosVersion
ProductName
SerialNumber

実際、MultiBeastの前回の設定では、ProductNameをiMac15,1にしました。しかしconfig.plistではそれが書かれておらず、iMac14,2になってしまっています。SMBIOSをしっかり設定することで、ハードウェアに合致した機種IDになり、トラブルを回避できます。

SystemParameters

この部分は、MultiBeastがインストールしたそのままで大丈夫です。

今後の調整

今回の作業で、バニラなシステムになり、機種名が正しく設定できて、より安定なシステムになったのではと思います。終了、スリープなども機能します。ネットワークにも接続できていると思いますので、一通りの機能は使えていると思います。ただ、いくつかやり残している機能もあります。

サウンド

AppleALC.kextがあり、またconfig.plistのAudioでInject 1としているので、運が良ければ音は出ます。でなければ、Injectの数値を変えるか、VoodooHDAを使うか、USBオーディオを使うと良いです。

音を出す

USB

USBの上限個数15を外すパッチを採用しませんでした。そのため使えないUSBポートがあるかもしれません。こちらを見て対応すると良いです。

USBポートを設定する

おまけ：名前の由来

Cloverの前に一般的だったブートローダープログラムがChameleonでした。macOSがインストールできるようにマシンを変化させる機能を、色を変えられるカメレオンになぞらえたのだと思います。Chameleonはオープンソースだったので、tonymacx86の中の人がこれをフォークしてtonymacx86版のブートローダープログラムを作り、これをChimeraと名付けました。異種のOSを起動できる機能を、色々な動物の部位を併せ持った伝説上の生き物になぞらえたのだと思います。

(Chimeraのアイコン)

Chameleonは古いハードウェアから最新ハードウェアまで満遍なくサポートするのに対して、Chimeraは古いハードウェアは切り捨てつつ、最新ハードウェアに積極的に対応する違いがありました。tonymacx86で提供するおすすめハードウェア構成で確実に動くことを目指していました。

その後、Chimeraとkext類をインストールして設定するためのインストーラが作られて、その名前がMultiBeastになったわけです。キメラをもじっての命名だと思います。その後に出た、インストール用USBメモリー作成ツールは、USBのUniversalと、どのマシンでも起動するユニバーサルなアプリであることからUniBeastと名付けられたと思われます。

tonymacx86式インストール手順 (その2: MultiBeast)

Mon, 10 Dec 2018 00:30:56 +0900

MultiBeastを使って「ポストインストール」する方法をHackintosh初心者向けに紹介します。MultiBeastはtonymacx86.comで作られて配布されているHackintosh作成ツールです。Apple純正インストーラやUniBeastによりmacOSがインストールされたドライブに、Cloverやkext類をインストールし、macOSを起動できる状態にしてくれます。インストールが簡単になってしまうので何をやっているか理解しないでHackintoshを作ってしまうとか、バニラなインストールにならないなどの批判もあります。しかし何をどうしたら良いかわからない初心者にはありがたいツールです。動かすまでに苦労することがHackintoshの醍醐味ではありますが、とりあえず動かないと心が折れます。なので、Hackintosh初心者は、まずはMultiBeastでインストールして、動くことを確認して、チューニングを施してバニラな構成に持っていくのも良いと思います。

tonymacx86式インストール手順

tonymacx86で推奨されているインストールの手順は：

動いているmacOSマシン（以下、親マシン）でApp StoreからmacOSをダウンロードする。
親マシン上でUSBメモリを初期化する。
親マシン上で、tonymacx86配布のUniBeastというツールを使ってインストール用USBメモリを作る。（UniBeastはcreateinstallmediaコマンドと同様にインストール用USBメモリを作り、それに標準的な構成でCloverをインストールします）
Hackintoshを作ろうとしているマシン（以下対象マシン）でインストール用USBメモリを起動する。
対象マシンに接続したドライブにmacOSをインストールする。（インストール用USBメモリを使うとこのドライブからmacOSを起動できます）
macOSで起動した対象マシン上でMultiBeastを使ってClover等をインストールし、そのドライブ単体でmacOSを起動できるようにする

です。1から5のステップは以下で説明しました。

tonymacx86式インストール手順 (その1: UniBeast)

この記事では6番目の最後のステップを説明します。この太字部分を「ポストインストール」とも呼んでいます。

MultiBeastでポストインストール

UniBeastは大抵のマシンで起動できるUSBドライブを作ってくれて操作も簡単です。それに対してMultiBeastによるポストインストールの手順は選択肢も多くて大変です。完成度を高めるためには調整も必要です。今回は、とりあえず動くところを目指し、バニラなインストールを目指した調整を次回に行います。

今回インストールを試みるマシンは、Haswell CPUとRadeon RX-580を使ったマシンです。まずはインストール先のハードウェアを調査しておきます。このマシンのマザーボードはMSI Z97A Gaming 7で、これには、以下のチップが搭載されています。

Intel 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を起動するとこんなウィンドウが出ます。

左上にはアイコンが並んでいます。このアイコンを左から順番に選択して作業を進めていきます。また、アイコンを選択すると、何のためにどの様な作業が行われるかの説明が表示されます。これを読んでいくと勉強になります。

Quick Startアイコン

まずはQuick Startアイコンを押します。すると、UEFI Boot ModeとLegacy Boot Modeの選択が可能になります。UEFI対応になったマザーボードですのでUEFI Boot Modeを選びます。CloverやkextがESPにインストールされるので、バニラなインストールに近くなります。

これを選択すると、

CloverがUEFIブート状態でインストールされ、
システムの設定がiMac14,2になって、
kextはFakeSMCがインストール

されるようになります。

Driversアイコン

次にDriversアイコンをクリックします。すると、Audio, Disk, Misc, Network, USBのアイコンが出ます。

Audioでは、音を出すドライバとして、以下の3種類を選択できます。音は後回しにしても良いと思うのでしたらどれも選択しなくても良いです。

AppleALC これを選んでおきましょう。一番新しくておすすめな方法です。Lilu.kextと一緒にインストールされて必要なパッチも全て行ってくれます。
Realtek ALCxxx 少し前に一般的だった方法です。色々とパッチを当てる必要があります。
Universal Voodooシリーズのドライバを入れる選択肢です。一番確実に動きますが、音が割れたりすることもあります。

Diskでは、以下を選択できます。インテルチップセット接続のSATAは、ここで何もしなくても動きますので、追加のSATAが不要ならどれも選択しなくて良いです。

3rd 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です。これだけはチェックします。

FakeSMC 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がインストールされます。

USBでは、以下を選択できます。

3rd 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に関するちゃんとした設定はあとで行いましょう。詳しくはこちらをご覧ください。

USBポートを設定する

Bootloaderアイコン

次にBootloaderアイコンをクリックします。

このアイコンでは以下の選択ができます。

Clover 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の設定に関して、詳しくはこちらをご覧ください。

NVRAMのエミュレーション

Customizeアイコン

次にCustomizeアイコンをクリックします。

Graphics Configurationでは以下の選択がでます。しかし、今回の構成で必要な項目はありません。何も選択しなくて良いです。

Intel 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に必要な項目はありません。何も選択しなくて良いです。

System Definitionsでは、今回の構成に近いMacのモデルを選択します。Macの仕様は、MacTracker.appなどで調べると良いかと思います。今回は、iMac15,1を選択します。

Buildアイコン

最後にBuildアイコンを選択すると今までの設定のまとめが出ます。これで問題無いことを確認できたら、右下のInstallアイコンをクリックします。するとSelect Install Driveで示されたドライブ（ここではMojave255SSD）のESPと/Library/Extensionsに必要なファイルがインストールされます。

以上で、ポストインストールが終了します。

起動する

いよいよこのドライブで起動してみましょう。tonymacX86で用意された特別なthemeが設定されているので、Cloverの起動選択画面はこんな感じになります。

これで問題なく起動します。

シリアル番号は（たぶん）Cloverが適当に生成してくれています。機種名はちょっとおかしいです。そのあたりはまた次回に調べたいです。でも問題なく起動して動作します。とりあえず起動するドライブを作れるという点で、MultiBeastは優れたツールだと思います。

次回は、MultiBeastが何をどこにインストールしたのか、それをどう改善していけるかを調べてみたいと思います。こちらに続きます：

tonymacx86式インストール手順 (その3: バニラ化と調整)

Recoveryからブートする

Sat, 08 Dec 2018 01:54:37 +0900

macOSをインストールすると、macOSの本体が入るボリュームの他に、Recovery（回復）用のボリュームが自動的に作成されます。Recoveryボリュームは、Cloverの起動画面に起動選択肢として現れます。右下の十字マークは、赤十字や病院の印です。macOS本体が起動しなくなってしまった非常時には、Recoveryボリュームから起動して復旧作業を行えます。

Recoveryボリューム

Recoveryボリュームの場所

diskutil listコマンドでマシンに接続されているドライブを見ることができます。コマンドの結果例を以下に示します。このマシンには512GBのSSDが接続されていますが、それがdisk0に割り当てられていることがわかります。disk0はEFIが使用するESP (EFI System Partition)とAPFSのコンテナに分割されています。APFSのコンテナは仮想的なドライブとしてdisk1に割り当てられています。

$ 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を共有しています。ここには実際に使用している容量が書いてあります。

/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です。

disk0s1: ESPです。ここにClover関係のファイル、Cloverが読み込むkext類があります。マザーボードのBIOS設定では、起動ボリュームとしてここを設定します。電源投入後、Cloverがkext読み込みとパッチ当てを終えるとmacOSを動かせます。
disk1s1: macOSの本体です。通常はこれで起動します。電源投入後にESPからHackintoshに必要なパッチやkextが読み込まれていれば、純正インストーラがインストールしたそのままで（バニラの状態で）動きます。
disk1s3: Recoveryボリュームです。非常時に起動することができます。ESPのファイル群によりHackintoshに必要な処理が終っていれば、これもバニラのまま動きます。

というわけで、バニラなCloverインストールが行われていれば、純正インストーラによりインストールされたmacOSだけでなく、Recoveryからも起動できるわけです。

/posts/131/

ちなみに、残りの二つのボリューム、PrebootとVMは、以下のものです。PrebootはAPFSボリュームからmacOSをブートするための作業用ボリュームらしいです。詳しい働きはわかりません。VMは仮想メモリ(Virtual Memory) のスワップ用ボリュームのようです。使われていないメモリ内容をここに保存します。以前のmacOSではスワップ領域がファイルだったようですが、APFSになってボリュームになりました。従来の物理的なボリュームだと記憶領域が固定されてしまうけど、APFSなら他のボリュームと共用できるので無駄がありません。ということで、ファイルよりおそらく効率の良いボリュームに変更されたのかと思います。

Recoveryボリュームの内容

Recoveryの中に何が保存されているかを調べてみましょう。これがdisk1s3だとわかっているので、以下のコマンドでマウントできます。この結果、/Volumes/Recoveryというフォルダにマウントされます。

$ diskutil mount disk1s3
Volume Recovery on disk1s3 mounted

マウントされたフォルダにはUUIDらしい名前のフォルダが一つだけありました。その中を見てみると以下のようでした。（結果を編集して作業ファイルらしい細かいファイルは省略してあります。）

$ 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を動かすための一式が入ったディスクイメージファイルです。これを使って非常時の起動を行なえるようです。

Recoveryでできること

Cloverの起動画面からRecoveryボリュームで起動すると、以下の画面が現れます。Recovery起動中のスクリーンショットの撮り方がわからなかったので、写真です。見にくくてすみません。画面にはmacOSユーティリティが現れます。macOSをインストールするときに現れるお馴染みの画面です。ここから4つの機能を利用できます。

メニューバーにはユーティリティという項目があり、ここにはさらに3個の機能が用意されています。全部で7種類のツールを使えます。順番に見ていきます。

起動セキュリティユーティリティ

Hackintoshでは動きません。Appleのサポートサイトに機能の説明があります。Apple T2 セキュリティチップを搭載した Mac コンピュータでファームウェアパスワードによる保護、安全な起動、外部起動を実現するツールのようです。HackintoshだけでなくT2非搭載のMacでは動かない機能です。

ネットワークユーティリティ

ネットワークの状況がわかります。Ethernetが機能していてDHCPでアドレス取得しているようです。LANチップのAtheros Killer E2200が動いています。CloverがESPにあるAtherosE2200Ethernet.kextを読み込んでくれていて、それが機能していることが確認できます。

WiFiも動いています。こちらはパスワードを入れなくても接続していました。いつものパスワードがRecoveryから使用できているようです。画面右上にはWiFiアイコンが出ています。もしアクセスポイントの選択やパスワード入力が必要ならば、WiFiアイコンから行えます。

ターミナル

ターミナルさえ動けばなんでもできるので安心です。大体のボリュームがすでにマウントされていますので、/Volumesからどれでも操作できます。ESPの内容も、diskutilコマンドでマウントすれば編集・修正できます。ただ、ESPの内容に不具合があったらRecoveryの起動もできない可能性が高いので、ESPを変更する場面は少ないかもしれません。通常はmacOSボリュームやNVRAMなどが変更対象になるかと思います。

TimeMachineバックアップから復元

これを選択すると、接続されているドライブとネットワーク上TimeMachineサーバが表示されます。その中から、必要なタイムスタンプのバックアップを復元できます。Recoveryから起動しているので、macOSのシステムも復旧できます。

macOSを再インストール

おなじみのmacOSインストーラが起動してインストールできます。インストールのためにはネットワークに接続している必要があるらしいです。

ヘルプ情報をオンラインで取得

Safariが起動してヘルプのファイルが開きます。ネットワークが接続されていれば、外部にも接続できます。

ディスクユーティリティ

ディスクユーティリティ.appが起動します。BaseSystem.dmgがディスクとしてマウントされている様子がわかります。ディスクユーティリティ.appが動けばドライブのフォーマットもボリューム追加・初期化も思いのままです。ただし起動しているRecoveryボリュームは使用中ですので初期化できません。

macOSに不具合がある場合は、初期化されたボリュームに新規インストールすることが多かったかと思います。APFSになってボリュームが幾つでも作れて、容量も気にする必要がなくなりました。なので、macOSを新規インストールする場合に、既存のボリュームを消去せず、それを残したまま新規にボリュームを追加しても良いかと思います。

NVRAMのエミュレーション

Thu, 15 Nov 2018 19:20:52 +0900

NVRAMは不揮発性メモリの意味で、電源を落としても記憶が消えないメモリーのことです。マザーボード上にもありボタン電池などでバックアップされています。コンピュータ機器では、音量とか起動ディスクなどの情報が記憶されています。昔のMacではPRAM (パラメータRAM) と呼ばれていたこともありますが、NVRAMと同じものです。

本物のMacのハードウェアにも、ATXマザーボード上にも、どちらにもNVRAMはあります。しかしHackintoshでは、macOSからATXマザーボード上のNVRAMがうまく読めないこともあるようです。

そこで使われるのがEmuVariableUefi-64.efiです。Cloverのdrivers64UEFIフォルダに入れておくと、NVRAMのふり（エミュレーション）をしてくれます。NVRAMが覚えておくべき情報を、おそらくSSD/HDDなどの上で記憶しておいてくるのだと思います。マザーボード上のNVRAMがmacOSから利用できていればEmuVariableUefi-64.efiは不要です（あっても構わないです）。利用できていなければ、後述するNvidia Webドライバの利用などで必要になります。

NVRAMの内容を見る

NVRAMはterminalからnvramコマンドで読み書きできます。man nvramとすると使い方が表示されます。それを見ると：

nvram [ -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 "name
value" statements. The first space on each line is taken to be the separator
between "name" and "value". 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にパイプすれば、スクロールや検索もできて便利かもしれません。

nvram -xp | less

-xpオプションでわかるように、NVRAMにはキーとデータの対でデータが保存されています。Hackintoshで重要なキーの一つがNVIDIAのWebドライバを使うかどうかを記憶するキー、nvda_drvです。Webドライバが機能しているならば、以下のコマンド

nvram nvda_drv

で1%00というデータが返ってくるはずです。16進数で表すと0x3100というデータで、アスキーコードの1と、数値のゼロの2バイトです。C言語などの文字列は、文字列の最後を0x00で表しますので、1を表す文字列だと思われます。使用中ということでtrueを表す1になっていると思われます。このキーが無い場合はドライバが動かないため、低解像度表示になったり、画面表示されない可能性もあります。

NVRAMの機能を確認する

NVRAMが機能しているかどうかを確認するためには、適当なキー・データ対を作って電源を切っても保存されているかどうか調べれば良いです。例えば、

sudo nvram hogehoge=HelloWorld

とすると、hogehogeというなんの意味もないキーが作られて、それにHelloWorldという文字が割り当てられます。

nvram hogehoge

で確認することができます。ここで、マシンを再起動してもこのデータが残っていればNVRAMが働いていることになります。確認ができたら、以下のようにして消しておきます。

sudo nvram -d hogehoge

手元の3台のマシンで調べたところ、2台はNVRAMを保持してくれていました。hogehogeも残っていました。一方で、1台はNVRAMが消えてしまいました。hogehogeが消えるだけではなく、nvramコマンドが返してくれるキーの数も6個しかありません。

nvram -xp | grep key
<key>EFIBluetoothDelay</key>
<key>LocationServicesEnabled</key>
<key>SystemAudioVolume</key>
<key>SystemAudioVolumeDB</key>
<key>bluetoothActiveControllerInfo</key>
<key>bluetoothInternalControllerInfo</key>

NVRAMが消えてしまうマシンでも、EmuVariableUefi-64.efiを入れておけば、NVRAMが消えなくなります。

Mojaveの「インストーラリソースが見つかりません」問題

Fri, 12 Oct 2018 00:30:00 +0900

Mojaveへの移行は基本的に簡単で、Cloverやkext類が最新なら何の問題もありません。ただ、一部の環境で、macOSインストーラが止まってしまうトラブルがあるようです。手元のマシンでも2台が止まってしまいました。どういうわけか不明です。インストーラの不具合ではないかという説もあります。ただ、世の中ではあまり話題になっていなくて、Hackintoshで主に発生しているようです。

症状

macOS Mojaveインストール.appを起動して、インストールの準備は順調に進みます。その次、1回目の再起動が発生します。ここで、Boot macOS Install from xxxxというエントリーから再起動すればインストーラが立ち上がって問題なく次に進むはずです。

しかしこの時に、「インストーラリソースが見つかりません。」と言われてインストーラが止まってしまうことがあります。再起動しても、またここで止まります。

画面に表示されるメッセージは、日本語では、

コンピュータにmacOSをインストールできませんでした
インストーラリソースが見つかりません。
インストーラを終了してコンピュータを再起動してからやり直してください。

です。英語の環境でインストーラが立ち上がった場合には、

macOS could not be installed on your computer
The installer resources were not found.
Quit the installer to restart your computer and try again.

と表示されます。句読点は表示のままです。

発生する時は、上書きインストールでも、クリーンインストールでも発生します。ファイルシステムがAPFSでもHFS+でも発生します。

解決策

このメッセージで検索しても事例はあまり見つかりません。それでもtonymacx86にはいくつかの報告と解決事例がありました。それによると、

USBに接続したSSDにインストールしようとしたらこうなったので、内部ドライブにインストールしたら成功した
M.2に挿していたNVMeを外したらインストールできた

などとありました。どうも、ストレージを複数接続している場合に発生しやすいようです。とは言え、手元のHDDを多数搭載したマシンでは問題ありませんので、数の問題ではないようです。

いろいろ探していたら、まとめてあるページを発見しました。

‘macOS could not be installed on your computer’ error when installi…

書いてある内容をまとめると、以下になります。

SATAドライブだけの構成の場合は、インストール先以外の全てのドライブを取り外してインストールする
M.2 NVMe SSDにインストールしているときは、M.2を外して、SATAドライブにインストールしてからコピーする

どうもスッキリ解決というわけにはいかないようです。

やってみた

手元で問題を起こしている1台のマシンはM.2 NVMe SSDを搭載しています。M.2 SSDにも、SATAのドライブにもどちらにインストールしようとしても、このエラーメッセージで止まってしまいます。上記のサイトのガイドでは実質的にお手上げのケースです。

M.2 SSDを取り外すのが厄介でしたので、別のマシンで予備のSSDにインストールしました。32GBの2.5インチSSDを外付けUSBケースに入れて、MacBook Proに接続しました。インストール直後のMojaveの容量は14GB以下なので、16GBくらいのUSBメモリでも可能かもしれません。Mojaveインストーラを起動して、USB経由でインストールしました。

2度再起動して、国名を選択する設定画面で、ちょっと乱暴でしたが、電源を切ってSSDをとりはずしました。これを、問題起こしているマシンのUSBに接続します。

M.2 SSDはAPFSでしたのでボリューム作るのが簡単です。クリーンインストール用にボリューム作ります。先ほどのUSB SSDの内容を、新しく作ったボリュームにコピーすれば良いのです。

上記のサイトでは、ここで使うツールとしてCarbon Copy Cloner (CCC)を一例にあげています。CCCに問題がある訳ではありませんが、出来るだけ素朴なツールを使いたい主義なので、まずはDisk Utility.appの復元をためしました。内部では多分ddコマンドが動いていると推測してます。でもエラーで止まってしまいました。

そこでrsyncコマンドをつかってみました。上手くいきました。/Volumesに、コピー元がsource 、コピー先がtargetとマウントされている場合、以下のコマンドでコピー出来ます。

sudo rsync -av /Volumes/source/ /Volumes/target/

次に、M.2 SSDのこの新ボリュームから起動させたところ、インストールの続きが始まり、無事完了しました。

手元でインストーラが止まっているもう一台のマシンにはmSATA SSDとSATAのHDDが接続されています。前述のサイトによると、こちらは使わないドライブを外すだけで良いようです。~~そのうち試して報告します。~~実際にやってみました。HDDを取り外して起動させたところ、このメッセージは出なくなり、無事インストールできました。

Mojaveにアップデート

Sat, 29 Sep 2018 11:32:52 +0900

火曜日にmacOS Mojaveが公開されました。Hackintoshをアップデートする時間がなかなか取れなかったのですが、ようやく作業できました。結論としては、ベータ版で確認されていた通りで、今回のアップデートには難しいところは全くありません。

上書きアップデート編

macOSアップデートの一番お手軽な方法は、App Storeからダウンロードして、そのままアップデートする方法です。環境設定も、インストールしたアプリケーションも、ユーザ設定もデータも全部そのまま引き継げますので簡単です。今回のアップデートは、OSの根本に大きな変化が少ないので、上書きアップデートができそうです。今回は、High Sierraが動いている初代NUC, DC3217IYEで試してみました。Ivy Bridgeマシンなので、なんとかギリギリでMojaveに対応しています。

NUCで作る超小型macOSマシン

Clover, KEXTをアップデートしておく

macOSのアップデートが簡単になった舞台裏では、Hackintosh開発者の皆さんの努力があります。ベータ版を元に不具合検証して、多数のアップデートが施されています。感謝です。なのでmacOSアップデート前に、最新版にアップデートしておきましょう。

現時点でのCloverの最新版リビジョンは4674です。古いようでしたらアップデートしておきます。

Kext類のアップデートにはKext Updater.appが便利です。起動すると、Kext Updaterそのものがアップデートされることもあります。最新版kextに関するデータベースが更新されるのだと思いますので、これもやっておきます。

アップデートしたら、もう一度Kext Updaterで最新になっていることを確認しても良いです。ただ、再起動を行わないと、新しいClover, Kextが機能しませんので、再起動してから確認します。

KextをMojaveの場所に複製する

もしKext類をEFI/CLOVER/kexts/10.13/に入れているようでしたら、同じ内容をEFI/CLOVER/kexts/10.14/にもコピーしておきます。これを忘れるとMojaveが起動しません。当たり前のことですがうっかり忘れて慌てた経験が複数回あります。

そういう可能性をなくすために、EFI/CLOVER/kexts/Other/にKextを入れておくのも良いかと思います。CloverはOtherの場所のkextを読み込んだ後で、10.14などの場所のkext類を読み込みます。同じkextがOtherとバージョン番号のフォルダの両方に存在しても、片方しか動かないので問題ありませんが、無駄なのでどちらか片方だけに入れておくのが良いです。

App StoreからMojaveをダウンロードする

App Storeに行くと、今ならバナー広告でmacOS Mojaveが絶賛宣伝中になっている思います。ダウンロードボタンを押してダウンロードします。6.03GBあります。

ダウンロードが終了すると、自動的に起動してインストーラが起動します。これは一旦終了して（しなくても良いですが）、アプリケーションフォルダを見てください。macOS Mojaveインストール.appというアプリケーションがありますので、これをどこかに複製して保存しておきます。バックアップしておかないと、インストール後に消えてしまうことがあります。せっかく時間をかけてダウンロードしたのですから、バックアップしておきましょう。

インストーラを起動する

macOS Mojaveインストール.appを起動すると以下のウィンドウが現れます。

「続ける」をクリックして、あとは指示に従ってどんどんインストールして行くだけです。

インストール途中で再起動する場面があります。この時、「Boot macOS Install from xxxx」という項目が作られていて、それから起動するようになっているはずです。xxxxの部分は、アップデートしようとしているパーティションの名前です。

以上の結果、無事アップデートできました。App Storeからのダウンロードによる上書きアップデートで問題なくMojaveに移行できることが確認できました。

クリーンインストール編

クリーンインストールも試してみました。問題ありません。こちらはタワー型デスクトップのHackintoshで試しました。HDDを多数搭載していて、予備のHDDにもmacOSとCloverがインストールしてあります。

作業の前に、メインのドライブと予備のドライブのESPに入っているCloverとkextを最新版にしておきます。メインのドライブのESPだけを使って以下の作業を行うことは可能ですが、将来、サブのESPを使うことも考えて、ついでにアップデートしておきました。

次に、予備のmacOSで起動して、メインで使っているシステムの入ったパーティションをAPFSでフォーマットしてしまいます。そしてmacOS Mojaveインストール.appを起動し、空になったパーティションにインストールしました。この場合も、インストール途中で1回再起動しますので、Boot macOS Install from …の項目から再起動します。

あと12日！Mojaveの受け入れ準備

Thu, 13 Sep 2018 21:00:00 +0900

Mojaveは9月25日に登場

今朝未明のキーノートは、いつもの秋のイベント同様にiPhoneメインで、ささやかに期待された新型Macの情報は皆無で寂しい限りです。ただ最後の3分を切ったところで、macOS Mojave配布日が発表されました。日本時間で9月25日だそうです。あと12日ですね。それまでのあなたのHackintoshに新バージョンをお迎えする準備をしておきましょう。（去年の状況と同じですね😀あと13日！High Sierraのお迎え準備）

以下はMojaveのベータ版での情報ですが正式版Mojaveでも同様と思われます。

High Sierraからのアップデートは簡単

今現在HackintoshをHigh Sierraで動かしているならアップデートは簡単です。Cloverとkext類を最新にしておけばokです。High Sierraへの移行では、APFS起動に伴いファームウェアアップデートされ、多少の対応が必要でしたが、今回はそれも不要です。

なお、Kext Updater.appを使うと、使用中のkextの最新版をチェックして、ダウンロードしてくれるので楽です。

Mojave移行の注意

Cloverなどを最新版にしておく以外にほとんど問題はないはずです。それでもありえそうな注意事項を列挙して見ます。

kextの格納場所

kextをEFI/CLOVER/kexts/10.13に入れている人は、10.14を新たに作って、全部のkextをコピーしておきます。もしくは、Otherフォルダにコピーしておいても良いです。10.14で起動する場合は、Otherの内容が先に読み込まれ、次に10.14フォルダが読み込まれます。10.13のフォルダの内容は無視されてしまいます。当たり前のことですが、うっかりして失敗した経験が何度かあります。

APFS

High SierraのインストールではAPFSを使わない選択肢がありました。でもMojaveからは必須になったようです。システムドライブをまだHFS+で運用している人は、対応が必要かと思います。ファイルシステムの移行は大事なので、APFS移行でも問題が発生するのではという懸念がありました。しかし、APFS移行問題は、実機でもHackintoshでもほとんど報告されていません。円滑に移行できていると思われます。

High Sierraが出た頃は、macOSからapfs.efiをESPにコピーしていました。その後公開されたApfsDriverLoader-64.efiを入れておけば、macOSに含まれる最新のapfs.efiを使ってくれるようになります。

Clover 4558で登場したApfsDriverLoader.efi

Mojave非対応Mac

公式サイトの情報によるとMojave対応機種は以下です。

MacBook (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では、起動時に禁止マークが出て止まってしまいます。

これを避けるためには、Cloverのブートオプションに

-no_compat_check

を追加します。これで機種チェックを回避できます。例えばconfig.plistに以下のように設定します。

<key>Boot</key>
  <dict>
    <key>Arguments</key>
    <string>-v -no_compat_check</string>

少なくともベータ版では、これでMojaveが起動しました。

Mojave非対応グラフィックス

MojaveからはMetal対応グラフィックスが必須になりました。ただ、今のところは、Metalの機能が無いと全く動かないという状態ではなく、Metal非対応のドライバをmacOSから除外したという状態のようです。なので、古いmacOSからMojaveで削除されたドライバを持って来ればなんとか動くようです。ただ、Metalの機能を使っている部分もあるので、多少の不具合（ぼかしが機能しないなど）はあるようです。

古いグラフィックスドライバを入れたり、また機種名を誤魔化すためのパッチを当てるツールも公開されています。実機向けのツールですが、Hackintoshでも使えると思います。

macOS Mojave Patcher

古いハードウェアがMojaveに対応していないのは実機でも同様のことですので、Hackintoshもハードウェアのアップデートを検討するのが良いと思います。自作機ならアップデートは簡単ですから。

Mojaveへの移行方法

これは実機でも同じですが、新しいOSバージョンへ移行するには、大胆または慎重などの移行方針を選べます。バニラなインストール方法でHackintoshしているなら、実機とほぼ同様の方法でアップデート可能です。

/posts/131/

主ドライブを上書きアップデートする

今動いているHigh SierraからMojaveのアップデータを起動する方法です。実機と同様に、App Storeからダウンロードしたアップデータをそのまま起動すれば、問題なくアップデートされるはずです。Appleお勧めの一番簡単な方法です。ただ、上記で説明したCloverとkext類のアップデートは済ませておきましょう。

別ドライブにインストールする

別ドライブにクリーンインストールする方法です。新OSの動作を確認して、問題がなければ移行しようという慎重な人向けです。自作HackintoshならSSDなどの追加は簡単だと思います。macOSだけならSSDは30GBもあれば十分ですが、現行製品だと120GBか256GBあたりがビット単価からしてお得感があります。直接内蔵しなくても、外付けケースに入れてUSB接続した別ドライブでもokです。

方法は簡単で、今動いているHigh Sierraから別ドライブをフォーマットして、Mojaveのアップデータを起動してインストールすれば良いです。クリーンインストールするために、単体で起動できるUSBメモリを作る方法もありますが、すでに起動できるドライブがあるならその必要はないと思います。インストールの途中で古い環境からの移行をするオプションが現れます。これを使えば、High Sierraでの設定などを移行することも簡単です。

別ドライブにmacOSをインストールしたら、そのドライブのESPにCloverとkext類も入れておきましょう。それで起動できれば、Hackintosh設定で失敗して主ドライブが起動しない時のバックアップになります。

主ドライブにクリーンインストールする

単体で起動できるUSBメモリを作った場合は、主ドライブにクリーンインストールすることもできるでしょう。または、「別ドライブにインストール」した後であれば、それを起動して、主ドライブにクリーンインストールすることもできます。

ユーザデータまでフォーマットすると復帰が大変ですが、/Users以下を別ドライブや別パーティションに入れてあれば、システム部分をフォーマットしてクリーンインストールしてもそれほど手間はかからないと思います。

ESPをマウントしてついでにバックアップする

Sat, 08 Sep 2018 14:23:46 +0900

時々は行ってやらないといけないHackintoshのメンテナンスでは、ESPをマウントする必要があります。またESPのバックアップがあれば、メンテナンスで失敗しても復帰できます。ということで、メンテナンスでESPをマウントするときに、同時にバックアップも行えば、万一メンテナンスで失敗しても、稼働していた最後のESPを取り戻せると考えました。

今までの関連記事

振り返ってみると、ESPをマウントする方法と、ESPをバックアップする方法を色々書いてきました。10.13.6でdiskutil mountコマンドにパスワードが必要になったので、使えなくなった方法もあります。

ESPをマウントするためのシェルスクリプト

ESPを自動バックアップする

10.13.6でESPをマウントする権限が変更される

単にマウントしてバックアップする

今回は、シンプルにマウントしてバックアップするスクリプトを考えました。過去に紹介したスクリプトを足し合わせた内容です。現在はこのスクリプトで、ESPのマウントもバックアップもどちらも行っています。ESPに手を加える直前にバックアップすることになるので、合理的かと思います。

#!/bin/sh
ESPUUID=00000000-0000-0000-0000-000000000000
BACKUP=~/Documents/OSX86/_currentESP/
sudo diskutil mount $ESPUUID
MP=`diskutil info $ESPUUID | grep "Mount Point"`
MP3=`echo $MP |  awk '{print $3}'`
MP4=`echo $MP |  awk '{print $4}'`

if [ -n "$MP4" ]; then
 cd $MP3" "$MP4
 rsync -av --delete $MP3" "$MP4"/" $BACKUP
else
 cd $MP3
 rsync -av --delete $MP3"/" $BACKUP
fi

date > timestamp.txt
cd EFI/CLOVER

過去記事の重複になりますが、各ステップを説明します。

最初に定義した変数、ESPUUIDはESPのUUIDです。例えばESPがdisk0s1に割り当てられた場合、
```
diskutil info disk0s1
```
とすると色々な情報が出てきます。この中に
```
Disk / Partition UUID:  00000000-0000-0000-0000-000000000000
```
というように表示されているのが、ESPのUUIDです。
次に定義した変数、BACKUPはESPの内容をバックアップしたい場所です。最後に/をつけます。これはのちに実行するrsyncコマンドの仕様上、重要です。バックアップ場所としては、iCloudやDropboxなどでクラウドと同期しているディレクトリを指定すると良いと思います。そうしておけば、万一マシンが起動しなくなっても、他のマシンから内容を取り寄せることができます。
diskutil mountの行で、ESPUUIDで指定したESPをマウントします。10.13.6からsuper user権限が必要になったのでsuコマンドをつけています。実行するとパスワードを求められるのでタイプします。
diskutil infoの行で、マウントポイントを得ています。このコマンドでマウントポイントが
```
Mount Point: /Volumes/EFI
```
のように表示されます。この行を取得しています。
次のawkコマンドとif文が続くところで、diskutil infoコマンドで得られる行から、マウントポイントだけを抽出しています。ややこしいですが、マウントポイントは、最初は
```
/Volumes/EFI
```
になるのですが、2個目以降は
```
/Volumes/EFI 1
```
のように、空白＋数字になります。どっちでも対応できるようにif文で対応しています。
cd $MP3″ “$MP4もしくはcd $MP3でESPの場所にカレントディレクトリを移動しています。シェルスクリプトの実行で移動する場合は、このスクリプトに例えばESPBackup.shと名前をつけた場合、
```
. ESPBackup.sh
```
として実行します。.の後には空白を入れます。
rsyncコマンドで、$BACKUPで指定したディレクトリにバックアップしています。更新のあったファイルだけが置き換わります。
dateコマンドでバックアップを取ったタイムスタンプを入れてみました。なくても良いですが、最後にバックアップした時刻がわかるので便利かと思います。
おまけ。本当の最後にCLOVERディレクトリに移動しています。引き続き作業するのに便利かと思いました。

ワンクリックで最新kextに〜Kext Updater.app (Ver. 2)

Sat, 21 Jul 2018 00:30:00 +0900

Kext Updater

古いバージョンの記事です。新しいバージョンに関しては以下をご覧ください。

Boot macOS

Hackintoshで使っているClover, EFIドライバ、kext類は、最新版を使うのが良いです。色々なバグが直されていて、安定しています。また常に最新にしておけば、macOSのバージョンアップにも対応できます。Mojaveに備えていつも最新状態にしておきたいものです。ただ、開発者の方々のページを巡回して最新版をチェックするのも大変です。

Hackintoshで使用中のkext類最新版をチェックして、新バージョンがあった場合にダウンロードしてくれる便利なツールがあります。ドイツのHackintoshフォーラムの人たちが作ってくれているKext Updaterです。以下でソースが公開されています。

コンパイル済みの最新版はこちらからダウンロードできます。

早速起動してみます。ラジオボタンがいくつかありますが、メインの機能は「Check for Updates」のボタンです。これを選択して、「Start」ボタンを押します。すると左のメッセージエリアに以下のような表示が出ます。

使用されているHackintoshのkextを全部調べ上げてくれて、それが最新版であるかどうか判断してくれます。ここではNvidiaGraphicsFixup.kextが最新版より一つ前のバージョンでした。そこで、これが自動的にダウンロードされて、デフォルトでは、デスクトップのKext-Updatesという名前のフォルダに入ります。このフォルダは「Open」ボタンで開けられます。そこで、必要ならば「Mount EFI」ボタンを押してESPをマウントして、ダウンロードした最新版と入れ替えます。

他にもラジオボタンから

基本的なkextをKext-Updatesフォルダにダウンロードする（右のメニューで種類を選べます）
一つのkextをダウンロードする（右のメニューでkextを選べます）
NVIDIA Webドライバをダウンロードする（右のメニューでバージョンを選べます）
Clover最新版をダウンロードする（Nightly Buildにチェックを入れると非公開最新版をダウンロードできます）

このツールにより、最新版をチェックして差し替える作業が大幅に楽になります。

Intel UHD Graphics 630用純正グラフィックスドライバ

Wed, 18 Jul 2018 23:48:53 +0900

先日発売された新MacBook Proには、Coffee Lake-S CPUがいよいよ搭載されました。新製品に搭載された5種類のCPUと内蔵グラフィックスは以下のとおりです。

Intel 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が安定して、そのグラフィックス性能を引き出せると思われます。

新機種で追加されたハードウェアのドライバを一般のmacOSユーザが入手できる時期は、通常、新機種が出た次のmacOSアップデートになります。今回の新MacBook Pro発表は、macOS 10.13.6が配布された直後なので、アップデートのタイミングを考えると、9月のMojaveでようやく入手できるかと思われます。なのでしばらくは入手不可能なのではと考えていました。ところが5chでこんな情報を教えてもらいました。tonymacx86のスレッドです。

www.tonymacx86.com

リカバリーパーティションで起動して入手する

新MacBook Proに搭載されているのは、App StoreからアップデートできるmacOSと同じ10.13.6です。しかし、App Storeで配布されているのはBuild 17G65なのに対して、新製品にインストールされているBuildは17G2112だそうです。そして、17G2112にしかIntel UHD Graphics 630のドライバは含まれていないようです。

ところが以下の手順で、最新Buildを入手できるそうです。

SMBIOSの設定で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だそうです。

Mojaveまで待てば良いけど

とはいえ9月に出ると思われるMojaveまで待てば、グラフィックスドライバは苦労をしなくても入手できます。また、Mojave Dev Beta 4から、このドライバが含まれているそうです。なので、本日出たMojave Public Beata 3にも、新ドライバが含まれているはずです。Mojaveは安定しているので、さっさとBetaに移行しても良いかもしれません。ただ、Coffee Lake-S自作Hackintoshをしている人が、High Sierraを使いたいと希望する場合には、この方法が良いかと思います。

Cloverで使うEFIドライバ

Sun, 15 Jul 2018 00:13:48 +0900

（古い情報です。最新情報はこちらをご覧ください。）

CLOVER 4988 でEFIドライバ関連が変更されました

—————

最近のClover*1でEFIドライバ類が色々と変更されている様です。気づいたところをメモしておきます。

64bit移行のためと思われる名称変更

EFIドライバフォルダ名

だいぶまえにdrivers32というフォルダがなくなってdrivers64だけになっていたと思うのですが、最近ではdrivers64UEFIになったようです。新規にインストールするとこれだけになります。drivers64は空になる事もあります。drivers64は手作業で消してしまっても良いようです。

また、Cloverのインストーラは、現在インストールされているドライバを見てチェックマークを更新しているわけでは無いようです。前回、インストールしたログを見て、その記録から更新するドライバを選んでいます。なので、手作業でインストールしたドライバは反映されていません。時々は、インストールされたドライバと照らし合わせて、更新リストに入っているかどうか確認した方が良いかと思います。

末尾が-64のドライバ

最近、全てのドライバのファイル名末尾に-64が付きました。64bitであることを明白にするためなのかと思います。同名のドライバで、末尾が-64で無いバージョンのドライバがESPに入っていると、アップデートで置き換えられない（両方が残ってしまう）ことがありますので、手作業で削除しておきましょう。

（更新：Clover 4988から64の名前が外されました。全て64ビットのみになったためと思われます。2019/7/13）

デフォルトのEFIドライバ

デフォルトでインストールされるEFIドライバは、インストーラで表示されなかったと思うのですが、最近では全部表示されるようになっています。以下の８個がデフォルトでインストールされる設定になっているようです。

デフォルトで選択されているので重要なドライバだとは思います。そのうち調べて、機能をメモしていきたいと思います。

一部はこちらを参考にしました。

github.com

AppleImageCodec/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個のみということかと思います。

オプションのドライバ

次に、デフォルトでは選択されていないドライバをチェックしていきます。

メモリ確保のドライバ

こちらの説明で、

Cloverインストーラの設定

以下のドライバの役割と、推奨順番を説明しました。推奨順番はこの順番です。

AptioMemoryFix.efi
OsxAptioFix3Drv-64.efi
OsxAptioFix2Drv-64.efi
OsxAptioFixDrv-64.efi
OsxLowMemFixDrv-64.efi

用意されているドライバが、最近では以下に変わっている様です。

AptioMemoryFix-64.efi
OsxAptioFix2Drv-64.efi
OsxAptioFixDrv-64.efi
OsxLowMemFixDrv-64.efi

~~AptioMemoryFixに-64が付いて、3Drvは無くなったようです。理由は不明です。今後、アップデートされないので3Drvは使わない方が良いかもしれません。~~（更新：最新バージョンでは3Drvが復活しています。何れにしても最新のCloverインストーラの選択肢に従うのが良いです。）また、上記のいずれもダメな場合は、 OsxAptioFix2Drv-free2000.efi を試すと良いです。これは最強な感じです。

これらのドライバが働かない場合、Clover選択画面の直後で起動が停止します。-vオプションで、メモリがallocateできないという様なメッセージが出ていたら、このドライバを差し替えてみてください。メモリのallocateはいろんな条件で失敗する様です。kextを入れ替える事で失敗が発生する事もあります。また、大抵は成功するものの、数回に１度ランダムにallocate失敗する事もあります。

ApfsDriverLoader.efi

前に紹介しましたように、apfs.efiをmacOS本体からロードしてくれるドライバがr4558から登場しました。これがあればapfs.efiを本体から持ってくる必要はありません。ただ、環境によっては失敗する事も稀にあるようですので、apfs.efiを手作業でコピーしておいた方が良い事もあります。今後改良されるのだとは思います。

Clover 4558で登場したApfsDriverLoader.efi

その他のドライバ

ApfsDriverLoader-64もそうですが、最近のインストーラで選択できるドライバが増えている気がします。よくわからないファイルもありますが、今後、検索して機能が判明したらまた紹介していきたいと思います。

AptioMemoryFix / 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個です。

ApfsDriverLoader-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個は不要のようです。

AppleImageCodec-64.efi
AppleKeyAggregator-64.efi
AppleUITheme-64.efi
DataHubDxe-64.efi
FirmwareVolume-64.efi

FileVault 2は使っていませんので、これらを除いて起動を試しました。なんの問題もなく起動しました。使っているのは以下の5個です。

ApfsDriverLoader-64.efi
AptioMemoryFix-64.efi
FSInject-64.efi
SMCHelper-64.efi
VBoxHfs-64.efi

かなりシンプルになりました。

*1:執筆時点のv2.4k r4586より少し前くらい

Sandy Bridge搭載Thinkpad X220でMojave

Thu, 28 Jun 2018 22:44:01 +0900

Sandy Bridge CPUとIntel HD Graphics 3000を搭載したThinkpad X220でmacOS Mojave Public Betaが動きました。機種チェックをさせないようにブートオプション設定して、グラフィックスドライバーを入れれば動きます。

前回のあらすじ

Thinkpad X220にHigh Sierraをインストールする記事を書きました。

/posts/53/

Thinkpad X220は、IBMが打ちやすさにこだわって設計したキーボードを備えた最後のモデルです。Sandy Bridge世代の製品で、MacintoshではMacBookPro8,1や、Macmini5,1に相当します。今回のMojaveでこれらは全てサポート外になりました。Thinkpadらしさを留めたX220が、現行macOSで動かなくなるのは残念なことでした。

Mojaveで動かない理由

Mojaveが非対応モデルで動かない理由は次の2点です。一つは、Mojaveの起動時にマシンのBoard-IDをチェックしていることです。チェックの結果、Mojave非対応モデルでは起動を中断します。この結果、画面に禁止マークが出て止まってしまいます。

もう一つは、グラフィックスドライバーが提供されていない事です。Intel HD Graphics 3000のドライバーが、Mojave から削除されてしまったのです。

(1) 機種チェックをさせないようにする

Cloverを-vオプション付けて起動すると、禁止マークの裏で表示されているエラーメッセージがわかります。

この番号はconfig.plistのSMBIOSセクションに書き込んだ Board-IDでした。MacBookPro8,1 (Early/Late 2011) が内蔵しているボードのIDです。これをチェックして、Mojave対応モデルかどうかを調べているようです。

機種チェックを行わないようにするには、Cloverのブートオプションに

-no_compat_check

を追加します。5chで教えてもらいました。例えばconfig.plistに以下のように設定します。

<key>Boot</key>
  <dict>
    <key>Arguments</key>
    <string>-v -no_compat_check</string>

これでMojaveが一応起動するようになります。

(2) グラフィックスドライバを入れる

機種チェックを回避すれば一応は起動します。しかし解像度は1024×768画素と低解像度で、解像度を上げることはできません。画面はチラつき、画面描画も遅いです。とても実用にはならない状態です。これはMojaveからIntel HD Graphics 3000のドライバが削除されてしまったからです。なんてことをするんだと思いますが、このモデルがOSの動作対象外になったので仕方ないところです。

でも嬉しいことに、以前のバージョンからドライバを持って来れば動くという情報がtonymacx86にありました。

www.tonymacx86.com

どういうわけか一世代前のSierraのドライバが良いようです。tonymacx86でこの方法を紹介してくれた人の話では、最初は直近世代のHigh Sierraのドライバを試したところ、ブラックスクリーンが出て動作しなかったそうです。そこで、もう一世代前のSierraを試したら成功したとのことでした。ということで、Sierra から、

AppleIntelHD3000Graphics.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を入れてパーミッションやキャッシュを設定するのは手作業でも可能ですが、今回はこのツールを使いました。

また、追加したkextを有効にするSIP設定をします。config.plistを以下のように設定します。通常、野良kextを/S/L/Eで使うには0x03にするのですが、今回はApple純正のkextなので0x02でも良いようです。0x01は信頼できないkextを許可する、0x02はファイルシステムへの制限を無効にする設定のようです。できるだけSIPの機能を生かすためには、最小限の0x02が良いと思います。

<key>RtVariables</key>
        <dict>
        <key>CsrActiveConfig</key>
             <string>0x02</string>
        </dict>

Mojaveが動いた

この結果、フル解像度でMojaveが動くようになりました。グラフィックスがちゃんと動いているかどうかを確認するには、Maps.appで地図が正しく表示されるかどうか、SafariでYoutube動画を再生できるかどうか、などを確認すると良いそうです。

「このMacについて」を見ると、機種はEarly 2011のMacBook Proになっています。またグラフィックスもIntel HD Graphics 3000になっています。古いドライバが仕事をしていることがわかります。Mojaveでは本来起動もしない仕様なマシンであることが面白いと思います。

Metalをサポートした機種のみがMojave対応になりましたが、Mojaveを動かすためにMetalは必ずしも必要ではないようです。今回Mojaveが非対応になった実機のMacでも、同じような手法でMojaveを動かすことが可能だと思われます。

Mojaveを動かすもう一つの方法

Mojaveのサポートから外された古いMacでMojaveを動かすためのパッチが公開されています。実機を対象としたパッチですが、Hackintosh でも有効と思われます。

macOS Mojave Patcher

このパッケージの中を見てみると、Intel HD Graphics 3000のドライバーなどが含まれています。おそらく、上で紹介した手法と同様に、古いmacOSから持ってきたドライバーを利用しているのでしょう。また、macOSにパッチを当てることで機種チェックを回避していると思われます。

macOS Mojave Public Beta版を試す

Wed, 27 Jun 2018 22:43:49 +0900

いよいよMojaveのPublic Betaが公開されました。そこで早速Hackintoshで動かしてみました。去年のHigh SierraではAPFSが登場しました。でも今回のアップデートでOSの根本が大きく変化している箇所はあまり多くないようです。なので、すでにHigh Sierraが動いているHackintoshでしたらMojaveを動かすのは簡単です。10.13.4から10.13.5のようなマイナーアップデートと変わりません。(とは言え、High Sierra の時もapfs.efiを追加するくらいでした。)

Public Betaを入手する

MojaveのPublic Betaを入手するには、Appleのサイト

Apple Beta Software Program

で、macOSPublicBetaAccessUtility.pkgを入手します。Apple IDでのログインが必要です。

これをダブルクリックすると、App StoreからInstall macOS Mojave Beta.appをダウンロードできるようになります。

macOSPublicBetaAccessUtility.pkgがインストールされたマシンでないと、ダウンロードできません。しかし、一旦App StoreからダウンロードしたInstall macOS Mojave Beta.appは、どのマシンでも使用できます。

インストールの手順は、こちらにも詳しく紹介されています。

www.itmedia.co.jp

Mojaveを導入・起動

こうして入手したInstall macOS Mojave Beta.appさえあれば、Mojaveの起動ディスクを作成できます。また、High Sierraに手を加えないVanillaなHackintoshならば、その起動用ESPを使って、Mojaveを起動できます。

そこで、以下の手順でMojave起動ドライブを作成して、Mojaveを起動しました。ここではHackintosh上でMojaveをSSDにインストールしましたが、もちろん実機のMacで行っても良いです。

現在の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をインストールします。
インストール途中で何回か再起動（たぶん２回）します。本物のMacの場合は自動で正しく再起動します。Hackintoshの場合は、再起動ボリュームが正しく引き継がれないことがあります。Cloverの選択画面で「Boot macOS Install from xxxx」という項目が選択されている事を確認してください。
Cloverの選択画面が「Boot macOS from xxxx」になったらインストールは終わりです。これを選択すれば、ユーザ設定などの画面になり、Mojaveを使えます。せっかくですからダークモードを試してみましょう。

Metal非対応では導入できない？

以上は、Apple社がmacOS純正ドライバーを提供しているRadeon RX 580搭載Hackintoshで作業しました。メーカー配布のドライバーがまだMojaveに対応していないNVIDIA GeForce搭載のHackintoshでインストール作業をしたところ、インストール途中でinstaller resourcesが足りないと言われてしまいました。なんのことか不明ですが、Metal対応のRadeonでは問題なかったことから、Metalに対応していないマシンではインストールできないという意味かと思われます。

MojaveドライブにCloverを入れる

これでMojaveが起動すれば、このドライブにClover類を入れて単体で起動できるようにするのは簡単です。以下の手順でESPを複製すれば良いです。

Mojaveを入れたドライブにCloverをインストールします。（このステップは飛ばしても良いと思います）
High Sierraが動いているドライブのESPの内容を、MojaveをインストールしたドライブのESPと同一にします。上のステップでCloverを入れているなら、全部コピーしなくても、CLOVERディレクトリの一部だけを差し替えればokです。kextをバージョンごとのフォルダに入れている場合は、10.14というフォルダを作って入れるようにします。

色々なマシンでMojaveを起動

ここで作成したMojaveの起動SSDを手元のマシンで試してみました。HackintoshではHigh Sierraの起動で使用しているESPを使っての起動を行いました。

AMD Radeon RX580搭載のHackintosh: 上のステップでMojaveインストールに使用したマシンです。Metal対応のドライバがmacOSに含まれているので、問題なく起動し、全てが快適に動作します。過渡期はmacOS標準サポートされているRadeon RX570/580は安心ですね。
NUC DC3217IYE Hackintosh: Intelの初代Core i3 NUCです。NUCの初代はIvy Bridgeなので、実はNUC iGPUの多くがMetal対応していて、その結果、Mojave対応です。これも全く問題なく起動しました。
Nvidia GPU搭載Hackintosh: NVIDIAが配布するドライバー (Web driver) がMojaveに未対応なので、表示解像度が低いままで表示がちらつくものの、とりあえずは起動しました。Web driverが対応すればMetalが動いてMojaveが使えると思われます。まず大丈夫と思いますが、実際にドライバが出てみないとわからないですね。
ThinkPad X220 Hackintosh: 非対応CPUであるSandy Bridge搭載ThinkPadです。禁止マークが出て起動しません。
-vオプションでエラーメッセージを見ると以下のようです。起動しない理由として表示される番号、Mac-94245B3640C91C81 は、MacBook Pro Late 2011 13インチモデルのBoard-IDでした。config.plistのSMBIOSセクションで指定したIDです。試しにこれを2012年モデルのIDである Mac-6F01561E16C75D06に変えてみたところ起動はしました。ただ解像度は低くちらつきます。Metal非対応のグラフィックスにはmacOS標準ドライバが提供されなくなったのかと思われます。実質的にMojaveは使えないです。
実際に/System/Library/Extensionsを10.13.5と比較すると、Intel HD Graphics 3000に関係すると思われる名前のファイル（AppleIntelHD3000Graphics.kext, AppleIntelHD3000GraphicsGA.plugin, AppleIntelHD3000GraphicsGLDriver.bundle, AppleIntelHD3000GraphicsVADriver.bundle）がごっそりと消えています。
**追記：**動きました

/posts/47/
古いMacBook: Mojave非対応のLate 2009 MacBookに接続して起動を試みました。Hackintoshではなく本物のMacです。X220の時と同様に、禁止マークが出て起動しません。Command-vで起動すると、やはり次のようなメッセージが出ていました。Mac-F22C8AC8はこの機種のBoard-IDです。このような古いMacもBoard-IDを誤魔化す手法でなんとか起動できるのかもしれません。ただその場合も、グラフィックスは低解像度でしか動かないと思われます。

Clover 4558で登場したApfsDriverLoader.efi

Tue, 19 Jun 2018 20:25:48 +0900

ApfsDriverLoader.efi

Clover 4558が先ほどアップデートされましたが、これに新しいefiドライバであるApfsDriverLoader.efiが追加されました。これをdrivers64UEFIに入れておくと、DiskIOプロトコルを利用してAPFSコンテナからapfs.efiをロードしてくれるものらしいです。5chで教えてもらいました。

www.insanelymac.com

ブートの手順とそれに必要なファイル類について、こちらで説明しました。ブートボリュームがAPFSの場合は、ブートストラップローダを読み込むためにapfs.efiが必要でした。しかし、ApfsDriverLoader.efiを使えば、手作業でapfs.efiを用意する必要がなくなりました。過去の記事にも加筆しておきました。

Hackintoshの長靴 (ブート)

試しに、EFI/CLOVER/drivers64UEFIからapfs.efiを削除して、代わりにApfsDriverLoader.efiを入れて起動してみたところ、Cloverのブート選択画面で無事APFSディレクトリが表示されました。今までは、バージョンアップでapfs.efiが更新されると、そのたびに念のために新しくなった /usr/standalone/i386/apfs.efi をESPにコピーしていました。ブート時に自動で取り寄せてくれるのでこの作業が不要になったようです。

Thinkpad X220でHigh Sierra (2)準備・到着・起動

Sat, 09 Jun 2018 02:00:00 +0900

今回は、macOSとCloverをインストールしたSSD/HDD/USBメモリを作り、これでX220を起動させます。

（前回の進捗：Thinkpad X220にmacOSをインストールしようと思い立ち、機種選定して中古を発注しました。）

X220が到着するまで時間がありますので、お迎えの準備をしておきたいところです。モバイルのHackintoshを作るのは久しぶりなので、macOSが立ち上がるのかどうか心配です。とりあえずでも起動すれば、あとの最適化作業の目処が立ちます。ということで、X220が到着したらhackintosh化が可能なことをすぐに確認できるよう、接続すればmacOSが起動するドライブを作っておきます。

今回の試みでお世話になるのはこちらのサイトです。非常に丁寧に手順が説明されています。内容のアップデートも行われていてHigh Sierraの最新版に対応しています。下のリンクはHigh Sierra対応のページです。

x220.mcdonnelltech.com

また、必要なconfig.plist, kext類が一式揃えてあります。これがあれば、起動するドライブを作成しておくことは簡単です。このサイトで用意されている一式は、以下のリンク先にあります。これを入手しておきます。

http://www.mcdonnelltech.com/X220_macOS_10.13_Utility_and_Kext_pack_04.24.2019.zip

これをダウンロードして解凍すると、EFIというフォルダがあります。その中に、BOOTとCLOVERというフォルダがあります。これをHigh Sierraを起動させたいドライブのESPに入れれば良いのです。

macOS起動ドライブを作る

そこで、High Sierraの最新版 (執筆時点で10.13.5) が起動するドライブを作ります。macOSは、20GBくらいあればインストール可能です。それくらいの容量のUSBメモリでもokです。X220は、外部から割と簡単に（ねじ５本で）アクセスできる2.5インチドライブベイがあります。なので2.5インチのHDDまたはSDDを用意して、これに一式をインストールしても良いです。手元には、古い古い少容量の2.5インチSSDがあったので、それを使いました。これをSATAやUSBでmacOSが動いているマシンに接続し、macOSをインストールします。

インストール終了したら、動いているマシンで起動することを確認します。ここでユーザの設定などを行ってしまっても良いです。またもしインストールしたHigh Sierraが最新版ではなかったら、ここでコンボアップデートを当てても良いです。

ESPにファイルを入れる

macOS最新版をインストールしたら、そのドライブのESPをマウントします。例えばドライブがdisk3だったら、

diskutil mount /dev/disk3s1

というようにして、マウントします。ESPは、/Volumes/EFI以下にマウントされます。なので、

open /Volumes/EFI/

として、ここにダウンロードしたBOOTとCLOVERをコピーします。

APPLEというフォルダは、macOSインストーラが作ったフォルダです。このように、ESPにのみファイルを加えていて、macOS本体には何も手を加えていません。なので、完全にバニラな状態です。これで、X220で起動するドライブが完成したはずです。きっと、たぶん。

Thinkpad X220が到着

こんな準備をしながらワクワクしてお待ちしていたらThinkpad X220が意外と早く到着しました。開けてみると外観は期待以上に綺麗でした。とはいえキーボードは、それなりにテカっていて、Aなどは字の一部が消えています。でもキーボードは後で取り替えるつもりなので、気にしません。

起動するとWindows 7が入っていました。HDDは320GB, メモリは4GBx1でした。昔、iMacのメモリを増量した時に余った古いメモリ4GBx2が残っていたので、メモリ用の裏蓋を開けて交換しました。アップル純正メモリです。ネジ2本外すだけで簡単に交換できました。メンテナンスは今のMacBookシリーズとは比較にならないくらい簡単ですね。

追記：AliExpressでキーボードを取り寄せて交換しました。裏のネジを２本外して、キーボードを上にスライドさせるとキーボードが外れます。本体と接続しているフラットケーブルを持ち上げてコネクタを外せば簡単に交換できます。テカリも文字消えも無い新品なので、気持ち良いです。

用意したドライブは起動するのか？

では、いよいよmacOSを起動してみましょう。あらかじめ作っておいたドライブを接続します。USB外付けボックスを使っても良いです。USBの場合、USB 2.0ポートを使います。2.5インチドライブで起動ディスクを作ったのならば、すでに入っているHDDと差し替えても良いです。Thinkpadの脇にあるネジを1本外すとHDD格納ベイのカバーが外れて、HDDを引き出せます。HDDは、すぐに外せるゴムカバーの下で4本のネジで止まっているだけです。ちなみにHDDベイの部品は一式数百円くらいで買えますので、用意しておくとSSD/HDD交換が楽になると思います。

起動ドライブを指定するには、Thinkpadを起動するときにF12キーを連打します。そうすると起動ドライブを選択する画面になります。これで、macOSのディスクを選びます。その結果、

このように見事に立ち上がりました。macOSが起動するドライブを作って、配布されているESPファイル一式を入れただけです。ファイル一式を用意してくれている、上記のサイトのみなさんのおかげです。

トラックポイントと昔ながらのキーボードがエキゾチックで良い感じなのですが、LCDがほとんど水平になるくらいまで開くところもMacBookシリーズにない面白さです。搭載している液晶がパッシブマトリックスなので角度依存性が高くて真正面を外れると画質が悪いです。角度が大きく調整できることでその弱点も補えます。

ESPファイルの確認と調整

ということで、あっけなく起動しました。配布されていたファイルは何だったのか確認してみます。また、手を入れられるところは調整を試みてみます。

BOOTX64.efi

EFI/BOOT/の中に入れたファイルです。Cloverの本体ですので、Cloverのインストーラが入れるものと同じと思われます。新しいバージョンのCloverを入れれば、それに合わせて置き換わるファイルです。

dsdt.aml

EFI/CLOVER/ACPI/patchedに入れたファイルです。X220のDSDTにパッチを当てたファイルです。どう言うパッチを当ててあるのかわかりませんが、X220に合わせたファイルを配布してくれているおかげで、簡単に動かせました。そのまま使うことにします。

apfs.efi

EFI/CLOVER/drivers64UEFIに入れたファイルです。今回は10.13.5に付属する最新のものが入っていました。macOS本体付属のものより古いようなら差し替えておくと良いと思います。また、HFS+のブートファイルを読み込むために、VBoxHfs-64.efiも入っています。

OsxAptioFix2Drv-64.efi

EFI/CLOVER/drivers64UEFIに入れたファイルです。動くものならこれよりも最新のOsxAptioFix3Drv-64.efiが良いと言われています。さらに、AptioMemoryFix.efiで動けば、そのほうがさらに良いと言われています。試したところ、AptioMemoryFix.efiで起動しましたので、これに差し替えて使うことにしました。

これ以外のEFI/CLOVER/drivers64UEFIのファイル類は、Cloverインストーラのデフォルトでインストールされる6個のファイル、

AppleImageCodec-64.efi
AppleKeyAggregator-64.efi
AppleUITheme-64.efi
DataHubDxe-64.efi
FirmwareVolume-64.efi
FSInject-64.efi

に加えて、以下の3個が加わったものです。

OsxFatBinaryDrv-64.efi
SMCHelper-64.efi
UsbKbDxe.efi

kext類

使われているカーネル拡張は、以下の9種類です。

ACPIBatteryManager.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セクションが得られます（この中のシリアル番号は一例ですので使わないでください）。

<key>SMBIOS</key>
<dict>
 <key>BiosReleaseDate</key>
 <string>01/25/18</string>
 <key>BiosVendor</key>
 <string>Apple Inc.</string>
 <key>BiosVersion</key>
 <string>MBP81.88Z.004E.B00.1801250923</string>
 <key>Board-ID</key>
 <string>Mac-94245B3640C91C81</string>
 <key>BoardManufacturer</key>
 <string>Apple Inc.</string>
 <key>BoardSerialNumber</key>
 <string>W89122501OPFF4PJC</string>
 <key>BoardType</key>
 <integer>10</integer>
 <key>BoardVersion</key>
 <string>1.0</string>
 <key>ChassisAssetTag</key>
 <string>MacBook-Aluminum</string>
 <key>ChassisManufacturer</key>
 <string>Apple Inc.</string>
 <key>ChassisType</key>
 <string>0x0A</string>
 <key>Family</key>
 <string>MacBook Pro</string>
 <key>FirmwareFeatures</key>
 <string>0xC00DE137</string>
 <key>FirmwareFeaturesMask</key>
 <string>0xFF1FFF3F</string>
 <key>LocationInChassis</key>
 <string>Part Component</string>
 <key>Manufacturer</key>
 <string>Apple Inc.</string>
 <key>Mobile</key>
 <true/>
 <key>PlatformFeature</key>
 <string>0xFFFF</string>
 <key>ProductName</key>
 <string>MacBookPro8,1</string>
 <key>SerialNumber</key>
 <string>W89FT262DH2G</string>
 <key>Version</key>
 <string>1.0</string>
</dict>

また配布されているconfig.plistでは、Bootのオプションが

 <string>slide=0 kext-dev-mode=1</string>

となっていますが、slideもkext-dev-modeも今は使われていないと思います。全部を消しても大丈夫なはずです。slideはカーネルを読み込むアドレスをずらすオプションです。0に設定してあるので、特に何もしない設定です。Cloverのソースを見たところでは、slide自体がすでに使われていないようでした。kext-dev-modeはEl CapitanでSIPが導入された時に、使用できなくなったオプションです。

USB 3.0

USB 3.0を動かす方法も上記のサイトに書いてあります。RehabManさんが作って配布してくれているGenericUSBXHCI.kextを以下

https://bitbucket.org/RehabMan/os-x-generic-usb3/downloads/

からダウンロードしてEFI/CLOVER/kexts/Other (もしくはバージョン番号のディレクトリ) に入れるだけです。

このkextが無いと、i7 Thinkpad X220の青いUSB 3.0 ポートは動きません。kextを入れると、「システム情報」には現れないものの、ちゃんと動きます。同じUSBメモリを3.0と2.0ポートに挿して速度を計測してみたら、3.0の方が4倍高速でした。

サウンド

上記のサイトで配布されているkext一式に、AppleHDA_20672.kextが入っています。検索して見たところ、このkextを/System/Library/Extensionsに入れればそのままでサウンドが機能したと言う情報がありました。でも動きませんでした。もしかしたら手元の環境のせいなのかもしれませんが、多分、/S/L/Eでは無くて、ESPに入れたのがダメだったのかと思います。

とはいえ、せっかくバニラな構成を目指しているので、/S/L/Eにkextを入れたくありません。そこでAppleALC.kextを試してみました。AppleHDA_20672.kextをESPのCLOVER/kexts/から取り出して、代わりにAppleALC.kextとLilu.kextの最新版を入れました。

この結果、問題なくサウンドが機能しました。マイクロフォンも動きます。キーボードの音量+/-のキー、消音キーも機能します。でもマイクロフォンoffのキーは機能しませんでした。

続きはこちら

Thinkpad X220でHigh Sierra (3)BIOSと無線

Gigabyte Z370 AORUS Gaming 7, 8700K

Thu, 10 May 2018 22:37:37 +0900

Hackintosher.comの記事紹介です。Z370マザーボードとCoffee Lakeを使ってHackintoshを作りたいという場合に役立つ記事だと思います。

hackintosher.com

パーツ選択

High Sierra 10.13.Xを使えばCoffee Lakeはそのまま使えます。iGPUも使えます。Nvidia/AMDのグラフィックスも安定して使えます。この記事では、

CPU: Intel Core i7-8700k
マザーボード：Gigabyte Z370 AORUS Gaming 7
グラフィックス：Gigabyte AMD RX 560 4GB OC
SSD: SAMSUNG 960 EVO NVMe SSD

の組み合わせを紹介しています。しかし、tonymacx86のガイドで紹介されているパーツなら、これ以外でも同様に問題なく動くと思われます。

www.tonymacx86.com

ただ、この記事の手順で期待通りの成果をあげたいのでしたらマザーボードは同じものにした方が良いかもしれません。
グラフィックスはNVIDIAでも良いと書かれていますが、現時点ではAMDが良いです。NVIDIAは最近のmacOSで不具合が報告されています。どの環境でも発生する不具合ではないですし、今後のNVIDIA提供ドライバで解決されると思われますが、macOS標準のドライバで動くAMDの方が安心です。
この記事では、RX 560を使っていますが、もし予算に余裕があるなら、RX 570かRX 580を検討してください。Apple社やSonnet社がmacOSと互換性があると表明しているチップです。Sonnetのリストでは、RX 560はmacOSと互換性が無いとされていますので、今は動いても将来、スリープ復帰などで問題が出てくる可能性があります。

/posts/139/

NVMe SSDもSAMSUNG EVOシリーズ以外でも動くと思われますが、新規に購入するのであれば他の製品を購入してあえて冒険する必要もないです。（もし動いたらぜひ教えてください）
これ以外のパーツ（メモリ、HDD, 電源など）はどれでも良く、tonymacx86のリストから選ぶ必要すらありません。

Clover設定とkext

上で紹介した、Hackintosher.comのページで、ESPに入れるべきファイルの一式を配布しています。これをSSDのESPにそのまま入れるだけで大丈夫なはずです。内容には多少気になる点はありますが、とにかく起動するファイル類を配布してくれているのは初心者にとってありがたいと思います。気になる点は以下です。

RX 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の内容を理解しつつ、シンプルな構成に試行錯誤して書き換えていけば良いと思います。こちらを参考にしてください。

config.plistの実例紹介

マザーボードを設定する

以下のように設定すると良いようです。

Save & 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

こちらもご覧ください。

マザーボード (BIOS) 設定

この後グラフィックスの設定をします。このHackintosher.comのガイドでは、グラフィックスカードを使用する場合は、iGPUをDisabledにするようにと書かれています。手元のマシンで経験したところでは、iGPUをDisabledにしているとあるタイミングでAMDのグラフィックス性能が急激に低下します。Enabledにしておくのが良いと思います。以下をご覧ください。

/posts/62/

インストール手順

インストールの手順は、通常とほぼ同じですが、ESPに提供されたファイルを入れて使います。インストール用USBメモリなどにより起動用SSDにアクセスできる状態で、以下のステップを行います。

SSDをフォーマットする
macOSをこれにインストールする
CloverをESPにインストールする（これは省略可能）
ESPに入ったファイルをHackintosher.comで提供されているファイルと置き換える

3.は省略可能ですし、2.と4.の順番を逆にしても大丈夫なはずです。本ブログの解説記事も参考にしてください。

Hackintoshの作り方（総集編:10.13版）

まとめ

この記事の説明と配布ファイルで、とにかく起動すると思われますので、特に初めて挑戦する方にとってありがたいページかと思います。とにかくHackintoshが動けば安心できます。動いたところで、config.plist, kext, efiドライバなどを調査して最適化すると良いと思います。

SAPPHIRE NITRO+ RADEON RX 580を使う (10.13.4以降)

Tue, 03 Apr 2018 15:18:16 +0900

10.13.4では、Radeon搭載のThunderbolt 3接続外部GPUボックスが正式サポートされました。これにより、AMDグラフィックスカードの互換性が向上して、今まで以上に簡単にHackintoshで使えるようになりました。

10.13.3以前のmacOSでSAPPHIRE NITRO+ RADEON RX 580を使う方法を以下の記事で紹介しました。お勧めしませんが、どうしても10.13.3以前のmacOSを使いたい場合はこちらを参考にしてください。

/posts/90/

上記の記事では、kextを使用したり、config.plistに設定を書いたり、kextにパッチを当ててモデル名を書き換えたりしました。10.13.4では、これらの作業が全て不要になりました。結論として、SAPPHIRE NITRO+ RADEON RX 580は、箱から出してそのまま挿せば、なんの設定もしなくてもHackintoshで動作させることができます。

以下は、上の古い記事を、10.13.4に合わせて書き直したものです。

AMDから1枚を選ぶ

Hackintoshのためのグラフィックスカード選び方に関してこの記事で紹介しました。

/posts/139/

また、Appleが外付けGPUボックスでサポートするAMDのデスクトップ向けグラフィックスカードは、こちらで紹介しました。

Apple推奨グラフィックスカード

これによると、Polaris, Vega 56, Vega 64の3種類のアーキテクチャがサポートされているようです。具体的なチップは、以下です。

AMD 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以降では箱から出してそのまま動作します。

SAPPHIREを選ぶ

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であっても互換性が高いです。ただ、このカードは、すでに販売中止になっていて、入手が困難です。

PULSEの後継機種は、オーバークロックされたNITRO+です。これなら入手は容易です。また、10.13.4からは、NITRO+でもPULSE並みの互換性が確保されるようになりました。そこで今回は、SAPPHIRE NITRO+ RADEON RX 580 8Gを選びました。SAPPHIRE以外のブランドのカードでも、次に紹介するSONNETの資料によると、問題なく動くようです。ただ、Appleが採用・言及しているブランドですので、マザーボードブランドに合わせて見た目を揃えたいというように、特に選びたいブランドがなければ、HackintoshにはSAPPHIREを選んでおくのが無難かと思います。

SAPPHIRE以外の選択

Sonnet社が、同社のThunderbolt 3接続外部GPUボックスで使う各社グラフィックスカードの互換性リストを公開しています。

Sonnetの互換GPUリスト (10.13.4以降)

これから推測すると、10.13.4ではSAPPHIRE以外のメーカのカードも問題なく使用できるようです。そして、互換性の有無は、搭載しているGPUチップで決まるようです。このリストの内容をまとめると、以下のようです。

RX 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は避けた方が良いようです。

NVIDIAからの乗り換え方法

実はこれまでNvidia Geforceを使っていました。大昔はAMDを使っていましたが、macOSとの互換性が悪くなって、最近は、ずっとNvidiaでした。NVIDIAからAMDに移行するためには、NVIDIAのために入れていたWebドライバやkextやconfig.plistの設定を外します。

まずは、/Library/Extensions/に導入されたWebドライバをアンインストールします。Webなんとかという名前のkextが複数ありますので、それを消せば良いです。また、iMacのretinaディスプレイの回路を回避してブラックスクリーン発生を防いでくれる機能があるNvidiaGraphicsFixup.kextを入れている人も多いと思いますが、これも外します。また、config.plistでNvidiaWebドライバを有効にしていた所もfalseにします。もしくは、この部分を全部削除してもかまいません。

        <key>SystemParameters</key>
        <dict>
                <key>NvidiaWeb</key>
                <false/>
        </dict>

RADEONを動かす

ここでシステム終了して、NVIDIAを使っていた場合はそれを外し、Radeon RX 580に差し替えます。

初期化の問題（10.13.3以前で発生）

AppleのThunderbolt 3外付けGPUボックスでは、外部グラフィックスカードがプライマリディスプレイになることはありません。そのため、Hackintoshでグラフィックスカードをプライマリとして使用すると、初期化の問題が10.13.3以前では発生しました。この問題に対応しないと起動しても画面が表示されませんでした。しかし、10.13.4ではその問題がなくなり、差し替えて、電源を入れるだけで画面表示されます。

10.13.3以前では、

Radeonカードをセカンダリで起動する。例えばマルチスクリーン環境にして内蔵GPUをプライマリにする。
kextやDSDTにパッチを当てて初期化をさせないようにする。
これに相当する作業をWhateverGreen.kextとLilu.kextの組み合わせで実施する。
CloverのRadeonDeInit機能で初期化を阻止する

のいずれかの手段で初期化問題を回避していました。しかし、これが必要なくなりました。むしろ副作用が出る可能性もあります（10.13.4でRadeonDeInitを使うとノイズが出ました）ので、元の状態に戻すのが良いです。

モデル名の誤表示（10.13.3以前で発生）

10.13.3以前ではSAPPHIRE PULSEシリーズ以外のカードで、名前が正しく認識されない問題もありました。これは表面上のことで、性能や互換性には関係しないと言われています。見た目にこだわる場合は、対応するkextにパッチを当てることで表示名を変更できました。しかし10.13.4では、NITRO+カードも「システム情報」などで正しい名前が表示されます。

OpenCLスコアの劣化（10.13.4でも発生）

Geekbench 4でのOpenCL Scoreは145000前後です。他でも報告されている程度の妥当な成績なので、正しく設定できていると思います。しかし、しばらく使用していると性能が低下して、ベンチマークスコアが50000くらいになってしまうことがあります。色々試して見たところ、Intel CPU内蔵GPUをマザーボードの設定で無効にしていると性能低下が発生するようです。内蔵GPUはセカンダリーに設定して使用しない場合でも、有効にしておくのが良いようです。（この性能低下問題はMojaveでは発生しなくなりました。しかし内蔵グラフィックスを無効にするとJPEGファイルがクイックルックやプレビューで開けないようです。内蔵グラフィックスは有効にしておくのが良いようです。）

Safari動画再生の停滞（10.13.4でも発生）

Intel CPU内蔵GPUをマザーボードの設定で有効にすると、今度は別の問題が発生することがあります。NITRO+では、SafariでYoutubeなどの動画を再生すると、再生がカクカクして滞ったり、場合によってはハングすることが発生しました。Google Chromeでは問題が出ません。この不具合は、CPU内蔵GPUを無効にすれば解決しますが、上記で述べたような性能低下が発生します。

以前、Intel HD Graphicsを使って同様な不具合が発生した経験があり、その時は、IntelGraphicsFixup.kextとLilu.kextの組み合わせで解消しました。今回も、これで改善しました。ただし、IntelGraphicsFixup.kextとLilu.kextは最新版を使うのが良いです。古いバージョンだと改善しません。

ということで、Radeon GPUを正しく動作させるために10.13.4であっても

Intel CPU内蔵GPUは有効にしておく
IntelGraphicsFixup.kextを使う

のが良いようです。

更新: RX 480/470がサポートされたことを追記しました。2018/4/16

tonymacx86版のCloverインストーラ

Sat, 17 Feb 2018 00:06:14 +0900

今までCloverのインストーラとは別に、MultiBeastというインストールツールを提供して来たtonymacx86のサイトで、新たにCloverインストーラを提供するようになったようです。

www.tonymacx86.com

CloverのインストーラとMultiBeastの違いを簡単にまとめておきます：

Cloverというのはブートローダで、Clover本体のブートローダプログラムファイルと、機能を分担したドライバーのファイルと、設定ファイルconfig.plist、ブート画面のデザインthemeなどのファイルから構成されています。これらを然るべき場所にインストールしてくれるのがおなじみのCloverインストーラです。
MultiBeastというのは、オリジナルのCloverインストーラがやる作業に加えて、主にtonymacx86での推奨PC構成を動かすためのkextの追加、kextへのパッチ当て、config.plistの設定をやってくれます。

tonymacx86の上記のアナウンスによると、tonymacx86では、MultiBeastとは別に、もう一つのCloverインストーラを配布することにしたようです。Cloverのバージョンアップに素早く追随するのが目的とのことです。ダウンロード先は、以下です。MultiBeast, UniBeastなどと同じく、ユーザ登録してログインしないとダウンロードできません。

www.tonymacx86.com

何をやってくれるのか調べるために、このページのClover UEFI Boot Mode v2.4k r4411を実際にダウンロードして、空いているUSBメモリにインストールしてみました。このページの説明と、実際にインストールされた内容をみるに、以下のことをやってくれるようです。

Cloverの標準インストーラがやってくれる作業をする。
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の標準インストーラにあるカスタマイズ機能はありません。

MultiBeastでインストールした人が、Cloverを最新版にアップデートするために使うツールなのかもしれません。でも、それならCloverの標準インストーラで十分ではと思いました。

SSDのTRIMを有効にする

Thu, 01 Feb 2018 23:39:45 +0900

HDD/SSDの読み書き

HDDやSSDは、大容量のデータを低価格で管理するために、一定のかたまり単位でデータの読み書きを提供しています。このかたまりは、HDDではセクターと呼ばれ、SSDではページと呼んでいます。HDDにはセクターサイズが512バイトと4kBのものがあり、SSDのページは一般的には2kBです。これを、以下ではページと統一して呼ぶことにします。

新しいファイルは、新しいページから書き始めます。ページを使い切らなくても、そのページは全部そのファイルのものです。例えば以下のようにすると、Aという文字が書かれたファイルができます。ダンプしてみると文字と改行コードの2バイトの大きさのファイルだということがわかります。

echo A > tako
hexdump tako

このように小さなファイルでも、HDD/SSD上では1ページを使用します。（実際のHFS+では複数ページをまとめた4kBのサイズが最小単位です）

1ページに収まらないファイルは、複数ページに書き込まれます。どのファイルがどのページに書かれて、続きはどのページなのかを管理するのがファイルシステムです。その情報(目次に相当する情報)は特別なページに書いて管理しています。ページの情報が不要になっても、ページの内容をわざわざ消すことはしません。不要になったページ番号を、目次から削除するだけです。

SSDのデータ書込手順

HDDは、円板に塗布した磁性体に微小な磁石を多数作成して、これの磁極を変更してビットを記録します。磁極は磁場を加えると反転するので、上書きが容易です。例えば、ページにAという情報を書き込んだ後からBを書くと、それだけでAがBに書き変わってくれます。

一方SSDは、絶縁された微小な領域に電子を閉じ込める事でビットを記録します。電子を加えるのは比較的に簡単なのですが、取り除くのは手間がかかります。例えると、紙にインクで文字を書くようなものです。とあるページにインクで書かれているAの代わりに、新たにBを書くためには、手間をかけてAの文字を消さないといけません。漂白剤でまっさらな紙に戻してから書き込む必要があります。その上、SSDではページ単位での消去はできません。標準的なSSDでは64ページをまとめてブロックと呼んでいて、消去できるのはこのブロック単位です。いわば、64ページのノートブックになっていて、冊子ごと漂白剤に突っ込んでインクを消さないといけない状況です。

なのでOSから、例えばとある冊子(ブロック)の10ページ目に新たな情報を書き込んでくれと依頼されたSSDコントローラは、次のような作業をします。10ページ目以外の他のページに情報が書かれていたら、その内容を作業用メモリにバックアップします。次に、この冊子全体を漂白します。最後に、バックアップした情報を書き戻し、10ページ目に依頼された情報を書き込みます。かなり面倒な処理です。一方で、これが初めて使う冊子なら、バックアップは不要です。ですからSSDの書き込み速度は色々な要素で変動しますし、一般的にはSSDを使い込んでいくと書き込み速度が低下していきます。

TRIMの役割

SSDの書き込み速度を低下させる原因の一つが、HDDのことしか考えないで設計されたOSです。先に述べたように、OSは不要になったページをいちいち消去することはせず、目次から削除するだけです。ですが、目次がどのページに書かれているかとか、目次のデータ構造がどう決められているかは、HDD/SSDのコントローラにはわかりません。もしOSが、不要になったページ番号だけでもSSDコントローラに教えてくれれば、そのページを無駄にバックアップしたり、書き戻さないですむでしょう。SSDのメモリー素子は書き込むごとに疲弊して、故障の原因になると言われています。なので、不要な書き戻しは避けたいところです。また、一回のブロック消去で真っさらなページを多く用意できれば、次回の書き込みが高速になると期待できます。

このように、使用しなくなったページをSSDコントローラに知らせる機能がTRIMです。TRIMはSSDのために追加された拡張機能です。不要になった葉っぱ（ページ）を刈り取る (trimする) という意味から名付けられたのだと思います。

macOSのTRIM機能

SSDには是非とも欲しいTRIM機能ですが、macOSでは、Macに最初から搭載されているSSDにだけ機能します。なので、本物のMacであっても、ユーザが蓋を開けて交換した市販のSSDでは、TRIM機能が効きません。残念な状況ですが、あらゆるSSDでの動作を保証できないと考えて、そうしているのかと思われます。

Apple非純正のSSDに交換した場合は、macOSに標準で搭載されているtrimforceコマンドを使うと良いです。ターミナルから、

sudo trimforce enable

と打ち込んで、パスワードなどを入力すると、しばらく処理が行われた後、自動的に再起動して、搭載された全てのSSDでTRIMが機能するようになります。

実際はちょっと違います

というような説明がネット上にはあります。が、実際にはそんなに単純ではないです。実際には、

Apple非純正のSSDでも何もせずにTRIMが機能することがあります。
一方でtrimforceコマンドでTRIMが有効にならないSSDもあります。
そんな場合はIOAHCIBlockStorage.kextにパッチを当てれば良いです。

という状況です。

HackintoshでTRIMを有効化

HackintoshではApple純正SSDなどはまず使いませんので、そのままではTRIMが機能しない可能性が高いです。でも、非純正SSDでもTRIMが機能することもあります。ということでまずは状況を確認しましょう。それで機能していなければ対策をしましょう。

Step 1. TRIMが有効になっているかどうか確認する

リンゴマーク–>このMacについて–>システムレポート…–>ハードウェアから、SATA/SATA ExpressやNVMExpressの項目を見て、接続されているSSDを選択します。この中に、TRIMサポート：という項目があります。これが「はい」ならTRIMが機能しています。手元のマシンでは、M.2ソケット接続のSamsungのNVMe SSDは、バニラなmacOSでTRIMサポートされていました。TRIMサポートが「いいえ」なら次のステップに進みます。

Step 2. trimforceコマンドを試す

以前のmacOSではtrimforceがよく機能したものの、最近のmacOSではあまり当てにならない気がしています。でも機能することもあります。OS標準機能なので、一度は試しておきましょう。保証はしないよという警告が出ますが、実行してしまいます。再起動した後で、また「システム情報」でTRIMサポートを確認します。手元のSATA接続SanDiskの2.5インチSSDは、trimforceコマンドでもTRIM有効化できませんでした。

でも、AliExpressで買ったmSATA接続SSDはTRIM有効化できました。

Step 3. IOAHCIBlockStorage.kextにパッチを当てる

これは確実です。本物のMacを対象としたネット上の情報でも、パッチを当てる方法が紹介されています。でも、結構面倒ですし、SIPを無効にする必要がありますし、OSがバニラな状態ではなくなってしまいます。OSのアップデートごとに、同じパッチ当てをする必要があるでしょう。でもCloverを使ったHackintoshなら、config.plistで設定するだけで、起動時に動的にパッチを当てます。OS本体は手つかずのままパッチを当ててくれます。素晴らしいです。config.plistのKextsToPatchにセクションに以下のように書き込みます。

<key>KextsToPatch</key>
<array>
 <dict>
 <key>Name</key>
 <string>IOAHCIBlockStorage</string>
 <key>Find</key>
 <data>
 AEFQUExFIFNTRAA=
 </data>
 <key>Replace</key>
 <data>
 AAAAAAAAAAAAAAA=
 </data>
 <key>Comment</key>
 <string>TRIM Enabler</string>
 </dict>
</array>

このパッチでは、Base64表記でAEFQUExFIFNTRAA=というデータを、AAAAというAの羅列データに置き換えています。16進数で表すと

004150504c452053534400

というデータを

0000000000000000000000

で置き換えていることになります（Base64ではAが数値の0です）。元のデータは、最初と最後の0x00を除くと、真ん中はASCIIコードになっていて、APPLE SSDという文字列です。

004150504c452053534400
 A P P L E S S D

おそらくApple社のSSDに限定している場所を、0で消しているようです。この結果、手元のSanDisk 2.5インチSSDでもTRIMが有効になりました。

Asus Prime X299 Deluxe, 7980XE

Wed, 24 Jan 2018 22:26:56 +0900

X299マザーボードにSkylake-Xを搭載した自作水冷マシンにmacOSをインストールする記事がtonymacx86で紹介されています。iMac Proのようなマシンです。この記事が最初に書かれたのは去年の8月ですが、適宜アップデートされているようです。18コア36スレッドの究極のmacOSハードウェアを作るのは、ロマンですね。記事はかなりの長文ですのでサクッと抄訳してみたいと思います。

www.tonymacx86.com

—————————-ここから抄訳—————————-«

Skylake-X/X299のマシンにmacOS High Sierra 10.13.2をインストールしてiMac Pro相当のマシンを作るためのガイドです。

A.) ハードウェアの概要

i7-7640X と 7740X は、2チャンネルのDDR4-2666であったり、PCI express 3.0が16本しかなかったりで、見劣りがします。i7-7800とi7-7820は4チャンネルDDR4-2666ですがPCIeが28本です。ということで、最高の性能を得るためには、i9-7900X以上のCPUを選択することをお勧めします。

今回の構成は以下です。

マザーボード: 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にパッチを当てる手順は以下です。

BREWをインストールしてQT5をインストールする
CodeRush UEFIPatchをGithubから入手する
@interferenc氏によって作られたパッチのファイルpatches.txtを入手する
ASUSから最新のBIOSを入手する
UEFIPatchコマンドでパッチを当てる
出来上がったBIOSをFAT32のUSBメモリに入れる
BIOS起動時にF2を押してUSBからBIOSをアップデートする

再起動した後、ターミナルからbdmesg | grep MSRコマンドを入れると、MSR 0xE2レジスターがアンロックされたことを確認できます。

B2.) ASUSのBIOS設定

BIOSを設定します。（**訳注：**通常の設定ですので省略します）

B3.) – GigabyteのBIOS設定

BIOSを設定します。（**訳注：**こちらも省略します）

C.) エラーを防ぐための重要なアドバイス

配布しているファイルでは、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が出ると思いますので、そうなったらそれを使えば良いので、この作業は不要になります。

D.3) iMac Pro macOS High Sierra 10.13.2 (17C2120) USB インストーラを作る

いつものようにcreateinstallmediaコマンドで、インストール用USBメモリを作ります。作ったUSBメモリをブート可能にするために、以下の操作をします。

cd /Volumes/USB_VOLUME
mkdir .IABootFiles
cd .IABootFiles
cp /Volumes/USB_VOLUME/System/Library/CoreServices/boot.efi .

前のD.1節で作ったEFIフォルダを、このUSBのEFIパーティションに入れます。

D.4) iMac Pro macOS High Sierra 10.13.2 (17C2120) のクリーンインストール

Skylake-X/X299の自作システムに、17C2120をクリーンインストールします。このために、

新しい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が出れば不要な作業かと思います。

D.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から可能です。

**訳注：**もしかしたら10.13.3 Public Beta 4を使えば、そのままiMac対応High Sierraになっていたのかもしれないですね。

E.) インストール後の設定

E.1) CPU電力制御設定

**訳注：**電力制御を動かすための設定が説明されています。もともとXeonやXシリーズは、電力制御の設定が必要だったのですが、iMac Proのおかげで多少は楽になったようです。それでもいくつか作業が必要のようです。また、ssdtPRGen.shを使ってSSDTも作ります。

E.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で動きます。

E.5) ASUS Prime X299 Deluxe Thunderbolt EX3 PCIeカードを使う

Thunderboltカードを使うためには、残念ながらWindowsもインストールする必要があります。Windowsでカードが認識されて初期化されて、初めて、BIOSでThunderboltの設定ができるようになります。そこで、Windowsを起動できるようにインストールして、付録のThunderbolt EX3 DVDからドライバをインストールします。この後、BIOSからカードを設定します。

E.6) NVMe の互換性

10.13からSamsung EVO 960 M.2 NVMe SSDのような市販のSSDがネイティブに使えるようになりました。10.12で必要だったパッチは全て不要になりました。

E.7.) SSD TRIM Support

TRIM機能はアップル純正SSDでしかonになりません。そこで、IOAHCIBlockStorage.kextにconfig.plistでパッチを当てます。それでTRIMが有効になります。

Name*             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のおかげで使用できるようになりました。

E.9) ASUS Prime X299 Deluxe PCI Device Implementation

全てのPCIデバイスを正しくインストールするために、適切なACPI DSDT置き換えパッチテーブルと、SSDT-X299.amlが必要です。ASUS Prime X299 Deluxeのためにどちらも用意されています。添付したconfig.plistに含めてあります。

E.10) 「このMacについて」のCPU表示

見た目だけの問題ですが、何もしないと、Processorの表示がUnknownになっています。これは

/System/Library/PrivateFrameworks/AppleSystemInfo.framework/Versions/A/Resources/English.lproj/AppleSystemInfo.strings

を書き換え、config.plistのCPUセクションのTypeをUnknownに設定すると修正できます。

E.11) Logic-X などのAudioソフトウェア機能

MSR 0xE2レジスタのロックを外したことで、macOSのKernelが全て電力制御を担当することになり、以前のLogic-Xやその他のオーディオソフトウェアの問題が解決されました。それでも、Logic-Xで設定しなければならない項目があります。（**訳注：**これらのアプリのことがよくわかってません。すみません。）

F.) ベンチマーク

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

Hackintoshの長靴 (ブート)

Fri, 19 Jan 2018 12:08:07 +0900

↓ブートストラップ

ご存知のようにコンピュータを起動することをブートすると言います。このサイトの名前も、「macOSを起動しよう」という意味です。ブートは一般の辞書にも動詞として載っています。このブートの元の意味は長靴です。

一方、公式WikiによるとCloverの正式名称は、Clover Bootloaderです。Bootloaderというのは、

– Bootstrap program loader

を短くした言い方です。loadするというのは搭載するとか装填するという意味で、HDDなどからプログラムを読み込んで、コンピュータ上のメモリに格納して、プログラムが動作できるように準備する作業をさします。OSは稼働している間、こういう仕事をいつもやっています。当然ですが、loadするのもプログラムで実施しています。

ではコンピュータの電源を入れたばかりで、メモリー上のプログラムが空っぽの状態では、どうやってloadすれば良いのでしょうか。load作業を実施するプログラムはHDDの中にあります。缶切りが缶詰の中に入っている状況です。そこで使われるのが、缶切り機能だけに特化したBootstrap programという短い(OS全体に比べたら)プログラムです。CloverはmacOSを稼働させるために、まずはmacOSの核(kernel)となる基本機能を含むbootstrap programを読み込み (load) ます。次に、bootstrap programに制御を移管し、macOSの全体の読み込みと設定を行ってもらいます。なので、Cloverはbootstrap program loaderなわけです。

そもそもbootstrapって何かと言うと、上の写真にあるブーツの踵などについている平たい紐のことです。ストラップは平たい革紐のことです。ブーツに足を突っ込んで、このストラップを引っ張ってブーツを持ち上げると、楽に履けます。この時にもっと頑張ってストラップを引っ張ったら、自分で自分の体を持ち上げられるかもしれません。それでpull oneself up by one’s bootstrapsという言い回しは、「自力でなんとかする」という意味になりました。自力でなんとかOSを立ち上げるためのプログラムも、これにちなんでbootstrap programと呼ぶようになりました。

bootstrap programをloadするためには、

プログラムを装填するためのメモリ領域を確保して
ファイルシステムから読み込む

二つのステップが必要です。Cloverではそのために以下の設定が必要です。

メモリを確保する

マザーボードに電源が投入された直後は、UEFIという簡易的なOSのようなプログラムが動いていて、メモリなどのコンピュータリソースを管理しています。CloverはUEFIにお願いしてmacOSのbootstrap programを格納するためのメモリ領域を確保します。メモリ上には、すでにグラフィックスカードや他の周辺機器のBIOSが居座っていることもあります。空き地を探したり、空き地を確保するためのこれらを移動したり、いろいろな作業が必要です。その手続きが、マザーボードや搭載周辺機器によって異なることがあります。なので、それを行うプログラムもハードウェアに合わせて選択する必要があります。そこで、Cloverの設定作業

では、以下の選択肢の中から必要なプログラムを1つだけ選択して、EFI/CLOVER/drivers64UEFI/の中に格納します。

AptioMemoryFix.efi
OsxAptioFix3Drv-64.efi
OsxAptioFix2Drv-64.efi
OsxAptioFixDrv-64.efi
OsxLowMemFixDrv-64.efi

必要なのは、このうちの1つだけです。このリストの複数のファイルをdrivers64UEFIに入れてはいけません。また、推奨する順に番号が振られています。この順番に入れてみて、ちゃんと起動すればそれを使うのが良いです。できれば1か2が望ましいです。

この選択が正しくないと、メモリを確保できません。メモリを確保できないと、Cloverが起動した直後に、

こんなマークが出て止まってしまいます。-vオプションで起動すると、

OSXAptioFix2Drv: Starting overides for SystemLibrafyCoreServicesoot.efi
Using reloc block: no, hibernate wake: no
Error allocating 0x116f5 pages at 0x000..... alloc type 2
Couldn't allocate runtime area
Boot failed, sleeping for 10 seconds before exiting...

こんなメッセージが現れて止まってしまいます。こんなメッセージの場合もあります。

AptioMemoryFix(RC5) : Starting SystemLibraryCoreServicesoot.efi
Hibernate wake: no
does printf work??

また、これらのエラーは、必ず出るとは限りません。起動のタイミングで、周辺機器BIOSがたまたま分散せずにメモリマップ上のかたまった場所に配置され、空き領域が容易に確保できるような場合には、エラーが発生しにくいです。なので、何度も試すとエラーが出る場合もありますし、逆に、ほとんどエラーが出るけど稀に起動できたりすることもあります。

上記の5個のプログラムの違いは、以下で説明されています。

www.insanelymac.com

それによると：

OsxAptioFixDrv-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が使えました。

追記：起動に失敗する原因は、連続したメモリー空き空間が確保できないためです。KASLR（カーネル番地乱数化）をoffにしてslideを指定して、カーネル読み込み場所を明示的に指定することで解決します。詳しくはこちらをご覧ください。

slideでカーネル読み込み番地を調整する (Clover編)

ファイルシステムから読み込む

ファイルを管理するOSの仕組みがファイルシステムです。起動パーティションに使われるファイルシステムは、macOS Sierra以前ではHFS+だけですが、macOS High Sierra以降ではHFS+とAPFSの2種類が使われます。OSは、ファイルシステムを知り尽くしていて、その機能を全て使いこなします。bootstrap programに必要なファイルもファイルシステムの中に置かれていて、OSならばそれを読みだすのは簡単です。でも、コンピュータに電源を入れた直後は、ファイルを読みだすプログラムも、ファイルシステムの中にあります。またもや缶切りが缶詰の中にある状態です。

そこで、なんとかbootstrap program関連ファイルだけでも読みだすためのプログラムが作られています。それが、CloverのEFI/CLOVER/drivers64UEFI/の中に格納される次のファイルです。

VBoxHfs.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起動ボリュームが現れません。

VBoxHfs.efiだけがCloverの配布セットに含まれています。VBoxHfs-64.efiはオープンソースのHFS+ドライバです。オープンソースであるために、Appleの許可を得ずに（純正ドライバーの配布をお願いしても許可をもらえないと思いますが）配布することが可能なのです。

HFSPlus.efiはApple社純正のドライバで、本物のMacintoshのファームウェアで使われているものです。ハッカーのみなさんの技術で、ファームウェアから取り出されて、配布されています（名前で検索すれば配布サイトが出てきます）。多くのガイド、例えばこちらでは、VBoxHfs.efiをHFSPlus.efiに置き換えると良いと書かれています。オープンソースのプログラムより、Apple純正の方が高速だからという理由です。ただ、起動時間を実測してみたところ、

VBoxHfs-64.efiは約14秒
HFSPlus.efiは約9秒

程度の違いしかありませんでした。ブートの時しか関係しないことですし、現行macOSはAPFS起動のみですので、無理して入手して置き換える必要はないと思います。

apfs.efiは、macOS High Sierraの /usr/standalone/i386/ の中にあります。システムがAPFSに格納されている場合は、これが無いとCloverの起動選択画面に現れません。apfs.efi入手方法の詳細な手順は以下をご覧ください。

2018/06/19更新：Clover 4558からApfsDriverLoader.efiというドライバができて、apfs.efiの機能を自動的にロードしてくれるようになりました。なので、 /usr/standalone/i386/ からapfs.efiを取り寄せてESPに置く必要は無くなりました。

HackintoshをHigh Sierraにする

Windowsと同居する

Sun, 14 Jan 2018 14:48:50 +0900

Hackintoshで使うコンピュータはもともとWindowsをインストールする前提で作られているので、当然ながらWindowsも走ります。本物のMacでは、Boot CampというツールでWindowsを動かすようにしますが、その必要はありません（そもそもBoot Campは使えません）。今回は、macOSとWindowsのマルチブートを設定するときの注意事項を書いてみました。

別ドライブにインストールするのが楽

WindowsとmacOSを同一の物理ドライブの別パーティションにインストールすることは可能ではあります。でも色々面倒なので、できれば別の物理ドライブに、macOSとWindowsを分けてインストールするのが簡単です。デスクトップPCなら複数ドライブ搭載は簡単だと思います。

同一のドライブの別パーティションにmacOSとWindowsをインストールしようとすると、それぞれがESPを書き換えることになります。Cloverで設定したものが、Windowsをインストールすると動かなくなります。もう一度、設定すれば良いのですが、かなり面倒です。このような問題は、ESP以前のMBR（マスターブートレコード）を使っていた時代からありました。物理的に別のドライブにインストールすれば、それぞれのESPに個別に起動項目が書き込まれるので、干渉しません。別のドライブにインストールされたWindowsは、UEFI/BIOSの起動メニューで選択することもできますし、Cloverの起動選択画面からも起動できます。

最近の経験では、そもそもパーティションスキームが違ってインストールできないこともありました。特にAPFSになって採用された新しい論理パーティションなどは、Windowsインストーラから使えません。なので同じドライブにインストールしようとする場合は、パーティション分けの方法も面倒になり、試行錯誤が必要になると思います。

インストールに関係ないドライブを外す

Windowsをあまり使わないこともありますが、Windowsインストーラの挙動は、いまだに謎です。インストール対象のドライブ以外のドライブがコンピュータに多数接続されていると、インストールできないことがあります。もしかしたら接続されているドライブがmacOS用にパーティション分けされていたのがいけないのかもしれません。関係ないドライブは外しておいた方が良いです。

先日、m.2 SSDを外すのが面倒だったので接続したまま別ドライブにインストールを試みたら、m.2 SSDのESPに起動ファイルが書き込まれてCloverが起動しなくなってしまいました。Windowsインストーラは、インストール先として指定しないドライブを書き換えることもあるようです。面倒でもm.2 SSDを外すか、せめてUEFI/BIOSでm.2を読めないように設定して、Windowsインストールするのが良いと思いました。

時刻を合わせる

macOSとWindowsを切り替えて使用すると、時刻が合いません。9時間だけずれます。macOSはUTC (協定世界時: Coordinated Universal Time, 昔はグリニッジ標準時GMTと呼ばれていた時刻）を使っているのに対して、Windowsは現地時間を使っているからです。

コンピュータは、ファイル作成時刻などを管理するために、時計機能を備えています。マザーボードにはRTC（リアルタイムクロック）というチップが搭載されていて、電源が切れている時も、ボタン電池で時刻を刻んでいます。時差の違う場所に置かれたコンピュータ同士をネットワーク接続で使うことを考えると、コンピュータの時刻はどれか一つの基準時間を使うべきです。そうするとUTCを使用するのが順当です。ということで、macOSやLinuxなどのUNIX系のOSでは、UTCで時刻を管理して、必要に応じて現地時間に換算して表示しています。

UNIX系OSは専門家が使う高価で大掛かりなコンピュータのためのOSとして開発されました。一方、Windowsの先祖は、単独で動く簡素な個人用コンピュータ（マイクロコンピュータ、マイコン）で使われたOSです。昔のコンピュータには電池バックアップのRTCなどなかったので、起動時に時刻を入力させられました。個人ユーザがいちいちUTCと時差を入力するのは面倒なので、マイコンの時計は現地時間に設定することになっていました。それでWindowsは今でもRTCを現地時間に設定していて、UTCが必要な場合には、現地時間から換算しています。

RTCがUTCでも現地時間でも、必要に応じて換算すれば良いので問題はありません。でも、macOSとWindowsで同一のRTCを共有すると、OSを切り替えるたびに時間がずれてしまいます。Boot Campではこの問題を解決するドライバが用意されています。Hackintoshでは、当然ながらそういう配慮はありませんので、自力で解決することになります。

WindowsをUTCにする

WindowsとmacOSのどちらを相手に合わせても良いのですが、歴史的な経緯で仕方なく(?)現地時間を使っているWindowsを正統なUTCに切り替える方が簡単です。これにはレジストリを書き換えます。Windowsでregedit.exeを実行するとレジストリエディタが起動します。

左の階層から、コンピュータ、HKEY_LOCAL_MACHINE, SYSTEM, CurrentControlSet, Control, TimeZoneInformationと辿っていきます。TimeZoneInformationで右ボタンクリックでコンテクストメニューを呼び出し、「新規 (N)」「DWORD (32ビット) 値(D)」を選択します。

ここで、RealTimeIsUniversalという値を作り、この名前をダブルクリックして設定ウィンドウを開き、値を1に設定します。このあとWindowsをシャットダウンし、一旦macOSを起動して、またWindowsに戻ってくると、Windowsの時刻がmacOSと一致します。

コマンドプロンプトで設定する

フォーラムで教えていただきましたが、レジストリエディタを使う代わりに、Windowsのコマンドプロンプトから設定することも可能のようです。以下のようにタイプします。

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f

起動失敗に備えてバックアップ

Wed, 03 Jan 2018 12:01:34 +0900

Hackintoshでkextを入れ替えたり、config.plistを書き換えたりなど、色々実験していると、起動しなくなる状況に遭遇することがあります。そんな場合に対処できるように、起動可能なパーティションのバックアップを持つことは、Hackintoshを使う上での必須の習慣だと思います。

バニラなインストールをすると、SSD/HDDの本体パーティションにmacOSが入り、macOSでは使用しないEFI System Partition (ESP)にClover bootloaderやkext類がインストールされます。

/posts/131/

Hackintoshが動かなくなったことに備え、バックアップする対象は、以下のいずれかになります。

ESPとmacOSインストーラ
ESPとmacOS
ESPのみ

それぞれについて、以下で説明します。

1. 導入用USBメモリを残しておく

一番普通の方法かもしれません。一般的な手順では、USBメモリにmacOSインストーラを作り、これにCloverをインストールします。このUSBメモリを大事に保存しておけば、本体が起動しなくなった場合に利用できます。これがあれば、一切を消去してもう一度インストールし直すことができます。でも、そこまでやらなくても、macOSインストーラで起動できれば、ターミナル.appを起動することができるので、かなりの作業が可能です。起動失敗を引き起こしたkextを取り除いたり、config.plistを元に戻したりできます。

またバニラなインストールがされていれば、ESP部分を書き損じても、macOS本体は正しく残っている可能性が高いです。USBメモリのCloverで起動して、起動しなくなったドライブのmacOSから起動できれば、修復作業が容易です。

この方式の難点は、非常用のUSBメモリは滅多に使わないので、失くしてしまいやすいことです。手元にあるとついつい他の用途に使ってしまいます。気軽に使えないようにPCケースの中に入れておくのも良いかもしれないです。

2. CloverとmacOSを複製しておく

バニラなインストールをしていれば、macOS本体に手を入れることはないので、Hackintoshの不具合でmacOS本体を壊す危険はありません。でも、macOSのバージョンアップ、特に年に一回のメジャーバージョンアップに備えて、CloverとmacOSの両方をインストールして、バックアップとしておくのが良いです。

バックアップのためには、いつも使うSSD/HDDとは別のドライブに、macOSとCloverをインストールします。通常のインストールと同様に、インストール用のUSBメモリから起動して、対象とするドライブのパーティションをフォーマットして、macOSとCloverをインストールしても良いです。でも、すでに起動できるmacOSドライブがあってこれをバックアップするならもっと簡単です。以下のようにできます。

App StoreからダウンロードするmacOSインストーラを起動して、対象とするパーティションにmacOSをインストールします。
必要ならば移行アシスタントを使って現在の設定とアプリケーションもバックアップします。
対象とするドライブのESPに、現在起動しているESPの内容をコピーします。（Cloverインストーラを起動しても良いですが、ファインダによるドラッグ&ドロップだけでもバックアップできます）

もしマシンに複数のHDDを接続していて、その一部をデータ用やTimemachine用にしているような場合、そのHDDの最初に60GBくらいのパーティションを用意します。そしてこのパーティションとESPそれぞれに、上記の手順でmacOSとCloverを入れておくと良いです。macOS自体は30GB弱あればインストールできます。60GBあれば必須のアプリケーションと多少の作業は可能です。内蔵HDDにバックアップを用意しておけば、USBメモリと違って紛失する心配もありません。

3. ESPを複製しておく

バニラなインストールをしておけば、Hackintoshに必要なものは全てESPに入っています。設定を変えて起動しなくなる場合も、ほとんどの場合がESPの内容を書き換えてしまったことが原因です。そこで、ESPだけをバックアップしておけば、大抵の場合は、これから起動することで復帰できます。ESPは容量も少ないですので、バックアップも容易です。データ用のHDDやUSBメモリでは使われていない領域ですので、あちこちにバックアップしておくと良いです。内蔵SSD/HDDにも、空のESPがあったら、今使っているESPの内容をコピーしておきましょう。

ESPにあるファイルだけを、ファイルサーバやクラウドに保存しておいても良いと思います。これまでの説明で用意したバックアップのSSD/HDD/USBメモリが全て無くなってしまっても、ESPの内容さえ持って入れば、手元のSSD/HDD/USBメモリのESPにコピーして起動させることができます。

4. ESPを自動バックアップする

**追記：**ESPを自動的にバックアップする方法をこちらに書きました。

ESPを自動バックアップする

Cloverから季節のご挨拶

Wed, 27 Dec 2017 10:07:02 +0900

（更新：2017.1.2 新年の起動画面を追加）

クリスマスになってCloverの起動画面がクリスマス仕様になりました。最初にこれを見た年はびっくりしたので、今年からHackintosh始めた人は新鮮だったのではないでしょうか。ちなみに、新年になったら今度はしばらくの間、新年仕様に変わるはずです。旧漢字TalkとかMac OSでは新年になると「あけましておめでとうございます」表示が起動画面に出てました。Macintoshはそういうのを楽しむ文化なんですね。

とはいえ、複数の設定切り替えを、テーマの切り替えで確認していた人には、全部がクリスマス／新年になってしまうので厄介です。年末年始はHackしないでゆっくり休みなさいという意味かもしれませんが。また、もしかしたらクリスチャンじゃ無いからクリスマスは要らないという人もいるかもしれません。この機能を消して、通常の、設定済み起動画面に戻すのは簡単です。

ご挨拶の消し方

起動画面を定義するCloverの設定フォルダであるthemesにchristmasもしくはnewyearという名前のフォルダが入っているかと思います。これらはCloverのインストーラがデフォルトでインストールしますので、大抵はあるはずです。バニラなインストールでCloverをESPに入れてあるなら、christmasやnewyearは、EFI/CLOVER/themes/の中にあります。これらの名前のフォルダがあると、年末年始に自動的に切り替わります。そこでフォルダ名を別の名前に変更する（例えばchristmasをchristmas2などに変える）と、「季節のご挨拶」機能は効かなくなります。

新年のご挨拶

新年になりました。Cloverの起動画面も新年バージョンになりました。今年もよろしくお願いします。本物のMacで新年が祝われなくなってしまって、祝ってもらえるのはいまやHackintoshだけというのが面白いですね。以前から疑問なのですが、クリスマスツリーのような門松飾りのようなイラストは何なのでしょうか。Clover開発チームの居るロシアでの新年モニュメントなのかもしれないです。ご存知の方いらしたらよろしく。

HackintoshのOSアップデートは難しい？

Sun, 24 Dec 2017 16:34:39 +0900

「Hackintoshは最初は動いてもmacOSのアップデートのたびに大変なトラブルに陥る」というイメージがあるかもしれません。Apple社がちゃんとサポートしてくれている実機に比べたら面倒なのは確かですが、それほど変わらないと思います。macOSが好きで、動かないコンピュータを動かすことが趣味な人間が言うことですので、あまり当てにはなりませんが、

マイナーアップデートは楽勝

です。例えば10.13.1から10.13.2へのアップデートのように、年に数回行われるマイナーアップデートは実機と同じくらいのお手軽さです。少なくともここ2-3年の状況では、Cloverとkextを最新に保っておけば、App Storeからのアップデートをそのまま受け入れて、macOSアップデートしてもまず問題は起こりません。

NVIDIAのグラフィックスカードでWeb driverを使っている人は、新しいmacOSに対応したドライバが配布されるまで高解像度表示ができなくなるかもしれません。でもNVIDIAの対応はいつも敏速で、ほぼ24時間以内に新しいドライバを配布しています。Mac Proのユーザも多いのでしょうが、Hackintoshユーザからしたらありがたいメーカーです。

メジャーアップデートは少し大変

ここのところ年に一度、9月にあるメジャーアップデート（例えば10.12から10.13へのアップデート）は少し面倒な作業が伴います。それも年に一度のお祭りとして楽しんでいただければ良いと思います。

最近の出来事ですと、10.11でUSBの個数制限が行われて使用可能なUSBポートの数が、コントローラ当たり15までと制限されました。この制限を解除したり、制限の枠の中で使用するポートを指定する作業が必要でした。

USBポートを設定する

10.11ではSIPも導入されました。/S/L/Eや/L/Eにkextを置く場合ではSIPを無効にする設定が必要になりました。バニラなインストールをすればSIPはデフォルトでも大丈夫です。

/posts/132/

10.13ではAPFSが導入され、実機でファームウェアアップデートが行われました。それに合わせて、HackintoshでもSMBIOSの変更が必要でした。APFSボリュームから起動するためにはドライバも入れておかねばなりません。

HackintoshをHigh Sierraにする

このようにメジャーアップデートでは予期しない課題が発生する可能性がありますので、古いmacOSはそのまま残して、予備のSSD/HDDにシステムを作って動作を確認した方が良いと思います。パブリックベータが配布されている時期か試しておけば、正式リリースの時にいち早く導入できるかと思います。

アップデートは面倒なことだけではなく、新しいCPUへの対応、NVMe SSDの対応、ビデオカードの対応など、新しい技術の恩恵にあずかれるチャンスですので、積極的に受け入れていきたいと思います。

10.13.2へのマイナーアップデートで躓く

マイナーアップデートは楽勝と書きましたが、最近、躓いたことを書いておきます。メインで使用しているHackintoshで10.13.1から10.13.2へのアップデートをしたのですが、これはApp Storeからのダウンロードだけで簡単に終了しました。10.13.2でスリープが効かなくなったとかの噂も聞くのですが、全く問題ありません。

ところが、サブで使っているマシンでアップデートしようとしたら、インストールのための再起動で失敗しました。Boot macOS Install from xxxxが選択された、起動しようとするところで失敗し、再び再起動を無限に繰り返すようになりました。

たまにしか使わないサブのマシンでしたので、しばらくはあきらめて10.13.1の古いままで使っていました。このところ時間もできたのでじっくりと原因を探して見たら、なんとkextの一つ、Lilu.kextが古いだけでした。Lilu.kextは10.13.2のベータ版に合わせて11月上旬に1.2.1に更新されています。メインのマシンでは早々と更新していたのですが、サブマシンでは1.2.0のままでした。とほほな単純ミスでした。

ということで、最初にも書きましたが、Cloverとkext類は最新に保っておきましょう。

SAPPHIRE NITRO+ RADEON RX 580を使う (10.13.3以前)

Fri, 01 Dec 2017 00:00:00 +0900

ご案内：この記事は10.13.2および10.13.3を対象に書かれたものです。10.13.4では、Radeon搭載のThunderbolt 3接続外部GPUボックスが正式サポートされたことにより、ずっと簡単になりました。この記事の**「方法1」「方法2」「方法3」****「モデル名の修正」は不要**になりました。改訂版は以下です。(2018/4/3)

/posts/62/

Radeon RX 580を使ってみました。簡単で性能も良いです。

/posts/139/

Hackintoshのためのグラフィックスカード選び方に関して上の記事で紹介しました。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 に搭載されているブランドなので、安心感があります。

NVIDIAから乗り換え
RADEONを動かす方法
方法1: 内蔵GPUをプライマリにする
方法2: WhateverGreen.kextを使う
方法3: CloverのRadeonDeInit機能を使う
動作を確認
モデル名の修正
おまけ：現行macOSがサポートするAMDグラフィックスカード

NVIDIAから乗り換え

今まではNvidia Geforceを使っていました。大昔はAMDを使っていましたが、macOSとの互換性が悪くなって、最近は、ずっとNvidiaでした。ということで、NVIDIAが正常に動いているmacOS 10.13.1 からの引越しです。

まずはNVIDIAのために入れていたWebドライバやkextやconfig.plistの設定を外します。/Library/Extensions/に導入されたWebドライバをアンインストールします。iMacのretinaディスプレイの回路を回避してブラックスクリーン発生を防いでくれる機能があるNvidiaGraphicsFixup.kextを入れていたのですが、これも外します。config.plistでNvidiaWebドライバを有効にしていたのですが、これもfalseにしました。

        <key>SystemParameters</key>
        <dict>
                <key>NvidiaWeb</key>
                <false/>
        </dict>

RADEONを動かす方法

ここでシステム終了して、NVIDIAのグラフィックスカードを外し、Radeon RX 580に差し替えます。でもこのまま起動しても画面は出ません。画面が出ないだけで、macOSは起動していますので、sshサーバや画面共有サーバをonにして、他のマシンからアクセスできるようにしておくと良いでしょう。

画面が出ない問題は、Radeon RX 580がプライマリの状態では、グラフィックスカードのBIOSが初期化を正しく実行しないために引き起こされているようです。macOSが正しく初期化しようとするタイミングでは、すでに初期化が終了しているため、macOSによる初期化が実行されないらしいです。これを回避するために、いくつかの方法が知られています。

Radeonカードをセカンダリで起動する。例えば内蔵GPUをプライマリにする。マルチスクリーン環境が前提。
kextやDSDTにパッチを当てて初期化をさせないようにする。
これに相当する作業をWhateverGreen.kextとLilu.kextの組み合わせで実施する。
CloverのRadeonDeInit機能で初期化を阻止する

ここでは、以下のように、1番目、3番目、4番目の方法を紹介します。

方法1: 内蔵GPUをプライマリにする
方法2: WhateverGreen.kextを使う
方法3: CloverのRadeonDeInit機能を使う

方法3がおすすめです。

方法1: 内蔵GPUをプライマリにする

内蔵GPUをプライマリグラフィックスに、Radeon RX 580をセカンダリーグラフィックスに設定します。Radeonグラフィックスチップを搭載した実機や、Apple External Graphics Development Kitを接続した実機と同様の、一番実機に近い設定です。

これを行うためには、BIOS/UEFI設定で内蔵GPUをプライマリに設定します。

この設定をして、RX 580のみをディスプレイに接続すると、起動時のBIOS/UEFI画面やCloverの起動画面は表示されず、ディスプレイが真っ暗なままです。ただ、macOSのログイン画面まで来ると、ディスプレイに表示されます。

起動画面が表示されないので、ある意味、本物のMacのような感じはしますが、BIOSやCloverの操作はできません。通常はこのまま使って、必要な時に、マザーボードのディスプレイ端子にディスプレイを接続するのも良いかと思います。マルチディスプレイ環境や、ディスプレイに複数入力端子があるなら、RX 580とマザーボードの両方に接続しておけば、設定変更も容易になります。

BIOSの設定だけでRadeonが使えるようになりますが、ちょっと不自由な方法です。

方法2: WhateverGreen.kextを使う

WhateverGreen.kextはRadeonグラフィックスカードをプライマリグラフィックスとして使うためのパッチを当ててくれるkextです。Lilu.kextと一緒に使います。両方を/CLOVER/kextsのOtherもしくは該当するバージョンのフォルダに一緒に入れます。これだけでRadeon RX 580が使用できるようになります。

/posts/118/

方法3: CloverのRadeonDeInit機能を使う

もう一つの方法は、Cloverが提供しているRadeonDeInitの機能を使う方法です。この機能は、Clover 4296あたりからサポートされたばかりの新機能で、kext不要です。今後もClover開発者によりメンテナンスされることを考えると安心です。Radeonカードをサポートする機能を作り込むあたりに、Clover開発者の人たちのRadeonへの愛が感じられなくもないです。

この機能を設定しないで起動してしまい、Radeonからの画面が出なくなってしまっても、Cloverの起動画面からClover Boot Optionsを選ぶことで対処できます。この中から、起動画面からGraphics Injectorを選びます。するとこの中に、DeInitという項目があります。これがRadeonの初期化を無効にするオプションです。これにチェックマークを入れます。

これだけの操作で、Radeon RX 580は無事起動します。

config.plistにRadeonDeInitキーを追加して、これをにしておけば、次回の起動から、DeInitの項目を選択した状態になります。

        <key>Graphics</key>
        <dict>
                <key>Inject</key>
                <dict>
                        <key>ATI</key>
                        <false/>
                        <key>Intel</key>
                        <true/>
                        <key>NVidia</key>
                        <false/>
                </dict>
                <key>RadeonDeInit</key>
                <true/>
        </dict>

動作を確認

上で説明した3つの方法を全部試して見ました。どれも問題なく動きましたので、一番シンプルなRadeonDeInitを使う方法で動かすことにしました。

「システム情報」でチェックしてみると、正しく認識されているようです。Metalにも対応しています。Geekbench 4でのOpenCL Scoreは145000前後でした。他でも報告されている程度の妥当な成績なので、正しく設定できていると思います。

なお、しばらく使用していると性能が低下して、ベンチマークスコアが50000くらいになってしまうことがありました。色々試して見たところ、Intel CPU内蔵GPUをマザーボードの設定で無効にしていると性能低下が発生するようです。内蔵GPUはセカンダリーに設定して使用しない場合でも、有効にしておくのが良いようです。

一方、SafariでYoutubeなどの動画を再生すると、再生がカクカクして滞ったり、場合によってはハングすることが発生しました。Google Chromeでは問題が出ません。以前、Intel HD Graphicsを使って同様な不具合が発生した経験があり、その時は、IntelGraphicsFixup.kextとLilu.kextの組み合わせで解消しました。今回も、これで改善しました。ただし、IntelGraphicsFixup.kextとLilu.kextは最新版を使うのが良いです。古いバージョンだと改善しません。この不具合は、CPU内蔵GPUを無効にしても、同様に解決しますが、上記で述べたような性能低下が発生します。

ということで、正しく動作させるために

Intel CPU内蔵GPUは有効にしておく
IntelGraphicsFixup.kextを使う

のが良いようです。

モデル名の修正

「システム情報」や「このMacについて」を見て、ちょっとだけ気になるところがあります。モデル名が実際のカードと違うことです。例えば、RadeonDeInitを使った場合、AMD R9 xxxとなりました。他の方法の場合や、別のブランドのRX 580では別のモデル名になることもあるようです。AppleのExternal Graphics Development Kit に搭載されているのと同じSAPPHIRE PULSE RADEON RX 580を使えば、Radeon RX 580という表示になるという情報もあります。

でも、これは見た目だけの問題で、気にしなければどうでも良いことのようです。どうしても直したかったら、担当しているドライバにパッチを当てます。以下でも紹介した手法でパッチを当てます。

光学ドライブを使う

AMD 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セクションに書き込みます。例えば、以下のようになります。

                <key>KextsToPatch</key>
                <array>
                <dict>
                        <key>Comment</key>
                        <string>Rename AMD R9 xxx</string>
                        <key>Find</key>
                        <data>QU1EIFI5IHh4eA==</data>
                        <key>Name</key>
                        <string>AMD9500Controller</string>
                        <key>Replace</key>
                        <data>QU1EIFJYIDU4MA==</data>
                </dict>
                </array>

ちなみに文字列をBase64へ変換するには、ターミナルで次のようにすれば良いです。

$ echo -n "AMD R9 xxx" | base64
QU1EIFI5IHh4eA==
$ echo -n "AMD RX 580" | base64
QU1EIFJYIDU4MA==

これでモデル名がそれっぽく表示されるようになりました。

おまけ：現行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として使えると思われます。

Sonnetの互換GPUリスト (10.13.2以降)

Hackintoshの作り方（総集編:10.13版）

Sun, 26 Nov 2017 20:16:38 +0900

macOSをインストールする方法をご紹介してきたのですが、多数の記事に分散してしまっています。そこで、macOS 10.13 High Sierraをインストールする際に参考になる記事へのポインタをまとめた総集編を作ってみました。10.14 Mojaveについては以下をご覧ください。

Hackintoshの作り方（総集編:10.14版）

手順の概要を把握する

こちらは9TO5MacのライターのJeffさんのビデオです。テンポよく紹介されていますので、全体の流れを確認するのに良いと思います。

/posts/121/

/posts/131/

ハードウェアを用意する

Hackintoshを作るためには、互換性のあるハードウェアを自由に選んで組み合わせられる自作PCが、問題が少なく楽です。ノートPCなども可能ではありますが、上級者向けだと思います。CPUは、今の最新Mac実機が採用しているKaby Lakeもしくは

Hackintoshのパーツ選び【その1：CPU編】

発売されたばかりの最新のCoffee Lakeが良いと思います。多少、チャレンジングですが、将来のことを考えたら最新Coffee Lakeで組んでおくのが良いと思います。

Coffee Lake-SでmacOS

そうすると、マザーボードは、CPUに合わせて200シリーズか300シリーズを選ぶことになります。

Hackintoshのパーツ選び【その2：マザーボード編】

/posts/97/

グラフィックスカードはNVIDIAかAMDでしょうが、どちらも長短あります。少し前は、互換性、ドライバの提供、性能の点からNVIDIAがお勧めだったのですが、最近のmacOSではAMDの互換性が上がっています。詳しくは以下を参考にしてください。

HACKINTOSHのパーツ選び【その3：グラフィックス編】10.14以降版

/posts/36/

/posts/90/

無線アダプタ、SSD, そのほかのパーツについても紹介しておきました。

/posts/138/

Hackintoshのパーツ選び【その5：SSD】

Hackintoshのパーツ選び【その6：その他】

マザーボードのBIOS/UEFIを設定する

マザーボード (BIOS) 設定

必要なソフトウェアを入手する

Clover EFI bootloaderとefiドライバー

“Clover EFI bootloader”で検索します。以下が本家かと思われます。

https://sourceforge.net/projects/cloverefiboot/

こちらでも最新版が配布されています。

github.com

Cloverをダウンロードすると、インストーラ、efiドライバ、テーマファイルなども一緒に入手できます。

kext類

RehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket

Mac上で導入用のUSBメモリを作る

/posts/93/

Cloverインストールの手順はこちらにも書いてあります。

Cloverインストーラの設定

config.plistの例を示して、説明しました。

config.plistの実例紹介

config.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。

正しく機種設定する (SMBIOSの設定)

対象マシンをUSBメモリで起動してmacOSを導入する

このUSBメモリを、インストール先のマシンに挿して起動させます。起動しない場合は、Cloverの設定やkextの選定を確認します。

USB 3.0/3.1のUSBメモリを使った場合、Cloverの選択画面は現れるけど、そのあとのプロセスで失敗することがあります。macOSにはUSBの個数に制限があり、3.0/3.1のポートが2.0としてしか動かない場合があるからです。対応方法は以下の記事の「ポートを増やすパッチ」をご覧ください。

USBポートを設定する

ただ、USB 2.0でしたら確実に起動しますので、

USB 2.0のUSBメモリを使う
マザーボードのUSB 2.0専用ポートを使用する（全部が3.0/3.1の最近のマザーボードではこの手法は使えないです）
USB 2.0ハブを経由して無理やり2.0にする

などで対応するのが簡単です。2.0なのでインストールに時間がかかる欠点はあります。

無事起動したら、インストール先のSSD/HDDをGUIDパーティションとHFSジャーナリングでフォーマットします。次に、macOSインストーラを起動して、High Sierraをインストールします。インストール先ボリュームがSSDの場合は、ファイルシステムが自動的にAPFSに変更されるかもしれません。

macOSのインストール途中で、何度か再起動することがあります。その場合は、USBメモリから起動して、”Boot macOS Install from (インストール先のボリューム名)”という項目を選びます。

対象マシンにCloverを導入する

インストールが終了したら、またUSBメモリのESPから起動して、Cloverの選択画面でインストール先のmacOSを選択して起動します。この後、Cloverインストーラを起動して、インストール先にCloverを入れます。この手順は、先のUSBメモリにCloverを入れたのと同じ作業です。すでに動いているUSBメモリのESPをコピーしても良いです。SierraのHackintoshをHigh Sierraにアップデートする方法をこちらに書いておきましたので、ESPのコピーを行う方法の参考になるかと思います。

HackintoshをHigh Sierraにする

macOS環境を整える

USBに入れたCloverとkextで、最低限の起動は行えるようになっているはずです。さらに、グラフィックスカード、Ethernet, サウンドの設定をします。以下の記事が参考になるかと思います。

/posts/90/

Ethernetを設定する

/posts/120/

High Sierra導入用USBメモリ作成方法

Fri, 24 Nov 2017 14:10:36 +0900

このページは古いmacOS用の情報です。有用ではありますが、最新macOSに関する情報は以下をご覧ください。

Catalina導入用USBメモリーを作成する

今一番よく使われるHackintoshの作成方法は、以下のステップです。

Step 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をインストールしています。

よく紹介される手法では以下のような戦略でCloverをインストールしています。つまり、Step 2のUSBメモリへのインストールでは、できるだけ汎用性を持たせた設定にして幅広いマシンで起動できるようにします。一方、Step 4では、対象マシンに合わせたチューニングを施して性能を引き出します。

例えば、Tonymacx86で配布されているUniBeastは、Step 1, 2を自動化するツールですが、緩いチューニングで多くのハードウェアでとりあえず起動させることを目指しています。そのあと、インストール対象マシン上でMultiBeastツールを動かして、細かいチューニングをする手順を採用しています。この過程で、起動しなくなることも多いです。インストール対象マシンで試行錯誤を繰り返す手法では、起動不能になった場合、USBインストーラのESPからmacOSを再起動し、インストール先のESPの修正を行い、修正したESPを用いて起動する作業を繰り返します。修正と再試行のために、合計2回、macOSを起動し直すには時間がかかります。またとりあえず起動できるだけのmacOSでは画面が低解像度だったりネットに接続できないなどの不便さもあります。

そこで、Step 2の段階でインストール先マシンに合わせたチューニングを行うことを考えました。Step 2のインストールでチューニングを行えば、起動失敗したらUSBメモリーを実機に戻して修正すれば、再起動の手間は半減します。また、実機の整った環境で効率よく作業できます。ということで、Macintosh信者らしく実機を活用して、ある程度ちゃんとしたチューニングを目指したmacOSインストール用USBメモリーを作ってみます。

(1) App StoreからHigh Sierraを購入する

無料です。ダウンロードするとインストーラが起動しますが、これは中断します。/Applicationsの中にmacOS High Sierraインストール.appというアプリケーションができているはずです。5GB以上のサイズです。

(2) USBメモリを用意してフォーマットする

USBメモリーを用意します。容量は最低で8GB必要です。でも8GBと表記されている製品でも、ギリギリ足りないこともあります。その上の16GBにしておけば確実です。さらに上の32GBくらいになると、インストーラじゃなくてmacOSそのものをインストールできます。ただしUSB 2.0の速度で起動すると、かなり時間がかかります。

ディスクユーティリティ.appを起動して、USBメモリを、GUIDパーティションマップで、Mac OS拡張（ジャーナリング）フォーマットで初期化します。名前は、後で自動的に改名されてしまうので、ここでは適当で構いません。ここではUSBとしました。

(3) macOSインストーラをUSBメモリに入れる

macOSをクリーンインストールするために、インストール用ドライブを作成する機能, createinstallmediaが用意されています。ターミナルから、以下のようにタイプします。

$ sudo /Applications/Install\ macOS\ High\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/USB

これはUSBメモリがUSBという名前でマウントされている場合の例です。確認のプロンプトの後、しばらく時間がかかってインストール用USBメモリーが出来上がります。

名前もInstall macOS High Sierraに変わっています。ここで作成したUSBメモリーは、実機で起動して、macOSのクリーンインストールに使用することができます。オプションキーを押しながら実機を起動して、このUSBメモリで正しく起動できることを試しておきましょう。ここまでの手順はAppleのサポートページでも紹介されています。

macOS の起動可能なインストーラを作成する方法

(4) 必要なファイルを入手する

Cloverとkextファイルを入手しておきます。いずれも、その名前を使って検索すると、ダウンロードサイトが見つかります。kextについては、こちらの記事を参考にしてください。

/posts/126/

Clover EFI Bootloader

macOSを起動するブートローダです。

sourceforge.net

FakeSMC.kext

必須のkextです。MacにはSystem Management Controllerというサブシステムがあり、これのふりをしてくれるのがFakeSMC.kextです。RehabManさんがメンテナンスしてくれているダウンロードサイトです。

RehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket

Lilu.kext

これを使ってパッチを当てるkextを使う場合に必要なkextです。以下で解説しておきました。ダウンロード先も以下をご覧ください。

/posts/118/

グラフィックスkext (Intel用)

CPU内蔵のiGPU (Intel HD Graphics) を使う場合には、IntelGraphicsFixup.kextを使います。必須ではありませんが、いくつかの不具合を直してくれます。Lilu.kextが必要です。

sourceforge.net

グラフィックスkext (NVIDIA用)

NVIDIAのGeforceを使う場合には、NvidiaGraphicsFixup.kextを使います。SMBIOSで設定する機種によってはこれがないとブラックスクリーンになってしまい、表示が出ません。Lilu.kextが必要です。

sourceforge.net

グラフィックスkext (AMD用)

**追記：**10.13.4から、Appleの外部GPUボックス推奨のAMDグラフィックスカードを使う場合は、何もせずそのまま使えるようになりました。なので、以下に紹介したWhateverGreen.kextも不要です。(2018/4/12)

AMDのRadeonを使う場合には、WhateverGreen.kextを使います。これを使わないとプライマリディスプレイにならず、ブラックスクリーンになります。Lilu.kextが必要です。

github.com

そのほかのkext

必須ではありませんが、LAN用のkext, オーディオ用のkext, USB設定のためのkextがあっても良いです。後から用意しても良いですが、LAN用は早い段階で欲しいかもしれません。

Ethernetを設定する

/posts/120/

USBポートを設定する

(5) Cloverをインストールする

こちらに詳細に説明しておきました。

Cloverインストーラの設定

この手順でインストールを行います。選択する項目は以下です。

インストールボタンを押せばインストールが終了します。

インストールが終了した段階で、EFIという名前のボリュームがマウントされています。その中の、CLOVERフォルダに、先ほど指定したOsxAptioFix2Drv-64.efiなどが入っています。

Cloverインストール直後は、EFIがマウントされています。しかしEFIボリュームは通常はマウントされないので、手動でマウントする必要があります。こちらで説明しておきました。

ESPをマウントするためのシェルスクリプト

(6) kextをUSBメモリに入れる

用意したkextをUSBメモリのESP (EFI System Partition) に入れます。CLOVERの中のkextsというフォルダに、バージョン番号のディレクトリがあります。使いたいmacOSのバージョンに合わせたフォルダに入れます。Otherフォルダに入れたkextは、いずれのバージョンでも使われます。通常は、数字の方か、Otherかのいずれかを使います。

ここでは、macOS High Sierra用に10.13フォルダにkextを入れてみました。AMDグラフィックス搭載マシンを想定してWhateverGreen.kextが入っています。

(7) apfs.efiを入手してUSBメモリに入れる

macOS High Sierraからシステムのファイルシステムが、従来のHFS+からAPFSに変更されました。インストール先がUSBメモリだったりHDDだとHFS+のままですが、SSDだと自動的にAPFSに変換されます。USBメモリ内のインストーラを起動するだけなら関係ないですが、SSDにインストールされたmacOSを起動する場合はAPFSにアクセスできる機能が必要になります。Clover、というか一般にブートローダは、OSが起動する前に、ドライブからブートのためのファイル（例えばカーネルなど）を読み込む必要があるからです。この機能は、High Sierraに入っているapfs.efi で行えます。

まずはHigh Sierraインストーラの中にあるBaseSystem.dmgをマウントして、その中のusr/standalone/i386を開きます。

$ 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にコピーします。

(8) config.plistを編集する

ESPのCLOVERの中には、デフォルトで作成されたconfig.plistが入っています。これをconfig_def.plistのようにコピーしておきます。ちなみに、Cloverの起動画面で、configXXXX.plistのような名前のファイルから起動に使うファイルを選ぶことができます。config.plistについてはこちらで解説しておきました。

config.plistの実例紹介

デフォルトのconfig.plistはこんな感じになっています。

[XML] Clover config.plist – Pastebin.com

結構ややこしくて長ったらしいです。多くはコメントアウトされた記述です。XMLのコメントアウトは書きにくいのか、ここではkeyの名前に#をつけています。#をつけて、ありえない名前にすることで、無視されるようにしているようです。例えば、DisableDriversと書くべき以下の部分を、

DisableDrivers
CsmVideoDxe
VBoxExt4

#DisableDriversと以下のように書くことで、

#DisableDrivers
CsmVideoDxe
VBoxExt4

この部分をコメントアウトするのと同等の記述をしています。後からこの記述が必要になった時は、#を外せば良いのです。ただ、このようにコメントアウトされている箇所は、必要性の低い場所です。なのでほとんど削除することができます。

また、他にも必要性の低い場所があります。昔のマザーボードやハードウェアで必要とされていたものの、現在のマザーボードなどではほとんど不要であったり、むしろ不具合を引き起こしたりする記述が多くあります。それらを削除すると簡単になります。

(9) SMBIOSを設定する

デフォルトのconfig.plistでの機種設定は暫定的な設定です。実際には、インストール先のマシンに合わせて、しっかりと設定する必要があります。こちらに詳しい内容を説明しておきました。

正しく機種設定する (SMBIOSの設定)

こうして、コメントアウトされた部分を消して、不要な設定を消して、SMBIOSを設定した例を以下に示します。

[XML] Customized config.plist – Pastebin.com

(10) USBメモリで起動する

このUSBメモリをインストール対象マザーボードにさして、UEFIで起動ドライブに設定して、起動させます。以下のようなCloverの画面が出てくるはずです。デフォルトはクリスマスになっていました。ここまでは、Cloverをインストールすれば問題なく行き着くはずです。

なお、USBメモリが3.0である場合（多分、この容量のメモリはほとんど3.0じゃないでしょうか）USB 2.0のポートを使うと安全です。というのはUSBの個数制限で、macOSの起動後にUSB 3.0がアクセスできなくなり、止まってしまう可能性があるからです。2.0は遅いですが仕方ないです。生きている3.0もあるはずなので、ポートを抜き差しして、それを探しても良いです。USBの個数制限に関してはこちらの記事を見てください。

DSDTを変更してUSBポートを選別する

(11) macOSを対象マシンで起動することを確認する

この後、macOSのインストーラの起動が始まります。macOSのインストーラ画面が出れば無事終了です。現実には、途中で止まってしまうことも多いかと思います。その場合は、ブートオプションに-vをつけてエラーメッセージをみてください。Couldn’t allocate runtime areaというエラーを出して停止している場合は、OsxAptioFix…を別のものに差し替えてみてください。ここで何度か試行錯誤の作業が必要になるかと思います。とても運が良ければ、一回で起動できるかもしれません。

この先は、通常の実機でのmacOSクリーンインストールと同じ手順です。すなわち、インストール先のドライブをディスクユーティリティでフォーマットし、macOSをインストールします。何度か再起動することがありますが、その場合は、Cloverのブートドライブ選択画面でBoot macOS Install from…という項目を選びます。

macOSのインストールが終了したら、一旦はUSBメモリで起動して、起動項目でインストールしたばかりのmacOSドライブを選択します。そしてCloverをインストールし、USBメモリのESPの内容を、新しいmacOSドライブのESPにそのままコピーすれば、Hackintoshが完成です。

Clover画面から不要項目を除外

Fri, 10 Nov 2017 13:33:52 +0900

Cloverの起動画面には、起動選択項目がアイコンで並んでいます。この項目に、選んでも何もおきない項目が現れることがあります。その理由と、不要な起動項目を消す方法を書いておきます。

Boot macOS Install from xxxの項目を消す

macOSのインストールの過程でこの項目が出るようになります。

正常にインストールが終了するとこの項目は自動的に消えるのですが、何かの手違いがあると残ってしまいます。インストール途中だと判断されてこれがデフォルトで選択されてしまうこともあります。また、次に上書きインストールをすると、これが多数現れることになり、どれが本物か分からなくなります。ターミナルから以下のようにタイプすると消えます。

sudo rm -R /Volumes/xxx/.IABootFiles

.IABootFilesは.で始まる隠しディレクトリなので、ls -aじゃないと見つかりません。このディレクトリの中のcom.apple.Boot.plistを見るとインストールのために使用するInstallESD.dmgとかBaseSystem.dmgへのパスが書いてあります。大昔にインストールした名残だとすると、その場所にはもう無いので当然のことながら起動に失敗します。

Boot macOS install from xxx – Dataの項目を消す

Catalinaからメインの起動ボリュームが2個の論理ボリュームに分割されて、xxx – Dataというボリュームが追加されました。xxxはMacintosh HDのような起動ボリューム名です。- Dataの方には、変更できる内容が入り、従来の- Dataが付かない方には書き換えては困るシステムのデータが入っています。

この方式では、インストール用のデータはxxx – Dataの方にはいるようで、インストールに失敗するとBoot macOS install from xxx – Dataという項目が居残ってしまいます。これの消去方法をコメントでSuperBypassさんから教えていただきましたので以下に追記しておきます。つまり、/System/Volumes/Dataの中にmacOS Install Dataというディレクトリがあるので、これを消去すれば良いようです。こちらが参考になるそうです。

ただ、この中にあるLocked FilesというディレクトリがSIPでアクセス禁止されていますので、SIPを解除して、sudoで/System/Volumes/Data/macOS Install Dataを消去します。

xxx from Prebootの項目を消す

こちらは単なる見た目の問題です。

APFSになってから、Recoveryに加えて、Prebootというパーティションが起動項目に新たに加わって煩雑になりました。下の例は、メインのSSDに加えて、バックアップ用のHDDを接続したマシンのClover起動画面です。SSDにはAPFSフォーマットでMacintosh SSDというパーティションが作ってあり、High Sierraがインストールされています。メインのSSDに関係する起動選択肢は右の4個です。

4個の起動項目には、以下の名前が付いています。

Boot FileVault Prebooter from Preboot
Boot macOS Installer Prebooter from Preboot
Boot macOS from Macintosh SSD
Boot Recovery from Recovery

APFSになってから、Recoveryに加えて、Prebootという選択肢が起動項目に新たに加わって煩雑になりました。

追記：最近、FileVault関係の起動メニューは現れていません。CloverのFileVault関連のEFIドライバを入れないことにしているのが関係しているかもしれません（2018/12/15)

diskutil listコマンドでこのSSDを見ると次のようになっています。

/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コンテナの中に作られた仮想的なボリュームで、それぞれが記憶領域を共有していて追加・削除が簡単です。

APFSのVolumeを活用する

PrebootというAPFSボリュームは起動時の作業に使用するボリュームのようです。Prebootの名前のついた起動メニューを選択して起動しても、結局は本体のシステムが起動するようです。選択肢に表示される意味がないので、非表示にしてみましょう。

使わない起動選択肢を非表示にして、起動画面をスッキリさせることは、config.plistの記述で簡単に行えます。config.plistのGUIセクションに、Hideというキーを用意して、

        <key>GUI</key>
        <dict>
                <key>Hide</key>
                <array>
                        <string>Preboot</string>
                </array>

とすれば、Prebootボリュームに含まれる起動オプションは表示されなくなります。（1項目だけなのでarrayにする必要はないかもしれませんが、サンプルがarrayでしたし、将来増やしたいときのためにarrayにしておきました。) 結果がこれです。

必要な選択肢だけが表示されるようになりました。他にも表示から外したい選択肢があったらconfig.plistのHideの項にで挟んで追記していけば良いです。Hideの項で消してしまった項目を選択したくなった場合は、Clover選択画面でF3キーを押します。隠されたボリュームも表示されるようになります。

更新：Prebootボリュームを削除する手法を削除しました。(2018/12/15)

パワーマネジメントを設定する

Wed, 01 Nov 2017 14:02:02 +0900

MacintoshのCPUには電力管理(パワーマネージメント)の機構が搭載されていて、CPUの負荷が下がるとクロック周波数を下げて、消費電力を削減します。Intel Power Gadgetでその様子を確認できます。大抵のマシンでは、特段の設定をしなくても、クロック周波数が変動して電力管理が実施されます。

Intel Power Gadget

以下は、初代Intel NUCのDC3217IYEでの例です。CPUはIvyBridgeのCore i3モデル、3217Uです。真ん中のグラフがクロック周波数です。電力管理がされていないために、クロック周波数が定格近くの1.7GHzに張り付いて一定になっています。車に例えたらアクセル踏みっぱなしのフルスロットルで運転しているような状態です。

デスクトップ向けのCPUで自作すると、特別な処置をしなくても大抵は正しく電力管理されていて、クロック周波数のグラフは負荷に応じて変動することが多いです。実機ではこのCPUシリーズのi5モデルである3317UがMacBookAir5,1で採用されてますが、i3 3217Uを採用した機種はありません。その関係でCPU情報がOSに登録されてなく、電力管理が効いていないと思われます。

そんな時はPikeさんが作ってくれたスクリプトを動かしてSSDT.amlファイルを作ると改善することがあります。

GitHub - Piker-Alpha/ssdtPRGen.sh: Script to generate a SSDT for Power Manage…

まずは、ここからssdtPRGen.shというスクリプトをダウンロードします。そしてこれをターミナルで実行します。すると、~/Library/ssdtPRGen/にSSDT.amlができています。これをEFI/CLOVER/ACPI/patched に入れて再起動します。

DSDTについてはこちらで説明しましたが、

DSDTを編集する

SSDTはDSDTの補足ファイル、サブセットのような位置付けです。DSDTの一部を補足したり、書き換えたりする内容のようです。Pikeさんのスクリプトは、使用しているCPUに合わせて、電力管理に関する記述を作ってくれます。

この結果、Power Gadgetの様子は、以下のようになりました。

真ん中のグラフが示すように、CPUのクロック周波数が、負荷により変化して、省電力を実現しています。電力消費のグラフは一番上です。3.9WだったCPU消費電力が2.8Wに下がっています。クロック周波数が減少しているので、その分、省電力が達成できています。一番下のグラフに表示されている温度も、7度近く下がりました。

Coffee Lake-SでmacOS

Sat, 28 Oct 2017 14:57:59 +0900

新しいCPUが2017年11月2日発売

インテルのメインストリーム向け新デスクトップCPU、Coffee Lake-Sシリーズの国内販売が決まったようです。以下の6種類が11月2日に発売されます。

Products	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で採用されると予想されます。今回注目されていることは、コア数が増えたことです。今までずっと、

Core i7は4コア8スレッド、
Core i5は4コア4スレッド、
Core i3は2コア4スレッド

の構成が踏襲されてきましたが、今回は、

Core i7は6コア12スレッド、
Core i5は6コア6スレッド、
Core i3は4コア4スレッド

となり、久々のコア数増強です。AMDの新CPUがコア数重視なことに対抗しての結果と思われます。Kaby Lakeの時と売り出し価格は同程度なので、コア数増えたことでお得感があります。今回発売されるi7, i5, i3のそれぞれに、オーバークロック対応のKモデルと、無印のモデルがあります。K付きモデルはこの他に、無印と比べてクロックがより高い、TDPが高いという特徴があります。

CPU搭載iGPUは、今までのKaby LakeがIntel HD Graphics 630だったのに対して、Intel UHD Graphics 630になりました。しかし、多少クロックが上がったくらいで、内部的な設計やEU数はKaby Lake-S世代と何ら変わっていないそうです。iGPUに関しては、Kaby Lakeと同様の互換性で、macOSのスリープ復帰に多少問題が出るかと思います。

新CPUに対するHackintosh対応

過去の例を見ると、CPUが新しくなった時に、どれくらいHackintosh対応できるかどうかは、様々でした。

Haswell/BroadwellからSkylakeに移行した時は、コミュニティの皆さんが割と手こずっていた感じでした。最初はカーネルパニック連発で、なかなか起動せず、iMacがSkylakeを搭載した後も、しばらく不安定でした。安定したのは、MacBook系での採用が進んで、OSが十分に対応してからでした。CPUが発売されてから半年くらい時間がかかったと思います。

一方で、SkylakeからKaby Lakeの移行は、スムーズでした。 CPU IDとiGPU IDを古いSkylakeに偽装するだけでKaby Lakeは問題なく動き、Kaby Lake搭載iMacが出たタイミングのmacOS 10.12.6 で、偽装も不要になりました。

今回のKaby LakeからCoffee Lakeへの移行は、さらにマイナーチェンジだと言われています。CPUピンの割り当てが1本変更されたので、マザーボードの互換性は皆無ですが、チップセットはほとんど同じと言われています。iGPUにも違いはほとんどありません。

Coffee Lake-SでmacOS

実際に動作したという報告が、多数上がっています。Geekbenchにもベンチマークが上がっています。増えた全コア・スレッドがちゃんと認識されるようです。コア数が増えたので、Kaby Lakeに比べてマルチコアのスコアが目に見えて上昇しています。

Coffee Lake-Sを使う方法は簡単で、FakeCPUIDで 0x0906E9 にして、Kaby Lakeに偽装するだけで可能とのことです。Clover Configurator.appを使うならKernel and Kext PatchesのFakeCPUIDに0x0906E9を書き込みます。

config.plistを手作業で書き換えるなら、

<key>KernelAndKextPatches</key>
<dict>
<key>FakeCPUID</key>
<string>0x0906E9</string>

のようにKernelAndKextPachesのセクションにFakeCPUIDを書き込みます。iGPUはKaby Lakeと比べて大きな違いがないので、偽装する必要はないようです。

追記：FakeCPUIDをしなくてもHigh Sierraで動くようです。ただ、不明のCPUという表示になるようです。http://www.insanelymac.com/forum/topic/328819-hs-on-8700k-coffee-lake/
追記：MojaveになってCPU名も不明にはならなくなったようです。

Core i3ではiGPUが動かない？

こちらの報告によると、

www.tonymacx86.com

i3-8100ではIntel UHD Graphics 630が動かないそうです。i3-8100のiGPUのDevice IDは3E91で、i5-8400, i7-8700Kなどは3E92で、3E92のUHD 630じゃないとグラフィックス加速が効かないとのことです。iGPUを使う場合はi5以上を選ぶべきかもしれません。

新規に自作するならCoffee Lake-S

Kaby Lakeの時と同じく、iMacにCoffee Lakeが搭載されてmacOSが対応したら、FakeCPUIDを偽装する記述は不要になるはずです。ということで今現在、新規にHackintoshを組むならCoffee Lake-Sで作った方が良いと思われます。本物のMacintoshで未採用の最新6コアCPUを使えるというのはHackintoshの醍醐味ではないでしょうか。

HP 6300 Pro / HP 8300 Elite, Ivy Bridge

Thu, 26 Oct 2017 13:08:00 +0900

メーカ製のデスクトップを買うよりも自作をした方が、カスタマイズが自由で、良い部品を選べて、満足なコンピュータが手に入ると思っています。なので、メーカ製デスクトップPCには実のところあまり興味がないです。でも古いモデルが、格安で売られていたり、廃棄されていたりしたら、macOSを入れてみたくなると思います。

追記：フォーラムで教えていただきましたが、こちらの記事の方が新しくて、MultiBeastを使わない方法でオススメです。

ということで、tonymacx86に最近出ていた記事を読んでみることにしました。こちらです。

この記事では、HPのデスクトップPCであるHP 6300 ProとHP 8300 Eliteを対象にしています。Ivy Bridge時代の製品のようです。Amazonで調べたら、安いところでは1万円台で中古販売されているようです。

こちらのビデオでも、公共機関払い下げ品のHP 6300 Core i5モデルを$30で入手してmacOS Sierraをインストールしています。後述のように一部のモデルのiGPUはmacOSでサポートされていません。そこでGTX 750Tiを中古で買い、さらに中古HDD, 壊れたと勘違いされたSSDを追加購入して、合計で$70だそうです。

www.youtube.com

ということで、以下は、上のmacosx96の記事の抄訳です。

Step 1. ハードウェア構成をチェック

入手してWindowsがインストールされていたら、とりあえず起動して、間違いなく動くWindowsの元で、ハードウェアに不具合がないか確認します。CPUのグリスを塗り替えるのも良いでしょう。グラフィックスカードを取り付ける予定なら、ここで装着してテストしておくのも良いです。Intel HD4000を搭載したCPUが載っているなら、オンボードの映像出力（VGAを除く）が使えます。Intel HD2500はmacOS Sierraでサポートがありませんので、i3-3220やi5-3470などのHD2500搭載CPUの場合は、グラフィックスカードが必須です。

訳注：Wikipedia (Intel HD Graphics – Wikipedia)によるとHD2500とHD4000を搭載したデスクトップむけCPUは以下です。

**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を買うと良いです。

Step 2. BIOSをアップデートする

F10キーを押しながら起動してBIOSメニューに入り、BIOSバージョンを確認します。v02.83だったらv02.99 Rev. Aにアップデートします。この後、最新の03.04にアップデートしても良いけど必須ではないです。BIOSアップデートにはWindows上のツールか、BIOSメニューにあるツールを使います。

Step 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ですね。

Step 5. USBメモリー上にUnibeastインストーラを作る

訳注：createinstallmediaコマンドとCloverで作っても良いと思います。ここからの3ステップは、いつもの手順です。こちらもご覧ください。

/posts/121/

Step 6. USBメモリから起動してmacOSをインストール

Step 7. MultiBeastの設定

Step 8. config.plistを編集する

Clover Configuratorを使います。

DSDTパッチで、EHC1 を EH01 に、また、EHC2 を EH02に変更します
HD4000を使う場合はInject Intelをします
SIPを0x67にします（訳注：バニラなインストールするなら不要です）
Nvidia Web Driverを使うならNvidiaWebをtrueにします

CPUパワーマネジメントを設定しても良いです。CPUに応じたssdt.amlを使います。

Step 9. HDMIオーディオとアナログオーディオを有効にする

GT 710、1030、GTX 1050、1050 Tiなどを使っているなら、VoodooHDA 2.9.0 kextとAppleHDADisabler kextを使うとよいです。CPU内蔵のHD4000グラフィックスを使う場合も同様です。（訳注：/L/Eに入れろと書いてありますが、ESPで良いと思います）フロント右側のヘッドフォン端子が機能するはずです。左側は動きません。リアパネルの緑色の出力端子と入力端子も、動きます。VoodooHDA.prefPaneアプリケーションを使うと、システム環境設定で設定できるようになります。

いくつかのNVIDIAカードのHDMIオーディオは動きません。2.9.0 kextが動かなかったらVoodooHDA 2.8.8 kextを試すとうまくいくこともあります。アナログオーディオを使うには、AppleHDADisabler kextを忘れず使ってください。

もし、アナログオーディオが動かなかったらUSBアダプタを買うのが良いです。

訳注：こちらもどうぞ

/posts/120/

Step 10. iMessageとFaceTimeを動かす

iMessageとFaceTimeは、ちゃんと設定すれば動きます。
訳注：こちらも試してください。

iMessageを動かす

ダウンロードファイル

元の記事には、以下のファイルが添付されています。

HP.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)

DSDTを変更してUSBポートを選別する

Sat, 21 Oct 2017 13:19:56 +0900

追記：DSDTの編集例としてのUSB個数制限の回避を説明します。USB個数制限を回避するには、こちらの方法をお薦めします。

15個制限を回避するUSBInjectAll.kextの役割と使用法

DSDTの役割、取得方法、コンパイルの方法、更新方法をこちらで紹介しました。

DSDTを編集する

今回は、簡単な例でDSDTを書き換えるハッキングを試してみます。機能を追加したり、修正するのは難しいですが、機能を削るのなら簡単です。

USBポートを設定する

上の記事では、必要なUSBポートを機能させるために、不使用のUSBポートを除外する方法を説明しました。この記事では、DSDTを書き換えて同じことを実現してみます。

稼働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本あることになります。

このマザーボードでmacOSを動かして、IORegistryExplorer.appで認識されたUSB一覧を見てみます。すると、機能しているUSBポートは、以下の通りでした。HSはHigh Speed、SSPはSuper Speed PlusでそれぞれUSBの速度のモードです。HSがUSB 2.0で、SSPはUSB 3です。

つまり、USB 2.0が14本、USB 3が1本見えています。USBの本数が15本と言う制限があり、2.0から先に稼働した結果です。先の記事では、USBInjectAll.kextを使って、不使用のポートを除外して、必要なポートを生かしました。これをDSDTの書き換えでやってみます。

未使用のUSBをDSDTから削除する

USBの使用状況を調べたところ、HS04はどのコネクタにも接続されていませんでした。チップセットには搭載されているけど、配線されていないようです。そこでこれをDSDTから除外してみます。DSDTのソースを見て、HS04で検索します。するとDeviceの記述でアドレスを定義しているらしい箇所が見つかりました。まずはこれをコメントアウトしてみます。

コンパイルしたらエラーが出ました。

ScopeにもHS04に関する記述があるようです。これもコメントアウトします。長いのですが、/**/を使って自動コメントされた箇所があるので、頑張って行頭の//でコメントアウトします。

コンパイルしたら、成功しました。これで作成したDSDT.amlをEFI/CLOVER/ACPI/patchedに入れて、使用して、起動してみます。結果はこうなりました。

無事、未使用のHS04がリストから除外されているのが確認できます。また、15個制限の1個が空いたので、USB 3のポートの一つ、SSP2が新たに有効になりました。

この方法を、他にも使用していないポートに対して実施していけば、15個制限の中に、実際に使用しているポートを全て含めることができます。USBInjectAll.kextなどの追加のkextや、config.plistへのパッチが不要です。ある意味、一番根本的な解決方法です。

DSDTを編集する

Sun, 15 Oct 2017 00:26:18 +0900

DSDT (Differentiated System Description Table) はマザーボードがOSに対して提供するACPI規格に基づく情報です。これを通して、マザーボードの電源イベントに関する情報や、マザーボードが備えている機能、構成部品などの情報を提供します。このテーブルは、メーカーによってマザーボードのファームウェア上に用意されています。

Linux で ACPI の機能が使えないというのはよくある問題です。例えば、ファンが稼働しない、フタを閉じたときに画面がオフにならない、などの問題が発生します。これらの問題は DSDT が Windows しか考えずに作成されているのが原因で、インストール後にDSDTを書き直して（パッチを当てて）修正できます。

Hackintoshの場合、マザーボードがUEFIになってからは、MacintoshのEFIとの差が少なくなったのか、DSDTを改変しなくても動作するようになりました。ただ、ノートPCなどのパワーマネージメントが特殊なハードウェアの場合は、まだDSDT改変が必要です。また、DSDTを書き換えることで、macOSの動作を調整することも可能です。ということで、DSDTの改変のための基本的な手順を紹介します。有用な改変例は、折に触れて、紹介していければ良いかと思っています。

DSDT情報の差し替え手順

DSDTはAML (ACPI Machine Language)というプログラムのようなデータ形式で記述されます。通常は、マザーボードがAMLをOSに提供します。マザーボードとOSの中間に割り込んだCloverは、マザーボードに代わって、本来あるものとは別のAMLをmacOSに渡すことができます。config.plistで

<key>DSDT</key>
  <dict>
      <key>Name</key>
      <string>DSDT.aml</string>
  </dict>

と設定してあれば、

EFI/CLOVER/ACPI/patched/DSDT.aml

の場所・名前のファイルに記述されたAMLがmacOSに渡されます。

DSDTを改変する基本的な手順は、以下です。

マザーボードが提供しているDSDTをDSDT.amlファイルとして入手する
これを逆コンパイルしてDSDT.dslというテキストファイルを作る
DSDT.dslに変更を加える
DSDT.dslをコンパイルしてDSDT.amlを作る
DSDT.amlをEFI/CLOVER/ACPI/patchedに置き再起動する

以下で、この手順の詳細を説明します。

バニラなDSDTを入手する

HackintoshでmacOSが動いている状態では、CloverやHackintosh用kextがすでにDSDTを改変している可能性があります。この状態のDSDTを元に改変を進めると、将来のバージョンのCloverやkextで問題が生じる可能性が高いです。トラブルがあった場合の原因の切り分けも困難になります。そこで、マザーボードが提供しているそのままの（バニラな）DSDTを元に、改変を加えるのが良いです。

Cloverやkextが動く前のDSDTを入手するためには、いくつかの方法があります。シンプルなLinux起動DVDや、MS-DOS起動USBメモリを使って起動して、DSDT.aml取得プログラムを動かして入手することもできます。でも、最近のCloverには、DSDT.aml取得機能がありますので、これを使うのが一番簡単です。Cloverの起動ドライブ選択画面で、F1を押すとヘルプが出ます。

これにあるようにF4を押すと、EFI/CLOVER/ACPI/origin/にDSDTを取得してくれます。実際に実行すると、25種類のファイルがここに保存されます。この中の、DSDT.amlが必要とするファイルです。

MaciASL.appで逆コンパイルする

DSDT.amlは、インテルが提供しているASLコンパイラでコンパイルできます。このコンパイラの機能をGUIから操作して、逆コンパイル、編集、コンパイルなどの機能を全部やってくれる便利なツール（シンプルなIDE: 統合開発環境）がいくつか提供されています。定番は、MaciASL.appです。最新版はこちらで入手できます。

Releases · acidanthera/MaciASL

MaciASLを起動すると、いきなり.dslの情報が表示されます。これは、現在macOSが動いている状態でのDSDTです。なのでCloverなどがすでに改変した後のDSDTです。そこで、前の節で入手したバニラなDSDT.amlを読み込ませます。すると、これを逆コンパイルして人が読める形になった.dsl形式のテキストが表示されます。

MaciASL.appでコンパイルする

改変する前に、逆コンパイルされた.dslのテキストが、正しくコンパイルできることを確認します。逆コンパイルしたものを、そのままコンパイルするのですが、大抵の場合は、エラーが出ます。逆コンパイルが完璧でないことが原因のようです。エラーの一覧が表示されるので、それをクリックするとエラーの箇所を示してくれます。

私の手元の環境では、こんな2個のエラーが出ました。最初のエラーをクリックすると、Zeroという変数の行でした。

プログラムの流れと関係なく唐突に0という変数が出てきたので、エラーを出しているようです。おそらく、元のデータの余白に0が埋め込まれていて、それがそのまま逆コンパイルされたのではないかと思います。

この行だけをコメントアウトすると次の行で同じエラーが出ます。Zeroはかなりの数、続いています。そこでこれを全部コメントアウトします。

2個目のエラーも、Arg0という変数が唐突に現れたことが原因のようです。これもなんかの事情で埋め込まれた意味のない0のようです。

これも（こちらは1行だけでした）

// Arg0

などとしてコメントアウトします。Returnの後の行なので、絶対に到達しない部分ですので、削除して構わないはずです。

その結果エラーはゼロになりました。警告が多数出ていますが、これは無視して大丈夫です。めでたくコンパイルできました。コンパイルエラーは、マザーボードによって違うと思います。でもソースを見ていれば、なんとなく対処法がわかるかと思います。

ファイルメニューから、「Save As…」などを選び、現れるファイルダイアログで、ASLとAMLで保存できます。AMLファイルが、最終的に必要とするファイルですし、次回もこれから逆コンパイルして作業することができます。ただ、コメントなどは消えてしまうので、ASL形式でも保存しておくと良いです。

MaciASL.appで編集する

ASLが表示されているメイン領域で、自由に編集できます。結構使いやすいです。また、パッチするための手順だけが配布されていることがあるのですが、それを読み込む機能などがあります。

DSDT改変で、実際にどんなことができるのかは、今後の記事で、試しながら紹介していきたいと思います。

例えば以下ではUSBの項目を削除してみました。

DSDTを変更してUSBポートを選別する

USBポートを設定する

Sat, 30 Sep 2017 22:25:18 +0900

追記：この記事ではUSBの15個制限を簡易的に回避します。本気で対応するには、この記事の方法よりも、以下をお薦めします。

15個制限を回避するUSBInjectAll.kextの役割と使用法

この記事の結論を先に書いておきます。

15個の制限を外すパッチと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相当になってしまうこともあります。その対策について説明します。

何も対策しない場合のUSB構成

まずは、何も対策しないとどうなるかを見て見ましょう。IORegistryExplorer.appなどのツールを使うと、macOSから見たハードウェア構成がわかります。ちなみに表示される情報は、Cloverのパッチや各種kextが機能した後の結果で、マザーボードのUEFIが提示しているオリジナルの構成ではありません。

mac.softpedia.com

IORegistryExplorer.appを起動して、右上の虫眼鏡アイコンのところに、xhcと入力します。するとXHC関係の情報が現れます。XHCの下にHS01やSSP1と見えているのが、現在OSが認識しているUSBポートです。HSはHigh Speed、SSPはSuper Speed PlusでそれぞれUSBの速度のモードです。HSがUSB 2.0で、SSPはUSB 3です。

全く対策しない状態の手元のマザーボード(MSI Z97A Gaming 7)では、以下のような結果になりました。

USB 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に接続されているので、読み書きできます。）

解決策1：15個の制限を取り払う

解決策の一つは、上限15個の制限を外すパッチを当てることです。次の手順で15個の制限を外して、チップセットに接続された全てのUSBポートを使用できます。

config.plistにポート数を増やすパッチを当てる
USBInjectAll.kextを使用する
2.の両方を実施する必要があります。片方だけではダメです。この解決策の問題点は、パッチパターンがmacOSのバージョンごとに異なることです。パッチは、macOSの該当するバージョンにしか効きません。今使っているmacOS用のパッチが見つからない場合は、解決策2に進んでください。

ポート数を増やすパッチ

まずは、AppleUSBXHCIPCI.kextに以下のパッチを当てます（ New USB Raise Port Limit Patch for High Sierra | tonymacx86.com より）。

<dict>
<key>Comment</key>
<string>Change 15 port limit to 24 in XHCI</string>
<key>Find</key>
<data>g32MEA==</data>
<key>Name</key>
<string>AppleUSBXHCIPCI</string>
<key>Replace</key>
<data>g32MGw==</data>
</dict>

これは10.13 PB1をインストールした100シリーズマザーボード用のパッチと書いてありましたが、正式版10.13でZ97チップマザーボードでも動きました。

一方で、10.13.4からは違うパッチを当てないといけないようです。

www.insanelymac.com

後にも書きましたが、ポート数を増やすパッチはmacOSのマイナーバージョンごとに違っています。マイナーアップデートの都度対応する必要があり、お勧めの方法ではないです。

USBInjectAll.kextを使用

次にUSBInjectAll.kextをEFI/CLOVER/kexts/Otherもしくはバージョン番号のフォルダに入れます。

RehabMan / OS-X-USB-Inject-All / Downloads — Bitbucket

この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のポートがあることがわかります。

config.plistへのパッチ当てとUSBInjectAll.kextを使った結果を以下に示します。

このように、全てのUSBポートが使えるようになっていることがわかります。これで、順番の最後尾に並んでいたUSB 3も全て機能します。簡単に全USBを使えるように設定できました。tonymacx86で配布しているMultiBeastというインストールツールは、この手法を使っています。

実際に使っているUSBポートを特定する

上記の解決策で、全部のUSBが使えるようになります。簡単ですが、多少問題があります。まずは、そもそもmacOSが何らかの理由で15個に制限しているのに、その上限を増やしてしまって大丈夫なのかという懸念です。今のところ問題点は報告されていませんが、将来、何らかの副作用が出てくる可能性は否定できません。もう一つは、パッチの内容が、OSのバージョンやチップセットによって変わるらしいことです。今回のHigh Sierraへの移行にあたっても、パッチが更新されました。Sierraの時のパッチでは、上限を回避できないようです。この先のバージョンアップでも対応が必要になると思われます。

一方、USBInjectAll.kextは、名前は、「全てのUSBポートをインジェクトする」ですが、実際には、一部のUSBポートを遮断する機能があります。たとえば、もともとある20個のポートのうち、任意のポートを指定して、使用しないよう設定することができます。実際に使用しているポートだけを15個選んで設定すれば、15個の上限を外す必要は無くなります。そうすればconfig.plistに素性の良くないパッチを書き込む必要がなくなります。USBInjectAll.kextの方は、RehabManさんによってこまめに更新されているので、今後も安心して使用できます。

使用しないポートを除外するためには、実際に使っているUSBポートを特定する必要があります。ちょっと大変な作業ですが、マザーボードの構成を把握できるので、達成感はあります。それぞれのポートの番号は、

それぞれのポートにUSB機器を接続し、
IORegistryExplorer.app の表示の変化を確認する

ことで、特定できます。下の例は、とあるUSB 3ポートにUSB 3.0メモリを挿入してみたところです。SSP5のport-statusが、最初は0x0だったのですが、下の図のように0x1400に変化しました。（kUSBBusCurrentAllocationの値も変化しました。）これで、このポートはSSP5だということがわかります。このポートに、USB 2.0のデバイスを接続すれば、USB 2.0端子の番号もわかります。

こうして手元のマザーボードを調べて見ました。各ポートの番号は以下のようになっていました。

HS01 基板上の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モジュールに接続しているので、これを無効にするとキーボードもトラックパッドも使えなくなります。不明とあるポートは発見できませんでした。マザーボード上で配線されていないのかもしれません。

解決策2：使うポートを15個以下に選別する

行方不明のポートを使うことはありませんし、マザーボード上で接続していない端子のポートも当分は使いません。これを考えるとUSBポートを15個以下に絞り込むことができます。上の例では、HS04, HS07, HS08, HS12, HS13, SSP4は除外して良いです。

USBInjectAll.kextに除外するポートを伝える方法は、いくつかあるようですが、最も簡単なのは、Cloverのブートオプションで伝える方法です。HS04, HS07, HS08, HS12, HS13, SSP4を除外したい場合は、config.plistのBootキーの中にあるArgumentsキーに、

<key>Boot</key>
<dict>
 <key>Arguments</key>
 <string>uia_exclude=HS04;HS07;HS08;HS12;HS13;SSP4</string>

と書いておけば良いです。もしもすでに他のオプションが書いてあったら、空白で区切って追記します。例えば-vが書いてあって

<string>-v</string>

これを残したかったら、以下のようにします。

<string>-v uia_exclude=HS04;HS07;HS08;HS12;HS13;SSP4</string>

このconfig.plistで起動した結果を以下に示します。使用している14個のポート、HS01, 02, 03, 05, 06, 09, 10, 11, 14およびSSP1, 2, 3, 5, 6が機能していることがわかります。これなら15個未満ですので、config.plistへのパッチは不要です。

解決策3：DSDTを変更してUSBポートを選別する

こちらの記事でDSDTの変更でUSBポートを選別する方法を書いておきました。

DSDTを変更してUSBポートを選別する

iMessageを動かす

Thu, 28 Sep 2017 23:11:19 +0900

Hackintoshの完成度を評価する目安は色々あります。例えば、起動するかどうか、画面が出るか、音が出るか、LANに接続できるか、WiFiが動くか、iPhoneと連携できるかなどあります。中でも、iMessageが動くかどうかは機種情報が正しく設定できていることの目安になります。

iMessage騒動

2014年の8月に、多くのHackintoshが、iMessageに繋がらなくなりました。「カスタマーコード」が表示され、iMessageサポートに連絡せよというダイアログが出て、締め出されて（ロックアウト）しまったのです。サーバ管理者側でセキュリティポリシーが変更されたことなので、具体的にどうなったのか知る由もありません。でもHackintoshコミュニティが手探りで試し尽くしたところ、機種ID、ロムとメインロジックボードのシリアル番号情報が、接続ごとに変動したり、フォーマットが正しくない場合に接続できないらしいとわかりました。

2014年のセキュリティ強化はあまりに過激すぎたのか、Appleサポート掲示板を見ると、本物のMacユーザにも支障が出ていたようです。セキュリティはその後、緩んだり厳しくなったりして、11月頃には、とうとう実機のシリアル番号じゃないと接続できなくなったこともありました。でも2015年の2月のバレンタインデーに、突如チェックが緩和され、ロックアウトが発生しなくなりました。それでも、シリアル番号やボードシリアル番号などは、設定機種に合った正しいフォーマットのデータを継続的に使用することが良いとされています。間違った設定を行っても、ロックアウトには至らなくなりましたが、接続できない問題が発生するようです。

en0に設定する

iMessageに限らず、Appleのネットサービスを利用するためには、EthernetもしくはWi-FiのBSD装置名がen0である必要があります。実機がそうなっているからです。en0になっていないと、iMessageは使えませんし、App Storeへの接続でもエラーが出ます。

以下の記事でも紹介していますが、

Ethernetを設定する

以下のファイルを消して再起動すれば良いです。

/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
/Library/Preferences/SystemConfiguration/Preferences.plist

また、en0があってもこれの状態がBuiltinになっていないと接続できないことがあるようです。コメントで教えていただきました。こちらに説明があります。これの対処法も、上記のファイルを消して再起動すれば良いようです。

シリアル番号類を正しいフォーマットで設定する

先のiMessage騒動の時に、iMessageに認められる正しいシリアル番号のフォーマットが、コミュニティの協力で調べられました。その結果が、Clover Configuratorの自動生成機能に組み込まれています。なので、これを利用して、正しい情報を設定しておけば良いです。以下の記事で紹介しておきました。

正しく機種設定する (SMBIOSの設定)

注意すべき点は、一回設定したら、継続して使い続けることです。iMessageにログインするたびに機種情報が変動すると、不正な利用とみなされて接続できなくなる場合があるようです。

iMessageへの接続失敗を無かったことにする

以前にiMessageにログインしようとして失敗したことを無かったことにするためには、以下のファイル/ディレクトリを消して再起動すると良いそうです。

~/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

ただし、ロックアウトが発生していた時は、ローカルの記録をいくら消去しても無駄でした。失敗した記録は当然ですがサーバ側にも残っているようです。

そのほかの条件

大抵の場合は、en0にすることと、SMBIOSで機種情報を正しく設定することで、iMessageを利用できます。それでも、接続がうまくいかなくて苦労している人もいるようです。ネット上にはたくさんの対処法が紹介されています。わかりやすいガイドには以下があります。

www.tonymacx86.com

www.youtube.com

iMessageのメッセージが届かないとか、遅延するなどの問題も報告されますが、実機を使っても、同様なことが発生します。なので、実はHackintoshの問題ではなく、iCloud / AppleID自体のトラブルである可能性も高いです。

また、古くからのApple IDユーザのアカウントであったり、クレジットカードを登録しているアカウントは問題を起こしにくいという噂もあります。本当かもしれませんし、都市伝説みたいなものかもしれません。さらには、最近はApple IDが2ファクタ認証に移行しつつあります。2ファクタ認証しているApple IDは従来よりセキュアなので、その結果ロックアウトされにくいように思います。何れにしても、サーバ側でどのように運営しているかは謎ですし、そのポリシーも変化していると思われます。

HackintoshをHigh Sierraにする

Tue, 26 Sep 2017 12:18:21 +0900

Sierraで動いているHackintoshなら移行は簡単

High Sierraが出ました。HackintoshはOSのバージョンアップの時に設定がダメになって苦労する、と思い込んでいる人も多いかもしれません。でも、最近はとても簡単になりました。マイナーバージョンアップ（例えば10.12.5から10.12.6へのバージョンアップ）なんて、App Storeからダウンロードしてクリックするだけです。実機と同じです。今回のようなメジャーアップデート（10.12から10.13）は、いろいろと対応する必要がある場合もあります。でも、今年は楽勝の部類でした。

ということで、すでにSierraで動いているHackintoshをHigh Sierraにアップデートする方法を書いておきます。ここで紹介する手順は、別ドライブを用意してそこにHigh Sierraをインストールする手順です。

Sierra版の現状の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移行にとりかかってください。

Step 0: macOSをバニラな状態にしておく

簡単に移行するための前提です。こちらで解説して置きましたのでごらんください。

/posts/131/

つまり、macOSが入っているパーティションの内容には一切手を加えないで、実機と全く同じ状態にしておけば、アップデートは簡単になるということです。

Step 1: 旧バージョンSierraのHackintoshを最新にしておく

ここからが作業本番です。Hackintoshコミュニティのハッカーの方々は、High Sierraに向けて更新してくれています。なので、移行前に、最新にしておきましょう。最新にすることでSierraが動かなくなることはありません。最新にしてもSierraがちゃんと動くことを確認してきましょう。

まずはCloverを最新にします。今日現在ではリビジョン4220が最新のようです。システム環境設定に登録してある場合は、「更新を確認」するだけです。
kextを最新にします。kextの名前でGoogle検索すると配布サイトが出てきますので、最新版に差し替えておきましょう。
kextをEFI/CLOVER/kexts/10.12に入れている人は、10.13を新たに作ってコピーするか、Otherフォルダにコピーしておきます。

詳しくはこちらをご覧ください。

あと13日！High Sierraのお迎え準備

Step 2: config.plistのSMBIOS情報を最新にしておく

OSとしてのHigh Sierraの一番の変更点は、ファイルシステムがHFS+からAPFSに移行することです。High Sierraのアップデートでは、APFSでも起動できるようにファームウェアもアップデートされます。Hackintoshにとっては関係のないことですが、ファームウェアが対応版にアップデートされていないと判断されると、インストールが止まってしまうようです。そこでconfig.plistのSMBIOSセクションのBIOSバージョンの記述を、最新版ファームウェアと同じバージョン番号に書き換えます。

詳しい手順は、これもこちらをご覧下さい。

あと13日！High Sierraのお迎え準備

Step 3: High Sierraを別ドライブにインストールする

ここまでのステップで準備がしっかりできたので、ここから先は簡単です。

High Sierraをインストールするドライブを接続します。SSDでもHDDでも良いです。USB接続でも良いです。自作の人なら、余っているドライブをSATAケーブルでマザーボードに接続しても良いですね。

このドライブをディスクユーティリティでフォーマットします。フォーマットは、GUIDパーティションマップとHFS+ (Mac OS拡張ジャーナリング）とします。SierraのディスクユーティリティではAPFSを選択できません。が、ここでHFS+でフォーマットしても、SSDの場合は、この後のインストールで自動的にAPFSに変換されます。

Apple App StoreからHigh Sierraインストーラをダウンロードして、このドライブにインストールします。インストール途中で再起動することがあります。その場合は、現行のドライブで起動して、Cloverのメニューからインストール途中と思われるドライブを選択します。「Boot macOS Install from XXXX」というのがインストール途中にだけ現れるボリュームで、これを選択します。

途中の起動回数は、いつもは1回の気がしましたが、今回は2回のようでした。たまたまかもしれませんが、もしかしたらファームウェアをアップデートする作業（Hackintoshでは無駄な作業ですが）があったのかもしれません。もしくは、APFS変換の関係なのかもしれません。

インストールが終了したら、やはり、再起動します。インストール途中の再起動なのか、インストールが終了した後の再起動なのかは、先ほどの「Boot macOS Install from XXXX」というボリュームの有無で判断できます。Cloverの選択画面にこれがなくなっていれば、インストールは終了しています。

インストーラがHFS+でHigh Sierraをインストールした場合、Cloverのボリューム選択にHigh Sierraが現れていると思います。High Sierraを起動しても良いのですが、ここは、ぐっと我慢して次のステップに行きましょう。APFSに変換された場合は、High Sierraが現れていないと思います。次のステップで対応します。

次のステップでは、まずは古いSierraのドライブを選択して起動します。

Step 4: 最新版のAPFSドライバapfs.efiをESPに入れる

2018/06/19更新：Clover 4558からApfsDriverLoader.efiというドライバができて、apfs.efiの機能を自動的にロードしてくれるようになりました。なので、 /usr/standalone/i386/ からapfs.efiを取り寄せてESPに置く以下の作業は不要になりました。記録のために残しておきます。

High Sierra Public Betaの初期のバージョンでは、HFS+でのインストールがメニュー選択で可能でした。しかし、正式版をSSDにインストールする場合は、自動的にAPFSフォーマットに変換されるようです。HDDやFusion driveの場合はHFS+のままのようです。

Clover、というか一般にブートローダは、OSが起動する前に、ドライブからブートのためのファイル（例えばカーネルなど）を読み込む必要があります。なので、ファイルシステムにアクセスできる必要があります。この機能は、High Sierraの

/usr/standalone/i386/apfs.efi

で行えます。そこで、このファイルを、CloverのESPにコピーします。それを行わないと、APFSでフォーマットされたHigh Sierraを起動できません。そこで、APFSブートには以下のステップが必須です。

APFSでインストールした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に入っている最新版を使うのが良いでしょう。

High Sierraは起動しましたでしょうか？うまく起動すれば、ユーザ設定などの画面に進み、ログインできます。ここまでくればもう安心です。

Step 5: High SierraのドライブにCloverをインストールする

このステップは飛ばしても良いです。

現行のドライブのCloverからHigh Sierraのドライブが無事起動できて、アカウントなどの設定が終わったら、Cloverのインストーラを起動して、新しいドライブにCloverを入れます。このとき、ESPにインストールするよう指定します。

Step 6: 現行のESPからファイルをHigh SierraのESPにコピーする

High SierraのESPには、とりあえずインストールしたClover関連のディレクトリができているはずです。前のステップを省略すると、できていないかもしれません。何れにしても、古いSierraのドライブのESPの内容を、新しいHigh SierraのESPにコピーして、同じ内容にします。ファインダーからのドラッグ&ドロップで作業しても問題ありません。これで、High Sierraのドライブを起動ディスクにしても、ちゃんとHigh Sierraが起動するはずです。

次のStep: メインドライブのアップデート

これで無事、別ドライブで起動できましたでしょうか。問題なければメインドライブもアップデートしましょう。このステップと同様に、今度は、High Sierraのドライブから、メインドライブにインストールしていけば良いです。上書きインストールでも、いっそすっきりとフォーマットしてのクリーンインストールでもどちらでも良いと思います。Time Machineでバックアップとってあれば、クリーンインストールの後で移行することもできます。

補足

SMBIOSのデフォルト設定

Clover r4179以降では、config.plistで以下の値：

BiosReleaseDate
BiosVersion
FirmwareFeatures
FirmwareFeaturesMask

を指定しなくても、機種モデルの最新の値がデフォルトで設定されるようになったという情報もあります。実際にBiosVersionを削除して見たところ、それでも最新の値が使われていました。Step 2の作業の代わりに、これらの指定を単に削除して、Cloverのデフォルトに任せるのも可能かと思われます。

http://www.insanelymac.com/forum/topic/304530-clover-change-explanations/page-4#entry2482211

apfs.efiを入手するもう一つの方法

上記の説明では、High Sierraをインストールした後で、apfs.efiを入手しています。インストールする以前の、Install macOS High Sierra.app (日本語名は macOS High Sierraインストール.app)から取り出すこともできます。.appの中の

Install\ macOS\ High\ Sierra.app/Contents/SharedSupport/BaseSystem.dmg

にあるBaseSystem.dmgを開いてマウントします。次に、

/Volumes/OS X Base System/usr/standalone/i386/apfs.efi

の場所にあるapfs.efiを手に入れます。これで、Step 3の段階でapfs.efiを入手してESPに入れることができ、すぐにHigh Sierraから起動できます。

パッチを当てるkext: Lilu.kext

Sat, 23 Sep 2017 23:09:00 +0900

Lilu.kextはkext (カーネル拡張)にパッチを当てる仕組みを提供するkextです。ライブラリやプログラムにもパッチを当てられるようですが、kextにパッチを当てるために便利に用いられています。今年になってから登場した新しいkextです。元々は、サウンドを提供するkextであるAppleALC.kextを開発していた人が、パッチ当ての部分を分離して公開してくれたものです。なので、現在のAppleALC.kextもLilu.kextを使っています。

Releases · acidanthera/Lilu

Lilu.kextはパッチを当てるkextと一緒に使います。バニラな構成ならば、それぞれをEFI/CLOVER/kextsのOtherもしくは該当するバージョンのフォルダに一緒に入れます。Cloverもconfig.plistのKextsToPatchセクションの記述でkextにパッチを当ててくれます。この記述は簡単なのですが、kext本体のバイナリーファイルにしかパッチを当てられません。Lilu.kextは、パッチ方法を指定するkextを開発する必要がありますが、kext本体以外の様々なファイルや設定にパッチを当てられるようです。

以下で、Lilu.kextと一緒に使うためのkextを紹介します。

AppleALC

macOSのHD audio機能を使って音を出すためのパッチ。こちらで説明しました。

/posts/120/

古いバージョンは単独で動きますが、パッチ当て機能をLilu.kextに分離した後のバージョンは、Lilu.kextと一緒に使います。

Releases · acidanthera/AppleALC

WhateverGreen

~~10.12.6からRX480/580などのAMDグラフィックスカードがサポートされました。しかし、メインディスプレイにはならず、起動時にはCPU内蔵GPUなどの補助GPUが必要でした。これを解決するのがWhateverGreen.kextです。Radeonを使う人には必須です。~~以前はAMDグラフィックスカードの不具合に対応するkextでした。それでAMDカラーのgreenという名前が付いています。今は、

IntelGraphicsFixup
NvidiaGraphicsFixup
Shiki

の機能を統合し、ディスプレイに関係するパッチ機能をすべて盛り込んだkextになりました。詳しくは以下をご覧ください。これを入れれば統合されてしまったkextは使う必要がありません。

NvidiaGraphicsFixup

このkextはWhateverGreenに統合されました。

NVIDIAのGPUをiMac15,1 iMac17,1 MacPro 6,1のシステム設定で使おうとすると、ブート後に画面が黒くなって起動しなかったり、画面がスリープしたりする問題が発生します。 WebドライバだけでなくmacOS標準のドライバでも発生します。 iMacのレティナディスプレイやProのデュアルグラフィックスカードハードウェアを前提とした macOSの設定が、この問題を引き起こしているようで、black screen問題と呼ばれています。このkextを使うと、black screenを回避できます。

Releases · lvs1974/NvidiaGraphicsFixup

IntelGraphicsFixup

このkextはWhateverGreenに統合されました。

~~Intel HD Graphicsを使う場合に発生する以下の不具合を解決します。~~

~~Intel Graphics HD4000以降のブートロゴ表示の乱れ~~
~~Intel Azul Graphics (HD4400, HD4600)におけるPAVPフリーズ問題~~

ブートロゴの乱れは、起動時のアップルロゴとプログレスバーが表示される場面の後半で、表示が8個に分裂してストライプ状になる現象です。起動時だけのことで、無視しても良いくらいの問題ですがこれが解決されます。もう一つのPAVPフリーズ問題はもっと深刻で、一部の動画サイトをSafariで閲覧する場合や、iTunesでiTunes Storeの予告編を見る場面で、動画再生が滞ったり、場合によってはOSがフリーズする問題です。

Releases · lvs1974/IntelGraphicsFixup

Shiki

このkextはWhateverGreenに統合されました。

iTunesにあるDRM保護されているビデオはivy bridge以降で再生できない問題があります。購入した映画や、その予告編を再生しようとすると、映像が出ないとか、音だけしか出ない状態です。これを回避します。

Releases · acidanthera/Shiki

NightShiftUnlocker

10.12.4から導入されたNight Shift機能ですが、これにはMacBookPro9,x iMac13,x Macmini6,x MacBookAir5,x MacPro6,x MacBook8,x以降の機種が対応しています。これより古い機種でNight Shiftを動かすためのkextです。

Releases · 0xFireWolf/NightShiftUnlocker

そのほか

用途・効果を理解できていないのですが、Lilu.kextのサイトによると、このほかにも以下のようないろいろなパッチがあるようです。

AirportBrcmFixup Broadcom Airport Wi-Fi cardsへのパッチ

AzulPatcher4600 Intel HD 4600 へのパッチ

CoreDisplayFixup 非Iris Intel graphicsの高解像度サポート

CPUFriend 動的なパワーマネージメント

EnableLidWake ラップトップで蓋を開けた時のIntel Graphicsスリープ解除対応

HibernationFixup 3モードと25モードのハイバネーション対応

config.plistの実例紹介

Thu, 21 Sep 2017 22:07:11 +0900

長ったらしくてわかりにくいconfig.plistの書き方を、簡単に説明してみます。config.plistはCloverの設定をxml形式で書いたテキストファイルです。そのマニュアルは、Clover Wikiで公開されています。

https://clover-wiki.zetam.org/Configuration#Config.plist-structure

ただ、ここで十分に説明し尽くされていない項目も多く、分かりにくいです。Cloverは、長い間、様々な世代のCPU、チップセット、GPU、周辺機器をサポートしてきて、それに対応した機能を提供してきました。それらを全てconfig.plistで設定しているので、わかりにくくなるのも仕方ありません。古いシステムに関連している設定項目などは、もはやそれが実装された経緯を知らない人も多いはずです。

ということで、実際に動いているconfig.plistを例に、最新のハードウェアに関した項目だけに絞って説明してみます。下に示したconfig.plistの例はMSI Z97Aマザーボードで動いている設定です。デフォルトの設定、最新ハードウェアには無関係な部分などを削除しているので、割と短くてわかりやすいかと思います。9シリーズチップセットのマザーボードの例ですが、UEFIのマザーボードならこのconfig.plistでだいたい動くと思います。

https://pastebin.com/FkCTZEvq

以下でセクションごとに説明していきます。

ACPI

config.plistの冒頭に書かれているのはACPIセクションです。ACPIはAdvanced Configuration and Power Interfaceの略で、マザーボードの電源機能と構成要素を列挙し管理する統一された枠組です。DSDT (Differentiated System Description Table) は、マザーボードごとに固有の電源管理と構成を記述したデータです。SSDT (Secondary System Description Table)は、DSDTの補足データで、DSDTの一部を記述したデータです。SSDTには、DSDTの一部の記述をして、DSDTの内容を上書きします。

DSDTは全てのマザーボードが持っています。Hackintoshのコミュニティによって、DSDTに足りない記述を書き足したり、書き換えたりして、macOSを動かす努力が長年されてきました。昔のBIOSベースのマザーボードの時代には、それぞれのマザーボードBIOSバージョンごとに、改変されたSSDTが作られて、それを使ってmacOSをインストールしていました。config.plistのACPIセクションのDSDTとSSDTは、マザーボードが持っているACPI情報をどのように改変すべきかを書いた場所です。動的にパッチを当てるCloverの重要機能を指定しています。

MSI Z97Aマザーボードで動かすconfig.plistのACPIセクションを下に示します。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>ACPI</key>
 <dict>
 <key>DSDT</key>
 <dict>
 <key>Name</key>
 <string>DSDT.aml</string>
 </dict>
 <key>SSDT</key>
 <dict>
 <key>Generate</key>
 <dict>
 <key>CStates</key>
 <true/>
 <key>PStates</key>
 <true/>
 </dict>
 </dict>
 </dict>

重要機能の割には、シンプルです。というのも、UEFIマザーボードの時代になって以来、DSDTを変更しなくても、ほとんどそのままで動くようになったからです。なのでDSDTへのパッチ当ての指示は全て削除することができます。Nameでは、将来、手作業でDSDTにパッチ当てをしたいときに備えて、パッチを当てたDSDTファイルの名前を入れてあるだけです。なので、この記述も実は不要です。ちなみに、パッチを当てたDSDTファイルは、CloverのACPI/patchedディレクトリに入れます。

Generateでは、CPUの電源制御のCステートとPステートを用意するよう指定しました。これが必要なのかどうかよくわかっていませんが、多くのconfig.plistでこの指定がしてあるので、ここでも使いました。

またDSDT項目名を変更するパッチも必要に応じて書きます。こちらで説明しておきました。

config.plistでDSDT項目名を変更するパッチ

Boot

Bootの設定です。

 <key>Boot</key>
 <dict>
 <key>Arguments</key>
 <string></string>
 <key>DefaultVolume</key>
 <string>Macintosh HD</string>
 <key>Timeout</key>
 <integer>1</integer>
 <key>XMPDetection</key>
 <string>NO</string>
 </dict>

Argumentsは、Cloverがブートするときのオプションです。-vとか-xとか色々あります。また、kextが引き取ってくれるオプションもここに書きます。普通の起動にはオプション不要なので、この項目も不要です。でも、将来何か指定したいときのために、空のstringを書いておきました。

DefaultVolumeは、起動ボリューム名です。Timeoutは、Cloverのメニューが出てからユーザ入力を待つ時間です。この指定では、1秒後に自動的に起動します。XMPDetectionは、よくわかりません。eXtreme Memory Profileという機能を使うかどうかの設定です。使わないことにしています。

Devices

 <key>Devices</key>
 <dict>
 <key>Audio</key>
 <dict>
 <key>Inject</key>
 <string>1</string>
 </dict>
 <key>UseIntelHDMI</key>
 <false/>
 </dict>

Audioでは、オーディオチップのレイアウトの1番を使うよう指定しました。AppleALC.kextがこの値を使います。詳しくはこちらをご覧下さい。

/posts/120/

HDMIは使っていないのでUseIntelHDMIは、無しでも良いのですが、将来のためにfalseを入れておきました。

GUI

Cloverの起動画面の設定です。

 <key>GUI</key>
 <dict>
 <key>Language</key>
 <string>en:0</string>
 <key>Scan</key>
 <dict>
 <key>Entries</key>
 <true/>
 <key>Tool</key>
 <true/>
 </dict>
 <key>ScreenResolution</key>
 <string>1920x1200</string>
 <key>Theme</key>
 <string>Minimalism</string>
 </dict>

Scanは、ボリュームやUEFIツールのスキャンをするかどうか。Themeは、画面表示の色やアイコンなどの見た目の選択です。Cloverのthemesフォルダの中から、使用したいテーマのディレクトリ名を指定します。

Graphics

AMD, Intel, NVIDIAのGraphicsに関する指定です。

 <key>Graphics</key>
 <dict>
 <key>Inject</key>
 <dict>
 <key>ATI</key>
 <false/>
 <key>Intel</key>
 <true/>
 <key>NVidia</key>
 <false/>
 </dict>
 </dict>

AMDは使っていないのでfalseに、またNVIDIAの最近のモデルはfalseで良いとのことでそうしました。
デフォルトでは3社ともtrueだそうですが、必要に応じて自動設定されるそうなので、ここでは何も書かなくても良かったのかもしれません。

KernelAndKextPatches

Kernelとkextへのパッチ指定です。起動時に動的にパッチを当ててくれます。これもCloverの重要機能です。

 <key>KernelAndKextPatches</key>
 <dict>
 <key>AppleRTC</key>
 <true/>
 <key>KernelPm</key>
 <true/>
 <key>KextsToPatch</key>
 <array>
 
(省略)
 
 </array>
 </dict>

AppleRTCを当てないと、スリープでUEFI設定が消えてしまいます。KernelPmはHaswellの電力制御のパッチです。不要かもしれないけど、Z97チップセットマザーボードなので、念のために入れておきました。以上は定番のパッチです。

パッチ作業を具体的に指定したパッチを記述することもできます。それがKextsToPatchのセクションです。そういうものが必要ならば（省略）と書いた部分に書きます。以下に光ドライブのスリープ対応のパッチを紹介しました。参考にしてください。

光学ドライブを使う

RtVariables

Runtime 変数というセクションです。Cloverの機能を指定するパラメータを書くところのようです。あまり使い道がありません。

 <key>RtVariables</key>
 <dict>
 <key>CsrActiveConfig</key>
 <string>0x0</string>
 </dict>

ここではSIPを有効にするよう指定しています。多分デフォルトで有効だと思いますので、この記述は不要だと思います。でも、将来、無効にしたいときのために書いておきました。SIPとCsrActiveConfigの値については、こちらをご覧下さい。

/posts/132/

siroanko.hatenablog.com

SMBIOS

機種固有情報を書くセクションです。40行以上あるので省略しました。シリアル番号、ファームウェアのバージョン番号などを書きます。

 <key>SMBIOS</key>
 <dict>
(省略)
 </dict>

Clover configuratorを使うと、機種に合わせた値を生成してくれます。それのSMBIOSセクションをここにコピーペーストすれば良いです。詳しくは、こちらをご覧下さい。

正しく機種設定する (SMBIOSの設定)

SystemParameters

最近追加されたセクションです。

 <key>SystemParameters</key>
 <dict>
 <key>InjectKexts</key>
 <string>YES</string>
 <key>NvidiaWeb</key>
 <true/>
 </dict>
</dict>
</plist>

InjectKextsは、/EFI/CLOVER/kexts/に置いたkextを使うかどうかの指定です。自動的に検出するDetectという指定も可能ですが、明示的に指定した方が安心です。

NvidiaWebは、NVIDIAが配布しているドライバを使用するかどうかの指定です。昔は、ブートオプションで指定していましたが、Sierraからここで指定することになりました。

音を出す

Wed, 20 Sep 2017 20:05:42 +0900

Hackintoshで音を出すためのアプローチは、いくつかありますが、ここでは、一般的で簡単な3つの方法を難易度の低い順に紹介します。それぞれの作業量は、

何もしない
kextを1個入れる
kextを2個入れてconfig.plistを1項目追加する

です。

USBオーディオを使う

マザーボード搭載のオーディオチップを利用せずに、外付けの音源でデジタルアナログ変換するアプローチです。USB接続のDAC (デジタルアナログ変換器)を搭載した、スピーカ、アンプ、アダプターなどを接続するだけです。USBの標準的なオーディオ再生プロファイルを使うので、OSレベルでサポートされています。なので、特別のドライバーは不要で、何の手を加えなくても、音が出ます。ちなみに、Bluetoothスピーカも同様な仕組みで音が出ますので実機と同様に動きます。

USBオーディオ製品には、USBポート直結の安いDACがあります。手軽に試せて、実現できます。いくつか購入しましたが、どれもHackintoshで問題なく使用できました。ただスリープ復帰時にボツッというポップノイズが出る製品もありました。手元の環境でたまたま調子の良かったのは、この1,000円未満の製品でした。

USB DAC内蔵スピーカーも各種あります。これもいくつか購入しましたが、中でもこちらの製品は価格の割に良い音でした。

さらに手軽な値段のDAC内蔵アンプも多数あります。これをちゃんとしたスピーカに接続したらかなり良いオーディオ環境を実現できます。ピュアオーディオマニアが使うようなもっともっと高価な機器も使えます。

VoodooHDA.kextを使う

VoodooHDA.kextは、AppleのオーディオドライバであるAppleHDA.kextを置き換えることを目的に開発されているオープンソースのオーディオドライバです。これ単体で機能するドライバで、設定などがほとんど不要で、自動的にオーディオチップを検出してくれてすぐに機能します。一時は、クラッシュを引き起こすとか、音質が悪いとか言われていましたが、最近使ったところでは安定しているし、気になるような音質の問題もありませんでした。JeffさんのビデオでもVoodooHDA.kextを使っています。

**追記：**とあるマシンでVooDooHDA.kextを使っていると音割れがひどいことに気づきました。調整をしてくれるアプリケーションなどもあるので、それで頑張ると良いのかもしれません。でも次節で紹介するAppleALC.kextに替えたら音割れは起きなくなりました。VooDooは簡単ですが環境によっては合わない場合があるようです。(2018/6)

/posts/121/

VoodooHDA.kextをダウンロードして、ESPにあるCloverのEFI/CLOVER/kextsのOtherもしくは、該当するバージョンのフォルダに入れます。これだけで機能します。ESPに入れることでmacOSをバニラなままに保てます。

AppleALC.kextとLilu.kextを使う

3番目の方法は、昔から行われている伝統的な方法で、AppleHDA.kextに何とかオーディオチップを認識させようという方法です。そのために、AppleHDA.kextにパッチを当てたり、config.plistに必要な設定を書き込んだり、インジェクターkextを作ったり、こういう作業を自動化してくれるシェルスクリプトを走らせたり、など色々な手法があります。

このアプローチを格段に簡単にしてくれるのがAppleALC.kextです。これは、AppleHDA.kextにパッチを当ててくれるkextです。この開発者が、最近パッチを当てる機能を分離して、Lilu.kextという拡張機能を作りました。現在のバージョンのAppleALC.kextはLilu.kextと一緒に使います。この両方のkextをCloverのEFI/CLOVER/kextsのOtherもしくは、該当するバージョンのフォルダに入れます。AppleHDA.kextにパッチを当てないので、macOSをバニラなまま保つことができます。

こちらにAppleALC.kextがサポートしているチップ一覧があります。最近のマザーボードで一般的なRealtek以外に、Creative, CirrusLogic, AnalogDevices, Conexant, IDT, VIA, Intelをサポートしています。 IntelはHDグラフィックスのHDMI出力をサポートしています。

github.com

ここに書いてあるどのlayoutを使うかをconfig.plistに記載する必要があります。 Realtekの場合、だいたいは1で良いようです。以下に例を示します。

<key>Devices</key>
<dict>
        <key>Audio</key>
        <dict>
                <key>Inject</key>
                <integer>1</integer>
        </dict>

Jeffさんのインストールガイドビデオ

Tue, 19 Sep 2017 13:25:38 +0900

ネット上にはたくさんのインストールガイドの文章や動画がありますが、これが一番わかりやすくて見やすいと思います。9TO5Macに記事を書いているJeff Benjaminさんのビデオです。9TO5Macの記事にも連動しています。テンポが良くて、映像が綺麗です。バニラなインストール方式なので、のちのOSアップデートが簡単です。ナレーションは英語ですが、聞き取れない箇所があったら字幕をonにすると良いです。

Hackintosh 101: the macOS Sierra step-by-step install guide

次の手順でインストール作業を進めています。

Apple 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のあたりで、マシンから起動したら大成功ですね。あとのステップは、ゆっくり調整すれば良いところです。とてもわかりやすくて、適切なガイドなのですが、補足と、ちょっとだけ気になったところを書いておきます。

Nvidia Web driverの有効化

ビデオの中ではnvda_drv=1というブートコマンドを使っていますが、最近ではこれが効かないらしいです。config.plistに以下のように書くのが良いようです。

        <key>SystemParameters</key>
        <dict>
                <key>NvidiaWeb</key>
                <true/>
        </dict>

OsxAptioFixDrv-64.efi

ビデオでは、OsxAptioFixDrv-64.efiを使っていますが、マザーボードによってはOsxAptioFix2Drv-64.efiの方が良いこともあります。また、どっちでも起動できないことがあります。その場合は、OsxAptioFix2Drv-free2000.efiというドライバをGoogle検索して探して入れて見ましょう。これらのefiが機能しないと、macOSを最初に読み込むところで（++++マークが並んだ直後で）止まってしまいます。なお、これらのドライバを２種類以上入れるとどれが動くかわからないので、一つだけにします。

mountコマンド

ビデオの中では、mountコマンドを使ってEFIをマウントしています。mountコマンドは、UNIX起源の素朴なコマンドです。macOSが提供しているdiskutilコマンドの方が適切です。diskutil mount /dev/disk0s1 などとタイプします。この方法だとパスワードが不要です。このほか、EFIのマウントの話題はこちらもご覧ください。

ESPをマウントするためのシェルスクリプト

LANのkext

ビデオの中では、AppleIntelE1000e.kextを使っています。Ethernetのkextについて、以下の記事を書いておきました。ここにあるようにIntelのチップに対しては、AppleIntelE1000e.kextよりも、IntelMausiEthernet.kextの方が評判が良いようです。また、Intel以外のチップに対しては、それぞれに対応したkextを使います。

Ethernetを設定する

機種設定

完璧な機種設定方法はこちらに書いておきましたので参考にしてください。ビデオで紹介されている方式は、簡易的な方式で、Jeffさんも言っていますがiMessageが動きません。

正しく機種設定する (SMBIOSの設定)

ブラックスクリーン問題

機種を正しく設定するとブラックスクリーン問題が発生するかもしれません。Jeffさんのビデオでは、問題の発生しない機種に設定して、この問題を避けています。機種設定を正しくした上でブラックスクリーン問題を回避するには、Lilu.kextとNvidiaGraphicsFixup.kextを使ってください。こちらに解説がありました。

www.reddit.com

そのほかの参考記事

インストールに関するここのブログの記事もご覧ください。

マザーボードの設定はこちらに書いておきましたので参考にしてください。

マザーボード (BIOS) 設定

kextの解説はこちらです。

/posts/126/

Cloverインストールの解説はこちら。

Cloverインストーラの設定

正しく機種設定する (SMBIOSの設定)

Mon, 18 Sep 2017 19:52:05 +0900

Hackintoshは本物のMacintoshではありませんが、macOSは本物の機種上で動いていると思い込んでいます。Macintoshの機種名によってハードウェア構成が違いますから、それに合わせた効率的な動作を行ったりする可能性もあります。またiPhoneとの連携、iMessage, iCloudなどのサービス利用の際に、機種名をチェックし、不整合があると機能を止めることもあります。

なので、実際のハードウェア構成に近い実機のふりをして、その情報を正しく設定しておくことが重要です。

Clover Configuratorを使って設定

ハードウェアを特定する情報は、Cloverのconfig.plistの中の、SMBIOSセクションに書き込まれます。この記事では、その書き方を説明します。SMBIOS (System Management BIOS)というのは、BIOSを使っていたマザーボードにあるシステムを記述する機能です。

SMBIOSセクションに書き込む内容を作るために、Clover Configuratorの機能が便利です。これを起動して、左のメニューからSMBIOSを選択します。右の画面で、いろいろな設定をします。

機種を決める

まずは、Macintoshのどの機種にするかを決めます。ハードウェア、特にCPUが近いものが良いです。CPUが近ければ、チップセットも同じですし、ハードウェアの動作も近いと考えられます。Macintoshの仕様を確認するためにはMactrackerというフリーウェアが便利です。

‎Mactracker

自作PCならば、おそらくiMacのどれかが適当だと思います。Xeonなどを使う場合は、もしかしたらMac Proかも。またIntel NUCなどで自作する場合は、Mac miniとかMacBook Airなどに同等または近いCPU搭載機種が見つかるかもしれません。

例えば、Kaby LakeのCore i7 7700Kで自作したマシンなら、iMac18,3が最適です。

Clover ConfiguratorのSMBIOSを選ぶと現れる大きな疑問符の右下のボタンを、クリックします。すると機種一覧が出ますので、ここから目的の機種、例えばiMac18,3を選びます。

シリアル番号を決める

最初に決めるのはシリアル番号です。左のほうに、Serial Numberと書かれた場所の番号です。

このシリアル番号はある規則に従って、自動生成されています。最初のアルファベットが製造地（Cは中国）で、次が年号、その年の週、その週に生産された何台めであるかの番号、機種を表す記号、などが特定の規則に従って記載されています。Generate Newというボタンを押すと、番号を生成し直してくれます。変化する部分が、週と製造番号の部分です。

未使用のシリアル番号であることを確認

こうして生成したシリアル番号と同じ番号を持つMacintoshが実在する可能性があります。その場合、実機のユーザに迷惑をかけ、Hackintoshする事に支障が出るのではないかと、コミュニティの人たちは心配しています。そこで、実在するシリアル番号と重複しない番号を使うことが強く推奨されています。

実存の番号と重複しているかどうかの確認方法は、簡単です。生成したシリアル番号をコピーして、以下のページにペーストします。

Check Your Service and Support Coverage - Apple Support

この結果、「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。もし、保証状況やサービス期間の案内が出るようなら、このシリアル番号は実機で使われている番号です。その場合は、別のシリアル番号を生成し直します。実際に生成してみるとわかるのですが、実存するシリアル番号に当たることはほとんどありません。

SmUUIDを設定する

SmUUID と書かれた欄が空白かと思います。UUIDはオブジェクトを一意に識別するための128ビットの数値です。例えばSSDやHDDにも付いていて、ボリュームを識別できます。ソフトウェアによってはSmUUIDで不正利用のチェックをしているようなので、一旦決めたらめったには変更しないようにしましょう。

UUIDはターミナルを開いて、uuidgenというコマンドをタイプすると生成できます。

$ uuidgen
97809030-7837-424E-BB69-246B934CB66D

何度か生成して、適当な番号を選べば良いです。これをコピーして、Clover ConfiguratorのSmUUIDの欄にペーストします。

その他の値

その他の値は自動生成された値で問題ありません。

Board Serial NumberはMacintoshのロジックボードのシリアル番号です。適当にそれっぽい値が生成されているので、そのまま使います。Bios Versionは、High Sierraで重要になりました。APFSからの起動に対応しているかをこれでチェックし、対応していないとインストールできないようです。最新のClover Configuratorを使えば、対応したバージョンが生成されます。この他、Firmware FeaturesやFirmware Features Maskなどは機種を特定するための値です。これもHigh Sierraのインストールに必要なようです。

config.plistに書き込む

Clover Configuratorは設定した値を元にCloverのconfig.plistを作ってくれます。とはいえ、SMBIOSの設定しかしていませんので、中身はSMBIOSのセクションだけです。

作った内容をconfig.plistファイルに書き出すメニューがあります。もしくは、左の一番下にある、Text Modeを選ぶと、設定に基づいたconfig.plistをテキスト形式で観ることができます。これらのSMBIOSセクションをコピーして、Cloverのconfig.plistに書き込みます。

補足

SMBIOSのデフォルト設定

Clover r4179以降では、config.plistで以下の値：

BiosReleaseDate
BiosVersion
FirmwareFeatures
FirmwareFeaturesMask

http://www.insanelymac.com/forum/topic/304530-clover-change-explanations/page-4#entry2482211

(2019/4/10 加筆）

さらに、最近のCloverでは、SMBIOSのかなりの部分を自動的に作ってくれるようです。ファームウェアバージョンなどを最新にしてくれるようなので、config.plistで指定しない方が良いかもしれません。ということで以下の4種類、

BoardSerialNumber
ProductName
SerialNumber
SmUUID

を指定しておくだけで良いらしいです。

Ethernetを設定する

Sat, 16 Sep 2017 21:59:36 +0900

Ethernetを動かすkext

マザーボード搭載やPCIeカード搭載のEthernetチップは大体がサポートされています。Linux用のドライバを元に移植されているようです。最近のマザーボードでは、IntelかAtherosのチップが多いです。マザーボードを購入する場合は、以下のkextがサポートしているEthernetチップを、そのマザーボードが搭載していることを確認すると良いです。

Qualcomm Atheros

Miezeさんが作っているAtherosE2200Ethernet.kextを使います。最近のマザーボードに搭載されているKiller E2500がサポートされています。AR816x, AR817x, Killer E220x, Killer E2400, Killer E2500が動きます。

Intel

最近のマザーボードでは、Intel i219-VやIntel I211ATが搭載されています。いくつかのドライバが用意されています。調子よく動くものを使用すれば良いと思いますが、IntelMausi.kextが一般的に使われていてお勧めです。

AppleIntelE1000e.kext hnakさんが開発しています。Intel 825xx シリーズをサポートしています。

AppleIGB.kext これもhnakさん。Intel 82575, 82576, 82580, dh89xxcc, i350, i210, i211をサポートします。

IntelMausi.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のほうがサポート継続されているらしく、おすすめのようです。

Realtek

Miezeさんが作っているRealtekRTL8111.kextを使います。最近のマザーボードに搭載されている8111Hがサポートされています。

Ethernetの設定

上記のkextが対応しているEthernetチップなら、kextをCloverのkextsディレクトリに入れておくだけで機能します。

もう一つ注意しておくべき設定があります。それはEthernetがen0に割り当てられる必要があることです。Unixマシンは、ネットワークアダプタにen0, en1, en2と番号を振って管理しています。macOSではOSが発見した順番にen0から番号づけられています。実際のMacintoshでEthernetを持っている機種はEthernetがen0です。WiFiだけの機種はWiFiがen0です。このように割り振られていない場合に、Apple App Storeに接続できなかったり、iMessageが使えなかったりします。

他のネットワークアダプタが有効になった後で、Ethernetのkextをインストールして動かした場合などは、Ethernetがen0以外の番号に割り振られてしまいます。なので、「リンゴマーク」「このMacについて」「システムレポート」で開くシステム情報の、「ネットワーク」リストを選んで、Ethernetがen0であることを確認しましょう。

もしen0では無い場合は、以下のファイルを消して、再起動すればen0になります。(もしくはこの中にあるenXという文字をすべてen0にしても良いです。)

/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
/Library/Preferences/SystemConfiguration/preferences.plist

Hackintoshのためのkext入門

Fri, 15 Sep 2017 23:23:26 +0900

改定：2018/9/15

kextとは

kextとはKernel EXTension（カーネル拡張）の略で、カーネルと呼ばれるOSの本体を拡張する一連のファイルです。OSに必要とされる機能が増加し、いちいちカーネルに組み込んでいると管理が大変になったので、別ファイルにして必要に応じて組み込むことになりました。macOSに限らず、多くのOSで一般的な方式です。ネットワーク、グラフィックス、サウンドなどのハードウェアを動かすデバイスドライバの機能も、kextとして提供されています。

Hackintoshのためには、Hackintoshを実現するためにmacOSの機能に手を加えるkextや、実機でサポートされていないハードウェアを動かすためのkextなどが開発されて、配布されています。必要なものを集めてHackintoshにインストールします。

kextの置き場所〜macOSの場合

macOSでは、kextを/System/Library/Extensions/ (/S/L/Eと略されます）もしくは、/Library/Extensions/に置きます。/S/L/Eに置くkextは、SIPで署名チェックされます。なので、当然ながら署名のないHackintosh用のkextを加える場合、SIPをdisableにする必要があります。

/posts/132/

kextは、実はファイルではなくてディレクトリです。macOSのファインダーからファイルのように見えているだけで、中には、多数のファイルが含まれています*1。これらのファイルの全てがカーネルから実行できるように、パーミッションが正しく設定されている必要があります。また、kextを起動のたびにkextファイルから読むと時間がかかってしまいます。そこで、キャッシュして高速化を図っています。なので、新しいkextを加えるためには、単にディレクトリにコピーするだけでなく、中身のすべてのファイルのパーミッションを正しく設定して、キャッシュを作り直さないといけません。この作業をGUIで実行するツールも配布されています。

kextの置き場所〜Cloverの場合

kextの追加をCloverにお任せすれば、前節のややこしそうなkextインストールの手間は無関係です。EFI/CLOVER/kextsの中にkextを入れておくとCloverが追加してくれます。SIPはenableのままで大丈夫です。またパーミッション設定もキャッシュ作り直しも不要です。ディレクトリに入れるだけです。以前は、kextによっては（例えばLANのkext）/S/L/Eに入れないと機能しないこともありましたが、最近では、ほとんどのkextがCloverのディレクトリに置いても問題なく機能します。それでも依然として、/S/L/Eに置かないと機能しないkextも稀にありますので、その場合は試行錯誤して確認してください。

EFI/CLOVER/kextsは、macOSのルート、もしくはボリュームのESPのどちらかにあります。デフォルトはmacOSのルートですが、その場合、macOSをまっさらに入れ替えると消えてしまいます。ESPにおいてあれば、アップデートで変更されないので管理が容易です。ESPにCloverをインストールする方法は、バニラインストールとも言われます。以下で説明してあります。

/posts/131/

EFI/CLOVER/kextsの中には、macOSのバージョン番号のディレクトリと、Otherという名前のディレクトリがあります。Cloverは、

まず、Otherに入っているkext
次に、該当するバージョン番号のディレクトリに入っているkext

の順番で、kextをインストールします。この後はmacOSに引き継がれて、/L/E、/S/L/Eの順にkextがインストールされます。同じ名前のkextがあったとしたら、後からインストールされた方が優先します。

kextは、該当するバージョン番号のディレクトリに入れておいても良いです。もしくは、バージョン番号のディレクトリは使わない（空にしておく、もしくはそもそもディレクトリを作らない）でOtherに全部入れておいても良いです。両方に入れても良いですが、混乱しやすいかもしれません。皆さんのやりやすい方法で管理すれば良いです。

FakeSMC.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です。

NullPowerManagement.kext

現代のCPUは、負荷によって動作周波数を変更したり、スリープをしたりして、消費電力を制御しています。この結果、省電力を実現し、発熱量を減らしています。搭載しているCPUがどのように電力制御を行うかの情報は、マザーボードからACPIテーブルを介してOSに伝えられます。ただ一般のマザーボード使用を想定していないmacOSには、この情報が正しく伝わらないことがあります。そもそも実機で採用されていないCPUの場合には、macOSで対応することができないこともあります。CPUの電力制御が正しく行えない場合、macOSがカーネルパニックを引き起こして起動しないこともあります。

macOSでCPUの電力制御を担当しているkextは、AppleIntelCPUPowerManagement.kextです。NullPowerManagement.kextはこのkextを無効にします。その結果、電力制御関連の設定が正しく行われていなくても、とりあえずはHackintoshが起動するようになります。なので、tonymacx86で配布されているインストール用USBメモリ (UniBeast)などのインストーラではこのkextが使われます。

起動してくれるのはありがたいのですが、電力制御が行われないので、CPUは最大出力で稼働し続けます。そこで、DSDT, SSDT, config.plistなどを正しく設定してこのkextがなくても起動するように調整することが、Hackintosh作りの一つの目標になります。

このほかのkext

このほかの主なkextには、

Ethernetを動かすためのkext
サウンド関係のkext
USB関係のkext
グラフィックス関係のkext

などがあります。これらは、該当するハードウェアを機能させるためのkextです。そのハードウェアが原因のトラブルを解消する機能を持ったkextもあります。FakeSMC.kext以外のkextは、絶対に必要というものではなくて、必要に応じてインストールすれば良いものです。それぞれのハードウェアの話題のところで説明していこうと思います。

kextの探し方

Hackintoshに必要なkextは、その名前で検索すると開発サイトや配布サイトが見つかります。また、KextUpdater.appを使うと、現在使用しているkextの最新版をチェックしてダウンロードしてくれます。また主要なkextを個別にダウンロードすることも可能です。

*1:macOSのアプリケーション、.appも同様にファイルではなくてディレクトリです。

Time Machineは良いです

Thu, 14 Sep 2017 23:46:39 +0900

macOSの良いところはたくさんあります。インクリメンタルバックアップのTime Machineが、OS標準でサポートされていることも、他のOSにない、大きなメリットです。Time Machineのおかげで何度も助けられました。

スタイリッシュなMacintoshと違って、いくらでもHDDを内蔵できる無骨な自作Hackintoshなのですから、是非ともTime Machine専用のドライブを搭載して、Time Machineを動かすべきです。内蔵ドライブにバックアップすれば、ネット越しよりも高速にバックアップできます。なので、OSがバックアップ作業をしていることに気づくことは滅多にありません。快適です。

今だと、3TBの3.5インチHDDが一番お得な製品です。これを1台内蔵して、全部をバックアップ領域にしてはどうでしょうか。バックアップメディアが大きいほど、過去のデータに戻れます。目安としてはオリジナルデータの2-4倍あると良いらしいです。

Time Machine用ドライブの活用

単純に全部をバックアップ領域にしても良いです。

3TBの3.5インチHDDの全体をTime Machine領域にする

でも、3TB HDDのESP領域は何にも使われていません。それなら、このHDDのESPにCloverとkextなど、メインボリュームのESPと同じものを入れるのも良いと思います。Hackintoshしていると、「メインボリュームのESPに手を入れていたら、起動しなくなってしまった」というピンチを一度は経験します。間違った設定を元に戻したくても、起動しないので作業ができないという状況です。ESPのバックアップがあれば、そんな時にもあわてなくてすみます。マザーボードのUEFI設定で起動ドライブをTime Machineのドライブにすれば良いのです。

3TBの3.5インチHDDのESPにメインのESPをバックアップする
残りの領域をTime Machine領域にする

ESPは、内蔵HDDだけでなく、当然ながら外付けのHDDやUSBメモリにもバックアップしておけます。でも内蔵ドライブにバックアップしておくと、紛失する心配がありません。間違いなく必ず筐体の中にあって、どこかに行ってしまうことはありませんから。

また、3TB HDDに60GBくらいのパーティションを作って、ここにmacOSもバックアップして置くと、さらに安心です。

3TBの3.5インチHDDのESPにメインのESPをバックアップする
頭に60GBくらいのパーティションを作ってここにmacOSをバックアップする
残りの領域をTime Machine領域にする

Cloverインストーラの設定

Wed, 13 Sep 2017 17:08:34 +0900

Clover UEFI Bootloader

Hackintoshする方法はいくつかありますが、現在、一番ポピュラーなのは、Cloverブートローダを使う方法です。Cloverの本体は、コンピュータが起動した時に真っ先にブートされるBOOTX64.efiというファイルです（UEFI起動の場合）。

検索すると、tonymacx86サイトで配布しているUniBeastとかMultiBeastを使った方法が多数見つかりますが、これらもCloverを使っています。MultiBeastは、Cloverをインストールして、kextをインストールして、Cloverの設定をメニュー形式で行ってくれるツールなのです。

その大元の、Cloverにもインストーラはあり、Cloverの動作に最低限必要なファイルをインストールする機能があります。設定ファイルのカスタマイズや、kextファイルのインストールはやってくれません。しかし、そういう作業はインストーラ任せにしないで、手動で行った方が、システム構成を把握できます。その結果、トラブルにも対応できるようになります。なので、Cloverのインストーラを使う方法をお勧めします。

この記事では、Cloverのインストーラでカスタムインストールする方法を説明します。

インストール先の指定

デフォルトでは以下のような設定になります。以前にCloverをインストールしたことがあるボリュームを対象とした場合は、最後に指定した設定が表示されます。

最初に、ドライブのどこにインストールするかを決めます。デフォルトのBootloaderというメニューでは、MBRのある昔ながらのBIOS方式がデフォルトです。ここは是非、Cloverの強みが活かせるUEFIブートにしておきましょう。また、EFI System Partition (ESP)にインストールするよう選択しておきましょう。バニラなインストールが可能になります。

テーマなんて飾りです

テーマは、Cloverの起動ドライブ選択画面のデザインを変えるところです。指定しなくても良いですが、インストールするドライブごとに違うテーマを指定しておくと、どれで起動したかがわかって役に立ちます。テーマは、いろいろな人がデザインして配布しています。好きなものを選ぶと良いです。こんなシンプルなのはいかがでしょう。

Drivers64UEFI

次に選択すべきはDrivers64UEFIの中身です。ここには、OSが起動する前の、UEFIの環境で動作するプログラムが並んでいます。ここにリストされている以外の、必須のプログラムは、ここでの選択とは別に、自動的にCloverのディレクトリに入ります。

選んでおかねばならない一つは、メモリーを確保する際に生じる問題を修正するドライバです。これらのドライバは、macOSが起動する初期段階で、カーネルを読み込む前に動作します。正しく機能しないと、Couldn’t allocate runtime areaというエラーを出して停止してしまいます。選択肢は、

AptioMemoryFix.efi
OsxAptioFix3Drv-64.efi
OsxAptioFix2Drv-64.efi
OsxAptioFixDrv-64.efi
OsxLowMemFixDrv-64.efi

です。必要なのは、このうちの1つだけです。このリストの複数を選択してはいけません。番号は、推奨する順番です。この順番に入れてみて、ちゃんと起動すればそれを使うのが良いです。できれば1か2が望ましいです。Clover開発チームのSliceさんによる説明が、こちらにあります。

www.insanelymac.com

それによると：

OsxAptioFixDrv-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 が必要な場合もあります。

この他、マザーボードによっては、EmuVariableUefi-64も必要になります。MacintoshにはNVRAMがあって電源をoffにしても一部の設定が保存されています。同様の仕組みはUEFIマザーボードにもあります。ただ、それがうまく動かない場合があります。EmuVariableUefi-64はNVRAM機能をエミュレートしてくれるプログラムです。

他は非選択でok

他の項目は大体非選択で大丈夫です。「Clover環境設定をインストール」は、システム環境設定にCloverの項目を入れてくれるオプションです。Cloverのアップデートチェックをしてくれるので、チェックを入れておいても良いかと思います。

インストール後のディレクトリ構成

最終的には、以下のようなディレクトリ構造がESPに作られます。ここでは、Cloverインストーラがインストールしたefiファイルに加えて、High Sierraで必要になったAPFSブートのためのefi, apfs.efiが追加されています。また、OsxAptioFix2Drv-64の代わりにOsxAptioFix2Drv-free2000がインストールされています。

あと13日！High Sierraのお迎え準備

Wed, 13 Sep 2017 14:28:32 +0900

High Sierraは9月26日に登場

昨夜の発表では、Macintoshはおろか、間も無く登場のmacOSも紹介されなくて寂しい限りです。でもアップルのサイトには、macOS High Sierraの発表日がひっそりと掲載されています。9月26日だそうです。あと、13日ですね。それまでに、あなたのHackintoshに新バージョンをお迎えする準備をしておきましょう。

ドライブを用意

今使っているメインのドライブにいきなりHigh Sierraを入れるのは、多分問題なく動くと思いますが、さすがにチャレンジングです。使っていないドライブを用意しておきましょう。HDDでも良いですが、古いSSDでもあれば尚良いです。動かすには30GBくらいあれば十分です。自作マシンなら、マザーボードにSATAケーブルで接続すれば良いです。最近は、USB 3.0接続のUSBメモリーで高速なものもありますので、下手なHDDよりずっと速いかもしれません。それでもokだと思います。

Cloverを最新版に更新

最新版なほど安心です。現時点での最新版のリビジョンは4200です。古いようなら更新しておきましょう。

kextファイルを最新版に更新

開発者の皆さんがベータ版を使ってHigh Sierra対応を進めてくれています。使っているkextファイルの最新版が出ていないかどうか確認しましょう。kextファイルの名前でGoogle検索すれば良いです。全部最新版に更新しておきましょう。

また、kextをEFI/CLOVER/kexts/10.12に入れている人は、10.13を新たに作って、全部のkextをコピーしておきます。もしくは、Otherフォルダにコピーしておいても良いです。10.13で起動する場合は、Otherの内容が先に読み込まれ、次に10.13フォルダが読み込まれます。10.12のフォルダの内容は無視されてしまいます。

config.plistのSMBIOS情報を更新

High Sierraのアップデートでは、APFSでも起動できるようにファームウェアがアップデートされます。ファームウェアが対応版にアップデートされていないと判断されると、インストールが止まってしまうようです。そこでconfig.plistのSMBIOSセクションのBIOSバージョンの記述を、最新版ファームウェアと同じバージョン番号に書き換えておきましょう。また、Firmware FeaturesとかFirmware Features Maskという謎の情報がSMBIOSにないとインストールできなかったという報告もあります。config.plistにこの記述がなかったら、これも設定しておきましょう。

書き換えるべき情報は、機種ごとに違います。これを簡単に確実に知る方法の一つは、Clover Configuratorを使う事です。

mackie100projects.altervista.org

これをダウンロードして、左のリストからSMBIOSを選びます。右の疑問符のところをクリックして現れるポップアップメニューから、自分が設定している機種名を選びます（下の写真では疑問符が消えてiMacの写真に変わっています）。すると必要な数値を自動的に作ってくれます

この結果を、Save As…でconfig.plistファイルに書き出します。書き出したconfig.plistにはSMBIOSのセクションの記述しかありません。これを見ながら、現在のconfig.plistで足りない記述を書いていきます。更新、追記しないといけない項目は、以下です。これはiMac18,3の場合の例です。

<key>BiosReleaseDate</key>
<string>08/08/2017</string>
<key>BiosVersion</key>
<string>IM183.88Z.0151.B00.1708080034</string>
<key>FirmwareFeatures</key>
<string>0xFC0FE136</string>
<key>FirmwareFeaturesMask</key>
<string>0xFF1FFF3F</string>

これ以外の情報、例えば、シリアル番号とかUUIDなどは、現在の値を引き続き使います。書き換えてしまうとiMessageなどの動作に支障をきたすかもしれません。

SMBIOSの設定についてはこちらでも解説しておきました。

正しく機種設定する (SMBIOSの設定)

起動できることを確認

以上の変更を一つずつ行い、その度に起動できるかどうか確かめていきましょう。全部が最新版に更新されて、config.plistの記述が完全になるので、High Sierraにアップデートしないとしても、良いメンテナンス作業になります。

これでHigh Sierraを迎える環境は整いました。待ちきれないようでしたら、新しいドライブをディスクユーティリティでフォーマットして、今のドライブから新しいドライブにESP部分を複製して、Cloverが起動するようにしておいても良いでしょう。

macOSをバニラに保ってインストールする

Tue, 12 Sep 2017 23:05:32 +0900

macOSをインストールしてHackintosh をつくる方法、流儀、ツールはいくつかあります。ここでは、一番おすすめの、バニラな方法を紹介します。macOSをできる限りオリジナルなままに保ってインストールする方法です。バニラというのはVanillaアイスクリームのバニラで、チョコレート味とか抹茶味みたいに手を加えてない、素材のままという意味です。

バニラな方法では、macOSが入っているメインのパーティションの内容には一切手を加えないで、実機と全く同じ状態にしておきます。この方法では、カーネルやカーネル拡張（kextファイル）を書き換えません。HackintoshのためのkextファイルもmacOSパーティションには追加しません。

バニラのメリット

バニラな構成では、macOSメインのパーティションは本物のMac（実機）と同一です。なので、Hackintoshのドライブを本物のMacに取りつければ、そのまま起動します。macOSから見ると、このパーティションが世界の全てです。なので、macOSのバージョンアップをした時、書き換わるのもmacOSが入っているパーティションだけです。この部分に手を加えていると、バージョンアップのたびに対応し直す必要があります。しかしバニラに保っておけば対応の必要が無く、実機と同じようにApp Storeからバージョンアップするだけでの簡単な操作で行えます。

macOSのインストール手順

macOSをバニラにインストールする一般的な手順を書いておきます。Hackintoshに必要なファイルを、macOSメインパーティションではなく、ESP (EFI System Partition)に置くのがポイントです。

ボリュームをディスクユーティリティでフォーマットする
通常のインストーラを使ってmacOSをインストールする
Clover EFI BootloaderをESPにインストールする
Cloverの設定ファイルconfig.plistを目的に応じてカスタマイズする
必要なkextファイルを集めてESPのkext用フォルダに入れる

手順1と手順2は、通常のmacOSインストール手順です。実際のMacintoshにmacOSをインストールするのと同じ手順です。実機ならばm.2/SATA/USBなどで接続したボリュームをフォーマットしてそこにインストールします。Hackintoshならば、macOSインストーラが起動するUSBメモリを以下の手順：

High Sierra導入用USBメモリ作成方法

で作成して、これで起動して、ディスクユーティリティ.appを使って対象ボリュームをフォーマットして、macOSインストーラを使ってインストールします。

手順4と手順5は、macOSとHackintosh用ブートローダのCloverをインストールした後の、「ポストインストール」とも呼ばれる作業です。Hackintoshが正しく動くようにする作業で、色々なノウハウが必要です。手順3、手順4、手順5は、以下の記事を参照してください。

Cloverインストーラの設定

手順3は、macOSをUEFIマザーボードで起動させるためにUEFIブートローダであるCloverをインストールする手順です。Cloverはオープンソースで開発されているツールです。

Cloverのインストーラでは、Hackintoshに必要なファイルを置く場所を選択できます。一つの選択肢は、macOSが入っているメインパーティションのルートです。もう一つは、EFIシステムパーティションです（頭文字でESP）。

前者の場合、macOSのパーティションにファイルを追加するので、バニラに保つポリシーからは外れます。

後者でファイルが追加されるESPは、macOSでドライブをフォーマットすると自動的に作ってくれるパーティションの一つです。UEFIマザーボードが起動するときに使用するファイルが置かれる場所です。しかしmacOSはこのパーティションを使用しません。なので、ESPにHackintoshに必要なファイルを全て置けば、バニラなインストールが実現できます。

ESPを利用するためには、Cloverのインストーラで、カスタムインストールを選択し、「ESPにインストール」にチェックマークを付けます。

この記事の以下では、

フォーマット後に出来上がるパーティション構成と、
バニラを目指してCloverをインストールした後のESPの内容

を説明します。

バニラなディスク構成

バニラな方法で使用するESPは、macOSでドライブをフォーマットすると自動的に作ってくれます。試しに、ディスクユーティリティを使って120GBのSSDをまっさらにフォーマットしてみました。ターミナルからdiskutil listとするとフォーマット後のパーティションの一覧が出てます。例えば以下のようになります。これは全てディスクユーティリティが作ってくれるパーティションです。ただし、メインのパーティション名は、フォーマットの時に指定します（ここではMacintosh HDとしました）

/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 以下にマウントしてくれます。

sudo diskutil mount /dev/disk0s1

10.13.6からマウントするためにsudoが必要になりました。それより古いmacOSでしたらsudoなしでもマウントできます。

ESPの中身

先のmacOSのインストール手順の箇条書きに示したように、ボリュームをフォーマットした後に、macOSをインストールして、次にCloverをインストールします。Cloverをインストールした後の、ESPの一例を見てみましょう。

CLOVERというディレクトリができていて、この中に、設定ファイルconfig.plist, システム拡張ファイルkextを入れるkexts, EFIのドライバを入れるdrivers64UEFIなどが出来上がっています。これらはCloverのインストーラが作ってくれますが、手作業で作っても良いです。すでに動いているHackintoshの環境を移行する場合などは、このディレクトリ構造そのままに新しいドライブのESPにコピーすれば、引き継がれて稼働します。Cloverのインストーラは、最小構成のconfig.plistと、必要なdrivers64UEFIの中身をインストールしてくれます。

kextsは、必要に応じて手作業で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を有効にしてくれるので手間いらずでもあります。

SIP システム整合性保護機構

Tue, 12 Sep 2017 19:00:25 +0900

El CapitanでSIP (System Integrity Protection, システム整合性保護）という仕組みが導入されました。SIPは、システム管理者であっても、システムの要のディレクトリのファイルを変更したりファイル追加したりできない仕組みです。また、アップルに認められて署名されたカーネル拡張機能 (kextファイル) 以外は、機能しません。なんでも書き換えられるスーパーユーザであるルートはもはや居ないという意味で、rootlessとも呼ばれています。

デフォルトではSIPは有効になっていますが、無効にすることもできます。実機の場合は、以下のようにします。

リカバリーモードで起動します。
ターミナルを起動して csrutil disableもしくはcsrutil enableと入力します。
この後、再起動すれば、それぞれSIPが無効もしくは有効になります。

SIPに関してはこちらの記事に詳しく書いてあって参考になります。

news.mynavi.jp

Hackintoshでの対処方法

SIPが登場した時、Hackintoshが困難になるのではという予想もありました。でもCloverの開発者たちが頑張って対応してくれました。今では、Clover設定で、実機と同様に、SIPを有効にも無効にも自在に設定できます。HackintoshでSIPをどう設定して運用するか、対照的な2通りのアプローチがあるかと思います。

SIPは無効にして自由自在にパッチを当てまくる
macOSをバニラな状態に保ってSIPを有効にする

前者はSIP登場前と同様にmacOSに手を加えるアプローチです。後者のアプローチにある「バニラに保つ」方法の詳細は、以下をご覧ください。

/posts/131/

バニラな方法では、Hackintoshに必要なファイルは、全てをEFIシステムパーティション (ESP) に置きます。ESPはSIPの管轄外なのです。ここに置いたファイルは自在に書き換えられますし、ここに置いたkextファイルは、署名がなくても動きます。ESPは管理者アカウントなら自由にアクセスできるので、SIPの有効性を低下させてしまいますが、それでも、本体へのアタックはある程度は防げます。また、SIPを有効にできるかどうかは、システムがバニラに保たれているかどうかの指標にもなります。

CloverでのSIPの設定

起動時のClover設定画面でも一時的にSIP設定変更が可能です。

継続的に指定する場合はconfig.plistを編集します。config.plistのRtVariableセクションでSIP設定を変えられます。

        <key>RtVariables</key>
        <dict>
                <key>CsrActiveConfig</key>
                <string>0x0</string>
        </dict>

ここで使う代表的なCsrActiveConfigの値は以下です。

0x0 = SIPを有効にする (デフォルト値)
0x3 = SIPを部分的に無効にする (署名されていないkextをロードする)
0x67 = SIPを完全に無効にする

現在の設定状態は、csrutil statusコマンドで知ることができます。手元のマシンだと、以下のようになっていました。有効になっているということです。

$ csrutil status
System Integrity Protection status: enabled.

ちなみにRtVariablesキーでは、CsrActiveConfig以外にROMとかMLBとかBooterConfigの値を設定できますが、どれも今のCloverでは不要です。CsrActiveConfigだけが有効です。

光学ドライブを使う

Mon, 11 Sep 2017 13:57:04 +0900

現行のMacintoshからはすっかり駆逐されてしまった光学ドライブですが、Hackintoshなら5.25インチベイ搭載ケースを使っていくらでも復活できます。CD-ROMでもDVDでもokです。実機にはついぞ搭載されなかったBlu-rayドライブも搭載可能です。1台だけでなく2台3台と搭載することだって可能です。読み出すだけじゃなくて書き込むこともできます。搭載するに当たって、特に難しいことはありません。SATAケーブルと電源を配線するだけです。

「可能な場合でもハードディスクをスリープさせない」

簡単、かんたん、a piece of cakeだと思っていたら、「空のdvdがセットされました」というメッセージが出て、操作不能になることがあります。Pioneerのドライブで発生するような気がします。

一部の光学ドライブは、スリープコマンドを送りつけて動作を止めると、次にアクセスした時に復帰できないようです。にもかかわらず、macOSの省エネルギー設定では、「可能な場合はハードディスクをスリープさせる」ことがデフォルト設定になってます。これがトラブルの原因です。なので、この問題は、「システム環境設定」の「可能な場合はハードディスクをスリープさせる」のチェックを外すことで解決します。

カーネル拡張(kext)にパッチを当てる

上記の方法だと、当然ですがハードディスクはスリープしなくなります。また、私は経験したことがありませんが、この方法でも解決しないという報告もあるようです。そこで正攻法で根本的解決方法、つまりシステムにパッチを当てる方法を紹介します。

アップル社は対策済み

アップル社もこの問題はよ〜く分かっていて、旧型Mac Proに搭載されているPioneerの光学ドライブに対して対策をしています。PioneerSuperDrive.kextの中で、Pioneerの光学ドライブの型番を指定して、このドライブだけはスリープさせないようにという設定がされているようです。その型番とは、

DVD-RW DVR-105

です。この対策を担当しているkextは、PioneerSuperDrive.kextです。試しに、

/System/Library/Extensions/AppleStorageDrivers.kext/Contents/PlugIns/PioneerSuperDrive.kext/Contents/PlugIns/PioneerSuperDrive.kext/Contents/MacOS/PioneerSuperDrive

をhexdump -Cしてみると、

00000fb0  70 6c 65 5f 64 72 69 76  65 72 5f 50 69 6f 6e 65  |ple_driver_Pione|

00000fc0  65 72 53 75 70 65 72 44  72 69 76 65 00 44 56 44  |erSuperDrive.DVD|

00000fd0  2d 52 57 20 20 44 56 52  2d 31 30 34 00 31 2e 31  |-RW  DVR-104.1.1|

00000fe0  30 00 44 56 44 2d 52 57  20 20 44 56 52 2d 31 30  |0.DVD-RW  DVR-10|

00000ff0  35 00 4e 6f 20 53 6c 65  65 70 00 54 72 75 65 00  |5.No Sleep.True.|

と書いてあります。DVD-RW DVR-105をNo Sleepにするって書いてあるように見えます。DVR-104も対策済みみたいにも見えます。運良く、これらの型番のドライブをHackintoshに搭載した人は、きっとこの問題に遭遇しないのでしょう。そうでない人は、ファイルに書かれた型番を、実際に使っているドライブの型番に書き換えればよいわけです。

光学ドライブの型番を知る

光学ドライブの型番は、「リンゴマーク」「このMacについて」「システムレポート（システム情報）」「ハードウェア」「SATA/SATA Express」とだどっていけば、見つかります。手元の例ではPIONEERという表記を除いて、

BD-RW   BDR-205

でした。スペースの数（3個あります）も重要で、全部で15文字のはずです。

Cloverのconfig.plistでパッチを当てる

古代の手法では、 PioneerSuperDrive.kextの該当ファイルをバイナリーエディタで開いて、データを書き換えていました。これは色々問題があります。特に、OSのバージョンアップのたびに同じことをやらなければならないのが面倒です。現代風の方法では、Cloverの動的パッチ機能を使います。起動するタイミングでパッチを当ててくれる機能です。

設定ファイルconfig.plistにパッチ情報を書き込むのですが、この時、バイナリーデータを文字に対応させて変換するBase64という方式を使います。Base64への変換は、ターミナルのbase64コマンドで可能です。例えば、DVD-RW DVR-105（スペースは2個）とBD-RW BDR-205（スペースは3個）の文字列をBase64に変換するには、ターミナルで以下のようにタイプすれば良いです。

$ echo -n "DVD-RW DVR-105" | base64
RFZELVJXICBEVlItMTA1
$ echo -n "BD-RW BDR-205" | base64
QkQtUlcgICBCRFItMjA1

変換前後の文字列のBase64表記がわかりましたので、いよいよconfig.plistを開いて、KextsToPatchセクションに以下を追加します。

 <key>KextsToPatch</key>
 <array>
 <dict>
         <key>Comment</key>
         <string>PioneerBD-RW No Sleep</string>
         <key>Find</key>
         <data>RFZELVJXICBEVlItMTA1</data>
         <key>Name</key>
         <string>PioneerSuperDrive</string>
         <key>Replace</key>
         <data>QkQtUlcgICBCRFItMjA1</data>
 </dict>
 </array>

なんとなくわかると思いますが、PioneerSuperDrive.kextの、RFZELVJXICBEVlItMTA1というデータを検索して、QkQtUlcgICBCRFItMjA1に置き換えてくださいという指示です。これでめでたくスリープ問題が根本的に解決されるはずです。

OpenCoreのconfig.plistでパッチを当てる

OpenCoreでも同様に、config.pistの指定で動的にパッチ当てが可能です。以下にその方法を紹介しておきました。

Pioneer光学ドライブのパッチをOpenCoreに適用する

キーボードから開閉したい

ご存知のようにアップルの純正キーボードには光学ドライブをイジェクトするキーがついています。今風のMacintoshでは使いようのない無駄なキーですが、光学ドライブを搭載したHackintoshなら有効に使ってあげられます。と、思ったら、これが効かないこともありました。

解決策がこちら、

www.tonymacx86.com

で紹介されています。AHCI_3rdParty_SATA.kextに手を加えて使用する方法です。日本語で紹介された解説が、こちらにあります。

www.reddit.com

ESPをマウントするためのシェルスクリプト

Sun, 10 Sep 2017 23:43:45 +0900

EFIシステムパーティション(頭文字を並べてESP)には、Cloverブートローダとかconfig.plistとかkextファイルなどが置かれてます。ESPは通常はマウントされていませんので、これをメンテするときに、マウントする必要があります。例えば、ESPが/dev/disk0s1にある場合は、ターミナルから

diskutil mount /dev/disk0s1

とすればマウントできます。すると/Volumes/EFI以下にマウントされます。必要ならばここにcdしたり、これをファインダーに表示させます。

でもこの一連の作業が面倒なので、こんなシェルスクリプトを作って使っています。マウントしたESPは、マウントした順番に/Volumes/EFI, /Volumes/EFI 1, /Volumes/EFI 2のマウントポイントに割り当てられます。このスクリプトでは、マウントした後にCLOVERのディレクトリにcdしています。この後、open .などすればファインダに表示することもできます。

#!/bin/sh
if [ $# -eq 0 ]; then
DRIVE="0"
else
DRIVE=$1
fi
diskutil mount /dev/disk${DRIVE}s1 
MP=`diskutil info disk${DRIVE}s1 | grep "Mount Point"`
MP3=`echo $MP |  awk '{print $3}'`
MP4=`echo $MP |  awk '{print $4}'`
if [  -n "$MP4"  ]; then
cd $MP3" "$MP4"/EFI/CLOVER"
else
cd $MP3"/EFI/CLOVER"
fi

これをファイルにして、名前をつけて、実行可能にします。例えば、mountESPという名前のファイルにした場合、

/dev/disk2s1 をマウントしたいならば、ターミナルから以下のようにタイプします。

. mountESP 2

引数を省略すると/dev/disk0s1がマウントされます。ドライブが1個しかないマシンでは、必ず/dev/disk0に割り当てられるので、番号を省略できると便利と考えました。

. mountESP

ちなみに冒頭のピリオド空白(. )は重要です。通常よくやるように./mountESPとすると、最後のcdコマンドが効きません。実際には効いているのですが、シェルスクリプト実行環境の中で効いているので、ターミナルのプロンプトに戻ると元のディレクトリに帰って来てしまいます。ピリオド空白(. )は、ターミナルの実行環境のままで、キー入力そのもののようにスクリプトを実行するという意味だそうです。

追記：10.13.6からESPをマウントするのに管理者パスワードが必要になりました。なので、上記のスクリプトも、diskutil mountの行を、以下に変更する必要があります。(2018/7/10)

sudo diskutil mount /dev/disk${DRIVE}s1