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

Reply
  • 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

Children
  • 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

Related