My proposal is to drop platforms that aren't being tested, aren't being maintained, or are causing serious problems with general coreboot development.
For example - ASUS KGPE-d16 is still being used and tested, so I wouldn't suggest dropping that code, even though it apparently doesn't support S3, so it was suggested that we drop it. S3 isn't used heavily on servers, so personally I don't think it matters. - The ONLY platform that supports AGESA f12h is torpedo, and it's never been tested, so I'd like to suggest again that it get dropped. - Family 14h is very well tested, with regular testing happening. Do not drop. -- pcengines/apu1/4.9-1870-gd44d4f0f4e/2019-06-03T10_14_06Z -- asrock/e350m1/4.9-2228-gce4d39d2d7/2019-06-29T00_31_14Z - The last time a family 15tn board was tested was in 2019. Do not drop. -- lenovo/g505s/4.9-8-g42d1660/2018-12-21T00_01_02Z - The last time Family16KB was tested was in mid 2018. If it doesn't get tested again by mid 2020, I think we should consider dropping it then. -- asus/am1i-a/4.7-988-ge93634caa0/2018-05-03T08_29_12Z The initial reason we wanted to leave AMD vendorcode alone (8 years ago) was because we hoped that AMD would update it. That hasn't happened, so I've already told several people that they're welcome to make whatever changes they feel are needed. Martin On Thu, Sep 12, 2019 at 10:42 AM Patrick Georgi <pgeo...@google.com> wrote: > > On Thu, Sep 12, 2019 at 07:20:49PM +0300, Kyösti Mälkki wrote: > > Would "some people" or these "advocates" be willing to elaborate? > I CC'd Nico and Martin because I seem to remember that we talked > about AGESA (and its quality and/or life cycle). Nico, for example, > seems to advocate scrapping AGESA to replace it with a rewrite ;-) > > > I would say >50% of our MAINTAINERS file is just bogus when it comes > > to working through issues. > Which is something we're trying to improve. > > > 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. > It's unlikely that they'll find your request hidden in this thread, > which is about something very much outside their domain, so please > start a discussion separately and maybe Cc the people closest to > being maintainers for that part of the code (e.g. affected SoC)? > > > Do you want to extend this with c) coverity scan over vendorcode/ ? > Sorry if I wasn't as clear on this as I wanted to be: I'm not > saying that "it's ugly in Coverity means we'll drop the code", but > we have a couple of folks complaining about AGESA code quality like > all. the. time (e.g. Nico?), and during Jacob's GSoC there was some > talk about how it's unclear how long that code will remain in the > tree anyway (I think Martin can chime in on this). > > As I'm working through Coverity, that was brought back to my attention > and I thought about thinking about that. Also, if somebody wants > to step up as maintainer, Coverity provides a pretty good set of > bite-sized tasks that walk you through the code area of interest > indiscriminately. > > We said to leave vendorcode alone, but that was under the assumption > that it's maintained from some upstream source. Our AGESA sources > quite obviously aren't, so why not open them up to development > (including clean up) some more? > > > Reference to some already existing gerrit comments or mailing list posts > > would be nice. > Mostly chatter on IRC, to be honest. Part of the intent of this mail > was to surface this more officially. > > > AGESA may reach C_ENVIRONMENT_BOOTBLOCK by the time of the next > > release and is already at CAR_GLOBAL_MIGRATION=n. > Well, that's good news! > > > The timeframe for dropping entire platforms has previously > > been couple releases or couple years, > No change intended here. I mostly wanted to avoid bringing this up > formally just days before the intended removal (from feedback on the > removals in 4.10, people don't seem to notice out various deprecation > notices but only when stuff is gone). > > This was about surfacing issues like these earlier, to reduce the amount of > surprise. Having your status update on the C bootblock and CAR migration > implementation is useful for that, too! > > > you are making it sound like you want to drop AGESA vendorcode > > like tomorrow. > I'm sorry to have made that impression. That's definitely not what I was > proposing. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Paul Manicle, Halimah DeLaine Prado _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
