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