ガイド on Boot macOS

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個制限の設定が可能でした。今まで紹介した方法のどれよりも簡単だと思いますので、今後はこの方法で設定していこうと思います。コメントで教えていただきありがとうございました。

リムーバブル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の値を必ず置換えてください。

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

まとめ

リムーバブルドライブベイのホットプラグを可能にする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でもアイコンによる起動選択ができるようになっていることを教えていただきましたので、試しました。以下での設定が終了していることが前提です。

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の値を必ず置換えてください。

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

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に順調に移行できたかに見えました。

でも再起動をすると、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の値を必ず置換えてください。

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

まとめ

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のための機能を追加されたようです。

今まで、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 Sanity Checker

Sanity Checkerで検証

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

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

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

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

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

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

その他の設定

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

起動ボリュームの指定

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

Kext Updaterを使う

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

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

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

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

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

Windowsが起動しない

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

続きの記事

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

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

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

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

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

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

まとめ

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

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の表示不具合対応の顛末は次の記事で紹介します。

マザーボード起動スプラッシュ画像をMac風に変更する

Sat, 29 Feb 2020 17:22:41 +0900

起動時にマザーボードBIOSが起動するロゴマークを、本物Mac風に変更しました。ASUSのROGシリーズZ390マザーボードなので、ブート時に下のような画面が現れます。これを、上に示したようなAppleマークにしました。変更にはWindowsのツールを使用しました。

システムやアプリが起動する時に現れる画面をスプラッシュ (splash) 画面と呼びます。アプリ画面に「突入」する直前に現れる画面だからなのだと思います。本物のMacでは、電源投入直後のスプラッシュ画面に黒字に白のAppleマークが表示されます。昔の機種では、グレー地に黒いAppleだった気がします。一方で、一般的なマザーボードではマザーボードブランドのロゴが表示されます。ASUS ROGシリーズでは多少控えめな上のようなロゴが表示されますが、一般的にはかなり派手です。簡単に変更できるものならシンプルなAppleロゴに変更したいと思っていました。

macOSだけで変更する

Windowsのツールを使えば簡単に変更できるらしいと知っていたのですが、できればWindowsを使わないでなんとかしたいと思っていました。そんな時、Redditに解説が投稿されていたのを発見しました。

r/hackintosh - [GUIDE] How to create your own BIOS Splash Page with new custo…

この投稿者はASRock Z390ボードで試したところ成功したらしいです。でも結論から言うと、ASUS ROG Z390では簡単ではなかったです。以下で、この方法を簡単にご紹介します。

UEFIToolを入手する

UEFIToolというツールでBIOSイメージを変更できます。このツールをダウンロードします。Hackintoshコミュニティでお馴染みのvit9696さんもフォークしているようで、なんとmacOS版もありました。以下から、UEFITool.appをダウンロードします。

Releases · LongSoft/UEFITool

BIOSのイメージを読み込む

次にUEFIToolを起動して、マザーボードのBIOS ROMファイルを読み込みます。今回は、ASUSのサイトから入手したROG-MAXIMUS-XI-HERO-WIFI-ASUS-1401.CAPという名前のファイルを使いました。読み込みが終了すると、以下のような表示になります。

下のメッセージ欄に、「BIOSイメージを加工するとAptio カプセル署名が無効になります」という警告が出ています。後でこれが問題になりました。

現在のスプラッシュ画像を確認する

ROMファイルが読み込めたら、現在のスプラッシュ画像の場所を確認します。そこで、File–>Searchメニューを開いてSearchダイアログを開きます。GUIDタブを選択し、7BB28B99-61BB-11D5-9A5D-0090273FC14Dを検索します。

UEFIToolウィンドウの下部のMessageウィンドウに、「GUID pattern “7BB28B99-61BB-11D5-9A5D-0090273FC14D” found as …」という表示が出るはずです。これの一つをダブルクリックすると、BIOSスプラッシュ画像が保存されているセクションが表示されます。

今回、3箇所見つかりましたが、一つだけが下位階層のあるFileでした。これしか開くことができないので、この検索結果をダブルクリックしました。この中のRaw Sectionがスプラッシュ画面のようです。これを選択して右クリックします。Extract Body…を選択します。

ここでファイル名を指定すると（今回はROGという名前にしました）、ファイルタイプがrawのファイルが作られます。プレビューで開くこともできて、以下のように現在のスプラッシュ画面であることが確認できました。

新しい画像に差し替える

新しい画像を用意します。画像は、1024×768画素 (72または96dpi) 以下が良いとか、1MB以下が良いなどのサイズ上限があるようです。50 ~ 100KBくらいが良いのではとのことです。今回は、Cloverテーマの一つのMinimalismからファイルをいただいてきました。ファイル形式は、jpegやpngやtiffなどが使えるそうです。raw形式でなくてもUEFIToolが自動的にrawに変換してくれるようです。先程の右クリックのメニューからReplace body…を選べば差し替えることができます。

画像を差し替えたら、いったん保存します。そしてUEFIToolで再度開き、先程のように7BB28B99-61BB-11D5-9A5D-0090273FC14Dを検索し、新しい画像に差し替えられているかを確認します。今回用意したpngとtiffのアイコンと、変更したBIOSファイルから取り出したrawのアイコンを示します。

こうして作成した新しいBIOSファイルにアップデートすれば良いのですが、ASUS ROG Z390ではダメでした。BIOSのアップデートツールEzFlashで、”Selected file is not a proper BIOS!”というメッセージが出てしまいます。

おそらくは上で書いたように、ファイルの署名情報が狂ってしまったことが原因だと思います。いろいろ検索したら、改造BIOSをインストールする方法もあるようです。UEFIツールだけを使ってできるようです。ただ複雑な手順が必要で、またセキュリティ機能を外して行う作業なため、面倒で危険な作業のようです。スプラッシュ画像を差し替えたいだけのためにそこまでやるのは割りに合わないと思いました。

Windowsのツールで変更する

ということで、仕方なくWindowsを使うことにしました。操作も不慣れなのであまり使いたくなくて、Windowsはもう何ヶ月も起動していません。久々に起動したら、更新項目が多数溜まっていて、起動するだけでも大変でした。使用するツールはASUS AI Suite 3です。この中にEZ UpdateというBIOSアップデートの機能があり、これを使います。ネットでも配布されていますが、マザーボード付属のDVDからインストールしました。アプリをインストールするだけなのに、何度か再起動させられたのですが、Windowsってこんなものでしょうか？ASUS AI Suite 3のメニューの中からEZ Updateを起動し、BIOSファイルを指定したBIOSアップデートをします。

ここではバージョン1401を選んでいますが、マザーボードはすでに1401になっているのでもう一度上書きすることになります。BIOSファイルを指定すると、右下のMyLogoのボタンが選べるようになります。これを選択すると、

新しいスプラッシュ画像を選択できるようになります。上で紹介したCloverテーマのMinimalismのアイコンをそのまま使うと、少し巨大過ぎました。UEFIToolで取り出したオリジナルの画像があれば、それを元に、消したり重ねたりして調整すると目指す大きさで表示されると思います。画像設定後、再起動になり、BIOSがアップデートされます。いつものBIOSアップデート作業と同様に、CMOS設定もクリアされるので、USBメモリーなどにバックアップしておくと再設定が楽です。

GIGABYTEのガイド

ここまではASUSのマザーボードの話でした。GIGABYTEに関するコメントをいただいたので調べてみたら、こちらにGIGABYTEマザーボードのスプラッシュを変更する方法が書いてありました。GIGABYTEが配布しているWindows用ツールを使う方法と、（なんと！）macOSユーザ用にUEFIToolを使う方法が説明してありました。

まとめ

ASUS ROG Z390マザーボード起動時の画像を白いAppleマークに書き換えました。UEFIToolを使用するとBIOSの書き換えが出来、これを使ってスプラッシュ画像も変更できます。ただメーカの署名が無効になり、アップデートが非常に困難だとわかりました。そこでやむなくASUSが配布しているWindows用ツールを使用しました。久々に慣れないWindowsを起動して大変でしたが、作業自体は簡単でした。Macのようなシンプルな起動画面になりました。だからと言って何も変わらないのですが、再起動してはニヤニヤしています。

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%動かせる方法はありません。

