On Thu, Sep 12, 2019 at 5:43 PM Patrick Georgi via coreboot
coreboot is shipping AMD's open sourced AGESA for a few generations
as part of its tree.
Some people advocate dropping the code due to its quality and lack
of maintenance while others are happy with using the code.
Would "some people" or these "advocates" be willing to elaborate?
Pretty much none of the style guide rules have ever been applied to
vendorcode, if this is about clang-format or source code style in
So: to help keep this code alive, we'd need
maintainers - people
willing to work through issues, improve the code quality and generally
act as a point of contact if any questions arise.
I would say >50% of our MAINTAINERS file is just bogus when it comes
to working through issues. We can equally make such quality assurance
arguments about FSP2.0, once commercial vendor gets something merged,
they don't really care how much it gets in the way of overall
architecture or subsystems evolution. As an active topic, I don't see
anybody at Intel willing to discuss the topic of how hiding PCI
devices may brake PCI compliance and generally several assumptions in
coreboot PCI subsystem.
Previous decisions by coreboot leadership and/or community meeting
minutes were to let platform obsolition be determined by a) release
requirements, typically announced at least 12 months beforehand and b)
lack of board-status submissions. Do you want to extend this with c)
coverity scan over vendorcode/ ?
One item to start with could be to work through
issues, where the largest proportion is now AGESA based
after Jacob cleaned up most of the rest of the tree. See
Since coreboot seems to accept blobs with ease nowadays, the solution
to keep these platforms can be such that we move AGESA vendorcode to
submodule. We already have infrastructure to embed AGESA as a blob
into CBFS/FMAP. Method has been approved for amd/stoneyridge, so there
should be little to complain about it. Neither coverity or
clang-format rules need to extend to 3rdparty repositories.
Drivers needs support to not get in the way of later
and AGESA is sorely lacking in that department. If you see value
in that code, please step up now, not only when we're looking into
removing that code for good.
Please give detailed sample where AGESA or binaryPI (inside coreboot
proper, not vendorcode) is "sorely lacking or getting in the way" of
current developments. Reference to some already existing gerrit
comments or mailing list posts would be nice. I agree there are things
like SMM_ASEG=y, PARALLEL_MP=n. Do you have something completely
different in mind? I am not surprised if you wanted to deprecate
util/romcc rather sooner than later. If that is the driving force, it
is already covered with requirements for next release.
AGESA may reach C_ENVIRONMENT_BOOTBLOCK by the time of the next
release and is already at CAR_GLOBAL_MIGRATION=n. Situation with
binaryPI is actually worse, selected boards may meet requirements
though. The timeframe for dropping entire platforms has previously
been couple releases or couple years, you are making it sound like you
want to drop AGESA vendorcode like tomorrow.