cmake: tf-m: create tfm_api dependency on tfm_s.hex #75090
Conversation
Incremental builds for TF-M are not picked up by Zephyr linking stage. Code changes to tf-m repository results in a rebuild of TF-M and thus an updated tfm_s.hex (and other files). tfm_s.hex is merged together with the zephyr hex to form a final merged hex file for flashing. This is done as a post-build command, however such as step cannot take extra dependencies. The Zephyr target can have extra dependencies, however that will only ensure the dependency is brought up-to-date when Zephyr re-link, not re-linking Zephyr when the dependency changes. Therefore an object dependency is placed on the interface.c file for Zephyr TF-M interface implementation, which ensures the tfm_api library is brought up-to-date whenever TF-M rebuilds, and this update again ensures the Zephyr itself is re-linked whenever TF-M rebuilds. Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Incremental builds for TF-M are not picked up by Zephyr linking stage. Code changes to tf-m repository results in a rebuild of TF-M and thus an updated tfm_s.hex (and other files). tfm_s.hex is merged together with the zephyr hex to form a final merged hex file for flashing. This is done as a post-build command, however such as step cannot take extra dependencies. The Zephyr target can have extra dependencies, however that will only ensure the dependency is brought up-to-date when Zephyr re-link, not re-linking Zephyr when the dependency changes. Therefore an object dependency is placed on the interface.c file for Zephyr TF-M interface implementation, which ensures the tfm_api library is brought up-to-date whenever TF-M rebuilds, and this update again ensures the Zephyr itself is re-linked whenever TF-M rebuilds. Upstream PR: zephyrproject-rtos/zephyr#75090 Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Incremental builds for TF-M are not picked up by Zephyr linking stage. Code changes to tf-m repository results in a rebuild of TF-M and thus an updated tfm_s.hex (and other files). tfm_s.hex is merged together with the zephyr hex to form a final merged hex file for flashing. This is done as a post-build command, however such as step cannot take extra dependencies. The Zephyr target can have extra dependencies, however that will only ensure the dependency is brought up-to-date when Zephyr re-link, not re-linking Zephyr when the dependency changes. Therefore an object dependency is placed on the interface.c file for Zephyr TF-M interface implementation, which ensures the tfm_api library is brought up-to-date whenever TF-M rebuilds, and this update again ensures the Zephyr itself is re-linked whenever TF-M rebuilds. Upstream PR: zephyrproject-rtos/zephyr#75090 Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
|
Is there really a need for Zephyr to relink every time TF-M does so? @adeaarm any advice? |
You're correct, the NS world needs to relink only in case the veneers functions are updated, otherwise the two processing environments are completely indepedent. |
|
Zephyr combines the non-secure and the secure image in a single hex named tfm_merged.hex (which is eventually used by sysbuild later to generate merged.hex).This is generated using the extra_post_build_commands of Zephyr here: The reason that the relinking need to happen is that it will enforce this post_builds to execute every time that you update anything in TF-M even if you didn't update something in Zephyr. Without this we observed that a TF-M update will not update the tfm_merged.hex. |
In principle not, but the problem is the merging of the tf-m hex together with the zephyr hex, and this step is only performed when a Zephyr re-link happens. That was what I tried to describe here: #75090 (comment)
but guess I should have continued the sentence with additional |
Incremental builds for TF-M are not picked up by Zephyr linking stage. Code changes to tf-m repository results in a rebuild of TF-M and thus an updated tfm_s.hex (and other files). tfm_s.hex is merged together with the zephyr hex to form a final merged hex file for flashing. This is done as a post-build command, however such as step cannot take extra dependencies. The Zephyr target can have extra dependencies, however that will only ensure the dependency is brought up-to-date when Zephyr re-link, not re-linking Zephyr when the dependency changes. Therefore an object dependency is placed on the interface.c file for Zephyr TF-M interface implementation, which ensures the tfm_api library is brought up-to-date whenever TF-M rebuilds, and this update again ensures the Zephyr itself is re-linked whenever TF-M rebuilds. Upstream PR: zephyrproject-rtos/zephyr#75090 Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no> (cherry picked from commit 9a728d7)
9 participants
Incremental builds for TF-M are not picked up by Zephyr linking stage. Code changes to tf-m repository results in a rebuild of TF-M and thus an updated tfm_s.hex (and other files), but not a re-link of Zephyr.
tfm_s.hex is merged together with the zephyr hex to form a final merged hex file for flashing. This is done as a post-build command, however such as step cannot take extra dependencies. The Zephyr target can have extra dependencies, however that will only ensure the dependency is brought up-to-date when Zephyr re-link, not re-linking Zephyr when the dependency changes.
Therefore an object dependency is placed on the interface.c file for Zephyr TF-M interface implementation, which ensures the tfm_api library is brought up-to-date whenever TF-M rebuilds, and this update again ensures the Zephyr itself is re-linked whenever TF-M rebuilds, and thus the Zephyr re-link ensures a new merge of the two images.