UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

取消
显示结果 
搜索替代 
您的意思是: 
Visitor shaw2321
Visitor
833 次查看
注册日期: ‎12-10-2018

zynq芯片突然无法启动,efuse被修改

我在项目开展过程中遇到了efuse突然被修改导致zynq无法启动的故障,reboot status寄存器值为0x0048600C,跟官网论坛这个帖子关于ps端efuse误烧写问题类似,这导致自己公司设计的板卡Zynq 7000  045系列芯片无法正常启动的故障。我也查阅了xilinx论坛,按照网址:

https://www.xilinx.com/support/answers/65240.html

中的附件zynq_efuse_read_normal.zip读取了efuse寄存器,其值如下:

eFuse  Write Protection (2-bits) = 11

OCM ROM 128KB CRC Enable   = 1

RSA Authenticaiton Enable        = 1

DFT JTAG Disable                      = 1

DFT Mode Disable                    =  1

按照AR# 65240,之前排查了硬件上电时序,修改了硬件,但是后面发现依然没有能够解决efuse被误写的问题,可能是硬件设计人员忽略了时钟这块的影响,没有完成时钟对应的硬件修改。

现在我想咨询一下:

1.如果软件设计从一开始就使能了OCM ROM 128KB CRC和RSA Authetication这两个安全功能,那么按照这个设计,即便在硬件设计不满足AR# 65240要求而导致efuse被误写的情况下,芯片是否能够正常启动运行?我们现在的启动文件是fsbl.elf+uboot.elf二合一生成的BOOT.bin文件,查了手册OCM CRC这块使能对启动应该没有影响,关键是RSA Authetication这个怎么从软件上去实现,不知从何开始。

 

2.在硬件完全按照AR# 65240要求完成设计和修改的情况下,有没有办法确认efuse被误写的问题百分百得到了解决,而不会再次发生无法启动的问题。

现在迫切想彻底解决这个问题,非常希望官网的工程师能够提供解决方案以及验证是否解决的方法,非常感谢

0 项奖励
6 条回复6
Xilinx Employee
Xilinx Employee
792 次查看
注册日期: ‎04-15-2011

回复: zynq芯片突然无法启动,efuse被修改

@shaw2321 

关于你的第一个问题,你是想继续用被修改了efuse的片子吗?从你读出来的efuse寄存器看,eFuse  Write Protection (2-bits) = 11,你的efuse已经使能了写保护,所以你RSA相关的hash信息,也没有办法写到efuse里了,所以这个片子已经不能用了。

RSA的介绍,你可以参考XAPP1175.

你后续硬件的修改,是保证你后续的其他片子不被修改efuse。只要你严格按照AR#65240,是可以避免efuse被烧的。请注意,这里面包括了上电和掉电要求。

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 项奖励
Visitor shaw2321
Visitor
758 次查看
注册日期: ‎12-10-2018

回复: zynq芯片突然无法启动,efuse被修改

第1个问题,我的想法是假设我现在就需要用RSA认证功能,然后将hash写入efuse,并且使能RSA,即令:

RSA Authenticaiton Enable        = 1

而硬件上依然沿用原来有风险,不满足AR# 65240要求的设计,假设在运行过程中又发生了efuse被改写,此时发生的变化我理解应该是:

eFuse  Write Protection (2-bits) = 11

OCM ROM 128KB CRC Enable   = 1

在这种情况下,按照我的理解,OCM ROM的程序是官方的ROM程序,不会改动,OCM ROM 128KB CRC Enable之后只会影响启动时间,但是CRC校验依然是正确的。此时虽然efuse又被改写了,但是zynq芯片是可以正常运行的,RSA校验能够通过。我这样的理解是否正确?这是软件上规避这个问题的一个思路。

 

 

第二个问题,硬件设计上,如果按照AR# 65240的要求,下图的Power-off Test,是不是只要有一个是YES(比如Test 1是YES,其他三个Test是NO的情况),就可以理解为efuse被改写的情况是不会发生?

power-off_201510271325343286.PNG

0 项奖励
Xilinx Employee
Xilinx Employee
750 次查看
注册日期: ‎04-15-2011

回复: zynq芯片突然无法启动,efuse被修改

@shaw2321 

