# 2025-07-09 - coreboot Leadership Late GMT Meeting 


## Attendees

Mina Asante, Christian Walter, Jay Talbott, Julius Werner, Piyush Patle, 
Shaurya Rane, Werner Zeh,
Ziang Wang, David Hendricks, Jeremy Compostella, Matt DeVillier, Felix Singer, 
Andy Ebrahiem.



## Open Action Items

  * 2025-05-14
    * [Open] Martin: Review the list of people with +2 rights and update it 
before the next release.
  * 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

  * OSFC 2025 
    Dates: October 7–10, 2025



## Minutes


### [Michał Kopeć] RFC v2- Bootblock redundancy with coreboot 
* This is a follow-up to my colleague Michał Żygowski's RFC concerning 
redundancy of the bootblock, mainly on recent Intel-based platforms. We've 
taken your feedback and would like to present another proposal to you.The goal 
of this feature is to prevent accidental bricks caused by flashing a bad 
firmware image, by providing a secondary copy of boot firmware that acts as a 
fallback path for main firmware. 
  The general idea is that if a user flashes bad firmware or the update goes 
wrong, you can always restore functioning firmware by resetting the CMOS.
  On Intel, this is realized by the Top Swap mechanism, where the top range of 
the flash (of configurable size, from 64K to more than 1M in latest chipsets) 
can be swapped between two copies.
  At this point support for other architectures has not been considered, so 
initially this would be an Intel-only feature.
  I find it easiest to show an example FMAP first and then describe what's 
going on:
```
FLASH 32M {
SI_ALL 10M {
SI_DESC 16K
#if CONFIG_MAINBOARD_USES_IFD_GBE_REGION
SI_GBE 8K
#endif
SI_ME
}
RW_UNUSED 6M
SI_BIOS {
RW_MISC {
RW_MRC_CACHE 64K
SMMSTORE(PRESERVE) 256K
}
RW_PAD
FW_MAIN_B(CBFS) 6M
FW_MAIN_A(CBFS) 6M
FMAP 2K
TOPSWAP_B(CBFS) 512K
TOPSWAP_A(CBFS) 512K
}
}
```
In this example:
  - The FMAP region is not redundant and it is suggested that this region not 
change for the lifetime of the platform, to make sure the redundancy code works 
properly.
  - There are two bootblocks and two FW_MAIN sections which together establish 
Slot A and Slot B
  - Topswap regions are CBFSes that contain the bootblocks and ACMs if used by 
the build
  - ACMs are also why their sizes in this example are configured to 512K
  - SMMSTORE and MRC cache do not need to be and aren't covered by redundancy
  - Initially, the platform boots from Slot A only
  - Slot A firmware is unchanging and may be protected by chipset protection 
mechanisms (PRx registers on Intel based platforms)
  - The update flow
  - User attempts to update slot B, e.g. by flashrom
  - User sets the Attempt Slot B flag e.g. by nvramtool
  - User reboots the platform
  - Slot A firmware sees the Attempt Slot B flag, sets the Top Swap bit in the
  * PCH and resets the platform
  - Slot B firmware is booted
  - Recovery flow
  - User resets the CMOS
  - alternatively: attempt counter in CMOS, or watchdog resets the flags
  - Slot A firmware boots
  * There is also an option to have an updatable Slot A.
  - The modified update flow:
  - User initiates update of Slot B e.g. by flashrom
  - User sets the Attempt Slot B flag e.g. by nvramtool
  - User reboots the platform
  - Slot A firmware sees the Attempt Slot B flag and sets the Top Swap bit
  - Slot B proceeds to boot into the payload and assesses that the boot was 
successful as late as possible (e.g. by UEFI EBS) by setting the Slot B 
Successful flag in CMOS
  - User eventually reboots the platform
  - Slot B firmware sees the update successful flag and overwrites Slot A with 
contents of Slot B
    * [Werner] Nobody from 3mdeb in the call today so no real discussion 
possible. We try to get 3mdeb on the call for the next meeting for a more 
fruitful discussion.

### [Chris] Funding Call is still ongoing:
(https://www.osw.foundation/funding/small-scale-high-impact-firmware-contributions/)
  * Feel free to add proposals
  * In case you got any questions (scope, application, etc.) feel free to reach 
out to me (mailto:[email protected])

**Information**
  * coreboot announces tag 25.06 release. 
Find the release notes here:
(https://blogs.coreboot.org/blog/2025/07/04/announcing-the-coreboot-release-25-06/)



# Next Leadership Meeting
  * July 23, 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. 
Both sessions share the same meeting notes and Google Meet link.



# coreboot leadership meeting minutes
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to