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

Add post-build hook white-list to exporters #3875

Merged
merged 1 commit into from Mar 6, 2017

Conversation

Projects
None yet
4 participants
@theotherjimmy
Contributor

theotherjimmy commented Mar 2, 2017

We have scripts (written in python) that are run after a binary image is
created in the tools. These scripts are not really exportable, as they
are part of the tools and may include and use any bits of python code
they please. So we don't export them. This patch disables export
combinations that would not work because the post-binary hook is not
exported. A white-list is used for forward compatibility.

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

@ilg-ul I added a white-list of supported post-binary hooks to the GNU ARM Eclipse exporter. Could you verify that It's correct?

@theotherjimmy theotherjimmy force-pushed the theotherjimmy:export-postbuild-whitelist branch Mar 2, 2017

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

In particular, this was triggered by the MTS_mDot_F411RE having a particularly involved post-binary hook.

Old support:

| Platform              | atmelstudio | cmsis | coide | ds5_5 | e2studio | eclipse_armc5 | eclipse_gcc_arm | eclipse_iar | embitz | gcc_arm | gnuarmeclipse | iar | kds | lpcxpresso | make_armc5 | make_gcc_arm | make_iar | simplicityv3 | sw4stm32 | uvision | uvision5 | zip |
| MTS_MDOT_F411RE       |      -      |   x   |   x   |   -   |    -     |       x       |        x        |      x      |   x    |    x    |       x       |  x  |  -  |     -      |     x      |      x       |    x     |      -       |    -     |    x    |    x     |  -  |

New support:

| Platform              | atmelstudio | cmsis | coide | ds5_5 | e2studio | eclipse_armc5 | eclipse_gcc_arm | eclipse_iar | embitz | gcc_arm | gnuarmeclipse | iar | kds | lpcxpresso | make_armc5 | make_gcc_arm | make_iar | simplicityv3 | sw4stm32 | uvision | uvision5 | zip |
| MTS_MDOT_F411RE       |      -      |   x   |   x   |   -   |    -     |       -       |        -        |      -      |   -    |    -    |       -       |  x  |  -  |     -      |     -      |      -       |    -     |      -       |    -     |    x    |    x     |  -  |
@ilg-ul

This comment has been minimized.

Contributor

ilg-ul commented Mar 2, 2017

Could you verify that It's correct?

I'm afraid I can't be of much help, I do not know when these hooks are used :-(

does your patch mean that only projects with TEENSY3_1Code.binary_hook will be exported?

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

does your patch mean that only projects with TEENSY3_1Code.binary_hook will be exported?

Yes. Additionally, targets that do not define a post-binary hook will be exported (this should include most targets).

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

The hooks are here: https://github.com/ARMmbed/mbed-os/blob/master/tools/targets.py#L337-L500

They are free to import anything though, so there may be some references to other files.

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

I do not know when these hooks are used :-(

The post-binary hooks are run by the build system after generating a .bin file from the .elf file.

@ilg-ul

This comment has been minimized.

Contributor

ilg-ul commented Mar 2, 2017

I understand 'targets that do not define a post-binary hook', but what does the TEENSY3_1Code.binary_hook exactly do?

generate the .bin file? if so, this is covered by the plug-ins, but it is not absolutely guaranteed, since the user can change the settings.

I'm not familiar with your flashing procedures, is the .bin mandatory?

my recommendation is to directly program the .elf, preferably with a J-Link; NUCLEO boards can be reprogrammed to implement J-Link instead of ST-LINK.

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

TEENSY3_1Code.binary_hook exactly do?

Generates an intel hex format executable. that's it.

I'm not familiar with your flashing procedures, is the .bin mandatory?

Most targets are capable of flashing .bin format files (no format really). This is much faster than flashing the other option, .hex which is formated as intel hex.

my recommendation is to directly program the .elf, preferably with a J-Link; NUCLEO boards can be reprogrammed to implement J-Link instead of ST-LINK.

If you are programming directly from the .elf and that's you expectation for the end user, we can add "MCU_NRF51Code.binary_hook" to the list, as they simply flash at an offset. The offset that they flash at is already part of the .elf file.

@ilg-ul

This comment has been minimized.

Contributor

ilg-ul commented Mar 2, 2017

Generates an intel hex format executable. that's it.

I guess the HEX is also generated by default, with the current configuration, but you need to check.

If you are programming directly from the .elf and that's you expectation for the end user, we can add "MCU_NRF51Code.binary_hook" to the list, as they simply flash at an offset.

I'm afraid these are mbed specifics, and I have no experience with them.

the GNU ARM Eclipse build plug-ins do not have any requirements, by default they generate whatever the toolchain generate, which for most toolchains is .elf, and also the plug-ins provide several extra steps to generate the listing, to generate a binary and to show the size (with all last 3 being optional).

the GNU ARM Eclipse debugging plug-ins (J-Link, OpenOCD and QEMU) usually take an ELF and directly program the flash, but again, this is plug-in / JTAG specific.

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

Thanks @ilg-ul.

Given that the intension is to use an Eclipse debugging plug-in, I'm going to add "MCU_NRF51Code.binary_hook" to the list, as running this hook is not needed if you flash using the ELF file.

Add post-build hook white-list to exporters
We have scripts (written in python) that are run after a binary image is
created in the tools. These scripts are not really exportable, as they
are part of the tools and may include and use any bits of python code
they please. So we don't export them. This patch disables export
combinations that would not work because the post-binary hook is not
exported. A white-list is used for forward compatibility.

@theotherjimmy theotherjimmy force-pushed the theotherjimmy:export-postbuild-whitelist branch to fcef9a7 Mar 2, 2017

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

/morph export-build

@ilg-ul

This comment has been minimized.

Contributor

ilg-ul commented Mar 2, 2017

I'm going to add "MCU_NRF51Code.binary_hook" to the list ... running this hook is not needed

you certainly know better. :-)

also please note that the Eclipse debugging plug-ins know nothing about bootloaders and such special configurations, and usually not mastering these details is a certain cause of failures.

@theotherjimmy

This comment has been minimized.

Contributor

theotherjimmy commented Mar 2, 2017

also please note that the Eclipse debugging plug-ins know nothing about bootloaders and such special configurations, and usually not mastering these details is a certain cause of failures.

Yeah. That's part of the motivation for this patch actually. Some bootloaders check CRCs that are added by post-binary hooks. This patch disables export for all targets like that.

@mbed-bot

This comment has been minimized.

mbed-bot commented Mar 2, 2017

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph export-build

Output

mbed Build Number: 132

All exports and builds passed!

@0xc0170

0xc0170 approved these changes Mar 6, 2017

@0xc0170 0xc0170 merged commit bc8e2ec into ARMmbed:master Mar 6, 2017

4 checks passed

Cam-CI uvisor Build & Test Success
Details
ci/morph-export-build Job has started
Details
continuous-integration/jenkins/pr-head This commit looks good
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@theotherjimmy theotherjimmy referenced this pull request Mar 6, 2017

Closed

Enable target-specific toolchain options hook #3894

0 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment