Asus Z87 Gryphon - Is this pad file a problem? (UEFIPatch and MMTool create the same pad file).

[chiefwhosm]

Hi,
I'm trying to add rebar to my Asus Z87 Gryphon motherboard bios (latest available version). I successfully got to the stage of patching it, but I had 1 pad error when comparing the patched and original (with rebar module added) files. As a precaution I also compared the original bios against the rebar module added bios just to confirm the pad file wasn't added there and neither have any pad differences.

I used UEFI Tool to extract the four modules (pcibus, pcihostbridge and two NBPEI) and added them back into the unpatched (with rebar module) bios using MMTool v4.

I tested the MMTool saved file using UEFIPatch, it said there were no patches to apply.

I then compared the unpatched (with rebar module) file against the newly saved MMTool file and I still have the same pad error.

I also found someone suggesting using UEFITool 0.28.0 to do the patching by using remove on the old module and insert after (the module above the removed one) but this still led to the 1 pad error.

Is this pad error something that needs fixing, as I can't think of how else to fix it (and naturally I don't want to risk flashing it with Bios Flashback until I'm sure it's okay to use).

This is an image showing the 1 pad error:

I did find someone saying they fixed their pad file issues by editing the UI text in the patches.txt file (I presume the # lines?) to make the module size smaller. Is this something that needs doing to stop the pad file occuring?

Thanks for any help you can give.

[Koekieezz]

@chiefwhosm before all of that, do you aware if your bios have Above 4G decoding or not? It is possible that rebar can be done with linux without the mod at all (while DSDT patch might be necessary). While on windows, you need it.

As for the padding issue, you need to examine which module that causes it. My usual method is to take notes which dxe drivers was patched, usually PciBus, PciHostBridge, NvramSmi/NvramSmiDxe, and maybe Runtime. Now, extract those patched modules using uefitool ne a73, and then open up the stock bios with Uefitool 0.25.0, do not use later versions as it have a "bug" for asus board.

Now, replace them one by one, by this, i mean replace the patched module one at a time and save the bios file, to see which patch causes it. For example, when i replace PciBus, it causes the Pad file issue. The way to solve this is by Deleting the PciBus on stock bios, and then Insert After the patched PciBus Module AFTER the area that causes pad issue, in your case, there is a GUID above "PEFirmwareUpdate" GUID, so you only need to Insert After that GUID above "PEFirmwareUpdate", and do not Insert Before GUID PEFirmware Update, as it will shift it upwards, instead downwards, when you examine it with Hex tools like HxD. I have done that and it causes to brick.

If you do need the Above 4G Decoding, crossflashing the Z97 Gryphon might be possible, since this board doesn't have TPU Chip, it might be possible.

[chiefwhosm]

Thanks for the reply.

Yes, my mobo supports Above 4G decoding and it is enabled (I disabled/re-enabled it to make sure), however even editing grub (pci=realloc), rebar wouldn't enable under Linux (also I dual boot so ideally would want it working under Windows as well).

I didn't try DSDT patching, as Curi0's instructions say they're only applicable to:
Sandy/Ivy Bridge motherboards which have applied UEFIPatch.
ASRock Haswell/Broadwell/Skylake/Kabylake (excluding HEDT (X99/LGA2011-3 and X299/LGA2066)).
X79/LGA2011-0 systems which have applied UEFIPatch Extend MMIOH limit to fix Above 4G Decoding.
Systems without 4G decoding even in hidden settings.

I can confirm the module that was causing the problem was the PciHostBridge, and this is how the bios now looks, and I just wanted to ask if this is what you meant in terms of removing/inserting the module after the GUID above the PEFirmwareUpdate?

Thanks.

[Koekieezz]

@chiefwhosm , you can try to Bios Flashback this: Z87Gryphon_Complete.zip

It has no padding issues:

What i meant is insert after the GUID 2FAB50B8-AE15-4219-BAA0-E8CA23E57A1E, so the Patched modules that causes it will sit between 2FAB50B8-AE15-4219-BAA0-E8CA23E57A1E and PEFirmwareUpdate:

It has all the needed UEFI Patches, also i DSDT Edit it since i saw that the range for above 4g were none existent (and i include the .dsl of the modded one for your ease to implement in the linux kernel :) ), and i additionally added NVMe booting suppport and updated the bios modules:
Intel ME Firmware 9.0.30.1482 -> 9.0.31.1487
1 - Disk Controller
EFI Intel RST RAID Driver - 12.7.0.1936 -> 13.5.0.2164
OROM Intel RST for SATA - 12.7.0.1936 -> 13.5.0.2164
2 - Video OnBoard
EFI GOP Driver Haswell - 5.0.1036 -> 5.5.1034
RAW GOP VBT HASWELL - 177 -> 189
OROM VBIOS Haswell - 2179 -> OROM VBIOS HSW-BDW 1044
3 - Network
EFI Intel PRO1000 Driver - 5.4.19 -> 6.6.04
OROM Intel Boot Agent GE - 1.5.43 -> 1.5.62
EFI Realtek UNDI Driver - 2.020 -> 2.075

Microcodes - All Latest.

And if it worked, could you please also test iGPU usage, see if its booting normally in CSM Enabled and CSM Disabled?

[chiefwhosm]

Thanks for the reply, you confirmed that my BIOS looks okay so I tried it first, here are the results of using both my custom bios and yours:

My Bios:
Flashes correctly,.
PC Works as intended.
Enabling Rebar State, values above 10 prevents POST until CMOS reset.

Your Bios:
Flashes correctly.
PC won't POST (RAM and CPU error lights blink, one after the other).
Took out GPU and tried with iGPU, same problem.

I've now flashed my custom bios back on, and thankfully the computer functions again.

I tried a rebar value of 8 and the computer worked and I then slowly went up the values until the computer wouldn't POST anymore, so now I've found the maximum rebar value is 10 / 1024MB enabled.

Though under Windows (not tried booting Linux yet) the gpu drivers say rebar is still disabled.

Does this imply 4G Decoding isn't working?

I followed the instructions for enabling hidden 4G, the offset var for my board appears to be 0x327, and it is enabled, but in the Common issues (and fixes) section it does say that if 4G Decoding isn't working, then bar size won't work above 1024.

I have now made my own DSDT patch, and when applied it creates the same pad file as above, and results if flashed to the motherboard with the same cpu/ram lights issue from your own custom bios.

I also tried using "Replace as is" to see what difference that made, this did stop pad issues, but the result was the same cpu/ram lights issue once flashed.

I've since learnt this means the motherboard is no longer able to determine the ram timings and gets stuck in a loop.

Again, re-flashing the non-dsdt, rebar module version of the bios rom got me a working computer again so at least nothing bricked.

I also tried removing the lines from the dsl file it said it was safe to do, and slowly but surely decreased the size of the .efi until it was identical to the size of the original (60.7 kb 62,176, it still made pad files though and the ffs file was still slightly bigger than the un-modified version.
Original AmiBoardInfo.ffs size: 22.5kb (23,091)
DSDT Patch AmiBoardInfo.ffs size: 22.6kb (23,104)