MCUXpresso Secure Provisioning ToolのトピックSecurity boot type change.

Security boot type change.

Seongyon_Jeong — Mon, 07 Jul 2025 07:29:47 GMT

First, I Succeeded booting on Toolbar [Boot][Authenticated(HAB)] , [LC][closed,HAB enabled]

But. on the same board,
I changed the option of Boot, [Boot][XIP encrypted(BEE user Keys) authenticated] [LC][closed,HAB enabled]

this XIP project` flash resion, 0x6000_0000 , size 0x20000 , so I set the region like upper capture image.

and.. When Build Image on SEC , it is Successful and then write Image action is also successful

But, DipSwitch change to internal mode, and after reset, It is not woking....

lastly, again. Toolbar [Boot][Authenticated(HAB)] , Build-Write Image. -- Booting well...

The authenticated area and the SW_GP2 (BEE user key) area are clearly different.
Also, as shown in the screenshot above, SW_GP2 is clearly in a writable state, and based on the current value, it seems that it was properly written.

So, why is the booting not working?

Is it possibly due to a region setting problem in the XIP encryption (BEE user keys) configuration?

Here, I set the Protected Region 0 Start and Length to 0x60001000, which seems suspicious.

Could it be because this region is different from what is seen in the IDE?

However, since this is an XIP image, I had to set the flash base address to 0x60000000.
Also, this axf image runs well on a clean board without any secure settings, so the image itself seems to be fine.

Could you let me know What is wrong ?

Re: Security boot type change.

marek-trmac — Tue, 08 Jul 2025 06:11:13 GMT

Hi,

on your screenshot I can see the application starts at 0x60002000. The area 0x60000000-0x60001FFF is reserved for header of the boot image and the header should not be encrypted (there is no application code).

Re: Security boot type change.

Seongyon_Jeong — Wed, 09 Jul 2025 07:03:54 GMT

Are you referring to the start address 0x60002000 in the Build Image tab?

In my case, when using XIP encryption (BEE user keys) with the whole region option, the default start address was 0x60001000,
so I initially used 0x60001000 with size 0x0001F000.

As you suggested, I also tested with 0x60002000 and size 0x0001E000, but unfortunately, it still didn’t boot.

So I’m wondering:
if I first selected 0x60001000 and clicked Write Image, would that information be burned into FUSE,
making the image at 0x60002000 no longer work?

But then again, when I clicked Write Image, it showed “successful,” so I assumed it was fine.

Is there possibly a setting I may have overlooked?

Do I need to prepare a new EVK board (one that hasn’t been burned) and repeat the same process from the beginning?

Re: Security boot type change.

Seongyon_Jeong — Thu, 10 Jul 2025 01:48:26 GMT

I thought region is not critical,

below is from https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#preparing-source-image-for-rt10xx-rt116x-rt117x-devices

and It said that "keep the default settings to encrypt the whole image"
XIP encryption(BEE userkeys)`s whole image - Default setting`s start is 0x60001000 .
moreover almost SDK example XIP project has 0x60002000 startpoint.

and I compare Fuse value change this after and before.
Same fuses value. So. I conclueded that, the info about region is not include at Fuses.

so. no need new board. right? , then why 2case all is not working ?

RT1020-EVK. I have success booting in the only Authenticated(HAB) mode.
Is there another limitation regarding to RT1020 ?

@marek-trmac

Re: Security boot type change.

antonintomanec — Thu, 10 Jul 2025 07:51:58 GMT

Hi,

The region range values are included in the Encrypted Key Info Block (EKIB) at offset 0x60000400, so there is no need for a new EVK because of this.

Please try enabling XIP encryption by setting the pin GPIO_EMC_18 — BOOT_CFG1[0].
On the RT1020 EVK, this corresponds to switch SW8_1, which controls the Encrypted XIP bit.

Please try to set it.

Regards,
Tonda

Re: Security boot type change.

Seongyon_Jeong — Fri, 11 Jul 2025 00:54:34 GMT

Until now, I used SW8 1:4 = 0010 (internal mode) or 0001(serial download mode),

So. I expected your guide is working. and I used SW4[1,2,3,4] = 1010 or 1001

and In the fuse map ( build image Tab, OTP configuration button )

like upper capture, I changed it BOOT_CFG0 0bit 0 -> 1 ,

But still not working.

Re: Security boot type change.

Seongyon_Jeong — Fri, 11 Jul 2025 02:05:16 GMT

I prepared a new board and tested everything again from scratch.
In addition to what @antonintomanec kindly pointed out, I had also modified the BOOT_CFG0[0] bit (which is labeled EncryptedXIP in the OTP Configuration view of the SEC Tool) by setting it to 1 (enabled).
Looking back, I now suspect that this may have been an excessive or incorrect action. On the board I had been using previously, I was unable to revert this bit to 0, possibly because the region is in the FUSE area.

So, on the new board, I followed the exact same procedure as before, but this time I only changed the DIP switch (SW8) corresponding to BOOT_CFG0[0], as shown in the schematic provided in @antonintomanec ’s guide
After doing that and attempting to boot, I was able to confirm that XIP Encryption (BEE userdata) mode works correctly.

In the end, it seems that the EncryptedXIP field I found under BOOT_CFG0 in the FUSE settings of SEC Tool, should not have been modified. and Must switching dip SW8 not (0001 , 0010)
but (1001, 1010)

That was the root cause of the issue I was facing.

Really Thank you, antonintomanec

https://docs.mcuxpresso.nxp.com/secure/latest/06_processor_specific_workflow.html#rt10xx-rt116x-rt117x-device-workflow
In upper document, definetly About RT1020-EVK...

This guide MUST to be fixed. FlexSPI NOR +Encrypted XIP SW8: 1010 , not 0010
or Have to add some Comment regarding to SW8 dip switch 1 option, (EncryptedXIP on/off)

Re: Security boot type change.

marek-trmac — Sat, 12 Jul 2025 13:01:30 GMT

EncryptedXIP fuse bit is applied only if BT_FUSE_SEL bit fuse bit is burned to 1. Otherwise the value is retrieved from the pins.

Re: Security boot type change.

marek-trmac — Sat, 12 Jul 2025 13:09:26 GMT

Hi,

About the default value of encrypted range, BEE was tested with 0x60001000 and everything worked. Sorry for confusion.

Nevertheless, I think it would be better to encrypt application code only.