<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Nico<br /><br />On 26. Jun 2018 12:56 <a href="mailto:coreboot%40coreboot.org?Subject=Re%3A%20%5Bcoreboot%5D%20Porting%20Kabylake%20laptop&In-Reply-To=%3C7bc3873d-a7f3-1981-3b3b-fa6abc86bf8b%40secunet.com%3E" title="[coreboot] Porting Kabylake laptop" target="_blank" rel="noopener noreferrer">nico.huber@secunet.com</a> wrote: <br /><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;">If you use the exact same processor SKU as the reference board: yes.<br />Otherwise: no. Both the people who implemented FSP and who integrated<br />it into coreboot were lazy: They could have provided defaults for all<br />SKUs but didn't. If in doubt (and in case you don't have an NDA with<br />Intel) better ask here what the right defaults are for your processor.</blockquote><p> </p><p>I have a i5-7200U. Intel has some datasheets available for Kabylake-U. Can they be used to get VR values? <br /></p><p><br /></p><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;">2. Can the laptop work properly without GPIO? I don't know if there is<br /><blockquote>a way to dump the GPIO config in vendor firmware on Kabylake.</blockquote><br />What works with the reset default configuration and what not depends on<br />each board. It is likely to boot in my experience. Have a look at `util/<br />inteltool/` in our source tree. It can dump the GPIO registers for Sun-<br />rise Point (the 100-series PCH that comes with Skylake). The 200-series<br />PCH should be the same, but if you have an SoC version of Kaby Lake<br />(known as Kabylake-U / -Y / -R) things are different. I'll add Youness<br />in CC who might have a patch for that.<br /></blockquote><p><br /></p><p> Unfortunately inteltool doesn't support my PCH yet, probably because I have a Kabylake-U processor. <br /></p><p><br /></p><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><blockquote>3. Are there other settings that could damage the hardware?</blockquote><br />I can't tell if that is the case for your board without knowing your<br />board. Is it generally possible? yes. Though, it is unlikely that core-<br />boot contains code that would harm your board. When you copy code for<br />a reference board, you should also check the C code. It's not much and<br />if there is something you don't understand, better ask. All the board-<br />agnostic code should be safe (but there is no guarantee).<br /></blockquote><p><br /></p><p>Do evaluation boards like KBL RVP8 have only board-agnostic code or do they also have some board-specific code?<br /></p><p> </p><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;">And, as you need an FSP binary by Intel for Kaby Lake, it also has a<br />huge amount of settings (over 700 if you count them individually (but<br />they are actually grouped)). Some of these settings are overridden by<br />coreboot (devicetree settings or static platform code). And their code<br />quality is generally worse than coreboot's (maybe not over all but com-<br />pared to coreboot). So I can't say if FSP doesn't do any harm (though<br />unlikely, as it works for most everybody else so far). The binaries<br />on Github likely have defaults for the non-SoC version btw. Alas, FSP<br />is basically undocumented.</blockquote><p><br /></p><p>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?</p><p><br /></p><p>Thanks a lot for your help, it is very helpful.</p><p>Chris<br /></p> </body>
</html>