June 2024 - flashrom - mail.coreboot.org

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

Aug. 10, 2025

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

2 2

Re: Support for GD25LR512ME flash chip.
by Anastasia Klimchuk Nov. 1, 2024

Nov. 1, 2024

Victor, Thank you so much for the datasheets! I did a review of the pending patch, and now it will be possible to finally finish the patch from 2021 and get the chips submitted. Also thank you for attaching the log. Not sure if the log is complete? It ends at the start of the reading operation, but there is no final message of SUCCESS or FAIL. However, importantly, I could see in the beginning of the log which platform was detected, and it is Promontory. Which means... Avinash, Most likely you are hitting a known issue, you can read more details here: https://ticket.coreboot.org/issues/370 The issue is for Promontory, and also for chips larger than 16Mbyte: which is exactly what you have. I was actually trying to get help from AMD with this issue, so it's really good to have you here on the mailing list! Maybe you can help? Someone from AMD would be in the best position to fix Promontory, you have all the datasheets available, and all the hardware. Thank you! On Sat, May 11, 2024 at 9:40 PM Vlim <vlim(a)gigadevice.com> wrote: > > Hi, Anastasia, > > Please find the attached datasheet for GD25LR256E and GD25LR512ME. > > There are actually two issues. > > the released flashrom does not support GD25LR256E and GD25LR512ME. > With my patch, the dediprog programmer works for GD25LR512ME. But the AMD internal programmer for Birman Plus Board does not work. Output file attached. > > > This is the comment about Birman Plus Board > > 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. > > > Regards, > > Victor > > > ________________________________ > From: Anastasia Klimchuk <aklm(a)chromium.org> > Sent: Saturday, May 11, 2024 17:59 > To: Vlim <vlim(a)gigadevice.com>; Munduru, Avinash <avinash.munduru(a)amd.com> > Cc: flashrom(a)flashrom.org <flashrom(a)flashrom.org> > Subject: Re: [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 > > There is another thing, in addition to my previous message. > > I looked into the patch which adds chip definitions (this one > https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.co…) and the reason it is > pending is there are no links to datasheets (old links are not working > anymore). > It is unfortunate that the patch is pending since 2021, but I want to > try to fix the situation now, in the year 2024. > > Victor, maybe you know, is it possible to find datasheets for > GD25LR256E and GD251R512ME? I could finish the old patch and get chips > into the tree. > > This is a separate question to Avinash's issue with internal > programmer, but for this we need the very verbose log (which is log > with -VVV option on command line). > > Thank you! > > On Thu, May 9, 2024 at 11:03 PM Anastasia Klimchuk <aklm(a)chromium.org> wrote: > > > > Avinash, I read the thread and I see you are saying "I am attaching > > the log here" but I don't see the log? maybe you can re-send it again, > > now with the mailing list? (perhaps you sent it to Victor only?) > > Yes it is also important to know your board, since you are saying the > > chip worked successfully with dediprog, but not with the internal > > programmer. > > > > Victor, thank you so much for helping! > > > > > > On Mon, May 6, 2024 at 6:42 PM Vlim <vlim(a)gigadevice.com> wrote: > > > > > > 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 > > > 此为外部邮件，谨防钓鱼邮件，请注意邮件是否涉及敏感信息 > > > 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! > > > > > > > > > ________________________________ > > > 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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.co…" > > > > > > 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://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflashrom.… > > > > > > 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 > > > > > > ________________________________ > > > 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. > > > > > > _______________________________________________ > > > flashrom mailing list -- flashrom(a)flashrom.org > > > To unsubscribe send an email to flashrom-leave(a)flashrom.org > > > > > > > > -- > > Anastasia. > > > > -- > Anastasia. -- Anastasia.

3 11

release v1.4.0 plan and timeline
by Anastasia Klimchuk July 11, 2024

July 11, 2024

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

flashrom dev meeting notes 27.06.2024
by Anastasia Klimchuk July 2, 2024

July 2, 2024

# 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 June 25, 2024

June 25, 2024

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 June 25, 2024

June 25, 2024

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 June 21, 2024

June 21, 2024

❯ 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 June 8, 2024

June 8, 2024

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 2

Adding support for a new chip
by Jean-Baptiste Skutnik June 7, 2024

June 7, 2024

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