Sonnetの互換GPUリスト (10.15.1以降)

Mon, 04 Nov 2019 11:21:15 +0900

macOSで使えるGPU

MacのThunderbolt 3コネクタに接続する外部GPUボックス

を販売しているSonnet社が、macOS 10.15.1以降と互換性のあるグラフィックスカードの一覧を以下のPDFファイルで公開しています。

https://www.sonnettech.com/support/downloads/manuals/Compatibility_Graphics_C…

各ブランドごとの多数のモデルを掲載しています。Sonnetの外部GPUボックスは、AppleのExternal Graphics Development Kitにも採用されているほぼ純正みたいな存在です。なので、このリストで互換性があるとされたグラフィックスカードは、Hackintoshで、そのまま動くカードと考えて良いです。市場に出回っている多数の製品に対して互換性がチェックされているようですので、Hackintosh用グラフィックスカード購入の際は、これで確認しておきましょう。これを見ると、例えば、AMDリファレンス（ファンデーション）バージョンでは、以下のMがマークされた機種がmacOSと互換のようです。

主に、GPUチップによってのみ互換・非互換が決定するようです。まとめると以下のようになります。ただ、一部のブランドでは互換性が無いとされているモデルもあります。互換性確認ができていないだけなのか、何らかの問題があるのかは不明ですが、そのようなモデルは避けた方が良いと思います。

RX 470, RX 480, RX 570, RX 580は互換性あり
RX 560, RX 590は10.14.6から互換性あり
RX 460, RX 550は互換性なし
RX Vega 56/64は互換性あり
Radeon VIIは10.14.6から動くがスリープ・シャットダウンでファンが全開になる
RX 5500は非互換で、RX 5700, RX 5700 XTは互換性あり
R9 NANO/FURY は互換性なし
WX 5100は非互換で、WX 7100, WX8200, WX 9100は10.15.1から互換性あり
NVIDIA GeForce は互換性なし

また、Mac mini 2018では以下の制約があるそうです。

10.15.1ならば、Vega 56, Vega 64, WX8200, WX9100, Radeon 5700, Radeon 5700XTはGPUカードにモニターを接続してブートできるものの、
RX 560/570/580/590の場合はiGPUのHDMI端子にのみブート表示が出る。

以前の情報

古いmacOSに関する記述についてはこちらもご覧ください。

Sonnetの互換GPUリスト (10.13.4以降)

Sonnetの互換GPUリスト (10.13.2以降)

base64コマンドの使い方

Wed, 16 Oct 2019 23:52:12 +0900

Base64変換（文字列を変換）

echo -n "AMD RX 580" | base64
QU1EIFJYIDU4MA==

Base64変換（16進数を変換）

echo -en "\x9B\x3e\x00\x00" | base64
mz4AAA==

Base64逆変換（文字列をデコード）

echo QU1EIFJYIDU4MA== | base64 -D
AMD RX 580

Base64逆変換（16進数をデコード）

echo mz4AAA== | base64 -D | hexdump
0000000 9b 3e 00 00 
0000004

いつも使い方を忘れてしまうのでメモしておきます。Base64はバイナリーデータを文字で表記する場面でよく使用されます。config.plistでもお馴染みです。なので、時々、変換・逆変換したいことがあります。そのためのツールはたくさんありますし、変換してくれるwebページもあります。でも、ターミナルから使えるbase64コマンドならすぐに使えて便利です。使い方さえ忘れていなければ。

Base64の仕組み

文字しか表記できない・通信できない環境で、任意のデータを効率良く表現するために考えられました。英大文字、英子文字、数字、記号(+と/) に数字を割り当てます。アルファベットは26文字なので、Aが0でZが25です。引き続き小文字のaに26を割り当ててzまで使うと51まで表現できます。この後、数字の0 (=52)から9 (=61)を割り当てると、61まで表現できます。後2つあればキリが良いので、+ (=62)と/ (=63)を最後に使います。これで、A~~Z, a~~z, 0-9, +, /を使って0から63を表現できます。64進数です。ビット数は6ビットになります。

通常のコンピュータのデータはバイト単位、8ビット単位です。なので上位から6ビットごとに区切って変換します。端数は0ということにします。例えば、ASCIIコードで大文字のAは、0x41です。ビットで表すと、0100 0001です。6ビットに分けると、010000 01です。端数に0を追加すると、010000 010000です。010000は10進数で16になり、これが2個続きます。16には、Base64では、17番目のアルファベットQが割り当てられています。なのでBase64で表すとQQになります。また、Base64では4文字の倍数になるよう調整します。足りない部分には＝を追加します。ということで、大文字AをBase64で表現すると、QQ==になります。

base64コマンド

macOSにはターミナルから使えるbase64コマンドがあります。使い方は以下です。

 base64 [-h | -D | -d] [-b count] [-i input_file] [-o output_file]

I, oオプションで入出力ファイルを指定できますが、指定しなければ標準入出力が使用されます。hはヘルプ表示です。bで数値を指定すると、出力に改行を入れてくれます。Dオプションしか使うことはないと思います。オプションなしならエンコード、Dオプションでデコードです。

標準入出力を使うので、echoコマンドをパイプします。echo helloとタイプするとhelloという文字が表示されるのですが、デフォルトでは最後に改行が入ります。-nオプションで改行を出さないよう指定できます。echoコマンドを、16進数標示するhexdumpコマンドにパイプしてみます。こんな感じです。0aが改行コードです。

% echo hello | hexdump
0000000 68 65 6c 6c 6f 0a 
0000006
% echo -n hello | hexdump
0000000 68 65 6c 6c 6f 
0000005

なのでhelloという文字列だけ（改行は不要）をBase64にしたい場合は、

% echo -n hello | base64
aGVsbG8=

とします。結果が7文字だったので＝が1個追加されました。-Dオプションで元に戻してみましょう。

% echo aGVsbG8= | base64 -D
hello

echoで16進数を出すのはちょっと面倒です。0x01, 0x02, 0x03という3バイトを出すには、”\x01\x02\x03″と書きます。\xで次の2文字が16進数だということを表現します。またこのように\xで16進数渡すためには-eオプションが必要です。hexdumpにパイプして確認します。

% echo -en "\x01\x02\x03" | hexdump
0000000 01 02 03 
0000003

これをbase64にパイプすれば、変換できます。

% echo -en "\x01\x02\x03" | base64 
AQID

逆変換して確認しておきます。

% echo AQID | base64 -D | hexdump 
0000000 01 02 03 
0000003

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

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

マザーボード

マザーボードは、第9世代CPUをサポートするZ390, H370, B360などのチップセット搭載マザーボードを選ぶことになります。新規に購入するなら、古いマザーボードを選ぶ理由はないので、最新のものを選んだ方が良いと思います。安く自作するためにパーツの一部を中古で購入することもあるとは思いますが、マザーボードは新品が良いと思います。中古のマザーボードは、部品が劣化していることもあるようで、動作が安定しない印象があります。HackintoshはそもそもOSレベルで怪しいことをやりますので、ハードウェアは信頼性のあるものを選んでおきたいと思います。

マザーボードメーカーに関して、昔はGigabyteの互換性が高いと言われていましたが、今は、あまり関係ないです。カーネル読み込みのためのメモリー確保の容易さを考えるとASUSやASRockが良いように思います。MSIのメモリーマップも癖がありますが、対応は容易です。Gigabyteは、メモリー確保設定が難しい機種もあるようです。詳しくはこちらをご覧ください。いずれにしても、ネット上に成功例があり、詳しく解説されているマザーボードを選ぶのが良いと思います。

グラフィックス

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 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を入れます。このドライブでちゃんと起動することを確かめておけば、問題を切り分けることができて楽です。以下の記事では、この方法でインストールしましたので参考にしてください。

Cloverとkextを入れる

USBメモリーを作ってインストール先で起動させる方法でも、親マシンでmacOSを直接インストールする方法でも、いずれの場合でも、Hackintoshを起動させるためのESP部分を作成することが1番困難な部分です。ここには、Cloverとkext類を入れます。新しいmacOSに対応していて、各種バグが改善されている最新版をダウンロードすることをお勧めします。Cloverインストールの手順はこちらにも書いてあります。

