| e6a993d4 | 02-Jun-2017 |
Haojian Zhuang <haojian.zhuang@linaro.org> |
stdlib: support AARCH32 in endian head file
Add the support of AARCH32 in endian head file. The code is also
imported from FreeBSD 11.0. It's based on commit in below.
commit 4e3a5b429989b4ff621682
stdlib: support AARCH32 in endian head file
Add the support of AARCH32 in endian head file. The code is also
imported from FreeBSD 11.0. It's based on commit in below.
commit 4e3a5b429989b4ff621682ff1462f801237bd551
Author: mmel <mmel@FreeBSD.org>
Date: Tue Nov 10 12:02:41 2015 +0000
ARM: Remove trailing whitespace from sys/arm/include
No functional changes.
Approved by: kib (mentor)
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
show more ...
|
| 2a6c1a8f | 08-May-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
fip: move headers shared between TF and fiptool to include/tools_share
Some header files need to be shared between TF and host programs.
For fiptool, two headers are copied to the tools/fiptool dire
fip: move headers shared between TF and fiptool to include/tools_share
Some header files need to be shared between TF and host programs.
For fiptool, two headers are copied to the tools/fiptool directory,
but it looks clumsy.
This commit introduces a new directory, include/tools_share, which
collects headers that should be shared between TF and host programs.
This will clarify the interface exposed to host tools. We should
add new headers to this directory only when we really need to do so.
For clarification, I inserted a blank line between headers from the
include/ directory (#include <...>) and ones from a local directory
(#include "..." ).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| 0da2fe7e | 16-May-2017 |
Antonio Nino Diaz <antonio.ninodiaz@arm.com> |
Simplify assert() to reduce memory usage
The behaviour of assert() now depends on the value of the new optional
platform define `PLAT_LOG_LEVEL_ASSERT`. This defaults to `LOG_LEVEL` if
not defined b
Simplify assert() to reduce memory usage
The behaviour of assert() now depends on the value of the new optional
platform define `PLAT_LOG_LEVEL_ASSERT`. This defaults to `LOG_LEVEL` if
not defined by the platform.
- If `PLAT_LOG_LEVEL_ASSERT` >= `LOG_LEVEL_VERBOSE`, it prints the file
name, line and asserted expression.
- If `PLAT_LOG_LEVEL_ASSERT` >= `LOG_LEVEL_INFO`, it prints the file
name and line.
- If not, it doesn't print anything.
Note the old behaviour was to print the function name whereas now it
prints the file name. This reduces memory usage because the file name is
shared between all assert calls in a given file. Also, the default
behaviour in debug builds is to no longer print the asserted expression,
greatly reducing the string usage.
For FVP debug builds this change saves approximately:
No TBBR TBBR
BL1 1.6 KB 2.2 KB
BL2 1.7 KB 2.1 KB
BL31 2.6 KB 3.3 KB
Change-Id: I2947569d593df0b25611dc3c7a6096f42155c115
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
show more ...
|
| b6285d64 | 30-Mar-2017 |
Soby Mathew <soby.mathew@arm.com> |
AArch32: Rework SMC context save and restore mechanism
The current SMC context data structure `smc_ctx_t` and related helpers are
optimized for case when SMC call does not result in world switch. Th
AArch32: Rework SMC context save and restore mechanism
The current SMC context data structure `smc_ctx_t` and related helpers are
optimized for case when SMC call does not result in world switch. This was
the case for SP_MIN and BL1 cold boot flow. But the firmware update usecase
requires world switch as a result of SMC and the current SMC context helpers
were not helping very much in this regard. Therefore this patch does the
following changes to improve this:
1. Add monitor stack pointer, `spmon` to `smc_ctx_t`
The C Runtime stack pointer in monitor mode, `sp_mon` is added to the
SMC context, and the `smc_ctx_t` pointer is cached in `sp_mon` prior
to exit from Monitor mode. This makes is easier to retrieve the
context when the next SMC call happens. As a result of this change,
the SMC context helpers no longer depend on the stack to save and
restore the register.
This aligns it with the context save and restore mechanism in AArch64.
2. Add SCR in `smc_ctx_t`
Adding the SCR register to `smc_ctx_t` makes it easier to manage this
register state when switching between non secure and secure world as a
result of an SMC call.
Change-Id: I5e12a7056107c1701b457b8f7363fdbf892230bf
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
show more ...
|
| b10d4499 | 16-Feb-2017 |
Jeenu Viswambharan <jeenu.viswambharan@arm.com> |
Introduce ARM SiP service to switch execution state
In AArch64, privileged exception levels control the execution state
(a.k.a. register width) of the immediate lower Exception Level; i.e.
whether t
Introduce ARM SiP service to switch execution state
In AArch64, privileged exception levels control the execution state
(a.k.a. register width) of the immediate lower Exception Level; i.e.
whether the lower exception level executes in AArch64 or AArch32 state.
For an exception level to have its execution state changed at run time,
it must request the change by raising a synchronous exception to the
higher exception level.
This patch implements and adds such a provision to the ARM SiP service,
by which an immediate lower exception level can request to switch its
execution state. The execution state is switched if the request is:
- raised from non-secure world;
- raised on the primary CPU, before any secondaries are brought online
with CPU_ON PSCI call;
- raised from an exception level immediately below EL3: EL2, if
implemented; otherwise NS EL1.
If successful, the SMC doesn't return to the caller, but to the entry
point supplied with the call. Otherwise, the caller will observe the SMC
returning with STATE_SW_E_DENIED code. If ARM Trusted Firmware is built
for AArch32, the feature is not supported, and the call will always
fail.
For the ARM SiP service:
- Add SMC function IDs for both AArch32 and AArch64;
- Increment the SiP service minor version to 2;
- Adjust the number of supported SiP service calls.
Add documentation for ARM SiP service.
Fixes ARM-software/tf-issues#436
Change-Id: I4347f2d6232e69fbfbe333b340fcd0caed0a4cea
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
show more ...
|
| a5640252 | 27-Apr-2017 |
Antonio Nino Diaz <antonio.ninodiaz@arm.com> |
Fix execute-never permissions in xlat tables libs
Translation regimes that only support one virtual address space (such as
the ones for EL2 and EL3) can flag memory regions as execute-never by
setti
Fix execute-never permissions in xlat tables libs
Translation regimes that only support one virtual address space (such as
the ones for EL2 and EL3) can flag memory regions as execute-never by
setting to 1 the XN bit in the Upper Attributes field in the translation
tables descriptors. Translation regimes that support two different
virtual address spaces (such as the one shared by EL1 and EL0) use bits
PXN and UXN instead.
The Trusted Firmware runs at EL3 and EL1, it has to handle translation
tables of both translation regimes, but the previous code handled both
regimes the same way, as if both had only 1 VA range.
When trying to set a descriptor as execute-never it would set the XN
bit correctly in EL3, but it would set the XN bit in EL1 as well. XN is
at the same bit position as UXN, which means that EL0 was being
prevented from executing code at this region, not EL1 as the code
intended. Therefore, the PXN bit was unset to 0 all the time. The result
is that, in AArch64 mode, read-only data sections of BL2 weren't
protected from being executed.
This patch adds support of translation regimes with two virtual address
spaces to both versions of the translation tables library, fixing the
execute-never permissions for translation tables in EL1.
The library currently does not support initializing translation tables
for EL0 software, therefore it does not set/unset the UXN bit. If EL1
software needs to initialize translation tables for EL0 software, it
should use a different library instead.
Change-Id: If27588f9820ff42988851d90dc92801c8ecbe0c9
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
show more ...
|
| 16292f54 | 05-Apr-2017 |
David Cunado <david.cunado@arm.com> |
Update terminology: standard SMC to yielding SMC
Since Issue B (November 2016) of the SMC Calling Convention document
standard SMC calls are renamed to yielding SMC calls to help avoid
confusion wit
Update terminology: standard SMC to yielding SMC
Since Issue B (November 2016) of the SMC Calling Convention document
standard SMC calls are renamed to yielding SMC calls to help avoid
confusion with the standard service SMC range, which remains unchanged.
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf
This patch adds a new define for yielding SMC call type and deprecates
the current standard SMC call type. The tsp is migrated to use this new
terminology and, additionally, the documentation and code comments are
updated to use this new terminology.
Change-Id: I0d7cc0224667ee6c050af976745f18c55906a793
Signed-off-by: David Cunado <david.cunado@arm.com>
show more ...
|