[flashrom] [coreboot] Erase failure on Sapphire Pure Platinum H61 with coreboot

[Nicola Corna]

September 2, 2017 5:39 PM, "Nico Huber" <nico.h at gmx.de> wrote:

> Hi Nicola,
> 
> On 02.09.2017 15:06, Nicola Corna wrote:
> 
>> Hi,
>> 
>> I have a Sapphire Pure Platinum H61 with coreboot and flashrom fails
>> to erase the flash chip (corrupting the image); attached you can find
>> the log.
> 
> oh, the error message is rather subtle. I'll spare you the details.
> The actual problem is that your flash chip is rather unlikely and the
> write aai (0xad) and write disable (0x04) op codes are not in the list
> coreboot set as allowed op codes:
> 
>> 0x98: 0x05030201 (OPMENU)
>> 0x9C: 0x0bd89f20 (OPMENU+4)
> 
> Each byte here is one allowed op code. Now, to makes things worse, core-
> boot and flashrom use different sets of codes (e.g. flashrom uses read
> (0x03), coreboot uses fast read (0x0b)). The currently hardcoded list
> is define in sb/intel/bd82x6x/pch.h for your board. For full compatibi-
> lity with every coreboot feature that uses the flash (e.g. elog, flash
> console) and flashrom, you'd have to find a set of op codes that always
> works.
> 
> One question, though, is this the original flash chip of your board? If
> not, any effort to make it supported is probably wasted. If it is the
> original chip, I'd go this way: Make the op menu that coreboot sets in
> bd82x6x/finalize.c configurable through the devicetree. I'd leave the
> defaults from pch.h in place in case the devietree settings are left at
> zero.

Thanks for the explanation. Yes, it's the original flash chip.

> From the original op menu these are probably unneeded: byte program
> (0x02), either one of the block erasers (0x20 and 0xd8) and the fast
> read (0x0b).
> 
> Probably working (with flashrom) op menu for your chip:
> 
> 0x05030201
> 0x04ad9f20

I've modified the OPMENU 6 and 7 in sb/intel/bd82x6x/pch.h with this

#define SPI_OPMENU_6 0xad /* AAI write */
#define SPI_OPTYPE_6 0x01 /* Write, no address */

#define SPI_OPMENU_7 0x04 /* Write disable */
#define SPI_OPTYPE_7 0x01 /* Write, no address */

and indeed it works now.

There's only one thing that I don't understand: why is it preferable to
modify the allowed op codes in coreboot instead of modifying the default
write mode for the SST25VF032B in flashrom? From its datasheet I see
that it supports the usual byte-program mode in addition to the AAI mode.

>> Before coreboot's commit d533b16 the internal flashing worked after a
>> fresh start, while after a S3 resume it failed with the same error.
>> Starting from this commit, the internal flashing doesn't work at all.
> 
> For the record, this commit enabled the SPI lockdown (e.g. locked the
> OPMENU). Which was previously only set after resume by accident.
> 
>> As suggested by Nico Huber, I tried with `-p
>> internal:ich_spi_mode=hwseq`, without success (log attached).
> 
> Ah, I see why it didn't detect a chip. In the hardware sequencing mode,
> the actual communication with the flash chip is left to the PCH. We
> can't even probe for the chip, so giving it `-c SST25VF032B` makes it
> fail.
> 
> Nico
> 
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot

Nicola