@empilein
I forgot to say that you must remember to rename the Bios for Flashback to work. For you motherboard, it should be renamed M5A97R20.CAP before trying to flash it.
Thanks for the response. Sorry if I seemed upset. I appreciate everything you guys are doing. I obviously didn’t read enough, because even though I’m the exception, (as happens frequently to me when the exception is going to complicate my life) I should have taken more precautions prior to flashing. I did a dump, which now freezes right after dumping the first chip… but the hex shows 2104B_RCF which represents 1042A.
So it appears I did in fact crossflash. But I haven’t lost the use of any ports or functionality, as of yet.
I’m at the outer length of my understanding here, so any suggestions would be appreciated.
I’m thinking about using flashback with the earliest Asus bios and clearing cmos then seeing what it reads in DOS mode and the dump, in the hopes it triggers it to fallback to original firmware.
*Unless I am misunderstanding. The hex of the dump shows 2104B, but also says 2104B_FW. So does that mean I have 1042A chip with 1042A FW, or 1042 chip with 1042A FW?? The visual inspection of the chips show 1042 regardless.
did that and your last mod is working fine. only it doesnt show the harddisks under Sata settings in UEFI anymore. Under Boot tab i can select the SSD with Windows Boot Manager fine
i even benched on my samsung 840 evo before with 509mb/s and with new AHCI modul it has 522MB/s real nice 
@fr0tch
If your original dump file that was done before your first flash attempt shows 2104B, this means you have a 1042A firmware originally and, since it was working, it doesn’t really matter what is written on the chipset. It is another well known fact among many peoples who got burned by flashing the wrong firmware in a 1042(A) chip by only trusting according what is written on it. Why? Because it was discovered that way that there are chips that are identified as 1042 who work with the 1042A firmware and vice versa. Not many. But it happened to some peoples. Just don’t ask me why this happened and why some chips were made that way and not identified correctly… The point being that because of that, the original firmware in a chip is by far more trustworthy to say what a chip really is rather than what is written on it.
So since your dump of the original firmware says 2104B, it is a safe bet to say you probably have a 1042A chipset identified as 1042 written on it. So a 1042A firmware is the best bet to correct the problem since the original was the same.
Be warned that i say all this assuming that your dump file was made BEFORE your first flash attempt. If it was made after, then all bets are off and it is a guessing game now.
As for playing with the Bios to reset the chipset, i am sorry to say that nothing in the Bios will touch the firmware in the chipset even if you reflash it. And it is not related to flashback or the CMOS either. The chipset is completely independent and must be flash independently.
@Pheonix48
I wish I could say it was from the original fw, but it is not. That’s the current state of the backup. But, you have helped save me a bunch of time by explaining the disassociation of the chipset from the bios, in that I at least can focus there. Any suggestions on what method might be more effective? The DOS flash or the Windows Asmedia FWUpdater? Both have said succeeded at attempting, but clearly neither has functionally. I never tried flashing 1042 at first, but it’s fuzzy as to whether I noticed the issue under which condition. I did attempt to flash once before, but was rushed due to circumstances and was never able to check if it stuck. I DO know, that I didn’t realize at that time there was a 1042 and 1042A firmware difference, because the drivers from Asmedia didn’t differentiate or draw any attention to it. But I obviously didn’t do enough research the first time. So I’m at a loss for how to attempt fixing the issue. Ultimately there may be nothing I can do but live with it, but you know I’m going to try to rectify the problem. But in the interest of being reasonable, I’ll stop when the motherboard explodes in my face in a fiery hell or I throw it out the window.
And yes, after it hits the ground, I’d obviously still try booting one last time to see if that helped to fix the firmware issue.
Although, if the fiery hell thing happens, and my renters insurance covers the replacement of the motherboard… problem solved. At least where the motherboard is concerned.
Me… can’t be fixed.
@fr0tch
When you have a choice between flashing something within DOS or within Windows, ALWAYS, really, always chose to go the DOS way. It is by far the safest and the more direct aproach because nothing is in the middle of the process (like Windows and anything installed in it) that can mess things up between the original command to the flash itself. Imagine flashing a USB chip that control the USB ports while something else on the PC decide to try to access those same USB ports… Or another software or program in Windows that decide to prioritise or use the ressources needed to do the flash… There is always the hope that Windows can manage all those situations well but it is often just that: Hope. Hope with often bad results. Those situations can not happen in DOS. It is just a few example of why Windows should never be used to flash anything unless there is absolutely no other choice available. More often than not, the only reason that a Windows option exist to the customers is because many can’t do it in DOS, they just don’t know how. So to those peoples, Windows is the easier way even if it is also the riskier way.
@Pheonix48
Oh I agree 100 percent. That is always my go to method. I love using DOS for flashing.
But being this is a somewhat unique instance, sometimes the less obvious approach works. And sometimes what seems less obvious to the limited of knowledge, is in fact the obvious choice to the more knowledgeable. If that makes sense.
I just want to have all the options to consider, at the very least, before narrowing it down to the path I choose to go down… fall down… whichever.
Would the OptionROM offer any chances here at getting this right? Isn’t legacy more direct, as long as you make sure you have the right one? Or is that just for telling it the type of device to call from, and not so much the actual chip condititions?
@fr0tch
I think you need to understand how and where each component is and what it is related to. So here are some definitions and explications to try to explain it:
BIOS: That word is 2 things the little program that controls the startup of the PC that everyone knows about, but it is also how you refer and name the chip on the motherboard that the Bios (the software/firmware) is flashed into.
EFI ROM/module: One of many module in a modern Bios that control something in a UEFI Bios. Like the NVMe module that enable a NVMe drive.
Option ROM/PCI ROM: The same as the last but not EFI, rather legacy like before UEFI was invented. It can go into an old non-EFI/legacy Bios or can be put in the CSMCORE section of a UEFI Bios which permit it to use the module even if it is not EFI.
Chip: Usually called “Something-that-say-what-is-my-function chip” like the USB chip or the sound chip. Each is an other chip, completely differrent than the BIOS chip and somewhere else on the motherboard.
Chipset: Same as a chip but there are at least 2 or more of them. For example, a USB chipset is at least 2 chips that are connected and control each differents USB ports and, because they do the same job (but with different ports), they are flashed at the same time with the same firmware when needed to.
Firmware: A little program going into a chip or chipset (like a USB chipset) or a hardware (like a HDD drive or a BlueRay/DVD/CD drive) to tell it how to behave at the core. Like a Bios in a Bios chip. But because the Bios is so much important to the PC and control so many things, no one call it that. But it is, in a way, just that: A little program in a chip.
So when a program or even the Bios speak with a chip or a hardware, it tells it what it wants and what to do, but never how to do it. It is managed by the firmware and the hardware that the firmware control. The system can tell “Read the CD in the drive and send the sound to the sound chip” But it will never manage the CD itself and tell him how to read it, or say “i have just decided that you can now read CDs written with X protocol and here is how to do it”. It is the firmware that can and know how to do that, or it doesn’t and will answer to the system “Sorry, i can’t do it”.
So a firmware update in a USB chip can correct some random USB ports disconnect issue and can sometimes increase speed but a Bios update won’t. Unless the problem was an error in the way the Bios was giving the order but that is very rare.
It is a very oversimplified way to explain them all but enough for you to see and understand why a Bios change or a option rom, which is both the same because one is a part of the other, will unfortunately not fix your problem. Only a succesfull flash with the right firmware of your USB chipset can fix it.
The way i see it, you have a 50% chance of getting it right because it is either the firmware for the 1042A that you need to flash or the one for 1042.
Now a question: The first time you tried to flash it, did the flasher asked you if you wanted to “force” the flash anyway, or the question never appeared?
Honestly, my brain is frazzled after3 days of this. The first time I attempted to flash, was actually some time ago, so I don’t actually recall what happened in any useful amount.
I do however remember doing a flash in the last couple days where I had to “force” it from the Windows environment.
Interestingly though, I just had a positive flash using the Asus USB 3.0 FW Update Tool v3.0
It flashed successfully and it shows 120816_02_02_6D now when viewed with the Asmedia Tool instead of 100803_00_00_0D, which shows some positive movement.
I think. But I’ll reserve hope for later. SSID=8488 SVID=1043 though, is that right?
I need to take a break and get something to eat, and come back in a bit, sorry.
Sorry, can’t help you there. I don’t remember what it is it is supposed to show up and i am not near that PC now so i can’t verify that. Find the thread about flashing the ASMedia USB chip in the forum around here, it is probably written somewhere in it.
I found that when I grabbed the bins from different firmwares, regardless of the description and the purported use, the hex was was showing some were saying they were 1042 firmwares, but had config files that were expecting 1042a and visa versa. No wonder there are so many issues. So I made sure I had the expected config and bin for 1042. After using the Asus USB 3.0 update. As it was updating it was taking some time for the second controller, and I immediately dove and unplugged all my usb devices, and it then continued ending in blue success bars. Everything is working right now, from what I can tell. I then used DOS to update the latest 1042, which is why I found out about the bin and cfg differences, as I had a hunch something was weird. They installed successfully with /u, and then immediately and for the first time /d showed the related changes. Then I just ran LSPI and this is what is showing:
04:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller [1b21:1042] (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. P8B WS Motherboard [1043:8488]
Flags: bus master, fast devsel, latency 0
Memory at fe600000 (64-bit, non-prefetchable)
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [68] MSI-X: Enable+ Count=8 Masked-
Capabilities: [78] Power Management version 3
Capabilities: [80] Express Legacy Endpoint, MSI 00
05:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller [1b21:1042] (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. P8B WS Motherboard [1043:8488]
Flags: bus master, fast devsel, latency 0
Memory at fe500000 (64-bit, non-prefetchable)
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [68] MSI-X: Enable+ Count=8 Masked-
Capabilities: [78] Power Management version 3
Capabilities: [80] Express Legacy Endpoint, MSI 00
06:00.0 USB controller [0c03]: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller [1b21:1042] (prog-if 30 [XHCI])
Subsystem: ASUSTeK Computer Inc. P8B WS Motherboard [1043:8488]
Flags: bus master, fast devsel, latency 0
Memory at fe400000 (64-bit, non-prefetchable)
Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
Capabilities: [68] MSI-X: Enable+ Count=8 Masked-
Capabilities: [78] Power Management version 3
Capabilities: [80] Express Legacy Endpoint, MSI 00
The ASUS USB 3.0 updater must have been intended for Intel boards. Is that an issue, or is it just labelling?
I forgot to mention in the last post that I upgraded by DOS from 120816_02_02_6D to v130125_00_02_00 successfully.
@fr0tch
I can not say if the flasher you used was made for Intel motherboard initially or not. All can say is this:
- If everything is working then it is all that matter and the rest is just labelling as you said.
- Your subsystem in your data is shown as an Asus P8B WS motherboard. But that may be just labelling also. Subsystem are usually associated to a choice of numbers (1043:8488) that you have to enter before flashing or must change in the config file before flashing. To be honest, they are mostly just labelling and almost nobody take the time to find out what should really be input there.
To be precise on that last point, almost everyone just press “enter” when given that choice on the screen by a flasher, and i don’t blame them because no flasher is clear bout that but, almost always, the default answer given by the flasher is wrong. That may explain your P8B WS showing even if you are in truth on a Formula-Z. To explain even further, the subsytem input is not even used by the chip (to my knowledge, i could be wrong), except only to pass it on to the OS (Windows) who show that data as your hardware info. The only problem i can foresee, but never saw up to date, is if one day another hardware or firmware would require that data to interract with the chip. Then it would receive partially the wrong data in the sense that the answer would be by the system: “Here is what the chip told me: I have a 1042 chipset that are functionning on an Asus P8B WS motherboard”. And the reason i said i never saw it is because it seems that no software or hardware seems to care about the second haff of the answer. At least in my experience untill now. Maybe most people are just lucky to get away with the wrong answer but the exception must exist somewhere or else that data would not need to exist.
True. I’ll keep that in mind going forward. At the very least it taught me the importance of proper preliminary prep before flashing regardless of whether or not I think it’ll be needed. Something about the gambler in me, but its definitely a voice that I can shut up. Especially when considering expensive repercussions. New MB= new ram type and cpu socket as well.
Thanks for all the support through quick responses and expanding my knowledge on the subject, all voluntarily. It’s much appreciated. Now I’m seeing if I can get my 2nd pci-e x16 slot to run my second gtx970 @ x16 as well. The 890 PCIe configuration is a whole new area of exploration. Here come’s a bunch of reading and sorting out the misinformation from the opinion and theory from the legitimate and useful.
I will return to this issue to attempt to get everything labelled properly so everything gets called out and reported as it should, but I need a change of pace.
Genuine thanks Phoenix again for the help here, and for the motherboard BIOS versions and MODz that keep this rig flying:
MB: Asus Crosshair V Formula Z (2201 v7 mod w/890 PCIe Config)
CPU: AMD FX8350 Black Ed. @4.6
COOLING: CM MasterLiquid ML240L RGB
RAM: g.skill 32GB (8Gbx4)PC3-19200 2400MHz Trident X Series CL10 (10-12-12-31)
GPUs: 2xMSI 970GTX Gaming Ed in SLI
MONITORS: 3x Samsung S24D390
SOUND: Sound Blaster Z
KB: Logitech Orion Spark G910
MOUSE: Corsair M65 White, w/ Razer Firefly Hardpad Chroma
STORAGE (all SSD): Samsung 960Evo M.2 250G, Kingston V500 240G in the "X-Dock", Samsung 840 240G, Mushkin 1TB, Mushkin 240G
PS: NZXT 1000W White
CASE: CM Stryker Full White
I have a Z board - am I correct in assuming that the best BIOS Mod is now the Ultimate MOD?
[Edit] I recommend to anyone about to attempt this BIOS mod to read this thread from front to back…you need to do this to get all the relevant data.
Thanks to Stickmode, Phoenix48 and all the other thread contributors.
Is there anything else that can be upgraded ?!
@jprince1975
If you ask in the Bios itself, the official answer is no, because anything that can be upraded are already to the latest. The unofficial answer is the AMD AGESA module could probably be upgraded to the latest too but that seems to require to modify the code of the latest AGESA module to adapt it to this motherboard and this would require some serious skills from someone who really know what he is doing. Not many people can do that. I tried many times in many differrent ways to adapt it to the Formula (non-Z), which is practicly the same as the Z version, and i always failed by ending up with a different bug that showed up depending on the modifications i had done to try to adapt it. Some exemples are: Overclock stopped working, Cool & Quiet stopped working, amount of memory not reported correctly, AMD Catalyst program not reporting the video cards specs correctly, and in the worst case, random BSOD. So i repeat it: In theory, the answer in yes, but in practice, the answer is no.
If you ask outside of the Bios then yes, there is the firmware of the USB ASMedia chipset that can be upgraded separately.
I was looking at Stickmodes’ photos in post #8 regarding the configuration of Rufus for the Win10 bootable USB and I’m not clear on the setting for the File System (FAT32), on my other Rufus USB’s for 8, 8.1 & 10 I’ve always used NTFS for this setting to keep it the same as the O.S. primary boot drive (SSD or other) that I’m using. Wouldn’t this apply using the NVMe SSD also, or is there a specific reason for the Fat32 setting?
[Edit] When using Rufus v3.5 it automatically selects the NTFS setting so, just want to be sure I’m not missing something or if I should use Rufus v2.11 instead.
@rainworx
You can use NTFS if it is working for you and is probably the best for a Windows install. The only reason most people suggest FAT32 is only for compatibility and, very rarely, for space. Because older motherboards with older legacy Bios don’t alway recognize NTFS (newer) but are sure to recognize FAT32 (older). Also, in very rare case, formating in FAT32 makes the differrence between being able or not to put in your USB key what you want. The reason is because less space is lost in formating with FAT32 than with NTFS.
On a side note, the ideal format for most USB key would usually be exFAT (the successor of FAT32 who itself replaced FAT) but Rufus don’t have that choice.