1. 07 Feb, 2020 7 commits
    • Louis Mayencourt's avatar
      fconf: Move platform io policies into fconf · 0a6e7e3b
      Louis Mayencourt authored
      
      
      Use the firmware configuration framework to store the io_policies
      information inside the configuration device tree instead of the static
      structure in the code base.
      
      The io_policies required by BL1 can't be inside the dtb, as this one is
      loaded by BL1, and only available at BL2.
      
      This change currently only applies to FVP platform.
      
      Change-Id: Ic9c1ac3931a4a136aa36f7f58f66d3764c1bfca1
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      0a6e7e3b
    • Louis Mayencourt's avatar
      fconf: Add mbedtls shared heap as property · 6c972317
      Louis Mayencourt authored
      
      
      Use the firmware configuration framework in arm dynamic configuration
      to retrieve mbedtls heap information between bl1 and bl2.
      
      For this, a new fconf getter is added to expose the device tree base
      address and size.
      
      Change-Id: Ifa5ac9366ae100e2cdd1f4c8e85fc591b170f4b6
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      6c972317
    • Louis Mayencourt's avatar
      fconf: Add TBBR disable_authentication property · ce852841
      Louis Mayencourt authored
      
      
      Use fconf to retrieve the `disable_authentication` property.
      Move this access from arm dynamic configuration to bl common.
      
      Change-Id: Ibf184a5c6245d04839222f5457cf5e651f252b86
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      ce852841
    • Louis Mayencourt's avatar
      fconf: Add dynamic config DTBs info as property · 25ac8794
      Louis Mayencourt authored
      
      
      This patch introduces a better separation between the trusted-boot
      related properties, and the dynamic configuration DTBs loading
      information.
      
      The dynamic configuration DTBs properties are moved to a new node:
      `dtb-registry`. All the sub-nodes present will be provided to the
      dynamic config framework to be loaded. The node currently only contains
      the already defined configuration DTBs, but can be extended for future
      features if necessary.
      The dynamic config framework is modified to use the abstraction provided
      by the fconf framework, instead of directly accessing the DTBs.
      
      The trusted-boot properties are kept under the "arm,tb_fw" compatible
      string, but in a separate `tb_fw-config` node.
      The `tb_fw-config` property of the `dtb-registry` node simply points
      to the load address of `fw_config`, as the `tb_fw-config` is currently
      part of the same DTB.
      
      Change-Id: Iceb6c4c2cb92b692b6e28dbdc9fb060f1c46de82
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      25ac8794
    • Louis Mayencourt's avatar
      fconf: Populate properties from dtb during bl2 setup · 9814bfc1
      Louis Mayencourt authored
      
      
      Use the dtb provided by bl1 as configuration file for fconf.
      
      Change-Id: I3f466ad9b7047e1a361d94e71ac6d693e31496d9
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      9814bfc1
    • Louis Mayencourt's avatar
      fconf: Load config dtb from bl1 · 3b5ea741
      Louis Mayencourt authored
      
      
      Move the loading of the dtb from arm_dym_cfg to fconf. The new loading
      function is not associated to arm platform anymore, and can be moved
      to bl_main if wanted.
      
      Change-Id: I847d07eaba36d31d9d3ed9eba8e58666ea1ba563
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      3b5ea741
    • Louis Mayencourt's avatar
      fconf: initial commit · ab1981db
      Louis Mayencourt authored
      
      
      Introduce the Firmware CONfiguration Framework (fconf).
      
      The fconf is an abstraction layer for platform specific data, allowing
      a "property" to be queried and a value retrieved without the requesting
      entity knowing what backing store is being used to hold the data.
      
      The default backing store used is C structure. If another backing store
      has to be used, the platform integrator needs to provide a "populate()"
      function to fill the corresponding C structure.
      The "populate()" function must be registered to the fconf framework with
      the "FCONF_REGISTER_POPULATOR()". This ensures that the function would
      be called inside the "fconf_populate()" function.
      
      A two level macro is used as getter:
      - the first macro takes 3 parameters and converts it to a function
        call: FCONF_GET_PROPERTY(a,b,c) -> a__b_getter(c).
      - the second level defines a__b_getter(c) to the matching C structure,
        variable, array, function, etc..
      
      Ex: Get a Chain of trust property:
          1) FCONF_GET_PROPERY(tbbr, cot, BL2_id) -> tbbr__cot_getter(BL2_id)
          2) tbbr__cot_getter(BL2_id) -> cot_desc_ptr[BL2_id]
      
      Change-Id: Id394001353ed295bc680c3f543af0cf8da549469
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      ab1981db
  2. 06 Feb, 2020 1 commit
    • Max Shvetsov's avatar
      Adds option to read ROTPK from registers for FVP · a6ffddec
      Max Shvetsov authored
      
      
      Enables usage of ARM_ROTPK_LOCATION=regs for FVP board.
      Removes hard-coded developer keys. Instead, setting
      ARM_ROTPK_LOCATION=devel_* takes keys from default directory.
      In case of ROT_KEY specified - generates a new hash and replaces the
      original.
      
      Note: Juno board was tested by original feature author and was not tested
      for this patch since we don't have access to the private key. Juno
      implementation was moved to board-specific file without changing
      functionality. It is not known whether byte-swapping is still needed
      for this platform.
      
      Change-Id: I0fdbaca0415cdcd78f3a388551c2e478c01ed986
      Signed-off-by: default avatarMax Shvetsov <maksims.svecovs@arm.com>
      a6ffddec
  3. 04 Feb, 2020 1 commit
  4. 03 Feb, 2020 1 commit
  5. 29 Jan, 2020 1 commit
  6. 28 Jan, 2020 1 commit
  7. 27 Jan, 2020 2 commits
    • Madhukar Pappireddy's avatar
      plat/arm: Add support for SEPARATE_NOBITS_REGION · 0c1f197a
      Madhukar Pappireddy authored
      
      
      In order to support SEPARATE_NOBITS_REGION for Arm platforms, we need to load
      BL31 PROGBITS into secure DRAM space and BL31 NOBITS into SRAM. Hence mandate
      the build to require that ARM_BL31_IN_DRAM is enabled as well.
      
      Naturally with SEPARATE_NOBITS_REGION enabled, the BL31 initialization code
      cannot be reclaimed to be used for runtime data such as secondary cpu stacks.
      
      Memory map for BL31 NOBITS region also has to be created.
      
      Change-Id: Ibbc8c9499a32e63fd0957a6e254608fbf6fa90c9
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      0c1f197a
    • Vijayenthiran Subramaniam's avatar
      plat/arm/sgi: move topology information to board folder · a9fbf13e
      Vijayenthiran Subramaniam authored
      
      
      The platform topology description of the upcoming Arm's RD platforms
      have different topology than those listed in the sgi_topology.c file. So
      instead of adding platform specific topology into existing
      sgi_topology.c file, those can be added to respective board files. In
      order to maintain consistency with the upcoming platforms, move the
      existing platform topology description to respective board files.
      
      Change-Id: I4689c7d24cd0c75a3dc234370c34a85c08598abb
      Signed-off-by: default avatarVijayenthiran Subramaniam <vijayenthiran.subramaniam@arm.com>
      a9fbf13e
  8. 24 Jan, 2020 1 commit
  9. 23 Jan, 2020 1 commit
  10. 22 Jan, 2020 1 commit
    • Madhukar Pappireddy's avatar
      plat/arm: Add support for SEPARATE_NOBITS_REGION · d433bbdd
      Madhukar Pappireddy authored
      
      
      In order to support SEPARATE_NOBITS_REGION for Arm platforms, we need to load
      BL31 PROGBITS into secure DRAM space and BL31 NOBITS into SRAM. Hence mandate
      the build to require that ARM_BL31_IN_DRAM is enabled as well.
      
      Naturally with SEPARATE_NOBITS_REGION enabled, the BL31 initialization code
      cannot be reclaimed to be used for runtime data such as secondary cpu stacks.
      
      Memory map for BL31 NOBITS region also has to be created.
      
      Change-Id: Ibd480f82c1dc74e9cbb54eec07d7a8fecbf25433
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      d433bbdd
  11. 10 Jan, 2020 2 commits
    • Deepika Bhavnani's avatar
      Unify type of "cpu_idx" across PSCI module. · 5b33ad17
      Deepika Bhavnani authored
      
      
      NOTE for platform integrators:
         API `plat_psci_stat_get_residency()` third argument
         `last_cpu_idx` is changed from "signed int" to the
         "unsigned int" type.
      
      Issue / Trouble points
      1. cpu_idx is used as mix of `unsigned int` and `signed int` in code
      with typecasting at some places leading to coverity issues.
      
      2. Underlying platform API's return cpu_idx as `unsigned int`
      and comparison is performed with platform specific defines
      `PLAFORM_xxx` which is not consistent
      
      Misra Rule 10.4:
      The value of a complex expression of integer type may only be cast to
      a type that is narrower and of the same signedness as the underlying
      type of the expression.
      
      Based on above points, cpu_idx is kept as `unsigned int` to match
      the API's and low-level functions and platform defines are updated
      where ever required
      Signed-off-by: default avatarDeepika Bhavnani <deepika.bhavnani@arm.com>
      Change-Id: Ib26fd16e420c35527204b126b9b91e8babcc3a5c
      5b33ad17
    • Alexei Fedorov's avatar
      FVP: Remove re-definition of topology related build options · 94f1c959
      Alexei Fedorov authored
      
      
      This patch removes re-definition of the following FVP build
      options from plat\arm\board\fvp\fvp_def.h:
       'FVP_CLUSTER_COUNT'
       'FVP_MAX_CPUS_PER_CLUSTER'
       'FVP_MAX_PE_PER_CPU'
      which are set in platform.mk.
      
      This fixes a potential problem when a build option set in
      platform.mk file can be re-defined in fvp_def.h header file
      used by other build component with a different makefile which
      does not set this option.
      Ref. GENFW-3505.
      
      Change-Id: I4288629920516acf2c239c7b733f92a0c5a812ff
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      94f1c959
  12. 07 Jan, 2020 3 commits
  13. 03 Jan, 2020 1 commit
    • Vishnu Banavath's avatar
      drivers: add a driver for snoop control unit · c20c0525
      Vishnu Banavath authored
      
      
      The SCU connects one to four Cortex-A5/Cortex-A9 processors
      to the memory system through the AXI interfaces.
      
      The SCU functions are to:
      - maintain data cache coherency between the Cortex-A5/Cortex-A9
        processors
      - initiate L2 AXI memory accesses
      - arbitrate between Cortex-A5/Cortex-A9 processors requesting
        L2 accesses
      - manage ACP accesses.
      
      Snoop Control Unit will enable to snoop on other CPUs caches.
      This is very important when it comes to synchronizing data between
      CPUs. As an example, there is a high chance that data might be
      cache'd and other CPUs can't see the change. In such cases,
      if snoop control unit is enabled, data is synchoronized immediately
      between CPUs and the changes are visible to other CPUs.
      
      This driver provides functionality to enable SCU as well as enabling
      user to know the following
      - number of CPUs present
      - is a particular CPU operating in SMP mode or AMP mode
      - data cache size of a particular CPU
      - does SCU has ACP port
      - is L2CPRESENT
      
      Change-Id: I0d977970154fa60df57caf449200d471f02312a0
      Signed-off-by: default avatarVishnu Banavath <vishnu.banavath@arm.com>
      c20c0525
  14. 20 Dec, 2019 5 commits
    • Paul Beesley's avatar
      spm-mm: Remove mm_svc.h header · 962c44e7
      Paul Beesley authored
      
      
      The contents of this header have been merged into the spm_mm_svc.h
      header file.
      
      Change-Id: I01530b2e4ec1b4c091ce339758025e2216e740a4
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      962c44e7
    • Paul Beesley's avatar
      spm-mm: Refactor spm_svc.h and its contents · 0bf9f567
      Paul Beesley authored
      
      
      Change-Id: I91c192924433226b54d33e57d56d146c1c6df81b
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      0bf9f567
    • Paul Beesley's avatar
      spm-mm: Refactor secure_partition.h and its contents · aeaa225c
      Paul Beesley authored
      
      
      Before adding any new SPM-related components we should first do
      some cleanup around the existing SPM-MM implementation. The aim
      is to make sure that any SPM-MM components have names that clearly
      indicate that they are MM-related. Otherwise, when adding new SPM
      code, it could quickly become confusing as it would be unclear to
      which component the code belongs.
      
      The secure_partition.h header is a clear example of this, as the
      name is generic so it could easily apply to any SPM-related code,
      when it is in fact SPM-MM specific.
      
      This patch renames the file and the two structures defined within
      it, and then modifies any references in files that use the header.
      
      Change-Id: I44bd95fab774c358178b3e81262a16da500fda26
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      aeaa225c
    • Paul Beesley's avatar
      spm: Remove SPM Alpha 1 prototype and support files · 538b0020
      Paul Beesley authored
      
      
      The Secure Partition Manager (SPM) prototype implementation is
      being removed. This is preparatory work for putting in place a
      dispatcher component that, in turn, enables partition managers
      at S-EL2 / S-EL1.
      
      This patch removes:
      
      - The core service files (std_svc/spm)
      - The Resource Descriptor headers (include/services)
      - SPRT protocol support and service definitions
      - SPCI protocol support and service definitions
      
      Change-Id: Iaade6f6422eaf9a71187b1e2a4dffd7fb8766426
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      Signed-off-by: default avatarArtsem Artsemenka <artsem.artsemenka@arm.com>
      538b0020
    • Paul Beesley's avatar
      Remove dependency between SPM_MM and ENABLE_SPM build flags · 3f3c341a
      Paul Beesley authored
      
      
      There are two different implementations of Secure Partition
      management in TF-A. One is based on the "Management Mode" (MM)
      design, the other is based on the Secure Partition Client Interface
      (SPCI) specification. Currently there is a dependency between their
      build flags that shouldn't exist, making further development
      harder than it should be. This patch removes that
      dependency, making the two flags function independently.
      
      Before: ENABLE_SPM=1 is required for using either implementation.
              By default, the SPCI-based implementation is enabled and
              this is overridden if SPM_MM=1.
      
      After: ENABLE_SPM=1 enables the SPCI-based implementation.
             SPM_MM=1 enables the MM-based implementation.
             The two build flags are mutually exclusive.
      
      Note that the name of the ENABLE_SPM flag remains a bit
      ambiguous - this will be improved in a subsequent patch. For this
      patch the intention was to leave the name as-is so that it is
      easier to track the changes that were made.
      
      Change-Id: I8e64ee545d811c7000f27e8dc8ebb977d670608a
      Signed-off-by: default avatarPaul Beesley <paul.beesley@arm.com>
      3f3c341a
  15. 19 Dec, 2019 1 commit
  16. 18 Dec, 2019 1 commit
  17. 17 Dec, 2019 2 commits
  18. 10 Dec, 2019 1 commit
    • Ambroise Vincent's avatar
      arm: gicv3: Fix compiler dependent behavior · d0196911
      Ambroise Vincent authored
      
      
      C99 standard: "What constitutes an access to an object that has
      volatile-qualified type is implementation-defined".
      
      GCC is not considering the cast to void of volatile structures as an
      access and so is not actually issuing reads.
      
      Clang does read those structures by copying them on the stack, which in
      this case creates an overflow because of their large size.
      
      This patch removes the cast to void and instead uses the USED attribute
      to tell the compiler to retain the static variables.
      
      Change-Id: I952b5056e3f6e91841e7ef9558434352710ab80d
      Signed-off-by: default avatarAmbroise Vincent <ambroise.vincent@arm.com>
      	       Zelalem Aweke <zelalem.aweke@arm.com>
      d0196911
  19. 09 Dec, 2019 2 commits
  20. 19 Nov, 2019 1 commit
  21. 18 Nov, 2019 1 commit
    • Louis Mayencourt's avatar
      ROMLIB: Optimize memory layout when ROMLIB is used · e7b39089
      Louis Mayencourt authored
      
      
      ROMLIB extract functions code from BL images to put them inside ROM.
      This has for effect to reduce the size of the BL images.
      
      This patch take this size reduction into consideration to optimize the
      memory layout of BL2.
      A new "PLAT_ARM_BL2_ROMLIB_OPTIMIZATION" macro is defined and used to
      reduce "PLAT_ARM_MAX_BL2_SIZE". This allows to remove the gap between
      BL1 and BL2 when ROMLIB is used and provides more room for BL31.
      
      The current memory gain is 0x6000 for fvp and 0x8000 for juno.
      
      Change-Id: I71c2c2c63b57bce5b22a125efaefc486ff3e87be
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      e7b39089
  22. 15 Nov, 2019 1 commit
  23. 11 Nov, 2019 1 commit
    • Manish Pandey's avatar
      n1sdp: setup multichip gic routing table · 6799a370
      Manish Pandey authored
      
      
      N1SDP supports multichip configuration wherein n1sdp boards are
      connected over high speed coherent CCIX link, for now only dual-chip
      is supported.
      
      Whether or not multiple chips are present is dynamically probed by
      SCP firmware and passed on to TF-A, routing table will be set up
      only if multiple chips are present.
      
      Initialize GIC-600 multichip operation by overriding the default GICR
      frames with array of GICR frames and setting the chip 0 as routing
      table owner.
      
      Change-Id: Ida35672be4bbf4c517469a5b330548d75e593ff2
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      6799a370
  24. 07 Nov, 2019 1 commit