关于第一个问题,如果你主动把eFuse Write Protection使能了,这确实会避免后续efuse被写。但这里仍然会有风险,因为你通常不会在第一次上电就运行烧写eFuse的程序吧,你总要运行一下测试程序去确认板子的好坏,不然有问题了,你debug也比较困难。如果你一上电就运行烧efuse的程序,那第一次上电时,也存在被动烧efuse的的风险。所以根本方法还是参考AR#65240.

关于第二个问题,你的理解是对的,只要有一个yes,就可以避免这个情况。

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 项奖励
Visitor shaw2321
Visitor
718 次查看
注册日期: ‎12-10-2018

回复: zynq芯片突然无法启动,efuse被修改

最后再确认下OCM ROM 128KB CRC Enable   = 1,这个被使能,因为ROM程序是原厂的程序,所以这个CRC被使能,只是会影响Zynq芯片的启动时间(多出来ROM 128KB CRC校验的时间),但不会影响zynq的芯片启动,是否可以这样理解?

0 项奖励
Xilinx Employee
Xilinx Employee
714 次查看
注册日期: ‎04-15-2011

回复: zynq芯片突然无法启动,efuse被修改

对的,你的理解是对的。
下面一个AR的问题,其中一个解决方案,就是通过使能BOOTROM CRC延长启动时间的。FYI
https://china.xilinx.com/support/answers/63149.html
-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Visitor shaw2321
Visitor
690 次查看
注册日期: ‎12-10-2018

回复: zynq芯片突然无法启动,efuse被修改

我使用了ug1025.zip\ug1025\zc702_secure_key_driver创建了SDK工程,修改xilskey_input.h文件的PS相关的宏定义如下,取消了宏定义XSK_EFUSEPL_DRIVER,并且将XSK_EFUSEPS_RSA_KEY_HASH_VALUE 修改我自己生成的HASH值,并且将xilskey_efuse_example.c中的写efuse操作使能,即让语句“PsStatus = XilSKey_EfusePs_Write(&PsInstancePtr);”执行

 

//#define XSK_EFUSEPL_DRIVER
#define XSK_EFUSEPS_DRIVER

#ifdef XSK_EFUSEPS_DRIVER #define XSK_EFUSEPS_ENABLE_WRITE_PROTECT TRUE /**< Enable the eFUSE Array * write protection */ #define XSK_EFUSEPS_ENABLE_RSA_AUTH TRUE /**< Enable the RSA * Authentication eFUSE Bit */ #define XSK_EFUSEPS_ENABLE_ROM_128K_CRC TRUE /**< Enable the ROM * code 128K crc eFUSE Bit */ #define XSK_EFUSEPS_ENABLE_RSA_KEY_HASH TRUE /**< Enabling this * RsaKeyHashValue[64] is * written to eFUSE array */ #define XSK_EFUSEPS_RSA_KEY_HASH_VALUE "0CB77707CA0EB77E8BBBCFC4737E240403AF36F03E266EACDF62A0EA45E319FE" #endif /* End of XSK_EFUSEPS_DRIVER */

SDK编译生成了secure_key_driver.elf文件后,使用的SDK 2015.2的XMD执行如下命令:

connect arm hw

dow fsbl.elf

con

stop

dow secure_key_driver.elf

con

stop

执行完上述操作之后,通过zynq_efuse_read_normal.zip读取的结果如下,红色框内的bit位上述操作修改的值,同时PPK HASH值(XSK_EFUSEPS_RSA_KEY_HASH_VALUE)也成功写入。

efuseWrite.png

 

图1

再使用bif文件生成使能了RSA的fsbl.elf+uboot.elf二合一镜像,芯片能够正常启动,执行结果如下:

bootrun.png

图2

这基本上说明了我写入efuse的HASH值,和使能RSA Authenticaiton的二合一(fsbl.elf+uboot.elf)镜像可以正常通过验证运行。现在我的疑问是这样子的,我们之前没有用RSA Authentication,运行过程中efuse被异常修改而无法运行的芯片,其efuse状态如下所示:

2222.png

图3

可以看到前面三个选项跟我一样都被Programmed,但是上图蓝色框内的选项,在我前面执行的操作中并没有编程,现在我的问题是,在我图1那种情况下运行的芯片A,在运行过程中,如果同样因为硬件设计而导致efuse被异常修改变成图3这种情况,此种情况下芯片A是否还能够正常运行,蓝色框内的三个值对芯片运行有什么影响?特别是12,16,10这几个值,不是很清楚其含义。

有没有什么参考资料提供了蓝色框内信息的描述?

0 项奖励