Re: [coreboot] Porting Kabylake laptop

On 25. Jun 2018 18:18 [e-mail]  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

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/...

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 [e-mail] 
Sent: Monday, June 25, 2018 11:39 AM
To: Coreboot
Subject: Re: [coreboot] Porting Kabylake laptop

On 25. Jun 2018 18:18 [e-mail] 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

Porting Kabylake laptop

[Nico Huber]

Hi Chris,

On 25.06.2018 20:39, [e-mail] wrote:
> On 25. Jun 2018 18:18 [e-mail]  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:
> 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.
> 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.
> 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