I understand what you are saying. I already wrote about this. We have already encountered this when the offset to the FIT itself was lost. At the same time, the old versions of MMTool 5.0…0.7 and UR/UT 0.2x.x do not correct this offset. MMTool 5.2.0.24 and mCodeFIT 0.6.8 handle this.
But, in general, you must first watch the original and backup. There is such an example, although the file is clean original.
As I have no sufficient skills to understand the issue about µCodes update I do summarize my understanding:
For you Lost_N_BIOS the “bios.bin” is suspect and should not be FPT flashed ? For you Sonix do you think the “bios.bin” should be correct and FPT flashable because no error where displayed/detected during UBU operation?
→ The original stock BIOS (.CAP file) → The full “UBU v1.72.1 folder” which do contain the entry Bios Region input file “BR2401B.bin” to be modded, and the Bios Region output file “bios.bin” after UBU operation. → The set of ‘step by step’ screenshots to visualize the UBU operation done without any problem report and specifically before and after µCodes updates.
So, the basic question is: Does the output file “bios.bin” is suspect ? or is it fully OK to be FPT flashed ?
Do I have used the correct “MMTool” version for this try? or Do you recommend to use UBU tool for all items modding, except for µCodes modding, when the UBU input file is a Bios Region file (13MB) and not a classical Bios .CAP file (16MB) ?
Your recommandations will be very helpful to clarify me.
The first thing I want to say is that for such BIOS MMTool is not required at all. Everything makes UEFIReplace. All that is contained in the archive, has no information for reflection. As I said earlier, I see no particular problems after modifying the original BIOS image.
In the end, you yourself must decide to make and flash a modified BIOS or not. No one will ever give a 100% guarantee that everything will be Ok. Any intervention in BIOS is a tape measure.
ASUS also has CrashFree bios 3 function in board to rescue damaged bios ,but I think asus 3xx series board needs to verity intergrity and spi of bios.So it’s hard to flash bios, just wait for new bios version from offical.
After UBU operation,you could save modified BIOS by chosing “1 rename to…” selection instead of "0 as is bios.bin " ,this instruction you could find in section “C. Finishing UBU:” of thread [Tool Guide+News] “UEFI BIOS Updater” (UBU)
@SoniX - on post #70, I was not referring to anything to do with FIT, FIT is OK in his mod BIOS. Here is a link to the mod so you can see the items I mentioned at post #70 - https://1drv.ms/u/s!Ai4MDoZBl1gOggsHRFiOxruTN10t 1. Padding file above microcode is removed (Sometimes this is OK, often = brick) 2. Padding module just above VTF is drastically changed vs stock (stock is compressed, mod one is not, + different contents etc & it should remain same general “Look” in UEFITool before/after mod) Those 2 things are all I was mentioning, to my eyes this is broken mod BIOS and I would not risk flashing without programmer in hand
Sorry for any confusion, I did mention ucodes, but only in regards to that is what mod often removes the padding file and breaks the BIOS (FIT issues aside if present, this happens often with any various edit). He also modified other things in that same volume, so any of them on rebuild could have done this, or could have also changed the structure of the padd module above VTF too. I am not sure which edit is breaking the padding files in this mod (x2) Here is images of what I mean, in case you don’t have time to download stock BIOS and mod BIOS to compare
@100PIER - no, I mentioned this BIOS >> BR2401B_ubumodded.bin << I would not flash that due to reasons mentioned above and at post #70, it might be OK, but very risky to flash without programmer in hand (and again I do not think it’s OK, seen both of these issues and either alone = brick many times) And yes, as SoniX mentioned above, we cannot guarantee anything, I can only point out the issues I see in a mod by looking it over and then offer my advice and thoughts. You also cannot rely on any Asus "BIOS crash free recovery stuff etc, that is only last good hope, if BIOS is broken bad enough these kinds of recovery will not help, and with no programmer in hand no USB Flashback on this model risk goes way up when flashing even stock BIOS. I am not correct 100% of the time either, so you don’t have to only accept what I say, but I do know what I’m talking about so freqency of me being wrong on such things is low.
Thanks very much for your very clear opinion and I do agree to not FPT flash the ‘bios.bin’ output file of the UBU tool when the input file is a “BIOS region” dump.
As, at the moment, I have a programmer CH341A near the machine, but not working under W10 interface or Live USB Linux interface for some compatibilities problems with the BIOS component MXIC model MX25L12873F , I don’t want, for sure, to take the risk to brick the BIOS and get no solution to re-alive the BIOS. I do agree totally also the “BIOS crash free3” function is a pure ‘marketing feature’ which technically does not make sense… (As you said when a BIOS is dead and fully bricked, the minimum vital to offer under BIOS menu the “BIOS crash free” feature is also dead and bricked, and only one external action (such as a programmer tool) can re-alive the BIOS component).
So, at the moment, the only valid way to get a ‘FPT’ sure flashable modded BIOS is to provide you the stock BIOS file, the BIOS Region Dump file obtained from the “BIOS host PC system” via your Guide Lines, the list of items to mod and with your expertise you do manually mod the BIOS Region Dump file that can be finally is ‘FPT’ flashable on the “BIOS host PC system”.
@100PIER - As mentioned, it very well might be OK, but chances are high it’s not so it’s big risk to you if you do not have flash recovery tools and know how to easily recover from bad BIOS flash. Sometimes crashfree BIOS might recover from certain bad flashes or corrupt BIOS, but not always, same as with all brand “BIOS recovery or protection” programs, you simply can’t rely on that especially if you only have one system and no working flash recovery setup.
I have the stock BIOS, I simply need the FPT dumps from you and all the mods you wanted done, as we originally discussed in PM but then you kept getting new BIOS come out from Asus so we had delays, and I was slow to reply in PM’s too (Sorry) UBU may be able to edit some, or nearly all of those edits you made without messing up the BIOS (As I see it), it could just be the final microcode edit that breaks it all, hard to know. If you want to know for sure which edit, and when etc, you’d have to edit in one thing at a time and then save that BIOS into it’s own folder with the file you edited in (so I know which edit it was for each folder/BIOS) and then do that for each edit one by one and send a bunch of single edited BIOS (All in one archive eventually) Do the edits separately and save, so one BIOS has updated this only, next BIOS has updated that only, and so on, until you have a single BIOS for each of the edits. Then, I could check them all and tell you exactly what and when the BIOS gets broken. This would be helpful for SoniX to know too I’m sure.
And yes, I could then edit the BIOS manually and you could then flash via FPT and we’d be done
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).
