Chinese, Simplified Localization (zh-Hans)/Internal/Localizable.strings

@@ -987,6 +987,8 @@
 /* xH6-La-kRg */
 "TT_EnableWriteUnprotector" = "允许对UEFI运行时服务代码的写访问\n保证nvram能正常写入而不受到UEFI内的一些服务的影响,无论什么主板都要选择YES.";
 
+"TT_FixupAppleEfiImages" = "修复早期版本的Mac OS X boot.efi映像错误.\n\n现代安全PE加载程序将拒绝从Mac OS X 10.4 和 10.5的boot.efi映像进行引导,由于这些文件包含W * X错误和非法重叠的部分.\n\n这个quirk检测这些问题并在内存中对这些图像进行预处理,以便现代加载程序可以接受它们.\n\n内存中的预处理与安全引导不兼容,因为加载的映像不是磁盘上的映像,因此您不能根据原始磁盘映像内容对以这种方式加载的文件进行签名.某些固件将提供注册新的未知图像的哈希值, - 这仍然行得通.另一方面,想要在安全引导下启动如此早的、不安全的映像是不太现实的.\n\n提示1: 这个怪癖只适用于苹果特定的'fat'(一个映像中有32位和64位版本)的.efi文件, 并且在新macOS的Apple安全引导路径中从未应用过.\n\n提示2: 只有在加载Mac OS X 10.4和10.5时才需要这个怪癖,甚至只有当固件本身包含一个现代的、更安全的PE COFF映像加载程序时才需要. 这包括OpenDuet的当前版本.";
+
 /* woE-nK-MFN */
 "TT_ForceBooterSignature" = "为OpenCore启动器设置macOS引导签名.\n\n引导器签名, 本质上是加载映像的SHA-1哈希值, 从休眠状态唤醒时,由Mac EFI使用它来验证引导加载程序的真实性. 此选项强制macOS使用OpenCore启动器SHA-1哈希作为启动器签名,以使OpenCore休眠在Mac EFI固件上唤醒.\n\n注意：OpenCore启动器路径由LauncherPath属性确定.";
 
@@ -1779,7 +1781,7 @@ cat /proc/asound/card{n}/codec#{m}\n\n使用AudioOutMask, 它可以播放声音
 
 "TT_ResizeUsePciRbIo" = "使用PciRootBridgeIo进行resizeegpubars和ResizeAppleGpuBars\n\n这个怪癖使得resizeegpubars和ResizeAppleGpuBars使用PciRootBridgeIo而不是PciIo. 这在有bug的PciIo实现的系统上是需要的,其中试图配置可调整大小的BAR会导致能力I/O错误. 通常,在使用ReBarUEFI修改过的旧系统上需要这样做.";
 
-"TT_ShimRetainProtocol" = "请求Linux shim为后续映像加载保持协议安装.\n\n此选项仅在从shim链接OpenCore时才需要. 必须设置它，以便允许OpenCore启动由shim中存在的证书验证的项目，而不是在系统安全启动数据库中.";
+"TT_ShimRetainProtocol" = "请求Linux shim为后续映像加载保持协议安装.\n\n此选项仅在从shim链接OpenCore时才需要. 必须设置它,以便允许OpenCore启动由shim中存在的证书验证的项目,而不是在系统安全启动数据库中.";
 
 "TT_UnblockFsConnect" = "惠普笔记本在 OpenCore 引导界面没有引导项时设置为 YES";
 

Chinese, Traditional Localization (zh-Hant)/Internal/Localizable.strings

 /* mountefiController */

English Localization (en)/Internal/Localizable.strings

@@ -987,6 +987,8 @@
 /* xH6-La-kRg */
 "TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
 
+"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
+
 /* woE-nK-MFN */
 "TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
 
@@ -1071,7 +1073,7 @@
 "TT_FuzzyMatch" = "Type: plist boolean \nFailsafe: false \nDescription: Use kernelcache with different checksums when available.\n\nOn macOS 10.6 and earlier, kernelcache filename has a checksum, which essentially is adler32 from SMBIOS product name and EfiBoot device path. On certain firmware, the EfiBoot device path differs between UEFI and macOS due to ACPI or hardware specifics, rendering kernelcache checksum as always different.\n\nThis setting allows matching the latest kernelcache with a suitable architecture when the kernelcache without suffix is unavailable, improving macOS 10.6 boot performance on several platforms.";
 
 /* zDQ-MU-J9A */
-"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as the i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, OpenCore on macOS 10.6 falls back on the x86_64 architecture whenever it is supported by the board, as it is on macOS 10.7.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
+"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, when Auto is set, OpenCore on macOS 10.6 falls back to the x86_64 architecture when it is supported by the board, as on macOS 10.7. The 32-bit KernelArch options can still be configured explicitly however.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
 
 /* ZjB-iQ-yjq */
 "TT_kernelCache" = "Type: plist string\nFailsafe: Auto\nDescription: Prefer specified kernel cache type (Auto, Cacheless, Mkext, Prelinked) when available.\n\nDifferent variants of macOS support different kernel caching variants designed to improve boot performance.\nThis setting prevents the use of faster kernel caching variants if slower variants are available for debugging and stability reasons. That is, by specifying Mkext, Prelinked will be disabled for e.g. 10.6 but not for 10.7.\n\nNote: The first version (V1) of the 32-bit prelinkedkernel is unsupported due to the corruption of kext symbol tables by the tools. On this version, the Auto setting will block prelinkedkernel booting. This also results in the keepsyms=1 boot argument being non-functional for kext frames on these systems.";

French Localization (fr)/Internal/Localizable.strings

@@ -987,6 +987,8 @@
 /* xH6-La-kRg */
 "TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
 
+"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
+
 /* woE-nK-MFN */
 "TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
 
@@ -1071,7 +1073,7 @@
 "TT_FuzzyMatch" = "Type: plist boolean \nFailsafe: false \nDescription: Use kernelcache with different checksums when available.\n\nOn macOS 10.6 and earlier, kernelcache filename has a checksum, which essentially is adler32 from SMBIOS product name and EfiBoot device path. On certain firmware, the EfiBoot device path differs between UEFI and macOS due to ACPI or hardware specifics, rendering kernelcache checksum as always different.\n\nThis setting allows matching the latest kernelcache with a suitable architecture when the kernelcache without suffix is unavailable, improving macOS 10.6 boot performance on several platforms.";
 
 /* zDQ-MU-J9A */
-"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as the i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, OpenCore on macOS 10.6 falls back on the x86_64 architecture whenever it is supported by the board, as it is on macOS 10.7.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
+"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, when Auto is set, OpenCore on macOS 10.6 falls back to the x86_64 architecture when it is supported by the board, as on macOS 10.7. The 32-bit KernelArch options can still be configured explicitly however.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
 
 /* ZjB-iQ-yjq */
 "TT_kernelCache" = "Type: plist string\nFailsafe: Auto\nDescription: Prefer specified kernel cache type (Auto, Cacheless, Mkext, Prelinked) when available.\n\nDifferent variants of macOS support different kernel caching variants designed to improve boot performance.\nThis setting prevents the use of faster kernel caching variants if slower variants are available for debugging and stability reasons. That is, by specifying Mkext, Prelinked will be disabled for e.g. 10.6 but not for 10.7.\n\nNote: The first version (V1) of the 32-bit prelinkedkernel is unsupported due to the corruption of kext symbol tables by the tools. On this version, the Auto setting will block prelinkedkernel booting. This also results in the keepsyms=1 boot argument being non-functional for kext frames on these systems.";

Korean Localization (ko)/Internal/Localizable.strings

@@ -987,6 +987,8 @@
 /* xH6-La-kRg */
 "TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
 
+"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
+
 /* woE-nK-MFN */
 "TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
 
@@ -1071,7 +1073,7 @@
 "TT_FuzzyMatch" = "Type: plist boolean \nFailsafe: false \nDescription: Use kernelcache with different checksums when available.\n\nOn macOS 10.6 and earlier, kernelcache filename has a checksum, which essentially is adler32 from SMBIOS product name and EfiBoot device path. On certain firmware, the EfiBoot device path differs between UEFI and macOS due to ACPI or hardware specifics, rendering kernelcache checksum as always different.\n\nThis setting allows matching the latest kernelcache with a suitable architecture when the kernelcache without suffix is unavailable, improving macOS 10.6 boot performance on several platforms.";
 
 /* zDQ-MU-J9A */
