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: 
Highlighted
Adventurer
Adventurer
2,264 Views
Registered: ‎11-26-2016

Force Golden Bitstream Configuration

Jump to solution

Hi,

 

In case of a production design which has design flaws leading to a broken update mechanism it would be required to force the FPGA to boot from the golden bitstream design, even if the production design is "ok".

 

According to UG570 the IPROG command embedded in the bitstream can be disabled by setting the BITSTREAM.CONFIG.NEXT_CONFIG_REBOOT DISABLE property.
However, how can I bypass the IPROG command embedded in the Golden Bitstream?

 

Regards,
so-lli1

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
2,740 Views
Registered: ‎01-10-2012

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @so-lli1

 

The suggestion i mentioned does not make a blind jump as in your current case(golden image). You cant write to BOOTSTS but you can read the values to know if IPROG was issued previously, there are 2 sets of  status stored, x_1 & x_0, so you can read the BOOTSTS before making the jump decision  Also note that the BOOTSTS values does not get cleared unless PROG_B or POR is asserted so issuing IPROG via ICAP will retain the status register values or should i say get updated based on the outcome of the config.

 

There can also be other alternative.. but i guess this is straight forward.

10 Replies
Xilinx Employee
Xilinx Employee
2,222 Views
Registered: ‎01-10-2012

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @so-lli1

 

Not sure i understand your concern correctly.

 

In a typical multi boot application, there will be two images(bitstream) so in your case say you have 

2 images AA(Golden) & B (Multiboot). Assume you would normally use B image (boot from A and jump to B via IPROG)

Now anytime you want to update image B, u can do so and in case you fail while updating the image B, then you can safely

load the image A(golden) as fallback will be able to support loading the image from A.

 

Our UG and Xapp's have a very detailed explanation on how multiboot works, so might want to go through them to clearly understand the capability.

 

There is a good post by  sdowneyLGS

https://forums.xilinx.com/t5/Configuration/7-series-BPI-Flash-Remote-Update-Configuration-Failing-to/td-p/825111

 

 

0 Kudos
Adventurer
Adventurer
2,210 Views
Registered: ‎11-26-2016

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @gurupra,

 

I am aware of ug570, xapp1257 and the update process in general.

However, lets consider the situation that the image B (Multiboot) is at the limit regarding logic utilization and I don't want to implement the update logic (writing to the external flash) in both bitstreams (A and B). Then it would be nice if you could just force the FPGA to boot A (Golden) from within B and perform the update of B from there.

 

Another use case would be if the update process of B is not working, but the design was still released to customers. Than your product is stuck at B, even if A would be able to fix the issue by updating B...

 

Therefore, I would like to jump from image B to image A, but setting the WBSTAR address and issuing IPROG won't work (I guess), since the embedded IPROG in A will jump to B again if there was no error in BOOTSTS...

 

Is there a (clean) way to do this?

0 Kudos
Xilinx Employee
Xilinx Employee
2,204 Views
Registered: ‎01-10-2012

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @so-lli1

 

So if I were to summarize your requirement, you want to have control of where u want to  jump(IPROG)  and when you want to jump.

The best way is to use ICAP in your design and decide where and when you want to jump.

This Xapp might also help

https://www.xilinx.com/support/documentation/application_notes/xapp1296-multiboot-fallback-icap.pdf

 

0 Kudos
Adventurer
Adventurer
2,079 Views
Registered: ‎11-26-2016

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @gurupra

 

I thought this is of the table, but the customer now really wants this feature...

 

I am aware of ICAP and it is used within the design since the beginning to re-trigger FPGA Configuration after a Flash Update. However, I want it to be able to load Image A (golden). As far as I can tell the Bitstream header of the Image A (Golden) at the beginning of the Flash (Addr 0x00) checks for Boot Errors (IDCODE error, CRC error, WDT error,...) and if any occured, Image A is loaded, otherwise IPROG is triggered to jump to B (Multiboot). 

 

How can I force it to stay within Image A (Golden) even if Image B (Multiboot) is NOT corrupted?

0 Kudos
Xilinx Employee
Xilinx Employee
2,069 Views
Registered: ‎01-10-2012

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @so-lli1

 

If ICAP is used in the design and the jump is controlled from the design, sorry to say iam unable to understand your concern here ?

Can you please elaborate in detail ?

0 Kudos
Adventurer
Adventurer
2,067 Views
Registered: ‎11-26-2016

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @gurupra

 

First of all, thank you for your quick reply.

 

A typical flow would look like this:

 

1. FPGA boot up (Power UP)

2. FPGA starts to read Image A (Golden) at Flash location 0x00
3. Because WBSTAR is set to 0x10000 (location of B in flash) within Image A (Golden), the Configuration logic will jump to 0x10000 in the Flash to boot B (Production) from there.

4. Now the Image B (Production) is loaded and can be used

5. Within B (Production) we set WBSTAR to 0x00 to jump back to A (Golden) and trigger the IPROG command using ICAP

6. Which design is loaded in the FPGA now? A(Golden) or B (Production) and why?

0 Kudos
Xilinx Employee
Xilinx Employee
2,055 Views
Registered: ‎01-10-2012

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @so-lli1

 

Thanks for the elaboration, so your design is mix of BITSTREAM based( iprog embedded in bitstream) jump and design based jump ( using ICAP). Let me answer to your Q first.

 

The step 6 you mentioned will again load B(production). Why ? Because remember when you jumped back to A its not because of Fallback so, image A will use the WBSTAR settings and jump to B.

 

So what is the solution?

Use same ICAP approach to image A(golden) that is let it load first and then you jump to B ( to track you can use say BOOTSTS data), from  B back to A also via ICAP, again you can look into BOOTSTS and decide that you need not have to do the jump when in Back to A.

 

0 Kudos
Adventurer
Adventurer
2,041 Views
Registered: ‎11-26-2016

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @gurupra

 

Very glad to hear we are on the same page now.

 


 

The step 6 you mentioned will again load B(production). Why ? Because remember when you jumped back to A its not because of Fallback so, image A will use the WBSTAR settings and jump to B.

 

 


Correct.

 


 

So what is the solution?

Use same ICAP approach to image A(golden) that is let it load first and then you jump to B ( to track you can use say BOOTSTS data), from  B back to A also via ICAP, again you can look into BOOTSTS and decide that you need not have to do the jump when in Back to A.

 


This makes no sense to me.
If my criteria for a jump from A(golden) to B(production) happens according to BOOTSTS, what is the difference between the current approach and the one you are suggesting?

According to UG570, Table 9-19 it is not possible to write to BOOTSTS, so how should I inform A(golden) not to jump?

0 Kudos
Xilinx Employee
Xilinx Employee
2,741 Views
Registered: ‎01-10-2012

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @so-lli1

 

The suggestion i mentioned does not make a blind jump as in your current case(golden image). You cant write to BOOTSTS but you can read the values to know if IPROG was issued previously, there are 2 sets of  status stored, x_1 & x_0, so you can read the BOOTSTS before making the jump decision  Also note that the BOOTSTS values does not get cleared unless PROG_B or POR is asserted so issuing IPROG via ICAP will retain the status register values or should i say get updated based on the outcome of the config.

 

There can also be other alternative.. but i guess this is straight forward.

Adventurer
Adventurer
1,087 Views
Registered: ‎11-26-2016

Re: Force Golden Bitstream Configuration

Jump to solution

Hi @gurupra

 

Thank you for the clearification. Now I understand. However, in my specific case (due to several reasons) I was not able to follow your approach. The final solution was to set the Configuration WDT TIMER register in TIMER_CFG_MON Mode to a very low value and reconfiguring the FPAG using the WBSTAR register through Configuration Packets (ug570, p158). Therefore you always end up in the Golden Bitstream. Within its header, the TIMER register is reset to the desired value for the next run.

 

Thank you very much for your help. Although your suggesting was not the right solution for me, I still think this is a nice way to deal with this problem.