Change in PLATFORM_TEST build flag from boolean -> string, with the
current string options being tfm-testsuite and rss-nv-counters.
To get the old behavior, i.e. where we used to use PLATFORM_TEST=1,
we now need to pass PLATFORM_TEST=tfm-testsuite.
Adding new test of the AP/RSS interface for non-volatile counters.
The test reads, increments, and reads again each 3 types of NV
counters for: CCA, secure, and non-secure firmware. Enabled by
PLATFORM_TEST=rss-nv-counters.
Change-Id: I2044cc9b2f37984697e0754c9c824eab51a11e7f
Signed-off-by: Lauren Wehrmeister <lauren.wehrmeister@arm.com>
Signed-off-by: Raef Coles <raef.coles@arm.com>
* This change overrides the default PLAT_ARM_FIP_OFFSET_IN_GPT
* This aligns the FIP base in GPT image to the RSS ATU page size
boundary (8 KiB). RSS XIP feature requires the FIP to be aligned to
the page size boundary. TC platform will require the XIP feature.
* The aligned FIP_A is starting at sector 48. Hence the offset will be
48*512 = 0x6000.
Signed-off-by: Tintu Thomas <tintu.thomas@arm.com>
Change-Id: I8135ecd4168231847c80151c33ef8353a1586b9a
Taking a reference at this early stage can cause boot failure if the DM
firmware is not fully initialized. Remove this early call until the
fix in DM firmware is widely available.
Signed-off-by: Andrew Davis <afd@ti.com>
Change-Id: Ic9c47ccf1e9a1b9faeb1c7d2665d54cf55ef5396
When the TF-A is placed in DDR memory range, the DDR memory range is
getting explicitly reserved in the default device tree by TF-A.
This creates an error condition in the use case where Device tree is
not present or it is present at a different location.
To fix this, a new build time parameter, XILINX_OF_BOARD_DTB_ADDR, is
introduced. The TF-A will reserve the DDR memory only when a valid
DTB address is provided to XILINX_OF_BOARD_DTB_ADDR during build.
Now the user has options, either manually reserve the desired
DDR address range for TF-A in device tree or let TF-A access and modify
the device tree, to reserve the DDR address range, in runtime using
the build parameter.
Change-Id: I846fa373ba9f7c984eda3a55ccaaa622082cad81
Signed-off-by: Akshay Belsare <akshay.belsare@amd.com>
Use non-fast wakeup stop mode for system suspend support, so
the SOC can enter DSM mode by default.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: I37828d4e66ee2ebd48e7adca054b93c520cb2c82
A53 core's power up ack need to be used when system resume
from DSM mode.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: I47fb33c0582ae5f483ffaa887f95e27bd47875f7
Add the anamix PLL override setting for DSM mode support,
so that the PLL can be power down in DSM mode to save power.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: Ibe954bc7c4a7b453ace13f8e4b6a335e6d4856c3
This new workaround takes advantage of the per core IMR
registers in GPC in order to unmask the IRQ0, still generated
by the 12bit in IOMUX_GPR register (which now remains always set),
so it can only wake up one core at the time.Also, this entire
workaround has now been moved here in TF-A, allowing the kernel
side to be minimal.
Another advantage this workaround brings is the removal of the
50us delay (which was necessary before in gic_raise_softirq in
kernel) by allowing the core that is waking up to mask his own
IRQ0 in the suspend finish callback.
One important change here is the way the cores are woken up in
dram_dvfs_handler. Since the wake up mechanism has changed from
asserting the 12th bit in IOMUX_GPR and leaving the IMR1 1st bit
on for each core to exactly the reverse, that is, leaving the
IOMUX_GPR 12th bit always set and then masking/unmasking the IMR1
1st bit for each independent core, we need to use the imx_gpc_core_wake
to wake up the cores.
Also, the 50us udelay is moved to TF-A (inside imx_pwr_domain_off)
from kernel(gic_raise_softirq), since the new cpuidle workaround
does not need it in order to clean the IOMUX_GPC 12bit. For now,
the udelay seems to be still needed in order to delay the affinity
info OFF for the dying core. This is something that needs further
investigation.
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: I9f17ff6fc3452b8225a50b232964712aafeab78a
Add the dram retention support for i.MX8MQ. As there is
no enough ocram space available before entering TF-A,
so the timing info need to be copied from dram into ocram.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: Id8264c342fd62e297b1969cba5ed505450c78a25
iMX8MQ B2 chip uses same OCOTP magic value with B1. So
read the ROM version to distinguish it with B1.
Signed-off-by: Ye Li <ye.li@nxp.com>
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Change-Id: I3e6865922deeb66816a0dddb49d986405e802b6f
Backup the mr12/14 value as the actual value used is not the
one we configured in the ddrc config timing.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Change-Id: If04733b34a3b4c080828bb7c82e83f0badbeaafd
Pauth is a generic Arm feature that can be enabled on any platform that
implements it. It only needs a platform specific key generation hook. As
such, the generic Pauth enablement can be included in the generic build.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Ibf32f79addab3515214594bb8d7168151b450f59
APB Write data corruption following MRCTRL0.mr_wr=1 while
hardware-driven MR access is occurring
When performing a software driven MR access, the following
sequence must be done automatically before performing other
APB register accesses:
1. Set MRCTRL0.mr_wr=1
2. Check for MRSTAT.mr_wr_busy=0. If not, go to step (2)
3. Check for MRSTAT.mr_wr_busy=0 again (for the second time),
if not, go to step (2).
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Change-Id: Ie26e08bcc83d3ed4844ed04a853162308dcdccd0
Fix the out of bound access to the rank setting array.
Fix Coverity issue:
CID 6474575: Out-of-bounds access (OVERRUN)
CID 11014855: Unused value (UNUSED_VALUE)
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Change-Id: I5d9ef90f1479e5d46d1b6c8693a27e3abd614766
It seems the DRAM APB clock root slice can NOT work normally
if the PLLs is power down in DSM mode. So update this clock
slice's setting explicitly to make it work. This piece of code
is there for a long while on previous release, so just add
it back to align with previous flow.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
Change-Id: I113069494074194e116fdb1229052d2956bf90ea
Add DRAM PLL frequency setting for 3200mts & 4000mts.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Anson Huang <anson.huang@nxp.com>
Change-Id: I4b0609f9e7c0f35d75a26ec9ccebec77b3dbe68f
The dfimisc reg value should be shift right 8 bit to
get the current fsp.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Anson Huang <Anson.Huang@nxp.com>
Change-Id: I4c8c166bc3ad4cc1376961cbf47631c68b5900cc
update umctl2's setting based on phy training CDD value
to workaround the rank-to-rank space issue.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Anson Huang <anson.huang@nxp.com>
Change-Id: I0fab18cdc378fda760daa0f89c4dd84eb46f7e11
At the moment we only support FEAT_TRF to be either unconditionally
compiled in, or to be not supported at all.
Add support for runtime detection (ENABLE_TRF_FOR_NS=2), by splitting
is_feat_trf_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 TRF related registers.
Also move the context saving code from assembly to C, and use the new
is_feat_trf_supported() function to guard its execution.
The FVP platform decided to compile in support unconditionally (=1),
even though FEAT_TRF is an ARMv8.4 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: Ia97b01adbe24970a4d837afd463dc5506b7295a3
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
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>
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>
EM support was out of SMC SIP range that's why has been moved to SIP
range 0x3000 by commit acbae3998b ("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 504925f99d ("xilinx: zynqmp: Add
support for Error Management").
Change-Id: I2d9222d7dde507400893e06f7f12e1713ce6bc9a
Signed-off-by: Michal Simek <michal.simek@amd.com>
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
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
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
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
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
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>
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>
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>
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>
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>
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>
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>
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>
23:16 bits when they gets to SMC handler should be all zeros but be
inside SIP Service Calls range which is defined as 0x82000000-0x8200ffff
or 0xc2000000-0xc200ffff. That's why make sure that code won't handle
any SMCs in SIP range out of predefined range.
Also fix MASK values to check the same range for PM/IPI calls to make
sure that masking covers all required bits including 23:16. Bits 15:12
are used for different class of requests.
Change-Id: I9d3e91aa521d6bb90f6b15b71ff1e89fa77ee379
Signed-off-by: Michal Simek <michal.simek@amd.com>
23:16 bits when they gets to SMC handler should be all zeros but be
inside SIP Service Calls range which is defined as 0x82000000-0x8200ffff
or 0xc2000000-0xc200ffff. That's why make sure that code won't handle
any SMCs in SIP range out of predefined range. Because EM SMC is out of
this range already on this SOC check it after it (EMC SMC will be
handled separately).
Also fix MASK values to check the same range for PM/IPI/EM calls to make
sure that masking covers all required bits including 23:16. Bits 15:12
are used for different class of requests.
Change-Id: If23ac769c91d206e47758aeaa1f14e8b9c3dc7bb
Signed-off-by: Michal Simek <michal.simek@amd.com>
There is no reason to use else and concatenate EM SMCs with PM SMCs via
if/else pair. Also synchronize comment location.
Change-Id: I147f9d193574c2417c9d92d41a675e35ba282c9f
Signed-off-by: Michal Simek <michal.simek@amd.com>
Because RSS now does not map the header into the TC2 ROM, it is no
longer necessary to have the code start at 0x1000, so unify with other
TC platforms at 0x0.
Change-Id: I7ec34bb814865ba39678f4da0412294d4679052d
Signed-off-by: Raef Coles <raef.coles@arm.com>
Inside pm_ipi.c file, corrected the function description of
pm_ipi_buff_read_callb() and removed the return type as this is a void
function.
Signed-off-by: Naman Patel <naman.patel@amd.com>
Change-Id: I6257894337ef64497afb3e80d70af91a20357d5f
In the ZynqMP, 0x36 EEMI API ID is used for PM_FPGA_GET_VERSION and 0x37
is used for PM_FPGA_GET_FEATURE_LIST. The same ID numbers in the Versal
are used for PM_ADD_SUBSYSTEM and PM_DESTROY_SUBSYSTEM and it leads to
the EEMI API ID conflict between the platforms. To fix this issue this
patch updates the PM_FPGA_GET_VERSION and PM_FPGA_GET_FEATURE_LIST EEMI
API ID's to 0x48 and 0x49.
In linux zynqmp_pm_fpga_get_version() and
zynqmp_pm_fpga_get_feature_list() API's are uses PM_FPGA_GET_VERSION
and PM_FPGA_GET_FEATURE_LIST to get the xilfpga version and
xilfpga-supported feature list info. These API's are called only in
zynqmp-fpga.c as part of the probe. In case of this caller API's are
failed it will fall to the default feature list and this default
feature list is same as latest xilfpga-supported feature list (No new
feature was added in the xilfpga after adding these APIs). So, these
updated IDs will not cause any functional issues between Linux, TF-A,
and firmware components.
Signed-off-by: Nava kishore Manne <nava.kishore.manne@amd.com>
Change-Id: I14d974dd44651681ecbf726ad8b6940e1850cbec
PMC ipi register base can't be the same as is for IPI_ID_APU that's why
that address is not correct and needs to be fixed.
Change-Id: I7ff2c9c0dd5995487e41f6b1060e4c9880c009fa
Signed-off-by: Michal Simek <michal.simek@amd.com>
laurenw-arm
Tintu Thomas
Andrew Davis
Akshay Belsare
Jacky Bai
Ye Li
Boyan Karatotev
Andre Przywara
Govindraj Raja
Michal Simek
Mate Toth-Pal
Amit Nagal
Ronak Jain
Chris Kay
Elyes Haouas
Raef Coles
Naman Patel
Nava kishore Manne