2016-07-08 |
Introduce SEPARATE_CODE_AND_RODATA build flag
...
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
Sandrine Bailleux
committed
on 8 Jul 2016
|
BL1: Add linker symbol identifying end of ROM content
...
This patch adds a new linker symbol in BL1's linker script named
'__BL1_ROM_END__', which marks the end of BL1's ROM content. This
covers BL1's code, read-only data and read-write data to relocate
in Trusted SRAM. The address of this new linker symbol is exported
to C code through the 'BL1_ROM_END' macro.
The section related to linker symbols in the Firmware Design guide
has been updated and improved.
Change-Id: I5c442ff497c78d865ffba1d7d044511c134e11c7
Sandrine Bailleux
committed
on 8 Jul 2016
|
2016-06-16 |
Add optional PSCI STAT residency & count functions
...
This patch adds following optional PSCI STAT functions:
- PSCI_STAT_RESIDENCY: This call returns the amount of time spent
in power_state in microseconds, by the node represented by the
`target_cpu` and the highest level of `power_state`.
- PSCI_STAT_COUNT: This call returns the number of times a
`power_state` has been used by the node represented by the
`target_cpu` and the highest power level of `power_state`.
These APIs provides residency statistics for power states that has
been used by the platform. They are implemented according to v1.0
of the PSCI specification.
By default this optional feature is disabled in the PSCI
implementation. To enable it, set the boolean flag
`ENABLE_PSCI_STAT` to 1. This also sets `ENABLE_PMF` to 1.
Change-Id: Ie62e9d37d6d416ccb1813acd7f616d1ddd3e8aff
Yatharth Kochar
authored
on 9 May 2016
Soby Mathew
committed
on 16 Jun 2016
|
2016-04-07 |
Enable SCR_EL3.SIF bit
...
This patch enables the SCR_EL3.SIF (Secure Instruction Fetch) bit in BL1 and
BL31 common architectural setup code. When in secure state, this disables
instruction fetches from Non-secure memory.
NOTE: THIS COULD BREAK PLATFORMS THAT HAVE SECURE WORLD CODE EXECUTING FROM
NON-SECURE MEMORY, BUT THIS IS CONSIDERED UNLIKELY AND IS A SERIOUS SECURITY
RISK.
Fixes ARM-Software/tf-issues#372
Change-Id: I684e84b8d523c3b246e9a5fabfa085b6405df319
Soby Mathew
committed
on 7 Apr 2016
|
2016-03-30 |
Enable asynchronous abort exceptions during boot
...
Asynchronous abort exceptions generated by the platform during cold boot are
not taken in EL3 unless SCR_EL3.EA is set.
Therefore EA bit is set along with RES1 bits in early BL1 and BL31 architecture
initialisation. Further write accesses to SCR_EL3 preserve these bits during
cold boot.
A build flag controls SCR_EL3.EA value to keep asynchronous abort exceptions
being trapped by EL3 after cold boot or not.
For further reference SError Interrupts are also known as asynchronous external
aborts.
On Cortex-A53 revisions below r0p2, asynchronous abort exceptions are taken in
EL3 whatever the SCR_EL3.EA value is.
Fixes arm-software/tf-issues#368
Signed-off-by: Gerald Lejeune <gerald.lejeune@st.com>
Gerald Lejeune
committed
on 30 Mar 2016
|
2016-03-22 |
Simplify Firmware Design document
...
The Firmware Design document is meant to provide a general overview
of the Trusted Firmware code. Although it is useful to provide some
guidance around the responsibilities of the platform layer, it should
not provide too much platform specific implementation details. Right
now, some sections are too tied to the implementation on ARM
platforms. This makes the Firmware Design document harder to digest.
This patch simplifies this aspect of the Firmware Design document.
The sections relating the platform initialisations performed by the
different BL stages have been simplified and the extra details about
the ARM platforms implementation have been moved to the Porting Guide
when appropriate.
This patch also provides various documentation fixes and additions
in the Firmware Design and Platform Porting Guide. In particular:
- Update list of SMCs supported by BL1.
- Remove MMU setup from architectural inits, as it is actually
performed by platform code.
- Similarly, move runtime services initialisation, BL2 image
initialization and BL33 execution out of the platform
initialisation paragraph.
- List SError interrupt unmasking as part of BL1 architectural
initialization.
- Mention Trusted Watchdog enabling in BL1 on ARM platforms.
- Fix order of steps in "BL2 image load and execution" section.
- Refresh section about GICv3/GICv2 drivers initialisation on
ARM platforms.
Change-Id: I32113c4ffdc26687042629cd8bbdbb34d91e3c14
Sandrine Bailleux
committed
on 22 Mar 2016
|
2016-02-01 |
Improve memory layout documentation
...
This patch adds a brief explanation of the top/bottom load approach
to the Firmware Design guide and how Trusted Firmware keeps track of
the free memory at boot time. This will help platform developers to
avoid unexpected results in the memory layout.
Fixes ARM-software/tf-issues#319
Change-Id: I04be7e24c1f3b54d28cac29701c24bf51a5c00ad
Juan Castillo
committed
on 1 Feb 2016
|
2016-01-15 |
Doc: Update out-dated info about Juno's mailbox
...
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
Sandrine Bailleux
committed
on 15 Jan 2016
|
2016-01-12 |
Documentation: Fix broken links in ToCs
...
Change-Id: I4fcdb8e813e0392c2cd3d0623698e8319b3b0593
Sandrine Bailleux
committed
on 12 Jan 2016
|
2016-01-08 |
Fixes in CPU specific operations framework doc
...
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
Sandrine Bailleux
committed
on 8 Jan 2016
|
2015-12-21 |
Miscellaneous doc fixes for v1.2
...
Change-Id: I6f49bd779f2a4d577c6443dd160290656cdbc59b
Sandrine Bailleux
authored
on 17 Dec 2015
Dan Handley
committed
on 21 Dec 2015
|
2015-12-17 |
Merge pull request #472 from danh-arm/dh/fwu-docs
...
FWU: Add documentation for Firmware Update feature
danh-arm
committed
on 17 Dec 2015
|
FWU: Add documentation for Firmware Update feature
...
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>
Yatharth Kochar
authored
on 27 Oct 2015
Dan Handley
committed
on 17 Dec 2015
|
2015-12-15 |
Introduce the ARM TF reset design document
...
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
Sandrine Bailleux
committed
on 15 Dec 2015
|
2015-12-14 |
Remove dashes from image names: 'BL3-x' --> 'BL3x'
...
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
Juan Castillo
committed
on 14 Dec 2015
|
Replace all SCP FW (BL0, BL3-0) references
...
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
Juan Castillo
committed
on 14 Dec 2015
|
2015-09-11 |
Re-design bakery lock memory allocation and algorithm
...
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
Andrew Thoelke
authored
on 10 Sep 2015
Vikram Kanigiri
committed
on 11 Sep 2015
|
2015-09-01 |
Configure all secure interrupts on ARM platforms
...
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.
Fixes ARM-software/tf-issues#312
Change-Id: I39956c56a319086e3929d1fa89030b4ec4b01fcc
Vikram Kanigiri
committed
on 1 Sep 2015
|
2015-07-02 |
Merge pull request #324 from soby-mathew/sm/sys_suspend
...
PSCI: Add SYSTEM_SUSPEND API support
danh-arm
committed
on 2 Jul 2015
|
2015-06-22 |
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().
Change-Id: Ib6bf10809cb4e9b92f463755608889aedd83cef5
Soby Mathew
committed
on 22 Jun 2015
|
2015-06-04 |
Rationalize reset handling code
...
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
Sandrine Bailleux
committed
on 4 Jun 2015
|
Remove FIRST_RESET_HANDLER_CALL build option
...
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
Sandrine Bailleux
committed
on 4 Jun 2015
|
2015-06-01 |
Always enable CCI coherency in BL3-1
...
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
Sandrine Bailleux
committed
on 1 Jun 2015
|
2015-04-28 |
Doc updates following platform port reorganization
...
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
Dan Handley
committed
on 28 Apr 2015
|
2015-02-03 |
Merge pull request #254 from achingupta/ag/v1.1-doc-updates
...
Documentation for version 1.1
danh-arm
committed
on 3 Feb 2015
|
Documentation for version 1.1
...
Final updates to readme.md and change-log.md for ARM Trusted Firmware version
1.1. Also increment the version in the Makefile.
Change-Id: Ib001a6ec9a9c570985841d06f0ff80ed76c2996b
Achin Gupta
committed
on 3 Feb 2015
|
2015-02-02 |
Miscellaneous doc fixes for v1.1
...
Change-Id: Iaf9d6305edc478d39cf1b37c8a70ccdf723e8ef9
Sandrine Bailleux
committed
on 2 Feb 2015
|
2015-01-30 |
Fix the Cortex-A57 reset handler register usage
...
The CPU specific reset handlers no longer have the freedom
of using any general purpose register because it is being invoked
by the BL3-1 entry point in addition to BL1. The Cortex-A57 CPU
specific reset handler was overwriting x20 register which was being
used by the BL3-1 entry point to save the entry point information.
This patch fixes this bug by reworking the register allocation in the
Cortex-A57 reset handler to avoid using x20. The patch also
explicitly mentions the register clobber list for each of the
callee functions invoked by the reset handler
Change-Id: I28fcff8e742aeed883eaec8f6c4ee2bd3fce30df
Soby Mathew
committed
on 30 Jan 2015
|
2015-01-28 |
Merge pull request #248 from jcastillo-arm/jc/tf-issues/212_1
...
Allow BL3-2 to be loaded into the secure region of DRAM
danh-arm
committed
on 28 Jan 2015
|
2015-01-26 |
Call reset handlers upon BL3-1 entry.
...
This patch adds support to call the reset_handler() function in BL3-1 in the
cold and warm boot paths when another Boot ROM reset_handler() has already run.
This means the BL1 and BL3-1 versions of the CPU and platform specific reset
handlers may execute different code to each other. This enables a developer to
perform additional actions or undo actions already performed during the first
call of the reset handlers e.g. apply additional errata workarounds.
Typically, the reset handler will be first called from the BL1 Boot ROM. Any
additional functionality can be added to the reset handler when it is called
from BL3-1 resident in RW memory. The constant FIRST_RESET_HANDLER_CALL is used
to identify whether this is the first version of the reset handler code to be
executed or an overridden version of the code.
The Cortex-A57 errata workarounds are applied only if they have not already been
applied.
Fixes ARM-software/tf-issue#275
Change-Id: Id295f106e4fda23d6736debdade2ac7f2a9a9053
Yatharth Kochar
authored
on 20 Nov 2014
Achin Gupta
committed
on 26 Jan 2015
|