Implementing a failsafe boot/firmware upgrade process

[skoehler]

First let's talk about the Zynq's normal (multi)boot process. Assume that the boot mode is QSPI. Here's how I think it works. Please correct me if I'm wrong:

1. The Boot ROM (code inside the Zynq CPU) is loaded and executed
   1. it searches the QSPI flash for a valid boot loader
   2. where it starts searching depends on some non-volatile multiboot register
   3. if a valid boot loader(typically the FSBL) is found, it's loaded and executed
2. The FSBL does the following
   1. ps7_init() is executed
   2. if the application image is valid:
      1. the bitstream is loaded into the PL
      2. the executable code is loaded into RAM and executed
   3. if the image is not vaid:
      1. the non-volatile multiboot register is modified
      2. a reset is performed

Is this correct so far?

Now I would like to have 2 application images in the QSPI, each with it's own FSBL. This seems possible.

1. The first application image is a minimal program using a minimal bitstream. It's purpose is solely to allow upgrades of the 2nd application image.
2. The second application image is the full-blown application using a different and bigger bitstream.

I have multiple questions:

• When the Boot ROM looks at the 32kb blocks, does it only search for valid headers? Or does it compute a checksum of the whole bootloader?
• When the two application images are written to the QSPI flash the first time, I think the 1st application image would be booted on first boot. However, after programming the flash, I want the 2nd application image to be booted. Can I somehow change the multiboot register to default to the 2nd application?

[denist]

I am assuming zynq-7000 without security involved (no encryption).

• Is this correct so far?
  • Yes

• When the Boot ROM looks at the 32kb blocks, does it only search for valid headers? Or does it compute a checksum of the whole bootloader?
• Only the header. For the full bootloader Xilinx recommend RSA but you can try the checksum=md5 to see if the fallback work with it.
• When the two application images are written to the QSPI flash the first time, I think the 1st application image would be booted on first boot. However, after programming the flash, I want the 2nd application image to be booted. Can I somehow change the multiboot register to default to the 2nd application?
• You can change the multiboot register value using the debugger and then issue a SRST.
• NOTE: after a POR the bootROM will always execute the first image. There’s no way to change that. That’s why we suggest to have your working image first and your golden image second.

[skoehler]

Yes, I am using a Zynq 7000. Sorry for not mentioning that in my first post. Also, I do not intend to use encryption.

So what happens if the BootROM finds a valid bootloader header, but the code of the bootloader is actually corrupt? As far as I understand, the BootROM will still load the bootloader into OCM (RAM) and try to execute it. The (corrupted) bootloader code could go into an infinite loop or put the CPU in some bad state. What happens then?

Also, as far as I understand, the FSBL includes the ps7_init() code. So any firmware update for my device would have to come with its own FSBL. This means that, during a firmware update, there is the potential to end up with a corrupted bootloader (valid header, but broken code) and the system will not boot. In particular the BootROM would not even look for the golden image, since it finds the (valid) header of the corrupted bootloader first.

How can I protect my system from this problem?

[denist]

For the upgrade, you should always have two images on your system. When you upgrade the first one, the suggestion is always to write the synchword in the boot header at the end, after a valid verification that the rest of the copy was successful.

Without the synchword, you will always be able to fallback to the second (golden) image.

For FSBL integrity, can you check the md5 option in bootgen. I know it works for MPSoC but I don't recall if that's supported for FSBL in zynq-7000. 

[skoehler]

I tried to enable md5 for the FSBL, but bootgen says that md5 is not supported for the bootloader on Zynq.

Writing the synchword in the end seems a good solution to minimize the chance of ending up with corrupted bootloader.

[denist]

I was afraid about that on md5 and zynq-7000. I think the only option is to use an RSA only flow to guarantee full integrity of the image.