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.

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
BMC and BIOS updated without issue. Long and short of it is that sensors now work in both the BMC and lm-sensors (via NCT6779) but despite what the changelog says I've not found a way to disable the NIC sharing with the IPMI NIC; that's still only showing up as bond0 for me.

If you're looking at the temps in the BIOS, yeah I also saw a high temperature and vCPU set at 1.46V - I think these are their failsafe defaults since I don't think any power-saving is turned on inthe BIOS. Once booted, ipmitool sensor is showing CPU temp as 35 degrees and vCPU is 0.9V.

The only changes I've made in the BIOS so far is disabling PBO.
 

chithanh

New Member
Aug 12, 2019
2
0
1
About updating the UEFI via BMC, does anyone know (or tried) whether the update is possible if no CPU or an unsupported CPU is installed?

I'm currently eyeing a 3900X/X470D4U setup. ASRock updated the CPU QVL for the X470D4U but unfortunately the 3900X is missing. I wonder why. According to an Amazon review it works (with old UEFI, some issues).

I've found ASRock to make the most reliable BIOSes as far as their consumer kit goes, and their support are very linux-friendly.
My experience was the opposite. I tried contacting ASRock support about using fTPM on Linux on a consumer mobo (B350), which does not work due to what is most likely a UEFI bug. Their reply was basically, go use Windows.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
I successfully updated from 1.40 to 3.04 without a CPU or memory installed.

I hope the 3900X and 3800X are missing from the QVL because they haven't tested them yet; power delivery shouldn't be a problem as they already support the 105W 2700X.
 

Allan74

Member
May 15, 2019
132
13
18
Does the power section on that board honestly instill enough confidence in you to run greater than a 65W 6-core ?
 

Allan74

Member
May 15, 2019
132
13
18
Not that I know of, but it looks a little on the lite side compared to most desktop offerings in the power and heat dissipation portions at first glance. On paper may prove me wrong as I have no idea the quality of the components or the overall power delivery ratings.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
Most desktop boards have drastically over-built power delivery in my not-an-electrical-engineer opinion. It seems to be the go-fasta stripes of the last five years with everyone seeming to think they need 483 VRMs and an LN2 overclock in order to play FPS Du Jour VII.

This board has practically no overclocking capabilities in its design spec other than the boost mechanisms supported by AMD and thus no need to be able to provide oodles of current; there's simply no need for a huge stack of VRMs on these boards. Compare the power delivery circuitry on something like the Supermicro H11SSL series, capable of supporting the 225W TDP Epyc 7xx2 chips and yet still with less VRM bumfluffery than most desktop boards.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
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.

Edit 2020-08-31: DavidB says that the 0x4000 offset didn't work for him but an offset of 0x400 did. I'm not precisely sure why this might have happened (possibly going high enough to be out of range?) but don't be afraid of changing the offset value if needs be.
 
Last edited:
  • Like
Reactions: vcc3

trott90

New Member
Jan 27, 2018
13
0
1
48
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.
I also found this isuue on 2T version, only bond0 showed in IPMI web GUI, I think this is the reason I never got the NCIS working
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
I dare say if you ask the support bods they'll give you the same utility and instructions to fix that; I'm reluctant to post here as I'm not sure what the policy on executables is - if it's a widespread issue I hope ASRock will make it available as a FAQ entry.

Interestingly the linux bundle also contained a binary called asrripmi which appears to be a custom (statically linked?) version of ipmitool. Sadly it doesn't seem to contain any additional commands or a list of raws.
 

damienr

New Member
Nov 20, 2015
23
5
3
New Zealand
FYI - I had an issue with the newest 3.10 ROM and ESXI (6.7 build 13644319) booting. Unfortunately would hang on "Initializing Storage Stack".
Had to rollback to the 1.50 ROM.

Booting from an NVME Samsung 950 EVO.

Fortunately I'm still on a Ryzen 1700.

Had my board since close to release, and been rock solid. Running ESXI 6.7 the whole time.
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
Interestingly I've just noticed that ASRock have edited their official specs:
Code:
DIMM Size Per DIMM	ECC/UDIMM: 32GB, 16GB, 8GB
In combination with the earlier info from dmidecode and friends it looks like 32GB DIMMs are now supported (even in the QVL). If I win the lottery I'll see if anyone is selling the M391A4G43MB1-CTD Samsung 32GB UDIMMs.
 

trott90

New Member
Jan 27, 2018
13
0
1
48
Interestingly I've just noticed that ASRock have edited their official specs:
Code:
DIMM Size Per DIMM    ECC/UDIMM: 32GB, 16GB, 8GB
In combination with the earlier info from dmidecode and friends it looks like 32GB DIMMs are now supported (even in the QVL). If I win the lottery I'll see if anyone is selling the M391A4G43MB1-CTD Samsung 32GB UDIMMs.
I believ someone in level1techs confirms this board s upport 128gb ram
6000e0e85d9d1c4eb020102502ce5975ea4878f5.png
 

trott90

New Member
Jan 27, 2018
13
0
1
48
Interestingly I've just noticed that ASRock have edited their official specs:
Code:
DIMM Size Per DIMM    ECC/UDIMM: 32GB, 16GB, 8GB
In combination with the earlier info from dmidecode and friends it looks like 32GB DIMMs are now supported (even in the QVL). If I win the lottery I'll see if anyone is selling the M391A4G43MB1-CTD Samsung 32GB UDIMMs.
I found out M391A4G43MB1-CTDQ showed on taobao, I will order 4 of them and try this weekend
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
I found out M391A4G43MB1-CTDQ showed on taobao, I will order 4 of them and try this weekend
From the screenshot you posted from the other thread it certainly looks like they work, as well as now being listed in the QVL. I'm waiting for them to come back in stock in the UK so I can buy a couple myself.
 

MrFlppy

Member
Jun 11, 2016
41
1
8
38
Does anybody have a contact at ASRock Rack to find out when they are including the AGESA 1003 ABB fix for the RDRAND issue? Sucks that you cannot boot ESXi 6.7 U3 or Fedora 30 on an X470D4U if you are using a Ryzen 3000 CPU.
 

damienr

New Member
Nov 20, 2015
23
5
3
New Zealand
Does anybody have a contact at ASRock Rack to find out when they are including the AGESA 1003 ABB fix for the RDRAND issue? Sucks that you cannot boot ESXi 6.7 U3 or Fedora 30 on an X470D4U if you are using a Ryzen 3000 CPU.
Do you mind sharing your source of knowledge on that issue? Previously I stated an issue with ESXI once I updated the BIOS - and had to rollback. I'm now on 6.7.0U3 still without issue on that previous BIOS.
Note I'm also on the first generation Ryzen 1700; so perhaps not limited to Zen2...
 

EffrafaxOfWug

Radioactive Member
Feb 12, 2015
1,394
511
113
It's basically a bug between the Ryzen 3000 CPUs and the then-current AGESA firmware. Most linux distros using systemd were bitten by it, since systemd is wants cryptographically secure GUIDs at boot and uses an instruction called RDRAND to do it; out of the gate, the Zen 2 chips were returning garbage data back from the RDRAND instruction. The same bug is what stopped Destiny 2 running on windows. ESX 6.7u3 also has a similar requirement for RDRAND.

Since I think ESX PSODs fairly early on, even a userspace microcode load won't work around it and as such a new BIOS and AGESA code is needed.

I'm not aware of the bug affecting earlier CPUs though so I suspect you ran into a different issue.