1. 18 Sep, 2019 1 commit
  2. 13 Sep, 2019 1 commit
    • Andre Przywara's avatar
      qemu: Move and generalise FDT PSCI fixup · f240728b
      Andre Przywara authored
      
      
      The QEMU platform port scans its device tree to advertise PSCI as the
      CPU enable method. It does this by scanning *every* node in the DT and
      check whether its compatible string starts with "arm,cortex-a". Then it
      sets the enable-method to PSCI, if it doesn't already have one.
      
      Other platforms might want to use this functionality as well, so let's
      move it out of the QEMU platform directory and make it more robust by
      fixing some shortcomings:
      - A compatible string starting with a certain prefix is not a good way
      to find the CPU nodes. For instance a "arm,cortex-a72-pmu" node will
      match as well and is in turn favoured with an enable-method.
      - If the DT already has an enable-method, we won't change this to PSCI.
      
      Those two issues will for instance fail on the Raspberry Pi 4 DT.
      To fix those problems, we adjust the scanning method:
      The DT spec says that all CPU nodes are subnodes of the mandatory
      /cpus node, which is a subnode of the root node. Also each CPU node has
      to have a device_type = "cpu" property. So we find the /cpus node, then
      scan for a subnode with the proper device_type, forcing the
      enable-method to "psci".
      We have to restart this search after a property has been patched, as the
      node offsets might have changed meanwhile.
      
      This allows this routine to be reused for the Raspberry Pi 4 later.
      
      Change-Id: I00cae16cc923d9f8bb96a9b2a2933b9a79b06139
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      f240728b
  3. 01 Aug, 2019 1 commit
    • Julius Werner's avatar
      Switch AARCH32/AARCH64 to __aarch64__ · 402b3cf8
      Julius Werner authored
      
      
      NOTE: AARCH32/AARCH64 macros are now deprecated in favor of __aarch64__.
      
      All common C compilers pre-define the same macros to signal which
      architecture the code is being compiled for: __arm__ for AArch32 (or
      earlier versions) and __aarch64__ for AArch64. There's no need for TF-A
      to define its own custom macros for this. In order to unify code with
      the export headers (which use __aarch64__ to avoid another dependency),
      let's deprecate the AARCH32 and AARCH64 macros and switch the code base
      over to the pre-defined standard macro. (Since it is somewhat
      unintuitive that __arm__ only means AArch32, let's standardize on only
      using __aarch64__.)
      
      Change-Id: Ic77de4b052297d77f38fc95f95f65a8ee70cf200
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      402b3cf8
  4. 04 Jan, 2019 1 commit
    • Antonio Nino Diaz's avatar
      Sanitise includes across codebase · 09d40e0e
      Antonio Nino Diaz authored
      Enforce full include path for includes. Deprecate old paths.
      
      The following folders inside include/lib have been left unchanged:
      
      - include/lib/cpus/${ARCH}
      - include/lib/el3_runtime/${ARCH}
      
      The reason for this change is that having a global namespace for
      includes isn't a good idea. It defeats one of the advantages of having
      folders and it introduces problems that are sometimes subtle (because
      you may not know the header you are actually including if there are two
      of them).
      
      For example, this patch had to be created because two headers were
      called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform
      to avoid collision."). More recently, this patch has had similar
      problems: 46f9b2c3 ("drivers: add tzc380 support").
      
      This problem was introduced in commit 4ecca339
      
       ("Move include and
      source files to logical locations"). At that time, there weren't too
      many headers so it wasn't a real issue. However, time has shown that
      this creates problems.
      
      Platforms that want to preserve the way they include headers may add the
      removed paths to PLAT_INCLUDES, but this is discouraged.
      
      Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      09d40e0e
  5. 01 Nov, 2018 1 commit
  6. 28 Sep, 2018 1 commit
  7. 04 Sep, 2018 1 commit
  8. 26 Mar, 2018 1 commit
  9. 22 Mar, 2018 1 commit
  10. 28 Feb, 2018 1 commit
    • Michalis Pappas's avatar
      qemu: Support SEPARATE_CODE_AND_RODATA · 27e0ccab
      Michalis Pappas authored
      
      
      Update qemu_configure_mmu_##_el to add an additional region for code,
      marked as MT_CODE | MT_SECURE. Update ro region attributes to NON_EXEC.
      
      Update calls to QEMU_CONFIGURE_BLx_MMU() to pass an additional region for
      code. Update calls to pass regions defined in common_def.h.
      
      Increase MAX_MMAP_REGIONS to 10.
      
      Enable SEPARATE_CODE_AND_RODATA by default on QEMU builds.
      
      Fixes ARM-software/tf-issues#558
      Signed-off-by: default avatarMichalis Pappas <mpappas@fastmail.fm>
      27e0ccab
  11. 05 Feb, 2018 1 commit
    • Etienne Carriere's avatar
      qemu: support ARMv7/Cortex-A15 · 765ed9fc
      Etienne Carriere authored
      
      
      Define Qemu AArch32 implementation for some platform functions
      (core position, secondary boot cores, crash console). These are
      derived from the AArch64 implementation.
      
      BL31 on Qemu is needed only for ARMv8 and later. On ARMv7, BL32 is
      the first executable image after BL2.
      
      Support SP_MIN and OP-TEE as BL32: create a sp_min make script target
      in Qemu, define mapping for IMAGE_BL32
      
      Minor fix Qemu return value type for plat_get_ns_image_entrypoint().
      
      Qemu model for the Cortex-A15 does not support the virtualization
      extension although the core expects it. To overcome the issue, Qemu
      ARMv7 configuration set ARCH_SUPPORTS_VIRTUALIZATION to 0.
      
      Add missing AArch32 assembly macro arm_print_gic_regs from ARM platform
      used by the Qemu platform.
      
      Qemu Cortex-A15 model integrates a single cluster with up to 4 cores.
      
      Change-Id: I65b44399071d6f5aa40d5183be11422b9ee9ca15
      Signed-off-by: default avatarEtienne Carriere <etienne.carriere@linaro.org>
      765ed9fc
  12. 24 Aug, 2017 1 commit
    • Jens Wiklander's avatar
      qemu: Add OP-TEE extra image parsing support · e2af1cad
      Jens Wiklander authored
      
      
      OP-TEE may have extra images to be loaded. Load them one by one and do
      the parsing. In this patch, ARM TF need to load up to 3 images for
      OP-TEE: header, pager and pages images. Header image is the info about
      optee os and images. Pager image include pager code and data.  Paged
      image include the paging parts using virtual memory.
      Signed-off-by: default avatarJens Wiklander <jens.wiklander@linaro.org>
      e2af1cad
  13. 16 Aug, 2017 1 commit
    • Fu Wei's avatar
      qemu: Add LOAD_IMAGE_V2 support · 64b31125
      Fu Wei authored
      
      
      The generic LOAD_IMAGE_V2 framework has been merged and enable for almost
      all the arm platform. Because qemu platform doesn't share those common
      files with arm, QEMU haven't got this support yet.
      
      This patch add all the necessary code the files for adding LOAD_IMAGE_V2
      support on QEMU and enable it as default.
      
      Fixes ARM-software/tf-issues#507
      Signed-off-by: default avatarFu Wei <fu.wei@linaro.org>
      64b31125
  14. 14 Jul, 2017 1 commit
  15. 03 May, 2017 1 commit
  16. 02 May, 2017 1 commit
  17. 06 Feb, 2017 1 commit
    • Douglas Raillard's avatar
      Replace some memset call by zeromem · 32f0d3c6
      Douglas Raillard authored
      
      
      Replace all use of memset by zeromem when zeroing moderately-sized
      structure by applying the following transformation:
      memset(x, 0, sizeof(x)) => zeromem(x, sizeof(x))
      
      As the Trusted Firmware is compiled with -ffreestanding, it forbids the
      compiler from using __builtin_memset and forces it to generate calls to
      the slow memset implementation. Zeromem is a near drop in replacement
      for this use case, with a more efficient implementation on both AArch32
      and AArch64.
      
      Change-Id: Ia7f3a90e888b96d056881be09f0b4d65b41aa79e
      Signed-off-by: default avatarDouglas Raillard <douglas.raillard@arm.com>
      32f0d3c6
  18. 18 Jan, 2017 1 commit
  19. 09 Jun, 2016 1 commit
  20. 08 Apr, 2016 1 commit
    • Antonio Nino Diaz's avatar
      Remove BL32_BASE when building without SPD for FVP · 81d139d5
      Antonio Nino Diaz authored
      Previously, when building TF without SPD support, BL2 tried to load a
      BL32 image from the FIP and fails to find one, which resulted on
      warning messages on the console. Even if there is a BL32 image in the
      FIP it shouldn't be loaded because there is no way to transfer
      control to the Secure Payload without SPD support.
      
      The Makefile has been modified to pass a define of the form
      SPD_${SPD} to the source code the same way it's done for PLAT. The
      define SPD_none is then used to undefine BL32_BASE when BL32 is not
      used to prevent BL2 from trying to load a BL32 image and failing,
      thus removing the warning messages mentioned above.
      
      Fixes ARM-software/tf-issues#287
      
      Change-Id: Ifeb6f1c26935efb76afd353fea88e87ba09e9658
      81d139d5
  21. 31 Mar, 2016 1 commit
    • David Wang's avatar
      Add support to load BL31 in DRAM · 4518dd9a
      David Wang authored
      This patch adds an option to the ARM common platforms to load BL31 in the
      TZC secured DRAM instead of the default secure SRAM.
      
      To enable this feature, set `ARM_BL31_IN_DRAM` to 1 in build options.
      If TSP is present, then setting this option also sets the TSP location
      to DRAM and ignores the `ARM_TSP_RAM_LOCATION` build flag.
      
      To use this feature, BL2 platform code must map in the DRAM used by
      BL31. The macro ARM_MAP_BL31_SEC_DRAM is provided for this purpose.
      Currently, only the FVP BL2 platform code maps in this DRAM.
      
      Change-Id: If5f7cc9deb569cfe68353a174d4caa48acd78d67
      4518dd9a
  22. 14 Dec, 2015 2 commits
    • Juan Castillo's avatar
      Remove dashes from image names: 'BL3-x' --> 'BL3x' · d178637d
      Juan Castillo authored
      This patch removes the dash character from the image name, to
      follow the image terminology in the Trusted Firmware Wiki page:
      
          https://github.com/ARM-software/arm-trusted-firmware/wiki
      
      Changes apply to output messages, comments and documentation.
      
      non-ARM platform files have been left unmodified.
      
      Change-Id: Ic2a99be4ed929d52afbeb27ac765ceffce46ed76
      d178637d
    • Juan Castillo's avatar
      Replace all SCP FW (BL0, BL3-0) references · f59821d5
      Juan Castillo authored
      This patch replaces all references to the SCP Firmware (BL0, BL30,
      BL3-0, bl30) with the image terminology detailed in the TF wiki
      (https://github.com/ARM-software/arm-trusted-firmware/wiki):
      
          BL0          -->  SCP_BL1
          BL30, BL3-0  -->  SCP_BL2
          bl30         -->  scp_bl2
      
      This change affects code, documentation, build system, tools and
      platform ports that load SCP firmware. ARM plaforms have been
      updated to the new porting API.
      
      IMPORTANT: build option to specify the SCP FW image has changed:
      
          BL30 --> SCP_BL2
      
      IMPORTANT: This patch breaks compatibility for platforms that use BL2
      to load SCP firmware. Affected platforms must be updated as follows:
      
          BL30_IMAGE_ID --> SCP_BL2_IMAGE_ID
          BL30_BASE --> SCP_BL2_BASE
          bl2_plat_get_bl30_meminfo() --> bl2_plat_get_scp_bl2_meminfo()
          bl2_plat_handle_bl30() --> bl2_plat_handle_scp_bl2()
      
      Change-Id: I24c4c1a4f0e4b9f17c9e4929da815c4069549e58
      f59821d5
  23. 28 Apr, 2015 1 commit
    • Dan Handley's avatar
      Add common ARM and CSS platform code · b4315306
      Dan Handley authored
      This major change pulls out the common functionality from the
      FVP and Juno platform ports into the following categories:
      
      *   (include/)plat/common. Common platform porting functionality that
      typically may be used by all platforms.
      
      *   (include/)plat/arm/common. Common platform porting functionality
      that may be used by all ARM standard platforms. This includes all
      ARM development platforms like FVP and Juno but may also include
      non-ARM-owned platforms.
      
      *   (include/)plat/arm/board/common. Common platform porting
      functionality for ARM development platforms at the board
      (off SoC) level.
      
      *   (include/)plat/arm/css/common. Common platform porting
      functionality at the ARM Compute SubSystem (CSS) level. Juno
      is an example of a CSS-based platform.
      
      *   (include/)plat/arm/soc/common. Common platform porting
      functionality at the ARM SoC level, which is not already defined
      at the ARM CSS level.
      
      No guarantees are made about the backward compatibility of
      functionality provided in (include/)plat/arm.
      
      Also remove any unnecessary variation between the ARM development
      platform ports, including:
      
      *   Unify the way BL2 passes `bl31_params_t` to BL3-1. Use the
      Juno implementation, which copies the information from BL2 memory
      instead of expecting it to persist in shared memory.
      
      *   Unify the TZC configuration. There is no need to add a region
      for SCP in Juno; it's enough to simply not allow any access to
      this reserved region. Also set region 0 to provide no access by
      default instead of assuming this is the case.
      
      *   Unify the number of memory map regions required for ARM
      development platforms, although the actual ranges mapped for each
      platform may be different. For the FVP port, this reduces the
      mapped peripheral address space.
      
      These latter changes will only be observed when the platform ports
      are migrated to use the new common platform code in subsequent
      patches.
      
      Change-Id: Id9c269dd3dc6e74533d0e5116fdd826d53946dc8
      b4315306
  24. 27 Apr, 2015 1 commit
    • Dan Handley's avatar
      Remove use of PLATFORM_CACHE_LINE_SIZE · ce4c820d
      Dan Handley authored
      The required platform constant PLATFORM_CACHE_LINE_SIZE is
      unnecessary since CACHE_WRITEBACK_GRANULE effectively provides the
      same information. CACHE_WRITEBACK_GRANULE is preferred since this
      is an architecturally defined term and allows comparison with the
      corresponding hardware register value.
      
      Replace all usage of PLATFORM_CACHE_LINE_SIZE with
      CACHE_WRITEBACK_GRANULE.
      
      Also, add a runtime assert in BL1 to check that the provided
      CACHE_WRITEBACK_GRANULE matches the value provided in CTR_EL0.
      
      Change-Id: If87286be78068424217b9f3689be358356500dcd
      ce4c820d
  25. 22 Jan, 2015 1 commit
    • Soby Mathew's avatar
      Remove coherent memory from the BL memory maps · ab8707e6
      Soby Mathew authored
      This patch extends the build option `USE_COHERENT_MEMORY` to
      conditionally remove coherent memory from the memory maps of
      all boot loader stages. The patch also adds necessary
      documentation for coherent memory removal in firmware-design,
      porting and user guides.
      
      Fixes ARM-Software/tf-issues#106
      
      Change-Id: I260e8768c6a5c2efc402f5804a80657d8ce38773
      ab8707e6
  26. 14 Oct, 2014 1 commit
    • Juan Castillo's avatar
      Juno: Reserve some DDR-DRAM for secure use · 740134e6
      Juan Castillo authored
      This patch configures the TrustZone Controller in Juno to split
      the 2GB DDR-DRAM memory at 0x80000000 into Secure and Non-Secure
      regions:
      
      - Secure DDR-DRAM: top 16 MB, except for the last 2 MB which are
        used by the SCP for DDR retraining
      - Non-Secure DDR-DRAM: remaining DRAM starting at base address
      
      Build option PLAT_TSP_LOCATION selects the location of the secure
      payload (BL3-2):
      
      - 'tsram' : Trusted SRAM (default option)
      - 'dram'  : Secure region in the DDR-DRAM (set by the TrustZone
                  controller)
      
      The MMU memory map has been updated to give BL2 permission to load
      BL3-2 into the DDR-DRAM secure region.
      
      Fixes ARM-software/tf-issues#233
      
      Change-Id: I6843fc32ef90aadd3ea6ac4c7f314f8ecbd5d07b
      740134e6
  27. 09 Oct, 2014 1 commit
    • Juan Castillo's avatar
      Juno: Use TZC-400 driver calls · ef538c6f
      Juan Castillo authored
      This patch replaces direct accesses to the TZC-400 registers by the
      appropiate calls to the generic driver available in the Trusted
      Firmware in order to initialize the TrustZone Controller.
      
      Functions related to the initialization of the secure memory,
      like the TZC-400 configuration, have been moved to a new file
      'plat_security.c'. This reorganization makes easier to set up
      the secure memory from any BL stage.
      
      TZC-400 initialization has been moved from BL1 to BL2 because BL1
      does not access the non-secure memory. It is BL2's responsibility
      to enable and configure the TZC-400 before loading the next BL
      images.
      
      In Juno, BL3-0 initializes some of the platform peripherals, like
      the DDR controller. Thus, BL3-0 must be loaded before configuring
      the TrustZone Controller. As a consequence, the IO layer
      initialization has been moved to early platform initialization.
      
      Fixes ARM-software/tf-issues#234
      
      Change-Id: I83dde778f937ac8d2996f7377e871a2e77d9490e
      ef538c6f
  28. 21 Aug, 2014 3 commits
    • Soby Mathew's avatar
      Rationalize UART usage among different BL stages · 12d554f9
      Soby Mathew authored
      This patch changes the UART port assignment for various BL stages
      so as to make it consistent on the platform ports. The BL1, BL2 and
      BL3-1 now uses UART0 on the FVP port and SoC UART0 on the Juno port.
      The BL3-2 uses UART2 on the FVP port and FPGA UART0 on the Juno
      port.
      
      This provides an interim fix to ARM-software/tf-issues#220 until
      support is added for changing the UART port for a BL image between
      cold boot and runtime.
      
      Change-Id: Iae5faea90be3d59e41e597b34a902f93e737505a
      12d554f9
    • Juan Castillo's avatar
      Juno: Read primary CPU MPID from SCC GPR_1 · 38af430a
      Juan Castillo authored
      This patch removes the PRIMARY_CPU definition hardcoded in the
      Juno port. Instead, the primary CPU is obtained at runtime by
      reading the SCC General Purpose Register 1 (GPR_1), whose value
      is copied by the SCP into shared memory during the boot process.
      
      Change-Id: I3981daa92eb7142250712274cf7f655b219837f5
      38af430a
    • Sandrine Bailleux's avatar
      Juno: Implement initial platform port · 01b916bf
      Sandrine Bailleux authored
      This patch adds the initial port of the ARM Trusted Firmware on the Juno
      development platform. This port does not support a BL3-2 image or any PSCI APIs
      apart from PSCI_VERSION and PSCI_CPU_ON. It enables workarounds for selected
      Cortex-A57 (#806969 & #813420) errata and implements the workaround for a Juno
      platform errata (Defect id 831273).
      
      Change-Id: Ib3d92df3af53820cfbb2977582ed0d7abf6ef893
      01b916bf
  29. 14 Aug, 2014 1 commit
    • Juan Castillo's avatar
      FVP: make usage of Trusted DRAM optional at build time · 186c1d4b
      Juan Castillo authored
      This patch groups the current contents of the Trusted DRAM region at
      address 0x00_0600_0000 (entrypoint mailboxes and BL3-1 parameters) in
      a single shared memory area that may be allocated to Trusted SRAM
      (default) or Trusted DRAM at build time by setting the
      FVP_SHARED_DATA_LOCATION make variable. The size of this shared
      memory is 4096 bytes.
      
      The combination 'Shared data in Trusted SRAM + TSP in Trusted DRAM'
      is not currently supported due to restrictions in the maximum number
      of mmu tables that can be created.
      
      Documentation has been updated to reflect these changes.
      
      Fixes ARM-software/tf-issues#100
      
      Change-Id: I26ff04d33ce4cacf8d770d1a1e24132b4fc53ff0
      186c1d4b
  30. 12 Aug, 2014 1 commit
    • Juan Castillo's avatar
      FVP: apply new naming conventions to memory regions · 637ebd2e
      Juan Castillo authored
      Secure ROM at address 0x0000_0000 is defined as FVP_TRUSTED_ROM
      Secure RAM at address 0x0400_0000 is defined as FVP_TRUSTED_SRAM
      Secure RAM at address 0x0600_0000 is defined as FVP_TRUSTED_DRAM
      
      BLn_BASE and BLn_LIMIT definitions have been updated and are based on
      these new memory regions.
      
      The available memory for each bootloader in the linker script is
      defined by BLn_BASE and BLn_LIMIT, instead of the complete memory
      region.
      
      TZROM_BASE/SIZE and TZRAM_BASE/SIZE are no longer required as part of
      the platform porting.
      
      FVP common definitions are defined in fvp_def.h while platform_def.h
      contains exclusively (with a few exceptions) the definitions that are
      mandatory in the porting guide. Therefore, platform_def.h now includes
      fvp_def.h instead of the other way around.
      
      Porting guide has been updated to reflect these changes.
      
      Change-Id: I39a6088eb611fc4a347db0db4b8f1f0417dbab05
      637ebd2e
  31. 28 Jul, 2014 1 commit
    • Soby Mathew's avatar
      Parametrize baudrate and UART clock during console_init() · 462c8350
      Soby Mathew authored
      This patch adds baud rate and UART clock frequency as parameters
      to the pl011 driver api console_init(). This allows each platform
      to specify UART clock and baud rate according to their specific
      hardware implementation.
      
      Fixes ARM-software/tf-issues#215
      
      Change-Id: Id13eef70a1c530e709b34dd1e6eb84db0797ced2
      462c8350
  32. 01 Jul, 2014 1 commit
    • Sandrine Bailleux's avatar
      Remove concept of top/bottom image loading · 8f55dfb4
      Sandrine Bailleux authored
      This concept is no longer required since we now support loading of
      images at fixed addresses only.
      
      The image loader now automatically detects the position of the image
      inside the current memory layout and updates the layout such that
      memory fragmentation is minimised.
      
      The 'attr' field of the meminfo data structure, which used to hold
      the bottom/top loading information, has been removed. Also the 'next'
      field has been removed as it wasn't used anywhere.
      
      The 'init_bl2_mem_layout()' function has been moved out of common
      code and put in BL1-specific code. It has also been renamed into
      'bl1_init_bl2_mem_layout'.
      
      Fixes ARM-software/tf-issues#109
      
      Change-Id: I3f54642ce7b763d5ee3b047ad0ab59eabbcf916d
      8f55dfb4
  33. 24 Jun, 2014 2 commits
  34. 05 Jun, 2014 1 commit
  35. 29 May, 2014 1 commit
    • Andrew Thoelke's avatar
      Allow platform parameter X1 to be passed to BL3-1 · 03462671
      Andrew Thoelke authored
      bl2_main() was overwriting any platform set X1 parameter for BL3-1
      with the value zero.
      
      This patch ensure that any platform set value is correctly passed
      to BL3-1. The FVP port adds a check to verify this parameter is
      being passed correctly.
      
      Fixes ARM-software/tf-issues#173
      
      Change-Id: Ifbcda73d3d41d2b04a4baf5614e9d2d21f1717c8
      03462671
  36. 23 May, 2014 1 commit
    • Dan Handley's avatar
      Rename FVP specific files and functions · 17a387ad
      Dan Handley authored
      FVP specific files and functions containing the word "plat" have been
      renamed to use the word "fvp" to distinguish them from the common
      platform functionality and porting functions.
      
      Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d
      17a387ad