Hello Marek,
thanks for checking again! Everything is clear now. I have added your board and the chipset to our list of supported hardware and will commit that later together with other small changes. I'll explain a few bits below to whom it may concern, and if you like you could help verifying a tiny patch explained in the second halve of this mail.
On Tue, 30 Jul 2013 12:26:33 +0200 "Marek Zakrzewski" zakrzewskim@wp.pl wrote:
[…] Reading OPCODES... done OP Type Pre-OP op[0]: 0x02, write w/ addr, none op[1]: 0x3b, read w/ addr, none op[2]: 0x20, write w/ addr, none op[3]: 0x05, read w/o addr, none op[4]: 0x9f, read w/o addr, none op[5]: 0x01, write w/o addr, none op[6]: 0x00, read w/o addr, none op[7]: 0x00, read w/o addr, none Pre-OP 0: 0x06, Pre-OP 1: 0x00
This is the table of opcodes we are allowed to use by the configuration of your board.
[…] 0x98: 0x05203b02 (OPMENU) 0x9C: 0x0000019f (OPMENU+4)
Which is encoded in these registers. I misread it in your first mail, but now it is clear why hardware sequencing was enabled: because opcode 0x03 is not possible, which is the read opcode, hence it would not be able to read the chip at all without hw sequencing.
[…] Enabling hardware sequencing because some important opcode is locked. SPI Read Configuration: prefetching enabled, caching enabled, OK. The following protocols are supported: FWH, Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Found 1 attached SPI flash chip with a density of 16384 kB. The flash address space (0x000000 - 0x9acfff) is divided at address 0x653000 in two partitions.
The calculation of the top address was wrong. The size of the second partition was used instead of the total chip size. It should have been 0xffffff instead of 0x9acfff above and...
The first partition ranges from 0x000000 to 0x652fff. In that range are 1619 erase blocks with 4096 B each. The second partition ranges from 0x653000 to 0x9acfff.
here ^.
In that range are 2477 erase blocks with 4096 B each.
This is just a minor, cosmetic problem which should be fixed by the patch attached. It should apply on top of any recent flashrom revision I think, if in doubt please use the latest one, i.e. r1705. I will apply the patch even if you don't test, but every verification is welcomed of course.