refactor(versal-net): rename VERSAL_NET_IOU_SCNTRS register to generic

Refactor, the macro named VERSAL_NET_IOU_SCNTRS is being renamed to a more
generic macro name, which will be used in common cod

refactor(versal-net): rename VERSAL_NET_IOU_SCNTRS register to generic

Refactor, the macro named VERSAL_NET_IOU_SCNTRS is being renamed to a more
generic macro name, which will be used in common code to enable reuse
across various platforms.

Change-Id: I548437e0fe2d73b196468bc92029f8099ea1f8d1
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

fix(versal-net): setup counter frequency

Refactor the system counter configuration into the
syscnt_freq_config_setup() function as it involves timestamp and
system counter configuration, which requi

fix(versal-net): setup counter frequency

Refactor the system counter configuration into the
syscnt_freq_config_setup() function as it involves timestamp and
system counter configuration, which requires early configuration for
clock setup and read the value of the IOU_SCNTRS_BASE_FREQ register
using mmio_read_32() to determine the counter frequency.

If the counter frequency is zero, the system will set the default CPU
clocks constants in TF-A and displays message. However, if the counter
frequency is non-zero, the program will return the value stored in the
IOU_SCNTRS_BASE_FREQ register.

The issue lies in dcc_status_timeout(),function verifying timeout
status, particularly within timeout_cnt_us2cnt(), converting
microseconds to counter ticks using read_cntfrq_el0(), which returns
zero. timeout_elapsed() then checks if the current counter from
read_cntpct_el0() exceeds the expiration count, reached to timeout.

After the function set_cnt_freq() writes into the counter frequency
register, the function timeout_cnt_us2cnt() is used to obtain the
appropriate counter ticks. Subsequently, the function timeout_elapsed()
checks whether the current counter value read_cntpct_el0() has
exceeded the specified expiration count. If it has, this indicates
that the timeout has lapsed.

Change-Id: Ib9ed3493d22f23c832f8bb7d11c4f727fe1ebe3c
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

fix(versal): initialize cntfrq_el0 register

The set_cnt_freq() function is introduced to configure the counter
frequency register.If the counter frequency register is zero, it writes
the output of p

fix(versal): initialize cntfrq_el0 register

The set_cnt_freq() function is introduced to configure the counter
frequency register.If the counter frequency register is zero, it writes
the output of plat_get_syscnt_freq2() the cpu_clocks to the counter
frequency register.

According to the design specifications provided for Versal, the
lpd_data.cdo file contains a mask_write operation for register
0xFF140020 (base_frequency_ID_register) to set it to 0x5f5e100,
configuring it for a 100MHz clock frequency.

Reading the value of the IOU_SCNTRS_BASE_FREQ register using
mmio_read_32() to determine the counter frequency. If the counter
frequency is zero, the system will set the default CPU clocks constants
in TF-A and displays message. However, if the counter frequency is
non-zero, the program will return the value stored in the
IOU_SCNTRS_BASE_FREQ register.

The issue lies in dcc_status_timeout(),function verifying timeout
status, particularly within timeout_cnt_us2cnt(), converting
microseconds to counter ticks using read_cntfrq_el0(), which returns
zero. timeout_elapsed() then checks if the current counter from
read_cntpct_el0()exceeds the expiration count, denoting timeout.

After the function set_cnt_freq() writes into the counter frequency
register, the function timeout_cnt_us2cnt() is used to obtain the
appropriate counter ticks. Subsequently, the function timeout_elapsed()
checks whether the current counter value read_cntpct_el0() has
exceeded the specified expiration count. If it has, this indicates
that the timeout has lapsed.

Change-Id: I8f2f4d804b5aefa6f92083d831a5ebfade384294
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

feat(versal): enable errata management feature

The errata ABI feature-specific build flag, the flag enabling CPUs
in the CPU list, and the flags testing non-ARM interconnect-based
errata when enable

feat(versal): enable errata management feature

The errata ABI feature-specific build flag, the flag enabling CPUs
in the CPU list, and the flags testing non-ARM interconnect-based
errata when enabled from a platform level are added to the AMD-Xilinx
Versal platform makefile to assess the errata ABI feature
implementation.

ERRATA_ABI_SUPPORT : Boolean option to enable support for Errata
management firmware interface for the BL31 image. By default,
its disabled set to zero.

Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Change-Id: I54cda23d699abc0782f44172c28933f5cbb010b8

show more ...

Merge "feat(versal-net): add bufferless IPI Support" into integration

feat(versal-net): add bufferless IPI Support

There exist inter-processor interrupts on Versal-Net that do not have
corresponding message buffers. These bufferless IPI's on Versal NET
SOC are added t

feat(versal-net): add bufferless IPI Support

There exist inter-processor interrupts on Versal-Net that do not have
corresponding message buffers. These bufferless IPI's on Versal NET
SOC are added to static IPI Tables.

In hardware description there exists two IPI's called 'IPI6' without
buffers that have respective system interrupt values 95 and 101. For
these append the string '_95' or '_101' to denote the difference for
each.

Change-Id: I22bf1a68cb0ed68913eb868f1c197856fc7d82d5
Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>

show more ...

build(versal-net): reorganize platform source files

Reorganize the platform source files necessary across various
Bootloader (BL) configurations within the platform makefile.
This reordering aims to

build(versal-net): reorganize platform source files

Reorganize the platform source files necessary across various
Bootloader (BL) configurations within the platform makefile.
This reordering aims to prevent redundant inclusions of these files
across multiple makefiles used for distinct features.

Change-Id: I9c5525dd8522cb8c8e3ad6add70189dcb7cfcc29
Signed-off-by: Akshay Belsare <akshay.belsare@amd.com>

show more ...

fix(xilinx): update correct return types

Refactor the return types to ensure code correctness and compliance
for DT console.

Change-Id: I11dc3afbe168a78ddc03427df3f5f8d10fe40d40
Signed-off-by: Pras

fix(xilinx): update correct return types

Refactor the return types to ensure code correctness and compliance
for DT console.

Change-Id: I11dc3afbe168a78ddc03427df3f5f8d10fe40d40
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

fix(xilinx): add FIT image check in DT console

With this change, the 'is_valid_dtb()' function has been added,
which checks for the presence of the FDT header, FDT open, and the
'/configurations' pr

fix(xilinx): add FIT image check in DT console

With this change, the 'is_valid_dtb()' function has been added,
which checks for the presence of the FDT header, FDT open, and the
'/configurations' property in the DTB. This property is only available
in FIT images. If the property is present, a warning message is
printed, and the code skips reading console information from the
FIT image. Memory mapping is not necessary because it is called in
the early setup function to collect UART information from the DTB.

Change-Id: I91335a180e7ece2cc0ec9fac4026556c48dd8cc8
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

fix(xilinx): add FIT image check in prepare_dtb

Introduce two new functions: 'is_valid_image()' and 'is_fit_image()'
to enhance the functionality of the system. 'is_valid_image()' will
verify the pr

fix(xilinx): add FIT image check in prepare_dtb

Introduce two new functions: 'is_valid_image()' and 'is_fit_image()'
to enhance the functionality of the system. 'is_valid_image()' will
verify the presence of the FDT header and ensure that the FDT is
open. Meanwhile, 'is_fit_image()' will be responsible for detecting
FIT images. When TF-A is built with a DTB address during compilation
and later executed from DDR memory, TF-A will dynamically reserve a
memory location in the DTB during runtime.

This approach is effective when a raw DTB is present at the specified
address location. With this change, the "is_fit_image()" function
has been introduced to verify the existence of the "/configurations"
property within the DTB.

The presence of this property is exclusive to FIT images. In case
the property is found, a warning message is displayed, and memory
space reservation for its address space in DDR is not performed by
TF-A. However, if the property is not present, TF-A continues its
usual procedure of updating the raw DTB.

Additionally, dynamic mapping has been refactored and separated into
distinct functions: "add_mmap_dynamic_region ()" and
"remove_dynamic_mmap()". This separation enhances compatibility
and maintains better code organization.

Change-Id: I9cd3f09863b44483445e58c802dee34d58dfe2e9
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

Merge changes from topic "enable_assertion" into integration

* changes:
feat(zynqmp): enable assertion
feat(versal-net): enable assertion
feat(versal): enable assertion

Merge "feat(xilinx): switch boot console to runtime" into integration

