[coreboot] Flash access on ASUS F2A85 variants

Rudolf Marek r.marek at assembler.cz
Sun May 4 13:56:03 CEST 2014


Hi Stefan,
 > I could not find any details but the error message one receives:
> "ERROR: State of SpiAccessMacRomEn or SpiHostAccessRomEn prohibits full
> access."

Found ITE Super I/O, ID 0x8603 on port 0x2e
Found chipset "AMD FCH" with PCI ID 1022:780e. Enabling flash write... SPI base 
address is at 0xfec10000
Hudson-2/3/4 detected.
SpiRomEnable=1, PrefetchEnSPIFromIMC=0, PrefetchEnSPIFromHost=1
(0x6f4c2105) SpiArbEnable=1, SpiAccessMacRomEn=1, SpiHostAccessRomEn=0, 
ArbWaitCount=7, SpiBridgeDisable=1, SpiBusy=0
ERROR: State of SpiAccessMacRomEn or SpiHostAccessRomEn prohibits full access.

> If I read the documentation of SpiHostAccessRomEn correctly then it
> should not bother us at all. It indicates it the ethernet firmware can
> access the host partition of the flash chip. If however the other bit
> (SpiAccessMacRomEn) is reset to 0 then we indeed have a problem.

Yes I tried to disable the check and got following (I was testing BIOS version 6502)

Found Winbond flash chip "W25Q64.V" (8192 kB, SPI).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
coreboot last image size (not ROM size) is 8388608 bytes.
Manufacturer: ASUS
Mainboard ID: F2A85-M
Reading old flash chip contents... FIFO pointer corruption! Pointer is 0, wanted 3
Something else is accessing the flash chip and causes random corruption.
Please stop all applications and drivers and IPMI which access the flash chip.
FAILED.
>
> Can someone please send me the verbose output of flashrom to confirm
> which one it is? And I am also looking for testers with these boards,
> because I think the abort on SpiHostAccessRomEn is a bug in flashrom.

Hm looks like something will happen, becuase it does not work. This board has 
external ethernet chip. So the only master accessing the chip could be USB 3.0
firmware. But, this works fine with coreboot and also removing the XHCI drivers 
did not help.

Maybe some protection bits are set elsewhere.

This is dump of MMIO space:

hexdump -C a.bin
00000000  05 21 4c 6f 00 00 00 00  00 06 00 00 00 70 00 02  |.!Lo.........p..|
00000010  06 20 04 04 06 04 9f 05  03 0b 0a 02 ff 88 00 3b  |. .............;|
00000020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*

It looks like (look to 48751 Rev 3.00 - May 30, 2013 BKDG for AMD Family 16h 
Models 00h-0Fh Processors)

SPIx1D Alt_SPI_CS  0x88

SpiProtectEn0. IF (SPIx1D[SpiProtectLock]==1) THEN Read-only. ELSE Read-write. 
ENDIF.

Reset: 0. 1=Enable SPI read/write protection ranges specified by 
D14F3x[5C,58,54,50].

Funny is that the SPiProtectLock is not set to 1

00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge (rev 11)
00: 22 10 0e 78 0f 00 20 02 11 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 27 85
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 04 00 00 00 d5 ff 03 ff 07 ff 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

And all protection ranges are 0 anyway...

60: 00 00 00 00 30 02 00 00 00 00 0f 00 00 ff ff ff
70: 67 45 23 00 00 00 00 00 9c 00 00 00 05 0b 00 00
80: 08 00 03 a8 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 00 c1 fe 2f 01 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 e9 45 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 17 00 82 ff
d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

And clearing the bit 4 of 1d also did not help. So it must be something else 
elsewhere.

I hope this is enough information for the start ;)

Thanks
Rudolf




More information about the coreboot mailing list