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

[Icenowy Zheng]

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