[coreboot] Coreboot Purism BIOS is free? open?

[Zoran Stojsavljevic]

> Intel did not mislead, we told them, and continue to, that we _want_ an
> ME-less design (which is their term for what we asked for).

This is Mission Impossible. The reasons are Technical (bringing up the
platform) and Political => Sales and Marketing
domination/implications.

> And as we grow our leverage will grow, and our influence will grow. This
> is a long-term strategy and is playing out as planned.

Actually, it is vice versa. ME gets more and more complicated, as time
progresses. Understandable why. If INTEL solves Cannon Lake woes with
10nm technology (INTEL struggles for 20 months with yields), ME will
be even more complex to support EUV lithography and its outcomes.

> Not binary-blob free. It was always known this will be a large
> investment of both time and money. But coreboot ported to hardware
> within a few months is an accurate assessment of what I heard, and that
> turned out to be much longer, not in technical nature, but finding the
> right people/developers to do it properly. Now all our (x86) products
> are running coreboot, and will continue to.

As well as FSP. It gets more complicated, although it gets more
structured. There are three parts of the FSP blob now: FSP-S, FSP-M
and FSP-P. Silicon init, MRC and early platform init. And this to
disassemble is quite possible, but then the disassembled code will be
all magic addresses and magic data (except MRC, at least for LPDDR3).

Something like: uint32 read (uint32 * addr), void write (uint32 *
addr, uint32 data), where on some magic addr 0xFF87429C magic data are
stored: 0x0030CF46, and nobody really knows what address points to
(the feature), and what the data mean (since there are fields, usually
from 5 fields +)?! And there are gazillion of such registers there,
undocumented, which are outlined in C-Specs, NOT all of them???

The only proper way how to solve this problem is to force INTEL to
publicly release C-Specs for each and every CORE and ATOM families,
which is equivalent to force NSA to release their deepest secrets to
the public.

Good Luck with all of these efforts!
Zoran Stojsavljevic

On Sun, Dec 24, 2017 at 1:16 AM, Todd Weaver <todd at puri.sm> wrote:
> On Fri, 2017-12-22 at 22:06 -0500, Youness Alaoui wrote:
>> On Tue, Dec 19, 2017 at 3:54 PM, Timothy Pearson
>> <tpearson at raptorengineering.com> wrote:
>> >
>> > Thank you for the detailed explanation.  I guess this is an area in
>> > which experience matters; it is absolutely unacceptable (and not
>> > unexpected) that Intel misled your CEO, but this is sadly not an
>> > uncommon tactic in the industry.
>
> Intel has not misled anything. We knew the ME/FSP/vBIOS were the issues
> (from my first questions to this coreboot mailing list and the replies
> from the community), but there was no perfect alternative, so we chose
> Intel to get hardware (more) people wanted and work and invest toward
> liberating it.
>
> I can say, without much doubt, that if we chose any other platform we
> would have struggled in volume and not advanced any faster or farther
> than we have already.
>
> To liberate hardware, there are three larger paths:
> 1) use existing liberated hardware (gets older and older)
> 2) design using freed chips (low performance)
> 3) use products people want that are not yet fully liberated, invest in
> liberating.
>
> For laptops:
> #1 is already being done by many
> #2 is also being done
> #3 is the path we are doing for laptops.
>
> For a phone:
> #1 doesn't exist
> #2 is the path we are doing
> #3 others are trying
>
> We can then cross-polinate our investment efforts into the phone
> motherboard into a laptop with #2.
>
> I have a published business vision page here:
> https://puri.sm/about/business-model-and-vision/
>
>
>> > One item I would like to call out though is the following:
>> >
>> > > if old or non-x86 architectures were so appealing, you would have
>> > > seen that become the norm rather than the exception)
>
> This statement is accurate. The volume of sales would be significantly
> less if we tried non-x86. And then our growth would be smaller; and our
> investment toward freeing future hardware would not happen; and then
> there would be no advancement toward convenient ethical products, which
> is our goal.
>
>> > Trying to switch architectures may be hard, but it is only
>> > going to get harder day after day as people continue to cling to
>> > false hope that the x86 platform may ever be brought under their
>> > control.
>
> It's pretty simple. With leverage we can change businesses. This is not
> a short-term game, but a long-term... grow-gain leverage-influence
> change-repeat. And this is what we are doing at Purism, and will
> continue. We are not griping about the state of affairs, we have a plan
> to change the future, and are executing on it.
>
>
>> > I wonder, though, if given this information if possibly Raptor and
>> > Purism might have some common business ground here?  Purism has
>> > experience with laptop mechanicals and related concerns, and we
>> > have experience with truly blob-free, powerful hardware --
>> > combining those two could yield an interesting machine...
>
> Ping me off list to discuss. We are always looking for aligned-
> partnerships or collaboration.
>
>
>> > > The main question I have, and this is an honest question, is why
>> > > Purism chose to use the x86 platform as a base for libre
>> > > hardware, when it has been known for some time that said hardware
>> > > could never be made fully blob-free?
>
> See above, I think I laid out and answered this clearly. It's not just
> technical, there is a strong business model behind our approach.
>
>> > > There were (and are) other good ways to make a system that could
>> > > be fully blob-free, for instance ARM, and given the engineering
>> > > effort that is said to have been put into the Purism machines I
>> > > wonder what we could have had if said effort had been put into an
>> > > aarch64 system instead of an x86 system?
>
> Sure, that would sell a small fraction of the quantity, and fail to
> impact the future of computing in a way we model out.
>
>> > > > The second reason is that Todd (CEO) was in talks with Intel
>> > > > and was unfortunately lead to believe that they were open to
>> > > > release an ME-less design CPU for his needs, it ended up not
>> > > > being the case.
>
> Intel did not mislead, we told them, and continue to, that we _want_ an
> ME-less design (which is their term for what we asked for). And as we
> grow our leverage will grow, and our influence will grow. This is a
> long-term strategy and is playing out as planned.
>
> They will not adjust based on small quantities, but quantity =
> leverage, and our influence changes as volumes grow. (e.g. $ =
> influence)
>
>> > > > Todd thought that it would be possible to get a binary blob
>> > > > free coreboot/CPU with a few months of work.
>
> Not binary-blob free. It was always known this will be a large
> investment of both time and money. But coreboot ported to hardware
> within a few months is an accurate assessment of what I heard, and that
> turned out to be much longer, not in technical nature, but finding the
> right people/developers to do it properly. Now all our (x86) products
> are running coreboot, and will continue to.
>
>> > > > A good summary is that we want to "bring
>> > > > blob-free to the hardware that people want", rather than "bring
>> > > > blob-free hardware to the people who want it".
>
> This is great; and I may quote you on that :)
>
> Todd.
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot