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 (0xa0000 - 0xb0000) 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