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

[Wim Vervoorn]

Hello Alex,

I totally agree with your mail. This certainly looks like the way to deal with it.

We don't loose anything but make it easier to move forward with new designs at the same time when using branches.

BR Wim.





-----Original Message-----
From: coreboot [mailto:coreboot-bounces at coreboot.org] On Behalf Of Alex G.
Sent: Wednesday, October 28, 2015 4:56 AM
To: coreboot at coreboot.org
Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

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.
> 
> 
> 
> 
> 

--
coreboot mailing list: coreboot at coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot