UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Participant ddfst
Participant
926 Views
Registered: ‎07-02-2014

Multiboot: valid header required at NEXT_CONFIG_ADDR?

Jump to solution

Hello,

 

I've been experimenting with multiboot options and have observed the following - if I set next_config_addr option on my golden bitstream and there is no bitstream at all in the flash at specified address then FPGA (Artix-7) doesn't boot at all.

 

Doesn't that defy the point of being able to safely field-update the firmware? If there is a power loss event during or after first erase command (erasing the valid update bitstream header) and before corresponding program command it will brick the device. Or am I missing something in my observations?

0 Kudos
1 Solution

Accepted Solutions
Moderator
Moderator
1,225 Views
Registered: ‎06-05-2013

Re: Multiboot: valid header required at NEXT_CONFIG_ADDR?

Jump to solution

@ddfst
You can also refer XAPP1247 (https://www.xilinx.com/support/documentation/application_notes/xapp1247-multiboot-spi.pdf) which is a good source for understanding fallback. Check the timer barrier method(Page#15-16 of XAPP1247) which takes care of these scenarios. Where 2 timers are used. Golden Image, Timer1 & Timer 2 should be fixed. 

 

Timer1 sits near the start of update image and other timer sits towards the end of update image. Both are short times. First timer helps to sync the configuration logic to a known good SYNC word, . If it is not found then it will trigger the fallback. Second timer takes care of all other failures in the update image. i.e.  configuration logic does not see the end of startup to complete configuration. This also triggers the fallback. 

This method also eliminates the requirement to calculate timer value for the TIMER_CFG bitstream property. 

 Try to implement this method and share the update. 

Thanks

Harshit

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
4 Replies
Xilinx Employee
Xilinx Employee
896 Views
Registered: ‎01-10-2012

Re: Multiboot: valid header required at NEXT_CONFIG_ADDR?

Jump to solution

Hi @ddfst

 

Fallback is there for that very reason. Can you please go through UG470 in detail to better understand the capabilities of multi boot.

 

0 Kudos
Moderator
Moderator
1,226 Views
Registered: ‎06-05-2013

Re: Multiboot: valid header required at NEXT_CONFIG_ADDR?

Jump to solution

@ddfst
You can also refer XAPP1247 (https://www.xilinx.com/support/documentation/application_notes/xapp1247-multiboot-spi.pdf) which is a good source for understanding fallback. Check the timer barrier method(Page#15-16 of XAPP1247) which takes care of these scenarios. Where 2 timers are used. Golden Image, Timer1 & Timer 2 should be fixed. 

 

Timer1 sits near the start of update image and other timer sits towards the end of update image. Both are short times. First timer helps to sync the configuration logic to a known good SYNC word, . If it is not found then it will trigger the fallback. Second timer takes care of all other failures in the update image. i.e.  configuration logic does not see the end of startup to complete configuration. This also triggers the fallback. 

This method also eliminates the requirement to calculate timer value for the TIMER_CFG bitstream property. 

 Try to implement this method and share the update. 

Thanks

Harshit

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Participant ddfst
Participant
874 Views
Registered: ‎07-02-2014

Re: Multiboot: valid header required at NEXT_CONFIG_ADDR?

Jump to solution

@harshit

 

Thank you for pointing out the method. But what if update image size increases after sequential updates (with bitstream comression)? As far as I understand Timer2 image (that is not supposed to be rewritten on field-update) must be stored right after update image, and the provided tcl script maps out the flash just so.

 

For now just setting the timeout value to several times the normal configuration time assuming a 380 kHz internal clock seems to be the easiest and most robust solution. I can afford waiting for some extra seconds should the fail occur

0 Kudos
Moderator
Moderator
838 Views
Registered: ‎06-05-2013

Re: Multiboot: valid header required at NEXT_CONFIG_ADDR?

Jump to solution
Yes! Location for golden, timer1 & Timer2 is fixed. If setting the WDT meets your requirement then use that method.

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