flashrom

flashrom@flashrom.org

1 participants
9187 discussions

flashrom dev meeting notes 19.05.22
by Felix Singer 19 May '22

19 May '22

# 19th May 2022, 6:00 - 7:00 am UTC+0 Attendees: Anastasia, Nico, Edward, Martin, Felix, Thomas ## Decisions Summary * We are targeting v1.3 release between 1st August and 15th December. Until 1st August, we will fix as many bugs from the list as possible and then we will review the status. [https://ticket.coreboot.org/issues/353](https://ticket.coreboot.org/issues/… . * We will be discussing bugs for release more often in the meeting, to keep things moving. * Split programmer lifecycle tests into separate files per programmer. ## Agenda * [Martinr] When is the next flashrom release? It's been 2 years since the last release (v1.2). * [dhendrix] Should we start doing (semi-)automatic releases on a schedule, with point fixes to address specific problems that come up? We've tried the "wait until everything is perfect'' approach and it's resulted in years-long release cycles and countless forks. Now that we have unit tests we should be confident in doing more frequent releases. * [quasisec]: I would be in favor of a semi-auto release schedule +1. * [Nico] Currently we are rather exercising “wait until everything is broken”. When we set the bar higher in the past, releases were no issue. I think we should return to that. * [Edward] Using a bug tracker allows us to have release-blocker bugs and to know who is responsible for what to help clear up communication lines. * [Martin] Maybe create a release branch to fix any bugs without adding any more features that would introduce new bugs? * [aklm] At the meeting 2022-04-21 community decided that I am a release manager. I will do a release, but I very much appreciate any help and advice from people who have experience. I have never done any release before. I created a list of issues under parent task here [https://ticket.coreboot.org/issues/353](https://ticket.coreboot.org/issues/… some of them already assigned. * [aklm] Hopefully this year * [aklm] We’ve created a list of bugs that should be fixed before release. * After the tests are run. * Testing needs to be done for meson changes, and then another time before the release. * Once release branch is created, it needs to be tested * Martin: if we get qemu images I can add them to jenkins * Edward : intermediate step is one non-linux build bot * Breaking lifecycle tests into separate files : really nice to have * [martin]: Can we set a specific date for a release? That gives us something to aim for. If we need to postpone it, we can. * December? Too far away? * August 1? Is it too aggressive? * Nico: set up for jenkins builders should not affect the release * Thomas: not sure if we finish meson support. We can just document the meson builds for this release - it doesn’t have to be complete. * Edward: how about we have a release window between 1 Aug and 15 Dec * Nico: we can fix all bugs, or disable the code * Martin: We can work until 1 Aug and see how much is fixed. * [Martinr] Who is responsible for flashrom binaries? There don't seem to be links to binaries in [https://www.flashrom.org/Downloads](https://www.flashrom.org/Downloads) and I'm willing to bet that most of those maintainers aren't doing it any more. * [dhendrix] Upstream flashrom has only ever published sources (except for certain Windows binaries?). Package maintainers for various distros have been responsible for binary releases. * The reason I was asking was that the download page is very confusing and seems to be very out-of-date. [https://www.flashrom.org/Downloads](https://www.flashrom.org/Downloads) * Windows binaries are the only ones the users are asking for * Thomas: I can build binaries for meson build testing. * Felix: What about doing a static linux build? * Nico: Let’s postpone that until someone asks for it. * Nico: It could be useful to post a daily build off of master. * Martin: We could do a nightly build with jenkins? * Thomas: static libraries are libusb, libpci , libftdi , libjaylink. * TODO: add a bug for updating the Downloads page. * For linux systems use packaged binary, if you need latest, build off master * List of versions in each distro: [https://repology.org/badge/vertical-allrepos/flashrom.svg](https://repology… * [Martinr] What do we need to do for flashrom cross-platform build testing? * [Nico] We have a set of Docker containers prepared (util/manibuilder/). FelixS is looking into buildbot integration. If coreboot makes the switch eventually, it shouldn’t be an issue. * These are somewhat out of date. * Thomas has a number of qemu images as well. * TODO: file a bug to update containers * Martin or Nico will take care of updating these. * [Martinr] What's the current state of flashrom testing? * Is it mostly manual at this point? * Unit tests are running on every push, but these are just covering a very little bit. supplement documentation for what was intended for the patch. * Google is testing after downstreaming the code. Also get tested in the commit queue. AVL test of customer roms. * Martin: would this generate a bug upstream flashrom, or only within google? * The plan is to push all of these up to the flashrom bug tracker. * What tests are done for release? * We need to document this. * In the past, there has been testing on hardware, generate a release candidate and ask the community to test. * How do we test the different internal flashers? Just the community - there’s not much change in these programmers. * Martin: email alias flashrom-vvv to send logs ? something like coreboot board status. People can send email “I have tested in, here is an output” * RC branch, when you run it, please email the results * Edward: Do we want an owners file in the tree? “Here are drivers that are officially supported” * Felix: I have some ideas for a QA lab, like 9elements Lava QA but for flashrom. So we could test at least some programmers * Can we go through open patches manually? * What’s needed to continue work on meson? * Tests currently depend on libusb. So in the current setup at least one libusb programmer needs to be selected to run tests. However not all tests depend on libusb , only for some programmers. * Lets split lifecycle.c into per-programmer files and then we can run the tests that do not depend on libusb when the library is not present.

1 0

Open Source Firmware Hackathon 2022
by Felix Singer 18 May '22

18 May '22

Hi everyone, after two crazy years, we decided it's time to do a open source firmware hackathon. It will take place from 10th June - 12th June in Darmstadt, Germany. For more details and tickets, have a look on this site [1]. The hackathon will cover open source firmware projects, like coreboot, oreboot, flashrom, LinuxBoot and any topics related to them. We have two lecture rooms (2x 80 people) for discussions and presentations. Currently, only 17 tickets are left. Everyone is welcome, no matter if beginner or professional. 24h breakfast, snacks and soft drinks are provided for free. Would love to see you there! // Felix [1] https://osfw.foundation/events/osff-summer-hackathon-2022/

1 0

Failed Protectli fw6e coreboot (protectli_all_fw6_vault_kbl_v1.0.14.rom)
by John Caltry 18 May '22

18 May '22

Hello, Ubuntu 20.04 boot from USB (try Ubuntu) and attempted install using Protectli Flashli. Cut and paste follows, any advice is appreciated! John \ == \ /\ == \ /\ __ \ /\__ _\ /\ ___\ /\ ___\ /\__ _\ /\ \ /\ \ \ \ _-/ \ \ __< \ \ \/\ \ \/_/\ \/ \ \ __\ \ \ \____ \/_/\ \/ \ \ \____ \ \ \ \ \_\ \ \_\ \_\ \ \_____\ \ \_\ \ \_____\ \ \_____\ \ \_\ \ \_____\ \ \_\ \/_/ \/_/ /_/ \/_____/ \/_/ \/_____/ \/_____/ \/_/ \/_____/ \/_/ _________________________________________________________________________________________ =========================================FlashLi========================================= --Version 1.1.20-- Device: Protectli fw6e CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz BIOS Mode: BIOS Available BIOS: [1]: ami (FW6_all_YKBR6L12.bin) [2]: coreboot (protectli_all_fw6_vault_kbl_v1.0.14.rom) Enter the [#] of an image file, or [0] to quit. Flahing will not begin yet > 2 ********************************************!******************************************** 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 5.13.0-30-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 chipset "Intel Kaby Lake U w/ iHDCP2.2 Prem.". Enabling flash write... SPI Configuration is locked down. Enabling hardware sequencing because some important opcode is locked. OK. Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Reading ich descriptor... done. Using region: "bios". Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... FAILED at 0x00103056! Expected=0xff, Found=0xc5, failed byte count from 0x00000000-0x007fffff: 0x99c 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 let us know. TODO: Collect info and display instructions on how to submit a Github issue.

3 2

Flashrom Dev Meeting summary info
by Anastasia Klimchuk 18 May '22

18 May '22

Hello People, I wanted to summarise the information on the time of Dev meeting. At some point there was an idea to alternate times, but then we discovered that we got really lucky and there is one time which everyone agrees on. That was an open question at the last meeting, to confirm the time with those US folks who were not present. Since no one was replying to the mailing list, I reached out to folks and confirmed the time is fine. —------------- SUMMARY —------------- #1 Between November and March (inclusive) time of meeting: Wednesday 21:00-22:00 UTC+0 also known as Wednesday 13.00-14.00 Pacific Standard Time UTC-8 Wednesday 22.00-23.00 Central European Time UTC+1 Thursday 8.00-9.00am Australian Eastern Daylight Time UTC+11 #2 Between April and September (inclusive) time of meeting: Thursday 6.00-7.00am UTC+0 also known as Wednesday 11pm-midnight Pacific Daylight Time UTC-7 Thursday 8.00-9.00am Central European Summer Time UTC+2 Thursday 16.00-17.00 Australian Eastern Standard Time UTC+10 #3 Note that in the last week of March and 4 weeks of October there will be no meetings, because daylight saving time changes are happening on different dates in different locations, and setting up meeting time becomes too complicated. Once the regularity is stable, I will add info about Dev meeting on the Contacts page. Meanwhile: —---- FAQ —---- #1 When is the next meeting? Look into the meeting notes document <https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WF…>. The top entry, on the first page, with the date in the future, and empty list of attendees - is the next meeting. #2 How to join the meeting? Look into the meeting notes document <https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WF…>. On the top it says “to join, click the link”, click the link. #3 Where is that document? Meeting notes document is linked to the Home page of flashrom.org, Developers menu at the bottom of the page. #4 Do I need an invitation to join the meeting? No, just join. -- Anastasia.

1 1

Is anyone interested in OTP support patchset?
by Sergii Dmytruk 17 May '22

17 May '22

Hello, Some time ago I've revived an old patchset by Hatim Kanchwala and extended it with support for more devices and unit tests. It wasn't reviewed for a while and now that reviewing makes sense (changes it's based on were accepted) it's not really needed for 3mdeb's project anymore... The question is whether there is a need for it? If there is interest and wiliness to test it (wasn't tested on hardware), pursuing review still makes sense. Someone can even take over the patches and I'll become a reviewer and help along the way. If OTP isn't needed at the moment, the patchset will be abandoned at least until some project which requires OTP in flashrom or until someone else will pick it up. The first change of the series is (no topic yet) https://review.coreboot.org/c/flashrom/+/59402 To give you an idea of the amount of work it might take to upstream: Makefile | 2 chipdrivers.h | 5 cli_classic.c | 243 dummyflasher.c | 351 flash.h | 6 flashchips.c | 61 flashrom.8.tmpl | 81 libflashrom.h | 18 meson.build | 2 otp.c | 490 otp.h | 91 otp_layouts.c | 210 spi.h | 40 spi25.c | 89 spi25_statusreg.c | 90 tests/chip_otp.c | 470 tests/meson.build | 1 tests/tests.c | 14 tests/tests.h | 12 19 files changed, 2186 insertions(+), 90 deletions(-) Conflicts with current master for a couple of month, should be easy to fix (I'll do that if someone else will take over). I also have a bash script to test new CLI options via dummyflasher. Best regards, Sergii

1 0

Release preparations
by Nico Huber 17 May '22

17 May '22

Hi folks, people often ask me about a potential next release and what is holding me back. Long story short, I knew about some bad things in our master branch that make a release impossible and I was very much afraid that there could be more that I don't know about. I've been scrolling through the commit log from v1.1 (the last release I was involved) to today's master. Some of the things I found are simple like something missing for a flash chip entry. But most of it are things I'd rather not have on a release branch. And the list turned out to be much longer than I expected. OTOH, I didn't find issues of the worst kind I expected. Not sure how to go on from here. As this is a lot to do, I suggest that we freeze the master branch for everything that is neither a fix nor on the list (or a similar case that I missed). I noted sometimes that we could just drop the code from a release branch. If we'd decide to do that, we'd also need a plan how to stop the rot on the master branch. Below are my raw notes, I don't have the time to write things up nicely. I noted the commit hash where things began, but tried to take the cur- rent state into account. For instance, when it's about a new programmer driver, I was looking at the file, not the initial patch. Cheers, Nico Recommended clean-ups and investigations before v1.3 ==================================================== * cb973683 Added partial meson support which confuses package main- tainers. Should we remove it from or disable CLI building on release branches? * 71b706f5 Adds some libflashrom APIs with questionable design, buggy implementation and no visible user. Would be easiest to drop and add back when somebody needs it. Open comment. Partially fixed up. * 86fc9cf7 Open comment. Partially fixed up. * 05c629be Looks incomplete, flash would be fully erased with programmers that lack native 4BA command support. * ad08aef6 Undocumented programmer. disable? drop from realease branch? * 703de983 Added `spireadmode` param to sb600spi. (How) does it work? * 13a2ef6c Added `lspcon_i2c_spi`. Too generic name: LSPCon is a concept but driver seems to be about a specific vendor/chip. No pro- bing just starts to write to hardcoded addresses. WP code contains magic numbers, board specific? Implements `spi_ master` but contains hard-coded SPI opcodes. Not documented? disable? drop from release branch? * d97f87b0 Added `realtek_mst_i2c_spi`. No probing, starts by toggling a GPIO. Are GPIO settings board specific? Timeout checks seem to have regressed since original commit. Not documented? Changes clock settings, is this board specific? Implements `spi_master` with special cases in an opcode LUT, doesn't bail out on unknown codes. Falls back on unaligned reads/ writes, were these paths tested? Fixups suggest that the original code wasn't properly tested, was it by now? disable? drop from release branch? * be4682dc Might miss some block erasers. * f82dd300 Might miss some block erasers. * a2dc4f7f It seems `clear_spi_id_cache()` is never called. Probably, should be before probing. * 3149822c Added variable size in `dummy_programmer`. Didn't look at it right now, but I remember it caused a lot of trouble. Probably not fully fixed up yet. * cb9f3cd0 Possible division by zero. * ca2e3bce Fixed some libpci usage. IIRC, there are many more similar cases that might need a fix now that libpci is more strict. * 0386aa17 sb600spi refactoring. Looks like it dropped an error message from many error paths. * f745d0e6, adbae0e2 Added infrastructure for S25F chips. Code style looks a bit outdated. Probably needs upstream review. * 8fa792fb Added chips with oddities and w/o reasoning, e.g: .total_size = 16384, /* This is just half the size.... */ Complete patch needs review. * 855d6b6f Added Ryzen support to sb600spi. API violations. Stalled other cleanup work. Soft bricks machines with >16MiB flash. Patches on Gerrit. drop from release branch? * 32f4cb4f Looks like copy-pasta from Winbond chips. Might miss some block erasers. Missing 4BA_WRITE is probably wrong. * 45d50a10 Added support code for per-region file arguments. Review was interrupted, IIRC. Rebase was borked shortly before merge. Work never finished. * d4063bf3 Missed to update the manpage. Literal `-` shouldn't be in `<>`. * ce983bcc Missed to update the manpage. Filters only spaces when converting region names to file names. * 51e1d0e4 Still selects the wrong chipset, IIRC. * e98b2d11 Review never really started. See comments on Gerrit. Backport candidates =================== * 4ca575dc usbdev: Only match requested USB devices * 8bbb7648 spi95: Check for success before using send_command's returned data * b07c53d7 spi25: Debug flashrom crash when Write Protect is ON Looks like this covers up a general problem with flash-chip entries. Why would we know how to disable block protection if we don't know how to report it? Should probably be added to self checks. * 51261541 it87spi.c: Prevent use-after-free bug * da0825f0 chipset_enable.c: check return value from rphysmap() call * 705212da chipset_enable.c: Validate physmap() return rcrb value * b76d2810 dediprog: Fix segmentation fault on no device found * 1a21cc70 helpers.c: Fix undefined behavior in strndup() * a2f2f3f5 linux_mtd: Disable buffering on the mtd device * ab623c65 jlink_spi: Reduce transfer size * Many fixes in dummy_flasher, not sure if they were applicable earlier. * aedfb7eb flashrom.8: add missing entry for `--flash-contents` * 89c73b5a linux_mtd: check ioctl() return value properly

11 25

Updating Intel idaville BIOS failed.
by Jackie Tang 17 May '22

17 May '22

Hi Team, Excuse me, I am currently working on the BIOS of the Intel idaville platform, and the BIOS chip used is a 64M WINBOND W25Q512JVFIQ. After the machine boots into CentOS, I use the command "flashrom -w BIOS.ROM -p linux-spi" and it will return "No spi device given", and the BIOS update fails. May I ask what method can be used to solve this problem or update the BIOS with flashrom in the OS successfully, or how can I successfully mount the flash? Waiting for your reply. Best Regards, Celestica Technology Consultancy (Shanghai) Co.,Ltd Jackie

1 0

Gatekeeping, ACLs and Review Rules
by Nico Huber 17 May '22

17 May '22

Dear fellow flashrom developers, I've been reflecting lately about written and unwritten rules around our review process and our related privileges on Gerrit. I couldn't identify anything that works well, or let's say well enough. So it might be time we discuss some things and make changes :) Before the dawn of our Git repository and using Gerrit as a review plat- form, we had a Subversion repository. With very few people, usually one or two I think, that had write access. So practically we had gatekeepers that watched over the code. Eventually, they became a bottleneck so we widened that a little when starting the work on Gerrit. Today, I often catch myself falling back into such a gatekeeper mode. Which is futile anyway because I'm not the only one who can write to the repository. But I still wonder why this happens and if it's necessary. I guess first everyone needs to understand how we imagined things with Gerrit and how it looks like today. As mentioned above we set up a group "flashrom developers" which has exclusive write access to the reposi- tory. The idea was to only have people in this group who are long-term (I was thinking about years) contributors to flashrom, know each other from real-time communication (IRC) and trust each other. For the review right "+2", we used the "Reviewers" group from coreboot. IIRC, I pushed for the latter. I was hoping to grow the communities a little together that seemed to have gone separate ways in the years before. After all, a lot of coreboot developers use flashrom in their everyday work. Combined with the "flashrom developers" group it shouldn't have been an issue that people with little flashrom knowledge would review. Since the original setup (about 2017) things went on rather uncon- trolled. I think the gist of it is that people didn't expect that flashrom would need/have different rules compared to coreboot. At some point somebody whom I only knew from their work on coreboot sud- denly merged patches for flashrom. And I guess people pushing patches today pretty much expect that there is nothing more to be done once they see the first +2. No matter if the reviewer knows anything about flashrom. When reviewers disagree then, it can become frustrating for everyone. So currently, I lean towards aligning our process more with that of coreboot. The big difference seems to be that at coreboot merging patches, i.e. hitting the "Submit" button, is more or less considered an administrative task unrelated to one's opinion on the code. While for us it was supposed to replace the gatekeeping. Changing this would imply that we need our own group of reviewers. With this, a +2 would become both rarer and stronger. If this idea meets some consent, I would propose to copy the "flashrom developers" group for a start. And when we identify somebody over time who shows in-depth knowledge about at least a part of flashrom and good self-judgement if they are experienced enough for a +2, we could add them. Right now, some candidates come to mind already, Peter, Nikolai, and Thomas. The "flashrom developers" group also grants the privilege to block "-2" a change. I have very conflicting feelings about this. On one hand, this is a tool that is only ever necessary when people in said group can't trust each other. On the other, that seems to be the status quo already. Maybe we should have another group on top for this? This time really only for trusted, established, long-term contributors? Or maybe for those who maintain the codebase beyond what they are paid for? There is one related idea for a rule that crossed my mind: How about we forbid blocking reverts that fix a regression and apply cleanly (i.e. without needing to revert anything else in advance). Also, let them pass after review without waiting 24 hours. At least for myself this would reduce a lot pressure to fall back to gatekeeping if I knew I could keep things safe and sound without discussion. For maintainers, the patches that are already merged matter the most, cause the most work. This should also be the case for contributors, but alas many don't see it like this and don't help to fix things after a patch is merged. Easing reverts would push the hard work back to the people who break things. Looks a bit longer than what I intended to write, as usual when one starts writing ;) If we come to a conclusion wrt. Gerrit privileges, we could also discuss more rules for each role. While I'm not a fan of too many rules and would rather keep things to common sense, these things depend much on the people we add to the respective groups. I hope it's not too much to digest at once ;) Cheers, Nico

5 17

Questions regarding Easy project and GSoC
by Aarya Chaumal 17 May '22

17 May '22

Hello there, I hope you are well today when you receive this email. I am Aarya Chaumal, a Computer Engineering student at the College of Engineering Pune, India. While going through organizations for this year's Google's Summer of Code I came across your organization, Flashrom. I am a part of onboard computers subsystem at my college's satellite initiative. Through this, I have closely worked on Atmel SAM E70 XPLAINED board. Also, I have strong knowledge about C/C++ and assembly language. From your list of GSoC project ideas, I liked the idea of “Remove global state from flashrom” and "Optimize Erase-Function Selection", although I am not quite sure which one is more suitable for me. Can you guide me through this? As mentioned in your Contributor commitments and requirements, I started to do one of the easy projects - Add new flash chip definitions. For this, I read the relevant datasheets, one from the unlisted chips and another of a listed one (for reference) but still, I am not getting the information about some fields for the structure in the datasheet, namely the feature_bits, probe_timing. Also, do I have to write the probe, read, write and erase functions for the chip separately? Also, how do I test if my code is working as I don't have relevant hardware with me? Can you help me with this? Also what resources should I use to learn more about it? Thank you for looking into this for me. Sincerely, Aarya Chaumal

7 34

flash intel network adapter
by Denis 16 May '22

16 May '22

Hello. Do you have any plans to add support for 8086:1583 - Intel Ethernet Converged Network Adapter XL710-QDA2 ? After an unsuccessful firmware... BootUtil writes "Cannot initialize adapter". No standard ways to make rollback :((( It would be great to flash with your utility. Thanks in advance

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom