On Thu, Nov 25, 2021 at 9:50 PM Angel Pons <th3fan...@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.mal...@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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
