| #
baf2e39f |
| 08-Aug-2025 |
Madhukar Pappireddy <madhukar.pappireddy@arm.com> |
Merge changes I61d77211,I9cb5c1fa,I8e8a92fd into integration
* changes:
refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3
fix(gicv3): remove plat_gicv3_base.c
ref
Merge changes I61d77211,I9cb5c1fa,I8e8a92fd into integration
* changes:
refactor(gicv3): clarify redistributor base address usage with USE_GIC_DRIVER=3
fix(gicv3): remove plat_gicv3_base.c
refactor(versal-net): use the generic GIC driver
show more ...
|
| #
8a4a551c |
| 30-Jun-2025 |
Boyan Karatotev <boyan.karatotev@arm.com> |
refactor(versal-net): use the generic GIC driver
With the introduction of USE_GIC_DRIVER, platforms no longer have to do
their own GIC management for basic PSCI-related operations. Previously a
half
refactor(versal-net): use the generic GIC driver
With the introduction of USE_GIC_DRIVER, platforms no longer have to do
their own GIC management for basic PSCI-related operations. Previously a
half-measure was possible by using plat_gicv3_base.c to get semi-generic
helpers which versal_net uses.
Since USE_GIC_DRIVER is based on plat_gicv3_base.c, convert the platform
to use that so its code is more generic. Expected benefits are slightly
better performance around calling the gic hooks on cpu suspend and less
platform code.
Change-Id: I8e8a92fd4111e4a83c7a34bc5255d924bc54e769
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
show more ...
|
| #
dcbc607d |
| 08-Dec-2023 |
Joanna Farley <joanna.farley@arm.com> |
Merge "build(versal-net): reorganize platform source files" into integration
|
| #
4622da46 |
| 08-Nov-2023 |
Akshay Belsare <akshay.belsare@amd.com> |
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 ...
|
| #
dd532b9e |
| 03-Nov-2023 |
Joanna Farley <joanna.farley@arm.com> |
Merge changes from topic "xlnx_tsp_feat" into integration
* changes:
docs(versal-net): add TSP build documentation
docs(versal): add TSP build documentation
feat(versal-net): add tsp support
Merge changes from topic "xlnx_tsp_feat" into integration
* changes:
docs(versal-net): add TSP build documentation
docs(versal): add TSP build documentation
feat(versal-net): add tsp support
feat(versal): add tsp support
refactor(xilinx): add generic TSP makefile
chore(zynqmp): reorganize tsp code into common path
refactor(xilinx): rename platform function to generic name
show more ...
|
| #
639b3676 |
| 27-Oct-2023 |
Prasad Kummari <prasad.kummari@amd.com> |
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 ...
|