ZYBO Z7 board bricked after attempting secure boot

[phyguy]

I actually reached out to customer service last year about this, but they directed me here to the forums. I need the board for a project now and I am hoping to get a replacement because the board may not meet the Xilinx proper voltage synchronization required for secure boot. I would need someone in the technical staff to confirm this according to customer service.

History

I was working on a secure boot project, and apparently the ZYBOZ7 board may be susceptible to the following:

https://support.xilinx.com/s/article/65240?language=en_US

The board was working fine even with the PL eFUSE was set with an AES key. I was able to program encrypted bit streams and boot encrypted boot files. Because of Xilinx starbleed exploit:

https://support.xilinx.com/s/article/73541?language=en_US

Xilinx is instructing users to add authentication. I followed xpp1175:

https://support.xilinx.com/s/article/73541?language=en_US

and made certain that the PL eFuse was disabled as per the steps in the xapp. After running secure key to program the PS eFuse, the serial terminal printed out success and even read back the correct PPK Hash value. For me, the board stopped working on reboot. The board is 100% bricked at this point and when reading back the PL eFuse it is all zeros meaning it was corrupted. The PL eFuse always read back the AES key until I added authentication and programed the PS eFuse.

Can you confirm that the power up and down sequences are with the Xilinx spec? See

https://support.xilinx.com/s/article/65240?language=en_US

 

I've worked with board after this were the voltage was synchronized correctly and had no issue implementing secure boot. It comes down to confirming the voltages are correct to support secure boot though.

 

Thanks!

Edited July 12 by phyguy

[JColvin]

Hi @phyguy,

In general, Digilent does not have any support for secure boot for any of our device, as per the following threads:

As for the Design Advisory 65240, my understanding is that the at least the power-up sequences from point 1 are followed. The power-down sequence I am not certain about, particularly (and perhaps this is my ignorance speaking) because devices like the Zybo Z7 can be powered over USB and therefore can unexpectedly have the cable disconnected and the power shut off in an an uncontrolled manner.

Regardless, I have reached out to one of the design engineers for their insight into the three potential failure points.

Thanks,
JColvin

[phyguy]

Hello JColvin,

Thanks for the quick reply. Secure boot was actually working fine for over a week, it was when I tried to implement authentication that the board stopped working. The PS is now unusable because it requires authentication which was corrupted. I can assure you that power was not lost during the programming and the application even read back the correct keys. It was on restart that the PS stopped responding. I talked with other engineers familiar with this issue and they've said that they've seen boards with incorrect voltage synchronization that were setup for authentication work (with authentication) for up to 10 reboots before the PS gave out.

I understand that you are consulting with design engineers. I'd like to just get an answer on whether the voltage synchronization meets the Xilinx requirement. If not, I would really like to try and get a replacement. Thank again for the help.

 

P.S.

I no longer need secure boot or authentication, I just need the PS to work. 

Edited July 15 by phyguy

[JColvin]

Hi @phyguy,

The design engineer did not (and likely will not) have time to perform the tests, but they assured me that the power-on sequence, the PS_CLK, and PS_POR_B are all following the Xilinx recommendations. There is a bit more detail in the Reference Manual here: https://digilent.com/reference/programmable-logic/zybo-z7/reference-manual#power_sequencing.

However, historically speaking, Digilent did not check the power-off sequences on our older boards which includes both variants of the Zybo-Z7. The Design Advisory 65240 seems to indicate that all three failure points need to occur before power-off sequence becomes a potential problem. To me, this would mean that there "shouldn't" be a problem, but I have no further insight if that's the end of the story.

But to the point that you are more interested in (replacement), I don't have final say (and Sales, whom I believe you reached out to first, indicated to me that you might be past the 1 year warranty, https://digilent.com/shop/shipping-returns/#warranty) but I would be willing to do one replacement. The catch of course is that if the board does get replaced, there is a chance that the exact same failure you experienced may happen again, but as Digilent does not support secure boot methods, we will not be offering a running chain of replacements.

Let me know if you have any questions.

Thanks,
JColvin

[phyguy]

I will not be attempting a secure boot on the replacement. I just need the board to boot normally. How do we start the process on replacement?

[JColvin]

Hi @phyguy,

The email chain you had previously going with the Sales team will get the replacement process going. I already spoke with them about this situation from my perspective, so they should have everything they need regarding technical support. They will follow up with you to confirm shipping address and other details that I do not have access to.

Thanks,
JColvin

[phyguy]

Awesome! That you for your time. Great communication and customer support!