Age | Commit message (Collapse) | Author |
|
Set XN bit of block upper attribute to device memory in mmu. CPU may
speculatively prefetch instructions from device memory, but the IO
subsystem of some implementation may not support this operation. Set
this attribute to device memory mmu entries can prevent CPU from
prefetching device memory.
BRANCH=none
BUG=none
TEST=build and booted to kernel on oak-rev3 with dcm enabled.
Change-Id: I52ac7d7c84220624aaf6a48d64b9110d7afeb293
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7b01a4157cb046a5e75ea7625060a602e7a63c3c
Original-Change-Id: Id535e990a23b6c89123b5a4e64d7ed21eebed607
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/302301
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11722
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
do_dcsw_op is coded as a label, it's possible that linker will place
do_dcsw_op on unaligned address. To avoid this situation, we declare
do_dcsw_op as a function. Also explicitly set the 2nd argument of
ENTRY_WITH_ALIGN(name, bits) to 2.
do_dcsw_op:
cbz x3, exit
c103d: b40003e3 cbz x3, c10b9 <exit>
mov x10, xzr
c1041: aa1f03ea mov x10, xzr
adr x14, dcsw_loop_table // compute inner loop address
BRANCH=none
BUG=none
TEST=build and check do_dcsw_op in elf file
Change-Id: Ieb5f4188d6126ac9f6ddb0bfcc67452f79de94ad
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 4ee26b76089fab82cf4fb9b21c9f15b29e57b453
Original-Change-Id: Id331e8ecab7ea8782e97c10b13e8810955747a51
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293660
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/11395
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Kconfigs symbols of type bool are always defined, and can be tested with
the IS_ENABLED() macro.
symbol type except string.
Change-Id: Ic4ba79f519ee2a53d39c10859bbfa9c32015b19d
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BUG=None
BRANCH=None
TEST=Compiles successfully, sp verified during exception
Change-Id: Idbeb93b1dbf163e2d86cd42369941ff98a3d2d9e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ca73b40f0248497143b6ab42bd0f5cc6cddf7713
Original-Change-Id: I38ee403200acb0e3d9015231c274568930b58987
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/283542
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10842
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BRANCH=none
BUG=none
TEST=Booted on Oak and confirmed the output cacheable/non-cacheable
string is correct.
Change-Id: I062c1cc384b8cb9d07038399b1bc7ef47d992103
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 45552f95b55cd9fc81817e4ff02c78e885377065
Original-Change-Id: Ie52066dbefd2f54d0746792b89f0b57767811adb
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273994
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/10390
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We have observed issues with enabling CONFIG_SMP and adding prints
before MMU is enabled on Tegra-based SoCs. This seems to be related
to the hardware assisted locks and the restrictions laid down by ARMv8
spec.
BUG=None
BRANCH=None
TEST=Boots to kernel prompt on smaug.
Change-Id: I29a52f5a972baf396c01faba3ae3e5ecd27563e9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f52ee4b5b2e9b7f54eee0d105cb7e17f9a7e1613
Original-Change-Id: I432895560f468903c7beef00e78b6d38275a619c
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272449
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10311
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current arm64 MMU interface is difficult to use in pre-RAM
environments. It is based on the memranges API which makes use of
malloc(), and early stages usually don't have a heap. It is also built
as a one-shot interface that requires all memory ranges to be laid out
beforehand, which is a problem when existing areas need to change (e.g.
after initializing DRAM).
The long-term goal of this patch is to completely switch to a
configure-as-you-go interface based on the mmu_config_range() function,
similar to what ARM32 does. As a first step this feature is added
side-by-side to the existing interface so that existing SoC
implementations continue to work and can be slowly ported over one by
one. Like the ARM32 version it does not garbage collect page tables that
become unused, so repeated mapping at different granularities will
exhaust the available table space (this is presumed to be a reasonable
limitation for a firmware environment and keeps the code much simpler).
Also do some cleanup, align comments between coreboot and libpayload for
easier diffing, and change all error cases to assert()s. Right now the
code just propagates error codes up the stack until it eventually
reaches a function that doesn't check them anymore. MMU configuration
errors (essentially just misaligned requests and running out of table
space) should always be compile-time programming errors, so failing hard
and fast seems like the best way to deal with them.
BRANCH=None
BUG=None
TEST=Compile-tested rush_ryu. Booted on Oak and hacked MMU init to use
mmu_config_range() insted of memranges. Confirmed that CRCs over all page
tables before and after the change are equal.
Change-Id: I93585b44a277c1d96d31ee9c3dd2522b5e10085b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f10fcba107aba1f3ea239471cb5a4f9239809539
Original-Change-Id: I6a2a11e3b94e6ae9e1553871f0cccd3b556b3e65
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/271991
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10304
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
|
|
Rename Kconfig options for secmon and spintable to be prefixed with
ARM64_ instead of ARCH_, which seems to be the standard throughout the
rest of coreboot (e.g. ARM_LPAE or X86_BOOTBLOCK_SIMPLE). I think this
provides a clearer separation between generic options that are selected
by the architecture (e.g. a hypothetical ARCH_HAS_FEATURE_X similar to
some of the MAINBOARD_HAS_... we have) and options that only make sense
in the context of a single architecture.
Change-Id: I38c2efab833f252adbb7b61ef0af60ab25b768b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5067e47bc03f04ad2dba044f022716e0fc62bb9e
Original-Change-Id: I1b2038acc0d054716a3c580ce97ea8e9a45abfa2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/270783
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10242
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Implement the cpu_suspend for the PSCI service in secmon.
BRANCH=none
BUG=chrome-os-partner:39620
TEST=test with CPU idle driver that invoke the cpu_suspend of PSCI
Change-Id: I4cdfab88bf36bf432fb33c56c1ea114b384528f8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 90b3ea3fcb21cb393e30a8359f0328054961f6d5
Original-Change-Id: Ieb76abc017b9c3e074cc018903cef72020306a8f
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/269115
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10171
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
arch_program_segment_loaded ensures that the program segment loaded is
synced back from the cache to PoC. dcache_flush_all on arm64 does not
guarantee PoC in case of MP systems. Thus, it is important to track
and sync back all the required segments using
arch_program_segment_loaded. Use this function in rmodules as well
instead of cache_sync_instructions which guarantees sync upto PoC.
BUG=chrome-os-partner:37546
BRANCH=None
TEST=Boots into depthcharge on foster
Change-Id: I64c2dd5e40ea59fa31f300174ca0d0aebcf8041d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 35ba0b882b86ff2c29ac766e1d65f403c8346247
Original-Change-Id: I964aa09f0cafdaab170606cd4b8f2e027698aee7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/260908
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10173
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
1. change mmu granule size from 64KB to 4KB
2. correct level 1 translation table creation logic
3. automatically calculate granule size related macros
BRANCH=none
BUG=none
TEST=boot to kernel on oak board
Change-Id: I9e99a3017033f6870b1735ac8faabb267c7be0a4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2f18c4d5d9902f2830db82720c5543af270a7e3c
Original-Change-Id: Ia27a414ab7578d70b00c36f9c063983397ba7927
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265603
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/10009
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
This patchs introduces level specific data cache maintenance operations
to cache_helpers.S. It's derived form ARM trusted firmware repository.
Please reference here.
https://github.com/ARM-software/arm-trusted-firmware/blob/master/
lib/aarch64/cache_helpers.S
BRANCH=none
BUG=none
TEST=boot on smaug/foster
Change-Id: Ib58a6d6f95eb51ce5d80749ff51d9d389b0d1343
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b3d1a16bd0089740f1f2257146c771783beece82
Original-Change-Id: Ifcd1dbcd868331107d0d47af73545a3a159fdff6
Original-Signed-off-by: Joseph Lo <josephl@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265826
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9979
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
Disable and enable GIC before switching off a CPU and after bringing
it up back respectively.
BUG=None
BRANCH=None
TEST=Compiles successfully and psci commands work for ryu.
Change-Id: Ib43af60e994e3d072e897a59595775d0b2dcef83
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d5271d731f0a569583c2b32ef6726dadbfa846d3
Original-Change-Id: I672945fcb0ff416008a1aad5ed625cfa91bb9cbd
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265623
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9926
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
PSCI_CPU_OFF is SMC32 call, there is not SMC64 version. Register SMC32
and SMC64 types of PSCI calls.
BUG=None
BRANCH=None
TEST=Compiles successfully and CPU off works fine with PSCI command.
Change-Id: I8df2eabfff52924625426b3607720c5219d38b58
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9228c07f9d9a4dd6325afb1f64b41b9b8711b146
Original-Change-Id: I2f387291893c1acf40bb6aa26f3d2ee8d5d843ea
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265622
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9925
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We support SMC32 calls from AARCH64, however we do not support SMC32
calls from AARCH32. Reflect this policy in the code by using
appropriate names for exception type check in SMC handler.
BUG=None
BRANCH=None
TEST=Compiles successfully and able to turn CPU1 on and off using psci commands.
Change-Id: Ifc3c9e2fe0c4e6e395f2647769a2d07f5f41f57f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cbaf712c2c45273a9eb0b0808a0d4d0630023fdd
Original-Change-Id: I133b2c0bbc4968401a028382532bd051d6298802
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265621
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9924
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
CNTFRQ_EL0 can only be set in highest implemented exception level.
Save and restore CNTFRQ_EL0 for secondary cpus in coreboot.
This patch fix the error below:
SANITY CHECK: Unexpected variation in cntfrq. Boot CPU:
0x00000000c65d40, CPU1: 0x00000000000000
BRANCH=none
BUG=none
TEST=boot to kernel on oak board and check secondary cpu's cntfrq.
confirmed cpu1's cntfrq is same as boot cpu's.
Change-Id: I9fbc3c82c2544f0b59ec34b1d631dadf4b9d40eb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b47e4e649efc7f79f016522c7d8a240f98225598
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Change-Id: I2d71b0ccfe42e8a30cd1367d10b0f8993431ef8c
Original-Reviewed-on: https://chromium-review.googlesource.com/264914
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9921
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to allow proper working of caches, set the correct
shareability option for normal memory.
BUG=chrome-os-partner:38222
BRANCH=None
TEST=Compiles successfully for foster and SMP works.
Change-Id: I5462cb0a2ff94a854f71f58709d7b2e8297ccc44
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e092916780716ac80c3608c1bd8ca2901fbb3bd1
Original-Change-Id: Idd3c096a004d76a8fd75df2a884fcb97130d0006
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/262992
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9898
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to not duplicate the instruction cache invalidation
sequence provide a common routine to perform the necessary
actions. Also, use it in the appropriate places.
BUG=None
BRANCH=None
TEST=Built on ryu.
Change-Id: I29ea2371d034c0193949ebb10beb840e7215281a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d5ab28b5d73c03adcdc0fd4e530b39a7a8989dae
Original-Change-Id: I8d5f648c995534294e3222e2dc2091a075dd6beb
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260949
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9871
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
startup.c provides function to enable CPU in any stage to save register data
that can be used by secondary CPU (for normal boot) or any CPU (for resume
boot). stage_entry.S defines space for saving arm64_startup_data. This can be
filled by:
1) Primary CPU before bringing up secondary CPUs so that the secondary can use
register values to initialize MMU-related and other required registers to
appropriate values.
2) CPU suspend path to ensure that on resume the values which were saved are
restored appropriately.
stage_entry.S provides a common path for both normal and resume boot to
initialize saved registers. For resume path, it is important to set the
secondary entry point for startup since x26 needs to be 1 for enabling MMU and
cache.
This also ensures that we do not fall into false memory cache errors which
caused CPU to fail during normal / resume boot. Thus, we can get rid of the
stack cache invalidate for secondary CPUs.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots both CPU0 and CPU1 on ryu without mmu_enable and stack
cache invalidate for CPU1.
Change-Id: Ia4ca0e7d35c0738dbbaa926cce4268143c6f9de3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9f5e78469313ddd144ad7cf5abc3e07cb712183a
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I527a95779cf3fed37392b6605b096f54f8286d64
Original-Reviewed-on: https://chromium-review.googlesource.com/231561
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9540
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
TCR at EL1 is 64-bit whereas at EL2 and EL3 it is 32-bit. Thus, use 64-bit
variables to read / write TCR at current EL. raw_read_tcr_elx will handle it
automatically by accepting / returning 32-bit / 64-bit values.
BUG=chrome-os-partner:33962
BRANCH=None
TEST=Compiles and boots to kernel prompt.
Change-Id: I96312e62a67f482f4233c524ea4e22cbbb60941a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ae71f87143f899383d8311a4ef908908116340d7
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Change-Id: I459914808b69318157113504a3ee7cf6c5f4d8d1
Original-Reviewed-on: https://chromium-review.googlesource.com/231548
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9537
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
psci_soc_init() was added to allow SoC PSCI initialization.
However, actually calling said function was omitted accidentally.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and noted correct on entry point was used.
Change-Id: I84a397e2dabf149fe8f252ef69d0a7362fa1f194
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2a0e6ad41f049bbab483423231db59390894e9b2
Original-Change-Id: I1a4e25fde64ecdc98fa9231f7d9cafc21119630d
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/231935
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9530
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Provide support for SoCs to participate in PSCI commands.
There are 2 steps to a command:
1. prepare() - look at request and adjust state accordingly
2. commit() - take action on the command
The prepare() function is called with psci locks held while
the commit() function is called with the locks dropped.
No SoC implements the appropriate logic yet.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Booted PSCI kernel -- no SMP because cmd_prepare()
knowingly fails. Spintable kernel still brings up both
CPUs.
Change-Id: I2ae4d1c3f3eac4d1060c1b41472909933815d078
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 698d38b53bbc2bc043548792cea7219542b5fe6b
Original-Change-Id: I0821dc2ee8dc6bd1e8bc1c10f8b98b10e24fc97e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226485
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9423
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Newly turned on CPUs need a place to go bring its EL3
state inline with expectations. Plumb this path in for
CPUs turning on as well as waking up from a power down
state. Some of the infrastructure declarations were
moved around for easier consumption in ramstage and
secmon. Lastly, a psci_soc_init() is added to
inform the SoC of the CPU's entry point as well do
any initialization.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted. On entry point not actually utilized.
Change-Id: I2af424c2906df159f78ed5e0a26a6bc0ba2ba24f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: dbefec678a111e8b42acf2ae162c1ccdd7f9fd40
Original-Change-Id: I7b8c8c828ffb73752ca3ac1117cd895a5aa275d8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228296
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9422
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
|
|
Instead of relying on CONFIG_MAX_CPUS to be the number of
CPUs running a platform pass the number of online cpus
from coreboot secmon. That allows for actually enabled
CPUs < CONFIG_MAX_CPUS.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Booted SMP kernel.
Change-Id: Iaf1591e77fcb5ccf5fe271b6c84ea8866e19c59d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3827af876c247fc42cd6be5dd67f8517457b36e7
Original-Change-Id: Ice10b8ab45bb1190a42678e67776846eec4eb79a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227529
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9397
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The struct cpu_action already tracks entry/arg pointers. Use that
instead of duplicating the same information.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted.
Change-Id: I70e1b471ca15eac2ea4e6ca3dab7d8dc2774a241
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cdddfd8d74d227cb5cbdf15b6871480839fa20d8
Original-Change-Id: I4070ef0df19bb1141a1a47c4570a894928d6a5a4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227549
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9396
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current implementation of secmon assumes just entry/arg
are passed to secmon for starting up a CPU. That's lacking
in flexibility. Therefore change secmon_params to contain
both the BSP and secondary CPUs' entry/arg information.
That way more information can be added to secmon_params when
needed.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and booted SMP kernel using PSCI and spin table.
Change-Id: I84c478ccefdfa4580fcc078a2491f49f86a9757a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c5fb5bd857a4318174f5b9b48e28406e60a466f8
Original-Change-Id: Iafb82d5cabc806b6625799a6b3dff8d77bdb27e9
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227548
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9395
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There is state within the system that relies on having
all CPUs present in order to proceed with initialization.
The current expectation is that all CPUs are online and
entering the secure monitor. Therefore, wait until all
CONFIG_MAX_CPUs show up.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Can get all CPUs up in kernel using PSCI.
Change-Id: I741a09128e99e0cb0c9f4046b1c0d27582fda963
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 030535b7c9821b40bf4a51f88e289eab8af9aa13
Original-Change-Id: Ia0f744c93766efc694b522ab0af9aedf7329ac43
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227547
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The arch_run_on_all_cpus[_async]() APIs can run the BSP before
the APs if the BSP's id is less than the APs' ids. Fix this by
ensuring we run the necessary callback on all but self.
BUG=chrome-os-partner:33532
BRANCH=None
TEST=Booted spin table kernel. All CPUs are up.
Change-Id: Ic9a466c3642595bad06cac83647de81873b8353e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 575437354cc20eeac8015a0f7b0c9999ecb0deee
Original-Change-Id: I87e944f870105dbde33b5460660c96c93c3cdf93
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227488
Original-Tested-by: David Riley <davidriley@chromium.org>
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9392
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
In order to properly support more arm64 SoCs PSCI needs
to handle the hierarchy of cpus/clusters within the SoC.
The nodes within PSCI are kept in a tree as well as
a depth-first ordered array of same tree. Additionally,
the PSCI states are now maintained in a hierachal manner.
OFF propogates up the tree as long as all siblings are
set to OFF. ON propogates up the tree until a node is
not already set to OFF.
The SoC provides the operations for determining how many
children are at a given affinity level. Lastly, the
secmon startup has been reworked in that all non-BSP CPUs
wait for instructions from the BSP.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Can still boot into kernel with SMP.
Change-Id: I036fabaf0f1cefa2841264c47e4092c75a2ff4dc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 721d408cd110e1b56d38789177b740aa0e54ca33
Original-Change-Id: I520a9726e283bee7edcb514cda28ec1eb31b5ea0
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226480
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9390
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
In order to dynamically allocate structures based on
affinity levels add malloc() support.
BUG=chrome-os-partner:32136
BRANCH=None
TEST=Built and booted to kernel.
Change-Id: I40cbd8497a1599db12b9e87eeb379f7dcd21c9b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9cd2b23c2ea045b5832b3d838e29f4b6a1b6cdfb
Original-Change-Id: Ie1412a3a9eb07689059a2cd69bd111274bcb88fa
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226482
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9389
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
This stage is not tested on any hardware.
BUG=None
BRANCH=None
TEST=Compiles successfully for rush_ryu and veyron_pinky
Original-Change-Id: I6dd266471c815895bb3dd53d34aacc8fe825eeb6
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/221911
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 907ea2d1f8c9f01d815e8673695dd5271322c7a8)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I617a742d4a387be947086dae33e9a913f742a8d1
Reviewed-on: http://review.coreboot.org/9255
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Secmon needs a special build rule because of the objcopy -B
operation required to include it in ramstage. Utilize the
manual template so builds continue to work with upcoming
build chnages.
Note: secmon is actually missing symbols still so those
still need to be addressed. That looks to be as if
--gc-sections isn't be honored, but I'm actually thinking
the symbols are just erroneously carried over as the
references for these symbols don't show up in the
symbol table:
U coreboot_build
U coreboot_extra_version
U coreboot_version
U default_baudrate
U lb_add_console
U lb_add_serial
U uart_baudrate_divisor
Change-Id: I41c75e93536b73c4304ef3a87dc39d448d1f00d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9300
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
It's an unfortunate side effect of our different-archs-per-stage
mechanism that all src/arch/*/Kconfig files are always parsed with no
if blocks to exclude them if they're not relevant. This makes it very
easy to accidentally rely on a Kconfig default set by a totally
different and not applying architecture.
This patch moves a few Kconfigs from ARM and X86 that leaked out like
this into a common Kconfig file for clarity. It also gives ARM64 its
own BOOTBLOCK_CUSTOM mechanism so that it doesn't leech off the ARM one
(currently not used by any board).
In the future, we should maybe prefix all options in the arch/*/Kconfig
files with the architecture name (such as X86_BOOTBLOCK_NORMAL and
ARM_LPAE are already doing), to make it more apparent when they are used
in the wrong place.
BUG=None
TEST=None (tested together with dependent changes)
Change-Id: I3e8bb3dfbb2c4edada621ce16d130bd7387d4eb8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5528aa9252cdf711af3c160da387c6a7bebe9e76
Original-Change-Id: Ieb2d79bae6c6800be0f93ca3489b658008b1dfae
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219171
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9235
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
It also creates file names in the build directory and with
the stage sliced in, but keeps the extension for anything
not .c or .S.
Also some handling for non-.c/.S files was adapted to match.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: If8f89a7daffcf51f430b64c3293d2a817ae5120f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9175
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
|
|
Introduce generic-$(type)-ccopts and $(class)-generic-ccopts
to declare compiler flags that apply to all files of a certain
type or of a certain class. Then use them.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I655688e82a0cc5bad89b6f55dc217b9f66b64604
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9114
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
|
|
It points to a binary.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I164d7f717a9523d187e2c215083e176b59fd5acc
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9113
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Since PSCI dynamically determines which EL to transition
to based on SCR_EL3 there's no need to provide that
information.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted into kernel with MP.
Change-Id: Ia59bc8116ec4ae9bde2e6cad1861f76c14f7d495
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8bc5f7c8a114568ede98478c2fbea2f8b7d97f0c
Original-Change-Id: I8783b6315dca01464e14c9d2b20d009cf0beeb67
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218924
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9098
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The PSCI functionality initially includes CPU_ON and CPU_OFF
functions. Upon entering secmon if the parameters are non-NULL
then a PSCI CPU_ON action is done for the current CPU.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Booted kernel with PSCI support. Brought up all CPUs in kernel
using PSCI. Turned CPUs on and off.
Change-Id: I256fa45a1c9889ff9d7990eb1898df1ec241c117
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 689ba03e313e7e52e9b74aa774897b55cbd52748
Original-Change-Id: I943826b7dbcc8e3f6c8c4b66344af8fac12ba94e
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218923
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9097
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
If an exception is taken that the secmon won't return
to, there needs to be way to reset that cpu's state
w.r.t. stack usage. Therefore, provide secmon_trampoline
which will reinitialize the exception stack and SP_EL0
and start executing with SP_EL0 like the initial state
of the secmon entry.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted to kernel. Also tested when PSCI
is employed in the kernel.
Change-Id: Ie9f5bbe715dcbcf8b67ea40f9a3a5088ac7aa2ad
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1f546ee3e9eca93baaa1ae0437351205bf548a5
Original-Change-Id: Ia3da75e1fa0251c8ea30eb0b0523c8a51c03b917
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218922
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9096
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Two things:
1. Not returning once setting the return state.
2. mempcy(x, y, ARRAY_SIZE(x)) is not memcpy(x, y, sizeof(x))
With these 2 changes arguments and results are being processed
correctly.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Built and brought up SMP using PSCI.
Change-Id: If76a207e1a434a4c08faaa535f069d7386481e9e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 42d540afd4e6ea2b34cf3632ad2c683fcaa063c8
Original-Change-Id: I656b9c11e3bc07cc1664789a600eb88afd639f93
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218847
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9094
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to process PSCI commands SMC instructions need to be
serviced. Provide a simple way for users of SMC to register their
handlers by function.
The SMC layer hooks into the exception processing, however it only
processes AARCH64 SMC calls. All others are ignored.
BUG=chrome-os-partner:32112
BRANCH=None
TEST=Added nop smc call to depthcharge. SMC handled and continue booting
to kernel.
Change-Id: I378f13c29220ff9f37040f094bf9cfb69259af0c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 76d2febc50397348b68d38532b8f37e2b3cf6a30
Original-Change-Id: Ieaa29fa883b9f9d55fc62ba92a1d45452296efa4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218846
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9092
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The exception vectors were not reinitialized in secmon yet.
Add that as well as the split BSP vs non-BSP path. In doing
so bring in the cpu.c semantics for determining bsp at runtime.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted to kernel. Also noted only one CPU
printing messages.
Change-Id: I26a7f9446f4422d2203b1d520e69f8dee9450b59
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 67f79c61c902ee614f029047255b4be35112cd32
Original-Change-Id: Ide66f13c24f5798d5983c481ce616ae2800d558c
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218845
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9091
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
In order to build upon the arm64 exception handlers need
to be registered. This provides very basic support to
register a handler for a specific exception vector.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Built and booted into kernel.
Change-Id: If046f0736765a2efeb23201c1d2d1f7f7db47dd2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a82e5e8d5900ebef16abdb68701be6beeb9ca13a
Original-Change-Id: I0f68a48101ff48d582f5422871b9e7e5164357e4
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218650
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9088
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There was a hacky and one-off spin table support in tegra132.
Make this support generic for all arm64 chips.
BUG=chrome-os-partner:32082
BRANCH=None
TEST=Ran with and without secure monitor booting smp into the kernel.
Change-Id: I3425ab0c30983d4c74d0aa465dda38bb2c91c83b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 024dc3f3e5262433a56ed14934db837b5feb1748
Original-Change-Id: If12083a9afc3b2be663d36cfeed10f9b74bae3c8
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/218654
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9084
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Secure monitor runs at EL3 and is responsible for jumping to the payload at
specified EL and also to manage features like PSCI.
Adding basic implementation of secure monitor as a rmodule. Currently, it just
jumps to the the payload at current EL. Support for switching el and PSCI will
be added as separate patches.
CQ-DEPEND=CL:218300
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles succesfully and secure monitor loads and runs payload on ryu
Change-Id: If0f22299a9bad4e93311154e5546f5bae3f3395c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e40a21115aeac1cc3c73922bdc3e42d4cdb7d34
Original-Change-Id: I86d5e93583afac141ff61475bd05c8c82d17d926
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/214371
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9080
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Transition library acts as a common interface for handling exceptions. The only
thing that needs to be implemented by exception.c is the exc_dispatch routine to
handle the exceptions as required.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully and exceptions are tested using test_exc
Change-Id: I90b4861909189adfe8449b9d4590965e6b743c00
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b83c9404407dd4dd2dda4e4eaed0b443f0f58425
Original-Change-Id: Ibb643d7ea2f9aabbc66439549ea2168fd66ced5e
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217143
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9071
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
If mmu_init is called more than once then, free_idx should be reset to
1. Here, the assumption would be that mmu_init will not be called more than
once. However, this is not necessarily true. Thus, free_idx should be reset to 1
every time we are initializing ttb from scratch.
BUG=None
BRANCH=None
TEST=Compiles sucessfully and boots to kernel
Change-Id: I5ac0af43346a492583380b0f15101390fc98d182
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 398a68c3b08d82cfa521d235af2c1922629bdf56
Original-Change-Id: Idb7424df7dd577f263f12d1527dbd7fb89216d40
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/216906
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9068
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Instead of relying on config variables to determine the current el, use
{read/write}_current macros for accessing registers.
BUG=chrome-os-partner:30785
BRANCH=None
TEST=Compiles successfully and boots to kernel login prompt
Change-Id: I6c27571fa65e06e28b71fee3e21d6ca93542e66b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 96aed53b2879310f6f979d5aa78b8d1df7f04564
Original-Change-Id: If4a5d1e9aa50ab180c8012862e2a6c37384f7f91
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/217148
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/9065
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|