coreboot-gerrit May 2017

coreboot-gerrit@coreboot.org

1 participants
3888 discussions

Change in coreboot[master]: Documentation/Intel: Add vboot documentation
by Lee Leahy (Code Review) 03 May '17

03 May '17

Lee Leahy has uploaded a new change for review. ( https://review.coreboot.org/19534 ) Change subject: Documentation/Intel: Add vboot documentation ...................................................................... Documentation/Intel: Add vboot documentation Add documentation which describes how to build and sign a coreboot image which enables vboot. TEST=None Change-Id: Ie17b8443772f596de0c9d8afe6f4ec3ac4d4fef8 Signed-off-by: Lee Leahy <Leroy.P.Leahy(a)intel.com> --- M Documentation/Intel/index.html A Documentation/Intel/vboot.html 2 files changed, 374 insertions(+), 0 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/34/19534/1 diff --git a/Documentation/Intel/index.html b/Documentation/Intel/index.html index 6aaf1be..b2e826d 100644 --- a/Documentation/Intel/index.html +++ b/Documentation/Intel/index.html @@ -29,6 +29,7 @@ </li> <li><a target="_blank" href="SoC/soc.html">SoC</a> support</li> <li><a target="_blank" href="Board/board.html">Board</a> support</li> + <li><a target="_blank" href="vboot.html">Verified Boot (vboot)</a> support</li> </ul> diff --git a/Documentation/Intel/vboot.html b/Documentation/Intel/vboot.html new file mode 100644 index 0000000..1148028 --- /dev/null +++ b/Documentation/Intel/vboot.html @@ -0,0 +1,373 @@ +<!DOCTYPE html> +<html> + <head> + <title>vboot - Verified Boot Support</title> + </head> + <body> + +<h1>vboot - Verified Boot Support</h1> + +<p> +Google's verified boot support consists of: +</p> +<ul> + <li>A root of trust</li> + <li>Special firmware layout</li> + <li>Firmware verification</li> + <li>Firmware measurements</li> + <li>A firmware update mechanism</li> + <li>Specific build flags</li> + <li>Signing the coreboot image</li> +</ul> + +Google's vboot verifies the firmware verification and places measurements +within the TPM. + +<hr> +<h1>Root of Trust</h1> +<p> +When using vboot, the root-of-trust is basically the read-only portion of the +SPI flash. The following items factor into the trust equation: +</p> +<ul> + <li>The GCC compiler must reliably translate the code into machine code + without inserting any additional code (virus, backdoor, etc.) + </li> + <li>The CPU must reliably execute the reset sequence and instructions as + documented by the CPU manufacture. + </li> + <li>The SPI flash must provide only the code programmed into it to the CPU + without providing any alternative reset vector or code sequence. + </li> + <li>The SPI flash must honor the write-protect input and protect the + specified portion of the SPI flash from all erase and write accesses. + </li> +</ul> + +<p> +The firmware is typically protected using the write-protect pin on the SPI +flash part and setting some of the write-protect bits in the status register +during manufacturing. The protected area is typically 1/4th of the SPI flash +part size. Because this portion of the SPI flash is hardware write protected, +it is not possible to update this portion of the SPI flash in the field, +without altering the system to eliminate the ground connection to the SPI flash +write-protect pin. Without hardware modifications, this portion of the SPI +flash maintains the manufactured state during the system's lifetime. +</p> + +<hr> +<h1>Firmware Layout</h1> +<p> +Several sections are added to the firmware layout to support vboot: +</p> +<ul> + <li>Read-only section</li> + <li>Google Binary Blob (GBB) area</li> + <li>Read/write section A</li> + <li>Read/write section B</li> +</ul> +<p> +These following sections describe the various portions of the flash layout. +</p> + +<h2>Read-Only Section</h2> +<p> +The read-only section contains a coreboot file system (CBFS) that contains all +of the boot firmware necessary to perform recovery for the system. This +firmware is typically protected using the write-protect pin on the SPI flash +part and setting some of the write-protect bits in the status register during +manufacturing. The protected area is typically 1/4th of the SPI flash part +size and must cover the entire read-only section which consists of: +</p> +<ul> + <li>Vital Product Data (VPD) area</li> + <li>Firmware ID area</li> + <li>Google Binary Blob (GBB) area</li> + <li>coreboot file system containing read-only recovery firmware</li> +</ul> + +<h2>Google Binary Blob (GBB) Area</h2> +<p> +The GBB area is part of the read-only section. This area contains a 4096 or +8192 bit public root key that is used to verify the VBLOCK area to obtain the +firmware signing key. +</p> + +<h2>Recovery Firmware</h2> +<p> +The recovery firmware is contained within a coreboot file system and consists +of: +</p> +<ul> + <li>reset vector</li> + <li>bootblock</li> + <li>verstage</li> + <li>romstage</li> + <li>postcar</li> + <li>ramstage</li> + <li>payload</li> + <li>flash map file</li> + <li>config file</li> + <li>processor specific files: + <ul> + <li>Microcode</li> + <li>fspm.bin</li> + <li>fsps.bin</li> + </ul> + </li> +</ul> + +<p> +The recovery firmware is written during manufacturing and typically contains +code to write the storage device (eMMC device or hard disk). The recovery +image is usually contained on a socketed device such as a USB flash drive or +an SD card. Depending upon the payload firmware doing the recovery, it may +be possible for the user to interact with the system to specify the recovery +image path. Part of the recovery is also to write the A and B areas of the +SPI flash device to boot the system. +</p> + + +<h2>Read/Write Section</h2> + +<p> +The read/write sections contain a an area which contains the firmware signing +key and signature and an area containing a coreboot file system with a subset +of the firmware. The firmware files in FW_MAIN_A and FW_MAIN_B are: +</p> +<ul> + <li>romstage</li> + <li>postcar</li> + <li>ramstage</li> + <li>payload</li> + <li>config file</li> + <li>processor specific files: + <ul> + <li>Microcode</li> + <li>fspm.bin</li> + <li>fsps.bin</li> + </ul> + </li> +</ul> + +<p> +The firmware subset enables most issues to be fixed in the field with firmware +updates. The firmware files handle memory and most of silicon initialization. +These files also produce the tables which get passed to the operating system. +</p> + +<hr> +<h1>Firmware Updates</h1> +<p> +The read/write sections exist in one of three states: +</p> +<ul> + <li>Invalid</li> + <li>Ready to boot</li> + <li>Successfully booted</li> +</ul> + +<table border="1"> +<tr bgcolor="#ffc0c0"> +<td> +Where is this state information written? +<br/>CMOS? +<br/>RW_NVRAM? +<br/>RW_FWID_* +</td> +</tr> +</table> + +<p> +Firmware updates are handled by the operating system by writing any read/write +section that is not in the "successfully booted" state. Upon the next reboot, +vboot determines the section to boot. If it finds one in the "ready to boot" +state then it attempts to boot using that section. If the boot fails then +vboot marks the section as invalid and attempts to fall back to a read/write +section in the "successfully booted" state. If vboot is not able to find a +section in the "successfully booted" state then vboot enters recovery mode. +</p> + +<p> +Only the operating system is able to transition a section from the "ready to +boot" state to the "successfully booted" state. The transition is typically +done after after the operating system has been running for a while indicating +that successful boot was possible and the operating system is stable. +</p> + +<p> +Note that as long as the SPI write protection is in place then the system is +always recoverable. If the flash update fails then the system will continue +to boot using the previous read/write area. The same is true if coreboot +passes control to the payload or the operating system and then the boot fails. +In the worst case, the SPI flash gets totally corrupted in which case vboot +fails the signature checks and enters recovery mode. There are no times where +the SPI flash is exposed and the reset vector or part of the recovery firmware +gets corrupted. +</p> + +<hr> +<h1>Build Flags</h1> +<p> +The following Kconfig values need to be selected to enable vboot: +</p> +<ul> + <li>COLLECT_TIMESTAMPS</li> + <li>VBOOT</li> +</ul> + +<p> +The starting stage needs to be specified by selecting either +VBOOT_STARTS_IN_BOOTBLOCK or VBOOT_STARTS_IN_ROMSTAGE. +</p> + +<p> +If vboot starts in bootblock then vboot may be built as a separate stage by +selecting VBOOT_SEPARATE_VERSTAGE. Additionally, if RAM is too small to fit +both verstage and romstage then selecting VBOOT_RETURN_FROM_VERSTAGE enables +bootblock to reuse the RAM occupied by verstage for romstage. +</p> + +<p> +Non-volatile flash is needed for vboot operation. This flash area may be in +CMOS, the EC, or in a read/write area of the SPI flash device. Select one of +the following: +</p> +<ul> + <li>VBOOT_VBNV_CMOS</li> + <li>VBOOT_VBNV_EC</li> + <li>VBOOT_VBNV_FLASH</li> +</ul> +<p> +More non-volatile storage features may be found in src/vboot/Kconfig. +</p> + +<p> +A TPM is also required for vboot operation. TPMs are available in +drivers/i2c/tpm and drivers/pc80/tpm. +</p> + +<p> +Enabling vboot causes coreboot to be built several times, once for each of the +read-only section, the read/write A section and the read/write B section. +</p> + +<hr> +<h1>Signing the coreboot Image</h1> +<p> +The follow command script is an example of how to sign the coreboot image file. +This script is used on the Intel Galileo board and creates the GBB area and +inserts it into the coreboot image. It also updates the VBLOCK areas with the +firmware signing key and the signature for the FW_MAIN firmware. More details +are available in 3rdparty/vboot/README. +</p> + +<pre><code>#!/bin/sh +# +# The necessary tools were built and installed using the following commands: +# +# pushd 3rdparty/vboot +# make +# sudo make install +# popd +# +# The keys were made using the following command +# +# 3rdparty/vboot/scripts/keygeneration/create_new_keys.sh \ +# --4k --4k-root --output $PWD/keys +# +# +# Create the GBB area blob +# +gbb_utility -c 0x100,0x1000,0x7ce80,0x1000 gbb.blob + +# +# Add the empty GBB to the coreboot.rom image +# +dd conv=fdatasync ibs=4096 obs=4096 count=1553 \ +if=build/coreboot.rom of=build/coreboot.signed.rom + +dd conv=fdatasync obs=4096 obs=4096 seek=1553 if=gbb.blob \ +of=build/coreboot.signed.rom + +dd conv=fdatasync ibs=4096 obs=4096 skip=1680 seek=1680 count=368 \ +if=build/coreboot.rom of=build/coreboot.signed.rom + +# +# Add the keys and HWID to the GBB +# +gbb_utility \ +--set --hwid='Galileo' \ +-r $PWD/keys/recovery_key.vbpubk \ +-k $PWD/keys/root_key.vbpubk \ +build/coreboot.signed.rom + +# +# Sign the firmware with the keys +# +3rdparty/vboot/scripts/image_signing/sign_firmware.sh \ +build/coreboot.signed.rom \ +$PWD/keys \ +build/coreboot.signed.rom +</code></pre> + +<hr> +<h1>Boot Flow</h1> +<p> +The reset vector exist in the read-only area and points to the bootblock entry +point. The only copy of the bootblock exists in the read-only area of the SPI +flash. Verstage may be part of the bootblock or a separate stage. If separate +then the bootblock loads verstage from the read-only area and transfers control +to it. +</p> + +<p> +Upon first boot, verstage attempts to verify the read/write section A. It gets +the public root key from the GBB area and uses that to verify the VBLOCK area +in read-write section A. If the VBLOCK area is valid then it extracts the +firmware signing key (1024-8192 bits) and uses that to verify the FW_MAIN_A +area of read/write section A. If the verification is successful then verstage +instructs coreboot to use the coreboot file system in read/write section A for +the contents of the remaining boot firmware (romstage, postcar, ramstage and +the payload). +</p> + +<p> +If verification fails for the read/write area and the other read/write area is +not valid vboot falls back to the read-only area to boot into system recovery. +</p> + +<hr> +<h1>Chromebook Special Features</h1> +<p> +Google's Chromebooks have some special features: +</p> +<ul> + <li>Developer mode</li> + <li>Write-protect screw</li> +</ul> + +<h2>Developer Mode</h2> +<p> +Developer mode allow the user to use coreboot to boot another operating system. +This may be a another (beta) version of ChromeOS, or another flavor of Linux. +Use of developer mode does not void the Chromebook warranty. Upon entry into +developer mode, all locally saved data on the Chromebook is lost. This +prevents someone from entering developer mode to subvert the system security to +access files on the local system or cloud. +</p> + +<h2>Write Protect Screw</h2> +<p> +Early Chromebooks have a write-protect screw which provides the ground to the +write-protect pin of the SPI flash. Google specifically did this to allow +the manufacturing line and advanced developers to re-write the entire SPI flash +part. Once the screw is removed, any firmware may be placed on the device. +However, accessing this screw requires opening the case and voids the system +warranty! +</p> + +<hr> +<p>Modified: 2 May 2017</p> + </body> +</html> -- To view, visit https://review.coreboot.org/19534 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ie17b8443772f596de0c9d8afe6f4ec3ac4d4fef8 Gerrit-PatchSet: 1 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Lee Leahy <leroy.p.leahy(a)intel.com>

1 0

Change in coreboot[master]: mb/gigabyte/ga-b75m-d3h: add libgfxinit support
by Anonymous Coward (Code Review) 03 May '17

03 May '17

Anonymous Coward #1001586 has posted comments on this change. ( https://review.coreboot.org/19522 ) Change subject: mb/gigabyte/ga-b75m-d3h: add libgfxinit support ...................................................................... Patch Set 3: (1 comment) https://review.coreboot.org/#/c/19522/3/src/mainboard/gigabyte/ga-b75m-d3h/… File src/mainboard/gigabyte/ga-b75m-d3h/gma-mainboard.ads: PS3, Line 10: (DP1, : DP2, > According to Gigabyte web page there is no DisplayPort? Yes, there is no displayport socket on the board, but the info about ports within this list is what xrandr(1) reports, so it seems that the DVI and HDMI ports on the board are bridged from DP++ ports -- To view, visit https://review.coreboot.org/19522 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: If00a7247df0c32b3d1f489fb92d86baaa8fdf8ba Gerrit-PatchSet: 3 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Anonymous Coward #1001586 Gerrit-Reviewer: Anonymous Coward #1001586 Gerrit-Reviewer: Arthur Heymans <arthur(a)aheymans.xyz> Gerrit-Reviewer: Nico Huber <nico.h(a)gmx.de> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-HasComments: Yes

1 0

Change in coreboot[master]: google/fizz: Enable devices under pci 1c.0
by build bot (Jenkins) (Code Review) 03 May '17

03 May '17

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/19533 ) Change subject: google/fizz: Enable devices under pci 1c.0 ...................................................................... Patch Set 1: Verified+1 Build Successful https://qa.coreboot.org/job/coreboot-gerrit/53096/ : SUCCESS https://qa.coreboot.org/job/coreboot-checkpatch/8930/ : SUCCESS -- To view, visit https://review.coreboot.org/19533 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ide66823283c58d2bea0c9886f762f0581741affe Gerrit-PatchSet: 1 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Shelley Chen <shchen(a)google.com> Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org> Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Gwendal Grignou <gwendal(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-HasComments: No

1 0

Change in coreboot[master]: google/fizz: Enable devices under pci 1c.0
by Furquan Shaikh (Code Review) 02 May '17

02 May '17

Furquan Shaikh has posted comments on this change. ( https://review.coreboot.org/19533 ) Change subject: google/fizz: Enable devices under pci 1c.0 ...................................................................... Patch Set 1: Code-Review+2 -- To view, visit https://review.coreboot.org/19533 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ide66823283c58d2bea0c9886f762f0581741affe Gerrit-PatchSet: 1 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Shelley Chen <shchen(a)google.com> Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org> Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Gwendal Grignou <gwendal(a)chromium.org> Gerrit-HasComments: No

1 0

Change in coreboot[master]: google/fizz: Enable devices under pci 1c.0
by Shelley Chen (Code Review) 02 May '17

02 May '17

Shelley Chen has uploaded a new change for review. ( https://review.coreboot.org/19533 ) Change subject: google/fizz: Enable devices under pci 1c.0 ...................................................................... google/fizz: Enable devices under pci 1c.0 Turn on device 1c.0 in order to enable devices under it. BUG=b:37486021, b:35775024 BRANCH=None TEST=Boot from NVMe Change-Id: Ide66823283c58d2bea0c9886f762f0581741affe Signed-off-by: Shelley Chen <shchen(a)chromium.org> --- M src/mainboard/google/fizz/devicetree.cb 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/33/19533/1 diff --git a/src/mainboard/google/fizz/devicetree.cb b/src/mainboard/google/fizz/devicetree.cb index e18b767..ff2ec7f 100644 --- a/src/mainboard/google/fizz/devicetree.cb +++ b/src/mainboard/google/fizz/devicetree.cb @@ -228,7 +228,7 @@ device pci 19.1 on end # I2C #5 device pci 19.2 off end # I2C #4 - device pci 1c.0 off end # PCI Express Port 1 + device pci 1c.0 on end # PCI Express Port 1 device pci 1c.1 off end # PCI Express Port 2 device pci 1c.2 on end # PCI Express Port 3 for LAN device pci 1c.3 on -- To view, visit https://review.coreboot.org/19533 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: newchange Gerrit-Change-Id: Ide66823283c58d2bea0c9886f762f0581741affe Gerrit-PatchSet: 1 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Shelley Chen <shchen(a)google.com>

1 0

Change in coreboot[master]: google/gru: skip usbphy1 setup for Scarlet
by Julius Werner (Code Review) 02 May '17

02 May '17

Julius Werner has posted comments on this change. ( https://review.coreboot.org/19489 ) Change subject: google/gru: skip usbphy1 setup for Scarlet ...................................................................... Patch Set 4: Code-Review+2 -- To view, visit https://review.coreboot.org/19489 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I66e0d8a235cc9057964f7abca32bc692d41e88fd Gerrit-PatchSet: 4 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Philip Chen <philipchen(a)google.com> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: Philip Chen <philipchen(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-HasComments: No

1 0

Change in coreboot[master]: google/gru: skip usbphy1 setup for Scarlet
by build bot (Jenkins) (Code Review) 02 May '17

02 May '17

build bot (Jenkins) has posted comments on this change. ( https://review.coreboot.org/19489 ) Change subject: google/gru: skip usbphy1 setup for Scarlet ...................................................................... Patch Set 4: Verified+1 Build Successful https://qa.coreboot.org/job/coreboot-gerrit/53095/ : SUCCESS https://qa.coreboot.org/job/coreboot-checkpatch/8929/ : SUCCESS -- To view, visit https://review.coreboot.org/19489 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I66e0d8a235cc9057964f7abca32bc692d41e88fd Gerrit-PatchSet: 4 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Philip Chen <philipchen(a)google.com> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: Philip Chen <philipchen(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-HasComments: No

1 0

Change in coreboot[master]: google/gru: skip usbphy1 setup for Scarlet
by Philip Chen (Code Review) 02 May '17

02 May '17

Philip Chen has posted comments on this change. ( https://review.coreboot.org/19489 ) Change subject: google/gru: skip usbphy1 setup for Scarlet ...................................................................... Patch Set 3: (4 comments) https://review.coreboot.org/#/c/19489/3//COMMIT_MSG Commit Message: PS3, Line 2: philipchen > This should say "Philip Chen". Can you double-check your git config? Fixed my git config. PS3, Line 7: scarlet/gru > This would be better as "google/gru: ", probably, then you can keep the "Sc Done Line 8: > Please mention the reason for skipping the setup. Done https://review.coreboot.org/#/c/19489/3/src/mainboard/google/gru/mainboard.c File src/mainboard/google/gru/mainboard.c: PS3, Line 309: { > nit: can remove braces Done -- To view, visit https://review.coreboot.org/19489 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I66e0d8a235cc9057964f7abca32bc692d41e88fd Gerrit-PatchSet: 3 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Philip Chen <philipchen(a)google.com> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: Philip Chen <philipchen(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org> Gerrit-HasComments: Yes

1 0

Change in coreboot[master]: google/gru: skip usbphy1 setup for Scarlet
by Philip Chen (Code Review) 02 May '17

02 May '17

Hello build bot (Jenkins), I'd like you to reexamine a change. Please visit https://review.coreboot.org/19489 to look at the new patch set (#4). Change subject: google/gru: skip usbphy1 setup for Scarlet ...................................................................... google/gru: skip usbphy1 setup for Scarlet Board Scarlet doesn't use usbphy1. BUG=b:37685249 TEST=boot Scarlet, check the firmware log, and confirm no errors about USB1 Change-Id: I66e0d8a235cc9057964f7abca32bc692d41e88fd Signed-off-by: Philip Chen <philipchen(a)google.com> --- M src/mainboard/google/gru/mainboard.c M src/soc/rockchip/rk3399/include/soc/grf.h 2 files changed, 24 insertions(+), 32 deletions(-) git pull ssh://review.coreboot.org:29418/coreboot refs/changes/89/19489/4 -- To view, visit https://review.coreboot.org/19489 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I66e0d8a235cc9057964f7abca32bc692d41e88fd Gerrit-PatchSet: 4 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Philip Chen <philipchen(a)google.com> Gerrit-Reviewer: Julius Werner <jwerner(a)chromium.org> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: Philip Chen <philipchen(a)google.com> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

Change in coreboot[master]: mainboard/google/poppy: Add support for cr50 I2C TPM
by Furquan Shaikh (Code Review) 02 May '17

02 May '17

Furquan Shaikh has submitted this change and it was merged. ( https://review.coreboot.org/19518 ) Change subject: mainboard/google/poppy: Add support for cr50 I2C TPM ...................................................................... mainboard/google/poppy: Add support for cr50 I2C TPM 1. Add support for using cr50 I2C TPM on poppy. This will not be enabled until the next build. 2. Also, configure GPIOs for SPI and I2C TPM only if the corresponding Kconfig options are set. BUG=b:36265511 TEST=Verified on a reworked board that I2C TPM communication works fine. Change-Id: I3b293b8d410a6973a6dfea393c17d0be425b6a28 Signed-off-by: Furquan Shaikh <furquan(a)chromium.org> Reviewed-on: https://review.coreboot.org/19518 Tested-by: build bot (Jenkins) <no-reply(a)coreboot.org> Reviewed-by: Aaron Durbin <adurbin(a)chromium.org> --- M src/mainboard/google/poppy/Kconfig M src/mainboard/google/poppy/variants/baseboard/devicetree.cb M src/mainboard/google/poppy/variants/baseboard/gpio.c 3 files changed, 50 insertions(+), 8 deletions(-) Approvals: Aaron Durbin: Looks good to me, approved build bot (Jenkins): Verified diff --git a/src/mainboard/google/poppy/Kconfig b/src/mainboard/google/poppy/Kconfig index ce32081..58af8df 100644 --- a/src/mainboard/google/poppy/Kconfig +++ b/src/mainboard/google/poppy/Kconfig @@ -22,7 +22,16 @@ string default "variants/baseboard/devicetree.cb" +config DRIVER_TPM_I2C_BUS + depends on POPPY_USE_I2C_TPM + default 0x4 + +config DRIVER_TPM_I2C_ADDR + depends on POPPY_USE_I2C_TPM + default 0x50 + config DRIVER_TPM_SPI_BUS + depends on POPPY_USE_SPI_TPM default 0x1 config GBB_HWID @@ -56,6 +65,14 @@ int default 8 +# Select this option to enable use of cr50 I2C TPM on poppy. +config POPPY_USE_I2C_TPM + bool + default n + select I2C_TPM + select MAINBOARD_HAS_I2C_TPM_CR50 + select TPM2 + # Select this option to enable use of cr50 SPI TPM on poppy. # This option is disabled by default. config POPPY_USE_SPI_TPM @@ -64,6 +81,10 @@ select MAINBOARD_HAS_SPI_TPM_CR50 select SPI_TPM select TPM2 + +config TPM_TIS_ACPI_INTERRUPT + int + default 64 # GPE0_DW2_00 (GPP_E0) config VARIANT_DIR string @@ -75,12 +96,5 @@ select HAS_RECOVERY_MRC_CACHE select MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN select VBOOT_LID_SWITCH - -config DRIVER_TPM_SPI_BUS - default 0x1 - -config TPM_TIS_ACPI_INTERRUPT - int - default 64 # GPE0_DW2_00 (GPP_E0) endif # BOARD_GOOGLE_BASEBOARD_POPPY diff --git a/src/mainboard/google/poppy/variants/baseboard/devicetree.cb b/src/mainboard/google/poppy/variants/baseboard/devicetree.cb index d232028..4e3ffaf 100644 --- a/src/mainboard/google/poppy/variants/baseboard/devicetree.cb +++ b/src/mainboard/google/poppy/variants/baseboard/devicetree.cb @@ -154,7 +154,7 @@ register "usb3_ports[3]" = "USB3_PORT_EMPTY" # Empty register "i2c_voltage[0]" = "I2C_VOLTAGE_3V3" # Touchscreen - register "i2c_voltage[1]" = "I2C_VOLTAGE_3V3" # NFC + register "i2c_voltage[1]" = "I2C_VOLTAGE_3V3" # H1 register "i2c_voltage[2]" = "I2C_VOLTAGE_1V8" # Camera register "i2c_voltage[3]" = "I2C_VOLTAGE_1V8" # Pen register "i2c_voltage[4]" = "I2C_VOLTAGE_1V8" # Camera @@ -167,6 +167,12 @@ .early_init = 1, }" + # Configure I2C1 for cr50 TPM. Early init is required to set up a BAR + # for TPM communication before memory is up. + register "i2c[1]" = "{ + .early_init = 1, + }" + # Must leave UART0 enabled or SD/eMMC will not work as PCI register "SerialIoDevMode" = "{ [PchSerialIoIndexI2C0] = PchSerialIoPci, diff --git a/src/mainboard/google/poppy/variants/baseboard/gpio.c b/src/mainboard/google/poppy/variants/baseboard/gpio.c index fcbbb1d..2be9d0f 100644 --- a/src/mainboard/google/poppy/variants/baseboard/gpio.c +++ b/src/mainboard/google/poppy/variants/baseboard/gpio.c @@ -92,6 +92,7 @@ PAD_CFG_NF(GPP_B13, NONE, DEEP, NF1), /* B14 : SPKR ==> NC */ PAD_CFG_NC(GPP_B14), +#if IS_ENABLED(CONFIG_POPPY_USE_SPI_TPM) /* B15 : GSPI0_CS# ==> PCH_SPI_H1_3V3_CS_L */ PAD_CFG_NF(GPP_B15, NONE, DEEP, NF1), /* B16 : GSPI0_CLK ==> PCH_SPI_H1_3V3_CLK */ @@ -100,6 +101,16 @@ PAD_CFG_NF(GPP_B17, NONE, DEEP, NF1), /* B18 : GSPI0_MOSI ==> PCH_SPI_H1_3V3_MOSI */ PAD_CFG_NF(GPP_B18, NONE, DEEP, NF1), +#else + /* B15 : GSPI0_CS# ==> NC */ + PAD_CFG_NC(GPP_B15), + /* B16 : GSPI0_CLK ==> NC */ + PAD_CFG_NC(GPP_B16), + /* B17 : GSPI0_MISO ==> NC */ + PAD_CFG_NC(GPP_B17), + /* B18 : GSPI0_MOSI ==> NC */ + PAD_CFG_NC(GPP_B18), +#endif /* B19 : GSPI1_CS# ==> PCH_SPI_FP_CS_L */ PAD_CFG_NF(GPP_B19, NONE, DEEP, NF1), /* B20 : GSPI1_CLK ==> PCH_SPI_FP_CLK */ @@ -147,10 +158,17 @@ PAD_CFG_NF(GPP_C16, NONE, DEEP, NF1), /* C17 : I2C0_SCL ==> PCH_I2C0_TOUCHSCREEN_3V3_SCL */ PAD_CFG_NF(GPP_C17, NONE, DEEP, NF1), +#if IS_ENABLED(CONFIG_POPPY_USE_I2C_TPM) /* C18 : I2C1_SDA ==> PCH_I2C1_H1_3V3_SDA */ PAD_CFG_NF(GPP_C18, NONE, DEEP, NF1), /* C19 : I2C1_SCL ==> PCH_I2C1_H1_3V3_SCL */ PAD_CFG_NF(GPP_C19, NONE, DEEP, NF1), +#else + /* C18 : I2C1_SDA ==> NC */ + PAD_CFG_NC(GPP_C18), + /* C19 : I2C1_SCL ==> NC */ + PAD_CFG_NC(GPP_C19), +#endif /* C20 : UART2_RXD ==> PCHRX_SERVOTX_UART */ PAD_CFG_NF(GPP_C20, NONE, DEEP, NF1), /* C21 : UART2_TXD ==> PCHTX_SERVORX_UART */ @@ -353,6 +371,7 @@ /* Early pad configuration in bootblock */ static const struct pad_config early_gpio_table[] = { +#if IS_ENABLED(CONFIG_POPPY_USE_SPI_TPM) /* B15 : GSPI0_CS# ==> PCH_SPI_H1_3V3_CS_L */ PAD_CFG_NF(GPP_B15, NONE, DEEP, NF1), /* B16 : GSPI0_CLK ==> PCH_SPI_H1_3V3_CLK */ @@ -361,11 +380,14 @@ PAD_CFG_NF(GPP_B17, NONE, DEEP, NF1), /* B18 : GSPI0_MOSI ==> PCH_SPI_H1_3V3_MOSI */ PAD_CFG_NF(GPP_B18, NONE, DEEP, NF1), +#endif +#if IS_ENABLED(CONFIG_POPPY_USE_I2C_TPM) /* C18 : I2C1_SDA ==> PCH_I2C1_H1_3V3_SDA */ PAD_CFG_NF(GPP_C18, NONE, DEEP, NF1), /* C19 : I2C1_SCL ==> PCH_I2C1_H1_3V3_SCL */ PAD_CFG_NF(GPP_C19, NONE, DEEP, NF1), +#endif /* Ensure UART pins are in native mode for H1. */ /* C20 : UART2_RXD ==> PCHRX_SERVOTX_UART */ -- To view, visit https://review.coreboot.org/19518 To unsubscribe, visit https://review.coreboot.org/settings Gerrit-MessageType: merged Gerrit-Change-Id: I3b293b8d410a6973a6dfea393c17d0be425b6a28 Gerrit-PatchSet: 3 Gerrit-Project: coreboot Gerrit-Branch: master Gerrit-Owner: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Aaron Durbin <adurbin(a)chromium.org> Gerrit-Reviewer: Duncan Laurie <dlaurie(a)chromium.org> Gerrit-Reviewer: Furquan Shaikh <furquan(a)google.com> Gerrit-Reviewer: Paul Menzel <paulepanter(a)users.sourceforge.net> Gerrit-Reviewer: Vadim Bendebury <vbendeb(a)chromium.org> Gerrit-Reviewer: build bot (Jenkins) <no-reply(a)coreboot.org>

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

coreboot-gerrit May 2017