Re: [coreboot] New board with unsupported cpu, chipset, and superIO
On Aug 28, 2014, at 10:59 AM, ron minnich <rminnich@gmail.com> wrote:
The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :)
How much time and money for the RE effort did you have again? It needs to be a lot. Were I you I would not expect much help from the vendor to RE their code :-)
Time was measured in months. Not weeks nor years. Funds varied, which is why we are gathering interested developers to get some quotes to propose funding the effort.
And you're still going to need the microcode blob, almost certainly, unless you don't like having a working main board.
We require blob-free and a working main board, so this sounds like a really challenging RE effort indeed!
If you NEED blob-free, you may need to go ARM.
We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. Todd.
Am 28.08.2014 um 20:26 schrieb Todd Weaver:
We require blob-free and a working main board, so this sounds like a really challenging RE effort indeed! We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. In that case you will probably have to stick to GM45 or older, or Quark X1000. All other Intel chipsets require - to my knowledge - management engine firmware.
Regards, Patrick
On Aug 28, 2014, at 11:26 AM, Todd Weaver <todd@m2n.com> wrote:
On Aug 28, 2014, at 10:59 AM, ron minnich <rminnich@gmail.com> wrote:
The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) If you NEED blob-free, you may need to go ARM.
We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point.
Per the private messages, I am asking upstream if we can switch to AMD, is AMD in a state where we can attain (meaning it is possible (comparing that to Intel)) a binary free BIOS?
Am 28.08.2014 23:16 schrieb Todd Weaver:
On Aug 28, 2014, at 11:26 AM, Todd Weaver <todd@m2n.com> wrote:
On Aug 28, 2014, at 10:59 AM, ron minnich <rminnich@gmail.com> wrote:
The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) If you NEED blob-free, you may need to go ARM. We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. Per the private messages, I am asking upstream if we can switch to AMD, is AMD in a state where we can attain (meaning it is possible (comparing that to Intel)) a binary free BIOS?
You can, but with chipsets/CPUs released in the last few months you may be out of luck. Right now, it appears AMD does not see compelling enough business reasons to publish the source code for the newest hardware generations, but you may be able to get the source code for the blobs under NDA. That said, there are quite a few pieces of recent (and still in production) AMD hardware which do have full coreboot support. Exceptions from the blob-free guarantee are graphics firmware and USB3 firmware, which are both not executed on the main CPU. Depending on how big your order is (not just "enthusiasts all over the world will surely buy it", but real money spent by your company/organization), you might have some real leverage, even for getting code published. Regards, Carl-Daniel
On Aug 28, 2014, at 2:29 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:
Am 28.08.2014 23:16 schrieb Todd Weaver:
On Aug 28, 2014, at 11:26 AM, Todd Weaver <todd@m2n.com> wrote:
On Aug 28, 2014, at 10:59 AM, ron minnich <rminnich@gmail.com> wrote:
The truth here is that we NEED to have a blob-free version (libreboot), so I have a lot of work ahead of me :) If you NEED blob-free, you may need to go ARM. We cannot easily (actually it would be quite impossible) to move from the Intel hardware at this point. Per the private messages, I am asking upstream if we can switch to AMD, is AMD in a state where we can attain (meaning it is possible (comparing that to Intel)) a binary free BIOS?
You can, but with chipsets/CPUs released in the last few months you may be out of luck. Right now, it appears AMD does not see compelling enough business reasons to publish the source code for the newest hardware generations, but you may be able to get the source code for the blobs under NDA.
Thanks, that helps set the stage with AMD discussions.
That said, there are quite a few pieces of recent (and still in production) AMD hardware which do have full coreboot support. Exceptions from the blob-free guarantee are graphics firmware and USB3 firmware, which are both not executed on the main CPU.
Comparing the blob-free versions from Intel (which are apparently signed, so according to http://www.coreboot.org/Binary_situation are at a 9000+ panic level), would it be possible to have blob-free (probably through RE) that would work (meaning does not require signed binaries) on an AMD board?
Depending on how big your order is (not just "enthusiasts all over the world will surely buy it", but real money spent by your company/organization), you might have some real leverage, even for getting code published.
We will do what we can here. The issue is even with immense leverage, having the source released (from AMI, or AMD, (or Intel for that matter)) would undermine tremendous profit that these companies make by keeping this proprietary. So I’m leaning toward the direction that we’d have to RE the missing pieces (but could be wrong, thus the questions). Todd.
Am 2014-08-28 23:38, schrieb Todd Weaver:
Comparing the blob-free versions from Intel (which are apparently signed, so according to http://www.coreboot.org/Binary_situation are at a 9000+ panic level), would it be possible to have blob-free (probably through RE) that would work (meaning does not require signed binaries) on an AMD board? Newer chipsets (as in yet to be released) come with signed parts, but it seems the scope of the signature is configurable somehow by AMD. There were some mails about that a couple of days ago ("AMD PSP").
We will do what we can here. The issue is even with immense leverage, having the source released (from AMI, or AMD, (or Intel for that matter)) would undermine tremendous profit that these companies make by keeping this proprietary. AMD claims that they stopped working on open sourcing their initialization code because it's lots of work (ie. money) with limited return on investment. How much work that is isn't here or there (most of that is because their internal development process is less than optimal and, like most processes in most organizations, hard to change). But it means that someone could make it worth their while given the right kind of project.
What they don't provide sources for is CPU microcode updates (no one does since it's of limited value without the microcode development toolchain and the microcode itself that is getting updated) and various smaller firmware (USB3 which is a licensed core, IMC, an embedded controller, and the SMU). For IMC and SMU there's some reverse engineering effort, partially documented in the wiki, so by asking the right questions to the right people in this community, plus some development, it might be possible to get them opened up even without AMD's help. Patrick
Am 2014-08-28 23:38, schrieb Todd Weaver:
Comparing the blob-free versions from Intel (which are apparently signed, so according to http://www.coreboot.org/Binary_situation are at a 9000+ panic level), would it be possible to have blob-free (probably through RE) that would work (meaning does not require signed binaries) on an AMD board? Newer chipsets (as in yet to be released) come with signed parts, but it seems the scope of the signature is configurable somehow by AMD. There were some mails about that a couple of days ago ("AMD PSP”).
Thank you I will research that.
We will do what we can here. The issue is even with immense leverage, having the source released (from AMI, or AMD, (or Intel for that matter)) would undermine tremendous profit that these companies make by keeping this proprietary. AMD claims that they stopped working on open sourcing their initialization code because it's lots of work (ie. money) with limited return on investment. How much work that is isn't here or there (most of that is because their internal development process is less than optimal and, like most processes in most organizations, hard to change). But it means that someone could make it worth their while given the right kind of project.
Very helpful, thank you!
What they don't provide sources for is CPU microcode updates (no one does since it's of limited value without the microcode development toolchain and the microcode itself that is getting updated) and various smaller firmware (USB3 which is a licensed core, IMC, an embedded controller, and the SMU). For IMC and SMU there's some reverse engineering effort, partially documented in the wiki, so by asking the right questions to the right people in this community, plus some development, it might be possible to get them opened up even without AMD's help.
This is extremely helpful in making the case against Intel (which was better received than I had thought) we are at least working with the board manufacturer about AMD instead of Intel… Here’s hoping. Thank you all! Todd.
Just a word to whoever does this next: figure out your firmware picture first, THEN pick the hardware. It's never been a good idea to start the other way around. ron
participants (4)
-
Carl-Daniel Hailfinger -
Patrick Georgi -
ron minnich -
Todd Weaver