Zybo Z7 帶有一組用戶控制的 LED、按鈕和開關。所有這些都可以通過 Zynq 的 GPIO 控制器訪問。然而，只有一個 LED 和兩個按鈕直接連接到處理系統 (PS)，其余連接到可編程邏輯 (PL)。因此，在這個項目中，我不僅會展示如何控制 Zynq 的 GPIO，還會展示如何使用 GPIO 和 MMIO 與 PL 交互。

請注意，我假設您知道如何在 Zybo Z7 上運行 Genode。如果沒有，請查看我的Zybo Z7 項目入門。

建筑學

下圖說明了 Genode 中用于引腳級訪問的一般架構。最底層是Core / Init組件，它擁有最終權限并且不受訪問策略限制。它只是通過 IRQ 和 MMIO 服務向平臺驅動程序提供所有設備資源的權限。后者提供平臺服務，特定組件可以通過該服務獲得對單個設備的授權。在這種情況下，引腳驅動程序獲得對 GPIO 控制器的權限。同樣，它提供了Pin control 、Pin state和IRQ服務，用于將各個引腳的寫入、讀取和通知權限傳遞給特定組件。在此示例中，我將實現一個 MIO 演示組件，該組件控制 Zybo Z7 板的按鈕 4、按鈕 5 和 LED 4 的 PS 可訪問 GPIO 引腳。

權限由平臺驅動和管腳驅動逐漸降低。

?

測試引腳驅動器

Genode 21.11 引入了Pin I/O 會話接口，該接口首先由A64 SoC 的引腳驅動程序實現。使用 A64 引腳驅動程序作為藍圖，我效仿并為 Zynq SoC 實現了引腳驅動程序。由于出色的基礎工作，我能夠重用大部分代碼并專注于特定于 SoC 的部分。

有了手邊的引腳驅動器，我已經能夠控制 PS 可訪問的 LED 和按鈕。因此，我編寫了一個微型 MIO 演示組件。按下按鈕 4 時組件應打開 LED，按下按鈕 5 時關閉 LED。它還會生成反映 LED 狀態的狀態報告。

編寫組件的第一步是創建一個target.mk文件。慣例是根據組件的類型將組件的源代碼放在src/app、src/server、src/drivers或src/test 的子目錄中。在我的genode-zynq 存儲庫的克隆中，我因此創建了包含以下內容的文件src/app/zynq_gpio_demo/mio/target.mk 。請注意，因為我要實現多個相關組件，所以我將所有組件捆綁在一個公共子目錄zynq_gpio_demo 中。

TARGET := zybo_gpio_demo_mio
SRC_CC := main.cc
LIBS   := base

target.mk包含一些聲明，這些聲明將在編譯組件時由Genode的構建系統解釋。第一行指定目標二進制文件的名稱。第二行說明應將哪些源文件傳遞給 C++ 編譯器。在第三行中，我定義了庫依賴項（表示 Genode 的基礎 API）。base

接下來，我創建了main.cc文件。讓我們從前幾行開始。

/* Genode includes */
#include 

我們必須包含一些頭文件：base/component.h頭文件是實現本機 Genode 組件所必需的。接下來的三個包含是前面提到的由引腳驅動程序實現的引腳 I/O 會話接口所必需的。最后，os/reporter.h需要生成上述狀態報告。

我進一步Main在單獨的Demo名稱空間中聲明了一個對象。本地 Genode 組件沒有作為main() 我們在 POSIX 程序中使用的入口點的功能。相反，入口點是Component::construct() 我簡單地按Demo::Main對象實例化的方法。現在，讓我們看一下它的實現。

struct Demo::Main
{
    /* members */

    Env &_env;

    Pin_state::Connection   _btn4 { _env, "Btn4" };
    Pin_state::Connection   _btn5 { _env, "Btn5" };

    Pin_control::Connection _led4 { _env, "Led4" };

    Irq_connection _irq4 { _env, "Btn4" };
    Irq_connection _irq5 { _env, "Btn5" };

    Signal_handler _irq_handler {
        _env.ep(), *this, &Main::_handle_irq };

    Expanding_reporter _reporter { _env, "state", "state" };


    /* methods */

    void _update_state(bool on)
    {
        _reporter.generate([&] (Genode::Xml_generator & xml) {
            xml.attribute("value", on ? "yes" : "no");
        });

        _led4.state(on);
    }

    void _handle_irq()
    {
        _irq4.ack_irq();
        _irq5.ack_irq();

        if (_btn4.state())
            _update_state(true);
        else if (_btn5.state())
            _update_state(false);
    }


    /* constructor */

    Main(Env &env) : _env(env)
    {
        _update_state(false);

        _irq4.sigh(_irq_handler);
        _irq5.sigh(_irq_handler);
        _irq4.ack_irq();
        _irq5.ack_irq();
    }
};

成員：首先，該Main對象持有一個引用，Genode::Env因為這是構建其他成員所必需的。為了訪問按鈕的輸入引腳，我使用了Pin_state::Connection對象。傳遞給其構造函數的字符串稱為會話標簽，由 pin 驅動程序評估以應用匹配的訪問控制策略（詳情如下）。同樣，為了訪問 LED 的輸出引腳，我使用了一個Pin_control::Connection對象。此外，因為我想收到按鈕狀態更改的通知，所以我Irq_connection為每個按鈕添加了一個對象。這些伴隨著一個Signal_handler將注冊到 IRQ 連接的對象。此信號處理程序將調用該方法。最后，我正在使用狀態報告。這_handle_irq()Expanding_reporterExpanding_reporter將兩個字符串作為構造函數參數。第一個字符串指定頂級 XML 節點的名稱（Genode 中的報告通常是 XML 格式的），而第二個字符串定義會話標簽，可以將其視為報告的名稱。

方法：該_update_state() 方法有助于設置 LED 的狀態和更新組件的狀態報告。只要任一按鈕出現 IRQ，信號處理程序就會調用該方法。_handle_irq()此方法確認 IRQ 并評估按鈕狀態以相應地更新 LED 狀態。

構造函數：構造函數非常簡單。它設置初始 LED 狀態，在兩個 IRQ 連接上注冊信號處理程序并確認任何掛起的 IRQ。

我們需要的下一個要素是運行腳本。在 Genode 中，運行腳本是對某個要執行的場景的定義。更準確地說，它包含有關要構建的組件以及如何組合它們以創建特定場景的信息。運行腳本還可以評估正在運行的系統的（串行）輸出以檢查錯誤。由于運行腳本位于run/目錄中，因此我在 genode-zynq 存儲庫的克隆中創建了包含以下內容的文件run/zynq_gpio_demo.run 。

create_boot_directory

 import_from_depot [depot_user]/src/[base_src] \
                   [depot_user]/src/init \
                   [depot_user]/src/report_rom \
                   [depot_user]/src/zynq_platform_drv \
                   [depot_user]/src/zynq_pin_drv \
                   [depot_user]/raw/[board]-devices

 build { app/zybo_gpio_demo }

 install_config {
     <config>
         <parent-provides>
             <service name="LOG"/>
             <service name="PD"/>
             <service name="CPU"/>
             <service name="ROM"/>
             <service name="IO_MEM"/>
             <service name="IRQ"/>
         parent-provides>

         <default caps="200"/>

         <start name="report_rom">
             <resource name="RAM" quantum="1M"/>
             <provides>
                 <service name="Report"/>
                 <service name="ROM"/>
             provides>
             <route>
                 <service name="ROM"> <parent/> service>
                 <service name="CPU"> <parent/> service>
                 <service name="PD">  <parent/> service>
                 <service name="LOG"> <parent/> service>
             route>
             <config verbose="yes"/>
         start>

         <start name="platform_drv" managing_system="yes">
             <binary name="zynq_platform_drv"/>
             <resource name="RAM" quantum="1M"/>
             <provides><service name="Platform"/>provides>
             <config>
                 <policy label="zynq_pin_drv -> ">
                     <device name="gpio0"/>
                 policy>
             config>
             <route>
                 <any-service> <parent/> any-service>
             route>
         start>

         <start name="zynq_pin_drv">
             <resource name="RAM" quantum="1M"/>
             <provides>
                 <service name="Pin_state"/>
                 <service name="Pin_control"/>
                 <service name="IRQ"/>
             provides>
             <route>
                 <service name="ROM"> <parent/> service>
                 <service name="CPU"> <parent/> service>
                 <service name="PD">  <parent/> service>
                 <service name="LOG"> <parent/> service>
                 <service name="Platform">
                     <child name="platform_drv"/>
                 service>
             route>
             <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_prefix="zybo_gpio_demo_mio -> Btn4" pin="Btn4"/>
                <policy label_prefix="zybo_gpio_demo_mio -> Btn5" pin="Btn5"/>
                <policy label_prefix="zybo_gpio_demo_mio -> Led4" pin="Led4"/>
             config>
         start>

         <start name="zybo_gpio_demo_mio">
             <resource name="RAM" quantum="1M"/>
             <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="report">
                     <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/>
         start>

     config>
 }

 build_boot_image { zybo_gpio_demo_mio }

 run_genode_until forever

