Add post-build hook white-list to exporters

[theotherjimmy]

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]

@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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[theotherjimmy]

/morph export-build

[ilg-ul]

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]

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]

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!