This reverts commit 28821dbb22.
(https://review.coreboot.org/16649)
This change causes the kernel to boot really slow. Maybe there is an
interrupt storm that prevents the kernel from making any
progress. Reverting until the proper kernel dependency is met.
BUG=chrome-os-partner:57364
BRANCH=None
TEST=Kernels boots to prompt fine on DVT.
Change-Id: I1c9913b4476a08303f9dd887b8631601c847dcf7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d7014ee1bb88df7a2d7f6b3dced797fef75b252d
Original-Change-Id: I061c0b03b43b516a190b370c04888e73a410fcf1
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/391233
Original-Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/16881
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
CL:377541 was supposed to remove the big CPU cluster initialization from
rkclk_init() in the bootblock and move it to a more suitable place in
ramstage. Except that next to all the code cleanup I did in that patch,
I seem to have forgotten to actually remove that old code.
Big thanks to Nico for spotting that in the upstream coreboot review.
BRANCH=gru
BUG=chrome-os-partner:54906
TEST=Booted Kevin.
Change-Id: I09fe948b4587536802b42329b813177439e0804f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 77f9eaf0446b22adfca79d0adf8a0ecfd93c0040
Original-Change-Id: I13dab208225b7e43ad864f2f3cf51b3c104acd4b
Original-Reported-by: Nico Huber <nico.h@gmx.de>
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/389236
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16769
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This selects the rank to train before training is triggered. This is
to prevent any race conditions with the hardware.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=stressapptest -M 1536 -s 1000
Change-Id: I892bace414cf4495619d41bdaea0c4e91c1e29b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8f2dd6f52978a9e54ddd2688eb68fd237aabfe2d
Original-Change-Id: I4e7118d8509b59e391d0a254477b5390dfdd43a5
Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/387907
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: 云平 汤 <typ@rock-chips.com>
Reviewed-on: https://review.coreboot.org/16768
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
UX Doc = go/gale-hw-ui
This color wasn't changed earlier as the change wasn't done in
the OS also. However, since we cannot change this later in FW
(but OS can change anytime), I am making this change after discussing
with the UX team.
BUG=b:31501528, b:31633562
TEST=Change the device state to 'recovery mode' to observe the new
color.
BRANCH=none
Change-Id: Ia91f14eb77492095cb41a9de0bb9790e72aa4851
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36a3d8c6eabbc0b23d0a15d5bddc5ed3bdeebe70
Original-Change-Id: I88768b94cf91804a6005e44b1a168e059698ec4b
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/388206
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16767
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
There are two modifications in the driver:
1. Correctly set speeds based on DDR frequency.
Control the speeds in the predriver circuits to reduce power.
SPEED[1:0]
2'b00:less than 800Mbps(400MHz)
2b01 : 800Mbps(400MHz) to 1600Mbps(800MHz)
2b10 : 1600Mbsp(800MHz) to 2400Mbps(1200MHz)
2b11 : 3200Mbps and greater
2. Configure the number of cycles for the phy clock pll wait time after
locking, based on the DDR config file.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=do memtester on kevin board, and pass
Change-Id: Iaf6da59c6c5c290867e0922a2a99de272f4c7bde
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 125cf8afac3a682d33896fe74a20ba1d498a3bd2
Original-Change-Id: Iabc17df37a701c4f052540c3c259f209a1db3c59
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387428
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16722
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
PHY_PER_CS_TRAINING is being enabled when DDR frequency >= 666.
For per cs training, the controller should consider the PHY
delay line switch time and there should be more cycles to
switch the delay line, so update the W2W_DIFFCS_DLY_ value
from 0x1 to 0x5.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=do memtester on kevin board, and pass
Change-Id: I00df2d4724b0b77f3e7565809fb35bbd2ff01ea5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c135ea3e33d810ed322d947eb8d512d1ac119cfc
Original-Change-Id: I81b99cbc085769b7028e770509d79bd8d550820b
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387506
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16721
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
To save power when entering suspend, gpios 2 to 4 need to be set
to input and 'pull none' mode.
Pass the APIO configuration to ATF so it can do a proper job here.
BRANCH=None
BUG=chrome-os-partner:56423
TEST=run suspend_stress_test on kevin board
Change-Id: Id57fe8f622ae3f9c2bc7e58be89518b2b846cd37
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9c42082d1ca9a6baa735821382d3e83c1f8dc9ad
Original-Change-Id: Iaf441e8e34c5591ffe7c65f6533fcf0b733ff5ac
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/378475
Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com>
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16720
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We need to disable some regulators when the device goes into suspend.
This means that we need to pass some gpios to bl31, and disable these
gpios when bl31 runs the suspend function.
BRANCH=None
BUG=chrome-os-partner:56423
TEST=enter suspend, measure suspend gpio go to low
[pg: also update arm-trusted-firmware to match]
Change-Id: Ia0835e16f7e65de6dd24a892241f0af542ec5b4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0f3332ef2136fd93f7faad579386ba5af003cf70
Original-Change-Id: I03d0407e0ef035823519a997534dcfea078a7ccd
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/374046
Original-Commit-Ready: Caesar Wang <wxt@rock-chips.com>
Original-Tested-by: Caesar Wang <wxt@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16719
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Create the initial Pyro variant which refers to the Reef.
Pyro is APL Chrome board that deviate from reference board Reef.
BRANCH=master
BUG=None
TEST=Build
Signed-off-by: Kevin Chiu <Kevin.Chiu@quantatw.com>
Change-Id: I9beed1f6895e8891d3d51b563edfe172f566718b
Reviewed-on: https://review.coreboot.org/16855
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Colors and patterns as defined by the UX team
BUG=b:31501528
TEST=Move the device to different states in FW using rec and dev
button and verify the colors
BRANCH=None
Change-Id: I66d41a54590cd3ce4e5202c7cfa890f462fe195e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 703559d5dddaeeb7d435d6cadbb2009a1b7a76c8
Original-Change-Id: I95ab1fa59b483396ff1498a28f1ee98ac08d02d7
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387258
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16718
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In USB2 only mode, the Type-C PHY will be held in reset and
only the USB2 logic of the USB3 OTG controller and PHY will be
used over the USB2 pins on the Type-C connector to support Low,
Full and High-speed USB operation.
BRANCH=none
BUG=chrome-os-partner:56425
TEST=Go to recovery mode, plug a Type-C USB drive containing
chrome OS image into both ports in all orientations, check if
system can boot from USB.
Change-Id: Ic265c0c91c24f63b2f9c3106eb2bb277a589233b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a37ccc5b6019967483eac6b5a360d67bc3326e93
Original-Change-Id: I582f04f84eef447ff0ba691ce60e9461ed31cfad
Original-Signed-off-by: Liangfeng Wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/385837
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/16717
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
To improve sdram 800MHz and 933MHz stability, we
need to modify write leveling flow to get the
proper write leveling value.
BUG=chrome-os-partner:56940
BRANCH=none
TEST=Boot from kevin on 933MHz, and do stressapptest
Change-Id: I5b24c93d4a57917fb9af7e5e2a95d8423ccbaa7e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d84bf25b3e5de373c7913e6d534a810cb984b3fd
Original-Change-Id: I87efddf628c3683fcb85d6875e029cf3cbc482be
Original-Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Original-Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/384292
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/16716
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Since there's currently a limitation in coreboot's code that prevents
more than 4KB to be used by the eventlog anyway, this patch shrinks the
available RW_ELOG area in the FMAP for Gru down to 4KB. This may prove
prudent later if we ever resolve that limitation, so that tools can rely
on the area in the FMAP being the same as the area actually used by the
read-only firmware code on these boards.
BRANCH=gru
BUG=chrome-os-partner:55593
TEST=Booted Kevin, confirmed that eventlog got written normally. Ran a
reboot loop to exhaust eventlog space, confirmed that the shrink code
kicks in as expected before reaching 4KB.
Change-Id: I3c55d836c72486665a19783fe98ce9e0df174b6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 05efb82ca00703fd92d925ebf717738e37295c18
Original-Change-Id: Ia2617681f9394e953f5beb4abf419fe8d97e6d3e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/384585
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Simon Glass <sjg@google.com>
Reviewed-on: https://review.coreboot.org/16715
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We found that we may want to load some components of BL31 on the RK3399
into SRAM. As usual, these components may not overlap any coreboot
regions still in use at that time, as is already statically checked by
the check-ramstage-overlaps rule in Makefile.inc.
On RK3399, the only such regions are TTB and STACK. This patch moves the
TTB region back to the end of SRAM (right before STACK), so that a large
contiguous region of SRAM before that remains usable for BL31.
BRANCH=gru
BUG=None
TEST=Booted Kevin.
Change-Id: I1689d0280d79bad805fea5fc3759c2ae3ba24915
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1d4c6c6f6cc0efe97d6962a81e309a1c040d1def
Original-Change-Id: I37c94f2460ef63aec4526caabe58f35ae851bab0
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/384635
Original-Reviewed-by: Simon Glass <sjg@google.com>
Reviewed-on: https://review.coreboot.org/16714
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
With a SPI clock above about 24MHz the APB cannot keep up when doing
individual byte transfers. Adjust the driver to use 16-bit reads when
it can, to remove this bottleneck.
Any transaction which involves writing bytes still uses 8-bit transfers,
to simplify the code. These are the transfers that are not time-critical
since they tend to be small. The case that really matters is reading from
SPI flash.
In general we can use 16-bit reads anytime we are transferring an even
number of bytes. If the code detects an odd number of bytes, it tries to
perform the operation in two steps: once in 16-bit mode with an even
number of bytes, and once in 8-bit mode for the final byte. This allow
us to use 16-bit reads even if asked to transfer (for example) 0xf423
bytes.
The limit on in_now and out_now is adjusted to 0xfffe to avoid an extra
transfer when transferring ~>=64KB.
CQ-DEPEND=CL:383232
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see that things still work correctly. I tested (with
extra debugging) that the 16-bit case is being picked when it should be.
Change-Id: If5effae9a84e4de06537fd594bedf7f01d6a9c88
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ec250b4931c7d99cc014e32ab597fca948299d08
Original-Change-Id: Idc5b7e5d82cdbdc1e8fe8b2d6da819edf2d5570c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381312
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/16712
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
We found some boards are not stable when sdram is run at 933Mhz.
Before we can fix it, we need to lower the sdram frequency to 800MHz.
In this patch we modify the DQS delay from 0x280 to 0x260 and extend
the DQS window.
BRANCH=None
BUG=chrome-os-partner:56940
TEST=Booted Kevin.
Change-Id: I68561c4aa4d9ab66acfa3515a42d696157aff759
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 877a7f6ad22a5bde9f9e458bcb65f133f2f001bd
Original-Change-Id: I5eab6bbe96f0dae095c5353403292022e7a25421
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/382724
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16709
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Switch the BL31 (ARM Trusted Firmware) format to payload so that it can
have multiple independent segments. This also requires disabling the region
check since SRAM is currently faulted by that check.
This has been tested with Rockchip's pending change:
https://chromium-review.googlesource.com/#/c/368592/3
with the patch mentioned on the bug at #13.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs. Im not sure if it is
correct though:
CBFS: Locating 'fallback/payload'
CBFS: Found @ offset 1b440 size 15a75
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x18104800 memsize 0x117fbe0 srcaddr 0x100038 filesize 0x15a3d
Loading segment from ROM address 0x000000000010001c
Entry Point 0x0000000018104800
Loading Segment: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000018104800 memsz: 0x000000000117fbe0 filesz: 0x0000000000015a3d
using LZMA
[ 0x18104800, 18137d90, 0x192843e0) <- 00100038
Clearing Segment: addr: 0x0000000018137d90 memsz: 0x000000000114c650
dest 0000000018104800, end 00000000192843e0, bouncebuffer ffffffffffffffff
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 0 run 125150 exit 1
Jumping to boot code at 0000000018104800(00000000f7eda000)
CPU0: stack: 00000000ff8ec000 - 00000000ff8f0000, lowest used address 00000000ff8ef3d0, stack used: 3120 bytes
CBFS: 'VBOOT' located CBFS at [402000:44cc00)
CBFS: Locating 'fallback/bl31'
CBFS: Found @ offset 10ec0 size 8d0c
Loading segment from ROM address 0x0000000000100000
code (compression=1)
New segment dstaddr 0x10000 memsize 0x40000 srcaddr 0x100054 filesize 0x8192
Loading segment from ROM address 0x000000000010001c
code (compression=1)
New segment dstaddr 0xff8d4000 memsize 0x1f50 srcaddr 0x1081e6 filesize 0xb26
Loading segment from ROM address 0x0000000000100038
Entry Point 0x0000000000010000
Loading Segment: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x0000000000010000 memsz: 0x0000000000040000 filesz: 0x0000000000008192
using LZMA
[ 0x00010000, 00035708, 0x00050000) <- 00100054
Clearing Segment: addr: 0x0000000000035708 memsz: 0x000000000001a8f8
dest 0000000000010000, end 0000000000050000, bouncebuffer ffffffffffffffff
Loading Segment: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
lb: [0x0000000000300000, 0x0000000000320558)
Post relocation: addr: 0x00000000ff8d4000 memsz: 0x0000000000001f50 filesz: 0x0000000000000b26
using LZMA
[ 0xff8d4000, ff8d5f50, 0xff8d5f50) <- 001081e6
dest 00000000ff8d4000, end 00000000ff8d5f50, bouncebuffer ffffffffffffffff
Loaded segments
INFO: plat_rockchip_pmusram_prepare pmu: code d2bfe625,d2bfe625,80
INFO: plat_rockchip_pmusram_prepare pmu: code 0xff8d4000,0x50000,3364
INFO: plat_rockchip_pmusram_prepare: data 0xff8d4d28,0xff8d4d24,4648
NOTICE: BL31: v1.2(debug):
NOTICE: BL31: Built : Sun Sep 4 22:36:16 UTC 2016
INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO: plat_rockchip_pmu_init(1189): pd status 3e
INFO: BL31: Initializing runtime services
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x18104800
INFO: SPSR = 0x8
Change-Id: Ie2484d122a603f1c7b7082a1de3f240aa6e6d540
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8c1d75bff6e810a39776048ad9049ec0a9c5d94e
Original-Change-Id: I2d60e5762f8377e43835558f76a3928156acb26c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376849
Original-Commit-Ready: Simon Glass <sjg@google.com>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16706
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Some of the asserts for valid clock divisor ranges were off by one. This
patch corrects them and writes them all in a consistent way.
BRANCH=None
BUG=None
TEST=Booted Kevin.
Change-Id: I81749408a40822100797f1734f3b88987d12d8d5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e09cdfde26700496aaa1fc41489f63a355e8a89d
Original-Change-Id: I429edb99e2d5ff2302d9750e6569b3d21f5686fa
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381574
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/16704
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
SPI read speed directly impacts boot time and we do quite a lot of
reading.
Add a way to easily find out the speed of SPI flash reads within
coreboot.
Write speed is less important since there are very few writes and they
are small.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=run on gru with SPI_SPEED_DEBUG set to 1. See the output messages:
read SPI 627d4 7d73: 18455 us, 1740 KB/s, 13.920 Mbps
Change-Id: Id3814bd2b7bd045cdfcc67eb1fabc861bf9ed3b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 82cb93f6be47efce3b0a3843bab89d2381baef89
Original-Change-Id: Iec66f5b8e3ad62f14d836a538dc7801e4ca669e7
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376944
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16701
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add lpddr3-K4E6E304EB-2GB-1CH memory configuration for rialto.
BUG=chrome-os-partner:56759
BRANCH=none
TEST=Build
Change-Id: I698fe450d48b64a06232aa44ecf91d688d9dc17a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d3edecdb135939c3264ab1b831e7821d3a3e0149
Original-Change-Id: I7dae9fd822abeff5b08de0ab9262e1817ac58531
Original-Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/380443
Original-Commit-Ready: Alexandru Stan <amstan@chromium.org>
Original-Tested-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: Jonathan Dixon <joth@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16699
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch moves the big CPU cluster initialization on the RK3399 from
the clock init bootblock function into ramstage. We're only really doing
this to put the cluster into a sane state for the OS, we're never
actually taking it out of reset ourselves... so there's no reason to do
this so early.
Also cleaned up the interface for rkclk_configure_cpu() a bit to make it
more readable.
BRANCH=None
BUG=chrome-os-partner:54906
TEST=Booted Kevin.
Change-Id: I568b891da0abb404760d120cef847737c1f9e3ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bd7aa7ec3e6d211b17ed61419f80a818cee78919
Original-Change-Id: Ic3d01a51531683b53e17addf1942441663a8ea40
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/377541
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16698
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Gale EVT3 has only one LED controller (earlier we had 2).
Remove the support for the second controller and also the
corresponding microcode. The color values used are the same
as onHub (Arkham to be specific).
BUG=b:30890905
TEST=Move the device to different states manually by appropriate
actions (like dev mode, rec mode etc) and observe the different
colors.
BRANCH=None
Change-Id: I853035610ea7ea7c8d29c30d2de13c9e2e786b2b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 593905d2d69daa7482318aa5f5c5cd7cf984043e
Original-Change-Id: If8f22abd605faac6f6215ef600041740ce15ea0c
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/370821
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16697
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Move the setup of the IRQ status handler so it will be set up properly
before the early probe happens.
BUG=chrome-os-partner:53336
Change-Id: I4380af1233d2a252899459635a3cb69ca196088d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16861
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Due to different LCD panel requirements the delay between LVDS becomes
active and the backlight is switched on needs to be increased to 500 ms.
Change-Id: I09029624469aef412141c7b46224d48557ba4af1
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/16875
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
At higher SPI bus speeds the SPI RX value is not available in time for
sampling at the normal time. Add a delay to ensure that we read the
correct data.
The value of 40ns is chosen arbitrarily. In my testing I can use a sample
delay of 1 even at 24MHz. But since it is not necessary, I have left that
case alone. It kicks in at 25MHz and up.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see no change at current speed
Change-Id: I3ef335d9a532eaef1e76034bd02e185acf11176a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9b620c47fc3e39211487507fadb8657afdebee7
Original-Change-Id: I65d66d752cbbbee4d02f475de23a52069a0e9782
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381311
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16707
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Several of the special function pins we're using in firmware have a
pre-assigned pull-up or pull-down on power-on reset. We don't want those
to interfere with any of the signaling we're trying to do on those pins,
so this patch disables them.
Also do some house-cleaning to group the bootblock code better, and
change the setup code for all SPI and I2C buses to first initialize the
controller and then mux the pins... I assume this might be a little
safer (in case the controller peripheral has some pins in a weird state
before it gets fully initialized, we don't want to mux it through too
early).
BRANCH=None
BUG=chrome-os-partner:52526
TEST=Booted Kevin.
Change-Id: I4d5bd3f7657b8113d90b65d9571583142ba10a27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f8f7fd56e945987eb0b1124b699f676bc68d0560
Original-Change-Id: I6bcf2b9a5dc686f2b6f82bd80fc9a1a245661c47
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/382532
Reviewed-on: https://review.coreboot.org/16711
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This patch fixes a typo in the clock initialization code that caused the
PERILP1_PCLK_HZ constant to be ignored and the clock to always run at
the same speed as its parent (PERILP1_HCLK_HZ). Since we've done all our
previous tests and validation with this bug, we should probably increase
the value of the constant (that had not actually been used) to the value
that we had been incorrectly using instead (which also makes effective
SPI read times faster).
BRANCH=None
BUG=chrome-os-partner:56556
TEST=Booted Kevin.
Change-Id: Ibeb08f5fe5e984a74e3f57e60c62d4bfb644b6ca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 06e605a5fcb9bdf13a3d301112380633b892fd4e
Original-Change-Id: Icb5e079f53eb22b0dbf0ea4d1c2ff08688e3fa8e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381031
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/16703
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Increase the SPI bus speed to speed up boot time. The maximum supported
speed at 1.8V is 37.5MHz, and 33MHz is the next lowest convenient speed,
given the clock parents.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see that things still work correctly. Total time
spent on reading from SPI reduces from 185ms to 141ms.
Change-Id: I71436c9e343b18360fa63d528dea5cfcfbc831e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d7576f6e53e407af61160be142c3d589e864a8cf
Original-Change-Id: I55a19f523817862e081d23469e94fd795456dd67
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381313
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16708
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Output GPIOs should never have a pull-up or pull-down resistor attached
since they're actively driven. Since some GPIOs get initialized with a
pull at power-on reset, we should explicitly overwrite that setting.
Most other platforms do this on gpio_output, but Rockchip hadn't yet.
Also, shuffle some code around to make things cleaner and allow for
easier code reuse.
BRANCH=None
BUG=chrome-os-partner:52526
TEST=Booted Kevin.
Change-Id: I1425d074ea1e90f4484e1e84a8002b057192c5f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: df5b236bfd58b172435043c1cb792b917a4ec4ab
Original-Change-Id: I044266d71ef8bd0518316ff72d829d1ca1e30f35
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/382531
Original-Reviewed-by: Simon Glass <sjg@google.com>
Reviewed-on: https://review.coreboot.org/16710
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
If we setup the PWM _after_ the pinmux then there's a period of time
when we're driving the PWM incorrectly. Let's setup the regulator and
_then_ configure the pinmux.
This fixes no known bugs, but it is more correct and probably makes the
signals look better at bootup.
BRANCH=None
BUG=None
TEST=scope
Change-Id: I311c0eded873b65e0489373e87b88bcdd8e4b806
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fcf4d0ba29d82cce779c0b25ead36de4a95d97a1
Original-Change-Id: I5124f48d04a18c07bbd2d54bc08ee001c9c7e8d1
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381592
Original-Reviewed-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16700
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
As far as I know, the Cortex-A53 cores in RK3399 are of a newer revision
that is not affected by ARM erratum 843419. If it was, the workaround
would also need to be enabled in libpayload and Chrome OS userspace,
which it currently isn't. I assume this was just incorrectly copied over
from another SoC and we can safely remove it.
BRANCH=None
BUG=chrome-os-partner:56700
TEST=Booted Kevin.
Change-Id: I5b1534c954a6d985499b481738723cabbdc07253
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4891cc866583532ee3dcb1a5ad5b81670eb0743d
Original-Change-Id: Iadb57428f8727ce0e563204723644e2c79e3007c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376363
Original-Commit-Queue: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16702
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The datasheets on gm45: "Mobile Intel® 4 Series Express Chipset Family"
mention the possibility of having 352M ram preallocated for the
integrated graphic device. This only worked fine if the amount of ram in
the system was 3GB or less. When 4G or more is installed, memory is
remapped to create a 1GB large pci mmio hole which is not enough and
creates conflicts when 352M vram is used.
This patch increases the pci mmio hole size on Lenovo x200 to allow
352M vram to work.
TEST: build and flash on target with 4GB ram or more, use nvramtool to
set gfx_uma_size to 352M and reboot.
Change-Id: I5ab066252339ac7d85149d91b09a9eaaaab3b5b6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16831
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Kconfig symbols of type bool are ALWAYS defined, so this code was
always being included and run, which isn't what the author wanted.
Change to use IS_ENABLED(), and a regular if() instead of an #ifdef.
Change-Id: I72623fa27e47980c602135f4b73f371c7f50139b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Everybody knows WHAT they're supposed to do with options, so the text
"Pick this" or "Select to" are redundant.
Change-Id: I327c5be755373e99ca0738593bd78e1084d4d492
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16838
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The AGESA_BINARY_PI_LOCATION Kconfig symbol was declared as a string.
Change it to a hex value.
Change-Id: Ifd87b6c8dfcdf950aea9b15a6fea45bb72e8b4e9
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16835
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Kconfig hex values don't need to be in quotes, and should start with
'0x'. If the default value isn't set this way, Kconfig will add the
0x to the start, and the entry can be added unnecessarily to the
defconfig since it's "different" than what was set by the default.
A check for this has been added to the Kconfig lint tool.
Change-Id: I86f37340682771700011b6285e4b4af41b7e9968
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16834
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
On resume, TPM2_Starup(STATE) command needs to be sent to the TPM. This
ensures that TPM restores the state saved at last Shutdown(STATE).
Since tlcl_resume and tlcl_startup both use the same sequence for
sending startup command with different arguments, add a common function
that can be used by both.
BUG=chrome-os-partner:58043
BRANCH=None
TEST=Verified that on resume coreboot no longer complains about index
read for 0x1007. Return value is 0 as expected.
Change-Id: Ib8640acc9cc9cdb3ba5d40e0ccee5ca7d67fa645
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16832
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Revert commit 53552cc0 (Drop SuperIO nuvoton/nct6776),
removing the code as no other mainboard uses it.
The board Intel Saddle Brook uses this device, so add the
code back with minor adaptations.
Change-Id: I546879285ad8336e81798d0fbdf94f72e1fa61a2
Signed-off-by: Teo Boon Tiong <boon.tiong.teo@intel.com>
Reviewed-on: https://review.coreboot.org/16519
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The microcode for the BSP gets loaded early from the fit table, but in
case we have newer microcode in cbfs, try to load it again from cbfs.
BUG=chrome-os-partner:53013
TEST=Boot and verify that microcode tries to load into the BSP.
Change-Id: Ifd6c78d7b0eec333b79e0fe5cb6a81981b078f5d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16829
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Replace the use of the old device_t definition inside
southbridge/broadcom/bcm5785.
Change-Id: I091b07439ff918efa52cf8f8270484131fd0cec5
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16690
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/via/cn700.
Change-Id: Ib7761697daad3c459f3568e5158f925199bcd919
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16689
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
cpu/amd/model_fxx.
Change-Id: Iac7571956ed2fb927a6b8cc88514e533f40490d0
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16437
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
mainboard/biostar/am1ml.
Change-Id: Iba2fff5617c62152355b54e446517ad36108aa31
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/16688
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch increases the CPU specific passive temp. trip point
and critical temp. trip point value for DPTF policy.
BUG=chrome-os-partner:57903
TEST=Built, booted on reef and verified this passive and
critical temp. trip points with heavy workload.
Change-Id: I2a38d01a6539c1bd478f8716c4b543ebcd1f2080
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/16766
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Venkateswarlu V Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
For all mainboard variants use the "Google_Reef" family by default
which is populated in SMBIOS tables. A variant can provide their own
value if needed, but "Google_Reef" can reside as the family without
having to add conditions for each variant when MAINBOARD_FAMILY
have to be overridden.
BUG=chrome-os-partner:56677
Change-Id: Ic214eae1e6473b32f4cb442c09c34355357e1257
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16813
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
These default values weren't being set with the default
keyword so were ending up with different values.
from the default generated config file before this change:
CONFIG_DRIVER_TPM_I2C_BUS=0x9
CONFIG_DRIVER_TPM_I2C_ADDR=0x2
CONFIG_DRIVER_TPM_I2C_IRQ=-1
Change-Id: I19514d0c9b2a9b7e479f003a4d3384e073f4d531
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16828
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Because these variables had "non-hexidecimal" defaults, they
were updated by kconfig when writing defconfig files.
Change-Id: Ic1a070d340708f989157ad18ddc79de7bb92d873
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16827
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
A copy of our uart8250io driver sneaked in with Broadwell-DE support.
The only difference is the lack of initialization (due to FSP handling
that).
TEST=manually compared resulting object files
Change-Id: I09be10b76c76c1306ad2c8db8fb07794dde1b0f2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/16786
Tested-by: build bot (Jenkins)
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add PCI device id to native graphic init and add the Native graphic init
option in Kconfig.
Change-Id: I136122daef70547830bcc87f568406be7162461f
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16512
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This reuses the Intel Pineview native graphic initialization
to have output on the VGA connector of i945 devices.
The behavior is the same as with the vendor VBIOS BLOB.
It uses the external VGA display if it is connected.
Change-Id: I7eaee87d16df2e5c9ebeaaff01d36ec1aa4ea495
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16511
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The code to compute n, m1, m2, p1 divisors is not correct in coreboot and
on some targets hits a working mode at lower refresh rate, which is why
display is working on some targets.
The divisors must be such "refclk * (5 * (m1 + 2) + (m2 + 2))/ (n + 2)
/ (p1 * p2)" is as close as possible to the target frequency (which
is defined by the resolution and refresh rate).
This patch also fixes the reference frequency.
This patch reuses linux (4.1) code from drivers/gpu/drm/i915/intel_display.c
to correctly compute divisors.
The result is that some previously not working displays, like many
displays found on the Lenovo T60 might work now.
Some examples of T60 displays that were known to not work (in payload):
Samsung LTN141XA-L01 (14.1" 1024x768)
LG-Philips LP150X09 (15.1" 1024x768)
IDtech N150U3-L01 (15.1" 1600x1200)
IDtech IAQX10N (15.1" 2048x1536)
Samsung LTN154X3-L0A (15.4" 1280x800)
LG-Philips LP150E06-A5K4 (15.1" 1400x1050)
Tested on T60 with 1024x786.
Change-Id: I2c7f3bb0024ac005029eaebe3ecdc70c38ac777e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16504
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Function which invoked when TPM clear is requested was left empty,
this patch fixes it.
BRANCH=gru
BUG=chrome-os-partner:57411
TEST=verified on a chromeos device that tpm is in fact cleared when
CLEAR_TPM_OWNER_REQUEST is set by userland.
Change-Id: I4370792afd512309ecf7f4961ed4d44a04a3e2aa
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/16805
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Switch from FSP 1.1 to FSP 2.0 as the default build.
BRANCH=none
BUG=None
TEST=Build and run on Galileo Gen2
Change-Id: Icbb3a36cdde68baf4d68fbfc371f8847c56e1162
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16810
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Fix errors in debug display support.
BRANCH=none
BUG=None
TEST=Build FSP 2.0 (SEC/PEI core with all FSP debug on) and run on
Galileo Gen2
Change-Id: I2ece056d66dc8568a7b7206970f20368ec5bf147
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16809
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Fix the build issues with FSP 2.0:
* Remove struct from the various data structures.
* Properly display the serial port UPDs.
* Change chipset_handle_reset parameter type
BRANCH=none
BUG=None
TEST=Build FSP 2.0 (SEC/PEI core with all FSP debug off) and run on
Galileo Gen2
Change-Id: Icae578855006f18e7e5aa18d2fd196d300d0c658
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16808
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add support for multiple versions of FSP.
BRANCH=none
BUG=None
TEST=Build FSP 1.1 (SEC/PEI core, with all FSP debug off) and run on
Galileo Gen2
Change-Id: Ie7e7f0f883c4d3bfcb18fa25571e505cdde00b2d
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16807
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add Kconfig values to select the FSP setup:
* FSP version: 1.1 or 2.0
* Implementation: Subroutine or SEC/PEI core based
* Build type: DEBUG or RELEASE
* Enable all debugging for FSP
* Remove USE_FSP1_1 and USE_FSP2_0
Look for include files in vendorcode/intel/fsp/fsp???/quark
BRANCH=none
BUG=None
TEST=Build FSP 1.1 (subroutine) and run on Galileo Gen2
Change-Id: I3a6cb571021611820263a8cbfe83e69278f50a21
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16806
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
pcm205401 is CPU board equipped with T40R of AMD. We used SeaBIOS and
Windows Embedded Standard 7 to test pcm205401.
In comparison to pcm205400, only VGA PCI ID is changed and board
identifier strings in SMBIOS / DMI.
Change-Id: I6c7e90db84f13ffbf9e629f2b92649895a466155
Signed-off-by: Yuichi Ito <yui.corebt@gmail.com>
Reviewed-on: https://review.coreboot.org/15930
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
pcm205400 is CPU board equipped with T56N of AMD. We used SeaBIOS and
Windows Embedded Standard 7 to test pcm205400. I disable the port5,
6, and 7 of the PCI-e in elmex/pcm205400/PlatformGnbPcieComplex.h.
I disable the audio capabilities at the 236th line of
elmex/pcm205400/platform_cfg.h. Coding style is modified to avoid the
error and warning that occur when I commit.
Change-Id: I77cb76903fe3c1b500a306426f5399936382695b
Signed-off-by: Yuichi Ito <yui.corebt@gmail.com>
Reviewed-on: https://review.coreboot.org/15929
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add the 'probed' flag to the touchpad and touchscreen devices so they
are probed by the kernel before being loaded, in case they do not exist
or are replaced with another vendor.
BUG=chrome-os-partner:57686
Change-Id: I0a61964e6874cd99fab0c21fa404a43548fc8ab5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16743
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a config option to the generic I2C device driver to indicate to
the OS that this device should be probed before being added.
This can be used to provide ACPI device instantiations to devices that
may not actually exist on the board. For example, if multiple trackpad
vendors are supported on the same board they can both be described in
ACPI and the OS will probe the address and load the driver only if the
device responds to the probe at that address.
BUG=chrome-os-partner:57686
Change-Id: I22cffb4b15f25d97dfd37dc58bca315f57bafc59
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16742
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
A dedicated pmc_ipc DSDT entry is required for pmc_ipc kernel driver.
The ACPI mode entry includes resources for PMC_IPC1, SRAM, ACPI IO and
Punit Mailbox.
BRANCH=None
BUG=chrome-os-partner:57364
TEST=Boot up into OS successfully and check with dmesg to see the
driver has been loaded successfully without errors.
Change-Id: I3f60999ab90962c4ea0a444812e4a7dcce1da5b6
Signed-off-by: Zhao, Lijian <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/16649
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Intel telemetry support will require PMC IPC1 and SRAM devices to be
operated in ACPI mode. Then using fixed resources on BAR0, BAR1
and BAR2 (PMC only) for those two devices will help
the resource assignment in DSDT stage.
BUG=chrome-os-partner:57364
BRANCH=None
TEST=Boot up into Chrome OS successfully and check with dmesg to see
the driver has been loaded successfully without errors.
Change-Id: I8f0983a90728b9148a124ae3443ec29cd7b344ce
Signed-off-by: Zhao, Lijian <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/16648
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Compilation (w/o native raminit) fails due to missing include
Change-Id: Ic79a77006257b32e0181c88c4e24d7c1f5c5f7ce
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/16735
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use the GOOG ACPI ID until there is an official ID allocation
for coreboot. Since I administer this range I allocated
0xCB00-0xCBFF for coreboot use.
Change-Id: I38ac0a0267e21f7282c89ef19e8bb72339f13846
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16724
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This generates a fake VBT for the Intel i945 graphic device. i945
supports both the mobile chipset 945gm (calistoga) and the desktop
chipset 945gc (lakeport), which is why a VBT with a different id string
needs to be created for each target.
The VBT id string is obtained from the vbios blob in the following way:
"strings vbios.bin | grep VBT".
Change-Id: I8245b12b16a4426efbe1f584d4163fc257231a98
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16530
Tested-by: build bot (Jenkins)
Reviewed-by: Damien Zammit <damien@zamaudio.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Padding the VBT id string is now done automatically.
Change-Id: I8f9baf7b1585026bc29b82d07e451aa11e284ffb
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16740
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The VBT id string is 20 characters long.
If the string is shorter than 20 it needs spaces at the end.
This change is cosmetic as all strings were padded by hand.
Change-Id: Id6439f1d3dbd09319ee99ce9d15dbc3bcead1f53
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16739
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Add a header file to provide common declarations that the
mainboards can use regarding EC init.
BUG=chrome-os-partner:56677
Change-Id: Iaa0b37eff4de644e969a18364713b90b7f27fa1c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16734
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Tested-by: build bot (Jenkins)
Instead of relying on the mainboards to provide their own LID0
ACPI device, provide the infrastructure so that the mainboards
can signal to the EC ASL code to provide the default lid switch
implementation.
BUG=chrome-os-partner:56677
Change-Id: Ie43b1c4f8522db1245f1f479bfdb685d3066121d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16732
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Instead of having each mainboard provide the power button,
uncondtionally provide the power button ACPI device on behalf
of each mainboard.
BUG=chrome-os-partner:56677
Change-Id: I94c9e0353c8d829136f0d52a356286c6bedcddd5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16731
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The mainboard is not being worked on anymore, not available outside of
Intel and thus has litle practical use. Remove mainboard code completely.
Change-Id: Ic2c7ea3810ee70afc01a42786f8ccba9313134e4
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/16725
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Lijian Zhao <lijian.zhao@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Initialize the PCNT variable in GNVS so it is available to ACPI code
that expects to know the number of CPUs.
Change-Id: I7a6e003ac94218061bf98e8883ed2c62d856af8d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
All systems are building with IASL warnings as errors enabled.
Remove the option to disable it.
Remove the notification at the end of the build.
Change-Id: I5c6218c182fdf173b4026fd010d939a5fa36040e
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16606
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some changes were made in upstream in the meantime that broke the build:
- CHROMEOS_VBNV_CMOS was renamed to VBOOT_VBNV_CMOS
- recovery_move_enabled() -> vboot_recovery_mode_enabled()
- chromeos.asl was replaced by an acpi generator
Change-Id: Icd4ed5111cce9db79e12efb0cb7e898bba725c20
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16683
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Migrate google/enguarde (Lenovo N21 Chromebook) from Chromium tree to
upstream, using google/rambi as a reference.
original source:
branch firmware-enguarde-5216.201.B
commit cf1f57b [Enguarde: Adjust rx delay for norm.]
TEST=built and booted Linux on enguarde with full functionality
blobs required for working image:
VGA BIOS (vgabios.bin)
firmware descriptor (ifd.bin)
Intel ME firmware (me.bin)
MRC (mrc.elf)
external reference code (refcode.elf)
Change-Id: I3ccda29d1e095d8b1b36766cda913172f72233a7
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/15444
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Enable the cr50 TPM and interrupt as GPE0_DW1_28 for use during
verstage. The interrupt is left in APIC mode as the GPE is
still latched when the GPIO is pulled low.
BUG=chrome-os-partner:53336
Change-Id: Ib0247653bdcbaccb645cd16b81d7ec3c38f669af
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16673
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Support reading the ACPI GPE status (on x86) to determine when
the cr50 is ready to return response data or is done processing
written data. If the interrupt is not defined by Kconfig then
it will continue to use the safe delay.
This was tested with reef hardware and a modified cr50 image
that generates interrupts at the intended points.
BUG=chrome-os-partner:53336
Change-Id: Ic8f805159650c45382cacac8840450a1f8b4d7a1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16672
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Implement the generic acpi_get_gpe() function to read and clear
the GPE status for a specific GPE.
Tested by watching GPE status in a loop while generating interrupts
manually from the EC console.
BUG=chrome-os-partner:53336
Change-Id: I482ff52051a48441333b573f1cd0fa7f7579a6ab
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16671
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Initialize the GPEs from mainboard config in bootblock, so they
can be used in verstage to query latched interrupt status.
I still left it called in ramstage just to be sure that the
configuration was not overwritten in FSP stages.
Tested by reading and reporting GPE status in a loop in verstage
and manually triggering an interrupt on EC console.
BUG=chrome-os-partner:53336
Change-Id: Iacd0483e4b3229aca602bb5bb40586eedf35a6ea
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16670
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a function that can be implemented by the SOC to read
and clear the status of a single GPE. This can be used
during firmware to poll for interrupt status.
BUG=chrome-os-partner:53336
Change-Id: I551276f36ff0d2eb5b5ea13f019cdf4a3c749a09
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16669
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Unify the function names to be consistent throughout the driver
and improve the handling while waiting for data available and
data expected flags from the TPM.
BUG=chrome-os-partner:53336
Change-Id: Ie2dfb7ede1bcda0e77070df945c47c1428115907
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16668
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Clean up the mask and timeout handling in the locality functions
that were copied from the original driver.
BUG=chrome-os-partner:53336
Change-Id: Ifdcb3be0036b2c02bfbd1bcd326e9519d3726ee0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16667
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Rename the low-level functions from iic_tpm_read/write to
cr50_i2c_read/write to better match the driver name, and pass in the
tpm_chip structure to the low-level read/write functions as it will
be needed in future changes.
BUG=chrome-os-partner:53336
Change-Id: I826a7f024f8d137453af86ba920e0a3a734f7349
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16666
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use two different timeouts in the driver. The 2ms timeout is needed
to be safe for cr50 to cover the extended timeout that is seen with
some commands. The other at 2 seconds which is a TPM spec timeout.
BUG=chrome-os-partner:53336
Change-Id: Ia396fc48b8fe6e56e7071db9d74561de02b5b50e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16665
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reduce the static buffer size from the generic default 1260
down to 64 to match the max FIFO size for the cr50 hardware
and reduce the footprint of the driver.
BUG=chrome-os-partner:53336
Change-Id: I6f9f71d501b60299edad4b16cc553a85391a1866
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Originally I thought it would be cleaner to keep this code in one
place, but as things continue to diverge it ends up being easier
to split this into its own driver. This way the different drivers
in coreboot, depthcharge, and the kernel, can all be standalone
and if one is changed it is easier to modify the others.
This change splits out the cr50 driver and brings along the basic
elements from the existing driver with no real change in
functionality. The following commits will modify the code to make
it consistent so it can all be shared with depthcharge and the
linux kernel drivers.
BUG=chrome-os-partner:53336
Change-Id: I3b62b680773d23cc5a7d2217b9754c6c28bccfa7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16663
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the common enums and variables to tpm.h so it can be
used by multiple drivers.
BUG=chrome-os-partner:53336
Change-Id: Ie749f13562be753293448fee2c2d643797bf8049
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16662
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These values are found in util/cbfstool/cbfs.h.
Change-Id: Iea4807b272c0309ac3283e5a3f5e135da6c5eb66
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In preparation for making this check optional, move it into its own
function. load_self_segments() is already long and we don't want to make
it longer.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=boot on gru and see that BL31 loads and runs correctly
Change-Id: If48d2bf485a23f21c5599670e77a7b8b098f1a88
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 2381e02efa2033857ac06acbc4f0c0dd08de1080
Original-Change-Id: I005e5e4d9b2136605bdd95e9060655df7a8238cb
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381092
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16585
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tidy up a few things which look incorrect in this file.
BUG=chrome-os-partner:56314
BRANCH=none
TEST=build for gru
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 434e9ceb5fce69b28de577cdc3541a439871f5ed
Original-Change-Id: Ida7a62ced953107c8e1723003bcb470c81de4c2f
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376848
Original-Commit-Ready: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Change-Id: If8c283fe8513e6120de2fd52eab539096a4e0c9b
Reviewed-on: https://review.coreboot.org/16584
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In kernel side we set 1.1v for 1.5G, even for coreboot RO,
a higher voltage could be safer, 1.2v now seems too high.
BRANCH=none
BUG=chrome-os-partner:56948
TEST=bootup
Change-Id: I852e0d532369aad51b12770e2efb01aacf6662ce
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 000b5c099373be2a1f83c020ba23a0e79ea78fab
Original-Change-Id: Iecc620deee553c61a330353ac160aa3a36f516df
Original-Signed-off-by: Shunqian Zheng <zhengsq@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/380896
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16583
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The SPI driver is quite slow at reading data. For example, with a 24MHz
clock on gru it achieves a read speed of only 13.9Mbps.
We can correct this by reading the status registers once, then reading as
many bytes as are available before checking the status registers again. It
seems likely that a status register read requires synchronizing with the
SPI FIFO clock domain, which takes a while.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=run on gru and see the speed increase from 13.920 Mbps to 24.712 Mbps
Change-Id: I24aed0c9c6c5445634c4e056922afaee4e9a7b33
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 49c2fc20d7d7d703763e9b0a6f68313a349a84b9
Original-Change-Id: I42745f01f0fe069f6ae26d866004d36bb257e6b2
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376945
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16582
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This enhances gradation of some icons on vboot screens.
BUG=chrome-os-partner:56056
BRANCH=none
TEST=Booted Jerry
Change-Id: Ia19d585b69e7701040209e8bf0b8a6990a166c95
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 4e7a42c999673ebd89c5b30845a4a5ec93852166
Original-Change-Id: I126cb7077c834e1a8b0a625a592dce8789b5876c
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376884
Reviewed-on: https://review.coreboot.org/16581
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We did yet another small adjustment to the PWM regulator ranges for
Kevin rev6... this patch reflects that in code. Also rewrite code and
descriptions to indicate that these new ranges are not just for Kevin,
but also planned to be used on Gru rev2 and any future Gru derivatives
(which as I understand it is the plan, right?).
BRANCH=None
BUG=chrome-os-partner:54888
TEST=Booted my rev5, for whatever that's worth...
Change-Id: Id78501453814d0257ee86a05f6dbd6118b719309
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 4e8be3f09ac16c1c9782dee634e5704e0bd6c7f9
Original-Change-Id: I723dc09b9711c7c6d2b3402d012198438309a8ff
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/379921
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16580
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This enhances gradation of some icons on vboot screens.
BUG=chrome-os-partner:56056
BRANCH=none
TEST=Booted kevin-tpm2
Change-Id: I2fc943f89386ccc6cd9293f5811182a5a51d99b0
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: bb1f0fb00d023c045305edc6c9fc655b764a4e8c
Original-Change-Id: Ieb61830b9555da232936087cdcf7c61a1e55bab4
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376883
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16579
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds support to reboot the whole board after a hardware
watchdog reset, to avoid the usual TPM issues. Work 100% equivalent to
Veyron.
From my tests it looks like both SRAM and PMUSRAM get preserved across
warm reboots. I'm putting the WATCHDOG_TOMBSTONE into PMUSRAM since that
makes it easier to deal with in coreboot (PMUSRAM is currently not
mapped as cached, so we don't need to worry about flushing the results
back before reboot).
BRANCH=None
BUG=chrome-os-partner:56600
TEST='stop daisydog; cat > /dev/watchdog', press CTRL+D, wait 30
seconds. Confirm that system reboots correctly without entering recovery
and we get a HW watchdog event in the eventlog.
Change-Id: I317266df40bbb221910017d1a6bdec6a1660a511
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 3b8f3d064ad56d181191c1e1c98a73196cb8d098
Original-Change-Id: I17c5a801bef200d7592a315a955234bca11cf7a3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/375562
Original-Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16578
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This improves the previous linear search to O(log n). No change in
storage format.
BUG=chromium:640656
BRANCH=none
TEST=Manual
(test empty)
flashrom -i RW_NVRAM -e
Reboot; device should boot normally.
(start using records)
crossystem kern_nv=0xaab0
crossystem recovery_request=1 && reboot
Device should go into recovery mode with reason 1
Reboot again; it should boot normally.
crossystem kern_nv (should still contain 0xaab0)
Repeat steps several times with request=2, 3, etc.
flashrom -i RW_NVRAM -r nvdata
Modify nvdata to copy the first record across all valid
records
flashrom -i RW_NVRAM -w nvdata
Reboot; device should boot normally.
Change-Id: Ieb97563ab92bd1d18a4f6a9e1d20157efe311fb4
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: db9bb2d3927ad57270d7acfd42cf0652102993b1
Original-Change-Id: I1eb5fd9fa6b2ae56833f024bcd3c250147bcc7a1
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376928
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16577
Tested-by: build bot (Jenkins)
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Enable the cr50 TPM and interrupt as GPE0_DW1_28 for use during
verstage. The interrupt is left in APIC mode as the GPE is
still latched when the GPIO is pulled low.
BUG=chrome-os-partner:53336
Change-Id: I28ade5ee3bf08fa17d8cabf16287319480f03921
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Support reading the ACPI GPE status (on x86) to determine when
the cr50 is ready to return response data or is done processing
written data. If the interrupt is not defined by Kconfig then
it will continue to use the safe delay.
This was tested with reef hardware and a modified cr50 image
that generates interrupts at the intended points.
BUG=chrome-os-partner:53336
Change-Id: I9f78f520fd089cb4471d8826a8cfecff67398bf8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Implement the generic acpi_get_gpe() function to read and clear
the GPE status for a specific GPE.
Tested by watching GPE status in a loop while generating interrupts
manually from the EC console.
BUG=chrome-os-partner:53336
Change-Id: Id885e98d48c2133a868da19eca3360e2dfb82e84
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Initialize the GPEs from mainboard config in bootblock, so they
can be used in verstage to query latched interrupt status.
I still left it called in ramstage just to be sure that the
configuration was not overwritten in FSP stages.
Tested by reading and reporting GPE status in a loop in verstage
and manually triggering an interrupt on EC console.
BUG=chrome-os-partner:53336
Change-Id: I1af3e9ac1e5c59b9ebb5c6dd1599309c1f036581
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Add a function that can be implemented by the SOC to read
and clear the status of a single GPE. This can be used
during firmware to poll for interrupt status.
BUG=chrome-os-partner:53336
Change-Id: I536c2176320fefa4c186dabcdddb55880c47fbad
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Unify the function names to be consistent throughout the driver
and improve the handling while waiting for data available and
data expected flags from the TPM.
BUG=chrome-os-partner:53336
Change-Id: I7e3912fb8d8c6ad17d1af2d2a7189bf7c0c52c8e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Clean up the mask and timeout handling in the locality functions
that were copied from the original driver.
BUG=chrome-os-partner:53336
Change-Id: Ifa1445224b475aec38c2ac56e15cb7ba7fcd21ea
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Rename the low-level functions from iic_tpm_read/write to
cr50_i2c_read/write to better match the driver name, and pass in the
tpm_chip structure to the low-level read/write functions as it will
be needed in future changes.
BUG=chrome-os-partner:53336
Change-Id: Ib4a68ce1b3a83ea7c4bcefb9c6f002f6dd4aac1f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Use two different timeouts in the driver. The 2ms timeout is needed
to be safe for cr50 to cover the extended timeout that is seen with
some commands. The other at 2 seconds which is a TPM spec timeout.
BUG=chrome-os-partner:53336
Change-Id: I77fdd7ea646b8b2fef449f07e3a08bcce174fe8b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Furquan Shaikh