Re: [coreboot] [RFH] Native AMD fam10-15 support

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 06/20/2018 03:39 PM, taii...@gmx.com wrote:
> On 06/15/2018 03:33 AM, Kyösti Mälkki wrote:
>> On Fri, Jun 15, 2018 at 8:58 AM, taii...@gmx.com  wrote:
>>
>>> On 06/14/2018 08:42 PM, Kyösti Mälkki wrote:
 On Thu, Jun 14, 2018 at 4:38 AM, qtux  wrote:
 Now, since commit babb2e6 that claims to add S3 support on kgpe-d16 is
 within the latter period, I do not quite see how S3 support could have
 worked with that commit on kgpe-d16.  Or maybe this feature was never
 retested once it was rebased and upstreamed. Nor can I see how it
 could have worked for any commit in 4.6
>>>
>>> I just tested S3 again and it worked fine on my v4.6 D16.
>>>
>>
>> Please state the commit hash of the source tree you built and booted from,
>> we don't literally have such tag as "v4.6".
> 
> I was using the coreboot-4.6.tar.xz from the coreboot download page
> which is why I didn't include the hash.
> 
> [0.00] DMI: ASUS KGPE-D16/KGPE-D16, BIOS
> 4.6-db508565d2483394b709654c57533e55eebace51 07/10/2017
> 
>>
>> Repeat tests with current master.
> 
> Thanks, I will have info for you by the end of the this weekend and I
> will also investigate things myself if S3 doesn't work...
> 


Just wanted to follow up on the bisect offer for thisI'm back in the
D16 code for a different reason and if there's a general commit range
where the issue started, I'm happy to investigate.

Thanks!

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJbM/7nAAoJEK+E3vEXDOFbTXAH/1A5n3tVNLw7vHfZl+RknmGS
H66JAxqLH5oxjJwoJNsnK13LSnNDID7aL6VHbtkJFhDHHgnl6mofWwHldVU2igDG
31reRutYFGrNFzZvQyw5lLFa7dEW1xyZqex7LPO03ZKJFfW7y3ziAgMJNCDSKclM
xA8Qf2+N/bkQN3YV0eiGbe/vbE0B9NijwTxm1ycHlLRqIrWqJsZ6bw5HYBugquO0
FLbadXROjfgxQ8B5LAzOcJgA7ErBY6ZVL6xvH+H0Q/iQzhgsZ/s+hm0hhMZNfRML
uRs44iGy2Y2NsPes9MtK31iVG/BIvI854L+5NShG+sfzUddLrXabqB0C5ZQb7h8=
=c+c9
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[ron minnich]

On Wed, Jun 27, 2018 at 9:15 AM  wrote:

>
> Please correct me if I'm wrong, but I think LinuxBoot doesn't give the
> same security as coreboot+FSP because it leaves the firmware vendor and
> board manufacturer in the trust equation. With the FSP we only have to
> trust Intel.
>
>
you're right for some boards, but not all boards.

Our goal for some platforms is to have just the SEC and PEI as delivered
from the chipset vendor, and then DXEs compiled from source, then
linuxboot. We'd like to remove the firmware vendor and board manufacturer
from the trust equation -- and, interestingly, many board vendors we talk
to also want that very same thing.

We're not there yet, but getting closer all the time. And it's moving fast.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[chrisglowaki]

Hi Ron, Nico, 
27. Jun 2018 15:35 by nic...@gmx.de :


> On 27.06.2018 13:37, > chrisglow...@tutanota.com 
> >  wrote:
>> 26. Jun 2018 20:02 by >> rminn...@gmail.com >>  
>> <>> mailto:rminn...@gmail.com >> >:
>>> For a case like this, where your choice is between two binary blobs (FSP
>>> or UEFI) I would argue that linuxboot is a better way to go.
>
> Question is, what is this "case"? Chris, what is your motivation for the
> coreboot port?
>
>>>
>>> See > github.com/osresearch/heads <>>> http://github.com/osresearch/heads 
>>> >
>>> or > linuxboot.org <>>> http://linuxboot.org >  
>>> for more info.
>>> ron
>>
>> Doesn't linuxbootalso require the FSP blob for memory and silicon
>> initialization on any Intel board after Ivy Bridge?
>
> LinuxBoot is an ambiguous term. What Ron and Philipp suggest here is
> taking an existing UEFI, strip it down to something as light as core-
> boot and plug the Linux kernel in. If you just want to get rid of the
> bloated, often bug haunted, user visible parts of UEFI, this is a
> good way to achieve it. If you want more control over the earlier,
> lower level parts of the boot process, coreboot is the way to go, IMO.
>
> The convenient trick of UEFI/LinuxBoot is that you don't have to care
> about any mainboard specific things, if somebody else already ported
> UEFI for your board. And other than the name suggests, you can boot
> any other OS*, the Linux in LinuxBoot is just a fancy boot loader.

In my case the purpose of porting the laptop is security. LinuxBoot sounds very 
promising and if the coreboot port fails or is unstable it could be the only 
option. Please correct me if I'm wrong, but I think LinuxBoot doesn't give the 
same security as coreboot+FSP because it leaves the firmware vendor and board 
manufacturer in the trust equation. With the FSP we only have to trust Intel.




Thanks

Chris

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[Nico Huber]

On 27.06.2018 17:35, ron minnich wrote:
> On Wed, Jun 27, 2018 at 8:18 AM Nico Huber  wrote:
>> What about PEI, is that manageable too?
>>
> 
> it's a blob. What can I say? We take that blob. It's manageable. If you
> accept that you'll have to use a blob, my experience is still that UEFI is
> easier than FSP.

It's not a blob if you get to do the mainboard port ;) AFAICS, you
either need the binary FSP or the reference code (that FSP contains)
under NDA. What I really would like to know, but I know now you can't
answer that, is if the integration and configuration of the reference
code is easier than configuring FSP. I guess, with the reference code
at hand, you can at least mitigate the lack of documentation for its
options, a little.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] flashrom programmer

[Nico Huber]

Hi Zvika,

On 27.06.2018 05:04, Zvi Vered wrote:
> How can I know what is the right flashrom programmer I should use ?

for your case, `internal` is correct.

> The vendor's programmer works without any external hardware.
> When I tried: flashrom --programmer internal, I got:
> --
> flashrom v0.9.9-rc1-r1942 on Linux 4.13.0-36-generic (x86_64)
> flashrom is free software, get the source code at https://flashrom.org
> 
> Calibrating delay loop... OK.
> WARNING: No chipset found. Flash detection will most likely fail.

It seems your version of flashrom lacks support for your chipset. It
might have been added in the meantime, see [1] for a full list of cur-
rently supported hardware and [2] for list of the latest release. Even
if it's still unsupported, with some luck flashrom just lacks the PCI
ID.

Nico

[1] https://flashrom.org/Supported_hardware
[2] https://flashrom.org/Flashrom/1.0/Supported_Hardware

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[ron minnich]

On Wed, Jun 27, 2018 at 8:35 AM Nico Huber  wrote:

> And other than the name suggests, you can boot
> any other OS*, the Linux in LinuxBoot is just a fancy boot loader.


yes, the name LinuxBoot revives an old misconception, that LinuxBoot can
only boot Linux. Same problem we had with the name LinuxBIOS. Oh well ...
my bad.

>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[Nico Huber]

Hi,

On 27.06.2018 13:37, chrisglow...@tutanota.com wrote:
> 26. Jun 2018 20:02 by rminn...@gmail.com :
>> For a case like this, where your choice is between two binary blobs (FSP
>> or UEFI) I would argue that linuxboot is a better way to go.

Question is, what is this "case"? Chris, what is your motivation for the
coreboot port?

>> 
>> See > github.com/osresearch/heads >
>> or > linuxboot.org >  for more info.
>> ron
> 
> Doesn't linuxbootalso require the FSP blob for memory and silicon
> initialization on any Intel board after Ivy Bridge?

LinuxBoot is an ambiguous term. What Ron and Philipp suggest here is
taking an existing UEFI, strip it down to something as light as core-
boot and plug the Linux kernel in. If you just want to get rid of the
bloated, often bug haunted, user visible parts of UEFI, this is a
good way to achieve it. If you want more control over the earlier,
lower level parts of the boot process, coreboot is the way to go, IMO.

The convenient trick of UEFI/LinuxBoot is that you don't have to care
about any mainboard specific things, if somebody else already ported
UEFI for your board. And other than the name suggests, you can boot
any other OS*, the Linux in LinuxBoot is just a fancy boot loader.

Nico

* Not sure about the status of Windows support, but it seems doable
  if you keep enough UEFI.

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[ron minnich]

On Wed, Jun 27, 2018 at 8:18 AM Nico Huber  wrote:

> so you are doing UEFI board ports yourself now? I always had the impres-
> sion that you merely reuse existing ports and plug in the kernel.


This is probably my imprecise language, sorry about that.

We take SEC and PEI as a given, and the goal, over time, is to replace all
DXEs, including the binary DXECore, with an open source version. I'd
ideally like to see *zero* proprietary DXEs, but I don't expect to get
there. Here's a number: on one board, Trammell reports going from 400 DXEs
to 79. A good start. On another board, we got down to 4.


> Of
> course it's easier when somebody else already did the hard part.


Yes. That's the whole point. We aren't doing the hard part. And on Intel
server, with QPI or Omnipath, we will *never* get the information we need
to do that part anyway. It's not hard in that case, it's impossible. So we
have decided not to do the impossible part either :-)


> What about PEI, is that manageable too?
>

it's a blob. What can I say? We take that blob. It's manageable. If you
accept that you'll have to use a blob, my experience is still that UEFI is
easier than FSP.


> I wonder if they would do the UEFI port themselves. I have the feeling
> that some people still try coreboot with the wrong expectations, they
> hope because it's free software everything will just work as if they
> had paid an IBV (but at no cost).
>

No, they don't do the port. They use the SEC and PEI as given.

People who have done ports know how hard it is. People who have not done
ports have no idea, as you know. Many people still think installing
coreboot is as easy as installing an OS with a DVD ...


> We still own the first instructions (at least those that run from flash
> memory). FSP and what Intel hides in there is not about the processor or
> any architectural bring-up, it's about peripherals. One of them is the
> memory controller, but most are just random bits of Intel's chipsets.
> The part that makes FSP hard to handle is the latter. It could be super
> easy to handle if Intel would concentrate on the parts that they want
> to hide. But they just want to do it wrong.
>

I think what you just said here is that FSP could be, and should be, easy,
but Intel makes it hard? I think I'm agreeing with you.

I've noticed with some dismay that the scope of FSP continues to grow, as
it takes on more and more responsibility.


> Architectures don't matter, commitment to documentation is what makes
> OpenPower open.
>

I think you're right as far as it goes, but further, silicon companies need
either vertical integration on their hardware, so they are able to release
docs; or they need to use IP cores that have documents they can release.

On Power, it seems, IBM has the ability to release docs, and further, it
releases them. Intel has the ability to release docs, and has declined to
do so for almost 15 years. SiFive can't release some of their docs, as I
understand, because it had to license IP.

Commitment to document is necessary but not sufficient.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[Nico Huber]

Hi Ron,

On 27.06.2018 16:47, ron minnich wrote:
> On Wed, Jun 27, 2018 at 4:37 AM  wrote:
> 
>>
>> Doesn't linuxboot also require the FSP blob for memory and silicon
>> initialization on any Intel board after Ivy Bridge?
>>
> No. On x86 we do assume UEFI, however. That's a safe assumption. From what
> I've seen, working with UEFI, as we do in LinuxBoot, is far easier than

so you are doing UEFI board ports yourself now? I always had the impres-
sion that you merely reuse existing ports and plug in the kernel. Of
course it's easier when somebody else already did the hard part. So what
is it exactly that you are comparing here?

> dealing with FSP, ironically. That's partly because we remove at last 75%
> of the UEFI image so we can replace it with Linux. Once you get rid of most
> of UEFI it's a lot more manageable.

What about PEI, is that manageable too?

> 
> We just had a meeting yesterday with a server company that had tried and
> failed a coreboot port; it was just more than they could handle, they got
> no vendor support (surprise!), and it was going to have FSP anyway, hence
> no power-on/reset control in the end. They're going to give linuxboot a
> try.

I wonder if they would do the UEFI port themselves. I have the feeling
that some people still try coreboot with the wrong expectations, they
hope because it's free software everything will just work as if they
had paid an IBV (but at no cost).

> 
> Things are changing. My hope has always been to own the first instruction
> after power-on/reset. That's not going to happen in most x86 futures: x86
> vendors have worked hard to ensure that you can't get control at POR any
> more. If you're going to do binary blobs, I've begun to think linuxboot
> makes the most sense for most scenarios.

We still own the first instructions (at least those that run from flash
memory). FSP and what Intel hides in there is not about the processor or
any architectural bring-up, it's about peripherals. One of them is the
memory controller, but most are just random bits of Intel's chipsets.
The part that makes FSP hard to handle is the latter. It could be super
easy to handle if Intel would concentrate on the parts that they want
to hide. But they just want to do it wrong.

> What's the right architecture for full control? My RISC-V hopes are in
> tatters, so I guess it's back to Power.

Architectures don't matter, commitment to documentation is what makes
OpenPower open.

Nico

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[ron minnich]

On Wed, Jun 27, 2018 at 4:37 AM  wrote:

>
> Doesn't linuxboot also require the FSP blob for memory and silicon
> initialization on any Intel board after Ivy Bridge?
>
>
>
No. On x86 we do assume UEFI, however. That's a safe assumption. From what
I've seen, working with UEFI, as we do in LinuxBoot, is far easier than
dealing with FSP, ironically. That's partly because we remove at last 75%
of the UEFI image so we can replace it with Linux. Once you get rid of most
of UEFI it's a lot more manageable.

This is how easy it is: build a linux kernel with UEFI stub support, run
the simple command to create an FFS from it, put it in the firmware volume
using UEFI tool, done. The DXEcore will eventually find that Linux and run
it.

We have done this in as little as one day with two new servers. Several
companies are working on tools written in Go to build an automated
pipeline. Obviously, we want to remove as much UEFI as possible, but even
the manual procedure outlined above  is good enough for many companies.

There are tens of thousands of servers being sold this month that use
LinuxBoot. There were zero a year ago. Back in the 2000s, we were happy to
find out that over a period of 5 years, 100,000 linuxbios-based server
systems had been sold. That number will be equalled and exceeded in the
next few months with linuxboot nodes.

We just had a meeting yesterday with a server company that had tried and
failed a coreboot port; it was just more than they could handle, they got
no vendor support (surprise!), and it was going to have FSP anyway, hence
no power-on/reset control in the end. They're going to give linuxboot a
try.

Things are changing. My hope has always been to own the first instruction
after power-on/reset. That's not going to happen in most x86 futures: x86
vendors have worked hard to ensure that you can't get control at POR any
more. If you're going to do binary blobs, I've begun to think linuxboot
makes the most sense for most scenarios.

What's the right architecture for full control? My RISC-V hopes are in
tatters, so I guess it's back to Power.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[Zaolin]

Hey Chris,

yes it does. The PI interface is in terms of encapsulation somewhat
cleaner then the FSP integration.
I think that was Ron concern using PI instead of FSP.

If we talking about full customization up to the bootblock and vboot2
support
I would recommend to use coreboot in combination with LinuxBoot payload.

If we talk less effort to get your firmware running maybe LinuxBoot is
the better approach depending
on your platform.


Best Regards, Philipp

On 27.06.2018 13:37, chrisglow...@tutanota.com wrote:
> 26. Jun 2018 20:02 by rminn...@gmail.com :
>
>
>> For a case like this, where your choice is between two binary blobs (FSP or 
>> UEFI) I would argue that linuxboot is a better way to go. 
>> See > github.com/osresearch/heads >  or 
>> > linuxboot.org >  for more info. 
>> ron
>   
>
> Doesn't linuxbootalso require the FSP blob for memory and silicon 
> initialization on any Intel board after Ivy Bridge?
>
>
>
>
> Thanks
>
> Chris
>
>
>
>

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[chrisglowaki]

26. Jun 2018 20:02 by rminn...@gmail.com :


> For a case like this, where your choice is between two binary blobs (FSP or 
> UEFI) I would argue that linuxboot is a better way to go. 
> See > github.com/osresearch/heads >  or > 
> linuxboot.org >  for more info. 
> ron



Doesn't linuxbootalso require the FSP blob for memory and silicon 
initialization on any Intel board after Ivy Bridge?




Thanks

Chris

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot