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

[Andre 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.
>>
> 
> Yes, we include FIT support in our build, and we make a lot of
> sacrifices in functionality for it (reducing the types of media we can
> load from, tiny malloc, tiny printf, etc..).
> 
> When new features come out we need to decide which old ones to disable,
> so the benefits of FIT and other features have to be worth more than the
> size in code it takes to implement them. (I think this change is worth
> it and am willing to sacrifice other things to keep our boards booting
> and have this addition, but we need to try to keep this in size issue in
> mind).

OK, got it. I have some easy patches to cut off 250 Bytes or so from an
AArch64 build, maybe there is something similar possible for ARM?
For instance I converted the ctype() implementation from table based to
using simple comparisons and could cover all cases needed by the SPL and
save 200 Bytes. After a quick look at am335x_shc_sdboot_defconfig it
seems you have the 256 Byte ctype() table in there, so I can send this
patch to give you more back than this FIT extension takes ;-)

>>>> The first three patches rework the SPL FIT support to be more flexible
>>>> and to allow easier usage in the fourth patch, which introduces the
>>>> multiple-image loading facility.
>>>> The remaining patches enable that support for the Pine64 board to make
>>>> its SPL support finally useful and to demonstrate usage of this scheme:
>>>> patches 5-7 extend the usable SPL size by about 4 KB to allow AArch64
>>>> compilation of the SPL with FIT support enabled. Patch 8 implements the
>>>> board selector routine, which selects either the Pine64 or Pine64+ DTB
>>>> depending on the detected DRAM size. Patch 9 enables SPL FIT support in
>>>> the Pine64 defconfig.
>>>> To demonstrate the usage, patch 10 provides a FIT source file, which
>>>> loads and executes ATF before the U-Boot proper. Users are expected to
>>>> compile this with "mkimage -f boards/sunxi/pine64_atf.its -E pine64.itb",
>>>> then write the resulting file behind the SPL on an SD card (or any other
>>>> U-Boot supported boot media, for that matter).
>>>> Patch 11 then adds FIT support to the sunxi SPL SPI loading routine,
>>>> which allows to load ATF on boards with SPI flash as well.
>>>>
>>>> Questions:
>>>> 1) Is this scheme the right one (usage of "firmware" and "loadables",
>>>>    determination of entry point)? Shall we make use of the "setup"
>>>>    property?
>>>> 2) Shall we extend mkimage to allow supplying "loadable" files on the
>>>>    command line, which would allow to build the .itb file automatically?
>>>
>>> Where does this end, we may also need to add the load address for
>>> images, etc... eventually we are passing a full .its on the command
>>> line. I'm not against this, as it would help our build process also (we
>>> generate an .its file with all our build artifacts during our distro
>>> build and feed it to mkimage), so if we think this is better than option
>>> 3 below, we should think through all the things we may need before
>>> cluttering up the mkimage command line arguments.
>>
>> I agree, I was wondering about that as well. It's just tempting to add
>> one or two options and piggy-back on the existing Makefile support.
>>
>> Maybe some generic infrastructure of storing platform or board specific
>> .its files can be included into the build system? Similarly to .dts
>> files we could reference them in the (def)config and use mkimage -f
>> during build to generate an image? That sounds more flexible than adding
>> command line options to cover specific scenarios. We may use something
>> like mergeconfig to make changes to the .its when needed.
>>
> 
> I'm okay with that, as these .its files are .dts based anyway it
> shouldn't be too hard to have #includes to get other image specific
> nodes and overrides. One thing I'm not sure about is having the .its
> files stored in U-Boot tree, as most of the stuff we add to our .itb
> loadable section is external (ATF, OP-TEE, IPU/IVA firmware, etc..), but
> I'm all for adding the support to mkimage for such a thing anyway.

Yeah, that's an interesting point. Allwinner also needs the ATF bl31.bin
to be provided somehow. In the "demo" .its I put it into U-Boot root,
maybe we should create a directory "externals" or the like with just a
README in it, and people are supposed to copy or link in the binary
images there? In the .its it would read "../../externals/...", for
instance, to make it more clear that those components are external to
and not provided by U-Boot.

Cheers,
Andre.

>> Cheers,
>> Andre.
>>
>>>> 3) Is providing the .its source file for a (family of) boards the right
>>>>    way?
>>>> 4) Does this break any boards which already use SPL FIT loading?
>>>>
>>>> And for the Pine64 part:
>>>> 5) Is extending the usable SPL size like in patch 5-7 acceptable?
>>>>
>>>> I have a more generic solution for the .dtb selection in mind: Based on
>>>> some patch from Siarhei we store the .dtb filename in the SPL header and
>>>> select the .dtb from the FIT image by simply matching the name. This would
>>>> allow _one_ build supporting multiple boards. The actual board name would
>>>> need to written into the SPL header or could be copied from there when
>>>> updating the image.
>>>> I can provide the patches once we agreed upon this series.
>>>>
>>>> Please let me know what you think!
>>>>
>>>> Cheers,
>>>> Andre.
>>>>
>>>> Andre Przywara (11):
>>>>   SPL: FIT: refactor FDT loading
>>>>   SPL: FIT: rework U-Boot image loading
>>>>   SPL: FIT: factor out spl_load_fit_image()
>>>>   SPL: FIT: allow loading multiple images
>>>>   tools: mksunxiboot: allow larger SPL binaries
>>>>   sunxi: A64: SPL: allow large SPL binary
>>>>   sunxi: A64: move SPL stack to end of SRAM A2
>>>>   sunxi: SPL: add FIT config selector for Pine64 boards
>>>>   sunxi: Pine64: defconfig: enable SPL FIT support
>>>>   sunxi: Pine64: add FIT image source
>>>>   SPL: SPI: sunxi: add SPL FIT image support
>>>>
>>>>  board/sunxi/board.c             |  13 +++
>>>>  board/sunxi/pine64_atf.its      |  54 +++++++++
>>>>  common/spl/spl_fit.c            | 241 +++++++++++++++++++++++-----------------
>>>>  configs/pine64_plus_defconfig   |   5 +
>>>>  drivers/mtd/spi/sunxi_spi_spl.c |  39 +++++--
>>>>  include/configs/sunxi-common.h  |   6 +-
>>>>  scripts/Makefile.spl            |   7 +-
>>>>  tools/mksunxiboot.c             |  51 ++++++---
>>>>  8 files changed, 290 insertions(+), 126 deletions(-)
>>>>  create mode 100644 board/sunxi/pine64_atf.its
>>>>