- flashrom - mail.coreboot.org

CH341 and W25Q80DV
by Philip Zahariev 16 Dec '22

16 Dec '22

Hello, I try to program W25Q80DV, but have issues. Before programming I read contents of chip, but file is not look to me good. Unfortunately I not pay enough attention on this fact. After unsuccessful first programming read chip again and contents of file was changed. After that I carefully check connection and found that some connection was not good. Attach probe one more time and have success on erase operation, but not on write. Currently chip is full with “FF”, but every try for writhing give me error. Exact chip model is Winbond 25Q80DVSIG and chip is soldered on Gigabyte GC-Titan Ridge board. I’m using image-assembling-programmer.png for programming. Strange for me is result for command > flashrom -p ch341a_spi -c W25Q80.V flashrom v1.2 on Darwin 20.6.0 (x86_64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. But if I try command > flashrom -p ch341a_spi flashrom v1.2 on Darwin 20.6.0 (x86_64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q80.V" (1024 kB, SPI) on ch341a_spi. No operations were specified. Version of software was from today and compiled with "brew install flashrom” under MacOS Monterey 11.6.8 I’m waiting for your advice how to proceed further. Best regards Philip

1 0

Canceled event with note: Flashrom Dev Meeting @ Thu Dec 29, 2022 8am - 9am (AEDT) (flashrom@flashrom.org)
by aklm＠chromium.org 16 Dec '22

16 Dec '22

This event has been canceled with a note: "Meeting cancelled for 28 December 2022: holidays! :) Next meeting 11 January 2023 runs as usual." Flashrom Dev Meeting Thursday Dec 29, 2022 ⋅ 8am – 9am Eastern Australia Time - Sydney Join with Google Meet https://meet.google.com/iuf-mtri-zva?hs=224 Join by phone (AU) +61 2 9051 6791 PIN: 304642402 More phone numbers https://tel.meet/iuf-mtri-zva?pin=9271993818880&hs=0 Regular meeting of Flashrom project developers. Meeting notes doc: https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZ… Guests aklm(a)chromium.org - creator felix.singer12(a)gmail.com david.hendricks(a)gmail.com quasisec(a)google.com nico.h(a)gmx.de src(a)posteo.de martonmiklosqdev(a)gmail.com piotr.krol(a)3mdeb.com Maciej Pijanowski michal.zygowski(a)3mdeb.com th3fanbus(a)gmail.com stefan.k.reinauer(a)gmail.com nartemiev(a)google.com arthur(a)aheymans.xyz evanbenn(a)google.com gaumless(a)gmail.com flashrom(a)flashrom.org c-d.hailfinger.devel.2006(a)gmx.net ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 0

flashrom dev meeting notes 14.12.2022
by Anastasia Klimchuk 16 Dec '22

16 Dec '22

# 14th December, 21:00 - 22:00 UTC+0 Attendees: Anastasia, Angel ## Decision summary * REMINDER: next meeting 11 Jan. Happy holidays!! * Angel will help with point releases (tag + announcement on flashrom ML). ## Agenda * Main thing until the end of year: release 1.3 * High-level list of what’s new? * ~1000 commits over 3 years * Maybe look very quickly through them? * [Angel] For the future, make a list of significant changes, like coreboot’s. * Aklm is away from 17 Dec and back at the meeting 11 Jan. Will read all emails when back! * Angel will help with point releases (tag + announcement on flashrom ML). * REMINDER: next meeting 11 Jan. Happy holidays!! * [aklm] There are several patches “in-flight” which are fixing scan-build warnings. Can we help to either get them finished and merged, or abandon if that’s false positive warning? Otherwise we can have people duplicating each other's effort (already started happening). * [Angel] aklm probably refers to [https://review.coreboot.org/67700](https://review.coreboot.org/67700) and [https://review.coreboot.org/66225](https://review.coreboot.org/66225). * Update: This is resolved. -- Anastasia.

1 0

Why start over ( was Re: Starting over; how would you do it?)
by Nico Huber 13 Dec '22

13 Dec '22

Hi Richard, opening a new thread. Let's not derail the existing one before anything was discussed ;) On 19.11.22 21:18, Richard Hughes wrote: > On Sat, 19 Nov 2022 at 17:17, Nico Huber <nico.h(a)gmx.de> wrote: >> I've been thinking more and more about returning to a stable flashrom >> branch lately > > I'm missing the "why". To get back to work. To create something sustainable. As you and many others suggest, I also would like to have a branch that can be kept in a releasable state. First, we need a branch that is in a releasable state. You may have missed the decisions around the 1.3.x branch. The idea seems to be to clean things up on that release branch and for the time being do nothing about the open issues on the master branch. To me that's yet another sign that the current master branch is at a dead end. Nico

3 5

Contributing in GSOC 2023
by ABHISHEK TIWARI 10 Dec '22

10 Dec '22

Hello, I am a full-stack developer looking for organisations to contribute to this summer(GSOC 2023). If you allow me, I would love to contribute to this project's UI/UX part. I have experience I react.js and web development-related technologies, and I am an open-source contributor too, and a contributor of layer5.io and meshery.io. Waiting for your reply Thanks Abhishek Tiwari

1 0

gerrit settings
by Evan Benn 08 Dec '22

08 Dec '22

Hello, https://review.coreboot.org/admin/repos/flashrom,general https://gerrit-review.googlesource.com/Documentation/config-project-config.… I believe some small QOL improvements can be made in the flashrom settings: receive.requireSignedOffBy I think we can set this to true, I have been nagged by Ed enough times to remember to do this. 'Submit type' aka submit.action We use 'cherry pick'. This means each patch in a series says 'merge conflict' because it is being cherry picked without it's parent. It is tedious to submit a chain of patches (I hear) as each needs to wait for HEAD to sync and become the parent commit. The gerrit docs recommend NOT using cherry pick, and using 'rebase always' instead. Can we give it a try? https://gerrit-review.googlesource.com/Documentation/config-project-config.… "the rebase always action can be considered similar to the cherry pick action, but with the important distinction that rebase always does not ignore dependencies, which is why using the rebase always action should be preferred over the cherry pick submit action." Thanks Evan

1 0

unknown 25VG32 + ft2232h
by Arne Jansen 07 Dec '22

07 Dec '22

Hi, I encountered a flash chip that is not known to flashrom. I built flashrom from git, HEAD 153359935aa5. Write reported a fail, the other operations suceeded. Command line was: LD_LIBRARY_PATH=/home/arne/libftdi/build/src/libftdi.so.2 /home/arne/flashrom/flashrom -p ft2232_spi:type=2232H,port=A -w rv901_orig_rom.bin on arch linux (i needed build libftdi from source due to missing symbols in libusb). The datasheet for the chip is probably https://semic-boutique.com/wp-content/uploads/2016/05/ZB25VQ32.pdf Attached are the -VV logs for id, erase, write and read. Repeating write always fail in different places. -Arne

1 1

Project Proposal For GSOC 2023
by Yashashvi Mann 06 Dec '22

06 Dec '22

Respected Sir/Mam, My name is Yashashvi Mann and I am currently an undergraduate in Delhi technological University. I am a GSOC 2023 enthusiast. I have knowledge of HTML, CSS, Java script, Tailwind and React. I believe that I can contribute to the improvement of UI/UX of the flashrom website by specifically making the web site more user friendly and also ADC compliant by adding accesibility plugins as the current website framework majorly lacks it. I can provide more in depth information to it but not sure whom to contact for me to start? If you could guide me, I will be very grateful. Hope to hear from you soon. Regards.

1 0

GD25LQ128C/D error
by Tim Tech 02 Dec '22

02 Dec '22

Hello, I have flashed this chip in the past but suddenly I keep getting this error when writing/verification. I tried two separate flashrom versions, I'll post both error messages below: agimb@agimb-electro:~$ sudo ./flashrom -p ch341a_spi -w rom.rom flashrom v1.2-99-gfbb2b25f61 on Linux 5.15.0-53-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 GigaDevice flash chip "GD25LQ128C/GD25LQ128D" (16384 kB, SPI) on ch341a_spi. === This flash part has status UNTESTED for operations: PROBE READ ERASE WRITE 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... Erase/write done. Verifying flash... FAILED at 0x00002fc3! Expected=0x44, Found=0x04, failed byte count from 0x00000000-0x00ffffff: 0x83 Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! ----------------------------------------------------------------------------------------------------------------------- sudo ./flashrom -p ch341a_spi -w rom.rom flashrom v1.2-1028-gbd8a02de6c on Linux 5.15.0-53-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 GigaDevice flash chip "GD25LQ128C/GD25LQ128D/GD25LQ128E" (16384 kB, SPI) on ch341a_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x000168e3! Expected=0x57, Found=0x17, failed byte count from 0x00000000-0x00ffffff: 0x37 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! Thank you, Tim

2 1

flashrom dev meeting notes week 48/2022
by Felix Singer 01 Dec '22

01 Dec '22

# 30th November, 21:00 - 22:00 UTC+0 Attendees: Anastasia, Felix, Evan, Arthur ## Decision summary * Discussing the remaining issues from the 1.3 tracking ticket, all comments/updates are in the bugtracker * Meeting on 28th December will be canceled ## Agenda * [aklm] Lets go through bugs in the release list [https://ticket.coreboot.org/issues/353](https://ticket.coreboot.org/issues/… * We went through the bugs, end result: * 3 are on aklm * [https://ticket.coreboot.org/issues/354](https://ticket.coreboot.org/issues/… add a paragraph to README for RC1. * [https://ticket.coreboot.org/issues/356](https://ticket.coreboot.org/issues/… check with teammate(s) how is it going * [https://ticket.coreboot.org/issues/372](https://ticket.coreboot.org/issues/… finish two patches which are under review at the moment * 3 are on Felix * [https://ticket.coreboot.org/issues/374](https://ticket.coreboot.org/issues/… check with teammate, response needed * [https://ticket.coreboot.org/issues/375](https://ticket.coreboot.org/issues/… check with teammate, response needed * [https://ticket.coreboot.org/issues/408](https://ticket.coreboot.org/issues/… either do it quickly or re-link to 1.4 * We have some little number of patches to merge as of topic for_1.3.x and once it’s merged we can put a RC1 tag. After the tag is done, send an announcement on the mailing list. * Before 16 December (inclusive) aklm can send an announcement. If it happens later in December, Felix and Angel would need to do it. * Meeting on 28 Dec we cancel (holidays!!)

1 0

What company can add me the flash support?
by Herman Brule 30 Nov '22

30 Nov '22

Hi, What company can add me the flash support? I wish add 400USD bounty for: if you can add 25N01GVZEIG Winbond WSON 8x6-mm support Regards -- alpha_one_x86/BRULE Herman<alpha_one_x86(a)first-world.info> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server management IT, OS, technologies, research & development, security and business department

1 0

new: XMC QH64AHIG PPA77200 18 2033C
by Eric Starke 29 Nov '22

29 Nov '22

flashrom reported to me, that it found an unknown chip. In the schematics the chip name is: W25Q64JVSSIQ_SO8, but the marking on the chip states: XMC QH64AHIG PPA77200 18 2033C. Reading the chip worked so far. If you need more information, please e-mail me and I see what I can do. Thanks for maintaining this awesome software

1 0

"Intel P55" with PCI ID 8086:3b02 successful read / Apple iMac11,3 2010 firmware chip
by Wolf Dieter Brandt 29 Nov '22

29 Nov '22

flashrom v1.2 on Linux 5.10.0-8-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org flashrom was built with libpci 3.6.4, GCC 9.2.1 20200224, little endian Command line (7 args): flashrom --programmer internal -V -c MX25L3273E -r UEV.bin Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing internal programmer /sys/class/mtd/mtd0 does not exist No coreboot table found. Using Internal DMI decoder. No DMI table found. Found chipset "Intel P55" with PCI ID 8086:3b02. 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 = 0xc61: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: not enabled 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x0 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x1 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x2 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x3 0x7fffffff/0x7fffffff FWH IDSEL: 0x4 0x7fffffff/0x7fffffff FWH IDSEL: 0x5 0x7fffffff/0x7fffffff FWH IDSEL: 0x6 0x7fffffff/0x7fffffff FWH IDSEL: 0x7 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode enabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled 0x7fffffff/0x7fffffff FWH decode disabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching disabled, caching enabled, BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled SPIBAR = 0x00007f5fce36a000 + 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: 0x0000ffff (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write. 0x58: 0x03ff0021 FREG1: BIOS region (0x00021000-0x003fffff) is read-write. 0x5C: 0x00200001 FREG2: Management Engine region (0x00001000-0x00020fff) is read-write. 0x74: 0x82c10021 PR0: Warning: 0x00021000-0x002c1fff is read-only. 0x78: 0x9fff02e6 PR1: Warning: 0x002e6000-0x01ffffff is read-only. At least some flash regions are write protected. For write operations, you should use a flash layout and include only writable regions. See manpage for more details. 0x90: 0x04 (SSFS) SSFS: SCIP=0, FDONE=1, FCERR=0, AEL=0 0x91: 0xf97f20 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=2, DBC=63, SME=0, SCF=1 0x94: 0x5006 (PREOP) 0x96: 0x0c6c (OPTYPE) 0x98: 0x0103029f (OPMENU) 0x9c: 0x00002005 (OPMENU+4) 0xa0: 0x00000000 (BBAR) 0xc4: 0x00000000 (LVSCC) LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=0 0xc8: 0x00002011 (UVSCC) UVSCC: BES=0x1, WG=0, WSR=0, WEWS=1, EO=0x20 0xd0: 0x00000000 (FPB) OK. The following protocols are supported: SPI. Probing for Macronix MX25L3273E, 4096 kB: probe_spi_rdid_generic: id1 0xc2, id2 0x2016 Found Macronix flash chip "MX25L3273E" (4096 kB, SPI) mapped at physical address 0x00000000ffc00000. 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). Reading flash... done. Restoring MMIO space at 0x7f5fce36d8a0 Restoring PCI config space for 00:1f:0 reg 0xdc

1 0

Instructions for download, verify, and authenticate.
by 66Avanti＠outlook.com 29 Nov '22

29 Nov '22

To: flashrom(a)flashrom.org Hello, everyone! Here's a suggestion for a way to make flashrom easier to use: Please include simple and explicit instructions on how to verify and authenticate a download of flashrom. Linux Mint's installation instructions are an excellent example of clear instructions that non-technical users can follow easily. Linux Mint provides these steps: 1. Download the operating system (which is a ".iso" file), the sha256sum checksum (in a file named "sha256sum.txt"), and the Linux Mint digital signature/key (in a file named "sha256sum.txt.gpg"). All three files are available from the single download page. 2. Put the three files in the same folder in computer memory. 3. In a terminal screen, run "sha256sum *.iso". 4. Compare the result of the hash function in step 3 with the contents of the file named "sha256sum.txt". If they match, the iso has no errors. 5. Import the Linux Mint signing key by running this command in the terminal screen: "gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-key"27DE B156 44C6 B3CF 3BD7 D291 300F 846B A25B AE09". 6. In a terminal screen, run "gpg --verify sha256sum.txt.gpg sha256sum.txt". The results will say whether the source of the download is legitimate. The Linux Mint page is at: https://linux-mint-installation-guide.readthedocs.io/en/latest/verify.html The flashrom download page does not provide the sha256sum output. (I could not find it.) I ran "sha256sum flashrom" in a Linux terminal screen and used Google to search for the outcome and for more information. The Google search for the sha256sum (that I computed) returned seventeen hits. None of the hits was from an official flashrom.org man page. Most of them seem to be conversation between developers, not information for end-users. The "launchpad" webpage in the Google hits is from Ubuntu, but it has this note at the top: "flashrom (1.2-1) unstable; urgency=medium". That note suggests that the version of flashrom with the checksum "e1f8d..." is unstable and should not be used; at the least, it requires user care to install v. 1.2, not v. 1.2-1. The flashrom download page provides the "GPG signature" and a 40-digit hexadecimal number ("584A...") that seems to be related to the gpg signature, but neither one is in a readily usable form, and the correct instruction - with the correct syntax - to use them is not presented. (I read dozens of articles on "gpg" but did not find the necessary command to use. Like many people who need to use flashrom, I am not a computer code writer, so I need your help to get the command and syntax right.) Although I could download flashrom by using the Linux Mint Package Manager and then have reasonable confidence that the source of the file is legitimate, I would still need to confirm the sha256sum to be sure that the downloaded copy of the file is 100% correct. The final and reliable checksum should be posted on the manual's download page (along with instructions for signature verification) so that users won't need to search for the checksum and so that users can be certain that they have the right checksum and a reliable copy of flashrom. A defective operating system will cause problems, but it won't turn a computer into a brick. One mistake in the ROM could make the computer useless, so checking integrity and authenticity is a critical task. I sincerely appreciate all of the work that the flashrom team has put into a very worthwhile project, and I hope that these suggestions will make flashrom useful to many more people. - Joe

1 0

FAILED: Protectli vp4650
by Omkhar Arasaratnam 27 Nov '22

27 Nov '22

git cloned https://github.com/protectli-root/protectli-firmware-updater/tree/070b83f4d… Attempted to run on my Protectcli vp4650 - it failed ______ ______ ______ ______ ______ ______ ______ __ __ /\ == \ /\ == \ /\ __ \ /\__ _\ /\ ___\ /\ ___\ /\__ _\ /\ \ /\ \ \ \ _-/ \ \ __< \ \ \/\ \ \/_/\ \/ \ \ __\ \ \ \____ \/_/\ \/ \ \ \____ \ \ \ \ \_\ \ \_\ \_\ \ \_____\ \ \_\ \ \_____\ \ \_____\ \ \_\ \ \_____\ \ \_\ \/_/ \/_/ /_/ \/_____/ \/_/ \/_____/ \/_____/ \/_/ \/_____/ \/_/ _________________________________________________________________________________________ =========================================FlashLi========================================= --Version 1.1.28-- Device: Protectli vp4650 CPU: Intel(R) Core(TM) i5-10210U CPU @ 1.60GHz BIOS Mode: EFI Available BIOS: [1]: ami (vp4650_YW6L2516_221102.bin) Enter the [#] of an image file, or [0] to quit. Flashing will not begin yet > 1 ********************************************!******************************************** Are you sure you would like to flash this device? Flashing new firmware onto any hardware is potentially dangerous in that if the procedure is interrupted or otherwise not able to complete, your hardware may be rendered useless. Please proceed with caution. If there are any questions, please contact Protectli support BEFORE proceeding. Unless there is a compelling reason to update the BIOS, we recommend to stay with your current known working BIOS version ********************************************!******************************************** Acknowledgement Yes [Y]: Y flashrom v1.2-326-gf57486e on Linux 6.0.0-4-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). Found chipset "Intel Comet Lake U Premium". Enabling flash write... Warning: BIOS region SMM protection is enabled! Warning: Setting BIOS Control at 0xdc from 0xaa to 0x89 failed. New value is 0xaa. SPI Configuration is locked down. Enabling hardware sequencing because some important opcode is locked. PROBLEMS, continuing anyway Found Programmer flash chip "Opaque flash chip" (16384 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Reading old flash chip contents... done. Erasing and writing flash chip... Transaction error between offset 0x00600000 and 0x00600fff (= 0x00600000 + 4095)! Reading current flash chip contents... done. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. Looking for another erase function. No usable erase functions left. 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. Get help on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org with the subject "FAILED: <your board name>"! ------------------------------------------------------------------------------- DO NOT REBOOT OR POWEROFF! BIOS Flash failed, is this script running with root permissions? Please try again, but if problems persist, please contact Protectli. TODO: Collect info and display instructions on how to submit a Github issue. --oa

2 2

flashrom dev meeting notes week 45/2022
by Anastasia Klimchuk 27 Nov '22

27 Nov '22

(apologies this one is sent out of chronological order, it was completely missed. but... better late than never) # 2th November, 21:00 - 22:00 UTC+0 Attendees: Felix, Angel, Edward, Anastasia, Stefan ## Decision summary * Angel: See the ALL CAPS text at the start of the page. Thanks to aklm for the idea. We do not talk about others if they’re not present on the call. Mentioning people who did something, for context, is fine. * We created the release branch today and will be doing all the fixes/reverts into the release branch. Meanwhile development continues on master. * Initially we wanted to create a release branch with the name “1.3.x” but then we discovered a branch with this name already exists (created an unknown number of months ago, and in an unknown state). Therefore, Angel created branch with name “1.3.x_infdev” and the plan is to rename the current 1.3.x to 1.3.x_old (to keep whatever is in there) and then rename 1.3.x_infdev to 1.3.x. * Angel made [https://review.coreboot.org/68823](https://review.coreboot.org/68823) to deal with the sb600spi problems (“Promontory” support is broken), at least for the v1.3 release. A long-term plan is to fix the code. ## Agenda * When can we make a release branch? * Aklm: can we make a plan? * Branch master ? * [Angel] We need this for the release: [https://review.coreboot.org/68823](https://review.coreboot.org/68823) * Angel decided to create the `1.3.x_infdev` branch ([“infdev” is a reference to a Minecraft version](https://minecraft.fandom.com/wiki/Java_Edition_Infdev)) to be used as flashrom v1.3 release candidate. The already-present `1.3.x` branch is left untouched as we don’t know for sure whose it is. When the v1.3 release is done, Angel suggests keeping the `1.3.x_infdev` branch as a memento of the struggle. * Felix will figure out the status of the 1.3.x branch and what’s about it. -- Anastasia.

2 1

Starting over; how would you do it?
by Nico Huber 22 Nov '22

22 Nov '22

Hi flashrom folks, I've been thinking more and more about returning to a stable flashrom branch lately; starting over from v1.2 seems reasonable. The question is, how to proceed on such a branch? There are, of course, many cherries on the current master branch. But in what order should they be picked? And should they be picked first? What about even older patches? There are still many patches on patch- work [1] and also on Gerrit. Some of them probably also cherries. When I was still more of an official maintainer for flashrom, I tried to keep track of these things. And lately, a look at the wiki history told me that maintainers before me cared too [2]. But I guess nothing happened in that direction in the past 3 years. Depending on the progress with the 1.3 release, I'd suggest to either try to merge things in historical order, or start with the easy cher- ries on the current master branch (new chips and programmers that are ready; for a small release and then focus on a short release cycle). WDYT? Cheers, Nico [1] https://patchwork.coreboot.org/project/flashrom/list/ [2] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=2252#…

4 7

flashrom dev meeting notes week 46/2022
by Felix Singer 21 Nov '22

21 Nov '22

# 16th November, 21:00 - 22:00 UTC+0 Attendees: Anastasia, Felix ## Decision summary * Everything is in the bugtracker: some tickets have been unlinked from release, some others are waiting for clarification. We added comments to all tickets that we went through. ## Agenda * [aklm] Lets go through bugs in the release list [https://ticket.coreboot.org/issues/353](https://ticket.coreboot.org/issues/… * We went through the list and stopped at 372

1 0

[PATCH] Add support for XMC XM25QH128A. Read/write tested.
by Stijn Segers 21 Nov '22

21 Nov '22

Signed-off-by: Stijn Segers <foss(a)volatilesystems.org> --- flashchips.c | 49 ++++++++++++++++++++++++++++++++++++++++++++ include/flashchips.h | 1 + 2 files changed, 50 insertions(+) diff --git a/flashchips.c b/flashchips.c index 47a37ee..e3fd368 100644 --- a/flashchips.c +++ b/flashchips.c @@ -19707,6 +19707,55 @@ const struct flashchip flashchips[] = { .voltage = {1650, 1950}, }, + { + .vendor = "XMC", + .name = "XM25QH128A", + .bustype = BUS_SPI, + .manufacture_id = ST_ID, + .model_id = XMC_XM25QH128A, + .total_size = 16384, + .page_size = 256, + .feature_bits = FEATURE_WRSR_WREN | FEATURE_OTP | FEATURE_QPI | FEATURE_WRSR2, + .tested = TEST_OK_PREW, + .probe = probe_spi_rdid, + .probe_timing = TIMING_ZERO, + .block_erasers = + { + { + .eraseblocks = { {4 * 1024, 4096} }, + .block_erase = spi_block_erase_20, + }, { + .eraseblocks = { {32 * 1024, 512} }, + .block_erase = spi_block_erase_52, + }, { + .eraseblocks = { {64 * 1024, 256} }, + .block_erase = spi_block_erase_d8, + }, { + .eraseblocks = { {16 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_60, + }, { + .eraseblocks = { {16 * 1024 * 1024, 1} }, + .block_erase = spi_block_erase_c7, + } + }, + .printlock = spi_prettyprint_status_register_plain, + .unlock = spi_disable_blockprotect, + .write = spi_chip_write_256, + .read = spi_chip_read, + .voltage = {2700, 3600}, + .reg_bits = + { + .srp = {STATUS1, 7, RW}, + .srl = {STATUS2, 0, RW}, + .bp = {{STATUS1, 2, RW}, {STATUS1, 3, RW}, {STATUS1, 4, RW}}, + .tb = {STATUS1, 5, RW}, + .sec = {STATUS1, 6, RW}, + .cmp = {STATUS2, 6, RW}, + }, + .decode_range = decode_range_spi25, + }, + + { .vendor = "XMC", .name = "XM25QH128C", diff --git a/include/flashchips.h b/include/flashchips.h index 5df42dc..8317da7 100644 --- a/include/flashchips.h +++ b/include/flashchips.h @@ -818,6 +818,7 @@ #define ST_M45PE16 0x4015 #define XMC_XM25QH64C 0x4017 #define XMC_XM25QU64C 0x4117 +#define XMC_XM25QH128A 0x7018 #define XMC_XM25QH128C 0x4018 #define XMC_XM25QU128C 0x4118 #define XMC_XM25QH256C 0x4019 -- 2.36.1

3 8

Status of Meson support, where are we? (was Re: Build systems and `uinstall` option)
by Nico Huber 14 Nov '22

14 Nov '22

Hi all, it feels like this deserves its own thread. I was a little surprised by the news that we are already ready to deprecate Make. Hopefully, I'm just not up to date and this is the case! If I'm horribly off track, please ignore the following. IIRC, we said this would be the case if we can do everything with Meson what we can do with Make (due to lack of knowing what the latter can, we made a list of target environments that we need to support at least) and Meson produces the same binaries as Make. Are we there yet? My last state wrt. the more special target environments like lib- payload was that it seems feasible, but I haven't seen a PoC yet. On 10.11.22 17:43, Felix Singer wrote: > The Make build system is going to be deprecated with the next release > and it is going to be dropped with the release after that. "next release" being the one that just started or the next after that? iow. does this mean deprecate with flashrom 1.3 and drop in 1.4? > We discussed the Make build system in many meetings now and we all > agreed that we won't add any more features to it. That means its > current feature state is frozen and it doesn't get any additional > functionality, just bug fixes, refactorings or adjustments as far as > they are really necessary. Was this ever discussed on / announced to the ML? My status was that this was of the "nobody objected during some meeting" decision kind. Nico

5 7

Build systems and `uinstall` option
by Joursoir 14 Nov '22

14 Nov '22

Hello everyone, I wonder why there is no 'uninstall' option in the flashrom's Makefile? Is it just an oversight? Or do we have a reason for that? The same question is related to the meson script. -- Joursoir

5 12

Future development and release process
by Nico Huber 11 Nov '22

11 Nov '22

Hi flashrom fellows, some of us have picked a new release process for flashrom 1.3 that ignores the problems of the master branch but will attend to them on a separate branch. This leaves us without a strategy to get future releases done with less hassle. It also feels quite frustrating be- cause I fear it takes incentive away to fix the master branch. And hence increases the incentive for myself to abandon said branch. During a phone call with Felix, I explained the options I see roughly as follows. There are probably more options, feel free to discuss others as well. These just came to my head. 1. Full reset: Branch off 1.2.x before the master branch started to make trouble. Also reset the Gerrit privileges to a state where only people got merge rights after they earned trust by the pre- existing maintainers (people with those rights); to prevent that history repeats itself. So far this seemed to be unacceptable by the Google team. The rest of this email will assume that we won't be doing this. If it turns out I'm wrong, this would be my preferred solution and we won't have to discuss anything below. 2. Try harder: Keep working on the current master branch. Try to fix the process as we go along. This is unacceptable to me. We have tried this already and I have not seen things getting better. Building up on a broken state is most often harder than rewinding to a good state and starting new things from scratch. Working on this branch has not been fun since flashrom 1.2. Beside that, the master branch hasn't provided any- thing that I could use in my day job for years (not as a develop- ment tool and definitely not in our products). 3. Compromise: The current situation evolved due to a highly dynamic development process that is roughly the opposite of what we had before we tried to converge upstream and chromium development. Also, adding many new developers that are used to a very different process requires a lot of communication (IMO) which didn't happen. We could accept these different development strategies and work on two branches. Not(!) competing branches but branches that complement each other. Something like this was actually proposed before [1]. The rough idea: we could have a 'stable' branch and a more dynamic one. Back then we called the latter 'staging'. Merging commits to the 'stable' branch would be limited to maintainers who know flash- rom well enough and trust each other. To be honest, I wouldn't care much what happens on the 'staging' branch, who gets to merge etc. There were often reservations if this could work without diverging the branches. But there are strategies to avoid it. For instance, a regular `git merge` onto the 'staging' branch could avoid that. To give it a good start, I would also suggest to base a 'stable' branch on 1.2.x. 4. Divide: If we don't find a compromise, I'll have to continue my work on a new branch. I wouldn't care then if things diverge. Details depend mostly on who would like to join the effort. It would likely start on 1.2.x with things added from the current master branch (might get things through review again, or also cherry pick real cherries directly without going through Gerrit). Quite unappealing because it would push contributors to choose a branch. And we would have to discuss how to deal with future releases. You may notice that most of my ideas suggest rewinding to 1.2.x. Beside easing further development on a reasonable code base, there is one more thing driving me: The master branch contains many commits that caused awkward feelings. I think it would help working together if we wouldn't be reminded of them all the time. Nico [1] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=2252#…

1 0

Documenting flashrom's guts
by Angel Pons 08 Nov '22

08 Nov '22

Hi list, There's several things regarding flashrom's structure that seem to be underdocumented (or *are* documented, but the information is extremely hard to find). It would be very helpful to have this information available somewhere easy to find, such as the Wiki. Some things that would greatly benefit from being documented are: - flashrom's layers: which layers there are, and how they interact with each other. - flashrom's structures: which structures there are, how they interact with each other, and how they "map" to layers. Surely there are more things that would benefit from being documented. Let's not discuss *who* is going to do what for now; first, let's collect information about these parts of flashrom. Best regards, Angel

3 2

Branch 1.3.x is being prepared for release candidate
by Anastasia Klimchuk 07 Nov '22

07 Nov '22

Good Day Flashrom community, We’ve got good news about the upcoming release v1.3. Branch 1.3.x is officially opened and being prepared for release candidate. The branch has been fast-forwarded to head as of Friday last week. We are now going through the list of what is critical to do for the release and patching 1.3.x accordingly. You can see the patches for 1.3.x by this link: https://review.coreboot.org/q/project:flashrom+branch:1.3.x The next step will be to put an RC1 tag for the branch (when ready for that) and write another announcement. If you know of any bugs, please report to us, and thank you! In any case, bugs will be reported in the bugtracker. And then we can decide what’s the urgency and whether the bug is blocking the release or not. Meanwhile, development continues on master branch. Specifically, there are few ongoing projects in various stages of development: all of that continues. And hopefully, could be included in the next release. Thanks everyone! -- Anastasia.

1 0

Re: [review] WP documentation for flashrom users
by Anastasia Klimchuk 04 Nov '22

04 Nov '22

I only noticed now that the mailing list got lost from the last two messages. I apologise for that, it was completely unintentional! Re-sending again, and now including the mailing list. Text below. On Wed, Nov 2, 2022 at 12:17 AM Sergii Dmytruk <sergii.dmytruk(a)3mdeb.com> wrote: > > On Tue, Nov 01, 2022 at 09:32:27AM +1100, Anastasia Klimchuk wrote: > > Sergii, you mentioned in the earlier thread, you can convert the text > > to mediawiki format? That would be great! > > Also, would you be able to update the wiki page by yourself? We can > > create an account for you. > > Then you can preview/correct the text , until the result looks good to you. > > > > As we agreed in the earlier thread, this should go to > > https://www.flashrom.org/Documentation#Using_flashrom section. > > > > Thank you so much for your contributions! > > Yes, I can deal with MediaWiki and handle formatting issues myself if > I'll get an account. > > Just for information, it's trivial to convert to Wiki automatically: > > pandoc -w mediawiki bootblock-protection.md -o bootblock-protection.wiki > > The important thing is to have empty lines before lists in Markdown, > pandoc doesn't recognize lists otherwise. There can be other minor > differences. -- Anastasia.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom