# 2024-07-24 - coreboot Leadership Meeting


## Attendees
Martin Roth, Felix Singer, Felix Held, David Hendricks, Marshall Dawson, 
Maximilian Brune, Lean
Sheng Tan, Nico Huber, Matt DeVillier, Werner Zeh, Paule Panter, Ron Minnich, 
Julius Werner, Jason
Glenesk, Mina Asante.



## Announcements & Events
  * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA
    https://sfconservancy.org/fossy

  * COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04
    https://coscup.org/2024/en/landing

  * OSFC will be in Bochum Germany - September 3-5
    https://www.osfc.io

  * OCP Global Summit: San Jose, California on October 15–17, 2024
    https://www.opencompute.org/summit/global-summit




## Open Action Items
  * 2024-05-01
    * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to 
translate to Russian (?)
  * 2024-03-20
    * Martin:To Add a note to the gerrit guidelines to email the leadership for 
further discussion and guidance when code submissions are not up to standard.
  * 2024-03-06
    * Martin: To update gerrit contributing guidelines documentation.
      (https://doc.coreboot.org/contributing/index.html)
  * 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


### [Elyes] Submodules
  * chromeec and opensbi are a pain (#83466 and #83464 ) 
Not only they have not been updated for more than two years, they can block 
future improvements (as
testing & prepare for C23 see
(https://qa.coreboot.org/job/coreboot-toolchain/1646/testReport/junit/(root)/clang/EMULATION_QEMU_RI
CV_RV64_/) )
  * [Martin] I did a little work towards this a while back, looking at fixing 
chromeec by turning it
from a submodule into something more like what we do for payloads. This would 
let different
mainboards specify different versions. Unfortunately, this makes the CI very 
difficult, as one
platform could check out a different version as another platform is building it.
    I’d suggest we just abandon chromeec from the build completely. Even Google 
never used it as a part
of the coreboot build.
  * Julius mentioned that there was recently a discussion inside google about 
using the shared
header.
    * Martin: The chromeEC submodule is huge and in my opinion we should just 
continue copying the
single header file.

* Decision: Drop ChromeEC submodule from coreboot.

    * [Max] regarding OpenSBI: The pain point is mostly 
src/arch/riscv/opensbi.c since it includes the
sbi/fw-dynamic.h from the opensbi repo. I feel the pain since I have had 
trouble with it in the
past too. There are 3 solutions I can think of. 
      1. We remove it and merge 
[https://review.coreboot.org/c/coreboot/+/83284] I will try to merge it
anyway, since vendors tend to fork OpenSBI rather than upstreaming it.
      2. We rewrite src/arch/riscv/opensbi.c to not include the opensbi header. 
Shouldn’t be too hard to
add the structs and types that we need ourselfs. 
      3. We remove it and implement our own SBI implementation (very unlikely)
    * Ron (mostly) revived the SBI functionality from 10 years ago. The idea to 
remove the openSBI
header is a good one.
    * Max - there are only a couple of structures we need. Will prepare a patch 
this week.

### [Elyes] prepare for experimental and incomplete C23
  * If we opt to test and prepare for C23, and if we have to choose one 
functionality, would it be
the use of nullptr constante and nullptr_t type ?  (N3042) see
[https://review.coreboot.org/c/coreboot/+/83459/8]
Is that the right way?
  * One more question: If you have to choose only one “thing” that would 
improve the coreboot code
(ISO C11 / 17) what would it be? 
    * [Max] As a side note: If we use C23 I would like to make use of some of 
its features in coreboot
code in general. For example using the “#embed” for our unit tests and using a 
separation to write
long memory addresses (e.g. write 0xFFFF_FFFF instead of 0xFFFFFFFF)
  * Julius: I’d advocate we don’t do this - this is something brought in from 
c++ to address things
that aren’t generally applicable to coreboot. It’d be very intrusive.
  * Ron: Unless there’s some benefit that we don’t currently see, what’s the 
point?
  * Julius: There’s no objection to using C23 in general, but the nullptr_t 
type doesn’t gain us
anything. Max++

* Decision: Not looking to pursue this currently. 

### [Sheng] RFC for UPL support patch by Max
  *[https://review.coreboot.org/c/coreboot/+/76591]
  * Please review.
    * Matt: Some of the names could be improved.
    * Martin: Let’s put this discussion off until next week - I’ll make sure 
that it’s in the list of
patches to review.
    * UPL Spec is in github - please contribute.
    * [https://universalpayload.github.io/spec]
    * U-boot support: 
[https://patchwork.ozlabs.org/project/uboot/list/?series=416058]
    * Edk2 as well. Linuxboot will follow after

### [Nico] Flashprog releases and HW support
  * Flashprog does regular releases now. Is it ok to announce them on the 
coreboot ML (about every
3~4 months)? Just checking if anybody has feelings against it…
    * Probably a little more delicate: What to do about stale "Flashrom 
support" lines in docs and
board_info.txt where it's known broken? remove? replace w/ Flashprog? do 
nothing?
    * Martin: Let’s add a line for flashprog support. If flashrom is broken on 
a platform mark it as
no.
    * David: Do we want to create a CSV list for flash programs instead of 
separated lines?
      * Martin: this seems reasonable to me.
      * Nico: We’d need to update the various scripts to generate the website 
and lint the file. Nico can
take a look at this.
      * Matt: Sure, we can even add non-open firmware flash packages.




# Next Leadership Meeting
  * August 7,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.



# coreboot leadership meeting minutes
[2024-07-24](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit?pl=1)
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Reply via email to