You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The flash, or possibly other memory devices, area partitioned via DTS, and such partitioning may be applied via multiple overlays, which allows to create overlaying partitions or accidentally left some space unassigned.
The feature would not affect build in any other way than just displaying information, without categorizing anything as problem.
Describe the solution you'd like
I would like to propose to improve gen_defines.py or add additional script that would parse the final DTS file and
print table of enabled ("status" == "okay") memory devices, for example flash, with partitions that are created on them (and enabled), information on space that has not been allocated, and overlapping allocations.
The list may be similar to the fdisk output, or similar tool for Linux/Unix; or be something similar to:
Device flash0 at flash-controller@4001e000 allocation:
DTS Label Offset Size Overlaps
mcuboot 0x0000 0x0c000
image-1 0x0c000 0x02000 image-1, single
image-2 0x0d000 0x02000 single, image-2
single 0x0c000 0x04000 image-1, image-2
<unused> 0x10000 0x10000
storage 0x20000 0x02000
Device (...):
...
Describe alternatives you've considered
There is not such solution within Zephyr yet, the closest possible solution is proposed by @JordanYates#33656, but it is more related to fixing problems with compilation and linking. Note that the PR is actually presenting table of "regions" at the build completion, but is is slightly different as it presents how much of flash has been designated for "region" and how much will be occupied according to linker output.
Additional context
Here are pull requests that are trying to fix problem with compiler/linker being unaware of boundaries the app should be fit to; they are not directly impacted or impacting the feature but they are working with similar issue, but with different impact on build: @carlocaione's #35460 @JordanYates' #33656
The text was updated successfully, but these errors were encountered:
This issue, marked as an Enhancement, was opened a while ago and did not get any traction. It was just assigned to you based on the labels. If you don't consider yourself the right person to address this issue, please re-assing it to the right person.
Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.
@de-nordic you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.
Is your feature request related to a problem? Please describe.
The flash, or possibly other memory devices, area partitioned via DTS, and such partitioning may be applied via multiple overlays, which allows to create overlaying partitions or accidentally left some space unassigned.
The feature would not affect build in any other way than just displaying information, without categorizing anything as problem.
Describe the solution you'd like
I would like to propose to improve gen_defines.py or add additional script that would parse the final DTS file and
print table of enabled ("status" == "okay") memory devices, for example flash, with partitions that are created on them (and enabled), information on space that has not been allocated, and overlapping allocations.
The list may be similar to the
fdisk
output, or similar tool for Linux/Unix; or be something similar to:Describe alternatives you've considered
There is not such solution within Zephyr yet, the closest possible solution is proposed by @JordanYates #33656, but it is more related to fixing problems with compilation and linking. Note that the PR is actually presenting table of "regions" at the build completion, but is is slightly different as it presents how much of flash has been designated for "region" and how much will be occupied according to linker output.
Additional context
Here are pull requests that are trying to fix problem with compiler/linker being unaware of boundaries the app should be fit to; they are not directly impacted or impacting the feature but they are working with similar issue, but with different impact on build:
@carlocaione's #35460
@JordanYates' #33656
The text was updated successfully, but these errors were encountered: