[flashrom] Re: Fail flashing

2021-04-01 Thread 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: +4915252667614
> Adresse: Hausener Weg 96, 60489, Frankfurt am Main
>
>
> 
> From: Mike Banon 
> Sent: 24 March 2021 13:40
> To: G. Nalin 
> Cc: flashrom@flashrom.org 
> 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 

[flashrom] Re: Fail flashing

2021-03-24 Thread Mike Banon
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 flashrom@flashrom.org 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
> 0x7fff/0x7fff FWH IDSEL: 0x0
> 0x7fff/0x7fff FWH IDSEL: 0x0
> 0x7fff/0x7fff FWH IDSEL: 0x1
> 0x7fff/0x7fff FWH IDSEL: 0x1
> 0x7fff/0x7fff FWH IDSEL: 0x2
> 0x7fff/0x7fff FWH IDSEL: 0x2
> 0x7fff/0x7fff FWH IDSEL: 0x3
> 0x7fff/0x7fff FWH IDSEL: 0x3
> 0x7fff/0x7fff FWH IDSEL: 0x4
> 0x7fff/0x7fff FWH IDSEL: 0x5
> 0x7fff/0x7fff FWH IDSEL: 0x6
> 0x7fff/0x7fff FWH IDSEL: 0x7
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> 0x7fff/0x7fff FWH decode enabled
> Maximum FWH chip size: 0x10 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 = 0x7f0d5db92000 + 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: 0x (HSFC)
> HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0
> 0x50: 0x4a4b (FRAP)
> BMWAG 0x00, BMRAG 0x00, BRWA 0x4a, BRRA 0x4b
> 0x54: 0x FREG0: Flash Descriptor region (0x-0x0fff) is 
> read-only.
> 0x58: 0x0bff0500 FREG1: BIOS region (0x0050-0x00bf) is read-write.
> 0x5C: 0x04ff0003 FREG2: Management Engine region (0x3000-0x004f) is 
> locked.
> 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x1000-0x2fff) 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: 0x0080-0x00aa is read-only.
> 0x78: 0x8ab00ab0 PR1: Warning: 0x00ab-0x00ab0fff is read-only.
> 0x7C: 0x8adf0ab1 PR2: Warning: 0x00ab1000-0x00ad is read-only.
> 0x80: