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

D3NPA

Average Stuffer
Mar 8, 2020
58
41

Valantar

Shrink Ray Wielder
Jan 20, 2018
2,201
2,225
TestMem5

any reason not to use RGB?
Radeon GPUs seem to default to YCbCr 4:4:4 for some reason - at least that's true for my Fury X, RX 570 and 4650G Vega 7. I always switch them over to RGB - that's what PCs are supposed to use after all, and what PC OSes and applications are designed around. It's entirely possible that text rendering in YCbCr 4:4:4 looks weird.
 

gustav

Cable-Tie Ninja
Jun 18, 2020
193
90
UBU, 3.60R vs 1.46


Presing S you can extract he Frontend-UI (see git repo/tools/AMI...zip and UBU..zip) and compare both versions against each other.
This understanding is important. My asumption is, that the o/c code has to be present in both versions, maybe it's still "only" an UI option, just not to rule it out, or forget about it, and then searching and like not knowing what's going on...

This is how an extract looks like: (1.46 in this case)

Form: OC Tweaker, FormId: 0x2ACE {01 86 CE 2A A0 09}
0x27903 Subtitle: Statement.Prompt: CPU Configuration, Flags: 0x0 {02 87 A2 09 00 00 00}
0x2790A End {29 02}
0x2790C Subtitle: Statement.Prompt: STR_LINE, Flags: 0x0 {02 87 8A 09 00 00 00}
0x27913 End {29 02}
0x27915 Suppress If {0A 82}
0x27917 QuestionId: 0x205 equals value in list (0x0) {14 08 05 02 01 00 00 00}
0x2791F Gray Out If {19 82}
0x27921 QuestionId: 0x1D6 equals value 0x1 {12 06 D6 01 01 00}
0x27927 One Of: CPU Frequency and Voltage(VID) Change, VarStoreInfo (VarOffset/VarName): 0x16F, VarStore: 0x1, QuestionId: 0x2AEB, Size: 1, Min: 0x0, Max 0x1, Step: 0x0 {05 91 D7 09 D8 09 EB 2A 01 00 6F 01 14 10 00 01 00}
0x27938 One Of Option: Auto, Value (8 bit): 0x0 (default) {09 07 05 00 30 00 00}
0x2793F One Of Option: Manual, Value (8 bit): 0x1 {09 07 B6 00 00 00 01}
0x27946 End One Of {29 02}
0x27948 End If {29 02}
0x2794A End If {29 02}
0x2794C Suppress If {0A 82}
0x2794E QuestionId: 0x2AEB equals value 0x0 {12 06 EB 2A 00 00}
0x27954 Gray Out If {19 82}
0x27956 QuestionId: 0x1D6 equals value 0x1 {12 06 D6 01 01 00}
0x2795C Numeric: Frequency(MHz), VarStoreInfo (VarOffset/VarName): 0x170, VarStore: 0x1, QuestionId: 0x2AEC, Size: 4, Min: 0x0, Max 0x189C, Step: 0x19 {07 9A D9 09 DA 09 EC 2A 01 00 70 01 14 12 00 00 00 00 9C 18 00 00 19 00 00 00}
0x27976 Default: DefaultId: 0x0, Value (32 bit): 0x0 {5B 09 00 00 02 00 00 00 00}
0x2797F End {29 02}
0x27981 End If {29 02}
0x27983 End If {29 02}
0x27985 Suppress If {0A 82}
0x27987 QuestionId: 0x2AEB equals value 0x0 {12 06 EB 2A 00 00}
0x2798D Gray Out If {19 82}
0x2798F QuestionId: 0x1D6 equals value 0x1 {12 06 D6 01 01 00}
0x27995 Numeric: {a1#{f5#{w145000# Voltage(VID), VarStoreInfo (VarOffset/VarName): 0x17C, VarStore: 0x1, QuestionId: 0x2AED, Size: 4, Min: 0x0, Max 0x25D78, Step: 0x271 {07 9A 42 0A 43 0A ED 2A 01 00 7C 01 14 12 00 00 00 00 78 5D 02 00 71 02 00 00}
0x279AF Default: DefaultId: 0x0, Value (32 bit): 0x0 {5B 09 00 00 02 00 00 00 00}
0x279B8 End {29 02}
0x279BA End If {29 02}
0x279BC End If {29 02}
0x279BE Suppress If {0A 82}
0x279C0 QuestionId: 0x205 equals value in list (0x8, 0x9) {14 8A 05 02 02 00 08 00 09 00}
0x279CA Not {17 02}
0x279CC End {29 02}
0x279CE Suppress If {0A 82}
0x279D0 QuestionId: 0x2AEB equals value 0x0 {12 86 EB 2A 00 00}
0x279D6 Not {17 02}
0x279D8 End {29 02}
0x279DA Gray Out If {19 82}
0x279DC QuestionId: 0x1D6 equals value 0x1 {12 06 D6 01 01 00}
0x279E2 Ref: CPU Core (Per CCX), VarStoreInfo (VarOffset/VarName): 0xFFFF, VarStore: 0x0, QuestionId: 0x9F, FormId: 0x2ACF {0F 0F 4A 0A 4B 0A 9F 00 00 00 FF FF 00 CF 2A}
0x279F1 End If {29 02}
0x279F3 End If {29 02}
0x279F5 End If {29 02}
0x279F7 Suppress If {0A 82}
0x279F9 QuestionId: 0x205 equals value in list (0x8) {14 08 05 02 01 00 08 00}
0x27A01 Gray Out If {19 82}
0x27A03 QuestionId: 0x1D6 equals value 0x1 {12 06 D6 01 01 00}
0x27A09 Numeric: {a1#{f5#{w145000#SOC Voltage(VID), VarStoreInfo (VarOffset/VarName): 0x186, VarStore: 0x1, QuestionId: 0x2AEE, Size: 4, Min: 0x0, Max 0x25D78, Step: 0x271 {07 9A 48 0A 49 0A EE 2A 01 00 86 01 14 12 00 00 00 00 78 5D 02 00 71 02 00 00}
0x27A23 Default: DefaultId: 0x0, Value (32 bit): 0x0 {5B 09 00 00 02 00 00 00 00}
0x27A2C End {29 02}
0x27A2E End If {29 02}
0x27A30 End If {29 02}
0x27A32 Suppress If {0A 82}
0x27A34 QuestionId: 0x205 equals value in list (0x8, 0x9) {14 8A 05 02 02 00 08 00 09 00}
0x27A3E Not {17 02}
0x27A40 End {29 02}
0x27A42 Gray Out If {19 82}
0x27A44 QuestionId: 0x1D6 equals value 0x1 {12 06 D6 01 01 00}
0x27A4A Numeric: {a1#{f3#{w1300#CLDO VDDP Voltage Control, VarStoreInfo (VarOffset/VarName): 0x1A0, VarStore: 0x1, QuestionId: 0x2ACB, Size: 2, Min: 0x0, Max 0x60E, Step: 0xA {07 94 56 0A 57 0A CB 2A 01 00 A0 01 14 11 00 00 0E 06 0A 00}
0x27A5E Default: DefaultId: 0x0, Value (16 bit): 0x0 {5B 07 00 00 01 00 00}
0x27A65 End {29 02}
0x27A67 End If {29 02}
0x27A69 End If {29 02}
0x27A6B Suppress If {0A 82}

Check for example offset: 0x27995 -- SOC VID. There is also a variable behind this value -- in 'VarStoreInfo' at offset 0x186. So the o/c function would apply this value to it's method to achieve desired results. Of course it's all just guessing so far, but we have to start somewhere I guess :)
Also the same offset, see the Step: 0x271 in HEX? Check it in decimal system, it's 625.
Which step do we have adjusting the voltage? Right, 0.0625V.

From the UI it seems it is storing the data inside those structures:
0x24A70 VarStore: VarStoreId: 0x16 [560BF58A-1E0D-4D7E-953F-2980A261E031], Size: 0x9, Name: PNP0501_0_VV {24 23 8A F5 0B 56 0D 1E 7E 4D 95 3F 29 80 A2 61 E0 31 16 00 09 00 50 4E 50 30 35 30 31 5F 30 5F 56 56 00}
0x24A93 VarStore: VarStoreId: 0x17 [560BF58A-1E0D-4D7E-953F-2980A261E031], Size: 0x3, Name: PNP0501_0_NV {24 23 8A F5 0B 56 0D 1E 7E 4D 95 3F 29 80 A2 61 E0 31 17 00 03 00 50 4E 50 30 35 30 31 5F 30 5F 4E 56 00}




Again, we have an offset -- important to compare if the structures are different in length in 3.60R vs 1.46
There could the problems the A300 not saving X300's-BIOS settings come from, I will upload these findings.

It could take a bit time, till I can upload it, in the mean time, here a similar output from
it came up as I was searching for ASROCK-specific UEFI entity "PNP0501_0_VV" where the overclock
observed resides (again, guessing).

Greetings

Edit: in git/analysis-UBU you are able to find full "AMI Setup IFR extract".

Here are GUID's of the image, which are using PNP_0501_0_VV settings-structure.
Searched for the VarStore "560BF58A-1E0D-4D7E-953F-2980A261E031"...



Even more interesting... but it belongs to setup. Further down in the HEX-View, you can see 'options fields' -- I don't know how they are parsed.

Even-though I understand, that this attemp may fail, I have no better solution as to
try figure to it out how the modules come together. After the modules have been identified, there still may be the 'Knoll' in our way.
It could be so, that we have to read I2C-X300's-Knoll-Data to be able to "open" up o/c. I still have no idea.
Btw: I find this BB board not the best solution to post results at, which are based on pictures.

PS.: Check this out, I guess it's a chipset-less AsRock Board for AMD Epyc.

@alles_alles Curious to find Cezanne in the BIOS ROM, which upon search on google represents Ryzen 5xxx Series. So, yea there is something going on around Cezanne and X300/A300 -- but it may be only the AGESA version implementing it. Whether the mainboard fully supports this - or is able to configure the APU to "run" is another question.
 
Last edited:
  • Like
Reactions: D3NPA

gustav

Cable-Tie Ninja
Jun 18, 2020
193
90
Hello, small update on the repo:

Since there are two blocks where options are stored, namely PNP0501_0_VV and PNP0501_1_VV, I checked the output of UBU, which also stated two GUIDs for OROM, which are the options. I've extracted both regions + one large 532KB region, which contains a reference to the 0501-block.

The 532KB region, on the other hand is being parsed by UBU as well as by UEFITool and contains the BIOS ROMs for VBIOS, etc.

All 3 versions are online. Wondering if 3.60R to 3.60S differs and 3.60R to 1.46.

-- all files are same on hex-level: those may be "faisafe to defaults" or any defaults-options BIOS uses. dang, dead-end
 
Last edited:

apis29

Cable Smoosher
Jul 31, 2020
9
0
Almost Final !

Updated from BIOS 3.40 to 3.60S
Has this changed since the first BIOS that supported the 4000 series? Iirc when the first one came out I read a post only 3000 and 4000 series were supported in the new BIOS version?
 

Nunuji

Caliper Novice
Jan 17, 2021
23
8
Evening everyone!

So I finally had some time off and mangled a slim fan managed to stuff a 120^2x15mm fan into my deskmini! Temps overall are pretty good, though I still have to do some stress testing to make sure everything is stable and happy, especially with my RAM OC.

Problem is, some benchmarks (specifically OCCT) won't launch because of overheating protection. There are two sensors, reported as TMPIN6 and TMPIN8 in HWMonitor 1.43, that are averaging 107C+ at idle while everything else is 40-60C. Does anyone have any info on these or any ideas on where the various sensors are on the board?
 

gustav

Cable-Tie Ninja
Jun 18, 2020
193
90
Found AGESA Firmware reference

Basically everything's there. GfxFreqLimit, Boot procedure, etc. Very interesting read.

Check page 211 for Gfx. Before are cpu und Mem configs.

I did not find any SDK related files. But at least we know, how they could be set/parsed together.

Very interesting ist also the described boot init stages.

I believe the mainboard provides Uart/Debug headers. Would be interesting to tap inside

Page 273 speaks about Smm_Overclocking flag!
 
Last edited:

ratundtat

Average Stuffer
Sep 12, 2020
78
22
i am so insane, but i bought x300, now. there, the firmware is not better. no technical environments or inovation nuclear power free developlemt... jaja just a joke!
i do not know what the problem of asrock is.... i hate the case, + mount the 2 USB-cables it is annoying to close case to 100%, again. as like as at the a300. that is still expansive metal trash. but it is small, that i am liking.
what i want to say:
i took my settings into the x300. OS is arch-linux. OK, first good news is: now I can boot Linux Mint (USB-Live-Stick) without producing CMOS crash!
Arch works with adopting new NVRAM chroot method to efibootmgr adding .... i am not so good in english!

So i tested now my last moments before i changed to x300.
booting - start lutris - epic games - jurassic park.
that i was play lots of hours in the last days.
now, it is in ~1h hang the whole system. complete freeze. there is no reset-button, you know it. so push the power-button. ahhh that i did not awaiting-.-

and the other thing is booting: journalctl -xb
Jan 30 00:36:13 archlinux kernel: __common_interrupt: 1.55 No irq handler for vector
Jan 30 00:36:13 archlinux kernel: #2
Jan 30 00:36:13 archlinux kernel: __common_interrupt: 2.55 No irq handler for vector
Jan 30 00:36:13 archlinux kernel: #3
Jan 30 00:36:13 archlinux kernel: __common_interrupt: 3.55 No irq handler for vector
Jan 30 00:36:13 archlinux kernel: #4
Jan 30 00:36:13 archlinux kernel: __common_interrupt: 4.55 No irq handler for vector
Jan 30 00:36:13 archlinux kernel: #5
Jan 30 00:36:13 archlinux kernel: __common_interrupt: 5.55 No irq handler for vector
Jan 30 00:36:13 archlinux kernel: #6
Jan 30 00:36:13 archlinux kernel: __common_interrupt: 6.55 No irq handler for vector
Jan 30 00:36:13 archlinux kernel: #7
Jan 30 00:36:13 archlinux kernel: __common_interrupt: 7.55 No irq handler for vector
...
an 30 00:36:13 archlinux kernel: system 00:04: [io 0x0910-0x091f] has been reserved
Jan 30 00:36:13 archlinux kernel: system 00:04: [mem 0xfec00000-0xfec00fff] could not be reserved...

and i will found more.
i just changed the motherboard.

asrock need a complete new and better uefi-firmware development team.

some infos about me: i did years nothing in computer. just youtubing and google-ing 8years with old notebook.
my primary OS was linux mint.
i am using arch, because A300+P1+LM= kill CMOS, and because bad supporters i have the same settings still today.
with Arch my settings was running, but Arch is more difficult as Mint. And primary i just wanted googleing and facebooking and send dirty letters in thunderbird for my imaginary friends.... -.-

now i am a priceless product tester and annoy all users, because "debug".

later a300 -> mama #birthday-present. she using windows. ok she needs some new hardware, but she has just 100mb/sec hdd computer and other dinosaur hardware. with Firmware 3.60k she would´t have trouble with this product.

back to x300:
what uefi-firmware you will offer me? actual installed P1.40.

----
update:
i upgrade the firmware to P1.46 (X300)
i have some bugs in my bootscreen, will see later.
Jurassic Park works fine as like as A300 with Firmware 3.60k
 
Last edited:

Yurand

What's an ITX?
New User
Jan 29, 2021
1
0
Could you please post a link to 3.60s? Ive scrolled half of this thread and I cant seem to find a working link.
 

Nunuji

Caliper Novice
Jan 17, 2021
23
8
So I may have gently cooked my A300, and I'm wondering if you guys have had similar issues or any experience with something like this.

The short version is that, after an overheating issue, it is no longer stable during Unigine Valley and Superposition tests under certain conditions. At SOCv 1.13125 with RAM OC at 3600 CL16, Valley always causes a restart between scene 10 and 14. There is no blue screen, no error code, and the windows log just say sudden loss of power (super helpful XD). Superposition also fails, though I haven't pinpointed what scenes cause it. The weird thing is that according to other tests(memtest, prime95, cinebench), everything is stable and just fine? I'm pretty sure BEFORE the overheating issue it had no problem running both Valley on loop AND Prime95 at the same time, with zero crashes.

The longer version is that, while stress/stability testing, my makeshift 120mm fan setup decided to stop working, and I didn't notice and just thought the cooling was being really, really silent. Temps reached somewhere between 105-110C for several minutes before I realized something was wrong to shut everything down. I'm pretty sure something got a little toasty because the A300 had a little bit of a smell to it... not like something had burnt out, but definitely an ozone/toasty smell, if that makes sense.
At SOCv 1.20000 with RAM OC Superposition works just fine, but Valley still restarts around the same area.
At SOCv 1.13125 with RAM OC both crash. Memtest86 shows zero errors, prime95 and cinebench r20 work perfectly fine.
At regular XMP settings (3200 CL16) with almost and SOCv everything works fine.

System specs are ASRock A300, BIOS 1.60R, Ryzen 5 Pro 4650G, Crucial 2x8GB 3200 CL16 RAM, 250GB SATA SSD with Win10, 80GB HDD with Manjaro.
 
Last edited:

gustav

Cable-Tie Ninja
Jun 18, 2020
193
90
Hard to tell, why you experience such behavior.
Only some of us - choosen people - are able to run at mem@3600.

If you lower the RAM clock, at SOC VID below 1.2V, is it stable then?

Edit: I see, you already tested it "everything works fine"

Could be an issue of mainboard/cpu(vega particular). It's pretty hard to guess. It could be the signal traces on the mainboard - the routing of those. They may interfere with each other on the Signal-Level, so as APU starts to have a hard time pushing all of the data around, the interferences lead to a corruption in data, which that GPU driver is able to recover from by closing Valley and jumping into desktop.

How did the overheat happen? What was exactly overheated? CPU? I mean there is only 2-3 temp sensors you can trust, rest is kinda resting at "high-level".

Maybe do 3600 at cl18?
When temperatures change, the resistance and other electric properties may change. I could imagine, the overheat degraded a VRM-vomponent for the SOC on the mainboard. You may try to measure it using voltmeter. Internal resistance, and when on - voltagedrop, etc. It has to be "debugged" with capturing some values to be able to discuss the topic properly.

There could/should be also I2C chip, which is controlling the VRM stages, which may be programmed through I2C. (Modern OC-able graphics provide that interface) so sad, I do not have a spare A300 to test the basic build.

I keep the opinion not to Over-Power the SOC at 1.2V -- this is just crazy :)

Imagine, stock voltage is 1.0V, which you oc, and keep auto, it's set auto to 1.1V, which is +10% more. When you have a vdrop, ist like -10% voltage, which causes instability (in my case without manual adjustment it can go down as low as 0,97x V on 1.1-auto)

By manual compensation to 1.1375V it's stable.

What you could also try (to rule out a CPU issue) -- change your RAM and CPU to other A300 based board. If it's back to stable at 3600,CL16 and 1.13125 you know the overheat targeted mainboard.

To be able to tell more about the temperatures, you have to check the Novuton chip on the mainboard. It's the Super IO chip which turns on the system and lays everything in the way to be able to turn the CPU on.

Novuton chip is also the chip, where the power buttons are connected to which is used to establish needed voltages and do low-level job in a300 to power on the platform.

This chip comes in flavors for an Intel CPU but also separate editions for AMd CPU. The CPU temp sensor is connected from AM4 socket straight to the Novuton Chip's PINs, which reads the values and reports them..

If the Novuton has even more temperature-related PINs and only one is connected, the other may return false values, since they are floating either high or low. That's why I think one value is always like 115°C. Just have no idea where it comes from.. I believe the VRMs have also a Temperatur sensor underneath the heatsink. But I think they don't get as hot as 115°C since the ops-voltagr is between 70-110°C (as an example, please check against)

So far my ideas on that issue :)
Hope it helps somehow
 
Last edited:
  • Like
Reactions: Nunuji

Nunuji

Caliper Novice
Jan 17, 2021
23
8
Hard to tell, why you experience such behavior.
Only some of us - choosen people - are able to run at mem@3600.

If you lower the RAM clock, at SOC VID below 1.2V, is it stable then?

Edit: I see, you already tested it "everything works fine"

Could be an issue of mainboard/cpu(vega particular). It's pretty hard to guess. It could be the signal traces on the mainboard - the routing of those. They may interfere with each other on the Signal-Level, so as APU starts to have a hard time pushing all of the data around, the interferences lead to a corruption in data, which that GPU driver is able to recover from by closing Valley and jumping into desktop.

How did the overheat happen? What was exactly overheated? CPU? I mean there is only 2-3 temp sensors you can trust, rest is kinda resting at "high-level".

Maybe do 3600 at cl18?
When temperatures change, the resistance and other electric properties may change. I could imagine, the overheat degraded a VRM-vomponent for the SOC on the mainboard. You may try to measure it using voltmeter. Internal resistance, and when on - voltagedrop, etc. It has to be "debugged" with capturing some values to be able to discuss the topic properly.

There could/should be also I2C chip, which is controlling the VRM stages, which may be programmed through I2C. (Modern OC-able graphics provide that interface) so sad, I do not have a spare A300 to test the basic build.

I keep the opinion not to Over-Power the SOC at 1.2V -- this is just crazy :)

Imagine, stock voltage is 1.0V, which you oc, and keep auto, it's set auto to 1.1V, which is +10% more. When you have a vdrop, ist like -10% voltage, which causes instability (in my case without manual adjustment it can go down as low as 0,97x V on 1.1-auto)

By manual compensation to 1.1375V it's stable.

What you could also try (to rule out a CPU issue) -- change your RAM and CPU to other A300 based board. If it's back to stable at 3600,CL16 and 1.13125 you know the overheat targeted mainboard.

To be able to tell more about the temperatures, you have to check the Novuton chip on the mainboard. It's the Super IO chip which turns on the system and lays everything in the way to be able to turn the CPU on.

Novuton chip is also the chip, where the power buttons are connected to which is used to establish needed voltages and do low-level job in a300 to power on the platform.

This chip comes in flavors for an Intel CPU but also separate editions for AMd CPU. The CPU temp sensor is connected from AM4 socket straight to the Novuton Chip's PINs, which reads the values and reports them..

If the Novuton has even more temperature-related PINs and only one is connected, the other may return false values, since they are floating either high or low. That's why I think one value is always like 115°C. Just have no idea where it comes from.. I believe the VRMs have also a Temperatur sensor underneath the heatsink. But I think they don't get as hot as 115°C since the ops-voltagr is between 70-110°C (as an example, please check against)

So far my ideas on that issue :)
Hope it helps somehow
Thanks for your input! I had already thought about testing the RAM and APU in another system, but until I read it from you, I forgot I helped my friend build an A300 Deskmini a year ago! With his permission, I will borrow his system and run some tests on both to diagnose if it is a RAM, APU, or Motherboard issue. I'll report back here what I figure out, if anything.

To answer your question, the sensor that reported the 110C temp was definitely the CPU one and NOT one of the erroneous sensors... also the heatsink was VERY hot to the touch. It's times like these I wish I had a voltmeter and knew a bit more about that level of electronics. I somewhat suspect it is something to do with the VRM causing the problems, because the CPU clocks remain unchanged after all of this, and I've had previous experience with VRM power delivery issues.

I have also considered doing 3600CL18, and I am willing to bet it will work, but that will have to wait for my weekend. I also have my heart set on CL16, because there are measurable improvements at least in artificial tests, and I know Ryzen APUs especially appreciate fast RAM. As I said, I will do more tests on my days off and let you all know. :)

Regarding SOC @ 1.2V, While I would also never recommend someone to keep it this high for normal use, I do find it can be helpful when troubleshooting or working on OCs so that you don't have to worry about the SOC voltage being you limiting factor.
 
  • Like
Reactions: gustav

