[coreboot] Documentation creation for the coreboot wiki - what to do?

[Marshall Dawson]

I agree with Martin's assessment.  I'll elaborate that the suppliers are
simply delivering what their revenue generators ask for.  Those are
overwhelmingly ODMs and OEMs who demand that solutions be provided to them,
not Swiss Army knives or DIY kits.  That's why suppliers design software
that runs on MEs, IMCs, PSPs, sideband controllers, etc.  Customers rarely
care about what a product could do; they want to know what it does.

AMD used to be chill, they released the AGESA code - but then they took it
> closed source again....I would really like to know why.
>
AMD, in particular, requires any open-sourced closed code to go through an
IP scrub process first.  This is prohibitively expensive compared to their
anticipated return on investment.  Those of us interested in coreboot could
never make a convincing business case for the scrub to happen on time.
Without board and silicon support prior to a product's launch, that
would've made coreboot a non-starter for AMD customers.  Developing the
binaryPI was not intended as a slap on freedom, but it was a "something is
better than nothing" approach.

Thanks,
Marshall


On Sun, Jan 29, 2017 at 9:57 AM, Taiidan at gmx.com <Taiidan at gmx.com> wrote:

> On 01/28/2017 08:48 PM, Martin Roth wrote:
>
> On Fri, Jan 27, 2017 at 5:16 PM, Taiidan at gmx.com <Taiidan at gmx.com> wrote:
>>
>>> I would like to know as to how much we are allowed to indicate that x86
>>> OEM's are generally hostile to the FOSFW movement? I don't want to ruffle
>>> any feathers, as these days they are already significantly ruffled.
>>>
>> Hi Talidan,
>>    My personal opinion here is that you're incorrect.  I don't think
>> that they're hostile at all.  I think that the corporations don't see
>> the value in catering to the few people who are interested in
>> completely open firmware.  They're trying to solve issues, and the
>> solutions that they've chosen just happen to completely lock out third
>> party firmware.
>>
>> If you want to change that, I'd say that you have to be noticed, and
>> noticed in a POSITIVE light.  If the coreboot community just complains
>> about the current situation, we're not going to get anywhere.  There
>> are plenty of people at these companies who feel the same way that we
>> do about these sorts of issues, and we only make it harder by saying
>> that the OEMs are 'hostile' or 'evil'.  They aren't - they're just
>> looking to create value for their shareholders by leveraging
>> synergistic solutions.  Or something like that.  :)
>>
>> So while this is just my opinion, I'd recommend just keeping to the
>> facts about the issues, and not going beyond that.  Feel free to point
>> out the issues that Intel's bootguard or AMD's PSP present for us, but
>> I'd try to refrain from anything beyond that.  If you do want to go
>> beyond that, please make it plain that it's coming from you as an
>> individual, and may or may not reflect the coreboot community as a
>> whole.
>>
>> If we want to change things, we need an argument that makes sense to
>> the companies we want to change - Something financial.
>>
>> Martin
>>
>> The only issue is that there won't be a free firmware community in a few
> years due to the actions of intel and AMD as there is no way to shut off
> boot guard or ME/PSP.
> I don't consider a system with FSP/MRC/ME to be "free" firmware as
> coreboot does hardly anything in that situation.
>
> AMD used to be chill, they released the AGESA code - but then they took it
> closed source again....I would really like to know why.
>
>
> IMO getting intelligence agencies and major corporations involved in the
> free firmware movement is what will save it,  assured computing is all the
> rage these days - china and russia are making their own CPU designs and
> DARPA is interested in hardware verification. What corporation that deals
> with sensitive IP wants a black box supervisor processor (magic backdoor)
> on their every device?
>
> They currently do not know how much they need it, let us hope that will
> change.
>
>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20170129/0cb9a4d7/attachment.html>