<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Static Partition Alignment</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/113714/static-partition-alignment</link><description>Hi, We have a few questions regarding the pm_static.yml file that&amp;#39;s used for defining flash partitions in zephyr. Our main questions are regarding alignment; we&amp;#39;ve created a partition &amp;quot;device_details_partition&amp;quot; where we plan on writing configuration values</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 20 Aug 2024 12:15:55 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/113714/static-partition-alignment" /><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/499043?ContentTypeID=1</link><pubDate>Tue, 20 Aug 2024 12:15:55 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:42c4e4ef-e2fd-407d-b354-b835fb8d7445</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;I&amp;#39;m glad to hear that it worked, thanks for the update. The developers have made the following PRs to add support for reading the OTP registers in future SDK releases:&lt;/p&gt;
&lt;p&gt;&amp;nbsp;-&amp;nbsp;&lt;a id="" href="https://github.com/nrfconnect/sdk-nrf/pull/16927"&gt;https://github.com/nrfconnect/sdk-nrf/pull/16927&lt;/a&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;&amp;nbsp;-&amp;nbsp;&lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK_dev/doc/PR-16890/nrf/libraries/security/tfm/tfm_ioctl_api.html#read-service"&gt;https://developer.nordicsemi.com/nRF_Connect_SDK_dev/doc/PR-16890/nrf/libraries/security/tfm/tfm_ioctl_api.html#read-service&lt;/a&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Best regards,&lt;/p&gt;
&lt;p&gt;Vidar&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/497960?ContentTypeID=1</link><pubDate>Tue, 13 Aug 2024 08:10:28 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:44e81fb4-f515-4708-b2f5-6bf0ecd16d40</guid><dc:creator>hugzy123</dc:creator><description>&lt;p&gt;Hi Vidar,&amp;nbsp;&lt;br /&gt;&lt;br /&gt;Thanks for your reply.&lt;br /&gt;&lt;br /&gt;Apologies I should have mentioned I&amp;#39;m using nRF connect sdk v2.2.0.The &lt;span&gt;tfm_read_ranges.h file is in a different directory but seems to work the same with the changes applied.&lt;/span&gt;&lt;br /&gt;I found the file in &amp;quot;NRF_SDK\2.2.0\nrf\include\tfm\tfm_read_ranges.h&amp;quot;&lt;br /&gt;&lt;br /&gt;I think the function to read from the secure flash are different in this SDK version too, I used &amp;quot;secure_read_word&amp;quot; instead.&lt;br /&gt;&lt;br /&gt;Thanks,&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/497777?ContentTypeID=1</link><pubDate>Mon, 12 Aug 2024 11:11:22 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8ecaf7ab-46a0-4104-b706-3d180b3281d8</guid><dc:creator>Vidar Berg</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Yes, the UICR ranges you want to access from the app need to be added to the tfm-read ranges. Below is an example patch I made for the tfm_read_ranges.h header located in /v2.7.0/nrf/modules/trusted-firmware-m/tfm_boards/services/include:&lt;br /&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;pre class="ui-code" data-mode="text"&gt;diff --git a/modules/trusted-firmware-m/tfm_boards/services/include/tfm_read_ranges.h b/modules/trusted-firmware-m/tfm_boards/services/include/tfm_read_ranges.h
index a11c412a3..a393c1b73 100644
--- a/modules/trusted-firmware-m/tfm_boards/services/include/tfm_read_ranges.h
+++ b/modules/trusted-firmware-m/tfm_boards/services/include/tfm_read_ranges.h
@@ -39,6 +39,11 @@
 #define FICR_RESTRICTED_ADDR (FICR_BASE + 0x130)
 #define FICR_RESTRICTED_SIZE 0x8
 
+#ifdef NRF_UICR_S_BASE
+#define UICR_CUSTOMER_DATA_ADDR     ((uint32_t) &amp;amp;NRF_UICR_S-&amp;gt;OTP[0])
+#define UICR_CUSTOMER_DATA_SIZE 	(sizeof(uint32_t))
+#endif
+
 #if defined(FICR_SIPINFO_PARTNO_PARTNO_Pos)
 #define FICR_SIPINFO_ADDR (FICR_BASE + offsetof(NRF_FICR_Type, SIPINFO))
 #define FICR_SIPINFO_SIZE (sizeof(FICR_SIPINFO_Type))
