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: Ifcc755326832755cfbccd6f0a12104cba28a20af
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229975
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: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229974
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I9df24f302edc872bed991ea450c0af33a1c0ff7b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232239
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
With this descriptor added ramstage properly allocates memory
resources and creates entries in coreboot table. This also allows to
proceed to booting depthcharge, as it now can be loaded into the
existing memory.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=with the set of patches applied the firmware properly finds
depthcharge in CBFS, uncompresses it and attempts to start:
...
Booting payload fallback/payload from cbfs
Loading segment from rom address 0x9b000058
code (compression=1)
New segment dstaddr 0x80124020 memsize 0x2099a0 srcaddr 0x9b000090 filesize 0xbbe
Loading segment from rom address 0x9b000074
Entry Point 0x80124038
Loading Segment: addr: 0x0000000080124020 memsz: 0x00000000002099a0 filesz: 0x0000000000000bbe
lb: [0x0000000080000000, 0x0000000080013858)
Post relocation: addr: 0x0000000080124020 memsz: 0x00000000002099a0 filesz: 0x0000000000000bbe
using LZMA
[ 0x80124020, 8012596c, 0x8032d9c0) <- 9b000090
Clearing Segment: addr: 0x000000008012596c memsz: 0x0000000000208054
dest 80124020, end 8032d9c0, bouncebuffer 8ffd4f50
Loaded segments
BS: BS_PAYLOAD_LOAD times (us): entry 129 run 34579421 exit 129
Jumping to boot code at 80124038
ERROR: dropped a timestamp entry
CPU0: stack: 9a00c800 - 9a00d800, lowest used address 9a00d498, stack used: 872 bytes
entry = 80124038
Change-Id: Ifed5550f2c18430e9ae06ad1ecacaa13191b5995
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232571
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the code now running on the FPGA board it makes sense to correct
the memory layout definitions to match the actual hardware.
Note that the latest FPGA board firmware introduced support of the
additional 128KB of SRAM (called GRAM) at base address of 0x9a000000.
These are still interim values, which will be tweaked when the actual
bring up board is available.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=the code put into SPI NOR flash boots all the way to ramstage.
Change-Id: I50183c2d5f9017801d5c8a7a7addf08efa492b35
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229203
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Using REG_PCI_POLL32 to check if the LINK is active with 50ms timeout.
BRANCH=none
BUG=chromium:431169
TEST=Test on Enguarde, compile ok and boot OS
Change-Id: I490e6ffa40979628edf52a7444808b6d25a6e83d
Signed-off-by: Kevin Hsieh <kevin.hsieh@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/231777
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.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: Ia56c0599a15f966d087ca39181bfe23abd262e72
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231942
Reviewed-by: Aaron Durbin <adurbin@chromium.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: I4257b5a8807595140e8c973ca04e68ea8630bf9a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231941
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.
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: I57013b99c3af455cc3d7e78f344888d27ffb8d79
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231940
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I36bb16c8d931f862bf12a5b862b10cf18d738ddd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231222
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Since CL:226662, all TPMP accessing should be removed as well,
else it will cause fox_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: Ia0eebb1924bbb23979c880f7d05600a0cf1e4ca3
Signed-off-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232165
Reviewed-by: Wei Shun Chang <wei.shun.chang@intel.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
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: Ib195ed6e5f08ccaa6bbe3325c2199171bfb63b88
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232191
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
32K is a more appropriate room for Pistachio bootblock.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=there is no bootblock overflow even when compiled with -O0.
Change-Id: I74b6674aea95b1138e2168527239e2cfb4a7ad42
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232291
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The CPU on/off functions are the method for the Kernel to support CPU
hot-plug function in PSCI. To support this, we still need flow controller
support to capture the WFI from the CPU and inform PMC to power gate the
CPU core. On the other path, we turn on the CPU by toggling the PMC and
use flow controller to let go when the power is steady.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=built the kernel with PSCI enabled,
check both of the CPUs are coming up,
test the CPU hot-plug is working on Ryu
Change-Id: Ie49940adb2966dcc9967d2fcc9b1e0dcd6d98743
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/231267
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
fmap_find used to read 4096 bytes from the fmap offset blindly. instead, we read
the fmap header first to calcurate the size of the fmap. Then, we read flash
again exactly as much as the discovered fmap.
BUG=none
BRANCH=ToT
TEST=Booted Storm and Peppy. Built all current boards.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Ie5058d181e6565acb70bf108464682dd0e6c1f64
Reviewed-on: https://chromium-review.googlesource.com/231685
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Low level 64 bit division and modulo functions are not available for
MIPS platforms, but are required by the printk formatter.
Modify the code to avoid 64 bit math when building for MIPS. In case
the user does print a value exceeding 2^32, send a few junk characters
to the output to indicate a corrupted value printed.
BRANCH=none
BUG=none
TEST=startup code on Urara properly prints CBFS address values which
are passed as 64 bit integers.
Change-Id: I25b8a900b3ba4ec1da3446dcc5f03101d5cdb757
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232294
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit 9c0978d944.
The underlying assumption was that the only format specification which
required 64 bit division was '%L', and it was used on x86 only. It
turns out, that '%ll' also uses 64 bit division, and this format
specification is more popular in the code, which in turn results in
incorrect values printed when the caller passes in 64 bit numbers.
An alternative solution will be presented in the next patch.
BRANCH=none
BUG=none
TEST=none
Change-Id: Ie671d49a5026eb3b0c3c250f365d725e3b19bb25
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232293
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Adding this configuration option enables romstage console output.
Ideally this setting should be enabled automatically in case the
bootblock console is enabled.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=romstage messages show up on the console
Change-Id: I710e05ce24e1aeccc90aead50336f00dec52fff0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229202
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
With support for initializing registers based on values saved by primary CPU, we
no longer need to invalidate secondary CPU stack cache lines. Before jumping to
C environment, we enable caching and update the required registers.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I738250f948e912725264cba3e389602af7510e3e
Reviewed-on: https://chromium-review.googlesource.com/231563
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
startup.c provides function to enable CPU in any stage to save register data
that can be used by secondary CPU (for normal boot) or any CPU (for resume
boot). stage_entry.S defines space for saving arm64_startup_data. This can be
filled by:
1) Primary CPU before bringing up secondary CPUs so that the secondary can use
register values to initialize MMU-related and other required registers to
appropriate values.
2) CPU suspend path to ensure that on resume the values which were saved are
restored appropriately.
stage_entry.S provides a common path for both normal and resume boot to
initialize saved registers. For resume path, it is important to set the
secondary entry point for startup since x26 needs to be 1 for enabling MMU and
cache.
This also ensures that we do not fall into false memory cache errors which
caused CPU to fail during normal / resume boot. Thus, we can get rid of the
stack cache invalidate for secondary CPUs.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu without mmu_enable and stack
cache invalidate for CPU1.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I527a95779cf3fed37392b6605b096f54f8286d64
Reviewed-on: https://chromium-review.googlesource.com/231561
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Some registers are available only at EL3. Add conditional read/write functions
that perform operations only if currently we are in EL3.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ia170d94adb9ecc141ff86e4a3041ddbf9045bc89
Reviewed-on: https://chromium-review.googlesource.com/231549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
TCR at EL1 is 64-bit whereas at EL2 and EL3 it is 32-bit. Thus, use 64-bit
variables to read / write TCR at current EL. raw_read_tcr_elx will handle it
automatically by accepting / returning 32-bit / 64-bit values.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I459914808b69318157113504a3ee7cf6c5f4d8d1
Reviewed-on: https://chromium-review.googlesource.com/231548
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Update non-vboot2 memlayout:
1) Add timestamp region
2) Increase ramstage size
3) Change name from memlayout_vboot.ld to memlayout.ld so that any non-vboot
upstream board can also use this layout.
BUG=None
BRANCH=None
TEST=Compiles and boots to kernel prompt on ryu with vboot selected instead of
vboot2.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I91accd54efc53ab563a2063b9c6e9390f5dd527f
Reviewed-on: https://chromium-review.googlesource.com/231547
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Instead of having unified CBFS_CACHE and limiting the POSTRAM Cache size, split
them into PRERAM and POSTRAM CBFS_CACHE.
BUG=None
BRANCH=None
TEST=Compiles successfully for both rush and ryu. Boots to kernel prompt on ryu.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Iab21ff5c7ca880b6bd18846e5d8d71c26dff56cf
Reviewed-on: https://chromium-review.googlesource.com/231546
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Enable display code only if mainboard selects
MAINBOARD_DO_NATIVE_VGA_INIT. Otherwise build breaks for boards that do not
support display init yet.
BUG=chrome-os-partner:31936
BRANCH=None
TEST=Compiles for both rush and ryu. Display comes up for ryu in both normal and
dev mode.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ib4a3c32f1ebf5c6ed71c96a24893dcdee7488b16
Reviewed-on: https://chromium-review.googlesource.com/231545
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
A couple of regs need to be poked to allow audio output
from this part on Ryu P0/P1. It will be replaced by two
non-configurable amps on P3.
BUG=none
BRANCH=none
TEST=Build/flashed on Ryu P1, dumped AD4567 (I2C6 dev 0x34)
regs and confirmed settings.
Change-Id: I8999843646927dbd07a179ede973ba5f1eb97167
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/231384
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
edp must reset when device power up, otherwise the edp
register maybe uncertain, now the edp source clock default
select 27M, and in pinky and jerry board we use 24M as edp
sourec clock, if we want to reset edp, we must after the clock
source select 24M.
BUG=chrome-os-partner:34023
TEST=Booted Veyron jerry and read edid normal
BRANCH=None
Change-Id: Ica031d2d52deb539c1a0a56968786d6952b3d0e8
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/231336
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
This patch adds Cypress gen5 trackpad device supported in auron
platform.
The new Cypress gen5 trackpad's I2C address is 0x24 which is different
from the old trackpad device's I2C address 0x67.
BRANCH=None
BUG=None
TEST=None
Signed-off-by: Dudley Du <dudley.dulixin@gmail.com>
Change-Id: I4a80d6a5b63b4ec3a0d38258886b1979a12377ea
Reviewed-on: https://chromium-review.googlesource.com/230254
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Dudley Du <dudl@cypress.com>
Tested-by: Dudley Du <dudl@cypress.com>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
In order to start CPUs while in secmon/psci one needs to
set up the proper SoC state. Therefore, refactor the current
CPU startup API to allow for this by adding cpu_prepare_startup()
and start_cpu_silent().
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted kernel.
Change-Id: I842a391d3e27ddbfcdef1a2d60e3c66e60f99c77
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231936
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
psci_soc_init() was added to allow SoC PSCI initialization.
However, actually calling said function was omitted accidentally.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and noted correct on entry point was used.
Change-Id: I1a4e25fde64ecdc98fa9231f7d9cafc21119630d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231935
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Port over a few recent changes that were uploaded before the Mighty
board landed.
BRANCH=None
BUG=None
TEST=Booted on a Pinky rev2, went as far as you'd expect.
Change-Id: I546dbc41ccd191159e96b851424fcb37902a57ec
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231691
This is being triggered because the base address is added, but
there is nothing that needs done with it in set_resources step
and the ERROR message is tripping suspend resume test scripts.
BUG=chrome-os-partner:33385
BRANCH=samus,auron
TEST=boot on samus and check for ERROR strings,
successfully run suspend_stress_test without failures
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231603
(cherry picked from commit bb789492965d92e309a913dc7b9f09f7036c5480)
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I2b5f44795f1ee445d509b29bd56f498aea7b7fe3
Reviewed-on: https://chromium-review.googlesource.com/231604
Commit-Queue: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Limit power to 12W at 90C and remove limit at 85C.
BUG=chrome-os-partner:33995
BRANCH=none
TEST=manual:
To have the CPU consume maximum power it is necessary to stress
both the CPU and the GPU. Bastion (chrome.supergiantgames.com)
and/or webglsamples.googlecode.com can be useful for this.
Testing this properly requires a script to report the running
average power readings. The watch_power.sh script is attached
to this issue in the partner tracker.
1) Run watch_power.sh continuously:
localhost ~ # watch -n 0 bash -e /tmp/watch_power_v2.sh
2) Start WebGL Aquarium (or other stress apps). The power draw should
be close to 15W if under enough load.
3) Watch until temperature climbs above 90C and is caught by
the thermal zone 10 second poll, this can be sped up by blocking
or removing the fan.
4) The ACPI thermal zone states should change to reflect that
active[2] is now enabled and power consumption should drop to 12W.
5) Stop the stress apps and wait until the CPU cools off again,
enable the fan again if it was removed.
6) The ACPI thermal zone state should switch back to active[3].
Signed-off-by: Wei Shun Chang <wei.shun.chang@intel.com>
Change-Id: If6be36f7b8eed9347ed60b90e5a265f4f8d31548
Reviewed-on: https://chromium-review.googlesource.com/231382
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Based on TPS65913, the max LDO turn on time is 500us. Since it is requested
the default delay of 500us when calling function pmic_write_reg(), it is
safe to remove this 100ms delay.
BRANCH=none
BUG=chrome-os-partner:31936
TEST=build and test on ryu
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I53aecc273484edfa502231b44f6bcd7f5d8f9331
Reviewed-on: https://chromium-review.googlesource.com/231170
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.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
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I6968fcb6cda74e88f56bea6ea9bbf77cc795b8d6
Reviewed-on: https://chromium-review.googlesource.com/230887
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The romstage_main routine takes three parameters: bist, tsc_low and
tsc_hi. However in cache_as_ram.inc only the bist value is being
passed. This patch adds the two halves of the TSC value.
BRANCH=none
BUG=None
TEST=Build and run on Samus
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Change-Id: I34fb21e493dcb3a44426ba7964cd72a319a4254e
Reviewed-on: https://chromium-review.googlesource.com/231173
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The bootblock on Rush had bumped up into the verstage
allocation, causing the build to break. Reduced verstage from
60K to 58K and increased bootblock from 20K to 22K. Rush and
Ryu both build fine now.
BUG=none
BRANCH=none
TEST=Built both Rush and Ryu OK. Verifed verstage size
using cbfstool and it's around 55K, so plenty of room.
Change-Id: I7018f027d72d5e8aeb894857a5ac6a0bdc1de388
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/230824
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Secondary CPUs were intermittently not coming online as expected.
Upon investigation it was found that a cache line needed to be
invalidated that corresponded to the top of the stack for the
failing CPU.
Currently the secondary CPUs come online with caching disabled.
However, the code paths are using C and thus the stack it is assigned.
The MMU is enabled in C after it's pushed its return path onto the
stack that went directly to ram. When the cache line corresponding
to its stack is valid in the cache it will hit once the MMU is enabled.
That hit will have invalid data w.r.t. the return addresses pushed
directly into ram.
This is not the best solution as the only way to guarantee we don't
hit such a situation is to tightly manage resource usage up until
the point of MMU enablement. That can be done in a followup patch.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=On ryu where secondary CPUs weren't coming online consistently,
they now come up.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I32de749ea48c19e23442e6dc5678c5369ac3b2b6
Reviewed-on: https://chromium-review.googlesource.com/231219
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Implement VOP and eDP drivers, vop and edp clock configuration,
framebuffer allocation and display configuration logic.
The eDP driver reads panel EDID to determine panel dimensions
and the pixel clock used by the VOP.
The pixel clock is generating using the NPLL.
BUG=chrome-os-partner:31897
TEST=Booted Veyron Pinky and display normal
BRANCH=None
Change-Id: I61214f55e96bc1dcda9b0f700e5db11e49e5e533
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/219050
Reviewed-by: Julius Werner <jwerner@chromium.org>
Extend lib/reg_script.c to use a platform table to declare
additional platform specific register access routine functions.
REG_SCRIPT_TYPE_PLATFORM_BASE is the starting value for platform
specific register types. Additional register access types may be
defined above this value. The type and access routines are placed
into reg_script_type_table.
The Baytrail type value for IOSF was left the enumeration since it
was already defined and is being used for Braswell.
BRANCH=none
BUG=None
TEST=Use the following steps to test:
1. Build for a Baytrail platform
2. Build for the Samus platform
3. Add a platform_bus_table routine to a platform which returns the
address of an array of reg_script_bus_entry structures and the
number of entries in the array.
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/215645
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I7cd37abc5a08cadb3166d4048f65b919b86ab5db
Reviewed-on: https://chromium-review.googlesource.com/229612
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Merge change from coreboot.org: Add new finalize functions for devices
and chips
BUG=None
TEST=Requires FSP for testing
commit 2a58ecde78
Author: Marc Jones <marc.jones@se-eng.com>
Date: Tue Oct 29 17:32:00 2013 -0600
Add new finalize functions for devices and chips
Many chipset devices require additional configuration after
device init. It is not uncommmon for a device early in the
devicetree list to need to change a setting after a device later
in the tree does PCI init. A final function call has been added
to device ops to handle this case. It is called prior to coreboot
table setup.
Another problem that is often seen is that the chipset or
mainboard need to do some final cleanup just before loading the
OS. The chip finalize has been added for this case. It is call
after all coreboot tables are setup and the payload is ready to
be called.
Similar functionality could be implemented with the hardwaremain
states, but those don't fit well in the device tree function
pointer structure and should be used sparingly.
Change-Id: Ib37cce104ae41ec225a8502942d85e54d99ea75f
Reviewed-on: http://review.coreboot.org/4012
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I4f918a5908f2016f6e57f954284f9f8856bd8301
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/213694
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229572
Reviewed-by: Erik C Bjorge <erik.c.bjorge@intel.com>
The initial MP code assumed all CPUs would come online. That's not
very defensive, and it is a bad assumption. Provide a timeout
mechanism for bring CPUs online.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Multiple times with CPUs working and not working. Boot to kernel.
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ifb3b72e3f122b79e9def554c037c9b3d6049a151
Reviewed-on: https://chromium-review.googlesource.com/231070
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add the common header files for FSP 1.1. The are provided in an
EDK2 style tree to allow direct comparison with the EDK2 tree.
BRANCH=none
BUG=None
TEST=Build with FSP
Change-Id: I6f7316c8a31ec75d3593c950fe227a776a3e18a5
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/229618
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add the common header files for EDK2. These files come from the
open source EDK2 tree https://svn.code.sf.net/p/edk2/code/trunk/edk2
revision 16227. The are provided in an EDK2 style tree to allow
direct comparison with the EDK2 tree.
The following files were modified to remove trailing spaces and add
some #ifndef/#endif conditionals:
* MdePkg/Include/Base.h
* MdePkg/Include/Ia32/ProcessorBind.h
* MdePkg/Include/Uefi/UefiBaseType.h
* MdePkg/Include/X64/ProcessorBind.h
A patch for the files above has been submitted to
edk2-devel@lists.sourceforge.net for inclusion into a future revision
of EDK2's MdePkg.
Note: All the files below were modified to use Linux line termination.
BRANCH=none
BUG=None
TEST=Build with FSP
Change-Id: Icaeb0cde301c7d555e5d55a95932efc1bc315d40
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/229617
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
