November 2025 - coreboot - mail.coreboot.org

Jenkins on Debian oldstable vs Dockerfile on stable - update status
by ehaouas Nov. 30, 2025

Nov. 30, 2025

‌ Hello, I noticed an inconsistency in the Debian versions being used: - util/docker/coreboot-sdk/Dockerfile uses Debian stable - Jenkins continues to run on Debian oldstable with GCC-12 This issue was previously discussed in the leadership meeting, and it was agreed that Jenkins should be updated to Debian stable. However, this update still hasn't been implemented. I would like to understand: 1. What technical blockers are preventing this update? 2. Are there specific compatibility issues? 3. What is the expected timeline for resolving this? Thank you for your insights on this matter. Best regards, Elyes

1 0

2025-11-26 - coreboot Leadership Meetings Minutes
by mina＠coreboot.org Nov. 27, 2025

Nov. 27, 2025

# 2025-11-26 - coreboot Leadership Meetings ## Open Action Items * 2025-11-12 * [Done] Werner: Set up a call with Intel in early December * [Open] Martin: Will take care of patches older than a year. * 2024-11-27 * [Open] Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * [Open] Add clarification to docs: “Do not use gerrit change-id or CB: format in reference to already-merged patches.” * 2024-10-16 * [Open] Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * [Open] 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) * [Open] Daniel: Look at how we want to localize (non-console) strings for coreboot. Long-term project. ## Announcements & Events ## Late GMT coreboot Leadership Meeting Minutes ## Attendees Mina Asante, Werner Zeh, Matt DeVillier, Jay Talbott, Karthik R. ## Minutes ### [Werner] Coverity-Project is looking for some refactoring of their services. They want to understand if the projects using their services would be willing to sponsor their open program with money. * [Matt D] I’m not opposed to using coreboot’s resources to support Coverity; it’s just the question of whether we should make a donation and support their free tier or move up and use their paid services. * [Matt D] I think we should keep this discussion open for the next leadership meeting when we have a larger number of community members present. * [Werner Z] Agreed. ### [Werner Zeh] The meeting between intel and the coreboot community is scheduled for Wednesday, December 3. Further details can be found here, in an email I sent last Monday: (https://mail.coreboot.org/archives/list/coreboot@coreboot.org/thread/PKFR7R…) A calendar invite will be created, and everyone interested is welcome to join. ## Early GMT coreboot Leadership Meeting Canceled ### No issues on the meeting agenda # Next Leadership Meetings Date * December 10, 2025. * [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. We now host two leadership meetings, one in early GMT and one in late GMT, to better accommodate participants from the Asian time zones. Kindly note that both sessions use the same meeting notes and Google Meet link. # coreboot Leadership Meeting Notes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK….

1 0

[coreboot - Bug #617] (New) Missing safeguard: CBFS_SIZE greater than BIOS region in the IFD
by gaspar ilom Nov. 26, 2025

Nov. 26, 2025

Issue #617 has been reported by gaspar ilom. ---------------------------------------- Bug #617: Missing safeguard: CBFS_SIZE greater than BIOS region in the IFD https://ticket.coreboot.org/issues/617 * Author: gaspar ilom * Status: New * Priority: Normal * Target version: none * Start date: 2025-11-14 * Affected versions: main * Affected hardware: haswell ---------------------------------------- There are no effective safeguards to enforce that the `CONFIG_CBFS_SIZE` does not exceed the bios region as declared in the IFD. ### Impact - Downstream under Heads with a maximized bios region for the Haswell boards (T440p and W541) we could verify that this bug leads to an overflow when training the memory cache that makes it not work. This happens both with MRC blob and NRI and causes very slow boot times (20s) and S3 suspend/resume does not work. - Effects on other boards have not been observed but are possible. ### Expected behavior Coreboot should not build successfully if the `CBFS_SIZE` exceeds the bios region in the IFD and error out reporting the problem that caused this. ## Analysis Full details are under the PR in Heads and in particular this comment by @tlaurion https://github.com/linuxboot/heads/pull/2025/#issuecomment-3524672338 Ifttool reports a bios region of 0xBDEFFF (BDEFFF). However, the coreboot config contained: ``` CONFIG_CBFS_SIZE=0xBE4FFF ``` ``` ./build/x86/coreboot-25.09/util/ifdtool/ifdtool --platform ifd2 --layout w541_layout blobs/w541/ifd.bin && cat w541_layout File blobs/w541/ifd.bin is 4096 bytes Wrote layout to w541_layout 00000000:00000fff fd 00021000:00bfffff bios 00003000:00020fff me 00001000:00002fff gbe ``` After fixing the `CONFIG_CBFS_SIZE` the issues were fixed and fast boot with trained memory cache and S3 suspen/resume work again with NRI: https://github.com/linuxboot/heads/pull/2025/commits/9b8b9cacdcea4f67c95dce… -- 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

3 13

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org Nov. 24, 2025

Nov. 24, 2025

Dear coreboot Community, Please be reminded that our early GMT and late GMT coreboot leadership meetings are scheduled for Wednesday, November 26, 2025. [1] Kindly take a moment to update the agenda items with issues you'd like to discuss during these meetings. [2] Thank you. ## Current Agenda Items * No active issues on the agenda yet. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

coreboot architecture with signed FSP
by Werner Zeh Nov. 24, 2025

Nov. 24, 2025

Dear coreboot community, as some of you may have heard from the OSFC already, there are plans at Intel to restructure the way FSP is executed [1]. The main goal is to switch to an operation mode where only Intel signed FSP binaries can be executed. This comes, according to the current plans, with an architectural change that will affect coreboot's execution flow. In this proposed, changed execution flow a new FSP component will be loaded at reset vector and do the verification of the following FSP components like FSP-T, FSP-M and FSP-S. Then, the execution flow will continue in FSP and calls to coreboot code shall happen. In this new flow, no self-built FSP binaries can be executed anymore as they are not signed by Intel. I want to start a discussion with the community and Intel to see if we can come up with something better than this approach which will not heavily change the coreboot architecture but nevertheless provide a level of confidentiality for Intel's FSP blobs. You all are warmly welcome to participate in this discussion. Feel free to forward this invitation to anyone who might be interested. The call is planned for December 3th at 7 pm CET and will be hosted on Google Meet [2]. Feel free to join and let's have a constructive discussion. Werner [1] https://www.osfc.io/2025/talks/intel-r-signed-fsp-and-verified-boot/ [2] https://meet.google.com/kgh-nquh-usm

1 0

coreboot Meetings Announcement And Agenda Call
by mina＠coreboot.org Nov. 21, 2025

Nov. 21, 2025

Dear coreboot Community, Please note that the next leadership meetings for both the early GMT and late GMT time zones are scheduled for Wednesday, November 26, 2025. [1] Kindly take a moment to update the agenda items with issues you'd like to discuss during these meetings. [2] Thank you. Best regards, Mina. [1](https://coreboot.org/calendar.html) [2](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkK…

1 0

Curiosities of the ThinkCentre M93z with respect to the Intel Management Engine and hackability
by John Scott Nov. 19, 2025

Nov. 19, 2025

Hi, Many years ago I used to use Libreboot on a ThinkPad X200, but since then I've not been keeping an eye on the x86 firmware hacking community developments (save for the discovery of the "HAP bit" to disengage the Intel ME, which made some headlines at the time). Thus I'm not too familiar with the state of the art but wanted to share a finding that's too interesting to let be forgotten. I'm in the United States and got a Lenovo ThinkCentre M93z second hand from a local business that'd been using it: CPU: ID 0x306c3, Processor Type 0x0, Family 0x6, Model 0x3c, Stepping 0x3 Northbridge: 8086:0c00 (4th generation (Haswell family) Core Processor (Desktop)) Southbridge: 8086:8c4e (Q87) IGD: 8086:0402 (unknown) There are only a couple mentions on the internet, but when stumbling through Lenovo's manual I found that there is a motherboard jumper to disable the Intel Management Engine. (I thought these didn't exist?) Before moving the jumper over, I checked in the UEFI that it showed a version number and some other information about the Intel ME. The output of 'lspci' showed an Intel Management Engine Interface device (or something along those lines). After moving the jumper, I went back into the UEFI setup and found that the Intel ME configuration options were no longer able to be selected and the text turned light gray. The position where the version number formerly was now says "N/A", and 'lspci' shows there is no MEI device anymore: $ lspci 00:00.0 Host bridge: Intel Corporation 4th Gen Core Processor DRAM Controller (rev 06) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller (rev 06) 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06) 00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05) 00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev 05) 00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05) 00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05) 00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #5 (rev d5) 00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05) 00:1f.0 ISA bridge: Intel Corporation Q87 Express LPC Controller (rev 05) 00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05) 00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05) Isn't this neat? I don't fully understand what the implications are, such as "can this computer be liberated as much as a ThinkPad X200 can be?". So here are some additional things I've done just fooling around. The 'intelmetool' utility makes a seemingly-false claim that the Intel ME can't be killed on this system (my sole annotation being denoted by a '†' symbol): $ sudo intelmetool -s Bad news, you have a `Q87 Express LPC Controller` so you have ME hardware on board and you can't control or disable it, continuing... MEI found: [8086:8c3a] 8 Series/C220 Series Chipset Family MEI Controller #1 † This doesn't show up in 'lspci' anymore so perhaps this tool uses an indirect way to infer whether this exists? ME Status : 0x1e040185 ME Status 2 : 0x1652012e ME: FW Partition Table : OK ME: Bringup Loader Failure : NO ME: Firmware Init Complete : NO ME: Manufacturing Mode : NO ME: Boot Options Present : NO ME: Update In Progress : NO ME: Current Working State : Normal ME: Current Operation State : Bring up ME: Current Operation Mode : Security Override via Jumper ME: Error Code : No Error ME: Progress Phase : BUP Phase ME: Power Management Event : Pseudo-global reset ME: Progress Phase State : 0x52 ME: Extend SHA-256: 80e6f9c223162ef567282bdff22e274369465d7af5d6d97badb0e4a15ed79cca ME: failed to become ready ME: failed to become ready ME: GET FW VERSION message failed When passing the appropriate option to check on Intel Boot Guard (whatever that is), I find: Boot Guard MSR Output : 0x0 Your system isn't Boot Guard ready. You can flash other firmware! Also, I can use flashrom to dump the internal flash and get a seemingly-valid file: $ sudo flashrom -p internal -r ./foobar flashrom 1.4.0 on Linux 6.12.57+deb13-amd64 (x86_64) flashrom is free software, get the source code at https://flashrom.org Found chipset "Intel Q87". This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Warning: BIOS region SMM protection is enabled! Warning: Setting BIOS Control at 0xdc from 0x22 to 0x01 failed. New value is 0x22. SPI Configuration is locked down. The Flash Descriptor Override Strap-Pin is set. Restrictions implied by the Master Section of the flash descriptor are NOT in effect. Please note that Protected Range (PR) restrictions still apply. FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write. FREG1: BIOS region (0x00580000-0x00bfffff) is read-write. FREG2: Management Engine region (0x00003000-0x0057ffff) is read-write. FREG3: Gigabit Ethernet region (0x00001000-0x00002fff) is read-write. Enabling hardware sequencing due to multiple flash chips detected. OK. Multiple flash components detected, skipping flash identification. Found Programmer flash chip "Opaque flash chip" (12288 kB, Programmer-specific) on internal. Reading flash... done. I see that the 'ifdtool' utility can successfully dump information about such a flash dump. For example it says (among many other things) AltMeDisable bit is not set thus the jumper seems to be working by some totally different mechanism. That tool also hints that I have write access to all flash regions if I understand it right: Found Region Section FLREG0: 0x00000000 Flash Region 0 (Flash Descriptor): 00000000 - 00000fff FLREG1: 0x0bff0580 Flash Region 1 (BIOS): 00580000 - 00bfffff FLREG2: 0x057f0003 Flash Region 2 (Intel ME): 00003000 - 0057ffff FLREG3: 0x00020001 Flash Region 3 (GbE): 00001000 - 00002fff FLREG4: 0x00007fff Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused) Found Master Section FLMSTR1: 0x0a0b0000 (Host CPU/BIOS) Host CPU/BIOS Region Write Access: enabled Host CPU/BIOS Region Read Access: enabled FLMSTR2: 0x0c0d0000 (Intel ME) Intel ME Region Write Access: enabled Intel ME Region Read Access: enabled FLMSTR3: 0x08080118 (GbE) GbE Region Write Access: enabled GbE Region Read Access: enabled so presumably I can change attributes of the flash and maybe set the AltMeDisable/HAP bit if I so wish. So in conclusion, I don't know if there's anything groundbreaking here, but it sure would be cool if this just so happened to be a hidden gem in plain sight for tinkering with. Maybe completely free boot firmware could be made to run on it in reality as well as my dreams. Let me know what you think. Thanks

1 0

2025_11_19 coreboot Group Review Session
by mina＠coreboot.org Nov. 17, 2025

Nov. 17, 2025

Hello coreboot, Kindly note that our upcoming group review session is scheduled for Wednesday, November 19, 2025. https://meet.google.com/kpu-yozw-gtt Check the coreboot calendar for the time in your timezone: https://coreboot.org/calendar.html Here is a link to the list of patches to be reviewed this week: (https://docs.google.com/spreadsheets/d/1io-tewVlkX3PAkhR9ttCKjJXiXR9Emy6qsY…) Please add any specific patches you'd like the group to review to the top of the sheet. Since an hour may not be sufficient to address all patches on the list, reviewing patches in advance is greatly appreciated. Thank you. Best regards, Mina.

1 0

[coreboot - Bug #439] (New) Lenovo X201 Turbo Boost not working
by Lukas Karg Nov. 17, 2025

Nov. 17, 2025

Issue #439 has been reported by Lukas Karg. ---------------------------------------- Bug #439: Lenovo X201 Turbo Boost not working https://ticket.coreboot.org/issues/439 * Author: Lukas Karg * Status: New * Priority: High * Target version: none * Start date: 2022-11-18 * Affected versions: master * Affected hardware: Lenovo X201 * Affected OS: Linux, Windows, ... ---------------------------------------- -- 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 7

2025-11-12 - coreboot Leadership Meetings Minutes
by mina＠coreboot.org Nov. 13, 2025

Nov. 13, 2025

# 2025-11-12 - coreboot Leadership Meetings ## Open Action Items * 2025-11-12 * [Open] Werner: Set up a call with Intel in early December * [Open] Martin: Will take care of patches older than a year. * 2024-11-27 * [Open] Send out poll with regards to LLM usage (requested by SFC) * 2024-10-30 * [Open] Add clarification to docs: “Do not use gerrit change-id or CB: format in reference to already-merged patches.” * 2024-10-16 * [Open] Matt: Set up a meeting to discuss board status alternatives and send out invites. * Decouple data collection with uploading * Require gerrit credentials or other auth to push * Json format? * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh * 2024-09-18 * [Open] Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the meeting. Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje * 2024-05-01 * [Open] 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) * [Open] Daniel: Look at how we want to localize (non-console) strings for coreboot. Long-term project. ## Announcements & Events ## Late GMT coreboot Leadership Meeting Minutes ## Attendees Mina Asante, Jay Talbott, Werner Zeh, David Hendricks, Matt DeVillier, Julius Werner, Maximilian Brune, Alicja Michalska, Jon Murphy, Pono, Karthik R, Martin Roth. ## Minutes ### [Elyes] Can we remove OpenSBI from 3rdparty? * Currently, the 3rdparty/opensbi requires Position Independent Executables (PIEs), which coreboot does not support (https://qa.coreboot.org/job/coreboot-gerrit/285600/testReport/junit/(root)/…) * So far, coreboot has been using an old version of OpenSBI. However, this outdated version is now preventing us from updating Clang and GCC. * [Martin] What would this mean to the project? - We’ve tried updating to the latest openSBI in the past, but that was difficult, though I don’t remember why. I know that there are a couple of patches that worked towards this in the past, but I don’t know if they ever got merged. * [Max] Here is a patch to update openSBI and make it dependent on clang: (https://review.coreboot.org/c/coreboot/+/80138/9) * [Max] SBI is standard on RISC-V; we need it for all RISC-V targets (maybe just two mainboards and one emulated mainboard). Therefore, it is better not to remove it. OpenSBI does not hold us back from updating Clang. * [Werner/Matt] We will keep OpenSBI as a submodule ### [Max] Can we auto-abandon gerrit patches after a certain period of time? * Sadly, people don’t abandon their patches even if they didn’t touch them for years. That has some downsides. For example, at some point someone (I don’t remember who) removed himself from hundreds of old patches, which caused them to go back to the top of the list in gerrit. It's also useful to have a more sane list of open patches for searching purposes. I also sometimes just forget about patches, so it would be nice to get a notification from gerrit. * [Martin] We used to do this, but when we moved to the main branch from master, it reset the dates for all changes. It’s probably been long enough that we can abandon anything older than a year again. I’ll take care of that. - Another issue is that we’d like to get patches merged instead of just abandoning them. This involves people taking over old patches. We’ve addressed a lot of the outstanding core coverity issues, so maybe we can use every other review session (Wednesdays that we don’t have leadership meetings) to look at abandoned patches that could be revived and taken over. * [Matt] Should we implement a linter test to throw a warning when no “TEST=” line is available in a patch commit message? We could encourage this even in the Gerrit guidelines to help others to reproduce tests when a patch is taken over by somebody else. * Matt will have a look and take care. * [Alicja] This is a simple chip ID patch: (https://review.coreboot.org/c/coreboot/+/89157) However, buildtest complains about chromebook bootblock builds (size of bootblock too big). * [Max] This happens every now and then; no clue what goes wrong. * [Julius] There are many reasons why this can happen, as the bootblock size is limited due to early memory size constraints. This is nothing chromebook specific. * [Max] Can the SRAM size be extended to make the bootblock fit? * [Julius] Not always; news to be treated case-by-case * [Alicja] What to do when this happens on an unrelated patch? * [Julius] Reach out to the maintainer (from the maintainers list) of the failed board and ask for help. If there is nobody there, reach out to me for Chromebooks * GOOGLE MEDIATEK-BASED MAINBOARDS * M: Chen-Tsung Hsieh <chentsung(a)google.com> * M: Hung-Te Lin <hungte(a)chromium.org> * M: Yu-Ping Wu <yupingso(a)google.com> * M: Yidi Lin <yidilin(a)google.com> * S: Supported * F: src/mainboard/google/asurada/ * F: src/mainboard/google/cherry/ * F: src/mainboard/google/corsola/ * F: src/mainboard/google/geralt/ * F: src/mainboard/google/kukui/ * F: src/mainboard/google/oak/ * F: src/mainboard/google/rauru/ * F: src/mainboard/google/skywalker/ * [David] Could we switch to SFDP for those boards? This would cut down the chip ID array and therefore save space in the bootblock * [Julius] SFDP has disadvantages, too, as you need to query the SPI chip for the information in every stage. ### [Werner] How to deal with the signed FSP approach from Intel * As presented at the last OSFC (https://www.osfc.io/2025/talks/intel-r-signed-fsp-and-verified-boot/) Intel has plans to only execute signed FSP binaries. The current approach from Intel will heavily affect coreboot’s architecture. Can we start a discussion on how to deal with this? * [Jay] Ravi agrees that there need to be an exception for some users that are not able to use the new boot flow. It seems to be heavily pushed from the PC ecosystem * [Werner] We should start to work on this. Interested parties are Google, 9elements, SysPro, Martin, and Matt. I will set up an initial call with Intel in early December to start the discussion between Intel and the community. * [Martin] We can set up a CBFS mechanism to verify a binary before it gets loaded against a signature provided. * [Jay] We need the ability to build our own FSP for reasons. * [Martin] You have a license; go and sign it with your key ### [Martin] Cisco Meraki ignoring the GPL * The issue with Cisco devices that used coreboot that didn’t get the source code released is still present. The SFC isn’t interested in a lawsuit, but Hal Martin would still be interested in pursuing something if he can. How do we want to address this? Obviously it’d be better if Cisco just released their source code as they did once previously, but they haven’t responded to queries to release the source in several years * Do we want to help Hal with his legal campaign? * Help raise funds? * Donate money to his cause? * Do we want to just make this as public as possible and try to shame Cisco into releasing the source? * Publicize this widely on the blog, twitter, press releases, etc. * Add a webpage of companies that we know won’t comply with the GPL * Other ideas? * Or do we just want to ignore the issue? * [Matt] Public shaming (e.g. a blog post on phoronix) won’t hurt; maybe add a “hall of shame” on the coreboot webpage. * [Jon Murphy] Set up a letter on openletter.earth might help * [Werner] I do like this idea. * [Martin] Sure, let’s reach out to Hal and propose this. * [Werner] Will ask if FSFE has interest in this, too * [Pono] SFC does not want to have a lawsuit, but we can look into other opportunities we might have. * [David] Be careful - it might look bad if people wonder why (https://coreboot.org) isn't taking action financially, leaving it to some dude to do the dirty work. ## Early GMT coreboot Leadership Meeting Minutes ## Attendees Mina Asante, Werner Zeh, Jon Murphy. ### No issues on the early GMT meeting agenda. # Next Leadership Meetings Date * November 26, 2025. * [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. We now host two leadership meetings, one in early GMT and one in late GMT, to better accommodate participants from the Asian time zones. Kindly note that both sessions use the same meeting notes and Google Meet link. # coreboot Leadership Meeting Notes https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgK….

1 0