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

Nunuji

Caliper Novice
Jan 17, 2021
23
8
Conclusion: Need to raise SOC VID. Not possible.
If SOC VID can be adjusted, the system could run @3600MHz without any problems.
Just think for yourself. It ran with XMP Timings on 3200,3333 and 3400 with SOC VID = 0,9 (~1.0V)
Renoir is amaizing.
@gustav I am a little confused by your post here. I believe we are using the same BIOS (3.60R), and unless I am misunderstanding you can set the SOC VID to 1.13125, which is how I achieved 3600@CL16. May I ask what RAM you are using that you were not able to achieve this on the 3650G? Perhaps I am just misreading things....
 

The_Bavarian

Minimal Tinkerer
New User
Mar 27, 2021
3
2
@Ldthvx:
This is what I meant in the previous post. As long as you are using an apu up to Picasso, the X300 bios works on A300. As soon as you install a Renoir apu, the Asrock A300 "lock" refuses to use the X300-Bios.

Thank you very much for being so brave and testing it. Thanks to your bad experience with this procedure I will not try it by now.

Have a nice weekend.

Tom
 

gustav

Cable-Tie Ninja
Jun 18, 2020
186
83
@gustav I am a little confused by your post here. I believe we are using the same BIOS (3.60R), and unless I am misunderstanding you can set the SOC VID to 1.13125, which is how I achieved 3600@CL16. May I ask what RAM you are using that you were not able to achieve this on the 3650G? Perhaps I am just misreading things....
If I'm using Renoir, and 3.60R or 3.60S, it does not matter, if I increase using 3.60R the SOC VID to 1.12500 (as I first tried), it stayed in HWINO32 (ver. 7.00) below 1.0V - that's why I saw no reason to plump any numbers in the field, since SOC VID is not changing anyhow.

Please, show me a screenshot, where I'm able to see your SOC VID in Windows above 1.0V - that would be very helpful.
Speaking about BIOS 3.60R.

Update @XMP/3200MHz 18-18-18-43-61/1T: SOC VID is by default at 0,994V -> Valley -> 0,938V => ~19xx Points
Auto Timings / 3333MHz / SOC VID=1.1V : *next* => so, it kept the timings from XMP, at 3333MHz. SOC VID was not adjusted! it kept being 0.988V -> 0,925V
 
Last edited:

Ldthxv

Cable Smoosher
Jul 27, 2020
8
4
@Ldthvx:
This is what I meant in the previous post. As long as you are using an apu up to Picasso, the X300 bios works on A300. As soon as you install a Renoir apu, the Asrock A300 "lock" refuses to use the X300-Bios.

Thank you very much for being so brave and testing it. Thanks to your bad experience with this procedure I will not try it by now.

Have a nice weekend.

Tom
Correct! I just inserted a 2400G and the system boots up fine. Everything is working again with bios 1.58 from X300 and the 2400G APU.

