Note made a slight change to the guide based on experiences with altering @Maison1 's bios file. Turns out if you have BootGuard entries you need to alter your master microcode file’s size by either deleting extra ‘FF’ values or adding ‘FF’ values to match the original file size.
Thanks for finding the problem with the larger microcode file. It needs to be the same file size as before when integrating it back into the bios main file. As for other replaced files like efi gop file and oprom files I thought UEFITool will adjust the microcode file size automatically if it is smaller or bigger than before but it is not done. Microcode file size when reintegrating needs to have the original file size. In the past I did microcode replacement directly in the main bios file and then when this file increases or decreases you automatically delete FFs or add FFs.
Thanks to CodeRush as well for creation of UEFITool which checks the FIT of the bios file. Otherwise it would have been a misflash although the main bios file had the original size. Smaller microcode files are automatically integrated and resized but then at end of the microcode file the MPDT string comes earlier than expected by FIT.
I’ve never had a problem with efi gop and orom driver sizes not fitting in with Uefitool except in one case the file was wrapped in a compressed module and I had to basically rebuild the whole module from scratch using edktool kit utilities. Posted instructions a couple months ago somewhere in the efi module thread. Got to find it before I forget how I did it!
Can anyone with a better understanding of the Microcode structure of AMI BIOS answer a few questions?
Original BIOS contains 4 Microcode updates (Broadwell, Haswell, last two appear to be engineering samples?). FIT therefore contains 4 entries. Via UBU, I have added 2 updates (Broadwell 1B, Haswell 23), which causes two separate issues.
1.) It appears from my understanding that since the new Microcode is larger than the previous ones, the FIT entries are no longer correct:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
+-----------------------------------------------------------+
|No| CPUID | Platform | Version | Date | Size Hex |
+--+----------+----------+----------+------------+----------+
|01| 00040671 | 22 | 0000001B | 17-11-2017 | 00003400 |
|02| 000306C3 | 32 | 00000023 | 20-11-2017 | 00005C00 |
+-----------------------------------------------------------+
MPDT None
_FIT_ in GUID B52282EE-9B66-44B9-B1CF-7E5040F787C1
01 mCode Address - FFE3FB40
02 mCode Address - FFE42740
03 mCode Address - FFE47740
04 mCode Address - FFE4CF40
Attention!!!
Check the Address in the _FIT_
Address 01 mCode + Size 01 mCode = Address 02 mCode
0xFFE3FB40 + 0x00003400 = 0xFFE42F40
The original FIT table looks like this:
2
3
4
40FBE3FF000000000000000000010100
4027E4FF000000000000000000010100
4077E4FF000000000000000000010100
40CFE4FF000000000000000000010100
So my understanding is I need to adjust the second line to read:
402FE4FF000000000000000000010100
Is this correct?
2.) Since the UBU has apparently deleted Microcode 3/4, should I "FF" out the lines in the FIT table that describe where they are located? The addresses listed are no longer valid, and it seems that it would not be good if the board tried to load data from these.
3.) Can someone explain to me what the Vol4/Vol5 entries actually mean from MMTool?
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
+------------------------------------------------------------------------+
| MMTOOL 5.00.0007 |
| Copyright (c)2014 American Megatrends, Inc. |
+------------------------------------------------------------------------+
| CPU Patch Information |
+-----------------------------------------------------------------------------+
|Vol|No| Boot |MicroCodeID|Platform|CPUID| Revision |Date(YYYY/MM/DD)| Size |
+---+--+------+-----------+--------+-----+----------+----------------+--------+
|04 |01| NO | 0226711B | 22 |0671 | 1B | 2017/11/17 |00003400| | | | | | | | | | |
|04 |02| NO | 0326C323 | 32 |06C3 | 23 | 2017/11/20 |00005C00| | | | | | | | | | |
+-----------------------------------------------------------------------------+
| Total Patch Size: 00009000 |
+-----------------------------------------------------------------------------+
+------------------------------------------------------------------------+
| MMTOOL 5.00.0007 |
| Copyright (c)2014 American Megatrends, Inc. |
+------------------------------------------------------------------------+
| CPU Patch Information |
+-----------------------------------------------------------------------------+
|Vol|No| Boot |MicroCodeID|Platform|CPUID| Revision |Date(YYYY/MM/DD)| Size |
+---+--+------+-----------+--------+-----+----------+----------------+--------+
|05 |01| NO | 0226711B | 22 |0671 | 1B | 2017/11/17 |00003400| | | | | | | | | | |
|05 |02| NO | 0326C323 | 32 |06C3 | 23 | 2017/11/20 |00005C00| | | | | | | | | | |
+-----------------------------------------------------------------------------+
| Total Patch Size: 00012000 |
+-----------------------------------------------------------------------------+
Vol 4 contains the two Microcode entries, and the "Patch Size" is correct (3400 + 5C00 = 9000). Vol 5 is a mystery to me... "Patch Size" is 12000, which is exactly 9000 * 2????
1)if u use Broadwell microcode 17 it has the same size as original, so u can put whatever haswell microcode u want. The fit is always ok.
Test it and check what it writes there when u use broadwell microcode 17 :
Attention!!!
Check the Address in the FIT
Address 01 mCode + Size 01 mCode = Address 02 mCode
2)U dont need to replace nothing about 3 and 4. Motherboard dont gonna use the engineering samples. And if u try an engineer sample i beleive that simply it will not start.
So to follow up, after spending quite some time checking my work I was confident enough of the changes to go ahead and flash.
1.) Added Broadwell 1B and Haswell 23 (which also removed the engineering samples)
2.) Fixed address in FIT for Haswell Microcode
3.) Removed addresses (blanked out with "FF") in FIT for Microcode that no longer existed.
4.) Re-Validated FIT via UEFITool NE to make sure it was reading Microcode data correctly.
After USB Flashback, everything went okay, HWInfo is reading correct Microcode version, and Windows has picked up on this and turned on Spectre mitigations.
Personally I don’t use Ubu anymore to update my microcodes. I only use it to verify my work because it removes some of the other microcodes. Thats awesome you guys got it working!
Someone asked me to update their microcode on a MSI X299 Sli Pro board and had a problem trying to replace GUID 17088572-377F-44EF-8F4E-B09FFF46A070 the Microcode file inside UefiTool choking on the bios file when it tried to save the modified file erroring out with "Bad Image Relocation Entry". Same thing also happened with Phoenix Tool. If anyone knows of any compatibility issues with UefiTool and X299 bios files please let us know.
Thank you
@davidm71
thank you for the good (if a bit complicated) guide.
a couple of questions:
1. you used 2 different versions of UEFITool, but both are now outdated… have you tried with the latest version, if it is possible to use just one?
2. the guide is for replacing microcodes, how does it work when you want to add one without touching the previous ones? I am asking because I want to make a desktop chipset (Skylake in my case) functional with SKL, KBL and CFL CPUs
@elisw
1. Newer version work too. You need the new engine (NE) version for reading the FIT, and the non-NE version for changing the firmware because NE is read-only and non-NE has no support for the FIT.
2. You can add more microcodes to the end of the Microcode FFS and you will need to add new microcode entries for each new microcode to the FIT.
@elisw and @Ethaniel ,
I tried the newer version 22.1 of Uefitool. Thats the first thing I did and it choked on the X299 MSI SLI Plus bios file when I tried to replace it.
There must be something special about that MSI bios file format that the tools do not like. Even Phoenixtool couldn’t do it and complained there
was one module too many or something.
For now we have to wait for the developer of those tools to comment. I have opened an issue on the github page. Hopefully Coderush if he
has time would take a look.
Thanks.
PS: @elisw As far as adding one I suppose you would just insert the microcode at the end of the master microcode file, and then append the start address to the FIT table if possible.
Theoretically it should work. If you have a lot of ‘FF’ 's at the end you would also have to make sure the file size matches the previous size in some cases or because I found out that
some bios files have more than just microcodes listed in that FIT table (or just replace an unneeded entry or append to the last entry). Point is the FIT table would have to be corrected
to point to each entry correctly wether its a Microcode or Bootgaurd or what ever. Then open your modded file inside the NE version of UEFITool to make sure it can successfully read the entries.
Like elisw I find the guide a bit complicated - maybe more complicated than it has to be.
Probably it makes things more difficult for me to understand because I’m not a native speaker.
For example it took me a while to realise that you are using the UBU tool just as a microcode repository. And guess what I found when I searched for "Hx Edit" on Google? Definitely not "HxD".
Things became (a bit) clearer when I found your outdated guide here:
http://www.overclock.net/t/1577530/guide-how-to-update-the-cpu-microcode-on-the-x99-ami-bios
What about providing a short title to each step that reveals what you intend to do?
And what about giving a clear designation to each of the files you use? I found "that file" confusing. You could mention the file name extension for example.
Sorry if I sound like a teacher. But I think your guide is too good/important to not deserve to be more "accessible".
@davidm71
I had a deeper look at my BIOS: it is of the small type(8192 KB)
The whole volume (AFDD39F1-19D7-4501-A730-CE5A27E1154B), where both FIT table and microcodes are, has a full size (262144 bytes) which is too small to have 3 microcodes, as they are circa 95 KB each.
Will it be possible to enlarge the microcodes volume (maybe reducing the size of other volumes to keep the full BIOS size equal or is it a dead end?
Sorry guys I was at a conference for the last few days. Will try to make my guide a little clearer and easier to understand. Stay tuned.
@elisw ,
Wheres your bios file? Lets take a look…
Hi,
I spent the day trying to figure out how to add an extra microcode file to the pre-existing microcode master file and may have a solution though it could be kind of risky. This is what I have done. The first thing to do is to append the extra microcode file unto the last microcode within the master microcode file making sure the footer at the end remains the same. The problem here is that most likely there won’t be any firmware volume room or space left to accomodate the extra microcode. In anycase you also need to extract the FIT table using UEFITOOL NE version and open it in a hex editor and add another entry without altering file size. Got to do a little hexadecimal math to correct the correct offset location.
You can do that by using a hex calculator to add the last microcode address location value to the length value of that last microcode entry according to UEFITool NE’s FIT table. You also have to change the value that corresponds to the number of entries in the FIT table file. That is the 8th byte on the first line inside that FIT table. For example I changed ‘05’ to ‘06’ to reflect I have 5 entries as before I had 4 entries. Then you save every thing and replace the FIT table in UEFITool and then replace the master microcode file using UEFITool assuming you have enough room to do so or else UEFITool will bitch and complain.
If that happens you have to compress the next file in the UEFI volume following the microcode master file. In my case it was GUID 2D27C618-7DCD-41F5-BB10-21166BE7E143 and it was the last and only file I had following my microcode file which was GUID 17088572-377F-44EF-8F4E-B09FFF46A070. I used some advanced commands to compress the file and add it back. Here’s the link in another thread here I asked if it would work: [Experimental] LZMA F86 decompression. I wish you could compress the microcode file as that would make life easier but I don’t think that would be possible. I can’t even promise that compressing the following file in the main volume will not corrupt your bios. However at the very least UEFITool NE was able to open the bios file and list 5 microcodes where as there was four before. Need more expert advice at this point to move forward…
Crazy…
Edit: Sorry its a bit verbose here. This is an advanced mod fwiw. Will try to clean it up later.
don’t worry, for the time being I am satisfied with two microcodes… but if you succeed I am definitively interested.
link for bios download:
http://asrock.pc.cdn.bitgravity.com/BIOS…DS(7.30)ROM.zip
@elisw ,
I took a look and in your case there is no free room to add a 3rd microcode at all.
Unless of course you can grow the ffsv2 folder which is a mystery…
Please advise how to add update agesa ? ASRock x370 Taichi firmware & microcode drive.google.com/open?id=1iE88FLr7gOcNCLw_uT6EHPQMIVbQvb7Z
@davidm71 :
Thanks a lot for your information. I only wanted to change the microcode in the BIOS of my MSI GE62 6QF laptop and I always prefer to do things while having some control over the process. However, as this is the first time that I do this kind of modding, I’d prefer if an expert could check the attached BIOS file before I flash it. The file is modified from the original file in http://download.msi.com/bos_exe/nb/E16J4IMS.117.zip. The original file has the microcode version 0xC2, which includes the Spectre fix, but I prefer to use the previous microcode version 0xBE until Intel fixes the buggy new microcode. So I downgraded the microcode in the BIOS file to the BE version (attached to this post). Could you do some tests to confirm that I have not done anything stupid on it? I have opened it with MMTool and UBU with no warnings. Do I have to take an extra care because this is a laptop or have you had positive experiences flashing laptops with modded BIOSes?
Thanks in advance!
E16J4IMS.117_BE.rar (3.81 MB)