GitLab

Fixes issues #10:

https://github.com/ARM-software/tf-issues/issues/10



This patch changes all/most variables of type int to be size_t or long
to fix the sizing and alignment problems found when building with the
newer toolchains such as Linaro GCC 13.12 or later.

Change-Id: Idc9d48eb2ff9b8c5bbd5b227e6907263d1ea188b
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>

At present many recoverable failures are reported as errors. This patch
modifies all such failures to be reported as warnings instead.

Change-Id: I5141653c82498defcada9b90fdf7498ba496b2f2

If there is a request to open a file from FIP, and that file is not
found, the driver fails to reset the offset address. This causes
subsequent file loads to fail.

This patch resets the offset address to zero if a file is not found so
that subsequent file loads are unaffected.

Change-Id: I16418e35f92fb7c85fb12e2acc071990520cdef8

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

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

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