Re: [coreboot] Porting Kabylake laptop

Hi Nico

On 26. Jun 2018 12:56 [e-mail]  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?
> 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.
> > 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

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