Hi @Littell
I am sorry for the delayed reply.
The chapter 3 XIP boot flow of the AN12183 How to Enable Debugging for FLEXSPI NOR Flash does provide a simple overview of bootflow. Also this video complements very well NXP: MCU Tech Minutes: Boot Options for i.MX RT Crossover MCUs for me.
Let me provide some of my comments with regards to this:
The Reference Manual Figure 10-3 shows decision points and processes like "IVT header
valid?", "Image == XIP?", and "Authenticate Image" - what are the specifics of these checks?
About IVT header valid
If you have boot mode pins set to internal boot and boot config pins for XIP. After boot the bootROM will check for the IVT at 0x1000 base address of the booting device. If you are using a blinky demo on the i.MX RT1176, bootROM will go a look for the IVT at 0x3000_1000.
Now lets suppose that bootROM finds the IVT, it will proceed to check that the IVT is on the expected format:
It is important that the Tag parameter is met, along the lenght and version.
About Image == XIP?
The IVT contains several elements and one of them is the image's entry point. The image entry point is read by bootROM to know in which address will the application execute. If the image entry is set after the IVT space and in the FlexSPI mapped area, the bootROM will know that the image is an XIP image. In other words, if the entry point is above the 0x3000_2000 (for typical blinkly ) and in the FlexSPI address range, you know that the app will be executed from the external flash memory. If the image entry point is set to other address than like 0x8000_0000 (SECM SDRAM for example ), 0x2020_0000 ( internal SRAM ) it means that the image is not an XIP image and will know that it will have to copy flash contents to target RAM , there is image lenght parameter on the IVT.
About authenticate image
This is very generic, but it refers to the process of bootROM verifying image signature for secure boot. During development you should not worry about this step. If the image is not not trusted/valid the bootROM will not execute it.
I hope this still helps. Let me know any other question you may have, David.
Regards,
Diego
Hi @Littell
I am sorry for the delayed reply.
The chapter 3 XIP boot flow of the AN12183 How to Enable Debugging for FLEXSPI NOR Flash does provide a simple overview of bootflow. Also this video complements very well NXP: MCU Tech Minutes: Boot Options for i.MX RT Crossover MCUs for me.
Let me provide some of my comments with regards to this:
The Reference Manual Figure 10-3 shows decision points and processes like "IVT header
valid?", "Image == XIP?", and "Authenticate Image" - what are the specifics of these checks?
About IVT header valid
If you have boot mode pins set to internal boot and boot config pins for XIP. After boot the bootROM will check for the IVT at 0x1000 base address of the booting device. If you are using a blinky demo on the i.MX RT1176, bootROM will go a look for the IVT at 0x3000_1000.
Now lets suppose that bootROM finds the IVT, it will proceed to check that the IVT is on the expected format:
It is important that the Tag parameter is met, along the lenght and version.
About Image == XIP?
The IVT contains several elements and one of them is the image's entry point. The image entry point is read by bootROM to know in which address will the application execute. If the image entry is set after the IVT space and in the FlexSPI mapped area, the bootROM will know that the image is an XIP image. In other words, if the entry point is above the 0x3000_2000 (for typical blinkly ) and in the FlexSPI address range, you know that the app will be executed from the external flash memory. If the image entry point is set to other address than like 0x8000_0000 (SECM SDRAM for example ), 0x2020_0000 ( internal SRAM ) it means that the image is not an XIP image and will know that it will have to copy flash contents to target RAM , there is image lenght parameter on the IVT.
About authenticate image
This is very generic, but it refers to the process of bootROM verifying image signature for secure boot. During development you should not worry about this step. If the image is not not trusted/valid the bootROM will not execute it.
I hope this still helps. Let me know any other question you may have, David.
Regards,
Diego
