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?
09-10-2019 08:19 AM
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?
01-10-2020 02:46 AM
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... ;->
10-13-2020 05:32 PM
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
10-27-2020 02:15 PM
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.
10-27-2020 02:19 PM
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...
10-28-2020 06:15 AM
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).