1. 03 May, 2017 1 commit
  2. 12 May, 2016 1 commit
  3. 27 Apr, 2016 1 commit
    • Haojian Zhuang's avatar
      IO: support block device type · 9da7a653
      Haojian Zhuang authored
      
      
      FIP is accessed as memory-mapped type. eMMC is block device type.
      In order to support FIP based on eMMC, add the new io_block layer.
      
      io_block always access eMMC device as block size. And it'll only
      copy the required data into buffer in io_block driver. So preparing
      an temporary buffer is required.
      
      When use io_block device, MAX_IO_BLOCK_DEVICES should be declared
      in platform_def.h. It's used to support multiple block devices.
      Signed-off-by: default avatarHaojian Zhuang <haojian.zhuang@linaro.org>
      9da7a653
  4. 02 Nov, 2015 1 commit
    • Juan Castillo's avatar
      Remove deprecated IO return definitions · e098e244
      Juan Castillo authored
      Patch 7e26fe1f deprecates IO specific return definitions in favour
      of standard errno codes. This patch removes those definitions
      and its usage from the IO framework, IO drivers and IO platform
      layer. Following this patch, standard errno codes must be used
      when checking the return value of an IO function.
      
      Change-Id: Id6e0e9d0a7daf15a81ec598cf74de83d5768650f
      e098e244
  5. 23 Oct, 2015 1 commit
    • Juan Castillo's avatar
      IO Framework: use standard errno codes as return values · 7e26fe1f
      Juan Castillo authored
      This patch redefines the values of IO_FAIL, IO_NOT_SUPPORTED and
      IO_RESOURCES_EXHAUSTED to match the corresponding definitions in
      errno.h:
      
          #define IO_FAIL                     (-ENOENT)
          #define IO_NOT_SUPPORTED            (-ENODEV)
          #define IO_RESOURCES_EXHAUSTED      (-ENOMEM)
      
      NOTE: please note that the IO_FAIL, IO_NOT_SUPPORTED and
      IO_RESOURCES_EXHAUSTED definitions are considered deprecated
      and their usage should be avoided. Callers should rely on errno.h
      definitions when checking the return values of IO functions.
      
      Change-Id: Ic8491aa43384b6ee44951ebfc053a3ded16a80be
      7e26fe1f
  6. 25 Jun, 2015 1 commit
    • Juan Castillo's avatar
      Use numbers to identify images instead of names · 16948ae1
      Juan Castillo authored
      The Trusted firmware code identifies BL images by name. The platform
      port defines a name for each image e.g. the IO framework uses this
      mechanism in the platform function plat_get_image_source(). For
      a given image name, it returns the handle to the image file which
      involves comparing images names. In addition, if the image is
      packaged in a FIP, a name comparison is required to find the UUID
      for the image. This method is not optimal.
      
      This patch changes the interface between the generic and platform
      code with regard to identifying images. The platform port must now
      allocate a unique number (ID) for every image. The generic code will
      use the image ID instead of the name to access its attributes.
      
      As a result, the plat_get_image_source() function now takes an image
      ID as an input parameter. The organisation of data structures within
      the IO framework has been rationalised to use an image ID as an index
      into an array which contains attributes of the image such as UUID and
      name. This prevents the name comparisons.
      
      A new type 'io_uuid_spec_t' has been introduced in the IO framework
      to specify images identified by UUID (i.e. when the image is contained
      in a FIP file). There is no longer need to maintain a look-up table
      [iname_name --> uuid] in the io_fip driver code.
      
      Because image names are no longer mandatory in the platform port, the
      debug messages in the generic code will show the image identifier
      instead of the file name. The platforms that support semihosting to
      load images (i.e. FVP) must provide the file names as definitions
      private to the platform.
      
      The ARM platform ports and documentation have been updated accordingly.
      All ARM platforms reuse the image IDs defined in the platform common
      code. These IDs will be used to access other attributes of an image in
      subsequent patches.
      
      IMPORTANT: applying this patch breaks compatibility for platforms that
      use TF BL1 or BL2 images or the image loading code. The platform port
      must be updated to match the new interface.
      
      Change-Id: I9c1b04cb1a0684c6ee65dee66146dd6731751ea5
      16948ae1
  7. 14 Aug, 2014 1 commit
    • Dan Handley's avatar
      Move IO storage source to drivers directory · 935db693
      Dan Handley authored
      Move the remaining IO storage source file (io_storage.c) from the
      lib to the drivers directory. This requires that platform ports
      explicitly add this file to the list of source files.
      
      Also move the IO header files to a new sub-directory, include/io.
      
      Change-Id: I862b1252a796b3bcac0d93e50b11e7fb2ded93d6
      935db693
  8. 06 May, 2014 4 commits
    • Dan Handley's avatar
      Remove variables from .data section · 625de1d4
      Dan Handley authored
      Update code base to remove variables from the .data section,
      mainly by using const static data where possible and adding
      the const specifier as required. Most changes are to the IO
      subsystem, including the framework APIs. The FVP power
      management code is also affected.
      
      Delay initialization of the global static variable,
      next_image_type in bl31_main.c, until it is realy needed.
      Doing this moves the variable from the .data to the .bss
      section.
      
      Also review the IO interface for inconsistencies, using
      uintptr_t where possible instead of void *. Remove the
      io_handle and io_dev_handle typedefs, which were
      unnecessary, replacing instances with uintptr_t.
      
      Fixes ARM-software/tf-issues#107.
      
      Change-Id: I085a62197c82410b566e4698e5590063563ed304
      625de1d4
    • Dan Handley's avatar
      Reduce deep nesting of header files · 97043ac9
      Dan Handley authored
      Reduce the number of header files included from other header
      files as much as possible without splitting the files. Use forward
      declarations where possible. This allows removal of some unnecessary
      "#ifndef __ASSEMBLY__" statements.
      
      Also, review the .c and .S files for which header files really need
      including and reorder the #include statements alphabetically.
      
      Fixes ARM-software/tf-issues#31
      
      Change-Id: Iec92fb976334c77453e010b60bcf56f3be72bd3e
      97043ac9
    • Dan Handley's avatar
      Always use named structs in header files · fb037bfb
      Dan Handley authored
      Add tag names to all unnamed structs in header files. This
      allows forward declaration of structs, which is necessary to
      reduce header file nesting (to be implemented in a subsequent
      commit).
      
      Also change the typedef names across the codebase to use the _t
      suffix to be more conformant with the Linux coding style. The
      coding style actually prefers us not to use typedefs at all but
      this is considered a step too far for Trusted Firmware.
      
      Also change the IO framework structs defintions to use typedef'd
      structs to be consistent with the rest of the codebase.
      
      Change-Id: I722b2c86fc0d92e4da3b15e5cab20373dd26786f
      fb037bfb
    • Dan Handley's avatar
      Move include and source files to logical locations · 4ecca339
      Dan Handley authored
      Move almost all system include files to a logical sub-directory
      under ./include. The only remaining system include directories
      not under ./include are specific to the platform. Move the
      corresponding source files to match the include directory
      structure.
      
      Also remove pm.h as it is no longer used.
      
      Change-Id: Ie5ea6368ec5fad459f3e8a802ad129135527f0b3
      4ecca339
  9. 17 Feb, 2014 3 commits
    • Harry Liebel's avatar
      Add Firmware Image Package (FIP) driver · 561cd33e
      Harry Liebel authored
      The Firmware Image Package (FIP) driver allows for data to be loaded
      from a FIP on platform storage. The FVP supports loading bootloader
      images from a FIP located in NOR FLASH.
      
      The implemented FVP policy states that bootloader images will be
      loaded from a FIP in NOR FLASH if available and fall back to loading
      individual images from semi-hosting.
      
      NOTE:
      - BL3-3(e.g. UEFI) is loaded into DRAM and needs to be configured
        to run from the BL33_BASE address. This is currently set to
        DRAM_BASE+128MB for the FVP.
      
      Change-Id: I2e4821748e3376b5f9e467cf3ec09509e43579a0
      561cd33e
    • James Morrissey's avatar
      Implement load_image in terms of IO abstraction · 9d72b4ea
      James Morrissey authored
      The modified implementation uses the IO abstraction rather than
      making direct semi-hosting calls.  The semi-hosting driver is now
      registered for the FVP platform during initialisation of each boot
      stage where it is used.  Additionally, the FVP platform includes a
      straightforward implementation of 'plat_get_image_source' which
      provides a generic means for the 'load_image' function to determine
      how to access the image data.
      
      Change-Id: Ia34457b471dbee990c7b3c79de7aee4ceea51aa6
      9d72b4ea
    • James Morrissey's avatar
      Add IO abstraction framework · f2f9bb5e
      James Morrissey authored
      This is intended primarily for use as a storage abstraction.
      It allows operations such as image-loading to be implemented
      in a platform-independent fashion.  Each platform registers
      a set of IO drivers during initialisation.  The platform must
      also provide a function that will return a device and a specifier
      that can be used to access specified content.
      
      Clients of the API will primarily use device and entity handles.
      The term "entity" is deliberately vague, to allow for different
      representations of content accessed using different types of
      specifier, but will often be interpreted as a "file" where the
      specifier will normally be its path.
      
      This commit builds, but is intended to be paired with a sample
      implementation of "load_image" using a semi-hosting driver on FVP.
      
      Change-Id: Id3b52f1c0eb9ce76b44b99fc6b6460803668cc86
      f2f9bb5e