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 3 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
    • Madhukar Pappireddy's avatar
      fconf: enhancements to firmware configuration framework · 25d740c4
      Madhukar Pappireddy authored
      
      
      A populate() function essentially captures the value of a property,
      defined by a platform, into a fconf related c structure. Such a
      callback is usually platform specific and is associated to a specific
      configuration source.
      For example, a populate() function which captures the hardware topology
      of the platform can only parse HW_CONFIG DTB. Hence each populator
      function must be registered with a specific 'config_type' identifier.
      It broadly represents a logical grouping of configuration properties
      which is usually a device tree source file.
      
      Example:
      > TB_FW: properties related to trusted firmware such as IO policies,
      	 base address of other DTBs, mbedtls heap info etc.
      > HW_CONFIG: properties related to hardware configuration of the SoC
      	 such as topology, GIC controller, PSCI hooks, CPU ID etc.
      
      This patch modifies FCONF_REGISTER_POPULATOR macro and fconf_populate()
      to register and invoke the appropriate callbacks selectively based on
      configuration type.
      
      Change-Id: I6f63b1fd7a8729c6c9137d5b63270af1857bb44a
      Signed-off-by: default avatarMadhukar Pappireddy <madhukar.pappireddy@arm.com>
      25d740c4
  3. 09 Mar, 2020 10 commits
  4. 06 Mar, 2020 4 commits
  5. 05 Mar, 2020 2 commits
  6. 04 Mar, 2020 1 commit
    • Manish Pandey's avatar
      SPMD: loading Secure Partition payloads · cb3b5344
      Manish Pandey authored
      
      
      This patch implements loading of Secure Partition packages using
      existing framework of loading other bl images.
      
      The current framework uses a statically defined array to store all the
      possible image types and at run time generates a link list and traverse
      through it to load different images.
      
      To load SPs, a new array of fixed size is introduced which will be
      dynamically populated based on number of SPs available in the system
      and it will be appended to the loadable images list.
      
      Change-Id: I8309f63595f2a71b28a73b922d20ccba9c4f6ae4
      Signed-off-by: default avatarManish Pandey <manish.pandey2@arm.com>
      cb3b5344
  7. 03 Mar, 2020 4 commits
  8. 27 Feb, 2020 2 commits
  9. 26 Feb, 2020 1 commit
    • Masahiro Yamada's avatar
      uniphier: prepare uniphier_soc_info() for next SoC · dd53cfe1
      Masahiro Yamada authored
      
      
      The revision register address will be changed in the next SoC.
      
      The LSI revision is needed in order to know where the revision
      register is located, but you need to read out the revision
      register for that. This is impossible.
      
      We need to know the revision register address by other means.
      Use BL_CODE_BASE, where the base address of the TF image that is
      currently running. If it is bigger than 0x80000000 (i.e. the DRAM
      base is 0x80000000), we assume it is a legacy SoC.
      
      Change-Id: I9d7f4325fe2085a8a1ab5310025e5948da611256
      Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      dd53cfe1
  10. 25 Feb, 2020 12 commits