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 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
