自 OpenCore 慢慢普及开来以后,笔者时常见到有群友提问为什么使用 OpenCore 引导 Windows 会蓝屏,而直接在 BIOS 中选择 Windows Boot Manager 进行引导又不会?

OpenCore 和 Clover 最大的不同之一是,OC 开发团队 acidanthera 决定在 OpenCore 中的部分设置,SMBIOS 机型信息、DSDT 和 SSDT,都一视同仁地对所有操作系统生效。这样做的目的是让黑苹果更像白苹果,但是却有可能导致在 macOS 上正常可用的 ACPI 表到了其它操作系统上反而出现问题。

换言之,就是注入的信息让 Windows 崩溃了。这些信息共有三个部分,一是部分设置,二是 ACPI 文件(即 DSDT 和 SSDT),三是 SMBIOS ID。

接下来介绍对应的解决办法。

 

针对 Quirks 设置的修正

这个部分目前仅涉及一项,即 Booter 下的 Quirks 设置中的 SyncRuntimePermissions。

SyncRuntimePermissions 主要功能是修复与 MAT 表的对齐问题,并且需要使用 MAT 表启动 Windows 和 Linux,也推荐用于 macOS。当启用了 RebuildAppleMemoryMap 时,建议一同勾选此项,可解决部分机型引导 Windows 蓝屏问题。

下图是 OpenCore Configurator 的对应位置:

修复 OpenCore 引导 Windows 蓝屏

下图是 OCAuxiliaryTools 的对应位置:

修复 OpenCore 引导 Windows 蓝屏

下图是 ProperTree 的对应位置:

修复 OpenCore 引导 Windows 蓝屏

 

针对 ACPI 文件的修正

如果使用 OpenCore 引导 Windows 时出现蓝屏,并且明确注明“ACPI_BIOS_ERROR”或“ACPI_ERROR”(如下图),那么十之八九与 OpenCore 注入的 SSDT 文件有关。

修复 OpenCore 引导 Windows 蓝屏

修复的方法是编辑 SSDT 文件,可惜的是此方法需要一定的编程基础或理解能力,因此有一定门槛。

ACPI 文件一般以 xxx.dsl 或 xxx.aml 两种文件后缀形式出现,dsl 是源文件,aml 是已编译的文件,OpenCore 或 Clover 等引导工具使用的是后者。它们的编辑工具,macOS 建议使用 MaciASL,Windows 系统可使用 QtiASL。

下面以第十代酷睿 + 400 系主板为例进行演示:

修复 OpenCore 引导 Windows 蓝屏

「注意」SSDT 文件的命名并没有统一的强制性要求,文件名也不区分大小写,只要自己明白各个文件的作用就行。因此,上图中的三个文件在你的 EFI 文件夹里也可能被命名成以下几个:

  • SSDT-AWAC-disable.aml :用于关闭系统内置的 AWAC 时钟,因为 macOS 仅支持传统 RTC,用于 H310 及更高更新的主板芯片组
  • SSDT-EC-USBX.aml :这个略微复杂一些。在台式机上,EC(嵌入式控制器)与 AppleACPIEC 驱动程序不兼容,为了解决这个问题,我们需要禁用这个设备,并创建一个假的 EC 设备让 AppleBusPowerController 加载,在高于第六代酷睿的平台上,AppleBusPowerController 还需要一个名为 USBX 设备来为 USB 提供电源属性;而在笔记本机型上,EC 用于提供快捷键功能和电池控制,因此不能直接禁用,所以需要创建一个假的 EC 设备,以满足 macOS 的要求;综上,台式机和笔记本因需求不同,EC 相关的 SSDT 并不通用,注意选择。
  • SSDT-PLUG.aml :用于让 macOS 内核的 XCPM(XNU 的 CPU 电源管理)接管 CPU 的电源管理,有了原生电源管理,你的处理器才能正常睿频或休眠。

下面以修改 SSDT-AWAC.aml 为例:

修复 OpenCore 引导 Windows 蓝屏

我们将为它添加系统判断语句(用于判断当前系统是不是 macOS):

If ( _OSI( "Darwin" ) ) {  // 判断当前系统是否macOS
    xxxx  // 如果是,则此部分内容生效
}  // 结束判断

「注意」上面是因为需要解释,SSDT 文件中不能使用中文进行注释

 

添加到代码中,见下图:

修复 OpenCore 引导 Windows 蓝屏

整个过程有 3 个重点:

  • 任何符号绝对不能错
  • 不要漏掉 { 和 },把原来的内容包裹到 { } 中间
  • SSDT 文件中不能使用中文进行注释

如果你还是不明白在哪个位置插入判断句,看下面一步一改变的例子:

STAS = One

↓↓↓

{ STAS = One }

↓↓↓

If (  ) { STAS = One }

↓↓↓

If ( _OSI("Darwin") ) { STAS = One }

↓↓↓

If ( _OSI("Darwin") )
{
    STAS = One
}

 

.aml 编辑完成后直接保存文件即可,如果你编辑的是 .dsl 源文件,还需要导出成 .aml 格式,点击左上角 文件 → 另存为 → 文件格式选择 ACPI Machine Language Binary ,举例如下:

修复 OpenCore 引导 Windows 蓝屏

其它 SSDT 文件修改方法以此类推,全部修改保存完成后即可尝试引导 Windows 看是否解决了问题。

 

修正 ACPI 方法的补充

如果上述步骤未能解决你的问题,可继续参考此部分。

在不断的实践中,笔者发现有部分机型的 SSDT 文件在 Method 之后添加系统判断没有作用,需要放到外部表引用之后,例如:

 

修复 OpenCore 引导 Windows 蓝屏

即,在文件一开始定义块(DefinitionBlock)中,引用外部表(一个或多个 External)之后,直接加入判断句,将整个 SSDT 的文件内容囊括进整个系统判断中。这种情况下,完整的判断句应该如下:

If ( _OSI( "Darwin" ) ) {   // 判断当前系统是否macOS
    xxxx   // 如果是,则此部分内容生效
} else {  // 如果不是macOS
    // 这里空白什么都不要写
}   // 结束判断

「注意」上面是因为需要解释,SSDT 文件中不能使用中文进行注释

下面是更复杂的 SSDT-EC-USBX.aml 举例:

修复 OpenCore 引导 Windows 蓝屏

 

 

通用 SSDT 文件包

标准通用的 SSDT 文件在 OC 发行包中会附带,不知道在哪里找的

 

蓝奏云:点击进入,提取码:6ztv

 

 

SMBIOS 机型问题

通过 OpenCore 引导的 Windows,会将机型修改为 Mac 机型,这时如果通过鲁大师或其它系统检测软件进行检测,会得到类似“Acidanthera iMac20,2 All in one”这种结果,而不是原来的类似“Windows X64 电脑”的结果。

修复 OpenCore 引导 Windows 蓝屏

「提示」如果是真正的白苹果,则不会有“Acidanthera”字样,会被“Apple”或者“苹果”替代。

这也是因为 OpenCore 向系统注入了 SMBIOS 机型信息导致的结果。笔者刚开始并不觉得这个特点可能存在什么问题,直到后来遇到一位群友,他的主板是终生质保,在运行厂家配套的系统控制软件时,会显示主板的保修信息,但如果通过 OpenCore 引导,这个信息就无法读取了。

如果这种情况仅仅只影响信息读取和显示,那么另一种情况就是真切影响到了使用。这位倒霉的群友需要使用公司购买的行业专用软件,软件通过加密狗绑定主板信息才能正常开启和运行,所以通过 OpenCore 引导 Windows 后,完全没法使用。

这类情况目前可通过修改 config.plist 方法解决,如下:

  • Kernel → Quirks → CustomSMBIOSGuid 勾选/Enabled
  • Platforminfo → Generic → SpoofVendor 取消勾选/Disabled
  • Platforminfo → UpdateSMBIOSMode → 设置为 Custom

除了以上方法外,其它途径还有几种思路:

  • 改用 Clover :在 OC 团队停止开发 AptioMemoryFix.efi 后,Clover 陷入了一段时间的沉寂,不过,自 r5123 版本开始,Clover 正式集成了 OpenCore 的内核,版本是 0.6.3,在近期升级到 r5142 后,OC 内核更新到了 0.7.5。因此,使用 Clover 引导 Big Sur 或目前的 Monterey 是可行的,Clover 一直以来都不会全局注入信息;
  • 尝试使用 Windows 的 System-uuid:部分软件会以系统 uuid 为准进行绑定,因此在 OpenCore 等引导工具指定使用和 Windows 相同的 uuid 或许可以解决上述情况二的问题,使用相同 uuid 可能可以同时解决运行 macOS 后 Windows 激活失效的问题。
  • 改用其它人修改过的 OpenCore :OpenCore 一直存在一个非官方的 Mod 版本,这个版本的最大特点就是去掉了全局信息注入,也就是本文提到的信息注入带来的所有问题,理论上 Mod 版本都没有,但是原来在 GitHub 上更新的 N.D.K 版本 2020 年就已停更,新的 Mod 版本主要在远景论坛发布和维护。

发表评论

后才能评论