-"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as the i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, OpenCore on macOS 10.6 falls back on the x86_64 architecture whenever it is supported by the board, as it is on macOS 10.7.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
+"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, when Auto is set, OpenCore on macOS 10.6 falls back to the x86_64 architecture when it is supported by the board, as on macOS 10.7. The 32-bit KernelArch options can still be configured explicitly however.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
 
 /* ZjB-iQ-yjq */
 "TT_kernelCache" = "Type: plist string\nFailsafe: Auto\nDescription: Prefer specified kernel cache type (Auto, Cacheless, Mkext, Prelinked) when available.\n\nDifferent variants of macOS support different kernel caching variants designed to improve boot performance.\nThis setting prevents the use of faster kernel caching variants if slower variants are available for debugging and stability reasons. That is, by specifying Mkext, Prelinked will be disabled for e.g. 10.6 but not for 10.7.\n\nNote: The first version (V1) of the 32-bit prelinkedkernel is unsupported due to the corruption of kext symbol tables by the tools. On this version, the Auto setting will block prelinkedkernel booting. This also results in the keepsyms=1 boot argument being non-functional for kext frames on these systems.";

Polish Localization (pl)/Internal/Localizable.strings

@@ -987,6 +987,8 @@
 /* xH6-La-kRg */
 "TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
 
+"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
+
 /* woE-nK-MFN */
 "TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
 
@@ -1071,7 +1073,7 @@
 "TT_FuzzyMatch" = "Type: plist boolean \nFailsafe: false \nDescription: Use kernelcache with different checksums when available.\n\nOn macOS 10.6 and earlier, kernelcache filename has a checksum, which essentially is adler32 from SMBIOS product name and EfiBoot device path. On certain firmware, the EfiBoot device path differs between UEFI and macOS due to ACPI or hardware specifics, rendering kernelcache checksum as always different.\n\nThis setting allows matching the latest kernelcache with a suitable architecture when the kernelcache without suffix is unavailable, improving macOS 10.6 boot performance on several platforms.";
 
 /* zDQ-MU-J9A */
-"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as the i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, OpenCore on macOS 10.6 falls back on the x86_64 architecture whenever it is supported by the board, as it is on macOS 10.7.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
+"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, when Auto is set, OpenCore on macOS 10.6 falls back to the x86_64 architecture when it is supported by the board, as on macOS 10.7. The 32-bit KernelArch options can still be configured explicitly however.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
 
 /* ZjB-iQ-yjq */
 "TT_kernelCache" = "Type: plist string\nFailsafe: Auto\nDescription: Prefer specified kernel cache type (Auto, Cacheless, Mkext, Prelinked) when available.\n\nDifferent variants of macOS support different kernel caching variants designed to improve boot performance.\nThis setting prevents the use of faster kernel caching variants if slower variants are available for debugging and stability reasons. That is, by specifying Mkext, Prelinked will be disabled for e.g. 10.6 but not for 10.7.\n\nNote: The first version (V1) of the 32-bit prelinkedkernel is unsupported due to the corruption of kext symbol tables by the tools. On this version, the Auto setting will block prelinkedkernel booting. This also results in the keepsyms=1 boot argument being non-functional for kext frames on these systems.";

Resources/release_templates/Sample.plist

@@ -319,6 +319,8 @@
 			<true/>
 			<key>EnableWriteUnprotector</key>
 			<true/>
+			<key>FixupAppleEfiImages</key>
+			<false/>
 			<key>ForceBooterSignature</key>
 			<false/>
 			<key>ForceExitBootServices</key>
@@ -590,7 +592,7 @@
 				<key>ExecutablePath</key>
 				<string>Contents/MacOS/AirportBrcmFixup</string>
 				<key>MaxKernel</key>
-				<string>22.9.9</string>
+				<string></string>
 				<key>MinKernel</key>
 				<string>12.0.0</string>
 				<key>PlistPath</key>
@@ -626,7 +628,7 @@
 				<key>ExecutablePath</key>
 				<string></string>
 				<key>MaxKernel</key>
-				<string>22.9.9</string>
+				<string></string>
 				<key>MinKernel</key>
 				<string>17.0.0</string>
 				<key>PlistPath</key>
@@ -644,7 +646,7 @@
 				<key>ExecutablePath</key>
 				<string>Contents/MacOS/NVMeFix</string>
 				<key>MaxKernel</key>
-				<string>22.9.9</string>
+				<string></string>
 				<key>MinKernel</key>
 				<string>18.0.0</string>
 				<key>PlistPath</key>
@@ -860,7 +862,7 @@
 			</dict>
 			<dict>
 				<key>Arch</key>
-				<string>x86_64</string>
+				<string>Any</string>
 				<key>Base</key>
 				<string>_disable_serial_output</string>
 				<key>Comment</key>
@@ -890,7 +892,7 @@
 			</dict>
 			<dict>
 				<key>Arch</key>
-				<string>x86_64</string>
+				<string>Any</string>
 				<key>Base</key>
 				<string>_vstart</string>
 				<key>Comment</key>
@@ -920,7 +922,7 @@
 			</dict>
 			<dict>
 				<key>Arch</key>
-				<string>x86_64</string>
+				<string>Any</string>
 				<key>Base</key>
 				<string>_vstart</string>
 				<key>Comment</key>

Russian Localization (ru)/Internal/Localizable.strings

@@ -987,6 +987,8 @@
 /* xH6-La-kRg */
 "TT_EnableWriteUnprotector" = "Type: plist boolean\nFailsafe: false\nDescription: Permit write access to UEFI runtime services code.\n\nThis option bypasses RˆX permissions in code pages of UEFI runtime services by removing write protection (WP) bit from CR0 register during their execution. This quirk requires OC_FIRMWARE_RUNTIME protocol implemented in OpenRuntime.efi.\n\nNote: This quirk may potentially weaken firmware security. Please use RebuildAppleMemoryMap if the firmware supports memory attributes table (MAT). Refer to the OCABC: MAT support is 1/0 log entry to determine wheter MAT is supported.";
 
+"TT_FixupAppleEfiImages" = "Type: plist boolean\nFailsafe: false\nDescription: Fix errors in early Mac OS X boot.efi images.\n\nModern secure PE loaders will refuse to load boot.efi images from Mac OS X 10.4 and 10.5 due to these files containing WˆX errors and illegal overlapping sections.\n\nThis quirk detects these issues and pre-processes such images in memory, so that a modern loader can accept them.\n\nPre-processing in memory is incompatible with secure boot, as the image loaded is not the image on disk, so you cannot sign files which are loaded in this way based on their original disk image contents. Certain firmware will offer to register the hash of new, unknown images - this would still work. On the other hand, it is not particularly realistic to want to start such early, insecure images with secure boot anyway.\n\nNote 1: The quirk is only applied to Apple-specific ‘fat’ (both 32-bit and 64-bit versions in one image) .efi files, and is never applied during the Apple secure boot path for newer macOS.\n\nNote 2: The quirk is only needed for loading Mac OS X 10.4 and 10.5, and even then only if the firmware itself includes a modern, more secure PE COFF image loader. This includes current builds of OpenDuet.";
+
 /* woE-nK-MFN */
 "TT_ForceBooterSignature" = "Type: plist boolean\nFailsafe: false\nDescription: Set macOS boot-signature to OpenCore launcher.\n\nBooter signature, essentially a SHA-1 hash of the loaded image, is used by Mac EFI to verify the authenticity of the bootloader when waking from hibernation. This option forces macOS to use OpenCore launcher SHA-1 hash as a booter signature to let OpenCore shim hibernation wake on Mac EFI firmware.\n\nNote: OpenCore launcher path is determined from LauncherPath property.";
 
@@ -1071,7 +1073,7 @@
 "TT_FuzzyMatch" = "Type: plist boolean \nFailsafe: false \nDescription: Use kernelcache with different checksums when available.\n\nOn macOS 10.6 and earlier, kernelcache filename has a checksum, which essentially is adler32 from SMBIOS product name and EfiBoot device path. On certain firmware, the EfiBoot device path differs between UEFI and macOS due to ACPI or hardware specifics, rendering kernelcache checksum as always different.\n\nThis setting allows matching the latest kernelcache with a suitable architecture when the kernelcache without suffix is unavailable, improving macOS 10.6 boot performance on several platforms.";
 
 /* zDQ-MU-J9A */
