preload files to 9160?

[Loren Rogers]

Hello,

I'm working on an application that will use the nrf9160/nrf52.  I will need to make https REST calls where I will populate the http header with username/password credentials.  It's a huge security hole for me to hardcode those credentials AND we want to make it per-device specific (there will be many devices manufactured using the nrf91/nrf52 SoC.  So it would be ideal to preload some configuration file or something of the like which will represent the credentials to be accessed by the application that will be flashed after.  Also the production device will have no outside USB connection and the flash will be programmed using "pads".  Is there a way to send down something in some format to somewhere PRIOR to flashing the application?

Thanks

/Loren

[ovrebekk]

Hi Loren

If you have a debugger connected you could write a script that flashes some configuration data into a fixed location in flash. 

As long as you make sure that the application and other modules don't use this area of the flash for storing anything (code or data), you can then read out this information from the application at a later time. 

To access the flash through the debugger you can use the nrfjprog command line utility (or the pynrfjprog version, for Python). 

Best regards
Torbjørn

[Loren Rogers]

Hi Torbjorn!

Thank you for the quick response!  The plan is to create a custom board using the nrf9160 chip (not using DK board).  There will be no USB connectors on this board. Is there a way to attach a debugger with no USB connector?

/Loren

[ovrebekk]

Hi Loren

You mean in order to write to the flash from the debugger, right?

Looking at the documentation it appears there are no user variables available in the UICR for the nRF9160, which means you will need to write your data into the normal application flash instead (address range 0x0-0x100000). 

You need to find a free area of the flash that is not used for anything else, normally this would be at the top of the memory range, allowing room for the application at the bottom. 

In order to write to the flash using the debugger you can use commands similar to the ones shared in the link you sent:

nrfjprog -f NRF91 --memwr 0x000XXXXX --val 0x1234abcd

To read from the flash internally from the MCU all you have to do is refer to the same memory address, something like this:

const uint32_t * flash_ptr = (uint32_t*)0x00001234;

uint32_t flash_data = *flash_ptr;

Best regards
Torbjørn

[Loren Rogers]

Hi Torbjorn!

So my application is using TFM. If I look at my zephr.dts file I see:

flash0: flash@0 {
					compatible = "soc-nv-flash";
					label = "NRF_FLASH";
					erase-block-size = < 0x1000 >;
					write-block-size = < 0x4 >;
					reg = < 0x0 0x100000 >;
					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 >;
						};
					};

And from what I can understand from the documentation If I do a pm.yml that will make the partitions in the zephyr.dts ignored.  In the zephyr.dts I see 6 partitions.  The last one being storage_partition.  With a size of 0x6000 starting at 0xfa000.  Can I use this "storage_partition" to write my data?

If I cannot do that, then do I make a pm.yml for "settings"?  Kinda like pm.yml.settings?

Another question I have is will this entity I'm creating (single application) require multi-image?  Whether or not I need multi-image or single-image is confusing me.  I am using TFM and I do have a subfolder called "child_image" and there is just the mcuboot.conf.

Thanks!

/Loren

[ovrebekk]

Hi Loren

Normally you would use pm_static.yml to override the default partitions, or you would have to override the DTS configuration in an overlay or a custom board file. 

The storage_partition is typically accessed through some file system, and I would not recommend using this partition unless you can find some way to write the data from the application through the same file system. 

Instead I would recommend setting up your own little partition in a separate page of the flash, and use this for constant flash parameters. 

In order to do this you would need to reduce the size of the slot0 and slot1 partitions a little, to free up some spare room in the flash. 

By multi image do you mean the slot0 and slot1 images, or the secure and non-secure (ns) image?

MCUboot requires two slots two work, so you will always have a slot0 and a slot1 image (some times also referred to as the primary and secondary image). 

Having a secure and non secure image is necessary if you plan to use the TF-M module, since this module is designed to run in a secure partition while Zephyr and your application runs in the non secure partition. 

Best regards
Torbjørn

[Loren Rogers]

Hi Torbjorn,

I have some questions:

1. To modify slot0 and slot1 partitions, do I make a pm.yml?  Or do I make a file called nrf9160dk_nrf9160\nrf9160dk_nrf9160_common.dts in boards?  Or do I make a file called nrf9160dk_nrf9160_partition_conf.dts in boards?  In other words what build-related files do I need to create/modify in order to make partition size adjustments.

2. Do I modify both the secure and non-secure partitions for slot0 and slot1?

3. Does this new area need to be partitioned in order to use the 'nrfjprog' address writer?

4. You said in a previous comment in this thread: "You need to find a free area of the flash that is not used for anything else, normally this would be at the top of the memory range, allowing room for the application at the bottom. ". My question is Wouldn't I adjust the storage_partition partition as this is the top-most partition? Please refer to zephyr.dts I pasted in a previous message in this thread.

Thank you

/Loren

[Loren Rogers]

I believe I asnwered #1.  I modified the nrf9160dk_nrf9160_ns.overlay file.  This is my new Zephyr.dts flash:

				flash0: flash@0 {
					compatible = "soc-nv-flash";
					label = "NRF_FLASH";
					erase-block-size = < 0x1000 >;
					write-block-size = < 0x4 >;
					reg = < 0x0 0x100000 >;
					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 0x38000 >;
						};
						slot0_ns_partition: partition@48000 {
							label = "image-0-nonsecure";
							reg = < 0x48000 0x28000 >;
						};
						slot1_partition: partition@76000 {
							label = "image-1";
							reg = < 0x76000 0x40000 >;
						};
						slot1_ns_partition: partition@b6000 {
							label = "image-1-nonsecure";
							reg = < 0xb6000 0x3a000 >;
						};
						scratch_partition: partition@f0000 {
							label = "image-scratch";
							reg = < 0xf0000 0xa000 >;
						};
						storage_partition: partition@fa000 {
							label = "storage";
							reg = < 0xfa000 0x6000 >;
						};
					};
				};

[ovrebekk]

Hi

1. I believe this earlier answer from Didrik covers this pretty well. Essentially you can copy the partitions.yml file from your build folder, put it in your main project folder (next to the CMakeLists.txt file), rename it to pm_static.yml, and make the changes to the partitions as you like.

2. You have to figure out how much room you need for the secure and non secure partitions respectively. If you use the standard sample I believe 32kB should be sufficient for the secure slot, and the rest you can assign to the non secure slot which will be used by your application. 

One important point is that you need to make sure the two secure partisions (slot0_partition and slot1_partition) are the same size, and the same for slot0_ns_partition and slot1_ns_partition. 

3. The most important aspect is that no other partitions cover this area, and start filling it with data. The most safe way to do this is to put another partition there using the pm_static.yml file that I mentioned earlier. 

4. I would suggest putting this partition either just before or just after the storage_partition. 

Best regards
Torbjørn