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.

Zitat von Phoenix48 im Beitrag #213

---

@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.

---

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.

@rainworx

No, the latest Bios mod is v7 and can be found in the post #152

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.

Thanks Phoenix48 just wanted to be sure that there wasn't an underlying reason for the FAT32. And actually Rufus 1.14 and 2.11 do have the exFAT & UDF options but I've been using NTFS with v3.5 since it came out with no difficulties. I'm going to use the v7 Mod with an Intel 660p 1TB NVMe and I'll post my results.

I only use a single GFX card so would it make any difference if I used the 2nd PCIe X16 slot or should I just stick with the bottom PCIe X4 slot? In post #6 I noticed that Transcend used his 2nd PCIe X16 slot with success just wondering if there is any speed advantage or are we limited here by the PCIe 2.0 slots? Stickmode also mentions in post #7 that if he had the slot available he would have used the 2nd PCIe X16.

@rainworx

I can't answer that precisely because i don't know how many things you have plugged into your slots and how many lanes each of your devices needs. But i can explain how to find that out by yourself.

Here is what you need to know (and i strongly suggest for this that you download and look at the same time at the PCIe diagram in the motherboard manual in page 6 of the chapter 1):

- The specs for the 990FX chip (who controls PCIe) allow control for 3 x PCIe 2.0 x16 slot and can control these 3 slots in dual x16 or x16/x8/x8. Those are from top to bottom BUT NOT IN THAT ORDER. This means the following (check the manual's diagram):

1- PCIe 2.0 x16_1 (where _1 means the first x16 slot from the top) can do only x16 speed max not matter what.
2- PCIe 2.0 x16_2 can ONLY do x8 speed max no matter what.
3- PCIe 2.0 x16_3 can do x16 speed max ONLY IF nothing is plugged in PCIe 2.0 x16_2, otherwise it will only work at x8 speed max (this is where the x16/x8/x8 comes from)

- The 990FX controls the slots from top to bottom as far as communication distance is concerned. It is the time it takes for a slot and the chip to talk between them. This is a very minor influence on speed but it exist nonetheless. It means that for 2 slots of equal speed, the one closest to the top is always very slightly faster to respond than the other. This is the reason why everyone always says to put the main video card on top when possible.

With theses infos, you have all you need to plug all your devices accordingly to maximize their speed.

Ok...flashed the BIOS from flashback with ver. 7 Mod - no problem, booted into BIOS and checked that the system seen my NVMe as PATA SS [check] then changed the settings as per Stickmodes #8 post [saved/shutdown], plugged in my Win10 USB and powered up into BIOS checked settings and rebooted. I get this message:

"The system found unauthorized changes on the firmware, operating system or UEFI drivers. Press [N] to run the next boot device, or enter directly into BIOS Setup if there are no other boot devices installed. Go to BIOS Setup>Advanced>Boot and change the current boot device into other secured boot devices."

So kind of at a loss as to why it won't boot my Win10 USB setup as per Stickmodes instructions (GPT - UEFI) other than changed the Rufus setting "File System" to NTFS instead of the FAT32 (actually Rufus 3.5 does this automatically) but I can't see why this would matter, shouldn't. I checked all the BIOS USB settings and they are all Enabled and present so nothing there. I'm also using only the onboard USB ports.

Any ideas?

[Edit] - When I boot Win10 USB then get the above message, I return to BIOS Setup and I can clearly see my Win10 USB in "Boot Option #1" and in "Boot Override" no issues there.
- I also tried a new Win10 USB using Fat32 but it won't do it because of FAT32's 4GB limitation....Win10 1809 is 5.262GB.

@rainworx

I am not sure, but i think it is because you seems to try to put your USB key as primary disk in the Bios. Only the disk you want to install Windows into should be listed as primary in the Bios.

Usually, you access your Windows USB key by pressing F8 at startup and chosing your USB key (with UEFI) in the list that appear. This will start your Windows installation from your USB key and install it into your primary disk listed in your Bios.