Re: [coreboot] A case for branching AGESA

On Wed, Nov 4, 2015 at 8:09 AM, Martin Roth wrote: > Let's table the discussion of agesa (and other) platform removal for > now. I didn't talk about removal. I don't understand why people think "removal" in the context of the discussion I _attempted_ to start. Let's also

Re: [coreboot] A case for branching AGESA

Hi Alex, Sorry, I should have said 'removal from the coreboot master branch'. That's what we're discussing in both contexts. All 'removed' chips and platforms will still be accessible in one of the version branches if desired. Nico demonstrated this today by cherry-picking patches over to the

Re: [coreboot] A case for branching AGESA

Let's table the discussion of agesa (and other) platform removal for now. As Patrick said in the 4.2 release announcement, a plan for the removal of code is being written and will be posted for discussion shortly. Martin On Tue, Nov 3, 2015 at 12:58 PM, Timothy Pearson

Re: [coreboot] A case for branching AGESA

I strongly disagree with this branching "solution". Why? Because - if building all the targets is slow - then just don't build all the targets at once! If you need a fast build and you are not concerned about AMD boards - just because you don't have any - it is always possible to skip AGESA build

Re: [coreboot] A case for branching AGESA

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2015 03:41 AM, Vladimir wrote: > I strongly disagree with this branching "solution". Why? > Because - if building all the targets is slow - then just don't build > all the targets at once! If you need a fast build and you are not > concerned

Re: [coreboot] A case for branching AGESA

Alex G. wrote: > >> users of AGESA can continue to contribute and work on the codebase. > > ... and diverge... > > And that's expected. Convergence is a dream. I disagree. I think it's a goal rather than a dream. > AGESA boards use BuildOpts for configuration, and not much >

Re: [coreboot] A case for branching AGESA

* Alex G. [151101 21:29]: > Except for VX900 and sandybridge, every chipset implements its own SPD > parsing routines. Gee, let's keep VX900 around then, it's one of the few good examples ;) > Alex Stefan -- coreboot mailing list: coreboot@coreboot.org

Re: [coreboot] A case for branching AGESA

2015-11-01 21:29 GMT+01:00 Alex G. : >>> Patch trains from google and other contributions to non-AGESA code gain a >>> 2x to 3x >>> speedup in server time, while users of AGESA can continue to contribute >>> and work on the codebase. >> ... and diverge... > > And that's

Re: [coreboot] A case for branching AGESA

Alex, while I'm happy that you're providing hard numbers, I completely disagree with your conclusion. A much better approach, that doesn't rely on figuring out which parts happen to be inconvenient to a subset of our developers, is to build an analysis of the impact of a commit. For global code

Re: [coreboot] A case for branching AGESA

So, if someone came to me with this problem: building all the targets is slow and this solution: get rid of a bunch of them I'd tell them to go back for more data, because that's just not enough information. Why's it slow? Where's the time going? How many files, on average, are part of an AGESA

Re: [coreboot] A case for branching AGESA

On 11/01/2015 12:49 AM, Patrick Georgi wrote: > Just a note: the only reason why current Intel fares better I didn't say Intel fares better. FSP is on my (rather long) hitlist, but that's not within the scope of this discussion. >> 7 min vs 20 min on empty ccache, and 2 min vs 6 min on primed

[coreboot] A case for branching AGESA

AGESA is a very heavy beast, at over one and a half million lines of code. Although contributions to the AGESA codebase (boards and supporting chipset/cpu code) have slowed down significantly over the years, we still rebuild this behemoth for every version of a patch. This causes quite a bit of