RT1170 dual image support wi/ROM API's explained for real

Littell

Oh, and just for fun don't forget the execution environment is SPI NOR Flash XIP.

Has anyone actually made this scenario actually work?

diego_charles

First of all, this topic is still on validation, so please do not consider this yet as an official document. As you already saw, we still do not have official documentation in English, but we are working on this. I thank you for your interest and apologize for any inconvenience. Please take a look at the below and let me know your feedback, if you get any issues or find any inconsistency.

I tested this with the i.MX RT1170 EVKB and MCUXpresso Secure Provisioning Tool v9.

The bootROM plays an important role on this. Before getting started please check your bootROM version. Below an snapshot of how to do it.

My RT1170 contained a bootROM with version T2.0.0. Please help me to check yours by setting the MCU in serial downloader mode and calling the below command.

blhost u VID,PID --  get-property 24 command.

If you have an older or different bootloader version please let me know.

Preparation :

1 Download and install latest version of the MCUXpresso Secure Provisioning Tool.

2 Make a mass erase to EVK flash.This is to avoid any previous version numbers. A mass erase can be done with the MCUXpresso IDE with ease.

Project creation Steps:

Import Hello word demo, and add image L prefix. The project name will be Hello_word_ImageL.
On the demo source code make Print to say “Hello word from image L”
Import Hello word demo, and add image H prefix. The project name will be Hello_word_ImageH.
On the demo source code make Print to say “Hello word from image H”.
For each project remove XIP_BOOT_HEADER_ENABLE=0.
Compile each project.

Secure Provisioning Tool Steps:

Create a new SPT workspace for the RT1170.
Click on dual image boot button, select Target Image 0 and Image 1 and place image offset of 0x0040_0000

The OTP config will turn red, as the tool detects that we need to burn 0xC80 fuse, to contain the given offset.

Set RT1170 to serial downloader mode and test connection, for example over USB.
Open the OTP config and read current processor fuses.

Find fuse 0xC80, the tool will show required value and current value. Click on Fix option, if needed, and click OK.

Then, you will see that the OTP config will turn green.

Provide image L as the source image and set a image version of 0x5. This an example version number. .

Note: With this setup the SPT will write the image version of 5 and the same image to both address space of imageL and imageH of 0x3000_2000 and 0x3040_0000 respectively

Build and write the image.

This way image L will be written to memory but twice, because image L will be written on the offset and space of image H. This is considered as redundant boot.

Set MCU to internal boot and check in the console that image L boots, use serial terminal.

Provide now Image H as the source image and set an image version of 0x6.

Click on dual image boot and select image 1.

This way the SPT will only write to the offset and space of imageH (or image 1)

A warning will pop-up, solve the warning by creating required custom FCB for image H. Click on the FlexSPI NOR - Simplified button and creat the FCB.

Note: we discovered a bug in the SPT: When creating FCB block by "convert to FCB" button, region around the FCB is erased. Size of erased region is dependent on the minimal erasable block of memory. This can erase user data or image version that is placed immediately after FCB block for RT10xx/RT11xx devices. The solution for this bug is prepared for SPT v10. If you see any strange behavior review write again the image L and image H.

Build and write image H.

Check if image H boots.

Keep doing tests, programing H and L with different valid version numbers. The image will the higher valid version should be booted.

The below image shows the ability to boot different applications.

According to my tests, I could define the following:

The below table shows boot image criteria when two images are programmed into the flash.

L image version	H image version	Boot image criteria	Boot type
valid	valid	BootROM will boot the image with the higher valid version number.	Dual image boot
0xFFFF_FFFFF	valid	BootROM will boot image L first.	Redundant boot
valid	0xFFFF_FFFF	BootROM will boot image L first.	Redundant boot
Invalid	valid	BootROM will boot the image with the valid image version only.	Redundant boot
valid	invalid	BootROM will boot the image with the valid image version only.	Redundant boot

Where:

L : When there are two images in the flash memory, L image is the image located at the lowest physical address on the memory. Consider an image located at 0x3000_0000 and another one at 0x3040_000 , L is the image located at 0x3000_0000.

H: When there are two images in the flash memory , H image is the image located on the highest physical address on the memory. Consider an image located at 0x3000_0000 and another one at 0x3040_000 , H is the image located at 0x3040_0000.

image version: Is a four-byte tag. The first two less signficative bytes represent the real image version( ranging from 0x0000 to FFFF) and the next two more signficant bytes represent the inverse value of the two real image version bytes.

valid or valid image version : Is an image version where the real version number bytes and the inverse value bytes match . For example, 0xFFFE_0001, where 0001 is the real version number and 0xFFFE the inverse value of 0x0001.

Invalid or invalid image version : Is an image version where the real version number bytes and the inverse value bytes do not match For example : 0x0000_0001.

0xFFFF_FFFF: This a special case where all four bytes contain F’s, and it is also considered a valid version number. Is is an special version value useful to test redundant boot.

Redundant boot: The bootROM will always attempt to boot first image L if the below conditions are met:

There are two images (image L and image H ) in the flash memory.
Fuse 0xC80[23:16] value is different than zero.
Image L contains a valid version number or equivalent to 0xFFFF_FFFF.

If above conditions are not met, or if image L boot fails, the bootROM will attempt to boot image H.

Dual boot : the bootROM will always select to boot first the image with the highest version number if the below conditions are met.

There are two images (image L and image H ) in the flash memory.
Fuse 0xC80[23:16] value is different than zero.
Image L contains a valid version number different than 0xFFFF_FFFF.
Image H contains a valid version number different than 0xFFFF_FFFF.

If above conditions are not met, or selected image boot fails, the bootROM will attempt to boot from the other image, performing redundant boot.

I hope this could help,

Diego

Littell

I will certainly go through this with a fine-toothed comb. At first reading it does appear to match my understanding of Image Version behavior.

Notes from a first reading:

In "Project Creation Steps", "L" and "H" are suffixes, not prefixes.
The case when the two Image Versions are identical doesn't seem to be addressed in the "boot image criteria" table.
The concepts of "redundant" and "dual-image" need significant clarification.

The bootROM version on my EVKB is K3.0.1. I extracted it using the information in the RT1170 Reference Manual Section 10.13.1.

This is good information and it's a shame I had to push so hard for it to become available. But it's only one part of the overall issue we face: the execution environment of the application is XIP from the SPI NOR Flash. A critical feature of our project is dependent on being able to download and program Flash with a new image then reboot into that image. How is this to be mechanized in this execution environment?

diego_charles

Hi @Littell

Thank you for your quick feedback and interest! I do appreciate your patience and help as well. I will wait for any further comments from you.

Btw, could you explain further the mechanization on execution environment?

Diego

Littell

What are the steps needed to program the SPI NOR Flash with a new image then reboot into that image when utilizing XIP on the SPI NOR Flash?

diego_charles

Hi @Littell

Thank you for your reply!

I understand that you are making a reference to update an image with a newer version, like an OTA. If not let me know otherwise.

In this scenario we are manually booting the MCU into serial downloader mode and programming the image over SPT ( which implements BLHOST at a low level). I think that if you need some sort of automation. There is a raw and simple scenario where you would need to re-invoke the bootloader from SW, and this is possible, using the runBootloader() API, and then send the new image over BLHOST, with a different SW version, to benefit from the dual image feature.

For a more sophisticated way, I suggest looking at our SBL reference project and documentation. The SBL user guide details dual image use cases, but here we are not making any use of the ROM bootloader.

Diego

Littell

No, the image update cannot involve any external entities other than the one that provides a downloaded image.

Think of it this way, on a dual-image-configured XPI SPI NOR Flash: <app image in a file on a mounted filesystem> ==> <the area in XIP NOR Flash that is not being actively executed> ==> <reboot into the newly written image in Flash>

I'm not sure how to make it more clear or simpler.

diego_charles

Hi @Littell

Thank you for your reply!

I am afraid that I do not have such implementation steps, but for what I understand, your idea is interesting.

I have not tested reboot to execute the updated image with the higher version number. I think this is the most critical step. Because you can implement a custom way of receving and writting the image, this seems to be independent to dual boot feature from the bootROM. Also writting while executing the image is dependant on the features of your flash memory, for reference check this app note AN12564 Implement RWW on i.MX RT Series

Diego