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 s
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
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 faste
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
wrote:
> It is no
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 woul
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 t
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 wit
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 f
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
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 ca
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
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
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
integr
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 Kconfi
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 an
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
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
17 matches
Mail list logo
