nrf_security: Allow setting the kmu reserved area with dts

The kmu_push_area was only allowed to be set with dts
for the ram images. Now more images will use it and
hence the dependency on RAM images is removed.

Also create a Kconfig which depends on the dts entry
so that it can be used in the build system.

Signed-off-by: Georgios Vasilakis <[email protected]>

Author: Vge0rge

subsys/nrf_security/src/drivers/cracen/Kconfig

@@ -19,6 +19,9 @@ config CRACEN_NEED_MULTIPART_WORKAROUNDS
 config CRACEN_NEED_IKG_INTERRUPT_WORKAROUND
 	def_bool SOC_NRF54LM20A || SOC_NRF54LV10A
 
+config CRACEN_KMU_RESERVED_MEMORY_IN_DTS
+	def_bool "$(dt_nodelabel_enabled,nrf_kmu_reserved_push_area)"
+
 # Configure CRACEN_LOG_LEVEL
 module = CRACEN
 module-str = CRACEN

subsys/nrf_security/src/drivers/cracen/cracenpsa/src/kmu.c

@@ -33,16 +33,7 @@ extern nrf_security_mutex_t cracen_mutex_symmetric;
 
 #define KMU_PUSH_AREA_SIZE 64
 
-/* When execution in place (CONFIG_XIP) is not enabled, which in practice means that when Zephyr is
- * built for a RAM loaded image, the Zephyr linker script always places the RAM loaded image in the
- * top address of the RAM and then loads the linker scripts defined with the Zephyr SECTION_PROLOGUE
- * macros. Using SECTION_PROLOGUE macros to set the address of the kmu_push_area is
- * incompatible with RAM loaded images. The Zephyr reserved-memory devicetree methodology works for
- * both use cases but it requires heavy updates of multiple devicetree files and overlays. In order
- * to support the RAM loaded images use cases faster initial support for reserving the memory of
- * nrf_kmu_reserved_push_area though devicetree is limited to RAM loaded images.
- */
-#if DT_NODE_EXISTS(DT_NODELABEL(nrf_kmu_reserved_push_area)) && !CONFIG_XIP
+#if DT_NODE_EXISTS(DT_NODELABEL(nrf_kmu_reserved_push_area))
 
 #include <zephyr/dt-bindings/memory-attr/memory-attr.h>
 #include <zephyr/linker/devicetree_regions.h>