RT117x: Image Index (or Version) explaination

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

RT117x: Image Index (or Version) explaination

1,082 Views
mastupristi
Senior Contributor I

Hi,
I'm dealing with the Image Index, which on Secure Provisioning Tool is called Image Version.

A popup appears on Secure Provisioning Tool that says:


A version of the bootable image. It is defined in 4 bytes, the lower 2 bytes are the real image version number, and the upper 2 bytes are the inverted value of the lower 2 bytes image version, for example, 0xFFFE0001 for version 1. Either the complete 4 bytes value or the real image version number is expected.
Value 0xFFFFFFFF is also a valid image version, but with the lowest boot sequence. The image with the higher image version is booted first when the dual image boot is configured.

mastupristi_0-1717576442851.png

 

I need you to explain the phrase: “Either the complete 4 bytes value or the real image version number is expected”. Does it mean that even just the lower part of the 32-bit word is enough, and it is not checked that it corresponds with the inverted upper part?

Also I tested two images, at offset 0 Image Version 0xFFFE0001, while the other image has Image Version 0xFFFD0002. The image started by the ROM bootloader is the second one (as expected). Then I replace the first image with one having Image Version 0xFFFFFFFF. I would expect the second to continue to be booted because it is written "Value 0xFFFFFFFF is also a valid image version, but with the lowest boot sequence. The image with the higher image version is booted first". But the ROM bootloader starts the first. Is there something I am missing?

best regards

Max

0 Kudos
Reply
9 Replies

1,019 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @mastupristi 

Thank you for reaching out and for your patience. I am  checking internally the discrepancy that you are reporting. 

I think your test scenario where you had below dual image setup

Image Offset Image version
L 0x0 0xFFFFFFFF
H 0x00200000 0xFFFE0002

 

and your result was that image L was booted , instead image  H with the higher version, can be explained with the below note 

diego_charles_0-1719007933220.png

This means that ROM bootloader used redundant boot, and not dual image boot.

Lets check together the SPT comments regarding the inverted upper bits . Which image is booted if you set as below?

Image Offset Image version
L 0x0 0xFFFE0002
H 0x00200000 0x00000003

 

Is image H be booted first on your side?

Thanks for bringing this report.

Diego

 

 

0 Kudos
Reply

928 Views
mastupristi
Senior Contributor I

Hi @diego_charles 

here results of my test. The table shows the image version fields and which image boot:

 

LHboot
0xFFFFFFFF0xFFFE0001L
0xFFFF00000xFFFFFFFFL
0xFFFF000000000001L
0x000000020xFFFE0001H

 

image L is at offset 0x00000000, image H is at offset 0x00400000

What conclusions can you draw (considering the text in the popup of SPT)?

 

can be explained with the below note 

mastupristi_0-1719933212561.png

This means that ROM bootloader used redundant boot, and not dual image boot.

Please tell me in which document you found this note
Also tell me what you mean by "redundant boot", and where can i find documentation about it

 

regards

Max

0 Kudos
Reply

772 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @mastupristi 

Thank you very much for your patience. 

I ran tests  on my side and your test results match mine, and they are correct.

In the below table you can see that I made six tests. Test 1 to 4 are the same than yours and I have the same results. Tests 5 to 6 are almost like tests 3 and 4, but with valid version numbers.

 

Test  Image L  Image H booted image Reason
1 0xFFFF_FFFF 0xFFFE_0001 L  L is booted first, considering this as redundant boot, not dual image boot. Working on a more clear description
2 0xFFFF_0000 0xFFFF_FFFF L Working on a more clear description
3 0xFFFF_0000 0x0000_0001 L H contains an invalid header
4 0x0000_0002 0xFFFE_0001 H L contains an invalid header
5 0xFFFF_0000 0xFFFF_0001 H H version number is higher
6 0xFFF_0002 0xFFFF_0002 L L version number is higher

*Where image L is at  0x30000000, image H is at  0x30400000

I took the note from our colleague Jay heng, article   https://www.cnblogs.com/henjay724/p/15942801.html but as I have been talking with him, my previous translation of his chinese article was not good, and I apologize for that. A more accurate translation would be more like this

diego_charles_0-1722407608998.png

 

However, let me get back to you with a clear and logic description of the above results, as well redundant and dual image boot. Currently we do not have more supporting information, I do apologize for the inconvenience. However,   I am requesting a ticket to the internal documentation team to update  RM information.

Thank you very much for your efforts reporting this, as your patience. Please expect a follow up from my side.

Diego 

 

0 Kudos
Reply

763 Views
mastupristi
Senior Contributor I

Hi @diego_charles 

L is booted first, considering this as redundant boot, not dual image boot.

when you talk about “redundant boot” are you referring to what is described here? If not, can you describe it to me? What are the differences between “redundant boot” and dual image?

I believe that such important topics should be explained in detail in the reference manual, and/or in some application note. In my opinion it's not possible for such information to be only within articles written in Chinese, which is hard to find just by googling.

 

I remain waiting for your "more clear description"

 

best regards

Max

 

0 Kudos
Reply

711 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @mastupristi 

For now, I took  the reference regarding redundant boot  from here as you mention. 

I am currently addressing this internally, and I wil  get back to you.

Thank you for your patience and feedback. 

Diego

 

0 Kudos
Reply

370 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @mastupristi 

Let me provide you an update, I was testing further and discussing internally with other colleagues and SPT development team. The Reference manual does not cover this topic and we are working to add the information. I will return back to you.

Thank you very much.

Diego

0 Kudos
Reply

217 Views
Littell
Contributor II
Any update on this? The entire topic of dual-image/redundant boot/whatever-it's-called-this-week and ==> how to actually do it in a real application <== is so poorly explained it's almost comedy.
0 Kudos
Reply

183 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @Littell 

Thank you for your interest! I apologize for the inconvenience. 

As discussed on this comment   we still need further time to create  official documentation, as we need to aling with bootROM and other development teams internally.

I have a some steps to enable and test this feature on RT1170 with Secure Provisioning Tool , do you need assistance with this? Feel free to let me know if you need more help to evaluate this (due to the lack of documentation at this time). Also feel free to create another ticket and tag me.

All the best, 

Diego

0 Kudos
Reply

983 Views
mastupristi
Senior Contributor I

Hi@diego_charles 

I am currently out of the office until at least July 1, so I can't test what you are asking for until then.

and your result was that image L was booted , instead image  H with the higher version, can be explained with the below note 

mastupristi_0-1719303783860.png

This means that ROM bootloader used redundant boot, and not dual image boot.

I have two questions about this:

  1. In which document do I find this note?
  2. What is redundant boot and where can I find it documented?

best regards

Max

0 Kudos
Reply