This change sets up the list of source files for vboot2's
verstage without enabling it.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=not much testing yet, just successful compilation.
Change-Id: I4052c20795459bf0e057c0f0952226ea4a8c89f1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 48847ab8acfbe4b33d61d3d012c72c025cd8f364
Original-Change-Id: I1d7944e681f8a4b113a90ac028a0faba4423be89
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234643
Reviewed-on: http://review.coreboot.org/9684
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With introduction of uber-sbl SRAM usage pattern is changing, this
introduces the new memory layout.
This patch overlays DDR initialization code with uber-sbl, as uber-sbl
goes out of scope as soon as bootblock starts.
A 4K block at offset 0x3f000 added in the comments, this is a shared
structure used by different QCA modules.
This suggested layout is not final, but will allow to move closer to
the production image.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=with other patches applied Storm boots all the way to rombase and
initializes DRAM.
Change-Id: I46af81b39b09935aa7fffdabda223e7e64c7a446
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a20c0570361038c0ae406dcb1f4bc657eea120f6
Original-Change-Id: I927f6ffc524fc8f0effd7b91d3f5d1e8d6be1530
Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229023
Reviewed-on: http://review.coreboot.org/9683
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
LPAE (large physical address extension) is not available on this SOC
core, do not enable it.
[pg: we already had this one, but somehow LPAE slipped in again]
BUG=chrome-os-partner:27784
TEST=coreboot still comes up on AP148
Change-Id: Iaa80022c611f7377d8f4100487d32654150836d8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e6e12c39efd54e4fcbd444134bf30e211948a71b
Original-Change-Id: I9e9ad1aeaf613f04987c0c306a574085042d0e7b
Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.com>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198023
Original-Reviewed-by: deepa dinamani <deepad@quicinc.com>
Reviewed-on: http://review.coreboot.org/9682
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The gpio access code has been moved to a separate file to match other
platforms. Accessor functions are added to read different switches
state. They will be read by verstage, when it is enabled, and by
ramstage, for passing the values to depthcharge.
It is unfortunate that the gpio values are not being cached and can
change by the time CBMEM table is filled, but we have to live with
that for now.
BUG=chrome-os-partner:33756,chrome-os-partner:34161
BRANCH=storm
TEST=none yet.
Change-Id: I229fed0e35d643912f929671d5fc25aee5d1d167
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7e15aa281a1dbf2c463650b6c04991436022d8d4
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I940b54cd3cf046b94d57d59d370e634a70a8bbeb
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229426
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9681
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- These should be 64bit values so when they try to return -1
it is interpreted properly by the kernel.
- The GPE value needs to be reset at the start so it does not
return stale data from a previous resume.
- If a GPE register is zero the value should only be updated
if it has not yet found a set bit.
BUG=chrome-os-partner:34532
BRANCH=samus,auron
TEST=build and boot on samus, suspend/resume with various
wake sources and ensure the reported _SWS values are correct
in every case.
Original-Change-Id: Ic6897f20ad2f321f3566694c032b75a3db120556
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235012
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit be3c79b87b81563f744eb885708a52730debaccb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I801c6e4f90dde0f5f69685f987a9831ee5e99e4a
Reviewed-on: http://review.coreboot.org/9699
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This code that stores the initial timestamp is not being used,
instead the timestamp is passed to romstage_main().
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Original-Change-Id: I0e0fa1ba74ab93d4454fdfa12208e712d2ae913c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234402
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
(cherry picked from commit 838112cf79e2b4d51e5dc87d5ac9cd7e03807f29)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8fd7ba72c14c1e39f7bfa3a1ae8d03289a2abf73
Reviewed-on: http://review.coreboot.org/9698
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to avoid a 300ms timeout waiting for mbp_cleared flag
to be set there is a new flow for the ME10 1.5MB firwmare that
we can follow which will save significant boot time.
This requires sending new commands that do not generate an ACK
message, and ensuring an HMRFPO LOCK message is sent.
In addition now that the delay is removed clean up the ME path
to do the work in init() step and add a final() step that does
the disabling of the PCI device.
BUG=chrome-os-partner:30637,chrome-os-partner:34134
BRANCH=samus,auron
TEST=build and boot on samus, measure ~300ms speedup in boot time
Original-Change-Id: I753087ecd65f6ebed9f812318a359f893e01da9f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234400
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 25aff4b188dc94a99af30869a162e01e3fa8dee7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia35373548a902a718155a1a57057f55067d2f3ac
Reviewed-on: http://review.coreboot.org/9697
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove the blobs from the coreboot tree and get them from
3rdparty.
Change-Id: I0798091530be9654d7e073839b4efeb3f9c0302c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9694
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Remove the blobs from the coreboot tree and get them from
3rdparty.
Change-Id: I4938b5c47e6ae7059eda144b664aeafdd674f0fb
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This patch adds a new "backlight" output GPIO to the coreboot table in
order to avoid redundantly defining that GPIO in the payload.
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Tested together with corresponding depthcharge CL.
Change-Id: Ia997beb1a400136ad65d8f0217781c9782f6e8a5
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 04ce4c23573cf926aeef3d817d3ab00835f897c7
Original-Change-Id: I69b3c7ac6be4b9723b6a0dfecef5e1c4ea681aff
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242400
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9652
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
LDO4 and LDO5 are not turned on with the boot0 and boot1 RK808
strappings that we use on Brain.
BUG=none
BRANCH=none
TEST=built and booted on brain
Change-Id: I00393ca54958d9fff926606405edcd84901e4048
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c4c1862585fd058a8a9c8237c701b3bbf3b8aa83
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I846ef9d67a780cc07414d545524b9ec0b8490cf1
Original-Reviewed-on: https://chromium-review.googlesource.com/241734
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9648
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Danger has EDP, the original code was copied from Brain which
didn't.
BUG=none
BRANCH=none
TEST=built and booted on danger
Change-Id: Ib8e48078cc51fe0e1fb7049f70e810b8f0a7690a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 25fc6b4d82fb4bd80798cc809af4dacc6208109e
Original-Change-Id: Ic8b3f685e08bb96125c57d42db6a10e348a1a096
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/245161
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9679
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This applies the differences between Brain and Danger:
- Danger has an SDMMC slot
- Danger has a USB hub (TODO)
- Danger has LVDS (TODO)
- Add workaround for incorrect RAM_ID strapping
BUG=none
BRANCH=none
TEST=emerge-veyron_danger coreboot works
Change-Id: Idec527744de2583613b290e3e88850b33ff1c23d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 89278c2eeae4bae989a3549da627c5bbd5dd0d5a
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Iae3f85d4f41e04465a5046f2334c693337d006a4
Original-Reviewed-on: https://chromium-review.googlesource.com/241712
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9647
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds a directory with files copied over from Brain along with
build-related changes so that emerge-veyron_danger works. The next
patch will account for other differences.
BUG=none
BRANCH=none
TEST=emerge-veyron_danger coreboot works
Change-Id: I7ebd431cd48e257dfa761d32013d0e251b4f155d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a0f7d2f96540df6fdcd7a99d9e0fa02bbc6c1f73
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Id265a7715f07a647a449f00097bf40f7c9b4c068
Original-Reviewed-on: https://chromium-review.googlesource.com/241711
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9646
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
decode_edid() parses the whole EDID buffer, regardless of whether there
is an extension buffer, so we pass the size of the EDID actually read to
prevent EDID parser getting the wrong data.
BUG=chrome-os-partner:35053
TEST=Boot from jerry
BRANCH=veyron
Change-Id: I5951b670f129cf4765a5199cb58ac6abff5478a6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4d508647efc0a9d48b2a4b23c12a54b63af2813e
Original-Change-Id: I8cd8e09025520322461fe940b01e4af3995b5ecd
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/240643
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9645
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds RTC functions to the existing RK808 driver.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=with eventlog patches applied to pinky, booted and saw eventlog
entries generated with correct timestamps:
localhost ~ # mosys -k eventlog list
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Change-Id: I1df70a2ca94ff463ffea8d9f02d951d6c62e6b08
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a304f7e6954f585f04feef54c4902dcb25a39fcc
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I3a240e342a54b2e7023da71708d0d70f5131f0b9
Original-Reviewed-on: https://chromium-review.googlesource.com/238525
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9643
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This moves PMIC_BUS from each mainboard's board.h file to a per-
mainboard Kconfig variable. To prevent humans from forgetting to
set a valid value, an invalid default is set in the rk3288 Kconfig
and checked in rk808.c so that compilation will fail if the mainboard
Kconfig does not override it.
Originally, PMIC_BUS was only used by mainboard code as an argument
to RK808 PMIC functions. To conform to the generic RTC API, however,
the RK808 code needs to have the bus number globally defined somewhere
since the rtc_get() and rtc_set() functions don't take any args.
Since CONFIG_PMIC_BUS is globally visible, we no longer need to pass
bus number to the PMIC functions.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I73783878e507b2e7b1526dd2f81cfbdf8f1e2a55
Reviewed-on: https://chromium-review.googlesource.com/240203
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9642
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This patch implements support for the CRYPTO module in RK3288 and ties
it into the new vboot vb2ex_hwcrypto API. We only implement SHA256 for
now, since the engine doesn't support SHA512 and it's very unlikely that
we'll ever use SHA1 for anything again.
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed that it uses the hardware crypto engine and
that firmware body hashing time dropped to about 1.5ms (from over 70ms).
Change-Id: I91d0860b42b93d690d2fa083324d343efe7da5f1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e60d42cbffd0748e13bfe1a281877460ecde936b
Original-Change-Id: I92510082b311a48a56224a4fc44b1bbce39b17ac
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236436
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9641
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
BRANCH=None
TEST=emerge-veyron_speedy coreboot
BUG=None
Change-Id: Iab377e93472db0b7778df020afa84ee97f0e4079
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: fedf6ed7dc220d58ad10d49ac9ea02443746e77e
Original-Change-Id: Id5024bfd32a0aa1fb00f3af8dc337ccccaf40729
Original-Signed-off-by: Jiazi Yang <Tomato_Yang@asus.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/237544
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Trybot-Ready: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9640
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
BUG=None
TEST=emerge veyron_speedy and boot the Speedy board
BRANCH=None
Change-Id: Ida5fd6d839a2e704760a90e9c723c1b688ea6a84
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 42c0d11c3ec65874986c06ca4d7b34f5987f9409
Original-Change-Id: I2f0cff74517a8c031eabb64f4f82d455195c8dd1
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234715
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9639
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This applies the differences between Jerry and Brain:
- No EC
- No SD card
- Minor changes to GPIOs (no lid, power button active low)
- No variations between board IDs (yet)
- No backlight/display attached, but we do have some HDMI
and VOP configuration (need to double check that it's right).
BUG=none
BRANCH=none
TEST=built and booted on Brain (requires follow-up CL
to get into depthcharge)
Change-Id: Idbbc19856e05a145637c28d87c3e19855d13f03b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 67151129c28ca7dd83464e5a5c183d006299293c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I3c761d3d4d186a6208a772c05193bdcbd4a5c105
Original-Reviewed-on: https://chromium-review.googlesource.com/235921
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9638
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds a directory with files copied over from Jerry, in addition to
build system related changes (configs/* and Kconfig stuff) necessary
to emerge-veyron_brain coreboot.
The next patch will account for differences between Jerry and Brain.
BUG=none
BRANCH=none
TEST=emerge-veyron_brain coreboot works
Change-Id: Ib0da9caf80f46991b96bcb5756f807237f0902e1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 9509d6277dae25a78062c1301054a39f704b33fe
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I972f2623d9b0a43e3ea5312b3c4cd34ab44edc36
Original-Reviewed-on: https://chromium-review.googlesource.com/236989
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9637
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This BCT table is the same as "ramcode == 1", and has been pass the stress
test with this new Micron type.
-Micron MT41K256M16LY-107:N, ramcode = 4
BUG=chrome-os-partner:32071
TEST=emerged coreboot, booted successfully into kernel.
Change-Id: I80990fec6faf5dd2b8090658d865cc8dde31b753
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: bce2bf1fd518077e06d70d78a65d58ddef7b7bc6
Original-Change-Id: I2c0b28fdafb5299784519e641aa4edb53d0c36b2
Original-Signed-off-by: Neil Chen <neilc@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/236514
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9636
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Due to a missing i2c_init(), we were actually running our TPM with
default divisors at 660KHz. Oops.
While it's commendable that both the TPM and our controller seem to have
been running fine all this time at more than 1.5 times the maximum
frequency they support, we should probably still get that fixed.
Also sync Speedy back up to the other Veyron boards since it seems to
have missed a recent SDMMC patch.
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I255c66624b21bf48b12f950208ba2c401a75c4e4
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f2bd7c8579cd90d2f800c777c1981557d81a9b49
Original-Change-Id: I43e6b5fe02aca605a5b243c5b876bd44b90b2bf9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236580
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9634
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This switches all the rk3288 platforms to use the common CBFS wrapper
instead of implementing its own CBFS media driver. It also happens
that veyron_* platforms use Gigadevice SPI flash (at least for now).
As we use more SPI-related stuff, for example eventlog and vboot data in
Brain's case, we will need to use more of the SPI API anyway. This
prevents us from having to duplicate pieces of it for rk3288.
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Change-Id: Ie462456814646fdc277485d9e2d8c901fd4936e7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2d6df2fe6d78bc8eee8689019b9aaf29c82b6b30
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Id307bd5fb6cc8f79411d8c66e1370e80c58d017b
Original-Reviewed-on: https://chromium-review.googlesource.com/235882
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9678
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
BUG=None
TEST=emerge veyron_mighty and boot the Mighty board
BRANCH=None
Change-Id: I0047569c9eed7a3881500ba3b05e6726ba8d7b8f
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 49366e5bb3ecdec38c898c936392e5d77a91cd53
Original-Change-Id: I3fcdc837e8d7e62c145850f549662d8260aa1120
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234714
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9633
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
BUG=None
TEST=emerge veyron_jerry and boot the Jerry board
BRANCH=None
Change-Id: I38cb0106694ada431e6ab6194fce7ba1822bcbcf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6a061072860f74874f0098062806c01bdcb447bd
Original-Change-Id: I6eb0900516bcd95159c472749c54d356448d2344
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234713
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9632
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
BUG=None
TEST=emerge veyron_pinky and boot the Pinky board
BRANCH=None
Change-Id: I75bc1b7681c9a3d7dc2868a2b260884538587dbd
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 66069927618924af02a4e17503fa49ae2c31fdfc
Original-Change-Id: I06242ade0cabbba56b16b3832a1b4b09bec6f06b
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234712
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9631
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
We use the devicetree to pass the backlight control gpio before,
but if there have different board version, and it uses different
io to control backlight, it will hard to distinguish it. So, we
move the backlight control to mainboard, and use board_id
to distinguish the backlight control.
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: Ifa81eb2455296f4b4285b681208f4393f266fb34
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2ff7f65134dcf97f97757750eab41dcf8c7765d3
Original-Change-Id: I1ec8e04f4982c3a8c7e31d8dc2c75311b7199ffc
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234711
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9630
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Like Nyan, Veyron boards use a GPIO to reset the system so that we can
make the accompanying TPM reset secure and unforgeable. The normal
kernel reboot driver knows that, but the SoC-internal watchdog doesn't.
This patch implements a check for the global reset status register in
the early bootblock and triggers a hard_reset() when it matches "first
global watchdog reset" or "second global watchdog reset". Seems that
the difference between the two is is a choice controlled by
wdt_glb_srst_ctrl (unconfirmed), and we want this code to run in both
cases.
BRANCH=None
BUG=chrome-os-partner:33141
TEST=Run 'mem w 0xff800000 0x9' from the command line, watch how you end
up in recovery without this patch but can boot normally with it.
Change-Id: Ice79648831e1e97d22325711da9e82bbf6bf3c75
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 5d7cb52b2c2dcb2fff0bf83fc168439dade4b1b7
Original-Change-Id: I2581bde84f0445c15896060544e9acb60de91c8c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231734
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9629
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Add the Samsung-4GB and Hynix-4GB LPDDR inc files.
Use ram_id 1000 correspond to Samsung-4GB LPDDR
and use ram_id 1001 correspond to Hynix-4GB LPDDR.
BUG=chrome-os-partner:33269
TEST=Boot veyron_speedy normal
BRANCH=None
Change-Id: I21983c48e1e99aa70ae9bb3fb6550ae9af472015
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: d34b19dc9b57b4f31dc1b28581f3f8fc0fcc7e6b
Original-Change-Id: I55b6968c642df8c1f579e518232ab5d278e7e12f
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233859
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9628
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Essentially a copy of veyron_jerry for now
BUG=chrome-os-partner:33269
TEST=emerge-veyron_speedy coreboot
BRANCH=None
Change-Id: If8f32122e301df1766bca68b11efd8afe8be5e87
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f49a151e1dd956ed2cf3ba0b1f9307442b61e639
Original-Change-Id: Ife457db4fd67fe69bcd4082694b3372eccfb304b
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233822
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9627
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The only way to reliably reset an SD card in an unknown state is by
power-cycling. Since a kernel may crash and reboot at any point, SD
cards may be left in one of them fancy high-throughput modes that
depthcharge (or, in fact, a newly booting kernel without prior
knowledge) doesn't support, so we need to reset the card on every boot.
This patch adds support to turn off an RK808 regulator completely and
uses that to turn off SD card power rails in early romstage. The time
until configure_sdmmc() in ramstage turns them back on should be more
than enough to drain the power rail for an effective power-cycle.
BRANCH=None
BUG=chrome-os-partner:34289
TEST=Booted a Pinky from SD card, noticed that it works before and
after this patch.
Change-Id: Iaa5f7adaa59da69a964785c5e369ad73c6620224
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 95fba21907f1f3f686cb5a95b993736247db8f96
Original-Change-Id: I904b2d23ca35f765c000f9bee7637044f674eff9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233713
Original-Reviewed-by: Alexandru Stan <amstan@chromium.org>
Original-Tested-by: Alexandru Stan <amstan@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9626
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This function was added in upstream but was missing in Chromium OS
Change-Id: I35debf65153e5f280343eebfe91438ecf665ba22
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9677
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Commit 54229a7 (arm: Fix checkstack() to use correct stack size) didn't
quite hit the mark. Due to the crazy way our Kconfig includes work, It
accidentally set CONFIG_STACK_SIZE to 0 even on architectures that need
it.
This patch fixes the issue by moving everything back to a single entry
in src/Kconfig, making sure we end up with the intended numbers on all
architectures.
BRANCH=None
BUG=chrome-os-partner:34750
TEST=Built for Pinky, Urara, Falco and Ryu. Confirmed that the generated
.config contained CONFIG_STACK_SIZE=0x0 for the former two, and
CONFIG_STACK_SIZE=0x1000 for the latter.
Original-Change-Id: Ib18561925aafe7c74e6c4f0b10b55000a785e144
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236753
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit c64b127e163f98162f3f7195b6ed09bd5a4b77c4)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I2c747b04760bc97f43523596640bfb15317e5730
Reviewed-on: http://review.coreboot.org/9696
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Tested-by: build bot (Jenkins)
Coreboot is designed to have a single serial console at most, on top
of that it may have a CBMEM (virtual) console. Matters are complicated
by the fact that console interface is different between bootblock and
later stages.
A linker list of console driver descriptors is used to allow to
determine the set and type of console drivers at compile time. Even
though the upstream seems to have done away with this approach, which
does not seem the best idea.
As an alternative this patch introduces a common wrapper which
different UART drivers can plug in into. The driver exports a single
API which can be used both directly (in bootblock) and through the
wrapper (in later stages).
The existing drivers can be adjusted to fit this scheme one by one.
The common UART driver API also aligns fine with the upstream
approach.
BUG=chrome-os-partner:27784
TEST=none yet
Original-Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196660
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 94a36ad79a96f83d283c0fd073b05f98ae48820c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id1fe73d29f2a3c722bd77180beebaedb9bf7d6a1
Reviewed-on: http://review.coreboot.org/7872
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The ethernet switch, as soon as it is taken out of reset comes up in
default (bridging) mode, which allows traffic to flow freely across
the ports.
Let's keep it in reset such that there is no cross port traffic
happening while the device boots up.
BRANCH=storm
BUG=chrome-os-partner:32646
TEST=verified that the switch is held in reset during boot.
Change-Id: Ia1dbb47d892d564145da17425a596bf9bad40d29
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 50551d8c9a44d1b63e0948070f6573adf7729d37
Original-Change-Id: I6bf698beddc98ce18fee6b3b39622e356c8cfbad
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224989
Original-Reviewed-by: Toshi Kikuchi <toshik@chromium.org>
Reviewed-on: http://review.coreboot.org/9465
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This adds the TPM device to the devicetree and configures an
active high edge triggered interrupt at IRQ10 and adds the ACPI
Device for the TPM into the DSDT.
It also cleans up the EC PNP ID to use the EISAID for an EC since
there are now two PNP devices declared, and removes the unused
ENABLE_TPM define at the top of the DSDT.
BUG=chrome-os-partner:33385
BRANCH=samus
TEST=build and boot on samus, ensure TPM is functional at IRQ10
CQ-DEPEND=CL:226661
Change-Id: I4b9b016014d136fbf9a37003003632821ae93a53
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 0420e27b05d0f1568efa9beb849e0e8ff5995c86
Original-Change-Id: I2660cb30ac535da0b255603a619b9c09681ca947
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226663
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9471
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is not a standard feature so it should be included by the
mainboard if it is actually present in a system.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=build and boot on samus
CQ-DEPEND=CL:226663, CL:226664
Change-Id: Id4d0e5ed243dcb95e64fb8c848667f651b75aa4e
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8909913f5c11c5805c77a3373859634b02a301e2
Original-Change-Id: Ib7c171a5a007a2dddfb3d80341c6dc488e383e99
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226662
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9470
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Since CL:226662, all TPMP accessing should be removed as well,
else it will cause wtm2 coreboot failed on build.
BUG=none
BRANCH=none
TEST=./setup_board --board=fox_wtm2 && emerge-fox_wtm2 coreboot
CQ-DEPEND=CL:226662
Change-Id: Ib25f2d32997ef82b0ebf049803f2c5002a0a3abf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c99456bf42544518e2a36b6e0bbfe7f4ee1b4aff
Original-Change-Id: Ia0eebb1924bbb23979c880f7d05600a0cf1e4ca3
Original-Signed-off-by: Harry Pan <harry.pan@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/232165
Original-Reviewed-by: Wei Shun Chang <wei.shun.chang@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9477
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This change is made only to make sure there is a good
signal strength on the SPIM lines.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; works properly
BRANCH=none
Change-Id: I5b9427b14a407746fb5b707fa3b07a1a6774bfb1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e9d953283a5b43bf967128ca73db0e90c2df32df
Original-Change-Id: Ia589134cf0557613697d49fb0bdb1848af66f0e8
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/249732
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9675
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; I2C0 clock is
set up properly.
BRANCH=none
Change-Id: I15ffc5f7d8e8aadfc3cd249284bc492d0d13d9a1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6404ab6ad12ea1579eaf5ae55a9eddd9bd9f96e2
Original-Change-Id: Iafdf492291b47f0088f3b5e621d630b8d21ab106
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/250450
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9673
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The current MIPS PLL is configured in such a way that there is
excessive jitter. Correct this by applying new PLL settings. The
resultant frequency is 546MHz instead of 550MHz.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board as part of the JTAG
loading script;
BRANCH=none
Change-Id: Ica1bfff29e01819b86cd2bb8b18d8adc9dfa3260
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 0c04354b49b73d234492521d81b6600d487175b0
Original-Change-Id: I28b41b1e82dbdf9da21bf0ab74f9722cdad923f1
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245620
Original-Reviewed-by: James Hartley <james.hartley@imgtec.com>
Original-Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: http://review.coreboot.org/9671
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The base address used was TOP CLOCK control address instead of
the PERIPH CLOCK CONTROL. That was incorrect and is fixed with
the current patch.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; now the hash accelerator,
fed by this clock, is correctly clocked at 200MHz.
BRANCH=none
Change-Id: I0ead3951dc1dfc872881b8d1ae9b63f8104af50d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 871cb50ca43a6c760f346eb447e8ff102d8ca0b6
Original-Change-Id: I198d64f97a85a6fcf00c3853bf23d2d767e0e631
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245313
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9670
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:31438
TEST=tested in Pistachio bring up board; previous delay
at the beginning of bootblock is fixed.
BRANCH=none
Change-Id: I30335677c96bfd651bc49e36b562c48588009d67
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3d1eb117644af1323dd940e0a82a2ef44025d5b9
Original-Change-Id: I122df1f985163836bb2ddd027ef6ab2ce265d5dd
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243223
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9668
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some of the asserts were not done properly: the value has
to be shifted before is matched with the mask.
Added condition to exit while loop for USB clock setup.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; after this patch is
applied none of the asserts fail and the code is executed
properly.
BRANCH=none
Change-Id: Ib3aae9f7751a9f077bc95b6e0f9d63e3e16d8e4b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 96999a4322ba98e87bc6746ad05b30cc56704e2e
Original-Change-Id: I8d2d468d618ca1ffcb1421409122482444e6d420
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243214
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9667
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the added code for clock and MFIOs setup, bootblock
now exceeds 16KB. This patch increases the allowed limit
to 18KB.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; works as expected
BRANCH=none
Change-Id: I166f882bd3db446bcd6f9e1f828cab22266c6ac7
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: da95db5ed348419b7905dc1ab68fd64d7b2eb5e0
Original-Change-Id: I0cacc6163f21ae3673c2716b12dde66bd48290f9
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243213
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9665
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As the payload increases in size, a bigger CBFS cache is required.
Therfore, bootblock, romstage and the cbfs cache were placed in
GRAM (128 K) and the stack and cbmem console were moved to
SRAM (64 K). With the exception of CBFS cache, the sizes of all
the other regions remains the same.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA and bring up board;
behavior was as expected.
BRANCH=none
Change-Id: I19857f785ca1514f7483d582c7ad6ee470a8fefc
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c895660dbdcd113bdc9d832beab30886313c28d6
Original-Change-Id: I004f8f081d04f83e3f5cee969e50803685cfdf67
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/236551
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9664
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When using this mode data is received and transmitted on the same
edge of the SPFI clock, which allows for higher frequencies of
operation. In this mode the maximum supported frequency is 50Mhz.
If this mode is not enabled the maximum supported frequency is
25Mhz.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; the SPFI hardware block is
fed by the system clock (with a fixed freqency of 400 MHz).
To achieve the SPFI frequency of 50MHz the internal divider of
SPFI must be set to 64. To achieve a frequency of 25 Mhz the
internal divider must be set to 32.
A value of 64 = division by 8
A value of 32 = division by 16
BRANCH=none
Change-Id: Ifd5f739b6157b99e4c1f92b5bb72615ee610ae6c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8b6cce616ec7926682d4eff096563acf1dfd6c65
Original-Change-Id: I337b6fcf462bcf6021ca77a8b1133cf49140ba76
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241425
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9663
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Set elements:
- UART1 clock dividers and MFIOs
- SPIM1 clock dividers and MFIOs
- USB clock dividers
- System clock divider
- System PLL
- MIPS CPU PLL
BUG=chrome-os-partner:31438
TEST=tested on Pisachio bring up board; UART, SPI NOR, SPI NAND, and USB
have proper functionality.
BRANCH=none
Change-Id: Ib01186a652fd59295a4cafc3ca99b94aa9564f74
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 65e68d82f34bb40ef3cfb397ecf5df0c83201151
Original-Change-Id: Ia2c31bbbfc020dc4fd71c72b877414adfdfc42a8
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241423
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9662
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The GPU MMU won't function properly until it sees the VPR
is locked down. Therefore, do the appropriate work.
BUG=None
BRANCH=None
TEST=Built.
Change-Id: I6011c75c1e6c231f2fa416e0057cb5805a88a2bb
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: ca9cc9917b98a148442468d1d1541a0408ab6c2c
Original-Change-Id: I3601f419b561cee392391577ef8db66b9fbd8c1b
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242910
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: http://review.coreboot.org/9660
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add and call display shift clock divider function to set shift clock
divider.
This change is also intended for code sharing on dc settings.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and rush
Change-Id: I9ad1b32de50395720355bb2d00f5800c7f6c4b73
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 24a72fa3411652d54ae1f7d69db0a7293aad7877
Original-Change-Id: I01582c6863d31627ac93db9fddda93f4f78249cd
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238943
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9614
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
DP panel parameters generally can be retrieved thru edid. The parameters
specified here will be used when edid fetching failed.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build rush and ryu
Change-Id: I39e25c873561f75394408f6635aaa2e88b67d846
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c02facb9753de08f66f3ae40d7dca1eba50febc5
Original-Change-Id: I4785eca3ec03b48e8780ebf02389e9b46317e96d
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238941
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9612
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add these parameters so that they can be specified in devicetree.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and rush
Change-Id: I77ee16263e1ce6a8c32b3cd203c1b8a499514a8e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c3b254936e696f81ca7eeeb7f6968a5350352b59
Original-Change-Id: Iba47afe95c3889047a82582730be7a253fae76e7
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9611
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
checkstack() runs at the end of ramstage to warn about stack overflows,
and it assumes that CONFIG_STACK_SIZE is always the size of the stack to
check. This is only true for systems that bring up multiprocessing in
ramstage and assign a separate stack for each core, like x86 and ARM64.
Other architectures like ARM and MIPS (for now) don't touch secondary
CPUs at all and currently don't look like they'll ever need to, so they
generally stay on the same (SRAM-based) stack they have been on since
their bootblock.
This patch tries to model that difference by making these architectures
explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to
assume the whole (_estack - _stack) area in checkstack() instead. Also
adds a BUG() to the stack overflow check, since that is currently just
as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM
HALTED" output) but a little more easy to spot. Such a serious failure
should not drown out in all the normal random pieces of lower case boot
spam (also, I was intending to eventually have a look at assert() and
BUG() to hopefully make them a little more useful/noticeable if I ever
find the time for it).
BRANCH=None
BUG=None
TEST=Booted Pinky, noticed it no longer complains about stack overflows.
Built Falco, Ryu and Urara.
Change-Id: I6826e0ec24201d4d83c5929b281828917bc9abf4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 54229a725e8907b84a105c04ecea33b8f9b91dd4
Original-Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235894
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9610
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Freeing up memory on rk3288 is like squeezing water out of a stone right
now, but I still managed to get a few drops here and there. Let's hope
this will be enough.
BRANCH=None
BUG=None
TEST=Pinky builds and boots again. memsz is ~15K in bootblock and ~39K
in verstage.
Change-Id: Icf7ff3369bf367426a34f1490e0a041ae9bd6367
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9a3737ab535cdef228a1607433860f881db04412
Original-Change-Id: I90d9eab5b5d3af7a2e4b836a9c7b735b7c1c48e6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235870
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9609
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa
Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234063
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9608
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I87914df3c72f0262eb89f337454009377a985497
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c
Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232614
Reviewed-on: http://review.coreboot.org/9607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: I1b064ba3831c0c5b7965b1d88a6f4a590789c891
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ffaebcd3785c4ce998ac1536e9fdd46ce3f52bfa
Original-Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234062
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9606
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Non-x86 boards currently need to hardcode the position of their CBFS
master header in a Kconfig. This is very brittle because it is usually
put in between the bootblock and the first CBFS entry, without any
checks to guarantee that it won't overlap either of those. It is not fun
to debug random failures that move and disappear with tiny alignment
changes because someone decided to write "ORBC1112" over some part of
your data section (in a way that is not visible in the symbolized .elf
binaries, only in the final image). This patch seeks to prevent those
issues and reduce the need for manual configuration by making the image
layout a completely automated part of cbfstool.
Since automated placement of the CBFS header means we can no longer
hardcode its position into coreboot, this patch takes the existing x86
solution of placing a pointer to the header at the very end of the
CBFS-managed section of the ROM and generalizes it to all architectures.
This is now even possible with the read-only/read-write split in
ChromeOS, since coreboot knows how large that section is from the
CBFS_SIZE Kconfig (which is by default equal to ROM_SIZE, but can be
changed on systems that place other data next to coreboot/CBFS in ROM).
Also adds a feature to cbfstool that makes the -B (bootblock file name)
argument on image creation optional, since we have recently found valid
use cases for CBFS images that are not the first boot medium of the
device (instead opened by an earlier bootloader that can already
interpret CBFS) and therefore don't really need a bootblock.
BRANCH=None
BUG=None
TEST=Built and booted on Veyron_Pinky, Nyan_Blaze and Falco.
Change-Id: Ib715bb8db258e602991b34f994750a2d3e2d5adf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9879c0fbd57f105254c54bacb3e592acdcad35c
Original-Change-Id: Ifcc755326832755cfbccd6f0a12104cba28a20af
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229975
Reviewed-on: http://review.coreboot.org/9620
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71
Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9619
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
src/ec/google/chromeec/ec_lpc.c: In function ‘google_chromeec_command_v3’:
src/ec/google/chromeec/ec_lpc.c:88:3: error: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘unsigned int’ [-Werror=format=]
printk(BIOS_ERR, "EC cannot send %ld bytes\n",
^
cc1: all warnings being treated as errors
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Change-Id: I0d47350f00102a959d54a64b8f932099fc13f886
Reviewed-on: http://review.coreboot.org/9558
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Files necessary for the SOC bringup are added to the CBFS as raw
blobs.
Ipq8064 specific MBN header will allow to determine were the blobs
should be loaded and what start address should be used.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=build storm firmware and verify that the right components are added:
$ emerge-storm coreboot chromeos-bootimage
$ cbfstool /build/storm/firmware/image.bin print
image.bin: 8192 kB, bootblocksize 32488, romsize 2883584, offset 0x7f40
alignment: 64 bytes, architecture: arm
Name Offset Type Size
cdt.mbn 0x7f40 raw 376
ddr.mbn 0x8100 raw 25820
rpm.mbn 0xe640 raw 78512
tz.mbn 0x21940 raw 85360
fallback/verstage 0x36700 stage 39500
fallback/romstage 0x401c0 stage 15652
fallback/ramstage 0x43f40 stage 24328
config 0x49e80 raw 2701
fallback/payload 0x4a940 payload 65592
u-boot.dtb 0x5a9c0 (unknown) 2922
(empty) 0x5b580 null 2509336
$
Change-Id: I967cd20364c90a1ef7add959621992c2356f158d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6b5238d47da417b8b1993ad3348f4c32381cd0e4
Original-Change-Id: Id642ae68ef07750624f85b31ad891752d8af99bf
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233672
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9577
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The first blob in the Storm bootimage is a concatenation of the
Uber-sbl produced by the qca-firmware ebuild and the coreboot
bootblock.
The new tool is used to add the bootblock to uber-sbl and update the
size values in the combined header.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=no execution tests yet, the build succeeds.
Change-Id: I4f1fe8a97ffab04eee4f82bc43e6f5406dd9bb42
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a126a62f65a568d62fe35bdcf27eaec38fd1a997
Original-Change-Id: Iec3c1e943f1f9ee5ca20320a6365fc4aa5516e38
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232310
Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9573
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This provides the opportunity to remove the kludge of disabling caches
altogether in the bootblock.
[pg: originally, this commit also provided automatic cache management
after loading stages, ie. flush dcache, so code ends up in icache. This
is done differently in upstream, so it's left out here]
BUG=chrome-os-partner:34127, chrome-os-partner:31438
TEST=with this fix romstage, ramstage and payload are executed properly
BRANCH=none
Change-Id: I568c68d02b2cd9c1c2c9c1495ba3343c82509ccc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 95ab0f159cabf21fc100f371d451211e7d113761
Original-Change-Id: Iaf90b052073dd355ab9114e8dba9f5ef76188c94
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/232410
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9618
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The first 64 bytes of the framebuffer contain garbage after running
the option rom and after calling the VBE mode set with the flag to
clear the framebuffer.
Work around this issue by clearing the first 64 bytes in the framebuffer
in the broadwell graphics setup code after it executes the VBIOS.
BUG=chrome-os-partner:32771
BRANCH=samus,auron
TEST=build and boot on samus in dev mode, check for graphical corruption
Change-Id: I0381e32a5ea17e13c4ed598835999c12136418cf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f29c1b0b7c100cf290f82de671042823032f71c9
Original-Change-Id: I072bc913f7daea16e4861a7549e1b4ec85cde4cd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222676
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9464
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Some boards spread their timer implementation out in multiple files with
one function each for no discernable reason. Let's clean that up to make
things a little simpler to find.
BRANCH=None
BUG=None
TEST=Booted Pinky, compiled Daisy and Pit.
Change-Id: I8b543d1a0d9af37bde5433b0c9271d687b2404b2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 887765e1bd88d7aa49ad9a5e98b8831c10da6c10
Original-Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234061
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9601
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch doubles the ACLK peripheral clock for the PD_BUS power domain
to 297MHz, which is the closest to the maximum of 300MHz we can reach by
dividing GPLL. This frequency directly translates into SRAM speed, so
maximizing it has a huge impact on boot speed (especially with the lack
of SRAM caching).
BUG=chrome-os-partner:32987
TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed
that the (visibly) long signature verification times are nearly halved.
Change-Id: Iafa3044854a4058a7f885c775119d964a6295de4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c230585f4344d0eab4f8eeaa761869965f2da08a
Original-Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224524
Original-Trybot-Ready: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Commit 257aaee9e3a (arm: Add bootblock_mainboard_early_init() for
pre-console initialization) inadvertently moved the timer initialization
after console initialization for IPQ806x, which is apparently not a good
idea for this platform. This patch solves the issue by moving
init_timer() to bootblock_mainboard_early_init(), which is the new hook
explicitly provided to perform pre-console tasks.
BRANCH=None
BUG=None
TEST=Built and booted Storm with 257aaee9e reverted. Noticed that it was
already broken. Bisected coreboot and tracked down breakage to commit
a126a62f (ipq8064: use the new utility to build bootblock). Built and
booted successfully with this patch and a revert of a126a62f to confirm
that the bug in question here is fixed.
Change-Id: I4a3faa2aec8ff1fbbe6c389f1d048475aa944418
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 752d1f879f9bd841f18bd84842491f747458cf52
Original-Change-Id: Ie4aa2d06cb6fda6d5ff8dd5ea052257fb7b8a24b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233290
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9574
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this is a preparation for porting these drivers to coreboot. the code will be modified by the following patches.
BUG=chrome-os-partner:33647
BRANCH=ToT
TEST=None
Change-Id: I2baeed5b6130ace2515d6e28115f8d1008004976
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7c03a186a599be9d274c6fcdea1906529cc117d7
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I9f3428ef02d2ba15ae63c99b10fe0605dd595313
Original-Reviewed-on: https://chromium-review.googlesource.com/231461
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9582
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this is required to do early firmware selection using vboot2. actual
implementation can be done later.
BUG=chrome-os-partner:33755
BRANCH=ToT
TEST=Booted storm.
Change-Id: I8e9e168ea6fa3af149d5ad4ca51c5c9bba4d986d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 611c24773478c8c212d567bb4f2cb9a09898ddc8
Original-Change-Id: Idd1a1de4991a19902ffe45f01be89d47f4413779
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229425
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9581
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Until proper MIPS cache management is available it is necessary to
disable data and instruction caches, otherwise code placed in memory
stays in data cache and is not available for instruction fetched.
BRANCH=none
BUG=chrome-os-partner:31438,chrome-os-partner:34127
TEST=coreboot loading rombase and rambase now succeeds.
Change-Id: I4147e1325edc0b9bb951cd7ce18d5f104f3eaec0
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 93d5bfa1d01fbbabbabef33a22287ceeea28b15b
Original-Change-Id: Ib195ed6e5f08ccaa6bbe3325c2199171bfb63b88
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232191
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9569
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: Ia8ddd689a3bf09ed68f94907ea19d4d2ee874542
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/9594
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch uses the new bootblock_mainboard_early_init() hook to run the
UART pinmuxing on rk3288-based boards before initializing the console.
This allows us to get rid of the hacky second console_init() call in
bootblock_soc_init(). We can also simplify the pinmux selection a bit
since we know that a given board always uses the same UART (still keep
an assert around to be sure, though).
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky.
Change-Id: I3da8b0e4bd609f33cedd934ce51cb20b1190024b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: caabda8fc1ddb4805d86fd9a0d5d2f3cf738bfaf
Original-Change-Id: Ia56c0599a15f966d087ca39181bfe23abd262e72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231942
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9604
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On most platforms, enabling the console and exception handlers are
amongst the very first things you want to do, as they help you see
what's going on and debug errors in other early init code. However, most
ARM boards require some small amount of board-specific initialization
(pinmuxing, maybe clocks) to get the UART running, which is why
bootblock_mainboard_init() (and with it almost all of the actual
bootblock code) always had to run before console initialization for now.
This patch introduces an explicit bootblock_mainboard_early_init() hook
for only that part of initialization that absolutely needs to run before
console output. The other two hooks for SoC and mainboard are moved
below console_init(). This model has already proven its worth before in
the tegra124 and tegra132 custom bootblocks.
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Daisy, Storm and Ryu.
Change-Id: I510c58189faf0c08c740bcc3b5a654f81f892464
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f58e84a2fc1c9951e9c4c65cdec1dbeb6a20d597
Original-Change-Id: I4257b5a8807595140e8c973ca04e68ea8630bf9a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231941
Reviewed-on: http://review.coreboot.org/9603
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch makes some slight changes to the way bootblock_cpu_init() and
bootblock_mainboard_init() are used on ARM. Experience has shown that
nearly every board needs either one or both of these hooks, so having
explicit Kconfigs for them has become unwieldy. Instead, this patch
implements them as a weak symbol that can be overridden by mainboard/SoC
code, as the more recent arm64_soc_init() is also doing.
Since the whole concept of a single "CPU" on ARM systems has kinda died
out, rename bootblock_cpu_init() to bootblock_soc_init(). (This had
already been done on Storm/ipq806x, which is now adjusted to directly
use the generic hook.) Also add a proper license header to
bootblock_common.h that was somehow missing.
Leaving non-ARM32 architectures out for now, since they are still using
the really old and weird x86 model of directly including a file. These
architectures should also eventually be aligned with the cleaner ARM32
model as they mature.
[pg: this was already partly upstreamed. These are the remains.
Further cleanup is necessary and on the short-term TODO, but beyond
the scope of this commit]
BRANCH=None
BUG=chrome-os-partner:32123
TEST=Booted on Pinky. Compiled for Storm and confirmed in the
disassembly that bootblock_soc_init() is still compiled in and called
right before the (now no-op) bootblock_mainboard_init().
Change-Id: Idf655894c4fec8fce7d3348d3b3e43b1613b35db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 257aaee9e3aeeffe50ed54de7342dd2bc9baae76
Original-Change-Id: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231940
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9602
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Display configuration is board specific. The change here is preparing
for supporting other than dsi interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: Ied39d5d539d2be4983ab70976bffbe51fccba276
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 36be6b2e35c6246d5384d71b9ab9d4ddbf17764a
Original-Change-Id: I494a04f7d6c0dbad2d472f4c2cd0aabfb23b8c97
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234271
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9584
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
dc supporting functions can be used for other than dsi display
interfaces. This change is preparing for supporting sor display
interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: I8a310e188fae70d7726c4360894b392c4546e105
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a7ab7225e3419a0fd93894dbb9a959390f29945b
Original-Change-Id: Id14cbd89457cb91c23526927a432f4eb7cc6291b
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/234270
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9583
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This configures I2S1 and the codec MCLK muxes to pass the PCM
audio data to the RT5677 codec. Once depthcharge RT5677 codec
driver changes are in, audio 'beeps' should be heard on boot
(Ctrl-U / devmode/recmode).
BUG=chrome-os-partner:32582
BRANCH=none
TEST=Built and booted Ryu/A44.
Change-Id: I2143d544c75ee7e03ffc809561171920650e8d7d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 600c12ddf3543d2dcb47fd3e2f0704803dac5957
Original-Change-Id: Ib071bcb41fba8f6d628a386ed233ec84a54b0323
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233945
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9580
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With this change, audio 'beeps' are heard on boot if Ctrl-U is
pressed, or devmode/recmode is entered. I also tested via an
explicit call to VbExBeep in the kernel boot path. Note that
a couple of Rush CLs for depthcharge are needed for audio, too.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=as above. Built and booted Rush/Norrin64.
Change-Id: I43c65a4d11c5ab7b16289e19f3b42cfc0300ea7c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4a682fb2403f7c6d53e74bfa945481242577f6c3
Original-Change-Id: Ia37f077569afd806ce6574c4c58813fd7aca1644
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233671
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9579
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
After DDR PHY reset de-asserted, DLL automatically starts to
lock, and the lock time is maximum 5.12us. The output clock of
DLL supplies the clocks of DDR controller and PHY digital logic.
So before DLL lock, the clocks of DDR controller and PHY digital
logic are indeterminate. When programming DDR in the period of
DLL unlock, the programming maybe unstable because of the
indeterminate clocks. So we need wait for at least 5.12us after
de-asserting reset, then start to program DDR registers.
10us provide some safety margin.
BUG=chrome-os-partner:33148
TEST=I'm using the following command line test ok(15000 cycles).
"while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off;
do : ; done"
BRANCH=None
Change-Id: Ie7d615f5a2264c615c4b4413d6b828cd3d78cd2b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 54e1a439c0e29aaf4fc542ae756f7bb036ceaf3e
Original-Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0
Original-Signed-off-by: DaiLunXue <dlx@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/232894
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com>
Original-Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com>
Reviewed-on: http://review.coreboot.org/9578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Used for audio on Rush/Ryu. I2S1/DAP2 provides the audio
'stream' for the dev/rec mode 'beeps'.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=With follow-on CLs that make use of this support,
audio beeps (via VbExBeep) can be heard on Rush. Built
both Rush and Ryu OK.
Change-Id: Iea5559db4431e48001adbbce17fa0f3aaaf8387c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2bd701a5f4186e49739b25f4afd5000d5d9b4970
Original-Change-Id: Ia8c32303979f25300e22b5a14609d9d9d5ce3132
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233670
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9576
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Due to CL https://chromium-review.googlesource.com/231250,
depthcharge now detects gpio state based on gpio configurations
done by coreboot instead of redoing configuration at
depthcharge. However, PWR button and LID open pins have not
been configured in coreboot. So, add the missing code here.
Otherwise, TOT coreboot/depthcharge rush build can not load
in kernel.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build rush and test with pwr button press and lid switch
Change-Id: I7acc5e021fa769f68d4cbfd7202df325d4ea73c2
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a25dff24a2dcd33fcd15eb766432414af215c3ab
Original-Change-Id: I6c322cd987967920f236aae653294db079678408
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233322
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9575
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This CL makes slight changes to the ChromeOS-specific GPIO definitions
of Tegra and Rockchip boards to prepare them for new features in
depthcharge. It adds descriptions for the EC in RW and reset GPIOs,
changes the value Tegra writes into the (previously unused) 'port' field
to describe the complete GPIO information, and removes code to sample
some GPIOs that don't need to be sampled at coreboot time (to help
depthcharge detect errors and avoid using a stale value for something
that should always represent the current state).
BRANCH=None
BUG=None
TEST=None (tested together with depthcharge patches)
Change-Id: I3774979dbe7cacce4932c85810596d80e5664028
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: df295d0432fbf623597cf36ebb170bd4f63ee08d
Original-Change-Id: I36bb16c8d931f862bf12a5b862b10cf18d738ddd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231222
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9570
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
make *config was complaining about mainboards selecting a virtual
dev switch when CONFIG_CHROMEOS is not enabled.
While the long term cleanup should be to move the option out of
CONFIG_CHROMEOS and make it not be a user changeable option, this
approach is contained to vendorcode/ and gets rid of the warning.
Change-Id: Id090eb31d1307af7a0d1f9fbe641534dc24b24a9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9301
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some SPI controllers (like Imgtec Pistachio), have a hard limit on SPI
read and write transactions. Limiting transfer size in the wrapper
allows to provide the API user with unlimited transfer size
transactions.
The tranfer size limitation is added to the spi_slave structure, which
is set up by the controller driver. The value of zero in this field
means 'unlimited transfer size'. It will work with existion drivers,
as they all either keep structures in the bss segment, or initialize
them to all zeros.
This patch addresses the problem for reads only, as coreboot is not
expected to require to write long chunks into SPI devices.
BRANCH=none
BUG=chrome-os-partner:32441, chrome-os-partner:31438
TEST=set transfer size limit to artificially low value (4K) and
observed proper operation on both Pistachio and ipq8086: both
Storm and Urara booted through romstage and ramstage.
Change-Id: Ibb96aa499c3eec458c94bf1193fbbbf5f54e1477
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4f064fdca5b6c214e7a7f2751dc24e33cac2ea45
Original-Change-Id: I9df24f302edc872bed991ea450c0af33a1c0ff7b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232239
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9571
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
WPT-LP has 4 SATA ports. Current code assumes 6 SATA ports and as a result,
some reserved bits are written with 1. No specific issue has been observed
so far.
BUG=None
BRANCH=None
TEST=Verify SATA PCI configure space dump on Auron
Change-Id: I737719b3d5cd788158cd5b6991405ba098be4078
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 2b55587a74ac5d45354dc123937b562290468855
Original-Change-Id: I9c53ac86e2bf72901647bd2cfa48ac0ce31abea0
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233661
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9479
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As per the TCG PC Client TPM Interface Specification v1.2, bit 7 of the
access register (tmpRegValiSts bit) stays "0" until the TPM has complete
through self test and initialization. This bit is set "1" to indicate that
the other bits in the register are valid.
BRANCH=chromeos-2013.04
BUG=chrome-os-partner:35328
TEST=Booted up storm p0.2 and whirwind sp3.
Verified TPM chip is detected and reported in coreboot logs.
Change-Id: I1049139fc155bfd2e1f29e3b8a7b9d2da6360857
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 006fc93c6308d6f3fa220f00708708aa62cc676c
Original-Change-Id: I9df3388ee1ef6e4a9d200d99aea1838963747ecf
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242222
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9567
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
chromeos.h includes vboot_handoff.h, which includes vboot_api.h. since
vboot_api.h is not available to non-chromeos projects, build fails for
some boards (e.g. glados).
this change removes (unnecessary) inclusion of vboot_handoff.h in chromeos.h
and fixes other files which rely on indirect inclusion of vboot_handoff.h
by making it direct.
BUG=none
BRANCH=tot
TEST=built for cosmos, falco, lumpy, nyan_blaze, parrot, rambi, rush_ryu,
samus, storm, veyron_pinky
Change-Id: I465e3657c6a0944bc75a669e5e52e74d46b3ec6c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6ace70d721aceae9257288815ce8fd7c6c74b8f5
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I12612773372e358584d12fffaf5f968a46083fab
Original-Reviewed-on: https://chromium-review.googlesource.com/245864
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9566
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
sd->fw_version represents the version of the *current* firmware, which
is not necessarily the same as the one stored in the TPM (and may be 0
in recovery mode). Use the newly added sd->fw_version_secdata instead
which contains a more correct value.
CQ-DEPEND=CL:244601
BRANCH=veyron
BUG=chrome-os-partner:35941
TEST=Booted Jerry in recovery mode, confirmed crossystem tpm_fwver was
corrent (and not 0).
Change-Id: I30f5998da5ac518d6fcb7a651eba4e1fabc14478
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: eb8142f69cea34e11f9081caafcaae7a15cc3801
Original-Change-Id: Id95bd8c6412f2e8b2ae643c3b5a3dee13d0d47be
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/244591
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9565
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are multiple vboot APIs (1.0, 2.0, 2.1). We have to be
explicit about which library we want to link with.
When building firmware, the vboot_reference Makefile should be
invoked in one of three ways:
TARGET OUTPUT VERSION
fwlib vboot_fw.a 1.0
fwlib20 vboot_fw20.a 2.0
fwlib21 vboot_fw21.a 2.1
BUG=chromium:228932
BRANCH=ToT
CQ-DEPEND=CL:243980
TEST=manual
emerge-veyron_pinky vboot_reference coreboot
emerge-samus vboot_reference coreboot
emerge-daisy_spring vboot_reference chromeos-u-boot
Change-Id: I7dde513c49b8148bf46e8768ae438e1a85af4243
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 5e339cadad4815f061d4e5e20a9c9733f64cc90b
Original-Change-Id: I850646117211930d9215693c48f2c30d55a984d3
Original-Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/243981
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9564
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The first platform that used flash-backed VBNV data has a physical
recovery switch, get_recovery_mode_from_vbnv() was never implemented.
This patch adds get_recovery_mode_from_vbnv() similarly to how it's
implemented for other vbnv storage in other places.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=needs testing
Change-Id: Ifd795c5c1ff0f23619fd2125b4795571af03ece1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 09f1bf96089bf9d159e4220c1f4d99388d709545
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I9cf18c988eaa4b7e720d6c66a02b1c5c63b473e9
Original-Reviewed-on: https://chromium-review.googlesource.com/239978
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9563
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Even though coreboot always hardcodes the FMAP offset, the same is not
possible for all other tools that manipulate ROM images. Some need to
manually find the FMAP by searching for it's magic number (ASCII
"__FMAP__"). If we do something like 'memcmp(fmap_buffer, "__FMAP__",
...) in coreboot code, it has the unfortunate side effect that the
compiler will output that very same magic number as a constant in the
.rodata section to compare against. Other tools may mistake this for the
"real" FMAP location and get confused.
This patch reverses the constant defined in coreboot and changes the
only use of it correspondingly. It is not impossible but extremely
unlikely (at the current state of the art) that any compiler would be
clever enough to understand this pattern and optimize it back to a
straight memcmp() (GCC 4.9 definitely doesn't), so it should solve the
problem at least for another few years/decades.
BRANCH=veyron
BUG=chromium:447051
TEST=Made sure the new binaries actually contain "__PAMF__" in their
.rodata. Booted Pinky. Independently corrupted both the first and the
last byte of the FMAP signature with a hex editor and confirmed that
signature check fails in both cases.
Change-Id: I314b5e7e4d78352f409e73a3ed0e71d1b56fe774
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 1359d2d4502eb34a043dffab35cf4a5b033ed65a
Original-Change-Id: I725652ef2a77f7f99884b46498428c3d68cd0945
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240723
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9562
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The current vbnv flash code mistakenly uses the offset into the NVRAM
area as the absolute offset into the SPI NOR. This causes overwrites
RO section of the flash (when it is not protected) and causes failures
to retrieve the NVRAM contents by the user space apps.
This patch makes sure that the correct offset is used when accessing
NVRAM area in the SPI flash.
BRANCH=storm
BUG=chrome-os-partner:35316
TEST=run the update code on storm.
- no more RO section corruption observed
- running 'crossystem recovery_request=1' at Linux prompt causes the
next boot happen in recovery mode
Change-Id: Iba96cd2e0e5e01c990f8c1de8d2a2233cd9e9bc9
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 9fd15ff4b7aa77536723edbb94fa81f0ae767aed
Original-Change-Id: I86fe4b9a35f7c16b72abf49cfbfcd42cc87937e3
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240143
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: http://review.coreboot.org/9561
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some common VBNV variable offsets were defined in multiple vbnv_*
source files. This moves them to a header so that we can avoid
duplicating them in the future.
BUG=none
BRANCH=none
TEST=compiled for nyan_blaze and rambi
Change-Id: Ic292e546b665b40678b4de598783c1f6bfa35426
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: fd776f303a3d057d4b70997e7bb6bc85767e2278
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Ifcc13c90a910b86d4f9bb0027d913572c1d6d00b
Original-Reviewed-on: https://chromium-review.googlesource.com/239977
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9560
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This sets the new VB_INIT_FLAG_BEFORE_OPROM_LOAD flag for VbInit()
to indicate that we are running from early firmware before option
rom loading has occurred so it can do the right thing when it
checks whether or not to tell the system to reboot after setting
the VbNv flag.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=pass FAFT tests on samus
Change-Id: Id432dc154736baa799d9ddf5a6a25bccc66217ef
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8a576b0bf4b912f85a4e82bfe2cf13c838a069cc
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Change-Id: I6968fcb6cda74e88f56bea6ea9bbf77cc795b8d6
Original-Reviewed-on: https://chromium-review.googlesource.com/230887
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9559
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
CL:243671 moved the initialization of elog_initialized around, which is
now unfortunately so late that the ELOG_TYPE_BOOT event gets omitted
because the code believes the log to be broken at that time. Good thing
we now have a FAFT test for these things that I had of course been too
lazy to run. -.-
The real reason for moving that line was to put it after any point in
elog_init() that could still error out. The problem is that we might add
the "cleared" event before we try to shrink (which can fail and cause an
error)... but those two things cannot happen at the same time, so it
should be okay to flip them around and mark the elog as initialized in
between.
BRANCH=none
BUG=chrome-os-partner:35940
TEST=Ran firmware_EventLog on a Pinky, manually confirmed that I once
again get "System boot" events.
Change-Id: I12dcf4a8e47d302f6cd317194912c31db502bbaf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4a1c0b861017ca25229b1042c4b37dda33e869f9
Original-Change-Id: I4103779790e1a8a53ecabffd4316724035928ce6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/246715
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9503
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The elog driver has a really stupid bug that checks a result which is
stored in an unsigned variable for < 0. Surprisingly GCC does not catch
this nonsense right now, and I spent an hour trying out different
warning options without finding one that doesn't also bring a load of
stupid and unavoidable false positives (the biggest offender being
-Wtype-limits, which does exactly what we'd want except for flagging
things like if ((u8)var >= CONFIG_VAR_MIN) where the VAR_MIN Kconfig may
or may not be 0).
So, the only thing we can do is fix this one and wait for the next time
something like that blows up. -.- Also change some more code to make the
behavior more explicit (the old code already intended to work this way
since flash_base is statically initialized to 0, never assigned in the
error path and checked later in elog_init()... but there was an error
message that incorrectly claimed a different fallback behavior, and
explicitly assigning the values makes this easier to see). Finally, add
another state to the elog_initialized variable to avoid trying to
reinitialize a broken eventlog on every event (if it doesn't work the
first time, chances are that it won't work later on during the same boot
either).
BRANCH=None
BUG=chrome-os-partner:35940
TEST=Flashed Jerry with RO 6588.4 and RW 6588.23, observed how it now
cleanly enters recovery mode without blowing its bootblock away with
stray eventlog entries.
Change-Id: I0e5348ba961ce4835c30f7108a2453522095f2ee
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f9798dbf0c2b2e337062ecd84d0f45434343c0d9
Original-Change-Id: I4d93f48d2d01d75a04550d419e023aa42ca95a7a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/243671
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9557
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The information about the DMA memory area is further passed
through the coreboot table to the payload.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA; DMA memory area was used to test the
functionality of the DWC2 USB controller driver; behavior was
as expected.
BRANCH=none
Change-Id: I658e32352bd5fab493ffe15ad9340e19d02fd133
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 0debc105b072a37e2a8ae4098a9634d841191d0a
Original-Change-Id: Icf69835dc6a385a59d30092be4ac69bc80245336
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/235910
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9593
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
RAM repair has to be performed to cluster 1 also.
BRANCH=none
BUG=none
TEST=Test on Rush and make sure RAM repair completes
Change-Id: I0daf969a995a2be152270bc06501eaf086a13a97
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6b07894cc737cb192f68e254d522b55d8ca3b2f3
Original-Change-Id: I458e0a66d76318c6a4aa82547c9037c7b969f1e1
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/239360
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9592
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
make: *** No rule to make target `build/lib/memset.rmodules.o', needed by `build/vendorcode/google/chromeos/vboot1/vbootstub.elf'. Stop.
Fix the error by refering to ./src/arch/arm64/Makefile.inc:
rmodules_arm64-y += ../../lib/memset.c
rmodules_arm64-y += ../../lib/memcpy.c
BRANCH=none
BUG=none
TEST=build pass on our own MT8173 board
Change-Id: Ic870136db1ec9405e3d30caf6085f056bc46a5c2
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: d317dbe8732abbf7e785466e7d1e07425aac326f
Original-Change-Id: I69a7db83154a23f7878e9c604c9b541fb6fa308d
Original-Reviewed-on: https://chromium-review.googlesource.com/237974
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/9591
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Rather than enable this in every mainboard just enable
it by default for all broadwell devices and let a
specific mainboard disable it if needed.
BUG=chrome-os-partner:34420
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I6e47c20abf29abfbd1f4b7905914b4c9fadb0ae7
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 25d3a685893e1c85f7b78e302da3187947a1f84f
Original-Change-Id: I26d9f2e2a12d3f2f888ecb5af0d949eec5928f57
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238400
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9590
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is necessary for the subsequent changes that will add to the size
of romstage.
BUG=chrome-os-partner:31438
TEST=coreboot builds successfully;tested on Pistachio FPGA
BRANCH=none
Change-Id: I132215bd44708913d878bbd8b6147bef535b52df
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 00f73f9d80a36fc43735f093365564b9d74ed7f7
Original-Change-Id: Ie858416a1c9ab63cfe85eea40a76a093cbd2c79c
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233871
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9589
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this change makes vb2_working_data struct point to the vboot work buffer by
the offset instead of by the absolute address, which can be different
depending on the context (e.g. subprocessor v.s. main cpu).
BUG=none
BRANCH=tot
TEST=booted veyron pinky
Change-Id: I2191ca756c4f49441b3a357338f9c84564b58918
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 93f8b1da2b2c81aa3a33892987a71e9e1e7a8eff
Original-Change-Id: I4e4c12613304586b7395c5173cf08b8093f59521
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236583
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9588
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When the i-cache is on and the d-cache is off, the L1 i-cache is still
fetching information through L2 cache.
Since L2 cache is never invalidated, it has stale information.
BRANCH=storm
BUG=none
TEST=Resolves the invalidate data fetch from i-cache while jumping from
bootblock to romstage.
Change-Id: Ibaca1219be2e40ce5bbbd1c124863d0ea71d0466
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a13e20f9b242d8193dcb314a2bdc708c6bdfea51
Original-Change-Id: I252682d372bd505f525f075461b327e4bcf70a1a
Original-Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236422
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9587
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some of the options in cmos.layout date back to the K8 days, and have
not been used anywhere else, but K8. This makes nvramtool expose a
very confusing set of options, most of which have no effect. Clean up
the layout before it gets forked again.
TEST: Booted linux, and checked 'nvramtool -a' output.
Change-Id: I1c5f83790ec89ced4dcf954e4949f8554aef6087
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/8378
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
fmap_find used to read 4096 bytes from the fmap offset blindly. instead, we read
the fmap header first to calcurate the size of the fmap. Then, we read flash
again exactly as much as the discovered fmap.
BUG=none
BRANCH=ToT
TEST=Booted Storm and Peppy. Built all current boards.
Change-Id: Iaa50c1bc3401c77b433af11406d4b9d2e4e722e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 755ff66ab0a4d05e6d5410c11a6badb9fcb77a0d
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Ie5058d181e6565acb70bf108464682dd0e6c1f64
Original-Reviewed-on: https://chromium-review.googlesource.com/231685
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9556
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
edp must reset when device power up, otherwise the edp
register maybe uncertain, now the edp source clock default
select 27M, and in pinky and jerry board we use 24M as edp
sourec clock, if we want to reset edp, we must after the clock
source select 24M.
BUG=chrome-os-partner:34023
TEST=Booted Veyron jerry and read edid normal
BRANCH=None
Change-Id: I4b03dbabe5d3d595d2d56efb0cd82f510f8d2e1b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2292da77cc2322b85c4b4f4f20e4ebcc4c4d060d
Original-Change-Id: Ica031d2d52deb539c1a0a56968786d6952b3d0e8
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231336
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9555
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Implement VOP and eDP drivers, vop and edp clock configuration,
framebuffer allocation and display configuration logic.
The eDP driver reads panel EDID to determine panel dimensions
and the pixel clock used by the VOP.
The pixel clock is generating using the NPLL.
BUG=chrome-os-partner:31897
TEST=Booted Veyron Pinky and display normal
BRANCH=None
Change-Id: I01b5c347a3433a108806aec61aa3a875cab8c129
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e4f863b0b57f2f5293ea8015db86cf7f8acc5853
Original-Change-Id: I61214f55e96bc1dcda9b0f700e5db11e49e5e533
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9553
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Like most newer Chromebooks, Pinky and Jerry do not have physical
dev switches.
BUG=chrome-os-partner:33395
BRANCH=none
TEST=built and booted on Pinky, crossystem prints a valid value for
devsw_cur instead of an error.
Change-Id: If97ffa6f99eb31c05915f3ee82aaf6bd252d29e4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: db302d7286d3e7df9442928dac1d611a2c103163
Original-Change-Id: I186518a59699d293c7938221b3ae45b27361c255
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229680
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9552
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds support for Pinky rev3 (board ID 2) and Jerry rev2: the
power button GPIO changed polarity to low, the 5V_DRV pin for USB power
was moved to the AP again (welcome back!), and the EMMC_RST_L is now
finally on a port with the right IO voltage so we don't need any weird
pull-up tricks anymore. Since there are very few Jerry rev1s around,
we'll just move it over to the new code directly without introducing
board ID differences (also, because I have no idea how they stuffed it
this time... is this one actually called rev2?).
BRANCH=None
BUG=None
TEST=Still boots on my Pinky rev2, though that doesn't say much.
Change-Id: Id11044cedcaac5a4ae07e696893823925107a6db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 55344a9518ff04edcef01bcd40817e9e4b613717
Original-Change-Id: Iddee360fbda357ecde4ae5fbb5c3a01fe0c22474
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229010
Original-Reviewed-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9551
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch ports commit 567f616f (rk3288: slowly raise to max cpu
voltage to prevent overshoot) to Veyron_Jerry. It also fixes include
ordering and some comment grammar in the affected code.
BRANCH=None
BUG=chrome-os-partner:32716
TEST=None
Change-Id: I4ac14a38e4b3acc4926d4f51f409ff12d9c841cf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 679014bc843788e8d4d5f5c7470ae76f8be5e942
Original-Change-Id: I9c0aba40ddd8a0852391df184034baa740d063df
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228938
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9550
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This enables RAM_CODE_SUPPORT for veyron* platforms and uses the
generic gpio_get_binaries() function to read RAM_ID GPIOs.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=built and booted on pinky
Change-Id: I7a03e42a270bec7036004375d36734bfdfe6e528
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a325b204ff88131dfb0bdd3dfedb3c007cd98010
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Ibc4c61687f1c59311cbf6b48371f9a9125dbe115
Original-Reviewed-on: https://chromium-review.googlesource.com/227249
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9549
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This makes board_id() use the generic gpio_base2_value() function
to obtain the value of the board ID straps.
BUG=none
BRANCH=none
TEST=tested on pinky
Change-Id: I15c1310889b989c34638fd342011aef5fe7bcec1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fcbb8a6998a66531326afe16b232395d49fee64d
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I5847bf1c5b26bcaf7d36103f31bb255b31ff8185
Original-Reviewed-on: https://chromium-review.googlesource.com/228370
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9548
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
LDO7 (VCC10_LCD_PWREN_H) is essentially just a glorified GPIO that turns
the real VCC10 regulator on or off. We tried setting it to 3.3V since it
matches the VCC33_SYS voltage on the input of that regulator. However,
we didn't notice that the LDO only supports going up to 2.5V.
This patch changes the voltage to the allowed maximum, which should
still work fine as an enable line (and is the same value used by the
kernel). This removes an assertion error in the ramstage.
Also change the PMIC driver to assert maximum VSEL values based on the
LDO, because the lower-voltage ones support one more setting. (LDO3 is
actually listed to only go up to 0b1111 in the manual, and has a weird
jump from 0b1101 -> 2.2V (skipping over 0b1110) to 0b1111 -> 2.5V. I
don't know if that's a documentation error or what they were smoking
when they designed that, but we don't need to care for now.)
BRANCH=None
BUG=None
TEST=Booted on Pinky, no more ASSERTION FAILED.
Change-Id: I38bf99e38822fd0883fd4d0bd9a1b01143545a95
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 70f3149efbc3aa9a03ab3fd5be99d17d9c5e1c87
Original-Change-Id: I68a3bb882cf25d98aca8922ede2a17e1ef6524de
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228292
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-by: Jerry Parson <jwp@chromium.org>
Reviewed-on: http://review.coreboot.org/9547
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The veyron_jerry board code was just copied over from veyron_pinky
1-to-1. The Jerry board IDs start at 1, but there has never been a Jerry
rev0 so we can remove the code for board ID 0 from it.
BRANCH=none
BUG=None
TEST=Booted Jerry image on a Pinky rev2, worked fine.
Change-Id: I0f2ffdc577934c1695e8d2dcf71512696ac1d5a5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: aa36da69ac584b845e15282dae100eec27fc7f12
Original-Change-Id: I45a18b288c8d8b1399ceedf582addcce1c7e857d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228254
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9546
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The eMMC enable pin is in a 3.3V IO domain. Unfortunately the eMMC
expects this pin to be 1.8V. The way we were driving this pin would
cause the eMMC to pull power through this pin and that was causing
current leaks.
In future revisions of hardware we should move this pin somewhere more
legit. However, in the current hardware we can get things working
pretty well by using a pullup to "drive" this pin. This will work in
conjunction with the external 100K pullup to give a somewhat
reasonable voltage. The eMMC will also not be able to pull much
current through this pin, so it can't leak too badly.
BRANCH=none
BUG=chrome-os-partner:33319
TEST=Boot a kernel that doesn't touch the mux/pulls and see no leak:
dut-control --port=${SERVO} vcc_flash_ma -t 5
Change-Id: Ibc25cd090d826c8215be24a0b5c11d97b5281700
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 26e7a9d7e067ed4dd859387ee63bf654ab9dc529
Original-Change-Id: Iadfc1477cd478773cc9d159e3fbc22b66b8f0f78
Original-Signed-off-by: Doug Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226039
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9545
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is essentially a copy of veyron_pinky for now.
BUG=chrome-os-partner:33269
TEST=build and boot
Change-Id: I151c82f54ece4620953d0db5aedf027a3293926f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 267611f2354be4384de3f05d2459a4e421ee6b4f
Original-Change-Id: I0d473361e0850ee3b11da5a809f8396826ccdad6
Original-Signed-off-by: Katie Roberts-Hoffman <katierh@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225301
Reviewed-on: http://review.coreboot.org/9544
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Invoke the function which copies WiFi calibration data in a CBMEM
table.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that the WIFI entry is added to CBMEM when the
calibration data is present in the VPD.
Change-Id: Icab0a2343e88e1d44575eeb608fdf6588aff255b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 68b96f158633cb3a1f157b5a19da39fa7e78f975
Original-Change-Id: I5fa77da98e37b88da01fb7884e713535fc178006
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225272
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9543
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The CPU on/off functions are the method for the Kernel to support CPU
hot-plug function in PSCI. To support this, we still need flow controller
support to capture the WFI from the CPU and inform PMC to power gate the
CPU core. On the other path, we turn on the CPU by toggling the PMC and
use flow controller to let go when the power is steady.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=built the kernel with PSCI enabled,
check both of the CPUs are coming up,
test the CPU hot-plug is working on Ryu
Change-Id: If2c529b6719c5747d5aea95fb5049b2d7353ff17
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0f078e89daad1c4d8b342a395f36b3e922af66f5
Original-Change-Id: Ie49940adb2966dcc9967d2fcc9b1e0dcd6d98743
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231267
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9542
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With support for initializing registers based on values saved by primary CPU, we
no longer need to invalidate secondary CPU stack cache lines. Before jumping to
C environment, we enable caching and update the required registers.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu.
Change-Id: Ifee36302b5de25b909b4570a30ada8ecd742ab82
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0a0403d06b89dae30b7520747501b0521d16a6db
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I738250f948e912725264cba3e389602af7510e3e
Original-Reviewed-on: https://chromium-review.googlesource.com/231563
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9541
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
startup.c provides function to enable CPU in any stage to save register data
that can be used by secondary CPU (for normal boot) or any CPU (for resume
boot). stage_entry.S defines space for saving arm64_startup_data. This can be
filled by:
1) Primary CPU before bringing up secondary CPUs so that the secondary can use
register values to initialize MMU-related and other required registers to
appropriate values.
2) CPU suspend path to ensure that on resume the values which were saved are
restored appropriately.
stage_entry.S provides a common path for both normal and resume boot to
initialize saved registers. For resume path, it is important to set the
secondary entry point for startup since x26 needs to be 1 for enabling MMU and
cache.
This also ensures that we do not fall into false memory cache errors which
caused CPU to fail during normal / resume boot. Thus, we can get rid of the
stack cache invalidate for secondary CPUs.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu without mmu_enable and stack
cache invalidate for CPU1.
Change-Id: Ia4ca0e7d35c0738dbbaa926cce4268143c6f9de3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9f5e78469313ddd144ad7cf5abc3e07cb712183a
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I527a95779cf3fed37392b6605b096f54f8286d64
Original-Reviewed-on: https://chromium-review.googlesource.com/231561
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9540
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some registers are available only at EL3. Add conditional read/write functions
that perform operations only if currently we are in EL3.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: Ic95838d10e18f58867b6b77aee937bdacae50597
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 62a0e324a00248dba92cb3e2ac2f4072d0e4e2a7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: Ia170d94adb9ecc141ff86e4a3041ddbf9045bc89
Original-Reviewed-on: https://chromium-review.googlesource.com/231549
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9538
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
TCR at EL1 is 64-bit whereas at EL2 and EL3 it is 32-bit. Thus, use 64-bit
variables to read / write TCR at current EL. raw_read_tcr_elx will handle it
automatically by accepting / returning 32-bit / 64-bit values.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: I96312e62a67f482f4233c524ea4e22cbbb60941a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ae71f87143f899383d8311a4ef908908116340d7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I459914808b69318157113504a3ee7cf6c5f4d8d1
Original-Reviewed-on: https://chromium-review.googlesource.com/231548
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9537
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Update non-vboot2 memlayout:
1) Add timestamp region
2) Increase ramstage size
3) Change name from memlayout_vboot.ld to memlayout.ld so that any non-vboot
upstream board can also use this layout.
BUG=None
BRANCH=None
TEST=Compiles and boots to kernel prompt on ryu with vboot selected instead of
vboot2.
Change-Id: Idced98f9df7cdbab5f62cd1e382c6046ade1d867
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 20fffa282b20fb32ce2ff687f4479be630f90fcf
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I91accd54efc53ab563a2063b9c6e9390f5dd527f
Original-Reviewed-on: https://chromium-review.googlesource.com/231547
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9536
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of having unified CBFS_CACHE and limiting the POSTRAM Cache size, split
them into PRERAM and POSTRAM CBFS_CACHE.
BUG=None
BRANCH=None
TEST=Compiles successfully for both rush and ryu. Boots to kernel prompt on ryu.
Change-Id: I2a70df22fe5bae23e05cdf1b8a300369c7ccf87d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b93bc06de76cab0a1ec9a56e12c9a6942a430893
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: Iab21ff5c7ca880b6bd18846e5d8d71c26dff56cf
Original-Reviewed-on: https://chromium-review.googlesource.com/231546
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9535
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
A couple of regs need to be poked to allow audio output
from this part on Ryu P0/P1. It will be replaced by two
non-configurable amps on P3.
BUG=none
BRANCH=none
TEST=Build/flashed on Ryu P1, dumped AD4567 (I2C6 dev 0x34)
regs and confirmed settings.
Change-Id: Ie602b056fb1488546ab233f8f81cfacb96624ebb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 75dabe378b561e939381e2ef5113a2b28bfcedf8
Original-Change-Id: I8999843646927dbd07a179ede973ba5f1eb97167
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231384
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9532
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In order to start CPUs while in secmon/psci one needs to
set up the proper SoC state. Therefore, refactor the current
CPU startup API to allow for this by adding cpu_prepare_startup()
and start_cpu_silent().
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted kernel.
Change-Id: I1424500f6c9398f7d44350949c25bb3d4832cec7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 70f9cf67085b345b529b41dd6554e37d38a5b350
Original-Change-Id: I842a391d3e27ddbfcdef1a2d60e3c66e60f99c77
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231936
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9531
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
psci_soc_init() was added to allow SoC PSCI initialization.
However, actually calling said function was omitted accidentally.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and noted correct on entry point was used.
Change-Id: I84a397e2dabf149fe8f252ef69d0a7362fa1f194
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2a0e6ad41f049bbab483423231db59390894e9b2
Original-Change-Id: I1a4e25fde64ecdc98fa9231f7d9cafc21119630d
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231935
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9530
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Based on TPS65913, the max LDO turn on time is 500us. Since it is requested
the default delay of 500us when calling function pmic_write_reg(), it is
safe to remove this 100ms delay.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I2cfda38728db223c26f9122b70d37e828921459a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 271b7e95f66f4b8611a0d408e59f428c315074f3
Original-Change-Id: I53aecc273484edfa502231b44f6bcd7f5d8f9331
Original-Reviewed-on: https://chromium-review.googlesource.com/231170
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: http://review.coreboot.org/9529
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The bootblock on Rush had bumped up into the verstage
allocation, causing the build to break. Reduced verstage from
60K to 58K and increased bootblock from 20K to 22K. Rush and
Ryu both build fine now.
BUG=none
BRANCH=none
TEST=Built both Rush and Ryu OK. Verifed verstage size
using cbfstool and it's around 55K, so plenty of room.
Change-Id: Iaa3a5838c5235ec78c740a977bc032d8b5e270ef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 928a4d2d1efabe1e1d6a7fadc22ee0ac4269190e
Original-Change-Id: I7018f027d72d5e8aeb894857a5ac6a0bdc1de388
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/230824
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9528
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Secondary CPUs were intermittently not coming online as expected.
Upon investigation it was found that a cache line needed to be
invalidated that corresponded to the top of the stack for the
failing CPU.
Currently the secondary CPUs come online with caching disabled.
However, the code paths are using C and thus the stack it is assigned.
The MMU is enabled in C after it's pushed its return path onto the
stack that went directly to ram. When the cache line corresponding
to its stack is valid in the cache it will hit once the MMU is enabled.
That hit will have invalid data w.r.t. the return addresses pushed
directly into ram.
This is not the best solution as the only way to guarantee we don't
hit such a situation is to tightly manage resource usage up until
the point of MMU enablement. That can be done in a followup patch.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=On ryu where secondary CPUs weren't coming online consistently,
they now come up.
Change-Id: I03237656da180d1f74df3a8e00029ba8d778bca8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 06ab6afc996cf92c45d4cd6850e31167c2946a95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Change-Id: I32de749ea48c19e23442e6dc5678c5369ac3b2b6
Original-Reviewed-on: https://chromium-review.googlesource.com/231219
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9527
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The initial MP code assumed all CPUs would come online. That's not
very defensive, and it is a bad assumption. Provide a timeout
mechanism for bring CPUs online.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Multiple times with CPUs working and not working. Boot to kernel.
Change-Id: Ib0aef31f5c732816d65c2e4b3c6a89e159974fdc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9cf5bc2844c8f4ad987cfcb69ef33c73551f0083
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Change-Id: Ifb3b72e3f122b79e9def554c037c9b3d6049a151
Original-Reviewed-on: https://chromium-review.googlesource.com/231070
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9526
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The kernel does not correctly function without PLLD being enabled.
Additionally, PLLD can be the source for other clocks in the system.
Therefore, initialize PLLD to 300MHz unconditionally at BS_DEV_INIT
time in ramstage.
BUG=chrome-os-partner:33825
BRANCH=None
TEST=Built and booted ryu with display coming up both in dev mode as
well as normal mode.
Change-Id: Ib2a60bb9aafc03dc23aa932a480184d87f677c65
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4c49f964b55c3c33d03b95363277b262b679e740
Original-Change-Id: Ic5905e25051a042cea5010b8c6d61b1fb89a0a81
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/230774
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: http://review.coreboot.org/9525
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide an explicit name for configuring PLLD. The new name,
clock_configure_plld(), provides an explicit semantic to
what it is doing. Also, provide the printk() about actual
frequency vs requested frequency as most of the callers
were doing this themselves.
BUG=chrome-os-partner:33825
BRANCH=None
TEST=Built and booted on ryu.
Change-Id: I1880f0f305e69674922b070d282aac3acdc86aad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c51d5b0864d8bd0db5927380803cec46ccd74d48
Original-Change-Id: If744332b466d9486f83b08d0ab4e9006fadfecdd
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/230773
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: http://review.coreboot.org/9524
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Ryu RT5677 audio codec uses EXTPERIPH1 clock (12MHz)
for MCLK1, I2S1 for input. AHUB needs all of its child
peripherals taken out of reset and enabled, too.
This just sets up the audio clocks. More work still to
be done in the codec driver, and some kind of stub needs
to be created/hacked to set up the AD4567 speaker amp
regs for mono output on P1.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=Dumped clock regs and saw correct values
Change-Id: Ifb6551f1e09b38f440f3bb7c759b5e6c0b9e4e44
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 48f989a0291044f5fb4340cc89546325d819d82f
Original-Change-Id: I6c9e760ac39def92a6054d673f781facdbfd70a2
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229993
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9523
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When displaying a 800x600 bitmap on 2560x1800 panel, the image
is shown very small. So, set the fb to 1280x800 (based on tegra
dsi driver default mode setting), a 800x600 image can be shown
relatively proportional to panel size.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I1e360aeaec97b9df5d86e46951ab1326610260d2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 67c2a381322721a24b1b7f9ac366073b7e3c490c
Original-Change-Id: I62cbe9de1d1002293df20f8b1d752905c6ef33aa
Original-Reviewed-on: https://chromium-review.googlesource.com/229912
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9521
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Framebuffer line size and number of lines can have different
values than panel's resolution.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Change-Id: I228f1dd7fafc6577a8e8a987ff31ba73f7a655ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9a4929dc5831076f2f2a5dd2e13f24b3477e197b
Original-Change-Id: Iedeef796f02286bb03920413420f8952cf34334a
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229915
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9520
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
panel spec such as resoultion, bits per pixel are
needed to pass to depthcharge/payload for displaying
bitmap onto panel.
Enable display code only if mainboard selects
MAINBOARD_DO_NATIVE_VGA_INIT. Otherwise build breaks for
boards that do not support display init yet.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=Compiles for both rush and ryu. Display comes up for ryu in both normal and
dev mode.
Change-Id: I81b4d289699e7b0c2758ea1a009cbabaf8a2ce28
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b9b42486f203d332f6068ccd6f4a1a982d327a6b
Original-Change-Id: I5c8fde17d57e953582a1c1dc814be4c08e349847
Original-Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Commit-Id: ce2883b21d3fbfd54eac3a355fb34ec70e9f31ad
Original-Change-Id: Ib4a3c32f1ebf5c6ed71c96a24893dcdee7488b16
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: http://review.coreboot.org/9519
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Stack and Timestamp need lesser than 2K and since romstage is running out of
memory, adjust the overall memory assignment.
BUG=chrome-os-partner:33676
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: I5076252ae87268bd4e964c282d1cc337e0ea4e70
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f2d5d29e6f0f5058a41ed30aae98f79574e31609
Original-Change-Id: I0134f25dd49f2940bb159d131aaee12f81e13ef7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229001
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Commit-Queue: Tom Warren <twarren@nvidia.com>
Reviewed-on: http://review.coreboot.org/9512
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Chrome OS support needs to be enabled on urara. This patch adds a
placeholder file to keep Chrome OS support code.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Change-Id: I0731469934f04bd68914f09db5d64758c5d01545
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 169c62c9443c3b9fcab23b312b5cb18ba79437f4
Original-Change-Id: I8ec328d4f965ff80d17847f2f8ce62b402c42a46
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226179
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9466
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
According to BYT platform design guide chap 14.2.2, the NC GPIOs
need to be configured to GPO.
BRANCH=none
BUG=none
TEST=Test on rambi, boot to OS, and make sure NC pins config to GPO
Change-Id: Ida5ea89ee66e39b4fddea242dc918b314756d94f
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 998493566f5cf7abd9375583e12fe631b226e591
Original-Change-Id: Ieaf346d1c7bf3ecb47a71a6ee4afaa805235cc37
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/249060
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9509
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds a few retries to NVRAM read/write transactions with the
EC. Failing to read the NVRAM is not fatal to the boot, but it's still
pretty bad... especially since a single initial read failure will cause
vboot to blindly reinitialize the whole NVRAM with zeroes, destroying
important configuration bits like dev_boot_usb. The current EC
transaction timeout is one second, so the three retries added here can
potentially increase boot time by three seconds per transaction... but
this shouldn't happen in any normal case anyway, and if there are errors
a little extra wait is probably preferrable to nuking your NVRAM.
(Also, added a missing newline to an error message in the EC code.)
BRANCH=veyron
BUG=chrome-os-partner:36924
TEST=Booted a Jerry with the power button bug with a 2 second press,
noticed that the first two transactions failed but the third one
succeeded.
Change-Id: I5d1cf29ac1c555ea2336ebb0b0e0a3f7cbb9c3fd
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 894a8a0b4a9805e92544b5e3dfa90baf6d36649a
Original-Change-Id: I6267cdda2be2bad34541b687404c2434d3be345b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/251694
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9507
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Expand the boot block include file to allow for a file containing reset
routines to be added. Prevent breaking existing platforms by using a
Kconfig value to specify the path to this file, and have the code
include this file only if the Kconfig value is set.
BRANCH=none
BUG=None
TEST=Build and run on Glados
Change-Id: I604f701057d7018f2ed9c3ba49a643c4bca13f00
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c109481d9503916e19ed300c1a3f085e0d2b5c51
Original-Change-Id: I3214399f8156b5ea2ef709ce77e3915cea1523a3
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/248300
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9504
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Looks like Intel has added two more USB 2.0 ports from LynxPoint to
Broadwell, which shifted the port offsets of the USB 3.0 ports behind
them. The USB 2.0 ports are now 0x480 to 0x520 and the 3.0 ones 0x530 to
0x560 (at least according to what my kernel seems to think). The offset
of the first USB 3.0 port is hardcoded and seems to have been copied
over without accounting for this, meaning when we try to operate on all
USB 3.0 ports we actually operate on the last two 2.0 and the first two
3.0 ports instead.
This patch should fix the bug for now. In the future, we might want to
consider dynamically detecting port locations through the Protocol
Capability structures at the end of the XHCI register set instead.
BRANCH=samus
BUG=chrome-os-partner:35320
TEST=TODO
Change-Id: Ifab6e484980fd4cd0daf80ceb292ddced2ab1aea
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 525f359c0b6b95b260add2b4617fd86119d69397
Original-Change-Id: Ic2becf2b043612270909ceef66e7d58efc8fcbe1
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/247351
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-on: http://review.coreboot.org/9502
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This changes the PCIe replay timeout value in the root ports
to be 0xD to fix correctable AER replay timer timeout errors.
BUG=chrome-os-partner:31551
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: I3084cc633da6e9f9a783d923a3fe2c1097e711fd
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a64897efc26731fa3896e6d9a413941807296a28
Original-Change-Id: I53d87ad38856fd7de7f3f06a805c9342373bc968
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/245359
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9501
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is needed for audio playback after we disconnect PP1800_CODEC
from DACREF to avoid noise coupled on PP1800_CODEC, which makes
recording noisy.
For recording, DACREF comes from mic vref pump voltage.
For playback, DACREF comes from internal 1.8V.
BUG=chrome-os-partner:32953
BRANCH=samus
TEST=Set MICBIAS to 2.970V on Samus, playback/recording is clean
Change-Id: I65fb6dbfab54c7c4de6496fd4a0d666baead28ec
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3e62a61f6cf6042f6d653a827698b55ac86e2d2b
Original-Change-Id: I27430691e469dd7f4056d99438ce080062b58b9a
Original-Signed-off-by: Ben Zhang <benzh@chromium.org>
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241179
Reviewed-on: http://review.coreboot.org/9500
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The default micbias1 voltage is 1.476V (1.8V * 0.82) which does
not match what's specified on the schematic. This patch sets
the voltage to 2.970V (3.3V * 0.90) according to the schematic.
BUG=chrome-os-partner:32953
BRANCH=samus
TEST=Set MICBIAS to 2.970V on Samus and verified with a scope
Change-Id: I1ced834a5afe2de3fccf4bcff8ec9c8e5718f60a
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 176f9272801a3de5ed6fc05ade06042e2a2c0a5c
Original-Change-Id: Icdbc1b5f65fe28591d54544372bdc2dacb50e9c1
Original-Signed-off-by: Ben Zhang <benzh@chromium.org>
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241178
Reviewed-on: http://review.coreboot.org/9499
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this code change provides a way to enable 2x refresh rate
in RW image
In baytrail, it enables 2x refresh rate by default
BUG=chrome-os-partner:35210
BRANCH=none
TEST=check the register is set properly on rambi
Change-Id: I2a935b570c564986898b6c2064fc7ad43506dcba
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c740d403708862514be9fa24f56b2764328979eb
Original-Change-Id: I84f33d75ea7ebfea180b304e8ff683884f0dbe8a
Original-Signed-off-by: Kane Chen <kane.chen@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241754
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9498
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add some configuration options that allow tuning the VR for C-state
settings that may be able to reduce noise.
- Add option to enable slow VR ramp rate for C-state exit
- Add variable to configure the minimum C6/C7 voltage
BUG=chrome-os-partner:34771
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: I01445d62fbfcf200b787b924d8d72685819a4715
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: ed8f355e60292c82791817ae31bff58ac2390a72
Original-Change-Id: I8af75b69c8b55d3e210170ee96f8e22c2fd76374
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241950
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9497
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reduce the SATA Gen3 TX voltage amplitude by 210mV based
on the provided test results to help with SATA validation.
BUG=chrome-os-partner:34121
BRANCH=samus
TEST=build and boot on samus and ensure SATA is still working,
firmware image will be provided for full validation.
Change-Id: I574d2f457b7b6831a339602a4165e959a0e2ee7d
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 9500ec152d8f9c90513811b1a92d1a8c155f514a
Original-Change-Id: I233fa1a9a7f2877a97ef6834304680f82b958e82
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241800
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9496
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To ensure that boot flags (legacy, usb, signed-only) are
properly restored from CMOS and used in the first boot after
a battery removal or RTC reset then the VbNv region needs to
be preserved around the cmos_init call.
When using vboot firmware selection and VbNv is stored in CMOS
then that region of CMOS will have been re-initialized by the
time we call cmos_init and reset CMOS if the chipset flag was
set indicating a problem.
BUG=chrome-os-partner:35240
BRANCH=broadwell
TEST=manual testing on samus:
1) boot in dev mode, enable dev_boot_legacy and ensure it works
2) on EC console pulse PCH_RTCRST_L low for a second
3) ensure first boot after RTC reset will still boot legacy mode
4) remove battery for a time
5) ensure first boot after battery is re-inserted will still
boot legacy mode
Change-Id: Ica256bbdcba6d4616957ff38e63914dd15f645c6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 881c7841c95dec392a66eef38a7112c1f385fdfa
Original-Change-Id: I4c33f183ba4b301d68ae31c41fc6663f3be857b0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241529
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9495
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This function will use the next available/free protected range
register to cover the specified region of flash and write
protect it until the next reset.
This will be used by the common MRC cache code to protect the
RW_MRC_CACHE region after it is updated.
In order to communicate to the common NVM code that this function
is defined also enable CONFIG_MRC_SETTINGS_PROTECT variable.
BUG=chrome-os-partner:28234
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: I710c6a69f725479411ed978cc615e1bb78fb42b8
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 25365433be0f190e10a96d9946b8ea90c883b78a
Original-Change-Id: I4a4cd27f9f4a94b9134dcba623f33b114299818f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241129
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9493
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order for recovery request to be cleared with software sync disabled
we need to implement this function in the mainboard.
BUG=chrome-os-partner:28234
BRANCH=samus
TEST=boot in recovery with software sync disabled, ensure that the next
boot will not boot in recovery again.
Change-Id: Ie9c845396dfc6ab65296b2f18a86e23590c833d6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 430f85608cc3b59a68a86dba64ffe428bfc216a9
Original-Change-Id: Iac15b6a1b23cc971231339439bceb013f4a031bd
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241052
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9492
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With recent changes in the 3.14 kernel and the switch to not
using X the panel backlight is not geting turned on until
chrome is started which means the splash screen is not visible.
If we set the backlight PWM in coreboot then it will at least
turn on for the early boot process.
BUG=chrome-os-partner:31549
BRANCH=samus
TEST=boot on samus in normal mode and see the boot splash logo
Change-Id: I81e6b90617acb181b4de3365f8f56ec3b846b78b
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f850fe3faff268a64f18e6bd176ec1126b921e3b
Original-Change-Id: I622bef8af9bb6b753fe228b33ecdc4aae76af131
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240853
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9491
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order for some panels to meet spec when the system is put
into S5 by way of power button during firmware (i.e. not by
the OS) then it needs to turn off the backlight and give it
time to turn off before going into S5.
If the OS properly sequences the panel down then the backlight
enable bit will not be set in this step and nothing will happen.
BUG=chrome-os-partner:33994
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: Ic86f388218f889b1fe690cc1bfc5c3e233e95115
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e3c9c131a87bae380e1fd3f96c9ad780441add56
Original-Change-Id: I43c5aee8e32768fc9e82790c9f7ceda0ed17ed13
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240852
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9490
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When disabling PCIe ports skip steps if no card is detected.
This prevents the loop from timing out on each empty slot.
BUG=chrome-os-partner:31424
BRANCH=broadwell
TEST=build and boot on samus, check that this code is
no longer timing out when disabling PCIe ports
Change-Id: I84ee0e0e325784b3af06abe70420c07cf6e13ed2
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4d759e2350dd00ceb7df196ac7008729dc1e4cef
Original-Change-Id: Idd88f0f1191a5465a0d8dcca07b5c3a5c5ca8855
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240851
Original-Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9489
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The workarounds in ACPI methods for D0/D3 transition that are
used on haswell/LPT do not all apply to broadwell/WPT.
BUG=chrome-os-partner:28234
BRANCH=broadwell
TEST=build and boot on samus, test USB functionality and wake
and ensure the device still does into D3 state
Change-Id: Ic3a75f5bf50e826ade7d942b48cfebb75cf976e6
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 1b54d105957ee80ca34048c42fb8f241731281cf
Original-Change-Id: I877afd51fc6c9b7906e923b893fc31bdf2cd1090
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240850
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9488
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This changes the broadwell graphics init path to only do the delay
before initializing graphics when running chromeos if we are also
going to execute the option rom.
BUG=chrome-os-partner:33671
BRANCH=samus
TEST=build and boot on samus
Change-Id: Idb7d39b22f7f6dc3be6dfbd2fa3cc2e33d78a397
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f7ed93504a74760f16acb8fb3c6c57ac514b7260
Original-Change-Id: I350f85738efe3d17152de4f025adbfd52ae15b95
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228882
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9474
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We'll need to find a real ACPI device ID for
the rt5677 SPI driver. "RT5677AA" is temporary.
BUG=chrome-os-partner:33495
BRANCH=samus
TEST=load firmware via SPI; hotword detection works
Change-Id: I6dc55c4641c27a38570debe841a6afeb048eb868
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f0d7013b62c78deb82db1a431f079c79eded5270
Original-Change-Id: Ifb4a1b12776669e21c0b7c4679246717d72981ad
Original-Signed-off-by: Ben Zhang <benzh@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/235902
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9486
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
HSIOPC/GPIO71 is used to control power to VCCHSIO, VCCUSB3PLL and
VCCSATA3PLL in S0. PCH will drive HSIOPC low when all the high
speed I/O controllers (xHCI, SATA, GbE and PCIe) are idle.
This patch added a few additional PCIe programming steps as required
in 535127 BIOS Writer Guide Rev 2.3.0 to enable this power saving mode.
BUG=none
BRANCH=none
TEST=tested on Paine watching GPIO71 toggling as expected
Change-Id: Ica6954c125ec3129e2659168f1f23dc861ce5708
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e38f9ef57c480ca5ee420020eb80a1adb3c381d3
Original-Change-Id: I88ef125c681c8631e8b887f7ccf017b90b8c0f10
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/238580
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9482
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
To support the ACPI device specific properties that conform to the
existing devicetree bindings for this codec (in upstream kernels)
add a _DSD object to the existing codec device.
BUG=chrome-os-partner:29649
BRANCH=samus
TEST=build and boot on samus
Change-Id: Ice808ba7bf2f0378ac5a38afd27dbf6c8cac0da5
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: b3fc2d7e5a5878b1fff7627f803b883b38fea28d
Original-Change-Id: I344636171a3086a72087314503bfc99de5945b1f
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238857
Original-Reviewed-by: Ben Zhang <benzh@chromium.org>
Reviewed-on: http://review.coreboot.org/9483
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The registers that were used here are for CPT/PPT and not
for HSW/BDW chips.
Update this to update just the Gen3 TX Output Voltage Downscale
Amplitude Adjustment field in the SATA ECR T88.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I94b702dc4a3c98678ba048ff9cfa4a85cc5b1eed
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 4c5816cc647b84266751e8a591eb85d7735fee12
Original-Change-Id: I98ec9678938a6675828721d5b57683077f555d21
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/238800
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9484
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Added a few bits to set in finalize step from scrubbing BWG
and reference code.
BUG=chrome-os-partner:28234
BRANCH=broadwell
TEST=build and boot on samus
Change-Id: I7b0c4dd3f14c06175c973561760ad1bdafd46fbb
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3802aef908849fe6ea2bb0034d884064154ae9da
Original-Change-Id: Ia62055b32be039eef84a0f60f0ba307eb5dce6a1
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/239958
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9485
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The original code uses L1EXIT_MASK to shift the bit for
PCIe L1 exit latency, the code should use L1EXIT_SHIFT
for bit shifting.
BUG=chrome-os-partner:34037
BRANCH=None
TEST=build and boot on candy, verify B0:D28:F0 + 4Ch [17:15]
set to 010b. Correspond WIFI device performance got improvement.
Signed-off-by: Kevin L Lee <kevin.l.lee@intel.com>
Change-Id: I3ac5b6319b726aa16cdb9678face89022d979517
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 381827e3d92c9e786cd8ebe412586968662fb4be
Original-Change-Id: I8171f80720830cfa76f26778ae31c7590a723b92
Original-Reviewed-on: https://chromium-review.googlesource.com/234673
Original-Reviewed-by: Kenji Chen <kenji.chen@intel.com>
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Tested-by: Kenji Chen <kenji.chen@intel.com>
Original-Commit-Queue: Kenji Chen <kenji.chen@intel.com>
Reviewed-on: http://review.coreboot.org/9480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The TPM driver by default allocates a 4K transfer buffer on the stack,
which leads to lots of fun on boards with 2K or 3K stack sizes. On
RK3288 this ends up writing over random memory sections which dependent
on the memlayout of the day might contain timestamp data (no big deal)
or page tables (-> bad time).
This patch fixes the problem by reducing the buffer size to slightly
above 1K, which still seems to work as far as I can tell. There was
already some really odd code that #undef'ed this value and redefined it
with the lower number in one .c file (unfortunately not the one with the
buffer declaration), with no explanation whatsoever... I'm removing that
and just assume the smaller value will be fine for everything.
BRANCH=veyron
BUG=None
TEST=Booted Pinky and Falco.
Change-Id: I440a5662b41cbd8b7becab3113262e1140b7f763
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3d3288041b6629b7623b9d58816e782e72836b81
Original-Change-Id: Idf80f44cbfb9617c56b64a5c88ebedf7fcb4ec71
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236976
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9481
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Using REG_PCI_POLL32 to check if the LINK is active with 50ms timeout.
BRANCH=none
BUG=chromium:431169
TEST=Test on Enguarde, compile ok and boot OS
Change-Id: If98ab4e31d17ec4e62d68b93edcec6d9aee87367
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: cf692ae9aebb43ab46cb07d36b62b300b16be1dc
Original-Change-Id: I490e6ffa40979628edf52a7444808b6d25a6e83d
Original-Signed-off-by: Kevin Hsieh <kevin.hsieh@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/231777
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/9478
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is being triggered because the base address is added, but
there is nothing that needs done with it in set_resources step
and the ERROR message is tripping suspend resume test scripts.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=boot on samus and check for ERROR strings,
successfully run suspend_stress_test without failures
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231603
(cherry picked from commit bb789492965d92e309a913dc7b9f09f7036c5480)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I565c8af954f1c5a406d2c65f01c274e9259e43ec
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 9062734d884f814dc880589ee615b4d7e1fdc61a
Original-Change-Id: I2b5f44795f1ee445d509b29bd56f498aea7b7fe3
Original-Reviewed-on: https://chromium-review.googlesource.com/231604
Original-Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Original-Tested-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9476
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some actions are needed and some are not on the way resume from S3.
BRANCH=master
BUG=chrome-os-partner:33025,chrome-os-partner:33796
TEST=Built the image and confimed the boot_mode is correctly
configured.
Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Change-Id: If400df94f970a55f3921a5a2df24038d28beb489
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 40e719618ec101235cdb1755933e719abd873239
Original-Change-Id: Ia042ea8c63c2306e9d6a80d8efa66c4fc0722d85
Original-Reviewed-on: https://chromium-review.googlesource.com/229615
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Kenji Chen <kenji.chen@intel.com>
Original-Tested-by: Kenji Chen <kenji.chen@intel.com>
Reviewed-on: http://review.coreboot.org/9475
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This combines the board version reading and parsing to
a separate file that is compiled in both romstage (for
early serial output) and ramstage (for smbios tables).
It also adds a new board version that is wrapped back
to number zero as we are running out of available IDs.
BUG=chrome-os-partner:32895
BRANCH=samus
TEST=build and boot on samus EVT1 and EVT2 and check
for proper board versions reported in console and smbios.
Change-Id: I8c8f17708ced7167277a98529ff4597589f53095
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3ab8bba1021a8dd41dd2210ba73efd2231eb596c
Original-Change-Id: I2aa03e7486a9581f94dc4e12f6f29eb0c5b3bdbb
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229041
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9473
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This adds a ramstage driver for the TPM and allows the interrupt
to be configured in devicetree.cb.
The interrupt vector is set like other PNP devices, and the
interrupt polarity is set with a register configuration variable.
These values are written into locality 0 TPM_INT_VECTOR and
TPM_INT_ENABLE and then all interrupts are disabled so they are
not used in firmware but can be enabled by the OS.
It also adds an ACPI device for the TPM which will configure the
reported interrupt based on what has been written into the TPM
during ramstage. The _STA method returns enabled if CONFIG_LPC_TPM
is enabled, and the _CRS method will only report an interrupt if one
has been set in the TPM itself.
The TPM memory address is added by the driver and declared in the
ACPI code. In order to access it in ACPI a Kconfig entry is added for
the default TPM TIS 1.2 base address. Note that IO address 0x2e is
required to be declared in ACPI for the kernel driver to probe correctly.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=manual testing on samus:
1) Add TPM device in devicetree.cb with configured interrupt and
ensure that it is functional in the OS.
2) Test with active high and active low, edge triggered and level
triggered setups.
3) Ensure that with no device added to devicetree.cb that the TPM
is still functional in polling mode.
Change-Id: Iee2a1832394dfe32f3ea3700753b8ecc443c7fbf
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: fc2c106caae939467fb07f3a0207adee71dda48e
Original-Change-Id: Id8a5a251f193c71ab2209f85fb470120a3b6a80d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226661
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9469
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This moves the LPC TPM driver to drivers/pc80/tpm so it can
be turned into a ramstage driver with a chip.h
It includes no other changes yet.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=emerge-samus coreboot
Change-Id: Iac83e52db96201f37a0086eae9df244f8b8d48d9
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: be2db391f9da80b8b75137af0fe81dc4724bc9d1
Original-Change-Id: I60ddd1d2a3e72bcf169a0b44e0c7ebcb87f4617d
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226660
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9468
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
I2C bus SDA hold time can be marginal with 60ns value, especially
when there is level shifter on the bus. So program it to 300ns
based on Fast-mode specification, which is between 0 to 900ns.
Apply the same timing for Standard-mode as well.
Refer to original bug on BayTrail chrome-os-partner:28092, this
is to carry forward the fix to Broadwell.
BRANCH=chromeos-2013.04
BUG=chrome-os-partner:33378
TEST=suspend resume test, watch for I2C errors
Change-Id: I93200b141602163903f5c9f52b94013bcf3382a5
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 72b82a1d5d836594e7d0f95972cc0dc91ae7ff8c
Original-Change-Id: I995d6868a44f2578a6d0b18dd5e8548f3c3cd494
Original-Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/226386
Original-Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9467
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
MEI PCI device has internal logic to flush out the posted writes
before returning completion for non-posted request. When doing a RCBA
write to function disable and then using the PCI CFG RD cycle, need
to do RCBA posting read after writing to it to make sure the write
went through.
As Aaron sugegsted, abstracted function disable path to a common
function.
BUG=chrome-os-partner:33048
TEST=run warm and cold reboot testing
Change-Id: I40d374f1712a9137b3b1eac6bbf2d71078840406
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: f10b368e01aae1fc5dda63f7ac0641dd2636c949
Original-Change-Id: I87aa8ccd604446263fc3621c9a01839a5a75b644
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/223715
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9462
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:31424
TEST=Build a image and run on Samus proto boards to confirm if the
settings are applied correctly.
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Change-Id: I9147da86ce26ce7ef1c7034bc3dde0b27b63befa
Original-Commit-Id: 1717505a3fdf41c5972b1c929872577247f9e3b5
Original-Signed-off-by: Kenji Chen <kenji.chen@intel.com>
Original-Change-Id: I8138507506771148420a585fd12897a3bfe91916
Original-Reviewed-on: https://chromium-review.googlesource.com/221387
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/9463
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
DDI-A should not need re-enabled in the resume path, just
the resume path when we did not execute VBIOS.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus, test suspend+resume
Change-Id: I29d67591ac903bc1d712a956462bcf4a764ef2eb
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: c3fbeac10f3834a6d848154aa3449672871b13df
Original-Change-Id: Iaf7d083c5c92c42b7a117e2d2c9546ada6bf5f76
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/221988
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9461
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to report the GPE that woke the system to the kernel
coreboot needs to keep track of the first GPE wake source and
save it in NVS so it can be returned in \_GPE._SWS method.
This is similar to the saving of PM1 status but needs to go
through all the GPE0_STS registers and check for enabled and
triggered events.
A bit of cleanup is done for areas that were touched:
- platform.asl was not formatted correctly
BUG=chrome-os-partner:8127
BRANCH=samus,auron
TEST=manual:
- suspend/resume and wake from EC event like keyboard:
ACPI _SWS is PM1 Index -1 GPE Index 112 ("special" GPIO27)
- suspend/resume and wake from RTC event:
ACPI _SWS is PM1 Index 10 GPE Index -1 (RTC)
- suspend/resume and wake from power button:
ACPI _SWS is PM1 Index 8 GPE Index -1
- suspend/resume and wake from touchpad:
ACPI _SWS is PM1 Index -1 GPE Index 13
- suspend/resume and wake from WLAN:
ACPI _SWS is PM1 Index -1 GPE Index 10
Change-Id: I574f8cd83c8bb42f420e1a00e71a23aa23195f53
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: d4e06c7dfc73f2952ce8f81263e316980aa9760f
Original-Change-Id: I9bfbbe4385f2acc2a50f41ae321b4bae262b7078
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220324
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9460
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Most Baytrail based devices MMIO registers are reported in ACPI
space and the device's PCI config space is disabled. The PCI config
space is required for many "legacy" OSs that don't have the ACPI
driver loading mechanism. Depthcharge signals the legacy boot
path via the SMI 0xCC and the coreboot SMI handler can switch the
device specific registers to re-enable PCI config space.
BUG=chrome-os-partner:30836
BRANCH=None
TEST=Build and boot Rambi SeaBIOS.
Change-Id: I87248936e2a7e026f38c147bdf0df378e605e370
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: dbb9205ee22ffce44e965be51ae0bc62d4ca5dd4
Original-Change-Id: Ia5e54f4330eda10a01ce3de5aa4d86779d6e1bf9
Original-Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219801
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Mike Loptien <mike.loptien@se-eng.com>
Original-Tested-by: Mike Loptien <mike.loptien@se-eng.com>
Reviewed-on: http://review.coreboot.org/9459
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Changes:
acpi.c - Capitalize an acronym.
early_spi.c - Spelling error.
gpio.c - Capitalization of acronym + sentences.
gpio.h - Capitalization of sentences.
lpc.c - Capitalization of sentences.
soc.c - Spelling error + capitalization of acronym.
I just wanted to go through the process of commiting something onto Gerrit.
Change-Id: Iad2ac5409f883c5b7cbc25e4e296f386ad7e13d0
Signed-off-by: nicky sielicki <nlsielicki@wisc.edu>
Reviewed-on: http://review.coreboot.org/9510
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Before the change to use vb2_api.h, coreboot needed to know where to
find the vboot2 header files. Now those are all included by
vb2_api.h, so coreboot doesn't need to know about
firmware/2lib/include (and in fact, the 2lib directory is about to go
away).
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
Original-Change-Id: I7f69ca9cf8d45c325219efceca0cb8d1340f7736
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233223
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit b4d4a2da1c8b5a5f8f8da51f009227d3a616b096)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I4006f38835ea0f927142a8133bc24caaf2b7a214
Reviewed-on: http://review.coreboot.org/9447
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This will allow vboot2 to continue refactoring without breaking
coreboot, since there's now only a single file which needs to stay in
sync.
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
CQ-DEPEND=CL:233050
Original-Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233051
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit df55e0365de8da85844f7e7b057ca5d2a9694a8b)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I999af95ccf8c326f2fd2de0f7da50515e02ad904
Reviewed-on: http://review.coreboot.org/9446
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Apparently our initial submission of 16K was a little too generous for
the vboot2 work buffer, and I hear that we should also be well within
bounds for 12K. This patch reduces the minimum asserted by memlayout so
some of our low-mem boards can get a few more kilobytes back for
discretionary spending. Also changes the required minimum alignment to 8
since that's what the current vboot code aligns it to anyway, and add a
warning comment to make it clearer that this is a dangerous number
people should not be playing with lightly.
BRANCH=None
BUG=None
TEST=Built and booted on Pinky.
Original-Change-Id: Iae9c74050500a315c90f5d5517427d755ac1dfea
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232613
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 64e972f10363451cd544fdf8642bd484463703bc)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I362b8c33cf79534bb76bd7acda44d467563fe133
Reviewed-on: http://review.coreboot.org/9445
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
PHYSICAL_REC_SWITCH is set n by default and y for panther and stumpy.
BUG=none
BRANCH=ToT
TEST=Built nyan_blaze using vboot1/2. Built falco, lumpy, nyan,
blaze, parrot, rambi, samus, storm, pinky with default configuration.
panther and stumpy are not tested because they currently don't build on ToT.
Original-Change-Id: Ic45f78708aaa7e485d2ab459fd1948524edb412f
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227940
Original-Reviewed-on: https://chromium-review.googlesource.com/229602
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit edb2ba347b48887ffe450586af0351e384faad59)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I277f665cd4f3e1c21745cdc5c7a2cfe148661abe
Reviewed-on: http://review.coreboot.org/9444
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This adds the RAM config code to the coreboot tables. The purpose is
to expose this information to software running at higher levels, e.g.
to print the RAM config coreboot is using as part of factory tests.
The prototype for ram_code() is in boardid.h since they are closely
related and will likely have common code.
BUG=chrome-os-partner:31728
BRANCH=none
TEST=tested w/ follow-up CLs on pinky
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Idd38ec5b6af16e87dfff2e3750c18fdaea604400
Original-Reviewed-on: https://chromium-review.googlesource.com/227248
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 77dd5fb9347b53bb8a64ad22341257fb3be0c106)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ibe7044cafe0a61214ac2d7fea5f7255b2c11829b
Reviewed-on: http://review.coreboot.org/9438
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
The architectiure check in fmap.c is in fact used to delineate between
platforms where SPI flash is mapped to memory address space and where
it needs to be accessed through CBFS.
In fact cosmos board uses an ARM SOC which also maps SPI flash to
processor address space, this will have to be addressed when that
SOC's support is introduced, for now let's just presume that all but
X86 platforms require CBFS layer to access fmap.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Original-Change-Id: Id135dc63278555a7fc5039a568fb28864f7cb8d1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226180
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit b3c04f84504380066c54a6dec93781a4f25a5fc6)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I3a0a70fe583b69b1c9cd8729817bd7062126e1a9
Reviewed-on: http://review.coreboot.org/9436
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This patch adds functions looking in the VPD for WiFi calibration
data, and if found, copying the calibration blobs into CBMEM.
Two possible key names templates are used: wifi_base64_calibrationX
and wifi_calibrationX, where X is replaced by the WiFi interface
number. Up to four interfaces can be provisioned.
The calibration data will be retrieved from CBMEM by the bootloader
and placed into the device tree before starting the kernel.
The structure of the WiFi calibration data CBMEM entry is defined
locally: it is a concatenation of the blob names and their contents.
Each blob is padded as necessary to make sure that the size divisible
by four.
To make sure that the exactly required amount of memory is allocated
for the CBMEM entry, the function first scans the VPD, caching the
information about the available blobs and calculating their combined
size.
Then the required size CBMEM entry is allocates and the blobs are
copied into it.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=when this function is called, and the VPD includes calibration
data blobs, the WIFI entry shows up in the list of CBMEM entries
reported by coreboot.
Original-Change-Id: Ibe02dc36ff6254e3b9ad0a5bd2696ca29e1b2be3
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225271
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 9fe185ae5fdc1a896bf892b498bff27a3462caeb)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia60f0c5c84decf9854426c4f0cb88f8ccee69046
Reviewed-on: http://review.coreboot.org/9435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
SeaBIOS doesn't like CC and LD to contain arguments, so split
those out.
Change-Id: Id651719d529adfa8602a3e4f6685228330f36432
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9378
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kevin O'Connor <kevin@koconnor.net>
Adds AM1ML board. This board has AM1 Socket and supports all
new AM1 APUs from AMD. Based on asrock/imb-a180 board.
Successfully tested with SeaBIOS and Linux 3.8.x and Windows XP.
Successfully tested audio, video, network, PS/2 keyboard and mouse,
PCIe x16, COM port, SATA and USB.
LPT port is not tested yet and it’s unknown if it’s work.
Change-Id: I9ebb9acc590d38e47579adc263f45ae3f607684e
Signed-off-by: Sergej Ivanov <getinaks@gmail.com>
Reviewed-on: http://review.coreboot.org/9293
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Adds option FORCE_AM1_SOCKET_SUPPORT to disable
package type mismatch check between cpu and northbridge.
Default agesa for kabini doesn't know about AM1 socket
so it returns FALSE, that stops memory config code.
With this hack current agesa version supports the AM1 socket.
Change-Id: I99e9cec5cd558087092cf195094df20489f6d3b5
Signed-off-by: Sergej Ivanov <getinaks@gmail.com>
Reviewed-on: http://review.coreboot.org/9291
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
In agesa code for hudson southbridge LPC_DEV is not defined,
but used. Define LPC_DEV as done in southbridge/amd/cimx/sb800.
This fixes it.
Change-Id: Ie7db791e9eb607008e70e446fc6fd28114742750
Signed-off-by: Sergej Ivanov <getinaks@gmail.com>
Reviewed-on: http://review.coreboot.org/9292
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
This isn't done in upstream.
Change-Id: Ief1fea0f231d609372f065f6f6aee7bceaf31efc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9458
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
That variable isn't used anymore and the include statement
is already covered in CPPFLAGS_common further down that file.
Change-Id: I3e4fd3281dc0d3f73b238e121dbdfc0d29102b27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9448
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This should allow the max98090 codec to play beeps via
AHUB/I2S1 thru the depthcharge sound driver.
BUG=none
BRANCH=none
TEST=Saw max98090 codec init signon and register dump.
No sound yet.
Change-Id: I1ee0b61f5cbfe587ebd16b7dd9dce08d9d62c2c5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f4ee2ce3704711a9e00531b7599a1bcf194203ec
Original-Change-Id: I0bc8401e76b2c80a01083ac933a39f6cd4d1b78a
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229496
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Mike Frysinger <vapier@chromium.org>
Reviewed-on: http://review.coreboot.org/9429
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If all devices under AHUB (AUDIO/I2S/DAM/ADX/etc) aren't
clocked and taken out of reset, any access to any audio
peripheral will hang the system.
BUG=none
BRANCH=none
TEST=built both Rush and Ryu OK.
Change-Id: Iee8e33f005c5abaf09a14104c0b243b06eb4af24
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0016bd533864942225f2fb8e08ce871a186f2746
Original-Change-Id: I741d5ba4dd8bd963b6d261fbf41cfb77c274cb79
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229910
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Mike Frysinger <vapier@chromium.org>
Reviewed-on: http://review.coreboot.org/9428
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I2C1 was missing in the funit/i2c/addressmap tables/code.
BUG=none
BRANCH=none
TEST=Built Rush and Ryu. Built Rush w/code in mainboard.c
to enable I2C1 for the MAX98090 audio codec - codec could be
configured.
Change-Id: I0c678d21546eedb7404a1d3d4329da777430fc97
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4b623097a2adc4464c17bceed96ec3838beda985
Original-Change-Id: Ibe4f012fa2d427b95cd4672687132b47576b6a9a
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229574
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9427
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The TPS65913 PMIC has an RTC built into it. This change adds
a driver for it which implements the new RTC API.
BUG=chrome-os-partner:33764
BRANCH=None
TEST=Compiles and boots to kernel prompt on ryu. Timestamps for event log
verified across multiple boots.
Change-Id: I49ec9b78afc53f1cbd4be09e448cdae6077fb710
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c16c11e620c830e7a73a2a24fe4823ccea0f3c39
Original-Change-Id: If1d549ea2361d0de6be75fd24b9e9810a6df7457
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229414
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9425
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Provide support for SoCs to participate in PSCI commands.
There are 2 steps to a command:
1. prepare() - look at request and adjust state accordingly
2. commit() - take action on the command
The prepare() function is called with psci locks held while
the commit() function is called with the locks dropped.
No SoC implements the appropriate logic yet.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Booted PSCI kernel -- no SMP because cmd_prepare()
knowingly fails. Spintable kernel still brings up both
CPUs.
Change-Id: I2ae4d1c3f3eac4d1060c1b41472909933815d078
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 698d38b53bbc2bc043548792cea7219542b5fe6b
Original-Change-Id: I0821dc2ee8dc6bd1e8bc1c10f8b98b10e24fc97e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226485
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9423
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Newly turned on CPUs need a place to go bring its EL3
state inline with expectations. Plumb this path in for
CPUs turning on as well as waking up from a power down
state. Some of the infrastructure declarations were
moved around for easier consumption in ramstage and
secmon. Lastly, a psci_soc_init() is added to
inform the SoC of the CPU's entry point as well do
any initialization.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted. On entry point not actually utilized.
Change-Id: I2af424c2906df159f78ed5e0a26a6bc0ba2ba24f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: dbefec678a111e8b42acf2ae162c1ccdd7f9fd40
Original-Change-Id: I7b8c8c828ffb73752ca3ac1117cd895a5aa275d8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228296
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9422
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Enable display only developer and recovery mode.
Will add in the actual display supporting functions in coming
patches.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I0d312fd132dc310813432f4d8a28ad16c9bb36aa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: dd1bd56e83532c77d675f72b301b413cbcf3f489
Original-Change-Id: Idfa24d23c81baaedb944d2b9835255edad4e422b
Original-Reviewed-on: https://chromium-review.googlesource.com/226904
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: http://review.coreboot.org/9421
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
1. Add page address, an i2c address, into register address table
2. Add pmic read function
3. Add more registers and setting values.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: Ieef0737205b20add3ff8990f62dd8585a4e8c557
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6dcf42c299e25023991be331b724acd0fd9f32c2
Original-Change-Id: I227b3e9390e6fc020707d4730c19945760df6ca2
Original-Reviewed-on: https://chromium-review.googlesource.com/226902
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: http://review.coreboot.org/9420
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Take codec out of reset (GPIO_PH1 aka CODEC_RST_L) and enable LDO2
(GPIO_PR2/KB_ROW2 aka AUDIO_ENABLE). Muxes are setup and the two
GPIOs are set to output and driven high.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=RealTek ALC5677 codec shows up in I2C6 scan at address 0x2D,
can read/write registers.
Change-Id: I236850452d401fd89b4f59eb03f132c0be32fb20
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4fe3b0c1a3f5d6264b83d7a7e2363dc3f3235cbf
Original-Change-Id: Iedce7bb9f8e61d3b8cd693fc5e567323d89f8046
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/228920
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9419
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Proto 0,1,2 boards had pwr btn active high. Proto 3 onwards boards will have pwr
btn active low. Thus, select power btn polarity based on board id.
BUG=chrome-os-partner:33545
BRANCH=None
TEST=Compiles successfully and boots to kernel prompt on ryu proto 1.
Change-Id: I9b06b10358b91d40cfdb418ef8cf4da1ae833121
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7100a42b53a09ed4cb298f88d6f804f46fecacb5
Original-Change-Id: Icdf51b9324385de00f5787e81018518c5397215f
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/229011
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9418
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since gpio.c is more generic now and will be used in various
stages (ie for board_id()), compile it for all stages.
BUG=none
BRANCH=none
TEST=compiled for peppy and veyron_pinky
Change-Id: Ib5c73f68db92791dd6b42369f681f9159b7e1c22
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ef4e40ccf6510d63c4a54451bdfea8da695e387e
Original-Change-Id: I77ec56a77e75e602e8b9406524d36a8f69ce9128
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228325
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9414
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This deprecates TERTIARY_BOARD_ID. Instead, a board will set
BOARD_ID_SUPPORT (the ones affected already do) which will set
GENERIC_GPIO_SUPPORT and compile the generic GPIO library.
The user is expected to handle the details of how the ID is encoded.
BUG=none
BRANCH=none
TEST=Compiled for peppy, nyan*, storm, and pinky
Change-Id: Iaf1cac6e90b6c931100e9d1b6735684fac86b8a8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 93db63f419f596160ce2459eb70b3218cc83c09e
Original-Change-Id: I687877e5bb89679d0133bed24e2480216c384a1c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228322
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9413
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This adds gpio_base2_value() which reads an array of 2-state
GPIOs and returns a base-2 value, where gpio[0] represents the
least significant bit.
BUG=none
BRANCH=none
TEST=tested with follow-up patches for pinky
Change-Id: I0d6bfac369da0d68079a38de0988c7b59d269a97
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 27873b7a9ea237d13f0cbafd10033a8d0f821cbe
Original-Change-Id: Ia7ffc16eb60e93413c0812573b9cf0999b92828e
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228323
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9412
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch makes a few cosmetic changes:
- Rename tristate_gpios.c to gpio.c since it will soon be used for
binary GPIOs as well.
- Rename gpio_get_tristates() to gpio_base3_value() - The binary
version will be called gpio_base2_value().
- Updates call sites.
- Change the variable name "id" to something more generic.
BUG=none
BRANCH=none
TEST=compiled for veyron_pinky and storm
Change-Id: Iab7e32f4e9d70853f782695cfe6842accff1df64
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c47d0f33ea1a6e9515211b834009cf47a171953f
Original-Change-Id: I36d88c67cb118efd1730278691dc3e4ecb6055ee
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228324
Reviewed-on: http://review.coreboot.org/9411
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Our CBFS header offset on rk3288 was very low and overlapped with the
end of the bootblock on recent Pinky builds. This can create all kinds
of fun effects like BSS variables suddenly being initialized to
something else than zero, in an effect that jumps somewhere else for
every slightest code size change.
This patch moves the CBFS header offset up a bit and the CBFS ROM offset
down (because there's really no point in leaving such a large gap). This
resolves our immediate booting problems, and I'll also start on a patch
to add further checks somewhere that catch these overlaps in the future.
BRANCH=None
BUG=None
TEST=Created a Pinky image from the exact same commit version as the
official 6443.0.0 build, with a KERNELREVISION string of the exact same
length as the builder (which for some arcane reason is different than
running emerge locally, shifting the whole bootblock around with it).
Confirmed that I saw the same "Not enough room for another
sub-pagetable!" hang, and that this patch fixes it.
Change-Id: I9e59a282b3cd0af3b0d224d64c10b7c4d312ad02
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a142cd2c51c6f51a1597c21ad513feb151e0938
Original-Change-Id: I8be5b7b7e87021cc1b3a91d336e8d233546ee188
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228326
Original-Reviewed-by: Gediminas Ramanauskas <gedis@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9410
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since the LAST_THSUT bit is uncertain value when it cold-reboot,
we remove the printout about this status bit in coreboot.
BUG=chrome-os-partner:33521
TEST=Boot on veyron_pinky rev2
Change-Id: I3b9791ffdffeff0721e3d86378db6255c5abc9ea
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 16464d3229ad1001952ef1b50fe3e606d1583462
Original-Change-Id: I258750797e32c28f86e73a01eede005e890a6906
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/228391
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9409
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
slowly raise to max cpu voltage to prevent overshoot,
and in our experience,when cpu run in 1.8GHz,the
vdd_cpu must up to 1.4V
BUG=chrome-os-partner:32716, chrome-os-partner:31896
TEST=Boot on veyron_pinky rev2,check the rk808 buck1 voltage 1400mv
and measure the overshoot is 1440mv
Change-Id: I759840bd8cf57a5589bf1862d04803f80f804164
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 567f616ff091883ed3275b407859c9399db981b2
Original-Change-Id: I9bb739b49ae4b4f7a60133fa38b0fe51b95c0d78
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/226753
Original-Reviewed-by: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9408
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are changes in upcoming board revs that need to take
different action depending on board revision. Update the
enumeration to reflect upcoming reality.
BUG=chrome-os-partner:33578
BRANCH=None
TEST=Built and booted.
Change-Id: Ib51393e04d3255bbd44e5d77a2a7903109beebf4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: de8d629678c0ae17af9f7145e04d95f43c927ee0
Original-Change-Id: I64cdeab806e7a665051f1d47bbf044413f7a1196
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227681
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9407
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The gpio_get_tristates() function prints out the values
observed while processing the GPIOs. Additionally, the
values for the normalization were completely consecutive.
Therefore, this indirection can be removed.
BUG=chrome-os-partner:33578
BRANCH=None
TEST=Built and booted.
Change-Id: I088a2f1c7601c014a7f8a9eb228efa9bb80f1e01
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 02e52554b9cbf85034feb9aedc50f09b70893e32
Original-Change-Id: I17d85891087e3128790329a5f05cbdab4cbc950e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227680
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9406
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Add the Whirlwind board ID to the enum
- Replace comparisons of the board ID with 0 to the proto0 constant
TEST=Booted Storm with this coreboot version
BUG=none
BRANCH=none
Change-Id: I53be0b06c3444936a8bd67653e03b93bcb87e328
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7e055ef27ef1e07be09d80b2298384889214bf0d
Original-Change-Id: I75c7c98732c3d4569611de54d7aa149dd3b0fb7d
Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225460
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9404
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The new API allows to find VPD objects in the VPD cache. There is no
need for the caller to allocate or free the per object memory.
The existing API (cros_vpd_gets) now uses the new function as well.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that MAC addresses still show up in the device tree on
the booted storm device
Change-Id: Id06be315981cdaa2285fc1ec61b96b62b1178a4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 99a34344448a5521cee8ad3918aefb1fde28417d
Original-Change-Id: I6c0b11bb844d6235930124d642da632319142d88
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225258
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/9403
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch runs basic NAND initialization code on Proto 0.2 boards which
have been reworked for NAND. It makes sense to do this in coreboot for
two reasons:
- In general, it is reasonable for coreboot to initialize clocks and such
in preparation for depthcharge's use. Waiting times can be pooled, and
the initialization itself here is very fast.
- There is a kernel bug which requires that the clock is already initialized
before the kernel loads NAND support. coreboot is a more sensible place
to put a workaround than depthcharge because depthcharge initializes
things lazily, but when booting from USB, depthcharge won't need to look
at NAND.
This change involves bringing in an additional header file, ebi2.h, from U-Boot.
TEST=Booted a kernel from USB and verified that NAND came up without any
depthcharge hacks, whereas previously a USB-booted kernel would be unable
to access NAND even with the same drivers compiled in due to an initialization
failure.
BUG=chromium:403432
BRANCH=none
Change-Id: I04e99cb39d16848a6ed75fe0229b8f79bdf2e035
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9be29da5ccad9982f146ae00344f30598ef2371c
Original-Signed-off-by: Dan Ehrenberg <dehrenberg@chromium.org>
Original-Change-Id: I1760ecb4e47438311d80e34326e45578c608481c
Original-Reviewed-on: https://chromium-review.googlesource.com/225277
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9402
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The function to read board IDs from tristate GPIOs currently supports
two output modes: a normal base-3 integer, or a custom format where
every two bits represent one tristate pin. Each board decides which
representation to use on its own, which is inconsistent and provides
another possible gotcha to trip over when reading unfamiliar code.
The two-bits-per-pin format creates the additional problem that a
complete list of IDs (such as some boards use to build board-ID tables)
necessarily has "holes" in them (since 0b11 does not correspond to a
possible pin state), which makes them extremely tricky to write, read
and expand. It's also very unintuitive in my opinion, although it was
intended to make it easier to read individual pin states from a hex
representation.
This patch switches all boards over to base-3 and removes the other
format to improve consistency. The tristate reading function will just
print the pin states as they are read to make it easier to debug them,
and we add a new BASE3() macro that can generate ternary numbers from
pin states. Also change the order of all static initializers of board ID
pin lists to write the most significant bit first, hoping that this can
help clear up confusion about the endianness of the pins.
CQ-DEPEND=CL:219902
BUG=None
TEST=Booted on a Nyan_Blaze (with board ID 1, unfortunately the only one
I have). Compiled on Daisy, Peach_Pit, Nyan, Nyan_Big, Nyan_Blaze, Rush,
Rush_Ryu, Storm, Veryon_Pinky and Falco for good measure.
Change-Id: I3ce5a0829f260db7d7df77e6788c2c6d13901b8f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2fa9545ac431c9af111ee4444d593ee4cf49554d
Original-Change-Id: I6133cdaf01ed6590ae07e88d9e85a33dc013211a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219901
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9401
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e
Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Retrieving MAC address from VPD should be the board responsibility,
add a call to the recently introduced function.
BRANCH=storm
BUG=chromium:417117
TEST=verified that MAC addresses still show up in the device tree on
storm
Change-Id: Ib8ddc88ccd859e0b36e65aaaeb5c9473077c8c02
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 285cb256e619ef41c7f11680b3fa5310b1d93cf1
Original-Change-Id: I3913b10a425d8e8621b832567871ed4861756381
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223797
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9399
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Retrieval of the MAC address from the VPD is a Chrome OS specific
feature, required just on one platform so far. There is no need to
look for the MAC address in the VPD on all other Chrome OS boards.
BRANCH=storm
BUG=chromium:417117
TEST=with the upcoming patch applied verified that MAC addresses still
show up in the device tree on storm
Change-Id: If5fd4895bffc758563df7d21f38995f0c8594330
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fb4906ac559634321a01b4814f338611b9e98b2b
Original-Change-Id: I8e6f8dc38294d3ab11965931be575360fd12b2fc
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223796
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9398
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of relying on CONFIG_MAX_CPUS to be the number of
CPUs running a platform pass the number of online cpus
from coreboot secmon. That allows for actually enabled
CPUs < CONFIG_MAX_CPUS.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Booted SMP kernel.
Change-Id: Iaf1591e77fcb5ccf5fe271b6c84ea8866e19c59d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3827af876c247fc42cd6be5dd67f8517457b36e7
Original-Change-Id: Ice10b8ab45bb1190a42678e67776846eec4eb79a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227529
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9397
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The struct cpu_action already tracks entry/arg pointers. Use that
instead of duplicating the same information.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted.
Change-Id: I70e1b471ca15eac2ea4e6ca3dab7d8dc2774a241
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cdddfd8d74d227cb5cbdf15b6871480839fa20d8
Original-Change-Id: I4070ef0df19bb1141a1a47c4570a894928d6a5a4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227549
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9396
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current implementation of secmon assumes just entry/arg
are passed to secmon for starting up a CPU. That's lacking
in flexibility. Therefore change secmon_params to contain
both the BSP and secondary CPUs' entry/arg information.
That way more information can be added to secmon_params when
needed.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted SMP kernel using PSCI and spin table.
Change-Id: I84c478ccefdfa4580fcc078a2491f49f86a9757a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c5fb5bd857a4318174f5b9b48e28406e60a466f8
Original-Change-Id: Iafb82d5cabc806b6625799a6b3dff8d77bdb27e9
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227548
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9395
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There is state within the system that relies on having
all CPUs present in order to proceed with initialization.
The current expectation is that all CPUs are online and
entering the secure monitor. Therefore, wait until all
CONFIG_MAX_CPUs show up.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Can get all CPUs up in kernel using PSCI.
Change-Id: I741a09128e99e0cb0c9f4046b1c0d27582fda963
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 030535b7c9821b40bf4a51f88e289eab8af9aa13
Original-Change-Id: Ia0f744c93766efc694b522ab0af9aedf7329ac43
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227547
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change sets the stack pointer to the value specified in
memlayout.ld before jumping to the bootblock.
BUG=none
BRANCH=ToT
TEST=Built cosmos and all other current boards.
Change-Id: Ic1b790f27bce431124ba70cc2d3d3607c537564b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d50fd02db8bf10147fd808f3030e6297b9ca0aad
Original-Change-Id: I4bb8cea7435d2a0e2c1ced050c3366d2e636cb8a
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225420
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9384
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this adds an entry point jumping to main for the bootblock.
BUG=None
BRANCH=ToT
TEST=Built coreboot for cosmos
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1c9ea6ba63a1058e09613d969fe00308260037be
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 662d0083f25008b55b9bc5fbce9e30e6b80c2c65
Original-Change-Id: I74f2f5e3b3961ab54a7913e6b3a3ab0e6fd813a3
Original-Reviewed-on: https://chromium-review.googlesource.com/225205
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9382
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Use 'DEVICE_NOOP' macro introduced in:
commit 530355d include/device/device.h: Provide DEVICE_NOOP macro shim
to provide formalism. Make the null device ops here explicit and
in-line with formalism elsewhere.
Change-Id: I2400b29a5108a6bae21959177e53321810ca1407
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/8035
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This patch aligns bg4cd to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Cosmos.
Change-Id: I32a4407f7deb2b1752b6220a140352724f320637
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0b6bb6990417863010258632374c3f5ac19350c9
Original-Change-Id: Ia5299659ad186f2e7d698adfa7562396e747473f
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224506
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9358
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The SOC code should include the SPI controller driver when configured.
Enable SPI support for cosmos.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=cosmos builds
Change-Id: I8212f191b7d80f0bee86f746813edaf8e5ee6db1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd4853be5157247bb73fc22b9d4f8300228fe6ce
Original-Change-Id: If7e12e2fb04e63c36d9696d13e08397b91a77a8c
Original-Commit-Id: 7b1d095e5df6a864d3564bbf7a20cc211f75629a
Original-Change-Id: If9dd80cb96120d34a0865f7882cd62e45fed749d
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223750
Original-Reviewed-on: https://chromium-review.googlesource.com/223752
Reviewed-on: http://review.coreboot.org/9356
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The arch_run_on_all_cpus[_async]() APIs can run the BSP before
the APs if the BSP's id is less than the APs' ids. Fix this by
ensuring we run the necessary callback on all but self.
BUG=chrome-os-partner:33532
BRANCH=None
TEST=Booted spin table kernel. All CPUs are up.
Change-Id: Ic9a466c3642595bad06cac83647de81873b8353e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 575437354cc20eeac8015a0f7b0c9999ecb0deee
Original-Change-Id: I87e944f870105dbde33b5460660c96c93c3cdf93
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227488
Original-Tested-by: David Riley <davidriley@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9392
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Need to configure debug uart port to have proper baudrate/width/parity.
Hard-code it to 115200n8.
BUG=chrome-os-partner:32015
BRANCH=None
TEST=successfully suspend/resume on Rush/Ryu
Change-Id: I502fd8361baf2bea642fabbc4d5e126da5411ba3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8c70625ad41efca9117c8682113b226e929e93c5
Original-Change-Id: I6a96c80654ce52f5b877fd46995ca8c1aceb7017
Original-Signed-off-by: Yen Lin <yelin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/226407
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9391
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to properly support more arm64 SoCs PSCI needs
to handle the hierarchy of cpus/clusters within the SoC.
The nodes within PSCI are kept in a tree as well as
a depth-first ordered array of same tree. Additionally,
the PSCI states are now maintained in a hierachal manner.
OFF propogates up the tree as long as all siblings are
set to OFF. ON propogates up the tree until a node is
not already set to OFF.
The SoC provides the operations for determining how many
children are at a given affinity level. Lastly, the
secmon startup has been reworked in that all non-BSP CPUs
wait for instructions from the BSP.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Can still boot into kernel with SMP.
Change-Id: I036fabaf0f1cefa2841264c47e4092c75a2ff4dc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 721d408cd110e1b56d38789177b740aa0e54ca33
Original-Change-Id: I520a9726e283bee7edcb514cda28ec1eb31b5ea0
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226480
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9390
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The cpu_info struct can be easily obtained at runtime
based on smp_processor_id(). To allow easier mapping
between cpu_info and PSCI entities add the mpidr info
to the cpu_info struct.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted in SMP. Noted MPIDR messages for each cpu.
Change-Id: I390392a391d953a3b144b56b42e7b81f90d5fec1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d091706f64f1fc4b1b72b1825cab82a5d3cbf23e
Original-Change-Id: Ib10ee4413d467b22050edec5388c0cae57128911
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226481
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9388
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This file provides the SOC specific SPI driver API, it needs to be
filled up with code. Function descriptions can be found in
src/include/spi-generic.h.
BRANCH=none
BUG=chrome-os-partner:32631
TEST=compiles with the upcoming patches applied.
Change-Id: I3546d5f9fb2971f4ccb7a57ce8164fd77686af72
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0583f17fe3f6a258321765b91eae608e33577afe
Original-Change-Id: I0ee04ca17874a13403007bba80d5e8a7708bc625
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223719
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9355
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Corrected platform ID and added timer frequency for SOC.
The timer frequency is half the CPU frequency.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; behaves as expected.
BRANCH=none
Change-Id: If7e03232106b52f2522fc7da586bdaf95f5eefec
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: d94789950d5300bbe5defbf529480d8d545e743e
Original-Change-Id: I1187e4b5280eaf796777d882a2e154e2808e9e37
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/241426
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9193
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With this descriptor added ramstage properly allocates memory
resources and creates entries in coreboot table. This also allows to
proceed to booting depthcharge, as it now can be loaded into the
existing memory.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the set of patches applied the firmware properly finds
depthcharge in CBFS, uncompresses it and attempts to start:
...
Booting payload fallback/payload from cbfs
Loading segment from rom address 0x9b000058
code (compression=1)
New segment dstaddr 0x80124020 memsize 0x2099a0 srcaddr 0x9b000090 filesize 0xbbe
Loading segment from rom address 0x9b000074
Entry Point 0x80124038
Loading Segment: addr: 0x0000000080124020 memsz: 0x00000000002099a0 filesz: 0x0000000000000bbe
lb: [0x0000000080000000, 0x0000000080013858)
Post relocation: addr: 0x0000000080124020 memsz: 0x00000000002099a0 filesz: 0x0000000000000bbe
using LZMA
[ 0x80124020, 8012596c, 0x8032d9c0) <- 9b000090
Clearing Segment: addr: 0x000000008012596c memsz: 0x0000000000208054
dest 80124020, end 8032d9c0, bouncebuffer 8ffd4f50
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 129 run 34579421 exit 129
Jumping to boot code at 80124038
ERROR: dropped a timestamp entry
CPU0: stack: 9a00c800 - 9a00d800, lowest used address 9a00d498, stack used: 872 bytes
entry = 80124038
Change-Id: I15809e146407d66b04f2a97c47c961fdccb8e175
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a1577c5532a064426a3ea88b6f7f30ccdae24eaf
Original-Change-Id: Ifed5550f2c18430e9ae06ad1ecacaa13191b5995
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232571
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9192
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With the code now running on the FPGA board it makes sense to correct
the memory layout definitions to match the actual hardware.
Note that the latest FPGA board firmware introduced support of the
additional 128KB of SRAM (called GRAM) at base address of 0x9a000000.
These are still interim values, which will be tweaked when the actual
bring up board is available.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=the code put into SPI NOR flash boots all the way to ramstage.
Change-Id: I00aa5bc3aabba50df2187bb208cf2fcd11b26b3d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a6378be5cd304744b40c57a34d7a276233d45779
Original-Change-Id: I50183c2d5f9017801d5c8a7a7addf08efa492b35
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229203
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9337
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
32K is a more appropriate room for Pistachio bootblock.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=there is no bootblock overflow even when compiled with -O0.
Change-Id: I454746ce0b9daabc93ccbf3316655fac836af8ff
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 56adf22ba12f5a7c69d11c0c720996de32ca9149
Original-Change-Id: I74b6674aea95b1138e2168527239e2cfb4a7ad42
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232291
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9190
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
C0_COUNT register is a free running counter clocked by the CPU
frequency divided by two. On the FPGA board it results in 25 MHz, on
real SOCs it will have to be figured out later.
Some magic addresses and numbers are used to find out if the code is
running on the FPGA board.
timestamp_get() and timer_monotonic_get() are kept in the same file.
The CPU initialization makes sure that CO COUNT is in fact enabled and
starts from zero.
BRANCH=none
BUG=chrome-os-partner:33595,chrome-os-partner:31438
TEST=with timer enabled, the startup code properly initializes UART
and prints the coreboot bootblock banner message on the serial
console.
Change-Id: I98fe330b961f677448b222917ab7d586494ed4b7
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: a7324221c1d856ac72fa2b0ab586b5ea8cab3a05
Original-Change-Id: I2d518213de939e91a35f8aea174aed76d297dd72
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227888
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9188
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add GENERIC_UDELAY Kconfig option so that a generic
udelay() implementation is provided utilizing the
monotonic timer. That way each board/chipset doesn't
need to duplicate the same udelay(). Additionally,
assume that GENERIC_UDELAY implies init_timer()
is not required.
BUG=None
BRANCH=None
TEST=Built nyan, ryu, and rambi. May need help testing.
Change-Id: I7f511a2324b5aa5d1b2959f4519be85a6a7360e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1a85fbcad778933d13eaef545135abe7e4de46ed
Original-Change-Id: Idd26de19eefc91ee3b0ceddfb1bc2152e19fd8ab
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219719
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9334
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch aligns tegra124 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Nyan, Nyan_Big and Nyan_Blaze.
Change-Id: Ia82ab86b2af903690cc6c9d310f7bdda3425ea7c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4d23774e071ec22781991ff20fbf63802f620c88
Original-Change-Id: Ia126cff8590117788d1872e50608c257d2659c1f
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224504
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9326
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch aligns ipq806x to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Storm.
Change-Id: Icb81a77e6f458625f5379a980e8760388dd3a1f9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1bf23774c9ffa5d08c211f3658d39adcfa47b339
Original-Change-Id: I283cc7e6094be977d67ed4146f376cebcea6774a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224502
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9368
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Patrick Georgi <pgeorgi@google.com>
While upstreaming, some old (or downstream) names sneaked in.
Change-Id: I148fd8f46bc88c38ce1f62efe5771555bd5dcc5c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9350
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is the start of a series to change all non-x86 SoC-specific
headers to be included as <soc/header.h> instead of the old
<soc/vendor/chip/header.h> or "header.h". It will add an include/soc/
directory under every src/soc/vendor/chip/ and append the .../include/
part of that to the global include path.
This matches the usage of <arch/header.h> for architecture-specific
headers and had already been done for some headers on Tegra. It has the
advantage that a source file which does not know the specific SoC used
(e.g. Tegra files common for multiple chips, or a global include file)
can still include SoC-specific headers and access macros/types defined
there. It also makes the includes for mainboard files more readable, and
reduces the chance to pull in a wrong header when copying mainboard
sources to use a different-related SoC (e.g. using a Tegra124 mainboard
as template for a Tegra132 one).
For easier maintainability, every SoC family is modified individually.
This patch starts out by changing Rk3288. Also alphabetized headers in
affected files since we touch them anyway.
BUG=None
TEST=Whole series: compared binary images for Daisy, Nyan_Blaze,
Rush_Ryu, Storm, Urara and Veyron_Pinky. Confirmed that they are
byte-for-byte identical except for timestamps, hashes, and __LINE__
macro replacements. Compile-tested individual patches.
Change-Id: I4d74a0c56be278e591a9cf43f93e9900e41f4319
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ad8b6d2e0280428aa9742f0f7b723c00857334a
Original-Change-Id: I415b8dbe735e572d4ae2cb1df62d66bcce386fff
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222025
Reviewed-on: http://review.coreboot.org/9349
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
check the cpu and gpu temperature in romstage,
if over 120 degrees celsius,shut down the device.
BUG=None
Test=Boot on veyron_pinky rev2, write value
3421(125 celsius) to grf_tsadc_testbitl register,
the device will be shut down
Change-Id: I275d643ce8560444a9b42ee566d5fd63ebcda35e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e0c597489dc0637ffa66ee9db0c4f60757f8889f
Original-Change-Id: If406d6a4f6201150f52ea7fc64cd50b45778d7aa
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/223259
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9348
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As per NV SysEng, setting PINMUX_CLAMP_INPUTS=1 is now
considered a bad thing. It clamps _all_ tristated inputs
to zero, and isn't really the panacea for duplicated pinmux
mappings as was stated previously.
BUG=None
BRANCH=None
TEST=Built both Rush and Ryu OK. Tested on Rush, booted kernel
OK.
Change-Id: I7d6982a18a772efda7f1d3bf0dcb0d4d0a5bed8f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c5f77fa31961d39dd7b4bd2902288ead9ad80100
Original-Change-Id: I566c4516b34686b744a47a2b0c18c4b801456727
Original-Signed-off-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/224032
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9346
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Paging code is tricky and figuring out what is wrong with it can be a
pain. This patch tries to ease the burden by giving a little more
information for prefetch and data aborts, dumping the Instruction Fault
Address Register (IFAR), Instruction Fault Status Register (IFSR) and
Auxiliary Instruction Fault Status Register (AIFSR) or the respective
Data registers. These contain additional information about the cause of
the abort (internal/external, write or read, fault subtype, etc.) and
the faulting address.
BUG=None
TEST=I have read through enough imprecise asynchronous external abort
reports with this patch that I learned the bit pattern by heart.
Change-Id: If1850c4a6df29b1195714ed0bdf025e51220e8ab
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bf3b4924121825a5ceef7e5c14b7b307d01f8e9c
Original-Change-Id: I56a0557d4257f40b5b30c559c84eaf9b9f729099
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223784
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Remember the XN bit? The one we had so much fun with on Nyan (LPAE)
because not setting it allows random instruction prefetches to device
memory that hang the system every few thousand boots? Thankfully, we had
always been setting it in the non-LPAE MMU code already...
"When the XN bit is 1, a Permission fault is generated if the processor
attempts to execute an instruction fetched from the corresponding memory
region. However, when using the Short-descriptor translation table
format, the fault is generated only if the access is to memory in the
Client domain, see Domains[...]" - ARM A.R.M. section B3.7.2
Oops. This patch changes our Domain Access Control Register (DACR) to
set domain 0 (the only one we are using) to Client. This means that
access permissions (AP[2:0] bits) become enforced, but they are already
set to full access (0b011). It also means that non-LPAE systems will not
be allowed to execute from DCACHE_OFF memory with enabled MMU anymore.
As far as I can see, Veyron_Pinky has been the only board that does
that.
BUG=chrome-os-partner:32118
TEST=Booted Veyron_Pinky with MMU in the bootblock, saw hangs that look
like spurious prefetches and confirmed that this patch fixes them.
Change-Id: I81c00743f938924a5dc8825389fe512a069b77db
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cbc96db296a41ae700371a8515a1179c142f58e7
Original-Change-Id: I30676a5bfe12d516e5f910f51ee6854f6e5be557
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223783
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9343
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch aligns tegra132 to the new SoC header include scheme.
Also alphabetized headers in affected files since we touch them anyway.
BUG=None
TEST=Tested with whole series. Compiled Rush_Ryu.
Change-Id: I5cdf4008a65db84f15c937ef53aab5e4d3ef24c4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d5c5c63d7b6399d3eb8a211b15d47829fe93a591
Original-Change-Id: Ifafd4d42d4fb04a1c37e8a5f23877c2b550cf44c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224505
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9369
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Solving the DACR bug will mean that XN bits suddenly become enforced on
non-LPAE systems, and we will no longer be able to execute out of a
region mapped DCACHE_OFF. When we enable the MMU in romstage we are
still executing out of SRAM, so we would instantly kill ourselves.
Solve this issue by enabling the MMU earlier (in the bootblock) and
mapping the SRAM regions as DCACHE_WRITETHROUGH. They should really be
DCACHE_WRITEBACK, but it looks like there might be hardware limitations
in the Cortex-A12 cache architecture that prevent us from doing so.
Write-through mappings are equivalent to normal non-cacheable on the A12
anyway, and by using this attribute we don't need to introduce a new
DCACHE_OFF_BUT_WITHOUT_XN_BIT type in our API. (Also, using normal
non-cacheable might still have a slight speed advantage over strongly
ordered since it should fetch whole cache lines at once if the processor
finds enough accesses it can combine.)
CQ-DEPEND=CL:223783
BUG=chrome-os-partner:32118
TEST=None (depends on follow-up CL)
Change-Id: I1e5127421f82177ca11af892b1539538b379625e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e7b079f4b6a69449f3c7cc18ef0e1704f2006847
Original-Change-Id: I53e827d95acc2db909f1251de78d65e295eceaa7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223782
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9342
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds an mmu_config_range_kb() function, which can set memory
types at the 4KB level by chaining a fine-grained page table to an
existing superpage entry. It is only intended for special cases where
this level of precision is really necessary and therefore comes with a
few practical limitations (the area for each invocation must be confined
within a single superpage, and you are not allowed to remap the same
region with mmu_config_range() again later). Since the fine-grained page
tables need some space, boards intending to use this feature must define
a TTB_SUBTABLES() region in their memlayout.ld.
BUG=chrome-os-partner:32848
TEST=Booted both Veyron_Pinky (normal) and Nyan_Blaze (LPAE), ensured
that they still work. Checksummed the page tables with and without this
patch, confirmed that they end up equal. Hacked in some subtable test
entries, hexdumped all tables and manually confirmed that they look as
expected.
Change-Id: I8c3eb7c2eb9c82e2abc5f2c0dda91f5b2eee7023
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2f13e60cf5509b9a63fb7b8d84846daf889dc1b7
Original-Change-Id: Iedf7ca435ae337ead85115200d6987fb0d4828d7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223781
Reviewed-on: http://review.coreboot.org/9341
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Vadim Bendebury