Improve PSoC 6 post-build hooks, whitelist makefile export #9466

vmedcy · 2019-01-23T01:55:46Z

Description

Various improvements to the Cypress PSoC 6 post-build python hooks that bring compatibility with Cypress PSoC 6 boards (pull request pending). The fixes have no functional impact on FUTURE_SEQUANA port and enable export to makefile of PSoC 6 targeting projects.

This pull request addresses some review feedback from #8491 related to hex file discovery in the exported projects.

Pull request type

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

Reviewers

@theotherjimmy @lrusinowicz @orenc17

PSoC 6 hex files contain 4-byte chip ID at virtual offset 0x90500002 added by PSoC Creator or cymcuelftool from .cymeta ELF section. merge_images compares chip ID in CM0+ and CM4 hex files and raises an exception in case of mismatch. Chip ID is different for each MPN (for example, 0xE2072100 for CY8C6347BZI-BLD53 and 0xE2062100 for CY8C6247BZI-D54). CM0+ prebuilt images target CY8C6347BZI-BLD53 but should be compatible with other PSoC6 MPNs. Remove the check to enable merging CM0+ images with CM4 applications built for different MPNs, with empty or absent cymetadata.

Replace hard-coded numeric offsets of PSoC 6 hex file sections with sensible constants. Do not attempt to update the checksum and metadata contents if the sections are not found in the original HEX file.

Rename the existing PSoC-specific m0_core_img key in targets.json as a more generic hex_filename key. Update makefile exporter to select the subset of resources.hex_files matching the hex_filename value. Without this fix, multiple prebuilt CM0+ hex files are found in the target resources and erroneously passed to the srec_cat tool. The fix is generic so other targets that need post-build hex merging can use this key to pass the correct image to srecord tool. The fix also removes sub_target key: instead, rely hex_filename json key to detect if the hex image merging needs to be done. The sub_target is not used in mbed-os codebase for anything else. It is possible to override the hex file name in mbed_app.json: { "target_overrides": { "*": { "target.hex_filename": "my_custom_m0_image.hex" } }

ciarmcom · 2019-01-23T02:00:31Z

@vmedcy, thank you for your changes.
@theotherjimmy @orenc17 @ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-tools please review.

0xc0170 · 2019-01-23T09:04:03Z

Very good commit messages 👍

theotherjimmy

This is a breaking change: the prior definition of the PSoC6 will no longer work after these changes (mostly the rename of target.m0_core_img to hex_filename). Is this target released?

Yeah, but nobody used it in the online compiler, or outside of commenters on this PR

mikisch81 · 2019-01-23T15:32:01Z

c @orenc17 @alzix

vmedcy · 2019-01-23T16:51:59Z

@theotherjimmy:

This is a breaking change: the prior definition of the PSoC6 will no longer work after these changes (mostly the rename of target.m0_core_img to hex_filename). Is this target released?

I agree. The FUTURE_SEQUANA target was released with mbed-os-5.10.3. But the board is not yet available publicly, so the impact is limited to engineers working on preview version of the board AND customizing the "target.m0_core_img" in the mbed_app.json.

I dislike referencing target.m0_core_img in tools/export/makefile since the key name is too PSoC-specific.
I also dislike having different post-binary hooks for Cypress and Future PSoC 6 targets and only whitelisting Cypress hooks for makefile export (this functionality is critical for Cypress).
I believe renaming the key to hex_filename is a proper solution at this point of time.
I plan to submit similar change to tools/export/cmake whitelisting the PSOC6Code.complete hook, once this PR is approved.

lrusinowicz · 2019-01-23T17:18:42Z

@theotherjimmy:

This is a breaking change: the prior definition of the PSoC6 will no longer work after these changes (mostly the rename of target.m0_core_img to hex_filename). Is this target released?

I agree. The FUTURE_SEQUANA target was released with mbed-os-5.10.3. But the board is not yet available publicly, so the impact is limited to engineers working on preview version of the board AND customizing the "target.m0_core_img" in the mbed_app.json.

Agreed about the engineers affected. That's probably only me and @orenc17. Also, this is probably the last moment such a change could be pulled out.

I dislike referencing target.m0_core_img in tools/export/makefile since the key name is too PSoC-specific.

My point was that hex_filename was too generic, but on the other hand, using it works quite nicely in the makefile exporter.

I also dislike having different post-binary hooks for Cypress and Future PSoC 6 targets and only whitelisting Cypress hooks for makefile export (this functionality is critical for Cypress).

This, indeed, wouldn't make sense.

I believe renaming the key to hex_filename is a proper solution at this point of time.
I plan to submit similar change to tools/export/cmake whitelisting the PSOC6Code.complete hook, once this PR is approved.

vmedcy · 2019-01-23T17:23:59Z

@lrusinowicz: thank you for your feedback, this is nice that we are aligned on this.

lrusinowicz

I would consider changing this to generate warning only, rather than error, and to handle "no metadata" case to not generate warning. This way hex images for M0 fitting multiple targets could exists (without signature) and user at least will be warned when trying to use image targeting incompatible MPN.

vmedcy · 2019-01-23T19:15:33Z

@lrusinowicz I do not think metadata check should be performed, for various reasons:

Cypress deprecates the silicon ID in .cymeta section. This belongs to legacy PSoC Programmer / PSoC Creator programming flow. The new Cypress SW offerings (ModusToolbox and Cypress Programmer) do not perform any metadata injection / verification.
The same HEX file should easily work for multiple MPNs that belong to the same PSoC 6 device series. The warning can be confusing.
The check would only prevent a case when both M0+ and M4 HEX images contain metadata. When .cymeta section is missing in any of the images, ihex.tobinarray(start=0x90500002, ) will not work.
There are multiple (more significant) reasons why the CM0+ image might not work: invalid CY_CORTEX_M4_APPL_ADDR or FLASH/SRAM layout in the linker script.
toolchain.notify.info is not available in merge_images context, do not want to pass another message_func callback

lrusinowicz · 2019-01-23T21:00:46Z

@vmedcy
OK, if that's the case, especially point 1 which I was not aware off, then I have no more comments.

orenc17

Looks fine

theotherjimmy

I'm happy if we're confidant that very few people will be affected by the break.

theotherjimmy · 2019-01-24T15:22:54Z

I don't think anyone used the online compiler for this platform, so we should be good to go.

cmonr · 2019-01-25T20:29:57Z

CI started

mbed-ci · 2019-01-26T01:25:23Z

Test run: FAILED

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

Failed test jobs:

jenkins-ci/mbed-os-ci_greentea-test

0xc0170 · 2019-01-28T09:30:12Z

Test restarted

0xc0170 · 2019-01-28T09:31:24Z

I don't think anyone used the online compiler for this platform, so we should be good to go.

Just to confirm : this is fine for 5.11.4 (not 5.12) ?

theotherjimmy · 2019-01-28T15:44:06Z

@0xc0170 Correct. 5.11.4

The approach for the hex_files subset selection is identical to makefile exporter: #9466 Single hex file should be passed to srec_cat when hex_filename is set in targets.json or mbed_app.json.

The approach for the hex_files subset selection is identical to makefile exporter: ARMmbed#9466 Single hex file should be passed to srec_cat when hex_filename is set in targets.json or mbed_app.json.

vmedcy added 3 commits January 22, 2019 15:40

PSOC6.py: do not require metadata during HEX merging

5b0daad

Replace hard-coded numeric offsets of PSoC 6 hex file sections with sensible constants. Do not attempt to update the checksum and metadata contents if the sections are not found in the original HEX file.

ciarmcom requested review from orenc17, theotherjimmy and a team January 23, 2019 02:00

ciarmcom added the needs: review label Jan 23, 2019

theotherjimmy suggested changes Jan 23, 2019

View reviewed changes

lrusinowicz reviewed Jan 23, 2019

View reviewed changes

lrusinowicz approved these changes Jan 23, 2019

View reviewed changes

orenc17 approved these changes Jan 23, 2019

View reviewed changes

vmedcy mentioned this pull request Jan 24, 2019

Add Cypress PSoC 6 targets #9481

Merged

theotherjimmy approved these changes Jan 24, 2019

View reviewed changes

cmonr added needs: CI release-version: 5.11.4 and removed needs: review labels Jan 25, 2019

0xc0170 approved these changes Jan 28, 2019

View reviewed changes

0xc0170 added ready for merge and removed needs: CI labels Jan 28, 2019

cmonr merged commit 7f8ebc7 into ARMmbed:master Jan 28, 2019

cmonr removed the ready for merge label Jan 28, 2019

vmedcy mentioned this pull request Feb 19, 2019

PSOC6: enable export to CMake #9756

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve PSoC 6 post-build hooks, whitelist makefile export #9466

Improve PSoC 6 post-build hooks, whitelist makefile export #9466

vmedcy commented Jan 23, 2019

ciarmcom commented Jan 23, 2019

0xc0170 commented Jan 23, 2019

theotherjimmy left a comment •

edited

Loading

mikisch81 commented Jan 23, 2019

vmedcy commented Jan 23, 2019

lrusinowicz commented Jan 23, 2019

vmedcy commented Jan 23, 2019

lrusinowicz left a comment

vmedcy commented Jan 23, 2019

lrusinowicz commented Jan 23, 2019

orenc17 left a comment

theotherjimmy left a comment

theotherjimmy commented Jan 24, 2019

cmonr commented Jan 25, 2019

mbed-ci commented Jan 26, 2019

0xc0170 commented Jan 28, 2019

0xc0170 commented Jan 28, 2019

theotherjimmy commented Jan 28, 2019

Improve PSoC 6 post-build hooks, whitelist makefile export #9466

Improve PSoC 6 post-build hooks, whitelist makefile export #9466

Conversation

vmedcy commented Jan 23, 2019

Description

Pull request type

Reviewers

ciarmcom commented Jan 23, 2019

0xc0170 commented Jan 23, 2019

theotherjimmy left a comment • edited Loading

Choose a reason for hiding this comment

mikisch81 commented Jan 23, 2019

vmedcy commented Jan 23, 2019

lrusinowicz commented Jan 23, 2019

vmedcy commented Jan 23, 2019

lrusinowicz left a comment

Choose a reason for hiding this comment

vmedcy commented Jan 23, 2019

lrusinowicz commented Jan 23, 2019

orenc17 left a comment

Choose a reason for hiding this comment

theotherjimmy left a comment

Choose a reason for hiding this comment

theotherjimmy commented Jan 24, 2019

cmonr commented Jan 25, 2019

mbed-ci commented Jan 26, 2019

Test run: FAILED

0xc0170 commented Jan 28, 2019

0xc0170 commented Jan 28, 2019

theotherjimmy commented Jan 28, 2019

theotherjimmy left a comment •

edited

Loading