coreboot boot from little core, and not use big core for now,
but it seem if apll_b use defalut 24MHz it will take a long time
to enable big core, and will cause a watchdog crash, so we should
do apll_b initialization in coreboot, so set apll_b to 600MHz.
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: Id3487138b383b6643ba7e3ce1eae501a6622da10
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356399
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
use apll define instead apll_l define, so we can reuse it when
do apll_b setting.
BRANCH=None
BUG=None
TEST=Boot from Gru
Change-Id: I63966e98af48eaf49837eb0b781eea001a376ef4
Signed-off-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/356398
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Douglas Anderson <dianders@chromium.org>
now aclkm pclkdbg atclk clock use apll_l as parent, but the apll_l
may change in firmware, so we need to caculate the div value base
on apll_l frequency.
BRANCH=None
BUG=chrome-os-partner:54376
TEST=Boot from Gru
Change-Id: I7e3a5d9e3f608ddf15592d893117c92767fcd015
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356397
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 Neuschfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/15283
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/356717
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
Reviewed-on: https://chromium-review.googlesource.com/356715
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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 ~ #
Change-Id: I04116881a30001e35e989e51ec1567263f9149a6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356542
Reviewed-by: Andrey Pronin <apronin@chromium.org>
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: Iaf8a32cfe2b22c4ccff71952f90d162ad8c2d3e7
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355665
Reviewed-by: Martin Roth <martinroth@chromium.org>
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>
Reviewed-on: https://chromium-review.googlesource.com/356464
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
The name 'bpdt_size' is used for a function as well as ia local variable.
As ifwitool is compiled using HOSTCC, there can be an older gcc version
used for the compilation. With gcc version 4.4.7 I get the following
error: declaration of 'bpdt_size' shadows a global declaration
To fix it, rename the function to get_bpdt_size so that names are
unique now.
Change-Id: I47791c705ac4ab28307c52b86940a7a14a5cfef8
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15343
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/356460
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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)
Reviewed-on: https://chromium-review.googlesource.com/356455
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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>
Reviewed-on: https://chromium-review.googlesource.com/356453
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@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)
Reviewed-on: https://chromium-review.googlesource.com/356451
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@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)
Reviewed-on: https://chromium-review.googlesource.com/356450
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@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 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)
Reviewed-on: https://chromium-review.googlesource.com/356449
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@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 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)
Reviewed-on: https://chromium-review.googlesource.com/356448
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@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 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>
Reviewed-on: https://chromium-review.googlesource.com/356447
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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>
Reviewed-on: https://chromium-review.googlesource.com/356445
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
Reviewed-on: https://chromium-review.googlesource.com/356442
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
Change-Id: Ia781ce99630d759469d2bded40952ed21830e611
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356291
Tested-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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
Change-Id: Idb069dabb80d34a0efdf04c3c40a42ab0c8a3f94
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355704
Reviewed-by: Scott Collyer <scollyer@chromium.org>
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: Ie82d4e148025c0040cdb26f53f028d9b4cbe2332
Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Reviewed-on: https://chromium-review.googlesource.com/355200
Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Reviewed-by: Suresh Rajashekara <sureshraj@chromium.org>
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.
Change-Id: I917b2f74dfdbd214d7f651ce3d4b80f4a18def20
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353916
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
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: I202276ef9a43c28b5f304f901ac5b91048878b76
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353915
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
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: Ib340fa8e7db51c10e5080973c16a19b0ebbb61e6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353914
Commit-Ready: Martin Roth <martinroth@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: Kysti Mlkki <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>
Reviewed-on: https://chromium-review.googlesource.com/355743
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.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: Kysti Mlkki <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>
Reviewed-on: https://chromium-review.googlesource.com/355742
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@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.
CQ-DEPEND=CL:354785
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>
Reviewed-on: https://chromium-review.googlesource.com/355741
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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: I2de6fa6c05d3eca989d6785228d5adde1f2a7ab7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/355620
Reviewed-by: Bill Richardson <wfrichar@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: I60df65bfd4053207fa90b1c2a8609eec09f3c475
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/354040
