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

[Icenowy Zheng <icenowy@aosc.xyz>]

21.01.2017, 01:47, "Andre Przywara" <andre.przywara@arm.com>:
> 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.

Maybe you can take doc/README.x86 as a reference?

X86 platform nearly all needs external blob (except QEMU :-) ) to build
a ROM image.

>
> 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
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.