coreboot

coreboot@coreboot.org

6 participants
39685 discussions

2024-10-02 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 03 Oct '24

03 Oct '24

# 2024-10-02 - coreboot Leadership Meeting ## Attendees Felix Held, Alicja Michalska, David Hendricks, Matt DeVillier, Maximilian Brune, Werner Zeh, Mina Asante, Martin Roth, Jonathon Murphy, Felix Singer, Julius Werner, Karthik Ramasubramanian, Jeremy Compostella. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out invitations for this meeting. * Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico:(https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [jpmurphy] Have we solicited or received feedback on why organizations choose not to use coreboot? * Have we solicited or performed technical analysis of how we compare to other solutions or what features may be missing? * David: Were we supposed to set up a meeting to discuss ideas? * Intel was pushing slimboot - BSD licensed. * Do we know how much slimboot is used? * Werner: 2 years ago it was being used because of the license reason. More than 90% of contributions were made by intel employees. The main intel contributor has left the project. It doesn’t look like there’s a community there at all. No guarantee that the project will persist if intel decides to drop it. Based on the BSD license there’s not much of a chance that a healthy community will evolve. With intel’s current financial issues, it’s even less likely. * Max: I’m not hearing anything about slimboot anymore. * Martin: Inertia * Martin: UEFI is more expected, has larger IBVs. * The silicon vendors push the IBVs - AMI, Insyde, Phoenix. * ODMs just go with their relationships with the IBVs. * Developing on your own is hard * Complexity/inflexibility of FSP. It's hard to justify coreboot + FSP when FSP requires its own set of custom patches and hacks to change its default behavior. * Alicja: I believe we need something that can configure the platform options at runtime (writing to CMOS/SMMSTORE) instead of setting options at build time, many people using Chromebooks with Matt's builds complain about "lack of features". * Can anyone look further into this? ### [Werner] Present the workflow for Feature Request and Implementation which is an outcome of one of the OSFF’s workstreams. * There are tasks around streamlining feature implementation requests to make it more plannable for business use cases. Werner took it as an AI. Website: (https://opensourcefirmware.foundation/workstreams/feature-request-flow/) Specification: (https://drive.google.com/file/d/1su3s93xNgqy9AixDfHEWGrB_1nxYbQoz/view) * This process has been reviewed by a number of coreboot and OSFF community members from a number of companies. * This would not be required to add a feature, but is intended simply to help the project and feature implementers work through the process. * The point of this is to provide a timeline and a better guarantee that the feature would be accepted by the community. * Felixh: Who is doing the work to implement the feature? * This is not restricted by the process. Most of the time it would be the requester. * Felixh: The “guarantee” of acceptance is very concerning. I’m worried that companies will demand that their patches get rubber stamped. * That’s absolutely not guaranteed by this process. The idea is that a specification would be agreed upon, to facilitate the merging of features. The time to reject a feature is early in this * Max: Who decides when to transition between phases? * Werner: It differs between phases. One way is when the community and requester are in sync. In the implementation phase if the feature complies with the design document (this is decided by the implementation team). There are also suggested timelines. * Max: There are a number of feature patches where the idea is good, but the implementation doesn’t fit coreboot well. How do we avoid merging poor patches? * Werner: That’s why the community needs to be involved in the implementation phase. Full features shouldn’t just be dropped into the tree. * David: Agreed, even if an implementation isn’t perfect, it may be better to get it in then fix it rather than just letting it bitrot. * FelixH: If things are being done behind closed doors, this process may not work. * Martin: Behind closed doors should be a big exception. Let’s see how this goes. * Werner: I can look at creating a feature design template from the OSFF. We can also have a dashboard of features that are ongoing and what phase they’re in. There are a lot of things to improve in the ecosystem. * Martin: How to give feedback: * Werner: Send an email or review on the google [doc](https://docs.google.com/document/d/1zZvnoJwAKX7bm80UxPwnHMfelvoqoYbxR1…. Feedback is welcome. ### [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach. * 2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id. * Jon: We’re going to try to make the bugs public and update gerrit. Can we add a rule to link to the bug? * Martin will work with the other admins to make this work. * CrosBug? * BUG=b:? * CB-Bug - For coreboot bugs? * Werner: Please respond to the poll about how to respond to coverity issues. * (https://rallly.co/invite/1c8J3azXAcje) ### David: We had to take an action with a community member’s behavior. Details are on the mailing list. David will respond to various questions on the mailing list. * If anyone is feeling anxiety about dealing with other people in the community, *please* reach out. You can email anyone on the leadership team or the arbitration team. These issues will be kept confidential. (https://coreboot.org/leadership.html) ### Granite rapids patches are out! Great job getting these out before the chip is out. * FelixH: These are great and very appreciated. It’s obvious that a lot of work went into trying to improve things. # Next Leadership Meeting * October 16, 2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 30 Sep '24

