• State Verified Answer
  • Replies 4 replies
  • Subscribers 69 subscribers
  • Views 1837 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 233530
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

"Unable to find bootable image" -- SPM not being merged into mcuboot_primary_app.hex?

jbrzozoski

I (unfortunately) had to make my own forks of Zephyr and NRF to get around a build issue, and decided to implement a west.yml manifest in my application repository.  I made this change, then re-ran "west init" and "west update" in a new working directory to download new git clones of everything.  I updated my ZEPHYR_BASE environment variable, and was able to build with "west build -b nrf9160_pca10090ns ." in the new directory just fine, but when I load the application with "west flash -d build" it stops after MCUBoot with this:

***** Booting Zephyr OS v1.14.99-ncs1-1076-g582aa88991ba *****
[00:00:00.006,744] <inf> mcuboot: Starting bootloader
[00:00:00.015,167] <inf> mcuboot: Primary image: magic=unset, copy_done=0x3, image_ok=0x3
[00:00:00.026,458] <inf> mcuboot: Scratch: magic=unset, copy_done=0x50, image_ok=0x3
[00:00:00.037,139] <inf> mcuboot: Boot source: primary slot
[00:00:00.048,248] <inf> mcuboot: Swap type: none
[00:00:00.054,992] <err> mcuboot: Unable to find bootable image

I've spent all morning double and triple-checking that there are no differences between the old and new directory trees.  I've done "git clean -dxf" followed by recursive diffs, and found nothing different (outside of the .git directories).  The exact tag/reference names being used to check out some directories differ between the two, but the commit hashes are the same on both.

I checked the environment variables before each build to ensure that wasn't an issue.  (I learned that running zephyr-env.sh adds a script directory to the path, so if you re-use the same shell instance for builds in different Zephyr base directories you will likely be using the wrong script directory. But that wasn't my issue...)

I compared the build/zephyr/.config output between each directory, and found no differences other than ordering.

I captured a full "west build" output of a fresh build from each directory.  I searched both to make sure neither ever mentioned the other directory.  I edited out the differences I could explain (search-and-replace directory paths, remove ninja step numbers) and then ran a diff on the sorted outputs of both logs.  It found only 2 things different:

  1. The size of the FLASH region reported when linking zephyr/zephyr_prebuilt.elf *decreased* by 340 bytes in the new version.
  2. When merging zephyr/mcuboot_primary_app.hex it did not include spm/zephyr/zephyr.hex in the new version (but did in the old)

I'm still digging, trying to find why the merge dependency changed.  I'm guessing it is my issue since mcuboot could be looking in the wrong place or at an incomplete image without that hex file included.

If anyone else has ever bumped into this or has any suggestions of places to look, please speak up.

  • 0

    The Zephyr tag in that console output looks like I'm out in the weeds. A better description is "v1.14.99-ncs2-1-g582aa88991ba".  My build in the "good" directory reports that shorter description.  My failing build reports it funny since I didn't copy the tags properly when I forked Zephyr, so it had to go *way* back to find the most recent prior.  In general, I'm on NRF v1.0 plus one tiny change that is a workaround for this error.

  • 0

    I am becoming convinced that this is coming down to either config or include ordering.  I removed the build output directory, and ran just "west build -b nrf9160_pca10090ns --cmake-only" and I can already see a difference in the pm.config.  In the good one:

    PM_MCUBOOT_PRIMARY_APP_SPAN="app spm"

    And in the bad one:

    PM_MCUBOOT_PRIMARY_APP_SPAN="app"

    I'm having a bit of trouble decoding who generates pm.confg.  Now I need to read the partition manager scripts to figure out what went wrong.

  • +1

    Okay, found the problem...  The specific order of the modules in the west.yml MATTERS.

    I had put the NRF module at the bottom. 

    The manifest order affects the order of the listing in build/zephyr_modules.txt generated by zephyr_module.py.

    The order of zephyr_modules.txt affects the order of command line options to partition_manager.py, which affected the partitions config in subtle ways.

    And that broke my build.

    The fix was to move the NRF module to the top of the west.yml listing.

  • 0

    And one more useful snippet of information I learned today: if you want super-verbose build output when your issue is possibly rooted in cmake, use this:

    west -v build -b nrf9160_pca10090ns -- --trace &> build.log

    Change the board config to match yours, of course...  And be ready to slog through multi-megabyte build logs.

Related