Gold Linker does not support properly customized ld script.
BRANCH=none?? Is this correct? I am not sure of this.
BUG=chromium:461220
TEST=build coreboot under rush_ryu
Signed-off-by: Han Shen <shenhan@google.com>
Change-Id: Ic2f5a8000d764ff7374aa1aaa00895dafb75f307
Reviewed-on: https://chromium-review.googlesource.com/252870
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Han Shen <shenhan@chromium.org>
Tested-by: Han Shen <shenhan@chromium.org>
(cherry picked from commit 319365c7b11a5e48d8ecc5141b4b954c5533c85d)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/255972
This patch adds a few retries to NVRAM read/write transactions with the
EC. Failing to read the NVRAM is not fatal to the boot, but it's still
pretty bad... especially since a single initial read failure will cause
vboot to blindly reinitialize the whole NVRAM with zeroes, destroying
important configuration bits like dev_boot_usb. The current EC
transaction timeout is one second, so the three retries added here can
potentially increase boot time by three seconds per transaction... but
this shouldn't happen in any normal case anyway, and if there are errors
a little extra wait is probably preferrable to nuking your NVRAM.
(Also, added a missing newline to an error message in the EC code.)
BRANCH=veyron
BUG=chrome-os-partner:36924
TEST=Booted a Jerry with the power button bug with a 2 second press,
noticed that the first two transactions failed but the third one
succeeded.
Change-Id: I6267cdda2be2bad34541b687404c2434d3be345b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251694
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 894a8a0b4a9805e92544b5e3dfa90baf6d36649a)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251813
This brings brain, danger, and rialto up to parity with other
veyron platforms as far as eventlog functionality is concerned.
BUG=chrome-os-partner:34436
BRANCH=none
TEST="mosys eventlog list" shows events (tested on Brain)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ief09299965f6f21bc5a40cef31cde61344025c2a
Reviewed-on: https://chromium-review.googlesource.com/239979
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 1764bc53147718031231a6d125a4a1a96c4c6a8f)
jwerner: removed danger and rialto
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247157
This applies a previous patch ("chromeos: Provide common watchdog
reboot support") to some veyron platforms that were missing it.
BUG=none
BRANCH=none
TEST=built and booted on Brain
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I2861939655a995d309847f64cecd974a740fae37
Reviewed-on: https://chromium-review.googlesource.com/245633
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit b0c87dd4217917a35817c719efe43dd4ec442df0)
jwerner: removed danger and rialto
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247156
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: I21c0ef6ce4643e90a192d8b86659264895b5fda9
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/242792
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
(cherry picked from commit 7a5343eb9af12cae9a15284217762a91ae24bac6)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247155
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: Ib32aed50c9cae6db495ff3bab28266de91f3e73b
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/243139
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ad4f27dd08c467888eee87e3d9c4ab3077751898)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247154
backlight timing: LED_VCC->LED_PWM->LED_EN, we modify the
code to meet the timing.
BUG=chrome-os-partner:36201
TEST=Boot from jerry, and scope the backlight timing
BRANCH=None
Change-Id: I6c53a822410ad706383c6d9fa2b5f0437775f710
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/244639
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 52ac0b2944cea7dc860bfea12fe44851436bb7f7)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247153
ChromeOS/vboot devices expect the TPM PCRs 0 and 1 to be extended with
digests that attest the chosen boot mode (developer/recovery) and the
HWID in a secure way. This patch uses the newly added vboot2 support
functions to fetch these digests and store them in the TPM.
CQ-DEPEND=CL:245530
BRANCH=veyron
BUG=chromium:451609
TEST=Booted Jerry. Confirmed that PCR0 contains the same value as on my
vboot1 Blaze and Falco (and PCR1 contains some non-zero hash).
Change-Id: I7037b8198c09fccee5440c4c85f0821166784cec
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245119
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 8b44e13098cb7493091f2ce6c4ab423f2cbf0177)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245496
sd->fw_version represents the version of the *current* firmware, which
is not necessarily the same as the one stored in the TPM (and may be 0
in recovery mode). Use the newly added sd->fw_version_secdata instead
which contains a more correct value.
CQ-DEPEND=CL:245531
BRANCH=veyron
BUG=chrome-os-partner:35941
TEST=Booted Jerry in recovery mode, confirmed crossystem tpm_fwver was
corrent (and not 0).
Change-Id: Id95bd8c6412f2e8b2ae643c3b5a3dee13d0d47be
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/244591
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit eb8142f69cea34e11f9081caafcaae7a15cc3801)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245495
we will use dvs to adjust the voltage in kernel, if device reset
by watchdog in kernel, the dvs gpio may not reset, and we use the
i2c to adjust rk808 voltage in coreboot, so it may failure. so we
move the reboot_from_watchdog() before the rk808 setting.
BUG=None
TEST=Boot from speedy
BRANCH=None
Change-Id: I92b5c6413bbffe30566178de89df1f9683790982
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/244289
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 76efb4b0196eecc84664a4c5dce2221152a39c0a)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245494
Our <arch/io.h> headers are a mess and not in any way as
arch-independent as their pathname makes it sound. CL:242404 made this
blow up, but it's really just surprising that this didn't happen
earlier already.
This patch is just a quick fix to make MIPS ChromeOS boards buildable
again while we deal with the real issue of aligning the interfaces.
BRANCH=none
BUG=chromium:451270,chromium:451388
TEST=Booted Jerry, built Falco and Urara.
Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242504
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243127
Our use of the bucks may exceed their default maximum inductor current.
Just set it to the highest possible value for every buck we configure to
avoid problems... the kernel can later fine-tune the values further if
needed. (Also some slight grammar updates while I'm in there.)
BRANCH=veyron
TEST=Build and Boot on Jerry
BUG=None
Change-Id: I3801cabeb93d7bf7ecc02db0e69d4932c9394db9
Signed-off-by: huang lin <hl@rock-chips.com>
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242785
Reviewed-by: Douglas Anderson <dianders@chromium.org>
(cherry picked from commit 065a163bb902b8c96d05bfef6ed4885aa20f31cc)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243126
tMRD request 10nCK in LPDDR3, we set the DDR_PCTL_TMRD BIT0~BIT2 to generate
this single, but the max value we can set is 7, can not meet the standard.So,
now we send the Mode Register Set command manual,and we can add the delay
manual.
BUG=chrome-os-partner:34608
TEST=loop reboot
BRANCH=veyron
Change-Id: I0d29ea9cd82ef018e835ae53090a47d0299ef61d
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/242176
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit b60a4de6ff3ad3720c2c06ed7de03ed942360e6c)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243125
the reset single request 200us, we set the DDR_PUBL_PTR2 BIT0~BIT16 to
generate this single, when DDR run the 666Mhz, we calculate the value 0x20850,
exceed 0x1ffff(max value support by 17bit), so only 0x850 work, it only
generate 3.5us reset single, whitch don't meet the standard. So, now we set to maximun
when the value overflow, the reset single is 196us when ddr run the 666MHz.
BUG=chrome-os-partner:34875
TEST=loop reboot
BRANCH=veyron
Change-Id: I9b410e1605c87f12a5ca96ead12f8527ca4f417f
Signed-off-by: jinkun.hong <jinkun.hong@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/242175
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 767a4a3cb8dff47cb15064d335b78ffa5815914d)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243124
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).
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: I7ee1d02676e9159794d29e033d71c09fdf4620fd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242404
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit fffc484bb89f5129d62739dcb44d08d7f5b30b33)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243123
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: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242630
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243122
This patch adds a new "backlight" output GPIO to the coreboot table in
order to avoid redundantly defining that GPIO in the payload.
BRANCH=veyron
BUG=chrome-os-partner:34713
TEST=Tested together with corresponding depthcharge CL.
Change-Id: I69b3c7ac6be4b9723b6a0dfecef5e1c4ea681aff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242400
Tested-by: Lin Huang <hl@rock-chips.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 04ce4c23573cf926aeef3d817d3ab00835f897c7)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243121
The first platform that used flash-backed VBNV data has a physical
recovery switch, get_recovery_mode_from_vbnv() was never implemented.
This patch adds get_recovery_mode_from_vbnv() similarly to how it's
implemented for other vbnv storage in other places.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=needs testing
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I9cf18c988eaa4b7e720d6c66a02b1c5c63b473e9
Reviewed-on: https://chromium-review.googlesource.com/239978
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 09f1bf96089bf9d159e4220c1f4d99388d709545)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243120
BRANCH=None
TEST=Build speedy, pinky, mighty
BUG=None
Change-Id: I7c97d54f3a4c94f7e23d3e85b808cd64b1cacec7
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/241939
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit e6be62b4e64b13e285eb0480fdc65d814c6dadc0)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243099
I always had that TODO comment in there but I had already forgotten what
I even meant by it. It's really just a simple cleanup... this function
is (currently) veyron-specific and doesn't belong in common code.
BRANCH=veyron
BUG=None
TEST=Booted Jerry.
Change-Id: I6ce701a15a6542a615d3d81f70aa71662567d4fa
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241190
(cherry picked from commit d188398704575ad2fedc2a715e609521da2332b0)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243098
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:243110
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: I1950407d3b734e2845ef31bcef7bc59b96c2ea03
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240819
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 10afdba54dd5d680acec9cb3fe5b9234e33ca5a2)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243097
K4B4G1646Q-HYK0 is different form K4B4G1646D-BYK0 with chip physical
package and they have the same config parameters.
BRANCH=none
BUG=chrome-os-partner:34940
TEST=boot on Jerry board with K4B4G1646Q-HYK0
Change-Id: I31bcb348a45ff76e8e08127063bd0d04443ccb79
Signed-off-by: Paul Ma <magf@bitland.com.cn>
Reviewed-on: https://chromium-review.googlesource.com/241787
Reviewed-by: Julius Werner <jwerner@chromium.org>
Trybot-Ready: Julius Werner <jwerner@chromium.org>
(cherry picked from commit e925d784e1ebe444f5a5bcab47c8a661b0c6c527)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/243096
We've decided that it is generally okay for coreboot to expect unaligned
accesses to work. Trying to find all instances of unaligned access
opportunities and working around them in software would be an
unsustainable whack-a-mole contest. Instead, architectures and boards
need to make sure they conform to this, which on ARM and ARM64 requires
setting up paging early in the bootblock.
Other architectures (x86, ARM64, MIPS) already generate code in this
manner. ARM still had an -mno-unaligned-access flag hanging around that
has been copied so many times its initial origin was lost in time
(probably U-Boot). Let's remove it for consistency between architectures
and to improve code generation.
BRANCH=veyron
BUG=None
TEST=Booted Jerry and Blaze. Looked at the disassembly for
timestamp_sync() and confirmed that it only gives you half as much eye
cancer as before (GCC still somehow insists on byte accesses when
zeroing fields which is very odd, but at least that terrible AND/OR mess
is gone). Measured a boot time increase of about 11ms on Jerry (mostly
faster timestamp and CBFS accesses). Could not test Storm because
despite our claimed abundance of test devices, every time I get one of
them it magically disappears again in less than a week.
Change-Id: I1d046e05bb11822b86e467eafb6aa92e8fbce774
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/241732
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242162
Toolchain variables (CFLAGS, INCLUDES, etc.) defined by
create_class_compiler can be updated in toolchain.inc only after call
to create_class_compiler is performed. Here, CFLAGS_nonx86 was added
to CFLAGS_arm64 before create_class_compiler and hence the flags did
not show up during compilation.
BUG=None
BRANCH=None
TEST=Checked that dummy unused function does not show up in
ramstage.elf for ryu.
Change-Id: Ia152aaeef6d68f31eddda88506ee6630749f9dbb
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/239245
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242161
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
LDO4 and LDO5 are not turned on with the boot0 and boot1 RK808
strappings that we use on Brain.
BUG=none
BRANCH=none
TEST=built and booted on brain
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I846ef9d67a780cc07414d545524b9ec0b8490cf1
Reviewed-on: https://chromium-review.googlesource.com/241734
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242160
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
decode_edid() parses the whole edid buffer, regardless of whether there
is an extension buffer, so we pass the size of the EDID actually read to
prevent edid parser getting the wrong data.
BUG=chrome-os-partner:35053
TEST=Boot from jerry
BRANCH=veyron
Change-Id: I8cd8e09025520322461fe940b01e4af3995b5ecd
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/240643
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242159
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
This adds a 10us delay in between (re-)configuring and reading
GPIOs in gpio_base2_value() to give the values stored some time
to update.
As far as I know this hasn't bitten us since the function was
added, but adding a short delay here seems like the right thing
to do.
BUG=none
BRANCH=none
TEST=built and booted on Brain
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I79616a09d8d2ce4e416ffc94e35798dd25a6250d
Reviewed-on: https://chromium-review.googlesource.com/240854
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242158
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Even though coreboot always hardcodes the FMAP offset, the same is not
possible for all other tools that manipulate ROM images. Some need to
manually find the FMAP by searching for it's magic number (ASCII
"__FMAP__"). If we do something like 'memcmp(fmap_buffer, "__FMAP__",
...) in coreboot code, it has the unfortunate side effect that the
compiler will output that very same magic number as a constant in the
.rodata section to compare against. Other tools may mistake this for the
"real" FMAP location and get confused.
This patch reverses the constant defined in coreboot and changes the
only use of it correspondingly. It is not impossible but extremely
unlikely (at the current state of the art) that any compiler would be
clever enough to understand this pattern and optimize it back to a
straight memcmp() (GCC 4.9 definitely doesn't), so it should solve the
problem at least for another few years/decades.
BRANCH=veyron
BUG=chromium:447051
TEST=Made sure the new binaries actually contain "__PAMF__" in their
.rodata. Booted Pinky. Independently corrupted both the first and the
last byte of the FMAP signature with a hex editor and confirmed that
signature check fails in both cases.
Change-Id: I725652ef2a77f7f99884b46498428c3d68cd0945
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240723
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242157
Total FIFO length is split into many 512 byte blocks,
because the max packet size in coreboot is 512 byte,
then allot these blocks to GRXFSIZ and GNPTXFSZ evenly.
This method avoids the hardcoding and make the FIFO size
value work for dwc2 controller that has different FIFO ram size.
BUG=chrome-os-partner:32634
BRANCH=None
TEST=Boot kernel from USB
Change-Id: Ib50a08c193f7f65392810ca3528a97554f2c3999
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/233119
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242156
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
BUG=chrome-os-partner:34436
BRANCH=none
TEST=Built and booted on pinky w/ depthcharge fmap patch,
used mosys to verify that eventlog entries get populated:
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I19cb884be5c3e00975599e96e0223e33d32e7c0d
Reviewed-on: https://chromium-review.googlesource.com/238830
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242155
This adds RTC functions to the existing RK808 driver.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=with eventlog patches applied to pinky, booted and saw eventlog
entries generated with correct timestamps:
localhost ~ # mosys -k eventlog list
entry="0" timestamp="2015-01-06 13:45:33" type="Log area cleared" bytes="4096"
entry="1" timestamp="2015-01-06 13:45:33" type="System boot" count="0"
entry="2" timestamp="2015-01-06 13:45:33" type="Chrome OS Developer Mode"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I3a240e342a54b2e7023da71708d0d70f5131f0b9
Reviewed-on: https://chromium-review.googlesource.com/238525
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242154
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: https://chromium-review.googlesource.com/242153
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
The current vbnv flash code mistakenly uses the offset into the NVRAM
area as the absolute offset into the SPI NOR. This causes overwrites
RO section of the flash (when it is not protected) and causes failures
to retrieve the NVRAM contents by the user space apps.
This patch makes sure that the correct offset is used when accessing
NVRAM area in the SPI flash.
BRANCH=storm
BUG=chrome-os-partner:35316
TEST=run the update code on storm.
- no more RO section corruption observed
- running 'crossystem recovery_request=1' at Linux prompt causes the
next boot happen in recovery mode
Change-Id: I86fe4b9a35f7c16b72abf49cfbfcd42cc87937e3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240143
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242152
Tested-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Some common VBNV variable offsets were defined in multiple vbnv_*
source files. This moves them to a header so that we can avoid
duplicating them in the future.
BUG=none
BRANCH=none
TEST=compiled for nyan_blaze and rambi
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ifcc13c90a910b86d4f9bb0027d913572c1d6d00b
Reviewed-on: https://chromium-review.googlesource.com/239977
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242151
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
The correct return value for errors on a cbfs_media->map() call is
CBFS_MEDIA_INVALID_MAP_ADDRESS, not NULL. Not sure if that's the best
choice (since 0xffffffff is probably a more likely valid address than 0
there), but that's what the upper layers expect right now.
BRANCH=veyron
BUG=None
TEST=Press CTRL+L with an RW_LEGACY section filled with 0xff. Observe
how cbfs_get_header() returns failure without doing a bunch of NULL
pointer accesses first (not that those have any visible effect on
Veyron, but that's another problem...)
Change-Id: I0793434116a8c568e19fe0dee24f13942fc50f25
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/238991
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242150
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: I92510082b311a48a56224a4fc44b1bbce39b17ac
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236436
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242139
This patch aligns our verstage code to the new API addition in vboot2.
The hardware crypto functions are stubbed out by default and just
pretend that all algorithms are unsupported, causing vboot to fall back
to the normal software hashing code. These weak symbols can be
overridden by individual platform code to provide actual hardware
crypto engine support.
CQ-DEPEND=CL:242124
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed vboot falls back to software crypto.
Change-Id: Idf6a38febd163aa2bff6e9a0e207213f01ca8324
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236435
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242138
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 512K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236978
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242137
The current display init code causes Brain to crash when trying
to allocate resources. This just avoids doing display init if a
config variable is set. Once code has been implemented to properly
setup different types of displays we can get rid of this hack.
BUG=none
BRANCH=none
TEST=built and booted (to depthcharge) on Brain, compiled for
pinky with FEATURES=noclean and ensured config variable is 0
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I04c9e8181c58fa0608fd20776fa8c4798a023474
Reviewed-on: https://chromium-review.googlesource.com/235922
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242136
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
This applies the differences between Jerry and Brain:
- No EC
- No SD card
- Minor changes to GPIOs (no lid, power button active low)
- No variations between board IDs (yet)
- No backlight/display attached, but we do have some HDMI
and VOP configuration (need to double check that it's right).
BUG=none
BRANCH=none
TEST=built and booted on Brain (requires follow-up CL
to get into depthcharge)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I3c761d3d4d186a6208a772c05193bdcbd4a5c105
Reviewed-on: https://chromium-review.googlesource.com/235921
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242135
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
This adds a directory with files copied over from Jerry, in addition to
build system related changes (configs/* and Kconfig stuff) necessary
to emerge-veyron_brain coreboot.
The next patch will account for differences between Jerry and Brain.
BUG=none
BRANCH=none
TEST=emerge-veyron_brain coreboot works
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I972f2623d9b0a43e3ea5312b3c4cd34ab44edc36
Reviewed-on: https://chromium-review.googlesource.com/236989
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/242134
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
For coreboot Gus and Jaq are the same as mighty.
Copy from Mighty.
BUG=chrome-os-partner:35238
TEST=emerge coreboot
BRANCH=veyron
Change-Id: I7ec68401e6b053d54f8666b3d56d9da20e224605
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/239475
Reviewed-by: Julius Werner <jwerner@chromium.org>
Jaq and Gus are exactly the same as Mighty, copy configs
from Mighty
BUG=chrome-os-partner:35238
TEST=emerge libpayload
BRANCH=veyron
Change-Id: I92817cd223341ef9f195b9f3495c6dac4e0e1b83
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/239474
Reviewed-by: Julius Werner <jwerner@chromium.org>
veyron_minnie hardware is the same to the pinky4, so
modify the mainboard.c to fit the hardware.
BUG=chrome-os-partner:33269
TEST=emerge-veyron_minnie coreboot
BRANCH=firmware-veyron-6588.B
Change-Id: I0e79e2807b8d25d3461038d13269433e727b2efa
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/237621
Reviewed-by: Julius Werner <jwerner@chromium.org>
since i forgot add src/mainboard/google/veyron_minnie/Kconfig
to src/mainboard/google/Kconfig, it will lead to compile err.
BUG=chrome-os-partner:33269
TEST=emerge-veyron_minnie coreboot
BRANCH=firmware-veyron-6588.B
Change-Id: I0071d272d96491593c64e4ecd3f6365ad7f8550d
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/237620
Reviewed-by: Julius Werner <jwerner@chromium.org>
Trybot-Ready: Julius Werner <jwerner@chromium.org>
TEST=emerge-veyron_minnie coreboot
BUG=None
Change-Id: Ic7bba4e5b584f4123d07aa45b5110d94e55818c8
Signed-off-by: Lang Zhang <kingsley_zhang@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/237576
Reviewed-by: Julius Werner <jwerner@chromium.org>
BRANCH=None
TEST=emerge-veyron_speedy coreboot
BUG=None
Change-Id: Id5024bfd32a0aa1fb00f3af8dc337ccccaf40729
Signed-off-by: Jiazi Yang <Tomato_Yang@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/237544
Reviewed-by: Julius Werner <jwerner@chromium.org>
Trybot-Ready: Julius Werner <jwerner@chromium.org>
(cherry picked from commit fedf6ed7dc220d58ad10d49ac9ea02443746e77e)
Reviewed-on: https://chromium-review.googlesource.com/237971
BUG=None
TEST=emerge veyron_speedy and Boot the speedy board
BRANCH=None
Change-Id: I2f0cff74517a8c031eabb64f4f82d455195c8dd1
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234715
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 42c0d11c3ec65874986c06ca4d7b34f5987f9409)
Reviewed-on: https://chromium-review.googlesource.com/237716
Reviewed-by: Katie Roberts-Hoffman <katierh@chromium.org>
Commit-Queue: Jiazi Yang <Tomato_Yang@asus.com>
Tested-by: Jiazi Yang <Tomato_Yang@asus.com>
Essentially a copy of veyron_speedy for now.
BUG=chrome-os-partner:33269
TEST=build
Change-Id: Ib10fe9fd7337e197ba376b2e9be632b1ad83f74e
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/237413
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=chrome-os-partner:33269
TEST=emerge-veyron_minnie libpayload
Change-Id: I37b46cb903fec33de8c60fe142a4d2458b65092d
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/237412
Reviewed-by: Julius Werner <jwerner@chromium.org>
