[U-Boot] [RFC PATCH 04/11] SPL: FIT: allow loading multiple images

[Kever Yang]

Hi Andre,

On 01/22/2017 06:58 PM, André Przywara wrote:
> On 22/01/17 07:08, Kever Yang wrote:
>> Hi Andre,
>>
>>      Thanks for your patches, this is great help for enable ATF on U-Boot
>> SPL.
>> For ATF use case, we would like to identify which one is bl31 for we
>> need to
>> get entry point for it while we only need load address for other image.
>> Any idea on get this information from different "loadables"?
> So I thought this use case is covered by the current scheme?
>
> See below ...
>
>> On 01/20/2017 09:53 AM, Andre Przywara wrote:
>>> So far we were not using the FIT image format to its full potential:
>>> The SPL FIT loader was just loading the first image from the /images
>>> node plus one of the listed DTBs.
>>> Now with the refactored loader code it's easy to load an arbitrary
>>> number of images in addition to the two mentioned above.
>>> As described in the FIT image source file format description, iterate
>>> over all images listed at the "loadables" property in the configuration
>>> node and load every image at its desired location.
>>> This allows to load any kind of images:
>>> - firmware images to execute before U-Boot proper (for instance
>>>     ARM Trusted Firmware (ATF))
>>> - firmware images for management processors (SCP, arisc, ...)
>>> - firmware images for devices like WiFi controllers
>>> - bit files for FPGAs
>>> - additional configuration data
>>> - kernels and/or ramdisks
>>> The actual usage of this feature would be platform and/or board specific.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara at arm.com>
>>> ---
>>>    common/spl/spl_fit.c | 27 +++++++++++++++++++++++++++
>>>    1 file changed, 27 insertions(+)
>>>
>>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>>> index d4149c5..18269f7 100644
>>> --- a/common/spl/spl_fit.c
>>> +++ b/common/spl/spl_fit.c
>>> @@ -190,6 +190,7 @@ int spl_load_simple_fit(struct spl_image_info
>>> *spl_image,
>>>        struct spl_image_info image_info;
>>>        int node, images;
>>>        int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
>>> +    int index = 0;
>>>          /*
>>>         * Figure out where the external images start. This is the base
>>> for the
>>> @@ -234,6 +235,11 @@ int spl_load_simple_fit(struct spl_image_info
>>> *spl_image,
>>>        if (node < 0) {
>>>            debug("could not find firmware image, trying loadables...\n");
>>>            node = spl_fit_get_image_node(fit, images, "loadables", 0);
>>> +        /*
>>> +         * If we pick the U-Boot image from "loadables", start at
>>> +         * the second image when later loading additional images.
>>> +         */
>>> +        index = 1;
>>>        }
>>>        if (node < 0) {
>>>            debug("%s: Cannot find u-boot image node: %d\n",
>>> @@ -259,5 +265,26 @@ int spl_load_simple_fit(struct spl_image_info
>>> *spl_image,
>>>        image_info.load_addr = spl_image->load_addr + spl_image->size;
>>>        spl_load_fit_image(info, sector, fit, base_offset, node,
>>> &image_info);
>>>    +    /* Now check if there are more images for us to load */
>>> +    for (; ; index++) {
>>> +        node = spl_fit_get_image_node(fit, images, "loadables", index);
>>> +        if (node < 0)
>>> +            break;
>>> +
>>> +        spl_load_fit_image(info, sector, fit, base_offset, node,
>>> +                   &image_info);
>>> +
>>> +        /*
>>> +         * If the "firmware" image did not provide an entry point,
>>> +         * use the first valid entry point from the loadables.
>>> +         */
>>> +        if (spl_image->entry_point == -1U &&
>>> +            image_info.entry_point != -1U)
>>> +            spl_image->entry_point = image_info.entry_point;
> So this part here saves the entry point from the first image which
> provides an "entry" property in the loadables section, given that
> "firmware" didn't provide (a legal) one.
>
> So depending on what you want, these are the options:
> a) You want to branch to U-Boot (default case if mkimage -f auto is
> used): You either don't specify an explicit entry point at all or
> provide an "entry" property for the U-Boot "firmware" image.
> The code below at the end of this function takes care of this.
> b) You want to branch to something else (bl31.bin): You make sure there
> is no explicit entry point in "firmware", instead put one "entry"
> property in the bl31 image description you want to boot. This will then
> branch to that instead of U-Boot.
> Check the example .its in patch 10/11 for an example of this.
>
> So does this fit for you? Or is there a problem with this?

So that means only one 'entry' can be present even if there are more 
than one image, right?
I think every "firmware" image is possible to have both "load" and 
"entry" node,
for example if we have bl31, bl32 and bl33(U-Boot) in one FIT image,
then we need to fill the bl31_params_t structure with bl32 entry point 
and U-Boot entry point,
so that bl31 able to call bl32 and bl33.
That's why I think we need to identify each of the "firmware", but not 
only know they are
"loadables".

Thanks,
- Kever

>>> +    }
>>> +
>>> +    if (spl_image->entry_point == -1U || spl_image->entry_point == 0)
>>> +        spl_image->entry_point = spl_image->load_addr;
> This statement here takes the load address of the "firmware" image as an
> entry point if none is provided explicitly.
>
> Cheers,
> Andre.
>
>>> +
>>>        return 0;
>>>    }
>
>
>
>
>