Discussion:
Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
(too old to reply)
Martin Roth
2015-10-26 21:51:21 UTC
Permalink
I'd like to start a discussion about boards, chipsets, drivers, or
other code that can be removed from the tree.

At the coreboot conference in Bonn, we discussed this some. I believe
that we decided to wait until the next release/branch of the coreboot
tree before removing anything. By planning ahead and deleting the
components immediately after the release, we can list the things that
have been end-of-lifed in the branch release notes.

By discussing this on the mailing list instead of just pushing commits
to the tree, we can get better buy in from all interested parties.


I'd request that these be boards & chips that are no longer being
produced, and haven't been updated in a few years.

These seem like good candidates to start the discussion:
mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
northbridge/via/vx800 - http://review.coreboot.org/#/c/7471

As far as I can tell, the last real contributions to these came in
2009 - all the changes since then have been cleanup and modifications
for other changes across the coreboot tree.

What other directories should be removed from the tree after the next release?


Eventually it would be nice to be able to use submissions to
board-status repo to determine what's being used. We're just not at
that point yet.
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Alex G.
2015-10-27 03:36:20 UTC
Permalink
Post by Martin Roth
I'd like to start a discussion about boards, chipsets, drivers, or
other code that can be removed from the tree.
What other directories should be removed from the tree after the next release?
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native
support, I don't think we want to haul around the AGESA implementations,
which have been troublesome in the past.

Actually, branch off those boards, keep them alive in their little
branch, but remove them from master. Gerrit is knows how to handle
branches, so we already have the infrastructure in place to support this.

Alex
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Peter Stuge
2015-10-27 08:34:59 UTC
Permalink
Post by Alex G.
Post by Martin Roth
I'd like to start a discussion about boards, chipsets, drivers, or
other code that can be removed from the tree.
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native
support, I don't think we want to haul around the AGESA implementations,
which have been troublesome in the past.
Actually, branch off those boards, keep them alive in their little
branch, but remove them from master.
Hm maybe. It's important that the boards which use AGESA are still
available somehow, so that they could be ported to coreboot init
if someone has interest in doing that. Maybe a branch is good enough.


//Peter
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Wim Vervoorn
2015-10-27 15:01:38 UTC
Permalink
Sounds like a good idea to create a branch of these but shouldn't that be done for other boards as well.

So when you intend to remove boards to create version 4.2 you create a 4.1 branch of the existing state with those boards included. Then remove all boards that need to be dropped.

When it's handled this way it's probably easier to drop boards that aren't used actively and thereby dropping unnecessary maintenance work.

BR Wim

-----Original Message-----
From: coreboot [mailto:coreboot-***@coreboot.org] On Behalf Of Peter Stuge
Sent: Tuesday, October 27, 2015 9:35 AM
To: ***@coreboot.org
Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
Post by Alex G.
Post by Martin Roth
I'd like to start a discussion about boards, chipsets, drivers, or
other code that can be removed from the tree.
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming
native support, I don't think we want to haul around the AGESA
implementations, which have been troublesome in the past.
Actually, branch off those boards, keep them alive in their little
branch, but remove them from master.
Hm maybe. It's important that the boards which use AGESA are still available somehow, so that they could be ported to coreboot init if someone has interest in doing that. Maybe a branch is good enough.


//Peter

--
coreboot mailing list: ***@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Martin Roth
2015-10-27 16:14:54 UTC
Permalink
The current thought is to create a new branch for 4.2, *THEN* remove
the decided upon code from the master branch.

This removes the maintenance work on master going forward while
providing a known point if someone wants to pick up the boards going
forward.

I don't understand the question about creating a branch for other
boards as well. The branch would contain all current boards.

The question is really about what boards/code are inactive. The code
that's being updated right now for the ASUS/KGPE-D16 board looked
inactive for a significant time.


Personally, I think it's a bad plan to remove the AGESA code.
Throwing away the code that AMD has given us is telling them that they
were right, and they shouldn't bother opening the source. This is a
total contradiction of what we ACTUALLY want, which is the source code
for the binary PI releases.

If it's still decided to remove the AGESA family 10/15 codebases, my
thought would be to wait for at least the 4.3 release. That's going
to be 3 months from now, giving us some time to finish getting in the
code that's supposed to replace it and giving it time to stabilize.

Martin
Post by Wim Vervoorn
Sounds like a good idea to create a branch of these but shouldn't that be done for other boards as well.
So when you intend to remove boards to create version 4.2 you create a 4.1 branch of the existing state with those boards included. Then remove all boards that need to be dropped.
When it's handled this way it's probably easier to drop boards that aren't used actively and thereby dropping unnecessary maintenance work.
BR Wim
-----Original Message-----
Sent: Tuesday, October 27, 2015 9:35 AM
Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
Post by Alex G.
Post by Martin Roth
I'd like to start a discussion about boards, chipsets, drivers, or
other code that can be removed from the tree.
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming
native support, I don't think we want to haul around the AGESA
implementations, which have been troublesome in the past.
Actually, branch off those boards, keep them alive in their little
branch, but remove them from master.
Hm maybe. It's important that the boards which use AGESA are still available somehow, so that they could be ported to coreboot init if someone has interest in doing that. Maybe a branch is good enough.
//Peter
--
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Timothy Pearson
2015-10-27 18:52:32 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Martin Roth
The current thought is to create a new branch for 4.2, *THEN* remove
the decided upon code from the master branch.
This removes the maintenance work on master going forward while
providing a known point if someone wants to pick up the boards going
forward.
I don't understand the question about creating a branch for other
boards as well. The branch would contain all current boards.
The question is really about what boards/code are inactive. The code
that's being updated right now for the ASUS/KGPE-D16 board looked
inactive for a significant time.
Personally, I think it's a bad plan to remove the AGESA code.
Throwing away the code that AMD has given us is telling them that they
were right, and they shouldn't bother opening the source. This is a
total contradiction of what we ACTUALLY want, which is the source code
for the binary PI releases.
If it's still decided to remove the AGESA family 10/15 codebases, my
thought would be to wait for at least the 4.3 release. That's going
to be 3 months from now, giving us some time to finish getting in the
code that's supposed to replace it and giving it time to stabilize.
Martin
If I may add to this discussion, much of the rationale for dropping
AGESA has to do with the largely incompatible design (and coding style)
of AGESA versus the rest of coreboot. By encouraging the use of AGESA
over native intialization, not only does the native initialization code
receive less attention, but development of new features (such as
timestamping and early CBMEM) is also hampered.

