2 options - search for a clean and customized VBT 250 or search for a working GOP from 17.0.1060 to 108x. It is not necessary to check all versions selectively. The principle is simple, but dreary - if it works newer, it does not work, we reduce the version.
Or leave it as it is.
Here there is a version 17,0,1071.
You need to put the file in a folder - “Files\Intel\GOP\v17”
Be sure to rename it to “IntelGopDriver.efi”.
Check if it works, then it will be easier to look for other versions.
v1.80.a16.1 corrected the Microcode update bug when I selected 0 - Do not use MMTool, followed by R - Start replacement.
The Padding file under File GUID: B52282EE-9B66-44B9-B1CF-7E5040F787C1 for my Dell Vostro 3670 bios is not there, but that’s not a problem. For me and other Dell users with these modern bios’ (Winbond W25Q256JV 32MB bios chip, in my case), you will select 0 - Do not use MMTool, followed by A - Start replacement Alternative with MMTool.
Or, you can select 1 - Use MMTool, followed by A - Start replacement Alternative with MMTool.
The bottom line is that whether or not you use MMTool (mmtool_a5.exe), make sure you select A - Start replacement Alternative with MMTool.
Not entirely true.
You can choose any option (“use MMT or not use MMT”). If there is only one container with microcodes in the BIOS, there will always be an “Alternative replacement” option.
Out of the box this feature does not work. You either need an .exe from MCE or you need to install Python to run MCE.py. Anyway, I made you an updated BIOS.
It’s definitely interesting, I wonder if anyone will figure it out. I attach two BIOSes. The “mm” is the one that should theoretically match your modified BIOS, but doesn’t. There is minimal difference, I don’t know if it makes any difference. Everything in this version has been replaced with MMTool. On the other BIOS, only the microcodes were replaced with that one. Try both if you like.
If the “without MMTool” mode was used, then everything is correct - there is no difference between 1 7x and 1.80.U EFIReplace is working, and there are no changes in this section.
UBU versions 1.6x and below use only MMTool,Most likely about these versions. We are waiting for clarification.
In version 1.80, I combine all the best from 1.6x and 1.7x.
And the glitch seems to be a double substitution in one file.
What do you think will happen if you first replace the file using UEFIReplace, and then immediately replace it with MMTool.
Add
I have fixed the file replacement procedure.
Now, if you use the “use MMTool” mode,
a copy of the file is being made.
in the first file, the file is changed using UEFIReplace.
after the replacement, the finished FFS is extracted.
make a replacement in the second file using MMTool and ready-made FFS
It doesn’t seem to work normally to me. With UEFIReplace (mode 0) everything says UBU replaced, but somewhere in the process it seems that it didn’t. Otherwise it doesn’t replace anything. Reopening the bios.bin, everything is the original. Except for the microcodes, but MMTool replaces those too.
I think you misunderstood me. The point is that the A18 does not work well, but the A17 does. The A18 does not replace the modules (EFI, OROM), only the microcodes. But those are done by MMTool. And I don’t understand what AMD files you mean. The contents of A17 and A18 are the same except for UBU.cmd.
