flashrom

flashrom@flashrom.org

5 participants
9154 discussions

flashrom dev meeting notes 5.05.22
by Felix Singer 05 May '22

05 May '22

# 5th May 2022, 6:00 - 7:00 am UTC+0 Attendees: Anastasia, David, Edward, Felix, Nico, Nikolai, Thomas ## Decisions Summary * Thomas gets submit rights * We want a separate reviewers group for flashrom so that reviewers are not mixed across different projects * Different tags for bug IDs are needed so that Google IDs (non-public) are not mixed with tickets from the flashrom issue tracker (public) * The mailing list should be used more for design discussions ## Agenda * [aklm] I wanted to remind that we have an ongoing item “to figure out criteria to give people submit rights”. It was raised on the very first meeting. I think it is in many people's heads. * There is a thread on the mailing list “Gatekeeping, ACLs and Review Rules” ([link](https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/threa… )). The topic is in scope of the thread. Currently the last message is mine, I can’t just talk to myself on the topic. Please share your thoughts! * In the absence of criteria I want to nominate Thomas to get submit rights. This is also an idea from the very first meeting. * In addition to commit stats that Martin gave in the first meeting, I have more points * Thomas is active on the project for a while, * he will be a gsoc Mentor, teaching our new contributors * Reachable and responding on the irc, by email, mailing list * Yes, no objections! * We need rules for this. Not too many people should just get submit rights so that we can keep track. * Separate Reviewers group for flashrom, everyone agrees. * Nik: better have a restricted group for Reviewers, and everyone can submit. * Let’s give Thomas submit rights. Congrats! * Anything that’s left to discuss from the item: “(in case somebody knows) What is Google’s current strategy to avoid repeating mistakes of the past?” * [dhendrix] Is this the kind of finger pointing that Edward mentioned above? At this point, CrOS has proved more than happy to move upstream. The Github mirror is probably more of a concern. Perhaps upstream should consider how to get developers to choose upstream rather than the Github mirror or some other fork. * [Nico] Pointing at Google, actually. If one company forks and later wants their code upstream without proper review, something seems wrong. As if they never reflected about the problems. * [aklm] I am not sure we are on the same page on what are “mistakes of the past”. Everyone has their own idea on what the mistakes were. I can start from myself. From my observations, converging the code was considered a purely technical task, and so it was done as a technical task. However, converging the code means converging the people/the teams, converging very different workflows and work cultures. This does not seem to be thought through or ever discussed, and to me this is a mistake. * Thomas : put GOOGLE_BUG tag and BUG is for public issue tracker * Edward BUG=g:1234566,b:544 * Edward: happens more on board bringup * Nikolai: maybe keep b: prefix for google bugs BUG=b:google_id,f:flashrom_id * Felix : [https://doc.coreboot.org/infrastructure/services.html#issue-tracker](https:… * [quasisec] I am also unclear how CrOS convergence had really much of an impact on upstream considering >99% of the work was adjusting the CrOS fork to realign with upstream. Only an extremely small amount of alignment was in the form of upstream commits, e.g., missing raiden_debug and some unfortunate part of sb600spi. Is there a specific area that stands out? * [Nico] No idea if related to the original reasons for the fork, but that the convergence is stalling new releases for years stands out pretty much. * [Nico]: How can we teach developers who got to know the [Chrome OS] fork first about the upstream project (if not during review)? * [PatrickG] Once upstream-first is established, downstream patches aren’t reviewed anymore and redirected to upstream. * [quasisec] I am not sure anyone really “got to know the fork” as such. The problem was the fork was treated as a means to an end. Hence all the additional investment in improving flashrom such as life-cycle API and unit-testing to name some recent examples. Other examples include upstreaming additional hardware support such as lspcon, mst’s and raiden or later generation PCH rev’s. * [quasisec]: Regarding “teaching” can you elaborate on what this actually means as I think there is more than one dimension to the intent of that. * [Nico] I see a lack of a forum to teach people about the project. Because the mailing list is basically rejected by Google developers (with exceptions of course), and people ask to keep comments on Gerrit to very specific “actionable” items, where should we teach people about the project, how we do things and what to focus on? Etc. * [quasisec]: No one “rejected” anything, the commit you refer to Nico is here [https://review.coreboot.org/c/flashrom/+/62768](https://review.coreboot.org… and the issue is the tone of the review. I’ll leave others to judge. * Nico: we need to use mailing list for design discussions, before starting the work * Edward: how to decide what is big and what is small? * **dunning kruger effect** * Nico: early engagement before writing code. * New programmers should be discussed first. * Infra change * Change touching multiple layers * aklm: What happens when the developer has already started? * Threshold to decide whether to send a patch without any prior discussion or conversation: are you ok to re-write the patch if the idea is not supported as is? * Price of the mistake? * quasisec: how to make the price not so high that we don’t scare people away also? * Felix: mention in the guidelines , recommend to discuss on mailing list first * Aklm: this is already recommended on the guidelines * Edward: developers think in code first, they think of design and write some draft code * Nik: whatever tool works best * Felix: An account is needed for Gerrit and thus not everyone is able to join the discussion. * Aklm: for a patch you need to know whom to add as reviewers. On the mailing list, you just post, everyone reads. * quasisec: How to make things like adding programmers a bit more template’ty? Common pattern guidance? Make flashrom API’s better? * Edward: can the code say “file a bug” instead of “write to the mailing list”? * Nico: it could be another mailing list? * Edward: prefix in the subject line, so that people can filter if they want, or not do anything. Create a bug, bug updates are sent on the mailing list. User has a handle on the issue. * Felix: people need an account to create bugs on redmine, but for the mailing list no account is needed.

