02-11-2019 11:46 AM
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!
02-12-2019 02:23 AM
02-12-2019 02:23 AM
02-12-2019 03:32 AM
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?