Hello NXP experts,
I tried to forward my i.MX8DXP SoC lifecycle with sc_seco_forward_lifecycle( ) call,the lifecycle is one of the followin value:
/**
* SECO_LIFECYCLE_DEFAULT = (1U << 0) Default fab mode (early_fuses_pgrm not blown)
* SECO_LIFECYCLE_FAB = (1U << 1) Fab mode
* SECO_LIFECYCLE_NO_SECRETS = (1U << 2) No secrets
* SECO_LIFECYCLE_SECRETS = (1U << 3) With Secrets
* SECO_LIFECYCLE_SC_FW_CLSD = (1U << 4) SCU FW Closed
* SECO_LIFECYCLE_SECO_FW_CLSD = (1U << 5) SECO FW Closed
* SECO_LIFECYCLE_CLOSED = (1U << 6) Closed
* SECO_LIFECYCLE_CLOSED_FW = (1U << 7) Closed with FW
* SECO_LIFECYCLE_PART_RTN = (1U <<
* SECO_LIFECYCLE_RTN = (1U << 9) Field return
* SECO_LIFECYCLE_NO_RTN = (1U << 10) No Return
*/
But the "sc_seco_forward_lifecycle( )" function returns sucessfully only when lifecycle is "SECO_LIFECYCLE_CLOSED_FW",any other value possible will result failure.
1. I have burned OEM SRK hash into fuse[730-745]
2. I used a boot image signed with the corresponding SGK
3. I called sc_seco_forward_lifecycle(ipcHndl, 16) , but it returned with error code 11.
The commands I used to sign the boot image are:
./cst -i csf_boot_image.txt -o ipl-imx8qxp-cpu_c0.imx.signed
./cst -i csf_fs_image.txt -o ifs-imx8qxp-cpu-graphics.imx.signed
The csf files are attached.
Please help to check what is lost or fault, thank you.
Best Regards.
Liweihua
Solved! Go to Solution.
这个是正常的,刚刚烧录好的key,不能马上被使用,所以seco内部认为是没有key的,不能切换到oem closed,只有重启之后,key才会被seco读进去,然后才能切换到oem close。
This is normal. The key that has just been burned cannot be used immediately, so seco internally thinks that there is no key and cannot be switched to oem closed. Only after restarting, the key will be read by seco, and then can be switched to oem close .
这个是正常的,刚刚烧录好的key,不能马上被使用,所以seco内部认为是没有key的,不能切换到oem closed,只有重启之后,key才会被seco读进去,然后才能切换到oem close。
This is normal. The key that has just been burned cannot be used immediately, so seco internally thinks that there is no key and cannot be switched to oem closed. Only after restarting, the key will be read by seco, and then can be switched to oem close .
This Seco behavior is causing some headache during or production procedure. Because we need a extra reboot after fusing the keys to perform the ahab_close(). Unfortunately we need here a "real reboot" and not a simple partition reset. To ensure that Seco is restarted we implemented a reset by calling "sc_pm_reset" from U-Boot side. Then we can use sucessfully ahab_close on next boot but only if the U-Boot is also signed by the PKI
Hello?
Can someone help with this problem?
Now the OEM close is successful,
but after burning the SRK Hash,
it need to restart target board one time.
Is there any way to update lifecycle successfully without restarting after burning SRK Hash?
I have searched the uboot codes, but not found any hint about this problem.
Thanks.
Liweihua
Thanks!
Liweihua
Hi Liweihua
one can look at suggestions provided on
https://community.nxp.com/t5/i-MX-Processors/About-the-SoC-lifecycle/m-p/1204107#M166948
Best regards
igor
Hello igorpadykov ,
The two suggestions provided on
https://community.nxp.com/t5/i-MX-Processors/About-the-SoC-lifecycle/m-p/1204107#M166948,
The method that use JTAG should be excluded firstly, because the environment we are facing is mass production site;
The second suggestion is what I want to ask, why it failed when I call sc_seco_forward_lifecycle(ipcHndl, 16)?
Are there any prerequisites for successful execution of this call with the second parameter equals 16?
Thank you.
Liweihua
Hi Liweihua
for sc_seco_forward_lifecycle call usage one can look at SCFW (sc_fw_api_qx_b0.pdf)
documentation included in SCFW Porting Kit
Best regards
igor
Now the OEM close is successful,
but after burning the SRK Hash,
it need to restart target board one time.
Is there any way to update lifecycle successfully without restarting after burning SRK Hash?
I have searched the uboot codes, but not found any hint about this problem.
Thanks.
Liweihua