diff options
Diffstat (limited to 'docs/plat')
32 files changed, 1924 insertions, 514 deletions
diff --git a/docs/plat/arm/arm-build-options.rst b/docs/plat/arm/arm-build-options.rst new file mode 100644 index 000000000..d24ad231d --- /dev/null +++ b/docs/plat/arm/arm-build-options.rst @@ -0,0 +1,114 @@ +Arm Development Platform Build Options +====================================== + +Arm Platform Build Options +-------------------------- + +- ``ARM_BL31_IN_DRAM``: Boolean option to select loading of BL31 in TZC secured + DRAM. By default, BL31 is in the secure SRAM. Set this flag to 1 to load + BL31 in TZC secured DRAM. If TSP is present, then setting this option also + sets the TSP location to DRAM and ignores the ``ARM_TSP_RAM_LOCATION`` build + flag. + +- ``ARM_CONFIG_CNTACR``: boolean option to unlock access to the ``CNTBase<N>`` + frame registers by setting the ``CNTCTLBase.CNTACR<N>`` register bits. The + frame number ``<N>`` is defined by ``PLAT_ARM_NSTIMER_FRAME_ID``, which + should match the frame used by the Non-Secure image (normally the Linux + kernel). Default is true (access to the frame is allowed). + +- ``ARM_DISABLE_TRUSTED_WDOG``: boolean option to disable the Trusted Watchdog. + By default, Arm platforms use a watchdog to trigger a system reset in case + an error is encountered during the boot process (for example, when an image + could not be loaded or authenticated). The watchdog is enabled in the early + platform setup hook at BL1 and disabled in the BL1 prepare exit hook. The + Trusted Watchdog may be disabled at build time for testing or development + purposes. + +- ``ARM_LINUX_KERNEL_AS_BL33``: The Linux kernel expects registers x0-x3 to + have specific values at boot. This boolean option allows the Trusted Firmware + to have a Linux kernel image as BL33 by preparing the registers to these + values before jumping to BL33. This option defaults to 0 (disabled). For + AArch64 ``RESET_TO_BL31`` and for AArch32 ``RESET_TO_SP_MIN`` must be 1 when + using it. If this option is set to 1, ``ARM_PRELOADED_DTB_BASE`` must be set + to the location of a device tree blob (DTB) already loaded in memory. The + Linux Image address must be specified using the ``PRELOADED_BL33_BASE`` + option. + +- ``ARM_PLAT_MT``: This flag determines whether the Arm platform layer has to + cater for the multi-threading ``MT`` bit when accessing MPIDR. When this flag + is set, the functions which deal with MPIDR assume that the ``MT`` bit in + MPIDR is set and access the bit-fields in MPIDR accordingly. Default value of + this flag is 0. Note that this option is not used on FVP platforms. + +- ``ARM_RECOM_STATE_ID_ENC``: The PSCI1.0 specification recommends an encoding + for the construction of composite state-ID in the power-state parameter. + The existing PSCI clients currently do not support this encoding of + State-ID yet. Hence this flag is used to configure whether to use the + recommended State-ID encoding or not. The default value of this flag is 0, + in which case the platform is configured to expect NULL in the State-ID + field of power-state parameter. + +- ``ARM_ROTPK_LOCATION``: used when ``TRUSTED_BOARD_BOOT=1``. It specifies the + location of the ROTPK hash returned by the function ``plat_get_rotpk_info()`` + for Arm platforms. Depending on the selected option, the proper private key + must be specified using the ``ROT_KEY`` option when building the Trusted + Firmware. This private key will be used by the certificate generation tool + to sign the BL2 and Trusted Key certificates. Available options for + ``ARM_ROTPK_LOCATION`` are: + + - ``regs`` : return the ROTPK hash stored in the Trusted root-key storage + registers. The private key corresponding to this ROTPK hash is not + currently available. + - ``devel_rsa`` : return a development public key hash embedded in the BL1 + and BL2 binaries. This hash has been obtained from the RSA public key + ``arm_rotpk_rsa.der``, located in ``plat/arm/board/common/rotpk``. To use + this option, ``arm_rotprivk_rsa.pem`` must be specified as ``ROT_KEY`` + when creating the certificates. + - ``devel_ecdsa`` : return a development public key hash embedded in the BL1 + and BL2 binaries. This hash has been obtained from the ECDSA public key + ``arm_rotpk_ecdsa.der``, located in ``plat/arm/board/common/rotpk``. To + use this option, ``arm_rotprivk_ecdsa.pem`` must be specified as + ``ROT_KEY`` when creating the certificates. + +- ``ARM_TSP_RAM_LOCATION``: location of the TSP binary. Options: + + - ``tsram`` : Trusted SRAM (default option when TBB is not enabled) + - ``tdram`` : Trusted DRAM (if available) + - ``dram`` : Secure region in DRAM (default option when TBB is enabled, + configured by the TrustZone controller) + +- ``ARM_XLAT_TABLES_LIB_V1``: boolean option to compile TF-A with version 1 + of the translation tables library instead of version 2. It is set to 0 by + default, which selects version 2. + +- ``ARM_CRYPTOCELL_INTEG`` : bool option to enable TF-A to invoke Arm® + TrustZone® CryptoCell functionality for Trusted Board Boot on capable Arm + platforms. If this option is specified, then the path to the CryptoCell + SBROM library must be specified via ``CCSBROM_LIB_PATH`` flag. + +For a better understanding of these options, the Arm development platform memory +map is explained in the :ref:`Firmware Design`. + +.. _build_options_arm_css_platform: + +Arm CSS Platform-Specific Build Options +--------------------------------------- + +- ``CSS_DETECT_PRE_1_7_0_SCP``: Boolean flag to detect SCP version + incompatibility. Version 1.7.0 of the SCP firmware made a non-backwards + compatible change to the MTL protocol, used for AP/SCP communication. + TF-A no longer supports earlier SCP versions. If this option is set to 1 + then TF-A will detect if an earlier version is in use. Default is 1. + +- ``CSS_LOAD_SCP_IMAGES``: Boolean flag, which when set, adds SCP_BL2 and + SCP_BL2U to the FIP and FWU_FIP respectively, and enables them to be loaded + during boot. Default is 1. + +- ``CSS_USE_SCMI_SDS_DRIVER``: Boolean flag which selects SCMI/SDS drivers + instead of SCPI/BOM driver for communicating with the SCP during power + management operations and for SCP RAM Firmware transfer. If this option + is set to 1, then SCMI/SDS drivers will be used. Default is 0. + +-------------- + +*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/plat/fvp_ve.rst b/docs/plat/arm/fvp-ve/index.rst index 6abf9e5f7..8ac07418a 100644 --- a/docs/plat/fvp_ve.rst +++ b/docs/plat/arm/fvp-ve/index.rst @@ -78,3 +78,7 @@ Trusted Firmware-A made using the above make commands: -C motherboard.flashloader1.fname=<path_to_fip.bin> \ --data cluster.cpu0=<path_to_zImage>@0x80080000 \ --data cluster.cpu0=<path_to_ramdisk>@0x84000000 + +-------------- + +*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/plat/arm/fvp/index.rst b/docs/plat/arm/fvp/index.rst new file mode 100644 index 000000000..37010e1a5 --- /dev/null +++ b/docs/plat/arm/fvp/index.rst @@ -0,0 +1,637 @@ +Arm Fixed Virtual Platforms (FVP) +================================= + +Fixed Virtual Platform (FVP) Support +------------------------------------ + +This section lists the supported Arm |FVP| platforms. Please refer to the FVP +documentation for a detailed description of the model parameter options. + +The latest version of the AArch64 build of TF-A has been tested on the following +Arm FVPs without shifted affinities, and that do not support threaded CPU cores +(64-bit host machine only). + +.. note:: + The FVP models used are Version 11.6 Build 45, unless otherwise stated. + +- ``FVP_Base_AEMv8A-AEMv8A`` +- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502`` +- ``FVP_Base_RevC-2xAEMv8A`` +- ``FVP_Base_Cortex-A32x4`` +- ``FVP_Base_Cortex-A35x4`` +- ``FVP_Base_Cortex-A53x4`` +- ``FVP_Base_Cortex-A55x4+Cortex-A75x4`` +- ``FVP_Base_Cortex-A55x4`` +- ``FVP_Base_Cortex-A57x1-A53x1`` +- ``FVP_Base_Cortex-A57x2-A53x4`` +- ``FVP_Base_Cortex-A57x4-A53x4`` +- ``FVP_Base_Cortex-A57x4`` +- ``FVP_Base_Cortex-A72x4-A53x4`` +- ``FVP_Base_Cortex-A72x4`` +- ``FVP_Base_Cortex-A73x4-A53x4`` +- ``FVP_Base_Cortex-A73x4`` +- ``FVP_Base_Cortex-A75x4`` +- ``FVP_Base_Cortex-A76x4`` +- ``FVP_Base_Cortex-A76AEx4`` +- ``FVP_Base_Cortex-A76AEx8`` +- ``FVP_Base_Cortex-A77x4`` (Version 11.7 build 36) +- ``FVP_Base_Neoverse-N1x4`` +- ``FVP_Base_Zeusx4`` +- ``FVP_CSS_SGI-575`` (Version 11.3 build 42) +- ``FVP_CSS_SGM-775`` (Version 11.3 build 42) +- ``FVP_RD_E1Edge`` (Version 11.3 build 42) +- ``FVP_RD_N1Edge`` +- ``Foundation_Platform`` + +The latest version of the AArch32 build of TF-A has been tested on the +following Arm FVPs without shifted affinities, and that do not support threaded +CPU cores (64-bit host machine only). + +- ``FVP_Base_AEMv8A-AEMv8A`` +- ``FVP_Base_Cortex-A32x4`` + +.. note:: + The ``FVP_Base_RevC-2xAEMv8A`` FVP only supports shifted affinities, which + is not compatible with legacy GIC configurations. Therefore this FVP does not + support these legacy GIC configurations. + +The *Foundation* and *Base* FVPs can be downloaded free of charge. See the `Arm +FVP website`_. The Cortex-A models listed above are also available to download +from `Arm's website`_. + +.. note:: + The build numbers quoted above are those reported by launching the FVP + with the ``--version`` parameter. + +.. note:: + Linaro provides a ramdisk image in prebuilt FVP configurations and full + file systems that can be downloaded separately. To run an FVP with a virtio + file system image an additional FVP configuration option + ``-C bp.virtioblockdevice.image_path="<path-to>/<file-system-image>`` can be + used. + +.. note:: + The software will not work on Version 1.0 of the Foundation FVP. + The commands below would report an ``unhandled argument`` error in this case. + +.. note:: + FVPs can be launched with ``--cadi-server`` option such that a + CADI-compliant debugger (for example, Arm DS-5) can connect to and control + its execution. + +.. warning:: + Since FVP model Version 11.0 Build 11.0.34 and Version 8.5 Build 0.8.5202 + the internal synchronisation timings changed compared to older versions of + the models. The models can be launched with ``-Q 100`` option if they are + required to match the run time characteristics of the older versions. + +All the above platforms have been tested with `Linaro Release 19.06`_. + +.. _build_options_arm_fvp_platform: + +Arm FVP Platform Specific Build Options +--------------------------------------- + +- ``FVP_CLUSTER_COUNT`` : Configures the cluster count to be used to + build the topology tree within TF-A. By default TF-A is configured for dual + cluster topology and this option can be used to override the default value. + +- ``FVP_INTERCONNECT_DRIVER``: Selects the interconnect driver to be built. The + default interconnect driver depends on the value of ``FVP_CLUSTER_COUNT`` as + explained in the options below: + + - ``FVP_CCI`` : The CCI driver is selected. This is the default + if 0 < ``FVP_CLUSTER_COUNT`` <= 2. + - ``FVP_CCN`` : The CCN driver is selected. This is the default + if ``FVP_CLUSTER_COUNT`` > 2. + +- ``FVP_MAX_CPUS_PER_CLUSTER``: Sets the maximum number of CPUs implemented in + a single cluster. This option defaults to 4. + +- ``FVP_MAX_PE_PER_CPU``: Sets the maximum number of PEs implemented on any CPU + in the system. This option defaults to 1. Note that the build option + ``ARM_PLAT_MT`` doesn't have any effect on FVP platforms. + +- ``FVP_USE_GIC_DRIVER`` : Selects the GIC driver to be built. Options: + + - ``FVP_GIC600`` : The GIC600 implementation of GICv3 is selected + - ``FVP_GICV2`` : The GICv2 only driver is selected + - ``FVP_GICV3`` : The GICv3 only driver is selected (default option) + +- ``FVP_USE_SP804_TIMER`` : Use the SP804 timer instead of the Generic Timer + for functions that wait for an arbitrary time length (udelay and mdelay). + The default value is 0. + +- ``FVP_HW_CONFIG_DTS`` : Specify the path to the DTS file to be compiled + to DTB and packaged in FIP as the HW_CONFIG. See :ref:`Firmware Design` for + details on HW_CONFIG. By default, this is initialized to a sensible DTS + file in ``fdts/`` folder depending on other build options. But some cases, + like shifted affinity format for MPIDR, cannot be detected at build time + and this option is needed to specify the appropriate DTS file. + +- ``FVP_HW_CONFIG`` : Specify the path to the HW_CONFIG blob to be packaged in + FIP. See :ref:`Firmware Design` for details on HW_CONFIG. This option is + similar to the ``FVP_HW_CONFIG_DTS`` option, but it directly specifies the + HW_CONFIG blob instead of the DTS file. This option is useful to override + the default HW_CONFIG selected by the build system. + +Booting Firmware Update images +------------------------------ + +When Firmware Update (FWU) is enabled there are at least 2 new images +that have to be loaded, the Non-Secure FWU ROM (NS-BL1U), and the +FWU FIP. + +The additional fip images must be loaded with: + +:: + + --data cluster0.cpu0="<path_to>/ns_bl1u.bin"@0x0beb8000 [ns_bl1u_base_address] + --data cluster0.cpu0="<path_to>/fwu_fip.bin"@0x08400000 [ns_bl2u_base_address] + +The address ns_bl1u_base_address is the value of NS_BL1U_BASE. +In the same way, the address ns_bl2u_base_address is the value of +NS_BL2U_BASE. + +Booting an EL3 payload +---------------------- + +The EL3 payloads boot flow requires the CPU's mailbox to be cleared at reset for +the secondary CPUs holding pen to work properly. Unfortunately, its reset value +is undefined on the FVP platform and the FVP platform code doesn't clear it. +Therefore, one must modify the way the model is normally invoked in order to +clear the mailbox at start-up. + +One way to do that is to create an 8-byte file containing all zero bytes using +the following command: + +.. code:: shell + + dd if=/dev/zero of=mailbox.dat bs=1 count=8 + +and pre-load it into the FVP memory at the mailbox address (i.e. ``0x04000000``) +using the following model parameters: + +:: + + --data cluster0.cpu0=mailbox.dat@0x04000000 [Base FVPs] + --data=mailbox.dat@0x04000000 [Foundation FVP] + +To provide the model with the EL3 payload image, the following methods may be +used: + +#. If the EL3 payload is able to execute in place, it may be programmed into + flash memory. On Base Cortex and AEM FVPs, the following model parameter + loads it at the base address of the NOR FLASH1 (the NOR FLASH0 is already + used for the FIP): + + :: + + -C bp.flashloader1.fname="<path-to>/<el3-payload>" + + On Foundation FVP, there is no flash loader component and the EL3 payload + may be programmed anywhere in flash using method 3 below. + +#. When using the ``SPIN_ON_BL1_EXIT=1`` loading method, the following DS-5 + command may be used to load the EL3 payload ELF image over JTAG: + + :: + + load <path-to>/el3-payload.elf + +#. The EL3 payload may be pre-loaded in volatile memory using the following + model parameters: + + :: + + --data cluster0.cpu0="<path-to>/el3-payload>"@address [Base FVPs] + --data="<path-to>/<el3-payload>"@address [Foundation FVP] + + The address provided to the FVP must match the ``EL3_PAYLOAD_BASE`` address + used when building TF-A. + +Booting a preloaded kernel image (Base FVP) +------------------------------------------- + +The following example uses a simplified boot flow by directly jumping from the +TF-A to the Linux kernel, which will use a ramdisk as filesystem. This can be +useful if both the kernel and the device tree blob (DTB) are already present in +memory (like in FVP). + +For example, if the kernel is loaded at ``0x80080000`` and the DTB is loaded at +address ``0x82000000``, the firmware can be built like this: + +.. code:: shell + + CROSS_COMPILE=aarch64-none-elf- \ + make PLAT=fvp DEBUG=1 \ + RESET_TO_BL31=1 \ + ARM_LINUX_KERNEL_AS_BL33=1 \ + PRELOADED_BL33_BASE=0x80080000 \ + ARM_PRELOADED_DTB_BASE=0x82000000 \ + all fip + +Now, it is needed to modify the DTB so that the kernel knows the address of the +ramdisk. The following script generates a patched DTB from the provided one, +assuming that the ramdisk is loaded at address ``0x84000000``. Note that this +script assumes that the user is using a ramdisk image prepared for U-Boot, like +the ones provided by Linaro. If using a ramdisk without this header,the ``0x40`` +offset in ``INITRD_START`` has to be removed. + +.. code:: bash + + #!/bin/bash + + # Path to the input DTB + KERNEL_DTB=<path-to>/<fdt> + # Path to the output DTB + PATCHED_KERNEL_DTB=<path-to>/<patched-fdt> + # Base address of the ramdisk + INITRD_BASE=0x84000000 + # Path to the ramdisk + INITRD=<path-to>/<ramdisk.img> + + # Skip uboot header (64 bytes) + INITRD_START=$(printf "0x%x" $((${INITRD_BASE} + 0x40)) ) + INITRD_SIZE=$(stat -Lc %s ${INITRD}) + INITRD_END=$(printf "0x%x" $((${INITRD_BASE} + ${INITRD_SIZE})) ) + + CHOSEN_NODE=$(echo \ + "/ { \ + chosen { \ + linux,initrd-start = <${INITRD_START}>; \ + linux,initrd-end = <${INITRD_END}>; \ + }; \ + };") + + echo $(dtc -O dts -I dtb ${KERNEL_DTB}) ${CHOSEN_NODE} | \ + dtc -O dtb -o ${PATCHED_KERNEL_DTB} - + +And the FVP binary can be run with the following command: + +.. code:: shell + + <path-to>/FVP_Base_AEMv8A-AEMv8A \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C cluster0.NUM_CORES=4 \ + -C cluster1.NUM_CORES=4 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.RVBAR=0x04020000 \ + -C cluster0.cpu1.RVBAR=0x04020000 \ + -C cluster0.cpu2.RVBAR=0x04020000 \ + -C cluster0.cpu3.RVBAR=0x04020000 \ + -C cluster1.cpu0.RVBAR=0x04020000 \ + -C cluster1.cpu1.RVBAR=0x04020000 \ + -C cluster1.cpu2.RVBAR=0x04020000 \ + -C cluster1.cpu3.RVBAR=0x04020000 \ + --data cluster0.cpu0="<path-to>/bl31.bin"@0x04020000 \ + --data cluster0.cpu0="<path-to>/<patched-fdt>"@0x82000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk.img>"@0x84000000 + +Obtaining the Flattened Device Trees +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Depending on the FVP configuration and Linux configuration used, different +FDT files are required. FDT source files for the Foundation and Base FVPs can +be found in the TF-A source directory under ``fdts/``. The Foundation FVP has +a subset of the Base FVP components. For example, the Foundation FVP lacks +CLCD and MMC support, and has only one CPU cluster. + +.. note:: + It is not recommended to use the FDTs built along the kernel because not + all FDTs are available from there. + +The dynamic configuration capability is enabled in the firmware for FVPs. +This means that the firmware can authenticate and load the FDT if present in +FIP. A default FDT is packaged into FIP during the build based on +the build configuration. This can be overridden by using the ``FVP_HW_CONFIG`` +or ``FVP_HW_CONFIG_DTS`` build options (refer to +:ref:`build_options_arm_fvp_platform` for details on the options). + +- ``fvp-base-gicv2-psci.dts`` + + For use with models such as the Cortex-A57-A53 Base FVPs without shifted + affinities and with Base memory map configuration. + +- ``fvp-base-gicv2-psci-aarch32.dts`` + + For use with models such as the Cortex-A32 Base FVPs without shifted + affinities and running Linux in AArch32 state with Base memory map + configuration. + +- ``fvp-base-gicv3-psci.dts`` + + For use with models such as the Cortex-A57-A53 Base FVPs without shifted + affinities and with Base memory map configuration and Linux GICv3 support. + +- ``fvp-base-gicv3-psci-1t.dts`` + + For use with models such as the AEMv8-RevC Base FVP with shifted affinities, + single threaded CPUs, Base memory map configuration and Linux GICv3 support. + +- ``fvp-base-gicv3-psci-dynamiq.dts`` + + For use with models as the Cortex-A55-A75 Base FVPs with shifted affinities, + single cluster, single threaded CPUs, Base memory map configuration and Linux + GICv3 support. + +- ``fvp-base-gicv3-psci-aarch32.dts`` + + For use with models such as the Cortex-A32 Base FVPs without shifted + affinities and running Linux in AArch32 state with Base memory map + configuration and Linux GICv3 support. + +- ``fvp-foundation-gicv2-psci.dts`` + + For use with Foundation FVP with Base memory map configuration. + +- ``fvp-foundation-gicv3-psci.dts`` + + (Default) For use with Foundation FVP with Base memory map configuration + and Linux GICv3 support. + + +Running on the Foundation FVP with reset to BL1 entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``Foundation_Platform`` parameters should be used to boot Linux with +4 CPUs using the AArch64 build of TF-A. + +.. code:: shell + + <path-to>/Foundation_Platform \ + --cores=4 \ + --arm-v8.0 \ + --secure-memory \ + --visualization \ + --gicv3 \ + --data="<path-to>/<bl1-binary>"@0x0 \ + --data="<path-to>/<FIP-binary>"@0x08000000 \ + --data="<path-to>/<kernel-binary>"@0x80080000 \ + --data="<path-to>/<ramdisk-binary>"@0x84000000 + +Notes: + +- BL1 is loaded at the start of the Trusted ROM. +- The Firmware Image Package is loaded at the start of NOR FLASH0. +- The firmware loads the FDT packaged in FIP to the DRAM. The FDT load address + is specified via the ``hw_config_addr`` property in `TB_FW_CONFIG for FVP`_. +- The default use-case for the Foundation FVP is to use the ``--gicv3`` option + and enable the GICv3 device in the model. Note that without this option, + the Foundation FVP defaults to legacy (Versatile Express) memory map which + is not supported by TF-A. +- In order for TF-A to run correctly on the Foundation FVP, the architecture + versions must match. The Foundation FVP defaults to the highest v8.x + version it supports but the default build for TF-A is for v8.0. To avoid + issues either start the Foundation FVP to use v8.0 architecture using the + ``--arm-v8.0`` option, or build TF-A with an appropriate value for + ``ARM_ARCH_MINOR``. + +Running on the AEMv8 Base FVP with reset to BL1 entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux +with 8 CPUs using the AArch64 build of TF-A. + +.. code:: shell + + <path-to>/FVP_Base_RevC-2xAEMv8A \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cluster0.NUM_CORES=4 \ + -C cluster1.NUM_CORES=4 \ + -C cache_state_modelled=1 \ + -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \ + -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000 + +.. note:: + The ``FVP_Base_RevC-2xAEMv8A`` has shifted affinities and requires + a specific DTS for all the CPUs to be loaded. + +Running on the AEMv8 Base FVP (AArch32) with reset to BL1 entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux +with 8 CPUs using the AArch32 build of TF-A. + +.. code:: shell + + <path-to>/FVP_Base_AEMv8A-AEMv8A \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cluster0.NUM_CORES=4 \ + -C cluster1.NUM_CORES=4 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.CONFIG64=0 \ + -C cluster0.cpu1.CONFIG64=0 \ + -C cluster0.cpu2.CONFIG64=0 \ + -C cluster0.cpu3.CONFIG64=0 \ + -C cluster1.cpu0.CONFIG64=0 \ + -C cluster1.cpu1.CONFIG64=0 \ + -C cluster1.cpu2.CONFIG64=0 \ + -C cluster1.cpu3.CONFIG64=0 \ + -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \ + -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000 + +Running on the Cortex-A57-A53 Base FVP with reset to BL1 entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to +boot Linux with 8 CPUs using the AArch64 build of TF-A. + +.. code:: shell + + <path-to>/FVP_Base_Cortex-A57x4-A53x4 \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cache_state_modelled=1 \ + -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \ + -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000 + +Running on the Cortex-A32 Base FVP (AArch32) with reset to BL1 entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to +boot Linux with 4 CPUs using the AArch32 build of TF-A. + +.. code:: shell + + <path-to>/FVP_Base_Cortex-A32x4 \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cache_state_modelled=1 \ + -C bp.secureflashloader.fname="<path-to>/<bl1-binary>" \ + -C bp.flashloader0.fname="<path-to>/<FIP-binary>" \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000 + + +Running on the AEMv8 Base FVP with reset to BL31 entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``FVP_Base_RevC-2xAEMv8A`` parameters should be used to boot Linux +with 8 CPUs using the AArch64 build of TF-A. + +.. code:: shell + + <path-to>/FVP_Base_RevC-2xAEMv8A \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cluster0.NUM_CORES=4 \ + -C cluster1.NUM_CORES=4 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.RVBAR=0x04010000 \ + -C cluster0.cpu1.RVBAR=0x04010000 \ + -C cluster0.cpu2.RVBAR=0x04010000 \ + -C cluster0.cpu3.RVBAR=0x04010000 \ + -C cluster1.cpu0.RVBAR=0x04010000 \ + -C cluster1.cpu1.RVBAR=0x04010000 \ + -C cluster1.cpu2.RVBAR=0x04010000 \ + -C cluster1.cpu3.RVBAR=0x04010000 \ + --data cluster0.cpu0="<path-to>/<bl31-binary>"@0x04010000 \ + --data cluster0.cpu0="<path-to>/<bl32-binary>"@0xff000000 \ + --data cluster0.cpu0="<path-to>/<bl33-binary>"@0x88000000 \ + --data cluster0.cpu0="<path-to>/<fdt>"@0x82000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000 + +Notes: + +- If Position Independent Executable (PIE) support is enabled for BL31 + in this config, it can be loaded at any valid address for execution. + +- Since a FIP is not loaded when using BL31 as reset entrypoint, the + ``--data="<path-to><bl31|bl32|bl33-binary>"@<base-address-of-binary>`` + parameter is needed to load the individual bootloader images in memory. + BL32 image is only needed if BL31 has been built to expect a Secure-EL1 + Payload. For the same reason, the FDT needs to be compiled from the DT source + and loaded via the ``--data cluster0.cpu0="<path-to>/<fdt>"@0x82000000`` + parameter. + +- The ``FVP_Base_RevC-2xAEMv8A`` has shifted affinities and requires a + specific DTS for all the CPUs to be loaded. + +- The ``-C cluster<X>.cpu<Y>.RVBAR=@<base-address-of-bl31>`` parameter, where + X and Y are the cluster and CPU numbers respectively, is used to set the + reset vector for each core. + +- Changing the default value of ``ARM_TSP_RAM_LOCATION`` will also require + changing the value of + ``--data="<path-to><bl32-binary>"@<base-address-of-bl32>`` to the new value of + ``BL32_BASE``. + + +Running on the AEMv8 Base FVP (AArch32) with reset to SP_MIN entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``FVP_Base_AEMv8A-AEMv8A`` parameters should be used to boot Linux +with 8 CPUs using the AArch32 build of TF-A. + +.. code:: shell + + <path-to>/FVP_Base_AEMv8A-AEMv8A \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cluster0.NUM_CORES=4 \ + -C cluster1.NUM_CORES=4 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.CONFIG64=0 \ + -C cluster0.cpu1.CONFIG64=0 \ + -C cluster0.cpu2.CONFIG64=0 \ + -C cluster0.cpu3.CONFIG64=0 \ + -C cluster1.cpu0.CONFIG64=0 \ + -C cluster1.cpu1.CONFIG64=0 \ + -C cluster1.cpu2.CONFIG64=0 \ + -C cluster1.cpu3.CONFIG64=0 \ + -C cluster0.cpu0.RVBAR=0x04002000 \ + -C cluster0.cpu1.RVBAR=0x04002000 \ + -C cluster0.cpu2.RVBAR=0x04002000 \ + -C cluster0.cpu3.RVBAR=0x04002000 \ + -C cluster1.cpu0.RVBAR=0x04002000 \ + -C cluster1.cpu1.RVBAR=0x04002000 \ + -C cluster1.cpu2.RVBAR=0x04002000 \ + -C cluster1.cpu3.RVBAR=0x04002000 \ + --data cluster0.cpu0="<path-to>/<bl32-binary>"@0x04002000 \ + --data cluster0.cpu0="<path-to>/<bl33-binary>"@0x88000000 \ + --data cluster0.cpu0="<path-to>/<fdt>"@0x82000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000 + +.. note:: + The load address of ``<bl32-binary>`` depends on the value ``BL32_BASE``. + It should match the address programmed into the RVBAR register as well. + +Running on the Cortex-A57-A53 Base FVP with reset to BL31 entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``FVP_Base_Cortex-A57x4-A53x4`` model parameters should be used to +boot Linux with 8 CPUs using the AArch64 build of TF-A. + +.. code:: shell + + <path-to>/FVP_Base_Cortex-A57x4-A53x4 \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.RVBARADDR=0x04010000 \ + -C cluster0.cpu1.RVBARADDR=0x04010000 \ + -C cluster0.cpu2.RVBARADDR=0x04010000 \ + -C cluster0.cpu3.RVBARADDR=0x04010000 \ + -C cluster1.cpu0.RVBARADDR=0x04010000 \ + -C cluster1.cpu1.RVBARADDR=0x04010000 \ + -C cluster1.cpu2.RVBARADDR=0x04010000 \ + -C cluster1.cpu3.RVBARADDR=0x04010000 \ + --data cluster0.cpu0="<path-to>/<bl31-binary>"@0x04010000 \ + --data cluster0.cpu0="<path-to>/<bl32-binary>"@0xff000000 \ + --data cluster0.cpu0="<path-to>/<bl33-binary>"@0x88000000 \ + --data cluster0.cpu0="<path-to>/<fdt>"@0x82000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000 + +Running on the Cortex-A32 Base FVP (AArch32) with reset to SP_MIN entrypoint +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following ``FVP_Base_Cortex-A32x4`` model parameters should be used to +boot Linux with 4 CPUs using the AArch32 build of TF-A. + +.. code:: shell + + <path-to>/FVP_Base_Cortex-A32x4 \ + -C pctl.startup=0.0.0.0 \ + -C bp.secure_memory=1 \ + -C bp.tzc_400.diagnostics=1 \ + -C cache_state_modelled=1 \ + -C cluster0.cpu0.RVBARADDR=0x04002000 \ + -C cluster0.cpu1.RVBARADDR=0x04002000 \ + -C cluster0.cpu2.RVBARADDR=0x04002000 \ + -C cluster0.cpu3.RVBARADDR=0x04002000 \ + --data cluster0.cpu0="<path-to>/<bl32-binary>"@0x04002000 \ + --data cluster0.cpu0="<path-to>/<bl33-binary>"@0x88000000 \ + --data cluster0.cpu0="<path-to>/<fdt>"@0x82000000 \ + --data cluster0.cpu0="<path-to>/<kernel-binary>"@0x80080000 \ + --data cluster0.cpu0="<path-to>/<ramdisk>"@0x84000000 + +-------------- + +*Copyright (c) 2019, Arm Limited. All rights reserved.* + +.. _TB_FW_CONFIG for FVP: ../plat/arm/board/fvp/fdts/fvp_tb_fw_config.dts +.. _Arm's website: `FVP models`_ +.. _FVP models: https://developer.arm.com/products/system-design/fixed-virtual-platforms +.. _Linaro Release 19.06: http://releases.linaro.org/members/arm/platforms/19.06 +.. _Arm FVP website: https://developer.arm.com/products/system-design/fixed-virtual-platforms diff --git a/docs/plat/arm/index.rst b/docs/plat/arm/index.rst new file mode 100644 index 000000000..e26f75e56 --- /dev/null +++ b/docs/plat/arm/index.rst @@ -0,0 +1,19 @@ +Arm Development Platforms +========================= + +.. toctree:: + :maxdepth: 1 + :caption: Contents + + juno/index + fvp/index + fvp-ve/index + arm-build-options + +This chapter holds documentation related to Arm's development platforms, +including both software models (FVPs) and hardware development boards +such as Juno. + +-------------- + +*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/plat/arm/juno/index.rst b/docs/plat/arm/juno/index.rst new file mode 100644 index 000000000..cf328fac9 --- /dev/null +++ b/docs/plat/arm/juno/index.rst @@ -0,0 +1,246 @@ +Arm Juno Development Platform +============================= + +Platform-specific build options +------------------------------- + +- ``JUNO_TZMP1`` : Boolean option to configure Juno to be used for TrustZone + Media Protection (TZ-MP1). Default value of this flag is 0. + +Running software on Juno +------------------------ + +This version of TF-A has been tested on variants r0, r1 and r2 of Juno. + +To execute the software stack on Juno, the version of the Juno board recovery +image indicated in the `Linaro Release Notes`_ must be installed. If you have an +earlier version installed or are unsure which version is installed, please +re-install the recovery image by following the +`Instructions for using Linaro's deliverables on Juno`_. + +Preparing TF-A images +--------------------- + +After building TF-A, the files ``bl1.bin`` and ``fip.bin`` need copying to the +``SOFTWARE/`` directory of the Juno SD card. + +Creating a Firmware Image Package (FIP) +--------------------------------------- + +This section provides Juno and FVP specific instructions to build Trusted +Firmware, obtain the additional required firmware, and pack it all together in +a single FIP binary. It assumes that a Linaro release has been installed. + +.. note:: + Pre-built binaries for AArch32 are available from Linaro Release 16.12 + onwards. Before that release, pre-built binaries are only available for + AArch64. + +.. warning:: + Follow the full instructions for one platform before switching to a + different one. Mixing instructions for different platforms may result in + corrupted binaries. + +.. warning:: + The uboot image downloaded by the Linaro workspace script does not always + match the uboot image packaged as BL33 in the corresponding fip file. It is + recommended to use the version that is packaged in the fip file using the + instructions below. + +.. note:: + For the FVP, the kernel FDT is packaged in FIP during build and loaded + by the firmware at runtime. + +#. Clean the working directory + + .. code:: shell + + make realclean + +#. Obtain SCP_BL2 (Juno) and BL33 (all platforms) + + Use the fiptool to extract the SCP_BL2 and BL33 images from the FIP + package included in the Linaro release: + + .. code:: shell + + # Build the fiptool + make [DEBUG=1] [V=1] fiptool + + # Unpack firmware images from Linaro FIP + ./tools/fiptool/fiptool unpack <path-to-linaro-release>/[SOFTWARE]/fip.bin + + The unpack operation will result in a set of binary images extracted to the + current working directory. The SCP_BL2 image corresponds to + ``scp-fw.bin`` and BL33 corresponds to ``nt-fw.bin``. + + .. note:: + The fiptool will complain if the images to be unpacked already + exist in the current directory. If that is the case, either delete those + files or use the ``--force`` option to overwrite. + + .. note:: + For AArch32, the instructions below assume that nt-fw.bin is a + normal world boot loader that supports AArch32. + +#. Build TF-A images and create a new FIP for FVP + + .. code:: shell + + # AArch64 + make PLAT=fvp BL33=nt-fw.bin all fip + + # AArch32 + make PLAT=fvp ARCH=aarch32 AARCH32_SP=sp_min BL33=nt-fw.bin all fip + +#. Build TF-A images and create a new FIP for Juno + + For AArch64: + + Building for AArch64 on Juno simply requires the addition of ``SCP_BL2`` + as a build parameter. + + .. code:: shell + + make PLAT=juno BL33=nt-fw.bin SCP_BL2=scp-fw.bin all fip + + For AArch32: + + Hardware restrictions on Juno prevent cold reset into AArch32 execution mode, + therefore BL1 and BL2 must be compiled for AArch64, and BL32 is compiled + separately for AArch32. + + - Before building BL32, the environment variable ``CROSS_COMPILE`` must point + to the AArch32 Linaro cross compiler. + + .. code:: shell + + export CROSS_COMPILE=<path-to-aarch32-gcc>/bin/arm-linux-gnueabihf- + + - Build BL32 in AArch32. + + .. code:: shell + + make ARCH=aarch32 PLAT=juno AARCH32_SP=sp_min \ + RESET_TO_SP_MIN=1 JUNO_AARCH32_EL3_RUNTIME=1 bl32 + + - Save ``bl32.bin`` to a temporary location and clean the build products. + + :: + + cp <path-to-build>/bl32.bin <path-to-temporary> + make realclean + + - Before building BL1 and BL2, the environment variable ``CROSS_COMPILE`` + must point to the AArch64 Linaro cross compiler. + + .. code:: shell + + export CROSS_COMPILE=<path-to-aarch64-gcc>/bin/aarch64-none-elf- + + - The following parameters should be used to build BL1 and BL2 in AArch64 + and point to the BL32 file. + + .. code:: shell + + make ARCH=aarch64 PLAT=juno JUNO_AARCH32_EL3_RUNTIME=1 \ + BL33=nt-fw.bin SCP_BL2=scp-fw.bin \ + BL32=<path-to-temporary>/bl32.bin all fip + +The resulting BL1 and FIP images may be found in: + +:: + + # Juno + ./build/juno/release/bl1.bin + ./build/juno/release/fip.bin + + # FVP + ./build/fvp/release/bl1.bin + ./build/fvp/release/fip.bin + + +Booting Firmware Update images +------------------------------ + +The new images must be programmed in flash memory by adding +an entry in the ``SITE1/HBI0262x/images.txt`` configuration file +on the Juno SD card (where ``x`` depends on the revision of the Juno board). +Refer to the `Juno Getting Started Guide`_, section 2.3 "Flash memory +programming" for more information. User should ensure these do not +overlap with any other entries in the file. + +:: + + NOR10UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE + NOR10ADDRESS: 0x00400000 ;Image Flash Address [ns_bl2u_base_address] + NOR10FILE: \SOFTWARE\fwu_fip.bin ;Image File Name + NOR10LOAD: 00000000 ;Image Load Address + NOR10ENTRY: 00000000 ;Image Entry Point + + NOR11UPDATE: AUTO ;Image Update:NONE/AUTO/FORCE + NOR11ADDRESS: 0x03EB8000 ;Image Flash Address [ns_bl1u_base_address] + NOR11FILE: \SOFTWARE\ns_bl1u.bin ;Image File Name + NOR11LOAD: 00000000 ;Image Load Address + +The address ns_bl1u_base_address is the value of NS_BL1U_BASE - 0x8000000. +In the same way, the address ns_bl2u_base_address is the value of +NS_BL2U_BASE - 0x8000000. + +.. _plat_juno_booting_el3_payload: + +Booting an EL3 payload +---------------------- + +If the EL3 payload is able to execute in place, it may be programmed in flash +memory by adding an entry in the ``SITE1/HBI0262x/images.txt`` configuration file +on the Juno SD card (where ``x`` depends on the revision of the Juno board). +Refer to the `Juno Getting Started Guide`_, section 2.3 "Flash memory +programming" for more information. + +Alternatively, the same DS-5 command mentioned in the FVP section above can +be used to load the EL3 payload's ELF file over JTAG on Juno. + +For more information on EL3 payloads in general, see +:ref:`alt_boot_flows_el3_payload`. + +Booting a preloaded kernel image +-------------------------------- + +The Trusted Firmware must be compiled in a similar way as for FVP explained +above. The process to load binaries to memory is the one explained in +`plat_juno_booting_el3_payload`_. + +Testing System Suspend +---------------------- + +The SYSTEM SUSPEND is a PSCI API which can be used to implement system suspend +to RAM. For more details refer to section 5.16 of `PSCI`_. To test system suspend +on Juno, at the linux shell prompt, issue the following command: + +.. code:: shell + + echo +10 > /sys/class/rtc/rtc0/wakealarm + echo -n mem > /sys/power/state + +The Juno board should suspend to RAM and then wakeup after 10 seconds due to +wakeup interrupt from RTC. + +Additional Resources +-------------------- + +Please visit the `Arm Platforms Portal`_ to get support and obtain any other Juno +software information. Please also refer to the `Juno Getting Started Guide`_ to +get more detailed information about the Juno Arm development platform and how to +configure it. + +-------------- + +*Copyright (c) 2019, Arm Limited. All rights reserved.* + +.. _Linaro Release Notes: https://community.arm.com/dev-platforms/w/docs/226/old-release-notes +.. _Instructions for using Linaro's deliverables on Juno: https://community.arm.com/dev-platforms/w/docs/303/juno +.. _Arm Platforms Portal: https://community.arm.com/dev-platforms/ +.. _Juno Getting Started Guide: http://infocenter.arm.com/help/topic/com.arm.doc.dui0928e/DUI0928E_juno_arm_development_platform_gsg.pdf +.. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf +.. _Juno Arm Development Platform: http://www.arm.com/products/tools/development-boards/versatile-express/juno-arm-development-platform.php diff --git a/docs/plat/hikey.rst b/docs/plat/hikey.rst index 74ff2f46c..372d38867 100644 --- a/docs/plat/hikey.rst +++ b/docs/plat/hikey.rst @@ -1,15 +1,15 @@ -Description -=========== +HiKey +===== HiKey is one of 96boards. Hisilicon Kirin6220 processor is installed on HiKey. More information are listed in `link`_. How to build -============ +------------ Code Locations --------------- +~~~~~~~~~~~~~~ - Trusted Firmware-A: `link <https://github.com/ARM-software/arm-trusted-firmware>`__ @@ -33,7 +33,7 @@ Code Locations `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}. diff --git a/docs/plat/hikey960.rst b/docs/plat/hikey960.rst index 7ddb0b104..3d42a77c5 100644 --- a/docs/plat/hikey960.rst +++ b/docs/plat/hikey960.rst @@ -1,15 +1,15 @@ -Description -=========== +HiKey960 +======== HiKey960 is one of 96boards. Hisilicon Hi3660 processor is installed on HiKey960. More information are listed in `link`_. How to build -============ +------------ Code Locations --------------- +~~~~~~~~~~~~~~ - Trusted Firmware-A: `link <https://github.com/ARM-software/arm-trusted-firmware>`__ @@ -30,7 +30,7 @@ Code Locations `link <https://git.linaro.org/uefi/uefi-tools.git>`__ Build Procedure ---------------- +~~~~~~~~~~~~~~~ - Fetch all the above 5 repositories into local host. Make all the repositories in the same ${BUILD\_PATH}. diff --git a/docs/plat/index.rst b/docs/plat/index.rst index 595141372..63d29a9be 100644 --- a/docs/plat/index.rst +++ b/docs/plat/index.rst @@ -5,25 +5,52 @@ Platform Ports :maxdepth: 1 :caption: Contents :numbered: + :hidden: allwinner - fvp_ve - imx8 - imx8m - intel-stratix10 - ls1043a + arm/index meson-gxbb meson-gxl + meson-g12a + hikey + hikey960 + intel-agilex + intel-stratix10 + marvell/index mt8183 nvidia-tegra + warp7 + imx8 + imx8m + ls1043a + poplar qemu + qemu-sbsa + rpi3 + rpi4 rcar-gen3 rockchip - rpi3 socionext-uniphier - stm32mp1 synquacer + stm32mp1 ti-k3 - warp7 xilinx-versal xilinx-zynqmp + +This section provides a list of supported upstream *platform ports* and the +documentation associated with them. + +.. note:: + In addition to the platforms ports listed within the table of contents, there + are several additional platforms that are supported upstream but which do not + currently have associated documentation: + + - Arm Neoverse N1 System Development Platform (N1SDP) + - Arm Neoverse Reference Design N1 Edge (RD-N1-Edge) FVP + - Arm Neoverse Reference Design E1 Edge (RD-E1-Edge) FVP + - Arm SGI-575 and SGM-775 + - MediaTek MT6795 and MT8173 SoCs + +-------------- + +*Copyright (c) 2019, Arm Limited. All rights reserved.* diff --git a/docs/plat/intel-agilex.rst b/docs/plat/intel-agilex.rst index 015a195a8..ff27b6b5f 100644 --- a/docs/plat/intel-agilex.rst +++ b/docs/plat/intel-agilex.rst @@ -67,6 +67,7 @@ Boot trace ---------- :: + INFO: DDR: DRAM calibration success. INFO: ECC is disabled. NOTICE: BL2: v2.1(debug) diff --git a/docs/plat/intel-stratix10.rst b/docs/plat/intel-stratix10.rst index 77a45a478..7f8d18e03 100644 --- a/docs/plat/intel-stratix10.rst +++ b/docs/plat/intel-stratix10.rst @@ -67,6 +67,7 @@ Boot trace ---------- :: + INFO: DDR: DRAM calibration success. INFO: ECC is disabled. INFO: Init HPS NOC's DDR Scheduler. diff --git a/docs/plat/marvell/build.rst b/docs/plat/marvell/build.rst new file mode 100644 index 000000000..c10bcff79 --- /dev/null +++ b/docs/plat/marvell/build.rst @@ -0,0 +1,253 @@ +TF-A Build Instructions for Marvell Platforms +============================================= + +This section describes how to compile the Trusted Firmware-A (TF-A) project for Marvell's platforms. + +Build Instructions +------------------ +(1) Set the cross compiler + + .. code:: shell + + > export CROSS_COMPILE=/path/to/toolchain/aarch64-linux-gnu- + +(2) Set path for FIP images: + +Set U-Boot image path (relatively to TF-A root or absolute path) + + .. code:: shell + + > export BL33=path/to/u-boot.bin + +For example: if U-Boot project (and its images) is located at ``~/project/u-boot``, +BL33 should be ``~/project/u-boot/u-boot.bin`` + + .. note:: + + *u-boot.bin* should be used and not *u-boot-spl.bin* + +Set MSS/SCP image path (mandatory only for Armada80x0) + + .. code:: shell + + > export SCP_BL2=path/to/mrvl_scp_bl2*.img + +(3) Armada-37x0 build requires WTP tools installation. + +See below in the section "Tools and external components installation". +Install ARM 32-bit cross compiler, which is required for building WTMI image for CM3 + + .. code:: shell + + > sudo apt-get install gcc-arm-linux-gnueabi + +(4) Clean previous build residuals (if any) + + .. code:: shell + + > make distclean + +(5) Build TF-A + +There are several build options: + +- DEBUG + + Default is without debug information (=0). in order to enable it use ``DEBUG=1``. + Must be disabled when building UART recovery images due to current console driver + implementation that is not compatible with Xmodem protocol used for boot image download. + +- LOG_LEVEL + + Defines the level of logging which will be purged to the default output port. + + LOG_LEVEL_NONE 0 + LOG_LEVEL_ERROR 10 + LOG_LEVEL_NOTICE 20 + LOG_LEVEL_WARNING 30 + LOG_LEVEL_INFO 40 + LOG_LEVEL_VERBOSE 50 + +- USE_COHERENT_MEM + + This flag determines whether to include the coherent memory region in the + BL memory map or not. + +- LLC_ENABLE + + Flag defining the LLC (L3) cache state. The cache is enabled by default (``LLC_ENABLE=1``). + +- MARVELL_SECURE_BOOT + + Build trusted(=1)/non trusted(=0) image, default is non trusted. + +- BLE_PATH + + Points to BLE (Binary ROM extension) sources folder. Only required for A8K builds. + The parameter is optional, its default value is ``plat/marvell/a8k/common/ble``. + +- MV_DDR_PATH + + For A7/8K, use this parameter to point to mv_ddr driver sources to allow BLE build. For A37x0, + it is used for ddr_tool build. + + Usage example: MV_DDR_PATH=path/to/mv_ddr + + The parameter is optional for A7/8K, when this parameter is not set, the mv_ddr + sources are expected to be located at: drivers/marvell/mv_ddr. However, the parameter + is necessary for A37x0. + + For the mv_ddr source location, check the section "Tools and external components installation" + +- DDR_TOPOLOGY + + For Armada37x0 only, the DDR topology map index/name, default is 0. + + Supported Options: + - DDR3 1CS (0): DB-88F3720-DDR3-Modular (512MB); EspressoBIN (512MB) + - DDR4 1CS (1): DB-88F3720-DDR4-Modular (512MB) + - DDR3 2CS (2): EspressoBIN V3-V5 (1GB) + - DDR4 2CS (3): DB-88F3720-DDR4-Modular (4GB) + - DDR3 1CS (4): DB-88F3720-DDR3-Modular (1GB) + - DDR4 1CS (5): EspressoBin V7 (1GB) + - DDR4 2CS (6): EspressoBin V7 (2GB) + - CUSTOMER (CUST): Customer board, DDR3 1CS 512MB + +- CLOCKSPRESET + + For Armada37x0 only, the clock tree configuration preset including CPU and DDR frequency, + default is CPU_800_DDR_800. + + - CPU_600_DDR_600 - CPU at 600 MHz, DDR at 600 MHz + - CPU_800_DDR_800 - CPU at 800 MHz, DDR at 800 MHz + - CPU_1000_DDR_800 - CPU at 1000 MHz, DDR at 800 MHz + - CPU_1200_DDR_750 - CPU at 1200 MHz, DDR at 750 MHz + +- BOOTDEV + + For Armada37x0 only, the flash boot device, default is ``SPINOR``. + + Currently, Armada37x0 only supports ``SPINOR``, ``SPINAND``, ``EMMCNORM`` and ``SATA``: + + - SPINOR - SPI NOR flash boot + - SPINAND - SPI NAND flash boot + - EMMCNORM - eMMC Download Mode + + Download boot loader or program code from eMMC flash into CM3 or CA53 + Requires full initialization and command sequence + + - SATA - SATA device boot + +- PARTNUM + + For Armada37x0 only, the boot partition number, default is 0. + + To boot from eMMC, the value should be aligned with the parameter in + U-Boot with name of ``CONFIG_SYS_MMC_ENV_PART``, whose value by default is + 1. For details about CONFIG_SYS_MMC_ENV_PART, please refer to the U-Boot + build instructions. + +- WTMI_IMG + + For Armada37x0 only, the path of the WTMI image can point to an image which + does nothing, an image which supports EFUSE or a customized CM3 firmware + binary. The default image is wtmi.bin that built from sources in WTP + folder, which is the next option. If the default image is OK, then this + option should be skipped. + +- WTP + + For Armada37x0 only, use this parameter to point to wtptools source code + directory, which can be found as a3700_utils.zip in the release. Usage + example: ``WTP=/path/to/a3700_utils`` + + For example, in order to build the image in debug mode with log level up to 'notice' level run + + .. code:: shell + + > make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 PLAT=<MARVELL_PLATFORM> all fip + + And if we want to build a Armada37x0 image in debug mode with log level up to 'notice' level, + the image has the preset CPU at 1000 MHz, preset DDR3 at 800 MHz, the DDR topology of DDR4 2CS, + the image boot from SPI NOR flash partition 0, and the image is non trusted in WTP, the command + line is as following + + .. code:: shell + + > make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 CLOCKSPRESET=CPU_1000_DDR_800 \ + MARVELL_SECURE_BOOT=0 DDR_TOPOLOGY=3 BOOTDEV=SPINOR PARTNUM=0 PLAT=a3700 all fip + + Supported MARVELL_PLATFORM are: + - a3700 (for both A3720 DB and EspressoBin) + - a70x0 + - a70x0_amc (for AMC board) + - a80x0 + - a80x0_mcbin (for MacciatoBin) + +Special Build Flags +-------------------- + +- PLAT_RECOVERY_IMAGE_ENABLE + When set this option to enable secondary recovery function when build atf. + In order to build UART recovery image this operation should be disabled for + a70x0 and a80x0 because of hardware limitation (boot from secondary image + can interrupt UART recovery process). This MACRO definition is set in + ``plat/marvell/a8k/common/include/platform_def.h`` file. + +For more information about build options, please refer to the +:ref:`Build Options` document. + + +Build output +------------ +Marvell's TF-A compilation generates 7 files: + + - ble.bin - BLe image + - bl1.bin - BL1 image + - bl2.bin - BL2 image + - bl31.bin - BL31 image + - fip.bin - FIP image (contains BL2, BL31 & BL33 (U-Boot) images) + - boot-image.bin - TF-A image (contains BL1 and FIP images) + - flash-image.bin - Image which contains boot-image.bin and SPL image. + Should be placed on the boot flash/device. + + +Tools and external components installation +------------------------------------------ + +Armada37x0 Builds require installation of 3 components +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +(1) ARM cross compiler capable of building images for the service CPU (CM3). + This component is usually included in the Linux host packages. + On Debian/Ubuntu hosts the default GNU ARM tool chain can be installed + using the following command + + .. code:: shell + + > sudo apt-get install gcc-arm-linux-gnueabi + + Only if required, the default tool chain prefix ``arm-linux-gnueabi-`` can be + overwritten using the environment variable ``CROSS_CM3``. + Example for BASH shell + + .. code:: shell + + > export CROSS_CM3=/opt/arm-cross/bin/arm-linux-gnueabi + +(2) DDR initialization library sources (mv_ddr) available at the following repository + (use the "mv_ddr-armada-atf-mainline" branch): + + https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git + +(3) Armada3700 tools available at the following repository (use the latest release branch): + + https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git + +Armada70x0 and Armada80x0 Builds require installation of an additional component +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +(1) DDR initialization library sources (mv_ddr) available at the following repository + (use the "mv_ddr-armada-atf-mainline" branch): + + https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git diff --git a/docs/plat/marvell/build.txt b/docs/plat/marvell/build.txt deleted file mode 100644 index 7b75196fa..000000000 --- a/docs/plat/marvell/build.txt +++ /dev/null @@ -1,194 +0,0 @@ -TF-A Build Instructions -====================== - -This section describes how to compile the ARM Trusted Firmware (TF-A) project for Marvell's platforms. - -Build Instructions ------------------- -(1) Set the cross compiler:: - - > export CROSS_COMPILE=/path/to/toolchain/aarch64-linux-gnu- - -(2) Set path for FIP images: - - Set U-Boot image path (relatively to TF-A root or absolute path):: - - > export BL33=path/to/u-boot.bin - - For example: if U-Boot project (and its images) is located at ~/project/u-boot, - BL33 should be ~/project/u-boot/u-boot.bin - - .. note:: - - u-boot.bin should be used and not u-boot-spl.bin - - Set MSS/SCP image path (mandatory only for Armada80x0):: - - > export SCP_BL2=path/to/mrvl_scp_bl2*.img - -(3) Armada-37x0 build requires WTP tools installation. - - See below in the section "Tools and external components installation". - Install ARM 32-bit cross compiler, which is required for building WTMI image for CM3:: - - > sudo apt-get install gcc-arm-linux-gnueabi - -(4) Clean previous build residuals (if any):: - - > make distclean - -(5) Build TF-A: - - There are several build options: - - - DEBUG: default is without debug information (=0). in order to enable it use DEBUG=1 - Must be disabled when building UART recovery images due to current console driver - implementation that is not compatible with Xmodem protocol used for boot image download. - - - LOG_LEVEL: defines the level of logging which will be purged to the default output port. - - LOG_LEVEL_NONE 0 - LOG_LEVEL_ERROR 10 - LOG_LEVEL_NOTICE 20 - LOG_LEVEL_WARNING 30 - LOG_LEVEL_INFO 40 - LOG_LEVEL_VERBOSE 50 - - - USE_COHERENT_MEM: This flag determines whether to include the coherent memory region in the - BL memory map or not. - - - LLC_ENABLE: Flag defining the LLC (L3) cache state. The cache is enabled by default (LLC_ENABLE=1). - - - MARVELL_SECURE_BOOT: build trusted(=1)/non trusted(=0) image, default is non trusted. - - - BLE_PATH: - Points to BLE (Binary ROM extension) sources folder. Only required for A8K builds. - The parameter is optional, its default value is "plat/marvell/a8k/common/ble". - - - MV_DDR_PATH: - For A7/8K, use this parameter to point to mv_ddr driver sources to allow BLE build. For A37x0, - it is used for ddr_tool build. - Usage example: MV_DDR_PATH=path/to/mv_ddr - The parameter is optional for A7/8K, when this parameter is not set, the mv_ddr - sources are expected to be located at: drivers/marvell/mv_ddr. However, the parameter - is necessary for A37x0. - For the mv_ddr source location, check the section "Tools and external components installation" - - - DDR_TOPOLOGY: For Armada37x0 only, the DDR topology map index/name, default is 0. - Supported Options: - - DDR3 1CS (0): DB-88F3720-DDR3-Modular (512MB); EspressoBIN (512MB) - - DDR4 1CS (1): DB-88F3720-DDR4-Modular (512MB) - - DDR3 2CS (2): EspressoBIN V3-V5 (1GB) - - DDR4 2CS (3): DB-88F3720-DDR4-Modular (4GB) - - DDR3 1CS (4): DB-88F3720-DDR3-Modular (1GB) - - DDR4 1CS (5): EspressoBin V7 (1GB) - - DDR4 2CS (6): EspressoBin V7 (2GB) - - CUSTOMER (CUST): Customer board, DDR3 1CS 512MB - - - CLOCKSPRESET: For Armada37x0 only, the clock tree configuration preset including CPU and DDR frequency, - default is CPU_800_DDR_800. - - CPU_600_DDR_600 - CPU at 600 MHz, DDR at 600 MHz - - CPU_800_DDR_800 - CPU at 800 MHz, DDR at 800 MHz - - CPU_1000_DDR_800 - CPU at 1000 MHz, DDR at 800 MHz - - CPU_1200_DDR_750 - CPU at 1200 MHz, DDR at 750 MHz - - - BOOTDEV: For Armada37x0 only, the flash boot device, default is SPINOR, - Currently, Armada37x0 only supports SPINOR, SPINAND, EMMCNORM and SATA: - - - SPINOR - SPI NOR flash boot - - SPINAND - SPI NAND flash boot - - EMMCNORM - eMMC Download Mode - Download boot loader or program code from eMMC flash into CM3 or CA53 - Requires full initialization and command sequence - - SATA - SATA device boot - - - PARTNUM: For Armada37x0 only, the boot partition number, default is 0. To boot from eMMC, the value - should be aligned with the parameter in U-Boot with name of CONFIG_SYS_MMC_ENV_PART, whose - value by default is 1. - For details about CONFIG_SYS_MMC_ENV_PART, please refer to the U-Boot build instructions. - - - WTMI_IMG: For Armada37x0 only, the path of the WTMI image can point to an image which does - nothing, an image which supports EFUSE or a customized CM3 firmware binary. The default image - is wtmi.bin that built from sources in WTP folder, which is the next option. If the default - image is OK, then this option should be skipped. - - - WTP: For Armada37x0 only, use this parameter to point to wtptools source code directory, which - can be found as a3700_utils.zip in the release. - Usage example: WTP=/path/to/a3700_utils - - For example, in order to build the image in debug mode with log level up to 'notice' level run:: - - > make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 PLAT=<MARVELL_PLATFORM> all fip - - And if we want to build a Armada37x0 image in debug mode with log level up to 'notice' level, - the image has the preset CPU at 1000 MHz, preset DDR3 at 800 MHz, the DDR topology of DDR4 2CS, - the image boot from SPI NOR flash partition 0, and the image is non trusted in WTP, the command - line is as following:: - - > make DEBUG=1 USE_COHERENT_MEM=0 LOG_LEVEL=20 CLOCKSPRESET=CPU_1000_DDR_800 \ - MARVELL_SECURE_BOOT=0 DDR_TOPOLOGY=3 BOOTDEV=SPINOR PARTNUM=0 PLAT=a3700 all fip - - Supported MARVELL_PLATFORM are: - - a3700 (for both A3720 DB and EspressoBin) - - a70x0 - - a70x0_amc (for AMC board) - - a80x0 - - a80x0_mcbin (for MacciatoBin) - -Special Build Flags --------------------- - - PLAT_RECOVERY_IMAGE_ENABLE: When set this option to enable secondary recovery function when build - atf. In order to build UART recovery image this operation should be disabled for a70x0 and a80x0 - because of hardware limitation (boot from secondary image can interrupt UART recovery process). - This MACRO definition is set in plat/marvell/a8k/common/include/platform_def.h file - -(for more information about build options, please refer to section 'Summary of build options' in TF-A user-guide: - https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.md) - - -Build output -------------- -Marvell's TF-A compilation generates 7 files: - - ble.bin - BLe image - - bl1.bin - BL1 image - - bl2.bin - BL2 image - - bl31.bin - BL31 image - - fip.bin - FIP image (contains BL2, BL31 & BL33 (U-Boot) images) - - boot-image.bin - TF-A image (contains BL1 and FIP images) - - flash-image.bin - Image which contains boot-image.bin and SPL image; - should be placed on the boot flash/device. - - -Tools and external components installation -========================================== - -Armada37x0 Builds require installation of 3 components -------------------------------------------------------- - -(1) ARM cross compiler capable of building images for the service CPU (CM3). - This component is usually included in the Linux host packages. - On Debian/Ubuntu hosts the default GNU ARM tool chain can be installed - using the following command:: - - > sudo apt-get install gcc-arm-linux-gnueabi - - Only if required, the default tool chain prefix "arm-linux-gnueabi-" can be - overwritten using the environment variable CROSS_CM3. - Example for BASH shell:: - - > export CROSS_CM3=/opt/arm-cross/bin/arm-linux-gnueabi - -(2) DDR initialization library sources (mv_ddr) available at the following repository - (use the "mv_ddr-armada-atf-mainline" branch):: - https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git - -(3) Armada3700 tools available at the following repository (use the latest release branch):: - https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell.git - -Armada70x0 and Armada80x0 Builds require installation of an additional component --------------------------------------------------------------------------------- - -(1) DDR initialization library sources (mv_ddr) available at the following repository - (use the "mv_ddr-armada-atf-mainline" branch):: - https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git - diff --git a/docs/plat/marvell/index.rst b/docs/plat/marvell/index.rst new file mode 100644 index 000000000..89ebdc0a4 --- /dev/null +++ b/docs/plat/marvell/index.rst @@ -0,0 +1,14 @@ +Marvell +======= + +.. toctree:: + :maxdepth: 1 + :caption: Contents + + build + porting + misc/mvebu-a8k-addr-map + misc/mvebu-amb + misc/mvebu-ccu + misc/mvebu-io-win + misc/mvebu-iob diff --git a/docs/plat/marvell/misc/mvebu-a8k-addr-map.rst b/docs/plat/marvell/misc/mvebu-a8k-addr-map.rst new file mode 100644 index 000000000..e88a4582b --- /dev/null +++ b/docs/plat/marvell/misc/mvebu-a8k-addr-map.rst @@ -0,0 +1,49 @@ +Address decoding flow and address translation units of Marvell Armada 8K SoC family +=================================================================================== + +:: + + +--------------------------------------------------------------------------------------------------+ + | +-------------+ +--------------+ | + | | Memory +----- DRAM CS | | + |+------------+ +-----------+ +-----------+ | Controller | +--------------+ | + || AP DMA | | | | | +-------------+ | + || SD/eMMC | | CA72 CPUs | | AP MSS | +-------------+ | + || MCI-0/1 | | | | | | Memory | | + |+------+-----+ +--+--------+ +--------+--+ +------------+ | Controller | +-------------+ | + | | | | | +----- Translaton | |AP | | + | | | | | | +-------------+ |Configuration| | + | | | +-----+ +-------------------------Space | | + | | | +-------------+ | CCU | +-------------+ | + | | | | MMU +---------+ Windows | +-----------+ +-------------+ | + | | +-| translation | | Lookup +---- +--------- AP SPI | | + | | +-------------+ | | | | +-------------+ | + | | +-------------+ | | | IO | +-------------+ | + | +------------| SMMU +---------+ | | Windows +--------- AP MCI0/1 | | + | | translation | +------------+ | Lookup | +-------------+ | + | +---------+---+ | | +-------------+ | + | - | | +--------- AP STM | | + | +----------------- | | +-------------+ | + | AP | | +-+---------+ | + +---------------------------------------------------------------|----------------------------------+ + +-------------|-------------------------------------------------|----------------------------------+ + | CP | +-------------+ +------+-----+ +-------------------+ | + | | | | | +------- SB CFG Space | | + | | | DIOB | | | +-------------------+ | + | | | Windows ----------------- IOB | +-------------------+ | + | | | Control | | Windows +------| SB PCIe-0 - PCIe2 | | + | | | | | Lookup | +-------------------+ | + | | +------+------+ | | +-------------------+ | + | | | | +------+ SB NAND | | + | | | +------+-----+ +-------------------+ | + | | | | | + | | | | | + | +------------------+ +------------+ +------+-----+ +-------------------+ | + | | Network Engine | | | | +------- SB SPI-0/SPI-1 | | + | | Security Engine | | PCIe, MSS | | RUNIT | +-------------------+ | + | | SATA, USB | | DMA | | Windows | +-------------------+ | + | | SD/eMMC | | | | Lookup +------- SB Device Bus | | + | | TDM, I2C | | | | | +-------------------+ | + | +------------------+ +------------+ +------------+ | + | | + +--------------------------------------------------------------------------------------------------+ diff --git a/docs/plat/marvell/misc/mvebu-a8k-addr-map.txt b/docs/plat/marvell/misc/mvebu-a8k-addr-map.txt deleted file mode 100644 index 586e8b732..000000000 --- a/docs/plat/marvell/misc/mvebu-a8k-addr-map.txt +++ /dev/null @@ -1,47 +0,0 @@ -Address decoding flow and address translation units of Marvell Armada 8K SoC family - -+--------------------------------------------------------------------------------------------------+ -| +-------------+ +--------------+ | -| | Memory +----- DRAM CS | | -|+------------+ +-----------+ +-----------+ | Controller | +--------------+ | -|| AP DMA | | | | | +-------------+ | -|| SD/eMMC | | CA72 CPUs | | AP MSS | +-------------+ | -|| MCI-0/1 | | | | | | Memory | | -|+------+-----+ +--+--------+ +--------+--+ +------------+ | Controller | +-------------+ | -| | | | | +----- Translaton | |AP | | -| | | | | | +-------------+ |Configuration| | -| | | +-----+ +-------------------------Space | | -| | | +-------------+ | CCU | +-------------+ | -| | | | MMU +---------+ Windows | +-----------+ +-------------+ | -| | +-| translation | | Lookup +---- +--------- AP SPI | | -| | +-------------+ | | | | +-------------+ | -| | +-------------+ | | | IO | +-------------+ | -| +------------| SMMU +---------+ | | Windows +--------- AP MCI0/1 | | -| | translation | +------------+ | Lookup | +-------------+ | -| +---------+---+ | | +-------------+ | -| - | | +--------- AP STM | | -| +----------------- | | +-------------+ | -| AP | | +-+---------+ | -+---------------------------------------------------------------|----------------------------------+ -+-------------|-------------------------------------------------|----------------------------------+ -| CP | +-------------+ +------+-----+ +-------------------+ | -| | | | | +------- SB CFG Space | | -| | | DIOB | | | +-------------------+ | -| | | Windows ----------------- IOB | +-------------------+ | -| | | Control | | Windows +------| SB PCIe-0 - PCIe2 | | -| | | | | Lookup | +-------------------+ | -| | +------+------+ | | +-------------------+ | -| | | | +------+ SB NAND | | -| | | +------+-----+ +-------------------+ | -| | | | | -| | | | | -| +------------------+ +------------+ +------+-----+ +-------------------+ | -| | Network Engine | | | | +------- SB SPI-0/SPI-1 | | -| | Security Engine | | PCIe, MSS | | RUNIT | +-------------------+ | -| | SATA, USB | | DMA | | Windows | +-------------------+ | -| | SD/eMMC | | | | Lookup +------- SB Device Bus | | -| | TDM, I2C | | | | | +-------------------+ | -| +------------------+ +------------+ +------------+ | -| | -+--------------------------------------------------------------------------------------------------+ - diff --git a/docs/plat/marvell/misc/mvebu-amb.rst b/docs/plat/marvell/misc/mvebu-amb.rst new file mode 100644 index 000000000..d734003d6 --- /dev/null +++ b/docs/plat/marvell/misc/mvebu-amb.rst @@ -0,0 +1,58 @@ +AMB - AXI MBUS address decoding +=============================== + +AXI to M-bridge decoding unit driver for Marvell Armada 8K and 8K+ SoCs. + +The Runit offers a second level of address windows lookup. It is used to map +transaction towards the CD BootROM, SPI0, SPI1 and Device bus (NOR). + +The Runit contains eight configurable windows. Each window defines a contiguous, +address space and the properties associated with that address space. + +:: + + Unit Bank ATTR + Device-Bus DEV_BOOT_CS 0x2F + DEV_CS0 0x3E + DEV_CS1 0x3D + DEV_CS2 0x3B + DEV_CS3 0x37 + SPI-0 SPI_A_CS0 0x1E + SPI_A_CS1 0x5E + SPI_A_CS2 0x9E + SPI_A_CS3 0xDE + SPI_A_CS4 0x1F + SPI_A_CS5 0x5F + SPI_A_CS6 0x9F + SPI_A_CS7 0xDF + SPI SPI_B_CS0 0x1A + SPI_B_CS1 0x5A + SPI_B_CS2 0x9A + SPI_B_CS3 0xDA + BOOT_ROM BOOT_ROM 0x1D + UART UART 0x01 + +Mandatory functions +------------------- + +- marvell_get_amb_memory_map + Returns the AMB windows configuration and the number of windows + +Mandatory structures +-------------------- + +- amb_memory_map + Array that include the configuration of the windows. Every window/entry is a + struct which has 2 parameters: + + - Base address of the window + - Attribute of the window + +Examples +-------- + +.. code:: c + + struct addr_map_win amb_memory_map[] = { + {0xf900, AMB_DEV_CS0_ID}, + }; diff --git a/docs/plat/marvell/misc/mvebu-amb.txt b/docs/plat/marvell/misc/mvebu-amb.txt deleted file mode 100644 index 2a7a41ec9..000000000 --- a/docs/plat/marvell/misc/mvebu-amb.txt +++ /dev/null @@ -1,45 +0,0 @@ -AMB - AXI MBUS address decoding -------------------------------- - -AXI to M-bridge decoding unit driver for Marvell Armada 8K and 8K+ SoCs. - -- The Runit offers a second level of address windows lookup. It is used to map transaction towards -the CD BootROM, SPI0, SPI1 and Device bus (NOR). -- The Runit contains eight configurable windows. Each window defines a contiguous, -address space and the properties associated with that address space. - -Unit Bank ATTR -Device-Bus DEV_BOOT_CS 0x2F - DEV_CS0 0x3E - DEV_CS1 0x3D - DEV_CS2 0x3B - DEV_CS3 0x37 -SPI-0 SPI_A_CS0 0x1E - SPI_A_CS1 0x5E - SPI_A_CS2 0x9E - SPI_A_CS3 0xDE - SPI_A_CS4 0x1F - SPI_A_CS5 0x5F - SPI_A_CS6 0x9F - SPI_A_CS7 0xDF -SPI1 SPI_B_CS0 0x1A - SPI_B_CS1 0x5A - SPI_B_CS2 0x9A - SPI_B_CS3 0xDA -BOOT_ROM BOOT_ROM 0x1D -UART UART 0x01 - -Mandatory functions: - - marvell_get_amb_memory_map - returns the AMB windows configuration and the number of windows - -Mandatory structures: - amb_memory_map - Array that include the configuration of the windows - every window/entry is a struct which has 2 parameters: - - base address of the window - - Attribute of the window - -Examples: - struct addr_map_win amb_memory_map[] = { - {0xf900, AMB_DEV_CS0_ID}, - }; diff --git a/docs/plat/marvell/misc/mvebu-ccu.rst b/docs/plat/marvell/misc/mvebu-ccu.rst new file mode 100644 index 000000000..5bac11faf --- /dev/null +++ b/docs/plat/marvell/misc/mvebu-ccu.rst @@ -0,0 +1,33 @@ +Marvell CCU address decoding bindings +===================================== + +CCU configration driver (1st stage address translation) for Marvell Armada 8K and 8K+ SoCs. + +The CCU node includes a description of the address decoding configuration. + +Mandatory functions +------------------- + +- marvell_get_ccu_memory_map + Return the CCU windows configuration and the number of windows of the + specific AP. + +Mandatory structures +-------------------- + +- ccu_memory_map + Array that includes the configuration of the windows. Every window/entry is + a struct which has 3 parameters: + + - Base address of the window + - Size of the window + - Target-ID of the window + +Example +------- + +.. code:: c + + struct addr_map_win ccu_memory_map[] = { + {0x00000000f2000000, 0x00000000e000000, IO_0_TID}, /* IO window */ + }; diff --git a/docs/plat/marvell/misc/mvebu-ccu.txt b/docs/plat/marvell/misc/mvebu-ccu.txt deleted file mode 100644 index 976402761..000000000 --- a/docs/plat/marvell/misc/mvebu-ccu.txt +++ /dev/null @@ -1,23 +0,0 @@ -Marvell CCU address decoding bindings -===================================== - -CCU configration driver (1st stage address translation) for Marvell Armada 8K and 8K+ SoCs. - -The CCU node includes a description of the address decoding configuration. - -Mandatory functions: - - marvell_get_ccu_memory_map - return the CCU windows configuration and the number of windows - of the specific AP. - -Mandatory structures: - ccu_memory_map - Array that includes the configuration of the windows - every window/entry is a struct which has 3 parameters: - - Base address of the window - - Size of the window - - Target-ID of the window - -Example: - struct addr_map_win ccu_memory_map[] = { - {0x00000000f2000000, 0x00000000e000000, IO_0_TID}, /* IO window */ - }; diff --git a/docs/plat/marvell/misc/mvebu-io-win.txt b/docs/plat/marvell/misc/mvebu-io-win.rst index c83ad1fd2..52845ca02 100644 --- a/docs/plat/marvell/misc/mvebu-io-win.txt +++ b/docs/plat/marvell/misc/mvebu-io-win.rst @@ -1,5 +1,5 @@ Marvell IO WIN address decoding bindings -===================================== +======================================== IO Window configration driver (2nd stage address translation) for Marvell Armada 8K and 8K+ SoCs. @@ -8,26 +8,37 @@ The IO WIN includes a description of the address decoding configuration. Transactions that are decoded by CCU windows as IO peripheral, have an additional layer of decoding. This additional address decoding layer defines one of the following targets: - 0x0 = BootRom - 0x1 = STM (Serial Trace Macro-cell, a programmer's port into trace stream) - 0x2 = SPI direct access - 0x3 = PCIe registers - 0x4 = MCI Port - 0x5 = PCIe port - -Mandatory functions: - - marvell_get_io_win_memory_map - returns the IO windows configuration and the number of windows - of the specific AP. - -Mandatory structures: - io_win_memory_map - Array that include the configuration of the windows - every window/entry is a struct which has 3 parameters: + +- **0x0** = BootRom +- **0x1** = STM (Serial Trace Macro-cell, a programmer's port into trace stream) +- **0x2** = SPI direct access +- **0x3** = PCIe registers +- **0x4** = MCI Port +- **0x5** = PCIe port + +Mandatory functions +------------------- + +- marvell_get_io_win_memory_map + Returns the IO windows configuration and the number of windows of the + specific AP. + +Mandatory structures +-------------------- + +- io_win_memory_map + Array that include the configuration of the windows. Every window/entry is + a struct which has 3 parameters: + - Base address of the window - Size of the window - Target-ID of the window -Example: +Example +------- + +.. code:: c + struct addr_map_win io_win_memory_map[] = { {0x00000000fe000000, 0x000000001f00000, PCIE_PORT_TID}, /* PCIe window 31Mb for PCIe port*/ {0x00000000ffe00000, 0x000000000100000, PCIE_REGS_TID}, /* PCI-REG window 64Kb for PCIe-reg*/ diff --git a/docs/plat/marvell/misc/mvebu-iob.txt b/docs/plat/marvell/misc/mvebu-iob.rst index 97ec09d0e..d02a7e84c 100644 --- a/docs/plat/marvell/misc/mvebu-iob.txt +++ b/docs/plat/marvell/misc/mvebu-iob.rst @@ -10,28 +10,40 @@ When a transaction passes through the IOB, its address is compared to each of the enabled windows. If there is a hit and it passes the security checks, it is advanced to the target port. -Mandatory functions: - - marvell_get_iob_memory_map - returns the IOB windows configuration and the number of windows - -Mandatory structures: - iob_memory_map - Array that include the configuration of the windows - every window/entry is a struct which has 3 parameters: - - Base address of the window - - Size of the window - - Target-ID of the window - -Target ID options: - - 0x0 = Internal configuration space - - 0x1 = MCI0 - - 0x2 = PEX1_X1 - - 0x3 = PEX2_X1 - - 0x4 = PEX0_X4 - - 0x5 = NAND flash - - 0x6 = RUNIT (NOR/SPI/BootRoom) - - 0x7 = MCI1 - -Example: +Mandatory functions +------------------- + +- marvell_get_iob_memory_map + Returns the IOB windows configuration and the number of windows + +Mandatory structures +-------------------- + +- iob_memory_map + Array that includes the configuration of the windows. Every window/entry is + a struct which has 3 parameters: + + - Base address of the window + - Size of the window + - Target-ID of the window + +Target ID options +----------------- + +- **0x0** = Internal configuration space +- **0x1** = MCI0 +- **0x2** = PEX1_X1 +- **0x3** = PEX2_X1 +- **0x4** = PEX0_X4 +- **0x5** = NAND flash +- **0x6** = RUNIT (NOR/SPI/BootRoom) +- **0x7** = MCI1 + +Example +------- + +.. code:: c + struct addr_map_win iob_memory_map[] = { {0x00000000f7000000, 0x0000000001000000, PEX1_TID}, /* PEX1_X1 window */ {0x00000000f8000000, 0x0000000001000000, PEX2_TID}, /* PEX2_X1 window */ diff --git a/docs/plat/marvell/porting.rst b/docs/plat/marvell/porting.rst new file mode 100644 index 000000000..0a71dbd54 --- /dev/null +++ b/docs/plat/marvell/porting.rst @@ -0,0 +1,163 @@ +TF-A Porting Guide for Marvell Platforms +======================================== + +This section describes how to port TF-A to a customer board, assuming that the +SoC being used is already supported in TF-A. + + +Source Code Structure +--------------------- + +- The customer platform specific code shall reside under ``plat/marvell/<soc family>/<soc>_cust`` + (e.g. 'plat/marvell/a8k/a7040_cust'). +- The platform name for build purposes is called ``<soc>_cust`` (e.g. ``a7040_cust``). +- The build system will reuse all files from within the soc directory, and take only the porting + files from the customer platform directory. + +Files that require porting are located at ``plat/marvell/<soc family>/<soc>_cust`` directory. + + +Armada-70x0/Armada-80x0 Porting +------------------------------- + +SoC Physical Address Map (marvell_plat_config.c) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This file describes the SoC physical memory mapping to be used for the CCU, +IOWIN, AXI-MBUS and IOB address decode units (Refer to the functional spec for +more details). + +In most cases, using the default address decode windows should work OK. + +In cases where a special physical address map is needed (e.g. Special size for +PCIe MEM windows, large memory mapped SPI flash...), then porting of the SoC +memory map is required. + +.. note:: + For a detailed information on how CCU, IOWIN, AXI-MBUS & IOB work, please + refer to the SoC functional spec, and under + ``docs/marvell/misc/mvebu-[ccu/iob/amb/io-win].txt`` files. + +boot loader recovery (marvell_plat_config.c) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Background: + + Boot rom can skip the current image and choose to boot from next position if a + specific value (``0xDEADB002``) is returned by the ble main function. This + feature is used for boot loader recovery by booting from a valid flash-image + saved in next position on flash (e.g. address 2M in SPI flash). + + Supported options to implement the skip request are: + - GPIO + - I2C + - User defined + +- Porting: + + Under marvell_plat_config.c, implement struct skip_image that includes + specific board parameters. + + .. warning:: + To disable this feature make sure the struct skip_image is not implemented. + +- Example: + +In A7040-DB specific implementation +(``plat/marvell/a8k/a70x0/board/marvell_plat_config.c``), the image skip is +implemented using GPIO: mpp 33 (SW5). + +Before resetting the board make sure there is a valid image on the next flash +address: + + -tftp [valid address] flash-image.bin + -sf update [valid address] 0x2000000 [size] + +Press reset and keep pressing the button connected to the chosen GPIO pin. A +skip image request message is printed on the screen and boot rom boots from the +saved image at the next position. + +DDR Porting (dram_port.c) +~~~~~~~~~~~~~~~~~~~~~~~~~ + +This file defines the dram topology and parameters of the target board. + +The DDR code is part of the BLE component, which is an extension of ARM Trusted +Firmware (TF-A). + +The DDR driver called mv_ddr is released separately apart from TF-A sources. + +The BLE and consequently, the DDR init code is executed at the early stage of +the boot process. + +Each supported platform of the TF-A has its own DDR porting file called +dram_port.c located at ``atf/plat/marvell/a8k/<platform>/board`` directory. + +Please refer to '<path_to_mv_ddr_sources>/doc/porting_guide.txt' for detailed +porting description. + +The build target directory is "build/<platform>/release/ble". + +Comphy Porting (phy-porting-layer.h or phy-default-porting-layer.h) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- Background: + Some of the comphy's parameters value depend on the HW connection between + the SoC and the PHY. Every board type has specific HW characteristics like + wire length. Due to those differences some comphy parameters vary between + board types. Therefore each board type can have its own list of values for + all relevant comphy parameters. The PHY porting layer specifies which + parameters need to be suited and the board designer should provide relevant + values. + + .. seealso:: + For XFI/SFI comphy type there is procedure "rx_training" which eases + process of suiting some of the parameters. Please see *uboot_cmd* + section: rx_training. + + The PHY porting layer simplifies updating static values per board type, + which are now grouped in one place. + + .. note:: + The parameters for the same type of comphy may vary even for the same + board type, it is because the lanes from comphy-x to some PHY may have + different HW characteristic than lanes from comphy-y to the same + (multiplexed) or other PHY. + +- Porting: + The porting layer for PHY was introduced in TF-A. There is one file + ``drivers/marvell/comphy/phy-default-porting-layer.h`` which contains the + defaults. Those default parameters are used only if there is no appropriate + phy-porting-layer.h file under: ``plat/marvell/<soc + family>/<platform>/board/phy-porting-layer.h``. If the phy-porting-layer.h + exists, the phy-default-porting-layer.h is not going to be included. + + .. warning:: + Not all comphy types are already reworked to support the PHY porting + layer, currently the porting layer is supported for XFI/SFI and SATA + comphy types. + + The easiest way to prepare the PHY porting layer for custom board is to copy + existing example to a new platform: + + - cp ``plat/marvell/a8k/a80x0/board/phy-porting-layer.h`` "plat/marvell/<soc family>/<platform>/board/phy-porting-layer.h" + - adjust relevant parameters or + - if different comphy index is used for specific feature, move it to proper table entry and then adjust. + + .. note:: + The final table size with comphy parameters can be different, depending + on the CP module count for given SoC type. + +- Example: + Example porting layer for armada-8040-db is under: + ``plat/marvell/a8k/a80x0/board/phy-porting-layer.h`` + + .. note:: + If there is no PHY porting layer for new platform (missing + phy-porting-layer.h), the default values are used + (drivers/marvell/comphy/phy-default-porting-layer.h) and the user is + warned: + + .. warning:: + "Using default comphy parameters - it may be required to suit them for + your board". diff --git a/docs/plat/marvell/porting.txt b/docs/plat/marvell/porting.txt deleted file mode 100644 index f9a39a054..000000000 --- a/docs/plat/marvell/porting.txt +++ /dev/null @@ -1,118 +0,0 @@ -.. _porting: - -TF-A Porting Guide -================= - -This section describes how to port TF-A to a customer board, assuming that the SoC being used is already supported -in TF-A. - - -Source Code Structure ---------------------- -- The customer platform specific code shall reside under "plat/marvell/<soc family>/<soc>_cust" - (e.g. 'plat/marvell/a8k/a7040_cust'). -- The platform name for build purposes is called "<soc>_cust" (e.g. a7040_cust). -- The build system will reuse all files from within the soc directory, and take only the porting - files from the customer platform directory. - -Files that require porting are located at "plat/marvell/<soc family>/<soc>_cust" directory. - - -Armada-70x0/Armada-80x0 Porting -------------------------------- - - - SoC Physical Address Map (marvell_plat_config.c): - - This file describes the SoC physical memory mapping to be used for the CCU, IOWIN, AXI-MBUS and IOB - address decode units (Refer to the functional spec for more details). - - In most cases, using the default address decode windows should work OK. - - In cases where a special physical address map is needed (e.g. Special size for PCIe MEM windows, - large memory mapped SPI flash...), then porting of the SoC memory map is required. - - Note: For a detailed information on how CCU, IOWIN, AXI-MBUS & IOB work, please refer to the SoC functional spec, - and under "docs/marvell/misc/mvebu-[ccu/iob/amb/io-win].txt" files. - - - boot loader recovery (marvell_plat_config.c): - - Background: - boot rom can skip the current image and choose to boot from next position if a specific value - (0xDEADB002) is returned by the ble main function. This feature is used for boot loader recovery - by booting from a valid flash-image saved in next position on flash (e.g. address 2M in SPI flash). - - Supported options to implement the skip request are: - - GPIO - - I2C - - User defined - - - Porting: - Under marvell_plat_config.c, implement struct skip_image that includes specific board parameters. - .. warning:: to disable this feature make sure the struct skip_image is not implemented. - - - Example: - In A7040-DB specific implementation (plat/marvell/a8k/a70x0/board/marvell_plat_config.c), - the image skip is implemented using GPIO: mpp 33 (SW5). - - Before resetting the board make sure there is a valid image on the next flash address: - -tftp [valid address] flash-image.bin - -sf update [valid address] 0x2000000 [size] - - Press reset and keep pressing the button connected to the chosen GPIO pin. A skip image request - message is printed on the screen and boot rom boots from the saved image at the next position. - - - DDR Porting (dram_port.c): - - This file defines the dram topology and parameters of the target board. - - The DDR code is part of the BLE component, which is an extension of ARM Trusted Firmware (TF-A). - - The DDR driver called mv_ddr is released separately apart from TF-A sources. - - The BLE and consequently, the DDR init code is executed at the early stage of the boot process. - - Each supported platform of the TF-A has its own DDR porting file called dram_port.c located at - ``atf/plat/marvell/a8k/<platform>/board`` directory. - - Please refer to '<path_to_mv_ddr_sources>/doc/porting_guide.txt' for detailed porting description. - - The build target directory is "build/<platform>/release/ble". - - - Comphy Porting (phy-porting-layer.h or phy-default-porting-layer.h) - - Background: - Some of the comphy's parameters value depend on the HW connection between the SoC and the PHY. Every - board type has specific HW characteristics like wire length. Due to those differences some comphy - parameters vary between board types. Therefore each board type can have its own list of values for - all relevant comphy parameters. The PHY porting layer specifies which parameters need to be suited and - the board designer should provide relevant values. - - .. seealso:: - For XFI/SFI comphy type there is procedure "rx_training" which eases process of suiting some of - the parameters. Please see :ref:`uboot_cmd` section: rx_training. - - The PHY porting layer simplifies updating static values per board type, which are now grouped in one place. - - .. note:: - The parameters for the same type of comphy may vary even for the same board type, it is because - the lanes from comphy-x to some PHY may have different HW characteristic than lanes from - comphy-y to the same (multiplexed) or other PHY. - - - Porting: - The porting layer for PHY was introduced in TF-A. There is one file - ``drivers/marvell/comphy/phy-default-porting-layer.h`` which contains the defaults. Those default - parameters are used only if there is no appropriate phy-porting-layer.h file under: - ``plat/marvell/<soc family>/<platform>/board/phy-porting-layer.h``. If the phy-porting-layer.h exists, - the phy-default-porting-layer.h is not going to be included. - - .. warning:: - Not all comphy types are already reworked to support the PHY porting layer, currently the porting - layer is supported for XFI/SFI and SATA comphy types. - - The easiest way to prepare the PHY porting layer for custom board is to copy existing example to a new - platform: - - - cp ``plat/marvell/a8k/a80x0/board/phy-porting-layer.h`` "plat/marvell/<soc family>/<platform>/board/phy-porting-layer.h" - - adjust relevant parameters or - - if different comphy index is used for specific feature, move it to proper table entry and then adjust. - - .. note:: - The final table size with comphy parameters can be different, depending on the CP module count for - given SoC type. - - - Example: - Example porting layer for armada-8040-db is under: ``plat/marvell/a8k/a80x0/board/phy-porting-layer.h`` - - .. note:: - If there is no PHY porting layer for new platform (missing phy-porting-layer.h), the default - values are used (drivers/marvell/comphy/phy-default-porting-layer.h) and the user is warned: - - .. warning:: - "Using default comphy parameters - it may be required to suit them for your board". diff --git a/docs/plat/meson-g12a.rst b/docs/plat/meson-g12a.rst new file mode 100644 index 000000000..7cd1bf746 --- /dev/null +++ b/docs/plat/meson-g12a.rst @@ -0,0 +1,27 @@ +Amlogic Meson S905X2 (G12A) +=========================== + +The Amlogic Meson S905X2 is a SoC with a quad core Arm Cortex-A53 running at +~1.8GHz. It also contains a Cortex-M3 used as SCP. + +This port is a minimal implementation of BL31 capable of booting mainline U-Boot +and Linux: + +- SCPI support. +- Basic PSCI support (CPU_ON, CPU_OFF, SYSTEM_RESET, SYSTEM_OFF). Note that CPU0 + can't be turned off, so there is a workaround to hide this from the caller. +- GICv2 driver set up. +- Basic SIP services (read efuse data, enable/disable JTAG). + +In order to build it: + +.. code:: shell + + CROSS_COMPILE=aarch64-linux-gnu- make DEBUG=1 PLAT=g12a + +This port has been tested on a SEI510 board. After building it, follow the +instructions in the `gxlimg repository` or `U-Boot repository`_, replacing the +mentioned **bl31.img** by the one built from this port. + +.. _gxlimg repository: https://github.com/repk/gxlimg/blob/master/README.g12a +.. _U-Boot repository: https://github.com/u-boot/u-boot/blob/master/board/amlogic/sei510/README diff --git a/docs/plat/nvidia-tegra.rst b/docs/plat/nvidia-tegra.rst index bc9e35b4f..02ff38bef 100644 --- a/docs/plat/nvidia-tegra.rst +++ b/docs/plat/nvidia-tegra.rst @@ -1,6 +1,17 @@ NVIDIA Tegra ============ +- .. rubric:: T194 + :name: t194 + +T194 has eight NVIDIA Carmel CPU cores in a coherent multi-processor +configuration. The Carmel cores support the ARM Architecture version 8.2, +executing both 64-bit AArch64 code, and 32-bit AArch32 code. The Carmel +processors are organized as four dual-core clusters, where each cluster has +a dedicated 2 MiB Level-2 unified cache. A high speed coherency fabric connects +these processor complexes and allows heterogeneous multi-processing with all +eight cores if required. + - .. rubric:: T186 :name: t186 @@ -78,9 +89,10 @@ their dispatchers in the image without changing any makefiles. These are the supported Trusted OS' by Tegra platforms. -Tegra132: TLK -Tegra210: TLK and Trusty -Tegra186: Trusty +- Tegra132: TLK +- Tegra210: TLK and Trusty +- Tegra186: Trusty +- Tegra194: Trusty Scatter files ------------- @@ -98,7 +110,7 @@ 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. t186|t210|t132> SPD=<dispatcher e.g. trusty|tlkd> + TARGET_SOC=<target-soc e.g. t194|t186|t210|t132> SPD=<dispatcher e.g. trusty|tlkd> bl31 Platforms wanting to use different TZDRAM\_BASE, can add ``TZDRAM_BASE=<value>`` diff --git a/docs/plat/poplar.rst b/docs/plat/poplar.rst index 5884ed945..215f55142 100644 --- a/docs/plat/poplar.rst +++ b/docs/plat/poplar.rst @@ -1,5 +1,5 @@ -Description -=========== +Poplar +====== Poplar is the first development board compliant with the 96Boards Enterprise Edition TV Platform specification. @@ -35,10 +35,10 @@ must happen prior to invoking Trusted Firmware-A: l-loader --> Trusted Firmware-A --> u-boot How to build -============ +------------ Code Locations --------------- +~~~~~~~~~~~~~~ - Trusted Firmware-A: `link <https://github.com/ARM-software/arm-trusted-firmware>`__ @@ -50,7 +50,7 @@ Code Locations `link <http://git.denx.de/u-boot.git>`__ Build Procedure ---------------- +~~~~~~~~~~~~~~~ - Fetch all the above 3 repositories into local host. Make all the repositories in the same ${BUILD\_PATH}. @@ -89,7 +89,7 @@ The system will boot into a u-boot shell which you can then use to write the working firmware to eMMC. Boot trace -========== +---------- :: diff --git a/docs/plat/qemu-sbsa.rst b/docs/plat/qemu-sbsa.rst new file mode 100644 index 000000000..51fe41404 --- /dev/null +++ b/docs/plat/qemu-sbsa.rst @@ -0,0 +1,48 @@ +QEMU SBSA Target +================ + +Trusted Firmware-A (TF-A) implements the EL3 firmware layer for QEMU SBSA +Armv8-A. While running Qemu from command line, we need to supply two Flash +images. First Secure BootRom is supplied by -pflash argument. This Flash image +is made by EDK2 build system by composing BL1 and FIP. Second parameter for Qemu +is responsible for Non-secure rom which also given with -pflash argument and +contains of UEFI and EFI variables (also made by EDK2 build system). Semihosting +is not used + +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 FDT, generated by QEMU at run-time to add a node describing PSCI +and also enable methods for the CPUs. + +Current limitations: + +- Only cold boot is supported +- No instructions for how to load a BL32 (Secure Payload) + +To build TF-A: + +:: + + git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git tfa + cd tfa + export CROSS_COMPILE=aarch64-linux-gnu- + make PLAT=qemu_sbsa all fip + +Images will be placed at build/qemu_sbsa/release (bl1.bin and fip.bin). +Need to copy them into top directory for EDK2 compilation. + +:: + + cp build/qemu_sbsa/release/bl1.bin ../ + cp build/qemu_sbsa/release/fip.bin ../ + +Those images cannot be used by itself (no semihosing support). Flash images are built by +EDK2 build system, refer to edk2-platform repo for full build instructions. + +:: + + git clone https://github.com/tianocore/edk2-platforms.git + Platform/Qemu/SbsaQemu/Readme.md + diff --git a/docs/plat/qemu.rst b/docs/plat/qemu.rst index 4ebe64b85..88196bc93 100644 --- a/docs/plat/qemu.rst +++ b/docs/plat/qemu.rst @@ -10,7 +10,11 @@ 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 defconfig v4.5 Linux kernel is known to boot, FDT doesn't need to be +If ``ARM_LINUX_KERNEL_AS_BL33`` is set to 1 then this FDT will be passed to BL33 +via register x0, as expected by a Linux kernel. This allows a Linux kernel image +to be booted directly as BL33 rather than using a bootloader. + +An ARM64 defconfig v5.5 Linux kernel is known to boot, FDT doesn't need to be provided as it's generated by QEMU. Current limitations: @@ -20,7 +24,7 @@ Current limitations: - 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 +http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/latest/QEMU-KERNEL-AARCH64/RELEASE_GCC5/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 @@ -29,7 +33,7 @@ is conveniently achieved with symlinks the local names as: - ``bl2.bin`` -> BL2 - ``bl31.bin`` -> BL31 - ``bl33.bin`` -> BL33 (``QEMU_EFI.fd``) -- ``Image`` -> linux/Image +- ``Image`` -> linux/arch/arm64/boot/Image To build: @@ -37,12 +41,12 @@ To build: make CROSS_COMPILE=aarch64-none-elf- PLAT=qemu -To start (QEMU v2.6.0): +To start (QEMU v4.1.0): .. code:: shell qemu-system-aarch64 -nographic -machine virt,secure=on -cpu cortex-a57 \ -kernel Image \ - -append console=ttyAMA0,38400 keep_bootcon root=/dev/vda2 \ + -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/rpi4.rst b/docs/plat/rpi4.rst new file mode 100644 index 000000000..beb0227c2 --- /dev/null +++ b/docs/plat/rpi4.rst @@ -0,0 +1,84 @@ +Raspberry Pi 4 +============== + +The `Raspberry Pi 4`_ is an inexpensive single-board computer that contains four +Arm Cortex-A72 cores. Also in contrast to previous Raspberry Pi versions this +model has a GICv2 interrupt controller. + +This port is a minimal port to support loading non-secure EL2 payloads such +as a 64-bit Linux kernel. Other payloads such as U-Boot or EDK-II should work +as well, but have not been tested at this point. + +**IMPORTANT NOTE**: This port isn't secure. All of the memory used is DRAM, +which is available from both the Non-secure and Secure worlds. The SoC does +not seem to feature a secure memory controller of any kind, so portions of +DRAM can't be protected properly from the Non-secure world. + +Build Instructions +------------------ + +There are no real configuration options at this point, so there is only +one universal binary (bl31.bin), which can be built with: + +.. code:: shell + + CROSS_COMPILE=aarch64-linux-gnu- make PLAT=rpi4 DEBUG=1 + +Copy the generated build/rpi4/debug/bl31.bin to the SD card, adding an entry +starting with ``armstub=``, then followed by the respective file name to +``config.txt``. You should have AArch64 code in the file loaded as the +"kernel", as BL31 will drop into AArch64/EL2 to the respective load address. +arm64 Linux kernels are known to work this way. + +Other options that should be set in ``config.txt`` to properly boot 64-bit +kernels are: + +:: + + enable_uart=1 + arm_64bit=1 + enable_gic=1 + +The BL31 code will patch the provided device tree blob in memory to advertise +PSCI support, also will add a reserved-memory node to the DT to tell the +non-secure payload to not touch the resident TF-A code. + +If you connect a serial cable between the Mini UART and your computer, and +connect to it (for example, with ``screen /dev/ttyUSB0 115200``) you should +see some text from BL31, followed by the output of the EL2 payload. +The command line provided is read from the ``cmdline.txt`` file on the SD card. + +TF-A port design +---------------- + +In contrast to the existing Raspberry Pi 3 port this one here is a BL31-only +port, also it deviates quite a lot from the RPi3 port in many other ways. +There is not so much difference between the two models, so eventually those +two could be (more) unified in the future. + +As with the previous models, the GPU and its firmware are the first entity to +run after the SoC gets its power. The on-chip Boot ROM loads the next stage +(bootcode.bin) from flash (EEPROM), which is again GPU code. +This part knows how to access the MMC controller and how to parse a FAT +filesystem, so it will load further compononents and configuration files +from the first FAT partition on the SD card. + +To accommodate this existing way of configuring and setting up the board, +we use as much of this workflow as possible. +If bootcode.bin finds a file called ``armstub8.bin`` on the SD card or it gets +pointed to such code by finding a ``armstub=`` key in ``config.txt``, it will +load this file to the beginning of DRAM (address 0) and execute it in +AArch64 EL3. +But before doing that, it will also load a "kernel" and the device tree into +memory. The load addresses have a default, but can also be changed by +setting them in ``config.txt``. If the GPU firmware finds a magic value in the +armstub image file, it will put those two load addresses in memory locations +near the beginning of memory, where TF-A code picks them up. + +To keep things simple, we will just use the kernel load address as the BL33 +entry point, also put the DTB address in the x0 register, as requested by +the arm64 Linux kernel boot protocol. This does not necessarily mean that +the EL2 payload needs to be a Linux kernel, a bootloader or any other kernel +would work as well, as long as it can cope with having the DT address in +register x0. If the payload has other means of finding the device tree, it +could ignore this address as well. diff --git a/docs/plat/socionext-uniphier.rst b/docs/plat/socionext-uniphier.rst index 82b9b503a..92881932c 100644 --- a/docs/plat/socionext-uniphier.rst +++ b/docs/plat/socionext-uniphier.rst @@ -8,10 +8,11 @@ UniPhier SoC family implements its internal boot ROM, which loads 64KB [1]_ image from a non-volatile storage to the on-chip SRAM, and jumps over to it. TF-A provides a special mode, BL2-AT-EL3, which enables BL2 to execute at EL3. It is useful for platforms with non-TF-A boot ROM, like UniPhier. Here, a -problem is BL2 does not fit in the 64KB limit if `Trusted Board Boot`_ (TBB) -is enabled. To solve this issue, Socionext provides a first stage loader -called `UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the -DRAM, expands BL2 there, and hands the control over to it. Therefore, all images +problem is BL2 does not fit in the 64KB limit if +:ref:`Trusted Board Boot (TBB) <Trusted Board Boot>` is enabled. +To solve this issue, Socionext provides a first stage loader called +`UniPhier BL`_. This loader runs in the on-chip SRAM, initializes the DRAM, +expands BL2 there, and hands the control over to it. Therefore, all images of TF-A run in DRAM. The UniPhier platform works with/without TBB. See below for the build process @@ -50,7 +51,7 @@ Boot Flow 4. BL31, BL32, and BL33 - They all run in the DRAM. See `Firmware Design`_ for details. + They all run in the DRAM. See :ref:`Firmware Design` for details. Basic Build @@ -79,7 +80,8 @@ 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. + Refer to the :ref:`Prerequisites` document for the appropriate version of + mbed TLS. To enable TBB, add the following options to the build command:: @@ -109,9 +111,6 @@ Optional features .. [1] Some SoCs can load 80KB, but the software implementation must be aligned to the lowest common denominator. -.. _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/stm32mp1.rst b/docs/plat/stm32mp1.rst index 88251d6af..2c372a6a3 100644 --- a/docs/plat/stm32mp1.rst +++ b/docs/plat/stm32mp1.rst @@ -76,21 +76,34 @@ ROM code -> BL2 (compiled with BL2_AT_EL3) -> OP-TEE -> BL33 (U-Boot) Build Instructions ------------------ +Boot media(s) supported by BL2 must be specified in the build command. +Available storage medias are: +- ``STM32MP_SDMMC`` +- ``STM32MP_EMMC`` +- ``STM32MP_RAW_NAND`` +- ``STM32MP_SPI_NAND`` +- ``STM32MP_SPI_NOR`` -To build with SP_min: +To build with SP_min and support for all bootable devices: .. code:: bash - make CROSS_COMPILE=arm-linux-gnueabihf- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 AARCH32_SP=sp_min DTB_FILE_NAME=stm32mp157c-ev1.dtb + make CROSS_COMPILE=arm-linux-gnueabihf- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 AARCH32_SP=sp_min STM32MP_SDMMC=1 STM32MP_EMMC=1 STM32MP_RAW_NAND=1 STM32MP_SPI_NAND=1 + STM32MP_SPI_NOR=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb cd <u-boot_directory> make stm32mp15_trusted_defconfig make DEVICE_TREE=stm32mp157c-ev1 all -To build TF-A with with Op-TEE support: - +To build TF-A with OP-TEE support for all bootable devices: .. code:: bash - make CROSS_COMPILE=arm-linux-gnueabihf- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 AARCH32_SP=optee + make CROSS_COMPILE=arm-linux-gnueabihf- PLAT=stm32mp1 ARCH=aarch32 ARM_ARCH_MAJOR=7 AARCH32_SP=optee STM32MP_SDMMC=1 STM32MP_EMMC=1 STM32MP_RAW_NAND=1 STM32MP_SPI_NAND=1 STM32MP_SPI_NOR=1 DTB_FILE_NAME=stm32mp157c-ev1.dtb + cd <optee_directory> + make CROSS_COMPILE=arm-linux-gnueabihf- ARCH=arm PLATFORM=stm32mp1 CFG_EMBED_DTB_SOURCE_FILE=stm32mp157c-ev1.dts + cd <u-boot_directory> + make stm32mp15_optee_defconfig + make DEVICE_TREE=stm32mp157c-ev1 all + The following build options are supported: diff --git a/docs/plat/xilinx-versal.rst b/docs/plat/xilinx-versal.rst index 231286e7e..57a363bc9 100644 --- a/docs/plat/xilinx-versal.rst +++ b/docs/plat/xilinx-versal.rst @@ -14,7 +14,7 @@ To build: make RESET_TO_BL31=1 CROSS_COMPILE=aarch64-none-elf- PLAT=versal bl31 ``` -To build ATF for different platform (for now its just versal virtual "versal_virt") +To build ATF for different platform (supported are "silicon"(default) and "versal_virt") ```bash make RESET_TO_BL31=1 CROSS_COMPILE=aarch64-none-elf- PLAT=versal VERSAL_PLATFORM=versal_virt bl31 ``` @@ -33,3 +33,11 @@ Xilinx Versal platform specific build options * `VERSAL_PLATFORM`: Select the platform. Options: - `versal_virt` : Versal Virtual platform + +# PLM->TF-A Parameter Passing +------------------------------ +The PLM populates a data structure with image information for the TF-A. The TF-A +uses that data to hand off to the loaded images. The address of the handoff +data structure is passed in the ```PMC_GLOBAL_GLOB_GEN_STORAGE4``` register. +The register is free to be used by other software once the TF-A is bringing up +further firmware images. |