Prebuilt [SFFn] ASRock's DeskMini A300 - Finally!

[GLSRacer]

@ConsolidatedResults I haven't had any reason to check my temperature settings beyond the one time I ran stress testing in Fedora 32. Temps were fine under load at that time and I've had no reason to check the server temps now that I'm running Win 2012 R2 on my 2400G equipped A300W. There may be a problem with one of your sensors which could be a warranty fix. Hopefully someone who has had an issue with temps can chime in

 

[ConsolidatedResults]

@GLSRacer thanks for your sharing your experiences, much appreciated! If you are running as a server I would not expect much GPU load to be seen by you and thus no issues either.

On the temp issue, I have just breadboarded the thing and have applied the latest in precision temperature measurement equipment (my right index and middle fingers) and spot cooling solutions (blowing on stuff). I have come to the conclusion that the Nuvoton sensor on the A300 labeled "CPU" must be reading SOC VRM temps, or somewhere really close to that area of the board.

First I removed the VRM heatsink and fired up a CPU stresstest while observing the sensor readings. CPU internal sensor went up as expected and Nuvoton CPU sensor stayed almost flat as expected. The 3 MOSFETS that supply CPU core voltage got very warm to the touch but not to the point of being painfully hot.

I then used furmark to perform the same check for GPU. While GPU internal sensor did climb slowly, the Nuvoton "CPU" sensor hit 50°C almost immediately and only went up from there, I tested up to 72°C reading. The SOC VRM MOSFETS got increasingly hot to the touch to the point where leaving the fingers on for a couple seconds got painfully hot. Blowing on the SOC VRM area at this point did cause the sensor reading to drop almost 10°C. Blowing anywhere else onto the board (CPU VRM, around the socket, around the RAM etc.) would not cause a drop in temperature.

Lastly I remounted the VRM heatsink and ran Furmark again. The same sensor that easily hit 72°C previously appeared to settle into steady state at around 62°C, further supporting that the temp reading is VRM related.

So yeah, still not quite sure what to make of it. I may have had a bad mount with the VRM heatsink. Or i may have a bad batch of SOC VRM MOSFETS. Or this is just normal, even though I don't think 90°C on VRMs is great. I'll have to put it back into the case to see if it has changed, the delta between GPU temp and "CPU" sensor temp was only 20°C without case after remounting the VRM cooler, that is 10°C less delta than before.

Generally thermals outside of the case are soooo good by the way.

I would still love to hear anyone elses observations (also on the SOC voltage thing, I will do more tests there as well).

 

[officeplant]

First post here, just jumped back on the SFF train and picked up an A300 off newegg. I used to run a skylake SFF box mounted on the back of my monitor and I missed that kind of space savings.

Full build:
Athlon 3000G
2 x 8GB 2666 Hynix OEM HP memory I already had (HMA81GS6JJR8N-VKN0)
500GB 7200RPM WD Blue drive I had lying around
2TB WD Drive
256GB Samsung 970 EVO

Everything worked out of the box with 3.5 Bios. Updated to 3.6 but I'm not sure its making any differences in my case. It's been a lovely little box so far with a spare Wraith Stealth cooler I had from a previous build I sold. Stays under 60C even while gaming and doesn't make a sound.

Contemplating picking up a used 3400G locally for $110 but I'm not sure its worth it vs waiting to see what happens in the APU space in the next 7 months especially since the 8c/16t mobile part announcements. Posts here have me thinking I should wait for something with a little less power draw if I can get a 4c/8t part with the same thermals and power draw as the 3000G in 7 months that would be perfect.

<screenshot of HWiNFO64 after stress testing>

 

[Valantar]

@GLSRacer thanks for your sharing your experiences, much appreciated! If you are running as a server I would not expect much GPU load to be seen by you and thus no issues either.

On the temp issue, I have just breadboarded the thing and have applied the latest in precision temperature measurement equipment (my right index and middle fingers) and spot cooling solutions (blowing on stuff). I have come to the conclusion that the Nuvoton sensor on the A300 labeled "CPU" must be reading SOC VRM temps, or somewhere really close to that area of the board.

First I removed the VRM heatsink and fired up a CPU stresstest while observing the sensor readings. CPU internal sensor went up as expected and Nuvoton CPU sensor stayed almost flat as expected. The 3 MOSFETS that supply CPU core voltage got very warm to the touch but not to the point of being painfully hot.

I then used furmark to perform the same check for GPU. While GPU internal sensor did climb slowly, the Nuvoton "CPU" sensor hit 50°C almost immediately and only went up from there, I tested up to 72°C reading. The SOC VRM MOSFETS got increasingly hot to the touch to the point where leaving the fingers on for a couple seconds got painfully hot. Blowing on the SOC VRM area at this point did cause the sensor reading to drop almost 10°C. Blowing anywhere else onto the board (CPU VRM, around the socket, around the RAM etc.) would not cause a drop in temperature.

Lastly I remounted the VRM heatsink and ran Furmark again. The same sensor that easily hit 72°C previously appeared to settle into steady state at around 62°C, further supporting that the temp reading is VRM related.

So yeah, still not quite sure what to make of it. I may have had a bad mount with the VRM heatsink. Or i may have a bad batch of SOC VRM MOSFETS. Or this is just normal, even though I don't think 90°C on VRMs is great. I'll have to put it back into the case to see if it has changed, the delta between GPU temp and "CPU" sensor temp was only 20°C without case after remounting the VRM cooler, that is 10°C less delta than before.

Generally thermals outside of the case are soooo good by the way.

I would still love to hear anyone elses observations (also on the SOC voltage thing, I will do more tests there as well).

I thought VRMs could handle well in excess of 100°C? I get that 90 isn't particularly good, but it certainly shouldn't be a problem. But perhaps you could do something about your CPU cooler mounting so that its fan blows more air onto the VRM heatsink?

 

[ConsolidatedResults]

<screenshot of HWiNFO64 after stress testing>

Thanks!, that 3000G with it's 3CU Vega got the sensor to 51°C. That is obviously fine by itself, not sure how it would look like for an 8CU or 11CU part.

I thought VRMs could handle well in excess of 100°C? I get that 90 isn't particularly good, but it certainly shouldn't be a problem. But perhaps you could do something about your CPU cooler mounting so that its fan blows more air onto the VRM heatsink?

Yeah, the specsheet for the particular MOSFETS in the A300 lists 125°C max as the recommended operating temperature. But it also lists that safe operating area (in terms of max current output for a given board temp) starts to take a dive at around 95°C. It really depends on a lot of factors, like the thickness of the board copper layers, whether it's horizontally or vertically mounted and so forth. I do not pretend to able to derive firm conclusions from the specsheet If there were even one or two other sample A300 owners with a 2400G / 3400G which see the same or similar temps on the sensor as me I would know that my particular unit is at least operating like everyone else's

Unfortunately the cooler mount is already as good as it gets, the VRM heatsink is aligned with the cooler fins and smack in the middle of the fan's airflow. Still have to put the unit back together (wanted to have access to the Clear CMOS jumper for some other testing) and redo all the BIOS settings to see whether remounting the VRM heatsink made any difference for the assembled unit.

 

[GLSRacer]

@ConsolidatedResults just loaded CPUID HWMonitor and TMPIN6 is running 118C which is pretty crazy. TMPIN8 is 111C. The CPU is running at 33C.

 

[ConsolidatedResults]

@GLSRacer I think one can safely ignore the sensors that always show > 100°C, they appear to be stuck on bogus values.

For CPUID HWMonitor, I think the sensors map as follows, top to bottom:

