MCUBOOT_DIRECT_XIP mode

[Sathishkumar-rk]

Hi @DerekSnell @danieldegrasse,

Can you please give your thoughts on below request.

I want to use MCUBOOT_DIRECT_XIP upgrade mode to run latest image from their slots.

Trials for MCUBOOT_DIRECT_XIP:

1. Slot 0 with latest image

• Flashed slot-0 with image version 3.3.3+3
• Flashed slot-1 with image version 2.2.2+2
  Output:
  Slot 0 image is getting executed

2. Slot 1 with latest image

• Flashed slot-0 with image version 2.2.2+2
• Flashed slot-1 with image version 3.3.3+3
  Output:
  Slot 0 image getting executed but expectation is Slot 1 image will get execute.

I'm expecting in second test case from slot-1 image should get executed as per documentation details, whichever slot has higher version should get executed. below is my configuration details of MCUBoot and Zephyr application image.

• MCUBoot configuration
  

• Image preparation
  
  

[DerekSnell]

Hi @Sathishkumar-rk ,

The image in Slot1 needs to be confirmed. See steps using MCUmgr, and MCUboot documentation.

[Sathishkumar-rk]

Hi @DerekSnell

I have tried steps provided in zephyr_MCUBoot_Lab_v1.0.pdf file to upgrade the image from mcumgr.

while running image list command from mcumgr receiving NMP timeout error response.

Is there any other steps Am I missing in building process like should I change any MCUBoot settings to adopt mcumgr functions?

Thanks,
Sathishkumar K

[DerekSnell]

Hi @Sathishkumar-rk ,
I have not run into NMP timeout errors before. But after reviewing this other issue, and reading this note about NMP timeouts in the smp_svr doc, it seems the mcumgr host tool will report this error when it can no longer communicate with smp_svr over the serial connection.

Since this happens to you after giving the image list command, I would use a debugger with the smp_svr app, and step through the code after it receives this command, to see why the app stops responding.

Let us know what you find.

[Sathishkumar-rk]

Hi @DerekSnell

Thanks for the update.

Let me check the commands, which is given on community thread.

Will update the status here after debugging.

Thank you.

[Sathishkumar-rk]

Hi @DerekSnell

I can able to run the mcumgr with RT board.

From the issue forum which you have shared in last reply, found out in dts file uart port missing for mcumgr

with this uart port inclusion I cab able to use mcumgr

Thanks for the support. I will confirm with these changes whether DIRECT_XIP mode is working as expected or not & will update the status.

Thanks,
Sathishkumar K

[Sathishkumar-rk]

Hi @DerekSnell,

I have tested secondary slot image with confirm command but still my expectation is not met with confirm image.

In above log information, chain-load offset address pointing to secondary slot location it's as expected and from their application reset vector is called as application entry point.

Actually from debugging I understood that, when we do west build it's preparing application binary for primary slot. which is confirmed by zephyr memory map file. Because of this even-though secondary slot image calling application reset vector memory it's pointing out to primary location that's why it's always running primary location image.

Is that any way we can build application for secondary slot location, so that upon reset vector call it will point to secondary image entry point.

Earlier I was expected like if binary image flashed over secondary slot MCUboot direct XIP mode will take care of address related stuff but it seems it not getting handled.

To confirm the above statement i was tried to change the flash base address of application through menuconfig setting and build application binary. Flashed in secondary slot and confirmed.

Log Information:
binary build with default configuration:
*** Booting Zephyr OS build b6270b6acb3b ***
I: Starting Direct-XIP bootloader
I: Current datetime: 2022-11-14 19:00:00
I: Primary slot: version=1.1.1+1 Header Info=0x96f3b83d, 0x0, 0x400, 0x0, 0xf21c, 0x0, 0x0
I: Secondary slot: version=2.2.2+2 Header Info=0x96f3b83d, 0x0, 0x400, 0x0, 0xf21c, 0x0, 0x0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x320000
I: Jumping to the image slot
*** Booting Zephyr OS build b6270b6acb3b ***
[00:00:00.004,089] smp_sample: build time: Nov 23 2022 23:41:44
[00:00:00.004,119] smp_sample: version 1.1.1+1

Binary with modified configuration for secondary slot

*** Booting Zephyr OS build b6270b6acb3b ***
I: Starting Direct-XIP bootloader
I: Current datetime: 2022-11-14 19:00:00

I: Primary slot: version=1.1.1+1 Header Info=0x96f3b83d, 0x0, 0x400, 0x0, 0xf21c, 0x0, 0x0
I: Secondary slot: version=2.2.2+2 Header Info=0x96f3b83d, 0x0, 0x400, 0x0, 0xf21c, 0x0, 0x0
I: Image 0 loaded from the secondary slot
I: Bootloader chainload address offset: 0x320000
I: Jumping to the image slot
*** Booting Zephyr OS build b6270b6acb3b ***
[00:00:00.004,089] smp_sample: build time: Dec 9 2022 12:32:43
[00:00:00.004,119] smp_sample: version 2.2.2+2

Thanks,
Sathishkumar K
zephyr_build_mapfile.zip
mimxrt1160_evk_cm7.zip

[DerekSnell]

Hi @Sathishkumar-rk ,

I am no expert on MCUboot. My experience with MCUboot has always executed the applications from Slot0, and using MCUboot to swap the image in Slot1 to Slot0 before executing.

But if you want the linker to place the application code in the Slot1 partition for executing there, you just need to change the devicetree for the board. The line below is from the board's devicetree file, and normally places code in the Slot0 partition. The change below will move the executable image to Slot1.

chosen {
	zephyr,code-partition = &slot1_partition;
};

Best regards

[Sathishkumar-rk]

Hi @DerekSnell,

It makes sense to my understanding, Thanks for the information.