-"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as the i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, OpenCore on macOS 10.6 falls back on the x86_64 architecture whenever it is supported by the board, as it is on macOS 10.7.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
+"TT_kernelArch" = "Type: plist string\nFailsafe: Auto (Choose the preferred architecture automatically)\nDescription: Prefer specified kernel architecture (i386, i386-user32, x86_64) when available.\n\nOn macOS 10.7 and earlier, the XNU kernel can boot with architectures different from the usual x86_64. This setting will use the specified architecture to boot macOS when it is supported by the macOS and the configuration:\n• i386 — Use i386 (32-bit) kernel when available.\n• i386-user32 — Use i386 (32-bit) kernel when available and force the use of 32-bit userspace on 64-bit capable processors if supported by the operating system.\n\t– On macOS, 64-bit capable processors are assumed to support SSSE3. This is not the case for older 64-bit capable Pentium processors, which cause some applications to crash on macOS 10.6. This behaviour corresponds to the -legacy kernel boot argument.\n\t– This option is unavailable on macOS 10.4 and 10.5 when running on 64-bit firmware due to an uninitialised 64-bit segment in the XNU kernel, which causes AppleEFIRuntime to incorrectly execute 64-bit code as 16-bit code.\n• x86_64 — Use x86_64 (64-bit) kernel when available.\n\nThe algorithm used to determine the preferred kernel architecture is set out below.\n(a) arch argument in image arguments (e.g. when launched via UEFI Shell) or in boot-args variable overrides any compatibility checks and forces the specified architecture, completing this algorithm.\n(b) OpenCore build architecture restricts capabilities to i386 and i386-user32 mode for the 32-bit firmware variant.\n(c) Determined EfiBoot version restricts architecture choice:\n\t• 10.4-10.5 — i386 or i386-user32 (only on 32-bit firmware) • 10.6 — i386, i386-user32, or x86_64\n\t• 10.7 — i386 or x86_64\n\t• 10.8 or newer — x86_64\n(d) If KernelArch is set to Auto and SSSE3 is not supported by the CPU, capabilities are restricted to i386-user32 if supported by EfiBoot.\n(e) Board identifier (from SMBIOS) based on EfiBoot version disables x86_64 support on an unsupported model if any i386 variant is supported. Auto is not consulted here as the list is not overridable in EfiBoot.\n(f) KernelArch restricts the support to the explicitly specified architecture (when not set to Auto) if the architecture remains present in the capabilities.\n(g) The best supported architecture is chosen in this order: x86_64, i386, i386-user32.\n\nUnlike macOS 10.7 (where certain board identifiers are treated as i386 only machines), and macOS 10.5 or earlier (where x86_64 is not supported by the macOS kernel), macOS 10.6 is very special. The architecture choice on macOS 10.6 depends on many factors including not only the board identifier, but also the macOS product type (client vs server), macOS point release, and amount of RAM. The detection of all these is complicated and impractical, as several point releases had implementation flaws resulting in a failure to properly execute the server detection in the first place. For this reason, when Auto is set, OpenCore on macOS 10.6 falls back to the x86_64 architecture when it is supported by the board, as on macOS 10.7. The 32-bit KernelArch options can still be configured explicitly however.\n\nNote: 3+2 and 6+4 hotkeys to choose the preferred architecture are unsupported as they are handled by EfiBoot and hence, difficult to detect.";
 
 /* ZjB-iQ-yjq */
 "TT_kernelCache" = "Type: plist string\nFailsafe: Auto\nDescription: Prefer specified kernel cache type (Auto, Cacheless, Mkext, Prelinked) when available.\n\nDifferent variants of macOS support different kernel caching variants designed to improve boot performance.\nThis setting prevents the use of faster kernel caching variants if slower variants are available for debugging and stability reasons. That is, by specifying Mkext, Prelinked will be disabled for e.g. 10.6 but not for 10.7.\n\nNote: The first version (V1) of the 32-bit prelinkedkernel is unsupported due to the corruption of kext symbol tables by the tools. On this version, the Auto setting will block prelinkedkernel booting. This also results in the keepsyms=1 boot argument being non-functional for kext frames on these systems.";