And so it begins... First AMD Ryzen AM4 server motherboard.

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

nickf1227

Active Member
Sep 23, 2015
197
128
43
33
To all of my friends who want to use the stock cooler--

It is possible with a little...persuasion....to save you the $40 on another cooler.

The shroud pops off easily. Then you do some not-so-precision cutting of the frame and viola:
Been stable like this since December.

IMG_20200603_225656.jpg


IMG_20200603_225711.jpg
 

Attachments

  • Like
Reactions: nasi and TXAG26

DavidB

Member
Aug 31, 2018
60
19
8
I got an RMA replacement for this board but the new one has the CPU cooler backplate glued on. Anyone else have this on their board and tried to remove it with some hot air?
 

DavidB

Member
Aug 31, 2018
60
19
8
@EffrafaxOfWug Looking at the website, they still haven't published any newer BIOS/BMC than 3.20 and 1.6 respectively.
I imagine you procured from them direct via an open dialog re: your issues?

I'm not in a rush to update -- it has been stable with the exception of one issue that turned out to be a deteriorating NVMe drive.
I rolled back to 1.50 from 3.20 after storage-related issues prevented ESXI boot (iirc config) -- probably could have persevered with a BIOS tweak, but will just wait for the next published BIOS/BMC updates.
Version 3.30 is posted since last year. The boot issue that you're referring to is actually caused by an update to the CSM module that allows for older OSes to boot. Disabling the CSM module will fix the ESXi boot issue.
 

Egbert

New Member
May 6, 2012
9
2
3
I couldn't find a way to automate the update of the IPMI certificate for an ASRock Rack motherboard (specifically this one), so I wrote my own script:
asrock_ipmi_cert_updater

It took way longer to write the script than it would have taken me to manually update the certificate, even at a rate of every 3 months for a Let's Encrypt certificate, but it was the principle of the matter. :) Hopefully this will be useful to others who don't use the provided self-signed certificate.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
hello, can you use an Optane H10 m.2 drive as a boot drive with Ryzen?
I don't see why not; although not really an optane, the H10 is a relatively standard NVME drive and should work everywhere as far as I'm aware. I'm booting my X470D4U off two Intel P4101s in RAID1.
 

masimus

New Member
Aug 11, 2019
7
1
3
Hello!

I obtains this board a couple of days ago and have experienced some problems. Maybe you can point me in a good direction for trouble shooting :)

The board is to be deployed for my SOHO. It is now equipped with a 3950X, 4x32GB Samsung ECC UDIMM and a single SATA SSD (Samsung 863) for evaluation.

The problem is that at random times get assertions visible in BMC interface, that VCCM is (way!) above threshold. See pic 1. I have not found a general pattern when this occurs, but I have a hunch that is is normally tripped after a POST/Boot... A few minutes after the assertion, the system goes to a complete locked up state. See pic 2. Now the BMC cannot over see/read most of the sensors? Board will also not POST.

What voltage is VCCM? And why does it "jump" to an unreasonable high level?

In order to make sure that it is not the 3950X that is "too much" for the board, I have disabled PBO and Core Boost completely. After doing this, when I stress all CPU cores - it never goes above 55 degrees celsius (no watt meter handy to confirm actual power load). But the assertions does not generally appear to trigger during load, it can equally as well happen after long idle periods.

To get out of the locked state, I at one time left computer powered off over night - no problem for quite a while morning after. At one time I did a BIOS "reload" (upgrade to same firmware version but cleared settings) from BMC - which seemed to fix it atm as well. The board was delivered with FW 3.30 and BMC 1.90.00.

Thanks!

--- EDIT ---
I just had the problem again, while writing this post. Had the system powered down for approx 30 minutes. After power on, it appears to work fine again (until lock up happens next time :-/)... The VCCM reading is now 1.19V and I see that the Critical and Non-recovery levels are set to 1.32 and 1.38 respectively.
 

Attachments

Last edited:

DavidB

Member
Aug 31, 2018
60
19
8
Hello!

I obtains this board a couple of days ago and have experienced some problems. Maybe you can point me in a good direction for trouble shooting :)

The board is to be deployed for my SOHO. It is now equipped with a 3950X, 4x32GB Samsung ECC UDIMM and a single SATA SSD (Samsung 863) for evaluation.

The problem is that at random times get assertions visible in BMC interface, that VCCM is (way!) above threshold. See pic 1. I have not found a general pattern when this occurs, but I have a hunch that is is normally tripped after a POST/Boot... A few minutes after the assertion, the system goes to a complete locked up state. See pic 2. Now the BMC cannot over see/read most of the sensors? Board will also not POST.

What voltage is VCCM? And why does it "jump" to an unreasonable high level?

In order to make sure that it is not the 3950X that is "too much" for the board, I have disabled PBO and Core Boost completely. After doing this, when I stress all CPU cores - it never goes above 55 degrees celsius (no watt meter handy to confirm actual power load). But the assertions does not generally appear to trigger during load, it can equally as well happen after long idle periods.

To get out of the locked state, I at one time left computer powered off over night - no problem for quite a while morning after. At one time I did a BIOS "reload" (upgrade to same firmware version but cleared settings) from BMC - which seemed to fix it atm as well. The board was delivered with FW 3.30 and BMC 1.90.00.

Thanks!

--- EDIT ---
I just had the problem again, while writing this post. Had the system powered down for approx 30 minutes. After power on, it appears to work fine again (until lock up happens next time :-/)... The VCCM reading is now 1.19V and I see that the Critical and Non-recovery levels are set to 1.32 and 1.38 respectively.
I had this exact same problem and RMAed the board. Seems to be a common problem with the first batch of boards as Asrock support commented to RMA right away. You have a first production cycle board given the BMC/FW version. If you depend on a removable backplate you're pretty much out of luck as newer revisions have the black backplate glued on.
 

trott90

New Member
Jan 27, 2018
13
0
1
48
Rather annoying ASRock haven't provided a FAQ entry with a direct download TBH. Usual disclaimers apply about trusting binaries from random internet dudes.

The forum only accepts .zip files it seems and they must be <1MB so I've only been able to include the linux one by omitting the bundled asrripmi binary. I've included the asrripmi binary as a separate file in .xz format to get it small enough, with a fake .zip extension to fool the forum. It was originally included in the same directory as the BMCMAC binary.
I used the dos version and use the command: s_bmcmac u=0x4000, and it told me ok and kvm disconnected, but after reboot, nothing changes
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
I've not used the DOS version myself, but according to the doco the command line is meant to be:
Code:
S_BMCMAC.exe 0={MAC address}
...where in my case the MAC started with D0:50:99.
Incidentally, in case no-one's noticed yet, ASRR has started posting their beta firmwares and BIOS v3.37 for the X470D4U has been made available here which includes the latest 1.0.0.6 combo AGESA. Haven't tested it myself yet.
 

fridgespacer

New Member
Feb 27, 2019
12
6
3
I thought I'd read some problems with pci passthrough and 3.30 on level1techs. Maybe it was specific to KVM. I'll give it a shot.
 

nickf1227

Active Member
Sep 23, 2015
197
128
43
33
I do it all in VMWare so maybe that's the difference? But I pass a GTX1650 Ti to a windows guest just fine
 

DavidB

Member
Aug 31, 2018
60
19
8
The issue I've had with being unable to use only the dedicated IPMI interface for IPMI duties is now fixed.

I opened a support ticket and ASRock support sent me a CLI utility (DOS and linux versions) to set a MAC address; it seems that whilst one was set for the IPMI NIC, one *wasn't* set for the NCSI counterpart - their utility showed it to be all zeroes. I guess this is a known problem.

I copied the linux util into my test install image and ran the following command; the hex is an offset value added to the current MAC, so if your existing IPMI MAC is 12:34:56:78:90:ab
Code:
./BMCMAC u=0x40000
...your new MAC for the secondary would be 12:34:56:7C:90:AB.

This reprogrammed the secondary MAC with an offset based on the first (I dare say you could set any offset that made sense but I based this on one of the examples used in one of their text files). After this was set and the BMC rebooted, there are now two interfaces visible (eth0 and eth1) in both the BIOS and the IPMI web GUI instead of the one interface there was before (bond0). eth0 corresponds to the dedicated IPMI NIC, eth1 to the NCSI interface.

Fixing this has also fixed ssh running on the IPMI interface, although I've not found out how to do anything useful in it just yet.
for those coming to this thread and seeing a big FAIL when executing the above command, the offset posted has a 0 too many.
Windows:
Code:
BMCMAC.EXE u=0x4000
Linux:
Code:
BMCMAC u=0x4000
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
for those coming to this thread and seeing a big FAIL when executing the above command, the offset posted has a 0 too many.
Odd - the value was taken directly from the included ProgramMac.sh "script" which used this offset. Pretty sure I used the same value myself;
ProgramMac.sh said:
sudo ./BMCMAC u=0x40000
I assume this didn't work for you but 0x400 did? I wonder if your MAC was already at the "high" range and 4000 was enough to make it overflow or something.

I've edited my original post with a proviso just in case.
 

DavidB

Member
Aug 31, 2018
60
19
8
Odd - the value was taken directly from the included ProgramMac.sh "script" which used this offset. Pretty sure I used the same value myself;

I assume this didn't work for you but 0x400 did? I wonder if your MAC was already at the "high" range and 4000 was enough to make it overflow or something.

I've edited my original post with a proviso just in case.
When using 0x40000 the S_BMCMAC.EXE just gives you "allowable value out of range" and doesn't even enumerate the MAC addresses you already have hence I guess that you just had a 0 too many
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
It could be that your MAC already had its fourth octet at or near the max value for hex and wouldn't overflow. For instance if it was already FF you wouldn't be able to increase it any further, and likely the ASR BMC doesn't allow it to overflow in to other values.

Changing the offset to 0x400, 0x4000, or any other value really, just changes the place where the increase happens; to use my earlier example:
12:34:56:78:90:ab + 0x4000 = 12:34:56:7C:90:AB
12:34:56:78:90:ab + 0x400 = 12:34:56:78:94:AB
12:34:56:78:90:ab + 0x40 = 12:34:56:78:90:EB

If we start off with a MAC where the final octet is FE and add 0x40 to it, we can see if overflows in to the previous octet. I suspect that's where the ASRR util is falling over.
12:34:56:78:90:ab + 0x40 = 12:34:56:78:91:3E