@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).
chipsec has finally merged @kerneis-anssi’s amd updates.
So now you can run the following:
1
$ sudo python3 chipsec_util.py reg read SPICntrl0
Which will output something like the following:
1 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.
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: