cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jimg@crypto4a.com
Adventurer
Adventurer
2,008 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

1 Solution

Accepted Solutions
ibaie
Xilinx Employee
Xilinx Employee
1,967 Views
Registered: ‎10-06-2016

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.

View solution in original post

9 Replies
ibaie
Xilinx Employee
Xilinx Employee
1,968 Views
Registered: ‎10-06-2016

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.

View solution in original post

jimg@crypto4a.com
Adventurer
Adventurer
1,956 Views
Registered: ‎05-11-2018

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?

m.asy
Visitor
Visitor
1,617 Views
Registered: ‎06-17-2019

Hello,

I see that in a subsequent post you've managed to overcome this problem, could you tell us how you did it exactly, as I'm stuck in this problem right now, burned the RSA_EN fuse and now the encrypted/authentication hello world program i used as a test is working but I no longer have access to jtag, and thus this board is rendered useless for the moment. did you manage to get an SD card boot working?

Thank you.

jimg@crypto4a.com
Adventurer
Adventurer
1,382 Views
Registered: ‎05-11-2018

Hello,

Our solution was to use a clip to connect to the QSPI package on the board and program an updated image (which includes the JTAG unlock commands) manually via a SPI programming device (we're using the Dediprog SF600plus). Not a great solution, but it worked and now we've added the JTAG unlock commands to our standard FSBL image so we shouldn't need to use this handraulic approach in the future.  Of course, having said that I'm sure my next mistake is right around the corner... ;->

Take care.

Jim

LearningXilinx
Observer
Observer
901 Views
Registered: ‎09-03-2020

Hi,

Not sure why RSA_EN would disable the JTAG since the JTAG has its own eFUSE....

In any case, I have the same problem in where I can't connect to the FLASH via JTAG, to burn new images.

I CAN however, still boot different signed and encrypted images from the SD Card.

I replace added to my FSBL the code from AR# 68391 in stage stage 4 (XFSBL_STAGE4) in the main of xfsbl_main.c and with any extra debuf print statement to see when it started those lines and ended. All looked good.

 

However, I am still unable to connect the FPGA:

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

Retrieving Flash info...

ERROR: Flash Operation Failed

 

 

Please help.

 

0 Kudos
jimg@crypto4a.com
Adventurer
Adventurer
824 Views
Registered: ‎05-11-2018

Are you trying to connect using the SDK or Vivado's Hardware Manager?  If one isn't working then try to use the other to see if you can interrogate the JTAG chain to better understand what's going on.

I'm assuming you haven't burned the JTAG disable eFuse either.

Good luck!

  Jim

LearningXilinx
Observer
Observer
820 Views
Registered: ‎09-03-2020

According to Xilinx, enev if you don't burn the disable JTAG eFUSE, you can no longer boot into JTAG mode (i.e. use the flash util).

You can however, enable the JTAG during the executing image, for that run only...

0 Kudos
jimg@crypto4a.com
Adventurer
Adventurer
781 Views
Registered: ‎05-11-2018

Yep. I had run into exactly this issue and the way it was explained to me, by someone on these forums, was that the Xilinx flash programing utility triggers a reset of the device, which, because the device is in a secure boot configuration, locks down the JTAG path again, thereby blocking this as a viable means to program the device.

A couple of options for getting around this issue are to (1) get an external flash programmer (e.g., Dediprog) and use it to manually program the QSPI device, or (2) write some code that allows you to program the QSPI using the PS complex and then run it either via a boot from the SD card, or via the SDK debugger over JTAG which should still work after a successful secure boot.

The default lockdown of the JTAG path and the detrimental side effects it has on the typical Xilinx device programming functions, was definitely an unwelcome surprise when first experimenting with secure boot. It makes me wish they had made the JTAG enabled path the default, and then provide a means to disable the path via software in the FSBL (i.e., the exact opposite of what they ended up implementing).

Good luck!

  Jim

LearningXilinx
Observer
Observer
760 Views
Registered: ‎09-03-2020

Thanks for the info Jim,

 

It’s also amazing to see someone at your level on here and doing this type of work.

0 Kudos