- flashrom - mail.coreboot.org

flashrom release v1.4.0 is out
by Anastasia Klimchuk 26 Jul '24

26 Jul '24

Good day everyone, flashrom release v1.4.0 is out! Tarball: https://download.flashrom.org/releases/flashrom-1.4.0.tar.xz Signature: https://download.flashrom.org/releases/flashrom-1.4.0.tar.xz.asc Fingerprint: 6E6E F9A0 BA47 8006 E277 6E4C C037 BB41 3134 D111 Checkout from git repository: by the tag v1.4.0 on the main branch. Release notes published: https://flashrom.org/release_notes/v_1_4.html Since the previous v1.3.0 we got 438 commits from 73 authors. Thank you all so much! Many thanks to all our amazing contributors, reviewers, developers, maintainers, and everyone who supports flashrom in any way <3 All the patches that have been ready and waiting, will be submitted very soon. We return back to the normal development process. -- Anastasia.

1 0

FAILED: <Lantis>
by Abhinav Thulung 24 Jul '24

24 Jul '24

Hello flashrom, I was trying to disable WP with you software and decided to type “flashrom —erase” It now says: “Transaction error between offset 0x00bca000 and 0x00bca000 (= 0x00bca000 + 0)! ERASE_FALIED FAILED! Your flash chip is in an unknown state.” It then shows some ways to seek help, the it says: “DO NOT REBOOT OR POWEROFF! FAILED” What should I do? I can’t leave this like that forever. Please respond, I know you guys are busy people, but I would be forever grateful if you help me. Thanks. P.S: I have no ch341a USB or soldering items on me, I have no idea what I’m doing.

1 0

HELPPPP
by Anonymous 23 Jul '24

23 Jul '24

hello people, i want to restore my chromebook to its original state after installing windows. i booted it into a live ubuntu usb and i connected it into the internet, i installed curl and then i ran this command: cd ~; curl -L -O https://coolstar.org/chromebook/setup... && sudo bash setup-firmware.sh it gave me an error cuz they removed the file so i downloaded an archived one using the wayback machine. then i did sudo bash setup-firmware.sh and it gave me this error: Getting device/system info... Unable to read current firmware; cannot continue. Either add 'iomem=relaxed' to your kernel parameters, or trying running from a Live USB with a more permissive kernel (eg, Ubuntu). See https://www.flashrom.org/FAQ for more info

1 0

Could not read internal BIOS/UEFI FW chip on ASRock B450M Pro4 R2.0
by Jacob G 23 Jul '24

23 Jul '24

