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