search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.67k stars 6.52k forks source link

Add TFM_PROVIDES_BL1 option used to use stage 1 bootloader (BL1) from TF-M as part of final merged hex #49452

Open ext-mwo opened 2 years ago

ext-mwo commented 2 years ago

Is your enhancement proposal related to a problem? Please describe.

Both Zephyr and TF-M contains board support code for the same board. A Zephyr board config sets the corresponding TF-M board to be used when building TF-M.

Some of the TF-M boards produce a stage 1 (BL1) bootloader. The custom board that I use builds BL1.

The TF-M produced BL1 (elf|bin|hex) file is not accessible from Zephyr when making a merged hex image.

The image contains only BL2 and the secure/unsecure images merged into one HEX file (tfm_merged.hex).

I used the following command for testing: west build -p -b b_u585i_iot02a_ns samples/tfm_integration/tfm_ipc

Describe the solution you'd like

Add a config option: "TFM_PROVIDES_BL1" which instructs CMake to expect to find a BL1 (elf|bin|hex) after TF-M has been built. The option doesn't change TF-M configuration. The board used for TF-M is expected to output bl1.(elf|bin|hex) based on its config. It it doesn't the zephyr build will fail. The added option should be disabled per default.

Describe alternatives you've considered

The alternative is making flashing scripts that are not part of Zephyr.

Additional context No.

ext-mwo commented 2 years ago

I added the proposed solution here: https://github.com/zephyrproject-rtos/zephyr/pull/49453