Enable OTFAD function , then jump to application code will failure

[Felix_ar]

Hi All

The customer build bootloader by himself, but encounter some issue.

Disable OTFAD function, application code address start from 0x60020000.

bootloader can jump to application.

Enable OTFAD function, encryption application code address start from 0x60020000.

bootloader can't jump to application.

Enable OTFAD function, encryption application code address start from 0x60021000.

bootloader can jump to application.

Could you tell us how to do can fix this issue? or the first 4K bytes of the application code can't be  encrypted.

attached file is the customer sample code.

Bootloader (evkmimxrt1010_dev_hid_generic_bm): 0x60000000

Application(evkmimxrt1010_flexspi_nor_polling_transfer): 0x60020000

Thanks.

[diego_charles]

Hi @Felix_ar 

Thank you for reaching out! 

I understand that the customer can use OTFAD to decrypt automatically code, but to achive this they had  to increase by 1K  the offset of their application ( from 0x6002_0000 to 0x6002_1000) and they want to know why.

I quickly checked the customer bootloader source code,  but it is not clear for me how are they enabling/setting  the OTFAD prior to jump to the application, could you describe this? 

Did they configured OTFAD only for the application or for the bootloader or both? How ?

Another question is :  can we reproduce this with our MIMX RT1010 -EVK?

Thank you! 

Diego

[Felix_ar]

Hi @diego_charles 

Thank you reply.

1.  The customer use MCUXpresso Secure Provisioning Tool v9 to enable OTFAD function.

2. Only encryption application code.

3. MIMX RT1010 -EVK can reproduce  this issue.

below is Secure Provisioning Tool v9 setting screenshot.

Fail

Pass

Thank you.

[diego_charles]

Hi @Felix_ar 

Thank you for letting me know, I am working to see if I can replicate this on my end. 

Diego

[Felix_ar]

Hi @diego_charles 

Any update for this case?

Thanks.

[diego_charles]

Hi @Felix_ar 

Thank you very much for your patience, I appreciate.

I was able to get application working in plain mode. 

But I am still diagnosing why you can not setup OFTAD at 0x6002_0000 and boot. 

Just a question, how are you creating and loading the secondary application?

With the SPT is easy to program the bootlaoder and the flexSPI application as an additional image. but I do not know the process you are following. 

Diego

[Omar_hong]

Hi @diego_charles 

Thanks for your reply！

I am a customer of @Felix_ar .

I was able to get application working in plain mode. 

=>In this case, we can also operate normally.

But I am still diagnosing why you can not setup OFTAD at 0x6002_0000 and boot. 

=>All our data is attached for your reference so that you can reproduce our situation.

NXPRT1010_TEST

    Source code  ----------------bootloader & APP code 

    Full_Plaintext.bin---------- bootloader + APP

    TEST_KEY --------------------HAB+OTFAD KEY

    20000

boot_image-------------------generate by SPT

    debug_log.jpg

    OTFAD_config.jpg

    Full_cipher_text_60020000.bin

21000

    boot_image-------------------generate by SPT

   debug_log.jpg

   OTFAD_config.jpg

Full_cipher_text_6002100.bin

Just a question, how are you creating and loading the secondary application?

=>

1.I first used a new RT1010 EVB (not burn any efuse )to create the following bin file.

2.use the NXP IDE to flash the bootloader into the RT1010, and then use the NXP-MCUBootUtility to flash the app bin file into the RT1010.

3.use NXP-MCUBootUtility to download Full_Plaintext.bin(bootloader + app)

With the SPT is easy to program the bootlaoder and the flexSPI application as an additional image. but I do not know the process you are following. 

=>

I tried this feature, but the app section didn't succeed in encrypting, and the test results were also unsuccessful.

[Omar_hong]

Hi @diego_charles 

         Can you reproduce our situation?

 Any update for this case?

Thanks.

[diego_charles]

Hi @Omar_hong 

I just want to maintain you updated. 

I have been testing further by elaborating more tests on own  ( for example by encrypting both both bootloader and app together and still I am getting failures to boot to the application. Everything works well with boot to plain mode

I do apologize for the inconvenience, as the investigation still goes on.

Diego

[Omar_hong]

Hi @diego_charles  

  Thank you for your reply. If there are any details or questions you want to know, please let me know as soon as possible.

[diego_charles]

Hi @Omar_hong and @Felix_ar 

I want to maintain you updated. 

I think I managed to replicate your issue on my end, I thank you for your files and code, they help me as reference. But this still work in progress ( see last paragpraph ). Please take a look at my testing. 

I created my own bootloader image  at 6000_2000  and led_blinky image at 0x6002_0000, then I merged together to create a single binary. Easiest way I found to create a single binary with both bootloader and application was write both applications and export the memory contents of the flash using Segger's J-MEM.  I created a single binary to use the SPT to encrypt the image with ease. 

Below my test results.

1 If I set OTFAD Region 0 to 0x6002_1000 ( 4 KB offset from  entry of led_blinlky application), which is after the application entry, I can successfully boot the application.

Below application memory details.

Below evidence. 

2 If I set OTFAD region 1 to 0x6002_0000, encrypting the vector table, main function and a bit of the first part of the application, I can NOT boot the application. .

You can see the resets I made, jump can not be achieved. 

3 If I set OTFAD region 0 to 0x6000_2000, or 0x6000_1000 , encrypting the vector table, main function and and a bit of the first part of the  bootloader. I can  boot the bootloader and the application

So far, boot of the application at 0x6002_0000 works if OTFAD is set to 0x6002_1000. You are not loosing any space, but the first 4 KB of the application are in plain.  So what is next? I where able to replicate the problem on the bench, so I am discussing this internally, to provide you a clarification. 

I appreciate your patience and disposition.

Diego

[Omar_hong]

Hi @diego_charles 

    Thank you for your response. I look forward to your further results.

[diego_charles]

Hi @Omar_hong  and @Felix_ar 

Just to maintain you updated,  I just need more additional time, as I am waiting for feedback, internally. 

Diego

[diego_charles]

Hi @Felix_ar  and @Omar_hong 

I have more updates on this after, thanks to  my internal discussion.

After some debugging by following the test environment I created (based on yours)  the problem is mostly caused by same clock reconfiguration twice in both simple bootloader and app image. If we compile app image with clock_config.o and fsl_clock.o in RAM, then we could encrypt the whole app image starting from 0x6002_0000.

We are trying to analyze the root cause with designer for clock tree.

Diego

[Omar_hong]

Hi @diego_charles 

   Thank you for your prompt response. I look forward to your root cause analysis of this issue.

[diego_charles · Accepted solution]

Hi @Omar_hong 

Thank you for your reply, we have a suggestion, please try on your side and let me know your results.

Change clock init as below:

  CLOCK_InitSysPfd(kCLOCK_Pfd3, 19);
  CLOCK_SetMux(kCLOCK_PrePeriphMux, 2);

We found that ENET PLL have an impact for OTFAD decryption when both bootloader and application did ENET PLL initiation.

This is a special case for your test environment and the one I created.

Looking forward to hear from you.

Diego

[Omar_hong]

Hi @diego_charles ,

         This initially seems to have resolved the issue. I will try it out more in other board. Thank

you very much for your assistance.

If there are no further problems, I will close this issue.

Thank you once again for your great assistance !

[diego_charles]

Hi @Omar_hong 

We are very glad to know that  the problem is solved, we appreaciate your interested ( and patience during  our testing and  troubleshooting )

Diego