On 24.08.23 07:02, Martin Roth via coreboot wrote:
> I don't like that idea, but as was said in the meeting today, coreboot is
> willing to accept that, but on the condition that the source for the binary
> (and future similar binaries) is made open. To show good faith Intel could
> guarantee th
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
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
Dear coreboot community,
I am looking for feedback on the following topic.
x86 Pre-memory stages do not support the `.data' section and as a result
developers are required to include runtime initialization code instead
of relying on C global variable definition.
To illustrate the impact of this
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
5 matches
Mail list logo
