Building ATF to DDR location

For ZYNQMP:

By default, the Arm-trusted firmware builds for OCM space at address 0xFFFEA000. But, with DEBUG flag set to 1, it can't fit in OCM, so by default with DEBUG=1, it builds for DDR location 0x1000 with build flag DEBUG=1 mentioned while building. Alternatively, user has always an option to build for the location of their choice by specifying  the build flags ZYNQMP_ATF_MEM_BASE, ZYNQMP_ATF_MEM_SIZE while building. The flag ZYNQMP_ATF_MEM_BASE specifies the base address of ATF and flag ZYNQMP_ATF_MEM_SIZE specifies the maximum size the ATF image can be.

Example build command:

• make CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp bl31 ZYNQMP_ATF_MEM_BASE=0x10000 ZYNQMP_ATF_MEM_SIZE=0x40000

The above commands builds ATF for DDR location 0x10000 with image size restricted to 0x40000 which means ATF image can span from 0x10000 to 0x50000 in DDR.

For VERSAL:

By default, the Arm-trusted firmware builds for OCM space at address 0xFFFEA000. Currently it can fit in OCM, so with DEBUG=1 it builds for the location 0xFFFEA0000. Alternatively, user has always an option to build for the location of their choice by specifying  the build flags VERSAL_ATF_MEM_BASE, VERSAL_ATF_MEM_SIZE while building. The flag VERSAL_ATF_MEM_BASE specifies the base address of ATF and flag VERSAL_ATF_MEM_SIZE specifies the maximum size the ATF image can be.

Example build command:

• make CROSS_COMPILE=aarch64-none-elf- PLAT=versal bl31 VERSAL_ATF_MEM_BASE=0x10000 VERSAL_ATF_MEM_SIZE=0x40000

The above commands builds ATF for DDR location 0x10000 with image size restricted to 0x40000 which means ATF image can span from 0x10000 to 0x50000 in DDR.

SMC Handling

SMC(Secure Monitor call) is an instruction which is used to generate a synchronous exception which will be handled by Secure Monitor code running in EL3. The SMC will generally be invoked by a software running in Normal world/any Secure software (ex: EL1-Secure) for access to functionality which has to be handled in secure level i.e EL3. The arguments and return values are passed in Aarch64 general purpose registers. Once the smc is handled by the ATF, the result from this will be passed on to a Trusted OS or some other entity in the secure software stack.

PSCI(Power State Coordination Interface)

As of now, ATF supports PSCI standard 1.0. All PSCI operations can be performed using corresponding SMC from upper level software. Xilinx ATF handles power management related psci ops (ex: cpu standy, cpu suspend, power on, power off, system off, system reset etc..) in PMU FW and ATF take care of passing the respective operation to PMUFW using IPI.

For more information on PSCI, please refer to PSCI specification at http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf

For information on PSCI implemenation in ATF , please refer to docs/psci-lib-integration-guide.md and psci-pd-tree.md.

Zynq US+ Power Management

Below are the Zynq US+ specific SMC ID's list which are mostly the Power Management functionalities that are being handled by ATF through SMC calls from upper level software. For all the SMC ID's in ZynqMP, the ATF acts a pass through for handling it in Platform Management Unit(PMU) Firmware. Upon receiving the Synchronous exception through SMC, ATF checks for the SMC ID and accordingly communicates with PMU through IPI for handling it in PMU firmware and gets the response/result from it to pass the same to upper level software. More details on the functionalities of each can be found in Chapter11 Power Management Framework of Zynq UltraScale+ MPSoCSoftware Developer Guide (ug1137).

Versal Pin control

In Versal, the pin control and configurations are carried out at higher privilege level by performing corresponding SMC's from the higher level Linux. The Below SMC's are responsible for pin control and configurations. Here ATF calls MMIO read/write to perform pinmux and pin configurations.

Release Notes

• 2017.3 Release Notes
• 2017.4 Release Notes
• 2018.1 Release Notes
• 2018.2 Release Notes
• 2018.3 Release Notes

NOTE

Vivado allows assigning different IPI channels to each processor. So APU can be assigned any channel based on user's choice and the XPPU is configured accordingly to enforce this allocation. However, ATF uses a fixed IPI configuration without any way for user to specify the IPI slot. So, user has to modify this explicitly if there are any modification from default channel allocation. The below definitions in ATF file (plat/xilinx/zynqmp/pm_service/pm_ipi.c) has to be modified if any change is performed during IPI channel allocation.

#define IPI_BUFFER_RPU_0_BASE (IPI_BUFFER_BASEADDR + 0x0U)
#define IPI_BUFFER_RPU_1_BASE (IPI_BUFFER_BASEADDR + 0x200U)
#define IPI_BUFFER_APU_BASE (IPI_BUFFER_BASEADDR + 0x400U)
#define IPI_BUFFER_PL_0_BASE (IPI_BUFFER_BASEADDR + 0x600U)
#define IPI_BUFFER_PL_1_BASE (IPI_BUFFER_BASEADDR + 0x800U)
#define IPI_BUFFER_PL_2_BASE (IPI_BUFFER_BASEADDR + 0xA00U)
#define IPI_BUFFER_PL_3_BASE (IPI_BUFFER_BASEADDR + 0xC00U)
#define IPI_BUFFER_PMU_BASE (IPI_BUFFER_BASEADDR + 0xE00U)

Known Issues(If any)