Increased boot time when using FIP

[Grodriguez]

Hello,

 

We are upgrading from BSP 2.1.0 to 3.0.0. With BSP 2.1.0 we had implemented a Secure Boot mechanism as described here, i.e. both TF-A and u-boot were signed with the STM32 Signing Tool and had a stm32 header added.

 

Now with BSP 3.0.0 we see that u-boot is instead encapsulated in a FIP binary which is loaded by TF-A.

 

The problem with this is that this seems to increase boot time by about 1 second (measured with grabserial). The difference seem to be related to TF-A; see the following traces measuring time from boot until the first u-boot trace is printed:

 

For 2.1.0:

[0.000001 0.000001] INFO: Software access to all debug components is disabled
[0.479875 0.479874] INFO: Cannot get CPU version, debug disabled
[0.483940 0.004065] NOTICE: CPU: STM32MP157CAC Rev.?
[0.003018 0.003018] NOTICE: Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
[0.010905 0.007887] NOTICE: Board: MB1272 Var2.0 Rev.C-01
[0.014942 0.004037] NOTICE: Bootrom authentication succeeded
[0.034029 0.019087] INFO: Reset reason (0x14):
[0.036965 0.002936] INFO: Pad Reset from NRST
[0.064959 0.027994] INFO: PMIC version = 0x10
[0.067990 0.003031] INFO: Using SDMMC
[0.070117 0.002127] INFO: Instance 1
[0.072141 0.002024] INFO: Boot used partition fsbl1
[0.137033 0.064892] NOTICE: BL2: v2.2-r2.0(debug):v2.2-dirty
[0.141040 0.004007] NOTICE: BL2: Built : 13:36:23, Oct 22 2019
[0.144984 0.003944] INFO: Using crypto library 'stm32_crypto_lib'
[0.150903 0.005919] INFO: BL2: Doing platform setup
[0.155982 0.005079] INFO: RAM: DDR3-DDR3L 16bits 533000Khz
[0.165922 0.009940] INFO: Memory size = 0x20000000 (512 MB)
[0.169197 0.003275] INFO: BL2 runs SP_MIN setup
[0.177879 0.008682] INFO: BL2: Loading image id 4
[0.180977 0.003098] INFO: Loading image id=4 at address 0x2ffeb000
[0.185893 0.004916] INFO: Image id=4 loaded: 0x2ffeb000 - 0x2ffff000
[0.190022 0.004129] INFO: BL2: Loading image id 5
[0.193088 0.003066] INFO: Loading image id=5 at address 0xc0100000
[0.200903 0.007815] INFO: STM32 Image size : 902500
[0.241967 0.041064] INFO: Image id=5 loaded: 0xc0100000 - 0xc01dc564
[0.530058 0.288091] NOTICE: BL2: Booting BL32
[0.532189 0.002131] INFO: Entry point address = 0x2ffeb000
[0.536124 0.003935] INFO: SPSR = 0x1d3
[0.573027 0.036903] INFO: Software access to all debug components is disabled
[0.579131 0.006104] INFO: Use default chip ID, debug disabled
[0.584944 0.005813] NOTICE: SP_MIN: v2.2-r2.0(debug):v2.2-dirty
[0.590028 0.005084] NOTICE: SP_MIN: Built : 13:36:23, Oct 22 2019
[0.594989 0.004961] INFO: ARM GICv2 driver initialized
[0.608027 0.013038] INFO: Set calibration timer to 60 sec
[0.619929 0.011902] INFO: stm32mp IWDG1 (12): Secure
[0.623027 0.003098] INFO: SP_MIN: Initializing runtime services
[0.627001 0.003974] INFO: SP_MIN: Preparing exit to normal world
[0.729071 0.102070] 
[0.730001 0.000930] 
[0.730063 0.000062] U-Boot 2020.01-stm32mp-r2 (Feb 16 2021 - 09:24:22 +0100)

For 3.0.0:

[0.000000 0.000000] NOTICE: CPU: STM32MP157CAC Rev.?
[0.362179 0.362179] NOTICE: Model: STMicroelectronics STM32MP157C-DK2 Discovery Board
[0.370778 0.008599] NOTICE: Board: MB1272 Var2.0 Rev.C-01
[0.374010 0.003232] NOTICE: Bootrom authentication succeeded
[0.491971 0.117961] NOTICE: BL2: v2.4-r1.0(release):v2.4
[0.495124 0.003153] NOTICE: BL2: Built : 11:26:45, May 3 2021
[1.636946 1.141822] NOTICE: BL2: Booting BL32
[1.679858 0.042912] NOTICE: SP_MIN: v2.4-r1.0(release):v2.4
[1.683190 0.003332] NOTICE: SP_MIN: Built : 14:46:57, May 3 2021
[1.804044 0.120854] 
[1.804130 0.000086] 
[1.804163 0.000033] U-Boot 2020.10-stm32mp-r1 (May 03 2021 - 08:17:17 +0200)

Is this expected?

 

Is it possible to stick with the old secure boot method in 3.x ?

 

Thank you,

 

Guillermo

[Olivier GALLIEN]

Hi @Grodriguez​ ,

Thanks for raising this post.

Indeed we have noticed an extra boot time with FIP vs no-FIP on SDCard.

I'm checking this internally and will come back later for further comments.

In the meantime you can configure the DV3.0 without FIP. We call this "compatibility" mode.

For TF-A refer to :

How to configure TF-A BL2 - stm32mpu

And pay attention to section :

'For ecosystem release ≤ v3.0.0  compatibility'

"Compatibility" mode is not supported by the Makefile.sdk and so you should follow instruction to generate all params for the make command.

For U-boot :

STM32MP15 U-Boot - stm32mpu

"The ouput file is u-boot.stm32 for ecosystem release ≤ v2.1.0 or if you activate CONFIG_STM32MP15x_STM32IMAGE in your defconfig for ecosystem release v3.0.0 (this temporary option is only introduced to facilitate the FIP migration but it will be removed in the next EcosystemRelease)."

Hope it help,

Olivier

[Bernard PUEL]

Compatibility mode will still be available on V3 releases and removed on V4 (so for next kernel LTS ecosystem releases).

Investigation is ongoing. We think FIP mode will still be a bit longer than compatibility mode but we identified a main contributor of this additional boot time in

io_block function that is used in case of FIP (instead of io_mmc that was optimized).

[Grodriguez]

Thanks @Community member​ , @Bernard PUEL​.

So the extra delay is only when reading from SD? That's good to know since our product will boot from NAND -- no SD.

We were just using DK2 eval boards for testing for convenience.

Will repeat the tests on an EV1.

Nonetheless any update is welcome :)

Thank you,

Guillermo