RT117x: reserved fields populated by Secure Provisioning Tool

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

RT117x: reserved fields populated by Secure Provisioning Tool

735 Views
mastupristi
Senior Contributor I

Hello,

in the Security Reference Manual I find:

imageLayout.png

With Secure Provisioning Tool I wrote a correctly executable image, where I set image version 0x0013FFEC.
Rereading the contents of the flash I find that the area declared reserved is actually populated, and among other things I see that the version image is at offset 0x600:

actualContent.png

Moreover, the word at address 0x500 seems a plausible header (although 0xd8 should indicate a signature).

I would have expected to find this area unpopulated (like that between 0x100 and 0x3FF).

Where can I find the documentation for these areas?

regards

Max

0 Kudos
6 Replies

704 Views
mastupristi
Senior Contributor I

I believe there is a bug in the documentation, because FCB is 512 bytes big (see Reference Manual, section 10.6.3.2 Serial NOR configuration block (512 bytes)), so it stands at addresses between 0x400 and 0x5ff

This means that the reserved area cannot start at 0x500, but at least from 0x600. However at 0x600 there are the 4 bytes of the "image version", which I think should be just as documented (can you point me to where I can find it documented?).

 

regards

Max

0 Kudos

698 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

Yes, FCB is extended beyond 0x400 - 0x4FF range as suggested on the RM. 
If the field appears as reserved it means that the contents should not be visible to the user, it doesn't mean that the area remains blank. 

Omar_Anguiano_0-1701985023832.png

 

Best regards,
Omar

0 Kudos

673 Views
mastupristi
Senior Contributor I

If the field appears as reserved it means that the contents should not be visible to the user

This statement of yours is wrong!
The file evkmimxrt1170_flexspi_nor_config.c in the SDK contains a data structure that is used to populate FCB. All fields (512 bytes) are visible to the user! And the user can change them!
In addition, all the fields in that structure (512 bytes) are documented on the Reference Manual.
That is why your statement is wrong, and why I think the table 2-11 as it is is a bug and needs to be corrected.
Also at offset 0x600 there is "image version" so at least those other 4 bytes should be documented and not considered reserved.

regards

Max

0 Kudos

578 Views
Omar_Anguiano
NXP TechSupport
NXP TechSupport

I agree with you and apologize for the misunderstanding. 

What I meant to say is that the reserved space on the table you attached should be reduced since the FCB does not reflect its actual size and it should be documented.

Best regards,
Omar

 

0 Kudos

572 Views
mastupristi
Senior Contributor I

OK, so you agree with me about the table that it should be changed to something like the following:

OffsetDescription
0x000 - 0xFFKeyBlob
0x100 - 0x3FFReserved
0x400 - 0x5FFFlash Configuration Block
0x600 - 0x603Image Version
0x604 - 0x7FFReserved
0x800 - 0xFFFPUF Key Store (Reserved if KEK is stored in the OTP/eFuse block)
0x1000 - 0x1000+Image SizeBoot Image

 

best regards

Max

0 Kudos

371 Views
mastupristi
Senior Contributor I

Hi @Omar_Anguiano,

It has been a month since my last post. do you agree with me that the currently published documentation is wrong and deficient?

  • Table 2-11 should be modified as I indicated in my previous post
  • A detailed explanation of the "Image Version" field should be added in the documentation.

Please reply to me, and more importantly, let the documentation team know what changes need to be made.

0 Kudos