The graphics device needs to have its resource contraints
initialized before running the reference code. Right now just
use a 256MiB aperture, 32MiB of stolen memory data, and 2MiB
GTT memory.
BUG=chrome-os-partner:22869
BRANCH=None
TEST=Built and booted. Noted amount of stolen memory matches
configuration as well as BAR size within the graphics
device.
Change-Id: I328bf858f288363187cf705d6340947393b5ff10
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170427
Take advantage of the cache early in bootblock. The
intent is to speed up cbfs walking when trying to locate
romstage.
BUG=chrome-os-partner:22857
BRANCH=None
TEST=Built and booted.
Change-Id: If03210103c9782390230915db3b4a9759d172dce
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170426
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
B2 and B3 steppings are now bumped to version 313.
BUG=chrome-os-partner:22858
BRANCH=None
TEST=Built.
Change-Id: I09ae5110b66c725e959e95fc15bc85ccf371495d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170425
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The UART / serial console is put in retention state by kernel during suspend /
resume path, which caused Coreboot not able to print any messages during resume.
Sending values to the padret_uart_opt inside PMU may release UART, but that may
also cause unexpected output when kernel is back. However, it's still very
helpful when we are debugging suspend/resume inside Coreboot.
To get UART message on resume, call wakeup_enable_uart() in boot block or
romstage (before console_init).
BUG=none
TEST=emerge-peach_pit chromeos-coreboot-peach_pit
Change-Id: Ib5759cb402c6e018d9dba14fad8b61f6a1b1a265
Reviewed-on: https://chromium-review.googlesource.com/170440
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
These dependencies came indirectly through kconfig.h which was included
automatically with a -include option which was either part of INCLUDES or
specified directly.
A similar change was checked in for ARM upstream.
BUG=None
TEST=Built for falco.
BRANCH=None
Change-Id: I640b8115f6526c546fe5d251ef2c04e0e78e6ac9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170122
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
These dependencies came indirectly through kconfig.h which was included
automatically with a -include option which was either part of INCLUDES or
specified directly. With this change, I'm able to build for beaglebone with
make -j 48.
BUG=None
TEST=Built for kirby.
BRANCH=None
Change-Id: Ib2a69c47baaeddec9f73a059a94afc258c2ca79a
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170121
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
This will be needed for Link Time Optimizations
BUG=none
BRANCH=none
TEST=boot tested on Link
Change-Id: I92c3fac2ac0d4ea9e3afa73fefa93a856054a24b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/56121
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This patch enhances the armv7 exception handlers in Coreboot and
libpayload to show the correct SP and LR registers from the aborted
context, and also dump a part of the current stack. Since we cannot
access the banked registers of SVC mode from a different exception mode,
it changes Coreboot (and its payloads) to run in System mode instead. As
both modes can execute all privileged instructions, this should not have
any noticeable effect on firmware operation (please correct me if I'm
wrong!).
BUG=None
TEST=Cause a data_abort in Coreboot or depthcharge. Marvel at the
beautifully displayed stack dump that helps you debug the abort.
Change-Id: I0e04f47619e55308f7da4a3a99c9cae6ae35cc30
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170045
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The Bayley Bay reference board is a Bay Trail mobile and/or
desktop reference board.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted to romstage.
Change-Id: Ia0a4f94244ce7ac3a960de796170c091e384f976
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168388
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The initial Bay Trail code is intended to support
the mobile and desktop version of Bay Trail. This support
can train memory and execute through ramstage. However,
the resource allocation is not curently handled correctly.
The MRC cache parameters are successfully saved and reused
after the initial cold boot.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=Built and booted on a reference board through ramstage.
Change-Id: I238ede326802aad272c6cca39d7ad4f161d813f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168387
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Trustzone needs to be initialized/disabled both on boot and on wake, so it
needs to be done before ramstage which doesn't run on wake. cpu.c isn't
compiled into romstage and fixing that causes other problems, so the trustzone
functions were split out.
BUG=chrome-os-partner:22759
TEST=Built and booted on for snow, pit and kirby. Successfully slept and woke
on each.
BRANCH=None
Change-Id: I8fc630237ebec1f02a91600f8baf3d4e9ea66d0e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169817
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
The CPU_ADDR_BITS was being unconditionally set.
Don't do that.
BUG=None
BRANCH=None
TEST=Built bayleybay and can now set CPU_ADDR_BITS properly.
Change-Id: Idbc63328fade8f5f05f7f46282139b86e6694989
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169711
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The W25Q64DW spi part is programatically equivalent
to the other W25Q64 parts except it operates at 1.8V.
Just add a new entry with the appropriate ID.
BUG=chrome-os-partner:22292
BRANCH=None
TEST=SPI controller can program the part.
Change-Id: I65b0261223a9fefcb07477a43b6a3edb8228dd03
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170011
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On ARM the SPI flash is not memory mapped. Use the CBFS
interface to map the correct portion.
BRANCH=none
TEST=boot tested on pit
BUG=none
Change-Id: I8ea9aa0119e90a892bf777313fdc389c4739154e
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169781
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Only have the SPI driver produce output when CONFIG_DEBUG_SPI is
enabled.
BRANCH=none
TEST=booted on Pit, saw SPI messages from spi_claim_bus() go away
BUG=none
Change-Id: Ib911182b9b6a85e1a7b308f03c9b1bdba2fa0bf4
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170026
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: David Hendrix <dhendrix@chromium.org>
BUG=none
BRANCH=none
TEST=boot tested on pit, but more changes needed
Change-Id: I778ea787b20a7d7d7b202b1b5e7f956d2fde6629
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169621
On x86 VbExGetTimer() uses rdtsc. However, on all
other platforms, let's just use coreboot's monotonic timers.
BUG=none
BRANCH=none
TEST=more changes needed, but boot tested on pit
Change-Id: I0cd359f298be33776740305b111624147e2c850d
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169620
That extra struct is not needed, we already defined it earlier on.
Also fix coding style in the file.
BRANCH=none
TEST=boot tested on pit
BUG=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I586d290f2f3ba2f44aca7fdee400b88547465599
Reviewed-on: https://chromium-review.googlesource.com/169780
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
This patch adds support for the DesignWare3 USB 3.0 DRD controller and
PHY to the Exynos5250 and Exynos5420 CPUs. It also adds code to the
Google Snow, Pit and Kirby boards to turn these controllers on where
applicable.
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Idcca627363a69f1d65402e1acb9a62b439f077ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169452
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Currently the workaround for indicating a "full" battery kicks
in at 3%, but this turns out to be too high for some devices.
So move the workaround start point to 6% from full, or 94%.
BUG=chrome-os-partner:21959
BRANCH=falco,peppy,wolf,leon
TEST=emerge-falco chromeos-coreboot-falco
Change-Id: Ib4305df3a68e89f3a10a096d0e89d8105ea9037b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some USB3 devices are not showing up after suspend/resume cycles.
In particular if a device uses a lower power state like U2 it may
take longer to come up and the firmware needs to wait after sending
a warm port reset.
In addition skipping port reset to connected ports in the way into
suspend was causing problems so instead send all ports a reset
before suspend.
BUG=chrome-os-partner:22402
BRANCH=falco,peppy,leon,wolf
TEST=manual:
Suspend/resume with ADATA HE720 HDD (and other devices) both
connected at suspend and connecting while in suspend and ensure
that the devices always show up in the kernel.
Change-Id: Ib7b15dc65792742b4ceb7dcfc4b2c83192eafcc2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169548
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This is needed to make LTO happy with assembler functions.
BRANCH=none
TEST=boot tested on pit
BUG=none
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4dbfe193d470c795cfef2272f45a78fe156c4912
Reviewed-on: https://chromium-review.googlesource.com/168963
These symbols are not used anywhere in our C code, so
when using GCC's link time optimization feature they
will be dropped even though they're needed by libgcc.
Hence we need to mark them as used so GCC does not stumble
and fall over its own guts.
BUG=none
BRANCH=none
TEST=boot tested on pit.
Change-Id: Ib2e9ea2610b57ab8244d5b699dd56025a4f08a01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168773
When using GCC for linking, we should pass CFLAGS to the compiler
BRANCH=none
BUG=none
TEST=boot tested on pit
Change-Id: Ic46a9a38dddd763368635de77f576f7ae5b1b774
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168962
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
This commented out code is a left over from x86.
BUG=none
BRANCH=none
TEST=none
Change-Id: Ice806000c73d5a068962914d067d4de7b3d75f45
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168961
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendrix <dhendrix@chromium.org>
timer initialization is the first thing happening in
the Exynos CPU's bootblock code. Hence we don't need
to keep track of it in several places, and we don't
need to do it over and over again (e.g. in each stage)
BUG=none
BRANCH=none
TEST=boot tested on pit
Change-Id: I7bd9a0b7930fc9c37faabd62e3eecc3e5614a879
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168994
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Right now some console specific objects are included
in the bootblock even if CONFIG_BOOTBLOCK_CONSOLE is
disabled while others are not. Make all of them conditional
and also fix a preprocessor misuse in bootblock_simple.c
and a stray (useless) die() in the Exynos wakeup code that
made inclusion of those files necessary.
BRANCH=none
BUG=none
TEST=boot tested on pit
Change-Id: Ia7f9d17654466f199b0e13afbdc9e14c9706530f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168772
Reviewed-by: David Hendrix <dhendrix@chromium.org>
A recent change to support early firmware selection on ARM broke snow and was
incompletely implemented on pit and kirby. This change fixes snow by applying
the remaining part of the change that had been applied to the other two
boards, and also hooks up real values in the get_write_protect_state function.
BUG=None
TEST=Built and booted on snow and pit, built for kirby.
BRANCH=None
Change-Id: Ifef7ad1bf399f79353daec3dd46973f2b2022e37
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169120
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
When changing the from ROMCC to CC, three spaces got lost.
This fixes the build output. Purely cosmetical
BRANCH=none
TEST=none
BUG=none
Change-Id: I8850b6e0cc72ec07c2baf3cb574b13914517bb6c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168960
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Commit-Queue: David Hendrix <dhendrix@chromium.org>
This patch cleans out a lot of unused variables in the
ARM Kconfig files and introduces CONFIG_RAMSTAGE_BASE
which is similar to CONFIG_RAMBASE on x86.
This gets rid of the hard coded assumption that on ARM
coreboot is always executed at the lowest DRAM address.
But in fact, this might not be true because we might want
coreboot to live at the end of RAM, or in SRAM
BUG=none
BRANCH=none
TEST=successfully booted on pit.
Change-Id: I03e992645f9eb730e39a521aa21f702959311f74
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168645
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: David Hendrix <dhendrix@chromium.org>
When using dynamic CBMEM the CBMEM area is initialized before
entering ram stage, and so we need a way smaller temporary buffer
for the CBMEM console during early bits of ram stage. In practice
around 256 bytes are needed, but keep the buffer at 1k so we make
sure we don't run out.
TEST=Boot tested on pit
BRANCH=none
BUG=none
Change-Id: I462810b7bafbcc57f8e5f9b1d1f38cfdf85fa630
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168575
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
BRANCH=none
TEST=none
BUG=none
Change-Id: I01a11923fc1b250afeed36acc20793fd072421ba
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168574
Reviewed-by: Gabe Black <gabeblack@chromium.org>
All ARM systems we support have dynamic CBMEM support.
Hence drop non-dynamic CBMEM support from the mainboard
specific code.
BUG=none
BRANCH=none
TEST=boot tested on pit
Change-Id: Icdff8dd8306ca40f86f08dee2a65f03a526b99db
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168573
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The locality is requested when the TPM is initialized and released when
it's cleaned up. There's no reason to set it to the same thing again and
restore it back to the same value before and after every transaction.
BUG=None
TEST=Built and booted on pit.
BRANCH=None
forward ported from https://chromium-review.googlesource.com/#/c/168400
Change-Id: I291d1f86f220ef0eff6809c6cb00459bf95aa5e0
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168584
Reviewed-by: Gabe Black <gabeblack@chromium.org>
I assume from the code in the TPM driver that the TPM spec defines
different types of delays and timeouts which each have a particular
duration, and that the TPM can tell you how long each type is if you ask
it. There was a large table, some members of a data structure, and a
function or two which managed the timeouts and figured their value for
different operations. The timeout values for the various "ordinals"
were never set in the vendor specific data structure, however, and
always defaulted to 2 minutes. Similarly the timeouts a, b, c, and d
were never overridden from their defaults. This change gets rid of all
the timeout management code and makes the "ordinal" timeout 2 minutes
and the a, b, c, and d timeouts 2 seconds, the larger of the two default
values.
This is a port from depthcharge to coreboot, original change:
https://chromium-review.googlesource.com/#/c/168363/
BUG=None
TEST=Built and booted on kirby
BRANCH=None
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I79696d6329184ca07f6a1be4f6ca85e1655a7aaf
Reviewed-on: https://chromium-review.googlesource.com/168583
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
This patch renames the x86 way of doing things to
explicitly mention CMOS (which is not available on
our ARM platforms) and adds an implementation to
get VBNV through the Chrome EC. We might want to
refine this further in the future to allow VBNV
in the EC even on x86 platforms. Will be fixed when
that appears. Also, not all ARM platforms running
ChromeOS might use the Google EC in the future, in
which case this code will need additional work.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=needs further changes
BUG=none
Change-Id: Ice09d0e277dbb131f9ad763e762e8877007db901
Reviewed-on: https://chromium-review.googlesource.com/167540
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
On ARM platforms the TPM is not attached through LPC but through I2C.
This patch adds an I2C TPM driver that supports the following chips:
* Infineon SLB9635
* Infineon SLB9645
In order to select the correct TPM implementation cleanly, CONFIG_TPM
is moved to src/Kconfig and does the correct choice.
BRANCH=none
TEST=compile tested on peach_pit (more work needed to use this)
BUG=none
Change-Id: I2def0e0f86a869d6fcf56fc4ccab0bc935de2bf1
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/167543
Reviewed-by: ron minnich <rminnich@chromium.org>
Pit used GPIO X06, and while that's connected in the schematic on kirby as
well, it's with an unstuffed resistor. The line is actually connected to
GPIO Y00.
BUG=None
TEST=Built and booted on kirby with corresponding kernel device tree changes.
Suspended and resumed using the lid switch on servo and saw that the firmware
resumed instead of rebooting.
BRANCH=None
Change-Id: Iaa7497899cb4514ba94b1e414377799a0ce30e51
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168521
Reviewed-by: ron minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Transfered over from pit.
BUG=None
TEST=None
BRANCH=None
Change-Id: If6ef44951fcf3d2c7253333ef5e4da31614b3032
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168362
Reviewed-by: ron minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
All this samsung_get_base_address_of_device_with_a_really_long_name()
boilerplate makes my eyes bleed... I think there are so much cleaner
ways to do this. Unfortunately changing this ends up touching nearly
every Exynos5 file, but I hope you agree that it's worth it (and the
sooner we get it over with, the better... I can't bring myself to make
another device fit into that ugly scheme).
This also removes the redundant EXYNOS5 base address definitions from
the 5420 directory when there are EXYNOS5420 ones, to avoid complete
confusion. The new scheme tries to use EXYNOS5 for base addresses and
exynos5 for types that are common between the two processors, and
EXYNOS5420/exynos5420 for things that have changes (although I probably
didn't catch all differences).
BUG=None
TEST=Try to write some code that flips a single PMU register bit without
getting super frustrated with all the extra stuff you need to set up.
Change-Id: I87e58434490ed55a9bbe743af1f9bf2520dec13f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167579
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
This board was cloned from Falco, and the EC was replaced
by the ITE IT8772F SuperI/O
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BUG=none
BRANCH=none
TEST=none
Change-Id: Ia41af8425ab6c24746253abd025acd3365dd5a18
Reviewed-on: https://chromium-review.googlesource.com/167131
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Some drivers (like the I2C TPM driver) call mdelay instead of
udelay. While it's a shame that these chips are so slow, the
overhead of having those functions available in romstage is
minimal.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=compile tested
BUG=none
Change-Id: I1fa888fc5ca4489def16ac92e2f8260ccc26d792
Reviewed-on: https://chromium-review.googlesource.com/167542
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
This is needed by some drivers and use cases (mostly
around ChromeOS functionality on ARM)
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=compile tested, no functional change
BUG=none
Change-Id: I38dfdcb4c2e3dde1e94315828a195b077660b4ff
Reviewed-on: https://chromium-review.googlesource.com/167541
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Since we're now supporting ARMv7 relocations, we can enable
rmodule support on Exynos 5420. This does not automatically
enable relocatable ramstage.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=needs more changes
BUG=none
Change-Id: Ic3af1eabb3b816944587a46409224f778d941b8a
Reviewed-on: https://chromium-review.googlesource.com/167403
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Long term we should unify ARM and x86 handling of situations like this.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
BRANCH=none
TEST=needs further changes
BUG=none
Change-Id: Iac598234262264117553c8ce915ddcb7fcc6509e
Reviewed-on: https://chromium-review.googlesource.com/167402
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
