Fault When Reading Magic From Image Header

RE: Fault When Reading Magic From Image Header

Vidar Berg — Fri, 03 Sep 2021 13:21:49 GMT

Hi Peter,

Thanks for confirming that it worked for you as well! I forgot to add that the memory layout is controlled by Partition Manager when its enabled (always enabeld for multi-image builds), and not by the paritions defined in DTS.

Best regards,

Vidar

RE: Fault When Reading Magic From Image Header

uhrm — Fri, 03 Sep 2021 13:10:41 GMT

Hey Vidar,

That did the trick, I confirm that I can now read the header of the image when I have both the mcuboot and spm enabled.

Thanks for the help!

Best regards

Peter

RE: Fault When Reading Magic From Image Header

Vidar Berg — Fri, 03 Sep 2021 12:44:59 GMT

Hi Peter,

I've discussed this case with a colleague now. Turns out you need to use the SPMs secure services to get read access to the MCUBoot pad area when SPM is enabled. I quickly verified that it worked here with this code:

#include "secure_services.h"

void main(void)	
{
	uint32_t mcuboot_magic;

	int err = spm_request_read(&mcuboot_magic, 0x10000, sizeof(mcuboot_magic));
	if (err) {
		printk("Failed to read from MCUBoot pad area at 0x10000 (err %d)\n", err);
	} else {
		printk("MCUBoot magic word %x\n", mcuboot_magic);
	}

Regards,

Vidar

RE: Fault When Reading Magic From Image Header

uhrm — Thu, 02 Sep 2021 12:41:05 GMT

Hi Vidar,

As a test I disabled mcuboot, and the resulting layout is below.

Everything got shifted to lower memory addresses due not having the mcuboot, but the application is still located in the secure partition starting at 0x10000 even though (as mentioned in an earlier post) it is specified to go to the non secure partition.

I am able to read the flash at 0x10000 without getting the fault, but now I don't have the mcuboot to handle the firmware updates.

So my question is, what is the dependency between having the mcuboot enabled and reading out of flash from the secure area? In both cases the SPM is enabled.

Regards

Peter

RE: Fault When Reading Magic From Image Header

uhrm — Wed, 01 Sep 2021 15:31:23 GMT

Hi Vidar,

Per your question, looking at the MAP files and memory of the device, here is what I have:

1. Image header @ 0x10000 (512 bytes total: 32 header bytes + padding bytes)

2. SPM code @ 0x10200

3. Application 'code @ 0x20200

Thoughts?

Regards

Peter

RE: Fault When Reading Magic From Image Header

Vidar Berg — Wed, 01 Sep 2021 14:57:02 GMT

Hi Peter,

Sorry, I didn't notice the discrepancy between DTS and what was printed by the partition manager, I just assumed they would be the same. Could you check if you have anything at 0x20000? Based on the partition manager and *.map output, the NS app is starting 0x20200.

I will find out why the DTS and Partition manager don't operate with the same addresses in the meantime.

RE: Fault When Reading Magic From Image Header

uhrm — Wed, 01 Sep 2021 14:30:24 GMT

Hi Vidar,

See the layout in my project below, which looks similar to the one you sent:

Regarding the secure and non-secure partitions, in the DTS they are currently as follows:

partitions {
						compatible = "fixed-partitions";
						#address-cells = < 0x1 >;
						#size-cells = < 0x1 >;
						boot_partition: partition@0 {
							label = "mcuboot";
							reg = < 0x0 0x10000 >;
						};
						slot0_partition: partition@10000 {
							label = "image-0";
							reg = < 0x10000 0x40000 >;
						};
						slot0_ns_partition: partition@50000 {
							label = "image-0-nonsecure";
							reg = < 0x50000 0x30000 >;
						};
						slot1_partition: partition@80000 {
							label = "image-1";
							reg = < 0x80000 0x40000 >;
						};
						slot1_ns_partition: partition@c0000 {
							label = "image-1-nonsecure";
							reg = < 0xc0000 0x30000 >;
						};
						scratch_partition: partition@f0000 {
							label = "image-scratch";
							reg = < 0xf0000 0xa000 >;
						};
						storage_partition: partition@fa000 {
							label = "storage";
							reg = < 0xfa000 0x6000 >;
						};
					};

From looking into memory, I don't have anything in the non secure partition at 0x50000, but I do in the secure one at 0x10000. Not sure why this is happening because the board file I use specifies the code to be in the non-secure partition:

zephyr,code-partition = &slot0_ns_partition;

Thoughts?

Regards

Peter

RE: Fault When Reading Magic From Image Header

Vidar Berg — Wed, 01 Sep 2021 13:31:30 GMT

Hi Peter,

Yes I was wondering if you built the app as non-secure. I think you may be attempting to read from the mcu pad area for the SPM which runs in the Trust Zone secure domain.

Here is a screenshot I took from VS code with the new nRF connect plug-in to illustrate what the typical memory layout may look like:

Notice that the main non-secure application starts after the SPM at 0x50000.

Best regards,

Vidar

RE: Fault When Reading Magic From Image Header

uhrm — Wed, 01 Sep 2021 13:13:35 GMT

Hi Vidar,

I am using a non-secure board for the 9160, but we do have the mcuboot enabled and the application is signed. Is this what you refer about the secure domain?

All I want to do is to read the header and some of the TLV information from the application, so I can send it to a master SPI peripheral which will compare it to a locally stored 9160 image and determine if an update is needed.

If I can't read the header and TLV information from the 9160, what options do I have to accomplish this?

In the meantime I will check about the debug log as well.

Best regards

Peter

RE: Fault When Reading Magic From Image Header

Vidar Berg — Wed, 01 Sep 2021 12:44:19 GMT

Hello,

Is there a chance that the source pointer may be pointing to the secure domain? Do you have any debug logs from the device? I think the crashlog might provide some more clues. Just make sure you have CONFIG_RESET_ON_FATAL_ERROR set to 'n' in your prj.conf file for both SPM and your app to prevent it from entering a boot loop.

Best regards,

Vidar

RE: Fault When Reading Magic From Image Header

uhrm — Tue, 31 Aug 2021 13:45:14 GMT

Forgot to add, this is happening in an nRF9160. I have tried the same in an nRF5340 and I don't see the issue.