| Age | Commit message (Collapse) | Author |
|---|
|
BUG=None
BRANCH=None
TEST=Compiles successfully for veyron_pinky
Original-Change-Id: I3862e9bf2c32085c921adae4c1dcdf88ff0f3ff3
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/227243
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 0fabdbb05826160beb8ee8f89339b18a49e87ab8)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I4504d29a43084d4bd406626899b25903200fa6d7
Reviewed-on: http://review.coreboot.org/10740
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
BUG=none
BRANCH=none
TEST=built w/ follow-up rialto patch
Change-Id: I166c75673c199e8c6860f601db6759cdc3cb9c96
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ba0e0b639f12654ec54216d4366c688baa5b3253
Original-Change-Id: Id21c87ace2f4d381a1e374e1d5fe15cf1cd96da0
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/282047
Reviewed-on: http://review.coreboot.org/10779
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We currently select either HDMI or EDP (default). This patch
allows us to use HDMI as a fallback for devices that may have
a display connected on either interface. It also renames the
enums to sound a little more sensible in other contexts (more
on that in the follow-up patches).
VOP_MODE_AUTO is added to the mode enum which will make it explicit
that a board can support either. In AUTO_MODE we will try EDP first
and then fallback to HDMI. Other modes can be set to force a certain
behavior such as HDMI-only on Mickey where it doesn't make sense to
try EDP.
A follow-up patch will add logic for when we explicitly don't want
to probe for any display (headless devices).
BUG=none
BRANCH=none
TEST=On veyron_danger, connected EDP and HDMI displays and saw dev
mode screen appear on EDP display. Unplugged EDP and then dev mode
screen showed up on HDMI.
Change-Id: I22b38031c4ab3d79fbb182f7a906da1197f35543
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3f57ed3758c4e516d9fd226ad9499b102b81b423
Original-Change-Id: I352dcde16f7f3ebbf5796852b685685e541eb794
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/281076
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10775
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
this is an brief hdmi driver which config with simple
display parameter, const encoder input & output color
format and 8bit color depth, and only 48KHz audio support.
what's more to prevent TV have not show an right things
before coreboot switch to kernel space, we have to add
an terrible 2s delay to driver (2s come from test many
times), cause we have to wait TV to respond (we got no
flag to check whether it is ready).
BUG=chrome-os-partner:40337
TEST=Booted Veyron Jerry and display normal
BRANCH=None
Change-Id: Icd33467e95de6219e1b614616f0112afc52097b6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7e5b699aff75a579116aae63d858c834b2f648e8
Original-Change-Id: Iedc87c011c5b62ce5f16a296dd9c3e0c2eaba59b
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272565
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Original-Commit-Queue: Lin Huang <hl@rock-chips.com>
Original-Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-on: http://review.coreboot.org/10625
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BUG=none
BRANCH=none
TEST=Boot from mickey board
Change-Id: I6eadf52bddcf89011a112a8e5dee5e752556add9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e3c865f0bf8567c3183d7948a0f9e8361db70695
Original-Change-Id: I438527ee0870044f48b23a6842986e7cf166e191
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/276290
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/10477
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
The struct rockchip_spi_media type is no longer used;
nor is initialize_rockchip_spi_cbfs_media(). Remove them.
Change-Id: I2c24be249e0cd89e2dd328e05cdd24a178fe37e8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10214
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This patch adds the necessary platform glue to allow the use of
software-driven I2C bit banging on the RK3288. This is just a debugging
feature that can be used to reproduce certain I2C failure cases.
Also fix Makefile verstage linking for the feature and add some new
rk3288 IOMUX macros as needed.
BRANCH=None
BUG=None
TEST=Added "CONFIG_SOFTWARE_I2C=y" to configs/config.veyron_jerry,
wrapped Jerry's bootblock and verstage in software_i2c_attach/detach()
calls, confirmed that both PMIC and TPM could be driven correctly with
software I2C driver. Tried out different combinations of
software_i2c_wedge_ack() and software_i2c_wedge_read() on the PMIC and
observed transfer results with the hardware controller after reboot...
the worst that would happen is that the first register read-modify-write
(DCDC_ILMAX) would fail to read, but all later transfers would be fine.
Since that register is written twice (due to current BUCK1 ramp
implementation) and is not terribily important anyway, I think we don't
need to worry about wedging problems.
Change-Id: Iba801ee61d30fb1fd3aef8300612c67fa50c441b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 24dfca9bab38a20c40ef0c2dd4c775b8d8f47487
Original-Change-Id: I96777300a57c85471bad20e23a455551e9970222
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/247890
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9757
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Many ChromeOS devices use a GPIO to reset the system, in order to
guarantee that the TPM cannot be reset without also resetting the CPU.
Often chipset/SoC hardware watchdogs trigger some kind of built-in
CPU reset, bypassing this GPIO and thus leaving the TPM locked. These
ChromeOS devices need to detect that condition in their bootblock and
trigger a second (proper) reboot.
This patch adds some code to generalize this previously
mainboard-specific functionality and uses it on Veyron boards. It also
provides some code to add the proper eventlog entry for a watchdog
reset. Since the second reboot has to happen before firmware
verification and the eventlog is usually only initialized afterwards, we
provide the functionality to place a tombstone in a memlayout-defined
location (which could be SRAM or some MMIO register that is preserved
across reboots).
[pg: Integrates
'mips: Temporarily work around build error caused by <arch/io.h> mismatch]
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Run 'mem w 0xff800000 0x9' on a Jerry, watch how a "Hardware
watchdog reset" event appears in the eventlog after the reboot.
Change-Id: I0a33820b236c9328b2f9b20905b69cb934326f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fffc484bb89f5129d62739dcb44d08d7f5b30b33
Original-Change-Id: I7ee1d02676e9159794d29e033d71c09fdf4620fd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242404
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506
Original-Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242504
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Turns out there are uses for memlayout regions not specific to vboot2.
Rather than add yet another set of headers for a single region, let's
make the vboot2 one common for chromeos.
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm.
Change-Id: I228e0ffce1ccc792e7f5f5be6facaaca2650d818
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b
Original-Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242630
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
we use Kconfig define sdram size before, but there may use
different sdram size in the same overlay, so we must detect
sdram size at runtime now. If we use 4G byte sdram, we can
use[0x00000000:0xff000000], since the [0xff000000:0xffffffff]
is the register space.
BUG=chrome-os-partner:35521
TEST=Boot from mighty
BRANCH=None
Change-Id: I7a167c268483743c3eaed8b71c7ec545a688270c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ad4f27dd08c467888eee87e3d9c4ab3077751898
Original-Change-Id: Ib32aed50c9cae6db495ff3bab28266de91f3e73b
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/243139
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9734
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We've traditionally tucked the framebuffer at the end of memory (above
CBMEM) on ARM and declared it reserved through coreboot's resource
allocator. This causes depthcharge to mark this area as reserved in the
kernel's device tree, which may be necessary to avoid display corruption
on handoff but also wastes space that the OS could use instead.
Since rk3288 boards now have proper display shutdown code in
depthcharge, keeping the framebuffer memory reserved across the handoff
(and thus throughout the lifetime of the system) should no longer be
necessary. For now let's just switch the rk3288 implementation to define
it through memlayout instead, which is not communicated through the
coreboot tables and will get treated as normal memory by depthcharge.
Note that this causes it to get wiped in developer/recovery mode, which
should not be a problem because that is done in response to VbInit()
(long before any images are drawn) and 0 is the default value for a
corebootfb anyway (a black pixel).
Eventually, we might want to think about adding more memory types to
coreboot's resource system (e.g. "reserved until kernel handoff", or
something specifically for the frame buffer) to model this situation
better, and maybe merge it with memlayout somehow.
CQ-DEPEND=CL:239470
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Booted Jerry, noticed that 'free' now displays 0x7f000 more bytes
than before (curiously not 0x80000 bytes, I guess there's some alignment
waste in the kernel somewhere). Made sure the memory map output from
coreboot looks as expected, there's no visible display corruption in
developer/recovery mode and the 'cbmem' utility still works.
Change-Id: I12b7bfc1b7525f5a08cb7c64f0ff1b174df252d4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2
Original-Change-Id: I1950407d3b734e2845ef31bcef7bc59b96c2ea03
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240819
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch activates the chip driver for Winbond SPI flash (which,
incidentally, looks 99.9% the same as the Gigadevice driver but still
requires some extra 500+ bytes of object code... there's definitely room
for improvement here). Shuffle around rk3288 memlayout to make a little
more room in the bootblock.
BRANCH=veyron
BUG=chrome-os-partner:34176
TEST=Booted Pinky. Checked bootblock and verstage memsz of final binary
and noticed that both only have less than 500 bytes left against their
memlayout boundary. The next piece of code we add will cause some
serious headaches...
Change-Id: I97ea6ac334104e4219e310afc557c164b2ff19d9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8769e5a34ad3cd417132646fbb58ff51c29fb640
Original-Change-Id: Id2f1204c30aa28251cf85cb80d7ca44947388dba
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236977
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9719
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
we use the delay 200ms to meet the edp power timing request before,
it waste time, so we use the HPD function to detect the edp panel now.
In previous version, the hardware may not support the edp HPD function,
so in the code it will spend 200ms to detect hpd single, if it don't get
the hpd single, it will contiue the edp initialization process, to compatible
all of the hardware version.
BUG=chrome-os-partner:35623
TEST=Boot from Mighty, and display normal
BRANCH=None
Change-Id: I82c6a80e37fa42eef3521e6ebbf190d7e80fcece
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 7a5343eb9af12cae9a15284217762a91ae24bac6
Original-Change-Id: I21c0ef6ce4643e90a192d8b86659264895b5fda9
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242792
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: http://review.coreboot.org/9659
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This moves PMIC_BUS from each mainboard's board.h file to a per-
mainboard Kconfig variable. To prevent humans from forgetting to
set a valid value, an invalid default is set in the rk3288 Kconfig
and checked in rk808.c so that compilation will fail if the mainboard
Kconfig does not override it.
Originally, PMIC_BUS was only used by mainboard code as an argument
to RK808 PMIC functions. To conform to the generic RTC API, however,
the RK808 code needs to have the bus number globally defined somewhere
since the rtc_get() and rtc_set() functions don't take any args.
Since CONFIG_PMIC_BUS is globally visible, we no longer need to pass
bus number to the PMIC functions.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I73783878e507b2e7b1526dd2f81cfbdf8f1e2a55
Reviewed-on: https://chromium-review.googlesource.com/240203
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9642
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
This patch implements support for the CRYPTO module in RK3288 and ties
it into the new vboot vb2ex_hwcrypto API. We only implement SHA256 for
now, since the engine doesn't support SHA512 and it's very unlikely that
we'll ever use SHA1 for anything again.
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed that it uses the hardware crypto engine and
that firmware body hashing time dropped to about 1.5ms (from over 70ms).
Change-Id: I91d0860b42b93d690d2fa083324d343efe7da5f1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: e60d42cbffd0748e13bfe1a281877460ecde936b
Original-Change-Id: I92510082b311a48a56224a4fc44b1bbce39b17ac
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236436
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9641
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
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>
|
|
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>
|
|
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>
|
|
This patch doubles the ACLK peripheral clock for the PD_BUS power domain
to 297MHz, which is the closest to the maximum of 300MHz we can reach by
dividing GPLL. This frequency directly translates into SRAM speed, so
maximizing it has a huge impact on boot speed (especially with the lack
of SRAM caching).
BUG=chrome-os-partner:32987
TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed
that the (visibly) long signature verification times are nearly halved.
Change-Id: Iafa3044854a4058a7f885c775119d964a6295de4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c230585f4344d0eab4f8eeaa761869965f2da08a
Original-Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/224524
Original-Trybot-Ready: Doug Anderson <dianders@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9600
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Implement VOP and eDP drivers, vop and edp clock configuration,
framebuffer allocation and display configuration logic.
The eDP driver reads panel EDID to determine panel dimensions
and the pixel clock used by the VOP.
The pixel clock is generating using the NPLL.
BUG=chrome-os-partner:31897
TEST=Booted Veyron Pinky and display normal
BRANCH=None
Change-Id: I01b5c347a3433a108806aec61aa3a875cab8c129
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e4f863b0b57f2f5293ea8015db86cf7f8acc5853
Original-Change-Id: I61214f55e96bc1dcda9b0f700e5db11e49e5e533
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/219050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9553
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This moves vboot1 and vboot2 files to their designated directory. Common
code stays in vendorcode/google/chromeos.
BUG=none
BRANCH=none
TEST=built cosmos, veyron_pinky, rush_ryu, nyan_blaze, samus, parrot,
lumpy, daisy_spring, and storm.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Ia9fb41ba30930b79b222269acfade7ef44b23626
Original-Reviewed-on: https://chromium-review.googlesource.com/222874
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit cbfef9ad40776d890e2149b9db788fe0b387d210)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia73696accfd93cc14ca83516fa77f87331faef51
Reviewed-on: http://review.coreboot.org/9433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
We've had gpiolib.h which defines a few common GPIO access functions for
a while, but it wasn't really complete. This patch adds the missing
gpio_output() function, and also renames the unwieldy
gpio_get_in_value() and gpio_set_out_value() to the much easier to
handle gpio_get() and gpio_set(). The header is renamed to the simpler
gpio.h while we're at it (there was never really anything "lib" about
it, and it was presumably just chosen due to the IPQ806x include/
conflict problem that is now resolved).
It also moves the definition of gpio_t into SoC-specific code, so that
different implementations are free to encode their platform-specific
GPIO parameters in those 4 bytes in the most convenient way (such as the
rk3288 with a bitfield struct). Every SoC intending to use this common
API should supply a <soc/gpio.h> that typedefs gpio_t to a type at most
4 bytes in length. Files accessing the API only need to include <gpio.h>
which may pull in additional things (like a gpio_t creation macro) from
<soc/gpio.h> on its own.
For now the API is still only used on non-x86 SoCs. Whether it makes
sense to expand it to x86 as well should be separately evaluated at a
later point (by someone who understands those systems better). Also,
Exynos retains its old, incompatible GPIO API even though it would be a
prime candidate, because it's currently just not worth the effort.
BUG=None
TEST=Compiled on Daisy, Peach_Pit, Nyan_Blaze, Rush_Ryu, Storm and
Veyron_Pinky.
Change-Id: Ieee77373c2bd13d07ece26fa7f8b08be324842fe
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9e04902ada56b929e3829f2c3b4aeb618682096e
Original-Change-Id: I6c1e7d1e154d9b02288aabedb397e21e1aadfa15
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220975
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9400
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch is the start of a series to change all non-x86 SoC-specific
headers to be included as <soc/header.h> instead of the old
<soc/vendor/chip/header.h> or "header.h". It will add an include/soc/
directory under every src/soc/vendor/chip/ and append the .../include/
part of that to the global include path.
This matches the usage of <arch/header.h> for architecture-specific
headers and had already been done for some headers on Tegra. It has the
advantage that a source file which does not know the specific SoC used
(e.g. Tegra files common for multiple chips, or a global include file)
can still include SoC-specific headers and access macros/types defined
there. It also makes the includes for mainboard files more readable, and
reduces the chance to pull in a wrong header when copying mainboard
sources to use a different-related SoC (e.g. using a Tegra124 mainboard
as template for a Tegra132 one).
For easier maintainability, every SoC family is modified individually.
This patch starts out by changing Rk3288. Also alphabetized headers in
affected files since we touch them anyway.
BUG=None
TEST=Whole series: compared binary images for Daisy, Nyan_Blaze,
Rush_Ryu, Storm, Urara and Veyron_Pinky. Confirmed that they are
byte-for-byte identical except for timestamps, hashes, and __LINE__
macro replacements. Compile-tested individual patches.
Change-Id: I4d74a0c56be278e591a9cf43f93e9900e41f4319
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ad8b6d2e0280428aa9742f0f7b723c00857334a
Original-Change-Id: I415b8dbe735e572d4ae2cb1df62d66bcce386fff
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222025
Reviewed-on: http://review.coreboot.org/9349
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
