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

Reply via email to