• SYSTIN: a thermal sensor somewhere in a non-thermally busy location of the A300 board. Will show between slightly above ambient right after start of cold system and say 20°C over ambient after some busy usage. This sensor is labelled "Auxilliary" in HWInfo64
• CPUTIN, TMPIN5: These show the same value, appears to be showing the temp of the board in the area where the components are that supply power to the SOC (Vega, Memory Controller, IO...) section of the CPU. It's the stuff under and next to the black heatsink on top of the board. For me the reading rises a little bit when stressing the CPU and will rise a lot when stressing the GPU. This sensor is labelled "CPU" in HWInfo64.
• TMPIN6, TMPIN8: Bogus readings I would ignore They are labelled "Motherboard" and "AUXTINX" in HWInfo64
• TMPIN7: CPU Internal temperature read from the CPU itself. Should show roughly the same as "Package (Node 0)" temperature in HWMonitor and is labelled "CPU (Tctl/Tdie)" in HWInfo64, in the CPU section.
• TEMPIN3: Stuck on 40°C for me and I ignore it. Labelled "CPU (PECI)" in HWInfo64.

So yeah, if you were to apply e.g. a graphics intensive load, like a benchmark or 3D game, I would expect the readings for CPUTIN/TMPIN5 to quickly rise. If you were to apply a load that only stresses the CPU (like the stresstest on the "Bench" tab of CPU-Z) I would expect TMPIN7 to quickly rise, but CPUTIN/TMPIN5 to rise much less and less quickly than when applying a GPU load. Again because "CPUTIN" I think is not CPU at all but the SOC voltage regulator section of the mainboard.

 

[Ziyan]

Speaking about sensors, did anyone translate the Linux sensor names to meaningful ones? Here are they by default; I didn't look much into them yet.

