Skip to content

Enable split heap in K64F/K66F devices #10950

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

Merged
merged 3 commits into from
Jul 8, 2019

Conversation

artokin
Copy link
Contributor

@artokin artokin commented Jul 3, 2019

Description

-Enable MBED_SPLIT_HEAP for K64F and K66F
-Allow GCC_ARM toolchain to utilize remaining 64K memory area
-Make ARM toolchain to start memory filling from 64K region to leave
more space to bigger 192K region

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

Release Notes

-Enable MBED_SPLIT_HEAP for K64F and K66F
-Allow GCC_ARM toolchain to utilize remaining 64K memory area
-Make ARM toolchain to start memory filling from 64K region to leave
 more space to bigger 192K region.
@artokin artokin requested a review from kjbracey July 3, 2019 10:21
@artokin
Copy link
Contributor Author

artokin commented Jul 3, 2019

CI started.

@mbed-ci
Copy link

mbed-ci commented Jul 3, 2019

Test run: FAILED

Summary: 1 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_build-ARM

@OPpuolitaival
Copy link
Contributor

ARM build failed:
Error: L6220E: Execution region RW_m_data size (64272 bytes) exceeds limit (64256 bytes). Region contains 18 bytes of padding and 0 bytes of veneers (total 18 bytes of linker generated content).
Error: L6221E: Execution region RW_m_data with Execution range [0x1fff0500,0x20000010) overlaps with Execution region RW_m_data_2 with Execution range [0x20000000,0x20000858).

logs: http://mbed-os-ci.s3-website-eu-west-1.amazonaws.com/?prefix=jenkins-ci/ARMmbed/mbed-os/mbed-os-ci/PR-10950/artifacts/10950/1/build-ARM/FAIL/K64F/

When packing data into multiple regions using the `.ANY` directive,
the linker can accidentally overfill an area.

This doesn't normally happen because it defaults to
`--any_placement=worst_fit`, which puts data in the region with
most space.

When we prioritise regions with `.ANY1`/`.ANY2`, it may totally fill
an area, then fail to leave enough space for linker-generated veneers.
We've just seen this error with the new K64F linker map.

Adding `--any-contingency` makes it lower priority when a region is
98% full, avoiding this error.

The option should not have any effect on targets with scatter files
without prioritised `.ANY` directives.
@artokin
Copy link
Contributor Author

artokin commented Jul 3, 2019

Fix provided, CI started.

@mbed-ci
Copy link

mbed-ci commented Jul 3, 2019

Test run: FAILED

Summary: 2 of 11 test jobs failed
Build number : 2
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_cloud-client-test
  • jenkins-ci/mbed-os-ci_dynamic-memory-usage

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 4, 2019

Linker still reports a problem

Move heap_0 after .data as it is also placed to m_data.
@artokin
Copy link
Contributor Author

artokin commented Jul 8, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Jul 8, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 3
Build artifacts

@artokin artokin merged commit 3d65ace into ARMmbed:master Jul 8, 2019
@artokin artokin deleted the Update_freescale_K6xF_linker_files branch July 8, 2019 08:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants