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] 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

Re: [coreboot] Porting Kabylake laptop

[ron minnich]

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
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[chrisglowaki]

Hi Nico

On 26. Jun 2018 12:56 nico.hu...@secunet.com 

 wrote: 

> If you use the exact same processor SKU as the reference board: yes.
> Otherwise: no. Both the people who implemented FSP and who integrated
> it into coreboot were lazy: They could have provided defaults for all
> SKUs but didn't. If in doubt (and in case you don't have an NDA with
> Intel) better ask here what the right defaults are for your processor.

 

I have a i5-7200U. Intel has some datasheets available for Kabylake-U. Can they 
be used to get VR values? 





> 2. Can the laptop work properly without GPIO? I don't know if there is
>
>> a way to dump the GPIO config in vendor firmware on Kabylake.
>
> What works with the reset default configuration and what not depends on
> each board. It is likely to boot in my experience. Have a look at `util/
> inteltool/` in our source tree. It can dump the GPIO registers for Sun-
> rise Point (the 100-series PCH that comes with Skylake). The 200-series
> PCH should be the same, but if you have an SoC version of Kaby Lake
> (known as Kabylake-U / -Y / -R) things are different. I'll add Youness
> in CC who might have a patch for that.
>




 Unfortunately inteltool doesn't support my PCH yet, probably because I have a 
Kabylake-U processor. 





>> 3. Are there other settings that could damage the hardware?
>
> I can't tell if that is the case for your board without knowing your
> board. Is it generally possible? yes. Though, it is unlikely that core-
> boot contains code that would harm your board. When you copy code for
> a reference board, you should also check the C code. It's not much and
> if there is something you don't understand, better ask. All the board-
> agnostic code should be safe (but there is no guarantee).
>




Do evaluation boards like KBL RVP8 have only board-agnostic code or do they 
also have some board-specific code?


 

> And, as you need an FSP binary by Intel for Kaby Lake, it also has a
> huge amount of settings (over 700 if you count them individually (but
> they are actually grouped)). Some of these settings are overridden by
> coreboot (devicetree settings or static platform code). And their code
> quality is generally worse than coreboot's (maybe not over all but com-
> pared to coreboot). So I can't say if FSP doesn't do any harm (though
> unlikely, as it works for most everybody else so far). The binaries
> on Github likely have defaults for the non-SoC version btw. Alas, FSP
> is basically undocumented.




The FSP package from GitHub comes with config files for FSP. Do they need to be 
used or do only the settings in devicetree matter?




Thanks a lot for your help, it is very helpful.

Chris

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

Re: [coreboot] Porting Kabylake laptop

[Nico Huber]

Hi Chris,

On 25.06.2018 20:39, chrisglow...@tutanota.com wrote:
> On 25. Jun 2018 18:18 nic...@gmx.de  wrote:
>> you can generally boot without a complete port. But you can also damage
>> the hardware if you are not careful. Beside the devicetree settings (pay
>> attention when it comes to the voltage regulator settings!), the GPIO
>> configuration should also match your board. You can try to boot without
>> GPIO configuration (it should be safe because the hardware has to expect
>> the reset defaults for the GPIOs). But *never* try to boot with a copied
>> GPIO configuration from another board.
> 
> Thank you Nico for the warnings! A few questions:
> 
> 1. Is it safe to leave default VR settings from Kabylake Reference Board?

If you use the exact same processor SKU as the reference board: yes.
Otherwise: no. Both the people who implemented FSP and who integrated
it into coreboot were lazy: They could have provided defaults for all
SKUs but didn't. If in doubt (and in case you don't have an NDA with
Intel) better ask here what the right defaults are for your processor.

> 
> 2. Can the laptop work properly without GPIO? I don't know if there is
> a way to dump the GPIO config in vendor firmware on Kabylake.

What works with the reset default configuration and what not depends on
each board. It is likely to boot in my experience. Have a look at `util/
inteltool/` in our source tree. It can dump the GPIO registers for Sun-
rise Point (the 100-series PCH that comes with Skylake). The 200-series
PCH should be the same, but if you have an SoC version of Kaby Lake
(known as Kabylake-U / -Y / -R) things are different. I'll add Youness
in CC who might have a patch for that.

> 
> 3. Are there other settings that could damage the hardware?

I can't tell if that is the case for your board without knowing your
board. Is it generally possible? yes. Though, it is unlikely that core-
boot contains code that would harm your board. When you copy code for
a reference board, you should also check the C code. It's not much and
if there is something you don't understand, better ask. All the board-
agnostic code should be safe (but there is no guarantee).

And, as you need an FSP binary by Intel for Kaby Lake, it also has a
huge amount of settings (over 700 if you count them individually (but
they are actually grouped)). Some of these settings are overridden by
coreboot (devicetree settings or static platform code). And their code
quality is generally worse than coreboot's (maybe not over all but com-
pared to coreboot). So I can't say if FSP doesn't do any harm (though
unlikely, as it works for most everybody else so far). The binaries
on Github likely have defaults for the non-SoC version btw. Alas, FSP
is basically undocumented.

>> Regarding the EC, you can learn a lot about its interface from the
>> ven- dor's ACPI implementation. Unless the board uses a lot of PnP
>> interfaces of the EC (unlikely for a modern laptop), the datasheet is
>> usually not helpful. What you really would need is documentation
>> about the EC firm- ware and its OS interface. And you'll likely not
>> get that.
> 
> Can the laptop boot to Linux without EC support in coreboot?

Likely yes, sometimes the EC requires specific configuration by the host
firmware but I've never seen something that would stop it from booting.
Configuration aside, in case the BIOS flash chip is shared with the EC,
you have to take care to keep the EC firmware in place of course. Same
holds for all the Intel platform stuff that usually shares the flash
(when using flashrom, tell it to operate on the BIOS region only:
`--ifd -i bios`, that should be safe unless the EC firmware is in the
BIOS region).

> Regarding the ACPI implementation, can that be dumped using acpidump

Yes.

> and then used in the ec.asl file?

Not verbatim. For a fully working implementation you'll have to under-
stand and reimplement it. This is usually the biggest part of a laptop
port.

Nico

-- 
M. Sc. Nico Huber
Senior Consultant SINA Software Development and Verification
Division Defence
secunet Security Networks AG

Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325
E-Mail: nico.hu...@secunet.com
Mergenthalerallee 77, 65760 Eschborn, Deutschland
www.secunet.com
_

secunet Security Networks AG
Sitz: Kurfürstenstraße 58, 45138 Essen, Deutschland
Amtsgericht Essen HRB 13615
Vorstand: Dr. Rainer Baumgart (Vors.), Axel Deininger, Thomas Pleines
Aufsichtsratsvorsitzender: Ralf Wintergerst
__


0xBD56B4A4138B3CE3.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[chrisglowaki]

26. Jun 2018 07:44 by alexfein...@hotmail.com :

>
> Chris,
>
> The GPIO tables are usually compiled into the BIOS C code and not into ASL. 
> While decompiling DSDT can give you some insight into what GPIOs are used for 
> say WLAN power control or some of the hardware interrupts, there is also a 
> number of Kaby Lake pins that drive system signals or control onboard 
> hardware without going through ASL. For instance Coreboot build for KBL RVP3 
> uses this:
>
> https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/kblrvp/variants/rvp3/include/variant/gpio.h
>  
> 
>
>
> What Niko suggests is to review carefully all the lines that use GPIO_CFG_GPO 
> (output) to ensure that no pins that are configured as output unless you are 
> absolutely sure about where they go. Of course, this requires you to 
> understand the code
>

Hi Alex,
I mentioned dumping the ACPI code to ask if I can use it in the .asl files in 
mainboard directory (for example 
https://github.com/coreboot/coreboot/blob/master/src/mainboard/purism/librem_skl/acpi/ec.asl
 
).
 Dumping data for gpio.h I guess is hard because inteltool doesn't support 
Kabylake and I have no schematics. Nico said I can try booting without the GPIO 
config, but I don't know if the laptop will be usable without it.
Thanks,
Chris

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

Re: [coreboot] Porting Kabylake laptop

[Alex Feinman]

Chris,

The GPIO tables are usually compiled into the BIOS C code and not into ASL. 
While decompiling DSDT can give you some insight into what GPIOs are used for 
say WLAN power control or some of the hardware interrupts, there is also a 
number of Kaby Lake pins that drive system signals or control onboard hardware 
without going through ASL. For instance Coreboot build for KBL RVP3 uses this:

https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/kblrvp/variants/rvp3/include/variant/gpio.h


What Niko suggests is to review carefully all the lines that use GPIO_CFG_GPO 
(output) to ensure that no pins that are configured as output unless you are 
absolutely sure about where they go. Of course, this requires you to understand 
the code




