SEC Tool v7 Assigns application to Non-XIP mode when start address is secure flash

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SEC Tool v7 Assigns application to Non-XIP mode when start address is secure flash

Jump to solution
2,591 Views
george_iyo
Contributor II

XIP_no_secure_flash.png

 We've noticed that for applications on the RT685S that are in secure flash XIP mode, assigning the start address to beginning of the image header in secure flash (0x18001000) causes the image to not boot properly when enabled a signed booting + force Trustzone enabled in OTP. This does not occur when in the plain image and plain image + CRC mode and with Trustzone enabled. It would seem the SEC tool interprets the start address of (0x18001000) to be a non-XIP load-to-RAM image - is this a bug or intended behavior? We have noticed that reassigning our start address location to non-secure flash (0x08001000) enables the image to boot properly when signed and with Trustzone enabled in the OTP configuration.

0 Kudos
Reply
1 Solution
2,534 Views
marek-trmac
NXP Employee
NXP Employee

Hi George,

as a workaround solution, you can modify template for the mbi_config.yaml, so the tool always generates "XIP" image:

  • locate file "c:\nxp\MCUX_Provi_v7\bin\data\script_templates\RTxxx\mbi_config.yaml" in your installation directory
  • search for line "outputImageExecutionTarget: {{ mbi_config.outputImageExecutionTarget }}"
  • comment the line and/or replace by a new value "outputImageExecutionTargetExternal flash (XIP)"
  • save the file
  • build again

Please mind, after this change, load to RAM image for RTxxx will not work, as the tool will always generate XIP image.

Hope this helps.

Regards,
Marek


NOTE: If you find the answer useful, kindly click on [ACCEPT AS SOLUTION] button

View solution in original post

0 Kudos
Reply
5 Replies
2,562 Views
george_iyo
Contributor II

Following your instructions, when I change mbi_config.yaml's line 11 parameter to External flash (XIP), the app can't boot when launching from secure flash:

george_iyo_0-1698943352554.png

I've also noticed that hitting the "Build Image" button in the Build image tab also changes the mbi_config.yaml parameter back to RAM.

 

0 Kudos
Reply
2,572 Views
marek-trmac
NXP Employee
NXP Employee

Hi George,

I believe this is a bug, not intentional. I can see that generated mbi_config.yaml contains "outputImageExecutionTarget: RAM" instead "outputImageExecutionTarget: External flash (XIP)"

Could you please confirm, if you manually fix mbi_config.yaml and then if you invoke build script from the disk, the issue is resolved on your side?

Thank you for the report, we will fix this into next version (V8).

Regards,
Marek


NOTE: If you find the answer useful, kindly click on [ACCEPT AS SOLUTION] button
0 Kudos
Reply
2,542 Views
george_iyo
Contributor II

Sorry, I misread your post. After selecting build image, and then changing the mbi_config.yaml parameter to:

outputImageExecutionTarget: External flash (XIP)
 
And then executing build_image_lnx.sh seems to resolve the issue - sending the Write Image command in the SEC tool, and then hitting the reset button with doing a POR with shadow registers enabled seems to enable the image to boot. I'm wondering now if this at all impacts the creation of a manufacturing package within the tool - does the package reupdate the the yaml file, or does it just take in the files from the workspace?
 
2,535 Views
marek-trmac
NXP Employee
NXP Employee

Hi George,

as a workaround solution, you can modify template for the mbi_config.yaml, so the tool always generates "XIP" image:

  • locate file "c:\nxp\MCUX_Provi_v7\bin\data\script_templates\RTxxx\mbi_config.yaml" in your installation directory
  • search for line "outputImageExecutionTarget: {{ mbi_config.outputImageExecutionTarget }}"
  • comment the line and/or replace by a new value "outputImageExecutionTargetExternal flash (XIP)"
  • save the file
  • build again

Please mind, after this change, load to RAM image for RTxxx will not work, as the tool will always generate XIP image.

Hope this helps.

Regards,
Marek


NOTE: If you find the answer useful, kindly click on [ACCEPT AS SOLUTION] button
0 Kudos
Reply
2,536 Views
marek-trmac
NXP Employee
NXP Employee
Hi George,
the creation of manufacturing package should just take files in the workspace. Moreover, manufacturing package contains just files needed for write, as it is not expected the image will be re-built in the manufacturing.
Regards,
Marek


NOTE: If you find the answer useful, kindly click on [ACCEPT AS SOLUTION] button
0 Kudos
Reply