Indeed, 5.2.0.24 overwrites _FIT_.
It is not critical, since microcodes are still read without using _FIT_. But still not good. :(

Add:

Version 5.2 really corrects _FIT_ and by the way is very correct.
Unfortunately, the problem occurs if you restore the "Empty" file.

What exactly is the "Empty" file anyway? UBU just removes it, then updates the codes, then restores it all by itself.

I think unpatched 5.2.0.24 also mangles FIT, I had to downgrade to 5.0.0.7 to get a flashable image.

At the moment there are 2 thoughts or throw everything or delete this "Empty" module...

Add:
Test on ASUS Rampage V

@Sonix

I have tested UBU v1.69.13 for ASUS P8Z77-V Deluxe BIOS v2104 (Aptio 4) using the two MMTool variants:

Test 1) with MMTool v5.0.0.7 (time stamp 14th march 2014) => perfect it is OK
Test 2) with MMTool v5.2.0.24 (time stamp 31th january 2018) => problems:


Moreover I observe the BIOS file has been erased from the UBU folder when test 2 did fail.
Nota: the input BIOS file used for test 2 was the output bios file from the test 1.

@Sonix

I have tested UBU v1.69.13 for ASUS Sabertooth X99 BIOS v3801 (Aptio 5) using the two MMTool variants:

TestX99 1) with MMTool v5.0.0.7 (14march2014) => perfect all is OK

TestX99 2) with MMTool v5.2.0.24 (31jan2018) get from the recommended link on the startpost => 2 problems:
problem 1) security application does warm about GenFds.exe executable file : Missing Numerical Signature
problem 2) Keyboard strange problems such as Numerical pad entries are wrong (when select touch 3 produce a 5, etc..) and enter touch command becomes ignored and we have to come back with the mouse to the screen menu to change from ungreyed to black and becomes 'active' again to accept the users command)

I do not see any more sense in testing version 5.2.0.24.
Verdict - This version is not desirable to use for updating microcodes.

What about OROM modules, can 5.2.0.24 update them in UBU?

I successfully used v5.2.0.24 for updating EFI GOP SKL-KBL driver and EFI Realtek UNDI

With mmtool 5.2 I successfully updated any module on my ASRock Z170 Extreme4 BIOS file. I used the original file, without patching it. With 5.0.0.7 I always got "file size exceeded". I can't give feedback for Aptio 4.

The update of the EFI and OROM by 5.2 works well, but the update of the microcodes unfortunately pits the _FIT_.

Good evening,
first of all I'd like to thank you SoniX for your work.
As Morku with the latest UBU version and mmtool 5.2 I have been able too update the modules of my Z170 Extreme 4 (I used as base the lastest beta bios).
Did I get it right? The lastest mmtool version works well with the module update but not with microcodes?
Could be the solution to use the old 5.0 version for microcodes and then change the file to update the modules?
I have a question about Intel RST(e) OROM and EFI SataDriver, as I was saying I have been able to update the EFI IRST RAID for SATA from 14.6.0.2285 to 15.7.0.3054 but the OROM IRST RAID for SATA isn't updated to v15.7 is this working as intended or have I done something wrong?

Thank you.

SoniX posted new 1.69.14 and "1.69_Crutch" (with MMTool 5.02).......

Zitat von Fernando im Beitrag #3568

---

If this could be implemented into the UBU toolkit, it would be great!

---

Zitat von Fernando im Beitrag #3568

---

The MMTool v5.2 will be able to correctly update the Option ROM modules of AMI Aptio V BIOSes, but this feature has not yet been implemented by SoniX into the UBU tool script.
So your BIOS modding result was as intended by the current UBU version and you haven't done any mistake.

---