I think you meant to reply-all on this Keith, not just to me? On Sun, Dec 5, 2021 at 3:28 AM Keith Emery <[email protected]> wrote:
> Bounty source still needs an issue / feature request URL to be able to > determine if the funding goals have been met. Would it be possible to add > this to the coreboot documentation directory and have known bugs and or > feature requests render in an equivelent manner? > > > On 5/12/21 6:48 pm, Matt B wrote: > > From my point of view, I'd be very grateful if we could get this >> community strongly engaged in getting upstream coreboot builds working >> on, e.g., chromebooks. >> > > I fully understand that companies like Google which rely on shipping > coreboot would like it to be as easy as possible to port new platforms. At > the same time, this is a large number of AGESA platforms which have active > and vocal users. They no doubt would like to stay with the mainline to > continue to see fixes and enhancements like > https://github.com/osresearch/heads/issues/453. > > I'm interested in what would get everyone to a better state where things > go more smoothly. There is work underway to overcome the requirements this > time. Now is the best time to think about what can be done to ease the > maintenance burden before the next requirement creates another crisis. > > For example, untangling the AGESA code from the mainboard code to make it > more FSP-like. Examining the stages of what it does and better documenting > it so that e.g. the unknown resources that have been holding up the > allocator switchover are easier to find. Isolating the AGESA code into > stages to make it more modular and improve the most troublesome parts. To > work towards a more "native" port, what makes the most sense to tackle > first? I'm no expert in either AGEA or the minute of coreboot's structure > but those are some things that come to mind. > > As an interested user I'm fully willing and committed to contribute > funding towards such work. Everyone involved in the project has the same > goal in the end. > > -Matt > > On Sat, Dec 4, 2021 at 11:58 PM ron minnich <[email protected]> wrote: > >> based on what I'm seeing so far, 100 hours just means "compiles", >> which is only a fraction of the possible effort to get it to "works". >> You then have 50 boards to get working. >> >> and even then, at real world rates, 100 hours -> 25,000. >> >> There's only so much we can do. I at least would be way happier to see >> effort going into new boards. >> >> On Sat, Dec 4, 2021 at 8:48 PM Keith Emery <[email protected]> >> wrote: >> > >> > >> > I only said 100 hours because that was the figure that somebody stated >> > to shift all the listed boards onto the new Resource Allocator. We need >> > that to happen if these boards are to see maintenance in the future, so >> > I figured it made sense to just start with that. >> > >> > >> > On 5/12/21 5:53 am, ron minnich wrote: >> > > 100 hours of work for 50 boards? 2 hours per board? Each one fully >> > > tested and working as before? 'm pretty surprised. >> > > >> > > On Sat, Dec 4, 2021 at 4:38 AM Keith Emery < >> [email protected]> wrote: >> > >> Getting the listed AGESA boards operating on the new scheduler is >> > >> estimated to take around 100 hours of work. So do we have some idea >> of >> > >> what might be considered an acceptable hourly rate? Also do we have a >> > >> clear estimate of how many people have one of the effected boards? >> That >> > >> at least gives us a funding goal to work with. >> > >> >> > >> Alternatively is there some other way to determine a price to at >> least >> > >> get my specific board working with the new infrastructure? >> > >> >> > >> >> > >> On 4/12/21 12:37 pm, ron minnich wrote: >> > >>> I think the reason the question comes up time and time again is >> > >>> because the effort is non trivial. Were it reasonably easy, it would >> > >>> have been done by now. It's easy to get it to compile, but getting >> it >> > >>> to work solidly is not at all easy. >> > >>> >> > >>> It's very hard to let old systems go. But there's always a tradeoff. >> > >>> >> > >>> From my point of view, I'd be very grateful if we could get this >> > >>> community strongly engaged in getting upstream coreboot builds >> working >> > >>> on, e.g., chromebooks. >> > >>> >> > >>> I.e., upstream coreboot working on systems that are designed for, >> and >> > >>> ship with, coreboot. Even things that look easy are not always easy. >> > >>> >> > >>> ron >> > >>> >> > >>> On Fri, Dec 3, 2021 at 1:07 PM Matt B <[email protected]> >> wrote: >> > >>>>> It's just software, so it could certainly be done. How much work >> would >> > >>>>> be involved is the right question. Alas, I have no idea. One >> needs to >> > >>>>> study the AGESA sources to tell, I guess. >> > >>>> This question has come up time and time again: >> > >>>> What would actually be involved in {"cleaning up","doing a 'real' >> port","whatever else makes sense'} to make these platforms based on AGESA >> as maintainable as corresponding intel platforms? >> > >>>> >> > >>>> I'll happily buy a round of beer (or equivalent) for anyone who >> can provide a clear picture of what the road forward looks like. Then we >> can at least talk in grounded terms. >> > >>>> >> > >>>> -Matt >> > >>>> >> > >>>> On Wed, Dec 1, 2021 at 12:51 PM ron minnich <[email protected]> >> wrote: >> > >>>>> We've always deprecated platforms. And they're still in tree -- >> you >> > >>>>> can build for DEC Alpha if you want. There's no shame in not >> being in >> > >>>>> the latest release. >> > >>>>> >> > >>>>> Given unlimited time and money and people, we could fix all the >> > >>>>> problems. We live in a world of limits, and must do what we can >> with >> > >>>>> the resources we have. >> > >>>>> >> > >>>>> Nobody is stopping anyone from cleaning up the AGESA code. But >> it's >> > >>>>> been about 10 years since it came in, and such cleanup has yet to >> > >>>>> happen. >> > >>>>> >> > >>>>> We should move forward with the resource allocator, and if a board >> > >>>>> can't work with v4, and nobody is willing to do the work, that >> board >> > >>>>> should be left out of new releases. Having v3 and v4 both in-tree >> is >> > >>>>> not a viable long term strategy. >> > >>>>> >> > >>>>> On Wed, Dec 1, 2021 at 8:43 AM Nico Huber <[email protected]> wrote: >> > >>>>>> On 01.12.21 15:57, Ivan Ivanov wrote: >> > >>>>>>> Thank you, these seem to be good points. However, in regards to: >> > >>>>>>> >> > >>>>>>>> If you have any hope of open-source coreboot for newer >> platforms, you shouldn't make it harder for coreboot to advance. >> > >>>>>>> Where to advance? Are there any "newer platforms" that are as >> worthy >> > >>>>>>> as the "older platforms": >> > >>>>>> Not sure how to compare that, nobody has written native coreboot >> code >> > >>>>>> for the platforms that you deem worthy either. Also, ... >> > >>>>>> >> > >>>>>>> 1) as secure: no Intel ME / AMD PSP "security" co-processors, >> which >> > >>>>>>> are seen as harmful to real security by many ; >> > >>>>>> ...open-source AGESA seems worse to me. In theory one could >> review it, >> > >>>>>> but did anyone? AIUI, it even provides runtime code for the OS >> (ACPI >> > >>>>>> DSDT), i.e. tells the OS what to do. >> > >>>>>> >> > >>>>>> So what you call "real security" seems more like wishful >> security to >> > >>>>>> me. Presence of ME or PSP does not provide a security issue per >> se. It >> > >>>>>> depends on your threat model and if they are your weakest spot. >> There >> > >>>>>> are plenty of controllers even in older machines that run code >> from ROM >> > >>>>>> masks. What's the difference? Can we trust vendors with code in >> ROM >> > >>>>>> masks but not with code in flash? These are subtle >> considerations. So >> > >>>>>> far, it doesn't make older hardware more attractive to me. >> > >>>>>> >> > >>>>>> Did I mention that at least one of the pre-PSP platforms already >> has >> > >>>>>> a PSP, just hidden? Ok, I admit I didn't look at the silicon to >> check, >> > >>>>>> but it's common that a silicon vendor puts new stuff early into >> chips >> > >>>>>> to test it. So it seems very likely to be true. We generally >> don't >> > >>>>>> know what exactly lives in these chips. I rather trust what I >> can see. >> > >>>>>> >> > >>>>>>> 2) as affordable: the older devices are possible to get used >> for like >> > >>>>>>> $100-$200. Meanwhile - because of Boot Guard etc. - the "newer >> > >>>>>>> platforms" are unlikely to have coreboot without vendor's >> involvement, >> > >>>>>>> who will gladly charge a big extra for "coreboot support". >> > >>>>>> Last time I checked BootGuard wasn't a big issue, i.e. not so >> many >> > >>>>>> devices ship with it. Did that change? >> > >>>>>> >> > >>>>>> Devices sold today will be as affordable tomorrow (well, on a >> slightly >> > >>>>>> larger timescale). What's your point? >> > >>>>>> >> > >>>>>>> 3) as available: these generic consumer electronics, which have >> been >> > >>>>>>> shipped with a proprietary UEFI but got coreboot support later, >> have a >> > >>>>>>> huge numbers all over the world - compared to the quite limited >> > >>>>>>> availability of newer coreboot platforms. >> > >>>>>> I don't understand this point either. This will change, earth >> keeps >> > >>>>>> turning, right? Also, I'm quite sure that your numbers are wrong >> > >>>>>> anyway. Please check how many Chromebooks are sold, for instance. >> > >>>>>> These, are sold by people who actually support the project btw. >> > >>>>>> >> > >>>>>>> Sorry, I don't see any "newer platforms" which would match the >> "older >> > >>>>>>> platforms" on these critically-important points. >> > >>>>>> You seem to be too much used to look behind. Please look ahead >> from >> > >>>>>> time to time. And regarding security, don't trust what you read >> on >> > >>>>>> the internet. It's far more subtle than non-PSP is secure, PSP is >> > >>>>>> insecure. >> > >>>>>> >> > >>>>>> Also, it's not about old vs. new hardware anyway. There's much >> older >> > >>>>>> hardware than the AGESA ports that will stay maintained. It's >> about >> > >>>>>> hardware that nobody took the time to write a proper, long-term >> main- >> > >>>>>> tainable coreboot for. And I can't blame anyone for it. >> Everything >> > >>>>>> AMD Bulldozer based always seemed like the most unattractive >> hard- >> > >>>>>> ware to me. >> > >>>>>> >> > >>>>>>> So it doesn't seem reasonable to drop the "crappy code" of >> "older >> > >>>>>>> platforms" in favor of the "beautiful code" of "newer >> platforms", if >> > >>>>>>> they could never become as worthy. >> > >>>>>> You made it clear that they are worthy to *you* (even your >> arguments >> > >>>>>> seem extremely fragile, so maybe that changed), so you are free >> to look >> > >>>>>> after their code. Why not start with that instead of complaining >> that >> > >>>>>> nobody else does it for you? >> > >>>>>> >> > >>>>>>> Well, maybe some corporation sees their newer platform as "more >> > >>>>>>> worthy" - despite it's losing on all 3 points above and there >> are >> > >>>>>>> blobs-over-blobs. But they can't speak for the community of >> opensource >> > >>>>>>> hobbyists all over the world, people like you and me. And >> pleasing the >> > >>>>>>> corporations by easing their "burden" - while dropping the >> "older >> > >>>>>>> platforms" which are more worthy - doesn't seem wise, at least >> to >> > >>>>>>> me... >> > >>>>>> You are blaming and talking to the wrong people. Deprecating old >> code >> > >>>>>> was always driven by the most libre developers in this >> community, FWIW. >> > >>>>>> They shoulder the hard work to keep the code base maintainable, >> so I >> > >>>>>> think they should decide what is worthy and what isn't >> (hopefully not >> > >>>>>> based on some weak, wishful arguments). >> > >>>>>> >> > >>>>>> Keeping the code clean makes life easier for other people too, >> sure, but >> > >>>>>> that's what happens when people work together on a project. >> > >>>>>> >> > >>>>>> Nico >> > >>>>>> _______________________________________________ >> > >>>>>> coreboot mailing list -- [email protected] >> > >>>>>> To unsubscribe send an email to [email protected] >> > >>>>> _______________________________________________ >> > >>>>> coreboot mailing list -- [email protected] >> > >>>>> To unsubscribe send an email to [email protected] >> > >>> _______________________________________________ >> > >>> coreboot mailing list -- [email protected] >> > >>> To unsubscribe send an email to [email protected] >> _______________________________________________ >> coreboot mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
