how about 17.0.1.0 SATA OROM ? @tistou77 @SoniX @Fernando ldo

@SoniX

Thanks, it is for the error at the opening of UBU ?
And for the microcode ?

Thanks

This is one of the solutions so that you can open the BIOS to work correctly in MMTool.

There are 2 more solutions.
1) Replace the contents of the GUID B981F167-9D2B-4CA0-82E9-63DF0E3C3BF3 with any file with a different size.
2) Use MMTool v5.0.0.7.

Ok thanks for your explanation
I also noticed that even with the error, it still works

And for Microcode, how did you proceed to update it without having the 4F error at boot ?

Zitat von tistou77 im Beitrag #4805

---

And for Microcode, how did you proceed to update it without having the 4F error at boot ?

---

@SoniX

Ok thanks so much, waiting for this version
Same option (C and M) with MMTool 5.2 ?

Zitat von tistou77 im Beitrag #4807

---

Same option (C and M) with MMTool 5.2 ?

---

Why does the bios before and after updating with ubu have different number of entries for cpu microcodes?

Before:



After:



Note that there are also differences with size and offset.

Could there be a problem after flashing this bios with booting?

@Fernando @SoniX

For 5, It is necessary to use the file MMTool 5.2 patched (for microcode of the X299) ?

And I still have the error "Firmware Volume open error" when extracting OROMs (with UBU)
I type "N" to the question to finish the program, I have this message and after it is good



and in the end I have this message



If I do not make a usage error, is it not possible for UBU to automatically handle the extraction instead of typing N and continuing?

Thanks

@tistou77:

Look like @Fernando post above " The option 5 ("CPU Microcode") was available without MMTool and showed the currently present CPU Microcodes, but was not able to update them. This was no surprise for me, because the AMI MMTool is obviously the best choice for many BIOSes, when it comes to the task "Update of the CPU MicroCodes".
Good: The UBU tool gives a very clear suggestion to use the AMI MMTool for this task. "

How about UBU 1.71 for R6E 1603 BIOS Master tistou 77 ? Do you had " 4F CPU CHECK " after BIOS flashback process ?

PS. Sorry I couldn't access rog forum now. They'd banned me due R6E O-Beggar issue. 5555+
After I got banned from ASUS teams , It was very impressive for me that my point on R6E O-Beggar was indeed true.
It was low cost version of R6E and selling at same price. Piece of junk from ROG can't believe who dare to buy.

On my Asus Prime z370 1601 Bios trying to add the 17.0.0.3720 ROMs i get this error:
parsefile: non-empty pad-file contents will be destroyed after volume modifications

This doesn't happen with the 17.0.0.3713 ROMs
I checked the UBU_v1.70.rc20.1_updated-01-31-2019 and 1.71_dev_test

They'd block by binary code same as X299 platform due many of us modded their BIOS oftenly.

@pokuly - open your stock before BIOS in UEFITool NE, on the "Parser tab at bottom", or may also possibly UBU shows it too, unsure - https://github.com/LongSoft/UEFITool/releases
If you see this message on stock BIOS, before modifications, you want to see same exact message and same number of those messages on stock and final mod BIOS >> parsefile: non-empty pad-file contents will be destroyed after volume modifications
Yyou want same before and after mod, if it's missing after mod but was there before, then don't flash BIOS (usually wont work properly, tiny chance sometimes it does)