summaryrefslogtreecommitdiff
path: root/bl31/aarch64/bl31_entrypoint.S
diff options
context:
space:
mode:
authorSoby Mathew <soby.mathew@arm.com>2016-04-29 19:01:30 +0100
committerSoby Mathew <soby.mathew@arm.com>2016-07-19 10:19:01 +0100
commitcf0b1492ede6cbbf788144a56d276d8d7924500a (patch)
treee9c92fdc4021598fed52484d1a11100dbebc2b19 /bl31/aarch64/bl31_entrypoint.S
parent532ed6183868036e4a4f83cd7a71b93266a3bdb7 (diff)
Introduce PSCI Library Interface
This patch introduces the PSCI Library interface. The major changes introduced are as follows: * Earlier BL31 was responsible for Architectural initialization during cold boot via bl31_arch_setup() whereas PSCI was responsible for the same during warm boot. This functionality is now consolidated by the PSCI library and it does Architectural initialization via psci_arch_setup() during both cold and warm boots. * Earlier the warm boot entry point was always `psci_entrypoint()`. This was not flexible enough as a library interface. Now PSCI expects the runtime firmware to provide the entry point via `psci_setup()`. A new function `bl31_warm_entrypoint` is introduced in BL31 and the previous `psci_entrypoint()` is deprecated. * The `smc_helpers.h` is reorganized to separate the SMC Calling Convention defines from the Trusted Firmware SMC helpers. The former is now in a new header file `smcc.h` and the SMC helpers are moved to Architecture specific header. * The CPU context is used by PSCI for context initialization and restoration after power down (PSCI Context). It is also used by BL31 for SMC handling and context management during Normal-Secure world switch (SMC Context). The `psci_smc_handler()` interface is redefined to not use SMC helper macros thus enabling to decouple the PSCI context from EL3 runtime firmware SMC context. This enables PSCI to be integrated with other runtime firmware using a different SMC context. NOTE: With this patch the architectural setup done in `bl31_arch_setup()` is done as part of `psci_setup()` and hence `bl31_platform_setup()` will be invoked prior to architectural setup. It is highly unlikely that the platform setup will depend on architectural setup and cause any failure. Please be be aware of this change in sequence. Change-Id: I7f497a08d33be234bbb822c28146250cb20dab73
Diffstat (limited to 'bl31/aarch64/bl31_entrypoint.S')
-rw-r--r--bl31/aarch64/bl31_entrypoint.S62
1 files changed, 60 insertions, 2 deletions
diff --git a/bl31/aarch64/bl31_entrypoint.S b/bl31/aarch64/bl31_entrypoint.S
index 1c8eed9d..4c3a515a 100644
--- a/bl31/aarch64/bl31_entrypoint.S
+++ b/bl31/aarch64/bl31_entrypoint.S
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013-2015, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2013-2016, ARM Limited and Contributors. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
@@ -31,9 +31,10 @@
#include <arch.h>
#include <bl_common.h>
#include <el3_common_macros.S>
+#include <xlat_tables.h>
.globl bl31_entrypoint
-
+ .globl bl31_warm_entrypoint
/* -----------------------------------------------------
* bl31_entrypoint() is the cold boot entrypoint,
@@ -132,3 +133,60 @@ func bl31_entrypoint
b el3_exit
endfunc bl31_entrypoint
+
+ /* --------------------------------------------------------------------
+ * This CPU has been physically powered up. It is either resuming from
+ * suspend or has simply been turned on. In both cases, call the BL31
+ * warmboot entrypoint
+ * --------------------------------------------------------------------
+ */
+func bl31_warm_entrypoint
+ /*
+ * On the warm boot path, most of the EL3 initialisations performed by
+ * 'el3_entrypoint_common' must be skipped:
+ *
+ * - Only when the platform bypasses the BL1/BL31 entrypoint by
+ * programming the reset address do we need to set the CPU endianness.
+ * In other cases, we assume this has been taken care by the
+ * entrypoint code.
+ *
+ * - No need to determine the type of boot, we know it is a warm boot.
+ *
+ * - Do not try to distinguish between primary and secondary CPUs, this
+ * notion only exists for a cold boot.
+ *
+ * - No need to initialise the memory or the C runtime environment,
+ * it has been done once and for all on the cold boot path.
+ */
+ el3_entrypoint_common \
+ _set_endian=PROGRAMMABLE_RESET_ADDRESS \
+ _warm_boot_mailbox=0 \
+ _secondary_cold_boot=0 \
+ _init_memory=0 \
+ _init_c_runtime=0 \
+ _exception_vectors=runtime_exceptions
+
+ /* --------------------------------------------
+ * Enable the MMU with the DCache disabled. It
+ * is safe to use stacks allocated in normal
+ * memory as a result. All memory accesses are
+ * marked nGnRnE when the MMU is disabled. So
+ * all the stack writes will make it to memory.
+ * All memory accesses are marked Non-cacheable
+ * when the MMU is enabled but D$ is disabled.
+ * So used stack memory is guaranteed to be
+ * visible immediately after the MMU is enabled
+ * Enabling the DCache at the same time as the
+ * MMU can lead to speculatively fetched and
+ * possibly stale stack memory being read from
+ * other caches. This can lead to coherency
+ * issues.
+ * --------------------------------------------
+ */
+ mov x0, #DISABLE_DCACHE
+ bl bl31_plat_enable_mmu
+
+ bl psci_warmboot_entrypoint
+
+ b el3_exit
+endfunc bl31_warm_entrypoint