Skip to content

Fix expansion of application to target.restrict_size #14994

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

Closed

Conversation

icsys-omh
Copy link

Summary of changes

Fix expansion of application to target.restrict_size (#9949)

Without this, the binary for an application is not expanded to target.restrict_size. This means that if building a bootloader and an application, the application will not be placed correctly when combined with the bootloader binary, since the binary will be too small.

With this change, the bootloader binary is correctly expanded, and the application is hence located at the expected address, and buildling applications.

Inspired by #11043.

Impact of changes

I've also removed support for passing custom bytes to be used as padding from merge_region_list(), since it complicates this fix. This functionality appears unused internally, and I guess users are likely to use external tools if they need that kind of functionality.

Migration actions required

Documentation

None. This bring the actual functionality back to what's described in the bootloader docs.


Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

Reviewers


@ciarmcom ciarmcom added the release-type: patch Indentifies a PR as containing just a patch label Aug 11, 2021
@ciarmcom
Copy link
Member

@icsys-omh, thank you for your changes.
@ARMmbed/mbed-os-maintainers please review.

@ciarmcom ciarmcom requested a review from a team August 11, 2021 10:30
@0xc0170 0xc0170 requested a review from a team August 12, 2021 11:22
@ciarmcom ciarmcom added the stale Stale Pull Request label Aug 16, 2021
@ciarmcom
Copy link
Member

This pull request has automatically been marked as stale because it has had no recent activity. @ARMmbed/mbed-os-maintainers, @ARMmbed/mbed-os-core, please complete review of the changes to move the PR forward. Thank you for your contributions.

0xc0170
0xc0170 previously approved these changes Aug 16, 2021
@0xc0170 0xc0170 requested a review from a team August 16, 2021 13:56
@0xc0170 0xc0170 removed the stale Stale Pull Request label Aug 16, 2021
@0xc0170
Copy link
Contributor

0xc0170 commented Aug 17, 2021

Can you rebase your branch (icsys-omh:expand-application-to-restrict_size) ? I don't see here Github actions (travis was removed).

The test should be failing as this is touching frozen tools files (or regions.py was not?).

Supporting custom padding bytes complicates the code a lot, and appears
to be unused internally.

IntelHex will pad binary files as neccessary when writing, and supports
a custom byte for padding. However, merge_region_list() supported a
custom byte range for padding, which required a custom implementation.

The reason for removing was that this functionality complicated fixing
the expanding of the application to restrict_size, to fix ARMmbed#9949.
Without this, the binary for an application is not expanded to
target.restrict_size. This means that if building a bootloader and an
application, the application will not be placed correctly when combined
with the bootloader binary, since the binary will be too small.

With this change, the bootloader binary is correctly expanded, and the
application is hence located at the expected address. This fixes ARMmbed#9949.
@icsys-omh icsys-omh force-pushed the expand-application-to-restrict_size branch from 71b8acc to 6cd9e87 Compare August 17, 2021 12:25
@mergify mergify bot dismissed 0xc0170’s stale review August 17, 2021 12:26

Pull request has been modified.

@icsys-omh
Copy link
Author

@0xc0170 I just tried to rebase. Let me know if I didn't do it correctly.

@icsys-omh
Copy link
Author

@0xc0170 What should I do to move this PR forward?

@0xc0170
Copy link
Contributor

0xc0170 commented Aug 20, 2021

@ARMmbed/mbed-os-core will need to review as tools were frozen (see https://os.mbed.com/blog/entry/Introducing-the-new-Mbed-Tools/ Step 1).

@ciarmcom ciarmcom added the stale Stale Pull Request label Aug 25, 2021
@ciarmcom
Copy link
Member

This pull request has automatically been marked as stale because it has had no recent activity. @ARMmbed/mbed-os-core, please complete review of the changes to move the PR forward. Thank you for your contributions.

@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Aug 27, 2021
@ciarmcom ciarmcom added stale Stale Pull Request and removed stale Stale Pull Request labels Sep 3, 2021
@Patater
Copy link
Contributor

Patater commented Sep 8, 2021

@icsys-omh This PR unfortunately modifies files that are part of the old Mbed tools, which we've frozen bugs and all, so we can't accept this contribution. You can read more about why in this blog post..

I understand this is frustrating, as the replacement tools don't support yet bootloaders. We'd appreciate any support with adding bootloader support to the mbed-tools. Thanks!

@Patater Patater closed this Sep 8, 2021
@mergify mergify bot removed needs: review component: tools release-type: patch Indentifies a PR as containing just a patch labels Sep 8, 2021
@mergify mergify bot removed the stale Stale Pull Request label Sep 8, 2021
@0xc0170 0xc0170 mentioned this pull request Nov 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants