Re: [coreboot] 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
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[chrisglowaki]

Hi Nico

On 26. Jun 2018 12:56 nico.hu...@secunet.com 

 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? 





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




 Unfortunately inteltool doesn't support my PCH yet, probably because I have a 
Kabylake-U processor. 





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




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

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 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/variants/rvp3/include/variant/gpio.h


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

On 25. Jun 2018 18:18 nic...@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?

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


-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Bayley Bay FSP-based CRB

[Zvi Vered]

Dear Jose & Nico,

Thank you very much for your help !

Best regards,
Zvika

On Thu, Jun 21, 2018 at 11:28 AM Jose Trujillo 
wrote:

> Hello Zvika,
> Look for the list of Linux commands to dump many of the information from
> your original BIOS running, maybe there you will find this information.
>
> Also, some configuration can be seen from your original BIOS running Intel
> FIT for Baytrail in Windows.
>
> About configuring those settings in coreboot look for other examples in
> the coreboot tree about configuring PCI devices in devicetree.cb and other
> places.
>
> I Am new to coreboot too and please correct me if I Am wrong.
> Good Luck!
> J. Trujillo
>
> ‐‐‐ Original Message ‐‐‐
> On June 21, 2018 3:34 AM, Zvi Vered  wrote:
>
> Hello,
>
> Thank you very much for the detailed reply.
> Vendor's BIOS contains few peripherals initialization.
> For example: PCIe enumeration, SATA controller, USB etc.
> In case of PCIe enumeration, the generation of PCIe (1,2,3) can be set.
> Should vendor supply code for this ? or any other information ?
> How can I write it from scratch ?  Can Intel provide information on how to
> implement this initialization ?
>
> Thank you,
> Zvika
>
>
> On Mon, Jun 18, 2018 at 11:22 AM Jose Trujillo via coreboot <
> coreboot@coreboot.org> wrote:
>
>> Hello Zvika:
>> 1.- Usually it is not necessary to change the CBFS size unless the
>> compiler complain of lack of space.
>> 2.- You should not worry about this setting to make your system to work.
>> 3.- You should not use FSP_PACKAGE_DEFAULT if your plan is to use SIO
>> because it will enable SOC internal COM1, instead (if your plan is to use
>> FSP) enable FSP and add  a VGA bios bin manually (The use of FSP is
>> optional but I never tried without FSP).
>> 4.- You need to add them yourself, there are examples to follow in this
>> mail list.
>> Good luck!
>> J.Trujillo
>>
>> ‐‐‐ Original Message ‐‐‐
>> On June 18, 2018 6:24 AM, Zvi Vered  wrote:
>>
>> Hello,
>> I inspected the "Bayley Baay FSP-based CRB" sample in coreboot. after
>> make distclean I chose:
>> Mainboard vendor: Intel
>> Mainboard model: Bayley Bay FSP-based CRB
>> 1. The size of CBFS is: 0x20. Is it a fix size or should I change it
>> according to my board (which is also bay trail) ?
>> 2. According to "dmidecode" I ran on my target, "Address: 0xE"
>> Should I set this address in coreboot configuration ? How ?
>>
>> 3. In this board default configuration, "Configure defaults for the Intel
>> FSP package" is not selected. Is it possible that this board does not use
>> Intel FSP at all ?
>> Under "Generic Drivers", "Use Intel firmware Support Package' is also not
>> selected.
>>
>> 4. Under "chipset", there is no option to set "Super I/O". Can you please
>> tell why ?
>> 5. I noticed that the minimum ROM size is 2MB. If I set 4MB, the size of
>> coreboot.rom is also 4MB.
>>
>> Thank you in advance,
>> Zvika
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] flashrom programmer

[Zvi Vered]

Hello,

How can I know what is the right flashrom programmer I should use ?

under DOS\EFI I have a vendor's utility that enables flash programming.
But it can flash to a specified address.

The vendor's programmer works without any external hardware.
When I tried: flashrom --programmer internal, I got:
--
flashrom v0.9.9-rc1-r1942 on Linux 4.13.0-36-generic (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Calibrating delay loop... OK.
WARNING: No chipset found. Flash detection will most likely fail.
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.
--
Thank you,
Zvika
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[Nico Huber]

Hi Chris,

On 25.06.2018 20:39, chrisglow...@tutanota.com wrote:
> On 25. Jun 2018 18:18 nic...@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.hu...@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
__


0xBD56B4A4138B3CE3.asc
Description: application/pgp-keys
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Porting Kabylake laptop

[chrisglowaki]

26. Jun 2018 07:44 by alexfein...@hotmail.com :

>
> 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/variants/rvp3/include/variant/gpio.h
>  
> 
>
>
> 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
>

Hi Alex,
I mentioned dumping the ACPI code to ask if I can use it in the .asl files in 
mainboard directory (for example 
https://github.com/coreboot/coreboot/blob/master/src/mainboard/purism/librem_skl/acpi/ec.asl
 
).
 Dumping data for gpio.h I guess is hard because inteltool doesn't support 
Kabylake and I have no schematics. Nico said I can try booting without the GPIO 
config, but I don't know if the laptop will be usable without it.
Thanks,
Chris

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot