modules: tf-m: rework output file generation #98730

JordanYates · 2025-11-02T06:38:45Z

Stop mergehex.py argument --output-bin from consuming the first trailing argument that should have been in input_files.

S_NS_CONFIRMED_HEX_FILE was never generating a confirmed file, just the same file contents as S_NS_HEX_FILE. Since no logic needs a confirmed merge of tfm_s.hex and zephyr.hex, just remove the logic instead of fixing it.

Generate a binary version of tfm_s_zephyr_ns_signed.hex with objcopy. This file is valid for performing OTA upgrades, unlike tfm_merged.bin, which now contains BL2.

Generate tfm_merged.bin from tfm_merged.hex with objcopy.

Fixes #98728

After this PR, the correct file to use for OTA upgrades with CONFIG_TFM_MCUBOOT_IMAGE_NUMBER=1 is tfm_s_zephyr_ns_signed.bin, not tfm_merged.bin.

nandojve · 2025-11-04T08:44:58Z

Hi @JordanYates ,

I did not look in deep your changes but I would like to reinfoce:

1- The image that is flashed in production and in development (HEX FILE) MUST be confirmed.

This is necessary to make sure that TF-M state machine will work correctly.
Even if people say it is necessary to have a confirmed image to run I can argue that in the same way having confirmed do not affect. The main difference is that a confirmed image means (in terms of FWU) that it is a sane image.
2- The image that is used in FOTA (BIN FILE) MUST NOT be confirmed. User APP must confirm the image and it should be part of the TF-M FWU procedure.

That said, my original intention was (following your recommendation in the original PR) create valid names to differentiate the confirmed vs non-confirmed image. First should be used in production and second in FOTA.

In my eyes, at least in your last commit, it seems that you are providing the binary confirmed - which violates [2].

So, if there are different use cases that requires the BIN to be already confirmed we need to provide a way to fulfill that requirement in all scenarios.

JordanYates · 2025-11-04T10:45:21Z

I did not look in deep your changes but I would like to reinfoce:

This is a frustrating comment. If you haven't looked at the details why bring up points that you have no idea whether they are relevant or not. It just wastes everyones time.

1- The image that is flashed in production and in development (HEX FILE) MUST be confirmed.

Great, absolutely nothing has changed with respect to tfm_merged.hex, and tfm_merged.bin can now actually be used for that purpose.

2- The image that is used in FOTA (BIN FILE) MUST NOT be confirmed.

Great, that is the purpose of tfm_s_zephyr_ns_signed.bin, which is not confirmed.

That said, my original intention was (following your recommendation in the original PR) create valid names to differentiate the confirmed vs non-confirmed image

Not to be rude, but it sounds like you understood my recommendation and then ignored it. file_name_x.hex and file_name_x.bin should not contain fundamentally different file contents, which is what ended up being merged (as tfm_merged.hex and tfm_merged.bin).

In my eyes, at least in your last commit, it seems that you are providing the binary confirmed - which violates [2].

tfm_merged.bin SHOULD have the exact same file contents as tfm_merged.hex. Disagreeing with that statement is the same as saying zephyr.hex should contain a MCUboot image while zephyr.bin should not. It doesn't make any sense.

The correct file to use for OTA updates (As explicitly said in the PR description) is tfm_s_zephyr_ns_signed.bin.

nandojve · 2025-11-05T07:52:17Z

@JordanYates ,

I did not look in deep your changes but I would like to reinfoce:

This is a frustrating comment. If you haven't looked at the details why bring up points that you have no idea whether they are relevant or not. It just wastes everyones time.

I wish I had the proper amount of time to proper evaluate and you are talking about frustration. Frustration is working for months to get issues fixed and the PR got merged in the last day because someone don't came back. When I had a setup and time to evaluate where were you? Now in the RC-2 you want people be available to you as nothing happened. You could at least tag me to double check, which in my humble opinion, is the minimal to be professional. But thank you for clarify my concerns.

I was looking in the docs and they need to be changed to not create confusion.

I think it will be necessary to state what are the new artifacts to make clear to everyone. Proper naming convention could be necessary to easy follow the main idea. You want to have BIN files generated as same as HEX, I think this should be conditioned to the Kconfig option that states to generate bin files copies.

JordanYates · 2025-11-05T08:10:48Z

When I had a setup and time to evaluate where were you?

I did nack the original PR twice and commented over a few weeks the same issues, which were not resolved.
You did send a reminder but between it being sent and the PR being merged a few days later I was on leave.

You could at least tag me to double check

