1. 21 Jul, 2020 1 commit
  2. 25 Jun, 2020 1 commit
    • Manish V Badarkhe's avatar
      plat/arm: Load and populate fw_config and tb_fw_config · 82869675
      Manish V Badarkhe authored
      
      
      Modified the code to do below changes:
      
      1. Load tb_fw_config along with fw_config by BL1.
      2. Populate fw_config device tree information in the
         BL1 to load tb_fw_config.
      3. In BL2, populate fw_config information to retrieve
         the address of tb_fw_config and then tb_fw_config
         gets populated using retrieved address.
      4. Avoid processing of configuration file in case of error
         value returned from "fw_config_load" function.
      5. Updated entrypoint information for BL2 image so
         that it's arg0 should point to fw_config address.
      Signed-off-by: default avatarManish V Badarkhe <Manish.Badarkhe@arm.com>
      Signed-off-by: default avatarLouis Mayencourt <louis.mayencourt@arm.com>
      Change-Id: Ife6f7b673a074e7f544ee3d1bda7645fd5b2886c
      82869675
  3. 24 Jun, 2020 2 commits
  4. 30 Apr, 2020 1 commit
  5. 29 Apr, 2020 1 commit
    • Andre Przywara's avatar
      fdt/wrappers: Replace fdtw_read_cells() implementation · ff4e6c35
      Andre Przywara authored
      Our fdtw_read_cells() implementation goes to great lengths to
      sanity-check every parameter and result, but leaves a big hole open:
      The size of the storage the value pointer points at needs to match the
      number of cells given. This can't be easily checked at compile time,
      since we lose the size information by using a void pointer.
      Regardless the current usage of this function is somewhat wrong anyways,
      since we use it on single-element, fixed-length properties only, for
      which the DT binding specifies the size.
      Typically we use those functions dealing with a number of cells in DT
      context to deal with *dynamically* sized properties, which depend on
      other properties (#size-cells, #clock-cells, ...), to specify the number
      of cells needed.
      
      Another problem with the current implementation is the use of
      ambiguously sized types (uintptr_t, size_t) together with a certain
      expectation about their size. In general there is no relation between
      the length of a DT property and the bitness of the code that parses the
      DTB: AArch64 code could encounter 32-bit addresses (where the physical
      address space is limited to 4GB [1]), while AArch32 code could read
      64-bit sized properties (/memory nodes on LPAE systems, [2]).
      
      To make this more clear, fix the potential issues and also align more
      with other DT users (Linux and U-Boot), introduce functions to explicitly
      read uint32 and uint64 properties. As the other DT consumers, we do this
      based on the generic "read array" function.
      Convert all users to use either of those two new functions, and make
      sure we never use a pointer to anything other than uint32_t or uint64_t
      variables directly.
      
      This reveals (and fixes) a bug in plat_spmd_manifest.c, where we write
      4 bytes into a uint16_t variable (passed via a void pointer).
      
      Also we change the implementation of the function to better align with
      other libfdt users, by using the right types (fdt32_t) and common
      variable names (*prop, prop_names).
      
      [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi#n874
      [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/ecx-2000.dts
      
      
      
      Change-Id: I718de960515117ac7a3331a1b177d2ec224a3890
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      ff4e6c35
  6. 11 Mar, 2020 1 commit
    • 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
  7. 07 Feb, 2020 1 commit
    • 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