CLOVER 4988 でEFIドライバ関連が変更されました

Catalinaの出る少し前に、Cloverが管理するESPの構成が少し変わりました。古い説明を読む場合は、注意してください。

以下では、config.plistの例を示して、説明しました。

config.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。

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

config.plistの解説では、Corpnewtさんのバニラガイドが簡潔で良いと思います。「Coffee Lakeマシンのためのconfig.plistの作り方」のページを以下で紹介しています。

Cloverをインストールしたら、次にkext類をESPの部分に入れます。kextについてはいくつかの記事で解説しましたが、こちらが簡潔かもしれません。

CORPNEWTさんのバニラガイド~ Clover設定とkext

なお、CatalinaでCloverインストーラが動かない問題もあるようです。SIPを解除すればインストールできます。こちらをご覧ください。

CatalinaにしたらCloverがインストールできない

macOS環境を整える

以上の設定で、とりあえずの起動が行えることを目指します。それができたら、さらに、グラフィックスカード、Ethernet, サウンドの設定をします。以下の記事が参考になるかと思います。

r/hackintosh - Clover - Cannot Install w/o Ensuring File System is Read/Write

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を解除しても、次の次の起動ではちゃんと元に戻るそうです。

でもこの方法だと、インストーラを動かすまでに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メモリを持っていると、復旧作業が楽です。

パワーマネジメント入門

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 ライセンスに準拠します。）

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を利用できます。

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から必ず展開するように指定します。

Appleキーボードの☀︎キーで明るさ調整する

Tue, 06 Aug 2019 20:18:29 +0900

Appleキーボードにはディスプレイの明るさを調整するキーがあります。ところが、このキーを押しても外付け液晶ディスプレイの明るさは変化しません。そこでアプリケーションを入れて明るさ調整を可能にします。

太陽のキー

キーボードのF1, F2キーには、お日様マークが書いてあり、これに明るさ調整機能が割り当てられています。

本物のMacではこのキーを使って画面の明るさを調整できます。とはいえ、調整できるMacは、MacBookシリーズとiMacシリーズだけです。それ以外のデスクトップMac（Mac miniとMac Proだけですが）に市販のディスプレイを接続した構成では、このキーは機能しません。アップル社はMacBookとiMac以外には力を入れていないので、気にしていないのだと思います。なのでこれらのマイナーマシンユーザは、ディスプレイの調整ボタンに手を伸ばして、明るさ調整をする必要がありました。

VESAのDDC

外付けディスプレイだから、コンピュータから明るさを調整できないのは仕方ない、と思っていました。でもディスプレイの標準化を進めているVESA (Video Electronics Standards Association) では、コンピュータプログラムからディスプレイを設定するためのプロトコルを決めているようです。それがDDC (Display Data Channel) です。これを使えば、コンピュータからディスプレイの明るさ・コントラストを調整できて、さらにはディスプレイ内蔵（されていれば）スピーカ音量も調整できます。Mac miniやMac Proには通常はVESA規格のディスプレイが接続されるので、macOSでもDDCをサポートしてくれれば良いのにと思います。

DDCを使うアプリケーション

DDC機能を利用して、コンピュータからディスプレイの明るさやコントラストなどを調整するアプリケーションが複数開発されています。このようなアプリはWindowsやLinuxにもあるようで、macOSにもあります。私はこちらの記事へのコメントで教えていただき知りました。Redditでも紹介されていました。その一つがNativeDisplayBrightnessだそうです。でもファンクションキーへの割り当てなどで不具合があるようで、以下のMonitorControl.appが良いようです。記事冒頭は、このアプリケーションのアイコンです。

Release MonitorControl v1.3.0 · MonitorControl/MonitorControl

MonitorControl.appを使う

メニューバーから明るさ調整

GitHubのサイトからMonitorControl.appをダウンロードして、起動するとメニューバーにアイコンが表示されます。

これでモニターの明るさと音量が変えられます。Preferences…のメニューから設定すれば、コントラストも調整できます。Preferencesからは動作や、キーボードショートカット設定、ディスプレイ選択などを行えます。

ショートカットキーの設定

MonitorControl.appを起動すると以下のようなダイアログパネルが表示されます。キーボードの明るさキーから調整するためにはショートカットキーを設定してくださいという内容です。

その裏側には日本語のダイアログも出ていました。どのアプリケーションが動いていても、このアプリがイベントを受け取れるように許可してくださいという意味です。

そこで、「システム環境設定」「セキュリティとプライバシー」「プライバシー」「アクセシビリティ」と選択して、MonitorControl.appに「コンピュータの制御を許可」します。

これでキーボードから明るさ調整できるようになります。F1, F2キーを押すと画面に明るさ状態が表示され、これを変更できます。画面明るさがキーボードで簡単に変更できるのはなかなか快適です。

音量もキーで変更できるようにPreferences…で設定すれば、音量キーによりボリュームも変更できます。HDMIとは別にサウンドを設定しているので、下の写真ではmacOSのボリューム表示とディスプレイのOSDで表示されるボリューム表示が同時に出ています。

Apple純正キーボードの他にLogitech (Logicool) のキーボードも試してみました。F1/F2キーで明るさ変更できて、音量キーで音量調整できました。

自動起動

MonitorControl.appのメニューのPreferences…から、ログインで自動的に起動するというオプションが選べます。ただ、私の環境ではうまく動かなかったです。その代わり、「システム環境設定」「ユーザとグループ」「ログイン項目」にMonitorControl.appを追加したところ、問題なく自動起動するようになりました。

ExternalDisplayBrightnessというのもある

コメントでこういうアプリもあると教えてもらいました。本物のMacでも必要な機能なので、いろいろな人が作ってくれているようでありがたいです。

ExternalDisplayBrightness | František Nesveda

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項目が、パッチ対象の名前かどうかを調べておいて、パッチ対象の名称であった場合は、何か問題があった時に名称変更のパッチを試すのが良いと思います。

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を使えば良いようです。詳細は以下をご覧ください。

tonymacx86式インストール手順 (その2: MultiBeast)

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式インストール手順 (その3: バニラ化と調整)

macOSのためのGPUの選び方

Sun, 16 Jun 2019 17:25:04 +0900

GitHub - khronokernel/Catalina-GPU-Buyers-Guide: Host for files for the Catal…

CatalinaのためにどのGPUを選んだら良いかという記事がありましたので抄訳して紹介します。また、その後のmacOSでNaviシリーズがサポートされたので、この情報を追記しました。結論は、AMDならばRadeonの

RX 6600, RX 6600 XT, RX 6800, RX 6800 XT, RX 6900 XT
RX 5500, RX 5500 XT, RX 5600, RX 5600 XT, RX 5700, RX 5700 XT
RX 460 / 560 / 470 / 570 / 480 / 580 / 590
RX Vega 56 / 64 / VII

を、Nvidiaならば

Kepler シリーズ (GTX 6xx, 7xx など)

が動きます。ただし、MontereyからKeplerシリーズは動かなくなりました。古いmacOSからドライバを持ってくることで動かすことは可能です。

Releases · chris1111/Geforce-Kepler-patcher

（ここから抄訳）

NvidiaとWebDriverの現状

WebDriverが使えなくなった状況のままMojaveからCatalinaに移行しそうです。おそらくはこのあと、MojaveでもCatalinaでもWebDriverはサポートされないと思われます。ただしKeplerベースのGPUを使っているユーザは引き続きmacOSネイティブのドライバが利用できます。

なぜWhateverGreenが必要なのか？

macOSがネイティブにサポートするグラフィックスカードなのに、なぜWhateverGreenとLiluを使う必要があるのでしょうか？その理由は、PCとMacの内部配線が異なるため、Hackintoshでうまく機能しないためです。これを回避するために、デバイスの名前変更、フレームバッファ接続、オーディオコネクタのパッチ適用、ACPIを介したaty_config、cail_propertiesの変更などが必要です。WhateverGreenとLiluがこれらの作業を行ってくれます。内部構造に詳しい人達によってWhateverGreenは開発され、必要に応じてアップデートされていますので、これを使用しない理由はありません。以下の推奨カード、iGPUのすべてでWhateverGreenとLiluを使ってください。

