How to maintain AGESA-based ports long-term?
Hi coreboot folks, there have always been platforms in the coreboot tree that are easy to maintain and others, alas, that seem to be the complete opposite. When new features or new iterations of existing code are pushed, we'd love to keep everything up-to-date. But this is infeasible. Given the vast amount of platforms in-tree, including poorly written ones with inex- plicable code, it's simply not possible to demand this from any single developer or entity. Hence, what usually happens is that at first only the easy-to-maintain platforms are updated. This pattern usually works for some time, but at some point it looks like coreboot has been forked within its own tree, making further maintenance too hard. So we drop old code paths and the platforms relying on them from time to time. It seems to me that AGESA-based ports are always on the brink of being dropped. I can't say for sure why that is, neither do I want to pretend to know how to avoid it. However, I'm convinced that they are among the hard to maintain ports that drag the project down. And I have no doubt that we'd have to squabble less about them if somebody would actively take care of the code. I can't say that I'd be of much help and I don't really care about the code. But it seemed to me that other people do care and need a little nudge to get a discussion going. I'll list some thoughts what could be done. Feel free to agree to or dismiss any of it. Some things are mutually exclusive, others are not. Branching --------- I know some people are easily offended by the thought, but I want to mention it anyway as it seems to me like a cheap solution for the com- munity as a whole. We could maintain platforms on separate branches. Keeping things working shouldn't be much effort. At least, I guess the following would be necessary: * Keep the toolchain up-to-date and the code compatible. * Keep the payload hook-ups up-to-date and test them from time to time. Naturally, this is less effort on a branch that is dedicated to specific platforms, i.e. does not keep all the other things in the tree like we have on release branches. I would drop anything not related to the plat- forms in question right after the branch point. This would move most of the effort to the folks who actually benefit from the maintenance. However, given my experience in this community, I would expect people who usually only work on the master branch to still be responsive and helpful. Porting ------- Given that we are talking about platforms that are not based on native coreboot code but unmaintained vendor code instead, it might help to port these platforms to coreboot proper. I don't think that the integration of vendor core is a root-cause of the trouble. FWIW, other vendor code (well, usually in the form of blobs) has been integrated into coreboot with more success. However, a fresh port with decent review could definitely lose a lot of the burden of the old one. It's a huge effort of course, I don't want to hide that. Just like for the famous KGPE-D16 and surrounding platform code, I'd estimate roughly $200k for such an endeavor (maybe half of it for the initial implemen- tation and the rest for both sides during a few months of review). IMHO, this is an investment that was missed initially when these plat- forms were added to coreboot. Generally, getting something to boot with coreboot is rather easy. I guess you can get things running with maybe 20% of the effort necessary for a port of reasonable code quality. How- ever, if things are left in such a state, somebody has to pay 10% on top during every year of maintenance (which is currently left to the active coreboot developers). IOW, the current state is also very expen- sive whilst not getting anywhere, and paid by the wrong people. Documenting Hardware -------------------- The existing documentation, at least AFAICS, is rather thin. Every time some developer wants to advance coreboot and has to touch the respective code, they could use some good documentation. I can't exactly say what is missing. It's like whenever I have to look into a BKDG, I don't find what I'm looking for. Also, it's very hard to tell which AMD document applies to what hardware. Register descrip- tions are usually there, maybe what I'm missing is some in-depth docu- mentation of the concepts. Or maybe it would already help to extend the register descriptions. Also, organizing the available information could help. Comparing BKDGs to Intel's public, scrubbed datasheets, it seems the latter already have more in-depth textual descriptions. Cleaning up the existing ports ------------------------------ Of course, one can also try to continue as usual and bring things for- ward iteratively. This might be the most expensive way, though, so I put it last. Kyösti has already mentioned some things that could be done beyond what is immediately necessary to avoid the current depre- cation plans. He's definitely the guy to talk to about AGESA topics. Generally, just reading the code and bringing it into a readable state would help. There is a whole lot of inexplicable code, sometimes it just can't be explained because it's simply wrong. Sometimes it's just copy-pasta that was written for a different hardware generation. Maybe this could help: Try to figure out for every line of code what assumptions it makes. Try to very such assumptions with the common coreboot code and available documentation. And if it can't be found, and the assumption is about software, time to fix the code probably. If the assumption is about hardware, well, test the hardware (don't trust the code!). If any assumption is a hardware quirk that is not easy to find in the documentation, add a code comment about it. Oh, and I almost forgot, the board ports don't look like coreboot code. There's CamelCase, odd tables in C code (as if there was no devicetree), AGESA configuration done in the code of each and every mainboard that should be done only once in the chipset code... IMHO it looks like a mess. When one is used to coreboot and then sees this, there should be no doubt why we have deprecation squabbles ;) This [1] might be related. Board ports of other platforms have seen a lot of updates over the last ten years, that's not easy for ports where one doesn't know what to begin with. A last thought about board ports, wrt. to blobbed vendor code I stated it like this lately: The board port should be written such that in case one would replace the blob (vendor code) with a native coreboot port, that should be possible without touching the board code. IMO, there shouldn't be a trace of AGESA in the mainboard dirs. The mainboard code should configure the chipset drivers/code and the chipset code can use AGESA to achieve its goal, but shouldn't be force by mainboard code to do so. Nico
On 28.11.21 19:54, Nico Huber wrote:
Oh, and I almost forgot, the board ports don't look like coreboot code. There's CamelCase, odd tables in C code (as if there was no devicetree), AGESA configuration done in the code of each and every mainboard that should be done only once in the chipset code... IMHO it looks like a mess. When one is used to coreboot and then sees this, there should be no doubt why we have deprecation squabbles ;) This [1] might be related. Board ports of other platforms have seen a lot of updates over the last ten years, that's not easy for ports where one doesn't know what to begin with.
Looks like I forgot the ref here. [1] https://en.wikipedia.org/wiki/Broken_windows_theory
My two cents regarding funding: There are quite a lot of concerned users who use AGESA platforms, but aren't able to directly contribute to development (documentation and guides are indeed thin). Funding through the usual channels for the overall coreboot project seems to be impractical for bureaucratic reasons, but perhaps an effort chosen here could be more readily funded through something like https://www.bountysource.com/ ? Even if the full total can't be covered, it may make it more worth developer(s) time to undertake. There's also potential tie-in with https://github.com/osresearch/heads/issues/719 as the goal, cleaned up AGESA code fit for mainline, is very much the same. If they clean up the fam15h code that may provide a good base to undertake other cleanup work for 16h and 14h. On Sun, Nov 28, 2021 at 5:24 PM Nico Huber <nico.h@gmx.de> wrote:
On 28.11.21 19:54, Nico Huber wrote:
Oh, and I almost forgot, the board ports don't look like coreboot code. There's CamelCase, odd tables in C code (as if there was no devicetree), AGESA configuration done in the code of each and every mainboard that should be done only once in the chipset code... IMHO it looks like a mess. When one is used to coreboot and then sees this, there should be no doubt why we have deprecation squabbles ;) This [1] might be related. Board ports of other platforms have seen a lot of updates over the last ten years, that's not easy for ports where one doesn't know what to begin with.
Looks like I forgot the ref here.
Nico Huber:
I'll list some thoughts what could be done. Feel free to agree to or dismiss any of it. Some things are mutually exclusive, others are not.
Thank you for the well written summary. Have been asking myself some of the same questions. Lack the experience to make a recommendation for or against any approach.
Branching --------- I know some people are easily offended by the thought, but I want to mention it anyway as it seems to me like a cheap solution for the com- munity as a whole. We could maintain platforms on separate branches.
Is this different than the status quo? I think the concern here is once platforms are dropped from master, people rarely take the time to consider or backport any improvements to the out of sight, out of mind old branches. On the other hand, concerns about trying to maintain code with mounds of technical debt are entirely valid.
Porting ------- Given that we are talking about platforms that are not based on native coreboot code but unmaintained vendor code instead, it might help to port these platforms to coreboot proper.
You mention the KGPE-D16 as an example. I hadn't followed at the time, but from what I can tell it was a well-written, coreboot native port. However, that didn't save it from getting dropped, presumably under a similar scenario. What would be different with today's scenario, for example?
Documenting Hardware --------------------
Can't speak to this.
Cleaning up the existing ports ------------------------------ Of course, one can also try to continue as usual and bring things for- ward iteratively. This might be the most expensive way, though, so I put it last. Kyösti has already mentioned some things that could be done beyond what is immediately necessary to avoid the current depre- cation plans. He's definitely the guy to talk to about AGESA topics.
Generally, just reading the code and bringing it into a readable state would help. There is a whole lot of inexplicable code, sometimes it just can't be explained because it's simply wrong. Sometimes it's just copy-pasta that was written for a different hardware generation.
The code Kyösti referenced in soc/amd is definitely a lot easier to follow than vendorcode/amd.
Maybe this could help: Try to figure out for every line of code what assumptions it makes. Try to very such assumptions with the common coreboot code and available documentation. And if it can't be found, and the assumption is about software, time to fix the code probably. If the assumption is about hardware, well, test the hardware (don't trust the code!). If any assumption is a hardware quirk that is not easy to find in the documentation, add a code comment about it.
Oh, and I almost forgot, the board ports don't look like coreboot code. There's CamelCase, odd tables in C code (as if there was no devicetree), AGESA configuration done in the code of each and every mainboard that should be done only once in the chipset code... IMHO it looks like a mess. When one is used to coreboot and then sees this, there should be no doubt why we have deprecation squabbles ;) This [1] might be related. Board ports of other platforms have seen a lot of updates over the last ten years, that's not easy for ports where one doesn't know what to begin with.
Your "[1]" footnote didn't seem to make it.
A last thought about board ports, wrt. to blobbed vendor code I stated it like this lately: The board port should be written such that in case one would replace the blob (vendor code) with a native coreboot port, that should be possible without touching the board code. IMO, there shouldn't be a trace of AGESA in the mainboard dirs. The mainboard code should configure the chipset drivers/code and the chipset code can use AGESA to achieve its goal, but shouldn't be force by mainboard code to do so.
Something hybrid like this is what I was considering to remove LEGACY_SMP_INIT. Could the first portions of fam14-16 bootstrap (i.e. up to and including AP early initialization) be done with a more common/cleaner coreboot approach, then chained over to AGESA vendorcode for the rest? I have been unable to figure out the answer or how much work would be involved. If it is a valid approach, might let other native pieces be added in the future to more easily address new requirements.
On 29.11.21 14:49, awokd wrote:
Branching --------- I know some people are easily offended by the thought, but I want to mention it anyway as it seems to me like a cheap solution for the com- munity as a whole. We could maintain platforms on separate branches.
Is this different than the status quo?
Yes, these ports wouldn't hold the master branch back anymore.
I think the concern here is once platforms are dropped from master, people rarely take the time to consider or backport any improvements to the out of sight, out of mind old branches. On the other hand, concerns about trying to maintain code with mounds of technical debt are entirely valid.
They are out of sight either way, IMHO. The original deprecation notice is over a year old, why would anyone still put any effort into it? I assume if there was a dedicated place for these ports, people might even be encouraged to work on it because they don't have to fear that the ports are completely abandoned soon. I guess it depends most on the maintainers of such a branch. If they'd let it rot, things won't get better of course.
Porting ------- Given that we are talking about platforms that are not based on native coreboot code but unmaintained vendor code instead, it might help to port these platforms to coreboot proper.
You mention the KGPE-D16 as an example. I hadn't followed at the time, but from what I can tell it was a well-written, coreboot native port.
AFAIR, it's the exact opposite. IIRC, Timothy asked for $200k to publish the code, clean it up, and for upstreaming. They only got $50k which was enough to publish the code, that IMHO, was in a PoC state (it worked somehow for their selection of CPUs and DRAM, but not generally). And review was mostly skipped. There was this argument all over the review: that the existing code (K8 etc. IIRC) was broken anyway. I can't say if this is true. But it felt a little that upstreaming the KGPE-D16 work, in the given state and with the given resources, led to abandoning the last native AMD ports.
However, that didn't save it from getting dropped, presumably under a similar scenario. What would be different with today's scenario, for example?
Sincere, reasonable funding, clean code, decent review. Everything would (should?) be different. Before you consider paying somebody for the effort, you have to find somebody qualified and willing to do it anyway. I'd start with that. Then ask why they think they could succeed.
Oh, and I almost forgot, the board ports don't look like coreboot code. There's CamelCase, odd tables in C code (as if there was no devicetree), AGESA configuration done in the code of each and every mainboard that should be done only once in the chipset code... IMHO it looks like a mess. When one is used to coreboot and then sees this, there should be no doubt why we have deprecation squabbles ;) This [1] might be related. Board ports of other platforms have seen a lot of updates over the last ten years, that's not easy for ports where one doesn't know what to begin with.
Your "[1]" footnote didn't seem to make it.
Sorry, sent it later: [1] https://en.wikipedia.org/wiki/Broken_windows_theory
A last thought about board ports, wrt. to blobbed vendor code I stated it like this lately: The board port should be written such that in case one would replace the blob (vendor code) with a native coreboot port, that should be possible without touching the board code. IMO, there shouldn't be a trace of AGESA in the mainboard dirs. The mainboard code should configure the chipset drivers/code and the chipset code can use AGESA to achieve its goal, but shouldn't be force by mainboard code to do so.
Something hybrid like this is what I was considering to remove LEGACY_SMP_INIT. Could the first portions of fam14-16 bootstrap (i.e. up to and including AP early initialization) be done with a more common/cleaner coreboot approach, then chained over to AGESA vendorcode for the rest? I have been unable to figure out the answer or how much work would be involved. If it is a valid approach, might let other native pieces be added in the future to more easily address new requirements.
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. However, LEGACY_SMP_INIT sounds like something that is usually done late in ramstage. I'm not sure this is anything to make an early cut. Nico
Nico Huber:
On 29.11.21 14:49, awokd wrote:
Branching --------- I know some people are easily offended by the thought, but I want to mention it anyway as it seems to me like a cheap solution for the com- munity as a whole. We could maintain platforms on separate branches.
Is this different than the status quo?
Yes, these ports wouldn't hold the master branch back anymore.
Meant the status quo approach of deprecating boards and leaving to an older branch. I think you are saying it would be a named branch instead.
I think the concern here is once platforms are dropped from master, people rarely take the time to consider or backport any improvements to the out of sight, out of mind old branches. On the other hand, concerns about trying to maintain code with mounds of technical debt are entirely valid.
They are out of sight either way, IMHO. The original deprecation notice is over a year old, why would anyone still put any effort into it? I assume if there was a dedicated place for these ports, people might even be encouraged to work on it because they don't have to fear that the ports are completely abandoned soon.
I guess it depends most on the maintainers of such a branch. If they'd let it rot, things won't get better of course.
This might not be a bad compromise.
Porting ------- Given that we are talking about platforms that are not based on native coreboot code but unmaintained vendor code instead, it might help to port these platforms to coreboot proper.
You mention the KGPE-D16 as an example. I hadn't followed at the time, but from what I can tell it was a well-written, coreboot native port.
AFAIR, it's the exact opposite.
Thanks for the clarification. Sorry if I'm poking at an old wound for anybody.
On 29.11.21 15:58, awokd wrote:
Nico Huber:
On 29.11.21 14:49, awokd wrote:
Branching --------- I know some people are easily offended by the thought, but I want to mention it anyway as it seems to me like a cheap solution for the com- munity as a whole. We could maintain platforms on separate branches.
Is this different than the status quo?
Yes, these ports wouldn't hold the master branch back anymore.
Meant the status quo approach of deprecating boards and leaving to an older branch. I think you are saying it would be a named branch instead.
Well, if I wanted to maintain a branch I would make it dedicated to these specific ports. That would probably be easier to maintain than a release branch that covers all ports of the given time. Also, it seems to me that leaving things on an anonymous release branch provides too much hope that somebody else will do the work ;) Nico
Personally I don't see any reason for branching, if 99% of the rest of coreboot code (payloads etc.) is compatible. This will only get us outdated for these components on this branch, which otherwise could (and should) be kept simultaneously up-to-date to get the latest goodies. So, just make two folders: 1 - resource allocator v3, 2 - resource allocator v4, and access either v3 or v4 from outside depending on your board selection. пн, 29 нояб. 2021 г. в 18:53, Nico Huber <nico.h@gmx.de>:
On 29.11.21 15:58, awokd wrote:
Nico Huber:
On 29.11.21 14:49, awokd wrote:
Branching --------- I know some people are easily offended by the thought, but I want to mention it anyway as it seems to me like a cheap solution for the com- munity as a whole. We could maintain platforms on separate branches.
Is this different than the status quo?
Yes, these ports wouldn't hold the master branch back anymore.
Meant the status quo approach of deprecating boards and leaving to an older branch. I think you are saying it would be a named branch instead.
Well, if I wanted to maintain a branch I would make it dedicated to these specific ports. That would probably be easier to maintain than a release branch that covers all ports of the given time. Also, it seems to me that leaving things on an anonymous release branch provides too much hope that somebody else will do the work ;)
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
On Tue, Nov 30, 2021 at 6:54 AM Ivan Ivanov <qmastery16@gmail.com> wrote:
Personally I don't see any reason for branching, if 99% of the rest of coreboot code (payloads etc.) is compatible. This will only get us outdated for these components on this branch, which otherwise could (and should) be kept simultaneously up-to-date to get the latest goodies. So, just make two folders: 1 - resource allocator v3, 2 - resource allocator v4, and access either v3 or v4 from outside depending on your board selection.
This can work, however it depends on how much other code is impacted. A good example of this is the new SMM module loader introduced recently to accommodate CPUs with >32 threads (CB:43684). It was merged with "v2" in the filename so that work could continue on newer server CPUs while the original loader was still in use everywhere else. After some time spent testing it, the "v2" module loader became the default and "v2" was dropped from the name (CB:51528). In that case the code was isolated and the newer version was essentially a drop-in replacement. But even then, there was at least one known case where something broke (CB:52765). For something like the resource allocator I would expect a lot more dependencies on other parts of the tree. This can turn into a big and difficult-to-debug mess if code beyond the resource allocator has different behaviors depending on which version is being used. tl;dr: What you suggest is possible, but cost and benefit need to be considered and the cost can be very high if other parts of the codebase are impacted.
Good thing about what I've suggested - "different places for v3 and v4 allocators" - is that it's (almost?) already done ;-) вт, 30 нояб. 2021 г. в 20:12, David Hendricks <david.hendricks@gmail.com>:
On Tue, Nov 30, 2021 at 6:54 AM Ivan Ivanov <qmastery16@gmail.com> wrote:
Personally I don't see any reason for branching, if 99% of the rest of coreboot code (payloads etc.) is compatible. This will only get us outdated for these components on this branch, which otherwise could (and should) be kept simultaneously up-to-date to get the latest goodies. So, just make two folders: 1 - resource allocator v3, 2 - resource allocator v4, and access either v3 or v4 from outside depending on your board selection.
This can work, however it depends on how much other code is impacted. A good example of this is the new SMM module loader introduced recently to accommodate CPUs with >32 threads (CB:43684). It was merged with "v2" in the filename so that work could continue on newer server CPUs while the original loader was still in use everywhere else. After some time spent testing it, the "v2" module loader became the default and "v2" was dropped from the name (CB:51528).
In that case the code was isolated and the newer version was essentially a drop-in replacement. But even then, there was at least one known case where something broke (CB:52765). For something like the resource allocator I would expect a lot more dependencies on other parts of the tree. This can turn into a big and difficult-to-debug mess if code beyond the resource allocator has different behaviors depending on which version is being used.
tl;dr: What you suggest is possible, but cost and benefit need to be considered and the cost can be very high if other parts of the codebase are impacted.
On 01.12.21 11:28, Ivan Ivanov wrote:
Good thing about what I've suggested - "different places for v3 and v4 allocators" - is that it's (almost?) already done ;-)
It would mean a constant burden for the project. The resource allocation is kind of the heart of coreboot's ramstage, it's strongly tied to our devicetree model. Many changes in that area would have to be done twice, and changes to the older code are more expensive than changes to the newer, cleaner code (there were reasons to rewrite it!). Also, we'd be either constantly looking for testers for changes to the old code, or risk to break it which is why branching is so much cheaper for the community as a whole. Basically, what you are asking is that people who want to advance coreboot in that area should work twice as hard (mostly in their limited spare time). Trust me, it's infeasible. You can't talk people into maintaining some- thing for you when you ask them to work on something very pesky for free. Maybe worth to mention again: The platforms that don't work with the v4 allocator don't work because their code is broken. It's subtle bugs that were not visible with the v3 allocator by coincidence. You're also as- king to keep the code buggy. Nico PS. If you have any hope of open-source coreboot for newer platforms, you shouldn't make it harder for coreboot to advance.
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": 1) as secure: no Intel ME / AMD PSP "security" co-processors, which are seen as harmful to real security by many ; 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". 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. Sorry, I don't see any "newer platforms" which would match the "older platforms" on these critically-important points. 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. 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... ср, 1 дек. 2021 г. в 14:26, Nico Huber <nico.h@gmx.de>:
On 01.12.21 11:28, Ivan Ivanov wrote:
Good thing about what I've suggested - "different places for v3 and v4 allocators" - is that it's (almost?) already done ;-)
It would mean a constant burden for the project. The resource allocation is kind of the heart of coreboot's ramstage, it's strongly tied to our devicetree model. Many changes in that area would have to be done twice, and changes to the older code are more expensive than changes to the newer, cleaner code (there were reasons to rewrite it!). Also, we'd be either constantly looking for testers for changes to the old code, or risk to break it which is why branching is so much cheaper for the community as a whole. Basically, what you are asking is that people who want to advance coreboot in that area should work twice as hard (mostly in their limited spare time).
Trust me, it's infeasible. You can't talk people into maintaining some- thing for you when you ask them to work on something very pesky for free.
Maybe worth to mention again: The platforms that don't work with the v4 allocator don't work because their code is broken. It's subtle bugs that were not visible with the v3 allocator by coincidence. You're also as- king to keep the code buggy.
Nico
PS. If you have any hope of open-source coreboot for newer platforms, you shouldn't make it harder for coreboot to advance.
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
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 <nico.h@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-leave@coreboot.org
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 <rminnich@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 <nico.h@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-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
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 <matthewwbradley6@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 <rminnich@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 <nico.h@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-leave@coreboot.org
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
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.nbn@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 <matthewwbradley6@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 <rminnich@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 <nico.h@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-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
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.nbn@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.nbn@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 <matthewwbradley6@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 <rminnich@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 <nico.h@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-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
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 <rminnich@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.nbn@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.nbn@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 <matthewwbradley6@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 <rminnich@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 <nico.h@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-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
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 equivalent manner? Or is this sort of thing usually kept with the code in some other fashion? They're asking for a git URL, that seems to imply that they intend to audit the code before issuing funds. 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 <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 <rminnich@gmail.com <mailto:rminnich@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.nbn@internode.on.net <mailto:k.emery.nbn@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.nbn@internode.on.net <mailto:k.emery.nbn@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 <matthewwbradley6@gmail.com <mailto:matthewwbradley6@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 <rminnich@gmail.com <mailto:rminnich@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 <nico.h@gmx.de <mailto:nico.h@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-leave@coreboot.org <mailto:coreboot-leave@coreboot.org> > >>>>> _______________________________________________ > >>>>> coreboot mailing list -- coreboot@coreboot.org <mailto:coreboot@coreboot.org> > >>>>> To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org> > >>> _______________________________________________ > >>> coreboot mailing list -- coreboot@coreboot.org <mailto:coreboot@coreboot.org> > >>> To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org> _______________________________________________ coreboot mailing list -- coreboot@coreboot.org <mailto:coreboot@coreboot.org> To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org>
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 <k.emery.nbn@internode.on.net> 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 <rminnich@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.nbn@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.nbn@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 <matthewwbradley6@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 <rminnich@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 <nico.h@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-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
participants (7)
-
awokd -
David Hendricks -
Ivan Ivanov -
Keith Emery -
Matt B -
Nico Huber -
ron minnich