The SPI controller operates on packets which can be variable
length up to 32-bit packets. It also has the ability to be
put in packed or unpacked mode w.r.t each packet. i.e. does
a single fifo register hold >= 1 packet. The current programming
uses 8-bit packets in unpacked mode which means 4 fifo slots
are used for a 32-bit DMA transfter. As the AHB can only operate
on a minimum of 32-bit bursts the triggers need to be programmed
correctly so that there is room for a full 32-bit DMA transaction.
Previously faster SPI clocks just made things magically work.
BUG=chrome-os-partner:30779
BRANCH=None
TEST=Built and booted through coreboot with 20MHz SPI clock.
Change-Id: I3f1cd4dddcea9514327b2363ed450a527db7e1fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208862
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The Trust Zone carveout registers are only accessible using
a secure access mode. The AVP runs as non-secure all the time.
In EL3 the CPU is in secure mode, but when the MMU is enabled
the page tables dictate if accesses to certain regions are
secure or not. However, ramstage is currently being loaded
into non-secure memory and the page tables will live in
non-secure memory as well. Therefore, handle all these
cases by providing global state which mirrors the TZ
register.
BUG=chrome-os-partner:30782
BRANCH=None
TEST=Built and ran through ramstage with the MMU enabled
Resources are read and set accordingly.
Change-Id: Ib76b2641497a29ef2adb75934b2df55ecf0b3e78
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/209061
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Add support for mmu initialization and enabling caches. mmu_operations provides
functions to add mmap_regions using memrange library and then calls mmu_init for
armv8.
BUG=chrome-os-partner:30688
BRANCH=None
TEST=Compiles rush successfully and boots until depthcharge load. Goes past
all the earlier alignment errors.
Change-Id: I57c2be80427fa77239093c79ece73e31fd319239
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/208762
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
1) Add check for zero size in memrange.
2) Add public memrange_init_empty function to allow initializing only the
memrange structure without filling in device resources
BUG=None
BRANCH=None
TEST=Compiles and runs succesfully for rush MMU memranges.
Change-Id: I8e4d864cbc9a770cd208f8a9f83f509dc7ace894
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/208957
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Add support for initializing and enabling mmu for armv8. Using 64KiB granule and
33 bits per VA, thus total VA address space is 6GiB. PA Range is 64GiB. Makes
use of memrange library to get a list of all the mmap regions from the SoC to
initialize XLAT table.
Currently, all calculations in mmu.h are based on the assumptions that max 33
bits are used in VA and granule size is 64KiB. Changes in these assumptions will
have to reflect in the dependent calculations as well.
BUG=chrome-os-partner:30688
BRANCH=None
TEST=Compiles rush successfully and boots until "payload not found". Goes past
all the earlier alignment errors.
Change-Id: Iac1df15f0b81dcf64484a56b94f51357bcd67cc2
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/208761
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
This must be committed at the same time as the corresponding
depthcharge change which updates the fmap.
BUG=chrome-os-partner:30079
BRANCH=none
TEST=Build samus firmware.
dump_fmap -h /build/samus/firmware/image.bin shows PD_MAIN_A and
PD_MAIN_B sections.
Boot samus. 'crossystem mainfw_act' -> A
As root, 'crossystem fwb_tries=1'
Reboot samus. 'crossystem mainfw_act' -> B
CQ-DEPEND=CL:208984,CL:*169850,CL:208989
Change-Id: Ibccec8b82ba22c61248a79023f42b92e4763403e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208899
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Due to some projects don't have the correct settings in devicetree.cb
so put this change in case those projects without are setting in devicetree.cb
BUG=chrome-os-partner:30690
BRANCH=none
TEST=emerge-rambi coreboot without problem
checked the USBPHY_COMPBG is configured properly
even there is no setting in devicetree
Change-Id: Iaf8155497c41f10c81d1faa7bb0e3452a7cedcc6
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/209051
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Other default slams should be added later to the init table
once we know what the kernel touches. But for now, only VDD_CPU
is needed.
Also slipped in a minor name change in mainboard.c
BRANCH=none
BUG=none
TEST=none, no HW here for me to test on yet
Change-Id: Ifbe86192449ed0466085808a0a12a15a7b6a1795
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208385
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With this memory resource, the payload loading code should be
able to create a bounce buffer and load the payload successfully.
Adapted from tegra124 soc.c
BUG=None
BRANCH=None
TEST=Built and booted to ramstage on rush.
Change-Id: I2e336ce93c1b0236104e63d3785f0e3d7d76bb01
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208121
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
USBPHY_COMPBG needs to be configured by project
BUG=chrome-os-partner:30690
BRANCH=none
TEST=emerge-rambi coreboot without problem
checked the USBPHY_COMPBG is configured properly
CQ-DEPEND=CL:208557
Change-Id: I8f2714644e1ef5d790d7ef1f574ebb998abbdac6
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/208731
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Once LPDDR3 init is supported in the ryu romstage, this can
be reverted. Note that this 528MHz BCT has been pre-qualed
by NVIDIA AE's, but will be updated as more tuning is done.
BUG=none
BRANCH=none
TEST=Builds, BCT is in binary, but I have no HW here to test on
Change-Id: I315a9a5d56290bb5f51863b15053d2171db7b1e4
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/208384
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The CCSIDR_EL1 register has cache attribute information
for a given cache selection in CSSELR_EL1. However, the
cache isn't being selected before reading CCSIDR_EL1.
Instead use CTR_EL0 which better fits with the semantics
of dcache_line_bytes(). CTR_EL0 has the minimum data cache
line size of all caches in the system encoded in 19:16 encoded
as lg(line size in words).
BUG=None
TEST=Built.
Change-Id: I2cbf888a93031736e668918de928c3a99c26bedd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208720
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
USBPHY_COMPBG needs to be configured by project
BUG=chrome-os-partner:30690
BRANCH=none
TEST=emerge-rambi coreboot without problem
checked the USBPHY_COMPBG is configured properly
Change-Id: I05eee384d94cf5deeec14418bd78816df0b26a92
Signed-off-by: Kane Chen <kane.chen@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/208557
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
This patch removes a chunk of romstage code from Tegra and all Nyan
boards that was supposed to enable some LCD power rails early, but never
really worked. The dev_find_slot() function can only find PCI devices,
which the CPU cluster is not. Since we're done with Nyan-RO and the
ramstage display code is fine as it is, there is no point in trying to
fix this... but we should remove it from ToT lest someone uses it as a
blueprint to add more dead code to future boards.
BRANCH=None
BUG=None
TEST=None
Change-Id: I6eee256873299429d4e3934fe7d454120390f34d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207720
Reviewed-by: David Hendricks <dhendrix@chromium.org>
The address map code was originally assuming all carveouts would
be packed together in the upper end of the physical memory
address space. However, the trust zone carveout is always in the
32-bit address space. Therefore, one needs to query memory ranges
by above and below 4GiB with the assumption of carveouts being
packed at the top of *each* resulting range.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran through coreboot on rush.
Change-Id: Iab134a049f3726f1ec41fc6626b1a6683d9f5362
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208101
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The default CBFS size configuration setting is incorrect in case of
Qualcomm SOC targets, as the coreboot blob is much smaller than the
actual bootprom. Note that this size also must match the board fmap
defined in the appropriate depthcharge board directory.
BUG=chromium:394068
TEST=manual
. previously failing to boot coreboot image does not fail to load
depthcharge anymore.
Change-Id: I1b178970b1deee05705490542e4a0c57500379dd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208146
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is a minor tweak to make the console output cleaner
and more consistent with all the reporting of platform data.
BUG=chrome-os-partner:30586
BRANCH=None
TEST=build and boot on samus
Change-Id: Iea7b48f14795bd6061615a68ca25ff52f84abc5a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208213
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In order to ensure that we meet timing requirements for the SSD
power sequencing delay bringing the SSD out of reset until after
memory training.
BUG=chrome-os-partner:29914
BRANCH=None
TEST=build and boot on samus
Change-Id: I807e3d3698255287c3fe7219f44e8ec9a0985df1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208155
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- disable_self_refresh: parameter to disable memory self refresh
during training. This can be used to work around power issues
seen with lpddr3.
- disable_saved_data: parameter to disable the use of the cached
MRC data. This can be used to work around lpddr3 training replay
issues.
BUG=chrome-os-partner:29787,chrome-os-partner:29117
BRANCH=None
CQ-DEPEND=CL:*169275
TEST=build and boot on samus
Change-Id: I051bfbfa0d171ad9b2503cb9a30990b13b4c0cb2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208153
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Turn on keyboard backlight early in boot (not resume) path
as a sign of life for the system
- Add ACPI device for keyboard backlight so the kernel can find
and make use of it
BUG=chrome-os-partner:30586
BRANCH=None
TEST=build and boot on samus
Change-Id: Iecaef0ec5c814774e19d7c4a14cb92dc236cfee3
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208152
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change will read the chipset power state data earlier in boot
and then store a pointer to the data in romstage params for use in
other phases of romstage.
BUG=chrome-os-partner:30586
BRANCH=None
TEST=build and boot on samus
Change-Id: I5fd193b56f34fa3cfe3ad2eb8b915737e6807af4
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208151
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Provide a default Trust Zone region size of 1MiB, and
correctly account for it in the AVP and the arm64 cores.
The different paths between the arm64 cores and the AVP
is because the AVP cannot access the Trust Zone region
registers. Therefore the AVP needs to account for the
Trust Zone region.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran. Noted Trust Zone region being accounted for.
Change-Id: Ie0f117ec7a5ff8519c39778d3cdf88c3eee57ea5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208062
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Some of the SoC's need an early hook to configure
certain registers. One example of this is on t132
where ramstage is the first thing being ran on the
arm64 core and it is the only entity that can configure
certain registers required for the rest of ramstage.
Therefore, provide the opportunity for the SoC to
implement such requirements.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and ran through coreboot.
Change-Id: Ib352f3788872f888581b398c9b394b7c4e54b02a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208061
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
In order to make sharing of the location of MTS microcode easier
provide a Kconfig option that is the path to the files.
BUG=chrome-os-partner:30569
BRANCH=None
TEST=Built rush coreboot.
Change-Id: I36775d0018fc8591d5e77c2943e28a51381713f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207839
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This is a clone of rush for the time being. All the incompatible
bits can be moved later.
BUG=chrome-os-partner:30569
BRANCH=None
TEST=Built coreboot for rush_ryu board
Change-Id: Iae56d016d0c328d83242b95f307fefaa8c68deec
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207838
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The TrustZone carveout needs to be taken into account when
determining the memory layout. However, things are complicated
by the fact that TZ carveout registers are not accessible by
the AVP.
BUG=chrome-os-partner:30572
BRANCH=None
TEST=Built and booted to end of ramstage. Noted that denver cores
can read TZ registers while AVP doesn't bother.
Change-Id: I2d2d27e33a334bf639af52260b99d8363906c646
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207835
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Since RES1 and RES0 bits are marked as SBOP(Should-Be-One-or-Preserved) and
SBZP(Should-Be-Zero-or-Preserved) respectively, resetting the SCTLR and SCR
registers should be done with proper bitmask.
BUG=None
BRANCH=None
TEST=Compiles successfully and verified that the RES bits are preserved across
register writes.
Change-Id: I5094ba7e51e8ea6f7d7612ba4d11b10dcbdb1607
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/207815
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
The carveout regions need to be taken into account when
calculating addressable memory because those regions aren't
accesible from the main cpu. The additional exposed functions
are to accommodate adding resources during ramstage resource
reading. The TZ (trust zone) region is empty for now until
more documentation is provided on determining its location.
BUG=None
TEST=Built and booted through attempting payload loading.
MTS carveout is taken into account programatically.
Change-Id: I3301b2a12680ad79047198ada41f32eb1b7fa68b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207585
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
With BOARD_VARIANT_AP148 configuration option enabled the image will
be built for 512MB DRAM instead of 1024MB and the
mainboard_part_number field in the lb_mainboard entry will be set to
"AP148" instead of "Storm".
BUG=chrome-os-partner:30440
TEST=manual
. built and booted both AP148 and proto0 all the way to reading the
kernel
. verified that the config file includes correct part number and
memory size
. verified proper machine IDs reportted when starting the kernel
Change-Id: Ie609544a460fc991e66e8b95e8d7a3ed5e845f7b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207427
Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Enabled CBMEM support for t132 platforms. Some of the existing
code is moved around to avoid dependencies in the other stages
that need it.
BUG=None
BRANCH=None
TEST=Built and booted a rush with cbmem support.
Change-Id: I78a31b58ab9cc01a7b5d1fffdb6c8ae0c446c7dd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207163
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
In order to not have to guard cbmem console calls provide
empty implementations.
BUG=None
BRANCH=None
TEST=Able to build with call to cbmemc_reinit() without having
CONSOLE_CBMEM enabled.
Change-Id: Ib26f2d66f2a431fe53c7b9fc2dd03fc7168d8e75
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207580
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This patch is to perform software triggered RAM re-repair in
the warm boot path.
BUG=chrome-os-partner:30430
BRANCH=nyan
TEST=run suspend_stress_test on nyan.
Signed-off-by: Yen Lin<yelin@nvidia.com>
Change-Id: I540f8afbffa323d1e378cb6ba6a20be4afd08339
Reviewed-on: https://chromium-review.googlesource.com/207422
Tested-by: Yen Lin <yelin@nvidia.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Yen Lin <yelin@nvidia.com>
This patch is to perform software triggered RAM re-repair in
the cold boot path.
BUG=chrome-os-partner:30430
BRANCH=nyan
TEST=run cold reboot test on nyan.
Signed-off-by: Yen Lin <yelin@nvidia.com>
Change-Id: I87869431e80e7bc66948a7f67f35e5b907993765
Reviewed-on: https://chromium-review.googlesource.com/207362
Tested-by: Yen Lin <yelin@nvidia.com>
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Yen Lin <yelin@nvidia.com>
To align with arm use the RAMSTAGE_BASE Kconfig option
for start of ramstage. Also, use 16-byte alignment for the
start and end of the secions. 4 bytes were previously used, but
it definitely seems more appropriate to at least have the heap
handing out 16-byte aligned pointers.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Built and booted through attempting to load payload
Change-Id: I39329055696ae21a9ed1d9a64769981ab4dcdddd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207432
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Inconsistent progress was observed running ramstage.
It was determined that the hand-coded assembly functions
were causing issues. Some of the comments seems suspect about
the hardware taking care of alignment. The prudent thing to do
is to use the C ones. Optimization can come later after maturity.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Built and booted to attempting to payload
Change-Id: I4137adf9b36b638ed207e4efd57adaac64c6a6c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207431
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The startup sequence for cpu0 is implemented while also
providing a trampoline for transitioning to 64-bit mode because
the denver cores on t132 come out of cold reset in 32-bit mode.
Mainboard callbacks are provided for providing the board-specific
bits of the bringup sequence.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Built and booted through ramstage.
Change-Id: I50755fb6b06db994af8667969d8493f214a70aae
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207263
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Ramstage needs an assembly entry point for setting up
the initial state of the CPU. Therefore, a function is
provided, arm64_el3_startup(), that bootstraps the state
of the processor, initializes the stack pointer, and
branches to a defined entry symbol. To make this work
without adding too much preprocessor macro conditions
provide _stack and _estack for all the stages.
Currently the entry point after initialization is 'main',
however it can be changed/extended to do more work such
as seeding the stack contents with tombstones, etc.
It should be noted that romstage and bootblock weren't
tested. Only ramstage is known to work.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Brought up 64-bit ramstage on rush.
Change-Id: I1f07d5b6656e13e6667b038cdc1f4be8843d1960
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207262
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The driver structures live in special sections which have no
direct reference to the symbols. Therefore, when garbage
collecting sections in the liner the drivers are tossed out
resulting in no drivers being linked into ramstage. Fix this
by adding the KEEP() directive to those special sections.
BUG=chrome-os-partner:29923
BRANCH=None
TEST=Built and noted console starts working in ramstage.
Change-Id: Iaa0fd428bf975c82d4e6b0e75a17e6fd231fbaa9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/207261
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
1) In order to avoid stack from overflowing during ramstage decompression,
initialize stack right at the beginning of romstage.
2) Declare different Kconfig options for stack at each stage.
3) Provide a macro that does stack seeding if required and calls appropriate
function.
BUG=None
BRANCH=None
TEST=Compiles and runs successfully on rush.
Change-Id: I55d6ce59ea91affba3e86d68406921497c83fb52
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/206880
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
vboot2 abtracts tpm storage as some 'secure' space. Thus, it's firmware's
responsibility to handle vboot specific operations with tpm. This CL just copies
related files from vboot_reference so that we can see how code was modified in
the next CL. Note rollback_index.c/h were renamed to antirollback.c/h.
TEST=none
BUG=none
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Change-Id: I1792a622058f70a8fcd3c4037547539ad2870420
Reviewed-on: https://chromium-review.googlesource.com/206462
Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Based on TRM, cpu clock enabling and reset vector setting should
all be done properly before ungating cpu power partition. Otherwise,
with current code, a race condition could occur where cpu starts but
reset vector has not been set.
BUG=chrome-os-partner:30064
BRANCH=none
TEST=run nyan_big reboot test. No issue is experienced.
Signed-off-by: Jimmy Zhang <jimmzhang@nvidia.com>
Change-Id: I571e128693bb2763ee673bd183b8cf60921dc475
Reviewed-on: https://chromium-review.googlesource.com/206682
Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
Doing reset while VBERROR_TPM_REBOOT_REQUIRED occured.
BUG=chromium:389568
TEST=Manual force VBERROR_TPM_REBOOT_REQUIRED returned from VbInit()
and system will reboot.
Change-Id: I9d7c4b3a380a931a728f792b4013b3b9bf65dfae
Signed-off-by: Kevin Cheng <kevin.cheng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/206337
Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 32728dd9fc43a95d6f763a85f9cc7a660a66b175)
Reviewed-on: https://chromium-review.googlesource.com/206948
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
In the original fix for the 'Lost arb' we were seeing on
Nyan* during reboot stress testing, I had the name of
BC_TERMINATE's bit setting wrong. Fix this to use the
IMMEDIATE (1) setting. The setting didn't change, just
the name. According to Julius this is the optimal
setting for bus clear in this instance. Also widened
the SCLK_THRESHOLD mask to 8 bits as per spec.
BUG=chrome-os-partner:28323
BRANCH=nyan
TEST=Tested on nyan. Built for nyan and nyan_big.
Change-Id: I19588690924b83431d9f4d3d2eb64f4947849a33
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/206409
Reviewed-by: Julius Werner <jwerner@chromium.org>
We assume that the clock rate of SCLK/HCLK/PCLK was 408MHz which was same
as PLLP. But that is incorrect, BootROM had switched it to pllp_out2
with the rate 204MHz. So actually the warm boot procedure was running at
the condition of SCLK=HCLK=PCLK=pllp_out2 with the rate 204MHz.
And the CPU complex power on sequences were different with what we used
in kernel and Coreboot. Fix up the sequence as below.
* enable CPU clk
* power on CPU complex
* remove I/O clamps
* remove CPU reset
Update the time of the CPU complex power on function for record.
* power_on_partition(PARTID_CRAIL): 528 uSec
* power_on_partition(PARTID_CONC): 0 uSec
* power_on_partition(PARTID_CE0): 4 uSec
Finally, removing the redundant routine of a flow controller event with
(20 | MSEC_EVENT | MODE_STOP).
BUG=chrome-os-partner:29394
BRANCH=none
TEST=manually test LP0 with lid switch quickly and make sure the last
write to restore register successfully
Change-Id: Ifb99ed239eb5572351b8d896535a7c451c17b8f8
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/205901
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Commit-Queue: Jimmy Zhang <jimmzhang@nvidia.com>
