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
Hello Nico, “I've been scrolling through the commit log from v1.1 (the last release I was involved) to today's master.” I am wondering why v1.1, I know the latest released version is v1.2? Is there anything about v1.2 release why you don’t count it? “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)” But how can we freeze master… that would mean no one can do any work? Maybe I am missing something? Also I am looking at two lists. The first one, is my understanding correct, those can be bugs in bugtracker (which we will have soon right? :)) and assigned to different people? The second list Backport, are those good commits that go to the release? What is happening with all the other commits? (between v1.1 and now that would be a lot of them). I am just trying to understand the technical process. Some of the things in the first list that I wanted to ask about: “cb973683 Added partial meson support which confuses package main- tainers. Should we remove it from or disable CLI building on release branches?” Oh, we are using meson in the chromium tree to build everything. I added a topic to the meeting agenda about Meson and Makefile, although it overflowed to the next meeting. Also I understand Meson already got into v1.2? I thought the next version is based on the previous? “ad08aef6 Undocumented programmer. disable? drop from realease branch?” I looked that is about raiden debug programmer. If it is undocumented, can we document? On Mon, Mar 7, 2022 at 10:10 AM Nico Huber <nico.h@gmx.de> wrote:
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 _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
-- Anastasia.
Hi Anastasia, On 13.03.22 08:28, Anastasia Klimchuk wrote:
I've been scrolling through the commit log from v1.1 (the last release I was involved) to today's master.
I am wondering why v1.1, I know the latest released version is v1.2? Is there anything about v1.2 release why you don’t count it?
tl;dr it was done in a hurry, IIRC. Starting with 1.0, I maintained release branches per minor release (1.0.x, 1.1.x). The plan was to also make point releases on these branches if any fixes made it into a new release (and also apply to a release branch). I assume nobody kept track what might also apply to these branches until today. And to be honest, I forgot if there just wasn't anything applicable between v1.1 and v1.2 or if we didn't check ;) v1.1 was also the last release before some incredibly chaotic development started. To converge forks, some people seemed to push simple diffs of up- and downstream to upstream flashrom. Not sure what drove it, but the idea seems to have been that downstream was ahead, while it was actually years behind. Some of such patches made it into the master branch and I wanted to try at least one time to figure out if there was anything left that wasn't reverted yet.
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)
But how can we freeze master… that would mean no one can do any work? Maybe I am missing something?
No you didn't miss anything :) it would be a very desperate measure. However, I see no other solution to make progress again without forking or further stalling a release. And after 2 years I think the project has waited long enough. This is also why I suggested that we can drop suspicious code from a release branch (i.e. we could branch 1.3.x now and then delete code on that branch without affecting master). Then the freeze might be over really quickly. We'd only need to decide what to do with the code instead of fixing every- thing at once. However, if that would result in no action on the master branch until we branch 1.4.x, I would vote to delete the code on the master branch too.
Also I am looking at two lists. The first one, is my understanding correct, those can be bugs in bugtracker (which we will have soon right? :)) and assigned to different people?
Very much so.
The second list Backport, are those good commits that go to the release?> What is happening with all the other commits? (between v1.1 and now that would be a lot of them). I am just trying to understand the technical process.
This is about the older release branches. I just wrote down the commits that looked like they might fix something that was already an issue years ago. IOW, the second list doesn't matter for the v1.3 release. Nico
On 13.03.22 16:28, Nico Huber wrote:
On 13.03.22 08:28, Anastasia Klimchuk wrote:
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)
But how can we freeze master… that would mean no one can do any work? Maybe I am missing something?
No you didn't miss anything :) it would be a very desperate measure. However, I see no other solution to make progress again without forking or further stalling a release. And after 2 years I think the project has waited long enough.
Sorry folks, I didn't mean to provoke any hasty activity to fix the listed problems. Rather to push us to talk about what we should fix before a release and what features we could do without in a release. If we'd wait for everything to be fixed at snail pace, I fear people would give up before another release happens (I would). Not to mention that people will continue to push more controversial patches in the meantime. Nico
Thank you for the explanations! Really helpful. I am trying to understand the mechanics. “This is also why I suggested that we can drop suspicious code from a release branch (i.e. we could branch 1.3.x now and then delete code on that branch without affecting master). Then the freeze might be over really quickly.” This option would mean all the items from the first list are reverted in v1.3? And then they, hopefully, all get fixed to the time of v1.4? (correct me if I am wrong) Then that means on the other end there is an ideal scenario where all the items from the first list are fixed (on master) and then v1.3 happens? And also a scenario in between when some of the items are fixed, but not all of them? Which of these scenarios has minimum time to freeze master, and which one takes second place? I am asking because I fully agree with you, it seems just as you said “a very desperate measure”... so I am worried this may create a drama :\ We have already created 5 bugs as “flashrom release blockers” in our internal bug tracker (the only reason they are created in internal one is because flashrom bug tracker is not ready yet). There is no secret info there at all. That’s for all the items that are missing documentation. It is not a hasty activity, we want to help! Release is important. And especially the items which say “missing documentation”, it’s a no-brainer, needs to be fixed. “My latest idea about this is that we could add an option (e.g. `inofficial`) and a whitelist of known working platforms. Such that one would have to literally state they want an inofficial binary to build on a platform with unknown status.” Looks fine, let’s keep it unofficial (if it really is). Let’s just not delete it :) “I can work on that unless someone else wants the task.” Thanks Martin! There is a patch currently for man page: https://review.coreboot.org/c/flashrom/+/62768 But did you mean more than that? On Fri, Mar 18, 2022 at 2:56 AM Nico Huber <nico.h@gmx.de> wrote:
On 13.03.22 16:28, Nico Huber wrote:
On 13.03.22 08:28, Anastasia Klimchuk wrote:
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)
But how can we freeze master… that would mean no one can do any work? Maybe I am missing something?
No you didn't miss anything :) it would be a very desperate measure. However, I see no other solution to make progress again without forking or further stalling a release. And after 2 years I think the project has waited long enough.
Sorry folks, I didn't mean to provoke any hasty activity to fix the listed problems. Rather to push us to talk about what we should fix before a release and what features we could do without in a release. If we'd wait for everything to be fixed at snail pace, I fear people would give up before another release happens (I would). Not to mention that people will continue to push more controversial patches in the meantime.
Nico _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
-- Anastasia.
Hi, On 21.03.22 10:11, Anastasia Klimchuk wrote:
Thank you for the explanations! Really helpful.
I am trying to understand the mechanics.
This is also why I suggested that we can drop suspicious code from a release branch (i.e. we could branch 1.3.x now and then delete code on that branch without affecting master). Then the freeze might be over really quickly.
This option would mean all the items from the first list are reverted in v1.3?
in the most extreme scenario, yes. Please note that I don't consider everything on that list as a release blocker. Some things just looked odd and may only need a second look.
And then they, hopefully, all get fixed to the time of v1.4? (correct me if I am wrong)
Hopefully, yes. Not sure what to do if not, I wouldn't like to repeatedly clean up on release branches. Also, some of the items look like something we wouldn't even want on master, e.g. known broken things.
Then that means on the other end there is an ideal scenario where all the items from the first list are fixed (on master) and then v1.3 happens?
Then we would branch 1.3.x from master and v1.3-rc1 happens.
And also a scenario in between when some of the items are fixed, but not all of them?
Pretty much, yes, and I'd hope for this. Better to compromise than to wait forever ;)
Which of these scenarios has minimum time to freeze master, and which one takes second place? I am asking because I fully agree with you, it seems just as you said “a very desperate measure”... so I am worried this may create a drama :\
Given that nobody reacted with "let's do it", it seems very unlikely to me that we will exercise a freeze. Nico
On 13.03.22 08:28, Anastasia Klimchuk wrote:
Some of the things in the first list that I wanted to ask about:
cb973683 Added partial meson support which confuses package main- tainers. Should we remove it from or disable CLI building on release branches?”
Oh, we are using meson in the chromium tree to build everything. I added a topic to the meeting agenda about Meson and Makefile, although it overflowed to the next meeting.
Also I understand Meson already got into v1.2? I thought the next version is based on the previous?
Yes, but I hope that doesn't mean we can't revert problems :) The `meson.build` made it into v1.2, that is right but turned out to cause more trouble than was expected. OS package maintainers quickly adopted it without any second thought. And then all their packages had issues because the `meson.build` did some things wrong (no version in- formation in the binary for instance, no man page in the package, CLI options not working). Almost nobody tried to build the flashrom CLI with Meson before. The known issues are fixed, but so far we only know that it works on x86 and ARM with Linux (that's likely less than 10% of what is expected to work with the Makefile). My latest idea about this is that we could add an option (e.g. `inofficial`) and a whitelist of known working platforms. Such that one would have to literally state they want an inofficial binary to build on a platform with unknown status.
ad08aef6 Undocumented programmer. disable? drop from realease branch?
I looked that is about raiden debug programmer. If it is undocumented, can we document?
Hopefully. IMO, the minimum for a new programmer to be accepted upstream is a section in the manpage, including documentation about programmer parameters. With such documentation at hand, we could even start to re- view the code ;) I had a look at the comment on top of `raiden_debug_spi.c` right now. I knew it was attached over USB, but it seems that the other end goes directly to the target device (not any kind of dongle between two computers). If that is the case, it would be important to know what Chromebook (I guess) models support it. Nico
On Sun, Mar 13, 2022 at 9:49 AM Nico Huber <nico.h@gmx.de> wrote:
On 13.03.22 08:28, Anastasia Klimchuk wrote:
...
ad08aef6 Undocumented programmer. disable? drop from realease branch?
I looked that is about raiden debug programmer. If it is undocumented, can we document?
Hopefully. IMO, the minimum for a new programmer to be accepted upstream is a section in the manpage, including documentation about programmer parameters. With such documentation at hand, we could even start to re- view the code ;)
I had a look at the comment on top of `raiden_debug_spi.c` right now. I knew it was attached over USB, but it seems that the other end goes directly to the target device (not any kind of dongle between two computers). If that is the case, it would be important to know what Chromebook (I guess) models support it.
The raiden driver works with a number of different ChromeOS debug methods, not just chromebooks directly: 1) ChromeOS devices that support case closed debug (CCD) using the SuzyQable. - Make your own: https://www.youtube.com/watch?v=WGsyXlgSxFk - Was sold by sparkfun, but due to the chip shortages, it's out of stock. 2) ChromeOS devices that support CCD, using the Servo-V4 device. - This device and the two below are only available from google, because we haven't found a reseller that will partner with us to manufacture and sell it. - Both of these are documented on the CCD page at chromium.org: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/doc... 3) New ChromeOS devices that use the C2D2 debugger & 8-pin connector. - Somewhat documented at chromum.org: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/doc... 4) Old ChromeoOS devices that use the older style servo connector, debugged with the uServo debugger. - Documented at chromium.org: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/doc... The raiden driver is actually just a basic USB to serial driver that expects the Google UBS VIDs & DIDs. The flashrom interface sets up the packets in the way that the debugger on the other end of the device expects. As Nico mentioned, there's good documentation in the flashrom code already, and the entire rest of the interface is in the ChromeOS EC codebase, so it shouldn't be difficult to get the documentation done. I can work on that unless someone else wants the task. Martin
On Sun, 13 Mar 2022 at 15:49, Nico Huber <nico.h@gmx.de> wrote:
Also I understand Meson already got into v1.2? I thought the next version is based on the previous? Yes, but I hope that doesn't mean we can't revert problems :)
I don't think adding a smiley face makes it any less insulting to the people that added, and *continue to maintain* the meson feature.
The `meson.build` made it into v1.2, that is right but turned out to cause more trouble than was expected. OS package maintainers quickly adopted it without any second thought.
Have you pondered why that might be? OS package maintainers usually don't change the way they build packages without a good reason.
And then all their packages had issues because the `meson.build` did some things wrong (no version in- formation in the binary for instance, no man page in the package, CLI options not working).
Are there any issues outstanding? All this talk of "removing things" does not give me the warm-and-fuzzies for building things on top of the flashrom project. Richard
Hello Richard, On 21.03.22 17:23, Richard Hughes wrote:
On Sun, 13 Mar 2022 at 15:49, Nico Huber <nico.h@gmx.de> wrote:
Also I understand Meson already got into v1.2? I thought the next version is based on the previous? Yes, but I hope that doesn't mean we can't revert problems :)
I don't think adding a smiley face makes it any less insulting to the people that added, and *continue to maintain* the meson feature.
sorry if the context offended you. I meant this rather generally: We should be open to discuss such things. In the Meson case, I'd be happy about any solution that avoids accidental use of Meson for releases, i.e. when nobody tested if it's working correctly in a given environ- ment.
The `meson.build` made it into v1.2, that is right but turned out to cause more trouble than was expected. OS package maintainers quickly adopted it without any second thought.
Have you pondered why that might be? OS package maintainers usually don't change the way they build packages without a good reason.
I assume they got used to configuration systems like autotools/cmake/ Meson and use them by default if the necessary files are around. I consider not using such a system the exception today.
And then all their packages had issues because the `meson.build` did some things wrong (no version in- formation in the binary for instance, no man page in the package, CLI options not working).
Are there any issues outstanding?
How should we know? Nobody is taking the time to really test the Meson setup on Meson-supported platforms (except Linux). Or maybe somebody is and doesn't tell us. The issues that were fixed so far were only iden- tified when quirky binaries made it to the end users already. Fixing issues is the easy part, one needs to find them first though. And if that happens too late, it creates unnecessary work for developers and package maintainers. There is also one big general issue: we need to maintain two build systems now. We can't use GNU make only, because nobody knows what the requirements of the Meson users are. And we can't use Meson only, because nobody knows if and how it works on all the platforms suppor- ted by the Makefile. Nico
All this talk of "removing things" does not give me the warm-and-fuzzies for building things on top of the flashrom project.
On Mon, 21 Mar 2022 at 20:04, Nico Huber <nico.h@gmx.de> wrote:
There is also one big general issue: we need to maintain two build systems now. We can't use GNU make only, because nobody knows what the requirements of the Meson users are.
My vote would be to remove the *Makefile*, and move 100% to Meson -- the modern build-system that's *already* being used by the packagers for all the supported architectures and OS builds on dozens of distros. Richard
Richard Hughes <hughsient@gmail.com> writes:
On Mon, 21 Mar 2022 at 20:04, Nico Huber <nico.h@gmx.de> wrote:
There is also one big general issue: we need to maintain two build systems now. We can't use GNU make only, because nobody knows what the requirements of the Meson users are.
My vote would be to remove the *Makefile*, and move 100% to Meson -- the modern build-system that's *already* being used by the packagers for all the supported architectures and OS builds on dozens of distros.
FWIW, the pkgsrc build is currently using the Makefile. I use that to get flashrom on NetBSD-9 amd64 to use with apu2. More importantly, the instructions in the README in flashrom 1.2 do not mention meson and say to use make. Similary, https://www.flashrom.org/Downloads#Installation_from_source does not mention meson. (It also doesn't mention that specifically GNU make is required, vs BSD make, but that's pretty common to omit.) (I'm not claiming that building with meson wouldn't work, but just pointing out that "all packaging system builds use meson" is incorrect.) So if there is any talk of removing makefiles, there needs to be a release with formal support for meson including it being the standard approach in REAMDE and a deprecation warning.
On 21 March 2022 22:04:07 WET, Greg Troxel <gdt@lexort.com> wrote:
Richard Hughes <hughsient@gmail.com> writes:
On Mon, 21 Mar 2022 at 20:04, Nico Huber <nico.h@gmx.de> wrote:
There is also one big general issue: we need to maintain two build systems now. We can't use GNU make only, because nobody knows what the requirements of the Meson users are.
My vote would be to remove the *Makefile*, and move 100% to Meson -- the modern build-system that's *already* being used by the packagers for all the supported architectures and OS builds on dozens of distros.
FWIW, the pkgsrc build is currently using the Makefile. I use that to get flashrom on NetBSD-9 amd64 to use with apu2.
More importantly, the instructions in the README in flashrom 1.2 do not mention meson and say to use make.
Similary, https://www.flashrom.org/Downloads#Installation_from_source does not mention meson. (It also doesn't mention that specifically GNU make is required, vs BSD make, but that's pretty common to omit.)
(I'm not claiming that building with meson wouldn't work, but just pointing out that "all packaging system builds use meson" is incorrect.)
So if there is any talk of removing makefiles, there needs to be a release with formal support for meson including it being the standard approach in REAMDE and a deprecation warning.
Beside from the documentation, the meson file currently only works for Linux and was never announced as official way to build flashrom. Dropping the Makefile is also no option as long as the meson.build does not work with all platforms supported by flashrom. In a release we should have a consisted build system across all those platforms. The two build systems are also topic of the next developer meeting. Imo we should find a proper solution for the meson build file and do not rush for the next release. -- Thomas
On Mon, Mar 21, 2022 at 4:48 PM Thomas Heijligen <src@posteo.de> wrote:
Beside from the documentation, the meson file currently only works for Linux and was never announced as official way to build flashrom.
The original reason for adding Meson was to support fwupd, a very important use case which AFAIK is only intended to work with internal programmers for in-system flashing in Linux. Mission creep was not the intention, though Meson has evidently gained popularity for other use cases. Notably, according to a comment in CB:61198 <https://review.coreboot.org/c/flashrom/+/61198> Chromium now uses Meson for all builds too. ChromeOS and fwupd are probably the biggest users of flashrom when it comes to use of internal programmers. Also, as mentioned earlier in the thread there are many distributions using Meson for packaging. It will be good to understand why they are going this route and if it's better for the project in the long run. Personally I am more familiar with Make, but even I can see that our Makefile is one that only a flashrom developer could love.
On 22 March 2022 06:01:25 WET, David Hendricks <david.hendricks@gmail.com> wrote:
It will be good to understand why they are going this route and if it's better for the project in the long run. Meson is easier to use, especially when you have to deal with a lot of different projects. All variables you need are well defined and usable across all projects which uses meson. The build options are accessible without the need to dig into the buildfile or project documentation. With Makefiles every project has its own set of options and variables. That is an overhead you have to deal with as package maintainer. From a project developer perspective meson takes away a lot of work you otherwise have to do by your own in the Makefile. For example system determination, searching for dependencies and cashing of the build configuration. Personally I am more familiar with Make, but even I can see that our Makefile is one that only a flashrom developer could love. I've spend a lot of time into the Makefile in the last month and my hope is that it's more readable by now. I'm truly not a fan of it and I would be happy if we can drop it. But implementation wise the meson.build is not better. It's a translation from the Makefile which makes only minimal use of mesons features.
Am 22.03.22 um 07:01 schrieb David Hendricks:
On Mon, Mar 21, 2022 at 4:48 PM Thomas Heijligen <src@posteo.de> wrote:
Beside from the documentation, the meson file currently only works for Linux and was never announced as official way to build flashrom.
The original reason for adding Meson was to support fwupd, a very important use case which AFAIK is only intended to work with internal programmers for in-system flashing in Linux.
Mission creep was not the intention, though Meson has evidently gained popularity for other use cases. Notably, according to a comment in CB:61198 <https://review.coreboot.org/c/flashrom/+/61198> Chromium now uses Meson for all builds too. ChromeOS and fwupd are probably the biggest users of flashrom when it comes to use of internal programmers. Also, as mentioned earlier in the thread there are many distributions using Meson for packaging.
It will be good to understand why they are going this route and if it's better for the project in the long run. Personally I am more familiar with Make, but even I can see that our Makefile is one that only a flashrom developer could love.
AFAIR there were three arguments for meson: - Building dynamic libflashrom was nontrivial for the old makefile (static libflashrom was always there) - Meson is newer and easier on the eyes - Meson build integrates nicely with other packages built by meson Last time I checked, the following features were missing from the Meson build script in flashrom: - Complete crossbuild support - Native support for most non-Linux platforms - Support for quite a few programmers - Anyone who checks that the binaries built by Meson and Makefile are identical (admittedly that's not the fault of the code but a lack of time/motivation) There are even open bugs in Debian about Meson built flashrom: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955387 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976639 As a side note, we never used autotools even though one of the Debian flashrom uploaders thinks so. Our Makefile was not nice (I should know since I wrote most of the ancient code). Nobody has shown up willing to add all the features of Makefile to Meson and even if someone would be willing, we'd need testers for all the features, which also didn't happen in the almost 3 years since Meson support was contributed. I think Meson was a good idea, but it failed to get traction beyond "we need it for dynamic libflashrom". Side note: The now-defunct coreboot v3 also was a nice idea, but it failed to gain the necessary developer mindshare due to missing support for the use cases of most of the active coreboot developers. I was quite sad because I really liked coreboot v3. While some good parts of it were eventually adopted in coreboot v2/v4, quite a lot of development effort was mostly useful for the learning experience. This feels similar. AFAICS adding dynamic libflashrom support to Makefile would make the Meson support a true subset and then we could switch back to using Makefile for all cases. The current Makefile is a lot more readable than the state 3 years ago, so arguably Meson did help. Regards, Carl-Daniel
On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
AFAIR there were three arguments for meson: - Meson build integrates nicely with other packages built by meson
This means we can build libflashrom as a subproject, which means we can build the flashrom plugin even when the distro doesn't ship [a new enough] flashrom package: https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap That's just something you can't do with the Makefile, and removing the subproject would force us to remove flashrom support from almost all the CI systems we test fwupd with.
- Native support for most non-Linux platforms
I keep hearing this, but haven't got any actual data -- is there any reason why the meson build system wouldn't "just work" with *BSD/Win32/macOS?
I think Meson was a good idea, but it failed to get traction beyond "we need it for dynamic libflashrom".
I don't know how you've managed to get to "failed to get traction" given that it's being built with meson in 4 of the biggest projects (in terms of distribution, and number of deployed packages) using flashrom. This is all so frustrating: This feels like more of an existential crisis about what flashrom actually *is* rather than a discussion about build systems. Richard.
On Wed, Mar 23, 2022 at 09:20:18AM +0000, Richard Hughes wrote:
On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
AFAIR there were three arguments for meson: - Meson build integrates nicely with other packages built by meson
This means we can build libflashrom as a subproject, which means we can build the flashrom plugin even when the distro doesn't ship [a new enough] flashrom package: https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap
That's just something you can't do with the Makefile, and removing the subproject would force us to remove flashrom support from almost all the CI systems we test fwupd with.
Is meson unable to call `make` in a subdirectory? Luc Verhaegen.
Hi Richard, Am 23.03.22 um 10:20 schrieb Richard Hughes:
On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
AFAIR there were three arguments for meson: - Meson build integrates nicely with other packages built by meson This means we can build libflashrom as a subproject, which means we can build the flashrom plugin even when the distro doesn't ship [a new enough] flashrom package: https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap
That's just something you can't do with the Makefile, and removing the subproject would force us to remove flashrom support from almost all the CI systems we test fwupd with.
It took me some time to understand the text of this last sentence, but I'm unsure about the implied subtext. The first paragraph implies that a fwupd build can rebuild flashrom as well. Interesting. In that case a Meson wrapper for Makefile might satisfy your requirements in principle, but not in spirit. For the subtext of the last sentence I'm not sure if the intended understanding was "use Meson or we'll drop flashrom" or "give us a way to keep our CI running with flashrom" or something entirely different. Sorry, English is not my native language. I'm trying understand if this is a technical (something doesn't work) or social (something is frustrating) problem or both. Analyzing your statement above with the linguistic tools of Schulz von Thun and Watzlawick gave me the impression that I'm missing something here.
- Native support for most non-Linux platforms I keep hearing this, but haven't got any actual data -- is there any reason why the meson build system wouldn't "just work" with *BSD/Win32/macOS?
Someone would have to test it and document it. This also includes crossbuilds for MacOS and DOS on Linux which are both supported with Makefile. Documentation for the various Makefile based builds is available at https://github.com/flashrom/flashrom/blob/master/README . Copy/paste from a README is something that "just works". This is currently missing for our Meson build.
I think Meson was a good idea, but it failed to get traction beyond "we need it for dynamic libflashrom". I don't know how you've managed to get to "failed to get traction" given that it's being built with meson in 4 of the biggest projects (in terms of distribution, and number of deployed packages) using flashrom.
The switch to Meson in Debian has resulted in some regressions which caused people to join #flashrom IRC. Not all of the regressions were fixed. Maybe "failed to get traction" was the wrong phrase. "Nobody bothered to check the Meson build result and compare it to the Makefile reference" would be a more accurate description. This caused a mismatch between packagers picking up Meson and developers (as well as users following the documentation) still using the Makefile.
This is all so frustrating: This feels like more of an existential crisis about what flashrom actually *is* rather than a discussion about build systems.
I've seen this in many open source projects: A rewrite of some component happens, but the rewrite has a different subset (and not a superset) of features. As long as both the original and the rewritten version are available, neither side will have any motivation to make their version a superset of the features of the other side because their own use case works well. As a result, everyone is frustrated. My hope with flashrom is that it brings joy or at least works as a good tool. It is definitely not my intention to frustrate you. I would love to find a solution that makes everyone happy. Regards, Carl-Daniel
I have great news: I created items for the release in our bugtracker! Here is a parent issue “Release v1.3” https://ticket.coreboot.org/issues/353 and it has 23 subtasks. The subtasks are the items from the original starter email. Thank you so much Nico for going through the long history and making the list, that’s a lot of work and time! The very good thing is that now the big task is trackable, parallelizable and open to anyone who can join the effort. I looked into commits and gerrit reviews that correspond to those, I tried to get some context. Surely all of the descriptions can be improved, or more info can be added to issues. Especially if you are taking an issue and start working on it. Also, of course, more tasks can be added, if something is missing. Please set the parent issue #353, category “Release prep” and target release 1.3 if you add a new task. I assigned the parent issue to myself. Please tell me if anyone has objections. I did it because at the last dev meeting the community decided that I will be “release manager”. It was completely unexpected for me, but it is true to say that I very much want the release to happen. I really appreciate any help and advice from people! As a separate note, the question of meson and make has been discussed in this thread. And we now have a One Build System working group with the goal to converge two flashrom build systems into one (meson). Here is the doc with more info <https://docs.google.com/document/d/1TVso_VbrLEbGc7BNrYxqlrP8jMxB23TuMqEI3PnC...>. Everyone who is interested in contributing to the effort can join! This effort goes in parallel with release prep. I haven’t done any releases before, so tell me if I am wrong. But what I am thinking when looking at the list of issues: maybe we can have some time for “just fixing issues on master” and after that do a release branch? Does it make sense? “Some time” won’t take forever (AU winter maybe?). I have issue #353 assigned to me, so now it has to happen :) On Thu, Mar 24, 2022 at 2:34 AM Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@gmx.net> wrote:
Hi Richard,
Am 23.03.22 um 10:20 schrieb Richard Hughes:
On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
AFAIR there were three arguments for meson: - Meson build integrates nicely with other packages built by meson This means we can build libflashrom as a subproject, which means we can build the flashrom plugin even when the distro doesn't ship [a new enough] flashrom package: https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap
That's just something you can't do with the Makefile, and removing the subproject would force us to remove flashrom support from almost all the CI systems we test fwupd with.
It took me some time to understand the text of this last sentence, but I'm unsure about the implied subtext. The first paragraph implies that a fwupd build can rebuild flashrom as well. Interesting. In that case a Meson wrapper for Makefile might satisfy your requirements in principle, but not in spirit.
For the subtext of the last sentence I'm not sure if the intended understanding was "use Meson or we'll drop flashrom" or "give us a way to keep our CI running with flashrom" or something entirely different. Sorry, English is not my native language. I'm trying understand if this is a technical (something doesn't work) or social (something is frustrating) problem or both. Analyzing your statement above with the linguistic tools of Schulz von Thun and Watzlawick gave me the impression that I'm missing something here.
- Native support for most non-Linux platforms I keep hearing this, but haven't got any actual data -- is there any reason why the meson build system wouldn't "just work" with *BSD/Win32/macOS?
Someone would have to test it and document it. This also includes crossbuilds for MacOS and DOS on Linux which are both supported with Makefile. Documentation for the various Makefile based builds is available at https://github.com/flashrom/flashrom/blob/master/README . Copy/paste from a README is something that "just works". This is currently missing for our Meson build.
I think Meson was a good idea, but it failed to get traction beyond "we need it for dynamic libflashrom". I don't know how you've managed to get to "failed to get traction" given that it's being built with meson in 4 of the biggest projects (in terms of distribution, and number of deployed packages) using flashrom.
The switch to Meson in Debian has resulted in some regressions which caused people to join #flashrom IRC. Not all of the regressions were fixed. Maybe "failed to get traction" was the wrong phrase. "Nobody bothered to check the Meson build result and compare it to the Makefile reference" would be a more accurate description.
This caused a mismatch between packagers picking up Meson and developers (as well as users following the documentation) still using the Makefile.
This is all so frustrating: This feels like more of an existential crisis about what flashrom actually *is* rather than a discussion about build systems.
I've seen this in many open source projects: A rewrite of some component happens, but the rewrite has a different subset (and not a superset) of features. As long as both the original and the rewritten version are available, neither side will have any motivation to make their version a superset of the features of the other side because their own use case works well. As a result, everyone is frustrated.
My hope with flashrom is that it brings joy or at least works as a good tool. It is definitely not my intention to frustrate you. I would love to find a solution that makes everyone happy.
Regards, Carl-Daniel
-- Anastasia.
Anastasia Klimchuk <aklm@chromium.org> writes:
I haven’t done any releases before, so tell me if I am wrong. But what I am thinking when looking at the list of issues: maybe we can have some time for “just fixing issues on master” and after that do a release branch? Does it make sense? “Some time” won’t take forever (AU winter maybe?). I have issue #353 assigned to me, so now it has to happen :)
My $0.02 from dealing with various projects. Flashrom is small and I think it's best to do the release off master, getting everything done that needs to get done, and then beginning the process with feature freeze, moving to regression and doc fixes only, maybe alpha, beta, rc and then release. Only when there is a release create a branch that would be used for micro updates to the release while master is back open for development. In order to make a release it is necessary to say no to further changes. It is always possible to improve, but that leads to never releasing, and users are better served with a series of better releases, as long as each one does not have significant regressions. This is easy to say and hard to do! Creating a release branch before release means changes happen in master disconnected from release and there's backporting effort and a lot more work. Not branching incentivizes everyone to get the release done and hold their feature branches.
On Thu, 2022-04-28 at 08:22 -0400, Greg Troxel wrote:
Anastasia Klimchuk <aklm@chromium.org> writes:
I haven’t done any releases before, so tell me if I am wrong. But what I am thinking when looking at the list of issues: maybe we can have some time for “just fixing issues on master” and after that do a release branch? Does it make sense? “Some time” won’t take forever (AU winter maybe?). I have issue #353 assigned to me, so now it has to happen :)
My $0.02 from dealing with various projects.
Flashrom is small and I think it's best to do the release off master, getting everything done that needs to get done, and then beginning the process with feature freeze, moving to regression and doc fixes only, maybe alpha, beta, rc and then release. Only when there is a release create a branch that would be used for micro updates to the release while master is back open for development.
In order to make a release it is necessary to say no to further changes. It is always possible to improve, but that leads to never releasing, and users are better served with a series of better releases, as long as each one does not have significant regressions. This is easy to say and hard to do!
Creating a release branch before release means changes happen in master disconnected from release and there's backporting effort and a lot more work. Not branching incentivizes everyone to get the release done and hold their feature branches.
Good thoughts. Though, I think we shouldn't think about the actual release process too much now, because there are many issues from the past open and many questions unanswered. For now, we should just focus on indentifying major issues, fixing these and see how that goes. Moving the issues Nico mentioned to the ticket system is a good first step. It could take some time until the actual release process can start, since I think there is lots of work to do to get to this point. However, things might look totally different in some weeks or months and so I would postpone this discussion. It doesn't make much sense to me to do that now. // Felix
On Thu, Apr 28, 2022 at 9:36 PM Felix Singer <felixsinger@posteo.net> wrote:
On Thu, 2022-04-28 at 08:22 -0400, Greg Troxel wrote:
Anastasia Klimchuk <aklm@chromium.org> writes:
I haven’t done any releases before, so tell me if I am wrong. But what I am thinking when looking at the list of issues: maybe we can have some time for “just fixing issues on master” and after that do a release branch? Does it make sense? “Some time” won’t take forever (AU winter maybe?). I have issue #353 assigned to me, so now it has to happen :)
My $0.02 from dealing with various projects.
Flashrom is small and I think it's best to do the release off master, getting everything done that needs to get done, and then beginning the process with feature freeze, moving to regression and doc fixes only, maybe alpha, beta, rc and then release. Only when there is a release create a branch that would be used for micro updates to the release while master is back open for development.
I think this depends on what's happening for the release. If code is just being added, the master branch is fine. It sounded like there might be a desire to remove code to do the release. In that case it probably makes sense to get as close to the release as possible, branch, then remove any code necessary for the release to happen. After the code is removed, maybe only allow stabilization changes and bugfixes onto that branch.
In order to make a release it is necessary to say no to further changes. It is always possible to improve, but that leads to never releasing, and users are better served with a series of better releases, as long as each one does not have significant regressions. This is easy to say and hard to do!
Creating a release branch before release means changes happen in master disconnected from release and there's backporting effort and a lot more work. Not branching incentivizes everyone to get the release done and hold their feature branches.
Good thoughts. Though, I think we shouldn't think about the actual release process too much now, because there are many issues from the past open and many questions unanswered.
For now, we should just focus on indentifying major issues, fixing these and see how that goes. Moving the issues Nico mentioned to the ticket system is a good first step. It could take some time until the actual release process can start, since I think there is lots of work to do to get to this point. However, things might look totally different in some weeks or months and so I would postpone this discussion. It doesn't make much sense to me to do that now.
I agree that it's too early to actually start the release process. It's good to have a well defined process though, so that should probably start now, before it's needed. Maybe look over the coreboot release process and see what's useful to take from that. https://doc.coreboot.org/releases/checklist.html Keep in mind though that coreboot releases are more of a snapshot of the codebase at a certain point in time than an actual stabilized release, so I'd imagine flashrom might want to do something like a testing checklist. Martin
Thanks so much for your thoughts everyone! I have important information for this thread. Next flashrom dev meeting which is this Thursday (in two days), specifically: 19th May 2022, 6:00 - 7:00 am UTC+0 will be discussing flashrom release! There are two parts in the topic: next release v1.3 and also in general what approach we want to have for future releases. As you see on the meeting agenda here https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFs... Flashrom release is the first topic for 19th May. Next topic is “flashrom binaries” which is probably related to the first one. And if there is time left, the topic after that is “flashrom cross-platform build testing” which is also related. Everyone who is interested to discuss flashrom release is very very welcome to join the meeting! Also as I mentioned before, I created issues under parent task here https://ticket.coreboot.org/issues/353 (some of them already assigned to people). Alternatively you can open the list of all flashrom issues and set filters: category == Release prep && target version == 1.3 -- Anastasia.
On Tue, 17 May 2022 at 02:57, Anastasia Klimchuk <aklm@chromium.org> wrote:
Thanks so much for your thoughts everyone!
One more, if it helps. For fwupd we always have the "main" branch as "release ready" -- as in you can tag a release and drop a tarball without doing anything more than writing some release notes. This works really well for us, and most of the development is done in "wip" branches, some of which exist for months and are pushed by multiple people. For wip branches we have a policy of "no rebasing" so sometimes the wip branch gets branched into a different branch, rebased and then development continues. We only rebase the branch when merging to fix any conflicts. Having the development branch in this "always good to go" state means we can always drop a new release about once a month, and encourage downstreams to just ship the latest version, rather than telling them to cherry pick specific patches for bugs users are hitting. Just my 2p; feel free to ignore :) Richard.
On Sun, Mar 6, 2022 at 3:10 PM Nico Huber <nico.h@gmx.de> wrote:
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.
I have these applied to the OpenWrt tree: https://github.com/flashrom/flashrom/pulls/neheb . I recently rebased.
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 _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
participants (11)
-
Anastasia Klimchuk -
Carl-Daniel Hailfinger -
David Hendricks -
Felix Singer -
Greg Troxel -
Luc Verhaegen -
Martin L Roth -
Nico Huber -
Richard Hughes -
Rosen Penev -
Thomas Heijligen