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

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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 >

Re: [coreboot] flashrom programmer

2018-06-27 Thread 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: >

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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

Re: [coreboot] Porting Kabylake laptop

2018-06-27 Thread 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 > >