Select the BIOS on the dropdown at the bottom of the page
-
Save 15% on ALL SFF Network merch, until Dec 31st! Use code SFF2024 at checkout. Click here!
Prebuilt [SFFn] ASRock's DeskMini A300 - Finally!
- Thread starter confusis
- Start date
unpack and run ASROM.exe if you brave enough
just not working
looks like other settings works and saves fine, but can't guarantee all of them
OOPS, JUST REBOOTED WHILE WEB BROWSING
i'll try
here you go
not all menus, cause most of them are similar to a300
yes
Last edited:
unpack and run ASROM.exe if you brave enough
just not working
looks like other settings works and saves fine, but can't guarantee all of them
actually no reboots (for now) but i had ones on a300 bioses
OOPS, JUST REBOOTED WHILE WEB BROWSING
i'll try
here you go
not all menus, cause most of them are similar to a300
yes
awesome! thanks for the 10 screenshots as well!
First of all, thank you very much for trying that out. This is very interesting.
So you have a A300 and still got the options showed up? -- But those just "do not work", as you described.
I had some throughts in https://smallformfactor.net/forum/t...a300m-deskmini-a300.10567/page-25#post-236722 -- you may add to it.
If it's like this. We know 1.40 does not allow to save changes made. Now you are, but not for the OC settings.
Man... I would like to get more to know about the 'Knoll Activator Chip' -- which should basically have the Flags and System-Startup-Config...
If you find any intereting infos on that, please share. I think maybe creating an open-source git-repository for our attempts, where we can collect infos and knowledge. What do you think about it? Kinda doing the progress together.
Maybe desoldering this chips from X300 to A300 could enable 1.46' options? This would be amaizing and point straight at the component of interests...
I would like to welcome you: https://github.com/traumfaenger/a300-oc
Last edited:
I wouldn't be surprised if the activator chip just said "hey, I'm an A300" or "I'm an X300" and then the bios behaves accordingly, regardless of the menu options. The bios is probably also the one responsibly for only allowing APUs based on what the activator chip says. I wouldn't be surprised if (conceptually) it was that simple.
I also believe, it should be not that hard. The PSP of the Ryzen is asking it at startup about the options. Then it continues.
We know, that in the BIOS-ROM are 3 partitions, UEFI-based, and one is 128KB -- this could be the firmware of the ARM Cortex-based PSP inside AMD.
Probably there is somewhere to find this functions to read the 'Knoll' -- and the function has to speak with I2C, so it can be searched for ARM Cortex-specifix I2C-Channel2 Port, getting the HEX offset of the GPIO and then tracking down till the usage of it appears in the 128KB blob. (Ryzen[PSP] --> I2C_CH2 --> KNOLL, bidirectional, 2 lanes)
Edit: What I'm trying to say is, that those flags from the Knoll have also to be present in the BIOS, so it kinda recognizes the modes it should run.
We know, that in the BIOS-ROM are 3 partitions, UEFI-based, and one is 128KB -- this could be the firmware of the ARM Cortex-based PSP inside AMD.
Probably there is somewhere to find this functions to read the 'Knoll' -- and the function has to speak with I2C, so it can be searched for ARM Cortex-specifix I2C-Channel2 Port, getting the HEX offset of the GPIO and then tracking down till the usage of it appears in the 128KB blob. (Ryzen[PSP] --> I2C_CH2 --> KNOLL, bidirectional, 2 lanes)
Edit: What I'm trying to say is, that those flags from the Knoll have also to be present in the BIOS, so it kinda recognizes the modes it should run.
Last edited:
This is right on the money...
For anyone interested, updating to the X300 to the 1.46 bios (shipped with 1.40) has exposed the TDP limit (65/45/35) and it's actually doing an okay job undervolting the CPU to keep the temps down!
Seam's perfectly stable on the X300 for anyone interested!
ok, but no need to update just for this, Ryzen Controller should work fine
sure
Ok, the repo should now contain most interesting findings on A300, knoll and some pictures
But also BIOS images. Missing are "tools"
3.60R and 1.46 side-by-side
Drivers in the UEFI-Image
Probably CPU-microcode and more system-based-hw-images
e.g. "OemActivation" has OA3 -- which should be the OEM-Windows-Key-entry
-- https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/validate-oem-activation-key
There is also the bugged S3-driver, driver for the power- and sleep-buttons, driver to wake up from sleep, all low-level stuff the OS does not care about. It has to use those functions written. (more drivers: RealtekUefiDriver (NIC), even Fonts are there, "Defaults" -- which is probably "Load Defaults", setupdata, etc) I just don't know where to look for knoll.
There are even links to .ca files (certificate- and cert-requests which are looking for "http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.cr")
There are even embedded images
Oh dear, this is has a big scope, if we gonna really gonna try to reverse and adopt it.
Some of the GUID's are generic and known by UEFI-specs, those have names on the UEFItool. Unknown enteties are shown by GUID. Probably Knoll/Chipset-releated is one of those unknown entities.
Me trying simultaniously to update the git-repo, so all who wants to get a hold of, can go-as-the-analysis-goes.
Reading Knoll-Activator Dan's Logic Analyzed Data
1.
- set valid address to be 0x50
- write data to this address: "0x5E"
2.
- set valid address to read from: 0x50
- data read: 0x80 -- but than the orange data byte 5E: 80? Should it not be 0x5E as it was written?
Ah, I get it: It sets the address to read from, consists of 2 bytes:
- write to controller to read from 0x50 0x5E
- word from 0x505E = 0x80
Gonna look up I2C protocol to understand the happening...
So, somewhere in the UEFI BIOS should be 0x80 (and more), etc to "authorize" or "authenticate" the system-features?
Diggin further in the Trace:
It has sequence of reading 2 Bytes from an adjascent address, like:
Read: [Address | Value]
#1.
0x00 | 0x23 (may be the init), then
#2.
0xFE | 0x45
0xFF | 0xAD
#3. --> Could be first Config Block, then
0x7E | 0xCD
0x7F | 0x34
#4. --> second value of ??config block??
0x5E | 0x80
0x5F | 0xCE
#5. -->
0x40 | 0x04
0x41 | 0xCD
-->
(now again the ?separator?)
#6.
0x00 | 0x23 (same as first read, init)
#7. = #2.
0xFE | 0x45
0xFF | 0xAD
#8. = #3.
0x7E | 0xCD
0x7F | 0x34
#9. = #4.
#10. = #5.
It maybe a sync, init, so Clocks and Data passes and is not corrupted. (I2C-sync)
Now they can speak... lets see. Btw. The file I'm analyzing: "ActivatorChipTrimmed.sr", using PulseView stable (free)
Now lets look inside the main block, thicker, middle-part
Starts with
#1
write, addr=0x00, 1Byte, value=0x00
#2 then it reads (first block could be a value)
0x80 | 0x0C
0x81 | 0x4A
0x82 | 0x05
0x83 | 0x20
(here I dont know)
0x89 | 0x94
0x84 | 0x00
0x8C | 0x05
0x91 | 0x5A
(here could be the config-part, since it "just reads" straight on)
0x92
0x93
0x94
0x95
0x96
0x97
0x98
0x99
0x9A
0x9B
...
0xAF
(same as 3-lines of first block in beginning of #2)
0x80 | 0x0C
0x81 | 0x4A
0x82 | 0x05
(repeating again)
0x80 | 0x0C
0x81 | 0x4A
0x82 | 0x05
(then it repeats again the read from 0x92..0xAF)
(then again read from 0x80..0x82)
then it tries to read something, but there is no answer from the flash -- "data read-operation" returning no value
after it goes back reading from -- following addresses are new in the whole sequence:
0x02 | 0x0C
0x0C | 0x01
alternating
then it's done.
so there are not many bytes to understand.
It would make very much sence to grab the i2C trace from X300 and compare. Maybe by rewriting the Flash is it possible to "become the X300". Dunno untill now... However, this is all the data read from the Knoll:
last thing:
But also BIOS images. Missing are "tools"
3.60R and 1.46 side-by-side
Drivers in the UEFI-Image
Probably CPU-microcode and more system-based-hw-images
e.g. "OemActivation" has OA3 -- which should be the OEM-Windows-Key-entry
-- https://docs.microsoft.com/en-us/troubleshoot/windows-client/deployment/validate-oem-activation-key
There is also the bugged S3-driver, driver for the power- and sleep-buttons, driver to wake up from sleep, all low-level stuff the OS does not care about. It has to use those functions written. (more drivers: RealtekUefiDriver (NIC), even Fonts are there, "Defaults" -- which is probably "Load Defaults", setupdata, etc) I just don't know where to look for knoll.
There are even links to .ca files (certificate- and cert-requests which are looking for "http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.cr")
There are even embedded images
Oh dear, this is has a big scope, if we gonna really gonna try to reverse and adopt it.
Some of the GUID's are generic and known by UEFI-specs, those have names on the UEFItool. Unknown enteties are shown by GUID. Probably Knoll/Chipset-releated is one of those unknown entities.
Me trying simultaniously to update the git-repo, so all who wants to get a hold of, can go-as-the-analysis-goes.
Reading Knoll-Activator Dan's Logic Analyzed Data
But I think here is also a problem. How can we do following:
1.
- set valid address to be 0x50
- write data to this address: "0x5E"
2.
- set valid address to read from: 0x50
- data read: 0x80 -- but than the orange data byte 5E: 80? Should it not be 0x5E as it was written?
Ah, I get it: It sets the address to read from, consists of 2 bytes:
- write to controller to read from 0x50 0x5E
- word from 0x505E = 0x80
Gonna look up I2C protocol to understand the happening...
So, somewhere in the UEFI BIOS should be 0x80 (and more), etc to "authorize" or "authenticate" the system-features?
Diggin further in the Trace:
It has sequence of reading 2 Bytes from an adjascent address, like:
Read: [Address | Value]
#1.
0x00 | 0x23 (may be the init), then
#2.
0xFE | 0x45
0xFF | 0xAD
#3. --> Could be first Config Block, then
0x7E | 0xCD
0x7F | 0x34
#4. --> second value of ??config block??
0x5E | 0x80
0x5F | 0xCE
#5. -->
0x40 | 0x04
0x41 | 0xCD
-->
(now again the ?separator?)
#6.
0x00 | 0x23 (same as first read, init)
#7. = #2.
0xFE | 0x45
0xFF | 0xAD
#8. = #3.
0x7E | 0xCD
0x7F | 0x34
#9. = #4.
#10. = #5.
It maybe a sync, init, so Clocks and Data passes and is not corrupted. (I2C-sync)
Now they can speak... lets see. Btw. The file I'm analyzing: "ActivatorChipTrimmed.sr", using PulseView stable (free)
the things I wrote are for the A-mark in the screenshot, very probably a sync-phase
Now lets look inside the main block, thicker, middle-part
Starts with
#1
write, addr=0x00, 1Byte, value=0x00
#2 then it reads (first block could be a value)
0x80 | 0x0C
0x81 | 0x4A
0x82 | 0x05
0x83 | 0x20
(here I dont know)
0x89 | 0x94
0x84 | 0x00
0x8C | 0x05
0x91 | 0x5A
(here could be the config-part, since it "just reads" straight on)
0x92
0x93
0x94
0x95
0x96
0x97
0x98
0x99
0x9A
0x9B
...
0xAF
(same as 3-lines of first block in beginning of #2)
0x80 | 0x0C
0x81 | 0x4A
0x82 | 0x05
(repeating again)
0x80 | 0x0C
0x81 | 0x4A
0x82 | 0x05
(then it repeats again the read from 0x92..0xAF)
(then again read from 0x80..0x82)
then it tries to read something, but there is no answer from the flash -- "data read-operation" returning no value
after it goes back reading from -- following addresses are new in the whole sequence:
0x02 | 0x0C
0x0C | 0x01
alternating
then it's done.
so there are not many bytes to understand.
It would make very much sence to grab the i2C trace from X300 and compare. Maybe by rewriting the Flash is it possible to "become the X300". Dunno untill now... However, this is all the data read from the Knoll:
last thing:
X300-1.46 Frontend Options: OC Tweaker
A300-3.60R Frontend Options: OC Tweaker
Last edited:
Your input / ideas are appreaciated and welcome
Should I better post results in the BIOS-Thread? Like it's more tech than any guide or just a regular trouble.
I think it's better.
Just talked with a friend of mine, who happens to come also from IT-background. We discussed a bit, well, most elegant solution would be to analyze the X300's Knoll data to be able to spot differences. Afterwards figuring things out.
What I think of is the following: you can either access the problem from "low level" way, basically by analysing the Knoll and trying to spot and reverse differences, or you counter it from "high level" by exploiting the BIOS images to dig further and explore the bytes seen transmitted by Knoll on the A300. Have no spare money, still. Sadly
Should I better post results in the BIOS-Thread? Like it's more tech than any guide or just a regular trouble.
I think it's better.
Just talked with a friend of mine, who happens to come also from IT-background. We discussed a bit, well, most elegant solution would be to analyze the X300's Knoll data to be able to spot differences. Afterwards figuring things out.
What I think of is the following: you can either access the problem from "low level" way, basically by analysing the Knoll and trying to spot and reverse differences, or you counter it from "high level" by exploiting the BIOS images to dig further and explore the bytes seen transmitted by Knoll on the A300. Have no spare money, still. Sadly
Last edited:
Please HELP.
I changed cpu voltage to 1.2V in ryzen master, now the pc can't turn on.
When the power button pressed, CPU fan spin for a while then turn off.
Power indicator also didn't on.
My cpu is ryzen 2400G. Bios 3.40.
I have disconnected all ssd, but no avail.
All RAM disconnected too, this time the cpu fan keeps turn on but power led indicator still off and still couldn't boot.
Please help, how to fix this?
I changed cpu voltage to 1.2V in ryzen master, now the pc can't turn on.
When the power button pressed, CPU fan spin for a while then turn off.
Power indicator also didn't on.
My cpu is ryzen 2400G. Bios 3.40.
I have disconnected all ssd, but no avail.
All RAM disconnected too, this time the cpu fan keeps turn on but power led indicator still off and still couldn't boot.
Please help, how to fix this?
Last edited:
Is there a reset cmos header on the A300? If not, unplug the power brick, remove the CMOS battery, and hold the power button for a while (30 seconds is probably fine) to drain all residual power from the board. That should restore the BIOS back to defaults.
I don't know if there is a reset cmos header in A300, probably someone can tell me?
I am newbie on hardware, how to remove CMOS battery?
The battery is attached to a cable and motherboard , that cable attached to a jumper.
Is it enough to pull the cable from the jumper or should pull the battery from motherboard?
I am newbie on hardware, how to remove CMOS battery?
The battery is attached to a cable and motherboard , that cable attached to a jumper.
Is it enough to pull the cable from the jumper or should pull the battery from motherboard?
Last edited:
look at back
somewhere at up right, look closely
wait, did Ryzen Master even worked?
can't remember this on my 3200G (probably cause 3.50)
What's it look like? Near the usb jumper or dc jack?
I see a text clrcmos1 near usb jumper. Is this a cmos header?
How to reset it?
Manual is your best resource (being serious, without an image handy, the layout and descriptor is best to check manual, looks like when pulled out looking at front ports, right side, NOT the pair right next to the speaker)
Similar threads
