This repository was archived by the owner on Feb 21, 2026. It is now read-only.
Fix: firwmare start address assumptions#69
Merged
Conversation
…e're working with and dispatching to a file-specific loader
|
Review changes with Changed Files
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #69 +/- ##
========================================
- Coverage 6.21% 6.11% -0.10%
========================================
Files 25 29 +4
Lines 3187 3237 +50
Branches 3187 3237 +50
========================================
Hits 198 198
- Misses 2969 3019 +50
Partials 20 20 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
esden
suggested changes
Dec 17, 2025
Member
esden
left a comment
esden
left a comment
There was a problem hiding this comment.
Great progress on this. Nice to have this abstracted nicely. Only a few comments on what could potentially be an improved? Curious what you think.
…/ modules for each of the file types
…stead of a `Vec<u8>` for the firmware data
…gments we care about for loading firmware
…om an ELF and completed the FirmwareStorage interface for ELFFirmwareFile
… debugging execution flow
…ad in to ensure it's not impossibly large
…er than decomposing the file
… image we're playing with
dragonmux
force-pushed
the
fix/firwmare-start-address-assumptions
branch
from
a4cf39f to
a952aba
Compare
… so they're more sensible on use
…ogram_firmware()`
…oad address problem
esden
approved these changes
Dec 17, 2025
Member
esden
left a comment
esden
left a comment
There was a problem hiding this comment.
LGTM, thanks for the hard work. Let's keep moving! :D
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
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 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.
In this PR we address the dual issues of the ELF container the firmware is read from being thrown away too quickly, and the guessed load address being wrong on parts that have the firmware start at someplace other than 0x08002000.
To address this we introduce a new
FirmwareFiletype andFirmwareStoragetrait that allowsbmputilto transparently hold firmware backed by an arbitrary file type and which knows how to determine, when available, the load address a file is intended for. This is then promulgated through toBmpDevice::download()to allow it to more smartly determine load address.The introduced
ELFFirmwareFiletype that implemented theFirmwareStoragetrait holds onto significantly more information about the ELF that was read in w/o discarding it, thus allowing the actual load address of the firmware to propagate properly. This type also implements proper loading of segments in a manner more conducive to correctly loading the firmware into Flash on the target even in the face of arbitrary section names appearing. It fills gaps between segments with the erased byte to create a contiguous firmware image.There are still a bunch of assumptions being made that need addressing, however this unblocks us enough on hardware bringup and allows
bmputilto be successfully used with other platforms such as Blackpill which also use a different firmware load address.NB: This change may break ABI, however it does so on functionality that should never have been exposed to the world. Hopefully the new visibilities for the new functionality is set correctly in relation to that.