feat(arm): support FW handoff b/w BL2 & BL31

Add support for the firmware handoff framework between BL2 and BL31.
Create a transfer list in trusted SRAM, leveraging the larger SRAM sizes
in recent m

feat(arm): support FW handoff b/w BL2 & BL31

Add support for the firmware handoff framework between BL2 and BL31.
Create a transfer list in trusted SRAM, leveraging the larger SRAM sizes
in recent models. Load the HW_CONFIG as a TE along with entry point
parameters for BL31 execution.

Change-Id: I7c4c6e8353ca978a13520fb3e15fb2803f0f1d0e
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

Merge changes I3a4f9a4f,Iedc4e640 into integration

* changes:
docs(rmm): document console struct in rmm boot manifest
feat(rme): pass console info via RMM-EL3 ifc

feat(rme): pass console info via RMM-EL3 ifc

This patch modifies the boot manifest to add console information to
be passed from EL3 to RMM.

Boot manifest version is bumped to v0.3

Signed-off-by: H

feat(rme): pass console info via RMM-EL3 ifc

This patch modifies the boot manifest to add console information to
be passed from EL3 to RMM.

Boot manifest version is bumped to v0.3

Signed-off-by: Harry Moulton <harry.moulton@arm.com>
Signed-off-by: Soby Mathew <soby.mathew@arm.com>
Change-Id: Iedc4e640fb7a4450ce5ce966ae76936d1b7b742d

show more ...

Merge changes from topic "plat_gpt_setup" into integration

* changes:
feat(arm): move GPT setup to common BL source
feat(arm): retrieve GPT related data from platform
refactor(arm): rename L0/

Merge changes from topic "plat_gpt_setup" into integration

* changes:
feat(arm): move GPT setup to common BL source
feat(arm): retrieve GPT related data from platform
refactor(arm): rename L0/L1 GPT base macros

show more ...

feat(arm): retrieve GPT related data from platform

For RME-enabled platforms, initializing L0 and L1 tables and enabling
GPC checks is necessary. For systems using BL2 to load firmware images,
the G

feat(arm): retrieve GPT related data from platform

For RME-enabled platforms, initializing L0 and L1 tables and enabling
GPC checks is necessary. For systems using BL2 to load firmware images,
the GPT initialization has to be done in BL2 prior to the image load.
The common Arm platform code currently implements this in the
"arm_bl2_plat_gpt_setup" function, relying on the FVP platform's
specifications (PAS definitions, GPCCR_PPS, and GPCCR_PGS).

Different Arm platforms may have distinct PAS definitions, GPCCR_PPS,
GPCCR_PGS, L0/L1 base, and size. To accommodate these variations,
introduce the "plat_arm_get_gpt_info" API. Platforms must implement
this API to provide the necessary data for GPT setup on RME-enabled
platforms. It is essential to note that these additions are relevant to
platforms under the plat/arm hierarchy that will reuse the
"arm_bl2_plat_gpt_setup" function.

As a result of these new additions, migrate data related to the FVP
platform to its source and header files.

Signed-off-by: Rohit Mathew <Rohit.Mathew@arm.com>
Change-Id: I4f4c8894c1cda0adc1f83e7439eb372e923f6147

show more ...

Merge "feat(handoff): port BL31-BL33 interface to fw handoff framework" into integration

feat(handoff): port BL31-BL33 interface to fw handoff framework

The firmware handoff framework is a light weight mechanism for sharing
information between bootloader stages. Add support for this fra

feat(handoff): port BL31-BL33 interface to fw handoff framework

The firmware handoff framework is a light weight mechanism for sharing
information between bootloader stages. Add support for this framework at
the handoff boundary between runtime firmware BL31 and NS software on FVP.

Change-Id: Ib02e0e4c20a39e32e06da667caf2ce5a28de1e28
Signed-off-by: Harrison Mutai <harrison.mutai@arm.com>

show more ...

Merge changes from topic "mb/secure-evlog-cpy" into integration

* changes:
feat(fvp): copy the Event Log to TZC secured DRAM area
feat(arm): carveout DRAM1 area for Event Log

Merge "refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3" into integration

refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3

BL2_AT_EL3 is an overloaded macro which has two uses:
1. When BL2 is entry point into TF-A(no BL1)
2. When BL2 is runnin

refactor(build): distinguish BL2 as TF-A entry point and BL2 running at EL3

BL2_AT_EL3 is an overloaded macro which has two uses:
1. When BL2 is entry point into TF-A(no BL1)
2. When BL2 is running at EL3 exception level
These two scenarios are not exactly same even though first implicitly
means second to be true. To distinguish between these two use cases we
introduce new macros.
BL2_AT_EL3 is renamed to RESET_TO_BL2 to better convey both 1. and 2.
Additional macro BL2_RUNS_AT_EL3 is added to cover all scenarious where
BL2 runs at EL3 (including four world systems).

