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

Parents
  • Hello Michael,

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

    Interesting. I added this warning, so I would very much like to figure out why it is wrong.

    Could you add the following in partition_manager.cmake, just before the if()?

    message("PUT A LOT OF STUFF HERE SO WE EASILY CAN FIND THIS IN THE LOGS AAAAAAAAAAAAAAAAAAAAAAAAAAAA")
    message("Static configuration: ${static_configuration}")
    message("CONFIG_BOOTLOADER_MCUBOOT: ${CONFIG_BOOTLOADER_MCUBOOT}")
    message("CONFIG_SECURE_BOOT: ${CONFIG_SECURE_BOOT}")
    message("PUT A LOT OF STUFF HERE SO WE EASILY CAN FIND THIS IN THE LOGS AAAAAAAAAAAAAAAAAAAAAAAAAAAA")
    if (NOT static_configuration AND
    ...

    Regards,
    Sigurd Hellesvik

  • Hi Sigurd,

    sorry for the delay, I was very busy over the last weeks and just came back from a short holiday today.

    I also tried our your test code:

    === child image b0n - CPUNET (inherited) end ===
    
    CMake Warning at C:/ncs/v2.5.2/nrf/subsys/bootloader/cmake/debug_keys.cmake:36 (message):
      
    
          --------------------------------------------------------------
          --- WARNING: Using generated NSIB public/private key-pair. ---
          --- It should not be used for production.                  ---
          --- See CONFIG_SB_SIGNING_KEY_FILE                         ---
          --------------------------------------------------------------
          
    
    Call Stack (most recent call first):
      C:/ncs/v2.5.2/nrf/subsys/bootloader/cmake/provision_hex.cmake:47 (include)
      C:/ncs/v2.5.2/nrf/subsys/CMakeLists.txt:20 (include)
    
    
    -- libmetal version: 1.4.0 (C:/ncs/v2.5.2/zephyr/samples/bluetooth/hci_rpmsg)
    -- Build type:  
    -- Host:    Windows/AMD64
    -- Target:  Generic/arm
    -- Machine: arm
    -- Looking for include file stdatomic.h
    -- Looking for include file stdatomic.h - found
    -- Host:    Windows/AMD64
    -- Target:  Generic/arm
    -- Machine: arm
    -- C_FLAGS :  -Wall -Wextra
    -- open-amp version: 1.4.0 (C:/ncs/v2.5.2/modules/lib/open-amp/open-amp)
    -- Looking for include file fcntl.h
    -- Looking for include file fcntl.h - found
    PUT A LOT OF STUFF HERE SO WE EASILY CAN FIND THIS IN THE LOGS AAAAAAAAAAAAAAAAAAAAAAAAAAAA
    Static configuration: 
    CONFIG_BOOTLOADER_MCUBOOT: 
    CONFIG_SECURE_BOOT: y
    PUT A LOT OF STUFF HERE SO WE EASILY CAN FIND THIS IN THE LOGS AAAAAAAAAAAAAAAAAAAAAAAAAAAA
    CMake Warning at C:/ncs/v2.5.2/nrf/cmake/partition_manager.cmake:84 (message):
      
    
              ---------------------------------------------------------------------
              --- 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.                                   ---
              ---------------------------------------------------------------------
              
    
    Call Stack (most recent call first):
      C:/ncs/v2.5.2/zephyr/cmake/modules/kernel.cmake:247 (include)
      C:/ncs/v2.5.2/zephyr/cmake/modules/zephyr_default.cmake:138 (include)
      C:/ncs/v2.5.2/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:66 (include)
      C:/ncs/v2.5.2/zephyr/share/zephyr-package/cmake/ZephyrConfig.cmake:92 (include_boilerplate)
      CMakeLists.txt:5 (find_package)
    
    
    -- Configuring done
    -- Generating done
    -- Build files have been written to: C:/my_project_dir/build/hci_rpmsg
    === child image hci_rpmsg - CPUNET end ===
    
    -- Found Python3: C:/ncs/toolchains/c57af46cb7/opt/bin/python.exe (found version "3.8.2") found components: Interpreter 
    
    === child image mcuboot -  begin ===

    I wonder why secure boot is enabled in the debug output, and mcuboot is not enabled even though I use ist. I do not use TFM or non-secure code.

    This is my prj.conf:

    CONFIG_PRINTK=y
    CONFIG_ASSERT=y
    CONFIG_GPIO=y
    CONFIG_ZERO_LATENCY_IRQS=y
    
    CONFIG_FLASH=y
    CONFIG_FLASH_PAGE_LAYOUT=y
    CONFIG_MPU_ALLOW_FLASH_WRITE=y
    
    CONFIG_USB_DEVICE_STACK=y
    CONFIG_USB_DEVICE_PRODUCT="My Product"
    CONFIG_USB_DEVICE_MANUFACTURER="My Company"
    CONFIG_USB_DEVICE_SN="unknown"
    #CONFIG_USB_DEVICE_VID=0x2FE3
    CONFIG_USB_DEVICE_PID=0x0004
    CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=y
    
    CONFIG_SERIAL=y
    CONFIG_CONSOLE=y
    CONFIG_UART_CONSOLE=y
    CONFIG_UART_LINE_CTRL=y
    CONFIG_UART_INTERRUPT_DRIVEN=y
    
    CONFIG_BT=y
    CONFIG_BT_PERIPHERAL=y
    CONFIG_BT_DEVICE_NAME="My Device"
    CONFIG_BT_HCI=y
    
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
    
    CONFIG_BOOTLOADER_MCUBOOT=y
    CONFIG_BUILD_WITH_TFM=n
    
    CONFIG_MCUMGR=y
    CONFIG_MCUMGR_GRP_OS=y
    CONFIG_MCUMGR_GRP_IMG=y
    CONFIG_MCUMGR_TRANSPORT_UART=y
    
    # Configure dependencies for mcumgr
    CONFIG_NET_BUF=y
    CONFIG_ZCBOR=y
    CONFIG_FLASH=y
    CONFIG_IMG_MANAGER=y
    CONFIG_STREAM_FLASH=y
    CONFIG_FLASH_MAP=y
    CONFIG_BASE64=y
    

    Best regards,

    Michael

  • 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

  • puz_md said:
    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...

    In this case I think I would recommend to stay at your current NCS version for now.

    Bootloader and DFU functionality will in the end be the same for both versions, so as you say: When you got working DFU now, you could always update NCS version later.

    puz_md said:
    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?

    Yes, the network core also have a partitioning layout:

    puz_md said:
    I assumed b0n would have a defined size, and all the remaining net core flash would be used for the net core application

    Set here, so as you see it is configurable.
    We could also technically change it on our side, although I think Nordic will strive to never do that. But you should make sure that even in an unlikely even of something like that, your project will not be impacted.

    puz_md said:
    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?

    You will have two pm_static.yml files. I will list them as "COPY FROM -> COPY TO"

    • build/partitions.yml -> project/pm_static.yml
    • build/hci_rpmsg/partitions_CPUNET.yml -> ncs/zephyr/samples/bluetooth/hci_rpmsg/pm_static.yml
    puz_md said:
    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?

    Yes. Either hci_ipc (v2.6.x and above) or hci_rpmsg (v2.5.x and lower), or potentially others. See nRF5340: Multi-image builds

    Also from build log:

    puz_md said:
    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?

    Unfortunally, no. Not yet.
    This will be a feature in v2.7.0 with sysbuild, but I recommend that you set it in the NCS manually first, since you say you are low on time.
    Then you can make it pretty later.

    In the end:
    If you save your whole build folder of the version you program to devices in the release, and make sure to thoroughly test an update in the lab before sending it over DFU to devices in the field, you should not get any issues with partitioning that you cannot fix later.

    Btw, do you use external flash? (I will explain why this is a bit relevant based on your answer)

Reply
  • puz_md said:
    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...

    In this case I think I would recommend to stay at your current NCS version for now.

    Bootloader and DFU functionality will in the end be the same for both versions, so as you say: When you got working DFU now, you could always update NCS version later.

    puz_md said:
    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?

    Yes, the network core also have a partitioning layout:

    puz_md said:
    I assumed b0n would have a defined size, and all the remaining net core flash would be used for the net core application

    Set here, so as you see it is configurable.
    We could also technically change it on our side, although I think Nordic will strive to never do that. But you should make sure that even in an unlikely even of something like that, your project will not be impacted.

    puz_md said:
    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?

    You will have two pm_static.yml files. I will list them as "COPY FROM -> COPY TO"

    • build/partitions.yml -> project/pm_static.yml
    • build/hci_rpmsg/partitions_CPUNET.yml -> ncs/zephyr/samples/bluetooth/hci_rpmsg/pm_static.yml
    puz_md said:
    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?

    Yes. Either hci_ipc (v2.6.x and above) or hci_rpmsg (v2.5.x and lower), or potentially others. See nRF5340: Multi-image builds

    Also from build log:

    puz_md said:
    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?

    Unfortunally, no. Not yet.
    This will be a feature in v2.7.0 with sysbuild, but I recommend that you set it in the NCS manually first, since you say you are low on time.
    Then you can make it pretty later.

    In the end:
    If you save your whole build folder of the version you program to devices in the release, and make sure to thoroughly test an update in the lab before sending it over DFU to devices in the field, you should not get any issues with partitioning that you cannot fix later.

    Btw, do you use external flash? (I will explain why this is a bit relevant based on your answer)

Children
  • I've put the following in CMakeLists.txt to get it working:

    # Set signature key for application core bootloader (MCUBoot)
    set(mcuboot_CONFIG_BOOT_SIGNATURE_KEY_FILE \"${CMAKE_CURRENT_SOURCE_DIR}/keys/mcuboot-private-ecdsa-p256.pem\")
    
    # Set signature key for network core bootloader (B0n)
    set(hci_ipc_CONFIG_SB_SIGNING_KEY_FILE \"${CMAKE_CURRENT_SOURCE_DIR}/keys/b0n-private-ecdsa-p256.pem\")
    
    # Set static partition manager configuration for application core
    set(PM_STATIC_YML_FILE ${CMAKE_CURRENT_SOURCE_DIR}/configuration/${BOARD}/pm_static_cpuapp.yml)
    
    # Set static partition manager configuration for network core
    set(hci_ipc_PM_STATIC_YML_FILE ${CMAKE_CURRENT_SOURCE_DIR}/configuration/${BOARD}/pm_static_cpunet.yml)

  • Sigurd,

    I have been working through this warning, and your suggestion of copying the file from build/hci_rpmsg/partitions_CPUNET.yml to ncs/zephyr/samples/bluetooth/hci_rpmsg/pm_static.yml does resolve the warning.

    I am using external flash and am curious as to what you were planning on explaining above.

    Thank you.

  • It is 4 months since I wrote that, so unfortunately I can no longer remember what my point was

  • Hi, let me summarize how I resolved the issue on my side:

    1. SDK v2.5.3 via multi-image build

    The only solution was to put a pm_static.yml file directly into the net core sample's directory (e.g. C:\ncs\v2.5.3\zephyr\samples\bluetooth\hci_rpmsg\pm_static.yml). This is kind of dirty because the static partitioning will be used by all projects compiled on this computer. Further, there is a risk if someone else pulls the project from the repository and forgets to update their SDK directory with the pm_static-yml, the code will link to the wrong location.

    2. SDK v2.9.0 via sysbuild

    Create the following line(s) in sysbuild.cmake in your project directory. It will use pm_static_NETCORE in your project directory as the net core's static partitioning file.

    set(hci_ipc_PM_STATIC_YML_FILE ${APPLICATION_CONFIG_DIR}/pm_static_CPUNET.yml CACHE INTERNAL "" FORCE)
    message(STATUS "sysbuild.cmake - hci_ipc_PM_STATIC_YML_FILE: ${hci_ipc_PM_STATIC_YML_FILE}")

    Further, there is a bug in the SDK that must be fixed for the lines mentioned above to work as expected: Go to C:\ncs\v2.9.0\nrf\cmake\sysbuild\partition_manager.cmake, line 126, and comment out the following instruction with a hashtag:

    #set(static_configuration)

    So there is still a bug in the SDK that would come with some risk in multi-developer teams and for filed projects, but the fix is not application-specific anymore (you can use the same fix with multiple projects that use different net core partitioning). I hope it will be included in the SDK soon. Please mind that it is not included in recend SDK v2.9.1 yet!

    Net core update problems on SDK v2.9.0 via sysbuild

    You may also want to check out my other ticket here which describes a bug in mcuboot when trying to update the net core with SDK v2.9.0 (and most likely 2.9.1).

    Good luck with your projects!
    Michael

Related