05-10-2018 09:10 AM
I have an encrypted (with key1) boot image (created using bootgen) consisting of FLSB, .bit, a couple .elf's and some binary data files - we'll call that Boot Image 1. The very last binary data file is another encrypted (with key2) boot image (created separately using bootgen) consisting of an FSBL, .bit and .elf - we'll call that Boot Image 2.
Boot Image 1 works fine on its own. Load it to QSPI, program BBRAM with key1 and you're up and running.
Boot Image 2 works fine on its own. Load it to QSPI, program BBRAM with key2 and you're up and running.
One of the .elf's in Boot Image 1 uses the methodology from xqspips_flash_polled_example to read the Boot Image 2 binary out of flash (it lives at 0xFC24AC40) and re-write it to 0xFC000000 so that it becomes the new boot image. One of the other .elf's in Boot Image 1 is responsible for getting key2 and writing it to BBRAM (using XAPP1223 methodology) and that works just fine, so the issue is not that I have the wrong key loaded.
So using XQspiPs_PolledTransfer's to read/write from QSPI, I take the image and move it to the base address in flash. I have confirmed that the image I'm copying matches the image bootgen created (by manually comparing the first and last 12 pages or so and some random ones in between). When I power off the board and power it on again, the new image won't load (no done light). If I manually program Boot Image 2 to the flash using the SDK, it starts working.
Am I missing some kind of command to the flash chip or some kind of data put into registers that the program_flash command takes care of, but my straight copy does not?
05-30-2018 07:44 PM
I suggest to use QEMU for this issue.
It's easy way to debug booting sequence.
Would you refer the following URLs ?
06-01-2018 10:11 AM
zynq-7000? A secure boot error should be pulsed out on INIT_B. That might give you a clue on what's going wrong.
See UG585 "6.3.12 BootROM Error Codes" page 198 for the decoding