Hi Chris,
On 25.06.2018 20:39, chrisglowaki@tutanota.com wrote:
On 25. Jun 2018 18:18 nico.h@gmx.de mailto:nico.h@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:
- 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