Introduction
If the FPGA is operated in conjunction with a CPU, as in this
example, there is no direct access to
the EPCS memory. This requires a special FPGA bootloader to update the FPGA through the CPU
or without special hardware.
"The default EPCS Bootloader from altera resides in the first 0x400 (1K) bytes of the
epcs controller. This bootloader figures out the size of the sof information loaded in the EPCS
device and then assumes that that code follows immidiately afterwards. This works fine for single
hardware and software images. However if you have multiple images or you wish to place the nios
code at a different location, the default boot loader will not work for you."
(Source: "EPCS bootloaders"
Altera Wiki)
To solve this problem, the XModem bootloader environment was created with the source of an
alternative EPCS bootloader, the RSU code of the BeMicro
example, and a XModem functionality.
Hardware
Here the DE0-Nano Development and Education Board was used:
By the way, C3 (TXT) and A3 (RXD) are used for the UART.
Software
The alternative EPCS Bootloader and the RSU code from the example are only needed for Quartus
versions less than v15. From version 15 onwards, the new EPCS serial flash controller and
the Remote Update IP can be used without modifications. But here I use Quartus version 11.1sp2.
Additional hints can be find here:
XModem Bootloader (COM)
The DE0-Nano board is equipped with an
EPCS64
or EPCS64 compatible serial configuration device. This configuration device is like a SPI
flash memory. In case of the XModem Bootloader the address map looks like:
Area |
Address Offset |
Size (bytes) |
Bootloader area |
0x00000000 |
1024K |
User area |
0x00100000 |
7168K |
The EPCS64 has a size of 8 MBytes. Where the first 1 MByte is reserved for the XModem
Bootloader which contains the FPGA image and Nios II program. The user area, starting
by 0x00100000, can be used for a FPGA image only, or an image with Nios II program.
The data received from the XModem Bootloader must contain a valid XBOOT header. The XBOOT
header looks like:
The header and data are secured by a checksum. The data follows directly after the XBOOT
header. "StartAddress" is the start address of the XBOOT header in the EPCS memory.
The size of the update file, header and data, must be 64K bytes aligned. 64K bytes is the size
of a sector inside the EPCS memory.
The update file can be generated with the tool "rpd2xboot". This little tool requires
an Altera RPD (Raw Programming Data File) file for input and generates the XBOOT (XBO)
update file.
The XModem Bootloader checks if a valid image is available at address 0x00100000. If the
image is valid, it will be started automatically. If "KEY0" of the DE0-Nano is pressed while
the power is turned on, no valid image is started and the update mode will entered.
In this example, a real UART was used. However, it is also possible to use a virtual UART for
the update.
Some more features:
- The UART use 115200 baud, 8 bits, no parity, 1 stop bit and no flow control.
- Only a packet size of 128 bytes with CRC-16 is supported.
- A ping each second is send to start the XModem transfer.
- The XModem Bootloader will send a NAK to request a retransmitting if the delay between
two consecutive bytes of the same packet is more than 1000 ms.
- The XModem Bootloader will send a NAK to request a retransmitting if a CRC error is detected.
- Once the transfer ist started, the XModem Bootloader will abort the transfer and send a CAN
if no data was received for more than 10000 ms.
- The XModem Bootloader will abort the transfer and send a CAN if it cannot synchronize anymore
to the packet number.
FPGA image only
Here the example "de0n-xboot-blinky" is used to test the XModem Bootloader and to create
the sample screenshots.
After power on, and without a valid image available, the output looks like:
While the data is transferred, the output looks like:
If the transfer is finished, some tests will be done with the image. If the tests was successful,
the new image will be stored in the EPCS memory. The output looks like:
The image can be started by pressing "s". Now the LEDs should be running on the DE0-Nano board.
After power on, and with a valid image available, the output looks like:
And the image was started automatically by the XModem Bootloader.
If "KEY0" of the DE0-Nano is pressed while the power is turned on, no valid image is started and
the update mode will entered. The output looks like:
FPGA and Nios II image
Compared to the previous "FPGA image only" example there is an additional Nios II application available
here. Because of the multi image application, a new EPCS Bootlaoder is needed. This
alternative bootloader, "BROM", is implemented in the on-chip memory of the FPGA. The address map here
looks like:
Area |
Address Offset |
Size (bytes) |
Bootloader area |
0x00000000 |
1024K |
FPGA image |
0x00100000 |
768K |
Nios II image |
0x001C0000 |
64K |
"HW_OFFSET" and "SW_OFFSET" in "_create_img.bat" is used to set the address offset
from the FPGA and Nios II image. After power on the output looks like:
Here the FPGA image at address 0x00100000 is started by the XModem bootloader. This starts the EPCS bootloader
which in turn starts the Nios II application. By the way, the Nios II reset vector offset inside the EPCS memory
must be set with the Qsys "EPCS Reset vector offset" too:
For the "FPGA and Nios II image" example "de0n-xboot-test" was used.
XModem Bootloader (virtual COM)
This example is more a Proof of Concept than a full featured application. The XModem bootloader here has the
same functionality as the previous one but with a virtual COM port. Therefore the control is no longer done
via TeraTeram but via the CPU with which the virtual COM port is "connected". To test the
XModem bootloader with the virtual COM port, a DE0-Nano and an EA-LPC1788
board were used, which are connected with jumper wires.
The example "de0n-xboot-blinky" was also used here, where the XBO file was converted into a
C array with the help of xbin2c.
Download
If you got an error like "Generating BSP... has encountered a problem" take a look
here,
maybe "bsp-path-check" can solve the problem.
XModem Bootloader (COM) de0n-xboot-com_20170923 (699 KB, for Quartus II 11.1sp2)
XModem Bootloader (vCOM) de0n-xboot-vcom_20170923 (1.83 MB, for Quartus II 11.1sp2)
Test image "blinky" de0n-xboot-blinky_20170827 (40 KB, for Quartus II 11.1sp2)
Test image "test" de0n-xboot-test_20170915 (981 KB, for Quartus II 11.1sp2)
rpd2xboot-source_20170915 for Microsoft Visual C++ 6.0 (14 KB)
xbootinfo-source_20170918 for Microsoft Visual C++ 6.0 (11 KB)
rpd2xboot-win_20170915 application (23 KB)
md5sum zip file: 137A34A7D450D7E1ACA285C2242AD53D
xbootinfo-win_20170918 application (21 KB)
md5sum zip file: 4C2F820CF8902298E1E2049DB63846B4
|