[U-Boot] [RFC PATCH 00/11] extend FIT loading support (plus Pine64/ATF support)

[André Przywara]

Hi,

On 20/01/17 17:35, Andrew F. Davis wrote:
> On 01/20/2017 11:17 AM, Andre Przywara wrote:
>> Hi Andrew,
>>
>> thanks for the comments.
>>
>> On 20/01/17 17:02, Andrew F. Davis wrote:
>>> On 01/19/2017 07:53 PM, Andre Przywara wrote:
>>>> Currently the FIT format is not used to its full potential in the SPL:
>>>> It only loads the first image from the /images node and appends the
>>>> proper FDT.
>>>> Some boards and platforms would benefit from loading more images before
>>>> starting U-Boot proper, notably Allwinner A64 and ARMv8 Rockchip boards,
>>>> which use an ARM Trusted Firmware (ATF) image to be executed before U-Boot.
>>>>
>>>> This series tries to solve this in a board agnostic and generic way:
>>>> We extend the SPL FIT loading scheme to allow loading multiple images.
>>>> So apart from loading the image which is referenced by the "firmware"
>>>> property in the respective configuration node and placing the DTB right
>>>> behind it, we iterate over all strings in the "loadable" property.
>>>> Each image referenced there will be loaded to its specified load address.
>>>> The entry point U-Boot eventually branches to will be taken from the
>>>> first image to explicitly provide the "entry" property, or, if none
>>>> of them does so, from the load address of the "firmware" image.
>>>> This keeps the scheme compatible with the FIT images our Makefile creates
>>>> automatically at the moment.
>>>>
>>>> Apart from the already mentioned ATF scenario this opens up more usage
>>>> scenarios, of which the commit message of patch 04/11 lists some.
>>>>
>>>
>>> I have been thinking about a similar problem we are facing regarding
>>> OP-TEE loading when doing SPL-only boots. I think extending SPL FIT
>>> loader is a good approach, I've just been concerned about SPL bloat. On
>>> our High Security enabled AM335x SoC we only have 41KB of SRAM to load
>>> SPL (last I checked we only have 100 bytes of overhead left), and we
>>> need FIT support as we use it for image authentication (it's what we use
>>> the board_fit_image_post_process() hook for), so any changes to SPL FIT
>>> need to be carefully made.
>>
>> Understood. Have you actually included FIT support as it exists already
>> in your build? My observation is that even without these changes
>> proposed here SPL FIT adds quite a bit to the SPL size (hence my patches
>> to extend SPL size for AArch64 sunxi). This is mostly due to some libfdt
>> bits being included, so I guess there is not much you can do about it. I
>> will later check how much the code size changes with my patches.
>> And btw.: Allwinner has either 24KB or 32KB of SRAM, so the situation is
>> even more dire here.

So that's the situation for the Orangepi Zero (which is ARMv7), just
quick test with GCC 5.2.0 (I believe newer version can generate smaller
code):
opi-zero-defconfig: SPL-SPI, no FIT at all
   text    data     bss     dec     hex filename
  17536     432     232   18200    4718 spl/u-boot-spl
opi-zero-defconfig: SPL-SPI, current FIT SPL
   text    data     bss     dec     hex filename
  20100     432     232   20764    511c spl/u-boot-spl
opi-zero-defconfig: SPL-SPI, extended FIT SPL
   text    data     bss     dec     hex filename
  20313     432     232   20977    51f1 spl/u-boot-spl

So this costs us 213 Bytes.
Let me send you this ctype() hack I talked about, that saves quite
something for me:
opi-zero-defconfig: SPL-SPI, extended FIT SPL, tiny_ctype
   text    data     bss     dec     hex filename
  20069     432     232   20733    50fd spl/u-boot-spl

Cheers,
Andre.