Porting child image based project to sysbuild

[C.Thilo]

Hi

We are currently porting a project with a custom board and custom netcore image to sysbuild.

My current problem is, that we have a custom project for the netcore image which was added to the appcore project via CMakeLists.txt and add_child_image.

How is this done via sysbuild nowadays?

The former child image needs to be build during appcore build and added to the domain netcore so sysbuild recognizes it.

I tried it with the sysbuild cmake file:

ExternalZephyrProject_Add(
    APPLICATION net_core
    SOURCE_DIR "${CMAKE_CURRENT_LIST_DIR}/../netcore-project"
    BOARD pan_ng_module/nrf5340/cpunet
)

set_property(GLOBAL PROPERTY DOMAIN_APP_CPUNET net_core)
set(CPUNET_PM_DOMAIN_DYNAMIC_PARTITION net_core CACHE INTERNAL "")

add_dependencies(${DEFAULT_IMAGE} net_core)

But then there is the net_provision.hex which I don't know why it is produced!
Do I need to define the image for the netcore domain differently?

Thanks for any hint!

Cheers,
Thilo

[Einar Thorsrud]

Hi Thilo,

You normally only need to add a kconfig.sysbuild as explained under Adding custom network core images.

The creation of net_provision.hex does not indicate an issue I believe, as that is generated if you have secure boot for the net core enabled. See Migrating from multi-image builds to sysbuild. You do not get it if you disable secure boot for the network core with SB_CONFIG_SECURE_BOOT_NETCORE=n in sysbuild.conf.

[C.Thilo]

Hi Einar

thank you for your answer!
Then I will ignore net_provision.hex, cause we need the b0n bootloader to be able to update the net-core.

Another question is, why the merged.hex is not generated anymore?

The Build works and it generates the zephyr.hex files for mcuboot, cpuapp app, b0n and cpunet app (and net_provision.hex). So usually I would expect the merged.hex files. Was the generating of the merged.hex files remove?

Thank you for your time!

Cheers,
Thilo

[C.Thilo]

Hi Einar

nope.

With 3.4.0-rc1 the PCD CMakelists.txt still contains the problem, that it does not recognize the correct offset from the devicetree partitioning.

...../nrf-sdk-3.4.0/ZephyrSDK/nrf/subsys/pcd/src/pcd.c: In function 'network_core_pcd_cmdset':
<command-line>: warning: overflow in conversion from 'long long unsigned int' to 'off_t' {aka 'long int'} changes value from '18446744073692809216' to '-16742400' [-Woverflow]
...../nrf-sdk-3.4.0/ZephyrSDK/nrf/subsys/pcd/src/pcd.c:205:49: note: in expansion of macro 'PCD_NET_CORE_APP_OFFSET'
  205 |         err = pcd_cmd_write(cmd, src_addr, len, PCD_NET_CORE_APP_OFFSET);

and the net_provision.hex has the same problem.

Error: One or more batch tasks failed:
* 600104758: Device error: Address range 0x000085a8..0x000085c8 is outside the memory ranges defined for programming through the Network core (Generic)

Address range is without the offset of flash1.

Here are the changes which I need to add to make it work.
Theses are workarounds and not fixes, but perhaps you understand better why I need to make theses and can give me an hint!

diff --git a/scripts/bootloader/provision.py b/scripts/bootloader/provision.py
index 0998176b75..7503e63c12 100644
--- a/scripts/bootloader/provision.py
+++ b/scripts/bootloader/provision.py
@@ -269,7 +269,7 @@ def main():
     # The LCS and implementation ID is stored in the OTP before the
     # rest of the provisioning data so add it to the given base
     # address
-    provision_address = args.provision_addr + num_bytes_provisioned_elsewhere
+    provision_address = args.provision_addr + 0x1000000 + num_bytes_provisioned_elsewhere
     max_size = args.max_size - num_bytes_provisioned_elsewhere
 
     hashes = []
diff --git a/subsys/pcd/CMakeLists.txt b/subsys/pcd/CMakeLists.txt
index bdc04c4a65..d00fabef65 100644
--- a/subsys/pcd/CMakeLists.txt
+++ b/subsys/pcd/CMakeLists.txt
@@ -19,6 +19,7 @@ if(CONFIG_PCD_APP AND NOT CONFIG_PARTITION_MANAGER_ENABLED)
   # TODO: Likely need rework when mapped-partition is available/used
   dt_chosen(flash_path PROPERTY "zephyr,flash" TARGET b0n_target)
   dt_reg_addr(flash_address PATH ${flash_path} TARGET b0n_target)
-  math(EXPR s0_offset_address "${s0_partition_address} - ${flash_address}" OUTPUT_FORMAT HEXADECIMAL)
+  message("remove \" - \${flash_address}\"")
+  math(EXPR s0_offset_address "${s0_partition_address}" OUTPUT_FORMAT HEXADECIMAL)
   zephyr_library_compile_options("-DPCD_NET_CORE_APP_OFFSET=${s0_offset_address}")
 endif()

Cheers
Thilo

[Einar Thorsrud]

Hi Thilo,

I see. I have discussed this internally but we are not able to explain why you see this. I suspect there may be some problems with your device tree configuration (from your board files or overlays), but I am having problems understanding how. Have you compared your board files to the DK files in v3.4.0-rc1 or main?

[C.Thilo]

We created two dtsi files with the content generated via pm_to_dtsi.py. 
Added compatible fixed-partitions and address-cells and size-cells, both 1, and included theses dtsi into our common.dtsi files.

Here is the cpunet_partitions.dtsi:

/ {
	chosen {
		zephyr,code-partition = &cpunet_app_partition;
	};
};

&flash1 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;
		b0n_partition: partition@0 {
			label = "b0n";
			reg = <0x0 0x8580>;
		};

		bl_storage: provision_partition: partition@8580 {
			label = "b0-provision-data";
			reg = <0x8580 0x280>;
		};

		cpunet_app_partition: s0_partition: partition@8800 {
			label = "cpunet_app";
			reg = <0x8800 0x10000>;
		};
	};
};

For b0n there is an overlay, so it is placed into the b0n_partition:

/ {
    chosen {
        zephyr,code-partition = &b0n_partition;
    };
};

Thats it. 
Other partitions (besides for the cpuapp in flash0) we do not have in our devicetree.

When I add the flash offset to the parition offset, than the cpunet app has the wrong offset when trying to flash:

-- runners.nrfutil: Flashing file: ..../build/net_core/../signed_by_b0_net_core.hex
-- runners.nrfutil: Connecting to probe
-- runners.nrfutil: Erasing address ranges touched by firmware
Error: One or more batch tasks failed:
 * 600104758: Device error: Address range 0x02008800..0x0200fa18 is outside the memory ranges defined for programming through the Network core (Generic)

So on the one hand, the flash offset is added, and on the other it is not.

Any ideas?

Cheers,
Thilo

[Einar Thorsrud]

Hi Thilo,

Looking at the error "Address range 0x02008800..0x0200fa18 is outside the memory ranges defined for programming through the Network core (Generic)", it seems you have some remains of earlier attempts of adding the 0x01000000 offset, and so that is added twice. That needs to be reverted.

[C.Thilo]

Yeah correct but! Here we go:



Partition Offset 0x1008800 in the partitions dtsi:
Error one:

-- runners.nrfutil: Flashing file: ..../build/net_core/../signed_by_b0_net_core.hex
-- runners.nrfutil: Connecting to probe
-- runners.nrfutil: Erasing address ranges touched by firmware
Error: One or more batch tasks failed:
 * 600104758: Device error: Address range 0x02008800..0x0200fa18 is outside the memory ranges defined for programming through the Network core (Generic)

Partition Offset 0x8800 without changes of me at the nrfsdk:
Error one:

/media/data/projects/pan-ng/nrf-sdk-3.3.0/ZephyrSDK/nrf/subsys/pcd/src/pcd.c: In function 'network_core_pcd_cmdset':
<command-line>: warning: overflow in conversion from 'long long unsigned int' to 'off_t' {aka 'long int'} changes value from '18446744073692809216' to '-16742400' [-Woverflow]
<command-line>: note: in definition of macro 'PCD_NET_CORE_APP_OFFSET'

Error two:

- runners.nrfutil: Flashing file: /media/data/projects/pan-ng/nrf-sdk-3.3.0/PAN-NG-PROD_APPCORE/build/net_provision.hex
-- runners.nrfutil: Connecting to probe
-- runners.nrfutil: Erasing address ranges touched by firmware
Error: One or more batch tasks failed:
* 600104758: Device error: Address range 0x000085a8..0x000085c8 is outside the memory ranges defined for programming through the Network core (Generic)

Either way, something wents wrong!
IMHO, the parition offset with 0x8800 is the correct one in devicetree, so I tried to fix that.

Cheers,
Thilo

[Einar Thorsrud]

Hi Thilo,

I see. I am not able to understand what is going on there. I put together (with help of AI) a minimal sample that demonstrat a nRF5340 project with mcuboot and b0n using sysbuild and without partition manager. This builds for the DK and seems to work as expected. Can you use that as a reference? It whoudl work out of the box on a nRF5340 DK when built with NCS v3.4.0-rc1 (and can together with the DK board files hopefully be used as a reference for your custom board).sysbuild_netcore_demo.zip

[C.Thilo]

Hi Einar

any new ideas?

Cheers
Thilo

[Einar Thorsrud]

Hi Thilo,

Not in the sense that I am not sure why things are not working with your project. But have you had a look at the demo I uploded earlier today? Does that work for you as well, and if so can you use that as a reference?