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>
David Hendricks