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
