diff options
Diffstat (limited to 'docs/plat')
| -rw-r--r-- | docs/plat/hikey.rst | 156 | ||||
| -rw-r--r-- | docs/plat/hikey960.rst | 172 | ||||
| -rw-r--r-- | docs/plat/nvidia-tegra.rst | 98 | ||||
| -rw-r--r-- | docs/plat/qemu.rst | 48 | ||||
| -rw-r--r-- | docs/plat/socionext-uniphier.rst | 124 | ||||
| -rw-r--r-- | docs/plat/xilinx-zynqmp.rst | 67 |
6 files changed, 665 insertions, 0 deletions
diff --git a/docs/plat/hikey.rst b/docs/plat/hikey.rst new file mode 100644 index 00000000..027e14c7 --- /dev/null +++ b/docs/plat/hikey.rst @@ -0,0 +1,156 @@ +Description +=========== + +HiKey is one of 96boards. Hisilicon Kirin6220 processor is installed on HiKey. + +More information are listed in `link`_. + +How to build +============ + +Code Locations +-------------- + +- ARM Trusted Firmware: + `link <https://github.com/ARM-software/arm-trusted-firmware>`__ + +- edk2: + `link <https://github.com/96boards-hikey/edk2/tree/testing/hikey960_v2.5>`__ + +- OpenPlatformPkg: + `link <https://github.com/96boards-hikey/OpenPlatformPkg/tree/testing/hikey960_v1.3.4>`__ + +- l-loader: + `link <https://github.com/96boards-hikey/l-loader/tree/testing/hikey960_v1.2>`__ + +- uefi-tools: + `link <https://github.com/96boards-hikey/uefi-tools/tree/testing/hikey960_v1>`__ + +- atf-fastboot: + `link <https://github.com/96boards-hikey/atf-fastboot/tree/master>`__ + +Build Procedure +--------------- + +- Fetch all the above repositories into local host. + Make all the repositories in the same ${BUILD\_PATH}. + +- Create the symbol link to OpenPlatformPkg in edk2. + + .. code:: shell + + $cd ${BUILD_PATH}/edk2 + $ln -sf ../OpenPlatformPkg + +- Prepare AARCH64 && AARCH32 toolchain. Prepare python. + +- If your hikey hardware is built by CircuitCo, update *uefi-tools/platform.config* first. *(optional)* + **Uncomment the below sentence. Otherwise, UEFI can't output messages on serial + console on hikey.** + + .. code:: shell + + BUILDFLAGS=-DSERIAL_BASE=0xF8015000 + + If your hikey hardware is built by LeMarker, nothing to do. + +- Build it as debug mode. Create your own build script file or you could refer to **build\_uefi.sh** in l-loader git repository. + + .. code:: shell + + BUILD_OPTION=DEBUG + export AARCH64_TOOLCHAIN=GCC5 + export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools + export EDK2_DIR=${BUILD_PATH}/edk2 + EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey/${BUILD_OPTION}_${AARCH64_TOOLCHAIN} + # Build fastboot for ARM Trust Firmware. It's used for recovery mode. + cd ${BUILD_PATH}/atf-fastboot + CROSS_COMPILE=aarch64-linux-gnu- make PLAT=hikey DEBUG=1 + # Convert DEBUG/RELEASE to debug/release + FASTBOOT_BUILD_OPTION=$(echo ${BUILD_OPTION} | tr '[A-Z]' '[a-z]') + cd ${EDK2_DIR} + # Build UEFI & ARM Trust Firmware + ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey + # Generate l-loader.bin + cd ${BUILD_PATH}/l-loader + ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin + ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin + ln -sf ${BUILD_PATH}/atf-fastboot/build/hikey/${FASTBOOT_BUILD_OPTION}/bl1.bin fastboot.bin + python gen_loader.py -o l-loader.bin --img_bl1=bl1.bin --img_ns_bl1u=BL33_AP_UEFI.fd + arm-linux-gnueabihf-gcc -c -o start.o start.S + arm-linux-gnueabihf-ld -Bstatic -Tl-loader.lds -Ttext 0xf9800800 start.o -o loader + arm-linux-gnueabihf-objcopy -O binary loader temp + python gen_loader_hikey.py -o l-loader.bin --img_loader=temp --img_bl1=bl1.bin --img_ns_bl1u=fastboot.bin + +- Generate partition table for aosp. The eMMC capacity is either 4GB or 8GB. Just change "aosp-4g" to "linux-4g" for debian. + + .. code:: shell + + $PTABLE=aosp-4g SECTOR_SIZE=512 bash -x generate_ptable.sh + +Setup Console +------------- + +- Install ser2net. Use telnet as the console since UEFI fails to display Boot Manager GUI in minicom. **If you don't need Boot Manager GUI, just ignore this section.** + + .. code:: shell + + $sudo apt-get install ser2net + +- Configure ser2net. + + .. code:: shell + + $sudo vi /etc/ser2net.conf + + Append one line for serial-over-USB in below. + *#ser2net.conf* + + .. code:: shell + + 2004:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner + +- Open the console. + + .. code:: shell + + $telnet localhost 2004 + + And you could open the console remotely, too. + +Flush images in recovery mode +----------------------------- + +- Make sure Pin3-Pin4 on J15 are connected for recovery mode. Then power on HiKey. + +- Remove the modemmanager package. This package may cause the idt tool failure. + + .. code:: shell + + $sudo apt-get purge modemmanager + +- Run the command to download l-loader.bin into HiKey. + + .. code:: shell + + $sudo python hisi-idt.py -d /dev/ttyUSB1 --img1 l-loader.bin + +- Update images. All aosp or debian images could be fetched from `link <https://builds.96boards.org/>`__. + + .. code:: shell + + $sudo fastboot flash ptable prm_ptable.img + $sudo fastboot flash fastboot fip.bin + $sudo fastboot flash boot boot.img + $sudo fastboot flash cache cache.img + $sudo fastboot flash system system.img + $sudo fastboot flash userdata userdata.img + +Boot UEFI in normal mode +------------------------ + +- Make sure Pin3-Pin4 on J15 are open for normal boot mode. Then power on HiKey. + +- Reference `link <https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-ATF-UEFI-build-from-source.md>`__ + +.. _link: https://github.com/96boards/documentation/blob/master/ConsumerEdition/HiKey/Quickstart/README.md diff --git a/docs/plat/hikey960.rst b/docs/plat/hikey960.rst new file mode 100644 index 00000000..c28ef3ae --- /dev/null +++ b/docs/plat/hikey960.rst @@ -0,0 +1,172 @@ +Description +=========== + +HiKey960 is one of 96boards. Hisilicon Hi3660 processor is installed on HiKey960. + +More information are listed in `link`_. + +How to build +============ + +Code Locations +-------------- + +- ARM Trusted Firmware: + `link <https://github.com/ARM-software/arm-trusted-firmware>`__ + +- edk2: + `link <https://github.com/96boards-hikey/edk2/tree/testing/hikey960_v2.5>`__ + +- OpenPlatformPkg: + `link <https://github.com/96boards-hikey/OpenPlatformPkg/tree/testing/hikey960_v1.3.4>`__ + +- l-loader: + `link <https://github.com/96boards-hikey/l-loader/tree/testing/hikey960_v1.2>`__ + +- uefi-tools: + `link <https://github.com/96boards-hikey/uefi-tools/tree/hikey960_v1>`__ + +Build Procedure +--------------- + +- Fetch all the above 5 repositories into local host. + Make all the repositories in the same ${BUILD\_PATH}. + +- Create the symbol link to OpenPlatformPkg in edk2. + + .. code:: shell + + $cd ${BUILD_PATH}/edk2 + $ln -sf ../OpenPlatformPkg + +- Prepare AARCH64 toolchain. + +- If your hikey960 hardware is v1, update *uefi-tools/platform.config* first. *(optional)* + **Uncomment the below sentence. Otherwise, UEFI can't output messages on serial + console on hikey960 v1.** + + .. code:: shell + + BUILDFLAGS=-DSERIAL_BASE=0xFDF05000 + + If your hikey960 hardware is v2 or newer, nothing to do. + +- Build it as debug mode. Create script file for build. + + .. code:: shell + + BUILD_OPTION=DEBUG + export AARCH64_TOOLCHAIN=GCC48 + export UEFI_TOOLS_DIR=${BUILD_PATH}/uefi-tools + export EDK2_DIR=${BUILD_PATH}/edk2 + EDK2_OUTPUT_DIR=${EDK2_DIR}/Build/HiKey960/${BUILD_OPTION}_${AARCH64_TOOLCHAIN} + cd ${EDK2_DIR} + # Build UEFI & ARM Trust Firmware + ${UEFI_TOOLS_DIR}/uefi-build.sh -b ${BUILD_OPTION} -a ../arm-trusted-firmware hikey960 + # Generate l-loader.bin + cd ${BUILD_PATH}/l-loader + ln -sf ${EDK2_OUTPUT_DIR}/FV/bl1.bin + ln -sf ${EDK2_OUTPUT_DIR}/FV/fip.bin + ln -sf ${EDK2_OUTPUT_DIR}/FV/BL33_AP_UEFI.fd + python gen_loader.py -o l-loader.bin --img_bl1=bl1.bin --img_ns_bl1u=BL33_AP_UEFI.fd + +- Generate partition table. + *Make sure that you're using the sgdisk in the l-loader directory.* + + .. code:: shell + + $PTABLE=aosp-32g SECTOR_SIZE=4096 SGDISK=./sgdisk bash -x generate_ptable.sh + +Setup Console +------------- + +- Install ser2net. Use telnet as the console since UEFI will output window + that fails to display in minicom. + + .. code:: shell + + $sudo apt-get install ser2net + +- Configure ser2net. + + .. code:: shell + + $sudo vi /etc/ser2net.conf + + Append one line for serial-over-USB in *#ser2net.conf* + + :: + + 2004:telnet:0:/dev/ttyUSB0:115200 8DATABITS NONE 1STOPBIT banner + +- Open the console. + + .. code:: shell + + $telnet localhost 2004 + + And you could open the console remotely, too. + +Boot UEFI in recovery mode +-------------------------- + +- Fetch that are used in recovery mode. The code location is in below. + `link <https://github.com/96boards-hikey/tools-images-hikey960>`__ + +- Generate l-loader.bin. + + .. code:: shell + + $cd tools-images-hikey960 + $ln -sf ${BUILD_PATH}/l-loader/l-loader.bin + +- Prepare config file. + + .. code:: shell + + $vi config + # The content of config file + ./sec_user_xloader.img 0x00020000 + ./sec_uce_boot.img 0x6A908000 + ./l-loader.bin 0x1AC00000 + +- Remove the modemmanager package. This package may causes hikey\_idt tool failure. + + .. code:: shell + + $sudo apt-get purge modemmanager + +- Run the command to download l-loader.bin into HiKey960. + + .. code:: shell + + $sudo ./hikey_idt -c config -p /dev/ttyUSB1 + +- UEFI running in recovery mode. + When prompt '.' is displayed on console, press hotkey 'f' in keyboard. Then Android fastboot app is running. + The timeout of prompt '.' is 10 seconds. + +- Update images. + + .. code:: shell + + $sudo fastboot flash ptable prm_ptable.img + $sudo fastboot flash xloader sec_xloader.img + $sudo fastboot flash fastboot l-loader.bin + $sudo fastboot flash fip fip.bin + $sudo fastboot flash boot boot.img + $sudo fastboot flash cache cache.img + $sudo fastboot flash system system.img + $sudo fastboot flash userdata userdata.img + +- Notice: UEFI could also boot kernel in recovery mode, but BL31 isn't loaded in + recovery mode. + +Boot UEFI in normal mode +------------------------ + +- Make sure "Boot Mode" switch is OFF for normal boot mode. Then power on HiKey960. + +- Reference `link <https://github.com/96boards-hikey/tools-images-hikey960/blob/master/build-from-source/README-ATF-UEFI-build-from-source.md>`__ + +.. _link: http://www.96boards.org/documentation/ConsumerEdition/HiKey960/README.md diff --git a/docs/plat/nvidia-tegra.rst b/docs/plat/nvidia-tegra.rst new file mode 100644 index 00000000..7aac7e53 --- /dev/null +++ b/docs/plat/nvidia-tegra.rst @@ -0,0 +1,98 @@ +Tegra SoCs - Overview +===================== + +- .. rubric:: T210 + :name: t210 + +T210 has Quad ARM® Cortex®-A57 cores in a switched configuration with a +companion set of quad ARM Cortex-A53 cores. The Cortex-A57 and A53 cores +support ARMv8, executing both 64-bit Aarch64 code, and 32-bit Aarch32 code +including legacy ARMv7 applications. The Cortex-A57 processors each have +48 KB Instruction and 32 KB Data Level 1 caches; and have a 2 MB shared +Level 2 unified cache. The Cortex-A53 processors each have 32 KB Instruction +and 32 KB Data Level 1 caches; and have a 512 KB shared Level 2 unified cache. + +- .. rubric:: T132 + :name: t132 + +Denver is NVIDIA's own custom-designed, 64-bit, dual-core CPU which is +fully ARMv8 architecture compatible. Each of the two Denver cores +implements a 7-way superscalar microarchitecture (up to 7 concurrent +micro-ops can be executed per clock), and includes a 128KB 4-way L1 +instruction cache, a 64KB 4-way L1 data cache, and a 2MB 16-way L2 +cache, which services both cores. + +Denver implements an innovative process called Dynamic Code Optimization, +which optimizes frequently used software routines at runtime into dense, +highly tuned microcode-equivalent routines. These are stored in a +dedicated, 128MB main-memory-based optimization cache. After being read +into the instruction cache, the optimized micro-ops are executed, +re-fetched and executed from the instruction cache as long as needed and +capacity allows. + +Effectively, this reduces the need to re-optimize the software routines. +Instead of using hardware to extract the instruction-level parallelism +(ILP) inherent in the code, Denver extracts the ILP once via software +techniques, and then executes those routines repeatedly, thus amortizing +the cost of ILP extraction over the many execution instances. + +Denver also features new low latency power-state transitions, in addition +to extensive power-gating and dynamic voltage and clock scaling based on +workloads. + +Directory structure +=================== + +- plat/nvidia/tegra/common - Common code for all Tegra SoCs +- plat/nvidia/tegra/soc/txxx - Chip specific code + +Trusted OS dispatcher +===================== + +Tegra supports multiple Trusted OS', Trusted Little Kernel (TLK) being one of +them. In order to include the 'tlkd' dispatcher in the image, pass 'SPD=tlkd' +on the command line while preparing a bl31 image. This allows other Trusted OS +vendors to use the upstream code and include their dispatchers in the image +without changing any makefiles. + +Preparing the BL31 image to run on Tegra SoCs +============================================= + +.. code:: shell + + CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf- make PLAT=tegra \ + TARGET_SOC=<target-soc e.g. t210|t132> SPD=<dispatcher e.g. tlkd> bl31 + +Platforms wanting to use different TZDRAM\_BASE, can add ``TZDRAM_BASE=<value>`` +to the build command line. + +The Tegra platform code expects a pointer to the following platform specific +structure via 'x1' register from the BL2 layer which is used by the +bl31\_early\_platform\_setup() handler to extract the TZDRAM carveout base and +size for loading the Trusted OS and the UART port ID to be used. The Tegra +memory controller driver programs this base/size in order to restrict NS +accesses. + +typedef struct plat\_params\_from\_bl2 { +/\* TZ memory size */ +uint64\_t tzdram\_size; +/* TZ memory base */ +uint64\_t tzdram\_base; +/* UART port ID \*/ +int uart\_id; +} plat\_params\_from\_bl2\_t; + +Power Management +================ + +The PSCI implementation expects each platform to expose the 'power state' +parameter to be used during the 'SYSTEM SUSPEND' call. The state-id field +is implementation defined on Tegra SoCs and is preferably defined by +tegra\_def.h. + +Tegra configs +============= + +- 'tegra\_enable\_l2\_ecc\_parity\_prot': This flag enables the L2 ECC and Parity + Protection bit, for ARM Cortex-A57 CPUs, during CPU boot. This flag will + be enabled by Tegrs SoCs during 'Cluster power up' or 'System Suspend' exit. diff --git a/docs/plat/qemu.rst b/docs/plat/qemu.rst new file mode 100644 index 00000000..4e2cd7c5 --- /dev/null +++ b/docs/plat/qemu.rst @@ -0,0 +1,48 @@ +ARM Trusted Firmware for QEMU virt ARMv8-A +========================================== + +ARM Trusted Firmware implements the EL3 firmware layer for QEMU virt +ARMv8-A. BL1 is used as the BootROM, supplied with the -bios argument. +When QEMU starts all CPUs are released simultaneously, BL1 selects a +primary CPU to handle the boot and the secondaries are placed in a polling +loop to be released by normal world via PSCI. + +BL2 edits the Flattened Device Tree, FDT, generated by QEMU at run-time to +add a node describing PSCI and also enable methods for the CPUs. + +An ARM64 defonfig v4.5 Linux kernel is known to boot, FTD doesn't need to be +provided as it's generated by QEMU. + +Current limitations: + +- Only cold boot is supported +- No build instructions for QEMU\_EFI.fd and rootfs-arm64.cpio.gz +- No instructions for how to load a BL32 (Secure Payload) + +``QEMU_EFI.fd`` can be dowloaded from +http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-KERNEL-AARCH64/RELEASE_GCC49/QEMU_EFI.fd + +Boot binaries, except BL1, are primarily loaded via semi-hosting so all +binaries has to reside in the same directory as QEMU is started from. This +is conveniently achieved with symlinks the local names as: + +- ``bl2.bin`` -> BL2 +- ``bl31.bin`` -> BL31 +- ``bl33.bin`` -> BL33 (``QEMU_EFI.fd``) +- ``Image`` -> linux/Image + +To build: + +:: + + make CROSS_COMPILE=aarch64-none-elf- PLAT=qemu + +To start (QEMU v2.6.0): + +:: + + qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57 \ + -kernel Image \ + -append console=ttyAMA0,38400 keep_bootcon root=/dev/vda2 \ + -initrd rootfs-arm64.cpio.gz -smp 2 -m 1024 -bios bl1.bin \ + -d unimp -semihosting-config enable,target=native diff --git a/docs/plat/socionext-uniphier.rst b/docs/plat/socionext-uniphier.rst new file mode 100644 index 00000000..fb6ebe5e --- /dev/null +++ b/docs/plat/socionext-uniphier.rst @@ -0,0 +1,124 @@ +ARM Trusted Firmware for Socionext UniPhier SoCs +================================================ + +Socionext UniPhier ARMv8-A SoCs use ARM Trusted Firmware as the secure world +firmware, supporting BL1, BL2, and BL31. + +UniPhier SoC family implements its internal boot ROM, so BL1 is used as pseudo +ROM (i.e. runs in RAM). The internal boot ROM loads 64KB `1`_ image from a +non-volatile storage to the on-chip SRAM. Unfortunately, BL1 does not fit in +the 64KB limit if `Trusted Board Boot`_ (TBB) is enabled. To solve this problem, +Socionext provides a first stage loader called `UniPhier BL`_. This loader runs +in the on-chip SRAM, initializes the DRAM, expands BL1 there, and hands the +control over to it. Therefore, all images of ARM Trusted Firmware run in DRAM. + +The UniPhier platform works with/without TBB. See below for the build process +of each case. The image authentication for the UniPhier platform fully +complies with the Trusted Board Boot Requirements (TBBR) specification. + +The UniPhier BL does not implement the authentication functionality, that is, +it can not verify the BL1 image by itself. Instead, the UniPhier BL assures +the BL1 validity in a different way; BL1 is GZIP-compressed and appended to +the UniPhier BL. The concatenation of the UniPhier BL and the compressed BL1 +fits in the 64KB limit. The concatenated image is loaded by the boot ROM +(and verified if the chip fuses are blown). + +:: + + to the lowest common denominator. + +Boot Flow +--------- + +#. The Boot ROM + +This is hard-wired ROM, so never corrupted. It loads the UniPhier BL (with +compressed-BL1 appended) into the on-chip SRAM. If the SoC fuses are blown, +the image is verified by the SoC's own method. + +#. UniPhier BL + +This runs in the on-chip SRAM. After the minimum SoC initialization and DRAM +setup, it decompresses the appended BL1 image into the DRAM, then jumps to +the BL1 entry. + +#. BL1 + +This runs in the DRAM. It extracts BL2 from FIP (Firmware Image Package). +If TBB is enabled, the BL2 is authenticated by the standard mechanism of ARM +Trusted Firmware. + +#. BL2, BL31, and more + +They all run in the DRAM, and are authenticated by the standard mechanism if +TBB is enabled. See `Firmware Design`_ for details. + +Basic Build +----------- + +BL1 must be compressed for the reason above. The UniPhier's platform makefile +provides a build target ``bl1_gzip`` for this. + +For a non-secure boot loader (aka BL33), U-Boot is well supported for UniPhier +SoCs. The U-Boot image (``u-boot.bin``) must be built in advance. For the build +procedure of U-Boot, refer to the document in the `U-Boot`_ project. + +To build minimum functionality for UniPhier (without TBB): + +:: + + make CROSS_COMPILE=<gcc-prefix> PLAT=uniphier BL33=<path-to-BL33> bl1_gzip fip + +Output images: + +- ``bl1.bin.gzip`` +- ``fip.bin`` + +Optional features +----------------- + +- Trusted Board Boot + +`mbed TLS`_ is needed as the cryptographic and image parser modules. +Refer to the `User Guide`_ for the appropriate version of mbed TLS. + +To enable TBB, add the following options to the build command: + +:: + + TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 MBEDTLS_DIR=<path-to-mbedtls> + +- System Control Processor (SCP) + +If desired, FIP can include an SCP BL2 image. If BL2 finds an SCP BL2 image +in FIP, BL2 loads it into DRAM and kicks the SCP. Most of UniPhier boards +still work without SCP, but SCP provides better power management support. + +To include SCP\_BL2, add the following option to the build command: + +:: + + SCP_BL2=<path-to-SCP> + +- BL32 (Secure Payload) + +To enable BL32, add the following option to the build command: + +:: + + SPD=<spd> BL32=<path-to-BL32> + +If you use TSP for BL32, ``BL32=<path-to-BL32>`` is not required. Just add the +following: + +:: + + SPD=tspd + +.. _1: Some%20SoCs%20can%20load%2080KB,%20but%20the%20software%20implementation%20must%20be%20aligned +.. _Trusted Board Boot: ../trusted-board-boot.rst +.. _UniPhier BL: https://github.com/uniphier/uniphier-bl +.. _Firmware Design: ../firmware-design.rst +.. _U-Boot: https://www.denx.de/wiki/U-Boot +.. _mbed TLS: https://tls.mbed.org/ +.. _User Guide: ../user-guide.rst diff --git a/docs/plat/xilinx-zynqmp.rst b/docs/plat/xilinx-zynqmp.rst new file mode 100644 index 00000000..b9c7825b --- /dev/null +++ b/docs/plat/xilinx-zynqmp.rst @@ -0,0 +1,67 @@ +ARM Trusted Firmware for Xilinx Zynq UltraScale+ MPSoC +====================================================== + +ARM Trusted Firmware implements the EL3 firmware layer for Xilinx Zynq +UltraScale + MPSoC. +The platform only uses the runtime part of ATF as ZynqMP already has a +BootROM (BL1) and FSBL (BL2). + +BL31 is ATF. +BL32 is an optional Secure Payload. +BL33 is the non-secure world software (U-Boot, Linux etc). + +To build: + +.. code:: bash + + make ERROR_DEPRECATED=1 CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp bl31 + +To build bl32 TSP you have to rebuild bl31 too: + +.. code:: bash + + make ERROR_DEPRECATED=1 CROSS_COMPILE=aarch64-none-elf- PLAT=zynqmp SPD=tspd bl31 bl32 + +ZynqMP platform specific build options +====================================== + +- ``ZYNQMP_ATF_MEM_BASE``: Specifies the base address of the bl31 binary. +- ``ZYNQMP_ATF_MEM_SIZE``: Specifies the size of the memory region of the bl31 binary. +- ``ZYNQMP_BL32_MEM_BASE``: Specifies the base address of the bl32 binary. +- ``ZYNQMP_BL32_MEM_SIZE``: Specifies the size of the memory region of the bl32 binary. + +- ``ZYNQMP_CONSOLE``: Select the console driver. Options: + + - ``cadence``, ``cadence0``: Cadence UART 0 + - ``cadence1`` : Cadence UART 1 + +FSBL->ATF Parameter Passing +=========================== + +The FSBL populates a data structure with image information for the ATF. The ATF +uses that data to hand off to the loaded images. The address of the handoff data +structure is passed in the ``PMU_GLOBAL.GLOBAL_GEN_STORAGE6`` register. The +register is free to be used by other software once the ATF is bringing up +further firmware images. + +Power Domain Tree +================= + +The following power domain tree represents the power domain model used by the +ATF for ZynqMP: + +:: + + +-+ + |0| + +-+ + +-------+---+---+-------+ + | | | | + | | | | + v v v v + +-+ +-+ +-+ +-+ + |0| |1| |2| |3| + +-+ +-+ +-+ +-+ + +The 4 leaf power domains represent the individual A53 cores, while resources +common to the cluster are grouped in the power domain on the top. |