[coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Alex G.]

On 10/27/2015 01:36 PM, Vladimir wrote:
> Although I agree with you that AMD is not innocent as well, if you would
> check a "Binary situation" page at coreboot's wiki, you would see that
> Intel is in three times more evil

Probably "evil" is a bad term. I doubt that there's an ill intent. There
are customer (read OEMs) who want such "features". Remember the Lenovo
laptops that only allowed you to connect white-listed wifi cards before
they would boot? [1]

The real issue is that some of those "features" cannot be disabled, but
that's a technical argument, and has nothing to do with evil vs good.

> (still could not understand why some
> incredibly talented coreboot developers are spending so much time
> fighting Intel's ME issues,

I can't speak for others, but that allows me to continue to work on
coreboot, while also paying the bills. In fact, there is a significant
number of developers who pay their bills by working on coreboot. That's
progress that coreboot wouldn't otherwise see.

> In any case, it would be very sad to see the AMD code gone from the
> master branch. Even the code for some unpopular boards like Intel
> Atom-based EOL "Mohron Peak" was allowed to stay!

There are two reasons for that, one technical, and another one
political. On the technical side, there are users, and people stepped up
to maintain that code. That's usually sufficient to allow code back in.

On the non-technical side, one or two of the developers who originally
committed that code got very offended, angry, and blindsighted by the
fact that it was removed. I won't go into the details.

> Why AMD boards are considered worse? The sole idea of AMD code going away,

Who said AMD is worse? And who said AMD is going away? The whole idea is
to move it to a separate branch. This has two advantages:
 * it's only concerned with agesa boards, so it's not constrained by the
needs of other hardware
 * the master branch is no longer held back by the integration issues of
agesa

Positive side-effects:
 * No longer need to build-verify AGESA for unrelated changes (AGESA
boards take up more than half the server time)

> which will affect many alive-and-kicking coreboot-supported AMD boards,

How will moving code around affect supported boards?

> is beyond my comprehension

BRANCH NOT EQUALS REMOVAL

Does that help?

Someone in this thread (was it you Stefan?) was also suggesting we wait
until 4.3 release before we "remove" AGESA code. I know this whole
discussion started as "removing" stuff, but nobody wants to remove
anything anymore. We've gotten smarter. We just make the effort more
distributed and less centralized. I think moving to branches should be
done sooner rather than later.

Here's a list of things I think should be moved to branches, right after
the 4.2 release:

* AGESA
reason: integration issues

* binaryPI
reason: integration issues

* FSP 1.0
reason: integration issues

* MRC boards
reason: sandy/ivy already has native init path. Some chromebooks have
already been converted.

See the pattern? Now remember, this assumes branches are as first class
citizens as 'master'. Look at chromiumos coreboot: plenty of branches.
That shows it can work.

If people apply that pattern, there are a few other things that could be
branched, but I intentionally excluded:

* ROMCC-only boards:
why not: x86 bootblock still uses ROMCC, so there's no immediate value
in removing boards that also need ROMCC for romstage. Maybe we should
think of it for some future release, once we get more hardware to use
CAR setup in the bootlock.

* google FSP boards (informally, FSP 1.1)
why not: the FSP spec that's used on those boards is subject to change
(and become 1.2, 1.3, etc), and there's no indication that we'll see
significant integration issues if that happens/after it goes live.

Hope this clears things up,
Alex

[1] http://www.coreboot.org/images/6/68/Network_card_bios.jpg

> 
> On 27 October 2015 at 23:15, Timothy Pearson
> <tpearson at raptorengineeringinc.com
> <mailto:tpearson at raptorengineeringinc.com>> wrote:
> 
> On 10/27/2015 03:10 PM, Vladimir wrote:
>> It would be really wrong to remove the whole AGESA code: there are
>> AMD-based products which are still very alive and actively sold (at the
>> developing markets) Moving the support for these products to a separate
>> coreboot branch, could create many inconveniences for those AMD product
>> owners who would like to test & use the latest and greatest coreboot
>> build: they will have to backport all the commits of code that's used by
>> all the boards, to that separate abandoned branch - which would cause a
>> lot of hassle and would basically cut them off from the development
> 
>> I agree that removing could be done to some 2009 VIA-based EOL boards
>> that nobody cares about, but it would be a mistake to do that to all the
>> AMD products, some of which are still produced to this date and used
>> together with coreboot by lots of people from this mailing list
> 
>> Also, that action will send a bad signal to AMD. AMD is actively
>> supporting the coreboot project and is much more friendly to open source
>> community than Intel with it's ME and creepy lock-it-all desires.
>> Removing AGESA code would be an equivalent of telling "we don't need
>> your code" to AMD, one of the largest coreboot supporters, and that
>> could lead to a terrible consequences
> 
> AMD is hardly innocent on that front; they require a large binary blob
> to execute on the auxiliary CPU at bootup, with unknown security
> consequences.  Also, as far as I understand there has been no new AGESA
> source release for some time, only binary blobs.
> 
> 
> 
> 
>