[flashrom] flashrom OPCODES for SPI

[Stefan Tauner]

On Wed, 12 Dec 2012 11:13:49 +0400
Николай Николаев <evrinoma at gmail.com> wrote:

> i'm trying to reprogram spi chip with bios. My sdk-board is consist from
> motherboard and especial board. Motherboard has own flash bios chip like a
> mx25l6405 and chip SPI interface QM67. Especial board has a spi flash chip
> sst25vf016. Used jumpers i'm easy select flash bios chip for programming,
> and i select chip sst25vf016. Chip set QM67 is locked to change value
> registers opcodes and preop codes. This is codes value match with mx25l6405
> codes. And i can't reprogram selected chip, because opcodes select chip
> didn't match with opcodes stored in QM67.
> In function
> spi_write_status_register Flashrom source code algorithm trying change mode
> spi status register to write by sending unlock command JEDEC_WRSR and
> JEDEC_EWSR = 0x50. But preop codes register have a value JEDEC_WREN=0x06,
> and don't have a value JEDEC_EWSR=0x50. And STATUS register can't be
> unlocked, if i change value JEDEC_EWSR on 0x06 (chip sst25vf016 support
> this code) the STATUS register is unlock successful.

Hi,

I don't have a complete SST25VF016 datasheet. In the SST25VF080
datasheet WREN is mentioned but not in relation to WRSR but only
"normal" erase/write functions. The SST25VF016B datasheet however
clearly states:
"The WREN instruction may also be used to allow execution of the
Write-Status-Register (WRSR) instruction"

It is of course possible that both, the SST25VF080 and the SST25VF016,
support WREN for WRSR and your report is a good hint that this is true.
Can you confirm that you have the SST25VF016 and not some variation
like the SST25VF016B?

The "right" way to add support for you would have been to change the
chip definition of the SST25VF016B in flashchips.c by swapping
FEATURE_WRSR_EWSR for FEATURE_WRSR_EITHER. As you saw in
spi_write_status_register, using WREN is the default if both are
supported (or none is selected). I have done so in my local branch for
the 016 and 80(A) chips and will commit that later.

> And now we have a read
> and erase function but function write doesn't work, because algorithm use
> default_spi_write_aai function. That function use opcode
> JEDEC_AAI_WORD_PROGRAMM but opcodes and preopcodes registers doesn't have
> this code and we can't write new bios image in flash. But if we will be use
> function spi_chip_write_1 we successful write our image into flash chip
> sst25vf016.

Good.

> What you think about, if we exclude some parameters from structure FLASHCTX
> (like a feature_bits) and add array of OPCODES (with real opcodes for real
> chip) and add function to detect access opcodes for used chips?

There is nothing wrong with the feature bits, although the chipset code
(in your case ichspi.c) could be more intelligent in handling this
(ATM the write enable commands are handled by generic code only). The
Intel chipsets are very special and your case even more, so I don't want
to introduce complicated changes just because of this (also with the fix
i mentioned earlier, it should just work now even on your configuration,
feel free to disprove me).

The write command/opcode is different. Clearly we want to have
something similar to the erasers so that we can have multiple write
functions/opcodes per flash chip. This is on my TODO list, but I don't
have much time to work on it...

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner