Skip to content

GitLab

Switch branch/tag
  1. 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
  5. 06 Mar, 2020 4 commits
  7. 05 Mar, 2020 2 commits
  9. 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
  11. 03 Mar, 2020 4 commits
  13. 27 Feb, 2020 2 commits
  15. 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
  17. 25 Feb, 2020 13 commits