Provide a flexible way to avoid loading image in some configurations

[ljerry]

To handle various device storage configurations, be able to skip the loading of some image without introducing many dirty compilation switches in platform setup code is convenient.

• It is the case, for instance, when some images are loaded by debugger and therefore they should not be loaded by embedded BL.
• This is also the case for platform that can either make use of BL2 to access an IP requesting a complex driver (eMMC, NAND and so on) or rely on BL31 (when RESET_TO_BL31 is set) to perform the loadings if it can rely on a simple IO driver (such as IO memmap). Obviously, BL2 is no more needed in the latter configuration. Here, BL31 (platform setup code only) could either be configure to use a "dummy" IO driver or IO memmap.

This way, compilation switches add-ons can be set in platform makefile and *_io_storage.c file (or equivalent) leaving bl31_plat_setup.c untouched by this configuration.

The above mentioned "dummy IO" driver can be seen as a stub responding OK to the existing IO storage framework. A commit will follow to implement this fake driver.

[danh-arm]

There is certainly a use-case for BL2 having flexibility in the images it loads, ideally without having to rebuild the firmware. This is a bit related to #301. Eventually, we would like this (and other) information to be data driven, so that the platform could provide a configuration file to drive BL2 behaviour, perhaps even as part of the FIP.

I'm less sure about your use-case of getting BL31 to do image loading. This is not a true RESET_TO_BL31 use-case, since whatever mechanism loaded BL31 itself, should load these additional images. But that's really a platform specific design issue.

Anyway, a nicely architected solution for this is not coming soon, and your proposed interim solution looks reasonable. If you create a PR to this effect, I see no reason why it can't be merged.

[ljerry]

About BL31 to do image loading, I'm referring to the following paragraphe in firmware-design document chapter "### Using BL3-1 as the CPU reset vector":

In this configuration, the platform's Trusted Boot Firmware must ensure that
BL3-1 is loaded to its runtime address, which must match the CPU's RVBAR reset
vector address, before the application processor is powered on. Additionally,
platform software is responsible for loading the other BL3-x images required and
providing entry point information for them to BL3-1. Loading these images might
be done by the Trusted Boot Firmware or by platform code in BL3-1.

Obviously, in order to keep BL31 small these loadings must rely on basic IO drivers such as memmap.

[danh-arm]

Fair enough on the firmware design quote, although I would still personally discourage adding this functionality to BL31.