fix(zynqmp): separate EM from PM SMCs

There is no reason to use else and concatenate EM SMCs with PM SMCs via
if/else pair. Also synchronize comment location.

Change-Id: I147f9d193574c2417c9d92d41a

fix(zynqmp): separate EM from PM SMCs

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>

show more ...

fix(zynqmp): fix bl31_zynqmp_setup.c coding style

Fix trivial coding style violations.

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

Merge "feat(zynqmp): bump up version of query_data API" into integration

docs(xilinx): correct function description

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

docs(xilinx): correct function description

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

show more ...

fix(zynqmp): update the conflicting EEMI API IDs

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

fix(zynqmp): update the conflicting EEMI API IDs

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

show more ...

fix(versal): fix incorrect regbase for PMC IPI

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: I7ff2c9c0dd59954

fix(versal): fix incorrect regbase for PMC IPI

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>

show more ...

fix(versal): sync location based on IPI_ID macros

IPI_ID_* macros available at include/plat_ipi.h are using PMC/APU/RPU0..
order which is not how versal_ipi_table array is composed. That's why
swap

fix(versal): sync location based on IPI_ID macros

IPI_ID_* macros available at include/plat_ipi.h are using PMC/APU/RPU0..
order which is not how versal_ipi_table array is composed. That's why
swap APU and PMC to follow the same order as is described by macros.

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

show more ...

fix(xilinx): remove unused mailbox macros

All these macro are unused that's why remove them.

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

Merge "fix(zynqmp): fix DT reserved allocated size" into integration

fix(zynqmp): with DEBUG=1 move bl31 to DDR range

Due to size constraints in OCM memory range keeping the bl31 with
DEBUG=1 overlaps with the memory range from other Firmware thus
affecting the bootf

fix(zynqmp): with DEBUG=1 move bl31 to DDR range

Due to size constraints in OCM memory range keeping the bl31 with
DEBUG=1 overlaps with the memory range from other Firmware thus
affecting the bootflow on target.
bl31 binary can not be placed in OCM memory range when built with
DEBUG=1.
With DEBUG=1, by default bl31 is moved to DDR memory range
0x1000-0x7FFFF.
The user can provide a custom DDR memory range during build time using
the build parameters ZYNQMP_ATF_MEM_BASE and ZYNQMP_ATF_MEM_SIZE.

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

show more ...

fix(zynqmp): update MAX_XLAT_TABLES for DDR memory range

An assert is observed when the bl31 is placed in DDR memory range and
DEBUG is also enabled. To resolve this, increase the size of
MAX_XLAT_T

fix(zynqmp): update MAX_XLAT_TABLES for DDR memory range

An assert is observed when the bl31 is placed in DDR memory range and
DEBUG is also enabled. To resolve this, increase the size of
MAX_XLAT_TABLES to 8 when bl31 is placed in DDR memory range.

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

show more ...

feat(zynqmp): bump up version of query_data API

As per the current code base, the version of the PM_QUERY_DATA EEMI
API is 2 in the Versal but in ZynqMP it returns the base version.

Since this EEMI

feat(zynqmp): bump up version of query_data API

As per the current code base, the version of the PM_QUERY_DATA EEMI
API is 2 in the Versal but in ZynqMP it returns the base version.

Since this EEMI API ID support similar functionality for Versal and
ZynqMP, hence there should not be any difference in the versioning
as well.

In version 2, the feature check API supports the bitmask functionality
of the QUERY_DATA API, so the user can query the supported QUERY_DATA
ID first and if the ID is supported then the user can perform the
actual functionality of the same.

Hence, bump up the version of PM_QUERY_DATA API Id to 2.

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

show more ...

Merge "fix(zynqmp): enable A53 workaround(errata 1530924)" into integration

fix(zynqmp): fix DT reserved allocated size

BL31_LIMIT is not size but reserved node reg property contains base
address and size that's why BL31_LIMIT - BL31_BASE + 1 is correct size
of reseved spac

fix(zynqmp): fix DT reserved allocated size

BL31_LIMIT is not size but reserved node reg property contains base
address and size that's why BL31_LIMIT - BL31_BASE + 1 is correct size
of reseved space for BL31.
Also update warning message to cover that it is for BL31.

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

show more ...

fix(zynqmp): enable A53 workaround(errata 1530924)

BL31 already reports that there is missing CPU workaround for this
erratum as
"WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!"

fix(zynqmp): enable A53 workaround(errata 1530924)

BL31 already reports that there is missing CPU workaround for this
erratum as
"WARNING: BL31: cortex_a53: CPU workaround for 1530924 was missing!"

