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.