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.
So that's the situation for the Orangepi Zero (which is ARMv7), just quick test with GCC 5.2.0 (I believe newer version can generate smaller code): opi-zero-defconfig: SPL-SPI, no FIT at all text data bss dec hex filename 17536 432 232 18200 4718 spl/u-boot-spl opi-zero-defconfig: SPL-SPI, current FIT SPL text data bss dec hex filename 20100 432 232 20764 511c spl/u-boot-spl opi-zero-defconfig: SPL-SPI, extended FIT SPL text data bss dec hex filename 20313 432 232 20977 51f1 spl/u-boot-spl So this costs us 213 Bytes. Let me send you this ctype() hack I talked about, that saves quite something for me: opi-zero-defconfig: SPL-SPI, extended FIT SPL, tiny_ctype text data bss dec hex filename 20069 432 232 20733 50fd spl/u-boot-spl Cheers, Andre. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot