April 2024 - flashrom - mail.coreboot.org

Verification after write vs erase operations
by Anastasia Klimchuk Aug. 10, 2025

Aug. 10, 2025

Hello everyone, I want to bring into discussion a topic of verification of chip content which is performed after write or erase operations. Also for context prior discussion in this ticket: https://ticket.coreboot.org/issues/520 Currently we have a flag `-n` or `dont_verify_it` which is false by default. What the flag is doing is deciding whether verification needs to be performed after writing. The flag is false by default, so by default verification is happening after writing (which makes sense). Now the flag is only controlling write operation, and has no effect on erase operation. So for erase, the flag is ignored and verification is performed always. Just for context, it has always been like this. So for write operation we have a power option to say "ignore verification", and since it's false by default, the idea is, if you set it true then you know what you are doing. There is no such option for erase which seems a bit unfair. The two potential options to introduce equivalent option for erase are: 1) Add new flag `dont_verify_erase` (or some similar name) As a support for this option, it does not affect any existing use cases/scripts, and can be added any time. 2) Add coverage for erase operation under existing flag `-n` or `dont_verify_it` As a support for this option, erase operation can be seen as a variant of writing, since it does modify content of the chip, and so the fact it's not covered by the existing flag can be treated as a bug. What do people think about it? -- Anastasia.

2 2

RFC: removing 1 second verification delay
by Brian Norris May 12, 2024

May 12, 2024

Background: https://review.coreboot.org/c/flashrom/+/80807 A long time ago, in the pre-git times [1], flashrom added a 1 second delay to all verification, and claimed that some chips "need some time to calm down." The commit message claims it "fixes a few reports where verify directly after erase had unpleasant side effects like corrupting flash or at least getting incorrect verify results." It provides no details of what systems, chips, or programmers were involved. This delay remains in the --verify path today, and IMO, it's a big waste of time. If there are truly chips that are, say, deasserting the BUSY line before they're truly finished programming ... well, we should track those chips down and add targeted quirk flags for them. We shouldn't penalize all flashrom users in all cases for all time. Personally, I highly doubt that this delay is still relevant today -- there may have been a bug in some programmer that has since been fixed; there may have been some malfunctioning system that is no longer in use; ... or it's possible this is still hiding a real buggy chip somewhere out there. I propose: we still remove the delay. There's plenty of description in the above Gerrit link about why, and how we can handle regressions. (For one, it's relatively simple to split up a --verify operation into its constituent --write/sleep/--read operations, for debugging.) The request: 1. Tests: I've tested a few Chromebooks, but imagine this had to have been some more esoteric system. Extra testing is welcome. 2. Thoughts: does my proposal make sense? Am I missing something obvious? 3. Awareness: if nothing else, this email may serve to highlight in case we land the above patch and later hear back that there are some sketchy --verify reports from users. Thanks, Brian [1] The svn->git commit in question: commit 8ab49e72af8465d4527de2ec37b22cd44f7a1169 Date: Wed Aug 19 13:55:34 2009 +0000 Disallow erase/write for known bad chips so people won't try without a clear understanding

3 7

Support for GD25LR512ME flash chip.
by Munduru, Avinash May 6, 2024

May 6, 2024

[AMD Official Use Only - General] Hi, Currently, flash chip support for GD25LR512ME is not supported in flashrom utility. Please share a patch if it is already available. If not let me know how I can modify it. [cid:5890692a-9560-47ca-bacb-7255839da891]

2 2

Flashrom -VV for xmc qh64ahig
by DigitalAndrew April 30, 2024

April 30, 2024

flashrom unknown on Linux 6.5.0-kali3-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). flashrom was built with GCC 13.2.0, little endian Command line (3 args): flashrom -p ch341a_spi -VV Initializing ch341a_spi programmer Device revision is 3.0.4 The following protocols are supported: SPI. Probing for AMIC A25L010, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L016, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L020, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L032, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L040, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L05PT, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L05PU, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L080, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L10PT, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L10PU, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L16PT, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L16PU, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L20PT, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L20PU, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L40PT, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L40PU, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L512, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25L80P, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25LQ032/A25LQ32A, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25LQ16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for AMIC A25LQ64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF021, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF021A, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF041A, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF081, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF081A, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF161, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF321, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF321A, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DF641(A), 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DL081, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DL161, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25DQ161, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25F1024(A), 128 kB: probe_spi_at25f: id1 0xff, id2 0xff Probing for Atmel AT25F2048, 256 kB: probe_spi_at25f: id1 0xff, id2 0xff Probing for Atmel AT25F4096, 512 kB: probe_spi_at25f: id1 0xff, id2 0xff Probing for Atmel AT25F512, 64 kB: probe_spi_at25f: id1 0xff, id2 0xff Probing for Atmel AT25F512A, 64 kB: probe_spi_at25f: id1 0xff, id2 0xff Probing for Atmel AT25F512B, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25FS010, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25FS040, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25SF041, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25SF081, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25SF128A, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25SF161, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25SF321, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT25SL128A, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT26DF041, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT26DF081A, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT26DF161, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT26DF161A, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT26F004, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45CS1282, 16896 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB011D, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB021D, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB041D, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB081D, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB161D, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB321C, 4224 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB321D, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB321E, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel AT45DB642D, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Boya/BoHong Microelectronics B.25D16A, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Boya/BoHong Microelectronics B.25Q128AS, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for ESI ES25P16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for ESI ES25P40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for ESI ES25P80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for ESMT F25L008A, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for ESMT F25L32PA, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B05, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B05T, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B10T, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B16T, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B20T, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B32T, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B40T, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B64T, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25B80T, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25F05, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25F10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25F16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25F20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25F32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25F40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25F64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25F80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25P05, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25P10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25P16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25P20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25P32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25P40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25P64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25P80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25Q128, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25Q16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25Q32(A/B), 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25Q40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25Q64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25Q80(A), 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25QH128, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25QH16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25QH32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25QH64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25S10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25S16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25S20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25S32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25S40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25S64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon EN25S80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Fudan FM25F005, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Fudan FM25F01, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Fudan FM25F02(A), 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Fudan FM25F04(A), 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Fudan FM25Q08, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Fudan FM25Q16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Fudan FM25Q32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25B128B/GD25Q128B, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25LQ128C/GD25LQ128D/GD25LQ128E, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25LQ16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25LQ32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25LQ40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25LQ64(B), 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25LQ80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q127C/GD25Q128C, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q16(B), 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q20(B), 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q256D/GD25Q256E, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q32(B), 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q40(B), 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q512, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q64(B), 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25Q80(B), 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25T80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25VQ16C, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25VQ21B, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25VQ40C, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25VQ41B, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25VQ80C, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for GigaDevice GD25WQ80E, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for ISSI IS25LP064, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for ISSI IS25LP128, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for ISSI IS25LP256, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for ISSI IS25WP032, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for ISSI IS25WP064, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for ISSI IS25WP128, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for ISSI IS25WP256, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Intel 25F160S33B8, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Intel 25F160S33T8, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Intel 25F320S33B8, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Intel 25F320S33T8, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Intel 25F640S33B8, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Intel 25F640S33T8, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX23L12854, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX23L1654, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX23L3254, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX23L6454, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L1005(C)/MX25L1006E, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L12805D, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L12833F/MX25L12835F/MX25L12845E/MX25L12865E/MX25L12873F, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L1605, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L1605A/MX25L1606E/MX25L1608E, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L1605D/MX25L1608D/MX25L1673E, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L1635D, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L1635E, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L2005(C)/MX25L2006E, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L25635F/MX25L25645G, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L3205(A), 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L3205D/MX25L3208D, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L3206E/MX25L3208E, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L3235D, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L3233F/MX25L3273E, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L4005(A/C)/MX25L4006E, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L512(E)/MX25V512(C), 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L5121E, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L6405, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L6405D, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L6406E/MX25L6408E, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L6436E/MX25L6445E/MX25L6465E/MX25L6473E/MX25L6473F, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L6495F, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25L8005/MX25L8006E/MX25L8008E/MX25V8005, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25R3235F, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25R6435F, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25U12835F, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25U1635E, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25U25635F, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25U3235E/F, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25U51245G, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25U6435E/F, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX25U8032E, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX66L51235F/MX25L51245G, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix MX66L1G45G, 131072 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P05, 64 kB: Ignoring RES in favour of RDID. Probing for Micron/Numonyx/ST M25P05-A, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P10, 128 kB: Ignoring RES in favour of RDID. Probing for Micron/Numonyx/ST M25P10-A, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P128, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P20-old, 256 kB: Ignoring RES in favour of RDID. Probing for Micron/Numonyx/ST M25P32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P40-old, 512 kB: Ignoring RES in favour of RDID. Probing for Micron/Numonyx/ST M25P64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25P80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PE10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PE16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PE20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PE40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PE80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PX16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PX32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PX64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M25PX80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M45PE10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M45PE16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M45PE20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M45PE40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST M45PE80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q00A..1G, 131072 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q00A..3G, 131072 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q016, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q032..1E, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q032..3E, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q064..1E, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q064..3E, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q128..1E, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q128..3E, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q256..1E, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q256..3E, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q512..1G, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron/Numonyx/ST N25Q512..3G, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QL01G, 131072 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QU01G, 131072 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QL02G, 262144 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QU02G, 262144 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QU128, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QL128, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QL256, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QU256, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QL512, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Micron MT25QU512, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Nantronics N25S10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Nantronics N25S16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Nantronics N25S20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Nantronics N25S40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Nantronics N25S80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LD010(C), 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LD020(C), 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LD040(C), 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LD256C, 32 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LD512(C), 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LQ016, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LQ020, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LQ032C, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LQ040, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LQ080, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LV010, 128 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for PMC Pm25LV010A, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LV016B, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LV020, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LV040, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LV080B, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC Pm25LV512(A), 64 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for SST SST25LF020A, 256 kB: compare_id: id1 0x20, id2 0x16 Probing for SST SST25LF040A, 512 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for SST SST25LF080(A), 1024 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for SST SST25VF010(A), 128 kB: compare_id: id1 0x20, id2 0x16 Probing for SST SST25VF016B, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25VF020, 256 kB: compare_id: id1 0x20, id2 0x16 Probing for SST SST25VF020B, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25VF032B, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25VF040, 512 kB: compare_id: id1 0x20, id2 0x16 Probing for SST SST25VF040B, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25VF040B.REMS, 512 kB: compare_id: id1 0x20, id2 0x16 Probing for SST SST25VF064C, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25VF080B, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25VF512(A), 64 kB: compare_id: id1 0x20, id2 0x16 Probing for SST SST25WF010, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25WF020, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25WF020A, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25WF040, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25WF040B, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25WF080, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25WF080B, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST25WF512, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST26VF016B(A), 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST26VF032B(A), 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST SST26VF064B(A), 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for ST M95M02, 256 kB: probe_spi_st95: id1 0xff, id2 0xffff Probing for Sanyo LE25FU106B, 128 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for Sanyo LE25FU206, 256 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for Sanyo LE25FU206A, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Sanyo LE25FU406B, 512 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for Sanyo LE25FU406C/LE25U40CMC, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Sanyo LE25FW106, 128 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for Sanyo LE25FW203A, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Sanyo LE25FW403A, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Sanyo LE25FW406A, 512 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for Sanyo LE25FW418A, 512 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for Sanyo LE25FW806, 1024 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for Sanyo LE25FW808, 1024 kB: probe_spi_res2: id1 0x16, id2 0x16 Probing for Spansion S25FL004A, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL008A, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL016A, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL032A/P, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL064A/P, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL116K/S25FL216K, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL127S-256kB, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL127S-64kB, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL128L, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL128P......0, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL128P......1, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL128S......0, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL128S......1, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL128S_UL Uniform 128 kB Sectors, 16384 kB: Read id bytes: 0x20 0x70 0x17 0x20 0x70 0x17. Probing for Spansion S25FL128S_US Uniform 64 kB Sectors, 16384 kB: Read id bytes: 0x20 0x70 0x17 0x20 0x70 0x17. Probing for Spansion S25FL129P......0, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL129P......1, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL132K, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL164K, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL204K, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL208K, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL256L, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL256S Large Sectors, 16384 kB: Read id bytes: 0x20 0x70 0x17 0x20 0x70 0x17. Probing for Spansion S25FL256S Small Sectors, 16384 kB: Read id bytes: 0x20 0x70 0x17 0x20 0x70 0x17. Probing for Spansion S25FL256S......0, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FL512S, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Spansion S25FS128S Large Sectors, 16384 kB: Read id bytes: 0x20 0x70 0x17 0x20 0x70 0x17. Probing for Spansion S25FS128S Small Sectors, 16384 kB: Read id bytes: 0x20 0x70 0x17 0x20 0x70 0x17. Probing for Winbond W25P16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25P32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25P80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q128.V, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q128.V..M, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q128.W, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q128.JW.DTR, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q16.V, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q16.W, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q20.W, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q256FV, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q256JV_Q, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q256JV_M, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q256JW, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q256JW_DTR, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q32.V, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q32.W, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q32JW...M, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q40.V, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q40BW, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q40EW, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q512JV, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q512NW-IM, 65536 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q64BV/W25Q64CV/W25Q64FV, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q64JV-.Q, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q64JV-.M, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q64.W, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q64JW...M, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q80.V, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q80BW, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25Q80EW, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25X05, 64 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25X10, 128 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25X16, 2048 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25X20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25X32, 4096 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25X40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25X64, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond W25X80, 1024 kB: compare_id: id1 0x20, id2 0x7017 Probing for XMC XM25QH64C, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for XMC XM25QU64C, 8192 kB: compare_id: id1 0x20, id2 0x7017 Probing for XMC XM25QH128C, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for XMC XM25QU128C, 16384 kB: compare_id: id1 0x20, id2 0x7017 Probing for XMC XM25QH256C, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for XMC XM25QU256C, 32768 kB: compare_id: id1 0x20, id2 0x7017 Probing for Zetta Device ZD25D20, 256 kB: compare_id: id1 0x20, id2 0x7017 Probing for Zetta Device ZD25D40, 512 kB: compare_id: id1 0x20, id2 0x7017 Probing for Unknown SFDP-capable chip, 0 kB: SFDP revision = 1.0 SFDP number of parameter headers is 2 (NPH = 1). SFDP parameter table header 0/1: ID 0x00, version 1.0 Length 36 B, Parameter Table Pointer 0x000030 Parsing JEDEC flash parameter table... 3-Byte only addressing. Status register is non-volatile and the standard does not allow vendors to tell us whether EWSR/WREN is needed for status register writes - assuming EWSR. Write chunk size is at least 64 B. Flash chip size is 8192 kB. Block eraser 0: 2048 x 4096 B with opcode 0x20 Tried to add a duplicate block eraser: 2048 x 4096 B with opcode 0x20. Block eraser 1: 256 x 32768 B with opcode 0x52 Block eraser 2: 128 x 65536 B with opcode 0xd8 done. SFDP parameter table header 1/1: ID 0x20, version 1.0 Length 16 B, Parameter Table Pointer 0x000060 === SFDP has autodetected a flash chip which is not natively supported by flashrom yet. All standard operations (read, verify, erase and write) should work, but to support all possible features we need to add them manually. You can help us by mailing us the output of the following command to flashrom(a)flashrom.org: 'flashrom -VV [plus the -p/--programmer parameter]' Thanks for your help! === Added layout entry 00000000 - 007fffff named complete flash Found Unknown flash chip "SFDP-capable chip" (8192 kB, SPI) on ch341a_spi. Probing for AMIC unknown AMIC SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for Atmel unknown Atmel SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for Eon unknown Eon SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for Macronix unknown Macronix SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for PMC unknown PMC SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for SST unknown SST SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for ST unknown ST SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for Sanyo unknown Sanyo SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for Winbond unknown Winbond (ex Nexcom) SPI chip, 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for Generic unknown SPI chip (RDID), 0 kB: compare_id: id1 0x20, id2 0x7017 Probing for Generic unknown SPI chip (REMS), 0 kB: compare_id: id1 0x20, id2 0x16 Found Unknown flash chip "SFDP-capable chip" (8192 kB, SPI). === This flash part has status UNTESTED for operations: WP The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. Thanks for your help! No operations were specified.

1 0

flashrom @ IS25LP032
by krassopde12 April 24, 2024

April 24, 2024

Hi there, I just used flashrom to read and write to my IS25LP032 EEPROM, which worked smoothly, but as per the request of the program I am sending you the output of flashrom -VV. I used the flashrom version builtin in the current Kali Distribution, sadly I was not able to identify, which one I got. Thank you so much for your wonderful tool! <3 Regards!

1 0

Support Chip Winbond 25Q64FWSIG
by Ale Foga April 22, 2024

April 22, 2024

Hello I am trying to read and program a Winbond 25Q64FWSIG memory which is supported by what I see in the documentation, but I cannot perform any operations. I am using Arduino UNO as the interface. With the Winbond 25Q16BVSIG memory I was able to read and program it without problems and according to the list the supported memories are Winbond W25Q16.V 2048 SPI OK OK OK OK 2,700 3,600 Winbond W25Q64.W 8192 SPI OK OK OK OK 1,700 1,950 From what I can understand that if it works with 25Q16BVSIG memory, it would have to work with 25Q64FWSIG, right? I hope you can help me Attached console output *ale@ale:~$* sudo flashrom -p serprog:dev=/dev/ttyACM0:115200 -r backupG5.bin flashrom 1.4.0-devel (git:v1.2-1414-g2a5d2920) on Linux 5.10.0-28-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). serprog: Programmer name is "frser-duino" serprog: requested mapping AT45CS1282 is incompatible: 0x1080000 bytes at 0x00000000fef80000. serprog: requested mapping GD25LQ255E is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping GD25Q256D/GD25Q256E is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping IS25LP256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping IS25WP256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25L25635F/MX25L25645G is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25U25635F is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25U25643G is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25U51245G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MX66L51235F/MX25L51245G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MX66L1G45G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping MX77L25650F is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping N25Q00A..1G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping N25Q00A..3G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping N25Q256..1E is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping N25Q256..3E is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping N25Q512..1G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping N25Q512..3G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MT25QL01G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping MT25QU01G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping MT25QL02G is incompatible: 0x10000000 bytes at 0x00000000f0000000. serprog: requested mapping MT25QU02G is incompatible: 0x10000000 bytes at 0x00000000f0000000. serprog: requested mapping MT25QL256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MT25QU256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MT25QL512 is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MT25QU512 is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping S25FL256L is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping S25FL256S......0 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping S25FL512S is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping W25Q256FV is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256JV_Q is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256JV_M is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256JW is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256JW_DTR is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q512JV is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping W25Q512NW-IM is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping XM25QH256C is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping XM25QU256C is incompatible: 0x2000000 bytes at 0x00000000fe000000. Found Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on serprog. === This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE This flash part has status UNTESTED for operations: WP The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. You can also try to follow the instructions here: https://www.flashrom.org/contrib_howtos/how_to_mark_chip_tested.html Thanks for your help! Read is not working on this chip. Aborting. *Thank you so much*

1 0

Re: adding part #
by Anastasia Klimchuk April 21, 2024

April 21, 2024

This is good news, I can see your patch! You pushed your patch successfully, which you can see from the logs you posted earlier, and also the logs contain the link to the patch (https://review.coreboot.org/c/flashrom/+/81970 in this case). You can click the link and inspect how your patch looks, how Gerrit UI looks. View-only mode is public (you can send the link to anyone), but to modify your patch, respond to comments etc, you need to be logged into Gerrit. Next steps are documented in the section "Going through code reviews" here https://flashrom.org/dev_guide/development_guide.html#going-through-code-re… During the code review process communication is happening in Gerrit (not in the mailing list). So your immediate next step is to wait for reviewer(s) to go through your patch and add comments, it will happen soon. And then you need to fix and respond to comments. There are more details in the doc I linked. Thank you for your work! And keep an eye on your patch when the comments arrive. On Fri, Apr 19, 2024 at 6:03 AM Vlim <vlim(a)gigadevice.com> wrote: > > Thanks, > > I think I am getting closer. What do I do next? > > Regards, > > Victor > > > victor@victor-0-1:~/Desktop/flashrom$ git push upstream HEAD:refs/for/main > Username for 'https://review.coreboot.org': victorswlim > Password for 'https://victorswlim@review.coreboot.org': > Enumerating objects: 9, done. > Counting objects: 100% (9/9), done. > Delta compression using up to 8 threads > Compressing objects: 100% (5/5), done. > Writing objects: 100% (5/5), 1.74 KiB | 445.00 KiB/s, done. > Total 5 (delta 4), reused 0 (delta 0), pack-reused 0 > remote: Resolving deltas: 100% (4/4) > remote: Processing changes: refs: 1, new: 1, done > remote: > remote: SUCCESS > remote: > remote: https://review.coreboot.org/c/flashrom/+/81970 <Flashrom SPI NOR>: adding a few new SPI NOR part numbers [NEW] > remote: > To https://review.coreboot.org/flashrom > * [new reference] HEAD -> refs/for/main > > > ________________________________ > From: Anastasia Klimchuk <aklm(a)chromium.org> > Sent: Thursday, April 18, 2024 03:36 > To: Vlim <vlim(a)gigadevice.com>; Nikolai Artemiev <nartemiev(a)google.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Peter Marheine <pmarheine(a)chromium.org> > Subject: Re: [flashrom] Re: adding part # > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > You need to be logged into your Github account, and then open Gerrit login link and click "GitHub OAuth2". > > On Thu, Apr 18, 2024 at 3:33 PM Vlim <vlim(a)gigadevice.com> wrote: > > Hi, Anastasia, > > Looks like I am not able to create an account on https://review.coreboot.org/login > > This is what I got. And the account I have created on Github. > > Regards, > > Victor > > > victor@victor-0-1:~/Desktop/flashrom$ git push upstream HEAD:refs/for/main > Username for 'https://review.coreboot.org': victorswlim1 > Password for 'https://victorswlim1@review.coreboot.org': > remote: Unauthorized > fatal: Authentication failed for 'https://review.coreboot.org/flashrom/' > > > > ________________________________ > From: Anastasia Klimchuk <aklm(a)chromium.org> > Sent: Wednesday, April 17, 2024 21:50 > To: Vlim <vlim(a)gigadevice.com>; Nikolai Artemiev <nartemiev(a)google.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Peter Marheine <pmarheine(a)chromium.org> > Subject: Re: [flashrom] Re: adding part # > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > It seems like you created a commit locally, that's good! > Next instructions are to push your patch to Gerrit, here: > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.… > > On Thu, Apr 18, 2024 at 2:13 PM Vlim <vlim(a)gigadevice.com> wrote: > > > > Hi, Anastasia, > > > > I am a little lost. Can you advise I should do next. > > I am getting to the following step. > > > > Regards, > > > > Victor > > > > > > victor@victor-0-1:~/Desktop/flashrom$ git commit -a -s > > [upstream/main 4b717ed3] <Flashrom SPI NOR>: adding a few new SPI NOR part numbers > > 2 files changed, 742 insertions(+), 24 deletions(-) > > victor@victor-0-1:~/Desktop/flashrom$ git log > > commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main) > > Author: Victor Lim <vlim(a)gigadevice.com> > > Date: Wed Apr 17 20:53:44 2024 -0700 > > > > <Flashrom SPI NOR>: adding a few new SPI NOR part numbers > > > > These are the part # added > > GD25LB128E: 1.8V 128Mbit QE = 1 > > GD25LQ128E: 1.8V 128Mbit > > GD25LR128E: 1.8V 128Mbit RPMC > > GD25LB256F: 1.8V 256Mbit QE = 1 > > GD25LQ256H: 1.8V 256Mbit > > GD25LR256F: 1.8V 256Mbit RPMC > > GD25LB512MF: 1.8V 512Mbit QE = 1 > > GD25LR512MF: 1.8V 512Mbit RPMC > > GD25LF128E: 1.8V 128Mbit > > GD25LF256F: 1.8V 256Mbit > > GD25LF512MF: 1.8V 512Mbit > > GD25LB256E: 1.8V 256Mbit QE = 1 > > GD25LB512ME: 1.8V 512Mbit QE = 1 > > GD25B128E: 3V 128Mbit QE = 1 > > GD25Q128E: 3V 128Mbit > > GD25R128E: 3V 128Mbit RPMC > > GD25B256E: 3V 256Mbit QE = 1 > > GD25Q256E: 3V 256Mbit > > GD25R256E: 3V 256Mbit RPMC > > GD25B512MF: 3V 512Mbit QE = 1 > > GD25R512MF: 3V 512Mbit RPMC > > GD25F64F: 3V 64Mbit > > GD25F128F: 3V 128Mbit > > GD25F256F: 3V 256Mbit > > GD25F512MF: 3V 512Mbit > > GD25B512ME: 3V 512Mbit QE = 1 > > > > Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2 > > Signed-off-by: Victor Lim <vlim(a)gigadevice.com> > > > > commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, main) > > Author: Hsuan Ting Chen <roccochen(a)google.com> > > :...skipping... > > commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main) > > Author: Victor Lim <vlim(a)gigadevice.com> > > Date: Wed Apr 17 20:53:44 2024 -0700 > > > > <Flashrom SPI NOR>: adding a few new SPI NOR part numbers > > > > These are the part # added > > GD25LB128E: 1.8V 128Mbit QE = 1 > > GD25LQ128E: 1.8V 128Mbit > > GD25LR128E: 1.8V 128Mbit RPMC > > GD25LB256F: 1.8V 256Mbit QE = 1 > > GD25LQ256H: 1.8V 256Mbit > > GD25LR256F: 1.8V 256Mbit RPMC > > GD25LB512MF: 1.8V 512Mbit QE = 1 > > GD25LR512MF: 1.8V 512Mbit RPMC > > GD25LF128E: 1.8V 128Mbit > > GD25LF256F: 1.8V 256Mbit > > GD25LF512MF: 1.8V 512Mbit > > GD25LB256E: 1.8V 256Mbit QE = 1 > > GD25LB512ME: 1.8V 512Mbit QE = 1 > > GD25B128E: 3V 128Mbit QE = 1 > > GD25Q128E: 3V 128Mbit > > GD25R128E: 3V 128Mbit RPMC > > GD25B256E: 3V 256Mbit QE = 1 > > GD25Q256E: 3V 256Mbit > > GD25R256E: 3V 256Mbit RPMC > > GD25B512MF: 3V 512Mbit QE = 1 > > GD25R512MF: 3V 512Mbit RPMC > > GD25F64F: 3V 64Mbit > > GD25F128F: 3V 128Mbit > > GD25F256F: 3V 256Mbit > > GD25F512MF: 3V 512Mbit > > GD25B512ME: 3V 512Mbit QE = 1 > > > > Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2 > > Signed-off-by: Victor Lim <vlim(a)gigadevice.com> > > > > commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, main) > > Author: Hsuan Ting Chen <roccochen(a)google.com> > > Date: Thu Mar 7 18:46:10 2024 +0800 > > :...skipping... > > commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main) > > Author: Victor Lim <vlim(a)gigadevice.com> > > Date: Wed Apr 17 20:53:44 2024 -0700 > > > > <Flashrom SPI NOR>: adding a few new SPI NOR part numbers > > > > These are the part # added > > GD25LB128E: 1.8V 128Mbit QE = 1 > > GD25LQ128E: 1.8V 128Mbit > > GD25LR128E: 1.8V 128Mbit RPMC > > GD25LB256F: 1.8V 256Mbit QE = 1 > > GD25LQ256H: 1.8V 256Mbit > > GD25LR256F: 1.8V 256Mbit RPMC > > GD25LB512MF: 1.8V 512Mbit QE = 1 > > GD25LR512MF: 1.8V 512Mbit RPMC > > GD25LF128E: 1.8V 128Mbit > > GD25LF256F: 1.8V 256Mbit > > GD25LF512MF: 1.8V 512Mbit > > GD25LB256E: 1.8V 256Mbit QE = 1 > > GD25LB512ME: 1.8V 512Mbit QE = 1 > > GD25B128E: 3V 128Mbit QE = 1 > > GD25Q128E: 3V 128Mbit > > GD25R128E: 3V 128Mbit RPMC > > GD25B256E: 3V 256Mbit QE = 1 > > GD25Q256E: 3V 256Mbit > > GD25R256E: 3V 256Mbit RPMC > > GD25B512MF: 3V 512Mbit QE = 1 > > GD25R512MF: 3V 512Mbit RPMC > > GD25F64F: 3V 64Mbit > > GD25F128F: 3V 128Mbit > > GD25F256F: 3V 256Mbit > > GD25F512MF: 3V 512Mbit > > GD25B512ME: 3V 512Mbit QE = 1 > > > > Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2 > > Signed-off-by: Victor Lim <vlim(a)gigadevice.com> > > > > commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, main) > > Author: Hsuan Ting Chen <roccochen(a)google.com> > > Date: Thu Mar 7 18:46:10 2024 +0800 > > > > :...skipping... > > commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main) > > Author: Victor Lim <vlim(a)gigadevice.com> > > Date: Wed Apr 17 20:53:44 2024 -0700 > > > > <Flashrom SPI NOR>: adding a few new SPI NOR part numbers > > > > These are the part # added > > GD25LB128E: 1.8V 128Mbit QE = 1 > > GD25LQ128E: 1.8V 128Mbit > > GD25LR128E: 1.8V 128Mbit RPMC > > GD25LB256F: 1.8V 256Mbit QE = 1 > > GD25LQ256H: 1.8V 256Mbit > > GD25LR256F: 1.8V 256Mbit RPMC > > GD25LB512MF: 1.8V 512Mbit QE = 1 > > GD25LR512MF: 1.8V 512Mbit RPMC > > GD25LF128E: 1.8V 128Mbit > > GD25LF256F: 1.8V 256Mbit > > GD25LF512MF: 1.8V 512Mbit > > GD25LB256E: 1.8V 256Mbit QE = 1 > > GD25LB512ME: 1.8V 512Mbit QE = 1 > > GD25B128E: 3V 128Mbit QE = 1 > > GD25Q128E: 3V 128Mbit > > GD25R128E: 3V 128Mbit RPMC > > GD25B256E: 3V 256Mbit QE = 1 > > GD25Q256E: 3V 256Mbit > > GD25R256E: 3V 256Mbit RPMC > > GD25B512MF: 3V 512Mbit QE = 1 > > GD25R512MF: 3V 512Mbit RPMC > > GD25F64F: 3V 64Mbit > > GD25F128F: 3V 128Mbit > > GD25F256F: 3V 256Mbit > > GD25F512MF: 3V 512Mbit > > GD25B512ME: 3V 512Mbit QE = 1 > > > > Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2 > > Signed-off-by: Victor Lim <vlim(a)gigadevice.com> > > > > commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, main) > > Author: Hsuan Ting Chen <roccochen(a)google.com> > > Date: Thu Mar 7 18:46:10 2024 +0800 > > > > classic_cli_manpage.rst: Update doc for custom_rst of raiden_debug_spi > > :...skipping... > > commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main) > > Author: Victor Lim <vlim(a)gigadevice.com> > > Date: Wed Apr 17 20:53:44 2024 -0700 > > > > <Flashrom SPI NOR>: adding a few new SPI NOR part numbers > > > > These are the part # added > > GD25LB128E: 1.8V 128Mbit QE = 1 > > GD25LQ128E: 1.8V 128Mbit > > GD25LR128E: 1.8V 128Mbit RPMC > > GD25LB256F: 1.8V 256Mbit QE = 1 > > GD25LQ256H: 1.8V 256Mbit > > GD25LR256F: 1.8V 256Mbit RPMC > > GD25LB512MF: 1.8V 512Mbit QE = 1 > > GD25LR512MF: 1.8V 512Mbit RPMC > > GD25LF128E: 1.8V 128Mbit > > GD25LF256F: 1.8V 256Mbit > > GD25LF512MF: 1.8V 512Mbit > > GD25LB256E: 1.8V 256Mbit QE = 1 > > GD25LB512ME: 1.8V 512Mbit QE = 1 > > GD25B128E: 3V 128Mbit QE = 1 > > GD25Q128E: 3V 128Mbit > > GD25R128E: 3V 128Mbit RPMC > > GD25B256E: 3V 256Mbit QE = 1 > > GD25Q256E: 3V 256Mbit > > GD25R256E: 3V 256Mbit RPMC > > GD25B512MF: 3V 512Mbit QE = 1 > > GD25R512MF: 3V 512Mbit RPMC > > GD25F64F: 3V 64Mbit > > GD25F128F: 3V 128Mbit > > GD25F256F: 3V 256Mbit > > GD25F512MF: 3V 512Mbit > > GD25B512ME: 3V 512Mbit QE = 1 > > > > Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2 > > Signed-off-by: Victor Lim <vlim(a)gigadevice.com> > > > > commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, main) > > Author: Hsuan Ting Chen <roccochen(a)google.com> > > Date: Thu Mar 7 18:46:10 2024 +0800 > > > > classic_cli_manpage.rst: Update doc for custom_rst of raiden_debug_spi > > > > :...skipping... > > commit 4b717ed35f72c4dd460d97d030670f8b5b07efb4 (HEAD -> upstream/main) > > Author: Victor Lim <vlim(a)gigadevice.com> > > Date: Wed Apr 17 20:53:44 2024 -0700 > > > > <Flashrom SPI NOR>: adding a few new SPI NOR part numbers > > > > These are the part # added > > GD25LB128E: 1.8V 128Mbit QE = 1 > > GD25LQ128E: 1.8V 128Mbit > > GD25LR128E: 1.8V 128Mbit RPMC > > GD25LB256F: 1.8V 256Mbit QE = 1 > > GD25LQ256H: 1.8V 256Mbit > > GD25LR256F: 1.8V 256Mbit RPMC > > GD25LB512MF: 1.8V 512Mbit QE = 1 > > GD25LR512MF: 1.8V 512Mbit RPMC > > GD25LF128E: 1.8V 128Mbit > > GD25LF256F: 1.8V 256Mbit > > GD25LF512MF: 1.8V 512Mbit > > GD25LB256E: 1.8V 256Mbit QE = 1 > > GD25LB512ME: 1.8V 512Mbit QE = 1 > > GD25B128E: 3V 128Mbit QE = 1 > > GD25Q128E: 3V 128Mbit > > GD25R128E: 3V 128Mbit RPMC > > GD25B256E: 3V 256Mbit QE = 1 > > GD25Q256E: 3V 256Mbit > > GD25R256E: 3V 256Mbit RPMC > > GD25B512MF: 3V 512Mbit QE = 1 > > GD25R512MF: 3V 512Mbit RPMC > > GD25F64F: 3V 64Mbit > > GD25F128F: 3V 128Mbit > > GD25F256F: 3V 256Mbit > > GD25F512MF: 3V 512Mbit > > GD25B512ME: 3V 512Mbit QE = 1 > > > > Change-Id: I1526eed830845d5391ca14c7fd3ac58a5aee71f2 > > Signed-off-by: Victor Lim <vlim(a)gigadevice.com> > > > > commit 041644a6afb12232495c45d3450ae0b3e2eb2a2d (origin/main, origin/HEAD, main) > > Author: Hsuan Ting Chen <roccochen(a)google.com> > > Date: Thu Mar 7 18:46:10 2024 +0800 > > > > classic_cli_manpage.rst: Update doc for custom_rst of raiden_debug_spi > > > > Update technical details for custom_rst of raiden_debug_spi to help > > users better understand their configuration options. > > > > BUG=b:161745002 > > BRANCH=none > > : > > > > > > > > ________________________________ > > From: Anastasia Klimchuk <aklm(a)chromium.org> > > Sent: Saturday, April 13, 2024 00:19 > > To: Vlim <vlim(a)gigadevice.com>; Nikolai Artemiev <nartemiev(a)google.com>; Peter Marheine <pmarheine(a)chromium.org>; flashrom(a)flashrom.org <flashrom(a)flashrom.org> > > Subject: Re: [flashrom] Re: adding part # > > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > > This is really good news! I am so glad to hear that you are almost > > there. Thank you for your effort! > > > > We have the advice and instructions documented in Development Guide > > here: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.… > > And maybe you read this doc already, but if not, it's a good time to > > read it before pushing a patch. > > > > On Sat, Apr 13, 2024 at 3:46 AM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > Hi, Anastasia, > > > > > > It was due to the ch341a_spi not stable after my modification. > > > The on-board controller was powered by a 5V supply, and output signals are 5V. > > > I changed the power to 3V, since then, it was not stable sometimes. > > > After adding a cap to the 3V line close to the controller, it is ok now. > > > > > > I have almost finished verification for the new part #s to be added. > > > Expecting to submit the patch in a few days. > > > Do you have any advice for me about submitting the patch? > > > > > > Files I have modified are Flashchip.c and .h. > > > > > > Regards, > > > > > > Victor > > > > > > ________________________________ > > > From: Anastasia Klimchuk <aklm(a)chromium.org> > > > Sent: Friday, April 12, 2024 02:25 > > > To: Vlim <vlim(a)gigadevice.com>; Nikolai Artemiev <nartemiev(a)google.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Peter Marheine <pmarheine(a)chromium.org> > > > Subject: Re: [flashrom] Re: adding part # > > > > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > > > > This looks like timeout might be happening because of how your > > > programmer device is set up, not necessarily because the chip > > > definition is wrong. I remember often people say about ch341a_spi > > > "check the wires are not too long", maybe this applies to you? > > > > > > Also, you need to give more info: > > > > > > the exact command you ran > > > and full verbose logs (-VVV gives you super verbose mode) > > > also what are your current local changes? I assume you run it on your > > > local commit? you can push a patch and mark it "work in progress" so > > > that we know what is the actual code that you are running. > > > > > > On Tue, Apr 9, 2024 at 3:04 PM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > > > Thanks. > > > > > > > > Another question. > > > > I am getting the following message, please advise what is the possible issue? > > > > > > > > Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). > > > > Found GigaDevice flash chip "GD25F64F" (8192 kB, SPI) on ch341a_spi. > > > > Reading old flash chip contents... done. > > > > > > > > cb_in: error: LIBUSB_TRANSFER_TIMED_OUT > > > > ch341a_spi_spi_send_command: Failed to read 3 bytes > > > > Register read failed! > > > > write_flash: failed to write (0x66b200..0x66b7ff). > > > > Write failed at 0x5, Abort. > > > > Erase/write done from 0 to 7fffff > > > > Write Failed!Uh oh. Erase/write failed. Checking if anything has changed. > > > > Reading current flash chip contents... > > > > cb_out: error: LIBUSB_TRANSFER_TIMED_OUT > > > > > > > > cb_in: error: LIBUSB_TRANSFER_TIMED_OUT > > > > > > > > cb_in: error: LIBUSB_TRANSFER_TIMED_OUT > > > > > > > > Regards, > > > > > > > > Victor > > > > > > > > ________________________________ > > > > From: Anastasia Klimchuk <aklm(a)chromium.org> > > > > Sent: Monday, April 8, 2024 06:00 > > > > To: Vlim <vlim(a)gigadevice.com>; Nikolai Artemiev <nartemiev(a)google.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Peter Marheine <pmarheine(a)chromium.org> > > > > Subject: Re: [flashrom] Re: adding part # > > > > > > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > > > > > > If I understand your question correctly, `–wp-status` command should > > > > give you the info: > > > > Prints the flash’s current status register protection mode and write > > > > protection range. > > > > > > > > Probably you have looked at that already, but just in case all > > > > available commands are in the man page, or also can be read here: > > > > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.… > > > > > > > > > > > > On Sun, Apr 7, 2024 at 7:55 AM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > > > > > Looked at it further and understood that it is determined by the BPx bits, tb bit. > > > > > Is there a way I can read the status registers to make sure that all these bits match with the datasheet? > > > > > > > > > > Regards, > > > > > > > > > > Victor > > > > > > > > > > > > > > > ________________________________ > > > > > From: Vlim <vlim(a)gigadevice.com> > > > > > Sent: Friday, April 5, 2024 20:37 > > > > > To: Nikolai Artemiev <nartemiev(a)google.com>; Anastasia Klimchuk <aklm(a)chromium.org> > > > > > Cc: flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Peter Marheine <pmarheine(a)chromium.org> > > > > > Subject: Re: [flashrom] Re: adding part # > > > > > > > > > > Thanks. > > > > > > > > > > How are the protection ranges defined? > > > > > My device has ½ to 1/512. > > > > > So I am missing 1/128, 1/256, 1/512. > > > > > And I am getting some extra from 1/1024 to 1/8192. > > > > > > > > > > Please advise. > > > > > > > > > > Regards, > > > > > > > > > > Victor > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > From: Nikolai Artemiev <nartemiev(a)google.com> > > > > > Sent: Tuesday, March 26, 2024 18:54 > > > > > To: Anastasia Klimchuk <aklm(a)chromium.org> > > > > > Cc: Vlim <vlim(a)gigadevice.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Peter Marheine <pmarheine(a)chromium.org> > > > > > Subject: Re: [flashrom] Re: adding part # > > > > > > > > > > You don't often get email from nartemiev(a)google.com. Learn why this is important > > > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > > > Hi Victor, > > > > > > > > > > One thing to note with the printlock and unlock functions you mentioned earlier, i.e.: > > > > > > > > > > .printlock = SPI_PRETTYPRINT_STATUS_REGISTER_BP4_SRWD, > > > > > .unlock = SPI_DISABLE_BLOCKPROTECT_BP4_SRWD, > > > > > > > > > > These functions basically just allow flashrom to remove memory protection before writing to the chip. They can (and should) be omitted if you define reg_bits and decode_range in the chip entry, because that will enable full writeprotect support for the chip. > > > > > > > > > > The reason we still have unlock and printlock functions is for older chips that don't have reg_bits and decode_range defined. > > > > > > > > > > Cheers, > > > > > Nik > > > > > > > > > > > > > > > > > > > > On Tue, Mar 26, 2024 at 4:32 PM Anastasia Klimchuk <aklm(a)chromium.org> wrote: > > > > > > > > > > I will try to answer to everything in one message, but feel free to > > > > > ask more questions > > > > > > > > > > > Can you point me to the file that defines the commands? > > > > > > > > > > Most of them will be in include/spi.h > > > > > > > > > > It is a longer way if you want to trace implementation from, for > > > > > example SPI_CHIP_READ, to the place where command is sent, but in case > > > > > you would need it: > > > > > > > > > > you would need to go through the sequence of function calls, starting > > > > > from `spi_chip_read` in spi.c and then look into the programmer code > > > > > (for whichever is the programmer you are using) and see how that > > > > > programmer implements spi read and send commands. Specifically look > > > > > for `static const struct spi_master` in the programmer source code > > > > > file. > > > > > > > > > > Default functions are in spi.c and spi25.c files. > > > > > > > > > > > How is Dual IO and Quad IO supported here? > > > > > > > > > > Currently not implemented, however it would be really great to > > > > > implement it in the future (contributions are very welcome). > > > > > We do have those aspirational comments in flashchips.c , for example > > > > > (I am just copying from some chip) > > > > > > > > > > .write = SPI_CHIP_WRITE256, /* Dual I/O (0xA2) supported */ > > > > > .read = SPI_CHIP_READ, /* Fast read (0x0B), dual I/O (0x3B) supported */ > > > > > > > > > > So maybe you can add similar comments for the chip definition for now. > > > > > > > > > > On Tue, Mar 26, 2024 at 5:27 AM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > Can you point me to the file that defines the commands? > > > > > > Like SPI_CHIP_READ being 0x0b. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Victor > > > > > > > > > > > > ________________________________ > > > > > > From: Anastasia Klimchuk <aklm(a)chromium.org> > > > > > > Sent: Thursday, March 21, 2024 23:32 > > > > > > To: Vlim <vlim(a)gigadevice.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org> > > > > > > Cc: Peter Marheine <pmarheine(a)chromium.org> > > > > > > Subject: Re: [flashrom] Re: adding part # > > > > > > > > > > > > [You don't often get email from aklm(a)chromium.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > > > > > > > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > > > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > > > > > > > > > > For these two (printlock and unlock), you need to pick the function > > > > > > which handles the highest BP bit that chip supports. In your example, > > > > > > if a chip supports bits BP0-BP4 the correct functions are those with > > > > > > BP4 in the name. So you did it all right. > > > > > > > > > > > > If the chip supports write protection, you also need to set .reg_bits > > > > > > in chip definition. For this you need to have a look at struct > > > > > > reg_bit_map in include/flash.h, it has comments on what each bit in > > > > > > the struct means. > > > > > > > > > > > > > > > > > > On Fri, Mar 22, 2024 at 7:22 AM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > > > > > > > > > Thanks, Anastasia, > > > > > > > > > > > > > > Can you please explain this statement, > > > > > > > > > > > > > > .printlock = SPI_PRETTYPRINT_STATUS_REGISTER_BP4_SRWD, > > > > > > > .unlock = SPI_DISABLE_BLOCKPROTECT_BP4_SRWD, > > > > > > > > > > > > > > Looks like this is to support memory array protection. But it needs BP0-BP4. > > > > > > > Do I need to specify BP0 to BP3 as well? > > > > > > > Or I specify the setting when I initiate the flashrom programming command? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Victor > > > > > > > > > > > > > > ________________________________ > > > > > > > From: Anastasia Klimchuk <aklm(a)chromium.org> > > > > > > > Sent: Thursday, March 21, 2024 05:32 > > > > > > > To: Vlim <vlim(a)gigadevice.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org> > > > > > > > Cc: Peter Marheine <pmarheine(a)chromium.org> > > > > > > > Subject: [flashrom] Re: adding part # > > > > > > > > > > > > > > You don't often get email from aklm(a)chromium.org. Learn why this is important > > > > > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > > > > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > > > > > Hello Victor, > > > > > > > > > > > > > > Various feature bits are defined as macros in include/flash.h , some of them have comments explaining what they do. If the feature name is not descriptive, and there is no comment, but you think you might need this feature: feel free to ask. I would try to add comments later. > > > > > > > > > > > > > > SPI_DISABLE_BLOCKPROTECT_BP4_SRWD and other unlock functions as in spi25_statusreg.c. Those functions have comments, hopefully this can help! > > > > > > > > > > > > > > On Thu, Mar 21, 2024 at 2:48 PM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > > > > > > > > > Thanks, Peter, > > > > > > > > > > > > > > Where can I find the definition of terms like, > > > > > > > > > > > > > > .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_WRSR_EXT2, > > > > > > > SPI_DISABLE_BLOCKPROTECT_BP4_SRWD > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Victor > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > From: Peter Marheine <pmarheine(a)chromium.org> > > > > > > > Sent: Tuesday, March 19, 2024 15:42 > > > > > > > To: Vlim <vlim(a)gigadevice.com> > > > > > > > Cc: flashrom(a)flashrom.org <flashrom(a)flashrom.org> > > > > > > > Subject: Re: [flashrom] adding part # > > > > > > > > > > > > > > You don't often get email from pmarheine(a)chromium.org. Learn why this is important > > > > > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > > > > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > > > > > Our "how to add a new chip" documentation should point you in the right direction: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.… > > > > > > > > > > > > > > But feel free to ask further questions if anything there doesn't seem sufficient for your needs. > > > > > > > > > > > > > > On Wed, Mar 20, 2024 at 6:31 AM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > > > > > > > > > Hi, FlashRom team, > > > > > > > > > > > > > > I am the FAE director in Gigadevice and I would like to add some part #s to the flashchip.c and flashchip.h. > > > > > > > Can you please provide some guidance? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Victor Lim > > > > > > > FAE Director > > > > > > > GigaDevice Semiconductor > > > > > > > 4088833856 > > > > > > > > > > > > > > _______________________________________________ > > > > > > > flashrom mailing list -- flashrom(a)flashrom.org > > > > > > > To unsubscribe send an email to flashrom-leave(a)flashrom.org > > > > > > > > > > > > > > _______________________________________________ > > > > > > > flashrom mailing list -- flashrom(a)flashrom.org > > > > > > > To unsubscribe send an email to flashrom-leave(a)flashrom.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Anastasia. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Anastasia. > > > > > > > > > > > > > > > > > > > > -- > > > > > Anastasia. > > > > > _______________________________________________ > > > > > flashrom mailing list -- flashrom(a)flashrom.org > > > > > To unsubscribe send an email to flashrom-leave(a)flashrom.org > > > > > > > > > > > > > > > > -- > > > > Anastasia. > > > > > > > > > > > > -- > > > Anastasia. > > > > > > > > -- > > Anastasia. > > > > -- > Anastasia. > > > > -- > Anastasia. -- Anastasia.

1 0

Re: adding part #
by Anastasia Klimchuk April 18, 2024

April 18, 2024

If I understand your question correctly, `–wp-status` command should give you the info: Prints the flash’s current status register protection mode and write protection range. Probably you have looked at that already, but just in case all available commands are in the man page, or also can be read here: https://flashrom.org/classic_cli_manpage.html On Sun, Apr 7, 2024 at 7:55 AM Vlim <vlim(a)gigadevice.com> wrote: > > Looked at it further and understood that it is determined by the BPx bits, tb bit. > Is there a way I can read the status registers to make sure that all these bits match with the datasheet? > > Regards, > > Victor > > > ________________________________ > From: Vlim <vlim(a)gigadevice.com> > Sent: Friday, April 5, 2024 20:37 > To: Nikolai Artemiev <nartemiev(a)google.com>; Anastasia Klimchuk <aklm(a)chromium.org> > Cc: flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Peter Marheine <pmarheine(a)chromium.org> > Subject: Re: [flashrom] Re: adding part # > > Thanks. > > How are the protection ranges defined? > My device has ½ to 1/512. > So I am missing 1/128, 1/256, 1/512. > And I am getting some extra from 1/1024 to 1/8192. > > Please advise. > > Regards, > > Victor > > > > ________________________________ > From: Nikolai Artemiev <nartemiev(a)google.com> > Sent: Tuesday, March 26, 2024 18:54 > To: Anastasia Klimchuk <aklm(a)chromium.org> > Cc: Vlim <vlim(a)gigadevice.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Peter Marheine <pmarheine(a)chromium.org> > Subject: Re: [flashrom] Re: adding part # > > You don't often get email from nartemiev(a)google.com. Learn why this is important > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > Hi Victor, > > One thing to note with the printlock and unlock functions you mentioned earlier, i.e.: > > .printlock = SPI_PRETTYPRINT_STATUS_REGISTER_BP4_SRWD, > .unlock = SPI_DISABLE_BLOCKPROTECT_BP4_SRWD, > > These functions basically just allow flashrom to remove memory protection before writing to the chip. They can (and should) be omitted if you define reg_bits and decode_range in the chip entry, because that will enable full writeprotect support for the chip. > > The reason we still have unlock and printlock functions is for older chips that don't have reg_bits and decode_range defined. > > Cheers, > Nik > > > > On Tue, Mar 26, 2024 at 4:32 PM Anastasia Klimchuk <aklm(a)chromium.org> wrote: > > I will try to answer to everything in one message, but feel free to > ask more questions > > > Can you point me to the file that defines the commands? > > Most of them will be in include/spi.h > > It is a longer way if you want to trace implementation from, for > example SPI_CHIP_READ, to the place where command is sent, but in case > you would need it: > > you would need to go through the sequence of function calls, starting > from `spi_chip_read` in spi.c and then look into the programmer code > (for whichever is the programmer you are using) and see how that > programmer implements spi read and send commands. Specifically look > for `static const struct spi_master` in the programmer source code > file. > > Default functions are in spi.c and spi25.c files. > > > How is Dual IO and Quad IO supported here? > > Currently not implemented, however it would be really great to > implement it in the future (contributions are very welcome). > We do have those aspirational comments in flashchips.c , for example > (I am just copying from some chip) > > .write = SPI_CHIP_WRITE256, /* Dual I/O (0xA2) supported */ > .read = SPI_CHIP_READ, /* Fast read (0x0B), dual I/O (0x3B) supported */ > > So maybe you can add similar comments for the chip definition for now. > > On Tue, Mar 26, 2024 at 5:27 AM Vlim <vlim(a)gigadevice.com> wrote: > > > > Hi, > > > > Can you point me to the file that defines the commands? > > Like SPI_CHIP_READ being 0x0b. > > > > Thanks, > > > > Victor > > > > ________________________________ > > From: Anastasia Klimchuk <aklm(a)chromium.org> > > Sent: Thursday, March 21, 2024 23:32 > > To: Vlim <vlim(a)gigadevice.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org> > > Cc: Peter Marheine <pmarheine(a)chromium.org> > > Subject: Re: [flashrom] Re: adding part # > > > > [You don't often get email from aklm(a)chromium.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] > > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > > For these two (printlock and unlock), you need to pick the function > > which handles the highest BP bit that chip supports. In your example, > > if a chip supports bits BP0-BP4 the correct functions are those with > > BP4 in the name. So you did it all right. > > > > If the chip supports write protection, you also need to set .reg_bits > > in chip definition. For this you need to have a look at struct > > reg_bit_map in include/flash.h, it has comments on what each bit in > > the struct means. > > > > > > On Fri, Mar 22, 2024 at 7:22 AM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > Thanks, Anastasia, > > > > > > Can you please explain this statement, > > > > > > .printlock = SPI_PRETTYPRINT_STATUS_REGISTER_BP4_SRWD, > > > .unlock = SPI_DISABLE_BLOCKPROTECT_BP4_SRWD, > > > > > > Looks like this is to support memory array protection. But it needs BP0-BP4. > > > Do I need to specify BP0 to BP3 as well? > > > Or I specify the setting when I initiate the flashrom programming command? > > > > > > Regards, > > > > > > Victor > > > > > > ________________________________ > > > From: Anastasia Klimchuk <aklm(a)chromium.org> > > > Sent: Thursday, March 21, 2024 05:32 > > > To: Vlim <vlim(a)gigadevice.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org> > > > Cc: Peter Marheine <pmarheine(a)chromium.org> > > > Subject: [flashrom] Re: adding part # > > > > > > You don't often get email from aklm(a)chromium.org. Learn why this is important > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > Hello Victor, > > > > > > Various feature bits are defined as macros in include/flash.h , some of them have comments explaining what they do. If the feature name is not descriptive, and there is no comment, but you think you might need this feature: feel free to ask. I would try to add comments later. > > > > > > SPI_DISABLE_BLOCKPROTECT_BP4_SRWD and other unlock functions as in spi25_statusreg.c. Those functions have comments, hopefully this can help! > > > > > > On Thu, Mar 21, 2024 at 2:48 PM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > Thanks, Peter, > > > > > > Where can I find the definition of terms like, > > > > > > .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_WRSR_EXT2, > > > SPI_DISABLE_BLOCKPROTECT_BP4_SRWD > > > > > > Regards, > > > > > > Victor > > > > > > > > > ________________________________ > > > From: Peter Marheine <pmarheine(a)chromium.org> > > > Sent: Tuesday, March 19, 2024 15:42 > > > To: Vlim <vlim(a)gigadevice.com> > > > Cc: flashrom(a)flashrom.org <flashrom(a)flashrom.org> > > > Subject: Re: [flashrom] adding part # > > > > > > You don't often get email from pmarheine(a)chromium.org. Learn why this is important > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information > > > Our "how to add a new chip" documentation should point you in the right direction: https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.… > > > > > > But feel free to ask further questions if anything there doesn't seem sufficient for your needs. > > > > > > On Wed, Mar 20, 2024 at 6:31 AM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > Hi, FlashRom team, > > > > > > I am the FAE director in Gigadevice and I would like to add some part #s to the flashchip.c and flashchip.h. > > > Can you please provide some guidance? > > > > > > Regards, > > > > > > Victor Lim > > > FAE Director > > > GigaDevice Semiconductor > > > 4088833856 > > > > > > _______________________________________________ > > > flashrom mailing list -- flashrom(a)flashrom.org > > > To unsubscribe send an email to flashrom-leave(a)flashrom.org > > > > > > _______________________________________________ > > > flashrom mailing list -- flashrom(a)flashrom.org > > > To unsubscribe send an email to flashrom-leave(a)flashrom.org > > > > > > > > > > > > -- > > > Anastasia. > > > > > > > > -- > > Anastasia. > > > > -- > Anastasia. > _______________________________________________ > flashrom mailing list -- flashrom(a)flashrom.org > To unsubscribe send an email to flashrom-leave(a)flashrom.org -- Anastasia.

2 7

logs
by Krasen Tsonevski April 15, 2024

April 15, 2024

:~# /usr/local/sbin/flashrom -p ch341a_spi -w /home/ssss/SMT_X10IPMI_400_REDFISH.bin flashrom 1.4.0-devel (git:v1.2-1414-g2a5d2920) on Linux 5.15.0-102-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found Macronix flash chip "MX25L25635F/MX25L25645G" (32768 kB, SPI) on ch341a_spi. === This flash part has status UNTESTED for operations: WP The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. You can also try to follow the instructions here: https://www.flashrom.org/contrib_howtos/how_to_mark_chip_tested.html Thanks for your help! Unsetting lock bit(s) failed. Reading old flash chip contents... done. FAILED at 0x0044f004! Expected=0xff, Found=0xc1, failed byte count from 0x0044f000-0x0044ffff: 0x7 ERASE FAILED! Erase/write done from 0 to 1ffffff Write Failed!Uh oh. Erase/write failed. Checking if anything has changed. Reading current flash chip contents... done. Apparently at least some data has changed. Your flash chip is in an unknown state. Please report this to the mailing list at flashrom(a)flashrom.org or on IRC (see https://www.flashrom.org/Contact for details), thanks! --- Krasen Tsonevski IT Manager office: +359 2 975 16 16 mobile: +359 885 516 070 [ http://www.neterra.net/ | www.neterra.net ] [ https://neterra.net/network-access/dia-dedicated-internet-access ]

1 0

RFC: remove the calibrated delay loop
by Peter Marheine April 12, 2024

April 12, 2024

Proposed changes in https://review.coreboot.org/c/flashrom/+/80806 have gotten me thinking about the problems with flashrom's current delay implementation, following which I've got a few ideas about how it can be improved. If other developers agree that these changes are reasonable, I think I'll go ahead and work on them. Although I've measured some data, I haven't yet attempted to quantify the overall performance effect to flashrom from these changes because that would require implementing them. I do expect that I would gather that data for an actual implementation. ## Proposals 1. Remove support for delaying inside flashrom using a calibrated busy-loop. Delete `myusec_delay` and `myusec_calibrate_delay`. 2. Remove probing for OS timer resolution. Delete `clock_check_res` and `measure_os_delay_resolution`. Always use `clock_gettime`-based timing for busy-loops, or `gettimeofday` if `clock_gettime` is unavailable. 3. Make the threshold in `default_delay` to choose between sleep or busy-looping configurable at build time. Reduce the default from 100ms to 100μs. 4. Automatically attempt to run flashrom at realtime priority when supported by the system, to minimize timing error. ## Rationale Each of these proposed changes fits in with the others to simplify how flashrom delays while waiting for work to complete, but their reasons are largely independent. ### Calibrated busy-loop removal Flashrom's calibrated busy-loop is as old as flashrom itself, with its principle of operation first being established before 2003; the first commit to the flashrom repository included a version of `myusec_calibrate_delay` which attempted to count the number of iterations of an empty loop that the CPU could execute in 250ms. That initial version searched by doubling its delay time for each attempt, so delays could have been up to twice the length specified. On modern systems, it is a grave mistake to assume that any CPU-based calibration process can accurately measure real time by counting the number of instructions executed (or the number of loop iterations completed). Runtime frequency changes have become much more common in the intervening 20 years, and if CPU frequency changes while flashrom is running then calibration becomes wrong. On systems where all processors have the same maximum frequency, delay loop calibration tends to be fairly accurate because the current implementation calibrates for 1 second and this is at least as long as most systems take to reach their maximum clock speed under load. Short delays could be much longer than expected if the CPU clocked back down after calibration, but the calibrated delay would generally be close to correct at maximum speed so it would be unlikely to delay for less time than expected. Today's CPUs are even more heterogenous, however. ARM machines have used heterogenous multiprocessors since about 2011, and recent x86 systems from both Intel and AMD can also have different maximum clock speeds for different cores. On these machines, a delay loop calibrated on a CPU with lower maximum frequency could delay for too short a time when run on a different CPU with higher maximum speed. Even SMT systems that have dynamic thread scheduling policy for each physical core might exhibit higher performance if a sibling thread is idle! Although it may be possible to compensate for heterogenous multiprocessors (for example by calibrating delays for each CPU in the system or pinning flashrom to a single CPU using OS APIs), doing so would either increase runtime costs further or add to the maintenance burden of the flashrom maintainers. Because it is difficult to ensure a calibrated delay loop is actually correct, we should never use one. ### Ignoring OS-reported timer resolution On Linux, `clock_getres` is documented to lie sometimes: a "tickless" kernel can generally report times with nanosecond resolution, but `clock_getres` reports resolution of around 1 millisecond. This confounds flashrom, causing it to use the calibrated delay loop instead of OS timing. Because we cannot assume a CPU busy-loop to ever be truly calibrated on modern machines without significant effort, it is useless to try to use reported timer resolution as a signal to use a busy-loop instead (because there is no busy-loop to fall back to). We should instead use whatever OS timing is available. `gettimeofday` is specified as early as System V r4, but is deprecated in POSIX.1-2008. `clock_gettime` is mandatory since POSIX.1-2008. Some systems that we wish to support may lack `clock_gettime`, which is preferred because it offers nanosecond resolution to `gettimeofday`'s microsecond resolution and offers clock options that will never be discontinuous (for example due to daylight savings or leap seconds). Between these two functions, all platforms that flashrom wishes to support should be supportable. ### Reduced sleep thresholds On modern machines, the current 100 millisecond maximum busy-wait time is an eternity (and until recently it was 1 second, which is even more ridiculous). We can save a lot of power by giving up the CPU more readily, but choosing a threshold is somewhat challenging. Modern x86 systems have typical context switch latency (from suspending one process, deferring to the kernel, and restarting another process) of around 2 microseconds, so this is a reasonable starting point for the maximum time to busy-wait for: it's unlikely that another process can do anything useful in less that 2 microseconds, or that the OS can suspend the CPU to save energy. From surveying delay calls within flashrom, they span a large range from 1 microsecond up to a whole second. By inspection, 10 microseconds seems to be a common delay used when polling for completion of some operation. A few delay users describe how long it's usually expected for a polled operation to take, but most don't so it's difficult to tell how accurate the delays actually should be in order to minimize wasted time. #### Wakeup latency measurements To evaluate how much timing slop might be introduced by sleeping instead of busy-looping for short delays (less than 1 millisecond), I measured the latency of several operations on a selection of various Linux machines to evaluate how much longer it takes a program to actually resume from `nanosleep` versus the requested wait time. The systems were: * Mediatek Kompanio 500 (MT8173). Four ARMv7 cores running at up to 2 GHz. * Intel Xeon Gold 6154 (Xeon). Two sockets, each with 18 physical cores running 36 threads. * Intel Celeron N3350 (APL). Two x86 cores running at 1.1 GHz, up to 2.4 GHz. * AMD A4-9120C (AMD). Two x86 cores at 1.6 GHz, up to 2.4 GHz. * Intel Core Ultra 5 115U (MTL). Eight x86 cores in three performance tiers at 0.7-1.5 GHz, up to 2.1-4.2 GHz. I ran four tests each 16k times, getting the time elapsed for each iteration by calling `clock_gettime` immediately before and after each test. The minimum, maximum and mean time taken for each test was recorded. On all systems the reported timer resolution via `clock_getres` was 1 nanosecond. * nop: do nothing * sched_yield: call sched_yield() to attempt to run a different task without specifying a wait time * nanosleep 1u: call nanosleep() with a requested wait time of 1 microsecond * nanosleep 100u: call nanosleep() with a requested wait time of 100 microseconds The nop case provides baseline information on how long it takes to measure the time it takes an operation to complete. sched_yield approximates syscall and scheduling overhead, under the assumption that the OS will run its scheduler to see if another process wants the CPU. If it does, the delay time could be greatly increased because another process may get the CPU. The two nanosleep cases allow us to see how long a process that sleeps actually suspends for, and looking at two different delays is useful in case the OS tends to get sloppier if we request longer delays. In the following table, measured times are in microseconds, listed as mean / min / max. | Machine / Test | nop | sched_yield | nanosleep 1u | nanosleep 100u | |----------------|---------------------|-------------------|--------------------|-----------------------| | AMD | 0.1 / 0.06 / 38.3 | 0.6 / 0.6 / 100.1 | 64.5 / 6.4 / 2151 | 106.3 / 104.2 / 9619 | | MT8173 | 0.1 / 0.07 / 16.7 | 1.8 / 1.5 / 251.9 | 82.4 / 7.8 / 3051 | 195.9 / 109.3 / 5616 | | APL | 0.05 / 0.04 / 14.3 | 0.7 / 0.6 / 51.3 | 57.2 / 7.1 / 1236 | 217.6 / 108.4 / 10430 | | Xeon | 0.02 / 0.02 / 0.07 | 1.7 / 1.4 / 73.2 | 57.8 / 11.3 / 618 | 157.8 / 106.9 / 1299 | | MTL | 0.05 / 0.03 / 101.9 | 0.4 / 0.4 / 7.1 | 53.0 / 4.6 / 139 | 151.7 / 101.5 / 245 | Latency in excess of the requested wait time is fairly consistent, on average about 60 microseconds and within as little as 10% of the requested time for 100 microsecond delays. Very short delays tend to be worse, and the average case does notably better on systems with more CPU cores- probably because the CPU sometimes gets given to another process and causes long delays while that other process runs or the OS is doing some uninterruptible operation. These numbers are similar to the ones reported in https://review.coreboot.org/c/flashrom/+/80808, which lends credibility to this measurement method. High-resolution timers there improved minimum latency slightly, but as we'll see next, different scheduling improves the situation more. --- I also ran the tests with realtime scheduling policy (as in `sched_setscheduler(SCHED_FIFO)`) using `chrt --fifo 1` to run at the minimum priority within the FIFO real-time class. This is expected to reduce latency both by giving this process priority over all other processes on the system, and by allowing the OS to use a simpler scheduling algorithm when ultimately choosing to restart the process under test. In this table the nop and sched_yield tests are omitted because they are not as informative as the actual nanosleep numbers. | Machine / Test | nanosleep 1u | nanosleep 100u | |----------------|----------------------|------------------------| | AMD | 9.2 / 4.8 / 18.6 | 129.1 / 104.7 / 512.2 | | MT8173 | 13.5 / 6.8 / 1505 | 117.2 / 106.7 / 1022 | | APL | 5.4 / 4.8 / 45.2 | 106.3 / 104.2 / 452.3 | | Xeon | 4.4 / 4.2 / 60.2 | 104.9 / 103.0 / 164.9 | | MTL | 2.4 / 2.1 / 74.2 | 102.4 / 101.2 / 123.0 | At real-time priority, 1-microsecond sleeps look like they're basically only paying the cost of a context switch and 100-microsecond sleeps are more consistent than they were at normal priority: the average case is now accurate to within better than 10% on the faster machines with the slower ones not doing much worse. #### Practical sleep thresholds The existing code in flashrom that uses `clock_getres` rejects OS timers as a timing source if the resolution is less than 100 nanoseconds. Since the delay functions operate with microsecond precision, this suggests that it targets 10% accuracy for short waits and significantly better than that for long ones. Because we see that 10% accuracy is feasible on most systems for 100 microsecond sleeps, this seems like a reasonable minimum time to sleep for. Even on systems where accuracy is worse than 10%, use of `sleep`-style APIs guarantees that delays will never be less than the specified time: this approach will never malfunction, but unexpectedly long delays could make flash programming take longer than it would otherwise. Not all users or distributors will agree with this decision. Some very slow or old machines might achieve much worse precision such that it's considered worthwhile to busy-wait more aggressively (in order to complete programming more quickly), while some users might prefer to take every opportunity to save power by always sleeping. As a result, I believe this threshold should be made a compile-time option defaulting to 100 microseconds (although the final choice for the default can easily be adjusted). #### Use of real-time scheduling The accuracy of `sleep` APIs can be improved by using real-time scheduling classes as specified by POSIX, but enabling that for a given process usually requires special privileges. Many users run flashrom as the root user so it has the ability to make itself realtime, but there are also many applications where it need not run with root privileges. Because realtime priority is not required for correct operation, flashrom should attempt to make itself realtime but continue even if unable to do so. An informational message should be emitted if that fails so users can be aware that granting flashrom additional privileges may yield better performance. In libflashrom, realtime scheduling should not be enabled by default because it is very difficult to reason about the possible effects of changing a host process' scheduling class. Programs using flashrom as a library should manage priority themselves.

5 10