Motherboard Group Buy/Crowdfunded Modded BIOS for the Asrock A300m (Deskmini A300)

Feynek

Chassis Packer
Jan 12, 2021
15
0
I tell you the configuration of my rig:

A300m stx
Noctua NH-L9a-AM4 chromax.Black
AMD Ryzen 5 2400G (maybe upgrade 3400g or 4650g =p )
Crucial Ballistix BL2K8G32C16S4B 3200 MHz (maybe try later in 32go)
Sapphire NITRO + RX 5700 XT 8G GDDR6
Samsung 970 evo 500go for os and software (need to upgrade i think)
Samsung 860 evo 1TO for games
Intel AX200 Gig + Wi-FI 6 ( work very good!)
HDPLEX 400W AC-DC Ver 3.0 (I think this is the one)
 

Feynek

Chassis Packer
Jan 12, 2021
15
0
Hello, I have experienced similar behavior on tight timings. It was reporting in cpu-z 1500MHz which is ×2 = 3000MHz, had in the BIOS 3200MHz instead thou.

I described a bit of it here:
I've read a little your post ( because there is really a lot to read and I am not comfortable with English haha ) and if i if I understand correctly, you also advise against the 4650g on an a300?
 

gustav

Cable-Tie Ninja
Jun 18, 2020
163
73
I've read a little your post ( because there is really a lot to read and I am not comfortable with English haha ) and if i if I understand correctly, you also advise against the 4650g on an a300?
Hello :)

It's hard for me to advice to something I did not test, but from what I read others are reporting - 4650G or Renoir for A300 is not trivial. There is no official support for renoir on the A300. And since X300 is almost the same hardware (from what we know) - I see hard times to get it properly to work. More like a black box, weather it works or not, you have to try it out by yourself.
 
  • Like
Reactions: Feynek

MrJvr

Caliper Novice
Jan 18, 2021
26
8
Hey, I have just picked up an X300, currently running a 3000G, I have a 4650G in the post and also have 3400G/200GE/3600/3900x knocking about.
I am very keen on finding out of these can be run with CPU and a little more on the discrete graphics cards side as well :)
I would love to throw in a 3900x (whilst obviously undervolting the heck out of it!).
I'll report back on how easy it is to get a 4650G up and running.
 

Curiosity

SFF>Speed
Silver Supporter
Apr 30, 2016
614
658
Non-APU processors don't work, but you absolutely can run a discrete GPU through an M.2 slot using a riser.

I too would love to throw in something like a 3600 but alas, no dice. I think the best option is the 4650G.
 

MrJvr

Caliper Novice
Jan 18, 2021
26
8
Non-APU processors don't work, but you absolutely can run a discrete GPU through an M.2 slot using a riser.

I too would love to throw in something like a 3600 but alas, no dice. I think the best option is the 4650G.
Any idea why that is?
I have a 4650G in the post but I'm just more curious as to why or whether it's at all possible to be fair :)
 

Curiosity

SFF>Speed
Silver Supporter
Apr 30, 2016
614
658
I don't think we know why it started that way, but iirc someone emailed asrock (who has been receptive to making custom bioses in the past for some people, usually to solve issues) about getting a bios made to support non APU processors and ASrock deemed it too much trouble to be worth doing.
 

MrJvr

Caliper Novice
Jan 18, 2021
26
8
I don't think we know why it started that way, but iirc someone emailed asrock (who has been receptive to making custom bioses in the past for some people, usually to solve issues) about getting a bios made to support non APU processors and ASrock deemed it too much trouble to be worth doing.
Maybe it would be bringing in direct competition to other products or that there is just a much higher number of CPU's available so if they were to officially support it they could be opening them up to more support hassle than it's worth.
That being said, CPU support in a 1.7 litre machine would just be spectacular!
 
  • Like
Reactions: Curiosity

yuusou

Average Stuffer
Mar 16, 2019
78
51
I don't think we know why it started that way, but iirc someone emailed asrock (who has been receptive to making custom bioses in the past for some people, usually to solve issues) about getting a bios made to support non APU processors and ASrock deemed it too much trouble to be worth doing.
I think from the get-go these systems support non-APUs and then they limit it. After going through all the work to not support non-APUs, it would be a lot of wasted work for them. A shame though, it would a nice "goodbye" present if they did it just before discontinuing the product.
 
  • Like
Reactions: Curiosity

Nunuji

Chassis Packer
Jan 17, 2021
19
7
Maybe it would be bringing in direct competition to other products or that there is just a much higher number of CPU's available so if they were to officially support it they could be opening them up to more support hassle than it's worth.
That being said, CPU support in a 1.7 litre machine would just be spectacular!
I know this idea was floated elsewhere when Zen 3 originally came out, but I can't remember if it was true or not; maybe the BIOS chip physically can't support that many different CPUs? Like MSI supposedly had to launch a "new" line of non-500 series motherboards (the MAX series) to support some of the new CPUs. In a similar fashion, the ASRock beta BIOSs that support the 4000-series APUs had to remove older APUs from the support list to make that happen as well.

To that end, I am sure it would be a support nightmare to have two different branches of a BIOS on your website if one version couldn't handle every CPU/APU. Like imagine a situation in which someone with a Bristol Ridge APU on an A300 blindly "updated" to one of the beta BIOSs (let's pretend for this example that it wasn't a "beta" and was just sitting with the rest of the available downloads). All of a sudden they have basically bricked their A300 because it will no longer boot to bios to reverse the flash.
As much as I dislike that the X300 exists, I think it was less of a cash grab and more of a way to do product segmentation and avoid some support issues.
 

yuusou

Average Stuffer
Mar 16, 2019
78
51
They're already doing that though. The beta bioses have AGESA V2 and the regular bioses have AGESA only.
 

gustav

Cable-Tie Ninja
Jun 18, 2020
163
73
I know this idea was floated elsewhere when Zen 3 originally came out, but I can't remember if it was true or not; maybe the BIOS chip physically can't support that many different CPUs? Like MSI supposedly had to launch a "new" line of non-500 series motherboards (the MAX series) to support some of the new CPUs. In a similar fashion, the ASRock beta BIOSs that support the 4000-series APUs had to remove older APUs from the support list to make that happen as well.

To that end, I am sure it would be a support nightmare to have two different branches of a BIOS on your website if one version couldn't handle every CPU/APU. Like imagine a situation in which someone with a Bristol Ridge APU on an A300 blindly "updated" to one of the beta BIOSs (let's pretend for this example that it wasn't a "beta" and was just sitting with the rest of the available downloads). All of a sudden they have basically bricked their A300 because it will no longer boot to bios to reverse the flash.
As much as I dislike that the X300 exists, I think it was less of a cash grab and more of a way to do product segmentation and avoid some support issues.
I agree with you upon a strategic decision AsRock had to take in terms of supporting sub 150€ platform.

Couple of interesting points you mentioned, I'd like to add to.

1. maybe the BIOS chip physically can't support that many different CPUs?

Indeed there are limitations. One of a basic limitations, as you may know is for example the actual size of the BIOS chip (or it's flash to be exact). For example, the BIOSes for the A300 I have took a look at are all 16 megabytes in size.

This is also why support for older CPUs sometimes ways off. To be able to fit the code for new ones. Those parts of code - a bit simplified are used for "triggering he CPU to turn on, and it's Security Processor" and some other basic stuff.

But from developer point of view, you mention branches.

2. beaching & development

Since the manufacturer has to decide how many efforts and so to say money or "people's time" to relocate to do a specific task (whether developing for AGESA v2, or developing at all for example) -- so many branches there will be.

You see, branching as such is very common and using git as a tool for development process - you are pretty fast, flexible at switching branches.
Your working directly becomes practically *the* other branch. That's why I think it's up to the decisions you've mentioned.

There are development tools to write UEFI driver (very interesting read up, I will try to find the link later on, it consists of 3 parts)

The thing is that because there is X300 and it has mostly the same mainboard, there must be a small change to disable the OC features. The changes will become visible if someone with experience can compare 3.60R and 3.60S for example. But this is the OC point.

Now the support - which I think will be provided on X300 longer than on A300, it's also "the way to go". Not knowing anything about UEFi-internals it will be hard to understand. There is UEFItool, on github I believe, it can open, at least display the partitions in the BIOS file image. Additionally, there is AMI tool to open up the BIOS-frontend-more-type-of-thing and someone could do the changes required (mine did not work, but also did not brick). But for the changes to apply - the code behind the UI has to be there. Well, in 3.60R it certainly is, but in 3.60S we don't know. (Well, I think it has to be, since at XMP the SOC will be 1.1V on auto, and it's probably using the same code-segment just with an other parameter e.g. as HEX value -- it could be "unlockable" by UI after all)

3. compatibility

Also one thing to mention. Since there are AGESA v1 *and* v2 available for our board and the X300, they should be, and we know they are, mostly compatible -- there is a switch or a difference to search for and then to patch. But again it comes up to experience and passion I guess. Or doing a research on the PSP (Platform Secure Processor) could be good. Just to know where it decides to be able to do an OC or not. Thinking how to trigger an experiment...
The PSP is almost the first thing which boots up and valides the system as trustworthy. From there on it should be a secured boot process, now here I dunno whether it's even a valid patch-strategy.
A comparison between 1.40 / 3.60R / 3.60S should be done to be able track the changes, or at least to start somewhere. I dunno.

Ok I think I'm done.
Thanks for reading :) sorry for typos.

Edit: maybe a suggestion to make an open source project out of it, like by community? I have no idea how to manage something like this -- I mean something where all the progress of the analysis, reversing, screenshots, text segments to store and writing a Wiki is not I mainly do. How ever, I can provide the tools, links, and some read-ups.

Last time I asked the creator of ryzenadj if he knows where OC flag is or it exists, he did not knew that. I probably could ask again 😃

Edit x: https://github.com/traumfaenger/a300-oc you are welcome!

Edit xy: @Danlopez1222 I hope I have your "ok" to collect your findings in the repo. I do it -- you respond I'll remove it :) Sincerely
 
Last edited:

gustav

Cable-Tie Ninja
Jun 18, 2020
163
73
Do not want to spam, but you may check latest:

The repo should now contain all findings, and any who wants to start to explore the UEFI images, can do so.
 

Quango

Average Stuffer
Apr 6, 2019
85
20
Any idea why that is?
... I'm just more curious as to why or whether it's at all possible to be fair :)

The standard, squarish Mini-STX form factor is in general meant for APUs/iGPUs only by the manufacturers. This is the case for years now. Asrock had to "invent" the elongated Micro-STX form factor to add an MXM graphics card. (same with NUCs at Intel: the squarish have iGPUs only, the elongated "Enthusiast" models add another GPU.)