On Thu, Sep 12, 2019 at 5:43 PM Patrick Georgi via coreboot <coreboot@coreboot.org> wrote: > > Hi everybody, > > 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 vendorcode/. > 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 Coverity > issues, where the largest proportion is now AGESA based > after Jacob cleaned up most of the rest of the tree. See > https://scan.coverity.com/projects/coreboot 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 development, > 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. Regards, Kyösti Mälkki _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
