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>
BRANCH=None
TEST=Boot and run jerry rev2 board
BUG=None
Change-Id: Ice60a4576c9eb386599a545c1b8d470e8a2eed68
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/236500
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Paul Ma <magf@bitland.com.cn>
Tested-by: Paul Ma <magf@bitland.com.cn>
(cherry picked from commit f9075e6172d1ae503dc26bac8f1057455dc93c39)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237204
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: Id2f1204c30aa28251cf85cb80d7ca44947388dba
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236977
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 8769e5a34ad3cd417132646fbb58ff51c29fb640)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237203
The TPM driver by default allocates a 4K transfer buffer on the stack,
which leads to lots of fun on boards with 2K or 3K stack sizes. On
RK3288 this ends up writing over random memory sections which dependent
on the memlayout of the day might contain timestamp data (no big deal)
or page tables (-> bad time).
This patch fixes the problem by reducing the buffer size to slightly
above 1K, which still seems to work as far as I can tell. There was
already some really odd code that #undef'ed this value and redefined it
with the lower number in one .c file (unfortunately not the one with the
buffer declaration), with no explanation whatsoever... I'm removing that
and just assume the smaller value will be fine for everything.
BRANCH=veyron
BUG=None
TEST=Booted Pinky and Falco.
Change-Id: Idf80f44cbfb9617c56b64a5c88ebedf7fcb4ec71
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236976
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 3d3288041b6629b7623b9d58816e782e72836b81)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237202
Commit 54229a7 (arm: Fix checkstack() to use correct stack size) didn't
quite hit the mark. Due to the crazy way our Kconfig includes work, It
accidentally set CONFIG_STACK_SIZE to 0 even on architectures that need
it.
This patch fixes the issue by moving everything back to a single entry
in src/Kconfig, making sure we end up with the intended numbers on all
architectures.
BRANCH=None
BUG=chrome-os-partner:34750
TEST=Built for Pinky, Urara, Falco and Ryu. Confirmed that the generated
.config contained CONFIG_STACK_SIZE=0x0 for the former two, and
CONFIG_STACK_SIZE=0x1000 for the latter.
Change-Id: Ib18561925aafe7c74e6c4f0b10b55000a785e144
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236753
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit c64b127e163f98162f3f7195b6ed09bd5a4b77c4)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237028
this change makes vb2_working_data struct point to the vboot work buffer by
the offset instead of by the absolute address, which can be different
depending on the context (e.g. subprocessor v.s. main cpu).
BUG=none
BRANCH=tot
TEST=booted veyron pinky
Change-Id: I4e4c12613304586b7395c5173cf08b8093f59521
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236583
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 93f8b1da2b2c81aa3a33892987a71e9e1e7a8eff)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237027
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It turns out that it's not uncommon for a SPI chip to be probed
multiple times in different parts of the code during the execution
of a stage.
The original intent was just to make sure we aren't using the same
chip driver for multiple instances of a chip, due to limitations
in the driver's design. We'll have a better solution for that
eventually, this just un-breaks things (and effectively reverts
5da9e0e).
BUG=chrome-os-partner:34750
BRANCH=none
TEST=none
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Ie5c6e7f062a2f7c5361aebf5a4ab62a385739f65
Reviewed-on: https://chromium-review.googlesource.com/236673
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 0438927fa2469311b20e032377275100eee6e3a6)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237026
Due to a missing i2c_init(), we were actually running our TPM with
default divisors at 660KHz. Oops.
While it's commendable that both the TPM and our controller seem to have
been running fine all this time at more than 1.5 times the maximum
frequency they support, we should probably still get that fixed.
Also sync Speedy back up to the other Veyron boards since it seems to
have missed a recent SDMMC patch.
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I43e6b5fe02aca605a5b243c5b876bd44b90b2bf9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/236580
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit f2bd7c8579cd90d2f800c777c1981557d81a9b49)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237025
The way we use the SPI API does not allow for multiple chips to be
used simultaneously. This adds a dumb check to see if the chip has
already been probed/initialized, which should only happen once given
the current assumptions.
If we want to support multiple chips simultaneously, we should
further re-factor these chip drivers to be malloc()-friendly in
early stages (Julius suggested suggested implementing a mini-heap).
BUG=none
BRANCH=none
TEST=none (current ToT is broken)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I27ccbd5d94e00970f3a07c6383ccdce14a09cb60
Reviewed-on: https://chromium-review.googlesource.com/236080
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 5da9e0eceb50b99fa9aba6f597dafcab1965486c)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237024
This switches all the rk3288 platforms to use the common CBFS wrapper
instead of implementing its own CBFS media driver. It also happens
that veyron_* platforms use Gigadevice SPI flash (at least for now).
As we use more SPI-related stuff, for example eventlog and vboot data in
Brain's case, we will need to use more of the SPI API anyway. This
prevents us from having to duplicate pieces of it for rk3288.
BUG=none
BRANCH=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Id307bd5fb6cc8f79411d8c66e1370e80c58d017b
Reviewed-on: https://chromium-review.googlesource.com/235882
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 2d6df2fe6d78bc8eee8689019b9aaf29c82b6b30)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237023
This allows us to use the driver before ramstage.
BRANCH=none
BUG=none
TEST=built and booted on Pinky
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0ce901331e401274254b8889484ffb41359119fa
Reviewed-on: https://chromium-review.googlesource.com/235864
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit cd57587dab74de509d5c50cfc1ad337d765af6c8)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237022