gustav

Cable-Tie Ninja
Jun 18, 2020
193
90
You're welcome :) I'm happy in helping you to "see the forest in front of all those trees" - saying in german, when 4 eyes sees more than 2 :)

Looking forward into your results.

One point I'd like to mention:
By putting your RAM at CL18 at 3600 MHz should be meant as a test, untill your other hardware arrives.

I somehow bet it's also the VRMs. I have also not the best ones here :) Squirrel-sounds in "off" mode and in "stand-by" ... As soon as you hear this - you know, you did not win the lottery :D

There is a grain of salt to the whole SOC VID topic. You see, we don't know where those are being measured. You may find on yt a video from Gamer's Nexus, where he talks about the topic of "killing you cpu with vid soc voltage". Main gist, is that, even though you may set the VID @1.2V the mainboard may deliver in fact as much as e.g. 1.3V but due to measurements it's showing only 1.2V

Keep this in mind ;)

PS: I have to correct myself, you would need an oscilloscope to be able to tap in VRM analysis - it's a graph, phase, part of a sinus, which is needed to be generated in a "clean" way. But internal resistance is also a factor.

Which heatsink got so hot? The one on the CPU or the VRM-heatsink? ... Since they are pretty close to each other, I guess both got pretty warm :D

Were you running iGPU-intensive task? As we know AMD upwards K6 does not die anymore by high temps, since it's able to throttle it's clocks. (In fact, the then-competitor Pentium 3 managed to survive) However, I don't know whether the Vega uses that feature. Therefore the question about the load at timepoint of the overheat.
 
Last edited: