Today I dumped the bios of a Gigabyte GA-Z87X-UD5H using FPTW64 and also took a backup using QFlash utility. As I was in the process of updating my microcodes I looked inside and noticed that my FIT table was messed up, and not only that I now have an extra firmware volume that wasn’t there in the original bios. So I wonder where did the extra firmware volume come from?? It wasn’t in the original vanilla factory release!
In anycase this rom is special in that I have modded it many times for my Ozmosis hackintosh and have a log of like 10 roms I had in the past. Most recent one on file is from 2016 so I want a fresh copy. Going to just mod the microcode on the most recent dump backup file but which one should I use… The FPTW64 version or the QFlash version as there are minor differences between them as well according to a file comparison in HxD edit…
Kind of weird:
EDIT by Fernando: Inserted too big pictures resized and reinserted by using the Forum software (can be enlarged by clicking onto them)
I’m telling this story for more than 50 times already, but just in case someone finds it here: THIS IS NORMAL, that padding space in original image is specifically designed for this new backup NVRAM volume to be created by AMI NVRAM driver. It will be used as backup storage in case main one is corrupter or requires garbage collection, and it can also be used for various other things. This is how it worked since the very early days of Aptio4 back in 2013, and it still works this way in AptioV.
Maybe not the conversion of padding space into NVRAM backup was meant.
Maybe the increase of "EfiFirmwareFileSystem2…" from 4 counts in flashfile to 5 counts in backup (and the change of the offsets).
CodeRush Thanks for your input and shedding light on this. That is was what I thought but wasn’t sure. In anycase I ended up relocating the microcode volume to the top of the firmware volume as this way Ubu will not affect the FIT table as AE717C2F… GUID housed all the Dxe modules and Ubu inadvertently would mess that up. I also noticed that Uefitool 0.22.3 corrected the COREPEI PE start offset at the bottom of the rom automatically so no need to manually make corrections to PeiCore start address. I ended up flashing the altered backup copy I got from QFlash as opposed to Fptw64. Dont think it mattered which one was best despite the slight differences. Thanks.
I don’t remember the actual requirement now, but I’d put microcodes and other stuff that is supposed to be loaded from FIT (including FIT itself) into last 2 megabytes of BIOS image, because sometimes this is the only chunk of BIOS region accessible early in SEC phase. If moving uCodes up worked for you, it means they are loaded by BIOS later in boot process (in PEI-before-mem, I expect), but some systems with ME-based microcode loading will stop working if you move them too far up.
One other thing: if you want to compare 2 similar BIOS binaries, UEFITool is not the right thing to use. UEFIExtract has a report generation capability, and comparing those reports using text compare tools like WinDiff trumps everything else. Just generate 2 reports using ""UEFIExtract filename report" command for both file and compare (or upload of other to compare) the generated text files.
Yes it worked and considering that the FIT was broken for last few years I am surprised it worked till now. Anyhow thanks for the info regarding the last two megabytes. Was surprised at where it was located being one copy right after the compressed DXE volume and another exact mirror copy few modules in front of CorePEI!
Gigabyte’s original bios however referenced the first dxe volume and not the second pei one. As far as Gigabyte boards go I think it was either you or Pluto that said not to alter the order of the microcodes. Anyhow its working great now.
Will check out your other tool for a report!
Thanks.