firmware update using mcumgr displays information for only slot 0 and not slot 1.

[khalidjmi1200]

Describe the bug
when command mcumgr -c TTYMXC2 image list is issued from the mcumgr info for only slot 0 is displayed
bootable: false
flags:
hash: Unavailable
Above given flags are also not correct. I have primary and secondary partition.

To Reproduce
Steps to reproduce the behavior:

1. Build an application for mcu boot and flash it on the board stm32l452.
2. when board is ready to receive the update firmware.
3. execute mcumgr -c TTYMXC2 image list from the terminal.
4. Info for slot 0 is displayed and variable are incorrect
   Images:
   image=0 slot=0
   version: 0.0.0.0
   bootable: false
   flags:
   hash: Unavailable

Expected behavior
Images for slot 0 and slot 1 should be displayed.

Images:
image=0 slot=0
version: 0.0.0.0
bootable: true
flags:
hash: Unavailable
image=0 slot=1
version: 0.0.0.0
bootable: true.
flags:
hash: Unavailable

Impact
showstopper

Logs and console output

command executed from mcumgr

mcumgr conn add TTYMXC2 type="serial" connstring='dev=/dev/ttymxc2,baud=115200'
mcumgr conn show TTYMXC2mcumgr -c TTYMXC2 image list
mcumgr -c TTYMXC2 image upload /home/root/user_data/settings/zephyr.signed.bin -e -t 30
mcumgr -c TTYMXC2 image list
mcumgr -c TTYMXC2 reset

---

Output for Upload process.

Connection profile TTYMXC2 successfully added
Connection profiles:
TTYMXC2: type=serial, connstring='dev=/dev/ttymxc2,baud=115200'
Images:
image=0 slot=0
version: 0.0.0.0
bootable: false
flags:
hash: Unavailable
Split status: N/A (0)
21.03 KiB / 21.03 KiB [==============================================================================================================================================================] 100.00% 879 B/s 24s
Done
Images:
image=0 slot=0
version: 1.7.0.0
bootable: false
flags:
hash: Unavailable
Split status: N/A (0)

---

configuration file for MCU BOOT APPLICATION

CONFIG_PRINTK=y
CONFIG_STDOUT_CONSOLE=y # std::cout and printf output...
CONFIG_UART_CONSOLE_ON_DEV_NAME="UART_3" # ...goes to UART_3CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="bootloader/mcuboot/root-rsa-2048.pem"# Enable mcumgr.
CONFIG_MCUMGR=y# Some command handlers require a large stack.
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048# Enable flash operations.
CONFIG_FLASH=y# Enable most core commands.
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

---

• OS: (Linux ubuntu)
• Toolchain (arm)
• Commit SHA or Version used

Additional context
Upload process is completed successful but it always uploads to slot 0 and never to slot 1. So if upload process is interrupted, then MCU can not reboot.

[de-nordic]

Can you check whether the DTS correctly labels slot0_partition parition as "image-0" and slot1_partition as "image-1"?
I am guessing that you are using smp_svr as a server? Smp_svr is, at this point, not able to upload to active slot, which is running application slot; this looks like configuration problem.

[khalidjmi1200]

Hi,

As far as I know, enabling CONFIG_BOOTLOADER_MCUBOOT configures smp_server.
This is the dts file which I am using and think its correct as you mentioned.

&flash0 {
/*
* For more information, see:
* http://docs.zephyrproject.org/latest/guides/dts/index.html#flash-partitions
*/
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;

	/* 64KB for bootloader */
	boot_partition: partition@0 {
		label = "mcuboot";
		reg = <0x00000000 0x00010000>;
		read-only;
	};

	/* storage: 64KB for settings */
	storage_partition: partition@10000 {
		label = "storage";
		reg = <0x00010000 0x00010000>;
	};

	/* application image slot: 64KB */
	slot0_partition: partition@20000 {
		label = "image-0";
		reg = <0x00020000 0x00010000>;
	};

	/* backup slot: 64KB */
	slot1_partition: partition@30000 {
		label = "image-1";
		reg = <0x00030000 0x00010000>;
	};
	

	/* swap slot: 64KB */
	scratch_partition: partition@40000 {
		label = "image-scratch";
		reg = <0x00040000 0x00010000>;
	};

};

};

---

confugration file.

CONFIG_PRINTK=y
CONFIG_STDOUT_CONSOLE=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_REBOOT=y
CONFIG_MCUMGR=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_FLASH=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

Is there anything missing in the file?

[de-nordic]

What is the SHA of modules/lib/mcumgr you are using?

[khalidjmi1200]

name: mcumgr
revision: 5c5055f5a7565f8152d75fcecf07262928b4d56e
path: modules/lib/mcumgr

[de-nordic]

Inside your build directory, can you check file zephyr/zephyr.dts for:

zephyr,code-partition = &slot0_partition;

inside chosen section?

