Dear Marc,
Thank you for bringing this up on the coreboot mailing list.
Am Dienstag, den 16.05.2017, 22:37 +0000 schrieb Marc Jones:
We want to bring to your attention the following patches, which are the start of an experiment to move AMD coreboot SOCs to the same structure as other vendor SOCs.
https://review.coreboot.org/#/q/topic:soc_stoneyridge
The goals of the experiments are:
- to correct interfaces for each coreboot stage
- to leverage common coreboot drivers (which require the common soc
structure)
- to correct nagging issues in current implementations (cruft, bit-rot, etc)
- to provide an example for AMD silicon and mainboards moving forward
We recognize that these changes may not be compatible with the current binaryPI API (AGESA2008 a.k.a. v5),
Could you please elaborate where the API is broken?
so the separation allows current AGESA and binaryPI solutions to be maintained and developed independently. Once stable, we expect that changes may be back-ported or older silicon brought up to the new soc structure.
Seeing the lack of manpower for AMD systems, I am concerned about two(?) solutions that need to be maintained. If the current experiment succeeds, there should be a roadmap how the current boards will be ported.
Thanks,
Paul
On Sat, Jun 10, 2017 at 4:33 AM, Paul Menzel <paulepanter@users. sourceforge.net> wrote: ...
Seeing the lack of manpower for AMD systems, I am concerned about two(?) solutions that need to be maintained. If the current experiment succeeds, there should be a roadmap how the current boards will be ported.
I'm not speaking here for the coreboot leadership, for AMD, or anyone besides myself.
As far as I know, there is no plan to port the current boards forward. This will be completely new implementation, entirely separate from the old boards.
I don't see AMD going back to supporting the older platforms. Same with Intel, Rockchip, Google, or any other company. They're going to support the platforms that there is a financial incentive to support. As soon as they don't have a financial reason to support the platform any longer, it's really going to be up to the community to take over if we want them to continue moving forward.
We complain about companies using binaries, but then we ALSO complain when companies open up the code that they're using because it doesn't meet our standards. They gave the code to the community to use, and we STILL can't be happy about it. It's OPEN. Edit it. Fork it. Make it our own. If we're just going to complain, what incentive do they have to make it open? They had to go through a lot of work internally to be able to publish it, working with the lawyers and having engineers go through and scrub references to things they can't release. The code isn't perfect, but what code is?
If the community wants the older platforms to move forward, then WE should pick up support for the platforms we care about. If nobody cares enough about the platforms to say that they're going to help support them, then they're going to be removed from the main tree after one of the upcoming releases due to missing features. At that point, there will only be one solution to be maintained again.
We have some incredible people who work on the coreboot project. I'm always amazed and grateful to what people are willing to do in their spare time. Companies, however, don't typically have the same motivations as we do, so if we want the older "obsolete" platforms to continue to progress, we, the community will have to do that work.
If we make it too difficult for companies to participate in upstream coreboot, they're just going to fork the code internally and not get our feedback or reviews. In my opinion, it's much better if we TRY to get companies to work at coreboot.org instead of making it difficult for them by trying to require them to maintain platforms that they no longer care about.
Martin
-
Martin Roth -
Paul Menzel