To your remark in #70 Ok. A similar arrangement of the microcode container exists from the 100th series of the chipset. But I can not remember at least one mention of the fact that after replacing microcodes on such BIOSes with the help of UBU, users would get a brick. Perhaps this is due to the fact that basically the replacement was made using MMTool v5.2. But she also skids the container up and removes the Pad. But at the same time she can correct the position and contents of FIT.
When using UR (UEFIReplace), at the moment, a negative feedback was received. But as it turned out, the problem was not in the offset of the microcodes, but in the fact that the FIT itself had shifted, and the correction to the new offset was not made. After correcting this error, everything worked.
In any case, I added an alternative replacement method, similar to MSI x299.
But, this requires MMTool v5.2, and also if the new microcodes are larger in size than in BIOS, this will inevitably lead to a shift upwards and the removal of the Pad.
@SoniX - I am not sure if it only applies to UBU/MMTool modifications and these padding files, I’ve seen brick many times when doing manually too (UEFITool/Hex), if the padding files removed, or change in any way. Over time, I’ve just got used to checking these pad files (including ones not near microcodes), no matter how a mod is done, and if they do not match original BIOS then probably = brick. There may be times when it doesn’t brick if padding removed, but it’s big risk to take that chance it may or may not, especially if there’s no reliable way to semi-guess/know in advance when doing the mod? In your example above, did the padding file at the end of the last volume above VTF change too post-mod? If yes, then possibly not good BIOS to flash either.
Thanks for your follow up of the ‘problem’. To help you to diagnose it and regarding post #70 I have spend some hours to test modding the BIOS Region for a Z390M-Plus system using UBU tool v1.72.1. Here is the link to download the test results (7zipped 505 Mo file) : BR2401_UBU1721_tests_10-11apr19
3 variants of UBU tests: Without MMTool, with MMTool_a4 and with MMTool_a5. For each variant 6 “bios.bin” scenario: Single_Edit for RST modules, for GOP, for LAN, for µCodes, Multiple_Edits in the order RST then GOP then LAN then µCodes and Multiple_Edits in the order µCodes then LAN then GOP then RST. The full content of UBU folder is produced for each test done and located in the appropriate variant folder. So, each UBU folder does contain the output “bios.bin” file for analysis. Associate screenshots are provided in each variant folder.
Hope all the 18 “bios.bin” files for analysis (it should take lot of your time) will help to tell what and when the BIOS get (silently) broken.
Again, thanks for your time and your outstanding contributions.
First, for your BIOS, PZ390MP, MMTool is not used at all. You can even remove it and it will not affect in any way.
Second, we are only interested in the replacement of microcodes. That is, they need to be updated and then flash the BIOS. After reporting the computer is running or not.
In the reporting archive, only test files are sufficient. For example: - bios_mod_ubu_mC.bin - bios_mod_manual_mc.bin or something similar. You can also attach a text file, in which it is sufficient to describe that such a file is working and which is not.
Yes, i understand but as I have no software programmer to handle properly flashing via the CH341A Pro USB programmer I have. Under W10 or Linux interface the BIOS component of this mboard is not recognized. Apparently all the different software programmer versions have been tested only under W7. I have no W7 system for at least 4 years… So, I don’t want take the risk to have a bricked mboard without a BIOS re-store tool validate for this specific 128Mbits MXIC MX25L12873F chip.
@100PIER - wow, that is too much, 500MB! I only need you to modify BIOS once, with all edits except microcodes, then I can see if microcode edit is the one breaking the BIOS as I see it, or not. If you want to include one by one as I suggested >> RST modules, GOP, LAN, ucodes, then only 4-5 BIOS files would be needed, if we wanted to see if one of the others aside from microcode is breaking the BIOS IMO. SoniX and I are not looking at the same thing, or at least I am not 100% microcode edit is what’s breaking the BIOS as I see it - It may be, but possibly not, and that’s why I mentioned testing this way and sending me the files to check. So, if you want, upload one UBU mod BIOS with all edits except microcodes. And then if you want to additionally do one by one as I mentioned, one with RST mod only, one with GOP only, one with LAN only, and then one with microcodes only. Please also put in 7zip with max compression.
TO ALL Can someone please upload a copy of ubu.bat from v1_70_rc20_1 - I deleted my accidentally, thanks! Never mind, found a copy
Into the 500Mo package you already have lot of what you ask me, the folder names are self speaking. So, no need to me to resend what you already have.
You have Single Edit: RST modules only, GOP only, LAN only, µCodes only and Multiple Edits: in the order (RST+GOP+LAN+µCodes) or in the order (µCodes+LAN+GOP+RST).
For each case I do offer the BIOS.BIN built without MMTool or with MMTool_a4 or MMTool_a5. Sonix does tell that MMTool presence (whatever the version used) or MMTool no presence has no impact. I let you know what is your opinion about MMTool/no_MMTool ?
I will offer you soon to download the test case 7zipped missing which is a Multiple EDits done (RST+GOP+LAN) and no_MMTool.
@Lost_N_BIOS Here is the link to download the last missing Multi_Edits scenario (no MMTool used for this test): UBU_BR2401B_Multiples_Edits_[RST+GOP+LAN]_13apr19 The UBU folder is provided. Nota, when exit UBU tool I do get a Windows Explorer (this bug was already reported to Sonix, but I think the fix is missed with this v1.72.1 vesrion. If I remember a UBU.bat proplem…) So, now you have all possibles test cases for analysis. Thanks for your time analysis.
@Sonix, Thanks. I was not sure if when MMTool is present in UBU folder it was used by prority over UEFIReplace or not. Now it is clear for me. Does the "MMTool is required" invite criteria is only for BIOS Aptio V and when for some user specific edit such as "µCodes updates" or for any other criteria ?
By the way, did you remember the provisoire fix you indicate me few times ago into a previous UBU version to avoid Windows Explorer crash at UBU tool exit ? I thought it was fixed definitively but I do observe a such problem again with UBU v1.72.1 as reported in post #90 (the downloadable 7zipped file offered via the link does offer the full UBU v1.72.1 folder, so you can do the in-depth analysis of the full UBU folder and check again why the problem does re-appear again).
And so, I will try to explain again how UBU works.
Grab the file and define some parameters of the BIOS image: - Platform AMI Aptio /InsydeH2O/SCT Phoenix/Intel Insyde… - AMD or Intel - If Intel is the presence of FIT and how many containers with microcodes
Search and extract files EFI and OROM.
UEFIFind and UEFIExteact are responsible for these actions.
Next “Main Menu” and “Sub Menu” - UEFIFind, UEFIReplace and UEFIExttact utilities are working everywhere. - An exception is only for OROM on Aptio 4. MMTool is required to replace them.
[mCode] Replacing microscopes has several options.
AMD Aptio V Platform (Ryzen) - only mCodeFIT, since microcodes are located in padding.
Intel - If there are more than one container, then only MMTool is used. Since they are located mainly in PEI-volume. UEFITool cannot work correctly with such volumes. - If the microcode container is one, then UEFIReplace is used. UBU version 1.73 will allow the use of MMTool as an alternative method. Replacement is similar to that of MSI x299.
+ mCodeFIT for offset correction.
About “Exit” and so everything is clear.
In fact, the work of UBU is in many ways similar to the user’s manual actions.
@Sonix Thanks for your clear synthesis on how UBU does work.
I have tried v1.73 and got some problems:
1) why when Windows Explorer does remain opened on UBU folder does crash at UBU exit: [[File:UBU_crash_WindowsExplorer_14apr19.PNG|none|auto]]
2) when trying µCodes update (without MMtool presence) I got this error, my antivirus is educate to whitelist all the UBU folder. But, is there any reason to get this kind of error ? Does UBU use the default browser of the PC at any time ? If yes, I think ( a pure assumption) my antivirus (Iobit Fighter Antimalware v7.0) also has to take time to be educate to accept a ‘non-standard’ operation thru the web-browser. (at the second attempt after a popup menu invite acceptation the second attempt was accepted…) [[File:UBU173_µC_error_14apr19.PNG|none|auto]]
3) according your Post #91 I should NOT need MMTool presence and with this version v1.73 I get a contrary invitation message to use MMTool. If MMTool is not present I do observe the µCodes modding operation is not done. And after installed MMTool_a4 the µCodes operation has been accepted.
@Lost_N_BIOS I have done some BR2401B tests with new UBU V1.73. The MMTool presence is required for this version when trying mode µCodes. I have used MMTool_a4 to get accepted µCodes Edits. Here are 3 “bios.bin” 7zipped: BR2401B_UBU173_14apr19 One get with Multiple Edits [RST+GOP+LAN], One get with Single Edit [µCodes] only, One get with full Multiple Edits [RST+GOP+LAN+µCodes] Do you need more “bios.bin” ?
I do not know why you have such problems. UBU runs in a regular DOS console (cmd). Maybe the problem is in the antivirus, maybe in the special settings of Windows. I checked on: - Windows 7x64 (UAC disabled) + ESET IS - Windows 10x64 (UAC disabled) + Windows Defender - Windows 10x64 (UAC disabled) + ESET IS I do not observe problems.
I have already explained in which cases MMTool may be required.
Short question, is MMTool 4.50.0.23 still viable for service Aptio 4 BIOS with UBU and as standalone BIOS editor? Because in other thread recommend using it for just Aptio 4 BIOSes compare to what here prefer 5.0.0.7 as universal MMTool for both Aptio 4 and 5 with no trace of 4.50 mentioned.
@100PIER - sorry, but I don’t want to download 500MB to check BIOS issues. I have no opinion on MMTool and only use it myself when forced to (very rarely), but as SoniX said multiple times it’s not used anyway for your BIOS. I only needed you to modify BIOS once, with all edits except microcodes, then I can see if microcode edit is the one breaking the BIOS as I see it, or not. If you want to include one by one as I suggested >> RST modules, GOP, LAN, ucodes, then only 4-5 BIOS files would be needed. If we wanted to see if one of the others aside from microcode is breaking the BIOS (How I see it currently, and referring to previously posted UBU created BIOS mods before all this discussion BR2401Bmodded-via_UBU_07apr19)
Now, I downloaded your BIOS linked in post #96 -
biosRSTGOPLAN.bin (Has modified ucodes too vs stock 2013? +1 ucode count vs stock, unless you are using some other stock BIOS than 2013?) - Anyway, this BIOS OK to flash via FPT biosµC.bin - Broken BIOS due to the same two exact issues I outlined and showed images of in post #78 - I advise you do not flash this BIOS, unless you are ready and able to recover via flash programmer. It might be OK, but I would not risk it without flash programmer in hand. biosRSTGOPLANµC.bin - same as above
Here is updated BIOS safe to flash, I used your biosRSTGOPLAN.bin and updated microcodes manually and then fixed FIT. This was done using UEFITool 25.0, do not use 26.0 or same issues occur. If you want UBU to be able to do this, for your particular BIOS/case, I believe putting UEFIReplace 25.0 into the UBU folder in place of current one, then it will be OK/Same as I’m doing here (Have done this in past and worked out properly) http://s000.tinyupload.com/index.php?fil…913811624792532
@vuze4u mmtool v5.0.0.7 for Aptio IV BIOS ,remamed as "mmtool_a4.exe" mmtool v5.2.0.24 for Aptio V BIOS,renamed as "mmtool_a5.exe" I have copied both two versions of MMTool to root of the UBU directory.
Lost_N_BIOS: Many Thanks, your provided manually modded µCodes of the biosRSTGOPPLAN.bin file is exactly what I expected. Yes, stock 2013 is obsolete, the last stock is 2401, and yes ASUS has modified 3 µcodes for the 3 CPUIDs offered into 2013 stock and also added +1 new µcodes for a new CPUID.
Sonix: you said multiple times that I no need MMTool for this bios but UBU tool v1.73 said the contrary !
[[File:BR2401B_µC_15apr19.PNG]]
and after enter any key the original µCodes values is re-displayed:
Lost_N_BIOS: 1) Can you confirm me the manual µCodes you applied does correspond to the first displayed screenshot ? 906EA: 9A=>AE, 906EB: A4=>AE, 906EC: A0=>AE, new 906ED: B0
2) Your last recommandation is to replace the current UEFIReplace tool into UBU folder with UEFIReplace v25.00 Where can I get this exact version ? A link somewhere ?
Sonix: The current UBU v1.73.0 does require MMTool for this bios, so UBU does seem to ignore UEFIReplace. So, I don’t see how ‘to force’ UBU to use UEFIReplace v25.00 instead of MMTool requirement. Please, can you clarify ?
