mcuboot/samples/zephyr (make test-good-rsa) doesn't work #22903

kkiyota · 2020-02-18T14:29:32Z

Describe the bug
Using mcuboot/samples/zephyr, overwrite test case can work fine as shown below, where slot0 is overwritten by slot1. However, swap case(make test-good-rsa) doesn't work.

Could you let me know how I can debug it?

To Reproduce
Steps to reproduce the behavior:

mkdir build; cd build
cmake -DBOARD=nucleo_f767zi (with flash partitions)
make
See error => No errors

Expected behavior
According to Makefile, expectation should be described below.

//# Test a good image, with a good upgrade, using RSA signatures.
//# flash_boot: Unable to find bootable image
//# flash_hello1: hello1 runs
//# flash_hello2: hello2 runs
//# reset: hello1 runs

Impact
Showstopper

Screenshots or console output
/// make test-overwrite case (working) ////
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Swap type: none
[00:00:00.016,000] mcuboot: Unable to find bootable image
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Swap type: none
[00:00:00.066,000] mcuboot: Bootloader chainload address offset: 0x20000
[00:00:00.073,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-*
Hello World from hello1 on nucleo_f767zi!
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Swap type: test
[00:00:00.066,000] mcuboot: Image upgrade secondary slot -> primary slot
[00:00:00.073,000] mcuboot: Erasing the primary slot
[00:00:00.595,000] mcuboot: Copying the secondary slot to the primary slot: 0x20000 bytes
[00:00:07.442,000] mcuboot: Bootloader chainload address offset: 0x20000
[00:00:07.450,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-*
Hello World from hello2 on nucleo_f767zi!
/////////////////////////////////////////////////////////////////////////////////////////////////////////

/// make test-good-rsa case (not working) ////
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: none
[00:00:00.044,000] mcuboot: Unable to find bootable image
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: none
[00:00:00.095,000] mcuboot: Bootloader chainload address offset: 0x20000
[00:00:00.102,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-*
Hello World from hello1 on nucleo_f767zi!
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: test
[00:00:00.109,000] os: ***** BUS FAULT *****
[00:00:00.115,000] os: Precise data bus error
[00:00:00.120,000] os: BFAR Address: 0x20080004
[00:00:00.126,000] os: r0/a1: 0x20080000 r1/a2: 0x0000bc71 r2/a3: 0x00003384
[00:00:00.135,000] os: r3/a4: 0xffffc537 r12/ip: 0x00040000 r14/lr: 0x080007d3
[00:00:00.144,000] os: xpsr: 0x81000000
[00:00:00.149,000] os: Faulting instruction address (r15/pc): 0x08005d5e
[00:00:00.157,000] os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:00.165,000] os: Current thread: 0x20022b74 (unknown)
[00:00:00.172,000] os: Halting system
/////////////////////////////////////////////////////////////////////////////////////////////////////////

/// flash partition definition in zephyr/boards/arm/nucleo_f767zi/nucleo_f767zi.dts ///////
&flash0 {
/*
* For more information, see:
* http://docs.zephyrproject.org/devices/dts/flash_partitions.html
*/
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: 256KB */
	slot0_partition: partition@20000 {
		label = "image-0";
		reg = <0x00020000 0x00040000>;
	};

	/* backup slot: 256KB */
	slot1_partition: partition@60000 {
		label = "image-1";
		reg = <0x00060000 0x00040000>;
	};

	/* swap slot: 256KB */
	scratch_partition: partition@a0000 {
		label = "image-scratch";
		reg = <0x000a0000 0x00040000>;
	};

};

Environment (please complete the following information):

OS: (Ubuntu 19.10 on VirtualBox 6.0.16 )
Toolchain (Zephyr SDK 0.10.3, Zephyr 2.1.99, gcc-arm-none-eabi-9-2019-q4-major)

Additional context
Add any other context about the problem here.

Best regards,
Koji

The text was updated successfully, but these errors were encountered:

carlescufi · 2020-02-18T18:08:24Z

Using mcuboot/samples/zephyr,

Are you using Zephyr's built-in MCUBoot or upstream MCUBoot?

kkiyota · 2020-02-18T19:01:33Z

Sorry, but please let me know what the difference is.

kkiyota · 2020-02-19T03:20:26Z

Since I don't change released files other than dts file, it should be followed by Makefile as shown below. So mcuboot files are used at mcuboot/boot/zephyr

SOURCE_DIRECTORY := $(CURDIR)

boot: check
@rm -f mcuboot.bin
(mkdir -p $(BUILD_DIR_BOOT) &&
cd $(BUILD_DIR_BOOT) &&
cmake -DOVERLAY_CONFIG=$(BOOTLOADER_OVERLAY_CONFIG)
-G"Ninja"
-DBOARD=$(BOARD)
$(SOURCE_DIRECTORY)/../../boot/zephyr &&
ninja)
cp $(BUILD_DIR_BOOT)/zephyr/zephyr.bin mcuboot.bin

nvlsianpu · 2020-02-19T08:38:25Z

cc @utzig

utzig · 2020-02-19T11:52:00Z

@kkiyota Could you please paste your .config here? I remember there used to be issues with the STM32 flash driver when MULTITHREADING is disabled....

kkiyota · 2020-02-19T12:04:40Z

Here is mcuboot/samples/zephyr/build/nucleo_f767zi/mcuboot/zephyr/.config

If you need anything else, please let me know.

//////////////////////////////////////////////////////////////

mcuboot-config.txt

utzig · 2020-02-19T12:17:36Z

@kkiyota Yeah, that ended up quite unreadable :-P You should put it in a non-formatted block of text, anyways I think the issue is with the partitions you used, I was looking how I configured them for Mynewt and since there are non-linear sector sizes I would suggest you test with the same partition structure which would be:

	/* 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: 768KB */
	slot0_partition: partition@40000 {
		label = "image-0";
		reg = <0x00040000 0x000C0000>;
	};

	/* backup slot: 768KB */
	slot1_partition: partition@100000 {
		label = "image-1";
		reg = <0x00100000 0x000C0000>;
	};

	/* swap slot: 256KB */
	scratch_partition: partition@1c0000 {
		label = "image-scratch";
		reg = <0x001c0000 0x00040000>;
	};

kkiyota · 2020-02-19T12:34:14Z

@utzig I have no idea how I can paste as a plain text here. Instead, I added it as a text file. Please review it again.

I'll try using your partition later and let you know.

Thank you,
Koji

d3zd3z · 2020-02-19T12:45:57Z

It is known that the samples/zephyr makefile likely will only work for the frdm_k64f. Both the flash programming, as well as assumptions about partition positions. We have it as an issue in MCUboot: mcu-tools/mcuboot#213.

kkiyota · 2020-02-19T13:13:46Z

@d3zd3z Do you mean that I should wait until mcu-tools/mcuboot#213 will be resolved?

utzig · 2020-02-19T13:45:22Z

@kkiyota Would be nice if you could test with the suggested partition changes.

kkiyota · 2020-02-19T17:14:33Z

@utzig I'll work on it tomorrow due to conflict.

kkiyota · 2020-02-20T01:12:57Z

@utzig Could you also let me know your points? The difference between your partition map and mine is just slots' capacity.

utzig · 2020-02-20T09:06:55Z

@kkiyota The sectors are not linear in the STM32F7, which means not all sectors have the same size, you are starting a slot in a smaller sector which can't be swapped.

kkiyota · 2020-02-20T09:16:11Z

@utzig In my dts file as attached below again, both slot0 and slot1 are 256KB. Are you referring to this file? Or anything else?

/// flash partition definition in zephyr/boards/arm/nucleo_f767zi/nucleo_f767zi.dts ///////
&flash0 {
/*

For more information, see:
http://docs.zephyrproject.org/devices/dts/flash_partitions.html
*/
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: 256KB */
slot0_partition: partition@20000 {
label = "image-0";
reg = <0x00020000 0x00040000>;
};

/* backup slot: 256KB */
slot1_partition: partition@60000 {
label = "image-1";
reg = <0x00060000 0x00040000>;
};

/* swap slot: 256KB */
scratch_partition: partition@a0000 {
label = "image-scratch";
reg = <0x000a0000 0x00040000>;
};

};

utzig · 2020-02-20T09:23:28Z

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

The sector at 0x20000 is 128KB, which means you are using one sector plus half of the next sector (which is 256KB). MCUBoot in swap mode does not allow that.

/* backup slot: 256KB */
slot1_partition: partition@60000 {
label = "image-1";
reg = <0x00060000 0x00040000>;
};

The sector at 0x60000 is 256KB so this is one is OK.

kkiyota · 2020-02-20T10:19:36Z

@utzig Thank you for your reply! Looking at Zephyr document as shown below, the first parameter is defined as offset, and second one is capacity. Are you referring to the different spec?

//////////////////////////////////////////////////////////////////////////////////////
The content of the partitions node looks like this:

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

    partition1_label: partition@START_OFFSET_1 {
            label = "partition1_name";
            reg = <0xSTART_OFFSET_1 0xSIZE_1>;
    };

    /* ... */

    partitionN_label: partition@START_OFFSET_N {
            label = "partitionN_name";
            reg = <0xSTART_OFFSET_N 0xSIZE_N>;
    };

};
Where:

partitionX_label are device tree labels that can be used elsewhere in the device tree to refer to the partition
partitionX_name controls how defines generated by the Zephyr build system for this partition will be named

START_OFFSET_x is the start offset in hexadecimal notation of the partition from the beginning of the flash device

SIZE_x is the hexadecimal size, in bytes, of the flash partition

nvlsianpu · 2020-02-20T14:37:11Z

bug label removed as this is usage fault by incompatible partition configuration.
For get how partitions should be arranged pleas refer to mcuboot doc

kkiyota · 2020-02-20T15:29:29Z

@nvlsianpu Could you point out where my definition is incorrect if you think so?

utzig · 2020-02-21T00:16:11Z

I tested now with the partition configuration I have submitted earlier and I can confirm it can successfully upgrade and revert. I have built manually the bootloader and hello_word sample app, so maybe there might exist an issue with the build system that @d3zd3z mentioned. I might try to test that tomorrow as well.

@nvlsianpu Could you point out where my definition is incorrect if you think so?

As I wrote before "The sector at 0x20000 is 128KB, which means you are using one sector plus half of the next sector (which is 256KB)", can it be more clear than this?

Maybe try reading the reference manual: https://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/96/8b/0d/ec/16/22/43/71/DM00224583/files/DM00224583.pdf/jcr:content/translations/en.DM00224583.pdf

Go to page 88/1954, the sector at 0x20000 is 128KB and you can't mix sectors of different sizes; also you are describing it as 256KB in your DTS so it will use one sector + half sector. Your offsets should be updated to use the ones I have pasted here before; the size of the slots is not so important, I used 0xc0000 avoid wastings space, but it's fine if you want to stay with 0x40000.

kkiyota · 2020-02-22T08:46:14Z

@utzig Thank you for sending me ST document link! I didn’t know such NAND FLASH block limitation. I’ll try it ASAP.

kkiyota · 2020-02-25T13:52:30Z

@utzig I ran some experiments.

slot0_parition is set at Sector 5(256KB), slot1_partition is set at Sector 6 and scratch_partition is set at Sector 7.
It worked fine as shown below.

*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: none
[00:00:00.044,000] mcuboot: Unable to find bootable image
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: none
[00:00:00.095,000] mcuboot: Bootloader chainload address offset: 0x40000
[00:00:00.102,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-1*
Hello World from hello1 on nucleo_f767zi!
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: test
[00:00:09.736,000] mcuboot: Bootloader chainload address offset: 0x40000
[00:00:09.743,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-1*
Hello World from hello2 on nucleo_f767zi!
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: none
[00:00:00.035,000] mcuboot: Swap type: revert
[00:00:09.820,000] mcuboot: Bootloader chainload address offset: 0x40000
[00:00:09.828,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-1*
Hello World from hello1 on nucleo_f767zi!

slot0_parition is set at Sector 5&6(512KB), slot1_partition is set at Sector 7&8 and scratch_partition is set at Sector 9&10.
I got the following error when I loaded hello2, although I changed "--slot-size 0x80000". Any idea how I can fix it?

////
koji@koji-VirtualBox:~/mcuboot.nucleo_f767zi/samples/zephyr$ make flash_hello2
pyocd flash -a 0x80C0000 signed-hello2.bin --pack ~/Documents/DFP/Keil.STM32F7xx_DFP.2.12.0.pack
[====================] 100%
0088446:CRITICAL:main:erase_sector(0x8120000) error: 1
Traceback (most recent call last):
File "/home/koji/.local/lib/python3.7/site-packages/pyocd/main.py", line 344, in run
self._COMMANDSself._args.cmd
File "/home/koji/.local/lib/python3.7/site-packages/pyocd/main.py", line 481, in do_flash
file_format=self._args.format)
File "/home/koji/.local/lib/python3.7/site-packages/pyocd/flash/file_programmer.py", line 157, in program
self._loader.commit()
File "/home/koji/.local/lib/python3.7/site-packages/pyocd/flash/loader.py", line 168, in commit
keep_unwritten=self._keep_unwritten)
File "/home/koji/.local/lib/python3.7/site-packages/pyocd/flash/builder.py", line 466, in program
flash_operation = self._sector_erase_program_double_buffer(progress_cb)
File "/home/koji/.local/lib/python3.7/site-packages/pyocd/flash/builder.py", line 863, in _sector_erase_program_double_buffer
self.flash.erase_sector(sector.addr)
File "/home/koji/.local/lib/python3.7/site-packages/pyocd/flash/flash.py", line 353, in erase_sector
raise FlashEraseFailure('erase_sector(0x%x) error: %i' % (address, result), address, result)
pyocd.core.exceptions.FlashEraseFailure: erase_sector(0x8120000) error: 1
make: *** [Makefile:194: flash_hello2] Error 1

/// Terminal screen ///
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: none
[00:00:00.044,000] mcuboot: Unable to find bootable image
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: none
[00:00:00.095,000] mcuboot: Bootloader chainload address offset: 0x40000
[00:00:00.102,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d*
Hello World from hello1 on nucleo_f767zi!
////
*** hello2 was not loaded here.

Best regards,
Koji

utzig · 2020-02-25T15:25:46Z

I have no idea why make flash_hello2 failed but you have to make it run without fails to actually load hello2 correctly into the slot and be able to run an upgrade.

d3zd3z · 2020-02-25T16:52:03Z

I have no idea why make flash_hello2 failed but you have to make it run without fails to actually load hello2 correctly into the slot and be able to run an upgrade.

The Makefile that builds hello2 hardcodes everything about the partition, both when calling imgtool.py and when flashing the image. If this doesn't match the frdm-k64f, the upgrade won't likely work.

kkiyota · 2020-02-25T17:08:44Z

@d3zd3z I just changed "--slot-size" assuming that it's the same as slot0 and slo1 partition size. Is it correct understanding?

////////////////////////////

Build and sign "hello1".

hello1: check
(mkdir -p $(BUILD_DIR_HELLO1) &&
cd $(BUILD_DIR_HELLO1) &&
cmake -DFROM_WHO=hello1
-G"Ninja"
-DBOARD=$(BOARD)
$(SOURCE_DIRECTORY)/hello-world &&
ninja)
$(IMGTOOL) sign
--key $(SIGNING_KEY)
--header-size $(BOOT_HEADER_LEN)
--align $(FLASH_ALIGNMENT)
--version 1.2
--slot-size 0x80000
$(BUILD_DIR_HELLO1)/zephyr/zephyr.bin
signed-hello1.bin

Build and sign "hello2".

This is the same signing command as above, except that it adds the

"--pad" argument. This will also add the trailer that indicates

this image is intended to be an upgrade. It should be flashed into

the secondary slot instead of the primary slot.

hello2: check
(mkdir -p $(BUILD_DIR_HELLO2) &&
cd $(BUILD_DIR_HELLO2) &&
cmake -DFROM_WHO=hello2
-G"Ninja"
-DBOARD=$(BOARD)
$(SOURCE_DIRECTORY)/hello-world &&
ninja)
$(IMGTOOL) sign
--key $(SIGNING_KEY)
--header-size $(BOOT_HEADER_LEN)
--align $(FLASH_ALIGNMENT)
--version 1.2
--slot-size 0x80000
--pad
$(BUILD_DIR_HELLO2)/zephyr/zephyr.bin
signed-hello2.bin

kkiyota · 2020-02-25T17:12:36Z

@utzig Yes, I can compile it with no errors. When signed-hello2.bin was loaded, I just got the error which looks error for erase.

kkiyota · 2020-02-27T12:11:45Z

Hi,

Looking at my error message in case of 2 x 256KB sectors for slot1 (Sector 7 and 8) , erase error seems to occur at 0x8120000 which is in Sector 8. pyocd option for erase is set as sector erase as a default. However, it seems that there is no way to specify the 2 sectors erase. And it's not clear how erase and program operations are proceeded.

There is the description in pyocd document that pyocd doesn't run erase operation in "pyocd flash" command, but it looks erase operation was run.

Does anyone know how I can specify arguments for "pyocd flash" command or anything else?

In case of single sector dts configuration, it works fine. So I guess there may be additional cares required for >2 sectors case.

Regards,
Koji

/////////////////////

koji@koji-VirtualBox:~/mcuboot.nucleo_f767zi/samples/zephyr$ make flash_hello2
pyocd flash -a 0x80C0000 signed-hello2.bin --pack ~/Documents/DFP/Keil.STM32F7xx_DFP.2.12.0.pack
[====================] 100%
0088446:CRITICAL:main:erase_sector(0x8120000) error: 1
Traceback (most recent call last):

kkiyota · 2020-02-27T19:07:30Z

Referring to the log file, this flash may be configured as dual bank mode which is defined in Table 4 below instead of single bank mode in Table 3.

So in my last case with the following slot1_partition, it would be overlapped to Bank 2. I need to check it furthermore, though.

slot1_partition: partition@c0000 {
label = "image-1";
reg = <0x000C0000 0x00080000>;

kkiyota · 2020-02-27T20:08:16Z

I also confirmed by register read that flash controller in stm32f767zi was configured as single bank mode. However, pyocd log info showed erase operation was performed by 128KB(target sector size in dual bank mode) instead of 256KB(target sector size in single bank mode).

So I guess my problem is related to pyocd. Since my board files for nucleo-f767zi doesn't work with pyocd, I'm currently using Keil.STM32F7xx_DFP.2.12.0.pack which was downloaded from ARM site.

Any idea?

utzig · 2020-02-28T12:05:58Z

I use almost exclusively this tooling with STM32s: https://github.com/texane/stlink

kkiyota · 2020-02-28T13:05:46Z

@utzig Thank you! Is it different from ST supplied tools?

utzig · 2020-02-28T14:06:20Z

@utzig Thank you! Is it different from ST supplied tools?

I don't know what tools ST are supplying these days, but stlink is open-source and works on 100% of the boards I use (with no configuration required).

kkiyota · 2020-02-28T14:10:22Z

@utzig Thanks! In your case, does stlink work fine with 2 sectors of slot0 and slot1 like 256KB x2 in single bank mode?

utzig · 2020-02-28T14:50:41Z

@utzig Thanks! In your case, does stlink work fine with 2 sectors of slot0 and slot1 like 256KB x2 in single bank mode?

Yes, I have absolutely no issues, I use a lot of STM32 boards (20 or more) and everything works 100%.

kkiyota · 2020-02-28T14:58:14Z

@utzig Sounds good! I'll implement and run with it.

kkiyota · 2020-02-28T18:35:51Z

@utzig I installed stlink thru Ubuntu Software store.

In case of slot0=slot1=scratch=256KB, swap case works fine.

However, in case of slot0=slot1=scratch=512KB or slot0=slot1=768KB/ scratch=256KB, hello1 was executed although flash write operation was performed well. Expected result is that hello2 is run temporally and revert it on reset.

My set-flash command for hello2 is listed below. Is it correct command?

Any idea why only 256KB case could work?

flash_hello2:
st-flash --reset --format binary write signed-hello2.bin 0x080C0000 <= 512KB case(Sector 7/8)
st-flash --reset --format binary write signed-hello2.bin 0x08100000 <= 768KB case(Sector 8/9/10)

kkiyota · 2020-02-28T19:01:03Z

@utzig Looks like I forgot to change --slot-size during imgtoo.py execution. After I fixed it, everything looks fine as shown below in case of slot0=slot1=768KB and scratch=256KB.

Appreciated your help!

*** Booting Zephyr OS build z*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: none
[00:00:00.044,000] mcuboot: Unable to find bootable image
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.039,000] mcuboot: Swap type: none
[00:00:00.095,000] mcuboot: Bootloader chainload address offset: 0x40000
[00:00:00.102,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
Hello World from hello1 on nucleo_f767zi!
FLASH_OPTCR register= ffffaafd
*** *** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: primary slot
[00:00:00.040,000] mcuboot: Swap type: test
[00:00:10.598,000] mcuboot: Bootloader chainload address offset: 0x40000
[00:00:10.605,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
Hello World from hello2 on nucleo_f767zi!
FLASH_OPTCR register= ffffaafd
*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
[00:00:00.005,000] mcuboot: Starting bootloader
[00:00:00.011,000] mcuboot: Primary image: magic=good, swap_type=0x2, copy_done=0x1, image_ok=0x3
[00:00:00.021,000] mcuboot: Scratch: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.030,000] mcuboot: Boot source: none
[00:00:00.035,000] mcuboot: Swap type: revert
[00:00:15.926,000] mcuboot: Bootloader chainload address offset: 0x40000
[00:00:15.933,000] mcuboot: Jumping to the first image slot�*** Booting Zephyr OS build zephyr-v2.1.0-1214-g22326f6d99e8 ***
Hello World from hello1 on nucleo_f767zi!
FLASH_OPTCR register= ffffaafd

kkiyota added the bug The issue is a bug, or the PR is fixing a bug label Feb 18, 2020

carlescufi assigned d3zd3z and nvlsianpu Feb 18, 2020

carlescufi added the area: MCUBoot label Feb 18, 2020

nvlsianpu removed the bug The issue is a bug, or the PR is fixing a bug label Feb 20, 2020

jhedberg added the question label Feb 25, 2020

nashif closed this as completed Mar 18, 2020

mcuboot/samples/zephyr (make test-good-rsa) doesn't work #22903

mcuboot/samples/zephyr (make test-good-rsa) doesn't work #22903

Comments

kkiyota commented Feb 18, 2020

carlescufi commented Feb 18, 2020

kkiyota commented Feb 18, 2020

kkiyota commented Feb 19, 2020

nvlsianpu commented Feb 19, 2020

utzig commented Feb 19, 2020

kkiyota commented Feb 19, 2020 • edited Loading

utzig commented Feb 19, 2020

kkiyota commented Feb 19, 2020

d3zd3z commented Feb 19, 2020

kkiyota commented Feb 19, 2020

utzig commented Feb 19, 2020

kkiyota commented Feb 19, 2020

kkiyota commented Feb 20, 2020

utzig commented Feb 20, 2020

kkiyota commented Feb 20, 2020

utzig commented Feb 20, 2020

kkiyota commented Feb 20, 2020

nvlsianpu commented Feb 20, 2020

kkiyota commented Feb 20, 2020

utzig commented Feb 21, 2020 • edited Loading

kkiyota commented Feb 22, 2020

kkiyota commented Feb 25, 2020

utzig commented Feb 25, 2020

d3zd3z commented Feb 25, 2020

kkiyota commented Feb 25, 2020

Build and sign "hello1".

Build and sign "hello2".

This is the same signing command as above, except that it adds the

"--pad" argument. This will also add the trailer that indicates

this image is intended to be an upgrade. It should be flashed into

the secondary slot instead of the primary slot.

kkiyota commented Feb 25, 2020

kkiyota commented Feb 27, 2020

kkiyota commented Feb 27, 2020

kkiyota commented Feb 27, 2020

utzig commented Feb 28, 2020

kkiyota commented Feb 28, 2020

utzig commented Feb 28, 2020

kkiyota commented Feb 28, 2020

utzig commented Feb 28, 2020

kkiyota commented Feb 28, 2020

kkiyota commented Feb 28, 2020

kkiyota commented Feb 28, 2020

kkiyota commented Feb 19, 2020 •

edited

Loading

utzig commented Feb 21, 2020 •

edited

Loading