Sysbuild builds MCUBoot before static partitions are pulled in

RE: Sysbuild builds MCUBoot before static partitions are pulled in

Hung Bui — Mon, 11 Nov 2024 13:25:42 GMT

Hi Timothy,
You can try to do a quick test to set the slot0_partition and slot1_partition address to very near address , or at the very end of flash to see if you can still do DFU update.
From what I know we overwrite them with mcuboot_primary and mcuboot_secondary in our \nrf\include\flash_map_pm.h

I don't see slot0_flash and slot1_flash being used anywhere in the SDK else except from the define of them in the CMakelist.txt you pointed to.

RE: Sysbuild builds MCUBoot before static partitions are pulled in

timl2415 — Thu, 07 Nov 2024 19:01:16 GMT

Thanks for the response,

Like you suggested, i modified the dts partition map and mcuboot still jumped to the application address in my static partition map.

I'd still like some assurance that slot0 and slot1 arent being used as well. The errors when slot0 and slot1 partition aren't defined seem to be coming from bootloader/mcuboot/boot/zephyr/CmakeLists.txt on line 372 where there are some checks being on the slot partition sizes and flash r/w/e sizes. There are some cmake variables getting set in this code block. Can you confirm whether or not these checks are arbitrary and if the set variables are used elsewhere?

if(SYSBUILD)
  function(align_up num align result)
    math(EXPR out "(((${num}) + ((${align}) - 1)) & ~((${align}) - 1))")
    set(${result} "${out}" PARENT_SCOPE)
  endfunction()

  function(dt_get_parent node)
    string(FIND "${${node}}" "/" pos REVERSE)

    if(pos EQUAL -1)
      message(ERROR "Unable to get parent of node: ${${node}}")
    endif()

    string(SUBSTRING "${${node}}" 0 ${pos} ${node})
    set(${node} "${${node}}" PARENT_SCOPE)
  endfunction()

  if(CONFIG_SINGLE_APPLICATION_SLOT OR CONFIG_BOOT_FIRMWARE_LOADER OR CONFIG_BOOT_SWAP_USING_SCRATCH OR CONFIG_BOOT_SWAP_USING_MOVE OR CONFIG_BOOT_UPGRADE_ONLY OR CONFIG_BOOT_DIRECT_XIP OR CONFIG_BOOT_RAM_LOAD)
    # TODO: RAM LOAD support
    dt_nodelabel(slot0_flash NODELABEL "slot0_partition")
    dt_get_parent(slot0_flash)
    dt_get_parent(slot0_flash)

    if(NOT CONFIG_SINGLE_APPLICATION_SLOT)
      dt_nodelabel(slot1_flash NODELABEL "slot1_partition")
      dt_get_parent(slot1_flash)
      dt_get_parent(slot1_flash)

      if(NOT "${slot0_flash}" STREQUAL "${slot1_flash}")
        # Check both slots for the one with the largest write/erase block size
        dt_prop(erase_size_slot0 PATH "${slot0_flash}" PROPERTY "erase-block-size")
        dt_prop(write_size_slot0 PATH "${slot0_flash}" PROPERTY "write-block-size")
        dt_prop(erase_size_slot1 PATH "${slot1_flash}" PROPERTY "erase-block-size")
        dt_prop(write_size_slot1 PATH "${slot1_flash}" PROPERTY "write-block-size")

It seems like there should be documentation on the interaction between partition manager and sysbuild in 2.7.0 (perhaps in the migration guide). I asked a similar question while working on 2.6.0 and I was told that devicetree partitions weren't required to build MCUBoot.

Understanding MCUBoot partition management

RE: Sysbuild builds MCUBoot before static partitions are pulled in

Hung Bui — Thu, 07 Nov 2024 13:15:55 GMT

Hi Timothy,

You can find some discussion earlier about this here.

My understanding is that the partitions defined in device tree and the partitions in pm_static.yml with partition manager are 2 differents system. As mentioned in the above ticket when you use partition manager the device tree's partition become irrelevant. However, you can't build without that.

I would suggest to double check if modifying dts partition wouldn't affect the location of MCUBoot or slot0 or slot1. I would assume they don't

As mentioned in the ticket, we hope in the future it would be more clean and better align between Zephyr upstream and nRF Connect SDK.