How to? - AMD Microcode CPU update into an AMI BIOS (non-UEFI BIOS)

No luck mate, again the CFB3 program appears later than the flash process finish, anyway, thank you so much for all your help and time spended trying to resolve this issues.

Kind regards.

That’s not cool, of Asus I think! Try not flashing with any Asus related tools is the only other thing I can think of, I think CFB3 is recognizing it’s modified BIOS and stops it from working. Or if you have CH341A programmer, if not they are only $3 on ebay.
Try AFU ES versions I linked on page one, surely one will work.

I read all your post and looked at your original bios and i agree that restoring the integrity of the file/rebuilding it is probably the only bumb in the road remaining. I saw that you managed to update other modules before trying to update the microcodes. I am not used to use MMTool v3.23 and it may be a long shot but did you try to update another module AFTER updating the microcodes? If you are lucky, this can force MMTool to recalculate the checksum of the microcode file and rebuild it. I admit i don’t think MMTool will do it like, for example, CBROM do it, but it may be worth a try.

I was hoping to hear back with his results of trying AFU ES versions, with /GAN. Found another similar older BIOS this week giving ROM ID error instead of security/integrity error. I agree and think it’s just security check, not really flashing only acting like it, then recovering because it knows it’s modified BIOS.

AFU Or FPT DOS should get this flashed! I have not tried what you mentioned, well once I reinserted (in place, replace) the very last module 80h, same error when trying to flash.
My attempt in post #20 is kind of what you mentioned, I did the codes in, the it auto replaced them to another location, so probably same that way as if I continued after that and removed/added back another module. Not sure, but seems like it did what we’d expect from cbrom with similar things.

Same error with modified BIOS via AMITool (SLIC thing) we all know works like PhoenixTool on most all boards/BIOS unless there is a given error, same thing when flashing that too.
That really makes me think the only hold up is getting around the check, but using non-ASUS tools to flash.

Hi again mates!! (@Lost_N_BIOS and @Phoenix48 ), well , it has been a long time since my lost post in this thread, I’ve bad news, at this moment, it’s impossible to update the CPU microcodes at an AMI non-UEFI BIOS, I say this because I’ve been testing the process form the beginning (making the BIOS from zero) and flash it with a CH341A programmer and the result is the same, Crash Free BIOS 3 popups.

I don’t know if someone at this forum or another has been able to do this, but I think that the problem (like we said when this thread was opened)is the MMTool itself, it doesn’t recalculate the BIOS and the edited BIOS file is corrupt or broken when you try to replace / reinsert the E2 file (where the microcodes are).

Maybe we need to edit another file too or something like that, I don’t know.

Regards.

P.S.: When you power on the system, the message that appears on screen at Crash Free BIOS 3 is about the Block BOOT, maybe can we do something with this???

I don’t know if the 1B module is important to do this task (I’m a noob in this field - BIOS modding -), but, is there any kind of information of the CPU microcodes at this module??? I’m asking this, because I’ve found a tool that can unpack and pack that module (1B), but you’ve to compile it with Linux, and I’m a windows user, I don’t know how to compile it to try it, but the developer says that you can make a cross-compile, compile in Linux for windows 10.

The tools are AMIBIOS8 1B Utilities and you can take a look to them at:

https://github.com/pinczakko/AMIBIOS8_1B_Utils

@RaskaipikaFWR - flash (not program) latest BIOS and then send me a dump from the programmer. I’ve updated and used many AMI non-UEFI BIOS and even ones just like this, for myself and 100’s of other users, something different going on here
If you’ve already programmed a stock BIOS, not good Send me the first dump you made with programmer, or any dump you made before that.

The 1B tools you linked are only needed if we want to edit 1B, which we don’t. Lets call in the Pro AMD Microcode guy, maybe he already knows how to handle this type of issue we’ve been trying to work around @MiesMosel (See page one too, thanks)

Hello,

I’ll be back at home after weekend & would take a look at this.
Did somebody tried exchanging microcodes through romhole?

Regards, MiMo

Thanks @MiesMosel - I did not, but will look at that now. Previously I did module extract and update, and using microcode tab update, even dumped with phoenixtool and edited mid-process and rebuild with that, everything fails after flash.
Maybe some checksum issue or something to do with what I mentioned in post #12 (Or combo of both). I will check out romhole and see if I can see what you meant there.
I checked about romhole, and can’t find any info how that works, tested inserting a single ucode, crashes 3.26 and 3.22, but that’s probably not what you meant So will have to wait on you to explain this or until you have time to check yourself.

Hello Lost_N_BIOS,

it’s only an idea with the romholes, because I remember it once.
Asus boards mostly are secured BIOS, if UEFI or not.
“How” is this BIOS secured by which technique?

Best regards, MiMo

Ohh, I’m not familiar with method, so didn’t know anything about how to do it or how to try etc I do not know how BIOS is secured Even when mod BIOS programmed in with programmer Crash Free BIOS 3 invokes on reboot
Now, that could just be due to we’re breaking the BIOS with all currently tried methods to replace microcodes, or could be due to checksum or something else needs fixed first, not sure. I was hoping you already would know due to BIOS type etc, maybe you will see when you get home and start looking at the BIOS.

Hi again mates (@Lost_N_BIOS and @MiesMosel ), excuse me for the delay to answer you guys, well, I’ve flashed the “factory lastest version BIOS -1801-” using EZ Flash 2 tool from the BIOS, and then, I’ve used the CH341A to make a dump.

Here is the dump (google drive link):

BIOS dumped file

I don’t know if the MiesMosel’s question is about this, but the message that appears when I try to flash a BIOS image with the microcodes updated (E2 extracted, edited and replaced) is about “Boot block”, which if you take a look at MMTool 3.26 is EBB or Extended Boot Block, I think that MiesMosel is right, the ASUS’s BIOS are secured and maybe, we can do nothing about this, I don’t know.

The ways that I’ve used to flash the updated BIOS have been using ASUS EZ Flash 2 and using a CH341A programmer.

Regards.

Thanks @RaskaipikaFWR - it’s not so much about Asus being secured, we go around that every day flashing different methods, this is the first/only board I’ve ever ran into that couldn’t even run microcode updated mod BIOS, since you programmed one in and saw the same issue on reboot.
I’ve updated microcodes for users without issue for many many years on many Asus boards much older than yours and much newer too, all without issue. There’s something different about this BIOS, and since it’s older, I’m sure it’s just something to be done while modding probably forgotten over time and it’s not coming to mind just yet

Asus EZ Flash will always fail to flash mod BIOS, this is a given, so don’t waste your time with that ever. It’s always AFU using a certain version or method, other known flash tool for given BIOS version (for example some might use a phoenix based flash tool etc), or programmer.
Programmer should be no issue, so this means something in the mod process is not right, hopefully we can figure out… or remember

@ Lost_N_BIOS, I’ve used ASUS EZ Flash to be sure that the dumped created with the programmer CH341A was a “goog dump”, and the few information available at Internet about how to update microcodes for AMD non-UEFI BIOSes, makes this process more complicated, at least for me.

I don’t think taht we broke the BIOS the last year trying to update the CPU microcodes because when I’ve update the BIOS “without cpu microcodes” the result it has been satisfactory ever, I want to say that the updated BIOS with the last available PCI ROMs works well, no BSODs in Windows or problems with those PCI ROMs updated, and all the information about the motherboard itself is ok (MAC, serial number…).

I hope that you guys can be find the root of the problem with this motherboard taking a look in deep to the dumped BIOS because it’s a good motherboard that works like a charm with a FX 6300 processor.

Thanks for your time and help.

Regards.

EZ Flash may or may not program a dumped BIOS, it’s not designed for that but may accept it. It will never accept mod BIOS, usually, this is by design, so I simply meant don’t waste your time trying to EZ Flash any mod BIOS.

