提交 48c5e541 编写于 作者: M mackie100

Updated localizations

@Eugene-grb @bluehomewu @btwise @socialskyo @sebaprawilnie @droofy
上级 92cc6cd4
......@@ -1640,7 +1640,7 @@
"TT_GopPassThrough" = "在UGA协议实例之上提供GOP协议实例.\n\n该选项支持的值如下:\n• Enabled — 为所有UGA协议提供GOP.\n• Apple — 为启用了AppleFramebufferInfo的协议提供GOP.\n• Disabled — 不提供GOP.\n\n此选项通过基于UGA的代理为未实现协议的固件提供GOP协议.\n\n注意:此选项要求启用ProvideConsoleGop.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.\n\nNote 1: Automatic scale factor detection works on the basis of total pixel area and may fail on small HiDPI displays, in which case the value may be manually managed using the NVRAM section.\n\nNote 2: When switching from manually specified NVRAM variable to this preference an NVRAM reset may be needed.";
/* ProtocolOverrides */
"TT_AppleAudio" = "重新安装具有内置版本的Apple音频协议.\nApple音频协议允许macOS引导程序和OpenCore播放声音和信号以进行屏幕阅读或声音错误报告.\n支持的协议是蜂鸣声生成和VoiceOver. 在macOS High Sierra(10.13)之前不受支持.相反,较早的macOS版本使用AppleHDA协议,该协议目前尚未实现.\n\n要在实现某些协议的Mac系统上的OpenCore用户界面中获得音频播放,应启用此设置.\n\n注意:需要在UEFI-->Audio部分中配置后端音频驱动程序,这些协议才能使用.";
......
......@@ -999,7 +999,7 @@
/* JMF-hg-GgC */
"TT_RebuildAppleMemoryMap" = "Type: plist boolean\nFailsafe: false\nDescription: Generate Memory Map compatible with macOS.\n\nThe Apple kernel has several limitations on parsing the UEFI memory map:\n• The Memory map size must not exceed 4096 bytes as the Apple kernel maps it as a single 4K page. As some types of firmware can have very large memory maps, potentially over 100 entries, the Apple kernel will crash on boot.\n• The Memory attributes table is ignored. EfiRuntimeServicesCode memory statically gets RX permissions while all other memory types get RW permissions. As some firmware drivers may write to global variables at runtime, the Apple kernel will crash at calling UEFI runtime services unless the driver .data section has a EfiRuntimeServicesData type.\n\nTo workaround these limitations, this quirk applies memory attribute table permissions to the memory map passed to the Apple kernel and optionally attempts to unify contiguous slots of similar types if the resulting memory map exceeds 4 KB.\n\nNote 1: Since several types of firmware come with incorrect memory protection tables, this quirk often comes paired with SyncRuntimePermissions.\n\nNote 2 : The need for this quirk is determined by early boot failures. This quirk replaces EnableWriteUnprotector on firmware supporting Memory Attribute Tables (MAT). This quirk is typically unnecessary when using OpenDuetPkg but may be required to boot macOS 10.6, and earlier, for reasons that are as yet unclear.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor the development purposes one may take the risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor development purposes one may take risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
/* l3S-mh-5k0 */
"TT_SetupVirtualMap" = "Type: plist boolean\nFailsafe: false\nDescription: Setup virtual memory at SetVirtualAddresses.\n\nSome types of firmware access memory by virtual addresses after a SetVirtualAddresses call, resulting in early boot crashes. This quirk workarounds the problem by performing early boot identity mapping of assigned virtual addresses to physical memory.\n\nNote: The need for this quirk is determined by early boot failures.";
......@@ -1640,7 +1640,7 @@
"TT_GopPassThrough" = "Type: plist string\nFailsafe: Disabled\nDescription: Provide GOP protocol instances on top of UGA protocol instances.\n\nThe supported values for the option are as follows:\n• Enabled — provide GOP for all UGA protocols.\n• Apple — provide GOP for AppleFramebufferInfo-enabled protocols.\n• Disabled — do not provide GOP.\n\nThis option provides the GOP protocol via a UGA-based proxy for firmware that do not implement the protocol.\n\nNote: This option requires ProvideConsoleGop to be enabled.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.\n\nNote 1: Automatic scale factor detection works on the basis of total pixel area and may fail on small HiDPI displays, in which case the value may be manually managed using the NVRAM section.\n\nNote 2: When switching from manually specified NVRAM variable to this preference an NVRAM reset may be needed.";
/* ProtocolOverrides */
"TT_AppleAudio" = "Type: plist boolean\nFailsafe: false\nDescription: Replaces Apple audio protocols with builtin versions.\n\nApple audio protocols allow OpenCore and the macOS bootloader to play sounds and signals for screen reading or audible error reporting. Supported protocols are beep generation and VoiceOver. The VoiceOver protocol is specific to Gibraltar machines (T2) and is not supported before macOS High Sierra (10.13). Older macOS versions use the AppleHDA protocol (which is not currently implemented) instead.\n\nOnly one set of audio protocols can be available at a time, so this setting should be enabled in order to enable audio playback in the OpenCore user interface on Mac systems implementing some of these protocols.\n\nNote: The backend audio driver needs to be configured in UEFI Audio section for these protocols to be able to stream audio.";
......@@ -1708,6 +1708,6 @@
"TT_EnableVectorAcceleration" = "Type: plist boolean\nFailsafe: false\nDescription: Enable AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore-managed NVRAM system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ResizeGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Configure GPU PCI BAR sizes.\n\nThis quirk sets GPU PCI BAR sizes as specified or chooses the largest available below the ResizeGpuBars value. The specified value follows PCI Resizable BAR spec. Use 0 for 1 MB, 1 for 2 MB, 2 for 4 MB, and so on up to 19 for 512 GB.\n\nResizable BAR technology allows to ease PCI device programming by mapping a configurable memory region, BAR, into CPU address space (e.g. VRAM to RAM) as opposed to a fixed memory region. This technology is necessary, because one cannot map the largest memory region by default, for the reasons of backwards compatibility with older hardware not supporting 64-bit BARs. Consequentially devices of the last decade use BARs up to 256 MB by default (4 remaining bits are used by other data) but generally allow resizing them to both smaller and larger powers of two (e.g. from 1 MB up to VRAM size).\n\nOperating systems targeting x86 platforms generally do not control PCI address space, letting UEFI firmware decide on the BAR addresses and sizes. This illicit practice resulted in Resizable BAR technology being unused up until 2020 despite being standardised in 2008 and becoming widely available in the hardware soon after.\n\nModern UEFI firmware allow the use of Resizable BAR technology but generally restrict the configurable options to failsafe default (OFF) and maximum available (ON). This quirk allows to fine-tune this value for testing and development purposes.\n\nConsider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeGpuBars to 16 GB will change BAR0 to 8 GB and leave BAR1 unchanged.\n\nNote 1 : This quirk shall not be used to workaround macOS limitation to address BARs over 1 GB. ResizeAppleGpuBars should be used instead.\n\nNote 2: While this quirk can increase GPU PCI BAR sizes, this will not work on most firmware as is, because the quirk does not relocate BARs in memory, and they will likely overlap. Contributions to improve this feature are welcome.";
......@@ -999,7 +999,7 @@
/* JMF-hg-GgC */
"TT_RebuildAppleMemoryMap" = "Type: plist boolean\nFailsafe: false\nDescription: Generate Memory Map compatible with macOS.\n\nThe Apple kernel has several limitations on parsing the UEFI memory map:\n• The Memory map size must not exceed 4096 bytes as the Apple kernel maps it as a single 4K page. As some types of firmware can have very large memory maps, potentially over 100 entries, the Apple kernel will crash on boot.\n• The Memory attributes table is ignored. EfiRuntimeServicesCode memory statically gets RX permissions while all other memory types get RW permissions. As some firmware drivers may write to global variables at runtime, the Apple kernel will crash at calling UEFI runtime services unless the driver .data section has a EfiRuntimeServicesData type.\n\nTo workaround these limitations, this quirk applies memory attribute table permissions to the memory map passed to the Apple kernel and optionally attempts to unify contiguous slots of similar types if the resulting memory map exceeds 4 KB.\n\nNote 1: Since several types of firmware come with incorrect memory protection tables, this quirk often comes paired with SyncRuntimePermissions.\n\nNote 2 : The need for this quirk is determined by early boot failures. This quirk replaces EnableWriteUnprotector on firmware supporting Memory Attribute Tables (MAT). This quirk is typically unnecessary when using OpenDuetPkg but may be required to boot macOS 10.6, and earlier, for reasons that are as yet unclear.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor the development purposes one may take the risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor development purposes one may take risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
/* l3S-mh-5k0 */
"TT_SetupVirtualMap" = "Type: plist boolean\nFailsafe: false\nDescription: Setup virtual memory at SetVirtualAddresses.\n\nSome types of firmware access memory by virtual addresses after a SetVirtualAddresses call, resulting in early boot crashes. This quirk workarounds the problem by performing early boot identity mapping of assigned virtual addresses to physical memory.\n\nNote: The need for this quirk is determined by early boot failures.";
......@@ -1640,7 +1640,7 @@
"TT_GopPassThrough" = "Type: plist string\nFailsafe: Disabled\nDescription: Provide GOP protocol instances on top of UGA protocol instances.\n\nThe supported values for the option are as follows:\n• Enabled — provide GOP for all UGA protocols.\n• Apple — provide GOP for AppleFramebufferInfo-enabled protocols.\n• Disabled — do not provide GOP.\n\nThis option provides the GOP protocol via a UGA-based proxy for firmware that do not implement the protocol.\n\nNote: This option requires ProvideConsoleGop to be enabled.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.\n\nNote 1: Automatic scale factor detection works on the basis of total pixel area and may fail on small HiDPI displays, in which case the value may be manually managed using the NVRAM section.\n\nNote 2: When switching from manually specified NVRAM variable to this preference an NVRAM reset may be needed.";
/* ProtocolOverrides */
"TT_AppleAudio" = "Type: plist boolean\nFailsafe: false\nDescription: Replaces Apple audio protocols with builtin versions.\n\nApple audio protocols allow OpenCore and the macOS bootloader to play sounds and signals for screen reading or audible error reporting. Supported protocols are beep generation and VoiceOver. The VoiceOver protocol is specific to Gibraltar machines (T2) and is not supported before macOS High Sierra (10.13). Older macOS versions use the AppleHDA protocol (which is not currently implemented) instead.\n\nOnly one set of audio protocols can be available at a time, so this setting should be enabled in order to enable audio playback in the OpenCore user interface on Mac systems implementing some of these protocols.\n\nNote: The backend audio driver needs to be configured in UEFI Audio section for these protocols to be able to stream audio.";
......@@ -1708,6 +1708,6 @@
"TT_EnableVectorAcceleration" = "Type: plist boolean\nFailsafe: false\nDescription: Enable AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore-managed NVRAM system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ResizeGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Configure GPU PCI BAR sizes.\n\nThis quirk sets GPU PCI BAR sizes as specified or chooses the largest available below the ResizeGpuBars value. The specified value follows PCI Resizable BAR spec. Use 0 for 1 MB, 1 for 2 MB, 2 for 4 MB, and so on up to 19 for 512 GB.\n\nResizable BAR technology allows to ease PCI device programming by mapping a configurable memory region, BAR, into CPU address space (e.g. VRAM to RAM) as opposed to a fixed memory region. This technology is necessary, because one cannot map the largest memory region by default, for the reasons of backwards compatibility with older hardware not supporting 64-bit BARs. Consequentially devices of the last decade use BARs up to 256 MB by default (4 remaining bits are used by other data) but generally allow resizing them to both smaller and larger powers of two (e.g. from 1 MB up to VRAM size).\n\nOperating systems targeting x86 platforms generally do not control PCI address space, letting UEFI firmware decide on the BAR addresses and sizes. This illicit practice resulted in Resizable BAR technology being unused up until 2020 despite being standardised in 2008 and becoming widely available in the hardware soon after.\n\nModern UEFI firmware allow the use of Resizable BAR technology but generally restrict the configurable options to failsafe default (OFF) and maximum available (ON). This quirk allows to fine-tune this value for testing and development purposes.\n\nConsider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeGpuBars to 16 GB will change BAR0 to 8 GB and leave BAR1 unchanged.\n\nNote 1 : This quirk shall not be used to workaround macOS limitation to address BARs over 1 GB. ResizeAppleGpuBars should be used instead.\n\nNote 2: While this quirk can increase GPU PCI BAR sizes, this will not work on most firmware as is, because the quirk does not relocate BARs in memory, and they will likely overlap. Contributions to improve this feature are welcome.";
......@@ -999,7 +999,7 @@
/* JMF-hg-GgC */
"TT_RebuildAppleMemoryMap" = "Type: plist boolean\nFailsafe: false\nDescription: Generate Memory Map compatible with macOS.\n\nThe Apple kernel has several limitations on parsing the UEFI memory map:\n• The Memory map size must not exceed 4096 bytes as the Apple kernel maps it as a single 4K page. As some types of firmware can have very large memory maps, potentially over 100 entries, the Apple kernel will crash on boot.\n• The Memory attributes table is ignored. EfiRuntimeServicesCode memory statically gets RX permissions while all other memory types get RW permissions. As some firmware drivers may write to global variables at runtime, the Apple kernel will crash at calling UEFI runtime services unless the driver .data section has a EfiRuntimeServicesData type.\n\nTo workaround these limitations, this quirk applies memory attribute table permissions to the memory map passed to the Apple kernel and optionally attempts to unify contiguous slots of similar types if the resulting memory map exceeds 4 KB.\n\nNote 1: Since several types of firmware come with incorrect memory protection tables, this quirk often comes paired with SyncRuntimePermissions.\n\nNote 2 : The need for this quirk is determined by early boot failures. This quirk replaces EnableWriteUnprotector on firmware supporting Memory Attribute Tables (MAT). This quirk is typically unnecessary when using OpenDuetPkg but may be required to boot macOS 10.6, and earlier, for reasons that are as yet unclear.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor the development purposes one may take the risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor development purposes one may take risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
/* l3S-mh-5k0 */
"TT_SetupVirtualMap" = "Type: plist boolean\nFailsafe: false\nDescription: Setup virtual memory at SetVirtualAddresses.\n\nSome types of firmware access memory by virtual addresses after a SetVirtualAddresses call, resulting in early boot crashes. This quirk workarounds the problem by performing early boot identity mapping of assigned virtual addresses to physical memory.\n\nNote: The need for this quirk is determined by early boot failures.";
......@@ -1640,7 +1640,7 @@
"TT_GopPassThrough" = "Type: plist string\nFailsafe: Disabled\nDescription: Provide GOP protocol instances on top of UGA protocol instances.\n\nThe supported values for the option are as follows:\n• Enabled — provide GOP for all UGA protocols.\n• Apple — provide GOP for AppleFramebufferInfo-enabled protocols.\n• Disabled — do not provide GOP.\n\nThis option provides the GOP protocol via a UGA-based proxy for firmware that do not implement the protocol.\n\nNote: This option requires ProvideConsoleGop to be enabled.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.\n\nNote 1: Automatic scale factor detection works on the basis of total pixel area and may fail on small HiDPI displays, in which case the value may be manually managed using the NVRAM section.\n\nNote 2: When switching from manually specified NVRAM variable to this preference an NVRAM reset may be needed.";
/* ProtocolOverrides */
"TT_AppleAudio" = "Type: plist boolean\nFailsafe: false\nDescription: Replaces Apple audio protocols with builtin versions.\n\nApple audio protocols allow OpenCore and the macOS bootloader to play sounds and signals for screen reading or audible error reporting. Supported protocols are beep generation and VoiceOver. The VoiceOver protocol is specific to Gibraltar machines (T2) and is not supported before macOS High Sierra (10.13). Older macOS versions use the AppleHDA protocol (which is not currently implemented) instead.\n\nOnly one set of audio protocols can be available at a time, so this setting should be enabled in order to enable audio playback in the OpenCore user interface on Mac systems implementing some of these protocols.\n\nNote: The backend audio driver needs to be configured in UEFI Audio section for these protocols to be able to stream audio.";
......@@ -1708,6 +1708,6 @@
"TT_EnableVectorAcceleration" = "Type: plist boolean\nFailsafe: false\nDescription: Enable AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore-managed NVRAM system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ResizeGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Configure GPU PCI BAR sizes.\n\nThis quirk sets GPU PCI BAR sizes as specified or chooses the largest available below the ResizeGpuBars value. The specified value follows PCI Resizable BAR spec. Use 0 for 1 MB, 1 for 2 MB, 2 for 4 MB, and so on up to 19 for 512 GB.\n\nResizable BAR technology allows to ease PCI device programming by mapping a configurable memory region, BAR, into CPU address space (e.g. VRAM to RAM) as opposed to a fixed memory region. This technology is necessary, because one cannot map the largest memory region by default, for the reasons of backwards compatibility with older hardware not supporting 64-bit BARs. Consequentially devices of the last decade use BARs up to 256 MB by default (4 remaining bits are used by other data) but generally allow resizing them to both smaller and larger powers of two (e.g. from 1 MB up to VRAM size).\n\nOperating systems targeting x86 platforms generally do not control PCI address space, letting UEFI firmware decide on the BAR addresses and sizes. This illicit practice resulted in Resizable BAR technology being unused up until 2020 despite being standardised in 2008 and becoming widely available in the hardware soon after.\n\nModern UEFI firmware allow the use of Resizable BAR technology but generally restrict the configurable options to failsafe default (OFF) and maximum available (ON). This quirk allows to fine-tune this value for testing and development purposes.\n\nConsider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeGpuBars to 16 GB will change BAR0 to 8 GB and leave BAR1 unchanged.\n\nNote 1 : This quirk shall not be used to workaround macOS limitation to address BARs over 1 GB. ResizeAppleGpuBars should be used instead.\n\nNote 2: While this quirk can increase GPU PCI BAR sizes, this will not work on most firmware as is, because the quirk does not relocate BARs in memory, and they will likely overlap. Contributions to improve this feature are welcome.";
......@@ -999,7 +999,7 @@
/* JMF-hg-GgC */
"TT_RebuildAppleMemoryMap" = "Type: plist boolean\nFailsafe: false\nDescription: Generate Memory Map compatible with macOS.\n\nThe Apple kernel has several limitations on parsing the UEFI memory map:\n• The Memory map size must not exceed 4096 bytes as the Apple kernel maps it as a single 4K page. As some types of firmware can have very large memory maps, potentially over 100 entries, the Apple kernel will crash on boot.\n• The Memory attributes table is ignored. EfiRuntimeServicesCode memory statically gets RX permissions while all other memory types get RW permissions. As some firmware drivers may write to global variables at runtime, the Apple kernel will crash at calling UEFI runtime services unless the driver .data section has a EfiRuntimeServicesData type.\n\nTo workaround these limitations, this quirk applies memory attribute table permissions to the memory map passed to the Apple kernel and optionally attempts to unify contiguous slots of similar types if the resulting memory map exceeds 4 KB.\n\nNote 1: Since several types of firmware come with incorrect memory protection tables, this quirk often comes paired with SyncRuntimePermissions.\n\nNote 2 : The need for this quirk is determined by early boot failures. This quirk replaces EnableWriteUnprotector on firmware supporting Memory Attribute Tables (MAT). This quirk is typically unnecessary when using OpenDuetPkg but may be required to boot macOS 10.6, and earlier, for reasons that are as yet unclear.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor the development purposes one may take the risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor development purposes one may take risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
/* l3S-mh-5k0 */
"TT_SetupVirtualMap" = "Type: plist boolean\nFailsafe: false\nDescription: Setup virtual memory at SetVirtualAddresses.\n\nSome types of firmware access memory by virtual addresses after a SetVirtualAddresses call, resulting in early boot crashes. This quirk workarounds the problem by performing early boot identity mapping of assigned virtual addresses to physical memory.\n\nNote: The need for this quirk is determined by early boot failures.";
......@@ -1640,7 +1640,7 @@
"TT_GopPassThrough" = "Type: plist string\nFailsafe: Disabled\nDescription: Provide GOP protocol instances on top of UGA protocol instances.\n\nThe supported values for the option are as follows:\n• Enabled — provide GOP for all UGA protocols.\n• Apple — provide GOP for AppleFramebufferInfo-enabled protocols.\n• Disabled — do not provide GOP.\n\nThis option provides the GOP protocol via a UGA-based proxy for firmware that do not implement the protocol.\n\nNote: This option requires ProvideConsoleGop to be enabled.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.\n\nNote 1: Automatic scale factor detection works on the basis of total pixel area and may fail on small HiDPI displays, in which case the value may be manually managed using the NVRAM section.\n\nNote 2: When switching from manually specified NVRAM variable to this preference an NVRAM reset may be needed.";
/* ProtocolOverrides */
"TT_AppleAudio" = "Type: plist boolean\nFailsafe: false\nDescription: Replaces Apple audio protocols with builtin versions.\n\nApple audio protocols allow OpenCore and the macOS bootloader to play sounds and signals for screen reading or audible error reporting. Supported protocols are beep generation and VoiceOver. The VoiceOver protocol is specific to Gibraltar machines (T2) and is not supported before macOS High Sierra (10.13). Older macOS versions use the AppleHDA protocol (which is not currently implemented) instead.\n\nOnly one set of audio protocols can be available at a time, so this setting should be enabled in order to enable audio playback in the OpenCore user interface on Mac systems implementing some of these protocols.\n\nNote: The backend audio driver needs to be configured in UEFI Audio section for these protocols to be able to stream audio.";
......@@ -1708,6 +1708,6 @@
"TT_EnableVectorAcceleration" = "Type: plist boolean\nFailsafe: false\nDescription: Enable AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore-managed NVRAM system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ResizeGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Configure GPU PCI BAR sizes.\n\nThis quirk sets GPU PCI BAR sizes as specified or chooses the largest available below the ResizeGpuBars value. The specified value follows PCI Resizable BAR spec. Use 0 for 1 MB, 1 for 2 MB, 2 for 4 MB, and so on up to 19 for 512 GB.\n\nResizable BAR technology allows to ease PCI device programming by mapping a configurable memory region, BAR, into CPU address space (e.g. VRAM to RAM) as opposed to a fixed memory region. This technology is necessary, because one cannot map the largest memory region by default, for the reasons of backwards compatibility with older hardware not supporting 64-bit BARs. Consequentially devices of the last decade use BARs up to 256 MB by default (4 remaining bits are used by other data) but generally allow resizing them to both smaller and larger powers of two (e.g. from 1 MB up to VRAM size).\n\nOperating systems targeting x86 platforms generally do not control PCI address space, letting UEFI firmware decide on the BAR addresses and sizes. This illicit practice resulted in Resizable BAR technology being unused up until 2020 despite being standardised in 2008 and becoming widely available in the hardware soon after.\n\nModern UEFI firmware allow the use of Resizable BAR technology but generally restrict the configurable options to failsafe default (OFF) and maximum available (ON). This quirk allows to fine-tune this value for testing and development purposes.\n\nConsider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeGpuBars to 16 GB will change BAR0 to 8 GB and leave BAR1 unchanged.\n\nNote 1 : This quirk shall not be used to workaround macOS limitation to address BARs over 1 GB. ResizeAppleGpuBars should be used instead.\n\nNote 2: While this quirk can increase GPU PCI BAR sizes, this will not work on most firmware as is, because the quirk does not relocate BARs in memory, and they will likely overlap. Contributions to improve this feature are welcome.";
......@@ -999,7 +999,7 @@
/* JMF-hg-GgC */
"TT_RebuildAppleMemoryMap" = "Type: plist boolean\nFailsafe: false\nDescription: Generate Memory Map compatible with macOS.\n\nThe Apple kernel has several limitations on parsing the UEFI memory map:\n• The Memory map size must not exceed 4096 bytes as the Apple kernel maps it as a single 4K page. As some types of firmware can have very large memory maps, potentially over 100 entries, the Apple kernel will crash on boot.\n• The Memory attributes table is ignored. EfiRuntimeServicesCode memory statically gets RX permissions while all other memory types get RW permissions. As some firmware drivers may write to global variables at runtime, the Apple kernel will crash at calling UEFI runtime services unless the driver .data section has a EfiRuntimeServicesData type.\n\nTo workaround these limitations, this quirk applies memory attribute table permissions to the memory map passed to the Apple kernel and optionally attempts to unify contiguous slots of similar types if the resulting memory map exceeds 4 KB.\n\nNote 1: Since several types of firmware come with incorrect memory protection tables, this quirk often comes paired with SyncRuntimePermissions.\n\nNote 2 : The need for this quirk is determined by early boot failures. This quirk replaces EnableWriteUnprotector on firmware supporting Memory Attribute Tables (MAT). This quirk is typically unnecessary when using OpenDuetPkg but may be required to boot macOS 10.6, and earlier, for reasons that are as yet unclear.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor the development purposes one may take the risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
"TT_ResizeAppleGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Reduce GPU PCI BAR sizes for compatibility with macOS.\n\nThis quirk reduces GPU PCI BAR sizes for Apple macOS up to the specified value or lower if it is unsupported. The specified value follows PCI Resizable BAR spec. While Apple macOS supports a theoretical 1 GB maximum, in practice all non-default values may not work correctly. For this reason the only supported value for this quirk is the minimal supported BAR size, i.e. 0. Use -1 to disable this quirk.\n\nFor development purposes one may take risks and try other values. Consider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeAppleGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeAppleGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeAppleGpuBars to 16 GB will make no changes.\n\nNote: See ResizeGpuBars quirk for general GPU PCI BAR size configuration and more details about the technology.";
/* l3S-mh-5k0 */
"TT_SetupVirtualMap" = "Type: plist boolean\nFailsafe: false\nDescription: Setup virtual memory at SetVirtualAddresses.\n\nSome types of firmware access memory by virtual addresses after a SetVirtualAddresses call, resulting in early boot crashes. This quirk workarounds the problem by performing early boot identity mapping of assigned virtual addresses to physical memory.\n\nNote: The need for this quirk is determined by early boot failures.";
......@@ -1640,7 +1640,7 @@
"TT_GopPassThrough" = "Type: plist string\nFailsafe: Disabled\nDescription: Provide GOP protocol instances on top of UGA protocol instances.\n\nThe supported values for the option are as follows:\n• Enabled — provide GOP for all UGA protocols.\n• Apple — provide GOP for AppleFramebufferInfo-enabled protocols.\n• Disabled — do not provide GOP.\n\nThis option provides the GOP protocol via a UGA-based proxy for firmware that do not implement the protocol.\n\nNote: This option requires ProvideConsoleGop to be enabled.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.";
"TT_UIScale" = "Type: plist integer, 8 bit\nFailsafe: -1\nDescription: User interface scaling factor.\n\nCorresponds to 4D1EDE05-38C7-4A6A-9CC6-4BCCA8B38C14:UIScale variable.\n• 1 — 1x scaling, corresponds to normal displays.\n• 2 — 2x scaling, corresponds to HiDPI displays.\n• -1 — leaves the current variable unchanged.\n• 0 — automatically chooses scaling based on the current resolution.\n\nNote 1: Automatic scale factor detection works on the basis of total pixel area and may fail on small HiDPI displays, in which case the value may be manually managed using the NVRAM section.\n\nNote 2: When switching from manually specified NVRAM variable to this preference an NVRAM reset may be needed.";
/* ProtocolOverrides */
"TT_AppleAudio" = "Type: plist boolean\nFailsafe: false\nDescription: Replaces Apple audio protocols with builtin versions.\n\nApple audio protocols allow OpenCore and the macOS bootloader to play sounds and signals for screen reading or audible error reporting. Supported protocols are beep generation and VoiceOver. The VoiceOver protocol is specific to Gibraltar machines (T2) and is not supported before macOS High Sierra (10.13). Older macOS versions use the AppleHDA protocol (which is not currently implemented) instead.\n\nOnly one set of audio protocols can be available at a time, so this setting should be enabled in order to enable audio playback in the OpenCore user interface on Mac systems implementing some of these protocols.\n\nNote: The backend audio driver needs to be configured in UEFI Audio section for these protocols to be able to stream audio.";
......@@ -1708,6 +1708,6 @@
"TT_EnableVectorAcceleration" = "Type: plist boolean\nFailsafe: false\nDescription: Enable AVX vector acceleration of SHA-512 and SHA-384 hashing algorithms.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ForceOcWriteFlash" = "Type: plist boolean\nFailsafe: false\nDescription: Enables writing to flash memory for all OpenCore-managed NVRAM system variables.\n\nNote: This value should be disabled on most types of firmware but is left configurable to account for firmware that may have issues with volatile variable storage overflows or similar. Boot issues across multiple OSes can be observed on e.g. Lenovo Thinkpad T430 and T530 without this quirk. Apple variables related to Secure Boot and hibernation are exempt from this for security reasons. Furthermore, some OpenCore variables are exempt for different reasons, such as the boot log due to an available user option, and the TSC frequency due to timing issues. When toggling this option, a NVRAM reset may be required to ensure full functionality.";
"TT_ResizeGpuBars" = "Type: plist integer\nFailsafe: -1\nDescription: Configure GPU PCI BAR sizes.\n\nThis quirk sets GPU PCI BAR sizes as specified or chooses the largest available below the ResizeGpuBars value. The specified value follows PCI Resizable BAR spec. Use 0 for 1 MB, 1 for 2 MB, 2 for 4 MB, and so on up to 19 for 512 GB.\n\nResizable BAR technology allows to ease PCI device programming by mapping a configurable memory region, BAR, into CPU address space (e.g. VRAM to RAM) as opposed to a fixed memory region. This technology is necessary, because one cannot map the largest memory region by default, for the reasons of backwards compatibility with older hardware not supporting 64-bit BARs. Consequentially devices of the last decade use BARs up to 256 MB by default (4 remaining bits are used by other data) but generally allow resizing them to both smaller and larger powers of two (e.g. from 1 MB up to VRAM size).\n\nOperating systems targeting x86 platforms generally do not control PCI address space, letting UEFI firmware decide on the BAR addresses and sizes. This illicit practice resulted in Resizable BAR technology being unused up until 2020 despite being standardised in 2008 and becoming widely available in the hardware soon after.\n\nModern UEFI firmware allow the use of Resizable BAR technology but generally restrict the configurable options to failsafe default (OFF) and maximum available (ON). This quirk allows to fine-tune this value for testing and development purposes.\n\nConsider a GPU with 2 BARs:\n• BAR0 supports sizes from 256 MB to 8 GB. Its value is 4 GB.\n• BAR1 supports sizes from 2 MB to 256 MB. Its value is 256 MB.\n\nExample 1: Setting ResizeGpuBars to 1 GB will change BAR0 to 1 GB and leave BAR1 unchanged.\nExample 2: Setting ResizeGpuBars to 1 MB will change BAR0 to 256 MB and BAR0 to 2 MB.\nExample 3: Setting ResizeGpuBars to 16 GB will change BAR0 to 8 GB and leave BAR1 unchanged.\n\nNote 1 : This quirk shall not be used to workaround macOS limitation to address BARs over 1 GB. ResizeAppleGpuBars should be used instead.\n\nNote 2: While this quirk can increase GPU PCI BAR sizes, this will not work on most firmware as is, because the quirk does not relocate BARs in memory, and they will likely overlap. Contributions to improve this feature are welcome.";
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册