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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
104 Views
Registered: ‎05-11-2018

Unable to connect to ZCU9EG after programming RSA_EN efuse

Jump to solution

Hello,

I have a working ZCU9EG design with an attached QSPI containing a RSA-authenticated boot image (FSBL + PL + PS-application). Originally I had programmed the PPK0 fuses, but NOT the RSA_EN fuse. This booted without issue so I (naively) thought I could program RSA_EN to continue hardening the boot process. The good news is that the design I programmed into QSPI still boots successfully.  The bad news is that I can no longer connect to the device to program new QSPI images via either Vivado's (v2017.4) hardware manager or SDK's (v2017.4) program_flash utility. In both cases it complains about not being able to connect to the device, as shown in the following output of the SDK's program_flash utility:

cmd /C program_flash -f BOOT.bin -offset 0 -flash_type qspi_single -fsbl FSBL.elf -cable type xilinx_tcf url TCP:127.0.0.1:3121 

****** Xilinx Program Flash
****** Program Flash v2017.4 (64-bit)
  **** SW Build 2086221 on Fri Dec 15 20:55:39 MST 2017
    ** Copyright 1986-2017 Xilinx, Inc. All Rights Reserved.

Connecting to hw_server @ TCP:127.0.0.1:3121

WARNING: Failed to connect to hw_server at TCP:127.0.0.1:3121
Attempting to launch hw_server at TCP:127.0.0.1:3121

Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-JTAG-SMT2NC-210308A6518D
	Device 0: jsn-JTAG-SMT2NC-210308A6518D-24738093-0

Retrieving Flash info...

Initialization done, programming the memory
ERROR: [Xicom 50-60] Connect operation failed. Please make sure that the device is active.
Problem in Connecting to Target
Flash programming initialization failed.

ERROR: Flash Operation Failed

If I go to program the exact same binary onto another board which has RSA_EN = 0 then the connection is fine and the QSPI can be programmed without any issues.

If I use xsct within SDK (v2017.4) to connect to the device on the board that has RSA_EN = 1, I see that there is no PSU device showing up on the JTAG chain for some reason:

xsct% connect
tcfchan#1
xsct% targets
  1  PS TAP
     2  PMU
     3  PL
  4  dummy_dap

Compare that to the device on the board where RSA_EN = 0:

xsct% connect
tcfchan#2
Info: Cortex-A53 #0 (target 9) Stopped at 0x0 (Reset Catch)
xsct% targets
  1  PS TAP
     2  PMU
     3  PL
  4  PSU
     5  RPU (Reset)
        6  Cortex-R5 #0 (RPU Reset)
        7  Cortex-R5 #1 (RPU Reset)
     8  APU
        9  Cortex-A53 #0 (Reset Catch, EL3(S)/A64)
       10  Cortex-A53 #1 (Power On Reset)
       11  Cortex-A53 #2 (Power On Reset)
       12  Cortex-A53 #3 (Power On Reset)

Is there any reason why enabling the RSA_EN fuse would drop the PSU complex off of the JTAG chain? When I updated the RSA_EN fuse using the RSA fuse programming sample code it reported the security control fuses as shown below. Given that JTAG wasn't disabled I would expect to be able to see the PSU, but perhaps something else has crapped out and it just had the misfortune of occurring at the same time that I updated the RSA_EN fuse?

    Secure and Control bits of eFuse:
    
    AES key CRC check is enabled
    Programming AES key is enabled
    All boots must be encrypted with eFuseAES key is disabled
    BBRAM key is not disabled
    Error output from PMU is enabled
    Jtag is enabled
    DFT is enabled
    PROG_GATE feature is enabled
    Reboot from JTAG mode is enabled
    RSA authentication is enabled
    Locks writing to PPK0 efuse
    Revoking PPK0 is disabled
    writing to PPK1 efuses is not locked
    Revoking PPK1 is disabled
    LBIST is in disabled state
    PBR boot error halt is disabled
    Zeroization of registers in Low Power Domain (LPD) during boot is disabled
    Zeroization of registers in Full Power Domain (FPD) during boot is disabled
    
    User control bits of eFuse:
    Programming USER_0 fuses is enabled
    Programming USER_1 fuses is enabled
    Programming USER_2 fuses is enabled
    Programming USER_3 fuses is enabled
    Programming USER_4 fuses is enabled
    Programming USER_5 fuses is enabled
    Programming USER_6 fuses is enabled
    Programming USER_7 fuses is enabled
    Reserved 1 bits are not programmed on eFUSE
    Reserved 2 bits are programmed on eFUSE
    
    ZynqMp Efuse example exited successfully

Any insights into something that I may be missing here would be greatly appreciated. Thanks!

Take care.

  Jim

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
63 Views
Registered: ‎10-06-2016

Re: Unable to connect to ZCU9EG after programming RSA_EN efuse

Jump to solution

Hi jimg@crypto4a.com

When booting the device on Secure Mode (aka RSA_EN blown) the JTAG chain is disabled by default. You can open it if required afterwards from the FSBL and the process id documented on the AR#68391.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
2 Replies
Moderator
Moderator
64 Views
Registered: ‎10-06-2016

Re: Unable to connect to ZCU9EG after programming RSA_EN efuse

Jump to solution

Hi jimg@crypto4a.com

When booting the device on Secure Mode (aka RSA_EN blown) the JTAG chain is disabled by default. You can open it if required afterwards from the FSBL and the process id documented on the AR#68391.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Contributor
Contributor
52 Views
Registered: ‎05-11-2018

Re: Unable to connect to ZCU9EG after programming RSA_EN efuse

Jump to solution

Hello Ibai,

Thanks for the clarification and pointer. I had mistakenly believed that since JTAG_DISABLE wasn't being set, and the boot was successful that it would leave the JTAG interface intact.

Unfortunately, without a JTAG chain it's not clear to me how I can load a new FSBL with the required changes to unlock the JTAG chain (allow myself to introduce myself... ;->). We have no SD card slot or similar manual means of loading a new boot image into the board so I think there may be no way to recover from this state. Is there another mechanism that can be used to load an updated FSBL given a successful secure boot given the Vivado/SDK tools?

0 Kudos