nRF9160 custom board bootloader problems

RE: nRF9160 custom board bootloader problems

AscherA — Fri, 27 Jan 2023 08:59:57 GMT

Hello Didrik,

thanks again for your help. I tried implementing the NVS-Sample(None-Volatile-Storage-Sample) and the sample seems to work with my setup. Which means I will try writing my configuration to the NVS Storage partition.

Best regards,

Andreas

RE: nRF9160 custom board bootloader problems

Didrik Rokhaug — Wed, 25 Jan 2023 13:34:52 GMT

No. The non-secure partition must start at a 32kB boundary, which means that there might be some empty space e´between the secure and the non-secure firmware if the secure FW doesn't use a whole multiplum of 32kB.

RE: nRF9160 custom board bootloader problems

AscherA — Tue, 24 Jan 2023 15:13:58 GMT

If I understand correctly this means, that the "EMPTY_0" partition is only a "filler", but it is automatically assigned to the secure partition of the TF-M. Is there a way to assign it to the none-secure partition?

RE: nRF9160 custom board bootloader problems

Didrik Rokhaug — Tue, 24 Jan 2023 14:44:47 GMT

[quote user="AscherA"]Is it possible that with the addition of the bootloader this empty flash partition was somehow locked by the TF-M secure functions and that is why I am not able to access it?[/quote]

Yes. The application (and non-secure flash area) must start at a 32kB boundary. If the TF-M partition isn't large enough to fill a whole sector, an empty partition will be inserted to enusre proper alignment of the non-secure area.

RE: nRF9160 custom board bootloader problems

AscherA — Tue, 24 Jan 2023 09:06:48 GMT

Hello Didrik,

after finding out the exact address of our empty flash portion I tried to change our flash read function accordingly, but unfortunately this did not work and the nrf9160 still just restarts, when trying to read the flash partition.

Is it possible that with the addition of the bootloader this empty flash partition was somehow locked by the TF-M secure functions and that is why I am not able to access it?

Best regards,

Andreas

RE: nRF9160 custom board bootloader problems

AscherA — Mon, 23 Jan 2023 12:38:19 GMT

Hello Didrik,

thank you for the information. I checked my partitions.yml and have gone through all its entries.

The flash partition I am trying to access is at the address 0xfa000 and the flash_size I am tying to access is 0x6000.

The first entry in my partitions.yml is:

EMPTY_0:
  address: 0xf4000
  end_address: 0x100000
  placement:
    after:
    - mcuboot_secondary
  region: flash_primary
  size: 0xc000
app:
  address: 0x1c200
  end_address: 0x80000
  region: flash_primary
  size: 0x63e00

This should mean that the portion of the flash I am trying to access should be empty and not used by any other part of the application, if I am reading the partitions.yml right.

Also all the others partitions.yml entries to not use the specified flash memory partition.

Best regards,

Andreas

RE: nRF9160 custom board bootloader problems

Didrik Rokhaug — Fri, 20 Jan 2023 14:12:04 GMT

In NCS, we don't use the flash partitioning from the device tree, instead, we use the Partition Manager, which dynamically partitions the flash when you build the project.

You can find the resulting partition map in <your build folder>/partitions.yml. Could you check if the address you try to read from is not taken by MCUBoot or TF-M (and therefore not accessible from the non-secure application).

RE: nRF9160 custom board bootloader problems

AscherA — Wed, 18 Jan 2023 09:24:16 GMT

Hi Didrik,

unfortunately my original assessment was wrong. My nrf9160 does start my application even with the bootloader, but when I try to access my configuration the board restarts. Since accessing my configuration is the first point in my application it seemed like the bootloader was the cause.
But without the bootloader my application is working fine and my configuration can be recalled by the app.

Here some details about my configuration:

I am storing the configuration in the storage_partition of the nrf9160. Here you can see my board configuration:

&flash0 {

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

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x00000000 0x10000>;
		};
		slot0_partition: partition@10000 {
			label = "image-0";
		};
		slot0_ns_partition: partition@50000 {
			label = "image-0-nonsecure";
		};
		slot1_partition: partition@80000 {
			label = "image-1";
		};
		slot1_ns_partition: partition@c0000 {
			label = "image-1-nonsecure";
		};
		scratch_partition: partition@f0000 {
			label = "image-scratch";
			reg = <0x000f0000 0xa000>;
		};
		storage_partition: partition@fa000 {
			label = "storage";
			reg = <0x000fa000 0x00006000>;
		};
	};
};

The custom board is derived from the nrf9160dk_nrf9160 and there are only minimal changes to the configurations as can be seen for example in the partition management which is the same as the nrf9160dk.
To be able to store the configuration we used the "zephyr/drivers/flash.h" flash functions. Like mentioned above as soon as the application triggers the my custom "flash_data_read" function, the whole board panics and restarts.

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// read flash
int flash_data_read(void)
{
    //FLASH_SIZE defined above with 0x6000
    int result = flash_read(flash_dev,0xfa000, ptr_flash,FLASH_SIZE);

    //LOG_INF("Read config from flash -> result: %d", result);

    return result;
}

I though I made sure that none of the other functions used by my application uses this partition in any way. I also looked at the MCUBoot documentation and there is not mentioning of the storage_partition:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-zephyr.html

Without the bootloader the configuration does not cause any problem. Is the storage_partition used by the bootloader in any way?

Since this is not directly connected to my original question please let me know if i should open a new topic for this problem.

Best regards,

Andreas

RE: nRF9160 custom board bootloader problems

AscherA — Tue, 17 Jan 2023 14:57:44 GMT

Hi Didrik,

I tested adding the MCUBoot to the hello_world sample and I also build it with my custom secure board.

This worked fine without any problems. I tested this with the tfm_hello_world and the hello_world sample both started normal.

Best regards,

Andreas

RE: nRF9160 custom board bootloader problems

AscherA — Tue, 17 Jan 2023 07:47:40 GMT

Hi Didrik,

thanks for your help.

Yes my application fails to boot after I add the bootloader. I first added the FOTA library to be able to do a firmware update and after implementing it into my application I realized that I need the bootloader because my building process did not manufacture the app_update.bin output file.

I will try you suggestion and come back to you with the results.

Best regards,

Andreas

RE: nRF9160 custom board bootloader problems

Didrik Rokhaug — Mon, 16 Jan 2023 17:05:49 GMT

Hi,

Did I understand you correctly that the application failed to boot when you added the bootloader?

Or did it work with a bootloader, but when you changed the settings for the bootloader, it failed?

What happens if you try to run an application built for the secure domain?

E.g. try add MCUBoot (with your added configurations) to the hello_world sample, and build for the secure version of the board (the one that doesn't end with "_ns").

Best regards,

Didrik