BREAKING CHANGE: BL2_AT_EL3 renamed to RESET_TO_BL2 across the
repository.

Change-Id: I477e1d0f843b44b799c216670e028fcb3509fb72
Signed-off-by: Arvind Ram Prakash <arvind.ramprakash@arm.com>
Signed-off-by: Maksims Svecovs <maksims.svecovs@arm.com>

show more ...

Merge "style: remove useless trailing semicolon and line continuations" into integration

style: remove useless trailing semicolon and line continuations

found using checkpatch.pl[1]

[1]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/lint/checkpatch.pl

S

style: remove useless trailing semicolon and line continuations

found using checkpatch.pl[1]

[1]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/lint/checkpatch.pl

Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
Change-Id: I7957c9694300fefb85d11f7819c43af95271f14c

show more ...

feat(arm): carveout DRAM1 area for Event Log

Reserved 4KB area for Event Log in DRAM1. This area is used by BL2
to copy Event Log from internal SRAM to this carved out DRAM region
in the subsequent

feat(arm): carveout DRAM1 area for Event Log

Reserved 4KB area for Event Log in DRAM1. This area is used by BL2
to copy Event Log from internal SRAM to this carved out DRAM region
in the subsequent patch.

Change-Id: I7b405775c66d249e31edf7688d95770e6c05c175
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...

Merge changes I1b092bc1,Ifc2461b4,I5176caa5 into integration

* changes:
docs(rme): update RMM-EL3 Boot Manifest structure description
feat(rme): read DRAM information from FVP DTB
feat(rme): s

Merge changes I1b092bc1,Ifc2461b4,I5176caa5 into integration

* changes:
docs(rme): update RMM-EL3 Boot Manifest structure description
feat(rme): read DRAM information from FVP DTB
feat(rme): set DRAM information in Boot Manifest platform data

show more ...

feat(rme): read DRAM information from FVP DTB

This patch builds on the previous patch by implementing
support for reading NS DRAM layout of FVP model from
HW_CONFIG Device tree.

Macro _RMMD_MANIFES

feat(rme): read DRAM information from FVP DTB

This patch builds on the previous patch by implementing
support for reading NS DRAM layout of FVP model from
HW_CONFIG Device tree.

Macro _RMMD_MANIFEST_VERSION is renamed to
SET_RMMD_MANIFEST_VERSION to suppress MISRA-C
"rule MC3R1.D4.5: (advisory) Identifiers in
the same name space with overlapping visibility
should be typographically unambiguous" warning

Signed-off-by: AlexeiFedorov <Alexei.Fedorov@arm.com>
Change-Id: Ifc2461b4441a1efdd4b7c656ab4d15e62479f77b

show more ...

feat(rme): set DRAM information in Boot Manifest platform data

This patch adds support for setting configuration of DRAM banks
for FVP model in RMM-EL3 Boot Manifest structure.
Structure 'rmm_manife

feat(rme): set DRAM information in Boot Manifest platform data

This patch adds support for setting configuration of DRAM banks
for FVP model in RMM-EL3 Boot Manifest structure.
Structure 'rmm_manifest' is extended with 'plat_dram' structure
which contains information about platform's DRAM layout:
- number of DRAM banks;
- pointer to 'dram_bank[]' array;
- check sum: two's complement 64-bit value of the sum of
data in 'plat_dram' and 'dram_bank[] array.
Each 'dram_bank' structure holds information about DRAM
bank base address and its size. This values must be aligned
to 4KB page size.
The patch increases Boot Manifest minor version to 2 and
removes 'typedef rmm_manifest_t' as per
"3.4.15.1. Avoid anonymous typedefs of structs/enums in headers" of
https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-style.html

Signed-off-by: AlexeiFedorov <Alexei.Fedorov@arm.com>
Change-Id: I5176caa5780e27d1e0daeb5dea3e40cf6ad5fd12

show more ...

Merge "fix(rmmd): add missing padding to RMM Boot Manifest and initialize it" into integration

fix(rmmd): add missing padding to RMM Boot Manifest and initialize it

This patch also:
* Enforces the check of RES0 fields on EL3-RMM boot interface
and manifest
* Fixes a couple of

fix(rmmd): add missing padding to RMM Boot Manifest and initialize it

This patch also:
* Enforces the check of RES0 fields on EL3-RMM boot interface
and manifest
* Fixes a couple of nits on the EL3-RMM Boot Interface
documentation.

Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com>
Change-Id: Idb9e38f9fcda2ba0655646a1e2c4fdbabd5cdc40

show more ...

Merge changes from topic "jas/rmm-el3-ifc" into integration

* changes:
docs(rmmd): document EL3-RMM Interfaces
feat(rmmd): add support to create a boot manifest
fix(rme): use RMM shared buffer

Merge changes from topic "jas/rmm-el3-ifc" into integration

* changes:
docs(rmmd): document EL3-RMM Interfaces
feat(rmmd): add support to create a boot manifest
fix(rme): use RMM shared buffer for attest SMCs
feat(rmmd): add support for RMM Boot interface

show more ...

feat(rmmd): add support to create a boot manifest

This patch also adds an initial RMM Boot Manifest (v0.1) for fvp
platform.

Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com>
Ch

feat(rmmd): add support to create a boot manifest

This patch also adds an initial RMM Boot Manifest (v0.1) for fvp
platform.

Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com>
Change-Id: I1374f8f9cb207028f1820953cd2a5cf6d6c3b948

show more ...

feat(rmmd): add support for RMM Boot interface

This patch adds the infrastructure needed to pass boot arguments from
EL3 to RMM and allocates a shared buffer between both worlds that can
be used, am

feat(rmmd): add support for RMM Boot interface

This patch adds the infrastructure needed to pass boot arguments from
EL3 to RMM and allocates a shared buffer between both worlds that can
be used, among others, to pass a boot manifest to RMM. The buffer is
composed a single memory page be used by a later EL3 <-> RMM interface
by all CPUs.

The RMM boot manifest is not implemented by this patch.

In addition to that, this patch also enables support for RMM when
RESET_TO_BL31 is enabled.

Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com>
Change-Id: I855cd4758ee3843eadd9fb482d70a6d18954d82a

show more ...

Merge changes from topic "ffa_el3_spmc" into integration

* changes:
feat(spmc): enable checking of execution ctx count
feat(spmc): enable parsing of UUID from SP Manifest
feat(spmc): add parti

Merge changes from topic "ffa_el3_spmc" into integration

* changes:
feat(spmc): enable checking of execution ctx count
feat(spmc): enable parsing of UUID from SP Manifest
feat(spmc): add partition mailbox structs
feat(plat/arm): allow BL32 specific defines to be used by SPMC_AT_EL3
feat(plat/fvp): add EL3 SPMC #defines
test(plat/fvp/lsp): add example logical partition
feat(spmc/lsp): add logical partition framework

show more ...

feat(plat/fvp): add EL3 SPMC #defines

Introduce additional #defines for running with the EL3
SPMC on the FVP.

The increase in xlat tables has been chosen to allow
the test cases to complete success

feat(plat/fvp): add EL3 SPMC #defines

Introduce additional #defines for running with the EL3
SPMC on the FVP.

The increase in xlat tables has been chosen to allow
the test cases to complete successfully and may need
adjusting depending on the desired usecase.

Signed-off-by: Marc Bonnici <marc.bonnici@arm.com>
Change-Id: I7f44344ff8b74ae8907d53ebb652ff8def2d2562

show more ...

Merge changes from topic "refactor-hw-config-load" into integration

* changes:
docs(fvp): update loading addresses of HW_CONFIG
docs(fconf): update device tree binding for FCONF
feat(fvp): upd

Merge changes from topic "refactor-hw-config-load" into integration

* changes:
docs(fvp): update loading addresses of HW_CONFIG
docs(fconf): update device tree binding for FCONF
feat(fvp): update HW_CONFIG DT loading mechanism
refactor(st): update set_config_info function call
refactor(fvp_r): update set_config_info function call
refactor(arm): update set_config_info function call
feat(fconf): add NS load address in configuration DTB nodes

show more ...

feat(fvp): update HW_CONFIG DT loading mechanism

Currently, HW-config is loaded into non-secure memory, which mean
a malicious NS-agent could tamper with it. Ideally, this shouldn't
be an issue sinc

feat(fvp): update HW_CONFIG DT loading mechanism

Currently, HW-config is loaded into non-secure memory, which mean
a malicious NS-agent could tamper with it. Ideally, this shouldn't
be an issue since no software runs in non-secure world at this time
(non-secure world has not been started yet).

It does not provide a guarantee though since malicious external
NS-agents can take control of this memory region for update/corruption
after BL2 loads it and before BL31/BL32/SP_MIN consumes it. The threat
is mapped to Threat ID#3 (Bypass authentication scenario) in threat
model [1].

Hence modified the code as below -
1. BL2 loads the HW_CONFIG into secure memory
2. BL2 makes a copy of the HW_CONFIG in the non-secure memory at an
address provided by the newly added property(ns-load-address) in
the 'hw-config' node of the FW_CONFIG
3. SP_MIN receives the FW_CONFIG address from BL2 via arg1 so that
it can retrieve details (address and size) of HW_CONFIG from
FW_CONFIG
4. A secure and non-secure HW_CONFIG address will eventually be used
by BL31/SP_MIN/BL32 and BL33 components respectively
5. BL31/SP_MIN dynamically maps the Secure HW_CONFIG region and reads
information from it to local variables (structures) and then
unmaps it
6. Reduce HW_CONFIG maximum size from 16MB to 1MB; it appears
sufficient, and it will also create a free space for any future
components to be added to memory

[1]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html

Change-Id: I1d431f3e640ded60616604b1c33aa638b9a1e55e
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>

show more ...