stm32: Fix b_u585i_iot02a and regression script

[erwango]

There are 2 issues with current TF-M preventing to use on STM32 targets:

• Use of STSAFE should be disabled. This was fixed upstream with https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/29034/2. Note that this patch updates flash_layout which is only done for test purpose and required a flash partition update on Zephyr target which I prefer to avoid, so this particular fix is discarded
• "Hard reset" option usage in regression script actually prevent to update option bytes. Fix in upstream is under preparation but we do need to fix it for V3.7.0

[ithinuel]

Does that mean that the Zephyr 3.7 LTS would need a non-LTS release (or even a "floating git hash") of TF-M?

[erwango]

Does that mean that the Zephyr 3.7 LTS would need a non-LTS release (or even a "floating git hash") of TF-M?

Good point. This should be fixed in TF-M LTS first. This should be done this week.
I'll close this PR and open an issue to track the point.

[erwango]

Closing. Issue will be tracked by zephyrproject-rtos/zephyr#74880

[erwango]

Re-opening based on comment from maintainer

[Vge0rge]

Please cherry pick the commit "stm : fix error on b_u585i_iot02a with TF-Mv2.1.0" so that it has a ChangeId (and ideally but not that importantly the commit hash) so that it is easier to manage these commits in the next upmerge.

[erwango]

Please cherry pick the commit "stm : fix error on b_u585i_iot02a with TF-Mv2.1.0" so that it has a ChangeId (and ideally but not that importantly the commit hash) so that it is easier to manage these commits in the next upmerge.

See comment in the description. I don't want to cherrypick the complete change since it introduces a flash_layout change which is only there for debug purpose (according to the developer) and would require an update of the flash partition of the board with less room available for f/w as a consequence.

[ithinuel]

I have seen other PR where the changes are cherry picked and then another commit "reverts" part of it explaining in the commit message the reason for the revert.
It makes tracking the divergence between upstream & this fork easier. (because the "revert commit" can be itself reverted before pulling more commits from upstream on the next bump of TF-M).
I don't have strong opinions on that, maybe @d3zd3z or another maintainer of the repo can give some guidance?

[Vge0rge]

I have seen other PR where the changes are cherry picked and then another commit "reverts" part of it explaining in the commit message the reason for the revert. It makes tracking the divergence between upstream & this fork easier. (because the "revert commit" can be itself reverted before pulling more commits from upstream on the next bump of TF-M). I don't have strong opinions on that, maybe @d3zd3z or another maintainer of the repo can give some guidance?

@erwango Sure, there are ways to handle your use case though. What @ithinuel makes a lot of sense since it helps tracking what's happening in a separate commit. But at the very least a mention in the commit/change id of the upstream change helps a lot the people who do upmerges in this repo.

[erwango]

I have seen other PR where the changes are cherry picked and then another commit "reverts" part of it explaining in the commit message the reason for the revert.

Ok, I'll proceed this way.

[erwango]

@ithinuel @Vge0rge I've done as suggested. Please let me know if this is fine now.

[erwango]

@Vge0rge PTAL

[Vge0rge]

Look good now @erwango :)

[Vge0rge]

By the way, I cannot add myself as reviewer but if someone adds me I can approve as well.

[erwango]

By the way, I cannot add myself as reviewer but if someone adds me I can approve as well.

I tried, but I didn't managed.