RT117x: when SRC_GPR9[30] could be 1?

[mastupristi]

Hi,

I read the description of SRC_GPR9[30] in the reference manual:

I use QSPI on FlexSPI, and I programmed in the fuses xSPI_FLASH_SEC_IMG_OFFSET 0xC80[23:16] the value 0x10 to have an offset of 4MB.

Then I program the images to the right locations using the Image Index field (in the Secure Provisioning Tool it is called Image Version), based on whose value, the ROM Bootloader executes the image at offset 0x0 or 4MB.
In addition, my FW is able to run “the other” image thanks to the API runBootloader():

however in all these cases SRC_GPR9[30] is always 0.
Then I wonder what the meaning of the phrase “This bit identifies which image must be used—
primary and secondary."

When SRC_GPR9[30] should be 1?

best regards

Max

[Omar_Anguiano]

This bit is set to 1 by ROM on cases where the primary image fails, specifically if the authentication fails or there exist errors on the image. 
The goal of a secondary image is having a backup in case the primary image fails. 

Best regards,
Omar

[mastupristi]

Hi @Omar_Anguiano ,

I would like to try but I currently have an unsecured board available (no encrypted XIP and no HAB).

I enabled dual image, with the plaintext images.

How can I artificially induce a boot failure of a plain-text image, such that I fallback on the other image so that I can then verify that GPR9[30] is 1?

best regards

Max

[Omar_Anguiano]

If during primary image read there is a page with a number of errors higher than ECC can correct, the boot ROM will turn on PERSIST_SECONDARY_BOOT bit and perform SW reset.
So it is needed to inject various errors to the pages, please refer to XECC chapter. 

Best regards,
Omar

[mastupristi]

Hi @Omar_Anguiano 

I just tried it with HAB closed. I tried corrupting one of the two images.

ImageL is @0x00000000, imageH is @0x00400000

imageL	imageH	versions	boot	SRC_GPR9[30]	SRC_GPR9[27:26]
ok	ok	L>H	L	0	0
ok	ok	L<H	H	0	0
ok	corrupt	L<H	L	0	1
corrupt	OK	L>H	H	0	1

In my tests the bit SRC_GPR9[30] I always see it as 0, instead it changes SRC_GPR9[27:26]

can you confirm this for me?

best regards

Max

[mastupristi]

hi@Omar_Anguiano 

since my FW is XIP, it runs from flash, I ask you if XECC can inject errors also reading from flash

best regards

Max

[Omar_Anguiano]

Yes, XECC can inject errors to flash.

[mastupristi]

Hi @Omar_Anguiano 

I have to simulate errors when the ROM boot reads the plaintext FW. this means that I cannot do this from my FW. And this thing has to be done after a warm reset. Also, since the FW is the clear, the ROM boot has no reason to read the FW before jumping into it. Is that right?

Please can you detail what you have in mind? Eg. programming XECC and then resetting? How to program XECC?

best regards

Max

[mastupristi]

come on, NXP guys, don't be shy...