Also, add a disclaimer to explain that the current implementation of SPM
is a prototype that is going to undergo a lot of rework.
Change-Id: I303c1e61c51d9f286cc599fea565fc9ba5a996bf
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The old SMCs SP_MEMORY_ATTRIBUTES_{GET,SET}_AARCH64 have been removed in
favour of SPRT_MEMORY_PERM_ATTR_{GET,SET}_AARCH64.
Change-Id: Idb93cfa5461d0098df941037c5653f7c44b65227
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Note that the arguments passed during the SMC call don't comply with the
SPCI specifications. This will be fixed in following patches, but it is
needed to implement a few more SPCI SMCs to be able to do it. The
current code allows us to start testing it.
Change-Id: Ic13dcc54c40327df03be1b0f52e8a44f468f06b4
Co-authored-by: Jean-Paul Etienne <jean-paul.etienne@arm.com>
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
This buffer is where all the responses from Secure Partitions are stored
until they are requested.
Change-Id: Iafeb8f0848c5ff6f3e187060cd3a47702484dc45
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Blocking calls can only succeed if the target Secure Partition is idle.
Change-Id: Iabeaa0b8d3e653fd8581fa086758936abfc1c772
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Note that the arguments passed during the SMC call don't comply with the
SPCI specifications. This will be fixed in following patches, but it is
needed to implement a few more SPCI SMCs to be able to do it. The
current code allows us to start testing it.
Change-Id: Ief0e75d072b311737fcdb0c6a60ba5b7406a9ee5
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Introduce SMCs that open and close handles according to the SPCI
specification.
Change-Id: I65f365f15612e01aa445e783e96e48ae275c39fd
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Remove interfaces based on MM_COMMUNICATE.
Change-Id: I628c884b91d9f4758269ea2c4dedc37a66bb93cf
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
SPM needs to map a number of regions on behalf of the secure partition.
Previously, it used to get a list of them from platform code using the
plat_get_secure_partition_mmap() API. Now it gets them from the resource
description structure.
The SPM<->SP shared buffer is mapped dynamically at EL3. This buffer is
used to pass information between SPM and SP, so it must be mapped at EL3
as well in order to be used by SPM.
Dynamic translation tables have been enabled when the Trusted Firmware
is compiled with SPM support.
Change-Id: I64ad335e931661812a0a60558e60372e1e5e6b72
Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Read entrypoint of the Secure Partition from the resource description
struct.
Change-Id: Ie693c7b4d4fecafd85b6934d9d8c4232efb1dc55
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Load SP and RD from package instead of relying on RD being already
loaded in memory and the SP being loaded as a BL32 image.
Change-Id: I18d4fbf4597656c6a7e878e1d7c01a8a324f3f8a
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
This tool packages Secure Partitions and Resource Descriptor blobs into
a simple file that can be loaded by SPM.
Change-Id: If3800064f30bdc3d7fc6a15ffbb3007ef632bcaa
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
This information is retrieved from the resource description now.
Change-Id: Iaae23945eb2c45305cdc6442853e42f4e04fe094
Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
This information is defined by the Secure Partition in the resource
description.
Change-Id: Ia7db90c5de8360a596106880d3f6a632a88d3ea8
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Introduce helpers to create resource description struct, as well as code
to load the information from DTB files.
Change-Id: I0f5bb94eb8b01c6cb53fe807a9db0c05a70d7a43
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The structures and associated definitions are in different files so that
the definitions can be used inside DTS files while the structs are
private to SPM. They follow the SPRT specification.
Change-Id: Id6a629040a086c482b9d9fa1883b8aa6bbee619f
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The current SPM is a prototype that only supports one secure partition
in EL0. The objective of SPM is to have multiple partitions. The current
MM interface isn't adequate for this, so it is needed to modify heavily
the code to add proper support for it.
However, there are platforms which are already using this (like SGI) and
removing the code would break it. For this reason, the current SPM code
has been duplicated in order to temporarily preserve compatibility. All
new improvements/changes to SPM will be done in the non-deprecated copy,
that may change without notice.
The new build option SPM_DEPRECATED has been introduced to select the SPM
implementation. It defaults to 1, that selects the deprecated SPM.
Change-Id: Ic9f80b53b450e97b4d3f47e4ef4a138ee8d87443
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
The Armv8.5 extensions introduces PSTATE.SSBS (Speculation Store Bypass
Safe) bit to mitigate against Variant 4 vulnerabilities. Although an
Armv8.5 feature, this can be implemented by CPUs implementing earlier
version of the architecture.
With this patch, when both PSTATE.SSBS is implemented and
DYNAMIC_WORKAROUND_CVE_2018_3639 is active, querying for
SMCCC_ARCH_WORKAROUND_2 via. SMCCC_ARCH_FEATURES call would return 1 to
indicate that mitigation on the PE is either permanently enabled or not
required.
When SSBS is implemented, SCTLR_EL3.DSSBS is initialized to 0 at reset
of every BL stage. This means that EL3 always executes with mitigation
applied.
For Cortex A76, if the PE implements SSBS, the existing mitigation (by
using a different vector table, and tweaking CPU ACTLR2) is not used.
Change-Id: Ib0386c5714184144d4747951751c2fc6ba4242b6
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
I wrote most of this code and have a vested interest in keeping it
healthy, so adding myself as a maintainer.
Change-Id: I0edeebbc8336b6976dfaf393b3cfc7bc94089ac6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Now that we have switched to using the stack in MULTI_CONSOLE_API
framework functions and have factored all code involved in crash
reporting out into a separate file, there's really no reason to keep the
main framework code in assembly anymore. This patch rewrites it in C
which allows us to have a single implementation across aarch32/64 and
should be much easier to maintain going forward.
Change-Id: I6c85a01e89a79e8b233f3f8bee812f0dbd026221
Signed-off-by: Julius Werner <jwerner@chromium.org>
This patch makes the build system link the console framework code by
default, like it already does with other common libraries (e.g. cache
helpers). This should not make a difference in practice since TF is
linked with --gc-sections, so the linker will garbage collect all
functions and data that are not referenced by any other code. Thus, if a
platform doesn't want to include console code for size reasons and
doesn't make any references to console functions, the code will not be
included in the final binary.
To avoid compatibility issues with older platform ports, only make this
change for the MULTI_CONSOLE_API.
Change-Id: I153a9dbe680d57aadb860d1c829759ba701130d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
console_unregister() has always returned a pointer to the console that
was removed on success, not just an integer. Fix the C prototype to
match the assembly implementation.
Change-Id: Iafc43de0767a5c87c9ae5c3aba53761dd28d51e6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Crash reporting via the default consoles registered by MULTI_CONSOLE_API
has been broken since commit d35cc34 (Console: Use callee-saved
registers), which was introduced to allow console drivers written in C.
It's not really possible with the current crash reporting framework to
support console drivers in C, however we should make sure that the
existing assembly drivers that do support crash reporting continue to
work through the MULTI_CONSOLE_API.
This patch fixes the problem by creating custom console_putc() and
console_flush() implementations for the crash reporting case that do not
use the stack. Platforms that want to use this feature will have to link
plat/common/aarch64/crash_console_helpers.S explicitly.
Also update the documentation to better reflect the new reality (of this
being an option rather than the expected default for most platforms).
Change-Id: Id0c761e5e2fddaf25c277bc7b8ab603946ca73cb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Commit e74afb652 (Deprecate weak crash console functions) deprecated the
default inclusion of weak definitions for plat_crash_console functions
in plat/common/aarch64/platform_helpers.S. The code was later copied out
to plat/common/aarch64/crash_console_helpers.S so platforms can link it
explicitly if they want to. However, since deprecation does not mean
removal, the same code is also still duplicated in platform_helpers.S.
The duplicated code contains both empty stubs for the !MULTI_CONSOLE_API
case, and a real implementation that used to work but was broken by
commit d35cc34 (Console: Use callee-saved registers) for
MULTI_CONSOLE_API. It's not great to have both of these duplicated in
two files, so this patch splits them up: in platform_helpers.S we'll
only keep the empty stubs (guarded by !ERROR_DEPRECATED), which should
not regress functionality since the MULTI_CONSOLE_API implementation was
already broken anyway. In crash_console_helpers.S, we'll only keep the
MULTI_CONSOLE_API version, which is enough both as an implementation in
itself and as a sample for how to reimplement these functions in a
platform-specific file.
Change-Id: I83d95a90ab6aac597dc2ea2f2797ac2c8ed075d4
Signed-off-by: Julius Werner <jwerner@chromium.org>
SGI-Clark.Helios platform is similar to SGI-Clark.Ares platform.
The difference between these two platforms is the CPU type and
the number of CPUs. Add the base support for SGI-Clark.Helios platform.
Change-Id: I2b04cb3fb953907848b4fab016e3648899ca4256
Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
For SGI-Clark.Helios platform, at present, only the CPU power ON/OFF
ops are supported. So override the PSCI ops to allow callbacks only
for CPU power ON/OFF operations.
Change-Id: Idc0a3deb78cb850310cbe849d77604fa9881579c
Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
SGI-Clark.Helios platform is based on multi-threaded CPUs and uses an
additional thread power domain level as well.
Define a power domain tree descriptor 'sgi_clark_helios_pd_tree_desc'
for SGI-Clark.Helios platform and let the function
'plat_get_power_domain_tree_desc' pick up the correct power
domain tree descriptor based on the platform.
Change-Id: Ibc6d551b570bc740053316a3608c455679d9155b
Signed-off-by: Chandni Cherukuri <chandni.cherukuri@arm.com>
Generate a /reserved-memory node for FCNL in the DT passed to
subsequent stages, so they will know how the FCNL is configured.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Generate /compatible string for the platform, so that the subsequent
stages know which platform they are running on. This could be useful
when ie. building U-Boot that contains DTs for multiple platforms and
can thus decide on which platform it is running. This would ultimately
allow single bootloader binary for all Gen3 platforms.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Pass DTB containing DRAM layout from BL2 to BL33 via register x3, so
that the BL33 can simply consume it and get accurate DRAM layout info.
BL33 is in most usecases U-Boot.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Use array of start-size tuples for the DRAM banks and call single
function which iterates over this array to report the DRAM info.
This is in preparation for expanding this to generate FDT for the
next stage.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Print the DRAM configuration only after the DRAM was initialized. This
will be useful when deduplicating code populating FDT passed to U-Boot,
since it will contain the same macros as bl2_advertise_dram_size().
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
There is nothing preventing H3 older than v3.0 from printing the
DRAM configuration, just like v3.0 and newer. Drop the check and
let all H3 revisions print DRAM configuration in BL2.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Soby Mathew
Antonio Niño Díaz
Jeenu Viswambharan
Julius Werner
Chandni Cherukuri
Marek Vasut