@100PIER - You’re welcome! And sorry, I didn’t notice 2013 was older BIOS this entire time I thought it was latest. All I mentioned about 2013 makes sense now
I used your ucode update BIOS as the source of microcodes, extracted via MC Extractor and then I rebuild the microcode body myself in hex. So yes, all the same as you put, and all the latest, sorry I didn’t include MC Extractor image previously after the mod/update, see below
UEFIReplace 25.0 is here - https://github.com/LongSoft/UEFITool/releases/tag/0.25.0 And all versions are here - https://github.com/LongSoft/UEFITool/releases I don’t use UBU often, but I have done this replace UEFIReplace method in the past when current versions were causing this exact same issue and UEFITool 25 worked when 26 didn’t. Replacing UEFIReplace from V25 worked as expected just like UEFITool 25. As for the current UBU issue and MMTool/UEFIReplace question and issue you are having now, yes, that would need to change before you could make it use the swapped out UEFIReplace 25
As for current versions UBU and UEFIReplace inside standard package, I cannot comment on how it would treat this BIOS, I’ve not tested that but assume like UEFITool 26 it will break the BIOS at the two instances I pointed out and showed images of at post #78
@Lost_N_BIOS Thanks a lot, it is very clear and the modded BIOS Region you offered me is exactly up to date and as expected. Thanks for the 2 links. UEFIReplace v25.0 for Windows is dated on 02 june 2018, current UEFIReplace in UBU 1.73.0 folder is dated on 07 january 2019. Yes, I let Sonix to fix the current UBU issue about the MMTool/UEFIReplace question before to use the swapped out UEFIReplace 25.
You’re welcome @100PIER - and yes, I know version 25 is older, this is the one that works in your BIOS instance, some can use current/latest versions, others for certain things you need to use older version.
You can use the BIOS I made you while you wait (and or use it and be done messing around), if you want, or yes wait on SoniX to let you know what to do about UBU 1.73 version. You could also use 1.71 version too maybe, if it doesn’t give you the MMTool/UEFIReplace issues, but replace UEFIReplace if you do use that version too in case it doesn’t use MMTool.
Hi SonicX. Decided to try out the new version of your tool after not using it in quite a while. I’m experiencing the following error when updating a few components of an Asrock z77 pro4 2.00 beta bios. It does this for both the microde and rst, maybe others if I recall.
“praseFile: invalid data checksum 5ah, should be AAh”.
#Do not remove this file. #This file is for updating microcodes for MSI x299. # #To avoid a possible error - “Error in Saving”, # set ‘#’ at the beginning of the line that you turn off. #
CPUID Properties CPUID Manufacturer GenuineIntel CPUID CPU Name Intel(R) Core™ i9-7900X CPU @ 3.30GHz CPUID Revision 00050654h IA Brand ID 00h (Unknown) Platform ID 53h / MC 04h (LGA2066) Microcode Update Revision 5Dh
Glad I did not have to go down the DXE Volume Route as heard it has some oddities
Is this renaming of MMTool new? Using v1_73_2. I tried to edit an Aptio V bios file for a Z270M MSI Mortar and copied mmtool v5.2.0.24 as mmtool_a5.exe but Ubu complained that for Aptio IV bios files it needs the mmtool_a4.exe file. I assume it will know which one to use because with just the a4 version it modded the microcodes without issue. Sorry for confusing…
Thank you
EDIT: Did some reading and caught up. Understand now and sent my thanks to all who have made valuable comments. Thank you.
Thank you for your question. I’m also confusing now. Because My motherboard is Z97 ,I operated according to the instructions in this thread:[Tool Guide+News] “UEFI BIOS Updater” (UBU) Was I wrong before?
@davidm71 - no matter what answer you get, and how you end up doing things, do not flash stock BIOS via FPT, unless you edit in your NVRAM volumes, and board specific details (serial, UUID, LAN MAC etc) or all will be lost. I believe what you’re referring to is a discussion SoniX and I were having, he mentioned sometimes it may be an issue to use FPT dump, due to FIT corrections, but I’ve never seen that myself so I say it’s OK to use BIOS region dump with UBU But that may not apply to all instances? BIOS that my thoughts do not apply to, where you can’t use BIOS region with UBU, I’ve never seen myself but I also don’t use UBU for actual edits all that often either.
Thank you for that informative reply. I can only hope I never did use stock bios that way though have used fptw64 a hundred times to flash my dumps modded either by hand or through Ubutool. Have not noticed any negative effects as of yet. Also glad I took time to read the reports regarding the Gigabyte Z390 Kedarwolf had issues modding as I have the same board as him. Will have to pay attention to those FIT addresses just in case. Though if I recall correctly Sonic stated should use mmtool 5.2.0.24 for that board as it will ‘cope’ better? And if you use it rename it to a4 or a5?
You’re welcome - SoniX was saying that sometimes, in some BIOS/instances, this can mess up the FIT Table. I’ve never seen that happen, only when changing microcodes manually or with UBU at times, which we (or UBU) correct the FIT table afterwards anyway when it’s present.
You’ll have to wait on SoniX to answer you on the rest of that about renaming or which to use for that board, I am not sure what’s going on and have been waiting for all these recent changes with this or that MMTool version to get more “finalized” before downloading UBU again I do all mods by hand, but I do use UBU tool often to find a modules UUID quickly, or to show users something information-wise (modules present, version etc). Still using UBU_v1_70_rc20_1 as of now.
I tried latest UBU tool (1.73.1 and 1.73.2) to mod the latest official ASUS BIOS v3603 for the P8Z68-V-PRO (non-GEN3) board with new microcode and newer option ROM versions.
The result was: The full package (modding all option ROMs to newest offered by UBU) failed!
What worked was: - updating Intel RST ROM to v13.1.0.2126 (although Fernando suggests keeping a 12.x version for the Z68 chipset generation, this is unfortunately not offered by UBU) - updating Intel microcodes (esp. Sandy Bridge 206A7) - updating Marvell ROMs (for the 6 Gbps SATA ports) - keeping Intel Video BIOS at v2124 (which seems to be rather recent anyway) - keeping JMicron ROM at v1.7.23 (eSATA ports; version is not too far behind the offered v1.08.01 and v1.07.28) - keeping Intel GbE Boot ROM
When it failed, I could quickly see a full screen BIOS logo followed by a blinking cursor in the top left. Pressing any key at any time did not change anything. The boot device LED on the board stayed constantly lit (like it is during a normal boot). My last resort was a cheap CH341A-based flasher and flashtool under Linux which quickly restored the thankfully socketed BIOS chip (Winbond) to a working condition by just writing the official v3603 BIOS on it .
I am, however, unsure why it failed and I admit, that I didn’t want to try every possible remaining combination. The two culprit ROMs in question (to me) are the JMicron 363 ROM and the Intel GbE Boot ROM.
The JMicron ROM seems to be the very first in the boot order. When I tried v1.08.1 I saw nothing on screen, v1.7.28 showed a message and even detected an attached disk, but booting didn’t continue. So maybe updating the Intel GbE Boot ROM would perhaps be possible in addition, I deemed it not worthy as I don’t do a PXE boot.
If any of the UBU devs is interested, I still have the failed modding attempts as files.
To all the others, this is a warning to not update every ROM offered! There was no other way except for using an EEPROM writer to restore the BIOS. All the CrashFree3 BIOS restore magic for failed flashes just did not work!
@weaker : Welcome to the Win-RAID Forum and thanks for your report. Since it is UBU related, I have moved it into the UBU Discussion thread. This way the UBU maker @SoniX and the UBU users may better find your contribution.
The UBU tool doesn’t offer any Intel RST RAID ROM module. You can choose the desired version yourself by putting the file into the related UBU subfolder. For details please read the start post of >this< thread. Regards Dieter (alias Fernando)
OK, then I must have done that by myself upon preparation. Probably late at night I read a lot before I tried and of course I read also the thread you linked. Do you think it makes a noticeable difference between Intel RST 13.1 and the recommended 12.x version? So far, everything is solid and quick. And the pauses (probably due to SATA link power management) are also gone.
I thought it was latest. All I mentioned about 2013 makes sense now 
