Hi there again 
.
First, great job on keep supporting and maintaining this project. It has helped many people to gain free performance thanks to your effort! And also for everyone else who has finding fixes. Many thanks!..
Since the last added patch for X79 systems I decided to redo the BIOS with ReBAR for my P9X79-Pro, and I ran again into the padding corruption problem.
Upon patching Runtime module, padding would get corrupted and no workaround helps.
Recently, @ZOX found a solution for those who get a padding corruption from patching IvtQpiandMrcInit. Sadly, just following his solution isn’t enough so I tried to investigate a little more and these are my foundings:
-
Patching PciBus and IvtQpiandMrcInit (together / separately) without patching Runtime does not corrupt the paddings
-
Patching Runtime (alone / altogether / separately) corrupts padding and no workaround helps (extracting patched Runtime module using UEFITool and replacing it in the unpatched BIOS using MMTool4.50 or UEFITool)
-
Runtime patch deletes the first Pad-file, replacing it with FFs. To find the differences between BIOS with the patched Runtime module and the unpatched one, I patched only the Runtime module and compared it using Guiffy (since it is a free option that finds changed in the file and does not simply compare each offset like HxD) trying to mimic @ZOX’s solution.
Apart from the changes of the Runtime patch itself, you can see it deletes the Pad-file too and replacing it with FFs as mentioned.
What’s unclear to me is why MMTool4.50 or UEFITool deletes the Pad-file when solely replacing the Runtime module, as the Pad-file is outside the Runtime module and a lot of offsets below! Beats me… -
Replacing unpatched BIOS Runtime module in UEFITool and selecting “Do not rebuild” on the first Pad-file below BootPriority module results in two Pad-files one after another.
Trying to delete either the first or the second Pad-files below BootPriority module would result in padding corruption as shown in the picture in option 2. -
With HxD I searched all Pad-files existing on the unpatched BIOS and compared it with the BIOS from option 4, trying to locate which Pad-file was incorrectly added.
Normally it would return 4 hits (and on the Runtime patched BIOS which also corrupts padding, it would return 3 hits). Deleting one of the two Pad-files to achieve same Pad-files offset location as the unpatched BIOS. Finally, starting to see some results
, but we still have errors to fix.
-
Adding same amount of FFs characters as the Pad-file to the end of volume 3 (the volume with ReBarDxe.ffs) would fix the last two errors.
-
I thought to try patching again after I fixed the Pad-file issue, maybe it would fix the unaligned Raw files (as I previously isolated the PciBus and IvtQpiandMrcInit patches for easier troubleshooting, since Runtime patch is the problematic one).
Patching Runtime alone doesn’t find anything to patch (good, it means Runtime really is patched), so no output BIOS file.
Here where it gets interesting.
Patching IvtQpiandMrcInit alone returns as we would expect (with IvtQpiandMrcInit patched), sadly it did not fix the unaligned Raw file issue.
Patching PciBus alone seems “fix” the unaligned Raw file issue by corrupting again the Pad-files (meaning, deleting the Pad-file and replacing it with FF at the end of volume 3 respectively). What seems to happen here is because PciBus is in volume 3 same as Runtime it rebuilds it, hence gets corrupted again (same would happen if I just would press rebuild in UEFITool).
Simply patching the BIOS with all the patches at once and then add the deleted Pad-file before the Raw (offset 2CB388) and the remove FF characters respectively from the end of volume 3 (where ReBarDxe.ffs is located), and we get again the unaligned Raw file issue, but the Pad-files are now fixed.
If anyone here similar with this error and knows how to approach this I would appreciate your help very much!
Thanks for reading, every if you don’t have a solution to offer.