[Tool] Flashrom v1.2 [DOS] [AMD]

Here’s a compiled version of flashrom with Ryzen support (https://github.com/tolga9009/flashrom/tree/ryzen). It includes the libpci library so it supports the -p internal flag. It’s possible to compile libpci on Windows using MinGW and DJGPP so I’ve also attached the “libpci-libgetopt” folder with the pre-compiled libraries included so you can compile your own version easily.

Use this to compile it from MSYS:

make CC=i586-pc-msdosdjgpp-gcc STRIP=i586-pc-msdosdjgpp-strip LIBS_BASE=../libpci-libgetopt CONFIG_ENABLE_LIBUSB1_PROGRAMMERS=no

I've also included a version of Rufus that will create an MS-DOS boot disk. NOTE: You may need to enable the Compatibility Support Module (CSM) in your BIOS to boot it.

To backup your BIOS:
flashrom -p internal -r BACKUP.ROM

To write your own custom BIOS:
flashrom -p internal -w MOD.ROM

flashrom.zip (279 KB)

libpci-libgetopt.zip (185 KB)

Rufus_3.8.1579_Win10_MSDOS-Mod.zip (1.91 MB)

No AM4 mainboards handy now, will test it later and update result here.

Is it possible to create an EFI Shell version flashrom to flash Ryzen platform?
Some laptop do not have CSM.

flashrom requires DOS. If you don’t have the CSM option in your BIOS you can try setup_var to set CSM and / or disable BIOS Lock if you need to.

I am getting:

"No EEPROM/Flash device found"

I am on ASUS TUF GAMING X570-PLUS WiFi on BIOS 4002 at the moment

Using the DOS version…

Is there anything I can do?

I got this error today.

C:\>flashrom -p internal -w X3MSTX_1.70
flashrom on MS-DOS 8 (i786)
flashrom is free software, get the source code at https://flashrom.org
Calibrating delay loop... OK.
Found chipset "AMD FP4/FP5/AM4".
Enabling flash write... Disabling read write protection of flash addresses from Oxfc000000 to Oxfc85ffff failed.
Disabling read write protection of flash addresses from Oxfd000000 to Oxfd05ffff failed.
Disabling read write protection of flash addresses from Oxfe000000 to Oxfe05ffff failed.
Disabling read write protection of flash addresses from Oxff000000 to Oxff05ffff failed.
ERROR: State of SpiAccessMacRomEn or SpiHostAccessRomEn prohibits full access.
PROBLEMS, continuing anyway
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.

Looking into possible solutions.

So it looks like AGESA includes new security measures that render flashrom useless.

Before upgrading to a BIOS with AGESA or above it has been suggested to use UEFITool 0.26.0 and remove the following modules:

  • F2A29BBB-12D0-402B-90EC-4064A0C3DE5A / SMM module / AmdSpiRomProtect
  • C178E415-6E49-469A-B73D-F6C5EB4101EB / DXE driver / AmdSpiRomProtectDxe
  • 9D5FD24C-53DF-44AC-A336-B4879CDB29D9 / PEI module / AmdSpiRomProtectPei

Can anyone confirm that the above removes protection? Probably best to have a CH341A flash programmer + SOIC8 test clip cable in case it renders system non-bootable.

If you already flashed to a BIOS with AGESA or above you can try to flash to earlier BIOS (pre and clear CMOS and see if flashrom works again. I have not had any luck using this method.

Some more information I found on a forum:

@headkaze :
The Flashrom 1.2 Utitlities, which are attached to the start post of >this< thread, seem to work with my ASRock X570 Pro4 mainboard, although the in-use BIOS 4.20 contains the latest AGESA Patch C modules.
As you can see here, I was recently able to let the Flashrom 1.2 create a BACKUP of my mainboard’s current BIOS Region:

Flashrom v1.2 works.png

What I haven’t yet tested is flashing of a modded BIOS by using the Flashrom 1.2 Utilities.

It’s quite possible the new security features don’t inhibit the ability to use flashrom to make a backup of your BIOS and quite possibly you can still write a properly signed official BIOS. The problem is likely only with writing a custom modified BIOS.

$ sudo python3 chipsec_util.py mmio dump SPI
## ##
## CHIPSEC: Platform Hardware Security Assessment Framework ##
## ##
[CHIPSEC] Version : 1.7.0
[CHIPSEC] OS : Linux 5.14.0-custom #1 SMP Tue Aug 31 00:25:42 EDT 2021 x86_64
[CHIPSEC] Python : 3.9.5 (64-bit)

****** Chipsec Linux Kernel module is licensed under GPL 2.0
[CHIPSEC] API mode: using CHIPSEC kernel module API
[!] Unknown PCH: VID = 0x1022, DID = 0x790E, RID = 0xFF; Using Default.
[!] Results from this system may be incorrect.
[CHIPSEC] Helper : LinuxHelper (/home/***/Programming/chipsec/chipsec/helper/linux/chipsec.ko)
[CHIPSEC] Platform: Renoir Root Complex
[CHIPSEC] Executing command 'mmio' with args ['dump', 'SPI']

[CHIPSEC] Dumping SPI MMIO space..
[mmio] MMIO register range [0x00000000FEC10000:0x00000000FEC10000+000000FF]:
+00000000: 4F0C2105
+00000004: 00000000
+00000008: 00000600
+0000000C: 02000000
+00000010: 04042006
+00000014: 059F0406
+00000018: 020A0B03
+0000001C: 0206B8FF
+00000020: 10330713
+00000024: 20202008
+00000028: 0E06140C
+0000002C: 800054C0
+00000030: 460814CC
+00000034: 00000003
+00000038: FCFCFCFC
+0000003C: 000088FC
+00000040: EBBB6B3B
+00000044: 00000500
+00000048: 02000001
+0000004C: 00030002
+00000050: 0C131200
+00000054: ECBC6C3C
+00000058: 00004608
+0000005C: 00000000
+00000060: 00000000
+00000064: 000000FD
+00000068: 00000000
+0000006C: 00000000
+00000070: 00000000
+00000074: 00000000
+00000078: 00000000
+0000007C: 00000000
+00000080: 05000000
+00000084: DA001123
+00000088: 300665B1
+0000008C: C95F17BB
+00000090: 870ED138
+00000094: 0324F3C3
+00000098: F01DFA28
+0000009C: 95E8B95B
+000000A0: D75105C2
+000000A4: 82FEDDA5
+000000A8: 5CE01B8E
+000000AC: 8CF1F388
+000000B0: 07614F3A
+000000B4: 9D89E91B
+000000B8: 84145D79
+000000BC: 81DC60B7
+000000C0: FF765F24
+000000C4: 00000000
+000000C8: 00000000
+000000CC: 00000000
+000000D0: 00000000
+000000D4: 00000000
+000000D8: 00000000
+000000DC: 00000000
+000000E0: 00000000
+000000E4: 00000000
+000000E8: 00000000
+000000EC: 00000000
+000000F0: 00000000
+000000F4: 00000000
+000000F8: 00000000
[CHIPSEC] (mmio) time elapsed 0.002
sudo python3 chipsec_util.py mmio read SPI 0x0 0x4
[CHIPSEC] Read SPI + 0x0: 0x4F0C2105
0x4F0C2105 | (1 << 22) | (1 << 23) = 0x4FCC2105
sudo python3 chipsec_util.py mmio write SPI 0x0 0x4 0x4FCC2105
[CHIPSEC] Write SPI + 0x0: 0x4FCC2105
sudo python3 chipsec_util.py mmio read SPI 0x0 0x4
[CHIPSEC] Read SPI + 0x0: 0x4F0C2105
I guess it was worth a try!

@headkaze :
Please give us some additional information about your recent python tests while running Linux:
1. What exactly was the sense of your tests?
2. Which conclusions do you draw from the test results?
3. What have your python tests to do with the topic of this thread? Is the usage of python an alternative to the Flashrom tool?

Please put the python results into “spoilers” to save space.

Post #7 tells you the flash protection is SpiAccessRomEn (bit 22) and SpiHostAccessRomEn (bit 23) being cleared in the SPICntrl0 register (sudo python3 chipsec_util.py mmio dump SPI + 0x00). There’s a tool called chipsec which can read and write registers.

First I read the register sudo python3 chipsec_util.py mmio dump SPI + 0x0 which has a value of 0x4F0C2105, then I set bits 22 and 23, which gives 0x4FCC2105 and write this value back. Reading it again gives the original value of 0x4F0C2105. It demonstrates that these "clear-once protection bits" cannot be set again to remove the protection (as expected).

So, no solution to this? I would like to flash a modded BIOS with updated components… None of the other methods work so far

What about the usage of a programmer?

@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:
[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- here (maybe a new Mobo?) that can try that