refactor(brbe): enable FEAT_BRBE for FEAT_STATE_CHECKED

At the moment we only support FEAT_BRBE to be either unconditionally
compiled in, or to be not supported at all.

Add support for runtime dete

refactor(brbe): enable FEAT_BRBE for FEAT_STATE_CHECKED

At the moment we only support FEAT_BRBE to be either unconditionally
compiled in, or to be not supported at all.

Add support for runtime detection (ENABLE_BRBE_FOR_NS=2), by splitting
is_feat_brbe_present() into an ID register reading function and a second
function to report the support status. That function considers both
build time settings and runtime information (if needed), and is used
before we access BRBE related registers.

The FVP platform decided to compile in support unconditionally (=1),
even though FEAT_BRBE is an ARMv9 feature, so is not available with the
FVP model's default command line.
Change that to the now supported dynamic option (=2), so the right
decision can be made by the code at runtime.

Change-Id: I5f2e2c9648300f65f0fa9a5f8e2f34e73529d053
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

refactor(trbe): enable FEAT_TRBE for FEAT_STATE_CHECKED

At the moment we only support FEAT_TRBE to be either unconditionally
compiled in, or to be not supported at all.

Add support for runtime dete

refactor(trbe): enable FEAT_TRBE for FEAT_STATE_CHECKED

At the moment we only support FEAT_TRBE to be either unconditionally
compiled in, or to be not supported at all.

Add support for runtime detection (ENABLE_TRBE_FOR_NS=2), by splitting
is_feat_trbe_present() into an ID register reading function and a second
function to report the support status. That function considers both
build time settings and runtime information (if needed), and is used
before we access TRBE related registers.

The FVP platform decided to compile in support unconditionally (=1),
even though FEAT_TRBE is an ARMv9 feature, so is not available with the
FVP model's default command line.
Change that to the now supported dynamic option (=2), so the right
decision can be made by the code at runtime.

Change-Id: Iee7f88ea930119049543a8a4a105389997e7692c
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...

Merge changes from topic "mbedtls3_support" into integration

* changes:
feat(stm32mp1): add mbedtls-3.3 support config
refactor(fvp): minor cleanup with TRUSTED_BOARD_BOOT
style(crypto): add b

Merge changes from topic "mbedtls3_support" into integration

* changes:
feat(stm32mp1): add mbedtls-3.3 support config
refactor(fvp): minor cleanup with TRUSTED_BOARD_BOOT
style(crypto): add braces for if statement
feat(fvp): increase BL1_RW and BL2 size
feat(mbedtls): add support for mbedtls-3.3
refactor(crypto): avoid using struct mbedtls_pk_rsassa_pss_options
refactor(mbedtls): avoid including MBEDTLS_CONFIG_FILE

show more ...

feat(stm32mp1): add mbedtls-3.3 support config

Add stm32mp1_mbedtls_config-3.h config file for stm32mp1 builds with
mbedtls-3.3

Change-Id: I4581cb0ea7b2c7022e71aefd7ff05ee3a72f5883
Signed-off-by: G

feat(stm32mp1): add mbedtls-3.3 support config

Add stm32mp1_mbedtls_config-3.h config file for stm32mp1 builds with
mbedtls-3.3

Change-Id: I4581cb0ea7b2c7022e71aefd7ff05ee3a72f5883
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

revert(zynqmp): remove EM SMC handler

EM support was out of SMC SIP range that's why has been moved to SIP
range 0x3000 by commit acbae3998bd8 ("fix(zynqmp): move EM SMC range
to SIP range").
But af

revert(zynqmp): remove EM SMC handler

EM support was out of SMC SIP range that's why has been moved to SIP
range 0x3000 by commit acbae3998bd8 ("fix(zynqmp): move EM SMC range
to SIP range").
But after another investigation was found that this interface has no
user in any our SW and likely never adopted by anybody else. That's
why simply remove it. If there is any user it can be added back but
as TF-A size is challenging removing unused code is very welcome.
Origin code was added by commit 504925f99da0 ("xilinx: zynqmp: Add
support for Error Management").

Change-Id: I2d9222d7dde507400893e06f7f12e1713ce6bc9a
Signed-off-by: Michal Simek <michal.simek@amd.com>

show more ...

fix(imx8m): fix the dfiphymaster setting after dvfs

the dfi phy master setting need to be save/restore to make
sure it aligned with the initial config.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
R

fix(imx8m): fix the dfiphymaster setting after dvfs

the dfi phy master setting need to be save/restore to make
sure it aligned with the initial config.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Anson Huang <anson.huang@nxp.com>
Change-Id: I4f572b9aff9cc47a6c28524ce0fe03cdc66b88a1

show more ...

feat(imx8m): update the ddr4 dvfs flow to include ddr3l support

the DDR3L & DDR4 can share same piece of code for DDR frequency scaling.
So update the ddr4 dvfs flow to support DDR3L too.

Signed-of

feat(imx8m): update the ddr4 dvfs flow to include ddr3l support

the DDR3L & DDR4 can share same piece of code for DDR frequency scaling.
So update the ddr4 dvfs flow to support DDR3L too.

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Anson Huang <anson.huang@nxp.com>
Change-Id: Ifc6981f05ed8a4e399adad97690197a9680f554d

show more ...

fix(imx8m): correct the rank info get fro mstr

the bitfield of active_ranks in MSTR is defined as below.
Correct the rank num get in dram_info.

0x01: one rank;
0x11: two rank;

Signed-off-by: J

fix(imx8m): correct the rank info get fro mstr

the bitfield of active_ranks in MSTR is defined as below.
Correct the rank num get in dram_info.

0x01: one rank;
0x11: two rank;

Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Anson Huang <anson.huang@nxp.com>
Change-Id: Idcadb39f492a8fe81c973ac4136d9a1eaa32f54b

show more ...

feat(imx8m): fix the ddr4 dvfs random hang on imx8m

Remove the while loop waiting in step12 to align with what
we did before, just use a 'if' condition check for debug
purpose.

Tested-by: Peng Fan

feat(imx8m): fix the ddr4 dvfs random hang on imx8m

Remove the while loop waiting in step12 to align with what
we did before, just use a 'if' condition check for debug
purpose.

Tested-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: Id2685c5f628270a24944470d675a5c8706f39f13

show more ...

fix(rme): update sample platform attestation token

Update FVP platform attestation token to comply with RMM Beta0
specification. The changes are:
- change platform implementation id claim value from

fix(rme): update sample platform attestation token

Update FVP platform attestation token to comply with RMM Beta0
specification. The changes are:
- change platform implementation id claim value from 64 to 32 bits
- change Realm Challenge
- update Hash Algorithm Identifier claim value
- add protected header
- change signing algotithm to ECDSA ES384

Change-Id: I1c5907d1a4961ce08a1408d25128de125b3f2e7f
Signed-off-by: Mate Toth-Pal <mate.toth-pal@arm.com>

show more ...

feat(zynqmp): add hooks for mmap and early setup

Add early setup hooks (via custom_early_setup()) and provide a way
to cover custom memory mapping which includes extending memory map
via custom_mmap

feat(zynqmp): add hooks for mmap and early setup

Add early setup hooks (via custom_early_setup()) and provide a way
to cover custom memory mapping which includes extending memory map
via custom_mmap_add().

This likely also require to align MAX_XLAT_TABLE, MAX_XLAT_TABLES
macros. It can be done for example by defining these macros in
custom_pkg.mk
MAX_MMAP_REGIONS := XY
$(eval $(call add_define,MAX_MMAP_REGIONS))
MAX_XLAT_TABLES := XZ
$(eval $(call add_define,MAX_XLAT_TABLES))

custom_early_setup() can be used for early low level operations
related to setting up the system to correct state.

Signed-off-by: Amit Nagal <amit.nagal@amd.com>
Change-Id: I61df6f9ba5af0bc97c430974fb10a2edde44f23d

show more ...

Merge changes from topic "panic_cleanup" into integration

* changes:
refactor(bl31): use elx_panic for sysreg_handler64
refactor(aarch64): rename do_panic and el3_panic
refactor(aarch64): remo

Merge changes from topic "panic_cleanup" into integration

* changes:
refactor(bl31): use elx_panic for sysreg_handler64
refactor(aarch64): rename do_panic and el3_panic
refactor(aarch64): remove weak links to el3_panic
refactor(aarch64): refactor usage of elx_panic
refactor(aarch64): cleanup HANDLE_EA_EL3_FIRST_NS usage

show more ...

Merge "fix: remove useless "return" at void functions" into integration

fix(zynqmp): add bitmask for get_op_char API

As per the current functionality, there are a couple of types like
PM_OPCHAR_TYPE_TEMP, PM_OPCHAR_TYPE_POWER and PM_OPCHAR_TYPE_LATENCY
for the PM_GET_OP

fix(zynqmp): add bitmask for get_op_char API

As per the current functionality, there are a couple of types like
PM_OPCHAR_TYPE_TEMP, PM_OPCHAR_TYPE_POWER and PM_OPCHAR_TYPE_LATENCY
for the PM_GET_OP_CHARACTERISTIC EEMI API which is mismatched across
the Versal and ZynqMP platforms.

So added the bitmask functionality for PM_GET_OP_CHARACTERISTIC API
in feature check in the firmware and as part of that the firmware fill
up payload[1] with the bitmask value of supported types of the
PM_GET_OP_CHARACTERISTIC EEMI API but from TF-A based on the current
codebase it is just returning the version. So filling up the bitmask
buffer which is received from the firmware and returned the same to
the user.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Change-Id: I2c55f3e902a5f89eed899e99a97ad9b3f0a12796

show more ...

Merge changes I51c13c52,I3358c51e into integration

* changes:
build: always prefix section names with `.`
build: communicate correct page size to linker

Merge "fix(zynqmp): panic w/o handoff structure in !JTAG" into integration

refactor(aarch64): rename do_panic and el3_panic

Current panic call invokes do_panic which calls el3_panic, but now panic
handles only panic from EL3 anid clear separation to use lower_el_panic()
wh

refactor(aarch64): rename do_panic and el3_panic

Current panic call invokes do_panic which calls el3_panic, but now panic
handles only panic from EL3 anid clear separation to use lower_el_panic()
which handles panic from lower ELs.

So now we can remove do_panic and just call el3_panic for all panics.

Change-Id: I739c69271b9fb15c1176050877a9b0c0394dc739
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

refactor(aarch64): refactor usage of elx_panic

Currently we call el3_panic for panics from EL3 and elx_panic for
panics from lower ELs.

When we boot into a rich OS environment and interact with BL3

refactor(aarch64): refactor usage of elx_panic

Currently we call el3_panic for panics from EL3 and elx_panic for
panics from lower ELs.

When we boot into a rich OS environment and interact with BL31 using
SMC/ABI calls and we can also decide to handle any lower EL panics in
EL3. Panic can occur in lower EL from rich OS or during SMC/ABI calls
after context switch to EL3.

But after booting into any rich OS we may land in panic either from
rich OS or while servicing any SMC call, here the logic to use
el3_panic or elx_panic is flawed as spsr_el3[3:0] is always EL3h
and end up in elx_panic even if panic occurred from EL3 during
SMC handling.

We try to decouple the elx_panic usage for its intended purpose,
introduce lower_el_panic which would call elx_panic, currently
lower_el_panic is called from default platform_ea_handle which
would be called due to panic from any of the lower ELs.

Also remove the weak linkage for elx_panic and rename it to
report_elx_panic which could be used with lower_el_panic.

Change-Id: I268bca89c01c60520d127ef6c7ba851460edc747
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

refactor(aarch64): cleanup HANDLE_EA_EL3_FIRST_NS usage

Remove usage of HANDLE_EA_EL3_FIRST_NS in plat_default_ea_handler

Change-Id: I2bf4788960d20a090d66cf39c7bbbdea1d3243ca
Signed-off-by: Govindr

refactor(aarch64): cleanup HANDLE_EA_EL3_FIRST_NS usage

Remove usage of HANDLE_EA_EL3_FIRST_NS in plat_default_ea_handler

Change-Id: I2bf4788960d20a090d66cf39c7bbbdea1d3243ca
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

refactor(fvp): minor cleanup with TRUSTED_BOARD_BOOT

CRYPTO_SUPPORT is enabled by default when TRUSTED_BOARD_BOOT is
enabled so usage CRYPTO_SUPPORT in conjunction with TRUSTED_BOARD_BOOT
might some

refactor(fvp): minor cleanup with TRUSTED_BOARD_BOOT

CRYPTO_SUPPORT is enabled by default when TRUSTED_BOARD_BOOT is
enabled so usage CRYPTO_SUPPORT in conjunction with TRUSTED_BOARD_BOOT
might sometime be confusing to look at.

Adding minor cleanup to make it look simpler with conditions.
No functionality changes.

Change-Id: I800524d54ea56dc27b6c6da26c75a07f5f6de984
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

feat(fvp): increase BL1_RW and BL2 size

To support mbedtls3.3 increase BL1_RW and BL2 size rsa+ecdsa alg.

Increase both by one page size. In mbedtls3.3 numerous config options
have been tweaked and

feat(fvp): increase BL1_RW and BL2 size

To support mbedtls3.3 increase BL1_RW and BL2 size rsa+ecdsa alg.

Increase both by one page size. In mbedtls3.3 numerous config options
have been tweaked and made defaults[1] thus a small increase in size
can result for mbedtls-3.3

This size limitation is observed when we build TF-A with
TF_MBEDTLS_KEY_ALG=rsa+ecdsa this approach is used in juno as well,
so use similar approach for FVP.

[1]: https://github.com/Mbed-TLS/mbedtls/blob/development/docs/3.0-migration-guide.md

Change-Id: I8a423711ac50b3d615c1d9650086cdbca5051c8e
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

refactor(mbedtls): avoid including MBEDTLS_CONFIG_FILE

Currently we include MBEDTLS_CONFIG_FILE directly and if a custom
config file is used it will included.

However from mbedtls-3.x onwards it di

refactor(mbedtls): avoid including MBEDTLS_CONFIG_FILE

Currently we include MBEDTLS_CONFIG_FILE directly and if a custom
config file is used it will included.

However from mbedtls-3.x onwards it discourages usage of
MBEDTLS_CONFIG_FILE include directly, so to resolve this and keep 2.28
compatibility include version.h which would include the custom config
file if present and also would expose us with mbedtls-major-version
number which could be used for selecting features and functions for
mbedtls 2.28 or 3.3

Change-Id: I029992311be2a38b588ebbb350875b03ea29acdb
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>

show more ...

fix(zynqmp): panic w/o handoff structure in !JTAG

In case that FSBL (or SPL) doesn't provide valid handoff structure don't
fallback to default image location. In non JTAG boot mode all the time
stru

fix(zynqmp): panic w/o handoff structure in !JTAG

In case that FSBL (or SPL) doesn't provide valid handoff structure don't
fallback to default image location. In non JTAG boot mode all the time
structure should be passed. If it is not it can be opportunity to inject
any code to default locations and start it. That's why panic in all
these cases.

Change-Id: Ib3e11e2ae9ffec7406002cce4997b12b97bdc396
Signed-off-by: Michal Simek <michal.simek@amd.com>

show more ...

build: always prefix section names with `.`

Some of our specialized sections are not prefixed with the conventional
period. The compiler uses input section names to derive certain other
section name

build: always prefix section names with `.`

Some of our specialized sections are not prefixed with the conventional
period. The compiler uses input section names to derive certain other
section names (e.g. `.rela.text`, `.relacpu_ops`), and these can be
difficult to select in linker scripts when there is a lack of a
delimiter.

This change introduces the period prefix to all specialized section
names.

BREAKING-CHANGE: All input and output linker section names have been
prefixed with the period character, e.g. `cpu_ops` -> `.cpu_ops`.

Change-Id: I51c13c5266d5975fbd944ef4961328e72f82fc1c
Signed-off-by: Chris Kay <chris.kay@arm.com>

show more ...

fix(zynqmp): move EM SMC range to SIP range

EM SMC where out of SIP range which is 15:0 bits only. EM was used 19:17
bits which is wrong but no code was checking it. That's why vove EM SMC
to SIP ra

fix(zynqmp): move EM SMC range to SIP range

EM SMC where out of SIP range which is 15:0 bits only. EM was used 19:17
bits which is wrong but no code was checking it. That's why vove EM SMC
to SIP range.

Change-Id: I83f998a17a8b82b2c25ea8c9b247e42642c82178
Signed-off-by: Michal Simek <michal.simek@amd.com>

show more ...