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  BBB example at libreboot wiki), depending on a motherboard design this could be dangerous according to Angel Pons comments under  - 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 . 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)
 https://libreboot.org/docs/install/bbb_setup.html  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).  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 email@example.com wrote:
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.
Handy: +4915252667614 Adresse: Hausener Weg 96, 60489, Frankfurt am Main
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 firstname.lastname@example.org 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 email@example.com 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).
flashrom mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/
-- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/