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