21.01.2017, 01:47, "Andre Przywara" <andre.przyw...@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+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