That's why enable it by default as was done by other platforms for
example by commit 74665119f04d ("allwinner: Enable workaround for
Cortex-A53 erratum 1530924").

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

show more ...

feat(zynqmp): add SMCCC_ARCH_SOC_ID support

Add support for calling SMCCC_ARCH_SOC_ID which is used by Linux soc_id
driver for printing information about manufacturer and also chip version
and silic

feat(zynqmp): add SMCCC_ARCH_SOC_ID support

Add support for calling SMCCC_ARCH_SOC_ID which is used by Linux soc_id
driver for printing information about manufacturer and also chip version
and silicon ID code. SOC revision is directly mapped to chip ID code.
And SOC version is composed from manufacturer ID based on JEP-106 with
chip_id which contains bits mapped to CPU register 0xffca0044 platform
bits which differentiate between silicon, qemu and other emulated
platforms.

Function description is available at
docs/getting_started/porting-guide.rst.

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

show more ...

Merge "fix(versal-net): populate gic v3 rdist data statically" into integration

chore(xilinx): update print information

Remove company name from the console messages while printing only
relevant information for the platform.

Change-Id: Id8171326e0267eb6f3a26de4eb66143970de2dbd

chore(xilinx): update print information

Remove company name from the console messages while printing only
relevant information for the platform.

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

show more ...

fix(versal-net): populate gic v3 rdist data statically

Currently gicv3_rdistif_probe() is called per CPU. In case of maxcpus=1,
only 1 core is initialized and gicr_base_addrs initialized for CPU 0
o

fix(versal-net): populate gic v3 rdist data statically

Currently gicv3_rdistif_probe() is called per CPU. In case of maxcpus=1,
only 1 core is initialized and gicr_base_addrs initialized for CPU 0
only. Because of this assertion is raised during Linux system suspend.

During Linux suspend, platform callback saves GIC v3 state which
internally invokes arm_gicv3_distif_pre_save(). This function tries to use
gicr_base for all CPUs. Since GICR base address for secondary CPUs are not
initialized, it raises assertion.

To fix the issue, populate GIC v3 rdist data statically (similar to Versal)
instead of dynamically initializing GIC v3 rdist per CPU.

Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Change-Id: I98c97c03e451d05f4ebac358e197617ab9d9b71f

show more ...

feat(versal-net): add jtag dcc support

Add support for JTAG Debug Communication Channel(DCC), using the dcc
console driver, for Versal NET platform.
UART0/UART1 is not configured when the JTAG DCC i

feat(versal-net): add jtag dcc support

Add support for JTAG Debug Communication Channel(DCC), using the dcc
console driver, for Versal NET platform.
UART0/UART1 is not configured when the JTAG DCC is used as console for
the platform.
Though DCC is not using any UART, VERSAL_NET_UART_BASE needs
to be defined in the platform code. If its not defined, build errors
are observed.
Now VERSAL_NET_UART_BASE by default points to UART0 base.
Check for valid console(pl011, pl011_0, pl011_1, dcc) is
being done in the platform makefile, the error condition in
setting the value of VERSAL_NET_UART_BASE is redundant, thus the error
message is removed from the code.

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

show more ...

Merge "fix(zynqmp): fix xck24 silicon ID" into integration

fix(zynqmp): fix xck24 silicon ID

Origin ID code has changed from origin description. After receiving part
new ID code come up that's why fix it. The origin ID code has been added
by commit 86869f99

fix(zynqmp): fix xck24 silicon ID

Origin ID code has changed from origin description. After receiving part
new ID code come up that's why fix it. The origin ID code has been added
by commit 86869f99d0c1 ("feat(zynqmp): add support for xck24 silicon").

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

show more ...

feat(versal-net): add support for uart1 console

Versal NET platform supports two UART(UART0, UART1)
Add support for UART1 to be used as console for Versal NET platform.

Change-Id: I3bc2034f54052e37

feat(versal-net): add support for uart1 console

Versal NET platform supports two UART(UART0, UART1)
Add support for UART1 to be used as console for Versal NET platform.

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

show more ...

Merge changes from topic "fix-power-up-dwn-issue" into integration

* changes:
fix(versal-net): enable wake interrupt during client suspend
fix(versal-net): disable wakeup interrupt during client

Merge changes from topic "fix-power-up-dwn-issue" into integration

* changes:
fix(versal-net): enable wake interrupt during client suspend
fix(versal-net): disable wakeup interrupt during client wakeup
fix(versal-net): clear power down bit during wakeup
fix(versal-net): fix setting power down state
fix(versal-net): clear power down interrupt status before enable
fix(versal-net): resolve misra rule 20.7 warnings
fix(versal-net): resolve misra 10.6 warnings

show more ...

fix(versal): print proper atf handoff source

Versal uses PLM in the boot flow and printing FSBL in the log for
handoff parameters is misleading. Print proper source of TF-A
handoff parameters.

Chan

fix(versal): print proper atf handoff source

Versal uses PLM in the boot flow and printing FSBL in the log for
handoff parameters is misleading. Print proper source of TF-A
handoff parameters.

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

show more ...