[root@a300 ~]# sensors
amdgpu-pci-0300
Adapter: PCI adapter
vddgfx:           N/A
vddnb:            N/A
edge:         +30.0°C  (crit = +80.0°C, hyst =  +0.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
Tdie:         +30.2°C  (high = +70.0°C)
Tctl:         +30.2°C

nct6793-isa-0290
Adapter: ISA adapter
in0:                   392.00 mV (min =  +0.00 V, max =  +1.74 V)
in1:                     1.85 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in2:                     3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in3:                     3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in4:                   248.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in5:                   128.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in6:                   872.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in7:                     3.39 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in8:                     3.23 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in9:                     1.83 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in10:                  176.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in11:                  128.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
in12:                    1.85 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in13:                    1.70 V  (min =  +0.00 V, max =  +0.00 V)  ALARM
in14:                  184.00 mV (min =  +0.00 V, max =  +0.00 V)  ALARM
fan1:                     0 RPM  (min =    0 RPM)
fan2:                   813 RPM  (min =    0 RPM)
fan3:                     0 RPM  (min =    0 RPM)
fan4:                     0 RPM  (min =    0 RPM)
fan5:                     0 RPM  (min =    0 RPM)
SYSTIN:                +118.0°C  (high =  +0.0°C, hyst =  +0.0°C)  sensor = thermistor
CPUTIN:                 +41.5°C  (high = +80.0°C, hyst = +75.0°C)  sensor = thermistor
AUXTIN0:                +33.0°C  (high =  +0.0°C, hyst =  +0.0°C)  ALARM  sensor = thermistor
AUXTIN1:               +111.0°C    sensor = thermistor
AUXTIN2:               +110.0°C    sensor = thermistor
AUXTIN3:               +111.0°C    sensor = thermistor
SMBUSMASTER 0:          +30.0°C
PCH_CHIP_CPU_MAX_TEMP:   +0.0°C
PCH_CHIP_TEMP:           +0.0°C
PCH_CPU_TEMP:            +0.0°C
intrusion0:            OK
intrusion1:            ALARM
beep_enable:           disabled

 

[ConsolidatedResults]

@Ziyan, those appear to be the same as the names in HWInfo64 in Windows, in that case:

amdgpu-pci-0300:

• edge = iGPU internal sensor (on die)

k10temp-pci-00c3:

• Tdie / Tctl = CPU internal sensor (on die)

nct6793-isa-0290

• SYSTIN / AUXTIN1 / AUXTIN2 / AUXTIN3 = bogus
• CPUTIN = mainboard close to SOC VRM (if i am correct)
• AUXTIN0 = somewhere on the mainboard not thermally loaded

 

[GLSRacer]

@ConsolidatedResults Thanks, I suspected that they might be bogus since they only change by a few degrees and the reported values don't seem to correlate to system load (idle temps are similar to full load temps).

 

[rubicoin]

hi all, my first post here. i'm just about entering ryzen deskmini platform, coming from dell optiplex micro 3020 i3 version. got all the new shiny stuff needed for my build except a300 itself. i've ordered it 10 days ago and still waiting for delivery. somehow it is completely out of inventory everywhere here in hungary atm, no restocking seems to happen at distributors either. this got me thinking, maybe asrock is prepping a new amd apu deskmini product like a400 and a300 stocks remain limited for small markets like ours? anyway, i got a 2200g for my build as i planned on switching to 4X00g later this year sometime. i've been 99% sure that asrock would not build a new sff barebone for amd's last am4 apu line, and they would update a300 bios to support renoir asap (as the'd done it with picasso last year). this feeling is backed up by all related info in the following article:

https://wccftech.com/amd-b550-a520-chipset-mass-production-q1-2020-asmedia/

still i got concerns, especially after reading news about asrock jupiter a320 & a320-m motherboard. what do you think, is there real chance that asrock won't support renoir @ a300 and tries to push us towards this new 1 liter jupiter platform?

 

[The Gunslingers]

Hi All, I wanted to share these links as the could be helpful.


I believe this one has been posted before but this is an alternative option for the extra usb header cable
https://www.aliexpress.com/item/32928582883.html?spm=a2g0o.cart.0.0.281f3c00X95mBM&mp=1

I was unable to find the screw size for both the rear audio cable and the extra usb port mounts? That's my only worry as these don't come with screws.
Does anyone know the size?

 

[m4758406]

Hi All, I wanted to share these links as the could be helpful.


I believe this one has been posted before but this is an alternative option for the extra usb header cable
https://www.aliexpress.com/item/32928582883.html?spm=a2g0o.cart.0.0.281f3c00X95mBM&mp=1

I haven't tried it, but I was looking for the an alternative rear audio cable and found this which I believe will work.
https://www.aliexpress.com/item/32807241737.html

I was unable to find the screw size for both the rear audio cable and the extra usb port mounts? That's my only worry as these don't come with screws.
Does anyone know the size?

Maybe this help you little bit.
Following Link is from an german forum, was written by me ...

Stromspar PC 2019 Klein, Leise aber Videoschnitt möglich

Für den NUC habe ich den Test oben verlinkt, es sind etwa 6W im Idle und 74W bei Volllast, was dann nach einigen Sekunden auf 48W drosselt. Dabei geht natürlich auch die Performance runter. Der NUC leistet 155/779 (1T/nT) im Cinebench. Beim Ryzen-System mit der GT 1030 fehlt noch die SSD. Auch...

www.computerbase.de

"
Die Schrauben waren nicht dabei, aber hatte noch sehr viele aus von vor 20 Jahren.
Es sind die Standard-Schrauben wie man es bei den PC-Gehäusen verwendet.
Bei den PC-Gehäuse-Schrauben gibt es die mit dem Grobgewinde fürs Blech und Feingewinde um zbs. Laufwerke zu befestigen.
Die mit dem Feingewinde sind hier auf dem Foto zu sehen.

Hier die Abmaße meiner beiden Schrauben:
Länge mit Kopf ~10,9 mm.
Gewinde-Länge ~8,8 mm.
Gewinde-Durchmesser ~2,9mm.
Kopf-Durchmesser ~6,9 mm.
"

 

[The Gunslingers]

Maybe this help you little bit.
Following Link is from an german forum, was written by me ...

Stromspar PC 2019 Klein, Leise aber Videoschnitt möglich

Für den NUC habe ich den Test oben verlinkt, es sind etwa 6W im Idle und 74W bei Volllast, was dann nach einigen Sekunden auf 48W drosselt. Dabei geht natürlich auch die Performance runter. Der NUC leistet 155/779 (1T/nT) im Cinebench. Beim Ryzen-System mit der GT 1030 fehlt noch die SSD. Auch...

www.computerbase.de

Thanks, that with google translate is answered my question!

 

[Quango]

Finally my replacement A300 arrived after two weeks of shipping madness inside the local DHL distribution center.
With BIOS 3.50 it works out of the box with an Athlon 3000G. In the coming weeks I will assemble my temporary setup untill the Renoir APUs arrive.

 

[rubicoin]

Finally my replacement A300 arrived after two weeks of shipping madness inside the local DHL distribution center.
With BIOS 3.50 it works out of the box with an Athlon 3000G. In the coming weeks I will assemble my temporary setup untill the Renoir APUs arrive.

so you are 100% sure that renoir apus will be supported. good to hear and hopefully we get more info about the desktop apu lineup soon.

 

[Quango]

so you are 100% sure that renoir apus will be supported. good to hear and hopefully we get more info about the desktop apu lineup soon.

No, I am not, but my order was placed a month ago before the equestion came up here. Since the A300 has no actual chipset while the Renoirs keep the AM4 socket and the Vega graphics, I see no obstacle for compatibility beyond BIOS updates.

 

[officeplant]

Tried a friends 3200G. Stress test got the VRM up to 77C after an hour

 

[ConsolidatedResults]

@officeplant, thank you very much for testing! I see, I guess the temperatures would be higher for a 3400G and will also depend a lot on whether the CPU gets warm enough to spin the fan up to full. I don't think a situation where a GPU-only load with a lenient fan curve would keep the fan running at low RPMs while the SOC VRMs cook themselves is out of question. I am not sure it was a great decision from ASRock to remove the CPUTIN sensor as an input for fan curve in A300 BIOS 3.40. If you could chose in BIOS which sensor to use, have the two fan headers independent, that would be nice.

 

[ConsolidatedResults]

One other thing I have posted before, SOC Voltage not sticking for me in BIOS P/L3.XX, I had contacted ASRock support and they thankfully and helpfully came back fairly quickly and suggested I should bump RAM from DDR4-3200 to DDR4-3266. Huh? So I just finished testing and found the full story to be as follows:

In BIOS P1.20 SOC Voltage behaves as such:

• If (RAM Frequency = Auto) -> VSOC = 1.0V
• If (RAM Frequency = Manual) AND (SOC VID = Auto) -> VSOC = 1.1V
• If (RAM Frequency = Manual) AND (SOC VID = Manual) -> VSOC = SOC VID
• DRAM Voltage does not matter

Spoiler: The test series for P1.20

BIOS:	P1.20
CPU:	Ryzen 5 2400G
RAM:	Crucial CT16G4SFD832A.16FE1
RAM Nominal:	DDR4-3200 JEDEC SPD Profile
BIOS	BIOS	BIOS	BIOS	Effective (HWI64)
DRAM Frequency	DRAM Timing	DRAM Voltage	SOC Voltage	SOC Voltage
Auto (DDR4-2666)	Auto	1.2	Auto	1
DDR4-2400	Auto	1.2	Auto	1.1
DDR4-2666	Auto	1.2	Auto	1.1
DDR4-3200	Auto	1.2	Auto	1.1
DDR4-3333	Auto	1.2	Auto	1.1
Auto (DDR4-2666)	Auto	1.2	1.15 / VID 40	1
DDR4-2400	Auto	1.2	1.15 / VID 40	1.15
DDR4-2666	Auto	1.2	1.15 / VID 40	1.15
DDR4-3200	Auto	1.2	1.15 / VID 40	1.15
DDR4-3333	Auto	1.2	1.15 / VID 40	1.15
Auto (DDR4-2666)	Auto	1.35	1.15 / VID 40	1
DDR4-2666	Auto	1.35	1.15 / VID 40	1.15
DDR4-3333	Auto	1.35	1.15 / VID 40	1.15

In BIOS P3.50 SOC Voltage behaves as such:

• If (RAM Frequency = Auto) -> VSOC = 1.0V
• If (RAM Frequency = Manual) AND (RAM Frequency equal to or below SPD rating) = VSOC -> 1.0V
• If (RAM Frequency = Manual) AND (RAM Frequency above SPD) AND (SOC VID = Auto) -> VSOC = 1.1V
• If (RAM Frequency = Manual) AND (RAM Frequency above SPD) AND (SOC VID = Manual) -> VSOC = SOC VID
• DRAM Voltage or Timings do not matter

Spoiler: The test series for P3.50

BIOS:	P3.50
CPU:	Ryzen 5 2400G
RAM:	Crucial CT16G4SFD832A.16FE1
RAM Nominal:	DDR4-3200 JEDEC SPD Profile
BIOS	BIOS	BIOS	BIOS	Effective (HWI64)
DRAM Frequency	DRAM Timing	DRAM Voltage	SOC Voltage	SOC Voltage
Auto (DDR4-2666)	Auto	1.2	Auto	1
DDR4-2400	Auto	1.2	Auto	1
DDR4-2666	Auto	1.2	Auto	1
DDR4-3200	Auto	1.2	Auto	1
DDR4-3266	Auto	1.2	Auto	1.1
DDR4-3333	Auto	1.2	Auto	1.1
Auto (DDR4-2666)	Auto	1.2	1.15 / VID 40	1
DDR4-2400	Auto	1.2	1.15 / VID 40	1
DDR4-2666	Auto	1.2	1.15 / VID 40	1
DDR4-3200	Auto	1.2	1.15 / VID 40	1
DDR4-3333	Auto	1.2	1.15 / VID 40	1.15
Auto (DDR4-2666)	Auto	1.35	1.15 / VID 40	1
DDR4-2666	Auto	1.35	1.15 / VID 40	1
DDR4-3333	Auto	1.35	1.15 / VID 40	1.15
DDR4-3200	CL20	1.2	1.15 / VID 40	1

From this we do not know yet whether SOC VID kicks in at above 3200MT/s or above SPD rated speed, so I did a quick test with SODIMMs rated DDR4-2666 to prove it is not a hard setting at 3200MT/s but depends on rated DRAM speed.

Spoiler: The test series for P3.50 with DDR4-2666 SODIMMS

BIOS:	P3.50
CPU:	Ryzen 5 2400G
RAM:	Micron MTA4ATF51264HZ-2G6E3
RAM Nominal:	DDR4-2666 JEDEC SPD Profile
BIOS	BIOS	BIOS	BIOS	Effective (HWI64)
DRAM Frequency	DRAM Timing	DRAM Voltage	SOC Voltage	SOC Voltage
Auto (DDR4-2666)	Auto	1.2	Auto	1
DDR4-2733	Auto	1.2	Auto	1.1
DDR4-3200	Auto	1.2	Auto	1.1

This is the reason I was so confused, I had done most of my previous testing on P3.X BIOSes with the DDR4-2666 kit, where I would have never noticed the dependence of VSOC on SPD rated speed, because i never ran it at rated speed. I had tested the 3200 Kit only at higher frequencies on 3.XX BIOSes before, not at stock speed with just tightened timings and slightly increased VSOC, which is how I run them in P1.20.

I know there were some A300 owners that were having issues getting their RAM to run _at_ rated speed, maybe they would be able to run _above_ rated speed, if it was VSOC preventing stability before.

That leaves two questions maybe. 1) How does this behave with XMP? I don't have any XMP RAM to test. 2) Why, just why...?