Xilinx 7 Series FPGA
Zynq-7000
Xilinx AR5774 deals with the problem and provides some workarounds.
| # | Solution | Good | Bad |
|---|---|---|---|
| 0 | Use single 16MByte flash | There are no issues. Can be implemented as assembly option, no PCB change needed, only BOM change. | SPI Flash is limited to 16MByte. |
| 1 | Use stacked 16MByte flashes | Only 1 extra pin needed from MIO, 32MB can be safely accessed at full speed. | Hardware (PCB) change, more space needed on PCB. |
| 2 | Use 16MB flash, parallel configuration | ||
| 3 | Limit the access to lower 16Mbytes | No change of code or hardware | Only 16MBytes can be accessed safely, may have to take special actions to actually limit the access to lower 16Mbyte |
| 4 | Preload everything above 16Mbytes in FSBL, limit access to lower 16Mbytes after FSBL handout | Only FSBL changes needed, use of 32 bit addressing SPIx1 commands and not EAR register. | Access above 16MByte should not be performed from SSBL or application code, may have to take special actions to actually limit the access to lower 16Mbyte |
| 5 | Rewrite FSBL, SSBL and OS/RTOS Drivers to avoid using EAR register and "legacy mode" | Truly safe solution, no hardware changes no restriction on SPI Flash Partitioning. Very good solution for bare metal applications. | A lot of Code and drivers to modify, the patches have to be applied again after each software release. Access to SPI Flash above 16Mbyte must be done using SPIx1 mode command set, when using the speed optimized code the performance penalty is not that bad. |
| 6 | Place "reboot.bin" at 16MByte boundary | No change of code of hardware. | 256KByte sector at 16Mbyte offset in SPI Flash is "reserved" it must contain the "reboot.bin" image, special tool and/or scripts are needed to assemble the SPI Flash images to satisfy this requirement. If reset occurs while EAR =! 0 then Zynq PS is doing double reset sequence, first the reboot.bin executes, then it clears EAR and forces Zynq ARM core to reset followed by normal boot from Flash Address 0. However as reboot.bin does not perform any peripheral or memory or PLL initialization it executes very fast so the extra delay in startup is small. Boot history registers are also affected as there is sometimes extra reset involved during the boot. The likelihood of the double-reset to happen can be reduced if SSBL and application software do always include a dummy read from lower 16MByte after accesses to addresses above 16MB. |
| 7 | Duplicate FSBL at 16MByte boundary | Small change of FSBL, same FSBL at offset 0 and 16MByte. Code change affects only EAR register, all SPI Reads are still done using x4 commands. Same FSBL executes always no matter from what offset it was loaded, there is no significant change in startup time. There is no extra reset involved. | 256KByte sector at 16Mbyte offset in SPI Flash is "reserved" it must contain the "reboot.bin" image, special tool and/or scripts are needed to assemble the SPI Flash images to satisfy this requirement. |
| 8 | Duplicate EAR modified FSBL at 16MByte boundary | 256KByte sector at 16Mbyte offset in SPI Flash is "reserved" it must contain the "boot.bin" image (with the same FSBL as at offset 0), special tool and/or scripts are needed to assemble the SPI Flash images to satisfy this requirement. | |
| 9 | Implement System Controller in external CPLD forcing SPI Flash reset using Flash reset pin. | Small changes of software (need to pull one MIO Pin to fixed level). | One extra MIO pin is wasted. CPLD has to detect reliable all types of resets, this is only possible with software assistance. This detection may fail during debug sessions, so extra operation mode may have to be implemented to disable the CPLD reboot resets temporary. Have to use special SPI Flash IC with dedicated Reset input. |
Overview
Content Tools