Just because a board lacks active developers doesn't mean that no one is using it. As a layman I simply can't understand as to how all these seemingly insignificant improvements such as CBMEM in ramstage make it worth removing almost every compatible board from the source, including nearly all the models that still have an open source init.
To me it seems at the rate this is going soon all that will be left is a few blobbed and NDA'ed development boards unavailable to the general public.
Am I mistaken?
Hi,
On 23.08.2017 06:00, Taiidan@gmx.com wrote:
Just because a board lacks active developers doesn't mean that no one is using it.
right, and we won't stop anybody from using them in the future. Please keep in mind, when a board is removed from the tree that only means that the people working on newer boards don't maintain the old ones any more. You can still check out the parent of the removal commit and build these boards. I don't know which boards exactly are in question, but older board ports are often broken anyway. So you can't argue that keeping them in the tree would magically make them work.
As a layman I simply can't understand as to how all these seemingly insignificant improvements such as CBMEM in ramstage make it worth removing almost every compatible board from the source,
I agree that these improvements would be insignificant to the boards in question. Though, making improvements at all for newer platforms is much harder if you have to take care of the old platforms (with incompatible code) too.
including nearly all the models that still have an open source init.
Can I see numbers please? I count about 50 Intel based boards (not counting variants) with free init code which is actively developed. There are more on the ARM front and probably some AMD based too. They'll all stay. How many are we going to remove?
To me it seems at the rate this is going soon all that will be left is a few blobbed and NDA'ed development boards unavailable to the general public.
What rate? how many have we removed already? 2? If you estimate from that and the prospect that we'll remove 50+ one year later, well, then we'd remove 1,000+ boards next year. That would indeed be a problem...
Am I mistaken?
Yes, I guess.
Nico
Is there an index of which was the latest git commit for each removed board ? That would help anyone interested in working on them in the future. It is not strictly necessary, but would certainly make life easier. And it can't be that hard to update a wiki page (or something equivalent) any time there's a new board deprecation.
2017-08-23 16:53 GMT-03:00 Nico Huber nico.h@gmx.de:
Hi,
On 23.08.2017 06:00, Taiidan@gmx.com wrote:
Just because a board lacks active developers doesn't mean that no one is using it.
right, and we won't stop anybody from using them in the future. Please keep in mind, when a board is removed from the tree that only means that the people working on newer boards don't maintain the old ones any more. You can still check out the parent of the removal commit and build these boards. I don't know which boards exactly are in question, but older board ports are often broken anyway. So you can't argue that keeping them in the tree would magically make them work.
As a layman I simply can't understand as to how all these seemingly insignificant improvements such as CBMEM in ramstage make it worth removing almost every compatible board from the source,
I agree that these improvements would be insignificant to the boards in question. Though, making improvements at all for newer platforms is much harder if you have to take care of the old platforms (with incompatible code) too.
including nearly all the models that still have an open source init.
Can I see numbers please? I count about 50 Intel based boards (not counting variants) with free init code which is actively developed. There are more on the ARM front and probably some AMD based too. They'll all stay. How many are we going to remove?
To me it seems at the rate this is going soon all that will be left is a few blobbed and NDA'ed development boards unavailable to the general public.
What rate? how many have we removed already? 2? If you estimate from that and the prospect that we'll remove 50+ one year later, well, then we'd remove 1,000+ boards next year. That would indeed be a problem...
Am I mistaken?
Yes, I guess.
Nico
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Ah I see thanks for explaining.
I had read all the AGESA boards were going to be removed, besides the asus D8/D16 those are the last and best owner controlled x86 boards. Is there a current list of boards to be removed?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 08/23/2017 04:29 PM, Taiidan@gmx.com wrote:
Ah I see thanks for explaining.
I had read all the AGESA boards were going to be removed, besides the asus D8/D16 those are the last and best owner controlled x86 boards. Is there a current list of boards to be removed?
In light of this thread, and given our desire to continue supporting coreboot where possible, Raptor Engineering would like to announce that for the next 2 weeks we are extending a 75% off pricing deal on the REACTS [1] test system to members of the coreboot community. Simply use the promotional code COREBOOTREACTS17 at checkout to apply the discount.
We hope that this will help get more boards into an actively maintained state.
Thanks!
[1] https://secure.raptorengineering.com/content/REACTS/intro.html
- -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com
On Wed, Aug 23, 2017 at 2:31 PM Taiidan@gmx.com Taiidan@gmx.com wrote:
Ah I see thanks for explaining.
I had read all the AGESA boards were going to be removed, besides the asus D8/D16 those are the last and best owner controlled x86 boards. Is there a current list of boards to be removed?
I don't know, but I have brought this up from time to time. I believe that if they've not got a maintainer for more than a year it is time for them to be removed. I would like to have a list of all boards ever supported, along with the last coreboot revision where they can be found.
thanks
On Thu, Aug 24, 2017 at 12:29 AM, Taiidan@gmx.com Taiidan@gmx.com wrote:
Ah I see thanks for explaining.
I had read all the AGESA boards were going to be removed, besides the asus D8/D16 those are the last and best owner controlled x86 boards. Is there a current list of boards to be removed?
Hi
The work for LATE -> EARLY CBMEM transition for AGESA has been available for review since February 2017. It's probably announced or mentioned only briefly on the mailing list, but certainly very visible on gerrit.
Unfortunately people currently working on AMD platforms did not show much interest to review that work. Luckily, devs from chromeos team (who had no commercial interest, but maybe strings attached) stepped in the reviews so that the groundwork of AGESA interface changes got done and reviewed. What's left is merging the individual board changes, which I am about to do very soon now. Some regressions expected, most of the old defects remain unfixed.
I should thank the couple individuals and companies that contributed by covering some costs of this development. Still, that does not magically turn all these boards into status of "maintained".
Now, this applies to everyone: please push status updates for the boards you have access to, otherwise majority of AGESA boards just hit that deprecation in the next cycle of board removals. Also, when you create a board port and you go through all the trouble of getting it past (my strict or someone else's less strict) review policy, is it REALLY that hard to run board_status script? You know who you are. Is there something we need to do better here? Provide OS boot images just for this purpose?
As for binaryPI boards, those are at EARLY_CBMEM_INIT starting from August 2.
As for K8/K10, your help is needed in testing. This is particularly for boards with multiple CPU packages (nodes).
HTH, Kyösti
On Wed, Aug 23, 2017 at 7:00 AM, Taiidan@gmx.com Taiidan@gmx.com wrote:
Just because a board lacks active developers doesn't mean that no one is using it. As a layman I simply can't understand as to how all these seemingly insignificant improvements such as CBMEM in ramstage make it worth removing almost every compatible board from the source, including nearly all the models that still have an open source init.
First, I should correct you meant to say "CBMEM (enablement) in _romstage_".
As it appears, nobody yet explained on this thread the significance of EARLY_CBMEM_INIT, so here is my take on it:
The major features EARLY_CBMEM_INIT implies are: non-const global variables, CBMEM console, timestamps and USB / EHCI debug are available for use in romstage. I claim all of those have been absolute necessities to achieve the boottimes (and coreboot support in general) we have eg. with the popular lenovo laptops using ivybridge.
For old platforms, I mostly agree EARLY_CBMEM_INIT would not bring anything new there. You get instrumentation data if you really wanted to tune up the boot speed, but that's about it. As someone already explained, it's all about the maintenance burden. We probably had 15 variations of how to transition from romstage to ramstage and all the things involving CAR teardown and CBMEM init. Maybe we are down to 5 once LATE_CBMEM_INIT is gone?
Further on, I anticipate and hope that RELOCATABLE_RAMSTAGE becomes compulsory soon as well.
HTH, Kyösti
-
Felipe Sanches -
Kyösti Mälkki -
Nico Huber -
ron minnich -
Taiidan＠gmx.com -
Timothy Pearson