Open tlaurion opened 4 years ago
Traces: u-bmc kgpe-d16 actual board status
This board works as a QubesOS server while work is still needed. Freshly landed QubesOs-network-server code
A followup on https://github.com/osresearch/heads/issues/717#issuecomment-625825019
@tlaurion did 3mdeb decide not to take it on? It would be good to have as it's the only completely blob free board I can think of that's qubes compatible. Provided a 6200 series is used.
@Tonux599 3mbeb is absolutely willing to do the work.
@Tonux599 @mikebdp2
NlNet decided to not take it on (by funding the project's work). Q: Will we decide to take it on and make it happen? Let's see. :)
@pietrushnic
@tlaurion sorry, for not replying, recently we have quite a lot on my plate. Definitely, we would like to publish here documents that we sent to NLNet while applying for a grant. There is also a slightly modified version that we provided to Insurgo on Slack. Both documents rely on coreboot state in December 2019. @miczyg I think you can push grant content to 3mdeb GitHub repo as PR and link here for review.
This Pull Request contains the application 3mdeb sent to NLNet to obtain the grant: https://github.com/3mdeb/kgpe-osf/pull/1 Feel free to comment and review.
@pietrushnic @miczyg1 When should we expect an outcome? Also could you briefly outline any ways that members of the community could support you if or if not you get funding?
@Tonux599 there is no timeline since there is no official commitment from anyone to fully found the effort. We get some good words from various individuals and organizations, but that's all. @tlaurion mentioned that he can sponsor part of the effort, but we are not sure anyone would be happy with half-finished stuff. Vikings Gmbh sent us hardware so we have something to work on. NLNet did not approve of this grant, so I would not expect it will change in the future - I may be the wrong here. To sum the status of this project is "not founded" so we even do not put that on schedule and worry more about founded effort e.g. TrenchBoot and fwupd for Qubes OS.
How the community can help? We are very open here, whatever works for the community.
We would like to help, but without funding, we will do the best effort and it may take very long to bring back this platform. Please note our goal is not just to bring back the platform to mainline, but create a structure in which long term maintenance would not cost a lot. We did that for PC Engines routers for over 4 years.
@Tonux599 : For the moment, step would be to get people interested in the port. Let's remember that the KGPE-D16:
So the point here would be first to get enough attention so that the story doesn't repeat itself. Insurgo is interested to fund a big part of the work, but we concluded that we would not do this alone.
Some history:
Putting a bounty tag for this.
Something really interesting was proposed on this QubesOS ticket: https://github.com/QubesOS/qubes-issues/issues/2809#issuecomment-626111758
@pietrushnic, I would love to hear on your reception. This would basically mean that the independent tasks could be independently funded upon PR acceptation. Not sure how to orchestrate this.
We are currently experimenting with OpenCollective, while the fees are really high, which makes the move less interesting (a lot of money being lost in translation).
Other options might be more interesting, like Whonix did.
So the question here being mainly:
See this ticket to see how chicken/egg problems can last for a year even when money is available without a clear plan.
This is the inverse problem here, just like funded work normally work. Tasks here are defined, costs attached for work to be done is quantified with a fair price.
@tlaurion XVilka suggestion looks interesting, but definitely key problem is orchestration. We would like to avoid the situation when 3 or more teams work on a given feature in parallel and then post results claiming the founds. There should be serious commitment based on proven reputation and trust, otherwise, we have public bidding problem where lower price wins with quality.
Whonix stuff is even better, but we would have to research how it looks from the taxation and administration perspective.
@pietrushnic I'm not sure there is conflict between the two ideas with XVilka avenue. If the ticket is clear saying that 3mdeb realizes the work in question (milestones) and funds are released upon proof of work (PR).
But you are better placed then I am to see if this would work or not for 3mdeb.
@tlaurion and @pietrushnic : Have you contacted a Free Software Foundation? Since they have a lot of interest in RYF devices and are probably using these KGPE-D16 servers by themselves, if they'd learn about this critical situation - maybe they'll decide to co-fund?
P.S. also, some notes at #717 may be relevant.
@mikebdp2 we (as 3mdeb) never contacted FSF. I'm not sure if the situation is critical but it will get worst over time. From experience longer platform lays unmaintained bigger would be effort to bring it back. Do you know anyone who we should reach?
@tlaurion I believe you are in a better position to talk with FSF, then 3mdeb.
22000E isn't that much different from what Raptor wanted for OpenBMC port (at https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-offer.php). Maybe you should set up similar crowdfounding? Currently you only say "we are ready to work" etc. Raptor did the same and received no money, but when they officially started crowdfounding, it turned out there were enough people interested in it to gather the money.
@pkubaj very good point. It looks like Martin was intermediary gating the process. In case of difference in pricing, please note this was a different time and they are in the US not in PL, their costs are way higher than ours. More to that we are Yocto Participants and have Embedded Linux people on board, OpenBMC uses Yocto/OE build system, so this also simplifies the situation for 3mdeb.
@mikebdp2 we (as 3mdeb) never contacted FSF. I'm not sure if the situation is critical but it will get worst over time. From experience longer platform lays unmaintained bigger would be effort to bring it back. Do you know anyone who we should reach?
@tlaurion I believe you are in a better position to talk with FSF, then 3mdeb.
@pietrushnic writing to them.
@Tonux599 : For the moment, step would be to get people interested in the port. Let's remember that the KGPE-D16:
* was funded by [Libreboot and put upstream by RaptorEngineering](https://libreboot.org/docs/hardware/kgpe-d16.html) but previous work did not receive enough attention to be maintained and got dropped in coreboot 4.11 release for lack of maintainership. * the community crowdfunded the port of the[ BMC chip to OpenBMC ](https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-offer.php)and that work wasn't maintained. * NlNet refused to fund the work because they didn't understand the reasoning of funding old platform.
So the point here would be first to get enough attention so that the story doesn't repeat itself. Insurgo is interested to fund a big part of the work, but we concluded that we would not do this alone.
Some history:
* [FOSDEM talk by 3mdeb on AMD coreboot status](https://fosdem.org/2020/schedule/event/coreboot_amd/) * [Reddit thread on announced drop of the KGPE-d16](https://www.reddit.com/r/linux/comments/dz2hlt/boards_like_asus_kgped16_the_most_powerful/)
Putting a bounty tag for this.
Hi is there a list of the bugs/linux crash that Michal talk about in his fosdem talk ? Do they only happen when iommu is enabled ?
Btw i have a kgpe-d16 with jtag header soldered and an olimex. So if you are starting any group for dev , put me in, free time is limited but i can always help a bit and test.
@alexmaloteaux asked:
Hi is there a list of the bugs/linux crash that Michal talk about in his fosdem talk ? Do they only happen when iommu is enabled ? @miczyg1 ?
Simply have a look at the coreboot mailing list:
In case of what have to be done I believe Arthur email is quite good. @tlaurion you replied to it here
I have read the various mail list entry and i cant reproduce any of them. Actually i have a pretty stable system so far so i will list here my config and test , maybe others can use it as baseline to try to triggers issues and/or star the long 4.12 migration process. please note i have a pure server usage for this board and not a desktop pc.
Ill try to post a more detail description of the tpm issue i m facing later on
BR
@alexmaloteaux regarding TPM, TPM2 is currently unsupported with heads, see #287 however the Asus 90-C1B0AU-00XBN0VZ is a TPM1.2 module compatible with heads and this board.
I have two of those boards, one is a desktop, the other one is a server. Both run coreboot 4.11 tag.
Both run FreeBSD, the desktop is sometimes booted to Linux.
Both are stable. I didn't test averything that @alexmaloteaux tested. I'm pretty sure PCI passthrough won't work with bhyve due to CPU's missing some required features.
I have two of those boards, one is a desktop, the other one is a server. Both run coreboot 4.11 tag.
Both run FreeBSD, the desktop is sometimes booted to Linux.
Both are stable. I didn't test averything that @alexmaloteaux tested. I'm pretty sure PCI passthrough won't work with bhyve due to CPU's missing some required features.
63xx Series supports AMD-Vi and can support PCI passthrough , except os/coreboot bug
@mikebdp2 we (as 3mdeb) never contacted FSF. I'm not sure if the situation is critical but it will get worst over time. From experience longer platform lays unmaintained bigger would be effort to bring it back. Do you know anyone who we should reach? @tlaurion I believe you are in a better position to talk with FSF, then 3mdeb.
@pietrushnic writing to them.
@tlaurion any luck?
Waiting for an e-mail reply from FSF
I would suggest anyone interested in the d16 to be reupstreamed writing to FSF too?
I would suggest anyone interested in the d16 to be reupstreamed writing to FSF too?
@tlaurion any chance of seeing what you wrote or if not guidelines on what would good to include in the correspondence?
I would suggest anyone interested in the d16 to be reupstreamed writing to FSF too?
@tlaurion any chance of seeing what you wrote or if not guidelines on what would good to include in the correspondence?
@Tonux599: Contacted them through patron@fsf.org and business@fsf.org.
ryf@fsf.org might be of interest.
Hello FSF,
Insurgo here!
We have tried to get NlNet fund the KGPE-D16 revival. As you may know,
coreboot dropped support for that board in coreboot 4.11, leaving the
last RYF platform unmaintained and now rotting.
3mdeb made a really good grant application, but NlNet didn't really
understood the importance of maintaining old hardware, and unfortunately
the ball got dropped.
The details are in this ticket:
https://github.com/osresearch/heads/issues/719
I would love to start a discussion with you guys on what is possible and
if funds were available from you to jump in this subproject.
Thierry
Insurgo Open Technologies
How can we write them ? everybody individually pointing at this issue ? or collectively ?
Best Regards
@alexmaloteaux from my understanding of the past, interest from end users and enterprises should be expressed individually by the most numerous number of individual voices to should interest and why it matters.
@pietrushnic @miczyg1 : took some time to give love to #472 in link of #712. We are getting near of a Heads baseline.
RYF contacted and put 3mdeb in contact directly. Let's see where it goes...
@pietrushnic @miczyg1 there is a call preparation with RMS from GNU, vikings.net and Tiberiu from tehnoetic.com
I advised that you should join the discussion and shared Piotr e-mail address. Will follow through.
@alexmaloteaux
Btw i have a kgpe-d16 with jtag header soldered
Alexandre, I was really impressed to read that you got the JTAG header installed on the ASUS KGPE-D16 board :-) I assume that you also had to remove the solder plugs from the board first? If you are reading this message, and if you are willing to give a little advice, please could you send me a sign?! :-) I have been preparing the board to remove the solder plugs safely, and I would love to compare notes with somebody who has already done it successfully.
@tlaurion about the e-mail to FSF:
We have tried to get NlNet fund the KGPE-D16 revival. As you may know, coreboot dropped support for that board in coreboot 4.11, leaving the last RYF platform unmaintained and now rotting.
The chosen wording makes it seem as if it is the coreboot project's fault that the KGPE-D16 ended up unmaintaned and rotting. However, I have seen no one maintaining KGPE-D16 support in upstream coreboot, only users complaining about things not working. That the code for this mainboard got dropped from coreboot after the 4.11 release is not the reason why the board is no longer maintaned, but the other way around: as there had been no maintenance going on for a rather long time (even though there were plenty of bugs to fix), it had become a maintenance burden for coreboot developers and the code eventually got dropped as a result. Quite surprising, given that several companies are making profit by putting coreboot onto these boards.
Moreover, it is not the last RYF platform. It might be the most powerful x86 platform, but definitely not the only one.
@tlaurion about the e-mail to FSF:
We have tried to get NlNet fund the KGPE-D16 revival. As you may know, coreboot dropped support for that board in coreboot 4.11, leaving the last RYF platform unmaintained and now rotting.
The chosen wording makes it seem as if it is the coreboot project's fault that the KGPE-D16 ended up unmaintaned and rotting. However, I have seen no one maintaining KGPE-D16 support in upstream coreboot, only users complaining about things not working. That the code for this mainboard got dropped from coreboot after the 4.11 release is not the reason why the board is no longer maintaned, but the other way around: as there had been no maintenance going on for a rather long time (even though there were plenty of bugs to fix), it had become a maintenance burden for coreboot developers and the code eventually got dropped as a result. Quite surprising, given that several companies are making profit by putting coreboot onto these boards.
Moreover, it is not the last RYF platform. It might be the most powerful x86 platform, but definitely not the only one.
What were those bugs? I have coreboot 4.11 working on two KGPE-D16 boards. It has some issues, but they are easy to workaround. Those boards are quite finicky to set up with RAM compatibility issues etc., but this is also the case with vendor firmware.
I think those "reports" about broken coreboot were just users doing things wrong. And coreboot developers, instead of noticing that it works for other users (I repeatedly reported that) decided to go the easy way - just nuke it.
There's also another thing. I'm not a firmware developer, so I wouldn't be able to fix any issues in coreboot. But it happens that I'm a FreeBSD ports developer and I often fix ports that I don't care about, but I know users care. coreboot developers didn't have that sort of attitude. I wonder why. I just hope that there wasn't anyone sabotaging coreboot, because I would be sad to see that.
I vote for closing this issue, as too much FUD is spread.
@tlaurion about the e-mail to FSF:
We have tried to get NlNet fund the KGPE-D16 revival. As you may know, coreboot dropped support for that board in coreboot 4.11, leaving the last RYF platform unmaintained and now rotting.
The chosen wording makes it seem as if it is the coreboot project's fault that the KGPE-D16 ended up unmaintaned and rotting.
I agree that the wording is not optimal.
[…]
What were those bugs? I have coreboot 4.11 working on two KGPE-D16 boards. It has some issues, but they are easy to workaround. Those boards are quite finicky to set up with RAM compatibility issues etc., but this is also the case with vendor firmware.
I think those "reports" about broken coreboot were just users doing things wrong. And coreboot developers, instead of noticing that it works for other users (I repeatedly reported that) decided to go the easy way - just nuke it.
We talked about this in #coreboot@irc.freenode.net quite often: Random boot failures, all of memory not supported, higher energy usage compared to vendor firmware, problems loading latest microcode, ….
There's also another thing. I'm not a firmware developer, so I wouldn't be able to fix any issues in coreboot. But it happens that I'm a FreeBSD ports developer and I often fix ports that I don't care about, but I know users care. coreboot developers didn't have that sort of attitude. I wonder why. I just hope that there wasn't anyone sabotaging coreboot, because I would be sad to see that.
Hardware development is much harder than software development. You need to test the changes on actual hardware. Chipset changes affect other boards too, so you have to test those too. Also you need to have understanding of the hardware.
You can get active, and push the collecting the money forward by starting some kind of crowdfunding.
We talked about this in #coreboot@irc.freenode.net quite often: Random boot failures, all of memory not supported, higher energy usage compared to vendor firmware, problems loading latest microcode, ….
Random boot failures - that happens to me maybe in 1% or so of boot attempts (I mean, very rarely). True, vendor firmware doesn't do that, but this is so low priority to me that I literally don't care, All of memory not supported - isn't that also the case with vendor firmware? That would mean there's a hardware issue, which coreboot can at best workaround. Still there ARE RAM sticks that work properly, higher energy usage - that's unfortunately true, but that causes energy bills to go up, it doesn't cause any usage issues, Problems loading latest microcode - I don't have this issue, I have coreboot built with the latest microcode and it works.
Sure, there ARE issues that prevent coreboot from achieving 100% feature parity with vendor firmware. But, this is also the case with other boards. On ASUS F2A85-M I had to manually run fancontrol on Linux because CPU would overheat otherwise and FreeBSD was unusable on it (due to no fancontrol). Yet, I can see F2A85-M is still in upstream coreboot.
On ThinkPad X230, AFAIK the yellow USB port (that can charge devices even when the laptop is off) works like all other USB ports (so it charges only when the laptop is on). X230 is also still in upstream coreboot.
So IMO arguments that there are bugs don't hold as long as it's actually possible to get the board working and users are reporting them working.
Please let’s talk in IRC, before this issue gets even more convoluted.
You totally misunderstand, why the board was removed from the main branch (but it’s still in the branch 4.11_branch
).
It was not about the bugs or an incomplete port, it’s because the developers decided that each platform/board has to support certain features. Please read the release notes.
We talked about this in #coreboot@irc.freenode.net quite often: Random boot failures, all of memory not supported, higher energy usage compared to vendor firmware, problems loading latest microcode, ….
Random boot failures - that happens to me maybe in 1% or so of boot attempts (I mean, very rarely). True, vendor firmware doesn't do that, but this is so low priority to me that I literally don't care,
You asked, what bugs, and claimed there are none. Come on. That you live with them, is another topic.
All of memory not supported - isn't that also the case with vendor firmware? That would mean there's a hardware issue, which coreboot can at best workaround. Still there ARE RAM sticks that work properly,
The vendor firmware supports all 256 GB of memory. Where did you get this misinformation from? And again, how is your last statement even related?
higher energy usage - that's unfortunately true, but that causes energy bills to go up, it doesn't cause any usage issues, Problems loading latest microcode - I don't have this issue, I have coreboot built with the latest microcode and it works.
Good for you. I guess you do not use the Linux kernel?
Sure, there ARE issues that prevent coreboot from achieving 100% feature parity with vendor firmware. But, this is also the case with other boards. On ASUS F2A85-M I had to manually run fancontrol on Linux because CPU would overheat otherwise and FreeBSD was unusable on it (due to no fancontrol). Yet, I can see F2A85-M is still in upstream coreboot.
On ThinkPad X230, AFAIK the yellow USB port (that can charge devices even when the laptop is off) works like all other USB ports (so it charges only when the laptop is on). X230 is also still in upstream coreboot.
So IMO arguments that there are bugs don't hold as long as it's actually possible to get the board working and users are reporting them working.
See my statement at the very top. No idea, where you got your information about the cause for removal from. And people can still use the version from 4.11 (even up to the removal commit). Why do they need the new features, if it works as you said?
Thanks to the payload concept, people can still use newer payloads, which makes the main difference to them.
Anyway, I am out, and kindly ask you to inform yourself more diligently about the whole situation.
@paulmenzel
Please let’s talk in IRC, before this issue gets even more convoluted.
If we are going to move the discussion then the mailing list would be vastly better. It is important to correct the misunderstandings on the record. IRC is too "whizzy" to be able to absorb the complexities of the problems and the social interactions that led to this problem in the first place.
It's a convoluted issue and I think participants at all levels of experience are still trying to understand what's really going on. If this had been discussed on a mailing list then I would at least have been aware of the problems. If on IRC then no chance, because I'm not on IRC nearly as much as I used to be (I just can't).
Personally, I am trying to get much more actively involved in this, especially since I recently realized that the lack of support for the D16 port of coreboot was much less supported than I originally thought. It was only by reading this specific, complicated, conversation -- which has been necessary to tease out the misunderstandings -- that I realized the nature of the problem AT ALL.
I don't think that shifting the conversation to IRC is going to help clarify the issue for me. This thread has been necessarily convoluted because that is the nature of the problem!! It's not necessarily a bad thing, because we are exposing the issues that need to be brought to the surface. And I REALLY want to get involved with this project -- the coreboot port to D16 -- which I have already invested significant amounts of personal finances, time, and education into.
In fact, I think moving to IRC will make understand the issues worse for me because my daughter is about to start school and family life is becoming even more important now so I am unable to sit in IRC all day every day. (Compared to the last several years.)
In summary, the complexity of this conversation and working through it is actually necessary to understand the nature of the problem, which is just as much a social issue as a technical one. If the conversation is moved somewhere else, I vote for mailing list, not IRC.
/cc @Th3Fanbus
@Th3Fanbus
Quite surprising, given that several companies are making profit by putting coreboot onto these boards.
It is easy to write that, but hard to prove profit
hypothesis. Hardware margins are not so big and I'm pretty sure the volume of those boards does not justify further investment especially when the previous one failed.
@ullbeking
In summary, the complexity of this conversation and working through it is actually necessary to understand the nature of the problem, which is just as much a social issue as a technical one.
I agree with social part, technical is little bit easier for us (3mdeb). There is too much, not needed, misunderstanding and throwing rocks. IMO the community is about trust, responsibility, and eventually reputation. I'm sure we all are acting in goodwill here, but there should be an understanding that no company can afford infinite firmware support without a net profit margin. We believe it is possible to create after-market support driven by the community if it is big enough. That approach is hard like any B2C project.
In an ideal world, we would have enough traction in B2B relations to support the community. There are success stories behind that e.g. PC Engines, which we support for more than 4 years. There is Olimex and Allwinner story presented at FOSDEM 2020 that IMO applies here. To drive this success we need people like @tlaurion, coordinators, and organizers not in a chaotic way but well-organized project/product management way. Otherwise, we just have chaos or count on luck that NLNet or FSF will support.
Someone may ask if 3mdeb knows that why it will not organize everything? The answer is that we already delivered as much as we can and we plan to keep our promises to some point, despite time passing by and situation is more and more complex. We also have limited resources, which we have to manage wisely to deliver to the community great new open-source firmware projects/products.
What we can do? We should look at our peers, especially business peers, and figure out how they can benefit from well-maintained KGPE-D16, or maybe you have an idea for a business (even very small one) based on fully open platform. Of course, the goal is to get even small monetary contributions from them and gather the whole amount to reenable KGPE-D16 in upstream coreboot. We open to talk with those peers and negotiate conditions, then inform community about the progress.
We are not experienced with crowdfunding, but eventually will get there, if someone knows that environment we would be glad to talk about that. At some point, @tlaurion pointed to this campaign which in my opinion is a great example of how things can be organized.
Long run (12 months +) we can have a bug bounty program that will gather founds for maintainership and bug fixing.
In relation to the point above @tlaurion, has Insurgo considered a PrivacyBeast KGPE-D16?
Hi sorry for asking but until there is a final place to ask question , can somebody tell me if there is any solution/workaround for the energy usage.
im using cb 4.10 and i lowered the frequency of my 2x6378 to 1400 with powerd on hardenedbsd and it is mostly ok . But at 2400 Hz i need to have my dynatron g34 heatsink running at 100% all the time and the small room where the server is located is becoming really hot after a few hours of usage.
Thanks
EDITED.
In relation to the point above @tlaurion, has Insurgo considered a PrivacyBeast KGPE-D16? @Tonux599: Of course, but the actual situation of unknown stable hardware sourcing (TPM, board, BMC chip, CPU, memory..) and required work to make the kgpe-d16 maintained and back into upstream coreboot is out of my personal scope FTM.
Coreboot in heads is now pinned to specific version in master since #776. So the work to make the kgpe-d16 work with coreboot 4.11 can then start by the community, on which I will help, but won't pioneer without funding.
If someone here wants to help, then it goes back to starting a crowdfunding page, on which Insurgo would jump in and fund part of the work too.
Unfortunately, this is the situation we are in right now. My focus is more on current blob free laptops and future proof platforms. But would gladly work conjointly on bringing back to life the kgpe-d16.
Still no news from the FSF as of now and unfortunately went the farthest I could from a community, unpaid, perspective on my own time, for this platform (#134, #472 ... Your turn.)
Any help/tangible plan welcome on making this funded partially / conjointly would be awesome. Otherwise im a bit overwhelmed by other tasks to lead on this one.
Thierry/Insurgo
On July 15, 2020 1:11:58 PM UTC, Tonux599 notifications@github.com wrote:
In relation to the point above, @tlaurion has Insurgo considered a PrivacyBeast KGPE-D16?
-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/osresearch/heads/issues/719#issuecomment-658758622 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Not that anyone asked but I feel urged to drop a note concerning support for various AMD AM3/G34 boards. AM4 generation and similar are dead already anyway as far as i am concerned. same holds true for anything equipped with ME and similar. 1) branch 4.11 exists and can be contributed to and i welcome the fact it could be considered "stable" now for final review 2) alltogether the quality of what's present for AMD AM3/G34 after a decade of development raises concerns by itself, given this branch reached deprecated state with a quality present which I had considered not ready for production when this gear reached markets 10 years ago. the only difference to vendor bios i see concerning this is vendors do not provide sources. and to prevent a misunderstanding i might add it is certainly not coreboot devs to blame for this situation. 3) some patches for branch 4.11 are worked on to fix some AM3 board (https://github.com/agg1/coreboot/commits/master), which may be a decent alternative to KGPE-D16 and a viable option for a devs who couldn't afford a corebooted workstation for thousands of bucks 4) most importantly i would urge the industry including the FOSS people to rethink their general attitude towards resource requirements, as if it was necessary for amateur hackers and downstream developers to suck kilowatts from the powerwall with a 32core workstation and 256GiB of RAM, meanwhile a Hexacore with 16GiB RAM should do for another decade to come for some system integration tasks and distro maintenance. i can and do maintain a self-made hardened livedvd linux distro and it finished compiling everything from source in less than 24hours and 150Watts power draw only on a corebooted am3 workstation due to some optimizations und cuttings 5) my budget, and even if i could afford a KGPE-D16 i wouldn't want it but instead industry including FOSS people should align their resource requirements so development can be done on commodity hardware such as AM3 boards or quadcore laptops with 16GiGs of RAM with acceptable electricity costs for 24/7 full load operation, which makes me wonder again why up until recently a dual core with 2GB RAM was the only option officially tested with AM3-generation commodity hardware. same holds true for the chaotic nature of documentation available (BIOS, ACPI, chipsets, UEFI) which requires almost a livetime of work to attach some peripherals, initialize memory, etc. it is a nightmare. 6) i could rant day and night about industry habits (20 million LoC for GCC alone). again, rethink if industry could afford to loose another generation of amateur hackers them instead playing video games on threadripper workstations with PSP then
@tlaurion about the e-mail to FSF:
We have tried to get NlNet fund the KGPE-D16 revival. As you may know, coreboot dropped support for that board in coreboot 4.11, leaving the last RYF platform unmaintained and now rotting.
The chosen wording makes it seem as if it is the coreboot project's fault that the KGPE-D16 ended up unmaintaned and rotting.
@paulmenzel @Th3Fanbus: I am really sorry for the impact those words had. My intention was more to say exactly like everyone here is saying, maybe with clumsier words: the KGPE-D16 got dropped because of a lack of consistent maintainership/testing and other problems IMHO, where others disagreed... I think that most of the KGPE-D16 users came from libreboot project, which was using a static/older "distribution" of coreboot, which again, in my opinion, gave the illusion that those two projects were disjoint and diluted efforts.
The goal here is to learn from the past, not to blame anybody. When I say that the KGPE-D16 was left rotting, its historicism and I should not do that logic error since it's a reasoning that can happen only after the fact, while I personally tried to entice involvement prior of the drop, contacting the actors personally.
The facts are there though: in coreboot port not having enough working status reports in time for it to be maintained, down to crowdfunded OpenBMC port which stayed as a PoC with issues reported, confirmed, fixes provided while not merged for OpenBMC build system; no maintainership was made in time, nor regression testing to prevent dropping.
This leaves us where we are now, where OpenBMC port was left behind and branched, coreboot port is diverging from upstream from 4.11 (with missing security fixes and increasing costs of putting that board upstream).
It is really a sad story but there needs to be demand and community involvement at some point.
However, I have seen no one maintaining KGPE-D16 support in upstream coreboot, only users complaining about things not working. That the code for this mainboard got dropped from coreboot after the 4.11 release is not the reason why the board is no longer maintained, but the other way around: as there had been no maintenance going on for a rather long time (even though there were plenty of bugs to fix), it had become a maintenance burden for coreboot developers and the code eventually got dropped as a result. Quite surprising, given that several companies are making profit by putting coreboot onto these boards.
That is an interesting point on which I can't comment. On their defense, I would say that Viking provided a board to 3mdeb and were willing to contribute (coreboot mailing post missing). I am not aware of their other contributions. I can only say that I contacted them to joint efforts on Heads+OpenBMC when it was going to be public. No joint effort happened. I also have to learn from this in the future where I do not yet understand what is to be learned from that past.
Moreover, it is not the last RYF platform. It might be the most powerful x86 platform, but definitely not the only one.
Agreed, while:
Other board criticism was documented in earlier posts of this thread.
@miczyg1 made an awesome talk here including status of KGPE-D16. Please read my slides 45+ here for a global comprehension of the actual status of blobs in newer x86 boards. RYF on Intel/AMD will not happen for newer boards.
I think we should revive the KGPE-D16 and KCMA-D8 as a community but I fought enough on my own and no door opened following my personal efforts to date. I would gladly support someone taking that leadership and moving things forward from a different perspective, both with my time and financially; but won't lead this myself anymore.
I am ready for some constructive suggestions, though.
What do we do with those KGPE-D16/KCMA-D8 boards that will be the last PSP free, virtualization/QubesOS ready platforms while newer&freer platforms comes to maturity? Will there be a workforce, community driven, that will make this board come back to life? How do we aorganize around this as a community?
I'll personally watch this thread closely and will participate willingly. If the discussion moves somewhere else, please tag me in.
There was a proposition to do required work under refused grant application. If there is interest from third party to fund conjointly needed work, board could be maintained and reupstreamed, under u-bmc, coreboot and under Heads.
Edit:
Proposition from 3mdeb here
History here
~Possible funding path here~
Trail of 4.11 reported problems: https://github.com/osresearch/heads/issues/719#issuecomment-995879031
Last updates, newsletter, code source drop : https://github.com/osresearch/heads/issues/719#issuecomment-966729133