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 <[email protected]> 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 (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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
