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: 
Observer stevet
Observer
421 Views
Registered: ‎10-10-2018

modify next_config_addr when updating bitstream

Jump to solution

Hi

 

I am looking to use mutiboot with 4 different configurations, it it possible to update an image within the flas then modify the WBSTAR address (next_config_addr)?

I understant the WBSTAR is normall set in the .xdc file at time of jtag programming and the whole point point of multiboot is never to alter the golden image as this is know to work correctly. Just wondering if this can be done.

 

Thanks

 

Steve

1 Solution

Accepted Solutions
Moderator
Moderator
387 Views
Registered: ‎06-05-2013

Re: modify next_config_addr when updating bitstream

Jump to solution

Hi @stevet 

FIrst of all we don't recommend editing or chaging the bitstream after generation. There might be different results then what we expect. Refer to this AR https://www.xilinx.com/support/answers/58249.html 

WBSTAR is set in golden image and we don't expect that to change. There are few options which you can use here. 

-- Use ICAP for triggering the IPROG. Refer to the XAPP1296 https://www.xilinx.com/support/documentation/application_notes/xapp1296-multiboot-fallback-icap.pdf 

-- Next, you can add the new update image which has the 3rd image address (for example) 

Below is something I just ran and it works:

-- Golden

#BITSTREAM PROPERTIES REQUIRED FOR GOLDEN IMAGE:
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 1 [current_design]
set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]
set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 32'h00400000 [current_design]

 

-- 1st update image 

#BITSTREAM PROPERTIES REQUIRED FOR GOLDEN IMAGE:
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 1 [current_design]
set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]
set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 0x0600000 [current_design] # 00600000 is the location where 3rd image sits. 

So if you generate the complete mcs file with

golden + update 1 (which has next_config_addr to 600000 + update 2 (which can have another next_config_addr or it can be just without next_config_addr) 

If everything above works nicely then update2 will be loaded. Else you can expect a fallback and golden will be loaded. 

In general, you can jump from one image to another. Next to make system more robust you can look for timer barrier method suggested in XAPP1247 https://www.xilinx.com/support/documentation/application_notes/xapp1247-multiboot-spi.pdf 

Hope it helps!

Thanks

harshit 

PS: No device information was included in the post so I assumed you are using 7 or later series devices. 

 

 

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

View solution in original post

2 Replies
Moderator
Moderator
388 Views
Registered: ‎06-05-2013

Re: modify next_config_addr when updating bitstream

Jump to solution

Hi @stevet 

FIrst of all we don't recommend editing or chaging the bitstream after generation. There might be different results then what we expect. Refer to this AR https://www.xilinx.com/support/answers/58249.html 

WBSTAR is set in golden image and we don't expect that to change. There are few options which you can use here. 

-- Use ICAP for triggering the IPROG. Refer to the XAPP1296 https://www.xilinx.com/support/documentation/application_notes/xapp1296-multiboot-fallback-icap.pdf 

-- Next, you can add the new update image which has the 3rd image address (for example) 

Below is something I just ran and it works:

-- Golden

#BITSTREAM PROPERTIES REQUIRED FOR GOLDEN IMAGE:
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 1 [current_design]
set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]
set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 32'h00400000 [current_design]

 

-- 1st update image 

#BITSTREAM PROPERTIES REQUIRED FOR GOLDEN IMAGE:
set_property BITSTREAM.CONFIG.SPI_BUSWIDTH 1 [current_design]
set_property BITSTREAM.CONFIG.CONFIGFALLBACK ENABLE [current_design]
set_property BITSTREAM.CONFIG.NEXT_CONFIG_ADDR 0x0600000 [current_design] # 00600000 is the location where 3rd image sits. 

So if you generate the complete mcs file with

golden + update 1 (which has next_config_addr to 600000 + update 2 (which can have another next_config_addr or it can be just without next_config_addr) 

If everything above works nicely then update2 will be loaded. Else you can expect a fallback and golden will be loaded. 

In general, you can jump from one image to another. Next to make system more robust you can look for timer barrier method suggested in XAPP1247 https://www.xilinx.com/support/documentation/application_notes/xapp1247-multiboot-spi.pdf 

Hope it helps!

Thanks

harshit 

PS: No device information was included in the post so I assumed you are using 7 or later series devices. 

 

 

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

View solution in original post

Observer stevet
Observer
355 Views
Registered: ‎10-10-2018

Re: modify next_config_addr when updating bitstream

Jump to solution

Thanks for the information, it was very helpful. I ma right in thinking that if using the ICAP method the different versions need to be selected with the golden image via some switching statements in the golden image? and this same selection code can replicated in the updates to allow swapping of different versions.  The design will use GTX transcievers so if i go with this option i hope to switch the different versions with using this serial link.

 

The second method seems like a sgood option as a specific version can be loaded without no intervention from the user making a selection.

Yes, i'm using a Kintex 410T part.

 

Steve