I did try to flash back to 3.60S. Instant flash would not allow me to do it. Renaming A3MSTX_3.60S to X3MSTX_3.60S allowed me to choose it. But it then said: Invalid file. Trying ramalhais method to flash back also did not work. It always says it can no longer automatically detect the flash chip. So I think the only way to get back to 3.60S is via the CH341A programmer :-(
 

gustav

Cable-Tie Ninja
Jun 18, 2020
186
83
You mean by writing to the EEPROM of the BIOS chip.
But then there is a question: Can you just write the ROM to it, or has any pre-processing to be done, to e.g. "grab" the ROM at the correct offset,
since the BIOS file is consisting of "modules" than just simple bare .hex, you know what I mean.

Maybe you have to manipulate and cut&paste (into temp-storage) the correct offsets to combine those to a "proper" valid BIOS file, which can be flashed.
Dunno. I always loved those simple BIOS files, until UEFI came along with it's incomatibilities due to 'secure boot' and such. does anyone use TPM? - I also don't know why they (Intel&Co.) wanted to let it (so handly) in the desktop architecture. It is TPM, as long as / only to this point until the keys from it's ROM are leaked.
And DRM-based content is able to run without this dictated TPM-bulls$%t. (Correct me if I'm wrong)
By now we have custom ARM Cores inside of x86 CPU's which are validating trust-chain from 'power on' till 'shutdown of the system. Great ;)

Edit: The 1.58 BIOS is very interesting! I hope the AGESA stack gets ported to the A300 -.- I would be happy as a kid@Disneyland.
I see how much of stability Renoir adds to the system - since the change of the CPU I did not experience any freezings oder unwanted shutdown / hangs.
 
Last edited:

ramalhais

Caliper Novice
Nov 15, 2019
32
23
Correct! I just inserted a 2400G and the system boots up fine. Everything is working again with bios 1.58 from X300 and the 2400G APU.

I did try to flash back to 3.60S. Instant flash would not allow me to do it. Renaming A3MSTX_3.60S to X3MSTX_3.60S allowed me to choose it. But it then said: Invalid file. Trying ramalhais method to flash back also did not work. It always says it can no longer automatically detect the flash chip. So I think the only way to get back to 3.60S is via the CH341A programmer :-(

You can try loading UEFI defaults and save, then go back to the previous processor and try to flash again with flashrom.
Maybe flashrom doesn't work with 2400G.


EDIT: Nevermind. I just tried it on my 3400G and it also doesn't work 😢
It seems like either AMD AGESA or the ASRock BIOS is disabling writing to flash.
 
Last edited:

alles_alles

SFF Lingo Aficionado
Aug 11, 2020
107
28
SOORRRy doesnt seen the old post . :(

BIOS VERSION 1.58

have Cezenna support !!!!!


AMD ║
╟─┬────────┬────────┬──────────┬──────┬────────┬────╢
║#│ CPUID │Revision│ Date │ Size │ Offset │Last║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║1│00810F10│08101016│2019-04-30│0xC80 │0x5A6500│Yes ║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║2│00820F01│08200103│2019-04-17│0xC80 │0x5A7200│Yes ║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║3│00810F00│08100004│2016-11-20│0xC80 │0x5A7F00│Yes ║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║4│00810F80│08108002│2018-06-05│0xC80 │0x5A8C00│Yes ║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║5│00810F81│08108109│2019-04-17│0xC80 │0x5A9900│Yes ║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║6│00810F11│08101102│2018-11-06│0xC80 │0x5AA600│ No ║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║7│00860F00│0860000E│2020-01-27│0xC80 │0x72EF00│Yes ║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║8│00860F01│08600106│2020-06-19│0xC80 │0x72FC00│Yes ║
╟─┼────────┼────────┼──────────┼──────┼────────┼────╢
║9│00A50F00│0A50000B│2020-08-21│0x15C0│0x8AEF00│Yes ║
╚═╧════════╧════════╧══════════╧══════╧════════╧════╝
Zen 3 support is *really* coming to AM4 now : Amd (reddit.com)
aviable here.
Beta BIOS DeskMini | The r/ASRock Wiki (botflakes.github.io)
 
Last edited:

Ldthxv

Cable Smoosher
Jul 27, 2020
8
4
You can try loading UEFI defaults and save, then go back to the previous processor and try to flash again with flashrom.
Maybe flashrom doesn't work with 2400G.


EDIT: Nevermind. I just tried it on my 3400G and it also doesn't work 😢
It seems like either AMD AGESA or the ASRock BIOS is disabling writing to flash.
Thanks for letting me know! I think I will leave mine as it is and give it to a friend with the 2400G and get myself a X300. I wanted to get a new one in any case but did not know if I should take the X300 or the iBOX-V2000M. But seeing that the X300 now has support for Zen3 I would think it is a better choice. I will however keep the A300 case because I like the front better and think it will be better for cooling :-)

Again, thanks for all the help 😃
 
  • Like
Reactions: ramalhais

ramalhais

Caliper Novice
Nov 15, 2019
32
23
Thanks for letting me know! I think I will leave mine as it is and give it to a friend with the 2400G and get myself a X300. I wanted to get a new one in any case but did not know if I should take the X300 or the iBOX-V2000M. But seeing that the X300 now has support for Zen3 I would think it is a better choice. I will however keep the A300 case because I like the front better and think it will be better for cooling :-)

Again, thanks for all the help 😃

Just a bit more info:

I tried pulling PIN 3 of the flash chip W25Q128 to ground, as suggested below, but no luck:
https://github.com/pcengines/apu2-documentation/blob/master/docs/research/apu_bios_write_protect.md
SPI WP# is on the J2 header (page 12 on the board schematics). This signal is connected to the dedicated SPI WP# pin of the APU chip and can't be controlled like a GPIO.

First test was done checking the behavior of the SPI WP# pin, when shorted to ground. No change was noticed. Flashing was still possible using flashrom application on Voyage Linux distribution.

https://community.amd.com/t5/drivers-software/about-spi-interface-of-amd-chipset/td-p/45760
11-05-2020 09:09 AM

Re: About SPI Interface of AMD chipset​

Hi Kevin,
I have recently bumped into the same issue, also with Yangtze. From the SPIBAR dump you have attached I can clearly see that the SpiAccessMacRomEn (bit22) and SpiHostAccessRomEn (bit23) are cleared in the SpiCntrl0 register (SPIBAR + 0x00). If any of those two bits are cleared, all of the SPIRestrictedCmd (SPIBAR + 0x04/0x08) as well as SPI_CmdValue registers (SPIBAR + 0x10/0x14/0x18) are effective. Additionally, if SpiAccessMacRomEn is set, the software cannot access the lower 512KB of the SPI flash. That is why you cannot access the SPI flash, because the hardware detects an attempt of illegal access. If the SpiAccessMacRomEn (bit22) and SpiHostAccessRomEn (bit23) are cleared by the firmware/BIOS then you would have to patch/modify you BIOS, because these bits are clear-once and may be set to 1 only by a platform reset. If not cleared by BIOS, just keep these bits set and your SPI access software should work.

EDIT: I guess the only way to work-around it would be, to find the place in the BIOS where access to the flash is being locked, but that may be impossible if it's done in the PSP processor with ABL code (AGESA Boot Loader), because that's signed code.
 
  • Like
Reactions: gustav

gustav

Cable-Tie Ninja
Jun 18, 2020
186
83
@ramalhais good guessing. I think so too. Additionally, we have a problem: we don't know where in the AGESA/PSP architecture or any submodule of it the 'frash_write_enable' variable is stored. That's why a patch (additionally I guess would also need to patch the checksum at least - if not more) is very difficult.
Have you tried to open a BIOS file in the UEFITool? See how many sub modules in a UEFI there are. One of them, or the (as blob) included firmware of the PSP should contain that. Here we simply don't know. That's why docs are important from the software-perspective.

UEFITool Enteries:
- generic UEFI-standard-compliant Enteries/Submodules have a name, when seen in the UEFITool
- vendor specific UEFI drivers and modules can not be recognized by the tool, there for they have no "name". Since they are still following the UEFI-specs, UEFITool is still able to extra them and do any kind of manipulation.

Additionally, we know at this point (I may have posted somewhere how a simple UEFI driver is setup up / written, which is basically C/C++ and should be reverseable.

We just don't know where to look.


If we deal with hardware and chips as such. We may have success using datasheet. Something as read-out the eeprom or write it should be possible.
 
Last edited:

ramalhais

Caliper Novice
Nov 15, 2019
32
23
@ramalhais good guessing. I think so too. Additionally, we have a problem: we don't know where in the AGESA/PSP architecture or any submodule of it the 'frash_write_enable' variable is stored. That's why a patch (additionally I guess would also need to patch the checksum at least - if not more) is very difficult.
Have you tried to open a BIOS file in the UEFITool? See how many sub modules in a UEFI there are. One of them, or the (as blob) included firmware of the PSP should contain that. Here we simply don't know. That's why docs are important from the software-perspective.

UEFITool Enteries:
- generic UEFI-standard-compliant Enteries/Submodules have a name, when seen in the UEFITool
- vendor specific UEFI drivers and modules can not be recognized by the tool, there for they have no "name". Since they are still following the UEFI-specs, UEFITool is still able to extra them and do any kind of manipulation.

Additionally, we know at this point (I may have posted somewhere how a simple UEFI driver is setup up / written, which is basically C/C++ and should be reverseable.

We just don't know where to look.


If we deal with hardware and chips as such. We may have success using datasheet. Something as read-out the eeprom or write it should be possible.

I noticed that in the X300 1.58 BIOS there are at least 2 modules that don't exist on the older bioses, but this may be due to the new agesa version:
FlashSmiDxe
FlashSmiSmm

Also, you can still write to the flash inside the BIOS in an EFI shell, but i can't get AfuEfix64 to write a good BIOS. Even on windows with older BIOS, i could never flash a good BIOS. It always results in a bricked BIOS.
Just copy an EFI shell to a USB drive: https://github.com/tianocore/edk2/blob/UDK2018/ShellBinPkg/UefiShell/X64/Shell.efi
Download https://www.ami.com/static-downloads/Aptio_V_AMI_Firmware_Update_Utility.zip
Copy AfuEfix64.efi and the BIOS to the USB drive
Reboot
Go to the BIOS in the Exit menu, and go to "Launch EFI Shell from filesystem device"
fs3: (maybe it's fs2 or fs4 on your machine. maybe you can use command "map" to list the filesystems)
ls
AfuEfix64.efi backup.rom /O
 
Last edited:
  • Like
Reactions: gustav and Phuncz

limsandy

Average Stuffer
Jul 3, 2020
57
25
Edit: The 1.58 BIOS is very interesting! I hope the AGESA stack gets ported to the A300 -.- I would be happy as a kid@Disneyland.
I see how much of stability Renoir adds to the system - since the change of the CPU I did not experience any freezings oder unwanted shutdown / hangs.
Funny, I thought my 2200G was much more stable and I could run the memory at 2933 MHz. With Renoir 4650G my memory is only stable at 2400 MHz with-once-in-a-while random restart. To be fair, I was running 3.60S with the 2200G and 3.60R with 4650G.
 

A300

Average Stuffer
Jul 13, 2019
69
14
Funny, I thought my 2200G was much more stable and I could run the memory at 2933 MHz. With Renoir 4650G my memory is only stable at 2400 MHz with-once-in-a-while random restart. To be fair, I was running 3.60S with the 2200G and 3.60R with 4650G.
I am running 3.60S with 4650G.

Though did not test with memtest, didn't face random restart with RAM runs at 3200Mhz overclock from 2666Mhz.
 
Last edited:

ramalhais

Caliper Novice
Nov 15, 2019
32
23
Funny, I thought my 2200G was much more stable and I could run the memory at 2933 MHz. With Renoir 4650G my memory is only stable at 2400 MHz with-once-in-a-while random restart. To be fair, I was running 3.60S with the 2200G and 3.60R with 4650G.

Have you tried using DRAM-Calculator-for-Ryzen-1.7.3 and using all the suggested BIOS settings?
 

gustav

Cable-Tie Ninja
Jun 18, 2020
186
83
I noticed that in the X300 1.58 BIOS there are at least 2 modules that don't exist on the older bioses, but this may be due to the new agesa version:
FlashSmiDxe
FlashSmiSmm
Very welcome notice!
We should look into that!

Followup on Dxe Driver: from here
The Extensible Firmware Interface (EFI) can be implemented in many ways. One way is to implement via the Driver Execution Environment (DXE) Foundation portion of the Framework. As such, DXE represents a special type of driver that can be combined with EFI drivers in a given firmware volume.

There are two basic classes of DXE drivers. The first class is DXE drivers that execute very early in the DXE phase. The execution order of these DXE drivers depends on the evaluation of dependency expressions. These early DXE drivers typically contain basic services, processor initialization code, chipset initialization code, and platform initialization code. These early drivers also typically produce the architectural protocols that are required for the DXE Core to produces its full complement of EFI Boot Services and EFI Runtime Services. In order to support that fastest possible boot time, as much initialization should be deferred to the DXE drivers that follow EFI Driver Model described in the EFI 1.10 Specification.

Check this out! at this paragraph.

Writing SMM/DXE combined drivers​


SMM/DXE combined drivers looks very neat for evil purposes: you can have a single backdoor with ability to execute the both of DXE and SMM phase payloads.

I expected a difficulties with finding of usable example of such drivers in public sources like EDK2, Quark BSP or others. Actually, there's only two publicly available articles about UEFI SMM drivers development: "EFI Howto, Write a SMM Driver" and "BIOS Undercover: Writing A Software SMI Handler" — both of them are outdated, incomplete or vendor-specific.

To learn how to write combined drivers I decided to make a short reverse engineering of existing combined driver from my motherboard’s firmware. This time I used UEFITool by Nikolaj Schlej to work with flash image, if you need to do firmware modification and rebuild — this excellent tool works much more better than uefi-firmware-parser that was mentioned in my previous article.

As my target I took combined driver named 26A2481E-4424-46A2-9943-CC4039EAD8F8 (Google tells that this GUID belongs to S3Save UEFI driver but for our purposes it's doesn’t matter):

Will try it later on, extract the Dxe / Smm sections and open them up in Ghidra.
I have some embedded XP, so I may see somewhere in the code usage of the I2C interface, which whats to access the address of our flash-chip on the I2C bus.
There we know we found an important bit!

Gracias
 

gustav

Cable-Tie Ninja
Jun 18, 2020
186
83
@ramalhais Thank you for your hint's - I way able to spot in the "FlashDriverSmm" used Flash I2C devices & vendors (@Danlopez1222) was searching it too.



Like e.g.:
Fudan FM25W
ATMEL 26DF041
etc...
(and yes, it makes perfect sense there are couple of IC's to choose from, even manufacturers want to stay flexible and have a way to react to shortages of particular brands)

So the activator chip runs at 3.3V. [...]



Here are the Pulseview session files for the Analyzer

The next issue is that my hardware flasher won't read anything from the chips when set to 24xxx I2C EEPROM. It detects that an i2C chip exists there, but it just reads empty files. Is there a substantial difference between the 24xxx series of EEPROMS and the 34xxx series? I though the same i2C commands existed for both.
Now, I would say it makes sense - there is no 24xxx I2C flash nor any 34xxx series mentioned in the driver.


Open up in Ghidra, as x86_64, Intel arch is able to read & parse, looking good to start:
This is the extracted body of the particular PE32 image from UEFITool - "FlashDriverSmm" in this case. (which has also all those flash-chip vendors)


Ok, in "FlashDriverSmm" @ offset 0x000134f8 found probably something, where the flash-IC-vendor is set/choosen/identified:
- there is a section for ATMEL / ADESTO
- further code section for XMC, Cypress, Spansion 25FL(P), STM/Micron/Numonyx
- and one more for SST 25LF040 and SST 25LF080


My latest timestamp:


(Now some of the addresses has to be either the Flash chip on I2C bus or the PSP-related interface which then translates the query and works with the flash. Here we don't know yet. Is it the CPU which is accessing the flash (therefore the BIOS, let's simplify first) or is it the PSP....)

Hmm I can imagine, that at some point, the FlashDriver is being told which flash-IC to use, so it translates needed commands into the flash-IC-specific.
Ok, now we have to find the module the actual flash-data is coming from.

I've done some reverse work on STM32 with an ARM M0+ core, which worked well (after hours and days of read-ups, etc) - at the end I was able to achieve desired results. Here we have to start from ground up again.

Smi == System managements interface, I guess - will dig inside this driver.

The "FlashSmiDxe" looks also good, and it's init section is bigger, so settings up
the addresses and default / awaited values may take place here. Somehow need to grep the I2C-flash-address :/
"FlashSmiDxe" has also no vendors or any model numbers in it's data (vs. "FlashDriverSmm"). So, can we assume the correct "FlashDriver" has been choosen at this point?

Feel free to discuss this topic and post your results.

Maybe we could compare the dxe-setup routine with Dan's logic analyzer's output? It should make sense at some point.
The protocoll should be inside the driver, so exactly the requests should be followed by ("same") responces - if they're not XOR'ed with a timestamp or something to obfuscate it for us. -- By now the output may be interpreted wrong and there could be a need of re-sampling again. I don't want to discredit, I just want to rule out "dead ends".


And whatis this last dependency, which is on stack in the "FlashDriverSmm" but also in kinda all other runtime-related modules!?

However, the good news is - they are all reversable.
There is no luck I'm seeing myself accomplish the project due to couple of limiting factors. Time is being the most important one.
Therefore I'm open to people who want to get started with it, and will provide as much info as I can, to be able to grasp through this
topic all-together :)
 
Last edited:

gustav

Cable-Tie Ninja
Jun 18, 2020
186
83
Sorry guys, don't want to spam. Sometimes I simply have this moments...

1. Does anyone know where these codenames come from (PE32: "SecSMIFlash")
- Taishan
- Sandstone
- Huashan
- Shasta
found an answer: - chipset updates cover (Tiashan,Sandstone,Promontory,Huashan) -- those are chipset codenames

2. Error Codes? -- maybe we can see where they're used...

3. AmiFlashUpd

4. With time and reading & renaming / guessing it becomes more understandable

5. Ok, now I'm pretty sure "SecSMIFlash" is the FlashUtility which updates the actual BIOS.
1.


2.


3.


4.

If I search from string like "cpuid(0xbaccd00b)" at offset 0x00014c6a (you can look it up yourself) for "0xbaccd00b"...
It brings me results like this and this.

SMUDebugTool to access SMU which is to be found (undocumented(?)) on the PCIe-Root-Complex
 
Last edited:

Hammerfest

Trash Compacter
Jul 15, 2019
41
31
PSA Reminder:

If you haven't already, and if your on the "official" or "beta official" (IE not the ones from JZ), and having issue's with AGESA 1.0.0.1, you MUST open a ticket with ASRock or they will NEVER update it "officially".

The 3.60K "beta official" that updated it to AGESA Combo-AM4 1.0.0.4 Patch B fixed all the issues I HAD been having with the 2400G then 3400G in games (seriously, AMD AGESA updates fix so many things even for Zen!!!), and while I am currently on 3.60S (if I recall correctly) and have no issues in games or work programs either, the "official" release is STILL on 1.0.0.1 and is a buggy mess!

Make sure with your ticket you provide your ACTUAL issues along with proof that AGESA update fix's it, such as, going to 3.60K or the other beta's.
 
  • Like
Reactions: alles_alles