Last year? Do you mean I or someone here, updated a BIOS for you to modify other items but not microcodes, on this exact board before in the past, and you were able to use that one?
If yes, how did you flash it then, and did you try that same method now? And, what all was updated, please link the thread/discussion location. Thanks for mentioning this, it helps us know mod BIOS itself is not the issue then, only the actual microcode updating mod this time around.



@Lost_N_BIOS I will start form the beginning:

I’ve mod by myself the last available BIOS version (1801) to update the PCI ROMs (LAN, AHCI and RAID) two years ago, and I used the EZ Flash to do that wthout problems, it’s more, when I used windows 7 with this board, I modified it to get SLIC table (2.1) and the result was the same, NO problems.

When the last year, the Spectre and Meltdown vulnerabilites were published to the public and the respectives CPU microcodes for FX processors were published, I wanted to add them to my BIOS, and at the same way like when I updated the PCI ROMs, I searched information about it in this fantastic forum.

With the last year, I wanted to say all the information / progress that you can read in this thread, if you re-read this thread, you can see that the only BIOS that somebody made for me was you (trying to help me, of course, I want to say you THANKS!! about that); if you read the first page, I found that when we extract and modify the E2 module with HxD program (E2 is where the CPU microcodes are, I think) and replace it with MMTool 3.26 or other versions , its position (E2 module) changes and its Lockrom too, that is the root of the prblem, that MMTool doesn’t recalculate linke Phoenix BIOS Tool.

The problem I think, is not with the flash method (EZ flash or using a programmer), the prolem is when you update the CPU microcodes (extract, edit and replace process).

Sorry for my english, like you can read is not my native language and maybe, I’m making this task harder for you guys, excuse me.

2 years ago? Are you sure you remember correctly EZ Flash was how you updated? Do you still have that modified BIOS you made? If yes, can EZ Flash flash it now?
Yes, I knew I made some BIOS for you to try and update microcodes, I was asking only about the previous mod you said you flashed, I didn’t know you did that yourself so I was asking for a link to the thread to see what all was done.

Don’t worry, we will try to find a fix. I did re-read page one before I called in MiesMosel too, so yes I did remember all the issues
It’s good your board and EZ flash took mod BIOS back then, see if it does now with same BIOS you created two years ago (or mod new one without microcodes), maybe it’s not updated to where it blocks mod BIOS like all currently do.
If new or old mod, minus microcodes can be flashed in still via EZ Flash, then yes, we need to figure out how to correctly update the microcodes is all and than you can EZ flash that too. Don’t worry about “More work/Harder for us” etc, we (at least I) enjoy the challenges!

I will try again tomorrow when I have some time, and see if I can figure out proper method!

I’m so sorry but I don’t have that BIOS thtat I made by myself, but like the only thing that I did was update the PCI ROMs and nothing more, when I flashed the “stock BIOS” from ASUS webpage, the changes are reverted and the actual BIOS into the chip is like the original, well I think that, maybe that’s not true, you’ve more lnowledgment abou the process than me.

Yes, I’m sure that when I inserted time ago the slic 2.1 table for Windows 7, I flashed the BIOS with EZ Flash 2 BIOS tool without problems, after, when I began to use Windows 10, I flashed with EZ Flash 2 too the stock BIOS to “delete” the SLIC table and have a "clean BIOS (without SLIC table), and like I’ve said before, when I mod the BIOS by myself to update the ROM modules, I flashed it with EZ Flash 2 too without problems.

I’ve to say that this time I’ve tried to do the process of update the CPU microcodes with the CH341A programmer because I bought it a few months ago, when we tried the last year update the CPU microcodes, I didn’t have the programmer, I used the EZ Flash 2 tool from BIOS that time; finally, all the BIOS MODs that I’ve made and flashed these last years (SLIC Table and ROM modules), they have been done downloading the last available BIOS (1801) file, editing it and flashing it with EZ Flash Tool 2 without problems.

I haven’t used the AFU DOS program never, that’s for sure.

@Lost_N_BIOS and @MiesMosel , take a look to my BIOS file posted at this post when you have time and you can, one more time, thank you so much for your time and help.

Regards.

P.S.: I’ve made a new MOD BIOS only updating the ROM modules (AHCI, RAID and LAN) and it can be flashed without problems using EZ Flash 2 tool from BIOS, I’ve done this to be sure at 100% taht the root of the problem is the CPU microcodes update process, I’ve done this at two different ways:

- First: Downloading the BIOS from ASUS webpage, update the modules and flash the BIOS file form the BIOS.
- Second: Using the dumped BIOS made with the progammer, update it with ROM modules and flash the BIOS file from the BIOS.

Both methods work like a charm using EZ Flash 2, now, we can be sure at 100% that the problem is the CPU microcode update process and not the flashing method used.

I don´t know how nobody tried this process (update CPU microcodes) at AMD ASUS non-UEFI BIOS (Legacy BIOS) before, or at least, if somebody has been able to do the process correctly, why he/she didn’t share the correct steps and order to make it possible, maybe if we will be able to do it, of course, we will share it with the community at this fantastic forum.

You’re assumption about reflashing stock is about what happens, but if between 2 years ago and now, even the same BIOS “Version” from Asus could be updated silently between then and now to allow EZ Flash to flash mod BIOS back then but blocked now.
Please lets test, take stock BIOS and do some mods to it again like you did before except no microcodes, does that now EZ Flash in or not? Or, flash in any mod BIOS you have now for a test. - great, you did this already, thanks, I didn’t see as I was replying

I agree, and dislike AFU, so I wouldn’t suggest using anyway.

As I mentioned before, we (all modders) update microcode like this all the time in similar BIOS, without issue, there is something fishy/funky going on here, usually microcode is one of the easiest things to update, especially on older BIOS.
So this is unusual case, and why you don’t see some special secret sauce guide out there, because it’s not required usually anything special other than a general “how to update microcodes” using various methods.
Normally, for BIOS like this, MMTool microcode tab works properly, in at least some MMTool version, so ucode could be updated that way or via hex/module extraction either one, and it’s usually fine.
As I mentioned, I will make some more attempts at this for you! Please wait

Ohh, and to answer some of what you mentioned at the linked BIOS post, Boot Block, EBB and Romholes are all different things.

@MiesMosel - I do see “BIOS header” data changes sometimes, is there checksum there, I can’t tell? Or maybe one in ImageInfo module? I can’t find one in the actual module that contains the microcodes either, so still at a loss here
Maybe it’s crashing/failing out due to new ucode and original old Agesa? Maybe I should build modified BIOS with all same microcodes, just switch them around and rebuild, see if issue same or not. And another, with update single ucode to one version older than current, see if same issue or not.
Do you think that would be worth testing, and maybe confirm some possible Agesa/ucode conflict, if it was working/bootable this way - then I think it could confirm this mod methods OK but ucode/agesa issue.

I have to remember you guys that this motherboard is an AMD board, we can’t use the MMTool microcode tab and other thing is the order of the modules like they are showed by MMTool when they are updated:

If I update ONLY the ROM modules, the order don’t change, but if I update (extract, edit and replace it) ONLY the E2 module, the program changes its position, I think that the problem maybe can be that we lose other dependant module that is necessary for the microcodes, I don’t know.

One last thing, to update the RAID modules, at AMD motherboard you need to replace the module itself and the MIS.SIG, and at the same time, this motherboard has two RAID modules that you’ve to update to the motherboard works well, 4392 and 4393. The MISC.SIG for RAID modules (4392 and 4393) are F0 and F1, and there aren’t problems replacing them, I want to say that the order of MISC.SIG modules don’t change when you replace them.