flashrom March 2022

flashrom@flashrom.org

32 participants
30 discussions

Help !
by Guillaume Rallon 11 Mar '22

11 Mar '22

Hello, I request your help for a little problem. I try to unbrick my MSI Gaming 5 Z97 motherboard, using flashrom using a raspberry Pi 4b vi the JSPI1 port. I plugged it like this : Hold 0V o o WP 3.3V x o o o GND CLK o o CS SI-SO o o SO-SI o o VCC The plugin seems to be good as Flashrom detects the chipset as a Winbond W25Q64.V The battery of the mother board is removed, no other external current source plugged. When I launch the writing sequence everything goes flawlessly and the problem appears during the flash verification. I receive this message : Verifying flash... FAILED at 0x00000014! Expected=0x03, Found=0x02, failed byte count from 0x00000000-0x007fffff: 0x3d6c96 Your flash chip is in an unknown state. I tried to put HOLD at 3.3V and let the CMOS battery but it is always the same message. Maybe my chipset has an internal defect ? If yes, I think I can buy a new chip and solder it but it's a brutal solution ;) I would really be pleased if you could give me at least a clue. Best regards Guillaume RALLON The whole messages are below : flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=512 -w /home/Yogiadmin/flashrom/E7917IMS.190 flashrom v1.2-644-g79e2bd0 on Linux 5.10.92-v8+ (aarch64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on linux_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x00000014! Expected=0x03, Found=0x02, failed byte count from 0x00000000-0x007fffff: 0x3d6c96 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! -- RALLON Guillaume 19 CHEMIN DE LA RETARDIERE 44700 ORVAULT FRANCE 06 79 69 15 60

2 1

Experimental GD25Q40(B) support
by Wolf Dieter Brandt 09 Mar '22

09 Mar '22

2 1

EN25F10 read/write support log files
by Wolf Dieter Brandt 09 Mar '22

09 Mar '22

Here you go! Thanks fro this great tool!

2 1

Erase Failed - MX25L12805D, MX25L12835F/...
by dean rooney 09 Mar '22

09 Mar '22

Hello, I am trying to fix a bricked motherboard (Z170A Mpower Gaming Titanium). The motherboard does have a MX25L12873F (not seen on your supported list) but does have the MX25L12805D and MX25L12835F/MX25L12845E/MX25L12865E as similar chips. I am using flashrom on a Raspberry Pi 3 and had gotten quite far using the forums until I came across "ERASE FAILED". I am able to read the chip, but I am unable to write as it has this Erase Failed appears every time. I'm not sure if there is a work around. I've seen the -f force erase but I'm not aware how to use this function. Any help would be greatly appreciated. Kind Regards, Dean

2 1

Questions About Flashrom Of Gsoc
by Hui Xiang 09 Mar '22

09 Mar '22

Dear Sir/Madam, I hope you are well today when you receive this email. My name is Hui Xiang, and I am a University of Manchester Electrical and Electronic Engineering student. This summer, I would like to join Google Summer of Code. The Flashrom Project caught my eyes after I went through all the projects of GSoC. In my school project, I am now working on the NUCLEO-F401RE(STM32). I can programme in C and C++, as well as assembly language. From the file of GSoC project ideas, I really like the idea of "Design and implement new CLI based on libflashrom and enhance the API as needed". For the Flashrom project, I would like to make contributions on some API. What resources can I use to learn more about it? What skills do I need to improve to get accepted from Flashrom? Thank you for looking into this for me. Best Regards, Hui

2 1

MT25QU256 Tested/Passed with Olimex ARM-USB-OCD-H
by Shawn Rainey 08 Mar '22

08 Mar '22

Seems to work well with an in-house prototype board + the olimex jtag probe and some hacked in wiring. Log file of a write is attached.

1 0

[MT25QU256] Tested probe, read, write and erase through ft2232_spi programmer
by Charles Parent 08 Mar '22

08 Mar '22

Hello, First thank you a lot for your amazing work on flashrom, I just discovered this software and it saved me a lot of time lately ! I use it to flash a MT25QU256 through a FTDI4233H, and as software is telling me that this chip is labelled as untested I would like to send you the logs showing that it works indeed. Here are logs for both reading and writing / erasing. I also did varius tests, filling the EEPROM with arbitrary values and reading back to see everything was working. Please do not hesitate if you need more details ! Best regards, Charles Parent Software Engineer charles.parent(a)orolia2s.com<mailto:jean-arnold.chenilleau@orolia.com> [cid:755255d5-41f3-4c56-848c-a82a0d12ea1a] France, Sèvres 6, rue Troyon 92310 Sèvres

2 1

Flashrom has been accepted for GSoC 2022
by Anastasia Klimchuk 08 Mar '22

08 Mar '22

Hello Everyone, Breaking news! Flashrom has been accepted as a Mentoring Organization for GSoC 2022! This is amazing news, because for the first time in history, Flashrom is participating in GSoC as independent organisation, has its own Org Admins and an entry in the list of accepted organisations: https://summerofcode.withgoogle.com/programs/2022/organizations Here is Flashrom page: https://summerofcode.withgoogle.com/programs/2022/organizations/flashrom (in case you are wondering, I also have no idea why all the newlines have been removed from the long description :)) What’s going to happen next? Timeline is here https://developers.google.com/open-source/gsoc/timeline Please share the news with everyone, especially with people who may be interested to participate in GSoC as contributors. There are three resources that you can share (each of them or all of them): #1 Flashrom page on GSoC site: https://summerofcode.withgoogle.com/programs/2022/organizations/flashrom #2 Flashrom Contributor guidelines: https://www.flashrom.org/GSoC #3 Our Project Ideas list: https://docs.google.com/document/d/1AxMobB2v8Dv2uUwZPZ_vCmmONYDJuliHcnjfWOs… If you saw my earlier thread on the mailing list “Call for Mentors”, it is not too late to respond! There are many ways you can help (not only by being a mentor), and every help counts, no matter big or small. And it’s never too late if you want to help with something :) Respond to this thread, or respond to “Call for Mentors”, or contact me/aklm, Felix/flx or Angel/hell directly. Finally, I wanted to say thank you to everyone who helped and supported this effort! Your Org Admins, Anastasia, Felix, Angel.

1 0

[RFC] Flashrom Development Guidelines - Patch submission
by Anastasia Klimchuk 07 Mar '22

07 Mar '22

Hello Flashrom community, Recently, we (Anastasia and Felix, your Org Admins) were looking into the Flashrom Dev Guidelines page https://www.flashrom.org/Development_Guidelines#Patch_submission with the main goal to prepare the page for GSoC. Very soon (7th March) the results are announced, and in case Flashrom is accepted, we will suddenly have lots of people (potential contributors) looking into our Dev Guidelines! :) We have a suggestion on how to improve the guidelines. Specifically, this is about the “Patch Submission” section (not the whole guidelines). There are few most important points to address: 1. Update the links, so that they don’t point to instructions from the old coreboot wiki (which explains how to clone coreboot repo). 2. State very clearly that we have a strong preference for Gerrit code reviews (not mailing list reviews). 3. Explain that we don’t look at pull requests on GitHub. The updated version of the “Patch Submission” section that we are suggesting is below. Comments/feedback is welcome, the wording can be changed/improved, as long as the three main points are addressed. Unchanged sections are marked as such. Thank you so much! ----------------------------------------------------------------- *Patch Submission* Coding style (unchanged) Flashrom generally follows Linux kernel style <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Doc…> . The notable exception is the line length limit. Our guidelines are: - 80-columns soft limit for most code and comments. This is to encourage simple design and concise naming. - 112-columns hard limit. Use this to reduce line breaks in cases where they harm grep-ability or overall readability, such as print statements and function signatures. Don't abuse this for long variable/function names or deep nesting. - Tables are the only exception to the hard limit and may be as long as needed for practical purposes. GitHub The official Flashrom mirror on GitHub is: https://github.com/flashrom/flashrom Importantly, GitHub repo is only a mirror, so all changes must go through Gerrit on review.coreboot.org in order to be merged, even small patches such as adding support for a flash chip. For this reason, reviewers do not look at pull requests. Even if pull requests were automatically transferred to Gerrit, requirements such as the #Sign-off Procedure <https://www.flashrom.org/Development_Guidelines#Sign-off_Procedure> still present a problem. The quickest and best way to get your patch reviewed and merged is by sending it to review.coreboot.org. Conveniently, you can use your GitHub, GitLab or Google account as an OAuth2 login method. Please continue reading, the instructions are below. Preparing a patch Before sending a patch for review, put your Signed-off-by line <https://www.flashrom.org/Development_Guidelines#Sign-off_Procedure> in the commit message. Currently there are two ways to send patches for review: 1. Our strong preference, especially for large patches, is via Gerrit on review.coreboot.org <https://review.coreboot.org/#/q/project:flashrom>, i.e. git push origin HEAD:refs/for/master 2. For small patches, with the reviewer’s agreement, there is an option to send via our mailing list <https://www.flashrom.org/Contact#Mailing_List>. When sending a patch via the mailing list, send it in-line instead of as an attachment so that reviewers can easily comment on specific parts of it. However, eventually the reviewer will need to push patch to gerrit anyway. Our guidelines borrow heavily from the coreboot development guidelines <https://doc.coreboot.org/contributing/index.html>, and most of them apply to flashrom as well. The really important part is about the #Sign-off Procedure <https://www.flashrom.org/Development_Guidelines#Sign-off_Procedure>. We try to reuse as much code as possible and create new files only if absolutely needed, so if you find a function somewhere in the tree which already does what you want (even if it is for a totally different chip), please use it. See also Command set secrets <https://www.flashrom.org/Random_notes#Command_set_secrets>. The patch reviews may sound harsh, but please don't get discouraged. We try to merge simple patches after one or two iterations and complicated ones as soon as possible, but we have quite high standards regarding code quality. If you introduce new features (not flash chips, but stuff like partial programming, support for new external programmers, voltage handling, etc) please discuss your plans on the mailing list <https://www.flashrom.org/Contact#Mailing_List> first. That way, we can avoid duplicated work and know about how flashrom internals need to be adjusted and you avoid frustration if there is some disagreement about the design. For patches that modify convoluted tables like struct flashchip flashchips[] in flashchips.c it may make sense to increase the lines of context to include enough information directly in the patch for reviewers (for example to include the chip names when changing other parameters like .voltage). To do this with git use git format-patch -U5 where 5 is an example for the number of lines of context you want. Commit message (unchanged) Commit messages shall have the following format: <component>: Short description (up to 72 characters) This is a long description. Max width of each line in the description is 72 characters. It is separated from the summary by a blank line. You may skip the long description if the short description is sufficient, for example "flashchips: Add FOO25Q128" to add FOO25Q128 chip support. You may have multiple paragraphs in the long description, but please do not write a novel here. For non-trivial changes you must explain what your patch does, why, and how it was tested. TEST=tests that you performed Finally, follow the #Sign-off Procedure <https://www.flashrom.org/Development_Guidelines#Sign-off_Procedure> to add your sign-off! Signed-off-by: Your Name <your@domain> Sign-off Procedure (unchanged) We employ a similar sign-off procedure as the Linux kernel developers <http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_…> do. Add a note such as Signed-off-by: Random J Developer <random(a)developer.example.org> to your email/patch if you agree with the Developer's Certificate of Origin 1.1 printed below. Read this post on the LKML <https://lkml.org/lkml/2004/5/23/10> for rationale (spoiler: SCO). You must use your real name in the Signed-off-by line and in any copyright notices you add. Patches without an associated real name lack provenance and cannot be committed! Developer's Certificate of Origin 1.1: By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it; and (d) In the case of each of (a), (b), or (c), I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license indicated in the file. Note: The Developer's Certificate of Origin 1.1 <http://web.archive.org/web/20070306195036/http://osdlab.org/newsroom/press_…> is licensed under the terms of the Creative Commons Attribution-ShareAlike 2.5 License <http://creativecommons.org/licenses/by-sa/2.5/>. Submitting a patch using GerritSetting up a Gerrit accountAll changes have to go through Gerrit on review.coreboot.org in order to be merged, even small patches such as adding support for a flash chip. Our Gerrit supports multiple authentication methods <https://review.coreboot.org/login> including OAUTH2, e.g. Google, GitHub or GitLab, or also OpenID. 1. Go to https://review.coreboot.org/login and sign in. 2. Edit your settings by clicking on the gear icon in the upper right corner. 3. Set your Gerrit username. 4. Add an email address so that you receive notifications when others commented or reviewed your patch. 5. Add a SSH public key to your account, or click the button to generate an HTTPS password. Preparing your local repository Open https://review.coreboot.org/admin/repos/flashrom and choose your desired method to clone the repository. Supported methods are HTTPS and SSH. The same method will also be used when you push your changes to Gerrit later. Also, make sure to install the Change-Id hook. This generates a unique ID which is appended to your commit message. It is used by Gerrit to identify if a patch with the same ID exists, and if so it will add a new version to it called “patchset”. If you are just about getting a fresh copy of the flashrom repository, then you can use the command which you can find under “Clone with commit-msg hook”. If you have an existing copy of the repository and you need to install the hook afterwards, then you can run this command within your flashrom directory - mkdir -p .git/hooks && curl -Lo `git rev-parse --git-dir`/hooks/commit-msg https://review.coreboot.org/tools/hooks/commit-msg; chmod +x `git rev-parse --git-dir`/hooks/commit-msg) Pushing your patch to Gerrit 1. Check out a new local branch that tracks origin/master: git checkout -b <branch_name> origin/master 2. Do your changes 3. Add your changes using `git add` and create a commit using `git commit -s` 4. Push to gerrit: git push origin HEAD:refs/for/master. - If using HTTPS you will be prompted for the username and password you set in the Gerrit UI. - If successful, the Gerrit URL for your patch will be shown in the output. -- Anastasia.

2 2

FAILED: Chip is in an uknown state!
by Marcel Grant 04 Mar '22

04 Mar '22

Trying to flash Skulls on this X230, but keep getting this error. What am I doing wrong? Please help. Can I turn of computer now? What else can I try? sudo ./skulls.sh -b x230 1) ./x230_coreboot_seabios_74d2218cc7_top.rom 3) Quit 2) ./x230_coreboot_seabios_free_74d2218cc7_top.rom file not specified. Please select a file to flash. Please read the README for details about the differences: 1 x230_coreboot_seabios_74d2218cc7_top.rom: OK input: x230_coreboot_seabios_74d2218cc7_top.rom output: output/x230_coreboot_seabios_74d2218cc7_top_prepared_12mb.rom Warning: Make sure not to power off your computer or interrupt this process in any way! Interrupting this process may result in irreparable damage to your computer! Flash the BIOS now? y/N: y flashrom v1.2 on Linux 5.13.0-30-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using region: "bios". Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found chipset "Intel QM77". Enabling flash write... Warning: BIOS region SMM protection is enabled! Warning: Setting Bios Control at 0xdc from 0x2a to 0x09 failed. New value is 0x2a. SPI Configuration is locked down. FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only. FREG2: Management Engine region (0x00003000-0x004fffff) is locked. 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. PR1: Warning: 0x00b40000-0x00bfffff is read-only. PR2: Warning: 0x00b10000-0x00b10fff is read-only. PR3: Warning: 0x00ad0000-0x00adefff is read-only. PR4: Warning: 0x00800000-0x00aaffff 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. Enabling hardware sequencing due to multiple flash chips detected. OK. Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Reading old flash chip contents... done. Erasing and writing flash chip... Transaction error between offset 0x00800000 and 0x00800fff (= 0x00800000 + 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. 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!

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom March 2022