[PATCH] Fix flashrom init for VT8237S
Hello, Following patch fixes VIA SPI (VT8237S). It needs to have opcodes initialized same way as ICH7. Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Oh btw there is some logic problem with the flashrom -E. The spi_chip_erase_c7 gets called for mine chip: result = spi_disable_blockprotect(); if (result) { printf_debug("spi_disable_blockprotect failed\n"); return result; } result = spi_write_enable(); if (result) { printf_debug("spi_write_enable failed\n"); return result; } But it will fail sending spi_write_enable() because: int spi_write_enable() { const unsigned char cmd[JEDEC_WREN_OUTSIZE] = { JEDEC_WREN }; /* Send WREN (Write Enable) */ return spi_command(sizeof(cmd), 0, cmd, NULL); } And final fail: /* unknown / not programmed command */ if (opcode_index == -1) { printf_debug("Invalid OPCODE 0x%02x\n", cmd); return 1; } Because its just a prefix opcode. And prefix opcodes are not checked. Question is now what to do. Silently complete command the spi_write_enable, when we find the opcode in prefix opcode? The prefix opcode should get executed with the prefix automatically. Rudolf
On Fri, Dec 26, 2008 at 7:59 PM, Rudolf Marek <r.marek@assembler.cz> wrote:
Hello,
Following patch fixes VIA SPI (VT8237S). It needs to have opcodes initialized same way as ICH7.
I am glad that the OPCODE patch is more useful than scratching my own itch :-)
Because its just a prefix opcode. And prefix opcodes are not checked. Question is now what to do. Silently complete command the spi_write_enable, when we find the opcode in prefix opcode? The prefix opcode should get executed with the prefix automatically.
For an ad hoc solution, we can ignore the request to execute a command in ich_spi_command if we find that command is a preop. Later when chip erase is executed, some predefined (in pops[] ) preop will be picked up. However, I don't think it should be fixed in that way. One of the problems behind is design inconsistency in different operations. For chip/block/sector erase operations, spi_write_enable is integrated into those operations; for byte program, spi_write_enable is not integrated. yu ning
On Fri, Dec 26, 2008 at 9:47 PM, FENG Yu Ning <fengyuning1984@gmail.com> wrote:
For chip/block/sector erase operations, spi_write_enable is integrated into those operations;
I meant spi_write_enable is called explicitly.
for byte program, spi_write_enable is not integrated.
Whether preop will be sent or which preop will be sent before BYTE_PROGRAM is specified in struct OPCODES. Maybe whether to call spi_write_enable in spi_xxx_erase should be flash bus specific. yu ning
Maybe whether to call spi_write_enable in spi_xxx_erase should be flash bus specific.
Yes or we can ignore the pre op in ich code. Because then another command will be find in the table (assuming that it will always need a pre-op - is this true?) The WREN pre op is defined in JEDEC somewhere to be atomic? Any pointers to docs? Thanks, Rudolf
On Sat, Dec 27, 2008 at 1:24 AM, Rudolf Marek <r.marek@assembler.cz> wrote:
Yes or we can ignore the pre op in ich code. Because then another command will be find in the table (assuming that it will always need a pre-op - is this true?)
I have only investegated few SPI flash chips. For SST25 series, WREN is required before every time a write/erase command is to be sent. There are other people here who is familiar with much more chips than me. Carl-Daniel, can you help answer Rudolf's question?
The WREN pre op is defined in JEDEC somewhere to be atomic? Any pointers to docs?
There are atomicity issues in ICHx because they can share flash chips for BIOS and some on-board network controllers. Therefore I don't think JEDEC document will mention it. (Very appreciated if anyone familiar with JEDEC standard can help.) I have not read about atomicity issues in flash chip datasheets, only in ICH specs. yu ning
Rudolf Marek wrote:
Following patch fixes VIA SPI (VT8237S). It needs to have opcodes initialized same way as ICH7.
Signed-off-by: Rudolf Marek <r.marek@assembler.cz>
Acked-by: Peter Stuge <peter@stuge.se>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Committed revision 3926 Although the just erase dont work... its better then nothing. Is there some consensus how to fix that while I was away? Thanks, Rudolf -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmF7RQACgkQ3J9wPJqZRNW8XgCg2aub3W99EfwhBmpkqauAcqFN xtQAnAy/irxfR9knrMM4NEjYmukHRVXp =G5yq -----END PGP SIGNATURE-----
participants (3)
-
FENG Yu Ning -
Peter Stuge -
Rudolf Marek