描述

在第一部分中，我通過 GPIO 控制器啟用了對板載按鈕、開關和 LED 的控制。在這一部分中，我將實現一個自定義 IP 核來控制 Zybo Z7-20 (Z7-10) 上兩個（一個）RGB LED 的顏色和亮度。

在這個故事的結尾，您會找到快速設置說明，以從源代碼存儲庫中復制完整的演示。

概念

RGB LED 實際上由三個單獨的 LED 組成：紅色、綠色和藍色。每種顏色都可以通過不同的引腳打開/關閉。因此，通過改變每個 LED 的亮度，我們基本上可以混合任何顏色。但是，如果我們只有一個開/關開關，我們如何實際調整亮度呢？答案稱為 PWM（脈寬調制）。當以快于大約 50Hz 的速度打開和關閉 LED 時，人眼無法檢測到任何閃爍。因此，通過改變開啟時間和關閉時間之間的比率，我們能夠欺騙人眼感知不同的亮度級別。

盡管現代 CPU 的速度肯定足以單獨執行這項工作，但要確保在高 CPU 負載下的正確時序可能會變得棘手。即使我們設法滿足 PWM 的嚴格時序要求，其他應用程序也需要頻繁搶占。幸運的是，我們還有可編程邏輯 (PL)，我們可以為其配備定制 IP 核，以完美無缺地執行 PWM，從而將所有 CPU 資源留給更有趣的計算。

在開始實際實施之前，讓我說明一下我想要實現的目標：

該圖顯示了用于控制單個 RGB LED 的 my IP 核的基本思想。Xilinx 在ug1118方面提供了更詳細的指南。

有了這些背景信息，我就能夠通過Tool → Create and Package New IP創建我的自定義 IP 核。在對話框中，我選擇了 Create a new AXI4 peripheral因為我想實現一個 MMIO 接口。在最后的對話中，我選擇了編輯 IP作為下一步。

Vivado 的 IP 打包工具已經負責生成所有樣板代碼。默認情況下，它實現了一個帶有四個 32 位寄存器的 MMIO 接口，這正是我控制兩個 RGB LED 的顏色和亮度所需要的。

為了實現 RGB 模塊，我添加了一個 Verilog 源文件并開始實現一個用于驅動單個 RGB LED 引腳的模塊：

module rgbled(
     output reg [2:0] rgb,
     input wire [6:0] brightness,
     input wire [7:0] red,
     input wire [7:0] green,
     input wire [7:0] blue,
     input wire clk
     );

     // [...] see below

 endmodule

該rgbled模塊得到一個三位輸出信號rgb（每種顏色一位）。此外，它還有四個用于亮度、紅色、綠色和藍色值的輸入信號以及一個時鐘輸入。如果您是 Verilog 的新手并且想知道 和 之間的區別reg，wire我可以向您推薦本教程。簡而言之，一個reg信號能夠存儲一些狀態，而一個wire僅僅是一個連接。

作為模塊實現的第一部分，我添加了一個循環計數器，當它達到某個最大值時，它會將自身重置為 0：

module rgbled(
     // [...] see above

     reg [14:0] counter;

     wire [14:0] max_cycles;

     always @(posedge clk) begin
         if (counter < max_cycles) begin
             counter <= counter + 1;
         end
         else begin
             counter = 0;
         end
     end

     // [...] see below
 endmodule

我決定采用 0 到 100 之間的亮度值，以便max_cycles在 255（亮度 100）和 25500（亮度 1）之間線性縮放，亮度為 0 的特殊情況：

module rgbled(
     // [...] see above

     assign max_cycles =
         brightness > 100 ? 255
                          : (brightness == 0 ? 0
                                             : 255 * 100 / brightness);

     // [...] see below
 endmodule

這使得實現開/關切換邏輯變得非常簡單：

module rgbled(
     // [...] see above

     always @(posedge clk) begin
         if (max_cycles > 0) begin
             rgb[0] <= red   > counter ? 1 : 0;
             rgb[1] <= blue  > counter ? 1 : 0;
             rgb[2] <= green > counter ? 1 : 0;
         end
         else begin
             rgb <= 3'b000;
         end
     end
 endmodule

這就完成了rgbled模塊，但是，它仍然需要在自定義 IP 內核中實例化。創建 IP 核時，Vivado 生成了兩個 Verilog 文件。我確定后綴為S00_AXI.v的文件是 MMIO 模塊，另一個文件是頂層模塊。查看 MMIO 模塊，我注意到文件頂部有一條注釋“用戶在此處添加端口”，我在其中為輸出信號添加了這兩行：

// Users to add ports here
 output wire [2:0] led0,
 output wire [2:0] led1,

 // User ports ends
 // Do not modify the ports beyond this line

在文件的底部，我找到了注釋“在此處添加用戶邏輯”并插入了我的rgbled模塊的兩個實例。查看自動生成的實現，我發現 MMIO 寄存器被命名為slv_reg0, slv_reg1,slv_reg2以及slv_reg3. 因此，我只需要決定哪個寄存器中的哪些位。用于 RGB 和亮度值。我最終得到了這些實例化：

// Add user logic here
     rgbled led0_control (
         .clk   (S_AXI_ACLK),
         .red   (slv_reg0[23:16]),
         .blue  (slv_reg0[15:8]),
         .green (slv_reg0[7:0]),
         .brightness (slv_reg1[6:0]),
         .rgb   (led0)
     );

     rgbled led1_control (
         .clk   (S_AXI_ACLK),
         .red   (slv_reg2[23:16]),
         .blue  (slv_reg2[15:8]),
         .green (slv_reg2[7:0]),
         .brightness (slv_reg3[6:0]),
         .rgb   (led1)
     );
     // User logic ends

由于我修改了 MMIO 模塊的端口，我還在頂層文件中添加了兩個類似的輸出端口，并將它們傳遞給 MMIO 模塊的實例化。

完成這些更改后，我注意到Package IP視圖發生了一些變化。首先，文件組部分不再有綠色勾號。查看此部分并遵循 Vivado 的合并更改建議解決了此問題。端口和接口部分提供了一個類似的合并向導。Vivado 自動檢測到我之前添加的led0和led1端口。本節不需要手動調整，但我了解到我能夠定義某些類型的接口并將端口映射到這些接口。因此，人們可以將信號分組到一個共同的分組中，并協助 Vivado 的自動連接魔法。

我跳過了接口定義，進入了Review and Package部分并打包了我的 IP 核。我回到我的塊設計并將新封裝的 IP 內核添加到設計中，運行自動連接向導并將led0端口設置led1為外部（與之前對GPIO_0接口所做的一樣，請參見第 1 部分）。MMIO 設備的地址由 Vivado 自動分配，但可以在打開塊設計后在地址編輯器中更改。在重新生成比特流之前，我取消了約束文件中 RGB LED 行的注釋，并插入了相應的信號名稱（led0_0[0]toled0_0[2]和led1_0[0]to led1_0[2]）。

請注意，如果您想稍后編輯 IP 核，您可以右鍵單擊模塊設計中的核并選擇Edit in IP Packager 。

最終，我為這個新設計生成了比特流，并使用File → Export → Export Bitstream File導出結果。

使用自定義 IP 內核

有了新的比特流，我實現了一個zybo_gpio_demo_rgb組件來測試 MMIO 接口。該組件使用按鈕 0 到 3 循環顯示兩個 RGB LED 的某些顏色和亮度值。您可以在genode-zynq 存儲庫中找到代碼。如果您遵循了第 1 部分，那么其中的大部分內容是不言自明的。然而，讓我簡要說明如何訪問 MMIO 接口：

#include 

/* [...] */

class Demo::Rgb_leds : public Platform::Device::Mmio
{
	private:

		struct Led : Genode::Mmio {
			struct Color      : Register<0x0, 32> { };
			struct Brightness : Register<0x4, 32> { };

			void color(uint32_t c) {
				write(c); }

			void brightness(uint32_t b) {
				write(b); }
		};

		Led led0 { (addr_t)local_addr<void>() };
		Led led1 { (addr_t)local_addr<void>() + 0x8 };

	public:

		Rgb_leds(Platform::Device &device)
		: Platform::Device::Mmio(device)
		{ }

		void led0_color(uint32_t c) {
			led0.color(c); }

		void led0_brightness(uint32_t b) {
			led0.brightness(b); }

		void led1_color(uint32_t c) {
			led1.color(c); }

		void led1_brightness(uint32_t b) {
			led1.brightness(b); }
};

在 Genode 中，可以通過寄存器框架輕松訪問 MMIO 接口。我們只需要繼承Platform::Device::Mmio（或Genode::Mmio）并定義幾個寄存器。Platform::Device::Mmio從平臺驅動程序獲取映射的設備地址，而Genode::Mmio期望地址作為構造函數參數。在這里，我使用后者來定義Led包含單個 LED的Color和寄存器的結構。Brightness該類的模板參數Register指定其偏移量和訪問寬度（以位為單位）。可以輕松讀取寄存器。用模板方法編寫，read()如write()和 中Led::color()所示Led::brightness()。然后，我使用 的方法實例化該Led結構兩次，以獲取映射的設備地址。local_address()Platform::Device::Mmio

為了將新實現的組件添加到 GPIO 演示中，我在run/zybo_gpio_demo.run腳本中添加了以下啟動節點：

<start name="zybo_gpio_demo_rgb">
     <resource name="RAM" quantum="2M"/>
     <route>
         <service name="Pin_control"> <child name="zynq_pin_drv"/> service>
         <service name="Pin_state">   <child name="zynq_pin_drv"/> service>
         <service name="IRQ">         <child name="zynq_pin_drv"/> service>
         <service name="Platform">    <child name="platform_drv"/> service>
         <service name="ROM"> <parent/> service>
         <service name="CPU"> <parent/> service>
         <service name="PD">  <parent/> service>
         <service name="LOG"> <parent/> service>
     route>
 start>

此外，我修改了引腳驅動程序配置如下：

<config>
     
     <in  name="Btn4" bank="1" index="18" irq="rising"/>
     <in  name="Btn5" bank="1" index="19" irq="rising"/>
     <out name="Led4" bank="0" index="7"  default="on"/>

     <policy label="zybo_gpio_demo_mio -> Btn4" pin="Btn4"/>
     <policy label="zybo_gpio_demo_mio -> Btn5" pin="Btn5"/>
     <policy label="zybo_gpio_demo_mio -> Led4" pin="Led4"/>

     
     <in  name="Sw0"  bank="2" index="0" irq="edges"/>
     <in  name="Sw1"  bank="2" index="1" irq="edges"/>
     <in  name="Sw2"  bank="2" index="2" irq="edges"/>
     <in  name="Sw3"  bank="2" index="3" irq="edges"/>
     <out name="Led0" bank="2" index="8"  default="off"/>
     <out name="Led1" bank="2" index="9"  default="off"/>
     <out name="Led2" bank="2" index="10" default="off"/>
     <out name="Led3" bank="2" index="11" default="off"/>

     <policy label="zybo_gpio_demo_sw -> Sw0"  pin="Sw0"/>
     <policy label="zybo_gpio_demo_sw -> Sw1"  pin="Sw1"/>
     <policy label="zybo_gpio_demo_sw -> Sw2"  pin="Sw2"/>
     <policy label="zybo_gpio_demo_sw -> Sw3"  pin="Sw3"/>
     <policy label="zybo_gpio_demo_sw -> Led0" pin="Led0"/>
     <policy label="zybo_gpio_demo_sw -> Led1" pin="Led1"/>
     <policy label="zybo_gpio_demo_sw -> Led2" pin="Led2"/>
     <policy label="zybo_gpio_demo_sw -> Led3" pin="Led3"/>

     
     <in  name="Btn0" bank="2" index="4" irq="edges"/>
     <in  name="Btn1" bank="2" index="5" irq="edges"/>
     <in  name="Btn2" bank="2" index="6" irq="edges"/>
     <in  name="Btn3" bank="2" index="7" irq="edges"/>
     <policy label_suffix="zybo_gpio_demo_rgb -> Btn0" pin="Btn0"/>
     <policy label_suffix="zybo_gpio_demo_rgb -> Btn1" pin="Btn1"/>
     <policy label_suffix="zybo_gpio_demo_rgb -> Btn2" pin="Btn2"/>
     <policy label_suffix="zybo_gpio_demo_rgb -> Btn3" pin="Btn3"/>
 config>

為了進行簡短的測試運行，我通過（臨時）將以下行添加到board/zynq_zybo_z7/devices文件來讓平臺驅動程序了解新的 MMIO 設備：

<device name="rgbleds" type="my_rgbleds">
     <io_mem address="0x43c00000" size="0x1000"/>;
 device>

為了能夠訪問這個 MMIO 設備，我還在 platform-driver 配置中添加了相應的策略：

<policy label="zybo_gpio_demo_rgb -> ">
     <device name="rgbleds"/>
 policy>

將比特流文件復制到我的 SD 卡后，我可以使用 LED 下方的四個按鈕更改兩個 RGB LED 的顏色和亮度。但是，由于zybo_gpio_demo_rgb使用的 MMIO 設備只有在我的自定義比特流被加載時才可用，所以我更愿意在運行時使用 Genode 執行比特流加載過程，以便我可以在比特流加載后自動啟動相應的軟件組件.

在運行時切換比特流

在本節中，讓我們看看如何在運行時在 Genode 中加載比特流。僅僅對 FPGA 進行重新配置非常簡單，但它對定制平臺設備的可用性也有影響。為了適應這個用例，我創建了倉庫存檔pkg/drivers_fpga-zynq 。

如上圖所示，pkg/drivers_fpga-zynq子系統需要兩個 ROM 會話（devices_manager.config和policy ）以及一個文件系統會話。作為回報，它通過提供平臺服務充當平臺驅動程序。策略ROM 包含此 GPIO 演示的平臺驅動程序配置：

<report devices="yes"/>
 <policy label_suffix="zynq_pin_driver -> ">
     <device name="gpio0"/>
 policy>
 <policy label_suffix="zybo_gpio_demo_rgb -> ">
     <device name="rgbleds"/>
 policy>

節點指示內部平臺驅動程序在其狀態發生變化時生成設備報告。Zynq 驅動程序管理器使用此報告來確定特定設備何時可用。因此，Zynq Driver Manager 可能會生成一個新的init.config來啟動相應的驅動程序組件。驅動程序組件和相應的設備依賴項在管理器的配置中指定。為了在my_rgbleds設備可用后啟動zybo_gpio_demo_rgb ，我使用以下配置：

<config>
     <driver name="zybo_gpio_demo_rgb" device="my_rgbleds">
         <binary name="zybo_gpio_demo_rgb"/>
         <resource name="RAM" quantum="2M"/>
     driver>
 config>

devices_manager.config提供比特流及其實現的設備的規范。我們可以讓pkg/drivers_fpga-zynq子系統知道什么比特流可以使用什么設備，而不是像我在上一節中那樣將rgbleds設備添加到靜態設備 ROM。對于我之前生成的兩個比特流，我使用以下devices_manager.config 。

<config>
     <bitstream name="zybo_z720_rgb-bitstream.bit">
         <devices>
             <device name="rgbleds" type="my_rgbleds">
                 <io_mem address="0x43c00000" size="0x1000"/>;
             device>
         devices>
     bitstream>
     <bitstream name="zybo_z720_gpio-bitstream.bit"/>
 config>

請注意，我將兩個 ROM（devices_manager.config和policy ）打包到一個raw/zybo_gpio_demo存檔中。

pkg/drivers_fpga-zynq子系統最終從其文件系統會話中讀取用戶提供的比特流。此外，負責比特流加載的內部fpga_drv組件從/config文件獲取其配置。因此，該文件指定應將哪些比特流加載到 FPGA 中，例如：

<config>
     <bitstream name="zybo_z720_rgb-bitstream.bit"/>
 config>

通過簡單地更改此文件的內容，我們可以在比特流之間切換。至此，zybo_gpio_demo_mio組件為什么要生成狀態報告就清楚了。通過在run/zybo_gpio_demo.run腳本中添加一個ROM filter組件，我可以輕松實現碼流切換：

<start name="rom_filter">
 <resource name="RAM" quantum="1M"/>
 <provides>
     <service name="ROM"/>
 provides>
 <route>
     <service name="ROM" label="state"> <child name="report_rom"/> service>
     <service name="ROM"> <parent/> service>
     <service name="CPU"> <parent/> service>
     <service name="PD">  <parent/> service>
     <service name="LOG"> <parent/> service>
 route>
 <config>
     <input name="state">
         <attribute name="value"/>
     input>

     <output node="config">
         <node type="bitstream">
             <if>
                 <has_value input="state" value="yes"/>
                 <then>
                     <attribute name="name"
                                value="zybo_z720_rgb-bitstream.bit"/>
                 then>
                 <else>
                     <attribute name="name"
                                value="zybo_z720_gpio-bitstream.bit"/>
                 else>
             if>
         node>
     output>
 config>
start>

當然，我還需要實例化上圖中所示的所有組件。讓我們從用pkg /drivers_fpga-zynq子系統替換platform_drv開始：

<start name="platform_drv" caps="1000" managing_system="yes">
     <binary name="init"/>
     <resource name="RAM" quantum="24M"/>
     <provides> <service name="Platform"/> provides>
     <route>
         <service name="ROM" label="config">
            <parent label="drivers.config"/>
         service>
         <any-service> <parent/> <any-child/> any-service>
     route>
 start>

接下來，我添加了 Zynq 驅動程序管理器、動態驅動程序子系統和 VFS 服務器：

<start name="zynq_driver_manager">
     <resource name="RAM" quantum="2M"/>
     <route>
         <service name="ROM" label="devices">
             <child name="report_rom"/>
         service>
         <any-service> <parent/> <any-child/> any-service>
     route>
     <config>
         <driver name="zybo_gpio_demo_rgb" device="my_rgbleds">
             <binary name="zybo_gpio_demo_rgb"/>
             <resource name="RAM" quantum="2M"/>
         driver>
     config>
 start>

 <start name="dynamic_drivers" caps="500">
     <binary name="init"/>
     <resource name="RAM" quantum="5M"/>
     <route>
         <service name="ROM" label="config">
             <child name="report_rom"/>
         service>
         <service name="IRQ"> <child name="zynq_pin_drv"/> service>
         <any-service> <parent/> <any-child/> any-service>
     route>
 start>

 <start name="vfs">
     <resource name="RAM" quantum="8M"/>
     <provides><service name="File_system"/>provides>
     <route>
         <service name="ROM" label="fpga.config">
             <child name="rom_filter"/>
         service>
         <any-service> <parent/> any-service>
     route>
     <config>
         <vfs>
             <rom name="config" label="fpga.config"/>
             <rom name="zybo_z720_gpio-bitstream.bit"/>
             <rom name="zybo_z720_rgb-bitstream.bit"/>
         vfs>
         <default-policy root="/" writeable="no"/>
     config>
 start>

VFS 組件通過文件系統會話傳送由 ROM 過濾器組件生成的比特流和fpga.config ROM。

最后，我將import_from_depot行更新如下：

import_from_depot [depot_user]/src/[base_src] \
                   [depot_user]/src/init \
                   [depot_user]/pkg/drivers_fpga-zynq \
                   [depot_user]/src/driver_manager-zynq \
                   [depot_user]/src/report_rom \
                   [depot_user]/src/rom_filter \
                   [depot_user]/src/vfs \
                   [depot_user]/raw/zybo_gpio_demo \
                   [depot_user]/src/zynq_pin_drv \
                   [depot_user]/raw/[board]-devices

試一下修改后的運行腳本，我得到了這個輸出：

build/arm_v7a #> make run/zybo_gpio_demo BOARD=zynq_zybo_z7 KERNEL=hw
 ...
 [init -> report_rom] Warning: no policy defined for
                      label 'zynq_driver_manager -> devices'
 [init -> report_rom] Warning: no valid policy for ROM request
                      'zynq_driver_manager -> devices'
 [init -> report_rom] Warning: no policy defined for
                      label 'dynamic_drivers -> config'
 [init -> report_rom] Warning: no valid policy for ROM request
                      'dynamic_drivers -> config'
 [init -> report_rom] Warning: no policy defined for
                      label 'rom_filter -> state'
 [init -> report_rom] Warning: no valid policy for ROM request
                      'rom_filter -> state'
 ...

當然，我忘記了將策略定義添加到report_rom配置中，因此我為每個記錄的標簽添加了一個策略節點：

     
               report="zybo_gpio_demo_mio -> state"/>
     
               label="zynq_driver_manager -> devices"/>
     
               label="dynamic_drivers -> config"/>
 

運行腳本的另一個旋轉產生以下輸出：

[init -> vfs] Error: ROM-session creation failed (ram_quota=6144,
               cap_quota=3, label="zybo_z720_gpio-bitstream.bit")
 [init -> vfs] Error: Could not open ROM session for
               "zybo_z720_gpio-bitstream.bit"
 [init -> vfs] Error: failed to create  VFS node
 [init -> vfs] Error:    name="zybo_z720_gpio-bitstream.bit"
 [init -> vfs] Error: ROM-session creation failed (ram_quota=6144,
               cap_quota=3, label="zybo_z720_rgb-bitstream.bit")
 [init -> vfs] Error: Could not open ROM session for
               "zybo_z720_rgb-bitstream.bit"
 [init -> vfs] Error: failed to create  VFS node
 [init -> vfs] Error:    name="zybo_z720_rgb-bitstream.bit"

我還沒有提供比特流文件。對于一個簡短的測試，我可以簡單地將文件復制到build/arm_v7a/bin并將它們添加到該build_boot_image行。然而，我想到了另一個解決方案，它使用Goa ，一個基于命令行的工作流工具，用于為 Genode OS 框架開發應用程序。

為 Genode 構建和打包比特流

為了以倉庫檔案的形式提供比特流，我添加了對 Goa 的 Vivado 支持。幸運的是，Vivado 提供了以 tcl 腳本形式導出項目的命令，允許重新創建項目。在本節中，我將重點介紹如何使用 Goa 的 Vivado 支持。

首先，我需要導出要打包的 Vivado 項目。因此，在 Vivado 的 TCL 控制臺中，我輸入了以下命令：

write_project_tcl -paths_relative_to /home/johannes/vivado_workspace /tmp/vivado.tcl

該-paths_relative_to參數是必不可少的，因為它將源文件的路徑轉換為相對路徑。在我的goa-pkgs 存儲庫中，我創建了子目錄zynq/zybo_z720_rgb-bitstream/以創建一個新的 Goa 項目并將vivado.tcl復制到新的 Goa 項目的src/子目錄中。通過檢查 tcl 文件，我們可以獲得所需源文件的列表。在我的 tcl 文件中，以下幾行引起了我的注意：

proc checkRequiredFiles { origin_dir} {
   set status true
   set files [list \
  "[file normalize "$origin_dir/xilinx/project_2/project_2.srcs/constrs_1/imports/Downloads/Zybo-Z7-Master.xdc"]"\
   ]
   foreach ifile $files {
     if { ![file isfile $ifile] } {
       puts " Could not find local file $ifile "
       set status false
     }
   }

   set paths [list \
  "[file normalize "$origin_dir/../../[file normalize "$origin_dir/xilinx/ip_repo/rgbled_1.0"]"]"\
   ]
   foreach ipath $paths {
     if { ![file isdirectory $ipath] } {
       puts " Could not access $ipath "
       set status false
     }
   }

   return $status
 }

該checkRequiredFiles過程提供了關于我必須將哪些源文件復制到我的 Goa 項目中的第一個提示。在這種情況下，它列出了約束文件以及我的自定義 IP 內核的路徑。

請注意，Goa 會將src / 目錄中的所有文件鏡像到存檔的構建目錄中。$origin_dir此外，在重新創建 Vivado 項目時，它將使用構建目錄。因此，必須將所需文件及其相應的相對路徑復制到src / 目錄中。

通過向我的 Goa 項目添加一個工件文件，我進一步告訴 Goa 將什么構建工件包含到bin//zybo_z720_rgb-bitstream存檔中。由于 Goa 將比特流寫入以模式命名的文件中.bit，因此工件文件必須具有以下內容：

zybo_z720_rgb-bitstream.bit

此外，由于 bin 存檔總是與特定的 CPU 體系結構相關聯，因此我arm_v7a通過添加具有以下內容的.goarc來設置目標體系結構：

set arch arm_v7a
set jobs 1

請注意，我還將作業數限制為 1，以減少 Vivado 的資源消耗。有了這些先決條件，產生了以下錯誤：goa build

goa-pkgs/zynq/zybo_z720_rgb-bitstream$ goa build
Error: tool-chain prefix is not defined

此消息暗示在 Goa 中尚無對arm_v7a的內置支持。因此，我通過將以下行添加到.goarc文件來手動定義工具鏈前綴：

set cross_dev_prefix "/usr/local/genode/tool/current/bin/genode-arm-"

現在，goa build抱怨缺少 vivado 二進制文件：

goa-pkgs/zynq/zybo_z720_rgb-bitstream$ goa build
...
Error: build-directory creation via vivado failed:
  couldn't execute "vivado": no such file or directory

當然，我忘記了Vivado環境的源碼。如下修復此問題后，Goa 能夠在幾分鐘內構建比特流：

goa-pkgs/zynq/zybo_z720_rgb-bitstream$ source /tools/Xilinx/Vivado/2021.1/settings64.sh
goa-pkgs/zynq/zybo_z720_rgb-bitstream$ goa build
...
[zybo_z720_rgb-bitstream:vivado] 10 Infos, 0 Warnings, 0 Critical Warnings and 0 Errors encountered.
[zybo_z720_rgb-bitstream:vivado] write_bitstream completed successfully
[zybo_z720_rgb-bitstream:vivado] write_bitstream: Time (s): cpu = 00:00:11 ; elapsed = 00:00:13 . Memory (MB): peak = 3202.781 ; gain = 451.625 ; free physical = 1133 ; free virtual = 2434
[zybo_z720_rgb-bitstream:vivado] INFO: [Common 17-206] Exiting Vivado at Thu Oct  6 15:35:31 2022...

構建成功后，我準備嘗試goa export –depot-user jschlatow。輸出提醒我添加許可證和版本文件。添加這些文件后，我準備導出和發布 depot 存檔。

使用打包的比特流

最后遺漏的一塊拼圖是將以下參數添加到run/zybo_gpio_demo.run中的import_from_depot過程。

import_from_depot ...
                  jschlatow/src/zybo_z720_rgb-bitstream/2022-09-29 \
                  jschlatow/src/zybo_z720_gpio-bitstream/2022-09-27 \
                  ...

現在，在運行時make run/zybo_gpio_demo，我可以使用按鈕 4 和 5 在兩個比特流之間切換。

從源代碼復制演示

要重現演示，您可以在 genode-zynq 存儲庫中找到完整的運行腳本和源文件。我假設您已經克隆了主 genode 存儲庫和 genode-zynq 存儲庫（請參閱Genode 101：Zybo Z7 入門）。這也意味著您已經為arm_v7a創建了一個構建目錄。

作為先決條件，您需要下載比特流檔案。這是通過必須從基因節點工作樹中運行的以下兩個命令來實現的。

genode$ ./tool/depot/download jschlatow/bin/arm_v7a/zybo_z720_rgb-bitstream/2022-09-29
genode$ ./tool/depot/download jschlatow/bin/arm_v7a/zybo_z720_gpio-bitstream/2022-09-27

現在，您可以按如下方式執行運行腳本：

genode$ make -C build/arm_v7a run/zybo_gpio_demo BOARD=zynq_zybo_z7

如果您已經按照說明進行了 TFTP 引導，則只需按下 Zybo 板上的重置按鈕并等待系統引導新建的映像。或者，您將之前準備的 micro SD 卡的uImage文件替換為build/arm_v7a/var/run/zybo_gpio_demo/uImage。系統啟動后，您可以使用按鈕 4 和 5 切換比特流。這兩個比特流都允許您使用四個開關來控制它們旁邊的 LED。然而，只有在加載zybo_z720_rgb-bitstream時才能控制 RGB LED 。按鈕 0 到 3 用于循環顯示不同的顏色和亮度設置。