Re: [flashrom] Big problem after flash of SST SST25VF016B on HP Compaq 615

[Carl-Daniel Hailfinger]

Hi Parallix,

I have re-added the flashrom list so others can follow our conversation.
I just wanted to avoid any BIOS images on the list for legal reasons.

On 09.01.2010 22:17, Parallix wrote:
> Am Samstag, 9. Januar 2010 21:55:56 schrieben Sie:
> > On 09.01.2010 20:33, Parallix wrote:
> > > COMPLETE.
> > > Verifying flash... VERIFY FAILED at 0x00010058! Expected=0x15, Read=0x05, failed byte count from 0x00000000-0x001fffff: 0x12d075
> > >
> > > A verification by reading the BIOS (via flashrom -r <file>) and comparing it with
> > > the original bios (via diff) shows the same difference.
> >
> > This is very odd. Can you try flashing the backup BIOS with unmodified
> > latest flashrom, then read back the result?
>
> I used the unpatched flashrom v0.9.1-r845.

Thanks.
> > Please mail me personally at  the
> > following files (preferably bz2 compressed):
> > original backup
>
> Is attatched
> > readback image after flashing with unmodified latest flashrom
>
> Is attachted, too. It contains a lot of identical bytes and thus results
> in a much smaller bz2 file.

Thanks.
> From your log file:
> Chip status register is 8c
> Chip status register: Block Protect Write Disable (BPL) is set

This means it is probably not possible to undo the locking.
> Chip status register: Auto Address Increment Programming (AAI) is not set
> Chip status register: Bit 5 / Block Protect 3 (BP3) is not set
> Chip status register: Bit 4 / Block Protect 2 (BP2) is not set
> Chip status register: Bit 3 / Block Protect 1 (BP1) is set
> Chip status register: Bit 2 / Block Protect 0 (BP0) is set
> Chip status register: Write Enable Latch (WEL) is not set
> Chip status register: Write In Progress (WIP/BUSY) is not set
> Resulting block protection : 1C0000H-1FFFFFH

The good news is that the erase result is as expected from the block
protection data.
The not-so-good news is that we need a board enable routine for your
laptop if we want to flash the protected blocks.
The bad news is that we probably need SuperIO or EC information (which
we don't have) to write the board enable routine.

Now let us focus on recovery.

Can you read back the flash chip again and compare it against the last
readback? They should be identical. If not, we have a really big problem
where some unknown software is modifying the flash chip.

Then try to write with a flashrom patched with the following patch. It
will also turn up at
http://patchwork.coreboot.org/project/flashrom/list/ shortly in case you
have problems extracting the patch from this mail.

Do not erase, check only if 0x0-0x1BFFFF is erased, then write 0x0-0x1BFFFF.

Signed-off-by: Carl-Daniel Hailfinger

Index: flashrom-parallix/spi.c
===================================================================
--- flashrom-parallix/spi.c	(Revision 845)
+++ flashrom-parallix/spi.c	(Arbeitskopie)
@@ -997,10 +997,11 @@
  */
 int spi_chip_write_1(struct flashchip *flash, uint8_t *buf)
 {
-	int total_size = 1024 * flash->total_size;
+	int total_size = 0x1C0000;
    int i, result = 0;

spi_disable_blockprotect();
+#if 0
    /* Erase first */
    printf("Erasing flash before programming... ");
    if (erase_flash(flash)) {
@@ -1008,6 +1009,11 @@
    	return -1;
    }
    printf("done.\n");
+#endif
+	if (check_erased_range(flash, 0, total_size)) {
+		fprintf(stderr, "WTF erased area failed erasecheck!\n");
+		return 1;
+	}
    for (i = 0; i < total_size; i++) {
    	result = spi_byte_program(i, buf[i]);
    	if (result)