On Thu, Nov 25, 2021 at 9:50 PM Angel Pons th3fanbus@gmail.com 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 kyosti.malkki@gmail.com 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