MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

Albrecht Markus Schellenberger — Thu, 05 Aug 2021 13:00:38 GMT

Thanks for your feedback, Nicolas!

I will be on vacation for the next couple of weeks. If you need more support concerning this issue, I recommend you creating a new case referring to this one. One of my colleagues will help you then.

Thanks and regards,

Markus

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

n.marty — Tue, 03 Aug 2021 10:18:16 GMT

Hi Markus

The MCUBoot child_image is added automatically when I set CONFIG_BOOTLOADER_MCUBOOT=y in my prj.conf. If I manually add a child_image within my project's CMakeLists.txt I get a "duplicated child image error".

The solution for me was to use add_overlay_config() instead of add_child_image() in my project's CMakeLists.txt.
add_overlay_config() is part of sdk-nrf/cmake/extensions.cmake

In the beginning, I manually modified the variable mcuboot_OVERLAY_CONFIG which created a mess (and the problem I initially observed). When using add_overlay_config() the variable gets updated correctly. Unfortunately, the guideline does not mention the usage of add_overlay_config() in order to inject kconfig overlay to a child image.

best regards

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

Albrecht Markus Schellenberger — Wed, 21 Jul 2021 13:07:59 GMT

Thanks a lot for your feedback, Nicolas. It is really appreciated.

[quote user="Nicolas Marty"]it is dropping the partition manager configuration "partition_manager_enabled.conf" for some reason which in my eyes is a bug.[/quote]

I’m not quite sure if this is a bug, really.

[quote user="Nicolas Marty"]What is the best practice to build MCUBoot with own configuration flags?[/quote]

Could you please follow this guideline and check if that would work for you? The child_image directory configuration mechanism is what we normally recommend to do.

Regards,

Markus

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

n.marty — Tue, 20 Jul 2021 10:41:13 GMT

Hi all

I found a hotfix for the problem which was actually a problem with the build configuration.

When applying my own mcuboot.conf to the mcuboot project (via cmake) like this
list(APPEND mcuboot_OVERLAY_CONFIG ${MY_MCUBOOT_CONF_FILE})

it is dropping the partition manager configuration "partition_manager_enabled.conf" for some reason which in my eyes is a bug.

My hotfix for the moment is to manually append the partition_manager config in addition to my "usual" mcuboot.conf. I do it now like this:
list(APPEND mcuboot_OVERLAY_CONFIG ${MY_MCUBOOT_CONF_FILE})
list(APPEND mcuboot_OVERLAY_CONFIG "/opt/zephyrproject/nrf/subsys/partition_manager/partition_manager_enabled.conf")

and it builds a working bootloader.

I would rather not deal with such a static, absolute path in my project because this is gonna break sooner or later again.

What is the best practice to build MCUBoot with own configuration flags?

best regards

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

n.marty — Mon, 19 Jul 2021 15:07:22 GMT

Hi Markus

I found the problem. As you said, the bootloader image had a problem. And this problem was introduced by the following CMake snippet which is part of our project CMakeLists.txt:

if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
list(APPEND mcuboot_OVERLAY_CONFIG
        "${CMAKE_CURRENT_SOURCE_DIR}/mcuboot.conf")
endif()

This worked fine for the previous version, but for 1.6 this is breaking the MCUBoot build configuration for some reason. Unfortunately I couldn't see any hint about a problem in the build output...

The intention of this script is to append project specific configuration to MCUBoot, namely which key to use for the signature check, which key algorithm, etc.

I am now looking for a solution to append my MCUBoot config without modifying the external source files.
Do you know how this can be done? Or anyone else has an idea?

best regards

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

Albrecht Markus Schellenberger — Fri, 16 Jul 2021 11:25:58 GMT

Thanks a lot for the feedback, Nicolas!

Something seems to be wrong with the bootloader image in your application, then. I’m afraid I can not tell you much more than this at the moment.

When building the application in NCS v1.6.0, does the compiler throw any warnings or something that is different compared to the build in NCS you are switching from?

Regards,

Markus

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

n.marty — Fri, 16 Jul 2021 07:29:13 GMT

I deleted the build directory and did a clean build. Unfortunately this did not help.

Next I tried to flash the MCUBoot from the http update sample wiith your provided command. The "failed reading sectors" error disappeard but it is still not able to find a bootable image:

Here's the output after flashing MCBoot only:
I: Starting bootloader
I: Primary image: magic=unset, swap_type=0x1, copy_done=_ok=0x3
I: Boot source: none
I: Swap type: none
E: Image in the primary slot is not valid!
E: Unable to find bootable image

best regards

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

Albrecht Markus Schellenberger — Thu, 15 Jul 2021 12:21:31 GMT

Hello Nicolas,

Have you already tried to do a fresh build by deleting the build folder and recompile the whole application?

If that doesn’t help you could give it a shot flashing the MCUboot only from the HTTP application update sample to a device with the failing application.

Can be done by using:

nrfjprog --program *.hex --sectorerase

File located in <build_dir>/mcuboot/zephyr/zephyr.hex

Regards,

Markus

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

n.marty — Thu, 15 Jul 2021 10:32:04 GMT

Attached below the contents of the partitions.yml. This corresponds to the configuration from my previous posts.

EMPTY_0:
  address: 0xc000
  end_address: 0x10000
  placement:
    before:
    - mcuboot_pad
  region: flash_primary
  size: 0x4000
app:
  address: 0x20200
  end_address: 0x88000
  region: flash_primary
  size: 0x67e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0x10000
  end_address: 0x10200
  placement:
    align:
      start: 0x8000
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0x10000
  end_address: 0x88000
  orig_span: &id001
  - app
  - mcuboot_pad
  - spm
  region: flash_primary
  sharers: 0x1
  size: 0x78000
  span: *id001
mcuboot_primary_app:
  address: 0x10200
  end_address: 0x88000
  orig_span: &id002
  - app
  - spm
  region: flash_primary
  size: 0x77e00
  span: *id002
mcuboot_secondary:
  address: 0x88000
  end_address: 0x100000
  placement:
    after:
    - mcuboot_primary
    align:
      start: 0x8000
  region: flash_primary
  share_size:
  - mcuboot_primary
  size: 0x78000
nrf_modem_lib_ctrl:
  address: 0x20010000
  end_address: 0x200104e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - spm_sram
    - start
  region: sram_primary
  size: 0x4e8
nrf_modem_lib_rx:
  address: 0x200124e8
  end_address: 0x200144e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_tx
  region: sram_primary
  size: 0x2000
nrf_modem_lib_sram:
  address: 0x20010000
  end_address: 0x200144e8
  orig_span: &id003
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x44e8
  span: *id003
nrf_modem_lib_tx:
  address: 0x200104e8
  end_address: 0x200124e8
  inside:
  - sram_nonsecure
  placement:
    after:
    - nrf_modem_lib_ctrl
  region: sram_primary
  size: 0x2000
otp:
  address: 0xff8108
  end_address: 0xff83fc
  region: otp
  size: 0x2f4
spm:
  address: 0x10200
  end_address: 0x20200
  inside:
  - mcuboot_primary_app
  placement:
    before:
    - app
  region: flash_primary
  size: 0x10000
spm_sram:
  address: 0x20000000
  end_address: 0x20010000
  inside:
  - sram_secure
  placement:
    after:
    - start
  region: sram_primary
  size: 0x10000
sram_nonsecure:
  address: 0x20010000
  end_address: 0x20040000
  orig_span: &id004
  - sram_primary
  - nrf_modem_lib_ctrl
  - nrf_modem_lib_tx
  - nrf_modem_lib_rx
  region: sram_primary
  size: 0x30000
  span: *id004
sram_primary:
  address: 0x200144e8
  end_address: 0x20040000
  region: sram_primary
  size: 0x2bb18
sram_secure:
  address: 0x20000000
  end_address: 0x20010000
  orig_span: &id005
  - spm_sram
  region: sram_primary
  size: 0x10000
  span: *id005

Thank you for looking into it.

best regards

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

Albrecht Markus Schellenberger — Thu, 15 Jul 2021 10:25:56 GMT

Hello Nicolas,

could you please provide me with the partitions.yml of the failing application? The file is located in the root of your build folder. I will have to check this with our development team.

Thanks and regards,

Markus

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

n.marty — Thu, 15 Jul 2021 06:49:23 GMT

Hi Markus

I am currently working on the nrf9160dk board and not using external flash. The device tree was not modified apart from some uart pin and spi configuration.

I read a little bit more about the MCUBoot upgrade strategies and tried different configurations just to see if anything works. Attached below the mcuboot config parameters which I add to the build.

CONFIG_BOOT_SIGNATURE_KEY_FILE="key_fw_sign.pem" # has to be a relative path
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
CONFIG_BOOT_SIGNATURE_TYPE_RSA_LEN=2048
CONFIG_BOOT_UPGRADE_ONLY=n # overwrite only is not what we want
CONFIG_BOOT_SWAP_USING_SCRATCH=n # not what we want as it requires reserved memory space "scratch area"
CONFIG_BOOT_SWAP_USING_MOVE=y # would be good as this does not require scratch memory area
CONFIG_BOOT_DIRECT_XIP=n # would be an alternative for us, supported by nrf91? leads to FLASH area overflow when enabled
#CONFIG_SINGLE_APPLICATION_SLOT=y Not what we want, not compatible with dfu

I tried to enable each UPGRADE_ONLY, SWAP_USINGE_SCRATCH, SWAP_USING_MOVE and DIRECT_XIP to find a mode which makes the application boot. The build was successful for the first three, the last one DIRECT_XIP didn't build because of a FLASH overflow.
None of the images resulted from the first three configurations were able to boot.

My configuration is based on this sample https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/http_update/application_update/README.html#http-application-update-sample

When I try to build and run the sample with sdk v1.6.0 it works. It seems to be a problem within my application/configuration.

I am stuck on this. Any idea?

best regards

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

Albrecht Markus Schellenberger — Thu, 15 Jul 2021 05:49:36 GMT

Thanks for the feedback, Nicolas!

Are you using an external flash with your device/board?

Regards,

Markus

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

n.marty — Wed, 14 Jul 2021 15:09:26 GMT

Hi Markus

The problem occurs after i flash the board with "west flash --erase ..." (nrfjprog). So MCUBoot and application image should originate from the same nrf-sdk.

I don't know which swap type config I am using to be honest. I let it at default configuration. After an upgrade I am required to call boot_write_img_confirmed() in order to keep it booting from the upgraded image. I want to keep that mechanism to perform some selftests before confirming.

This is my kconfig about OTA:
CONFIG_IMG_MANAGER=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y
CONFIG_REBOOT=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_FOTA_DOWNLOAD=y
CONFIG_DOWNLOAD_CLIENT=y
CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096
CONFIG_DFU_TARGET=y
CONFIG_DFU_TARGET_MCUBOOT=y

Looking at autoconf.h after the build is finished I can't find any of these boot type definitions.

best regards

RE: MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

Albrecht Markus Schellenberger — Wed, 14 Jul 2021 11:34:23 GMT

Hello Nicolas,

does the MCUBoot on the failing device originate from the same version of the nrf-sdk? What kind of boot swap are you using?

Regards,

Markus