That's my bad, I assumed Github would automatically notify you since you so recently made changes, but didn't initially check. I did see that you were tagged two hours after the PR was opened, there didn't seem much reason to tag you again.

I was looking in the docs and they need to be changed to not create confusion.

Yes

You want to have BIN files generated as same as HEX

I want to have file names mean something

JordanYates · 2025-11-05T08:34:08Z

I was looking in the docs and they need to be changed to not create confusion.

There are other textual updates, but this is the key table I am proposing.

JordanYates · 2025-11-05T08:47:29Z

Now in the RC-2 you want people be available to you as nothing happened

Also just to address this, I know its not ideal, but it takes me time to update my fork to newer releases and start testing, which then requires finding and fixing issues before a PR can be opened. You may notice this PR was opened on a Sunday evening, I'm trying to raise and fix issues as quickly as possible. It may be RC2, but its only 5 business days after RC1, the first call for testing.

nordicjm

it should be noted that what happens in this file is (and was) wrong, there are Kconfigs for specifying the output file formats, CONFIG_BUILD_OUTPUT_HEX and CONFIG_BUILD_OUTPUT_BIN, neither of which seem to be checked or used here

modules/trusted-firmware-m/CMakeLists.txt

Stop `--output-bin` from consuming the first trailing argument that should have been in `input_files`. Signed-off-by: Jordan Yates <jordan@embeint.com>

Fix formatting errors that cause CI to complain. Signed-off-by: Jordan Yates <jordan@embeint.com>

`S_NS_CONFIRMED_HEX_FILE` was never generating a confirmed file, just the same file contents as `S_NS_HEX_FILE`. Since no logic needs a confirmed merge of `tfm_s.hex` and `zephyr.hex`, just remove the logic instead of fixing it. Signed-off-by: Jordan Yates <jordan@embeint.com>

Generate a binary version of `tfm_s_zephyr_ns_signed.hex` with objcopy. This file is valid for performing OTA upgrades, unlike `tfm_merged.bin`, which contains BL2. Signed-off-by: Jordan Yates <jordan@embeint.com>

Since `tfm_merged.bin` now contains BL2, it can only be used for the same purposes as `tfm_merged.hex` (intial firmware loading). Therefore it should be using the confirmed images that `tfm_merged.hex` does. Since the only difference between the two files with that change is now the output format, we can directly generate `tfm_merged.bin` from `tfm_merged.hex` with `objcopy` instead of going through `mergehex.py`. Signed-off-by: Jordan Yates <jordan@embeint.com>

Document the useful output files that exist, which files they are constructed from, and what they can be used for. Update other sections that are no longer correct with changes. Signed-off-by: Jordan Yates <jordan@embeint.com>

JordanYates · 2025-11-05T09:21:38Z

it should be noted that what happens in this file is (and was) wrong, there are Kconfigs for specifying the output file formats, CONFIG_BUILD_OUTPUT_HEX and CONFIG_BUILD_OUTPUT_BIN, neither of which seem to be checked or used here

That's a good point, but unless I am mistaken respecting those options requires this PR.
Those options don't make sense if tfm_merged.hex and tfm_merged.bin don't have the same file contents (the complete merged output).

nordicjm · 2025-11-05T09:23:11Z

it should be noted that what happens in this file is (and was) wrong, there are Kconfigs for specifying the output file formats, CONFIG_BUILD_OUTPUT_HEX and CONFIG_BUILD_OUTPUT_BIN, neither of which seem to be checked or used here

That's a good point, but unless I am mistaken respecting those options requires this PR. Those options don't make sense if tfm_merged.hex and tfm_merged.bin don't have the same file contents (the complete merged output).

The files used for generating them should be the same, yes, but the hex should not be generated if the Kconfig is not selected but the bin file should be :)

sonarqubecloud · 2025-11-05T09:24:07Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

JordanYates · 2025-11-05T09:26:28Z

The files used for generating them should be the same, yes, but the hex should not be generated if the Kconfig is not selected but the bin file should be :)

Do you want that as part of this PR? I would leave it for the next feature cycle

nordicjm · 2025-11-05T09:28:44Z

The files used for generating them should be the same, yes, but the hex should not be generated if the Kconfig is not selected but the bin file should be :)

Do you want that as part of this PR? I would leave it for the next feature cycle

Not for this PR but a future task, this fixes a bug and the behaviour has not changed in this PR in regards to that from the existing behaviour so it's been a bug for a while

nandojve · 2025-11-06T07:14:56Z

I was looking in the docs and they need to be changed to not create confusion.

There are other textual updates, but this is the key table I am proposing.

1- I think the output content is correct.
2- Could you clarify why the HEX for FOTA. Is there anything else that I'm missing? Anyway, zephyr_ns_signed.hex must be available too then.
3- By the convention we are proposing, tfm_merged should be renamed to something like tfm_merged_signed_confirmed . Besides, _merged seems to me odd at moment but I can not think something better.

nandojve · 2025-11-06T07:15:48Z

The files used for generating them should be the same, yes, but the hex should not be generated if the Kconfig is not selected but the bin file should be :)

Do you want that as part of this PR? I would leave it for the next feature cycle

Not for this PR but a future task, this fixes a bug and the behaviour has not changed in this PR in regards to that from the existing behaviour so it's been a bug for a while

Maybe we open an issue to be addressed in future and not to forget ?

JordanYates · 2025-11-06T10:23:23Z

1- I think the output content is correct.

Great

2- Could you clarify why the HEX for FOTA. Is there anything else that I'm missing?

I don't pretend to know every possible upgrade mechanism, maybe there is some custom thing that wants a hex file uploaded to the cloud and it handles processing it to some other form. The file is available there, with the same logical contents as the .bin, if anyone wants to use it.

Anyway, zephyr_ns_signed.hex must be available too then.

I tweaked the table after the screenshot, every file in the table has a .hex and .bin variant listed now.

3- By the convention we are proposing, tfm_merged should be renamed to something like tfm_merged_signed_confirmed . Besides, _merged seems to me odd at moment but I can not think something better.

Probably, but the file has been called tfm_merged for a long time now, changing it in this PR is not a good idea IMO. Absolutely we can change it next release.

maass-hamburg · 2025-11-06T12:54:51Z

so what is the point here, I unfortunately never used tf-m.

JordanYates · 2025-11-06T13:13:44Z

so what is the point here, I unfortunately never used tf-m.

Fixing the linked issue

maass-hamburg · 2025-11-06T13:31:47Z

If I interpret it right, instead of combining bin and hex separate, the merged bin files is now created from the merged hex files

JordanYates · 2025-11-06T22:07:22Z

If I interpret it right, instead of combining bin and hex separate, the merged bin files is now created from the merged hex files

No. tfm_merged.bin had different file contents (missing the bootloader) compared to tfm_merged.hex.
This PR normalises the file contents for each file name, .hex/.bin is now purely the encoding format.

tejlmand · 2025-11-07T15:32:42Z

The files used for generating them should be the same, yes, but the hex should not be generated if the Kconfig is not selected but the bin file should be :)

@nordicjm correct, but for the TF-M then BUILD_WITH_TFM selects hex output 🙈

zephyr/modules/trusted-firmware-m/Kconfig.tfm

Lines 39 to 44 in dbcfb77

    
           menuconfig BUILD_WITH_TFM 
        
           	bool "Build with TF-M as the Secure Execution Environment" 
        
           	depends on TRUSTED_EXECUTION_NONSECURE 
        
           	depends on TFM_BOARD != "" 
        
           	depends on ARM_TRUSTZONE_M 
        
           	select BUILD_OUTPUT_HEX

tejlmand

Approving this PR as it does fixes issues related to earlier merged PR.

That said, I do think its unfortunate that bin output is depending on hex output, but as TF-M enforces hex output, then this is not an issue in practice.

tejlmand · 2025-11-07T15:02:53Z

scripts/build/mergehex.py

                        help="What to do when files overlap (error, ignore, replace). "
                             "See IntelHex.merge() for more info.")
