Tegra platforms were using the v2 xlat_tables implementation in
common/tegra_common.mk, but v1 xlat_tables.h headers in soc/*/plat_setup.c
where arrays are being defined. This caused the next physical address to
be read as granularity, causing EINVAL error and triggering an assert.
Consistently use xlat_tables_v2.h header to avoid this.
This fixes all defects according to MISRA Rule 3.1: "The character
sequences /* and // shall not be used within a comment". This affects
all URLs in comments, so they have been removed:
- The link in `sdei_state.c` can also be found in the documentation file
`docs/sdei.rst`.
- The bug that the file `io_fip.c` talks about doesn't affect the
currently supported version of GCC, so it doesn't make sense to keep
the comment. Note that the version of GCC officially supported is the
one that comes with Linaro Release 17.10, which is GCC 6.2.
- The link in `tzc400.c` was broken, and it didn't correctly direct to
the Technical Reference Manual it should. The link has been replaced
by the title of the document, which is more convenient when looking
for the document.
Change-Id: I89f60c25f635fd4c008a5d3a14028f814c147bbe Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The console core flush API expects the base address in the first
register, but ARM helpers currently sets the second register with the
base address. This causes an assert failure.
TSPD: Require NS preemption along with EL3 exception handling
At present, the build option TSP_NS_INTR_ASYNC_PREEMPT controls how
Non-secure interrupt affects TSPs execution. When TSP is executing:
1. When TSP_NS_INTR_ASYNC_PREEMPT=0, Non-secure interrupts are received
at the TSP's exception vector, and TSP voluntarily preempts itself.
2. When TSP_NS_INTR_ASYNC_PREEMPT=1, Non-secure interrupts causes a
trap to EL3, which preempts TSP execution.
When EL3 exception handling is in place (i.e.,
EL3_EXCEPTION_HANDLING=1), FIQs are always trapped to EL3. On a system
with GICv3, pending NS interrupts while TSP is executing will be
signalled as FIQ (which traps to EL3). This situation necessitates the
same treatment applied to case (2) above.
Therefore, when EL3 exception handling is in place, additionally
require that TSP_NS_INTR_ASYNC_PREEMPT is set to one 1.
Strictly speaking, this is not required on a system with GICv2, but the
same model is uniformly followed regardless, for simplicity.
TSPD: Explicitly allow NS preemption for Yielding SMCs
When EL3 exception handling is in effect (i.e.,
EL3_EXCEPTION_HANDLING=1), Non-secure interrupts can't preempt Secure
execution. However, for yielding SMCs, preemption by Non-secure
interupts is intended.
This patch therefore adds a call to ehf_allow_ns_preemption() before
dispatching a Yielding SMC to TSP.
Deprecate one EL3 interrupt routing model with EL3 exception handling
When ARM Trusted Firmware is built with EL3_EXCEPTION_HANDLING=1,
EL3 interrupts (INTR_TYPE_EL3) will always preempt both Non-secure and
secure execution.
The interrupt management framework currently treats EL3 interrupt
routing as valid. For the above reason, this patch makes them invalid
when EL3_EXCEPTION_HANDLING is in effect.
Commit 21b818c05fa4ec8cec468aad690267c5be930ccd (BL31: Introduce
Exception Handling Framework) introduced the build option
EL3_EXCEPTION_HANDLING, but missed to pass that to the build command
line. This patch fixes that.
Define Qemu AArch32 implementation for some platform functions
(core position, secondary boot cores, crash console). These are
derived from the AArch64 implementation.
BL31 on Qemu is needed only for ARMv8 and later. On ARMv7, BL32 is
the first executable image after BL2.
Support SP_MIN and OP-TEE as BL32: create a sp_min make script target
in Qemu, define mapping for IMAGE_BL32
Minor fix Qemu return value type for plat_get_ns_image_entrypoint().
Qemu model for the Cortex-A15 does not support the virtualization
extension although the core expects it. To overcome the issue, Qemu
ARMv7 configuration set ARCH_SUPPORTS_VIRTUALIZATION to 0.
Add missing AArch32 assembly macro arm_print_gic_regs from ARM platform
used by the Qemu platform.
Qemu Cortex-A15 model integrates a single cluster with up to 4 cores.
AArch32 only platforms can boot the OP-TEE secure firmware as
a BL32 secure payload. Such configuration can be defined through
AARCH32_SP=optee.
The source files can rely on AARCH32_SP_OPTEE to condition
OP-TEE boot specific instruction sequences.
OP-TEE does not expect ARM Trusted Firmware formatted structure
as boot argument. Load sequence is expected to have already loaded
to OP-TEE boot arguments into the bl32 entrypoint info structure.
Last, AArch32 platform can only boot AArch32 OP-TEE images.
Masahiro Yamada [Tue, 30 Jan 2018 10:30:39 +0000 (19:30 +0900)]
uniphier: allocate xlat region of on-chip SRAM only when needed
Currently, the xlat region of the on-chip SRAM is always allocated
for all BL images.
The access to the on-chip SRAM is necessary for loading images from
a USB memory device (i.e. when updating firmware), so unneeded for
the usual boot procedure.
To avoid this waste, allocate the xlat region dynamically only for
BL2, and only when it is necessary.
Masahiro Yamada [Tue, 30 Jan 2018 09:49:37 +0000 (18:49 +0900)]
uniphier: get back original BL31/32 location used before BL2-AT-EL3
Commit 247fc0435191 ("uniphier: switch to BL2-AT-EL3 and remove BL1
support") accidentally changed the location of BL31 and BL32. The
new memory map overlaps with the audio DSP images, also gives impact
to OP-TEE. They are both out of control of ARM Trusted Firmware, so
not easy to change. This commit restores the image layout that was
originally used prior to the BL2-AT-EL3 migration.
Masahiro Yamada [Thu, 1 Feb 2018 12:37:40 +0000 (21:37 +0900)]
uniphier: add a helper to get image_info
In the next commit, I will have more usecases to get struct image_info
from image ID. It is better to make a helper function at a different
layer. I do not need the current uniphier_image_descs_fixup() since
the code is small enough to be squashed into the caller side.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
image_decompress: add APIs for decompressing images
These APIs are used by platforms that need to decompress images.
image_decompress_init():
This registers a temporary buffer and a decompressor callback.
This should be called from platform init code.
image_decompress_prepare():
This should be called before each compressed image is loaded. The
best location to call this will be bl*_plat_handle_pre_image_load().
image_decompress():
This should be called after each compressed image is loaded. The
best location to call this will be bl*_plat_handle_post_image_load().
Masahiro Yamada [Thu, 1 Feb 2018 07:45:51 +0000 (16:45 +0900)]
bl2: add bl2_plat_handle_pre_image_load()
There are cases where we need to manipulate image information before
the load. For example, for decompressing data, we cannot load the
compressed images to their final destination. Instead, we need to
load them to the temporary buffer for the decompressor.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
zlib: add gunzip() support
This commit adds some more files to use zlib from TF.
To use zlib, ->zalloc and ->zfree hooks are needed. The implementation
depends on the system. For user-space, the libc provides malloc() and
friends. Unfortunately, ARM Trusted Firmware does not provide malloc()
or any concept of dynamic memory allocation.
I implemented very simple calloc() and free() for this. Stupidly,
zfree() never frees memory, but it works enough for this.
The purpose of using zlib is to implement gunzip() - this function
takes compressed data from in_buf, then dumps the decompressed data
to oub_buf. The work_buf is used for memory allocation during the
decompress. Upon exit, it updates in_buf and out_buf. If successful,
in_buf points to the end of input data, out_buf to the end of the
decompressed data.
The original tarball is available from http://zlib.net/
The zlib is free software, distributed under the zlib license. The
license text is included in the "zlib.h" file. It should be compatible
with BSD-3-Clause.
The zlib license is included in the SPDX license list available at
https://spdx.org/licenses/, but I did not add the SPDX license tag to
the imported files above, to keep them as they are in the upstream
project. This seems the general policy for ARM Trusted Firmware, as
SPDX License Identifier was not added to files imported from FreeBSD.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
Build: add GZIP compression filter
One typical usage of the pre-tool image filter is data compression,
and GZIP is one of the most commonly used compression methods.
I guess this is generic enough to be put in the common script instead
of platform.mk.
If you want to use this, you can add something like follows to your
platform.mk:
Masahiro Yamada [Thu, 1 Feb 2018 07:31:09 +0000 (16:31 +0900)]
Build: support pre-tool image processing
There are cases where we want to process images before they are
passed to cert_create / fiptool.
My main motivation is data compression. By compressing images, we can
save data storage, and possibly speed up loading images. The image
verification will also get faster because certificates are generated
based on compressed images.
Other image transformation filters (for ex. encryption), and their
combinations would be possible. So, our build system should support
transformation filters in a generic manner.
The choice of applied filters is up to platforms (so specified in
platform.mk)
To define a new filter, <FILTER_NAME>_RULE and <FILTER_NAME>_SUFFIX
are needed.
For example, the GZIP compression filter can be implemented as follows:
The _RULE defines how to create the target $(1) from the source $(2).
The _SUFFIX defines the extension appended to the processed image path.
The suffix is not so important because the file name information is not
propagated to FIP, but adding a sensible suffix will be good to classify
the data file.
Platforms can specify which filter is applied to which BL image, like
this:
<IMAGE_NAME>_PRE_TOOL_FILTER specifies per-image filter. With this,
different images can be transformed differently. For the case above,
only BL32 and BL33 are GZIP-compressed. Nothing is done for other
images.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
Build: change the first parameter of TOOL_ADD_IMG to lowercase
In the next commit, I need the image name in lowercase because
output files are generally named in lowercase.
Unfortunately, TOOL_ADD_IMG takes the first argument in uppercase
since we generally use uppercase Make variables.
make_helpers/build_macros.mk provides 'uppercase' macro to convert
a string into uppercase, but 'lowercase' does not exist. We can
implement it if we like, but it would be more straightforward to
change the argument of TOOL_ADD_IMG.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
Build: remove third argument of CERT_ADD_CMD_OPT
The third argument was given "true" by images, but it was moved
to TOOL_ADD_PAYLOAD. No more caller of CERT_ADD_CMD_OPT uses this.
So, the third argument is always empty. Remove it.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
Build: move cert_create arguments and dependency to FIP_ADD_PAYLOAD
The fiptool and cert_create use the same command options for images.
It is pretty easy to handle both in the same, symmetrical way.
Move CRT_ARGS and CRT_DEPS to FIP_ADD_PAYLOAD. This refactoring makes
sense because FIP_ADD_PAYLOAD is called from MAKE_BL (when building
images from source), and from FIP_ADD_IMG (when including external
images). (FIP_ADD_PAYLOAD will be renamed later on since it now
caters to both fiptool and cert_create).
We can delete CERT_ADD_CMD_OPT for images in tbbr.mk. It still
needs to call CERT_ADD_CMD_OPT directly for certificates.
The duplicated code increases the maintenance burden. Also, the build
rule of BL2U looks clumsy - we want to call MAKE_BL to compile it from
source files, but we want to put it in fwu_fip. We can not do it in a
single macro call since the current MAKE_BL does not support fwu_fip.
To refactor those in a clean way is to support one more argument to
specify the FIP prefix. If it is empty, the images are targeted to
fip, whereas if the argument is "FWU_", targeted to fwu_fip.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
Build: refactor BL32 build rules
This complicated if-conditional combo was introduced by commit 70d1fc5383b9 ("Fix build error when `BL32` is not defined") in order
to fix the compile error of "make all" when SPD=opteed is given.
The requirement for the build system is like follows:
- If both BL32 and BL32_SOURCES are defined, the former takes
precedence.
- If BL32 is undefined but BL32_SOURCES is defined, we compile
BL32 from the source files.
- We want to let the build fail if neither of them is defined,
but we want to check it only when we are building FIP.
Refactor the code to not call FIP_ADD_IMG twice. The behavior is
still the same.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
Build: replace $(call MAKE_TOOL_ARGS,...) with $(call FIP_ADD_IMG,...)
We use $(call MAKE_TOOL_ARGS,...) or $(call FIP_ADD_IMG,...) where we
expect externally built images. The difference between the two is
check_* target. It now checks if the given path exists, so it is a
good thing to use $(call FIP_ADD_IMG,...) in all the places.
Masahiro Yamada [Fri, 26 Jan 2018 02:42:01 +0000 (11:42 +0900)]
Build: check if specified external image exists
check_* targets check if the required option are given, but do not
check the validity of the argument. If the specified file does not
exist, let the build fail immediately instead of passing the invalid
file path to tools.
Julius Werner [Wed, 10 Jan 2018 23:12:47 +0000 (15:12 -0800)]
Makefile: Use ld.bfd linker if available
Some toolchain distributions install both the BFD and GOLD linkers under
the names <target>-ld.bfd and <target>-ld.gold. <target>-ld will then be
a symlink that may point to either one of these.
Trusted Firmware should always be linked with the BFD linker, since GOLD
is meant primarily for userspace programs and doesn't support many of
the more obscure linker script features that may be needed for firmware.
With this patch the Makefile will auto-detect if ld.bfd is available and
use it explicitly in that case.
Change-Id: I7017055f67db3bd57d191d20a7af06ca646937d7 Signed-off-by: Julius Werner <jwerner@chromium.org>
With the old system `checkpatch.pl` gets one sole input that consists of
the commit message and commit diff of each commit between BASE_COMMIT
and HEAD. It also filters out changes in some files, which makes `git
format-patch` completely ignore that commit, even the commit message.
With the new system the commit message and commit diff are analyzed
separately. This means that, even if all the files modified by a commit
are filtered out, the commit message will still be analyzed.
Also, all commits are analyzed individually. This way it's easier to
know which commit caused the problem, and there are no warnings about
repeated "Signed-off-by" lines.
Change-Id: Ic676a0b76801bb2607141a8d73dc3a942dc01c0e Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Optimize SMCCC_ARCH_WORKAROUND_1 on Cortex A57/A72/A73 and A75
This patch implements a fast path for this SMC call on affected PEs by
detecting and returning immediately after executing the workaround.
NOTE: The MMU disable/enable workaround now assumes that the MMU was
enabled on entry to EL3. This is a valid assumption as the code turns
on the MMU after reset and leaves it on until the core powers off.
In the initial implementation of this workaround we used a dedicated
workaround context to save/restore state. This patch reduces the
footprint as no additional context is needed.
Additionally, this patch reduces the memory loads and stores by 20%,
reduces the instruction count and exploits static branch prediction to
optimize the SMC path.
In preparation for SMCCC v1.1 support, save x4 to x29 unconditionally.
Previously we expected callers coming from AArch64 mode to preserve
x8-x17. This is no longer the case with SMCCC v1.1 as AArch64 callers
only need to save x0-x3.
This patch maps the devices in the first GB of the system address map
on the FVP into the S-EL1&0 translation regime when SPM support is
enabled. This grants the Secure Partition access to the devices in
this region, for example the memory-mapped Generic Timer device.
Andreas Färber [Sat, 27 Jan 2018 15:46:59 +0000 (16:46 +0100)]
fiptool: Fix use after free
Commit 880b9e8b4c99ad99eee14079d5a6162733ef4931 (Add padding at the end
of the last entry) added code using toc_entry pointer, whose memory is
already freed via variable buf. This causes enormous padding on openSUSE.
Free the memory buffer only after padding is done.
Victor Chong [Sat, 27 Jan 2018 12:36:12 +0000 (21:36 +0900)]
hikey: fix assert in sec_protect()
`assert(e)` was used in place of `if (e) ERROR()` when sec_protect()
was ported from hikey fork so the logic should have been reversed.
Fixes: 3d5d9f5a ("hikey: configure the top 16MB of DRAM as secure") Fixes: 52988b38 ("hikey: configure 4 MB of secure DRAM for OP-TEE
Secure Data Path") Signed-off-by: Victor Chong <victor.chong@linaro.org> Tested-by: Victor Chong <victor.chong@linaro.org>
Derek Basehore [Fri, 26 Jan 2018 06:05:41 +0000 (22:05 -0800)]
rockchip: Disable rdist before pwr_dm_suspend is called
This disables the redistributor before either of the pwr_dm_suspend
functions are called. This is because the rdist save code in the
rk3399 rockchip_soc_sys_pwr_dm_suspend function requires that each
redistributor be disabled before saving state.
Julius Werner [Mon, 22 Jan 2018 22:02:03 +0000 (14:02 -0800)]
delay_timer: Guarantee that delay time can never be undershot
Delay functions like udelay() are often used to ensure that the
necessary time passed to allow some asynchronous event to finish, such
as the stabilization delay for a power rail. For these use cases it is
not very problematic if the delay is slightly longer than requested,
but it is critical that the delay must never be shorter.
The current udelay() implementation contains two hazards that may cause
the delay to be slightly shorter than intended: Firstly, the amount of
ticks to wait is calculated with an integer division, which may cut off
the last fraction of ticks needed. Secondly, the delay may be short by a
fraction of a tick because we do not know whether the initial ("start")
sample of the timer was near the start or near the end of the current
tick. Thus, if the code intends to wait for one tick, it might read the
timer value close to the end of the current tick and then read it again
right after the start of the next tick, concluding that the duration of
a full tick has passed when it in fact was just a fraction of it.
This patch rounds up the division and always adds one extra tick to
counteract both problems and ensure that delays will always be larger
but never smaller than requested.
Change-Id: Ic5fe5f858b5cdf3c0dbf3e488d4d5702d9569433 Signed-off-by: Julius Werner <jwerner@chromium.org>
Masahiro Yamada [Tue, 19 Dec 2017 02:56:05 +0000 (11:56 +0900)]
uniphier: switch to BL2-AT-EL3 and remove BL1 support
UniPhier platform implements non-TF boot ROM. Prior to the BL2-AT-EL3
support, BL1 (worked as a pseudo ROM) was needed just for ensuring BL2
is entered at EL1-S. Now, this platform is able to avoid this waste.
Masahiro Yamada [Mon, 22 Jan 2018 09:35:16 +0000 (18:35 +0900)]
uniphier: set PROGRAMMABLE_RESET_ADDRESS to disable warm boot mailbox
The warm boot mailbox code is compiled if PROGRAMMABLE_RESET_ADDRESS
is disabled.
The warm boot mailbox is useless for UniPhier SoC family because BL1
is not the first image. The UniPhier platform implements non-TF ROM,
then BL1 works as a pseudo ROM, so it is never executed in the warm
boot.
The reset vector address is not actually programmable for UniPhier
platform, but it should not hurt to enable PROGRAMMABLE_RESET_ADDRESS
to disable the mailbox and remove pointless plat_get_my_entrypoint.
Peter Griffin [Thu, 21 Dec 2017 18:03:46 +0000 (18:03 +0000)]
hikey: configure 4 MB of secure DRAM for OP-TEE Secure Data Path
Update the memory firewall configuration to reserve 4 MB of secure RAM
for use by the kernel and OP-TEE as the Secure Data Path pool.
Note that this address range (0x3E800000 - 0x3EC00000) falls in the
range already set aside by UEFI (which reserves the upper 32 MB of the
1GB DRAM for OP-TEE [1]) and was previously unused.
[1] https://github.com/96boards-hikey/edk2/blob/hikey/HisiPkg/HiKeyPkg/Library/HiKeyLib/HiKeyMem.c#L44 Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Acked-by: Victor Chong <victor.chong@linaro.org>
projects / arm-tf.git / log