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 >>>> _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