-    parser.add_argument("--output-bin", default=False,
+    parser.add_argument("--output-bin", action='store_true',


I do know that some of this are just trying to patch what was done in #94470 with regards to how mergehex is used to create bin file.

One can discuss if script name / purpose should be updated.

That said, this change fixes an immediate issue which is good 👍

tejlmand · 2025-11-07T15:13:51Z

modules/trusted-firmware-m/CMakeLists.txt

        $<$<NOT:$<BOOL:${CONFIG_TFM_BL1}>>:$<TARGET_PROPERTY:tfm,BL2_HEX_FILE>>
        ${S_NS_SIGNED_CONFIRMED_HEX_FILE}
+
+      COMMAND ${CMAKE_OBJCOPY} --input-target=ihex --output-target=binary ${MERGED_HEX_FILE} ${MERGED_BIN_FILE}


I agree that because mergehex already works on the hex files in order to produce the bin binary, then there is no reason for going through an extra mergehex path.

The question regarding bin output depending on hex output, and thus mergehex producing bin output is another (though important) discussion, is something which I don't think belong here.

Thus approving this change.

nandojve

Thank you for the fixing @JordanYates

JordanYates added this to the v4.3.0 milestone Nov 2, 2025

JordanYates added area: TF-M ARM Trusted Firmware-M (TF-M) bug The issue is a bug, or the PR is fixing a bug labels Nov 2, 2025

zephyrbot added the area: Build System label Nov 2, 2025

zephyrbot requested review from 57300, Vge0rge, d3zd3z, ithinuel, jeremybettis, nashif, nordicjm, tejlmand, tomi-font, valeriosetti and wearyzen November 2, 2025 06:40

zephyrbot assigned tejlmand Nov 2, 2025

JordanYates force-pushed the 251102_tfm_files branch from 0cd0379 to 0afe6fc Compare November 2, 2025 06:46

JarmouniA requested a review from nandojve November 2, 2025 09:27

JordanYates force-pushed the 251102_tfm_files branch from 4eddd41 to 179ec23 Compare November 5, 2025 08:40

nordicjm reviewed Nov 5, 2025

View reviewed changes

modules/trusted-firmware-m/CMakeLists.txt Outdated Show resolved Hide resolved

JordanYates added 4 commits November 5, 2025 19:20

scripts: build: mergehex: fix --output-bin

99cbba8

Stop `--output-bin` from consuming the first trailing argument that should have been in `input_files`. Signed-off-by: Jordan Yates <jordan@embeint.com>

modules: tf-m: fix CMake formatting

aa5938f

Fix formatting errors that cause CI to complain. Signed-off-by: Jordan Yates <jordan@embeint.com>

modules: tf-m: generate tfm_s_zephyr_ns_signed.bin

d8ca6cb

Generate a binary version of `tfm_s_zephyr_ns_signed.hex` with objcopy. This file is valid for performing OTA upgrades, unlike `tfm_merged.bin`, which contains BL2. Signed-off-by: Jordan Yates <jordan@embeint.com>

JordanYates added 2 commits November 5, 2025 19:20

doc: tfm: document output files

e410e2d

Document the useful output files that exist, which files they are constructed from, and what they can be used for. Update other sections that are no longer correct with changes. Signed-off-by: Jordan Yates <jordan@embeint.com>

JordanYates force-pushed the 251102_tfm_files branch from 179ec23 to e410e2d Compare November 5, 2025 09:20

nandojve requested a review from nordicjm November 6, 2025 07:16

JarmouniA requested a review from maass-hamburg November 6, 2025 12:40

tejlmand approved these changes Nov 7, 2025

View reviewed changes

nandojve approved these changes Nov 7, 2025

View reviewed changes

jhedberg merged commit 3ad0946 into zephyrproject-rtos:main Nov 7, 2025
35 checks passed

JordanYates deleted the 251102_tfm_files branch November 7, 2025 23:00

modules: tf-m: rework output file generation #98730

modules: tf-m: rework output file generation #98730

Uh oh!

Conversation

JordanYates commented Nov 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nandojve commented Nov 4, 2025

Uh oh!

JordanYates commented Nov 4, 2025

Uh oh!

nandojve commented Nov 5, 2025

Uh oh!

JordanYates commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JordanYates commented Nov 5, 2025

Uh oh!

JordanYates commented Nov 5, 2025

Uh oh!

nordicjm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JordanYates commented Nov 5, 2025

Uh oh!

nordicjm commented Nov 5, 2025

Uh oh!

sonarqubecloud bot commented Nov 5, 2025

Quality Gate passed

Uh oh!

JordanYates commented Nov 5, 2025

Uh oh!

nordicjm commented Nov 5, 2025

Uh oh!

nandojve commented Nov 6, 2025

Uh oh!

nandojve commented Nov 6, 2025

Uh oh!

JordanYates commented Nov 6, 2025

Uh oh!

maass-hamburg commented Nov 6, 2025

Uh oh!

JordanYates commented Nov 6, 2025

Uh oh!

maass-hamburg commented Nov 6, 2025

Uh oh!

JordanYates commented Nov 6, 2025

Uh oh!

tejlmand commented Nov 7, 2025

Uh oh!

tejlmand left a comment

Choose a reason for hiding this comment

Uh oh!

tejlmand Nov 7, 2025

Choose a reason for hiding this comment

Uh oh!

tejlmand Nov 7, 2025

Choose a reason for hiding this comment

Uh oh!

nandojve left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

JordanYates commented Nov 2, 2025 •

edited

Loading

JordanYates commented Nov 5, 2025 •

edited

Loading