そのほかに知っておくべきこと

macOSはSLI、Crossfire、複数コアGPU (Radeon Pro Duo)のいずれもサポートしていません
HDMI / DisplayPortを介して音声出力するには、AppleALC.kextとその他のIO-REG編集が必要になる場合があります
GPUオーバークロックができるのはVega 10 GPUだけです（PyVegaというツールが必要）
サポートされているGPUとサポートしていないGPUを併用するとスリープやその他の機能が中断される問題があります。詳細については、GPUを無効化するためのガイドを参照してください。

動くAMD GPU

Navi シリーズ

Catalina 10.15.1からRX 5500, 5600, 5700シリーズがサポートされました。
Big Sur 11.4からAMD RX 6800, RX 6800XT, RX 6900XTがサポートされました。
Monterey 12.1からAMD RX 6600, 6600 XTがサポートされました。

Naviシリーズでは以下の GPUがネイティブにサポートされています。ただし起動オプションに、agdpmod=pikeraを追加する必要があります。

AMD Radeon RX 6600, RX 6600 XT, RX 6800, RX 6800 XT, RX 6900 XT
AMD Radeon RX 5700, RX 5700 XT, RX 5700 XT 50th Anniversary
AMD Radeon RX 5600, RX 5600 XT
AMD Radeon RX 5500, RX 5500 XT

Vega 20シリーズ

MojaveからVega 20シリーズのGPUがネイティブにサポートされています。すなわち

Radeon VII

が動きます。

Vega 10シリーズ

High SierraからVega 10シリーズのGPUがネイティブにサポートされています。すなわち

Vega 56
Vega 64
Vega 64 Liquid
Vega Frontier Edition
Radeon Pro WX 9100
Radeon Pro WX 7100

が動きます。Vega 10で避けるべきGPUブランドはXFXとSapphireです。ビデオBIOSとmacOSの互換性に問題があるようです。

Radeon 400/500 シリーズ (Polaris)

PolarisはmacOSによりネイティブにサポートされています。以下のシリーズです。ローエンドのRX550はPolarisではなくLexaコアなのでmacOSでサポートされていません。Polarisシリーズで避けるべきGPUブランドはXFXとASRockです。これもビデオBIOSとmacOSの相性に問題があります。解決できたという報告もありますが駄目なこともあるようです。避けたほうが無難です。

（訳注：コメントいただいた内容によると、以下の状況でASRockが問題なく使用できたそうです。ASRock, Phantom Gaming D RX580、macOS 10.15.4 、Metal: 対応、機能セットmacOS GPUFamily2 v1、CPU: Core i7 2600K、RAM: DDR3 32GB、M/B: ASUS MAXIMUS V GENE。またフォーラムでもASRockのRX 580が動いた報告をいただいています。ASRockを避ける必要はどうやら無いようです。）

RX 460/560/560X
RX 470/570/570X
RX 470D
RX 480/580/580X
RX 590
WX 2100
WX 3100
WX 4100
WX 5100

GCN 3 以前のカード

GCN 3以前のカードは、CatalinaでMetalをサポートすると思われますが、一部のカードは動かない可能性もあります。おそらくHD 7XXXシリーズ以降のGPUはMetal互換ですが、Catalinaでの動作確認はされていません。

Radeon R9 3xx (Fiji)

FijiもCatalinaでサポートされるとは思われます。しかし報告がありませんのでR5およびR7カードの成功を保証することはできません。また、リファレンスデザインと違うカードでは、macOSで動かすために多くの作業を必要とする場合があります。という条件のもとで、サポートされているカードは以下です。

R7 240
R7 250
R9 260/360
R7 260x/360x
R7 265
R7 270/370
R9 270X/370X
R9 280/380
R9 280x/380x
R9 290/390(FakeID が必要)
R9 290X/390X
R9 390(FakeID が必要)
R9 Nano
R9 Fury
R9 Fury X

動かないAMD GPU

Navi シリーズ (RX 5000)

macOSにはNavi用ドライバがありません。このカードが入っているとスリープなどの機能に支障をきたします。その場合は、サポートされていないGPUを無効化にするためのガイドを参照してください。以下のカードはサポートされていません。

訳注：「動くAMD GPU」のセクションに追加したように、Catalina 10.15.1から元記事で紹介されている以下のカードは動きます。

RX 5700
RX 5700 XT
RX 5700 XT 50th Anniversary Edition

Lexa シリーズ (RX 400/500)

Polaris GPUに似た型番ですが、全然異なり、どのバージョンのmacOSもサポートしていません。これもスリープ機能などで問題を引き起こしますので、併用する場合は、サポートされていないGPUを無効化にするためのガイドを参照してください。以下のカードはサポートされていません。

RX 540/X
RX 550/X

動くNvidia GPU

Kepler シリーズ (GTX 6xx, 7xx)

KeplerシリーズはCatalinaで動作する唯一の100％ネイティブのNvidiaカードです。このうちGTX 650Ti、660、660tiで問題が報告されていますが、これはmacOSがGK106コアをサポートしていないことが原因です。（訳注：コメントでいただいた情報によると、Mojave,Catalina環境では、GK106のバグは直されたようで、問題なく動くようです。）

もう一つの注意点は、初期の製品には、FermiコアなのにKeplerコアと紛らわしい型番のローエンド製品があることです。また後期の製品のうち、GTX 745、750、750tiはKeplerではなく次世代のMaxwellですので注意が必要です。（訳注：こちらのページを見ると、どの製品がどのアーキテクチャなのかわかります。コア名がGFなのがFermi, GKなのがKepler, GMなのがMaxwellです。GKの製品を選べば良いです。）

動作するカードは以下です。

GTX Titan (GK 110 Maxwell core)
GTX Titan Black (GK 110 Maxwell core)
GTX Titan Z (macOSでサポートされている数少ないデュアルGPUの一つ)
GTX 780/Ti
GTX 770
GTX 760/Ti
GT 740
GT 730 (GK208 variant)
GT 720
GT 710
GTX 690 (macOSでサポートされているもう一つのデュアルGPU)
GTX 680
GTX 670
GTX 660Ti
GTX 660(MUST BE RUNNING A GK 104 core, NOT GK 106)（訳注：GK 106もokらしい。)
GTX 650(GK 107 core)
GT 640(Kepler edition, GK 107/208 core)
GT 630(Kepler edition, GK 107/208 core)
Quadro 410
Quadro K420
Quadro K600
Quadro K2000/D
Quadro K4000/D
Quadro K4200
Quadro K5000
Quadro K5200
Quadro K6000

動かない nVidia GPU

Turing シリーズ (GTX 20xx, 16xx)

以下のカードはどのmacOSでも動きません。

Titan RTX
RTX 2080/Ti
RTX 2070
RTX 2060
GTX 1660/Ti
GTX 1650/Ti
Quadro RTX 4000
Quadro RTX 5000
Quadro RTX 6000
Quadro RTX 8000

Volta シリーズ

以下のカードもどのmacOSでも動きません。

Titan V
Titan V CEO Edition
Quadro GV100

Pascal Series (GTX 10xx)

PascalとMaxwellのサポート状況についてはみなさんご存知と思いますが、簡単に繰り返します。MojaveとCatalinaではサポートされていませんが、High Sierra 10.13.6以前ならばNvidiaのWebDriverとWhateverGreenの組み合わせで動きます。この条件で動くカードは以下です。

GTX Titan X(GP 102-400 Pascal core)
GTX Titan Xp(GP 102-450 Pascal core)
GTX 1080/Ti
GTX 1070/Ti
GTX 1060
GTX 1050/Ti
GT 1030
Quadro P400
Quadro P600
Quadro P620
Quadro P1000
Quadro P2000
Quadro P4000
Quadro P5000
Quadro P6000
Quadro GP100

Maxwell シリーズ (GTX 9xx, 745, 750 とその ti版)