Merge "feat(zynqmp): remove pm_ioctl_set_sgmii_mode api" into integration

feat(zynqmp): remove pm_ioctl_set_sgmii_mode api

There are no existing users of pm_ioctl_set_sgmii_mode() API so
cleanup the dead code.

Change-Id: I1088d2f5c944bf54fc5fdd554360bdd321ad798a
Signed-o

feat(zynqmp): remove pm_ioctl_set_sgmii_mode api

There are no existing users of pm_ioctl_set_sgmii_mode() API so
cleanup the dead code.

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

show more ...

feat(versal-net): add tsp support

Introduces support for the Test Secure Payload (TSP) for AMD-Xilinx
Versal NET platform. TSP is a component for testing and validating
secure OS and trusted execut

feat(versal-net): add tsp support

Introduces support for the Test Secure Payload (TSP) for AMD-Xilinx
Versal NET platform. TSP is a component for testing and validating
secure OS and trusted execution environments.

If a BL32 image is present, then there must be a matching Secure-EL1
Payload Dispatcher (SPD) service called TSPD, this service is
responsible for Initializing the TSP. During initialization that
service must register a function to carry out initialization of BL32
once the runtime services are fully initialized. BL31 invokes such
a registered function to initialize BL32 before running BL33.

The GICv3 driver is initialized in EL3 and does not need to be
initialized again in SEL1 GICv3 driver is initialized in EL3 This is
because the S-EL1 can use GIC system registers to manage interrupts
and does not need GIC interface base addresses to be configured.

The secure code load address is initially being pointed to 0x0 in the
handoff parameters, which is different from the default or user-provided
load address of 0x60000000. In this case, set up the PC to the
requested BL32_BASE address to ensure that the secure code is loaded
and executed from the correct location.

Change-Id: I58fe256dc9d6be5cee384c5ebb9baca2737c02a6
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

feat(versal): add tsp support

Introduces support for the Test Secure Payload (TSP) for AMD-Xilinx
Versal platform. TSP is a component for testing and validating
secure OS and trusted execution envi

feat(versal): add tsp support

Introduces support for the Test Secure Payload (TSP) for AMD-Xilinx
Versal platform. TSP is a component for testing and validating
secure OS and trusted execution environments.

If a BL32 image is present, then there must be a matching Secure-
EL1 Payload Dispatcher (SPD) service called TSPD, this service
is responsible for Initializing the TSP. During initialization that
service must register a function to carry out initialization of
BL32 once the runtime services are fully initialized. BL31 invokes
such a registered function to initialize BL32 before running BL33.

The GICv3 driver is initialized in EL3 and does not need to be
initialized again in SEL1 GICv3 driver is initialized in EL3
This is because the S-EL1 can use GIC system registers to manage
interrupts and does not need GIC interface base addresses to be
configured.

The secure code load address is initially being pointed to 0x0
in the handoff parameters, which is different from the default
or user-provided load address of 0x60000000. In this case, set up
the PC to the requested BL32_BASE address to ensure that the secure
code is loaded and executed from the correct location.

Change-Id: Ida0fc6467a10bfde8927ff9b3755a83f3e16f068
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

refactor(xilinx): add generic TSP makefile

Updated the generic TSP makefile in the common path for reuse in
different platforms.

Change-Id: Idd14675bc547e0a4a95132653a181e7ff39a547a
Signed-off-by:

refactor(xilinx): add generic TSP makefile

Updated the generic TSP makefile in the common path for reuse in
different platforms.

Change-Id: Idd14675bc547e0a4a95132653a181e7ff39a547a
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

chore(zynqmp): reorganize tsp code into common path

Reorganized TSP code into common folder, updated paths in
tsp-zynqmp.mk. Handling the return value of a console registration
function.

Change-Id:

chore(zynqmp): reorganize tsp code into common path

Reorganized TSP code into common folder, updated paths in
tsp-zynqmp.mk. Handling the return value of a console registration
function.

Change-Id: I848f17c3417b3e8c8cbd2058e9642ed13d121325
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

refactor(xilinx): rename platform function to generic name

Refactor two platform specific functions, plat_versal_get_mmap() and
plat_versal_net_get_mmap(), to use a more generic function name
plat_g

refactor(xilinx): rename platform function to generic name

