CONFIG_HW_UNIQUE_KEY_LOAD does not work with CONFIG_DISABLE_FLASH_PATCH

Hi,

I do not immediately see why this combination should not work. Can you upload your modified example configuration which includes B0 etc so that I can test on my end?

Just add CONFIG_DISABLE_FLASH_PATCH=y to b0.conf. I tested with nRF52840 DVK.

Hi,

When I test with this change it works on my end, using both SDK 1.9.0 and 1.9.1. Have you made any other changes as well? Can you elaborate on how you test?

nrfjprog --deviceversion

NRF52840_xxAA_REV1

You need to ensure you start with a completely blank device or you will not see the issue:

nrfjprog -e
Erasing user available code and UICR flash areas.
Applying system reset.

This is the entire diff of the nrf folder:

diff --git a/samples/keys/hw_unique_key/child_image/b0.conf b/samples/keys/hw_unique_key/child_image/b0.conf
index 180ca7ccc..0e3e38615 100644
--- a/samples/keys/hw_unique_key/child_image/b0.conf
+++ b/samples/keys/hw_unique_key/child_image/b0.conf
@@ -4,4 +4,5 @@
 # SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
 #
 
+CONFIG_DISABLE_FLASH_PATCH=y
 CONFIG_HW_UNIQUE_KEY_LOAD=y

My build command, executed from the nrf folder:

west build -p -b nrf52840dk_nrf52840 -d build samples/keys/hw_unique_key

Flash the code:

west flash -d build   

Output of the DVK on the serial console:

First boot, expecting app to write HUK.
Error: Hardware Unique Key not present.

Ah, you are right. No idea why I did not see this before. I am not able to answer this right now but I am checking with the team working on this and will get back to you.

Hi,

I am sorry for the late update. What is happening is essentially this:

1. (b0 PRE_KERNEL2) Bootloader sees that a key is not written, and writes its own flag in flash to keep track of this. It now assumes the app will be booted and will write a HUK.
2. (b0 POST_KERNEL) Flash patch is disabled and the device is rebooted for the configuration to take effect.
3. (b0 PRE_KERNEL2) Bootloader sees that a key is not written, and that it has written the flag. It assumes the app was unsuccessful in writing a HUK so it throws an error.

The team is made aware of this now and will look into hw to do handle this properly.

Hi,

I am sorry for the late update. What is happening is essentially this:

1. (b0 PRE_KERNEL2) Bootloader sees that a key is not written, and writes its own flag in flash to keep track of this. It now assumes the app will be booted and will write a HUK.
2. (b0 POST_KERNEL) Flash patch is disabled and the device is rebooted for the configuration to take effect.
3. (b0 PRE_KERNEL2) Bootloader sees that a key is not written, and that it has written the flag. It assumes the app was unsuccessful in writing a HUK so it throws an error.

The team is made aware of this now and will look into hw to do handle this properly.