Re: [e-mail] post from [e-mail] requires approval

[Misha Wiesel]

Good morning.
                You are right, the revised message was sent to your mailbox only. I am resending it to [e-mail], too, as you requested.

[ULP-NG]# ./flashrom -p internal -V -c W25Q256JV_M -w COB_G509_000_v007.BIN
flashrom v1.1 on Linux 4.15.18-1-ULP-NG+ (x86_64)
flashrom is free software, get the source code at https://flashrom.orghttps://clicktime.symantec.com/3Vrx3RWZjMwHS9TMzsSaiWF6H2?u=https%3A%2F%2Fflashrom.org

flashrom was built with libpci 3.5.2, GCC 7.4.0, little endian
Command line (7 args): ./flashrom -p internal -V -c W25Q256JV_M -w COB_G509_000_
v007.BIN
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Initializing internal programmer
/sys/class/mtd/mtd0 does not exist
No coreboot table found.
Using Internal DMI decoder.
DMI string chassis-type: "Desktop"
DMI string system-manufacturer: "Default string"
DMI string system-product-name: "Default string"
DMI string system-version: "Default string"
DMI string baseboard-manufacturer: "Default string"
DMI string baseboard-product-name: "Default string"
DMI string baseboard-version: "Default string"
Found chipset "Intel C627 Series Chipset (QS/PRQ)" with PCI ID 8086:a1c6.
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with it,
then please email a report to [e-mail] including a verbose (-V) log
.
Thank you!
Enabling flash write... BIOS_SPI_BC = 0x8aa: BIOS Interface Lock-Down: enabled,
Boot BIOS Straps: 0x0 (SPI)
Top Swap: not enabled
SPI Read Configuration: prefetching enabled, caching enabled,
BIOS_CNTL = 0xaa: BIOS Lock Enable: enabled, BIOS Write Enable: disabled
Warning: BIOS region SMM protection is enabled!
Warning: Setting Bios Control at 0xdc from 0xaa to 0x89 failed.
New value is 0xaa.
SPIBAR = 0x00007f4dca80c000 (phys = 0xfe010000)
0x04: 0xc800 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, SCIP=0, PRR34_LOCKDN=0, WRSDIS=1, FDOPSS=0, FDV=1
, FLOCKDN=1
SPI Configuration is locked down.
The Flash Descriptor Override Strap-Pin is set. Restrictions implied by
the Master Section of the flash descriptor are NOT in effect. Please note
that Protected Range (PR) restrictions still apply.
Reading OPCODES... done
0x06: 0x0200 (HSFC)
HSFC: FGO=0, HSFC=0, WET=0, FDBC=2, SME=0
0x0c: 0x00000000 (DLOCK)
DLOCK: BMWAG_LOCKDN=0, BMRAG_LOCKDN=0, SBMWAG_LOCKDN=0, SBMRAG_LOCKDN=0,
       PR0_LOCKDN=0, PR1_LOCKDN=0, PR2_LOCKDN=0, PR3_LOCKDN=0, PR4_LOCKDN=0,
       SSEQ_LOCKDN=0
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-
write.
0x58: 0x1fff1000 FREG1: BIOS region (0x01000000-0x01ffffff) is read-write.
0x5C: 0x0a350003 FREG2: Management Engine region (0x00003000-0x00a35fff) is read
-write.
0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-
write.
0x80: 0x0fef0a36 FREG11: unknown region (0x00a36000-0x00feffff) has unknown perm
issions.
0xa0: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0xa1: 0xfe0000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=6
0xa4: 0x0000     (PREOP)
0xa6: 0x0000     (OPTYPE)
0xa8: 0x00000000 (OPMENU)
0xac: 0x00000000 (OPMENU+4)
Enabling hardware sequencing because some important opcode is locked.
PROBLEMS, continuing anyway
The following protocols are supported: Parallel, LPC, FWH, Programmer-specific.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
Restoring PCI config space for 00:1f:5 reg 0xdc
[ULP-NG]#

From: David Hendricks 
Sent: יום ה 14 נובמבר 2019 20:52
To: Misha Wiesel 
Subject: Re: [e-mail] post from [e-mail] requires approval

Thanks, Misha. One more thing - Can you please send the revised message to the mailing list? It seems it was only sent to my personal email account.

On Thu, Nov 14, 2019 at 1:01 AM Misha Wiesel <[e-mail]> wrote:

Good morning.

As you say, I copy the output of “exact chip” with -V (not -VVV) into the message.

Also, as far as I saw during my own minor “experiments”, it seems the flashrom does not detect the SPI bus presence at the programmer side…

[ULP-NG]# ./flashrom -p internal -V -c W25Q256JV_M -w COB_G509_000_v007.BIN
flashrom v1.1 on Linux 4.15.18-1-ULP-NG+ (x86_64)
flashrom is free software, get the source code at https://flashrom.orghttps://clicktime.symantec.com/3Vrx3RWZjMwHS9TMzsSaiWF6H2?u=https%3A%2F%2Fflashrom.org

flashrom was built with libpci 3.5.2, GCC 7.4.0, little endian
Command line (7 args): ./flashrom -p internal -V -c W25Q256JV_M -w COB_G509_000_
v007.BIN
Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Initializing internal programmer
/sys/class/mtd/mtd0 does not exist
No coreboot table found.
Using Internal DMI decoder.
DMI string chassis-type: "Desktop"
DMI string system-manufacturer: "Default string"
DMI string system-product-name: "Default string"
DMI string system-version: "Default string"
DMI string baseboard-manufacturer: "Default string"
DMI string baseboard-product-name: "Default string"
DMI string baseboard-version: "Default string"
Found chipset "Intel C627 Series Chipset (QS/PRQ)" with PCI ID 8086:a1c6.
This chipset is marked as untested. If you are using an up-to-date version
of flashrom *and* were (not) able to successfully update your firmware with it,
then please email a report to [e-mail] including a verbose (-V) log
.
Thank you!
Enabling flash write... BIOS_SPI_BC = 0x8aa: BIOS Interface Lock-Down: enabled,
Boot BIOS Straps: 0x0 (SPI)
Top Swap: not enabled
SPI Read Configuration: prefetching enabled, caching enabled,
BIOS_CNTL = 0xaa: BIOS Lock Enable: enabled, BIOS Write Enable: disabled
Warning: BIOS region SMM protection is enabled!
Warning: Setting Bios Control at 0xdc from 0xaa to 0x89 failed.
New value is 0xaa.
SPIBAR = 0x00007f4dca80c000 (phys = 0xfe010000)
0x04: 0xc800 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, SCIP=0, PRR34_LOCKDN=0, WRSDIS=1, FDOPSS=0, FDV=1
, FLOCKDN=1
SPI Configuration is locked down.
The Flash Descriptor Override Strap-Pin is set. Restrictions implied by
the Master Section of the flash descriptor are NOT in effect. Please note
that Protected Range (PR) restrictions still apply.
Reading OPCODES... done
0x06: 0x0200 (HSFC)
HSFC: FGO=0, HSFC=0, WET=0, FDBC=2, SME=0
0x0c: 0x00000000 (DLOCK)
DLOCK: BMWAG_LOCKDN=0, BMRAG_LOCKDN=0, SBMWAG_LOCKDN=0, SBMRAG_LOCKDN=0,
       PR0_LOCKDN=0, PR1_LOCKDN=0, PR2_LOCKDN=0, PR3_LOCKDN=0, PR4_LOCKDN=0,
       SSEQ_LOCKDN=0
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-
write.
0x58: 0x1fff1000 FREG1: BIOS region (0x01000000-0x01ffffff) is read-write.
0x5C: 0x0a350003 FREG2: Management Engine region (0x00003000-0x00a35fff) is read
-write.
0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-
write.
0x80: 0x0fef0a36 FREG11: unknown region (0x00a36000-0x00feffff) has unknown perm
issions.
0xa0: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0xa1: 0xfe0000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=6
0xa4: 0x0000     (PREOP)
0xa6: 0x0000     (OPTYPE)
0xa8: 0x00000000 (OPMENU)
0xac: 0x00000000 (OPMENU+4)
Enabling hardware sequencing because some important opcode is locked.
PROBLEMS, continuing anyway
The following protocols are supported: Parallel, LPC, FWH, Programmer-specific.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
Restoring PCI config space for 00:1f:5 reg 0xdc
[ULP-NG]#

From: David Hendricks <[e-mail]>
Sent: יום ה 14 נובמבר 2019 07:56
To: Misha Wiesel <[e-mail]>
Subject: Re: [e-mail] post from [e-mail] requires approval

Hello Misha,
Your e-mail got stuck in the moderation queue due to the large attachments. I suggest copy & pasting write-flash-exact-chip.log directly into the body of the e-mail. The other logs are quite large (-V is usually sufficient, -VVV is extra verbose for development) and might not be much help.

On Wed, Nov 13, 2019 at 8:37 AM <[e-mail]> wrote:
As list administrator, your authorization is requested for the
following mailing list posting:

List:    [e-mail]
    From:    [e-mail]
    Subject: Flashrom 1.1 + C627 board + W25Q256* flash chip

The message is being held because:

The message is not from a list member

At your convenience, visit your dashboard to approve or deny the
request.

---------- Forwarded message ----------
From: Misha Wiesel <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc:
Bcc:
Date: Wed, 13 Nov 2019 16:37:22 +0000
Subject: Flashrom 1.1 + C627 board + W25Q256* flash chip

Good morning.
                I am trying to write the SPI flash using the Fashrom v1.1 for C627 board (Intel PCH) and flash chip W25Q256 JV M.
                According to release notes for version 1.1, these HW components are supported already by flashrom. But I encounter problems. As it is being asked by flashrom utility, I report about it. Following some details:

1.       First, I read the existing flash. See the attached log file “read-flash.log”.

2.       Then, I try to write the flash (from its original image) using the -c option. The write fails. See the attached log “write-flash-exact-chip.log”.

3.       Next, I try to write the flash (from the same image) followed by verification, but without -c option. See the attached log “write-verify-flash.log”.

a.       If it will help… The verification reports an error at address 0x1000008f (values f8 vs f0). Comparison of original and read from flash chip images shows the same difference at the same offset.

4.       The flashrom I used was downloaded from the flashrom.orghttps://clicktime.symantec.com/3MEY6WtGEXZe52MGS5LGKvf6H2?u=http%3A%2F%2Fflashrom.org, version 1.1. Compiled locally under Ubuntu 18.04:

a.       Build machine kernel version: 4.15.0

b.       Target machine kernel version: 4.15.18

c.       ‘make’ version : GNU Make 4.1

d.       ‘cc’ version : cc (Ubuntu 7.4.0-1ubunutu-1~18/04/1) 7.4.0

e.       Build command: make CONFIG_ENABLE_LIBUSB0_PROGRAMMERS=no CONFIG_ENABLE_LIBUSB1_PROGRAMMERS=no

5.       If it is essential: the build environment and the target are not the same machine. Both machines are x86_64, running kernel 4.15 (different revisions) and Ubuntu 18.04 (different set of packages installed).

---------- Forwarded message ----------
From: [e-mail]
To:
Cc:
Bcc:
Date: Wed, 13 Nov 2019 16:37:35 +0000
Subject: confirm 4a0a115cd8f10c51539c5dcaa3861e3efba29d0f
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message.  Do this if the message is
spam.  If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list.  The Approved: header can also appear in the first line
of the body of the reply.

[e-mail] post from [e-mail] requires approval

[Nico Huber]

Hi Misha,
> ---------- Forwarded message ----------
> From: Misha Wiesel <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Cc:
> Bcc:
> Date: Wed, 13 Nov 2019 16:37:22 +0000
> Subject: Flashrom 1.1 + C627 board + W25Q256* flash chip
>             Good morning.
>             I am trying to write the SPI flash using the Fashrom v1.1 for C627 board (Intel PCH) and flash chip W25Q256 JV M.
>             According to release notes for version 1.1, these HW components are supported already by flashrom. But I encounter problems. As it is being asked by flashrom utility, I report about it. Following some details:
>
>
>   First, I read the existing flash. See the attached log file “read-flash.log”.
>
>   Then, I try to write the flash (from its original image) using the -c option. The write fails. See the attached log “write-flash-exact-chip.log”.

