AM625: Unable to authenticate boot image loaded from NORFLASH even with MCU+ SDK AM62x version 10.01.00.33 when not setting OSPI Input Clock Frequency and Divider as 166MHz and 2 using SysConfig tool on AM625 HS FS chip

Hi,

I have assigned the thread to the concerned expert, please expect response by next week.

Regards,
Aparna

Zijian XU said:

"Failed to authenticate Image."

This happens when the appimage is fails authentication using SYSFW.

The API which does this is:

Can you help answer the following:

1. Is it a custom EVM/board? If yes, have you updated the DDR configuration file?
2. Is the NOR flash part which you are using the same as on the TI AM62x EVM?
3. Can you go to SysConfig and check if the PHY is enabled or not? Please also comment on the mode of operation, I am assuming 8D-8D-8D?

Looking forward to your response.

Regards,

Vaibhav

Hi!

Answers to your questions:

1. Yes, it is a custom board. But, we are using the same DDR as the EVM (SK-AM62-LP), so the DDR configuration file keeps the default, and I am sure the DDR is working normally, I've tested running M4F app on DDR already.

2. The NOR flash is not the same, Ours is Micron's MT25QL01GBBB8E12-0SIT. The current configurations differs from the default in SysConfig tool are listed below:

Flash Type: Serial Nor Flash
Protocol: 1S-1S-1S
Flash Size In Bytes: 134217728
Flash Page Size In Bytes: 256
Flash JEDEC Manufacturer ID: 0x20
Flash JEDEC Device ID: 0xBA21
Flash Block Size In Bytes: 65536
Flash Sector Size In Bytes: 4096
Block Erase CMD (3B): 0xD8
Block Erase CMD (4B): 0xDC
Sector Erase CMD (3B): 0x20
Sector Erase CMD (4B): 0x21
Read Command: 0x13
Write/Page Program Command: 0x12
Chip Erase Command: 0xC4
Enable 4 Byte Addressing: TRUE

3. The PHY is NOT enabled, since we don't have it in the physical board. The operation mode is 1S-1S-1S as shown above.

Additionally, we ONLY enabled 4 pins in OSPI, as shown below:

OSPI CLK Pin(OSPI0_CLK): OSPI0_CLK/G19, No Pull, Rx Enabled
OSPI CS0 Pin(OSPI_CSn0): OSPI0_CSn0/F19, No Pull, Rx DISABLED
OSPI Data I/O Pin0(OSPI0_D0): OSPI0_D0/F18, No Pull, Rx Enabled
OSPI Data I/O Pin1(OSPI0_D1): OSPI0_D1/G17, No Pull, Rx Enabled

Also, I have ROUGHLY checked that the memory content from 0x84000000 to 0x8400012C are the same for 166MHz/2 and lower clock settings situations just before doing the real authentication operation (Bootloader_socAuthImage() after doing DDR copy, which the value of ddrCopy variable is 1) from CCS's Memory Browser. Can I assume the NOR flash is fine with copying the image to the DDR and just SYSFW is not working fine, or the data may be corrupted some where else?

BR,

Zijian XU

Hi,

Can you go ahead and share the flash parts json file which you uploaded? Or just the sysconfig setting of the ospi and flash tab will also work for me.

I can then go ahead and share the required changes that needs to be done.

Best Regards,

Vaibhav

Hi,

Let me upload all my sbl related projects to you, please try different slow combinations of OSPI Input Clock speed and divider settings. I haven't use any other flash config json file as you can check in the projects below. Please use UART boot mode and `uart_uniflash.py` with this configuration, then switch to OSPI NOR FLASH boot mode to start your board:

--flash-writer=sbl_prebuilt/am62x-sk-lp/sbl_uart_uniflash_stage1.release.hs_fs.tiimage
--file=/path/to/sbl_uart_uniflash_stage2_am62x-sk-lp_r5fss0-0_nortos_ti-arm-clang-xzj/Debug/sbl_uart_uniflash_stage2_am62x-sk-lp_r5fss0-0_nortos_ti-arm-clang-xzj.appimage.hs_fs --operation=flash --flash-offset=0x0
--file=/path/to/sbl_null_am62x-sk-lp_r5fss0-0_nortos_ti-arm-clang/Debug/sbl_null.Debug.hs_fs.tiimage --operation=flash --flash-offset=0x0
--file=../../examples/drivers/ipc/ipc_rpmsg_echo_linux/am62x-sk-lp/r5fss0-0_freertos/ti-arm-clang/ipc_rpmsg_echo_linux.release.appimage.hs_fs --operation=flash --flash-offset=0xA00000 

sbl_uart_uniflash_stage2_am62x-sk-lp_r5fss0-0_nortos_ti-arm-clang-xzj.zip

sbl_null_am62x-sk-lp_r5fss0-0_nortos_ti-arm-clang.zip

BR,

Zijian XU.

Hi,

Zijian XU said:

sbl_uart_uniflash_stage2_am62x-sk-lp_r5fss0-0_nortos_ti-arm-clang-xzj.zip

It says that this attachment is invalid.

So we can do one quick thing, can we run a basic 1s-1s-1s test to see if flash configuration works fine?

Please go ahead and set the flash to operate in 1s-1s-1s mode.

Let me know the results of the same.

Regards,

Vaibhav

Hi,

I uploaded the invalid file again, please have a try again... And I've tested 1s-1s-1s erase/write/read-ing in different combinations of OSPI Input Clock and Divider settings, such as 166MHz/2, 166MHz/32, and so on, it should be okay(since too long time to test the whole 128MB of the NOR Flash, I just run the test code for about 1 hour), you can also find the NOR flash testing code inside the uploaded projects(related codes has been commented out).

For 1s-1s-1s mode, the authentication will fail for lower OSPI speed, only 166MHz/2 is passed. But what I want is to authenticate in 1s-1s-1s mode with lower speed.

0820.sbl_uart_uniflash_stage2_am62x-sk-lp_r5fss0-0_nortos_ti-arm-clang-xzj.zip

BR,

Zijian XU.

Hi Zijian,

The subject matter expert is currently out of office. Please expect delayed responses.

Regards,

Tushar

Hello,

Zijian XU said:

For 1s-1s-1s mode, the authentication will fail for lower OSPI speed, only 166MHz/2 is passed. But what I want is to authenticate in 1s-1s-1s mode with lower speed.

If the authentication fails, the bootloader driver copies to image to DDR & authenticates from there which should mostly pass resulting in successful boot at the end.

Do you not observe the same behaviour?

Regards,

Prashant

Hi Prashant,

I observed the same behaviour: after the authentication, the image content copied to DDR before the authentication still does not change. Please notice that for SDK version 10.01.00.33, for all OSPI clock / divider situations, all the image content will be copied to DDR, thus, it all produce the same warning, as I have mentioned in the original question:

Zijian XU said:

I noticed that it still produces a warning saying, "Failed to authenticate and copy on the go, reading the image to DDR."

For SDK version 10.01.00.33: The differences between 166MHz/2 and other combinations are just if they got authenticated and decrypted correctly. All images are got copied to DDR first.

For SDK version 10.00.00.14: The images are not copied, as I found in the SDK source code, and the authentication will directly fail.

BR,

Zijian XU

Hi Zijian,

Zijian XU said:

For SDK version 10.01.00.33: The differences between 166MHz/2 and other combinations are just if they got authenticated and decrypted correctly. All images are got copied to DDR first.

Then you may continue with this SDK version.

For authenticating directly from flash, it is expected the flash is run at the highest mode possible.

Regards,

Prashant

Hi Prashant,

Zijian XU said:

Failed to authenticate and copy on the go, reading the image to DDR."

I still don't understand the reason for authentication failure on DDR, even the content is fully copied from flash succesfully, for lower flash speed configuration. What's the relationship of the content on DDR and lower flash speed?

BR,

Zijian Xu.

Hello,

Zijian XU said:

Please notice that for SDK version 10.01.00.33, for all OSPI clock / divider situations, all the image content will be copied to DDR,

This is incorrect. The image is first authenticated directly from the flash. If only it fails, the bootloader driver copies the image to DDR and try authenticating from there.

So, the following log means:

Zijian XU said:

Failed to authenticate and copy on the go, reading the image to DDR."

The authentication directly from flash failed so the image is copied to DDR. If the authentication pass then the image would be booted otherwise the boot failure occurs.

The direct authentication from flash can fail if the flash is not initialized in the highest mode possible as it may not provide enough read throughput in the lower speed modes. 

Regards,

Prashant

Hi Prashant, 

Prashant Shivhare said:

The direct authentication from flash can fail if the flash is not initialized in the highest mode possible as it may not provide enough read throughput in the lower speed modes. 

Does it mean the low speed mode of flash may make the timeout for doing the SYSFW authentication?

BR,

Zijian Xu

Hello,

Zijian XU said:

Does it mean the low speed mode of flash may make the timeout for doing the SYSFW authentication?

That is correct. Even though the flash driver in the SDK may be able to R/W the flash correctly in the lower speed mode, the TIFS could still fail to authenticate the image directly from the flash because of the lower throughput.

The TIFS has relaxed this requirement from v11 so you may try the latest TIFS binaries once:

https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/?id=c4c02adc7068e241f71f3a844e5c8572c4981145

Regards,

Prashant

Hi,

Prashant Shivhare said:

The TIFS has relaxed this requirement from v11 so you may try the latest TIFS binaries once:

https://git.ti.com/cgit/processor-firmware/ti-linux-firmware/commit/?id=c4c02adc7068e241f71f3a844e5c8572c4981145

I will try later to verify if it works. Thank you!

BR,

Zijian Xu