The PL011 TRM (ARM DDI 0183G) specifies that the UART must be
disabled before any of the control registers are programmed. The
PL011 driver included in TF does not disable the UART, so the
initialization in BL2 and BL31 is violating this requirement
(and potentially in BL1 if the UART is enabled after reset).
This patch modifies the initialization function in the PL011
console driver to disable the UART before programming the
control registers.
Register clobber list and documentation updated.
FixesARM-software/tf-issues#300
Change-Id: I839b2d681d48b03f821ac53663a6a78e8b30a1a1
Currently, Trusted Firmware on ARM platforms unlocks access to the
timer frame registers that will be used by the Non-Secure world. This
unlock operation should be done by the Non-Secure software itself,
instead of relying on secure firmware settings.
This patch adds a new ARM specific build option 'ARM_CONFIG_CNTACR'
to unlock access to the timer frame by setting the corresponding
bits in the CNTACR<N> register. The frame id <N> is defined by
'PLAT_ARM_NSTIMER_FRAME_ID'. Default value is true (unlock timer
access).
Documentation updated accordingly.
FixesARM-software/tf-issues#170
Change-Id: Id9d606efd781e43bc581868cd2e5f9c8905bdbf6
GIC v2 and v3 specification references in the porting guide
should refer to publically visible links, not ARM internal links.
Change-Id: Ib47c8adda6a03581f23bcaed72d71c08c7dd9fb1
Signed-off-by: Yuping Luo <yuping.luo@arm.com>
Since commit 804040d106, the Juno port has moved from per-CPU mailboxes
to a single shared one. This patch updates an out-dated reference to
the former per-CPU mailboxes mechanism in the Firmware Design.
Change-Id: I355b54156b1ace1b3df4c4416e1e8625211677fc
Migrate all direct usage of __attribute__ to usage of their
corresponding macros from cdefs.h.
e.g.:
- __attribute__((unused)) -> __unused
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
This patch adds a brief description of 'MAX_MMAP_REGIONS' and
'ADDR_SPACE_SIZE' to the Porting Guide. These fields must be defined
by the platform in order to use the translation table library.
Change-Id: Ida366458fe2bc01979091a014dc38da0fae5991e
This patch fixes a couple of issues in the "CPU specific operations
framework" section in the Firmware Design document.
* Fix broken link to the CPU Specific Build Macros document.
* Fix the path to the cortex_a53.S file.
* Fix power levels terminology.
Change-Id: Ib610791eaba13dab2823b7699bb63534bcd1c8fb
The fip_create tool specifies images in the command line using the
ARM TF naming convention (--bl2, --bl31, etc), while the cert_create
tool uses the TBBR convention (--tb-fw, --soc-fw, etc). This double
convention is confusing and should be aligned.
This patch updates the fip_create command line options to follow the
TBBR naming convention. Usage examples in the User Guide have been
also updated.
NOTE: users that build the FIP by calling the fip_create tool directly
from the command line must update the command line options in their
scripts. Users that build the FIP by invoking the main ARM TF Makefile
should not notice any difference.
Change-Id: I84d602630a2585e558d927b50dfde4dd2112496f
Remove the following redundant sentence from the user guide, which
implies the user should use the TF version from the Linaro release,
which was not the intention:
"However, the rest of this document assumes that you got the
Trusted Firmware as part of the Linaro release."
Also, tidied up the grammar in this section.
Change-Id: I5dae0b68d3683e2a85a7b3c6a31222182a66f6c8
This patch adds design documentation for the Firmware Update (FWU)
feature in `firmware-update.md`. It provides an overview of FWU,
describes the BL1 SMC interface, and includes diagrams showing
an example FWU boot flow and the FWU state machine.
This patch also updates the existing TF documents where needed:
* `porting-guide.md`
* `user-guide.md`
* `firmware-design.md`
* `rt-svc-writers-guide.md`
* `trusted_board_boot.md`
Change-Id: Ie6de31544429b18f01327bd763175e218299a4ce
Co-Authored-By: Dan Handley <dan.handley@arm.com>
This patch introduces a new document presenting the ARM Trusted
Firmware Reset Design. It shows the reset code flow, lists the
different build options that affect it, in which case to use them
and what their exact effect is.
The section about using BL31 entrypoint as the reset address has
been moved from the general firmware design document to this one.
It's also been improved to explain why the FVP port supports the
RESET_TO_BL31 configuration, even though the reset vector address
can't be programmed dynamically.
This document includes some images, which have been generated using
Dia version 0.97.2. This tool can be obtained from:
https://wiki.gnome.org/Apps/Dia/Download
This patch provides:
- the image files describing the different reset flow diagrams;
- the source '.dia' file;
- a script automating the generation of the images from the '.dia'
file.
Note that the 2 latter files are not actually needed for the document
and are provided for convenience only, in case the reset images need
to be modified.
Change-Id: Ib6302e8209d418a5b31c4e85e55fd9e83caf2ca2
This patch updates the relevant documentation in ARM Trusted Firmware
for the new GIC drivers. The user-guide.md and porting-guide.md have been
updated as follows:
* The build option to compile Trusted Firmware with different GIC drivers
for FVP has been explained in the user-guide.md.
* The implementation details of interrupt management framework porting
APIs for GICv3 have been added in porting-guide.md.
* The Linaro tracking kernel release does not work OOB in GICv3 mode.
The instructions for changing UEFI configuration in order to run with
the new GICv3 driver in ARM TF have been added to user-guide.md.
The interrupt-framework-design.md has been updated as follows:
* Describes support for registering and handling interrupts targeted to EL3
e.g. Group 0 interrupts in GICv3.
* Describes the build option `TSP_NS_INTR_ASYNC_PREEMPT` in detail.
* Describes preemption of TSP in S-EL1 by non secure interrupts and
also possibly by higher priority EL3 interrupts.
* Describes the normal world sequence for issuing `standard` SMC calls.
* Modifies the document to correspond to the current state of interrupt
handling in TSPD and TSP.
* Modifies the various functions names in the document to reflect
the current names used in code.
Change-Id: I78c9514b5be834f193405aad3c1752a4a9e27a6c
This patch removes the dash character from the image name, to
follow the image terminology in the Trusted Firmware Wiki page:
https://github.com/ARM-software/arm-trusted-firmware/wiki
Changes apply to output messages, comments and documentation.
non-ARM platform files have been left unmodified.
Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
This patch replaces all references to the SCP Firmware (BL0, BL30,
BL3-0, bl30) with the image terminology detailed in the TF wiki
(https://github.com/ARM-software/arm-trusted-firmware/wiki):
BL0 --> SCP_BL1
BL30, BL3-0 --> SCP_BL2
bl30 --> scp_bl2
This change affects code, documentation, build system, tools and
platform ports that load SCP firmware. ARM plaforms have been
updated to the new porting API.
IMPORTANT: build option to specify the SCP FW image has changed:
BL30 --> SCP_BL2
IMPORTANT: This patch breaks compatibility for platforms that use BL2
to load SCP firmware. Affected platforms must be updated as follows:
BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
BL30_BASE --> SCP_BL2_BASE
bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
The mbed TLS library has introduced some changes in the API from
the 1.3.x to the 2.x releases. Using the 2.x releases requires
some changes to the crypto and transport modules.
This patch updates both modules to the mbed TLS 2.x API.
All references to the mbed TLS library in the code or documentation
have been updated to 'mbed TLS'. Old references to PolarSSL have
been updated to 'mbed TLS'.
User guide updated to use mbed TLS 2.2.0.
NOTE: moving up to mbed TLS 2.x from 1.3.x is not backward compatible.
Applying this patch will require an mbed TLS 2.x release to be used.
Also note that the mbed TLS license changed to Apache version 2.0.
Change-Id: Iba4584408653cf153091f2ca2ee23bc9add7fda4
Move up the version numbers in the user guide of:
* DS-5 (to v5.22)
* Base FVP (to 7.0)
* Foundation FVP (to 9.4)
* Linaro release (to 15.10)
Note that, starting from Linaro release 15.10, the related release
instructions have migrated from http://releases.linaro.org to the
ARM Connected Community website. The URLs in the User Guide have
been updated accordingly.
The 'libssl-dev' package has been removed from the list of
prerequisite tools, as it is already referenced on the ARM Connected
Community page. Also, the 'device-tree-compiler' package has been
marked as an optional dependency, since the Trusted Firmware
repository provides the prebuilt DTB files. Hence, this tool is
needed only when the user wants to rebuild the DTS files.
Change-Id: I4a172ece60bf90437131c6b96e73a9f1e9b40117
The Server Base System Architecture document (ARM-DEN-0029)
specifies a generic UART device. The programmer's view of this
generic UART is a subset of the ARM PL011 UART. However, the
current PL011 driver in Trusted Firmware uses some features
that are outside the generic UART specification.
This patch modifies the PL011 driver to exclude features outside
the SBSA generic UART specification by setting the boolean build
option 'PL011_GENERIC_UART=1'. Default value is 0 (use full
PL011 features).
User guide updated.
FixesARM-software/tf-issues#216
Change-Id: I6e0eb86f9d69569bc3980fb57e70d6da5d91a737
This patch overrides the default weak definition of
`bl31_plat_runtime_setup()` for ARM Standard platforms to
specify a BL31 runtime console. ARM Standard platforms are
now expected to define `PLAT_ARM_BL31_RUN_UART_BASE` and
`PLAT_ARM_BL31_RUN_UART_CLK_IN_HZ` macros which is required
by `arm_bl31_plat_runtime_setup()` to initialize the runtime
console.
The system suspend resume helper `arm_system_pwr_domain_resume()`
is fixed to initialize the runtime console rather than the boot
console on resumption from system suspend.
FixesARM-software/tf-issues#220
Change-Id: I80eafe5b6adcfc7f1fdf8b99659aca1c64d96975
It is not ideal for BL31 to continue to use boot console at
runtime which could be potentially uninitialized. This patch
introduces a new optional platform porting API
`bl31_plat_runtime_setup()` which allows the platform to perform
any BL31 runtime setup just prior to BL31 exit during cold boot.
The default weak implementation of this function will invoke
`console_uninit()` which will suppress any BL31 runtime logs.
On the ARM Standard platforms, there is an anomaly that
the boot console will be reinitialized on resumption from
system suspend in `arm_system_pwr_domain_resume()`. This
will be resolved in the following patch.
NOTE: The default weak definition of `bl31_plat_runtime_setup()`
disables the BL31 console. To print the BL31 runtime
messages, platforms must override this API and initialize a
runtime console.
FixesARM-software/tf-issues#328
Change-Id: Ibaf8346fcceb447fe1a5674094c9f8eb4c09ac4a
On a GICv2 system, interrupts that should be handled in the secure world are
typically signalled as FIQs. On a GICv3 system, these interrupts are signalled
as IRQs instead. The mechanism for handling both types of interrupts is the same
in both cases. This patch enables the TSP to run on a GICv3 system by:
1. adding support for handling IRQs in the exception handling code.
2. removing use of "fiq" in the names of data structures, macros and functions.
The build option TSPD_ROUTE_IRQ_TO_EL3 is deprecated and is replaced with a
new build flag TSP_NS_INTR_ASYNC_PREEMPT. For compatibility reasons, if the
former build flag is defined, it will be used to define the value for the
new build flag. The documentation is also updated accordingly.
Change-Id: I1807d371f41c3656322dd259340a57649833065e
This patch adds watchdog support on ARM platforms (FVP and Juno).
A secure instance of SP805 is used as Trusted Watchdog. It is
entirely managed in BL1, being enabled in the early platform setup
hook and disabled in the exit hook. By default, the watchdog is
enabled in every build (even when TBB is disabled).
A new ARM platform specific build option `ARM_DISABLE_TRUSTED_WDOG`
has been introduced to allow the user to disable the watchdog at
build time. This feature may be used for testing or debugging
purposes.
Specific error handlers for Juno and FVP are also provided in this
patch. These handlers will be called after an image load or
authentication error. On FVP, the Table of Contents (ToC) in the FIP
is erased. On Juno, the corresponding error code is stored in the
V2M Non-Volatile flags register. In both cases, the CPU spins until
a watchdog reset is generated after 256 seconds (as specified in
the TBBR document).
Change-Id: I9ca11dcb0fe15af5dbc5407ab3cf05add962f4b4
The implications of the 'PROGRAMMABLE_RESET_ADDRESS' build option on
the platform porting layer are simple enough to be described in the
User Guide directly. This patch removes the reference to the Porting
Guide.
Change-Id: I7f753b18abd20effc4fd30836609e1fd51d9221d
This patch introduces a new build option named COLD_BOOT_SINGLE_CPU,
which allows platforms that only release a single CPU out of reset to
slightly optimise their cold boot code, both in terms of code size
and performance.
COLD_BOOT_SINGLE_CPU defaults to 0, which assumes that the platform
may release several CPUs out of reset. In this case, the cold reset
code needs to coordinate all CPUs via the usual primary/secondary
CPU distinction.
If a platform guarantees that only a single CPU will ever be released
out of reset, there is no need to arbitrate execution ; the notion of
primary and secondary CPUs itself no longer exists. Such platforms
may set COLD_BOOT_SINGLE_CPU to 1 in order to compile out the
primary/secondary CPU identification in the cold reset code.
All ARM standard platforms can release several CPUs out of reset
so they use COLD_BOOT_SINGLE_CPU=0. However, on CSS platforms like
Juno, bringing up more than one CPU at reset should only be attempted
when booting an EL3 payload, as it is not fully supported in the
normal boot flow.
For platforms using COLD_BOOT_SINGLE_CPU=1, the following 2 platform
APIs become optional:
- plat_secondary_cold_boot_setup();
- plat_is_my_cpu_primary().
The Porting Guide has been updated to reflect that.
User Guide updated as well.
Change-Id: Ic5b474e61b7aec1377d1e0b6925d17dfc376c46b
- Document the new build option EL3_PAYLOAD_BASE
- Document the EL3 payload boot flow
- Document the FVP model parameters to boot an EL3 payload
Change-Id: Ie6535914a9a68626e4401659bee4fcfd53d4bd37
Normally, in the FVP port, secondary CPUs are immediately powered
down if they are powered on at reset. However, when booting an EL3
payload, we need to keep them powered on as the requirement is for
all CPUs to enter the EL3 payload image. This patch puts them in a
holding pen instead of powering them off.
Change-Id: I6526a88b907a0ddb820bead72f1d350a99b1692c
This patch adds support for booting EL3 payloads on CSS platforms,
for example Juno. In this scenario, the Trusted Firmware follows
its normal boot flow up to the point where it would normally pass
control to the BL31 image. At this point, it jumps to the EL3
payload entry point address instead.
Before handing over to the EL3 payload, the data SCP writes for AP
at the beginning of the Trusted SRAM is restored, i.e. we zero the
first 128 bytes and restore the SCP Boot configuration. The latter
is saved before transferring the BL30 image to SCP and is restored
just after the transfer (in BL2). The goal is to make it appear that
the EL3 payload is the first piece of software to run on the target.
The BL31 entrypoint info structure is updated to make the primary
CPU jump to the EL3 payload instead of the BL31 image.
The mailbox is populated with the EL3 payload entrypoint address,
which releases the secondary CPUs out of their holding pen (if the
SCP has powered them on). The arm_program_trusted_mailbox() function
has been exported for this purpose.
The TZC-400 configuration in BL2 is simplified: it grants secure
access only to the whole DRAM. Other security initialization is
unchanged.
This alternative boot flow is disabled by default. A new build option
EL3_PAYLOAD_BASE has been introduced to enable it and provide the EL3
payload's entry point address. The build system has been modified
such that BL31 and BL33 are not compiled and/or not put in the FIP in
this case, as those images are not used in this boot flow.
Change-Id: Id2e26fa57988bbc32323a0effd022ab42f5b5077
This patch modifies the prototype of the bl1_plat_prepare_exit()
platform API to pass the address of the entry point info structure
received from BL2. The structure contains information that can be
useful, depending on the kind of clean up or bookkeeping operations
to perform.
The weak implementation of this function ignores this argument to
preserve platform backwards compatibility.
NOTE: THIS PATCH MAY BREAK PLATFORM PORTS THAT ARE RELYING ON THE
FORMER PROTOTYPE OF THE BL1_PLAT_PREPARE_EXIT() API.
Change-Id: I3fc18f637de06c85719c4ee84c85d6a4572a0fdb
This patch introduces a new build flag, SPIN_ON_BL1_EXIT, which
puts an infinite loop in BL1. It is intended to help debugging
the post-BL2 phase of the Trusted Firmware by stopping execution
in BL1 just before handing over to BL31. At this point, the
developer may take control of the target using a debugger.
This feature is disabled by default and can be enabled by
rebuilding BL1 with SPIN_ON_BL1_EXIT=1.
User Guide updated accordingly.
Change-Id: I6b6779d5949c9e5571dd371255520ef1ac39685c
The IMF_READ_INTERRUPT_ID build option enables a feature where the interrupt
ID of the highest priority pending interrupt is passed as a parameter to the
interrupt handler registered for that type of interrupt. This additional read
of highest pending interrupt id from GIC is problematic as it is possible that
the original interrupt may get deasserted and another interrupt of different
type maybe become the highest pending interrupt. Hence it is safer to prevent
such behaviour by removing the IMF_READ_INTERRUPT_ID build option.
The `id` parameter of the interrupt handler `interrupt_type_handler_t` is
now made a reserved parameter with this patch. It will always contain
INTR_ID_UNAVAILABLE.
FixesARM-software/tf-issues#307
Change-Id: I2173aae1dd37edad7ba6bdfb1a99868635fa34de
This patch changes the build time behaviour when using deprecated API within
Trusted Firmware. Previously the use of deprecated APIs would only trigger a
build warning (which was always treated as a build error), when
WARN_DEPRECATED = 1. Now, the use of deprecated C declarations will always
trigger a build time warning. Whether this warning is treated as error or not
is determined by the build flag ERROR_DEPRECATED which is disabled by default.
When the build flag ERROR_DEPRECATED=1, the invocation of deprecated API or
inclusion of deprecated headers will result in a build error.
Also the deprecated context management helpers in context_mgmt.c are now
conditionally compiled depending on the value of ERROR_DEPRECATED flag
so that the APIs themselves do not result in a build error when the
ERROR_DEPRECATED flag is set.
NOTE: Build systems that use the macro WARN_DEPRECATED must migrate to
using ERROR_DEPRECATED, otherwise deprecated API usage will no longer
trigger a build error.
Change-Id: I843bceef6bde979af7e9b51dddf861035ec7965a
This patch adds an optional API to the platform port:
void plat_error_handler(int err) __dead2;
The platform error handler is called when there is a specific error
condition after which Trusted Firmware cannot continue. While panic()
simply prints the crash report (if enabled) and spins, the platform
error handler can be used to hand control over to the platform port
so it can perform specific bookeeping or post-error actions (for
example, reset the system). This function must not return.
The parameter indicates the type of error using standard codes from
errno.h. Possible errors reported by the generic code are:
-EAUTH : a certificate or image could not be authenticated
(when Trusted Board Boot is enabled)
-ENOENT : the requested image or certificate could not be found
or an IO error was detected
-ENOMEM : resources exhausted. Trusted Firmware does not use
dynamic memory, so this error is usually an indication
of an incorrect array size
A default weak implementation of this function has been provided.
It simply implements an infinite loop.
Change-Id: Iffaf9eee82d037da6caa43b3aed51df555e597a3
This patch is a complete rework of the main Makefile. Functionality
remains the same but the code has been reorganized in sections in
order to improve readability and facilitate adding future extensions.
A new file 'build_macros.mk' has been created and will contain common
definitions (variables, macros, etc) that may be used from the main
Makefile and other platform specific makefiles.
A new macro 'FIP_ADD_IMG' has been introduced and it will allow the
platform to specify binary images and the necessary checks for a
successful build. Platforms that require a BL30 image no longer need
to specify the NEED_BL30 option. The main Makefile is now completely
unaware of additional images not built as part of Trusted Firmware,
like BL30. It is the platform responsibility to specify images using
the macro 'FIP_ADD_IMG'. Juno uses this macro to include the BL30
image in the build.
BL33 image is specified in the main Makefile to preserve backward
compatibility with the NEED_BL33 option. Otherwise, platform ports
that rely on the definition of NEED_BL33 might break.
All Trusted Board Boot related definitions have been moved to a
separate file 'tbbr_tools.mk'. The main Makefile will include this
file unless the platform indicates otherwise by setting the variable
'INCLUDE_TBBR_MK := 0' in the corresponding platform.mk file. This
will keep backward compatibility but ideally each platform should
include the corresponding TBB .mk file in platform.mk.
Change-Id: I35e7bc9930d38132412e950e20aa2a01e2b26801
This patch redefines the values of IO_FAIL, IO_NOT_SUPPORTED and
IO_RESOURCES_EXHAUSTED to match the corresponding definitions in
errno.h:
#define IO_FAIL (-ENOENT)
#define IO_NOT_SUPPORTED (-ENODEV)
#define IO_RESOURCES_EXHAUSTED (-ENOMEM)
NOTE: please note that the IO_FAIL, IO_NOT_SUPPORTED and
IO_RESOURCES_EXHAUSTED definitions are considered deprecated
and their usage should be avoided. Callers should rely on errno.h
definitions when checking the return values of IO functions.
Change-Id: Ic8491aa43384b6ee44951ebfc053a3ded16a80be
This patch adds an optional API to the platform port:
void bl1_plat_prepare_exit(void);
This function is called prior to exiting BL1 in response to the
RUN_IMAGE_SMC request raised by BL2. It should be used to perform
platform specific clean up or bookkeeping operations before
transferring control to the next image.
A weak empty definition of this function has been provided to
preserve platform backwards compatibility.
Change-Id: Iec09697de5c449ae84601403795cdb6aca166ba1
When a platform port does not define PLAT_PERCPU_BAKERY_LOCK_SIZE, the total
memory that should be allocated per-cpu to accommodate all bakery locks is
calculated by the linker in bl31.ld.S. The linker stores this value in the
__PERCPU_BAKERY_LOCK_SIZE__ linker symbol. The runtime value of this symbol is
different from the link time value as the symbol is relocated into the current
section (.bss). This patch fixes this issue by marking the symbol as ABSOLUTE
which allows it to retain its correct value even at runtime.
The description of PLAT_PERCPU_BAKERY_LOCK_SIZE in the porting-guide.md has been
made clearer as well.
Change-Id: Ia0cfd42f51deaf739d792297e60cad5c6e6e610b
This patch unifies the bakery lock api's across coherent and normal
memory implementation of locks by using same data type `bakery_lock_t`
and similar arguments to functions.
A separate section `bakery_lock` has been created and used to allocate
memory for bakery locks using `DEFINE_BAKERY_LOCK`. When locks are
allocated in normal memory, each lock for a core has to spread
across multiple cache lines. By using the total size allocated in a
separate cache line for a single core at compile time, the memory for
other core locks is allocated at link time by multiplying the single
core locks size with (PLATFORM_CORE_COUNT - 1). The normal memory lock
algorithm now uses lock address instead of the `id` in the per_cpu_data.
For locks allocated in coherent memory, it moves locks from
tzfw_coherent_memory to bakery_lock section.
The bakery locks are allocated as part of bss or in coherent memory
depending on usage of coherent memory. Both these regions are
initialised to zero as part of run_time_init before locks are used.
Hence, bakery_lock_init() is made an empty function as the lock memory
is already initialised to zero.
The above design lead to the removal of psci bakery locks from
non_cpu_power_pd_node to psci_locks.
NOTE: THE BAKERY LOCK API WHEN USE_COHERENT_MEM IS NOT SET HAS CHANGED.
THIS IS A BREAKING CHANGE FOR ALL PLATFORM PORTS THAT ALLOCATE BAKERY
LOCKS IN NORMAL MEMORY.
Change-Id: Ic3751c0066b8032dcbf9d88f1d4dc73d15f61d8b
ARM TF configures all interrupts as non-secure except those which
are present in irq_sec_array. This patch updates the irq_sec_array
with the missing secure interrupts for ARM platforms.
It also updates the documentation to be inline with the latest
implementation.
FixesARM-software/tf-issues#312
Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
This patch corrects some typos in the platform migration guide. More
importantly, the commit ID of the patch that implements migration of ARM
Reference platforms to the new platform API has been corrected.
Change-Id: Ib0109ea42c3d2bad2c6856ab725862652da7f3c8
This patch adds the necessary documentation updates to porting_guide.md
for the changes in the platform interface mandated as a result of the new
PSCI Topology and power state management frameworks. It also adds a
new document `platform-migration-guide.md` to aid the migration of existing
platform ports to the new API.
The patch fixes the implementation and callers of
plat_is_my_cpu_primary() to use w0 as the return parameter as implied by
the function signature rather than x0 which was used previously.
Change-Id: Ic11e73019188c8ba2bd64c47e1729ff5acdcdd5b
Since there is a unique warm reset entry point, the FVP and Juno
port can use a single mailbox instead of maintaining one per core.
The mailbox gets programmed only once when plat_setup_psci_ops()
is invoked during PSCI initialization. This means mailbox is not
zeroed out during wakeup.
Change-Id: Ieba032a90b43650f970f197340ebb0ce5548d432
This patch adds support to the Juno and FVP ports for composite power states
with both the original and extended state-id power-state formats. Both the
platform ports use the recommended state-id encoding as specified in
Section 6.5 of the PSCI specification (ARM DEN 0022C). The platform build flag
ARM_RECOM_STATE_ID_ENC is used to include this support.
By default, to maintain backwards compatibility, the original power state
parameter format is used and the state-id field is expected to be zero.
Change-Id: Ie721b961957eaecaca5bf417a30952fe0627ef10
This patch defines deprecated platform APIs to enable Trusted
Firmware components like Secure Payload and their dispatchers(SPD)
to continue to build and run when platform compatibility is disabled.
This decouples the migration of platform ports to the new platform API
from SPD and enables them to be migrated independently. The deprecated
platform APIs defined in this patch are : platform_get_core_pos(),
platform_get_stack() and platform_set_stack().
The patch also deprecates MPIDR based context management helpers like
cm_get_context_by_mpidr(), cm_set_context_by_mpidr() and cm_init_context().
A mechanism to deprecate APIs and identify callers of these APIs during
build is introduced, which is controlled by the build flag WARN_DEPRECATED.
If WARN_DEPRECATED is defined to 1, the users of the deprecated APIs will be
flagged either as a link error for assembly files or compile time warning
for C files during build.
Change-Id: Ib72c7d5dc956e1a74d2294a939205b200f055613
The state-id field in the power-state parameter of a CPU_SUSPEND call can be
used to describe composite power states specific to a platform. The current PSCI
implementation does not interpret the state-id field. It relies on the target
power level and the state type fields in the power-state parameter to perform
state coordination and power management operations. The framework introduced
in this patch allows the PSCI implementation to intepret generic global states
like RUN, RETENTION or OFF from the State-ID to make global state coordination
decisions and reduce the complexity of platform ports. It adds support to
involve the platform in state coordination which facilitates the use of
composite power states and improves the support for entering standby states
at multiple power domains.
The patch also includes support for extended state-id format for the power
state parameter as specified by PSCIv1.0.
The PSCI implementation now defines a generic representation of the power-state
parameter. It depends on the platform port to convert the power-state parameter
(possibly encoding a composite power state) passed in a CPU_SUSPEND call to this
representation via the `validate_power_state()` plat_psci_ops handler. It is an
array where each index corresponds to a power level. Each entry contains the
local power state the power domain at that power level could enter.
The meaning of the local power state values is platform defined, and may vary
between levels in a single platform. The PSCI implementation constrains the
values only so that it can classify the state as RUN, RETENTION or OFF as
required by the specification:
* zero means RUN
* all OFF state values at all levels must be higher than all RETENTION
state values at all levels
* the platform provides PLAT_MAX_RET_STATE and PLAT_MAX_OFF_STATE values
to the framework
The platform also must define the macros PLAT_MAX_RET_STATE and
PLAT_MAX_OFF_STATE which lets the PSCI implementation find out which power
domains have been requested to enter a retention or power down state. The PSCI
implementation does not interpret the local power states defined by the
platform. The only constraint is that the PLAT_MAX_RET_STATE <
PLAT_MAX_OFF_STATE.
For a power domain tree, the generic implementation maintains an array of local
power states. These are the states requested for each power domain by all the
cores contained within the domain. During a request to place multiple power
domains in a low power state, the platform is passed an array of requested
power-states for each power domain through the plat_get_target_pwr_state()
API. It coordinates amongst these states to determine a target local power
state for the power domain. A default weak implementation of this API is
provided in the platform layer which returns the minimum of the requested
power-states back to the PSCI state coordination.
Finally, the plat_psci_ops power management handlers are passed the target
local power states for each affected power domain using the generic
representation described above. The platform executes operations specific to
these target states.
The platform power management handler for placing a power domain in a standby
state (plat_pm_ops_t.pwr_domain_standby()) is now only used as a fast path for
placing a core power domain into a standby or retention state should now be
used to only place the core power domain in a standby or retention state.
The extended state-id power state format can be enabled by setting the
build flag PSCI_EXTENDED_STATE_ID=1 and it is disabled by default.
Change-Id: I9d4123d97e179529802c1f589baaa4101759d80c
This patch removes the assumption in the current PSCI implementation that MPIDR
based affinity levels map directly to levels in a power domain tree. This
enables PSCI generic code to support complex power domain topologies as
envisaged by PSCIv1.0 specification. The platform interface for querying
the power domain topology has been changed such that:
1. The generic PSCI code does not generate MPIDRs and use them to query the
platform about the number of power domains at a particular power level. The
platform now provides a description of the power domain tree on the SoC
through a data structure. The existing platform APIs to provide the same
information have been removed.
2. The linear indices returned by plat_core_pos_by_mpidr() and
plat_my_core_pos() are used to retrieve core power domain nodes from the
power domain tree. Power domains above the core level are accessed using a
'parent' field in the tree node descriptors.
The platform describes the power domain tree in an array of 'unsigned
char's. The first entry in the array specifies the number of power domains at
the highest power level implemented in the system. Each susbsequent entry
corresponds to a power domain and contains the number of power domains that are
its direct children. This array is exported to the generic PSCI implementation
via the new `plat_get_power_domain_tree_desc()` platform API.
The PSCI generic code uses this array to populate its internal power domain tree
using the Breadth First Search like algorithm. The tree is split into two
arrays:
1. An array that contains all the core power domain nodes
2. An array that contains all the other power domain nodes
A separate array for core nodes allows certain core specific optimisations to
be implemented e.g. remove the bakery lock, re-use per-cpu data framework for
storing some information.
Entries in the core power domain array are allocated such that the
array index of the domain is equal to the linear index returned by
plat_core_pos_by_mpidr() and plat_my_core_pos() for the MPIDR
corresponding to that domain. This relationship is key to be able to use
an MPIDR to find the corresponding core power domain node, traverse to higher
power domain nodes and index into arrays that contain core specific
information.
An introductory document has been added to briefly describe the new interface.
Change-Id: I4b444719e8e927ba391cae48a23558308447da13
This patch fixes a pair of typos. The security state had been described
as non-secure where it should have been secure.
Change-Id: Ib3f424708a6b8e2084e5447f8507ea4e9c99ee79
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.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
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.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
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.
Tested by booting TLK without the NEED_BL32 flag.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch implements support for T132 (Denver CPU) based Tegra
platforms.
The following features have been added:
* SiP calls to switch T132 CPU's AARCH mode
* Complete PSCI support, including 'System Suspend'
* Platform specific MMIO settings
* Locking of CPU vector registers
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
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.
Change-Id: Ia8bd043f4b74f1e1b10ef0d12cc8a56ed3c92b6e
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.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
This patch updates the user guide, adding instructions to build the
Trusted Firmware with Trusted Board Support using the new framework.
It also provides documentation about the framework itself, including
a detailed section about the TBBR implementation using the framework.
Change-Id: I0849fce9c5294cd4f52981e7a8423007ac348ec6
The authentication framework deprecates plat_match_rotpk()
in favour of plat_get_rotpk_info(). This patch removes
plat_match_rotpk() from the platform port.
Change-Id: I2250463923d3ef15496f9c39678b01ee4b33883b
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.
REMOVED BUILD OPTIONS:
* 'AUTH_MOD'
Change-Id: I47d436589fc213a39edf5f5297bbd955f15ae867
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
}
In case the platform returns a hash of the key:
DigestInfo ::= SEQUENCE {
digestAlgorithm AlgorithmIdentifier,
keyDigest OCTET 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.
Change-Id: Ib25862e5507d1438da10773e62bd338da8f360bf
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.
Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
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.
Documentation updated accordingly.
Change-Id: I67ab1c2b1f8a25793f0de95e8620ce7596a6bc3b
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().
Change-Id: Ib6bf10809cb4e9b92f463755608889aedd83cef5
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.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
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.
FixesARM-software/tf-issues#308
Change-Id: Ica8cb72c0c5e8b3503f60b5357d16698e869b1bd
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.
Change-Id: If59c3b11fb1f692976e1d8b96c7e2da0ebfba308
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.
Change-Id: If5ecd74d75bee700b1bd718d23d7556b8f863546
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.
Change-Id: Ie5c17dbbd0932f5fa3b446efc6e590798a5beae2
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.
Change-Id: Idf1bdeb24d2e1947adfbb76a509f10beef224e1c
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.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
There has been a breaking change in the communication protocols used
between the AP cores and the SCP on CSS based platforms like Juno.
This means both the AP Trusted Firmware and SCP firmware must be
updated at the same time.
In case the user forgets to update the SCP ROM firmware, this patch
detects when it still uses the previous version of the communication
protocol. It will then output a comprehensive error message that helps
trouble-shoot the issue.
Change-Id: I7baf8f05ec0b7d8df25e0ee53df61fe7be0207c2
Update the User Guide, Porting Guide and Firmware Design documents
to align them with the recent changes made to the FVP and Juno
platform ports.
Also fix some other historical inaccuracies.
Change-Id: I37aba4805f9044b1a047996d3e396c75f4a09176
Include TLK Dispatcher's documentation and add NVIDIA to the
Acknowledgements file. TLK is now a supported Trusted OS with
the Trusted Firmware.
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
