使用Genode控制Zybo Z7 GPIO - 第2/2部分

描述

在第一部分中，我通过 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 用于循环显示不同的颜色和亮度设置。