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

OpenCoreはCloverから分岐し、OZMOSISの流れを取り込んだ新しいオープンソースのブートローダーです。Z390マザーボードで動かしたところとりあえずはmacOSが起動しました。

OpenCoreとは

OpenCoreは、完璧にオープンソースであることが特徴の新しいブートローダーです。Cloverから分岐し、OZMOSISの流れを取り込んでいます。OZMOSISを開発していたドイツのHackintosh-Forum.deの人たちが開発を進めているようです。OZMOSISってどんなものだったかと言うと、ファームウェア形式のブートローダーで、マザーボードのBIOSを置き換えて動作します。OZMOSISをマザーボードのBIOS更新機能を使ってインストールすれば、普通のマザーボードがmacOSを直接起動できるマザーボードに変身します。macOSもmacOSインストーラも実機と同様にそのまま起動できるという理想を追ったブートローダーだったのですが、調整やアップデートのたびにBIOS更新作業をするのは大変でした。ChameleonやCloverみたいにドライブの一部に書き込む方式の方が色々楽です。ということでOZMOSISはあまり流行りませんでした。開発チームもそれを認識して、今度はClover方式のブートローダーを作ることにしたのだと思われます。

使用したハードウェア

OpenCoreを試したハードウェアは、以下で紹介したZ390マシンです。モデルIDはiMac19,1で、macOS Mojave 10.14.5です。

ここで使っているkextは

  • AppleALC.kext
  • IntelMausiEthernet.kext
  • Lilu.kext
  • USBInjectAll.kext
  • VirtualSMC.kext
  • WhateverGreen.kext

です。efiファイルは大半がClover 5018で配布されているものです。

  • ApfsDriverLoader.efi
  • AptioMemoryFix.efi (これはKext Updater.appで入手)
  • FSInject.efi
  • VirtualSmc.efi (VirtualSMC.kextに同梱されているもの)
  • VBoxHfs.efi
  • EmuVariableUefi.efi

またUSBInjectAll.kextで使うためのSSDTファイルも使っています。こちらで作成したものです。これがSSDT-UIAC.amlという名前です。

OpenCoreを入手する方法

いろいろな方法がありますが、一番お手軽なのは最近のKext Updater.appを使う方法です。Kext UpdaterもOpenCoreを作っている人たちが活躍しているHackintosh-Forum.deで作られていますので、その関係でOpenCoreダウンロード機能が実装されているのだと思います。Load Bootloaderのラジオボタンを選択して、右のポップアップメニューからOpenCoreを選択します。

ダウンロードすると、Kext-Updatesフォルダの中にOpenCoreというフォルダができて、この中にデバッグ版とリリース版

  • OpenCore-0.0.4-DEBUG
  • OpenCore-0.0.4-RELEASE

のフォルダが出来ています。今回はRELEASE版を使ってみましたが、DEBUG版の方がより多くのエラーメッセージを出してくれるらしいです。

ESPディレクトリ構築

Docsフォルダの中には、とても詳しい取扱説明書が入っています。Cloverにはあまりなくて、ネット上のマニュアルも古かったりします。説明書を一緒に配布してくれているのは助かります。まだちゃんと読んでませんが、必要な情報は全部書いてあるのではないかと思います。マニュアルによると、構築すべきディレクトリ構造は以下の通りのようです。

グレーの項目は任意の項目です。なので、EFIの下に、BOOTとOCを作って、OCの中のDriversにefiファイルを、Kextsにkextファイルを入れれば良いようです。またOCの中にconfig.plistを起きます。名前がOCになっただけで、CloverのESP配置とだいたい同じです。この図に従ってESPの中にディレクトリを用意し、DriversフォルダとKextsフォルダに上記のefiファイルとkextファイルを入れました。またACPIフォルダにSSDT-UIAC.amlを入れました。

config.plist編集

Docsフォルダの中に、マニュアルと一緒にconfig.plistのサンプルファイルも入っています。名前が、Sample.plistとなっています。今回はこのファイルをもとに動かしてみました。まずはSample.plistをconfig.plistに名称変更します。そして以下の手順で書き変えました。

SMBIOS設定

まずは機種設定からです。どうやら<key>PlatformInfo</key>の中の<key>Generic</key>の中が機種設定関連のようです。この部分のMLBがCloverでのBoardSerialNumberに対応し、SystemProductNameがProductNameに、SystemUUIDがSmUUIDに対応するようです。それぞれの値を書いておきます。

	<key>MLB</key>
	<string>C02921130GULNV9JA</string>
	
	<key>SystemProductName</key>
	<string>iMac19,1</string>

	<key>SystemSerialNumber</key>
	<string>C02YR2YHJV3Q</string>

	<key>SystemUUID</key>
	<string>E45005B4-95C7-4B0C-9739-30947DDEB37C</string>

FileVault設定

この状態で起動させようとしたところ、FileVaultの用意ができていないというような内容のメッセージが出て起動が中断しました。config.plistを見ると、<key>Misc</key><key>Security</key>の中にFileVaultらしい設定があり、有効にされているようです。ここのtrueの部分2箇所をfalseに書き換えました。これでメッセージが出なくなりました。

<key>Security</key>
	<dict>
		<key>ExposeSensitiveData</key>
		<integer>2</integer>
		<key>HaltLevel</key>
		<integer>2147483648</integer>
		<key>RequireSignature</key>
		<false/>
		<key>RequireVault</key>
		<false/>
		<key>ScanPolicy</key>
		<integer>983299</integer>
	</dict>

efi設定

次に、HFSPlus.efiが見つからないというメッセージで起動が中断されました。最近はAPFSになって、HFS+での起動は使わないので、上記のリストのようにCloverデフォルトのVBoxHfs.efiを使っていました。なんでこのメッセージが出るのかと思ったらconfig.plistの<key>UEFI</key><key>Drivers</key>の中にefiファイルの一覧が書いてありました。フォルダに入れるだけでなくconfig.plistにも書いておくようです。FileVaultに関係したefiファイルも入っています。これらのリストを、実際に使っているefiファイルに書き換えました。

<key>UEFI</key>
<dict>

	<key>Drivers</key>
	<array>
		<string>VBoxHfs.efi</string>
		<string>ApfsDriverLoader.efi</string>
		<string>EmuVariableUefi.efi</string>
		<string>FSInject.efi</string>
		<string>AptioMemoryFix.efi</string>
		<string>VirtualSmc.efi</string>
	</array>

kext設定

ほかも見てみると、<key>Kernel</key><key>Add</key>の場所に、kextに関する記載もあります。この記述順にロードされるようなので順番も大事なようです。

IntelMausiEthernet.kextの名前が違っている(IntelMausi.kextになっている)のとEnabledされていないようなので、修正しました。

<dict>
	<key>BundlePath</key>
	<string>IntelMausiEthernet.kext</string>
	<key>Comment</key>
	<string></string>
	<key>Enabled</key>
	<true/>
	<key>ExecutablePath</key>
	<string>Contents/MacOS/IntelMausiEthernet</string>
	<key>MatchKernel</key>
	<string></string>
	<key>PlistPath</key>
	<string>Contents/Info.plist</string>
</dict>

また、USBInjectAll.kextの記述も追加しました。順番が大事のようです。arrayの最初の方に入れたら動きません。arrayの最後に追加しました。

      <dict>
        <key>BundlePath</key>
        <string>USBInjectAll.kext</string>
        <key>Comment</key>
        <string></string>
        <key>Enabled</key>
        <true/>
        <key>ExecutablePath</key>
        <string>Contents/MacOS/USBInjectAll</string>
        <key>MatchKernel</key>
        <string></string>
        <key>PlistPath</key>
        <string>Contents/Info.plist</string>
      </dict>

SSDT設定

使用するSSDTもconfig.plistで指定する必要があるようです。今回は、SSDT-UIAC.amlを使います。そこで、<key>ACPI</key><key>Add</key>のarrayの中に、

      <dict>
        <key>Comment</key>
        <string>USB list for USBInjectAll</string>
        <key>Enabled</key>
        <true/>
        <key>Path</key>
        <string>SSDT-UIAC.aml</string>
      </dict>

を追加しました。

動作確認

BIOSでOpenCoreをインストールしたドライブを選択すると、Cloverと同様に起動ボリュームの選択画面が出ます。テキストだけのシンプルな画面です。ここで10.14.5の入ったMacintosh HDを選択しました(この例ではキーボードの5を押す)。この後、設定に不備があると上記のようなエラーメッセージが出ることもありますし、起動が停止することもあります。

でも、ここまでの設定で、なんと起動しました。config.plistで手付かずの項目がいっぱいあるのに、とりあえず起動したのは意外でした。よかったです。

使用したconfig.plistを以下においておきます。

動くこと

画面が出て動作します。Radeon RX 580が正しくと動きます。IntelMausiEthernet.kextも動きます。なのでLAN接続ができます。またBroadcomの純正WiFiも動きます。

USBInjectAll.kextと自作のSSDTの組み合わせで、USBの取捨選択ができています。15個制限問題を解決できています。

動かないこと

シャットダウンすると画面は消え、シャットダウンプロセスが実行されるのですが、電源が切れるところまで行き着きません。電源スイッチを長押しして強制的にoffにする必要があります。その影響で次の起動の時にBIOS表示で警告が出ます。ACPI関係の設定が足りないのだと思います。

OpenCoreに行くべきか?

ということで、OpenCoreでの起動を確認できました。今後は、USBの指定方法や、今回見た以外のconfig.plistの設定など、マニュアルや検索して調べて見たいと思います。

ではCloverをやめてOpenCoreに移行すべきでしょうか。OpenCoreの人たちは、以下のようなメリットを訴えています。

  • 完全にオープンソースなので安心
  • 設計が新しい

確かにCloverは開発過程がそれほどオープンになっていないので、わかりにくいところがあるかと思います。ロシアで開発されているCloverとドイツで開発されているOpenCoreでは、偏見かもしれませんが、なんとなくOpenCoreに安心感を感じます。開発がオープンなのでHackintoshの主流がOpenCoreに移行していく可能性は高いです。でも今現在では、Cloverに関するノウハウが大量にネットにありますし、しばらくはCloverが使われると思います。

主流ブートローダーは、数年前にChameleonからCloverに交代しました。ただ、この交代では、レガシーなMBR (マスターブートレコード)からESPに対応すること、起動時に動的にパッチを当ててくれる機能、macOSとの相性が良くなることなど、いくつもメリットがありました。CloverからOpenCoreに変えても、目に見えるメリットはないので、移行は緩やかかもしれません。CloverからOpenCoreに移行したらグラフィックスカードの動作が安定したと言う情報も見かけました。今後どうなるにしても、選択肢が複数あることは良いことです。

29件のコメント

  1. お疲れ様です。
    記事をもとに、少しいじってみました、(ASUS Prime H310-A)
    efiは
    ApfsDriverLoader.efi
    EmuVariableUefi.efi
    FSInject.efi
    OsxAptioFix3Drv.efi
    SMCHelper.efi
    VBoxHfs.efi
    kestは
    AppleALC.kext
    FakeSMC.kext
    Lilu.kext
    RealtekRTL8111.kext
    USBInjectAll.kext
    WhateverGreen.kext
    です。
    USBInjectAll.kextは
    <dict>
    <key>BundlePath</key>
    <string>USBInjectAll.kext</string>
    <key>Comment</key>
    <string></string>
    <key>Enabled</key>
    <true/>
    <key>ExecutablePath</key>
    <string>Contents/MacOS/USBInjectAll</string>
    <key>MatchKernel</key>
    <string></string>
    <key>PlistPath</key>
    <string>Contents/Info.plist</string>
    </dict>

    で動きました。15個の制限のブートオプションを
    <dict>
    <key>boot-args</key>
    <string>-v keepsyms=1 alcid=7 uia_exclude=HS01;HS02;HS05;HS06;HS11;HS12;HS13;HS14;SS01;SS02;SS05;SS06</string>
    <key>csr-active-config</key>
    <data>AAAAAA==</data>
    <key>nvda_drv</key>
    <data>MQ==</data>
    <key>prev-lang:kbd</key>
    <data>cnUtUlU6MjUy</data>
    </dict>

    の通り入れて、動きました。
     シャットダウン関係は無理でした。
    Ver0.0.4、これから、ノウハウがたまっていくんでしょうね。
     

  2. [OpenCoreは、完璧にオープンソースであることが特徴の新しいブートローダー] なので、新しい時代の夜明けなのかも。Chameleon -> Clover の移行の際の変化も経験したユーザーとして、さらに Clover-> OpenCoreへの変革にも、参加できるとは本当にラッキーです。

    ダメ元で、ちょっと サンプル Config.plisの汎用度を試してみました。

    1) Clover Configurator
    やはり内部構造が異なっていることから、まったくの互換性なし。
     でも、text modeでは読み取れますが、ベタ文字列の羅列で編集が大変です(初心者には酷)
     長期的にはOpenCore専用のConfiguratorの早期提供が、今後のユーザー拡大に大きく貢献するかも。

    2) Xcode
    かつて、Clover が世の中に普及(認知)し始めた時に、専用のconfigurator がまだ用意されていない時期だったので、同じように このXcodeで読み込んで編集した思い出があります。
    歴史は繰り返す….ですが、 新しい時代の変革は新しいツール(OpenCore)で切り開かれる…と感じます。
     Key – Type – Valueと 整然と表示されて、読み落とし、記入漏れの誤りは少なくなるでしょう。

    ーーーーーーー
    追記: < Cloverと同様に起動ボリュームの選択画面が出ます。テキストだけのシンプルな画面 >
     Cloverのような GUIのテクニックを駆使した画面と比較して、な、なんと シンプルな.. 画面!!
     モノは考えようで、試読性(ぱっと見てすぐわかる)の点では GOOD !!

     OpebnCoreを使うこと:現時点でのメリット
    1) 既に使い慣れている kext Updater ツールで、一括管理できそう
    2) オープンソース主体ゆえに、万人の智恵・工夫が迅速に反映され、さらにコード自体が万人にDEBUGされており、大勢でかついた神輿のように 今後 勢力を増すのでは。
    愛用している Braveブラウザーのように、 いずれカミソリのような切れ味(高速処理)が OpenCoreのソースコードの中に取り込まれて、それを我らユーザーが享受できることを期待

    1. 後記:
       先人 お二人の冒険心に導かれ、私も この新世界に一歩 踏み込んでみました。

      1) 初見:
       EFIフォルダー内の階層構造が3段、 一方Cloverでは4段。
       やはり、階層構造が浅い分だけ、シンプル差がBetter

      2) まだバージョン・リリースが 1.0.0にも達していないPreview版ゆえ、 良い子の皆さまには利用を強くお奨められません。 

      約三時間の奮闘(頭のパズル)で得られた事を以下にQuickにご紹介。

      – Clover Configurator に相当するツールがまだないので、 ほぼ手作業…しんどい
       生産効率は超最悪、でも動き出したらフットワークが軽くてやみつきになりそう。

      – FakeSMC およびVirtualSMCの両方のタイプで検証したが、 センサー用の xxxx.kextが見つからない(正しく登録していても)とのERRORが出る。 
      センサー用にxxxxx.kextの登録手順は別の方式なのかも??

      – kext群の一つとして、NullCPUPowerManagementCPUPowerManagement.kextを放り込んでいるせいなのか、我がHainctosh(OpenCore)は正常にShutdownしてくれました。

       ここらで、ちょっと一休み….

  3. ———————–
    追記2:
    3) 今回は、怖いもの見たさで Release版ではなく、あえて ERROR表示のメリハリがきいているであろうDebug版の OpenCoreコードを使用

    4) Mojaveレベルでは、 VirtualSMC系 および FakeSMC系のいずれを採用しても(センサー周りのkextの取扱いがまだ不勉強)、同じようにサクサク動く。
    しかしながら、こと Catalina Public Beta版に限って言うと、FakeSMC系の方が最後まで 起動プログレスバーが進み、どうにかログイン画面までたどり着けた。

    5) mifjpn さんが 紹介なさっているいくつかのパッチ作業は、実際にConfig.plist上で書き込む適切な場所を探したが、力不足で見つからず現時点では、適用を保留中。

  4. ———————–
    追記3:

    6) Kext Updaterツールが、Clover環境の場合と同様に以下の作業ができるかどうか試してみた、 
      Kext群のそれぞれが最新版かどうかの検証
      EFI区画のマウント/ アンマウント

     すると、Kext Updaterアプリからは、以下のメッセージを表示してきた。
     The value for ‘Expose Sensitive Data’ (Misc/Security) in your OpenCore config.plist must be set to ‘3’. Without this value, the Kext Updater works only to a limited extent.

     そこで、指示内容に従って、該当する値を2から3に変更し、次にEFI区画からの再起動、再度 作業をTRY. これで、ようやく 念願ことができるようになり、めでたしめでたし。

    注: 副次効果として、 EFI区画マウント/アンマウント作業のために残していたClover COnfiguratorを、ラウンチDOCから切り離すことができた。 さらに、アプリケーションフォルダーからも抹殺。 

  5. お疲れ様です。
     NullCPUPowerManagement.kext
    一応試してみましたが、Shutdownは無理でした。
     Cloverでは、EmuVariableUefi.efiが効いたのですが、何らかの機微のあるオプションと共に効いてるのか、不明点も多いですね。(ただ、解決方も、やや伝承的になるのは、世のMB,CPU,VGAの組み合わせが非常に多くあるからでしょうねぇ)また、そのように、世のMB,CPU,VGAの組み合わせが非常に多くあるために、CloverスイートClover configrator(unibeast multibeastなども)があるということが、万人が解決法を探ることができるという正の相関を生み出しているのでしょうね。
     初心者ながら私が思うに、OPENCOREのシェアが上がるのは、あまりあまたあるハードウェアの組み合わせに、いかに対応するかという点にあるような気がします。(ありえないとは思いますが、オープンソースだから万人がビルドできるので、自分のMB,CPU,VGA用にビルドしてください。ビルド用のmakeオプションはこちらです。ではCloverを超えられないでしょう。)
     まず本体がVer1.0.0を迎えることもありますが、セットスイートとともに、ほぼ万人に解を探すことのできる環境が必要なのかもしれませんね。

  6. mifjpnさん、
      迅速なレスに感謝いたします。
     「手間のかかる子ほど可愛い」ではないですが、このOpenCoreに一度触れると次から次へと やってみたいことが出てきて、雑学的なコメント投稿をつづけてしまい、折角のブログ掲示板を汚してしまったかも..と思ったりもしています。

    o 「NullCPUPowerManagement.kext。一応試してみましたが、Shutdownは無理でした。」
     そうでしたか 残念。 上述のコメント投稿で書き漏らした(まだ網羅していない)ことがひとつ。
     xxxx.efi および xxxx.kextの箇所は、 bootmacosさんの提示内容に沿って行いましたが、さらに自分の直感で、わがHacintosh環境において大切であろうと考え、Clover環境 EFI-Clover-ACPU-Patchedで保管していたファイル群を このOPenCore の EFI-OC-ACPIフォルダーにコピペしていました。

    o すみません、OpenCore Config.plistへのPatch適用の方法にまだ不慣れなので、お手数ですが以下のPatch適用をどの場所にどのように記載(指定)なさったのか その手順を「種明かし」していただけないでしょうか?  
     OpenCoreに興味を持ち始めたコミュニティーの皆さんも、きっと知りたがるかとおもいます。
    ーーー引用箇所 ーーーー
    15個の制限のブートオプションを

    boot-args
    -v keepsyms=1 alcid=7 uia_exclude=HS01;HS02;HS05;HS06;HS11;HS12;HS13;HS14;SS01;SS02;SS05;SS06
    csr-active-config
    AAAAAA==
    nvda_drv
    MQ==
    prev-lang:kbd
    cnUtUlU6MjUy

    の通り入れて、動きました。
    ーーーーーーーーーーーーーーーーーー終わり

  7. 追記 4:
    すでに熟成されたツール:CloverLoader他 に慣れており、まだまだ荒削りで手間のかかるツール:OpenCore に興味がわかない方は、当コメント内容をスルーしてください(折角の時間がもったいないので)。

    —–新ブートローダー OpenCoreを使うと、こんなことってあるの?
    a) 昨夜 夕方 OpenCore ブートローダーの入ったEFI区画をBIOS省略時起動ボリュームにしたまま、電源オフ。
     すでに多くの方がご存知かと思いますが、昨夜から明け方の間に,macOSx Mojaveの最終リリース(10.14.6 Final)が提供開始されました。
     そのニュースを見て、現有Mojave 10.14.6 public beta xの起動ボリュームの上書きアップグレードと、
     他の起動ボリューム(Mojave 10.14.5 Final)のクリーン導入作業を思い立った。

    b)OpenCore ブートローダーの入ったEFI区画起動による[起動ボリュームへのOSx10.14.6 上書き導入]のてんまつ;
     作業結果:問題なく、日本語表示で導入作業を完了
     良かった点: OpenCorteブートローダーのもとで、上書き導入すると 途中2回再起動があったが、キーボードに一切手を触れることなく、自動で作業が進んだ。
    (あたかも、純正macでの上書き導入をおこなっているがごとく)
      注:Cloverブートローダー使用時のような、さてさえどれかいな?と探して手動選択する手間・時間はまったく不要。

    c) OpenCore ブートローダーの入ったEFI区画起動による[OSx10.14.6 新規導入]のてんまつ;
     導入作業の結果: 中断
     背景・理由は、第一優先順位の起動ボリュームではにために、 該当する数字でその対象起動ボリュームを選んだ、それを2回も繰り返し。 問題は一応 Install作業が終えて、ターゲットのボリュームからの起動が行われて、ユーザー環境初期設定の時に、問題発生。
     な、なんと!! 表示されたのは、ロシア語(日本 ->  Япония (読み方 Yaponiya)。
    これでは、表示されている文章・意味が理解できず、 ギブアップ!!!!
     
     救済策: BIOS起動ボリュームとして、やむなく CLoverboot Loaderが入っているEFI区画に選び変えて再起動、使い慣れているClover Boot Loaderを利用して、最終的には日本語表示で無事完了。
     <教訓> OpenCoreはまだまだ発展途上なかば、CloberBootLoader環境はゴミ箱に捨てるなかれ!!

    d) OpenCorerブートローダーの方が、Clover ブートローダーよりもフットワークが軽いって本当?
     おそらく、OpenCorerブートローダーが知名度・熟成度合いが低いので、両ブートローダーを比較した資料は出ていないかも。 実際に、わがHacintosh環境(自作PC,i7-6700K, Z170M-OC-Fomula.マザボ)で動かした後で、判明したことは ひとつ。
     どういうわけか、わがHacintosh環境では ハーパースレッデング(HTT)を Enabled(ON)にすると、駄々をこねる困った子ちゃんです( これまではClover BootLoader 主体)
     ところが、ブートローダーをOpenCoreに切り替えると、あらふしぎ HTT Enableにしても、お利口さんのままで、上機嫌のまま。
     -> OpenCoreの内部コードは、きっと洗練されて(プチ断捨離も行われて?)、フットワークがより軽やかになり、省電力に貢献しているのだと確信。

    ここで、一休み。 
    (不定期な投稿、 つづく)

  8. 訂正:
    第一優先順位の起動ボリュームではにために、 -> 第一優先順位の起動ボリュームではないため、

  9. 追記5:
     上述の後記:で以下のように述べた件に関して、重要な解決ヒントが見つかったのでご紹介します。
    ————————-
    – FakeSMC およびVirtualSMCの両方のタイプで検証したが、 センサー用の xxxx.kextが見つからない(正しく登録していても)とのERRORが出る。 
    センサー用にxxxxx.kextの登録手順は別の方式なのかも??
    ————————-

    *解決ヒントを見つけられたかも・・・ ー
     参照Webページ: 
     Getting-Started-With-OpenCore
     A brief guide to using the OpenCore bootloader for hackintoshes  
    https://insanelymacdiscord.github.io/Getting-Started-With-OpenCore/

    *とても重要な情報(解決ヒント)は以下の4行です。 
    >Kernel
    >Add: Here we can specify kexts to inject from our EFI into the kernel kextcache. Order of kexts is >important, they are loaded in this order. Plugins for other kexts should always come after the main >kext. Lilu should be first, then Lilu plugins like WhateverGreen and VirtualSMC.

    *このヒントから得られた解決策 
     定義する順番は、 まず最初は かならず Lilu,  次にメインのkextのグループ, 後ろの方にLiluや 他の主要なkextためのpluginを並べること

    1) LiluのためのPluginとしてはWhateverGreen やVirtualSMCが該当するので、
    これらは必ず Lilu.kextの定義した後(下部?)に定義する

    2) 例えば、SMCProcessor.kextは VirtualSMC.kextのためのPluginなので、
    Virtual.kextの定義した後(下部?)に定義する

    (つづく)

    1. 情報ありがとうございます。順番が重要なのですね。USBInjectAll.kextを入れる場所を調整して再挑戦してみます。

    2. kext記述の順番が大事という情報ありがとうございました。おかげさまでUSBInjectAll.kextが動きました。ロード順の一番最後に追加しました。またUSBInjectAll.kextが使用するSSDTの指定もしました。これでUSBの15個制限問題を回避できました。助かりました。

  10. お疲れ様です。失礼しました。
    boot-argsの15個の制限とは
    uia_exclude=HS01;HS02;HS05;HS06;HS11;HS12;HS13;HS14;SS01;SS02;SS05;SS06
    のことで、
    https://bootmacos.com/entry/2017/09/30/222518
    ここに書いてあります。
    DSDTよりも簡便なので、ブートオプションでやってみています。
    以上です。

  11. mifjpn さん、
     
     まだOpenCore ブートローダー(Config.plist作成を含む)全体を不慣れなので、お教えください。

     具体的には、OpenCoreパッケージのどの箇所を修正して、自分の希望するブートオプションを指示するのでしょうか?
     お手数をおかけしますが、よろしくお願いいたします。

  12. ごめんなさい、ちょっとわかりづらかったかもしれませんね。
     場所がどこになるのかは、XMLなので、そこを示すシンタックスがあればいいので、前後も含めて、辞書形式~Key=boot-arg部分を抜いたのです。
    <dict>
      <key>boot-args</key>
      <string>-v keepsyms=1 alcid=7 uia_exclude=HS01;HS02;HS05;HS06;HS11;HS12;HS13;HS14;SS01;SS02;SS05;SS06</string>
      <key>csr-active-config</key>
      <data>AAAAAA==</data>
      <key>nvda_drv</key>
      <data>MQ==</data>
      <key>prev-lang:kbd</key>
      <data>cnUtUlU6MjUy</data>
    </dict>

    と書いたのです。
    わたしは簡便にcoteditorで、<key>boot-args</key>を検索し、そこから位置を特定しました。
     ここではHTMLを生で書くので、うまく見えてればいいですが、どうでしょうか?

    1. 追伸
      もちろん、Config.plistですし、ここでダウンロードしたものを、改変して使いました。
      よろしくお願いします。

      1. <わたしは簡便にcoteditorで、boot-argsを検索し、そこから位置を特定しました。

        貴重なヒントをお提示いただき、ありがとうございます。
        腰をすえて、そして真剣にOpenCoreパッケージで提供されているDocs内の取説(Configuration PDF)を頭から尻尾の方まで、”boot-args”をキーワードにしてスキャンして、念願の設定手順の箇所を見つけました。
         それは、 取説の26ページ下 8。5 Other Variables での最初の特定Variablesの所でした。
         見つかって良かった。

    2. お疲れ様です。すみません。
      こちらでは、Boot macOSさんへの追試コメントとして、書き込みました。
      長くなるようでしたら、ディスカッションに行った方がいいかな^^;wとおもいます。
      失礼しました。

      1. ありがとうございます。記事に直接関係する情報ですので、ここで続けていただいた方が散逸しなくて良いと思います。

        1. ありがとうございます。
          Shutdownについては、
          https://www.reddit.com/r/hackintosh/comments/a8uthx/vanilla_mojave_wont_shutdown/
          で、SSDT-GPRW.aml のはなしは、がじってみようかと思いますが・・・
          なにせ、ひとまず、Windows10のブートの選択肢がないんですね。
          デュアルブート(USBのSSD,HDDのEFIもスキャンしてくれないので、実質クワトロブートですが)には、とても厳しいので、実際のところちょっと萎えています。

  13. <>
     最初はとっつきにくそうな感じがしましたが、触れればふれるほどますますその魅力にハマってしまいます。個人的にテストして得られた成果をご紹介(個人的な見解)いたします。

    長文になりましたが、参考になれば幸いです。
    なお、実際に適用する場合は、事前に バックアップを作成し、自己責任にて行ってください。

    1) センサー用の xxxx.kextが見つからない(正しく登録していても)とのERRORが出る… の対処法
     <>
     OCフォルダー内のConfig.plistにて、該当センサーを登録する際にはBundlePath 名は、FakeSMC_CPUSensors.kext であっても、その下行で明示する ExcutablePath 名は「実際にそのパッケージ内で記録されている名称までのリンク情報」でなければなりません。 
    具体的には、Contents/MacOS/CPUSensors としなければ正しく認識・ロードされません。

    2) 「SLIDEでカーネル読み込み番地を調整する」手法を OpenCore ブートローダーのConfig.plist に反映するには..
    <>
    a) Boot-Argument: slide=128
    b) RtVariables: CsrActive  0x40

     実際にConfig.plist 上に反映したXcodeの出力結果(NVRAMーAddだけを抜粋、ASCII Text形式)
    NVRAM = {
    Add = {
    “4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = {
    UIScale = ;
    };
    “7C436110-AB2A-4BBB-A880-FE41995C9F82” = {
    “boot-args” = “-v keepsyms=1 slide=128”;
    “csr-active-config” = 0x40;
    “nvda_drv” = ;
    “prev-lang:kbd” = ;
    };
    };

    3)UEFI – Driversでの記載順序に注意!
    「SLIDEでカーネル読み込み番地を調整する」記事を読解しようと奮闘していた際に、ふと
    ー これらのカーネル番地にはどんなモジュール(xxxx.efi など)がどのような順番で読み込まれるのだろう?
    ー 先日、同じConfig.plist 内のKernel – Add の箇所で、 xxxx.kext を読み込む順番 にはあらかじめ決められたルールがあることを学んだが、もしかして UEFI – Driversでの記載順序(すなわち 読み込み順序)にも、最適化する手法があるのでは??

    <>
    aa ) UEFI – Driversでの記載順序を2種類用意する。 Catalina PB4環境を利用。
     A案 (従来のランダムな記載)と
     B案 (カーネル読み込みにおいてシステムが ”とある優先順位”を持って、動作内容を選別し並行処理している…と推測。それに見合うであろう順番で記載)

    A案: 抜粋、ASCII Properly List 
    UEFI = {
    ConnectDrivers = YES;
    Drivers = (
    “OsxFatBinaryDrv.efi”,
    “ApfsDriverLoader.efi”,
    “FSInject.efi”,
    “EmuVariableUefi.efi”,
    “OsxAptioFix3Drv.efi”,
    “VirtualSmc.efi”,
    );

    B案: 抜粋、ASCII Properly List
    UEFI = {
    ConnectDrivers = YES;
    Drivers = (
    “ApfsDriverLoader.efi”,
    “OsxAptioFix3Drv.efi”,
    “OsxFatBinaryDrv.efi”,
    “EmuVariableUefi.efi”,
    “FSInject.efi”,
    “VirtualSmc.efi”,
    );

    bb ) 実際に、2種類のUEFIー Drivers記載順序で、どのような違いが出るのかを検証。
     あえてシステム負荷を増やして差異が出やすいように、「Hyper Threading : Enabled」環境下で実施。

    結果: A 案の場合は、システム起動中に息切れ(?)状態となり、ログ展開の途中でフリーズ。
       一方、B案の場合は、内部処理の流れに無駄が少ないのか 無事 起動を完了しログイン画面到達。

    注:これらは、あくまでもクイックな確認であり、引き続きB案で動作状況を継続観察いたします。
     

  14.  たまたま、今日 Kext Updater ツールにて、 OpenCore Bootloader パッケージの再ロードをしようとしたら、 従来のレベル 004 から 一段高いレベル 005に変わっているのに、気がつきました。

    1) [ダメ元覚悟で] クイックですが、efi-OC フォルダー内の OpenCore.efiと efi-Boot フォルダー内のBootx64.efi の2つだけを最新版(005) に置き換えて、再起動してみたらすんなり問題なく動きました。

    2) さらに、我がHacintosh環境(Z170M , i7-6700K)で HyperThreading= Enableで試した結果、起動時の安定度合いが「これまで悩まされ続けられていたCatalina(PB4)環境」においても、かなり満足度の高い状況であることを知りました。粘ってここまで来た甲斐がありました。

     参考になれば、幸いです。
    これで、ようやく我がHacintosh環境でもCatalinaに利用携帯の軸足を移す時期が来たようです。

  15. 後記:
    Kekt Updater V3 アプリでの機能強化に同期して、OpenCoreブートローダーによるOSx起動時での立ち上がりが良くなって 起動の途中で 息切れ状態になることが ほぼ皆無になりました。

     我がHacintosh環境(Hyper Threading Enabled )では、 これまでOCフォルダー内のConfig.plistにおいて、Root – NVRAM – add 指定の中で boot-argsにて -vオプションを明示的に選んでいました。
    ———————— -v オプションにてコンソールロギングを表示

    Add

    4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14

    UIScale
    AQ==

    7C436110-AB2A-4BBB-A880-FE41995C9F82

    boot-args
    -v keepsyms=1 slide=128
    csr-active-config
    0x40
    nvda_drv
    MQ==
    prev-lang:kbd
    cnUtUlU6MjUy

    <起動途中での原因探しのためにロギングを取りやめて、 通常のブート形態に変更>0
     同じConfig.plist 内(NVRAMーadd)を以下のように変更しました。
     結果的にブートに要する時間を短縮できて、大変 満足しています。
    —————— -v オプションの指定なし、Debug Modeは.オフ、

    4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14

    UIScale
    AQ==

    7C436110-AB2A-4BBB-A880-FE41995C9F82

    boot-args
    keepsyms=1 slide=128
    bootercfg
    log=0, debug=0
    csr-active-config
    0x40
    nvda_drv
    MQ==
    prev-lang:kbd
    cnUtUlU6MjUy

    ————————

     お役に立てれば、幸いです。

  16. 補足: plistの中身を抜粋して貼り付けたのですが、などの区切りワードが吸収されてしまったので 形式タイプを変えて再書き込みいたしました。

    ASCII Property List 形式にて、NVRAM-ADDの箇所のみ抜粋して提示いたします。

    1)——-#Configの latest コピー, v005, -v debug
    NVRAM = {
    Add = {
    “4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = {
    UIScale = ;
    };
    “7C436110-AB2A-4BBB-A880-FE41995C9F82” = {
    “boot-args” = “-v keepsyms=1 slide=128”;
    “csr-active-config” = 0x40;
    “nvda_drv” = ;
    “prev-lang:kbd” = ;
    };
    };
    Block = {
    “4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = (
    UIScale,
    );
    “7C436110-AB2A-4BBB-A880-FE41995C9F82” = (
    “boot-args”,
    );
    };
    LegacyEnable = NO;
    LegacySchema = {
    “8BE4DF61-93CA-11D2-AA0D-00E098032B8C” = (
    Boot0080,
    Boot0081,
    Boot0082,
    BootNext,
    BootOrder,
    );
    “7C436110-AB2A-4BBB-A880-FE41995C9F82” = (
    EFILoginHiDPI,
    EFIBluetoothDelay,
    “LocationServicesEnabled”,
    SystemAudioVolume,
    SystemAudioVolumeDB,
    “bluetoothActiveControllerInfo”,
    “bluetoothInternalControllerInfo”,
    flagstate,
    “fmm-computer-name”,
    “nvda_drv”,
    “prev-lang:kbd”,
    );
    };
    };

    2)——-#Configのlatest コピー none of -v, Debug=0
    NVRAM = {
    Add = {
    “4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = {
    UIScale = ;
    };
    “7C436110-AB2A-4BBB-A880-FE41995C9F82” = {
    “boot-args” = “keepsyms=1 slide=128”;
    bootercfg = “log=0, debug=0”;
    “csr-active-config” = 0x40;
    “nvda_drv” = ;
    “prev-lang:kbd” = ;
    };
    };
    Block = {
    “4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14” = (
    UIScale,
    );
    “7C436110-AB2A-4BBB-A880-FE41995C9F82” = (
    “boot-args”,
    );
    };
    LegacyEnable = NO;
    LegacySchema = {
    “8BE4DF61-93CA-11D2-AA0D-00E098032B8C” = (
    Boot0080,
    Boot0081,
    Boot0082,
    BootNext,
    BootOrder,
    );
    “7C436110-AB2A-4BBB-A880-FE41995C9F82” = (
    EFILoginHiDPI,
    EFIBluetoothDelay,
    “LocationServicesEnabled”,
    SystemAudioVolume,
    SystemAudioVolumeDB,
    “bluetoothActiveControllerInfo”,
    “bluetoothInternalControllerInfo”,
    flagstate,
    “fmm-computer-name”,
    “nvda_drv”,
    “prev-lang:kbd”,
    );
    };

    ——-

  17. 「新ブートローダーOPENCOREを使う」という この記事に惹かれ、Clover ブートローダの代替品として 追加こなすべく奮闘し、今日に至っています。

    「素材が良いのだけれど…」の心情に、今 陥っている次第です。
    なんとなれば、Catalina Public Beta Test#8までは、そこそこ順調に”てなづけて”来ましたが,
    #9の至った後 動作が不自然(Disk Utilityの FirstAidで 長時間のループが頻繁に,,, など)になり、一時休止にして、急遽 元のClover Boot ( R5070)に戻って Hacintoshを稼働させています。

    他の方がたは、どのようになさっているのでしょうか? とても、気になります。
    願わくば、 OpenCore 060にアップグレードされ、速やかにリリースされることを ?!

  18. 「新ブートローダーOPENCORE 051 (正確には0.5.1)を使う」

     Catalina Public Beta #10 (Nearly Equal GM)を導入した後、どうもOpenCore 050の起動ステップがぎこちなくなった。 上述(10/2)のようにレベル050の後継となる新コードを期待していたら、今日 Kext Updater (最新はV3.1.7)でいつものようにチェックしたら、新しく 051が入手可能であると知らされた。

     モノは試し….と、直ぐに 0.5.1の新コードを導入(置き換え)。
    直前まで起動ステップがぎこちなさで苦労していたのが、嘘のよう!! 
    すっきり、ササさっと、Catalina pb #10が立ち上がるようになり、一安心。

    追伸:Cloverboot Loaderに「もしものことあっった」場合の代替ローダーとして、遊休のEFS区画が空いていたら、このOpenCore 0.5.1のコードを導入しておくと便利です。お勧めいたします。

  19. 「新ブートローダーOPENCORE 0.5.2がリリースされました」

    あえて、変更・改善点を確認しないで 盲目的に最新版0.5.2 に更新。
    起動ステップにおいては、0.5.1と差異は感じられず。

    追記:Kexts Updaterは 3.1.8に更新し、さらに VirtualSMC.kext   1.0.8 ( 及び VirtualSMC.efiも) 、 WhateverGreen 1.3.3も 同時に更新。 

  20. お疲れ様です。
    0.5.3になって、どうなったかと、前の通りやっても、ブート画面すら出ません。
    興味自体はあるので、続けてみればと思うのですが、Success例が少ないので、探しかねてます。
    スマの辰五郎様、導入を教えてくださると幸いです。

返信を残す

メールアドレスが公開されることはありません。

「名前」「メールアドレス」「サイト」は空白でも投稿できますが、日本語が含まれない投稿は無視されます。(スパム対策)