Nico,
> For our FSP implementation, I intend to rely on the FSP 2.0 EAS published
> > by Intel then document the important differences, which I hope is
> extremely
> > minimal. Then there will also be a Picasso-specific Integration Guide,
> > again similar to Intel's docs. This leaves us
On 26.01.20 20:15, David Hendricks wrote:
> On Sat, Jan 25, 2020 at 4:44 PM Nico Huber wrote:
>> we've recently seen the deprecation of Intel/Broadwell-DE support
>> because it turned out to be too proprietary to be maintained in the
>> long run.
>
> To be fair, the FSP 1.0 platforms
David Hendricks schrieb am Mi., 29. Jan. 2020,
00:51:
> we'd first need to invent a way to
> send an electric shock thru the keyboard to users who complain to (or
> about) Intel when something goes wrong with the code.
>
That may have been necessary in the era of the fdiv bug but I'm not sure
> Writing new code could considerably reduce its complexity
> and make things much easier. After a few years with FSP, I'm convinced
> that writing clean code would be cheaper than the FSP integration with
> all its avoidable complexity. Intel might not like it, but you could
> reach proper
Hi Marshall,
On 28.01.20 02:12, Marshall Dawson wrote:
>> That's why I always encourage people to ask for documentation instead
>> of code. Opening code that was developed in private is a pain for both
>> sides. However, I guess it could be taken as a good omen; that a silicon
>> vendor won't
Hi Jonathan,
On 27.01.20 23:01, Jonathan Zhang (Infra) wrote:
> On 1/27/20, 10:56 AM, "Nico Huber" wrote:
>> We had this before: Something that nobody really cared about was
>> upstreamed. And then later, it was copied for newer platforms and
>> people were confused by the feedback that they
On Mon, Jan 27, 2020 at 04:24:00PM -0600, Matt DeVillier wrote:
> having a src/mainboard/stub/ for **all** SoC might not be a bad idea,
> especially if it were to select less common/non-default options that other
> in-tree boards don't select by default, to ensure full coverage of all SoC
>
Patrick,
> Should we add stub mainboards for new chipsets that build the code as a
> way to make sure nobody else inadvertently breaks things (at least not too
> bad)?
>
That's an interesting idea. A benefit that I see is that it's then
demonstrable how changes and additions affect the
Hi Marshall,
thank you very much for your huge elaboration. I had already given up
all hope to see public communication from AMD. That's really great to
see things change.
It's a lot to digest, I'll try to just briefly comment on my main
concern, why I called it controversial: the unclear blob
On Mon, Jan 27, 2020 at 3:57 PM Patrick Georgi via coreboot <
coreboot@coreboot.org> wrote:
> Hi Marshall,
>
> thanks for that cohesive report and insight into your development process
> and the trade-offs involved.
>
> Am Mo., 27. Jan. 2020 um 21:12 Uhr schrieb Marshall Dawson <
>
On 1/27/20, 10:56 AM, "Nico Huber" wrote:
Hi Jonathan,
thanks for your email. It's become very rare that developers take part
in mailing-list discussions when they are asked to. So it's really
appreciated.
Jumping to conclusion without knowing context could cause
Hi Marshall,
thanks for that cohesive report and insight into your development process
and the trade-offs involved.
Am Mo., 27. Jan. 2020 um 21:12 Uhr schrieb Marshall Dawson <
marshalldawson...@gmail.com>:
> Instead, please give me the opportunity to review any of your changes that
> touch the
Despite my frustration here, I’m optimistic that this discussion can serve
to close out the thread “Copy-first platform additions (was: Re: Re:
Proposal to add teeth to our Gerrit guidelines)”
Hi Jonathan,
thanks for your email. It's become very rare that developers take part
in mailing-list discussions when they are asked to. So it's really
appreciated.
On 27.01.20 17:21, Jonathan Zhang (Infra) wrote:
> On 1/26/20, 11:32 AM, "Nico Huber" wrote:
>>
>> Hi David,
>>
>>On 26.01.20
On 1/26/20, 11:32 AM, "Nico Huber" wrote:
Hi David,
On 26.01.20 20:15, David Hendricks wrote:
> On Sat, Jan 25, 2020 at 4:44 PM Nico Huber wrote:
>> There are currently two new platforms in development that seem to
>> have trouble with public binaries (which would be
Hey Martin,
On 26.01.20 21:21, Martin Roth wrote:
> The picasso platforms are being worked on in a private repo because
> it's not bootable at coreboot.org. It's not bootable because the
> patches that would make it bootable were delayed and rejected.
I'm sorry that you had trouble with your
On Sun, Jan 26, 2020 at 12:38 PM Kevin Paul Herbert wrote:
>
> I am shipping a product based on Broadwell-DE and FSP 1.0. It’s very
> disappointing to have to rely on binary blobs and I wish I could do better,
> but I’d rather ship with coreboot than proprietary UEFI.
>
> I expected to upstream
I am shipping a product based on Broadwell-DE and FSP 1.0. It’s very
disappointing to have to rely on binary blobs and I wish I could do better, but
I’d rather ship with coreboot than proprietary UEFI.
I expected to upstream my code at some point but if FSP 1.0 support is being
deprecated I
On 26.01.20 20:36, Martin Roth wrote:
> While it's not my preference, I'm fine with pulling picasso out of the
> tree and doing the development in private if that's the community
> desire. When we're done, it can go in, or not, as the coreboot
> community chooses. Because we can't boot what's in
The picasso platforms are being worked on in a private repo because
it's not bootable at coreboot.org. It's not bootable because the
patches that would make it bootable were delayed and rejected.
What's the incentive to work on anything at coreboot.org? Why should
any company work at
On 26.01.20 21:09, Nico Huber wrote:
> Hi Martin,
>
> On 26.01.20 20:36, Martin Roth wrote:
>> While it's not my preference, I'm fine with pulling picasso out of the
>> tree and doing the development in private if that's the community
>> desire. When we're done, it can go in, or not, as the
Hi Martin,
On 26.01.20 20:36, Martin Roth wrote:
> While it's not my preference, I'm fine with pulling picasso out of the
> tree and doing the development in private if that's the community
> desire. When we're done, it can go in, or not, as the coreboot
> community chooses. Because we can't
While it's not my preference, I'm fine with pulling picasso out of the
tree and doing the development in private if that's the community
desire. When we're done, it can go in, or not, as the coreboot
community chooses. Because we can't boot what's in coreboot
currently, we're being forced to
Hi David,
On 26.01.20 20:15, David Hendricks wrote:
> On Sat, Jan 25, 2020 at 4:44 PM Nico Huber wrote:
>> There are currently two new platforms in development that seem to
>> have trouble with public binaries (which would be necessary to make
>> the code useful to the coreboot community).
On Sat, Jan 25, 2020 at 4:44 PM Nico Huber wrote:
>
> Hello coreboot fellows,
>
> we've recently seen the deprecation of Intel/Broadwell-DE support
> because it turned out to be too proprietary to be maintained in the
> long run.
To be fair, the FSP 1.0 platforms (Broadwell-DE, Baytrail,
25 matches
Mail list logo
