cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer
Observer
976 Views
Registered: ‎05-25-2018

Implementing a failsafe boot/firmware upgrade process

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?
0 Kudos
5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
927 Views
Registered: ‎10-11-2011

Re: Implementing a failsafe boot/firmware upgrade process

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.
-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
899 Views
Registered: ‎05-25-2018

Re: Implementing a failsafe boot/firmware upgrade process

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?

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
879 Views
Registered: ‎10-11-2011

Re: Implementing a failsafe boot/firmware upgrade process

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. 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Observer
Observer
875 Views
Registered: ‎05-25-2018

Re: Implementing a failsafe boot/firmware upgrade process

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.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
860 Views
Registered: ‎10-11-2011

Re: Implementing a failsafe boot/firmware upgrade process

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.

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos