RT117x: what is ImageIndex

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

RT117x: what is ImageIndex

Jump to solution
1,818 Views
mastupristi
Senior Contributor I

On both the Safety Reference Manual and the Reference Manual, I saw this flow chart
flowchart.png

 

I highlighted the word ImageIndex and the fact that it looks like the ROM bootloader has the ability to attempt to boot multiple images.
I tried searching for 'ImageIndex' in both manuals: it only appears in those flowcharts. Changing search paramenters I found this:

B_API.png
Unfortunately, I cannot figure out the use case for this feature. I would like to know how to operationally exploit this feature. Where should the images be placed in the flash? How do you implement the "backup image" and "old image" scenarios?
In general, I need more documentation. Is there any Manual (maybe of the i.MX6 or i.MX8) or some AN that explains this in detail?

Best regards

Max

0 Kudos
Reply
1 Solution
1,776 Views
mastupristi
Senior Contributor I

could the two images have different keyblobs?

Once again I answer my own question: probably yes!

remap_keyblob.png

The point is that I don't know if keyblob remapping is only effective if the key blob is in the ECC, or is it on regardless but changes the offset at which to take it.

Referring to the statement, "When ADDRSTART setting is same as ASFM_BASE, and OTFAD keyblob function is enabled, keyblob is also remapped"

  • ASFM_BASE should be 0x30000000, right?
  • OTFAD keyblob function is enabled when ENCRYPTED_XIP is enabled, right?

regards

Max

View solution in original post

0 Kudos
Reply
8 Replies
1,739 Views
mastupristi
Senior Contributor I

OK! I was able to replicate the example explained in AN12255 on RT1170-EVK. I attach the project.

I configured XIP_BOOT_HEADER_ENABLE=1 to also include boot headers in the binary. I build twice by changing FIRMWARE_INDEX 0 or 1. Then on my EVK I burned 0x08 into xSPI_FLASH_SEC_IMG_OFFSET:
xSPI_FLASH_SEC_IMG_OFFSET.png

so that the images have an offset of 2MB between them

Using JLINK, I wrote image 0 at the beginning of the flash and image 1 at offset 0x20000. And the result is this:

dualImage.png

Then I tried the encrypted versions. The procedure is not as straightforward as for the plain-text version. I had to configure XIP_BOOT_HEADER_ENABLE=0, so that no boot header would be included in the binary. Then:

  • using Provisioning tool I wrote image 1, and verified its operation (of course I turned on the ENCRYPTED_XIP_EN switch and in the USER_KEY5 I have the KEK written). I did this because I don't know how to force provisioning tool to write the image to an arbitrary address.
  • using JLINK I reread the FW from the flash (paying attention to the length)
  • using Provisioning tool I wrote image 0, and verified
  • Using JLINK, I wrote at offset 0x200000 the reread image.

Image 0 is executed but image 1 does not start.

What could I have done wrong?

more questions:

Is it possible to input an executable with boot headers to Provisioning Tool? How?

Is it possible to generate the encrypted bootable image (thus containing FCB, IVT, keyblob, etc.) offline (without having an EVK connected)?

Is it possible with Provisioning Tool to force the binary write address?

at resets or power cycles it always starts image 0. Is there any way to persist the index of the image to start?

 

best regards

Max

0 Kudos
Reply
1,669 Views
mastupristi
Senior Contributor I

I went ahead as a self-taught person on this. See https://community.nxp.com/t5/i-MX-RT/RT117x-dual-image-boot-order/m-p/1769007#M27874

This raises another question for me: I tried writing the image to addresses 0x30000000, 0x30200000, 0x30400000 and 0x30600000. However, only the first two images manage to be executed correctly.

Why?

 

regards

Max

 

0 Kudos
Reply
1,665 Views
mastupristi
Senior Contributor I

I got the point (I had missed it on a first reading)

expla.png

0 Kudos
Reply
1,804 Views
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @mastupristi,

This feature is used when remapping the flash, to have more than one firmware or even doing a OTA firmware upgrade. Please look into the "How to Use Flash Remapping Function" (AN12255) for more information about how to enable this feature. Also, for OTA specific information look into "FOTA Design for SBL and SFW" (AN13460).

I hope this helps!

BR,
Edwin.

1,789 Views
mastupristi
Senior Contributor I

Please look into the "How to Use Flash Remapping Function" (AN12255)

This document describe Remapping feature for RT1060:
Remapping.png

does this apply also to RT117x?

It also assumes the use of MFGTOOL via USB, but on my custom board I don't have USB, and the serial I may have is not the "right" one.

What can be an altertnative way?

 

regards

Max

0 Kudos
Reply
1,786 Views
mastupristi
Senior Contributor I

does this apply also to RT117x?

I am reading AN12255 thoroughly, searching and finding the same things on the Reference Manual of RT117x. That means I can answer my own question in the affirmative.

Given this info, I have a question: could the two images have different keyblobs? I know that the KEK, written in the fuses, is one for all, but could the keyblob (containing KEY and CTR) be different for each image?

regards

Max

0 Kudos
Reply
1,754 Views
EdwinHz
NXP TechSupport
NXP TechSupport

Hi @mastupristi,

1. Yes, it also applies to RT1170.

2. Yes, different images can contain different keyblobs.

1,777 Views
mastupristi
Senior Contributor I

could the two images have different keyblobs?

Once again I answer my own question: probably yes!

remap_keyblob.png

The point is that I don't know if keyblob remapping is only effective if the key blob is in the ECC, or is it on regardless but changes the offset at which to take it.

Referring to the statement, "When ADDRSTART setting is same as ASFM_BASE, and OTFAD keyblob function is enabled, keyblob is also remapped"

  • ASFM_BASE should be 0x30000000, right?
  • OTFAD keyblob function is enabled when ENCRYPTED_XIP is enabled, right?

regards

Max

0 Kudos
Reply