发 帖  
原厂入驻New
申请华秋企业认证 多层板首单免费打样!
30s提交资料,10分钟通过审核(免费赔付+顺丰包邮)>>立即报名
[问答] Spartan-6“安全更新”机制无法正常运行
147 FPGA 编程
分享
大家好,
我正在尝试让“安全更新”机制正常运行。
我希望在地址为0x0的FLASH中有一个小的HEADER图像,它将使用地址0x600000处的MAIN图像对FPGA进行编程。
但是,如果MAIN映像损坏,那么我希望FPGA“返回”并使用地址0x10000处的GOLDEN映像进行编程。
MAIN图像和GOLDEN图像都允许我用新图像覆盖(通过以太网)字段中的MAIN图像。
GOLDEN图像位于受保护的FLASH区域,因此无法在现场覆盖。
我手动生成了一个HEADER图像。
我已将MAIN图像的地址设置为0x600000,将GOLDEN图像的地址设置为0x10000。
我已将HEADER,GOLDEN和MAINimages写入FLASH。当我为FPGA供电时,HEADER图像加载并使用MAIN图像对FPGA进行编程。
但是,如果我损坏MAIN映像并重新启动FPGA,则不会加载GOLDEN映像。
考虑到我必须在错误的地址处设置GOLDEN图像,我在HEADER图像中交换了MAIN和GOLDEN图像的地址,并对FPGA进行了电源循环。
HEADER图像使用GOLDEN图像加载和编程FPGA。
因此,GOLDEN和MAIN图像的FLASH中的地址是正确的,并且HEADER图像看起来配置正确,但“后备”机制似乎不起作用。
我做错了什么?
谢谢,
西蒙

以上来自于谷歌翻译


以下为原文

Hi All,

I am trying to get the 'Safe Update' mechanism working. I want to have a small HEADER image in FLASH at address 0x0 that will program the FPGA with the MAIN image at address 0x600000. However, IF that MAIN image is corrupt then I want the FPGA to 'fallback' and be programmed with the GOLDEN image at address 0x10000. Both the MAIN image and GOLDEN image allow me to overwrite (via Ethernet) the MAIN image in the field with a new image. The GOLDEN image is in an area of FLASH that is protected so cannot be overwritten in the field.



I have manually generated a HEADER image.



I have set the address of the MAIN image to 0x600000 and the address of the GOLDEN image to 0x10000. I have written the HEADER, GOLDEN and MAIN images to FLASH. When I powercycle the FPGA the HEADER image loads and programs the FPGA with the MAIN image.

However, if I corrupt the MAIN image and powercycle the FPGA the GOLDEN image is not loaded. Thinking that I must have the GOLDEN image at the incorrect address I swapped the addresses of the MAIN and GOLDEN images in the HEADER image and powercycLED the FPGA. The HEADER image loads and programs the FPGA with the GOLDEN image. Therefore, the addresses in FLASH of the GOLDEN and MAIN images are correct and the HEADER image appears to be configured correctly, but the 'fallback' mechanism doesn't appear to be working.

What have I done wrong?

Thanks,

Simon
0
2019-7-23 11:55:26   评论 分享淘帖 邀请回答

相关问题

12个回答
现在还有一段时间了,但我相信我通过勾选ISE中的'-g reset_on_error:'选项>生成编程文件(右键单击属性)>主图像中的常规选项来重新解决这个问题。
如果找到SYNC字但CRC失败则可以推测此选项会导致复位,而这又会回落到黄金映像。
似乎适合我。
西蒙
在原帖中查看解决方案

以上来自于谷歌翻译


以下为原文

It was a while back now, but I belive that I resoved this issue by ticking the '-g reset_on_error:' option in ISE > Generate Programming File (right click for properties) > General Options in my main image.
 
Presumable if the SYNC word is found but the CRC fails then this option causes a reset which in turn fallsback to the golden image.
 
Appears to work for me.
 
Simon
View solution in original post
2019-7-23 12:10:33 评论

举报

嗨,
您可以检查您的bitgen设置中是否设置了以下选项
next_config_register_write:在主图像中禁用。
如果未设置此选项,请告知我们结果。
在配置失败期间还将状态寄存器分享给黄金映像。
--Krishna

以上来自于谷歌翻译


以下为原文

Hi,
 
Can you check if the following option is set in your bitgen settings
next_config_register_write:Disable in the main image.
If not set this option and let us know the results. Also share us the status registers during configuration failure to golden image.
 
--Krishna 
2019-7-23 12:26:18 评论

举报

嗨,你是怎么破坏多重启动图像的?
您是否编辑了CRC寄存器?请注意,CRC错误或看门狗超时错误(跟踪检测同步字所用的时间)会触发Spartan6器件的回退。如果您正在编辑多重引导映像的内容,那么
必须100%确定损坏的图像在配置期间抛出CRC错误。要测试图像是否正确损坏,请在JTAG模式下使用多重启动映像配置FPGA。
如果配置失败并出现CRC错误,那么我们应该期待回退,假设bitgen设置被设置为适当的值.Regards,Krishna
--------------------------------------------------
---------------------------------------------请将帖子标记为
如果提供的信息能够回答您的问题/解决您的问题,请“接受为解决方案”。给予您认为有用的帖子。

以上来自于谷歌翻译


以下为原文

Hi,

How did you corrupt the multiboot image? Did you edit the CRC register?

Please note that either a CRC error or a watchdog time out error (tracks the time taken for the detection of sync word) triggers fallback in Spartan6 devices.

If you are editing the contents of the multiboot image, you have to be 100% sure that the corrupted image throws a CRC error during configuration.
To test whether the image was corrupted properly or not, please configure the FPGA with the multiboot image in JTAG mode. If the configuration fails with a CRC error then we should expect the fallback assuming that the bitgen settings were set to appropriate values.

Regards,
Krishna-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
2019-7-23 12:42:08 评论

举报

嗨Krishna(s)?
感谢您的回复。
我在主图像和黄金图像中没有未选中“将多点设置放入比特流”。
在失败期间,我从未进入黄金映像,因此无法读取状态寄存器。
我只通过将一半图像写入FLASH来破坏主图像(在数据传输完成之前中止了数据传输,这可能会在现场发生),我认为这已损坏主图像,因为在电源循环后FPGA将无法编程
(DONE LED熄灭)。
由于我写了一半的图像,所以会找到SYNC字0xaa995566,因为它位于图像的开头,所以这可能意味着看门狗不会超时。
写入图像的一半可能不会导致CRC错误。
但是,由于FPGA尚未编程,因此可能会出现某种错误。
我尝试在编程viaImpact之前手动编辑主图像位文件。
但是,Impact引发了一个ERROR,指出我更改的字节无效然后崩溃(Impact应用程序已关闭)。
问候,
西蒙

以上来自于谷歌翻译


以下为原文

Hi Krishna(s)?,
 
Thanks for your reply.
 
I have "Place MultiBoot Settings into Bitstream" unticked in the Main image and Golden image.
 
During a failure I never get to the Golden image so I cannot read the Status registers.
 
I corrupted the Main image by only writing half the image to FLASH (aborted the data transfer before it is finished, something that may well happen in the field), I presume that this has corrupted the Main image because after a powercycle the FPGA will not program (DONE LED is off). Since I have written half the image the SYNC word 0xaa995566 will be found, as it is at the beginning of the image so presumably this means that the watchdog will not timeout. Writing half the image may or may not result in a CRC error. However, since the FPGA has not been programmed then presumably some sort of error has occurred.
 
I tried to manually edit the Main image bitfile, prior to programming via Impact. However, Impact threw an ERROR stating that the byte I changed was invalid and then crashed (Impact application closed).
 
Regards,
 
Simon
 
2019-7-23 13:01:11 评论

举报

嗨西蒙,
简单的方法是编辑比特流中的CRC寄存器值。
如何在.bit文件中找到CRC寄存器?
CRC寄存器是type1数据包寄存器。
有关类型1数据包的说明,请参阅UG380的表5-24,第91页:
由于我们正在寻找CRC值,因此type1 write1到CRC寄存器的命令将是 - >
001 xx xxxxxx xxxxx
001 10 000000 00010
从表5-23确定10
从表5-30确定000000,因为CRC寄存器地址是6'h00
将其翻译为HEX是30 02。
在您的位文件中,通过在任何编辑器中打开位文件来搜索值30 02。
后跟30 02的值是CRC值。
现在,将此crc值编辑为某个随机值。
这将有助于抛出CRC错误。
试试这个,看看后备是否正常工作。
问候,
克里希纳
--------------------------------------------------
---------------------------------------------请将帖子标记为
如果提供的信息能够回答您的问题/解决您的问题,请“接受为解决方案”。给予您认为有用的帖子。

以上来自于谷歌翻译


以下为原文

Hi Simon,
 
The easy way would be to edit the CRC register value in the bitstream.
 
How to find the CRC register in .bit file?
 
The CRC register is a type1 packet register. Refer to Table 5-24, page 91 of UG380 for a description of a Type 1 Packet:
 
  Since we are looking for CRC value,the command for type1 write1 to CRC register would be->
 
001 xx xxxxxx xxxxx
 
001 10 000000 00010
 
10 is determined from Table 5-23
000000 is determined from Table 5-30 as the CRC register address is 6'h00
 
Translating this to HEX is 30 02.
 
In your bit file,search for the value 30 02 by opening the bit file in any editor. The value followed by 30 02 is the CRC value.
 
Now, edit this crc value to some random value. This will help in throwing the CRC error.
 
Try this and see if the fallback works correctly.
 
