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>
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>
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
checkstack() runs at the end of ramstage to warn about stack overflows,
and it assumes that CONFIG_STACK_SIZE is always the size of the stack to
check. This is only true for systems that bring up multiprocessing in
ramstage and assign a separate stack for each core, like x86 and ARM64.
Other architectures like ARM and MIPS (for now) don't touch secondary
CPUs at all and currently don't look like they'll ever need to, so they
generally stay on the same (SRAM-based) stack they have been on since
their bootblock.
This patch tries to model that difference by making these architectures
explicitly set CONFIG_STACK_SIZE to zero, and using that as a cue to
assume the whole (_estack - _stack) area in checkstack() instead. Also
adds a BUG() to the stack overflow check, since that is currently just
as non-fatal as the BIOS_ERR message (despite the incorrect "SYSTEM
HALTED" output) but a little more easy to spot. Such a serious failure
should not drown out in all the normal random pieces of lower case boot
spam (also, I was intending to eventually have a look at assert() and
BUG() to hopefully make them a little more useful/noticeable if I ever
find the time for it).
BRANCH=None
BUG=None
TEST=Booted Pinky, noticed it no longer complains about stack overflows.
Built Falco, Ryu and Urara.
Change-Id: I49f70bb7ad192bd1c48e077802085dc5ecbfd58b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235894
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 54229a725e8907b84a105c04ecea33b8f9b91dd4)
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/237021
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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: I90d9eab5b5d3af7a2e4b836a9c7b735b7c1c48e6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235870
Reviewed-by: David Hendricks <dhendrix@chromium.org>
BUG=None
TEST=emerge veyron_mighty and Boot the mighty board
BRANCH=None
Change-Id: I3fcdc837e8d7e62c145850f549662d8260aa1120
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234714
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=None
TEST=emerge veyron_jerry and Boot the jerry board
BRANCH=None
Change-Id: I6eb0900516bcd95159c472749c54d356448d2344
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234713
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: I06242ade0cabbba56b16b3832a1b4b09bec6f06b
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234712
Reviewed-by: Julius Werner <jwerner@chromium.org>
we use the devicetree to pass the backlight control gpio before,
but if there have different board version, and use different
io to control backlight, it will hard to distinguish it. so we
move the backlight control to mainboard, and we can through board_id
to distinguish the backlight control.
BUG=None
TEST=emerge veyron_pinky and Boot the pinky board
BRANCH=None
Change-Id: I1ec8e04f4982c3a8c7e31d8dc2c75311b7199ffc
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/234711
Reviewed-by: Julius Werner <jwerner@chromium.org>
Display configuration is board specific. The change here is preparing
for supporting other than dsi interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: I494a04f7d6c0dbad2d472f4c2cd0aabfb23b8c97
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/234271
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
dc supporting functions can be used for other than dsi display
interfaces. This change is preparing for supporting sor display
interface.
BUG=chrome-os-partner:34336
BRANCH=none
TEST=build ryu and test dev/rec mode, also build rush ok
Change-Id: Id14cbd89457cb91c23526927a432f4eb7cc6291b
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/234270
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- These should be 64bit values so when they try to return -1
it is interpreted properly by the kernel.
- The GPE value needs to be reset at the start so it does not
return stale data from a previous resume.
- If a GPE register is zero the value should only be updated
if it has not yet found a set bit.
BUG=chrome-os-partner:34532
BRANCH=samus,auron
TEST=build and boot on samus, suspend/resume with various
wake sources and ensure the reported _SWS values are correct
in every case.
Change-Id: Ic6897f20ad2f321f3566694c032b75a3db120556
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/235012
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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: I2581bde84f0445c15896060544e9acb60de91c8c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/231734
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Define the signature for the FSP HOB list pointer and add it to the
table parser.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. Test successful if the code attempts to load the payload
Change-Id: I3e340289b0ba560147d9766583a82b783adb1605
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/234525
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Call FspNotify to finish the platform initialization. Attempts to
load the payload.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. If running on a non-samus board, in
src/mainboard/google/samus/Kconfig:
a. Comment out select EC_GOOGLE_CHROMEEC
b. Comment out select EC_SOFTWARE_SYNC
4. If running on a non-samus board, in
src/mainboard/google/samus/spd/spd.c comment out the check for
valid SPD data at the end of the file
5. Build and run on Samus
6. Test successful if the code attempts to load the payload
Change-Id: I007bd5481e532e14dca3f158b8eb1d8cb4dc3f47
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232874
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
With introduction of uber-sbl SRAM usage pattern is changing, this
introduces the new memory layout.
This patch overlays DDR initialization code with uber-sbl, as uber-sbl
goes out of scope as soon as bootblock starts.
A 4K block at offset 0x3f000 added in the comments, this is a shared
structure used by different QCA modules.
This suggested layout is not final, but will allow to move closer to
the production image.
BRANCH=storm
BUG=chrome-os-partner:34161
TEST=with other patches applied Storm boots all the way to rombase and
initializes DRAM.
Change-Id: I927f6ffc524fc8f0effd7b91d3f5d1e8d6be1530
Signed-off-by: Deepa Dinamani <deepad@codeaurora.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229023
16K of BSS scratchpad buffer is no pocket change for some platforms that
really need to count every kilobyte in their SRAM stages. This patch
makes sure we don't compile LZMA code into the romstage if we don't need
it because the ramstage is not compressed anyway.
BRANCH=None
BUG=None
TEST=Booted Pinky and Blaze. Confirmed that romstage memsz on Pinky is
way smaller than before.
Change-Id: Icf04971b8ddafa76052135cd0e44977d44d69486
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234539
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support to call FspSiliconInit
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. After power on, POST code should be 0x35 if successful, hangs in
src/soc/intel/broadwell/romstage/romstage.c/romstage_after_car
Change-Id: I80363425df97bf1f1f9b9180f2fd4c625125d33e
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232383
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Add support to call FspTempRamExit
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. After power on, POST code should be 0x35 if successful, hangs in
src/soc/intel/broadwell/romstage/romstage.c/romstage_after_car
Change-Id: I512bfa8c3add8a16d945c5983873ee0286ec40d1
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/232500
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Repartition the RAM initialization code to share the setup and caching
support. Display the parameters for the MemoryInit call. Initialize
memory using the FSP binary. Upon return display the HOBs and memory
configuration before hanging displaying POST code 0x35.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. After power on, POST code should be 0x35 if successful, hangs in
src/soc/intel/broadwell/romstage/romstage.c/romstage_common
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Change-Id: I02e1ea422644da1f6285812dd36045a70e0f4324
Reviewed-on: https://chromium-review.googlesource.com/231285
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
S25FL116K family use the first 3 bytes in response to a regacy identification
command (9f) while previously supported models use the last 4 bytes. This change
defines identify functions to allow both types to be handled correctly.
BUG=none
BRANCH=tot
TEST=verified romstage is loaded on cosmos development board.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: Icdd2645e356652672c4482e7b805da1bc0f21e71
Reviewed-on: https://chromium-review.googlesource.com/234431
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The library timestamp module generates exactly the same error messages
in different situations, which does not help debugging.
Lets keep all messages different.
BRANCH=none
BUG=none
TEST=it still builds for storm
Change-Id: I0cbd4281f458de06e06fe58a02eafd1e96d7117d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234406
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
this is a preparation for porting these drivers to coreboot. the code will be modified by the following patches.
BUG=chrome-os-partner:33647
BRANCH=ToT
TEST=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I9f3428ef02d2ba15ae63c99b10fe0605dd595313
Reviewed-on: https://chromium-review.googlesource.com/231461
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
During execution, src/soc/intel/broadwell/romstage/fsp_1_1.inc calls
src/soc/intel/fsp/fsp_util.c/find_fsp, added in change list 229573,
to locate the FSP binary in CBFS. Determine the TempRamInit entry point
and call TempRamInit. After returning, fsp_1_1.inc calls into
src/soc/intel/broadwell/romstage/romstage.c/romstage_main.
BRANCH=none
BUG=None
TEST=Use the following steps to reproduce:
1. Get the private FSP parts: internal 187295
2. Copy configs/config.samus.fsp to configs/config.samus
3. Build and run on Samus
4. After power on, POST code should be 0x35 if successful, hangs in
src/soc/intel/broadwell/romstage/romstage.c/romstage_main
Change-Id: Id7d17b7b46e73a7b6b4dae6ee859016dab6e6d6f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/234140
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
this is required to do early firmware selection using vboot2. actual
implementation can be done later.
BUG=chrome-os-partner:33755
BRANCH=ToT
TEST=Booted storm.
Change-Id: Idd1a1de4991a19902ffe45f01be89d47f4413779
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229425
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
