The code misses the cases when a response was received but the command
failed. This patch fixes the problem.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=none
Change-Id: I3d50a4b67e3592bb80d2524a7c7f264fddbd34ae
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 8f4d6185e13beead7156027e1cb40f7944e46569
Original-Change-Id: I914ab6509d3ab2082152652205802201a6637fcc
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358096
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15637
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
tlcl_force_clear() needs to be issued each time when the device mode
switches between normal/development/recovery.
This patch adds command implementation using TPM_Clear TPM2 command,
and also invokes it before factory initialization.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM_Clear command succeeds at factory startup and
the boot proceeds normally.
Change-Id: Ia431390870cbe448bc1b6f1755ed17953be9bdf1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 347ff17b97da45fa4df547ff32f9dd2c8972cefd
Original-Change-Id: I2a0e62527ad46f9dd060afe5e75c7e4d56752849
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358095
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15636
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The TPM2 specification allows defining NV ram spaces in a manner
that makes it impossible to remove the space until a certain PCR is in
a certain state.
This comes in handy when defining spaces for rollback counters: make
their removal depend on PCR0 being in the default state. Then extend
PCR0 to any value. This guarantees that the spaces can not be deleted.
Also, there is no need t create firmware and kernel rollback spaces
with different privileges: they both can be created with the same set of
properties, the firmware space could be locked by the RO firmware, and
the kernel space could be locked by the RW firmware thus providing
necessary privilege levels.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:55063
TEST=with the rest of the patches applied it is possible to boot into
Chrome OS maintaining two rollback counter spaces in the TPM NV
ram locked at different phases of the boot process.
Change-Id: I889b2c4c4831ae01c093f33c09b4d98a11d758da
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 36317f5e85107b1b2e732a5bb2a38295120560cd
Original-Change-Id: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358094
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15635
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The command is sent in session mode, but has no parameters associated
with it.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the following patches verified that TPM_Clear command is
handled successfully by the TPM.
Change-Id: I3c9151e336084160acd3bb1f36f45b4d5efd4a33
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 503ad5e72fd5bd902325d74fd680c17c7c590e36
Original-Change-Id: Ida19e75166e1282732810cf45be21e59515d88e2
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/357973
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15634
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
For coreboot TPM2 the use case session header is always the minimal
possible size, the only difference is that some commands require one
and some require two handles.
Refactor common session header marshalling code into a separate
function. This will be useful when more commands marshalling code is
added.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=flashed the TPM and rebooted the device a few times, it
successfully loaded chrome os on every attempt.
Change-Id: I9b1697c44f67aab32b9cd556b559a55d5050be06
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: a97a7fa16ceeb484e90e2e1f0573e58a468350b2
Original-Change-Id: I86e6426be5200f28ebb2174b418254018e81da8e
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/357972
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15633
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The function is reusing some variables which confuses the reader as
the variable names do not match their second function.
This patch edits the code for readability without changing
functionality.
BRANCH=None
BUG=chrome-os-partner:50465
TEST=with the rest of the patches applied Kevin still boots into
chrome OS.
Change-Id: I396206a64403229ba3921a47b5a08748d8a4b0a3
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 3cf02c365d098c9d2ca57def7cf349ef2291d140
Original-Change-Id: I95a07945d9d2b00a69d514014f848802b82dd90f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358915
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15611
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The marshaling/unmarshaling code is using integer values to represent
room left in the buffer, to be able to communicate three conditions:
positive number means there is room left in the buffer, zero means
that the exact amount of data in the buffer was unmarshaled and
negative value means that the result of the operation did not fit into
the buffer.
The implementation is wrong though, as it compares directly signed and
unsigned values, which is illegal, as signed values get promoted to
unsigned by the compiler.
This patch changes the marshaling code to use size_t for the size, and
use zero as marshaling failure indication - after all the buffer where
the data is marshaled to should definitely be large enough, and it is
reasonable to expect at least some room left in it after marshaling.
The unmarshaling situation is different: we sure want to communicate
errors to the caller, but do not want to propagate error return values
through multiple layers. This patch keeps the size value in int, but
checks if it is negative separately, before comparing with positive
values.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied kevin successfully boots up.
Change-Id: Ibfbd1b351e35e37c8925a78d095e4e8492805bad
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: b1e862c2a650fa5f6cb25a01fe61e848a696cf17
Original-Change-Id: Ie7552b333afaff9a1234c948caf9d9a64447b2e1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358772
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15610
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some structures were included in tpm2_tlcl_structures.h that are not
needed for tpm2 commands used by coreboot. Drop them from the include
file.
BRANCH=none
BUG=none
TEST=coreboot image for gru/kevin still builds fine.
Change-Id: Id3a01f7afbddc98b4d14125452ae6a571f1b19cb
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 9375eef5a3f5ed2ba216b1cc8a4ce5c78ebe53d8
Original-Change-Id: I89b46900e5356989f2683d671552ecca5103ef90
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358093
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15608
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
TPM2 structure definitions use pointers instead of buffers where
possible. One structure was left behind. Replace that buffer definition
with a pointer to be consistent.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=compilation succeeds, the code using the changed structure in the
upcoming patches allows to successfully boot chrome OS on Kevin
Change-Id: Iea59943aa0ad6e42fcd479765a9ded0d7a1680d7
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 02b2909b1875ba65cd56cf8e3697a2b67ddaea07
Original-Change-Id: I9856ac516be13f5892ba8af0526708409a297033
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358771
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/15609
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With recent bootblock code additions the CBMEM console buffer is not
large enough to store the entire log accumulated before DRAM is
initialized, spilling 700 bytes or so on the floor.
This patch adds 1 KB to the CBMEM console buffer, at the expense of the
bootblock area in SRAM. The bootblock is taking less then 26K out of
31K allocated for it after this change.
Placing CBMEM console area right after the bootblock makes sure other
memory regions are not going to be affected should memory distribution
between bootblock and CBMEM console need to change again.
BRANCH=none
BUG=none
TEST=examining /sys/firmware/log after device boots up into Chrome OS
does not report truncated console buffer any more.
Change-Id: I016460f57c70dab4d603d4c5dbfc5ffbc6c3554f
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: bfa31684a1a9be87f39143cb6c07885a7b2e4843
Original-Change-Id: I2c3d198803e6f083ddd1d8447aa377ebf85484ce
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/358125
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15607
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Gru and derivative boards use TPM2 to support Chrome OS verified boot.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=re-built Kevin firmware, verified that TPM2 support over SPI is
enabled, and that with appropriate vboot and depthcharge patches
applied the device can boot into chrome os properly verifying RW
firmware and kernel key indices.
Change-Id: Id14a51cea49517bd2cc090ba05d71385aad5b54c
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 60e229d93d7e219e261b851f654e459eb2cf4f41
Original-Change-Id: Ic6f3c15aa23e4972bf175b2629728a338c45e44c
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/354781
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://review.coreboot.org/15606
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add a few missing Kconfig defaults for derivatives of the Oak and Gru
baseboards. Also group all Kconfigs that must change for derivatives
together for easier updating.
BRANCH=None
BUG=None
TEST=None
Change-Id: I95ebb08b4f13f09f2539b451d7b96a826ddf98f8
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: ae3f13c1dc323f4c7c4a176a4f5e1285fec312ce
Original-Change-Id: I658130e88daa2d113fd722b0527cf0e7ab66c7ef
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/357922
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15605
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds the support for gpio_tier1_sci_en bit which
needs to be set before going to sleep so that when
gpio_tier1_sci_sts bit gets set platform can wake
from S3.
BUG = chrome-os-partner:53992
TEST = Platform wakes from S3 on lidopen,key press.
Tested on Amenia and Reef boards.
Change-Id: I3ba79fa53ca8817149d585fa795a8f427c128dcb
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/15612
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
FSP is currently setting a hard-coded policy for the interrupt
polarity settings. When the mainboard has already set the GPIO
settings up prior to SiliconInit being called that results
in the previous settings being dropped. Work around FSP's
default policy until FSP is fixed.
BUG=chrome-os-partner:54955
Change-Id: Ibbd8c4894d8fbce479aeb73aa775b67df15dae85
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15649
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
For APIC routed gpios, set the corresponding interrupt polarity
for the associated IRQ based on the gpio pad's invert setting.
This allows for the APIC redirection entries to match the hardware
active polarity once the double inversion takes place to meet
apollolake interrupt triggering constraints.
BUG=chrome-os-partner:54955
Change-Id: I69c395b6f861946d4774a4206cf8f5f721c6f5f4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15648
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The interrupt and timer subsystem (ITSS) sits between the APIC
and the other logic blocks. It only supports positive polarity
events, but there's a polarity inversion setting for each IRQ such
that it can pass the signal on to the APIC according to the
expected APIC redirection entry values. This support is needed
in order for the platform/board to set the expected interrupt
polarity into the APIC for gpio signals.
BUG=chrome-os-partner:54955
Change-Id: I50ea1b7c4a7601e760878af515518cc0e808c0d1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15647
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Utilize the new interrupt macros in order to specify correct
polarity of the gpio interupts. Some of the interrupts were
working by catching the opposite edge of the asserted interrupt.
BUG=chrome-os-partner:54977
Change-Id: I55bee2c4363cfdbf340a4d5b3574b34152e0069c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Utilize the new interrupt macros in order to specify correct
polarity of the gpio interupts. Some of the interrupts were
working by catching the opposite edge of the asserted interrupt.
BUG=chrome-os-partner:54977
Change-Id: Iee33c0a949be0a11147afad8a10a0caf6590ff7b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15645
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Internally, apollolake routes its interrupts as active high.
This includes SCI, SMI, and ACPI. Therefore, provide helper
macros such that the user can describe an interrupt's active
high/low polarity more easily. It helps for readability when
one is comparing gpio configuration next to APIC configuration
in different files. Additionally, the gpio APIC macros always
use a LEVEL trigger in order to let the APIC handle the
filtering of the IRQ on its own end.
BUG=chrome-os-partner:54977
Change-Id: Id8fdcd98f0920936cd2b1a687fd8fa07bce9a614
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15644
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
FSP1_0 places romstage ram stack at fixed location of
RAMTOP in low memory before returning to coreboot proper.
There is no possibility of making a complete backup of
RAMBASE..RAMTOP region and currently such backup is not
even attempted.
As a conclusion, S3 resume would always cause OS memory
corruption.
Change-Id: I5b9dd4069082e022b01b0d6a9ad5dec28a06e8b0
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15576
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
For some reason the self loader wasn't clearing segments
marked as BSS type. Other segments which weren't fully
written by the file-backed content were being cleared up
to the indicated memsize. Treat segments marked BSS
similarly by clearing their content.
Change-Id: I9296c11a89455a02e5dd18bba13d4911517c04f6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15603
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There were two successive calls to prog_set_area() which
duplicated the same logic. Remove the unnecessary redundancy.
Change-Id: I594577f8e7e78d403e7a5656f78e784e98c2c859
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15602
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The list insertion operations were open coded at each location.
Add helper functions which provide the semantics needed by
the selfboot code in a single place.
Change-Id: Ic757255e01934b499def839131c257bde9d0cc93
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15601
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I195fd3a9c7fc07c35913342d2041e1ffef110466
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15549
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The HTIF is deprecated and the newest RISC-V binutils don't know the
mtohost/mfromhost CSRs anymore.
The SBI implementation still needs to be restructured.
Change-Id: I13f01e45b714f1bd919e27b84aff8db772504b1f
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15289
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This patch sets the devicetree for gpe0_dw configuration
and also configures the GPIO lines for SCI. EC_SCI_GPI
is configured to proper value.
BUG = chrome-os-partner:53438
TEST = Toggle pch_sci_l from ec console using gpioset command
and see that the sci counter increases in /sys/firmware/acpi/interrupt
and also 9 in /proc/interrupt
Change-Id: If258bece12768edb1e612c982514ce95c756c438
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/15556
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch sets the devicetree for gpe0_dw configuration
and also configures the GPIO lines for SCI. EC_SCI_GPI
is configured to proper value.
BUG = chrome-os-partner:53438
TEST = Toggle pch_sci_l from ec console using gpioset command
and see that the sci counter increases in /sys/firmware/acpi/interrupt
and also 9 in /proc/interrupt
Change-Id: I3ae9ef7c6a3c8688bcb6cb4c73f5618e7cde342c
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/15325
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds the handler to enable bit for gpio_tier1_sci_en.
gpio_tier1_sci_en enables the setting of the GPIO_TIER1_SCI_STS
bit to generate a wake event and/or an SCI or SMI#. We are setting
the bit for gpio_tier1_sci_en from the ASL code as OS clears this bit
if set from BIOS. As per ACPI spec _GPE is defined as the Named
Object that evaluates to either an integer or a package. If _GPE
evaluates to an integer, the value is the bit assignment of the SCI
interrupt within the GPEx_STS register of a GPE block described in
the FADT that the embedded controller will trigger. FADT right now
has no mechanism to acheive the same.
Change-Id: I1e1bd3f5c89a5e6bea2d1858569a9d30e6da78fe
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/15578
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As reported by Andrew Engelbrecht on the coreboot mailing list, there
was an issue when selecting the pxe rom file:
When using "make menuconfig", if "add pxe rom" is selected, then
the field below to set to the path of the pxe rom, the "add pxe rom"
option gets disabled.
This problem seems to be due to the use of the 'optional' Kconfig
keyword, so this section of the Kconfig is rewitten here to remove that
keyword and fix the issue.
Change-Id: I51680cb746160cb853c8679ac64e2d37989cb574
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15555
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
olddefconfig is used to expand the miniconfig files with all the default
values removed by the 'savedefconfig' target.
Change-Id: Ic9c62f4c334919e8be478d30099819b90891670a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/15319
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Properly obtain the top of memory address from the hardware registers
set by FSP.
TEST=Build and run on Galileo Gen2
Change-Id: I7681d32112408b8358b4dad67f8d69581c7dde2e
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15594
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add host bridge register access routines and macros.
TEST=Build and run on Galileo Gen2
Change-Id: I52eb6a68e99533fbb69c0ae1e6d581e4c4fab9d2
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15593
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
CAS latency = 2 support added for DDR2.
Change-Id: I08d72a61c27ff0eab19e500a2f547a5e946de2f0
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15439
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The pull bias settings for GPIO0_A, GPIO0_B, GPIO2_C and GPIO2_D
are different from the other GPIO banks.
This patch adds a callback function to get the GPIO pull value
of each SoC(rk3288 and rk3399) so we can still use the common
GPIO driver.
BRANCH=none
BUG=chrome-os-partner:53251
TEST=Jerry and Gru still boot
Change-Id: I2a00b7ffd2699190582f5f50a1e21b61c500bf4f
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 46d5fa7297693216a2da9bcf15ccce4af796e80e
Original-Change-Id: If53f47181bdc235a1ccfefeeb2a77e0eb0e3b1ca
Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/358110
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15587
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
- Update so that the RAM id is read from ADC instead of
hard-coded from the config array.
- Update the boardid readings so that they are bucketed instead
of within an error margin.
BRANCH=None
BUG=chrome-os-partner:54566,chrome-os-partner:53988
TEST=hexdump /proc/device-tree/firmware/coreboot/ram-code
and boardid when OS boots up. Also verified that
voltage read in debug output returns correct id.
Change-Id: I963406d8c440cd90c3024c814c0de61d35ebe2fd
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 068705a38734d2604f71c8a7b5bf2cc15b0f7045
Original-Change-Id: I1c847558d54a0f7f9427904eeda853074ebb0e2e
Original-Signed-off-by: Shelley Chen <shchen@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356584
Original-Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/15586
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Enable CONFIG_EC_SOFTWARE_SYNC. Crossystem needs this to get ec RW/RO
info.
BUG=chrome-os-partner:54566
BRANCH=None
TEST=1. apreset from ec console. Check for
"VbEcSoftwareSync() check for RW update"
string in ap console.
2. Run "ectool version" from OS to check
that RO/RW version are different and
that we're in RW:
RO version: kevin_v1.1.4818-8243672
RW version: kevin_v1.1.4762-1957187
Firmware copy: RW
3. Run crossystem ecfw_act. check for
RW return value.
Change-Id: If6524f2cca4a6223ab9704d0af827e8c1072670f
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 0deb0e1c69d6bf21acf7640bf76f9196e14437d7
Original-Change-Id: I0db8235cf7d472f0aa642eea1998282d010d3433
Original-Signed-off-by: Shelley Chen <shchen@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/357811
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15584
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
coreboot boots from the little core, and doesn't use the big core for
now, but if apll_b is set to the default 24MHz, it will take a long time
to enable the big core. This will cause a watchdog crash, so apll_b
initialization to 600MHz needs to be done in coreboot.
BRANCH=none
BUG=chrome-os-partner:54817
TEST=Pick CL:353762 and see big CPU clocks look right
TEST=Boot from Gru and see no cpufreq warnings
Change-Id: Ie45cd2271555942e4321e9a9e523dc10f63d8107
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id:
Original-Change-Id: I20b8b591db3171e27740d85edce11f9e8797d849
Original-Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Original-Commit-Id: 16bc916174042620bebe19ae73d241002491aecc
Original-Original-Change-Id: Id3487138b383b6643ba7e3ce1eae501a6622da10
Original-Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Original-Reviewed-on: https://chromium-review.googlesource.com/356399
Original-Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15583
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Use the apll define instead of the apll_l define so it can be reused
when setting apll_b.
BRANCH=None
BUG=None
TEST=Boot from Gru
Change-Id: Iebc4ce3b66a86c33653292340b9855265ac4fc07
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: eb578110d19a35ef04f8749fdc202055abd50fd1
Original-Change-Id: I63966e98af48eaf49837eb0b781eea001a376ef4
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/356398
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/15582
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This patch adds a TPM2 specific path in the vboot2 initialization
sequence when the device is turned on in the factory for the first
time, namely two secure NVRAM spaces are created, with different
access privileges.
The higher privilege space can be modified only be the RO firmware,
and the lower privilege space can be modified by both RO and RW
firmware.
The API is being modified to hide the TPM implementation details from
the caller.
Some functions previously exported as global are in fact not used
anywhere else, they are being defined static.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=when this code is enabled the two secure spaces are successfully
created during factory initialization.
Original-Commit-Id: 5f082d6a9b095c3efc283b7a49eac9b4f2bcb6ec
Original-Change-Id: I917b2f74dfdbd214d7f651ce3d4b80f4a18def20
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353916
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
squashed:
mock tpm: drop unused functions
safe_write() and safe_define_space() functions are defined in
secdata_mock.c, but not used in mocked TPM mode.
The actual functions have been redefined as static recently and their
declarations were removed from src/include/antirollback.h, which now
causes compilation problems when CONFIG_VBOOT2_MOCK_SECDATA is
defined.
Dropping the functions from secdata_mock.c solves the problem.
BRANCH=none
BUG=none
TEST=compilation in mock secdata mode does not fail any more.
Original-Commit-Id: c6d7824f52534ecd3b02172cb9078f03e318cb2b
Original-Change-Id: Ia781ce99630d759469d2bded40952ed21830e611
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356291
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Icb686c5f9129067eb4bb3ea10bbb85a075b29955
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15571
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Currently aclkm pclkdbg atclk clocks use apll_l as a parent, but the
apll_l frequency may change in firmware, so we need to caculate the div
value based on the apll_l frequency.
BRANCH=None
BUG=chrome-os-partner:54376
TEST=Boot from Gru
Change-Id: I2bd8886168453ce98efec58b5490c2430762769b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 116ae863a504630e2aff056564836d84198fcae2
Original-Change-Id: I7e3a5d9e3f608ddf15592d893117c92767fcd015
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356397
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15581
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Cleans up the comments in sdram.c to make them consistent.
BRANCH=none
BUG=none
TEST=make sure gru/kevin build and boot
also, run "stressapptest -M 1024 -s 3600" to make sure it passes
Change-Id: I1daf72b847374d549389bacd2fa0a9f8f231b190
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 63a224d6f4b0e4d13bc372c05c4b9196895d553f
Original-Change-Id: Iaf8a32cfe2b22c4ccff71952f90d162ad8c2d3e7
Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/355665
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15579
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Some devices allow to retrieve firmware version by reading the same 4
byte register repeatedly until the entire version string is read.
Let's print out TPM firmware version when available. Just in case
something goes wrong limit the version string length to 200 bytes.
CQ-DEPEND=CL:355701
BRANCH=none
BUG=chrome-os-partner:54723
TEST=built the new firmware and ran it on Gru, observed the following
in the coreboot console log:
Connected to device vid:did:rid of 1ae0:0028:00
Firmware version: cr50_v1.1.4792-7a44484
Original-Commit-Id: 1f54a30cebe808abf1b09478b47924bb722a0ca6
Original-Change-Id: Idb069dabb80d34a0efdf04c3c40a42ab0c8a3f94
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/355704
Original-Reviewed-by: Scott Collyer <scollyer@chromium.org>
Squashed with:
tpm: use 4 byte quantities when retrieving firmware version
The CR50 device is capable of reporting its firmware version in 4 byte
quantities, but the recently introduced code retrieves the version one
byte at a time.
With this fix the version is retrieved in 4 byte chunks.
BRANCH=none
BUG=none
TEST=the version is still reported properly, as reported by the AP
firmware console log:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: cr50_v1.1.4804-c64cf24
localhost ~ #
Original-Commit-Id: 3111537e7b66d8507b6608ef665e4cde76403818
Original-Change-Id: I04116881a30001e35e989e51ec1567263f9149a6
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/356542
Original-Reviewed-by: Andrey Pronin <apronin@chromium.org>
Change-Id: Ia9f13a5bf1c34292b866f57c0d14470fe6ca9853
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15573
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reusing the LED patterns as it was defined for Storm/WW/Platform.
BUG=b:29051518
TEST=After about 3 seconds of powering on the device different colors
should be seen at the LED ring, depending on the state of the device.
Alternatively, move the device to different states manually by
appropriate actions (like dev mode, rec mode etc) and observe the
colors.
BRANCH=None
Change-Id: I6f1b23fee15747a402e209a2d06f8794bbc2c5a1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: be1194b095d9a5cf269710c43a27a5afb3e87b29
Original-Change-Id: Ie82d4e148025c0040cdb26f53f028d9b4cbe2332
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/355200
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Suresh Rajashekara <sureshraj@chromium.org>
Reviewed-on: https://review.coreboot.org/15572
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
TPM commands need to be serialized (marshaled) to be sent to the
device, and the responses need to be de-serialized (unmarshaled) to be
properly interpreted by upper layers.
This layer does not exist in TPM1.2 coreboot implementation, all TPM
commands used there were hardcoded as binary arrays. Availability of
the marshaling/unmarshaling layer makes it much easier to add new TPM
commands to the code.
Command and response structures used in these functions are defined in
Parts 2 and 3 of the TCG issued document
Trusted Platform Module Library
Family "2.0"
Level 00 Revision 01.16
October 30, 2014
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied it is possible to
successfully initialize firmware and kernel TPM spaces.
Change-Id: I80b3f971e347bb30ea08f820ec3dd27e1656c060
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 0782d9d452efb732e85d1503fccfcb4bf9f69a68
Original-Change-Id: I202276ef9a43c28b5f304f901ac5b91048878b76
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353915
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Reviewed-on: https://review.coreboot.org/15570
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
This is the first approximation of implementing TPM2 support in
coreboot. It is very clearly incomplete, some of the larger missing
pieces being:
- PCR(s) modification
- protection NVRAM spaces from unauthorized deletion/modification.
- resume handling
- cr50 specific factory initialization
The existing TPM1.2 firmware API is being implemented for TPM2. Some
functions are not required at all, some do not map fully, but the API
is not yet being changed, many functions are just stubs.
An addition to the API is the new tlcl_define_space() function. It
abstracts TMP internals allowing the caller to specify the privilege
level of the space to be defined. Two privilege levels are defined,
higher for the RO firmware and lower for RW firmware, they determine
who can write into the spaces.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied Kevin/Gru devices can
initialize and use firmware and kernel spaces
Change-Id: Ife3301cf161ce38d61f11e4b60f1b43cab9a4eba
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: bcc8e62604c705798ca106e7995a0960b92b3f35
Original-Change-Id: Ib340fa8e7db51c10e5080973c16a19b0ebbb61e6
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353914
Original-Commit-Ready: Martin Roth <martinroth@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15569
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The "PC Client Protection Profile for TPM 2.0" document defines SPI
bus addresses for different localities. That definition is not honored
in the cr50 implementation, this patch fixes it: locality zero
register file is based off 0xd40000.
BRANCH=none
BUG=chrome-os-partner:54720
TEST=with the fixed cr50 image and the rest of TPM2 initialization
patches applied factory initialization sequence on Gru succeeds.
Change-Id: I49b7ed55f0360448b9a6602ebd31a3a531608da3
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 43344fff5d58ec235e50030413fc38c98dd0a9a1
Original-Change-Id: I2de6fa6c05d3eca989d6785228d5adde1f2a7ab7
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/355620
Original-Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://review.coreboot.org/15568
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
If CAR migration operations unintentionally set the lock,
BSP would have got stuck on printk() calls above already.
Change-Id: I35155ebcb00475a0964fc639ee74ad2755127740
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15589
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Vadim Bendebury