The TZDRAM base on the reference platform has been bumped up due to
some BL2 memory cleanup. Platforms can also use a different TZDRAM
base by setting TZDRAM_BASE=<value> in the build command line.
This patch removes the bootargs pointer from the platform params
structure. Instead the bootargs are passed by the BL2 in the
bl32_ep_info struct which is a part of the EL3 params struct.
Tegra210: enable WRAP to INCR burst type conversions
The Memory Select Switch Controller routes any CPU transactions to
the appropriate slave depending on the transaction address. During
system suspend, it loses all config settings and hence the CPU has
to restore them during resume.
This patch restores the controller's settings for enabling WRAP to
INCR burst type conversions on the master ports, for any incoming
requests from the AXI slave ports.
Tested by performing multiple system suspend cycles.
Remove the 'NEED_BL32' flag from the makefile. TLK compiles using a
completely different build system and is present on the device as a
binary blob. The NEED_BL32 flag does not influence the TLK load/boot
sequence at all. Moreover, it expects that TLK binary be present on
the host before we can compile BL31 support for Tegra.
This patch removes the flag from the makefile and thus decouples both
the build systems.
Tegra: modify 'BUILD_PLAT' to point to soc specific build dirs
This patch modifies the 'BUILD_PLAT' makefile variable to point to the soc
specific build directory in order to allow each Tegra soc to have its own
build directory. This way we can keep the build outputs separate and can
keep multiple soc specific builds alive at the same time.
Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is
fully ARMv8 architecture compatible. Each of the two Denver cores
implements a 7-way superscalar microarchitecture (up to 7 concurrent
micro-ops can be executed per clock), and includes a 128KB 4-way L1
instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2
cache, which services both cores.
Denver implements an innovative process called Dynamic Code Optimization,
which optimizes frequently used software routines at runtime into dense,
highly tuned microcode-equivalent routines. These are stored in a
dedicated, 128MB main-memory-based optimization cache. After being read
into the instruction cache, the optimized micro-ops are executed,
re-fetched and executed from the instruction cache as long as needed and
capacity allows.
Effectively, this reduces the need to re-optimize the software routines.
Instead of using hardware to extract the instruction-level parallelism
(ILP) inherent in the code, Denver extracts the ILP once via software
techniques, and then executes those routines repeatedly, thus amortizing
the cost of ILP extraction over the many execution instances.
Denver also features new low latency power-state transitions, in addition
to extensive power-gating and dynamic voltage and clock scaling based on
workloads.
The validate_power_state() handler checks the power_state for a valid afflvl
and state id. Although the afflvl check is common, the state ids are implementation
defined.
This patch moves the handler to the tegra/soc folder to allow each SoC to validate
the power_state for supported parameters.
Tegra: T210: include CPU files from SoC's platform.mk
This patch moves the inclusion of CPU code (A53, A57) to T210's
makefile. This way we can reduce code size for Tegra platforms by
including only the required CPU files.
Tegra: Introduce config for enabling NS access to L2/CPUECTRL regs
A new config, ENABLE_NS_L2_CPUECTRL_RW_ACCESS, allows Tegra platforms to
enable read/write access to the L2 and CPUECTRL registers. T210 is the
only platform that needs to enable this config for now.
Tegra210: lock PMC registers holding CPU vector addresses
This patch locks access to the PMC registers which hold the CPU reset
vector addresses. The PMC registers are used by the warmboot code and
must be locked during boot/resume to avoid booting into custom firmware
installed by unknown parties e.g. hackers.
The PMC Scratch22 register contains the CPU reset vector to
be used by the warmboot code to power up the CPU while resuming
from system suspend. This patch locks this PMC register to avoid
any further writes.
Tegra210: deassert CPU reset signals during power on
This patch de-asserts the CPU reset signals for each CPU as
part of it's power on sequence. This is needed to get rid of
the wait in BPMP firmware during SC7 exit.
This patch fixes the delay loop used to wake up the BPMP during SC7 exit.
The earlier loop would fail just when the timer was about to wrap-around
(e.g. when TEGRA_TMRUS_BASE is 0xfffffffe, the target value becomes 0,
which would cause the loop to exit before it's expiry).
This patch introduces the backend required for implementing the delay
timer API. Tegra has an on-chip free flowing us timer which can be
used as the delay timer.
Juan Castillo [Tue, 7 Jul 2015 14:36:33 +0000 (15:36 +0100)]
Fix bug in semihosting write function
The return value from the SYS_WRITE semihosting operation is 0 if
the call is successful or the number of bytes not written, if there
is an error. The implementation of the write function in the
semihosting driver treats the return value as the number of bytes
written, which is wrong. This patch fixes it.
Juan Castillo [Fri, 12 Jun 2015 10:27:59 +0000 (11:27 +0100)]
TBB: rework cert_create tool to follow a data driven approach
This patch reworks the certificate generation tool to follow a data
driven approach. The user may specify at build time the certificates,
keys and extensions defined in the CoT, register them using the
appropiate macros and the tool will take care of creating the
certificates corresponding to the CoT specified.
Linaro produce monthly software releases for the Juno and AEMv8-FVP
platforms. These provide an integrated set of software components
that have been tested together on these platforms.
From now on, it is recommend that Trusted Firmware developers use the
Linaro releases (currently 15.06) as a baseline for the dependent
software components: normal world firmware, Linux kernel and device
tree, file system as well as any additional micro-controller firmware
required by the platform.
This patch updates the user guide to document this new process. It
changes the instructions to get the source code of the full software
stack (including Trusted Firmware) and updates the dependency build
instructions to make use of the build scripts that the Linaro releases
provide.
Juan Castillo [Tue, 9 Sep 2014 08:49:23 +0000 (09:49 +0100)]
Use uintptr_t as base address type in ARM driver APIs
This patch changes the type of the base address parameter in the
ARM device driver APIs to uintptr_t (GIC, CCI, TZC400, PL011). The
uintptr_t type allows coverage of the whole memory space and to
perform arithmetic operations on the addresses. ARM platform code
has also been updated to use uintptr_t as GIC base address in the
configuration.
Implement get_sys_suspend_power_state() handler for Tegra
This patch implements the get_sys_suspend_power_state() handler required by
the PSCI SYSTEM_SUSPEND API. The intent of this handler is to return the
appropriate State-ID field which can be utilized in `affinst_suspend()` to
suspend to system affinity level.
Juan Castillo [Tue, 30 Jun 2015 12:36:57 +0000 (13:36 +0100)]
TBB: build 'cert_create' with ECDSA only if OpenSSL supports it
Some Linux distributions include an OpenSSL library which has been
built without ECDSA support. Trying to build the certificate
generation tool on those distributions will result in a build error.
This patch fixes that issue by including ECDSA support only if
OpenSSL has been built with ECDSA. In that case, the OpenSSL
configuration file does not define the OPENSSL_NO_EC macro. The tool
will build successfully, although the resulting binary will not
support ECDSA keys.
Juan Castillo [Fri, 10 Apr 2015 11:43:27 +0000 (12:43 +0100)]
TBB: delete deprecated plat_match_rotpk()
The authentication framework deprecates plat_match_rotpk()
in favour of plat_get_rotpk_info(). This patch removes
plat_match_rotpk() from the platform port.
After updating the main authentication module to use the transport
and crypto modules and the CoT description, the PolarSSL
authentication module is no longer required. This patch deletes it.
Juan Castillo [Tue, 19 May 2015 10:54:12 +0000 (11:54 +0100)]
TBB: switch to the new authentication framework
This patch modifies the Trusted Board Boot implementation to use
the new authentication framework, making use of the authentication
module, the cryto module and the image parser module to
authenticate the images in the Chain of Trust.
A new function 'load_auth_image()' has been implemented. When TBB
is enabled, this function will call the authentication module to
authenticate parent images following the CoT up to the root of
trust to finally load and authenticate the requested image.
The platform is responsible for picking up the right makefiles to
build the corresponding cryptographic and image parser libraries.
ARM platforms use the mbedTLS based libraries.
The platform may also specify what key algorithm should be used
to sign the certificates. This is done by declaring the 'KEY_ALG'
variable in the platform makefile. FVP and Juno use ECDSA keys.
On ARM platforms, BL2 and BL1-RW regions have been increased 4KB
each to accommodate the ECDSA code.
Juan Castillo [Mon, 1 Jun 2015 15:34:23 +0000 (16:34 +0100)]
TBB: add ECDSA support to the certificate generation tool
This patch extends the 'cert_create' tool to support ECDSA keys
to sign the certificates. The '--key-alg' command line option
can be used to specify the key algorithm when invoking the tool.
Available options are:
The TF Makefile has been updated to allow the platform to specify
the key algorithm by declaring the 'KEY_ALG' variable in the
platform makefile.
The behaviour regarding key management has changed. After applying
this patch, the tool will try first to open the keys from disk. If
one key does not exist or no key is specified, and the command line
option to create keys has been specified, new keys will be created.
Otherwise an error will be generated and the tool will exit. This
way, the user may specify certain keys while the tool will create
the remaining ones. This feature is useful for testing purposes
and CI infrastructures.
The OpenSSL directory may be specified using the build option
'OPENSSL_DIR' when building the certificate generation tool.
Default is '/usr'.
Juan Castillo [Thu, 7 May 2015 13:52:44 +0000 (14:52 +0100)]
TBB: add TBBR Chain of Trust
This patch adds a CoT based on the Trusted Board Boot Requirements
document*. The CoT consists of an array of authentication image
descriptors indexed by the image identifiers.
A new header file with TBBR image identifiers has been added.
Platforms that use the TBBR (i.e. ARM platforms) may reuse these
definitions as part of their platform porting.
PLATFORM PORT - IMPORTANT:
Default image IDs have been removed from the platform common
definitions file (common_def.h). As a consequence, platforms that
used those common definitons must now either include the IDs
provided by the TBBR header file or define their own IDs.
*The NVCounter authentication method has not been implemented yet.
Juan Castillo [Thu, 2 Apr 2015 14:44:20 +0000 (15:44 +0100)]
TBB: add mbedTLS authentication related libraries
This patch adds the following mbedTLS based libraries:
* Cryptographic library
It is used by the crypto module to verify a digital signature
and a hash. This library relies on mbedTLS to perform the
cryptographic operations. mbedTLS sources must be obtained
separately.
Two key algorithms are currently supported:
* RSA-2048
* ECDSA-SECP256R1
The platform is responsible for picking up the required
algorithm by defining the 'MBEDTLS_KEY_ALG' variable in the
platform makefile. Available options are:
Juan Castillo [Thu, 2 Apr 2015 08:48:16 +0000 (09:48 +0100)]
TBB: add authentication framework
This patch adds the authentication framework that will be used as
the base to implement Trusted Board Boot in the Trusted Firmware.
The framework comprises the following modules:
- Image Parser Module (IPM)
This module is responsible for interpreting images, check
their integrity and extract authentication information from
them during Trusted Board Boot.
The module currently supports three types of images i.e.
raw binaries, X509v3 certificates and any type specific to
a platform. An image parser library must be registered for
each image type (the only exception is the raw image parser,
which is included in the main module by default).
Each parser library (if used) must export a structure in a
specific linker section which contains function pointers to:
1. Initialize the library
2. Check the integrity of the image type supported by
the library
3. Extract authentication information from the image
- Cryptographic Module (CM)
This module is responsible for verifying digital signatures
and hashes. It relies on an external cryptographic library
to perform the cryptographic operations.
To register a cryptographic library, the library must use the
REGISTER_CRYPTO_LIB macro, passing function pointers to:
1. Initialize the library
2. Verify a digital signature
3. Verify a hash
Failing to register a cryptographic library will generate
a build time error.
- Authentication Module (AM)
This module provides methods to authenticate an image, like
hash comparison or digital signatures. It uses the image parser
module to extract authentication parameters, the crypto module
to perform cryptographic operations and the Chain of Trust to
authenticate the images.
The Chain of Trust (CoT) is a data structure that defines the
dependencies between images and the authentication methods
that must be followed to authenticate an image.
The Chain of Trust, when added, must provide a header file named
cot_def.h with the following definitions:
- COT_MAX_VERIFIED_PARAMS
Integer value indicating the maximum number of authentication
parameters an image can present. This value will be used by the
authentication module to allocate the memory required to load
the parameters in the image descriptor.
Juan Castillo [Tue, 14 Apr 2015 11:49:03 +0000 (12:49 +0100)]
TBB: add platform API to read the ROTPK information
This patch extends the platform port by adding an API that returns
either the Root of Trust public key (ROTPK) or its hash. This is
usually stored in ROM or eFUSE memory. The ROTPK returned must be
encoded in DER format according to the following ASN.1 structure:
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
An implementation for ARM development platforms is provided in this
patch. When TBB is enabled, the ROTPK hash location must be specified
using the build option 'ARM_ROTPK_LOCATION'. Available options are:
- 'regs' : return the ROTPK hash stored in the Trusted
root-key storage registers.
- 'devel_rsa' : return a ROTPK hash embedded in the BL1 and
BL2 binaries. This hash has been obtained from the development
RSA public key located in 'plat/arm/board/common/rotpk'.
On FVP, the number of MMU tables has been increased to map and
access the ROTPK registers.
A new file 'board_common.mk' has been added to improve code sharing
in the ARM develelopment platforms.
Juan Castillo [Mon, 13 Apr 2015 16:36:19 +0000 (17:36 +0100)]
Use numbers to identify images instead of names
The Trusted firmware code identifies BL images by name. The platform
port defines a name for each image e.g. the IO framework uses this
mechanism in the platform function plat_get_image_source(). For
a given image name, it returns the handle to the image file which
involves comparing images names. In addition, if the image is
packaged in a FIP, a name comparison is required to find the UUID
for the image. This method is not optimal.
This patch changes the interface between the generic and platform
code with regard to identifying images. The platform port must now
allocate a unique number (ID) for every image. The generic code will
use the image ID instead of the name to access its attributes.
As a result, the plat_get_image_source() function now takes an image
ID as an input parameter. The organisation of data structures within
the IO framework has been rationalised to use an image ID as an index
into an array which contains attributes of the image such as UUID and
name. This prevents the name comparisons.
A new type 'io_uuid_spec_t' has been introduced in the IO framework
to specify images identified by UUID (i.e. when the image is contained
in a FIP file). There is no longer need to maintain a look-up table
[iname_name --> uuid] in the io_fip driver code.
Because image names are no longer mandatory in the platform port, the
debug messages in the generic code will show the image identifier
instead of the file name. The platforms that support semihosting to
load images (i.e. FVP) must provide the file names as definitions
private to the platform.
The ARM platform ports and documentation have been updated accordingly.
All ARM platforms reuse the image IDs defined in the platform common
code. These IDs will be used to access other attributes of an image in
subsequent patches.
IMPORTANT: applying this patch breaks compatibility for platforms that
use TF BL1 or BL2 images or the image loading code. The platform port
must be updated to match the new interface.
Juan Castillo [Tue, 10 Mar 2015 15:18:55 +0000 (15:18 +0000)]
TBB: replace assert() with runtime checks in PolarSSL module
Using assert() to check the length of keys and hashes included in
a certificate is not a safe approach because assert() only applies
to debug builds. A malformed certificate could exploit security
flaws in release binaries due to buffer overflows.
This patch replaces assert() with runtime checkings in the PolarSSL
authentication module, so malformed certificates can not cause a
memory overflow.
Juan Castillo [Thu, 5 Mar 2015 14:30:00 +0000 (14:30 +0000)]
TBB: use ASN.1 type DigestInfo to represent hashes
The cert_create tool calculates the hash of each BL image and includes
it as an ASN.1 OCTET STRING in the corresponding certificate extension.
Without additional information, the firmware running on the platform
has to know in advance the algorithm used to generate the hash.
This patch modifies the cert_create tool so the certificate extensions
that include an image hash are generated according to the following
ASN.1 structure:
Juan Castillo [Wed, 25 Feb 2015 12:43:12 +0000 (12:43 +0000)]
TBB: add build option to save private keys
This patch adds a boolean build option 'SAVE_KEYS' to indicate the
certificate generation tool that it must save the private keys used
to establish the chain of trust. This option depends on 'CREATE_KEYS'
to be enabled. Default is '0' (do not save).
Because the same filenames are used as outputs to save the keys,
they are no longer a dependency to the cert_tool. This dependency
has been removed from the Makefile.
This patch fixes the build time condition deciding whether the
read-write data should be relocated from ROM to RAM. It was incorrectly
using __DATA_ROM_START__, which is a linker symbol and not a compiler
build flag. As a result, the relocation code was always compiled out.
This bug has been introduced by the following patch:
"Rationalize reset handling code"
Soby Mathew [Wed, 17 Dec 2014 14:47:57 +0000 (14:47 +0000)]
PSCI: Add SYSTEM_SUSPEND API support
This patch adds support for SYSTEM_SUSPEND API as mentioned in the PSCI 1.0
specification. This API, on being invoked on the last running core on a
supported platform, will put the system into a low power mode with memory
retention.
The psci_afflvl_suspend() internal API has been reused as most of the actions
to suspend a system are the same as invoking the PSCI CPU_SUSPEND API with the
target affinity level as 'system'. This API needs the 'power state' parameter
for the target low power state. This parameter is not passed by the caller of
the SYSTEM_SUSPEND API. Hence, the platform needs to implement the
get_sys_suspend_power_state() platform function to provide this information.
Also, the platform also needs to add support for suspending the system to the
existing 'plat_pm_ops' functions: affinst_suspend() and
affinst_suspend_finish().
Varun Wadekar [Tue, 16 Jun 2015 05:53:00 +0000 (11:23 +0530)]
Add missing features to the Tegra GIC driver
In order to handle secure/non-secure interrupts, overload the plat_ic_*
functions and copy GIC helper functions from arm_gic.c. Use arm_gic.c
as the reference to add Tegra's GIC helper functions.
Now that Tegra has its own GIC implementation, we have no use for
plat_gic.c and arm_gic.c files.
Andrew Thoelke [Thu, 11 Jun 2015 13:22:07 +0000 (14:22 +0100)]
Fix integer extension in mpidr_set_aff_inst()
mpidr_set_aff_inst() is left shifting an int constant and an
unsigned char value to construct an MPIDR. For affinity level 3 a
shift of 32 would result in shifting out of the 32-bit type and
have no effect on the MPIDR.
These values need to be extended to unsigned long before shifting
to ensure correct results for affinity level 3.
Ryan Harkin [Tue, 17 Mar 2015 14:54:01 +0000 (14:54 +0000)]
FVP: Add SP804 delay timer
Add SP804 delay timer support to the FVP BSP.
This commit simply provides the 3 constants needed by the SP804
delay timer driver and calls sp804_timer_init() in
bl2_platform_setup(). The BSP does not currently use the delay
timer functions.
Note that the FVP SP804 is a normal world accessible peripheral
and should not be used by the secure world after transition
to the normal world.
Change-Id: I5f91d2ac9eb336fd81943b3bb388860dfb5f2b39 Co-authored-by: Dan Handley <dan.handley@arm.com>
Ryan Harkin [Tue, 17 Mar 2015 14:50:05 +0000 (14:50 +0000)]
Add a simple delay timer driver API
The API is simple. The BSP or specific timer driver creates an
instance of timer_ops_t, fills in the timer specific data, then calls
timer_init(). The timer specific data includes a function pointer
to return the timer value and a clock multiplier/divider. The ratio
of the multiplier and the divider is the clock frequency in MHz.
After that, mdelay() or udelay() can be called to delay execution for
the specified time (milliseconds or microseconds, respectively).
Change-Id: Icf8a295e1d25874f789bf28b7412156329dc975c Co-authored-by: Dan Handley <dan.handley@arm.com>
Varun Wadekar [Wed, 10 Jun 2015 08:34:32 +0000 (14:04 +0530)]
Reserve a Video Memory aperture in DRAM memory
This patch adds support to reserve a memory carveout region in the
DRAM on Tegra SoCs. The memory controller provides specific registers
to specify the aperture's base and size. This aperture can also be
changed dynamically in order to re-size the memory available for
DRM video playback. In case of the new aperture not overlapping
the previous one, the previous aperture has to be cleared before
setting up the new one. This means we do not "leak" any video data
to the NS world.
Varun Wadekar [Fri, 5 Jun 2015 07:27:27 +0000 (12:57 +0530)]
Boot Trusted OS' on Tegra SoCs
This patch adds support to run a Trusted OS during boot time. The
previous stage bootloader passes the entry point information in
the 'bl32_ep_info' structure, which is passed over to the SPD.
The build system expects the dispatcher to be passed as an input
parameter using the 'SPD=<dispatcher>' option. The Tegra docs have
also been updated with this information.
For CSS based platforms, the constants MHU_SECURE_BASE and
MHU_SECURE_SIZE used to define the extents of the Trusted Mailboxes.
As such, they were misnamed because the mailboxes are completely
unrelated to the MHU hardware.
This patch removes the MHU_SECURE_BASE and MHU_SECURE_SIZE #defines.
The address of the Trusted Mailboxes is now relative to the base of
the Trusted SRAM.
This patch also introduces a new constant, SCP_COM_SHARED_MEM_BASE,
which is the address of the first memory region used for communication
between AP and SCP. This is used by the BOM and SCPI protocols.
Add a comment explaining what the SCP boot configuration information
is on CSS based platforms like Juno. Also express its address
relatively to the base of the Trusted SRAM rather than hard-coding it.
Juan Castillo [Mon, 8 Jun 2015 10:35:06 +0000 (11:35 +0100)]
Fix build option 'ARM_TSP_RAM_LOCATION' in user guide
The 'ARM_TSP_RAM_LOCATION_ID' option specified in the user guide
corresponds to the internal definition not visible to the final
user. The proper build option is 'ARM_TSP_RAM_LOCATION'. This
patch fixes it.
This patch introduces a new platform build option, called
PROGRAMMABLE_RESET_ADDRESS, which tells whether the platform has
a programmable or fixed reset vector address.
If the reset vector address is fixed then the code relies on the
platform_get_entrypoint() mailbox mechanism to figure out where
it is supposed to jump. On the other hand, if it is programmable
then it is assumed that the platform code will program directly
the right address into the RVBAR register (instead of using the
mailbox redirection) so the mailbox is ignored in this case.
The attempt to run the CPU reset code as soon as possible after reset
results in highly complex conditional code relating to the
RESET_TO_BL31 option.
This patch relaxes this requirement a little. In the BL1, BL3-1 and
PSCI entrypoints code, the sequence of operations is now as follows:
1) Detect whether it is a cold or warm boot;
2) For cold boot, detect whether it is the primary or a secondary
CPU. This is needed to handle multiple CPUs entering cold reset
simultaneously;
3) Run the CPU init code.
This patch also abstracts the EL3 registers initialisation done by
the BL1, BL3-1 and PSCI entrypoints into common code.
This improves code re-use and consolidates the code flows for
different types of systems.
NOTE: THE FUNCTION plat_secondary_cold_boot() IS NOW EXPECTED TO
NEVER RETURN. THIS PATCH FORCES PLATFORM PORTS THAT RELIED ON THE
FORMER RETRY LOOP AT THE CALL SITE TO MODIFY THEIR IMPLEMENTATION.
OTHERWISE, SECONDARY CPUS WILL PANIC.
This patch removes the FIRST_RESET_HANDLER_CALL build flag and its
use in ARM development platforms. If a different reset handling
behavior is required between the first and subsequent invocations
of the reset handling code, this should be detected at runtime.
On Juno, the platform reset handler is now always compiled in.
This means it is now executed twice on the cold boot path, first in
BL1 then in BL3-1, and it has the same behavior in both cases. It is
also executed twice on the warm boot path, first in BL1 then in the
PSCI entrypoint code.
Also update the documentation to reflect this change.
NOTE: THIS PATCH MAY FORCE PLATFORM PORTS THAT USE THE
FIRST_RESET_HANDLER_CALL BUILD OPTION TO FIX THEIR RESET HANDLER.
FVP: Correct the PSYSR_WK bit width in platform_get_entrypoint
This patch fixes the incorrect bit width used to extract the wakeup
reason from PSYSR in platform_get_entrypoint() function. This defect
did not have any observed regression.
On ARM standard platforms, snoop and DVM requests used to be enabled
for the primary CPU's cluster only in the first EL3 bootloader.
In other words, if the platform reset into BL1 then CCI coherency
would be enabled by BL1 only, and not by BL3-1 again.
However, this doesn't cater for platforms that use BL3-1 along with
a non-TF ROM bootloader that doesn't enable snoop and DVM requests.
In this case, CCI coherency is never enabled.
This patch modifies the function bl31_early_platform_setup() on
ARM standard platforms so that it always enables snoop and DVM
requests regardless of whether earlier bootloader stages have
already done it. There is no harm in executing this code twice.
ARM Trusted Firmware Design document updated accordingly.
Varun Wadekar [Tue, 19 May 2015 11:18:04 +0000 (16:48 +0530)]
Support for NVIDIA's Tegra T210 SoCs
T210 is the latest chip in the Tegra family of SoCs from NVIDIA. It is an
ARM v8 dual-cluster (A57/A53) SoC, with any one of the clusters being active
at a given point in time.
This patch adds support to boot the Trusted Firmware on T210 SoCs. The patch
also adds support to boot secondary CPUs, enter/exit core power states for
all CPUs in the slow/fast clusters. The support to switch between clusters
is still not available in this patch and would be available later.
Soby Mathew [Tue, 26 May 2015 15:58:54 +0000 (16:58 +0100)]
CSS: Extract primary cpu id using the correct bit width
This patch fixes the incorrect bit width used to extract the primary
cpu id from `ap_data` exported by scp at SCP_BOOT_CFG_ADDR in
platform_is_primary_cpu().
Achin Gupta [Mon, 18 May 2015 09:56:47 +0000 (10:56 +0100)]
Fix reporting of interrupt ID in ARM GIC driver
The ARM GIC driver treats the entire contents of the GICC_HPPIR as the interrupt
ID instead of just bits[9:0]. This could result in an SGI being treated as a
Group 1 interrupt on a GICv2 system.
This patch introduces a mask to retrieve only the ID from a read of GICC_HPPIR,
GICC_IAR and similar registers. The value read from these registers is masked
with this constant prior to use as an interrupt ID.
Achin Gupta [Wed, 13 May 2015 16:57:18 +0000 (17:57 +0100)]
Fix handling of spurious interrupts in BL3_1
There are couple of issues with how the interrupt routing framework in BL3_1
handles spurious interrupts.
1. In the macro 'handle_interrupt_exception', if a spurious interrupt is
detected by plat_ic_get_pending_interrupt_type(), then execution jumps to
'interrupt_exit_\label'. This macro uses the el3_exit() function to return to
the original exception level. el3_exit() attempts to restore the SPSR_EL3 and
ELR_EL3 registers with values from the current CPU context. Since these
registers were not saved in this code path, it programs stale values into
these registers. This leads to unpredictable behaviour after the execution of
the ERET instruction.
2. When an interrupt is routed to EL3, it could be de-asserted before the
GICC_HPPIR is read in plat_ic_get_pending_interrupt_type(). There could be
another interrupt pending at the same time e.g. a non-secure interrupt. Its
type will be returned instead of the original interrupt. This would result in
a call to get_interrupt_type_handler(). The firmware will panic if the
handler for this type of interrupt has not been registered.
This patch fixes the first problem by saving SPSR_EL3 and ELR_EL3 early in the
'handle_interrupt_exception' macro, instead of only doing so once the validity
of the interrupt has been determined.
The second problem is fixed by returning execution back to the lower exception
level through the 'interrupt_exit_\label' label instead of treating it as an
error condition. The 'interrupt_error_\label' label has been removed since it is
no longer used.
Soby Mathew [Mon, 11 May 2015 22:15:06 +0000 (23:15 +0100)]
PSCI: Set ON_PENDING state early during CPU_ON
In the debug build of the function get_power_on_target_afflvl(), there is a
check to ensure that the CPU is emerging from a SUSPEND or ON_PENDING state.
The state is checked without acquiring the lock for the CPU node. The state
could be updated to ON_PENDING in psci_afflvl_on() after the target CPU has
been powered up. This results in a race condition which could cause the
check for the ON_PENDING state in get_power_on_target_afflvl() to fail.
This patch resolves this race condition by setting the state of the target
CPU to ON_PENDING before the platform port attempts to power it on. The
target CPU is thus guaranteed to read the correct the state. In case
the power on operation fails, the state of the CPU is restored to OFF.
Juan Castillo [Thu, 16 Apr 2015 13:17:49 +0000 (14:17 +0100)]
FVP: update device tree idle state entries
Device tree idle state bindings changed in kernel v3.18. This patch
updates the FVP DT files to use PSCI suspend as idle state.
The patch also updates the 'compatible' property in the PSCI node
and the 'entry-method' property in the idle-states node in the FVP
Foundation GICv2-legacy device tree.
projects / arm-tf.git / log