doc: Complete the storage abstraction layer doc
Add uml sequence and class diagram to illustrate the behavior of the
storage abstraction layer.
Change-Id: I338262729f8034cc3d3eea1d0ce19cca973a91bb
Signed-off-by: Louis Mayencourt <louis.mayencourt@arm.com>
diff --git a/docs/getting_started/porting-guide.rst b/docs/getting_started/porting-guide.rst
index 72865a5..b327f6e 100644
--- a/docs/getting_started/porting-guide.rst
+++ b/docs/getting_started/porting-guide.rst
@@ -2762,14 +2762,12 @@
Storage abstraction layer
-------------------------
-In order to improve platform independence and portability an storage abstraction
-layer is used to load data from non-volatile platform storage.
+In order to improve platform independence and portability a storage abstraction
+layer is used to load data from non-volatile platform storage. Currently
+storage access is only required by BL1 and BL2 phases and performed inside the
+``load_image()`` function in ``bl_common.c``.
-Each platform should register devices and their drivers via the Storage layer.
-These drivers then need to be initialized by bootloader phases as
-required in their respective ``blx_platform_setup()`` functions. Currently
-storage access is only required by BL1 and BL2 phases. The ``load_image()``
-function uses the storage layer to access non-volatile platform storage.
+.. uml:: ../resources/diagrams/plantuml/io_framework_usage_overview.puml
It is mandatory to implement at least one storage driver. For the Arm
development platforms the Firmware Image Package (FIP) driver is provided as
@@ -2779,13 +2777,25 @@
is in ``drivers/io/io_storage.c`` and the driver files are located in
``drivers/io/``.
+.. uml:: ../resources/diagrams/plantuml/io_arm_class_diagram.puml
+
Each IO driver must provide ``io_dev_*`` structures, as described in
``drivers/io/io_driver.h``. These are returned via a mandatory registration
function that is called on platform initialization. The semi-hosting driver
implementation in ``io_semihosting.c`` can be used as an example.
+Each platform should register devices and their drivers via the storage
+abstraction layer. These drivers then need to be initialized by bootloader
+phases as required in their respective ``blx_platform_setup()`` functions.
+
+.. uml:: ../resources/diagrams/plantuml/io_dev_registration.puml
+
+The storage abstraction layer provides mechanisms (``io_dev_init()``) to
+initialize storage devices before IO operations are called.
+
+.. uml:: ../resources/diagrams/plantuml/io_dev_init_and_check.puml
+
-The Storage layer provides mechanisms to initialize storage devices before
-IO operations are called. The basic operations supported by the layer
+The basic operations supported by the layer
include ``open()``, ``close()``, ``read()``, ``write()``, ``size()`` and ``seek()``.
Drivers do not have to implement all operations, but each platform must
provide at least one driver for a device capable of supporting generic