[coreboot] Porting Kabylake laptop

[Nico Huber]

Hi Chris,

On 25.06.2018 20:39, chrisglowaki at tutanota.com wrote:
> On 25. Jun 2018 18:18 nico.h at gmx.de <mailto:nico.h at 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.huber at 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
______________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xBD56B4A4138B3CE3.asc
Type: application/pgp-keys
Size: 5227 bytes
Desc: not available
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180626/a17a630a/attachment.skr>