- From what I understand, what coreboot actually wants is access the
source code, but not necessarily to just use the source code as-is.
Would it make more sense to keep the vendorcode available, but put a
large warning on it that boards using said vendorcode are not supported
(and remove them from Jenkins builds, etc.)? Maybe even moving those
boards to a different subdirectory (vendor_shim_mainboards) would help
reinforce this idea.

- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWL8fwAAoJEK+E3vEXDOFbaq8IAJM1L/hOMN5u1uitpqtNQVWW
s6iAWYmmemH/1vIzMCk1GBp6RRLpd1Na7fNFIIoCY8hBV2VQY+oLge7AQ2BMqhGQ
exzCKgDLaR9b1icktnho2kDXVShUkv+WMCQPetKXV4VPHZ4sudqjRS1GWqqVtXx2
fKPnopESqreOdBP+dg1fCygN1MeKtZM1Sort2+j0Uxfvog1VNHzZ18AMrZXNQNMr
armK/JwwxAq7Ku5MbxkH0+zV6G+VxrVYfkOV7bEtgcHtnpRRPA32dLGLIwcoM7Ea
xcqrsehZSN+5K8+dskRFGVVWekpb0i7cX+UBg1GiIC7nJXpfIAreRckmtcVkXOY=
=MdqC
-----END PGP SIGNATURE-----
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
ron minnich
2015-10-27 19:20:25 UTC
Permalink
The AGESA code was always an awkward fit into coreboot. It was more like a
badly designed artificial limb than a real part of the code base. I
understand the idea of encouraging vendors to commit source but, at this
point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful
in its time but I think I'm with tpearson on this point.

I believe we should drop AGESA on any boards that have native support, and
the sooner the better.

ron
David Hendricks
2015-10-27 19:35:27 UTC
Permalink
This all sounds fine from a developer's perspective, but what about AMD's
customers? I honestly have no clue if the decision to use an AMD product
with coreboot hinges on whether AMD's supplied AGESA code is used or not.
But I can imagine ripping out the AMD-supplied code might make it difficult
for AMD to support customers who use coreboot.

I'm sure there are people on this list who _have actually supported
customers_ using AMD products and coreboot, so I'd like to hear their
perspective.

/my $0.02.
Post by ron minnich
The AGESA code was always an awkward fit into coreboot. It was more like a
badly designed artificial limb than a real part of the code base. I
understand the idea of encouraging vendors to commit source but, at this
point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful
in its time but I think I'm with tpearson on this point.
I believe we should drop AGESA on any boards that have native support, and
the sooner the better.
ron
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
Aaron Durbin
2015-10-27 19:40:56 UTC
Permalink
Post by David Hendricks
This all sounds fine from a developer's perspective, but what about AMD's
customers? I honestly have no clue if the decision to use an AMD product
with coreboot hinges on whether AMD's supplied AGESA code is used or not.
But I can imagine ripping out the AMD-supplied code might make it difficult
for AMD to support customers who use coreboot.
I'm sure there are people on this list who _have actually supported
customers_ using AMD products and coreboot, so I'd like to hear their
perspective.
/my $0.02.
The code lives on a branch. People are more than happy to work within
that branch. That's exactly what branches are for.

I'll one up the recommendation and suggest all non-romcc code that
#includes C files gets removed after the branch point. Or do such a
thing in the next release. I'm sick of having to deal with and
fighting against these development constructs.
Post by David Hendricks
Post by ron minnich
The AGESA code was always an awkward fit into coreboot. It was more like a
badly designed artificial limb than a real part of the code base. I
understand the idea of encouraging vendors to commit source but, at this
point, the AMD ship has sailed off to Port Binary Blob. AGESA was helpful in
its time but I think I'm with tpearson on this point.
I believe we should drop AGESA on any boards that have native support, and
the sooner the better.
ron
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Vladimir
2015-10-27 20:10:31 UTC
Permalink
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
Post by David Hendricks
Post by David Hendricks
This all sounds fine from a developer's perspective, but what about AMD's
customers? I honestly have no clue if the decision to use an AMD product
with coreboot hinges on whether AMD's supplied AGESA code is used or not.
But I can imagine ripping out the AMD-supplied code might make it
difficult
Post by David Hendricks
for AMD to support customers who use coreboot.
I'm sure there are people on this list who _have actually supported
customers_ using AMD products and coreboot, so I'd like to hear their
perspective.
/my $0.02.
The code lives on a branch. People are more than happy to work within
that branch. That's exactly what branches are for.
I'll one up the recommendation and suggest all non-romcc code that
#includes C files gets removed after the branch point. Or do such a
thing in the next release. I'm sick of having to deal with and
fighting against these development constructs.
Post by David Hendricks
Post by ron minnich
The AGESA code was always an awkward fit into coreboot. It was more
like a
Post by David Hendricks
Post by ron minnich
badly designed artificial limb than a real part of the code base. I
understand the idea of encouraging vendors to commit source but, at this
point, the AMD ship has sailed off to Port Binary Blob. AGESA was
helpful in
Post by David Hendricks
Post by ron minnich
its time but I think I'm with tpearson on this point.
I believe we should drop AGESA on any boards that have native support,
and
Post by David Hendricks
Post by ron minnich
the sooner the better.
ron
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
http://www.coreboot.org/mailman/listinfo/coreboot
Timothy Pearson
2015-10-27 20:15:09 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vladimir
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.

- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWL9tLAAoJEK+E3vEXDOFbGXEH/Ar/eErlZp8biCEOO3EUKXN3
CXpvDMgjsWf8k0jmlW25ythzyEuD1fLsVhD84GvvO0anwMhT66IXtHVAyXUegd7T
+iJd1MmthsSJRNW8xLhu9r+YEZInLAlq56HZ7ebnwbVmeokRhUdfCKUkUshPOO0N
73v5Q7SLQbhR8NwWzDF9jYF/DJyqfkgO1boBxDDGeV5XPzy5Ho+fwPFrH+E47nes
4u1uNxu8MYQvDoQzxIc/HE9scAhl79kuk3GUuiuoe6RlreKPlrFQVK0Rb+yIe/n+
63mz53ZLdHCoglQLiGpMYlrQDSgzwvHH7i+lfavacgctJd7+Q0n5MFh9TppN4Uc=
=G6dr
-----END PGP SIGNATURE-----
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Vladimir
2015-10-27 20:36:47 UTC
Permalink
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 (still could not understand why some
incredibly talented coreboot developers are spending so much time fighting
Intel's ME issues, while AMD boards don't have that "dragon you have to
tame" on board)

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! Why AMD boards are considered worse? The
sole idea of AMD code going away, which will affect many alive-and-kicking
coreboot-supported AMD boards, is beyond my comprehension

On 27 October 2015 at 23:15, Timothy Pearson <
Post by Timothy Pearson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vladimir
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.
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJWL9tLAAoJEK+E3vEXDOFbGXEH/Ar/eErlZp8biCEOO3EUKXN3
CXpvDMgjsWf8k0jmlW25ythzyEuD1fLsVhD84GvvO0anwMhT66IXtHVAyXUegd7T
+iJd1MmthsSJRNW8xLhu9r+YEZInLAlq56HZ7ebnwbVmeokRhUdfCKUkUshPOO0N
73v5Q7SLQbhR8NwWzDF9jYF/DJyqfkgO1boBxDDGeV5XPzy5Ho+fwPFrH+E47nes
4u1uNxu8MYQvDoQzxIc/HE9scAhl79kuk3GUuiuoe6RlreKPlrFQVK0Rb+yIe/n+
63mz53ZLdHCoglQLiGpMYlrQDSgzwvHH7i+lfavacgctJd7+Q0n5MFh9TppN4Uc=
=G6dr
-----END PGP SIGNATURE-----
Timothy Pearson
2015-10-27 20:41:08 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vladimir
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 (still could not understand why some
incredibly talented coreboot developers are spending so much time
fighting Intel's ME issues, while AMD boards don't have that "dragon you
have to tame" on board)
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! Why AMD boards are
considered worse? The sole idea of AMD code going away, which will
affect many alive-and-kicking coreboot-supported AMD boards, is beyond
my comprehension
This is why I was advocating a gentle demotion to second class status.
You can still use the AGESA code where needed, but native intialization
would be preferred for new ports.

- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWL+FhAAoJEK+E3vEXDOFbjmIIAK3Tf/KBLQH92uCJsCn5ekJv
S5hE1LdDBvRXM5p3xZWarqnomfvbxeNP8fg9PfOixxDLLSE/gWKE5B1H119le5Dl
aXU99ge7dMefZ9uxm0zfjKLvCsS/vc7ESqC+KKcYxK0Q1KswF/g6wLeaG8LS18wQ
W83gZCTdFjW8YhTnxu8kzmXDT+2vT5CSSGQoN0d6gD0WZrti7gLCL1m9Nu5stnKt
Kul93N7KmVYhdUAIBzyrsTl5/JV5JzOXgHFVUvhrUa1XqRk5DC1MjHHaTYA6W1kT
+f5m9HnBTGP6G4agtHBiScq/XBCl7+MdMkx3Ecb32QMgyvcSlG3UMLXiax2UHYA=
=nXMZ
-----END PGP SIGNATURE-----
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
David Hendricks
2015-10-27 21:10:18 UTC
Permalink
On Tue, Oct 27, 2015 at 1:41 PM, Timothy Pearson <
Post by Timothy Pearson
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Vladimir
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 (still could not understand why some
incredibly talented coreboot developers are spending so much time
fighting Intel's ME issues, while AMD boards don't have that "dragon you
have to tame" on board)
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! Why AMD boards are
considered worse? The sole idea of AMD code going away, which will
affect many alive-and-kicking coreboot-supported AMD boards, is beyond
my comprehension
This is why I was advocating a gentle demotion to second class status.
You can still use the AGESA code where needed, but native intialization
would be preferred for new ports.
Ah, thanks for the clarification. I think I had a knee-jerk reaction since
the idea of ripping out AGESA entirely has been floated in the past. This
seems like a decent approach.
Post by Timothy Pearson
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJWL+FhAAoJEK+E3vEXDOFbjmIIAK3Tf/KBLQH92uCJsCn5ekJv
S5hE1LdDBvRXM5p3xZWarqnomfvbxeNP8fg9PfOixxDLLSE/gWKE5B1H119le5Dl
aXU99ge7dMefZ9uxm0zfjKLvCsS/vc7ESqC+KKcYxK0Q1KswF/g6wLeaG8LS18wQ
W83gZCTdFjW8YhTnxu8kzmXDT+2vT5CSSGQoN0d6gD0WZrti7gLCL1m9Nu5stnKt
Kul93N7KmVYhdUAIBzyrsTl5/JV5JzOXgHFVUvhrUa1XqRk5DC1MjHHaTYA6W1kT
+f5m9HnBTGP6G4agtHBiScq/XBCl7+MdMkx3Ecb32QMgyvcSlG3UMLXiax2UHYA=
=nXMZ
-----END PGP SIGNATURE-----
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
ron minnich
2015-10-27 21:32:40 UTC
Permalink
I think we can make it clear to AMD that we are grateful for AGESA and
their support, and the way they have helped us to get to a good place in
terms of code; and, further, we can now offer a better option, with code
that really fits well into coreboot.

I don't see demoting AGESA as a bad thing; it's a good thing. AGESA got us
to where we are, and now we take the next step: code that is well
integrated. In fact I think we're all giving AMD a huge vote of confidence
by making the effort to make their chips fit really well into coreboot,
instead of being half-in/half-out. This is going to be a big improvement.

We're not tossing AMD out; we're inviting them into the living room, with a
warm fire and a nice place to sit down and relax :-)

ron
Vladimir
2015-10-27 22:17:14 UTC
Permalink
Thank you for this enlightening message about blobgesa... Luckily AMD was
10 years slow at following Intel's ME example, 10 years since ME first
version, and it was not until 2015 that built-in Platform Secure Processors
completely took over the AMD's Mobility family ( Kaveri from 2014 still
didnt have PSP ) . Desktop family has 2015 Godavari without the PSP. It
seems that PSP-blobgesa plague is going from low end to high end direction,
and - while it took over the mobility family - desktop high end is still
OK, and server family is far from it (so far only low end "seattle" servers
are affected)

Hopefully this blobgesa will be open sourced eventually - its not that far
from reality because AMD open sourced a lot of stuff during the past
months... Also it will be very interesting to see how AMD Zen platforms
will behave

Best regards,
Vladimir Shipovalov
if you would check a "Binary situation" page at coreboot's wiki, you would
see that Intel is in three times more evil
That page is outdated. Newer AMD systems have the platform security
processor, which is quite similiar to the ME.
http://www.uefi.org/sites/default/files/resources/UEFI_PlugFest_AMD_Security_and_Server_innovation_AMD_March_2013.pdf
has some information on the PSP.
Chips with PSP are btw. only supported by blobgesa.
Also the AGESA source is quite a mess (I started to do some cleanups
there, but finally dropped the project, because it wasn't worth the time
for me) and having native initialization will be much better.
Regards
Felix
Alex G.
2015-10-28 03:56:21 UTC
Permalink
Post by Vladimir
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.
Post by Vladimir
(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.
Post by Vladimir
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.
Post by Vladimir
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)
Post by Vladimir
which will affect many alive-and-kicking coreboot-supported AMD boards,
How will moving code around affect supported boards?
Post by Vladimir
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] Loading Image...
Post by Vladimir
On 27 October 2015 at 23:15, Timothy Pearson
Post by Vladimir
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.org
http://www.coreboot.org/mailman/listinfo/coreboot
Wim Vervoorn
2015-10-28 07:51:29 UTC
Permalink
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-***@coreboot.org] On Behalf Of Alex G.
Sent: Wednesday, October 28, 2015 4:56 AM
To: ***@coreboot.org
Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
Post by Vladimir
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.
Post by Vladimir
(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.
Post by Vladimir
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.
Post by Vladimir
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)
Post by Vladimir
which will affect many alive-and-kicking coreboot-supported AMD boards,
How will moving code around affect supported boards?
Post by Vladimir
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
Post by Vladimir
On 27 October 2015 at 23:15, Timothy Pearson
Post by Vladimir
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.org http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Patrick Georgi
2015-10-28 08:32:45 UTC
Permalink
Post by Alex G.
Here's a list of things I think should be moved to branches, right after
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.
Post by Alex G.
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
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
--
coreboot mailing list: ***@corebo
Vladimir
2015-10-28 12:59:18 UTC
Permalink
How will moving [AGESA] code [to a separate branch] affect supported
[AMD] boards?
The biggest problem here is:

Various improvements and important bug fixes, that will be introduced to a
master branch and affect all the coreboot boards, will not be automatically
applied to that separate AMD branch. Those coreboot developers which have
AMD boards and want to constantly use and test latest and greatest coreboot
builds, they will have to constantly check the coreboot commit log and
backport all these improvements and fixes to their separate (and soon to be
abandoned) AMD branch. That will be adding lots of unnecessary manual work
and draining lots of workhours, which otherwise could have been spent on
writing the bug reports or improving a coreboot code which is common for
all the coreboot-supported boards.

As result, moving AGESA code will affect - and not only AMD boards: all the
coreboot supported boards will be indirectly negatively affected by that
change...
Perhaps in the short term we can port the remaining AGESA Fam15h boards
to native init, and look into moving Fam14h to as much native as
possible while still keeping the PSP happy with its blobs?
If the AGESA boards will be ported to a native init, they will be able to
continue to be supported by a master branch! That approach will allow
coreboot developers with AMD boards to avoid spending time on backporting
the changes and concentrate on developing and testing the latest coreboot
builds from a master branch

Best regards,
Vladimir Shipovalov
Post by Alex G.
Here's a list of things I think should be moved to branches, right after
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.
Post by Alex G.
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
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
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
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
GeschÀftsfÌhrer: Matthew Scott Sucherman, Paul Terence Manicle
--
http://www.coreboot.org/mailman/listinfo/coreboot
Patrick Georgi
2015-10-28 13:24:39 UTC
Permalink
Post by Vladimir
If the AGESA boards will be ported to a native init, they will be able to
continue to be supported by a master branch! That approach will allow
coreboot developers with AMD boards to avoid spending time on backporting
the changes and concentrate on developing and testing the latest coreboot
builds from a master branch
I agree. Patches accepted.


Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
--
coreboot mailing list: ***@coreboot.org
http:/
Aaron Durbin
2015-10-28 13:52:15 UTC
Permalink
Post by Vladimir
How will moving [AGESA] code [to a separate branch] affect supported [AMD]
boards?
Various improvements and important bug fixes, that will be introduced to a
master branch and affect all the coreboot boards, will not be automatically
applied to that separate AMD branch. Those coreboot developers which have
AMD boards and want to constantly use and test latest and greatest coreboot
builds, they will have to constantly check the coreboot commit log and
backport all these improvements and fixes to their separate (and soon to be
abandoned) AMD branch. That will be adding lots of unnecessary manual work
and draining lots of workhours, which otherwise could have been spent on
writing the bug reports or improving a coreboot code which is common for all
the coreboot-supported boards.
Those developers should then take a more active role in improving the
code that is applicable to them. As it stands now, I don't see any
work going in improving those code bases.
Post by Vladimir
As result, moving AGESA code will affect - and not only AMD boards: all the
coreboot supported boards will be indirectly negatively affected by that
change...
Perhaps in the short term we can port the remaining AGESA Fam15h boards
to native init, and look into moving Fam14h to as much native as
possible while still keeping the PSP happy with its blobs?
If the AGESA boards will be ported to a native init, they will be able to
continue to be supported by a master branch! That approach will allow
coreboot developers with AMD boards to avoid spending time on backporting
the changes and concentrate on developing and testing the latest coreboot
builds from a master branch
There's more to it than just moving to native init. That doesn't
remove the maintenance burden.
Post by Vladimir
Best regards,
Vladimir Shipovalov
Post by Alex G.
Here's a list of things I think should be moved to branches, right after
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.
Post by Alex G.
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
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
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
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/corebo
Aaron Durbin
2015-10-28 13:50:10 UTC
Permalink
Post by Patrick Georgi
Post by Alex G.
Here's a list of things I think should be moved to branches, right after
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.
Post by Alex G.
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
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
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.
That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.

What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient. From
the few years that I have been involved in this project I have seen
the airplanes pile up in the graveyard. So basically, it seems like
status quo rules. Or the time horizon for change is so long (10 years)
that the result is accumulation of more cruft? To add insult to injury
there's no tenable way of making changes in these areas because the
physical resources are not readily available to test against. As such
there is no progress in fixing those inconveniences which in turn
means an ever increasing burden for making non-periphery changes.

Ignoring the #include "file.c" constructs, a large majority of the
mainboards drive romstage flow entirely within those directories. i.e.
main() starts in mainboard. There is no common/consistent flow for
romstage on x86. That requires chipset as well as mainboard changes to
rectify. How do you propose one goes about doing that? Build test it?
Then have someone come 6 months later and say "hey, this doesn't
work."
Post by Patrick Georgi
tl;dr: hiding problems in branches won't serve us long-term.
What does serve us long-term? And what are those goals? Is it
quantifiable by the number of mainboards checked into the coreboot.org
repo that build regardless of the maintenance burden?
Post by Patrick Georgi
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/ma
Patrick Georgi
2015-10-28 14:15:18 UTC
Permalink
Post by Aaron Durbin
That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.
What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient.
For one: when things are considered too inconvenient (and used and
maintained) to be practical to keep around, remove them. For real.
Claiming that we can stuff them "in branches" is a cop-out, because
they're still dead.

That's also why I proposed to go with tags for releases: When people
are motivated enough to dig out the old stuff and make it work again,
there should be some incentive to bring them up to current standards.
Then they can get back into master.
If somebody is spearheading such an effort and provides test
resources, I think there's even some willingness to help with some of
the more mechanical tasks - like cleaning out #include "file.c" stuff,
but the motivation is rather hard to get by when it's unclear if the
code is ever used again.

People can still take any old commit (tagged, branched, or not) and do
their own thing on github - however I think we're setting standards by
what we do. Opening branches encourages to keep basing work on them,
instead of considering snapshots to be just that.

My main objection to dropping things was that the motivation by the
proponents always looked very similar to "this is inconvenient to me
right now, let's get rid of this".
If we were consequential in following up every such sentiment by
everyone, we'd probably ship a single file, COPYING.


Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/li
Aaron Durbin
2015-10-28 14:30:47 UTC
Permalink
Post by Patrick Georgi
Post by Aaron Durbin
That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.
What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient.
For one: when things are considered too inconvenient (and used and
maintained) to be practical to keep around, remove them. For real.
Claiming that we can stuff them "in branches" is a cop-out, because
they're still dead.
That's also why I proposed to go with tags for releases: When people
are motivated enough to dig out the old stuff and make it work again,
there should be some incentive to bring them up to current standards.
Then they can get back into master.
If somebody is spearheading such an effort and provides test
resources, I think there's even some willingness to help with some of
the more mechanical tasks - like cleaning out #include "file.c" stuff,
but the motivation is rather hard to get by when it's unclear if the
code is ever used again.
Where is that motivation now? There is no one providing the resources
so the answer is status quo which in turn means an insanely daunting
task in trying to clean up things that just so happen to touch 90% of
the mainboards because of the existing code flow/design. Without the
resources nothing can be done which means accumulation of cruft and no
idea if anyone uses anything. What's the end game there?

Maybe it doesn't matter because all the work required has been
completed going forward so one can just keep cranking out boards, but
I suspect that is not the case. And when another requirement surfaces
that no one was anticipating do we add yet another API/subset on how
to do things? Where's the common base to work against?
Post by Patrick Georgi
People can still take any old commit (tagged, branched, or not) and do
their own thing on github - however I think we're setting standards by
what we do. Opening branches encourages to keep basing work on them,
instead of considering snapshots to be just that.
What are the standards we're setting?
Post by Patrick Georgi
My main objection to dropping things was that the motivation by the
proponents always looked very similar to "this is inconvenient to me
right now, let's get rid of this".
If we were consequential in following up every such sentiment by
everyone, we'd probably ship a single file, COPYING.
I think you're taking such a notion to the extreme. Probably the
superset of opinion may be that, but I don't think that's practical
nor helpful in this discussion. I've cited very specific things that I
have run into within my development, and I don't see a solution aside
from "tred lightly, hold your nose, and hope for the best". I'd be
happy to help support said improvement work, but there's no path for
such things, and the carrot of getting back into the sacred master
branch is apparently unpalatable for people.

From my vantage point it seems people want the playground they grew up
with and knew and loved. Therefore, don't ever change my playground.
Post by Patrick Georgi
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/core
Martin Roth
2015-10-28 15:48:15 UTC
Permalink
It seems that we've got more issues than we can address before the
proposed 4.2 release date within the next few days - we're trying to
get this out in October.

Maybe it's time for another 'Major' release where we can remove more
than just the few mainboards and truly obsolete code that I was
thinking of when I started this conversation.

Is there anyone against removal of any of these boards/chipsets after
the 4.2 release, or should we wait for a decision about handling all
of the current issues before we delete anything?

mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
* arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131
* digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855,
SB: INTEL_I82801DX
* ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* newisys/khepri - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* tyan/s2735 - CPU: INTEL_SOCKET_MPGA604, NB: INTEL_E7501, SB:
INTEL_I82870, SB: INTEL_I82801EX
* tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111
* tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151
* tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* tyan/s2885 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB:
AMD8131, SB: AMD8151
* tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
* tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
* tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
* tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131


I'd vote against the removal of any of the AGESA codebases for this
release with the possible exception of the Family 12 codebase. It's
only used in the torpedo mainboard, and even that's not well
supported.
I'd vote against the removal of any of the Intel FSP codebases for
this release. They are recent, and they are definitely still being
used. Even Rangeley. Yes, they have their issues.

I could support moving platforms off to the 4.X branch if we decide to
create a 5.0 branch to move forward and get things cleaned up. Still,
having dealt with several different forks of the coreboot code, my
opinion is that branching is basically going to end the support for
these platforms. Of course the people that don't use those platforms
don't care whether coreboot is killed off for those platforms, so I'd
ask that these platforms that we're choosing to die be picked
carefully.
Post by Aaron Durbin
Post by Patrick Georgi
Post by Aaron Durbin
That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.
What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient.
For one: when things are considered too inconvenient (and used and
maintained) to be practical to keep around, remove them. For real.
Claiming that we can stuff them "in branches" is a cop-out, because
they're still dead.
That's also why I proposed to go with tags for releases: When people
are motivated enough to dig out the old stuff and make it work again,
there should be some incentive to bring them up to current standards.
Then they can get back into master.
If somebody is spearheading such an effort and provides test
resources, I think there's even some willingness to help with some of
the more mechanical tasks - like cleaning out #include "file.c" stuff,
but the motivation is rather hard to get by when it's unclear if the
code is ever used again.
Where is that motivation now? There is no one providing the resources
so the answer is status quo which in turn means an insanely daunting
task in trying to clean up things that just so happen to touch 90% of
the mainboards because of the existing code flow/design. Without the
resources nothing can be done which means accumulation of cruft and no
idea if anyone uses anything. What's the end game there?
Maybe it doesn't matter because all the work required has been
completed going forward so one can just keep cranking out boards, but
I suspect that is not the case. And when another requirement surfaces
that no one was anticipating do we add yet another API/subset on how
to do things? Where's the common base to work against?
Post by Patrick Georgi
People can still take any old commit (tagged, branched, or not) and do
their own thing on github - however I think we're setting standards by
what we do. Opening branches encourages to keep basing work on them,
instead of considering snapshots to be just that.
What are the standards we're setting?
Post by Patrick Georgi
My main objection to dropping things was that the motivation by the
proponents always looked very similar to "this is inconvenient to me
right now, let's get rid of this".
If we were consequential in following up every such sentiment by
everyone, we'd probably ship a single file, COPYING.
I think you're taking such a notion to the extreme. Probably the
superset of opinion may be that, but I don't think that's practical
nor helpful in this discussion. I've cited very specific things that I
have run into within my development, and I don't see a solution aside
from "tred lightly, hold your nose, and hope for the best". I'd be
happy to help support said improvement work, but there's no path for
such things, and the carrot of getting back into the sacred master
branch is apparently unpalatable for people.
From my vantage point it seems people want the playground they grew up
with and knew and loved. Therefore, don't ever change my playground.
Post by Patrick Georgi
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.or
ron minnich
2015-10-28 15:53:09 UTC
Permalink
IIRC I did the IBM e325/6 back in the day and I'm happy to see it die.

ron
Post by Martin Roth
It seems that we've got more issues than we can address before the
proposed 4.2 release date within the next few days - we're trying to
get this out in October.
Maybe it's time for another 'Major' release where we can remove more
than just the few mainboards and truly obsolete code that I was
thinking of when I started this conversation.
Is there anyone against removal of any of these boards/chipsets after
the 4.2 release, or should we wait for a decision about handling all
of the current issues before we delete anything?
mainboard/via/epia-m700 - http://review.coreboot.org/#/c/7470
northbridge/via/vx800 - http://review.coreboot.org/#/c/7471
* arima/hdama - CPU: _AMD_SOCKET_940 NB: AMDK8, SB: AMD8111, SB: AMD8131
* digitallogic/adl855pc - CPU: INTEL_SOCKET_MPGA479M, NB: INTEL_I855,
SB: INTEL_I82801DX
* ibm/e325 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* ibm/e326 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* iwill/dk8s2 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* iwill/dk8x - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* newisys/khepri - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
INTEL_I82870, SB: INTEL_I82801EX
* tyan/s2850 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111
* tyan/s2875 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8151
* tyan/s2880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* tyan/s2881 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* tyan/s2882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
AMD8131, SB: AMD8151
* tyan/s2891 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
* tyan/s2892 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
* tyan/s2895 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: NVIDIA_CK804, SB: AMD8131
* tyan/s4880 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
* tyan/s4882 - CPU: AMD_SOCKET_940, NB: AMDK8, SB: AMD8111, SB: AMD8131
I'd vote against the removal of any of the AGESA codebases for this
release with the possible exception of the Family 12 codebase. It's
only used in the torpedo mainboard, and even that's not well
supported.
I'd vote against the removal of any of the Intel FSP codebases for
this release. They are recent, and they are definitely still being
used. Even Rangeley. Yes, they have their issues.
I could support moving platforms off to the 4.X branch if we decide to
create a 5.0 branch to move forward and get things cleaned up. Still,
having dealt with several different forks of the coreboot code, my
opinion is that branching is basically going to end the support for
these platforms. Of course the people that don't use those platforms
don't care whether coreboot is killed off for those platforms, so I'd
ask that these platforms that we're choosing to die be picked
carefully.
Post by Aaron Durbin
Post by Patrick Georgi
Post by Aaron Durbin
That presupposes there is work going on in those branches that is
desired to be pushed back into another branch. Anyone can very much
port forward something if they so choose. That's the point of the
branching mechanism.
What is your proposal for dealing w/ inconvenience? I haven't seen a
modicum of change in that area. In fact, what we have seen is more
boards being added that use the constructs that are inconvenient.
For one: when things are considered too inconvenient (and used and
maintained) to be practical to keep around, remove them. For real.
Claiming that we can stuff them "in branches" is a cop-out, because
they're still dead.
That's also why I proposed to go with tags for releases: When people
are motivated enough to dig out the old stuff and make it work again,
there should be some incentive to bring them up to current standards.
Then they can get back into master.
If somebody is spearheading such an effort and provides test
resources, I think there's even some willingness to help with some of
the more mechanical tasks - like cleaning out #include "file.c" stuff,
but the motivation is rather hard to get by when it's unclear if the
code is ever used again.
Where is that motivation now? There is no one providing the resources
so the answer is status quo which in turn means an insanely daunting
task in trying to clean up things that just so happen to touch 90% of
the mainboards because of the existing code flow/design. Without the
resources nothing can be done which means accumulation of cruft and no
idea if anyone uses anything. What's the end game there?
Maybe it doesn't matter because all the work required has been
completed going forward so one can just keep cranking out boards, but
I suspect that is not the case. And when another requirement surfaces
that no one was anticipating do we add yet another API/subset on how
to do things? Where's the common base to work against?
Post by Patrick Georgi
People can still take any old commit (tagged, branched, or not) and do
their own thing on github - however I think we're setting standards by
what we do. Opening branches encourages to keep basing work on them,
instead of considering snapshots to be just that.
What are the standards we're setting?
Post by Patrick Georgi
My main objection to dropping things was that the motivation by the
proponents always looked very similar to "this is inconvenient to me
right now, let's get rid of this".
If we were consequential in following up every such sentiment by
everyone, we'd probably ship a single file, COPYING.
I think you're taking such a notion to the extreme. Probably the
superset of opinion may be that, but I don't think that's practical
nor helpful in this discussion. I've cited very specific things that I
have run into within my development, and I don't see a solution aside
from "tred lightly, hold your nose, and hope for the best". I'd be
happy to help support said improvement work, but there's no path for
such things, and the carrot of getting back into the sacred master
branch is apparently unpalatable for people.
From my vantage point it seems people want the playground they grew up
with and knew and loved. Therefore, don't ever change my playground.
Post by Patrick Georgi
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Hamburg
Post by Aaron Durbin
Post by Patrick Georgi
GeschÀftsfÌhrer: Matthew Scott Sucherman, Paul Terence Manicle
--
http://www.coreboot.org/mailman/listinfo/coreboot
--
http://www.coreboot.org/mailman/listinfo/coreboot
Peter Stuge
2015-10-28 14:00:08 UTC
Permalink
branches are where commits are pushed to die.
Yes, this is a very important point, and is why I don't support Alex'
proposal of moving some things to live only on a branch, and not on master.

Branches *can* work really well, but only when there is a person
and/or team actively maintaining that branch, and for that to work
well, the branch needs to have a fairly clear policy. The best
example of this is the Linux kernel.