30 Sep '24

Dear community, Please be reminded that our coreboot leadership meeting is scheduled for Wednesday, October 2, 2024.[1] Kindly review the current agenda and share your thoughts or suggest additional items you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda Items ### [jpmurphy] Have we solicited or received feedback on why organizations choose not to use coreboot? * Have we solicited or performed technical analysis of how we compare to other solutions or what features may be missing? ### [Werner] Present the workflow for Feature Request and Implementation which is an outcome of one of the OSFF’s workstreams. ### [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach. * 2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 27 Sep '24

27 Sep '24

Dear community, Our upcoming coreboot leadership meeting is scheduled for Wednesday, October 02, 2024.[1] Kindly take a moment to update the current agenda with matters you wish to see discussed during the meeting.[2] Thank you. Best regards, Mina Asante. [1](https://coreboot.org/calendar.html). [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK….

1 0

2024_09_25 coreboot Group Review Session
by mina＠coreboot.org 27 Sep '24

27 Sep '24

Hello coreboot! Our next group review session is on Wednesday, September 25, 2024: https://meet.google.com/kpu-yozw-gtt Please check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html As usual, we'll begin by reviewing a few patches together, then switch to individual reviews. However, everyone will still be available if you have questions about the patch you're reviewing. Here’s the link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Kindly add any specific patches you'd like the group to review to the top of the sheet. Given the limited time for our review session, any reviews completed beforehand would be greatly appreciated. Thank you. Best regards, Mina.

2 1

links for "board-status" not found
by lödur 23 Sep '24

23 Sep '24

Hello, on page: https://coreboot.org/status/board-status.html the both links for "a tool in the coreboot repository" https://review.coreboot.org/plugins/gitiles/coreboot/+/HEAD/util/board_stat… "board status repository" https://review.coreboot.org/plugins/gitiles/board-status/ point to "Not Found" Could you repair these links, please. Thanks, loedur

2 1

Re: Could not find a bounce buffer... Payload not loaded. Intel 440BX/LX Board
by Branden Waldner 22 Sep '24

22 Sep '24

Hi Christian, Both Keith Hei and I [Branden] have 440BX boards that still run up-to-date/recent coreboot (though they do need a bit of work). I also have an Intel 440LX board [Trigem Florida-TG (COGNAC)] that I was intending on trying to get coreboot to run on yet, but I wanted to get it reworked at the local maker/hackerspace to socket the flash chip which I haven't been able to get done. From old messages on the mailing list, it looked like the 440BX code did run on the 440LX and I have had it run at 66MHz fsb speed on the 440BX. Though maybe the memory settings could be an issue if the ram is rated for faster than the [older] chipset can handle (I'm not sure about the details of it)? I probably can't help much though and Keith has been working on a Haswell board recently, so I'm not sure how much time he has had to work on the older boards. I just figured I make sure to mention it at least. Branden PS Necroware on Youtube / scorp on Vogons forum has the same board as you [in the video: Too nice to be true? Intel i440LX was upset about my plans] and has expressed interest in open source works, so maybe he might be interested as well? I haven't tried messaging him about it.

2 1

Gerrit Gitiles is back - for now
by Felix Singer 20 Sep '24

20 Sep '24

I've just enabled Gitiles again. We will observe which effect this has on Gerrit now. Fingers crossing that it won't cause a high load anymore :) Felix

3 4

2024-09-18 - coreboot Leadership Meeting Minutes
by mina＠coreboot.org 19 Sep '24

19 Sep '24

# 2024-09-18 - coreboot Leadership Meeting ## Attendees Ron Minnich, Felix Singer, Julius Werner, Felix Held, Matt DeVillier, Nico Huber,Jon Murphy, Werner Zeh, David Hendricks, Mina Asante. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit ## Open Action Items * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out invitations for this meeting. * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-01-10 * Nico:(https://review.coreboot.org/q/topic:enforce_region_api) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project. ## Minutes ### [Martin] How do we want to handle code written with copilot or other AI tools. * We don’t currently have a policy, and it seems like we should. * [Matt] Code generated by AI is not copyrightable. Submitters should stay responsible for their code, regardless how it was created. * [David] Would be polite if the author mentions in the commit message that AI was used to create (parts) of the code. Still DCO should cover the legal parts of this discussion. Therefore, we do not need a dedicated policy for that. * [David] We should try to leverage AI possibilities in our project. As Bryan @ Oxide observed, open source code are by nature documented better than proprietary firmware (as far as LLM training goes) and this can be an advantage of coreboot. * [Nico] Can this make it easier to violate the DCO using AI? Should we try to improve the awareness in the community? * [Matt] The AI can spit out license-incompatible code and this way could make it into coreboot’s code base. * [Matt] Update the DCO to include that the comitter has to ensure that the added code from AI is compliant to our license. * [David] Are there filters available at the AI side to ensure output is license compatible? * [Julius] We could ask the SFC for help from the legal standpoint →[David](mailto:david.hendricks@gmail.com) will ask ### [jpmurphy] What are the coreboot projects goals? * Individuals and companies have their own goals. Do we have wider goals from the project’s point of view? * [David] This is a huge topic. Should we start a doc and just collect things there? * [Ron] Initial goals of linuxbios were: maintainability, security reliability * Goal was to have computers shipped with coreboot, not to retrofit machines like buying a Wintel PC and installing Linux on it. * [Werner] Get adoption by big vendors earlier, the rest will fall into it. * [Nico] For an early vendor adoption, we need to be able to boot into Windows as a first class citizen * [FelixH] UEFI way of booting an OS is de facto standard in the client space. We could counter this with EDK 2 but somebody should take the time to work on this. * [David] There are a number of different solutions to boot Windows (Universal Payload, EDK 2, Yabits and Rust Hypervisor (Akira's projects)), has somebody had a closer look? If the goal is to boot into EDK2, why bother with coreboot at all? * [David] Multiple architectures and boards in a single codebase - LinuxBIOS started with PPC, Alpha, and x86. Support for ARM helped get Intel to support coreboot. EDK2 is a fork-per-product sort of deal. * [Werner] We should continue the task of re-building coreboot’s webpage. Gather all the requirements and reach out to some company that can do the work based on our requirements. Preserve a section in this webpage where real uses-cases can be added to to make coreboot’s use cases popular. * [FelixH] Simplified architecture, not bloated like EDK2 with its dispatcher, dynamic module loading, etc. ### [jpmurphy] How do we want to manage a roadmap? * Can we start a draft of a roadmap to at least start gathering a list of features/tech debt and their priorities? * [FelixH] Writing up a roadmap does not mean the features will be implemented. Who will make sure that we stick to the planned roadmap? * [Jon] We should have at least a list gathered so that we can plan * [FelixS] We have too many communication channels, keeping track can be quite challenging. * [Werner] Use a kanban board to publish and track progress of features? * Better look/feel than tickets. * [Werner] The coreboot project has a few different communication channels around (mailing list, Slack, Matrix, IRC, Google docs, Discord) All our discussions happen spreaded among those and there is no central place (accepted by all community members) where decisions are written down. * Mailing list seems suitable as it has an archive but some people opted out due to heated discussions and other issue we had in the past. * Google docs could be one place but unfortunately not every community member likes them. In addition, despite the meeting minutes, there is no “official” document where centric decisions are written down, one has to search in the archive to find things. * Slack/Matrix are not used by everyone. * IRC is not suitable for such things as well. * Would a kanban-style board be something we like to have a look into for such things? I know, ranting about too many communication channels and then adding another one isn’t the best move. But still, let us at least discuss. * Possible open source boards we can have a look at: (https://kanboard.org/) and (https://wekan.github.io/). It might be easier to maintain a feature roadmap this way, IMHO. And we can host it on coreboot.org to have full control over it. * [FelixS] I suggest using [forgejo for kanban boards](https://forgejo.org/docs/latest/user/project/) instead, since I’ve suggested it as an issue tracker before and it got positive feedback. Both, issues and kanban, are very well integrated. So we reduce the number of services. ### [jpmurphy] We get coverity results for free from synopsis. At the time of writing, there are 705 outstanding defects. Do we have a plan for burning these down? * (https://scan.coverity.com/projects/coreboot)? * Can we set a bar to burn these down by a certain date, and then moving forward we require that the defect count is 0 prior to releases? * [FelixH] Can we export the coverity results and show them in a coreboot-driven dashboard so that everybody can have access? * [Jon] Set up a dedicated meeting to discuss this? * [Werner] I can send out an invite to discuss this. ### [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach. * 2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id. # Next Leadership Meeting * October 2,2024. * [coreboot Calendar](https://coreboot.org/calendar.html). # Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.

1 0

Announcement: Introducing UEFI Capsule Update Integration for coreboot with EDK II
by Beata Skierka 18 Sep '24

18 Sep '24

Hello, We are pleased to announce the launch of a project by 3mdeb aimed at integrating UEFI Capsule Update for coreboot with EDK II as a payload. This initiative aims to bring the capsule-based update method, providing an alternative to the traditional flashrom-based method, which becomes more and more difficult to implement, due to the restricted OS-level access to the firmware storage. One of the main goals is also to ease the integration and firmware update deployments via the fwupd for devices running open-source firmware (based on coreboot + EDK II). For a detailed project outline, please visit our Dasharo documentation [1]. We are looking for feedback through comments on this thread or via the built-in discussion module on the website. Although the project plan has been already accepted by the NLnet Foundation, there may be still some room for justified changes. You can track project's progress via the GitHub Project [2]. Your feedback and participation would be much appreciated. We welcome your involvement in discussions, reviewing, and testing. You might already have seen some first patches as a results of this project getting started, such us: - https://review.coreboot.org/c/coreboot/+/82247 - https://review.coreboot.org/c/coreboot/+/82248 - https://review.coreboot.org/c/coreboot/+/82249 - https://review.coreboot.org/c/coreboot/+/82610 We acknowledge and appreciate the funding support from the NLnet Foundation. [1] https://docs.dasharo.com/projects/capsule-updates/ [2] https://github.com/orgs/Dasharo/projects/7/views/1 Best regards, Beata Skierka Project Manager https://3mdeb.com | @3mdeb_com

8 18

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org 16 Sep '24

16 Sep '24

Dear coreboot community, Please be reminded that our leadership meeting is scheduled for Wednesday, September 18, 2024.[1] Kindly review the current agenda and share your thoughts or suggest additional items you would like to see discussed during the meeting.[2] Thank you. ## Current Agenda ### [Martin] How do we want to handle code written with copilot or other AI tools. * We don’t currently have a policy, and it seems like we should. * [jpmurphy] What are the coreboot projects goals? * [jpmurphy] How do we want to manage a roadmap? * Can we start a draft of a roadmap to at least start gathering a list of features/tech debt and their priorities? * [jpmurphy] Have we solicited or received feedback on why organizations choose not to use coreboot? * Have we solicited or performed technical analysis of how we compare to other solutions or what features may be missing? * [jpmurphy] How do we utilize the OSFF to obtain NDA’s with SoC vendors and provide early silicon support? * [jpmurphy] I opened a bug within Google to update our best practices on bugs being used with coreboot. There are at least two options, asking for feedback/alternatives: * 1. Use a public component that everyone can see accessible at <code>(https://issuetracker.google.com/)</code> * <code>Some bugs will still need to stay private to protect business needs and may create the need for secondary bugs. For this reason, some Googlers prefer we not use this approach.</code> * <code>2. Instead of using BUG=b: fields within commit messages, googlers could use a different ID to make it more clear it's a Google bug. Felix S had suggested ChromeOS-Bug-Id</code> * <code>[jpmurphy] We get coverity results for free from synopsis. At the time of writing, there are 705 outstanding defects. Do we have a plan for burning these down?</code> * <code>(https://scan.coverity.com/projects/coreboot)?</code> * <code>Can we set a bar to burn these down by a certain date, and then moving forward we require that the defect count is 0 prior to releases?</code> ### [Werner] The coreboot project has a few different communication channels around (mailing list, Slack, Matrix, IRC, Google docs) All our discussions happen spreaded among those and there is no central place (accepted by all community members) where decisions are written down. * Mailing list seems suitable as it has an archive but some people opted out due to heated discussions and other issue we had in the past * Google docs could be one place but unfortunately not every community member likes them. In addition, despite the meeting minutes, there is no “official” document where centric decisions are written down, one has to search in the archive to find things * Slack/Matrix are not used by everyone * IRC is not suitable for such things as well In addition, I agree with jmurphy’s points above, we do not have a plan for a roadmap. Would a kanban-style board be something we like to have a look into for such things? I know, ranting about too many communication channels and then adding another one isn’t the best move. But still, let us at least discuss. Possible open source boards we can have a look at:(https://kanboard.org/) and (https://wekan.github.io/) It might be easier to maintain a feature roadmap this way, IMHO. And we can host it on coreboot.org to have full control over it. ## Announcements & Events * OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit

1 0

← Newer
1
2
3
4
5
6
7
...
3969
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot