Martin Roth via coreboot:
> - The ONLY platform that supports AGESA f12h is torpedo, and it's
> never been tested, so I'd like to suggest again that it get dropped.
I am seeing some unique Coverity issues in f12h as well. Is there an
established procedure for dropping platforms, or is it as
On Sat, Sep 21, 2019 at 5:18 AM Matt B wrote:
>>
>> There is essentially no interest for new board ports on AGESA/binaryPI,
>> these platforms have mostly survived in the tree due to commercial support
>> to maintain them.
>
> This seems to be untrue when boards like the Asus AM1I-A were ported
>
> There is essentially no interest for new board ports on AGESA/binaryPI,
> these platforms have mostly survived in the tree due to commercial support
> to maintain them.
>
This seems to be untrue when boards like the Asus AM1I-A were ported as
recently as last year. [1] It's a AMD family 16h
On Thu, Sep 19, 2019 at 11:12 AM Nico Huber wrote:
>
> On 12.09.19 18:42, Patrick Georgi wrote:
> > On Thu, Sep 12, 2019 at 07:20:49PM +0300, Kyösti Mälkki wrote:
> >> Would "some people" or these "advocates" be willing to elaborate?
> > I CC'd Nico and Martin because I seem to remember that we
On 12.09.19 18:42, Patrick Georgi wrote:
> On Thu, Sep 12, 2019 at 07:20:49PM +0300, Kyösti Mälkki wrote:
>> Would "some people" or these "advocates" be willing to elaborate?
> I CC'd Nico and Martin because I seem to remember that we talked
> about AGESA (and its quality and/or life cycle). Nico,
On Thu, Sep 19, 2019 at 3:20 AM Matt B wrote:
>
>
> Kyösti Mälkki said:
>>
>> AFAICS, that platform codebase even suffers from cache coherency issues
>> while executing from cache-as-ram; there has been indications that increased
>> spinlock usage in romstage causes boot failures and/or reset
Kyösti Mälkki said:
> AFAICS, that platform codebase even suffers from cache coherency issues
> while executing from cache-as-ram; there has been indications that
> increased spinlock usage in romstage causes boot failures and/or reset
> loops.
>
Where do you see this? Has it been reported?
On Thu, Sep 19, 2019 at 1:05 AM Martin Roth wrote:
>
> My proposal is to drop platforms that aren't being tested, aren't
> being maintained, or are causing serious problems with general
> coreboot development.
>
> For example
> - ASUS KGPE-d16 is still being used and tested, so I wouldn't suggest
My proposal is to drop platforms that aren't being tested, aren't
being maintained, or are causing serious problems with general
coreboot development.
For example
- ASUS KGPE-d16 is still being used and tested, so I wouldn't suggest
dropping that code, even though it apparently doesn't support
awokd via coreboot wrote:
> Submitted a request to Coverity to be added as contributor.
Thank you very much! That's great.
//Peter
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
Patrick Georgi via coreboot:
>
> [snip well-written description of contributor/maintainer duties]
Thank you for that. Wonder if it should be added to the project
documentation somewhere- I'd seen bits and pieces of it before on this
list, but it is a great overview.
> Plus, I mentioned it
On Thu, Sep 12, 2019 at 04:46:00PM +, awokd via coreboot wrote:
> > Drivers needs support to not get in the way of later development,
> > and AGESA is sorely lacking in that department. If you see value
> > in that code, please step up now, not only when we're looking into
> > removing that
Jacob Garber:
> The Coverity issue tracker has several IDE-like features, such as a usage
> finder and go-to definitions. This was adequate for most of my needs, and
> anything else I tracked down using vim and judicious use of grep. There are
> probably more efficient ways to do this (eg.
On Thu, Sep 12, 2019 at 04:46:00PM +, awokd via coreboot wrote:
> Patrick Georgi via coreboot:
> > Hi everybody,
> >
> > coreboot is shipping AMD's open sourced AGESA for a few generations
> > as part of its tree.
> >
> > Some people advocate dropping the code due to its quality and lack
> >
excellent points matt
"There is no working bad source so bad that a binary blob is better"
"working bad source should never be replaced by a blob, but only by
improved working bad source"
"we must never remove working bad source that is in use if the only
replacement is a blob"
On Thu, Sep
Greetings all,
Patrick gregori said:
> Mostly chatter on IRC, to be honest. Part of the intent of this mail was
> to surface this more officially.
>
It would be helpful to carry over more details when porting discussions
from IRC. It is always good to be specific how something is broken, not
Interesting discussion! It got me to wondering, having spent a lot of
time in the V1, V2, and V3 trees the last few months.
Is this statement true?
"There is no source so bad that a binary blob is better"
If we take that to be true, then what about this:
"bad source should never be replaced by a
Patrick Georgi via coreboot:
> Hi everybody,
>
> coreboot is shipping AMD's open sourced AGESA for a few generations
> as part of its tree.
>
> Some people advocate dropping the code due to its quality and lack
> of maintenance while others are happy with using the code.
>
> So: to help keep
On Thu, Sep 12, 2019 at 07:20:49PM +0300, Kyösti Mälkki wrote:
> Would "some people" or these "advocates" be willing to elaborate?
I CC'd Nico and Martin because I seem to remember that we talked
about AGESA (and its quality and/or life cycle). Nico, for example,
seems to advocate scrapping AGESA
On Thu, Sep 12, 2019 at 5:43 PM Patrick Georgi via coreboot
wrote:
>
> Hi everybody,
>
> coreboot is shipping AMD's open sourced AGESA for a few generations
> as part of its tree.
>
> Some people advocate dropping the code due to its quality and lack
> of maintenance while others are happy with
20 matches
Mail list logo
