Hi Hannah,
Personally I think it is not a good argument saying that "there are many blobs still being loaded by Coreboot and not all of these are Intel blobs, so why not allow another Intel blob to be merged" - as we always striving for a better solution, and I presume you heard the strong voice of the community from the meeting yesterday regarding the proposal. I understand that currently there are timeline constraints for development and validation, it is indeed a valid point as I was also coming from a similar background before. Would you think it makes sense if you could propose or come out with the plan for the open sourcing uGOP while we are getting your patch merged? That would give a good assurance and a gesture of good faith - I presume that once it is done open sourced, the community is happy to involve in the long term maintenance of it (as always), hence that would bring long term benefit if you think from this perspective, and Intel would also requires lesser effort to port it to the next gen iGfx, so the ROI is definitely there. 

Again, much thanks for taking time to join the meeting yesterday for an honest and candid discussion exchange on this topic - we really appreciate it when the silicon vendor took effort to engage the community actively especially in this kind of topic, that helps to build further trust for the future development. Hopefully there is a good outcome from this ;) 

Sheng


On Thu, 24 Aug 2023 at 05:33, Williams, Hannah <hannah.williams@intel.com> wrote:
We understand the hesitation to introduce one more binary blob in Coreboot. We are not opposed to open sourcing (we did support libgfxinit for our previous platforms). The Meteor Lake platform is at the final stages of development and validation, so Intel prefers to proceed with the current path to have https://review.coreboot.org/q/topic:%22ugop%22  merged now and we will follow up in parallel with a plan for open sourcing uGOP.

Notice though that currently there are many blobs still being loaded by Coreboot and not all of these are Intel blobs, so why not allow another Intel blob to be merged? Also, this is only an alternate method to libgfxinit. We do not have support today for Meteor Lake in libgfxinit, so this is not an option, hence we want the alternate method that uses the blob (uGOP). Once libgfxinit support is enabled in Coreboot, we then have the choice to use the blob or libgfxinit.
Hannah
-----Original Message-----
From: coreboot org <coreboot.org@gmail.com>
Sent: Wednesday, August 23, 2023 1:22 PM
To: coreboot <coreboot@coreboot.org>
Subject: [coreboot] 2023-08-23 - coreboot Leadership meeting minutes

# 2023-08-23 - coreboot Leadership

# Attendees:
  * ChrisW, MartinR, SubrataB, WernerZ, JonathanH, PatrickG, PaulP, JeremyC,
    KapilP, AnilK, HannahW, JasonG, RajA, FelixH, SimonG, JayT, JuliusW,
    ShelleyC, Nico, DavidH, MaximilianB, PratikkumarP, JonM, VincentZ, StefanR,
    MarshallD, ArthurH, FelixS

# Minutes:

## [Subrata] Intel AP FW team would like to present the uGOP
**implementation** meant for early Sign of Life (SOL).
  * The support commitment about libgfxinit is not strong from Intel management
    hence, Intel wished to leverage existing GFX PEIM in a much smaller format
    to support early display init. I’m hoping to invite the Intel team to
    present the talk.
  * [Martin] I’m not sure that we want to replace an open source solution with a
    proprietary solution. If we can get the uGOP source code opened, that would
    be ideal, but I can’t imagine how difficult that would be.
  * Discussion was started on the mailing list _[RFC] Pre-Memory Sign-of-Life
    using Intel uGOP_:
    https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/4OS45H7JRVFOC447YYMLCDWUF42X4RHV/
  * [sjg] Has there been discussion of libgfxinit in C?
    * https://code.google.com/archive/p/i915tool/source/default/source
  * https://review.coreboot.org/c/coreboot/+/76762
  * The root cause is long memory-training times on recent Intel devices. For
    AMD it is around 1 second per GB, but Intel takes longer
  * The uGOP driver is needed to show graphics during the long DDR5
    Initialization.
  * Why can’t the uGOP driver be in the FSPM?
    * An API needs to be exposed.
  * Intel wants to have a unified interface between coreboot & UEFI firmware,
    which is why they want to use the uGOP driver.
    * So why can’t the uGOP driver be open source?
      * Because of intel. Maybe in a year the situation will have changed.
        * This isn’t coreboot’s problem. The Meteor Lake GPU VPU Linux driver
          was [open sourced last
year](https://patchwork.kernel.org/project/dri-devel/patch/20220728131709.1087188-2-jacek.lawrynowicz@linux.intel.com/).
        * Release the information, and the community can help.
    * The uGOP is needed for early bringup of the chip, but Google needs the
      uGOP driver for the length of the program, because any other possibility
      won’t be tested.
    * The uGOP driver allows comparison with libgfxinit.
      * But we can already compare libgfxinit with the full GOP driver.
  * Again, why should the coreboot community care?
    * The only way we can get Intel to change and actually support open source
      is by putting our foot down now and refusing the uGOP driver. Intel has
      *no* incentive to change otherwise.
  * coreboot does *NOT* want another blob. Intel keeps telling coreboot that
    it’s just not possible or that it’s going to take too long, but if they had
    started on a previous project, they’d be ready now.
  * Intel: Not able to make changes for current platform but may consider them
    in future.
    * [Patrick] Same answer as in the last 13 years. Nothing ever happens (and I
      don’t blame the messengers, I fully believe that they try)

## [FelixS] Broken Matrix/IRC bridge
  * Bridge is disconnected from IRC and will not be coming back soon. What can
    we do for coreboot?
    * Can we set up our own matrix bridge. We can do this, but need to work out
      the details.
    * GDPR may be a concern (need to limit data collection).

## [Martin]How do we want to handle renaming I2C master/slave to controller/target.
  The I2C Spec has changed the names, but most datasheets have not.
  * Should we rename everything I2C across all of coreboot so that the naming is
    consistent inside coreboot, but register names are different from
    datasheets.
  * Should we leave the master/slave terminology for registers so they match the
    datasheets, and have the mismatch inside of coreboot.
  * https://review.coreboot.org/c/coreboot/+/77098
    * Julius and Arthur vote to leave the register names using the terminology
      from their datasheets.
      * [Nic] This seems to be in line with what is published on
        https://doc.coreboot.org/community/language_style.html
  * Consensus during meeting: Keep drivers consistent with datasheets, however
    the higher-level APIs can use the newer language.

## [Martin] Does anyone know if the workaround for xeon_sp/spr:
  Enable BROKEN_FSP_NEEDS_STACK_ABOVE_BSS is still needed?
  * https://review.coreboot.org/c/coreboot/+/61164/3
  * Arthur can look to see.

## [Martin] A while back, we discussed trying to help people with patches to keep things from getting stale.
  Over the past several weeks, I’ve been trying to review things that are
  starting to get a little old. While this can be cumbersome with long patch
  trains, I think it’s very useful overall.

  Here are the searches I’ve been using:
  * [cb_review_1_week_ignore_starred](https://review.coreboot.org/q/repo:coreboot+AND+status:open+AND+age:1week+AND+-is:wip+AND+-has:unresolved+AND+-label:Code-Review-1+AND+-label:Verified-1+AND+-is:starred)
  * [cb_review_1_week](https://review.coreboot.org/q/repo:coreboot+AND+status:open+AND+age:1week+AND+-is:wip+AND+-has:unresolved+AND+-label:Code-Review-1+AND+-label:Verified-1)
  * [cb_review_2_weeks](https://review.coreboot.org/q/repo:coreboot+AND+status:open+AND+age:2week+AND+-age:3month+AND+-is:wip+)
    * The 1 week search filters out a lot of patches - anything with open
    comments, anything that isn’t verified, anything with open comments.
    * The 2 week patch just filters WIP and anything over 3 months old.
    * I’ve been trying to keep fresh patches from getting over 7 days old.

## [Martin] Within AMD, we’ve been discussing the licensing for the APCB (AMD PSP Customization Block) blobs.
  We believe that they should be licensed similar to how we license the vbt.bin
  files - as pure configuration data. Currently we’re using the CC-PDDC license
  for those files, and including them in the main coreboot repository. How would
  people feel about doing the same with the APCB files?
  * APCB configuration tooling isn’t public, so the data block itself is the
    best that can be offered
  * Still, it’s only data (like SPD or VBT)
  * Concern if this is data that ought to be changed more often than, say, SPD?
  * It makes sense to keep APCB with mainboard, but user should be aware that
    APCB may get reconfigured at runtime, thus it will not necessarily match the
    blob stored in the repo.

## [FelixS] [https://felixsinger.github.io/bootguard-status/](https://felixsinger.github.io/bootguard-status/)
  * People often ask on which boards coreboot can be ported on or if their
    boards can be supported by coreboot.
  * This tracks hardware which has BootGuard enabled or disabled.
  * What do people think of this? Would it be reasonable to host this at a
    coreboot.org domain?
    * Yes, but let’s make it more generic to support other companies.
    * Maybe merge with the board-status list?
      * This is autogenerated, so it would be difficult.
    * Let’s put it on coreboot.org as it is now, but update it for other
      platforms.

## [Paul] Please let’s use the mailing list more.
  Some topics on the agenda could be discussed there first. The agenda sometimes
  looks like a different/alternative forum.
  * It’s easier to discuss things in the meeting by speaking than having to
    write an email.
  * People should look at the agenda, and add arguments here before the meeting,
    such as the discussion about renaming I2c. This does help shorten the
    meetings.

## [Paul] Experienced reviewers from coreboot companies?
  Who replaced Aaron, Furqan and Tim? Currently my feeling is, only 9elements
  does “deep” review for the general code base.
  * It’s hard to get the experience to do the in-depth reviews - When
    experienced people leave the companies, it’s hard to replace them
  * [David] Need to recruit more people to develop coreboot professionally.
  * FelixH and MartinR review everything they merge pretty thoroughly.

## [Paul] Early MRC caching: https://review.coreboot.org/c/coreboot/+/77295
  * New Kconfig option or should integration with all platforms be evaluated
    first
    * (Ran out of time, we’ll discuss on the mailing list.)

## [Paul] Status amount of funds and spending thereof.
  * (Ran out of time, we’ll discuss on the mailing list.)

## [Kyösti] Public document, or some other approach, needed to complete review of Intel Thunderbolt:
  https://review.coreboot.org/c/coreboot/+/75286
  * Add JeremyC to the review, and he can try to help find someone.
  * Bring up on the mailing list so the people at intel have more visibility.


# 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
  https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-leave@coreboot.org