Does the file zephyr/.config, in build directory, have CONFIG_FLASH_LOAD_OFFSET pointing to the address of slot0_partition?

[khalidjmi1200]

I have added .config and zephyr.dts file for both MCU BOOT and Application.
I have also added config for both MCU BOOT and Application

---

zephyr/zephyr.dts for MCU BOOT

/ {
#address-cells = < 0x1 >;
#size-cells = < 0x1 >;
chosen {
zephyr,entropy = &rng;
zephyr,flash-controller = &flash;
zephyr,sram = &sram0;
zephyr,flash = &flash0;
zephyr,can-primary = &can1;
zephyr,code-partition = &boot_partition; -------> In mcuboot it points to boot_partition
zephyr,console = &usart1;
}

---

zephyr/zephyr.dts for Application.

/ {
#address-cells = < 0x1 >;
#size-cells = < 0x1 >;
chosen {
zephyr,entropy = &rng;
zephyr,flash-controller = &flash;
zephyr,sram = &sram0;
zephyr,flash = &flash0;
zephyr,can-primary = &can1;
zephyr,code-partition = &slot0_partition; -------> In application it points to slot0_partition
};

---

zephyr/.config for MCU BOOT

CONFIG_HAS_FLASH_LOAD_OFFSET=y
CONFIG_USE_DT_CODE_PARTITION=y
CONFIG_FLASH_LOAD_OFFSET=0x0
CONFIG_FLASH_LOAD_SIZE=0x10000

---

zephyr/.config for Application

CONFIG_HAS_FLASH_LOAD_OFFSET=y
CONFIG_USE_DT_CODE_PARTITION=y
CONFIG_FLASH_LOAD_OFFSET=0x20000
CONFIG_FLASH_LOAD_SIZE=0x10000

---

confugration file for MCUBOOT.

CONFIG_CONSOLE=n
CONFIG_CONSOLE_HANDLER=n
CONFIG_UART_CONSOLE=n
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
CONFIG_MCUBOOT_SERIAL=y
CONFIG_BOOT_SERIAL_DETECT_PORT="GPIOE"
CONFIG_BOOT_SERIAL_DETECT_PIN=1
CONFIG_BOOT_SERIAL_DETECT_PIN_VAL=0
CONFIG_MCUBOOT_INDICATION_LED=y

---

confugration file for Application.

CONFIG_PRINTK=y
CONFIG_STDOUT_CONSOLE=y
CONFIG_UART_CONSOLE_ON_DEV_NAME="UART_3"
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_SIGNATURE_KEY_FILE="bootloader/mcuboot/root-rsa-2048.pem"
CONFIG_MCUMGR=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048
CONFIG_FLASH=y
CONFIG_MCUMGR_CMD_IMG_MGMT=y
CONFIG_MCUMGR_CMD_OS_MGMT=y

[Laczen]

Hi, isn't this error caused by mcumgr communicating with mcuboot directly (and not smp_srv) ?

[khalidjmi1200]

Yes, I checked the config file and its not configured as smp_server. Is it necessary to be configured as smp_server?

[de-nordic]

Where do you upload the software, to the mcuboot serial recovery or to an application?

[khalidjmi1200]

I upload the software to an mcuboot serial recovery.

[Laczen]

@khalidjmi1200, mcuboot serial recovery has limited functionality and will upload to slot0. In a "normal" operation mode your application (running smp_server) is responsible for uploading to slot1. Then mcuboot will do the move to slot0

[de-nordic]

It is not mcumgr problem, mcumgr library is not used by mcuboot. This is not a bug.

[Laczen]

@khalidjmi1200 I agree with de-nordic, this is not a bug. What you could say is that mcumgr should not respond to the image list command, probably it doesn't as the hash is unavailable.

[de-nordic]

It is not mcumgr problem, mcumgr library is not used by mcuboot. This is not a bug.

@khalidjmi1200 I agree with de-nordic, this is not a bug. What you could say is that mcumgr should not respond to the image list command, probably it doesn't as the hash is unavailable.

I should have specified that "this is not a bug" in Zephyr or modules/lib/mcumgr.

I do not know whether it could be considered bug in mcuboot, as mcuboot does implement the image list it just does not send back the hash.
The mcuboot (re-)implements, as @Laczen has mentioned, very basic set of mcumgr features and this is:
echo, image upload (always to slot 0) and image list.

[de-nordic]

Btw, the mcumgr command line tool, unless -e switch is provided, preceedes the image upload with erase command that is hardwired, within mcumgr library, to erase slot_1/image-1 and in image upload adds image=0 field by default; at this point the mcuboot ignores erase and does not use image selector.

[khalidjmi1200]

Hi @de-nordic and @Laczen,

Thanks for your prompt reply. I will investigate the way to communicate through smp_server from the other device. I will let you know.
Thanks once again

[de-nordic]

@khalidjmi1200 Can you convert the issue into discussion, so that it would not be hanging over our heads as a bug?