cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
yfortin
Observer
Observer
1,528 Views
Registered: ‎05-25-2015

Petalinux Golden Image for Zynq-7000

Jump to solution

Hi,

 

I am trying to understand how I can include a fallback (or golden) Petalinux image on my QSPI flash for Zynq-7000. This is to make sure that the system will keep working in the case where an error occurs during the update of the main image and it gets corrupted.

 

I have read some docs (UG821, xapp1175, etc) and web articles about multiboot and fallback images. My understanding is that the golden image should be placed in the QSPI flash above the update image. If the image at 0x00000000 turns out to be invalid, BootROM will automatically search for a valid header at every 32KB offset and eventually find and boot the golden image. I am using the non-secure boot mode for now and I have Vivado/Petalinux 2018.2.

 

That sounds easy enough for the case when all of the image is contained within a single .BIN file for bare metal application, but I’m having trouble finding the right way to configure Petalinux images (BOOT.BIN and image.ub) to get this to work.

 

I have attempted to create two sets of three partitions (for update and golden images) on the QSPI flash with arrangement as shown below. Note that the golden image is voluntarily smaller than the update image.

 

Primary Flash (ps7_qspi_0)  --->

[ ] Advanced Flash Auto Configuration

    *** partition 0 ****

(update_boot) name

(0x800000) size

    *** partition 1 ****

(update_bootenv) name

(0x20000) size

    *** partition 2 ****

(update_kernel) name

(0xA80000) size

    *** partition 3 ****

 (golden_boot) name

(0x700000) size

    *** partition 4 ****

(golden_bootenv) name

(0x20000) size

    *** partition 5 ****

(golden_kernel) name

(0x640000) size

    *** partition 6 ****

(spare) name

(0x0) size

    *** partition 7 ****

() name

 

This I think is similar to Figure 3-7 (Non-Secure Fallback Image Format) from UG821.

 

The flash size is 32Mbit, so these partitions fill the entire space between 0x00000000 and 0x02000000. I have used petalinux-config ---> Flash Settings to configure the partitions as shown above, and also set each component to their corresponding partition name;

Advanced bootable images storage Settings ---> boot image settings ---> (golden_boot) flash partition name

Advanced bootable images storage Settings ---> u-boot env partition settings ---> (golden_boot_env) flash partition name

Advanced bootable images storage Settings ---> kernel image settings ---> (golden_kernel) flash partition name

 

After compiling everything, I have erased the whole flash and programmed BOOT.BIN (file size 6.5MB) at offset 0x12A0000 (which is the start of “golden_boot” partition) and image.ub (file size 5.7MB) to offset 0x19C0000 (which is the start of “golden_kernel” partition).

 

With the flash being blank at the bottom, I was expecting BootROM to search for a valid header all the way to 0x12A0000 and boot from there, but that did not happen. Nothing happened. I know for sure that BOOT.BIN and image.ub are valid, because everything works fine if I create a partition set with only golden_boot, golden_bootenv and golden_kernel, starting at offset zero.

 

  It appears I do not have the correct configuration to boot Petalinux from an offset other than 0x0. Can anyone explain what configuration I need for my golden Petalinux image? Is there a tutorial on that specific case?

 

  Thanks,

  Yannick.

0 Kudos
Reply
1 Solution

Accepted Solutions
yfortin
Observer
Observer
1,423 Views
Registered: ‎05-25-2015

Hi Shaun,

 

  Thank you for the recommendations.

 

  I did not yet succeed in implementing multiboot, but I understand now what was wrong with the configuration described in my original post;

 

  My flash was completely erased and I wrote BOOT.BIN at offset 0x012A0000, hoping that BootROM would discover the header during its header search process. However I just found out in UG585 that the search range for a Quad-SPI flash 4-bit device is limited to the first 16MB (section "BootROM Header Search Stepping and Range"), which means address 0x012A0000 is out of range.

 

  I tested with lower addresses and I see that FSBL is discovered correctly by BootROM as long as I write my image to offset 0x00FE0000 or lower.

 

  I also spent some time reading and analyzing the FSBL code, and I have a better idea of the work that needs to be done now. I'll keep working on it...

 

  Thanks,

  Yannick.

View solution in original post

0 Kudos
Reply
2 Replies
shaunpur
Xilinx Employee
Xilinx Employee
1,466 Views
Registered: ‎10-16-2015

Hi Yannick,

 

Have you seen the following wiki page on this topic?

Some changes may also be needed to the default u-boot scripts.  The wiki page doesn't cover this, but I've posted some info on this for a similar question that came up recently:

 

https://forums.xilinx.com/t5/Embedded-Boot-and-Configuration/Wanted-Zynq-QSPI-MultiBoot-example/td-p/885889

 

If neither of the above help, I suggest enabling debug print-outs for all the FSBLs.  If the images are aligned correctly, you should at least see the golden FSBL attempt to boot and see how far it gets.

 

Regards,

Shaun

0 Kudos
Reply
yfortin
Observer
Observer
1,424 Views
Registered: ‎05-25-2015

Hi Shaun,

 

  Thank you for the recommendations.

 

  I did not yet succeed in implementing multiboot, but I understand now what was wrong with the configuration described in my original post;

 

  My flash was completely erased and I wrote BOOT.BIN at offset 0x012A0000, hoping that BootROM would discover the header during its header search process. However I just found out in UG585 that the search range for a Quad-SPI flash 4-bit device is limited to the first 16MB (section "BootROM Header Search Stepping and Range"), which means address 0x012A0000 is out of range.

 

  I tested with lower addresses and I see that FSBL is discovered correctly by BootROM as long as I write my image to offset 0x00FE0000 or lower.

 

  I also spent some time reading and analyzing the FSBL code, and I have a better idea of the work that needs to be done now. I'll keep working on it...

 

  Thanks,

  Yannick.

View solution in original post

0 Kudos
Reply