Regards,
Krishna 
-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
2019-7-23 13:08:29 评论

举报

嗨克里希纳,
我的位文件中有三个0x30 02实例。
如果我在每个实例中单独修改0x30 02之后的字节,那么在每个实例中,位文件仍然使用Impact对FPGA进行成功编程。
问候,
西蒙

以上来自于谷歌翻译


以下为原文

Hi Krishna,
 
There are three instances of 0x30 02 in my bitfile. If I modify the byte following 0x30 02 in each instance individually the bitfile still sucessfully programs the FPGA using Impact in each instance.
 
Regards,
 
Simon
2019-7-23 13:24:04 评论

举报

嗨西蒙,应该只有一个0X3002。
你可以附上位文件吗?问候,克里希纳
--------------------------------------------------
---------------------------------------------请将帖子标记为
如果提供的信息能够回答您的问题/解决您的问题,请“接受为解决方案”。给予您认为有用的帖子。

以上来自于谷歌翻译


以下为原文

Hi Simon,

There should be only one 0X3002. Can you please attach the bit file?

Regards,
Krishna-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
2019-7-23 13:36:52 评论

举报

嗨克里希纳,
0x3002的三个实例如下所示。
问候,
西蒙

以上来自于谷歌翻译


以下为原文

Hi Krishna,
 
The three instances of 0x3002 are as shown below.
 

 

 

 
Regards,
 
Simon
2019-7-23 13:44:45 评论

举报

更新:
使用IMPACT中的“读取设备状态”选项,这是主图像良好时的输出.....
...这是主图像损坏时的输出(仅将图像的一半写入FLASH)...
...这表明主映像损坏导致了CRC错误,但也没有发生FALLBACK。
有什么想法吗?
西蒙

以上来自于谷歌翻译


以下为原文

Update:
 
Using the 'Read Device Status' option in IMPACT here is the output when the Main image is good .....
 

 
...and here is the output when the Main image is corrupted (by only writing half the image to FLASH) ...
 

 
... this shows that the Main image corruption has caused a CRC error, but also that FALLBACK has not occured.
 
Any ideas why?
 
Simon
2019-7-23 13:50:50 评论

举报

进一步更新:
我从MAIN图像中完全删除了SYNC字,并在电源循环后加载了GOLDEN图像。
当我读到状态寄存器时,它看起来像这样....
....所以后备工作正常,但只有当WATCHDOG因未找到SYNC字而超时时。
问题是为什么在出现CRC错误时回退不起作用?
谢谢,
西蒙

以上来自于谷歌翻译


以下为原文

Further Update:
 
I removed the SYNC word completly from the MAIN image and after a powercycle the GOLDEN image loaded. When I read the status register it looked like this ....
 

 
.... so fallback is working, but only when the WATCHDOG times out as a result of not finding the SYNC word.
 
The question is why does fallback not work when there is a CRC error?
 
Thanks,
 
Simon
2019-7-23 14:10:48 评论

举报

> ....所以后备工作正常,但只有当WATCHDOG因未找到SYNC字而超时时。>问题是为什么在出现CRC错误时回退不起作用?
嗨西蒙,
我们期望在这里有相同的行为,我们使用Spartan6 Multiboot进行了一系列测试,我可以确认:
当SYNC字不存在但是损坏的图像(例如由于取消更新)不会触发回退时,它可以工作。
同时有解决方案吗?
问候,

以上来自于谷歌翻译


以下为原文

> .... so fallback is working, but only when the WATCHDOG times out as a result of not finding the SYNC word.
> The question is why does fallback not work when there is a CRC error?
 
Hi Simon,
we expect the same behavior here, we did a bunch of tests with Spartan6 Multiboot and I can confirm:
It works when the SYNC word isn't there but a corrupted image (due to a canceled update for example) won't trigger the fallback. Is there a solution to it in the meanwhile?
 
Greetings,
2019-7-23 14:26:06 评论

举报

现在还有一段时间了,但我相信我通过勾选ISE中的'-g reset_on_error:'选项>生成编程文件(右键单击属性)>主图像中的常规选项来重新解决这个问题。
如果找到SYNC字但CRC失败则可以推测此选项会导致复位,而这又会回落到黄金映像。
似乎适合我。
西蒙

以上来自于谷歌翻译


以下为原文

It was a while back now, but I belive that I resoved this issue by ticking the '-g reset_on_error:' option in ISE > Generate Programming File (right click for properties) > General Options in my main image.
 
Presumable if the SYNC word is found but the CRC fails then this option causes a reset which in turn fallsback to the golden image.
 
Appears to work for me.
 
Simon
2019-7-23 14:39:40 评论

举报

只有小组成员才能发言,加入小组>>

50个成员聚集在这个小组

加入小组

创建小组步骤

关闭

站长推荐 上一条 /10 下一条

快速回复 返回顶部 返回列表