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>
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>
The lock stores need to migrate from CAR to CBMEM.
Change-Id: I3cffd14bdfc57d5588d0f24afe00e0f9891bfe5a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15588
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It is not possible for cbmem_add() to complete succesfully before
cbmem_recovery() is called. Adding more tables on S3 resume path
is also not possible.
Change-Id: Ic14857eeef2932562acee4a36f59c22ff4ca1a84
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15472
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In particular, update host_event the original value for MKBP was not
set in ToT.
CQ-DEPEND=CL:353634
BUG=b:27849483
BRANCH=none
TEST=Compile on Samus. Tested in Cyan branch.
Change-Id: I0184e4f0e45c3321742d3138ae0178c159cbdd0a
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: cc6750b705300f5b94bf23fe5485d6e7a5f9e327
Original-Change-Id: I60df65bfd4053207fa90b1c2a8609eec09f3c475
Original-Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/354040
Reviewed-on: https://review.coreboot.org/15567
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This is needed to ensure that the ram-code node is included in the
device tree by depthcharge.
BRANCH=none
BUG=chrome-os-partner:54566
TEST=built updated firmware, booted on kevin into Linux shell, checked
the device tree contents:
localhost ~ # od -tx1 /proc/device-tree/firmware/coreboot/ram-code
0000000 00 00 00 01
0000004
localhost #
Change-Id: Ibe96e3bc8fc0106013241738f5726783d74bd78b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 53c002114f7044b88728c9e17150cd3a2cf1f80f
Original-Change-Id: Iba573fba9f9b88b87867c6963e48215e254319ed
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/354705
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15566
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Previously, any 800MHz DIMMs were being slowed to 667MHz
for no reason other than there was a bug in the maximum
frequency detection code for the MCH.
Change-Id: Id6c6c88c4a40631f6caf52f536a939a43cb3faf1
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/15257
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Specify the memory initialization parameters in
mainboard/intel/galileo/devicetree.cb. Pass these values into FSP to
initialize memory.
TEST=Build and run on Galileo Gen2
Change-Id: I83ee196f5fb825118a3a74b61f73f3728a1a1dc6
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15260
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Switch the I2C scripts to properly match the I2C address selection for
the Galileo Gen1 board.
TEST=Build an run on Galileo Gen1
Change-Id: I9fc8b59a3a719abb474c99a83e0d538794626da9
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15258
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Remove the unused Kconfig values which specify the PDAT file, its
location and inclusion into the coreboot file system. Remove the code
in romstage which locates the pdat.bin file.
TEST=Build and run on Galileo Gen2
Change-Id: I397aa22ada6c073c60485a735d6e2cb42bfd40ab
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15205
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add the gpio_defs.h reference in chip.h to enable
reef and amenia devicetree.cb to use the definitions from gpio_defs.h.
Change-Id: I333d4e810e42309ac76dd90c19f05cf3e3a517b1
Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com>
Reviewed-on: https://review.coreboot.org/15550
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Use the device driver for DA7219 device configuration in the SSDT and
remove the static copy in the DSDT.
Tested on reef to ensure that the generated SSDT contents are
equivalent to the current DSDT contents.
Change-Id: I288eb05d0cb3f5310c4dca4aa1eab5a029f216af
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15539
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a device driver to generate the device and required properties
into the SSDT.
This driver uses the ACPI Device Property interface to generate the
required parameters into the _DSD table format expected by the kernel.
This was tested on the reef mainboard to ensure that the SSDT contained
the equivalent parameters that are provided by the current DSDT object.
Change-Id: Ia809e953932a7e127352a7ef193974d95e511565
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15538
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is a second ACPI _DSD document from the UEFI Forum that details
how _DSD style tables can be nested, creating a tree of similarly
formatted tables. This document is linked from acpi_device.h.
In order to support this the device property interface needs to be
more flexible and build up a tree of properties to write all entries
at once instead of writing each entry as it is generated.
In the end this is a more flexible solution that can support drivers
that need child tables like the DA7219 codec, while only requiring
minor changes to the existing drivers that use the device property
interface.
This was tested on reef (apollolake) and chell (skylake) boards to
ensure that there was no change in the generated SSDT AML.
Change-Id: Ia22e3a5fd3982ffa7c324bee1a8d190d49f853dd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15537
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
IRQ 9 is used for different purpose on this board so move
SCI away to IRQ10.
Change-Id: I107bfb5ec8cd05f844ee75550779be7746e77a88
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15563
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Based on the board revision apply the correct GPIO changes.
The only differences are the addition of 2 peripheral wake signals
and a dedicated peripheral reset line.
BUG=chrome-os-partner:54959,chrome-os-partner:54960,chrome-os-partner:54961
BRANCH=None
TEST=Built and tested on reef.
Change-Id: I9cac82158e70e0af1b454ec4581c2e4622b95b4b
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://review.coreboot.org/15562
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The board build version is provided by the EC on reef.
Provide the necessary functional support for coreboot
to differentiate the board versions.
BUG=chrome-os-partner:54959,chrome-os-partner:54960,chrome-os-partner:54961
BRANCH=None
TEST=Built and tested on reef.
Change-Id: I1b7e8b2f4142753cde736148ca9495bcc625f318
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://review.coreboot.org/15561
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
While the proto boards didn't have a memory SKU notion the
EVT boards do. Therefore, provide support for selecting the
proper memory SKU information based on the memory id straps.
This works on EVT boards because the pins used for the
strapping weren't used on proto. However, internal pullups
need to be enabled so that proto boards read the correct
id.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
Change-Id: I8653260e5d1b9adc83b78ea2770c683b72535e11
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://review.coreboot.org/15560
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Instead of having all the mainboards put similar logic
into their own code provide common mechanism for memory
SKU selection. A function, meminit_lpddr4_by_sku(), is
added that selects the proper configuration based on the
SKU id and configuration passed in. LPDDR4 speed as well
as DRAM device density configuration is associated for
each logical channel per SKU id.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
Change-Id: Ifc6a734040bb61a58bc3d4c128a6420a71245c6c
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://review.coreboot.org/15559
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The internal pulls for gpio_input_pullup() and gpio_input_pulldown()
were using fairly strong pulls. Weaken them so that external pulls
can override the internal ones. This matches the current assumptions
of lib/gpio.c.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
Change-Id: Ifda1d04d40141325f78db277eb0bd55574994abf
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://review.coreboot.org/15558
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>
Provide common implementations for gpio_base2_value() variants
which configure the gpio for internal pullups and pulldowns.
BUG=chrome-os-partner:54949
BRANCH=None
TEST=Built and used on reef for memory config.
Change-Id: I9be8813328e99d28eb4145501450caab25d51f37
Signed-off-by: Aaron Durbin <adurbin@chromuim.org>
Reviewed-on: https://review.coreboot.org/15557
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Have acpigen_write_package() return a pointer to the package element
counter so it can be used for dynamic package generation where needed.
Change-Id: Id7f6dd03511069211ba3ee3eb29a6ca1742de847
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15536
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The name must not terminated with a newline character `\n` as it would
make it hard to use it strings. So, remove the newline from the two SoCs
with it.
Change-Id: I7570442b38a455e7c497d7f461c208fb0a88296d
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/15540
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
A call to early_mainboard_init is already present in verstage, thus it
is only necessary to call it from romstage when not in vboot context.
Change-Id: I2e0b5a369c5fb24efae4ac40d83a31f5cf4a078d
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15450
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This includes the proper Kconfig options (based on the chromium os
coreboot configuration) for setting up verstage on tegra124 devices.
Change-Id: I4a1976ff684a417cae6fa718ef53cad763cee47d
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15451
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Since SPI controller opcode registers are locked by FSP, they need to be
initialized to a known good state before ReadyToBoot event and after
every SPI flash access (e.g. for MRC cache) has been finished in order
to enable the OS to use SPI controller without constraints.
Change-Id: I0a66344cd44e036c3999ae98d539072299cf5112
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15547
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The SCI interrupt can be routed to different IRQs using ACPI control
register. Instead of using hard coded IRQ9 for ACPI table generation
read back the register and return the used IRQ number. This way SCI IRQ
can be modified (e.g. for a given mainboard) and ACPI tables will
remain consistent.
Change-Id: I534fc69eb1df28cd8d733d1ac6b2081d2dcf7511
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15548
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: York Yang <york.yang@intel.com>
Add driver code to initialize Siemens NC FPGA as PCI device.
Beside some glue logic it contains a FAN controller and
temperature monitor.
Change-Id: I2cb722a60081028ee5a8251f51125f12ed38d824
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15543
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
There are several different macros available to convert a PCI device and
function to a single 8 bit value. One is PCI_DEVFN and is defined in
device/pci_def.h. The other is DEV_FUNC and is defined in several intel
fsp based chipset implementations. In fsp_broadwell_de DEV_FUNC is even
used without being defined at all. This patch unifies the situation so
that only PCI_DEVFN is used.
Change-Id: Ia1c6d7f3683badc66d15053846936d88aa836632
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15546
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Enable the usage of DRIVER_INTEL_I210 and provide a function to search
for a valid MAC address for all i210 devices using hwilib.
Change-Id: Ic0f4f1579364cf5b0111334a05a8a0926785318b
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15517
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The function mainboard_get_mac_address() is used to get a MAC address
for a given i210 PCI device. Instead of passing pure numbers for PCI
bus, device and function pass the device pointer to this function. In
this way the function can retrieve the needed values itself as well as
have the pointer to the device tree so that PCI path can be evaluated
there.
Change-Id: I2335d995651baa5e23a0448f5f32310dcd394f9b
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15516
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This patch adds the basic framework for SCI to GPE routing code.
BUG = chrome-os-partner:53438
TEST = Toogle 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/interrupts.
Change-Id: I3b3198276530bf6513d94e9bea02ab9751212adf
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/15324
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
On Apollolake CSE can be used to fetch firmware from boot media. However,
when this feature is not used, CSE needs to be explicitly notified of it
before memory training is complete. This way it can transition to next
state.
BUG=chrome-os-partner:53876
TEST=CSE can be power-gated during S0iX. Confirmed with LTB.
Change-Id: I5141bff350b6c0bb662424b7b709f0787ec5fd28
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15494
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add the Audio DSP device for apollolake as a PCI driver with a static
scan_bus handler so generic devices can be declared under it.
This is for devices like the Maxim 98357A which is connected on the
I2S bus for data but has no control channel bus and instead just has
a GPIO for channel selection and power down control and needs to
describe that GPIO connection to the OS via ACPI.
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659b12
Signed-off-by: Harsha Priya <harshapriya.n@intel.com>
Reviewed-on: https://review.coreboot.org/15528
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The P2SB device is device 0xd and function 0. If hidden that
causes the latter pci devices on function >= 1 to not be probed
in the kernel. This is also a problem for coreboot if the P2SB
device is hidden by FSP. That means the coreboot driver won't
be ran. Therefore, provide hide and unhide functions for the
P2SB device.
The other quirk is to allow the GPIO devices to work correctly.
Those devices are ACPI devices. However, their resources are
sub-regions within the P2SB BAR. Sadly, linux doesn't handle
ACPI devices being children of PCI devices. This leads to resource
conflict errors when the P2SB device is visible. For the
time being keep the P2SB device hidden, but also ensure the
resources it is using are accounted for and reserved. The fallout
of that is the PMC and SPI device are no longer probed by the
kernel.
BUG=chrome-os-partner:53017
TEST=Ensured P2SB device is visible and pci resources are allocated
correctly for the devices.
Change-Id: I24e59bbde74310e1ce8425b344a3ad0b88702153
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15530
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Correct the GPP PCIe lane number comments so that they match the code.
Change-Id: If27c6a55ebedb0927dd9e8c7c9a833194e129a25
Signed-off-by: Derek Waldner <derek.waldner.os@gmail.com>
Reviewed-on: https://review.coreboot.org/15095
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Have the different acpi_device_ path functions use a different static
buffer so they can be called interchangeably.
Change-Id: I270a80f66880861d5847bd586a16a73f8f1e2511
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15521
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add the function defined in gpio.h to translate a gpio_t into a
value for use in an ACPI GPIO pin table.
For skylake this just returns the gpio_t value as the pins are
translated directly and they are all in the same ACPI device.
Change-Id: I00fad1cafec2f2d63dce9f7779063be0532649c7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15520
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The upstream kernel driver is not using the of-style naming for
sdmode-gpio so remove the maxim prefix, and remove the duplicate
entry for the sdmode-delay value as well.
Also fix the usage of the path variable, since the device path uses
a static variable it can't be assigned that early or it will be
overwritten by later calls.
This results in the following output for the _DSD when tested on
reef mainboard:
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301")
Package (0x02)
{
Package (0x02)
{
"sdmode-gpio",
Package (0x04)
{
\_SB.PCI0.HDAS.MAXM,
Zero,
Zero,
Zero
}
},
Package (0x02)
{
"sdmode-delay",
Zero
}
}
})
Change-Id: Iab33182a5f64c89151966f5e79f4f7c30840c46f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15514
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are four GPIO communities in this SOC and they are implemented
as separate ACPI devices. This means the pin number that is used in
an ACPI GPIO declaration needs to be relative to the community that
the pin resides in. Also select GENERIC_GPIO_LIB in the SOC Kconfig
so this function actually gets used.
This was tested on the reef mainboard by verifying the output of the
SSDT for the Maxim 98357A codec that the assigned GPIO_76 is listed
as pin 0x24 which is the value relative to the Northwest community.
Change-Id: Iad2ab8eccf4c91185a075ffce8d41c81f06c1113
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15513
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add a function for an SOC to define that will allow it to map the
SOC-specific gpio_t value into an appropriate ACPI pin. The exact
behavior depends on the GPIO implementation in the SOC, but it can
be used to provide a pin number that is relative to the community or
bank that a GPIO resides in.
Change-Id: Icb97ccf7d6a9034877614d49166bc9e4fe659bcf
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15512
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instantiate the touchpad using the drivers/i2c/generic device driver
to generate the ACPI object in the SSDT.
There is not currently a separate wake pin for this device, this will
be added in EVT hardware.
This was tested on the reef board by ensuring that the touchpad device
continues to work in the OS.
Also remove the LPC TPM from the DSDT as it is not present.
Change-Id: I3151a28f628e66f63033398d6fab9fd8f5dfc37b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15481
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Support the I2C interfaces on this SOC using the Intel common lpss_i2c
driver. The controllers are supported in pre-ram environments by
setting a temporary base address in bootblock and in ramstage using
the naturally enumerated base address.
The base speed of this controller is 133MHz and the SCL/SDA timing
values that are reported to the OS are calculated using that clock.
This was tested on a google/reef board doing I2C transactions to the
trackpad both in verstage and in ramstage.
Change-Id: I0a9d62cd1007caa95cdf4754f30c30aaff9f78f9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15480
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for the soc_acpi_name() handler in the device operations
structure to translate a device path into ACPI name.
In order to make this more complete add some missing devices in
include/soc/pci_devs.h.
Change-Id: I517bc86d8d9fe70bfa0fc4eb3828681887239587
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15479
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
That function is no longer used. All users have been updated to
use the ulzman() function which specifies lengths for the input
and output buffers.
Change-Id: Ie630172be914a88ace010ec3ff4ff97da414cb5e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15526
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Boards broken with commit:
062ef1c AGESA boards: Split dispatcher to romstage and ramstage
Boot failure with asus/f2a85-m witnessed around MemMS3Save() call,
message "Save memory S3 data in heap" in verbose agesa logs was
replaced by a system reset.
Default stubs for MemS3ResumeConstructNBBlock() returned TRUE
without initializing the block contents. This would not work for case
with multiple NB support built into same firmware.
MemMCreateS3NbBlock() then returned with S3NBPtr!=NULL with uninitialized
data and MemMContextSave() referenced those as invalid pointers.
There is no reason to prevent booting in the case S3 resume data is not
passed to ramstage, so remove the ASSERT(). It only affects builds with
IDSOPT_IDS_ENABLED=TRUE anyways.
Change-Id: I8fd1e308ceab2b6f4b4c90f0f712934c2918d92d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15344
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Have the Skylake SOC generate ACPI timing values for the enabled I2C
controllers instead of passing it in the DSDT with static timings.
The timing values are generated from the controller clock speed and
are more accurate than the hardcoded values that were in the ASL which
were originally copied from Broadwell where the controller is running
at a different clock speed...
Additionally it is now possible for a board to override the values
using devicetree.cb. If zero is passed in for SCL HCNT or LCNT then
the kernel will generate its own timing using the same forumla, but if
the SDA hold time value is zero the kernel will NOT generate a correct
value and the SDA hold time may be incorrect.
This was tested on the Chell platform to ensure all the I2C devices on
the board are still operational with these new timing values.
Change-Id: I4feb3df9e083592792f8fadd7105e081a984a906
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15291
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Configure GPIO_199 and GPIO_200 as NF2 to work as HPD.
Change-Id: If3aa6b75ed22c221cfbedaecf16035cdd9939387
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Reviewed-on: https://review.coreboot.org/15447
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add ACPI NHLT table generation that the current hardware
supports as well select the hardware used on the board.
Amenia has support for two audio codecs, Dialog for
headsets and Maxim for speakers.
Change-Id: Iaba9ec81ffb4f128f2e4413dec5174d9ecb856c9
Signed-off-by: Saurabh Satija <saurabh.satija@intel.com>
Reviewed-on: https://review.coreboot.org/15024
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The nvs.h header is the one which defines global_nvs_t proper.
Don't rely on an indirect inclusion.
Change-Id: I89d6a73f65e408c73f068b4a35b5efd361a6e5d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15503
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Every other platform has global_nvs_t as a typedef. For some
reason apollolake didn't bother following current conventions.
Fix this omission to allow for better code sharing and consistency.
Change-Id: Id596eed517737759a64ce803c89ea2a05cbe2cce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15502
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
If read_vbnv finds that the vbnv_copy is not valid, it initializes it
with the correct HEADER_SIGNATURE and other attributes. However, the
vbnv copy is checked for validity and initialized at the vboot layer as
well. Since, vboot is the owner of this data, it should be the one
initializing it. Thus, if read_vbnv sees that the data is not valid,
simply reset it to all 0s and let vboot layer take care of it. This also
removes the need for additional checks to ensure that the dirty vbnv
copy is properly updated on storage.
Change-Id: I6101ac41f31f720a6e357c9c56e571d62e0f2f47
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch exposes a function to read pmc bar.
PMC bar is read in function read_pmc_mmio_bar which
is defined static in file pmutil.c. This patch exposes
that functionality to call it from other files.
BUG=chrome-os-partner:53438
TEST= Read the PMC bar value properly from outside
pmutil file.
Change-Id: I26ee13e6ab95d3a8991c7f8ea4b3856ceb015d10
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/15460
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If there is an external 16550 like UART, one needs to enable
the appropriate address ranges before console_init() is called
so that the init sequence can reach the external UART. Otherwise
the UART will only start working in ramstage and will produce
unreadable characters in romstage due to the lack of initialization.
Tested-on: Siemens MC_BDX1
Change-Id: Iafc5b5b6df14916c5ed778928521d4a8f539cf46
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15495
Tested-by: build bot (Jenkins)
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add support for a fourth info block type to hwilib. This block
provides new values and is now variable in length.
Change-Id: Ia928b4a98b806ba3e80fb576b78f60bb8f2ea3fc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15478
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The nhlt_soc_serialize() and nhlt_soc_serialize_oem_overrides()
functions should be able to be leveraged on all Intel SoCs
which support NHLT. Therefore provide that functionality and
make skylake use it.
Change-Id: Ib5535cc874f2680ec22554cecaf97b09753cacd0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15490
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
The nhlt_soc_add_endpoint() is no longer used. Drop its declaration.
Change-Id: I3b68471650a43c5faae44bde523abca7ba250a34
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15489
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Utilize the new NHLT helper functions by driving the NHLT
endpoints through data descriptors.
Change-Id: I80838214d3615b83d4939ec2d96a4fd7050d5920
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15488
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to ease the porting of supporting NHLT endpoints
introduce a nhlt_endpoint_descriptor structure as well as
corresponding helper functions.
Change-Id: I68edaf681b4e60502f6ddbbd04de21d8aa072296
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15486
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Change PCI macros in such a way they can be transparently used across
romstage and ramstage.
Change-Id: Idc708c1990f2fc1d941bb82efcb0a697524f2eca
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15483
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
New UPDs added to header files as well as many comment fixes. Memory
infor is now defined in FspmUpd.h and added ability to skip CSE RBP
for coreboot. Removes some UPDs that are no longer available from
source.
BUG=chrome-os-partner:54677
BRANCH=none
TEST=built and tested with FSP 143_10 version
Change-Id: I7e1f531ebbe343b45151a265ac715ae74aeffcad
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/15459
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently, read_vbnv performs a reset of the vbnv cache if it is not
valid. However, this information is not passed up to the vboot layer,
thus resulting in missed write-back of vbnv cache to storage if vboot
does not update the cache itself.
Update read_vbnv to return a value depending upon whether it wants a
write-back to be performed when save is called.
Return value:
0 = No write-back required
1 = Write-back of VBNV cache is required.
Change-Id: I239939d5f9731d89a9d53fe662321b93fc1ab113
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15457
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
SD card need 20K PULLUP on D0-D3/CLOCK/COMMAND lines.
Without this SDCARD will throw data read/write errors.
BUG=chrome-os-partner:54676
TEST=Build and boot to OS.
Verify SD card is detected and data read/write works well.
Change-Id: I90da5b84dc2e488eb38f805322bd7b4dee394e5b
Signed-off-by: Freddy Paul <freddy.paul@intel.com>
Reviewed-on: https://review.coreboot.org/15345
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add the audio controller device to ACPI and define the _DSM handler
to return the address of the NHLT table, if set in NVS.
Change-Id: I619dbfb562b94255e42a3e5d5a3926c28b14db3e
Signed-off-by: Saurabh Satija <saurabh.satija@intel.com>
Reviewed-on: https://review.coreboot.org/15026
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
Configure unused Pads as NC
and sort the pads according to the gpio community.
Move the pad configurations from mainboard to gpio.h
BUG=none
TEST=Boot to OS and check all functionalities.
Change-Id: I8e9eeebf5d75c71c521649c72612c06f3fa43701
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://review.coreboot.org/15327
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The different entry points (0x100, 0x140, ...), which were defined in
the RISC-V Privileged Specification 1.7, aren't used anymore. Instead
the Spike bootrom jumps at the start of our image, and traps are handled
through mtvec.
Change-Id: I865adec5e7a752a25bac93a45654ac06e27d5a8e
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15283
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The previous change with that intent aligned the framebuffer's
bytes-per-line to 64 instead of 32:
commit 8957dd6b52
Author: Paul Kocialkowski <contact@paulk.fr>
Date: Sun May 1 18:38:04 2016 +0200
tegra124: Align the framebuffer's bytes-per-line to 32
Change-Id: I88bba2ff355a51d42cab6a869ec1e9c534160b9c
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14816
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
This will allow kernel to trigger a APM SMI to enable\disable SCI
Change-Id: I1be79b7a3082c23fbaf204eff55360c46458e325
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/15347
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Parse the devicetree and pass the unused device to fsp
for disabling the device function.
BRANCH=none
BUG=chrome-os-partner:54325
TEST=device off in devicetree should disable the device.
Change-Id: I784b72a43fda13aa17634bf680205ab2d36e8d09
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://review.coreboot.org/15337
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Add support for vboot_platform_prepare_reboot which is called whenever
vboot requests reboot of the platform. SLP_TYPE needs to be set to S5 in
such conditions since the platform would no longer be in a resuming
state after reset.
Change-Id: I01392bfda90c9274cd52c1004555d250b1d539b7
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15340
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We want to be able to easily change SDRAM clock rate for debugging
purposes. This patch adds configurations for 4 different clock rates.
Same configs are used for all rk3399 boards at 200, 666 and 800 MHz.
Kevin board does not run reliably at 666 MHz, an option for it is
added to run at 300 MHz, this option is available to Kevin only.
There is not much room left in the coreboot romstage section, this is
why the config file for 928 MHz is being added with this patch but is
not included in the code, one of the lower frequency options will have
to be dropped for the higher frequency option to be added.
BRANCH=none
BUG=chrome-os-partner:54144
TEST=run "stressapptest -M 1024 -s 3600" and pass on both kevin and
gru. Verified that on Kevin the firmware reports starting up
SDRAM at 300 MHz and on Gru at 800 MHz.
Change-Id: Ie24c1813d5a0e9f0f9bfc781cade9e28fb6eb2f1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: ef5e4551b79c3f0531f9af35491f2c593f8482f1
Original-Change-Id: I08bccd40147ad89d851b995a8aab4d2b6da8258a
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353493
Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://review.coreboot.org/15309
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This is a purely cosmetic change replacing some of the more prominent
copy and paste sections of the code with compressed versions of the
same.
BRANCH=none
BUG=none
TEST=with the rest of the patches applied stressapptest still runs for
an hour on both Kevin and Gru.
Change-Id: I492e1898e312473d07d9e5eceb3e3e10b48ee35f
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: eb8043f96457d090dbbee57097bc1d685e7d32d2
Original-Change-Id: I362e0e261209ae4d4890ecb0e08bb1956c172ffd
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/353774
Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://review.coreboot.org/15308
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Obtain the real-time clock value from the EC on start-up and show the
current time.
BUG=chrome-os-partner:52220
BRANCH=none
TEST=(partial) with future commits and EC clock set, boot on gru into
Linux shell and check the firmware log:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:09:16
Change-Id: Id3ef791f546419c4881a891251cbb62d7596884b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 348e9373b0e95a17f5c39ec28a480712e6e45caf
Original-Change-Id: Iff43b16a86d9fee483420ee2eff5ff3d276716a3
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/351781
Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15303
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Call basic FSP reset handling in FspNotify stage. Handling of reset requests
for other stages need to be implemented as well.
BUG=chrome-os-partner:54149
BRANCH=none
TEST=with FSP that returns reset codes, do cold boot, check
that reboot sequence occurs properly.
Change-Id: I55542aa37e60edb17ca24ac358b61df72679b83e
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15280
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Any FSP API call may request a reset. This is indicated in API function
return code. Add trivial reset handler code.
BUG=chrome-os-partner:54149
BRANCH=none
TEST=none
Change-Id: Ieb5e2d52ffdaf3c3ed416603f6dbb4f9c25a1a7b
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15334
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Global reset enable bit is not cleared on reset. Therefore, clear
the bit early. Lock down 0xcf9 so that payload/OS can't issue
global reset.
BUG=chrome-os-partner:54149
BRANCH=none
TEST=none
Change-Id: I3ddf6dd82429b725c818bcd96e163d2ca0acd308
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15199
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Apollolake defines Global Reset where Host, TXE and PMC are reset.
During boot we may need to trigger a global reset as part of platform
initialization (or for error handling). Add functions to trigger
global reset, enable/disable it and lock global reset bit.
BUG=chrome-os-partner:54149
BRANCH=none
TEST=none
Change-Id: I84296cd1560a0740f33ef6b488f15f99d397998d
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15198
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Looks like we need to do real cold reset in some FSP flows, so
reverting this.
This reverts commit 6f762171de.
Change-Id: Ie948d264c4e2572dab26fdb9462905247a168177
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15331
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Some platforms have an RTC provided by the Chrome OS EC. Allow the EC to
implement rtc_get() so that this can be plumbed in.
BUG=chrome-os-partner:52220
BRANCH=none
TEST=(partial) with future commits, boot on gru and see output:
Date: 1970-01-17 (Saturday) Time: 1:42:44
Then reboot ~10 seconds later and see output:
Date: 1970-01-17 (Saturday) Time: 1:42:53
Change-Id: I3b38f23b259837cdd4bd99167961b7bd245683b3
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 4a4a26da37323c9ac33030c8f1510efae5ac2505
Original-Change-Id: Icaa381d32517dfed8d3b7927495b67a027d5ceea
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/351780
Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15302
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add functions to convert between seconds and a struct rtc_time. Also
add a function that can display the time on the console.
BUG=chrome-os-partner:52220
BRANCH=none
TEST=(partial) with future commits and after setting RTC on the EC:
boot on gru into linux shell, check firmware log:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:01:44
Then reboot ~10 seconds and check again:
localhost ~ # grep Date: /sys/firmware/log
Date: 2016-06-20 (Monday) Time: 18:01:54
Change-Id: Id148ccb7a18a05865b903307358666ff6c7b4a3d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 3b02dbcd7d9023ce0acabebcf904e70007428d27
Original-Change-Id: I344c385e2e4cb995d3a374025c205f01c38b660d
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/351782
Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15301
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Declare the mainboard attached devices in the devicetree and enable
the provided device drivers by default to generate the ACPI objects
for these devices. Then remove the static ACPI objects from the DSDT
in mainboard.asl.
This was tesed on a Chell mainboard since I lack a kunitmisu device.
I used different GPIOs across boots to verify that the different
audio codec devices would be "detected" and generated in the SSDT.
Change-Id: I9b3b2247a84aeb7c07780958377d5bea14417ce6
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15317
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Declare the mainboard attached devices in the devicetree and enable
the provided device drivers by default to generate the ACPI objects
for these devices. Then remove the static ACPI objects from the DSDT
in mainboard.asl.
This was tested on a Chell mainboard since I lack a lars device.
Change-Id: Ifba6fc6589ddd54f4c85e8858f17997fbb4b6176
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15316
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Declare the mainboard attached devices in the devicetree and enable
the provided device drivers by default to generate the ACPI objects
for these devices. Then remove the static ACPI objects from the DSDT
in mainboard.asl.
This was verified on a glados board by verifying the SSDT contents
against what used to be in the DSDT.
Change-Id: I710cbb8462d0fe695297102a64bec8e4212acc65
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15315
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Declare the mainboard attached devices in the devicetree and enable
the provided device drivers by default to generate the ACPI objects
for these devices. Then remove the static ACPI objects from the DSDT
in mainboard.asl.
This was verified by comparing the generated ACPI code in the SSDT
to what was in mainboard.asl and ensuring the contents are
functionally equivalent.
Change-Id: I4725bbe2d47178568e3024fe3bb48cc80ff861c3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15314
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Rewrite inline assembly for ARMv7+ to correctly annotate inputs and
outputs. On ARM GCC 6.1.1, this causes assembly output to change from
the incorrect
@ r0 is allocated to hold dst and x0
@ r1 is allocated to hold src and x1
ldr r0, [r1] @ clobbers dst!
ldr r1, [r1, #4]
str r0, [r0]
str r1, [r0, #4]
to the correct
@ r0 is allocated to hold dst
@ r1 is allocated to hold src and x1
@ r3 is allocated to hold x0
ldr r3, [r1]
ldr r1, [r1, #4]
str r3, [r0]
str r1, [r0, #4]
Also modify checkpatch.pl to ignore spaces before opening brackets when
used in inline assembly.
Change-Id: I255995f5e0a7b1a95375258755a93972c51d79b8
Signed-off-by: Benjamin Barenblat <bbaren@google.com>
Reviewed-on: https://review.coreboot.org/15216
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Correct the definitions for 16b and 32b SO-DIMM modules.
Regarding JEDEC Standard No. 21-C
Annex K: Serial Presence Detect for DDR3 SDRAM Modules (2014),
the hex values used for 16b-SO-DIMM is 0x0c
and for 32b-SO-DIMM module type is 0x0d
Change-Id: I9210ac3409a4aaf55a0f6411d5960cfdca05068d
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/15262
Tested-by: build bot (Jenkins)
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Broken with commit:
2585209 mb/samsung/lumpy/romstage: read SPD data of removable DIMM
The blob can pick SPDs from the addresses defined in pei_data
and we do only define read_spd() with USE_NATIVE_RAMINIT.
Change-Id: Ibd6d7a4a53fa808b476d3060872cb10d3dfce534
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15329
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Broken with commit:
5c10abe nb/intel/sandybridge: increase MMCONF_BASE_ADDRESS
Available sandybridge/systemagent-r6.bin has MMCONF hard-coded
at some places and samsung/lumpy fails at boot here:
CBFS: Locating 'mrc.bin'
CBFS: Found @ offset 9fec0 size 2fc94
System Agent: Starting up...
System Agent: Initializing
These are the last lines as captured over USB debug.
Change-Id: I441847f0e71a5e1be9c8ef6a04a81eb7bdd8a6d9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15328
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Mark 256KiB at end of BIOS region as unusable BIOS region is
memory-mapped just below 4GiB, however last 256KiB is unusable. Mark it
accordingly in fmd file.
2. Use up holes in RW region for RW_A and RW_B.
3. Fill up holes in RO with UNUSED regions.
BUG=chrome-os-partner:54672
Change-Id: I5facc566bb70d950522e12228b0631ddf00ac63d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15313
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
for per cs training, there should be more cycles to switch delay line.
so increase W2W_DIFFCS_DLY_F0 value from 0x1 to 0x5.
BRANCH=none
BUG=chrome-os-partner:54144
TEST=run "stressapptest -M 1024 -s 1000" and pass
Change-Id: I11720b7c6f009789b88ca26fc5da88597ed1622e
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 9de93beae09174d50a31d2df655529f71628f77c
Original-Change-Id: Ide23fff04fd63fb0afc538b610b7685756f79f8d
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/352953
Original-Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://review.coreboot.org/15307
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
After write leveling for all ranks, check the
PHY_CLK_WRDQS_SLAVE_DELAY result, if the two ranks in one slice both
meet (0x200-PHY_CLK_WRDQS_SLAVE_DELAY < 0x20) or
(0x200-PHY_CLK_WRDQS_SLAVE > 0x1E0), enable PHY_WRLVL_EARLY_FORCE_ZERO
for this slice, and trigger write leveling again.
BRANCH=none
BUG=chrome-os-partner:54144
TEST=run "stressapptest -M 1024 -s 1000" and pass
Change-Id: I1a0e4e888eb62b5fae5b5e5437a385e8660a246d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 717cbac97b2045f2934e99859ce405aa3637b1c4
Original-Change-Id: Ic0d7c59404e870a7108ed64bbf3215fcc2d0973e
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/351825
Reviewed-on: https://review.coreboot.org/15300
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
To fully define TPM attachment to a SPI interface both bus and CS
(chip select) settings are required. Add the missing CS configuration
option.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied it is possible to compile in
and run TPM2 SPI driver.
Change-Id: If297df8e5b9526f156ed1414eb9db317d6af5b33
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353913
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15299
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This introduces a SPI TPM driver compliant with the TCG issued "TPM
Profile (PTP) Specification Revision 00.43" which can be found by
googling its title.
The driver implements both the hardware flow control protocol and the
TPM state machine.
The hardware flow control allows to map SPI based TPM devices to the
LPC address space on x86 platforms, on all other platforms it needs to
be implemented in the driver software.
The tis layer is somewhat superficial, it might have to be expanded
later.
A lot more implementation details can be found in the code comments.
Also, it is worth mentioning that this is not a complete version of
the driver: its robustness needs to be improved, delay loops need to
be bound, error conditions need to propagate up the call stack.
BRANCH=none
BUG=chrome-os-partner:52132, chrome-os-partner:50645, chrome-os-partner:54141
TEST=with the rest of the patches applied coreboot is able complete
Chrome OS factory initialization of the TPM2 device.
Change-Id: I967bc5c689f6e6f345755f08cb088ad37abd5d1c
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 5611c6f7d7fe6d37da668f337f0e70263913d63e
Original-Change-Id: I17d732e66bd231c2289ec289994dd819c6276855
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/350124
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15298
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Tested-by: build bot (Jenkins)
The CENTER LOGIC should always be 0.9V and can not be adjusted,
so use duty_ns = 2860 to correct CENTER LOGIC to 0.9V. And now
DDR seems to run stable at 800MHz on the gru board.
BRANCH=none
BUG=chrome-os-partner:54144, chrome-os-partner:53208
TEST=run "stressapptest -M 1024 -s 1000" and pass
Change-Id: Ia900e248c10ddd0ab630446a324cc0446c0fa49b
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: f4fb1cefb59ac4099cef8b32a68ed9222e708478
Original-Change-Id: I2238da6c17908d09bc284b321d796901317ed9ef
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/352772
Reviewed-on: https://review.coreboot.org/15297
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Set up the pins and initialize the driver.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:51537
TEST=with the rest of the patches applied it is possible to
communicate with the cr50.
Change-Id: I9fc1cb84ccababa6f58b2d5beec4572dc1d79da1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 6100471db2a00fd411afc05d621429b8f8a2f81d
Original-Change-Id: I0ccd8777288e35870658268813c9202dd850c70d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/349852
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/15296
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This register is described in the TRM in section called
GRF_GPIO3D_IOMUX. Added definitions allow to configure the SPI0
interface.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:51537
TEST=with the rest of the patches applied it is possible to
communicate over SPI0
Change-Id: Ieee3fcae6095020042b02673c7d863f398ed2eb4
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 8f155e3b47c9f44ad4e5a2513916572e7d5ec0ab
Original-Change-Id: Iea92971b0520dc4549cd0fd263dcb2098f80f6d6
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/349851
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/15295
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Until now it was assumed that all TPM devices were of the same type
(TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs
and all other boards had I2C connected TPMs.
With the advent of TPM2 specification there is a need to be able to
configure different combinations of TPM types (TPM or TPM2) and
interfaces (LPC, I2C and SPI).
This patch allows to do it. Picking Chrome OS still assumes that the
board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's
Kconfig will trigger including of TPM2 instead.
MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding
SPI_TPM to the board config switches interface choice to SPI, and if
neither of the two is defined, the interface is assumed to be I2C.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that none of the generated board configurations change
as a result of this patch. With the rest of the stack in place it
is possible to configure different combinations of TPM types and
interfaces for ARM and x86 boards.
Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1
Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/349850
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15294
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
get_bios_size returns the value of bios_size. Use this function to
calculate bios_size for caching in bootblock.
BUG=chrome-os-partner:54563
Change-Id: I2e592b1c52138bd4623ad2acd05c744224a8e50b
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15292
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This variable name was changed in chip.h but not the consumer
and it was submitted before it was caught.
Change-Id: I7c492b588b2fd854a9eeac36029a46da324a7b1b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15109
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Some of the support functions will be built for romstage
once HIGH_MEMORY_SAVE is removed.
Change-Id: I43ed9067cf6b2152a354088c1dcb02d374eb6efe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15242
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This file is pulled for x86 bootblock builds using ROMCC,
which would choke on struct bus.
Change-Id: Ie3566cd5cfc4b4e0e910b47785449de81a07b9ef
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15274
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
No need to make low memory backup unless we are on
S3 resume path.
Hide those details from ACPI.
Change-Id: Ic08b6d70c7895b094afdb3c77e020ff37ad632a1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15241
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Without RELOCATABLE_RAMSTAGE have WB cache large enough
to cover the greatest ramstage needs, as there is no benefit
of trying to accurately match the actual need. Choose
this to be bottom 16MiB.
With RELOCATABLE_RAMSTAGE write-back cache of low ram is
only useful for bottom 1MiB of RAM as a small part of this gets used
during SMP initialisation before proper MTRR setup.
Change-Id: Icd5f8461f81ed0e671130f1142641a48d1304f30
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15249
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
At the higher speeds stressapptest shows memory errors. We don't want
to track down random problems due to simple memory corruption, so slow
memory back down to 300 MHz until someone figures out how to make it
faster without sacrificing reliability.
BRANCH=None
BUG=chrome-os-partner:54144
TEST=stressapptest -M 1024 -s 240
Change-Id: I2417f93f65b1491a028a63ce563ed7dd7831becc
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id:
Original-Change-Id: I02182b25e677e27e8541445938f9da9ae9553fa6
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/350480
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15120
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
To support gpio power off SOC, we need to pass the power off
gpio parameter to BL31. Gru reuse tsadc overtemp pin as power
off gpio, so need to iomux to gpio function when use gpio power
off function, either in bl31 or depthcharge.
BRANCH=None
BUG=chrome-os-partner:53448
TEST=Build gru
Change-Id: Ibfe64042f39f6df1b87536b50fe432859bf74426
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id:
Original-Change-Id: Ie7a1bbea4a12753f0abac7a9142f2e032686ce31
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/349703
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15119
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
To support gpio reset SOC, we need to pass the reset gpio
parameter to BL31. Note: request BL31 have supported this
function.
BRANCH=None
BUG=chrome-os-partner:51924
TEST=Build gru
Change-Id: I182cff11ce6f5dc3354db0dc053c128b813acf9f
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id:
Original-Change-Id: I8283596565d552b1f3db31c28621a1601c226999
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/349702
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15118
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
sometimes we need gpio number, so add this macro so we
can get the gpio number if we need.
BRANCH=None
BUG=chrome-os-partner:51924
TEST=Build gru
Change-Id: I0c8c6cc0643a66e9ae1f21b02c7364c641b9805d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id:
Original-Change-Id: I98e8cf15543179904295a86e9f720c2d7c8b443a
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/349701
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/15117
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Disabling ISH causes resets in FSP which leads to hang. This should be
fixed in a later stepping. Until then keep ISH enabled.
BUG=chrome-os-partner:54033
Change-Id: Id9cb276eed8d027ab6d2e81a5ec962bc730c1ff5
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15142
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Instead of hard-coding the BIOS region start and end addresses, read
BIOS_BFPREG to determine the base and limit for the mapped BIOS
region.
BUG=chrome-os-partner:54563
Change-Id: Iddd3d4cc945f09e8f147e293bb9144471a6a220d
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15269
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This makes it clearer that the read/write operations are being performed
on the host controllers registers.
Change-Id: Id63d778a4a03c461d97e535c34b85ada3ae469de
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15281
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This allows initialization of runtime region devices and xlate region
devices where all parameters cannot be statically determined.
BUG=chrome-os-partner:54563
Change-Id: Ia6e1b695fed3bbfa08598d1593e650fc1465d41f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15267
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This makes the name consistent with other region device init macros.
Change-Id: I248894ba6c85326b615dcb71e8f498bc8be50911
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15277
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
spi_read_status reads the status register using hardware sequencing and
returns 0 on success and -1 on error. Use spi_read_status to return
appropriate value for get_sw_write_protect.
BUG=chrome-os-partner:54283
Change-Id: I7650b5c0ab05a8429c2b291f00d4672446d86e03
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15266
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
spi_init should be run early enough in ramstage so that any init
calls (e.g. mainboard_ec_init) that write on flash have right
permissions set.
Change-Id: I9cd3dc723387757951acd40449d4a41986836d2a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15235
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Bootblock:
- Temporary BAR needs to be assigned for SPI device until PCI
enumeration is done by ramstage which allocates a new BAR.
- Call spi_init to allow bootblock/verstage to write/erase on flash.
Ramstage:
- spi_init needs to run in ramstage to allow write protect to be
disabled for eventlog and NVRAM updates. This needs to be done pretty
early so that any init calls(e.g. mainboard_ec_init) writing to flash
work properly.
Verified with this change that there are no more flash write/erase
errors for ELOG/NVRAM.
BUG=chrome-os-partner:54283
Change-Id: Iff840e055548485e6521889fcf264a10fb5d9491
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15209
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
This I2C controller has separate registers for different speeds to set
specific timing for SCL high and low times, and then a single register
to configure the SDA hold time.
For the most part these values can be generated based on the freq of
the controller clock, which is SOC-specific. The existing driver was
generating SCL HCNT/LCNT values, but not the SDA hold time so that is
added.
Additionally a board may need custom values as the exact timing can
depend on trace lengths and the number of devices on the I2C bus. This
is a two-part customizaton, the first is to set the values for desired
speed for use within firmware, and the second is to provide those
values in ACPI for the OS driver to consume.
And finally, recent upstream changes to the designware i2c driver in
the Linux kernel now support passing custom timing values for high
speed and fast-plus speed, so these are now supported as well.
Since these custom speed configs will come from devicetree a macro is
added to simplify the description:
register "i2c[4].speed_config" = "{
LPSS_I2C_SPEED_CONFIG(STANDARD, 432, 507, 30),
LPSS_I2C_SPEED_CONFIG(FAST, 72, 160, 30),
LPSS_I2C_SPEED_CONFIG(FAST_PLUS, 52, 120, 30),
LPSS_I2C_SPEED_CONFIG(HIGH, 38, 90, 30),
}"
Which will result in the following speed config in \_SB.PCI0.I2C4:
Name (SSCN, Package () { 432, 507, 30 })
Name (FMCN, Package () { 72, 160, 30 })
Name (FPCN, Package () { 52, 120, 30 })
Name (HSCN, Package () { 38, 90, 30 })
Change-Id: I18964426bb83fad0c956ad43a36ed9e04f3a66b5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15163
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch enlists ELAN trackpad on I2C4 for reef board.
BUG=None
TEST=Build and boot to OS.
Ensure ELAN trackpad is working with ELAN trackpad driver enabled
in kernel.
Change-Id: I788600f16dea9fac0e089cb82ccfc38a960157f9
Signed-off-by: Freddy Paul <freddy.paul@intel.com>
Reviewed-on: https://review.coreboot.org/15213
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
New structures and functions have been added to make it easier and
clearer to talk to GPIOs, configure the clock module, and toggle the
LEDs. Use that code in bootblock.c instead of doing those things
manually with hardcoded addresses.
Change-Id: If41db0220de4bc95a6c99945ec402e3026cb4eeb
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/3944
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
RAM doesn't need any initialization on qemu, so we can simply use it
right away. No need to try using the cache as ram in the first place.
We also can place the stack in normal ram right from start and we
don't have to switch it to another place later on. Place the stack
in real mode memory which isn't used for something else.
Change-Id: Ib7a3f58a846d139f7babea5f43722a30fe0fe962
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: https://review.coreboot.org/15214
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This is where the RAM is (now), on RISC-V.
We need to put coreboot.rom in RAM because Spike (at the moment) only
supports loading code into the RAM, not into the boot ROM.
Change-Id: I6c9b7cffe5fa414825491ee4ac0d2dad59a2d75c
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15149
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Variable name shadows parameter name used on other functions,
and it can be local anyway after function removal.
Change-Id: I3164b15b33d877fef139f48ab2091e60e3124c3b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15240
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Not masking any bits in Operating System Capabilities, which means we
support all the capabilities that OS passed in Arg3
Change-Id: Ib87915e18e305db41b52891ac5430201dda64bb5
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://review.coreboot.org/15021
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of programming unsupported CAS use the highest supported
value. Start at DDR3 maximum of CAS 18T.
Increase error message verbosity level.
Useful for overclocking.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
Allows to run a DDR3-1600 DIMM at 933Mhz.
Change-Id: I2e8aadd541f06fa032ad7095c9a2d5e3bb7613f3
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15217
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Calculate the value from current DDR frequency.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
Change-Id: I57ffbfeb291fc2fede278d18527993e7432e9bd8
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15184
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Add Ramaxel DRAM manufacturer id.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
The manufacturer name shows up in dmidecode.
Change-Id: I14cdc82c09f0f990e2ba18083748d11d79e53874
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15183
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Set max_mem_clock_mhz in devicetree to 933Mhz.
Allows to run the memory at up to DDR3-1866.
The same frequency was allowed within the first vendor bios,
but Lenovo than decided to limit it to DDR3-1333.
Tested on Lenovo T520 and DDR3-1600 DIMM (RMT3170eb86e9w16).
The RAM is now running at DDR3-1600 instead of DDR3-1333.
This gives about 4% performance increase in glmark2 using the
Intel GPU.
Change-Id: If15be497402d84a2778f0434b6381a64eda832d6
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/15158
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
CPU_MICROCODE_MULTIPLE_FILES relies on SUPPORT_CPU_MICROCODE_CBFS,
which is not set if CPU_MICROCODE_CBFS_NONE is set.
This makes selecting CPU_MICROCODE_MULTIPLE_FILES conditional.
Change-Id: I0c28f99a1b868bbf90a6f048cce3bea4ff849f76
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/15259
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineering.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
It would not be possible to set MTRR for range 1MiB to 4MiB.
Our RAMTOP is power of 2 and enabling cache for bottom
1MiB should cause no problems.
Change-Id: I3619bc25be60f42b68615bfcdf36f02d66796e02
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15238
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Required EHCI state is maintained as a CAR_GLOBAL to have it
properly migrated.
Change-Id: I8df413bec6faae4952670710c8ac804e0331c966
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15236
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reference to CACHE_AS_RAM was from the days we had
romcc boards using socket_mPGA605.
Change-Id: If397db83a01adeda4dd18d8b4c6e89bf0984264a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15224
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This is more of ACPI S3 resume and x86 definition than CBMEM.
Change-Id: Iffbfb2e30ab5ea0b736e5626f51c86c7452f3129
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15190
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This Kconfig is deprecated, new platforms need to locate
ramstage stack in CBMEM instead.
Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15189
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that the flash size is increased to 16MiB, add RW_NVRAM and
RW_LEGACY sections to chromeos.fmd file.
BUG=chrome-os-partner:54390
Change-Id: I6c79d35295c4bc774f05f8045ac920474d7a791f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15192
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Migrate google/rikku (Acer Chromebox CXI2) from Chromium tree to
upstream, using google/guado as a baseline.
original source:
branch firmware-rikku-6301.110.B
commit 2e71207 [CHERRY-PICK: broadwell: Update to microcode 0x1F]
TEST=built and booted Linux on rikku with full functionality
blobs required for working image:
VGA BIOS (vgabios.bin)
firmware descriptor (ifd.bin)
Intel ME firmware (me.bin)
MRC (mrc.bin)
external reference code (refcode.elf)
Change-Id: Iba618a0b2cf2d613f6429b3e7606e0b47fa97a4d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/12802
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
CBMEM console stores all the console logs in CBMEM. Address of this
location in CBMEM where console logs are stored needs to be passed up to
OS using GNVS.
1. Add CBMC to GNVS fields in globalnvs.asl
2. Add cbmc member to global_nvs_t structure in nvs.h
3. Initialize gnvs->cbmc to address of cbmem console
BUG=chrome-os-partner:54342
Change-Id: Idcd4573e626fa433c1623bdcbe29921de64539b2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15177
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
FSP methods may require reset under certain conditions. That is indicated
by returning specific return code. Add the missing return status codes.
BUG=chrome-os-partner:54149
BRANCH=none
TEST=none
Change-Id: I460353c5f835548a98255bd3e11dbfd08260ea52
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/15185
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Vadim Bendebury