Probably yes, because it has an Intel X299 chipset and should support VROC.
Do you use or want to use the VROC feature?
Me no but other yes with X299 
@tistou77 :
Please attach the latest BIOS for your X299 chipset mainboard.
@SoniX :
Meanwhile I have tested the v1.7.1_dev-test2 version with the BIOS v7.50 for my ASRock Fatal1ty Z170 Prof. Gaming i7.
Here is a short summary of my results:
- The UBU tool v1.71 DEV-Test2 without MMTool was able to successfully update
a) both Intel RAID modules (EFI “RaidDriver” and the “RaidOrom”)
b) all Intel Networking modules (EFI and Option ROM), which were within the related BIOS, and
c) the Intel GopDriver. - Without the presence of an AMI Aptio MMTool the option 4 (“Other SATA Controllers”) had no function.
- The option 5 (“CPU Microcode”) was available without MMTool and showed the currently present and the available CPU Microcodes, but was not able to update them.
- Contrary to the Test1 version the Test2 one showed the detected Option ROM modules within the main menu without any problem.
- After the addition of the AMI MMTool v5.0.0.7 (renamed to “MMTool_a4.exe”) the update of the “CPU Microcode” worked flawlessly.
Here are the related pictures (left: Main menu before the BIOS update, middle: Main menu after the BIOS update, right: CPU Microcode update success):
Conclusion: Well done, SoniX! This is again a big step forward for the usage of the UBU tool.
@Fernando
Thank you so much! :))
OOPS! Sorry. Found a mistake and fixed it.
Implemented the following method:
If MMTool not present, but the count of containers with microcodes is 1, then UEFIReplace is used.
For other cases, MMTool is required.
Added:
Upload Test_3
where version Test_3 is available ?
@SoniX :
Thank you very much for the release of UBU’s 3rd test version v1.71.
Meanwhile I have tested this new test version with an AMI Aptio IV BIOS (ASRock Z97 Extreme6 v2.80) and an AMI Aptio V BIOS (ASRock Fatal1ty Z170Prof. Gaming i7 v7.50).
These were my test results:
- The “pure” UBU v1.71 Test3 version (without adding any AMI MMTool) is able to execute nearly all BIOS modding tasks, which are offered by the UBU tool.
- Even without MMTool the option “Update of the CPU MicroCode” worked flawlessly with the Z170 BIOS.
- These were the only tasks, where the addition of the AMI MMTool seems to be required:
a) Update of some Option ROM modules
b) Update of the CPU Microcode for certain BIOSes (here: Z97 BIOS)
Here are the related pictures I got while using the “pure” UBU v1.71 without having added any MMTool (left: Z97 BIOS, right: Z170 BIOS):
1. UBU Main Menu at the beginning:
2. UBU Main Menu after having finalized all tasks:
And here is the picture I got with the Z97 BIOS after having added the AMI Aptio V MMTool v5.0.0.7:
Summary: Everything seems to be fine - Congrats to SoniX!
By the way - I have fixed a typo within the “Network” section of the UBU.bat file (should be “Chips” instead of “Chios”).
@SoniX :
UBU v1.71 DEVTest3
_List_Extri.TXT
Inrel VROC irste 560052004F00430020003.002E00
Intel typo ?
My MB bios 1704 has EFI IRSTe v5.4.0.1039 with VROC
https://dlcdnets.asus.com/pub/ASUS/mb/LG…E-ASUS-1704.zip
Intel_RST(e)_r4 has v6.0.0.1024. with all contents copied to UBU intel RSTe folder
UBU does not update to v6. Should it ?
Thanks for UBU
@Fernando
Thank you so much for the tests. :))
@biozzz
UBU test versions are made to solve some problems in the replacement of microcodes. I think that at the moment we managed to solve many of these problems.
Now you can do other modules, including IRSTe/VROC.
Immediately I will answer you - no typos. Since there are no common patterns for the files of IRSTe and VROC, therefore they will have to be considered separately.
Think the difference is clear?Thereby I was puzzled and wrote about it here.
Intel EFI “RaidDriver” and “GopDriver” BIOS Modules (45)
Therefore, UBU does not know how to work with new versions of IRSTe/VROC.
Now, for work, I have your BIOS image with the necessary files to implement support.
Added:
By the way, in the 5th version of IRSTe, I did not find any mention of VROC.
@Fernando , @Sonix
Do you have observed like me that after Exit UBU Dev Test3 you got a EXPLORER.exe crash like this one ?
BEX64
Nom de l’application: Explorer.EXE
Version de l’application: 10.0.17763.348
Horodatage de l’application: 03d46193
Nom du module de défaut: StackHash_686f
Version du module de défaut: 0.0.0.0
Horodatage du module de défaut: 00000000
Décalage de l’exception: PCH_EB_FROM_ntdll+0x00000000000A01C4
Code d’exception: c0000005
Données d’exception: 0000000000000008
Version du SE: 10.0.17763.2.0.0.768.101
ID de paramètres régionaux: 1036
Information supplémentaire 1: 686f
Information supplémentaire 2: 686fa74059c76c74c3be5bab467b2332
Information supplémentaire 3: f049
Information supplémentaire 4: f04905c5f4de22ab50d7bd47c2a1e956
Nom de l’application: Explorer.EXE
Version de l’application: 10.0.17763.348
Horodatage de l’application: 03d46193
Nom du module de défaut: StackHash_686f
Version du module de défaut: 0.0.0.0
Horodatage du module de défaut: 00000000
Décalage de l’exception: PCH_EB_FROM_ntdll+0x00000000000A01C4
Code d’exception: c0000005
Données d’exception: 0000000000000008
Version du SE: 10.0.17763.2.0.0.768.101
ID de paramètres régionaux: 1036
Information supplémentaire 1: 686f
Information supplémentaire 2: 686fa74059c76c74c3be5bab467b2332
Information supplémentaire 3: f049
Information supplémentaire 4: f04905c5f4de22ab50d7bd47c2a1e956
Additionally to my recent report I would like to show how the task “Update of CPU MicroCode” has been managed by the “pure” UBU tool v1.71_Dev-Test3 (without MMTool).
Here is the picture I got with the ASRock Z97 BIOS while trying to update its CPU Microcode (Update didn’t succeed due to the missing MMTool):
And here are the related pictures I got with the ASRock Z170 BIOS (Update succeeded):
@100PIER :
No, I didn’t get an EXPLORER.EXE crash while doing my work with the UBU test tool.
Question: Did you add the AMI Aptio MMTool or not?
Yes, all tests were done with MMTool v 5.0.0.7 added and renamed as indicate into UBU folder.
@Fernando
That’s right, it should be.
In your case, Z170 has one container with microcodes and it is not in the PEI volume. This allows you to not use MMTool.
Z97 of these containers are larger and they are in the PEI-volume. Therefore, it is desirable to use MMTool.
@100PIER
I can only assume that this is somehow a problem in the OS. I have no other ideas.
Added:
100PIER Try the following:
Find the line “EXIT 0” and delete “0”.
If the problem persists, then I don’t know the reason.
@Sonix, @Lost_N_BIOS , @Fernando ,
1) Where in UBU Folder is located the "EXIT 0" to be replaced with "EXIT" for a test ?
2) I have tried to mod via UBU tool (with MMTool) the BIOS REGION of the ASUS Prime Z390M-Plus BIOS v2013. The BIOS REGION File size is 13 Mo only.
The BIOS REGION File was obtained via FPT Tool (under DOS interface) as Recommended by Lost_N_BIOS
Option Network to modd i719 component stuff is OK
Option µCode CPU update does seem OK, however I am worried about a message.
Here are the screenshots:
I am worried by the error message "Incompatible file size" at step10.
Does the µCodes update were properly done ?
Do you think this modded BIOS REGION can be flashed with FTP tool without bricking the motherboard ?
I suspect, that SoniX meant the related command within the ubu.bat.
Thanks Fernando, I have modded UBU.BAT, via Notepad++, at line 1601, and will do test.
@100PIER - that looks like it’s failed to me, on the microcode update/FIT table replacement.
If you do not have a flash controller, you shouldn’t beta test BIOS mod programs (beta UBU I mean), that’s risking a bricked system with no way to recover.
mCodeFIT error message "Incompatible file size"
At the moment, the adjustment of FIT is possible only for complete BIOS images (8192KB or 16MB). Other sizes are not allowed.
This is done for 100% accuracy, since the offset of the microcodes is read from the real position in the BIOS image.
I can fix this for the BIOS Region, but I do not have absolute confidence that the resulting shifts will be correct for the entire BIOS image.