@Fernando Well that would be the last resort, but I don’t think that would be practical for everyone though
@DarkPoe : Depending on the mainboard manufacturer it becomes more and more difficult to get a modded BIOS flashed the easy way.
chipsec has finally merged @kerneis-anssi’s amd updates.
So now you can run the following:
$ sudo python3 chipsec_util.py reg read SPICntrl0
Which will output something like the following:
2
3
4
5
6
7
8
9
10
11
[CHIPSEC] SPICntrl0=0x4F0C2105
[*] SPICntrl0 = 0x4F0C2105 << SPI_Cntrl0. Reset: 0FC0_0000h.
[18] SpiReadMode[0] = 1 << Read-write. Reset: 0. Bit[0] of SpiReadMode. See the definition of SpiReadMode[2:1] in this register. SpiReadMode = {SpiReadMode[2:1],SpiReadMode[0]}.
[21] IllegalAccess = 0 << Read-only. Reset: 0. 0=Legal index mode access. 1=Illegal index mode access.
[22] SpiAccessRomEn = 0 << Read,Write-0-only. Reset: 1. 0=Software cannot access MAC's portion of the ROM space (lower 512 KB). 1=Software can access MAC's portion of the ROM space. This is a clear-once protection bit. Once set, some SPI registers can't be written and discards a SPI request if it is an illegal request.
[23] SpiHostAccessRomEn = 0 << Read,Write-0-only. Reset: 1. 0=MAC cannot access BIOS ROM space (upper 512 KB). 1=MAC can access BIOS ROM space. This is a clear-once protection bit. Once set, some SPI registers can't be written and discards a SPI request if it is an illegal request.
[24] ArbWaitCount = 7 << Read-write. Reset: 7h. Specifies the amount of wait time the SPI controller asserts HOLD# before it should access the SPI ROM, under ROM sharing mode with the MAC. This time is to allow the MAC to sample HOLD#.
[27] SpiBridgeDisable = 1 << Read-write. Reset: 1. Setting this bit disables the SPI bridge mode (SB acts as a SPI-LPC bridge to the MAC).
[28] SpiClkGate = 0 << Read-write. Reset: 0. 1=Skip the 8th SPI clock at the end data when doing read.
[29] SpiReadMode[2:1] = 2 << Read-write. Reset: 0h. Description: See Table 78 [SpiReadMode[2:0]]. NOTE: SPI modes supported are listed below,
[31] SpiBusy = 0 << Read-only. Reset: 0. 0=SPI bus is idle. 1=SPI bus is busy.
Now you can clearly see that SpiAccessRomEn and SpiHostAccessRomEn are both set to 0. This means the BIOS ROM space is protected.
@DarkPoe the only way around this would be to remove the appropriate modules from the BIOS before upgrading as mentioned in my previous post.
I have yet to hear if anyone has done this successfully.
Well… I am tempted to buy a chip programmer because I believe it won’t be easier from here now on…
But yeah, it would be hard to find someone with pre-1.2.0.0 here (maybe a new Mobo?) that can try that
I tryed 2 days with efiflash 0.87 mod it dosent work with capsule …this tool works perkekt for my capsule gigabyte ga-ax370m-ds3h. I Love You.
i activated rezisabel Bar
IT WORKED!
I can confirm that after removing the DXE driver AmdSpiRomProtectDxe using UEFITool 0.28.0 flashrom can read the SPI again.
Tested on my Asrock Deskmini X300 bios version P1.80A
Hello, so by removing AmdSpiRomProtectDxe from the bios, any agesa 1.2.x.x could use flashrom in any means? is it only AmdSpiRomProtectDxe, or the entire AmsSpiRomProtect modules (normal, dxe, and Pei)?
Well the other modules don’t exist (i searched for the GUID) in the SPI flash image so i just removed the only one that exist and flashrom worked again.The bios P1.80A of the deskmini X300 has AGESA 1.2.0.7 so that it should work on any AGESA 1.2.x.x but when i can get my hands on the hardware i need to flash a WSON8 chip i can also test this on a Asus X570I motherboard.
Here is what CHIPSEC say after removing AmdSpiRomProtectDxe:
i am wondering if removing the amdspiromprotectpei is necessary too for the bios that have it
Good morning everyone! i am looking for the latest version of dos flashrom ch341a can you help me? thanks.
I mean the one that starts from prompt or windows. I’m looking for a more current version.
@papele
For the latest flashrom version you should better look >here<.
By the way - what has the tool to do with the CH341A programmer?
because it works with the ch341a programmer. I have seen but there is nothing.
Do you have Flashrom v1.3 compiled version
I’ve compiled flashrom version 1.4 and flashprog version 1.1, using MSYS2 and DJGPP (12.2.0 Standalone as per i write this, since i use MSYS2 instead of MinGW), based from information in this page, and sourced from both github page respectively (Flashrom | Flashprog), using pciutils 3.13.0 instead 3.5.6, and used CWSDPMI.EXE from pciutils-3.12.0-djgpp instead. Commands remain the same.
Both natively support Promontory AM4. Could be used on MS-DOS and FreeDOS. Since i use B550M Pro4 with 5700X, i couldn’t dump or flash/write due to im using AGESA 1.2.0.C and it does have AmdSpiRomProtectDxe, but the tool are able to detect my bios chip (Winbond W25Q256JW, i didnt know what my chip before i use this) and the platform i use.
Here are the files: Flashrom v1.4 DOS | Flashprog v1.1 DOS (CWSDPMI.EXE v3.12.0 included) (280.6 KB)
As always, DWYOR.
@Koekieezz
Thanks for the new/updated Flashrom version.
I will test it with my AMD X570 chipset system as soon as possible.
Thanks, i recommend bios agesa 1.2.0.3c or below, since your bios on last post (4.20) doesnt have AmdSpiRomProtectDXE, which is the reason why it could run flashrom.
Currently i am a bit interested in this but since i dont have ryzen 3100 (the minimum it could run on release bios), i got to halt my progress, or maybe trying to find a way to flash using CH341A on SPI_TPM_J1 once i have the jumper and 1.8v converter.
The plan is to flash on agesa older than 1.2.x.x, removing the protection DXE of latest bios for my board (ver L3.41), flash using either flashrom/flashprog, and test it. Or maybe if i could able to hot flash it i could just dump the latest bios, remove the protect dxe, then hotflash the protection-removed bios.
By any chance, do you know which Hex/GUID was used for asrock protection that you mentioned here?
I am trying to find a way possible to access the bios without hardware meddling (also if possible, removing the secure flash check), since the bios chip is WSON8 config. Does the UBU method did not work? Like if i were to dump my stock flashed bios with internal update from bios > remove protectdxe + use UBU remove secure flash check > flash the modded apr_bios.rom, would it remove the secure flash check from bios, so that i wont need to use flashrom/prog (since if i update the bios from old bios to new stock unflashed bios it might remove UUID). For 32MB asrock bioses ofc.
EDIT: It looks that emptying SubGUID 5A88641B-BBB9-4AA6-80F7-498AE407C31F leaving hex E4 07 C3 1F only, might disable it (based on Lost_n_Bios Screenshots)? I’ve been reading this post from lordkag, wondering if it is appliable to amd bioses.
There are 2 of the mentioned SubGUID in recent asrock bioses, the idea is “what if” both SubGUID is filled with FF but leaving the hex E4 07 C3 1F only intact? Would it Disable it? Like if you’re able to pull your bios using Flashrom > make a copy of the dump > edit both subguid to FF’s but leaving hex E4 07 C3 1F still there, save it, flash the "FWCapsule “removed” " Bios > Download latest bios, do the same fill both SubGUID Mentioned with FF’s leaving hex E4 07 C3 1F only + remove AmdSpiRomProtectDXE in the latest stock bios, so that now you have the latest bios with "FWCapsule “removed” " Bios and the RomProtectDXE removed > Flash that bios > Now your board could accept modded bios either using flashrom/prog or using instant tool IF it actually succeed.
TL;DR: Dump current bios without RomProtectDXE> Edit HEX on mentioned SubGUIDs > flash that modded current bios > download the latest bios and do the same with HEX, but also remove RomProtectDXE > flash that latest modified bios (verify if instant flash is bypassed) > verify if Internal Flasher in the latest-modiied bios are able to flash modded bios.
If it is able to, then everytime a bios is modded they must do that HEX method but also remove the RomProtectDXE, if they want the convinient bios update without worrying the UUID, SN, MAC, etc getting removed each time they want to update, since flashrom flashes the bios as-is, which is a bit inconvinient unless it is the dump of the flahshed latest bios/the bios they desire and they use that dump to modify anything, they wont lose the data.
The currently latest BIOS for my mainboard has AGESA 1.2.0.C. So the Flashrom tool may not work with it.
By the way - don’t expect this month any test results from my side.
Hello @Fernando , I successfully remove the AmdSpiRomProtectDXE from my bios dump using ch341a, and i could confirm that, official bios → flashed to board using instant flash → dump that bios from bios chip (i use SPI_TPM_J1 + CH341A for it) → remove the dxe = Flashprog/Flashrom is working again, and yes im on agesa 1.2.0.C, so it is really the dxe that prevents it, and yours are able to be used without any modification (supposedly). Below i attach some success:
Read:
Write:
Result:
I didn’t include the flashrom pic in write part, but i did test it and it was the same as flashprog. I personally recommends Flashprog as it does maintained and the author keeping it up to date.