# 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://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-...). * 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...
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://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-...). * 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
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
Hi Hannah,
On 24.08.23 05:33, Williams, Hannah 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.
I don't comprehend this "merged now". *If* the project agrees to this path, first the design would have to be discussed. And then we could start a review. Merging comes after that. And as mentioned in the other thread, last time in a similar case it took 11 months. So if you are in a hurry to get something upstream, this doesn't seem like a promising approach.
Again if the project would agree, you could probably speed things up by proposing a more modern interface and code flow (for libgfxinit we currently have a simple API: gma_gfxinit(), gma_gfxstop(), and I don't see why a blob couldn't reuse this interface). And a binary format that doesn't need changes to our tools.
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?
Quite simple, because this is a free-software project, and every single blob requires careful consideration.
The question raised one concern for me: Is it maybe that the amount of blobs mislead you to believe that integrating the uGOP would be an easy, feasible solution? I think it's quite important to discuss these things, so everybody can make better decisions in the future and avoid all the friction and pain for developers caused by bad decisions.
If the obscure blob situation makes things harder, maybe it's time for a little housecleaning? For instance, if you've followed the other thread, there was the MP PPI mentioned, and some misunderstandings around it. Could Intel maybe evaluate what blobs and interfaces are actually required in upstream coreboot, and clean up the integration? For the MP PPI for instance, I saw half a dozen Kconfig options where one might suffice. It would also be interesting to see if the argu- ments that were used to introduce the blobs are still valid. WDYT?
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).
Either way takes time because we are only in the very early stages to discuss the uGOP solution. Here's a thought: Implementing libgfxinit support for MTL right now would at least speed the process up for the next generation. And in the best case, it would be ready before the MTL launch. So if you are in a hurry, the best thing to do is to work in parallel on both approaches and start coding right away.
Regards, Nico
Hi Sheng, Yes I will come back within the next few weeks on open sourcing uGOP.
Hi Nico, I think your suggestion to use similar interface to libgfxinit (gma_gfxinit(), gma_gfxstop()) is a good idea. Please add your comments to the CLs and we will work on it. Regarding the MP PPI and the Kconfig cleanup that you mentioned, we will take this up. I am going to open a internal ticket to follow up on this. Also, on your comment on implementing libgfxinit for MTL, this will not speed up the process for us because we do not have resources to work on it and this is why we went the faster route to re-use what we already have (GOP) and modified it as uGOP for SOL use case. Thanks Hannah
On 25.08.23 06:52, Williams, Hannah wrote:
I think your suggestion to use similar interface to libgfxinit (gma_gfxinit(), gma_gfxstop()) is a good idea. Please add your comments to the CLs and we will work on it.
Thanks. I'll wait though, until the decisions about open-sourcing and integrating uGOP are made.
Regarding the MP PPI and the Kconfig cleanup that you mentioned, we will take this up. I am going to open a internal ticket to follow up on this.
Thanks again! However the MP PPI was just one example. It would be good to have up-to-date information and clean integration for all features of Intel's blobs. Information, I think, is the more impor- tant part. Staying with the MP PPI example: IIRC, when it was intro- duced there was a list of advanced features added to our documen- tation, arguing that the features would only be made possible by the MP PPI integration. But I'm not sure if any of these features ever surfaced in coreboot. So maybe this is something to add to your ticket: Do we actually need the MP PPI in coreboot?
Also, on your comment on implementing libgfxinit for MTL, this will not speed up the process for us because we do not have resources to work on it
Last time I checked Intel was still a multi-billion dollar company. I think this translates to: SOL is not a high enough priority for Intel.
and this is why we went the faster route to re-use what we already have (GOP) and modified it as uGOP for SOL use case.
If you only go one route, we'll never have a definite answer which is the faster one.
Regards, Nico
Here are the reasons why we cannot open source Meteor Lake uGOP: - It has licensed code for HDMI and other industry specifications (i915 also cannot open source HDMI 2.1) - VBT spec is not open sourced There will have to be a re-design of the uGOP component so that we can work around above issues and still open source. This is being considered for future SOCs. Hannah
Hi Hannah, Thanks for the update.
Presumably the HDMI source isn't required in the uGOP driver for chromebooks, so that shouldn't be a problem. With chromebooks, only the eDP should need to be initialized to show signs-of-life.
I guess the only thing I really see happening at this point is for Intel to make the uGOP driver a part of the FSP, which I understand isn't ideal.
I'm sure you can understand that as an open source project, we've had enough proprietary blobs forced on the project already and don't want any more. Martin
Sep 6, 2023, 10:58 by hannah.williams@intel.com:
Here are the reasons why we cannot open source Meteor Lake uGOP:
- It has licensed code for HDMI and other industry specifications (i915 also cannot open source HDMI 2.1)
- VBT spec is not open sourced
There will have to be a re-design of the uGOP component so that we can work around above issues and still open source. This is being considered for future SOCs. Hannah _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Martin, For laptop form factor, yes only eDP is needed but we do need HDMI for other use cases like Chromebox. It is too late for us to do any cleanup of uGOP for Meteor Lake. I understand that you don't want to include proprietary blobs going forward, but for situations like this where we cannot open source because of IP or licensing restrictions, we do need Coreboot to provide an alternate method to load and execute initialization from the blob. Even if we start open sourcing uGOP for a future SOC, there will be an early period of the SOC where we will have to use a blob as an alternate method until PV after which open source would be possible. We have started the conversation with our internal teams on open sourcing whatever can be open sourced in uGOP similar to i915 but this is going to take some time and can only be targeted for future SOC. Thanks Hannah
Am 06.09.2023 um 18:57 schrieb Williams, Hannah:
Here are the reasons why we cannot open source Meteor Lake uGOP:
- It has licensed code for HDMI and other industry specifications (i915 also cannot open source HDMI 2.1)
- VBT spec is not open sourced
There will have to be a re-design of the uGOP component so that we can work around above issues and still open source. This is being considered for future SOCs.
At the risk of repeating myself: That seems like a you-problem to me.
By now the question (and request by Intel customers) of having GOP (or its predecessor vgabios) available under open source terms is older than some of the contributors to coreboot.
Given that https://www.phoronix.com/news/Intel-MTL-Graphics-Linux-Stable claims that the Meteor Lake GPU bring-up in Linux is now ready, maybe those folks, who know both your GPU design _and_ how to work in an open source environment could help out the GOP folks?
(And don't complain about any choices made in libgfxinit: Intel had tons of time to come up with an adequate solution, thereby shaping the standard solution in that problem space - and decided not to. Eventually people put in _their_ effort to support _your_ hardware.)
Regards, Patrick
Already there are binaries FSP, AGESA, PSP being used in Coreboot and because of IP and licensing issues everything cannot be open sourced. The uGOP is just a stripped down version of GOP that is already inside FSP. This is the fastest method for this specific product and hence we are asking for a waiver to the closed source binary rule (by the way where is this stated in coreboot.org?). We will also work closely with our other open source Linux graphics team to see how we can leverage common code for future Silicon. Hannah
Hello Hannah,
On 07.09.23 20:49, Williams, Hannah wrote:> Already there are binaries FSP, AGESA, PSP being used in Coreboot and> because of IP and licensing issues everything cannot be open sourced.
The uGOP is just a stripped down version of GOP that is already inside FSP. This is the fastest method for this specific product and hence we are asking for a waiver to the closed source binary rule (by the way where is this stated in coreboot.org?).
Terms and conditions to use and modify/extend coreboot can be found here https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/COP...
The second sentence of the preamble already wraps the gist of it up, very well: "By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users."
Changing software that comes in form of a blob is hard (and in case of FSP even denied by its license; nobody but Intel is allowed to even fix security issues).
The technical mechanism to guarantee freedom lives in Section 3. The basic idea is that everybody who makes a product with coreboot has to share the source code of their whole coreboot under a compatible license. In a way, this means one has to pay to license coreboot for their products--not with money but with source code. Now with FSP, Intel presents their customers with an uncomfortable choice: Don't use Intel or go in debt (not being able to pay with source code). And now that Intel plunged everybody into debts for 10 years, you are asking for a waiver, so everybody can incur more debts? When should this end? When will Intel help to pay any of it back? Maybe, as a token of good faith, Intel could start publishing source code of this decade of FSP?
All this "software freedom" may seem unnecessarily idealistic. But it often turns out that it actually helps with the every growing complexity of today's computer systems. And it helps to scale, it helps innovation. OTOH, the way I see it, Intel's approach seems to achieve less at much higher cost. As far as I understand, Intel's argument not to open source is usually a combination of: * There are a few lines that can't be open sourced because IP / NDA. * Intel supports only a single code base because of "convergence goals", (and that code base needs to be tainted by the lines mentioned above).
I believe it's such convergence goals that keep Intel stuck 30 years in the past. Back then, there was little product diversity. Having a single, validated binary scaled well enough for a 386 SL/SX/DX (all in desktop like PCs). Toolchains weren't trusted, reproducibility probably wasn't a thing. Security updates were not a concern. I could imagine that source code wasn't even properly archived. IMO, the way Intel handles firmware today perfectly fits these times... In the 21st century, things look kind of the opposite: (security) updates every- where, huge product diversity (x86 on tablets, laptops, desktops, workstations, servers, all the IoT things--everything multiplied by consumer, embedded, server markets), and reproducible builds. A single validated binary probably scales so badly, I can't imagine the costs, and the horrors Intel employees have to go through. This also has bad effects on Intel's customers: there is absolutely no room for inno- vation.
Let's imagine for a moment, everybody using coreboot for Meteor Lake would have to use a single coreboot build, a single binary, configured VBT-style. It seems virtually impossible to get that done in time. OTOH, it seems possible that supporting the coreboot code base and projects like libgfxinit directly--instead of trying to converge everybody's needs in a single binary--is actually cheaper for Intel. The SoL feature could be the perfect project to experiment with a community approach.
Hannah, sorry if I digressed too much, but I really hope this helps to understand the bigger picture. Please help Intel to embrace diver- sity instead of trying to cook up single binaries. Actually, Pat Gelsinger seems to understand already[1]: "• And, as is core to the Intel values, we will be inclusive in our approach and support of communities’ efforts, while embracing diversity and our differences because they make us better." There are probably many levels inside Intel between you and him that need your help to understand it too, and to adapt Intel to the 21st century.
Nico
[1] https://www.linkedin.com/pulse/open-letter-ecosystem-pat-gelsinger
Hello Hannah,
Williams, Hannah wrote:
Already there are binaries FSP, AGESA, PSP being used in Coreboot
We consider this historical problems in the coreboot project and it is absolutely not something we intend to lean into. Since you have a mandate to work with coreboot I guess you are onboard with this, after all, our culture is inherent to our project.
and because of IP and licensing issues everything cannot be open sourced.
I consider this a temporary problem for Intel that it needs to solve to avoid losing future business to competing, open source solutions.
This is the fastest method for this specific product
Since coreboot isn't owned by Intel I'm afraid Intel has to accept that the request gets denied by coreboot.
I guess you can understand that coreboot has no incentive to make further compromise that would really only benefit Intel and actually hurt coreboot.
binary rule (by the way where is this stated in coreboot.org?).
Do you really not understand the spirit of open source and what coreboot is doing since more than 20 years? I guess you do but that you need a reference to something written for some silly higher-ups. :\
We will also work closely with our other open source Linux graphics team to see how we can leverage common code for future Silicon.
This is a good idea. Maybe libgfxinit could even become the primary codebase at some point. In any case it's just silly to duplicate work at all, including for i915+GOP.
Kind regards
//Peter
While it is true that there are binary blobs in coreboot today, that was not always the case.
From 1999 to about 2011, all coreboot images were built from 100% source code, most of it GPL, some of it BSD-style license (e.g. microcode).
Around 2006, Intel made it impossible to continue with open source for server platforms by restricting access to chipset data.
In 2014, AMD decided they would no longer release AGESA as open source, breaking with a commitment they made in 2006 at the LinuxBIOS meeting in Hamburg.
I don't think that the existence of blobs justifies adding more blobs.
On Mon, Sep 11, 2023 at 10:52 AM Peter Stuge peter@stuge.se wrote:
Hello Hannah,
Williams, Hannah wrote:
Already there are binaries FSP, AGESA, PSP being used in Coreboot
We consider this historical problems in the coreboot project and it is absolutely not something we intend to lean into. Since you have a mandate to work with coreboot I guess you are onboard with this, after all, our culture is inherent to our project.
and because of IP and licensing issues everything cannot be open sourced.
I consider this a temporary problem for Intel that it needs to solve to avoid losing future business to competing, open source solutions.
This is the fastest method for this specific product
Since coreboot isn't owned by Intel I'm afraid Intel has to accept that the request gets denied by coreboot.
I guess you can understand that coreboot has no incentive to make further compromise that would really only benefit Intel and actually hurt coreboot.
binary rule (by the way where is this stated in coreboot.org?).
Do you really not understand the spirit of open source and what coreboot is doing since more than 20 years? I guess you do but that you need a reference to something written for some silly higher-ups. :\
We will also work closely with our other open source Linux graphics team to see how we can leverage common code for future Silicon.
This is a good idea. Maybe libgfxinit could even become the primary codebase at some point. In any case it's just silly to duplicate work at all, including for i915+GOP.
Kind regards
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Hannah
It looks like your information is not up to date.
https://www.phoronix.com/news/Intel-HDMI-2.1-FRL-Linux so hdmi 2.1 upstreaming in Linux began 10 months ago?
Both Linux and https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commits/master/ has support for VBT, which should suffice without a spec. Even coreboot has limited support for VBT.
It looks like there is no good reason for this blob to be closed source or did I miss something? The only difference with i915 that has functional display support is that you use VGA legacy mode in uGOP and not a linear framebuffer. VGA legacy mode is very old. I think you'll have a hard time convincing this community that this mode is sensitive NDA only IP that justifies a blob.
Do you have other technical reasons to justify uGOP being closed source while Linux has support pretty much a year before the silicon is released? Maybe we or a search engine can help you out on those too?
Arthur
On Wed, Sep 6, 2023, 17:58 Williams, Hannah hannah.williams@intel.com wrote:
Here are the reasons why we cannot open source Meteor Lake uGOP:
- It has licensed code for HDMI and other industry specifications (i915
also cannot open source HDMI 2.1)
- VBT spec is not open sourced
There will have to be a re-design of the uGOP component so that we can work around above issues and still open source. This is being considered for future SOCs. Hannah _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
It is not possible to open source uGOP today without re-writing it. We do not have time to re-write considering our product timeline and hence the request to allow to use binary now. We acknowledge that we will make effort to open source uGOP for future SOC by working internally with the other teams in Intel like i915 team. We have to see how to write common code between the two so that we can open source at the same time. Hannah
Were it not for the fact that we've been having the general open source discussion with intel for 24 years, and this graphics discussion for 10 years, we might believe that the claim of future open source is possible.
Intel did not take open source into account when Intel wrote this code; why would we expect Intel to take open source into account now?
It's very easy to predict that the open source rewrite, or release, will never happen. Because there's decades of history to draw upon.
I hope this explains a certain apparent disbelief on the community's part that we should take binaries now, and an open source version tomorrow. Because we know it won't happen. It seems pointless to accept a binary blob, in the short term, when we know there are only binary blobs in the long term.
ron
On Thu, Sep 7, 2023 at 1:50 PM Williams, Hannah hannah.williams@intel.com wrote:
It is not possible to open source uGOP today without re-writing it. We do not have time to re-write considering our product timeline and hence the request to allow to use binary now. We acknowledge that we will make effort to open source uGOP for future SOC by working internally with the other teams in Intel like i915 team. We have to see how to write common code between the two so that we can open source at the same time.
Hannah
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi Hannah
So the only reason for including uGOP as a blob is a failed planning at Intel and nothing technical?
I agree with Patrick here. This is really an Intel-problem and not something coreboot should have to put up with.
Arthur
On Thu, Sep 7, 2023, 21:50 Williams, Hannah hannah.williams@intel.com wrote:
It is not possible to open source uGOP today without re-writing it. We do not have time to re-write considering our product timeline and hence the request to allow to use binary now. We acknowledge that we will make effort to open source uGOP for future SOC by working internally with the other teams in Intel like i915 team. We have to see how to write common code between the two so that we can open source at the same time.
Hannah
-
Arthur Heymans -
coreboot org -
Lean Sheng Tan -
Martin Roth -
Nico Huber -
Patrick Georgi -
Peter Stuge -
ron minnich -
Williams, Hannah