WHY IRSTe?
For IRST -> RST (v11-v17)
For IRSTe -> ESTw (v3-v5)
AMD microcode update on Asrock FM2A75 Pro4-M failed. Black screen after i flashed bios with updated microcode. Before i update all roms its working, after microcode its not. Which version i use? Latest UBU v1.70.rc16.1.1
Here is my thread for whats going on: Asrock FM2A75 Pro4-M MAC, UUID etc
Microcode insertion into the AmdProcessorInitPeimPEI file in above mod BIOS was done properly, I checked, something else in the rebuild or edited module insertion failed @SoniX Or maybe the capsule removal/editing process?
AMD mCode.
Unfortunately I can not say what the problem is. I do not have a motherboard on the AMD platform to do tests.
I can tell you how the replacement works.
* For Aptio 5, there are no problems, since the microcodes are in Padding.
For Aptio 4:
1) Exttacrt (PE) body AmdProcessorInitPeim
2) We find the necessary microcode and replace it with a new one.
- We do not insert, do not add, namely replace 1 in 1.
3) Modified AmdProcessorInitPeim replace in BIOS.
Everything. Perhaps we must also do something, but as I said - I do not have MB AMD to test the functionality.
PS
- I can assume that the problem is in the UEFIRaplace utility, as there are problems when working with PEI-volume.
- Perhaps you need a new version of AGESA,
Edit:
If anyone has ideas or specific solutions, then please share.
Thanks for the info @SoniX - I did notice it was exactly replacement in-place, and that all looks good to me (Same as I would do manually)
I will see if he wants to test insertion of the module via MMTool, or direct hex replacement. He does have programmer so hopefully he will be up for a quick few tests. If it turns out OK I will let you know, thanks again!
* Forgot to mention, Capsule removal on that BIOS is OK, he said he modified several other roms using UBU before, without microcode update, and it was OK
Thanks for infos, yup i will help if i can to test AMD microcode updates. Yesterday i get working mobo again with programmer, now second project to update all roms, and also update microcode. The question is i use only UBU or i need UEFITool or hex edit also?
@SoniX
I have updated the microcode with UBU of my ASRock 990FX Professional (Aptio 4) and it works perfectly.
@Lost_N_BIOS
Perhaps the problem is in the microcode of the FM2 platform
microcode replacement looked fine, I think it’s just methods used in general, we need to try other methods - will be testing different ways to do same modification tonight, hopefully we can find the solution.
For now @PREM1Z don’t use UBU/UEFITool (I assume same as using UEFIReplace), we already know the outcome there for this particular BIOS. I will make new BIOS for you to try tonight, unless you want to go ahead and try too, it’s OK with me.
I planned to do a direct hex edit, in-place update of the ucodes, and then another using MMTool to extract and edit the AmdProcessorInitPeimPEI then reinsert.
Right, I have made it work now. Thanks for the help.
@SoniX - regarding #4562-4565 and this thread - Asrock FM2A75 Pro4-M MAC, UUID etc (Asrock FM2A75 Pro4-M UBU Microcode update)
I have created three test BIOS for the user and they all work properly, those are in post #11 at link above if you need to see them to check or compare.
I believe the issue with UBU/UEFIReplace was incorrect checksum applied in the header of the modified AmdProcessorInitPeimPEI module, but it could be also due to rebuild of other modules on save too, not sure.
I did check and see UBU changes this checksum, but the value did not match the value I got that worked during my edits.
I edited three ways, and all worked properly (MMTool/Hex, other direct hex edit, and hex and PhoenixTool combo (Edited via structure button only, then grabbed BIOS from dump folder without rebuild fom main app)
@Lost_N_BIOS
As I have already said, there may well be a problem with the PEI. UEFITool/UEFIReplace utilities do not always successfully work with PEI volumes. This was noticed when replacing Intel microcodes. Therefore, it was decided to return MMTool.
In this case, the complaint is one, but I will take it into consideration. If there are still complaints, I will consider other solutions.
Thank you.
OK, yes I saw you mentioned that, I only meant to pass along this info in a helpful manner, in case maybe it helps you figure out how to maybe correct things in any future updates regarding this type of modifications.
@Lost_N_BIOS
Hmm … Very strange. I compared 3 of your files and they are identical. This really surprised me.
I see only the replacement of the microcode and the adjustment of the CS.
This is typical if all 3 BIOS files were manually edited in the hex editor, without using third-party utilities.
In these files, the creation time is almost the same. This is also confusing.
But nevertheless it works.
I will try to replace UEFMReplase with MMTool, let’s see what happens.
@SoniX - I made all three of them in very short time-frame, within a few minutes maybe. I assumed they would be similar, but not exact same, I suspected MMTool would look most different, since it does it’s own thing sometimes 
Hex edit first I think, then MMTool (Extract, hex edit, replace), both of those only took a second, then PhoenixTool is just as fast as using UEFITool, edited via structure button, extract file edit in hex and replace, then grab file out of dump/BIOS folder and done (Except correct checksum done after that I think)
Phoenix method outlined here would be same as an edit with UEFITool, I manually fixed checksum post-edit, and would assume same needs done with UEFITool/UEFIReplace and it would be OK.
I think for this process, when PEI module is involved, yes maybe MMTool would be best choice if easily implemented for such instances only.
@Lost_N_BIOS
I did the tests with MMTool and got the same result as yours.
One thing is bad, MMTool cannot edit checksums when replacing FFS.
Well, we will think what to do with it.
Yes @SoniX - I think maybe I corrected all checksums myself after edits, I can’t remember, but that may be also why all times you checked when comparing are very close too.
I noticed checksum was wrong when dropping the hex edited file into UEFITool, then fixed other two as I went along. So, whatever gives checksum in UEFITool for that module could be invoked to get correct value post re-insertion, then correct checksum last.
Well, in any case, we know that the problem is in the UEFIReplace. At the moment, only one solution - to use MMTool.
Since it makes no sense to repair the old platfomu UEFITool, which made UEFIReplace.
v1.70 RC17 not working:
I just downloaded UBU 1.70 rc17 and copied patched MMTool v5.2.024 into its folder. Then I pasted the latest BIOS 1604 for a Asus Sabertooth 990FX (https://dlcdnets.asus.com/pub/ASUS/mb/So…X-ASUS-1604.zip) to UBU’s folder and started it. I want to test the replacement of AMD microcodes, so I did try it and got the message “parseBios: one of volumes inside overlaps the end of data File replaced”. This doesn’t sound like everything is ok.
Here is a screenshot: https://imgur.com/2L8WhV5
What’s wrong here?
Edit:
After saving the modded BIOS file, I opened it with UEFITool 0.25.1 and it says “parseBIOS: one of volumes inside overlaps the end of data”. However, this also happens with the original BIOS file from Asus. Is this a problem?