06-10-2019 06:42 AM
I'm using a partname xczu7eg (Ultra Scale plus) and I have just generated an encrypted BOOT.bin by running the tcl script:
exec bootgen -arch zynqmp -image ./Hercules_2.bif -w -o ./BOOT.bin -encrypt bbram -p xczu7eg
where the bif file is as follows:
[bootloader, encryption=aes] Hercules_2_FSBL.elf
[destination_device = pl, encryption=aes] Hercules2_top.bit
[destination_cpu = a53-0, encryption=aes] Hercules_2.elf
Well, I'm trying to write the bbram.nky by using Vivado Hardware Manager via JTAG connection, but I can't find the corresponding menu (Program BBR Key).
Thanks in advance.
06-11-2019 08:15 AM
To program the keys (BBRAM and eFuse) in Zynq UltraScale+ refer to XAPP 1319. The programming is done via the XilSkey library.
06-12-2019 12:42 AM
thanks for your response.
The chapter "Programming the AES Key in BBRAM" in XAPP1319 (v1.0) suggests to use the Hardware platform ZCU102_hw_platform(pre-defined).
Is it strictly necessary to use that platform? Or it is possible to use the hw_platform of the project?
06-12-2019 05:54 AM
XAPP1319 uses the ZCU102 as a demonstration platform. You should be using the HDF that represents your specific hardware since you are using a custom board.
06-13-2019 01:53 AM
thanks for you response.
According to the XAPP1319, the unique way to load the aes key into the BBRAM is to create a specific BOOT.bin, save it on SD and re-boot the board from the SD itself.
Well, I'm in a situation in which the board booting from SD is not an easy operation, so I'm wondering if there is an alternative way to upload the aes key into the BBRAM.
06-13-2019 05:54 AM
You can put the boot.bin into any flash boot - QSPI, SD, eMMC, etc.
06-13-2019 08:58 AM
thanks. I've tried by rpogramming BOOT.bin into QSPI and it works as you say: at the reboot the QSPI content is loaded into BBRAM.
Well, i'm wondering if there is a way to create a unique BOOT.bin containig both key and project in order to avoid the two uploads (KEY and PROJECT).
06-14-2019 05:45 AM
If a key does not exist, it will be generated in the first run, the boot.bin will be generated witht that key in the second run. There is no means to generate a key and build a boot.bin with that new key in one pass.
06-24-2019 08:29 AM
Glena, I have noticed that if I use the JTAG to load into QSPI the BOOT.bin for the key and then the BOOT.bin for the encrypted project, no other encrypted projects can be loaded into QSPI via JTAG. The unique way it seems to use the SD card. Can you confirm this behavior? In the case the SD slot is broken, there is an alternative to the SD?
06-24-2019 08:44 AM
When you boot secured, JTAG is disabled. This is a security feature, and the board is working as designed. If you want to have JTAG accessibility in secure boot, refer to AR6839
06-25-2019 12:31 AM
Glena, thanks a lot for your answers. Let me ask another question. Is there a way to write in QSPI more than one BOOT.bin (at different addresses) and to decide what of the BOOTs to load at the board rebooting?
06-25-2019 03:22 AM
06-25-2019 06:19 AM
In many ways it depends on when you want to have JTAG access restored. I have typically re-enable JTAG in the XFsbl_HookBeforeHandoff section in xfsbl_hooks.c
06-25-2019 06:26 AM
06-25-2019 07:12 AM
If you are booting encrypted, JTAG is disabled by the BootROM. To re-enable JTAG follow AR6839
06-27-2019 05:02 AM
06-27-2019 05:26 AM
The modified FSBL needs to be in the boot.bin. Is that where you are placing it?
06-27-2019 05:34 AM - edited 06-27-2019 05:55 AM
The bif file to generate the new BOOT.bin is the following:
[destination_device = pl] ./Hercules_top.sdk/Hercules_2_hw/Hercules2_top.bit
[destination_cpu = a53-0] ./Hercules_top.sdk/Hercules_2/Debug/Hercules_2.elf
so, the modified FSBL is the bootloader.
The new BOOT.bin is generated with the following command:
bootgen -arch zynqmp -image Hercules_2.bif -w -o ./BOOT.bin
Here the message from SDK Program Flash:
cmd /C program_flash -f \
C:\Users\ccastell\Desktop\Hercules_top.sdk\BOOT_newscript_reJTAG_3.bin -offset 0 \
-flash_type qspi_dual_parallel -fsbl \
-cable type xilinx_tcf url TCP:127.0.0.1:3121
****** Xilinx Program Flash
****** Program Flash v2018.2 (64-bit)
**** SW Build 2258646 on Thu Jun 14 20:03:12 MDT 2018
** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.
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-HS3-210299A56673
Device 0: jsn-JTAG-HS3-210299A56673-14730093-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
06-27-2019 06:11 AM
I've used it like this:
u32 XFsbl_HookBeforeHandoff(u32 EarlyHandoff)
u32 Status = XFSBL_SUCCESS;
* Add the code here
You could try moving the code to XFsbl_HookAfterBSDownload or at the start of your application.
06-27-2019 06:31 AM
06-27-2019 06:58 AM
booting in JTAG Boot Mode is always an option.
06-28-2019 12:04 AM
Could you provide detailed steps for JTAG booting in Ultra Scale plus? Which tool should be used?
06-28-2019 05:36 AM - edited 06-28-2019 05:39 AM
For the Zynq UltraScale +, set the boot mode pins to jtag boot mode and cycle pos_por_b
07-01-2019 08:39 AM
I need more information. For example, where I must put BOOT.bin and FSBL? I need SDK?
Sorry, but I need more information because what I have found in the web is not clear to me.
07-01-2019 10:17 AM
UG1209 is a good resource.
When you boot in JTAG Boot mode, there is nothing loaded. You can load your files over JTAG, program the QSPI, etc. from there. Boot.bin contains the FSBL, I'm not sure why you mention those separately. You can use the SDK GUI or XSCT in command-line form.
07-02-2019 12:26 AM
for me BOOT.bin and FSBL are separated becasue SDK Program Flash requires two files: see attached image.
Let me try to list the steps for JTAG boot:
1) set switches on board for JTAG booting
2) Press PWR button board for re-booting (nothing is loaded)
3) Use SDK (like in the attached image) to program QSPI: in this case JTAG is not blocked!
Are these steps correct?
In order to avoid a stall situation, I wait for your confirmation before trying these steps.
07-02-2019 05:54 AM
Boot.bin must ALWAYS contain an fsbl, optionally it can contain your bitstream and application - on most cases it will contain those as well. The FSBL used by program is a guide file only used to set up the tool, refer to AR 70148
07-02-2019 06:13 AM
that is in the docs, please read them
set the mode switch to jtag and toggle ps_por_b or power cycle the board.