1 0

Updated invitation: Flashrom Dev Meeting (monthly) @ Every 2 weeks from 4pm to 5pm on Thursday (AEST) (flashrom@flashrom.org)
by aklm＠chromium.org 03 May '22

03 May '22

This event has been changed. Title: Flashrom Dev Meeting (monthly) Monthly meeting of Flashrom project developers. Meeting notes doc: https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZ… When: Every 2 weeks from 4pm to 5pm on Thursday Eastern Australia Time - Sydney Joining info: Join with Google Meet https://meet.google.com/iuf-mtri-zva?hs=224 Join by phone (AU) +61 2 9051 6791 (PIN: 304642402) More phone numbers: https://tel.meet/iuf-mtri-zva?pin=9271993818880&hs=0 Calendar: flashrom(a)flashrom.org Who: * aklm(a)chromium.org - creator * felix.singer12(a)gmail.com * david.hendricks(a)gmail.com * quasisec(a)google.com * nico.h(a)gmx.de * Martin Roth * src(a)posteo.de * martonmiklosqdev(a)gmail.com * piotr.krol(a)3mdeb.com * Maciej Pijanowski * michal.zygowski(a)3mdeb.com * th3fanbus(a)gmail.com * stefan.k.reinauer(a)gmail.com * nartemiev(a)google.com * arthur(a)aheymans.xyz * flashrom(a)flashrom.org Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmVscGY2cjNsdTZw… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account flashrom(a)flashrom.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Updated invitation: Flashrom Dev Meeting (monthly) @ Every 2 weeks from 4pm to 5pm on Thursday (AEST) (flashrom@flashrom.org)
by aklm＠chromium.org 03 May '22

03 May '22

This event has been changed. Title: Flashrom Dev Meeting (monthly) Monthly meeting of Flashrom project developers. Meeting notes doc: https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZ… When: Every 2 weeks from 4pm to 5pm on Thursday Eastern Australia Time - Sydney Joining info: Join with Google Meet https://meet.google.com/iuf-mtri-zva?hs=224 Join by phone (AU) +61 2 9051 6791 (PIN: 304642402) More phone numbers: https://tel.meet/iuf-mtri-zva?pin=9271993818880&hs=0 Calendar: flashrom(a)flashrom.org Who: * aklm(a)chromium.org - creator * felix.singer12(a)gmail.com * david.hendricks(a)gmail.com * quasisec(a)google.com * nico.h(a)gmx.de * Martin Roth * src(a)posteo.de * martonmiklosqdev(a)gmail.com * piotr.krol(a)3mdeb.com * Maciej Pijanowski * michal.zygowski(a)3mdeb.com * th3fanbus(a)gmail.com * stefan.k.reinauer(a)gmail.com * nartemiev(a)google.com * arthur(a)aheymans.xyz * flashrom(a)flashrom.org * c-d.hailfinger.devel.2006(a)gmx.net Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=MmVscGY2cjNsdTZw… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account flashrom(a)flashrom.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

MX25L12833F
by Jon Bowen 02 May '22

02 May '22

2 1

Found Generic flash chip "unknown SPI chip (REMS)" (0 kB, SPI) on serprog.
by Gabriel Lopes da Silva Saraiva 01 May '22

01 May '22

The CHIP IC is: 25QL128CSIG I submitted a ticket on github, but but the BOT shut down, I tried to submit it a second time. sudo flashrom -p serprog:dev=/dev/ttyACM0:4000000 -r file-to-save.binflashrom unknown on Linux 5.11.0-46-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). serprog: Programmer name is "stm32-vserprog" serprog: requested mapping AT45CS1282 is incompatible: 0x1080000 bytes at 0x00000000fef80000. serprog: requested mapping GD25Q256D is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping IS25LP256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping IS25WP256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25L25635F/MX25L25645G is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25U25635F is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MX25U51245G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MX66L51235F/MX25L51245G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MX66L1G45G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping N25Q00A..1G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping N25Q00A..3G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping N25Q256..1E is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping N25Q256..3E is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping N25Q512..1G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping N25Q512..3G is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MT25QL01G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping MT25QU01G is incompatible: 0x8000000 bytes at 0x00000000f8000000. serprog: requested mapping MT25QL02G is incompatible: 0x10000000 bytes at 0x00000000f0000000. serprog: requested mapping MT25QU02G is incompatible: 0x10000000 bytes at 0x00000000f0000000. serprog: requested mapping MT25QL256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MT25QU256 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping MT25QL512 is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping MT25QU512 is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping S25FL256S......0 is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping S25FL512S is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping W25Q256.V is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256JV_M is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256.W is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q256JW_DTR is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping W25Q512JV is incompatible: 0x4000000 bytes at 0x00000000fc000000. serprog: requested mapping XM25QH256C is incompatible: 0x2000000 bytes at 0x00000000fe000000. serprog: requested mapping XM25QU256C is incompatible: 0x2000000 bytes at 0x00000000fe000000. No EEPROM/flash device found. Note: flashrom can never write if the flash chip isn't found automatically. Att, Utherbone (Gabriel) <http://speedtec.gq/> <http://speedtec.gq/> <http://gabrielsaraiva.xyz/>

2 1

[flashrom - Bug #352] (New) test issue for mailing list
by Felix Singer 25 Apr '22

25 Apr '22

Issue #352 has been reported by Felix Singer. ---------------------------------------- Bug #352: test issue for mailing list https://ticket.coreboot.org/issues/352 * Author: Felix Singer * Status: New * Priority: Normal * Target version: none * Start date: 2022-04-25 ---------------------------------------- This is a test issue for the flashrom mailing list. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: https://ticket.coreboot.org/my/account

1 0

Unsupported chip AT25SF128A
by Staffan Ulfberg 23 Apr '22

23 Apr '22

Datasheet at: https://www.dialog-semiconductor.com/sites/default/files/2021-02/DS-AT25SF1… Probing for Unknown SFDP-capable chip, 0 kB: SFDP revision = 1.0 SFDP number of parameter headers is 2 (NPH = 1). SFDP parameter table header 0/1: ID 0x00, version 1.0 Length 36 B, Parameter Table Pointer 0x000030 Parsing JEDEC flash parameter table... 3-Byte only addressing. Status register is non-volatile and the standard does not allow vendors to tell us whether EWSR/WREN is needed for status register writes - assuming EWSR. Write chunk size is at least 64 B. Flash chip size is 16384 kB. Block eraser 0: 4096 x 4096 B with opcode 0x20 Tried to add a duplicate block eraser: 4096 x 4096 B with opcode 0x20. Block eraser 1: 512 x 32768 B with opcode 0x52 Block eraser 2: 256 x 65536 B with opcode 0xd8 done. SFDP parameter table header 1/1: ID 0x1f, version 1.0 Length 12 B, Parameter Table Pointer 0x000060 === SFDP has autodetected a flash chip which is not natively supported by flashrom yet. All standard operations (read, verify, erase and write) should work, but to support all possible features we need to add them manually. You can help us by mailing us the output of the following command to flashrom(a)flashrom.org: 'flashrom -VV [plus the -p/--programmer parameter]' Thanks for your help! ===

1 0

Code Reviews guidelines discussion
by Anastasia Klimchuk 22 Apr '22

22 Apr '22

Hello People, Few weeks ago at the flashrom meeting we had a discussion about code reviews and the situations that sometimes happen. We decided that it would be good to have some guidelines… and then we decided that I will start writing something. I have been thinking about it since then. I even started writing something, but I wasn’t happy at all: it felt like composing a wall of text that no one would be reading. I decided to think about: what problems are we solving? And then it got much better. I gathered the list of problems that I think are present and repeatedly happen during code reviews. All of the below is RFC and of course, if there is a problem that is missing, please tell. I would really appreciate everyone’s opinions on this! What I suggest is: after agreeing on the list of problems, compose and agree the answers to them (yes easier to say then to do :)), and then it can be like “Code Reviews FAQ” or something like that? Especially if we can encourage people to read the other point of view first. —-------------------------------------- ## Contributor point of view ## —-------------------------------------- #1 Is this comment a conversation or an action item? #2 Is this comment blocking patch from merging or non-blocking? #3 Are we waiting for anyone [else] to have a look at this patch? #4 Is my patch ready to be merged? / Why is my patch not being merged? #5 Who are the best reviewers for this patch? #6 This patch is a real emergency, what is the process for that? —----------------------------------------------------- ## Reviewer / Maintainer point of view ## —----------------------------------------------------- #1 My important comment(s) got ignored and the patch was merged regardless. #2 I have so many code reviews, and everyone wants it fast and complains reviews are too slow. #3 A patch that was merged broke something, but people don't want to revert. #4 I asked the patch owner to fix something, but they are arguing with me instead, and wasting everyone's time. #5 What this patch is doing, and why is it needed? #6 I want to review the patch, but I am busy for the next X weeks. -- Anastasia.

