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!
03-06-2019 08:07 AM
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
03-08-2019 12:20 PM
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.
03-08-2019 12:20 PM
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.
03-12-2019 07:49 AM
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