search

linuxboot / heads

A minimal Linux that runs as a coreboot or LinuxBoot ROM payload to provide a secure, flexible boot environment for laptops, workstations and servers.
https://osresearch.net/
GNU General Public License v2.0
1.41k stars 183 forks source link

Re-upstreaming and maintainership of the KGPE-D16 - Cost: 30 000E and counting #719

Open tlaurion opened 4 years ago

tlaurion commented 4 years ago

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:

Last updates, newsletter, code source drop : https://github.com/osresearch/heads/issues/719#issuecomment-966729133

tlaurion commented 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

Tonux599 commented 4 years ago

@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.

tlaurion commented 4 years ago

@Tonux599 3mbeb is absolutely willing to do the work.

tlaurion commented 4 years ago

@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. :)

tlaurion commented 4 years ago

Applicable?

tlaurion commented 4 years ago

@pietrushnic

pietrushnic commented 4 years ago

@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.

miczyg1 commented 4 years ago

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.

Tonux599 commented 4 years ago

@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?

pietrushnic commented 4 years ago

@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.

  1. We can split this project and drive as an open and free contribution if there are developers and testers who willing to support the development and debugging. In such a situation we will support whoever will do that as much we can including, coordination review and help in merging code upstream.
  2. We can open any channel that the community is comfortable with to try to gather remaining founds. @tlaurion suggested OpenCollective, we can align probably to any suggestion - we have no problem in handling the administrative part.
  3. We have a PayPal donation button on our website, although this is probably one of the worst options.
  4. We are fine with commercial assignments if anyone is willing to go that path. It can be even a very small part of the task, but at least it will move us forward.
  5. If we can sell a platform in some form or bundle services, which will generate margin, then we can use it to bring back the platform to the mainline.

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.

tlaurion commented 4 years ago

@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.

tlaurion commented 4 years ago

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.

pietrushnic commented 4 years ago

@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.

tlaurion commented 4 years ago

@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.

mikebdp2 commented 4 years ago

@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.

pietrushnic commented 4 years ago

@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.

pkubaj commented 4 years ago

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.

pietrushnic commented 4 years ago

@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.

tlaurion commented 4 years ago

@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.

alexmaloteaux commented 4 years ago

@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.

tlaurion commented 4 years ago

@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 ?

miczyg1 commented 4 years ago

Simply have a look at the coreboot mailing list:

pietrushnic commented 4 years ago

In case of what have to be done I believe Arthur email is quite good. @tlaurion you replied to it here

alexmaloteaux commented 4 years ago

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

Tonux599 commented 4 years ago

@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.

pkubaj commented 4 years ago

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.

alexmaloteaux commented 4 years ago

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

Tonux599 commented 4 years ago

@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?

tlaurion commented 4 years ago

Waiting for an e-mail reply from FSF

tlaurion commented 4 years ago

I would suggest anyone interested in the d16 to be reupstreamed writing to FSF too?

Tonux599 commented 4 years ago

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?

tlaurion commented 4 years ago

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
alexmaloteaux commented 4 years ago

How can we write them ? everybody individually pointing at this issue ? or collectively ?

Best Regards

tlaurion commented 4 years ago

@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.

tlaurion commented 4 years ago

@pietrushnic @miczyg1 : took some time to give love to #472 in link of #712. We are getting near of a Heads baseline.

tlaurion commented 4 years ago

RYF contacted and put 3mdeb in contact directly. Let's see where it goes...

tlaurion commented 4 years ago

@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.

ullbeking commented 4 years ago

@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.

Th3Fanbus commented 4 years ago

@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.

pkubaj commented 4 years ago

@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.

paulmenzel commented 4 years ago

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.

pkubaj commented 4 years ago

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.

paulmenzel commented 4 years ago

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.

ullbeking commented 4 years ago

@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

pietrushnic commented 4 years ago

@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.

Tonux599 commented 4 years ago

In relation to the point above @tlaurion, has Insurgo considered a PrivacyBeast KGPE-D16?

alexmaloteaux commented 4 years ago

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

tlaurion commented 4 years ago

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.

agg1 commented 4 years ago

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 commented 4 years ago

@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.