flashgen.py: allow loading arbitrary binaries into flash images using --otdesc
#207
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
rivos-eblot
requested changes
Oct 2, 2025
Currently the `otdesc` option accepts an address for a binary and then attempts to guess whether the binary is a ROM_EXT or a bootloader file, loading it at the hard-coded offsets. With the result of `opentitantool image assemble` it would instead be more useful to place binaries arbitrarily, wherever we wish, even across flash banks to support mirrored flash images. This commit changes the `otdesc` option to just load the given data at the given offset provided it does not exceed the maximum flash size. This option is basically converted to mean "place this data at this location, without care for what it is". For now, use of ELFs for debug symbol support is dropped from the `otdesc` option, because binaries can be loaded that are not ROM_EXTs or bl0s as defined in the flash format. In the future, the flash format should be updated to support an arbitrary number of convenience debugging ELFs, and then this option can be added back, but support for this is dropped for now when using this option (debug ELFs still remain if loading ROM_EXT and bl0 files the normal way). Signed-off-by: Alex Jones <alex.jones@lowrisc.org>
AlexJones0
force-pushed
the
arbitrary_flash_imgs
branch
from
0549b33 to
9028353
Compare
jwnrt
reviewed
Oct 2, 2025
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.
Currently, the
--otdescoption accepts an address for a binary, and then attempts to guess whether the binary is a ROM_EXT or a bootloader file, loading it at hard-coded offsets with relevant size and ELF checks etc. This is not hugely useful and primarily exists for compatibility with theopentitantool image assembleformat (it is unclear whether anything still uses this, I don't think so though).Currently,
opentitantool image assembleis being used within OpenTitan to construct an image spanning both flash banks; it is more useful inflashgen.pyto be able to place binaries (or any data) of any size at any arbitrary location in flash, so long as it does not exceed the flash capacity. This commit modifies this option to mean "place this data at this location, without care for what it is".For now, use of ELFs for debug symbol support is dropped from the
--otdescoption, because binaries can be loaded which are not ROM_EXTs or bl0s as defined in the flash format (e.g. further boot stages). The flash format currently hardcodes ELFs to only support ROM_EXT and bl0 ELFs in specific locations (also see #193). An ideal solution to this issue would update the flash format in the future to support an arbitrary number of convenience debugging ELFs, at which point this option can be added back, but for now this PR drops support for this option (for--otdesconly, not for--execand--boot) to prioritise debugging of ROM_EXT tests on Earlgrey.Aside: in the future it might be nice to extend this to also support placing binaries in INFO pages to essentially support splicing of flash info pages.