MCUBoot is linked to slot0 because overlay is dropped in boilerplate.cmake

[Qbicz]

EDIT: Clarification on request from @SebastianBoe: This issue is the same as mcu-tools/mcuboot#399. However, I suspect the problem to be in Zephyr boilerplate.cmake, not in MCUBoot.
Main problem is that when mcuboot/boot/zephyr/CMakeLists.txt is provided with -DDTC_OVERLAY_FILE from command line, it is not appended to the list of overlayed files, but used instead.
Chain here is mcuboot/boot/zephyr/CMakeLists.txt -> boilerplate.cmake -> dts.cmake.
So far I found that before the line
https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/app/boilerplate.cmake#L369
DTC_OVERLAY_FILE has all the files it should, and after that it only has the one provided from command line.

Original issue:

Describe the bug
MCUBoot executable should start from 0x000.
However, after NCS umperge d97e9f5 (Zephyr d3bb3cf, MCUBoot ebd05033480cc) when generated/built from zephyr app or nrf app directory, the executable is linked from 0xC000 and cannot be used as bootloader.

To Reproduce
We used to generate MCUBoot build files with the following command:
https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/samples/nrf_desktop/CMakeLists.txt#L131

Configuration is same as in mcuboot/boot/zephyr. The only difference is logging on.
https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/samples/nrf_desktop/configuration/nrf52840_pca20041/mcuboot_ZDebugMCUBoot.conf

However, with after building bootloader the executable starts from 0xC000 as if it was a Zephyr application with MCUBoot support.
Beginning of bootloader hex:

:10C00000485200203DE90000AF0601007DE8000035
:10C010007DE800007DE800007DE800007DE800008C
:10C020007DE800007DE800007DE80000A5E4000058
:10C030007DE800007DE800004DE4000039060100C5
:10C0400015E9000015E9000015E9000015E90000F8
:10C0500015E9000015E9000015E9000015E90000E8

Expected behavior
MCUBoot code should start from 0x000.

Impact
Showstopper.

Environment (please complete the following information):

• Toolchain (e.g Zephyr SDK 0.10.0, west 0.5.7)
• Commit d3bb3cf

[jfischer-no]

Is it the same issue as #15077?

[Qbicz]

No, #15077 is for PCA10059. This issue is for compiling MCUBoot from application directory. In our application, we added ninja mcuboot target which looks like this https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/samples/nrf_desktop/CMakeLists.txt#L131

With previous revisions, MCUBoot hex was linked from 0x0000 if it was built with the CMake command mentioned.

Now hex is linked from 0xC000. However, when I build directly from mcuboot/zephyr/boot, it is still linked from 0x0000.

[lemrey]

What you say is slightly incorrect, MCUboot is not linked from 0x00 but in boot_partition.
That's done by dts.overlay under /mcuboot/boot/zephyr, when compiling MCUboot.

I see in your CMakeList.txt file that you specify an overlay manually and do not select the boot_partition. I suppose that the overlay in MCUboot is not applied in that case; though I am not entirely clear why your image is linked a slot0 partition then.

CC: @nvlsianpu

[Qbicz]

Thanks @lemrey. I checked with @nvlsianpu offline and the partitions in the dts_compiled file look like this:

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

				boot_partition: partition@0 {
					label = "mcuboot";
					reg = <0x00 0xc000>;
				};

				slot0_partition: partition@c000 {
					label = "image-0";
					reg = <0xc000 0x67000>;
				};

				slot1_partition: partition@73000 {
					label = "image-1";
					reg = <0x73000 0x67000>;
				};

				scratch_partition: partition@da000 {
					label = "image-scratch";
					reg = <0xda000 0x1e000>;
				};

				storage_partition: partition@f8000 {
					label = "storage";
					reg = <0xf8000 0x8000>;
				};
			};

However, partition is chosen incorrectly:

	chosen {
		zephyr,console = "/soc/uart@40002000";
		zephyr,sram = "/memory@20000000";
		zephyr,flash = "/flash-controller@4001E000/flash@0";
		zephyr,code-partition = "/flash-controller@4001E000/flash@0/partitions/partition@c000";
	};

When I remove -DDTC_OVERLAY_FILE argument from cmake, the partition is chosen correctly:

	chosen {
		...
		zephyr,code-partition = "/flash-controller@4001E000/flash@0/partitions/partition@0";
	};

Problem comes from the fact that MCUBoot dts.overlay is not overlayed.

We build the list of overlay files to use in CMakeLists, here: https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/samples/nrf_desktop/CMakeLists.txt#L33 It is possible that after adding flash overlay to change partitions on dongle, MCUBoot overlay was ignored by mistake on other boards. I will check how we can fix it, i.e. get the DTC_OVERLAY_FILE from MCUBoot and append additional overlay to it.

[Qbicz]

When I pass the -DDTC_OVERLAY_FILE to mcuboot/boot/zephyr/CMakeLists.txt the file is appended, but then the appended file is dropped in the boilerplate.cmake in line
set(DTC_OVERLAY_FILE "${DTC_OVERLAY_FILE}" CACHE STRING
https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/app/boilerplate.cmake#L369

Turns out this bug is duplicate of mcu-tools/mcuboot#399
I may be caused by confusion between lists and strings in CMake.

MCUBOOT_OVERLAYis/home/fi/ncs/nrf/samples/nrf_desktop/configuration/nrf52840_pca20041/flash.overlay
MCUBOOT_OVERLAYis/home/fi/ncs/nrf/samples/nrf_desktop/configuration/nrf52840_pca20041/flash.overlay /home/fi/ncs/mcuboot/boot/zephyr/dts.overlay
Zephyr version: 1.14.0
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4") 
-- Selected BOARD nrf52840_pca20041
BOILERPLATE_OVERLAYis/home/fi/ncs/nrf/samples/nrf_desktop/configuration/nrf52840_pca20041/flash.overlay /home/fi/ncs/mcuboot/boot/zephyr/dts.overlay
BOILERPLATE_OVERLAYis/home/fi/ncs/nrf/samples/nrf_desktop/configuration/nrf52840_pca20041/flash.overlay /home/fi/ncs/mcuboot/boot/zephyr/dts.overlay
HERE DTC_OVERLAY_FILE is cached
BOILERPLATE_OVERLAYis/home/fi/ncs/nrf/samples/nrf_desktop/configuration/nrf52840_pca20041/flash.overlay

[Qbicz]

The overlay list is passed around as a space-separated string "a.overlay b.overlay c.overlay". I don't know why caching drops one of the overlays. Removing this command
https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/app/boilerplate.cmake#L369 results in all overlays being applied.

[carlescufi]

@SebastianBoe @mbolivar could it be that DTC_OVERLAY_FILE expects filenames separate by semicolon instead of space?

[SebastianBoe]

@hakonfam : FYI

[Qbicz]

Using a space separated string is expected in dts.cmake and should work as long as full string is passed to dts.cmake from app/boilerplate.cmake:
https://github.com/zephyrproject-rtos/zephyr/blob/master/cmake/dts.cmake#L37

It is only the caching in boilerplate.cmake that strips the other overlays and only passes one. I don't really understand why. Workaround would be to disable cache in
set(DTC_OVERLAY_FILE "${DTC_OVERLAY_FILE}" CACHE STRING.