We don't have the manpower of the Linux kernel however. And I don't
that you're volunteering to maintain the branch, Alex?

I'd like to propose that without a designated maintainer stepping up
we don't create branches other than per the release process that
we're starting to get into.

The AGESA code and older FSP and the other things you list are yes
older and less shiny than the new native code, but also more proven.

It's not a good idea to sweep older code under a branchy carpet until
newer code is generally felt to be equal or better. I don't think
that's the case yet, it's just too early.


//Peter
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Alex G.
2015-10-28 15:43:37 UTC
Permalink
Post by Peter Stuge
branches are where commits are pushed to die.
Yes, this is a very important point, and is why I don't support Alex'
proposal of moving some things to live only on a branch, and not on master.
So, tagging and removing is better than a branch where people can
continue to work, and submit patches via coreboot.org? I guess we'd much
rather just remove stuff than allow people to continue using it, right?
I guess we want to disallow people the ability to backport features to
their hardware, and just remove it instead.
Post by Peter Stuge
Branches *can* work really well, but only when there is a person
and/or team actively maintaining that branch, and for that to work
well, the branch needs to have a fairly clear policy. The best
example of this is the Linux kernel.
If branches die out they die out. That means there isn't interest in
that hardware. Big deal.
Post by Peter Stuge
We don't have the manpower of the Linux kernel however. And I don't
that you're volunteering to maintain the branch, Alex?
Do you offer to maintain the problematic code going forward?
Post by Peter Stuge
I'd like to propose that without a designated maintainer stepping up
we don't create branches other than per the release process that
we're starting to get into.
I'd like to propose that without a designated maintainer stepping up, we
just remove the code. Experience tells us that people are silent until
their (broken) toys are taken away, and only then start crying. Just
look at the fiasco (in no particular order) Marc, Martin, and Ron caused
after sandybrdge fsp got removed. Branches might prevent that.
Post by Peter Stuge
The AGESA code and older FSP and the other things you list are yes
older and less shiny than the new native code, but also more proven.
The need to make changes to core code whenever a new mainboard is added
is proven indeed.

Alex
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Peter Stuge
2015-10-28 16:44:15 UTC
Permalink
Post by Alex G.
Post by Peter Stuge
branches are where commits are pushed to die.
Yes, this is a very important point, and is why I don't support Alex'
proposal of moving some things to live only on a branch, and not on master.
So, tagging and removing is better than a branch where people can
continue to work, and submit patches via coreboot.org?
I think you are confusing things. I disagree with removing the things
you listed.

Here's a brief summary of the release process as I understand it:

For each release a tag and a branch are created, and on master some
old things are then immediately removed. I disagree with removing the
things you have listed for this release.


The community works on what interests them. Some work will go only into
the post-release branch, and some work goes only into master. That's OK.

The post-release branch is second class in the sense that anything
happening there does not have to fit into master. It is first class
in the sense that larger changes in master do not have to be worked
into code removed after the release.


However, this is not what we are discussing.

We are discussing whether the things you listed should stay on master
or not, after the current release, and I strongly feel that most if
not all of them should.

I do not think that there is any urgency.
Post by Alex G.
Post by Peter Stuge
Branches *can* work really well, but only when there is a person
and/or team actively maintaining that branch, and for that to work
well, the branch needs to have a fairly clear policy. The best
example of this is the Linux kernel.
If branches die out they die out. That means there isn't interest in
that hardware. Big deal.
I'm afraid it just isn't that simple.
Post by Alex G.
Post by Peter Stuge
We don't have the manpower of the Linux kernel however. And I don't
that you're volunteering to maintain the branch, Alex?
Do you offer to maintain the problematic code going forward?
We are already doing all right there, and I don't see it as problematic.
Post by Alex G.
Post by Peter Stuge
I'd like to propose that without a designated maintainer stepping up
we don't create branches other than per the release process that
we're starting to get into.
I'd like to propose that without a designated maintainer stepping up, we
just remove the code.
I think that's too large a change compared to how the community has
worked before to be either practical or useful.

I don't think this is a bad end goal for us to have, but I also don't
believe that we can go from A to Z in a single step.
Post by Alex G.
Just look at the fiasco (in no particular order) Marc, Martin, and
Ron caused after sandybrdge fsp got removed.
From what I can tell that was caused by you, but that's getting off topic.


//Peter
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Gerd Hoffmann
2015-10-29 09:52:53 UTC
Permalink
Post by Alex G.
Post by Peter Stuge
branches are where commits are pushed to die.
Yes, this is a very important point, and is why I don't support Alex'
proposal of moving some things to live only on a branch, and not on master.
So, tagging and removing is better than a branch where people can
continue to work, and submit patches via coreboot.org?
Typically branches are used for two purposes:

(1) stable releases. Tag v4.2, branch off, possibly tag v4.2.1 bugfix
Typically no development happens here, often projects even have the
policy that fixes need to land in master before they are allowed to
be cherry-picked into a stable branch.

(2) development branches. New stuff, intended to be merged in master.

Have a branch to park unliked code there is just a bad excuse IMO.
Don't do that.

If there is dead code, i.e. boards not being sold any more and not
having seen updates (other than tree-wide cleanups) for years -- just
remove them, and document the last release supporting that hardware.

For AGESA I don't think it should be removed. Even if the plan is to
obsolete the code some day with native support in codeboot -- I think
for the time being it is useful for developers to be able to look at the
code, to be able to build agesa/native versions of a board from the same
coreboot code base, for regression testing and bringing native on par
with agesa ...

cheers,
Gerd
--
coreboot mailing list: ***@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Continue reading on narkive:
Loading...