@@ -74,6 +79,11 @@ static const struct tfm_read_service_range ranges[] = {
 #if defined(NRF_APPLICATION_CPUC_S)
 	{.start = CPUC_CPUID_ADDR, .size = CPUC_CPUID_SIZE},
 #endif
+#if defined(UICR_CUSTOMER_DATA_ADDR)
+	{ .start  = UICR_CUSTOMER_DATA_ADDR, .size = UICR_CUSTOMER_DATA_SIZE }, 
+#endif 
 };
 
+
+
 #endif /* TFM_READ_RANGES_H__ */&lt;/pre&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;And here is the test code I used to verify that it worked:&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;pre class="ui-code" data-mode="text"&gt;#include &amp;lt;soc_secure.h&amp;gt;

int main(void)
{
	int err;
	uint32_t read_buffer;

	printf(&amp;quot;Hello World! %s\n&amp;quot;, CONFIG_BOARD_TARGET);

	err = soc_secure_mem_read(&amp;amp;read_buffer, (void *)&amp;amp;NRF_UICR_S-&amp;gt;OTP[0], sizeof(uint32_t));
	if (err) {
		printf(&amp;quot;soc_secure_mem_read() failed. (err %d)\n&amp;quot;, err);
	} else {
		printf(&amp;quot;NRF_UICR_S-&amp;gt;OTP[0] : 0x%x\n&amp;quot;, read_buffer);
	}

	return 0;
}
&lt;/pre&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Writing the OTP register with nrfjprog:&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;&lt;pre class="ui-code" data-mode="text"&gt;$ nrfjprog --memwr 0xff8100  --val 0x12345&lt;/pre&gt;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Since the OTP region may be used to store secrets, TF-M does not expose this memory region by default.&amp;nbsp;&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Best regards,&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;Vidar&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/497512?ContentTypeID=1</link><pubDate>Thu, 08 Aug 2024 16:28:20 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:acc60f46-9892-49d7-a1de-1d331d3f33d7</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;That was a bummer, I will transfer the case to someone that can suggest how to do this using partion then.&lt;/p&gt;
&lt;p&gt;Kenneth&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/497455?ContentTypeID=1</link><pubDate>Thu, 08 Aug 2024 09:26:46 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:b14e1f5e-fd4c-44c9-b526-d1c608fbfaf4</guid><dc:creator>hugzy123</dc:creator><description>&lt;p&gt;If you look further down the &lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/92878/programming-and-reading-otp/422267"&gt;post&lt;/a&gt;, the nordic employee suggests this is an issue for the nRF5340 too.&lt;/p&gt;
&lt;p&gt;&lt;em&gt;&amp;quot;Unfortunately, this is not yet implemented on our side.&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;One can add ranges by appending this array:&amp;nbsp;&lt;a href="https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.6.0-ncs3/platform/ext/target/nordic_nrf/nrf9160dk_nrf9160/services/include/tfm_read_ranges.h#L25"&gt;https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.6.0-ncs3/platform/ext/target/nordic_nrf/nrf9160dk_nrf9160/services/include/tfm_read_ranges.h#L25&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;em&gt;Similarly for nrf5340,&amp;nbsp;&lt;a id="" href="https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.6.0-ncs3/platform/ext/target/nordic_nrf/nrf5340dk_nrf5340_cpuapp/services/include/tfm_read_ranges.h"&gt;https://github.com/nrfconnect/sdk-trusted-firmware-m/blob/v1.6.0-ncs3/platform/ext/target/nordic_nrf/nrf5340dk_nrf5340_cpuapp/services/include/tfm_read_ranges.h&lt;/a&gt;&amp;quot;&lt;br /&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;I&amp;#39;ve tried adding some code to read directly from the OTP area of the UICR&amp;nbsp;and using&amp;nbsp; &amp;quot;tfm_platform_mem_read&amp;quot; to read from the secure area but these both failed.&lt;br /&gt;&lt;br /&gt;Do I first need to add the UICR range into the nRF5340 tfm-read ranges?&lt;br /&gt;&lt;br /&gt;Thanks,&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/497338?ContentTypeID=1</link><pubDate>Wed, 07 Aug 2024 12:27:29 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:852da168-b865-49c7-b0e4-be9463be3b7e</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;Then it shouldnt&amp;#39; be a problem to use UICR for the application as you see fit no. The other case you refer to is for the nRF9160 and does not apply here.&lt;/p&gt;
&lt;p&gt;Kenneth&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/497290?ContentTypeID=1</link><pubDate>Wed, 07 Aug 2024 09:22:05 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:3511c15f-1398-4a42-add2-3369124f408c</guid><dc:creator>hugzy123</dc:creator><description>&lt;p&gt;Thanks for your reply.&lt;br /&gt;&lt;br /&gt;Before we moved over to zephyr we used the custom data section of the UICR on our old nRF52 board to store this information, however, we thought we &lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/92878/programming-and-reading-otp"&gt;couldn&amp;#39;t use UICR with TF-M in zephyr&lt;/a&gt;.&lt;br /&gt;&lt;br /&gt;I&amp;#39;ve just searched through our firmware and found&amp;nbsp;CONFIG_SECURE_BOOT is set to 1 in the multiprotocol_rpmsg networ core image, but not in our application. Would this prevent us from using OTP memory in the UICR?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/497235?ContentTypeID=1</link><pubDate>Tue, 06 Aug 2024 20:35:22 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:6f41fbed-9225-404e-acf1-09c44d397e46</guid><dc:creator>hmolesworth</dc:creator><description>&lt;p&gt;This is an issue which often arises, and often it is better to avoid messing with fixed memory locations and simply use an unused interrupt vector to point to the data which can then reside anywhere in flash and indeed move between builds. The advantage here is hijacking several vectors allows reading out software version, software CRCC, and other device details spread randomly through the code. Vectors are already at fixed known addresses, and daisy-chained vectors can be used if needed if traversing multiple bootloaders and the like.&lt;/p&gt;
&lt;p&gt;I like to increase the size of the vector table to use the extra space at the end instead of using an unused existing vector which might one day become used if the hardware evolve, though there are plenty of unused vectors in the standard tables.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Static Partition Alignment</title><link>https://devzone.nordicsemi.com/thread/497231?ContentTypeID=1</link><pubDate>Tue, 06 Aug 2024 19:57:39 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f9fc706b-caae-442f-8f44-fd7ed5b5f926</guid><dc:creator>Kenneth</dc:creator><description>&lt;p&gt;Hello,&lt;/p&gt;
&lt;p&gt;I assume you only intend to write some data to the device during production, and this data will not change during the lifetime of the product. In that case you can check out the OTP memory in the UICR (fyi: the OTP can be programmed several times during prototype development through the SWD interface, but it&amp;#39;s not programmable several times internally from the MCU, which is why I guess they call it OTP). Anyways, you can find a discussion here that may be useful. From the dicussion it seems like it&amp;#39;s only if you enable &lt;span&gt;CONFIG_SECURE_BOOT (NSIB) that you can&amp;#39;t use the OTP memory region to store your own data&lt;/span&gt;:&lt;br /&gt;&lt;a href="https://devzone.nordicsemi.com/f/nordic-q-a/100971/which-registers-in-the-uicr-of-the-nrf5340-are-reserved-for-user-access"&gt;https://devzone.nordicsemi.com/f/nordic-q-a/100971/which-registers-in-the-uicr-of-the-nrf5340-are-reserved-for-user-access&lt;/a&gt;&amp;nbsp;&lt;/p&gt;
&lt;p&gt;There is also some description in the nRF5340 PS if you search for &amp;#39;OTP&amp;#39;.&lt;/p&gt;
&lt;p&gt;Kenneth&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>