Hi NXP,
1. I have referred to "MCUXpresso Secure Provisioning Tool User Guide v.9" ,on page 74 "6.2.3.9 Booting OTFAD encrypted image authenticated with user" . If I was rebuild a new .axf file and encrypted by "Build image" button,
Can I use NXP-MCUBootUtility to loader encrypted bin files to RT1010? Or I have to use "Write image" button in Write image view?
2. In OTFAD configuration, Can the area length and area start address be changed after blowing the fuse?
3. What should we normally set the starting address of the area starting address for RT1010(0x60000000 or 0x60001000)?
Hi @Omar_hong,
Anytime you are modifying flash or FlexSPI registers you do need to be careful. Typically any flash modifications should be done from RAM code. You do not want to be attempting to execute from the flash while also modifying the flash or FlexSPI configuration as this can create read-while-write conditions.
When you are using OTFAD that adds an extra level of buffering to FlexSPI operations. This changes timing in ways such that code which works fine with OTFAD disabled (like the flash_component_nor example) can encounter errors. Adding a check that the FlexSPI is idle using the FlexSPI_STS0[SEQIDLE] bit should resolve the issue. Because the point of this check is to make sure there isn't FlexSPI activity, the check should be done from RAM.
Regards,
Melissa
Hi Omar,
1) MCUXpresso Secure Provisioning tool is not designed as compatible with NXP-BootUtility. We recommend to use "write". The write generates and executes the script. So you can customize the script if it does not match your needs.
2) I think, the OTFAD start/end address are not stored in the fuses, but I'm not sure.
You can review the fuse configuration of the Build page, see [OTP configuration] button.
3) Start address filed on the build page is editable only if you are using .BIN file. We recommend to use AXF, S19 or HEX, so the start address can be detected directly from the source file. The image shall be built to 0x60002000 (so the interrupt vector table starts at 0x60002000). Not sure whether 0x60001000 can work too. We recommend to start with Unsigned image and test whether the application works, before you sign and encrypt.
Hi Marek,
Thank you for your reply as well.
In addition to the above questions, I also have the following questions.
1. In "MCUXpresso Secure Provisioning Tool User Guide v.9" Page 67 (6.2.2 Connecting the board), step 2 "Make sure you have J1 (J38 on RT1176, RT1166) set to 3-4 to power the board from USB OTG." Dose it mean I should short pin 3 to pin 4 like following picture? But even if I don't do this, it doesn't seem to affect the progress of OTFAD
2 . I applied OTFAD to the SDK example project (evkmimxrt1010_flash_component_nor), and I found that it seemed that the flash could not be operated normally.
The program will get stuck at line 107
status = Nor_Flash_Initialization(&norConfig, &norHandle);
But if OTFAD is not used, this SDK could run normally.
Did I left out some detail?
Hi Omar,
ad 1) this is just configuration of the power for the board. It should not affect OTFAD.
ad 2) Please ensure, the clock configuration is not affected in the OTFAD encrypted code. The clock should be stable for the code encrypted by the OTFAD on RT1010.
I do not know how the flash programming works from SDK driver with OTFAD, I do not have any experience here. Could you add more details what memory block is encrypted?
Hi @marek-trmac
Below are my flash clock settings and OTFAD clock settings, which I believe are consistent. Additionally, I have included information about the encrypted block. I have tried different flash sample project on the RT1010, and they all exhibit the same issue when OTFAD is applied.
Could you provide us with an solution for this situation?
Hi Omar,
I mean, it is not allowed to change core clock of the processor from the encrypted code. If you need to change clock frequency, you must do that before you enter into the encrypted code.
Hi NXP, @marek-trmac,
So, is NXP's FlexSPI with on-the-fly AES decryption (OTFAD) feature incompatible with the operation of NOR flash?
It is currently confirmed that directly using NXP's SDK(evkmimxrt1010_flash_component_nor) to apply OTFAD encryption is not workable.
Could you provide us with an solution for this situation?
(A simple NOR flash sample code that can use OTFAD encryption.)
Hi Omar,
sample application is provided in MCUX_Provi_v9.0.1\sample_data\targets\MIMXRT1010\source_images\evkmimxrt1010_iled_blinky_ext_FLASH.s19. This is application that blinks LED and does not affect the clock configuration (default clock configuration is used).
The step-by-step process for OTFAD encryption for RT10xx processors is described in User Guide chapter 6.2.3.8 or 6.2.3.9.
Hi @marek-trmac
Thank you for your reply as well.
sample application is provided in MCUX_Provi_v9.0.1\sample_data\targets\MIMXRT1010\source_images\evkmimxrt1010_iled_blinky_ext_FLASH.s19. This is application that blinks LED and does not affect the clock configuration (default clock configuration is used).
=>I used the OTFAD process to load this image onto the RT1010, and I can indeed see the LED blinking. But I can't confirm if this example uses the nor flash.
=>This application only has the .S19 file. Could you provide us with the complete development codebase?
Hi Omar,
the application was created from the SDK example (https://mcuxpresso.nxp.com) named "iled_blinky" for EVK-RT1010 board. The clock initialization was removed from the example.
Unfortunately, we do not have the modified source anymore. But you can look at the similar application for RT1060, see "sample_data\targets\MIMXRT1060\source_images\led_blinky.c".
The application does not modify the external flash, it is an application running from external flash. In MCUXpresso Secure Provisioning tool we do not have any example, how to modify external flash.
Hi @marek-trmac
What we want to know is NXP's OTFAD feature incompatible with the operation of NOR flash?
It is currently confirmed that directly using NXP's SDK(evkmimxrt1010_flash_component_nor) to apply OTFAD encryption is not workable.
But both "Hello_world" and "LED" SDK sample code to apply OTFAD encryption is workable.
I tried to trace the sample code(evkmimxrt1010_flash_component_nor) and found that modifying the FlexSPI registers[Module Control Register 0 (MCR0)] causes the program stuck.
Can you tell us why we cannot modify the FlexSPI registers[Module Control Register 0 (MCR0)] when OTFAD is enabled?