newt/builder: read BOOTUTIL_MAX_IMG_SECTORS from syscfg for boot trailer #605
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
m-gorecki
requested changes
Oct 7, 2025
newt/builder/targetbuild.go
Outdated
Comment on lines
801
to
818
| sectors, ok := t.res.Cfg.Settings["BOOTUTIL_MAX_IMG_SECTORS"] | ||
| if !ok { | ||
| util.StatusMessage(util.VERBOSITY_DEFAULT, | ||
| "* Warning: target does not define BOOTUTIL_MAX_IMG_SECTORS "+ | ||
| "setting; assuming a value of 128.\n") | ||
| maxImgSectors = 128 | ||
| } else { | ||
| val, err := util.AtoiNoOct(sectors.Value) | ||
| if err != nil { | ||
| util.StatusMessage(util.VERBOSITY_DEFAULT, | ||
| "* Warning: target specifies invalid non-integer "+ | ||
| "BOOTUTIL_MAX_IMG_SECTORS setting; assuming a "+ | ||
| "value of 128.\n") | ||
| maxImgSectors = 128 | ||
| } else { | ||
| maxImgSectors = val | ||
| } | ||
| } |
Contributor
There was a problem hiding this comment.
This does the same as previous block of code for MCU_FLASH_MIN_WRITE_SIZE. You could add private helper function which will validate the setting and return it's value (or default value if proper setting is not present). Helper would be used like this:
minWriteSz := t.getSettingIntValue(t.res.Cfg.Settings, "MCU_FLASH_MIN_WRITE_SIZE", 1)
maxImgSectors := t.getSettingIntValue(t.res.Cfg.Settings, "BOOTUTIL_MAX_IMG_SECTORS", 128)
where 1 and 128 are configurable default values returned in case of wrong/lack of syscfg.
wiktorkwiatkowski
force-pushed
the
target_build
branch
3 times, most recently
from
bc055e7 to
58ec2a8
Compare
m-gorecki
approved these changes
Oct 9, 2025
Boot trailer size was hardcoded to 128 sectors, ignoring the value set in syscfg. This caused mismatches between trailer size and the actual image size when BOOTUTIL_MAX_IMG_SECTORS was set to value other than 128, potentially making images not fit in the slot. Now the trailer size is calculated based on the syscfg value.
wiktorkwiatkowski
force-pushed
the
target_build
branch
from
58ec2a8 to
c27c0d0
Compare
kasjer
approved these changes
Oct 13, 2025
Contributor
kasjer
left a comment
kasjer
left a comment
There was a problem hiding this comment.
Verified to work correctly on STM32L4. Previously if image was close to slot size MCUBOOT failed to swap. Now image is reported as too big.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Boot trailer size was hardcoded to 128 sectors, ignoring the value set in syscfg. This caused mismatches between trailer size and the actual image size when
BOOTUTIL_MAX_IMG_SECTORSwas set to value other than 128, potentially making images not fit in the slot. Now the trailer size is calculated based on the syscfg value.