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/4OS45...
- [sjg] Has there been discussion of libgfxinit in C?
- 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-... ). * 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+AN... )
- [cb_review_1_week](
https://review.coreboot.org/q/repo:coreboot+AND+status:open+AND+age:1week+AN... )
- [cb_review_2_weeks](
https://review.coreboot.org/q/repo:coreboot+AND+status:open+AND+age:2week+AN... ) * 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/%5D(https://felixsinger.githu...)
- 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/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj... _______________________________________________ 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