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 <[email protected]> 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 <[email protected]> > Sent: Wednesday, August 23, 2023 1:22 PM > To: coreboot <[email protected]> > 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/[email protected]/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/[email protected]/ > ). > * 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 -- [email protected] To unsubscribe send an > email to [email protected] > _______________________________________________ > coreboot mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
