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>
This code that stores the initial timestamp is not being used,
instead the timestamp is passed to romstage_main().
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: I0e0fa1ba74ab93d4454fdfa12208e712d2ae913c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234402
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
When turning up the CPU frequency set it to turbo if that is
a possibility. Also only set the frequency on the boot CPU
since that is all we need it on, this will allow the 1-core
turbo ratio.
BUG=chrome-os-partner:28234
BRANCH=samus,auron
TEST=build and boot on samus
Change-Id: Ib5ad746767ee0a56bc7e59de679a9342f053c0e5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to avoid a 300ms timeout waiting for mbp_cleared flag
to be set there is a new flow for the ME10 1.5MB firwmare that
we can follow which will save significant boot time.
This requires sending new commands that do not generate an ACK
message, and ensuring an HMRFPO LOCK message is sent.
In addition now that the delay is removed clean up the ME path
to do the work in init() step and add a final() step that does
the disabling of the PCI device.
BUG=chrome-os-partner:30637,chrome-os-partner:34134
BRANCH=samus,auron
TEST=build and boot on samus, measure ~300ms speedup in boot time
Change-Id: I753087ecd65f6ebed9f812318a359f893e01da9f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234400
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234063
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We have known for a while that the old x86 model of calling init_timer()
in ramstage doesn't make sense on other archs (and is questionable in
general), and finally removed it with CL:219719. However, now timer
initialization is completely buried in the platform code, and it's hard
to ensure it is done in time to set up timestamps. For three out of four
non-x86 SoC vendors we have brought up for now, the timers need some
kind of SoC-specific initialization.
This patch reintroduces init_timer() as a weak function that can be
overridden by platform code. The call in ramstage is restricted to x86
(and should probably eventually be removed from there as well), and
other archs should call them at the earliest reasonable point in their
bootblock. (Only changing arm for now since arm64 and mips bootblocks
are still in very early state and should sync up to features in arm once
their requirements are better understood.) This allows us to move
timestamp_early_init() into arch code, so that we can rely on timestamps
being available at a well-defined point and initialize our base value as
early as possible. (Platforms who know that their timers start at zero
can still safely call timestamp_early_init(0) again from platform code.)
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Storm, compiled Daisy and Pit.
Change-Id: Iece1614b7442d4fa9ca981010e1c8497bdea308d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234062
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some boards spread their timer implementation out in multiple files with
one function each for no discernable reason. Let's clean that up to make
things a little simpler to find.
BRANCH=None
BUG=None
TEST=Booted Pinky, compiled Daisy and Pit.
Change-Id: I43d29cd1b4a1d89cfd40f6cba5ca99ada3b00f82
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234061
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ramstage is loaded from romstage, so the LZMA scratchpad buffer used
to decompress it is part of the romstage BSS in SRAM. On RK3288, SRAM
cannot be cached which makes the decompression so slow that it's faster
to just load an uncompressed image from SPI. Disable ramstage
compression on this SoC to account for that.
Since Kconfig is weird and we cannot disable an option that is enabled
by default with 'select', we need to rearrange menu groups so that
'mainboard' and 'chipset' come before 'General setup', which allows the
subdirectory Kconfig files sourced by them to override the generic
defaults specified later.
BRANCH=None
BUG=None
TEST=Built for Pinky and Falco, confirmed that the former didn't have
COMPRESS_RAMSTAGE in its .config and the latter still did. Measured a
speed-up of about 35ms on Pinky. (For some weird reason, the
decompression of the payload also takes way longer than on other
platforms, although not as long as the ramstage. I have no explanation
for that and can't really think of a good way to figure it out... maybe
the Cortex-A12 is just terrible at some operation that LZMA uses a lot?)
Change-Id: I9f67f7537696ec09496483b16b59a8b73f4cb11b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/234192
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch doubles the ACLK peripheral clock for the PD_BUS power domain
to 297MHz, which is the closest to the maximum of 300MHz we can reach by
dividing GPLL. This frequency directly translates into SRAM speed, so
maximizing it has a huge impact on boot speed (especially with the lack
of SRAM caching).
BUG=chrome-os-partner:32987
TEST=Booted Veyron_Pinky. Hacked timestamps into vboot and confirmed
that the (visibly) long signature verification times are nearly halved.
Change-Id: I3f19eaa3d97dcc6235d820c71eb5edf2ae87d647
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/224524
Trybot-Ready: Doug Anderson <dianders@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This configures I2S1 and the codec MCLK muxes to pass the PCM
audio data to the RT5677 codec. Once depthcharge RT5677 codec
driver changes are in, audio 'beeps' should be heard on boot
(Ctrl-U / devmode/recmode).
BUG=chrome-os-partner:32582
BRANCH=none
TEST=Built and booted Ryu/A44.
Change-Id: Ib071bcb41fba8f6d628a386ed233ec84a54b0323
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233945
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With this change, audio 'beeps' are heard on boot if Ctrl-U is
pressed, or devmode/recmode is entered. I also tested via an
explicit call to VbExBeep in the kernel boot path. Note that
a couple of Rush CLs for depthcharge are needed for audio, too.
BUG=chrome-os-partner:32582
BRANCH=none
TEST=as above. Built and booted Rush/Norrin64.
Change-Id: Ia37f077569afd806ce6574c4c58813fd7aca1644
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233671
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
add the samsung-4GB and hynix-4GB lpddr inf file,
and use ram_id 1000 correspond to samsung-4GB lpddr
use ram_id 1001 correspond to hynix-4GB lpddr
BUG=chrome-os-partner:33269
TEST=Boot veyron_speedy normal
BRANCH=None
Change-Id: I55b6968c642df8c1f579e518232ab5d278e7e12f
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/233859
Reviewed-by: Julius Werner <jwerner@chromium.org>
Data toggle should be running like 0, 1, 0, 1, ...
In the failed case (where a low-speed USB keyboard or km232 device
is installed), data toggle will be running as 0, 1, 0, 1, ..., 1, 1.
Therefore causing Halted or Transaction Error bit to be set in qTD
Status field.
BUG=None
BRANCH=None
TEST=Tested on nyan_kitty platform, firmware-kitty-5771.61.B branch.
Attached USB keyboard or km232 device to root-hub port (same side as
SD card slot).
Made sure no transaction error after doing interrupt transfer.
Change-Id: Ic2c0f95cff2ae6e314967b0b82231a962255f1a7
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/233857
Reviewed-by: Julius Werner <jwerner@chromium.org>
After DDR PHY reset de-asserted, DLL automatically starts to
lock, and the lock time is maximum 5.12us. The output clock of
DLL supplies the clocks of DDR controller and PHY digital logic.
So before DLL lock, the clocks of DDR controller and PHY digital
logic are indeterminate. When programming DDR in the period of
DLL unlock, the programming maybe unstable because of the
indeterminate clocks. So we need wait for at least 5.12us after
de-asserting reset, then start to program DDR registers.
Add some redundancy, the waiting time hopes to achieve 10us.
BUG=chrome-os-partner:33148
TEST=I'm using the following command line test ok(15000 cycles).
"while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off;
do : ; done"
BRANCH=None
Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0
Signed-off-by: DaiLunXue <dlx@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/232894
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com>
Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com>
Essentially a copy of veyron_jerry for now
BUG=chrome-os-partner:33269
TEST=emerge-veyron_speedy coreboot
BRANCH=None
Change-Id: Ife457db4fd67fe69bcd4082694b3372eccfb304b
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/233822
Reviewed-by: Julius Werner <jwerner@chromium.org>