Refactor two platform specific functions, plat_versal_get_mmap() and
plat_versal_net_get_mmap(), to use a more generic function name
plat_get_mmap(). The function can be used in the common code to
obtain memory region.

Change-Id: I3eeb24aff217eef30af60a7742cbebe9d3b2edce
Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>

show more ...

feat(zynqmp): enable assertion

Retain assertions in builds for TF-A run from DDR with
ENABLE_ASSERTIONS=1. It helps to catch programming errors
(e.g. bad argument provided by platform porting functi

feat(zynqmp): enable assertion

Retain assertions in builds for TF-A run from DDR with
ENABLE_ASSERTIONS=1. It helps to catch programming errors
(e.g. bad argument provided by platform porting function)
code size change is 4k.
For debug builds, assertions are enabled by default.
The same change is done by Tegra: plat/nvidia/tegra/platform.mk.

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

show more ...

feat(versal-net): enable assertion

Retain assertions in release builds by building TF-A with
ENABLE_ASSERTIONS=1. It helps to catch programming errors
(e.g. bad argument provided by platform porting

feat(versal-net): enable assertion

Retain assertions in release builds by building TF-A with
ENABLE_ASSERTIONS=1. It helps to catch programming errors
(e.g. bad argument provided by platform porting function)
in release builds as well.
code size change is 4k.
For debug builds, assertions are enabled by default.
The same change is done by Tegra: plat/nvidia/tegra/platform.mk

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

show more ...

feat(versal): enable assertion

Retain assertions in release builds by building TF-A with
ENABLE_ASSERTIONS=1. It helps to catch programming errors
(e.g. bad argument provided by platform porting fun

feat(versal): enable assertion

Retain assertions in release builds by building TF-A with
ENABLE_ASSERTIONS=1. It helps to catch programming errors
(e.g. bad argument provided by platform porting function)
in release builds as well.
code size change is 4k.
For debug builds, assertions are enabled by default.
The same change is done by Tegra: plat/nvidia/tegra/platform.mk.

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

show more ...

fix(versal): type cast addresses to fix integer overflow

Typecast the base and size arguments for build time as unsigned
integers and the limit derived from these two as an unsigned long
to prevent

fix(versal): type cast addresses to fix integer overflow

Typecast the base and size arguments for build time as unsigned
integers and the limit derived from these two as an unsigned long
to prevent size integer overflow issues during the build.

Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Change-Id: Iefc148e0091e8c8a4ca505691036c79528a558a4

show more ...

feat(xilinx): switch boot console to runtime

Switch boot console to runtime at bl31_plat_runtime_setup() for all Xilinx
SOCs to follow default behavior. Till now boot console is used for the
whole l

feat(xilinx): switch boot console to runtime

Switch boot console to runtime at bl31_plat_runtime_setup() for all Xilinx
SOCs to follow default behavior. Till now boot console is used for the
whole lifecycle of TF-A. On the other hand there is no option to configure
different boot and run time console that's why this isn't really a issue.

Documentation is describing default behavior like this:
"
Function : bl31_plat_runtime_setup() [optional]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

::

Argument : void
Return : void

The purpose of this function is allow the platform to perform any BL31 runtime
setup just prior to BL31 exit during cold boot. The default weak
implementation of this function will invoke ``console_switch_state()`` to switch
console output to consoles marked for use in the ``runtime`` state.
"

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

show more ...

feat(versal-net): retrieval of console information from dtb

Introduces functionality to retrieve console information from the
device tree (DTB) and use it in TF-A code.

Comparing early console info

feat(versal-net): retrieval of console information from dtb

Introduces functionality to retrieve console information from the
device tree (DTB) and use it in TF-A code.

Comparing early console information and the data populated from
the DTB. In case of a mistmatch, the changes takes care of
unregistering the build time console configuration and registering the
DTB-based console.

Reorganizes the console configuration setup in BL31 by moving it to a
dedicated function called setup_console() in the plat_console.c
file. This change improves code readability by isolating console-
related settings, making it easier to manage and extend the console
configuration in the future.

Signed-off-by: Prasad Kummari <prasad.kummari@amd.com>
Change-Id: I7b6ebad0e91133ab5fbda8f3a8663abfb6dd2458

show more ...