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 <k.emery....@internode.on.net> 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 <k.emery....@internode.on.net>
> > 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 <matthewwbradl...@gmail.com> 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 <rminn...@gmail.com> 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 <nic...@gmx.de> 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 -- coreboot@coreboot.org
> >>>>>> To unsubscribe send an email to coreboot-le...@coreboot.org
> >>>>> _______________________________________________
> >>>>> coreboot mailing list -- coreboot@coreboot.org
> >>>>> To unsubscribe send an email to coreboot-le...@coreboot.org
> >>> _______________________________________________
> >>> coreboot mailing list -- coreboot@coreboot.org
> >>> To unsubscribe send an email to coreboot-le...@coreboot.org
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
