MCUboot partition for Zephyr

[AndreasM]

Hi, we have a costumer who wants be able to do a firmware update over BLE. We have a running application that takes about 260k of FLASH. This fits in the NRF52832 (512k FLASH) but not with the two  slot1/slot2 partitions for MCUboot.

It would help to put the Zephyr part in a separate partition that will not be updated and therefore has not to be mapped. Is there a solution to do so. The dts would lock like:

(The address range is not correct below)

&flash0 {

    partitions {
    compatible = "fixed-partitions";
    #address-cells = <1>;
    #size-cells = <1>;

    boot_partition: partition@0 {
        label = "mcuboot";
        reg = <0x00000000 0xa000>;
    }

    zephyr_partition: partition@44000 {
        label = "zephyr"; 
        reg = <0x00044000 0x8000>;
    };

   slot0_partition: partition@a000 {
        label = "image-0";
        reg = <0x0000a000 0x39000>;
    };
    slot1_partition: partition@43000 {
        label = "image-1";
        reg = <0x00043000 0x39000>;
    };

    scratch_partition: partition@7c000 {
       label = "image-scratch";
       reg = <0x0007C000 0x1000>;
    };
    storage_partition: partition@7d000 {
       label = "storage";
       reg = <0x0007d000 0x00002000>;
    };
    };
};

Thanks for ideas to manage this situation. 

[Hung Bui]

Hi Andreas, 

There is a difference between the Zephyr architecture and our legacy softdevice architecture that Zephyr's stack is not separated from the application. So it's not possible to have a dedicated "stack" area that will not get updated. 

So in this case you really need to suggest the customer to reduce the size of the application. Is there any static data that was included in the application that can be moved to the storage area ? 
Another option is to move to a chip with larger flash size, the nRF52840 for example. 

[AndreasM]

What about following solutions:

1.) Can we use an external Flash to store one of the images?

2.) Can we do the update in two steps. First download a smaller application, that only has the BLE function to download a bigger file with the real application. The benefit would be, that we do not need two images with the same size rather have to images with different size they may overlap.

[Hung Bui]

Hi Andreas, 

1) Yes it's possible. If you can add external flash to the board then you can configure MCUBoot to use the external flash as secondary slot. You can have a look at this case: https://devzone.nordicsemi.com/f/nordic-q-a/72543/mcu-boot-with-external-flash-littles-partition-and-secondary-image-partition

2. This is a good idea. But I'm not 100% sure if it's supported by MCUBoot and by Nordic implementation. You can have a look at the DirectXIP section here. I will need to check with our team to see if #1. You can use Direct XIP 2. You can configure Slot 1 larger size than Slot 2. 

I will keep you updated. 

[Hung Bui]

Hi Andreas, 

2. The information I got from the developer is that Direct XIP is available  in MCUBoot but we haven't integrated it in to NCS. So in theory it's possible to do what you are planning but we haven't tested that. In addition you would need to compile the smaller application and the real application to start at a dedicated location, it's something we haven't tested. 

So all in all I would suggest to go for the external flash solution.