Guide to Patching the Supermicro Super X10/X11 Series

[OdinVex]

Guide to Patching the Supermicro Super X10/X11 Series

Supermicro Super X11-Series Notes

Note the Supermicro Super X11 series should be rather similar to patch, if not the same, but this guide was built on the Supermicro Super X10 series.

---

Introduction

It's unfortunate the Supermicro Super X10DRU-i+ motherboard doesn't natively support ReBar, but you can use ReBarUEFI to work around this issue. The normal ReBarUEFI guide(s) may work for other motherboards, but it shouldn't be used for this motherboard and possibly other Supermicro motherboards around the X10 series and newer. There are a few reasons, but the strongest reason is because the tools used in the ReBarUEFI guide strip a lot of data from the BIOS and change the layout dramatically. It isn't necessary. This short guide should help you to patch a BIOS safely.

---

Backup your BIOS

You should back up your BIOS, the actual chip itself. The BIOS contains some unique data, such as motherboard MAC addresses and other FRU, some very necessary for everything to work! When updating your BIOS, some data remains unchanged. This is because the BIOS contains unique information that's crucial for full device functionality. Without this unique data, your network cards may permanently brick unless you can figure out where to write that MAC address in the BIOS to unbrick it. In short, backing up your BIOS is highly recommended when modifying any BIOS so it can be restored should any modifications fail.

To back up your BIOS, use an SPI (serial peripheral interface) reader. As of 2025/5/22, I've only seen these motherboards use a Winbond W25Q128FV 16MB flash chip. Your SPI reader must use 3.3V only, anything else will most likely destroy your BIOS chip. The pinout for the BIOS is typical of SPI chips in SOIC packages: #1 is CS, #2 is DO, #3 is WP, #4 is GND, #5 is DI, #6 is CLK, #7 is HOLD, #8 is VCC. If your reader needs an ID for the chip (to verify communication), see the manufacturer's datasheet or try EF 40 18.

Actual backup processes are beyond the scope of this guide!

---

Obtaining ReBarUEFI and Blocklisting Unsupported Devices

Having backed up your BIOS, you now need to determine whether you may need to blocklist devices or not. If you don't need to blocklist any then grab a copy of the latest ReBarDxe.ffs file from the releases. You can't currently blocklist a device with the normal version of ReBarUEFI.

As of 2025/5/22, the standard ReBarUEFI release can cause issues with devices that don't support ReBar. Specifically, it can break the PCI Config Space for subsequent devices. If you have any devices that don't support ReBar then you will need to blocklist the device ID of them. Be aware this applies to all devices that have that device ID. I'd also appreciate you reporting the device ID (such as 10de:1bb1, an Nvidia Quadro P4000 or 10de:1bb0, an Nvidia Quadro P5000, both belong to the Pascal architecture) to ReBarUEFI, so everyone can check the blocklist and block them if they need to.

To blocklist a device ID, you need to modify ./ReBarDxe/ReBar.c, specifically you need to patch pciRebarGetPossibleSizes by adding a block for each device you wish to skip adjusting the bar size for. Insert a block before return cap >> 4; such as:

if (vid == 0x10d0 && did == 0x1bb1) {  // Nvidia Quadro P4000 does not support ReBar
    return 0;
}

Take note of the device ID and vendor ID. After patching and compiling ReBarUEFI, you'll be ready to continue.

Compiling ReBarUEFI is beyond the scope of this guide!

---

Obtain a Flashable BIOS

Obtain a copy of your motherboard BIOS from the manufacturer. If you can't obtain one, then you may be able to try using another copy of your BIOS backup. It may fail.

Be aware some BIOS files are considered proprietary and shouldn't be shared for legal reasons.

---

Patching the BIOS, Assisted or Manual

Decide with which method you wish to patch the BIOS. The assisted method is recommended, but it depends upon your ability to obtain a copy of AMI MMTools v5.0 (sometimes called Aptio Tool(s) v5.0). Good luck; supposedly they're restricted-access tools, so you might have difficulty obtaining them. If you can't find those tools, then you need to proceed manually. Do not use the tools from the normal ReBarUEFI guide(s), as they strip information and sometimes output a broken BIOS.

Assisted Method

As of 2025/5/22, the AMI MMTools utility binary used for this guide has an MD5 checksum of 81c8bbdd9887aadb585bc547149c01c9. Run the AMI MMTools utility and load the image. Then search the list of entries until you find one with a GUID matching 3C1DE39F-D207-408A-AACC-731CFB7F1DD7. Check the Volume column to determine which volume it resides in, and find the last entry in the list with that Volume number and click on it. Then click Browse and find your ReBarDxe.ffs (from the Downloads section or one you compiled), make sure the Insert FFS Options groupbox radio button Insert As Is is selected, and finally click Insert. If your BIOS doesn't have support for NVMe-booting and you want to add it, you can repeat these instructions and insert other DXE files, such as with the NvmeExpress project DXE. Save the image file.