From: coreboot  on behalf of 
chrisglow...@tutanota.com 
Sent: Monday, June 25, 2018 11:39 AM
To: Coreboot
Subject: Re: [coreboot] Porting Kabylake laptop

On 25. Jun 2018 18:18 nic...@gmx.de<mailto:nic...@gmx.de> wrote:

you can generally boot without a complete port. But you can also damage
the hardware if you are not careful. Beside the devicetree settings (pay
attention when it comes to the voltage regulator settings!), the GPIO
configuration should also match your board. You can try to boot without
GPIO configuration (it should be safe because the hardware has to expect
the reset defaults for the GPIOs). But *never* try to boot with a copied
GPIO configuration from another board.


Thank you Nico for the warnings! A few questions:

1. Is it safe to leave default VR settings from Kabylake Reference Board?

2. Can the laptop work properly without GPIO? I don't know if there is a way to 
dump the GPIO config in vendor firmware on Kabylake.

3. Are there other settings that could damage the hardware?



Regarding the EC, you can learn a lot about its interface from the ven-
dor's ACPI implementation. Unless the board uses a lot of PnP interfaces
of the EC (unlikely for a modern laptop), the datasheet is usually not
helpful. What you really would need is documentation about the EC firm-
ware and its OS interface. And you'll likely not get that.


Can the laptop boot to Linux without EC support in coreboot?

Regarding the ACPI implementation, can that be dumped using acpidump and then 
used in the ec.asl file?


Thanks,

Chris


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

Re: [coreboot] Porting Kabylake laptop

[chrisglowaki]

On 25. Jun 2018 18:18 nic...@gmx.de  wrote:


> you can generally boot without a complete port. But you can also damage
> the hardware if you are not careful. Beside the devicetree settings (pay
> attention when it comes to the voltage regulator settings!), the GPIO
> configuration should also match your board. You can try to boot without
> GPIO configuration (it should be safe because the hardware has to expect
> the reset defaults for the GPIOs). But *never* try to boot with a copied
> GPIO configuration from another board.




Thank you Nico for the warnings! A few questions:

1. Is it safe to leave default VR settings from Kabylake Reference Board?

2. Can the laptop work properly without GPIO? I don't know if there is a way to 
dump the GPIO config in vendor firmware on Kabylake.

3. Are there other settings that could damage the hardware?


 


> Regarding the EC, you can learn a lot about its interface from the ven-
> dor's ACPI implementation. Unless the board uses a lot of PnP interfaces
> of the EC (unlikely for a modern laptop), the datasheet is usually not
> helpful. What you really would need is documentation about the EC firm-
> ware and its OS interface. And you'll likely not get that.
>




Can the laptop boot to Linux without EC support in coreboot? 


Regarding the ACPI implementation, can that be dumped using acpidump and then 
used in the ec.asl file?




Thanks,

Chris


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

Re: [coreboot] Porting Kabylake laptop

[Nico Huber]

Hi Chris,

On 25.06.2018 16:50, chrisglow...@tutanota.com wrote:
> I have a Kabylake laptop with a Sunrise Point chipset, that I want to
> port to coreboot using the FSP blob. I have no coding skills, but can
> follow the Librem build coreboot script and use code from ports using
> FSP 2.0 (Librem 15v3, Google Kabylake Chromebooks, Kabylake RVP8) to
> create mainboard directory for the laptop with proper devicetree. The EC
> on the laptop is an ITE with no datasheet available. Is it possible to
> at least get the laptop to boot using some code from these ports + the
> FSP and then use console log to fix issues? Can bad code alone damage
> the laptop?

you can generally boot without a complete port. But you can also damage
the hardware if you are not careful. Beside the devicetree settings (pay
attention when it comes to the voltage regulator settings!), the GPIO
configuration should also match your board. You can try to boot without
GPIO configuration (it should be safe because the hardware has to expect
the reset defaults for the GPIOs). But *never* try to boot with a copied
GPIO configuration from another board.

Regarding the EC, you can learn a lot about its interface from the ven-
dor's ACPI implementation. Unless the board uses a lot of PnP interfaces
of the EC (unlikely for a modern laptop), the datasheet is usually not
helpful. What you really would need is documentation about the EC firm-
ware and its OS interface. And you'll likely not get that.

Hope that helps,
Nico

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