Sick & Tired of ASRock X870E Nova !!!!

This board has brought me nothing but trouble!
see here:
https://forum.asrock.com/forum_posts.asp?TID=104532
and or here:
https://www.reddit.com/r/ASRock/comments/1jurebn/asrock_x870e_nova_disk_interaction_extremely_slow/?rdt=34096

I can not find a solution for the on going POST & drive access problem!
(the Ethernet slowness has yet to be mentioned or addressed)
I have received no ASRock Rep replies from my repeated posts and emails. (this, from my research, is not the usual procedure from ASRock, why no response?)
But this is a cutting edge board. I would expect some teething issues, but this has been going on far too long from launch.
My board is out of 'return' period, and having registering it with ASRock, I get nothing.
Anyone out there have some suggestions about what to do next ?

Based on your comments in the Reddit post, I am wondering if there is an issue with either the BIOS retaining settings, or the CLRCMOS jumper or button having an issue.

First: Power off your system completely and turn off the switch on the power supply or pull the plug from the mains/wall socket, whichever is easier.

1. Double check the BIOS CR2032 battery (round silver disc battery) is properly seated, if so, then remove it to check for any plastic sticker or sheet that may be blocking contact with the battery socket pad/pin. I have had this issue before where the battery still had the protective sheet under it to block contact with the socket. I've also had batteries that had weak charge arrive in new mobos, it happens. After removing the battery, check the bottom of the battery and that there is nothing covering it, then check in the socket that the pin or pad is not covered or blocked in any way. Re-seat the battery.

2.Check that Jumper #19 (CLRCMOS1) jumper pins are not shorted/jumped, there should be bare pins without a jumper there. If there is a jumper on these pins, remove it and save it somewhere safe. If there was a jumper here, your board would boot into a fresh startup/setup sequence in BIOS every time, and no settings would be saved.

3. Double check that the CLEAR-CMOS BUTTON on the rear of the motherboard on the I/O block in the upper left of it, there are two square buttons: one that says BIOS FLASHBACK, and one that says CMOS with a rounded arrow on it. Press the CMOS button about 10 times, firmly pressing it fully in and making sure it pops out/back normally each time, this is a momentary switch, and it should not feel "stuck" or slow in any way. If there is a short or problem with this switch, it could also be causing the behavior you described in your Reddit post.

4. Plug your power supply back into the wall/mains socket and turn on the PSU power switch next to the cord inlet. Wait approximately 15 seconds or so before pressing the power button. Turn on the system with the power button after waiting, and now wait for the system to POST, it will still take a while as it is your "first" boot from the system's viewpoint as we've cleared all settings. Enter the BIOS immediately when able to/prompted. Apply optimized default settings, and then exit, saving the changes. Allow the system to reboot, it will probably still take a good hot minute but shouldn't be as long as the first one. It may immediately reboot after the splash screen/logo screen if Secure Boot is configuring, this is normal, and should be a quick reboot, not a long one, if it is, note that. Now you should be booting to windows, it may or may not take a hot moment if windows needs to enumerate everything allover again or if any addressing/things changed in DMI/ACPI/APIC/PCIe tables etc., as this can happen when clearing all settings in the fashion we did. Once windows boots, let it sit for about 10 minutes, this is to ensure that any remaining hardware and drivers are installed and setup without interruption, should it be necessary. Now shutdown windows from the power menu.

5. Once the power is off, wait about 15 seconds. Now press the power button to turn the system on, the boot should be more in a normal time frame, and windows load should not be taking forever at this point.

If you are still having issues, then I'm afraid something is either wrong with the NVRAM for the BIOS/DMI or the BIOS itself. Have you tried re-flashing your BIOS? It could be corrupted. Follow the steps provided from the Nova's motherboard BIOS support page (or below) for re-flashing using the FLASHBACK method.

1. Start by downloading the latest BIOS revision zip file, extracting the zip and copying the BIOS ROM or CAP file inside the folder to a FAT32 formatted USB drive into its root directory and renaming the copied file to CREATIVE.ROM on the USB drive, in the root folder/directory (meaning place it directly in the drive, not into a folder on the drive.)

2. Shutdown Windows. Ensure the USB drive with the ROM image is plugged into the Flashback USB Port, which on the Nova is the USB-A port in the middle between the Ethernet Port, and the USB-C port on the bottom of that stack. That is to say, the USB-A port directly below the Ethernet Port. Press the BIOS FLASHBACK square button in the upper left, with the picture of the lightning bolt, it should begin flashing after a few seconds, this means it is starting to access the file and will flash the BIOS.

3. The process may take several minutes, be patient. Once completed the light should be off on the button and this indicates success. If it is solid then some issue has occurred and you may wish to try again, or double check you have named the file correctly and placed it in the root of the USB, and that the USB drive is plugged into the correct port. If after another attempt it is unsuccessful, you may have an issue with the BIOS, contact support and share your findings.

4. If successful, you will have to go through a couple boots but then the problem should be gone, as you will again have a "first power up" situation after the reflash, but after that and a couple quick subsequent reboots, it should normalize, if not, please contact support.

If none of the above are successful in solving the issue, or if the Flashback process does not work correctly, contact Support and share your findings.

Hope this helps!

-Spikeypup

You are so very welcome, sorry for the delay in my reply...

Also, thank you so much for your detailed reply! Great observations and reporting!

Originally, I was thinking that the BIOS was not saving it's settings either due to no battery or low 3.5v rail for the BIOS NVRAM, bad BIOS NVRAM or bad BIOS image etc., or caused by either the battery or by the switch being shorted or the pins; since you have replied back with information that indicates you should be ok on this front and we can probably eliminate this (after you flash the BIOS we'll know for sure), it now leaves me wondering...

First, please do flash the system ASAP and before trying anything else below to eliminate the possibility of a corrupt BIOS image and ensure we are on good ground. Please report back how long the flash takes, if it takes more than 15-20 minutes, definitely note that. Sorry I misnamed the Defaul BIOS Setting option, you were right it was the Load UEFI BIOS Defaults. Jumper 19 is indeed CLRCMOS1, so you were right there as well. As for the battery, we can see if there is plastic underneath by checking the VBAT/VBATT reading in HWINFO64 is at 3.3V-3.55V (Please download HWINFO64 portable for this and some things below), if it is weaker or if it is zero, then we know there is a plastic guard under there and we can eliminate or confirm this as an issue then.

Secondly, some further diagnositcs, and a hunch:

Have you tried removing all USB devices from your rig except for keyboard and mouse? Are you using anything external that is storage or storage dock related? This sounds like a USB enumeration or other USB type comm issue. The temperatures you reported are within spec and range, so no worries there. Please ensure all USB header connections are locked in tight and secure to the motherboard...

Since you have replaced everything, including I am guessing the MOBO and this problem is persisting, there is a deeper compatibility problem or fault going on. And one that keeps carrying over, which usually means your Storage devices or USB devices...so let's walk this angle.

To ensure that there is proper operation, voltages need to be observed to be within range and stable. Can you use HWINFO64 to generate a view of your voltages and system, as well as all the SMART data/readings from the connected drive(s)... Please upload a reply with that screenshot(s), it would really help.

I have a suspicion that it is either a USB device that is failing to enumerate properly or is hogging the buss with nonsense, so a bad controller in the device, or that one of your drives has a faulty controller and doing the same but on the NVME/PCIe bus, SATA controller(s), etc.

I experienced this before on another system of mine, different mobo brand and SATA drives only (6 of them), but one of the drives had a controller that went bad, causing the controller to be filled with nonsense garbage and causing constant interface resets (on the SATA controler and the PCIe bus it was connected to), so any device that was on that controller tree/chain had to wait enough time slices where the controller was free so it could send its requested data out to the controller, however, it has to wait until all that garbage from the controller would stop being sent to it, basically when there is a quiet moment, and then not to mention between the resets of the connected devices as well, so there is little time where the bus isn't saturated with garbage responses or commands, and isn't being reset due to that garbage...

You could see why this would cause a major storage bottleneck if you are moving data on the same bus or especially between busses, such as from the NVME PCIe bus, across to the I/O die then over to a USB controller then over USB Storage protocol to the file system then back to the USB Storage protocol layer then to the USB storage device and back (acks and such), imagine if data were being spit out to any bus/controller connected tot hat bus that was not proper or malformed, it would keep causing resets on those busses/controllers and connected device resets, in addition to the jabber traffic taking up resources on the bus/controller, the device trying to be read from or written to would be waiting 90% of the time and only able to transmit/receive the other 10%, or even worse like 97% and 3% is more like what is sounds like, and imagine if that 3% good time is only available 15% of the time due to resets etc...

Anyways, this is my hunch, and I could be totally wrong, but I hope not...

Windows is SUPPOSED to help report these things to the user, it doesn't do a great job of that unless a drive is fully failing and SMART contains the right figures to cause the alert, and even then it's during diag and data collection time only, as it isn't checking SMART data all the time... but I digress.... lol

SOOOOOOOOOOO The test for this would be:

Ensure you are using only the one O/S drive and no USB devices other than keyboard and mouse for the moment and see if it boots fine and works fine... If it does, then your other drive(s), at least one of them, is either failing or not working properly and may need a firmware update.

Now add any other internal drives, one at a time. Test the boot and function, until you get to the point where you've added a drive and it all falls apart, that is the bad drive, and could need a firmware update, or the controller is just toast. At this point then it probably isn't your USB devices, now if you add all your SATA/NVME drives and you are booting well and fine, then start the same process of testing your USB devices, add them one at a time, and test the boot process, until it goes wonky, then you found your incompatible device, and it could be for any number of reasons, if it has a removable cable, try a different one. You'd be surprised but because USB is a interface method that has connectors constantly going in and out wearing them down on both the host device and the cable, and then the cables get all bent and worn etc... you see where I'm going with this, so sometimes it's just a cable that need replacing to make the devices happy to talk to each other again, other times the controller or the PHY on the USB just blows out becuase USB power delivery is...interesting, and the device just won't recognize properly or enumerate properly anymore, or just malfunction in general.

Once I see the HWINFO64 screenshot or text paste then I can know more about what might be happening here. But it seems like either the USB issue I described with either a storage device or other device that is just not getting along, causing huge delays in enumeration and device recognition, or it's the NVME/SATA drives and one of them has a bad controller acting up...

I wish you the best of luck, looking forward to hearing back!

-Spikeypup