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
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>
this allows each board to decide what to do after firmware verification is
done. some board needs to return back to the previous stage and let the
previous stage kick off the verified stage.
this also makes it more visible what is going to happen in the verstage since
stage_exit now resides in main().
BUG=none
BRANCH=tot
TEST=booted cosmos dev board. booted blaze in normal and recovery mode.
built for all current boards.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I3cb466cedf2a9c2b0d48fc4b0f73f76d0714c0c7
Reviewed-on: https://chromium-review.googlesource.com/232517
The gpio access code has been moved to a separate file to match other
platforms. Accessor functions are added to read different switches
state. They will be read by verstage, when it is enabled, and by
ramstage, for passing the values to depthcharge.
It is unfortunate that the gpio values are not being cached and can
change by the time CBMEM table is filled, but we have to live with
that for now.
BUG=chrome-os-partner:33756,chrome-os-partner:34161
BRANCH=storm
TEST=none yet.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I940b54cd3cf046b94d57d59d370e634a70a8bbeb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/229426
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This device is not used in current builds and should be
disabled to help EMI.
BUG=chrome-os-partner:34117
BRANCH=samus
TEST=build and boot on samus
Change-Id: I62541e343dcaa3cd31c81b73d8c27a5efcf3ad60
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234403
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
