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
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
