| 496d7081 | 15-Feb-2023 |
Amit Nagal <amit.nagal@amd.com> |
feat(zynqmp): add support for custom sip service
Add support for custom sip service. Bare minimum implementation for custom_smc_handler is provided by platform. Actual definition for custom_smc_hand
feat(zynqmp): add support for custom sip service
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>
show more ...
|
| af4d8c6d | 13-Feb-2023 |
Elyes Haouas <ehaouas@noos.fr> |
fix: remove useless "return" at void functions
void functions() returns nothing. So remove useless "return".
found using checkpatch.pl[1]
[1]: https://review.coreboot.org/plugins/gitiles/coreboot/
fix: remove useless "return" at void functions
void functions() returns nothing. So remove useless "return".
found using checkpatch.pl[1]
[1]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/lint/checkpatch.pl
Change-Id: I3daab2abec225a657af48f7d8c215cc554713074 Signed-off-by: Elyes Haouas <ehaouas@noos.fr>
show more ...
|
| 4a50363a | 15-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
fix(versal): check smc_fid 23:16 bits
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-0xc20
fix(versal): check smc_fid 23:16 bits
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>
show more ...
|
| 09b342a9 | 14-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
fix(zynqmp): check smc_fid 23:16 bits
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-0xc20
fix(zynqmp): check smc_fid 23:16 bits
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>
show more ...
|
| a9113966 | 14-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
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 ...
|
| 26ef5c29 | 13-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
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> |
| f9e11c72 | 16-Feb-2023 |
Raef Coles <raef.coles@arm.com> |
fix(tc): unify TC ROM start addresses
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.
fix(tc): unify TC ROM start addresses
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>
show more ...
|
| 0069933a | 16-Feb-2023 |
Joanna Farley <joanna.farley@arm.com> |
Merge "feat(zynqmp): bump up version of query_data API" into integration |
| b96065a0 | 15-Feb-2023 |
Naman Patel <naman.patel@amd.com> |
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 ...
|
| bcc1348b | 15-Feb-2023 |
Nava kishore Manne <nava.kishore.manne@amd.com> |
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 ...
|
| c4185d51 | 09-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
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 ...
|
| 92a43bdf | 08-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
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 ...
|
| 15f49cb4 | 08-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
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> |
| 97936d89 | 15-Feb-2023 |
Joanna Farley <joanna.farley@arm.com> |
Merge "fix(zynqmp): fix DT reserved allocated size" into integration |
| 2537f072 | 15-Feb-2023 |
Akshay Belsare <akshay.belsare@amd.com> |
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 ...
|
| 12446ce8 | 15-Feb-2023 |
Akshay Belsare <akshay.belsare@amd.com> |
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 ...
|
| aaf5ce77 | 13-Feb-2023 |
Ronak Jain <ronak.jain@amd.com> |
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 ...
|
| 2616f4b4 | 14-Feb-2023 |
Joanna Farley <joanna.farley@arm.com> |
Merge "fix(zynqmp): enable A53 workaround(errata 1530924)" into integration |
| fb9d95e3 | 14-Feb-2023 |
Joanna Farley <joanna.farley@arm.com> |
Merge "feat(zynqmp): add SMCCC_ARCH_SOC_ID support" into integration |
| 63bb9056 | 04-Oct-2022 |
Andre Przywara <andre.przywara@arm.com> |
feat(qemu): combine TF-A artefacts into ROM file
At the moment the QEMU platform documentation asks users to combine bl1.bin and fip.bin in a certain way to get an image that can be used on the QEMU
feat(qemu): combine TF-A artefacts into ROM file
At the moment the QEMU platform documentation asks users to combine bl1.bin and fip.bin in a certain way to get an image that can be used on the QEMU command line.
Let the build system actually create those files already, if we provide a non-secure payload (BL33), to simplify deployment and spare the user of fragile operations.
Change-Id: Ia35f17b9d60aab41f0d53f1f73a1326a316c4950 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
show more ...
|
| 2c039153 | 13-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
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 ...
|
| a6ff0067 | 16-Jan-2023 |
Chris Kay <chris.kay@arm.com> |
build: permit multiple linker scripts
This change allows platforms to provide more than one linker script to any image utilizing the `MAKE_BL` build system macro.
This is already done by some Media
build: permit multiple linker scripts
This change allows platforms to provide more than one linker script to any image utilizing the `MAKE_BL` build system macro.
This is already done by some MediaTek platforms via the `EXTRA_LINKERFILE` build system variable, which has now been removed.
In its place, additional linker scripts may be added to the `<IMAGE>_LINKER_SCRIPT_SOURCES` variable.
BREAKING-CHANGE: The `EXTRA_LINKERFILE` build system variable has been replaced with the `<IMAGE>_LINKER_SCRIPT_SOURCES` variable. See the commit message for more information.
Change-Id: I3f0b69200d6a4841fd158cd09344ce9e67047271 Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| 82274936 | 16-Jan-2023 |
Chris Kay <chris.kay@arm.com> |
build: clarify linker script generation
The following build system variables have been renamed:
- `LINKERFILE` -> `DEFAULT_LINKER_SCRIPT` - `BL_LINKERFILE` -> `DEFAULT_LINKER_SCRIPT_SOURCE` - `<IMA
build: clarify linker script generation
The following build system variables have been renamed:
- `LINKERFILE` -> `DEFAULT_LINKER_SCRIPT` - `BL_LINKERFILE` -> `DEFAULT_LINKER_SCRIPT_SOURCE` - `<IMAGE>_LINKERFILE` -> `<IMAGE>_DEFAULT_LINKER_SCRIPT_SOURCE`
These new names better reflect how each variable is used:
1. the default linker script is passed via `-dT` instead of `-T` 2. linker script source files are first preprocessed
Additionally, linker scripts are now placed in the build directory relative to where they exist in the source directory. For example, the `bl32/sp_min/sp_min.ld.S` would now preprocess to `sp_min/sp_min.ld` instead of just `bl32.ld`
BREAKING-CHANGE: The `LINKERFILE`, `BL_LINKERFILE` and `<IMAGE_LINKERFILE>` build system variables have been renamed. See the commit message for more information.
Change-Id: If8cef65dcb8820e8993736702c8741e97a66e6cc Signed-off-by: Chris Kay <chris.kay@arm.com>
show more ...
|
| af4fee04 | 10-Feb-2023 |
Sandrine Bailleux <sandrine.bailleux@arm.com> |
Merge changes from topic "mb/tos-fw-config-load-refactor" into integration
* changes: feat(spmd): map SPMC manifest region as EL3_PAS feat(fvp): update device tree with load addresses of TOS_FW
Merge changes from topic "mb/tos-fw-config-load-refactor" into integration
* changes: feat(spmd): map SPMC manifest region as EL3_PAS feat(fvp): update device tree with load addresses of TOS_FW config refactor(fvp): rename the DTB info structure member feat(fconf): rename 'ns-load-address' to 'secondary-load-address'
show more ...
|
| d8133d77 | 09-Feb-2023 |
Michal Simek <michal.simek@amd.com> |
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 ...
|