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>
make oldconfig doesn't like 'y' as response to a choice item
such as the architecture list. An empty response, however, is
acceptable, so use that.
Change-Id: Ic3164dd3f40e4a7f5d91e3a7008893655cd69ac2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9676
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Extended the 32bit CPU counter to 64bit by adding a static
variable that takes into account CPU counter overflow.
The varibale is updated everythime the timer_raw_value
function is called so I assume that the function is called
often enought to not miss an overflow of the CPU counter.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; works as expected
BRANCH=none
Change-Id: I98bcc56e600dcff0c6da7c140dd34faec5e00885
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 972b105f950d800fa44f27bce090f6b89a5a84b9
Original-Change-Id: Id67b14e9d9c2354bc417b6587b615d466690c9b7
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/247642
Original-Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: http://review.coreboot.org/9672
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>
The address of the output buffer sent to the device should be
the bus address and not the virtual address.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA and bring up board;
USB works properly after this change
BRANCH=none
Change-Id: I5c9d199e17c3f4303095ad73f4980d32d04c6118
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 942c385c112c2a4e409da806548081d3e2f8f438
Original-Change-Id: I0c06196501a968a72cb3f2c7dd1027bb22cdaada
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245387
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9455
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Total FIFO length is split into 512 byte blocks.
Allocate these blocks to GRXFSIZ and GNPTXFSZ evenly.
This method avoids hardcoding and makes the FIFO size value
work for dwc2 controllers that have a different FIFO ram size.
BUG=chrome-os-partner:32634
BRANCH=None
TEST=Boot kernel from USB
Change-Id: I78ce0fa4c4600fb56c991874a93bdd6674e648c2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5645a25e95f84359cd10fc9fcf56e1f73fd6ce87
Original-Change-Id: Ib50a08c193f7f65392810ca3528a97554f2c3999
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233119
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9454
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: I33f312a939e600b8f4e50a092bb61c5d6bc6d741
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 39ffe53336a2a3b2baa067cdd3dccca5ae93f68e
Original-Change-Id: Idad1ad165fd44df635a0cb13bfec6fada1378bc8
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/211053
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9453
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>
Move the 3rdparty marker to blobs.git commit 892a697
Change-Id: I8a51f301e08e49970b4747f004e0752617de8005
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9625
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
huang lin