1. 24 Jul, 2019 1 commit
    • Julius Werner's avatar
      Factor out cross-BL API into export headers suitable for 3rd party code · 57bf6057
      Julius Werner authored
      
      
      This patch adds a new include/export/ directory meant for inclusion in
      third-party code. This is useful for cases where third-party code needs
      to interact with TF-A interfaces and data structures (such as a custom
      BL2-implementation like coreboot handing off to BL31). Directly
      including headers from the TF-A repository avoids having to duplicate
      all these definitions (and risk them going stale), but with the current
      header structure this is not possible because handoff API definitions
      are too deeply intertwined with other TF code/headers and chain-include
      other headers that will not be available in the other environment.
      
      The new approach aims to solve this by separating only the parts that
      are really needed into these special headers that are self-contained and
      will not chain-include other (non-export) headers. TF-A code should
      never include them directly but should instead always include the
      respective wrapper header, which will include the required prerequisites
      (like <stdint.h>) before including the export header. Third-party code
      can include the export headers via its own wrappers that make sure the
      necessary definitions are available in whatever way that environment can
      provide them.
      
      Change-Id: Ifd769320ba51371439a8e5dd5b79c2516c3b43ab
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      57bf6057
  2. 18 Jul, 2019 1 commit
    • Julius Werner's avatar
      Introduce lightweight BL platform parameter library · b852d229
      Julius Werner authored
      
      
      This patch adds some common helper code to support a lightweight
      platform parameter passing framework between BLs that has already been
      used on Rockchip platforms but is more widely useful to others as well.
      It can be used as an implementation for the SoC firmware configuration
      file mentioned in the docs, and is primarily intended for platforms
      that only require a handful of values to be passed and want to get by
      without a libfdt dependency. Parameters are stored in a linked list and
      the parameter space is split in generic and vendor-specific parameter
      types. Generic types will be handled by this code whereas
      vendor-specific types have to be handled by a vendor-specific handler
      function that gets passed in.
      
      Change-Id: If3413d44e86b99d417294ce8d33eb2fc77a6183f
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      b852d229