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.
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
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
September 2, 2017 5:39 PM, "Nico Huber" nico.h@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Nicola
Hi,
On 02.09.2017 21:02, Nicola Corna wrote:
September 2, 2017 5:39 PM, "Nico Huber" nico.h@gmx.de wrote:
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.
TLDR; it would be a lot slower.
Alas, there is no usual byte-program mode. Most chips do a 256B page program which uses op code 0x02 too. For the SST25VF032B it's really a 1B program. If you use that instead of the AAI write, you get lots of overhead (6B total, if I'm not mistaken, instead of ~1.5B per actual written byte + twice the polling for write-in-progress).
Nico
September 3, 2017 12:24 AM, "Nico Huber" nico.h@gmx.de wrote:
TLDR; it would be a lot slower.
Alas, there is no usual byte-program mode. Most chips do a 256B page program which uses op code 0x02 too. For the SST25VF032B it's really a 1B program. If you use that instead of the AAI write, you get lots of overhead (6B total, if I'm not mistaken, instead of ~1.5B per actual written byte + twice the polling for write-in-progress).
Nico
Thank you.
I've noticed that some boards have already an extra "finalize", which overrides the default opmenu and optype (see mb/siemens/mc_bdx1/mainboard.c): should I copy that implementation or add the configurations in the device tree and modify every sb/intel/*/pch.h (as you suggested before)?
Nicola
On 04.09.2017 19:31, Nicola Corna wrote:
September 3, 2017 12:24 AM, "Nico Huber" nico.h@gmx.de wrote:
TLDR; it would be a lot slower.
Alas, there is no usual byte-program mode. Most chips do a 256B page program which uses op code 0x02 too. For the SST25VF032B it's really a 1B program. If you use that instead of the AAI write, you get lots of overhead (6B total, if I'm not mistaken, instead of ~1.5B per actual written byte + twice the polling for write-in-progress).
Nico
Thank you.
I've noticed that some boards have already an extra "finalize", which overrides the default opmenu and optype (see mb/siemens/mc_bdx1/mainboard.c):
AFAICS, these boards use very different code paths with different inter- faces to override the op menu configuration.
should I copy that implementation or add the configurations in the device tree and modify every sb/intel/*/pch.h (as you suggested before)?
I didn't mean to suggest modifying every pch.h, but only sb/intel/ bd82x6x/finalize.c (the pch.h should stay intact to give defaults). It's probably easier if I put my idea into a patch for discussion. Stay tuned.
Nico
-
Nico Huber -
Nicola Corna