[coreboot] Re: Jenkins V-1 failure due to internal error

[Martin Roth via coreboot]

Hey Jeremy, I retriggered the build. I thought that at one point we had it set 
up so that anyone could retrigger the builds, but that doesn't seem to be the 
case anymore. Let me see if I can fix that.

Martin

Sep 6, 2023, 16:38 by jeremy.composte...@intel.com:

> Hi,
>
> It happened to me a couple of times in the past and again today. I got
> a V-1 on  without any
> "good reasons" as 
> error seems to be unrelated to my patch.
>
> Is there a way to restart the build and get rid of the V-1 without
> re-submitting a patch with a minor commit message change ?
>
> Regards,
>
> -- 
> *Jeremy*
> /One Emacs to rule them all/
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Jenkins V-1 failure due to internal error

[Compostella, Jeremy]

Hi,

It happened to me a couple of times in the past and again today. I got
a V-1 on  without any
"good reasons" as 
error seems to be unrelated to my patch.

Is there a way to restart the build and get rid of the V-1 without
re-submitting a patch with a minor commit message change ?

Regards,

-- 
*Jeremy*
/One Emacs to rule them all/
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes

[Patrick Georgi via coreboot]

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

[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes

[Williams, Hannah]

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

[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes

[Martin Roth via coreboot]

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.willi...@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-le...@coreboot.org
>

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: 2023-08-23 - coreboot Leadership meeting minutes

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

[coreboot] Re: [RFC] x86: Add .data section support for pre-RAM stages

[Martin Roth via coreboot]

Hi Jeremy,
  I've added it to the agenda for today's leadership meeting.
Martin

Sep 5, 2023, 15:30 by jeremy.composte...@intel.com:

> Hi,
>
> Any feedback on this topic ?
>
> I made some significant changes and made sure to cover all the cases
> we identified including non-XIP stages. Cf. 
> 
>
> Thanks,
> Jeremy
>
> "Compostella, Jeremy"  writes:
>
>> 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 lack of .data section support, here
>> are two limitations I personally ran into:
>> 1. The inclusion of libgfxinit in romstage last year has required some
>>  changes in libgfxinit to ensure data is initialized at runtime. In
>>  addition, we had to manually map some .data symbols in the _bss
>>  region.
>> 2. CBFS cache is currently not supported in pre-memory stages and
>>  enabling it would require to add an initialization function and
>>  find a generic spot to call it.
>>
>> Instead of going though these workarounds and as it was suggested on
>> [[RFC] VGA Text mode in romstage] last year, I believe we could add
>> support for a `.data' section. I have been working on a solution for
>> eXecute-In-Place (XIP) pre-memory stages (`bootblock', `verstage' and
>> `romstage') which deliver good results
>> (cf. ).
>>
>> In short this patch:
>> 1. creates a new ELF segment to hold the `.data' section
>> 2. creates a `.data' section with its Virtual Memory Address (VMA)
>>  within Cache-as-RAM (CAR) boundaries and its Load Memory Address
>>  (LMA) following the .text section (at `_etext').
>>
>> cbfstools is also updated:
>> - To process this new segment and `.data' section
>> - To place the .data section content right after the
>>  code (cf. `parse_elf_to_xip_stage' function)
>>
>> At the moment, this patch makes cbfstool detects the presence of the
>> segment automatically and assume this is a "data" segment. But we
>> could add a new parameter to make this new behavior less automatic if
>> you think this would be better.
>>
>> This patch also adds a piece of assembly code (or C-code for
>> bootblock) to copy the `.data' section content to Cache-As-RAM at
>> runtime.
>>
>> Regards,
>>
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org