我不想在這里詳述所有細節。運行腳本指定要從倉庫（Genode 的包管理）導入哪些檔案，以及要從源代碼樹構建哪些組件。它還為頂級 init 組件安裝配置。關于init的配置的詳細解釋請參考Genode手冊的系統配置章節。但是，我們可以在沒有深入了解的情況下確定該場景由四個部分組成：report_rom、platform_drv和。zynq_pin_drvzybo_gpio_demo_mio

report_rom：該組件提供一個ROM和一個Report服務。它允許組件發布它們的報告，這些報告可以通過 ROM 連接訪問。因此，它實現了單寫入器、多讀取器方案。

platform_drv：這是一個驅動程序組件，可以最終控制硬件外圍設備（例如 MMIO 設備）。根據其配置，它通過提供的平臺服務將對各個設備的控制權傳遞給其他組件。平臺驅動程序需要訪問我從軟件倉庫導入的板特定設備ROM。它的配置包含基于標簽的策略，這些策略將設備（由設備ROM定義）分配給相應的平臺會話。在這里，被授予對設備的訪問權限。zynq_pin_drvgpio0

zynq_pin_drv:這是引腳驅動程序。其配置為按鈕指定了兩個輸入引腳，為 LED 指定了一個輸出引腳。查看Zybo Z7 手冊，我發現 LED 4 連接到 MIO 引腳 7，按鈕 4 和 5 分別連接到 MIO 引腳 50 和 51。知道 GPIO bank 0 覆蓋 MIO 引腳 0 到 31 而 bank 1 覆蓋引腳 32 到 53，我最終得到了發布的配置。與平臺驅動程序類似，對單個引腳的訪問由基于標簽的策略定義。

zybo_gpio_demo_mio:這是我上面實現的演示組件。請注意，我將它的和Pin_state會話請求路由到 pin 驅動程序。會話請求被路由到組件。Pin_controlIrqreportreport_rom

該場景的構建和運行如下：

build/arm_v7a$ make run/zybo_gpio_demo BOARD=zynq_zybo_z7 KERNEL=hw

通過此設置，我可以使用兩個按鈕打開/關閉 LED。在串行控制臺上，我可以進一步看到以下輸出：

[init -> report_rom] report 'zybo_gpio_demo_mio -> state'
[init -> report_rom]   
[init -> report_rom] report 'zybo_gpio_demo_mio -> state'
[init -> report_rom]   "yes"/>

并不壯觀，但看到引腳驅動器工作時仍然令人滿意。在下一步中，我為 FPGA 創建了一個自定義比特流來控制連接到 PL 的開關、按鈕和 LED。

創建自定義比特流

為可編程邏輯實施復雜的定制設計可能會很繁瑣，尤其是如果您是 FPGA 領域的新手。我最后一次使用賽靈思 FPGA 是在大約十年前，當時工具發生了很大變化。因此，我從一個非常簡單的設計開始，以檢查我的基本設置是否正確。

作為先決條件，我必須在單獨的 Ubuntu VM 中安裝 Vivado ML Standard。我對它占用的磁盤空間量 (~60GB) 感到震驚，因此不得不相應地增加 VM 大小。

作為起點，我遵循了本教程。由于它已經包含了 Vivado 的詳細分步說明，因此我寧愿堅持對本文中的各個步驟進行簡要總結。

在 Vivado 中，我打開了一個新項目并使用左側的 Flow Navigator 創建了一個模塊設計。在block design中，我添加了Zynq處理系統作為IP（intellectual property）核。添加 IP 核后，Vivado 通常會提供運行連接自動化以連接所有明顯信號的選項。運行自動化將IP 核的接口DDR和接口連接到相應的（自動創建的）外部端口。FIXED_IO

在這一點上，我很好奇我的最低限度但無用的設計是否基本上是完整和正確的，因此點擊了“驗證設計”按鈕。

?

哎呀！顯然，因為我沒有按照上述教程的建議添加 AXI IP 核，連接自動化無法決定如何連接 AXI 時鐘信號。通過鎖定教程中的其他步驟，我能夠決定 AXI 時鐘信號應該連接到FCLK_CLK0IP 內核的接口。

修復此問題后，我生成了 HD??L 包裝器（右鍵單擊模塊設計）。不幸的是，我的 Vivado 安裝在此過程中總是卡住，就像“初始化語言服務器”時一樣。在工具→設置→工具設置→文本編輯器→語法檢查中將語法檢查從“Sigasi”更改為“Vivado”，在重新啟動 Vivado 后為我解決了這個問題。

在這一點上，我開始偏離上述教程。我不想實例化 AXI_GPIO IP 內核（這需要引腳驅動程序的支持），而是想使用 SoC 的 GPIO 控制器與 PL 交互。這是可能的，因為 GPIO 控制器的 bank 2 和 3 通過 EMIO 接口連接到 PL。EMIO 信號只需要路由到 FPGA 的正確引腳。

通過雙擊 Zynq PS IP 內核，我在外設 I/O 引腳卡上啟用了 GPIO EMIO。此外，在MIO 配置卡上，我將 EMIO GPIO 寬度設置為 12（用于 4 個開關、4 個 LED、4 個按鈕）。通過這樣做，IP 內核獲得了一個GPIO_0接口。為了使它成為一個外部信號，我選擇了名稱并右擊以從上下文菜單中選擇Make external 。這創建了一個名為連接到 IP 內核的外部接口。GPIO_0_0由于 GPIO 信號是三態的，外部信號將由gpio_0_0_tri_ioVivado 命名。我通過查看 HDL 包裝器（在重新生成它之后）仔細檢查了這個命名方案。

最后，我添加了一個 Xilinx 設計約束 (XDC) 文件以將信號綁定gpio_0_0_tri_io 到那些實際連接到開關/LED/按鈕的設備引腳。幸運的是，Digilent為其電路板提供了主文件。使用主文件，只需取消注釋個別行并插入相應的信號名稱。我通過添加源對話框添加了 Zybo-Z7-Master 文件，取消了 LED、按鈕和開關行的注釋，并將信號名稱插入gpio_0_0_tri_io[0]到gpio_0_0_tri_io[11]. 您可以在上述教程中找到更詳細的說明。

生成比特流時，我注意到 Vivado 占用了大量 RAM。由于我在單獨的 Ubuntu VM 中運行該工具，這有時會導致無法解釋的構建錯誤。向 VM 添加另一個 GB 的 RAM 并將作業數量減少到 1 對我來說是個竅門。最終，我能夠通過File → Export → Export Bitstream File導出生成的比特流文件。

在啟動時加載比特流

由于 FPGA 使用易失性存儲器來存儲其編程，因此必須在每次通電后重新編程。比特流文件包含必要的（特定于設備的）信息。最簡單的方法是讓引導加載程序負責加載比特流。Xilinx 的 FSBL 和 u-boot 對此提供支持。當使用相應的配置選項編譯時，您可以使用 u-boot 的fpga命令加載比特流。有兩個子命令：load和loadb。前者需要原始比特流 (.bin)，例如通過回讀獲取的比特流。后者需要 Vivado 導出的 a.bit 文件。與原始比特流相比，此文件具有不同的字節順序并包含文件頭。

為了簡化啟動時的比特流加載，我在 u-boot 的默認環境中添加了兩個命令，分別檢查fpga.bin 。fpga.bit文件，如果存在，fpga在啟動到 Genode 之前執行相應的命令。此外，您可以通過將以下行添加到您的etc/build.conf來使用比特流填充 SD 卡映像。

RUN_OPT_zybo += --image-uboot-bitstream "/path/to/bitstream.bit"

測試比特流

為了測試比特流，我實現了一個zybo_gpio_demo_sw組件，它控制開關和每個開關旁邊的 LED。代碼非常簡單。您可以在genode-zynq 存儲庫中找到它。

我還在run/zybo_gpio_demo.run腳本中添加了以下啟動節點：

<start name="zybo_gpio_demo_sw">
     <resource name="RAM" quantum="1M"/>
     <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="ROM"> <parent/> service>
         <service name="CPU"> <parent/> service>
         <service name="PD">  <parent/> service>
         <service name="LOG"> <parent/> service>
     route>
     <config/>
 start>

此外，更有趣的是，我修改了 pin-driver 配置以添加相應的策略：

<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"/>
 config>

因為我想在上升沿和下降沿觸發中斷，所以我使用了開關輸入引腳。irq="edges"

啟用 RGB LED

到目前為止，我故意忽略了 Zybo Z7-20 (Z7-10) 上兩個（一個）RGB LED 的存在。其中每一個實際上都由一個綠色、一個藍色和一個紅色 LED 組成。原則上，這些 LED 可以像其他 LED 一樣進行控制。然而，由于它們的亮度需要通過脈寬調制 (PWM) 進行調節，因此為這項工作實施定制 IP 內核更為明智。這在本故事的第 2 部分中有所介紹，其中還包括使用我的預構建比特流再現完整 GPIO 演示的說明。