Skip to content

Using UEFIPatch

Jump to bottom
Curi0 edited this page Dec 7, 2025 · 72 revisions

Many consumer motherboards have issues handling 64-bit BARs which are required for Resizable BAR to work at its full size. Here you can find out how to use UEFIPatch (part of UEFITool) to patch UEFI to make it compatible with 64-bit BARs and solve various issues.

Working patches

  • <4GB BAR size limit removal
  • <16GB BAR size limit removal
  • <64GB BAR size limit removal
  • Prevent 64-bit BARs from being downgraded to 32-bit
  • Increase MMIO space from 16-32GB to full usage of 512GB/39-bit range (Skylake/Kaby Lake/Coffee Lake)
  • Increase MMIO space from 8-16GB to full usage of 512GB/39-bit range (Haswell/Broadwell). The issue of older patches being limited to 64GB has been fixed.
  • Increase MMIO space from 16GB to full usage of 64GB/36-bit range (Sandy/Ivy Bridge). Requires DSDT modification on certain motherboards. See wiki page DSDT Patching for more information.
  • Remove NVRAM whitelist to solve ReBarState GetLastError: 5
  • Fix USB 3 ports not working in BIOS with 4G Decoding enabled (Ivy Bridge/Haswell/Broadwell)
  • X79 Above 4G Decoding fix

Using UEFIPatch

  1. Download UEFIPatch from here. As of writing this the latest version is 0.28.0 released in March 2020.
  2. Download patches.txt and place it into a folder along with UEFIPatch and your BIOS file. It should look something like this image

You don't have to comment out patches in patches.txt that are for other platforms

X79 systems will need to uncomment (remove # on second line with hex codes) the patch Extend MMIOH limit to fix Above 4G Decoding (X79), it's commented because of its possible incompatibility with multi CPU systems. Do not use this patch if your X79 already has working 4G decoding such as on a few AliExpress boards.

Append the following additional patches you need to patches.txt

  • Haswell / Broadwell aka Intel 8 or 9 Series Chipset (H81/B85/Q85/Q87/H87/Z87/C222/C224/C226/H97/Z97) patch for 4G decoding/resizable BAR to function correctly HswAbove4G.txt. This patch is required for 4G decoding/resizable BAR to function correctly on these systems.

  • Intel 7 Series Chipset (B75/Z75/H77/Z77/Q75/Q77/C216) patch for functioning USB 3 ports in BIOS with 4G Decoding enabled IvyUSB3.txt

  • Intel 8 Series Chipset (H81/B85/Q85/Q87/H87/Z87/C222/C224/C226) patch for functioning USB 3 ports in BIOS with 4G Decoding enabled HswUSB3.txt

  • Intel 9 Series Chipset (H97/Z97) patch for functioning USB 3 ports in BIOS with 4G Decoding enabled BdwUSB3.txt

  1. Run UEFIPatch on the BIOS file in command prompt/Powershell/terminal. It should look something like below the patches will differ depending on your BIOS image

If you get No patches can be applied to input file you can skip this and continue to DSDT Patching using the unpatched BIOS file. Make sure to check there is no pad file issue caused by adding the module before flashing it.

Any errors reported by UEFIPatch are safe to ignore.

  1. You'll get a new file created with .patched as the extension. This file will be used for the next steps if there isn't pad file issue.

Checking for pad file issue

UEFITool/UEFIPatch have a bug which results in pad file corruption that affects mostly ASUS motherboards. Pad file corruption will cause boot failure which can only be fixed by flashing a proper BIOS. You can check for this issue by comparing pad files of the modified volume in UEFITool.

Good (both pad files being same, if you can't find pad file in both DXE volumes it's also ok)

image

Bad (pad file gets changed)

image

Pad file issue workaround

Until bug #231 is fixed in UEFITool/UEFIPatch this will be required. Usually motherboards from before Skylake use MMTool 4.50.0.23 while motherboards after use 5.02.0025. If you get Error in Saving or The input image is not Aptio V it's because you're using the wrong MMTool version.

See MMTool method from Adding FFS module for more information on how to find MMTool.

  1. Open the .patched BIOS in UEFITool and Extract as is the .ffs files of the modules that were patched. You can find these by looking at the patches.txt file and seeing which ones were patched. In this case it is PciBus and PciHostBridge.

    image

  2. Open your unpatched BIOS in MMTool (click Load Image). Select the module you want to replace and click the Replace tab. Click Browse and select the patched .ffs file. Sometimes only the GUID will be visible so check it if FileName is blank.

    image

  3. Click Replace. Repeat this for the other patched .ffs module(s) and be careful not be mix them up.

  4. Click Save Image As to save the modified BIOS. This file will be used for the next steps.

You can verify if the patches are applied by running UEFIPatch for all the patches you applied on the saved file, it should say No patches can be applied to input file. In some rare cases like the Haswell/Broadwell NBPEI patch it may apply to a section that was invisible to MMTool (used as a backup?), in this case you should use the patched file it outputs if you can confirm it has no pad file issue.

Verify that the pad files are proper before continuing.

When replacing a TE Image (used only for the X79 4G decoding fix) you may find that even MMTool still causes pad file issue, in that case you will need to manually do the patch using a hex editor. @ZOXZX explained it in the comment here. Also if you have any issues applying the Runtime patch it's completely optional (used for EFI applications accessing PCIe BAR like OpenCore boot audio) and you can skip it.

Continue to DSDT Patching

Thanks @romulus2k4 for discovering this workaround for the pad file issues.

Creating UEFI patches (for advanced users only, requires some x86 assembly knowledge)

 image (infographic uses the C code generated by Ghidra because x86 assembly is confusing)

The MMIOPrint tool can be useful to view the UEFI memory map and check if there's any issues with it that require patching.

This image should explain how the AddMemorySpace function works, you can usually locate it by looking for CALL qword ptr [RAX + 0x18], the DXE services table / gDS corresponds to RAX. On most platforms you'll need to search for this in the PciHostBridge module. HEDT/server platforms might use PciRootBridge instead.

https://github.com/tianocore/edk2/blob/a074649c6096d6dd36d03db5a55316d129e776b5/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c#L95 the source of the DXE Services table shows the header is 0x18 long so the first function AddMemorySpace will be located at 0x18 and the others at 8 byte offsets. You can also see in the image that SetMemorySpaceAttributes at offset 0x40 gets called later.

uRam00000000e00000a8 corresponds to the TOUUD register on Intel which you can confirm reading their datasheets.

All patches were created using Ghidra with efiSeek plugin.

Clone this wiki locally