Static Partition Manager and XIP Variant

RE: Static Partition Manager and XIP Variant

Sigurd Hellesvik — Fri, 22 Dec 2023 08:29:41 GMT

Good catch! If you use serial DFU, you only need one slot, getting a lot more space to work with.

Thanks a lot for the kind words, and especially for sharing the solution! I am sure that future users will find this helpful.

RE: Static Partition Manager and XIP Variant

alex-b — Thu, 21 Dec 2023 20:25:48 GMT

Ok, so I've got it working, and here's what I did in case others find it helpful!

I didn't quite end up following your suggestion above Sigurd, but I did get a lot of help from reading through all that, as well as this.

I've ended up making the mcuboot wait for 15 seconds when it starts for a DFU connection, and using that to update the application. This allows me to have a single image that's big enough for my application to fit in, and will enable the devices to be updated in the field.

I set the prj.conf for mcuboot as follows:

CONFIG_MAIN_STACK_SIZE=10240
CONFIG_MBEDTLS_CFG_FILE="mcuboot-mbedtls-cfg.h"

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_PM_PARTITION_SIZE_MCUBOOT=0xc000

CONFIG_SIZE_OPTIMIZATIONS=y
CONFIG_SINGLE_APPLICATION_SLOT=y

# Enable wait for DFU functionality
CONFIG_BOOT_USB_DFU_WAIT=y
CONFIG_BOOT_USB_DFU_WAIT_DELAY_MS=15000

CONFIG_FLASH=y
CONFIG_FLASH_PAGE_LAYOUT=y
CONFIG_FLASH_MAP=y
CONFIG_FCB=y
CONFIG_SETTINGS=y
CONFIG_SETTINGS_FCB=y
CONFIG_MPU_ALLOW_FLASH_WRITE=y

(There's other pointers on here how to do that in the child_image folder, but that's for another day!)

In my board.dts file I had the following set up:

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

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x0 0x10000>;
		};
		slot0_partition: partition@10000 {
			label = "image-0";
			reg = <0x10000 0x30000>;
		};
	};
};

In my application's prj.conf file I added:

CONFIG_BOOTLOADER_MCUBOOT=y

# Build
CONFIG_SIZE_OPTIMIZATIONS=y

CONFIG_MCUBOOT_GENERATE_CONFIRMED_IMAGE=y

Once it was all up and working, I went back and added the pm_statc.yml file to my project (taken directly from the generated partitions.yml file in the build folder.

app:
  address: 0xc200
  end_address: 0x3e000
  region: flash_primary
  size: 0x31e00
mcuboot:
  address: 0x0
  end_address: 0xc000
  placement:
    before:
    - mcuboot_primary
  region: flash_primary
  size: 0xc000
mcuboot_pad:
  address: 0xc000
  end_address: 0xc200
  placement:
    before:
    - mcuboot_primary_app
  region: flash_primary
  size: 0x200
mcuboot_primary:
  address: 0xc000
  end_address: 0x3e000
  orig_span: &id001
  - app
  - mcuboot_pad
  region: flash_primary
  size: 0x32000
  span: *id001
mcuboot_primary_app:
  address: 0xc200
  end_address: 0x3e000
  orig_span: &id002
  - app
  region: flash_primary
  size: 0x31e00
  span: *id002
settings_storage:
  address: 0x3e000
  end_address: 0x40000
  placement:
    align:
      start: 0x1000
    before:
    - end
  region: flash_primary
  size: 0x2000
sram_primary:
  address: 0x20000000
  end_address: 0x20008000
  region: sram_primary
  size: 0x8000

For completeness, when I boot the board up now, I can run the following line from where I downloaded dfu-util:

dfu-util --alt 0 --download ../nRFprojects/xxxx/build_Xxxx/zephyr/app_update.bin

My plan is to build a reset into my application, which can be triggered over the Bluetooth connection, so that in the field we can plug in the USB (which will also charge the device), trigger the reset from our app, then use df-util to update the app.

What could go wrong! 🙂

Hopefully the above helps someone else out too, I've learnt a lot in doing it though, and thanks ever so much to Sigurd and the rest of the Nordic support team too!

Alex

RE: Static Partition Manager and XIP Variant

alex-b — Tue, 19 Dec 2023 16:52:10 GMT

Thanks for the pointers Sigurd, sounds like a bit of a challenge but I'll give it a go and report back how I get on!

Alex

RE: Static Partition Manager and XIP Variant

Sigurd Hellesvik — Tue, 19 Dec 2023 15:32:39 GMT

Here are some pointers:

First, I would like to say that this approach is not officially supported by us, so best I can do is to give you help to do it yourself. And we can not guarantee anything related to this, as it is not properly tested.

If you do not want to take all the effort to craft a new pm_static.yml for testing every time you change the partition size, you can temporarily make changes to pm.yml for mcuboot to set mcuboot_secondary. In that case, you can change this line to "size: 0x20000" (or any other size), and the partition manager will automatically size the rest to fit with that.

Next up, if you build your project with CONFIG_BOOT_BUILD_DIRECT_XIP_VARIANT, the build will create a secondary image file build/zephyr/mcuboot_secondary_app_update.bin which you should be able to use for the secondary slot.

Further more, I think you need to do two different projects, and make sure that mcuboot signing keys match up (If you do not set the key manually it will be the same test key).
Then as long as both projects have the same pm_static.yml, I think you should be able to switch between the two.

Lastly, you need a way to go from the application to the DFU image when you want to do DFU.
By default, direct_XIP boots the image with the newest version. So we need some trick to make it go back to the previous image. I think the easiest way here might be to set CONFIG_BOOT_DIRECT_XIP_REVERT for the child image. Then find a way to revert the image when you need to go to the DFU image.
Testing this, I see that MUCboot can no longer find the image if I enable this configuration. I asked our MCUboot developers about this. Maybe you can find another way to switch between the images?

RE: Static Partition Manager and XIP Variant

Sigurd Hellesvik — Tue, 19 Dec 2023 12:34:08 GMT

Right, the DFU partition is smaller than the main application of course.

One possible limitation here is that MCUboot assumes that both slots are the same size, which may make partitioning harder.

In that case I agree that you need static partitioning to fix this yes.

I will have a look and see if I can figure something out.

RE: Static Partition Manager and XIP Variant

alex-b — Tue, 19 Dec 2023 12:27:43 GMT

Hi Sigurd, I can build them both separately without using the static PM, and they seem to work individually.

However, following your excellent suggestion, I've removed the stain PM and tried using the DFU application to load a new version of the DFU application into the second slot, and that hasn't worked.

I made sure I updated the version, using:

CONFIG_MCUBOOT_IMGTOOL_SIGN_VERSION="1.0.0+1"

But when it resets after the DFU update, it still runs the initial version in slow 0.

Alex

RE: Static Partition Manager and XIP Variant

Sigurd Hellesvik — Tue, 19 Dec 2023 12:19:35 GMT

I see, that makes sense.

Does it work if you build without pm_static.yml?
Generally I recommend building without pm_static.yml when developing. Then when having released the device (and when testing this last step), copy build/partitions.yml to pm_static.yml to make sure partitioning never changes, so that it repartitioning does not break future DFU.

See Static partition requirement for DFU for more info on static partitioning.

RE: Static Partition Manager and XIP Variant

alex-b — Tue, 19 Dec 2023 12:14:51 GMT

Hi Sigurd, thanks for the quick response!

Direct-XIP is what I need, to be able to run either the DFU or our application from internal flash.

Alex

RE: Static Partition Manager and XIP Variant

Sigurd Hellesvik — Tue, 19 Dec 2023 12:07:43 GMT

Hi,

Direct-XIP is not the same as XIP.

XIP is usually running part of the code from external flash.

Direct-XIP still uses two slots in internal flash, but for DFU, MCUboot does not swap to run the new image. See Equal slots (direct-xip).

Which of these do you want?

Regards,
Sigurd Hellesvik