coreboot for the 21st century
setting up the project for the next decade
Purpose: Purge all boards / chipsets / cpus that require ROMCC in romstage and known broken chipsets (sc520, i855)
coreboot is now officially 15 years old. One and a half long decades with ups and downs. During this time we collected over 250 different mainboards. A great achievement, but also a great maintenance burden.
* It is hard to keep 250+ mainboards working. Actually impossible. * Keeping them working comes at a cost. Keep old infrastructure around. Workarounds, special cases * We don’t test except on the very last stuff we’re working on
To fix this issue, we suggest to establish a process to obsolete old hardware in a controlled way. Getting rid of old baggage is great and liberating for future products, but it is also one of the moves the strictly hobbyist community considers corporate driven. Hence, we want to satisfy both a speedy light-weight development process and keeping all the good coreboot legacy alive.
For the first time in 2014, and every few years after that (e.g. every two years), we will create a new “community branch” that focusses on older mainboards. This branch will start out as an exact copy of ToT coreboot. Suggested name: “coreboot-community-2014” or “coreboot-v4.0”. Then this branch will not get any further new feature development (of features not available in ToT) but only bug fixes for boards to get them working and potentially backports.
After the branch is created, all obsoleted mainboards are removed from the main repository. The version will be coreboot 4.1. Cleanup shall begin to remove all the cruft that we had around to get those old boards working. Each mainboard in v4.1 will have a supporter / owner. New mainboards are not admitted into V4.1 without a supporter / owner.
If somebody in the community wants to keep a board / chipset alive in the tree, they can re-import them by cleaning up the board to work with the new, cruft free infrastructure.
In 2016 we will do the same thing again, and it will become coreboot 6.0
Appendix A: romcc boards to be removed
advantech/pcm-5820 asi/mb_5blgp asi/mb_5blmp axus/tc320 bcom/winnet100 bifferos/bifferboard digitallogic/msm586seg dmp/vortex86ex eaglelion/5bcm iei/juki-511p iei/nova4899r intel/jarrell intel/truxton intel/xe7501devkit supermicro/x6dai_g supermicro/x6dhe_g2 supermicro/x6dhe_g supermicro/x6dhr_ig2 supermicro/x6dhr_ig technologic/ts5300 televideo/tc7020 via/epia via/epia-m via/epia-n
I like this, I just wish we could remove more boards :-)
ron
Actually, this sounds pretty good. When the X99 boards come out, I would actually be interested in "sponsoring" a dev to adopt an X99 mainboard for Coreboot. I would even be willing to have a discussion about various X99 boards, in order to adopt one with the broadest overall interest.
Gary
On Thu, Mar 20, 2014 at 2:33 PM, Stefan Reinauer < stefan.reinauer@coreboot.org> wrote:
coreboot for the 21st century
setting up the project for the next decade
Purpose: Purge all boards / chipsets / cpus that require ROMCC in romstage and known broken chipsets (sc520, i855)
coreboot is now officially 15 years old. One and a half long decades with ups and downs. During this time we collected over 250 different mainboards. A great achievement, but also a great maintenance burden.
- It is hard to keep 250+ mainboards working. Actually impossible.
- Keeping them working comes at a cost. Keep old infrastructure around. Workarounds, special cases
- We don't test except on the very last stuff we're working on
To fix this issue, we suggest to establish a process to obsolete old hardware in a controlled way. Getting rid of old baggage is great and liberating for future products, but it is also one of the moves the strictly hobbyist community considers corporate driven. Hence, we want to satisfy both a speedy light-weight development process and keeping all the good coreboot legacy alive.
For the first time in 2014, and every few years after that (e.g. every two years), we will create a new "community branch" that focusses on older mainboards. This branch will start out as an exact copy of ToT coreboot. Suggested name: "coreboot-community-2014" or "coreboot-v4.0". Then this branch will not get any further new feature development (of features not available in ToT) but only bug fixes for boards to get them working and potentially backports.
After the branch is created, all obsoleted mainboards are removed from the main repository. The version will be coreboot 4.1. Cleanup shall begin to remove all the cruft that we had around to get those old boards working. Each mainboard in v4.1 will have a supporter / owner. New mainboards are not admitted into V4.1 without a supporter / owner.
If somebody in the community wants to keep a board / chipset alive in the tree, they can re-import them by cleaning up the board to work with the new, cruft free infrastructure.
In 2016 we will do the same thing again, and it will become coreboot 6.0
Appendix A: romcc boards to be removed
advantech/pcm-5820 asi/mb_5blgp asi/mb_5blmp axus/tc320 bcom/winnet100 bifferos/bifferboard digitallogic/msm586seg dmp/vortex86ex eaglelion/5bcm iei/juki-511p iei/nova4899r intel/jarrell intel/truxton intel/xe7501devkit supermicro/x6dai_g supermicro/x6dhe_g2 supermicro/x6dhe_g supermicro/x6dhr_ig2 supermicro/x6dhr_ig technologic/ts5300 televideo/tc7020 via/epia via/epia-m via/epia-n
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Thu, 20 Mar 2014 22:33:21 +0100 Stefan Reinauer stefan.reinauer@coreboot.org wrote:
dmp/vortex86ex
What's exactly wrong with that one? DMP ported their SoC themselves less than half a year ago, and I seriously doubt that dropping that already would be a good marketing move for coreboot at all. :)
* Stefan Tauner stefan.tauner@student.tuwien.ac.at [140321 01:42]:
On Thu, 20 Mar 2014 22:33:21 +0100 Stefan Reinauer stefan.reinauer@coreboot.org wrote:
dmp/vortex86ex
What's exactly wrong with that one? DMP ported their SoC themselves less than half a year ago, and I seriously doubt that dropping that already would be a good marketing move for coreboot at all. :)
I noticed that too...
No boards are being dropped, they continue to be present in the 4.0 branch.
Maybe the board can be converted to use cache as ram? (That was the only criteria for any board on the list, as going forward it will be harder and harder to support romcc-romstage boards, at no real benefit)
Stefan
On 03/21/2014 02:58 AM, Stefan Reinauer wrote:
- Stefan Tauner stefan.tauner@student.tuwien.ac.at [140321 01:42]:
On Thu, 20 Mar 2014 22:33:21 +0100 Stefan Reinauer stefan.reinauer@coreboot.org wrote:
dmp/vortex86ex
What's exactly wrong with that one? DMP ported their SoC themselves less than half a year ago, and I seriously doubt that dropping that already would be a good marketing move for coreboot at all. :)
I noticed that too...
No boards are being dropped, they continue to be present in the 4.0 branch.
Maybe the board can be converted to use cache as ram? (That was the only criteria for any board on the list, as going forward it will be harder and harder to support romcc-romstage boards, at no real benefit)
Stefan
There is no MTRR support in vortex86ex.
Kyösti
2014-03-21 19:45 GMT+08:00 Kyösti Mälkki kyosti.malkki@gmail.com:
On 03/21/2014 02:58 AM, Stefan Reinauer wrote:
- Stefan Tauner stefan.tauner@student.tuwien.ac.at [140321 01:42]:
Maybe the board can be converted to use cache as ram? (That was the only criteria for any board on the list, as going forward it will be harder and harder to support romcc-romstage boards, at no real benefit)
There is no MTRR support in vortex86ex.
Yes, that is right. DMP/Vortex86EX has no MTRR. So it maybe a problem if without romcc. :(
On 20.03.2014 22:33, Stefan Reinauer wrote:
coreboot for the 21st century
setting up the project for the next decade
Purpose: Purge all boards / chipsets / cpus that require ROMCC in romstage and known broken chipsets (sc520, i855)
coreboot is now officially 15 years old. One and a half long decades with ups and downs. During this time we collected over 250 different mainboards. A great achievement, but also a great maintenance burden.
- It is hard to keep 250+ mainboards working. Actually impossible.
- Keeping them working comes at a cost. Keep old infrastructure around. Workarounds, special cases
- We don’t test except on the very last stuff we’re working on
The boards and chipsets are sufficiently well insulated from each other so that it's possible to improve one without breaking the others. With board-status the potential users and devs have a good overview which revisions work on which devices. The breakage will periodically occur no matter if it's 25 board or 250 boards. And it will be fixed by those who care about the particular board. Also I feel like the amount of boards supported is actually a relatively minor maintenance burden compared to number of *options* supported. I think we should first go on killing the options noone really uses like possibility disabling ACPI tables (I have a changeset for this, mixed reception), disabling SMBIOS tables. "relocatable" modules should be chosen by chipset, not be user-visible, and so on. There are more broken option configurations than broken boards.
* Vladimir 'φ-coder/phcoder' Serbinenko phcoder@gmail.com [140321 04:13]:
The boards and chipsets are sufficiently well insulated from each other so that it's possible to improve one without breaking the others. With board-status the potential users and devs have a good overview which revisions work on which devices. The breakage will periodically occur no matter if it's 25 board or 250 boards. And it will be fixed by those who care about the particular board.
Somewhat agreed. Yet, there is a certain amount of technical debt caused by boards that went out of production in the early 2000s that keep us from creating clean designs across the board instead of hiding features inside of chipsets and boards. This is exactly what then leads to the problem you are describing next:
Also I feel like the amount of boards supported is actually a relatively minor maintenance burden compared to number of *options* supported. I think we should first go on killing the options noone really uses like possibility disabling ACPI tables (I have a changeset for this, mixed reception), disabling SMBIOS tables. "relocatable" modules should be chosen by chipset, not be user-visible, and so on. There are more broken option configurations than broken boards.
Absolutely agreed. When we moved from coreboot v2 to v4 with the little v3 detour we recognized that there are several levels of "configuration" that happened in Config.lb back then. These were: - build rules hidden in a board config. - board specific configuration (device tree) - user configs determined at build time - user configs determined at runtime (cmos etc)
A lot of that stuff ended up in the same file, and there was no clear abstraction. Then we moved to Kconfig, and away from creating Makefiles at compile time through a nasty python wrapper. However, parsing the device tree to provide compile time options in Kconfig seemed really troublesome, and so we "broke" our clean design of having device specific info in the device tree and only options in Kconfig. Once you go down that road, it becomes a dump really quickly, and now we have to clean up that stuff. My personal opinion is that providing non-choice options to users (like "turn off ACPI and break booting any OS newer than 10ys) are not real options and just messing with the user at the cost of making the build system more complicated.
All in all, there are lots of things awaiting to be fixed in the future.
Stefan
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On 20.03.2014 22:33, Stefan Reinauer wrote:
During this time we collected over 250 different mainboards. A great achievement,
I suppose that most of boards were contributed by non-commercial community. Yet now you propose to basically kill this chicken nesting golden eggs and make coreboot commercial-only. Sorry but your proposition with handling non-commercial community doesn't make any sense at all. You propose to represent the community by small number of people who most likely won't be available enough and who don't represent the community as whole. No single person or small team can represent an entire community, no matter how these persons are knowledgeable and competent. Commercial entity could be represented by one person but a community of independent volunteers can't.
On Fri, Mar 21, 2014 at 7:55 AM, Vladimir 'φ-coder/phcoder' Serbinenko < phcoder@gmail.com> wrote:
I suppose that most of boards were contributed by non-commercial community.
It's much more complicated than that. The initial support for coreboot came from DOE. SiS gve a lot of support with early boards and chipsets, as did via and to some extent Acer. LNXI was tremendous, providing romcc and the alpha port. DOE funded a PowerPC port. AMD gave us AGESA, and their commitment to releasing source began in 2007 and continues to this day. More recently, SAGE gave us several boards, and Google of course gave us the Ivybridge, Sandybridge, Haswell, Baytrail, and ARM ports, including V8. The German Gov't gave us the i945 bits. We got some very nice early contributions for Geode from a community developer, but starting in 2006 AMD committed two full time guys for several years to make it an industrial quality port; their work spanned 3 years. Core Systems carried the ball for many years in Germany, and it was a very lonely time for them.
If you look carefully, or if you have been here since the beginning as I have, you'll realize that your claim here is quite wrong. This is not like Linux. You can no longer just jump in with some docs and get a chipset done in a few months on your own, as I did for the 440gx in 1999. You need a substantial financial commitment to do a chipset, as well as access to documents that are very hard to get in some cases, before you can even start. I estimate based on what I know of the people involved at various companies, and taking a very low burdened headcount cost, that the companies involved have contributed well over $50M to this effort. And that's only taking the people I know. There are lots of others I don't know.
In general, the wonderful work by our non-commercial people has been to take an existing chipset port to a new mainboard -- a lot of work, but anywhere from 10x to 100x less work than the chipset work as I can tell you from experience -- or to improve common code that applies to all motherboards, such as cbfs; and, of course, in addition to coding we see the outstanding job people like Peter do on outreach. Vladimir, you are one of our extreme cases, given your levels of contribution of chipset code for the intel chipset MRC and graphics on the thinkpads :-) How you figured that memory training stuff out I don't know.
It's just not fair to discount the gov't and commercial involvement in coreboot. Without those sustaining commitments over the last 15 years coreboot would not exist. And, like it or not, they represent by far the greatest amount of code that has been contributed to coreboot. You don't have to believe me; check the numbers.
ron
Am Donnerstag, den 20.03.2014, 22:33 +0100 schrieb Stefan Reinauer:
Appendix A: romcc boards to be removed bifferos/bifferboard dmp/vortex86ex
These are unfortunate, since they're relatively new ports (and one of them by the vendor, no less!).
I hope their RAM init is relatively simple - in that case, it might be possible to restrict romcc use to their northbridge code, without affecting common coreboot code.
Patrick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Regarding name for community branch (for maintaining old boards).
On 20/03/14 21:33, Stefan Reinauer wrote:
Suggested name: “coreboot-community-2014” or “coreboot-v4.0”.
Oldboot.
Dear Stefan, dear coreboot folks,
Am Donnerstag, den 20.03.2014, 22:33 +0100 schrieb Stefan Reinauer:
coreboot for the 21st century
setting up the project for the next decade
thank you for starting a public discussion!
Purpose: Purge all boards / chipsets / cpus that require ROMCC in romstage and known broken chipsets (sc520, i855)
coreboot is now officially 15 years old. One and a half long decades with ups and downs. During this time we collected over 250 different mainboards. A great achievement, but also a great maintenance burden.
- It is hard to keep 250+ mainboards working. Actually impossible.
- Keeping them working comes at a cost. Keep old infrastructure around. Workarounds, special cases
- We don’t test except on the very last stuff we’re working on
To fix this issue, we suggest to establish a process to obsolete old hardware in a controlled way. Getting rid of old baggage is great and liberating for future products, but it is also one of the moves the strictly hobbyist community considers corporate driven. Hence, we want to satisfy both a speedy light-weight development process and keeping all the good coreboot legacy alive.
For the first time in 2014, and every few years after that (e.g. every two years), we will create a new “community branch” that focusses on older mainboards. This branch will start out as an exact copy of ToT coreboot. Suggested name: “coreboot-community-2014” or “coreboot-v4.0”. Then this branch will not get any further new feature development (of features not available in ToT) but only bug fixes for boards to get them working and potentially backports.
A question to the Git expert. Is there a way to model the requirements in a different repository structure, for example having a core coreboot repository and putting the chipset, Super IO and boards in separate repositories? I think, the OpenEmbedded/Yocto project does something like this and they call it layers [1]. I have no idea though how that worked out for them. My impression from when they started it was, that the initial setup was more difficult in comparison to having everything in one repository and I guess the layers break more often. Also incentive to care for all the layers might be not so high.
A policy has to set up though, when and how changes to the core repository can be made so that the maintained/supported board layers are not broken.
After the branch is created, all obsoleted mainboards are removed from the main repository. The version will be coreboot 4.1.
I suggest to bump the major number by one, that means coreboot 5. Why not even use the year, so make it coreboot 2014, which is easier to recognize too.
Cleanup shall begin to remove all the cruft that we had around to get those old boards working. Each mainboard in v4.1 will have a supporter / owner. New mainboards are not admitted into V4.1 without a supporter / owner.
Where are these supporters/owners documented? What requirements do they have to fulfill, which if not met cause the board removal?
If somebody in the community wants to keep a board / chipset alive in the tree, they can re-import them by cleaning up the board to work with the new, cruft free infrastructure.
I agree that, people wanting to keep a board in the tree have to help supporting it by at least testing them in a timely manner.
In 2016 we will do the same thing again, and it will become coreboot 6.0
As written above take the year as the version would be useful in my opinion. I also would increase the minor number each time a new board is submitted/merged or an unmaintained one is removed.
Appendix A: romcc boards to be removed
advantech/pcm-5820 asi/mb_5blgp asi/mb_5blmp axus/tc320 bcom/winnet100 bifferos/bifferboard digitallogic/msm586seg dmp/vortex86ex eaglelion/5bcm iei/juki-511p iei/nova4899r intel/jarrell intel/truxton intel/xe7501devkit supermicro/x6dai_g supermicro/x6dhe_g2 supermicro/x6dhe_g supermicro/x6dhr_ig2 supermicro/x6dhr_ig technologic/ts5300 televideo/tc7020 via/epia via/epia-m via/epia-n
As others noted, it has to be decided what to do with boards, that do not adhere to current requirements due to missing hardware features and not because of lack of maintenance/support as the Bifferboard and DMP Vortex86 EX.
Thanks,
Paul
[1] http://www.openembedded.org/wiki/Layers_FAQ [2] http://layers.openembedded.org/layerindex/branch/master/layers/
Am Montag, den 24.03.2014, 10:38 +0100 schrieb Paul Menzel:
A question to the Git expert. Is there a way to model the requirements in a different repository structure, for example having a core coreboot repository and putting the chipset, Super IO and boards in separate repositories?
That's technically possible. It will also multiply the problems people already have with one git submodule (3rdparty) by many, amplified by the fact that these submodules are in no way optional.
I think, the OpenEmbedded/Yocto project does something like this and they call it layers [1].
That's something completely different, which happens at the build system layer. It also builds on mostly independent units, while coreboot is quite an integrated package.
Cleanup shall begin to remove all the cruft that we had around to get those old boards working. Each mainboard in v4.1 will have a supporter / owner. New mainboards are not admitted into V4.1 without a supporter / owner.
Where are these supporters/owners documented?
"MAINTAINERS"
What requirements do they have to fulfill, which if not met cause the board removal?
"they break when useful design changes to the coreboot core are implemented" (eg the "remove all cruft" part)
In this concrete situation, the "cruft" is a bit underspecified. I guess it's about all the __ROMCC__ ifdefs and limits to romstages designed to keep non-CAR boards alive.
If somebody in the community wants to keep a board / chipset alive in the tree, they can re-import them by cleaning up the board to work with the new, cruft free infrastructure.
I agree that, people wanting to keep a board in the tree have to help supporting it by at least testing them in a timely manner.
Testing won't be enough.
Regards, Patrick
-
Andrew Wu -
gary sheppard -
Kyösti Mälkki -
Patrick Georgi -
Paul Menzel -
ron minnich -
Stefan Reinauer -
Stefan Tauner -
The Gluglug -
Vladimir 'φ-coder/phcoder' Serbinenko