GTXでは900番台がMaxwellです。ただ、GTX 745, 750, および750tiは型番が紛らわしいですがMaxwellベースです。MaxwellシリーズもPascalと同じ状況です。つまり、以下のカードは、High Sierra 10.13.6以前ならばNvidiaのWebDriverとWhateverGreenの組み合わせで動きます。

GTX Titan X(GM 200 Maxwell core)
GTX 980/ti
GTX 970
GTX 960
GTX 950
GTX 750/ti
GTX 745
Quadro K620
Quadro K1200
Quadro K220
Quadro M2000
Quadro M4000
Quadro M5000
Quadro M6000
NVS 510

Intel CPU 内蔵 GPU

iGPUを動かすために、FrameBufferパッチを適用する必要があります。また、Pentium、Celeron、Atom CPUに存在するiGPUは、ネイティブにサポートされたことがなく、かなりの作業が必要になるため、除外します。

Westmere i3/5/7-xxx

単にHD Graphicsと呼ばれていたiGPUです。High Sierra 10.13.6までのmacOSで動きます。残念ながらMojaveではサポートされなくなりました。古いkextを使って無理やり動かすことは可能です。

Sandy Bridge i3/5/7-2XXX

HD 2000, HD 3000です。これもHigh Sierra 10.13.6までのmacOSで動きます。残念ながらMojaveではサポートされなくなりました。古いkextを使って無理やり動かすことは可能です。

Ivy Bridge i3/5/7-3XXX

HD 4000に関しては、Catalinaで完全にネイティブに動きます。一方、HD 2500に関しては、Mojaveで一部分しかサポートされず、Quick Sync機能がサポートされていません。

Haswell i3/5/7-4XXX

以下のiGPUです。ほとんどがCatalinaでネイティブに動きます。ただHD4400だけは、DeviceID改変 + FakePCIID.kext + FakePCIID_HDGraphics.kextが必要か、もしくは、APCIパッチが必要です。

HD 4200
HD 4400(FakeID が必要)
HD 4600
HD 5000
HD 5100
HD P4600(動くはず)
HD P4700(動くはず)

Broadwell以降のiGPU

以下のiGPUです。すべての動作報告が得られているわけではありませんが、Catalinaで使えると考えられます。

HD 5300
HD 5500
HD 5600
HD 6000
HD 6100
HD 6200
HD P5700(動くはず)
Iris Pro P6300

Skylake i3/5/7-6XXX

以下のiGPUです。すべての動作報告が得られているわけではありませんが、Catalinaで使えると考えられます。

HD 510
HD 515
HD 520
HD 530
HD P530
Iris 540
Iris 550
Iris Pro 580
Iris Pro P555
Iris Pro P580

Kabylake i3/5/7-7XXX

以下のiGPUです。すべての動作報告が得られているわけではありませんが、Catalinaで使えると考えられます。ただし、Pentium G4560に搭載されているHD 610は動きません。

HD 615
HD 620
HD 630
Iris Plus 640
Iris Plus 650

Kabylake refresh/ Coffeelake i3/5/7-8XXX/9XXX

以下のiGPUです。すべての動作報告が得られているわけではありませんが、Catalinaで使えると考えられます。ただし、i3 8100と8350Kはそれ以外のCPUとは違うUHD 630を使用しています。

（訳注：対応方法はこちらをご覧ください。）

UHD 610
UHD 620
UHD 630
Iris Plus 655

早い話、何を買ったら良いの？

現時点でお勧めできるカードはAMDのPolaris(Rx 4xx, 5xx) 以降だけです。AMDのGCN 3以前とNvidiaのKeplerのような古いカードも動きますが、いつサポートを打ち切られるかわかりません。なので以下がお勧めカードです。リファレンスカードが一般的に安全です。XFXは避けたほうが良いです。

RX 460/560
RX 470/570
RX 480/580
RX 590
RX Vega 56
RX Vega 64
Radeon VII
RX 5500, RX 5500 XT, RX 5600, RX 5600 XT, RX 5700 / 5700 XT
RX 6800, RX 6800XT, RX6900XT

（抄訳おわり）

Redditの反応

この元記事に関してredditでいくつかコメントがありました。

VegaではXFXとSapphireを避けるべき？

r/hackintosh - Avoid Sapphire and XFX Vega?

これに対するコメントは以下のようでした。

SapphireブランドのVega 56を使っているが問題は無い
XFXブランドのVegaは明らかに避けた方が良い
SapphireブランドのVegaは快調に使えている報告もあるがトラブっている報告もある。トラブルは厄介で解決したという報告は稀。
Vegaを買うならMSIかASUSが良い。Gigabyteも良さそうだけどあまり出回っていないためか2件しか動作報告が無い。

Radeon VIIのブランド毎の違いはある？

r/hackintosh - Differences in Radeon VII brand?

これに対するコメントによると、「Redeon VIIは全てAMDが作っているリファレンスカードで、VBIOSのソースコードも提供されていない。そのためどのブランドのカードも同じもの」なのだそうです。

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

起動しないマシンを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 .

のようにしてコピーすることが可能です。

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

のように表示されます。

古いmacOSをコレクションする

Mon, 11 Feb 2019 12:54:54 +0900

過去の特定のバージョンのmacOSが必要になることが稀にあります。でも古いバージョンのmacOSは入手困難です。アップルから正規に入手できる時期に忘れずにダウンロードして確保しておきましょう。
（更新：CatalinaとBig Surの情報を追記しました。2021/10/29）

古いmacOSが必要になる時

OSの更新で使えなくなったハードウェアでマシンを組もうと思う時、古いOSが必要です。例えば10.14 MojaveからIntel HD Graphics 3000のドライバが削除されてしまったので、Sandy Bridgeの内蔵GPUは動かなくなってしまいました。そこで10.12 SierraからIntel HD Graphics 3000のドライバを持ってくると動きました。10.13 High Sierraのドライバでは動きませんでした。2世代前のmacOSをたまたま持っている人だけが対応できる方法です。

また、最初のiMac Proには10.13.2が搭載されていましたが、この時に10 GbpsのEthernetがmacOSで動くようになりました。搭載されているのは、一般的に使われているAquantia AQC107というチップです。ただし拡張カードのファームウェアが違うのでそのままでは動きません。10.13.3になった時に、なぜかmacOS対応のファームウェアが含まれていて、10 Gbpsカードを挿したままアップデートするとファームウェアが書き換えられてmacOSで動くと報告されています。10.13.2以下のHigh Sierraをたまたま持っている人だけが対応できる方法です。

以上はかなりニッチな事例です。しかしMojaveでNVIDIAのドライバが動かなくなったので、いまだにHigh Sierraなどの古いmacOSが必要になる場面は多いかと思います。

古いmacOSの入手方法

App Storeアプリから入手する

App Storeから一旦購入したアプリケーションは、いつでも入手可能なところがApp Storeの優れた点です。この原則はmacOSでも有効で、一旦ダウンロードした古いmacOSは「購入済み」ボタンを押すとApp Storeの画面に現れました。

でもMojaveになって、これが出来なくなりました。Mojaveからは、左下の名前をクリックすると現れる「アカウント」のページに、購入済みのアプリケーションが現れるようになりました。ただmacOSは現れません。私の場合は、なぜか古いmacOSのPublic BetaやGM Candidateが表示されます。昔購入したServer版も現れます。でもmacOSは現れません。現行のMojaveだけは、検索窓からMojaveを検索すると現れます。

ということでまだMojaveに移行していないみなさんは、High Sierra以前で稼働しているうちに、昔に購入したmacOSをダウンロードしておきましょう。

プロダクトIDを手掛かりに入手する

App Storeで配布されているソフトウェアは、プロダクトIDという一意の番号で管理されています。これを知っていればMojaveで選択肢に現れない古いmacOSをダウンロードできる可能性があります。

こちらのサイト

OS X 10.7 Lion ~ macOS 10.13 High Sierraまでのインストーラーアプリをダウンロ…

ではいくつかのmacOSのプロダクトIDを紹介してくれています。それによると、

