Loading images from BL2

[ruchi393]

Hi,

On our platform we are using BL2 at EL3 and have a use case where some extra firmware images need to be downloaded for initializing certain system components before control is passed to BL31. The only way I could figure out for doing so in TF-A, is by adding some image ID's corresponding to these in the Image ID list , FIP tool and load these images.

Currently we were loading these images in u-boot using the FIT . The FIT header is used to extract information about these images and then load them.

What is the suggested way to do so in TF-A ? Is it acceptable to add such images in FIP layout ?

Regards, Ruchika

[danh-arm]

Yes, this is an expected use-case. It sounds similar to the case of loading the SCP_BL2 image on the Arm Juno reference platform. In that case, the BL2 image ID list is prefixed with an additional SCP_BL2 image, while continuing to specify BL31 as the first image to execute after BL2, using the EP_FIRST_EXE attribute. See the file plat/arm/common/aarch64/arm_bl2_mem_params_desc.c. If you want your additional images to be executed on the AP, then you will need to specify one of those as the EP_FIRST_EXE instead.

On Arm platforms it is necessary to override bl1_plat_handle_post_image_load() to ensure the SCP_BL2 image is transferred to the SCP after it is loaded. See arm_bl2_handle_post_image_load(). This won't be necessary if you are executing your additional images on the AP.

Finally, you might need to use the IMAGE_ATTRIB_PLAT_SETUP attribute to indicate to the BL2 generic code at which point bl2_platform_setup() is called. On Arm platforms this is specified on the BL31 image, so that bl2_platform_setup() occurs after the SCP_BL2 image is loaded and transferred to the SCP.

[ruchi393]

Thanks. In my usecase, these images are some DDR PHY images which need to be loaded to initialize DDR before other images can be loaded on DDR. I would add the required UUID's to do so. Is there any convention being followed when selecting UUID for a new image type ?

Follow up query on FIP IO driver - I would further like to split and create another FIP image which has all these DDR PHY images rather than using a single FIP image which has these images as well as the other BL3x images. Having separate FIP image for these images would provide more flexibility to the developer. In our flow, the DDR driver would be responsible for parsing this FIP image to find the PHY images and taking the necessary actions. These PHY images once programmed would hardly change.

When looking at the io driver framework, I see that current fip implementation only allows a single fip device to exist at a time since it depends on file state and io dev information maintained in some static global data. (current_file and fip_dev_info). To allow the possibility for platforms to use FIP images more flexibly, I plan to add a pool of fip_dev_info and file states in the driver. Platforms can choose to limit this with MAX_FIP_DEVICES they support. I have done a rough PoC for same and in principle it seems to work. I would like to get an opinion if such a change would be acceptable.

[danh-arm]

Is there any convention being followed when selecting UUID for a new image type ?

Just use a uuid generator program (e.g. uuidgen in the util-linux package) to ensure uniqueness.

I would like to get an opinion if such a change would be acceptable

From your description, this sounds reasonable. I guess we'd need to see some code to be sure. I would be slightly concerned about the additional memory required to have multiple FIPs open at the same time.