cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
9,107 Views
Registered: ‎04-06-2012

Spartan 6 multiboot - Fallback does NOT work

Jump to solution

I think my issue is related to the header file. I followed the instructions given by siktap in this thread: https://forums.xilinx.com/t5/Configuration/Spartan-6-Fallback-Multiboot-Configuration/m-p/438250/highlight/true#M225

 

I have a golden image where leds blink quickly.

I have a multiboot image where leds blink slowly.

Both images have been tested stand-alone and work as expected.

 

On power-up, the multiboot image loads properly. However when I corrupt the multiboot image in the flash memory, the golden image does NOT get loaded; nothing happens and the fpga does not boot up. It seems like I might be missing an important value in one of the registers?

 

Here is the content of my boot_header.hex:

 

FFFFFFFF    //  DUMMYWORD,  DUMMYWORD
AA995566     //  SYNCWORD
31E1FFFF 
32610000     //  3261=GENERAL1 0x0000=address[15:0] MultiBoot image location
32810340    //  3281=GENERAL2 0x03=SPIx1 read command, 0x40=address[23:16] MultiBoot image address
32A10000 //  32A1=GENERAL3 0x0000=address[15:0] Golden image address location
32C10301 //  32C1=GENERAL4 0x03=SPIx1 read command, 0x01=address[23:16] of Golden image address
32E10000 
30A10000
33012100   // IS THIS SET PROPERLY?
3201001F
30A1000E 
20002000    //  NOOP, NOOP
20002000    //  NOOP, NOOP

 

Here is how I generate the .mcs for my header:

promgen -w -p mcs -r boot_header_only.hex -o boot_header_only.mcs

 

Here is how I generate the .mcs for the two images:

promgen -w -p mcs -spi -s 16384 -u 010000 goldenFastBlink.bit -u 400000 MultibootSlowBlink.bit -o image_no_header.mcs

 

And then I add the content of boot_header_only.mcs in the beginning of image_no_header.mcs. I know for a fact that this (at least) partially works because my image at 0x004000000 gets loaded properly. If I try to corrupt a sector in the multiboot image region (let's say 0x00410000), the fallback mechanism does NOT work and NOTHING happens.

 

Is this related to my header file? What am I doing wrong?

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
16,840 Views
Registered: ‎04-06-2012

Re: Spartan 6 multiboot - Fallback does NOT work

Jump to solution

Hi, I figured out what was wrong with my design. I had the '-g reset_on_err:yes' option for both the golden and multiboot images since it was mentionned in the thread I linked, so this option wasn't the issue. However, one very important information was missing from that thread.

 

My problem is that the multiboot image was being compiled with next_config_register_write:enable parameter, which is set by default. In a workflow similar to the reference thread I linked, the manually compiled header contains the important addresses. These addresses are neither found in the golden nor the multiboot images. For this reason, next_config_register_write MUST be set to next_config_register_write:disable for the multiboot image, otherwise the system flow is as follows:

 

  1. The header commands are executed and the multiboot and golden start addresses are set in the proper registers
  2. The multiboot address is loaded. However since the program is compiled with next_config_register_write:enable, the values for the golden and multiboot addresses that were set at step number 1 get erased and replaced by what I assume are default values (0x000000 everywhere?!).
  3. Assuming the multiboot image gets corrupted on purpose, the system is unable to fallback to the golden image because the address registers have been modified when the corrupted multiboot image was read.

I'm not yet sure if next_config_register_write must be set to enable/disable or if it is irrelevant for my project. I believe it is irrelevant since the golden image only exists to run a minimalist server that will enable me to write a new multiboot image to the memory. After doing so, the system will be rebooted anyway and the header in the flash should be read again, which will load the multiboot image. I believe it would be important if I planned to use icap to handle the signals directly to load the multiboot image without rebooting.

 

View solution in original post

5 Replies
Highlighted
Adventurer
Adventurer
9,098 Views
Registered: ‎04-06-2012

Re: Spartan 6 multiboot - Fallback does NOT work

Jump to solution

Here is the status registers content (obtained using Impact) after I edit the release code memory range:

 

Boundary-scan chain validated successfully.
'1': Reading bootsts register contents...
[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         1
[1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         1
[2] RESERVED                                                               :         0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR                                  :         0
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR                                  :         0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                      :         1
[6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         1
[7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         1
[8] RESERVED                                                               :         0
[9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR                                  :         1
[10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR                                 :         0
[11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                     :         0
[12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         1
[13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         1
[14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         1
'1': Reading status register contents...
[0] CRC ERROR                                                              :         0
[1] IDCODE ERROR                                                           :         0
[2] DCM LOCK STATUS                                                        :         1
[3] GTS_CFG_B STATUS                                                       :         0
[4] GWE STATUS                                                             :         0
[5] GHIGH STATUS                                                           :         0
[6] DECRYPTION ERROR                                                       :         0
[7] DECRYPTOR ENABLE                                                       :         0
[8] HSWAPEN PIN                                                            :         1
[9] MODE PIN M[0]                                                          :         1
[10] MODE PIN M[1]                                                         :         0
[11] RESERVED                                                              :         0
[12] INIT_B PIN                                                            :         1
[13] DONE PIN                                                              :         0
[14] SUSPEND STATUS                                                        :         0
[15] FALLBACK STATUS                                                       :         0

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,806 Views
Registered: ‎09-05-2007

Re: Spartan 6 multiboot - Fallback does NOT work

Jump to solution

When preparing your BIT files did you set the ‘-g reset_on_err:yes’ option? Alternatively, did you set the RESET_ON_ERR bit in the COR2 register as part of your ICAP MultiBoot sequence?

 

It is also typical to set the ‘-g next_config_register_write:disable’ option so that contents of the GENERAL registers remain untouched during the reboot.

 

Ken Chapman
Principal Engineer, Xilinx UK
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
8,807 Views
Registered: ‎09-05-2007

Re: Spartan 6 multiboot - Fallback does NOT work

Jump to solution

Did you set the '-g reset_on_err:yes' option when generating your BIT files?

Ken Chapman
Principal Engineer, Xilinx UK
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
9,020 Views
Registered: ‎09-05-2007

Re: Spartan 6 multiboot - Fallback does NOT work

Jump to solution

Did you set the '-g reset_on_err:yes' option when generating your BIT files?

Ken Chapman
Principal Engineer, Xilinx UK
0 Kudos
Highlighted
Adventurer
Adventurer
16,841 Views
Registered: ‎04-06-2012

Re: Spartan 6 multiboot - Fallback does NOT work

Jump to solution

Hi, I figured out what was wrong with my design. I had the '-g reset_on_err:yes' option for both the golden and multiboot images since it was mentionned in the thread I linked, so this option wasn't the issue. However, one very important information was missing from that thread.

 

My problem is that the multiboot image was being compiled with next_config_register_write:enable parameter, which is set by default. In a workflow similar to the reference thread I linked, the manually compiled header contains the important addresses. These addresses are neither found in the golden nor the multiboot images. For this reason, next_config_register_write MUST be set to next_config_register_write:disable for the multiboot image, otherwise the system flow is as follows:

 

  1. The header commands are executed and the multiboot and golden start addresses are set in the proper registers
  2. The multiboot address is loaded. However since the program is compiled with next_config_register_write:enable, the values for the golden and multiboot addresses that were set at step number 1 get erased and replaced by what I assume are default values (0x000000 everywhere?!).
  3. Assuming the multiboot image gets corrupted on purpose, the system is unable to fallback to the golden image because the address registers have been modified when the corrupted multiboot image was read.

I'm not yet sure if next_config_register_write must be set to enable/disable or if it is irrelevant for my project. I believe it is irrelevant since the golden image only exists to run a minimalist server that will enable me to write a new multiboot image to the memory. After doing so, the system will be rebooted anyway and the header in the flash should be read again, which will load the multiboot image. I believe it would be important if I planned to use icap to handle the signals directly to load the multiboot image without rebooting.

 

View solution in original post