# 2022-02-23 - coreboot Leadership Meeting Minutes

## Attendees:

Felix Singer, Jay Talbott, Werner Zeh, Martin Roth, Ron Minnich, Eric
Peers, Piotr Krol, Felix Held, Jason Glenesk, Subrata Banik, David
Hendricks, Marshall, Sheng, Tim C.


## Key Decisions:

* coreboot would like to apply for Google Season of docs, but needs
someone to run the project.
* The documentation menu is being reworked.
* No decision made at this time about CB:62013. It would be nice to make
  it easier to support chips building from outside of the existing
  codebase, but that encourages not pushing those changes back to
  coreboot.  If/When we do make this easier to support, please don't use
  weak externs.


## Minutes:

* [FelixS] [Season of Docs
  
2022](https://opensource.googleblog.com/2022/02/Announcing%20Season%20of%20Docs%202022.html)
  application phase starts on 23.02.
    * Martin will ask around to see who would be interested in running
      this for coreboot.  TimW expressed interest in it last year, so we
      can start with him.


* [Jay] Support for 1st/2nd gen Xeon-SP (Sky Lake / Cascade Lake) on OCP
  Tioga Pass.
    * Facebook & Intel had put together a POC for 1st Gen, and showed it
      at a couple of events.  FSP was hacked together and was not going
      to be published.  coreboot code is present and is ongoing for
      future platforms.  SysPro was hired by ITRenew to port the Gen3
      code back to gen 1 & 2.  ITRenew was just bought out by Iron
      Mountain, and that line has been scrapped.  Funding has been lost,
      so SysPro will be shelving this until someone else funds it.
      Creating the FSP under agreement with Intel, which will also not
      be going forward.
    * David - Tides may turn again.  That had been ITRenew’s model and
      they found that reselling the servers for use can earn a lot more
      $$$ then selling discrete parts. Maybe the parts shortage changed
      this...
    * Send to mailing list.  Check with OCP to see if anyone there is
      interested in finishing the project.
    * Can’t really hand off the project to anyone else easily - FSP is
      under contract between Intel & SysPro. But coreboot can be
      developed by anyone.


* [Subrata] Like to discuss about
  [CB:62013](https://review.coreboot.org/c/coreboot/+/62013) ( a problem
  highlighted by Intel for early SoC development using downstream
  coreboot, will share more lights if get chance to talk during meeting)
    * Having the device IDs in common code causes rebase issues when
      developing a new SOC internally before the information can be
      released.
    * The patch may help intel development, but this also allows the
      vendors to avoid downstreaming the code.
    * [David] this is definitely a common problem in development.
    * [FelixH] Unless there’s a definite technical reason, it’d be
      preferable to keep it in the common code.  It’s not too difficult
      to keep the patches in sync by rebase every once in a while.
    * [Werner] Let’s try to point to a better way of doing open
      sourcing.
    * [David] How do we get vendors like Intel & AMD get to a state
      where they can more easily push code upstream before their
      platform is released?  Is there a model to reduce needed diffs to
      common code when a new product goes upstream?
    * [Marshall] Is the problem that this is solving an embargo problem?
      Is it that companies would keep code internal forever and not
      publish it to the coreboot codebase?
    * [Subrata] Not really an embargo issue, though David’s point is
      valid.
* In the patch train, there’s a comment that talks about the
  early development problem.
* For meteor lake, intel copied the current code a while back,
  and branched it off into a separate SOC.  This makes rebasing
  issues difficult.
* To make this easier, moving things to the SOC code out of the
  common code.
* Keeping the device ids in common code pollutes the namespace
  and causes code to have to loop through all of the device IDs.
    * Weak externs cause a lot of issues because you can’t easily tell
      where the code is coming from.


* [MartinR] 4.16 release is coming along - should be done today or
  tomorrow.


* [Felix S] Reworking the menu of doc.coreboot.org. More patches will
  follow
  
[https://review.coreboot.org/c/coreboot/+/62219](https://review.coreboot.org/c/coreboot/+/62219)


* [Martinr] Coverity builds have been having issues.  When the Go code
  was added to the coreboot build, that messed up the analysis for a
  while.  We got that fixed at the beginning of february, but coverity
  updated their toolchain, and things are getting stuck again.  Martin
  is working on getting this going again.


* [MartinR] Adding a tool to jenkins to scan the codebase for broken
  links.
    * Lots of broken links found, especially in the wiki.


* [Subrata] Requested help a couple of weeks ago to drop APIs from FSP.
  2 already done, and still more are planning for removal.  Thanks!

# 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 mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to