Manual Method ( Not Complete Yet )

The manual method not recommended for most people, as the process becomes more tedious. Most people don't understand the difference between insertion and overwriting when referring to hex editors, making this more error-prone. You can use a tool from the ReBarUEFI guide(s) to view information about the BIOS to determine where you should begin overwriting the BIOS file with the contents of ReBarDxe.ffs. ...TODO: Add normal-guide tool info for finding patch offset... Take note of the BIOS file size. Once you've determined the correct offset, copy the bytes from the ReBarDxe.ffs and overwrite the blank-space represented by FF, or rarely 00 and save it. Check the file size; if it's not the same, then try again. Now that your BIOS patching is nearly finished, there is one last byte to patch to indicate the DXE module's loading status. In the hex editor, find the beginning of where you inserted the ReBarDxe.ffs by searching for the byte-sequence 77 17 EE A8 F5 A4 45 43 9D A4 13 74 20 84 D3 1E. This is the GUID for ReBarDxe.ffs and it's part of the header of the file contents for it. Notice the offset, add 0x18 to it, and select that offset. The byte located at that offset is usually 0x07. Change the byte to 0xF8. Normally, this is done when patching it via the assisted method. Save the image file.

---

Flash the BIOS

Flash the BIOS (preferably via IPMI-BMC!) and be patient. If you failed to properly create the BIOS, then the system will turn on and then make a fuss on-screen and turn off. Retry from the beginning. After flashing the BIOS correctly, the system may or may not reboot multiple times before finally taking the flash (it may go part way through the BIOS boot sequence at different points and reboot; don't panic). If the BIOS version you're flashing is the same version you had begun with, then you don't need to reset the BIOS for these motherboards. Otherwise, reset your BIOS and make your changes all over again. Make sure Above-4G-Decoding is enabled, CSM is disabled, and so forth, then boot your preferred operating system and set the ReBarState as per the ReBarUEFI guide(s), then check your devices to see how they responded.

[OdinVex]

I'll find time to edit the guide to provide details for users desiring the manual method if they're unable to obtain the tools for the assisted method.

[OdinVex]

Originally, my reasons for manually patching the BIOS were to ensure no data was stripped by the tool(s) mentioned in the normal ReBarUEFI guide(s). Some of it was critical to keep, and I felt the drastic change in the output BIOS from the tool(s) just felt too radical a change besides what I'd expect from a simple insertion of a module. After having done that, I found my (PNY) Nvidia Quadro P4000 not only did not support ReBar, ReBarUEFI was unintentionally breaking the PCI Config Space for the device(s) after it, such as my (Sparkle) Intel Arc A310 Eco (Low-Profile). After blocklisting the Nvidia card, the Intel card finally got a resized bar it could use, the maximum 4GB, and performance was significantly better.

I figured I would document the process for others, so they'll know what to expect and how I did it for these motherboards.

[xCuri0]

Seems like it's a weird issue with the Quadro PCIe device advertising Resizable BAR capability even when it doesn't support it and causing issues when it's attempted to be enabled.

Maybe Linux kernel has a list of devices with resizable bar quirks like this, when I created this module in 2022 the 5600XT 1GB -> 8GB fix was the only one.

[OdinVex]

Seems like it's a weird issue with the Quadro PCIe device advertising Resizable BAR capability even when it doesn't support it and causing issues when it's attempted to be enabled.

Maybe Linux kernel has a list of devices with resizable bar quirks like this, when I created this module in 2022 the 5600XT 1GB -> 8GB fix was the only one.

The Nvidia Pascal architecture doesn't support ReBar at all and Nvidia has mentioned they won't ever change that. The Nvidia broke the Intel for Windows Server, too. It's not just Linux that needs a correctly configured PCI Config Space. I needed both devices running as best they could so I determined to simply blocklist the Nvidia and all was well afterward.

In my offline fork I've blocklisted the entire Pascal architecture and made it easy enough to extend, though I may rewrite the logic of that to blocklist more predictably. I've been building a list of every AMD, ATI, and Nvidia card that doesn't support ReBar (never) and I'm going to try to determine the feasibility of including a master blocklist of them. Another fork I've been working on is a redesign of the entire blocklist/allowlist. In this fork, I've redesigned ReBarState to be a list of allowed IDs and what size they individually want. It seems better this way. The size of the module has not increased, either. I specifically enforce the size restriction on the module to maintain compatibility. I'm still not sure if it'd be wanted and I've only been able to test it out with my limited number of GPUs, so I'd only post-back when I've been able to test much more.

[OdinVex]

In short, part of the Nvidia Turing architecture and everything older than it does not support ReBar (and never will). As for AMD, I've not bothered to learn yet of where their ReBar support begins, the same with Intel.

Edit: Since the Nvidia device IDs are somewhat predictable and knowing the device ID upper byte is which architecture, it was rather easy to build an entire blocklist of Nvidia cards. In short, if it's older than Turing, blocklist it, if it's a certain Turing, blocklist it.