Hello - I was told to email by flashrom :) I tried to read the BIOS chip in my ASRock B450M Pro4 R2.0, with UEFI firmware version 10.20 (recently released - less than a month old) with flashrom and it failed: [nix-shell:~]$ sudo flashrom -p internal -r asrock-b450mpro4-efifw.rom [sudo] password for jrg: flashrom v1.3.0 on Linux 6.6.39 (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 chipset "AMD FP4". Enabling flash write... FCH device found but SMBus revision 0x51 does not match known values. Please report this to flashrom(a)flashrom.org and include this log and the output of lspci -nnvx, thanks!. Could not determine chipset generation.PROBLEMS, continuing anyway No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. Here is your requested information. The output of lspci -nnvx is in the attached .log file.

1 0

release v1.4.0 plan and timeline
by Anastasia Klimchuk 11 Jul '24

11 Jul '24

Good day everyone, We are preparing to do v1.4.0 release and below is the plan and timeline. TLDR: The release will be from the main branch. Testing and bug fixing window is from 28 June to 26 July, any help is highly appreciated! https://flashrom.org/how_to_support_flashrom.html#building-and-testing Known issue: https://ticket.coreboot.org/issues/370 More details: #1 In two weeks, on 28 June, we update the VERSION file to 1.4.0-rc1 and put a tag v1.4.0-rc1 (which means the first release candidate). From that moment, we open a 4-weeks window for testing and bugfixing. That is from 28 June to 26 July. During this window, bug fixes will be reviewed and submitted, but things like new features/refactorings etc will need to wait until 26 July. Just to be clear, any patch with new feature can be pushed and reviewed, it just won't be submitted until 26 July. Any help is very much appreciated during this time. #2 If needed, we can create v1.4.0-rc2 during the window #3 On 26 July, we update the VERSION file to 1.4.0 and put a tag v1.4.0 Then, there will be an announcement about the release, with the link to full release notes. After all that, VERSION file will be updated to 1.5.0-devel, all the patches that are ready and have been waiting, will be submitted, and everything gets back to normal. If later a point release is needed, it will be branched from v1.4.0 tag. Also, we plan to do another release later this year. So everything that didn't get submitted until 28 June (and by this didn't get into 1.4), can get into 1.5 later this year. Note there is a known issue: https://ticket.coreboot.org/issues/370 -- Anastasia.

1 2

CHIPSET: Intel Kaby Lake U w/ iHDCP2.2 Prem
by Jason Whitaker 09 Jul '24

09 Jul '24

Unsure of board URL, this is an Asus Chromebox for Google Meet: https://www.asus.com/displays-desktops/mini-pcs/chrome-os-devices/asus-goog… Happy to test builds or offer hardware in exchange for help - I have several of these and am using the Mr Chromebox installer on them. Thanks. lspci: 00:00.0 Host bridge: Intel Corporation Device 5914 (rev 08) 00:02.0 VGA compatible controller: Intel Corporation Device 5917 (rev 07) 00:04.0 Signal processing controller: Intel Corporation Device 1903 (rev 08) 00:08.0 System peripheral: Intel Corporation Sky Lake Gaussian Mixture Model 00:14.0 USB controller: Intel Corporation Device 9d2f (rev 21) 00:14.2 Signal processing controller: Intel Corporation Device 9d31 (rev 21) 00:15.0 Signal processing controller: Intel Corporation Device 9d60 (rev 21) 00:15.2 Signal processing controller: Intel Corporation Device 9d62 (rev 21) 00:17.0 SATA controller: Intel Corporation Device 9d03 (rev 21) 00:19.0 Signal processing controller: Intel Corporation Device 9d66 (rev 21) 00:19.1 Signal processing controller: Intel Corporation Device 9d65 (rev 21) 00:1c.0 PCI bridge: Intel Corporation Device 9d12 (rev f1) 00:1c.3 PCI bridge: Intel Corporation Device 9d13 (rev f1) 00:1e.0 Signal processing controller: Intel Corporation Device 9d27 (rev 21) 00:1e.2 Signal processing controller: Intel Corporation Device 9d29 (rev 21) 00:1e.6 SD Host controller: Intel Corporation Device 9d2d (rev 21) 00:1f.0 ISA bridge: Intel Corporation Device 9d4e (rev 21) 00:1f.2 Memory controller: Intel Corporation Device 9d21 (rev 21) 00:1f.3 Multimedia audio controller: Intel Corporation Device 9d71 (rev 21) 00:1f.4 SMBus: Intel Corporation Device 9d23 (rev 21) 00:1f.5 Non-VGA unclassified device: Intel Corporation Device 9d24 (rev 21) 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59)

2 1

flashrom dev meeting notes 27.06.2024
by Anastasia Klimchuk 02 Jul '24

02 Jul '24

# 27th June 2024, 6:00-7:00 UTC+0 https://ticket.coreboot.org/issues/542 https://ticket.coreboot.org/issues/543 https://ticket.coreboot.org/issues/545 Attendees: Joursoir, Anastasia ## Agenda * As the time goes, chip vendors are producing newer models, which sometimes re-use model IDs of old versions. Old versions are considered as "end of life", and replaced with newer models with more features. However flashchips.c accumulates everything and with time we get more and more duplicate model IDs. This makes adding new models harder, but also increases the chance users need to manually specify the chip model. Question: How can we avoid old chip models dragging down adding new ones, without completely removing them from the database (some users might still be using end-of-life chips)? * probably wasn't an issue 20 years ago when flashchips.c was designed, but now it is * have a flag "end of life" for chip definition? by default, given multiple definitions of the same model ID, the definition without a flag be selected? * vendors adding new model can mark old one end-of-life, in the same patch * [joursoir] It doesn't bother me. maybe it's not a big problem? but just having a flag "end-of-life" for information might be useful * need to be a good clear name, because flashrom still supports everything! * separate file flashchips_legacy.c for old chips? * bad: moving definitions from one file to another is pita * CONCLUSION: maybe we can add a flag to flashchip struct and no changes to probing logic yet. * ticket: [https://ticket.coreboot.org/issues/542](https://ticket.coreboot.org/issues/… * non-SPI chips are rarely used, and need special treatment in many places in the code. The code for non-SPI (flashchips definitions, parallel programmers, pieces of core logic) hasn't been updated or maintained for many years, So there are no new chips added or new features to the programmers. * maybe we can create a separate repo "flashrom-non-spi" with all the code. it will probably have 1 commit a year, or even less. The rest of code (SPI and PROG) will be simplified, better tested and can add new modern features * it will be too confusing for users, they might not know what they have, SPI or not * two binaries is confusing too * CONCLUSION: this idea is too wild, don't do this * [joursoir] It would be nice to have a pretty table of supported chips (like we had on the old wiki) on our website. Right now, there's flashrom option that prints chips in html format, however we need to rewrite it to rst so sphinx can use it. are there any pitfalls? * we can do 2-step process: one step generates .rst file (logic can be based on print.c), second step is normal build with documentation, and sphinx will generate html file for the website. * we can generate and publish html page with supported devices for the latest release. * developers who are interested what is supported at head, can look into source code or run `flashrom -L` . no need to generate html between releases. * [joursoir] I will do it! * ticket: [https://ticket.coreboot.org/issues/543](https://ticket.coreboot.org/issues/… * How about, we split our large file flashchips.c into smaller files, per manufacturer? * seems like a good idea * smaller files can get different maintainers per file => easier to get attention to your patch for flashchip * less merge conflicts * easier to find chips, easier to maintain * for example, const struct flashchip flashchips[] = { #include "chips/gigadevice.inc" #include "chips/macronix.inc" #include "chips/winbond.inc" } .inc is not valid c file, just a piece of code (slice array) another idea can be array of .c files * ticket: [https://ticket.coreboot.org/issues/545](https://ticket.coreboot.org/issues/… -- Anastasia.

3 5

FCH device found but SMBus revision 0x71 does not match known values
by tihmstar 25 Jun '24

25 Jun '24

Hi i have a QNAP TS-H1677AXU-RP-R7-32G NAS and i'm running a very unsupported config. I installed my own linux on it and somehow managed to enable secureboot, even though the bios doesn't have any settings regarding that. I would like to also enable TPM (from my understanding the installed AMD Ryzen 7 7700 should have fTPM?), but BIOS doesn't have any options about that either. It's weird, because the mainboard even has a dedicated TPM slot for external TPM. On further research i found this article https://ristovski.github.io/posts/inside-insydeh2o/ mentioning flashrom tool for dumping bios. I tried it but no success. It did say to send you an email, so here you go. Maybe you can help me with my journey to dump my bios? If nothing else, maybe the attached log is helpful to you. Cheers tihmstar

1 0

FAILED: juniper router
by Steve Topletz 25 Jun '24

25 Jun '24

I have previously backed up the bios and am attempting to erase it, and am left in an "unknown" state. My desire is to successfully execute the erase. I am constrained from physically disassembling the mx204 router to confirm the board and chip. Multiple flash chip definitions match the detected chip(s): "MX25L12805D", "MX25L12833F", "MX25L12835F/MX25L12873F", "MX25L12845E/MX25L12865E", "MX25L12850F" I tried doing wp-status on all of them, and all responded "Cannot read SECURITY: unsupported by chip" except for "MX25L12850F" which responded: Protection range: start=0x00000000 length=0x00000000 (none) Protection mode: disabled node:/var/tmp/fw/x86_64-linux-gnu/sbin# ./flashrom -p internal:laptop=this_is_not_a_laptop -c "MX25L12850F" --ifd -i bios --erase -noverify-all --force -V flashrom 1.4.0-devel on Linux 5.2.60-rt15-LTS19 (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with GCC 12.2.0, little endian Command line (11 args): ./flashrom -p internal:laptop=this_is_not_a_laptop -c MX25L12850F --ifd -i bios --erase -noverify-all --force -V Initializing internal programmer /sys/class/mtd/mtd0 does not exist No coreboot table found. Using Internal DMI decoder. No DMI table found. Found chipset "Intel C610/X99 (Wellsburg)" with PCI ID 8086:8d44. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0xc01: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (unknown) Top Swap: not enabled 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x4 0x7fffffff/0x7fffffff FWH IDSEL: 0x5 0x7fffffff/0x7fffffff FWH IDSEL: 0x6 0x7fffffff/0x7fffffff FWH IDSEL: 0x7 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching disabled, caching enabled, BIOS_CNTL = 0x22: BIOS Lock Enable: enabled, BIOS Write Enable: disabled Warning: BIOS region SMM protection is enabled! Warning: Setting BIOS Control at 0xdc from 0x22 to 0x01 failed. New value is 0x22. SPIBAR = 0x00007fa5f44f1000 + 0x3800 0x04: 0xe008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 SPI Configuration is locked down. Reading OPCODES... done 0x06: 0x0004 (HSFC) HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0 0x50: 0x00007a5b (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0x7a, BRRA 0x5b 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. 0x58: 0x0fff0800 FREG1: BIOS region (0x00800000-0x00ffffff) is read-write. 0x5C: 0x07ff0003 FREG2: Management Engine region (0x00003000-0x007fffff) is locked. 0x60: 0x00020001 FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write. Not all flash regions are freely accessible by flashrom. This is most likely due to an active ME. Please see https://flashrom.org/ME for details. 0x74: 0x8fff0de0 PR0: Warning: 0x00de0000-0x00ffffff is read-only. 0x78: 0x8dab0dab PR1: Warning: 0x00dab000-0x00dabfff is read-only. 0x7C: 0x8da30d80 PR2: Warning: 0x00d80000-0x00da3fff is read-only. 0x80: 0x8cfe0820 PR3: Warning: 0x00820000-0x00cfefff is read-only. 0x84: 0x80000000 PR4: Warning: 0x00000000-0x00000fff is read-only. At least some flash regions are read protected. You have to use a flash layout and include only accessible regions. For write operations, you'll additionally need the --noverify-all switch. See manpage for more details. 0x90: 0x84 (SSFS) SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 0x91: 0xf84150 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=5, DBC=1, SME=0, SCF=0 0x94: 0x0606 (PREOP) 0x96: 0xf27c (OPTYPE) 0x98: 0x0002209f (OPMENU) 0x9c: 0x00000503 (OPMENU+4) 0xa0: 0x00000000 (BBAR) 0xc4: 0x80802015 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=1, EO=0x20, VCL=1 0xc8: 0x00002015 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=1, EO=0x20 0xd0: 0x50444653 (FPB) OK. ======================================================================== You may be running flashrom on an unknown laptop. We could not detect this for sure because your vendor has not set up the SMBIOS tables correctly. Some internal buses have been disabled for safety reasons. You can enforce using all buses by adding -p internal:laptop=this_is_not_a_laptop to the command line, but please read the following warning if you are not sure. Laptops, notebooks and netbooks are difficult to support and we recommend to use the vendor flashing utility. The embedded controller (EC) in these machines often interacts badly with flashing. See the manpage and https://flashrom.org/Laptops for details. If flash is shared with the EC, erase is guaranteed to brick your laptop and write may brick your laptop. Read and probe may irritate your EC and cause fan failure, backlight failure and sudden poweroff. You have been warned. ======================================================================== The following protocols are supported: FWH, SPI. Probing for Macronix MX25L12850F, 16384 kB: compare_id: id1 0xc2, id2 0x2018 Added layout entry 00000000 - 00ffffff named complete flash Found Macronix flash chip "MX25L12850F" (16384 kB, SPI) mapped at physical address 0x00000000ff000000. Chip status register is 0x00. Chip status register: Status Register Write Disable (SRWD, SRP, ...) is not set Chip status register: Bit 6 is not set Chip status register: Block Protect 3 (BP3) is not set Chip status register: Block Protect 2 (BP2) is not set Chip status register: Block Protect 1 (BP1) is not set Chip status register: Block Protect 0 (BP0) is not set Chip status register: Write Enable Latch (WEL) is not set Chip status register: Write In Progress (WIP/BUSY) is not set This chip may contain one-time programmable memory. flashrom cannot read and may never be able to write it, hence it may not be able to completely clone the contents of this chip (see man page for details). Skipping writeprotect-based unlocking for read/verify operations. Reading ich descriptor... read_flash: region (00000000..0xffffff) is readable, reading range (00000000..0x000fff). done. Added layout entry 00000000 - 00000fff named fd Added layout entry 00800000 - 00ffffff named bios Added layout entry 00003000 - 007fffff named me Added layout entry 00001000 - 00002fff named gbe Using region: "bios". spi_read_register: read from register 5 not supported by programmer. wp_read_register: read from register 5 not is supported by programmer, writeprotect operations will assume it contains 0x00. spi_read_register: read from register 5 not supported by programmer. wp_read_register: read from register 5 not is supported by programmer, writeprotect operations will assume it contains 0x00. spi_read_register: read from register 5 not supported by programmer. wp_read_register: read from register 5 not is supported by programmer, writeprotect operations will assume it contains 0x00. spi_read_register: read from register 5 not supported by programmer. wp_read_register: read from register 5 not is supported by programmer, writeprotect operations will assume it contains 0x00. erase_write: region (00000000..0xffffff) is writable, erasing range (0x800000..0x800fff). Transaction error! SSFS: SCIP=0, FDONE=1, FCERR=1, AEL=0 SSFC: SCGO=0, ACS=1, SPOP=0, COP=1, DBC=0, SME=0, SCF=0 Running OPCODE 0x20 failed at address 0x800000 (payload length was 0). spi_write_cmd failed during command execution at address 0x800000 Erase/write done from 800000 to ffffff Erase Failedspi_read_register: read from register 5 not supported by programmer. wp_read_register: read from register 5 not is supported by programmer, writeprotect operations will assume it contains 0x00. spi_read_register: read from register 5 not supported by programmer. wp_read_register: read from register 5 not is supported by programmer, writeprotect operations will assume it contains 0x00. spi_read_register: read from register 5 not supported by programmer. wp_read_register: read from register 5 not is supported by programmer, writeprotect operations will assume it contains 0x00. Your flash chip is in an unknown state. Get help on IRC (see https://www.flashrom.org/Contact) or mail flashrom(a)flashrom.org with the subject "FAILED: <your board name>"!------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! Restoring MMIO space at 0x7fa5f44f48a0 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

error with chip flashing
by srojan s 21 Jun '24

21 Jun '24

❯ sudo flashrom -p ch341a_spi -f -n -w /Users/science/Downloads/coreboot_edk2-astronaut-mrchromebox_20240615.rom flashrom v1.3.0 on Darwin 23.5.0 (arm64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. libusb: info [darwin_detach_kernel_driver] no capture entitlements. may not be able to detach the kernel driver for this device libusb: info [darwin_claim_interface] no interface found; setting configuration: 1 Found Winbond flash chip "W25Q128.V" (16384 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. Thanks for your help! Reading old flash chip contents... done. Erasing and writing flash chip... FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00000fff: 0x1000 ERASE FAILED! Reading current flash chip contents... done. Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00007fff: 0x7f5f ERASE FAILED! Reading current flash chip contents... libusb: warning [darwin_transfer_status] transfer error: timed out cb_in: error: LIBUSB_TRANSFER_TIMED_OUT ch341a_spi_spi_send_command: Failed to read 4100 bytes libusb: warning [darwin_abort_transfers] aborting all transactions on interface 0 pipe 1 Can't read anymore! Aborting. 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!

1 0

Re: New chip: EN25Q128.
by Anastasia Klimchuk 08 Jun '24

08 Jun '24

Hello Rogier, I just checked, EN25Q128 is supported in the latest release 1.3, and from your logs you have 1.2 Is it possible for you to upgrade flashrom to the latest version? On Fri, Jun 7, 2024 at 11:36 PM Rogier Wolff <R.E.Wolff(a)bitwizard.nl> wrote: > > Hi, > > I have a bunch of EN25Q128 here. The CH341 programmer that I bought > recognizes it as 16Mbyte, but ... not "recognized". > > So attached is the output of -VV as requested. > > Let me know if I can be of any more help. Ah! I'll include the > datasheet. > > (My finger still hurts: I wanted to make sure it was correctly seated > in the clip that I have.... No BBQ sounds, but definitively hot. I > think I checked the orientation, but... Anyway. First chip redirected to > the bin, second chip gives the attached results!). > > Roger. > > -- > ** R.E.Wolff(a)BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** > ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** > f equals m times a. When your f is steady, and your m is going down > your a is going up. -- Chris Hadfield about flying up the space shuttle. > _______________________________________________ > flashrom mailing list -- flashrom(a)flashrom.org > To unsubscribe send an email to flashrom-leave(a)flashrom.org -- Anastasia.

2 1

Adding support for a new chip
by Jean-Baptiste Skutnik 07 Jun '24

07 Jun '24

Hello all, I broke my motherboard and flashrom would help me save 300$. I need to flash the BIOS chip and unfortunately, only the older version of the chip seems to be supported, so I would need to patch support in. The chip is the Winbond W25X40CL, which appears to be an upgrade over the W25X40 that flashrom supports. However, when hooking it up, the latter is detected and only the first 500K are available. I would need some guidance on what to do next. Looking through the gerrit I see the patches for new chip support add to flashchips.c and include/flashchips.h. Is there some documentation on what the fields represent in there so that I am not plugging randomly ? How does the process work when recognizing chips ? Would adding this chip create a conflict with its predecessor ? Thanks, JB

2 1

Issue with Flashrom: Failed Erase Operation
by Imed Hanchour 16 May '24

16 May '24

I am writing to report an issue I encountered while attempting to use Flashrom on my system. I am currently using Flashrom version 1.4.0-devel on a Raspberry Pi running Linux 5.15.61-v7+ (armv7l). When trying to perform an erase operation on a Macronix flash chip "MX25U3235E/F" (4096 kB, SPI) using the linux_spi interface, I encountered the following error: FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x003fffff: 0x3b5631 ERASE FAILED! Erase/write done from 0 to 3fffff Erase FailedYour flash chip is in an unknown state. I have attempted to troubleshoot the issue by ensuring proper connections and trying the operation multiple times without success. I have also verified that the flash chip is supported by Flashrom. Could you please provide guidance on how to resolve this issue or any additional troubleshooting steps I can take? I am eager to contribute to resolving this problem and willing to provide any further information or logs that may be needed. Thank you for your attention to this matter. I appreciate your support and assistance. Best regards Imed

1 1

RFC: removing 1 second verification delay
by Brian Norris 12 May '24

12 May '24

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

Re: Support for GD25LR512ME flash chip.
by Vlim 11 May '24

11 May '24

Thanks, Avinash, Can you advise which board are you using? I have tested this patch with the USB programmer only since I do not have access to the motherboard. Hi, Flashrom team, Can you also help on this? Regards, Victor Lim FAE Director GigaDevice Semiconductor 4088833856 vlim(a)gigadevice.com ________________________________ From: Munduru, Avinash <Avinash.Munduru(a)amd.com> Sent: Monday, May 6, 2024 16:24 To: Vlim <vlim(a)gigadevice.com>; flashrom(a)flashrom.org <flashrom(a)flashrom.org> Subject: Re: Support for GD25LR512ME flash chip. You don't often get email from avinash.munduru(a)amd.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information [AMD Official Use Only - General] Hi Victor, Thanks for sharing the patch. Here is an update after trying the shared patch. Now, Flashrom can detect the flash chip. Using dediprog programmer I can read/write the flash chip successfully. Whereas with using the internal programmer i.e. "-p internal" the read/write is failing. I am attaching the log here. Please give your input on this. Once again! Thanks for your help! [cid:106c2846-2fbe-4c90-a577-2a5266807244] ________________________________ From: Vlim <vlim(a)gigadevice.com> Sent: Sunday, May 5, 2024 1:54 PM To: flashrom(a)flashrom.org <flashrom(a)flashrom.org>; Munduru, Avinash <Avinash.Munduru(a)amd.com> Subject: Re: Support for GD25LR512ME flash chip. Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding. Hi, Avinash, Sorry that I am working on adding this part to Flashrom, but has not completed the entire process. Can you please use the attached flashchips.c and flashshchips.h and replace that in flashrom distribution? This is the process. git clone "https://review.coreboot.org/flashrom" meson setup builddir meson compile -C builddir meson test -C builddir meson install -C builddir Please also refer to the following link for compilation of the code. https://flashrom.org/dev_guide/building_from_source.html I have a compiled version for Ubuntu Linux, if that will help, I can share with you. Regards, Victor Lim GigaDevice Semiconductors Inc. 4088833856 vlim(a)gigadevice.com ________________________________ From: Munduru, Avinash via flashrom <flashrom(a)flashrom.org> Sent: Tuesday, April 30, 2024 16:54 To: flashrom(a)flashrom.org <flashrom(a)flashrom.org> Subject: [flashrom] Re: Support for GD25LR512ME flash chip. 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 This is an external email, beware of phishing emails. Please pay close attention to whether the email contains sensitive information [AMD Official Use Only - General] + attaching the output log [cid:3861d565-f2f4-472d-b4f0-cadd6bc4980e] ________________________________ From: Munduru, Avinash Sent: Tuesday, April 30, 2024 2:04 PM To: flashrom(a)flashrom.org <flashrom(a)flashrom.org> Subject: Support for GD25LR512ME flash chip. 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

Support for GD25LR512ME flash chip.
by Munduru, Avinash 06 May '24

06 May '24

[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

FAILED: Acer VN7-571G
by Zatrit 02 May '24

02 May '24

I have a full flash memory dump on my Raspberry Pi, which I use as a programmer, can I reboot my laptop in this case?

1 0

Flashrom -VV for xmc qh64ahig
by DigitalAndrew 30 Apr '24

30 Apr '24

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 24 Apr '24

24 Apr '24

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 22 Apr '24

22 Apr '24

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 21 Apr '24

21 Apr '24

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 18 Apr '24

18 Apr '24

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 15 Apr '24

15 Apr '24

:~# /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 12 Apr '24

12 Apr '24

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

Failed - HP Elite 3800 SFF Macronix MX25L12835E
by flrom1001 07 Apr '24

07 Apr '24

Hi Flashrom Team / Forum, I am using a System Rescue USB drive to run Flashrom The BIOS chip on the HP Elite 3800 is MXIC MX25L12835E Mi-10G. I photographed it to read the correct model.. When Flashrom probes the BIOS chip on HP Elite 3800 SFF it returns the following : [root@sysrescue /mnt/usb/ih]# flashrom -p internal flashrom v1.2 on Linux 6.6.14-1-lts (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). No DMI table found. Found chipset "Intel Q77". This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... The Flash Descriptor Override Strap-Pin is set. Restrictions implied by the Master Section of the flash descriptor are NOT in effect. Please note that Protected Range (PR) restrictions still apply. OK. Found Macronix flash chip "MX25L12805D" (16384 kB, SPI) mapped at physical address 0x00000000ff000000. Found Macronix flash chip "MX25L12835F/MX25L12845E/MX25L12865E" (16384 kB, SPI) mapped at physical address 0x00000000ff000000. Error accessing MT25QL02G, 0x10000000 bytes at 0x00000000f0000000 /dev/mem mmap failed: Resource temporarily unavailable Could not map flash chip MT25QL02G at 0x00000000f0000000. Error accessing MT25QU02G, 0x10000000 bytes at 0x00000000f0000000 /dev/mem mmap failed: Resource temporarily unavailable Could not map flash chip MT25QU02G at 0x00000000f0000000. Multiple flash chip definitions match the detected chip(s): "MX25L12805D", "MX25L12835F/MX25L12845E/MX25L12865E" Please specify which chip definition to use with the -c <chipname> option. [root@sysrescue /mnt/usb/ih]# flashrom -p internal -c MX25L12835E flashrom v1.2 on Linux 6.6.14-1-lts (x86_64)flashrom is free software, get the source code at https://flashrom.org The actual chip is MXIC MX25L12835E Mi-10G. I checked the MXIC comparison of these chips and they are very similar. The main difference with the 35E is the physical pinout is different. Do you know if programming using the chip models found by FlashRom would work. Any advise would be appreciated. Don

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom