1. 12 Mar, 2020 1 commit
    • Madhukar Pappireddy's avatar
      plat/arm/fvp: populate pwr domain descriptor dynamically · 6138ffbc
      Madhukar Pappireddy authored
      
      
      The motivation behind this patch and following patches is to extract
      information about the platform in runtime rather than depending on
      compile time macros such as FVP_CLUSTER_COUNT. This partially enables
      us to use a single binary for a family of platforms which all have
      similar hardware capabilities but differ in configurations.
      
      we populate the data structure describing the power domain hierarchy
      of the platform dynamically by querying the number of clusters and cpus
      using fconf getter APIs. Compile time macro such as FVP_CLUSTER_COUNT
      is still needed as it determines the size of related data structures.
      
      Note that the cpu-map node in HW_CONFIG dts represents a logical
      hierarchy of power domains of CPU. However, in reality, the power
      domains may not have been physically built in such hierarchy.
      
      Change-Id: Ibcbb5ca7b2c969f8ad03ab2eab289725245af7a9
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      6138ffbc
  2. 11 Mar, 2020 2 commits
    • Madhukar Pappireddy's avatar
      fconf: Extract topology node properties from HW_CONFIG dtb · 4682461d
      Madhukar Pappireddy authored
      
      
      Create, register( and implicitly invoke) fconf_populate_topology()
      function which extracts the topology related properties from dtb into
      the newly created fconf based configuration structure 'soc_topology'.
      Appropriate libfdt APIs are added to jmptbl.i file for use with USE_ROMLIB
      build feature.
      
      A new property which describes the power domain levels is added to the
      HW_CONFIG device tree source files.
      
      This patch also fixes a minor bug in the common device tree file
      fvp-base-gicv3-psci-dynamiq-common.dtsi
      As this file includes fvp-base-gicv3-psci-common.dtsi, it is necessary
      to delete all previous cluster node definitons because DynamIQ based
      models have upto 8 CPUs in each cluster. If not deleted, the final dts
      would have an inaccurate description of SoC topology, i.e., cluster0
      with 8 or more core nodes and cluster1 with 4 core nodes.
      
      Change-Id: I9eb406da3ba4732008a66c01afec7c9fa8ef59bf
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      4682461d
    • Madhukar Pappireddy's avatar
      fconf: necessary modifications to support fconf in BL31 & SP_MIN · 26d1e0c3
      Madhukar Pappireddy authored
      
      
      Necessary infrastructure added to integrate fconf framework in BL31 & SP_MIN.
      Created few populator() functions which parse HW_CONFIG device tree
      and registered them with fconf framework. Many of the changes are
      only applicable for fvp platform.
      
      This patch:
      1. Adds necessary symbols and sections in BL31, SP_MIN linker script
      2. Adds necessary memory map entry for translation in BL31, SP_MIN
      3. Creates an abstraction layer for hardware configuration based on
         fconf framework
      4. Adds necessary changes to build flow (makefiles)
      5. Minimal callback to read hw_config dtb for capturing properties
         related to GIC(interrupt-controller node)
      6. updates the fconf documentation
      
      Change-Id: Ib6292071f674ef093962b9e8ba0d322b7bf919af
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      26d1e0c3
  3. 10 Mar, 2020 1 commit
  4. 03 Mar, 2020 2 commits
  5. 25 Feb, 2020 1 commit
    • Alexei Fedorov's avatar
      FVP: Fix incorrect GIC mapping · b3c431f3
      Alexei Fedorov authored
      
      
      This patch fixes incorrect setting for DEVICE1_SIZE
      for FVP platforms with more than 8 PEs.
      The current value of 0x200000 supports only 8 PEs
      and causes exception for FVP platforms with the greater
      number of PEs, e.g. FVP_Base_Cortex_A65AEx8 with 16 PEs
      in one cluster.
      
      Change-Id: Ie6391509fe6eeafb8ba779303636cd762e7d21b2
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      b3c431f3
  6. 24 Feb, 2020 2 commits
    • Petre-Ionut Tudor's avatar
      Read-only xlat tables for BL31 memory · 60e8f3cf
      Petre-Ionut Tudor authored
      
      
      This patch introduces a build flag which allows the xlat tables
      to be mapped in a read-only region within BL31 memory. It makes it
      much harder for someone who has acquired the ability to write to
      arbitrary secure memory addresses to gain control of the
      translation tables.
      
      The memory attributes of the descriptors describing the tables
      themselves are changed to read-only secure data. This change
      happens at the end of BL31 runtime setup. Until this point, the
      tables have read-write permissions. This gives a window of
      opportunity for changes to be made to the tables with the MMU on
      (e.g. reclaiming init code). No changes can be made to the tables
      with the MMU turned on from this point onwards. This change is also
      enabled for sp_min and tspd.
      
      To make all this possible, the base table was moved to .rodata. The
      penalty we pay is that now .rodata must be aligned to the size of
      the base table (512B alignment). Still, this is better than putting
      the base table with the higher level tables in the xlat_table
      section, as that would cost us a full 4KB page.
      
      Changing the tables from read-write to read-only cannot be done with
      the MMU on, as the break-before-make sequence would invalidate the
      descriptor which resolves the level 3 page table where that very
      descriptor is located. This would make the translation required for
      writing the changes impossible, generating an MMU fault.
      
      The caches are also flushed.
      Signed-off-by: default avatarPetre-Ionut Tudor <petre-ionut.tudor@arm.com>
      Change-Id: Ibe5de307e6dc94c67d6186139ac3973516430466
      60e8f3cf
    • Sandrine Bailleux's avatar
      plat/arm: Pass cookie argument down to arm_get_rotpk_info() · 88005701
      Sandrine Bailleux authored
      
      
      The cookie will be leveraged in the next commit.
      
      Change-Id: Ie8bad275d856d84c27466461cf815529dd860446
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      88005701
  7. 19 Feb, 2020 1 commit
  8. 18 Feb, 2020 3 commits
    • Jimmy Brisson's avatar
      Add Matterhorn CPU lib · da3b47e9
      Jimmy Brisson authored
      
      
      Also update copyright statements
      
      Change-Id: Iba0305522ac0f2ddc4da99127fd773f340e67300
      Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      da3b47e9
    • Jimmy Brisson's avatar
      Add CPULib for Klein Core · f4744720
      Jimmy Brisson authored
      
      
      Change-Id: I686fd623b8264c85434853a2a26ecd71e9eeac01
      Signed-off-by: default avatarJimmy Brisson <jimmy.brisson@arm.com>
      f4744720
    • Alexei Fedorov's avatar
      FVP: Fix BL31 load address and image size for RESET_TO_BL31=1 · 6227cca9
      Alexei Fedorov authored
      
      
      When TF-A is built with RESET_TO_BL31=1 option, BL31 is the
      first image to be run and should have all the memory allocated
      to it except for the memory reserved for Shared RAM at the start
      of Trusted SRAM.
      This patch fixes FVP BL31 load address and its image size for
      RESET_TO_BL31=1 option. BL31 startup address should be set to
      0x400_1000 and its maximum image size to the size of Trusted SRAM
      minus the first 4KB of shared memory.
      Loading BL31 at 0x0402_0000 as it is currently stated in
      '\docs\plat\arm\fvp\index.rst' causes EL3 exception when the
      image size gets increased (i.e. building with LOG_LEVEL=50)
      but doesn't exceed 0x3B000 not causing build error.
      
      Change-Id: Ie450baaf247f1577112f8d143b24e76c39d33e91
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      6227cca9
  9. 10 Feb, 2020 2 commits
  10. 07 Feb, 2020 3 commits
    • Louis Mayencourt's avatar
      arm-io: Panic in case of io setup failure · 97399821
      Louis Mayencourt authored
      
      
      Currently, an IO setup failure will be ignored on arm platform release
      build. Change this to panic instead.
      
      Change-Id: I027a045bce2422b0a0fc4ff9e9d4c6e7bf5d2f98
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      97399821
    • 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 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
  11. 06 Feb, 2020 2 commits
    • 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
    • Louis Mayencourt's avatar
      fvp: Slightly Bump the stack size for bl1 and bl2 · 64271c74
      Louis Mayencourt authored
      
      
      Stack usage reaches 90% with some configuration. Bump slightly the stack
      size to prevent a stack-overflow.
      
      Change-Id: I44ce8b12906586a42f152b7677785fcdc5e78ae1
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      64271c74
  12. 04 Feb, 2020 1 commit
  13. 03 Feb, 2020 1 commit
  14. 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
  15. 07 Jan, 2020 1 commit
  16. 20 Dec, 2019 3 commits
    • 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
  17. 18 Dec, 2019 1 commit
  18. 09 Dec, 2019 1 commit
  19. 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
  20. 15 Nov, 2019 1 commit
  21. 07 Nov, 2019 1 commit
  22. 03 Oct, 2019 1 commit
  23. 02 Oct, 2019 1 commit
  24. 30 Sep, 2019 1 commit
  25. 26 Sep, 2019 1 commit
  26. 25 Sep, 2019 1 commit
    • Sandrine Bailleux's avatar
      FVP: Fix plat_set_nv_ctr() function · bd363d35
      Sandrine Bailleux authored
      The Fast Models provide a non-volatile counter component, which is used
      in the Trusted Board Boot implementation to protect against rollback
      attacks.
      
      This component comes in 2 versions (see [1]).
      
      - Version 0 is the default and models a locked non-volatile counter,
        whose value is fixed.
      
      - Version 1 of the counter may be incremented in a monotonic fashion.
      
      plat_set_nv_ctr() must cope with both versions. This is achieved by:
      1) Attempting to write the new value in the counter.
      2) Reading the value back.
      3) If there is a mismatch, we know the counter upgrade failed.
      
      When using version 0 of the counter, no upgrade is possible so the
      function is expected to fail all the time. However, the code is
      missing a compiler barrier between the write operation and the next
      read. Thus, the compiler may optimize and remove the read operation on
      the basis that the counter value has not changed. With the default
      optimization level used in TF-A (-Os), this is what's happening.
      
      The fix introduced in this patch marks the write and subsequent read
      accesses to the counter as volatile, such that the compiler makes no
      assumption about the value of the counter.
      
      Note that the comment above plat_set_nv_ctr() was clearly stating
      that when using the read-only version of the non-volatile counter,
      "we expect the values in the certificates to always match the RO
      values so that this function is never called". However, the fact that
      the counter value was read back seems to contradict this comment, as
      it is implementing a counter-measure against misuse of the
      function. The comment has been reworded to avoid any confusion.
      
      Without this patch, this bug may be demonstrated on the Base AEM FVP:
      - Using version 0 of the non-volatile counter (default version).
      - With certificates embedding a revision number value of 32
        (compiling TF-A with TFW_NVCTR_VAL=32).
      
      In this configuration, the non-volatile counter is tied to value 31 by
      default. When BL1 loads the Trusted Boot Firmware certificate, it
      notices that the two values do not match and tries to upgrade the
      non-volatile counter. This write operation is expected to fail
      (because the counter is locked) and the function is expected to return
      an error but it succeeds instead.
      
      As a result, the trusted boot does not abort as soon as it should and
      incorrectly boots BL2. The boot is finally aborted when BL2 verifies
      the BL31 image and figures out that the version of the SoC Firmware
      Key Certificate does not match. On Arm platforms, only certificates
      signed with the Root-of-Trust Key may trigger an upgrade of the
      non-volatile Trusted counter.
      
      [1] https://developer.arm.com/docs/100964/1160/fast-models-components/peripheral-components/nonvolatilecounter
      
      
      
      Change-Id: I9979f29c23b47b338b9b484013d1fb86c59db92f
      Signed-off-by: default avatarSandrine Bailleux <sandrine.bailleux@arm.com>
      bd363d35
  27. 11 Sep, 2019 1 commit
    • John Tsichritzis's avatar
      Modify FVP makefile for cores that support both AArch64/32 · cd3c5b4c
      John Tsichritzis authored
      
      
      Some cores support only AArch64 from EL1 and above, e.g. A76, N1 etc. If
      TF-A is compiled with CTX_INCLUDE_AARCH32_REGS=0 so as to properly
      handle those cores, only the AArch64 cores' assembly is included in the
      TF-A binary. In other words, for FVP, TF-A assumes that AArch64 only
      cores will never exist in the same cluster with cores that also support
      AArch32.
      
      However, A55 and A75 can be used as AArch64 only cores, despite
      supporting AArch32, too. This patch enables A55 and A75 to exist in
      clusters together with AArch64 cores.
      
      Change-Id: I58750ad6c3d76ce77eb354784c2a42f2c179031d
      Signed-off-by: default avatarJohn Tsichritzis <john.tsichritzis@arm.com>
      cd3c5b4c
  28. 16 Aug, 2019 1 commit
    • Alexei Fedorov's avatar
      FVP: Add Delay Timer driver to BL1 and BL31 · 1b597c22
      Alexei Fedorov authored
      
      
      SMMUv3 driver functions which are called from BL1 and BL31
      currently use counter-based poll method for testing status
      bits. Adding Delay Timer driver to BL1 and BL31 is required
      for timeout-based implementation using timer delay functions
      for SMMU and other drivers.
      This patch adds new function `fvp_timer_init()` which
      initialises either System level generic or SP804 timer based on
      FVP_USE_SP804_TIMER build flag.
      In BL2U `bl2u_early_platform_setup()` function the call to
      `arm_bl2u_early_platform_setup()` (which calls
      `generic_delay_timer_init()` ignoring FVP_USE_SP804_TIMER flag),
      is replaced with `arm_console_boot_init()` and `fvp_timer_init()`.
      
      Change-Id: Ifd8dcebf4019e877b9bc5641551deef77a44c0d1
      Signed-off-by: default avatarAlexei Fedorov <Alexei.Fedorov@arm.com>
      1b597c22