[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Keith Thanks a lot for testing! It looks like the newer parallel mp code uses "mfence" which is probably not supported by your CPU. I updated the code to reflect that. I'd appreciate if you can test the latest version of https://review.coreboot.org/c/coreboot/+/59693/ Kind regards On Tue, Nov 30, 2021 at 8:13 PM Keith Hui wrote: > Hi everyone, > > Thanks for your efforts to keep a computing legend alive. :) > > I suffered an unexpected exception after applying the patch train. > Serial log at the end of this email. I probably could leave out > bootblock/romstage/postcar, but it's here for completeness. Next: > bisect. > > I do still have a P2B-DS on hand, but all my Pentium 3 CPUs are > singles, and Pentium III-S 1400MHz (the best CPU money can buy for > this board) are running ~$85 apiece on ebay. On the other hand, I > think one of my two P2B-LS may have died. > > (Branden - and a P3B-F board too. ;-) > > Meanwhile, I should have pushed harder to get P8Z77-M into the tree. > > Keith > > On Tue, 30 Nov 2021 at 05:32, Angel Pons wrote: > > > > Hi Branden, > > > > On Mon, Nov 29, 2021 at 9:18 PM Branden Waldner > wrote: > > > > > > I wasn't really sure that I wanted to comment on this, but seeing as > > > how I have some of the affected boards I guess I should. > > > > Thank you very much. > > > > > Angel Pons wrote: > > > > Besides AMD AGESA boards, the other boards that need to be updated > are AOpen DXPL > > > > Plus-U (a dual-socket server board that uses Netburst Xeons, no > other board in the tree uses > > > > the same chipset code) and various Asus P2B boards (which support > Pentium 2/3 CPUs, these > > > > boards are older than me). Even though I only know two people who > still have some of these > > > > boards (and they don't have the same boards), they're still > supported because the code has > > > > been maintained so far. > > > > > > I am one of the two with Asus P2B boards, with Keith Hui being the > > > other. I've got a P2B and a P2-99 and I believe Keith Hui has a > > > P2B-LS. > > > So far there have not been very many changes and Keith Hui and others > > > have worked on them, all I've done is test master and relevant patch > > > sets every once in a while. > > > I know I have not been uploading board_status results and I have not > > > gotten around to fixing the variant set up for the P2-99 so I'm not > > > uploading results that are uncertain about which board they are for. > > > Not really relevant, but I think it is pretty neat to be running > > > coreboot on boards older then some of the contributors. > > > > > > Mike Banon wrote: > > > > I am often build-testing my boards (didn't notice a > > > > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, > but only because I've been > > > > re-using the previously built toolchains to save time). Also, I am > actively tech-supporting all the > > > > people who would like to build coreboot for AMD boards from this > list, even right now I am in an > > > > active message exchange with >10 people who are switching to these > boards to run coreboot > > > > on them - and any user may give back to the project one day. > > > > > > I actually have a few AMD boards and laptops that might be viable for > > > porting to, but I've never looked in to it much because of the state > > > support is in coreboot and the fact most of the hardware was actively > > > being used. > > > > > > Arthur Heymans wrote: > > > > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also > includes the codepath for > > > > SMM_ASEG. This code is used to start APs and do some feature > programming on each AP, but > > > > also set up SMM. This has largely been superseded by PARALLEL_MP, > which should be able > > > > to cover all use cases of LEGACY_SMP_INIT, with little code changes. > The reason for > > > > deprecation is that having 2 codepaths to do the virtually the same > increases maintenance > > > > burden on the community a lot, while also being rather confusing. > > > > > > > > A few things are lacking in PARALLEL_MP init: - Support for > !CONFIG_SMP on single core > > > > systems. It's likely easy to extend PARALLEL_MP or write some code > that just does CPU > > > > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa > - 0xb) region. A > > > > POC showed that it's not that hard to do with PARALLEL_MP > > > > https://review.coreboot.org/c/coreboot/+/58700 > > > > > > I didn't even know that was a problem until now. I doubt there is much > > > I can do about it myself at this point in time, though I can try to > > > look through it I guess. > > > > Looks like Arthur has already implemented some changes to use > > PARALLEL_MP on i440bx. As of writing, the patches assume there's only > > one CPU (I already pointed out this is incorrect for boards with two > > CPU sockets/slots). I'd greatly appreciate if Keith and/or you could > > test them on actual hardware. The patches to apply, in order, are: > > > >
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi everyone, Thanks for your efforts to keep a computing legend alive. :) I suffered an unexpected exception after applying the patch train. Serial log at the end of this email. I probably could leave out bootblock/romstage/postcar, but it's here for completeness. Next: bisect. I do still have a P2B-DS on hand, but all my Pentium 3 CPUs are singles, and Pentium III-S 1400MHz (the best CPU money can buy for this board) are running ~$85 apiece on ebay. On the other hand, I think one of my two P2B-LS may have died. (Branden - and a P3B-F board too. ;-) Meanwhile, I should have pushed harder to get P8Z77-M into the tree. Keith On Tue, 30 Nov 2021 at 05:32, Angel Pons wrote: > > Hi Branden, > > On Mon, Nov 29, 2021 at 9:18 PM Branden Waldner wrote: > > > > I wasn't really sure that I wanted to comment on this, but seeing as > > how I have some of the affected boards I guess I should. > > Thank you very much. > > > Angel Pons wrote: > > > Besides AMD AGESA boards, the other boards that need to be updated are > > > AOpen DXPL > > > Plus-U (a dual-socket server board that uses Netburst Xeons, no other > > > board in the tree uses > > > the same chipset code) and various Asus P2B boards (which support Pentium > > > 2/3 CPUs, these > > > boards are older than me). Even though I only know two people who still > > > have some of these > > > boards (and they don't have the same boards), they're still supported > > > because the code has > > > been maintained so far. > > > > I am one of the two with Asus P2B boards, with Keith Hui being the > > other. I've got a P2B and a P2-99 and I believe Keith Hui has a > > P2B-LS. > > So far there have not been very many changes and Keith Hui and others > > have worked on them, all I've done is test master and relevant patch > > sets every once in a while. > > I know I have not been uploading board_status results and I have not > > gotten around to fixing the variant set up for the P2-99 so I'm not > > uploading results that are uncertain about which board they are for. > > Not really relevant, but I think it is pretty neat to be running > > coreboot on boards older then some of the contributors. > > > > Mike Banon wrote: > > > I am often build-testing my boards (didn't notice a > > > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but > > > only because I've been > > > re-using the previously built toolchains to save time). Also, I am > > > actively tech-supporting all the > > > people who would like to build coreboot for AMD boards from this list, > > > even right now I am in an > > > active message exchange with >10 people who are switching to these boards > > > to run coreboot > > > on them - and any user may give back to the project one day. > > > > I actually have a few AMD boards and laptops that might be viable for > > porting to, but I've never looked in to it much because of the state > > support is in coreboot and the fact most of the hardware was actively > > being used. > > > > Arthur Heymans wrote: > > > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also > > > includes the codepath for > > > SMM_ASEG. This code is used to start APs and do some feature programming > > > on each AP, but > > > also set up SMM. This has largely been superseded by PARALLEL_MP, which > > > should be able > > > to cover all use cases of LEGACY_SMP_INIT, with little code changes. The > > > reason for > > > deprecation is that having 2 codepaths to do the virtually the same > > > increases maintenance > > > burden on the community a lot, while also being rather confusing. > > > > > > A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP > > > on single core > > > systems. It's likely easy to extend PARALLEL_MP or write some code that > > > just does CPU > > > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa - > > > 0xb) region. A > > > POC showed that it's not that hard to do with PARALLEL_MP > > > https://review.coreboot.org/c/coreboot/+/58700 > > > > I didn't even know that was a problem until now. I doubt there is much > > I can do about it myself at this point in time, though I can try to > > look through it I guess. > > Looks like Arthur has already implemented some changes to use > PARALLEL_MP on i440bx. As of writing, the patches assume there's only > one CPU (I already pointed out this is incorrect for boards with two > CPU sockets/slots). I'd greatly appreciate if Keith and/or you could > test them on actual hardware. The patches to apply, in order, are: > > https://review.coreboot.org/59694 > https://review.coreboot.org/59695 > https://review.coreboot.org/59692 > https://review.coreboot.org/59693 > > > Branden Waldner > > Best regards, > Angel coreboot-4.15-346-g096d97c3c6-dirty Tue Nov 30 17:10:13 UTC 2021 bootblock starting (log level: 7)... FMAP: Found "FLASH" version 1.1 at 0x0. FMAP: base = 0xfffc size = 0x4 #areas = 3 FMAP: area COREBOOT found @ 200 (261632 bytes)
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Branden, On Mon, Nov 29, 2021 at 9:18 PM Branden Waldner wrote: > > I wasn't really sure that I wanted to comment on this, but seeing as > how I have some of the affected boards I guess I should. Thank you very much. > Angel Pons wrote: > > Besides AMD AGESA boards, the other boards that need to be updated are > > AOpen DXPL > > Plus-U (a dual-socket server board that uses Netburst Xeons, no other board > > in the tree uses > > the same chipset code) and various Asus P2B boards (which support Pentium > > 2/3 CPUs, these > > boards are older than me). Even though I only know two people who still > > have some of these > > boards (and they don't have the same boards), they're still supported > > because the code has > > been maintained so far. > > I am one of the two with Asus P2B boards, with Keith Hui being the > other. I've got a P2B and a P2-99 and I believe Keith Hui has a > P2B-LS. > So far there have not been very many changes and Keith Hui and others > have worked on them, all I've done is test master and relevant patch > sets every once in a while. > I know I have not been uploading board_status results and I have not > gotten around to fixing the variant set up for the P2-99 so I'm not > uploading results that are uncertain about which board they are for. > Not really relevant, but I think it is pretty neat to be running > coreboot on boards older then some of the contributors. > > Mike Banon wrote: > > I am often build-testing my boards (didn't notice a > > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but > > only because I've been > > re-using the previously built toolchains to save time). Also, I am actively > > tech-supporting all the > > people who would like to build coreboot for AMD boards from this list, even > > right now I am in an > > active message exchange with >10 people who are switching to these boards > > to run coreboot > > on them - and any user may give back to the project one day. > > I actually have a few AMD boards and laptops that might be viable for > porting to, but I've never looked in to it much because of the state > support is in coreboot and the fact most of the hardware was actively > being used. > > Arthur Heymans wrote: > > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes > > the codepath for > > SMM_ASEG. This code is used to start APs and do some feature programming on > > each AP, but > > also set up SMM. This has largely been superseded by PARALLEL_MP, which > > should be able > > to cover all use cases of LEGACY_SMP_INIT, with little code changes. The > > reason for > > deprecation is that having 2 codepaths to do the virtually the same > > increases maintenance > > burden on the community a lot, while also being rather confusing. > > > > A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on > > single core > > systems. It's likely easy to extend PARALLEL_MP or write some code that > > just does CPU > > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa - > > 0xb) region. A > > POC showed that it's not that hard to do with PARALLEL_MP > > https://review.coreboot.org/c/coreboot/+/58700 > > I didn't even know that was a problem until now. I doubt there is much > I can do about it myself at this point in time, though I can try to > look through it I guess. Looks like Arthur has already implemented some changes to use PARALLEL_MP on i440bx. As of writing, the patches assume there's only one CPU (I already pointed out this is incorrect for boards with two CPU sockets/slots). I'd greatly appreciate if Keith and/or you could test them on actual hardware. The patches to apply, in order, are: https://review.coreboot.org/59694 https://review.coreboot.org/59695 https://review.coreboot.org/59692 https://review.coreboot.org/59693 > Branden Waldner > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org Best regards, Angel ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
I wasn't really sure that I wanted to comment on this, but seeing as how I have some of the affected boards I guess I should. Angel Pons wrote: > Besides AMD AGESA boards, the other boards that need to be updated are AOpen > DXPL > Plus-U (a dual-socket server board that uses Netburst Xeons, no other board > in the tree uses > the same chipset code) and various Asus P2B boards (which support Pentium 2/3 > CPUs, these > boards are older than me). Even though I only know two people who still have > some of these > boards (and they don't have the same boards), they're still supported because > the code has > been maintained so far. I am one of the two with Asus P2B boards, with Keith Hui being the other. I've got a P2B and a P2-99 and I believe Keith Hui has a P2B-LS. So far there have not been very many changes and Keith Hui and others have worked on them, all I've done is test master and relevant patch sets every once in a while. I know I have not been uploading board_status results and I have not gotten around to fixing the variant set up for the P2-99 so I'm not uploading results that are uncertain about which board they are for. Not really relevant, but I think it is pretty neat to be running coreboot on boards older then some of the contributors. Mike Banon wrote: > I am often build-testing my boards (didn't notice a > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only > because I've been > re-using the previously built toolchains to save time). Also, I am actively > tech-supporting all the > people who would like to build coreboot for AMD boards from this list, even > right now I am in an > active message exchange with >10 people who are switching to these boards to > run coreboot > on them - and any user may give back to the project one day. I actually have a few AMD boards and laptops that might be viable for porting to, but I've never looked in to it much because of the state support is in coreboot and the fact most of the hardware was actively being used. Arthur Heymans wrote: > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes > the codepath for > SMM_ASEG. This code is used to start APs and do some feature programming on > each AP, but > also set up SMM. This has largely been superseded by PARALLEL_MP, which > should be able > to cover all use cases of LEGACY_SMP_INIT, with little code changes. The > reason for > deprecation is that having 2 codepaths to do the virtually the same increases > maintenance > burden on the community a lot, while also being rather confusing. > > A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on > single core > systems. It's likely easy to extend PARALLEL_MP or write some code that just > does CPU > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa - > 0xb) region. A > POC showed that it's not that hard to do with PARALLEL_MP > https://review.coreboot.org/c/coreboot/+/58700 I didn't even know that was a problem until now. I doubt there is much I can do about it myself at this point in time, though I can try to look through it I guess. Branden Waldner ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
> > On a side note is there any kind of crowd sourcing platform / escrow > service for GPL projects? I know it's been talked about, and there have > been attempts made. But as far as I can tell, nothing has ever prospered. If someone wanted to work with one of the approved coreboot contractors > or individual contributor to set up a fundraiser of some sort to raise > money to do things like this, that'd be great. We've had a requests for > things like this in the past, but it's not something that the coreboot > project itself can really do. We don't want to pit one group of coreboot > developers against another, and the coreboot project also doesn't deliver > binaries or sign contracts for work, so coreboot can't make guarantees > about deliverables.I'd be happy to help get a fundraiser set up if anyone > is interested in doing the work, but it's going to have to go through an > actual fundraising site, and of course we'd want to have a full written > plan before starting anything. I've seen bountysource employed for various things in the past, from compatibility enhancements for POWER9 to GCC backend implementations for AVR. I think it's reasonably fair, with the bounty available to whoever is willing to put in the work to close the issue. The only thing missing that I can see is the need for an "issue" (a la github issues) that can be "closed" to trigger the end of the bounty. I don't know if gerrit supports such a functionality. On Sun, Nov 28, 2021 at 9:46 PM ron minnich wrote: > having read this discussion, and with all respect for all the opinions > so clearly expressed, I still support Arthur's original proposal. > > > On Sun, Nov 28, 2021 at 2:20 PM David Hendricks > wrote: > > > > > > > >> 1. These boards will be gone for the people who check the "mainboards > >> supported by coreboot" and see only the "new Intel stuff". This > >> hinders the coreboot community growth around the "gone boards", and > >> also of the coreboot community in general: the fewer boards are > >> supported by coreboot, the more difficult it is for a potential > >> user/contributor to find the supported board and join us. > > > > > > For the record, we have removed Intel boards from the master branch in > the past - See 4.11_branch. This was for boards that used FSP 1.0, > including popular Baytrail Atom and Broadwell-DE platforms which are still > widely used today. This ensures that those platforms continue existence on > an easy-to-find stable branch where one can reasonably expect to check out > the code and have it work. Checking out the master branch only to find out > that it doesn't work and then bisecting years worth of commits is a poor > user experience. > > > > Perhaps we should follow the 4.11_branch example and do something > similar with old AGESA boards? Boards which are forward-ported and tested > can stay (or be re-introduced) in the master branch, of course. > > > > Many of the AGESA platforms in the list Arthur provided are ~10 years > old. Some are clearly obsolete, like the Gizmosphere boards that have not > been in production for years and whose manufacturer is defunct. Others like > the PCEngines APUs should be more readily available to test and have > developers able to spend some time forward-porting the necessary bits. > > > > Lastly, I'll mention that there is an active crowdfunding effort to > re-upstream KGPE-D16 support: > https://github.com/osresearch/heads/issues/719. There's clearly a lot of > enthusiasm with that board, and 3mdeb is already porting allocate v4 to it. > Perhaps enthusiasts for other boards can piggyback on this effort and > leverage some of their work to bring other boards up to date. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
having read this discussion, and with all respect for all the opinions so clearly expressed, I still support Arthur's original proposal. On Sun, Nov 28, 2021 at 2:20 PM David Hendricks wrote: > > > >> 1. These boards will be gone for the people who check the "mainboards >> supported by coreboot" and see only the "new Intel stuff". This >> hinders the coreboot community growth around the "gone boards", and >> also of the coreboot community in general: the fewer boards are >> supported by coreboot, the more difficult it is for a potential >> user/contributor to find the supported board and join us. > > > For the record, we have removed Intel boards from the master branch in the > past - See 4.11_branch. This was for boards that used FSP 1.0, including > popular Baytrail Atom and Broadwell-DE platforms which are still widely used > today. This ensures that those platforms continue existence on an > easy-to-find stable branch where one can reasonably expect to check out the > code and have it work. Checking out the master branch only to find out that > it doesn't work and then bisecting years worth of commits is a poor user > experience. > > Perhaps we should follow the 4.11_branch example and do something similar > with old AGESA boards? Boards which are forward-ported and tested can stay > (or be re-introduced) in the master branch, of course. > > Many of the AGESA platforms in the list Arthur provided are ~10 years old. > Some are clearly obsolete, like the Gizmosphere boards that have not been in > production for years and whose manufacturer is defunct. Others like the > PCEngines APUs should be more readily available to test and have developers > able to spend some time forward-porting the necessary bits. > > Lastly, I'll mention that there is an active crowdfunding effort to > re-upstream KGPE-D16 support: https://github.com/osresearch/heads/issues/719. > There's clearly a lot of enthusiasm with that board, and 3mdeb is already > porting allocate v4 to it. Perhaps enthusiasts for other boards can piggyback > on this effort and leverage some of their work to bring other boards up to > date. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
1. These boards will be gone for the people who check the "mainboards > supported by coreboot" and see only the "new Intel stuff". This > hinders the coreboot community growth around the "gone boards", and > also of the coreboot community in general: the fewer boards are > supported by coreboot, the more difficult it is for a potential > user/contributor to find the supported board and join us. > For the record, we have removed Intel boards from the master branch in the past - See 4.11_branch. This was for boards that used FSP 1.0, including popular Baytrail Atom and Broadwell-DE platforms which are still widely used today. This ensures that those platforms continue existence on an easy-to-find stable branch where one can reasonably expect to check out the code and have it work. Checking out the master branch only to find out that it doesn't work and then bisecting years worth of commits is a poor user experience. Perhaps we should follow the 4.11_branch example and do something similar with old AGESA boards? Boards which are forward-ported and tested can stay (or be re-introduced) in the master branch, of course. Many of the AGESA platforms in the list Arthur provided are ~10 years old. Some are clearly obsolete, like the Gizmosphere boards that have not been in production for years and whose manufacturer is defunct. Others like the PCEngines APUs should be more readily available to test and have developers able to spend some time forward-porting the necessary bits. Lastly, I'll mention that there is an active crowdfunding effort to re-upstream KGPE-D16 support: https://github.com/osresearch/heads/issues/719. There's clearly a lot of enthusiasm with that board, and 3mdeb is already porting allocate v4 to it. Perhaps enthusiasts for other boards can piggyback on this effort and leverage some of their work to bring other boards up to date. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Peter, On 28.11.21 02:44, Peter Stuge wrote: > TL;DR: If someone wants to deprecate older code then *they* have to > first balance any compatibility debt introduced by the newer code. sounds fair. However I have to ask, do you see things are unbalanced? And in what direction? Taking the allocator case for instance, there is zero compatibility debt introduced by the new code. All the debt is within the code of the deprecated platforms, which is neither compatible to the old nor the new allocator code. It's just buggy. Always has been. Changing core coreboot code just makes this more visible, and to me it seems fairer to deprecate broken code than to pretend that it's working. Overall, all the cases of dropped platforms that I can recall are of this kind: Somebody pushed their code upstream and then they or somebody relying on the code tried to get their bugs fixed for free by coreboot maintainers. IMHO, this is heavily unbalanced and depre- cation are a means to fix that. > Anything else incentivises a race to the bottom; to move fast and > break things. coreboot IMO neither wants nor needs that. Sounds right. But I guess you assumed things are unbalanced in a different direction than they are :) > Patrick Georgi via coreboot wrote: >>> With all due respect, dropping support for the majority of AMD boards >> >> Dropping support for hardware has never been the primary purpose of >> deprecation plans, > > I think the difference is unimportantly subtle; deprecation is formal > intent to (eventually) drop. No, not unconditionally and definitely not eventually. Their is always hope that somebody tries to fix the platforms that rely on deprecated code. > > Deprecating code that not only provably works on hardware but is in > fact *our only* code that currently works on the hardware IMO falls > between lazy and malicious, in any case far from good practice when > considering the future. tl;dr that code works by coincidence is not enough to ask other people to maintain it. You may not have read the code of the platforms in question. I did and IMHO, if anything is malicious then it's having such broken, impossible to maintain code in our tree. Looking at the code, I have to assume it was added with minimum effort to write sound code and maximum debt. People have worked to fix it and clean it up for years and it's still in a (IMHO) horrible state. Pushing such code into the tree "falls between lazy and malicious". Asking to keep such code without the intention to fix it, too. > Our classic tension between private interests and the public good > will not diminish over time unless everyone invests towards that goal. > The Linux kernel is a perfect example of what happens otherwise, it's > certainly nothing to strive for. What's the public good in this case? Isn't it for the public good when people like Arthur continue to support projects like coreboot? You seem a little too biased towards existing code, but what about new code? Is there no public interest in new code? > > I consider Arthur's argument about maintenance burden to be based on the > false premise that newer code is per se more valuable than older code. Ok, your are free to consider it like this. But I can tell you it's wrong. IIRC, all the deprecation up to now were in favor of code that turned out to work best for all sound coreboot ports. Of course, new code doesn't always work well for ports that only worked by coincidence with the old code, and there's the burden. Who's responsible to fix code that was added in a poor state? The original authors? the people who rely on it? or the people who want to continue the project? > > If only considering hardware running the newer code with tunnel vision > I do understand such an attitude, but to me a hard requirement for such > a premise is that the newer code is a drop-in replacement - only then > is it prudent to speak of deprecating the older code. If it's not > compatible then the new code obviously solves a different problem. > > It's of course too late to enforce drop-in compatibility once new code > has been accepted into the tree, but the desire for deprecation such as > this is a good opportunity to pay back what I consider compatibility debt > in the new code. > > Accepting an incompatible new implementation fails to create the incentives > required for medium to long-term codebase stability. It would be wise to > start repairing that culture deficit right now. Again, the incompatibility burden is usually not introduced by the new code. What you say seems generally true, but you are blaming / talking to the wrong people. It's not what is going on in this project. > > I find it completely unacceptable for someone working on something new > to push a workload of forward-porting onto people who have no relation > whatsoever to that new effort, but I'm sure it's a fun power trip. :) I find it completely unacceptable for someone adding broken code to push a workload of fixing onto
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Am 28.11.2021 um 02:44 schrieb Peter Stuge: Patrick Georgi via coreboot wrote: With all due respect, dropping support for the majority of AMD boards Dropping support for hardware has never been the primary purpose of deprecation plans, I think the difference is unimportantly subtle; deprecation is formal intent to (eventually) drop. I'll try to make it clearer: Dropping support FOR HARDWARE has never been the primary purpose of deprecation plans The primary goal, as seen in the title, is to remove LEGACY_SMP_INIT and RESOURCE_ALLOCATOR_V3. One purpose of announcements like the one by Arthur is to start a discussion how to get there while ideally NOT dropping the devices that would be affected (as listed in the original email). I'll leave the rest of the email uncommented because it's only derailing matters even more. Regards, Patrick ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
TL;DR: If someone wants to deprecate older code then *they* have to first balance any compatibility debt introduced by the newer code. Anything else incentivises a race to the bottom; to move fast and break things. coreboot IMO neither wants nor needs that. Patrick Georgi via coreboot wrote: > > With all due respect, dropping support for the majority of AMD boards > > Dropping support for hardware has never been the primary purpose of > deprecation plans, I think the difference is unimportantly subtle; deprecation is formal intent to (eventually) drop. Deprecating code that not only provably works on hardware but is in fact *our only* code that currently works on the hardware IMO falls between lazy and malicious, in any case far from good practice when considering the future. Our classic tension between private interests and the public good will not diminish over time unless everyone invests towards that goal. The Linux kernel is a perfect example of what happens otherwise, it's certainly nothing to strive for. I consider Arthur's argument about maintenance burden to be based on the false premise that newer code is per se more valuable than older code. If only considering hardware running the newer code with tunnel vision I do understand such an attitude, but to me a hard requirement for such a premise is that the newer code is a drop-in replacement - only then is it prudent to speak of deprecating the older code. If it's not compatible then the new code obviously solves a different problem. It's of course too late to enforce drop-in compatibility once new code has been accepted into the tree, but the desire for deprecation such as this is a good opportunity to pay back what I consider compatibility debt in the new code. Accepting an incompatible new implementation fails to create the incentives required for medium to long-term codebase stability. It would be wise to start repairing that culture deficit right now. I find it completely unacceptable for someone working on something new to push a workload of forward-porting onto people who have no relation whatsoever to that new effort, but I'm sure it's a fun power trip. :) Please be more mindful than that. I've of course also made mistakes, but I try to always improve. If companies are unable to invest in creating open source firmware for the public good then please think about whether you really want to be known for introducing compatibility debt. If companies are able but merely unwilling then please be honest about that and do not bother others with your code, you should maintain it locally then. No progress can be infinitely better than "wrong" progress, and therein lies the challenge for private interests in projects for the public good. A strange game! Kind regards //Peter ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
If someone wanted to work with one of the approved coreboot contractors or individual contributor to set up a fundraiser of some sort to raise money to do things like this, that'd be great. We've had a requests for things like this in the past, but it's not something that the coreboot project itself can really do. We don't want to pit one group of coreboot developers against another, and the coreboot project also doesn't deliver binaries or sign contracts for work, so coreboot can't make guarantees about deliverables. I'd be happy to help get a fundraiser set up if anyone is interested in doing the work, but it's going to have to go through an actual fundraising site, and of course we'd want to have a full written plan before starting anything. Martin Nov 25, 2021, 18:03 by k.emery@internode.on.net: > I'm happy to contribute financially. It just comes with the caveat that I > need to know with some surety that I can finally have a working board at the > end of it. > > On a side note is there any kind of crowd sourcing platform / escrow service > for GPL projects? I know it's been talked about, and there have been attempts > made. But as far as I can tell, nothing has ever prospered. > > >> My ballpark estimation is a total of less than 100hours of >> contributors' time to migrate AGESA platform codes to avoid >> deprecation. Shared between five people who know what they are doing, >> it is very much doable within a month. >> >> Kind regards, >> Kyösti Mälkki >> ___ >> coreboot mailing list -- coreboot@coreboot.org >> To unsubscribe send an email to coreboot-le...@coreboot.org >> > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
24. November 2021 21:16, "Mike Banon" schrieb: > With all due respect, dropping support for the majority of AMD boards Dropping support for hardware has never been the primary purpose of deprecation plans, but since deprecations have been interpreted like that too often, I propose using clearer language going forward. I'd appreciate comments on https://review.coreboot.org/c/coreboot/+/59677 to ensure that it brings the point across. Regards, Patrick ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
I'm happy to contribute financially. It just comes with the caveat that I need to know with some surety that I can finally have a working board at the end of it. On a side note is there any kind of crowd sourcing platform / escrow service for GPL projects? I know it's been talked about, and there have been attempts made. But as far as I can tell, nothing has ever prospered. My ballpark estimation is a total of less than 100hours of contributors' time to migrate AGESA platform codes to avoid deprecation. Shared between five people who know what they are doing, it is very much doable within a month. Kind regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
On Thu, Nov 25, 2021 at 9:50 PM Angel Pons wrote: > > TL;DR: The deprecation notice is a call for action. Please stop > complaining about it, let's work on a solution instead. Especially > when https://review.coreboot.org/q/topic:amd_resource_allocator_v4 > already exists, which implements some of the required changes. > Thanks for your thoughts, Angel. Seems like my first contribution to coreboot just reached the age of 10 years. commit 521d8c25734dcfd38fa2e17a416e587fccb96080 Author: Kyösti Mälkki Date: Mon Oct 17 17:10:03 2011 +0300 Activate older Xeon P4 microcodes This was for one of the boards on the deprecation list, aopen/dxplplusu. No SPI flash, ASEG SMM (TSEG available), no compulsory SMI_HANDLER, no PCI MMCONFIG (now ECAM). CPU without x86_64, only 34bit PAE, somewhat complex CAR bringup, 2 power-hungry socketed P4 Xeon CPUs. No PCIe, some PCI-X slots, DDR1 with ECC, Parallel ATA no SATA. I think I have touched the chipset support maybe 3 times in the last 5 years --- still boots with iPXE to iSCSI root. It is likely to survive this deprecation of LEGACY_SMP_INIT too. I think OEM BIOS had a date like from 2005. For a contributor I find competent and interested enough, I might offer some of the following AGESA boards as a donation: * lippert/frontrunner-af (fam14 liano?) * gizmosphere/gizmo (fam14 liano?) * pcengines/apu1 (fam14 liano?) * amd/olivehill (fam16 kabini) * asrock/imb-a180 (fam16 kabini) * lenovo/g505s (fam15 trinity/richland) * ibase/i595f (fam15 trinity/richland, reaches payload with serial console, not really ported) Contact me privately to discuss terms and possible shipment. I may not be able to provide much documentation, many I have are NDA'd. AFAICS master and release 4.15 are in a booting condition for all the above with allocator V3. Like with C_ENV_BOOTBLOCK (previous valid and sensible deprecation reason) I can participate with the review progress. If I remember correctly, it was you Mike B. and Michal Z. who did most of the legwork then. I feel I have personally contributed enough with little returned value to AGESA, but a lot of soc/amd/common should be reusable for TSEG, PARALLEL_MP and also cleaner SPI Flash write support and MRC_WR_CACHE (fam16kb). There may still be a lot of assumptions of HyperTransport and multiple CPU sockets under nb/ that should be cleaned too. From experience, I can tell having parallel implementations for a single task is both a development headache with lots of preprocessor guards involved, and slows down the review process a lot. From what I remember allocator V3 does not play well with large graphics framebuffers or 64bit resources in general and I feel it's time to let it go. Also, feel free to study the history of deprecations and imagine what the tree would look like if we still allowed things like a static allocation for CBMEM done late in ramstage, or optional choice of CAR_MIGRATION or ROMCC. As I see it, forced deprecation is the only means to wake up the small group of people who are competent enough to take on a task like PARALLEL_MP migration, but are mostly just waiting for someone else to volunteer first. Maybe with some luck they provide feedback by testing builds when requested, often feedback arrives 6 months later revealing something broken. My ballpark estimation is a total of less than 100hours of contributors' time to migrate AGESA platform codes to avoid deprecation. Shared between five people who know what they are doing, it is very much doable within a month. Kind regards, Kyösti Mälkki ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hi Mike, I typically don't indulge in mailing list drama, but I'm sick and tired of seeing people waste their time and energy along with others'. This is not the first time I've seen something like this: something similar happened about two years ago when other AMD boards (KGPE-D16 and KCMA-D8, among others) were slated for removal. It was a difficult decision, but had to be done. I really don't want history to repeat itself again, but I fear it's going to happen unless there's a change of attitude right now. On Thu, Nov 25, 2021 at 4:05 PM Mike Banon wrote: > > > The word 'drop' has ominous connotations, but it's not a deletion. A board > > is never really gone. > > "Dropping" 50 boards may be ominous in relation to the future of the > coreboot project: Note that these boards will only be dropped if no one steps up to adapt their code accordingly. Moreover, the first deprecation notice for RESOURCE_ALLOCATOR_V3 was issued as part of the coreboot 4.13 release notes, i.e. last year. The removal was postponed indefinitely because https://review.coreboot.org/q/topic:amd_resource_allocator_v4 implements the required changes. However, not all patches have landed yet, and efforts seem to have stalled: as of writing, all but one of the unmerged changes were last updated in May 2021, and the outlier was last updated in 2021-06-23. Hopefully, this notice will reactivate efforts to get these patches submitted without reactivating the local mailing list volcanoes. IMHO, lamenting about deprecation notices on the mailing list is counterproductive: it invests no resources into addressing the root problem (code needs to be maintained, but isn't), but instead tries to somehow avoid having to address the root problem by inciting emotional responses from others, such as anger. In my experience, this is a recipe for a conflict, a bitterly unpleasant waste of many people's time and energy for naught, leading to an equally disgraceful aftermath; a war in which most of the casualties are motives to work on the project. Wouldn't it be much more useful to, say, work on adapting the code, add new features or improve existing functionality, write some documentation, or even check the grammar of the code comments in the tree? > 1. These boards will be gone for the people who check the "mainboards > supported by coreboot" and see only the "new Intel stuff". This > hinders the coreboot community growth around the "gone boards", and > also of the coreboot community in general: the fewer boards are > supported by coreboot, the more difficult it is for a potential > user/contributor to find the supported board and join us. In my experience, most people who've contributed didn't have a supported board. I myself got involved with the coreboot community because none of the boards I had was supported; about three and a half years later, I now am one of the most active contributors. I only tolerated the bugs and limitations of coreboot (let's be honest; we're not perfect and we don't provide the same features as vendor firmware) because I was experiencing first-hand how hard firmware development is. I'm pretty sure I wouldn't be writing this email had one of my boards already been supported. Granted, it's nearly impossible for a newcomer to port a board when its chipset is not supported. The first board I ported is the Asus P8H61-M PRO, an Intel Sandy/Ivy Bridge desktop board with a serial port and a socketed DIP8 flash chip. Back then, Sandy/Ivy Bridge was one of the best-supported platforms (and still is, as of writing). Several people on IRC (to which I'm forever thankful) helped me port this board. I only know of one person on IRC that could help porting an AMD board using AGESA, and there aren't many people who have AGESA-supported boards. > 2. It's not just the loss of boards - it's also the loss of coreboot > users/contributors who only have these boards and don't want to switch > to anything else: i.e. because the newer coreboot-supported boards > have Intel ME / AMD PSP that are viewed negatively by many people out > of security considerations, - and security is one of the top reasons > why the people switch to coreboot in the first place. First and foremost, there's support for older Intel boards that don't require ME firmware or simply don't have a ME at all, and people still use them. Besides AMD AGESA boards, the other boards that need to be updated are AOpen DXPL Plus-U (a dual-socket server board that uses Netburst Xeons, no other board in the tree uses the same chipset code) and various Asus P2B boards (which support Pentium 2/3 CPUs, these boards are older than me). Even though I only know two people who still have some of these boards (and they don't have the same boards), they're still supported because the code has been maintained so far. If there are contributors who only have these boards, where are they? Why aren't they trying to adapt the code? If they don't know how, why haven't they asked for help on
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
> Do you remember from where you got these magic values? Suspect I'm going > to need similar. Will investigate soc/amd/¨* too. > /* QEMU-specific register */ > #define EXT_TSEG_MBYTES 0x50 > +#define SMRAMC 0x9d > +#define C_BASE_SEG ((0 << 2) | (1 << 1) | (0 << 0)) > +#define G_SMRAME (1 << 3) > +#define D_LCK (1 << 4) > +#define D_CLS (1 << 5) > +#define D_OPEN (1 << 6) > +#define ESMRAMC0x9e > +#define T_EN (1 << 0) > +#define TSEG_SZ_MASK (3 << 1) > +#define H_SMRAME (1 << 7) Those are northbridge specific register on how to handle the SMM windows (SMRAM). The BKDG should have something similar. TSEG is also an interesting search parameter. On Thu, Nov 25, 2021 at 7:39 PM awokd via coreboot wrote: > Arthur Heymans: > > > https://review.coreboot.org/c/coreboot/+/48210 and > > https://review.coreboot.org/c/coreboot/+/48262/ provided the > implementation > > for PARALLEL_MP on qemu. > > Notice that modern AMD CPUs (soc/amd/¨*) also use PARALLEL_MP and can be > > used as an example for AMD AGESA platforms too. > > > > Good luck! > > Thank you, going to need it! Would be nice if that AMD open source rep. > wanted to own and deliver on global (to AMD AGESA) changes like this to > "demonstrate a renewed commitment to the community" in corpospeak, but > will see what I can do. > > Do you remember from where you got these magic values? Suspect I'm going > to need similar. Will investigate soc/amd/¨* too. > > /* QEMU-specific register */ > #define EXT_TSEG_MBYTES 0x50 > +#define SMRAMC 0x9d > +#define C_BASE_SEG ((0 << 2) | (1 << 1) | (0 << 0)) > +#define G_SMRAME (1 << 3) > +#define D_LCK (1 << 4) > +#define D_CLS (1 << 5) > +#define D_OPEN (1 << 6) > +#define ESMRAMC0x9e > +#define T_EN (1 << 0) > +#define TSEG_SZ_MASK (3 << 1) > +#define H_SMRAME (1 << 7) > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Arthur Heymans: https://review.coreboot.org/c/coreboot/+/48210 and https://review.coreboot.org/c/coreboot/+/48262/ provided the implementation for PARALLEL_MP on qemu. Notice that modern AMD CPUs (soc/amd/¨*) also use PARALLEL_MP and can be used as an example for AMD AGESA platforms too. Good luck! Thank you, going to need it! Would be nice if that AMD open source rep. wanted to own and deliver on global (to AMD AGESA) changes like this to "demonstrate a renewed commitment to the community" in corpospeak, but will see what I can do. Do you remember from where you got these magic values? Suspect I'm going to need similar. Will investigate soc/amd/¨* too. /* QEMU-specific register */ #define EXT_TSEG_MBYTES 0x50 +#define SMRAMC 0x9d +#define C_BASE_SEG ((0 << 2) | (1 << 1) | (0 << 0)) +#define G_SMRAME (1 << 3) +#define D_LCK (1 << 4) +#define D_CLS (1 << 5) +#define D_OPEN (1 << 6) +#define ESMRAMC0x9e +#define T_EN (1 << 0) +#define TSEG_SZ_MASK (3 << 1) +#define H_SMRAME (1 << 7) ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
> To address the OP, it seems like there is some activity on getting an > AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init > also needed (and is there any activity or something I can do to help?) > Realize resources may not exist to spoon feed problem definitions to a > level my brain can handle. https://review.coreboot.org/c/coreboot/+/48210 and https://review.coreboot.org/c/coreboot/+/48262/ provided the implementation for PARALLEL_MP on qemu. Notice that modern AMD CPUs (soc/amd/¨*) also use PARALLEL_MP and can be used as an example for AMD AGESA platforms too. Good luck! Arthur On Thu, Nov 25, 2021 at 6:30 PM awokd via coreboot wrote: > Patrick Georgi via coreboot: > > On 25.11.21 17:04, Mike Banon wrote: > >> 2. It's not just the loss of boards - it's also the loss of coreboot > >> users/contributors who only have these boards and don't want to switch > > These users didn't contribute fixes to their boards (or even just > > feedback that things needs to be done and testing when others provide > > patches) - are they even contributors? > > > > It's easy to argue in favor of "lots of users" (or contributors if you > > want), but if they're all but invisible, do they even exist? > > I contributed a number of changes to address Coverity warnings in the > AMD families, and am actively using a corebooted G505s and PC Engines > APU. I lurk in the mailing list most of the time, and have a hard time > tracking what needs to be done to keep boards alive. On this thread, for > example, the updated requirements feel like they are (but are likely > not) coming out of the blue. > > To address the OP, it seems like there is some activity on getting an > AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init > also needed (and is there any activity or something I can do to help?) > Realize resources may not exist to spoon feed problem definitions to a > level my brain can handle. > > The rest of the reply might be due to communication losses of non-face > to face transmission medium. > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Am 25.11.2021 um 18:06 schrieb AreYouLoco? via coreboot: In my opinion coreboot is more developer friendly than user friendly. Kinda obvious: We don't even ship binaries... Given the trouble these deprecation announcements always are, I can tell you an even more developer friendly strategy: We could simply make all boards compile _somehow_ with the new infrastructure and retire the old one because it fell out of use. Without telling anybody. If such a change lands in, say 4.16, and you only think of updating your firmware in, say 4.20, there has been one year of development going on after the removal (assuming the newly-proposed quarterly release schedule). The result: fixing the issue becomes much harder, by then, rolling back is impossible, and nobody can quite remember what the issue was. That strategy is more developer friendly because we don't have to deal with crap on the mailing list. Is it more user friendly? And board depreciation is not a good idea. I understand that they can be brought back at some point. But lets be realistic that this need some developer time and testing. And in capitalistic world that means money to support old boards. It also costs developer time to keep maintaining several alternate code paths, some of which are only used for boards no developer still uses (or they would have patched them to use the new code already). As it stands, the proposed timeline allows for: - ~2 more months to intervene before that list of boards even makes it into some official release notes. Adapt a board to the new infrastructure before then and it can disappear from that list before it even becomes official. - 6 additional months in which the announcement is out in the open but the code is still in ToT. Adapt a board to the new infrastructure before then and while the old infrastructure will be dropped, the board won't be affected. Even after that, all the existing coreboot versions are still there. There are already some patches out there, so it appears that the strategy how to adapt a board to the new infrastructure is well understood - we're lacking the ability to test these boards. Even if you can't adapt a board yourself, I'd suspect that announcing that you have some piece of hardware, can provide logs and offer to run tests will spark interest in developers creating a patch for the board. We just don't do that speculatively because while it's usually simple to make a board compile it's far from clear that the result will still boot. So: what board(s) are you offering to test? Patrick ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Patrick Georgi via coreboot: On 25.11.21 17:04, Mike Banon wrote: 2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch These users didn't contribute fixes to their boards (or even just feedback that things needs to be done and testing when others provide patches) - are they even contributors? It's easy to argue in favor of "lots of users" (or contributors if you want), but if they're all but invisible, do they even exist? I contributed a number of changes to address Coverity warnings in the AMD families, and am actively using a corebooted G505s and PC Engines APU. I lurk in the mailing list most of the time, and have a hard time tracking what needs to be done to keep boards alive. On this thread, for example, the updated requirements feel like they are (but are likely not) coming out of the blue. To address the OP, it seems like there is some activity on getting an AGESA RESOURCE_ALLOCATOR_V4 working, but is an AGESA PARALLEL_MP init also needed (and is there any activity or something I can do to help?) Realize resources may not exist to spoon feed problem definitions to a level my brain can handle. The rest of the reply might be due to communication losses of non-face to face transmission medium. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
It's definitely preferable to have platforms working in-tree rather than out of tree. This is a *significant* portion of coreboot's supported platforms and sends a strong signal to anyone using or considering them that they can just forget about the coreboot project because the rug may be pulled out from under them at any time. These users didn't contribute fixes to their boards (or even just feedback > that things needs to be done and testing when others provide patches) - are > they even contributors? > It's easy to argue in favor of "lots of users" (or contributors if you > want), but if they're all but invisible, do they even exist? > People constantly complain about a lack of developer manpower, yet also don't care about how many users coreboot has. Do you not see that the only source of the former is from the latter? Loco is right about coreboot being more developer focused than user focused. While there is now (finally!) some sane documentation for simple things like creating a patch on gerrit, these few guides are very hard to find especially from the coreboot.org frontpage. I'm still not aware of anything even approaching a comprehensive porting guide. There is effectively no path for users to follow to fix even the simplest bug. (eg. I'd love to port from the AM1I-A to the AM1M-A, owning spares of both, but the lack of guidance makes the process a black hole of inestimable time) This is in STARK contrast to a project like PostmarketOS which puts a lot of thought into bringing users into development work. They have font-page guides that go into great detail on creating a new port. They even have detailed guides on how to port a phone to the mainline kernel, for absolute beginners. They have a simple all-in-one script that build the environment, can create the files for a new port, and can automatically package these changes for review. There are a lot of lessons to be learned from pmOS who ran into exactly this problem and fixed it. On Thu, Nov 25, 2021 at 12:17 PM Arthur Heymans wrote: > > 1. These boards will be gone for the people who check the "mainboards > > supported by coreboot" and see only the "new Intel stuff". This > > hinders the coreboot community growth around the "gone boards", and > > also of the coreboot community in general: the fewer boards are > > supported by coreboot, the more difficult it is for a potential > > user/contributor to find the supported board and join us. > > Coreboot supports a lot more platforms than "new Intel stuff", which is > quite an achievement. > To make it possible for very different hardware in one branch, thoughtful > design is needed. > Supporting different codepaths to do the same thing blows up the > complexity of maintenance and makes it harder to > support both old and new boards as you lose track of how code changes can > affect other systems. > Keeping things simple is not optional in a project like coreboot. So it's > not about adding > a minor feature like you said in your previous email. It's really about > keeping > things manageable long term for everyone. That however requires some work > from time to time on some platforms and sometimes dropping boards if no > one steps up to do that work. > > > 2. It's not just the loss of boards - it's also the loss of coreboot > > users/contributors who only have these boards and don't want to switch > > to anything else: i.e. because the newer coreboot-supported boards > > have Intel ME / AMD PSP that are viewed negatively by many people out > > of security considerations, - and security is one of the top reasons > > why the people switch to coreboot in the first place. > > Sorry, not buying that argument at all for AMD AGESA supported platforms. > I don't see a lot of development on gerrit for these platforms especially > in comparison with Intel ones of similar age. > > Regards > Arthur > > On Thu, Nov 25, 2021 at 5:04 PM Mike Banon wrote: > >> > The word 'drop' has ominous connotations, but it's not a deletion. A >> board is never really gone. >> >> "Dropping" 50 boards may be ominous in relation to the future of the >> coreboot project: >> >> 1. These boards will be gone for the people who check the "mainboards >> supported by coreboot" and see only the "new Intel stuff". This >> hinders the coreboot community growth around the "gone boards", and >> also of the coreboot community in general: the fewer boards are >> supported by coreboot, the more difficult it is for a potential >> user/contributor to find the supported board and join us. >> >> 2. It's not just the loss of boards - it's also the loss of coreboot >> users/contributors who only have these boards and don't want to switch >> to anything else: i.e. because the newer coreboot-supported boards >> have Intel ME / AMD PSP that are viewed negatively by many people out >> of security considerations, - and security is one of the top reasons >> why the people switch to coreboot in the first place. >> >> 3. Unless someone will be
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
> 1. These boards will be gone for the people who check the "mainboards > supported by coreboot" and see only the "new Intel stuff". This > hinders the coreboot community growth around the "gone boards", and > also of the coreboot community in general: the fewer boards are > supported by coreboot, the more difficult it is for a potential > user/contributor to find the supported board and join us. Coreboot supports a lot more platforms than "new Intel stuff", which is quite an achievement. To make it possible for very different hardware in one branch, thoughtful design is needed. Supporting different codepaths to do the same thing blows up the complexity of maintenance and makes it harder to support both old and new boards as you lose track of how code changes can affect other systems. Keeping things simple is not optional in a project like coreboot. So it's not about adding a minor feature like you said in your previous email. It's really about keeping things manageable long term for everyone. That however requires some work from time to time on some platforms and sometimes dropping boards if no one steps up to do that work. > 2. It's not just the loss of boards - it's also the loss of coreboot > users/contributors who only have these boards and don't want to switch > to anything else: i.e. because the newer coreboot-supported boards > have Intel ME / AMD PSP that are viewed negatively by many people out > of security considerations, - and security is one of the top reasons > why the people switch to coreboot in the first place. Sorry, not buying that argument at all for AMD AGESA supported platforms. I don't see a lot of development on gerrit for these platforms especially in comparison with Intel ones of similar age. Regards Arthur On Thu, Nov 25, 2021 at 5:04 PM Mike Banon wrote: > > The word 'drop' has ominous connotations, but it's not a deletion. A > board is never really gone. > > "Dropping" 50 boards may be ominous in relation to the future of the > coreboot project: > > 1. These boards will be gone for the people who check the "mainboards > supported by coreboot" and see only the "new Intel stuff". This > hinders the coreboot community growth around the "gone boards", and > also of the coreboot community in general: the fewer boards are > supported by coreboot, the more difficult it is for a potential > user/contributor to find the supported board and join us. > > 2. It's not just the loss of boards - it's also the loss of coreboot > users/contributors who only have these boards and don't want to switch > to anything else: i.e. because the newer coreboot-supported boards > have Intel ME / AMD PSP that are viewed negatively by many people out > of security considerations, - and security is one of the top reasons > why the people switch to coreboot in the first place. > > 3. Unless someone will be manually copying all the time, these boards > won't get the updates of the common coreboot parts, even if such > updates aren't related to the deletion reason. A reason which won't be > understood by the opensource-loving community around the world - on > Phoronix etc. - as good enough for "50 boards drop" - so doing this > may harm the reputation of a coreboot project. > > Of course, the people may finally fork a coreboot to i.e. > "coreboot_extended" or "coreboot_notcorporate" (need a good name) and > continue contributing there. Such a fork may even become more popular > than the original coreboot of the future, because it will support > significantly more boards. But, if this happens, it will fragment the > coreboot community and split / spread thin our joint efforts for not a > good enough reason. > > > It's just that active development ends, as no one is working to keep > them up to date. There is a cost to keeping boards too long when there is > no one maintaining them. > > Even right now there's an active development & maintainership (as > evidenced by all these changes at review.coreboot.org), - just not for > this v4 resource allocator. > > > Would it be ok with you to drop the board, and bring it back when it is > working again? > > I'm not sure I understand: at least my boards from this list are > working perfectly at the moment. > > > They may still build, but they can stop working. People should be able > to count on a board working if they build an image. > > I am often build-testing my boards (didn't notice a > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, > but only because I've been re-using the previously built toolchains to > save time). Also, I am actively tech-supporting all the people who > would like to build coreboot for AMD boards from this list, even right > now I am in an active message exchange with >10 people who are > switching to these boards to run coreboot on them - and any user may > give back to the project one day. > > Hopefully my post above explains why I think "dropping 50 boards is a > bad idea", although I agree that it would be nice
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Dear coreboot folks, Am 25.11.21 um 17:43 schrieb Patrick Georgi: On 25.11.21 17:04, Mike Banon wrote: […] [ forking threat, and follow-up comment ] Please let’s not escalate this. (Type your answer, save it in the draft folder, sleep over it, and then think if you want to send it.) I thank Arthur, for bringing this up on the list. 8.5 months is hopefully enough to review the 3mdeb patches [1] and maybe even Nico’s proposed allocator improvements [2]. Kind regards, Paul [1]: https://review.coreboot.org/c/coreboot/+/53991 "cpu/amd/agesa/family15tn/model_15_init.c: create correct MTRR solution" [2]: https://review.coreboot.org/c/coreboot/+/41956 "device: Introduce v4.5 resource allocator" ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
On November 25, 2021 4:43:35 PM UTC, Patrick Georgi via coreboot wrote: >On 25.11.21 17:04, Mike Banon wrote: >These users didn't contribute fixes to their boards (or even just feedback >that things needs to be done and testing when others provide patches) - are >they even contributors? > >It's easy to argue in favor of "lots of users" (or contributors if you want), >but if they're all but invisible, do they even exist? > I'm one of that invisible contributors. In my opinion coreboot is more developer friendly than user friendly. For me not since I get use to coreboot builds at some point in time. But in general coreboot is hard to get your hands on at first. And board depreciation is not a good idea. I understand that they can be brought back at some point. But lets be realistic that this need some developer time and testing. And in capitalistic world that means money to support old boards. I just hope I am wrong... ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
On 25.11.21 17:04, Mike Banon wrote: 2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch These users didn't contribute fixes to their boards (or even just feedback that things needs to be done and testing when others provide patches) - are they even contributors? It's easy to argue in favor of "lots of users" (or contributors if you want), but if they're all but invisible, do they even exist? Of course, the people may finally fork a coreboot to i.e. Do it. I'm getting tired of people making this particular empty promise. "coreboot_extended" or "coreboot_notcorporate" (need a good name) and Given this: -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ Maybe coreboot_3mdeb_corporate might be a proper name? Regards, Patrick ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
> The word 'drop' has ominous connotations, but it's not a deletion. A board is > never really gone. "Dropping" 50 boards may be ominous in relation to the future of the coreboot project: 1. These boards will be gone for the people who check the "mainboards supported by coreboot" and see only the "new Intel stuff". This hinders the coreboot community growth around the "gone boards", and also of the coreboot community in general: the fewer boards are supported by coreboot, the more difficult it is for a potential user/contributor to find the supported board and join us. 2. It's not just the loss of boards - it's also the loss of coreboot users/contributors who only have these boards and don't want to switch to anything else: i.e. because the newer coreboot-supported boards have Intel ME / AMD PSP that are viewed negatively by many people out of security considerations, - and security is one of the top reasons why the people switch to coreboot in the first place. 3. Unless someone will be manually copying all the time, these boards won't get the updates of the common coreboot parts, even if such updates aren't related to the deletion reason. A reason which won't be understood by the opensource-loving community around the world - on Phoronix etc. - as good enough for "50 boards drop" - so doing this may harm the reputation of a coreboot project. Of course, the people may finally fork a coreboot to i.e. "coreboot_extended" or "coreboot_notcorporate" (need a good name) and continue contributing there. Such a fork may even become more popular than the original coreboot of the future, because it will support significantly more boards. But, if this happens, it will fragment the coreboot community and split / spread thin our joint efforts for not a good enough reason. > It's just that active development ends, as no one is working to keep them up > to date. There is a cost to keeping boards too long when there is no one > maintaining them. Even right now there's an active development & maintainership (as evidenced by all these changes at review.coreboot.org), - just not for this v4 resource allocator. > Would it be ok with you to drop the board, and bring it back when it is > working again? I'm not sure I understand: at least my boards from this list are working perfectly at the moment. > They may still build, but they can stop working. People should be able to > count on a board working if they build an image. I am often build-testing my boards (didn't notice a https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only because I've been re-using the previously built toolchains to save time). Also, I am actively tech-supporting all the people who would like to build coreboot for AMD boards from this list, even right now I am in an active message exchange with >10 people who are switching to these boards to run coreboot on them - and any user may give back to the project one day. Hopefully my post above explains why I think "dropping 50 boards is a bad idea", although I agree that it would be nice to get a resource allocator v4 working on them. On Thu, Nov 25, 2021 at 12:46 AM ron minnich wrote: > > The word 'drop' has ominous connotations, but it's not a deletion. A > board is never really gone. It's git. I can still find the Alpha > boards in there if I go back far enough. It's just that active > development ends, as no one is working to keep them up to date. > > Would it be ok with you to drop the board, and bring it back when it > is working again? > > There is a cost to keeping boards too long when there is no one > maintaining them. They may still build, but they can stop working. > That's happened and in my view it's best not to let it happen. People > should be able to count on a board working if they build an image. > > Thanks > > ron > > > On Wed, Nov 24, 2021 at 12:16 PM Mike Banon wrote: > > > > With all due respect, dropping support for the majority of AMD boards > > - with a quite significant community around them! - doesn't seem like > > a wise decision, if we still care about the coreboot marketshare on > > the worldwide-available consumer PCs. Small improvement in the common > > source, but a huge loss of boards? (almost 50!). For the sake of the > > bright future of the coreboot project, this must be prevented at all > > costs... > > > > Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 > > change where tried to get a resource allocator V4 working for these > > AGESA boards, and despite a tiny size (less than 20 lines) - it almost > > worked, judging by that fam15h A88XM-E booted fine (although there > > might have been some other problems undercover). I wonder if it could > > help and will be happy to test the new changes related to this. > > > > > > On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans wrote: > > > > > > > We could announce this deprecation in the 4.16 release notes, then > > > > deprecate after 4.18 (8.5 months from now). At
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
The word 'drop' has ominous connotations, but it's not a deletion. A board is never really gone. It's git. I can still find the Alpha boards in there if I go back far enough. It's just that active development ends, as no one is working to keep them up to date. Would it be ok with you to drop the board, and bring it back when it is working again? There is a cost to keeping boards too long when there is no one maintaining them. They may still build, but they can stop working. That's happened and in my view it's best not to let it happen. People should be able to count on a board working if they build an image. Thanks ron On Wed, Nov 24, 2021 at 12:16 PM Mike Banon wrote: > > With all due respect, dropping support for the majority of AMD boards > - with a quite significant community around them! - doesn't seem like > a wise decision, if we still care about the coreboot marketshare on > the worldwide-available consumer PCs. Small improvement in the common > source, but a huge loss of boards? (almost 50!). For the sake of the > bright future of the coreboot project, this must be prevented at all > costs... > > Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 > change where tried to get a resource allocator V4 working for these > AGESA boards, and despite a tiny size (less than 20 lines) - it almost > worked, judging by that fam15h A88XM-E booted fine (although there > might have been some other problems undercover). I wonder if it could > help and will be happy to test the new changes related to this. > > > On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans wrote: > > > > > We could announce this deprecation in the 4.16 release notes, then > > > deprecate after 4.18 (8.5 months from now). At that point, we'd create a > > > branch and set up a verification builder so that any deprecated platforms > > > could be continued in the 4.18 branch. > > > > That timeline of 8.5 months does sound fair. I just found this updated > > release schedule in the meeting minutes. > > If we are going to release every 3 months then I guess that's a good way to > > go. > > > > I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll > > update it to reflect that schedule if it can be agreed upon. > > > > On Wed, Nov 24, 2021 at 6:07 PM Martin Roth wrote: > >> > >> Hey Arthur, > >> > >> Nov 24, 2021, 05:50 by art...@aheymans.xyz: > >> > >> > Hi > >> > I would like to suggest to deprecate some legacy codepaths inside the > >> > coreboot tree and therefore make some newer ones mandatory. > >> > ... snip ...> About the timeline of deprecations. Is deprecating non > >> > conforming platforms from the master branch after the 4.16 release in 6 > >> > months a reasonable proposal? > >> > > >> I have no strong opinion about the platform deprecations, although I > >> suspect that PC Engines might be unhappy if it's platforms were removed > >> from the ToT codebase. > >> > >> My preference would be to announce deprecations in the release notes. We > >> just missed the 4.15 release, but we're switching to a 3 month release > >> cadence, so the next release will be in early February, 2.5 months from > >> now. > >> > >> We could announce this deprecation in the 4.16 release notes, then > >> deprecate after 4.18 (8.5 months from now). At that point, we'd create a > >> branch and set up a verification builder so that any deprecated platforms > >> could be continued in the 4.18 branch. > >> > >> Would this schedule work? > >> > >> Martin > >> > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > > > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
> With all due respect, dropping support for the majority of AMD boards > - with a quite significant community around them! - doesn't seem like > a wise decision, if we still care about the coreboot marketshare on > the worldwide-available consumer PCs. Small improvement in the common > source, but a huge loss of boards? (almost 50!). For the sake of the > bright future of the coreboot project, this must be prevented at all > costs... If there is such a community around those boards there must be someone willing to either invest time or money to implement the proposed improvements. Having boards or platforms inside the tree is much cheaper than paying AMI for a crappy closed source BIOS/UEFI. It's still not a free endeavor and code requires maintenance from time to time such that development on the master branch can remain simple and sensible. Not maintaining code from time to time and enforcing some features, is probably far worse for the project. > Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 > change where tried to get a resource allocator V4 working for these > AGESA boards, and despite a tiny size (less than 20 lines) - it almost > worked, judging by that fam15h A88XM-E booted fine (although there > might have been some other problems undercover). I wonder if it could > help and will be happy to test the new changes related to this. The proposed change requires the code to know what memory regions are used and must be reserved. Angel already reviewed the patch it seems, so that's probably a good start. On Wed, Nov 24, 2021 at 9:16 PM Mike Banon wrote: > With all due respect, dropping support for the majority of AMD boards > - with a quite significant community around them! - doesn't seem like > a wise decision, if we still care about the coreboot marketshare on > the worldwide-available consumer PCs. Small improvement in the common > source, but a huge loss of boards? (almost 50!). For the sake of the > bright future of the coreboot project, this must be prevented at all > costs... > > Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 > change where tried to get a resource allocator V4 working for these > AGESA boards, and despite a tiny size (less than 20 lines) - it almost > worked, judging by that fam15h A88XM-E booted fine (although there > might have been some other problems undercover). I wonder if it could > help and will be happy to test the new changes related to this. > > > On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans > wrote: > > > > > We could announce this deprecation in the 4.16 release notes, then > deprecate after 4.18 (8.5 months from now). At that point, we'd create a > branch and set up a verification builder so that any deprecated platforms > could be continued in the 4.18 branch. > > > > That timeline of 8.5 months does sound fair. I just found this updated > release schedule in the meeting minutes. > > If we are going to release every 3 months then I guess that's a good way > to go. > > > > I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll > update it to reflect that schedule if it can be agreed upon. > > > > On Wed, Nov 24, 2021 at 6:07 PM Martin Roth > wrote: > >> > >> Hey Arthur, > >> > >> Nov 24, 2021, 05:50 by art...@aheymans.xyz: > >> > >> > Hi > >> > I would like to suggest to deprecate some legacy codepaths inside the > coreboot tree and therefore make some newer ones mandatory. > >> > ... snip ...> About the timeline of deprecations. Is deprecating non > conforming platforms from the master branch after the 4.16 release in 6 > months a reasonable proposal? > >> > > >> I have no strong opinion about the platform deprecations, although I > suspect that PC Engines might be unhappy if it's platforms were removed > from the ToT codebase. > >> > >> My preference would be to announce deprecations in the release notes. > We just missed the 4.15 release, but we're switching to a 3 month release > cadence, so the next release will be in early February, 2.5 months from now. > >> > >> We could announce this deprecation in the 4.16 release notes, then > deprecate after 4.18 (8.5 months from now). At that point, we'd create a > branch and set up a verification builder so that any deprecated platforms > could be continued in the 4.18 branch. > >> > >> Would this schedule work? > >> > >> Martin > >> > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > > > > -- > Best regards, Mike Banon > Open Source Community Manager of 3mdeb - https://3mdeb.com/ > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
With all due respect, dropping support for the majority of AMD boards - with a quite significant community around them! - doesn't seem like a wise decision, if we still care about the coreboot marketshare on the worldwide-available consumer PCs. Small improvement in the common source, but a huge loss of boards? (almost 50!). For the sake of the bright future of the coreboot project, this must be prevented at all costs... Some time ago I did https://review.coreboot.org/c/coreboot/+/41431 change where tried to get a resource allocator V4 working for these AGESA boards, and despite a tiny size (less than 20 lines) - it almost worked, judging by that fam15h A88XM-E booted fine (although there might have been some other problems undercover). I wonder if it could help and will be happy to test the new changes related to this. On Wed, Nov 24, 2021 at 8:52 PM Arthur Heymans wrote: > > > We could announce this deprecation in the 4.16 release notes, then > > deprecate after 4.18 (8.5 months from now). At that point, we'd create a > > branch and set up a verification builder so that any deprecated platforms > > could be continued in the 4.18 branch. > > That timeline of 8.5 months does sound fair. I just found this updated > release schedule in the meeting minutes. > If we are going to release every 3 months then I guess that's a good way to > go. > > I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update > it to reflect that schedule if it can be agreed upon. > > On Wed, Nov 24, 2021 at 6:07 PM Martin Roth wrote: >> >> Hey Arthur, >> >> Nov 24, 2021, 05:50 by art...@aheymans.xyz: >> >> > Hi >> > I would like to suggest to deprecate some legacy codepaths inside the >> > coreboot tree and therefore make some newer ones mandatory. >> > ... snip ...> About the timeline of deprecations. Is deprecating non >> > conforming platforms from the master branch after the 4.16 release in 6 >> > months a reasonable proposal? >> > >> I have no strong opinion about the platform deprecations, although I suspect >> that PC Engines might be unhappy if it's platforms were removed from the ToT >> codebase. >> >> My preference would be to announce deprecations in the release notes. We >> just missed the 4.15 release, but we're switching to a 3 month release >> cadence, so the next release will be in early February, 2.5 months from now. >> >> We could announce this deprecation in the 4.16 release notes, then deprecate >> after 4.18 (8.5 months from now). At that point, we'd create a branch and >> set up a verification builder so that any deprecated platforms could be >> continued in the 4.18 branch. >> >> Would this schedule work? >> >> Martin >> > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/ ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
Hey Arthur, Nov 24, 2021, 05:50 by art...@aheymans.xyz: > Hi > I would like to suggest to deprecate some legacy codepaths inside the > coreboot tree and therefore make some newer ones mandatory. > ... snip ...> About the timeline of deprecations. Is deprecating non > conforming platforms from the master branch after the 4.16 release in 6 > months a reasonable proposal? > I have no strong opinion about the platform deprecations, although I suspect that PC Engines might be unhappy if it's platforms were removed from the ToT codebase. My preference would be to announce deprecations in the release notes. We just missed the 4.15 release, but we're switching to a 3 month release cadence, so the next release will be in early February, 2.5 months from now. We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch. Would this schedule work? Martin ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
> We could announce this deprecation in the 4.16 release notes, then deprecate after 4.18 (8.5 months from now). At that point, we'd create a branch and set up a verification builder so that any deprecated platforms could be continued in the 4.18 branch. That timeline of 8.5 months does sound fair. I just found this updated release schedule in the meeting minutes. If we are going to release every 3 months then I guess that's a good way to go. I started a CL: https://review.coreboot.org/c/coreboot/+/59618 . I'll update it to reflect that schedule if it can be agreed upon. On Wed, Nov 24, 2021 at 6:07 PM Martin Roth wrote: > Hey Arthur, > > Nov 24, 2021, 05:50 by art...@aheymans.xyz: > > > Hi > > I would like to suggest to deprecate some legacy codepaths inside the > coreboot tree and therefore make some newer ones mandatory. > > ... snip ...> About the timeline of deprecations. Is deprecating non > conforming platforms from the master branch after the 4.16 release in 6 > months a reasonable proposal? > > > I have no strong opinion about the platform deprecations, although I > suspect that PC Engines might be unhappy if it's platforms were removed > from the ToT codebase. > > My preference would be to announce deprecations in the release notes. We > just missed the 4.15 release, but we're switching to a 3 month release > cadence, so the next release will be in early February, 2.5 months from now. > > We could announce this deprecation in the 4.16 release notes, then > deprecate after 4.18 (8.5 months from now). At that point, we'd create a > branch and set up a verification builder so that any deprecated platforms > could be continued in the 4.18 branch. > > Would this schedule work? > > Martin > > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
I think, given how good a job you've all done with the release tags and so on, it's easy for people to get to a working build for a board; therefore, deprecating non conforming platforms make sense, as does your suggestion for six months. On Wed, Nov 24, 2021 at 4:51 AM Arthur Heymans wrote: > > Hi > > I would like to suggest to deprecate some legacy codepaths inside the > coreboot tree and therefore make some newer ones mandatory. > > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes > the codepath for SMM_ASEG. This code is used to start APs and do some feature > programming on each AP, but also set up SMM. This has largely been superseded > by PARALLEL_MP, which should be able to cover all use cases of > LEGACY_SMP_INIT, with little code changes. The reason for deprecation is that > having 2 codepaths to do the virtually the same increases maintenance burden > on the community a lot, while also being rather confusing. > > A few things are lacking in PARALLEL_MP init: > - Support for !CONFIG_SMP on single core systems. It's likely easy to extend > PARALLEL_MP or write some code that just does CPU detection on the BSP CPU. > - Support smm in the legacy ASEG (0xa - 0xb) region. A POC showed > that it's not that hard to do with PARALLEL_MP > https://review.coreboot.org/c/coreboot/+/58700 > > No platforms in the tree have any hardware limitations that would block > migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase. > > The second codepath that I'd like to propose for deprecation is > RESOURCE_ALLOCATOR_V3. > V4 was introduced more than a year ago and with minor changes most platforms > were able to work just fine with it. A major difference is that V3 uses just > one continuous region below 4G to allocate all PCI memory BAR's. V4 uses all > available space below 4G and if asked to, also above 4G too. This makes it > important that SoC code properly reports all fixed resources. > > Currently only AGESA platforms have issues with it. On gerrit both attempts > to fix AMD AGESA codebases to use V4 and compatibility modes inside the V4 > allocator have been proposed, but both efforts seem stalled. See the (not yet > merged) documentation https://review.coreboot.org/c/coreboot/+/43603 on it's > details. It looks like properly reporting all fixed resources is the culprit. > > About the timeline of deprecations. Is deprecating non conforming platforms > from the master branch after the 4.16 release in 6 months a reasonable > proposal? > > The affected boards currently are: > AMD_INAGUA > AMD_OLIVEHILL > AMD_PARMER > AMD_SOUTHSTATION > AOPEN_DXPLPLUSU > AMD_PERSIMMON > AMD_THATCHER > AMD_UNIONSTATION > ASROCK_E350M1 > ASUS_A88XM_E > ASROCK_IMB_A180 > ASUS_AM1I_A > ASUS_F2A85_M > ASUS_F2A85_M_PRO > ASUS_F2A85_M_LE > ASUS_P2B_RAMDEBUG > ASUS_P2B_LS > ASUS_P2B_F > ASUS_P2B_D > ASUS_P2B_DS > ASUS_P3B_F > ASUS_P2B > ODE_E20XX > BIOSTAR_AM1ML > BIOSTAR_A68N5200 > ELMEX_PCM205400 > ELMEX_PCM205401 > GIZMOSPHERE_GIZMO2 > GIZMOSPHERE_GIZMO > HP_ABM > HP_PAVILION_M6_1035DX > JETWAY_NF81_T56N_LF > LENOVO_G505S > LIPPERT_FRONTRUNNER_AF > LIPPERT_TOUCAN_AF > MSI_MS7721 > PCENGINES_APU1_ > PCENGINES_APU2_ > PCENGINES_APU3_ > PCENGINES_APU4_ > PCENGINES_APU5_ > PCENGINES_APU1 > PCENGINES_APU2 > PCENGINES_APU3 > PCENGINES_APU4 > PCENGINES_APU5 > > sidenote: Qemu platforms support both LEGACY_SMP_INIT and PARALLEL_MP init so > I did not list them here. > > Let me know your thoughts. > > Arthur > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
