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>
The Device Present (DP) field is set to '1' after host controller
receive 'SUCCESS' return code on the response of the DME_LINKSTARTUP UIC
CMD during host controller initialization.
JEDEC Standard No. 223E
Page 28
Signed-off-by: Jorge Troncoso <jatron@google.com>
Change-Id: I9db0374c1df3530d64187b9e449cde3b27d63072
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>
Added few missed links for Security Advisories.
Change-Id: I9cab72b70a518273cbb1a291142f452198427127
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.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>
The docs say 3 is valid, but it is not. Jammy uses 3.10 so pin it to
that.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I73530750065294eb511d88318ba86a6c50c8aa7d
Specifying build.tools is mandatory. We use python, so use the latest
one available. For ubuntu 22.04 that should be 3.10 or thereabouts.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Ifd184b9f3b2d8e91182ccb73c47b148e4aeaff05
Readthedocs uses weird defaults and the web interface gives limited
configuration options. Add the config file to allow them to be changed.
Bump build os image to Ubuntu 22.04 to be in line with the CI.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: I1a620b15ab3924244f305056096024fe117c63dd
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>
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>
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>
All these macro are unused that's why remove them.
Change-Id: I843cc7c1a592c47376a01c52f45b6d59da80772b
Signed-off-by: Michal Simek <michal.simek@amd.com>
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>
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>
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
This change communicates the common and maximum page sizes to the
linker, which allows us to use the built-in constants that it provides
to deal with page alignments.
We only support 4K pages today so the fact these are fixed is not too
much of an issue, but we will need to revisit this if we ever support
other page sizes.
Change-Id: I3358c51e70df794025ddf25209ae0e2a96550b0e
Signed-off-by: Chris Kay <chris.kay@arm.com>
