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" <[email protected]> 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. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner
>From e949a68cc4af8fe4998815ad2a899e7a4dd4e073 Mon Sep 17 00:00:00 2001 From: Stefan Tauner <[email protected]> Date: Tue, 30 Jul 2013 16:32:30 +0200 Subject: [PATCH] ichspi: Fix printing address ranges if space is divided by FPB. Signed-off-by: Stefan Tauner <[email protected]> --- ichspi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ichspi.c b/ichspi.c index 4f6a1b1..6d1bd1a 100644 --- a/ichspi.c +++ b/ichspi.c @@ -1210,7 +1210,7 @@ static int ich_hwseq_probe(struct flashctx *flash) } else { msg_cdbg("The flash address space (0x%06x - 0x%06x) is divided " "at address 0x%06x in two partitions.\n", - 0, size_high-1, boundary); + 0, total_size-1, boundary); size_low = total_size - size_high; erase_size_low = ich_hwseq_get_erase_block_size(0); @@ -1224,7 +1224,7 @@ static int ich_hwseq_probe(struct flashctx *flash) eraser->eraseblocks[1].size = erase_size_high; eraser->eraseblocks[1].count = size_high / erase_size_high; msg_cdbg("The second partition ranges from 0x%06x to 0x%06x.\n", - boundary, size_high-1); + boundary, total_size-1); msg_cdbg("In that range are %d erase blocks with %d B each.\n", size_high / erase_size_high, erase_size_high); } -- Kind regards, Stefan Tauner
_______________________________________________ flashrom mailing list [email protected] http://www.flashrom.org/mailman/listinfo/flashrom