1 0

Unable to read “Boyamicro” SPI chip.
by Frankie LEE (HTX) 22 Apr '22

22 Apr '22

Hi, Unable to read “Boyamicro” SPI chip? Any workaround? Thanks. ============================================================================================== ack@ack:~$ flashrom -p ft2232_spi:type=2232H,port=B,divisor=4 -r firmware.bin flashrom v1.2 on Linux 5.13.0-40-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 Generic flash chip "unknown SPI chip (RDID)" (0 kB, SPI) on ft2232_spi. === This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE The test status of this chip may have been updated in the latest development version of flashrom. If you are running the latest development version, please email a report to flashrom(a)flashrom.org<mailto:flashrom@flashrom.org> if any of the above operations work correctly for you with this flash chip. Please include the flashrom log file for all operations you tested (see the man page for details), and mention which mainboard or programmer you tested in the subject line. Thanks for your help! Read is not working on this chip. Aborting.

1 0

flashrom dev meeting notes 21.04.22
by Felix Singer 21 Apr '22

21 Apr '22

# 21th April 2022, 6:00 - 7:00 am UTC+0 Attendees: Thomas, David, Edward, Nico, Anastasia, Nikolai ## Decisions Summary * Anastasia will be doing next release. She has never done release before, and needs help from more experienced people. ## Agenda * [FelixS] Redmine is ready to use * If you wonder, new registrations require an unlock by an administrator. This is to prevent spamming and bots. Maybe we can work out something better in the future. * I added additional fields to issues, so that important information is easily visible. For example affected hardware, affected OS, affected version. Please tell me if you find these useful or if you need other fields, trackers, .. * aklm: let’s start using, I will try to create an account and see how it goes * [FelixS] Created a proposal for closing GitHub issues and pull requests automatically * Closes newly created issues and pull requests and adds a comment using GitHub Actions hook. Old issues and pull requests stay untouched. * [flashrom patch](https://review.coreboot.org/c/flashrom/+/63671), based on GitHub Actions hook and [repo- lockdown](https://github.com/dessant/repo-lockdown). * My playground [https://github.com/felixsinger/awesome-repo](https://github.com/felixsinger… * [Nico] ChromeOS fork and attempted convergence * (in case witnesses of that time are present) What led to the fork? * [PatrickG] Velocity requirements: stuff needed to happen to make progress on the products using flashrom and it didn’t happen in time. Not much of a problem when it’s temporary but stuff just piled up over time. * Nico: lots of things went wrong. And it took around 8 months to converge * David: Fork happened when Carl-Daniel was the maintainer, and he was really busy. Tools were worse that time. * We had irreconcilable differences at that time * Edward: Stefan asked me to unfork flashrom. I had to work out how things were done, how to re-write parts of the system. It was just me, on my own, no other resources. I took upstream and tried to make chrome os work with upstream. Except for a few patches: mapping hack inside of sb600spi, I am trying to chase AMD to get documentation , so that I can improve it. * David: Timer stuff I was trying to deal locally. There were a bunch of things that had to be dealt locally. * David: It was uglier downstream than it should have been. Trying to minimize the number of hacks. There are things that can be tr * Edward: Where we are today: I was trying to have a team for flashrom, to spend dedicated time to work on flashrom. We had good results on that, but it takes time. Hard to allocate people. * (in case somebody knows) What is Google’s current strategy to avoid repeating mistakes of the past? * [PatrickG] Generally CrOS is willing to go upstream-first (as with coreboot) after divergence has been resolved. Depends on the upstream, so probably need to work on the questions raised by Edward et al. * [Nico] Upstream-first of a dominant vendor made it harder for others to work upstream on coreboot. It’s not what I had in mind, but this would be repeating a mistake, IMHO. * Nico: There were very good and very bad contributions during last years * Edward: how do you quantify that nothing is happening? * Nico : sb600 is bricking machines , but nothing is happening * Edward: maybe it is a visibility problem, also some things are really hard * Nico: maybe devs in google need to talk to each other? * Edward: original patch came from AMD, not from google * Nico: if it takes a long time to find a solution, maybe just revert? * Edward: we didn’t know it would take so long * David: board bringup. There is 3-4 months time before chromebooks get into users hands, and then bugs get filed. Bugs in the code which is 6 months old, but people are already reassigned to other tasks. * Edward: maybe have a parameter which turns on the behaviour, default is turned off. The problem exists, but it is not trivial. * Nico: The problem with the “upstream-first” idea: when something is not trivial, you push it upstream first, and then try to figure out how to fix it. * Edward: that was exceptional situation, it is better now * Nico: most of the issues in the list are from google. When someone looks at the code, it is clear that code it is not understood. * Edward: we opened issues about non-documented programmer, and added documentation * Nico: one of the drivers is mixing all layers of flashrom. * Nikolai: what are concerns with the code? We will try to remove them. * Edward: The datasheet was in mandarin, and lots of questions were discussed in mandarin with the vendor. Vendors were not giving documentation, despite us asking them many times. * Nico: Who is doing reviews for google? We need reviewers who know all layers of flashrom. * David: Can we simplify the process of adding a new chipset? So that it would be easier to contribute without introducing bugs? * Thomas: It would be nice to have more structure in the code repository. It is hard to understand where the code needs to go. Having a specific place for every component is a good idea * David : flash.h and flashrom.c are dumping grounds * Anastasia: Nico do you think it is possible so that we all work together normally and peacefully? If we resolve issues from the past, and also write guidelines so that new issues won’t appear and development goes normally? >> Yes it is possible. * Let's make a release! * Nico: I spent a lot of time on this already, I can’t spend even more time. Anyone else? * Nikolai: What if the vendor does not give documentation, do you think it’s better to have a driver which is not documented, or no driver at all? * David: for early chromebooks , drivers were not documented. That’s why an option was called “I want brick” * Edward: some of the changes in the chromium tree we are not sending upstream, because there is no documentation * Nikolai: Can we have a flag for situations like sb600spi ? Finer granularity than the whole driver. Feature flags? * Nico: other people work on the sb600spi code, affects everyone who works on the code. * Edward: something similar in kernel hardware quark framework. * Nico: this needs documentation, whatever is needed to understand the quark. Man pages are for the users, but there also should be documentation for developers. In what product is this chip? You can document what you know * [dhendrix] Is this the kind of finger pointing that Edward mentioned above? At this point, CrOS has proved more than happy to move upstream. The Github mirror is probably more of a concern. Perhaps upstream should consider how to get developers to choose upstream rather than the Github mirror or some other fork. * [Nico] Pointing at Google, actually. If one company forks and later wants their code upstream without proper review, something seems wrong. As if they never reflected on the problems. * [aklm] I am not sure we are on the same page on what are “mistakes of the past”. Everyone has their own idea on what the mistakes were. I can start from myself. From my observations, converging the code was considered a purely technical task, and so it was done as a technical task. However, converging the code means converging the people/the teams, converging very different workflows and work cultures. This does not seem to be thought through or ever discussed, and to me this is a mistake. * [quasisec] I am also unclear how CrOS convergence had really much of an impact on upstream considering >99% of the work was adjusting the CrOS fork to realign with upstream. Only an extremely small amount of alignment was in the form of upstream commits, e.g., missing raiden_debug and some unfortunate part of sb600spi. Is there a specific area that stands out? * [Nico] No idea if related to the original reasons for the fork, but that the convergence is stalling new releases for years stands out pretty much. * Anastasia: We currently have more GSOC project proposals than mentors (5 vs 3). If someone wants to be a mentor, it is not too late. Contact Anastasia or Felix.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom