ZYNQ 7000系統在出場時需要將韌體從eMMC啟動,原因有2:
需要注意,ZYNQ7000 系列不支援eMMC作為BOOT 啟動盤。那麼我們需要用QSPI FLASH + eMMC的方式啟動系統,QSPI FLASH存放BOOT檔案,eMMC存放核心檔案+檔案系統或者只存放檔案系統;
「The eMMC memory can only be used as secondary storage since the Zynq BOOTROM only recognizes QSPI, NAND, NOR or SD card as a primary boot medium.」
圖 1‑1 工作流程
建立vivado工程,匯出hdf描述檔案,這裡只需要根據原理圖給出一個最簡單的即可。
圖 2‑1 ZYNQ7000最小系統
編譯後,匯出hdf檔案。
首先你得有一個ubuntu的petalinux環境,這裡不做說明。
圖 2‑2 準備進入設定選項
圖 2‑3 進行高階啟動項設定,其它保持預設即可(如何SD有2個,可以手動選擇一個)
圖 2‑4 boot image, u-boot, kernel均選擇從FLASH啟動
圖 2‑5 boot從FLASH啟動,其它2項不再截圖說明
圖 2‑6 返回首頁,選擇Image打包設定
圖 2‑7 選擇ROOTFS為INITRAMFS(掉電不儲存資料)
以上設定完成後,儲存退出
由於需要用QSPI啟動的系統對eMMC進行分盤操作,需要用到如下命令
fdisk, mkfs, mount, umount
需要在ROOTFS設定中把這些庫包含進來。
petalinux-config -c rootfs
圖 2‑8 設定filesytem package
需要包含下列package
Inside base > util-linux, check util-linux, util-umount, util-mount, util-mkfs, util-fdisk
圖 2‑9
Inside base > e2fsprogs, check e2fsprogs-mke2fs
圖 2‑10 e2fsprogs-mke2fs
設定號之後,儲存退出,編譯
petalinux-build
編譯完成後,將uboot, kernel, fpga(bit stream 這裡沒有bit)全部打包到BOOT.bin
petalinux-package --boot --fsbl ./images/linux/zynq_fsbl.elf –fpga --u-boot --kernel –force
圖 2‑11 打包BOOT.BIN
然後用SDK或者VIVADO燒錄BOOT.bin到FLASH,為了簡單還是用VIVADO燒錄吧,這個燒錄也可以用指令碼實現,這裡不多討論。
圖 2‑12 燒錄BOOT.BIN到QSPI FLASH
然後設定為QSPI啟動,上電觀察UART輸出
圖 2‑13 啟動成功後觀察儲存裝置
首先檢視disk資訊,可以用fdisk -l,其中mmcblk0是eMMC,mmcblk0p1/2是之前已經分配好的分割區。
圖 3‑1 eMMC狀態
刪除已有分割區,重新來一遍
圖 3‑2 解除安裝disk
Fdisk刪除已有分割區, d 是刪除指令
圖 3‑3 刪除已有分割區
在fdisk互動模式下,按照以下步驟進行操作:
a. 輸入 n 建立新分割區。
b. 選擇主分割區或擴充套件分割區。
c. 設定分割區起始磁區(例如:預設值為 2048)。
d. 設定分割區結束磁區(根據您想要的分割區大小設定,64MB 對應 131072 磁區)。
e. 重複上述步驟建立第二個分割區。
圖 3‑4 建立1個primary分割區,64MB
圖 3‑5 建立第二個分割區
指定第一個分割區為FAT32
mkdosfs -F 32 /dev/mmcblk0p1
指定第二個分割區為EXT4,預設是ext4。注意,第二個分割區也分成primary即可。
圖 3‑6 分割區分配完成,並且自動mount 了
相對與QSPI啟動盤製作,只需要改動啟動設定、檔案系統設定即可。
boot.img和uboot 還是從FLASH啟動,kernel和檔案系統選擇SD啟動。
圖 4‑1 kernel存放在SD
圖 4‑2 檔案系統存放於SD卡
然後儲存退出,編譯打包即可,打包時無需打包kernel。
檔案有多個copy方式,比如U盤映象、網路copy,這裡為了簡單,我就用的U盤copy
圖 5‑1 U盤COPY,推薦用winscp 簡單直觀
如果是不包含fpga bit 檔案的BOOT.bin,大小大約500KB,而FPGA bit 檔案無論你是否有邏輯在裡面,尺寸都不會減小(因為FPGA的邏輯閘是固定的,約束檔案啟用壓縮選項會適當減小)。BOOT.bin尺寸打了以後,下載速度很慢,並且每次更新bit後有需要重新打包下載到FLASH,因此最好把bit放到eMMC裡面,這樣就方便多了。
「Zynq devices are hardwired in BOOTROM code to boot only from NAND, NOR, SD or QSPI persistent memory devices. However, it is possible to reduce the size of the primary boot image by moving the bitstream, normally the largest component by far, to secondary persistent storage. In this configuration, the primary boot image consists only of the first and second stage bootloaders, to create an image that is often less than 500K bytes. The second stage loader, u-boot in this case, is responsible for loading the Programmable Logic in the device via PCAP. The procedure can be demonstrated using a PicoZed module and carrier combination, where the boot image is stored in QSPI, and the bitstream and PetaLinux image is stored in eMMC.」
在Xilinx的FPGA中,有三個常見的用於部分重設定的模組,它們分別是ICAP、PCAP和MCAP。
ICAP代表Internal Configuration Access Port(內部設定存取埠),PCAP代表Processor Configuration Access Port(處理器設定存取埠),MCAP代表Media Configuration Access Port(媒體設定存取埠)。
在Xilinx的FPGA中,有三個常見的用於部分重設定的模組,它們分別是ICAP、PCAP和MCAP。
ICAP代表Internal Configuration Access Port(內部設定存取埠),PCAP代表Processor Configuration Access Port(處理器設定存取埠),MCAP代表Media Configuration Access Port(媒體設定存取埠)。
關於為什麼MCAP被稱為Media-CAP以及它的命名由來,我推測可能是因為無法使用PCIe-CAP,所以選擇了Media作為命名的一種替代。
xCAP是指在FPGA完成設定後,從FPGA邏輯存取FPGA設定功能的模組。
ICAP是實現在FPGA區域內的模組。當在僅使用FPGA裝置進行部分重設定時,FPGA邏輯可以使用ICAP來修改重設定區域。
相反,在執行處理器的裝置上,例如Zynq系列的裝置,實現了PCAP模組,ARM處理器可以通過PCAP存取FPGA的設定功能。
例如Vitis等框架在Linux環境中使用名為XRT的執行時來通過PCAP修改PL區域。
MCAP是從UltraScale開始引入的模組,它附加在PCIe硬體宏上。
例如,對於在PCIe匯流排上已被識別的FPGA裝置,可以直接將FPGA重設定為"PCIe->重設定區域",而不是通過"PCIe->執行中的FPGA邏輯->ICAP->重設定區域"這樣的路徑。
對於不帶有處理器且UltraScale中沒有PCIe的裝置(例如Virtex、Kintex和UltraScale+中沒有PCIe的裝置,是否有UltraScale中沒有PCIe的裝置我不確定),只存在ICAP模組。
由於ICAP是從FPGA邏輯存取的,因此存在類似於ICAPE3的模組,但PCAP和MCAP無法直接從FPGA邏輯存取,因此不存在相應的模組。
最近,我已經很少使用ICAP,但經常使用PCAP和MCAP,尤其是在與FPGA中的某些硬體宏(如MMCM、PCIe和GTY等)相結合時,我認為xCAP是最常用的模組。
關於為什麼MCAP被稱為Media-CAP以及它的命名由來,我推測可能是因為無法使用PCIe-CAP,所以選擇了Media作為命名的一種替代。
xCAP是指在FPGA完成設定後,從FPGA邏輯存取FPGA設定功能的模組。
ICAP是實現在FPGA區域內的模組。當在僅使用FPGA裝置進行部分重設定時,FPGA邏輯可以使用ICAP來修改重設定區域。
相反,在執行處理器的裝置上,例如Zynq系列的裝置,實現了PCAP模組,ARM處理器可以通過PCAP存取FPGA的設定功能。
例如Vitis等框架在Linux環境中使用名為XRT的執行時來通過PCAP修改PL區域。
MCAP是從UltraScale開始引入的模組,它附加在PCIe硬體宏上。
例如,對於在PCIe匯流排上已被識別的FPGA裝置,可以直接將FPGA重設定為"PCIe->重設定區域",而不是通過"PCIe->執行中的FPGA邏輯->ICAP->重設定區域"這樣的路徑。
對於不帶有處理器且UltraScale中沒有PCIe的裝置(例如Virtex、Kintex和UltraScale+中沒有PCIe的裝置,是否有UltraScale中沒有PCIe的裝置我不確定),只存在ICAP模組。
由於ICAP是從FPGA邏輯存取的,因此存在類似於ICAPE3的模組,但PCAP和MCAP無法直接從FPGA邏輯存取,因此不存在相應的模組。
The second stage loader, u-boot in this case, is responsible for loading the Programmable Logic in the device via PCAP. The procedure can be demonstrated using a PicoZed module and carrier combination, where the boot image is stored in QSPI, and the bitstream and PetaLinux image is stored in eMMC.
這裡已經說了U-boot負責PCAP的呼叫工作,所以如果需要使用細節,可以檢視u-boot程式碼。
The following tasks are required to move the bitstream to eMMC.
1. Modify the u-boot configuration to add bitstream loading from eMMC memory.
2. Use the PetaLinux toolchain to create a boot image with only the first stage loader and u-boot.
3. Use the write_cfgmem TCL command in Vivado to modify the bitstream by performing byteswapping, required to load via the PCAP interface. This creates a new binary format file.
4. Write the new binary file to the eMMC and boot the target from QSPI/eMMC.
https://github.com/Avnet/petalinux/blob/master/configs/u-boot/platform-top.h.pz_sd_boot_no_bit
圖 6‑1 首先找到platform-auto.h
然後進行修改,增加如下內容:
然後編譯:
Petalinux-build -c u-boot
編譯完成後,打包韌體
petalinux-package - -boot - - fsbl images/linux/images/zynq_fsbl.elf - -uboot - - force
只需要打包boot,uboot即可
然後對FPGA bit檔案放到image.ub同級目錄即可,這裡bit檔案需要用VIVADO的指令碼進行修改為bin檔案:
cd [get_property DIRECTORY [current_project]]/[current_project].runs/impl_1
write_cfgmem -format bin -interface spix1 -loadbit "up 0x0 [get_property top [current_fileset]].bit" -file [get_property DIRECTORY [current_project]]/system.bit.bin -force
上電啟動,觀察串列埠輸出和板卡加了bit之後的變化(我在之前和之後用了不同的LED顯示狀態用於觀察)