search

ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.68k stars 2.98k forks source link

GCC_ARM produces non contiguous FW image #13831

Closed moshe-shahar closed 3 years ago

moshe-shahar commented 4 years ago

Description of defect

On some targets, GCC_ARM produces a non-contiguous FW image. When building application and bootloader combine image in hex format, bootloader integrity checks failed to validate active FW.

Target(s) affected by this defect ?

Reproduced on K64F but can appear on many others

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM

What version of Mbed-os are you using (tag or sha) ?

mbed-os 15.1.0 to mbed-os 6.4.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

NA

How is this defect reproduced?

Build:

mbed import mbed-os-example-blinky
cd mbed-os-example-blinky
mbed add git@github.com:ARMmbed/mbed-bootloader-binaries.git bl
curl https://gist.githubusercontent.com/moshe-shahar/d0491058a8d8a35d23ea0d5ea6a17498/raw/mbed_app_with_bl.json -o mbed_app.json
mbed compile -m K64F -t ARM
mbed compile -m K64F -t GCC_ARM

Test:

  1. pyocd flash -M under-reset BUILD/K64F/ARM/mbed-os-example-blinky.hex or write something in 0xA810-0xA83F
  2. pyocd flash -M under-reset BUILD/K64F/GCC_ARM/mbed-os-example-blinky.hex

Results:

Mbed Bootloader
[DBG ] Active firmware integrity check failed
No Update image
[ERR ] Active firmware invalid
Failed to jump to application!

Note, the issue can't be reproduced with DAPLink because it erases the flash sectors and hides the problem.

moshe-shahar commented 4 years ago

Here is a suggested fix for K64F to that issue: https://github.com/ARMmbed/mbed-os/pull/13832

But, this issue probably exists on more targets (from a quick look, K66F too) and needs further investigation on how to prevent creating a non-contiguous application.

Another issue that may be hidden here is that when the combined Bootloader+App tool is calculating the App digest, it's using 0xFF value for the gap, which is by chance is the erase value in that target.

moshe-shahar commented 4 years ago

Thanks to @kjbracey-arm and @alzix for the support.

Here is additional info that may be useful: FILLing unused Memory with the GNU Linker.

ciarmcom commented 4 years ago

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers. Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2599

ciarmcom commented 3 years ago

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.