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@raptorengineeringinc.com mailto:tpearson@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.
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@coreboot.org] On Behalf Of Alex G. Sent: Wednesday, October 28, 2015 4:56 AM To: coreboot@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@raptorengineeringinc.com mailto:tpearson@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@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
2015-10-28 4:56 GMT+01:00 Alex G. mr.nuke.me@gmail.com:
Here's a list of things I think should be moved to branches, right after the 4.2 release:
So far the idea was to drop things in master after a release, and create branches for releases (as I did for 4.1 yesterday, in addition to the tag). So, when dropping stuff after the 4.2 release, to go back to these things, you start from the 4.2 branch.
Now remember, this assumes branches are as first class citizens as 'master'. Look at chromiumos coreboot: plenty of branches. That shows it can work.
There's a significant difference (and a problem that we'd inherit by adopting the chromium gerrit model):
The difference is that Chromium firmware branches are made per-board for devices where not many changes are expected. The items you point out are most interesting for adding new boards (nevermind if this actually happens - but the Lenovo *60 stuff wasn't predicted a year before it happened either, 945 was "dead" then). If we go for branches for that, developing FSP1.0 coreboot will look quite different from master-coreboot.
The problem we have with firmware branches over at Chromium is that, as far non-ChromeOS development is concerned, branches are where commits are pushed to die. They're not folded back into mainline Chromium nor coreboot.org. We don't really have a good solution for that.
If we spawn tons of branches every time something becomes a bit inconvenient to deal with, we're quickly devolving into u-boot: vendors will just start maintaining their own branches, and porting high level features between those requires an immense amount of effort because there are many years of divergence between them. If you want a taste of that, try building something on Chromium's chromeos-2013.04 branch and then port it to upstream master. And that was just 2.5 years.
tl;dr: hiding problems in branches won't serve us long-term.
Patrick
-
Alex G. -
Patrick Georgi -
Wim Vervoorn