Unexpected warning message: partition_manager.cmake says I do not use pm_static.yml, even though it is there.

Hello,

I am using a nRF5340 with mcuboot and multiple customer-specific partitions.
I did not finish creating a separate board definition yet. Currently, we are using the nRF5340-DK board definition and remove development kit specific items while adding our components. Just for reference.
Concerning the partitions, I created pm_static.yml in out project's base directory (where src/, build/ and child_image/ directories also reside). The partition handling seemed to work in our main application.

When I perform a pristine build, I receive an error message, telling me that I would not use a static partition configuration (pm_static.yml). although it is there.

[{  "resource": "/c:/ncs/v2.5.2/nrf/cmake/partition_manager.cmake",
    "owner": "nrf-connect",
    "severity": 4,
    "message": "CMake Warning at C:/ncs/v2.5.2/nrf/cmake/partition_manager.cmake:79 (message):",
    "source": "cmake",
    "startLineNumber": 79,
    "startColumn": 1,
    "endLineNumber": 79,
    "endColumn": 2147483647
}]

...and if I double-click on the message, I see this piece of code in partition_manager.cmake:

if (NOT static_configuration AND
  (CONFIG_BOOTLOADER_MCUBOOT OR CONFIG_SECURE_BOOT))
      message(WARNING "
        ---------------------------------------------------------------------
        --- WARNING: Using a bootloader without pm_static.yml.            ---
        --- There are cases where a deployed product can consist of       ---
        --- multiple images, and only a subset of these images can be     ---
        --- upgraded through a firmware update mechanism. In such cases,  ---
        --- the upgradable images must have partitions that are static    ---
        --- and are matching the partition map used by the bootloader     ---
        --- programmed onto the device.                                   ---
        ---------------------------------------------------------------------
        \n"
      )
endif()

What went wrong here? Is my pm_static.yml applied successfully?

Best regards,
Michael

  • The thing is:

    When you enable MCUboot on the application core, and use the network core, the network core bootloader known as b0n or netboot will be automatically included for the network core image.

    This takes the form of CONFIG_SECURE_BOOT for the network core image.
    The build runs multiple build loops for each image.
    When the network core build loop is ran, CONFIG_SECURE_BOOT is therefore true for this image, but somehow it does not have knowledge about static partitioning.

    This means that if you build without pm_static.yml, you should get two warnings about static partitioning, right?

    For a workaround, you can simply ignore the second pm_static warning you get.

    For a long-time fix, I will create a PR soon to fix this, when I figure out the best way to fix it.
    This PR will then become part of future versions of the nRF Connect SDK.

    Does this work for you?

  • Update:

    I have found that you need will need to do static partitioning on the network core after all, as changing of the network core parittioning could cause errors.

    I have not found a good way to do this on v2.6.0, so suggest that you add pm_static.yml to ncs/zephyr/samples/bluetooth/hci_ipc/ for now.

    In v2.7.0 Sysbuild will come, and then that can likely be used for this.

    Please confirm that you read my message

  • Hi Sigurd, thanks for your support and sorry for being a bit busy...

    I didn't have time to remove static partitioning yaml again, but I think there was another warning message when I was using the automatically generated partitions.

    Maybe the network core is not aware of static partitioning because I do not implement network core code (everything is auto.generated by the nRF Connect SDK, I just define characteristics etc. in the application core).
    Do you agree that there is no risk having the network core being compiled without static partitioning in this case? Or could this affect future software updates for the network core via mcuboot / mcumgr?

    I'm looking forward to 2.7.0 then. Hope this does not add more bug risks. Will 2.7.0 be produktion ready? Or should we rather stay at 2.5.2 (currently being used) or switch over to 2.6.0?

    Best regards,
    Michael

  • puz_md said:
    Maybe the network core is not aware of static partitioning because I do not implement network core code (everything is auto.generated by the nRF Connect SDK, I just define characteristics etc. in the application core).
    Do you agree that there is no risk having the network core being compiled without static partitioning in this case? Or could this affect future software updates for the network core via mcuboot / mcumgr?

    Unfortunately, it is the opposite.

    Our out of the box network core code (likely hci_ipc) does not have static partitioning by default.
    As long as you do not change anything, the partitioning should be the same.

    But if we hypothetically were to change the partitioning of the hci_rpmsg sample (with b0n) in the future, that may impact your network core DFU if you do not manually add static partitioning to that.

    The important part is not that you use static partitioning now, but that the partitioning is the same when you do updates. That is what static partitioning does: it makes sure that your partitioning never changes.

    puz_md said:
    Will 2.7.0 be produktion ready?

    What exactly do you mean by that?

    puz_md said:
    Or should we rather stay at 2.5.2 (currently being used) or switch over to 2.6.0?

    That is up to you.

    You can still use static partitioning if you update by the workaround I described below

    Sigurd Hellesvik said:
    so suggest that you add pm_static.yml to ncs/zephyr/samples/bluetooth/hci_ipc/ for now.
  • Hi Sigurd,

    this is becoming a rather tricky issue...

    With "production ready", I meant that the SDK version is stable and approved for shipping products to our customers based on this SDK version. We plan do deliver first samples to our customers in a couple of weeks and the software should be upgradeable, which means that at least the basic bootloader and partitioning framework should work reliably. I'm getting a bit cold feet right now...

    If I understand your words correctly, this means that the net core also uses different partitions, even if we don't use dual slots there? I assumed b0n would have a defined size, and all the remaining net core flash would be used for the net core application...

    Concerning the workaround you suggested:

    1. You say I should add pm_static.yml to the net core. But my pm_static.yml does not define any memory space in the net core memory region, but only the slots for mcuboot and some reserved / customer specific regions in the app core's flash memory. If I remember correctly, my pm_static.yml is based on the automatically generated partitioning file, just like described in the tutorials. So, what exactly should be the content of the pm_static.yml for the net core?

    2. You suggested to add pm_static.yml to ncs/zephyr/samples/bluetooth/hci_ipc/ - does this mean that when I enable Bluetooth in prj.conf, the build system compiles this sample (!!!) into my code?

    3. Can I also place the pm_static.yml into a subdirectory in my project directory, so that I don't have to modify the toolchain directory? e.g. <proj-dir>/child_image/pm_static_hci_ipc.yml or something like this?

    Best regards,
    Michael

Related