Skip to content

flash: workaround compiler error with FIH_PANIC #144

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 16, 2025

Conversation

nashif
Copy link
Member

@nashif nashif commented Jul 11, 2025

Both function are not declared in any headers.

Signed-off-by: Anas Nashif anas.nashif@intel.com

Add code_unreachable to satisfy compiler and convince it we do not
return in this function.

The error we are getting:

error: 'noreturn' function does return [-Werror]

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
@nashif nashif force-pushed the topic/flash_header branch from 69bfcdc to 1348d64 Compare July 12, 2025 11:57
@nashif nashif changed the title flash: declare both flash_area_sector_from_off and flash_area_get_sector flash: workaround compiler error with FIH_PANIC Jul 12, 2025
nicola-mazzucato-arm and others added 3 commits July 12, 2025 09:38
Fix the following warning in cc3xx_init.c
warning: unused variable 'lock_dfa_enabled' [-Wunused-variable]
   75 |     uint32_t lock_dfa_enabled = dfa_is_supported;
      |              ^~~~~~~~~~~~~~~~

Signed-off-by: Nicola Mazzucato <nicola.mazzucato@arm.com>
Change-Id: I6d6ad2100557b55d4aabdfcdb1ea3b9e2d799b22
(cherry picked from commit e201cb6)
Do not report errors on array-parameter warnings, zephyr does, but in
tf-m this is being ignored and requires some significant changes to
comply.

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
or else we get defined-but-not-used warnings which would turn into
errors.

Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Copy link
Collaborator

@tomi-font tomi-font left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite like how we're just fixing things here locally. Have those patches been submitted upstream? At the very least can we put up PRs upstream at the same time and reference them?

@nashif
Copy link
Member Author

nashif commented Jul 14, 2025

I don't quite like how we're just fixing things here locally. Have those patches been submitted upstream? At the very least can we put up PRs upstream at the same time and reference them?

well, I am not introducing a feature and we need those changes for the 4.2 release. Thats why we have this repo, we should not be waiting for upstream to deal with such issues.

One of the changes has another PR which has dependencies on mcuboot and is being submitted as a patch already, not sure how this will be dealt with:

#143

@tomi-font
Copy link
Collaborator

well, I am not introducing a feature and we need those changes for the 4.2 release. Thats why we have this repo, we should not be waiting for upstream to deal with such issues.

Of course as I said I don't mean to wait for fixes to be merged upstream. But we do cooperate and contribute upstream, that's the preferred way. We aim to have as little local patches as possible because it's a source of issues. So here ideally I would rather send those commits as upstream PRs and cherry pick them here, no need to even have a review on them yet, but at least we have something to point to for future cleanup.

One of the changes has another PR which has dependencies on mcuboot and is being submitted as a patch already, not sure how this will be dealt with:

#143

Hmm not sure either what's the right way to go about this. cc @nordicjm @de-nordic

@nashif
Copy link
Member Author

nashif commented Jul 15, 2025

Of course as I said I don't mean to wait for fixes to be merged upstream. But we do cooperate and contribute upstream, that's the preferred way. We aim to have as little local patches as possible because it's a source of issues. So here ideally I would rather send those commits as upstream PRs and cherry pick them here, no need to even have a review on them yet, but at least we have something to point to for future cleanup.

well, I am not even sure how to submit those patches and where, most links in the README are dead. Can someone else please (maintainers of this module in Zephyr) do this? those are trivial build related changes.

@nashif
Copy link
Member Author

nashif commented Jul 16, 2025

one of the commits submitted upstream https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/40761

@nashif nashif merged commit 021e2bb into zephyrproject-rtos:main Jul 16, 2025
@tomi-font
Copy link
Collaborator

tomi-font commented Jul 17, 2025

well, I am not even sure how to submit those patches and where, most links in the README are dead. Can someone else please (maintainers of this module in Zephyr) do this? those are trivial build related changes.

I'll take the two remaining commits upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants