September 2, 2017 5:39 PM, "Nico Huber" <[email protected]> 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: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot Nicola _______________________________________________ flashrom mailing list [email protected] https://mail.coreboot.org/mailman/listinfo/flashrom
