Boot up time of NCS application

RE: Boot up time of NCS application

Sigurd — Fri, 01 Sep 2023 15:24:23 GMT

Hi!

As far as I can tell, it's mainly a tradeoff between boot time and security. i.e. as mentioned in the Kconfig help text: https://github.com/nrfconnect/sdk-mcuboot/blob/v1.9.99-ncs3/boot/zephyr/Kconfig#L178

RE: Boot up time of NCS application

trafficode — Fri, 01 Sep 2023 09:42:48 GMT

[quote userid="15146" url="~/f/nordic-q-a/103379/boot-up-time-of-ncs-application/444042"]From start-up, until main() in the application is reached, you have all the PRE_KERNEL_1 , PRE_KERNEL_2 , and POST_KERNEL initialization. The device drivers you are using are initialized before your main() function. E.g. if you using the serial driver in your application, then the UART is initialized at PRE_KERNEL_1 level. The more drivers and things that are enabled, the longer time it will take.[/quote]

I know it. Like I mentioned in first post: application without MCUBOOT boot up in 8ms, so thats the time of booting only the application, peripheralls etc. So there is no significant optimization to reach.

DALI(Digital addresable lighting interface): two wire serial interface.

https://www.dali-alliance.org/

CONFIG_BOOT_VALIDATE_SLOT0=n helped a lot. Now boot up time is about 10ms: APPL+MCUBOOT.

But each stick has two ends. What I'm loosing in this approach?

CONFIG_BOOT_VALIDATE_SLOT0 controls whether MCUboot validates the signature of the booted image on every boot (or just when upgrading). This can be disabled to make the boot process slightly faster, at the cost of no longer verifying a path of trust to the running image.

It seems to be still secure, do You know some additional bad sides?

RE: Boot up time of NCS application

Sigurd — Fri, 01 Sep 2023 09:24:46 GMT

From start-up, until main() in the application is reached, you have all the PRE_KERNEL_1 , PRE_KERNEL_2 , and POST_KERNEL initialization. The device drivers you are using are initialized before your main() function. E.g. if you using the serial driver in your application, then the UART is initialized at PRE_KERNEL_1 level. The more drivers and things that are enabled, the longer time it will take.

I'm not sure what this DALI interface is, but in theory it could be up and running and be responsive before you reach main().

Also, with MCUBoot, it will take longer before your application boots.
MCUBoot will e.g. validate the signature of the image that it will boot, and this takes a bit of time.
You can try to speed up the boot process by setting CONFIG_BOOT_VALIDATE_SLOT0=n and/or BOOT_VALIDATE_SLOT0_ONCE=y https://github.com/nrfconnect/sdk-mcuboot/blob/v1.9.99-ncs3/boot/zephyr/Kconfig#L178

RE: Boot up time of NCS application

trafficode — Fri, 01 Sep 2023 09:11:34 GMT

I set gpio pin when I reach while(1){} in main(). It means that pin is set if device is initialized and ready to work. Then I observe VDD and this pin on oscilloscope. Thats haw I'm doing boot up measurements.

Why it is critical... Device is based on DALI interface. Standard require that device/driver has to answer to query no longer than 450ms after mains appear on device. And this procedure(power cycle and query) is automated by certified by "DALI Alliance" tester device. To meet worldwide requirements and to put sticker into device I need to met this requirement...

Specific electronics gives 300ms overhead between mains and vdd appear. Thats why 150ms is so critical.

RE: Boot up time of NCS application

Sigurd — Fri, 01 Sep 2023 08:59:26 GMT

Hi,

1) How are you measuring this? Is it when you e.g. reach main() in your app?

2) Can you elaborate on what makes it critical you start up very fast? Do you need to e.g. set some GPIO pin high within x time, or send some data over UART, etc ?