[flashrom] Re: Fail flashing

[Mike Banon]

Hi there GN, any news regarding your progress? btw please CC flashrom
mailing list for your future replies, so that someone else could be
able to help you as well

On Sun, Mar 28, 2021 at 7:49 PM GN  wrote:
> Dear MIke,
>
> Thank you for you detailed answer, very much appreciated.
>
> Thank you for the clarification about the chips, I was getting crazy finding the right information about it. I will report the difference across all the posts I wrote on the issue :)
>
> The procedure in [1] is for a BBB. I will try to understand what can be transferred to the CH341a that I am using. For it, I found this interesting DIY, although according to the author the outputted voltage cannot be carefully controlled.
>
> I have tried to connect the power supplier to the naked motherboard while reading the Winbond chip. As predicted, the power LED on the CH341a lights on dimmed and it gets full-on when connected to the USB 3 port. Less obviously,  flashrom cannot recognize the chip when the power supplier is connected. As I disconnect the power supplier, flashrom correctly recognizes the chip again, but the writing problems persist.
>
> Bests regards,
>
> GN
>
> On 25.03.21 14:39, Mike Banon wrote:
>
> I think the only way to prevent the current leaking to the surrounding
> elements of a chip - is desoldering. So, if we are trying to avoid the
> desoldering - yes, you could try reducing the length of wires between
> a programmer and a test clip - i.e. to 10cm. That certainly wouldn't
> hurt, and sometimes it really helps to achieve the successful flashing
> by ISP (in-system programming) method.
>
> Please note: while there are some successful examples of using the
> external PSU for an ISP flashing (i.e. this [1] BBB example at
> libreboot wiki), depending on a motherboard design this could be
> dangerous according to Angel Pons comments under [2] - so using the
> external PSU should be avoided unless all the other options have been
> tried and you still don't want to solder/desolder.
>
> While looking for the examples of L530 flashing I found a thread with
> your comments [3]. To answer your question why the other people were
> also targeting a ps08a chip: this is CMOS, and clearing a CMOS memory
> sometimes is also important to ensure the successful boot of a
> proprietary BIOS - but we haven't reached this stage yet, since we're
> just trying to flash a BIOS into a SPI flash chip.
>
> Have you ever tested your CH341A before in other setups? If not, do
> you have a spare CH341A to try it with a different one? And could you
> try a higher powered USB port to ensure that your CH341A itself is
> sufficiently powered? (i.e. you may be using a USB extender for your
> convenience, which is fine - but that extender also shouldn't be too
> long)
>
> [1] https://libreboot.org/docs/install/bbb_setup.html
> [2] https://review.coreboot.org/c/flashrom/+/31830
> (this was my patch for the older version of flashrom useful in a
> unreliable flashing setup, but I only successfully read with it and
> never successfully wrote).
> [3] https://www.badcaps.net/forum/showthread.php?t=61517
>
> P.S. I'm not sure how you can measure the leakage with a multimeter,
> and in any case knowing the exact values isn't necessary - when we
> already know the cause of unsuccessful flashing and just need to find
> out how to resolve it.
>
> On Wed, Mar 24, 2021 at 8:46 PM G. Nalin  wrote:
>
> HI,
>
> I have been recommended to desolder the BIOS chip to use the CH341a reliably, but I would like to avoid it and use the clip instead! Should I simply cut shorter the clip wires? Is there something I can do to ground the motherboard or avoid the leaking? How can I measure it (I have just a multimeter here atm).
>
> I don´t know how to supply the power externally while the EEPROM is connected to the USB. Could you indicate me a reference?
>
> I tried to verify the dumo, but if fails because there is some writing involved.
> $ sudo flashrom -V -p ch341a_spi -v bios1b.img
>
> I don´t have a reference so I can´t say if the HEX or BIN dump is actually at least partially valid. It is not all FF and 00.
>
> Cheers,
>
> Giammarco Nalin
>
> Handy: [phone]
> Adresse: Hausener Weg 96, 60489, Frankfurt am Main
>
> From: Mike Banon 
> Sent: 24 March 2021 13:40
> To: G. Nalin 
> Cc: [e-mail] 
> Subject: Re: [flashrom] Fail flashing
>
> Could you please verify that at least a part of the binary file got
> flashed correctly? If yes, these reliability problems could be caused
> by your setup - i.e. too long wires or the surrounding elements of the
> BIOS chip are drawing too much current - causing a voltage drop on the
> chip itself and the remaining is insufficient for the reliable
> flashing (in this case I could recommend using the external power
> supply for 3.3V line)
>
> On Wed, Mar 24, 2021 at 9:50 AM G. Nalin  wrote:
>
> Hi all,
> I am trying to flash a WInbond w25q64bv BIOS chip of a Thinkpad L530. I am on Ubuntu 20.04. Using a EEPROM  ch341a and I am not able to copy correctly the content of the chip: diff and md5sum return all the time some errors. Trying to erase the chip gives random errors like
>
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ch341a_spi.
> Reading old flash chip contents... done.
> Erasing and writing flash chip... FAILED at 0x000b6000! Expected=0xff, Found=0xae, failed byte count from 0x000b6000-0x000b6fff: 0x382
> ERASE FAILED!
>
> and so on. When I prompt the internal status I get:
>
> $sudo flashrom -V -p internal
>
> flashrom v1.2 on Linux 5.8.0-45-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> flashrom was built with libpci 3.6.4, GCC 9.2.1 20200304, little endian
> Command line (3 args): flashrom -V -p internal
> 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: "Notebook"
> Laptop detected via DMI.
> DMI string system-manufacturer: "LENOVO"
> DMI string system-product-name: "20AWS01V01"
> DMI string system-version: "ThinkPad T440p"
> DMI string baseboard-manufacturer: "LENOVO"
> DMI string baseboard-product-name: "20AWS01V01"
> DMI string baseboard-version: "0B98401 PRO"
> W836xx enter config mode worked or we were already in config mode. W836xx leave config mode had no effect.
> Active config mode, unknown reg 0x20 ID: 00.
> Found chipset "Intel QM87" with PCI ID 8086:8c4f.
> 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... Root Complex Register Block address = 0xfed1c000
> GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
> Top Swap: not enabled
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x0
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x0
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x1
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x1
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x2
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x2
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x3
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x3
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x4
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x5
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x6
> 0x7fffffff/0x7fffffff FWH IDSEL: 0x7
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> 0x7fffffff/0x7fffffff FWH decode enabled
> Maximum FWH chip size: 0x100000 bytes
> SPI Read Configuration: prefetching enabled, caching enabled,
> BIOS_CNTL = 0x2b: BIOS Lock Enable: enabled, BIOS Write Enable: enabled
> Warning: BIOS region SMM protection is enabled!
> Warning: Setting Bios Control at 0xdc from 0x2a to 0x09 failed.
> New value is 0x2b.
> SPIBAR = 0x00007f0d5db92000 + 0x3800
> 0x04: 0xe008 (HSFS)
> HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
> SPI Configuration is locked down.
> Reading OPCODES... done
> 0x06: 0x0000 (HSFC)
> HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0
> 0x50: 0x00004a4b (FRAP)
> BMWAG 0x00, BMRAG 0x00, BRWA 0x4a, BRRA 0x4b
> 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
> 0x58: 0x0bff0500 FREG1: BIOS region (0x00500000-0x00bfffff) is read-write.
> 0x5C: 0x04ff0003 FREG2: Management Engine region (0x00003000-0x004fffff) is locked.
> 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write.
> Not all flash regions are freely accessible by flashrom. This is most likely
> due to an active ME. Please see https://flashrom.org/ME for details.
> 0x74: 0x8aaf0800 PR0: Warning: 0x00800000-0x00aaffff is read-only.
> 0x78: 0x8ab00ab0 PR1: Warning: 0x00ab0000-0x00ab0fff is read-only.
> 0x7C: 0x8adf0ab1 PR2: Warning: 0x00ab1000-0x00adffff is read-only.
> 0x80: 0x8bff0b40 PR3: Warning: 0x00b40000-0x00bfffff is read-only.
> At least some flash regions are read protected. You have to use a flash
> layout and include only accessible regions. For write operations, you'll
> additionally need the --noverify-all switch. See manpage for more details.
> 0x90: 0xc0 (SSFS)
> SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
> 0x91: 0xf94000 (SSFC)
> SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=1
> 0x94: 0x0606     (PREOP)
> 0x96: 0x3f90     (OPTYPE)
> 0x98: 0x03003505 (OPMENU)
> 0x9c: 0x9f20d802 (OPMENU+4)
> 0xa0: 0x00000000 (BBAR)
> 0xc4: 0x80802025 (LVSCC)
> LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1
> 0xc8: 0x80000000 (UVSCC)
> UVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0
> 0xd0: 0x50444653 (FPB)
> Enabling hardware sequencing due to multiple flash chips detected.
> OK.
> The following protocols are supported: Programmer-specific.
> Probing for Programmer Opaque flash chip, 0 kB: Hardware sequencing reports 2 attached SPI flash chips with a combined density of 12288 kB.
> 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 0xbfffff.
> In that range are 1453 erase blocks with 4096 B each.
> Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific) mapped at physical address 0x0000000000000000.
> Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific).
> No operations were specified.
> Restoring MMIO space at 0x7f0d5db958a0
> Restoring PCI config space for 00:1f:0 reg 0xdc
>
> ///////////////////////////
>
> $ sudo flashrom -V -p ch341a_spi
> flashrom v1.2 on Linux 5.8.0-45-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
>
> flashrom was built with libpci 3.6.4, GCC 9.2.1 20200304, little endian
> Command line (3 args): flashrom -V -p ch341a_spi
> Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
> Initializing ch341a_spi programmer
> Device revision is 3.0.4
> The following protocols are supported: SPI.
>
> ......
>
> Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on ch341a_spi.
> Chip status register is 0x00.
>
> This chip may contain one-time programmable memory. flashrom cannot read
> and may never be able to write it, hence it may not be able to completely
> clone the contents of this chip (see man page for details).
>
> Cheers,
>
> GN
>
> flashrom mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> Handy: [phone]
> Adresse: Hausener Weg 96, 60489, Frankfurt am Main