OS X 10.7 Lion 444303913
OS X 10.8 Mountain Lion 537386512
OS X 10.9 Mavericks 675248567
OS X 10.10 Yosemite 915041082
OS X 10.11 El Capitan 1018109117または 1147835434
macOS 10.12 Sierra 1127487414
macOS 10.13 High Sierra 1246284741
macOS 10.14 Mojave 1398502828
macOS 10.15 Catalina 1466841314
macOS 11 Big Sur 1526878132

だそうです。この番号を使って、

https://itunes.apple.com/jp/app/idプロダクトID?mt=12

にアクセスすると古いmacOSのApp Storeアプリ画面が開きます。ただ、現時点で試したところではYosemite以前はこんなダイアログが出て利用できないようです。

この方法でダウンロードできるのは以下のバージョンでした。

El Capitan https://itunes.apple.com/jp/app/id1147835434?mt=12
Sierra https://itunes.apple.com/jp/app/id1127487414?mt=12
High Sierra https://itunes.apple.com/jp/app/id1246284741?mt=12
Mojave https://itunes.apple.com/jp/app/id1398502828?mt=12
Catalina https://itunes.apple.com/jp/app/id1466841314?mt=12
Big Sur https://apps.apple.com/jp/app/macos-big-sur/id1526878132?mt=12

masコマンドを使う

上記のサイトではHomebrewで導入できるmasコマンドを紹介してくれています。コマンドラインからMacのApp Storeにアクセスするためのアプリケーションです。ターミナルで以下のようにすれば、Homebrewをインストールして、次にmasをインストールできます。

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew install mas

単にmasとだけタイプすると

mas
Available commands:

account Prints the primary account Apple ID
help Display general or command-specific help
home Opens MAS Preview app page in a browser
info Display app information from the Mac App Store
install Install from the Mac App Store
list Lists apps from the Mac App Store which are currently installed
lucky Install the first result from the Mac App Store
open Opens app page in AppStore.app
outdated Lists pending updates from the Mac App Store
reset Resets the Mac App Store
search Search for apps from the Mac App Store
signin Sign in to the Mac App Store
signout Sign out of the Mac App Store
uninstall Uninstall app installed from the Mac App Store
upgrade Upgrade outdated apps from the Mac App Store
vendor Opens vendor's app page in a browser
version Print version number

とヘルプが出ます。

mas intall プロダクトID

とすればダウンロードできるようです。info, searchなどはあまり効きません。それに出てこなくてもinstallコマンドは動くことがあるようです。

mas install 444303913

でプロダクトIDが分かっているうちの一番古いLionをダウンロードしてみました。

App Storeアプリからダウンロードする方法も、masコマンドも、どちらも購入したことのあるmacOSしか再入手できません。一旦はダウンロードしておく必要があります。

マイナーバージョンを入手する

今までの方法で、運が良ければ古いmacOSを入手できます。でも入手できるのは、それぞれのメジャーバージョン（MojaveとかHigh Sierraなどのバージョン）の最終版です。例えばHigh Sierraなら10.13.6が入手できます。では10.13.3が必要な場合はどうしたら入手できるでしょうか？

アップル社は統合アップデート(combo update)を長期にわたって配布してくれています。統合アップデートなら同じメジャーバージョンのすべての古いバージョンからアップデートできます。統合アップデートは、サポートページで検索したり、

[Apple - Support - Downloads](https://support.apple.com/downloads/combo update)

Googleの検索で「macOS 10.13.3 combo update」などと検索すると出てきます。私が探せた一番古いcombo updateは10.2.4でした。

OSメーカとしては、少しでも新しいバージョンにアップデートして欲しいので、全てのマイナーバージョンへのアップデートを配布し続けてくれているのだと思います。なのでできるだけ最初のマイナーバージョンを持っていれば、多くのマイナーバージョンへアップデートできます。例えば、10.13.0を持っていれば、10.13.1から10.13.6のすべてにアップデートできます。10.13.0は1ヶ月少しだけ配布されていました。今では入手できない貴重なバージョンですので、大事に保存しておきましょう。

LionとMountain Lionが無償配布

（追記：2021/7/18）Appleの公式サポートページから、LionとMountain Lionが無料でダウンロードできるようになったようです。以下です。

Mac OS X Lion Installer

Mac OS X Mountain Lion Installer

まとめ

古いmacOSを入手可能にしておくためには以下のことが重要です。

どのメジャーバージョンのmacOSも一度はダウンロードしておくと良いです。例えば、Mojaveは嫌いだからといって次のバージョンが出るまでダウンロードせず放置していると、正規に入手するチャンスを逃してしまいます。
古いmacOSがApp Storeで入手できることをあてにしてはいけないです。いつダウンロードできなくなるかわかりません。手元にコピーを置いておくべきです。
できるだけ最初のマイナーバージョンを持っておくと良いです。全部のマイナーバージョンのコピーを集めておくのは面倒ですし、ストレージの場所も必要です。10.xx.0を持っていれば統合アップデートでどのバージョンにもアップデートできます。実用上は一番安定と思われる最終バージョンも持っていると良いと思います。High Sierraなら10.13.0と10.13.6を持っていれば完璧なコレクションになります。

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をインストールする手順を書いておきましたので、参考にしてください。

Hackintoshのパーツ選び【その1：CPU編】

CPUは、最新の第9世代Coffee Lake-S Refreshが良いと思います。Macで採用されている最新CPUは第8世代です。例えば最新Mac miniでは、モバイル版ではありますが、第8世代CPUが使われています。ピンが半田付け方式なだけで、デスクトップの第8世代Coffee Lake-Sと同じCPUですので、第8世代Coffee Lake-Sでも良いでしょう。インテルは現在、CPUの量産体制に問題があり、第8世代もローエンドモデルを中心にまだ現役ですので、入手は容易です。

そうすると、マザーボードは、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で良いかと思います。

macOSのインストール途中で、何度か再起動することがあります。親マシンがHackintoshの場合は、インストール途中のCloverの起動画面で、”Boot macOS Install from (インストール先のボリューム名)”という項目を選びます。

Cloverとkextを入れる

親マシンで起動できるmacOSディスクが出来上がったら、親マシンに接続したまま、Cloverをインストールします。Cloverインストールの手順はこちらにも書いてあります。

config.plistの例を示して、説明しました。

config.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。

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

Cloverをインストールしたら、次にkext類をESPの部分に入れます。kextについてはいくつかの記事で解説しましたが、こちらが簡潔かもしれません。

CORPNEWTさんのバニラガイド~ Clover設定とkext

macOS環境を整える

Clover EFI bootloader / Themes / [649fa8] /themes

Cloverのテーマ

Sun, 27 Jan 2019 17:00:26 +0900

Cloverが起動した直後に、起動ドライブや起動オプションの選択をする画面があります。この画面はカスタマイズ可能で、色々な人が凝った画面を作ってくれています。これらの「テーマ」は以下のサイトなどで配布されています。

設定方法

ここから気に入ったテーマのフォルダをダウンロードして、EFI/CLOVER/themes/フォルダの中に入れます。次に、（例えばフォルダの名前がMinimalismの場合）config.plistで

	<key>GUI</key>
	<dict>
		<key>Theme</key>
		<string>Minimalism</string>
	</dict>

のように設定します。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>

以上のようになります。

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のいくつかの項目を自動で作ってくれますが、完全ではありません。こちらのガイド

を見て、少なくとも以下の項目は作成しておくのが良いです。

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ポートがあるかもしれません。こちらを見て対応すると良いです。

tonymacx86式インストール手順 (その1: UniBeast)

おまけ：名前の由来

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のステップは以下で説明しました。

この記事では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に関するちゃんとした設定はあとで行いましょう。詳しくはこちらをご覧ください。

tonymacx86式インストール手順 (その3: バニラ化と調整)

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が何をどこにインストールしたのか、それをどう改善していけるかを調べてみたいと思います。こちらに続きます：

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が消えなくなります。

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ドライバは、インストーラで表示されなかったと思うのですが、最近では全部表示されるようになっています。以下の８個がデフォルトでインストールされる設定になっているようです。

デフォルトで選択されているので重要なドライバだとは思います。そのうち調べて、機能をメモしていきたいと思います。

一部はこちらを参考にしました。

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 4558で登場したApfsDriverLoader.efi

以下のドライバの役割と、推奨順番を説明しました。推奨順番はこの順番です。

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を手作業でコピーしておいた方が良い事もあります。今後改良されるのだとは思います。

その他のドライバ

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より少し前くらい

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

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/

Hackintoshのパーツ選び【その5：SSD】

無線アダプタ、SSD, そのほかのパーツについても紹介しておきました。

/posts/138/

Hackintoshのパーツ選び【その6：その他】

マザーボードのBIOS/UEFIを設定する

マザーボード (BIOS) 設定

必要なソフトウェアを入手する

Clover EFI bootloaderとefiドライバー

“Clover EFI bootloader”で検索します。以下が本家かと思われます。

https://sourceforge.net/projects/cloverefiboot/

こちらでも最新版が配布されています。

RehabMan / OS-X-FakeSMC-kozlek / Downloads — Bitbucket

Cloverをダウンロードすると、インストーラ、efiドライバ、テーマファイルなども一緒に入手できます。

kext類

Mac上で導入用のUSBメモリを作る

/posts/93/

Cloverインストールの手順はこちらにも書いてあります。

config.plistの例を示して、説明しました。

config.plistの中でも、機種を設定するSMBIOSセクションの記述は重要です。その部分を説明したのがこの記事です。

対象マシンをUSBメモリで起動してmacOSを導入する

このUSBメモリを、インストール先のマシンに挿して起動させます。起動しない場合は、Cloverの設定やkextの選定を確認します。

USB 3.0/3.1のUSBメモリを使った場合、Cloverの選択画面は現れるけど、そのあとのプロセスで失敗することがあります。macOSにはUSBの個数に制限があり、3.0/3.1のポートが2.0としてしか動かない場合があるからです。対応方法は以下の記事の「ポートを増やすパッチ」をご覧ください。

HackintoshをHigh Sierraにする

ただ、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のコピーを行う方法の参考になるかと思います。

macOS環境を整える

USBに入れたCloverとkextで、最低限の起動は行えるようになっているはずです。さらに、グラフィックスカード、Ethernet, サウンドの設定をします。以下の記事が参考になるかと思います。

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

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のサポートページでも紹介されています。

(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が必要です。

そのほかのkext

必須ではありませんが、LAN用のkext, オーディオ用のkext, USB設定のためのkextがあっても良いです。後から用意しても良いですが、LAN用は早い段階で欲しいかもしれません。

(5) 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についてはこちらで解説しておきました。

[XML] Clover config.plist – Pastebin.com

デフォルトのconfig.plistはこんな感じになっています。

結構ややこしくて長ったらしいです。多くはコメントアウトされた記述です。XMLのコメントアウトは書きにくいのか、ここではkeyの名前に#をつけています。#をつけて、ありえない名前にすることで、無視されるようにしているようです。例えば、DisableDriversと書くべき以下の部分を、

DisableDrivers
CsmVideoDxe
VBoxExt4

#DisableDriversと以下のように書くことで、

#DisableDrivers
CsmVideoDxe
VBoxExt4

この部分をコメントアウトするのと同等の記述をしています。後からこの記述が必要になった時は、#を外せば良いのです。ただ、このようにコメントアウトされている箇所は、必要性の低い場所です。なのでほとんど削除することができます。

また、他にも必要性の低い場所があります。昔のマザーボードやハードウェアで必要とされていたものの、現在のマザーボードなどではほとんど不要であったり、むしろ不具合を引き起こしたりする記述が多くあります。それらを削除すると簡単になります。

(9) SMBIOSを設定する

デフォルトのconfig.plistでの機種設定は暫定的な設定です。実際には、インストール先のマシンに合わせて、しっかりと設定する必要があります。こちらに詳しい内容を説明しておきました。

[XML] Customized config.plist – Pastebin.com

こうして、コメントアウトされた部分を消して、不要な設定を消して、SMBIOSを設定した例を以下に示します。

(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が完成です。

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への接続でもエラーが出ます。

以下の記事でも紹介していますが、

以下のファイルを消して再起動すれば良いです。

/Library/Preferences/SystemConfiguration/NetworkInterfaces.plist
/Library/Preferences/SystemConfiguration/Preferences.plist

また、en0があってもこれの状態がBuiltinになっていないと接続できないことがあるようです。コメントで教えていただきました。こちらに説明があります。これの対処法も、上記のファイルを消して再起動すれば良いようです。

シリアル番号類を正しいフォーマットで設定する

先のiMessage騒動の時に、iMessageに認められる正しいシリアル番号のフォーマットが、コミュニティの協力で調べられました。その結果が、Clover Configuratorの自動生成機能に組み込まれています。なので、これを利用して、正しい情報を設定しておけば良いです。以下の記事で紹介しておきました。

注意すべき点は、一回設定したら、継続して使い続けることです。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は従来よりセキュアなので、その結果ロックアウトされにくいように思います。何れにしても、サーバ側でどのように運営しているかは謎ですし、そのポリシーも変化していると思われます。

音を出す

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出力をサポートしています。

Check Your Service and Support Coverage - Apple Support

ここに書いてあるどのlayoutを使うかをconfig.plistに記載する必要があります。 Realtekの場合、だいたいは1で良いようです。以下に例を示します。

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

正しく機種設定する (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する事に支障が出るのではないかと、コミュニティの人たちは心配しています。そこで、実在するシリアル番号と重複しない番号を使うことが強く推奨されています。

実存の番号と重複しているかどうかの確認方法は、簡単です。生成したシリアル番号をコピーして、以下のページにペーストします。

この結果、「申し訳ありませんが、このシリアル番号は有効ではありません。ご確認の上、もう一度やり直してください。」と表示されれば問題ありません。もし、保証状況やサービス期間の案内が出るようなら、このシリアル番号は実機で使われている番号です。その場合は、別のシリアル番号を生成し直します。実際に生成してみるとわかるのですが、実存するシリアル番号に当たることはほとんどありません。

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

を指定しなくても、機種モデルの最新の値がデフォルトで設定されるようになったという情報もあります。実際にBiosVersionを削除して見たところ、それでも最新の値が使われていました。Step 2の作業の代わりに、これらの指定を単に削除して、Cloverのデフォルトに任せるのも可能かと思われます。

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

を指定しておくだけで良いらしいです。

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

Sun, 17 Sep 2017 12:18:24 +0900

5.25インチベイに取り付ける取り外し可能なHDDケース

今のMacintosh製品には5.25インチベイが無いです。最近の自作PCケースも、5.25インチベイの無い製品が増えていますが、あれば色々便利です。中でも、簡単に5.25/2.5インチドライブを取り付け・取り外しできるリムーバブルディスクケースは便利だと思います。自作していれば、小容量の古いHDD/SSDが余ってしまいがちです。それが簡単に取り付けられるリムーバブルケースがあれば、大容量のデータを高速にコピーして持ち運ぶとか、新しいバージョンのOSを実験的にインストールするとか、いろいろな場面で便利に使えます。

市販の製品

5.25インチベイ自体が廃れ始めているので、製品もひところに比べたら少ないですが、いくつかあるようです。5.25インチと2.5インチの両方が入る製品が多いようです。隙間にUSBコネクタを装備している製品とか、光学ドライブも入れられる製品もあります。ちなみに、大は小を兼ねるので、5.25インチが一台だけしか入らないケースも、工夫すれば2.5インチもなんとかなります。

HDD/SSDのSATAコネクタは、なんども抜き差しする前提で設計されていないので、壊れやすいと言われています。ちゃんとしたサーバで使うホットプラグケースでは、強度の高いコネクタ付きトレイを用意してHDDをネジ止めする構造になっています。でも、素人がちょっとした実験で抜き差しするくらいなら、全然問題ありません。ねじ止めしなくても取り付けられるケースが楽です。

またこれらの製品は、ホットプラグ対応を謳っています。電源を入れたまま、HDD/SSDを抜き差しできるという意味です。ただし、これは電気的に問題を起こさないという意味であって、マウントしたままいきなり取り外すと当然ですがデータが損傷する可能性があります。非マウント状態にしてから抜き差しする必要があります。

ホットプラグなドライブアイコン

ドライブはmacOSでいろいろなアイコンで表示されます。一般的なHDD/SSDは銀色のアイコンです。ちょっと古い感じのハードディスクの形です。USBメモリーは白いアイコンで表示されます。スリットがあるので、光学ドライブの絵なのかもしれません。また、取り外し可能なHDDなどはオレンジ色のアイコンで表示されます。取り外し可能なドライブアイコンの隣には、イジェクトアイコンが表示されていて、これを押すとアンマウントされます。

上で紹介したリムーバブルケースは、取り外し可能なディスクなので、イジェクトマークのあるアイコンになるべきです。でも、USB接続と違い、リムーバブルケースからマザーボードへは内蔵ドライブと同じSATAケーブルで接続します。マザーボードから見たら、SATAコネクタが内部のHDDに接続されているか、もしくはリムーバブルHDDケースに接続されているのかの区別はつきません。人手で指定する必要があります。

いくつかのマザーボードではデフォルト設定として、インテルのチップセットに接続されたドライブを内部ドライブ（銀色アイコン）にしています。一方で、チップセットのSATAに加えて追加SATAチップを搭載して、SATAの数を増やしている場合、追加のSATAチップに接続されたドライブはリムーバブルボリュームに設定されていることが一般的です。でも全てをホットプラグ対象とみなすマザーボードも中にはあります。こうした割り当てで、内蔵ドライブがオレンジ色のアイコンになってしまうことがあります。それが嫌な人のために、 AHCI_3rdParty_eSATA.kextや AHCI_Intel_Generic_SATA.kextといったkextが用意されていました。これらのkextの主な目的は、オレンジ色のアイコンを銀色に戻すことです。ただ、これらのkextは最近のmacOSでは機能しないことが多いので、あまり使われなくなりました。

BIOSでホットプラグを設定

マザーボード搭載のSATAに接続したドライブがリムーバブル（ホットプラグ）なのかどうかは、BIOS設定で指定します。下はMSIのマザーボードの例です。

この機能で、それぞれのSATAコネクタに接続されているドライブが、固定ドライブなのか、ホットプラグさせるドライブなのかを設定します。これが一番理想的ですね。この方式ならば、オレンジアイコンの割り当てを正しく行うことができます。ただし、後述するように、BIOSでホットプラグに設定しても、macOSで必ずしもオレンジアイコン表示にはならない場合もあるようです。

なお銀色アイコンで、イジェクトマークがついていないドライブでも、ゴミ箱方向へドラッグ&ドロップすればアンマウントできます。また、ディスクユーティリティを使ってもアンマウントできます。ターミナルから、diskutil unmount /dev/disk… としてもアンマウントできます。

ただ、銀色アイコンとして認識されているSATAドライブは、起動時に接続されていなければ認識されません。macOS起動後に接続しても認識されません。また、起動時に接続されてマウントされても、その後で一旦アンマウントしたら、もう一度接続しても認識されません。なので、リムーバブルケースで接続する場合は、オレンジ色のアイコンで認識されないととても不便です。

macOSでホットプラグ

BIOSレベルでホットプラグに設定しても、macOSでオレンジアイコンにならない場合があります。銀色アイコンの状態では、起動時にはマウントしますが、ホットプラグによりマウントしてくれない状態になります。SATAチップの種類、マザーボード、macOSのバージョンなどで対応が異なるようです。

Z97マザーボード＋Sierra以前

この記事を最初に書いた時点では、MSIのZ97チップセットマザーボードでSierraで動かしていました。BIOSのホットプラグ設定をすると、macOSでもオレンジアイコンになりホットプラグでマウントされ、安定に動作していました。

Z97マザーボード＋High Sierra以降

不安定です。High Sierraになった時点で、BIOSで設定しても銀色アイコンのままのこともあり、動くこともあるようです。ASUS ROG MAXIMUS XI HERO (Z390)マザーボード＋Catalinaの組み合わせでは、BIOS設定のホットプラグが正しくオレンジアイコンに表示されることも何度かありました。その時は、スリープしても問題ありません。でも何度も起動して確認すると、マウントされないこともあります。

PCIe拡張SATAカード + Catalina

以前、macOSと互換性のあるPCIe拡張SATAカードをご紹介しました。

PCIe拡張カードでSATAを増設する

追記：以下の方法では、マウントする際にBig Surが落ちることがありました。後述する長いパターンのパッチを当ててください。ASMediaやMarvellのチップでもホットプラグ可能です。

~~これらのカードの場合、こちらで紹介されているように、~~

Find --> 40600200
Replace --> 00000000
AppleAHCIPort

というパッチを当てれば、ASMediaやMarvellのチップでホットスワップできるようです。元のサイトの説明では、SATAポートデュプリケータの不具合に対応するパッチらしいですが、ホットプラグ問題も解決するようです。具体的には、config.plistに

<key>KextsToPatch</key>
 <array>
 <dict>
 <key>Comment</key>
 <string>ALPM IO Error AppleAHCIPort</string>
 <key>Disabled</key>
 <false/>
 <key>Find</key>
 <data>QGACAA==</data>
 <key>InfoPlistPatch</key>
 <false/>
 <key>Name</key>
 <string>AppleAHCIPort</string>
 <key>Replace</key>
 <data>AAAAAA==</data>
 </dict>
 </array>

を追加します。QGACAA==が40600200で、AAAAAA==は00000000です。これでホットスワップが動くようになり、スリープしても大丈夫でした。Marvell 88SE9230チップセットによるカードと、ASMedia ASM1061チップセットカードの両方で動作を確認しました。

Z390 + Catalinaのパッチ

コメントでまっくぷろさんからいただいた情報によると、こちらで紹介されているパッチもしくはその変形を使うと、Z390チップセットのSATAをホットプラグ対応にできるようです。

Find --> 89C82540 6002003D 40200000 750C81E1 BF7FFFFF 898B5101 0000
Replace --> 90909090 90909090 90909090 90909090 90909090 90909090 9090
AppleAHCIPort

または、

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

のようです。これに対するBase64文字列を、上で紹介したように、config.plistのKextsToPatchセクションに書き込んでおけば良いようです。

このパッチのいずれでも動かないようでしたら（もしくは将来のmacOSバージョンで動かなくなったら）、AppleAHCIPort.kext/Contents/MacOS/AppleAHCIPortをバイナリーサーチして40200000を検索して、その前後から上記のようなパッチを作れば良いようです。例えば以下のようにします。10.15.3での実施例です。まずはバイナリーをhexdumpしました。

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

lessの中で、サーチコマンド

/40 20 00 00

をタイプし、40 20 00 00を探します。

00029a0 73 0e 81 ca 40 80 00 00 89 d1 89 93 69 01 00 00
00029b0 89 ca 81 e2 40 60 02 00 81 fa 40 20 00 00 75 0c
00029c0 81 e1 bf 7f ff ff 89 8b 69 01 00 00 f6 c1 40 74
00029d0 7e 3d 09 01 01 00 72 77 44 89 fa c1 ea 0a 81 e2

この方法では、運悪く改行にかかっているとデータ列が見つからない可能性はありますが、首尾よく発見できました。他には存在していないようです。ということで、まっくぷろさんの情報と同じく、40 20 00 00を挟んだデータ列をNOP (90) に置き換える

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

というパッチで良いようです。base 64に変換します。詳しくはこちらをご覧ください。

echo -n "\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=

ちなみにNOPコマンド列である9090…の方は、

echo -n "\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=

です。なので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のconfig.plistで当てる方法を以下で紹介しました。

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

また、Big Sur対応のパッチを以下で紹介しました。

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

結論

ホットプラグできるリムーバブルベイは便利です。チップセットSATAの場合は、BIOSでホットプラグを設定します。それでもmacOSにホットプラグ対応と認識されない場合は、AppleAHCIPort.kextにconfig.plistでパッチを当てます。手元の環境 (ASUS Z390 + Catalina) では、MarvellのSATA拡張カードを使っているので、拡張カード用のパッチを当てることにしました。

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

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がインストールされています。

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は、以下の記事を参照してください。