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>
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>
To be inline with other features, and to allow the availability to be
checked for different contexts, move the FGT availability check out of
the save/restore functions. This is instead now checked at the caller.
Change-Id: I96e0638714f9d1b6fdadc1cb989cbd33bd48b1f6
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
So far the check_feature() function compares the subfield of a CPU ID
register against 0, to learn if a feature is enabled or not.
This is problematic for checks that require a certain revision of a
feature, so we should check against a minimum version number instead.
On top of that we might need to add code to support newer versions of a
feature, so we should be alerted if new hardware introduces a higher
number.
Extend the check_feature() function to take two extra arguments: the
minimum version, and the greatest currently known number.
Then make sure that the CPU ID field is in this range.
Change-Id: I425b68535a2ba9eafd31854e74d142183b521cd5
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Some MISRA test complains about our code to isolate CPU ID register
fields: the ID registers (and associated masks) are 64 bits wide, but
the eventual field is always 4 bits wide only, so we use an unsigned
int to represent that. MISRA dislikes the differing width here.
Since the code to extract a feature field from a CPU ID register is very
schematic already, provide a wrapper macro to make this more readable,
and do the proper casting in one central place on the way.
While at it, use the same macro for the AArch32 feature detection side.
Change-Id: Ie102a9e7007a386f5879ec65e159ff041504a4ee
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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
When we reach sysreg_handler64 from any trap handling we are entering
this path from lower EL and thus we should be calling lower_el_panic
reporting mechanism to print panic report.
Make report_elx_panic available through assembly func elx_panic which
could be used for reporting any lower_el_panic.
Change-Id: Ieb260cf20ea327a59db84198b2c6a6bfc9ca9537
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
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
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>
Cleanup weak links to el3_panic and restrict crash_reporting usage
to bl31.
Crash reporting is not used with bl1, bl2 and weak linkage to el3_panic
is used, this can cause ambiguity in understanding the code so remove
this weak linkage and introduce funcs that should be used when we have
crash reporting for el3 panics.
Change-Id: Ic5c711143ba36898ef9574a078b8fa02effceb12
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
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>
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>
Current CFLAGS if set for library builds could impact entire build, so
allow to pass additional CFLAGs for library builds based on format
<LIBNAME>_CFLAGS.
This support is currently needed to avoid 'redundant declaration'
error from latest mbedtls-3.3, the issue is reported to mbedtls[1]
and is under consideration to remove any redundant declarations.
But till then we have to disable that compiler option while building
for mbedtls-3.3
[1]: https://github.com/Mbed-TLS/mbedtls/issues/6910
Change-Id: Ic99af22b229f8089c82110d6545f762c14a62f5c
Signed-off-by: Govindraj Raja <govindraj.raja@arm.com>
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>
The Device Present (DP) field is set to '1' after host controller
receive 'SUCCESS' return code on the response of the DME_LINKSTARTUP UIC
CMD during host controller initialization.
JEDEC Standard No. 223E
Page 28
Signed-off-by: Jorge Troncoso <jatron@google.com>
Change-Id: I9db0374c1df3530d64187b9e449cde3b27d63072
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>
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>
Added few missed links for Security Advisories.
Change-Id: I9cab72b70a518273cbb1a291142f452198427127
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>
Add support for custom sip service.
Bare minimum implementation for custom_smc_handler is provided
by platform. Actual definition for custom_smc_handler will be provided
by custom pkg.
This feature is going to be used by external libraries. For example
for checking it's status.
The similar approach is also used by qti/{sc7180,sc7280} platforms
by providing a way to select QTISECLIB_PATH.
This code is providing a generic way how to wire any code
via custom $(CUSTOM_PKG_PATH)/custom_pkg.mk makefile with also an
option to wire custom SMC. SMC functionality depends on "package".
Change-Id: Icedffd582f76f89fc399b0bb2e05cdaee9b743a0
Signed-off-by: Amit Nagal <amit.nagal@amd.com>
The docs say 3 is valid, but it is not. Jammy uses 3.10 so pin it to
that.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I73530750065294eb511d88318ba86a6c50c8aa7d
Specifying build.tools is mandatory. We use python, so use the latest
one available. For ubuntu 22.04 that should be 3.10 or thereabouts.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Ifd184b9f3b2d8e91182ccb73c47b148e4aeaff05
Andre Przywara
Joanna Farley
Sandrine Bailleux
Amit Nagal
Bipin Ravi
Madhukar Pappireddy
Govindraj Raja
Ronak Jain
Manish Pandey
Manish V Badarkhe
Michal Simek
Jorge Troncoso
Chris Kay
Patrik Berglund
Olivier Deprez
Boyan Karatotev