Zephyr With Custom bootloader

[danielb-tkjcy3rq]

Hi All,

I'm struggling a little with using zephyr with a custom bootloader. I decided against MCUBoot because it doesn't quite meet my project's requirements. For starters, my client requires three firmware partitions: current (slot0_partition), update (slot1_partition), and factory. The factory is a golden image to fallback to if all fails. I sort of patched mcuboot to manually copy the factory image to slot0 and try to boot gain. This worked OK.

Another issue I have with MCUBoot is its limitation on image downgrade. Unless I'm missing something, it doesn't allow downgrading and the update image's version has to be higher than the image in the primary slot. My client want to freely upgrade and downgrade, but I can't see an easy way around this.

The third issue I have is with multicore images. I'm using imxrt1170 based board and I make use of both processors. When I build with sysbuild, the output is two binaries (one for each core). I posted an issue about this one here. Basically, what I would like to do it after the build finishes is to contatenate the two binaries, sign the combined binary and then flash it. When I sign the combined binary, I can add a header containing (among other things) an offset address for the second core's binary. The second core will run from RAM and not XIP.

I have a basic bootloader which is able to boot single core images built for MCUBoot. After the build process, I run a custom python script to add the header to zephyr.bin and write that to flash. I failed miserably getting zephyr to use my custom script instead of mcuboot.cmake. I followed the doc in https://docs.zephyrproject.org/latest/develop/west/sign.html and set SIGNING_SCRIPT to my custom cmake. I placed my script (modified version of mcuboot.cmake) in $ZEPHYR_BASE/cmake and the python script in $ZEPHYR_BASE/scripts/build. The issue is that 'west sign' complains because I'm not using imgtool or rimage.

I'm using Zephyr 3.5.0.

Any pointers would be much appreciated.

[nixward]

Hi Danielb,

As far as I know CONFIG_MCUBOOT_DOWNGRADE_PREVENTION is opt in, so just ensure this option is not being enabled.

Hopefully others can help you with your multicore needs, I know there's been a lot of work recently on hwmv2 which may help.

[mariopaja]

@danielb-tkjcy3rq I have used rt1064 with mcuboot and updatehub on zephyr v3.3 and I didnt have downgrade problems

[danielb-tkjcy3rq]

Thank you @mariopaja and @nixward. I had misunderstood about MCUBoot not allowing downgrade.

The only blocker I have at the moment is the multicore image issue. For ease of discussion, I will use the openamp sample project running on the mimxrt1160_evk board. I built the project with 'west build -b mimxrt1160_evk_cm7 samples/subsys/ipc/openamp --sysbuild -- -DSB_CONFIG_BOOTLOADER_MCUBOOT=y' and have seen it boot. Well, after patching MCUBoot a bit because it was failing to disable the data and instruction caches.. I also modified the mimxrt1160_evk_cm4.dtsi device tree to add 'nxp,m4-partition = &slot2_partition;' as slot0 partition will be used by mcuboot for the CM7 update firmware.

I'm thinking that I can use slot0 and slot1 for the CM7, slot2 and slot3 for the CM4 image. It appears that 'DSB_CONFIG_BOOTLOADER_MCUBOOT=y' is only resulting in the CM7 image being signed and not the CM4. I added CONFIG_BOOTLOADER_MCUBOOT=y to the CM4 prj.conf and that results in the build attempting to sign the image. The build still fails with the error below because the CM4 is meant to run from RAM so it has 'zephyr,flash' set to ocram and not to flash with actual partitions.

FATAL ERROR: DT zephyr,flash chosen node has no partitions, can't find partitions for MCUboot slots

Can anyone see a solution for this?

Thanks,
Daniel

[DerekSnell]

Hi @danielb-tkjcy3rq ,
In the RT11xx architecture, typically the CM7 boots first. The CM4 executes from RAM, but the image is stored in flash. The CM7 app loads the CM4 app from flash to RAM, sets the boot address for the CM4, and then enables the CM4 to boot. See soc.c.

If you setup a slot partition in flash for the CM4, and set the zephyr,flash node to that slot, I believe the linker would place the code in that flash slot to execute from, which I do not think you want.

Perhaps you could find a way to use the MCUboot slots for this. But if I were attempting this, I would try to simplify this. I don't have all the detailed steps for you, but I would combine the CM7 and CM4 image into a single binary to write to flash. Sign that combined binary, and write it to the MCUboot slots. MCUboot would be unaware it contains the CM4 image. At boot, MCUboot authenticates the entire combined image, and then boots the CM7. And then the CM7 loads the CM4 app to RAM and boots the second core.

Let us know what you decide to do, and how it works out. Best regards

[danielb-tkjcy3rq]

Thanks @DerekSnell. I think I've got this working working by combining the images and siging both. I had to patch my zephyr checkout a bit to get it to work though.

Roughly, this is what I did:

• Made sure both CM7 and CM4 projects output hex.
• Added fixed flash partition for the CM4 making sure its address is in the range of the slot0_partition (this feels very hacky and I hate it). Basically slot0_partition is 0x30120000 - 0x30220000 and secondary_core_partition0 is 0x301e0000 - 0x30220000 (last 256KB).
• modified sign.py so allow input file path argument
• modified mcuboot.cmake to pass ${MERGED_HEX_NAME} when calling sign.py
• I use 'west flash --domain cm7_project_name' to flash the combined and signed hex file.
• Modified Zephyr's CMAkeLists.txt so that the rule to merge hex files is done/checked before signing (not sure if moving it was necessary)

#  set_property(GLOBAL APPEND PROPERTY HEX_FILES_TO_MERGE ${my_local_list})
# Note that the zephyr.hex file will not be included automatically.
set(MERGED_HEX_NAME "" CACHE INTERNAL "Merged HEX file name")
get_property(HEX_FILES_TO_MERGE GLOBAL PROPERTY HEX_FILES_TO_MERGE)
if(HEX_FILES_TO_MERGE)
  # Merge in out-of-tree hex files.
  set(MERGED_HEX_NAME merged.hex)

  # Append the custom command to extra_post_build_commands
  set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
    COMMAND ${PYTHON_EXECUTABLE} ${ZEPHYR_BASE}/scripts/build/mergehex.py -o ${MERGED_HEX_NAME} ${HEX_FILES_TO_MERGE}
    DEPENDS ${HEX_FILES_TO_MERGE} ${logical_target_for_zephyr_elf}
  )

  message(VERBOSE "Merging hex files: ${HEX_FILES_TO_MERGE}")
endif()

# Generate and use MCUboot related artifacts as needed.
if(CONFIG_BOOTLOADER_MCUBOOT)```