Intel doesn't allow direct access to the flash chip with your chipset.
Hence, the chip never shows up by its actual name "W25Q256JV_M" but
only as "Opaque flash chip" and the `-c` option is futile.
>   Next, I try to write the flash (from the same image) followed by verification, but without -c option. See the attached log “write-verify-flash.log”.
>
> a.       If it will help… The verification reports an error at address 0x1000008f (values f8 vs f0). Comparison of original and read from flash chip images shows the same difference at the same offset.

Do you know exactly what the firmware of your mainboard does? It's
possible that some other process also tries to write to the chip (e.g.
firmware in SMM). You could try the same command again and see if it
gives different results. Sometimes it just works by chance. But I can
only advice to continue if you have means to recover from a bad flash.

Hope that helps,
Nico

[e-mail] post from [e-mail] requires approval

[Misha Wiesel]

Good morning.

Thank you for your responses.
> Intel doesn't allow direct access to the flash chip with your chipset.
> Hence, the chip never shows up by its actual name "W25Q256JV_M" but only as "Opaque flash chip" and the `-c` option is futile.

Ok, got you.
> Do you know exactly what the firmware of your mainboard does?

When you say "firmware", do you mean BIOS? Or some [other] board-specific firmware? 
    To answer your question I will likely need to query the mainboard vendor, so I need to know what exactly I should ask them...
> It's possible that some other process also tries to write to the chip (e.g. firmware in SMM).

I do not think something else is trying to access the chip at the same time. During my tests, I am running, say, "a minimal system": it is a reduced Ubuntu 18.04 in command-line mode, without any graphics and most of user services/tools; all network interfaces are down, and so all network services are not active, etc.
> You could try the same command again and see if it gives different results. Sometimes it just works by chance.

I tried the same command(s) many time. The result is always the same: error at the same offset [above 128M], and the same f0 vs. f8.
    As far as I can assume according to the offset of the failure, it looks like the "Opaque flash chip" cannot deal correctly with a flash chip of size of 256M (or, of size over 128M)...
> But I can only advice to continue if you have means to recover from a bad flash.

It is not about a single recovery for the bad flash. I have to have a tool that works stable. The goal is to be able to recover/update flash (bios) at any moment with minimal probability of failure.

By the way, do the flashrom requires some specific settings/parameters/etc. in the kernel (kernel.cfg)?

-----Original Message-----
From: Nico Huber  
Sent: יום ב 18 נובמבר 2019 12:23
To: Misha Wiesel ; David Hendricks ; [e-mail]
Subject: Re: [flashrom] Re: [e-mail] post from [e-mail] requires approval

Hi Misha,
> ---------- Forwarded message ----------
> From: Misha Wiesel <[e-mail]>
> To: "[e-mail]" 
> <[e-mail]>
> Cc:
> Bcc:
> Date: Wed, 13 Nov 2019 16:37:22 +0000
> Subject: Flashrom 1.1 + C627 board + W25Q256* flash chip
>             Good morning.
>             I am trying to write the SPI flash using the Fashrom v1.1 for C627 board (Intel PCH) and flash chip W25Q256 JV M.
>             According to release notes for version 1.1, these HW components are supported already by flashrom. But I encounter problems. As it is being asked by flashrom utility, I report about it. Following some details:
>
>
>   First, I read the existing flash. See the attached log file “read-flash.log”.
>
>   Then, I try to write the flash (from its original image) using the -c option. The write fails. See the attached log “write-flash-exact-chip.log”.

Intel doesn't allow direct access to the flash chip with your chipset.
Hence, the chip never shows up by its actual name "W25Q256JV_M" but only as "Opaque flash chip" and the `-c` option is futile.
>   Next, I try to write the flash (from the same image) followed by verification, but without -c option. See the attached log “write-verify-flash.log”.
>
> a.       If it will help… The verification reports an error at address 0x1000008f (values f8 vs f0). Comparison of original and read from flash chip images shows the same difference at the same offset.

Do you know exactly what the firmware of your mainboard does? It's possible that some other process also tries to write to the chip (e.g.
firmware in SMM). You could try the same command again and see if it gives different results. Sometimes it just works by chance. But I can only advice to continue if you have means to recover from a bad flash.

Hope that helps,
Nico