-
-
Notifications
You must be signed in to change notification settings - Fork 10
Fix: firwmare start address assumptions #69
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
Conversation
…e're working with and dispatching to a file-specific loader
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
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
a4cf39f to
a952aba
Compare
… so they're more sensible on use
…ogram_firmware()`
…oad address problem
esden
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks for the hard work. Let's keep moving! :D
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.